JP7663178B2

JP7663178B2 - 無人店舗の商品を管理する管理サーバ及び管理方法

Info

Publication number: JP7663178B2
Application number: JP2021093705A
Authority: JP
Inventors: 紘暉山本; 洋介宮島; 修司渡辺; 達哉水島
Original assignee: CLASSMETHOD, INC.
Current assignee: CLASSMETHOD, INC.
Priority date: 2021-06-03
Filing date: 2021-06-03
Publication date: 2025-04-16
Anticipated expiration: 2041-06-03
Also published as: JP2022185837A; WO2022254958A1

Description

本発明は、無人店舗の商品を管理する管理サーバ及び管理方法に関する。

本技術分野の背景技術として、特開２０２０－１７３８１５号公報（特許文献１）がある。この公報には、「自律店舗追跡システムにおいて、店舗１０１の商品格納エリア１０２には、商品１１１、１１２、１１３及び１１４が配置されている。カメラ１２１及び１２２は、商品格納エリア１０２並びに人が移動する店舗１０１の１つ又は複数の領域を監視する。人１０３は、時間１４１において、商品格納エリア１０２の近傍で立っている状態で監視される。」と記載されている（要約参照）。
また、関連する背景技術として、国際公開第２０１５／１７３８６９号（特許文献２）がある。この公報には、「検出部（５２）は、商品の位置に応じて設定された第１の領域内で人の手を検知した後に、第１の領域と同じ領域又は第１の領域を包含する第２の領域内で人の手が検知されず、かつ、位置に応じて設定された商品の検知領域内で商品が検知されない場合に、商品がピックアップされたことを検出する。」と記載されている（要約参照）。

特開２０２０－１７３８１５号公報国際公開第２０１５／１７３８６９号

従来技術では、無人店舗で商品を購入する顧客の動作を監視するため、店舗内に設置したカメラから撮影された画像上で画像解析を行っていた。例えば、上記特許文献１、２の開示内容では、撮影画像に対して、人体の骨格モデルに基づく画像解析を行って、顧客の全身から複数の特徴点を検出している（例えば、特許文献１の図６Ａ－Ｅ、図７Ａ－Ｂ、図１１及び図１４、並びに、特許文献２の図３等を参照）。
しかしながら、これらの特許文献では、算出された特徴点を用いるのみで、精度の高い商品ピックアップ判定を行うことができなかった。

上記課題を解決するために、例えば特許請求の範囲に記載の構成を採用する。本願は上記課題を解決する手段を複数含んでいるが、その一例を挙げるならば、商品を管理する管理システムであって、商品棚に設置された重量センサから送信された重量情報を取得する手段と、第１のカメラセンサにより撮影された画像から顧客の位置情報を取得する手段と、第２のカメラセンサにより撮影された画像から骨格検出モデルを適用することによって前記顧客の人体の特徴点を取得するとともに、前記人体の特徴点を用いて手の推定点を算出する手段と、前記顧客の位置情報と、前記算出された手の推定点と前記商品棚の位置との間の相互関係と、前記重量センサの出力の変化と、に基づいて、商品のピックアップを判定する手段と、を有することを特徴とする。

本発明によれば、カメラにより撮影された画像に対して骨格検出モデルを適用し、手の推定点を算出することで、より精度の高い商品ピックアップ判定を行うことができる。
上記した以外の課題、構成及び効果は、以下の実施形態の説明により明らかにされる。

全体の商品管理システム１の構成図の例である。管理サーバ１０１のハードウェア構成の例である。モバイル端末１０２のハードウェア構成の例である。サイネージ端末１０３のハードウェア構成の例である。カメラセンサユニット１０４、１０４ａのハードウェア構成の例である。重量センサユニット１０５のハードウェア構成の例である。無線接続で重量センサデバイスと接続したマイコン７１０と通信する接続構成の例である。有線接続で重量センサデバイス６０８と接続したマイコン７１０と通信する接続構成の例である。入店管理端末１０６のハードウェア構成の例である。決済処理サーバ１０７のハードウェア構成の例である。商品管理システム１の機能構成例を説明する図である。サイネージ表示の機能構成例を説明する図である。商品マスタ情報１３００の例である。ユーザマスタ情報１４００の例である。セグメント情報１５００の例である。取得判定範囲情報１６００の例である。位置追跡情報１７００の例である。棚イベント情報１８００の例である。見積管理情報１９００の例である。マイコン７１０からデータ集約送信器６３０へ送信される重量情報２０００の例である。商品棚設置用フレームの構成例である。商品棚の構成を説明する図である。商品の取得判定範囲を説明する模式図である。重量情報蓄積処理フロー２４００の例である。位置情報蓄積処理フロー２５００の例である。店舗における商品購入の全体処理フロー２６００の例である。入店処理フロー２７００の例である。商品判定処理フロー２８００の例である。顧客判定処理フロー２９００の例である。見積表示処理フロー３０００の例である。支払処理フロー３１００の例である。サイネージ表示処理フロー３２００の例である。ハードウェアのリファレンスモデル３３００の例である。注文管理画面の例である。商品購入画面の例である。商品管理システムの適用例である。人体の骨格の特徴の例である。撮影画像から顧客の骨格情報を検出する例である。撮影画像から顧客の骨格情報を検出する例である。撮影画像から顧客の骨格情報を検出する例である。撮影画像から顧客の骨格情報を検出するプロセスの例である。骨格検出処理フロー４２００の例である。店舗内の様子を２つのカメラから撮影した例である。２つの撮影画像から顧客の骨格情報を検出する例である。商品のピックアップの判定の例である。商品のピックアップの判定で用いられる判定基準の例である。商品のピックアップの判定の例である。商品のピックアップの判定の例である。商品のピックアップの判定の例である。商品のピックアップの判定の例である。商品のピックアップの判定の例である。商品のピックアップの判定の例である。店舗内のフロアの例である。店舗内のフロアを複数のエリアに区分けした例である。店舗内の商品棚を実際に撮影した例である。店舗内のフロアを複数のエリアに区分けした例である。店舗内の顧客を複数のカメラから追跡する例である。顧客の位置の追跡状況の例である。顧客の服装の情報を抽出する例である。顧客の位置の追跡状況の例である。顧客の位置の追跡状況の例である。撮影画像から顧客の骨格情報、位置情報及び商品の重量データを検出するプロセスの例である。商品のピックアップの判定の例である。商品のピックアップの判定の例である。図６４のフローの出力例である。

以下、実施例を図面を用いて説明する。
本実施例は、無人店舗の商品を管理する商品管理システム１を想定する。顧客は、店舗に入店する際に、顧客のモバイル端末に表示された２次元バーコードや非接触型ＩＣチップを入店管理端末にかざすことにより入店記録を行う。店舗内の商品棚に陳列された商品を手に取ることで、手に取った商品の情報や数が顧客のモバイル端末に表示され、店舗の外に出ることによって、商品の決済が完了する。
なお、無人であっても実施可能な仕組みの提供を想定するが、店舗は有人であっても構わない。

また、本実施例は、あらかじめ寸法を決めたいくつかの商品棚設置用フレームにカメラや商品棚を設置したうえで、あらかじめ登録されたいくつかのシステム初期設定を自動で実行することで、無人店舗の設置の際の店舗ごとの作り込みによる労力や時間、コストを削減することができる。

図１は、全体の商品管理システム１の構成図の例である。
商品管理システム１は、店舗内の商品棚設置用フレーム２１００内又は周辺に設置されたサイネージ端末１０３、位置検出用カメラセンサユニット１０４、骨格検出用カメラセンサユニット１０４ａ、重量センサユニット１０５、入店管理端末１０６を備え、管理サーバ１０１、決済処理サーバ１０７にネットワークを介して接続されている。この商品管理システム１にネットワーク介してモバイル端末１０２からアクセスを行う。なお、ネットワークは有線、無線を問わず、それぞれの端末はネットワークを介して情報を送受信することができる。

管理サーバ１０１は、店舗で発生する様々な事象を蓄積し、これを解析して、商品判定、顧客判定、見積表示等の処理を行う。
モバイル端末１０２は、顧客が保有するスマートフォン、タブレット、ウェアラブル端末などのモバイル端末であり、顧客が手に取った商品の情報が表示される。
カメラセンサユニット１０４は、複数のカメラデバイス５０６が接続されたカメラ管理端末５３０を有し、店舗内の顧客の移動軌跡（例えば歩行軌跡）を取得する。
カメラセンサユニット１０４ａは、複数のカメラデバイス５０６ａが接続されたカメラ管理端末５３０ａを有し、店舗内の顧客の骨格の特徴部を取得する。なお、カメラ管理端末５３０とカメラ管理端末５３０ａは別の端末としたが、１つの端末が両方の機能を備える構成であってもよい。

重量センサユニット１０５は、商品棚の商品カゴに設置された複数の重量センサデバイス６０８と、マイコン７１０とデータ集約送信器６３０を有し、重量の変化を検知して重量情報を管理サーバ１０１に送信する。
入店管理端末１０６は、顧客の保有するモバイル端末に表示された２次元バーコードや非接触型ＩＣチップを読み取り、顧客のユーザ情報を特定する。
決済処理サーバ１０７は、管理サーバ１０１から顧客の取得した商品に対する決済処理依頼を受信し、顧客のユーザ情報に対応付けられた決済方法により決済処理を実行する。

商品管理システム１のそれぞれの端末や管理サーバ１０１は、例えば、スマートフォン、タブレット、携帯電話機、携帯情報端末（ＰＤＡ）などの携帯端末（モバイル端末）でもよいし、メガネ型や腕時計型、着衣型などのウェアラブル端末でもよい。また、据置型または携帯型のコンピュータや、クラウドやネットワーク上に配置されるサーバでもよい。また、機能としてはＶＲ（仮想現実感：Virtual Reality）端末、ＡＲ（拡張現実感：AugmentedReality）端末、ＭＲ（複合現実感：Mixed Reality）端末でもよい。あるいは、これらの複数の端末の組合わせであってもよい。例えば、１台のスマートフォンと１台のウェアラブル端末との組合せが論理的に一つの端末として機能し得る。またこれら以外の情報処理端末であってもよい。

商品管理システム１のそれぞれの端末や管理サーバ１０１は、それぞれオペレーティングシステムやアプリケーション、プログラムなどを実行するプロセッサと、ＲＡＭ（Random Access Memory）等の主記憶装置と、ＩＣカードやハードディスクドライブ、ＳＳＤ（Solid State Drive）、フラッシュメモリ等の補助記憶装置と、ネットワークカードや無線通信モジュール、モバイル通信モジュール等の通信制御部と、タッチパネルやキーボード、マウス、音声入力、カメラ部の撮像による動き検知による入力などの入力装置と、モニタやディスプレイ等の出力装置とを備える。なお、出力装置は、外部のモニタやディスプレイ、プリンタ、機器などに、出力するための情報を送信する装置や端子であってもよい。

主記憶装置には、各種プログラムやアプリケーションなど（モジュール）が記憶されており、これらのプログラムやアプリケーションをプロセッサが実行することで全体システムの各機能要素が実現される。なお、これらの各モジュールは集積化する等によりハードウェアで実装してもよい。また、各モジュールはそれぞれ独立したプログラムやアプリケーションでもよいが、１つの統合プログラムやアプリケーションの中の一部のサブプログラムや関数などの形で実装されていてもよい。
本明細書では、各モジュールが、処理を行う主体（主語）として記載をしているが、実際には各種プログラムやアプリケーションなど（モジュール）を処理するプロセッサが処理を実行する。

補助記憶装置には、各種データベース（ＤＢ）が記憶されている。「データベース」とは、プロセッサまたは外部のコンピュータからの任意のデータ操作（例えば、抽出、追加、削除、上書きなど）に対応できるようにデータ集合を記憶する機能要素（記憶部）である。データベースの実装方法は限定されず、例えばデータベース管理システムでもよいし、表計算ソフトウェアでもよいし、ＸＭＬ、ＪＳＯＮなどのテキストファイルでもよい。データベース管理システムで実装する場合には、リレーショナルデータベース（ＲＤＢＭＳ）であってもよいし、非リレーショナルデータベース（非ＲＤＢＭＳ）であってもよい。

図２は、管理サーバ１０１のハードウェア構成の例である。
管理サーバ１０１は、例えばクラウド上に配置されたサーバで構成される。
主記憶装置２０１には、各種モジュール（プログラムやアプリケーション）２１０が記憶されており、これらのプログラムやアプリケーションをプロセッサ２０３が実行することで管理サーバ１０１の各機能要素が実現される。
それぞれのモジュール及びその処理については後述する。

補助記憶装置２０２は、マスタＤＢ２２０及び各種情報記憶ＤＢ２２１を備える。
マスタＤＢ２２０は、ユーザマスタ情報１４００や商品マスタ情報１３００等を記憶する。
各種情報記憶ＤＢ２２１は、カメラセンサユニット１０４、カメラセンサユニット１０４ａ、重量センサユニット１０５、及び入店管理端末１０６から送信される情報を記憶する、又は管理サーバ１０１内で処理、加工された各種情報を記憶する。
それぞれ記憶される情報については後述する。

図３は、モバイル端末１０２のハードウェア構成の例である。
モバイル端末１０２は、例えばスマートフォン、タブレット等の端末で構成される。
主記憶装置３０１には、商品購入管理モジュール３１０等のプログラムやアプリケーションが記憶されており、これらのプログラムやアプリケーションをプロセッサ３０３が実行することでモバイル端末１０２の各機能要素が実現される。

商品購入管理モジュール３１０は、管理サーバ１０１の見積表示モジュール１１０６やモバイル購入管理モジュール１１０８等と連携し、商品の購入画面を表示したり、購入履歴を表示したりする。
補助記憶装置３０２は、モバイル端末１０２に記憶されているユーザ管理情報３２０を記憶する。

図４は、サイネージ端末１０３のハードウェア構成の例である。
サイネージ端末１０３は、例えばスマートフォン、タブレット、ノートＰＣ、デスクトップＰＣ、マイクロコンピュータ、シングルボードコンピュータ等の端末で構成される。シングルボードコンピュータとしては、例えばRaspberry Piを用いることができる。
主記憶装置４０１には、サイネージ情報表示モジュール４１０等のプログラムやアプリケーションが記憶されており、これらのプログラムやアプリケーションをプロセッサ４０３が実行することでサイネージ端末１０３の各機能要素が実現される。

補助記憶装置４０２は、表示する商品の広告などのサイネージ情報４２０を記憶する。
サイネージ情報表示モジュール４１０は、管理サーバ１０１のサイネージ処理モジュール１２０２から表示指示を受信し、表示指示に対応するサイネージ情報４２０をディスプレイや電子ペーパー等の出力装置４０５に表示する。
又は、管理サーバ１０１から送信されるサイネージ情報を受信して表示する構成であってもよい。

図５の（Ａ）は、位置検出用カメラセンサユニット１０４のハードウェア構成の例である。
複数のカメラデバイス５０６がネットワークを介してカメラ管理端末５３０と接続されている。カメラ管理端末５３０は、例えばデスクトップＰＣ、マイクロコンピュータ、シングルボードコンピュータ、クラウド上のサーバ等で構成される。
主記憶装置５０１には、軌跡管理モジュール５１０等のプログラムやアプリケーションが記憶されており、これらのプログラムやアプリケーションをプロセッサ５０３が実行することでカメラ管理端末５３０の各機能要素が実現される。
図５の（Ｂ）は、骨格検出用カメラセンサユニット１０４ａのハードウェア構成の例である。
複数のカメラデバイス５０６ａがネットワークを介してカメラ管理端末５３０ａと接続されている。カメラ管理端末５３０ａは、例えばデスクトップＰＣ、マイクロコンピュータ、シングルボードコンピュータ、クラウド上のサーバ等で構成される。
主記憶装置５０１aには、骨格検出モジュール５１０ａ等のプログラムやアプリケーションが記憶されており、これらのプログラムやアプリケーションをプロセッサ５０３aが実行することでカメラ管理端末５３０ａの各機能要素が実現される。

なお、カメラデバイス５０６はＴＯＦ（Time of Flight）センサを含む。ＴＯＦセンサは光源から発した光が対象物で反射し、センサに戻ってくるまでの光の飛行時間（時間差）を検出することにより、対象物までの距離を測定するセンサである。ＴｏＦ方式のイメージセンサにより、画素ごとに距離情報を検出し、高精度な距離画像を取得することもできる。
また、複数のＴｏＦセンサやカメラを用いることにより、対象物の形状や３次元的な重なりをより高精度に判定することが可能となる。例えば、複数の顧客が同時に店舗内にいる場合のそれぞれの人物の重なりを判定したり、手の移動を検知したりすることができる。

複数のカメラデバイス５０６による計測の場合、正しく移動軌跡を取得し、対象物の形状を特定するためには、それぞれのカメラの設置位置や設置角度を正しく計測し、細やかな設定の調整（キャリブレーション）が必要となる。しかしながら、本実施例においては、あらかじめ標準化された商品棚設置用フレーム２１００の、あらかじめ定められた位置にカメラデバイス５０６を設置し、それらのカメラの設定を管理サーバ１０１側から一括で設定する構成をとることにより、初期設定の簡素化、効率化及び、軌跡情報の取得精度の向上を実現している（図２１参照）。複数のカメラデバイス５０６ａについても同様に構成することができる。

軌跡管理モジュール５１０は、複数のカメラデバイス５０６から取得した画像情報や、対象物までの距離情報などを集約し、解析を実行することで、対象物までの距離や対象物の形状、対象物の位置を特定する。位置検出モジュール５１０と呼ぶこともある。
また、この距離情報を時系列に蓄積することにより、センサ取得範囲における顧客の移動軌跡を取得し、軌跡情報５２０に蓄積する。具体的には、軌跡管理モジュール５１０は、複数のカメラデバイス５０６が軌跡を検知し始めた場合に、検知した人物に対して人物ＩＤを付し、この人物の各時刻における位置情報を時系列に軌跡情報５２０に記憶する。これらの時系列情報を繋ぎ合わせることにより、特定の人物ＩＤに対応する人物の移動軌跡を取得することができる。

軌跡管理モジュール５１０は、移動軌跡を再現するための人物ＩＤと時刻情報と当該時刻における位置情報とを管理サーバ１０１に送信する。若しくは、これらをまとめた軌跡情報を管理サーバ１０１に送信する。
骨格検出モジュール５１０ａは、複数のカメラデバイス５０６ａから取得した画像情報に対して画像解析を行って、人体の骨格モデルに基づいて特徴部を抽出し、特徴部情報５２０ａに蓄積する。さらに、骨格検出モジュール５１０ａは、検出した特徴部に基づいて、他の特徴部を演算により求めて、特徴部情報５２０ａに蓄積してもよい。
骨格検出モジュール５１０ａは、顧客の特徴部の情報を管理サーバ１０１に直接送信してもよい。または、骨格検出モジュール５１０ａは、顧客の特徴部の情報をカメラ管理端末５３０の軌跡管理モジュール５１０に送信し、軌跡管理モジュール５１０側で検出した情報と顧客の特徴部の情報とを統合した後、カメラ管理端末５３０の軌跡管理モジュール５１０が管理モジュール管理サーバ１０１に送信してもよい。

図６は、重量センサユニット１０５のハードウェア構成の例である。
複数の重量センサデバイス６０８がマイコン（マイクロコントローラ）７１０を介してデータ集約送信器６３０と接続されている。データ集約送信器６３０は、例えばデスクトップＰＣ、マイクロコンピュータ、シングルボードコンピュータ、クラウド上のサーバ等で構成される。シングルボードコンピュータとしては、例えばRaspberry Piを用いることができる。
主記憶装置６０１には、マイコン７１０から受信した重量情報を処理し、管理サーバ１０１に送信するための各種モジュール６１０等のプログラムやアプリケーションが記憶されており、これらのプログラムやアプリケーションをプロセッサ６０３が実行することでデータ集約送信器６３０の各機能要素が実現される。
補助記憶装置６０２は、データ集約送信器６３０やマイコン７１０、重量センサデバイス６０８の設定情報や管理情報等のＩｏＴ機器管理情報６２０を記憶する。

図７は、無線接続で重量センサデバイス６０８と接続したマイコン７１０と通信する接続構成の例である。
商品棚には複数の重量センサデバイス６０８が設置されており、それぞれ重量センサデバイス６０８の上には商品カゴが設置されている。重量センサデバイス６０８は、商品カゴに乗せられた商品等の重量を測定し、またその重量の変化を検知するデバイスである。取得された重量データはＡ／Ｄ変換器７２０によりデジタル情報に変換され、マイコン７１０に送信される。
マイコン７１０は、受信した重量情報をＢｌｕｅｔｏｏｔｈ（登録商標）等の無線通信を利用してデータ集約送信器６３０に送信する。

図２０は、マイコン７１０からデータ集約送信器６３０へ送信される重量情報２０００の例である。
重量情報２０００は、項目２０２０に示す各項目の情報を有しており、フィールド名２０３０として例えばサンプル値２０４０のような値を有している。
重量情報２０００は、商品カゴＩＤ２００１、データ種別、重量２００２、送信回数、状態２００３、起動後経過時間、前回重量２００４、遅延時間２００５、状態変化有無２００６等の項目を有する。

商品カゴＩＤ２００１は、重量センサデバイス６０８毎に設定されるＩＤである。商品カゴに入れられた商品の商品ＩＤ１５０２と対応付けられており、重量２００２の変化と、商品カゴＩＤ２００１に対応付けられた商品ＩＤ１５０２から、どの商品が何個商品カゴから取り出されたのかを算出することができる。
重量２００２は商品カゴの中の重量をグラム単位で表示する。測定値からは商品カゴの重量が除かれた、内容物の重量を表示し、内容物が無い状態では０を示す。但し、商品カゴの重量が含まれる構成としても構わない。
送信回数は、マイコン７１０起動からのデータの送信回数を示す。送信回数を逐次カウントアップし、メモリがオーバーフローした場合には値を０に戻す。

状態２００３は、重量センサデバイス６０８の状態を示す。測定した重量データが安定していないUNSTABLE状態であった場合には０を、重量データが安定しているSTABLE状態である場合には１を示す。
起動後経過時間は、マイコン７１０起動時からの経過時間をミリ秒単位で表示する。１ミリ秒毎にカウントアップし、メモリがオーバーフローした場合には値を０に戻す。
前回重量２００４は、前回測定時の重量をグラム単位で表示する。遅延時間２００４は、状態２００３がUNSTABLEからSTABLEに変化するまでの時間をミリ秒単位で表示する。
状態変化有無２００６は、前回の測定から状態２００３が変化したかどうかを示すフラグである。前回の測定から状態２００３が変化した場合は１を、変化していない場合は０を示す。

マイコン７１０は、重量センサデバイス６０８から受信した重量に変化が見られた場合に、状態２００３に「UNSTABLE状態」を示す０をセットし、状態変化有無２００６が「有り」を示す１をセットした重量２００２を含む重量情報２０００をデータ集約送信器６３０に送信する。
マイコン７１０は、重量センサデバイス６０８からの重量データを常時受信するが、重量に変化が無い場合（変化量が閾値を超えない場合）には、１０秒毎など定期的に重量データをデータ集約送信器６３０に送信する。この場合には、状態２００３に「STABLE状態」を示す１をセットし、状態変化有無２００６が「無し」を示す０をセットした重量２００２を含む重量情報２０００をデータ集約送信器６３０に送信する。

重量の変化があるかどうかは、重量２００２の平均値（例えば過去１０回分の値の平均値）と新たに取得した値との偏差から判定する。例えば、安定状態（状態２００３がSTABLE）から偏差が閾値（例えばσ＝±１．０）より大きい変化が生じた場合に変化があったと判定し、状態２００３をUNSTABLEに変更する。また、この際、状態変化有無２００６は「有り」を示す１となる。逆に、商品を取り上げたタイミングなど、一度UNSTABLE状態になった場合には、同様に平均値と新たに取得した値との偏差を算出し、偏差が閾値以下かつ、平均値を取得した回数が３回以上となった場合はSTABLE状態に変更する。マイコン７１０は、状態２００３が、「UNSTABLE」から「STABLE」に変化した場合に、その重量２００２を含む重量情報２０００をデータ集約送信器６３０に送信する。

状態変化有無２００６は、前回の測定と新たな測定との状態２００３が「STABLE」から「UNSTABLE」に変化した場合、または「UNSTABLE」から「STABLE」に変化した場合には、変化したことを示す１をセットする。
ここで、平均値からの偏差を用いる場合の他、単に前回重量と最新の重量との間の差分が、所定の閾値、例えば５ｇを超えた場合を状態が変化した場合としてもよい。
また、同様に、単に前回重量と最新の重量との間の差分が所定の閾値、例えば５ｇ以下の場合に、重量データが安定しているSTABLE状態であると判定してもよい。

本実施例では、マイコン７１０は、重量センサデバイス６０８から常時重量データを受信しているが、上述の通り、重量の変化のない場合には例えば１０秒毎に重量情報２０００をデータ集約送信器６３０に送信する。
また、商品を取り上げた場合など、重量に変化が生じた場合には、そのタイミングで第１回目の重量情報２０００が送信され、その重量が安定した後に第２回目の重量情報が送信されるようにしている。

例えば、商品カゴから商品を取り上げる場合を想定すると、顧客が商品を手に取る一瞬、商品を下に押し下げる力が働き、一瞬重量が増加することがある。その後商品を取り上げると、商品の重さ分重量が減少する。
また、商品を取り上げた瞬間に重量が安定するわけではなく、重量の値が振動し、数ミリ秒から数秒してから重量の値が安定する。
本実施例では、このように重量の変化が発生した時刻と、その値が安定する時刻との間に遅延が発生することを考慮し、重量情報を２回送ることで２段階の処理を実施することを可能にする。

例えば、１回目の重量情報２０００の送信に応じてサイネージ端末１０３へのサイネージ表示処理３２００を実行することで、商品を手に取った場合に、その商品に関する説明や、合わせて買ってもらいたい商品の広告情報などを、遅延なくすぐにサイネージ端末１０３に表示することができる。
一方、重量が安定した後の数値に基づく２回目の重量情報２０００の送信に応じて、商品判定処理２８００を実行することで、手に取った商品の数を正しく計測することができる。

また、重量が安定している場合の１０秒毎の重量情報２０００に基づいて、それぞれの商品の数を算出し、在庫管理に用いることもできる。
例えば、本実施例では商品のあるべき場所と数量を把握しているため、商品が無くなりそうになれば欠品予報を送信しバックヤードのスタッフに商品補充を促す、商品があるべき位置にない場合はレイアウトアラートを送信しバックヤードのスタッフに再配置を促す
、等の在庫管理が可能となる。
また、商品カゴ内に１０個など所定の数の商品を配置して販売を開始し、例えば３個等の所定の数以下となった場合に、商品ＩＤ（又は商品カゴＩＤ）と共に現在の個数３個と最初の個数１０個との差分の７個を通知し、この通知に基づいてその商品を７個ロボットやコンベア等の仕組みにより自動的に補充する仕組みとしてもよい。

重量情報２０００を受信したデータ集約送信器６３０は、受信した情報をＭＱＴＴプロトコルなどの所定のプロトコルに変換して、暗号化したうえで、管理サーバ１０１に送信する。
各重量情報２０００には時刻情報を付加することもできる。この場合に、データ集約送信器６３０がデータを送信する時刻情報を重量情報２０００に含めて送信してもよいし、マイコン７１０が重量情報２０００をデータ集約送信器６３０に送信する際に、時刻情報を含める構成としてもよい。
ここで、重量情報２０００に含まれる時刻情報でデータを並べることで重量時系列データを生成することができる。

