JP4857946B2 - センサデバイス管理装置および方法 - Google Patents

Description

本発明は、センサデバイスと個体識別装置を用いて物品の情報を管理するユビキタス情報システムの運用管理装置および方法に関する。

ＲＦＩＤ（Radio Frequency Identification）やセンサノードといった、センサデバイスとＲＦＩＤタグなどの個体識別装置の組合せによって、従来まで情報システムに取り込むことが出来なかった現場の情報を参照可能にするユビキタス情報システムが構築されてきている。

ＲＦＩＤとは、非接触でデータの読み書きができる、汚れや埃の影響を受けにくいといった特徴を持つ、電波や電磁波などの無線を利用してＲＦＩＤリーダとの間でＩＣタグに格納された情報を送受信する技術であり、物品の識別や管理分野で利用されている。一般的なＲＦＩＤシステムは、個体識別情報を持つ複数のＩＣタグと、無線インタフェースを利用してＩＣタグ中の情報を取得するＲＦＩＤリーダから構成される。ＲＦＩＤリーダとＩＣタグは無線を利用して送受信を行うため、その通信距離は送受信に用いる無線の周波数によって異なる。ＩＣタグの持つ個体識別情報は、そのシステム中で一意となるように構成される。アンテナ側からの非接触電力伝送技術により、電池を持たない半永久的に利用可能なＩＣタグも存在する。

しかし、無線インタフェースを持つセンサデバイスは電波の干渉やハード故障等の原因により正しく現場の情報を読み取れないことがある。（以下、これをデバイスレベルエラーと呼ぶ。）ユビキタス情報システムでは、従来まで情報システムに取り込めなかった様々な場所を対象として情報を取得するため、一般にセンサデバイスの数は多くなる。このため、前述のデバイスレベルエラーはシステム全体では無視できない確率で発生することとなり、デバイスレベルエラーを前提としたシステムの構築が必要となっている。

センサデバイスとしてＲＦＩＤリーダを用い、個体識別装置としてＲＦＩＤタグを用いたシステムの一例として商品の在庫管理システムがある。こうしたシステムでは、データ参照の不確実性を考慮し、複数のＲＦＩＤリーダを使って同一の商品を監視するのが一般的である。このため、各ＲＦＩＤリーダが取得するＩＤの集合間には、規則性がある。この規則性を利用して、各リーダから取得したデータを解析・統合して付加価値のあるデータ生成を行うことができる。（特許文献１）また、ＲＦＩＤの各リーダから取得する情報に基づいて、リーダの異常を発見することができる。（特許文献２）
特表２００４−５３３０３４ 特開２００５−３５２０００

前記文献２に記載の従来技術は、特定のＲＦＩＤリーダ、ＲＦＩＤタグのハードウェア故障の検出を行う。この方法では、周囲の通信環境の変化および指向性の変化でデータ参照が出来なくなった状態については対応できないため、発見できるデバイスレベルエラーの範囲が狭い。

前記特許文献１に記載の従来技術は、複数の情報源からデータを取得し、自動解析して作成した付加価値のあるデータを蓄積および再配布する仕組みについての技術である。解析のためのルールは予め定義しておく必要がある。

複数のＲＦＩＤリーダで同一の商品を監視するようなシステムの場合、「複数のＲＦＩＤリーダが取得した識別情報には、一定割合以上の重複が存在するＲＦＩＤリーダのグループ」が存在することが多い。（以下、複数のセンサデバイスが取得した識別情報から所定の条件を満たすようなセンサデバイスのグループを抽出したものを規則と呼ぶ。）そして、この規則が不成立となる場合は、規則を構成するいずれかのＲＦＩＤリーダでデバイスレベルエラーが発生していると考えられる。このため、規則に着目してＲＦＩＤリーダのデバイスレベルエラーの発見に利用する方法がある。しかし、ＲＦＩＤリーダを使って商品の数を監視するようなシステムでは、扱うＲＦＩＤリーダの数が大量であるため、そこに現れる規則も大量になる。また、構成変更によるＲＦＩＤリーダの配置場所変更に伴い、規則も頻繁に変わることが考えられる。こうした状況から、人手での規則の生成、登録、変更は困難である。また、設定ミスや登録漏れも発生してしまう。

前記課題を解決するために、システムが正しく稼動している時点で各センサデバイスが取得する個体識別情報の集合をもとに規則を自動抽出する「リーダ間規則抽出機能」を提供する。この機能により、多数のセンサデバイスを用いたシステムでも規則の自動抽出が可能となる。また、所定の数の規則が不成立な状態となることを業務の変更として定義しておき、業務変更時には規則を再構築する「リーダ間規則再構築機能」で最新の規則を用いてシステムの監視を可能にする。

本発明によって、規則が自動抽出されるため、従来技術では困難であった規則の作成が可能となる。これによって、システムで発生するデバイスレベルエラーを発見することが可能となる。

また別には、不成立である規則が所定の数を超えた場合に規則再抽出を行うことによって、業務の変更や、環境の変化が多いシステムにおいて、最も適合した規則でシステムを監視することが可能となる。

以下、図面に基づき、本発明の実施の形態を説明する。

図１は、センサデバイスとしてＲＦＩＤリーダ、個体識別装置としてＲＦＩＤタグを用いたセンサデバイス運用管理システムの例を示すものである。レイアウト１５０、１６０、１７０のように、頻繁にセンサデバイスや個体識別装置の位置関係が変化する。

レイアウト１５０、１６０、１７０は、棚１１０、１１１上に配置されたＲＦＩＤタグの取り付けられた物品１３１〜１３４から、センサデバイス１２０および１２１を用いてデータ１５１、１６１、１７１を取得している様子を表している。

センサデバイスは無線によりＲＦＩＤタグから個体識別情報を取得するが、無線による通信可能距離によって、ＲＦＩＤタグと交信できる範囲が限られてくる。

レイアウト１５０では棚１１０、１１１は直列に配置され、レイアウト１６０では棚は並列で同方向に配置され、レイアウト１７０では棚は並列に向き合って配置されている。データ１５１、１６１、１７１に示すように、同じ性能のセンサデバイス、ＲＦＩＤタグを用いた場合でも、レイアウトが変わればセンサデバイスが持つ指向性、通信可能距離によって各センサデバイスが取得するデータは異なる。

データ取得機能２１１は、センサデバイス１２０および１２１が取得したデータ１５１または１６１または１７１を記憶部２４０に登録する。

候補規則抽出機能２２１および候補規則フィルタリング機能２２２は、記憶部２４０からデータを取得し、デバイスレベルエラーを監視するための規則および加工ロジックを自動抽出して記憶部２４０に登録する。本実施例では、候補規則フィルタリング機能２２２と候補規則抽出機能２２１は分かれているが、候補規則抽出機能２２１が候補規則フィルタリング機能２２２の機能を行うようにしてもよい。

データ加工機能２１２は、記憶部２４０に格納されたセンサデバイスが取得したデータおよび加工ロジックを用いて、各規則に対応する加工済データを作成する。

