特開 2022-111746 状態推定システム、及び状態推定プログラム

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

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

(11)【公開番号】P2022111746

(43)【公開日】2022-08-01

(54)【発明の名称】状態推定システム、及び状態推定プログラム

(51)【国際特許分類】

   G06T 7/00 20170101AFI20220725BHJP

【ＦＩ】

G06T7/00 300F

【審査請求】未請求

【請求項の数】9

【出願形態】ＯＬ

(21)【出願番号】P 2021007377

(22)【出願日】2021-01-20

(71)【出願人】

【識別番号】516249414

【氏名又は名称】ＡＷＬ株式会社

(74)【代理人】

【識別番号】100084375

【弁理士】

【氏名又は名称】板谷 康夫

(74)【代理人】

【識別番号】100125221

【弁理士】

【氏名又は名称】水田 愼一

(74)【代理人】

【識別番号】100142077

【弁理士】

【氏名又は名称】板谷 真之

(72)【発明者】

【氏名】ファドワ ゴーラビ

(72)【発明者】

【氏名】土田 安紘

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

5L096

【Ｆターム（参考）】

5L096DA03

5L096GA30

5L096HA09

5L096JA03

5L096JA11

(57)【要約】      （修正有）

【課題】カメラから入力された各フレーム画像における注目領域の状態を正確に推定し、推論処理の処理負荷を小さくする状態推定システム及び状態推定プログラムを提供する。
【解決手段】状態推定処理は、各フレーム画像におけるテーブル（注目領域）の画像に付与されたラベルに基づいて、テーブルの暫定状態を推定し、時刻Ｔ以降のフレーム画像におけるテーブルの暫定状態（時刻Ｔ～（Ｔ＋２）の暫定状態）と、時刻Ｔより前のフレーム画像におけるテーブルの最終状態（時刻（Ｔ－２）～（Ｔ－１）の最終状態）とに基づいて、時刻Ｔのフレーム画像におけるテーブルの最終状態を推定する。これにより、単純なＭＬＣモデルを用いて、注目領域の画像にラベルを付与した場合でも、ラベルに含まれるノイズが最終状態の推定結果に与える影響を減らせ、複雑なＭＬＣモデルを用いる必要が無く、推論処理の処理負荷を小さくできる。
【選択図】図１２

【特許請求の範囲】

【請求項1】

カメラから入力された各フレーム画像における注目領域の画像に、１以上のラベルを付与するラベル付与手段と、
前記ラベル付与手段により前記注目領域の画像に付与されたラベルに基づいて、前記注目領域の暫定状態を推定する暫定状態推定手段と、
前記カメラから入力された過去の複数のフレーム画像のうち、所定の時刻のフレーム画像における前記注目領域の最終状態を推定する最終状態推定手段とを備える状態推定システムにおいて、
前記最終状態推定手段は、前記過去の複数のフレーム画像のうち、前記所定の時刻以降のフレーム画像における前記注目領域の暫定状態と、前記所定の時刻より前のフレーム画像における前記注目領域の最終状態とに基づいて、前記所定の時刻のフレーム画像における前記注目領域の最終状態を推定する状態推定システム。

【請求項2】

前記ラベル付与手段は、前記注目領域の画像に、各ラベルの尤度を付与し、
前記暫定状態推定手段は、前記各ラベルの尤度と、前記各ラベルの尤度の閾値とを比較して、前記注目領域の暫定状態を推定することを特徴とする請求項１に記載の状態推定システム。

【請求項3】

前記所定の時刻のフレーム画像における前記注目領域の最終状態が、前記最終状態推定手段により推定された最終状態になることが、状態遷移のルールを表すステートマシンから見て許容されない場合は、前記所定の時刻のフレーム画像における前記注目領域の最終状態を、このフレーム画像の一つ前のフレーム画像における前記注目領域の最終状態に維持する状態遷移検証手段をさらに備えることを特徴とする請求項１又は請求項２に記載の状態推定システム。

【請求項4】

前記状態遷移検証手段は、前記注目領域の最終状態が、前記最終状態推定手段により推定された最終状態になることが、状態遷移のルールを表すステートマシンから見て許容されない場合でも、前記暫定状態推定手段により推定された前記注目領域の暫定状態が、所定時間以上、同じ状態であるときには、前記注目領域の最終状態が、前記最終状態推定手段により推定された最終状態に遷移することを許容することを特徴とする請求項３に記載の状態推定システム。

【請求項5】

前記状態推定システムの使用者に報知を行う報知手段をさらに備え、
前記報知手段は、前記最終状態推定手段により推定された前記注目領域の最終状態が、所定の条件を満たしたときに、前記状態推定システムの使用者に報知を行うことを特徴とする請求項１又は請求項２に記載の状態推定システム。

【請求項6】

前記状態推定システムの使用者に報知を行う報知手段をさらに備え、
前記報知手段は、前記状態遷移検証手段による検証後における、前記注目領域の最終状態が、所定の条件を満たしたときに、前記状態推定システムの使用者に報知を行うことを特徴とする請求項３又は請求項４に記載の状態推定システム。

【請求項7】

前記報知手段は、前記使用者への報知を行うための報知画面を表示装置に出力し、
前記報知画面は、前記使用者への報知の情報と、前記カメラから直近に入力されたフレーム画像に基づく画像とを含むことを特徴とする請求項５又は請求項６に記載の状態推定システム。

【請求項8】

コンピュータを、
カメラから入力された各フレーム画像における注目領域の画像に、１以上のラベルを付与するラベル付与手段と、
前記ラベル付与手段により前記注目領域の画像に付与されたラベルに基づいて、前記注目領域の暫定状態を推定する暫定状態推定手段と、
前記カメラから入力された過去の複数のフレーム画像のうち、所定の時刻のフレーム画像における前記注目領域の最終状態を推定する最終状態推定手段として機能させるための状態推定プログラムにおいて、
前記最終状態推定手段は、前記過去の複数のフレーム画像のうち、前記所定の時刻以降のフレーム画像における前記注目領域の暫定状態と、前記所定の時刻より前のフレーム画像における前記注目領域の最終状態とに基づいて、前記所定の時刻のフレーム画像における前記注目領域の最終状態を推定する状態推定プログラム。

【請求項9】

前記コンピュータを、さらに、
前記所定の時刻のフレーム画像における前記注目領域の最終状態が、前記最終状態推定手段により推定された最終状態になることが、状態遷移のルールを表すステートマシンから見て許容されない場合は、前記所定の時刻のフレーム画像における前記注目領域の最終状態を、このフレーム画像の一つ前のフレーム画像における前記注目領域の最終状態に維持する状態遷移検証手段として機能させることを特徴とする請求項８に記載の状態推定プログラム。

【発明の詳細な説明】

【技術分野】

【0001】

本発明は、状態推定システム、及び状態推定プログラムに関する。