データ集約送信器６３０は、管理サーバ１０１から受信した制御情報に基づいて、マイコン７１０及び重量センサデバイス６０８の制御や初期設定を行うことができる。例えば電源のオンオフを切り替えたり、設定情報を追記又は更新したりすることが可能である。

図８は、有線接続で重量センサデバイス６０８と接続したマイコン７１０と通信する接続構成の例である。
マイコン７１０は複数の重量センサデバイス６０８とＡ／Ｄ変換器７２０を介して有線で接続されている。また、マイコンはデータ集約送信器６３０とも優先で接続されており、ＣＡＮ（Controller Area Network）により通信を行う。
トランシーバ７３０、７３１は、互いにＣＡＮ方式でデータの送受信を行い、デイジーチェーンで接続されたコントローラ７４０がＣＡＮ方式による通信を制御する。

マイコン７１０はＵＳＢ又はＣＡＮ経由で給電することができる。
図７と同様に、マイコンは重量情報２０００をデータ集約送信器６３０に送信し、データ集約送信器６３０は制御情報をマイコン７１０に送信する。
有線接続では、無線接続により通信が不安定になることや、通信の遅延が発生することを避けることができる。

図９は、入店管理端末１０６のハードウェア構成の例である。
入店管理端末１０６は、例えばスマートフォン、タブレット等の端末や、２次元バーコードや非接触型ＩＣチップを読み取る専用端末で構成される。
主記憶装置９０１には、入店管理モジュール９１０等のプログラムやアプリケーションが記憶されており、これらのプログラムやアプリケーションをプロセッサ９０３が実行することで入店管理端末１０６の各機能要素が実現される。

入店管理モジュール９１０は、カメラ部９０６により顧客のモバイル端末１０２に表示された２次元バーコードを読み取る、又は、入力装置９０４により顧客のモバイル端末１０２の非接触型ＩＣチップと通信することにより、ユーザ特定情報を受信する。
入店管理モジュール９１０は、ユーザが入店した情報としてユーザ特定情報を管理サーバ１０１に送信する。この際、ユーザ特定情報を受信した日時を入店時刻として、管理サーバ１０１に送信してもよい。
補助記憶装置９０２は、入店管理端末管理情報９２０を記憶する。ここには、入店処理を行った場合に取得したユーザ特定情報や時刻情報を記憶してもよい。

なお、入店時の情報入力は、２次元バーコード等のバーコードによる読み取りや、モバイル端末１０２の非接触型ＩＣチップによる通信の他、電子マネーや非接触型ＩＣカード、磁気情報の読み取りなどによって実行されてもよい。
この場合、入店の仕方によって退店時の退店ゲートでの動作を変えることが可能である。例えば、モバイル端末１０２上のアプリの２次元バーコードや非接触型ＩＣチップによる入店の場合には、退店ゲートが自動で開いてアプリ上のクレジットカード決済が実行される。
退店時に手に取った商品に関して２次元バーコードを印刷し、この印刷物を自動決済機で読み取らせることで、ゲストユーザもクレジットカードや電子マネーや現金で決済できるようにしてもよい。

図１０は、決済処理サーバ１０７のハードウェア構成の例である。
決済処理サーバ１０７は、例えばクラウド上に配置されたサーバで構成される。
主記憶装置１００１には、決済処理実行モジュール１０１０が記憶されており、これらのプログラムやアプリケーションをプロセッサ１００３が実行することで決済処理サーバ１０７の各機能要素が実現される。

決済処理実行モジュール１０１０は、モバイル端末１０２による商品購入や、店舗による商品購入に対して、決済処理を実行する。実行された決済結果はモバイル端末１０２に送信され、商品購入管理モジュール３１０と連携し出力装置３０５である画面に表示される。
補助記憶装置１００２は、決済処理に必要な個人情報やユーザ情報、クレジットカード情報や、決済履歴等の決済処理情報１０２０を記憶する。

図１１は、商品管理システム１の機能構成例を説明する図である。
管理サーバ１０１は、重量情報処理モジュール１１０１、位置情報処理モジュール１１０２、骨格検出処理モジュール１１０２ａ、入退店管理モジュール１１０３、商品判定モジュール１１０４、顧客個数判定モジュール１１０５、見積表示モジュール１１０６、支払管理モジュール１１０７、モバイル購入管理モジュール１１０８、等のプログラムやアプリケーションである各種モジュール２１０を記憶しており、各種処理を実行する。
また、管理サーバ１０１は、各種センサから受信した情報や、管理サーバ１０１で生成した情報を記憶するセグメント情報１５００、取得判定範囲情報１６００、位置追跡情報１７００、骨格検出情報１７００ａ、棚イベント情報１８００、見積管理情報１９００、入店情報１１１１等を有する。

各種モジュール２１０は、一つの管理サーバ１０１上に配置されるように記載しているが、これらはそれぞれクラウド上の別の仮想サーバ上に配置する構成としてもよいし、これらのうちの一部のグループ毎に、仮想サーバ上に配置する構成としてもよい。
また、各種情報も、クラウド上のそれぞれ別の記憶装置上に記憶する構成としてもよいし、これらのうちの一部のグループ毎に、クラウド上に配置する構成としてもよい。

重量情報処理モジュール１１０１は、重量センサユニット１０５から商品カゴＩＤを含む重量情報を受領し、重量情報に対応する時刻情報と共に蓄積する。
重量情報蓄積処理フローについては図２４で後述する。

位置情報処理モジュール１１０２は、カメラセンサユニット１０４から移動軌跡を再現するための人物ＩＤと時刻情報と当該時刻における位置情報とを受信する。
位置情報処理モジュール１１０２は、受信した位置情報に基づき、人物が滞在した範囲を特定し、特定した滞在範囲の情報を時刻情報と共に蓄積する。
位置情報蓄積処理フローについては図２５で後述する。

骨格検出処理モジュール１１０２ａは、カメラセンサユニット１０４ａから店舗内の人物の様子を撮影した撮影画像と時刻情報とを受信する。
骨格検出処理モジュール１１０２ａは、人物の上半身の所定の特徴点（手の推定点）を演算により求めることができる。この情報を用いることで、管理サーバ１０１は、手の推定点と商品棚の位置との対応関係を判定することができる。
骨格検出処理フローについては図４２で後述する。

入退店管理モジュール１１０３は、入店管理端末１０６の入店管理モジュール９１０から、顧客のユーザ特定情報を受信し、受信したユーザ特定情報がどのユーザＩＤに対応するかを特定し、情報を受信した時刻情報と共に入店情報１１１１に記憶する。
なお、顧客のモバイル端末１０２に表示されたバーコードを読み取った時刻又は非接触型ＩＣチップから非接触通信により情報を取得した時刻を、情報を受信した時刻情報の代わりに又は併せて記憶してもよい。
入店処理フローについては図２７で後述する。

商品判定モジュール１１０４は、棚イベント情報１８００に蓄積された情報に基づいて、顧客が手に取った商品及びその個数を判定する。
商品判定処理フローについては図２８で後述する。

顧客個数判定モジュール１１０５は、棚イベント情報１８００、位置追跡情報１７００及び骨格検出情報１７００ａに蓄積された情報に基づいて、重量の変化が発生した（イベントが発生した）時刻に、変化が発生した棚のそばにいた顧客を特定する。その際、どの顧客が、商品をいくつピックアップしたのかについて判定する。
顧客個数判定処理フローについては図２９で後述する。

見積表示モジュール１１０６は、入店処理、商品判定処理及び顧客判定処理の結果を突き合わせ、顧客のモバイル端末１０２に手に取った商品の内容及び個数とその金額を表示する。
見積表示処理フローについては図３０で後述する。

支払管理モジュール１１０７は、見積処理実行後、顧客が退店した場合に決済処理の実行を決済処理サーバ１０７に依頼する。
支払処理フローについては図３１で後述する。

モバイル購入管理モジュール１１０８は、モバイル端末１０２の商品購入管理モジュール３１０から直接オンラインオーダーを行う場合に、オーダーを受け付ける。
モバイル購入管理モジュール１１０８は、ユーザから商品の選択、個数の選択を受け付けると、商品マスタ情報１３００に基づいて、合計金額を算出し、モバイル端末１０２に表示する。
その後、注文の依頼を受け付けると、支払管理モジュール１１０７が、合計金額及び対応するユーザＩＤ等のユーザ情報を決済処理サーバ１０７に送信し、決済処理サーバ１０７が決済処理を実行する。

図１２は、サイネージ表示の機能構成例を説明する図である。
管理サーバ１０１のＩｏＴ情報処理モジュール１２０１は、ＭＱＴＴフォーマットに従って送信された重量情報を受信する。なお、ＩｏＴ情報処理モジュール１２０１は図１１の重量情報処理モジュール１１０１の前段に配置されている。安定状態から重量の変化が発生した場合に、データ集約送信器６３０により重量が変化した第１時刻と、その値が安定した第２の時刻の２回に分けて重量情報が送信される。

ＩｏＴ情報処理モジュール１２０１は、１回目の重量情報を受信した場合に、その重量情報をサイネージ処理モジュール１２０２に転送する。なお、重量情報をそのまま転送しなくとも、重量情報に含まれる商品カゴＩＤを通知する構成としてもよい。
ＩｏＴ情報処理モジュール１２０１は、２回目の重量情報を受信した場合に、その重量情報を商品や商品数の特定のために図１１の重量情報処理モジュール１１０１に転送する。
なお、ＩｏＴ情報処理モジュール１２０１がそれぞれの重量情報を振り分ける構成であるが、１回目の重量情報はサイネージ処理モジュール１２０２及び重量情報処理モジュール１１０１の両方に送信し、棚イベント情報１８００にいずれの重量情報も記憶する構成としてもよい。

なお、本実施例は、ＩｏＴ情報処理モジュール１２０１がＭＱＴＴブローカーとしてＭＱＴＴ形式で送信される重量情報を受信し、これをサブスクライブするサイネージ処理モジュール１２０２又は重量情報処理モジュール１１０１に振り分ける構成であるが、重量センサユニット１０５が、あらかじめ異なる宛先に１回目の重量情報と２回目の重量情報とを振り分ける構成としてもよい。

また、ＩｏＴ情報処理モジュール１２０１の振り分けは、安定後の受信回数が１回目か２回目かに応じて振り分けることとしてもよいし、重量情報に含まれる状態変化有無２００６や、状態２００３のフラグに基づいて、振り分けを実行する構成としてもよい。
この場合、例えば、状態変化有無２００６が「変化有」で状態２００３が「不安定」になった場合には１回目の重量情報であると判断する。状態変化有無２００６が「変化有」で状態２００３が「安定」になった場合には２回目の重量情報であると判断する。
又は、重量の変化が生じたことを示すフラグである状態変化有無２００６のみに基づいて判断してもよい。例えば状態変化有無２００６が重量の変化が生じたことを示す「変化有」になった場合に、第１回目の情報であるとして重量情報をサイネージ処理モジュール１２０２に重量情報を送付することとしてもよい。

図１３～図１９は管理サーバ１０１の補助記憶装置２０２の各種情報記憶ＤＢ２２１に記憶されている情報である。
図１３は、商品マスタ情報１３００の例である。
商品マスタ情報１３００は、項目１３２０に示す各項目の情報を有しており、フィールド名１３３０として例えばサンプル値１３４０のような値を有している。
商品マスタ情報１３００は、在庫有無、商品イメージ、商品ＩＤ１３０１、商品名１３０２、価格１３０３、優先度、原価、税額、販売タイプ、重量１３０４、サイネージ情報１３０５等の項目を有する。
商品ＩＤ１３０１はキーとして使われ、商品名１３０２を特定するためや、商品ＩＤ１３０１に対応するサイネージ情報１３０５を表示するために使用することができる。
重量１３０４は、重量センサユニット１０５が取得した重量の変化量に対して、その商品が何個分商品カゴから取り上げられたのかを計算する際に使用される。

図１４は、ユーザマスタ情報１４００の例である。
ユーザマスタ情報１４００は、項目１４２０に示す各項目の情報を有しており、フィールド名１４３０として例えばサンプル値１４４０のような値を有している。
ユーザマスタ情報１４００は、ユーザＩＤ１４０１、ユーザ表示ＩＤ、名前、メールアドレス、生年月日、性別、ユーザ特定情報１４０２等の項目を有する。
ユーザＩＤ１４０１は、ユーザを特定する情報であり、このユーザＩＤ１４０１に対応付けて各ユーザのモバイル端末１０２が管理されており、ユーザＩＤ１４０１に基づいて当該ユーザのモバイル端末１０２上に購入商品の見積もり情報等を表示することができる。
ユーザ特定情報１４０２は、ユーザを特定する際に用いられる情報で、例えば、セキュリティを考慮して定期的に更新されるトークン（ハッシュ値）等の値である。

図１５は、セグメント情報１５００の例である。
セグメント情報１５００は、項目１５２０に示す各項目の情報を有しており、フィールド名１５３０として例えばサンプル値１５４０のような値を有している。
セグメント情報１５００は、商品カゴＩＤ１５０１と商品ＩＤ１５０２とを対応付ける情報である。
このセグメント情報１５００によって、重量センサユニット１０５から受信した重量情報に含まれる商品カゴＩＤから、商品ＩＤを特定し、どの商品を取り上げたことによって重量が変化したのかを把握することができる。

本実施例では、棚の商品カゴに商品を登録する設定を簡単に行うことができる。最初に何も商品が乗っていない状態の設定を受け付ける。次にサイネージ端末１０３に例えば「１つ商品を商品カゴに載せてください」というようなインストラクションを表示し、１つ商品を商品カゴに載せてもらう。
重量センサユニット１０５は、商品１つの重量を取得し、管理サーバ１０１に送信する。管理サーバ１０１の商品判定モジュール１１０４は、商品マスタ情報１３００に登録されている複数の商品から、重量１３０４が測定した重量に近い候補を近い順に商品棚のそばにあるサイネージ端末１０３にリスト表示し、「リストから商品カゴに載せた商品を選択してください」というようなインストラクションを表示する。

管理者は、その表示されたリストの中から実際に商品カゴに載せた商品と同じ情報を選択する。この選択に応じて、商品判定モジュール１１０４は、商品を載せた商品カゴのある商品カゴＩＤ１５０１と、商品ＩＤ１５０２との対応付けを行い、セグメント情報１５００に記憶する。
リストから選択する形ではなく、自動的に重さが最も近い商品と対応付ける構成としてもよい。
次に、サイネージ端末１０３に「３つの商品を商品カゴに載せてください」というようなインストラクションを表示する。３つの商品の重量情報から平均重量を算出し、商品判定モジュール１１０４は、商品増減時の重み誤差を自動で設定する。

図１６は、取得判定範囲情報１６００の例である。
取得判定範囲情報１６００は、項目１６２０に示す各項目の情報を有しており、フィールド名１６３０として例えばサンプル値１６４０のような値を有している。
取得判定範囲情報１６００は、商品カゴ毎に、商品カゴから商品を取れる範囲を規定する情報である。
取得判定範囲情報１６００は、商品カゴＩＤ１６０１、判定エリア１６０２、判定滞在範囲１６０３を有する。
商品カゴＩＤ１６０１は、重量センサユニット１０５の重量センサデバイス６０８と対応付けられており、どの商品カゴから商品を取った結果、重量に変化があったのかを特定することができる。
判定エリア１６０２は、商品カゴＩＤ１６０１に対応付けられた商品を取れる範囲を商品棚設置用フレーム２１００の中の座標で示したものである（図２１参照）。
判定滞在範囲１６０３は、商品カゴＩＤ１６０１に対応付けられた商品を取れる範囲をあらかじめ区切った区画単位で示したものである。

取得判定範囲について図２１～図２３を用いて説明する。
図２１は、商品棚設置用フレームの構成例である。
本実施例は、あらかじめ寸法を決めた商品棚設置用フレームにカメラや商品棚を設置したうえで、あらかじめ登録されたいくつかのシステム初期設定を自動で実行することで、無人店舗の設置の際の店舗ごとの作り込みによる労力や時間、コストを削減することができる。
商品棚設置用フレーム２１００は、例えば、縦横２．５ｍ、高さ３ｍの櫓状のフレームである。４本の支柱２１０１又はその近傍（例えば梁２１０２）のあらかじめ決められた位置にカメラデバイス５０６が設置されている。もしくは、この位置にカメラデバイス５０６を設置できるようにカメラデバイス５０６の取付部を有していてもよい。

フレームの一本の支柱２１０１を座標（０，０）とし、そこからｘ、ｙ方向にミリメートル単位で座標平面を規定する。図の例では、左下の支柱の座標が（０，０）、右下の支柱の座標が（２５００，０）となり、右奥の支柱の座標が（２５００，２５００）となる。
この中の所定の位置に商品棚を設置することで、カメラセンサユニット１０４、重量センサユニット１０５の設定を半自動化する。

図２２は、商品棚の構成を説明する図である。
商品棚を正面から見た図２２の２２００において、一つの商品棚２２０１には、３×３個の商品カゴ２２０２が設置されている。このそれぞれの商品カゴの下には重量センサデバイス６０８が設置され、それぞれの商品カゴの中の重量を測定している。
商品棚のサイズは横幅×奥行き×高さが４５０×５００×１５００ｍｍのサイズを想定する。本実施例ではこのサイズ以外にもあらかじめいくつかの商品棚のサイズが準備されており、この規定のサイズから商品棚を選択することで、管理サーバ１０１から設定情報がカメラセンサユニット１０４及び重量センサユニット１０５に送付され、設定が半自動的に完了する仕組みになっている。
商品棚を左横から見た図２２の２２５０において、商品棚２２５１の前には商品を取得できる仮想の取得エリア２２５２を設定する。仮想の取得エリアは顧客が商品に手を伸ばせる範囲と同じ商品棚の先端から７６０ｍｍを規定している。

図２３は、商品の取得判定範囲を説明する模式図である。
商品棚設置用フレーム２１００を上から見た図２３の２３００には、図２１と同じ座標が表示されており、左下の支柱２１０１の座標を（０，０）とし、右上の支柱２１０１を（２５００，２５００）とする。
図２３の手前部分にはＡＳ０１～ＡＳ０４の４つの商品棚２３０１が設置されている。商品棚の先端からｙ軸方向に７６０ｍｍであって、ｘ軸方向に商品棚２３０１の幅４５０ｍｍ毎の範囲を、１つの領域とすると、ある商品棚の正面の１つ及び左側２つと右側２つまでの領域を顧客が商品を取得できる範囲、つまり取得判定範囲として規定する。

例えば、ＡＳ０２の商品棚２３５１の取得判定範囲２３５２は、Ａ０、Ａ１、Ａ２、Ａ３、Ａ４の範囲になる。同様に、ＡＳ０１の商品棚の取得判定範囲は、Ａ０、Ａ１、Ａ２、Ａ３の範囲になり、ＡＳ０４の商品棚の取得判定範囲は、Ａ２、Ａ３、Ａ４、Ａ５の範囲になる。商品カゴ毎の取得判定範囲は図１６の取得判定範囲情報１６００に記憶されている。例えば商品棚ＡＳ０２の上から２つ目の商品カゴには商品カゴＩＤ１５０１としてＡＳ０２＿Ｂが記憶されており、この商品カゴに対応する判定エリア１６０２は、座標（０，５００）（０，１２６０）（２１５０，１２６０）（２１５０，５００）で囲まれた部分である。

また、座標の他に、店舗内または商品棚設置用フレーム２１００内をあらかじめ区切った区画で表すこともでき、商品棚ＡＳ０２の場合、判定滞在範囲１６０３は図２３のＡ０～Ａ４の部分に対応する。ここで１区画は４５０ｍｍ×７６０ｍｍの範囲としている。
商品取得範囲は、本実施例ではｘ、ｙ軸の平面範囲内としているが、商品カゴＩＤは、例えばＡＳ０２＿Ａが商品棚の１番上の段、ＡＳ０２＿Ｂが２番目の段、ＡＳ０３＿Ｃが３番目の段、というようにｚ軸方向にも商品カゴを特定することができ、これに応じて、判定エリアもｚ軸方向の値を入れても構わない。

図１７の（Ａ）は、位置追跡情報１７００の例である。
位置追跡情報１７００は、項目１７２０に示す各項目の情報を有しており、フィールド名１７３０として例えばサンプル値１７４０のような値を有している。
位置追跡情報１７００は、店舗内のどこに誰がいたかを時間順に記憶する情報である。位置情報記憶部又は位置情報記憶手段と呼ぶこともある。
位置追跡情報１７００は、期限１７０５、滞在範囲１７０１、人物ＩＤ１７０２、店舗ＩＤ１７０３、タイムスタンプ１７０４等の項目を有する。
滞在範囲１７０１は、図１６と同様に店舗内または商品棚設置用フレーム２１００内をあらかじめ区切った区画が記憶されており、カメラセンサユニット１０４から送信される位置情報から特定された顧客が滞在した場所を記憶する。

図１７の（Ｂ）は、骨格検出情報１７００ａの例である。
骨格検出情報１７００ａは、項目１７２０ａに示す各項目の情報を有しており、フィールド名１７３０ａとして例えばサンプル値１７４０ａのような値を有している。
骨格検出情報１７００ａは、店舗内の顧客の撮影画像に対して骨格検出モジュールを適用することで検出された特徴部に関する情報である。
この情報は、骨格検出用カメラセンサユニット１０４ａの骨格検出モジュール５１０ａによって検出された人体の上半身の所定の特徴部（例えば、頭部、左右の肩、左右の肘、左右の手首）の位置座標に関する。さらに、これら特徴部の位置座標を用いて、演算によって求められた人体の他の部位の特徴部（例えば、左右の手の推定点等）の位置座標を同様に含めることができる。

なお、同図では、撮影画像上で１人の顧客が検出された場合のその顧客の骨格検出情報１７００ａについて例示している。撮影画像上で複数人の顧客が検出された場合には、それぞれの顧客ごとに別々に骨格検出情報１７００ａが作成される。その場合、顧客ごとに図１７の（Ｂ）の表を別々に作成してもよい。または、同一撮影画像上の複数人の顧客について図１７の（Ｂ）の表をまとめて作成してもよい。
上半身の所定の特徴部と手の推定点の情報は、位置追跡情報１７００の検出した情報と統合することができる。
さらに、骨格検出情報１７００ａでは、位置追跡情報１７００の場合と同様に、期限やタイムスタンプなどを含めることができる。

図１７の（Ｂ）の表は、画像内での追跡情報を含めることができる。例えば、図１７の（Ａ）の表と図１７の（Ｂ）の表は、別々に作成されてもよいが、まとめて作成されてもよい。例えば、カメラセンサユニット１０４ａの撮影画像に基づいて作成された図１７の（Ｂ）のデータを、カメラセンサユニット１０４の撮影画像に基づいて作成された図１７の（Ａ）の表に入れ込むようにしてもよい。または、この逆でもよい。

人物ＩＤ１７０２は、カメラセンサユニット１０４から送信される人物を特定する情報であり、この段階ではユーザＩＤとは対応付けられていない。従って、どのユーザであるかは特定されていないが、ある人物がタイムスタンプ１７０４で示す時間に、滞在範囲１７０１にいたという事を記憶する。
店舗ＩＤ１７０３は、どの店舗での出来事かを記憶する。
タイムスタンプでは、カメラセンサユニット１０４から送信されるデータを例えばＵＮＩＸ（登録商標）タイムスタンプ（秒単位）で記憶する。
また、これらのレコードは期限１７０５で指定された期限を超えると削除される、もしくは別の安価なストレージ領域に移行される。

図１８は、棚イベント情報１８００の例である。
棚イベント情報１８００は、項目１８２０に示す各項目の情報を有しており、フィールド名１８３０として例えばサンプル値１８４０のような値を有している。
棚イベント情報１８００は、重量センサユニット１０５から送信される重量情報に基づいて、商品棚で発生した重量変化などのイベントを記憶する。重量情報記憶部又は重量情報記憶手段と呼ぶこともある。
棚イベント情報１８００は、イベントＩＤ、商品カゴＩＤ１８０１、前回重量１８０２、店舗ＩＤ、タイムスタンプ１８０３、タイプ、重量１８０４、重量変化量１８０５等の項目を有する。
商品カゴＩＤ１８０１は、重量センサユニット１０５から送信された重量の変化した商品カゴＩＤ２００１に対応する値が記憶される。

前回重量１８０２及び重量１８０４には、重量センサユニット１０５から送信されたそれぞれ前回重量２００４、重量２００２の値が記憶される。なお、前回重量１８０２には送信された値でなく、管理サーバ１０１が記憶している前回の重量が記憶される構成としてもよい。
重量変化量１８０５は、現在の重量１８０４と前回重量１８０２との差分の値が記憶される。
タイムスタンプ１８０３には、イベントの発生した時刻が記憶される。重量情報処理モジュール１１０１が重量情報を受信した時刻が記憶されるが、データ集約送信器６３０が重量情報を送信した時刻を使用してもよいし、マイコン７１０が重量情報を送信した時刻や、マイコン７１０が重量の値を取得した時刻、重量センサデバイス６０８が重量の値を取得した時刻を使用してもよい。

図１９は、見積管理情報１９００の例である。
見積管理情報１９００は、項目１９２０に示す各項目の情報を有しており、フィールド名１９３０として例えばサンプル値１９４０のような値を有している。
見積管理情報１９００は、見積表示モジュール１１０６が特定したユーザＩＤ１９０１、人物ＩＤ１９０２、商品ＩＤ１９０３及び商品の個数１９０４、タイムスタンプ１９０５を記憶する。つまり、誰がいつ何を何個商品棚から取り上げたのかの判定結果を記録する情報である。

図２４～図３２は、商品管理システム１のそれぞれの端末や管理サーバ１０１の各モジュールが実施する処理の例である。
図２４は、重量情報蓄積処理フロー２４００の例である。
重量情報処理モジュール１１０１は、重量センサユニット１０５から送信された重量情報を受信する（ステップ２４１０）。
重量情報処理モジュール１１０１は、受信した時間の時刻情報を取得する（ステップ２４２０）。また、棚イベント情報１８００に記憶されるその他の情報を取得もしくは算出する。

重量情報処理モジュール１１０１は、取得した時刻情報と共に重量情報及びその他の情報を対応付けて棚イベント情報１８００に蓄積する（ステップ２４３０）。
なお、時刻情報は、重量情報処理モジュール１１０１が重量情報を受信した時刻としたが、データ集約送信器６３０が重量情報を送信した時刻を使用してもよいし、マイコン７１０が重量情報を送信した時刻や、マイコン７１０が重量の値を取得した時刻、重量センサデバイス６０８が重量の値を取得した時刻を使用してもよい。

図２５は、位置情報蓄積処理フロー２５００の例である。
位置情報処理モジュール１１０２は、カメラセンサユニット１０４から送信された人物ＩＤと時刻情報と当該時刻における位置情報とを受信する（ステップ２５１０）。
位置情報処理モジュール１１０２は、位置情報に基づいて、人物ＩＤで示される人物が滞在した滞在範囲を特定する（ステップ２５２０）。滞在範囲は、店舗内または商品棚設置用フレーム２１００内をあらかじめ区切った区画の情報と対応付けて、どこの区画に属するのかを特定する。また、位置追跡情報１７００に示される項目１７２０のその他の情報を取得もしくは算出する。
位置情報処理モジュール１１０２は、特定した滞在範囲の情報、人物ＩＤ、時刻情報及びその他の情報を対応付けて位置追跡情報１７００に記憶する（ステップ２５３０）。
なお、人物が滞在した場所は、滞在範囲１７０１のサンプル値１７４０のＡ１，Ａ２等、あらかじめ規定された区画の情報が記憶されるが、位置情報として受信した座標情報を記憶する構成としてもよし、複数の位置情報をまとめた軌跡情報を記憶する構成としてもよい。

