JP2007066299A - 組織体における組織間での資産追跡 - Google Patents

Abstract

【課題】ａｕｔｏ−ｉｄノードのネットワークおよびプロセッサを含むシステムを提供すること。
【解決手段】システムはａｕｔｏ−ｉｄノードとプロセッサのネットワークを含む。各ａｕｔｏ−ｉｄノードは、そのａｕｔｏ−ｉｄノードとネットワーク内の別のａｕｔｏ−ｉｄノードの間の階層関係を定義するインデックスデータを含み、ａｕｔｏ−ｉｄノードは、そのａｕｔｏ−ｉｄノードによって読み取られた１つまたは複数の資産についての状態データおよび履歴データを格納するストレージを含む。プロセッサは、ネットワーク内の選択されたａｕｔｏ−ｉｄノードだけを照会するために、ａｕｔｏ−ｉｄノード内のインデックスデータに従うことによって、ａｕｔｏ−ｉｄノードのネットワークからデータを抽出するように動作可能であり、選択されたノードは、ａｕｔｏ−ｉｄノードのインデックスによって定義される階層ネットワークに配置される。
【選択図】図１

Description

本記載は、資産の自動識別、追跡、及び取り扱いに関する。

自動識別（ａｕｔｏ−ｉｄ）システムは、たとえば、製造、販売、搬送、または商取引における他の形で使用されることになる製品を識別、または他の形でそれら製品に関する情報を入手するのに使用される。たとえば、裏の部屋にある箱のような、物理的な物体に関する情報を、その箱に取り付けられたタグまたは他の識別子に関連して保管することができ、かつ／または一意の識別子を用いてタグ付けされた物体を、小売店の棚に置くことができる。次に、リーダまたはセンサなどのある種のデバイスを使用して、識別子を使用することによって物理的な物体を識別することができ、これによって、たとえば物体のブランド名または物体の有効期限など、箱または物体に関するコンピュータシステムに格納された情報を決定し、取り込み、使用することができる。

ＲＦＩＤ（Ｒａｄｉｏ−Ｆｒｅｑｕｅｎｃｙ Ｉｄｅｎｔｉｆｉｃａｔｉｏｎ）システムとして、ａｕｔｏ−ｉｄシステムの一例が知られている。ＲＦＩＤは、一般に、一意の番号（および／または他の識別する情報）が、ＲＦＩＤタグまたはトランスポンダ内のアンテナに使われるマイクロチップに格納される技術を参照する。リーダが、アンテナと通信し、マイクロチップから一意の番号を入手し、これによって一意の番号に関連する情報を入手するのに使用される。有利なことに、ＲＦＩＤは、高速かつ無線であり、リーダとタグの間の通信を可能にするのに方向(direction)または見通し線(line of sight)を必要とせず、人間がデータを入力する必要を減らすかなくす。その結果、ＲＦＩＤは、たとえば、店内または倉庫内のタグ付けされた物体の識別、ＲＦＩＤタグを有する自動車による料金の自動支払い、および／または制限された区域への立ち入りを許可された人員の識別のような、多くの応用例に使用することができる。

多数のタイプのａｕｔｏ−ｉｄシステム装置が存在する。例に、２Ｄバーコードスキャナ、スマートカードデバイス／リーダ、光学文字認識システム、およびバイオメトリックシステム（たとえば、網膜および指紋読取り）が含まれる。そのようなシステムの多数またはすべてが、コストを減らし、効率を高め、データ精度を改善し、より細かいデータ（単一の品目／物体のレベルまで）を提供し、これによって企業システムの運営における顧客満足度を高める能力または可能性を有する。

第１の全般的な態様で、システムは、ａｕｔｏ−ｉｄノードのネットワークおよびプロセッサを含む。各ａｕｔｏ−ｉｄノードは、ａｕｔｏ−ｉｄノードとネットワーク内の別のａｕｔｏ−ｉｄノードとの間の階層関係を定義するインデックスデータを含み、ａｕｔｏ−ｉｄノードは、ａｕｔｏ−ｉｄノードによって読み取られた１つまたは複数の資産についての状態および履歴データを保管するストレージを含む。プロセッサは、ネットワーク内の選択されたａｕｔｏ−ｉｄノードだけを照会するために、ａｕｔｏ−ｉｄノード内のインデックスデータに従うことによって、ａｕｔｏ−ｉｄノードのネットワークからデータを抽出するように動作可能であり、選択されたノードは、ａｕｔｏ−ｉｄノードのインデックスによって定義される階層ネットワークに配置される。

実施形態に、次の特徴のうちの１つまたは複数を含むことができる。たとえば、資産は、物理的な物体とすることができる。資産は、ａｕｔｏ−ｉｄノードによって識別される識別子に関連づけられることができる。前記識別子は、ＲＦＩＤタグとすることができる。ａｕｔｏ−ｉｄノードは、資産がａｕｔｏ−ｉｄノードで識別された時刻を追跡するように、動作可能とすることができる。

ａｕｔｏ−ｉｄノードは、少なくとも１つのノードと通信し、ａｕｔｏ−ＩＤシステムを介する資産の進行についてのノードから供給されるデータを受け取るように動作可能な自動識別デバイスをさらに含むことができる。システムは、資産の識別子を受け取るように動作可能なユーザインターフェースをさらに含むことができる。ａｕｔｏ−ｉｄノードのネットワークは、単一の組織に関連するａｕｔｏ−ｉｄノードを含むことができる。ａｕｔｏ−ｉｄノードのネットワーク内の異なるａｕｔｏ−ｉｄノードは、異なる組織に関連することができる。

もう１つの全般的な態様において、方法は、ａｕｔｏ−ｉｄノードによって読み取られた１つまたは複数の資産についての状態および履歴データを保管するためのストレージをそれぞれが含むａｕｔｏ−ｉｄノードのネットワーク内で、ａｕｔｏ−ＩＤシステム内の異なるａｕｔｏ−ｉｄノードの間の階層関係を定義することと、第１ａｕｔｏ−ｉｄノードを第２ａｕｔｏ−ｉｄノードに関係させるインデックスを第１ａｕｔｏ−ｉｄノードに保管することと、ネットワーク内の選択されたａｕｔｏ−ｉｄノードだけを照会するためにａｕｔｏ−ｉｄノード内のインデックスデータに従うことによってａｕｔｏ−ｉｄノードのネットワークからデータを抽出することとを含む方法であって、選択されたノードは、ａｕｔｏ−ｉｄノードのインデックスによって定義される階層ネットワークに配置されることを特徴とする。

実施形態に、次の特徴のうちの１つまたは複数を含むことができる。たとえば、資産は、物理的な物体とすることができる。方法は、資産をノードによって識別される識別子に関連付けることをさらに含むことができる記識別子は、ＲＦＩＤタグであることができる。

前記方法は、資産がａｕｔｏ−ｉｄノードによって識別された時刻についてのタイミングデータを保管することをさらに含むことができる。ａｕｔｏ−ｉｄノードのネットワークは、単一の組織に関連するａｕｔｏ−ｉｄノードを含むことができる。ａｕｔｏ−ｉｄノードの前記ネットワーク内の異なるａｕｔｏ−ｉｄノードは、異なる組織に関連することができる。

もう１つの全般的な態様において、機械可読記憶媒体は、ａｕｔｏ−ｉｄノードによって読み取られた１つまたは複数の資産についての状態および履歴データを保存するストレージをそれぞれが含むａｕｔｏ−ｉｄノードのネットワーク内で、ａｕｔｏ−ＩＤシステム内の異なるａｕｔｏ−ｉｄノードの間の階層関係を定義し、第１ａｕｔｏ−ｉｄノードを第２ａｕｔｏ−ｉｄノードに関係させるインデックスを第１ａｕｔｏ−ｉｄノードに保管し、ネットワーク内の選択されたａｕｔｏ−ｉｄノードだけに照会するためにａｕｔｏ−ｉｄノード内のインデックスデータに従うことによってａｕｔｏ−ｉｄノードのネットワークからデータを抽出することを、１つまたは複数のプロセッサに、引き起こさせる実行可能命令を含み、選択されたノードは、ａｕｔｏ−ｉｄノードのインデックスによって定義される階層ネットワークに配置されることを特徴とする。

実施形態に、次の特徴のうちの１つまたは複数を含むことができる。たとえば、記憶媒体は、１つまたは複数のプロセッサに、資産をノードによって識別される識別子に関連付けることを引き起こさせる実行可能命令をさらに含むことができる。識別子は、ＲＦＩＤタグとすることができる。ａｕｔｏ−ｉｄノードのネットワーク内の異なるａｕｔｏ−ｉｄノードは、異なる組織に関連することができる。

１つまたは複数の実施形態の詳細を、添付図面および下の説明に示す。他の特徴は、説明および図面ならびに請求項から明白であろう。

図１は、ａｕｔｏ−ｉｄシステム１００のネットワーク図である。図１では、複数のエンタープライズアプリケーションに、例として、サプライチェーンマネジメントアプリケーション１０２が含まれ、サプライチェーンマネジメントアプリケーション１０２は、企業が、その企業の製品またはサービスの生産／購入、出荷、または販売のプロセスを監督するのに使用することができる。資産追跡管理システム１０４は、たとえば、どの資産（たとえば在庫資産）が企業にとって使用可能もしくは使用不能、または企業によって望まれるかを決定するために、サイトまたは組織または多くの組織間の中、またはこれにまたがって、多くの資産を監視し、追跡するのに使用することができる。倉庫管理アプリケーション１０６は、倉庫の受取態様と、在庫態様と、選択態様と、出荷態様とを監督するのに使用することができる。分析システム１０８は、たとえばコンシューマ要求に対する応答の速度、盗難から生じる損失、または企業の利益もしくは運営に影響し得る他の要因など、企業の運営の諸態様を定量化するのに使用することができる。

図１に示されたエンタープライズアプリケーションの例は、エンタープライズシステムに共通するデータを収集し、共有し、使用するのに、企業が必要とするものを示す。たとえば、サプライチェーンマネジメントアプリケーション１０２は、資産管理アプリケーション１０４内のデータに基づいて、あるタイプの資産が現在何個使用可能であるかを知る必要があるかもしれない。分析システム１０８は、たとえばパフォーマンスの問題点（倉庫の使用法、配送遅延理由、またはサプライチェーンを介する品目の進行を有効にすること）、問題（たとえば、製品偽造パターン）、および物理的な物体（品目、ケース、パレット）の一般的な可視性を発見するために、ａｕｔｏ−ｉｄミドルウェアと他のアプリケーション１０２、１０４、１０６からもまた、データを抽出するかもしれない。分析システム１０８は、ポータルシステムを介して、発見された結果を報告できる。

たとえばすぐ上で説明したものなど、エンタープライズアプリケーションによって共有かつ使用されるデータの多くは、エンタープライズシステムによって購入され、かつ／または販売される製品またはサービスに関する。図１では、これらの製品またはサービスに関する情報が、ミドルウェアインフラストラクチャ１１０の使用を介してアプリケーションによって入手され、ミドルウェアインフラストラクチャ１１０は、購入され、かつ／または販売される製品およびサービスに関する情報を自動的に入手し、共有するためのａｕｔｏ−ｉｄ（自動識別）システムを実装する。