【背景技術】

【0002】

従来から、物体認識用のＤＮＮ（Deep Neural Network）において、画像を入力すると、複数の正解ラベルを返す（出力する）タイプのディープニューラルネットワークモデル（多ラベル分類用ニューラルネットワークモデル）がある。この多ラベル分類（ＭＬＣ（Ｍｕｌｔｉ Ｌａｂｅｌ Ｃｌａｓｓｉｆｉｃａｔｉｏｎ））用ニューラルネットワークモデルを用いれば、カメラから入力された各フレーム画像における注目領域の画像に映り込んでいる1つ以上の物体について、各物体の種別を判別することができるので、上記の注目領域における現在の状態を推定することが可能である。そして、上記のように、カメラから入力された各フレーム画像における注目領域の状態を推定することができれば、レストラン等の店舗や、郵便局、銀行及び病院等における、注目領域の状態（例えば、レストランのテーブルや、郵便局、銀行及び病院の窓口等の状態）を、これらの施設のスタッフに報知することで、これらの施設のスタッフの作業効率を向上させることができる。なお、多ラベル分類器の例は、例えば、特許文献１に開示されている。

【先行技術文献】

【特許文献】

【0003】

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

【発明の概要】

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

【0004】

しかしながら、一般に、１つの静止画像（カメラから入力された各フレーム画像における注目領域の画像）のみに基づいてラベルを付与するタイプの単純な多ラベル分類用ニューラルネットワークモデル（以下、「ＭＬＣモデル」という）からの出力データ（例えば、１以上のラベルと、これらのラベルの尤度）には、ノイズが含まれるので、上記の注目領域における状態を正確に推定することはできない。この点は、上記の単純なＭＬＣモデル以外の、１つの静止画像のみに基づいてラベルを付与するタイプの単純な多ラベル分類用アルゴリズムに共通した問題である。

【0005】

また、行動認識等の分野では、時系列のフレーム画像（例えば、時刻ｔ、ｔ－１、ｔ－２、ｔ－３、ｔ－４、ｔ－５、ｔ－６の６枚のフレーム画像）に基づいて、正確な推定結果を返すことができる複雑な多ラベル分類用アルゴリズム（例えば、複雑なＭＬＣモデル）も使用されているが、このような多ラベル分類用アルゴリズムは、一度に、複数のフレーム画像を処理するので、（プロセッサにおける）推論処理の処理負荷が大きくなる。

【0006】

本発明は、上記課題を解決するものであり、カメラから入力された各フレーム画像における注目領域の状態を正確に推定することが可能で、しかも、推論処理の処理負荷が小さい状態推定システム、及び状態推定プログラムを提供することを目的とする。

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

【0007】

上記課題を解決するために、本発明の第1の態様による状態推定システムは、カメラから入力された各フレーム画像における注目領域の画像に、１以上のラベルを付与するラベル付与手段と、前記ラベル付与手段により前記注目領域の画像に付与されたラベルに基づいて、前記注目領域の暫定状態を推定する暫定状態推定手段と、前記カメラから入力された過去の複数のフレーム画像のうち、所定の時刻のフレーム画像における前記注目領域の最終状態を推定する最終状態推定手段とを備える状態推定システムにおいて、前記最終状態推定手段は、前記過去の複数のフレーム画像のうち、前記所定の時刻以降のフレーム画像における前記注目領域の暫定状態と、前記所定の時刻より前のフレーム画像における前記注目領域の最終状態とに基づいて、前記所定の時刻のフレーム画像における前記注目領域の最終状態を推定する。

【0008】

この状態推定システムにおいて、前記ラベル付与手段は、前記注目領域の画像に、各ラベルの尤度を付与し、前記暫定状態推定手段は、前記各ラベルの尤度と、前記各ラベルの尤度の閾値とを比較して、前記注目領域の暫定状態を推定してもよい。

【0009】

この状態推定システムにおいて、前記所定の時刻のフレーム画像における前記注目領域の最終状態が、前記最終状態推定手段により推定された最終状態になることが、状態遷移のルールを表すステートマシンから見て許容されない場合は、前記所定の時刻のフレーム画像における前記注目領域の最終状態を、このフレーム画像の一つ前のフレーム画像における前記注目領域の最終状態に維持する状態遷移検証手段をさらに備えることが望ましい。

【0010】

この状態推定システムにおいて、前記状態遷移検証手段は、前記注目領域の最終状態が、前記最終状態推定手段により推定された最終状態になることが、状態遷移のルールを表すステートマシンから見て許容されない場合でも、前記暫定状態推定手段により推定された前記注目領域の暫定状態が、所定時間以上、同じ状態であるときには、前記注目領域の最終状態が、前記最終状態推定手段により推定された最終状態に遷移することを許容することが望ましい。

【0011】

この状態推定システムにおいて、前記状態推定システムの使用者に報知を行う報知手段をさらに備え、前記報知手段は、前記最終状態推定手段により推定された前記注目領域の最終状態が、所定の条件を満たしたときに、前記状態推定システムの使用者に報知を行うようにしてもよい。

【0012】

この状態推定システムにおいて、前記状態推定システムの使用者に報知を行う報知手段をさらに備え、前記報知手段は、前記状態遷移検証手段による検証後における、前記注目領域の最終状態が、所定の条件を満たしたときに、前記状態推定システムの使用者に報知を行うことが望ましい。

【0013】

この状態推定システムにおいて、前記報知手段は、前記使用者への報知を行うための報知画面を表示装置に出力し、前記報知画面は、前記使用者への報知の情報と、前記カメラから直近に入力されたフレーム画像に基づく画像とを含むことが望ましい。

【0014】

本発明の第２の態様による状態推定プログラムは、コンピュータを、カメラから入力された各フレーム画像における注目領域の画像に、１以上のラベルを付与するラベル付与手段と、前記ラベル付与手段により前記注目領域の画像に付与されたラベルに基づいて、前記注目領域の暫定状態を推定する暫定状態推定手段と、前記カメラから入力された過去の複数のフレーム画像のうち、所定の時刻のフレーム画像における前記注目領域の最終状態を推定する最終状態推定手段として機能させるための状態推定プログラムにおいて、前記最終状態推定手段は、前記過去の複数のフレーム画像のうち、前記所定の時刻以降のフレーム画像における前記注目領域の暫定状態と、前記所定の時刻より前のフレーム画像における前記注目領域の最終状態とに基づいて、前記所定の時刻のフレーム画像における前記注目領域の最終状態を推定する。

【0015】

この状態推定プログラムにおいて、前記コンピュータを、さらに、前記所定の時刻のフレーム画像における前記注目領域の最終状態が、前記最終状態推定手段により推定された最終状態になることが、状態遷移のルールを表すステートマシンから見て許容されない場合は、前記所定の時刻のフレーム画像における前記注目領域の最終状態を、このフレーム画像の一つ前のフレーム画像における前記注目領域の最終状態に維持する状態遷移検証手段として機能させることが望ましい。