図４２は、骨格検出処理フロー４２００の例である。
骨格検出処理モジュール１１０２ａは、撮影画像上で骨格検出モジュールを適用することで検出された人体の上半身の特徴点（例えば、頭部、右肩、左肩、右肘、左肘、右手首、左手首）を受信する（ステップ４２１０）。この特徴点は、骨格検出用カメラセンサユニット１０４ａの骨格検出モジュール５１０ａにより求められる。
次に、上記人体の上半身の特徴点を用いて、手の推定点を演算により求める（ステップ４２２０）。この手の推定点は、骨格検出用カメラセンサユニット１０４ａの骨格検出モジュール５１０ａにより求められる。この際、首部等、人体の他の部位の位置座標を合わせて求めてもよい。

さらに、時刻情報と共に手の推定点の情報を蓄積する（ステップ４２３０）。
位置情報処理モジュール１１０２によって取得した位置情報と、骨格検出処理モジュール１１０２ａによって取得した位置情報とは、互いに位置座標を対応付けることができる。
なお、骨格検出用カメラセンサユニット１０４ａがこの骨格検出処理フロー４２００を実行し、特徴点情報や、その特徴点情報から算出された手の推定位置座標等を、管理サーバ１０１に送信してもよい。または、管理サーバ１０１側で、撮影画像に基づいて、ステップ４２１０、ステップ４２２０及びステップ４２３０の各フローを実行してもよい。

図２６は、店舗における商品購入の全体処理フロー２６００の例である。
顧客が店舗に入店し、入店管理端末１０６で入店処理を行うと、入退店管理モジュール１１０３が入店処理２７００を実行する（ステップ２６１０）。
顧客が店舗内を移動する移動軌跡に関する情報は逐次位置追跡情報１７００に記憶され、商品棚から商品を取得した情報は棚イベント情報１８００に記憶されている。
商品判定モジュール１１０４は、記憶された棚イベント情報１８００に基づいて、顧客が取り上げた商品の内容及び個数を特定する商品判定処理２８００を実行する（ステップ２６２０）。

顧客個数判定モジュール１１０５は、記憶された位置追跡情報１７００、骨格検出情報１７００ａ及び棚イベント情報１８００に基づいて、重量変化の発生した商品カゴに手の届く範囲にいた顧客を特定する顧客判定処理２９００を実行する（ステップ２６３０）。この際、演算により求められた手の推定点と商品棚の位置との間の相互関係を判定した結果と、重量変化を検知したセンサの出力の変化を判定した結果とに基づいて、どの顧客によって、商品棚から商品がいくつピックアップされたかを判定するのが好ましい。
見積表示モジュール１１０６は、入店処理２７００、商品判定処理２８００及び顧客判定処理２９００の処理結果を突き合わせ、どのユーザがどの商品を何個手に取ったのかを算出し、ユーザのモバイル端末１０２に見積もり情報を表示する見積表示処理３０００を実行する（ステップ２６４０）。

支払管理モジュール１１０７は、顧客の退店を示す情報を受信したことに基づいて、見積もりされていた商品に対する決済処理を決済処理サーバ１０７に依頼する支払処理３１００を実行する（ステップ２６５０）。

以下それぞれの処理フローの詳細を説明する。
図２７は、入店処理フロー２７００の例である。
入退店管理モジュール１１０３は、入店管理端末１０６の入店管理モジュール９１０から、顧客のユーザ特定情報を受信し（ステップ２７１０）、受信した時間の時刻情報を入店時刻として取得する（ステップ２７２０）。
入退店管理モジュール１１０３は、受信したユーザ特定情報と、記憶しているユーザマスタ情報１４００のユーザ特定情報１４０２とを照合し、対応するユーザＩＤ１４０１を取得することで、どのユーザが入店したかを特定する（ステップ２７３０）。
入退店管理モジュール１１０３は、特定したユーザＩＤ１４０１と、入店時刻を入店情報１１１１に記憶する（ステップ２７４０）。

なお、入店時刻は管理サーバ１０１の入退店管理モジュール１１０３が顧客特定情報を受信した時刻を入店時刻としているが、入店管理端末１０６の入店管理モジュール９１０が、顧客のモバイル端末１０２に表示されたバーコードを読み取ったタイミング、又は非接触型ＩＣチップから非接触通信により情報を取得したタイミングで、入店時刻を生成し、顧客特定情報と共に管理サーバ１０１に送信する構成としてもよい。

図２８は、商品判定処理フロー２８００の例である。
商品判定モジュール１１０４は、重量の変化が発生した時刻（イベント発生時刻）の情報を棚イベント情報１８００から取得する（ステップ２８１０）。
商品判定モジュール１１０４は、棚イベント情報１８００から重量の変化が発生した商品カゴＩＤと重量変化量とを取得する（ステップ２８２０）。

商品判定モジュール１１０４は、セグメント情報１５００に基づいて、商品カゴＩＤ１５０１に対応付けられた商品ＩＤ１５０２の情報及び、商品マスタ情報１３００から、重量の変化が発生した商品カゴＩＤに対応する商品情報を取得する（ステップ２８３０）。
商品判定モジュール１１０４は、重量変化量と商品マスタ情報１３００に記憶された商品の重量１３０４とに基づいて、顧客が取り上げた商品の個数を算出する（ステップ２８４０）。
商品判定モジュール１１０４は、取得した商品情報及び算出した商品の個数情報を出力する（ステップ２８５０）。
この判定結果は、演算により求められた手の推定点と商品棚の位置との相互関係の判定結果を突き合わせることにより、判定精度の低下を防ぐのが好ましい。

図２９は、顧客判定処理フロー２９００の例である。
顧客個数判定モジュール１１０５は、棚イベント情報１８００から、イベントが発生した時刻を取得する（ステップ２９１０）。
顧客個数判定モジュール１１０５は、棚イベント情報１８００及び入店情報１１１１、位置追跡情報１７００から、イベントが発生した場所の近辺に滞在した人物の人物ＩＤを特定する（ステップ２９２０）。
顧客個数判定モジュール１１０５は、特定した人物ＩＤを出力する（ステップ２９３０）。

例えば、商品カゴの重量の変化が生じるというイベントが発生した場合には、顧客個数判定モジュール１１０５は、重量の変化が生じた時刻に該当するタイムスタンプ１８０３を棚イベント情報１８００から取得する。
次に、取得判定範囲情報１６００の商品カゴＩＤ１６０１に対応する判定滞在範囲１６０３と、位置追跡情報１７００の人物ＩＤ１７０２に対応する滞在範囲１７０１とを突き合わせることにより、重量の変化が発生した商品カゴから商品を取得可能な範囲にイベント発生時刻に滞在した顧客の人物ＩＤを特定する。

また、顧客が入店したというイベントが発生した場合には、顧客個数判定モジュール１１０５は、入店時刻に該当するタイムスタンプを入店情報１１１１から取得する。
次に、入店情報１１１１の人物ＩＤと、位置追跡情報１７００の位置情報（滞在範囲１７０１）及び人物ＩＤ１７０２とを突き合わせすることにより、入店時点に入店管理端末１０６のそばに滞在した顧客の人物ＩＤを特定する。

なお、重量センサユニット１０５は、重量センサデバイス６０８により取得された重量の変化が生じた時間と重量の変化が安定した時間との２回に分けて重量情報を送信し、棚イベント情報１８００は、いずれの情報も記憶する構成とすることもできるし、２回目の重量が安定した後の重量情報のみを記憶する構成にすることもできる。
棚イベント情報１８００は、１回目の重量情報に対応する前記重量の変化が生じた第１の時間と重量の変化が安定した第２の時間との差分時間を記憶することもでき、この場合には、１回目の重量情報を記憶しない構成であっても、２回目の重量情報に対応する第２の時間から差分時刻を引いた時間に基づいて、当該時間の人物ＩＤを特定することができる。つまり重量の変化が安定した第２の時間と上記差分時間とに基づいて、商品の個数と顧客とを対応付け、顧客のモバイル端末１０２に前記商品の個数を表示することができる。

なお、棚イベント情報１８００のタイムスタンプ１８０３と、位置追跡情報１７００のタイムスタンプ１７０４にはセンサの誤差等により、若干のタイムラグが生じている可能性があるため、顧客の位置を特定する時刻は段階的に広くとって人物ＩＤを特定することも好ましい。
例えば、重量の変化が発生した時刻のタイムスタンプ１８０３と、その前１秒と後１秒の合計３秒間の位置追跡情報１７００から、対応する人物ＩＤを特定する。ここで対応する人物ＩＤを特定できなかった場合には、範囲をタイムスタンプ１８０３と、その前後２秒ずつの合計５秒間に拡大し、人物ＩＤが特定できるか確認する。このように順次判定時間を段階的に広めて、人物が特定できるところまで処理を繰り返す。

また、複数の人物ＩＤが候補として得られた場合には、最も確率の高い人物を対象として特定する。例えば、商品カゴから最も近い人や、商品カゴに手を伸ばした人物を確率が高い人物として特定する。これらの情報はカメラセンサユニット１０４により取得される顧客の位置情報や、手の動きの情報により取得することができる。さらに、これらの情報は、カメラデバイス５０６ａからの撮影画面上で抽出された骨格の特徴部を用いて演算によって求められた手の推定点と商品棚の位置との相互関係の判定結果と突き合わせることもできる。

また、重量の変化が発生した時刻の前後の時刻（例えば前後１分間）にイベントが発生した商品カゴの周辺（例えば商品棚設置用フレーム２１００の内部）に滞在する人物の数に応じて、人物特定に用いる判定時間範囲を変更する構成としてもよい。つまり商品棚設置用フレーム２１００や店舗内に１人しか顧客が存在しない場合には、そこで発生した重量変化はその１人の顧客によるものである可能性が高いので、このような場合には、判定時間範囲を広めにとる。例えば重量の変化が発生した時刻と、その前後５秒ずつの合計１１秒間に商品カゴの判定滞在範囲１６０３に滞在する顧客の人物ＩＤを特定する。

逆に、商品棚設置用フレーム２１００や店舗内の顧客数が多い場合には、判定時間範囲を短くとり、より精度を高める処理を行う。例えば、重量の変化が発生した時刻の１秒間に商品カゴの判定滞在範囲１６０３に滞在する顧客の人物ＩＤを特定し、特定できなかった場合には、さらに前後１秒ずつ拡大した３秒間の範囲で判定することを繰り返す。このように段階的に判定時間範囲を広げていく。
このように、重量の変化が発生した時刻などのイベント発生時刻において、商品棚設置用フレーム２１００や店舗内に滞在する顧客数に応じて、人物を特定する判定時間範囲を動的に変更することで、判定のスピードや精度を高めることが可能となる。

図３０は、見積表示処理フロー３０００の例である。
見積表示モジュール１１０６は、入店処理２７００、商品判定処理２８００及び顧客判定処理２９００の処理結果を取得し、これらの突き合わせを行う（ステップ３０１０）。
見積表示モジュール１１０６は、イベント発生時刻に対応するユーザＩＤ、商品情報、商品の個数情報を取得し、記憶する（ステップ３０２０）。例えば、商品判定処理２８００により特定された重量の変化が発生した時刻における商品情報、商品の個数情報と、顧客判定処理２９００により特定された重量の変化が発生した時刻における人物ＩＤとを対応付ける。また、顧客判定処理２９００により特定された上記人物ＩＤの人物が入店管理端末１０６のそばに滞在した時刻のあたりに入店した人物のユーザＩＤを対応付ける。
見積表示モジュール１１０６は、対応付けられたユーザＩＤ、人物ＩＤ、商品ＩＤ、個数、タイムスタンプを見積管理情報１９００に記憶する。

つまり、商品棚に設置した重量センサユニット１０５から送信された重量情報と、この重量情報に対応する第１の時間情報とが棚イベント情報１８００に時系列に蓄積されており、
カメラセンサユニット１０４から送信された顧客の位置情報と、この位置情報に対応する第２の時間情報とが位置追跡情報１７００に時系列に蓄積されており、
カメラセンサユニット１０４ａから送信された顧客の骨格の位置情報と、この位置情報に対応する第３の時間情報とが骨格検出情報１７００ａに時系列に蓄積されており、
顧客の入店時の第４の時間情報が入店情報１１１１に時系列に蓄積されており、
これら第１の時間情報と第２の時間情報と第３の時間情報と第４の時間情報とに基づいて蓄積情報を突き合わせることにより、商品の個数と顧客とユーザ情報とを対応付け、ユーザ情報により特定された顧客のモバイル端末１０２に商品の個数情報を表示することができる。
なお、棚イベント情報１８００、位置追跡情報１７００、骨格検出情報１７００ａ、入店情報１１１１は、それぞれ又は一部が異なる記憶手段に記憶されていてもよいし、全てが同一の記憶手段に記憶されていてもよい。

見積表示モジュール１１０６は、見積管理情報１９００に基づいて、ユーザＩＤ１９０１に対応する顧客のモバイル端末１０２に商品情報、商品の個数情報を送信し、表示する（ステップ３０３０）。モバイル端末１０２の商品購入管理モジュール３１０は、受信した商品情報、商品の個数情報をディスプレイ等の出力装置３０５に表示する。
見積表示モジュール１１０６は、顧客が退店するまでに商品カゴから取り出した商品の合計金額を算出し、顧客のモバイル端末１０２に表示する（ステップ３０４０）。

なお、重量センサユニット１０５による情報やカメラセンサユニット１０４、カメラセンサユニット１０４ａによる映像により、顧客の購入した商品及びその個数を判定できない場合には要チェックリストに情報を記憶する。
例えば、重量の変化量の検知が怪しい場合や、カメラデバイス５０６からの位置情報の検知、カメラデバイス５０６ａからの撮影画像に基づく手の推定点の演算が旨く行かない場合や、映像が隠れてしまい判別できていない場合等のイレギュラーな事象が発生する場合、最終的に人間によるチェックを行うための要チェックリストに情報を記憶する。これにより、管理サーバ１０１で判別しきれない場合には、後から人間が補佐を行うことで精度の高い買い物体験を実現することができる。決済処理自体は退店後に実行されるため利用者の顧客体験は損なわれることはない。

本実施例では、カメラセンサユニット１０４から取得した顧客の位置情報に関する情報（移動軌跡）と、カメラセンサユニット１０４ａから取得した顧客の骨格検出に関する情報（手の推定点など）と、重量センサユニット１０５から取得した重量の変化に関する情報と、入店管理端末１０６から取得した顧客の入店に関する情報と、を時系列で蓄積することにより、店内で起こったいつ誰がどこで何をしたのかという情報が全て時系列でクラウド上の管理サーバ１０１に保存されており、これらを時系列で再現することが可能となる。
また、全てのセンサが独立して動作しており、それぞれの情報を時系列で蓄積すれば様々な分析や顧客判定制度を高めることが可能となるため、例えば後から利用者の性別や年齢を推定するセンサを追加することも容易である。

図３１は、支払処理フロー３１００の例である。
支払管理モジュール１１０７は、顧客が退店エリアの外に一定時間、例えば１０秒以上出たことを示す情報を受信する（ステップ３１１０）。退店エリアの外に出たかどうかは、カメラセンサユニット１０４が、あらかじめ定めた座標の範囲から顧客が外に出たかどうかを検知することにより判定する。図２１及び図２３の商品棚設置用フレーム２１００を使用した例では、座標（０，０）、（０，２５００）、（２５００，２５００）、（２５００，０）で囲われた範囲が退店エリアである。
商品棚設置用フレーム２１００を使用しない構成においては、店舗の内部または近辺で退店エリアの座標を任意に設定しておけばよい。

退店エリアの外に一定時間出たことに応じて、支払管理モジュール１１０７は、見積表示モジュール１１０６が記憶していた全ての商品の合計金額を算出する（ステップ３１２０）。
支払管理モジュール１１０７は、当該商品を商品カゴから手に取ったユーザＩＤ及び合計金額を決済処理サーバ１０７に送信し、決済処理サーバ１０７がユーザＩＤに対応する決済処理情報１０２０に基づいて決済処理を実行する（ステップ３１３０）。

本実施例では、最終的に手に取った商品や個数が間違っていた場合には、モバイル端末１０２の商品購入管理モジュール３１０（例えばスマートフォン上のアプリ）から払い戻しを実行できる。決済処理では、退店後に決済処理サーバ１０７にて決済予約を掛け、一定時間後に決済確定処理を行っており、決済予約から決済確定処理まで一定時間を空ける
ことで、返品時の手数料の支払いを無くしている。

図３２は、サイネージ表示処理フロー３２００の例である。
サイネージ処理モジュール１２０２は、ＩｏＴ情報処理モジュール１２０１から、重量センサユニット１０５で計測した重量値が安定状態から不安定状態に変化が発生したタイミングの１回目の重量情報を受信する（ステップ３２１０）。なお、ＩｏＴ情報処理モジュール１２０１により重量情報が振り分けられて受信される構成でなく、データ集約送信器６３０から重量情報を受信する構成であってもよい。

サイネージ処理モジュール１２０２は、重量情報から重量の変化が発生した商品カゴＩＤを取得する（ステップ３２２０）。
サイネージ処理モジュール１２０２は、セグメント情報１５００及び商品マスタ情報１３００から商品カゴＩＤに対応する商品ＩＤの商品名１３０２や価格１３０３等の商品情報及びサイネージ情報１３０５を取得する（ステップ３２３０）。

サイネージ処理モジュール１２０２は、取得したサイネージ情報をサイネージ端末１０３に送信し、表示する（ステップ３２４０）。サイネージ情報としては、例えば商品カゴＩＤに対応する商品ＩＤの商品名や価格、広告などの情報や、対応する商品ＩＤに関連付けられた商品の商品名や価格、広告などの情報（例えば、玉ねぎを手に取った場合に、この玉ねぎを使用した料理であるカレールーに関する情報）が記憶されている。

なお、サイネージ情報はサイネージ処理モジュール１２０２が送信する構成としたが、サイネージ処理モジュール１２０２からの商品ＩＤ等サイネージ情報を特定する情報の送信に応じて、サイネージ端末１０３に記憶されているサイネージ情報４２０を読み出す構成であってもよい。
サイネージ端末１０３は、例えばタブレット端末であり、自身の有するディスプレイにサイネージ情報を表示する構成であってもよいし、例えばRaspberry Piななどのシングルボードコンピュータやコンピュータが、外付けのディスプレイにサイネージ情報を表示する構成であってもよい。

また、サイネージ処理モジュール１２０２が、サイネージ情報や、商品ＩＤ等サイネージ情報を特定する情報をＰｕｓｈ形式で送信する構成であってもよいし、ＭＱＴＴ形式に基づいてサイネージ端末１０３がサブスクライブしているサイネージ処理モジュール１２０２から情報をＰｕｌｌ形式で取得する構成であってもよい。

図３３は、ハードウェアのリファレンスモデル３３００の例である。
通常、無人店舗を実現しようとした場合、店舗の構造や商品配置に応じて店舗ごとに複数のカメラセンサの位置や個数などを個別に設定する必要があり、設定のための労力や時間、コストがかかることとなる。

一方本実施例では、あらかじめサイズを決めた商品棚設置用フレーム２１００を準備し、かつ図２１の様に決められた位置にカメラデバイス５０６を設置する構成とする、また、さらに商品棚設置用フレーム２１００内の所定の位置に、決められたサイズの商品棚を設置することより、無人店舗設営時の初期設定を簡素化し、設営のための労力や時間、コストを削減することができる。
また、商品棚設置用フレーム２１００を並べていくことで、店舗のサイズに応じて商品管理システム１のサイズを簡単に調整することが可能である。

本実施例では、商品棚設置用フレーム２１００を用いるウォークスルー（屋内用）３３１０の構成について説明したが、さらにサイズの大きいコンテナを利用したウォークスルー（屋外用）３３２０の構成をとることもできる。この場合にも、商品棚設置用フレーム２１００と同様にコンテナ内のあらかじめ決められた位置にカメラデバイス５０６を設置し、種々初期設定を簡素化することが可能である。

図３３のハードウェアのリファレンスモデル３３００では、このような無人店舗の構成や、カメラデバイス５０６、カメラデバイス５０６ａの個数などのあらかじめ決められたモデルを、あたかもクラウドのサービスを選択するのと同じように、ウェブサイト上から選択するインターフェースを顧客に提供する。
インスタンスファミリー３３０１は、無人店舗やモバイルオーダーの構成を示す。インスタンスタイプ３３０２は、クラウドサービスにおけるＩａａＳ（Infrastructure as a Service）の様に、各構成を示すタイプを示す。
イメージ３３０３は、各インスタンスタイプを設置する場合に想定される店舗形式を示す。

カメラ３３０４は、カメラの有無を示す。カメラには、カメラデバイス５０６とカメラデバイス５０６ａを含むことができる。
複数名対応３３０５は、複数の顧客を判別できるかどうかを示す。
屋内３３０６及び屋外３３０７は、屋内向けの店舗化、屋外向けの店舗化を示す。
サイズ概算は、この商品管理システム１のサイズを示す。
例えば複数名対応３３０５が「無し」であり顧客が一人のみの簡易型の商品管理システム１では、重量センサユニット１０５のみを使用し、カメラセンサユニット１０４及び／またはカメラセンサユニット１０４ａを設置しないことで、省スペースかつ安価にシステムを構築することができる。

管理サーバ１０１は、ユーザからインスタンスタイプ３３０２の選択を受け付けることで、必要な商品棚設置用フレーム２１００やカメラデバイス５０６やカメラデバイス５０６ａ等のハードウェアを、場合により倉庫等から店舗に配送した後、これらを設置した後、管理サーバ１０１から、カメラ管理端末５３０、カメラ管理端末５３０ａ、及びデータ集約送信器６３０に初期設定情報及び初期設定手順を送信し、これらの端末や機器がそれらを実行することで、カメラセンサユニット１０４、カメラセンサユニット１０４ａ、及び重量センサユニット１０５に対する初期設定が完了する。

例えば、店舗内の店内の重量センサデバイス６０８やマイコン７１０やデータ集約送信器６３０が接続された重量センサユニット１０５に対する電源を入れると、ＷｉＦｉ（またはＬＴＥ）モデム経由でクラウド上の管理サーバ１０１に自動接続し、それぞれのデバイスや機器に割り当てられたＩＤや機器情報が管理サーバ１０１に送信される。
管理サーバ１０１は、送信されたＩＤや機器情報で特定された各機器やデバイスに対し、選択されたインスタンスタイプ３３０２で指定された構成に基づくそれぞれのデバイスや機器に対応したセットアップデータや、セットアッププログラム等を送信し、セットアップ手順を実行する。

このような手順により、クラウド上の管理サーバ１０１では、設定状況を把握でき、稼働中の状況を把握することが可能となる。また、障害発生時には、管理サーバ１０１からカメラセンサユニット１０４、カメラセンサユニット１０４ａ、及び重量センサユニット１０５の各機器やデバイスの再起動や再セットアップなどの操作を行うリモート運用が可能となる。

例えば、図２１の商品棚設置用フレーム２１００の例では、カメラデバイス５０６が少なくとも４本の支柱近傍の所定の位置に設置されており、商品棚設置用フレーム２１００内の所定の位置に重量センサデバイス６０８を設置した商品棚を配置した後、管理サーバが重量センサの複数のマイコン７１０（もしくは重量センサデバイス６０８）を特定する情報（それぞれの商品カゴＩＤ）と設定情報とをデータ集約送信器６３０に送付し、複数のマイコン７１０の商品カゴＩＤと設定情報とに基づいて、データ集約送信器６３０が管理サーバにおける複数のマイコン７１０の設定を実行する。カメラデバイス５０６とは異なる位置に、カメラデバイス５０６ａを設置してもよい。

カメラセンサユニット１０４は図２１や図２３のような商品棚設置用フレーム２１００内の座標情報と対応付けて、重量センサユニット１０５のマイコン７１０を特定する商品カゴＩＤを記憶する。図２３の例では商品棚ＡＳ０１に存在する商品カゴＩＤがＡＳ０１＿ＡとＡＳ０１＿ＢとＡＳ０１＿Ｃにはいずれも座標（３５０，０）（３５０，５００）（８００，５００）（８００，０）で囲われた範囲が対応付けられている。

図３４は、注文管理画面３４００の例である。
管理サーバ１０１の見積表示モジュール１１０６は、ユーザの注文履歴を管理する。
注文管理画面３４００では、商品を手に取った履歴３４０１と、その商品を再び商品カゴに戻した履歴３４０２が表示されており、チョコチップクッキーを１つとり、１つ戻した（－１した）ことが分かる。またキャラメルワッフルを手に取った履歴３４０３があり、それらの合計金額３４０４が１６２円である旨が表示されている。

図３５は、商品購入画面の例である。
商品カゴから商品を手に取った顧客に対応付けられたユーザＩＤで特定されたモバイル端末１０２に表示される画面の例である。
画面３５００はキャンディを２つ商品カゴからとったことが検知され、表示される画面の例である。商品３５０１にホワイトチョコ１つとキャンディ２つが表示されている。画面３５５０はその後キャンディを１つ商品カゴに戻したことが検知され、表示される画面の例である。商品３５０２にはホワイトチョコ１つとキャンディ１つが表示されている。

一般的なＰＯＳシステムでは、購入した商品をカゴにいれた順番は分からない。一方、本実施例の商品管理システム１では、どの商品棚の前にどの順番で訪れて、何を手にとって、戻して、結果的に何をどの順番で買ったのか、等の店舗内での行動を時系列で全て把握している。そのため、より詳細な行動及び購買データを取得することが可能となり、手に取ったが買わなかった商品や長く滞在した商品棚に置かれている商品について、再来店に購入を促すクーポンの発行や、興味を持った履歴のアプリ上の表示等を実行することができる。

また、入店時にユーザ特定情報により認証を行っているため、そのユーザに対する属性情報をユーザマスタ情報１４００から取得することで、この属性情報と店舗内の行動トラッキングにより、顧客が商品棚の前に来た際に、過去の購買履歴に合わせたサイネージ情報を表示したり、アップセルを促すクーポンをサイネージに表示することが可能となる。
また、電子値札を組み合わせると、顧客ごとに、クーポン価格を適用した割引金額を電子値札に表示したり、見積表示モジュール１１０６により表示される金額を割引価格とするなど、ダイナミックプライシングやダイナミックオファーを行うことも可能となる。

本実施例の商品管理システム１では、カメラセンサユニット１０４、カメラセンサユニット１０４ａ、及び重量センサユニット１０５を用いて様々な商品の販売管理を簡単に行う仕組みを実現することができる。また、あらかじめこれらのセンサを組み込む位置を指定した商品棚設置用フレーム２１００やコンテナ、商品棚を使用し、管理サーバ１０１から設定情報や設定手順をＰｕｓｈ形式でデータ集約送信器６３０、カメラ管理端末５３０及びカメラ管理端末５３０ａに送信して初期設定を行うことで、無人端末等の商品管理システム１を簡単に導入することが可能となる。

次に、本発明に係る商品管理システム１の実施例２について説明する。記載の重複を避けるため、主に、上記実施例１との相違点について説明する。実施例２は、実施例１と組み合わされて実施されてもよく、それぞれ別々に実施されてもよい。

図３６を参照すると、実施例２を適用可能な店舗内の様子を、（Ａ）と（Ｂ）の２つに分けて示している。これら図では、同一の店舗内の様子が、同一の視点から、異なる時刻で撮影されている。これら図から理解できるように、店舗内には、複数の商品棚が設置されている。各商品棚では、複数の商品が販売用に展示されている。各商品棚の間は、顧客が自由に歩き回れる通路となっている。

