JP5416619B2 - Ｒｆｉｄプラットフォームシステム、ロガー装置、及び、管理方法 - Google Patents

Description

本発明はＲＦＩＤ（Radio Freqency IDentification）タグの所在を管理するＲＦＩＤプラットフォームシステムに関する。

近年、物品の情報を個別に識別するためのＲＦＩＤシステムの開発が活発化されている。もともとＲＦＩＤシステムは、バーコードに代わる新たな商品識別及び管理技術として開発されてきたが、現在ではそれに留まらず、様々な技術分野への応用も展開されている。管理対象も物品に限らず、人も対象とするようになってきた。例えば、公共交通機関においては、従来の改札券や定期券の代わりに、ＲＦタグを内蔵した入場管理カードの利用が急速に進展している。また、ＲＦタグを用いて人を管理する技術の一つとして、ＲＦタグを所持した人がどこにいるのかをコンピュータ上で把握する在席管理システムが挙げられる。

従来のＲＦＩＤシステムは、単一のプラットフォームと、複数のタグリーダとにより構成される。ＲＦタグから送信されるタグデータは、タグリーダの何れかを介してプラットフォームに集約される。プラットフォームに集約されたタグデータは、データベース化されて、在席管理システムのような各種アプリケーションに提供される。特許文献１〜４には、タグリーダにおいて取得したタグデータを管理し、各種アプリケーションに提供するＲＦＩＤシステムが記載されている。

特に特許文献４に記載のイベント管理デバイスは、複数の種類の異なるタグリーダからアプリケーションに伝送されるデータ量を低減するために、各種タグリーダと各種アプリケーションとの通信をサポートし、タグリーダから取得したタグデータに対してイベント生成処理及びデータフィルタリング処理を行っている。このイベント管理デバイスにおいて、タグリーダとアプリケーションとの通信は、互いに異なるタグリーダのプロトコルの互換及び変換を行うことによってサポートされ、タグリーダ毎に取得されたタグデータは、フィルタリング及びイベント生成の後にデータ格納ユニットに格納され、各種アプリケーションに提供される。

特開２００９−１５７７７９号公報（２００９年７月１６日公開） 特開２００９−１３４７２２号公報（２００９年６月１８日公開） 特開２００８−１５８６５１号公報（２００８年７月１０日公開） 特表２００８−５２４７４２号公報（２００８年７月１０日公表）

しかしながら、上述した特許文献４に記載の従来技術においては、システムで管理すべきＲＦタグ及びタグリーダの情報を一つのイベント管理デバイスで一括管理し、さらに取得したタグデータは全て一つのデータベースに格納される。したがって、管理すべきＲＦタグの数が増加すると、タグデータの管理を行うイベント管理デバイスの負荷が増大し、システムのパフォーマンスが著しく低下する。換言すれば、システムのパフォーマンスを一定以上に保つためには、管理するＲＦタグの数を一定数以下に抑える必要が生じる。特許文献１〜３に記載の従来技術も、一つのプラットフォームで全てのタグ情報を一括管理しているので、同様の問題点を有している。

本発明は、上記の問題点に鑑みてなされたものであり、その目的は、管理すべきＲＦタグの数が増加しても、著しいパフォーマンスの低下を生じることのないＲＦＩＤプラットフォームシステム、換言すれば、著しいパフォーマンスの低下を生じることなく、管理すべきＲＦタグの数をいくらでも増加させることのできるＲＦＩＤプラットフォームシステムを提供することにある。

上記課題を解決するために、本発明に係るＲＦＩＤプラットフォーム装置システムは、異なるＲＦタグ群を管理する複数のプラットフォーム装置と、上記複数のプラットフォーム装置のアドレスを管理するマスタプラットフォーム装置と、上記複数のプラットフォーム装置の何れかに対応するロガー装置であって、ＲＦタグが対応プラットフォーム装置で管理するＲＦタグ群に含まれる場合、上記ＲＦタグから読み出したタグデータを上記対応プラットフォーム装置に送信するロガー装置とを含み、上記ロガー装置は、上記ＲＦタグが上記対応プラットフォーム装置で管理するＲＦタグ群に含まれない場合、上記ＲＦタグを管理するプラットフォーム装置のアドレスを上記マスタプラットフォーム装置に問い合わせ、上記マスタプラットフォーム装置は、上記複数のプラットフォーム装置の各々に上記ＲＦタグを管理するプラットフォーム装置であるかを問い合わせ、上記ＲＦタグを管理するプラットフォーム装置であると回答したプラットフォーム装置のアドレスを上記ロガー装置に回答し、上記ロガー装置は、上記ＲＦタグから読み出したタグデータを、上記マスタプラットフォーム装置から回答されたアドレス宛てに送信する、ことを特徴としている。

また、上記課題を解決するために、本発明に係る管理方法は、異なるＲＦタグ群を管理する複数のプラットフォーム装置と、上記複数のプラットフォーム装置のアドレスを管理するマスタプラットフォーム装置と、上記複数のプラットフォーム装置の何れかに対応するロガー装置とを用いてＲＦタグから読み出したタグデータを管理する管理方法であって、上記ＲＦタグが対応プラットフォーム装置で管理するＲＦタグ群に含まれる場合、上記ロガー装置が、上記ＲＦタグから読み出したタグデータを上記対応プラットフォーム装置に送信するステップと、上記ＲＦタグが上記対応プラットフォーム装置で管理するＲＦタグ群に含まれない場合、上記ロガー装置が、上記ＲＦタグを管理するプラットフォーム装置のアドレスを上記マスタプラットフォーム装置に問い合わせるステップと、上記マスタプラットフォーム装置が、上記複数のプラットフォーム装置の各々に上記ＲＦタグを管理するプラットフォーム装置であるかを問い合わせ、上記ＲＦタグを管理するプラットフォーム装置であると回答したプラットフォーム装置のアドレスを上記ロガー装置に回答するステップと、上記ロガー装置が、上記ＲＦタグから読み出したタグデータを、上記問い合わせに対して上記マスタプラットフォーム装置から回答されたアドレス宛てに送信するステップと、を含むことを特徴としている。

上記の構成によれば、ＲＦタグが対応プラットフォーム装置で管理するＲＦタグ群に含まれない場合でも、ロガー装置は、マスタプラットフォーム装置に問い合わせることによって、そのＲＦタグを管理するプラットフォーム装置のアドレスを知り、そのＲＦタグを管理するプラットフォーム装置にタグデータを送信することができる。すなわち、ロガー装置は、どのプラットフォーム装置が管理しているＲＦタグであろうと、正しくタグデータを送信することができる。

しかも、ＲＦＩＤプラットフォームシステムは、複数のプラットフォーム装置によってＲＦタグを分担して管理している。このため、管理すべきＲＦタグの枚数が増加しても、新たなプラットフォーム装置を追加することにより、システムのパフォーマンスの低下を容易に回避することができる。なお、新たなプラットフォーム装置の追加は、そのアドレスをマスタプラットフォームに登録するだけでよいので極めて容易である。

また、マスタプラットフォーム装置は、複数のプラットフォーム装置のアドレスさえ管理すればよく、タグＩＤやタグデータを管理する必要がない。このため、管理すべきＲＦタグの枚数が増加し、プラットフォーム装置の台数が増加したとしても、マスタプラットフォーム装置がボトルネックになって、システムのパフォーマンスが低下する虞がない。

また、本発明に係るＲＦＩＤプラットフォーム装置システムにおいて、上記ロガー装置は、上記ＲＦタグのタグＩＤを上記マスタプラットフォーム装置に送信することによって、上記マスタプラットフォーム装置に問い合わせるものであり、上記マスタプラットフォーム装置は、上記ＲＦタグのタグＩＤを上記複数のプラットフォーム装置の各々に送信することによって、上記複数のプラットフォーム装置の各々に問い合わせるものであり、上記複数のプラットフォーム装置の各々は、自身の管理するＲＦタグのタグＩＤを格納したデータベースを有しており、上記マスタプラットフォーム装置から送信された上記ＲＦタグのタグＩＤが当該データベースに格納されているか否かを判定し、上記ＲＦタグのタグＩＤが上記データベースに格納されていると判定した場合、自身のアドレスを上記マスタプラットフォーム装置に送信することによって、上記マスタプラットフォーム装置に回答し、上記マスタプラットフォーム装置は、上記ＲＦタグを管理するプラットフォーム装置であると回答したプラットフォーム装置のアドレスを上記ロガー装置に送信することによって、上記ロガー装置に回答する、ことが好ましい。