規則監視機能２３１は、記憶部２４０に登録された規則を取得し、センサデバイス１２０および１２１で発生するデバイスレベルエラーを監視する。例えば、各レイアウトで取得するデータ１５１〜１７１によれば、センサデバイス１２０と１２１の取得データには、それぞれ７５％、５０％、１００％の重複が存在する。データ１６１の例では、リーダＡがＩＤ１，２，３，４のＲＦＩＤと、リーダＢがＩＤ３，４のＲＦＩＤと交信し、個体識別情報を取得している。このうち、ＩＤ３とＩＤ４が重複しており、ＩＤの重複度は５０％（ＩＤ４個中２個重複）である。

データの重複が成り立たなくなる時はセンサデバイスにデバイスレベルエラーが発生するため、システムではこの重複度を利用してセンサデバイス１２０または１２１にデバイスレベルエラーを監視している。例えば、データ１６１においては、リーダＡとリーダＢの重複度は５０％であるが、リーダＢが故障すると、リーダＢではＲＦＩＤタグと交信できなくなり、５０％であった重複度が０％に変化する。

このように重複度が大幅に変化したことを監視しておけば、リーダＡかＢのいずれかにデバイスレベルエラーが発生したことを検知することが可能となる。また、このように重複度の変化したセンサデバイスのグループに対して、ＲＦＩＤタグのデータの取得情報を監視すれば、このグループの中のいずれかのリーダがデバイスレベルエラーとなっているかを判定することが可能となる。

例えば、先ほどの例であれば、リーダＡとリーダＢのグループに重複度の変化があったことを検知し、このリーダＡとリーダＢの、ＲＦＩＤタグの個体識別情報の取得の状態を収集すれば、リーダＢについて故障が発生したことを検知することができる。

図２は、運用管理サーバの全体構成を表す図の例である。このシステムは、例えば、複数のセンサデバイス２６０、２７０と複数の個体識別装置２８１〜２８３と、運用管理サーバ２００と記憶部２４０から構成することができる。以下の実施例では、センサデバイス２６０と２７０は同じ仕様であるとしているが、異なる仕様のハードウェアを用いてもよい。また、個体識別装置２８１〜２８３にも異なる仕様のハードウェア装置を用いてもよい。システム中のセンサデバイスおよび個体識別装置の数は、システムの規模に応じて増加させることができる。

運用管理サーバ２００は、メモリ２０１とプロセッサ２０２を有し、ディスクインタフェース２０３を通じて記憶部２４０にアクセスし、通信インタフェース２０４を通じて例えばインターネット等のネットワーク２０６に接続される。
メモリ２０１は、例えばＲＡＭ（Random Access Memory）で構成され、サーバプログラム２０５が読み込まれる。プロセッサ２０２は、例えばＣＰＵ（Central Processing Unit）で構成され、メモリ２０１上に読み込まれたプログラムを実行する。

サーバプログラム２０５はデータ取得機能２１１、データ加工機能２１２、候補規則抽出機能２２１、候補規則フィルタリング機能２２２、規則監視機能２３１、ユーザ通知機能２３２を有する。各機能についての詳細は後述する。

センサデバイス２６０は、例えばＲＦＩＤリーダで構成され、通信インタフェース２６１および無線インタフェース２６２を有する。

個体識別装置２８１〜２８３は、例えば、ＲＦＩＤタグで構成され、個体識別情報を含むデータを保持する。

センサデバイス２６０は、無線インタフェース２６２を通じて個体識別装置２８１〜２８３が保持する個体識別情報を取得し、通信インタフェース２６１を通じて運用管理サーバ２００に送る。

ここで、個体識別装置からのデータ取得は、システム定義管理テーブル２４３に定められた間隔で行ってもよいし、取得したデータは所定の規則によって加工した後、運用管理サーバに送られても良い。センサデバイス２７０はセンサデバイス２６０と同等の機能を有するものとする。

記憶部２４０は、例えば、ハードディスクで構成される。記憶部２４０は、プログラムコード２４１とデータ部２４２を有する。

データ部２４２は、システム定義管理テーブル２４３、デバイス管理テーブル２４４、加工タイプ管理テーブル２４５、一次データ管理テーブル２４６、加工ロジック管理テーブル２４７、加工済データ管理テーブル２４８、候補規則管理テーブル２４９、登録規則管理テーブル２５０から構成される。各テーブルのデータ構造については後述する。

運用管理サーバ２００は、ディスクインタフェース２０３を通じてプログラムコード２４１をメモリ２０１に読み込み、プロセッサ２０２を用いて実行することにより、複数の機能２１１〜２３２をそれぞれ実現する。しかしこれらはソフトウェアで実現するのみならず、データ取得部２１１、候補規則抽出部２２１、候補規則フィルタリング部２２２、データ加工部２１２、規則監視部２３１、ユーザ通知部２３２など、各処理を行う処理部として集積回路化するなどしてハードウェアで実現することもできる。

図７は、システムに必要な定義を格納する、システム定義管理テーブル２４３のデータ構造の例を表す。項目７２０と定義値７３０で、システムの定義を管理する。システム定義管理テーブルの各値はユーザが定義し、候補規則抽出機能２２１、候補規則フィルタリング機能２２２、規則監視機能２３１が使用する。

加工タイプ７２１は、図４の候補機能抽出処理において、データ加工機能２１２が加工済データを生成するための計算式である。計算式とは、複数のセンサデバイスが観測するデータ間に存在する関係を明らかにするものである。データ間に存在する関係には、例えば、複数のセンサデバイスが同一の個体識別情報を取得する割合に着目し、各センサデバイスが取得する個体識別情報の論理積を論理和で除した「重複度チェック」がある。また、同一の個体識別情報を取得しない割合に着目し、各センサデバイスが取得する個体識別情報の排他的論理和を論理和で除した「非重複度チェック」がある。また、「重複度チェック」と「非重複度チェック」の両方に着目してもよい。

「重複度チェック」では、複数のセンサデバイスが取得している個体識別情報の和集合に対して、その複数のセンサデバイスが取得している重複する個体識別情報である積集合の割合を求める。

加工タイプ７２１の定義値７３０には、図９で示す加工タイプ管理テーブル２４５のタイプＩＤ９１０またはタイプ名称９２０で定義された値が格納される。本実施例では、同一時間にセンサデバイスが取得したデータを対象としているが、所定の時間差で取得されたデータに着目して同様の関係について着目してもよい。

組合せデバイス数７２２は、図４の候補規則抽出処理において、加工ロジックデータを生成するために使用する。加工ロジックデータは、加工ロジック管理テーブル２４７に格納され、データ加工機能２１２が加工済データを生成する際の入力となるセンサデバイスの一覧および、データの計算式を表すタイプＩＤを保持する。

図８は、デバイス管理テーブル２４４のデータ構造の例を表す。デバイス管理テーブルは、システム中に存在するセンサデバイスを管理するために、個々のセンサデバイスについて、テーブル中で一意なＩＤであるデバイスＩＤ８２０およびデバイス名称８３０を保持する。デバイス管理テーブルの各値は、システムの構築時にユーザによって定義され、データ取得機能２１１、候補規則抽出機能２２１が使用する。