「店舗」とは、経済活動を行うために、商品またはサービスを提供する施設を指す。店舗は、少なくとも、商品棚を設置するためのスペースを有していればよく、その周囲を囲む壁や天井は必ずしも必要としない。例えば、店舗は、ショッピングセンター、百貨店またはアウトレットモール等のように、一つの建物の一区画として設けられてもよい。または、店舗は、小型のスーパーマーケットまたは一個人事業主の店等のように、一つの建物全体として設けられてもよい。または、店舗は、建物を有しない屋外の一区画として設けられてもよい。

「商品」とは、店舗内で、経済活動の対象として取引きされる物品を指す。物品とは、例えば、食料品、飲料品、文房具または衣類等の有体物である。この有体物には、データまたはプログラム等を一時的に記憶した任意の種類の記憶媒体も含まれる。また、この有体物には、サービス提供に関する任意の媒体も含むことができる。

「商品棚」とは、商品を陳列するための任意の構成物を指す。例えば、商品棚は、商品陳列用の棒を、上下方向に１段または複数段で備えてもよい。棒は、一端側を商品棚の本体に固定され、他端側を自由端部として、商品をフック状にひっかけてもよい。または、商品棚は、商品陳列用の板を、上下方向に１段または複数段で備えてもよい。板は、ほぼ水平な上面を有し、一端側を商品棚の本体に固定され、その上面に１つまたは複数の商品を載せてもよい。または、商品棚は、商品陳列用の商品かごを、上下方向に１段または複数段で備えてもよい（図２２等参照）。

本実施例では、商品棚の各段には、陳列されている商品の重さを検知または算出するためのセンサを設置することができる。例えば、商品棚の棒にフック状にひっかけられている商品の重さを検出するセンサが、棒と関連付けられて設置されている。または、商品棚の板や商品かごの上に載せられている商品の重さを検出するセンサが、板や商品かごと関連付けられて設置されている。センサは、検出した棒または板または商品かごの重さを数値化して出力し、その値を管理サーバ１０１に送信することができる。

好ましくは、センサは、重量センサである。例えば、センサは、ロードセルまたは電磁平衡式センサ等である。ただし、このセンサには、現在入手可能なセンサだけでなく、将来的に入手可能なセンサを含むことができる。さらに、このセンサは、重量を直接的に検知する形態に限定されない。例えば、このセンサは、重さとは違う別の変位量を検出して、その変位量に基づいて重さの変化を演算によって求めてもよい。

以下、商品棚の各段には、商品棚の棒または板または商品かごに乗せられている商品の重さを直接的に検出する重量センサが設置されているものとする。この重量センサは、実施例１で用いられた重量センサユニット１０５の重量センサデバイス６０８（図７、図８参照）でもよい。
重量センサデバイス６０８は、あらかじめ、商品棚の棒または板または商品かごに何も置かれていない状態の重さを、初期値として検出し、管理サーバ１０１に送信する。ただし、初期値は、０ｇに限定されない。

次に、重量センサデバイス６０８は、商品棚の各段（例えば、棒または板または商品かご）に乗せられた１つまたは複数の商品の重さを所定間隔で周期的に検出して、管理サーバ１０１に送信する。従って、管理サーバ１０１には、重量センサデバイス６０８の検出値に基づいて、商品棚の各段の重さの変位量が、所定間隔で周期的に送信される。この情報は、管理サーバ１０１と関連付けられた任意の記憶装置内に記憶することができる。

好ましくは、店舗内には、中の様子を撮影するために、２種類のカメラが設けられている。
一つは、店舗内の顧客の位置を検出するカメラとして機能するカメラ（第１のカメラセンサ）である。このカメラは、実施例１の位置検出用カメラセンサユニット１０４のカメラデバイス５０６でもよい。カメラデバイス５０６は、店舗内の顧客の移動軌跡（例えば歩行軌跡）を所定間隔で周期的に取得して、管理サーバ１０１に送信する。

一つは、店舗内の顧客の様子を撮影して、その撮影画像に対して人体の骨格モデルを適用して、特徴部を抽出するカメラ（第２のカメラセンサ）である。このカメラは、実施例１の骨格検出用カメラセンサユニット１０４ａのカメラデバイス５０６ａでもよい。カメラデバイス５０６ａは、店舗内の顧客の特徴点を所定間隔で周期的に抽出して、管理サーバ１０１に送信する。
さらに、カメラセンサユニット１０４ａの骨格検出モジュール５１０ａは、上記特徴点に基づいて、手の推定点などを演算に求めて、その値を管理サーバ１０１に送信してもよい。または、管理サーバ１０１の骨格検出処理モジュール１１０２ａは、送信された上記撮影画像または特徴点に基づいて、手の推定点などを演算により求めてもよい。

上記カメラデバイス５０６とカメラデバイス５０６ａの位置座標は、これらの出力を受信する管理サーバ１０１にとって、既知である。従って、管理サーバ１０１は、それぞれの撮影画像の位置座標を互いにレジストレーションまたは座標変換することができる。
なお、上記「位置座標」には、カメラのパラメータとして、３次元空間内の位置（ｘ、ｙ、ｚ）と、回転情報（θ、φ、ψ）との双方を含むことができるものとする。
従って、管理サーバ１０１には、これらカメラの撮影画像に基づいて、各顧客の移動軌跡と、各顧客の骨格モデルに基づく特徴点が、互いに関連付けられるように、周期的に送信されている（図１１参照）。これらの情報は、管理サーバ１０１と関連付けられた任意の記憶装置内に記憶することができる。

その結果、管理サーバ１０１は、店舗内の各顧客に対して、人物ＩＤと、時系列的な位置情報と、時系列的な骨格情報とをまとめて関連付けることができる。なお、骨格情報には、撮影画像上で骨格検出モジュールの適用によって得られた特徴部（頭部、首、肩、肘、手首等）の位置情報と、この特徴部を用いて演算によって求められた特徴部（手等）の位置情報とが含まれる。

なお、図１１では、位置検出用カメラセンサユニット１０４側の出力と、骨格検出用カメラセンサユニット１０４ａ側の出力とが、それぞれ別々に管理サーバ１０１に送信されているが、他の実施形態では、位置検出用カメラセンサユニット１０４側の出力と、骨格検出用カメラセンサユニット１０４ａ側の出力とを統合した後、その出力を合わせて管理サーバ１０１に送信してもよい。
例えば、骨格検出用カメラセンサユニット１０４ａが骨格の特徴部、手の推定位置座標情報を位置検出用カメラセンサユニット１０４に送信する。その後、位置検出用カメラセンサユニット１０４がこれらの情報を座標変換し、人物の座標情報と対応付け、これらの情報を管理サーバ１０１に送信することとしてもよい。

好ましくは、位置検出用カメラ１０４（カメラデバイス５０６）と骨格検出用カメラ１０４ａ（カメラデバイス５０６ａ）とは、それぞれ別体のカメラとして店舗内に設置されている（図３６の（Ａ）参照）。
各カメラデバイス５０６、５０６ａは、静止画（写真）として被写体を撮影して、その静止画データを取得、記録または出力してもよい。または、各カメラは、動画形式として被写体を撮影して、その動画形式のファイルから静止画を取得、記録または出力してもよい。動画は、複数の静止画を時系列的に並べたものとして理解することができるため、以下、各カメラによって静止画を電子的に取得するものとする。

各カメラデバイス５０６、５０６ａは、カメラの大きさの違い（小型、大型等の変化）、カメラによって撮影される静止画の色情報の違い（ＲＧＢのビット数、フルカラー、トゥルーカラー等の変化）、カメラの撮影方式の違い（通常の撮影、赤外線撮影、奥行きの情報を取得するデプスカメラ等の変化）、カメラの設置位置の違い（店舗内の上方、側方または下方等の変化）等について、実施形態に応じて変更することができる。

各カメラデバイス５０６、５０６ａは、ＰＯＶ（Point-Of-View）または「視点」を有し、それぞれのＰＯＶを通して、ＦＯＶ（Field-Of-View）または「視野」内にいる被写体の撮影を電子的に行う。好適には、各カメラデバイス５０６、５０６ａは、複数の商品棚のそれぞれについて、各商品棚の周囲の人の動きを最適に撮影するため、予め、ＰＯＶ／ＦＯＶが固定されている。ただし、各カメラデバイス５０６、５０６ａは、ＰＯＶ／ＦＯＶを可変に構成することは可能である。

各カメラデバイス５０６、５０６ａは、人物を正面側からほぼ同じ高さで撮影するように設置されてもよい。この場合、撮影画面上で、人物の上半身と下半身とでほぼ均等に２次元状に骨格検出モデルを適用することができる。ただし、カメラを設置できる箇所が限定的になる。また、店舗内の人の数が増えると、各カメラのＰＯＶ／ＦＯＶが妨げられやすくなる。その結果、期待された精度が大きく低下する虞がある。特に、撮影画像上で人同士が重なる（オクルージョン）ことによって、検出精度が下がることの影響が大きい。同じ空間内に複数のカメラを設置することでこの問題に対応することは可能だが、その場合、コスト高になりやすい。

各カメラデバイス５０６、５０６ａは、人物を上から見下ろすように撮影するように設置されてもよい。この場合、撮影画面上で、人物の上半身と下半身とで奥行が異なるように表れるので、３次元状に骨格検出モデルを適用することになる。そのため、人物の上半身と下半身とで特徴点を検出する場合、画像解析の難易度が上がる虞がある。ただし、この場合、人物の上方にある各カメラのＰＯＶ／ＦＯＶが妨げられにくくなる。また、カメラの設置場所をより広範囲に確保できる。特に、撮影画像上で人同士が重なることを回避できるため、検出精度を上げることができる。

好ましくは、本実施例では、店舗の天井または上方に設置した各カメラデバイス５０６、５０６ａにより、下方を見下ろすように店舗内の様子を撮影する（図３６の（Ａ）参照）。
さらに、撮影画像に基づいて骨格検出モデルを適用する際、上から撮影した画像と映っている骨格座標（正解データ）を与えて学習させる。この際、所謂、深層学習の転移学習・ファインチューニングと呼ばれる手法を用いることができる。加えて、後述のように、骨格検出モデルの適用をできるだけ簡潔に行うための工夫を加える。これによって、各カメラデバイス５０６、５０６ａが上方から下方を見下ろすように撮影した画像に基づいて、比較的に高い精度で骨格検出が行えるようにしている。
ただし、各カメラデバイス５０６、５０６ａは、店舗内で、側方または下方または他の位置から顧客の様子を撮影することは可能である。

例えば、位置検出用カメラデバイス５０６として、被写体までの距離を測定する３次元センサまたはＴＯＦ（Time of Flight）センサを用いてもよい。この際、３次元センサは、パルス光を投光して、該パルス光が物体に反射して戻ってくるまでの時間に基づいて、物体までの距離を求めることができる。ＴＯＦセンサを用いる場合、撮影画面上で、ピクセル（画素）毎またはピクセルの集まり毎に、被写体の距離情報を記録することができる。

例えば、骨格検出用カメラデバイス５０６ａとして、奥行きの情報を取得する深度センサを内蔵したカメラであるデプス（Depth）カメラまたは３次元カメラを用いることができる。特に、３Ｄカメラを用いて撮影された画像上で、奥行きを含めた３次元の認識を可能にする。この際、３Ｄカメラは、ＲＧＢカメラと赤外線カメラとから構成することで、色情報に加えて奥行きの情報を取得して、３次元での認識を可能にしてもよい。撮影画像に対して、骨格検出モジュールを適用することで、人物の骨格を推定することを可能にする。

従来技術では、撮影画像上で画像解析を行って、人体の特徴点を検出する際、顧客の全身にわたって複数の特徴点を検出していた（例えば、特許文献１の図６Ａ－Ｅ、図７Ａ－Ｂ、図１１及び図１４、特許文献２の図３等参照）。しかしながら、顧客の全身（上半身と下半身）にわたって複数の特徴点を検出する場合、事前のラーニング処理が難しく、実際の作業に時間がかかり、かつエラーを生じやすくなるという課題があった。

特に、下半身の足等については、前後の足を交差させる等の姿勢の変化によって、画像上に足の一部が隠されることがあった。見えない部位は、検出結果と正解との間にズレが生じやすく、学習が進みにくい虞があった。また、天井に設けたカメラから下方にいる顧客を撮影する場合、正面側から撮影する場合と異なり、上半身によって下半身が隠されやすくなるため、上半身と下半身とで出力の品質を揃えることが難しい場合があった。

また、従来技術では、撮影画像に基づいて、人体の手／指の特徴点を抽出することがあった。商品のピックアップのプロセスでは、手や指の動作が重要になるからである。例えば、特許文献２では、「管理サーバ１０１２０は、人の手の検知を、撮像画像に含まれる人の画像について行った骨格分析によって行う（段落００７９参照）」等と説明している。しかしながら、手や指は、比較的に小さくて、複雑な動きを行うため、事前のラーニング処理が難しく、実際の作業に時間がかかり、かつエラーを生じやすくなるという課題があった。

特に、手首は、人体の腕と手の掌とをつなぐ部分であって、関節（橈骨手根関節）が関連付けられている。加えて、手首の先にある手には、通常、５本の指（第一指乃至第五指）があり、それぞれの指には、複数の関節（第一関節乃至第四関節）が関連付けられている。従って、手首、手及び指は、その位置を様々に変化させるように、複雑な動きを行う。この結果、撮影画像に対して骨格検出モジュールを適用して、手や指の細かい動きを追跡することには、特有の困難があった。

さらに、商品購入時に、顧客が商品棚に向って腕を伸ばして、商品をピックアップする際、その周囲にある他の商品や商品棚の形状等によって、商品を掴もうとする手や指の動きが隠されることがあった。また、顧客が衣服のポケット等の中に手や指を入れて、その位置が隠されることがあった。このような比較的隠されやすい手や指は、検出結果と正解との間にズレが生じやすく、学習が進みにくいという課題があった。

本実施例では、制御装置（例えば、骨格検出用カメラセンサユニット１０４ａの骨格検出モジュール５１０ａまたは管理サーバ１０１の骨格検出処理モジュール１１０２ａ）によって、カメラデバイス５０６ａが撮影した画面上で、人体の骨格モデルに基づいて骨格検出モジュールを適用する。この際、顧客の上半身に限定して、特徴点を検出する。顧客の下半身については、骨格検出モジュールの適用対象から除外する。
本実施例では、商品のピックアップに寄与する人体の動きは上半身に限られ、下半身の動きは実質的に無視できることを利用する。この結果、本実施例では、骨格検出モジュールの適用対象を半減することにより、事前のラーニング処理をより容易にし、実際の作業の時間をより迅速化し、かつエラーの発生を抑えて、出力の信頼性を高めることができる。

さらに、本実施例では、制御装置（例えば、骨格検出用カメラセンサユニット１０４ａの骨格検出モジュール５１０ａまたは管理サーバ１０１の骨格検出処理モジュール１１０２ａ）によって、カメラデバイス５０６ａが撮影した画面上で、骨格検出モジュールを適用する際、人体の手首から先の部位（手や指）は、検出対象から除外する。その替わりに、骨格検出モジュールを適用して抽出された顧客の上半身の他の特徴点（例えば、肩、肘、手首）に基づいて、手首から先の部位の位置を演算により求める。
本実施例では、上半身の一部の特徴点（例えば、肩、肘、手首）を取得することができれば、人体の骨格構造に基づいて、手の位置を推測できることを利用する。

本実施例では、天井から店舗内を撮影するデプスカメラや３次元カメラで利用者を撮影し、どの段の棚のどの商品を手に取ったかを判定する。この際、手や指の位置を、商品取得判定に利用しようとすると、カメラ位置から見て手や指が棚と重なってしまい、高さ方向が判定できない（誤った高さの商品を取得したと判定してしまう）。
そこで、棚と重なる手や指の位置情報は使用せず、棚と重ならない手首、肘または腕の任意の部分の位置座標情報から、手の位置を演算して求めることとしている。
この結果、事前のラーニング処理をより容易にし、実際の作業の時間をより迅速化し、かつエラーの発生を抑えて、出力の信頼性を高めることができる。

例えば、カメラセンサユニット１０４ａのカメラデバイス５０６ａが撮影した画面上で、骨格検出モジュールを適用することにより、顧客の上半身のうち、商品のピックアップに用いられた１つの腕の肘と手首の２つの位置について特徴点を検出し、手や指等の他の特徴点については、これらの位置に基づいて演算により求める。
好適には、カメラセンサユニット１０４ａのカメラデバイス５０６ａが撮影した画面上で、骨格検出モジュールを適用することにより、顧客の上半身のうち、左右の肘、左右の手首の４つの位置について特徴点を検出し、手や指等の他の特徴点については、これらの位置に基づいて演算により求める。

より好適には、カメラセンサユニット１０４ａのカメラデバイス５０６ａが撮影した画面上で、骨格検出モジュールを適用することにより、顧客の上半身のうち、左右の肩、左右の肘、左右の手首の６つの位置について特徴点を検出し、手や指等の他の特徴点については、これらの位置に基づいて演算により求める。
より好適には、カメラセンサユニット１０４ａのカメラデバイス５０６ａが撮影した画面上で、骨格検出モジュールを適用することにより、顧客の上半身のうち、頭部、左右の肩、左右の肘、左右の手首の計７つの位置に限定して特徴点を検出し、手や指等の他の特徴点については、これらの位置に基づいて演算により求める。
より好適には、カメラセンサユニット１０４ａのカメラデバイス５０６ａが撮影した画面上で、骨格検出モジュールを適用することにより、顧客の上半身のうち、頭部、首部、左右の肩、左右の肘、左右の手首の計８つの位置に限定して特徴点を検出し、手や指等の他の特徴点については、これらの位置に基づいて演算により求める。

図３７の（Ａ）を参照すると、従来技術で適用されていた、骨格検出モジュールの適用時の人体の特徴点が例示されている。この例では、人体のうち、上半身と下半身とから１８個の特徴点を検出している。実際の撮影画像から、これら特徴点を検出することには特有の困難があり、実際の適用時にはエラーの発生が多かった。
図３７の（Ｂ）を参照すると、本実施例における、人体の上半身の特徴点が例示されている。この例では、好適には、人体のうち、最大で、頭部（１）、首部（２）、左右の肩（３、６）、左右の肘（４、７）、左右の手首（５、８）の８つの位置（太線部）を検出して、人体の他の部位（手、首等）の位置を演算により求めることができる。
好ましくは、各特長点は、撮影画像中のピクセル座標に基づく。

好ましくは、頭部（１）の位置を検出する際、両目、両耳、鼻等の顔面の細かい特徴点については除外して、頭部（１）の検出を容易にする。
好ましくは、抽出した特徴部（頭部（１）、左右の肩（３、６）、左右の肘（４、７）、左右の手首（５、８））の位置に基づいて、首（２）の位置を演算により求める。
好ましくは、抽出した特徴部（頭部（１）、左右の肩（３、６）、左右の肘（４、７）、左右の手首（５、８））の位置に基づいて、左右の手首（５、８）から先の左右の手の位置（手の推定点）を演算により求める。
好ましくは、胸や背中の胴体の位置は検出対象から除外するが、人体の前後方向を検出または演算により求めることは可能である。

特に、肘（４、７）の位置と、手首（５、８）の位置とを抽出することにより、腕、前腕、上腕の各位置を演算により求めることができる。
この際、「腕」とは、人体のうち、肩（３、６）から手首（５、８）までの部分を指すものとする。
また、「前腕」とは、人体のうち、肘（４、７）を境に腕を２つの区間に分けて、手首（５、８）に近い方を指すものとする。
また、「上腕」とは、人体のうち、肘（４、７）を境に腕を２つの区間に分けて、肩（３、６）に近い方を指すものとする。
「前腕」と「上腕」は、肩（３、６）、肘（４、７）、手首（５、８）の三次元空間内の位置座標に基づいて、直線状に求めることができる。
好ましくは、人体の骨格構造に基づいて、「前腕」と「上腕」について、単純な直線状として求める。ただし、人体の骨格構造に基づいて、「前腕」と「上腕」について、円弧状または曲線状として求めることは可能である。

さらに、肘（４、７）から手首（５、８）までの前腕の長さを二等分する中心の位置として、「前腕中心点」を演算により求めることができる。
同様に、肘（４、７）から肩（３、６）までの上腕の長さを二等分する中心の位置として、「上腕中心点」を演算により求めることは可能である。
ただし、商品の購入プロセスで重要な役割を果たすのは、手や指の側の部位である。このため、本実施例では、特に、「前腕」と「前腕中心点」とを演算により求める。
なお、「前腕中心点」を求める替わりに、肘（４、７）から手首（５、８）までの前腕の長さを三等分して、手首（５、８）に近い方を演算により求めてもよい。
また、「前腕中心点」を求める替わりに、肘（４、７）から手首（５、８）までの前腕の長さを三等分して、肩（３、６）に近い方を演算により求めてもよい。
また、「前腕中心点」を求める替わりに、肘（４、７）から手首（５、８）までの前腕の長さを複数の区間に分割して、任意の区間を演算により求めてもよい。

さらに、「首（２）」を、人体において頭部と胴体をつなぐ部位として求めることができる。本実施例２では、左右の肩（３、６）の位置に基づいて、首（２）の位置を演算により求めてもよい。左右の肩（３、６）の長さ（肩幅）は、人体の動きによって、通常、大きく変化しないため、３次元空間内のその中間の位置座標を求めることで、水平方向での首（２）の位置を求めることができる。さらに、左右の肩（３、６）の位置を基準として、垂直方向の首（２）の位置を求めることができる。例えば、左右の肩（３、６）の位置の水平方向の中心位置であって、かつ、上方向に所定距離持ち上げた位置でもよい。この際、頭部（１）の位置と左右の肩（３、６）の位置とを用いて、首（２）の位置を求めてもよい。

なお、頭部（１）は、人体のうち最も高い位置にある、所定の大きさを有する部位として求めてもよい。これによって、例えば、髪型の変化や、帽子の有無等の相違によらず、統一的に頭部（１）の位置を求めることができるようにしてもよい。さらに、顔等の詳細については、検出対象から除外するため、比較的容易に頭部（１）の位置座標を取得することができる。なお、頭部（１）の位置を求める際、前方（顔のある方向）または後方（顔のない方向）の区別をすることは可能である。

商品のピックアップのプロセスで、とりわけ重要なのが、手首の先にある手の位置である。
「手首（５、８）」とは、人体の腕と手の掌とをつなぐ部分を指すものとする。
「手」とは、人体のうち、手首（５、８）から指先までの部分を指すものとする。腕の末端にある器官である手は、腕には含まれないものとする。
本実施例では、撮影画像上で行った画像解析により直接的に求めた肘（４、７）や手首（５、８）等の位置に基づいて、手の推定点を演算により求めることができる。

手は、開いたり閉じたりすることで、大きさを変えることができる。このため、手の推定点は、手のどの位置を基準にするかで変化する。本実施例では、実際の商品の購入プロセスを基準にして、手の推定点を求める。例えば、商品を掴む動作に注目して、掌の中心位置として、手の推定点を求めてもよい。または、商品まで最大限に届く範囲に注目して、手を開いたときの指の先端として、手の推定点を求めてもよい。または、商品をピックアップする動作に注目して、他の位置で手の推定点を求めてもよい。

例えば、「手の推定点」は、肘（４、７）の位置を基準にして、前腕の方向に沿って直線を適用したとき、肘（４、７）から手首（５、８）までの前腕の長さを所定の倍数で延長した位置として求めてもよい。
前腕に沿って、手首から先に所定倍数で延長された位置に「手の推定点」を定めることにより、実際に、顧客が商品棚に向って腕を伸ばして、商品を掴もうとする状態での手の略中心点（または手の先端）を取得する。このため、手首や指等の様々な動きにかかわらず、統一的に、商品を掴もうとする手の基準となる位置を取得する。

上記「所定の倍数」とは、本出願人による様々な試験を経て、試行錯誤的に導き出された値である。
例えば、手の推定点は、肘（４、７）を基準にして、前腕の方向に沿って、肘（４、７）から手首（５、８）までの前腕の長さを「４／３」倍に延長した位置である。
例えば、手の推定点は、肘（４、７）を基準にして、前腕の方向に沿って、肘（４、７）から手首（５、８）までの前腕の長さを「１．３３」倍に延長した位置である。
例えば、手の推定点は、肘（４、７）を基準にして、前腕の方向に沿って、肘（４、７）から手首（５、８）までの前腕の長さを「１．３」倍に延長した位置である。

上述のように、商品のピックアップの仮定では、手の大きさは様々に変化する。したがって、手の基準となる点をどのように設定するかで、所定の倍数は変化し得る。例えば、掌の中心位置を基準とするか、それとも、手を開いたときの指の先端を基準とするかで、所定の倍数は変化し得る。また、実施例の店舗内の商品棚の大きさや形状等によって、商品購入時に、手が隠される割合が変化し得る。従って、上記「所定の倍数」については、実施形態に応じて、修正を加えることは可能である。

例えば、手の推定点は、肘を基準にして、前腕の方向に沿って、肘から手首までの前腕の長さを「４／３」倍、「１．３３」倍、または「１．３」倍に延長した位置に対して、±５％程度、±１０％程度、±１５％程度、±２０％程度、または±２５％程度の範囲内で修正を加えてもよい。他、実施態様に応じて、上記「所定の倍数」に対して、より小さな割合またはより大きな割合で修正を加えることは可能である。

また、手の推定点は、肘から「前腕中心点」までの長さが、所定の倍数（例えば、８／３倍、２．６７倍、２．７倍等）で延長されることで、求められてもよい。
また、手の推定点は、「前腕中心点」から手首までの長さが、所定の倍数（例えば、８／３倍、２．６７倍、２．７倍等）で延長されることで、求められてもよい。
つまり、例えば肘から前腕中心点までを１、肘から手首までを２、手首から手までを０．６７（肘から手首／３）としたとき、肘から手までを２．６７とする。
これらの場合、所定の倍数と、その修正の割合は、前腕の長さを延長する場合と同様に求めることができる。

同様に、手の推定点は、「腕の任意の位置」から手首までの長さが、所定の倍数で延長されることで、求められてもよい。
さらに、手の推定点は、３次元空間内の１点として求められる他、３次元空間内の任意の広がり（幅／大きさ）として求められてもよい。例えば、手の推定点は、手の指先から掌の中心までの広がりとして求められてもよい。

本実施例では、男女の相違や、身長の相違や、年齢の相違によって影響を受けることなく、統一的に、顧客の「手の推定点」を求めることができる。
即ち、解剖学的には、男性と女性の間の差異は、骨格に関しては小さいとされている。同じ身長であれば、男女の区別なく、肩幅や手の大きさは、ほとんど同一であるとされている。従って、本実施例は、顧客の男女の相違にかかわらず「手の推定点」を求めることができる。

また解剖学的には、手の大きさは、身長の大きさに比例する傾向がある。一般に、身長の大きなひとは、前腕の長さも長く、手の大きさも大きい傾向にある。同様に、身長の小さなひとは、腕の長さも短く、手の大きさも小さい傾向にある。このことは、大人と子供の関係についても同様に当てはめることができる。従って、本実施例は、顧客の身長や年齢の相違にかかわらず「手の推定点」を求めることができる。