上記の構成によれば、ロガー装置からマスタプラットフォーム装置に送信される問い合わせ、及びマスタプラットフォーム装置から各プラットフォーム装置に送信される問い合わせには、ロガー装置が検出したＲＦタグのタグＩＤが含まれている。そして、プラットフォーム装置は、データベースに格納された自身の管理するＲＦタグのタグＩＤに、マスタプラットフォーム装置からの問い合わせに含まれる上記ＲＦタグのタグＩＤが含まれているか否かを判定し、含まれていると判定した場合にプラットフォーム装置は自身のアドレスをマスタプラットフォーム装置に送信する。さらに、マスタプラットフォーム装置は、プラットフォーム装置から送信されたアドレスをロガー装置に送信することによって、ロガー装置に回答する。

また、本発明に係るＲＦＩＤプラットフォーム装置システムにおいて、上記ロガー装置は、ＲＦタグのタグＩＤと、該ＲＦタグから読み出したタグデータを送信した送信先アドレスとを関連付けて記憶するキャッシュを備えており、新たなＲＦタグが上記対応プラットフォーム装置で管理するＲＦタグ群に含まれない場合に、該新たなＲＦタグから読み出したタグデータを送信する送信先アドレスを、上記キャッシュにおいて該新たなＲＦタグのタグＩＤに関連付けられた送信先アドレスに設定する、ことが好ましい。

上記の構成によれば、ＲＦタグが対応プラットフォーム装置で管理するＲＦタグ群に含まれない場合であっても、そのＲＦタグのタグデータの送信が２度目以降であれば、マスタプラットフォーム装置への問い合わせを行わずに、キャッシュから送信先アドレスを読み出すことができる。このため、システムのパフォーマンスを更に向上させることができる。

また、上記ＲＦＩＤプラットフォームシステムを複数含み、更に、各ＲＦＩＤプラットフォームシステムに含まれるマスタプラットフォーム装置のアドレスを管理する上位マスタプラットフォーム装置を追加した構成も本発明の範疇に入る。

上記の構成によれば、管理すべきＲＦタグの枚数が指数関数的に増加しても、より上位のマスタプラットフォーム装置を追加することにより、システムのパフォーマンスの低下を容易に回避することができる。

また、上記ＲＦＩＤプラットフォームシステムに含まれるロガー装置、プラットフォーム装置、及びマスタプラットフォーム装置も本発明の範疇に入る。

すなわち、本発明のロガー装置は、ＲＦタグ群を管理するプラットフォーム装置に対応するロガー装置であって、ＲＦタグが上記ＲＦタグ群に含まれない場合、上記ＲＦタグを管理するプラットフォーム装置のアドレスを、上記プラットフォーム装置を含む複数のプラットフォーム装置のアドレスを管理するマスタプラットフォーム装置に問い合わせる問合手段と、上記ＲＦタグが上記ＲＦタグ群に含まれる場合、上記ＲＦタグから読み出したタグデータを、上記プラットフォーム装置に送信し、上記ＲＦタグが上記ＲＦタグ群に含まれない場合、上記ＲＦタグから読み出したタグデータを、上記問い合わせに対して上記マスタプラットフォーム装置が回答したアドレス宛てに送信する送信手段と、を備えていることを特徴としている。

また、本発明のプラットフォーム装置は、ＲＦタグ群を管理するプラットフォーム装置であって、当該プラットフォーム装置を含む複数のプラットフォーム装置のアドレスを管理するマスタプラットフォーム装置からの問い合わせであって、特定のＲＦタグを管理するプラットフォーム装置であるかを問う問い合わせに対して、上記特定のＲＦタグが上記ＲＦタグ群に含まれている場合、上記特定のＲＦタグを管理するプラットフォーム装置である旨を回答する回答手段を備えている、ことを特徴としている。

また、異なるＲＦタグ群を管理する複数のプラットフォーム装置のアドレスを管理するマスタプラットフォーム装置であって、上記複数のプラットフォーム装置の何れかに対応するロガー装置からの問い合わせであって、特定のＲＦタグを管理するプラットフォーム装置のアドレスを問う問い合わせに応じて、上記複数のプラットフォーム装置の各々に上記特定のＲＦタグを管理するプラットフォーム装置であるかを問い合わせ、上記特定のＲＦタグを管理するプラットフォーム装置であると回答したプラットフォーム装置のアドレスを上記ロガー装置に回答する回答手段を備えている、ことを特徴としている。

本発明に係るＲＦＩＤプラットフォームシステムは、以上のように、異なるＲＦタグ群を管理する複数のプラットフォーム装置と、上記複数のプラットフォーム装置のアドレスを管理するマスタプラットフォーム装置と、上記複数のプラットフォーム装置の何れかに対応するロガー装置であって、ＲＦタグが対応プラットフォーム装置で管理するＲＦタグ群に含まれる場合、上記ＲＦタグから読み出したタグデータを上記対応プラットフォーム装置に送信するロガー装置とを含み、上記ロガー装置は、上記ＲＦタグが上記対応プラットフォーム装置で管理するＲＦタグ群に含まれない場合、上記ＲＦタグを管理するプラットフォーム装置のアドレスを上記マスタプラットフォーム装置に問い合わせ、上記マスタプラットフォーム装置は、上記複数のプラットフォーム装置の各々に上記ＲＦタグを管理するプラットフォーム装置であるかを問い合わせ、上記ＲＦタグを管理するプラットフォーム装置であると回答したプラットフォーム装置のアドレスを上記ロガー装置に回答し、上記ロガー装置は、上記ＲＦタグから読み出したタグデータを、上記マスタプラットフォーム装置から回答されたアドレス宛てに送信する。

したがって、管理すべきＲＦタグの数が増加しても、著しいパフォーマンスの低下を生じることのないＲＦＩＤプラットフォームシステムを実現することができる。

本発明の第１の実施形態に係るＲＦＩＤプラットフォームシステムの全体構成を示すシステム構成図である。 図１のＲＦＩＤプラットフォームシステムに含まれるロガーの要部構成を示すブロック図である。 図１のＲＦＩＤプラットフォームシステムに含まれるプラットフォームの要部構成を示すブロック図である。 図１のＲＦＩＤプラットフォームシステムに含まれるマスタプラットフォームの要部構成を示すブロック図である。 図３に示すプラットフォームのデータベース（マスタデータベース）に含まれるタグ管理テーブルを示す図である。 図３に示すプラットフォームのデータベース（マスタデータベース）に含まれるタグリーダ管理テーブルを示す図である。 図３に示すプラットフォームのデータベース（マスタデータベース）に含まれる抽象データ管理テーブルを示す図である。 図４に示すマスタプラットフォームのインデックスデータ管理テーブルを示す図である。 図２に示すロガーのキャッシュデータ管理テーブルを示す図である。 本発明の第２の実施形態に係るＲＦＩＤプラットフォームシステムの全体構成を示す図である。

〔ＲＦＩＤプラットフォームシステム〕
（実施形態１）
本発明の第１の実施形態について、図１〜図９に基づいて説明すれば以下のとおりである。なお、以下の説明において、「ＲＦタグ」とは、タグＩＤを記憶するＩＣチップが埋め込まれた近距離無線通信可能なタグのことを指し、パッシブタグであるか、アクティブタグであるかは問わない。

本実施形態に係るＲＦＩＤプラットフォームシステム１について、図１を参照して説明する。図１は、本実施形態に係るＲＦＩＤプラットフォームシステム１の全体構成を示すシステム構成図である。図１に示すように、ＲＦＩＤプラットフォームシステム１は、マスタプラットフォーム（マスタプラットフォーム装置）２（ＭＰＬＡＴ）、プラットフォーム（プラットフォーム装置）３（ＰＬＡＴ１〜２）、及びロガー（ロガー装置）４（ＬＯＧ１〜４）を備えている。

本実施形態において、ＲＦＩＤプラットフォームシステム１は、マスタプラットフォーム２であるＭＰＬＡＴの下位に、プラットフォーム３であるＰＬＡＴ１及びＰＬＡＴ２を備えている。また、ＰＬＡＴ１の下位には、ロガー４であるＬＯＧ１及びＬＯＧ２を備えており、ＰＬＡＴ２の下位には、ロガー４であるＬＯＧ３及びＬＯＧ４を備えている。このように、マスタプラットフォーム２、プラットフォーム３、及びロガー４は、階層構造を形成している。また、各ロガー４の下位には、それぞれ２つの子ロガー５が設けられている。子ロガー５は、それぞれに１対１で対応するＲＦタグリーダ６に接続されている。