図９は、加工タイプ管理テーブル２４５のデータ構造の例を表す。加工タイプを表すタイプＩＤ９１０とタイプ名称９２０、各タイプに対応した計算式９３０を格納する。加工タイプ管理テーブルの各値は、システムに予め定義されており、計算式９３０はデータ加工機能２１２が、データ加工を行うときに使用する。

図１０は、一次データ管理テーブル２４６のデータ構造の例を表す。テーブル中で一意なデバイスＩＤ１０１０と取得識別情報１０２０によって、センサデバイスが取得した識別情報を格納する。一次データ管理テーブルの各値は、データ取得機能２１１がセンサデバイスから取得した値に基づき登録する。

図１１は、加工ロジック管理テーブル２４７のデータ構造の例を表す。テーブル中で一意なロジックＩＤ１１０と、加工タイプを表すタイプＩＤ１１２０、組合せに利用するデバイスＩＤ１１５０を格納する。本実施例ではデバイス組合せ数が２である場合のデータ構造を示しているが、組合せの数はこれに限るものではない。加工ロジック管理テーブルの各値は、候補規則抽出機能２２１、候補規則フィルタリング機能２２２によって作成され、規則監視機能２３１、ユーザ通知機能２３２によって利用される。この組み合わせで複数のセンサデバイスをグループ分けしている。

図１２は、加工済データ管理テーブル２４８のデータ構造の例を表す。テーブル中で一意なデータＩＤ１２１０、データを作成するために使用したロジックＩＤ１２２０、値１２３０を格納する。加工済データ管理テーブルの各値は、データ加工機能２１２によって作成される。作成のタイミングは、センサデバイスからのデータ取得のタイミングに特に制限されない。

図１３は、候補規則管理テーブル２４９のデータ構造の例を表す。テーブル中で一意な候補規則ＩＤ１３１０、ロジックＩＤ１３２０、値１３３０を格納する。候補規則管理テーブルの各値は、候補規則抽出機能２２１によって作成され、候補規則フィルタリング機能２２２で利用される。

図１４は、登録規則管理テーブル２５０のデータ構造の例を表す。テーブル中で一意な規則ＩＤ１４１０、ロジックＩＤ１４２０、値１４３０を格納する。登録規則管理テーブルの各値は、候補規則フィルタリング機能２２２によって作成され、規則監視機能２３１、ユーザ通知機能２３２で利用される。

プロセッサ２０２によって実現される各機能２１１〜２３２を説明する。これらは本来、プロセッサ２０２がプログラムに従って実行するが、ここでは説明を簡単にするために各機能２１１〜２３２を実行主体として説明する。また、各機能をハードウェアで実現した場合には、各ハードウェアの処理部が実行主体として実行することも可能である。

データ取得機能２１１は、通信インタフェース２０４を介してセンサデバイス２６０、２７０からセンサデバイスを一意に特定するデバイスＩＤ１０１０およびセンサデバイスが取得した取得識別情報１０２０を取得し、取得したデバイスＩＤがデバイス管理テーブル２４４のデバイスＩＤとして定義されていることを確認し、一次データ管理テーブル２４６に登録する。例えば、デバイスＩＤ「Ｓ１」であるセンサデバイス２６０が、個体識別装置２８１〜２８３からそれぞれ識別情報「１」「２」「３」を取得した場合には、デバイスＩＤ「Ｓ１」の取得識別情報として「１」「２」「３」を一次データ管理テーブル２４６に登録する。

データ取得機能２１１は、センサデバイスから取得した識別情報がデバイスＩＤではない場合には、デバイス管理テーブル２４４を参照してデバイスＩＤを取得する。例えば、センサデバイスから取得した識別情報がセンサデバイス名称８３０の値「リーダＡ」である場合は、対応するデバイスＩＤ「Ｓ１」を取得してデバイスＩＤとする。データの取得が所定の間隔を置いて行われる場合、データ取得機能２１１が一次データ管理テーブル２４６に格納するデータは、ある時間帯で取得されたデータとして認識される。

データ加工機能２１２は、加工ロジック管理テーブル２４７のロジックＩＤ１１１０の値「Ｌ１」に対応するタイプＩＤ１１２０の値「Ｔ１」および組合せデバイスＩＤ１１５０のセンサデバイスＡ１１４０の値「Ｓ１」およびセンサデバイスＢ１１５０の値「Ｓ２」を取得する。

データ加工機能２１２は、前記で取得したタイプＩＤ１１２０の値「Ｔ１」に対応する計算式を、加工タイプ管理テーブル２４５のタイプＩＤ９１０の値「Ｔ１」の計算式「論理積／論理和×１００」から取得する。

データ加工機能２１２は、前記で取得したセンサデバイスＡ１１４０の値「Ｓ１」に対応する取得識別情報「１」「２」「３」を、一次データ加工テーブル２４６のデバイスＩＤ１０１０の値「Ｓ１」の取得識別情報１０２０から取得する。センサデバイスＢの取得識別情報についても同様に取得識別情報「２」「３」を取得する。

データ加工機能２１２は、前記で取得した計算式「論理積/論理和×１００」およびセンサデバイスＡおよびセンサデバイスＢについて取得した取得識別情報を用いて、加工済データの値「６６」を計算して求める。「論理積/論理和×１００」はつまり、複数のセンサデバイスに対応付けられた個体識別情報の和集合「１」「２」「３」に対する、複数のセンサデバイスに対応付けられた個体識別情報の積集合「２」「３」の割合６６％を求めている。

本実施例では、組合せデバイスＩＤの数が２である場合について記述しているが、組合せデバイスの数が３以上である場合も同様の手順で加工済データの値を求める。

データ加工機能２１２は、加工済データ管理テーブル２４８中で一意なデータＩＤ１２１０として「Ｄ１」を作成し、「Ｄ１」に対応する値としてロジックＩＤ「Ｌ１」、値「６６」を加工済データ管理テーブル２４８に登録する。

センサデバイスの動作を監視するための規則は、候補規則抽出機能２２１および候補機能フィルタリング機能２２２によって実現される。

候補規則抽出機能２２１は、一次データ管理テーブル２４６に格納されたデータを用いて、規則の候補を抽出し、候補規則管理テーブル２４９に格納する。

候補規則フィルタリング機能２２２は、候補規則管理テーブル２４９に格納された候補規則をシステム定義管理テーブル２４３に格納された所定の条件でフィルタリングし、登録規則管理テーブルに格納する。各機能の詳細はフローチャートを用いて後述する。

図３は、センサデバイスの動作を監視するための規則を抽出する処理を表すフローチャートの例である。規則の抽出は、候補規則抽出処理Ｓ３１０と、候補規則フィルタリング処理Ｓ３２０からなる。各処理については後述する。