さらに、本実施例では、後述のように、「手の推定点」に関連する高さ方向の位置座標を比較的に高い精度で取得できるように工夫を加えている。
従って、本実施例では、人体の上半身に限定して検出された特徴点に基づいて、「手の推定点」を求めるため、車椅子で来店する顧客に対しても、通常に歩行する他の顧客と同様に、「手の推定点」を求めることができる。
従って、本実施例は、通常の歩行をする健常者と、車椅子で移動する障碍者との相違によって影響を受けることなく、顧客の「手の推定点」を求めることができる。

さらに、本実施例では、上述のように、人体の下半身の状態にかかわらず、「手の推定点」を求めることができる。
従って、本実施例は、通常の歩行をする健常者と、松葉杖を使って移動する障碍者との相違によって影響を受けることなく、顧客の「手の推定点」を求めることができる。
従って、本実施例は、実質的にほとんどの状況下で、統一的に顧客の「手の推定点」を求めることができる。

さらに、本実施例では、人の上半身に限定して、特徴点（頭部、肩、肘、手首）を抽出することにより、全身から複数の特徴点を抽出する場合と比較して、画像上に遠近感のズレが生じることを最小にしている。さらに、本実施例では、隠されやすい部位を検出対象から除外して、検出の容易な特徴点に絞って画像解析を行うことで、画像解析にエラーが生じることを最小にしている。

例えば、従来技術では、店舗の天井付近に設置されたカメラから、その下方の人物を撮影する場合、その人物を正面から撮影する場合と比較して、上半身と下半身とでは遠近感に相違が生じて、上半身に対して下半身がより小さく表れやすくなっていた。また、下半身は、上半身によって隠されることがあった。本実施例では、そのような不都合が生じることを最小にしている。

図３８の（Ａ）、（Ｂ）を参照すると、撮影画像に対する骨格検出モデルの適用例が示されている。この例では、店舗の天井付近に設置されたカメラ（例えば、カメラセンサユニット１０４ａのカメラデバイス５０６ａ）から、下方の人を撮影した画像に基づいて、各人の骨格検出モデルの適用例が示されている。
図３８の（Ａ）では、撮影画像上で骨格検出モデルを適用するとき、人体の骨格の特徴に基づいて、全身から複数の特徴点（例えば、１８個）を検出している（図３７の（Ａ）参照）。特にこの例では、足元で検出精度が大きな乱れが生じているのがわかる。また、手首から先の手や指の細かい部位については、検出が困難であることがわかる。

図３８の（Ｂ）では、本実施例に従って、撮影画像上で骨格検出モデルを適用するとき、上半身に限定して、より限られた数で、複数の特徴点（例えば、８個）を検出している（図３７の（Ｂ）参照）。本実施例では、検出が比較的容易な部位に限定して、人体の特徴点を検出することにより、骨格検出モデルの適用の精度の低下を回避している。さらに、検出した特徴点に基づいて、手や指の位置を演算により求めるため、単なる骨格検出モデルの適用からは取得できない位置についても取得できるようにしている。

図３９を参照すると、撮影画像に対して適用される骨格検出モデルの例が示されている。このように、通常の骨格検出モデルの適用時には、手首から先は出力されない場合がある。
前腕の方向で、手首の位置までしか検出されない場合、商品との間の距離が大き過ぎることになる。この結果、従来技術では、手首の位置に基づいて、商品のピックアップの判定を行う場合、検出誤差や設定ミスが発生しやすくなる。その結果、近くにいる他の顧客との間で、間違った商品のピックアップの判定を行うリスクが生じやすくなっていた。
本実施例では、手の推定点を演算により求めるため、そのようなリスクの発生を最小にしている。

さらに、本実施例では、「手の推定点」に関連する高さ方向の位置座標を比較的に高い精度で取得できるように工夫を加えている。
図４０の（Ａ）を参照すると、骨格検出モデルの適用時に、手首より先の部位が商品棚の天板によって隠される場合を例示している。
この状態で手首の位置を検出しようとすると、図４０の（Ｂ）に例示するように、商品棚の一部（天板等）の上に誤って手首が検出されることが起こり得る。その結果、手首の位置座標を取得するため、その画像上のピクセルの位置で高さ方向（Ｚ軸方向）の位置座標を取得しようとすると、検出対象にずれが生じることが起こり得る。
このように、カメラが天井から斜め下を撮影した場合の３次元空間内で、特にＺ軸座標（奥行の情報）では、手首の位置座標ではなく、商品棚の一部（天板等）の位置情報が誤って取得されることがある。その場合、手首の位置座標を正確に求めることができない虞がある。

本実施例では、商品の購入プロセスで、顧客が商品棚に近づく場合、その手または手首の位置情報を取得する時、手首の位置ではなく、肘と手首の間の位置を使用することができる。
例えば、肘から手首までの前腕の長さを二等分する中心の位置として、「前腕中心点」を求めて、その位置でデプス（奥行き）を取得してもよい。

実際の商品購入プロセスでは、商品棚の中にある商品を手で掴もうとする際、手や指だけでなく、手首や前腕の一部が隠されることが起こり得る。しかし、そのような場合であっても、「前腕中心点」までが商品棚の中に隠されることは少ない。
従って、本実施例では、例えば、顧客が商品棚に近づく場合、手首の位置情報（特にデプス）として「前腕中心点」の位置を求めてもよい。

ただし、デプスを取得する位置は、商品棚の各段の板の大きさ等に基づいて変化し得る。そのため、本実施例では手首のＺ軸方向の位置として、「前腕中心点」の位置を使用することに限定されない。
例えば、肘から手首までの前腕の長さを三等分して、手首に近い側または肩に近い側の位置を求めて、その位置でＺ軸方向の位置を取得してもよい。
または、肘から手首までの前腕の長さのうち、任意の位置を求めて、その位置でＺ軸方向の位置を取得してもよい。

さらに、Ｚ軸方向の位置に関して、「前腕中心点」の位置情報を取得するとともに、上半身の他の部位、例えば、肩、上腕中心点、肘などの位置情報を取得して、これらの値を組み合わせて用いてもよい。
従って、本実施例では、商品棚の任意の段の中に手を入れた場合、その上方の天板等のため、商品を掴もうとする手首より先が隠されたとしても、そのＺ軸方向の位置を比較的に正確に求めることができる。

図４１を参照すると、本実施例における手の推定点を求めるプロセスが例示されている。この工程は、骨格検出用カメラセンサユニット１０４ａの骨格検出モジュール５１０ａにより行うことができる（図５の（Ｂ）参照）。
まず、骨格検出モジュール５１０ａが、カメラデバイス５０６ａの撮影画像を入力として受信する（ステップＳ１）。この撮影画像は、例えば、ＲＧＢ画像である。

次に、骨格検出モジュール５１０ａは、その撮影画像に基づいて、所定の部位について骨格の座標（Ｘ，Ｙ座標）を取得する（ステップＳ２）。例えば、肘、手首の（Ｘ，Ｙ座標）をそれぞれ取得する。
次に、骨格検出モジュール５１０ａは、肘、手首の（Ｘ，Ｙ座標）に基づいて、「前腕中心点」の（Ｘ，Ｙ座標）を演算により求める（ステップＳ３）。
次に、骨格検出モジュール５１０ａは、「前腕中心点」及び／または肘の位置におけるデプス（Ｚ座標等）を取得する（ステップＳ４）。

次に、骨格検出モジュール５１０ａは、肘を基準として、前腕の長さを所定の倍数で延長する（ステップＳ５）。例えば、骨格検出モジュール５１０ａは、肘から「前腕中心点」までの長さ（または「前腕中心点」から手首まで）を求めて、その長さを２．６７倍延長する。その結果、骨格検出モジュール５１０ａは、「手の推定点」の座標（Ｘ，Ｙ座標）を演算により求める。
次に、骨格検出モジュール５１０ａは、肘と「前腕中心点」のＺ座標（デプス）を取得し（ステップＳ６）、これを同様に２．６７倍することで、「手の推定点」のＺ座標を演算により求める。
このように、骨格検出モジュール５１０ａは、肘と「前腕中心点」の座標から「手の推定点」の３次元空間内の位置座標（Ｘ、Ｙ、Ｚ座標）を演算により求める。

なお、肘から「前腕中心点」の長さを２．６７倍（２と２／３倍）するとは、つまり、肘から手首までの長さの１．６７倍（１と２／３倍）の位置に「手の推定点」があることを意味する。
最初からＺ座標を含めたＸ，Ｙ，Ｚ座標により手の推定点を算出することも可能であるが、こうすると棚の中に手が入っている状態では、天井から撮影したカメラからでは手のＺ座標（またはデプス）を正確に算出することができず、誤差が発生してしまう。
従って、本実施例では、手が棚の中に入っていても撮影されている肘と「前腕中心点」のＺ座標（またはデプス）を取得し、それらの間の長さを延長することで、手のＸ，Ｙ，Ｚ座標を算出する。

以上のように、本実施例では、実際に、店舗内に設置した骨格検出用カメラセンサユニット１０４ａのカメラデバイス５０６ａによって撮影された画像に基づいて、人体の上半身に限定して骨格検出モデルを適用することで、骨格検出モジュール５１０ａが頭部、首部、両肩、両肘、両手首の８個の特徴点を検出することができる。
撮影画像上で適用される骨格検出モデルについては、事前に様々な学習作業（ラーニングまたはトレーニング）が行われる。

本実施例では、店舗内での人の動き（歩行等）や、実際の商品購入プロセス等を基準として、検出の容易な特徴点（頭部、首部、両肩、両肘、両手首等）に絞って画像解析を行うことで、事前の学習作業を容易にしている。
この際、本実施例では、人体の動きを考慮する。例えば、人体は、腰を曲げたり、体を反らしたり、腕を上下させたり、腕を前後させたり、腕を組んだり等、様々な動作を行うことができる。本実施例では、店舗内で想定される人の動きに集中して学習作業を行うことで、その運用を容易にしている。例えば、店舗内での通常の歩行姿勢や、背中を丸めた姿勢等を主体として学習し、宙返り等の特殊な動作はあらかじめ学習内容から除外する。

学習作業段階では、カメラ管理端末５３０ａの骨格検出モジュール５１０ａは、特に人体の頭部、肩、肘、手首について、特徴的な形状、図形、輪郭、線、頂点、色等に基づいて、静止画の画像解析を行ってもよい。
この際、骨格検出モジュール５１０ａは、受信した静止画に対して、ピクセル毎またはピクセル集合毎で、画像を分類化してもよい。そして、ピクセル毎またはピクセル集合毎で、形状、図形、輪郭、線、頂点、色等の識別を行うことで、頭部、肩、肘、手首に関する特徴的な物標を特定してもよい。

骨格検出モジュール５１０ａは、ＡＩによる機械学習により、予め各種画像に対して画像解析のトレーニングを行うのが好ましい。特に、様々な具体例に基づいて、実際に画像解析を行って、画像から物標（形状、図形、輪郭、線、頂点、色等）を識別し抽出するトレーニングを行う。トレーニングは、例えば、数百、数千、またはそれ以上の異なる物標の画像に対して行われ、各種結果を蓄積する。その際、その結果について統計データを計算及び生成してもよい。トレーニングによって、高い識別率、例えば、９９％程度または９９．９％程度またはそれ以上の程度での識別率が得られた後で、実際に画像処理を行って、画像から物標を識別してもよい。

上記ＡＩによる機械学習により実施されるトレーニングでは、様々な画像情報を教師データとして用いてもよい。例えば、入力を静止画として、出力を特徴的な物体の形状、図形、輪郭、線、頂点、色等に関する情報とする判定モデルを機械学習により生成してもよい。
トレーニングでは、様々な時間帯における店舗内の様子を勘案してもよい。例えば、店舗内に光が差し込む日中や、店舗内の照明だけが用いられる夜中における、影の映り方の相違などを学習してもよい。また、店舗内に人がいないとき、数人だけがいるとき、大勢の人がいるときなどの、様々な店舗内の様子について学習してもよい。
この判定モデルに新たな静止画を入力することで、出力として特徴的な物標が得られるようにしてもよい。

実際の骨格検出時には、骨格検出モジュール５１０ａは、事前の学習作業時に蓄積されたデータに基づいて、特徴点ごとに信頼度を作成してもよい。
例えば、事前に学習した位置とほぼ等しい割合（約１００％や、約９９％程度）で検出位置が一致したとき、高い信頼度の情報を付与してもよい。また、事前に学習した位置と比較して、検出位置のズレが大きくなる程、より低い信頼度の情報を付与してもよい。

例えば、画像を入力として、画像中に映っている人物ごとに、特徴点（頭・首・両肩・両肘・両手首等）に関して、位置（画像中のピクセル座標）と、信頼度（０から１の値や、１から１０の値等で、数値が高いほど位置の精度が高いことが期待される値）とを表示してもよい。後者については、画像中で、関節の位置に色を変えることで表示してもよい。例えば、緑色の場合は信頼度が高く、黄色の場合は信頼度が中間で、橙色の場合は信頼度が低いことを示してもよい。色分けや、色のグラディエーションで信頼度を表示することで、どの関節の位置の信頼性が高いかについて、速やかに視認できるようにしてもよい。

本実施例では、店舗の天井または上方に設置した骨格検出用カメラセンサユニット１０４ａのカメラデバイス５０６ａによって顧客を上から見下ろすように撮影することで、被写体とカメラとの間が遮られることを最小にしている（図３６の（Ａ）参照）。しかしながら、そのような場合であっても、顧客の立ち位置や、他の顧客との重なり方などによっては、顧客の腕や肩などの体の一部が完全に撮影されない場合が起こり得る。

一方、本実施例では、好適には、店舗内に設置された各商品棚をそれぞれ最良に撮影できるように、複数のカメラデバイス５０６ａを設置している（図３６の（Ａ）参照）。そのため、少なくとも２つのカメラデバイス５０６ａによって、同一の商品棚の近くにいる顧客の様子を、それぞれ異なるＰＯＶ／ＦＯＶから、ほぼ同時に撮影することが起こり得る。
そこで、１つのカメラデバイス５０６ａからの撮影画像だけでは、ある顧客の上半身の所定の骨格が十分に検出できない場合には、骨格検出モジュール５１０ａは、他のカメラデバイス５０６ａからの撮影画像を援用して、その欠けている部分を補うようにしてもよい。

図４３の（Ａ）、（Ｂ）を参照すると、店舗内の同一の顧客について、異なる２つのカメラデバイス５０６ａのＰＯＶ／ＦＯＶから撮影された撮影画像が例示されている。
図４３の（Ａ）では、商品棚に対して正対する顧客の様子が正面側から撮影されており、一方の腕を下している様子が示されている。
図４３の（Ｂ）では、商品棚に対して正対する顧客の様子が側方から撮影されており、一方の腕を下し、他方の腕を曲げている様子が示されている。
理想的には、商品棚に対して正対した顧客を正面から撮影する図４２の（Ａ）が好ましいが、顧客の立ち位置や向き等によっては、必ずしも顧客の上半身の全体が撮影されないことが起こり得る。その場合、同一顧客をほぼ同時に撮影した他のカメラデバイス５０６ａの撮影画像を補助的に用いてもよい。

例えば、２つのカメラデバイス５０６ａによって、同一人物をほぼ同時に撮影できたと仮定する。それぞれの撮影画像を受信するカメラ管理端末５３０ａにとっては、各カメラデバイス５０６ａの位置座標は既知であり、それぞれの撮影画像上の位置座標を互いにレジストレーションまたは座標変換することができる。
例えば、図４３の（Ａ）で撮影された人物の骨格の特徴を基準とし、欠けている部分（例えば、一方の腕側の特徴部は検出できたが、他方の腕側の特徴部が検出できなかった場合）については、骨格検出モジュール５１０ａは、図４３の（Ｂ）で撮影された人物の骨格の特徴を援用する。その際、図４３の（Ｂ）の特徴部の位置座標を、図４３の（Ａ）における位置座標に変換して、図４３の（Ａ）の３次元空間内で２つの撮影画像の特徴部の位置を重ね合わせてもよい。

図４４の（Ａ）、（Ｂ）を参照すると、２つのカメラデバイス５０６ａによって撮影された画像に基づいて検出された骨格の位置を、同一座標上にまとめた例が示されている。例えば、それぞれの画像から検出された各関節が、互いの位置座標を重ね合わせることが可能なとき、それぞれを同一の関節に紐づける。

好ましくは、図４４の（Ａ）に例示するように、骨格検出モジュール５１０ａは、各カメラデバイス５０６ａから検出された関節のうち、特に頭部の座標を基準として、他の関節の位置座標をグルーピングする。そして、骨格検出モジュール５１０ａは、各カメラデバイス５０６ａから検出された頭部、首部、両肩、両肘、両手首の座標を重ね合わせることで、各カメラから検出された関節の位置座標を互いに対応付ける。
その際、２つのカメラデバイス５０６ａから取得された頭部の位置座標が互いに所定の閾値内で重ね合うとき、例えば、１００％から９９％までの範囲内、または１００％から９５％までの範囲内、または１００％から９０％までの範囲内の重なり合いが得られてとき、双方を互いに紐づける。首、肩、肘、手首などについても同様である。

図４４の（Ｂ）では、骨格検出モジュール５１０ａが、２つのカメラデバイス５０６ａから取得された各特徴部の位置座標を１つの位置座標に集約した場合を例示している。
この際、骨格検出モジュール５１０ａは、２つの３次元空間内の位置座標を１つに集約する時、あらかじめ、優先する順位を定めておく。例えば、商品棚に対して正面から撮影した静止画像に基づく特徴部の方を、商品棚に対して角度を付けて（例えば、横から）撮影した静止画像に基づく特徴部に対して、優先させてもよい。
このようにして、本実施例では、一方のカメラデバイス５０６ａのＰＯＶ／ＦＯＶから完全に撮影できなかった部分が、他方のカメラデバイス５０６ａのＰＯＶ／ＦＯＶから撮影できた場合には、骨格検出モジュール５１０ａは、その撮影された部分によって足りない部分を補完することができる。

従って、本実施例では、図４１で例示したプロセスでは、骨格検出モジュール５１０ａは、ある１つのカメラデバイス５０６ａから得られた１つの撮影画像に基づいて骨格検出モジュールを適用することによって、顧客の上半身の特徴を検出して、「手の推定点」を演算により求めてもよい。
または、本実施例では、図４１で例示したプロセスでは、骨格検出モジュール５１０ａは、２つまたは複数のカメラデバイス５０６ａから得られた２つまたは複数の撮影画像の組み合わせに基づいて骨格検出モジュールを適用することによって、顧客の上半身の特徴を検出して、「手の推定点」を演算により求めてもよい。
従って、本実施例では、様々な状況下で、顧客が商品をピックアップするときの基準となる「手の推定点」を取得することができる。

次に、「手の推定点」を用いて行われる、商品のピックアップのイベントの判定について説明する。
なお、「ピックアップ」とは、顧客の手によって、店舗内の商品棚に陳列されていた１つまたは複数の商品が取り上げられることをいう。そのときの手の形状や指の位置等は任意であり、また、取り上げられる方向または高さ等は任意である。
カメラ管理端末５３０ａの骨格検出モジュール５１０ａが取得した「手の推定点」の位置座標は、管理サーバ１０１に送信される。または、その情報は、カメラ管理端末５３０の位置検出モジュール５１０が取得した情報と統合された後、管理サーバ１０１に送信されてもよい。
管理サーバ１０１は、「手の推定点」の位置を取得することにより、３次元空間内で、既に知られている商品棚の位置（商品の位置）と、「手の推定点」の位置との相対関係を判定することができる。

上記判定は、同一の３次元空間内で、双方の３次元座標の接近度合いに基づいて行われる。
例えば、商品棚の位置（商品の位置）に対して、１００％から９０％までの範囲内、または１００％から９５％までの範囲内、または１００％から９９％までの範囲内で「手の推定点」の位置が重なっていることが判定された場合、商品棚の商品の近くに手が存在することを判定することができる。
または、例えば、商品棚の各商品と関連付けられた所定の閾値に対して、その閾値を超えて「手の推定点」が検出された場合、その商品の近くに手が存在することを判定することができる。
これらの場合、管理サーバ１０１の顧客個数判定モジュール１１０５は、商品がピックアップされるイベントの発生を推定／仮定することができる。
上述のように、商品棚と関連付けられている重量センサデバイス６０８の出力は、管理サーバ１０１の顧客個数判定モジュール１１０５に送信されている。従って、管理サーバ１０１は、さらに重量センサデバイス６０８からの出力値を組み合わせて用いることで、実際に商品がピックアップされるイベントが発生しているか否かについて、高い精度で判定することができる。

即ち、本実施例では、商品棚の各段には、それぞれの棒または板または商品かごの上に置かれた商品の重さを検出する重量センサデバイス６０８が組み込まれている（図７、図８等参照）。管理サーバ１０１の顧客個数判定モジュール１１０５は、その重量センサデバイス６０８の出力を所定間隔で周期的に受信する。通常、商品の重さ自体には、経時的な変化は起こらない。そのため、重量センサデバイス６０８が仕様通り作動している限り、管理サーバ１０１の顧客個数判定モジュール１１０５は、その商品棚に商品が置かれているか否かを常時追跡することができる。

例えば、ある商品棚に、１つ当たり５０ｇの重さの商品が２つ置かれていて、初期値を０ｇとした場合（棒や板や商品かごの重さを０ｇと仮定する場合）、その商品棚の重さは１００ｇとして検出される。
「手の推定点」が商品棚の商品の位置に重なった時点またはその前後で、該当する商品棚の重さに変化が生じたとする（例えば、１００ｇの値が５０ｇの値に変化する）。その場合、管理サーバ１０１の顧客個数判定モジュール１１０５は、それら２つのデータに基づいて、その「手の推定点」と関連付けられた顧客によって、重さの変化が生じた商品（５０ｇ＝１００ｇ－５０ｇ）がピックアップされたと判定することができる。

管理サーバ１０１の顧客個数判定モジュール１１０５は、商品棚の各段の重量センサデバイス６０８が定期的に（ループ処理で）取得している重量のデータを、「重量時系列データ（重量情報の一部）」として参照することができる。例えば、重量センサは、１００ｍｓ周期で、商品棚の各段の重量のデータを取得してもよい。
上述のように、商品棚の近くにはカメラデバイス５０６、５０６ａが設けられており、定期的に（ループ処理で）商品棚の周囲の様子を撮影することができる。
重量センサデバイス６０８が重さを検出する周期と、カメラデバイス５０６、５０６ａが画像を撮影する周期とは、一致する必要はないが、店舗内の人の動きを逐次追跡するために十分に短いものとする。

なお、カメラデバイス５０６ａは、常時、所定間隔で、周期的に商品棚の近くにいる人物の画像を撮影してもよい。
または、カメラデバイス５０６ａは、商品棚の近くに人物が接近したことを検知したとき、その出力をトリガとして、その人物の画像を撮影してもよい。
または、カメラデバイス５０６ａは、商品棚の近くに人物が接近して、かつ商品棚の方に腕を指し伸ばしたことを検知したとき、その出力をトリガとして、その人物の画像を撮影してもよい。
カメラ管理端末５３０ａまたは管理サーバ１０１は、各場合で、カメラデバイス５０６ａから送信される撮影画像の入力の受信をトリガとして、上記「手の推定点」の三次元空間内の位置座標（Ｘ、Ｙ、Ｚ座標）を演算により求めてもよい。

本実施例では、管理サーバ１０１の顧客個数判定モジュール１１０５によって行われる顧客個数判定の処理（流れ）は、以下の各ステップからなるフローを有する。
顧客個数判定モジュール１１０５は、事前に、平均的な顧客の手の位置と、商品棚中の商品セグメントまたは商品との間の距離（または、商品に対して手が接近したと判定できる閾値）を測定または算出し、その値を記憶する（前処理）。
顧客個数判定モジュール１１０５は、位置検出用カメラセンサユニット１０４のカメラデバイス５０６によって、店舗内の各顧客の位置を追跡した撮影画像を受信する。
顧客個数判定モジュール１１０５は、骨格検出用カメラセンサユニット１０４ａのカメラデバイス５０６ａによって、店舗内の各顧客の様子を撮影した撮影画像を受信する。
顧客個数判定モジュール１１０５は、カメラデバイス５０６ａからの撮影画像上で骨格検出処理モジュールが適用されて、検出された顧客の上半身の所定の特徴部に基づいて演算により求められた手の推定点の位置座標を取得する。

さらに、顧客個数判定モジュール１１０５は、一つの３次元空間内に、位置検出用カメラセンサユニット１０４からの出力と、骨格検出用カメラセンサユニット１０４ａからの出力とを互いに組み合わせてもよい。これら情報は、顧客ごとに１つの人物ＩＤに集約されて、時系列的に蓄積される。例えば、顧客個数判定モジュール１１０５は、キャリブレーション情報を利用して、（骨格検出情報中の）各顧客の手の位置を、画像内のピクセル座標から、位置追跡空間の座標に変換してもよい。
さらに、顧客個数判定モジュール１１０５は、位置追跡情報中の各顧客の位置と、骨格検出情報中の各顧客の位置を突き合わせて、骨格検出情報中の顧客の人物ＩＤを決定してもよい。

さらに、顧客個数判定モジュール１１０５は、店舗内の各商品棚の位置座標について既知である。このため、店舗内の顧客のうちの誰が、何処の商品棚に向って手を伸ばしているのかを判定することができる。例えば、管理サーバ１０１は、手の推定点と、商品セグメントまたは商品の位置との間の距離（以下、手セグメント距離）を計算する。
さらに、顧客個数判定モジュール１１０５は、商品を展示する各商品棚の重量時系列データを受信し、継続的に、商品の重量の時系列変化を分析する。

図６２を参照すると、骨格検出用カメラセンサユニット１０４ａの出力、位置検出用カメラセンサユニット１０４の出力、及び重量センサユニット１０５の出力が、管理サーバ１０１の顧客個数判定モジュール１１０５に送信される別の例が示されている。
骨格検出用カメラセンサユニット１０４ａは、店舗内を撮影することで、ＲＧＢ画像とＤｅｐｔｈ画像（深さ画像）とを取得する。これら画像は、エッジデバイス側で、骨格検出モジュール５１０ａによって処理することができる。

なお、以下の処理は、エッジデバイス側から管理サーバ１０１側（クラウド側）に画像を送信した後、サーバ側で処理を行う構成であってもよい。
まず、ステップＸ１で、ＲＧＢ画像に対して、骨格検出モデルを適用することで、人体の骨格モデルに基づいて、所定の特徴部（頭部、首部、両肩、両肘、両手首のうちの全てまたは任意の一部、以下同様）のＸ、Ｙ座標を取得することができる。

一方、ステップＸ２で、Ｄｅｐｔｈ画像に対して、座標変換歪み補正を適用することで、Ｄｅｐｔｈ画像をＲＧＢ画像に対応付けることができる。ステップＸ３で、これら双方を組み合わせることで、所定の特徴部のＸ、Ｙ座標とＤｅｐｔｈ情報（Ｚ座標）とを統合することができる。
さらに、ステップＸ４で、この結果に対して座標変換歪み補正を適用することで、ＲＧＢ画像上でのＸ、Ｙ座標の歪みを補正できる。この結果、カメラ座標として、所定の特徴部のＸ、Ｙ座標とＤｅｐｔｈ情報（Ｚ座標）とを取得することができる。さらに、ステップＸ５で、この位置情報に基づいて、所定の演算を行うことで、手の推定位置の座標を求めることができる。従って、最終的に、骨格の所定の特徴部と手の推定点のＸ、Ｙ、Ｚのカメラ座標を取得することができる。