一般に、ａｕｔｏ−ｉｄシステムは、上で言及したように、企業によって売られるか使用される製品に関する情報の自動収集および使用を可能にし、識別子および識別子に関する情報を入手するためのリーダを含む。図１では、ａｕｔｏ−ｉｄ要素の例は、バーコードリーダ／プリンタ１１２を含み、バーコードリーダ／プリンタ１１２は、物体に取り付けられた（取り付けられることになる）バーコードラベルを読み取りまたは印刷するのに使用することができる。ＲＦＩＤシステムの上記の議論から理解されるべきであるように、ＲＦＩＤリーダ／プリンタ１１４が図示されており、これは物体に取り付けられたＲＦＩＤタグから情報を読み取るか、これに情報を割り当てるのに使用することができる。センサ１１６は、たとえば、環境センサ（たとえば、温度計）、あるいは、音声認識センサまたは光学文字認識センサを指してもよい。モバイルリーダ１１８は、その名前が暗示するように、たとえばＲＦＩＤタグまたは他のａｕｔｏ−ｉｄ識別子を検知するためにユーザが持ち運ぶことのできるリーダを指す。最後に、図１において、ＰＬＣ（Ｐｒｏｇｒａｍｍａｂｌｅ Ｌｏｇｉｃ Ｃｏｎｔｒｏｌｌｅｒ）デバイスは、下でより詳細に説明するように、オン／オフ制御、タイミング、ロジック、カウントおよびシーケンシングなどの応用例に使用され、デバイスコントローラシステムによって制御されることもできるディジタルコントローラを表す。バイオメトリックデバイスなどの他のデバイスも、ここで使用することができる。ここでは、一部の例だけがリストされている。

図１に示されているように、次に、ａｕｔｏ−ｉｄデバイス／システム１１２〜１２０のいずれかによって入手された情報は、エンタープライズアプリケーション１０２〜１０８のいずれかへ通信し、これらの間で共有され、これらによって使用されることができる。このように、企業は、その運営の範囲全体にまたがって、本質的にリアルタイムな情報を入手し、使用することができる。さらに、企業は、他の企業と情報を共有することができる。たとえば、サプライチェーンマネジメントアプリケーション１０２を、第１企業（たとえば、小売店）に関連付けることができ、倉庫管理アプリケーションを、第２企業（たとえば、製造業者）に関連付けることができる。ａｕｔｏ−ｉｄデバイス／システム１１２〜１２０から情報を入手し、これと他の情報をミドルウェアインフラストラクチャ１１０にまたがって共有することによって、２つの企業は、それぞれの運営の両方の効率を高めることができる。

図２は、図１のａｕｔｏ−ｉｄの特徴を例示するシステム２００のブロック図である。図２では、エンタープライズアプリケーション２０２は、上で述べたさまざまなアプリケーション１０２〜１０８ならびにさまざまな他のエンタープライズアプリケーションを含むことができる。

ａｕｔｏ−ｉｄインフラストラクチャ２０４は、図１のミドルウェアインフラストラクチャ１１０の一部または全体を表す。詳しくは、ａｕｔｏ−ｉｄインフラストラクチャ２０４は、ａｕｔｏ−ｉｄノード２０６、２０８、および２１０を含む。ａｕｔｏ−ｉｄノード２０６、２０８、および２１０は、一般に、ａｕｔｏ−ｉｄデバイス１１２〜１２０によって入手された関連情報を既存のビジネスロジックまたはデータに関連付けるように設計された、定義された位置にあるノードを表す。さらに、ａｕｔｏ−ｉｄノード２０６、２０８、および２１０は、ａｕｔｏ−ｉｄデバイス／システム１１２〜１２０によって追跡されてきた製品または物体の履歴情報を保管するのに使用することができる。そのような履歴の情報は、たとえば、特定の時刻における状態情報、物体の位置、追跡される物体または特定の位置に関連する環境情報、および所望の目的のために収集され、結びつけあれる、複数の物体に関する情報を含むことができる。

ａｕｔｏ−ｉｄノード２０６、２０８、および２１０を、企業全体にわたってまたは複数の企業にまたがって戦略的に置くことができる。たとえば、１つまたは複数のａｕｔｏ−ｉｄノード２０６を、製造現場に位置づけることができ、一方で、ａｕｔｏ−ｉｄノード２０８を、小売り製品流通場所に位置づけることができ、ａｕｔｏ−ｉｄノード２１０を、小売店に位置づけることができる。さらに、１つまたは複数のａｕｔｏ−ｉｄノードを、原料供給業者、製造工場、製造流通センタ、および運送サービスの位置に備えることができる。このように、ａｕｔｏ−ｉｄノードの実際の設定に固有の情報を、その特定のノードにおいてのみ入手し、保持することができる。

たとえば、小売店にあるａｕｔｏ−ｉｄノード２１０は、品物の小売価格、または小売店の棚にある品物の数を追跡するのに使われることができる。そのような情報は、製造工場位置にあるａｕｔｏ−ｉｄノード２０６に有用でないかもしれないが、小売り流通位置にあるａｕｔｏ−ｉｄノード２０８に部分的に有用であるかもしれない。たとえば、小売り流通位置にあるａｕｔｏ−ｉｄノード２０８は、品物の小売価格に関心を持たないかもしれないが、（再仕入れのために）現在棚に置かれている品物数に関心を持つかもしれない。

同様に、異なる場所にある業務およびビジネスロジックは、局所化されたａｕｔｏ−ｉｄノード２０６、２０８、および２１０の使用から利益を得る場合がある。たとえば、小売りａｕｔｏ−ｉｄノード２１０は、物体の盗難を防ぐためのワークフローを含むかもしれない一方で、製造ａｕｔｏ−ｉｄノード２０６は、特定の期間に製造された物体の量を監視することに関心を持つかもしれない。このように局所化されたａｕｔｏ−ｉｄノードの分散ネットワークを使用することによって、システム２００は、より効率的で、かつ、さまざまな位置にいるユーザにより有用な形で、情報を処理することができる。

システム２００内の各ａｕｔｏ−ｉｄノードは、一般に、図２でデバイスコントローラ２１２、２１４、および２１６として示された１つまたは複数のデバイスコントローラを含み、これらのデバイスコントローラは、流通ａｕｔｏ−ｉｄノード２０８に関連する。もちろん、ａｕｔｏ−ｉｄノード２０６、２０８、および２１０のそれぞれが、より少数またはより多数のデバイスコントローラを有することができ、あるいは、デバイスコントローラを全く使用しなくてもよい。

例としてデバイスコントローラ２１４を参照すると、図２は、デバイスコントローラ２１４が、ａｕｔｏ−ｉｄデバイス１１２〜１２０のうちのいくつかまたはすべての動作を監督し、調整するのに使用されうることを示す。もちろん、デバイスコントローラ２１２および２１６は、これらのデバイスコントローラに接続できる類似するａｕｔｏ−ｉｄデバイスの動作を監督するために使用されうる。

さらに詳しくは、デバイスコントローラ２１４は、それに関連するａｕｔｏ−ｉｄノード２０８の効率を高めるために、ａｕｔｏ−ｉｄデバイス１１２〜１２０からのデータを処理するのに使用できる。たとえば、デバイスコントローラ２１４は、ａｕｔｏ−ｉｄノード２０８の流通機能に有用な形で、および／またはエンタープライズアプリケーション２０２に有用な形で、そのａｕｔｏ−ｉｄノードによって指定される形で余分な情報を除去することができ、あるいは、データを組み合わせるか修正することができる。

このように、デバイスコントローラ２１４は、おそらくａｕｔｏ−ｉｄノード２０８からの指示に基づいて、ａｕｔｏ−ｉｄデバイス１１２〜１２０を調整し、管理し、（処理された）情報をａｕｔｏ−ｉｄデバイスからａｕｔｏ−ｉｄノード２０８に中継する。たとえば、ａｕｔｏ−ｉｄノード２０８を、物体２１８（たとえば、販売のために小売業者に配送されるおもちゃまたは他の品目）に関する特定のクラスのデータ（たとえば、量など）を入手するよう、デバイスコントローラ２１４に指示するために使用できる。次に、デバイスコントローラ２１４が、ＲＦＩＤリーダ／プリンタ１１４を使用して、物体２１８に関連するタグ２２０からこの情報を得ることができ、次に、当該物体がある個数使用可能であるという情報をａｕｔｏ−ｉｄノード２０８に渡す前に、現在入手されている望まれない情報を除去することができる。

もう１つの例として、ａｕｔｏ−ｉｄノード２０８は、情報を物体２１８に割り当てるようにデバイスコントローラ２１４に指示することができる。たとえば、デバイスコントローラ２１４は、ＲＦＩＤリーダ／プリンタ１１４を、物体２１８の現在の価格を変更する（たとえば、あるクラスの物体に取り付けられたＲＦＩＤタグ２２０に新しい価格情報を保存すること、またはこれに関連すること）のに使用することができる。

図２から、デバイスコントローラ２１２、２１４、および２１６のそれぞれを、それに関連するａｕｔｏ−ｉｄデバイスおよび／または環境デバイス１１２〜１２０のすべてに関して、データをフィルタリング、集計、書き込み、または他の形で操作するのに使用できるのと同様に、ａｕｔｏ−ｉｄノード２０８は、それに関連するデバイスコントローラ２１２、２１４、および２１６のデータを、フィルタリング、集計、割り当て、または他の形で操作するように動作可能である。このように、ａｕｔｏ−ｉｄノード２０８が、エンタープライズアプリケーション２０２のうちの１つまたは複数で動作できる業務を用いて、そのデバイスコントローラ２１２、２１４、および２１６からの情報を統合することができる。

拡張によって、エンタープライズアプリケーション２０２が、ａｕｔｏ−ｉｄノード２1６、２1８、および２１０のすべてからの情報を集計するように動作可能であることがわかる。さらに、システム２００のあるレベルで有用な情報が、別のレベルで有用でないかもしれないことを理解されたい。たとえば、エンタープライズアプリケーション２０２が、リーダ／プリンタ１１４によって収集された低レベル（たとえば、品目レベル）情報に関心がないか、使用できないかもしれない。むしろ、エンタープライズアプリケーション２０２は、情報がデバイスコントローラ２１４および／またはａｕｔｏ−ｉｄノード２０８によってフィルタリングされ、かつ／または集計される範囲までその情報に関心のみ持つかもしれない。

説明したアーキテクチャの結果として、エンタープライズアプリケーション２０２および／または多数のエンタープライズアプリケーションからのビジネスロジックを、ａｕｔｏ−ｉｄミドルウェア１１０内でサポートできることを理解されたい。さらに、そのような多数のエンタープライズアプリケーションを、エンタープライズアプリケーションのすべてに共通する、単一の物理ハードウェアシステムおよび単一のａｕｔｏ−ｉｄミドルウェアでサポートすることができる。

図３は、図２のａｕｔｏ−ｉｄインフラストラクチャ２０４を使用するネットワークアーキテクチャ３００のブロック図である。さらに詳しくは、図３には、図２のａｕｔｏ−ｉｄインフラストラクチャ２０４を、ａｕｔｏ−ｉｄシステムを使用するために開発されてきたＥＰＣ（Ｅｌｅｃｔｒｏｎｉｃ Ｐｒｏｄｕｃｔ Ｃｏｄｅ）で使用されるアーキテクチャが示されている。

ＥＰＣは、ＵＰＣ（Ｕｎｉｆｏｒｍ Ｐｒｏｄｕｃｔ Ｃｏｄｅ）識別子と同様に、複数の組織および企業がそれぞれの製品、商品、サービス、またはこれらの集合（たとえば、パレット、ケース、またはトラック積荷）を一意に指定、識別するのに使用することに合意した事前定義のフォーマットおよび方式を有する、一意の番号を指す。ＲＦＩＤシステムにおいて、ＥＰＣは、図２の物体２１８上のタグ２２０に割り当てることができる。たとえば、古典的なＥＰＣは、例えば４つのフィールドすなわち、ヘッダフィールド（異なるフォーマットを区別する）、製造業者フィールド（ＥＰＣを割り当てる各組織がそれ自体の製造業者フィールドを有する）、製品フィールド（製品コード）、および通し番号（製品に関する）によって定義される。