図４は、候補規則抽出処理を表すフローチャートの例であり、図３のＳ３１０に対応する。候補規則抽出機能２２１は、Ｓ４０１〜Ｓ４０６、Ｓ４０９〜Ｓ４１２を提供し、データ加工機能２１２はＳ４０７、Ｓ４０８を提供する。

候補規則抽出機能２２１は、図７で示すシステム定義管理テーブル２４３を参照し、加工タイプ７２１の値「重複度チェック」および組合せデバイス数７２２の値「２」を取得する（ステップＳ４０１）。

加工タイプ７２１の定義値７３０「重複度チェック」に対応する計算式を、加工タイプ管理テーブル２４５のタイプ名称９２０の値が「重複度チェック」である計算式９３０「論理積／論理和×１００」から取得する。前ステップで取得した加工タイプ７２１がタイプ名称である場合は、ここで計算式に加えてタイプＩＤ「Ｔ１」を取得する（Ｓ４０２）。

デバイス管理テーブル２４４のデバイスＩＤ８２０からシステムで管理しているデバイスＩＤの一覧「Ｓ１」、「Ｓ２」、「Ｓ３」、「Ｓ４」を取得する（Ｓ４０３）。

前ステップで取得したデバイスＩＤの一覧と組合せデバイス数７２２の定義値「２」より、デバイスの組合せリスト（Ｓ１、Ｓ２）（Ｓ１、Ｓ３）（Ｓ１、Ｓ４）（Ｓ２、Ｓ３）（Ｓ２、Ｓ４）（Ｓ３、Ｓ４）を作成する（Ｓ４０４）。

候補規則抽出機能２２１は、各デバイス組合せについて、Ｓ４０１またはＳ４０２で取得したタイプＩＤ「Ｔ１」を付与して加工ロジック管理データＬ１〜Ｌ６を作成し、加工ロジック管理テーブル２４７に登録する。本実施例では、組合せデバイス数７２２の定義値は「２」、デバイス数が「４」であるが、デバイス管理テーブル２４４に登録されているデバイス数がｍ、組合せデバイス数７２２がｎである場合は、加工ロジック管理データはｍＣｎ個作成される。また、組合せデバイス数７２２の定義値を最大組合せデバイス数として、ｎより少ない組合せについても規則を抽出してもよい（Ｓ４０４）。

候補規則抽出機能２２１は、Ｓ４０５、Ｓ４１１、Ｓ４１２、Ｓ４０４で作成した加工ロジック管理データの数だけＳ４０６〜Ｓ４１０を実行する。

候補規則抽出機能２２１は、一次データ管理テーブル２４６を参照し、加工ロジックデータに含まれる各センサデバイスが取得した一次データを取得する。例えば、ロジックＩＤ１１１０の値が「Ｌ１」である加工ロジックデータは、センサデバイス「Ｓ１」「Ｓ２」が取得した一次データを対象とするので、一次データ管理テーブルでデバイスＩＤ１０１０の値が「Ｓ１」である取得識別情報「１」「２」「３」を、デバイスＩＤ１０１０の値が「Ｓ２」に対応する取得識別情報「２」「３」を取得する（Ｓ４０６）。

データ加工機能２１２は、前ステップで取得した一次データとＳ４０２で取得した計算式９３０を用いて、加工済データを生成する。前ステップでセンサデバイス「Ｓ１」と「Ｓ２」それぞれについて識別情報を取得しているので、これをもとに論理和「１」「２」「３」および論理積「２」「３」を求める。次に、計算式「論理積／論理和×１００」に当てはめ、加工済データの値「６６」を得る（Ｓ４０７）。

図１０の一次データ管理テーブル２４６には図示していないが、例えばデバイスＩＤが「Ｓ３」であるセンサデバイスが、取得識別情報「２」「３」「４」を取得しており、一次データ管理テーブル２４６に格納されている場合を考える。

「Ｓ１」のセンサデバイスが取得している取得情報は「１」「２」「３」なので、（Ｓ１，Ｓ３）のグループは、論理和「１」「２」「３」「４」、論理積「２」「３」が求まり、計算式「論理積／論理和×１００」では、「５０」が得られる。

また、デバイス管理テーブル２４４に登録されているデバイス数が４、組合せデバイス数７２２が３である場合、４Ｃ３＝４個の規則が抽出される。具体的には（Ｓ１、Ｓ２、Ｓ３）（Ｓ１、Ｓ２、Ｓ３）（Ｓ１、Ｓ３、Ｓ４）（Ｓ２、Ｓ３、Ｓ４）の４個の規則が抽出される。これに対して（Ｓ１、Ｓ２、Ｓ３）のグループの規則であれば、このＳ１〜Ｓ３のセンサデバイスが取得した取得識別情報の和集合を求め、これらＳ１〜Ｓ３で重複している取得識別情報である積集合を求め、この積集合／和集合×１００を求めることになる。

例えば、先の例と同様、「Ｓ１」が「１」「２」「３」を取得し、「Ｓ２」が「２」「３」を取得し、「Ｓ３」が「２」「３」「４」を取得している場合を考える。

複数のセンサデバイスＳ１、Ｓ２、Ｓ３に対応付けられた個体識別情報の和集合「１」「２」「３」「４」に対する、複数のセンサデバイスＳ１，Ｓ２，Ｓ３に対応付けられた個体識別情報の積集合「２」「３」の割合５０％が求められる。

データ加工機能２１２は、加工済データ管理テーブル２４８中で一意なデータＩＤ１２１０「Ｄ１」を作成し、データの加工に使用したロジックＩＤ１２２０である「Ｌ１」、前ステップで作成した加工済データの値「６６」と共に、加工済データ管理テーブル２４８に登録する（Ｓ４０８）。

加工済みデータ管理テーブル２４８の値１２３０は一定の期間毎に、または常に更新され、最新の重複度等の値になる。

候補規則抽出機能２２１は、ステップ４０４で作成した加工ロジック管理データを加工ロジック管理テーブル２４７に登録する（Ｓ４０９）。

候補規則抽出機能２２１は、Ｓ４０８で値を作成するのに使用したロジックＩＤおよび加工済データの値を、候補規則管理テーブル２４９に登録する。例えば、ロジックＩＤ「Ｌ１」と加工済データの値「６６」を、候補規則管理テーブル２４９に登録する（Ｓ４１０）。

図５は、候補規則フィルタリング処理を表すフローチャートの例であり、図３中のＳ３２０に対応する。候補規則フィルタリング機能２２２は、Ｓ５０１〜Ｓ５１０を提供する。

候補規則フィルタリング機能２２２は、システム定義管理テーブル２４３を参照し、データの許容幅７２３の値「±５％」および規則成立条件７２４の値「３０％以上の重なり」を取得する（Ｓ５０１）。

取得データの許容幅７２３は、候補規則フィルタリング機能２２２が作成する規則に許容幅を持たせるために使用する。周囲の環境変化によって、センサデバイスが常に同じデータを取得できず、取得データに揺らぎが発生している場合に値を指定する。