位置検出用カメラセンサユニット１０４は、ステップＹ１に示すように、店舗内を撮影することで、人物に対して、ＩＤと、ＴｏＦ座標として、Ｘ、Ｙ、Ｚ座標を取得することができる。この画像は、ＰＣ等のエッジデバイス側で、位置検出モジュール５１０によって処理される。一方、ステップＹ２で、位置検出用カメラセンサユニット１０４は、骨格検出用カメラセンサユニット１０４ａからの出力を受信して、骨格の所定の特徴部と手の推定点のＸ、Ｙ、Ｚのカメラ座標を取得することができる。

さらに、ステップＹ３で、この結果に対して座標変換補正を適用することで、カメラ座標をＴｏＦ座標に対応付けることができる。さらに、ステップＹ４で、同一空間内で、ステップＹ１とＹ３の出力を組み合わせることで、骨格と人物とを対応付けることができる。従って、最終的に、人物（顧客）のＩＤ、頭部、手の推定点のＴｏＦ座標としてのＸ、Ｙ、Ｚ座標を取得することができる。

さらに、重量センサユニット１０５の重量センサデバイス６０８は、重さのデータを時系列的に取得する。ステップＺ１に示すように、このデータは、ＲａｓｐｂｅｒｒｙＰｉ（登録商標）等のエッジデバイス側で、モジュール６１０によって処理される。
管理サーバ１０１の顧客個数判定モジュール１１０５は、予め取得している店舗内の商品棚の商品の位置と、位置検出用カメラセンサユニット１０４から取得した人物（顧客）のＩＤ、頭部、手の推定点のＴｏＦ座標としてのＸ、Ｙ、Ｚ座標と、重量センサデバイス６０８から取得した時系列的な重さのデータとを受信する。従って、これらデータを組み合わせて用いることで、顧客の商品のピックアップの判定を行うことができる。

従って、顧客個数判定モジュール１１０５は、短時間のうちに、連続して商品が取られるような変化が生じたとき、どの時間に、何個の商品が、誰によってピックアップされたのかを判定することができる。
よって、本実施例では、複数の顧客が、同時またはほぼ同時に、互いに近接する単数または複数の商品をピックアップするとき、どの顧客が、どの商品を幾つピックアップしたのかを判定することができる。
以下、重量センサデバイス６０８の出力と手の推定点とを用いて、商品のピックアップの判定について、より具体的に説明する。

図４５を参照すると、顧客個数判定モジュール１１０５に送信される、重量センサデバイス６０８の出力の変化と、顧客の手の推定点と棚との間の距離の変化とが重ね合わせて例示されている。
図４５の上方には、各商品棚の重量時系列データの例がグラフで示されている。このグラフの横軸には、時間（ｍｓ）が取られ、縦軸には、重量センサデバイス６０８が記録した値（ｇ）が取られている。

図４５の下方には、上記重量センサデバイス６０８を備えている商品棚の近くにいる２人の顧客（ユーザ）について、それぞれの手の推定点の位置と棚との間の距離の変化がグラフで示されている。このグラフの横軸には、時間（ｍｓ）が取られ、縦軸には、各ユーザの手の推定点と棚（又は商品でも構わない）との間の距離（ｍｍ）の変化（手の推定点と商品棚の位置との相互関係）が取られている。顧客個数判定モジュール１１０５は、手の推定点と棚の間の距離が閾値を下回った場合には、そのあたりで商品を取った可能性があるものと判定する。
なお、各ユーザには、それぞれ、１と２の人物ＩＤ（識別番号）が付与されている。

図４５を参照すると、ｔ０からｔ２（ｍｓ）までの間では、重量センサデバイス６０８の出力に変化がないことが読み取れる。このため、この期間では、顧客個数判定モジュール１１０５は、商品棚の商品には変化が起きていないことを推測できる。
ｔ２からｔ４（ｍｓ）までの間で、重量センサデバイス６０８の出力の低下が記録されている。この期間、最終的に、５０ｇの重量センサデバイス６０８の出力の低下が記録されている。従って、顧客個数判定モジュール１１０５は、この差分の重さ（５０ｇ）に相当する１つまたは複数の商品がピックアップされたことを推測できる。

ｔ４からｔ７（ｍｓ）までの間で、重量センサデバイス６０８の出力が大きく低下した値を維持していることが読み取れる。このため、この期間では、顧客個数判定モジュール１１０５は、商品棚の商品には変化が起きていないことが推測できる。
なお、グラフでは、重量センサデバイス６０８の出力が簡略化して直線状に示されている。実際には、商品棚の棒にフック状にかけられている商品がピックアップされるとき、棒に負荷が加わるため、重量センサの出力は直線にはならない。商品棚の板や商品かごの上に商品が置かれている場合も同様である。

本実施例では、顧客個数判定モジュール１１０５は、ユーザ１、ユーザ２の各手セグメント距離と重量時系列データの時刻とを組み合わせて判定している。
この例では、ユーザ１は、時刻ｔ１付近までは、手の推定点が商品棚から離れていたが、時刻ｔ１付近からｔ５付近までの間では、手の推定点が商品棚に近づいているのがわかる。
なお、時刻ｔ１とは、ユーザ１が手を商品棚に向って指し伸ばし始めた後、手と棚との間の距離が所定の閾値を下まわり（または上まわり）、商品セグメントまで手を近づけたと判定されたときの時刻である。

また、時刻ｔ５とは、手を商品セグメントまで近づけた状態から、手を商品棚から離れるように戻し始めた後、手と棚との間の距離が所定の閾値を超えて、商品セグメントから手を遠ざけたと判定されたときの時刻である。
なお、グラフでは、手の推定点の出力が簡略化して直線状に示されている。実際には、まっすぐな軌跡にはならないことを理解されたい。

同様に、ユーザ２は、時刻ｔ３付近までは、手の推定点が商品棚から離れていたが、時刻ｔ３付近からｔ６付近までの間で、手の推定点が商品棚に近づいているのがわかる。
なお、時刻ｔ３とは、ユーザ１が手を商品棚に向って指し伸ばし始めた後、手と棚との間の距離が所定の閾値を下まわり（または上まわり）、商品セグメントまで手を近づけたと判定されたときの時刻である。

また、時刻ｔ６とは、手を商品セグメントまで近づけた状態から、手を商品棚から離れるように戻し始めた後、手と棚との間の距離が所定の閾値を超えて、商品セグメントから手を遠ざけたと判定されたときの時刻である。
なお、ユーザ１とユーザ２のグラフ上の縦軸の大きさの相違は、各顧客と商品棚との間の距離の相違に基づく。
なお、閾値は、商品棚の構成、商品の大きさ等を考慮して、任意の値として設定することができる。

顧客個数判定モジュール１１０５は、上記グラフに基づいて、時刻ｔ２からｔ４までの間で、重量センサデバイス６０８の出力に変化が生じていることがわかり。このことから、顧客個数判定モジュール１１０５は、特にこの期間中に、商品のピックアップのイベントが発生したことを推定できる。
ただし、顧客個数判定モジュール１１０５は、この期間中、その商品の近くに、ユーザ１の手の推定点と、ユーザ２の手の推定点とが存在していたことを理解できる。
従って、顧客個数判定モジュール１１０５は、ユーザ１とユーザ２のいずれかによってその商品のピックアップが行われたのかを判定するための処理を行う。

本実施例では、顧客個数判定モジュール１１０５は、誰が、どの商品をいくつピックアップしたのかを判定するための演算を行う。特に、顧客個数判定モジュール１１０５は、重量変化の起きた期間（時刻ｔ２から時刻ｔ４まで）をユーザごとに分割して、各時間区間の両端の重量の差を計算し、そのユーザが取った重量として紐付ける。
即ち、顧客個数判定モジュール１１０５は、ユーザごとに手伸ばしの区間を推定し、その両端の重量変化を取得する。
例えば、顧客個数判定モジュール１１０５は、重量の変化が生じた期間として、時刻ｔ２と時刻ｔ４とを取得する。

また、ユーザ１について、商品のピックアップを可能とする手の移動が生じた期間（手伸ばしの区間）として、時刻ｔ１と時刻ｔ５とを取得する。
また、ユーザ２について、商品のピックアップを可能とする手の移動が生じた期間（手伸ばしの区間）として、時刻ｔ３と時刻ｔ６とを取得する。
管理サーバ１０１は、これら情報を時系列的にまとめて、対比して、ユーザごとの動きがより明確になるように、期間（時刻ｔ２から時刻ｔ４まで）を分割する。

まず、顧客個数判定モジュール１１０５は、時刻ｔ１から時刻ｔ３までの期間では、主にユーザ１の手の動きが問題となり、ユーザ２の手の動きは問題ではないと判定する。
また、顧客個数判定モジュール１１０５は、時刻ｔ３から時刻ｔ４までの期間は、主にユーザ１とユーザ２の手の動きが問題になると判定する。
従って、顧客個数判定モジュール１１０５は、重量の変化が起きた期間（ｔ２からｔ４まで）を、各ユーザの手の動きに基づいて、第１の区間（ｔ２からｔ３まで）と、第２の区間（ｔ３からｔ４まで）とに分割する。
そして、顧客個数判定モジュール１１０５は、第１の期間（ｔ２からｔ３まで）では、主にユーザ１の手の動きが、重量変化に寄与していると推測する。
また、顧客個数判定モジュール１１０５は、第２の期間（ｔ３からｔ４まで）では、主にユーザ１とユーザ２の手の動きが、重量変化に寄与していると推測する。

さらに、顧客個数判定モジュール１１０５は、上記期間（ｔ２からｔ４まで）の分割に対応して、重量についても分割する。即ち、顧客個数判定モジュール１１０５は、商品の重量の変化（全体で５０ｇとする）が直線的に生じたと仮定して、この重量の変化を第１の区間と第２の区間とに分けて、比例演算する。
例えば、顧客個数判定モジュール１１０５は、第１の区間については、全体で５０ｇとしたとき、３５ｇ相当の重さの変化が生じたことを算出する。さらに、この重さの変化（３５ｇ）を、ユーザ１だけに紐づける。
また、顧客個数判定モジュール１１０５は、第２の区間については、全体で５０ｇとしたとき、１５ｇ相当の重さの変化が生じたことを算出する。さらに、この重さの変化（１５ｇ）を、ユーザ１とユーザ２の双方に紐づける。

次に、顧客個数判定モジュール１１０５は、ユーザごとに想定可能な重量を合計して、（予め登録されている）商品の重量と比較して、商品の個数に変換する。
例えば、顧客個数判定モジュール１１０５は、第１の期間（ｔ２からｔ３まで）では、重量センサの変化分（３５ｇ）は、ユーザ１だけに紐づけられている。この期間については、管理サーバ１０１は、ユーザ１とユーザ２とに場合分けする必要がない。
しかし、第２の期間（ｔ３からｔ４まで）では、重量センサの変化分（１５ｇ）は、ユーザ１とユーザ２に紐づけられている。この期間については、顧客個数判定モジュール１１０５は、その重量がユーザ１とユーザ２のどちらに起因するのかについて、場合分けして検討する必要がある。

顧客個数判定モジュール１１０５は、最終的には、５０ｇ相当の商品がピックアップされたことを知っている。そこで、顧客個数判定モジュール１１０５は、第２の期間（ｔ３からｔ４まで）については、上記ユーザ１のみに紐づけられた断片的な重さを差し引いた分（５０ｇ－３０ｇ＝１５ｇ）を、ユーザ１とユーザ２とにそれぞれ紐づけて、その結果を対比する。

例えば、顧客個数判定モジュール１１０５は、仮定１として、第２の期間（ｔ３からｔ４まで）では、ユーザ１によって１５ｇ相当の重さがピックアップされたと仮定する。この場合、最終的に、ユーザ１によって（５０ｇ＝３５ｇ＋１５ｇ）の商品がピックアップされ、ユーザ２によって（０ｇ＝０ｇ＋０ｇ）の商品がピックアップされたと仮定する。
また、顧客個数判定モジュール１１０５は、仮定２として、第２の期間（ｔ３からｔ４まで）では、ユーザ２によって１５ｇ相当の重さがピックアップされたと仮定する。この場合、最終的に、ユーザ１によって（３５ｇ＝３５ｇ＋０ｇ）の商品がピックアップされ、ユーザ２によって（１５ｇ＝０ｇ＋１５ｇ）の商品がピックアップされたと仮定する。

次に、顧客個数判定モジュール１１０５は、各仮定１、２について、最終的に推定された重さの変化を、商品１個当たりの重さ（５０ｇ）で除算する。
仮定１については、顧客個数判定モジュール１１０５は、ユーザ１によって、１．０個分（＝５０ｇ／５０ｇ）の商品がピックアップされるとともに、ユーザ２によって０．０個分（＝０ｇ／５０ｇ）の商品がピックアップされたことを判定する。
仮定２については、顧客個数判定モジュール１１０５は、ユーザ１によって、０．７個分（＝３５ｇ／５０ｇ）の商品がピックアップされるとともに、ユーザ２によって０．３個分（＝１５ｇ／５０ｇ）の商品がピックアップされたことを判定する。

なお、商品のピックアップ時には、商品棚の棒や板や商品かごに負荷がかかるため、重量センサの読み取り値は、完全な直線ではなく、変動が生じ得る。そこで、顧客個数判定モジュール１１０５は、予め、商品１個当たりの許容誤差を定めておくのが好ましい。例えば、５０ｇの商品については、±０．２個分（１０ｇ）の誤差を許容できるものとする。

次に、顧客個数判定モジュール１１０５は、各仮定１、２について、商品１個当たりの許容誤差の範囲内にあるか否かの判定を行う。
仮定１については、ユーザ１、２の双方について、許容誤差の範囲内にあることを判定できる。
仮定２については、ユーザ１、２の双方について、許容誤差の範囲外にあることを判定できる。
従って、顧客個数判定モジュール１１０５は、最終的に、ユーザ１によって、１個当たり５０ｇの商品がピックアップされ、ユーザ２によっては、商品はピックアップされなかったものと判定できる。

上記顧客個数判定モジュール１１０５の判定で用いられる許容誤差については、様々に設定することができる。
例えば、重量変化が１００ｇであって、２個分の許容誤差（５０×２±１０×２）内にある場合（２．０個分）、ピックアップされた商品の個数を２個として確定してもよい。
また、重量変化が１０５ｇであって、２個分の許容誤差（５０×２±１０×２）内にある場合（２．１個分）、ピックアップされた商品の個数を２個として確定してもよい。
また、重量変化が１２５ｇであって、２個分の許容誤差（５０×２±１０×２）内にない場合（２．５個分）、ピックアップされた商品の個数を２個として確定しないで、不確定としてもよい。
また、重量変化が１６０ｇであって、３個分の許容誤差（５０×３±１０×３）内にある場合（３．２個分）、ピックアップされた商品の個数を３個として確定してもよい。

本実施例では、重量個数の変換処理について、より細分化した制御を適用することができる。
重量センサデバイス６０８の特性として、一般に、重量変化の幅が大きいほど、誤差が相対的に小さくなる傾向がある。そこで、本実施例では、重量センサデバイス６０８からの重量変化が大きいときは、許容する誤差を相対的に小さくしてもよい。例えば、図４６を参照すると、商品１個あたりの重量が１００ｇとした場合の、重量変化がマイナス（商品が取られた）の場合について、１個から９個までの各値の変化を例示している。この値は、上記顧客個数判定モジュール１１０５の判定処理で援用されるものとする。

図４６では、左端から、ピックアップされた商品の個数、その重量変化の目標値（正数）、実際に生じた重量変化の測定値、許容可能な全体の差分、許容可能な１個当たりの差分を示している。同図から理解できるように、例えば、１個の商品がピックアップされたときの、その１個当たりの許容可能な差分を１５ｇであることが理解できる。このピックアップされる数が増えるにつれて、その１個当たりの許容可能な差分は減少していき、例えば、９個の商品がピックアップされたときの、その１個当たりの許容可能な差分を６．２２ｇであることが理解できる。

このように、顧客個数判定モジュール１１０５は、ピックアップされる商品の重量（数）に応じて、商品がいくつピックアップされたのかを判定する段階で判定の基準となる数値を細かく設定することができる。これにより、重量センサの特性に基づいて、ピックアップされる数が増えるにつれて、その判定精度を向上させることができる。なお、図４６では、ピックアップされる商品の数が１個から９個までの範囲内に限定している。この範囲を超える場合には、判定人等による判定を行ってもよい。または、より多くの数の範囲に対応できるように、図４６に示した範囲を拡張してもよい。

なお、ピックアップされる商品の重量（数）に応じて、より重くなる程、より精度の高い判定基準を適用する結果、一部の範囲内で、適用基準が重なり合うことが起こり得る。例えば、７個の許容可能な全体の差分（６４８ｇ～７５２ｇ）と、８個の許容可能な全体の差分（７４６ｇ～８５４ｇ）との間で、一部重複している（７４６ｇ～７５２ｇ）。この場合、顧客個数判定モジュール１１０５は、個数の少ない方から優先的に判定を適用することで、結果が重複（混合）することを回避する。例えば、この場合、７つの個数を優先的に適用する。

図６３を参照すると、上記顧客個数判定モジュール１１０５の判定のフロー６３００について簡略化して示している。図４５に例示したグラフを再度参照して、図６３のフローについて説明する。
まず、ステップ６３１０で、顧客個数判定モジュール１１０５は、ユーザごとに手伸ばしの区間を取得する。
例えば、ユーザ１については、商品に手を近づけた手伸ばしの区間として、時刻ｔ１と時刻ｔ５との間の区間を取得する。ユーザ２については、商品に手を近づけた手伸ばしの区間として、時刻ｔ３と時刻ｔ６との間の区間を取得する。
次に、ステップ６３２０で、ユーザごとに紐づけられる手伸ばしの区間の場合分けをする。
例えば、時刻ｔ１と時刻ｔ３との間の区間１は、ユーザ１にだけ紐づけることができる。また、時刻ｔ３と時刻ｔ５との間の区間２は、ユーザ１とユーザ２に重複して紐づけることができる。また、時刻ｔ５と時刻ｔ６との間の区間３は、ユーザ２にだけ紐づけることができる。

次に、ステップ６３３０で、場合分けをした各区間の両端の重量変化を取得する。
例えば、区間１については、３５ｇの重量変化を取得する。区間２については、１５ｇの重量変化を取得する。区間３については、０ｇの重量変化を取得する。
次に、ステップ６３４０で、複数のユーザに紐づけられた区間について、その重量変化を各ユーザに振り分けた場合の仮定を行う。
例えば、区間１については、ユーザ１についてだけ３５ｇの重量変化を取得する。区間２については、ユーザ１、２について１５ｇの重量変化を取得するので、各ユーザ１，２について１５ｇの重量変化が振り分けられたと仮定する（上記仮定１、仮定２を参照）。

次に、ステップ６３５０で、商品１個あたりの重さに関して、上記仮定の妥当性の判定を行う。
例えば、仮定１については、ユーザ１にのみ５０ｇの商品が振り分けられるので、商品１個の重さ５０ｇとの対比から、妥当であると判定する。また、仮定２については、ユーザ１に３５ｇの商品が振り分けられ、ユーザ２に１５ｇの商品が振り分けられるので、商品１個の重さ５０ｇとの対比から、妥当でないと判定する。

どのユーザが、どの商品を幾つピックアップしたかについて、顧客個数判定モジュール１１０５で行われる判定は、図６３のフローに限定されない。
例えば、図６４を参照すると、顧客個数判定モジュール１１０５の判定のフロー６４００の他の例について簡略化して示している。
この例では、まず、ステップ６４１０で、顧客個数判定モジュール１１０５は、ユーザごとに手伸ばしの区間を取得する。

次に、ステップ６４２０で、顧客個数判定モジュール１１０５は、ユーザごとに手伸ばしの区間の両端の重量変化を取得する。
次に、ステップ６４３０で、顧客個数判定モジュール１１０５は、ユーザごとに商品１個あたりに占める重量変化の割合を取得する。
次に、ステップ６４４０で、顧客個数判定モジュール１１０５は、すべてのユーザについて重量変化の割合を比較する。

図６５を参照すると、図６４に例示したフローの出力例が示されている。
この例では、店舗内のある商品（１５０ｇ相当）の近くに３人の顧客がいて、それぞれ、＃１、＃２、＃３のＩＤが付与されている。
顧客ごとにその商品の近くに手を伸ばしていた期間を求め、その期間に対応する重量変化量の割合を求めている。
例えば、１つあたり１５０ｇの商品に対して、顧客＃１については２０ｇ分の重量変化量が求められ、顧客＃２については１２０ｇ分の重量変化量が求められ、顧客＃３については１０ｇ分の重量変化量が求められている。

そこで、顧客個数判定モジュール１１０５は、これら３つの重量変化量の割合を対比することで、顧客＃２によってその商品がピックアップされたものと推定することができる。
図６５に示すように、ユーザごとに手伸ばし区間の重量変化分をグラフ状に表示することで、その視覚的な対比を容易にしてもよい。この出力は、ユーザ端末の画面等に表示してもよい。表示態様は図６５に限定されず、他、円グラフ等で表示してもよい。
本実施例では、どのユーザが、どの商品を幾つピックアップしたかについて、顧客個数判定モジュール１１０５で行われる判定は、図６３、図６４のフローに限定されない。図６３、図６４に例示したフローについては、様々な修正、変更が可能である。

なお、顧客個数判定モジュール１１０５は、重量センサユニット１０５による情報やカメラセンサユニット１０４、カメラセンサユニット１０４ａによる映像により、顧客の購入した商品及びその個数を判定できない場合には要チェックリストに情報を記憶するのが好ましい。
例えば、顧客個数判定モジュール１１０５は、重量の変化量の検知が怪しい場合や、カメラデバイス５０６からの位置情報の検知、カメラデバイス５０６ａからの撮影画像に基づく手の推定点の演算が旨く行かない場合や、映像が隠れてしまい判別できていない場合等のイレギュラーな事象が発生する場合、最終的に人間によるチェックを行うための要チェックリストに情報を記憶する。これにより、顧客個数判定モジュール１１０５側で判別しきれない場合には、後から人間が補佐を行うことで精度の高い買い物体験を実現することができる。決済処理自体は退店後に実行されるため利用者の顧客体験は損なわれることを最小にする。

管理サーバ１０１は、上記顧客個数判定モジュール１１０５のフローで十分な判定ができない場合は、判定不能として、各ユーザの端末に適当なインストラクションを表示するのが好ましい。
例えば、顧客個数判定モジュール１１０５が十分な判定できなかった商品については、店員によって、問題の生じたユーザに問い合わせをして、どの商品をピックアップしたかについて問い合わせを行うためのインストラクションを表示してもよい。

有人店舗または無人店舗のいずれの場合であっても、後処理で、各ユーザがそれぞれ自己申告でどの商品をピックアップしたかについて選択してもらってもよい。この後処理は、ユーザが退店する前に行うのが好ましいが、ユーザが退店した後で行うことも可能である。
このように、顧客個数判定モジュール１１０５が商品のピックアップについて十分な判定ができなかった場合には、ユーザの協力を求めて、その問題を解決するのが好ましい。ユーザの協力を求めるためのインストラクションの表示は、様々に行うことができる。例えば、判定できなかった商品については、「確認中です」等と端末に表示して、ユーザに確認してもらってもよい。

図４７を参照すると、管理サーバ１０１によって行われる商品のピックアップの判定の他の例が示されている。
図４５の例では、１つの商品がピックアップされている。実際の商品の購入プロセスでは、複数の商品が連続的にピックアップされることが起こり得る。そのような場合であっても、本実施例では、取った商品の個数を計算することを可能にしている。
なお、図４７の例では、図４５、図４６、図６３、図６４を参照して上述した判定内容をすべて備えることができる。

図４７を参照すると、重量センサの出力の変化と、２人のユーザの手の推定点の変化とが重ね合わせて示されている。
同図には、各商品棚の重量時系列データの例がグラフで示されている。このグラフの横軸には、時間（ｍｓ）が取られ、左側の縦軸には、重量センサが記録した値（ｇ）が取られている。

同図には、上記重量センサデバイス６０８を備えている商品棚の近くにいる２人のユーザについて、それぞれの手の推定点の変化例がグラフで示されている。このグラフの横軸には、時間（ｍｓ）が取られ、右側の縦軸には、各顧客の手と商品との間の距離（ｍｍ）が取られている。
なお、各ユーザには、それぞれ、ＡとＢの人物ＩＤ（識別番号）が付与されている。

商品棚の棒にフック状にかけられている商品がピックアップされるとき、棒に負荷が加わるため、重量センサデバイス６０８の出力は、一様にはならない。商品棚の板や商品かごの上に商品が置かれている場合も、同様である。
図４７を参照すると、凡そ、１５００ｍｓから２５００ｍｓまでの間では、重量センサデバイス６０８の出力に変化はなく、このため、顧客個数判定モジュール１１０５は、商品棚の商品には変化が起きていないことが推測できる。
２５００ｍｓから３８００ｍｓまでの間で、重量センサデバイス６０８の出力の低下を記録している。このため、顧客個数判定モジュール１１０５は、商品棚の商品をピックアップしたこと（またはピックアップしようとしたこと）を推測できる。

３８００ｍｓから５０００ｍｓまでの間で、重量センサデバイス６０８の出力が瞬間的な跳ね返りとともに大きな低下を記録するとともに、５０００ｍｓから６０００ｍｓまでの間で、重量センサデバイス６０８の出力が安定している。このため、顧客個数判定モジュール１１０５は、商品棚の商品がピックアップされたことが推測できる。
この期間、最終的に、凡そ、３００ｇから８０ｇまで重量センサデバイス６０８の出力が低下している。このため、顧客個数判定モジュール１１０５は、この差分の重さ（２２０ｇ程度）の１つまたは複数の商品がピックアップされたことを推定できる。

上記重量センサの出力の変化が起きた期間中、顧客個数判定モジュール１１０５は、問題の商品の近くに２人のユーザの手の動きがあったことを理解できる。
そこで、顧客個数判定モジュール１１０５は、各ユーザＡ、Ｂの手セグメント距離と重量時系列データの時刻を合わせる。そして、手セグメント距離情報から、各顧客が該当するセグメントに手を伸ばしている期間（手伸ばしの区間）を決定する。その際、各ユーザＡ、Ｂについて、所定の閾値を超えて、手の動きがあったか否かの判定を行う。

特に、顧客個数判定モジュール１１０５は、手伸ばしの区間を推定し、その両端の重量変化を取得する。
例えば、顧客個数判定モジュール１１０５は、ユーザＡについては、凡そ、２２００ｍｓから３１００ｍｓまでの期間内、その商品棚の商品の近くに、手の推定点が位置していることがわかる。
また、顧客個数判定モジュール１１０５は、顧客Ｂについては、凡そ、３６００ｍｓから４５００ｍｓまでの期間内、その商品棚の商品の近くに、手の推定点が位置していることがわかる。
次に、顧客個数判定モジュール１１０５は、各期間で、両端の重量の差を計算し、関連するユーザが取った重量として紐付ける。
この際、顧客個数判定モジュール１１０５は、ユーザごとに重量を合計し、（予め登録されている）商品の重量と比較して、商品の個数に変換する

例えば、顧客個数判定モジュール１１０５は、以下の各ステップを含む処理を行う。
顧客個数判定モジュール１１０５は、あらかじめ、商品１個あたりの重量と、許容する誤差の割合を設定して、記憶装置内に該当するデータを保存している。例えば、商品１個あたりの重量が５０ｇの場合、許容する誤差の割合を０．２個分（１０ｇ）として設定する。
次に、顧客個数判定モジュール１１０５は、商品棚に組み合わせた重量センサデバイス６０８によって、商品がピックアップされたとき、その重量の変化を示す数値（ｇ）を受信する。