【発明の効果】

【0016】

本発明の第１の態様による状態推定システム、及び第２の態様による状態推定プログラムによれば、過去の複数のフレーム画像のうち、所定の時刻以降のフレーム画像における注目領域の暫定状態と、上記所定の時刻より前のフレーム画像における注目領域の最終状態とに基づいて、上記所定の時刻のフレーム画像における注目領域の最終状態を推定するようにした。これにより、上記の１つの静止画像（カメラから入力された各フレーム画像における注目領域の画像）のみに基づいてラベルを付与するタイプの単純な多ラベル分類用アルゴリズム（例えば、単純なＭＬＣモデル）を用いて、注目領域の画像にラベルを付与した場合でも、このラベルに含まれるノイズが最終状態の推定結果に与える影響を減らすことができる。従って、各フレーム画像における注目領域の（最終）状態を正確に推定することができる。

【0017】

また、本発明の第１の態様による画像分析装置、及び第２の態様による状態推定プログラムによれば、上記のように、１つの静止画像（各フレーム画像における注目領域の画像）のみに基づいてラベルを付与するタイプの単純な多ラベル分類用アルゴリズム（例えば、単純なＭＬＣモデル）を用いた場合でも、各フレーム画像における注目領域の（最終）状態を正確に推定することができるので、複数の（時間的に）連続した静止画像（時系列のフレーム画像）に基づいてラベルを付与するタイプの複雑な多ラベル分類用アルゴリズム（例えば、複雑なＭＬＣモデル）を用いる必要がない。従って、（プロセッサにおける）推論処理の処理負荷を小さくすることが可能になる。

【図面の簡単な説明】

【0018】

【図1】本発明の一実施形態の状態推定システムの概略の構成を示すブロック構成図。

【図2】図１中の分析ボックスの概略のハードウェア構成を示すブロック図。

【図3】同分析ボックスにおけるＣＰＵの機能ブロック構成図。

【図4】上記状態推定システムにおける状態推定処理の概要を示すフローチャート。

【図5】図４中のＳ２の処理（前処理１）の説明図。

【図6】図４中のＳ５の処理の説明図。

【図7】上記状態推定システムにおける各テーブルの状態の遷移のルールを表すステートマシンを示す図。

【図8】上記状態推定システムにおける暫定状態推定処理のフローチャート。

【図9】図６中の推論エンジンによる推論結果を示す図。

【図10】上記状態推定システムにおける最終状態推定処理のフローチャート。

【図11】上記最終状態推定処理に用いられるステートバッファの説明図。

【図12】図１０におけるＳ２１乃至Ｓ２７の処理の説明図。

【図13】上記状態推定システムにおいて、ステートマシンから見て許されない状態遷移が許容される場合の説明図。

【図14】上記状態推定システムにおいてスタッフへの報知（アラート）が行われる場合の説明図。

【図15】上記のスタッフへの報知に用いられる報知画面の説明図。

【図16】変形例１－１の状態推定システムにおけるステートマシンを示す図。

【図17】変形例１－１の状態推定システムにおける注目領域の説明図。

【図18】変形例１－２の状態推定システムにおけるステートマシンを示す図。

【図19】変形例１－２の状態推定システムにおける注目領域の説明図。

【図20】変形例１－３の状態推定システムにおけるステートマシンを示す図。

【図21】変形例１－３の状態推定システムにおける報知画面を示す図。

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

【0019】

以下、本発明を具体化した実施形態による状態推定システム、及び状態推定プログラムについて、図面を参照して説明する。図１は、本実施形態による状態推定システム１０の概略の構成を示すブロック構成図である。本実施形態では、分析ボックス１（請求項における「コンピュータ」）、ネットワークカメラ（ＩＰ（Ｉｎｔｅｒｎｅｔ Ｐｒｏｔｏｃｏｌ）カメラ）である３６０度カメラ２、及びサイネージ３（請求項における「表示装置」）が、レストランのチューン店の店舗Ｓ内に配される場合の例について説明する。図１に示すように、状態推定システム１０は、店舗Ｓ内に配された、分析ボックス１、１つ以上の３６０度カメラ２（以下、「カメラ２」と略す）、サイネージ３、ハブ４、及びルータ６と、クラウドＣ上のＡＩ分析サーバ７及び管理サーバ８とを備えている。ただし、上記の構成要素のうち、ルータ６と、ＡＩ分析サーバ７と、管理サーバ８とは、あくまでも、状態推定システム１０における付属的な構成要素である。

【0020】

上記のカメラ２は、ＩＰアドレスを持ち、ネットワークに直接接続することが可能なネットワークカメラであると同時に、天井等に取り付けられて、店舗Ｓにおける広範な領域を撮影することが可能な３６０度カメラである。図１に示すように、分析ボックス１は、ＬＡＮ（Ｌｏｃａｌ Ａｒｅａ Ｎｅｔｗｏｒｋ）５とハブ４とを介して、１つ以上のカメラ２と接続され、これらのカメラ２の各々から入力された各フレーム画像に基づいて、各フレーム画像における各注目領域の状態（具体的には、各テーブルの状態）の推定処理等の推論処理を行う。また、上記のサイネージ３は、後述する報知画面７１（図１５参照）等の表示に用いられる。

【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】

次に、図１０乃至図１２を参照して、上記の状態推定エンジンによる最終状態推定処理について説明する。この最終状態推定処理は、分析ボックス１のＣＰＵ１１（の最終状態推定部２３）によって、上記の暫定状態推定処理の後に行われる。

【0047】

図１１に示すように、上記の最終状態推定処理に用いられるステートバッファ６０は、（２ｎ＋１）フレーム分の状態の格納用バッファである。図１１に示すステートバッファ６０の例では、ウィンドウサイズｗ（ステートバッファ６０に格納可能な状態の最大数（２ｎ＋１））は、１１になっている。このように、ウィンドウサイズｗが１１である場合には、今回の最終状態の推定対象となるテーブルが映ったフレーム画像が、時刻Ｔ（請求項における「所定の時刻」）のフレーム画像であるとすると、先ず、分析ボックス１のＣＰＵ１１（の最終状態推定部２３）は、図１１に示すように、上記のステートバッファ６０に、時刻（Ｔ－５）～（Ｔ－１）のフレーム画像に映ったテーブルの最終状態と、時刻Ｔ～（Ｔ＋５）のフレーム画像に映ったテーブルの暫定状態とを格納する。

【0048】