規則抽出の際に算出した値をＸ、データの許容幅７２３をＹとした場合には、規則では値がＸ−ＹからＸ＋Ｙまでの間に入っていることを監視する。データの許容幅７２３には０以上の値を設定し、システムで使用するセンサデバイスの精度が高いほど低く設定する。高精度なセンサデバイスを使用する場合は「０％」としてもよいし、指定しなくてもよい。

規則成立条件７２４は、候補規則フィルタリング機能２２２が、候補規則抽出機能２２１が作成した候補規則から規則を絞り込むための条件を表す。例えば、候補規則ＩＤ１３１０が「ＣＲ１」である場合の値「６６」（６６％の重なりを示す）が、規則成立条件「３０％以上の重なり」を満たしているかどうかを判定することによって、候補規則を絞り込んでいく。なお、本実施例では、規則成立条件は１つであるが、複数の条件を指定してもよい。また、複数条件を指定する場合は、条件を全て満たすものを規則としてもよいし、条件のうち一つでも満たすものを規則としてもよい。

候補規則フィルタリング機能２２２は、候補規則管理テーブル２４９を参照し、候補規則を取得する（Ｓ５０２）。Ｓ５０３、Ｓ５０８、Ｓ５０９により、前ステップで取得した候補規則の数だけ、Ｓ５０４〜Ｓ５０７を実行する。

全ステップで取得した候補規則がＳ５０１で取得した規則成立条件７２４の値「３０％以上の重なり」を満たしているかどうかを判定し（Ｓ５０４）、条件を満たしていればＳ５０５に、見なしていなければＳ５０７に処理を進める。例えば、図１３の候補規則管理テーブルにおいて、候補規則ＩＤ１３１０が「ＣＲ１」である場合の値は「６６」であるため、規則成立条件「３０％以上」を満たしているとしてＳ５０５の処理に進む。また候補規則ＩＤ１３１０が「ＣＲ３」である場合の値は「０」であるため、条件を満たしていないとしてＳ５０７に処理を進める。

規則成立条件７２４を満たした候補規則を規則として作成する。この際、登録する値１３３０はデータの許容幅７２３の値「±５％」によって加工する。例えば、候補規則ＩＤ１３１０が「ＣＲ１」である場合の値「６６」は「６１〜７１」として加工する（Ｓ５０５）。

登録規則管理テーブル内で一意な規則ＩＤ１４１０を生成し、前ステップで作成した規則と共に登録規則管理テーブル２５０に登録する。例えば、候補規則ＩＤ１３１０の「ＣＲ１」に対応した規則の登録時には、規則ＩＤ１４１０として「Ｒ１」を作成し、ロジックＩＤ「Ｌ１」、値「６１〜７１」と共に登録規則管理テーブルに格納する（５０６）。

ロジックＩＤ１３２０の値を用いて、規則成立条件７２４を満たさなかった候補規則に対応する加工ロジックを、加工ロジック管理テーブル２４７からを削除する。例えば、候補規則管理ＩＤが「ＣＲ３」の値「０」は、規則成立条件７２４の値「３０％以上の重なり」を満たさないので、「ＣＲ３」に対応するロジックＩＤ１３２０の値「Ｌ３」に対応する加工ロジックデータ１１１３を、加工ロジック管理テーブル２４７から削除する（Ｓ５０７）。

候補規則管理テーブル２４９から、全ての候補規則を削除することにより、登録規則管理テーブル２５０を作成する（Ｓ５１０）。このようにして、複数のセンサデバイスをグループ分けして、そのうち重複度が所定の条件を満たすグループを監視対象の規則として抽出する。別の言い方をすると、複数のセンサデバイスのうち、重複度が所定の条件を満たすセンサデバイスをグループとして抽出して監視する。

規則監視機能２３１は、センサデバイスから抽出され一次データ管理テーブルに格納されたデータを登録規則管理テーブル２５０に格納された規則に基づいてセンサデバイスの異常を監視する。異常を発見した場合、規則監視機能２３１は、ユーザ通知機能２３２を用いてユーザに異常を通知する。また、所定の数以上の規則が不成立となった場合には、候補規則抽出機能２２１および候補規則フィルタリング機能２２２を呼び出して、規則の再抽出を行う。

ユーザ通知機能２３２は、規則監視機能２３１がセンサデバイスの異常を発見した際に呼び出され、例えばメールやシステムログなどを用いてユーザや管理者に通知を行う。この通知では、センサデバイスに異常が発生した旨、どのセンサデバイスに異常が発生しているか、どの規則が条件を満たさなくなっているか、再抽出する場合には再抽出する旨、条件を満たさなくなったセンサデバイスのグループなどを通知する。 これらの通知はユーザや保守員、管理者などが使用している、コンピュータなどの端末や携帯電話などに通知する。

図６は、規則監視処理を表すフローチャートの例である。規則監視機能２３１は、Ｓ６０１〜Ｓ６１０およびＳ６１２を提供し、ユーザ通知機能２３２はＳ６１１、Ｓ６１３を提供する。

規則監視機能２３１は、再抽出チェックカウンタを「０」で初期化する。再抽出チェックカウンタは、不成立となった規則の数を表すカウンタであり、０以上の値をとる（Ｓ６０１）。

登録規則管理テーブル２５０を参照し、登録された規則の規則ＩＤ１４１０、ロジックＩＤ１４２０、値１４３０を取得し保持する。例えば、規則ＩＤ「Ｒ１」、ロジックＩＤ「Ｌ１」、値「６１〜７１」を取得する。このとき、登録規則管理テーブル２５０に登録された規則の総数も取得する。図１４に示す登録規則管理テーブル２５０では規則の総数は「４」となる（Ｓ６０２）。

Ｓ６０３、Ｓ６０４では、前ステップで取得した登録規則に対して、Ｓ６０３〜Ｓ６０７までの処理を実行する。

規則監視機能２３１は、登録規則のロジックＩＤ１４２０に対応する加工済データの値を、加工済データ管理テーブル２４８より取得する。例えば、規則ＩＤ「Ｒ１」に対応する加工済データの値は、加工済データ管理テーブル２４８のロジックＩＤ１２２０が「Ｌ１」である値「６６」を取得する（Ｓ６０５）。

なお、この加工済みデータ管理テーブル２４８の値１２３０は一定の期間毎に、または常に最新の状態に更新されている。センサデバイスの状態や、ＲＦＩＤタグの移動などにより、重複度等の値１２３０は変化する。センサデバイスのセンサには指向性があるため、センサデバイスの方向が変化したような場合であっても、重複度等の値１２３０は変化することになる。

前ステップで取得した一定期間毎に、または常に最新の状態に更新されている加工済データに基づいて重複度を計算し、登録規則の値を比較して、規則が条件を満たしているかをチェックし、条件を満たしていればＳ６０３を実行し、条件を満たしていない場合は、Ｓ６０７で再抽出チェックカウンタを更新した後でＳ６０３を実行する（Ｓ６０６）。