次に、顧客個数判定モジュール１１０５は、変化した重量の数値（ｇ）を、あらかじめ記憶しているその商品１個あたりの重量（ｇ）で割る演算を行う。
次に、顧客個数判定モジュール１１０５は、上記演算結果を、あらかじめ記憶しているその商品の誤差の割合と対比する。
上記対比の結果、許容誤差割合以内であることが導かれた場合、顧客個数判定モジュール１１０５は、その個数を確定する。

例えば、顧客個数判定モジュール１１０５は、時刻ｔ１１から時刻ｔ１２までの期間では、主にユーザＡの手の動きを問題とする。この期間、ユーザＢの手の動きが認められるものの、商品セグメントからの距離が遠いため、その手の動きを無視することができる。さらに、顧客個数判定モジュール１１０５は、この期間では、約１００ｇ（３００ｇ－２００ｇ）の重さの変化があったことを知得する。
また、顧客個数判定モジュール１１０５は、時刻ｔ１３から時刻ｔ１４までの期間では、主にユーザＢの手の動きを問題とする。さらに、この期間では、約１２０ｇ（２００ｇ－８０ｇ）の重さの変化があったことを知得する。

これらから、顧客個数判定モジュール１１０５は、ユーザＡによって１００ｇ相当の重さの商品がピックアップされ、その後、ユーザＢによって１２０ｇ相当の重さの商品がピックアップされたことを仮定できる。
そこで、顧客個数判定モジュール１１０５は、その商品セグメントにある商品の記憶されている重さによって、上記仮定の検証を行う。
上記検証の結果、許容誤差から外れたことが導かれた場合、顧客個数判定モジュール１１０５は、その個数を不確定とし、逆の場合には確定とする。

以上のように構成されることで、本実施例では、商品のピックアップのイベントが発生した場合に、その周囲に複数のユーザがいた場合、どのユーザが、いくつの商品をピックアップしたかについて判定することができる。
さらに、本実施例では、管理サーバ１０１の顧客個数判定モジュール１１０５は、重量センサデバイス６０８の出力に基づく重量変化が理想的な場合から外れていても、商品のピックアップの判定を可能にするための工夫を行っている。

例えば、図４８、図４９を参照すると、さらに重量センサの出力例が示されている。
これら図に示された例では、図４５、図４７と同様に、重量センサの出力の変化と、２人のユーザの手の推定点の変化が重ねて示されている。
なお、図４８、図４９の例では、図４５、図４６、図４７、図６３、図６４を参照して上述した判定内容をすべて備えることができるが、記載の重複を避けるため、重複部分についての説明は割愛する。

図４８の例では、重量が落ちきるまで、比較的に長い時間（２秒程度）かかっている。
図４９の例では、一度に１つの商品をピックアップしただけにも関わらず、重量が上がったり下がったりしている。図４８、図４９に示すように、重量センサデバイス６０８の出力は、必ずしも、重量変化が理想的なものとはならない。
商品棚の棒、板、商品かご等にセンサ（重量センサデバイス６０８等）を組み込んで、その重さを測定または算出するとき、そのピックアップ時に棒、板、商品かご等に負荷がかかり、重さの数値には変動が生じ得る。その結果、重量センサデバイス６０８の出力の重さの変化に時間がかかることがある。また、重さの変化に上下の変動が生じることがある。
これらの場合、従来技術では、重量センサデバイス６０８の重量情報のみでは、どの時刻に、いくつの商品がピックアップされたかについての判別が難しい場合があった。

本実施例では、上記の場合、管理サーバ１０１の顧客個数判定モジュール１１０５は、問題の商品棚の近くにいる各ユーザの手の推定点を追跡する。手の推定点は、所定の閾値と対比されることで、その手が商品の近くまで伸ばされているか否かについて判定される。従って、管理サーバ１０１は、各ユーザの手伸ばしの区間を推定する。顧客個数判定モジュール１１０５は、各区間の両端の時刻に関して、重量センサデバイス６０８等からの出力を参照することができる。このため、顧客個数判定モジュール１１０５は、各ユーザの手伸ばしの区間の両端の重量変化を取得することができる。

顧客個数判定モジュール１１０５は、各ユーザについて、重量変化から個数に変換する場合分けを行うことができる。例えば、１人のユーザについてのみ手の推定点の変化が検出された場合には、そのユーザについてのみ、重量変化から個数に変換する。また、２人または複数のユーザについてのみ手の推定点の変化が検出された場合には、ユーザごとに場合分けをして、各重量変化から個数に変換する。顧客個数判定モジュール１１０５は、場合分けごとに、最終的に得られた重量の変化との間で妥当か否かの判定を行う。

例えば、図４８に例示するように、重量の変化に時間がかかる場合でも、各ユーザの
手伸ばしの区間を推定し、その両端の重量変化を取得することで、そのような重さの変化に対応することができる。
また、図４９に例示するように、重量の変化に変動が生じる場合でも、各ユーザの
手伸ばしの区間を推定し、その両端の重量変化を取得することで、そのような重さの変化に対応することができる。
従って、顧客個数判定モジュール１１０５は、重量センサデバイス６０８の出力が理想的でなくても、ピックアップされた商品の個数を判定することができる。

実際には、重量センサデバイス６０８の出力や、演算によって求められた手の推定点の位置は、常に正確に求められるとは限らない。
そこで、本実施例では、管理サーバ１０１の顧客個数判定モジュール１１０５が商品のピックアップが生じているか否かについてより良好に判定するために、さらなる工夫を行うことができる。
例えば、実際にユーザが商品棚に向って手を伸ばして、商品をつかもうとする時間と、実際に重量センサデバイス６０８が商品の重さの変動について出力する時間との間には、わずかながら差が生じ得る。実際に商品をピックアップした瞬間と前後して、重量センサデバイス６０８の出力の変化が得られることがあるためである。

図５０の（Ａ）を参照すると、上方に重量センサデバイス６０８の出力の変化を示し、下方にその商品に関するユーザの手の推定点の距離の変化を示している。
図５０の（Ａ）から理解できるように、時刻Ｔ１で、ユーザは商品に向って手を伸ばして、その手と商品との間の距離が閾値を超えて近づいている。さらに、時刻Ｔ２で、ユーザは商品から離れるように手を戻して、その手と商品との間の距離が閾値を超えて離れている。
このユーザの手の動きから幾分遅れて、時刻ＴａとＴｂとの間で、重量センサデバイス６０８の出力の落ち込みが検出されている。
このように、ユーザの手の動きに基づく時間と、重量センサデバイス６０８の出力に基づく時間との間にズレがあると、管理サーバ１０１は、ユーザの手の推定点の動きと、重量センサデバイス６０８の出力の変化との間で、正確な対応関係が得られない虞がある。

図５０の（Ｂ）を参照すると、同様に、上方に重量センサの出力の変化を示し、下方にその商品とユーザの手の推定点との間の距離の変化を示している。
図５０の（Ｂ）から理解できるように、管理サーバ１０１の顧客個数判定モジュール１１０５は、ユーザの手の動きに基づく時間と、重量センサデバイス６０８の出力に基づく時間との間にズレがあることを検出した場合、いずれか一方の時間を前後にずらすことで、双方の対応関係がより明瞭になるような補正をしている。
例えば、この図では、顧客個数判定モジュール１１０５は、実際の重量センサデバイス６０８の出力に基づく時刻ＴａとＴｂを、それぞれ幾分前にずらしている（時刻Ｔａ’とＴｂ’を参照）。

この補正時間（Ｔａ－Ｔａ’またはＴｂ－Ｔｂ’）は、固定された値として予め定めておくことができる。この場合、ユーザの手の動きに基づく時間と、重量センサデバイス６０８の出力に基づく時間との間にズレがあることを検出した場合、予め定められた大きさで、いずれか一方の時間を前後にずらす。
または、この補正時間（Ｔａ－Ｔａ’またはＴｂ－Ｔｂ’）は、変動可能な値として予め定めておくことができる。この場合、ユーザの手の動きに基づく時間と、重量センサデバイス６０８の出力に基づく時間との間にズレがあることを検出した場合、そのズレの大きさに対応した大きさで、いずれか一方の時間を前後にずらす。

このように、顧客個数判定モジュール１１０５は、ユーザの手の動きに基づく時間と、重量センサデバイス６０８の出力に基づく時間とのいずれかに修正を加えることができる。このように補正時間を設定することで、顧客個数判定モジュール１１０５は、顧客の手の推定点の動きと、重量センサデバイス６０８の出力の変化とについて、より正確な対応関係が得られるようにしている。

例えば、撮影画像に基づく画像解析中に、手の推定点の動きに遅れが生じることがある。または、商品がピックアップされたときに、重量センサデバイス６０８がその事象を遅れて検知することがある。そのような場合であっても、本実施例は、補正時間を導入することで、実際に商品のピックアップの判定をより正確に行えるようにしている。
なお、補正時間を導入する前提条件として、ユーザの手の動きに基づく時間と、重量センサデバイス６０８の出力に基づく時間との間のずれが、所定の大きさよりも小さいか否かの判定を行うのが好ましい。

本実施例では、顧客個数判定モジュール１１０５が商品のピックアップが生じているか否かについてより良好に判定するために、さらなる工夫を行うことができる。
例えば、実際に顧客が商品棚に向って手を伸ばして、商品をつかもうとする際、撮影画像に基づく骨格検出時には、実際の特徴部の位置と演算により求められた特徴部の位置との間には、わずかながらずれが生じ得る。このずれが大きい場合には、実際には、商品をピックアップしようとして手を伸ばしているにもかかわらず、手がのばされていないと検出される虞がある。

図５１の（Ａ）を参照すると、上方に重量センサデバイス６０８の出力の変化を示し、下方にその商品に関するユーザの手の推定点の距離の変化を示している。
図５１の（Ａ）から理解できるように、時刻Ｔ１で、ユーザは商品に向って手を伸ばして、その手と商品との間の距離が閾値を超えて近づいている。さらに、時刻Ｔ２で、ユーザは商品から離れるように手を戻して、その手と商品との間の距離が閾値を超えて離れている。
さらに、この期間中、時刻ＴａとＴｂとの短期間の間で、そのユーザが手を戻して、また手を伸ばしていることが検出されている。このため、顧客個数判定モジュール１１０５は、時刻ＴａとＴｂとの間では、そのユーザの手の動きに対して、重量センサデバイス６０８の出力の変化とを対応付けることができない（その期間、そのユーザは商品のピックアップをしていないと判定する）。

本実施例では、肘と手首の位置から前腕の長さと方向を取得して、その長さを延長することで手の推定点の位置を演算により求めることができる。この演算の基準となる肘や手首の位置にズレが生じると、その影響を受けて、手の推定点に位置ズレが生じることが起こり得る。例えば、実際にはユーザが商品棚の中まで手を伸ばしているにもかかわらず、その手が所定位置まで届いていないと判定されることが起こり得る。
例えば、図５１の（Ａ）では、実際には、ユーザが時刻Ｔ１とＴ２との間で連続して商品に向って手を伸ばしているにもかかわらず、時刻ＴａとＴｂとの間では、その手の動きに切れ目があると検出されている。仮に、この切れ目の動きが、不正確な手の推定点の位置の演算に起因する場合、顧客個数判定モジュール１１０５は、商品のピックアップの判定を正しく行うことができない。

図５１の（Ｂ）を参照すると、同様に、上方に重量センサの出力の変化を示し、下方にその商品とユーザの手の推定点との間の距離の変化を示している。
即ち、顧客個数判定モジュール１１０５は、人物ＩＤに紐づけられた手の推定点の位置を常時監視する。
ある人物ＩＤに紐づけられた手の推定点が、所定の閾値を超えたとき、その手が商品棚の中の商品をピックアップ可能な位置に到達したことを推定する（例えば、時刻Ｔ１）。

その後、同一の人物ＩＤに紐づけられた手の推定点が、所定の閾値を下回ったとき、その手が商品棚の中の商品をピックアップ可能な位置から遠ざかったことを推定する（例えば、時刻Ｔａ）。
その後、同一の人物ＩＤに紐づけられた手の推定点が、再度、所定の閾値を超えたとき、その手が商品棚の中の商品をピックアップ可能な位置に到達したことを推定する（例えば、時刻Ｔｂ）。
その後、同一の人物ＩＤに紐づけられた手の推定点が、所定の閾値を下回ったとき、その手が商品棚の中の商品をピックアップ可能な位置から遠ざかったことを推定する（例えば、時刻T２）。

このように、顧客個数判定モジュール１１０５は、顧客の手を伸ばしている期間に切れ目が検出されたとき（例えば、時刻TａとＴｂとの間）、以下の判定を行う。
検出されたその切れ目の前後で、商品をピックアップ可能な位置にある手の人物ＩＤが同一であるか否かの判定を行う。
上記判定で、切れ目の前後の人物ＩＤが同一である場合、さらに、その切れ目が生じた時間間隔（時刻ＴａとＴｂとの間）が、所定の閾値よりも下回っているか否かの判定を行う。

上記判定で、ごく短時間で切れ目が生じていたことがわかった場合には、顧客個数判定モジュール１１０５は、その切れ目は無視することができると判定し、その切れ目が事実上存在しないように補正を加える。その結果、商品のピックアップの判定で、その切れ目による悪影響を受けることを回避または最小にしてもよい。
例えば、顧客個数判定モジュール１１０５は、時刻ＴａとＴｂとの間を、時刻Ｔｃで例示するように最小にするか、ゼロにする。それによって、ユーザの手の動きに切れ目が生じたとしても、それによって、商品のピックアップの判定に狂いが生じることを回避させている。

例えば、カメラセンサユニット１０４ａのカメラデバイス５０６ａの撮影画面の品質は一様ではなく、撮影対象の顧客の急な動きなどによって、撮影画面上の肘や手首の位置がずれたり、ぼける可能性がある。ただし、そのような場合であっても、その特徴部と紐づけられている人物ＩＤについては、連続して認定することができる。例えば、人物ＩＤについては、別のカメラセンサユニット１０４のカメラデバイス５０６によって検証してもよい。

従って、顧客個数判定モジュール１１０５は、各人物ＩＤごとに、位置ズレを生じさせているか否かの判定をして、その間隔が短ければ（例えば、時刻ＴａとＴｂとの間）、そのズレを無視するように補正する（例えば、時刻Ｔｃ）。
このように、本実施例では、実際の商品のピックアップの判定中に、ユーザが単独で存在していて、その手伸ばしの期間中に生じた切れ目の長さが短く、かつその期間の両側で手を伸ばしているユーザの人物ＩＤが同一の場合には、その切れ目の間においても、そのユーザが手を伸ばしていたと判定して、上書きする。

本実施例では、顧客個数判定モジュール１１０５が商品のピックアップが生じているか否かについてより良好に判定するために、さらなる工夫を行うことができる。
図５２の（Ａ）を参照すると、上方に重量センサデバイス６０８の出力の変化を示し、下方にその商品に関するユーザ１、ユーザ２の手の推定点の距離の変化を示している。
図５２の（Ａ）から理解できるように、時刻Ｔ１で、ユーザ１は商品に向って手を伸ばして、その手と商品との間の距離が閾値を超えて近づいている。さらに、時刻Ｔ２で、ユーザ１は商品から離れるように手を戻して、その手と商品との間の距離が閾値を超えて離れている。

また、時刻Ｔ３で、ユーザ２は商品に向って手を伸ばして、その手と商品との間の距離が閾値を超えて近づいている。さらに、時刻Ｔ４で、ユーザ２は商品から離れるように手を戻して、その手と商品との間の距離が閾値を超えて離れている。
これら２人のユーザ１、２の動きの間には切れ目があり、時刻Ｔ２からＴ３にかけて、どちらのユーザ１、２も商品に向って手を指し伸ばしていないことが検出されている。
これらユーザ１、２の手の動きに対して、重量センサデバイス６０８の出力は幾分ずれて（時間差を伴って）検出されている。

このように、ユーザが商品棚に向って手を伸ばして、商品をつかもうとしたときの骨格検出の時間と、重量センサデバイス６０８の出力の時間との間には、わずかながら差が生じ得る。
手の推定点は、撮影画像に基づいて検出されているが、骨格検出した位置や重量センサデバイス６０８の時間はブレる場合がある。その結果、重量センサデバイス６０８の出力の変化を、ユーザ１、２に対して正しく対応付けることができないことが起こり得る。図５２の（Ａ）に示したように、重量変化が少し遅かったり、時間差がずれた結果、誰も手を伸ばしてない区間が存在した場合、その区間の重量の変化をユーザと紐づけすることができないことがある。

例えば、時間Ｔ２とＴ３では、ユーザ１、２の手は商品から遠ざかっていると検出されるため、この期間に生じた重量変化は、ユーザ１、２のいずれにも関連付けることができない。
また、時間Ｔ４以降では、ユーザ１、２の手は商品から遠ざかっていると検出されるため、この期間に生じた重量変化は、ユーザ１、２のいずれにも関連付けることができない。
これらの場合、顧客個数判定モジュール１１０５は、商品のピックアップの判定を正しく行うことができない。

図５２の（Ｂ）を参照すると、同様に、上方に重量センサデバイス６０８の出力の変化を示し、下方にその商品とユーザの手の推定点との間の距離の変化を示している。
例えば、顧客個数判定モジュール１１０５は、重量センサデバイス６０８の出力の変化が生じた前後に、２人または複数のユーザ１、２の手の動きがあって、各ユーザ１、２の動きの間に切れ目があったことを検出したとする（例えば、時間Ｔ２とＴ３の間や、時間Ｔ４以降の所定期間）。

その場合、顧客個数判定モジュール１１０５は、切れ目の大きさ（例えば、時間Ｔ２とＴ３の間や、時間Ｔ４以降の所定期間）を所定の閾値と対比して、無視できる大きさか否かの判定を行う。
無視することができないと判定した場合、顧客個数判定モジュール１１０５は、各ユーザ１、２の動きを所定時間だけ前後に拡大して、その切れ目の大きさ（例えば、時間Ｔ２とＴ３の間や、時間Ｔ４以降の所定期間）を減らすような補正を行う。
それによって、各ユーザ１、２の動きと、重量センサの出力の変化とのより良好に対応付けるようにする。

例えば、顧客個数判定モジュール１１０５は、次のうちの任意の１つまたは複数または全部を行う。
例えば、ユーザ１が手を商品棚に向って指し伸ばした時間Ｔ１を、所定時間の大きさ（例えば、時間Ｔａ）で前にずらす。
例えば、ユーザ１が手を商品棚から戻した時間Ｔ２を、所定時間の大きさ（例えば、時間Ｔｂ）で後にずらす。
例えば、ユーザ２が手を商品棚に向って指し伸ばした時間Ｔ３を、所定時間の大きさ（例えば、時間Ｔｃ）で前にずらす。
例えば、ユーザ２が手を商品棚から戻した時間Ｔ４を、所定時間の大きさ（例えば、時間Ｔｄ）で後にずらす。

この際、補正によって導入される時間の大きさＴａ、Ｔｂ、Ｔｃ、Ｔｄは、それぞれ同一の大きさでもよい。また、実施状況等によって、これら時間の大きさＴａ、Ｔｂ、Ｔｃ、Ｔｄは変化してもよい。
従って、顧客個数判定モジュール１１０５は、各ユーザ１、２の手の動きを前後に拡大することで、誰も手を伸ばしてない区間をより短くまたは最小にして、重量の変化をユーザ１、２と紐づけすることを容易にする。

顧客個数判定モジュール１１０５は、図５０の（Ｂ）、図５１の（Ｂ）、図５２の（Ｂ）に例示した制御をそれぞれ単独で行ってもよく、または、それぞれ互いに組み合わせて行ってもよい。さらに、これら判定制御では、図４５、図４６、図４７、図４８、図４９、図６３、図６４に例示した制御を適当に選択して組み合わせることができる。
例えば、ある商品の周囲で複数のユーザが同時に手を伸ばしている区間において、その商品の重量変化が検出された場合、どのユーザがいくつの商品をピックアップしたのかについて、十分な判定ができない虞が起こり得る。
本実施例では、そのようなユーザ／個数が不確定になりやすい場合では、上記の手が重なった時の判定ロジックを導入して対応してもよい。
従って、本実施例では、「手の推定点」を用いて実際に商品をピックアップするイベントが生じているか否かの判定について、実際の運用をより容易にして、その判定精度を高めるための工夫を行う。

以上のように構成されることで、顧客個数判定モジュール１１０５は、店舗内のある商品の近くに複数の顧客がいる場合、以下の制御を行うことができる。
顧客ごとに、演算により求められた手の推定点と、商品棚（商品）の位置との間の相互関係を判定する。特に、顧客ごとに商品の近くに手を伸ばしている時間間隔を求める。
重量センサの出力の変化を判定する。特に、重量センサの取得する重さの時系列データのうち、顧客ごとに上記時間間隔に対応する商品の重量変化量を求める。
顧客ごとに、商品棚から商品がピックアップされたか否かを判定する。特に、商品１つあたりの重さに対して占める、顧客ごとの上記時間間隔に対応する商品の重量変化量の割合を求める。

従って、本実施例は、様々な状況下で、商品をピックアップするユーザの動きの判定を可能にする。
例えば、本実施例では、どのユーザが、どの商品を何個取ったのかについて判定することができる。
特に、本実施例は、商品をとったユーザと、商品の個数とを正しく判定することを可能にする。特に、ユーザの人物ＩＤごとに、商品のピックアップを判定する。
さらに、本実施例は、ユーザの人物ＩＤごとに、個数／種類を含めた商品のピックアップを判定する。特に、重量センサが分離できないくらいの時間間隔で、連続で商品を取得した場合であっても、対応することができる

例えば、本実施例では、「ユーザＡとユーザＢが、それぞれ商品ａを１つずつ取った」、ということを出力できる。
また、本実施例では、「ユーザＡが商品ａを２つ取り、ユーザＢが商品ａを１つ取った」、ということを出力できる
また、本実施例では、「ユーザＡが商品ａを１つ取り、ユーザＢが商品ｂを１つ取った」、ということを出力できる。
従って、本実施例では、どのユーザが、どの商品を、いくつ取ったのかについて判定することができる。このため、従来技術と比べて、商品のピックアップの判定をより高い精度で行うことを可能にする。

これに対して、従来技術では、カメラの撮影画像と、重量センサの出力とを用いて、商品をピックアップする顧客の動きを判定する際、ある商品を取りうる距離に、複数の顧客が同時に存在する場合（商品の近くに複数の手が同時に存在する場合）、判定が困難になることがあった。
また、従来技術では、同じ位置の商品が連続して複数ピックアップされる場合（ピックアップされる各商品の時間が近い場合）、判定が困難になる傾向があった。
また、従来技術では、同時に隣接する商品が複数ピックアップされる場合（ピックアップされる各商品の位置が近い場合）、判定が困難になる傾向があった。
また、従来技術では、同時に複数個の商品がピックアップされた場合、判定が困難になる傾向があった。

特に、従来技術では、商品をピックアップする顧客の動きを判定する際、商品の「重量情報」については、状態が安定化した前後の重量の変化差分のみが含まれていた。
また、従来技術では、商品をピックアップする顧客の動きを判定する際、その重量情報の変化の生じた時刻において、１人顧客のみが商品を取ったことを前提としていた。
また、従来技術では、重量センサの近くにいるユーザがその商品を取ったと判定して、出力していた。このため、その近くに複数のユーザが存在する場合、十分な判定できないものとして、出力することがあった。

このように、従来技術では、互いに近い距離にいる複数の顧客が商品を取った場合、誰が取ったか判定することができなかった。また、同じ重量センサの棚から、連続して（時間間隔をあけず）、商品が取られた場合、どの顧客が何個取ったかについて十分に判定することができなかった。
本実施例では、このような従来技術の問題を解決するための好適な手段を提供している。

なお、従来技術では、撮影画像上での画像解析に基づいて、商品のピックアップが行われたか否かを判定する場合、商品の画像解析や商品を掴もうとする手の画像解析にディープニューラルネットワーク（ＤＮＮ：Deep Neural Network）を用いることがあった。ＤＮＮとは、ニューラルネットワークをディープラーニングに対応させて4層以上に層を深くしたものをいう。ＤＮＮは、画像認識に応用することができ、特に、２次元の画像データを一次元等の適当な数値列に変換してＤＮＮに入力すると、その画像に何がどの位置に写っているかを認識した結果を出力することができる。

画像認識でＤＮＮを用いる場合、次の問題があった。
ＤＮＮでは、判定する商品の種類が限られている。これに対して、公知なように、一般的な商店等で販売されている商品は、新商品の開発がほぼ途切れなく継続されている。例えば、スーパーやコンビニ等では、常時、新しい商品が導入されている。
ＤＮＮでは、判定する商品の種類を増やそうとする場合、モデルの構成を変え、モデルを再度学習する必要がある。新商品が導入される間隔が短い場合、十分な学習期間を確保できず、運用面で課題が残る。

また、撮影画像上でＤＮＮを適用する場合、商品の有無がカメラに映る陳列方法しか採用できない。複数段を有する商品棚（平積み方式等）では、天板のない最上段の棚に乗せられた商品のみが、その全体を撮影することができるため、ＤＮＮの適用が可能となる。しかし、商品棚の２段目以降の段では、商品の全体が撮影できないため、ＤＮＮの適用が困難になり得る。従って、複数段の商品棚を有する店舗では、ＤＮＮに基づく画像認識には運用面で課題が残る。

これに対して、本実施例では、管理サーバ１０１の顧客個数判定モジュール１１０５は、カメラセンサユニット１０４のカメラデバイス５０６からの撮影画像に基づいて得られた顧客の移動軌跡と、カメラセンサユニット１０４ａのカメラデバイス５０６ａからの撮影画像に基づいて得られた顧客の手の推定点と、商品棚の重量センサデバイス６０８の読み取り値とを組み合わせて用いることで、商品のピックアップが生じているか否かを判定する。このため、本実施例では、各商品の重量さえ知ることができれば、商品の種類を選ぶことなく適用できる。従って、本実施例では、商品の種類をより簡単に増やすことができる。

さらに、本実施例では、カメラセンサユニット１０４のカメラデバイス５０６や、カメラセンサユニット１０４ａのカメラデバイス５０６ａによって、必ずしも商品の全体が撮影されることを必要としていない。このため、本実施例では、商品の陳列の仕方を選ぶことなく適用することができる。例えば、本実施例では、任意の形状の商品棚（平積み方式等）に適用することができる。

さらに、本実施例では、商品のピックアップの判定をより良好に行うための工夫を行っている。
通常、店舗内には、複数の商品棚が設置されている（図３６の（Ａ）、（Ｂ）参照）。そのため、ほぼ同時刻に、同じ顧客の動作を複数のカメラ（例えば、カメラデバイス５０６、カメラデバイス５０６ａ等）によって撮影されることが起こり得る。撮影画像の品質を良好に保つためには、予め、想定される使用状況に基づいて、各カメラの優先順位を設定しておくのが好ましい。

例えば、商品棚の中の商品をピックアップする様子を撮影するためには、商品棚に対して向かい合う顧客の正面側の様子を上方から撮影するのが好ましい。その場合、好適には、顧客の商品を掴もうとする腕の動きを全体的に撮影することが好ましい。さらに好適には、顧客の左右の腕を比較的に均等に撮影する。これに対して、顧客を側方から撮影する場合、顧客の商品を掴もうとする腕の動きが顧客の体によって隠されることが起こり得る。また、顧客の左右の腕を比較的に均等に撮影することが困難となる。

このように、各カメラの撮影画像の内容は一様ではない。上記のように、顧客を正面から撮影した画像と、顧客を側方から撮影した画像との両方が利用可能な場合、前者については、後者に対して、より高い優先度を与えておくのが好ましい。これによって、好ましい品質の画像に基づいて画像解析が行われることを確保できる。