すなわち、図１０のフローチャートに示すように、分析ボックス１のＣＰＵ１１（の暫定状態推定部２２）によって、新たなフレーム画像（のテーブル画像４１）に映ったテーブルについての暫定状態の推定処理が完了すると（Ｓ２１でＹＥＳ）、ＣＰＵ１１（の最終状態推定部２３）は、現在のステートバッファ６０のレングス（ステートバッファ６０に格納済の状態（ステート）の数）が、ｗ（ステートバッファ６０に格納可能な状態の最大数（２ｎ＋１））より小さいか否かを判定する（Ｓ２２）。そして、現在のステートバッファ６０のレングスが、ｗより小さい場合には（Ｓ２２でＹＥＳ）、上記の新たなフレーム画像に映ったテーブルについての暫定状態（直近に推定されたテーブルの暫定状態）を、ステートバッファ６０に追加して格納する（Ｓ２３）。

【0049】

図１２を参照して、上記の暫定状態の追加格納処理について、説明する。図１２に示す例では、説明を簡単にするために、上記のウィンドウサイズｗ（ステートバッファ６０に格納可能な状態の最大数（２ｎ＋１））が、５である場合の例について、説明する。図１２に示すように、ＣＰＵ１１（の最終状態推定部２３）は、ｔ＝１～４の時には、その時点におけるステートバッファ６０のレングス（ステートバッファ６０に格納済の状態の数）が、ｗ（＝５）より小さいので（図１０のＳ２２でＹＥＳ）、上記の直近に推定されたテーブルの暫定状態を、ステートバッファ６０に追加して格納する（Ｓ２３）。

【0050】

これに対して、上記Ｓ２２の判定時において、図１２に示すｔ＝５の時のように、既に、その時点におけるステートバッファ６０のレングス（ステートバッファ６０に格納済の状態の数）が、ｗ（＝５）になっている時には（Ｓ２２でＮＯ）、ファーストインファーストアウト（先入れ先出し）の方式で、ステートバッファ６０から、一番最初に格納した状態（その時点の（Ｔ－２）の状態）を取り出して（除去して）（Ｓ２４）、上記の直近に推定されたテーブルの暫定状態を、ステートバッファ６０に（（Ｔ＋２）の状態として）格納する（Ｓ２５）。

【0051】

次に、ＣＰＵ１１（の最終状態推定部２３）は、上記Ｓ２３又はＳ２５の処理後におけるステートバッファ６０のレングス（ステートバッファ６０に格納済の状態の数）が、ｗ（＝５）になっているか否かを判定する（Ｓ２６）。この判定の結果、ステートバッファ６０のレングスが、ｗ（＝５）になっているときには（Ｓ２６でＹＥＳ）、ＣＰＵ１１（の最終状態推定部２３）は、ステートバッファ６０に格納済の状態（時刻（Ｔ－２）と（Ｔ－１）の最終状態、及び時刻Ｔ～（Ｔ＋２）の暫定状態）のうち、最頻の（最も多い）状態を、時刻Ｔ（のフレーム画像に映ったテーブル）の最終状態であると推定して、この最頻の状態を、ステートバッファ６０における時刻Ｔの最終状態としてセットする（Ｓ２７）。具体的には、図１２における左側の時刻（ｔ＝５）のステートバッファ６０の例では、格納されている５つの状態のうち、４つが注文済み状態なので、「注文済み状態」を、ステートバッファ６０における時刻Ｔの最終状態６１ａとする。また、図１２における右側の時刻（ｔ＝５）のステートバッファ６０の例では、格納されている５つの状態のうち、３つが注文済み状態なので、「注文済み状態」を、ステートバッファ６０における時刻Ｔの最終状態６１ａとする。なお、図１２における関数ｖは、ステートバッファ６０における各状態の頻度（数）を示す。詳細に言うと、ｖ（空席）、ｖ（注文待ち）、ｖ（注文済み）、ｖ（食事中）は、それぞれ、ステートバッファ６０に格納されている「空席状態」、「注文待ち状態」、「注文済み状態」、及び「食事中状態」の数（個数）を示す。

【0052】

上記の最終状態推定部２３によるＳ２７の処理（時刻Ｔの最終状態の推定処理）が終了すると、ＣＰＵ１１（の状態遷移検証部２４）は、時刻Ｔの（フレーム画像における）テーブルの最終状態が上記Ｓ２７でセットされた最終状態になることが、図７に示すステートマシンから見て許容されるか否かを判定する（Ｓ２８）。この判定の結果、許容されない場合は（Ｓ２８でＮＯ）、ＣＰＵ１１（の状態遷移検証部２４）は、時刻Ｔのテーブルの最終状態を、時刻Ｔのフレーム画像の一つ前のフレーム画像（時刻（Ｔ－１）のフレーム画像）におけるテーブルの最終状態に維持する。すなわち、ＣＰＵ１１（の状態遷移検証部２４）は、時刻Ｔのテーブルの最終状態を、時刻（Ｔ－１）のフレーム画像におけるテーブルの最終状態に訂正する（Ｓ２９）。

【0053】

より正確に説明すると、ＣＰＵ１１（の状態遷移検証部２４）は、図７に示すステートマシンから見て、時刻（Ｔ－１）の（フレーム画像における）テーブルの最終状態が「空席状態」であるときに、時刻Ｔの（フレーム画像における）テーブルの最終状態が「注文済み状態」に遷移することは、許容されないので、この場合には、原則として、時刻Ｔのテーブルの最終状態を、時刻（Ｔ－１）のテーブルの最終状態（「空席状態」）に維持する。とは言え、顧客が、来店してテーブルに座ると同時に、スタッフがテーブルにコップを置いて注文を取ること（テーブルの状態が、「空席状態」から「注文済み状態」になる（遷移する）こと）はあり得ることである。このため、ＣＰＵ１１（の状態遷移検証部２４）は、時刻Ｔの（フレーム画像における）テーブルの最終状態が上記Ｓ２７でセットされた最終状態になることが、図７に示すステートマシンから見て許容されない場合でも、暫定状態推定部２２により推定された暫定状態が、所定時間以上、同じ状態であるときには、テーブルの最終状態が、上記Ｓ２７でセットされた最終状態になることを許容する場合がある。

【0054】

すなわち、図１３に示すように、暫定状態推定部２２により推定されたテーブルの暫定状態が、「空席状態」であった後、１０秒以上、「注文済み状態」であり続けると、ＣＰＵ１１（の状態遷移検証部２４）は、テーブルの最終状態が、「空席状態」から「注文済み状態」に遷移することを許容する。また、図１３に示すように、暫定状態推定部２２により推定されたテーブルの暫定状態が、「注文待ち状態」であった後、１０秒以上、「食事中状態」であり続けると、ＣＰＵ１１（の状態遷移検証部２４）は、テーブルの最終状態が、「注文待ち状態」から「食事中状態」に遷移することを許容する。さらにまた、暫定状態推定部２２により推定されたテーブルの暫定状態が、「食事中状態」であった後、６０秒以上、「空席状態」であり続けると、ＣＰＵ１１（の状態遷移検証部２４）は、テーブルの最終状態が、「食事中状態」から「空席状態」に遷移することを許容する。ただし、ＣＰＵ１１の状態遷移検証部２４が、ステートマシンから見て許されない状態遷移を許容するのは、上記の「空席状態」から「注文済み状態」への遷移、「注文待ち状態」から「食事中状態」への遷移、及び「食事中状態」から「空席状態」への遷移だけであって、例えば、「空席状態」から「片付け待ち状態」への遷移や、「注文待ち状態」から「片付け待ち状態」への遷移等については、許容しない。