図３では、ＥＰＣＩＳ（ＥＰＣ 情報サービス）層３０２は、ネットワーク上でＥＰＣデータの交換を可能にする。すなわち、ＥＰＣＩＳは、ＥＰＣ番号を識別したリーダがその番号に関する（したがって、それに関連する品目に関する）情報を見つけ、使用することのできる標準的なフォーマットまたはプロトコルを提供する。いくつかの実装で、および／または関連する実装で、たとえばＰＭＬ（Ｐｈｙｓｉｃａｌ Ｍａｒｋ−ｕｐ Ｌａｎｇｕａｇｅ）および／またはＸＭＬ（ｅＸｔｅｎｓｉｂｌｅ Ｍａｒｋ−ｕｐ Ｌａｎｇｕａｇｅ）などの言語を、上で説明した運送およびビジネスレベルＥＰＣ情報のために使用に使用してもよい。

ＥＰＣＩＳ層３０２は、アプリケーションマネージャ３０４から情報を受け取り、アプリケーションマネージャ３０４は、一般に、情報イベント（たとえば、タグ読取）を監督し、ＥＰＣＩＳ層３０２への通信に関するイベントを管理し、これによってＥＰＣＩＳリポジトリ３０６への通信に関するイベントを管理するように動作可能である。アプリケーションマネージャ３０４は、データが特定のアプリケーションまたはデバイスにとって即座に有用でない可能性がある比較的長い期間にわたってリポジトリ３０６にデータが蓄積される際に、リポジトリ３０６を監視し、設定するように動作する。一般的に、たくさんの物体に関する情報のフローは、特に潜在的なネットワーク遅延がある場合に、リポジトリ３０６がリアルタイムで実用的に有用であるには多すぎる場合がある。むしろ、図２のａｕｔｏ−ｉｄノード２０８は、おそらくある一定の時間周期で、ａｕｔｏ−ｉｄノード２０８に即座に有用である可能性があるそのような情報を追跡するのに使用される。

アプリケーションマネージャ３０４およびＥＰＣＩＳ層３０２は、ＯＮＳ（オブジェクトネーミングサービス）にアクセスでき、このＯＮＳは、ドメインネームサービス（ＤＮＳ）に似ており、アプリケーションマネージャ３０４およびＥＰＣＩＳ層３０２が製品のＥＰＣコードに基づいてその製品に関する情報を見つけることを可能にする検索サービスである。ＯＮＳ３０８は、異なるレベルの情報を有することができ、これらの情報は、たとえば、情報が製品にローカルにまたは非ローカルのどちらで保管されるかによって分類することができる。

アプリケーションレベルイベント（ＡＬＥ）インターフェース層３１０は、デバイスマネージャ３１２およびデバイスコントローラ２１４へのインターフェースを提供する。さらに詳しくは、ＡＬＥインターフェース層３１０を使用して、デバイスマネージャ３１２および／またはデバイスコントローラ２１４から受け取られる際に、情報イベントをフィルタリングまたは集計することができる。デバイスマネージャ３１２を使用して、デバイスコントローラ２１４の状態および／または設定を管理することができる。

図３にも示されているように、リーダプロトコルインターフェース層３１４は、デバイス１１４にインターフェースを提供する。すなわち、異なる企業は、異なるタイプのデバイス１１４または他のａｕｔｏ−ｉｄデバイスを採用することができ、これらのデバイスおよび企業は、リーダと通信するのに異なるリーダプロトコルを利用できることを理解されたい。リーダプロトコルインターフェース３１４は、システム３００内のすべてのリーダとの通信を可能にするように設計される。

図３から、システム３００を、図２のａｕｔｏ−ｉｄインフラストラクチャ２０４なしで使用することができ、また、逆に、図２のａｕｔｏ−ｉｄインフラストラクチャ２０４を、図３の他の要素なしで使用できることを理解されたい。このように図３は、図２のａｕｔｏ−ｉｄインフラストラクチャ２０４を、ＥＰＣネットワークおよびＥＰＣ標準規格で使用することができるが、これらの使用が要求されていないことを示す。

図４は、図２および／または３のａｕｔｏ−ｉｄノード２０６、２０８、および２１０のブロック図である。図４に示されているように、コアサービスモジュール４０２は、下で詳細に述べるように、たとえばａｕｔｏ−ｉｄノード２０８の実行詳細を取り扱う、一方でさまざまな統合モジュール４０４、４０６、４０８、および４７０は、外部のフィーチャ、ユーザ、およびサービスに関するコアサービスモジュール４０２の詳細を、通信、構成、および管理を取り扱う。

たとえば、バックエンドシステム統合層４０４は、ａｕｔｏ−ｉｄノード４００と、たとえば図１のアプリケーション１０２〜１０８または図２のアプリケーション２０２のようなバックエンドシステムとの間の通信を取り扱う。

デバイス統合層４０６は、ａｕｔｏ−ｉｄノード４００とデバイスの間の通信を処理する。たとえば、デバイス統合層４０６は、図２のノード２０８とデバイスコントローラ２１４の間の通信を可能にすることができる。いくつかの実装で、デバイス統合層４０６は、トラッキングデバイス１１２〜１１８のうちの１つまたは複数と直接の通信を可能にすることができる。

ヒューマン統合層４０８は、ａｕｔｏ−ｉｄノード４００とユーザインターフェースの間の通信を行う。たとえば、ａｕｔｏ−ｉｄノードオペレータは、ユーザインターフェースを介してあるタスクを実行するように、またはａｕｔｏ−ｉｄノードが受け取る情報を監視するように、ａｕｔｏ−ｉｄノードを設定することができる。オペレータは、たとえば予期していないイベントまたは誤動作の場合にａｕｔｏ−ｉｄノードから警告メッセージを取得することもできる。さらに、ａｕｔｏ−ｉｄノード４００のセキュリティを監視することができので、承認された人員だけがａｕｔｏ−ｉｄノード４００と対話できるようになる。

ノード統合層４７０は、ａｕｔｏ−ｉｄノード４００と他のａｕｔｏ−ｉｄノードの間の通信を行う。たとえば、多数の隣接するａｕｔｏ−ｉｄノードは一緒に、物体のルーティング情報を提供するために、または物体の追加ユニットを購入または仕入れなければならないかどうかを判定するために、流通またはサプライチェーンを介して物体を追跡することができる。

コアサービスモジュール４０２に、アクティビティおよびプロセス管理モジュール４１０を含む。アクティビティおよびプロセス管理モジュール４１０は、たとえば、タグ情報が、（たとえば）図２のＲＦＩＤリーダ１１４によって物体２１８のタグ２２０から情報が読み取られる読取りまたはトラッキングイベントのような、物体が経験するイベントに関連する情報を分析する。次に、アクティビティおよびプロセス管理モジュール４１０は、この情報を、特定の物体に関係する既知の情報とマッチさせる。

たとえば、下でより詳細に説明するように、各追跡される物体を、たとえば業務モデルまたはワークフローとも称される、１つまたは複数の業務に関連付けることができる。そのようなプロセスは、一般に、物体がその寿命の一部またはすべての間すなわち、製造から流通まで、流通から小売り販売まで、または製造から小売り販売までの間に経験するだろうすべての既知のまたは予想される可能性を記述したものである。この意味で、ａｕｔｏ−ｉｄノードは、特定のａｕｔｏ−ｉｄノード４００の任務によって、特定の物体の寿命情報のすべて、または寿命情報のいくつかのサブセットだけを必要とするかもしれない。

したがって実際に、（関連する業務モデルから派生する）予測されたイベント情報と同様に前に検出されたイベント情報と結び付けられた現在のイベント情報（たとえば、リーダ１１４によってタグ２２０から読み取られる情報）は、ａｕｔｏ−ｉｄノード４００が追跡された物体の状態に関して決定することを可能にする。このように、ａｕｔｏ−ｉｄノード４００は、最小限の人間の介入または監督で効果的でコスト効率のよい形で、サプライチェーンまたは他のビジネスモデル（たとえば、顧客による商品返品）を介して、物体の識別と追跡ができる。

アクティビティおよびプロセス管理モジュール４１０は、イベントメッセージディスパッチャ４１２を含む。イベントメッセージディスパッチャ４１２は、異なるソースからイベントを受け取り、上で言及したように、期限イベントは、一般に、たとえば図１のトラッキングデバイス１１２〜１１８のうちの１つまたは複数のアクティビティによって引き起こされる出来事を指すことができる。

いくつかの実施例において、いくつかのイベントは、イベントメッセージディスパッチャ４１２で任意の個数のソースから受け取られるソフトウェア／データパケットとして表すことができる。追跡デバイス１１２〜１１８に加えて、イベントを、ヒューマン統合モジュール４０８を経由してローカルオペレータから受け取ることができる。イベントを、たとえば、バックエンドシステム４０４または別のａｕｔｏ−ｉｄノードから受け取ることもできる。

イベントのこれらの異なるソースは、さまざまなイベントの記述において、同一または類似のフォーマットを共有できる。たとえば、イベントの異なるソースは、イベントを記述するのに汎用のイベント記述子プロトコルを使用してもよい。イベント記述子は、たとえば、設計された物体識別子、イベント型（たとえば、ＲＦＩＤ読取イベント）、イベントソース（たとえば、ＲＦＩＤリーダ１１４）、タイムスタンプ、イベントソースの位置、イベントサブジェクト識別子、または他の情報を含んでもよい。

１つの個別の例として、リーダデバイス１１４が、ｉｄ「ａｂｃｄ１２３４」を有するＲＦＩＤリーダから、時刻「１０：２３ＡＭ Ｄｅｃ ２１，２００４」に関連し、スキャンされた物体への一意の物体固有識別子を有する「ｓｃａｎｎｉｎｇ」のイベント型を送ることができる。このように、異なるソースからのイベントは、互換性のあるフォーマットで、イベントメッセージディスパッチャ４１２内で受け取られるので、イベントメッセージディスパッチャ４１２は、イベントのソースにかかわりなく、同一または類似する形で入ってきたイベントを行うことができる。

イベントメッセージ処理器４１２は、上で言及した情報または他の情報の一部またはすべてを分析し、入ってきたイベントを１つまたは複数のアクティビティ処理器４１４または４１６にディスパッチする。たとえば、イベントは、イベントの型（たとえば、デバイスリーダイベント、隣接ａｕｔｏ−ｉｄノードイベント、またはバックエンドシステムイベント）、イベントの時刻（たとえば、イベントが日中イベントであるか夜間イベントであるか）、または実際にアクティビティ処理器がイベントの処理を委任できる他のすべての基準に基づいて、他のアクティビティ処理器４１４、４１６のうちの１つにディスパッチすることができる。

アクティビティ処理器４１４、４１６は、イベントに関連し、必要な時にアクセスできるすべての既知のデータと一緒に、イベントに含まれるイベントに関する情報を分析し、この情報を、イベントの物体に関連する決定された業務と比較する。それを行う際に、アクティビティ処理器４１４、４１６は、イベントに応答して、行われるべき１つまたは複数の未来のアクションがあれば、それを決定するように動作する。

一度決定されると、未来のアクションは、その実行のためにａｕｔｏ−ｉｄノード４００の外部に通信することができる。たとえば、未来のアクションは、統合インターフェース４０４、４０６、４０８、および／または４７０を介して通信することができる。このように、たとえば、人のオペレータはいくつかのアクションを実行するように要求、または通知をあげ、または別個のａｕｔｏ−ｉｄノード２０４、２０６、２０８（またはバックエンドエンタープライズアプリケーション１０２〜１０８／２０２もしくはデバイス１１２〜１２０）はいくつかの要求されたアクティビティの通知をすることができる。アクティビティ処理器４１４、４１６もまた、イベントによって表される変更を反映し、物体が業務内のどこにいるかをより実際的に反映するために、それ自体の状態および／または物体にかかわるトラッキングデータを更新することができる。

物体に関連する業務は、ルールのセットおよび／または物体およびおそらく他の物体に関連するだろうワークフローモデルの一部として表すことができる。たとえば、ルールは、特定の状態または状況に応答して異なるアクションが行われることを提示する、条件節に似ていてよい。すなわち、ルールは、受け取ったイベントに関して１つまたは複数の条件が満たされる場合に、応答して１つまたは複数のアクションを行われるべきことを提示できる。条件のタイプ、意思決定プロセス、および応答アクションは、下で詳細に述べる。

