知財求人 - 知財ポータルサイト「IP Force」
▶ 株式会社東芝の特許一覧 ▶ 東芝ソリューション株式会社の特許一覧
特許7600324多様性を持つエッジコンピュータ、エッジコンピュータ制御システム
(19)【発行国】日本国特許庁(JP)
(12)【公報種別】特許公報(B2)
(11)【特許番号】
(24)【登録日】2024-12-06
(45)【発行日】2024-12-16
(54)【発明の名称】多様性を持つエッジコンピュータ、エッジコンピュータ制御システム
(51)【国際特許分類】
G06F 9/54 20060101AFI20241209BHJP
A61B 5/00 20060101ALI20241209BHJP
A61B 5/01 20060101ALI20241209BHJP
【ＦＩ】
G06F9/54 F
A61B5/00 102A
A61B5/01 350
【請求項の数】
5
(21)【出願番号】P 2023131979
(22)【出願日】2023-08-14
(62)【分割の表示】P 2020071175の分割
【原出願日】2020-04-10
(65)【公開番号】P2023138864
(43)【公開日】2023-10-02
【審査請求日】2023-08-14
(73)【特許権者】
【識別番号】000003078
【氏名又は名称】株式会社東芝
(73)【特許権者】
【識別番号】301063496
【氏名又は名称】東芝デジタルソリューションズ株式会社
(74)【代理人】
【識別番号】110001737
【氏名又は名称】弁理士法人スズエ国際特許事務所
(72)【発明者】
【氏名】吉本 武弘
(72)【発明者】
【氏名】石塚 晃
【審査官】坂東 博司
(56)【参考文献】
【文献】特開２０１８－１８５７９７（ＪＰ，Ａ）
【文献】特表２０１７－５２５２３２（ＪＰ，Ａ）
【文献】米国特許出願公開第２０１８／００２７１００（ＵＳ，Ａ１）
【文献】特表２０１９－５０７４０３（ＪＰ，Ａ）
(58)【調査した分野】(Int.Cl.，ＤＢ名)
Ａ６１Ｂ ５／０１
Ａ６１Ｂ ５／００
Ｇ０６Ｆ ９／５４
(57)【特許請求の範囲】
【請求項1】
携帯端末、ＩｏＴ機器を含む複数のデバイス、クラウドサーバ及びＷｅｂサービスサーバと通信可能なエッジコンピュータであって、前記クラウドサーバから事前に取り込んだ複数のアプリケーションルールを実行させるためのアプリケーションエンジンと、
前記複数のデバイスのそれぞれと、前記クラウドサーバ及び前記Ｗｅｂサービスサーバのそれぞれとに対応した個々の前記アプリケーションルールを適用するために設けられた複数のマイクロサービスとを備え、
前記複数のマイクロサービスのそれぞれは、
前記アプリケーションエンジンから、対応する前記アプリケーションルールを受取り、
前記アプリケーションルールに基づいて、対応する前記複数のデバイス及び前記Ｗｅｂサービスサーバに実行させようとするルールのＡＰＩコマンドを送信すること、また、前記複数のデバイス及び前記Ｗｅｂサービスサーバのそれぞれから受け取ったデータを前記アプリケーションエンジンに提供することで、対応する前記アプリケーションルールを実現させる、エッジコンピュータ。
【請求項2】
前記複数のマイクロサービスのいずれかは、データ解析処理を専門に行うＡＩクラスを備え、前記データ解析処理の結果を前記アプリケーションエンジンに送ることで、前記アプリケーションルールの処理負荷を低減している、請求項1記載のエッジコンピュータ。
【請求項3】
前記複数のデバイスには、赤外線の光に感度を有する第1のカメラと、赤外線の光を除く光に感度を有する第２のカメラを含み、前記アプリケーションルールは、前記第1のカメラと前記第２のカメラが撮像した画像を判断して高熱者を検知するためのルールを備えることを特徴とする、請求項1記載のエッジコンピュータ。
【請求項4】
電話機能を備える携帯形であることを特徴とする、請求項1記載のエッジコンピュータ。
【請求項5】
携帯端末、ＩｏＴ機器を含む複数のデバイス、クラウドサーバ及びＷｅｂサービスサーバと通信可能なエッジコンピュータの制御システムであって、前記クラウドサーバから事前に取り込んだ複数のアプリケーションルールを実行させるためのアプリケーションエンジンと、
前記複数のデバイスのそれぞれと、前記クラウドサーバ及び前記Ｗｅｂサービスサーバのそれぞれとに対応した個々の前記アプリケーションルールを適用するために設けられた複数のマイクロサービスとを備え、
前記複数のマイクロサービスのそれぞれは、
前記アプリケーションエンジンから、対応する前記アプリケーションルールを受取り、
前記アプリケーションルールに基づいて、対応する前記複数のデバイス及び前記Ｗｅｂサービスサーバに実行させようとするルールのＡＰＩコマンドを送信すること、また、前記複数のデバイス及び前記Ｗｅｂサービスサーバのそれぞれから受け取ったデータを前記アプリケーションエンジンに提供することで、対応する前記アプリケーションルールを実現させるものであり、
前記複数のデバイスと前記Ｗｅｂサービスサーバとの連携を可能とするエッジコンピュータの制御システム。
【発明の詳細な説明】
【技術分野】
【0001】
本発明の実施形態は、多様性を持つエッジコンピュータ、エッジコンピュータ制御システムに関する。
【背景技術】
【0002】
コンピュータシステムは、各種のプログラムを搭載して、多様性をもつことができる。しかし、各種のプログラムは個々に切り換えて使用され、切り替えの後、切り替わったプログラムの処理範囲内でデータ処理が終了する。
【先行技術文献】
【特許文献】
【0003】
【文献】特開２０１８－１８５７９７号公報
【発明の概要】
【発明が解決しようとする課題】
【0004】
本実施形態では、各種の独自の機能を互いに連携させた処理を可能とする多様性をもつエッジコンピュータ、エッジコンピュータ制御システムを提供することを目的とする。
【課題を解決するための手段】
【0005】
本実施形態では、携帯端末、ＩｏＴ機器を含む複数のデバイス、クラウドサーバ及びＷｅｂサービスサーバと通信可能なエッジコンピュータであって、
前記クラウドサーバから事前に取り込んだ複数のアプリケーションルールを実行させるためのアプリケーションエンジンと、
前記複数のデバイスのそれぞれと、前記クラウドサーバ及び前記Ｗｅｂサービスサーバのそれぞれとに対応した個々の前記アプリケーションルールを適用するために設けられた複数のマイクロサービスとを備え、
前記複数のマイクロサービスのそれぞれは、
前記アプリケーションエンジンから、対応する前記アプリケーションルールを受取り、
前記アプリケーションルールに基づいて、対応する前記複数のデバイス及び前記Ｗｅｂサービスサーバに実行させようとするルールのＡＰＩコマンドを送信すること、また、前記複数のデバイス及び前記Ｗｅｂサービスサーバのそれぞれから受け取ったデータを前記アプリケーションエンジンに提供することで、対応する前記アプリケーションルールを実現させる、エッジコンピュータが提供される。
前記クラウドサーバから事前に取り込んだ複数のアプリケーションルールを実行させるためのアプリケーションエンジンと、
前記複数のデバイスのそれぞれと、前記クラウドサーバ及び前記Ｗｅｂサービスサーバのそれぞれとに対応した個々の前記アプリケーションルールを適用するために設けられた複数のマイクロサービスとを備え、
前記複数のマイクロサービスのそれぞれは、
前記アプリケーションエンジンから、対応する前記アプリケーションルールを受取り、
前記アプリケーションルールに基づいて、対応する前記複数のデバイス及び前記Ｗｅｂサービスサーバに実行させようとするルールのＡＰＩコマンドを送信すること、また、前記複数のデバイス及び前記Ｗｅｂサービスサーバのそれぞれから受け取ったデータを前記アプリケーションエンジンに提供することで、対応する前記アプリケーションルールを実現させる、エッジコンピュータが提供される。
【図面の簡単な説明】
【0006】
【発明を実施するための形態】
【0007】
図１を用いて、本実施形態の基本的概念を説明する。図１（ａ）が示すように、複数の人が集まった場所を想定する。その中に体温が所定値（例えば摂氏３７．５度）以上の高熱者が居た場合には、その高熱者を自動で個別検出する。図１（ｂ）の表示例では、斜線で示した人が摂氏３７．５度以上の高熱者に該当する。そしてその情報を、自動通知する（図１（ｃ））。その通知方法として複数の選択肢が存在し、本実施形態では非常に簡単な方法で選択肢の選定が行える。ここで通知方法に関して、複数の方法を同時に選択してもよい。
【0008】
図１（ａ）では集合場所に集まった人数が比較的少数なため、各自はそれぞれ分離して表示されている。しかし集合する人の人口密度が増加すると、部分的な重なりが生じてくる。被測定対象物の表面温度分布を測定する従来のサーモグラフィ技術では、複数の人が互いに重なり合った場所での個別識別ができない。したがって従来のサーモグラフィ技術のみを使用した場合には、人の密集場所での高熱者のみの個別検出（密集場所からの個別抽出）ができない。
【0009】
本実施形態では赤外線カメラを用いたサーモグラフィ技術に画像認識技術を組み合わせて、高熱者のみの個別検出（個別抽出）を可能にした。具体的な組み合わせ方法として本実施形態では、赤外線カメラ８０６に対する制御手段４としてのマイクロサービス８０Ｃの一部（あるいはその内部）に、ＡＩ技術を利用した画像認識機能を持ったプログラム（画像認識クラスAI Analyze Class）２０１８の組み込み７６を行う。詳細は図１１と図１３を用いて後述する。
【0010】
人が集合して活動する場所でのウィルス感染リスクを軽減するために、感染が疑われる高熱者を容易に検出・通知する技術が必要とされる。本実施形態では、既存のスマートフォンやタブレットなどのエッジコンピュータ６に市販の赤外線カメラ８０６を装着し、詳細は後述するｉｆＬｉｎｋ（登録商標）アプリと呼ぶソフトウェア（サービス提供アプリケーションプログラム）９２をインストールするだけで利用が可能となる。
【0011】
上記に説明した市販の赤外線カメラ８０６として、市販のスマートフォンやタブレットなどのエッジコンピュータ６と接続できる赤外線カメラ８０６を使用してもよい。この赤外線カメラ８０６を使用すると、非常に容易に市販のスマートフォンやタブレットなどのエッジコンピュータ６と接続できるので、本実施形態における高熱者検出システムを簡単に構築できる。
【0012】
また上記のｉｆＬｉｎｋアプリ９２は、多くの人が所持しているスマートフォンやタブレットのアプリとして動作する。その結果として、既存のスマートフォンやタブレット、赤外線カメラ８０６のインフラストラクチャ（使用環境）を使用し、ｉｆＬｉｎｋアプリ９２のインストールという非常に簡易的な方法のみで、各活動拠点での感染リスク軽減に役立つ効果がある。
【0013】
本実施形態において赤外線カメラ８０６が撮影した映像あるいは静止画像に画像認識を組み合わせて、集団の中から高熱者のみを個別検出（個別抽出）し、その情報を自動で通知する。
【0014】
赤外線カメラ８０６によるサーモグラフィ技術を活用して被測定対象物の表面温度を検知する方法は、従来から存在する。しかし上述したように人が密集して複数人が重なった場合、これまでは映像／静止画の観察者が目視で確認しながら個人個人に分離（個別抽出）することが必要だった。さらに従来のサーモグラフィ技術のみでは被測定対象物が人間か他の物体かの識別ができないため、被測定対象物の識別者を必要とする。そのため従来のサーモグラフィ技術は、専任の監視員を配備できる会社や施設の受付などでしか利用できなかった。
本実施形態ではＡＩ技術を用いた画像認識クラス（AI Analyze Class）２０１８の組み込み７６により、赤外線カメラから得られた画像（映像または静止画）をコンピューター（エッジコンピュータ６）が高熱者を認識する。このようにエッジコンピュータ６内部で自動認識されるので、監視員がいなくても高熱者を検知し通知することができる。従って本実施形態では監視（高熱者の自動個別検出）コストが大幅に低下する効果がある。
なお高熱者の認識方法として本実施形態ではＡＩ技術を用いた画像認識クラス（AI Analyze Class）２０１８の使用に限らず、任意の画像認識方法を採用してもよい。例えば専用の画像認識機能を有した独自のハードウェアを事前に準備してもよい。この場合にはこのハードウェア宛に赤外線カメラから得られた画像を送信して画像認識させ、その結果を返信させてもよい。
本実施形態ではＡＩ技術を用いた画像認識クラス（AI Analyze Class）２０１８の組み込み７６により、赤外線カメラから得られた画像（映像または静止画）をコンピューター（エッジコンピュータ６）が高熱者を認識する。このようにエッジコンピュータ６内部で自動認識されるので、監視員がいなくても高熱者を検知し通知することができる。従って本実施形態では監視（高熱者の自動個別検出）コストが大幅に低下する効果がある。
なお高熱者の認識方法として本実施形態ではＡＩ技術を用いた画像認識クラス（AI Analyze Class）２０１８の使用に限らず、任意の画像認識方法を採用してもよい。例えば専用の画像認識機能を有した独自のハードウェアを事前に準備してもよい。この場合にはこのハードウェア宛に赤外線カメラから得られた画像を送信して画像認識させ、その結果を返信させてもよい。
【0015】
図１（ｃ）では体温が所定値（例えば摂氏３７．５度）を超えた高熱者を検出すると、その結果を自動通知する。この自動通知方法の選択肢例として、高熱者の存在を明示した画像（映像または静止画像）をスマートフォンやタブレットなどのエッジコンピュータ６の表示画面１２上に表示１２１０してもよい。またそれに限らず、高熱者を検出したエッジコンピュータ６の近くに設置されたサイネージ（電子掲示板）８０４上に警告を表示１２２０してもよい。
【0016】
また表示形態として特定画像に限らず、“警告文をテキスト形式で記述”された警告画面をエッジコンピュータ６の表示画面１２上やサイネージ８０４上に表示１２３０してもよい。さらに所定画像やテキスト警告文などの視覚に訴えるだけでなく、音声警告１２４０などの聴覚や、触覚、嗅覚に訴える方法で通知してもよい。
【0017】
さらにネットワーク通信などを利用して、高熱者検出場所から離れた場所へ通知する遠隔通知を行ってもよい。この遠隔通知方法として、メール通信（２３０）１２５０や、Ｗｅｂ画面（２１０）上の情報掲載１２６０を行ってもよい。このＷｅｂ画面上に掲載１２６０される情報として高熱者個別情報に限らず、異なる多数箇所で得られた情報の集計結果を掲示してもよい。
【0018】
また通知形態として上記に説明した“情報伝達”に限らず、通行ゲート（８２０）の遮断処理１２７０など機器動作１２９０を伴う物理的操作を行ってもよい。
【0019】
上記に説明した選択肢に限らず、任意の通知方法で高熱者の存在を通知してもよい。また通知方法として、複数の選択肢に対して同時に通知してもよい。
【0020】
従来の監視システムは検知後の通知のしくみが固定であり、そのための利用方法に柔軟性がなかった。それに比べて本実施形態における高熱者を検知後の通知方法は、利用者（ユーザ）の所持する機器、ソフトウェア等に合わせて柔軟に設定することができる。その柔軟に設定できる選択肢として、パトライト（登録商標）を点灯してもよいし、警報音１２４０を鳴らしたり音声合成を利用した音声案内１２８０（音声警告１２４０）、メール送信１２５０やＳＮＳ（Social Networking Service）等のメッセージングソフトで通知、画面表示１２１０、１２３０など任意に設定可能となっている。この通知方法としては、事前に利用者が設定した方法を使用する。
この利用者（ユーザ）の所持する機器、ソフトウェア等に合わせて柔軟に設定可能にする技術として本実施形態では図７や図１１、図２２を用いて後述するように、アプリケーション（ＩＦ－ＴＨＥＮ）ルール７０の設定と、それを利用したアプリケーション（ＩＦ－ＴＨＥＮ）エンジン９０の設定を行う。つまりユーザは、例えばスマートフォンなどの画面上で上記のような複数の通知方法の仕組みの中から一つあるいは複数の通知方法を柔軟に設定できる。
この利用者（ユーザ）の所持する機器、ソフトウェア等に合わせて柔軟に設定可能にする技術として本実施形態では図７や図１１、図２２を用いて後述するように、アプリケーション（ＩＦ－ＴＨＥＮ）ルール７０の設定と、それを利用したアプリケーション（ＩＦ－ＴＨＥＮ）エンジン９０の設定を行う。つまりユーザは、例えばスマートフォンなどの画面上で上記のような複数の通知方法の仕組みの中から一つあるいは複数の通知方法を柔軟に設定できる。
【0021】
図２を用いて、本実施形態における基本システム（高熱者検出システム）を説明する。本基本システム（高熱者検出システム）では、赤外光にを有する第１の光センサに該当する赤外線カメラ８０６と、赤外線以外の波長光にを有する撮像素子を含む第２の光センサである通常のカメラ８１６を併用する。
【0022】
一般的に波長域が３８０ｎｍから８１０ｎｍの範囲を“可視光”と呼び、波長域が８１０ｎｍから１ｍｍの範囲を一般的には“赤外線”または“赤外光”と呼ぶ。しかし黒体輻射光を用いて“人間の体温測定”を行うのに適した“赤外光”の波長域は図１９が示すように、１μｍから１００μｍの範囲内であり、望ましくは２．５μｍから２０μｍの範囲内が適正と考えられる。したがってここで第１の光センサとして赤外線カメラ８０６で使用される“赤外線”または“赤外光”の波長域は、１μｍから１００μｍの範囲内（望ましくは２．５μｍから２０μｍの範囲内）を意味する。
【0023】
したがって上記範囲を外れた波長光を、ここでは“赤外線以外の波長光”と呼ぶ。また本実施形態では、体温が所定値を超えた高熱者の検出に前記の“赤外線以外の波長光”にを有する撮像素子を含む第２の光センサ（通常のカメラ８１６）から得られた第２の信号も使用する。それに適した光として、紫外線（波長１０ｎｍ以上）、可視光、近赤外光（波長２．５μｍ以下）、マイクロ波（波長１０ｃｍ以下）が適している。上記の情報を加味した“赤外線以外の波長光”の波長域は、１０ｎｍから２．５μｍの範囲あるいは２０μｍから１０ｃｍの範囲（望ましくは３８０ｎｍから１μｍの範囲あるいは１００μｍから１０ｃｍの範囲）となる。
【0024】
“通常カメラ８１６”とは一般的に、波長域が３８０ｎｍから８１０ｎｍの“可視光”にを有する撮像素子を含む第２の光センサを示す場合が多い。しかし図２に記載した“通常カメラ８１６”は、１０ｎｍから２．５μｍの範囲あるいは２０μｍから１０ｃｍの範囲（望ましくは３８０ｎｍから１μｍの範囲あるいは１００μｍから１０ｃｍの範囲）にを有する撮像素子を含む光センサを示す。
【0025】
スマートフォンやタブレットなどのエッジコンピュータ６の多くには、通常カメラ８１６が標準的に内蔵されている。したがってスマートフォンやタブレットなどのエッジコンピュータ６に標準的に内蔵されたカメラを、図２に示す通常カメラ８１６として使用しても良い。
【0026】
一方で市販の赤外線カメラ８０６を使用する場合には、その赤外線カメラ８０６（赤外光にを有する第１の光センサ）から得られた第１の信号（温度特性信号）を、無線通信手段あるいは有線通信手段を利用してエッジコンピュータ６に通信してもよい。またそれに限らず図３を使って後述するように、接続部１０を介して直接信号転送してもよい。
【0027】
図２に示すように本システムのアプリケーション１００（ソフトプログラム）は、利用シーンに応じた認識ロジックの設定が可能な認識設定部１１０の機能と、判定温度設定部１２０の機能、アプリケーション（ＩＦ－ＴＨＥＮ）ルール７０（図７と図１１、図２２を用いて後述）を設定する検知ルール設定部１３０の機能、検知時動作設定部１４０の機能、検知情報送信部１５０の機能から構成されている。図２の実施例では、この本システムのアプリケーション１００は、エッジコンピュータ６にインストールされるソフトウェアの形態を取る。しかしそれに限らず、各構成１１０～１５０の機能一部が専用ハード（電子回路）で構成されてもよい。
【0028】
従って上述した本システムのアプリケーション１００（ソフトプログラム）がインストールされたエッジコンピュータ６あるいは各機能１１０～１５０の一部を実行する専用ハード（電子回路）が組み込まれたエッジコンピュータ６が、本実施形態における高熱者検出装置に該当する。
【0029】
赤外線カメラ８０６（赤外光にを有する第１の光センサ）から得られた第１の信号（温度特性信号）は、認識設定部（の機能）１１０の赤外線画像認識部１１６（第１の画像認識部）に送信される。そしてこの赤外線画像認識部１１６で、空間的な温度分布特性が画像認識（第１の画像認識）される。
【0030】
通常のカメラ８１６（赤外線以外の波長光にを有する撮像素子を含む第２の光センサ）から得られた画像信号（映像信号または静止画像信号が相当し第２の信号に対応）は、認識設定部（の機能）１１０の通常カメラ画像認識部１１２（第２の画像認識部）に送信される。そしてこの通常カメラ画像認識部１１２で行う第２の画像認識として、１〕画像信号の画像認識（画像解析）を行い、２〕画面内に人が居るかどうかを判別（人物検出）し、３〕画面内に人が居る場合には、その人数を算出（人数検出）し、４〕画面内に人が居る場合に限り、その人数それぞれの頭部の位置を認識（頭部検出）する。またそれと同時に５〕画面内に判別された人毎に、その人と赤外線カメラ８０６とのの計算（検出）も行ってもよい。
【0031】
また判定温度設定部（の機能）１２０には人物頭部温度判定部１２５が存在し、この中で赤外線カメラ８０６の方向を向いている人物頭部の温度が体温として測定される。そして体温が所定値（例えば摂氏３７．５度）を超えた高熱者を検出（高熱者有無の判定）する。その温度判定の結果として高熱者を検出した場合には、自動的に通知を行う。具体的には検知ルール設定部（の機能）１２０の検知時動作指示部（アプリケーション（ＩＦ－ＴＨＥＮ）エンジン）９０に検知情報が伝わる。そして検出部動作設定部（の機能）１４０が動作して、通知処理が実行される。
【0032】
図３と図４を用いて、この通常カメラ画像認識部１１２で行われる“２〕人物検出”の説明を行う。赤外線カメラ８０６から得られた第１の信号（温度特性信号）のみからでは、黒体輻射する熱源の種別（何から熱が輻射されているか？）を特定できない。したがって通常カメラ画像認識部１１２で行われる画像認識技術を組み合わせない場合には、人以外の物体の温度も判定される。
【0033】
図３（ａ）が示す例として、手に持っているコーヒーカップ内に入った高温のコーヒーを飲んでいる人を考える。そしてこの時には、コーヒーカップの表面温度が５０℃だったとする。この場面から得られるサーモグラフィ画面（赤外線画像認識部１１６の出力）では図３（ｂ）が示すように、コーヒーカップの表面温度５０℃が検出される。人の高熱か否かの判定温度が“３７．５℃”とした場合には、この判定温度をコーヒーカップの表面温度５０℃が超える。黒体輻射する熱源の種別（何から熱が輻射されているか？）を特定できないと、『高熱者が存在する』と誤判定される（図３（ｃ））。
【0034】
図４は、『人の頭部の温度のみを判定に使用』する場合の効果を示す。ここで図４（ａ）は、図３（ａ）と同じ図を示している。そして『人の頭部の温度のみを判定に使用』する場合には、コーヒーカップの表面温度５０℃が検出対象から外される（図４（ｂ））。
【0035】
この通常カメラ画像認識部１１２で行われる“２〕人物検出”の結果と赤外線画像識別部１１６から出力される画面内の空間的温度分布特性は、人物頭部温度判定部１２５（図２）で統合処理される。そして人物頭部温度判定部１２５では図４（ｃ）が示すように、『人の頭部の温度のみ』が“高熱者の有無判定”に利用される。ここでは人物の頭部温度を体温測定に利用しているが、それに限らず人物の任意場所を体温測定に利用してもよい。人物の頭部以外で体温測定する場合には、“人物頭部温度判定部１２５”の名称は同じ機能を有する“人物の体温判定部”に変更してもよい。そしてこの場合には、“第１の画像認識の結果と第２の画像認識の結果から、人物の体温判定部が体温が所定値を超えた高熱者の有無を検出する”ことになる。
【0036】
このように本実施形態では、赤外光にを有する第１の光センサ（赤外線カメラ８０６）から得られた第１の信号と、赤外線以外の波長光にを有する撮像素子を含む第２の光センサ（通常カメラ８１６）から得られた第２の信号を併用して、体温が所定値を超えた高熱者を検出する。その結果として、正常判定（図４（ｄ））の判定精度が大幅に向上する効果が生まれる。
【0037】
次に前述した通常カメラ画像認識部１１２（図２）で行われる“４〕頭部検出”の説明を行う。図３と図４を用いて上述したように、頭部の温度だけを取得すると他の熱源による誤検知を排除できる効果がある。またさらに、Ａ〕胴体や肢体は被服で覆われて露出しないので、そこからの体温測定結果の誤差が大きいＢ〕頭部は比較的露出しているため、比較的体温測定し易い。したがって頭部の温度のみの取得を行う事で、体温測定精度が向上する効果もある。
【0038】
さらに通常カメラ画像認識部１１２で行われる“３〕人数検出”との関係も説明する。複数の人が密集した場所から得られる画像（映像または静止画像）では、Ｃ〕体の一部（胴体や肢体）が隣接者と重なり易いが、頭部の位置は比較的分離配置されるという特徴がある。したがって本実施形態では特に頭部位置を利用することで“３〕人数検出”の画像認識処理の簡素化が図れるばかりでなく、“３〕人数検出”の精度も向上する。
【0039】
通常カメラ画像認識部１１２で行われる“４〕頭部検出”を利用した、“２〕人物検出”と“３〕人数検出”の具体的方法に付いて説明する。人物の頭部の形や髪形に関する複数の標準サンプルが予め、通常カメラ画像認識部１１２に保存されている。そして通常カメラ８１６（赤外線以外の波長光にを有する撮像素子を含む第２の光センサ）から得られた画像（第２の信号）と上記複数の標準サンプル間のパターンマッチング度を算出する。そしてパターンマッチング度が所定値を超えた領域を“人の頭部候補”と推定する。
【0040】
多くの場合、“人の頭部”の下に胴体が存在し、その胴体の周辺に肢体（手足）が配置されている。このように推定された“人の頭部候補”の直下に胴体や肢体が検出された場合のみ、“２〕人物検出”が行われる。そして画面内の“２〕人物検出”された領域の数が、“３〕人数検出”の結果となる。
【0041】
ところで“４〕頭部検出”された領域が“頭部の後ろ側”の場合には、精度の良い体温測定は難しくなる。体温測定対象者が後ろを向いた場合を考える。この場合には頭部の表皮から放出された黒体輻射光が、赤外線カメラ８０６に向かう光路途中の毛髪で散乱される。そして赤外線カメラ８０６で検出される黒体輻射光の光量が大幅に低下するため、体温測定精度が大幅に低下する（サーモグラフィの検出原理は、図１９を用いて後述する）。そのため“赤外線カメラ８０６に向かって前方を向いた頭部”のみを検出するのが望ましい。
【0042】
“赤外線カメラ８０６方向を向いた頭部”のみを“４〕頭部検出”の方法として、頭部前方に配置された“目”や“鼻”、“口”の位置を利用してもよい。具体的方法として、目や鼻、口の形状に関する複数の標準サンプルを、通常カメラ画像認識部１１２に予め保存されておく。そして通常カメラ８１６から得られた画像を細かい領域に分割し、分割領域毎に目や鼻、口の標準サンプルとの間のパターンマッチング度を算出する。そして得られた“目の候補となる領域の位置”と、“鼻の候補となる領域の位置”、“口の候補となる領域の位置”間の位置関係を利用して、“赤外線カメラ８０６方向を向いた頭部”を検出する。
【0043】
上記の説明では“赤外線カメラ８０６方向を向いた頭部”に関して“４〕頭部検出”を行い、人物頭部温度判定部１２５で頭部の体温を測定した。しかしそれに限らず、頭部以外の領域を利用して体温測定してもよい。
【0044】
また“２〕人物検出”の方法としても、必ずしも“４〕頭部検出”の結果を利用する必要は無い。本実施形態における“２〕人物検出”では、利用シーンに応じた柔軟な方法が適用できる。例えば受付カウンタを訪れた来客数は同時に数名以下の場合が多いので、比較的容易に人物の個別識別が容易となる。しかし受付カウンタ奥に設置された通常カメラ８１６では、来客者の上半身しか撮影できない。
【0045】
また通常カメラ８１６で通路を撮影する場合には全身撮影が可能な反面、動いている人を認識する必要がある。つまり通路での高熱者検出には、高速性が要請される。一方で４０人程度の生徒が集まった教室内で高熱者を検出する場合には、大勢の人の体温を同時測定する必要がある。
【0046】
このように異なる利用シーン毎に最適な人物検出ロジックを予め設定しておき、活用場面毎に最適ロジックを選択して柔軟な対応を可能にすることが好ましい。この活用場面に応じた柔軟な対応を可能にする方法として例えば、利用シーンの選択をユーザに許可する選択メニューを設けて、最適な人物検出ロジックが実行されるようにしても良い。また図１３を用いて後述するように、ＡＩを用いた画像認識クラス（AI Analyze Class）内に複数のメソッド（利用シーン毎の最適な人物検出ロジック）を配置しておく。そしてＡＰＩコマンドを利用して活用場面毎に最適なメソッドについて、選択的に呼び出し７６を行う。
【0047】
次に図２の通常カメラ画像認識部１１２で行われる“５〕画面内に判別された人毎の検出”に関して説明する。赤外線カメラ８０６では、黒体輻射する熱源（人の頭部）とのが遠いと、実際の温度より低めに読み取られる傾向がある（これに関しても、図１９を用いて後述する）。そのため“５〕検出”の結果を利用して、α〕赤外線画像認識部１１６で得られた空間的な温度分布特性に対して、人物頭部温度判定部１２５での体温補正（温度補正）を行うか、あるいはβ〕赤外線カメラ８０６とのが一定のより遠い人に対しては、判定温度より低い場合でも、検知時動作指示部（アプリケーション（ＩＦ－ＴＨＥＮ）エンジン）９０が注意を促す、指示を出すなどの処理が行える。
【0048】
したがって“５〕検出”を利用すると体温検出精度が向上し、検知時動作指示部９０からの指示精度が向上する効果が生まれる。
【0049】
上記の“５〕検出”の方法として、複数の通常カメラ８１６から得られる個別画像を利用し、“三角法”（測量などで用いられ、三角形の辺と角の関係を利用してなどを算出する手法）を用いてを算出してもよい。例えばスマートフォンやタブレットをエッジコンピュータ６に使用する場合、エッジコンピュータ６内に通常カメラ８１６が標準的に内蔵されている。したがって複数のエッジコンピュータ６から得られる個別画像を通信手段で共用すれば、“三角法”を用いてを算出できる。またそれに限らず、図２０で後述する２個の可視光センサ４６、４８が内蔵された３眼赤外線カメラを使用すれば、これ単独でも“５〕検出”が可能となる。
【0050】
あるいは図２の通常カメラ画像認識部１１２で解析された画像内からピンポイント的に最大温度位置や最小温度位置を推測し、これらを利用してもよい。すなわち通常カメラ画像認識部１１２で推定された最大／最小温度位置の情報と、赤外線画像認識部１１６で抽出された最大／最小温度位置の情報を利用し、“三角法”を用いてを算出してもよい。
【0051】
他の実施例として、ＧＰＳ（Global Positioning System）やビーコンを用いた位置情報を利用してもよい。例えば通常カメラ画像認識部１１２での画像認識の結果、検出された人物個々の識別（同定）が可能な場合を考える。その場合には識別（同定）された人物が所有している携帯端末（スマートフォン）と通信を行い、相手の位置情報を収集できる。
【0052】
検知時動作設定部１４０は、体温が所定値を超えた高熱者の存在を通知する各種の通知手段の制御方法を設定する機能を有する。この具体的な通知手段として、警報音の発生１２４０や音声案内１２８０、画面表示１２３０、メール送信１２５０、機器動作１２９０（１２７０）などの選択肢が存在する。これらの中で自動通知時に使用される選択肢（同時複数選択も可能）は、検知時動作指示部（アプリケーション（ＩＦ－ＴＨＥＮ）エンジン）９０で予め規定されたアプリケーション（ＩＦ－ＴＨＥＮ）ルール７０（図７と図１１を用いて後述）に従って指定される。そしてこのアプリケーション（ＩＦ－ＴＨＥＮ）ルール７０に従って指定された通知手段（選択肢）に対して必要な情報が、検知時動作指示部（アプリケーション（ＩＦ－ＴＨＥＮ）エンジン）９０から通信（送信）される。
【0053】
本システムのアプリケーション１００には検知情報送信部１５０の機能が内蔵されている。本システムのアプリケーション１００の実行に関する管理・監視・設定を行うクラウドサーバ２へ向けた必要な情報が適宜、検知情報送信部（の機能）１５０から送信される。
【0054】
検知ルール設定部（の機能）１４０で使用されるアプリケーション（ＩＦ－ＴＨＥＮ）ルール７０は、クラウドサーバ２から設定されてもよい。この場合にはアプリケーション（ＩＦ－ＴＨＥＮ）ルール７０の実行状況を複数個所で監視する必要があるため、クラウドサーバ２が必要となる。
【0055】
またそれに限らず、本システムのアプリケーション１００の表示画面からローカルに、アプリケーション（ＩＦ－ＴＨＥＮ）ルール７０を設定してもよい。その場合には、クラウドサーバ２が無くても本システムのアプリケーション１００の実行が可能となる。
【0056】
【0057】
本システムのアプリケーション１００の動作中は、図５に示す動作を繰り返す周期処理Ｓ０１が続けられる。ステップ０２（Ｓ０２）では始めに、通常カメラ８１６（第２の光センサ）が撮像した画像信号（映像または静止画像）が、第２の信号として通常カメラ画像認識部１１２（第２の画像認識部）に送信される。するとこの通常カメラ画像認識部１１２で“１〕画像認識”が行われ、“４〕頭部検出”の結果を利用した“３〕人数検出”と“頭部位置算出（４〕頭部検出の一部）”、“５〕検出”が実行される（ここまでＳ０２となる）。ここで“３〕人数検出”の結果として人物の人数が１以上で無い（すなわち通常カメラ８１６で得られた画像内に人物が含まれて無い）場合（Ｓ０３のＮｏ）には、ステップ０４（Ｓ０４）の処理終了に進む。
【0058】
一方で人物の人数が１以上の（通常カメラ８１６で得られた画像内に人物が含まれた）場合（Ｓ０３のＹｅｓ）には、人物頭部温度判定部（人物の体温判定部）１２５で人数分に相当する個々人頭部位置での温度情報を取得する（Ｓ０５）。これに先立ち赤外線画像認識部１１６（第１の画像認識部）では、赤外線カメラ８６０（赤外光にを有する第１の光センサ）から得られた温度特性信号（第１の信号）を利用して画面内の空間的温度分布特性を算出しておく。人物頭部温度判定部（人物の体温判定部）１２５ではこの画面内の空間的温度分布特性上に、通常カメラ画像認識部１１２（第２の画像認識部）から得られた個々人の頭部位置情報を重ねて、個々人の頭部温度（体温）を取得する。
【0059】
次にステップ０６（Ｓ０６）に示すように、人物頭部温度判定部（人物の体温判定部）１２５内部で個々人の頭部温度（体温）毎に所定値（例えば摂氏３７．５度）を超えるか否かの“設定温度判定”を行う。この設定温度判定の結果として体温が所定値を超えた人がいない場合には、ステップ０７（Ｓ０７）の処理終了に進む。
【0060】
図５の実施例では“設定温度判定”の判定値（所定値）として、“警報値”（例えば摂氏３７．５度）と“注意値”（例えば摂氏３７度）の２種類を設定する。ここで“警報値”の値は、“注意値”よりも高い値に設定する。
【0061】
ステップ０６（Ｓ０６）での判定結果が“警報値”以上の場合には、ステップ１０（Ｓ１０）に示す通知処理として警報を通知する。この具体的通知方法は、検知時動作指示部（アプリケーション（ＩＦ－ＴＨＥＮ）エンジン）９０で設定されたアプリケーション（ＩＦ－ＴＨＥＮ）ルール７０の規定に従い、検知時動作設定部１４０で“警報通知”に適した選択肢１２４０～１２９０を選択する。
【0062】
一方でステップ０６（Ｓ０６）での判定結果が“警報値”以下で“注意値”以上の場合には、前述した“５〕検出”の結果を加味して判定する。“５〕検出”結果の利用方法例として、『β〕赤外線カメラ８０６とのが一定の（設定値）より遠い人に対しては、判定温度より低い場合でも、検知時動作指示部（アプリケーション（ＩＦ－ＴＨＥＮ）エンジン）９０が注意を促す指示を出す』説明をした。
【0063】
赤外線カメラ８０６と測定対象者間のが広がると、測定結果（体温）が実際より低温となる（詳細は図１９を用いて後述）。従ってステップ０８（Ｓ０８）が示すように、測定対象者の頭部位置と赤外線カメラ８０６との間のが予め定めた設定値より遠いか否かの判定を行う。もしもこのが設定値より近い（Ｓ０８のＮｏ）場合には、『測定対象者体温の測定値精度が高い』と見なす。この場合には『高熱者は居ない』と判断され、処理終了（Ｓ０９）となる。
【0064】
一方で対応が設定値より遠い（Ｓ０８のＹｅｓ）場合には、『測定対象者体温の測定値精度が低い』と見なす。つまり『本来は測定対象者が高熱者で体温が“警報値”（摂氏３７．５度）を超えているにも関わらず、サーモグラフィの測定精度が悪いため正しい体温が測定できなかった』と推定する。そしてステップ１１（Ｓ１１）に示すように、“注意”の通知処理を行う。
【0065】
この場合も、検知時動作指示部（アプリケーション（ＩＦ－ＴＨＥＮ）エンジン）９０で設定されたアプリケーション（ＩＦ－ＴＨＥＮ）ルール７０の規定に従い、検知時動作設定部１４０が“注意通知”に適した選択肢１２４０～１２９０を操作する。
【0066】
図６は、高熱者検出装置に対応した図２のエッジコンピュータ６あるいはそれを含む高熱者検出システムの利用場面例（ユースケース）を示す。図６に示す高熱者検出システムでは、図２０で後述する構造を持った３眼赤外線カメラ８０６とスマートフォンなどのエッジコンピュータ６（高熱者検出装置）から構成される。そして両者は、接続部１０を介して接続されている。
【0067】
ここで、（電車などの）車両に乗車中や（食堂など）人が集まる場所で、スマートフォンを操作する人が多い。図６の上部では、車両内や人が集まる場所内で近くに人の集団が居た状況を示している。スマートフォン（エッジコンピュータ６）で他のアプリケーションプログラム２２を使用している状況を、図６の下部が示している。近くの集団の中に高熱者が居た場合には、その検出結果が表示画面１２上に画面表示１２３０される。
【0068】
検知時動作設定部１４０が制御する警告画面表示１２３０の例として、検出された高熱者が斜線で明記されている。またそれと同時に、『警告近くに高熱者が居ます！！御注意下さい！』の警告文も表示されている。
【0069】
図６に示す方法では他のアプリケーションプログラム２２使用時にユーザに自動通知されるため、通知の即時性とユーザへの利便性が大幅に向上する。
【0070】
なお図６に示した高熱者検出システムの利用場面例（ユースケース）では、エッジコンピュータ６の表示画面１２上に警告画面表示１２３０を行っている。それに限らず例えば、図１７で後述するＨＭＤ（Head Mounted Display）８１０上に警告画面表示１２３０を行ってもよい。
【0071】
図７を用いて、本実施形態の他の実施例を説明する。図７に示すシステム構成では、クラウドサーバ２とエッジコンピュータ６とが、互いに通信可能１８な構成となっている。またこのエッジコンピュータ６は、センサ８０２やサイネージ（電子掲示板）８０４、赤外線カメラ８０６、スマートフォンやタブレットなどの携帯端末８０８、ＨＭＤ（Head Mounted Display）８１０、ＩｏＴ機器（ゲート等）８２０などの各種デバイス８を制御して、ユーザに各種サービスを提供できる。これら各種デバイスが例えば温度センサ、圧力センサ、ジャイロや通常カメラ８１６などの各種センサの場合は、このエッジコンピュータ６に内蔵されてもよい。それに限らず、これら各種デバイスの一部はこのエッジコンピュータ６の外に配置され、通信で制御されてもよい。
【0072】
このエッジコンピュータ６の内部はアプリケーション（ＩＦ－ＴＨＥＮ）エンジン９０を持ち、予め記録された（クラウドサーバ２から事前にインストールされた）アプリケーション（ＩＦ－ＴＨＥＮ）ルール７０に応じた処理を行って（各種デバイス８を制御して）、ユーザにサービスを提供する。
【0073】
また図７に示すように、センサ８０２やサイネージ（電子掲示板）８０４、赤外線カメラ８０６、スマートフォンやタブレットなどの携帯端末８０８、ＨＭＤ（head mounted display）８１０、ＩｏＴ機器（ゲート等）８２０などの各種デバイス８を個々に制御するマイクロサービス８０Ａ～８０Ｆが、エッジコンピュータ６に予め組み込まれて（クラウドサーバ２から事前にインストールされて）いる。そしてこれらのマイクロサービス８０Ａ～８０Ｆをアプリケーション（ＩＦ－ＴＨＥＮ）エンジン９０が操作して、各種デバイス８間の連携制御を行う。この時には、アプリケーション（ＩＦ－ＴＨＥＮ）エンジン９０から操作したいマイクロサービス８０Ａ～８０Ｆに対してＡＰＩ（application program interface）コマンドが発行される。
【0074】
またそれに限らず本実施形態では、ＩｏＴサービスサーバ２２０と連携制御するＩｏＴサーバマイクロサービス８０Ｇやメールサーバ２３０と連携するメーラーマイクロサービス８０Ｈ、Ｗｅｂサービスサーバ２１０に対してアクセスしてＷｅｂサービスを得るためのＷｅｂマイクロサービス８０Ｉなどを所有（エッジコンピュータ６に予めインストール）してもよい。 このＷｅｂマイクロサービス８０Ｉの具体的制御例として、ＨＴＭＬ（Hyper Text Mark-Up Language）内に指定されたフォーム要素（Form Element）の枠内に必要な情報を自動で書き込む制御やＷｅｂページ間の遷移制御などを行ってもよい。このようにエッジコンピュータ６のソフトウェアアーキテクチャ内にＷｅｂマイクロサービス８０Ｉの領域を設置することで、Ｗｅｂサービスのような高度なサービスをユーザが享受できる。図７に示したＩｏＴサーバマイクロサービス８０Ｇやメーラーマイクロサービス８０Ｈに限らず、図示してないサイバ空間上で利用可能なあらゆるサービスに個々にアクセスできるマイクロサービス８０を、Ｗｅｂマイクロサービス８０Ｉと同列に配置してもよい。図７には図示してないサイバ空間上のサービス例として、証券（特定銘柄の株）の自動売買や特定商品の発注と受け取った商品代金の自動振り込み（課金処理）、映画や音楽の鑑賞券の購入申し込みや所定旅行などの予約申し込みなどのユーザサービスを行ってもよい。
【0075】
このようにサイバ空間上の各サービスに個々にアクセスできるマイクロサービス８０をエッジコンピュータ６のソフトウェアアーキテクチャ内に配置（予めインストール）可能にすると、サイバ空間上の異なるサービス間をつなげた連携サービスをユーザが享受できる。
【0076】
ところで従来は実空間内に存在する各種デバイス８を利用したサービスと上記サイバ空間上のサービス間の連携は、比較的希薄だった。図７のように各種デバイス８を制御するマイクロサービス８０Ａ～８０Ｆを、上記Ｗｅｂマイクロサービス８０Ｉと同列に配置可能にすることで、各種デバイス８を利用した実空間上あるいは物理空間上のサービスと上記サイバ空間上のサービスをシームレスに違和感なく跨った高度な連携サービスをユーザが享受可能となる。
【0077】
過去にアナログデータとして扱われていた映像や音声をデジタルデータで扱う技術が生まれた時に、“あらゆる媒体（メディア）がデジタルで統合的に扱える”機能を示す『マルチメディア』と言う言葉が流行となった。そして現在では、このようなデジタル世界が当然の世界となっている。
【0078】
実空間内に存在する物体（object and/or instance）やその状態（state）の検出や操作を担う各種デバイス８を個々に制御する専用の制御ソフト（マイクロサービス８０）を本実施例で新規に定義する事で、実空間内／物理空間内で提供できるサービスとサイバ空間上で提供できるサービスを組み合わせた（混在させた）より高度なサービスの提供が可能となる『マルチサービス』の世界が構築できる。そしてユーザに高度なサービスを提供するための“各種サービス間の組み合わせ方法”が、アプリケーション（ＩＦ－ＴＨＥＮ）ルール７０で規定される。
【0079】
この図７と前述した図２の関係を説明する。図２の通常カメラ８１６はセンサ８０２の一種に対応し、図２と図７の赤外線カメラ８０６は同一デバイス８を意味する。従って図２の通常カメラ画像認識部１１２は、センサマイクロサービス８０Ａに対応する。そして図２の赤外線認識部１１６と人物頭部温度判定部１２５が、赤外線カメラマイクロサービス８０Ｃに対応する。図２では通常カメラ画像認識部１１２で行われた画像認識の結果が人物頭部温度判定部１２５に転送されている。図７ではアプリケーション（ＩＦ－ＴＨＥＮ）エンジン９０を経由して、センサマイクロサービス８０Ａと赤外線カメラマイクロサービス８０Ｃ間の情報交換が行われる。
【0080】
また検知ルール設定部１３０の検知時動作指示部（アプリケーション（ＩＦ－ＴＨＥＮ）エンジン）９０が、図７に示したアプリケーション（ＩＦ－ＴＨＥＮ）エンジン９０に相当する。
【0081】
一方で図２のメール送信１２５０を制御する検知時動作設定部１４０の機能が、メーラーマイクロサービス８０Ｈで処理される。またＨＭＤ８１０の表示部上に画面表示１２３０を行う場合には、画面表示１２３０を制御する検知時動作設定部１４０の機能が、ＨＭＤマイクロサービス８０Ｅで処理される。
【0082】
そして例えば“検出された高熱者の通行を制限するための通過ゲート遮断”などの機器動作１２９０（１２７０）をする場合には、対応する検知時動作設定部１４０の機能が、個別機器マイクロサービス８０Ｆで処理される。
【0083】
個々のエッジコンピュータ６が使用するアプリケーション（ＩＦ－ＴＨＥＮ）ルール７０や各種デバイス８に関し、クラウドサーバ２が実行する機能としてルール設定・配信部（の機能）２０２やデバイス管理部（の機能）２０６を持つ。それに限らず、クラウドサーバ２がマイクロサービス登録部（の機能あるいはモジュール）２０４（［モジュール］に関する用語定義は後述する）としての機能を持っていてもよい。
【0084】
エッジコンピュータ６がアプリケーション（ＩＦ－ＴＨＥＮ）ルール７０に従ってユーザにサービス提供する時に得られる各種データは、クラウドサーバ２でデータ管理／蓄積２０８され、データ／情報記憶装置２００に適宜保存される。
【0085】
図８は、アンドロイド（登録商標）ベースのスマートフォンで使用されるプログラム構成例を示す。ｉｆＬｉｎｋ（登録商標）ウィジェット（widget）１１００で、ｉｆＬｉｎｋの状態を表示する。
【0086】
Ｊａｖａ（登録商標）言語で記述されたマイクロサービス８０Ａ～８０Ｆが、ｉｆＬｉｎｋアプリ１０００の下位領域に設置されている。このｉｆＬｉｎｋアプリ１０００の一部として、アプリケーション（ＩＦ－ＴＨＥＮ）エンジン９０が動作する。他にアプリケーション（ＩＦ－ＴＨＥＮ）ルール７０も、このｉｆＬｉｎｋアプリ１０００の中で使用される。すなわちこのｉｆＬｉｎｋアプリ１０００が、ｉｆＬｉｎｋにつながるマイクロサービス８０Ａ～８０Ｆやアプリケーション（ＩＦ－ＴＨＥＮ）ルール７０の管理をおこなう。
【0087】
図９を用いて、図７に示したエッジコンピュータ６の内部とクラウドサーバ２との関係について、詳細に説明する。エッジコンピュータ６には、サービス提供アプリケーションプログラムのｉｆＬｉｎｋアプリ９２が事前にインストールされている。このｉｆＬｉｎｋアプリ９２のソフトウェアアーキテクチャとして、アプリケーション（ＩＦ－ＴＨＥＮ）エンジン部９０、設定・管理画面構成部９８およびデータ送信部９６、ルール受信部９４が構成要素として存在する。またエッジコンピュータ６には、例えばＸＭＬ（Extensible Markup Language）形式で記述されたアプリケーション（ＩＦ－ＴＨＥＮ）ルール７０を保存するメモリ領域が存在する。そしてアプリケーション（ＩＦ－ＴＨＥＮ）エンジン部９０は、アプリケーション（ＩＦ－ＴＨＥＮ）ルール７０に従って対応するマイクロサービス８０を操作する。
【0088】
ここではｉｆＬｉｎｋアプリ９２を“ソフトウェアプログラム”として説明したがそれに限らず、“ハードウェア”でｉｆＬｉｎｋアプリ９２を構成してもよい。この場合には、アプリケーション（ＩＦ－ＴＨＥＮ）ルール７０を保存するメモリ領域と、アプリケーション（ＩＦ－ＴＨＥＮ）エンジン部９０、設定・管理画面構成部９８およびデータ送信部９６、ルール受信部９４がそれぞれ物理的に分離した電子回路で構成されてもよい。
【0089】
クラウドサーバ２のソフトウェアアーキテクチャは図９が示すように、マイクロサービス登録部２０４とルール設定・配信部２０２、データ収集サービス部（ＤＤＳ：Data Destination Service）２１６、エンドポイン管理部（ＥＰＭ：End Point Manager）２１４、Ｗｅｂ－ＡＰＩ制御部２１８、データ／情報記憶装置２００から構成される。
【0090】
そしてこのルール設定・配信部２０２で、ユーザ要求に合わせたアプリケーション（ＩＦ－ＴＨＥＮ）ルール７０の設定と、アプリケーション（ＩＦ－ＴＨＥＮ）ルール７０のユーザへの配信を管理する。
【0091】
ｉｆＬｉｎｋアプリで収集されたデータは、エッジコンピュータ６０のデータ送信部９６から通信経路１８を経由して、クラウドサーバ２のデータ収集サービス部（ＤＤＳ）２１６に転送される。そしてこのデータ収集サービス部（ＤＤＳ）２１６で整理されたデータは逐次、データ／情報記憶装置２００に保存される。
【0092】
またユーザ要求に合わせて設定されたアプリケーション（ＩＦ－ＴＨＥＮ）ルールもデータ／情報記憶装置２００に保存される。そして必要なタイミングでアプリケーション（ＩＦ－ＴＨＥＮ）ルール７０がデータ／情報記憶装置２００から読み出され、エンドポイント管理部（ＥＰＭ）２１４から通信経路１８を経由して、ｉｆＬｉｎｋアプリのルール受信部９４に配信される。そしてこのルール受信部９４が受信したアプリケーション（ＩＦ－ＴＨＥＮ）ルール７０は、（図示してないが）エッジコンピュータ６の記憶領域に保存される。また所定の機関で認証を受けて登録されたマイクロサービス８０も、エンドポイント管理部（ＥＰＭ）とルール受信部９４を経由してエッジコンピュータ６にインストールされる。
【0093】
一方でｉｆＬｉｎｋアプリから収集してデータ／情報記憶装置２００に保存された各種データは、Ｗｅｂ－ＡＰＩを介して各種アプリケーションサービス１８００の処理対象となる。このアプリケーションサービス１８００の具体的サービス内容として、〇ｉｆＬｉｎｋアプリから収集したデータの可視化１８０２〇ｉｆＬｉｎｋアプリから収集したデータの管理１８０４〇ｉｆＬｉｎｋアプリから収集したデータを用いたエッジコンピュータ６の状態と各種モジュール９の状態に関する状態監視と異常対応１８０６（モジュール９の説明は後述）〇ｉｆＬｉｎｋアプリから収集したデータの分析１８０８〇ｉｆＬｉｎｋアプリを用いたユーザへのサービス最適化１８１０およびモジュール９設定条件の最適化１８１０〇データの分析１８０８の結果得られた情報を用いた情報サービス１８１２などを行う。
【0094】
図１０には、図７および図９で示したアプリケーション（ＩＦ－ＴＨＥＮ）エンジン９０に実装される機能を示す。具体的機能として、アクティベーション９０２とルール管理制御９０４、ルール実行制御９０６、センサデータ制御９１０、ＪＯＢ制御９１２、ログ出力機能９１４、同一イベント無視時間の設定機能９１６、他のエッジコンピュータ６にまたがるＩＦ－ＴＨＥＮ機能９１８、ルール有効化・無効化機能９２０、実行時間制御機能９２２、中間データ保持オブジェクト機能９２４などがある。
【0095】
アクティベーション９０２では、アプリケーション（ＩＦ－ＴＨＥＮ）エンジン９０がｉｆＬｉｎｋアプリ９２から起動された際に、ｉｆＬｉｎｋアプリ９２との接続確立を行う。
【0096】
ルール管理制御９０４では、アプリケーション（ＩＦ－ＴＨＥＮ）エンジン９０起動時に予め保持しているアプリケーション（ＩＦ－ＴＨＥＮ）ルール７０を読み出し、内部状態を構築する。つまり、例えば実際のセンサ８０２からの検出出力あるいは命令の待ち状態（いくつかの選択肢を持つ準備状態）となる。
【0097】
ルール実行制御９０６では、ｉｆＬｉｎｋアプリ９２から通知されたセンサデータ情報を元に、内部状態に基づいて条件に一致するアプリケーション（ＩＦ－ＴＨＥＮ）ルール７０を抽出する。つまり検出出力の内容（命令内容）に応じたルールが選択される。
【0098】
センサデータ制御９１０では、ｉｆＬｉｎｋアプリ９２からのデバイス情報６８を受信し、アプリケーション（ＩＦ－ＴＨＥＮ）ルール７０に対応した実行制御を起動する。
【0099】
ＪＯＢ制御９１２では、必要なＪＯＢ情報をｉｆＬｉｎｋアプリ９２へ通知する。
【0100】
ログ出力機能９１４では、ログレベル（ログ内容の重要度或は細かさ）に応じてログ（例えばサービス履歴）を出力する。
【0101】
同一イベント無視時間の設定機能９１６とは、同様のセンサデータが入力されても、指定された時間の間は、発生を抑制する機能を意味する。
【0102】
他のエッジコンピュータ６にまたがるＩＦ－ＴＨＥＮ機能９１８では、ＪＯＢを別の特定のエッジコンピュータ６へ通知し、そこでＪＯＢを実行させる。
【0103】
ルール有効化・無効化機能９２０とは、アプリケーション（ＩＦ－ＴＨＥＮ）ルール７０で実行（ＴＨＥＮ）７８（図１１を用いて後述）に指定されたルールのＯＮ／ＯＦＦを切り替える機能を意味する。
【0104】
実行時間制御機能９２２とは、特定の実行（ＴＨＥＮ）７８タイミングをずらして、一定時間後に続きの実行（ＴＨＥＮ）７８（図１１を用いて後述）ができる機能を意味する。
【0105】
中間データ保持オブジェクト機能９２４とは、処理途中で発生する中間データを記憶装置に保持し、別のルールの条件（ＩＦ）７２（図１１を用いて後述）への入力を可能とする機能を意味する。
【0106】
図１１は、本実施形態における応用例概念を表現するブロック図である。本実施形態が提案する『マルチサービス』の世界では例えば、物理的現実世界で生じる実体や状態（あるいはそれらに関連する情報）７の変化検出結果とサイバ空間上のサービス（Ｗｅｂサービス２１０）が直接連携して、ユーザへのサービス提供が可能となる。
【0107】
つまり、図７では、デバイス８以外を活用したユーザへのサービス形態として、Ｗｅｂサービスサーバ２１０とメールサーバ２３０を明示的に示した。それに対してここでは、物理的な実空間内でユーザにサービスを提供する手段としての各種デバイス８（図７の８０２－８２０に相当）と、サイバ空間上でユーザにサービスを提供する手段（例えばＷｅｂサービスサーバ２１０が提供するＷｅｂ画面など）を総称して、“人間が認識可能な実体または状態、情報（instance, status, and/or information）７（７Ａ－７Ｆに相当）”と呼ぶ。また、前述したデバイス８は、“人間が認識可能な実体／状態／情報７”の一種に該当する。またこれらを個々に制御する汎用的手段を“制御手段４（４Ａ－４Ｆ）”と定義する。
【0108】
先にも述べたように、デバイス８以外を活用したユーザへのサービス形態として図７では、Ｗｅｂサービスサーバ２１０とメールサーバ２３０を明示的に示した。それに対してここでは、“人間が認識可能な実体または状態、情報（instance, status, and/or information）７（７Ａ－７Ｆ）”を新しく提唱した。前述したデバイス８は、“人間が認識可能な実体／状態／情報７”の一種に該当する。またこれらを個々に制御する汎用的手段を“制御手段４（４Ａ－４Ｆ）”と定義した。
【0109】
例えばＡＩ（Artificial Intelligence）プログラムを利用してＷｅｂ画面を制御（ＨＴＭＬ内指定のフォーム要素の枠内に必要情報を自動で書き込む制御やＷｅｂページ間の遷移制御など）する例や、Ｗｅｂ画面を利用した発注処理や契約処理、申し込み処理を行う例を考える。この場合には、Ｗｅｂ画面の情報（具体例として発注処理時や契約処理時、申し込み処理時に書き込むべきＷｅｂ画面上の“書式”）が“人間が認識可能な実体または状態、情報７”の一種に該当し、その情報を制御する（具体例としてＷｅｂ画面上の“書式”の必要項目に自動的に必要事項を記入し、ユーザの確認後にＷｅｂ画面上の“実行”ボタンを押す処理などを行う）ＡＩプログラムが制御手段４に該当する。
【0110】
他の例としてセンサ８０２を利用して収集したビッグデータがデータ／情報記憶装置２００に保存された後、統計解析ソフトを利用してデータ解析した場合を考える。この場合のセンサ８０２単体は、デバイス８に分類されるので“人間が認識可能な実体／状態／情報７”の一種に該当する。そしてこのセンサ８０２の動作を制御するセンサマイクロサービス８０Ａが、制御手段（マイクロサービス）４の一種になる。
【0111】
またさらにビッグデータ保存に利用されるデータ／情報記憶装置２００は、デバイス８に分類されるので“人間が認識可能な実体／状態／情報７”の一種に該当する。そしてこのデータ／情報記憶装置２００に保存されたビッグデータやデータ解析後に得られた情報も、“人間が認識可能な実体／状態／情報７”の一種に分類できる。それに比べて統計解析ソフトが行うデータ解析処理は、広義の“データ制御”に当てはまる。従ってこの統計解析ソフトは、制御手段（マイクロサービス）４の一種に該当する。
【0112】
ここで図１１に示す制御手段４の機能実現形態として、ハード構成（例えば論理回路の組み合わせ）で実現してもソフトプログラムで実現しても良い。例えばオブジェクト指向のプログラミング言語を用いたプログラム形態を取る制御手段４を特に、マイクロサービス８０と呼ぶ。ここで、オブジェクト指向でないプログラミング言語（例えばアセンブラなど）で作成されるマイクロサービスでもよいことは勿論である。
【0113】
デバイス８とサイバ空間上サービス提供手段を総称して（一般化して）“認識可能な実体／状態／情報７”と名付け、マイクロサービス８０を含む一般化された総称名を“制御手段４”と呼び、ユーザに対するあらゆるサービス形態に対して今後は汎用的に説明する。
【0114】
例えばセンサ８０２単体を“制御手段４”が制御して初めて、センシング機能が実現できる。このようにユーザに提供するサービスに関係して所定機能の実現手段を、“モジュール９（９Ａ－９Ｆ）”と呼ぶ。モジュール９は基本的に、“認識可能な実体／状態／情報７”と“制御手段４”から構成される。
このモジュール９の設置形態として、モジュールγ９Ｃ全体がエッジコンピュータ６に内蔵されてもよい。それに限らずモジュール９Ｄ、９Ｅの認識可能な実体／状態／情報７Ｄ、７Ｅのみがエッジコンピュータ６の外部に配置されても良い。この場合にはエッジコンピュータ６に配置された（事前にインストールされた）制御手段（マイクロサービス）４Ｄ、４Ｅと認識可能な実体／状態／情報７Ｄ、７Ｅ間が通信手段１８で信号的に接続されている。
このモジュール９の設置形態として、モジュールγ９Ｃ全体がエッジコンピュータ６に内蔵されてもよい。それに限らずモジュール９Ｄ、９Ｅの認識可能な実体／状態／情報７Ｄ、７Ｅのみがエッジコンピュータ６の外部に配置されても良い。この場合にはエッジコンピュータ６に配置された（事前にインストールされた）制御手段（マイクロサービス）４Ｄ、４Ｅと認識可能な実体／状態／情報７Ｄ、７Ｅ間が通信手段１８で信号的に接続されている。
【0115】
またエッジコンピュータ６に限らず、クラウドサーバα２Ａに制御手段（マイクロサービス）４Ａ、４Ｂが存在してもよい。
【0116】
ユーザに所定サービスを提供するために行われるモジュールγ９Ｃとモジュールδ９Ｄ間の連携方法を規定するアプリケーションルールβ７０Ｂは基本的に、条件（ＩＦ）β７２Ｂから実行（ＴＨＥＮ）β７８Ｂへ向けて時間的推移する基本ロジックで構成される。
【0117】
「暗くなったら照明を点灯させる」ロジック例（アプリケーションルールβ７０Ｂ）を用いて、この“条件（ＩＦ）β７２Ｂ⇒実行（ＴＨＥＮ）β７８Ｂ”ロジックとその具体的処理の内容を説明する。この場合には、条件（ＩＦ）β７２Ｂに対応した処理としてアプリケーション（ＩＦ－ＴＨＥＮ）エンジン９０から照度センサの制御手段（マイクロサービス）γ４Ｃに対してＡＰＩコマンド７５が発行される。それに対応して照度センサの制御手段（マイクロサービス）γ４Ｃは、認識可能な実体／状態／情報７の照度センサγ７Ｃを制御して周辺環境の照度を測定させる。得られた照度が事前設定値より低い場合には、照度センサの制御手段（マイクロサービス）γ４Ｃからアプリケーション（ＩＦ－ＴＨＥＮ）エンジン９０に対してＡＰＩコマンド７５の戻り値が返される。
【0118】
するとアプリケーション（ＩＦ－ＴＨＥＮ）エンジン９０は上記アプリケーションルールβ７０Ｂに従って、実行（ＴＨＥＮ）β７８Ｂの操作を開始する。このときは、アプリケーション（ＩＦ－ＴＨＥＮ）エンジン９０は、マイクロサービスから受け取った信号を、ＩＦ－ＴＨＥＮルールの解読内容に基づき、必要なマイクロサービスに指示を行う。つまり、アプリケーション（ＩＦ－ＴＨＥＮ）エンジン９０は自律的に処理を実行するのではなく、ＩＦで指定されたマイクロサービスから受け取ったデータを、ルールの条件に照らし合わせて、条件に合致したときに、ＴＨＥＮで指定されたマイクロサービスに実行指示をだす。
【0119】
するとアプリケーション（ＩＦ－ＴＨＥＮ）エンジン９０から照明点灯スイッチの制御手段（マイクロサービス）δ４Ｄに対して次のＡＰＩコマンド７５が発行される。そして照明点灯スイッチの制御手段（マイクロサービス）δ４Ｄが認識可能な実体／状態／情報７である照明点灯スイッチδ７Ｄを制御して、照明点灯スイッチを入れる。これにより、照明スイッチを制御する機能を持つモジュールδ９Ｄの機能が実行される。
【0120】
次にユーザが新たなモジュールε９Ｅ、ζ９Ｆを購入してシステム拡張した場合を説明する。このモジュールε９Ｅ、ζ９Ｆの制御手段（マイクロサービス）ε４Ｅ、ζ４Ｆとそれらを組み合わせたアプリケーションルールγ７０Ｃは、Ｗｅｂサーバのクラウドサーバβ２Ｂ内で生成される。その後にクラウドサーバβ２Ｂとエッジコンピュータ６とを接続する通信回線１８を経由してそれらがインストール１８０される。
【0121】
そしてインストール１８０された制御手段（マイクロサービス）ε４Ｅ、ζ４Ｆとアプリケーションルールγ７０Ｃは、それぞれファイルの形で（例えばマイクロサービスファイル２６０２やアプリケーションルールファイルとして）エッジコンピュータ６の所定記録領域に保存される。
【0122】
それと並行してクラウドサーバβ２Ｂでは、既存のアプリケーションルールβ７０Ｂと新規に作成するアプリケーションルールγ７０Ｃとを統合する統合ルール７００が生成される。そしてクラウドサーバβ２Ｂで、既存のアプリケーションルールβ７０Ｂと新規に作成するアプリケーションルールγ７０Ｃ間の整合性が検証される。その検証結果として何らかの不具合が発見された場合には、上記のインストール１８０の際またはユーザに対するサービス提供の際にユーザに通知される。
【0123】
クラウドサーバβ２Ｂは、多数のエッジコンピュータを相手にして、それぞれのエッジコンピュータのアプリケーションルールを検証することが可能である。エッジコンピュータとしては、工場、病院、学校、役所、農場、家庭などのエッジコンピュータがあり、それぞれの施設に適したアプリケーションルールが採用されている。
【0124】
上記説明で使用した用語も含めて、本特許明細書内で使用する用語を下記に定義する。
【0125】
●［モジュール（Module）９］－－所定機能の実現手段を意味し、この所定機能が実現された実空間上で人間が［認識可能な実体または状態、情報（instance, status, and/or information）７］とその［制御手段（controller）４］との組み合わせで構成される。本実施形態では基本的に、個々の［制御手段５］で制御される複数の［モジュール９］の操作（動作）の組み合わせで、ユーザに対するサービスが提供される。本実施形態内で説明する［モジュール９］とは、『所定機能を実現するための組み合わせ』の“概念”を示しているに過ぎない。したがって［モジュール９］を構成する［認識可能な実体または状態、情報７］とその［制御手段４］は、“物理的に一体化”されている必要は無い。例えば［認識可能な実体または状態、情報７］とその［制御手段４］が物理的に離れた位置に設置され、通信手段１８を利用して両者が連携してもよい。さらに後述するように、いずれも“物理的実体（Physically real object）”を形成している必要は無い。
【0126】
●［人間が認識可能な実体／状態／情報（instance, status, and/or information）７］－－実空間上での所定機能の実現対象（object）を意味する。ここで言う実現対象（object）の中に、温湿度や脈拍などの測定可能な［状態］も含まれる。本特許明細書では下記に記載するコンテンツ、データ／情報、処理と、デバイスなどの種類が、実空間上で認識可能な上記［実体または状態、情報（instance, status, and/or information）７］に含まれる。
【0127】
●［データ／情報（data and/or information）］－－取得データ／情報および提供用データ／情報のいずれもが含まれる。ここでセンサなどの［デバイス］で収集したデータが取得データの一種に該当し、この取得データを解析した結果得られた情報は、取得情報の一種に該当する。当然ながらこの［データ］の中には、温湿度や脈拍などの［状態］の測定結果も含まれる。また［サービス］としてユーザに提供されるデータや情報が提供用データ／情報に分類される。具体的一例として教育資料や教育教材などが、この提供用データ／情報に該当する。
【0128】
●［処理］－－所定機能の実現形態の具現化プロセスを意味し、電子機器の介在が前提条件となる。すなわち電子機器を用いたあらゆる具体的動作が含まれる。例えばスマートフォンやＷｅｂ画面を用いた発注処理や送金／振込処理、為替処理、（保険などの）契約処理、旅行や業務のスケジューリングおよび、旅行手配などの具体的動作が該当する。ところで例えば“申し込み用紙に手書きした書類を郵便ポストに入れる”などの人手の処理は電子機器が介在しないため、本明細書内で説明する［処理］には該当しない。
【0129】
●［デバイス８］－－実空間上に実在し、所定機能の実現に利用されるあらゆる電子機器が含まれる。従って上記［処理］を実行する電子機器や上記［コンテンツ］を表示する電子機器、上記［情報／データ］を格納する記憶装置も含まれる。この［デバイス８］は単体で、外部の電子機器との間の通信を行うための通信機能を内蔵しても良い。またこの［デバイス８］は、自然界の物理的（もしくは化学的）な状態や現象に対して作用する機能を持っても良い。自然界に対して受動的作用を行うデバイスには、センサなどが含まれる。また自然界に対して能動的に作用を行うデバイスには、ロボットや駆動機構、表示装置（表示素子）などが含まれる。この［デバイス８］の物理的形態として据え置き形に限らず、移動可能な携帯形の形態を取っても良い。例えばユーザの腕や足に固定するバンド形センサや腰に固定するベルト形センサ、または頭部に装着するＶＲ（virtual reality）タイプやＡＲ（augmented reality）タイプのＨＭＤ８１０などユーザが装着可能（wearable）な形態を取っても良い。
【0130】
●［制御手段（controller）４］－－所定機能を実現するため、［人間が認識可能な実体／状態／情報７］を制御する手段を意味する。この中に通信機能が内蔵され、通信手段を利用して［人間が認識可能な実体／状態／情報７］を制御しても良い。この［制御手段４］を用いた実施例として、Ｗｅｂ頁間の遷移制御やＷｅｂ頁内での必要箇所の自動入力制御、蓄積されたデータのデータ解析制御、物品の売買処理制御や自動旅行手配処理制御、ロボットの動き制御などが含まれる。また［人間が認識可能な実体／状態／情報７］が温湿度などのセンサに対する制御手段では、自然界の物理的（もしくは化学的）な［状態］を検出して数値化（データ化）する制御をおこなう。ここでこの制御手段の中では、個別詳細機能を実現するための詳細手順が規定される。例えば論理回路の組み合わせで制御ロジックが形成された“ハード形態”で詳細手順が規定されても良い。またそれに限らず、［エッジコンピュータ６］や［クラウドサーバ２］にインストール可能なプログラムのような“ソフト形態” で詳細手順が規定されても良い。
【0131】
●［マイクロサービス（Micro-service）８０／ＩＭＳ］－－オブジェクト指向のプログラミング言語を用いたプログラムで形成した［制御手段４］を意味する。このマイクロサービスの制御対象（object）は上述したようにデバイスに限らず、処理やコンテンツ、情報／データが含まれる。従って例えば、Ｗｅｂ頁間の遷移制御や特定Ｗｅｂ頁に対応した画面操作などの制御を行うためのＡＩ技術を用いたプログラムソフトも、マイクロサービスの一種あるいはその中の一部に含まれる。同様にＡＩ技術を用いて例えば特定の映像コンテンツ内に登場する人物の人数を自動抽出するプログラムソフトや、取得データを（例えば統計解析などを利用した）解析するプログラムソフトも、マイクロサービスの一種あるいはその中の一部に含まれる。ここで解析した結果得られた情報やその情報を保存する記録装置は、［人間が認識可能な実体／状態／情報７］として扱われる。また［マイクロサービス８０］は［制御手段４］の一形態なので、上述したように［マイクロサービス４］をインストールする事で、［エッジコンピュータ６］や［クラウドサーバ２］に拠る制御対象（人間が認識可能な実体／状態／情報７）の制御が可能となる。ここでこの“ソフト形態”で詳細手順を規定する場合、Ｊａｖａ（登録商標）言語やオブジェクティブＣ（Objective-C）言語などのオブジェクト指向のプログラミング言語を用いたプログラムで［制御手段４］を形成すると、既作成プログラム資産の有効活用（他プログラムでの組み込み（import）や呼び出し（ＡＰＩコマンド７５発行）など）が行える（詳細は第２章で後述）。さらにＯＳ（operating system）非依存のＪａｖａ言語でプログラムを記述すると、［制御手段４］としての汎用性が向上する。以降の説明内では、マイクロサービスの代わりにＩＭＳ（ifLink Micro-service）とも呼ぶ。
【0132】
●［制御用メソッド（Control Method）］－－［マイクロサービス８０］の一部を構成し、特定の個別詳細機能を実現するための詳細手順を規定したプログラムを意味する。個々の制御用メソッドが、個別詳細機能を実現する最小関数単位（すなわちサブプログラム）として扱われる。［アプリケーションエンジン９０］からのＡＰＩコマンド７５として、特定の個別詳細機能に対応した制御用メソッド名を対応関数（コマンド）として呼び出せる。それにより、［アプリケーションエンジン９０］で制御用メソッド名に対応した個別詳細機能を実行させることができる。本実施形態ではオブジェクト指向のプログラミング言語を用いて［制御用メソッド］のプログラムを記述（プログラム内容を規定）する事で、上記のように［アプリケーションルール７０］に［制御用メソッド］が連携できる。（具体例を上げた詳細説明は第２章で後述）
●［制御用クラス（Control Class）］－－個々の［制御用メソッド］の中で、共通類似機能毎に集めた集合体の塊を意味する。生成するインスタンス（実体）の初期設定機能に対応した制御用メソッドをコンストラクタ（Constructor）と呼ぶ。同一集合体に含まれるコンストラクタ名（コンストラクタに対応する制御用メソッド名）を、制御用クラス名と一致させても良い。前述した［マイクロサービス８０］の中で、共通する類似機能毎に制御用メソッドをまとめた管理単位が［制御用クラス］に相当する。従って同一使用目的の［マイクロサービス８０］に、複数の異なる［制御用クラス］が存在しても良い。
●［制御用クラス（Control Class）］－－個々の［制御用メソッド］の中で、共通類似機能毎に集めた集合体の塊を意味する。生成するインスタンス（実体）の初期設定機能に対応した制御用メソッドをコンストラクタ（Constructor）と呼ぶ。同一集合体に含まれるコンストラクタ名（コンストラクタに対応する制御用メソッド名）を、制御用クラス名と一致させても良い。前述した［マイクロサービス８０］の中で、共通する類似機能毎に制御用メソッドをまとめた管理単位が［制御用クラス］に相当する。従って同一使用目的の［マイクロサービス８０］に、複数の異なる［制御用クラス］が存在しても良い。
【0133】
●［制御用パッケージ（Control Package）］－－類似機能を持ったクラスの集合を示す。すなわち類似機能を持ったクラスの集まりをフォルダ単位に分けて管理する仕組みに従って定義される。本実施形態では特に、同一モジュール９に含まれる実体／状態／情報７毎に制御用パッケージを分け、それぞれ異なる制御用パッケージ名（制御用パッケージ毎の識別情報）を個々に設定する。従って個々に設定された制御用パッケージ名（制御用パッケージ毎の識別情報）を利用して、実体／状態／情報毎の内容の識別が可能となる。ここで実体／状態／情報に属する［デバイス］を制御するための［制御用パッケージ］の名前を設定する場合には、モジュール（あるいはデバイス）の製造または販売メーカの識別情報や、モジュール（あるいはデバイス）の種別情報、個々の製造番号などを制御用パッケージ毎の識別情報に利用（設定）しても良い。
【0134】
●［マイクロサービスファイル２６０２］－－クラウドサーバ２またはエッジコンピュータ６の記憶領域に［マイクロサービス８０］を保存するための保存単位（保存形態／保存形式）を示す。［マイクロサービス８０］が例えばＪａｖａ言語で記述する場合には、［マイクロサービス８０］の中身はＪａｖａ言語の記述文の繋がりとなっている。この情報を保存するには、（制御用クラス毎の処理内容も記述された）制御用クラス単位でファイルを構成する。そしてこの制御用クラスファイルの拡張子は「.class」となる。またクラウドサーバ２またはエッジコンピュータ６の記憶領域に、制御用パッケージ毎の「フォルダ」を配置し、その中に制御用クラスファイルを格納する。なおこのフォルダ名を制御用パッケージ名と一致させる。するとこのフォルダ名からモジュール（あるいはデバイス）の製造／販売メーカ識別情報やモジュール（あるいはデバイス）の種別情報が分かるので、必要な制御用クラスファイルの検索が容易となる。
【0135】
●［ＡＰＩ（ＡＰＩコマンド）７５］－－［アプリケーション（ＩＦ－ＴＨＥＮ）エンジン９０］から個々のマイクロサービス８０を操作するための、［アプリケーション（ＩＦ－ＴＨＥＮ）エンジン９０］と［マイクロサービス８０］との間のコミュニケーション手段（コミュニケーションツール）を示す。［マイクロサービス８０］はそれぞれ、制御用パッケージ／制御用クラス／制御用メソッドの階層構造を持つ。［ＡＰＩ（ＡＰＩコマンド）７５］では、個別詳細機能を実現するための詳細手順（プログラム）を示す特定の制御用メソッド名を指定し、制御用メソッド単位での個別詳細機能操作を行う場合が多い。例えばＪａｖａ言語で記述されたアプリケーションプログラム２２（後述する［ｉｆＬｉｎｋアプリ（サービス提供アプリケーションプログラム）］も含む）でこの特定の制御用メソッドの個別詳細機能を実行する方法例を説明する。このアプリケーションプログラム２２のクラス内で最初に、対応する制御用メソッドが入っている制御用パッケージの制御用クラスを組み込む（ｉｍｐｏｒｔ処理する）。そして上記クラス内またはメソッド内で対応する制御用メソッド名を指定することで、この個別詳細機能を実行できる。
●［アプリケーション（ＩＦ-ＴＨＥＮ）ルール７０］－－ユーザに所定サービスを提供する方法を示した、異なる複数の制御手段４（またはモジュール９）を組み合わせ方法（ルール）の規定情報を示す。［アプリケーション（ＩＦ-ＴＨＥＮ）ルール７０］が例えば論理回路の組み合わせで構成されるハードウェアで構成されている場合、この組み合わせ論理回路の出力端子が、［制御手段４］の論理回路の組み合わせで構成される制御ロジックの入力端子側に電気的に直接接続される。一方でこの［アプリケーション（ＩＦ-ＴＨＥＮ）ルール７０］が所定記述方法に則った記述形式（Ｗｅｂ画面を構成するＨＴＭＬも含む）で規定された場合には、クラウドサーバ２またはエッジコンピュータ６のアプリケーション（ＩＦ－ＴＨＥＮ）エンジン９０が上記［アプリケーション（ＩＦ-ＴＨＥＮ）ルール７０］の内容を解読する。そしてその解読結果に基づいて、アプリケーション（ＩＦ－ＴＨＥＮ）エンジン９０から該当するマイクロサービス８０に対してＡＰＩコマンド７５が発行され、マイクロサービス８０からの認識可能な実体／状態／情報７への制御が開始される。
●［アプリケーション（ＩＦ-ＴＨＥＮ）ルール７０］－－ユーザに所定サービスを提供する方法を示した、異なる複数の制御手段４（またはモジュール９）を組み合わせ方法（ルール）の規定情報を示す。［アプリケーション（ＩＦ-ＴＨＥＮ）ルール７０］が例えば論理回路の組み合わせで構成されるハードウェアで構成されている場合、この組み合わせ論理回路の出力端子が、［制御手段４］の論理回路の組み合わせで構成される制御ロジックの入力端子側に電気的に直接接続される。一方でこの［アプリケーション（ＩＦ-ＴＨＥＮ）ルール７０］が所定記述方法に則った記述形式（Ｗｅｂ画面を構成するＨＴＭＬも含む）で規定された場合には、クラウドサーバ２またはエッジコンピュータ６のアプリケーション（ＩＦ－ＴＨＥＮ）エンジン９０が上記［アプリケーション（ＩＦ-ＴＨＥＮ）ルール７０］の内容を解読する。そしてその解読結果に基づいて、アプリケーション（ＩＦ－ＴＨＥＮ）エンジン９０から該当するマイクロサービス８０に対してＡＰＩコマンド７５が発行され、マイクロサービス８０からの認識可能な実体／状態／情報７への制御が開始される。
【0136】
●［統合ルール７００］－－同一のエッジコンピュータ６または同一のｉｆＬｉｎｋアプリに複数の異なる［アプリケーション（ＩＦ-ＴＨＥＮ）ルール７０］が規定された時に生成される。この［統合ルール７００］の生成目的は、複数の異なる［アプリケーション（ＩＦ-ＴＨＥＮ）ルール７０］が組み合わされた場合に発生し得る矛盾や不具合を事前に発見し、ユーザへのサービス提供時のトラブル回避にある。ユーザが複数の異なる［アプリケーション（ＩＦ-ＴＨＥＮ）ルール７０］の規定を希望した場合、最初にクラウドサーバ２で［統合ルール７００］が生成され、クラウドサーバ２でこの［統合ルール７００］に沿った操作がシミュレーションされる。このシミュレーション結果で矛盾や不具合が発生した場合には、ユーザに通知して善処を提案する。シミュレーション結果で矛盾や不具合が起きない事が確認された後、この統合ルール７００がクラウドサーバ２からエッジコンピュータ６にインストール１８０される。このインストール１８０後は、エッジコンピュータ６ではこの［統合ルール７００］に従って各種マイクロサービス８０（制御手段４）の操作が行われる。
【0137】
●［エッジコンピュータ６］－－［アプリケーション（ＩＦ-ＴＨＥＮ）エンジン９０］を持ち、［アプリケーション（ＩＦ-ＴＨＥＮ）ルール７０］とそれに対応したユーザへのサービス提供に必要な各種［マイクロサービス８０］が予め記憶されている。ユーザが［プレイス１］から所定のサービス提供を受けたい場合には、［プレイス１］へのユーザからの要求に基づき、［アプリケーション（ＩＦ-ＴＨＥＮ）ルール７０］とそれに対応した［マイクロサービス８０］がクラウドサーバβ２Ｂから事前にインストールされる。［エッジコンピュータ６］は、プロセッサとメモリ部、通信部から構成される。ここでインストールされた［アプリケーション（ＩＦ-ＴＨＥＮ）ルール７０］とそれに対応した［マイクロサービス８０］は、メモリ部に格納される。またこの［アプリケーション（ＩＦ-ＴＨＥＮ）ルール７０］に従って［アプリケーション（ＩＦ-ＴＨＥＮ）エンジン９０］の機能を、上記プロセッサが担う。このようにプロセッサとメモリ部、通信部から構成される限り、［エッジコンピュータ６］として任意の形態を取れる。具体的な形態例として、パーソナルコンピュータやスマートフォン、タブレット、サイネージ、ゲートウェイ、ルータなどが［エッジコンピュータ６］として機能してもよい。
【0138】
●［ｉｆＬｉｎｋアプリ（サービス提供アプリケーションプログラム）９２］－－ユーザ１７００に所定サービスを提供するために、クラウドサーバα２Ａまたはエッジコンピュータ６で処理されるプログラムを意味する。そしてこれは、［アプリケーション（ＩＦ-ＴＨＥＮ）ルール７０］の内容に沿った処理を実行する［アプリケーション（ＩＦ-ＴＨＥＮ）エンジン９０］と、設定・管理画面部９８、クラウドサーバ２間の通信に関与するデータ送信９６とルール受信部９４から構成される。またこの［ｉｆＬｉｎｋアプリ（サービス提供アプリケーションプログラム）９２］では、予め保存された所定の［アプリケーション（ＩＦ-ＴＨＥＮ）ルール７０］の内容を最初に参照するようにプログラムされている。そしてクラウドサーバα２Ａまたはエッジコンピュータ６の［アプリケーション（ＩＦ-ＴＨＥＮ）エンジン９０］が、この［ｉｆＬｉｎｋアプリ（サービス提供アプリケーションプログラム）９２］内でプログラムされた内容に沿った処理を実行し、ユーザ１７００に所定サービスを提供する。
【0139】
●［アプリケーション（ＩＦ-ＴＨＥＮ）エンジン９０］－－クラウドサーバα２Ａまたはエッジコンピュータ６に内蔵され、クラウドサーバα２Ａまたはエッジコンピュータ６内での処理／実行を行う場所（機能）を意味する。ハード的には、演算処理プロセッサ（あるいはその処理状態）を対応させてもよい。この［アプリケーション（ＩＦ-ＴＨＥＮ）エンジン９０］は［アプリケーション（ＩＦ-ＴＨＥＮ）ルール７０］を読み込み、その内容を解読する。そしてその解読内容を参照し、［ｉｆＬｉｎｋアプリ（サービス提供アプリケーションプログラム）９２］でプログラムされた内容に沿った処理を実行する。その処理／実行の途中で、必要な［ＡＰＩコマンド７５］をマイクロサービス８０に発行する。この［アプリケーション（ＩＦ-ＴＨＥＮ）エンジン９０］の内部は、［アプリケーション（ＩＦ-ＴＨＥＮ）ルール７０］が記述された記述形式（対応するプログラミング言語）に応じたプログラミング言語解釈エンジンと、その解釈結果を参照しながら［ｉｆＬｉｎｋアプリ（サービス提供アプリケーションプログラム）］で規定されたプログラムに沿った処理を実行する制御エンジンから構成される。［アプリケーション（ＩＦ-ＴＨＥＮ）ルール７０］がＨＴＭＬで記述（表現）された場合に対応して、Ｗｅｂブラウザ機能が内蔵されてもよい。
【0140】
●［クラウドサーバ２］－－［アプリケーション（ＩＦ-ＴＨＥＮ）エンジン９０］を持ち、［アプリケーション（ＩＦ-ＴＨＥＮ）ルール７０］とそれに対応したユーザへのサービス提供に必要な各種［マイクロサービス８０］が予め記憶されている。ユーザが［プレイス１］から所定のサービス提供を受けたい場合には、［プレイス１］へのユーザからの要求に基づき、［アプリケーション（ＩＦ-ＴＨＥＮ）ルール７０］とそれに対応した［マイクロサービス８０］をエッジコンピュータ６に送信する。この送信方法の一例としてＨＴＭＬ内でＵＲＬを指定するリンク機能（Anchor Element）を利用する場合には、この［クラウドサーバ２］としてＷｅｂサーバ機能を有してもよい。
【0141】
●［サービス］－－所定の［実体／状態／情報７］の制御を組み合わせて、有償または無償でユーザに対して所定の［処理］や［状態］の変化、あるいは［コンテンツ］や［データ／情報］を提供する能動的動作を意味する。本実施形態では［アプリケーション（ＩＦ-ＴＨＥＮ）ルール７０］に従って、ユーザに［サービス］を提供する。この［サービス］提供の形態として本実施形態では、各種デバイス８を利用した実空間上あるいは物理空間上のサービスとＷｅｂサービスなどを利用したサイバ空間上のサービス間の垣根を越えた（跨った）組み合わせ（複合化）サービスを提供してもよい。
【0142】
図１１で説明した本実施形態における応用例概念を下記にまとめて記述する。すなわちモジュール９は、人間が認識可能な実体または状態／情報７と、それを制御する制御手段４から構成される。そしてこのモジュール９は複数定義できる。すなわち第１のモジュールγ９Ｃに関する第１の制御手段γ４Ｃと第２のモジュールδ９Ｄに関する第２の制御手段δ４Ｄが個々に定義される。
【0143】
ここでこの第１のモジュールγ９Ｃと前記第２のモジュールδ９Ｄの組み合わせでユーザにサービスを提供するためのアプリケーションルール７０が設定される。そしてこのアプリケーションルール７０の内容に従ってアプリケーション（ＩＦ－ＴＨＥＮ）エンジン９０から第１の制御手段γ４Ｃと第２の制御手段δ４Ｄに対して個々にＡＰＩコマンド７５が発行されて、第１または第２の制御手段γ４Ｃ、δ４Ｄを操作する。本実施形態におけるモジュール制御方法を利用する。
【0144】
上述した制御手段４の中にマイクロサービス８０が含まれる。そしてこのマイクロサービス８０は、オブジェクト指向のプログラミング言語を用いたプログラムで形成（記述）してもよい。（但しそれに限らず、マイクロサービス８０を任意のプログラミング言語で記述してもよい。）ここで人間が認識可能な第１の実体または状態、情報γ７Ｃを制御する第１のマイクロサービス８０（制御手段γ４Ｃ）と、人間が認識可能な第２の実体または状態、情報δ７Ｄを制御する第２のマイクロサービス８０（制御手段δ４Ｄ）が定義される。そしてこの第１のマイクロサービス８０と前記第２のマイクロサービス８０の組み合わせでユーザにサービスを提供するためのアプリケーションルールβ７０Ｂが設定される。そしてアプリケーションルールβ７０Ｂに従ってアプリケーション（ＩＦ－ＴＨＥＮ）エンジン９０から発行されるＡＰＩコマンド７５に対応して、これら第１／第２のマイクロサービス８０が認識可能な第１の実体または状態、情報γ７Ｃ、δ７Ｄを個々に制御する。
【0145】
また本実施形態（の応用例）におけるエッジコンピュータ６では、アプリケーションルールγ７０Ｃ（および統合ルール７００）とマイクロサービス８０（制御手段４Ｆ）をクラウドサーバβ２Ｂから受信し、事前にインストール１８０しておく。その結果として、人間が認識可能な第１の実体または状態、情報ε７Ｅを制御する第１のマイクロサービス８０（制御手段ε４Ｅ）と、人間が認識可能な第２の実体または状態、情報ζ７Ｆを制御する第２のマイクロサービス８０（制御手段ζ４Ｆ）、それに関係するアプリケーションルールγ７０Ｃ（および統合ルール７００）が、予めエッジコンピュータ６に内蔵されている。ここで上記アプリケーションルールγ７０Ｃ（および統合ルール７００）は、第１のマイクロサービス８０（制御手段ε４Ｅ）と第２のマイクロサービス８０（制御手段ζ４Ｆ）の組み合わせでユーザにサービスを提供するためのルールが規定されている。そして上記エッジコンピュータ６で第１のマイクロサービス８０（制御手段ε４Ｅ）と第２のマイクロサービス８０（制御手段ζ４Ｆ）を操作して、人間が認識可能な第２の実体または状態、情報ζ７Ｆまたは人間が認識可能な第２の実体または状態、情報ζ７Ｆを個別に制御して、ユーザに対してサービスを提供する。
【0146】
特に本実施形態（の応用例）におけるエッジコンピュータ６では、アプリケーション（ＩＦ－ＴＨＥＮ）エンジン９０を所有する。そして上記アプリケーションルールγ７０Ｃ（および統合ルール７００）で規定されたルールに従って、アプリケーション（ＩＦ－ＴＨＥＮ）エンジン９０からＡＰＩコマンド７５を第１のマイクロサービス８０（制御手段ε４Ｅ）と第２のマイクロサービス８０（制御手段ζ４Ｆ）に発行する。その結果として、第１または第２のマイクロサービス８０（制御手段ε４Ｅ、ζ４Ｆ）が認識可能な実体または状態、情報ε７Ｅ、ζ７Ｆを個々に制御して、ユーザへのサービスを提供する。そして本実施形態（の応用例）におけるサービス提供方法では、上述した方法を用いてユーザへのサービスを提供する。
【0147】
本実施形態（の応用例）では上述したように、マイクロサービス８０の内容をＪａｖａ言語などのＯＳ非依存プログラミング言語で記述できる。
【0148】
図１２を用いて、その効果を説明する。ＯＳ非依存の汎用プログラミング言語のＪａｖａ言語の場合、個々のＯＳ層α３０Ａ、β３０Ｂに対応した翻訳領域α１３００Ａ、β１３００Ｂ（Virtual Machine）が予め準備されている。そしてＪａｖａ言語で記述されたマイクロサービス８０の内容が、翻訳領域α１３００Ａ、β１３００Ｂ（Virtual Machine）を経由して翻訳され、個々のＯＳα３０Ａ、β３０Ｂに渡される。
【0149】
特に本実施形態におけるマイクロサービス８０のコマンドは、ＯＳ層α３０Ａ、β３０Ｂレベルの基本的ＡＰＩコマンド７５の組み合わせで記述される。その結果として、各デバイスの基本的制御を詳細に行える効果が生まれる。
図１３に、マイクロサービス８０のクラス構成（ソフトウェアアーキテクチャ）を示す。なお、この章ではマイクロサービス８０を中心に説明するがそれに限らず、広義な制御手段４にも下記に説明する内容は適用できる。
図１３に、マイクロサービス８０のクラス構成（ソフトウェアアーキテクチャ）を示す。なお、この章ではマイクロサービス８０を中心に説明するがそれに限らず、広義な制御手段４にも下記に説明する内容は適用できる。
【0150】
マイクロサービス８０に要求される基本機能として、『対応する個々のデバイス８の制御機能』が必須条件となる。しかしそれに限らず、『個々のデバイス８の制御に関係した周辺機能』も、マイクロサービス８０の機能として要求される。その具体例として例えば、アプリケーション（ＩＦ－ＴＨＥＮ）エンジンとのインターフェース処理を行ったり、対応するデバイス８が動作可能な状態か否かの確認なども必要となる。
【0151】
本実施形態ではマイクロサービス８０を上記とは異なる機能別に異なるクラスに分離し、マイクロサービス８０の機能拡張性を向上させている。つまり『対応する個々のデバイス８の制御機能』を実行するために、個別デバイス制御クラス（Custom Device Class）２１０２を設定する。そして対応するデバイス８の個別詳細機能毎の詳細手順プログラム内容が記述された複数のメソッドを、この中に配置（記述）する。
【0152】
一方で『個々のデバイス８の制御に関係した周辺機能』を実行させるプログラムとして、個別デバイス対応マイクロサービス内制御クラス（Customims Class）２１１０を設置する。
【0153】
ここで上記の個別デバイス対応マイクロサービス内制御クラス（Customims Class）２１１０の中から、個別デバイス制御クラス（Custom Device Class）２１０２の個別の制御メソッドを呼び出して（組み込んで）７６実行可能にしている。具体的には個別デバイス対応マイクロサービス内制御クラス（Customims Class）２１１０の前にインポート文を用いてimport [個別デバイス制御用パッケージ名].[個別デバイス制御クラス名（Custom Device）];を指定すると、個別デバイス対応マイクロサービス内制御クラス（Customims Class）２１１０で個別デバイス制御クラス２１０２内個別制御クラスの組み込み７６が可能となる。そして個別デバイス対応マイクロサービス内制御クラス（Customims Class）２１１０またはその中の特定制御クラスで、個別デバイス制御クラス２１０２内個別制御メソッド名と引数、戻り値の形式（タイプ）を記述する。これにより、個別デバイス対応マイクロサービス内制御クラス（Customims Class）２１１０またはその中の特定制御クラス内で、個別デバイス制御クラス２１０２内個別制御メソッドの呼び出し／使用７６が可能となる。
【0154】
本実施形態では、制御するデバイス８個々の特性に合わせた最適なデータＥ６０をデバイス８に送信できる。それを可能にするため本実施形態では、異なる製造／販売メーカとデバイス機種毎に異なる個別デバイス制御用パッケージ２１００の設定を可能にしている。
【0155】
一方でユーザに納入したシステム間の互換性や将来の拡張性を保証する必要がある。このようなシステム間の互換性や将来の拡張性を確保するため、クラス毎の記述内容（プログラム）の基準となるテンプレートクラスを提供してもよい。すなわち個別デバイス制御クラス（Custom Device Class）２１０２に対しては、デバイス制御テンプレートクラス（Base Device Class）２００２をテンプレートクラスとして任意のプログラマに提供する。また個別デバイス対応マイクロサービス内制御クラス（Customims Class）２１１０に対しては、マイクロサービス内制御テンプレートクラス（BaseIms Class）２０１０をテンプレートクラスとして任意のプログラマに提供する。
【0156】
新たなマイクロサービス８０をプログラミングしようとするプログラマは上記テンプレート内容の小修正（カスタマイズ）７４のみで個別デバイス制御クラス（Custom Device Class）２１０２と個別デバイス対応マイクロサービス内制御クラス（Customims Class）２１１０が作成できるので、新たなマイクロサービス８０の作成を行うプログラマは短期間で効率良くマイクロサービス８０を作成できる効果がある。
【0157】
そして各クラスが元のテンプレートクラスを機能継承（Extends）７４している事を示すため、個別に作成した各クラス名を定義する場所で例えばpublic class Custom Device extends Base Device { と記述すると、クラス間の機能継承（Extends）７４の関係が明記される。このような記述方法を利用することで、個別のマイクロサービス８０の管理が容易になるばかりでなく、システム間の互換性と拡張性が確保し易くなる。
【0158】
ところで上記の“public”は、「 Custom Device Class の他システムでの使用（転用）を許可する」と言う意味を持つ。この場所に“public”の代わりに“private”と記載すると、自分自身のクラス（上記の例では、Custom Device Class）以外の使用が禁止される。また“protected”と記述すると、パッケージのクラスと機能継承７４したクラスのみで使用可能となる。多くのプログラマがマイクロサービス８０の作成（修正）に関わると、意図しない改ざんなどトラブルが発生し易い。上記のようにルール化する事で、複数のプログラマ間でのトラブル発生頻度が減る効果がある。
【0159】
図１３が示すように、アプリケーション（ＩＦ－ＴＨＥＮ）エンジン９０からのＡＰＩコマンド（連携指定）７５は、マイクロサービス内制御テンプレートクラス（BaseIms Class）２０１０で処理する。
【0160】
またユーザ１７００へ所定サービスを提供している途中で例えば、デバイス８の電池切れなど異常事態が発生する可能性がある。この緊急で発生する異常事態に対処する機能を持った異常検知クラス（Health Check Task Class）２０１６を配置し、異常事態への迅速対処を可能にしている。この異常検知クラス（Health Check Task Class）２０１６は、マイクロサービス内制御テンプレートクラス（BaseIms Class）２０１０から呼び出し／組み込み処理７６される。ここでの呼び出し／組み込み処理７６は、上述した同じ方法で処理される。
【0161】
特に本実施形態では、画像認識などのＡＩ処理が必要となる。そのため基本制御用パッケージ２０００に、ＡＩ技術を用いた画像認識処理を専門に行うＡＩを用いた画像認識クラス（AI Analyze Class）２０１８を配置している。
【0162】
図２の通常カメラ画像認識部１１２（図７ではセンサマイクロサービス８０Ａが対応）で１〕画像信号の画像認識（画像解析）を行い、２〕画面内に人が居るかどうかを判別（人物検出）し、３〕画面内に人が居る場合には、その人数を算出（人数検出）し、４〕画面内に人が居る場合に限り、その人数それぞれの頭部の位置を認識（頭部検出）し、５〕画面内判別された人毎に、その人と赤外線カメラ８０６とのの計算（検出）する一連の画像認識処理が行われる説明をした。そしてそれに対応してＡＩを用いた画像認識クラス（AI Analyze Class）２０１８で、上記〔１〕～〔５〕の個別処理を行う個々のメソッドがそれぞれ配置（プログラム記述）されている。
【0163】
そして各メソッドに対応したＡＰＩコマンドを用いて、マイクロサービス内制御テンプレートクラス（BaseIms Class）２０１０または個別デバイス対応マイクロサービス内制御クラス（Customins Class）２１１０内ら個別に対応する各メソッドを呼び出して７６処理される。ここで図５に示したフロー手順に従って順次、対応する各メソッドを呼び出す７６。
【0164】
図２の通常カメラ画像認識部１１２で行う“２〕人物検出”に関する画像認識処理では、利用シーンに応じた柔軟な処理が要求されることを既に説明した。例えば受付カウンタを訪れた来客数は同時に数名以下の場合が多いので、比較的容易に人物の個別識別が容易となる。しかし受付カウンタ奥に設置された通常カメラ８１６では、来客者の上半身しか撮影できない。
【0165】
また通常カメラ８１６で通路を撮影する場合には全身撮影が可能な反面、動いている人を認識する必要がある。つまり通路での高熱者検出には、高速性が要請される。一方で４０人程度の生徒が集まった教室内で高熱者を検出する場合には、大勢の人の体温を同時測定する必要がある。
【0166】
このように“受付カウンタ”や“通路内”、“教室内”などの利用シーンに応じた最適な人物検出ロジック（画像認識アルゴリズム）に個々に対応した複数のＡＩを用いた画像認識クラス（AI Analyze Class）２０１８を同一の基本制御用パッケージ２０００内に同時配置してもよい。（但しこの場合には、クラス毎にクラス名が変わる。）そしてマイクロサービス内制御テンプレートクラス（BaseIms Class）２０１０または個別デバイス対応マイクロサービス内制御クラス（Customims Class）２１１０からは、対応するクラス名を指定すると共にその中に個別に配置（記述）された各メソッドを呼び出して７６処理される。
【0167】
またそれに限らず、ＡＩを用いた画像認識クラス（AI Analyze Class）２０１８に“受付カウンタ”や“通路内”、“教室内”などの利用シーンに応じて上記〔１〕～〔５〕の個別処理を行う個々のメソッドを全て配置（プログラム記述）してもよい。
【0168】
このように同一の基本制御用パッケージ２０００にＡＩを用いた画像認識クラス（AI Analyze Class）２０１８を配置すると、マイクロサービス８０での対応する各クラスを呼び出し７６／活用が可能となる。それにより異なる利用シーン毎に最適な人物検出ロジックが選択できるので、柔軟で高精度な画像認識やＡＩ処理が可能となる。
【0169】
同一マイクロサービス８０の画像認識（あるいはＡＩ処理に利用される）に使用されるデータ移動の方法を説明する。図２で示したデータのブロック間移動と、同一マイクロサービス８０内データのメソッド間移動は実質的に同義語を意味する。例えば図２では、通常カメラ画像識別部１１２のブロック内での画像認識結果が、人物頭部温度判定部１２５のブロック内に移動する。
【0170】
図１３のデバイス制御テンプレートクラス（Base Device Class）２００２あるいは個別デバイス制御クラス（Custom Device Class）２１０２で取得したセンサ８０２の検出データは、ＡＩを用いた画像認識クラス（AI Analyze Class）２０１８の対応するメソッド内で利用される。この時のデータ移動に関しては、マイクロサービス内制御テンプレートクラス（BaseIms Class）２０１０または個別デバイス対応マイクロサービス内制御クラス（Customins Class）２１１０の所定プログラムが制御と管理を行う。
【0171】
またそれに限らずデバイス制御テンプレートクラス（Base Device Class）２００２あるいは個別デバイス制御クラス（Custom Device Class）２１０２で取得したセンサ８０２の検出データを、一時的に（ストリームデータ一時保存用の）バッファメモリ２００８に保存してもよい。そしてＡＩを用いた画像認識クラス（AI Analyze Class）２０１８の対応するメソッドが、そこから必要なデータを読み出して利用してもよい。
【0172】
図１３ではＡＩ処理の一例として、専門の画像認識を行う画像認識クラス（AI Analyze Class）２０１８（データ解析処理プログラム）を配置した。しかしそれに限らず、例えばデータ制御機能やデータ操作機能、（インターネットを利用した）自動データ収集機能などあらゆる人工知能技術を利用した特定機能に特化した任意のＡＩクラス（ＡＩプログラム）を基本制御用パッケージ２０００に配置してもよい。
【0173】
このように基本制御用パッケージ２０００にデータ解析を専門に行うＡＩクラスを設けると、マイクロサービス８０の内部で高度なデータ解析処理が実行可能となる。それによりマイクロサービス８０の内部で処理したデータ解析結果のみをアプリケーション（ＩＦ－ＴＨＥＮ）エンジン９０を渡すことができるので、アプリケーション（ＩＦ－ＴＨＥＮ）エンジン９０の処理負担を大幅に軽減できる効果が生まれる。さらに人工知能技術を利用した特定機能に特化したＡＩクラス（ＡＩプログラム）を基本制御用パッケージ２０００に任意に配置できるので、マイクロサービス８０の中で人工知能技術を利用した高度な処理が任意に可能となる。
【0174】
クラウドサーバ２またはエッジコンピュータ６の外部にデバイス８が設置された場合には、マイクロサービス８０は通信回線１８を経由してデバイス８を制御する。ここで例えば通信回線１８が混雑したり断線した場合には、デバイス８からの応答が戻るまでシステムがフリーズする危険性がある。
【0175】
これに対して応答時間監視クラス（Timeout Check Task Class）２００６を設置すると、マイクロサービス８０とデバイス８間の通信状況を監視できる。そして通信の不具合を察知して迅速な対応を取る事で、システム内のフリーズ状況を防止できる。
【0176】
またセンサデバイス８０２の種別に拠っては、バイナリデータ（“１”か“０”の２値データ）から映像ストリームに至る多様なデータを扱う必要がある。ここでストリーム制御エンジンクラス（Stm Engine Class）２００４を設ける事で、効率良く多様なデータを統合的に扱える効果が生まれる。なおこのストリーム制御エンジンクラス（Stm Engine Class）２００４内部あるいはこれと同列位置にＡＩ技術を用いたストリーム解析クラス／メソッドを配置してもよい。すなわち上述したように、インポート文を用いてＡＩ技術を用いたストリーム解析クラスをストリーム制御エンジンクラス（Stm Engine Class）２００４あるいはデバイス制御用テンプレートクラス（Base Device Class）２００２（ストリーム制御エンジンクラス（Stm Engine Class）２００４と同列位置に配置する場合）に組み込む。それに拠りストリーム制御エンジンクラス（Stm Engine Class）２００４またはデバイス制御用テンプレートクラス（Base Device Class）２００２で、ＡＩ技術を用いたストリーム解析クラス内の／メソッドの使用（呼び出し）が可能となる。
【0177】
これによりセンサデバイス８０２から得られた生のストリームデータをアプリケーション（ＩＦ－ＴＨＥＮ）エンジン９０に渡すだけでなく、ストリームデータを自動で解析した結果得られた解析結果情報のみをアプリケーション（ＩＦ－ＴＨＥＮ）エンジン９０に渡すことが可能となり、アプリケーション（ＩＦ－ＴＨＥＮ）エンジン９０の処理負荷を大幅に改善できる効果が生まれる。なおこの場合にはエッジコンピュータ６またはクラウドサーバ２内のデータ／情報記憶装置２に、センサデバイス８０２から得られた生のストリームデータを時系列ファイルとして順次保存してもよい。そしてＡＩ技術を用いたストリーム解析クラスのメソッドは、適時時系列ファイル（生のストリームデータファイル）を再生する。そしてＡＩ技術を用いたデータ解析で得られた解析情報を用いて特定の条件（ＩＦ）β判定を行ってもよい。
【0178】
図１３に示すようにデバイス制御テンプレートクラス（Base Device Class）から、上述した応答時間監視クラス（TimeoutCheckTask Class）２００６とストリーム制御エンジンクラス（StmEngine Class）２００４の呼び出し／組み込み７６が行える。この呼び出し／組み込み７６処理の具体的方法は、上述した同じ方法が採用される。
【0179】
本実施形態において（Ｊａｖａ言語などの）オブジェクト指向のプログラミング言語を用いてマイクロサービス８０を記述すると、基本制御用パッケージ２０００の既存のプログラム資産を個別デバイス制御用パッケージ２１００で有効利用できる効果が生まれる。するとプログラマのマイクロサービス８０開発効率が大幅に向上する。
【0180】
例えば個別デバイス対応マイクロサービス内制御クラス（Customins Class）２１１０と個別デバイス制御クラス（Custom Device Class）の前にインポート文を用いてimport [基本制御用パッケージ２０００の名前].[異常検出クラス名（HealthCheckTask）]; と、import [基本制御用パッケージ２０００の名前].[応答時間監視クラス名（TimeoutCheckTask）]; 、import [基本制御用パッケージ２０００の名前].[ストリーム制御エンジンクラス名（StmEngine）];を記述することで、各クラスに定義されているメソッドのプログラムを利用できる。
【0181】
さらにアプリケーション（ＩＦ－ＴＨＥＮ）エンジン９０からのＡＰＩコマンド（連携指定）７５の送付先をマイクロサービス内制御テンプレートクラス（BaseIms Class）２０１０から個別デバイス対応マイクロサービス内制御クラス（Customims Class）２１１０に変更する。
【0182】
これら一連の処理（プログラム変更）の結果として実質的に、基本制御内パッケージ２０００内対応クラスであるデバイス制御テンプレートクラス（Base Device Class）２００２とマイクロサービス内制御テンプレート（BaseIms Class）２０１０を、個別デバイス制御用パッケージ２１００の対応クラスである個別デバイス制御クラス（Custom Device Class）２１０２と個別デバイス対応マイクロサービス内制御クラス（Customims Class）２１１０に差し替え使用７１することになる。このようにオブジェクト指向のプログラミング言語を用いてマイクロサービス８０を記述すると、非常にわずかな記載内容の変更だけでプログラム編集が容易かつ正確に行える効果がある。
【0183】
図１４を用いて、個別デバイス制御用パッケージで設定されるマイクロサービス８０の機能を説明する。必須欄２２０４で丸が付いている３項目（初期化２２１０と終了２２１２、開始・停止２２１４）は、最低限必須な機能となる。そして残りの２項目（センサデータ送信２２１８とＪＯＢ（仕事）受信２２２０）は、対応するデバイス８の特性に拠っては不要な機能になり得る。
【0184】
マイクロサービスの機能の中で初期化２２１０は、ｉｆＬｉｎｋアプリ（前述した用語の定義を参照）から起動された際に、ｉｆＬｉｎｋアプリとの接続やマイクロサービス８０および制御するデバイス８を登録する機能を示す。
【0185】
終了２２１２の機能は、ｉｆＬｉｎｋアプリから終了された際に、ｉｆＬｉｎｋアプリとの接続やマイクロサービス８０および制御するデバイス８を切断、終了する機能である。
【0186】
開始・停止２２１４の機能は、アプリケーション（ＩＦ－ＴＨＥＮ）ルール７０として登録されているデバイス８のルールが有効または無効になった場合に、デバイス８の開始または停止を行う機能である。
【0187】
次に状態通知２２１６の機能の説明を行う。ｉｆＬｉｎｋアプリでは、登録されているデバイスの状態を管理している。この状態通知２２１６は、ｉｆＬｉｎｋアプリで管理しているデバイス８の状態を更新するためにｉｆＬｉｎｋアプリへ通知する機能を示す。
【0188】
センサデータ送信２２１８の機能は、制御するデバイス８から送られるセンサデータをｉｆＬｉｎｋアプリへ送信する機能である。
【0189】
最後にＪＯＢ受信２２２０の機能に付いて説明する。ＩｆＬｉｎｋアプリを経由して、クラウドサーバ２もしくはアプリケーション（ＩＦ－ＴＨＥＮ）エンジン９０からＪＯＢの内容（操作内容の指示／ＡＰＩ）が通知される。このＪＯＢ受信２２２０は、ＩｆＬｉｎｋアプリから通視されるＪＯＢ情報を処理する機能である。
【0190】
図１５は、マイクロサービス内制御テンプレートクラス（BaseIms Class）２０１０あるいは個別デバイス対応マイクロサービス内制御クラス（Customims Class）が提供するＡＰＩの一覧を示す。すなわちマイクロサービス内制御テンプレートクラス（BaseIms Class）２０１０に、図１５で示した各制御用メソッドを記述（配置）する。つまり図１５のメソッド・関数欄２３０２に記載した各制御用メソッドが、マイクロサービス８０に標準装備されている必要がある。
【0191】
メソッド・関数欄２３０２に記載した各制御用メソッドの先頭に記載されている“void”や“int”は、制御用メソッドの戻り値のタイプ（形式／型）を表す。例えば所定のクラスまたは所定のメソッドからこの制御用メソッドを呼び出し７６で使用した場合、この制御用メソッドの処理終了後に「どんなタイプのデータが使用しているクラスやメソッドに戻ってくるか？」を示す。
【0192】
例えば“void”の文字が最初に記載された制御用メソッドでは、「戻り値無し」（すなわち制御用メソッドの処理終了後は、特定のデータは使用しているクラスやメソッドに戻って来ない）の状態を示す。
【0193】
同様に“int”や“long”の文字が最初に記載された制御用メソッドでは、「サイズが３２ビットや６４ビットの範囲の整数」が制御用メソッドの処理終了後に戻ってくる。
【0194】
そして“boolean”の文字が最初に記載された制御用メソッドでは、「“true”もしくは“false”の真偽値」が制御用メソッドの処理終了後に戻ってくる。
【0195】
また制御用メソッドの括弧内では、制御用メソッドに引き継がれる“引数のタイプ（形式／型）”と“引数”が、“スペース”を挟んで組となって記載されている。ここで複数の“引数”が引き継がれる場合には、引数の組の間に“，”（カンマ）が配置される。
【0196】
この引数のタイプ（形式／型）として“String”は、「文字列」を表す。また“Map”とは、キーと値がペアで格納される“キー／バリュー形データベース”を表す。そして“HashMap”は、上記“キー／バリュー形データベース”あるいはその仕組みを使ったクラス（HashMap Class）を意味する。このようにデバイス８の制御に“キー／バリュー形データベース”を使用することで、異なる制御用パッケージを跨ったメソッド間でのデータ／情報の共有化が図ＡＡれる効果が生まれる。さらにこのデータ／情報の保存形式として“キー／バリュー形データベース”を用いることで、データ検索の利便性が向上する。
【0197】
また“Message”とは、アプリケーション（ＩＦ－ＴＨＥＮ）エンジン９０宛やｉｆＬｉｎｋアプリ宛に直接送信できる“メッセージ”を意味する。また図１５で記載された“コンストラクタ”に付いては、［制御用クラス］に関する用語の定義で既に説明した。
【0198】
図１５で記載される“EPA”や“epa”“Epa”とは、“End Point Access”の略称で、アプリケーション（ＩＦ－ＴＨＥＮ）エンジン９０やｉｆＬｉｎｋアプリの事を指し示す。これに関係して図１５の２８番目に“void onActivationResult(boolean result, EPADevice device)”が記載されている。この処理概要２３０４は、“ｉｆＬｉｎｋアプリからのサービスの登録結果通知”と記載されている。ここで引数として、“引数のタイプ（形式／型）”に“EPADevice”が、“引数”として“device”が指定されている。ここで言う“サービスの登録”とは、“アプリケーション（ＩＦ－ＴＨＥＮ）ルール７０が操作するデバイス８の登録”を意味する。そしてその結果が“result”という引数に入る。ここで“登録できた”場合には、“result”に“true”が入力されて戻る。一方で“登録できなかった”場合には、“result”に“false”が入力されて戻る。上記引数の“device”は、“device”と言う識別情報が設定された特定のデバイス８を意味する。そしてその“引数のタイプ（形式／型）”を指定する“EPADevice”とは、“アプリケーション（ＩＦ－ＴＨＥＮ）エンジン９０またはｉｆＬｉｎｋアプリが識別できるデバイス８”を意味する。
【0199】
本実施形態で使用するデバイス８には、携帯形デバイス８も含まれる。従ってアプリケーション（ＩＦ－ＴＨＥＮ）ルール７０に従って携帯形デバイス８の操作を試みた時、対象となる携帯形デバイス８が操作領域外に持ち出されるケースが多発する。従ってユーザに対するサービス提供に先立って、対象となる携帯形デバイス８が操作領域に存在するか否かを事前に確認する必要がある。それには操作領域に存在するか否かを事前に確認すべき携帯形デバイス８の事前登録が必要となる。
【0200】
その事前登録のため、１１番目または１２番目に記載したコールバック登録の“void registerCallback()”や“void registerCallback（String cookie）”を行う。また操作領域に存在するか否かの事前確認が不要になった携帯形デバイス８に対しては、１３番目に記載したコールバック解除の“void unregisterCallback()”を行う。
【0201】
そして対象となるデバイス８の事前確認が行えた場合には、１４番目の“boolean createDevice()”を用いて“デバイス登録”を行う。逆に事前確認が出来なかったデバイス８に対しては、１５番目の“boolean deleteDevice()”で“デバイス解除”を行う。
【0202】
またユーザにサービス提供途中で例えば、特定デバイス８の電池切れなどでサービス継続が難しくなる場合が生じる。この状況に対応するため、２１番目の“void startHealthCheck(long interval)”でデバイス８毎の“ヘルスチェック開始”を行える。このメソッドでは“連続したヘルスチェック”の代わりに、“interval”で指定した一定周期毎のチェックを行ってもよい。
【0203】
そしてトラブルが発生した時には、マイクロサービス８０からアプリケーション（ＩＦ－ＴＨＥＮ）エンジン９０あるいはｉｆＬｉｎｋアプリに対して『警告通知』が必要となる。この場合には、１７番目の“int send_alert(-)”のメソッドを動作させて“アラート送信”が行える。
【0204】
本実施形態で行われる高熱者検出の中で、アプリケーション（ＩＦ－ＴＨＥＮ）エンジン９０からセンサマイクロサービス８０Ａと赤外線カメラマイクロサービス８０Ｃに要求される機能として、ａ）高熱者の検出（発見） とｂ）ユーザへの通知に必要な情報の提供の２種類が存在する。
【0205】
例えば図６の利用場面例（ユースケース）では“ａ）高熱者を検出（発見）”場合には、表示画面１２上に“検出した高熱者を斜線表示”してユーザに警告している。このように“検出した高熱者を可視化”するために必要な“ｂ）情報の提供”が必要となる。ところでこの“検出した高熱者を斜線表示した画像”は、ＡＩを用いた画像認識クラス（AI Analyze Class）２０１８で生成される。
【0206】
このような場合には、上記（ａ）と（ｂ）では、アプリケーション（ＩＦ－ＴＨＥＮ）エンジン９０に提供するデータの形式（制御用メソッドの戻り値のタイプ（形式／型））が異なる。
【0207】
このような状況に柔軟に対応するため、アプリケーション（ＩＦ－ＴＨＥＮ）エンジン９０から対応するマイクロサービス８０Ａ、８０Ｃに対して、“送信回答するデータフォーマット”を指定する必要がある。
【0208】
そのためマイクロサービス内制御テンプレートクラス（BaseIms Class）２０１０あるいは個別デバイス対応マイクロサービス内制御クラス（Customims Class）が提供するＡＰＩとして、マイクロサービス内制御テンプレートクラス（BaseIms Class）２０１０あるいは個別デバイス対応マイクロサービス内制御クラス（Customims Class）の対応メソッドから送信するデータフォーマットを指定するvoid setSendDataFormat(String format) が必要となる。
【0209】
このＡＰＩの引数 format のデータタイプ（形式／型）は String（文字列）で設定されている。つまりテキスト形式で送信するデータフォーマットが、アプリケーション（ＩＦ－ＴＨＥＮ）エンジン９０から指定される。
【0210】
ここで上記の“ａ）高熱者の検出（発見）結果報告”では、多量のデータが不必要となる。この場合のデータ送信処理には long send_data(Map map) が利用され、『高熱者が何人検出（発見）された』という情報がアプリケーション（ＩＦ－ＴＨＥＮ）エンジン９０に回答される。もし高熱者が検出できなかった場合でも、『高熱者が“０”人検出（発見）された』と回答させてもよい。このＡＰＩで指定された Map とは、『キーと値のペアが集合されたデータ』の形式を意味する。
【0211】
すなわちアプリケーション（ＩＦ－ＴＨＥＮ）エンジン９０が対応するマイクロサービス８０Ａ、８０Ｃに対して“ａ）高熱者の検出（発見）結果報告”を要求する場合には、最初に void setSendDataFormat(String format) のＡＰＩコマンドを発行して、『高熱者人数を算出するための画像認識処理』を実行させる。そして次に long send_data(Map map) のＡＰＩコマンドを発行して、“ａ）高熱者の検出（発見）結果報告”をさせる。
【0212】
ここで高熱者を検出（発見）された場合には、アプリケーション（ＩＦ－ＴＨＥＮ）エンジン９０が対応するマイクロサービス８０Ａ、８０Ｃに対して“ｂ）ユーザへの通知に必要な情報の提供”を要求する。この時も void setSendDataFormat(String format) のＡＰＩコマンドを発行するが、要求内容の違いを引数 format の中にテキスト形式で指定する。
【0213】
図６の利用場面例（ユースケース）から容易に分かるように、“ｂ）ユーザへの通知に必要な情報”の形式として映像や静止画像などのストリームデータを含むことがある。また映像や静止画、音声情報などのストリームデータには、多くの異なるデータ圧縮方式が存在する。従ってアプリケーション（ＩＦ－ＴＨＥＮ）エンジン９０から発行される void setSendDataFormat(String format) の引数format の中で、データ種別やデータ圧縮方式、必要なストリームデータの内容とその表示形式（例えば高熱者のみに斜線を引いて明示するなど）が指定される。
【0214】
そして例えば映像情報を要求する場合には、アプリケーション（ＩＦ－ＴＨＥＮ）エンジン９０から Stream send_data(Stream movie) のＡＰＩコマンドが発行される。ここで Stream とは“ストリーム形式のデータ”を意味し、映像情報が movie に入る。
【0215】
一方で静止画像の情報を要求する場合には、Stream send_data(Stream image, long time) のＡＰＩコマンドを発行する。この場合には静止画像情報が、image に入る。ここで time の情報で、“静止画像情報をキャプチャーする（取り込む）時刻”が設定できる。
【0216】
図６の利用場面例（ユースケース）から容易に分かるように、ユーザへの通知に画像（映像または静止画像）を使用する場合がある。このユーザに通知する画像をアプリケーション（ＩＦ－ＴＨＥＮ）エンジン９０または検知時動作設定部１４０に関係するマイクロサービス８０Ｈ、８０Ｆ側で生成させると、生成処理に多大な負荷が掛かる。
【0217】
本実施形態のように条件（ＩＦ）７２（図１１）側に関係したマイクロサービス８０Ａ、８０Ｃ側で“ｂ）ユーザへの通知に必要な情報の提供”をさせることで、高熱者検出装置（あるいは高熱者検出システム全体）の処理負荷を低減できる効果が生まれる。
【0218】
図１６に、デバイス制御テンプレートクラス（Base Device Class）あるいは個別デバイス制御クラス（Custom Device Class）が提供する（アプリケーション（ＩＦ－ＴＨＥＮ）エンジン９０からコマンド発行される）ＡＰＩの一覧を示す。記載ルールは、図１５と同じである。
【0219】
アプリケーションルール７０は基本的に、所定の条件（ＩＦ）７２に応じた所定の実行（ＴＨＥＮ）７８の組み合わせで構成される。例えばユーザ環境の温湿度や照度が刻々と変化するように、この条件（ＩＦ）７２判定の対象となる認識可能な実体／状態／情報７は時々刻々と変化する。この時間変化に対応できるように本実施形態では、“キー／バリュー形データベース”に対応する“HashMap”上へ、認識可能な実体／状態／情報７を時系列的に記録できるようにしている。
【0220】
例えば現在の認識可能な実体／状態／情報７の取得（すなわち例えばセンサデバイス８０２から得られるセンサデータの取得）を行いたい場合には、マイクロサービス内制御テンプレートクラス（BaseIms Class）２０１０から“HashMap createSensorData()”を呼び出し７６て、“センサデータの生成”を行う。一方で指定時刻での“センサデータの生成”を行いたい場合には、“HashMap createSensorData(long time)”の引数“time”に、データを得る時の指定時刻を設定する。また特定の時間間隔でデータ取得（＝“センサデータの生成”）を行いたい場合には、マイクロサービス内制御テンプレートクラス（BaseIms Class）２０１０のプログラムで特定時間間隔に合わせたデータ取得時刻を自動算出する。そしてその自動算出して得られた時刻を、“HashMap createSensorData(long time)”の引数“time”に順次指定する。
【0221】
そうして時系列的に蓄積されたセンサデータ（認識可能な実体／状態／情報７の内容）は“long sendSensor(Map map)”を利用して、デバイス制御テンプレートクラス（Base Device Class）２００２からマイクロサービス内制御テンプレートクラス（BaseIms Class）２０１０へ向けて“センサデータの送信”が行われる。
【0222】
図１６では一例として、センサデバイス８０２に対応するデバイス制御テンプレートクラス（Base Device Class）２００２の制御クラスの一覧を示した。しかしそれに限らず図７に示すように、携帯端末デバイス８０８やＨＭＤデバイス８１０、ＩｏＴ機器デバイス８２０に含まれる各種ロボット（あるいは駆動機構）などの制御が必要となる。従って図１６に記載した内容に限らず処理概要２３０４として例えば、“駆動実行”や予め指定された“画面／映像の表示”などが含まれる。
【0223】
また各種デバイス８がエッジコンピュータ６やクラウドサーバ２の外部に配置された場合には、デバイス８と対応するマイクロサービス８０間での通信制御が必要となる。図１６に示した制御メソッドのソースコードの説明をここでは省略するが、通信制御に必要な制御もソースコードの中に記述されても良い。例えば“java（登録商標）.net”パッケージの“Socketlmpl Class”を組み込む７６と、ＩＰアドレスレベルでデバイス８に対する通信制御が可能となる。具体的には、デバイス制御テンプレートクラス（Base Device Class）の前にimport java.net.Socketlmpl;を記述する。それに拠り、Socketlmpl Class の基本的通信制御を行う各種メソッドを使う事が可能となる。
【0224】
図１５の void setSendDataFormat(String format) に対応した機能である HashMap setDeviceData(HashMap map, long time) を利用して、マイクロサービス内制御テンプレートクラス（BaseIms Class）２０１０あるいは個別デバイス対応マイクロサービス内制御クラス（Customims Class）２１１０からセンサデータの設定が行われる。この時に利用される引数 map において、「映像を収集するか？」や「静止画像を収集するか？」などのセンサデータの種別などが設定される。またこの引数 time は、静止画像をキャプチャー（取得）する時刻を示す。
【0225】
もし映像を収集したい場合には、最初に Stream createSensorData() をコマンド発行して対応するセンサ８０２や赤外線カメラ８０６に映像を収集させる。その途中でセンサ８０２や赤外線カメラ８０６の収集を中止させたい場合には、 void removeCreateSensorData() のＡＰＩコマンドを発行してセンサデータ生成の中止（解除）をさせる。その後に Stream sendSensor(Stream movie) を発行すると、マイクロサービス内制御テンプレートクラス（BaseIms Class）２０１０あるいは個別デバイス対応マイクロサービス内制御クラス（Customims Class）２１１０の他のプログラム（メソッド）で収集映像の利用が可能となる。
【0226】
また静止画像を収集したい場合には、最初に Stream createSensorData(long time) をコマンド発行して対応するセンサ８０２や赤外線カメラ８０６に静止画像を収集させる。その後に Stream sendSensor(Stream image, long time) を発行すると、マイクロサービス内制御テンプレートクラス（BaseIms Class）２０１０あるいは個別デバイス対応マイクロサービス内制御クラス（Customims Class）２１１０の他のプログラム（メソッド）で収集静止画の利用が可能となる。
【0227】
図１７を用いて、本実施形態におけるデバイス８の状態遷移を、説明する。デバイス８の状態に関しては、停止状態２４００と動作状態２４０２、実行中２４０８、準備状態２４１０、エラー発生状態２４１４の５状態が定義される。
【0228】
デバイス８の制御開始２３００直後は、停止状態２４００となっている。そしてマイクロサービス８０によるデバイス制御の起動を意味する“createDevice()”（図１５の１４番目参照）が実行２５０２されると、デバイス８は動作状態２４０２に移る。ここで“createDevice()”の応答２５０６が失敗２５１０すると、エラー発生状態２４１４となり、ｉｆＬｉｎｋアプリの切断２５００のタイミングで停止状態２４００に戻る。またデバイス８が動作状態２４０２の時でもｉｆＬｉｎｋアプリの切断２５００が起きると、デバイス８は停止状態２４００に戻る。
【0229】
一方で“createDevice()”の応答２５０６が成功２５１２すると、デバイス８は準備状態２４１０に入る。そしてアプリケーション（ＩＦ－ＴＨＥＮ）エンジン９０からの動作指示２５０８が来ると、デバイスは動作開始して実行中２４０８となる。ここでアプリケーション（ＩＦ－ＴＨＥＮ）エンジン９０からの停止指示２５０４が来るとデバイス動作は停止し、デバイス８は準備状態２４１０に戻る。またデバイス８が準備状態２４１０と実行中２４０８のいずれの状態でも、ｉｆＬｉｎｋアプリが切断されると、デバイス８は停止状態２４００になる。
【0230】
そしてデバイス８の実行中２４０８にデバイス動作が失敗２５３０すると、デバイス動作開始のリトライ２５３０が必要となるため、デバイス８はエラー発生状態２４１４となる。同様にデバイス８実行中２４０８のデバイス８からの応答が無い時間が長くなるとタイムアウト２５２０が発生し、デバイス８はエラー発生状態２４１４となる。
【0231】
所定機能を実現するモジュール９を、デバイス８（あるいは人間が認識可能な実体／状態／情報７）とそれを制御するマイクロサービス８０（あるいは制御手段４）を分離した。それに拠り、デバイス８の状態とマイクロサービス８０の状態を分離して管理できる。一方でユーザへのサービス実行中に、ユーザが『アプリケーション（ＩＦ－ＴＨＥＮ）ルール７０の内容を変更』する（すなわちアプリケーション（ＩＦ－ＴＨＥＮ）ルール７０から操作するデバイス８が急に変更される）ことがある。このようにデバイス８の状態とマイクロサービス８０の状態を分離して管理すると、ユーザが行う『アプリケーション（ＩＦ－ＴＨＥＮ）ルール７０の変更』に対してリアルタイムの変更が容易となる効果がある。
【0232】
図１８に示すように、本実施形態におけるマイクロサービス８０の状態としては、静止状態２４００と接続中２４１２、動作状態２４０２、デバイス制御２４０４、開始２３００、エラー発生２４１４の６状態を定義できる。そして図１８に示すように、マイクロサービス８０の状態とデバイス８の状態との間の関係が成立する。
図１９は黒体輻射光源から放射される輻射光の光源温度と分光放射輝度との関係を示す。所定温度を有する全て物体は、その温度に応じた電磁波（黒体輻射光）を放射することが知られている。従ってそこから放射される黒体輻射光の分光特性を測定することで、黒体輻射光源の温度が分かる。
図１９は黒体輻射光源から放射される輻射光の光源温度と分光放射輝度との関係を示す。所定温度を有する全て物体は、その温度に応じた電磁波（黒体輻射光）を放射することが知られている。従ってそこから放射される黒体輻射光の分光特性を測定することで、黒体輻射光源の温度が分かる。
【0233】
図１９の分光特性図から所定波長１４の電磁波のみを抽出した場合、黒体輻射光源の温度で放射輝度が変化することが分かる。サーモグラフィ技術では、測定対象物から放射される輻射光の中で所定波長１４の電磁波のみを抽出し、その抽出電磁波強度から測定対象物の温度を測定する。
【0234】
このサーモグラフィ技術を用いて人物の頭皮表面温度を測定する場合、黒体輻射光の光路途中の毛髪で光散乱を受ける。したがって人物頭部の中で髪の毛が多く分布する場所（頭部の後ろ側など）での頭皮表面温度の測定は、大幅に測定精度が低下する（毛髪での光散乱ロスの影響で実際より低い温度が計測される）。そのためサーモグラフィ技術を用いて人物の頭皮表面温度を測定するには、毛髪分布が少ない顔面での測定が望ましい。
【0235】
また赤外線カメラ８０６で検出される所定波長１４の電磁波強度は、測定対象物から赤外線カメラ８０６までのの二乗に反比例する。従ってサーモグラフィ技術を用いた被測定対象物の表面温度測定では、測定対象物から赤外線カメラ８０６までのの増加に従って検出温度の低下が生じる。
【0236】
サーモグラフィ技術を用いて人物頭部の体温を精度良く測定する時の注意点として、上記の１）顔面（頭部の前面で、頭皮の露出場所）測定２）測定対象物と赤外線カメラ８０６間の考慮に加えて３）水分吸収（顔表面の汗と湿度の影響）と温度測定に使用する波長との関係４）赤外線カメラ８０６自体の温度依存性を持った暗電流の影響除去も考慮する必要がある。
【0237】
図１９に示した特性から、人の体温測定には２．５μｍから２０μｍの範囲の波長域光を使用するのが望ましい事を既に説明した。ところでこの範囲の光では、中心波長が２．９５５μｍ近傍と６．１００μｍ近傍で大きな水の吸収ピークが見られる。さらに６．９μｍより長い波長域では、波長が増加するに従って水の吸収量が増加する傾向にある。
【0238】
実際の水分子による光吸収量の具体例を示す。厚み０．３μｍの水膜の中を２．９５５μｍの波長光が通過すると、光量の８割が減衰する（すなわち入射光量の２割しか透過しない）。多量に汗をかくと、汗が水滴になって滴り落ちる経験をした人は多いと思われる。この時の水滴の直径が１～２ｍｍ程度を考えると、上記の光吸収量が如何に大きいかが分かる。
【0239】
一方で水分子による光吸収量の波長依存特性は、波長３．７５μｍ近傍と波長５．３０μｍ近傍で最小値を取る。従ってサーモグラフィに使用する所定波長１４の値としては、３．７５μｍ近傍または５．３０μｍ近傍が望ましい。そして上記の水分子の光吸収特性まで考慮すると、人の体温測定には３．３μｍ以上で５．７μｍ以下の範囲の波長域光を使用するのが望ましい。所定波長１４の値として、この範囲の波長光をサーモグラフィに使用すれば、比較的汗や空気中の湿度の影響が少なく体温測定が行える。
【0240】
さらに高精度の体温測定が要求される場合には、互いに異なる２波長光それぞれでの検出温度を測定してもよい。この２波長光での検出温度特性と上述した水分子光吸収の波長依存特性を組み合わせることで、赤外光の光路途中で光吸収した水分子量が推定できる。この推定された水分子量の値を使って検出温度を補正すると、正確な体温が算出できる。
【0241】
赤外線カメラ８０６の暗電流（黒体輻射光が遮断された時に流れる疑似検出電流）は、意外に大きい事が分かる。従って人の体温を正確に測定する場合には、検出電流値から暗電流の値を差し引く必要がある。ここでこの暗電流の値は、赤外線カメラ８０６内部の温度で変化する。
【0242】
赤外線カメラ８０６の暗電流値の測定には、赤外線カメラ８０６の入り口遮光は好ましくない。常温の光遮蔽部材からの黒体輻射光が赤外線カメラ８０６に入射して、暗電流値が測定できなくなる。人の体温測定の合間に、赤外線カメラ８０６を充分遠方物体に向けて暗電流値を頻繁に測定するのが望ましい。黒体輻射光の輝度は、赤外線カメラ８０６と充分遠方物体との間のの二乗に反比例するため、充分遠方物体からの黒体輻射光はほとんど赤外線カメラ８０６内に入らない。この状態で赤外線カメラ８０６から得られる信号量（電流値）が、暗電流の値にほぼ等しくなる。
【0243】
図２０に、本実施形態の応用例である３眼赤外線カメラ内構造を示す。ここでの“３眼”とは、赤外光３８を赤外光センサ３４上に集光させる１個のレンズ３２（１眼）と、可視光４０を可視光センサ４６、４８上に集光させる２個のレンズ４２、４４（２眼）の合計“３個のレンズ”を意味する。
【0244】
赤外光３８にを有する赤外光センサ３４が内蔵された赤外線カメラ８０６では、赤外光３８を集光させるレンズ３２の直前に、バンドパス光学フィルタ２４が配置されている。上述したように、このバンドパス光学フィルタ２４は３．３μｍ以上で５．７μｍ以下の範囲の波長域光（あるいは波長３．７５μｍ近傍の光または波長５．３０μｍ近傍の光）のみを通過させるように設計されている。
【0245】
この赤外光センサ３４から得られる検出信号（第１の信号）は温度分布映像／画像生成部３６に転送される。そしてこの温度分布映像／画像生成部３６で、空間的な検出温度分布特性を生成する。
【0246】
また図２０に示す３眼赤外線カメラ８０６では、上述した理由（測定対象２０と赤外線カメラ８０６間の変化）から生じる検出温度低下を補正する機能が内蔵されている。すなわち３眼の中の可視光４０に対応した２眼（レンズ４２、４４）で測定対象物（測定対象者）までのＬを測定し、その測定されたＬに応じて検出温度を補正する。
【0247】
つまり３眼赤外線カメラ８０６では、可視光４０を通過させる２個のレンズ４２、４４が互いに離れた位置に配置されている。従って測定対象２０に対する結像位置が、可視光センサ（撮像素子）４６と４８とでずれる。このずれ量を検出することで、“三角法”に基付いて測定対象２０から３眼赤外線カメラ８０６までのＬが算出できる。
【0248】
具体的には各可視光センサ（撮像素子）４６、４８から得られる検出信号（第２の信号）を利用して、可視映像／可視画像生成部５２、５４で測定対象２０に対する結像パターンを生成する。そして測定対象物毎の分布算出部６２で両者の結像パターン間のずれ量を調べ、測定対象２０から３眼赤外線カメラ８０６までのＬを算出する。
【0249】
前述したように測定対象２０から放射された黒体輻射光の輝度は、このＬの二乗に反比例する。従って温度分布補正部６０内部ではここで得られたＬの値を用いて、上記の空間的な検出温度分布特性を補正して実際の体温を算出する。
【0250】
温度分布補正部６０からは、“補正後の温度分布”しか得られない。単なる温度分布特性のみからは、測定対象２０の識別は難しい。そのため合成部６８では、上記の“補正後の温度分布”に可視光を撮像して得られた測定対象２０の輪郭や目、鼻、口などの形状画像を重ねる。そしてこの合成画像を、温度分布出力端子５８に出力する。
【0251】
ここで“補正後の温度分布”に重ねられる輪郭や目、鼻、口などの形状画像は、可視映像／可視画像の輪郭形状抽出部（目の輪郭を含む）６６から得られる。特にこの輪郭や目、鼻、口などの形状画像の中心位置は、“補正後の温度分布”の中心位置と一致する必要がある。図２０から分かるように、赤外線カメラ８０６のレンズ３２の位置と通常カメラ８１６－１，２のレンズ４２、４４の位置がずれる。従って上記の中心位置ずれを補正する必要がある。
【0252】
合成後の可視光平面映像／画像生成部６４では、中心位置ずれが補正された可視画像を生成する。それには可視映像／可視画像生成部５２、５４で得られた画像と、測定対象物毎の分布算出部６２から得られた情報Ｌが利用されている。そしてここで得られた可視画像は、可視映像／可視画像出力端子５６から出力される。
【0253】
図２０と先に説明した図２との対応関係を、以下に説明する。図２の通常カメラ８１６は、図２０の通常カメラ８１６－１、２に対応し、図２と図２０は同一の赤外線カメラ８０６をもつ。また図２０の可視映像／可視画像生成部５２、５４から測定対象物毎の分布算出部６２、合成後の可視光平面映像／画像生成部６４までが、図２の通常カメラ画像認識部１１２の一部に相当する。そして図２０の温度分布映像／画像生成部３６から温度分布補正部６０、合成部（可視光の輪郭も表示した温度分布）６８までが、図２の赤外線画像認識部１１６に相当する。
【0254】
また図２０で示した３眼赤外線カメラ８０６自体は、図７の赤外線カメラ８０６に対応する。そして図２の人物頭部温度判定部１２５は、図７の赤外線カメラマイクロサービス８０Ｃの一部に対応する。さらに図２の検知時動作設定部１４０は、図７のメーラーマイクロサービス８０ＨやＨＭＤマイクロサービス８０Ｅ、個別機器マイクロサービス８０Ｆなどに対応する。
【0255】
図２の通常カメラ画像認識部１１２では、“１〕画像解析”から“２〕人物検出”、“３〕人数検出”、“４〕頭部検出”、“５〕検出”に至る高度な“画像認識”を行う説明をした。そしてその高度な“画像認識”は、センサマイクロサービス８０ＡのＡＩを用いた画像認識クラス（AI Analyze Class）２０１８（図１３）で実行される説明を行った。
【0256】
図２１は、図１３で説明したセンサマイクロサービス８０Ａのクラス構造（ソフトウェアアーキテクチャ）での各クラス間の連携例を示す。始めに Customims Class で Custom Device Class と AI Analyze Class のインポート（組み込み）処理７４、７６を行う。これにより Custom Device Class と AI Analyze Class で定義（記述）されたメソッドの、Customims Class での使用が可能となる。
【0257】
そしてステップ４４（Ｓ４４）においてアプリケーション（ＩＦ－ＴＨＥＮ）エンジン９０から発行されるＡＰＩコマンドの void setSendDataFormat (String format) で送信データフォーマット指定を受ける。上記引数の format に『通常のカメラ８１６からの画像信号の認識（解析）後に得られた人物の人数の回答要求』が含まれた場合には、AI Analyze Class のメソッドを使った画像認識処理が開始される。
【0258】
画像認識処理を開始する前に、通常カメラ８１６からの画像信号（映像信号または静止画像信号が相当し第２の信号に対応）の取得が必要となる。そのため Customims Class で HashMap SetDeviceData() を呼び出す。すると Custom Device Class で予め記述された対応メソッドが動作し（Ｓ４５）、通常カメラ８１６を使った画像信号の取得が開始される。
【0259】
ステップ４６（Ｓ４６）では、通常カメラ８１６を使った画像信号の取得が行われる。次に Customims Class で Stream sendSensor() が呼び出されたタイミングで、通常カメラ８１６が取得した画像信号が Customims Class に読み込まれる。ここで読み込まれた画像信号は、バッファメモリ２００８（図１３）に保存されてもよい（Ｓ４８）。
【0260】
AI Analyze Class で予め記述された対応メソッドを Customims Class で呼び出して（Ｓ４９）、バッファメモリ２００８に保存され画像信号の画像認識処理側読み取り（Ｓ５０）が行われる。同様に AI Analyze Class で予め記述された対応メソッドを Customims Class で呼び出すことで、人物の頭部位置算出指示とその結果得られる人数算出の指示（Ｓ５１）が行われる。それに応じて AI Analyze Class で予め記述された対応メソッドが動作し、データ解析（画像認識）Ｓ５２が実行される。そして上記対応メソッドの実行が完了すると、データ解析（画像認識）の結果得られた人物の人数が分かる（Ｓ５３）。
【0261】
ステップ５４（Ｓ５４）では、その算出された人数に応じて『頭部の温度取得が必要か否か？』の判定処理が行われる。なおここまでは通常カメラ８１６を制御するセンサマイクロサービス８０Ａ単独の処理フローを説明した。
【0262】
ステップ５５（Ｓ５５）とステップ５６（Ｓ５６）での頭部温度の抽出処理は、上記センサマイクロサービス８０Ａと赤外線カメラマイクロサービス８０Ｃとの連携処理あるいは、上記センサマイクロサービス８０Ａでの画像認識結果を利用した赤外線カメラマイクロサービス８０Ｃでの処理となる。
【0263】
図２２は高熱者検出時に複数媒体へ同時に通知を行う場合のアプリケーション（ＩＦ－ＴＨＥＮ）ルール設定方法例を示す。図２２では３眼赤外線カメラ８０６から得られた各種映像や各種静止画像１２８だけでなく、ＧＰＳ位置センサ８３０から得られた位置情報１３８も検出信号として利用する。
【0264】
ここで高熱者検出時の通知先（通知に利用する媒体）の設定は、アプリケーション（ＩＦ－ＴＨＥＮ）エンジン９０のメモリ領域７１に保存されたアプリケーション（ＩＦ－ＴＨＥＮ）ルール７０で規定（記述）される。
【0265】
図２２の例では、メール通信／メール送信１２５０と警告画面表示１２３０の両方に通知する。ここで重要な事は“高熱者が検出”されたことだけでなく、通知を受けたユーザが“検出された高熱者を識別”できる必要がある。図６の警告画面表示１２３０例では、“右端の人が斜線表示”されて識別可能になっている。このようにユーザへの通知時に“画像を利用した視覚化”を行うと、通知を受けたユーザが容易に高熱者（注目すべき対象）を識別できる効果がある。
【0266】
この通知時の“視覚化”のため、警告画面表示１２３０を制御する画面表示用マイクロサービス８０Ｋに対しては、高熱者特定画像１３６を送信してもよい。またメール通信／メール送信１２５０を制御するメーラーマイクロサービス８０Ｈへ高熱者顔画像１３２を送信してもよい。ここでメール受信するユーザは、現場から離れた位置に居る可能性が高い。そのためメーラーマイクロサービス８０Ｈに対して、ＧＰＳ位置センサ８３０から取得した位置情報１３８から得られた高熱者位置情報１３４を送信してもよい。
【0267】
ここで特に重要な事は、『通知側の（すなわち図１１の実行（ＴＨＥＮ）７８に関連した）マイクロサービス８０Ｈ、８０Ｋに送信する情報１３２～１３６を、センサ側の（すなわち図１１の条件（ＩＦ）７２に関連した）マイクロサービス８０Ｃ、８０Ｊに作らせて送信させる』ところにある。ユーザへの通知（すなわち図１１の実行（ＴＨＥＮ）７８）に必要な情報を、センサ側の（すなわち図１１の条件（ＩＦ）７２に関連した）マイクロサービス８０Ｃ、８０Ｊで作成すると、高熱者検出装置内部（あるいは高熱者検出システム全体）の処理効率が大幅に向上する効果がある。
【0268】
高熱者検出時の通知情報の例は、図６の表示画面１２のように“警告文”と“高熱者識別が容易な表示画像”で構成されている。また上記“警告文”の内容は、定形フォーマット化が可能な場合が多い。従ってアプリケーション（ＩＦ－ＴＨＥＮ）ルール７０の実行部（ＴＨＥＮ）７８（図１１）が行う処理の中で『ユーザへの情報提供』の方法として、標準テンプレート（定形フォーマット）を多用できる。そのため『ユーザへの情報提供』に関連したマイクロサービス８０の中では、『既存テンプレートを利用した標準フォーマット作成』の処理が実施可能となる。
【0269】
図２３は、情報提供関連のマイクロサービスのクラス構成（ソフトウェアアーキテクチャ）を示す。情報提供関連の基本制御用パッケージ２０００に、既存テンプレートを利用した標準フォーマット生成クラス（FillFormat Class）２０１９が含まれる。そしてここでユーザに通知する情報に関する“定型文”（例えば上記の“警告文”など）と、“表示画像”（例えば上記の“高熱者識別が容易な表示画像”など）の組が生成される。
【0270】
この既存テンプレートを利用した標準フォーマット生成クラス（FillFormat Class）２０１９の中（所定メソッド）で作成した作成フォーマット７７は、作成フォーマット保存用バッファメモリに一時保存される。そしてこの一時保存された作成フォーマット７７はデバイス制御テンプレートクラス（Base Device Class）２００２または個別デバイス制御クラス（Custom Device Class）２１０１を経て、ユーザに画面表示１２３０される。
【0271】
図２４では、図２３に示した情報提供（自動通知）関連のマイクロサービスを用いたユーザへの情報通信方法を説明している。図２２を用いて、『通知側の（すなわち図１１の実行（ＴＨＥＮ）７８に関連した）マイクロサービス８０Ｈ、８０Ｋに送信する情報１３２～１３６を、センサ側の（すなわち図１１の条件（ＩＦ）７２に関連した）マイクロサービス８０Ｃ、８０Ｊに作らせて送信させる』説明をした。ここではその具体的な処理フローを説明する。
【0272】
図２４のステップ２４（Ｓ２４）からステップ２９（Ｓ２９）までが、センサ側の（すなわち図１１の条件（ＩＦ）７２に関連した）マイクロサービス８０Ｃに必要な情報を作成させて受け取るまでの処理を示している。そしてステップ３０（Ｓ３０）からステップ３１（Ｓ３１）までが、センサ側マイクロサービス８０Ｃが作成した情報を利用した情報を通知側の（すなわち図１１の実行（ＴＨＥＮ）７８に関連した）マイクロサービス４Ｄ、８０Ｈ、８０Ｋに送信して通知処理をさせている。
【0273】
本実施形態では高熱者を検出して初めて、ユーザへの通知が必要となる。従って最初にセンサ側の（すなわち図１１の条件（ＩＦ）７２に関連した）マイクロサービス８０Ｃに対して、条件（ＩＦ）７２に合致したか否か？すなわち高熱者を検出したか否か？（Ｓ２７）の回答をさせる。そして高熱者を検出した場合には、通知側の（すなわち図１１の実行（ＴＨＥＮ）７８に関連した）マイクロサービス４Ｄ、８０Ｈ、８０Ｋに送信するために必要な情報１２８を、センサ側の（すなわち図１１の条件（ＩＦ）７２に関連した）マイクロサービス８０Ｃに作成／送信させる（Ｓ２９）。
【0274】
ここでステップ２４（Ｓ２４）とステップ２８（Ｓ２８）では、アプリケーション（ＩＦ－ＴＨＥＮ）エンジン９０からセンサ側のマイクロサービス８０Ｃに対して void setSendDataFormat (String format) （図１５）のＡＰＩコマンドを発行する。これによりセンサ側のマイクロサービス８０Ｃが作成／送信する情報内容の切り替え指示を行う。
【0275】
本発明の実施形態を説明したが、この実施形態は一例として提示したものであり、発明の範囲を限定することは意図していない。この新規な実施形態は、その他の様々な形態で実施されることが可能であり、発明の要旨を逸脱しない範囲で、種々の省略、置き換え、変更を行うことができる。この実施形態やその変形や、実施形態の組み合わせも、発明の範囲や要旨に含まれるとともに、特許請求の範囲に記載された発明とその均等の範囲に含まれる。
【符号の説明】
【0276】
２・・・クラウドサーバ、６・・・エッジコンピュータ、７０・・・アプリケーション（ＩＦ－ＴＨＥＮ）ルール、８０・・・マイクロサービス、９０・・・アプリケーション（ＩＦ－ＴＨＥＮ）エンジン、９２・・・ｉｆＬｉｎｋアプリ。
【図1】
【図2】
【図3】
【図4】
【図5】
【図6】
【図7】
【図8】
【図9】
【図10】
【図11】
【図12】
【図13】
【図14】
【図15】
【図16】
【図17】
【図18】
【図19】
【図20】
【図21】
【図22】
【図23】
【図24】