【0055】

ＣＰＵ１１の状態遷移検証部２４は、上記図１０中のＳ２９の最終状態の訂正処理が終了すると、訂正後における時刻Ｔのテーブルの最終状態を、報知部２５（図３参照）に送る（出力する）。また、上記図１０中のＳ２８の判定の結果、時刻Ｔのテーブルの最終状態が上記Ｓ２７でセットされた最終状態になることが許容される場合には（Ｓ２８でＹＥＳ）、ＣＰＵ１１の状態遷移検証部２４は、上記Ｓ２７でセットされた時刻Ｔのテーブルの最終状態を、報知部２５（図３参照）に送る（出力する）。

【0056】

ＣＰＵ１１の報知部２５は、上記の状態遷移検証部２４から送られた、時刻Ｔのテーブルの最終状態が、以下の条件を満たしたときに、状態推定システム１０の使用者であるスタッフに報知を行う（アラートを上げる）。具体的には、図１４に示すように、ＣＰＵ１１の報知部２５は、時刻Ｔのテーブルの最終状態が、空席状態５１から注文待ち状態５２に変わると、顧客が来店してテーブルの座席に座ったとみなして、アラート７０ａを上げて、スタッフに報知を行う。また、ＣＰＵ１１の報知部２５は、状態遷移検証部２４から送られた、時刻Ｔのテーブルの最終状態が、１０分以上、注文済み状態５３であると、顧客が長時間注文を待っているとみなして、アラート７０ｂを上げて、スタッフに報知を行う。さらにまた、ＣＰＵ１１の報知部２５は、状態遷移検証部２４から送られた、時刻Ｔのテーブルの最終状態が、所定の時間（例えば、５分）以上、片付け待ち状態５５であると、テーブルが長時間片付けられていない（トレイがテーブルに放置されている）とみなして、アラート７０ｃを上げて、スタッフに報知を行う。

【0057】

上記のスタッフへの報知には、図１に示すサイネージ３が用いられる。図１５は、サイネージ３のディスプレイに表示される報知画面７１である。この報知画面７１は、スタッフへの報知の情報と、カメラ２から直近に入力されたフレーム画像に基づく画像（３６０度カメラであるカメラ２で撮影した円座標系の画像を、２次元直交座標系の画像（平面展開画像）に変換したもの）とを含む画像である。以下の説明では、上記のカメラ２から直近に入力されたフレーム画像に基づく画像を、「カメラ２から直近に入力されたフレーム画像」と略す。

【0058】

ＣＰＵ１１の報知部２５は、状態遷移検証部２４から送られた、時刻Ｔのテーブルの最終状態に基づいて、報知画面７１上に、フレーム７２～７４を表示する。これらのフレームのうち、一点鎖線のフレーム７２は、このフレーム７２で囲まれたテーブルが、「注文済み状態」であることを示し、破線のフレーム７３は、このフレーム７３で囲まれたテーブルが、「注文待ち状態」であることを示し、実線のフレーム７４は、このフレーム７４で囲まれたテーブルが、「食事中状態」であることを示す。また、報知画面７１上におけるフレームで囲まれていないテーブルは、空席状態である。また、図１５には示していないが、報知画面７１上には、テーブルが「片付け待ち状態」であることを示すフレームも表示され得る。

【0059】

また、ＣＰＵ１１の報知部２５は、状態遷移検証部２４から送られた、時刻Ｔのテーブルの最終状態に基づいて、報知画面７１上に、上記のアラート７０ａ～７０ｃを表示する。すなわち、ＣＰＵ１１の報知部２５は、状態遷移検証部２４から送られる、時刻Ｔのテーブルの最終状態が、空席状態５１から注文待ち状態５２に変わると、該当のテーブルを囲む破線のフレーム７３をブリンク表示させると共に、サイネージ３のスピーカから警告音を出力させることにより、上記のスタッフへのアラート７０ａを行う。また、ＣＰＵ１１の報知部２５は、状態遷移検証部２４から送られた、時刻Ｔのテーブルの最終状態が、１０分以上、注文済み状態５３であると、該当のテーブルを囲む一点鎖線のフレーム７２をブリンク表示させることにより、上記のスタッフへのアラート７０ｂを行う。さらにまた、ＣＰＵ１１の報知部２５は、状態遷移検証部２４から送られた、時刻Ｔのテーブルの最終状態が、所定の時間（例えば、５分）以上、片付け待ち状態５５であると、該当のテーブルを囲むフレームをブリンク表示させることにより、上記のスタッフへのアラート７０ｃを行う。

【0060】

上述したように、ＣＰＵ１１の報知部２５は、報知画面７１上に、上記のフレーム７２～７４だけではなく、カメラ２から（分析ボックス１に）直近に入力されたフレーム画像も、表示する。この理由は、以下の通りである。すなわち、ＣＰＵ１１の報知部２５は、時刻Ｔの（テーブルの）最終状態に基づいて、上記のフレーム７２～７４の表示や、上記のアラート７０ａ～７０ｃを行うが、図１１及び図１２の説明で言及したように、時刻Ｔの最終状態を推定するためには、将来（時刻Ｔよりも後）の暫定状態（図１１中の時刻（Ｔ＋１）～（Ｔ＋５）の暫定状態）が必要になる。図４で説明したように、カメラ２からの画像のフレームレートは、１ｆｐｓであるので、時刻（Ｔ＋５）の暫定状態を得ることができるのは、時刻Ｔの（テーブルの）暫定状態を推定してから５秒後になる。従って、上記Ｓ２７（図１０参照）の時刻Ｔの最終状態推定処理を行うために、５秒以上のディレイ（遅延）が生じる。また、報知部２５が、状態遷移検証部２４から、時刻Ｔのテーブルの最終状態を受け取るのは、図４のＳ１でカメラ２からフレーム画像を受信した後、Ｓ２～Ｓ６の全ての処理が終了してからである。

【0061】