そのようなルールを実装するために、アクティビティ処理器４１４は、アクティビティ処理器４１４における入ってきたイベントにルールセット４２０および４２２を適用するルールエンジン４１８を含む。ルールエンジン４１８は、ａｕｔｏ−ｉｄノード４００で受け取ったイベントに適応されることになるプログラム可能なルールセットのアーキテクチャを提供する。ルールエンジン４１８は、たとえば、受け取ったイベントに適用できる、ルールセット４２０／４２２内の１つまたは複数のルールを検索するメカニズムを実装することができる。

たとえば、ルールエンジンは、（上で言及したように汎用のイベント記述子プロトコルでフォーマットすることができる）イベントを解析することができ、１つまたは複数の適用可能なルールを見つけるために、各ルールセットおよび／またはルールの選択基準を計算し、マッチさせることができる。ルールエンジン４１８もまた、コアサービス４１０の他の部分でアクションをアクティブ化すること、および／またはバックエンドシステム統合４０４、デバイス統合４０６、ヒューマン統合４０８、およびノード統合４７０を介して、外部モジュール、ユーザ、およびサービスでのアクション要求を通信することによって、ルールを実行するメカニズムを含むことができる。

１つの例として、イベントメッセージ処理器４１２は、入ってきたイベントが、ある位置でのデバイスのあるクラス（たとえば、倉庫にある特定の波止場岸）で受け取られた集荷に関係することを決定することができ、そのようなイベントの処理を割り当てられるアクティビティ処理器４１４にそのイベントを、ディスパッチすることができる。アクティビティ処理器４１４は、ルールエンジン４１８内のルールセット４２０がこのタイプのイベントに適用するのに適当なルールセットであることを決定するために、そのイベントがある物体に関係し、かつ／または他の特性（たとえば、夜間出荷中に発生した）を有することを決定することができる。次に、ルールセット４２０を適用して、受け取ったイベントを分析し、これによって、各ルールの条件節を、（おそらく）他の情報に沿って、そのイベントに関して受け取った情報とマッチさせることができ、マッチがある場合に、そのイベントおよびマッチする物体に関して行うべき将来のアクションまたは期待されるアクションを決定するために、そのルールを適用することができる。

ルールエンジン４１８は、拡張性があるので、より多くのルールセットを、機能を崩壊させずにルールエンジンに追加することができる。さらに、ルールエンジン４１８は、柔軟性があるので、既存のルールセットは、たとえばランタイムまたは不要になった時に、除去するか非アクティブにすることができる。

ルールセット４２０は、たとえば、バックエンドシステム統合モジュール４０４を介して、あるいは他のインターフェースモジュール４０６、４０８、または４７０のうちの一つからのバックエンドシステムによって、アクティビティ処理器４１４、４１６に割り当てることができる。ルールは、他のａｕｔｏ−ｉｄから、図３のＥＰＣＩＳリポジトリ３０６から、または他のソースから追加することもできる。ルールセット４２０／４２２はモジュラなので、他のルールセットの動作を崩壊させずに簡単に置換しまたは修正することができる。

上で言及したように、ルールエンジン４１８は、イベントに関連する物体に将来または期待されるアクションがある場合にそれを決定するために、物体固有のイベントを受け取り、そのイベントを業務に関連付ける。それを行う際に、ルールエンジン４１８は、マッチング動作を実行するのに役立つだろう追加データに接続できる。詳しくは、コアサービス４０２において、関連付けデータ管理モジュール４２３は、アクティビティおよびプロセス管理モジュール４１０と通信し、ルールエンジン４１８によるルールセット４２０および４２２の実装に役立つだろうデータおよびサービスを格納（またはアクセス）する。

たとえば、関連付けデータ管理モジュール４２３は、アクティビティ処理器４１４、４１６と密接に働いて、各イベントオブジェクトのライフサイクルまたはその一部を記憶することができ、イベントの受信に応答してリアルタイムでイベントオブジェクトの状態を更新することができる。たとえば、関連付けデータ管理モジュール４２３は、物体がそのライフサイクルを通じて、たとえば原料供給業者から製造業者、小売業者へまたは物体の返却から物体が再生された物体としての小売り販売のために再梱包されるまで、進行する際に、物体に関するデータを含むことができる。

関連付けデータ管理モジュール４２３は、一般に、特定の物体に関する２つのクラスのデータを追跡する。くわしくは、動的データは、時間で変化するデータ、変化すると期待することのできるデータ、または物体が時間を介して移動するのに関連して変化するデータを指す。逆に、静的データは、一般に時間で変化しないデータ、またはたまにのみ変化するデータを指す。異なるパラメータを、追跡される物体および業務に応じて、動的または静的と考えることができる。たとえば、物体の位置は、動的と考えることができるが、物体の色または重さは、一般に静的と考えることができる。しかし、特に製造プロセス中に、物体の色が変化することは可能であり、この場合に、色を、動的な性質と考えることができる。

このように動的データは、定義されたライフサイクルまたはタイムラインを介して物体を表す。たとえば、動的データは一般に、図４において、３つのコンポーネントすなわち、期待されるアクション４２４、現在の状態４２６、および履歴４２８を含むとして表される。期待されるアクション４２４は、一つのイベントに関する、期待される将来のイベントまたは可能性のある将来のイベントを含む。したがって、現在の状態４２６は、イベントの現在の状態を含むことができ、履歴４２８は、イベントオブジェクトが経験した過去のイベントのリストを含むことができる。

これらのコンポーネントは動的なので、関連するデータは、特定の物体に関して受け取られるイベントに応答して変更されるかもしれない。たとえば、３つのコンポーネント４２４、４２６、４２８は、イベントが受け取られるたびにアクティビティ処理器４１４、４１６によって更新されるかもしれない。くわしくは、イベントは、発送センタでの物体の受取を引き起こす場合に、その物体の現在の状態が、現在の状態４２６内で「輸送中」から「受取済み」に変更されるかもしれない。次に、前の状態エントリが、物体の輸送履歴（たとえば、輸送中に移動した経路）を表すために、履歴４２８に移動するかもしれない。期待されるアクション４２４の「受取済み」の期待されるアクションは、現在の状態４２６として再指定され、ルールエンジン４１８は、期待されるアクション４２４内にまだある期待されるアクションのどれを次に実施すべきか（たとえば、店の棚に置くために物体を荷おろしする）を決定するために、ルールセット４２０を使用してもよい。

動的データは、このように少なくとも特定の物体に関してイベントが受け取られるのと同じ頻度で変わるかもしれない。イベントの個数および頻度は、一般に、リーダの個数および可用性に関係するので、理論的限界では、十分に多数のリーダによってそのライフタイム中に継続的に追跡される物体は、継続的な基準で変化する動的データを有し得るようになる。

対照的に、静的データは、一般に、標準的または継続的な基準で更新する必要は期待されない、データベースまたはメモリ内の関連付けデータ管理モジュール４２３内に格納される。むしろ、関連付けデータ管理モジュール４２３は、外部ソースと通信して、周期的または半周期的な基準で静的データを更新するだろう。したがって、そのような静的データは、一般に、イベントに応答して変更を期待され得ない（いくつかの状況でこれが発生する可能性はあるが）。

たとえば、位置データベース４３０は、発送センタの住所ならびにその発送センタに到着する出荷の可能なソースの住所を含むことができる。いくつかの位置情報は、動的と考えることができ（たとえば、輸送中の物体の現在位置）、一方他の位置情報は、静的と考えることができる（たとえば、特定の物体が作られる製造施設）ことを理解されたい。しかし、一般に、静的情報は、イベントごとの基準では変化しないと考えられるだろう。

同様に、製品データベース４３２は、イベントごとの基準で、変化するが、もう一度は一般に変化しないというような記述を含む、追跡されている製品または物体の詳細な記述を含むことができる。製品データベース４３２は、そのような情報を保管することができ、あるいは、たとえば汎用製品ｉｄ（たとえば、物体２１８のタグ２２０から読み取られるＥＰＣコード）を使用して、外部ソースから情報を調べることができる。

業務データベース４３４は、物体に関連する１つまたは複数の業務を含むことができる。上で言及したように、業務は、物体のライフタイムを支配するように設計されたタスク／イベントの形式化されたワークフローまたは進行を指すことができる。たとえば、業務モデルは、製造プロセス、流通プロセス、または欠陥のある商品の顧客返品プロセスに関して形式化することができる。

そのような場合に、業務モデルは、それぞれの物体のライフサイクルの全体（または大部分）を介して多数の物体のライフサイクルを管理するために、たとえばバックエンドシステム２０２で、抽象的なレベルで設計できる。次に、業務モデルの特定のサブセットまたはインスタンス化は、ａｕｔｏ−ｉｄノード４００で実装しまたは監視でき、その結果、特定の物体の業務モデルは、その物体が経験する可能性があるライフサイクルイベントおよび可能な（予想される）イベントを表す。このタイプの実装の特定の例は、図６に準じて下で述べる。

他の例で、このレベルで定義される業務モデルまたはワークフローがない場合があり、ルール、動的データ、および静的データは、物体が経験するだろう業務を暗黙のうちに定義することができる。

リソースデータベース４３６に、イベントに関する他のリソースを含むことができる。たとえば、リソースデータベース４３６は、イベントに応答するのにどのアクションが必要であれ、そのアクションを実施するのに使用可能なリソースを含むことができる。たとえば、物体が、その物体を運搬するのに特殊な装置を必要とする倉庫で受け取られる場合に、リソースデータベース４３６は、その倉庫の施設で使用可能だろうそのような移動装置に関する情報を格納できる。類似するコメントは、物体のライフサイクル全体を通じて物体の管理に有用であろう他のリソースに適用され、その結果、一般に、ルールエンジン４１８はアクションが必要であると決定する時に、リソースデータベースはそのアクションを実施するのにどのリソースが使用可能かを決定する判定することを尋ねられる。

上記実施例は、動的データおよび静的データの分割に関して述べているが、この分割が単に一例であることを理解されたい。たとえば、データベース４３０〜４３６は、静的データに加えて動的データのいくつかまたはすべてを保管するのに使用され、この場合に、上の例より頻繁に動的に変更するデータで単に更新することができる。たとえば、位置データが動的または静的な位置情報を表せる範囲まで、上で言及したように、位置データベース４３０は、動的および／または静的データを含むと考えることができることを理解されたい。

コアサービス４０２は、ａｕｔｏ−ｉｄノード４００の設定と管理するための、設定とアドミニストレーション管理モジュール４４０も含む。たとえば、アドミニストレーション管理モジュール４４０は、ユーザがより多くのルールセット４２０、４２２をアップロードし、モジュール４０４〜４０８に関する統合ロジックを管理し、または外部サービスとの接続を確立する（たとえば、静的データストレージ４３０〜４３６を更新するために）ことを許可することができる。インデックス４４２は、下で詳細に説明するように、保守できるａｕｔｏ−ｉｄノード４００と他のａｕｔｏ−ｉｄノードの間の１つまたは複数の関連を示す。最後に、図４では、ストレージおよびアーカイビング管理モジュール４５０が、コアサービスモジュール４１０のデータストレージおよびアーカイビングを管理する。たとえば、モジュール４５０は、頻繁に使用されるデータまたはある事前に決定された時間の間に使用されなかったデータをアーカイブするのに使用することができる。そう行う際に、モジュール４５０は、ａｕｔｏ−ｉｄノード４００で必要なリソースを最小にするために、外部ストレージ位置と相互作用することができる。

図４の上の説明は、特定の物体または物体のグループのタイムラインの例に関して与えられたもので、ここで、物体の期待されるアクションは、実際のイベントとマッチする。しかし、ルール、タイムライン、および他の基準を、他のパラメータに関して実装できることを理解されたい。