例えば、規則ＩＤ１４１０が「Ｒ１」の値は「６１〜７１」であり、加工済データ管理テーブル２４８でロジックＩＤ「Ｌ１」に対応する値が「６６」であることから、この規則Ｒ１は条件を満たしているとしてＳ６０３に処理が進む。仮に、加工済データ管理テーブル２４８でデータＩＤ「Ｄ１」に対応する値が、センサデバイスの状態やＲＦＩＤタグの移動などにより変化し「５０」になっていたとすると、この規則は条件「６１〜７１」を満たしていないとしてＳ６０７に処理が進み、再抽出チェックカウンタの値を１増加する。

ここで、条件を満たしているかどうかの判定は、一度だけ行うのではなく、所定の間隔で複数回判定した結果を用いることや、所定の時間経過後に再判定してもよい。

ユーザ通知機能２３２は、規則を構成しているリーダにデバイスエラーが発生している可能性のあることをユーザに通知する。例えば、登録規則管理テーブル２５０の規則ＩＤ１４１０が「Ｒ１」である規則が不成立であった場合、ロジックＩＤ１４２０の値「Ｌ１」に対応するセンサデバイス「Ｓ１」「Ｓ２」を加工ロジック管理テーブル２４７より取得し、これらのセンサデバイスにデバイスエラーが発生した可能性があるとして、ユーザに通知する（Ｓ６１３）。

この際に、例えばＳ１が故障したことにより、デバイスエラーが発生し、個体識別情報を取得できなくなっていたとすると、デバイスエラーが発生した可能性があるデバイスは「Ｓ１」「Ｓ２」であるが、さらに、このＳ１，Ｓ２について、一次データ管理テーブル２４６の現在の状態を取得することで、Ｓ２は正常に情報取得しているが、Ｓ１は情報を取得できていないことを知ることができ、Ｓ１が故障していることが分かる。

監視を行っているＲＦＩＤタグやセンサデバイスの数が膨大な場合には、このように規則を満たさなくなったセンサデバイスグループを、まず絞り込んでやり、その後このセンサデバイスが情報を正常に取得できているかどうかを、一次データ管理テーブルの現在の情報取得状況を見ることで、故障などのデバイスレベルエラーが起こっているセンサデバイスを絞り込むことができる。

そして、この絞り込んだセンサデバイスをユーザに通知することで、どのセンサデバイスにエラーが発生しているかをユーザや管理者が知ることができる。

また、例えばデバイスの組合せリスト（Ｓ１、Ｓ２）（Ｓ１、Ｓ３）（Ｓ１、Ｓ４）（Ｓ２、Ｓ３）（Ｓ２、Ｓ４）（Ｓ３、Ｓ４）からなる規則Ｒ１，Ｒ２，Ｒ３，Ｒ４，Ｒ４，Ｒ５，Ｒ６が登録規則管理テーブル２５０により監視されていた場合に、センサデバイスＳ１の向きが大きく変わったとすると、センサデバイスＳ１が含まれるグループの規則Ｒ１，Ｒ２，Ｒ３についてのみ、登録規則管理テーブルの値１４３０の値を満たさなくなる。

これを監視している側から見ると、規則Ｒ１，Ｒ２，Ｒ３が突然、値を満たさなくなるのであり、この場合に、この規則Ｒ１，Ｒ２，Ｒ３に対応するセンサデバイスのグループ（Ｓ１、Ｓ２）（Ｓ１、Ｓ３）（Ｓ１、Ｓ４）を加工ロジック管理テーブルから取得し、このなかですべてに重複しているセンサデバイスＳ１を抽出することで、Ｓ１に何らかの障害、設置方向の変化、デバイスレベルエラーなどが発生していることを判別し、問題が発生したセンサデバイスを絞り込むことができる。そして、この絞り込んだセンサデバイスにエラーが発生していることを、ユーザや管理者に通知する。

再抽出チェックカウンタの処理Ｓ６０８では、再抽出チェックカウンタの値をチェックし、「０」よりも大きな値である場合はＳ６０８に処理を進め、値が「０」である場合は処理を終了する（Ｓ６０８）。

システム定義管理テーブル２４３を参照して、再構築条件７２５の値である「６０％以上が不成立」を取得する（Ｓ６０９）。

Ｓ６０２で取得した規則の総数と前ステップで取得した再構築条件７２５「６０％以上が不成立」とから、規則の再抽出が必要となる時の不成立規則数を求める。例えば、図１４の登録規則管理テーブルの例では、現在監視している規則の総数が「４」、再構築条件７２５の値が「６０％以上が不成立」であることから、規則の再抽出が必要となる時の不成立規則数は４×６０％を切り上げ「３」となる（Ｓ６１０）。つまり、現在監視している規則Ｒ１〜Ｒ４のうち３つ以上の規則が値１４３０を満たさなくなった場合に、図３の規則の再抽出が行われる。

上記で求めた不成立規則数と再抽出チェックカウンタとを比較し、再抽出チェックカウンタの値が大きい場合は、Ｓ６１１に処理を進める。再抽出チェックカウンタの値の方が小さい場合には、Ｓ６１３に処理を進める。

ユーザ通知機能２３２は、規則の再抽出が行われることをメールやシステムログを用いてユーザに通知する（Ｓ６１１）。

規則監視機能２３１は、Ｓ３１０、Ｓ３２０で前述した規則抽出処理を呼び出す（Ｓ６１２）。

複数の規則が一度に、値を満たさなくなり、再構築条件７２５の値を超えると、図３の規則の再抽出が行われる。

例えば、図１のような複数のＲＦＩＤタグが付いた商品を陳列するようなレイアウトについて、本実施例の構成を適用することを考える。数百点の商品のＲＦＩＤタグを例えば４つセンサデバイスで管理しているとすると、デバイスの組合せリスト（Ｓ１、Ｓ２）（Ｓ１、Ｓ３）（Ｓ１、Ｓ４）（Ｓ２、Ｓ３）（Ｓ２、Ｓ４）（Ｓ３、Ｓ４）からなる規則Ｒ１，Ｒ２，Ｒ３，Ｒ４，Ｒ４，Ｒ５，Ｒ６で数百点のＲＦＩＤタグの取得識別情報を監視している。

ここで規則Ｒ１のセンサ（Ｓ１、Ｓ２）で論理和として１００個のＲＦＩＤタグを監視しており、Ｓ１とＳ２で重複度が７０％だったと仮定すると、Ｓ１とＳ２で７０個の識別情報が重複して監視されている。このうちの５点の商品が売れて、その重複して監視している７０個の識別情報から５点のＲＦＩＤタグの識別情報が消えたとしても、現在監視している総数９５個のＲＦＩＤタグについて、６５個のＲＦＩＤタグが重複して監視されており、この場合の新たな重複度を計算すると６５個／９５個×１００＝６８．４となり、もとの７０％という重複度からほとんど変化していない。

このように、いくらかの商品が売れ、ＲＦＩＤの総数が変化していったとしても、登録規則管理テーブルで監視している値１４３０の範囲に収まっており、デバイスエラーとしては検知されない。一方前述のように、あるセンサデバイスがデバイスレベルエラーを起こしたとすると、この登録規則管理テーブルの値を満たさなくなり、エラーが通知される。