従って、報知画面７１上に表示される各テーブルのフレーム７２～７４や、アラート７０ａ～７０ｃは、あくまでも、５秒以上前（ＣＰＵ１１や（推論）チップ１４の性能によっては、数十秒以上前になることもあり得る）にカメラ２から（分析ボックス１に）入力されたフレーム画像に基づく情報である。この情報のディレイ（遅延）の問題を解消するために、ＣＰＵ１１の報知部２５は、図１５に示すように、報知画面７１上に、上記のフレーム７２～７４だけではなく、カメラ２から（分析ボックス１に）直近に入力されたフレーム画像も、表示する。このように、報知画面７１上に、カメラ２から直近に入力されたフレーム画像を表示することにより、報知画面７１上に表示される各テーブルのフレーム７２～７４の更新や、アラート７０ａ～７０ｃの実行が遅れるにも拘らず、報知画面７１上に表示された直近のフレーム画像を見たスタッフが、各テーブルの状態の変化や、上記のアラート７０ａ～７０ｃに対応する状態（顧客の来店や、顧客が長時間注文を待っている状態や、テーブルが長時間片付けられていない状態）の発生に気づくことができる。

【0062】

なお、テーブルの状態が所定の条件になった時に、直ぐにアラートを発しなければならないような場合には、図１１及び図１２に示されるステートバッファ６０に格納する、時刻Ｔより後の暫定状態（将来の状態）の数を減らしたり、ゼロにして、アラートのリアルタイム性を高めることも考えられるが、ステートバッファ６０に格納する、時刻Ｔより後の暫定状態の数を減らせば減らすほど、時刻Ｔの最終状態の推定精度が低くなる。従って、ステートバッファ６０に格納する、時刻Ｔより後の暫定状態の数は、少なくとも３以上であることが望ましく、できれば５以上であることが望ましい。要するに、ステートバッファ６０に格納する、時刻Ｔより後の暫定状態の数は、最終状態の推定精度の観点からは、多い方が望ましいが、フレーム７２～７４の更新やアラートのリアルタイム性の観点からは、少ない方が望ましい。なお、テーブルの状態が所定の条件になった時に、直ぐにアラートを発しなければならないような場合において、ステートバッファ６０に格納する、時刻Ｔより後の暫定状態の数を減らしたり、ゼロにした場合には、その分だけ、ステートバッファ６０に格納する、時刻Ｔより前の最終状態の数を増やすことが、最終状態の推定精度の観点から、望ましい。

【0063】

上記のように、本実施形態の状態推定システム１０及び状態推定プログラム１８によれば、過去の複数のフレーム画像のうち、所定の時刻（時刻Ｔ）以降のフレーム画像（図１１の例では、時刻Ｔ～（Ｔ＋５）のフレーム画像）におけるテーブルの暫定状態と、上記所定の時刻より前のフレーム画像（図１１の例では、時刻（Ｔ－５）～（Ｔ－１）のフレーム画像）におけるテーブルの最終状態とに基づいて、上記所定の時刻（時刻Ｔ）のフレーム画像におけるテーブルの最終状態を推定するようにした。これにより、１つの静止画像のみに基づいてラベルを付与するタイプの単純なＭＬＣモデルを用いて付与されたラベルに含まれるノイズが最終状態の推定結果に与える影響を減らすことができる。従って、上記の単純なＭＬＣモデルを用いて付与された、ノイズを含むラベルに基づいて、各フレーム画像におけるテーブルの暫定状態を推定しているにも拘わらず、これらの暫定状態に基づいて、各フレーム画像におけるテーブルの（最終）状態を正確に推定することができる。

【0064】

また、本実施形態の状態推定システム１０及び状態推定プログラム１８によれば、上記のように、１つの静止画像（各フレーム画像におけるテーブル画像）のみに基づいてラベルを付与するタイプの単純なＭＬＣモデルを用いているので、複数の（時間的に）連続した静止画像（時系列のフレーム画像）に基づいてラベルを付与するタイプの複雑なＭＬＣモデルを用いた場合と比べて、（推論）チップ１４等のプロセッサにおける推論処理の処理負荷を小さくすることができる。従って、本状態推定システム１０は、エッジ側に配された処理能力の高くないコンピュータを用いて、容易に実現することができる。

【0065】

また、本実施形態の状態推定システム１０によれば、推論エンジン４６（ＭＬＣモデル）によりテーブル画像４１に付与された各ラベルの尤度と、各ラベルの尤度の閾値とを比較して、テーブルの暫定状態を推定するようにした。これにより、テーブルの暫定状態を容易に推定することができる。

【0066】

また、本実施形態の状態推定システム１０によれば、時刻Ｔのフレーム画像におけるテーブルの最終状態が、最終状態推定部２３により推定された最終状態（図１０中のＳ２７の処理でセットされた最終状態）になることが、状態遷移のルールを表すステートマシン（図７参照）から見て許容されない場合は、時刻Ｔのフレーム画像におけるテーブルの最終状態を、このフレーム画像の一つ前のフレーム画像（時刻（Ｔ－１）のフレーム画像）におけるテーブルの最終状態に維持するようにした。これにより、単純なＭＬＣモデルを用いて付与されたラベルに基づく、暫定状態の推定結果に含まれるノイズの影響を除去することができる。

【0067】

上記のように、ステートマシンを用いて、暫定状態の推定結果に含まれるノイズの影響を除去する理由は、以下の通りである。すなわち、状態推定システム１０では、上記のように、所定の時刻Ｔ以降のフレーム画像におけるテーブルの暫定状態と、所定の時刻Ｔより前のフレーム画像におけるテーブルの最終状態とに基づいて、所定の時刻Ｔのフレーム画像におけるテーブルの最終状態を推定することにより、単純なＭＬＣモデルを用いて付与されたラベルに含まれるノイズが最終状態の推定結果に与える影響を減らすことができる。とは言え、この処理だけでは、各テーブル画像に付与されたラベルに含まれるノイズが最終状態の推定結果に与える影響を、完全に除去することはできない。このため、状態推定システム１０では、ステートマシンを用いて、状態遷移のルールから見て許容されない最終状態への遷移を防ぐことにより、単純なＭＬＣモデルを用いて付与されたラベルに含まれるノイズが最終状態の推定結果に与える影響を、より減らしている。

【0068】

また、本実施形態の状態推定システム１０によれば、時刻Ｔのフレーム画像におけるテーブルの最終状態が、最終状態推定部２３により推定された最終状態になることが、状態遷移のルールを表すステートマシンから見て許容されない場合でも、暫定状態推定部２２により推定された暫定状態が、所定時間以上、同じ状態であるときには、テーブルの最終状態が、最終状態推定部２３により推定された最終状態になることを許容する場合がある。これは、ステートマシンが示すルールから外れた例外的な状態遷移のパターンに対応するためである。

【0069】

また、本実施形態の状態推定システム１０によれば、状態推定エンジン（図４参照）から出力された（状態遷移検証部２４による検証後における、）テーブルの最終状態が、所定の条件を満たしたときに、状態推定システム１０の使用者（スタッフ）に報知を行うようにした。これにより、状態遷移検証部２４による検証済の正確な最終状態に基づいて、スタッフに報知を行うことができるので、店舗のオペレーションを効率化することができる。