たとえば、物体固有であるよりむしろ、ａｕｔｏ−ｉｄノードは、特定のリーダまたはリーダのセットに関して動作することができる。たとえば、１つのリーダは、多数の物体の識別子からイベントを検出することができるので、履歴４２８、現在の状態４２６、および期待されるアクション４２４は、リーダによって読み取られる特定の物体に関してではなく、リーダに関して定義することができる。

たとえば、クリスマスディスプレイは、多数のクリスマス関連物体を売ることができ、ディスプレイが空になる時を決定するために、リーダを物体に隣接して配置することができる。この例では、アクティビティ処理器４１４が、特定のリーダに関して発生するすべてのアクティビティを処理することができ、ルールセット４２０は、たとえば、裏の部屋または製造業者からの在庫の再注文するパラメータ、またはあるタイプの物体が売り切れた時に別のタイプの物体に置き換えるためのパラメータを設計することができる。

したがって、アクティビティおよびプロセス管理モジュール４１０は、多数の異なるパラメータおよびガイドラインに従って動作することができるにも関わらず、本明細書に含まれる説明および例から、アクティビティおよびプロセス管理モジュール４１０が、期待されるイベントまたは将来のイベントを決定し、期待されるイベントにマッチする対応するイベントが来るまで待つように動作可能であることを理解されたい。その際に、アクティビティおよびプロセス管理モジュール４１０は、期待されるイベントに一致しない多数のイベントを処理し、この場合に、アラームを引き起こすか、あるいは、アクションは取られる必要がなくなるだろう。

図５は、図２〜４のａｕｔｏ−ｉｄノードの処理５００を示すフロー図であり、この処理で、ａｕｔｏ−ｉｄノードはイベントを処理する。図５では、初期的に、イベントメッセージディスパッチャ４１２は、トラッキングデバイス１１２〜１２０のうちの１つまたはいくつかの他のイベントを生成するデバイスからイベントを受け取る（５０２）。たとえば、ソーダのパレットが、大規模小売店の倉庫に到着し、ＲＦＩＤリーダ１１４によってスキャンされてもよい。次にイベントは、イベントメッセージディスパッチャ４１２に送られるデータパケットの形で、物体（この場合に、パレット自体および／またはソーダのそれぞれ個々の缶）の識別を反映して生成される。

次に、イベントメッセージディスパッチャ４１２は、そのイベントに適当なアクティビティ処理器を見つけるために、イベントに含まれるおよび／または関連する情報を使用する（５０４）。たとえば、イベントメッセージディスパッチャ４１２は、アクティビティ処理器４１４はソーダのパレットの「受取」タイプのイベントを処理すると決定することができる。イベントメッセージディスパッチャ４１２は、このように、受け取ったイベントを、見つかったアクティビティ処理器に渡す。

アクティビティ処理器４１４は、ディスパッチされたイベントを受け取り、選択されたルールで、たとえばルールエンジン４１８およびルールセット４２０で、そのイベントを処理する（５０６）。くわしくは、ルールエンジン４１８が、受け取ったイベントに適用する適当なルールがある場合に、それを見つけるために、イベントおよび関連する物体の情報を分析する。

次に、ルールエンジン４１８は、受け取ったイベントに応答して行われるべき期待されるアクションを決定するために、ルール４２０のイベントを実行する（５０８）。たとえば、上の例を継続すると、ルールセット４２０は、ソーダの出荷がそれらを仕入れるために特定の倉庫で受け入れられるかどうかのルール、または（たとえば、特定の倉庫が既にソーダを十分に仕入れている場合に）拒絶し、ソーダ在庫が不足している可能性がある別の倉庫に転送するルールを含むことができる。もう１つの例をあげると、ソーダのパレットの受取（または他のイベント）は、業務の終了を引き起こすことができる（少なくとも、識別可能な将来について、または特定のａｕｔｏ−ｉｄノード４００がその物体に関連して関係する限り）。

次に、アクティビティ処理器４１４は、イベントの新しい状態を用いてａｕｔｏ−ｉｄシステムを更新する（５１０）。たとえば、受け取った物体の新しい位置を、位置データベース４３０と製品データベース４３２の両方で更新することができる。また、イベントの業務状態は、期待されるアクション４２４、現在の状態４２６、および履歴４２８で更新することができる。たとえば、期待されるアクション４２４は、ルールエンジン４１８からの新たに計算された「期待されるアクション」で更新することができ、現在の状態４２６を、新しい現在の状態として「物体受取済」イベントを用いて更新することができ、物体の以前の状態（たとえば、「輸送中」）を履歴４２８に置くことができる。

次に、アクティビティ処理器４１４は、受け取ったイベントが将来の期待されるアクションとマッチできるか決定する（５１２）。そうである場合には、アクティビティ処理器は、そのイベントを関連するエンタープライズシステムに通信することによって、イベント／アクションの処理を完了し、これによって、エンタープライズシステム内でさらなるアクション／処理を引き起こすことができる（５１４）。

たとえば、アクティビティ処理器４１４は、受け取られた物体に関する期待されるアクション４２４を分析することができ、次に、さまざまな基準を評価して、将来のアクションを行うべきかどうかを決定することができ、たとえば、ルールセット４２０は、物体の期待されるアクションは仕入れアクションを含んでいるか、位置は受け取った物体の位置とマッチするか、現在のタイムスタンプがイベントの有効な時間範囲内か、受け取る倉庫がソーダの在庫量の期待を下回っているか、ソーダのパレットはその倉庫を通って移動し、適当な棚に置くことができるかを決定することができる。もちろん、受け取ったイベントが期待されるアクションとマッチするだろうかを比較するのに使用される、上の例より多数またはより少数の基準があってもよい。

さらに、受け取ったイベントに１つまたは複数の期待されるアクションがあってもよく、それはたとえば、アクティビティ処理器４１４は、期待されるアクションが見つかるか、リストを完全に調べるまで、期待されるアクションのリストを通ってループすることができる。たとえば、物体が、最終目的地へ輸送中である場合に、複数の出荷のために可能な輸送位置があるかもしれない。輸送位置のいずれか１つでの物体の受取は、期待されるアクションへのマッチとして適格を得ることができる。もう１つの例として、「受け取った出荷」イベントは、倉庫管理システムに通信することができ、その結果、倉庫システムが、その在庫レコードを更新できるようになり、さらにまたはその代わりに、「受け取られた出荷」イベントを、製造業者の管理システムに通信することができ、その結果、物体の状態を「出荷済み」に変更できる。

アクティビティ処理器４１４は、受け取ったイベントとマッチする期待されるアクションを見つけられない時、アクティビティ処理器は、受け取ったイベントを期待されないイベントまたは例外として扱うことができる（５１６）。次に、アクティビティ処理器４１４は、たとえば、ローカルオペレータのユーザインターフェースに警告を送り、期待されないアクションについてローカルオペレータに通知することができ、あるいは、別の例外処理システムを引き起こして、期待されないアクションを報告することができる。その一方で、イベントが、他のアクティビティ処理器によっても受け取られる場合には、アクティビティ処理器４１４は、他の処理器がそのイベントを処理する責任を負うことが可能であると決定することができ、警告を発行しないことができる。

まさに説明したように、アクティビティ処理器４１４およびルールエンジン４１８は、このように少なくとも２つの主要で重複する機能のために働く。第１に、それらは、受け取ったイベントが期待されるアクションとマッチするかどうかすなわち、発生したばかりのイベントが発生すると想定（期待）されたかどうかを決定する。第２に、そのイベントが発生すると想定された場合に、ルールエンジン４１８は、期待されるアクションに応答してさらなる何かしらのアクションが行われると想定されるかどうかを決定し、そうであれば、それ相応にさらなるアクションを引き起こす（または、その代わりに、エラー警告を引き起こす）。

図６は、図５の処理で使用され、物理的な物体に関連する業務モデル６００のブロック図である。上で言及したように、業務モデル６００に、物体の状態のシーケンスと、ある状態から次の状態へのあらゆる変化を引き起こすイベントが含まれる。

図６において要素６０２〜６３０は、物体がある状態、過去のある時点であった状態、または将来の時点であり得る状態を表す。さらにくわしくは、各長方形の要素は、物体かつ／または物体のライフサイクル（もしくはその一部）に関連する業務の一部である状態を表す。たとえば、「状態４」６０８は、「輸送中の物体」の状態を表すことができる。楕円形のオブジェクトは、そこから続くイベントに複数の可能性があり得ることを業務モデルが意図する状態を表し、そのようなイベントは、さまざまな状態６０２〜６３０をリンクする遷移矢印６３２〜６６６のうちの複数の矢印によって表される。

結果として図６は、アクティビティ処理器４１４、４１６が、物体のタイムラインに沿った複数の時点を通じて、物体の展開をどのように管理し、期待されるアクションと最初にマッチするイベントの参照される機能性をどのように達成するかと、どの将来のイベントをその後に引き起こすべきかの決定に関して、図４および５に関して上で述べた特徴を概念的に示す。

たとえば、状態６０８は、「輸送中」の状態を表すことができ、その結果、状態６０８は、該当する物体の現在の状態４２６を表し、イベント６３８は、目的の倉庫に置かれたリーダでの物体のＲＦＩＤタグの読取の期待されるイベントを表し、一方で状態６１０は、「倉庫にある」という期待される状態を表す。このように、アクティビティ処理器４１４は、輸送中において物体が状態６０８に「輸送中」が入った後のある点でイベント６３８を受け取るならば、このアクティビティ処理器は、イベント６３８は指定された倉庫へ物体を送るという期待されるアクション（イベント）とマッチすることを決定するために、適切なルールエンジン／ルールセットを使できる。ルールセット６２０のルールは、たとえば、イベントが生成されたのと該当するリーダの位置、イベントのタイミング、または物体自体の識別に基づいて、そのような決定を行うことができる。

イベントが、期待されるイベントとマッチすると仮定すると（そうでない場合には、警告を引き起こすか、またはアクションを行われないだろうという決定を行うことができる）、アクティビティ処理器は、物体の現在の状態を状態６１０に切り替え、状態６０８を履歴または過去の状態に切り替える。次に、アクティビティ処理器は、可能性のある、期待されるイベント６４０、６５４、および６５８のうちのどれが、次に物体によって経験されるべきか決定する。

他の実装において、オペレータは、どの状態６１２、６２４、または６２６が次に経験されるかを決定することができ、次にアクティビティ処理器は、イベント６４０、６５４、または６５８のうちの１つが実際に発生するのを単に待ち、それ相応に状態６１２、６２４、または６２６のうちの１つを選択することができる。もう１つの実施形態で、オペレータは、状態６１２、６２４、または６２６のうちのどれが期待されるかをアクティビティ処理器４１４に通知することができ、その結果、アクティビティ処理器４１４は、対応するイベントが発生した時を決定できるようになる。

図６から、たとえばルールがどのように実装されるかに応じて、特定の物体が業務モデル６００を通じて従うことのできる多数の可能な経路またはタイムラインがあることは明白である。さらに、特定の経路に沿った物体の進行は、現在までの経路に依存することができ、１つまたは複数の将来の可能な経路（状態）にも依存することができる。その結果、ルールセット４２０および４２２を追加し、除去し、または変更することによって、物体の経路またはライフサイクルを、多数の状態およびシナリオにおいて簡単に管理することができる。

たとえば、図６は、農園から小売り食料品店へ出荷されつつある肉または他の農産物のパッケージのライフサイクルを表すことができる。状態６１０は、「倉庫Ａにある」という状態を表すことができ、状態６１２、６２４、および６２６は、「国Ａの受取施設」、「国Ｂの受取施設」、および「国Ｃの受取施設」の状態を表すことができる。