マスタプラットフォーム２の下位にある２つのプラットフォーム３は、異なるサーバ８上で動作している。そして、各プラットフォーム３の下位のロガー４及び子ロガー５は、そのプラットフォーム３と同一のサーバ８上で動作している。また、マスタプラットフォーム２は、これら２つのプラットフォーム２とは異なるサーバ（不図示）上で動作している。すなわち、ＲＦＩＤプラットフォームシステム１は、ＰＬＡＴ１、ＬＯＧ１、ＬＯＧ２、ＬＯＧ１１、ＬＯＧ１２、ＬＯＧ２１及びＬＯＧ２２として機能する第１のサーバ８と、ＰＬＡＴ２、ＬＯＧ３、ＬＯＧ４、ＬＯＧ３１、ＬＯＧ３２、ＬＯＧ４１及びＬＯＧ４２として機能する第２のサーバ８と、ＭＰＬＡＴとして機能する第３のサーバとにより実現されている。

ＲＦＩＤプラットフォームシステム１は、各ＲＦタグ７の所在を管理するためのシステムである。ここで、ＲＦタグ７がどのＲＦＩＤリーダ６の近傍に存在しているのかを管理するとは、各ＲＦタグ７のタグＩＤと、そのＲＦタグ７を検出したＲＦタグリーダ６のリーダＩＤとの間に動的な関連付けを与えることを指す。

そして、本実施形態に係るＲＦＩＤプラットフォームシステム１は、管理すべきＲＦタグ７の所在を２つのプラットフォーム３で分担して管理する点に特徴がある。すなわち、管理すべきＲＦタグ７を第１のＲＦタグ群と第２のＲＦタグ群とに分け、第１のＲＦタグ群の所在を第１のプラットフォーム３（ＰＬＡＴ１）で管理し、第２のＲＦタグ群の所在を第２のプラットフォーム３（ＰＬＡＴ２）で管理する。

ＲＤＩＤプラットフォームシステム１において、各ＲＦタグ７の所在は、以下のように管理される。

すなわち、ＲＦタグリーダ６は、ＲＦタグ７との間で近距離無線通信が可能になると、そのＲＦタグ７からタグＩＤを取得することによって、そのＲＦタグ７を検出する。そして、ＲＦタグリーダ６は、ＲＦタグ７を検出すると、そのＲＦタグ７から取得したタグデータを、子ロガー５を介して上位のロガー４に送信する。ここで、ＲＦタグリーダ６から送信されるタグデータには、少なくとも検出されたＲＦタグ７のタグＩＤと、検出したＲＦタグリーダ６のリーダＩＤとが含まれる。

ロガー４は、自身の上位にあるプラットフォーム３で管理すべき全てのＲＦタグ７のタグＩＤを記憶しており、受信したタグデータに含まれるタグＩＤが自身の上位にあるプラットフォーム３が管理すべきＲＦタグ７のものであるか否かを判定することができる。そして、受信したタグデータに含まれるタグＩＤが自身の上位にあるプラットフォーム３で管理すべきＲＦタグ７のものである場合、ロガー４は、受信したタグデータを自身の上位にあるプラットフォーム３のデータベースに格納する。これは、従来のＲＦＩＤプラットフォームシステムと同様の処理である。一方で、受信したタグデータに含まれるタグＩＤが自身の上位にあるプラットフォーム３で管理すべきＲＦタグ７のものでない場合、このタグデータがいずれのプラットフォーム３で管理されるべきタグデータであるのかは、ロガー４にとって差し当たり不明である。

そこで、ロガー４は、受信したタグデータに含まれるタグＩＤが自身の上位にあるプラットフォーム３で管理すべきＲＦタグ７のものでない場合、タグデータを格納すべきプラットフォーム３をマスタプラットフォーム２に問い合わせる。ここで、ロガー４が送信する問い合わせには、タグＩＤ（ロガー４が受信したタグデータに含まれるタグＩＤ）が含まれている。ロガー４からの問い合わせを受けたマスタプラットフォーム２は、インデックスデータを参照して、自身の下位に存在する全てのプラットフォーム３（問い合わせのあったロガー４を関するプラットフォーム３以外）に、当該問い合わせをブロードキャストする。ここで、マスタプラットフォーム２が送信する問い合わせにも、タグＩＤ（ロガー４が受信したタグデータに含まれるタグＩＤ）が含まれている。なお、ロガー４がマスタプラットフォーム３に送信する問い合わせ、及び、マスタプラットフォーム３が各プラットフォーム２に送信する問い合わせは、例えば、問い合わせ言語（データベース言語を含む）におけるクエリとして実現することができる。

マスタプラットフォーム２からの問い合わせを受け付けた各プラットフォーム３は、当該問い合わせに含まれるタグＩＤと自身の管理すべきＲＦタグ７のタグＩＤとを比較し、一致する場合にはＩＰアドレスをマスタプラットフォーム２に送信することによって回答する。回答を受け付けたマスタプラットフォーム２は、プラットフォーム３から送信されたＩＰアドレスを、問い合わせのあったロガー４に送信することによって回答する。回答を受け付けたロガー４は、当該回答に基づいて、タグデータをプラットフォーム３に格納する。

このように、ＲＦＩＤプラットフォームシステム１は、複数のプラットフォーム３によって、複数のＲＦタグ７のタグデータを分担して管理し、それぞれのプラットフォーム３にＲＦタグ７のタグデータを格納するデータベースを設けている。このため、１つのサーバにアクセスが集中することがなく、パフォーマンスの低下を回避することができる。したがって、管理すべきＲＦタグ７及びＲＦタグリーダ６の台数が増加した場合でも、それに伴ってこれらを管理すべきプラットフォーム３の台数を増加させれば、１つのサーバにかかる負担を軽減することができる。

また、各プラットフォーム３を管理するマスタプラットフォーム２は、配下のプラットフォーム３のインデックスデータのみを有しているので、配下のプラットフォーム３の数が増加した場合でも、そのＩＰアドレスをインデックスデータに追加するだけでよい。したがって、大容量のデータベースを特に用いる必要がなく、拡張性に優れている。

なお、本実施形態において、ＲＦＩＤプラットフォームシステム１は、プラットフォーム３と、その下位のロガー４とを同一サーバにおいて動作させているが、サーバのパフォーマンスをさらに向上させるために、これらを異なるサーバにおいて動作させてもよい。また、マスタプラットフォーム２は、プラットフォーム３及びロガー４とは異なるサーバ上で動作させてもよいし、いずれかのプラットフォーム３と同一サーバ上で動作させてもよい。すなわち、複数のプラットフォーム３をそれぞれ異なるサーバ上で動作させていれば、他のブロックの動作場所は特に限定されない。

また、プラットフォーム３、ロガー４、及び子ロガー５の台数も特に限定されず、管理すべきＲＦタグリーダ６及びＲＦタグ７の台数に応じて適宜増加させてもよい。特に、プラットフォーム３にかかる負荷を分散させるために、１つのプラットフォーム３あたり複数のロガー４を動作させたり、他のプラットフォーム３よりも処理頻度が高いプラットフォーム３に対して、その下位のロガー４を他のプラットフォーム３の下位のロガー４よりも多数動作させたりする等、種々の運用形態にも対応できる。

（ロガー４の構成）
ロガー４の要部構成について、図２を参照して説明する。図２は、ロガー４の要部構成を示すブロック図である。図２に示すように、ロガー４は、マスタデータ取得部１１、マスタデータメモリ１２、キャッシュメモリ１３、タグデータ受信部１４、タグＩＤ判定部１５、タグＩＤ問合部（問合手段）１６、タグメモリ１７、及びタグデータ送信部（送信手段）１８を備えている。

以下、ロガー４の各部について説明する。なお、本実施形態においては、ＰＬＡＴ１が管理するＬＯＧ１を、ロガー４の例として説明する。

マスタデータ取得部１１は、上位のプラットフォーム３（本実施形態においてはＰＬＡＴ１）で管理されているＲＦタグ７のタグＩＤを取得するための手段である。マスタデータ取得部１１は、取得したタグＩＤをマスタデータとしてマスタデータメモリ１２に格納する。なお、マスタデータメモリ１２に格納されているタグＩＤを、以下では「マスタタグＩＤ」と呼称する。