このように、数百点のＲＦＩＤタグを監視するような状況において、各センサのグループ間の重複度の変化を用いてデバイスレベルエラーを監視することで、数百点のＲＦＩＤタグ自体に若干の変化が生じても、そのＲＦＩＤタグの変化の影響をうけることなく、センサデバイスの状況変化のみを検知することができる。

さらに、図１のようなレイアウトがしばしば変更されるような状況で、数百点のＲＦＩＤタグを監視しているとする。この場合に、商品陳列のレイアウトが、大幅に変更されたとすると、規則Ｒ１〜Ｒ６のすべてについて、登録規則管理テーブル２５０の値１４３０を満たさなくなる。このように、システム定義管理テーブル２４３の再構築条件７２５の値以上の規則が、一度に値を満たさなくなった場合には、レイアウトの大幅変更などの要因が発生したことが分かり、図３の規則の再構築を行うことで、再度新しいレイアウトについて、登録規則の管理を行うことができるようになる。

ＲＦＩＤのような膨大な数の商品を管理し、それらの位置が大きく変化するような場合に、本実施例のようなセンサデバイスのグループを抽出して、グループとして管理を行ってやることによって、商品の移動や、変更、消滅などの状況に応じて、適宜新たにグルーピングをし直して、デバイスレベルエラーを検知することが可能となる。

毎朝商品のレイアウトを変更するようなアパレル業界や、市場などでは、管理者が監視するＲＦＩＤを自ら設定してやることなく、毎朝自動的にグルーピングが行われ、センサデバイスの監視を行うことができる。

センサデバイスに物理的な位置を特定する機能を設けておけば、デバイスレベルエラーの発生により通知されたセンサデバイスを特定して、保守員がそのセンサデバイスが設置されている場所に向かい修復を行うことができる。またセンサデバイスが数百個あるような場合には、そのうちの一部のセンサデバイスに位置を特定する機能を設けておけば、デバイスレベルエラーが生じたグループに含まれる位置を特定することが可能なセンサデバイスを通知することにより、保守員はそのセンサデバイスのある場所に行くことができる。

デバイスレベルエラーが起きているセンサデバイスは、位置を特定することの可能なセンサデバイスと同一のグループに属しているため、保守員が行った位置を特定することができるセンサデバイスの付近にあるセンサデバイスを検査することでエラーを起こしたデバイスを見つけることができる。このように一部のセンサデバイスにのみ位置を特定する機能を設ける場合には、すべてのセンサデバイスに対して位置を特定する機能を設けなくてすむため、コストが軽減される。

物理的な位置を特定することが可能なセンサデバイスを一部に使用する場合には、この位置を特定することが可能なセンサデバイスとの間で重複度が所定の値以上のセンサデバイスをグループ化することで、このセンサデバイスを中心にグルーピングを実施することも可能である。この場合には、管理者はこの位置を特定することが可能なセンサデバイスの位置を管理端末のＧＵＩに物理的なレイアウト図と共に表示しておけば、デバイスレベルエラーが起こって条件を満たさなくなったグループがどこにあるのかをＧＵＩ上で容易に確認することができる。

また、本実施例では、ユーザ通知機能における通知先をユーザとしているが、これはセンサデバイスの取替えを行う保守員、センサデバイスを遠隔監視する管理者であってもよい。さらに、ユーザ通知機能における通知方法を、本実施例ではメールやシステムログとしているが、これに加えて管理者などの使用するコンピュータ、携帯電話等の端末に対するＧＵＩによるアラート表示やポップアップ表示、またパトロールランプやブザーを用いてもよい。

ここで、本実施例では、規則の再抽出を実施する条件を、所定の割合を超えて規則が不成立となった場合としているが、この条件は、所定の数以上の規則が不成立となった場合、所定時間内に不成立となった規則の数が所定の数を超えた場合、所定以上の回数だけ所定の規則が不成立となった場合のいずれかとしてもよい。これらの基準となる所定の数、所定時間などは、システム管理テーブル２４３に記憶されている。

図１５に基づいて、前記第１実施例の変形例を説明する。第１実施例で述べた説明が適宜援用される。本実施例の特徴は、候補規則抽出処理において取得する一次データの生成方法にある。

第１の実施例では、規則の抽出に使用するデータは、あるタイミングでセンサデバイスが取得したデータを対象としている。周囲の環境変化によっては、あるタイミングでセンサデバイスがデータを取得する時、システムが正常な状態でない可能性がある。

図１５は、センサデバイスが取得するデータには、時間の揺らぎがあることを考慮した候補規則の抽出処理を表す。ここで、候補規則抽出機能２２１はＳ４０１Ａ、Ｓ１５０１、Ｓ１５０２、Ｓ４０２〜Ｓ４０６、Ｓ４０９〜Ｓ４１２を提供し、データ加工機能２１２はＳ４０７、Ｓ４０８を提供し、データ取得機能２１１はＳ１５０３、Ｓ１５０４を提供する。

候補規則抽出機能２２１は、システム定義管理テーブル２４３を参照し、前述した加工タイプ７２１および組合せデバイス数７２２、データの許容幅７２３に加えて、デバイス揺らぎ条件７２６を取得する（Ｓ４０１Ａ）。

デバイス揺らぎ条件７２６は、センサデバイスが正しくデータを取得するため条件であり、所定の時間であってもよいし、所定の回数であってもよい。本実施例では、センサデバイスは所定の時間をかければ正しくデータが取得できる場合を想定して記述する。例えば、センサデバイス２６０、２７０は、３分間の間には全ての個体識別情報を読み取れるものとした場合、デバイス揺らぎ条件７２６の値は「１８０秒で全データ取得」として定義する。

揺らぎカウンタを０で初期化する。揺らぎカウンタは、デバイス揺らぎ条件の現在値を表すカウンタであり、０以上の値をとる（Ｓ１５０１）。

揺らぎカウンタが所定のデバイス揺らぎ条件７２６を満たしているかどうかを判定する（Ｓ１５０２）。デバイス揺らぎ条件７２６を満たしている場合はＳ４０２を実行し、満たしていない場合はＳ１５０３〜Ｓ１５０４を実行する。例えば、デバイス揺らぎ条件７２６が「１８０秒で全データ取得」である場合は、データの取得を開始してから１８０秒経過するまでＳ１５０３〜Ｓ１５０４を実行する。

データ取得機能２１１は、システム中のセンサデバイスからデータを取得する（Ｓ１５０３）。

前ステップで取得したデータを一次データ管理テーブル２４６に登録する（Ｓ１５０４）。データの登録では、既存データに上書きしてもよいし、取得タイミング毎に分けて登録してもよい。

デバイス揺らぎ条件として、取得タイミングごとに登録する方法では図１６に示すようにセンサデバイスが取得する個体識別情報の揺らぎを考慮した加工済データが作成される。最小値１６４０には揺らぎ条件を満たすまでの間に取得した最小値を格納し、最大値１６５０には同様に取得した最大値を格納する。