図５３を参照すると、本実施例を利用可能な実際の店舗内の平面図が示されている。同図から理解できるように、店舗内には、出入り口（入店エリア／退店エリア）が設けられ、それに続いて、複数の商品棚が設置されたフロアが用意されている。なお、同図ではフロアを略四角形状に示しているが、実際のフロアの形状は様々に構成可能である。通常、店舗内のスペースを有効活用するため、フロアに設置された各商品棚は上下に複数段に分かれて、各段に複数の商品を提示している。これら商品棚の間は、顧客が自由に歩き回ることができるフリースペースとなっている。

図５４を参照すると、図５３に例示した店舗内の平面図において、主に商品棚の設置位置に基づいたフロアの区分けが例示されている。このように、１つのフロアには、複数のエリアが設定されている。各エリアは、略四角形状の枠で例示されており、その枠の中には、１つまたは複数の商品棚が設置可能となっている。このエリアの形状及び大きさは様々に構成可能である。好適には、付近に設置されたカメラによって良好に撮影可能な範囲と対応付けられている。隣接するエリアは、双方の間に隙間を設けてもよい。また、隣接するエリアは、双方の間で一部重複させてもよい。

図５５を参照すると、図５４に例示した店舗内の商品棚及び／またはエリアに関して、実際のカメラの撮影画像の例が示されている。この撮影画像は、カメラセンサユニット１０４のカメラデバイス５０６と、カメラセンサユニット１０４ａのカメラデバイス５０６ａとの双方に適用可能である。
図５５から理解できるように、エリアの設定では、棚の前（商品がおいてある位置と、少し手前側）を囲むように設定してもよい。

図５５から理解できるように、例えば、カメラのＰＯＶ／ＦＯＶは、商品棚をほぼ真上から撮影して、その商品棚に展示されている商品をピックアップしようとする顧客の腕の様子を正面から撮影できるようにしている。通常、顧客は、商品棚の中に展示されている商品を確認するために、商品棚と正対する。この場合、比較的良好に、顧客の上半身の様子を撮影することができる。なお、商品棚に対して斜めに立って、横から商品を取るような動きについても、少なくともその差し出された腕の様子は撮影できるようにしている。

各商品棚及び／またはエリアの位置と、その周囲を撮影する各カメラのＰＯＶ／ＦＯＶは予め知られている。このため、どのカメラによってどの商品棚を最適に撮影できるのかは既知である。管理サーバ１０１は、商品棚及び／またはエリアごとに、好ましいカメラの優先順序を決めており、その順序に従って、撮影画像の画像解析を行うことができる。
例えば、複数のカメラの撮影画像が利用可能であることが前もって推測できる場合、横から撮影した画像だと位置の精度が落ちるので、正面から撮影できる画像が利用可能な場合には、後者を優先的に利用する。

優先度は、店舗内の様子に基づいて、様々に設定することができる。
例えば、優先度は、各カメラ５０６、５０６ａの位置と、商品棚及び／またはエリアの位置との間の距離を基準にしてもよい。
例えば、優先度は、各カメラ５０６、５０６ａのＰＯＶ／ＦＯＶと、商品棚及び／またはエリアの周囲に存在可能な人との対応関係を基準にしてもよい。
例えば、優先度は、各カメラ５０６、５０６ａの撮影画像と、被写体の向きとの対応関係を基準にしてもよい。
例えば、優先度は、各カメラ５０６、５０６ａの撮影画像と、被写体との間の障害物の有無を基準にしてもよい。
例えば、優先度は、各カメラ５０６、５０６ａの撮影画像と、それに基づく骨格検出の精度を基準にしてもよい。

他、各カメラ５０６、５０６ａの撮影画像の大きさ、様子、品質等に基づいて、優先度を様々に設定することができる。
さらに、優先度に関連して、各エリアの大きさ、形状等を様々に設定することができる。
このように、管理サーバ１０１は、予めどのカメラの撮影画像を用いるかについて優先度を設定することで、画像解析の品質が所定の基準を満たすようにしてもよい。

図５６を参照すると、ある店舗内の平面図（フロア）において、８つのエリアを画定するとともに、各エリアの撮影状況を例示している。これらの撮影画像は、カメラ５０６、５０６ａの双方またはいずれかに適応可能である。
図５６から理解できるように、店舗内の様子は、複数（例えば、８つ）の撮影画像として取得可能である。これら撮影画像のうち、どの撮影画像を利用するかによって、店舗内を移動する顧客の追跡が変化し得る。

例えば、あるカメラ５０６、５０６ａの撮影画像に基づいて、ある顧客の動きを良好に撮影できたとしても、その顧客の位置の変化の結果、その撮影画像では、もはやその顧客の動きを十分に撮影できなくなることがある。
管理サーバ１０１は、顧客の位置の変化や、顧客の動きの変化などに従って、想定可能な複数（例えば、８つ）の撮影画像のうち、どの撮影画像を利用するのが好ましいかについて、予め優先度を決めておいてもよい。

図５７を参照すると、図５６に例示した場合において、店舗内を移動する顧客の様子が、２つの異なるカメラから追跡した例を示している。
同図では、右上から左下にかけて、符号０２３６、０１０８、０２２７、０３５７、０５７０、０３９０、０３９１、０１３８で示された８つのカメラが例示されている。これらカメラは、カメラセンサユニット１０４のカメラデバイス５０６と、カメラセンサユニット１０４ａのカメラデバイス５０６ａの双方またはいずれかでもよい。

この例では、人物ＩＤとして、８３７が付与されているユーザが、２つのカメラ（０２２７と０３９１）によってほぼ同時に検出されている。
人物ＩＤ「８３７」が小さく表示されている方は、カメラセンサユニット１０４のカメラデバイス５０６の撮影画像（ＴｏＦ）に基づいて出力された人物ＩＤに相当している。人物ＩＤ「８３７」が大きく表示されている方は、カメラセンサユニット１０４ａのカメラデバイス５０６ａの撮影画像に基づいて骨格と位置が紐付けられた結果、フロア内に存在すると推定されたユーザの人物ＩＤに相当している。

各カメラのＰＯＶ／ＦＯＶと、店舗内の顧客の位置との関係によって、各カメラによって検出される顧客の位置情報は変化し得る。管理サーバ１０１は、顧客の位置を連続的に追跡するとともに、その位置の変化に従って、どのカメラからの撮影画像を用いるかについて、予め優先度を定めておくことができる。その結果、管理サーバ１０１は、店舗内を移動する顧客について、常に、高い精度でその顧客の位置を追跡できるようにしている。
このことは、顧客の位置検出用カメラセンサユニット１０４のカメラデバイス５０６と、顧客骨格検出用カメラセンサユニット１０４ａのカメラデバイス５０６ａとの双方について当てはめることができる。

各カメラ５０６、５０６ａのＰＯＶ／ＦＯＶは、それぞれ対応する商品棚の付近を適当にカバーするように、互いに相違する。好適には、各カメラ５０６、５０６ａのＰＯＶ／ＦＯＶは、近くの商品棚の様子を良好に撮影できるように、予め固定されている。
しかしながら、ある商品棚の付近の様子を良好に撮影するためには、予め設定されたＰＯＶ／ＦＯＶでは適当でない場合、管理サーバ１０１は、カメラ５０６、５０６ａのＰＯＶ／ＦＯＶを変更させてもよい。

例えば、店舗内で、比較的隅の方に顧客がいて、その様子が良好に撮影できない場合、カメラ５０６、５０６ａの向きや角度を調整してもよい。
従って、管理サーバ１０１は、各カメラ５０６、５０６ａについて優先度を予め設定するとともに、実際の運用状況に応じて、各カメラ５０６、５０６ａのＰＯＶ／ＦＯＶに修正を加えることは可能である。
このように、本実施例では、顧客の動きを連続して追跡できるように工夫している。

本実施例では、管理サーバ１０１がより良好に顧客の追跡を行えるように、さらなる工夫を行うことができる。この制御は、例えば、位置情報処理モジュール１１０２で行ってもよい。また、骨格検出処理モジュール１１０２ａ、顧客個数判定モジュール１１０５等で行ってもよい。
例えば、従来技術では、店舗内の顧客の移動の仕方によっては、カメラセンサユニット１０４のカメラデバイス５０６またはカメラセンサユニット１０４ａのカメラデバイス５０６ａによって、顧客を完全に追跡することができない場合があった。顧客の位置情報を正確に追跡できない場合には、その後の商品のピックアップの判定を十分に行うことができないため、問題となる。

例えば、図５８を参照すると、従来技術におけるカメラセンサユニット１０４のカメラデバイス（ＴｏＦ）５０６の追跡ミス／入れ替わりの様子が簡略的に例示されている。
図５８から理解できるように、店舗内を二人のユーザが存在している。この例では、それぞれ、人物ＩＤとして、０と１とが割り当てられている。各ユーザ０、１は、同一または異なるカメラによって追跡されている。同図の（１）から（２）に例示するように、二人の顧客の位置が互いに接近すると、双方を明確に識別できない事態が起こり得る。図では、急接近した二人の顧客に対して、その後、同図の（２）から（３）に例示するように、それぞれの人物ＩＤ０、１が入れ替えられている。
このように、追跡情報（人物情報）において、顧客の人物ＩＤが入れ替わると、その後の顧客の追跡や骨格検出などがすべて連鎖的に誤る虞がある。

本実施例では、上記のような事態が生じるのを未然に防ぐための手段を備えている。特に、本実施例では、カメラセンサユニット１０４のカメラデバイス５０６またはカメラセンサユニット１０４ａのカメラデバイス５０６ａによって撮影された画像に基づいて、顧客の位置を抽出する際、同時に、顧客の服装の情報を抽出する。各顧客は、それぞれ、位置情報と服装の情報（色情報）とを組み合わされて追跡することができる。従って、二人の顧客の位置が互いに接近した結果、位置情報だけでは、双方を明確に識別できない事態が生じたとしても、双方の服装の情報に基づいて、互いに区別することを可能にする。

例えば、本実施例では、カメラセンサユニット１０４のカメラデバイス５０６またはカメラセンサユニット１０４ａのカメラデバイス５０６ａによって撮影された画像に基づいて、顧客の服装の色または形状を抽出する。例えば、顧客の肩の色を抽出する。顧客の頭部は、帽子などの着脱によって、色や形状の情報の一貫性が失われることが起こり得る。肘や手首や腕などは、比較的自由に動くことができ、見る角度によって隠されることが起こり得る。

例えば、肘の場合、検出位置がずれたときや、腕まくりしている場合、素肌と服のどちらにもなりうる。また、手首だと、ポケット等へ出入りする場合、服や手のどちらにもなりうる。これらに対して、肩の位置は、多くの状況で比較的継続して視認することが可能である。そのため、肩の色の情報を用いることで、顧客の服装の情報を継続して追跡することができる。

他、本実施例では、肩の色に追加して、顧客の他の色の情報を用いてもよい。例えば、肩の色の情報と、胸部や背中の色の情報とを組み合わせて用いてもよい。さらに、顧客の肩、胸部及び／または背中の服装の形状の情報を用いてもよい。さらに、単純な色でなく、服装全体の形状、模様、色、及び／または特徴量（例えば、特徴量は、別途作成したモデル・特徴量の計算方法によって抽出可能）等を利用してもよい。

図５９を参照すると、顧客の肩の色の情報を取得する状況を例示している。
本実施例では、カメラセンサユニット１０４のカメラデバイス５０６またはカメラセンサユニット１０４ａのカメラデバイス５０６ａによって撮影されたＲＧＢ画像から、顧客の肩の座標の色を取得することで、服装の色を判別してもよい。
なお、頭部が左右に動くことで、頭部の位置と肩の位置とが一部重なることが起こり得る。そのため、両肩の座標のうち、頭から遠い方の肩の座標を採用するのが好ましい。これにより、ユーザが映る角度によっては、頭が肩に重なることが起こり得るが、そのような事態を回避できる。図５９では、頭部の位置と、左右の肩の位置とを対比して、頭部からより離れている右肩の方を採用し、左肩の方は不採用としてもよい。

このようにして、店舗内の所定の領域（入口付近）から入店した各顧客について、入店直後の一定時間の間、位置情報とともに、肩の服装の色を記録する。または、入店直後に限らず、安定してユーザの服装を判定できる位置・タイミングで、服装の情報を取得してもよい。例えば、顧客個数判定モジュール１１０５は、任意のタイミングで服装の情報の取得を開始した後、数十秒、１分、数分間または他の任意の期間、周期的に肩の色を記録して、その平均値を演算により求めて、その値を顧客の服装の色として登録する。

以降は、例えば、顧客個数判定モジュール１１０５は、各顧客の肩の色を取得し続け、複数の顧客が互いに接近した場合（図５８の（２）参照）、それぞれの顧客の位置情報と服装の色情報とを組み合わせて用いて、互いに区別する。一時的に、複数の顧客の間で位置情報及び／または服装の色情報の入れ替わりが起きた場合、識別番号を入れ替える等して、識別番号（人物ＩＤ）が誤って付与されることを防止または訂正する。

顧客の位置情報の追跡が正常に動作しているとき、例えば、顧客個数判定モジュール１１０５は、次のように機能する。
例えば、顧客が店舗内の予め設定された出現エリア（入場口近辺）に来たら、各顧客に独自の人物ＩＤを付与して、追跡を開始する。人物ＩＤは、数字及び／または文字等を用いて構成されてもよい。例えば、人物ＩＤは、来店する顧客ごとに通し番号として付与されてもよい。
また、例えば、人物ＩＤは、日時／時間の組み合わせとして付与されてもよい。例えば、２０２１年５月３０日午前７時１０分３０秒に来店した顧客に対しては、２０２１０５３００７１０３０の識別番号を付与してもよい。同一の日時／時間に複数の顧客が現れたときには、末尾にａ、ｂ、ｃ等の符号を付けて互いに区別してもよい。

店舗内に顧客が存在する間、各顧客に割り当てられた人物ＩＤは、そのまま保持される。そして、顧客が店舗内の予め設定された消失エリア（退場口近辺）に来たら、各顧客に割り当てられた人物ＩＤが消去されて、追跡が終わる。同じ店舗に、同一人物が再度来店する場合、その都度、異なる人物ＩＤが付与される。
従来技術では、顧客が店舗内の所定の消失エリアに来ていないにも関わらず、その人物ＩＤが消えることがあった（人物ＩＤのロスト）。その場合、以降、そのユーザの追跡情報が出力されなくなるという問題があった。
また、その顧客が改めて店舗内の所定の出現エリア（入場口近辺）に来たら、新たにその顧客に別の人物ＩＤが付与されることがあった（意図しない人物ＩＤの再出現）。その場合、以降、その顧客は、あたかも他の顧客（別人）として判定されることになるという問題があった。

本実施例では、上記のような、人物ＩＤのロスト／人物ＩＤの再出現といった事態が生じることを未然に防ぐ手段をさらに備える。
例えば、本実施例では、顧客の人物ＩＤを一時的に消失する事態が生じたとしても、カメラセンサユニット１０４のカメラデバイス５０６またはカメラセンサユニット１０４ａのカメラデバイス５０６ａの撮影画像から検出される骨格の情報や、服装の色の情報に基づいて、その顧客を追跡することができる。
従って、骨格の情報及び／または服装の色の情報に基づいて追跡される顧客については、その人物ＩＤを継続して維持することができる。また、その顧客が改めて店舗内の所定の出現エリア（入場口近辺）に来たとしても、その顧客に対して新しい人物ＩＤを付与することを回避／訂正することができる。

図６０を参照すると、顧客の追跡を良好に行う様子が簡略的に示されている。
本実施例では、位置情報、骨格情報及び／または服装の色情報に基づいて、例えば、顧客個数判定モジュール１１０５は、カメラセンサユニット１０４のカメラデバイス５０６によって追跡している顧客の人物ＩＤを保持する。従って、図６０の（１）から（２）に例示したように、互いに近接する顧客を識別することができる。
さらに、図６０の（３）に例示したように、顧客の位置が消失エリアに入らないまま、その追跡が一時的に終了した場合（符号Ａの点線参照）、例えば、顧客個数判定モジュール１１０５は、その顧客が店内にとどまっているものと仮定して、その人物ＩＤを保持することができる。

例えば、顧客個数判定モジュール１１０５は、現在追跡している各顧客について、そのデータを常時参照できるようにする。例えば、現在追跡している各顧客について、それぞれの骨格情報及び／または服装の色情報を紐付けておく。
例えば、顧客個数判定モジュール１１０５は、店舗内にいる顧客全員のうち、余った骨格情報及び／または服装の色情報が見つかった場合、店舗内にとどまっていると仮定した顧客（一時的に追跡が消えた顧客）が、その骨格情報及び／または服装の色情報が見つかった位置にいるものとして仮定して、その位置から追跡を再開してもよい。

図６０の（４）から（５）を参照すると、位置情報を失って、骨格情報及び／または服装の色情報だけを有する顧客が改めて出現エリアに入ったことにより、別の人物ＩＤ（２）が付与されることが例示されている。
このように、従来技術では、一度人物ＩＤの追跡が途切れると、その人物に対しては別の人物ＩＤが付与されていた。

これに対して、図６１の（１）から（３）を参照すると、本実施例では、位置情報を失って、骨格情報及び／または服装の色情報だけを有する顧客が改めて出現エリアに入ったことにより、別の人物ＩＤ（２）が付与されると、その新しく付与された人物ＩＤ（２）を元の人物ＩＤ（０）で置き換えることが例示されている。この結果、本実施例では、顧客が別人として誤って認定されることを防止している。

以上のように、本実施例では、カメラの撮影画像に基づいて、人の上半身に限定して、特徴点（頭部、肩、肘、手首）を抽出する際、その位置情報だけでなく、服装の情報（服装の色、形状、模様、及び／または特徴量）を抽出してもよい。
例えば、顧客個数判定モジュール１１０５は、カメラの撮影した画像に対して骨格検出モデルを適用することにより、さらに人体の肩部の付近の色の情報を検出してもよい。例えば、顧客個数判定モジュール１１０５は、この検出した肩の色の情報を基準にして、その肩の所有者に対して人物ＩＤを付与してもよい。
従って、本実施例では、店舗内の顧客の動きをより正確に追跡することを可能にする。その結果、店舗内における顧客の商品のピックアップの判定を正確に行うことを可能にする。

なお、本実施例では、カメラセンサユニット１０４ａには、深さ情報（デプス）を取得できるカメラを用いることができる。ただし、他の実施例によっては、カメラセンサユニット１０４ａには、通常のカメラ（２Ｄカメラ）を用いることができる。
また、本実施例では、カメラセンサユニット１０４には、ＴｏＦセンサ・モジュールによる位置の追跡を行うことができる。ただし、他の実施例では、カメラセンサユニット１０４による位置の追跡モジュール自体を削除することができる。他の実施例では、複数のカメラセンサユニット１０４ａからの撮影画像間でユーザの特定・マッチングを行ってもよい。このように、顧客の位置の追跡と骨格情報の取得の双方を複数のカメラセンサユニット１０４ａだけで行うことは可能である。

なお、本実施例では、顧客が商品に向って手を伸ばしたときの接近の度合いを判定する基準（閾値）については、手動で商品の位置を取得し設定することができる。ただし、他の実施例では、この基準の設定について、自動補正（キャリブレーション）を適用することは可能である。他の実施例では、顧客が商品をとった際の手の座標を取得し、各商品の位置を上書きすることで、自動で商品の位置を補正してもよい。

なお、本実施例では、どの顧客が商品をピックアップしたかの判定が不十分な場合、判定員による人的な判定を行うことができる。この際、判定員は、カメラセンサユニット１０４、１０４ａによって撮影された動画をそのまま再生することができる。ただし、他の実施例では、この判定員の判定を補助する手段を備えることができる。
他の実施例では、判定用の動画を撮影するカメラをキャリブレーションすることで、各カメラの位置・姿勢（カメラパラメータ）を計算することができる。さらに、このパラメータを利用して、商品の位置や、ユーザの位置が、画面上でどの点になるか計算し、その動画内にアノテーションすることで、判定員がよりわかりやすくなるようにしてもよい。

なお、本発明は上記した実施例に限定されるものではなく、様々な変形例が含まれる。例えば、上記した実施例は本発明を分かりやすく説明するために詳細に説明したものであり、必ずしも説明した全ての構成を備えるものに限定されるものではない。また、ある実施例の構成の一部を他の実施例の構成に置き換えることが可能であり、また、ある実施例の構成に他の実施例の構成を加えることも可能である。また、各実施例の構成の一部について、他の構成の追加・削除・置換をすることが可能である。

また、上記の各構成、機能、処理部、処理手段等は、それらの一部又は全部を、例えば集積回路で設計する等によりハードウェアで実現してもよい。また、上記の各構成、機能等は、プロセッサがそれぞれの機能を実現するプログラムを解釈し、実行することによりソフトウェアで実現してもよい。各機能を実現するプログラム、テーブル、ファイル等の情報は、メモリや、ハードディスク、ＳＳＤ（Solid State Drive）等の記録装置、または、ＩＣカード、ＳＤカード、ＤＶＤ等の記録媒体に置くことができる。

また、制御線や情報線は説明上必要と考えられるものを示しており、製品上必ずしも全ての制御線や情報線を示しているとは限らない。実際には殆ど全ての構成が相互に接続されていると考えてもよい。
なお、上述の実施例は少なくとも特許請求の範囲に記載の構成を開示している。

１…商品管理システム、１０１…管理サーバ、１０２…モバイル端末、１０３…サイネージ端末、１０４…位置追跡用カメラセンサユニット、１０４ａ…骨格検出用カメラセンサユニット、１０５…重量センサユニット、１０６…入店管理端末、１０７…決済処理サーバ、５０６…カメラデバイス、５０６ａ…カメラデバイス、６０８…重量センサデバイス、６３０…データ集約送信器、７１０…マイコン、２１００…商品棚設置用フレーム

Claims

商品を管理する管理システムであって、
商品棚に設置された重量センサから送信された重量情報を取得する手段と、
第１のカメラセンサにより撮影された画像から顧客の位置情報を取得する手段と、
第２のカメラセンサにより撮影された画像から骨格検出モデルを適用することによって前記顧客の人体の特徴点を取得するとともに、前記人体の特徴点を用いて手の推定点を算出する手段と、
前記顧客の位置情報と、前記算出された手の推定点と前記商品棚の位置との間の相互関係と、前記重量センサの出力の変化と、に基づいて、商品のピックアップを判定する手段と、を有し、
前記商品のピックアップを判定する手段は、
前記手の推定点と前記商品棚の位置との間の相互関係に基づいて、前記顧客が商品のピックアップを可能とする手の移動が生じた期間である手伸ばしの期間を求め、
前記重量センサの出力の変化に基づいて、複数の前記顧客のそれぞれに対し、前記手伸ばしの期間の両端での重量変化量を求め、
複数の前記顧客のそれぞれに対して算出された前記重量変化量に基づいて、商品をピックアップした前記顧客を判定する、
管理システム。
前記第２のカメラセンサは、骨格検出用カメラセンサユニットであって、撮影された画像に対して前記骨格検出モデルを適用することにより、前記人体の肘と手首の特徴点を検出し、
前記検出した特徴点の位置を用いて、前記肘と前記手首との間の長さである前腕の長さを所定の倍数で延長した位置を、前記手の推定点として算出する、
請求項１に記載の管理システム。
前記骨格検出用カメラセンサユニットは、前記前腕の長さを４／３倍の±２５％の範囲内、１．３３倍の±２５％の範囲内または１．３倍の±２５％の範囲内のいずれか１つで延長した位置を、前記手の推定点として算出する、
請求項２に記載の管理システム。
前記骨格検出用カメラセンサユニットは、
前記前腕の長さを二等分する中心の位置を、前腕中心点として算出し、
前記前腕の方向に沿って、前記肘から前記前腕中心点までの長さを所定の倍数で延長した位置を、前記手の推定点として算出する、
請求項２に記載の管理システム。
前記骨格検出用カメラセンサユニットは、
前記肘と前記手首との間の水平方向の２次元座標から、前記前腕中心点を算出し、
前記肘から前記前腕中心点までの３次元座標による長さを所定の倍数で延長した位置を、前記手の推定点として算出する
請求項４に記載の管理システム。
前記骨格検出用カメラセンサユニットは、前記人体のうち、頭部、左右の肩、左右の肘、左右の手首の７つの特徴点を検出する、
請求項２から５のいずれか１項に記載の管理システム。
前記第１のカメラセンサは、前記顧客の位置を追跡する位置追跡用カメラセンサユニットであって、前記顧客までの距離を測定するカメラセンサである、
請求項１から６のいずれか１項に記載の管理システム。
前記第１のカメラセンサは、前記顧客の位置を追跡する位置追跡用カメラセンサユニットであって、前記第２のカメラセンサから送信された前記特徴点と前記手の推定点の情報を、前記顧客の位置情報と同一の座標空間内に座標変換して、統合する、
請求項１から７のいずれか１項に記載の管理システム。
前記第１のカメラセンサと前記第２のカメラセンサの少なくとも一方は、さらに前記顧客の前記人体の肩の付近の色、形状、模様、及び／または特徴量の情報を検出し、
前記検出した肩の色、形状、模様、及び／または特徴量の情報を用いて、その肩に対応する前記顧客に対して識別情報を付与する、
請求項１から８のいずれか１項に記載の管理システム。
前記商品のピックアップを判定する手段は、
商品１つあたりの重量情報を取得し、複数の前記顧客のそれぞれに対して算出された前記重量変化量が、前記商品１つあたりの重量情報の整数倍に近い前記顧客を、前記商品をピックアップした前記顧客であるとして判定する
請求項１に記載の管理システム。
前記商品のピックアップを判定する手段は、
前記重量センサの出力の変化の時間と前記手の推定点の位置の変化の時間とのいずれかについて、時間を前後にずらす補正を行う、
請求項１から１０のいずれか１項に記載の管理システム。
前記商品のピックアップを判定する手段は、
前記商品の近くにいる前記顧客の数が一人であると判定した場合に、前記顧客の前記手伸ばしの期間の中に途切れが存在した場合、その途切れを排除または最小にする補正を行う、
請求項１、１０、又は１１に記載の管理システム。
前記商品のピックアップを判定する手段は、
前記商品の近くにいる前記顧客が複数であると判定した場合に、複数の前記顧客の手伸ばしの期間の間に途切れが存在した場合、その途切れを排除または最小にするように、その途切れの前後の顧客の手の動きを拡大する補正を行う、
請求項１から１０のいずれか１項に記載の管理システム。
管理サーバにより実行される、商品を管理する管理方法であって、
商品棚に設置した重量センサから送信された重量情報を取得し、
第１のカメラセンサにより撮影されたた画像から顧客の位置情報を取得し、
第２のカメラセンサにより撮影された画像から骨格検出モデルを適用することによって前記顧客の人体の特徴点を取得するとともに、前記人体の特徴点を用いて手の推定点を演算により求め、
前記顧客の位置情報と、前記手の推定点と前記商品棚の位置と、の間の相互関係に基づいて、前記顧客が商品のピックアップを可能とする手の移動が生じた期間である手伸ばしの期間を求め、
前記重量センサの出力の変化に基づいて、複数の前記顧客のそれぞれに対し、前記手伸ばしの期間の両端での重量変化量を求め、
複数の前記顧客のそれぞれに対して算出された前記重量変化量に基づいて、商品をピックアップした前記顧客を判定する、
処理を実行することを特徴とする管理方法。
管理サーバに請求項１４に記載の方法の各ステップを実行させるためのプログラム。