ルールを調べて、状態６１２、６２４、および６２６のうちのどれが可能であり、その結果、たとえば、対応するイベント６４０、６５４、または６５８のうちのどれが受け取られると期待できるかを決定することができる。たとえば、肉または他の農産物の輸入制限に関していくつかの国で農業規制が適用されるかもしれない。その結果、アクティビティ処理器４１４は、状態６１０において、肉出荷が国Ｚの原産であると状態６０２で決定する場合に、この判定で、国ＡおよびＢへの出荷を制限するルールを適用することができる（すなわち、状態６２６への将来のアクションを制限し、その結果、イベント６５８が関連するａｕｔｏ−ｉｄでの期待されるイベントになる）。類似するコメントは、最終の宛先の状態（たとえば、小売り食料品店）６２２など、「将来の」状態に基づくだろうルールにあてはまる。

出荷または他のイベント／状態の制限に関するそのようなルールを動的に修正できることを理解されたい。たとえば、農業規制が特定の国の政府の法令によって解除される場合に、ルールを変更して、以前には何の出荷も許可されていなかった国への肉の出荷を許可するよう修正できる。しかし、それを行う際に、業務モデルおよびａｕｔｏ−ｉｄノード４００の基本アーキテクチャは、維持される。同様に、より多くのルールは、業務に、特別な処理命令、あるいは、特定の製品の元の業務およびライフサイクルへの追加／変更を追加することができる。

そのようなルールは、ａｕｔｏ−ｉｄノードにローカルに追加することができ、これによって、特定のローカルビジネスロジックを処理するための共通のビジネスルールの柔軟な調整が可能になることを理解されたい。このアーキテクチャは、エンタープライズシステムが、たとえば、組織全体のポリシを適用するのを助ける一方で、より低いレベル、たとえばローカルａｕｔｏ−ｉｄレベルでの変化を許可する。このアーキテクチャは、エンタープライズシステムが、必要な場合にルールセットまたはａｕｔｏ−ｉｄノードの他の動作に関する情報を入手できる場合であっても、低レベルのローカルで固有な業務（たとえば、ルールまたはルールセットの形式で表される）の詳細な管理という負担を負わないよう助けることもできる。このアーキテクチャは、エンタープライズシステムに、業務を増大させるための拡張可能なプラットフォームも与える。

図４のａｕｔｏ−ｉｄノードのアーキテクチャの柔軟性のもう１つの例として、アーキテクチャが、業務の事情全般で、所望のルールの時間制限付きの適用を個別に許可することを理解されたい。たとえば、クリスマスシーズン中のクリスマスディスプレイに関する上で言及した例で、ルールセット４２２は、販売用の物体を含む小売店のクリスマスディスプレイ内のａｕｔｏ−ｉｄノードにアップロードすることができる。

ルールセットは、ディスプレイの内容（物体）がある選択された量未満に落ち込んだ時に、その物体の追加単位が特定の製造業者から自動的に再注文されるべきであるというルール４２２を含むことができる。クリスマスの後に、このルールは、非アクティブ化するか、異なる在庫レベルが新しい注文を引き起こすことを指定する新しいルールに置き換えることができる。

アクティビティおよびプロセス管理モジュール４１０のアーキテクチャにおいて、ディスプレイからの物体の除去のそれぞれは、関連するＲＦＩＤリーダからのイベントを引き起こすことができ、そのイベントは、そのリーダに関連するルールを有する在庫アクティビティ処理器にマッチさせることができる。次に、そのルールは、残りの在庫を在庫の「トリガー」量と比較し、在庫の指定されたレベル未満の「期待されるイベント」に達した時に、アクティビティ処理器は、ディスプレイのより多くの関連する物体に注文を引き起こす。

ルールエンジンのアーキテクチャは、ａｕｔｏ−ｉｄノードが他のイベントを処理するのを邪魔せずに、ルール更新を行うことを許可する。たとえば、小売りシステムにおいて、各プロモーションインベントまたはセールイベントを、ルールセットで表すことができ、リストのセール物体の新価格を、そのルールから決定することができる。倉庫管理システムにおいて、季節物体の在庫レベルは、たとえば倉庫の地方気候に応じて、年の異なる時期にまたは倉庫の異なる位置に、異なるルールセットを適用することによって調整することができる。

図６の業務モデルは、アクティビティおよびプロセス管理モジュール４１０のルールを実装するフレームワークの１つの表現にすぎないことを理解されたい。物体またはデバイスの状態および対応するイベントは、いくつかの他のフレームワークによって形作られることができ、あるいは、ルール自体の中で潜在的であることができる。

図７Ａは、図１〜４のａｕｔｏ−ｉｄシステムと共に倉庫環境で使用されるａｕｔｏ−ＩＤ追跡システム７００のブロック図である。図７Ａにおいて、トラッカ７０２は、倉庫環境内での１つまたは複数の資産（たとえば、物理的な物体）の移動に対応する移動データを特定し、監視するのに使用される。さらにくわしくは、移動データは、一般に、１つまたは複数のａｕｔｏ−ｉｄノードに関連する特定の環境（たとえば、図２の製造環境、流通環境、および／または小売り環境）を介して物理的な物体の移動に対応する。すなわち、移動データは、ａｕｔｏ−ｉｄノード７０４によって監視され、維持される環境（たとえば、原料供給業者、製造業者、または小売業者の環境）を介して、資産または資産のタイプの移動に対応する。たとえば、図７Ａに示されているように、倉庫環境を介して資産の移動に対応する移動は、ａｕｔｏ−ｉｄノード７０４によって監視され、維持される。

倉庫環境は、本明細書のこの例の目的のために、一般に、たとえばサプライチェーンの一部として、物理的な物体を受け取り、処理し、保管し、かつ／または出荷することを意図される。そのような倉庫環境は一般に、たとえば図２の物理的な物体２１８に関連するＲＦＩＤタグ２２０から読み取られる物理的な物体に関する情報において、多数のデータ読取ポイント７０６〜７１８が含む。

図１〜４の上記説明から、図７Ａに示されたさまざまなデータ読取ポイント７０６〜７１８は、図１および２のさまざまなデバイスコントローラおよび／またはリーダに対応し、かつ／またはこれらを含むことができることを理解されたい。たとえば、受取ゲート７０６は、物体２１８が倉庫で受け取られるデータ読取点を表す。受取ゲート７０６は、デバイスコントローラ２１２から２１６のうちの１つまたは複数、ならびに／もしくはたとえばＲＦＩＤリーダ１１４などのリーダ１１２〜１２０のうちの１つまたは複数を含むことができる。結果として、物体２１８が受取ゲート７０６で受け取られる時に、識別情報（たとえば、ＳＫＵ番号）を含む情報が、図４に関して説明した状況でタグ２２０から読み取られる。次に、図４に関して説明したように、イベントメッセージは、受取ゲート７０６において生成し、ａｕｔｏ−ｉｄノード７０４に送ることができる。

次に、物体２１８は、たとえば、開梱ステーション７０８、（出荷が、開梱されずに全体で「収納される」）収納ゾーン７１０、貯蔵検査施設７１２、梱包ステーション７１４、荷役ステーション７１６、および／または出荷ドア７１８のような、複数の残りのデータ読取ポイントのうちの１つまたは複数に転送することができる。さまざまなデータ読取ポイント７０６〜７１８の機能の考察は、明白でない範囲まで、下でトラッカ７０２の機能および動作の背景において下に詳細に説明する。

しかし、一般に、物体２１８は、倉庫環境を介して移動する時にデータ読取ポイント７０６〜７１８のうちの一つのさまざまなデータ読取ポイントに出会うかもしれないことを理解されたい。たとえば、物体２１８は、小売り品目の２つのケースのパレットを含むことができる。この物体２１８は、受取ゲート７０６で受け取られ、２つのケースに分離するために開梱ステーション７０８で部分的に開梱できる。次に、１つのケースは荷役ステーション７１６に転送することができ、一方でもう一つは、荷役ステーション７１６に送られる前に、異なる梱包方式（たとえば、別のタイプの小売り商品と一緒に別のパレットに置かれる）に従う再梱包のために梱包ステーション７１４に転送される。その後、両方のケースは、出荷のために出荷ドア７１８に送ることができる。

図７Ａは、複数のデータ読取ポイント７０６〜７１８のそれぞれのうちの単一のデータ読取ポイントに関して上で述べたが、そのような議論は、明瞭さおよび単純さのために提供されることを理解されたい。もちろん、実際の倉庫環境内では、受取ゲート７０６のうちの多く、または複数のデータ読取ポイント７０６〜７１８あるいは他のデータ読取りポイントのうちのいずれかがあるかもしれない。

また、たとえば収納ゾーン７１０のような特定のデータ読取ポイントは、単一の読取位置よりむしろ、一般的な地域（および多数の追跡装置）に関連付けることができ、そのようなものは、特定の受取ゲート（もちろん、特定の受取ゲートに複数のリーダがあってもよい）でより発生しそうである。

図７Ｂに示されているように、倉庫環境に関連するａｕｔｏ−ｉｄノード７０４ａに結び付けられるのに加え、ａｕｔｏ−ＩＤ追跡システムのトラッカ７０２は、サプライチェーン７４０の異なる環境に関連する複数のａｕｔｏ−ｉｄノード７４２ａ〜ｎ、７４４ａ〜ｎ、７０４ａ〜ｎ、７４６ａ〜ｎ、および７４８ａ〜ｎに結びつけられることができる。特に、サプライチェーン７４０は、１つまたは複数の原料供給業者、製造工場、製造流通センタの倉庫、小売り流通センタの倉庫、および小売店を含むことができ、１つまたは複数のａｕｔｏ−ｉｄノードは、それぞれの環境に関連付けることができる。たとえば、ａｕｔｏ−ｉｄノード７４２ａ、７４２ｂ、７４２ｃ、および７４２ｎは、異なる原料供給業者、原料供給業者内の異なる位置、または原料供給業者の異なる処理ステップに関連付けることができる。ａｕｔｏ−ｉｄノード７４４ａ、７４４ｂ、７４４ｃ、および７４４ｎは、異なる製造工場、製造工場内の異なる位置、または製造工場の異なる処理ステップに関連付けることができる。ａｕｔｏ−ｉｄノード７０４ａ、７０４ｂ、７０４ｃ、および７０４ｎは、製造流通センタの異なる倉庫、倉庫内の異なる位置（上で図７Ａについて説明したように）、または倉庫の異なる処理ステップに関連付けることができる。ａｕｔｏ−ｉｄノード７４６ａ、７４６ｂ、７４６ｃ、および７４６ｎは、小売業者の異なる流通センタ倉庫、小売業者の倉庫内の異なる位置（上で図７Ａについて説明したように）、または小売業者の倉庫の異なる処理ステップに関連付けることができる。ａｕｔｏ−ｉｄノード７４８ａ、７４８ｂ、７４８ｃ、および７４８ｎは、異なる小売業者、小売業者内の異なる位置、または小売業者の異なる処理ステップに関連付けることができる。図を明瞭にするため図７には示されていないが、サプライチェーン７４０内のさまざまな環境に関連する各ａｕｔｏ−ｉｄノード７４２ａ〜ｎ、７４４ａ〜ｎ、７０４ａ〜ｎ、７４６ａ〜ｎ、および７４８ａ〜ｎは、データ読取ポイント７０６〜７１８に接続されたａｕｔｏ−ｉｄノード７０４を示す図７Ａに示す例に示されているように、サプライチェーン７４０において１つまたは複数のデータ読取ポイントに接続することができる。

物体２１８は、単一のタグ２２０を有する単一の物体として図示されているが、上の議論から、物体２１８が、一緒に製造するか梱包することができる複数の商品および／または物体がサプライチェーン７４０を通って移動する際に発生する複数のイベントを表すことも理解されたい。すなわち、すぐ上で与えた例のように、物体２１８は、個々の物体またはケースを含む商品のパレット、材料の集合、またはある処理ステップの完了を表すことができる。

サプライチェーン７４０を介する物理的な物体２１８の移動を管理するさまざまな技術は、上の図４〜６の考察から明白である。たとえば、図６のビジネスモデル６００などの業務モデルは、たとえば物体２１８の出所または宛先、物体２１８の販売に関連する小売店の在庫要件、または他のいくつかのビジネス判断基準もしくはビジネスロジックに基づいて、物理的な物体２１８の移動を管理できる。