タグデータ受信部１４は、ＲＦタグリーダ６（本実施形態においてはＲ１またはＲ２）がＲＦタグ７から取得したタグデータを受信するための手段である。タグデータ受信部１４で受信するタグデータは、ＲＦタグ７を検出したときにＲＦタグリーダ６から送信されるものであり、少なくとも、そのＲＦタグ７のタグＩＤと、そのＲＦタグリーダ６のリーダＩＤとを含んでいる。タグデータ受信部１４は、受信したタグデータをタグメモリ１７に格納すると共に、受信したタグデータに含まれるタグＩＤをタグＩＤ判定部１５に提供する。なお、タグメモリ１７には、自身を管理するプラットフォーム３のＩＰアドレス（ＰＬＡＴアドレス）が予め格納されている。

タグＩＤ判定部１５は、受信したタグデータが上位のプラットフォーム３（本実施形態においてはＰＬＡＴ１）で管理すべきＲＦタグ７に関するものであるか否かを判定するための手段である。具体的には、（１）タグデータ受信部１４から取得したタグＩＤをマスタデータメモリ１２に格納されている各マスタタグＩＤと比較し、（２−１）一致するマスタタグＩＤが存在する場合、そのタグデータは上位のプラットフォーム３で管理すべきＲＦタグ７に関するものであると判定し、（２−２）一致するマスタタグＩＤが存在しない場合、そのタグデータは上位のプラットフォーム３で管理すべきＲＦタグ７に関するものでないと判定する。タグＩＤ判定部１５は、この判定結果をタグデータ送信部１８に提供する。また、そのタグデータが上位のプラットフォーム３で管理すべきＲＦタグ７に関するものでないと判定した場合には、タグデータ受信部１４から取得したタグＩＤをタグＩＤ問合部１６に提供する。

タグＩＤ問合部１６は、受信したタグデータが上位のプラットフォーム３（本実施形態においてはＰＬＡＴ１）で管理すべきＲＦタグ７に関するものでない場合に、そのタグデータを管理しているプラットフォーム３（本実施形態においてはＰＬＡＴ２）のＩＰアドレスを、マスタプラットフォーム２に問い合わせるための手段である。具体的には、タグＩＤ判定部１５から取得したタグＩＤをマスタプラットフォーム２に送信し、その応答として、受信したタグデータを管理すべきプラットフォーム３のＩＰアドレスをマスタプラットフォーム２から受信する。そして、タグＩＤ問合部１６は、受信したＩＰアドレスをタグデータ送信部１８に提供する。本実施形態においては、マスタプラットフォーム２から受信するのは、ＰＬＡＴ２のＩＰアドレスとなる。

なお、本実施形態においては、タグＩＤ問合部におけるＩＰアドレスの問い合わせ処理を高速化するためにキャッシュを利用する構成を採用している。すなわち、タグＩＤを取得すると、タグＩＤ問合部１６は、まず、キャッシュメモリ１３からキャッシュデータ（キャッシュ情報）を読み出す。このキャッシュデータには、以前に検出されたＲＦタグ７に関するデータが含まれている。すなわち、キャッシュデータは、以前に検出されたＲＦタグ７のうち、ＰＬＡＴ１以外のプラットフォーム３が管理するＲＦタグ７のタグＩＤを、当該ＲＦタグ７を管理するプラットフォーム３のＩＰアドレスと関連付けて格納している。本実施形態においては、キャッシュデータに含まれるのは、ＰＬＡＴ２が管理するＲＦタグ７のタグＩＤと、これを管理するＰＬＡＴ２のＩＰアドレスとなる。

タグＩＤ問合部１６は、タグＩＤ判定部１５から取得したタグＩＤを、キャッシュデータに含まれるタグＩＤと比較して、一致するタグＩＤが存在するか否かを判断する。キャッシュデータに一致するタグＩＤが存在する場合、マスタプラットフォーム２への問い合わせは行わずに、キャッシュデータに含まれる当該タグＩＤに関連付けられたＩＰアドレスをタグデータ送信部１８に提供する。

なお、マスタプラットフォーム２からプラットフォーム３のＩＰアドレスを受信したとき、検出したＲＦタグ７のタグＩＤを、マスタプラットフォーム２から受信したＩＰアドレスに関連付けて、キャッシュメモリに格納する。このように更新したキャッシュデータは、次に同一のＲＦタグ７を検出したときに利用される。また、一定期間利用されなかったキャッシュデータは削除されるようになっている。

タグデータ送信部１８は、タグデータ受信部１４で受信したタグデータが上位のプラットフォーム３で管理すべきＲＦタグ７に関するタグデータである場合、そのタグデータを上位のプラットフォーム３のＩＰアドレス（本実施形態においてはＰＬＡＴ１のＩＰアドレス）宛に送信し、そうでない場合、そのタグデータをマスタプラットフォーム２から取得したＩＰアドレス（本実施形態においてはＰＬＡＴ２のＩＰアドレス）宛に送信するたの手段である。

具体的には、受信したタグデータが上位のプラットフォーム３で管理されているＲＦタグ７に関するものであるとの判定結果をタグＩＤ判定部１５から取得した場合、タグデータ送信部１８は、タグメモリ１７からタグデータと、上位のプラットフォーム３のＩＰアドレスとを読み出す。そして、タグデータ送信部１８は、タグメモリ１７から読み出したタグデータを、タグメモリ１７から読み出したＩＰアドレス宛に送信する。受信したタグデータが上位のプラットフォーム３で管理すべきＲＦタグ７に関するものでないとの判定結果をタグＩＤ判定部１５から取得した場合、タグデータ送信部１８は、タグメモリ１７からタグデータを読み出し、タグＩＤ問合部１６からＩＰアドレスを取得する。そして、タグデータ送信部１８は、タグメモリ１７から読み出したタグデータを、タグＩＤ問合部１６から取得したＩＰアドレス宛に送信する。

このようにロガー４は、ＲＦタグリーダ６から、検出したＲＦタグ７のタグデータを受信したとき、自身を管理するプラットフォーム３のマスタデータ、又は以前に検出したタグデータに関するキャッシュデータに基づいて、検出したＲＦタグ７のタグデータを格納するプラットフォーム３を判定する。そして、マスタデータ又はキャッシュデータに、検出したＲＦタグ７のタグデータを格納するプラットフォーム３の情報が含まれていない場合、プラットフォーム３を管理するマスタプラットフォーム２に対して、当該ＲＦタグ７のタグデータを格納するプラットフォーム３を問い合わせる。

これにより、タグデータを格納するデータベースが複数のサーバに分散していても、タグデータを正確に格納することができる。また、マスタデータの参照、キャッシュデータの参照、及びマスタプラットフォーム２への問い合わせを組み合わせてタグデータの格納先を取得することによって、タグデータの格納処理時間を短縮することができる。

（プラットフォーム３の構成）
プラットフォーム３の要部構成について、図３を参照して説明する。図３は、プラットフォーム３の要部構成を示すブロック図である。図３に示すように、プラットフォーム３は、タグデータ受信部２１、抽象データベース２２、マスタデータベース２３、タグデータ問合判定部（回答手段）２４、及びタグＩＤ問合部２５を備えている。

以下、プラットフォーム３によるタグデータの格納処理の概要について説明する。なお、本実施形態においては、ＰＬＡＴ１のタグデータ格納処理を、プラットフォーム３の処理例として説明する。

タグデータ受信部２１は、ロガー４から送信されたタグデータを受信し、抽象データベース２２に格納する。抽象データベースには、子ロガー５を介してロガー４にタグデータを送信するＲＦタグリーダ６に固有の識別情報（リーダＩＤ）と、当該ＲＦタグリーダ６により検出されたＲＦタグ７のタグＩＤとに関連付けて、ＲＦタグ７の検出履歴を表すタグデータが格納される。

マスタデータベース２３は、ＰＬＡＴ１が管理すべきＲＦタグ７に関する情報を含むマスタデータを、ＬＯＧ１のマスタデータ取得部１１に送信する。また、マスタデータベース２３は、タグデータ問合判定部２４に、当該マスタデータに含まれるマスタＩＤを送信する。マスタデータベース２３には、後述するタグ管理テーブル及びタグリーダ管理テーブルが格納されている。

タグＩＤ問合部２５は、マスタプラットフォーム２から、検出したＲＦタグ７のタグＩＤをマスタデータに含むか否かの問い合わせを受け付け、受信したタグＩＤをタグデータ問合判定部２４に送信する。タグＩＤを受信したタグデータ問合判定部２４は、マスタデータベース２３からマスタＩＤを取得して、マスタＩＤにタグＩＤが含まれるか否かを判定し、判定結果をタグＩＤ問合部２５に送信する。タグＩＤ問合部２５は、受信した判定結果をマスタプラットフォーム２に送信する。

