(57)【要約】      （修正有）【課題】不良タグを容易に発見することができる不良タグ検知システムおよび不良タグ検知方法を提供する。【解決手段】自動決済システム１は、商品（料理）と関連付けられたタグの不良品を検知するための不良タグ検知システムである。自動決済システム１は、商品を決済する際に、複数のタグの情報を読取り可能なタグＲ／Ｗ部１６と、タグＲ／Ｗ部１６が読み取った複数のタグの各利用履歴を管理するためのサーバー２とを含む。【選択図】図１
2013254325.tif 000002
【特許請求の範囲】
【請求項１】
商品と関連付けられたタグの不良品を検知するための不良タグ検知システムであって、
商品を決済する際に、複数のタグの情報を読取り可能な読取手段と、
前記読取手段が読み取った複数のタグの各利用履歴を管理するための管理手段と、
を含むことを特徴とする、不良タグ検知システム。
【請求項２】
不良タグを抽出するための所定条件の入力を受け付ける受付手段と、
前記利用履歴および前記所定条件に基づいて不良タグを抽出する抽出手段と、
を含むことを特徴とする、請求項１記載の不良タグ検知システム。
【請求項３】
前記所定条件は、導入を開始してからの所定期間内における利用実績が相対的に低いタグを検出するための条件であって、所定期間内におけるタグの利用回数、タグの最終利用日、および、所定期間内におけるタグの連続不利用日数の少なくともいずれかを含むことを特徴とする、請求項２記載の不良タグ検知システム。
【請求項４】
前記利用履歴は、所定期間のそれぞれの日における各タグの利用有無を含み、
所定期間内の所定の評価日以前の利用有無および他のタグの利用有無に基づいて、当該評価日における各タグの故障可能性を算出する算出手段と、
前記算出手段が算出した故障可能性に基づいて不良タグを抽出する抽出手段と、
を含むことを特徴とする、請求項１記載の不良タグ検知システム。
【請求項５】
前記抽出手段が抽出した不良タグを報知する報知手段を含むことを特徴とする、請求項２〜４のいずれかに記載の不良タグ検知システム。
【請求項６】
商品と関連付けられたタグの不良品を検知するための不良タグ検知方法であって、
商品を決済する際に、複数のタグの情報を読み取るステップと、
読み取った複数のタグの各利用履歴を管理するステップと、
不良タグを抽出するための所定条件と前記利用履歴とに基づいて不良タグを抽出するステップと、
を含むことを特徴とする、不良タグ検知方法。
【請求項７】
商品と関連付けられたタグの不良品を検知するための不良タグ検知方法であって、
商品を決済する際に、複数のタグの情報を読み取るステップと、
読み取った複数のタグの各利用履歴を管理するステップと、
所定期間内の所定の評価日以前の各タグの利用有無および他のタグの利用有無に基づいて、当該評価日における各タグの故障可能性を算出するステップと、
算出した故障可能性に基づいて不良タグを抽出するステップと、
を含むことを特徴とする、不良タグ検知方法。
【発明の詳細な説明】
【技術分野】
【０００１】
この発明は、タグの不良品（不良タグ）を検知するための不良タグ検知システムおよび不良タグ検知方法に関する。
【背景技術】
【０００２】
下記特許文献１では、ＩＤタグを貼付または埋設した食器を載せたトレーが載置されるオートレジ端末機が提案されている。このオートレジ端末機にはＩＤタグ読出装置が設けられていて、ＩＤタグ読出装置は、トレー上の食器のＩＤタグからＩＤコードを読み出す。ＩＤコードには、食器に盛り付けられていた料理の名称や値段が対応付けられており、オートレジ端末機では、ＩＤタグ読出装置が読み出したＩＤコードに基づいて、トレー上の食器の料理について決済処理を行うことができる。
【先行技術文献】
【特許文献】
【０００３】
【特許文献１】特開２００１−２５６４４９号公報
【発明の概要】
【発明が解決しようとする課題】
【０００４】
特許文献１のオートレジ端末機において、複数の食器を載せたトレーがオートレジ端末機に載置され、ＩＤタグ読取装置が複数のＩＤタグから一度にＩＤコードを読み出す場合が想定される。複数のＩＤタグのうちのどれかが、故障した不良タグであった場合、ＩＤタグ読取装置では、どのＩＤタグが不良タグであるのかは検知できないので、不良ＩＤタグが付された食器の料理についての決済処理が実施されずじまいになってしまい、その分、食堂等の売上が減少してしまうことが懸念される。
【０００５】
かといって、不良タグを見つけるために、食器を１つずつオートレジ端末機にセットして、ＩＤタグのＩＤコードがＩＤタグ読取装置によって正しく読み出されるのかをＩＤタグ１つ１つについて調べるのでは、効率が悪いし、手間がかかる。
この発明は、かかる背景のもとでなされたもので、不良タグを容易に発見することができる不良タグ検知システムおよび不良タグ検知方法を提供することを目的とする。
【課題を解決するための手段】
【０００６】
請求項１記載の発明は、商品と関連付けられたタグの不良品を検知するための不良タグ検知システムであって、商品を決済する際に、複数のタグの情報を読取り可能な読取手段と、前記読取手段が読み取った複数のタグの各利用履歴を管理するための管理手段と、を含むことを特徴とする、不良タグ検知システムである。
請求項２記載の発明は、不良タグを抽出するための所定条件の入力を受け付ける受付手段と、前記利用履歴および前記所定条件に基づいて不良タグを抽出する抽出手段と、を含むことを特徴とする、請求項１記載の不良タグ検知システムである。
【０００７】
請求項３記載の発明は、前記所定条件は、導入を開始してからの所定期間内における利用実績が相対的に低いタグを検出するための条件であって、所定期間内におけるタグの利用回数、タグの最終利用日、および、所定期間内におけるタグの連続不利用日数の少なくともいずれかを含むことを特徴とする、請求項２記載の不良タグ検知システムである。
請求項４記載の発明は、前記利用履歴は、所定期間のそれぞれの日における各タグの利用有無を含み、所定期間内の所定の評価日以前の利用有無および他のタグの利用有無に基づいて、当該評価日における各タグの故障可能性を算出する算出手段と、前記算出手段が算出した故障可能性に基づいて不良タグを抽出する抽出手段と、を含むことを特徴とする、請求項１記載の不良タグ検知システムである。
【０００８】
請求項５記載の発明は、前記抽出手段が抽出した不良タグを報知する報知手段を含むことを特徴とする、請求項２〜４のいずれかに記載の不良タグ検知システムである。
請求項６記載の発明は、商品と関連付けられたタグの不良品を検知するための不良タグ検知方法であって、商品を決済する際に、複数のタグの情報を読み取るステップと、読み取った複数のタグの各利用履歴を管理するステップと、不良タグを抽出するための所定条件と前記利用履歴とに基づいて不良タグを抽出するステップと、を含むことを特徴とする、不良タグ検知方法である。
【０００９】
請求項７記載の発明は、商品と関連付けられたタグの不良品を検知するための不良タグ検知方法であって、商品を決済する際に、複数のタグの情報を読み取るステップと、読み取った複数のタグの各利用履歴を管理するステップと、所定期間内の所定の評価日以前の各タグの利用有無および他のタグの利用有無に基づいて、当該評価日における各タグの故障可能性を算出するステップと、算出した故障可能性に基づいて不良タグを抽出するステップと、を含むことを特徴とする、不良タグ検知方法である。
【発明の効果】
【００１０】
請求項１記載の発明によれば、不良タグ検知システムでは、商品を決済する際に読取手段が読み取った各タグの利用履歴を管理手段が管理しているので、不良タグの疑いのあるタグ（利用頻度が他のタグより低い）を利用履歴に基づいて絞り込み、早期に把握できる。そして、絞り込んだ（不良タグの疑いのある）タグだけを読取手段で読み取れるか否かテストすれば、全てのタグをテストする手間をかけずに済み、不良タグの検知にかかる時間を短縮できる。その結果、不良タグを容易に発見することができる。
【００１１】
請求項２および６記載の発明によれば、不良タグの疑いのあるタグを利用履歴および所定条件に基づいて高精度に抽出できる（絞り込める）ので、不良タグを一層容易に発見することができる。
請求項３記載の発明で挙げられた所定条件は、導入を開始してからの所定期間内における利用実績が相対的に低いタグを検出できる条件であるから、このような所定条件を用いれば、不良タグを高精度に抽出できる。
【００１２】
請求項４および７記載の発明によれば、所定期間内の所定の評価日以前の利用有無および他のタグの利用有無といった統計データに基づいて算出した各タグの故障可能性によって、不良タグを一層高精度に抽出することができる。
請求項５記載の発明によれば、報知手段の報知内容によって不良タグを把握できるので便利である。
【図面の簡単な説明】
【００１３】
【図１】図１は、この発明に係る不良タグ検知システムとしての自動決済システム１の全体構成を示すブロック図である。
【図２】図２は、タグ１８が取り付けられた食器１７を底側から見た斜視図である。
【図３】図３は、ユーザが自動決済システム１で決済を行う様子を示す図である。
【図４】図４は、ユーザが食事をする前後における決済の流れを示すフローチャートである。
【図５】図５は、自動決済システム１のサーバー２に記憶されるデータを示す図である。
【図６】図６は、食器１７の棚卸し作業の流れを示すフローチャートである。
【図７】図７は、サーバー２に記憶されるデータを示す図である。
【図８】図８は、サーバー２に記憶されるデータを示す図である。
【図９】図９（ａ）および（ｂ）は、サーバー２に記憶されるデータを示す図である。
【発明を実施するための形態】
【００１４】
以下には、図面を参照して、この発明の実施形態について具体的に説明する。また、以下では、決済金額を算出し、電子マネー等で自動決済を行う端末を「オートレジ」と言うことにする。
図１は、この発明に係る不良タグ検知システムとしての自動決済システム１の全体構成を示すブロック図である。
【００１５】
図１を参照して、この自動決済システム１は、たとえば、会社等における食堂に適用される。自動決済システム１によって、決済が自動で行われるので、食堂において決済に携わる係員が不要となる。
自動決済システム１は、管理手段としてのサーバー２と、食堂クライアント３と、オートレジ４と、カード処理端末５とを含んでいる。サーバー２と、食堂クライアント３と、オートレジ４と、カード処理端末５とは、有線または無線の通信回線で構成されたＬＡＮ６を介して通信可能に接続されている。なお、ＬＡＮ６は、ルーター７を介して外部ネットワーク８に接続されていても構わない。
【００１６】
サーバー２は、食堂における料理の決済履歴等を管理しているコンピュータであり、たとえば、専用のサーバー室に設置される。具体的構成として、サーバー２には、マイクロコンピュータ等で構成された制御部９（受付手段、抽出手段、算出手段、報知手段）が備えられている。制御部９は、ＣＰＵやメモリ（ＲＯＭ、ＲＡＭ）などを含んでいる。制御部９は、サーバー２の動作を制御するためのものである。
【００１７】
また、サーバー２には、記憶部１０が設けられており、この記憶部１０が、前述した決済履歴や、食堂で提供される各料理の情報（メニューおよび値段等）を記憶している。そして、サーバー２には、キーボード等で構成された操作部１１が設けられており、係員は、操作部１１を操作することによって、サーバー２に対して所望の指示を与えることができる。さらに、サーバー２には、たとえば液晶の表示器である表示部１２が設けられており、記憶部１０に記憶された情報等が表示部１２に表示される。
【００１８】
食堂クライアント３は、前述した各料理の情報（メニューおよび値段等）を設定（変更）するために用いられるコンピュータであり、たとえば、食堂における係員用事務室等に設置される。当該情報は、サーバー２から引き出されて食堂クライアント３によって設定される。
なお、サーバー２と食堂クライアント３とは、互いに通信可能な状態で図１に示すように別々に存在してもよいし、一体のコンピュータとして存在してもよい。
【００１９】
オートレジ４は、食堂における決済コーナー内に設置されている。なお、図１では２台のオートレジ４が図示されているが、オートレジ４の設置台数は任意に決めることができる。オートレジ４では、電子マネーによる自動決済が可能である。
ここで、食堂のユーザは、電子マネー機能付きの決済用カード１３を携帯している。この実施形態でのカード１３は、プリペイド方式（前払方式）の電子マネーに対応したプリペイドカードであって、電子マネーの額をプリペイド価値として記憶している。なお、図示しない専用の端末においてカード１３のプリペイド価値を追加で蓄積（チャージ）することができる。
【００２０】
オートレジ４は、表示部１４と、トレー載置台１５と、読取手段としてのタグＲ／Ｗ（Ｒｅａｄ／Ｗｒｉｔｅ）部１６と、制御部２０とを主に含んでいる。
表示部１４は、たとえば液晶の表示器である。トレー載置台１５は、天面が水平方向に平らな台である。なお、トレー載置台１５の天面には、食堂のトレー１９が嵌まり込める窪みが設けられていてもよく、この場合、決済中にトレー１９の位置がずれることを防止できる。タグＲ／Ｗ部１６は、たとえばＩＣタグリーダであって、トレー載置台１５に内蔵されている。制御部２０は、マイクロコンピュータ等で構成されており、オートレジ４に内蔵されていて、オートレジ４の動作を制御する。
【００２１】
カード処理端末５は、各オートレジ４と１対１の関係となるように設けられている。カード処理端末５は、対応するオートレジ４と直接通信することができる。カード処理端末５には、電子マネーによる自動決済を行うためのアプリケーションが記憶されている。カード処理端末５は、対応するオートレジ４の制御部２０の指示によって前記アプリケーションを起動させてから、前述したカード１３に記憶された電子マネーの額を読み取って書き換えることができる。なお、カード処理端末５を、対応するオートレジ４の一部とみなしてもよい。
【００２２】
この実施形態の食堂で扱われる全ての食器１７では、その糸尻（底部）にタグ１８が取り付けられている。図２では、タグ１８が取り付けられた食器１７を底側から見ている。タグ１８は、図示しないＩＣチップ、コイルおよびアンテナ等が内蔵されたＩＣタグである。
図１に示すように、食器１７には、ご飯茶碗１７Ａ、汁物用のお椀１７Ｂ、おかずを盛り付けるため小皿１７Ｃ…というように複数の種類があるが、食器１７の各種類には、識別番号が付与されている。たとえば、ご飯茶碗１７Ａの識別番号は、００１であり、汁物用のお椀１７Ｂの識別番号は、００２であり、小皿１７Ｃの識別番号は、００３である…といった具合である。識別番号は、基本的には食器１７の種類毎に決められる番号である。各識別番号に対して、料理のメニューおよび値段が割り当てられており、識別番号毎のメニューおよび値段は、サーバー２の記憶部１０に記憶されている。また、サーバー２の記憶部１０には、食堂に存在する全ての食器１７の在庫数が種類毎に記憶されている。
【００２３】
また、同一の識別番号の食器１７において、１つ１つの食器１７に対してシリアルＮｏ．が割り当てられている。シリアルＮｏ．は、各種類（識別番号）における個々の食器１７を識別するためのものである。各食器１７に取り付けられたタグ１８を構成するＩＣチップ（図示せず）にシリアルＮｏ．が記録されている。サーバー２の記憶部１０には、シリアルＮｏ．と識別番号とが対応付けて記憶されており（後述する図５参照）、サーバー２上では、シリアルＮｏ．が分かれば、そのシリアルＮｏ．の食器１７についての識別番号、料理のメニューおよび値段が把握できるようになっている。つまり、シリアルＮｏ．が記録されたタグ１８は、自身が取り付けられた食器１７に盛り付けられる商品（ここでは料理）と関連付けられている。
【００２４】
図３は、ユーザが自動決済システム１で決済を行う様子を示す図である。図４は、ユーザが食事をする前後における決済の流れを示すフローチャートである。
このような自動決済システム１における決済の一連の流れを、図１〜図４を参照しながら簡単に説明すると、まず、ユーザは、食堂に入ってからトレー１９（図１参照）を取り、好みの料理（商品）が盛り付けられた食器１７を選んでトレー１９に載せる（図４のステップＳ１）。そして、ユーザは、食事をするために席に着く前（食前）、または、席に着いて食器１７の料理を食べ終わった後（食後）に、自分が選んだ料理について決済するために、食器１７が載ったトレー１９を持って決済コーナーへ向かう（図３参照）。
【００２５】
そして、決済コーナーに辿り着いたユーザは、決済するために、図３に示すように、トレー１９を、空いているオートレジ４（対応するカード処理端末５も含む）のトレー載置台１５に載せる（図４のステップＳ２）。すると、オートレジ４では、このトレー１９に載っている各食器１７のタグ１８に記憶されている情報（換言すれば、各食器１７のシリアルＮｏ．）が、タグＲ／Ｗ部１６によって非接触で読み取られる。ここで、トレー１９に複数の食器１７が載っている場合には、タグＲ／Ｗ部１６は、これらの食器１７のタグ１８（複数のタグ１８）の情報を一度に読み取ることができる。
【００２６】
タグＲ／Ｗ部１６によるタグ１８の読み取りに応じて、オートレジ４の制御部２０は、読み取られた全てのシリアルＮｏ．に対応する料理情報（ユーザが選んでトレー１９に載せた全ての料理のメニューおよび値段）および前述した識別番号を、サーバー２から呼び出し（オートレジ４側で予め記憶されていた料理情報が呼び出されてもよい）、表示部１４に一括表示する。
【００２７】
料理情報が表示部１４に一括表示されるのに前後して、カード処理端末５では、前述したアプリケーションが起動し、これによって、決済処理の準備が完了し、カード処理端末５は、カード１３からプリペイド価値（電子マネーの額）を非接触で読み取れる状態になる。
そして、この状態で、ユーザが自分のカード１３をカード処理端末５にかざすと、カード１３に記憶されたプリペイド価値がカード処理端末５によって読み取られて書き換えられる。これにより、カード１３に記憶されている電子マネーの額が、前述した料理（ユーザが選んでトレー１９に載せた全ての料理）の総額分だけ減算される。
【００２８】
カード１３のプリペイド価値の書き換えが完了すると、トレー載置台１５のトレー１９に載せられた全ての食器１７の料理について、電子マネーによる決済処理が完了する（図４のステップＳ２）。その後、ユーザは、食前に決済したのであれば、席に着いて食事をし、食後に決済したのであれば、食器１７が載ったトレー１９を食器返却コーナーへ持っていく。ただし、食後の決済の方が、食前の決済に比べて、決済コーナーで比較的並ばずに決済できたり、食器１７に料理がない分トレー１９が軽かったり（持ちやすかったり）、食器１７から料理をこぼす虞がなかったりする点で有利である。
【００２９】
決済後（決済完了と同時でも構わない）、決済処理を終えたオートレジ４の制御部２０は、今回の決済処理に係る情報を、決済情報としてサーバー２に通知する（図４のステップＳ３）。決済情報には、決済した料理（当該料理が盛り付けられた食器１７）の識別番号およびシリアルＮｏ．と、決済処理が完了した日時（利用日時）とが主に含まれている。制御部２０は、１件分の決済処理が完了すると、その都度、決済情報をサーバー２に通知する。
【００３０】
決済情報の通知を受けたサーバー２の制御部９（図１参照）は、当該決済情報を基に、記憶部１０（図１参照）において、該当する食器１７（決済した料理についての食器１７）毎に利用日時を記録する（図４のステップＳ４）。
図５は、自動決済システム１のサーバー２に記憶されるデータを示す図である。
具体的に、記憶部１０には、図５に示すようなテーブル５０が記憶されており、このテーブル５０に、各食器１７の利用日時等のデータが記録される。図５のテーブル５０では、各食器１７について、識別番号（図５では「００３」）、シリアルＮｏ．（図５では「００００１」〜「００００５」）、前回棚卸日時、最終利用日時、利用日数、利用回数およびステータスが横並びで記録されている。なお、前回棚卸日時および最終利用日時のそれぞれにおいて、日付と時刻とは、別々の欄に記録されているが、同一の欄にまとめて記録されても構わない。なお、図５では、識別番号が００３の食器１７のデータしか示されていないが、実際には、それ以外の識別番号の食器１７のデータもテーブル５０に記憶されている。
【００３１】
前回棚卸日時は、直近で食器１７の棚卸しを実施した日時、その食器１７を食堂に導入した日時、および、その食器１７の初回利用日時のうち、いずれか遅い日時である。前回棚卸日時は、サーバー２のオペレータ（係員）が操作部１１（図１参照）を操作することによって手入力されても構わないし、食器１７の棚卸しや導入や初回利用の際に、図示しない端末に食器１７のタグ１８を読み取させることによって自動入力されてもよい。新品の食器１７が食堂に導入されたときには、その食器１７に対して識別番号が割り当てられ、当該識別番号と、この食器１７のシリアルＮＯ．と、導入日時（初期における前回棚卸日時となる）とがテーブル５０に記録される。食堂に導入された食器１７について、その後に棚卸しが実施されると、その都度、当該食器１７についての前回棚卸日時が、前述した手入力または自動入力によって更新される。なお、全ての食器１７が同じタイミングで導入されたり、棚卸しを受けたりするとは限らないので、前回棚卸日時は、食器１７毎にまちまちとなる場合がある（シリアルＮｏ．００００４の前回棚卸日時を参照）。
【００３２】
最終利用日時は、各食器１７について、サーバー２がオートレジ４から直近で受信した最新の利用日時であり、換言すれば、直近で食器１７が利用された（当該食器１７のタグ１８がタグＲ／Ｗ部１６に認識された）日時である。
利用日数は、各食器１７について、前回棚卸日時から現在までの期間でサーバー２が利用日時（決済情報）を受信した日の合計日数である。たとえば、シリアルＮｏ．が００００１の食器１７の場合、利用日数が１７３日であることから、前回棚卸日時（２０１１／４／１の１５：１３）から現在（最終利用日時（２０１１／１２／２０の１２：３１）以降）までの期間において、この食器１７が１７３日利用された（当該食器１７のタグ１８が１７３日タグＲ／Ｗ部１６に認識された）ことになる。
【００３３】
利用回数は、各食器１７について、前回棚卸日時から現在までの期間でサーバー２が利用日時を受信した回数の合計である。たとえば、シリアルＮｏ．が００００１の食器１７の場合、利用日数が２０８回であることから、前回棚卸日時から現在までの期間において、この食器１７が２０８回利用された（当該食器１７のタグ１８が２０８回タグＲ／Ｗ部１６に認識された）ことになる。
【００３４】
サーバー２の制御部９は、決済情報の通知を受けると、その都度、テーブル５０において、当該決済情報に含まれるシリアルＮｏ．の食器１７についての最終利用日時、利用日数および利用回数を更新する。なお、ここでの更新は、後述する警告条件を入力したときに実施されてもよい。
ステータスは、各食器１７についての特記事項であり、追って具体例を挙げながら説明する。
【００３５】
これらのデータ（各シリアルＮＯ．の食器１７についての前回棚卸日時、最終利用日時、利用日数、利用回数およびステータス）は、シリアルＮｏ．を記憶したタグ１８の利用履歴でもある。よって、サーバー２は、記憶部１０（テーブル５０）において、タグＲ／Ｗ部１６が読み取った複数のタグ１８の各利用履歴を管理していることになる。
次に、食堂で実施される棚卸し作業について説明する。
【００３６】
図６は、食器１７の棚卸し作業の流れを示すフローチャートである。
食堂では、食堂の係員（当該係員とは別の専門の業者である場合もある）によって定期的（たとえば月に１度）に食器１７の棚卸しが実施される。棚卸しでは、食堂内の食器１７が係員によって１つずつチェックされ、食器１７の実際の在庫数とサーバー２に記憶された在庫数とが一致するか否かが、食器１７の種類毎（前述した識別番号毎）に確認される。
【００３７】
棚卸しの際、食器１７自体の損傷の有無が係員によって確認されるとともに、食器１７に取り付けられたタグ１８の不具合（故障）も確認される。たとえば、熱や衝撃によって、タグ１８内でＩＣチップが破損したり、コイルが断線したりすることがある。このように故障して不良品となったタグ１８（以下では、「不良タグ」ということがある）は、タグＲ／Ｗ部１６によって認識できない。食器１７の故障の有無は目視によって容易に発見できるが、タグ１８の不具合の有無を目視で確認することは困難である。タグ１８の不具合の有無を確認する作業は、食器１７を１つずつタグＲ／Ｗ部１６にかざして各食器１７のタグ１８がタグＲ／Ｗ部１６によって認識されるか否かをチェックする必要があり、食堂内の全ての食器１７をチェックする場合には、大変な重労働になる。
【００３８】
このような問題を解決するために、この自動決済システム１は、故障したタグ１８の不良品（不良タグ）を自動検知できるようになっている。そして、自動決済システム１を用いた以下の手順を踏むことによって、タグ１８の不具合の有無（不良タグの有無）を容易に見つけることができる。
図６を参照して、係員は、まず、故障したタグ１８を抽出して当該タグ１８の故障を警告するための警告条件を設定する（ステップＳ１１）。警告条件とは、前述したテーブル５０（図５参照）にデータ登録された食器１７の中から、故障した（厳密には、故障した可能性が高い）タグ１８を抽出するための所定条件である。故障したタグ１８が取り付けられた食器１７は、他の（タグ１８が故障していない）食器１７よりも最終利用日時からの利用実績がない。つまり、故障したタグ１８とは、導入を開始してからの所定期間（たとえば、導入開始から現在までの期間）内における利用実績が相対的に低いタグ１８であって、警告条件とは、このようなタグ１８を検出するための条件である。
【００３９】
故障したタグ１８が取り付けられた食器１７の場合、たとえば、最終利用日時は、他の（タグ１８が故障していない）食器１７よりも著しく前（先）であり、利用日数および利用回数は、他の食器１７よりも著しく少なくなる傾向にある。最終利用日時についての警告条件は、最終利用日時（時刻は問わなくてもよい）が今回の棚卸し作業よりも所定日数以前であることであり、利用日数および利用回数についての警告条件は、所定期間内における利用日数および利用回数がそれぞれの閾値未満であることである。係員は、食堂の運用状況に応じて、いずれかの警告条件中から最適なものを設定（選択）し、サーバー２の操作部１１を操作することによって（選択した）警告条件をサーバー２に入力する。なお、警告条件は１つだけでなくてもよく、複数の警告条件（後述する他の警告条件も含む）が適宜組み合わされて選択されてもよい。つまり、たとえば、最終利用日時および利用回数の両方についての警告条件を選び、どちらかの警告条件に先に引っ掛かった食器１７のタグ１８を不良タグとして警告してもよい。
【００４０】
警告条件が入力されたサーバー２では、制御部９が、当該警告条件の入力を受け付ける。そして、制御部９は、テーブル５０内の全ての食器１７のデータについて、当該警告条件に引っ掛かるか否かを判定し、該当する食器１７が見つかった場合には、警告判定を行う（ステップＳ１２）。ここでは、制御部９は、テーブル５０内のデータ（各タグ１８についての前述した利用履歴）および警告条件に基づいて不良タグを抽出していることになる。
【００４１】
なお、以降では、警告条件に引っ掛かった食器１７が見つかったものとして説明を続ける。
図５を参照して、たとえば、最終利用日時が今回の棚卸し作業日（２０１１／１２／２０であるとする）よりも所定日数（ここでは、７日）以前であること、つまり、最終利用日時から７日以上経過していることを警告条件とした場合、最終利用日が２０１１／１２／１２であって識別番号００３でシリアルＮｏ．００００３の食器１７が、警告条件に引っ掛かる。この場合、制御部９は、テーブル５０において、この（シリアルＮｏ．００００３の）食器１７のステータスを「警告」とすることによって、この食器１７に対して警告判定する。
【００４２】
また、別の警告条件として、利用日数が所定日数（前述した閾値であり、たとえば１５０日）未満であることや、利用回数が所定回数（前述した閾値であり、たとえば１６０回）未満であることを採用してもよい。ただし、利用日数および利用回数を定める基準となる前回棚卸し日時が全ての食器１７で同じである場合に、利用日数および利用回数を警告条件にすることが好ましい。なぜなら、前述したように前回棚卸し日時が全ての食器１７で同じとは限らないので、前回棚卸し日時が他の食器１７よりも後の食器１７が、タグ１８が故障していないのに、警告条件に引っ掛かってしまう虞があるからである（シリアルＮｏ．００００４の食器１７を参照）。
【００４３】
そこで、タグ１８が故障していない食器１７が警告条件に引っ掛かってしまうことを避けるために、さらに別の警告条件として、利用日数あたりの利用回数（以下では、「単位利用回数」ということにし、テーブル５０の利用回数を利用日数で割って得られる値）が一定回数未満であることを採用してもよい。大体の食器１７が毎日１回は利用されることを前提とすると、当該一定回数は、たとえば、０．９回／日と設定される。なお、食器１７は毎日１回利用されることを前提としたが、人気のないおかずであれば余る可能性があることを考慮して、実際の設定値（前記一定回数）はもう少し低めの値であってもよい。図５の場合、識別番号００３でシリアルＮｏ．００００３の食器１７だけが、その単位利用回数が０．８８（≒１５３回÷１７３日）回／日であって当該一定回数（０．９回／日）未満であることから、警告条件に引っ掛かる。この場合、制御部９は、テーブル５０において、この（シリアルＮｏ．００００３の）食器１７のステータスを「警告」とすることによって、この食器１７に対して警告判定する。
【００４４】
以上のように所望の警告条件を用いた警告判定の後、制御部９は、警告条件に引っ掛かった食器１７（タグ１８）の情報として、当該食器１７の識別番号およびシリアルＮｏ．をサーバー２の表示部１２（図１参照）に表示する（ステップＳ１３）。なお、ここでは、警告条件に引っ掛かった食器１７と識別番号（種類）が同じである他の食器１７の情報も表示部１２に表示されてもよく、この場合、図５のテーブル５０の登録内容がそのまま表示部１２に表示されてもよい。
【００４５】
また、前述したように、食器１７の識別番号は、当該食器１７の種類（ご飯茶碗、お椀、小皿等）と一致しているので、識別番号とともに、または、識別番号の代わりに、食器１７の種類が表示部１２に表示されてもよい。さらに、食器１７の種類毎の画像（たとえば、ご飯茶碗の画像）が、サーバー２で記憶されていて、食器１７の識別番号および種類とともに、または、これらの代わりに、食器１７の画像が表示部１２に表示されてもよい。このように、制御部９は、ステップＳ１３において、警告対象の食器１７（タグ１８）の情報を表示部１２（サーバー画面）に表示することによって、ステップＳ１２で抽出した不良タグを係員に報知する。係員とっては、制御部９による表示部１２での報知内容によって不良タグを把握できるので便利である。
【００４６】
前述した識別番号００３でシリアルＮｏ．００００３の食器１７（図５参照）が警告条件に引っ掛かったとした場合、係員は、表示部１２に表示された食器１７の情報を閲覧し、識別番号が００３の食器１７群の中に、タグ１８が故障した食器１７が紛れていることを把握する。この実施形態では、タグ１８の表面にシリアルＮｏ．が表示されていないので、タグ１８を見ても、そのタグ１８に記録されたシリアルＮｏ．は分からないが、表示部１２に表示された食器１７の識別番号によって、タグ１８が故障した食器１７の種類を全種類の中から絞り込むことができる。
【００４７】
係員は、警告条件に引っ掛かった識別番号（ここでは、００３）に対応する種類の全ての食器１７を１つずつオートレジ４のタグＲ／Ｗ部１６にかざして、各食器１７のタグ１８がタグＲ／Ｗ部１６によって正常に認識されるか否かの読取テストを行う（ステップＳ１４）。これにより、警告条件に引っ掛かったシリアルＮｏ．（ここでは、００００３）の食器１７だけがタグＲ／Ｗ部１６に認識されないので、この結果を受けて、係員は、タグＲ／Ｗ部１６に認識されなかったシリアルＮｏ．００００３の食器１７のタグ１８（不良タグ）を排除する（ステップＳ１４）。
【００４８】
係員は、警告条件に引っ掛かった食器１７のタグ１８を排除し、警告条件に引っ掛かったタグ１８が他に存在しないことを確認した後、サーバー２の操作部１１を操作する。この操作に応じて、制御部９は、テーブル５０における当該食器１７（ここでは、シリアルＮｏ．００００３の食器１７）についてのステータスを、図５に示す「警告」から図７に示す「排除済」に変更する（ステップＳ１５）。
【００４９】
そして、全ての棚卸し作業が完了すると、係員は、サーバー２の操作部１１を操作して、棚卸し作業の完了を確定させる。この操作に応じて、制御部９は、テーブル５０において、ステータスが「排除済」となった食器１７を除く全ての食器１７について、利用日数および利用回数を０（零）にクリアし、前回棚卸し日時を、今回の棚卸し作業の完了日時（たとえば、２０１１／１２／２０の１７：００）に変更（更新）する。これらのデータ変更が終わった状態のテーブル５０は、図８に示されている。なお、ステータスが「排除済」となった食器１７についての全てのデータがテーブル５０から消去されてしまっても構わない。
【００５０】
以上のように、自動決済システム１では、商品（ここでは、料理）を決済する際にタグＲ／Ｗ部１６が読み取った各タグ１８の利用履歴をサーバー２が管理している。そのため、不良タグの疑いのあるタグ１８（利用頻度が他のタグ１８より低い）を利用履歴に基づいて絞り込み（厳密には、不良タグの疑いのあるタグ１８が付いた食器１７の種類を絞り込み）、早期に把握できる。そして、絞り込んだ（不良タグの疑いのある）タグ１８だけをタグＲ／Ｗ部１６で読み取れるか否かテストすれば、全てのタグ１８をテストする手間をかけずに済み、不良タグの検知にかかる時間を短縮できる。その結果、不良タグを容易に発見することができる。
【００５１】
特に、不良タグの疑いのあるタグ１８を利用履歴および警告条件（導入を開始してからの所定期間内における利用実績が相対的に低いタグ１８を検出できる条件）に基づいて高精度に抽出できる（絞り込める）ので、不良タグを一層容易に発見することができる。
不良タグを容易に発見できることによって、故障した不良タグを早期に排除できるので、見過ごされた不良タグによる食堂の売上損失を減少させることができる。
【００５２】
また、このような自動決済システム１では、ハードウェアを変更せずに、ソフトウェア（サーバー２の記憶内容や制御部９の動作）を変更するだけで、故障の疑いのあるタグ１８を発見することができる点でも利点がある。
この発明は、以上の実施形態の内容に限定されるものではなく、請求項記載の範囲内において種々の変更が可能である。
【００５３】
たとえば、タグ１８の表面や食器１７の表面に、このタグ１８に記憶されたシリアルＮｏ．が目視可能に表示されていてもよい。この場合、警告条件に引っ掛かったシリアルＮｏ．のタグ１８が付いた食器１７を、オートレジ４のタグＲ／Ｗ部１６でチェックすることなく、すぐにピンポイントで見つけて排除することができる。
また、テーブル５０では、各食器１７（タグ１８）の連続不利用日数（最後に利用されてから次に利用されるまでの経過日数）が管理されていてもよい。タグ１８が故障した場合、そのタグ１８がそれ以降利用されることがないことから、このタグ１８について故障時から次回棚卸しまでの日数は、連続不利用日数となる。所定期間内における連続不利用日数が所定の閾値を超えて極端に多いことを、前述した警告条件としてもよい。
【００５４】
また、前述した実施形態では、個々の食器１７における最終利用日時や利用日数や利用回数（前述した単位利用回数も含む）や連続不利用日数を用いて警告条件を設定し、警告条件に引っ掛かった食器１７のタグ１８が故障しているものと推定している。これらの最終利用日時や利用日数や利用回数や連続不利用日数を用いるだけでも、故障したタグ１８をかなりの精度で簡易的に発見することができるが、故障したタグ１８の発見精度を高めるためには、以下の統計データを用いた方法が挙げられる。
【００５５】
図９（ａ）および（ｂ）は、サーバー２に記憶されるデータを示す図である。
サーバー２の記憶部１０（図１参照）には、前述したテーブル５０とは別に、図９（ａ）に示すテーブル６０と、図９（ａ）に示すテーブル６１とが記憶されている。
図９（ａ）を参照して、テーブル６０では、各食器１７について、前述した識別番号（食器１７の種類）およびシリアルＮｏ．と、データＮｏ．と、所定の評価期間（ここでは、１／１６〜１／２６までの１１日間）の日別の利用有無ｉ（Ｔ）とが記憶されている。ここでのＴとは、評価期間におけるそれぞれの日（図９（ａ）の場合には、１／１６〜１／２６のいずれか）である。なお、図９（ａ）では、識別番号が００３の食器１７のデータしか示されていないが、実際には、それ以外の識別番号の食器１７のデータもテーブル６０に記憶されている。
【００５６】
データＮｏ．は、テーブル６０における各食器１７のデータ（前述した日別の利用有無ｉ（Ｔ））を同一識別番号の食器１７間で関連付けるために設けられており、図５では、上下に隣り合う食器１７のデータ間で、データＮｏ．が１→２→３→４→５というように連番になっている。図５では、一例として、１のデータＮｏ．は、シリアルＮｏ．が００００１のデータ（利用有無ｉ（Ｔ））に対応しており、５のデータＮｏ．は、シリアルＮｏ．が００００５のデータに対応している。
【００５７】
日別の利用有無ｉ（Ｔ）は、各シリアルＮｏ．の食器１７について、前述した評価期間のそれぞれの日に設けられている。たとえば、評価期間のいずれかの日において、利用があった（前述した利用日時がサーバー２に送信された）食器１７のその日における利用有無ｉ（Ｔ）は、利用ありを意味する「０（零）」となる（たとえば、００００１のシリアルＮｏ．における１／１６のｉ（Ｔ（＝１／１６））を参照）。一方、評価期間のいずれかの日において、利用がなかった（前述した利用日時がサーバー２に送信されなかった）食器１７のその日における利用有無ｉ（Ｔ）は、利用なしを意味する「１」となる（たとえば、００００２のシリアルＮｏ．における１／１７のｉ（Ｔ（＝１／１７））を参照）。たとえば、食堂が休日となる土日には、全ての食器１７の利用有無ｉ（Ｔ）は、「１」となる（たとえば、全てのシリアルＮｏ．における１／２１および１／２２のｉ（Ｔ（＝１／２１，１／２２））を参照）。なお、食堂が開いている平日では、営業時間が終わるまでの間は、全ての食器１７の利用有無ｉ（Ｔ）は、「０」になっていて、営業時間終了後の時点でその日の利用が１度もなかった食器１７の利用有無ｉ（Ｔ）は、「０」→「１」となってテーブル６０に記録される。このように、サーバー２は、記憶部１０のテーブル６０において、所定期間（評価期間）のそれぞれの日における各食器１７（各タグ１８）の利用有無ｉ（Ｔ）を、タグ１８の利用履歴として管理している。
【００５８】
また、テーブル６０には、同一の識別番号の全ての食器１７における評価期間の日別の利用有無ｉ（Ｔ）の平均ｍ（Ｔ）も記録されている（テーブル６０の最下欄を参照）。たとえば、１／１６における平均ｍ（Ｔ（＝１／１６））は、０．２（＝（０＋０＋０＋０＋１）／５）である。
係員が、前述した評価期間以後（たとえば、評価期間満了日の翌日）に棚卸しを実施するためにサーバー２の操作部１１を操作すると、制御部９は、テーブル６０のデータに基づいて、図９（ｂ）のテーブル６１を作成する。テーブル６１では、各食器１７について、前述した識別番号（食器１７の種類）およびシリアルＮｏ．と、データＮｏ．と、先ほどの評価期間の日別の評価値Ｋ（Ｔ）とが記憶されている。なお、図９（ｂ）では、識別番号が００３の食器１７のデータしか示されていないが、実際には、それ以外の識別番号の食器１７のデータもテーブル６１に記憶されている。
【００５９】
データＮｏ．、識別番号およびシリアルＮｏ．は、テーブル６０（図９（ａ）参照）のデータＮｏ．、識別番号およびシリアルＮｏ．と一致している。つまり、テーブル６１でも、テーブル６０と同様に、データＮｏ．１は、シリアルＮｏ．が００００１のデータ（テーブル６１では評価値Ｋ（Ｔ））に対応しており、データＮｏ．５は、シリアルＮｏ．が００００５のデータに対応している。
【００６０】
日別の評価値Ｋ（Ｔ）は、各シリアルＮｏ．の食器１７について、前述した評価期間のそれぞれの日における利用有無ｉ（Ｔ）および平均ｍ（Ｔ）等に基づいて、以下の式（１）で算出される。
Ｋ（Ｔ）＝ａ・Ｋ（Ｔ−１）＋ｂ・ｉ（Ｔ）・（１−ｍ（Ｔ））…式（１）
ここで変数ａおよびｂは、経験上で得られた変数であり、変数ａは、０．９であり、変数ｂは、１である。Ｋ（Ｔ−１）とは、前日のＫ（Ｔ）のことである。また、ｉ（Ｔ）とは、テーブル６０（図９（ａ）参照）における同じ日の同じシリアルＮｏ．での利用有無ｉ（Ｔ）である。また、ｍ（Ｔ）とは、テーブル６０における同じ日の平均ｍ（Ｔ）である。
【００６１】
たとえば、評価期間の初日（ここでは、１／１６）における各食器１７では、Ｋ（Ｔ−１）が０（零）となり（評価期間より前日（ここでは、１／１５）の評価値Ｋ（Ｔ）が存在しないため）、シリアルＮｏ．００００５の利用有無ｉ（Ｔ（＝１／１６））だけが「１」であり、平均ｍ（Ｔ（＝１／１６））が０．２である（図９（ａ）参照）。これらの値を式（１）に代入することにより、１／１６では、シリアルＮｏ．００００５の評価値Ｋ（Ｔ（＝１／１６））だけが０．８０と算出され、他のシリアルＮｏ．（００００１〜００００４）の評価値Ｋ（Ｔ（＝１／１６））は、全て０．００と算出される。
【００６２】
また、たとえば、１／１８におけるシリアルＮｏ．００００２の食器１７では、前日（１／１７）のＫ（Ｔ−１（＝１／１７））が０．８０となり、当日（１／１８）の利用有無ｉ（Ｔ（＝１／１８））が１であり、当日の平均ｍ（Ｔ（＝１／１８））が０．２である（図９（ａ）参照）。これらの値を式（１）に代入することにより、１／１８におけるシリアルＮｏ．００００２の評価値Ｋ（Ｔ（＝１／１８））は、１．５２と算出される。
【００６３】
このようにして、制御部９は、各食器１７について、評価期間の全ての日における評価値Ｋ（Ｔ）を算出する。全ての評価値Ｋ（Ｔ）の算出が完了した状態が図９（ｂ）に示されている。そして、評価期間の最終日（評価日ともいい、ここでは、１／２６）における各食器１７の評価値Ｋ（Ｔ（＝１／２６））について、係員は、サーバー２の操作部１１を操作することによって、所定の閾値（ここでは、２．００）を設定し、当該最終日の評価値Ｋ（Ｔ）が閾値以上であることを警告条件としている。この場合、当該最終日の評価値Ｋ（Ｔ）が２．１２であって識別番号００３でシリアルＮｏ．００００３の食器１７が、警告条件に引っ掛かっている。この場合、制御部９は、テーブル５０（図５参照）において、この（シリアルＮｏ．００００３の）食器１７のステータスを「警告」とすることによって、この食器１７に対して警告判定する。その後の処理については、前述した実施形態と同様である（図６のステップＳ１３以降参照）。
【００６４】
この場合、制御部９は、所定期間（評価期間）内の所定の評価日以前の利用有無ｉ（Ｔ）および他のタグ１８の利用有無ｉ（Ｔ）に基づいて、当該評価日における各タグの故障可能性を、評価値Ｋ（Ｔ）として算出し、この評価値Ｋ（Ｔ）に基づいて不良タグを抽出している。つまり、食器１７の評価値Ｋ（Ｔ）とは、その食器１７自身の評価期間のそれぞれの日の利用有無だけでなく、休日の有無や、他の食器１７の利用有無ｉ（Ｔ）が考慮された（各タグ１８の）故障可能性である。このように所定期間内の所定の評価日以前の利用有無ｉ（Ｔ）および他のタグ１８の利用有無ｉ（Ｔ）といった統計データに基づいて算出した各タグ１８の故障可能性によって、不良タグを一層高精度に抽出することができる。
【００６５】
また、図１に示す自動決済システム１は、前述した食堂に限らず、コンビニエンスストアやスーパー等の商店での決済にも適用可能である。商店の場合、店内に陳列された各商品にタグ１８が取り付けられていて、客は、たとえば、複数の商品を選んで籠に入れてレジに向かう。客は、レジに設けられたオートレジ４に籠をセットすると、籠内の商品の全てのタグ１８がタグＲ／Ｗ部１６によってほぼ同時に読み取られて、商品名がオートレジ４の表示部１４（図１参照）に表示される。客は、自身のカード１３をカード処理端末５に読み取らせることで、自分が選んだ商品についての決済を行う。
【００６６】
また、前述した実施形態では、警告条件に引っ掛かったタグ１８が排除されるが、このタグ１８が取り付けられていた食器１７自体になんら問題がなければ、タグ１８を不良品から正常品に取り替えて食器１７を再利用しても構わない。
また、前述した実施形態では、プリペイド方式（前払方式）の電子マネーおよびプリペイドカード１３を用いているが、電子マネーをポストペイ方式（後払方式）とするとともにカード１３をクレジットカードとして、決済代金を後から回収する（社員食堂の場合には、社員の給与から天引きする）構成であってもよい。
【００６７】
また、図９において、食器１７が使用された場合には「０（零）」を記録しているが、この「０」は表示しなくてもよい。要は、食器１７が使用されたものか否かが分かればよいのである。
【符号の説明】
【００６８】
１    自動決済システム
２    サーバー
９    制御部
１６  タグＲ／Ｗ部
１８  タグ
【図１】
2013254325.tif 000003
【図２】
2013254325.tif 000004
【図３】
2013254325.tif 000005
【図４】
2013254325.tif 000006
【図５】
2013254325.tif 000007
【図６】
2013254325.tif 000008
【図７】
2013254325.tif 000009
【図８】
2013254325.tif 000010
【図９】
2013254325.tif 000011