【0070】

また、本実施形態の状態推定システム１０によれば、分析ボックス１の（ＣＰＵ１１の）報知部２５が、スタッフへの報知を行うための報知画面７１を、サイネージ３（のディスプレイ）に表示し、この報知画面７１に、スタッフに各テーブルの状態を報知するための情報（図１５におけるフレーム７２～７４）に加えて、カメラ２から直近に入力されたフレーム画像を表示するようにした。これにより、時刻Ｔの暫定状態を推定してから、時刻Ｔの最終状態の推定が完了するまでに時間がかかることに起因して、報知画面７１上に表示される各テーブルのフレーム７２～７４の更新や、アラート７０ａ～７０ｃの実行が遅延するにも拘らず、スタッフが、報知画面７１上に表示された直近のフレーム画像を見て、各テーブルの状態の変化や、上記のアラート７０ａ～７０ｃに対応する状態（顧客の来店や、顧客が長時間注文を待っている状態や、テーブルが長時間片付けられていない状態）の発生に気づくことができる。

【0071】

変形例：
なお、本発明は、上記の各実施形態の構成に限られず、発明の趣旨を変更しない範囲で種々の変形が可能である。次に、本発明の変形例について説明する。

【0072】

変形例１：
上記の実施形態では、状態推定システム１０が、レストランの店舗用の状態推定システムである場合の例について、説明した。けれども、本発明の状態推定システムは、これに限られず、図７に示すステートマシンを切り換える（入れ替える）ことにより、色々な用途に応用することができる。

【0073】

変形例１－１：
例えば、ステートマシンを、図１６に示すステートマシンに変更することにより、本発明の状態推定システムを、各種販売店のレジや、銀行、郵便局、病院、レンタカーの店舗等の窓口用の状態推定システムにすることができる。以下の説明では、上記の各種販売店のレジや、銀行、郵便局、病院、レンタカーの店舗等の（顧客サービス用の）窓口を、総称して、「窓口」と呼ぶ。図１６及び図１７に示す例では、注目領域には、上記の窓口８６（の領域）（図１７参照）だけではなく、顧客の待機エリアの椅子８７（の領域）が含まれる。

【0074】

図１６に示すステートマシンにおける、（窓口８６及び椅子８７の）状態には、空き状態８１と、待ち状態８２と、サービス提供状態８３と、処理中状態８４とがある。空き状態８１は、図１７に示す窓口８６と椅子８７が空いている状態であり、待ち状態８２は、顧客が、窓口８６又は椅子８７で、スタッフのサービス提供を待っている状態である。また、サービス提供状態８３は、スタッフが、窓口８６で、顧客にサービスを提供している状態であり、処理中状態８４は、スタッフが、いわゆるバックオフィスで、顧客の要求を処理している状態である。

【0075】

この状態推定システムでは、図１６に示すように、ラベル付与部がＭＬＣモデルを用いて注目領域の画像に付与するラベル（付与ラベル）が、空きラベルである時に、暫定状態推定部が、注目領域の暫定状態が空き状態８１であると推定し、上記の付与ラベルが、顧客ラベルのみである時に、暫定状態推定部が、注目領域の暫定状態が待ち状態８２であると推定する。また、上記の付与ラベルが、顧客ラベルとスタッフラベルである時に、暫定状態推定部が、注目領域の暫定状態がサービス提供状態８３であると推定し、上記の付与ラベルが、スタッフラベルである時に、暫定状態推定部が、注目領域の暫定状態が処理中状態８４であると推定する。

【0076】

図１６に示すように、注目領域（図１７に示す窓口８６及び椅子８７）の状態は、原則として、空き状態８１、待ち状態８２、サービス提供状態８３、処理中状態８４の順に遷移した後、一旦、サービス提供状態８３になってから、空き状態８１に戻る。

【0077】

この変形例１－１の状態推定システムは、顧客が窓口８６に近づいた時、及び顧客が待機エリアの椅子８７に座った時に、これらの窓口８６及び椅子８７が映ったフレーム画像に基づいて、図１６に示すアラート８０ａを、店員に通知する。顧客が窓口８６に近づいた時には、該当の窓口８６の番号と共に、上記のアラート８０ａが、全ての店員、又は特殊な専門知識を有する特定の店員に通知される。ここで、銀行や、郵便局等の店員（スタッフ）は、窓口におけるサービス提供業務だけではなく、バックオフィスにおける事務作業も行っている。従って、上記のようなアラート８０ａを店員に通知することにより、店員は、バックオフィスにおける事務作業に集中して、顧客が現れた時だけ、窓口をチェックすれば良い（窓口におけるサービス提供を行えば良い）ようにすることができるので、店員による店舗オペレーションを最適化することができる。

【0078】

また、この変形例１－１の状態推定システムは、窓口８６が映ったフレーム画像に基づいて、図１６に示すアラート８０ｂを通知する。このアラート８０ｂは、（１）窓口８６における、ある店員による顧客へのサービス提供オペレーションが完了したことを、他の店員に通知するためと、（２）窓口が利用可能になったことを、顧客に通知するために行われる。上記のアラート８０ａ及びアラート８０ｂの通知は、サイネージへの報知画面表示や、スピーカによる警告音出力により行われる。なお、図１７から分かるように、この変形例１－１の状態推定システムに使用されるカメラは、上記実施形態のような３６０度カメラではなく、通常のネットワークカメラである。

【0079】

変形例１－２：
また、ステートマシンを、図１８に示すステートマシンに変更することにより、本発明の状態推定システムを、銀行のＡＴＭ(現金自動預け払い機) 用の状態推定システムにすることができる。この例では、注目領域は、図１９に示すＡＴＭ９４（の領域）である。

【0080】

図１８に示すように、上記のステートマシンにおける、ＡＴＭ９４の状態には、空き状態９１と、処理中状態９２と、支援中状態９３とがある。空き状態９１は、図１９に示すＡＴＭ９４が空いている状態であり、処理中状態９２は、顧客がＡＴＭ９４のサービスを使用している状態である。また、支援中状態９３は、顧客が５分以上ＡＴＭ９４の前にいた（処理中状態９２が５分以上継続した）ために、銀行のスタッフが顧客のＡＴＭ操作を支援している状態である。

【0081】

この状態推定システムでは、図１８に示すように、ラベル付与部がＭＬＣモデルを用いてＡＴＭ９４の画像に付与するラベル（付与ラベル）が、空きラベルである時に、暫定状態推定部が、ＡＴＭ９４の暫定状態が空き状態９１であると推定し、上記の付与ラベルが、顧客ラベルのみである時に、暫定状態推定部が、ＡＴＭ９４の暫定状態が処理中状態９２であると推定する。また、上記の付与ラベルが、顧客ラベルとスタッフラベルである時に、暫定状態推定部は、ＡＴＭ９４の暫定状態が支援中状態９３であると推定する。