このように、プラットフォーム３は、自身が管理するＲＦタグ７が検出された場合のみタグデータの格納処理を行い、他のＲＦタグ７が検出された場合には、タグデータの格納処理を行う必要がない。したがって、１つのプラットフォーム３にアクセスが集中することがなく、パフォーマンスの低下を回避することができる。

（マスタプラットフォーム２の構成）
マスタプラットフォーム２の要部構成について、図４を参照して説明する。図４は、マスタプラットフォーム２の要部構成を示すブロック図である。図４に示すように、マスタプラットフォーム２は、タグＩＤ問合部（回答手段）３１、ＰＬＡＴアドレスデータベース３２、及びＰＬＡＴ問合部３３を備えている。

以下、プラットフォーム３からの問い合わせに対する、マスタプラットフォーム２における応答処理の概要について説明する。なお、本実施形態においては、ＬＯＧ１からの問い合わせに対する応答処理を、マスタプラットフォーム２の処理例として説明する。

タグＩＤ問合部３１は、ＬＯＧ１から、検出したＲＦタグ７のタグデータを格納するプラットフォーム３の問い合わせを受け付けると、当該問い合わせに含まれる、ＲＦタグ７のタグＩＤをＰＬＡＴ問合部３３に提供する。タグＩＤを取得したＰＬＡＴ問合部３３は、ＰＬＡＴアドレスデータベース３２から、マスタプラットフォーム２が管理する全てのプラットフォーム３のＩＰアドレスを取得する。ＰＬＡＴアドレスデータベース３２には、マスタプラットフォーム２が管理する全てのプラットフォーム３のＩＰアドレスを含むインデックスデータテーブルが格納されている。

ＰＬＡＴ問合部３３は、ＰＬＡＴアドレスデータベース３２から取得した全てのＩＰアドレス宛に、ＬＯＧ１からの問い合わせに含まれるタグＩＤを送信し、当該タグＩＤをマスタデータに含むか否かを問い合わせる。ただし、問い合わせのあったＬＯＧ１を管理するＰＬＡＴ１には、この問い合わせをする必要はない。問い合わせを受けた各プラットフォーム３は、マスタプラットフォーム２から受信したタグＩＤが、自装置で管理するＲＦタグ７のタグＩＤであれば（受信したタグＩＤがマスタデータに含まれるタグＩＤであれば）、自装置のＩＰアドレスをマスタプラットフォーム２に回答する。そして、ＰＬＡＴ問合部３３は、問い合わせの対象になっているＲＦタグ７を管理するプラットフォーム３からの回答を受信すると、当該プラットフォーム３のＩＰアドレスをＰＬＡＴアドレスとして、タグＩＤ問合部３１に提供する。タグＩＤ問合部３１は、取得したＰＬＡＴアドレスをＬＯＧ１に送信する。

このように、マスタプラットフォーム２は、ロガー４からの問い合わせをロガー４からの問い合わせを配下のプラットフォーム３に転送するのみで、自身でタグデータの格納処理や格納先の検索処理を行わない。すなわち、自身が管理するプラットフォーム３のＩＰアドレスのみをインデックスデータとして管理し、他のマスタデータは有していない。したがって、配下のプラットフォーム３、ロガー４及びＲＦタグリーダ６の台数が増加したとしても、プラットフォーム３のＩＰアドレスを追加するだけでよく、大容量のデータベースは必要なく、拡張性に優れている。

（マスタデータベース２３内のテーブル例）
プラットフォーム３が備えたマスタデータベース２３には、プラットフォーム３自身が管理するＲＦタグ７及びＲＦタグリーダ６のマスタデータが格納されている。すなわち、自身の抽象データベース２２にタグデータを格納するＲＦタグ７、及びこれを検出するＲＦタグリーダ６に関するマスタデータが格納されている。このマスタデータは、ロガー４のマスタデータ取得部１１又はプラットフォーム３のタグデータ問合判定部２４によって引き出されて、タグデータの管理に利用される。

マスタデータベース２３内に格納されるテーブルの例を、図５及び６に示す。図５は、タグ管理テーブルを示す図であり、図６は、タグリーダ管理テーブルを示す図である。なお、マスタデータベース２３内には、これらのテーブルに限らず、ＲＦＩＤプラットフォームシステム１内の各ブロックが所定の処理を実行する際に必要とする各種テーブルを格納しておくことができる。

（タグ管理テーブル）
図５に示すタグ管理テーブルは、ＲＦタグ７に固有の識別情報（タグＩＤ）と、当該ＲＦタグ７を所持するユーザの氏名情報とを関連付けて格納している。タグＩＤは、ＲＦタグ７ごとに一意に割り当てられた識別情報（本実施形態では整数）である。すなわち各ユーザは一意のタグＩＤが割り当てられたＲＦタグ７を所持する。

したがって、ロガー４は、ＲＦタグリーダ６から送信された無線信号に含まれるタグＩＤの値を用いて、タグ管理テーブルから取得したマスタデータを参照すれば、ＲＦタグリーダ６が検出したＲＦタグ７のタグデータを、自身を管理するプラットフォーム３に格納するか否かを判定することができる。

（タグリーダ管理テーブル）
図６に示すタグリーダ管理テーブルは、ＲＦタグリーダ６に固有の識別情報（リーダＩＤ）と、当該ＲＦタグリーダ６の設置場所を示す情報とを関連付けて格納している。このリーダＩＤは、ＲＦタグリーダ６ごとに一意に割り当てられた識別情報（本実施形態では整数）である。また、ＲＦタグリーダ６は、ＲＦタグ７の検出結果を含む信号をロガー４に送信する際、自身に割り当てられた一意のリーダＩＤを当該信号に含めている。

すなわち、ＲＦタグリーダ６が出力する信号において、検出されたＲＦタグ７のタグＩＤと、当該ＲＦタグリーダ６のリーダＩＤとが互いに関連付けられている。そして、ロガー４は、ＲＦタグリーダ６が検出したＲＦタグ７の検出結果を、検出したＲＦタグリーダ６のリーダＩＤと関連付けて、プラットフォーム３に格納する。

（抽象データベース２２内のテーブル例）
プラットフォーム３が備えた抽象データベース２２には、ＲＦタグリーダ６によるＲＦタグ７の検出情報又は非検出情報を表す履歴データ（抽象データ）が格納される。抽象データはタグデータとして、ロガー４のタグデータ送信部１８からプラットフォーム３のタグデータ受信部２１に送信され、タグデータ受信部２１により抽象データベース２２に格納される。

抽象データベース２２に格納される抽象データ管理テーブルの例を、図７に示す。図７は、抽象データ管理テーブルを示す図である。なお、抽象データベース２２内には、このテーブルに限らず、ＲＦＩＤプラットフォームシステム１内の各ブロックが所定の処理を実行する際に必要とする各種テーブルを格納しておくことができる。

図７に示す抽象データ管理テーブルは、ＲＦタグ７のタグＩＤと、そのＲＦタグ７を検出したＲＦタグリーダ６のリーダＩＤと、そのＲＦタグ７の検出開始時間と、そのＲＦタグ７の検出終了時間と、そのＲＦタグ７の検出状態を示す情報とを、互いに関連付けて格納している。

各ＲＦタグリーダ６は、一定の時間が経過するたびに、ＲＦタグ７の検出結果を含む信号を、子ロガー５を介してＲＦＩＤプラットフォームシステム１に送信する。子ロガー５において受信された信号は、当該子ロガー５を管理するロガー４に送られる。ロガー４は、受信した信号を解析することによって、ある時刻において、ＲＦタグ７がＲＦタグリーダ６によって検出されたか否かを示すレコード情報を生成し、プラットフォーム３に保存する。したがって、プラットフォーム３には、一定の時間が経過するたびに、プラットフォーム３において管理されている全ＲＦタグ７を対象に、ある時刻において、ＲＦタグ７が検出されたか否かを示すデータが格納されていく。

なお、本実施形態では、ＲＦタグリーダ６が自ら時間をカウントし、規定の時間が経過した時点で、ＲＦタグ７の検出処理を開始する。そして、検出処理の終了後、ＲＦタグ７の検出結果を含む無線信号を、子ロガー５を介してロガー４に送信する。一方、ロガー４は、ＲＦタグリーダ６から送られてくる信号を受動的に処理することによって、上記規定の時間が経過するたびにタグデータを蓄積させていく。