最小値と最大値を持つ加工済データを利用し、最大値＋データの許容幅と最小値―データの許容幅を求めることで、図１７に示すように、デバイス揺らぎ条件を考慮した規則が作成できる。

Ｓ１５０５では、揺らぎカウンタを更新し、Ｓ１５０２の処理に戻る。

センサデバイス運用管理システムを表す図の例である。 本発明の実施形態の全体構成を示すブロック図の例である。 規則抽出処理を表すフローチャートの例である。 候補規則生成処理を表すフローチャートの例である。 候補規則フィルタリング処理を表すフローチャートの例である。 規則監視処理を表すフローチャートの例である。 システム定義管理テーブルのデータ構造の例である。 デバイス管理デーブルのデータ構造の例である。 加工タイプ管理テーブルのデータ構造の例である。 一次データ管理テーブルのデータ構造の例である。 加工ロジック管理テーブルのデータ構造の例である。 加工済データ管理テーブルのデータ構造の例である。 候補規則管理テーブルのデータ構造の例である。 登録規則管理テーブルのデータ構造の例である。 デバイス揺らぎ条件を考慮した規則抽出処理を表すフローチャートの例である。 デバイス揺らぎ条件を考慮した加工済データ管理テーブルのデータ構造の例である。 デバイス揺らぎ条件を考慮した登録規則管理テーブルのデータ構造の例である。

符号の説明

２００ 運用管理サーバ
２０１ メモリ
２０２ プロセッサ
２０３ ディスクインタフェース
２０４ 通信インタフェース
２０５ サーバプログラム
２０６ ネットワーク
２４０ 記憶部
２６０、２７０ センサデバイス
２８１、２８２、２８３ 個体識別装置

Claims (10)

1. 個体識別装置から個体識別情報を取得する複数のセンサデバイスを管理するセンサデバ
   イス管理装置であって、
   前記複数のセンサデバイスから前記個体識別情報を取得するデータ取得部と、
   前記センサデバイスと、前記センサデバイスの取得した前記個体識別情報とを対応付け
   た一次情報を記憶する記憶部と、
   前記一次情報の前記複数のセンサデバイスが取得した識別情報に基づいて、所定の条件を満たすセンサデバイスをグループとして抽出する抽出部と、
   抽出した前記グループに属するセンサデバイス間で、前記所定の条件を満たしているか
   どうかを監視する監視部とを有し、
   前記所定の条件は、前記一次情報の、複数の前記センサデバイスに対応付けられた複数の前記個体識別情報の重複度が所定の割合以上であることを特徴とするセンサデバイス管理装置。
2. 請求項１に記載のセンサデバイス管理装置であって、
   前記重複度は、複数の前記センサデバイスのそれぞれに対応付けられた個体識別情報の
   和集合に対する、該複数の前記センサデバイスのそれぞれに対応付けられた個体識別情報
   の積集合の割合であることを特徴とするセンサデバイス管理装置。
3. 請求項１乃至２のいずれか１に記載のセンサデバイス管理装置であって、
   前記グループは複数あり、
   前記監視部は、前記複数のグループの数に対する、前記所定の条件を満たしていないグ
   ループの数の割合が所定の割合以上であるかどうかを判定し、
   所定の割合以上であると判定された場合に、前記抽出部が前記複数のセンサデバイス間
   で所定の条件を満たすセンサデバイスをグループとして抽出しなおすことを特徴とするセンサデバイス管理装置。
4. 請求項１乃至３のいずれか１に記載のセンサデバイス管理装置であって、
   前記データ取得部は、所定の期間の間、前記複数のセンサデバイスから前記個体識別情
   報を複数回取得し、
   前記記憶部は、前記複数回の取得により、前記センサデバイスと、前記センサデバイス
   の取得した個体識別情報とを対応付けた前記一次情報を、複数記憶し、
   前記抽出部は、複数の前記一次情報に基づいて、前記複数のセンサデバイス間で所定の
   条件を満たすセンサデバイスをグループとして抽出する
   ことを特徴とするセンサデバイス管理装置。
5. 請求項４に記載のセンサデバイス管理装置であって、
   複数の前記一次情報に基づいて、前記複数のセンサデバイス間で所定の条件を満たすセ
   ンサデバイスをグループとして抽出する処理は、
   複数の前記一次情報の平均値に基づいて、前記複数のセンサデバイス間で所定の条件を
   満たすセンサデバイスをグループとして抽出する処理である
   ことを特徴とするセンサデバイス管理装置。
6. 個体識別装置から個体識別情報を取得する複数のセンサデバイスを管理するセンサデバ
   イス管理方法であって、
   前記センサデバイスと、前記センサデバイスの取得した前記個体識別情報とを対応付け
   た一次情報を生成し、
   前記一次情報の前記複数のセンサデバイスが取得した識別情報に基づいて、所定の条件
   を満たすセンサデバイスをグループとして抽出し、
   抽出した前記グループに属するセンサデバイス間で、前記所定の条件を満たしているか
   どうかを監視し、
   前記所定の条件は、前記一次情報の、複数の前記センサデバイスに対応付けられた複数の前記個体識別情報の重複度が所定の割合以上である
   ことを特徴とするセンサデバイス管理方法。
7. 請求項６に記載のセンサデバイス管理方法であって、
   前記重複度は、複数の前記センサデバイスのそれぞれに対応付けられた個体識別情報の
   和集合に対する、該複数の前記センサデバイスのそれぞれに対応付けられた個体識別情報
   の積集合の割合であることを特徴とするセンサデバイス管理方法。
8. 請求項６乃至７のいずれか１に記載のセンサデバイス管理方法であって、
   前記グループは複数あり、
   前記監視部は、前記複数のグループの数に対する、前記所定の条件を満たしていないグ
   ループの数の割合が所定の割合以上であるかどうかを判定し、
   所定の割合以上であると判定された場合に、前記抽出部が前記複数のセンサデバイス間
   で所定の条件を満たすセンサデバイスをグループとして抽出しなおす
   ことを特徴とするセンサデバイス管理方法。
9. 請求項６乃至８のいずれか１に記載のセンサデバイス管理方法であって、
   前記一次情報の生成は、所定の期間の間、前記複数のセンサデバイスから複数回取得さ
   れた前記個体識別情報に基づき、前記センサデバイスと前記センサデバイスの取得した個
   体識別情報とを対応付けた一次情報を、複数生成するものであり、
   複数の前記一次情報に基づいて、前記複数のセンサデバイス間で所定の条件を満たすセ
   ンサデバイスをグループとして抽出する
   ことを特徴とするセンサデバイス管理方法。
10. 請求項９に記載のセンサデバイス管理方法であって、
    複数の前記一次情報に基づいて、前記複数のセンサデバイス間で所定の条件を満たすセ
    ンサデバイスをグループとして抽出する処理は、
    複数の前記一次情報の平均値に基づいて、前記複数のセンサデバイス間で所定の条件を
    満たすセンサデバイスをグループとして抽出する処理である
    ことを特徴とするセンサデバイス管理方法。

Images