結果として、データ読取ポイント（たとえば、７０６〜７１８）によって生成され、ａｕｔｏ−ｉｄノード７０４および７４２〜７４８で受け取られる多数のイベントメッセージは、サプライチェーン７４０を介する物体の経路を定義するのに使用することができる。たとえば、業務モデルは、その中でイベントメッセージは特定のデータ読取ポイント（たとえば、７０６〜７１８）で生成され、特定のａｕｔｏ−ｉｄノード（たとえば、７４２ａ、７４４ｃ、７０４ａ、７４６ｂ、および７４８ｎ）によって特定の順序で受け取られる、サプライチェーンを通る物体２１８の経路を定義することができる。

１つの例示的実施例において、業務モデル６００は、錠剤薬の瓶のためのサプライチェーン７４０を通る経路を定義することができる。モデル６００によって定義される経路は、原料が特定の原料供給業者（たとえば、７４２ａ）から調達されること、原料供給業者がある処理ステップに従うことと、ある製造工場（たとえば、７４４ｃ）で薬剤が製造されることと、原料は、特定の製造ラインを通って移動し、製造業者によって特定の技術で処理されることと、製造された薬剤は、特定のルーチンに従って、製造倉庫（たとえば、７０４ａ）に入れられ、出荷されることと、製造された薬剤は、特定のルーチンに従って特定の小売り倉庫（たとえば、７４６ｂ）によって、受け取られ、保管され、小売業者に出荷され、特定の手順に従って特定の小売業者（たとえば、７４８ｎ）によって、受け取られ、保管され、販売されることを要求することができる。

ビジネスモデル６００によって定義されたサプライチェーン経路に沿ったそれぞれのポイントを介する物体２１８の移動は、ａｕｔｏ−ｉｄノード７０４および７４２〜７４８によって追跡と監視できる。たとえば、ある資産（たとえば、錠剤薬の瓶）がサプライチェーンを介して移動する際に、トラッキングデバイス１１２〜１１８からａｕｔｏ−ｉｄノード７４２、７４４、７０４、７４６、および７４８に報告されるイベントメッセージは、サプライチェーンを介する物体の経路を追跡するのに使用することができる。次に、サプライチェーンを介する実際の経路は、サプライチェーンを介する資産の進行を確認するためのビジネスモデルによって定義される所定の経路と比較することができる。

しかし、ＲＦＩＤデバイスの１００％成功読取率を期待することはできず、物理的制限および人員エラーのために、いくつかの読取ポイントが、読取を失敗するかもしれない。所定のフロー経路に基づいて、ストレージのレイアウト配置およびタスク配置など、プロセス最適化により的確なデータを提供するために、履歴データを修正されるかもしれない。

さらに、所定の経路に従わなかった偽造または処理を誤った製品が存在するかもしれない。所定のフロー経路に基づいて、システムは、サプライチェーン内でこれらの偽造または処理を誤った製品を識別することができる。

上の例は、主に、倉庫環境に関して与えられたが、トラッカ７０２は、描かれたａｕｔｏ−ｉｄノードのいずれとも共に、およびたとえば、小売業者、サプライチェーン、製造のようなａｕｔｏ−ｉｄノード、または流通ａｕｔｏ−ｉｄノードなどの他のａｕｔｏ−ｉｄノードと共に使用できることを理解されたい。

さらに、追跡技術は、拡張性があり、図１〜３の上で説明したａｕｔｏ−ｉｄインフラストラクチャ１１０の階層的性質をこのように活用することができる。たとえば、サプライチェーンを介する進行の追跡は、複数のａｕｔｏ−ｉｄノードにまたがって、エンタープライズアプリケーション全体にまたがって、またはサプライチェーン全体にまたがって実行することができる。さらに、多数の資産（たとえば、個々の錠剤、錠剤の瓶、ケース内の瓶、パレット内のケース、出荷内のパレット）の階層的性質を与えられれば、追跡は、複数のレベルにまたがって行うこともできる。

上で説明したように、ａｕｔｏ−ｉｄノード２０６、２０８、２１０、４００は、たとえば１つまたは複数の物体の履歴４２８または現在の状態４２６についての情報を収集することができる。さらに、ａｕｔｏ−ｉｄノード４００は、位置情報４３０、製品情報４３２、業務情報４３４、および他のリソース情報４３６を保守することができる。この情報は、たとえば統合インターフェース４０４、４０６、４０８、または４２７を介する使用のためにエンタープライズアプリケーション１０２、１０４、または１０６に渡すことができ、または、ａｕｔｏ−ｉｄノード４００のストレージ４５０に保管することができ、ａｕｔｏ−ｉｄノード４００から後の使用のために取り出すことができる。多数のａｕｔｏ−ｉｄノード４００のネットワーク内で、豊富な分散情報が存在する。しかし、情報は、企業またはエンタープライズアプリケーションによる使用のために集中化または組織化される必要はない。

図８を参照すると、ａｕｔｏ−ｉｄノードのネットワーク８００からの情報に関する照会を容易にするために、１つまたは複数の組織内のａｕｔｏ−ｉｄノード４００のネットワーク８００の階層構造を定義することができる。

図８で示される例示的なネットワーク８００は、３つの関連する組織８０２、８０４、および８０６内で動作するａｕｔｏ−ｉｄノードを含む。たとえば、第１の組織８０２は、消費財製品を販売する競合するスーパーストア小売業者８０４および８０６に出荷される消費財（たとえば、剃刀の刃）の製造業者とできる。

第１の組織８０２のａｕｔｏ−ｉｄノード８１０〜８４４は、１つまたは複数の流通センタ８１０、８１２、および８１４に関連する１つまたは複数のａｕｔｏ−ｉｄノードが、倉庫８２０、８２２、および８２４に関連する１つまたは複数のａｕｔｏ−ｉｄノードの上位である階層に組織化できる。各倉庫８２０、８２２、および８２４は、１つまたは複数の上位流通センタ８１０、８１２、および８１４と、１つまたは複数の下位発送センタ８３０、８３２、および８３４に関連付けることができる。各発送センタ８３０、８３２、および８３４は、１つまたは複数のトラック８４０、８４２、および８４４に関連付けることができ、これらのトラック８４０、８４２、および８４４に、消費財のパレットは、スーパーストア小売業者８０４または８０６への配送のために発送センタ８３０、８３２、および８３４から積載される。各発送センタは、製品のパレットを輸送するトラック８４０、８４２、および８４４に関連付けることもできる。

第１の組織８０２の異なるレベル８１０〜８４４に関連するａｕｔｏ−ｉｄノードの階層構造は、ａｕｔｏ−ｉｄノードに課されるインデックス方式によって定義し、保守することができる。たとえば、ａｕｔｏ−ｉｄノードを、ａｕｔｏ−ｉｄノードのネットワーク８００の１つまたは複数の他のａｕｔｏ−ｉｄノードに関連付ける１つまたは複数のポインタは、ａｕｔｏ−ｉｄノード４００のインデックス４４２で保守することができる。そのポインタは、ノードのネットワーク８００内の異なるａｕｔｏ−ｉｄノード４００の間の階層関係を定義して構造化することができる。この階層を、動的とすることができ、異なるａｕｔｏ−ｉｄノードのインデックス４４２に格納されたポインタは、異なる目的のための異なる階層を定義するために変えられる。たとえば、第１の組織は、男性用剃刀と女性用剃刀の両方を作るかもしれない。異なる製品が、異なる流通センタ８１０、８１２、および８１４から出荷され、異なる倉庫８２０、８２２、および８２４に格納されるかもしれないので、ポインタは、異なる製品の流通を表すために異なる階層を定義するために、ネットワークのａｕｔｏ−ｉｄノード４００のインデックス４４２に格納することができる。

同様に、スーパーストア小売業者８０４または８０６のうちの１つのａｕｔｏ−ｉｄノード８６０〜８９４は、ａｕｔｏ−ｉｄノード８６０〜８９４は他のノードの上位および／または下位としてそのノードを定義するインデックス４４２内の１つまたは複数のポインタが含む階層に組織することができる。たとえば、１つまたは複数の受取センタ８６０、８６２、および８６４に関連するａｕｔｏ−ｉｄノードは、受け取る倉庫８７０、８７２、および８７４に関連するａｕｔｏ−ｉｄノードの上位とすることができる。小売業者倉庫８７０、８７２、および８７４のうちの１つまたは複数は、小売店８８０、８８２、および８８４に関連する１つまたは複数のａｕｔｏ−ｉｄノードの上位ノードとすることができ、小売店８８０、８８２、および８８４に関連するａｕｔｏ−ｉｄノードのうちの１つまたは複数は、店内の売り場または棚８９０、８９２、および８９４に関連するａｕｔｏ−ｉｄノードの上位とすることができる。

インデックス方式によってａｕｔｏ−ｉｄネットワーク８００に課せられた階層で、分散形でネットワーク８００内に格納する情報は、そのネットワークからすばやく効率的に取り出すことができる。たとえば、ａｕｔｏ−ｉｄノード４００は、ノードによって検出された物体の履歴４２８および／または現在の状態４２６を格納することができる。この情報を中央データベースに渡さずに、またはこの情報を中央データベースに渡すと共に、この情報は、個々のａｕｔｏ−ｉｄノードのストレージ４５０に格納することができる。その後、ネットワーク８００が、１つまたは複数のａｕｔｏ−ｉｄノード４００によって読み取られた品目についての情報を照会する時、その情報は、要求された情報の位置が見つかり、回復されるまで、ネットワーク８００を介して、インデックス方式を掘り下げるために課せられる階層に従って、ノードから抽出することができる。

たとえば、製造業者８０２が、それが作り、出荷したある製品（たとえば、特定の通し番号によって特定される時）が欠陥品であり、リコールされなければならないと決定すると、その製造業者は、組織化され機能化されたネットワークを検索することによって、製品の位置を決定することができる。この検索は、ある製品がどの流通センタにあるかまたはどの流通センタを通過したかを決定するためにａｕｔｏ−ｉｄノード８１０、８１２、および８１４を照会することによって開始することができる。照会に対して否定の結果を返す流通センタのａｕｔｏ−ｉｄノード（たとえば、流通センタ８６２および８６４）およびその下位の関連するａｕｔｏ−ｉｄは、検索から除去できる。照会に対して肯定の応答を返す流通センタ８１０にとって、流通センタ８１０に関連する下位ａｕｔｏ−ｉｄノード８２０、８２２、および８２４を照会できる。同じように、製品が通過した倉庫８２０に関連する発送センタ８３０、８３２、および８３４に対応する下位ａｕｔｏ−ｉｄノードは照会することができ、以下同様である。このように、インデックス方式によってノードのネットワーク８００に課せられる階層構造に従うことによって、欠陥製品の位置を決定できる。

上で説明した組織内階層構造に加えて、このインデックス方式は、ａｕｔｏ−ｉｄノードの組織間階層構造を定義するために拡張することができる。たとえば、第２の組織８０４は、第１の組織８０２によって作られ、第２の組織に出荷される製品に付随するａｕｔｏ−ｉｄノード８６０〜８９４のストレージ４５０内に含まれる情報に、第１の組織８０２がアクセスするのを許可することができる。そのようなアクセスを用いて、第１の組織８０２は、第１の組織のノード８１０〜８４４に照会することに加えて、トップダウン形（たとえば、ノード８６０、８６２、および８６４から開始し、階層構造の下に進行して）で、第２の組織に関連するａｕｔｏ−ｉｄノード８６０〜８９４を機能的かつ効率的に照会することができる。