逆に、ロガー４のタグデータ受信部１４が能動的に自ら時間をカウントし、規定の時間が経過した時点で、各ＲＦタグリーダ６に、ＲＦタグ７の検出を指示する信号を送信してもよい。この場合、各ＲＦタグリーダ６は当該指示信号を受信したら直ちにＲＦタグ７の検出処理を開始する。

（抽象データ管理テーブルへのデータ蓄積）
ロガー４は、検出したＲＦタグ７の検出履歴を表すタグデータを解析することによって、プラットフォーム３にＲＦタグ７の検出履歴を格納していく。具体的には、プラットフォーム３の抽象データベース２２内の抽象データ管理テーブルにおいて、ＲＦタグ７が非検出状態になっているときに、当該ＲＦタグ７が検出されれば、当該ＲＦタグ７の検出履歴を示すレコードを１つ生成し、抽象データ管理テーブルに蓄積する。

本実施形態では、ロガー４は、検出履歴の蓄積処理を、新たなタグデータを検出するたびに行う。なお、一定数のタグデータを検出した時点において、検出履歴の格納処理をまとめて行うことも可能である。

図７を例に、抽象データ管理テーブルにレコードが蓄積されていく流れを説明する。まず初期状態では抽象データ管理テーブルに何のレコードも格納されていないので、いずれのＲＦタグ７の検出状態も「非検出」である。ここで、ロガー４が、時刻「１１：１１：１０」において、「０００１」のリーダＩＤが割り当てられたＲＦタグリーダ６から、「０００１」のタグＩＤが割り当てられたＲＦタグ７を検出したことを示す生データを受信したとする。

このときロガー４は、当該生データを処理することによって、当該ＲＦタグ７が非検出状態から検出状態に変化したと判定する。この結果、第１行目のレコードを抽象データ管理テーブルに生成する。具体的には、検出されたＲＦタグ７のタグＩＤ、当該ＲＦタグ７を検出したＲＦタグリーダ６のリーダＩＤ、当該ＲＦタグ７が検出された時間（タグ検出開始時間）、および検出状態を示す情報（ここでは「検出」）を互いに関連付けたレコードを生成する。なお、ＲＦタグ７の検出はまだ終わっていないので、タグ検出終了時間は空白（データなし）である。

これ以降、ロガー４は、「０００１」のタグＩＤが割り当てられたＲＦタグ７を検出していることを示す信号を、「０００１」のリーダＩＤが割り当てられたＲＦタグリーダ６から定期的に受信している。すなわち、ＲＦタグ７の検出は終了せずに継続している。したがって、抽象データ管理テーブルの１行目のレコードはそのままの状態で変化させない。

ここで、ロガー４が、時刻「０１：０１：００」において、「０００２」のリーダＩＤが割り当てられたＲＦタグリーダ６から、「０００２」のタグＩＤが割り当てられたＲＦタグ７を検出したことを示す生データを受信したとする。ロガー４は、当該生データを処理することによって、当該ＲＦタグ７が非検出状態から検出状態に変化したと判定する。その結果、第２行目のレコードを抽象データ管理テーブルに生成する。このとき、検出されたＲＦタグ７のタグＩＤ、当該ＲＦタグ７を検出したＲＦタグリーダ６のリーダＩＤ、当該ＲＦタグ７が検出された時間（タグ検出開始時間）、および検出状態を示す情報（ここでは「検出」）を互いに関連付けたレコードを生成する。なお、ＲＦタグ７の検出はまだ終わっていないので、タグ検出終了時間は空白（データなし）である。

なお、ロガー４は、「０００１」のタグＩＤが割り当てられたＲＦタグ７を検出していることを示す信号を、「０００１」のリーダＩＤが割り当てられたＲＦタグリーダ６から、依然として定期的に受信している。すなわち、当該ＲＦタグ７の検出は終了せずに継続している。したがって、抽出データ管理テーブルの１行目のレコードは依然としてそのままの状態で変化させない。

次に、ロガー４が、時刻「０１：０１：０１」において、「０００２」のリーダＩＤが割り当てられたＲＦタグリーダ６から、「０００２」のタグＩＤが割り当てられたＲＦタグ７を検出したことを示す信号を受信しなかったとする。このときロガー４は、当該ＲＦタグ７が当該時刻において検出されなかったことを示す生データを抽象データ管理テーブルに格納する。ロガー４は、当該生データを処理することによって、当該ＲＦタグ７の検出が終了したと判定し、第２行のレコードにおいて、タグ検出終了時間の欄に、時刻「０１：０１：０１」を書き込み、さらに、同レコードの検出状態欄を「検出」から「非検出」に変更する。これらの処理によって、当該ＲＦタグ７の検出履歴を示すデータ（レコード）が閉じられる。すなわち、当該第２行目のレコードは抽象データ管理テーブル内に履歴として残り、これ以上、その内容が変化することはない。

次に、ロガー４が、時刻「０１：０１：１０」において、「０００２」のリーダＩＤが割り当てられたＲＦタグリーダ６から、「０００２」のタグＩＤが割り当てられたＲＦタグ７を検出したことを示す生データを受信したとする。このときロガー４は、当該生データを処理することによって、検出されたＲＦタグ７のタグＩＤを特定する。そして、抽出データ管理テーブルに記録されたレコードのうち、特定した「０００２」のタグＩＤが記憶されている最新のレコードを検索する。そして、検索したレコードにおける検出状態欄の値を取得する。

図７の例では、このときロガー４は第２行目のレコードを検出し、検出状態欄の値として「非検出」を取得する。したがって、ロガー４は、「０００２」のタグＩＤが割り当てられたＲＦタグ７が、新たに非検出状態から検出状態に変化したと判定する。これにより、抽出データ管理テーブルに新たなレコードとして第３行目のレコードを生成する。具体的には、検出されたＲＦタグ７のタグＩＤ、当該ＲＦタグ７を検出したＲＦタグリーダ６のリーダＩＤ、当該ＲＦタグ７が検出された時間（タグ検出開始時間）、および検出状態を示す情報（ここでは「検出」）を互いに関連付けたレコードを生成する。なお、ＲＦタグ７の検出はまだ終わっていないので、タグ検出終了時間は空白（データなし）である。

上記の手順を繰り返すことによって、ロガー４は、抽象データ管理テーブルにレコードを蓄積させていく。図７の例では、第３行までのレコードが蓄積されており、各レコードはいずれかのＲＦタグ７の検出履歴を示している。すなわち、図７の例では、「０００１」のタグＩＤが割り当てられたＲＦタグ７、および「０００２」のタグＩＤが割り当てられたＲＦタグ７は、タグの検出が開始されてから、現時点（ロガー４がタグ抽象データ管理テーブルを参照する最新の時点）に至るまで、ずっと検出され続けている。なお、「０００２」のタグＩＤが割り当てられたＲＦタグ７は、以前に一度、検出が完了しているので、その履歴が抽象データ管理テーブルに残っている（第２行のレコード）。

（ＰＬＡＴアドレスデータベース３２内のテーブル例）
マスタプラットフォーム２のＰＬＡＴアドレスデータベース３２には、マスタプラットフォーム２が管理する全てのプラットフォーム３のＩＰアドレスを含むインデックスデータが格納されている。このインデックスデータは、ＰＬＡＴ問合部３３によって引き出されて、検出したＲＦタグ７を管理するプラットフォーム３の問い合わせに利用される。

ＰＬＡＴアドレスデータベース３２内に格納されるインデックスデータ管理テーブルの例を、図８に示す。図８は、インデックスデータ管理テーブルを示す図である。なお、ＰＬＡＴアドレスデータベース３２内には、これらのテーブルに限らず、ＲＦＩＤプラットフォームシステム１内の各ブロックが所定の処理を実行する際に必要とする各種テーブルを格納しておくことができる。

図８に示すインデックスデータ管理テーブルは、マスタプラットフォーム２が管理する全てのプラットフォーム３のＩＰアドレスを格納している。したがって、マスタプラットフォーム２は、ロガー４から問い合わせを受け付けたとき、当該インデックスデータ管理テーブルにＩＰアドレスが含まれる全てのプラットフォーム３に対して、ＲＦタグリーダ６が検出したＲＦタグ７のタグＩＤの値を送信して、当該タグＩＤをマスタデータに含むプラットフォーム３を問い合わせることができる。