【0082】

図１８に示すように、ＡＴＭ９４の状態は、原則として、空き状態９１から処理中状態９２に遷移した後、空き状態９１に戻る。ただし、空き状態９１から処理中状態９２に遷移した後、５分以上経過した場合には、銀行のスタッフが顧客のＡＴＭ操作を支援するので、処理中状態９２から支援中状態９３に遷移した後、空き状態９１に戻る。

【0083】

図１８に示すアラート９０ａは、各ＡＴＭ９４の前における顧客の有無（各ＡＴＭ９４が空き状態９１であるか否か）を、銀行のスタッフに通知するためのアラートである。この変形例１－２の状態推定システム（における分析ボックス）は、各ＡＴＭ９４が映ったフレーム画像に基づいて、銀行のカウンターの中のスタッフがいるエリアに設置されたサイネージに、どのＡＴＭ９４が空いていて、どのＡＴＭが使用中かを示す報知画面を表示することにより、上記のアラート９０ａを上げる。上記の報知画面が、全てのＡＴＭ９４が空いていない（使用中である）ことを示す時には、銀行のスタッフは、ＡＴＭ９４の設置エリアの状況をチェックし、顧客のＡＴＭ操作を速めるように支援する。

【0084】

また、図１８に示すアラート９０ｂは、上記のように、顧客が５分以上ＡＴＭ９４の前にいた（処理中状態９２が５分以上継続した）時に、それを銀行のスタッフに通知するためのアラートである。このアラート９０ｂが通知されると、銀行のスタッフは、該当のＡＴＭ９４を使用中の顧客の操作を支援する。

【0085】

変形例１－３：
また、ステートマシンを、図２０に示すステートマシンに変更することにより、本発明の状態推定システムを、ハイウェイバス用の状態推定システムにすることができる。この例では、注目領域は、バスの各座席（の領域）である。

【0086】

図２０に示すように、上記のステートマシンにおける（バスの）各座席の状態には、空席状態９５と、着席状態９６とがある。空席状態９５は、該当の座席が、空いている状態であり、着席状態９６は、該当の座席に乗客が座っている状態である。この状態推定システムでは、図２０に示すように、ラベル付与部がＭＬＣモデルを用いて該当の座席の画像に付与するラベル（付与ラベル）が、空席ラベルである時に、暫定状態推定部が、該当の座席の暫定状態が空席状態９５であると推定し、上記の付与ラベルが、人ラベルである時に、暫定状態推定部が、該当の座席の暫定状態が着席状態９６であると推定する。図２０に示すように、各座席の状態は、空席状態９５から着席状態９６に遷移した後、空席状態９５に戻る。

【0087】

この変形例１－３の状態推定システム（における分析ボックス）は、バス内の各座席が映ったフレーム画像に基づいて、図２１に示すように、バスのドアに設置されたサイネージ９８に、バスの各座席の状態を示す報知画面９９を表示する。この報知画面９９には、座席状態表示欄９９ａと、着席数表示欄９９ｂとが設けられている。上記の座席状態表示欄９９ａは、バス内の各座席の状態（どの座席が空いていて、どの座席に乗客が座っているか）を示し、着席数表示欄９９ｂは、バス内の座席のうち、着席状態９６にあると推定された座席の数を示す。

【0088】

上記の報知画面９９は、（１）乗客による座席の選択、及び（２）ドライバーによる着席している乗客数の確認に用いられる。上記の（１）乗客による座席の選択は、以下のようにして、行われる。すなわち、バスがバス停に着くと、状態推定システム（における分析ボックス）が、バスのドアに設置されたサイネージ９８に、報知画面９９を表示する。バスに乗り込む乗客は、この報知画面９９における座席状態表示欄９９ａを見て、空いている座席の中から、自分の座席を決める（選択する）。

【0089】

また、上記の（２）ドライバーによる着席している乗客数の確認は、以下のような場合に行われる。例えば、バスが、サービスエリア等の休憩所に到着して、決められた休憩時間が経過した時に、バスのドライバーが、サイネージ９８に表示された報知画面９９における着席数表示欄９９ｂを見て、着席状態にある座席の数（すなわち、着席している乗客数）を確認するときである。

【0090】

変形例２：
上記の実施形態では、状態推定システム１０が、分析ボックス１（請求項における「コンピュータ」）に加えて、カメラ２、及びサイネージ３等を備えている場合の例を示したが、これらの構成要素のうち、本発明の状態推定システムに必須の構成要素は、分析ボックスのみである。すなわち、注目領域（例えば、テーブル）の撮影用のカメラは、既存の（外付けの）監視カメラであってもよく、報知画面の表示用のサイネージも、既存の（外付けの）表示装置であってもよい。

【0091】

変形例３：
上記の実施形態では、分析ボックス１のＣＰＵ１１が、ラベル付与部２１と、暫定状態推定部２２と、最終状態推定部２３と、状態遷移検証部２４と、報知部２５とを備える構成にしたが、本発明の状態推定システムは、この構成に限られない。例えば、各店舗に配するカメラを、いわゆるエッジコンピューティング機能を有するＡＩ（Ａｒｔｉｆｉｃｉａｌ Ｉｎｔｅｌｌｉｇｅｎｃｅ）カメラにして、このＡＩカメラに、ＭＬＣモデルを備えたアプリパッケージをインストールして、ＡＩカメラが、上記のラベル付与部の機能を備えるようにしてもよい。

【0092】

変形例４：
上記の実施形態では、１つの静止画像のみに基づいてラベルを付与するタイプの単純なＭＬＣモデルを用いて、カメラ２から入力された各フレーム画像における各注目領域の画像（テーブル画像）に、１以上のラベルを付与する場合の例を示したが、本発明における「ラベル付与手段」は、上記のような単純なＭＬＣモデルを用いたものに限られず、各注目領域の画像に多ラベルを付与することが可能な多ラベル分類用アルゴリズムを用いたものであればよい。

【符号の説明】

【0093】

１ 分析ボックス（コンピュータ）
２ カメラ
３ サイネージ（表示装置）
１０ 状態推定システム
１８ 状態推定プログラム
２１ ラベル付与部（ラベル付与手段）
２２ 暫定状態推定部（暫定状態推定手段）
２３ 最終状態推定部（最終状態推定手段）
２４ 状態遷移検証部（状態遷移検証手段）
２５ 報知部（報知手段）
３１ａ～３１ｔ、４１ テーブル画像（注目領域の画像）
７１ 報知画面
７２～７４ フレーム（請求項における「使用者への報知の情報」）
Ｔ 時刻（所定の時刻）

【図1】

【図2】

【図3】

【図4】

【図5】

【図6】

【図7】

【図8】

【図9】

【図10】

【図11】

【図12】

【図13】

【図14】

【図15】

【図16】

【図17】

【図18】

【図19】

【図20】

【図21】