さらに、ノードのネットワーク８００の階層構造を拡張するために、第１の組織８０２のａｕｔｏ−ｉｄノード８１０〜８４４と第２の組織のノードの間で関連付けを作成できる。たとえば、第１の組織８０２からの製品が、トラック８４０によって第２の組織８０４に出荷される時、その製品は、トラック８４０によって第２の組織の受取センタ８６０または受取倉庫８７０に配送することができる。したがって、受取センタ８６０および／または受取倉庫８７０に関連するａｕｔｏ−ｉｄノードは、第１の組織８０２の観点から、トラック８４０または発送センタ８３０に関連するノードの下位とすることができる。

本発明は、ディジタル電子回路、コンピュータハードウェア、ファームウェア、ソフトウェア、またはこれらの組合せにおいて実装することができる。本発明は、データ処理装置（たとえばプログラム可能なプロセッサ、コンピュータ、多数のコンピュータ）によって実行されるか、またはその動作を制御するために、コンピュータプログラム製品（すなわち、情報媒体（たとえば機械可読記憶装置または伝搬される信号において）で明白に実施されるコンピュータプログラム）として実装できる。コンピュータプログラムは、コンパイルされる言語およびインタープリタ言語を含む任意の形のプログラミング言語で記述でき、独立プログラム、モジュール、コンポーネント、サブルーチン、またはコンピューティング環境での使用に適する他のユニットを含む、任意の形で展開することができる。コンピュータプログラムは、１つのコンピュータ上、または、１つの場所あるいは複数の場所にまたがって分散る複数のコンピュータに上で、実行するために展開することができ、通信ネットワークによって相互接続することができる。

本発明の方法ステップは、入力データを動作し、出力を生成することによって本発明の機能を実行するためにコンピュータプログラムを実行する１つまたは複数のプログラム可能なプロセッサによって実行することができる。方法ステップは特殊用途の論理回路、たとえばＦＰＧＡ（Field Programmable Gate Away）またはＡＳＩＣ（Application Specific Integrated Circuit）で実行でき、本発明の装置はこれらとして実装することができる。

コンピュータプログラムの実行に適するプロセッサは、たとえば、汎用および特殊用途のマイクロプロセッサと、あらゆる種類のディジタルコンピュータの１つまたは複数のプロセッサの両方といった例を含む。一般に、プロセッサは、命令およびデータを、読取専用メモリまたはランダムアクセスメモリあるいはその両方から受け取るだろう。コンピュータの本質的な要素は、命令を実行するプロセッサと、命令およびデータを格納するための１つまたは複数の記憶装置である。一般に、コンピュータは、データを格納するための１つまたは複数の大容量記憶装置（たとえば磁気ディスク、光磁気ディスク、または光ディスク）もまた含み、あるいは、これからデータを受け取るか、これにデータを送るか、その両方へ動作可能なように連結する。コンピュータプログラム命令とデータを具体化するのに適する情報媒体は、たとえば、半導体メモリデバイス（たとえばＥＰＲＯＭ、ＥＥＰＲＯＭ、およびフラッシュメモリデバイス）と、内蔵ハードディスクおよび取外し可能ディスクなどの磁気ディスクと、光磁気ディスクと、ＣＤ−ＲＯＭディスクおよびＤＶＤ−ＲＯＭディスクといった例を含む、不揮発性媒体のすべての形が含まれる。プロセッサおよびメモリは、特殊目的の論理回路によって増補されるか、またはこれに組み込むことができる。

ユーザとの相互作用を提供するために、本発明は、ユーザに情報を表示するための、ＣＲＴ（陰極線管）またはＬＣＤ（液晶ディスプレイ）モニタなどのディスプレイデバイスと、ユーザがコンピュータに入力を提供できるようにする、マウスまたはトラックボールなどのポインティングデバイスおよびキーボードを有するコンピュータ上で実装できる。他の種類のデバイスは、ユーザとの相互作用を提供するために使用でき、たとえば、ユーザに提供するフィードバックは、視覚フィードバック、聴覚フィードバック、または触覚フィードバックなどのあらゆる形の感覚的フィードバックとすることもでき、ユーザからの入力は、音響、音声、または触覚入力を含むあらゆる形で受け取ることができる。

本発明は、バックエンドコンポーネント（たとえばデータサーバ）、またはミドルウェアコンポーネント（たとえばアプリケーションサーバ）、またはフロントエンドコンポーネント（たとえばユーザがそれを介して本発明の実装と相互作用できるグラフィカルユーザインターフェースまたはウェブブラウザを有するクライアントコンピュータ）、またはそのようなバックエンドコンポーネント、ミドルウェアコンポーネント、もしくはフロントエンドコンポーネントのあらゆる組合せを含むコンピューティングシステムで実装できる。このシステムのコンポーネントは、ディジタルデータ通信（たとえば通信ネットワーク）の任意の形または媒体によって相互接続することができる。通信ネットワークの例は、ローカルエリアネットワーク（「ＬＡＮ」）、高域ネットワーク（「ＷＡＮ」）、およびインターネットを含む。

コンピューティングシステムは、クライアントおよびサーバを含むことができる。クライアントおよびサーバは、一般に、互いに離れており、通常、通信ネットワークを介して相互作用する。クライアントとサーバの関係は、それぞれのコンピュータ上で動作し、互いにクライアント−サーバ関係を有するコンピュータプログラムの効力によって生じる。

多くの実施例を説明した。それにもかかわらず、さまざまな変更がなされ得ることを理解されたい。したがって、他の実施形態は、添付の請求の範囲内である。

ａｕｔｏ−ｉｄシステムを示すネットワーク図である。 ａｕｔｏ−ｉｄノードおよびデバイスコントローラを有するａｕｔｏ−ｉｄインフラストラクチャを含む、図１のａｕｔｏ−ｉｄ特徴の例を示すシステムを示すブロック図である。 図２のａｕｔｏ−ｉｄインフラストラクチャと共に使用するネットワークアーキテクチャのブロック図である。 図２および図３のａｕｔｏ−ｉｄノードのブロック図である。 図２〜４のａｕｔｏ−ｉｄノードの処理を示すフロー図である。 図５の処理に使用される業務モデルのブロック図である。 図１〜４のａｕｔｏ−ｉｄシステムと共に使用される追跡システムのブロック図である。 サプライチェーンが通うさまざまな環境のブロック図である。 ａｕｔｏ−ｉｄノードのネットワークのブロック図である。

Claims (20)

1. ａｕｔｏ−ｉｄノードのネットワークと、プロセッサとを含むシステムであって、
   前記ａｕｔｏ−ｉｄノードの各々は、当該ａｕｔｏ−ｉｄノードと前記ネットワーク内の別のａｕｔｏ−ｉｄノードとの間の階層関係を定義するインデックスデータを含み、
   前記ａｕｔｏ−ｉｄノードは、当該ａｕｔｏ−ｉｄノードによって読み取られた１つまたは複数の資産に関する状態データおよび履歴データを保管するストレージを含み、
   前記プロセッサは、前記ネットワーク内の選択されたａｕｔｏ−ｉｄノードだけに照会するために、前記ａｕｔｏ−ｉｄノード内のインデックスデータに従うことによって、前記ａｕｔｏ−ｉｄノードのネットワークからデータを抽出するように動作可能であって、
   前記選択されたノードは、前記ａｕｔｏ−ｉｄノードのインデックスによって定義される階層ネットワークに配置される
   ことを特徴とするシステム。
2. 前記資産は、物理的な物体であることを特徴とする請求項１に記載のシステム。
3. 前記資産は、前記ａｕｔｏ−ｉｄノードによって識別される識別子に関連づけられることを特徴とする請求項１に記載のシステム。
4. 前記識別子は、ＲＦＩＤタグであることを特徴とする請求項３に記載のシステム。
5. 前記ａｕｔｏ−ｉｄノードは、前記資産が前記ａｕｔｏ−ｉｄノードで識別される時刻を追跡するように動作可能であることを特徴とする請求項１に記載のシステム。
6. 前記ａｕｔｏ−ｉｄノードは、少なくとも１つのノードと通信する自動識別デバイスを含み、前記システムを介した前記資産の進行について前記ノードから提供されるデータを受け取るように動作可能であることを特徴とする請求項１に記載のシステム。
7. 前記資産の識別子を受け取るよう動作可能なユーザインターフェースをさらに含むことを特徴とする請求項１に記載のシステム。
8. 前記ａｕｔｏ−ｉｄノードのネットワークは、単一の組織に関連するａｕｔｏ−ｉｄノードを含むことを特徴とする請求項１に記載のシステム。
9. 前記ａｕｔｏ−ｉｄノードのネットワーク内の異なるａｕｔｏ−ｉｄノードは、異なる組織に関連することを特徴とする請求項１に記載のシステム。
10. ａｕｔｏ−ｉｄノードによって読み取られた１つまたは複数の資産ついての状態および履歴データを格納するストレージを各々が含むａｕｔｏ−ｉｄノードのネットワーク内で、ａｕｔｏ−ＩＤシステム内の異なるａｕｔｏ−ｉｄノードとの間の階層関係を定義するステップと、
    第１ａｕｔｏ−ｉｄノードを第２ａｕｔｏ−ｉｄノードに関係づけるインデックスを、前記第１ａｕｔｏ−ｉｄノードに保管するステップと、
    前記ネットワーク内の選択されたａｕｔｏ−ｉｄノードだけに照会するために、前記ａｕｔｏ−ｉｄノード内のインデックスデータに従うことによって、ａｕｔｏ−ｉｄノードの前記ネットワークからデータを抽出するステップとを含み、
    前記選択されたノードは、前記ａｕｔｏ−ｉｄノードのインデックスによって定義される階層ネットワークに配置されることを特徴とする方法。
11. 前記資産は、物理的な物体であることを特徴とする請求項１０に記載の方法。
12. 前記資産を前記ノードによって識別される識別子に関連付けるステップをさらに含むことを特徴とする請求項１０に記載の方法。
13. 前記識別子は、ＲＦＩＤタグであることを特徴とする請求項１２に記載の方法。
14. 資産がａｕｔｏ−ｉｄノードによって識別される時刻についてのタイミングデータを格納するステップをさらに含むことを特徴とする請求項１０に記載の方法。
15. 前記ａｕｔｏ−ｉｄノードのネットワークは、単一の組織に関連するａｕｔｏ−ｉｄノードを含むことを特徴とする請求項１０に記載の方法。
16. 前記ａｕｔｏ−ｉｄノードのネットワーク内の異なるａｕｔｏ−ｉｄノードは、異なる組織に関連することを特徴とする請求項１０に記載の方法。
17. ａｕｔｏ−ｉｄノードによって読み取られた１つまたは複数の資産についての状態および履歴データを格納するストレージをそれぞれ含むａｕｔｏ−ｉｄノードのネットワーク内で、ａｕｔｏ−ＩＤシステムの異なるａｕｔｏ−ｉｄノードの間の階層関係を定義することと、
    第１ａｕｔｏ−ｉｄノードを第２ａｕｔｏ−ｉｄノードに関係させるインデックスを、前記第１ａｕｔｏ−ｉｄノードに格納することと、
    選択されたａｕｔｏ−ｉｄノードが前記ａｕｔｏ−ｉｄノードのインデックスによって定義される階層ネットワークに配置され、前記ネットワーク内の選択されたａｕｔｏ−ｉｄノードだけを照会するために、前記ａｕｔｏ−ｉｄノード内のインデックスデータに従うことによって、ａｕｔｏ−ｉｄノードの前記ネットワークからデータを抽出することと
    を、１つまたは複数のプロセッサにさせる実行可能命令を含む機械可読記憶媒体。
18. 前記１つまたは複数のプロセッサに、前記資産を前記ノードによって識別される識別子に関連付けることをさせる実行可能命令をさらに含むことを特徴とする請求項１７に記載の機械可読記憶媒体。
19. 前記識別子は、ＲＦＩＤタグであることを特徴とする請求項１８に記載の機械可読記憶媒体。
20. 前記ａｕｔｏ−ｉｄノードのネットワーク内の異なるａｕｔｏ−ｉｄノードは、異なる組織に関連することを特徴とする請求項１７に記載の機械可読記憶媒体。
    

Images