(57)【特許請求の範囲】
【請求項１】
リーダＩＤにより特定されるリーダがタグから読み取ったタグＩＤを通知するタグ通知方法であって、
コンピュータが、
状態遷移データとその状態遷移データの状態のうちの現在の状態を示す現状態とを、タグＩＤごとに対応づけて記憶手段に記憶し、
前記状態遷移データは、状態遷移を構成する状態ごとにその状態において読み取り可能なリーダの前記リーダＩＤと、その読み取り可能なリーダがタグＩＤを読み取ったときに次に遷移する先の次状態と、を対応づけるデータであり、
リーダがタグを読み取ると、当該タグのタグＩＤおよび当該リーダのリーダＩＤを入力するタグ入力手順と、
前記タグ入力手順で入力されたタグＩＤから、そのタグＩＤに対応する前記状態遷移データと前記現状態とを前記記憶手段から読み取り、前記読み取った現状態を検索キーとして前記読み取った状態遷移データから状態遷移を構成する状態を検索し、検索された前記状態に対応する前記リーダＩＤを取得し、前記タグ入力手順で入力されたリーダＩＤと前記取得したリーダＩＤとが一致すれば、現状態を前記状態遷移データが示す前記次状態へと遷移させるとともに、前記タグ入力手順で読み取ったタグＩＤを正常陳列データとして通知することを許可する正常陳列判定手順と、
前記タグ入力手順で読み取ったタグＩＤのうちの前記正常陳列判定手順により通知を許可されなかったタグＩＤについて、前記リーダがタグから前記タグＩＤを読み取る回数が指定回数以上のときに、前記タグ入力手順で読み取ったタグＩＤを誤陳列データとして通知することを許可する誤陳列判定手順と、
前記正常陳列判定手順または前記誤陳列判定手順により通知を許可されたタグＩＤを通知するイベント通知手順と、
を実行することを特徴とするタグ通知方法。
【請求項２】
前記誤陳列判定手順では、前記コンピュータが、リーダＩＤごとに設定された前記指定回数を前記記憶手段から読み取ることを特徴とする請求項１に記載のタグ通知方法。
【請求項３】
前記誤陳列判定手順では、前記コンピュータが、リーダＩＤおよびタグＩＤの組ごとに設定された前記指定回数を前記記憶手段から読み取ることを特徴とする請求項１に記載のタグ通知方法。
【請求項４】
前記誤陳列判定手順では、前記コンピュータが、リーダＩＤおよびタグＩＤの組、ならびに、前記現状態ごとに設定された前記指定回数を前記記憶手段から読み取ることを特徴とする請求項１に記載のタグ通知方法。
【請求項５】
リーダＩＤにより特定されるリーダがタグから読み取ったタグＩＤを通知するタグ通知方法であって、
コンピュータが、
状態遷移データとその状態遷移データの状態のうちの現在の状態を示す現状態とを、タグＩＤごとに対応づけて記憶手段に記憶し、
前記状態遷移データは、状態遷移を構成する状態ごとにその状態において読み取り可能なリーダの前記リーダＩＤと、その読み取り可能なリーダがタグＩＤを読み取ったときに次に遷移する先の次状態と、を対応づけるデータであり、
リーダがタグを読み取ると、当該タグのタグＩＤおよび当該リーダのリーダＩＤを入力するタグ入力手順と、
前記タグ入力手順で入力されたタグＩＤから、そのタグＩＤに対応する前記状態遷移データと前記現状態とを前記記憶手段から読み取り、前記読み取った現状態を検索キーとして前記読み取った状態遷移データから状態遷移を構成する状態を検索し、検索された前記状態に対応する前記リーダＩＤを取得し、前記タグ入力手順で入力されたリーダＩＤと前記取得したリーダＩＤとが一致すれば、現状態を前記状態遷移データが示す前記次状態へと遷移させるとともに、前記タグ入力手順で読み取ったタグＩＤを正常陳列データとして通知することを許可する正常陳列判定手順と、
前記タグ入力手順で読み取ったタグＩＤのうちの前記正常陳列判定手順により通知を許可されなかったタグＩＤについて、前記リーダがタグから前記タグＩＤを読み取る時間が指定時間以上のときに、前記タグ入力手順で読み取ったタグＩＤを誤陳列データとして通知することを許可する誤陳列判定手順と、
前記正常陳列判定手順または前記誤陳列判定手順により通知を許可されたタグＩＤを通知するイベント通知手順と、
を実行することを特徴とするタグ通知方法。
【請求項６】
前記誤陳列判定手順では、前記コンピュータが、リーダＩＤごとに設定された前記指定時間を前記記憶手段から読み取ることを特徴とする請求項５に記載のタグ通知方法。
【請求項７】
前記誤陳列判定手順では、前記コンピュータが、リーダＩＤおよびタグＩＤの組ごとに設定された前記指定時間を前記記憶手段から読み取ることを特徴とする請求項５に記載のタグ通知方法。
【請求項８】
前記誤陳列判定手順では、前記コンピュータが、リーダＩＤおよびタグＩＤの組、ならびに、前記現状態ごとに設定された前記指定時間を前記記憶手段から読み取ることを特徴とする請求項５に記載のタグ通知方法。
【請求項９】
請求項１ないし請求項８のいずれか１項に記載のタグ通知方法を、前記コンピュータに実行させるためのタグ通知プログラム。
【請求項１０】
リーダＩＤにより特定されるリーダがタグから読み取ったタグＩＤを通知するタグ通知装置であって、
前記タグ通知装置が、
状態遷移データとその状態遷移データの状態のうちの現在の状態を示す現状態とを、タグＩＤごとに対応づけて記憶手段に記憶し、
前記状態遷移データは、状態遷移を構成する状態ごとにその状態において読み取り可能なリーダの前記リーダＩＤと、その読み取り可能なリーダがタグＩＤを読み取ったときに次に遷移する先の次状態と、を対応づけるデータであり、
リーダがタグを読み取ると、当該タグのタグＩＤおよび当該リーダのリーダＩＤを入力するタグ入力手順と、
前記タグ入力手順で入力されたタグＩＤから、そのタグＩＤに対応する前記状態遷移データと前記現状態とを前記記憶手段から読み取り、前記読み取った現状態を検索キーとして前記読み取った状態遷移データから状態遷移を構成する状態を検索し、検索された前記状態に対応する前記リーダＩＤを取得し、前記タグ入力手順で入力されたリーダＩＤと前記取得したリーダＩＤとが一致すれば、現状態を前記状態遷移データが示す前記次状態へと遷移させるとともに、前記タグ入力手順で読み取ったタグＩＤを正常陳列データとして通知することを許可する正常陳列判定手順と、
前記タグ入力手順で読み取ったタグＩＤのうちの前記正常陳列判定手順により通知を許可されなかったタグＩＤについて、前記リーダがタグから前記タグＩＤを読み取る回数が指定回数以上のときに、前記タグ入力手順で読み取ったタグＩＤを誤陳列データとして通知することを許可する誤陳列判定手順と、
前記正常陳列判定手順または前記誤陳列判定手順により通知を許可されたタグＩＤを通知するイベント通知手順と、
を実行することを特徴とするタグ通知装置。
【請求項１１】
リーダＩＤにより特定されるリーダがタグから読み取ったタグＩＤを通知するタグ通知装置であって、
前記タグ通知装置が、
状態遷移データとその状態遷移データの状態のうちの現在の状態を示す現状態とを、タグＩＤごとに対応づけて記憶手段に記憶し、
前記状態遷移データは、状態遷移を構成する状態ごとにその状態において読み取り可能なリーダの前記リーダＩＤと、その読み取り可能なリーダがタグＩＤを読み取ったときに次に遷移する先の次状態と、を対応づけるデータであり、
リーダがタグを読み取ると、当該タグのタグＩＤおよび当該リーダのリーダＩＤを入力するタグ入力手順と、
前記タグ入力手順で入力されたタグＩＤから、そのタグＩＤに対応する前記状態遷移データと前記現状態とを前記記憶手段から読み取り、前記読み取った現状態を検索キーとして前記読み取った状態遷移データから状態遷移を構成する状態を検索し、検索された前記状態に対応する前記リーダＩＤを取得し、前記タグ入力手順で入力されたリーダＩＤと前記取得したリーダＩＤとが一致すれば、現状態を前記状態遷移データが示す前記次状態へと遷移させるとともに、前記タグ入力手順で読み取ったタグＩＤを正常陳列データとして通知することを許可する正常陳列判定手順と、
前記タグ入力手順で読み取ったタグＩＤのうちの前記正常陳列判定手順により通知を許可されなかったタグＩＤについて、前記リーダがタグから前記タグＩＤを読み取る時間が指定時間以上のときに、前記タグ入力手順で読み取ったタグＩＤを誤陳列データとして通知することを許可する誤陳列判定手順と、
前記正常陳列判定手順または前記誤陳列判定手順により通知を許可されたタグＩＤを通知するイベント通知手順と、
を実行することを特徴とするタグ通知装置。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、タグ通知方法、タグ通知プログラム、および、タグ通知装置に関する。
【背景技術】
【０００２】
近年、製造、流通、サービスなどの分野で、ＲＦＩＤ（Radio Frequency Identification）タグを活用したアプリケーションの実証実験や実用化が先行して既に始まっており、普及に向けた準備が進みつつある。最近の事例では、アパレル産業などの製販一体型の業態や、自動車や家電などの単価が高い分野のほかに、比較的商品単価の安いスーパーマーケット店舗での個品管理まで実証実験が行われてきている。
【０００３】
タグの応用技術として、例えば、次のようなものが挙げられる。特許文献１は、無線ＩＤタグを移動体に付して、施設内を移動する移動体の正確な動線情報を生成する技術を開示する。特許文献２は、非接触ＩＣタグをソフト製品に付して、リース店、レンタルショップにおけるソフト製品の流通管理を正確かつ簡単にする技術を開示する。特許文献３は、ＩＣタグに個人情報を格納し、その個人情報に含まれる認証用のコードが盗用されることを防ぐために、通信の安全性を高める技術を開示する。
【０００４】
特許文献１は、買物カゴや買物カートにＲＦＩＤタグを付し、店舗内にＲＦＩＤリーダを張り巡らせ、ＲＦＩＤリーダがＲＦＩＤタグを読み取ると、ＲＦＩＤリーダの識別情報、ＲＦＩＤタグの識別情報、そのときの時刻を関連付けた情報をＤＢに送信、蓄積させる。そして、蓄積された情報をもとに、買物カゴや買物カートの動線情報、ひいては買物カゴや買物カートを使って買物をしている人の動線情報を表示するシステムが提案されている。しかし、買物カゴや買物カートにＲＦＩＤタグを付すことにより、人の動線情報を把握することは、プライバシー問題の懸念がある場合がある。
【０００５】
また、ＲＦＩＤタグを商品に付した応用例として、スマートシェルフが挙げられる。スマートシェルフは、万引き防止や在庫管理、流通過程で発生する紛失の責任者の明確化などを目的に、シェーバと関連商品にＲＦＩＤタグを貼り付け、商品棚にＲＦＩＤリーダを搭載したものである。スマートシェルフを店舗に設置し、ＲＦＩＤタグの情報を読み取らせる事例も報告されている。
【特許文献１】特開２００５−７１２５２号公報
【特許文献２】特開２００２−７４５０１号公報
【特許文献３】特開２００３−３１７０４４号公報
【発明の開示】
【発明が解決しようとする課題】
【０００６】
しかし、従来のスマートシェルフは、商品が所定のスマートシェルフの近傍を移動中にもかかわらず、所定のスマートシェルフの上に商品が陳列されたと誤検出することがあった。つまり、商品の移動中に、その商品の陳列されるべきスマートシェルフとは別のスマートシェルフに設置されたタグリーダが、移動中の商品のＲＦＩＤタグから商品情報を読み取ることにより、別のスマートシェルフにその商品が陳列されていると誤認識してしまう。その結果、誤認識に基づく誤ったイベント通知が、商品を管理するシステムへと送信されてしまい、業務に支障をきたす可能性がある。
【０００７】
なお、商品の移動中とは、例えば、多数の商品にＲＦＩＤタグを貼り付け、多数のスマートシェルフを店頭に設置するスーパーマーケットシステムを考えると、ＲＦＩＤタグが貼り付けられた商品を倉庫から店頭の陳列されるべきスマートシェルフに品出しするとき、その逆に店頭の陳列されるべきスマートシェルフから倉庫に品戻しするとき、または、消費者がＲＦＩＤタグ付きの商品を購入するために買物カゴに入れるなどして持ち歩くときなどが挙げられる。
【０００８】
そこで、本発明は、商品に付されたＲＦＩＤタグの読み取りに関して、誤検出を抑制することを主な目的とする。
【課題を解決するための手段】
【０００９】
本発明は、リーダＩＤにより特定されるリーダがタグから読み取ったタグＩＤを通知するタグ通知方法であって、
コンピュータが、
状態遷移データとその状態遷移データの状態のうちの現在の状態を示す現状態とを、タグＩＤごとに対応づけて記憶手段に記憶し、
前記状態遷移データは、状態遷移を構成する状態ごとにその状態において読み取り可能なリーダの前記リーダＩＤと、その読み取り可能なリーダがタグＩＤを読み取ったときに次に遷移する先の次状態と、を対応づけるデータであり、
リーダがタグを読み取ると、当該タグのタグＩＤおよび当該リーダのリーダＩＤを入力するタグ入力手順と、
前記タグ入力手順で入力されたタグＩＤから、そのタグＩＤに対応する前記状態遷移データと前記現状態とを前記記憶手段から読み取り、前記読み取った現状態を検索キーとして前記読み取った状態遷移データから状態遷移を構成する状態を検索し、検索された前記状態に対応する前記リーダＩＤを取得し、前記タグ入力手順で入力されたリーダＩＤと前記取得したリーダＩＤとが一致すれば、現状態を前記状態遷移データが示す前記次状態へと遷移させるとともに、前記タグ入力手順で読み取ったタグＩＤを正常陳列データとして通知することを許可する正常陳列判定手順と、
前記タグ入力手順で読み取ったタグＩＤのうちの前記正常陳列判定手順により通知を許可されなかったタグＩＤについて、前記リーダがタグから前記タグＩＤを読み取る回数が指定回数以上のときに、前記タグ入力手順で読み取ったタグＩＤを誤陳列データとして通知することを許可する誤陳列判定手順と、
前記正常陳列判定手順または前記誤陳列判定手順により通知を許可されたタグＩＤを通知するイベント通知手順と、
を実行することを特徴とする。
その他の手段は、後記する。
【発明の効果】
【００１０】
本発明によれば、読み取られたタグＩＤについて、指定スケジュールと照合することにより、商品に付されたＲＦＩＤタグの読み取りに関して、誤検出を抑制することができる。
【発明を実施するための最良の形態】
【００１１】
以下、図面を参照しつつ、本発明を実施するための最良の形態について説明する。
【００１２】
図１は、本発明を実施するための最良の形態に係るシステムの全体構成図である。システムは、読み取りリーダスケジュール装置１００と、読み取りリーダスケジュール装置１００に１つ以上つながるリーダ制御装置２００と、リーダ制御装置２００に１つ以上つながるリーダ３００と、リーダ３００が読み取る１つ以上のタグ４００と、から構成される。
【００１３】
店員は、倉庫にある商品を取り出し、店内を移動し、売り場の棚の上に商品を設置する。商品には、タグＩＤ４０１により特定されるタグ４００が付されている。売り場の棚は、リーダＩＤ３０１により特定されるリーダ３００が付されている。リーダ３００は、近傍または接触するタグ４００と通信を行うことにより、タグＩＤ４０１を読み取る。リーダ制御装置２００は、管理サーバ（図示省略）からの要求に応じて、リーダ３００が読み取ったタグＩＤ４０１を管理サーバに通知する。これにより、管理サーバは、売り場の棚に商品が陳列された旨を、管理者に知らせることができる。
【００１４】
まず、比較例の形態では、リーダ制御装置２００は、リーダ３００が通信可能なタグ４００を発見すると、無条件に全てのタグＩＤ４０１を取得して、管理サーバに通知していた。その方式では、商品が所定のスマートシェルフの近傍を移動中にもかかわらず、所定のスマートシェルフの上に商品が陳列されたと誤検出することがあった。
【００１５】
そこで、本実施形態は、リーダ３００が取得した全てのタグＩＤ４０１のうち、管理サーバに通知するタグＩＤ４０１を選択するために、２つの条件を設定することを特徴とする。１つめの条件は、商品の流通業務をもとに設定された指定スケジュールである。２つめの条件は、商品の配置期間をもとに設定された指定条件である。リーダ制御装置２００は、１つめの条件を満たすタグＩＤ４０１を、管理サーバに通知してもよい。または、リーダ制御装置２００は、１つめの条件を満たさず、２つめの条件を満たすタグＩＤ４０１について、管理サーバに通知してもよい。
【００１６】
管理サーバに通知するタグＩＤ４０１を選択するための２つの条件について、条件を満たすか否かの判定は、リーダ制御装置２００ではなく、読み取りリーダスケジュール装置１００が代行する。なお、リーダ制御装置２００は、読み取りリーダスケジュール装置１００を内包した、タグ通知装置として構成してもよい。
【００１７】
１つめの条件の概要を説明する。読み取りリーダスケジュール装置１００は、読み取りリーダスケジュールＤＢ１１１に格納された指定スケジュールをもとに、タグＩＤ４０１を通知するためのイベントを発生させるか否かを判定する。指定スケジュールは、タグ４００の読み取りに関する状態および状態間の遷移を規定した状態遷移表（詳細は図２参照）である。
【００１８】
２つめの条件の概要を説明する。読み取りリーダスケジュール装置１００は、強制読み取りイベント生成条件ＤＢ１１２（詳細は図３参照）に格納された指定条件をもとに、タグＩＤを通知するためのイベントを発生させるか否かを判定する。
【００１９】
タグ４００は、例えばＲＦＩＤタグやＩＣカード、バーコードなど、少なくともそのタグ４００のＩＤであるタグＩＤ４０１を含む媒体である。リーダ３００は、タグ４００のタグＩＤ４０１を同時に１つ以上読み取る装置であり、少なくともそのリーダ３００のＩＤであるリーダＩＤ３０１を含む。
【００２０】
リーダ制御装置２００は、１つ以上のリーダ３００を制御する装置であり、少なくともＣＰＵ（Central Processing Unit）２０１と、メモリ２０２と、記憶装置２０３と、通信インタフェース２０４と、１つ以上のリーダインタフェース２０５と、時計２０６と、から構成される。リーダインタフェース２０５は、リーダ３００のインタフェース方式に対応したインタフェースであり、リーダ３００と通信する。
【００２１】
通信インタフェース２０４は、例えば有線ＬＡＮ（Local Area Network）カードや無線ＬＡＮカードなどといったインタフェースであり、少なくとも読み取りリーダスケジュール装置１００と通信する。記憶装置２０３は、例えばハードディスクドライブやフラッシュメモリなど、プログラムやデータを記憶する装置であり、プログラムとして少なくともタグ読み取りイベント生成プログラム２１０を含む。
【００２２】
タグ読み取りイベント生成プログラム２１０は、１つ以上のリーダ３００から、リーダ３００のそれぞれが１つ以上のタグＩＤ４０１を読み取って、タグＩＤ４０１のそれぞれとそのリーダ３００のリーダＩＤ３０１とを関連付けた１つ以上のタグＩＤ４０１−リーダＩＤ３０１のペアを受信する。
【００２３】
そして、タグ読み取りイベント生成プログラム２１０は、タグＩＤ４０１−リーダＩＤ３０１のペアのそれぞれについて、そのタグＩＤ４０１のタグ４００がそのときにそのリーダＩＤ３０１のリーダ３００に読み取られるスケジュール通りであったかスケジュール管理プログラム１１０に問い合わせる。スケジュール通りであればスケジュール通りの読み取りとしてイベントを生成する。一方、スケジュール通りでなく、スケジュール管理プログラム１１０が指定した時間、読み取られ続ければ強制読み取りとしてイベントを生成する。
【００２４】
タグ読み取りイベント生成プログラム２１０は、ＣＰＵ２０１に実行されることにより、リーダ３００がタグ４００を読み取ると、当該タグのタグＩＤ４０１および当該リーダ３００のリーダＩＤ３０１を入力するタグ入力部と、タグ入力部に入力されたタグＩＤに関する指定スケジュールの現状態からの遷移が、タグ入力部に入力されたリーダＩＤ３０１と一致すれば、現状態を遷移させるとともにタグＩＤ４０１の通知を許可するイベント判定部と、イベント判定部により許可されたタグＩＤ４０１を通知するイベント通知部と、を実現する。
【００２５】
また、イベント通知部が、タグ入力手順で入力されたタグＩＤ４０１に関する指定スケジュールの現状態からの遷移が、タグ入力部に入力されたリーダＩＤ３０１と一致しないタグＩＤ４０１について、指定条件に合致すれば、タグＩＤ４０１の通知を許可する。
【００２６】
タグ読み取りイベント生成プログラム２１０は、メモリ２０２に読み込まれ、ＣＰＵ２０１に実行されることにより、それぞれの処理が実行される。なお、タグ読み取りイベント生成プログラム２１０は、実行時にメモリ２０２にデータとして少なくともタグ読み取りバッファ２１１を生成する。
【００２７】
タグ読み取りバッファ２１１は、タグ読み取りイベント生成プログラム２１０が受信したタグＩＤ４０１−リーダＩＤ３０１のペアのうち、タグＩＤ４０１のタグ４００がそのときにリーダＩＤ３０１のリーダ３００に読み取られるスケジュール通りでないものを、その読み取りが開始された時刻と、その読み取りが指定時間続行するときには、強制読み取りとしてイベントを生成する指定時間と、を関連付けてその読み取りが続行する限り、指定時間が過ぎるまでバッファリングするためのデータである（詳細は、図４参照）。
【００２８】
次に、読み取りリーダスケジュール装置１００は、ＰＣなどの装置であり、少なくともＣＰＵ１０１と、メモリ１０２と、記憶装置１０３と、通信インタフェース１０４と、から構成される。通信インタフェース１０４は、例えば有線ＬＡＮカードや無線ＬＡＮカードなどといったインタフェースであり、１つ以上のリーダ制御装置２００と通信する。
【００２９】
記憶装置１０３は、例えばハードディスクやフラッシュメモリなど、プログラムやデータを記憶する装置であり、プログラムとして少なくともスケジュール管理プログラム１１０を含み、データとして少なくとも読み取りリーダスケジュールＤＢ１１１と、強制読み取りイベント生成条件ＤＢ１１２と、を含む。スケジュール管理プログラム１１０は、記憶装置１０３からメモリ１０２に読み込まれ、ＣＰＵ１０１に実行されることにより、それぞれの処理が実行される。
【００３０】
スケジュール管理プログラム１１０は、タグ読み取りイベント生成プログラム２１０から、１つ以上のタグＩＤ−リーダＩＤのペアを含む読み取りリーダスケジュール確認要求を受信し、タグＩＤ−リーダＩＤのペアのそれぞれについて、読み取りリーダスケジュールＤＢ１１１の内容に従って、そのタグＩＤのタグ４００がそのときにそのリーダＩＤのリーダ３００に読み取られるスケジュール通りであったか確認する。
【００３１】
そして、スケジュール管理プログラム１１０は、スケジュール通りであればそのタグＩＤのタグ４００が次にどのリーダＩＤのリーダ３００に読み取られるかの状態を遷移させ、スケジュール通りの読み取りだとタグ読み取りイベント生成プログラム２１０に応答する。一方、スケジュール通りの読み取りでなければ強制読み取りイベント生成条件ＤＢ１１２の内容に従って、そのタグＩＤのタグ４００がそのリーダＩＤのリーダ３００に指定時間、読み取られ続けていれば強制読み取りとしてイベントを生成する指定時間をタグ読み取りイベント生成プログラム２１０に応答する。
【００３２】
読み取りリーダスケジュールＤＢ１１１は、それぞれのタグＩＤのタグ４００について、どのリーダＩＤのリーダ３００に読み取られていくかのスケジュールを管理し、スケジュール通りに読み取られればそのタグＩＤのタグ４００が次にどのリーダＩＤのリーダ３００に読み取られるかの状態を遷移させるためのデータである（詳細は、図２参照）。なお、読み取りリーダスケジュールＤＢ１１１は、事前にそのシステムの運用管理者などによって、読み取りリーダスケジュール装置１００の図示しない入力装置に入力されるなどにより設定される。
【００３３】
強制読み取りイベント生成条件ＤＢ１１２は、それぞれのリーダＩＤのリーダ３００について、スケジュール通りの読み取りでないどのタグＩＤのタグ４００であっても、指定時間、読み取り続けていれば強制読み取りとしてイベントを生成する指定時間を管理するためのデータである（詳細は、図３参照）。なお、強制読み取りイベント生成条件ＤＢ１１２は、事前にそのシステムの運用管理者などによって、読み取りリーダスケジュール装置１００に図示しない入力装置に入力されるなどにより設定される。
【００３４】
図２は、読み取りリーダスケジュールＤＢ１１１の構成図であり、レコードのフィールドとして少なくともタグＩＤ１１１ａと、読み取りリーダ状態遷移表１１１ｂと、現状態１１１ｃと、を含む。タグＩＤ１１１ａは、そのシステムに含まれるタグ４００のタグＩＤ４０１のすべて（Ｔ５６，Ｔ５７，Ｔ７８，．．．）が、列挙されている。
【００３５】
読み取りリーダ状態遷移表１１１ｂは、そのレコードのタグＩＤ１１１ａに示すタグ４００について、どのリーダＩＤのリーダ３００に読み取られていくかのスケジュールを管理するフィールドである。初めの状態である状態０において読み取りを許可するリーダ３００のリーダＩＤを読み取り許可リーダＩＤ１１１ｂ０ａに列挙し、読み取り許可リーダＩＤ１１１ｂ０ａに列挙されたリーダＩＤのそれぞれについて、状態０においてそのリーダＩＤのリーダ３００に読み取られれば遷移させる次の状態を次状態１１１ｂ０ｂに指定する。
【００３６】
読み取りリーダ状態遷移表１１１ｂにおいて、状態１以降においても、状態０においてと同様に読み取り許可リーダＩＤ１１１ｂ１ａと、次状態１１１ｂ１ｂと、を設定する。なお、読み取り許可リーダＩＤに任意のリーダ３００を示す「ａｎｙ」を設定すれば、その状態においてどのリーダＩＤのリーダ３００の読み取りであっても許可し、読み取り許可リーダＩＤに何も設定しなければ、その状態においてどのリーダＩＤのリーダ３００の読み取りであっても許可しない。
【００３７】
現状態１１１ｃには、そのレコードのタグＩＤ１１１ａに示すタグ４００について、読み取りリーダ状態遷移表１１１ｂの内容に従って遷移しているそのときの状態を記憶させる。例えば、タグＩＤ「Ｔ５７」において、現状態１１１ｃが「状態０」であり、次状態１１１ｂ０ｂの「状態１」に遷移するためには、読み取り許可リーダＩＤ１１１ｂ０ａに示される「Ｒ０１」または「Ｒ０２」のリーダにタグが読み取られる必要がある。
【００３８】
指定スケジュールを活用することにより、店員が商品を移動中に通りかかった棚について、その棚のリーダ３００が商品のタグＩＤ４０１を読み取っても、指定スケジュールの状態遷移に登録されていないので、タグＩＤ４０１は通知されない。これにより、店の管理者は、移動中の商品ではなく、陳列された商品の位置を把握することができる。
【００３９】
図３は、強制読み取りイベント生成条件ＤＢ１１２の構成図であり、レコードのフィールドとして少なくともリーダＩＤ１１２ａと、強制読み取りイベント生成時間１１２ｂと、を含む。リーダＩＤ１１２ａには、そのシステムに含まれるリーダ３００のリーダＩＤ３０１のすべてを列挙する。
【００４０】
強制読み取りイベント生成時間１１２ｂには、そのレコードのリーダＩＤ１１２ａに示すリーダ３００について、スケジュール通りの読み取りでないどのタグＩＤのタグ４００であっても、その強制読み取りイベント生成時間１１２ｂの間、読み取り続けていれば強制読み取りとしてイベントを生成する時間を指定する。
【００４１】
なお、強制読み取りイベント生成時間１１２ｂに０秒を設定すれば、そのレコードのリーダＩＤ１１２ａに示すリーダ３００が、スケジュール通りの読み取りでないどのタグＩＤのタグ４００を読み取っても、待たずにそのまま強制読み取りとしてイベントを生成する。また、強制読み取りイベント生成時間１１２ｂに∞を設定すれば、そのレコードのリーダＩＤ１１２ａに示すリーダ３００が、スケジュール通りの読み取りでないどのタグＩＤのタグ４００を読み取っても、イベントを生成しない。
【００４２】
このように、強制読み取りイベント生成条件ＤＢ１１２に記述された指定条件は、商品が所定の場所に配置された期間をもとに、あらかじめ用意したしきい値との比較によって、配置された商品のタグＩＤを通知するか否かを判定するために使用される。なお、図３では、指定条件がリーダＩＤごとに設定されていたが、リーダＩＤおよびタグＩＤの組ごとに、あるいは、リーダＩＤおよびタグＩＤの組、ならびに、指定スケジュールの現状態ごとに設定されていてもよい。また、強制読み取りイベント生成時間１１２ｂの代わりに、指定回数を設定してもよい。
【００４３】
指定条件を活用することにより、客が誤って商品を別の棚に移動させてしまったときなど、その商品の陳列されるべきものとは別の商品棚に陳列されている状態（誤陳列の状態）を、イベントとして通知することにより、店の管理者は、各商品の正確な現在位置を把握することができる。
【００４４】
次に、図４は、タグ読み取りバッファ２１１の構成図であり、レコードのフィールドとして少なくともタグＩＤ２１１ａと、リーダＩＤ２１１ｂと、読み取り開始時刻２１１ｃと、強制読み取りイベント生成時間２１１ｄと、を含む。
【００４５】
タグＩＤ２１１ａと、リーダＩＤ２１１ｂと、には、タグ読み取りイベント生成プログラム２１０が受信したタグＩＤ４０１−リーダＩＤ３０１のペアのうち、タグＩＤ４０１のタグ４００がそのときにリーダＩＤ３０１のリーダ３００に読み取られるスケジュール通りでないものを記憶させる。なお、記憶されたレコードは、タグＩＤ２１１ａを通知する候補となるレコードである。一方、読み取られるスケジュール通りのものは、タグＩＤ２１１ａを通知することが確定するため、記憶する必要がない。
【００４６】
読み取り開始時刻２１１ｃは、レコードのタグＩＤ２１１ａに示すタグ４００が、レコードのリーダＩＤ２１１ｂに示すリーダ３００に読み取られ始めた時刻である。
【００４７】
強制読み取りイベント生成時間２１１ｄは、レコードのタグＩＤ２１１ａに示すタグ４００が、レコードのリーダＩＤ２１１ｂに示すリーダ３００に、強制読み取りイベント生成時間２１１ｄの間、連続して読み取られれば、強制読み取りとしてイベントを生成する時間である。
【００４８】
次に、図５は、スケジュール管理プログラム１１０による読み取りリーダスケジュール確認処理のフローチャートである。以下、図５の概要を説明する。
【００４９】
スケジュール管理プログラム１１０は、タグ読み取りイベント生成プログラム２１０から、１つ以上のタグＩＤ−リーダＩＤのペアを含む読み取りリーダスケジュール確認要求を受信し、タグＩＤ−リーダＩＤのペアのそれぞれについて、読み取りリーダスケジュールＤＢ１１１の内容に従って、そのタグＩＤのタグ４００がそのときにそのリーダＩＤのリーダ３００に読み取られるスケジュール通りであったか確認する。
【００５０】
まず、スケジュール管理プログラム１１０は、スケジュール通りであれば、そのタグＩＤのタグ４００が次にどのリーダＩＤのリーダ３００に読み取られるかの状態を遷移させ、スケジュール通りの読み取りだとタグ読み取りイベント生成プログラム２１０に応答する。
【００５１】
一方、スケジュール管理プログラム１１０は、スケジュール通りでなければ、強制読み取りイベント生成条件ＤＢ１１２の内容に従って、そのタグＩＤのタグ４００がそのリーダＩＤのリーダ３００に指定時間、読み取られ続ければ強制読み取りとしてイベントを生成する指定時間をタグ読み取りイベント生成プログラム２１０に応答する。以上、図５の概要を説明した。
【００５２】
図６は、読み取りリーダスケジュール確認要求５００の構成を示す。まず、スケジュール管理プログラム１１０は、タグ読み取りイベント生成プログラム２１０から、読み取りリーダスケジュール確認要求５００を受信することにより（図５のＳ１１１）、処理を開始する。なお、読み取りリーダスケジュール確認要求５００は、１つ以上のタグＩＤ５００ａ−リーダＩＤ５００ｂのペアを含むデータである。
【００５３】
そして、スケジュール管理プログラム１１０は、受信した読み取りリーダスケジュール確認要求５００に含まれるタグＩＤ５００ａ−リーダＩＤ５００ｂのペアのそれぞれについて、Ｓ１１２、Ｓ１１３、Ｓ１１４のステップの処理を行う。
【００５４】
スケジュール管理プログラム１１０は、タグＩＤ−リーダＩＤのペアによる現状態での読み取りの可否を判定する（Ｓ１１２）。つまり、スケジュール管理プログラム１１０は、タグＩＤ５００ａとタグＩＤ１１１ａとが一致するときに、読み取りリーダスケジュールＤＢ１１１におけるタグＩＤ１１１ａを含むレコードについて、読み取りリーダ状態遷移表１１１ｂの現状態１１１ｃに対応する読み取り許可リーダＩＤに、リーダＩＤ５００ｂが含まれるかチェックする。
【００５５】
読み取りが可能なとき（Ｓ１１２，Ｙｅｓ）、スケジュール管理プログラム１１０は、レコードの、読み取りリーダ状態遷移表１１１ｂの現状態１１１ｃに対応する次状態を、現状態１１１ｃに記憶させるように読み取りリーダの状態遷移を行い（Ｓ１１３）、Ｓ１１５に移る。
【００５６】
読み取りが不可能なとき（Ｓ１１２，Ｎｏ）、スケジュール管理プログラム１１０は、リーダＩＤ５００ｂとリーダＩＤ１１２ａとが一致する際の、強制読み取りイベント生成条件ＤＢ１１２におけるリーダＩＤ１１２ａを含むレコードについて、強制読み取りイベント生成時間１１２ｂを取得し（Ｓ１１４）、Ｓ１１５に移る。
【００５７】
そして、スケジュール管理プログラム１１０は、Ｓ１１１で受信した読み取りリーダスケジュール確認要求５００に含まれるタグＩＤ５００ａ−リーダＩＤ５００ｂのペアのすべてが確認済みかチェックする（Ｓ１１５）。すべてが確認済みのときは（Ｓ１１５，Ｙｅｓ）、Ｓ１１６に移り、すべてが確認済みではないときは（Ｓ１１５，Ｎｏ）、Ｓ１１２に移る。
【００５８】
さらに、スケジュール管理プログラム１１０は、タグ読み取りイベント生成プログラム２１０に、読み取りリーダスケジュール確認要求応答５０１を送信し（Ｓ１１６）、以上で読み取りリーダスケジュール確認処理は完了する。
【００５９】
図７は、読み取りリーダスケジュール確認要求応答５０１の構成を示す。読み取りリーダスケジュール確認要求応答５０１は、少なくともタグＩＤ５０１ａ−スケジュール確認結果５０１ｂのペアを含む。タグＩＤ５０１ａには、Ｓ１１１で受信した読み取りリーダスケジュール確認要求５００に含まれるタグＩＤ５００ａのすべてが設定される。スケジュール確認結果５０１ｂには、タグＩＤ５０１ａのそれぞれについて、Ｓ１１２のチェックでリーダＩＤ５００ｂが含まれていればＯＫが、含まれていなければＳ１１４で取得した強制読み取りイベント生成時間１１２ｂが設定される。
【００６０】
次に、図８は、タグ読み取りイベント生成処理のフローチャートである。以下、図８のフローチャートの概要を説明する。タグ読み取りイベント生成プログラム２１０は、１つ以上のリーダ３００から、リーダ３００のそれぞれが１つ以上のタグＩＤ４０１を読み取って、タグＩＤ４０１のそれぞれとそのリーダ３００のリーダＩＤ３０１とを関連付けた１つ以上のタグＩＤ４０１−リーダＩＤ３０１のペアを受信する。
【００６１】
タグ読み取りイベント生成プログラム２１０は、タグＩＤ４０１−リーダＩＤ３０１のペアのそれぞれについて、タグＩＤ４０１のタグ４００がそのときにリーダＩＤ３０１のリーダ３００に読み取られるスケジュール通りであったかスケジュール管理プログラム１１０に問い合わせ、スケジュール通りであればスケジュール通りの読み取りとしてイベントを生成し、スケジュール通りでなく、スケジュール管理プログラム１１０が指定した時間、読み取られ続けていれば強制読み取りとしてイベントを生成する。以上、図８のフローチャートの概要を説明した。
【００６２】
まず、タグ読み取りイベント生成プログラム２１０は、１つ以上のリーダ３００から、１つ以上のタグＩＤ４０１−リーダＩＤ３０１のペアを時計２０６から取得した時刻と関連付けて受信することにより（Ｓ２１１）、処理を開始する。
【００６３】
そして、タグ読み取りイベント生成プログラム２１０は、スケジュール管理プログラム１１０に読み取りリーダスケジュール確認要求５００を送信し（Ｓ２１２）、読み取りリーダスケジュール確認要求５００を受信したスケジュール管理プログラム１１０は、図５の説明で記載した方法に従って、読み取りリーダスケジュール確認要求５００に含まれるタグＩＤ５００ａ−リーダＩＤ５００ｂのペアのそれぞれについて、スケジュール通りの読み取りであったか確認し、タグ読み取りイベント生成プログラム２１０に読み取りリーダスケジュール確認要求応答５０１を返信する。
【００６４】
タグ読み取りイベント生成プログラム２１０は、読み取りリーダスケジュール確認要求応答５０１を受信し、読み取りリーダスケジュール確認要求応答５０１に含まれるタグＩＤ５０１ａ−スケジュール確認結果５０１ｂのペアのそれぞれについて、Ｓ２１３、Ｓ２１４、Ｓ２１５、Ｓ２１６のステップの処理を行う。なお、読み取りリーダスケジュール確認要求５００のタグＩＤ５００ａ−リーダＩＤ５００ｂのペアには、Ｓ２１１で受信したタグＩＤ４０１−リーダＩＤ３０１のペアのすべてが設定される。
【００６５】
Ｓ２１３では、タグ読み取りイベント生成プログラム２１０は、スケジュール確認結果５０１ｂがＯＫであるかチェックする。
【００６６】
まず、スケジュール確認結果５０１ｂがＯＫのとき（Ｓ２１３，Ｙｅｓ）、読み取りイベント生成プログラム２１０は、タグＩＤ５０１ａや、タグＩＤ５０１ａに対応するＳ２１１で受信したタグＩＤ４０１−リーダＩＤ３０１のペア、ならびにペアに関連付けられている時刻から判明する、タグＩＤ５０１ａを読み取ったリーダ３００のリーダＩＤ３０１、ならびに読み取り時刻などをもとに、スケジュール通りの読み取りとしてイベントを生成し（Ｓ２１４）、業務への活用につなげ、Ｓ２１７に移る。
【００６７】
一方、スケジュール確認結果５０１ｂがＯＫではないとき（Ｓ２１３，Ｎｏ）、タグ読み取りイベント生成プログラム２１０は、タグ読み取りバッファ２１１に、タグＩＤ５０１ａに対応するＳ２１１で受信したタグＩＤ４０１−リーダＩＤ３０１のペアに一致するタグＩＤ２１１ａ−リーダＩＤ２１１ｂのペアを参照できるかチェックする（Ｓ２１５）。ペアを参照できるときは（Ｓ２１５，Ｙｅｓ）、Ｓ２１７に移り、ペアを参照できないときは（Ｓ２１５，Ｎｏ）、Ｓ２１６に移る。
【００６８】
そして、タグ読み取りイベント生成プログラム２１０は、タグ読み取りバッファ２１１に、タグＩＤ２１１ａ−リーダＩＤ２１１ｂのペア、読み取り開始時刻２１１ｃ、強制読み取りイベント生成時間２１１ｄのそれぞれが、タグＩＤ５０１ａに対応するタグＩＤ４０１−リーダＩＤ３０１のペア、ペアに関連付けられている時刻、スケジュール確認結果５０１ｂである行を追記し（Ｓ２１６）、Ｓ２１７に移る。
【００６９】
さらに、タグ読み取りイベント生成プログラム２１０は、Ｓ２１３で受信した読み取りリーダスケジュール確認要求応答５０１に含まれるタグＩＤ５０１ａ−スケジュール確認結果５０１ｂのペアのすべてが確認済みかチェックする（Ｓ２１７）。すべてが確認済みのときは（Ｓ２１７，Ｙｅｓ）、Ｓ２１８に移り、すべてが確認済みではないときは（Ｓ２１７，Ｎｏ）、Ｓ２１３に移る。
【００７０】
そして、タグ読み取りイベント生成プログラム２１０は、Ｓ２１３で受信した読み取りリーダスケジュール確認要求応答５０１に含まれるタグＩＤ５０１ａ−スケジュール確認結果５０１ｂのペアのすべてについてＳ２１３、Ｓ２１４、Ｓ２１５、Ｓ２１６のステップの処理を行った結果、参照、追記されなかったタグ読み取りバッファ２１１の行（レコード）を削除する（Ｓ２１８）。なお、タグ読み取りバッファ２１１のどの行が参照、追記されなかったものなのかは、例えば、タグ読み取りイベント生成プログラム２１０が、参照、追記された行（レコード）の図示しないＩＤを記憶しておくことにより判別できる。
【００７１】
さらに、タグ読み取りイベント生成プログラム２１０は、時計２０６からそのときの時刻を取得し、タグ読み取りバッファ２１１に、強制読み取りイベント生成時間２１１ｄを過ぎている、すなわち時刻が読み取り開始時刻２１１ｃに強制読み取りイベント生成時間２１１ｄを足した時刻を過ぎている行のそれぞれについて、レコードのタグＩＤ２１１ａや、リーダＩＤ２１１ｂ、読み取り開始時刻２１１ｃなどをもとに、強制読み取りとしてイベントを生成し（Ｓ２１９）、業務への活用につなげ、行のすべてを削除する。以上でタグ読み取りイベント生成処理は完了して受信待機に移行する（Ｓ２２０）。
【００７２】
以上、本発明を実施するための最良の形態などについて具体的に説明したが、本発明はこれに限定されるものではなく、その要旨を逸脱しない範囲で種々変更可能である。例えば、図１のシステムの構成を以下に示すように、変形実施してもよい。
【００７３】
タグ読み取りイベント生成プログラム２１０は、実行時にメモリ２０２にデータとしてタグ読み取りバッファ２１１を１つ生成していたが、そのリーダ制御装置２００につながるリーダ３００ごとに複数生成するリーダ制御装置２００の構成であってもよい。リーダ制御装置２００では、タグ読み取りバッファ２１１にバッファリングするデータのうち、リーダＩＤを省略してもよい。
【００７４】
リーダ３００がタグ４００を読み取った時刻は、リーダ制御装置２００の時計２０６によるものであったが、リーダ３００に時計を含むシステムの構成であれば、リーダ３００がタグ４００を読み取った時刻は、リーダ３００に含まれる時計によるものであってもよい。システムで、そのリーダ制御装置２００につながるリーダ３００のすべてが時計を含めば、そのリーダ制御装置２００の時計２０６を省略してもよい。
【００７５】
リーダＩＤ３０１がリーダ３００に含まれていたが、リーダＩＤ３０１がリーダ３００に含まれないシステムの構成であってもよい。システムでは、リーダ３００がつながるリーダインタフェース２０５のそれぞれに対しＩＤを割り振り、ＩＤを記憶装置２０３にデータとして含ませたものをリーダＩＤとする。
【００７６】
それぞれのタグＩＤのタグ４００について、どのリーダＩＤのリーダ３００に読み取られていくかのスケジュールを管理していたが、リーダ３００に１つ以上アンテナがつながるシステムの構成であれば、どのＩＤのアンテナに読み取られていくかのスケジュールを管理してもよい。つまり、図１のシステムでは、リーダＩＤで管理していたものを、アンテナのＩＤであるアンテナＩＤで管理することになる。
【００７７】
それぞれのリーダＩＤのリーダ３００について、スケジュール通りの読み取りでないどのタグＩＤのタグ４００であっても、指定時間、読み取り続けていれば強制読み取りとしてイベントを生成していたが、指定回数、読み取り続けていれば強制読み取りとしてイベントを生成するシステムの構成であってもよい。
【００７８】
強制読み取りイベント生成条件ＤＢ１１２が指定時間で管理していたものを、指定回数で管理することになり、タグ読み取りバッファ２１１も指定時間で管理していたものを、指定回数で管理することになり、また、タグ読み取りバッファ２１１にバッファリングするデータのうち、その読み取りの開始時刻を省略してもよく、ひいては時計２０６を省略してもよい。
【００７９】
読み取りリーダスケジュール装置１００と、読み取りリーダスケジュール装置１００に１つ以上つながるリーダ制御装置２００と、を含んでいたが、読み取りリーダスケジュール装置１００と、リーダ制御装置２００と、を統合した統合装置を１つ以上含むシステムの構成であってもよい。図１のシステムでは、読み取りリーダスケジュールＤＢ１１１と、強制読み取りイベント生成条件ＤＢ１１２と、が統合装置それぞれの記憶装置に記憶され、前記統合装置間でミラーリングされ、データの同期（duplicate）が取られる。
【００８０】
スケジュール管理プログラム１１０は、読み取りリーダスケジュール装置１００の記憶装置１０３に記憶されており、メモリ１０２に読み込まれ、ＣＰＵ１０１に実行されることにより、読み取りリーダスケジュール装置１００において処理が実行されていたが、スケジュール管理プログラム１１０が、リーダ制御装置２００の記憶装置２０３に記憶されており、メモリ２０２に読み込まれ、ＣＰＵ２０１に実行されることにより、リーダ制御装置２００において処理が実行されるシステムの構成であってもよい。
【００８１】
スケジュール管理プログラム１１０は、記憶装置１０３に記憶される読み取りリーダスケジュールＤＢ１１１と、強制読み取りイベント生成条件ＤＢ１１２とにアクセスするシステムの構成のほか、スケジュール管理プログラム１１０が、記憶装置１０３に記憶される読み取りリーダスケジュールＤＢ１１１と、強制読み取りイベント生成条件ＤＢ１１２と、がメモリ２０２ないし記憶装置２０３にミラーリングないしキャッシュされたものにアクセスするシステムの構成であってもよい。
【００８２】
スケジュール管理プログラム１１０は、読み取りリーダスケジュールＤＢ１１１の内容に従って、そのタグＩＤのタグ４００がそのときにそのリーダＩＤのリーダ３００に読み取られるスケジュール通りであったか確認していた。ここで、読み取りリーダスケジュールＤＢ１１１の内容は、様々な表現形式でスケジュールを記述することができる。
【００８３】
読み取りリーダスケジュールＤＢ１１１の内容をもとに、そのリーダＩＤのリーダ３００がそのときに読み取るスケジュール通りのタグＩＤのリストを、それぞれのリーダ３００につながるリーダ制御装置２００にリアルタイムに配信することで、リストが配信されるリーダ制御装置２００のタグ読み取りイベント生成プログラム２１０が、そのタグＩＤ４０１のタグ４００がそのときにそのリーダＩＤ３０１のリーダ３００に読み取られるスケジュール通りであったか、スケジュール管理プログラム１１０に問い合わせるのではなく、リストを参照することにより確認し、その確認結果をスケジュール管理プログラム１１０に通知し、確認結果を読み取りリーダスケジュールＤＢに反映させるシステムの構成であってもよい。
【００８４】
強制読み取りイベント生成条件ＤＢ１１２が読み取りリーダスケジュール装置１００の記憶装置１０３に記憶されていたが、それぞれのリーダ制御装置２００に、強制読み取りイベント生成条件ＤＢ１１２のレコードのうち、そのリーダ制御装置２００につながるリーダ３００のリーダＩＤ３０１に一致するもののみからなるＤＢを記憶装置２０３に記憶させ、タグ読み取りイベント生成プログラム２１０がＤＢから、強制読み取りとしてイベントを発生させる条件を取得するシステムの構成であってもよい。
【００８５】
図２の読み取りリーダスケジュールＤＢ１１１は、レコードのフィールドとして現状態１１１ｃを含んでいたが、タグ４００がデータを読み書きできる領域を持つとき、現状態１１１ｃを読み取りリーダスケジュールＤＢ１１１に持つのではなく、タグ４００がデータを読み書きできる領域に持つＤＢの構成であってもよい。
【００８６】
図３の強制読み取りイベント生成条件ＤＢ１１２は、リーダＩＤ１１２ａごとに、強制読み取りイベント生成時間１１２ｂを管理していたが、それぞれのリーダＩＤのリーダ３００が、それぞれのタグＩＤのタグ４００を読み取ったペア、すなわちリーダＩＤとタグＩＤとのペアごとに、強制読み取りイベント生成時間１１２ｂを管理するＤＢの構成であってもよい。または、それぞれのリーダＩＤのリーダ３００が、それぞれの現状態に、それぞれのタグＩＤのタグ４００を読み取った組合せ、すなわちリーダＩＤと現状態とタグＩＤとの組合せごとに、強制読み取りイベント生成時間１１２ｂを管理するＤＢの構成であってもよい。
【００８７】
図８のフローチャートでは、Ｓ２１１で受信したタグＩＤ４０１−リーダＩＤ３０１のペアのすべてを読み取りリーダスケジュール確認要求５００に設定していたが、ペアのうち、タグ読み取りバッファ２１１に参照できるものは読み取りリーダスケジュール確認要求５００に設定しないように動作してもよい。図８のフローチャートでは、Ｓ２１３の結果、ＯＫでなければ、Ｓ２１５を省いて、Ｓ２１６に移る。また、図８のフローチャートでは、Ｓ２１８を省き、その代わりにＳ２１２において、タグ読み取りバッファ２１１の行のうち、Ｓ２１１で受信したタグＩＤ４０１−リーダＩＤ３０１のペアに含まれないものを削除する。
【００８８】
図８のフローチャートでは、Ｓ２１９はＳ２２０の直前に行っていたが、そのフローチャートにおいてどのタイミングで行ってもよい。さらに、図８では、Ｓ２１６において、強制読み取りイベント生成時間２１１ｄが０秒であれば、タグ読み取りバッファ２１１への追記は行わず、直接、強制読み取りとしてイベントを生成し、業務への活用につなげてもよい。
【００８９】
図９は、図２の状態遷移表の一部（タグＩＤ１１１ａがＴ５６のデータ）を状態遷移図にしたものである。各状態（現状態１１１ｃ、次状態１１１ｂ０ｂ）は、丸で囲まれたノードで示される。状態間の遷移は、ノード間の矢印で示され、状態が遷移するための入力は、読み取り許可リーダＩＤ１１１ｂ０ａである。例えば、現状態１１１ｃが「状態０」で、読み取り許可リーダＩＤ１１１ｂ０ａの「Ｒ１２」が入力されると、次状態１１１ｂ０ｂの「状態１」に遷移する。
【００９０】
このように、状態が遷移する読み取り許可リーダＩＤ１１１ｂ０ａからタグＩＤ１１１ａが入力された時には、そのタグＩＤ１１１ａを通知するためのイベントを発生させる。一方、状態が遷移しないリーダＩＤ３０１からタグＩＤ１１１ａが入力された時には、タグＩＤを通知するためのイベントを発生させない。
【図面の簡単な説明】
【００９１】
【図１】本発明の一実施形態に関するシステムを示す構成図である。
【図２】本発明の一実施形態に関する読み取りリーダスケジュールＤＢを示す構成図である。
【図３】本発明の一実施形態に関する強制読み取りイベント生成条件ＤＢを示す構成図である。
【図４】本発明の一実施形態に関するタグ読み取りバッファを示す構成図である。
【図５】本発明の一実施形態に関する読み取りリーダスケジュール確認処理を示すフローチャートである。
【図６】本発明の一実施形態に関する読み取りリーダスケジュール確認要求を示す構成図である。
【図７】本発明の一実施形態に関する読み取りリーダスケジュール確認要求応答を示す構成図である。
【図８】本発明の一実施形態に関するタグ読み取りイベント生成処理を示すフローチャートである。
【図９】本発明の一実施形態に関する読み取りリーダスケジュールＤＢを示す状態遷移図である。
【符号の説明】
【００９２】
１００  読み取りリーダスケジュール装置
１１０  スケジュール管理プログラム
１１１  読み取りリーダスケジュールＤＢ
１１２  強制読み取りイベント生成条件ＤＢ
２００  リーダ制御装置
２１０  タグ読み取りイベント生成プログラム
２１１  タグ読み取りバッファ
３００  リーダ
３０１  リーダＩＤ
４００  タグ
４０１  タグＩＤ
５００  読み取りリーダスケジュール確認要求
５０１  読み取りリーダスケジュール確認要求応答
【図１】
0004644095.tif 000002
【図２】
0004644095.tif 000003
【図３】
0004644095.tif 000004
【図４】
0004644095.tif 000005
【図５】
0004644095.tif 000006
【図６】
0004644095.tif 000007
【図７】
0004644095.tif 000008
【図８】
0004644095.tif 000009
【図９】
0004644095.tif 000010