（キャッシュメモリ１３内のテーブル例）
ロガー４のキャッシュメモリ１３には、ロガー４がＲＦタグリーダ６から最近受信した、ＲＦタグ７を管理するプラットフォーム３に関する情報が格納されている。すなわち、キャッシュメモリ１３は、最近検出されたＲＦタグ７の検出データを格納するプラットフォーム３のＩＰアドレスを、当該ＲＦタグ７のタグＩＤと関連付けてキャッシュデータとして格納している。このキャッシュデータは、タグＩＤ問合部１６において利用される。

キャッシュメモリ１３内に格納されるキャッシュデータテーブルの例を、図９に示す。図９は、キャッシュデータテーブルを示す図である。図９に示すキャッシュデータテーブルは、ロガー４の配下のＲＦタグリーダ６において、最近検出したＲＦタグ７のタグＩＤと、当該ＲＦタグ７の検出データを蓄積したプラットフォーム３のＩＰアドレスとを関連付けて格納している。

ロガー４のタグＩＤ問合部１６は、マスタプラットフォーム２からＲＦタグ７のタグデータを格納するプラットフォーム３のＩＰアドレスを取得すると、キャッシュデータテーブルを更新し、ＲＦタグ７のタグＩＤと当該ＲＦタグ７を管理するプラットフォーム３のＩＰアドレスとを関連付けた新たなキャッシュデータを追加する。追加されたデータは、次に同一のＲＦタグ７を検出したときに利用される。また、一定期間利用されなかったキャッシュデータは削除される。

（実施形態２）
本発明の第２の実施形態について、図１０に基づいて説明すれば以下のとおりである。本実施形態に係るＲＦＩＤプラットフォームシステム１００について、図１０を参照して説明する。図１０は、本実施形態に係るＲＦＩＤプラットフォームシステム１００の全体構成を示す図である。図１０に示すように、ＲＦＩＤプラットフォームシステム１００は、２つのマスタプラットフォーム１０２を備え、これらのマスタプラットフォーム１０２のさらに上位に、マスタプラットフォーム１０２を管理する上位マスタプラットフォーム１０１を備えている点において、実施形態１のＲＦＩＤプラットフォームシステム１と異なっている。本実施形態においては、実施形態１と異なる点について説明し、他の詳細については省略する。

本実施形態において、ＲＦＩＤプラットフォームシステム１００は、上位マスタプラットフォーム（ＭＰＬＡＴ１）１０１の下位に、２つのマスタプラットフォーム（ＭＰＬＡＴ１１及びＭＰＬＡＴ１２）１０２を備えている。そして、ＭＰＬＡＴ１１の下位には、２つのプラットフォーム（ＰＬＡＴ１及びＰＬＡＴ２）１０３を備えており、ＭＰＬＡＴ１２の下位にはプラットフォーム（ＰＬＡＴ３）１０３を備えている。ＰＬＡＴ１の下位構造は、実施形態１のＲＦＩＤプラットフォームシステム１と同様である。

ＰＬＡＴ２は、その下位に２つのロガー（ＬＯＧ３及びＬＯＧ４）１０４を備えており、ＬＯＧ３は２つの子ロガー（ＬＯＧ３１及びＬＯＧ３２）１０５を、ＬＯＧ４は１つの子ロガー（ＬＯＧ４１）１０５を、それぞれの下位に備えている。ＰＬＡＴ３は、その下位に３つのロガー（ＬＯＧ５、ＬＯＧ６及びＬＯＧ７）１０４を備えている。ＬＯＧ５は２つの子ロガー（ＬＯＧ５１及びＬＯＧ５２）１０５を、ＬＯＧ６は１つの子ロガー（ＬＯＧ６１）１０５を、ＬＯＧ７は１つの子ロガー（ＬＯＧ７１）１０５を、それぞれの下位に備えている。

各子ロガー１０５は、それぞれに１対１で対応するＲＦタグリーダ１０６に接続されている。マスタプラットフォーム１０２の下位にある３つのプラットフォーム１０３はそれぞれ、異なるサーバ１０８上で動作している。そして、各プラットフォーム１０３の下位のロガー１０４及び子ロガー１０５は、自身を管理するプラットフォーム１０３と同一のサーバ１０８上で動作している。また、２つのマスタプラットフォーム１０２は、その下位にある何れか１つのプラットフォーム１０３と同一のサーバ１０８、又は、これらのサーバ１０８とは異なるサーバ上で動作している。

上位マスタプラットフォーム１０１は、自身が管理する全てのマスタプラットフォーム１０２のＩＰアドレスを、マスタプラットフォーム１０２を識別するインデックスデータ（マスタプラットフォーム識別情報）として有している。ロガー１０４から、ＲＦタグ１０７のタグデータを格納するプラットフォーム１０３の問い合わせを受け付けたマスタプラットフォーム１０２は、自身が管理する全てのプラットフォーム３のマスタデータに当該ＲＦタグ１０７のタグＩＤが見つからなかった場合、上位マスタプラットフォーム１０１に、当該ＲＦタグ１０７のタグデータを格納するプラットフォーム１０３を問い合わせる。

問い合わせを受け付けた上位マスタプラットフォーム１０１は、インデックスデータを参照して、問い合わせのあったマスタプラットフォーム１０２以外の全てのマスタプラットフォーム１０２に、当該ＲＦタグ１０７の検出データを格納するプラットフォーム１０３を問い合わせる。問い合わせを受け付けたマスタプラットフォーム１０２は、自身が管理するプラットフォーム１０３に、当該ＲＦタグ１０７のタグＩＤをマスタデータに含むか否かを問い合わせる。このような問い合わせを繰り返すことによって、検出したＲＦタグ１０７のタグデータの格納先を取得することができる。

このように、ＲＦＩＤプラットフォームシステム１００は、マスタプラットフォーム１０２の台数を増加させ、これらのマスタプラットフォーム１０２の上位に、これらを管理する上位マスタプラットフォーム１０１を備えているので、管理するＲＦタグリーダ１０６及びＲＦタグ１０７の台数がさらに増加しても、１つのマスタプラットフォーム１０２に処理を集中させることがなく、パフォーマンスの低下を回避することができる。また、管理するＲＦタグリーダ１０６及びＲＦタグ１０７の台数がさらに増加しても、これらを管理するプラットフォーム１０３を増加させ、さらにマスタプラットフォーム１０２や上位マスタプラットフォーム１０１を増加させて階層を増やすことによって、対応することができる。

〔プログラム及び記録媒体〕
ＲＦＩＤプラットフォームシステム１に含まれている各ブロックは、ハードウェアロジックによって構成すればよい。または、次のように、ＣＰＵ（Ｃｅｎｔｒａｌ Ｐｒｏｃｅｓｓｉｎｇ Ｕｎｉｔ）を用いてソフトウェアによって実現してもよい。

すなわち、ＲＦＩＤプラットフォームシステム１を構成する各機器は、各機能を実現するプログラムの命令を実行するＣＰＵ、このプログラムを格納したＲＯＭ（Ｒｅａｄ Ｏｎｌｙ Ｍｅｍｏｒｙ）、上記プログラムを実行可能な形式に展開するＲＡＭ（Ｒａｎｄｏｍ Ａｃｃｅｓｓ Ｍｅｍｏｒｙ）、および、上記プログラムおよび各種データを格納するメモリ等の記憶装置（記録媒体）を備えている。この構成により、本発明の目的は、所定の記録媒体によっても、達成できる。

この記録媒体は、上述した機能を実現するソフトウェアであるＲＦＩＤプラットフォームシステム１のプログラムのプログラムコード（実行形式プログラム、中間コードプログラム、ソースプログラム）をコンピュータで読み取り可能に記録していればよい。ＲＦＩＤプラットフォームシステム１に、この記録媒体を供給する。これにより、コンピュータとしてのＲＦＩＤプラットフォームシステム１（またはＣＰＵやＭＰＵ）が、供給された記録媒体に記録されているプログラムコードを読み出し、実行すればよい。

プログラムコードをＲＦＩＤプラットフォームシステム１を構成する各機器に供給する記録媒体は、特定の構造または種類のものに限定されない。すなわちこの記録媒体は、たとえば、磁気テープやカセットテープ等のテープ系、フロッピー（登録商標）ディスク／ハードディスク等の磁気ディスクやＣＤ−ＲＯＭ／ＭＯ／ＭＤ／ＤＶＤ／ＣＤ−Ｒ等の光ディスクを含むディスク系、ＩＣカード（メモリカードを含む）／光カード等のカード系、あるいはマスクＲＯＭ／ＥＰＲＯＭ／ＥＥＰＲＯＭ／フラッシュＲＯＭ等の半導体メモリ系などとすることができる。

また、ＲＦＩＤプラットフォームシステム１を構成する各機器を通信ネットワークと接続可能に構成しても、本発明の目的を達成できる。この場合、上記のプログラムコードを、通信ネットワークを介してＲＦＩＤプラットフォームシステム１を構成する各機器に供給する。この通信ネットワークはＲＦＩＤプラットフォームシステム１を構成する各機器にプログラムコードを供給できるものであればよく、特定の種類または形態に限定されない。たとえばインターネット、イントラネット、エキストラネット、ＬＡＮ、ＩＳＤＮ、ＶＡＮ、ＣＡＴＶ通信網、仮想専用網（Ｖｉｒｔｕａｌ Ｐｒｉｖａｔｅ Ｎｅｔｗｏｒｋ）、電話回線網、移動体通信網、衛星通信網等であればよい。

この通信ネットワークを構成する伝送媒体も、プログラムコードを伝送可能な任意の媒体であればよく、特定の構成または種類のものに限定されない。たとえばＩＥＥＥ１３９４、ＵＳＢ（Ｕｎｉｖｅｒｓａｌ Ｓｅｒｉａｌ Ｂｕｓ）、電力線搬送、ケーブルＴＶ回線、電話線、ＡＤＳＬ（Ａｓｙｍｍｅｔｒｉｃ Ｄｉｇｉｔａｌ Ｓｕｂｓｃｒｉｂｅｒ Ｌｉｎｅ）回線等の有線でも、ＩｒＤＡやリモコンのような赤外線、Ｂｌｕｅｔｏｏｔｈ（登録商標）、８０２．１１無線、ＨＤＲ、携帯電話網、衛星回線、地上波デジタル網等の無線でも利用可能である。なお本発明は、上記プログラムコードが電子的な伝送で具現化された、搬送波に埋め込まれたコンピュータデータ信号の形態でも実現され得る。

本発明は上述した各実施形態に限定されるものではなく、請求項に示した範囲で種々の変更が可能であり、異なる実施形態にそれぞれ開示された技術的手段を適宜組み合わせて得られる実施形態についても本発明の技術的範囲に含まれる。

本発明は、ＲＦＩＤシステムとして、幅広く利用することができる。

１ ＲＦＩＤプラットフォームシステム
２ マスタプラットフォーム
３ プラットフォーム
４ ロガー
５ 子ロガー
６ ＲＦタグリーダ
７ ＲＦタグ

Claims (6)

1. 異なるＲＦタグ群を管理する複数のプラットフォーム装置と、
   上記複数のプラットフォーム装置のアドレスを管理するマスタプラットフォーム装置と、
   上記複数のプラットフォーム装置の何れかに対応するロガー装置であって、ＲＦタグが対応プラットフォーム装置で管理するＲＦタグ群に含まれる場合、上記ＲＦタグから読み出したタグデータを上記対応プラットフォーム装置に送信するロガー装置とを含み、
   上記ロガー装置は、上記ＲＦタグが上記対応プラットフォーム装置で管理するＲＦタグ群に含まれない場合、上記ＲＦタグを管理するプラットフォーム装置のアドレスを上記マスタプラットフォーム装置に問い合わせ、
   上記マスタプラットフォーム装置は、上記複数のプラットフォーム装置の各々に上記ＲＦタグを管理するプラットフォーム装置であるかを問い合わせ、上記ＲＦタグを管理するプラットフォーム装置であると回答したプラットフォーム装置のアドレスを上記ロガー装置に回答し、
   上記ロガー装置は、上記ＲＦタグが上記対応プラットフォーム装置で管理するＲＦタグ群に含まれない場合、上記ＲＦタグから読み出したタグデータを、上記マスタプラットフォーム装置から回答されたアドレス宛てに送信する、ことを特徴とするＲＦＩＤプラットフォームシステム。
2. 上記ロガー装置は、上記ＲＦタグのタグＩＤを上記マスタプラットフォーム装置に送信することによって、上記マスタプラットフォーム装置に問い合わせるものであり、
   上記マスタプラットフォーム装置は、上記ＲＦタグのタグＩＤを上記複数のプラットフォーム装置の各々に送信することによって、上記複数のプラットフォーム装置の各々に問い合わせるものであり、
   上記複数のプラットフォーム装置の各々は、自身の管理するＲＦタグのタグＩＤを格納したデータベースを有しており、上記マスタプラットフォーム装置から送信された上記ＲＦタグのタグＩＤが当該データベースに格納されているか否かを判定し、上記ＲＦタグのタグＩＤが上記データベースに格納されていると判定した場合、自身のアドレスを上記マスタプラットフォーム装置に送信することによって、上記マスタプラットフォーム装置に回答し、
   上記マスタプラットフォーム装置は、上記ＲＦタグを管理するプラットフォーム装置であると回答したプラットフォーム装置のアドレスを上記ロガー装置に送信することによって、上記ロガー装置に回答する、
   ことを特徴とする請求項１に記載のＲＦＩＤプラットフォームシステム。
3. 上記ロガー装置は、ＲＦタグのタグＩＤと、該ＲＦタグから読み出したタグデータを送信した送信先アドレスとを関連付けて記憶するキャッシュを備えており、新たなＲＦタグが上記対応プラットフォーム装置で管理するＲＦタグ群に含まれない場合に、該新たなＲＦタグから読み出したタグデータを送信する送信先アドレスを、上記キャッシュにおいて該新たなＲＦタグのタグＩＤに関連付けられた送信先アドレスに設定する、
   ことを特徴とする請求項１又は２に記載のＲＦＩＤプラットフォームシステム。
4. 請求項１から３までの何れか１項に記載のＲＦＩＤプラットフォームシステムを複数含み、更に、各ＲＦＩＤプラットフォームシステムに含まれるマスタプラットフォーム装置のアドレスを管理する上位マスタプラットフォーム装置を含んでいる、
   ことを特徴とするＲＦＩＤプラットフォームシステム。
5. ＲＦタグ群を管理するプラットフォーム装置に対応するロガー装置であって、
   ＲＦタグが上記ＲＦタグ群に含まれない場合、上記ＲＦタグを管理するプラットフォーム装置のアドレスを、上記プラットフォーム装置を含む複数のプラットフォーム装置のア
   ドレスを管理するマスタプラットフォーム装置に問い合わせる問合手段と、
   上記ＲＦタグが上記ＲＦタグ群に含まれる場合、上記ＲＦタグから読み出したタグデータを、上記プラットフォーム装置に送信し、上記ＲＦタグが上記ＲＦタグ群に含まれない場合、上記ＲＦタグから読み出したタグデータを、上記問い合わせに対して上記マスタプラットフォーム装置が回答したアドレス宛てに送信する送信手段と、を備えている、
   ことを特徴とするロガー装置。
6. 異なるＲＦタグ群を管理する複数のプラットフォーム装置と、上記複数のプラットフォーム装置のアドレスを管理するマスタプラットフォーム装置と、上記複数のプラットフォーム装置の何れかに対応するロガー装置とを用いてＲＦタグから読み出したタグデータを管理する管理方法であって、
   上記ＲＦタグが対応プラットフォーム装置で管理するＲＦタグ群に含まれる場合、上記ロガー装置が、上記ＲＦタグから読み出したタグデータを上記対応プラットフォーム装置に送信するステップと、
   上記ＲＦタグが上記対応プラットフォーム装置で管理するＲＦタグ群に含まれない場合、上記ロガー装置が、上記ＲＦタグを管理するプラットフォーム装置のアドレスを上記マスタプラットフォーム装置に問い合わせるステップと、
   上記マスタプラットフォーム装置が、上記複数のプラットフォーム装置の各々に上記ＲＦタグを管理するプラットフォーム装置であるかを問い合わせ、上記ＲＦタグを管理するプラットフォーム装置であると回答したプラットフォーム装置のアドレスを上記ロガー装置に回答するステップと、
   上記ＲＦタグが上記対応プラットフォーム装置で管理するＲＦタグ群に含まれない場合、上記ロガー装置が、上記ＲＦタグから読み出したタグデータを、上記問い合わせに対して上記マスタプラットフォーム装置から回答されたアドレス宛てに送信するステップと、を含むことを特徴とする管理方法。

Images