(57)【要約】  品目のリアル・タイム及びコンテキスト認識追跡（１１６）のための、コンピュータ・プログラム生産物を含む方法及び装置を提供する。品目に結合されているタグ（１０２）を読み取り、タグから読み取った情報、及びタグについての位置情報を、少なくとも２つの企業によって供給し、品目についての処置情報を、供給連鎖内の企業に可視化して保持する。処置情報は、品目と、品目に影響を及ぼす情報、例えば、地空間的イベントや交通の遅れを追跡するワールド・モデルにマッピングすることができる。処置情報の可視性は、許可によって制御することができる。可視情報は、特定の品目と、発注及び出荷文書のような業務文書との間の関係を含むことができる。
2005515135.tif 000002
【特許請求の範囲】
【請求項１】
コンテキスト認識及びリアル・タイム品目追跡の方法であって、
タグ・リード・データの多数のインスタンスを受信するステップであって、各インスタンスが、品目に結合されたタグから読み取った情報を含み、該読み取った情報が、前記タグから自動的に読み取った一意のディジタル識別子を含み、各インスタンスが、対応するタグの位置、及び一意の識別子が前記タグから読み取られたときのその結合品目を含むステータス情報を含み、前記タグ・リード・データの多数のインスタンスが、一括して、多数の品目に結合されたタグから読み取った情報を含む、ステップと、
コンテキスト情報の１つ以上のインスタンスを受信するステップであって、各インスタンスが、関連するタグ付け不可能な物理的状況を記述し、前記コンテキスト情報が、前記状況の位置を含むステータスを示し、前記コンテキスト情報の多数のインスタンスが、一括して、多数の状況を記述する情報を含む、ステップと、
前記受信したタグ・リード・データ及びコンテキスト情報を用いて、仮想ワールドにおける仮想品目及び仮想状況を保持するステップであって、前記仮想品目が、前記多数の商品の各々のオブジェクトを含み、前記仮想状況が、前記多数の状況の各々のオブジェクトを含み、前記オブジェクトの各々が、その対応する品目又は状況のステータスを表す、ステップと、
前記仮想品目及び仮想状況によって表される前記状況及び前記品目の間において、前記仮想ワールドで発生する相互作用を検出するステップと
からなることを特徴とする方法。
【請求項２】
請求項１記載の方法において、
前記物品及び状況に関する前記仮想ワールドにおける情報を、時間、三次元空間、及び一意の識別子からなる仮想ワールド全域の標準化次元にマッピングすることによって、前記物品及び状況を、空間及び時間において、互いに対して追跡可能とした
ことを特徴とする方法。
【請求項３】
請求項１記載の方法において、該方法は更に、
検出した相互作用が、前記多数の物品のいずれかに影響を及ぼすと判断したときには、常に、前記仮想ワールドのユーザに警報を発生するステップ
を含み、前記ユーザが人又はコンピュータ・プログラムであることを特徴とする方法。
【請求項４】
請求項１記載の方法において、該方法は更に、
前記仮想ワールドに、前記物品それぞれの現在地の表現と、前記状況それぞれの現在地の表現とを維持するステップ
を含み、これら表現は各々、最後に受信したタグ・リード・データ及びコンテキスト情報を反映していることを特徴とする方法。
【請求項５】
請求項４記載の方法において、該方法は更に、
位置及び状況を緯度、経度、及び高度で表すステップ
を含むことを特徴とする方法。
【請求項６】
請求項４記載の方法において、該方法は更に、
前記物品の位置の履歴、及び前記状況の位置の履歴を保持するステップ
を含むことを特徴とする方法。
【請求項７】
請求項５記載の方法において、該方法は更に、
前記物品の位置の履歴に基づいて、前記物品の少なくとも１つの今後の位置の予測を、前記仮想ワールドから得るステップ
を含むことを特徴とする方法。
【請求項８】
請求項７記載の方法において、該方法は更に、
前記状況の位置の履歴にも基づいて、前記今後の位置の予測を得るステップ
を含むことを特徴とする方法。
【請求項９】
請求項１記載の方法において、該方法は更に、
前記仮想ワールドに、前記物品それぞれの現状態の表現と、前記状況それぞれの現状態の表現とを保持するステップ
を含み、これら表現はそれぞれ、最後に受信したタグ・リード・データ及びコンテキスト情報を反映していることを特徴とする方法。
【請求項１０】
請求項９記載の方法において、該方法は更に、
前記物品の状態の履歴、及び前記状況の状態の履歴を保持するステップ
を含むことを特徴とする方法。
【請求項１１】
請求項１０記載の方法において、該方法は更に、
前記物品の状態の履歴に基づいて、前記物品の少なくとも１つの今後の状態の予測を、前記仮想ワールドから得るステップ
を含むことを特徴とする方法。
【請求項１２】
請求項１１記載の方法において、該方法は更に、
前記状況の状態の履歴にも基づいて、前記今後の状態の予測を得るステップ
を含むことを特徴とする方法。
【請求項１３】
請求項１又は請求項８記載の方法において、該方法は更に、
タグ・リード・データ及びコンテキスト情報の各インスタンスにタイム・スタンプを関連付けるステップ
含み、各タイム・スタンプを単一の規格に同期させていることを特徴とする方法。
【請求項１４】
請求項１記載の方法において、
前記タグ付け不可能な状況は、天候に関する状況を含み、
前記天候に関する状況の位置を、少なくとも経度、緯度、及び高度によって記述する
ことを特徴とする方法。
【請求項１５】
請求項１記載の方法において、
前記タグ付け不可能な状況は、交通事故を含み、
前記交通事故の位置を、少なくとも経度、緯度、及び高度によって記述する
ことを特徴とする方法。
【請求項１６】
請求項１記載の方法において、該方法は更に、
階層情報の１つ以上のインスタンスを受信するステップであって、各インスタンスが、前記仮想ワールドにおいて表される物品間の階層を記述する、ステップと、
前記受信した階層情報を用いて、前記仮想ワールドにおいて、各々前記階層の１つを表すコンテキスト・オブジェクトを保持するステップと
を含むことを特徴とする方法。
【請求項１７】
請求項１６記載の方法において、
前記階層の少なくとも１つは、いくつかの特定の物品が別の物品内に収容されている、物品間の関係であることを特徴とする方法。
【請求項１８】
請求項１記載の方法において、該方法は更に、
第１物品に付帯するセンサから得たセンサ情報を受信するステップと、
前記第１物品に対する第１物理的オブジェクトを前記センサ情報を用いて更新するステップと
を含むことを特徴とする方法。
【請求項１９】
請求項１記載の方法において、コンテキスト情報を受信するステップは、
外部システムからコンテキスト情報のインスタンスを受信するステップ
を含むことを特徴とする方法。
【請求項２０】
請求項１記載の方法において、コンテキスト情報を受信するステップは、
コンテキスト情報のインスタンスを受信するステップであって、前記インスタンスが、特定の位置に付帯するセンサからの遠隔測定データを含んでいる、ステップ
を含むことを特徴とする方法。
【請求項２１】
請求項２０記載の方法において、該方法は更に、
特定の地点又は区域に付帯するセンサによって発生され、前記特定の地点又は区域において発生する状況を表す遠隔測定データを受信するステップと、
前記仮想ワールドが、前記遠隔測定データによって表される状況によって影響を受ける物品が、前記地点又は前記仮想ワールドにおいて表される区域にあることを検出したときに、前記仮想ワールドのユーザに警報を発生するステップであって、前記ユーザが人又はコンピュータ・プログラムである、ステップと
を含むことを特徴とする方法。
【請求項２２】
請求項２０記載の方法において、該方法は更に、
特定の地点又は区域に付帯するセンサによって発生され、前記仮想ワールドにおけるコンテキスト・オブジェクト内の前記地点又は区域の現在の温度を表す温度データを受信するステップと、
前記仮想ワールドが、前記現在の温度によって影響を受ける物品が前記地点又は区域においてであることを検出したときに、前記物品及び現在の温度を前記仮想ワールドにおいて表して前記仮想ワールドのユーザに警報を発生するステップであって、前記ユーザが人又はコンピュータ・プログラムである、ステップと
を含むことを特徴とする方法。
【請求項２３】
請求項１記載の方法において、該方法は更に、
物理的オブジェクトに温度例外を付与するステップと、
前記温度例外を満たすときに、アクションを実行させるステップと
を含むことを特徴とする方法。
【請求項２４】
請求項２３記載の方法において、
前記アクションは、ユーザに警報を発生することからなり、前記ユーザは人又はコンピュータ・プログラムであることを特徴とする方法。
【請求項２５】
請求項１記載の方法において、該方法は更に、
物理的オブジェクトにルールを付与するステップであって、前記ルールが、前記仮想ワールドにおける現在の情報に応じて、トリガ・イベントを引き起こすか、又はアクションを実行させるように動作可能である、ステップ
を含むことを特徴とする方法。
【請求項２６】
請求項１記載の方法において、該方法は更に、
コンテキスト・オブジェクトにルールを付与するステップであって、前記ルールが、前記仮想ワールドにおける現在の情報に応じて、トリガ・イベントを引き起こすか、又はアクションを実行させるように動作可能である、ステップ
を含むことを特徴とする方法。
【請求項２７】
請求項１記載の方法において、該方法は更に、
物品が前記仮想ワールドにおいて表されている現時点又は表されていた過去の時点における前記物品のステータスに関するクエリを受信し、処理し、応答するステップ
を含むことを特徴とする方法。
【請求項２８】
請求項２７記載の方法において、該方法は更に、
現在又は過去の時点における特定の物品に対して特定の関係を有する物品が、前記仮想ワールドにおいて表されている場合、又は表されていた場合、前記物品及び特定の製品のステータスに関するクエリを受信し、処理し、応答するステップ
を含むことを特徴とする方法。
【請求項２９】
品目に結合されている書き込み可能タグ上のデータを更新する方法であって、
システムにおいて、第１品目についての第１属性情報を受信するステップであって、前記第１属性情報が、前記第１品目に結合されている第１タグから自動的に読み取ったデータから得たものであり、前記第１属性情報が、前記第１品目を識別する第１識別子を含む、ステップと、
前記システムにおいて、第２品目についての第２属性情報を受信するステップであって、前記第２属性情報が、前記第２品目に結合されている第２タグから自動的に読み取ったデータから得たものであり、前記第２属性情報が、前記第２品目を識別する第２識別子を含む、ステップと、
前記システムにおいて、前記第１品目と前記第２品目との間の関係を指定する関係情報を受信するステップと、
前記システムにおいて、前記第１及び第２品目をそれぞれ表す第１及び第２仮想品目を保持するステップであって、前記オブジェクトがそれぞれ、前記第１属性情報及び前記第２属性情報を表す情報と、センサ情報とを表し、前記システムにおいて、前記第１及び第２品目間の前記関係を表す仮想状況を保持するステップと、
前記物理的及び仮想状況における情報から警報条件を認識するステップであって、前記警報条件が前記第１品目に関係する、ステップと、
前記警報条件に応答して、前記第１品目に書き込む更新属性情報を発生するステップと、
前記システムにおいて、前記警報条件を認識した後に、タグ・ライタ・ステーションにおいて前記第１タグの存在を検出するステップと、
前記タグ・ライタ・ステーションにおける前記第１タグの存在を検出したときに、前記タグ・ライタ・ステーションに、前記第１タグに前記更新情報を書き込ませるステップと
からなることを特徴とする方法。
【請求項３０】
請求項２９記載の方法において、
前記警報条件は、前記システム外部のアプリケーションにおいて認識され、前記アプリケーションは、前記システムによって保持されているオブジェクトから前記システム情報を受信し、
前記更新属性情報を前記第１タグに書き込む要求によって、前記更新属性情報は、前記アプリケーションによって発生され、前記アプリケーションによって前記システムに供給され、
前記システムは、前記要求に応答して、前記タグ・ライタ・ステーションに、前記更新情報を前記第１タグに書き込ませる
ことを特徴とする方法。
【請求項３１】
請求項３０記載の方法において、
前記第１及び第２仮想品目は、前記システムによって保持されている仮想ワールドにおける、その対応する品目を表し、
前記アプリケーションは、前記仮想ワールドを監視する
ことを特徴とする方法。
【請求項３２】
請求項２９記載の方法において、
前記警報条件は、前記システムに供給される１つ以上の警報ルールに応じて動作する前記システムのコンポーネントによって認識され、
前記更新情報は、前記システムに供給される１つ以上の更新ルールに応じて動作する前記システムのコンポーネントによって認識され、
前記タグ・ライタ・ステーションにおいて、前記システムに供給される１つ以上のライト・データ・ルールに応じて、前記第１タグに前記更新情報を書き込む
ことを特徴とする方法。
【請求項３３】
請求項２９記載の方法において、前記センサは前記第２タグに結合されていることを特徴とする方法。
【請求項３４】
請求項２９記載の方法において、前記センサは温度センサであることを特徴とする方法。
【請求項３５】
請求項３４記載の方法において、
前記警報条件は、前記センサが測定する温度が閾値を超えたときに発生され、
前記更新情報は、前記第１品目に対する生産物有効期限の短縮である
ことを特徴とする方法。
【請求項３６】
請求項２９記載の方法において、前記第１タグは、無線周波数トランスポンダであることを特徴とする方法。
【請求項３７】
請求項２９記載の方法において、前記第１及び第２識別子は、一意の識別子であることを特徴とする方法。
【請求項３８】
商業データ処理環境において実行する方法であって、前記環境は供給連鎖における多数の企業を含み、前記方法は、前記企業に、前記供給連鎖における品目の処置のリアル・タイムの可視性を与えるステップを含み、該ステップは、
第１企業から、タグ・リード・データの多数のインスタンスを受信するステップであって、各インスタンスが品目に結合されているタグから読み取った情報を含み、前記読み取った情報が、前記タグから自動的に読み取った一意のタグを含み、各インスタンスは、タグ識別子が前記タグから読み取られたときの対応するタグの位置及びそれに結合されている品目も含み、前記第１企業から受信したタグ・リード・データの多数のインスタンスは、多数の品目に結合されているタグから読み取った情報を一括して含む、ステップと、
前記第１企業から受信した前記タグ・リード・データを用いて前記品目についての処置情報を保持するステップと、
第２企業から、第２タグ・リード・データの多数のインスタンスを受信するステップであって、各インスタンスが、品目に結合されているタグから読み取った情報を含み、該読み取った情報が、前記タグから自動的に読み取った一意のタグ識別子を含み、各インスタンスは、タグ識別子が前記タグから読み取られたときの対応するタグの位置及びそれに結合されている品目も含み、前記第２企業から受信したタグ・リード・データの多数のインスタンスは、前記多数の品目の少なくとも１つに結合されているタグから読み取った情報を一括して含む、ステップと、
前記第２企業から受信した前記タグ・リード・データを用いて、前記品目についての処置情報を保持するステップであって、前記いずれかの企業から特定の品目について受信したタグ・リード・データを用いて、前記処置情報を更新する、ステップと、
前記第１及び第２企業を含む前記供給連鎖する多数の企業に、前記処置情報を可視化するステップと
からなることを特徴とする方法。
【請求項３９】
請求項３８記載の方法において、該方法は更に、
第３企業から、第３タグ・リード・データの多数のインスタンスを受信するステップであって、各インスタンスが品目に結合されているタグから読み取った情報を含み、前記読み取った情報が、前記タグから自動的に読み取った一意のタグ識別子を含み、各インスタンスは、前記タグ識別子を前記タグから読み取ったときの前記対応するタグの位置及びそれに結合されている品目も含み、前記第３企業から受信したタグ・リード・データの前記多数のインスタンスが、前記多数の品目の少なくとも１つに結合されているタグからの情報を一括して含む、ステップと、
前記第３企業からのタグ・リード・データを用いて前記品目についての処置情報を保持するステップであって、いずれかの企業から特定の品目について受信したタグ・リード・データを用いて前記処置情報を更新する、ステップと
を含むことを特徴とする方法。
【請求項４０】
請求項３８記載の方法において、
前記多数の品目に結合されている前記タグはそれぞれ、無線周波数識別子（ＲＦＩＤ）タグを含み、各ＲＦＩＤタグは、電子製品コード（ｅＰＣ）を一意のタグ識別子として担持することを特徴とする方法。
【請求項４１】
請求項３８記載の方法において、
前記可視性は、制御された可視性であり、
前記方法は、更に、
前記処置情報を前記供給連鎖における特定の企業に対して可視化する範囲を示す許可情報を受信するステップと、
前記許可情報によって許可された処置情報のみを、前記特定の企業に可視化するステップと
を含むことを特徴とする方法。
【請求項４２】
請求項４１記載の方法において、
前記処置情報は、複数の品目属性を含み、
前記許可情報は、前記品目属性の少なくとも１つについて、該品目属性を可視化できる企業を指定する
ことを特徴とする方法。
【請求項４３】
請求項３８記載の方法において、
前記多数の企業は、供給元企業と宛先企業とを含み、
前記供給元企業は、前記宛先企業が行った発注に対する発注文書と、前記宛先企業が行った発注を満足するように用意した商品の物理的出荷に対する出荷文書とを有し、
可視性は、前記タグ・リード・データと、前記発注文書及び出荷文書を含む業務文書との間の関係の可視性を含み、
前記品目の処置のリアル・タイムの可視性を前記企業に与えるステップは更に、
出荷情報を受信するステップであって、出荷情報が、
前記出荷における承認に対応する品目に対するタグ識別子と、
各タグ識別子を前記出荷文書の出荷番号と関連付ける情報と、
前記集荷番号を前記発注文書の発注番号に関連付ける情報と、
を含む、ステップと、
前記タグ・リード・データを前記出荷情報と相関付けるステップと、
前記相関付けを前記宛先企業に入手可能とし、前記宛先企業が前記出荷における品目に対するタグ識別子を用いて前記出荷を確認できるようにするステップと
を含むことを特徴とする方法。
【請求項４４】
１組のルールを受信するステップであって、前記ルールが外部アプリケーションにどのデータを供給するか指定する、ステップと、
１つ以上のタグ・リーダから品目識別子を含む品目データを受信するステップであって、各品目識別子を、物理的品目に結合されているディジタル・タグから読み取り、前記品目識別子が前記品目を一意に特定する、ステップと、
他のセンサ・デバイスから追加品目データを受信するステップであって、前記他のセンサ・デバイスは、タグ・リーダ以外のデバイスであって、前記追加の品目データは、品目識別子以外の追加の物理的品目属性を含み、前記追加の品目データを、前記タグ・リーダによって識別される１つ以上の品目に関係付ける、ステップと、
前記ルール、品目識別子、及び追加の品目データを用いて、前記品目識別子及び追加の品目データ中のどの部分集合を前記外部アプリケーションに供給するか判断するステップと、
前記外部アプリケーションに、前記受信した品目識別子及び追加の品目データの中の前記部分集合のみからなるデータを供給するステップと
からなることを特徴とする方法。
【請求項４５】
請求項４４記載の方法において、前記判断及び前記データの供給がリアル・タイムで行われることを特徴とする方法。
【請求項４６】
請求項４４記載の方法において、該方法は更に、
品目識別子を追加の品目データと合算して、上位データを生成するステップと、
前記上位データを前記外部アプリケーションに供給するステップと
を含むことを特徴とする方法。
【請求項４７】
請求項４４記載の方法において、該方法は更に、
前記外部アプリケーションからデータを受信するステップであって、前記データが、アクチュエータ・デバイスを制御するためのコンフィギュレーション・データを含む、ステップと、
前記コンフィギュレーション・データを、前記アクチュエータ・デバイスに適合するフォーマットに変換するステップと、
前記変換したコンフィギュレーション・データを前記アクチュエータ・デバイスに供給するステップと
を含むことを特徴とする方法。
【請求項４８】
情報担体に有体的に具現化し、品目のコンテキスト認識及びリアル・タイム追跡のためのコンピュータ・プログラム生産物であって、
データ処理装置に、タグ・リード・データの多数のインスタンスを受信させ、各インスタンスが、品目に結合されたタグから読み取った情報を含み、該読み取った情報が、前記タグから自動的に読み取った一意のディジタル識別子を含み、各インスタンスが、前記対応するタグの位置、及び前記一意の識別子が前記タグから読み取られたときのその結合品目を含むステータス情報を含み、前記タグ・リード・データの多数のインスタンスが、一括して、多数の品目に結合されたタグから読み取った情報を含み、
データ処理装置に、コンテキスト情報の１つ以上のインスタンスを受信させ、各インスタンスが、関連するタグ付け不可能な物理的状況を記述し、前記コンテキスト情報が、前記状況の位置を含むステータスを示し、前記コンテキスト情報の多数のインスタンスが、一括して、多数の状況を記述する情報を含み、
データ処理装置に、前記受信したタグ・リード・データ及びコンテキスト情報を用いて、仮想ワールドにおける仮想品目及び仮想状況を保持させ、前記仮想品目が、前記多数の商品の各々のオブジェクトを含み、前記仮想状況が、前記多数の状況の各々のオブジェクトを含み、前記オブジェクトの各々が、その対応する品目又は状況のステータスを表し、
データ処理装置に、前記仮想品目及び仮想状況によって表される前記状況及び前記品目間において、前記仮想ワールドで発生する相互作用を検出させる、
ように動作可能なコンピュータ・プログラム生産物。
【請求項４９】
情報担体に有体的に具現化し、品目に結合されている書き込み可能タグ上のデータを更新するコンピュータ・プログラム生産物であって、
データ処理装置に、システムにおいて、第１品目についての第１属性情報を受信させ、前記第１属性情報が、前記第１品目に結合されている第１タグから自動的に読み取ったデータから得たものであり、前記第１属性情報が、前記第１品目を識別する第１識別子を含み、
前記データ処理装置に、前記システムにおいて、第２品目についても第２属性情報を受信させ、前記第２属性情報が、前記第２品目に結合されている第２タグから自動的に読み取ったデータから得たものであり、前記第２属性情報が、前記第２品目を識別する第２識別子を含み、
前記データ処理装置に、そして無において、第２品目に結合されたセンサから自動的に読み取ったデータから得られたセンサ情報を受信させ、
前記データ処理装置に、前記システムにおいて、前記第１品目と前記第２品目との間の関係を指定する関係情報を受信させ、
前記データ処理装置に、前記システムにおいて、前記第１及び第２品目をそれぞれ表す第１及び第２仮想品目を保持させ、前記オブジェクトが、それぞれ、前記第１属性情報及び前記第２属性情報を表す情報と、前記センサ情報とを表し、前記システムにおいて、前記第１及び第２品目間の前記関係を表す仮想状況を保持させ、
前記データ処理装置に、前記物理的及び仮想状況における情報から、前記第１品目に関係する警報条件を認識させ、
前記データ処理装置に、前記警報条件に応答して、前記第１品目に書き込む更新属性情報を発生させ、
前記データ処理装置に、前記システムにおいて、前記警報条件を認識した後に、タグ・ライタ・ステーションにおいて前記第１タグの存在を検出させ、
前記データ処理装置に、前記タグ・ライタ・ステーションにおける前記第１タグの存在を検出したときに、前記タグ・ライタ・ステーションにおいて、前記タグ・ライタ・ステーションに、前記第１タグに前記更新情報を書き込ませる
ように動作可能なコンピュータ・プログラム生産物。
【請求項５０】
情報担体に有体的に具現化し、供給連鎖内に多数の企業を含む商業データ処理環境において用いるコンピュータ・プログラム生産物であって、
第１企業から、タグ・リード・データの多数のインスタンスを受信させ、各インスタンスが品目に結合されているタグから読み取った情報を含み、前記読み取った情報が、前記タグから自動的に読み取った一意のタグを含み、各インスタンスは、タグ識別子が前記タグから読み取られたときの対応するタグの位置及びそれに結合されている品目も含み、前記第１企業から受信したタグ・リード・データの多数のインスタンスは、多数の品目に結合されているタグから読み取った情報を一括して含み、
前記第１企業から受信した前記タグ・リード・データを用いて前記品目についての処置情報を保持させ、
第２企業から、第２タグ・リード・データの多数のインスタンスを受信させ、各インスタンスが、品目に結合されているタグから読み取った情報を含み、該読み取った情報が、前記タグから自動的に読み取った一意のタグ識別子を含み、各インスタンスは、タグ識別子が前記タグから読み取られたときの対応するタグの位置及びそれに結合されている品目も含み、前記第２企業から受信したタグ・リード・データの多数のインスタンスは、前記多数の品目の少なくとも１つに結合されているタグから読み取った情報を一括して含み、
前記第２企業から受信した前記タグ・リード・データを用いて、前記品目についての処置情報を保持させ、前記いずれかの企業から特定の品目について受信したタグ・リード・データを用いて、前記処置情報を更新させ、
前記第１及び第２企業を含む前記供給連鎖における多数の企業に、前記処置情報を可視化させ
ることによって、前記企業に、前記供給連鎖における品目の処置のリアル・タイムの可視性を提供するように動作可能なコンピュータ・プログラム生産物。
【請求項５１】
情報担体に有体的に具現化し、センサ・デバイスと上位アプリケーションとの間のデータ転送のためのコンピュータ・プログラム生産物であって、
データ処理装置に、外部アプリケーションにどのデータを供給するか指定する１組のルールを受信させ、
前記データ処理装置に、１つ以上のタグ・リーダから品目識別子を含む品目データを受信させ、各品目識別子が、物理的品目に結合されているディジタル・タグから読み取られ、前記品目識別子が前記品目を一意に特定するものであり、
前記データ処理装置に、他のセンサ・デバイスから追加品目データを受信させ、前記他のセンサ・デバイスは、タグ・リーダ以外のデバイスであって、前記追加の品目データは、品目識別子以外の追加の物理的品目属性を含み、前記追加の品目データが、前記タグ・リーダによって識別される１つ以上の品目に関係付けられており、
前記ルール、品目識別子、及び追加の品目データを用いて、前記品目識別子及び追加の品目データ中のどの部分集合を前記外部アプリケーションに供給するか判断させ、
前記外部アプリケーションに、前記受信した品目識別子及び追加の品目データ中の前記部分集合のみからなるデータを供給させる
ように動作可能なコンピュータ・プログラム生産物。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、有形品目(tangible item)の追跡に関する。
【背景技術】
【０００２】
従来の有形品目追跡システムは、大抵の場合、計算機及びソフトウェアを含んでいる。このようなシステムは、追跡対象物体の現在地のようなステータスを示す情報を維持する。これは、仮想ワールドとして考えることができる。
【発明の開示】
【発明が解決しようとする課題】
【０００３】
従来のシステムでは、品目の実際のステータスと、システムによって示されるステータスとの間に不一致が容易に生じる可能性がある。多くの場合、不一致は、手作業によるデータ入力の誤り及びシステムの限界によって生ずる。このような問題の結果、従来のシステムでは、実際の描写が歪んだり、断片化する可能性がある。加えて、従来のシステムの殆どは、非常に限られた範囲及び分解能で監視しており、例えば、製品分類と品質の間の区別だけはできるが、個々の品目間の区別はできないシステムもある。
【課題を解決するための手段】
【０００４】
本明細書は、コンテキスト認識リアル・タイム品目追跡のための、コンピュータ・プログラム生産物を含む、方法及び装置について記載する。
本明細書で用いる場合、「品目」(item)という用語は、「物体」(object)という用語の使用から来る曖昧さを回避するために、実際の有形物体を意味することとする。「物体」という用語は、以下の文章では、データ処理構造に言及する場合にのみ用いることとする。
【０００５】
概括的には、一態様において、本発明は、品目を追跡するためのシステム及び方法、並びにこの方法の態様を実行するように構成されたコンポーネントを特徴とする。本発明によるシステムは、１つ以上の品目にタグを付けるための規格を指定する情報を含むタグ付コンポーネントであって、各タグが大域的に一意の識別子を含むタグ付けコンポーネントと、タグと通信するデバイスを含み、更にコンテキスト情報を受信するデバイスを含むオブジェクト・インターフェース・コンポーネントと、コンテキスト情報を処理するロジックと、システムのアクションを指定しコンテキスト情報に応答して実行するロジックとを含むコンテキスト認識インテリジェンスと、システムのコンポーネント間の通信及びシステム外部のデバイスとの通信のための通信ミドルウェア・コンポーネントとを含む。
【０００６】
概括的には、別の態様では、本発明は、品目のコンテキスト認識及びリアル・タイム追跡のためのシステム及び方法、並びにこの方法の態様を実行するように構成されたコンポーネントを特徴とする。この態様による方法は、タグ・リード・データの多数のインスタンスを受信するアクションであって、各インスタンスが、品目に結合されたタグから読み取った情報を含み、読み取った情報が、タグから自動的に読み取った一意のディジタル識別子を含み、各インスタンスが、対応するタグの位置、及び一意の識別子がタグから読み取られたときのその結合品目を含むステータス情報を含み、タグ・リード・データの多数のインスタンスが、一括して、多数の品目に結合されたタグから読み取った情報を含んでいる、アクションと、コンテキスト情報の１つ以上のインスタンスを受信するアクションであって、各インスタンスが、関連するタグ付け不可能な物理的状況を記述し、コンテキスト情報が、状況の位置を含むステータスを示し、コンテキスト情報の多数のインスタンスが、一括して、多数の状況を記述する情報を含んでいる、アクションと、受信したタグ・リード・データ及びコンテキスト情報を用いて、仮想ワールドにおける仮想品目及び仮想状況を保持するアクションであって、仮想品目が、多数の品目の各々のオブジェクトを含み、仮想状況が、多数の状況の各々のオブジェクトを含み、オブジェクトの各々が、その対応する品目又は状況のステータスを表している、アクションと、仮想品目及び仮想状況によって表される状況及び品目間において、仮想ワールドで発生する相互作用を検出するアクションとを実行する。
【０００７】
概括的に、別の態様において、本発明は、企業間で情報を利用可能にするシステム及び方法、並びにこの方法の態様を実行するように構成されたコンポーネントを特徴とする。この態様による方法は、第１企業からタグ・リード・データの多数のインスタンスを受信するアクションであって、各インスタンスが、少なくとも一意のディジタル識別子を含む、品目に結合されているタグから自動的に読み取った情報を含み、各インスタンスが、対応するタグの位置及びそれに結合されている品目を含むステータス情報を含み、第１企業から受信したタグ・リード・データの多数のインスタンスは、第１の多数の品目に結合されているタグから読み取った情報を一括して含み、タグ・リード・データは、第１企業の第１データ処理システムから得たデータを含む、アクションと、第１企業から受信したタグ・リード・データを用いて、仮想ワールドにおける仮想表現を維持するアクションであって、仮想表現が、多数の品目の各１つの仮想表現を含み、各仮想表現がそれに対応するステータスを表す、アクションと、第２企業からからタグ・リード・データの多数のインスタンスを受信するアクションであって、各インスタンスが、少なくとも一意のディジタル識別子を含む、品目に結合されているタグから自動的に読み取った情報を含み、各インスタンスが、対応するタグの位置及びそれに結合されている品目を含むステータス情報を含み、第２企業から受信したタグ・リード・データの多数のインスタンスは、第１の多数の品目に結合されているタグから読み取った情報を一括して含み、タグ・リード・データは、第２企業の第２データ処理システムから得たデータを含む、アクションと、第２企業から受信したタグ・リード・データを用いて、仮想ワールドにおける仮想表現を維持するアクションであって、仮想表現が、第２の多数の品目の各々の仮想表現を含み、各仮想表現がそれに対応するステータスを表し、いずれかの記号から特定の品目について受信したタグ・リード・データを用いて、当該品目に対応する仮想表現を更新する、アクションと、更新した仮想表現から及び仮想ワールドからの情報を、第１企業及び第２企業の双方に利用可能にするアクションとを実行する。
【０００８】
概括的には、別の態様では、本発明は、品目に結合されている書き込み可能タグ上の情報を更新するためのシステム及び方法、並びにこの方法の態様を実行するように構成されているコンポーネントを特徴とする。この態様による方法は、本システムにおいて、第１品目についての第１属性情報を受信するアクションであって、第１属性情報が、第１品目に結合されている第１タグから自動的に読み取ったデータから得たものであり、第１属性情報が、第１品目を識別する第１識別子を含む、アクションと、本システムにおいて、第２品目についても第２属性情報を受信するアクションであって、第２属性情報が、第２品目に結合されている第２タグから自動的に読み取ったデータから得た者であり、第２属性情報が、第２品目を識別する第２識別子を含む、アクションと、本システムにおいて、第１品目と第２品目との間の関係を指定する関係情報を受信するアクションと、本システムにおいて、第１及び第２品目をそれぞれ表す第１及び第２仮想品目を保持するアクションであって、オブジェクトが、それぞれ、第１属性情報及び第２属性情報を表す情報と、センサ情報とを表し、本システムにおいて、第１及び第２品目間の関係を表す仮想状況を保持するアクションと、物理的及び仮想状況における情報から警報条件を認識するアクションであって、警報条件が第１品目に関係する、アクションと、警報条件に応答して、第１品目に書き込む更新属性情報を発生するアクションと、本システムにおいて、警報条件を認識した後に、タグ・ライタ・ステーションにおいて第１タグの存在を検出するアクションと、タグ・ライタ・ステーションにおける第１タグの存在を検出したときに、タグ・ライタ・ステーションにおいて、タグ・ライタ・ステーションに、第１タグに更新情報を書き込ませるアクションとを実行する。
【０００９】
有利な実施態様は、以下の特徴の１つ以上を有することができる。品目及び状況に関する仮想ワールドにおける情報を、時間、三次元空間、及び一意のアイデンティティの仮想ワールド全域の標準化次元にマップすることによって、品目及び状況を、空間及び時間において、互いに対して追跡可能とする。また、本方法は、検出した相互作用が、多数の品目のいずれかに影響を及ぼすと判断したときにはいつでも、仮想ワールドのユーザに警報を発生する。また、本方法は、仮想ワールドに、品目の各々の現在地の表現と、状況の各々の現在地の表現とを維持し、表現は、各々、最後に受信したタグ・リード・データ及びコンテキスト情報を反映する。また、本方法は、位置及び状況を緯度、経度、及び高度で表す。また、本方法は、品目の位置の履歴、及び状況の位置の履歴を保持する。また、本方法は、品目の位置の履歴に基づいて、品目の少なくとも１つの今後の位置の予測を、仮想ワールドから得る。また、本方法は、状況の位置の履歴にも基づいて、今後の位置の予測を得る。また、本方法は、仮想ワールドに、品目の各々の現状態の表現と、状況の各々の現状態の表現とを保持し、表現は、各々、最後に受信したタグ・リード・データ及びコンテキスト情報を反映する。また、本方法は、品目の状態の履歴、及び状況の状態の履歴を保持する。また、本方法は、品目の状態の履歴に基づいて、品目の少なくとも１つの今後の状態の予測を、仮想ワールドから得る。また、本方法は、状況の状態の履歴にも基づいて、今後の状態の予測を得る。また、本方法は、タグ・リード・データ及びコンテキスト情報の各インスタンスとタイム・スタンプを関連付け、各タイム・スタンプを単一の規格に同期させる。タグ付け不可能な状況は、天候に関する状況を含み、天候に関する状況の位置を、少なくとも経度、緯度、及び高度によって記述する。タグ付け不可能な状況は、交通事故を含み、交通事故の位置を、少なくとも経度、緯度、及び高度によって記述する。また、本方法は、階層情報の１つ以上のインスタンスを受信し、各インスタンスが、仮想ワールドにおいて表される品目間の階層を記述し、受信した階層情報を用いて、仮想ワールドにおいて各々階層の１つを表すコンテキスト・オブジェクトを保持する。階層の少なくとも１つは、いくつかの特定の品目が別の品目内に収容されている、品目間の関係である。また、本方法は、第１品目に付帯するセンサから得たセンサ情報を受信し、第１品目に対する第１物理的オブジェクトをセンサ情報を用いて更新する。また、本方法は、外部システムからコンテキスト情報のインスタンスを受信する。また、本方法は、コンテキスト情報のインスタンスを受信し、インスタンスは、特定の位置に付帯するセンサからの遠隔測定データを含む。また、本方法は、特定の地点又は区域に付帯するセンサによって発生され、特定の地点又は区域において発生する状況を表す遠隔測定データを受信し、仮想ワールドが、遠隔測定データによって表される状況によって影響を受ける品目が、仮想ワールドにおいて表される地点又は区域にあることを検出したときに、仮想ワールドのユーザに警報を発生し、ユーザとは人又はコンピュータ・プログラムである。また、本方法は、特定の地点又は区域に付帯するセンサによって発生され、仮想ワールドにおけるコンテキスト・オブジェクト内の地点又は区域の現在の温度を表す温度データを受信し、仮想ワールドが、現在の温度によって影響を受ける品目が、仮想ワールドにおいて表される、地点又は区域においてであることを検出したときに、品目及び現在の温度を仮想ワールドにおいて表して仮想ワールドのユーザに警報を発生し、ユーザとは人又はコンピュータ・プログラムである。また、本発明は、物理的オブジェクトに温度例外を付与し、温度例外を満たすときに、処置を実行させる。この処置は、ユーザに警報を発生することからなり、ユーザとは人又はコンピュータ・プログラムである。また、本方法は、物理的オブジェクトにルールを付与し、このルールは、仮想ワールドにおける現在の情報に応じて、トリガ・イベントを引き起こすか、又は処置を実行させるように動作可能である。また、本方法は、コンテキスト・オブジェクトにルールを付与し、このルールは、仮想ワールドにおける現在の情報に応じて、トリガ・イベントを引き起こすか、又は処置を実行させるように動作可能である。本方法は、更に、品目が仮想ワールドにおいて表されている現時点又は表されていた過去の時点における品目のステータスに関するクエリを受信し、処理し、応答する。また、本方法は、現在又は過去の時点における特定の品目が仮想ワールドにおいて表されている、又は表されていた場合、品目及び特定の品目に対して特定の関係を有する品目のステータスに関するクエリを受信し、処理し、応答する。
【００１０】
概括的には、別の態様では、本発明は、供給連鎖における品目に関する情報へのアクセスを多数の企業に与えるコンピュータ・プログラム生産物を含む方法及び装置を特徴とする。品目に結合されたタグを読み取り、タグから読み取った情報及びタグに関する位置情報を、少なくとも２つの企業によって提供し、当該品目に関する処置情報を保持するために用いる。処置情報は、供給連鎖における企業には見えるようにする。タグは、各々ｅＰＣ（電子製品コード）を一意のタグ識別子として有する無線周波数識別タグとすることができる。処置情報の可視性は、許可によって制御することができる。可視情報は、発注や出荷文書のような、特定の品目と業務文書との間の関係を含むことができる。出荷文書を可視化することにより、品目タグから読み取った情報を用いて、出荷品のアイデンティティ又は完全性を確認することができる。本発明によるシステムは、第１企業から、タグ・リード・データの多数のインスタンスを受信する手段であって、各インスタンスが品目に結合されているタグから読み取った情報を含み、読み取った情報が、タグから自動的に読み取った一意のタグを含み、各インスタンスは、タグ識別子がタグから読み取られたときの対応するタグの位置及びそれに結合されている品目も含み、第１企業から受信したタグ・リード・データの多数のインスタンスは、多数の品目に結合されているタグから読み取った情報を一括して含む、手段と、第１企業から受信したタグ・リード・データを用いて品目についての処置情報を保持する手段と、第２企業から、第２タグ・リード・データの多数のインスタンスを受信する手段であって、各インスタンスが、品目に結合されているタグから読み取った情報を含み、読み取った情報が、タグから自動的に読み取った一意のタグ識別子を含み、各インスタンスは、タグ識別子がタグから読み取られたときの対応するタグの位置及びそれに結合されている品目も含み、第２企業から受信したタグ・リード・データの多数のインスタンスは、多数の品目の少なくとも１つに結合されているタグから読み取った情報を一括して含む、手段と、第２企業から受信したタグ・リード・データを用いて、品目についての処置情報を保持する手段であって、いずれかの企業から特定の品目について受信したタグ・リード・データを用いて、処置情報を更新する、手段と、第１及び第２企業を含む供給連鎖における多数の企業に、処置情報を可視化する手段とを含む。
【００１１】
前述のシステムの有利な実施態様は、以下の特徴の１つ以上を有することができる。本システムは、第３企業から、第３タグ・リード・データの多数のインスタンスを受信する手段であって、各インスタンスが品目に結合されているタグから読み取った情報を含み、読み取った情報が、タグから自動的に読み取った一意のタグ識別子を含み、各インスタンスは、タグ識別子をタグから読み取ったときの対応するタグの位置及びそれに結合されている品目も含み、第３企業から受信したタグ・リード・データの多数のインスタンスが、多数の品目の少なくとも１つに結合されているタグからの情報を一括して含む、受信手段と、第３企業からのタグ・リード・データを用いて品目についての処置情報を保持する手段であって、いずれかの企業から特定の品目について受信したタグ・リード・データを用いて処置情報を更新する、保持手段とを含むことができる。本システムは、多数の品目に結合されているタグが、無線周波数識別子（ＲＦＩＤ）タグを含み、各ＲＦＩＤタグが、電子製品コード（ｅＰＣ）を一意のタグ識別子として担持するように実現することができる。本システムは、可視性が、制御された可視性であるように実現することができ、本システムは、更に、処置情報を供給連鎖における特定の企業に対して可視化する範囲を示す許可情報を受信する手段と、許可情報によって許可された処置情報のみを、特定の企業に可視化する手段とを含むことができる。本システムは、処置情報が、複数の品目属性を含み、許可情報は、品目属性の少なくとも１つについて、品目属性を可視化できる企業を指定するように実現することができる。本システムは、多数の企業が、供給元企業と宛先企業とを含み、供給元企業は、宛先企業が行った発注に対する発注文書と、宛先企業が行った発注を満足するように用意した商品の物理的出荷に対する出荷文書とを有し、可視性が、タグ・リード・データと、発注文書及び出荷文書を含む業務文書との間の関係の可視性を含み、品目の処置のリアル・タイムの可視性を企業に与える手段が、更に、出荷における承認に対応する品目に対するタグ識別子と、各タグ識別子を出荷文書の出荷番号と関連付ける情報と、集荷番号を発注文書の発注番号に関連付ける情報とを含む出荷情報を受信する手段と、タグ・リード・データを出荷情報と相関付ける手段と、相関付けを宛先企業に入手可能とし、宛先企業が出荷における品目に対するタグ識別子を用いて出荷を確認できるようにする手段とを含むように実現することができる。
【００１２】
概括的には、別の態様において、本発明は、品目を追跡する分散型システムのノード間で通信するための、コンピュータ・プログラム生産物を含む方法及び装置を特徴とする。本システムは、第１企業におけるノード階層であって、このノード階層が、１つ以上の親ノードと、１つ以上のローカル・ノードとを含み、各ローカル・ノードが、親ノードの子である、ノード階層と、第２企業におけるノード階層であって、このノード階層が、１つ以上の親ノードと、１つ以上のローカル・ノードとを含み、各ローカル・ノードが、親ノードの子である、ノード階層とを含む。本システム内部では、各ノードが複数の品目と担当ノードとの間のマッピングを保持している。マッピングは、各品目毎に、当該品目に指定された担当ノードである少なくとも１つの親ノードを指定し、少なくとも２つの品目に、異なる指定担当ノードを特定する。各ノードは、タグ・リード・データの多数のインスタンスを受信するように動作可能であり、各インスタンスが品目に結合されているタグから読み取った情報を含み、読み取った情報が、タグから自動的に読み取った一意のタグを含み、各インスタンスは、タグ識別子がタグから読み取られたときの対応するタグの位置及びそれに結合されている品目も含み、タグ・リード・データの多数のインスタンスは、多数の品目に結合されているタグから読み取った情報を一括して含む。タグ・リード・データの各インスタンス毎に、各ノードは、タグ・リード・データを、当該ノードが保持するマッピングによって特定した、指定担当ノードに伝達するように動作可能である。
【００１３】
本システムの有利な実施態様は追加の特徴を含むことができる。本システムは、第１ノードにおいて確立したマッピングが第２ノードにおいて確立したマッピングとは異なるように実現することができる。本システムは、ノードから品目の指定担当ノードにタグ・リード・データを伝達した後、ノードが指定担当ノードから品目に関する追加情報を受信し、品目の処置情報を更新して、受信した追加情報を反映させるように実現することができる。多数の品目は、そのためにタグ・リード・データが受信され、互いに階層関係を有することができる。タグ識別子は、品目の生産者又は製品分類を指定することができる。
【００１４】
概括的には、別の態様において、本発明は、分散型システムにおいて品目処置情報を伝達するコンピュータ・プログラム生産物を含む方法及び装置を特徴とする。本システムは、監視システムと、タグ付品目を追跡するシステムを含む１人以上の加入者と、１つ以上のイベント・ルータとを含む。監視システムは、１つ以上のタグ付品目を検出し、イベントを発生し、このイベントを１つ以上のイベント・ルータに発行(publish)するように動作可能である。イベントは、タグ識別子と、リーダ識別子と、タイム・スタンプとを含む。タグ付品目を追跡するシステムは、１つ以上のイベント・ルータから１つ以上のタグ付品目に関するイベントを受信するために加入(subscribe)し、イベントを受信したときに、この受信したイベントを用いて、１つ以上のタグ付品目の処置情報を更新するように動作可能である。各イベント・ルータは、加入者のリストを保持し、監視システムからイベントを受信し、イベントを加入者に送るように動作可能である。
【００１５】
概括的には、別の態様において、本発明は、センサ又はアクチュエータ・デバイスと、上位アプリケーションとの間でデータを転送する、コンピュータ・プログラム生産物を含む方法及び装置を特徴とする。本発明によるコンピュータ・プログラム生産物は、データ処理装置に、１組のルールを受信させ、ルールが外部アプリケーションにどのデータを供給するか指定し、１つ以上のタグ・リーダから品目識別子を含む品目データを受信させ、各品目識別子を、物理的品目に結合されているディジタル・タグから読み取らせ、品目識別子が品目を一意に特定し、他のセンサ・デバイスから追加品目データを受信させ、他のセンサ・デバイスは、タグ・リーダ以外のデバイスであって、追加の品目データは、品目識別子以外の追加の物理的品目属性を含み、追加の品目データを、タグ・リーダによって識別される１つ以上の品目に関係付け、ルール、品目識別子、及び追加の品目データを用いて、品目識別子及び追加の品目データの内どの部分集合を外部アプリケーションに供給するか判断させ、外部アプリケーションに、受信した品目識別子及び追加の品目データの内部分集合のみからなるデータを供給させるように動作可能である。更に、このコンピュータ・プログラム生産物は、外部アプリケーションからデータを受信し、データが、アクチュエータ・デバイスを制御するためのコンフィギュレーション・データを含み、コンフィギュレーション・データを、アクチュエータ・デバイスに適合するフォーマットに変換し、変換したコンフィギュレーション・データをアクチュエータ・デバイスに供給するように動作可能である。
【００１６】
概括的には、別の態様において、本発明は、追跡情報を伝達するシステム及び方法を特徴とする。この方法は、複数の識別コードを受信するステップであって、各識別コードが関連する仮想品目を一意に識別する、ステップと、複数の識別コードを、１つ以上の識別コード集合にソートするステップと、識別コード集合内において各識別コードに共通な冗長コード部分を認識するステップと、１つ以上の識別コード集合を含む文書を作成するステップと、この文書を階層構造に編成し、各識別コード集合毎に、冗長部分を一旦リストに纏め、冗長部分を省略して各識別コードをリストに纏めるステップとを含む。
【００１７】
概括的には、別の態様において、本発明は、追跡情報にフィルタ処理を行うシステム及び方法を特徴とする。この方法は、複数の仮想品目に関連付けられた複数の識別コードを検索するステップであって、仮想品目が品目と品目のコンテナとを含み、各識別コードが、関連する仮想品目を一意に識別する文字列である、ステップと、各識別コードにおいて、関連するオブジェクトが品目又はコンテナのどちらかを示す文字を探し出すステップと、探し出した文字に基づいて、各識別コードが品目又はコンテナのどちらに対応するか判定するステップとを含む。
【００１８】
概括的には、別の態様において、本発明は、品目に関する追跡情報を伝達するシステム及び方法を特徴とする。この方法は、品目の集合についての追跡情報を作成するステップであって、追跡情報が品目の各々を１つ以上の属性及び任意の対応する値として表す、ステップと、追跡情報における各異なる属性の各インスタンスを、その対応する異なるコード化方式によって符号化することによって、追跡情報を符号化するステップと、符号化追跡情報を受領人に送るステップと、どの属性に受領人がアクセスすることを許可されているか判定を行うステップと、コード化方式の部分集合を受領人に供給するステップであって、部分集合が受領人にアクセスが許可されている属性のコード化方式のみを含む、ステップとを含む。
【００１９】
本発明は、１つ以上の以下の利点を実現するように実現することができる。本発明のシステムは、事実上無制限の数の品目及び実ワールドにおけるその他の品目、並びに品目と別のものとの間の関係を認識することができる。本システムは、広範囲の規模で実現することができる。本システムのアーキテクチャは、多種多様のアプリケーションと同時に容易に動作し、これらに入力することができる。アーキテクチャは、品目又は品目に影響を及ぼす状況のような、非常に多くの任意のものの追跡にも対応する。同様に、アーキテクチャは、あらゆる種類の属性を、追跡対象品目又は状況と関連付けることができる。階層的及びその他の関係を、追跡対象物間で定義し、その関係にある追跡物に用いることができる。アーキテクチャは、いずれの種類のデータ源にも開放されており、データ源には、あらゆる種類のセンサ及びスキャナ、並びに状況情報、例えば、天候、交通状態、飛行機及び貨車の予定、到達時刻データなどのような輸送予定を提供するシステムが含まれる。本システムは、実ワールド（実世界）と仮想ワールド（仮想世界）との間に包括的かつインテリジェントな和合(glue)をもたらし、コンテキスト認識、リアル・タイム品目追跡を行うために用いることができる。
【００２０】
本システムは、本来的に、コンテキスト認識インテリジェンスを統合している。このようなインテリジェンスにより、システムは、どの地空間イベントが、追跡対象のどの品目に影響を与えるか把握し、このようなイベントに応答して処置を講ずることができる。本システムは、総括的地空間能力(generic geospatial abilities)を、動的コンテキスト認識インテリジェンスに設けることができる。利用可能なデータ及び遠隔測定に基づいて、本システムは、どこで、どのように、そしてどの品目が、互いに関して、特定の時点にいるか把握し、更に、定義したルールに応じてアクションを呼び出すことができる。
【００２１】
本システムは、非専有(non-proprietary)公開インターフェースを用いて、既存のソフトウェア及びハードウェア・システムと統合することができる。このようなインターフェースにより、本システムは、既存のシステムにプラグインやアップグレードを必要とせずに、既存のシステムと互換性を有することができる。例えば、本システムは、非専有公開インターフェースを提供して、事実上あらゆる種類のタグ、タグ・リーダ、スキャナ、センサ、及びアプリケーションを統合することができる。本システムは、総括的に品目タグからデータを読み取り、データを書き込むことができるアプリケーションを含むように実現することができる。本システムは、リアル・タイム遠隔測定の総括的追跡を含むことができる。本システムは、既存の地理情報システム（「ＧＩＳ」）及びデータを統合することができる。
【００２２】
本システムは、業界を跨いで、全範囲の新たなアプリケーション又は改良したアプリケーションの開発を支援する。このようなアプリケーションは、供給連鎖(supply chain)管理、物資追跡及び管理、セキュリティ及び侵入制御、輸送、料金回収、販売時情報管理、及び手荷物の取り扱いに関するものを含む。ただし、これらに限定されるものではない。
本システムは、ローカル・レベルからグローバル・レベルまで規模が自在である。即ち、本システムは、１つ以上の業界において業務単位、単一の会社、会社のグループに対応するように実現することができる。本システムは、品目及び状況をリアル・タイムで追跡することができる。本システムは、品目又は品目群の現在及び過去の状態を提供することができ、例えば、ワイヤレス通信によって、又はインターネットのようなネットワークを通じて、遠隔地から提供することができる。
【００２３】
種々の創意によって、将来には、あらゆるタイプの多数の品目に一意にタグ付けし、多くの場合自動的に動作するセンサによって、大域的に識別可能となるであろう。本システムは、多数の業界及び会社を跨って動作し、スマートな企業レベルの品目追跡案を提供することができる。本システムは、開放、総括的、そして構成変更可能な業務方法を提供し、多数の業界や用途に適用することができる。この業務方法によって、顧客は品目の仮想表現を総括的に定義し、ネットアークを通じてソフトウェア・システムに導入し、動的なコンテキスト・データに基づいてアクションを読み出すルールを付与し、追跡対象オブジェクトの現在及び過去のコンテキストに関する、又はこれらから得られた多数の属性についてシステムに問い合わせることが可能となる。
【００２４】
本システムは、非専有インターフェース、例えば、ウェブ・ブラウザ又はＸＭＬ（拡張可能マークアップ言語）文書のような自己記述文書によって、ユーザ及び外部アプリケーションにアクセスすることができる。本システムは、多数の一意にタグが付けられた品目、及び必要であれば、遠隔測定データを、時間及び空間において追跡することができる。本システムは、品目又はその環境の位置、及び／又はそこからの遠隔測定データを追跡し、システムに供給する、センサ、デバイス、及びサービスに対して、公開の総括的かつ非専有インターフェースを設ける。また、本システムは、物理的品目又はデータを受信可能なこれらのタグにデータを書き込むセンサ、デバイス、及びサービスにも、公開かつ非専有インターフェースを設ける。本システムは、特定の属性及びメソッドを含む、一意にタグ付けされた品目及びそれらの階層の仮想表現を定義し、システムには既知の動的コンテキスト・データに基づいてアクションを読み出すことができるルールを定義し、品目に影響を及ぼし得る物理的制約又はその他の影響の仮想表現を定義し、品目及びその他の実ワールド物を表すデータ・オブジェクトの属性レベルでの、洗練されたデータ・アクセス・フィルタ設定を定義し、追跡対象品目の現在及び過去のコンテキストに関係する、又はこれらから派生した多数の特徴についてシステムに問い合わせを行い、これらを仮想化し、品目関係データをネットワークを通じて相手と共有するユーザ・インターフェース、アプリケーション・インターフェース、及びツールを提供する。
【００２５】
本システムは、多様なエンティティによって、それら自体の目的のために用いることができ、各エンティティは、本システムを用いて他のエンティティには見ることができる、そのタグ付品目、そのデータ入力デバイス、及びその追跡対象状況に関する情報の一部又は全てをなすことができる。その他のエンティティは、この情報を用いて、元来情報を収集又は提供した目的とは無関係に、種々の寄与又はその有利な相互作用の使用及び効果を、寄与がなされた時点においてもくろむことをいかなる点においても必要とせずに、システムのユーザのコミュニティ全体の経験や歴史から教わることができる。
【００２６】
本システムは、出荷の準備又はトラックの装荷中というような、出荷プロセスの間に犯した手作業の誤りの早期発見を可能にする。本システムは、供給連鎖における商品の実際の処置を最大限可視化する。本システムは、永続的に全ての履歴を保管し、信頼性、保証、顧客の返品、窃盗の予防、及びその他の業務プロセスを支援する。本システムは、既存のシステムと統合し、機能性の二重化を回避する。本発明は、可能な限り機能性の自動化を可能とし、品目を追跡するために用いるタグを有効利用して、例えば、顧客の宛先における出荷の検知に基づく請求書発行を可能にする。
【００２７】
本システムは、連続的に、１年３６５日、１日２４時間動作することができる。ソフトウェアのアップグレードは、システム全体を切り離すことなく、動的に行うことができる。データは、データの意味構造が変化しても変化しない総括的構造に格納することができる。障害発生の場合、レイテンシが少ない復旧機構によって、システムを迅速に復旧させることができる。
本システムは、規模を調整し、大量のユーザに対応することができる。データの変更を行う機構は、データに対してクエリを実行する機構から、帯域外で(out-of-band)行うことができる。クエリは、データの以前の状態に制限することができるので、現在の状態が余りに多くのクエリによって過剰負荷となることはない。
【００２８】
本システムは、ノード間で低レベルのデータ通信だけが行えればよく、それでもシステムの地理的に分散したノード間を移動する、各追跡対象品目の位置及び処置の最新状態との同期を確実に取ることができる。本システムは、ローカル・ノードからシステムの残り部分への通信が不能であっても、このローカル・ノードで継続して業務処理を行うことを可能にする。本システムは、切断したノードが一旦再接続されたなら、報告されていなかったデータを切断されたノードが収集してシステムの残り部分に確実に伝達し、他のノードが受信した変更を切断されたノードに確実に伝達することを必ず遂行する。加えて、通信量及び品目履歴格納コストは、品目の階層において最上位の品目の移動のみを報告することによって、減少する。
【００２９】
本システムは、数十億台ものスマート品目からのデータをリアル・タイムで受信することができ、その収集やフィルタ処理を行うために大量に処理能力を拡張する必要はない。スマート品目は、単一の工場又は倉庫に閉じ込めておく必要はない。本システムは、多くの地理的に分散した位置からデータを収集することができる。本システムは、いずれの可能な形式のスマート品目についても、ハードウェア特定インターフェースに対応する必要がない。本システムは、新たな通信チャネル及び新たなハードウェア・インターフェースに対処するために、容易に拡張することができる。業務ルールによって、本システムを新たな構成及び場面に適合させることができ、ソフトウェア・エンジンが動作をプログラムし直す必要はない。
【００３０】
本システムは、適応型リアル・タイム在庫管理を実現するために用いることができる。集めた在庫変化の周期的報告を受信する代わりに、本システムは、在庫の変化をリアル・タイムで報告させることができ、人の介入もない。固定の予定に応じて行われるだけの補充計画の代わりに、補充計画のタイミングを適応的とし、報告されたリアル・タイム在庫レベルに応じて、頻度を増減して行うことができる。
本システムは、ＵＩＤの冗長部分を隠してメモリ又は通信中の帯域幅を節約することができる。本システムは、異なるタイプの品目から読み取ったＵＩＤの集合を受信し、どのタイプの品目が特定のＵＩＤによって識別されるのか判断することができる。この判断から、本システムは、ある品目タイプに関連するＵＩＤをフィルタ処理によって取り出し、フィルタ処理したあるタイプの品目に関するＵＩＤの集合のみを受領人に供給することができる。
【００３１】
本システムは、追跡情報に対する選択的なアクセスを行うことができる。本システムは、同じ追跡情報を全ての消費者に送り、同時に、消費者の許可レベルに応じて情報へのアクセス・レベルを異ならせて与えることができるという利便性を提供することができる。即ち、本システムは、追跡情報を符号化するが、所与の消費者には、追跡情報の一部を復号化する手段のみを供給することができる。
符号化システムは、アクセス制御だけでなく、情報の効率的な伝達も行うことができる。本システムは、追跡情報内部の記述的テキストを、記述的テキストよりも短いコード化テキストに置き換えることができる。追跡情報をタグに格納する際、これによって、タグに格納できる情報を増加させることができる。追跡情報がネットワークを通じて伝達される場合、これによって、情報が消費する帯域幅の量が減少する。
【００３２】
本発明の１つ以上の実施形態の詳細については、添付図面及び以下の説明に明記されている。本発明のその他の特徴及び利点は、説明、図面、及び特許請求の範囲から明白となるであろう。
なお、種々の図面における同様の参照番号や表示は、同様の要素を示すこととする。
【発明を実現するための最良の形態】
【００３３】
目次
１．システムの概要
２．本システムの一実施態様
２．１  企業間出荷のシナリオ
２．２  双方向データ・フロー
３．本発明の別の実施態様
３．１  ソフトウェアのアップグレード
３．２  企業間可視性(visibility)
３．３  ワールド・モデル間におけるデータ通信及びコヒーレンス
３．４  国際取引における品目毎の識別
３．５  品目のシナリオ
３．６  情報検索のシナリオ
４．品目追跡システムとタグ・リーダとの間のデータ転送
４．１  イベント・ルータ
４．２  統合エンジン
５．追跡情報の圧縮、フィルタ処理、及び符号化
【００３４】
１．システムの概要
本発明によるシステムは、品目及び品目に影響を及ぼす状況に関する情報を、公開、非専有形態で受信する。本明細書では、「品目」という用語は非常に広い意味を有する。これは、先に引用した特許出願において用いられている「品目」という用語の意味を含む。ＥＲＰ（企業資源計画）、ＳＣＭ（供給連鎖管理）、及び戦略物流システムとの互換性のために、品目の観念は、材料表、貨物引換書、梱包リスト、選別リスト(pick list)等に品目が見られる場合に、通常暗示される全てを含むこととする。したがって、これは、生産され、出荷され、消費者に販売される等の可能性があるあらゆる物理的物体を含む。また、これは、会社の会計、又は出荷のようなその他の業務システムにおいて参照される可能性のあるあらゆる物資も含むことができる。
【００３５】
タグ付品目とは、自己識別タグを付帯する品目である。タグは、単一の品目と関連付けることもでき（前述の意味では）、あるいは１群の品目と関連付けることもできる。したがって、単にいくつかの例を揚げると、タグ付品目は、以下のいずれかとすることができる。石鹸の瓶のような個々の品目、タグ付きラップトップのような物資、恐らく様々なタイプの品目の集合を収容しているケース、又は多くのケースを収容する荷台等、コンテナ、トラック又はトレーラ、飛行機、船舶、及び貨車。
【００３６】
民生品及びその他の分野では、品目に、どのようなタイプの品目特定タグでも備えさせることができない場合もある。例えば、タグ付ケースは、４８瓶の石鹸を含む場合があり、その各々は、同じＵＰＣ（統一商品コード）又はＳＫＵ（在庫維持単位）あるいはその他の製品番号によるバー・コードを有し、更に、各々を別個に顧客に販売することができる。追跡システムは、定価の付いた品目を個々に追跡する販売時情報管理受領書によって、タグ・レベルで追跡した出荷品を相関付けることができる。バー・コードは、通常、ＵＩＤ（一意のシステム識別子）ではなく、単に品目タイプ又はＳＫＵを担持する。本システムは、バー・コード・データをタグ・データと関連付ける、何らかの想定を行うことができる。スーパーマーケット又は小売り商店においてタグによってケース・レベルで棚卸しを行えば、タグ・リーダを用いた定期的な棚卸しを活用することができる。一旦ケースが在庫から消えれば、システムは、その内容物が陳列棚上に置かれ、任意の順序で販売される可能性があると想定する。個々の品目を識別しない場合、タグ付きケースを開いた時点以降、追跡システムの精度を維持する方法はない。
【００３７】
一般に、タグはＲＦＩＤ（無線周波数識別子）タグであるが、ＲＦ技術に基づく必要はない。例えば、タグは、光学、磁気、光磁気、又はその他の技術によって読み取るように実現したり、あるいはタグとリーダとの間における物理的接触によって、又は、これによらずに実現することができる。更に、タグは受動型（通信及びデータ送信のための内部電源を内蔵していない）又は能動型とすることができ、処理能力を有することも、有さないことも可能である。本明細書では、タグはディジタル的に識別可能なタグであることを意味しているものとする。これが意味するのは、タグには、一意のディジタル・アイデンティティ（ID）を、何らか種類のリーダを用いてタグから直接読み取ることができる特性があるということである。ある種のディジタル的に識別可能なタグには、書き込むこともでき、これらは、通信ネットワークに依存することなく情報を利用可能にする必要がある場合に、特に有効である。
【００３８】
本明細書では、「仮想品目」(virtual item)という用語は、ある品目に対応し、この品目表現として用いられるデータを意味する際に用いられる。同様に、「仮想状況」(virtual circumstance)という用語は、例えば、関係やイベントを含む、有形物及び無形物に対応し、それを表す表現として用いられるデータを意味する際に用いられる。仮想品目又は仮想状況は、用語のオブジェクト指向プログラムの意味では、オブジェクトとして実現することができる。しかしながら、これは、その他の都合が良い方法であればいずれでも、例えば、データベースにおけるレコードによって実現することもできる。
【００３９】
一般に、仮想状況を形成し維持するのは、これらが、仮想品目によって表される品目に影響を及ぼす潜在性を有する何かを表すからであり、これを総称して状況と呼ぶことができる。状況の一例には、地空間イベント(geospatial event)があり、例えば、追跡対象品目を搬送する輸送船の航行を阻害し得るハリケーン、輸送船からの品目の搬出を妨害する可能性がある労働者ストライキ、及び品目の配達を遅延させ得る交通事故を含むことができる。
階層という用語は、品目と状況との間の関連又は関係を意味する。例えば、缶の荷台における１つの缶の場合、荷台に影響を及ぼすイベントは、この缶にも影響を及ぼす。仮想状況は、階層を表すことができる。
【００４０】
本システムは、種々の情報源から情報を受信する。情報源は、インターネットのようなネットワークを通じて、又は直接システムに結合することができる。本システムは、専有の即ち非公開インターフェースによって、情報源から情報を受信するように構成することができ、その場合、情報のフォーマットは、本システムと互換性を有するように変換される。本システムは、データ入力デバイス、例えば、タグ・リーダ、センサ、及びスキャナを含む。このようなデバイスを通じて、システムは連続的に商品の状態、及び物理的オブジェクト及びコンテキスト・オブジェクトによって表される状況を連続的に追跡し、記録することができる。商品の状態には、そのステータス、属性、及び位置を含むことができる。
【００４１】
２．システムの一実施態様
図１に示すように、本発明による品目追跡システム（ＩＴＳ）は、タグ・コンポーネント（「ＴＣ」）１０２、オブジェクト・インターフェース・コンポーネント（「ＯＩＣ」）１０４、通信ミドルウェア・コンポーネント（「ＣＭＣ」）１０６、コンテキスト認識インテリジェンス・コンポーネント（「ＣＡＩＣ」）１０８、及びヒューマン・インターフェース・コンポーネント（「ＨＩＣ」）１１０によって実現することができる。代替実施態様では、ＨＩＣ１１０を他のコンポーネントに統合する。これらのコンポーネントの各々は、１つ以上のコンピュータ上で実行し、データ取得、出力、及び送信機能を実行するデバイスを制御するコンピュータ・プログラムとして実現することができる。また、図１は、ＩＴＳのコンポーネント間、並びにシステム及び外部アプリケーション１１２と、外部市場１１４と、その他の外部ＩＴＳとの間における通信フローも示す。この通信フローは、ＸＭＬ文書の交換を通じてというように、便利な公開形式であれば、任意の方式で実現することができる。
【００４２】
前述のコンポーネントは、分散型、リアル・タイム、そしてイベントに基づくアーキテクチャで構成されている。各コンポーネント又は全てのコンポーネント、あるいはシステムのコンポーネントのあらゆる組み合わせは、ミクロからマクロ・レベルで実現することができる。ミクロ・レベルの実施態様とは、単一デバイス上での実施態様のことであり、マクロ・レベルの実施態様とは、ネットワーク状のコンピュータ群のように、多数のデバイス上での実施態様のことである。各コンポーネントは、コンピュータを含む多数のデバイスにわたって分散することができ、これらをネットワークによって相互接続する。各コンポーネントは、多数の異なるアプリケーションで構成、即ち、実現されており、これらが一体となって当該コンポーネントの機能を実行する。以上に記載したコンポーネント・アーキテクチャによって、システムは、ローカル・レベルからグローバル・レベルに機能性を集合化及び調整可能としつつ、非専有の(non-proprietary)標準的なインターフェースを用いて、ハードウェア及びソフトウェアが容易に統合可能であることを確保する。
【００４３】
コンポーネントは、ソフトウェア・システム、及び関連するデバイスを含むことができる。ソフトウェア・システムは、あらゆるソフトウェア、アプリケーション、コンピュータ・プログラム生産物を含む。例えば、ソフトウェア・システムは、企業レベルで動作するアプリケーション及びサーバとすることができる。ソフトウェア・システム間の通信は、通信ネットワークを通じて行うことができる。コンポーネントは、ＨＴＴＰ上のＸＭＬのような、公開規格に基づくもののような、ネットワークを通じてアクセス可能なサービスのために、汎用オープン・インターフェースに接続する(expose)。以下に、これらのコンポーネントについて更に説明する。
【００４４】
タグ・コンポーネント
システムに導入された品目は、利用可能な品目レベル・タグ付け技術のいずれか、例えば、能動及び受動型無線周波数識別子（「ＲＦＩＤ」）タグ、バー・コード、及び単体毎に付けることができるタグによって、一意の識別子が付けられる。
システムが最初に品目又は状況を認識したとき、それがシステムに導入されたと言い、対応するオブジェクト（即ち、仮想品目又は仮想状況）が作成される。システムは、特定の動的ｎ次元コンテキスト及び属性空間を、導入されたオブジェクトに割り当てる。例えば、システムは、所有者、価格、ロット番号、及び温度を、導入されたオブジェクトに割り当てることができる。任意に、システムは、特定のルールを、導入されたオブジェクトに添付する。例えば、システムは、対応する品目の温度がレベルｙに足した場合、アクションｚを生起することを指定するルールを添付することができる。
【００４５】
特定的な実施態様のＴＣ１０２は、システムにはどのタグ付け技術を用いることができるか、そしてどのようにそれを用いるかについて公開して指定する。ＴＣ１０２は、インターネット技術に基づく分散型知識システムを含む。即ち、ＴＣ１０２は、概略的に、大域的に一意の識別子の指定及びその適用方法、対応するタグの仕様を記載したカタログ、そのリーダ／ライタ・ハードウェア、及びそれらの仕様に関するあらゆる態様、品目のタグ付けに適用される特定の規格及び法規、標準化した通信並びにコンテキスト・データのフォーマット及びインターフェース、リード及びライト・プロセスの仕様、能動型タグに対する処理及び送信要件、並びに遠隔測定データの仕様、最良の産業実践、即ち、タグ及びタグ・コンテンツの選択及び展開に関する知識、セキュリティ及び許可要件及び規格、ベンチマーク、実現指針、並びに頻繁に出される質問を含み、これらを提供する。
加えて、ＴＣ１０２は、製造業者、システム統合者、及び顧客が、最適な品目−タグ−リーダ／ライタの組み合わせ、及び特定の場面に対する規格を特定し、妥当性を判断し、実現することを可能にする、ツール、コンテンツ、ソフトウェア展開キット、及びアプリケーションを提供することもできる。ＴＣは、前述の要件を満たすように、任意のソフトウェア開発環境で構築することができる。
【００４６】
オブジェクト・インターフェース・コンポーネント
ＯＩＣ１０４は、付属ハードウェアからシステム、又はその逆へにデータを変換する。また、ＯＩＣ１０４は、必要な内部処理を全て実行することもできる。
ＯＩＣ１０４は、システムと実ワールドとの間の、洗練された、汎用双方向スマート・ソフトウェア・インターフェースである。ここでは、オブジェクトがシステムに導入され、そのステータス及び遠隔測定データが受信され、必要に応じてフィルタ処理され、変換され、前処理され、処理される。オブジェクトは、現コンテキスト又はステータス・データに応じて、警報イベントをトリガしたり、アクションを生起させることができるルールを添付するように実現することができるので、ＯＩＣ１０４は、ルール・エンジンを埋め込むか、又はこれと連結し、これらの種類のルールを処理するように実現することができる。ＯＩＣ１０４をカスタム化することによって、顧客は、顧客のタグ・リーダの１つが、最初に、システムが一意のシステム識別子（「ＵＩＤ」）にマッピングすることができる品目タグを検出したときに、ＯＩＣ１０４が何をすべきか指定することができる。このようなアクションは、外部アプリケーション、例えば、ＥＲＰ（企業資源計画）アプリケーションとの通信を含むことができる。
【００４７】
また、ＯＩＣ１０４は、包括的に、タグ・インターフェース・ハードウェア、例えば、ＲＦＩＤリーダ、バー・コード・スキャナ、ポリマ・タグ・リーダ、及びスキャナ、並びにその動作用ソフトウェアが、どのようにシステムと通信するかについて指定し、その妥当性を判断する。結果的に、ＯＩＣ１０４は、標準化した統合、データの妥当性判断、フィルタ処理、及び変換、双方向イベント基準安全通信、並びにデータ前処理を行う、全てのタグ特定リード／ライト・デバイスを取り囲む汎用ソフトウェア・ラッパ(generic software wrapper)として作用する。
【００４８】
ＯＩＣ１０４は、データを受信できるだけでなく、システムに取り付けられているハードウェア及びソフトウェア、そして最終的にタグ付品目自体にもデータを送ることができるので、システムはＯＩＣを用いてデータをこのような品目に送り、これらが遠隔制御可能に構成されている場合、これらを遠隔地から制御することができる。
ＯＩＣ１０４は、全てのインバウンド及びアウトバウンド通信、例えば、ディジタル証書にもとづくものに対して、洗練されたセキュリティ方式を適用し執行することができる。ＯＩＣ１０４は、上述の要件を満たすソフトウェア開発環境であれば、任意のもので構築することができる。
【００４９】
通信ミドルウェア・コンポーネント
コンポーネントが通信する際、標準化されたイベントの送信及び受信を行うが、コンポーネントは、これらをネットワークを通じて送信及び受信することができる。ＣＭＣ１０６は、ＯＩＣ１０４とＣＡＩＣ１０８（以下で説明する）との間、そして通常、システム・コンポーネントのいずれの間における標準化イベントの妥当性をも判断し、転送する。ＣＭＣ１０６は、システム・コンポーネントのいずれかと、他のアプリケーション、デバイス及びコンポーネントとの間における標準化イベントの妥当性も判断し、転送することができる。
ＣＭＣ１０６は、データ及び認証の妥当性判断、格納及び検索、保存、データ解読／暗号化、並びにイベントのマルチキャストというような機能を実行する。ＣＭＣ１０６は、全てのインバウンド及びアウトバウンド通信、例えば、ディジタル証書にもとづくものに対して、洗練されたセキュリティ方式を適用し執行することができる。ＣＭＣ１０６は、上述の要件を満たすソフトウェア開発環境であればそのいずれでも構築することができる。
【００５０】
コンテキスト認識インテリジェンス・コンポーネント
ＣＡＩＣ１０８は、システムに情報処理機能(intelligence)を設けるロジックを含み、導入されたオブジェクトによって表されるタグ付品目が、何のために、どこで、そしてどのように、特定の時点において、互いに対して又は実ワールドのしくみ(feature)に対して、存在するか、存在したか、又は存在するであろうかということに関する問い合わせを受信し、処理し、応答する。ＣＡＩＣ１０８は、アプリケーション及びルールのような追加のしくみをプラグインし、その汎用的なサービス集合を拡張する、公開内部及び外部インターフェースを提供する。
【００５１】
以前に述べたように、システムは、潜在的に品目に影響を及ぼす可能性があるイベントを表す仮想状況を含むことができる。このようなイベントの例には、ハリケーン、高温地点又は地域、及び交通渋滞が含まれる。また、仮想状況は、品目の属性を記述することもできる。属性の例には、地空間経路、速度、及び目的地が含まれる。センサの遠隔測定読み取り値も、仮想状況として導入することができる。
ＣＡＩＣ１０８は、データベースを含み、これによってシステムは、導入されたオブジェクトの現在の状態、及びこれらのオブジェクトの状態変化の履歴を格納し検索することができる。このデータベースは、地空間データを処理することができ、多数のコンピュータ及び多数のサイトに分散することができる。
ＣＡＩＣ１０８は、全てのインバウンド及びアウトバウンド通信、例えば、ディジタル証書にもとづくものに対して、洗練されたセキュリティ方式を適用し執行することができる。ＣＡＩＣ１０８は、上述の要件を満たすソフトウェア開発環境であれば、任意のもので構築することができる。
【００５２】
ヒューマン・インターフェース・コンポーネント
ＨＩＣ１１０は、人が容易にアクセスしシステムを制御可能とするのに適した多数の技術を包括的に統合する。これらの技術は、例えば、ＨＴＭＬ又はＸＭＬに基づいた、音声制御、スタイラス制御、及び多モード・ヒューマン・インターフェースを含み、あらゆる種類のデータ視覚化技術等を含む。ＨＩＣ１１０は、アプリケーション及びインフラストラクチャ・レイヤを、表現及び人との対話（双方向処理）レイヤから分離する。
ＨＩＣ１１０は、全てのインバウンド及びアウトバウンド通信、例えば、ディジタル証書にもとづくものに対して、洗練されたセキュリティ方式を適用し執行することができる。ＨＩＣ１１０は、上述の要件を満たすソフトウェア開発環境であれば任意のもので構築することができる。
【００５３】
オブジェクトのシステムへの導入
動作において、オブジェクト（例えば、仮想品目及び仮想状況）は、標準化したパラメータ化イベントを用いて、システムに導入することができる。これらのイベントは少なくともシステムＵＩＤを含む。加えて、特定の属性、メソッド、及びルールも、導入されたオブジェクトに添付する（例えば、現在の温度、現所有者、製造業者、温度例外、警報、ルール、データ・アクセス、及び許可仕様(authority specifications)）。
【００５４】
一意の識別子
システムは、導入された全てのオブジェクトをシステムＵＩＤにマッピングする。システムがローカル・レベルからグローバル・レベルまで調整できるようにするため、そして他のシステムと問題なく統合できるようにするためには、この識別子は大域的に一意でなければならない。オブジェクトの指示物が、大域的に一意の識別子が付されたタグを有すると、その識別子をＵＩＤとして用いることができる。しかしながら、識別子を必ずしも用いなくてもよい。このような一意の識別子の１つに、ＭＩＴ（マサチューセッツ工科大学）AutoID Centerの電子製品コード（ｅＰＣ）がある。図２Ａは、ｅＰＣのフォーマットを示す。
【００５５】
本システムは、ＵＩＤを分割して、サーチ性能を高める。
品目に一意のタグを付ける方法の１つは、ＲＦＩＤチップをこれらに取り付けることである。これらの電子チップは、少なくとも１つの相対的に一意の識別子を保持しており、これは特定のリーダ・デバイスによって読み取ることができる。更に洗練性を高めたチップでは、外部リード／ライト機能を備えた動的データ格納機能も備え、スマート・チップは内蔵処理用電源を含む。ＲＦＩＤ技術の利点の１つは、多数の品目を、遠距離から自動的に、これらを分解即ちアンパック(unpack)せずに識別できることである。あるいは、本システムは、品目レベルのバー・コード、磁気テープ、及びポリマ・タグのような他の技術を用いて、システムＵＩＤにマップすることができる識別子を有する仮想品目にタグを付けることができる。
【００５６】
イベント
本システムは、イベントを用いることによって、内部及び外部と通信することができる。以下は、このようなイベントを表すＸＭＬ文書の一例を提示する。イベントを表すには、便利な形態であればそのいずれでも使用可能である。
<event>
<type>SEEN_OBJECT</type>
<parameters>
<sender>
<UID>xx.xxxxxxx.xxxxxx.xxxxxxxxx</UID>
<type>RFID_READER</type>
</sender>
<telemetry>
<UID>xx.xxxxxxx.xxxxxx.xxxxxxxxy</UID>
<temperature>
<unit>C</unit>
<value＞45.43</value>
</temperature>
</telemetry>
</parameters>
</event>
【００５７】
時間、空間、一意の識別子、コンテキスト、階層
本システムは、導入されたあらゆるオブジェクトを、時間、空間（３−Ｄ）、一意の識別子（ＵＩＤ）、及びコンテキストの、システム全体の標準化次元にマッピングする。本システムは、入力データを、システム全体の同期タイム・スタンプとともにセーブする。空間とは、点（純粋な位置）から三次元空間における複雑な三次元多面体（例えば、品目の位置、サイズ、及び形状を表す）までの、あらゆるもののことを言う。コンテキストは、ｎ次元（例えば、温度、速度、及び重さのような属性を表す）とすることができる。
各次元は、システム全体の標準的単位、例えば、協定国際時（「ＵＴＣ）」、及び国際単位系（「ＳＩ」）のような、国際規格に基づいた単位で測定する。
【００５８】
時間及び空間は不変の次元であるので、システムのコア空間は、これらの次元又はその部分集合において動作する、ＧＩＳのような他の全システムと互換性がある。導入されたオブジェクトは、動的階層の一部とすることができる。階層は、仮想状況によって記述することができる。
内部又は外部イベント・データに基づいて、システムは、前述の空間内において導入されたオブジェクトによって表される品目の状態を追跡し記録する。次いで、クエリ（質問）に答えたり、空間内における導入された物体の状態、及びそれらの間の関係について、以下のように警報を発することができる。
【００５９】
・２００１年１２月１２日に、品目（ＵＩＤ）はどこにあったか。
・住所ｚから半径ｙ以内のどこに、タイプｘの品目全て（ＵＩＤ）があるか。
・熱帯性暴風ｘによって私の物資のどれが被害を受けるか。
・物資(asset)ｘの最も近い予備部品はどこにあり、工場ｙに早ければいつまでに届けることができるか。
・ロット番号ｘの配送生産品全ては、今現在どこにあるのか。
・あとｙ日で有効期限となる私の生産物ｘに対する最も近い要求はどこからか。
・警告！  化学物資ｘ及びｙの貯蔵は互いに近すぎる。
・警告！  従業員ｘは、建物ｚからラップトップｙを持ち出すことを許可されていない。
履歴データ、統計、又はその他の方法に基づいて、システムは、導入された物体又はそれらの集団の今後の状態又は挙動を得ることもできる。
【００６０】
直接又は派生位置データ
品目の位置をシステムに記述するには、種々の方法が可能である。直接記述の一例は、標準的な方法で構成された経度、緯度、及び高度データの集合である。
派生位置データの記述の一例は、タグ・リーダが配置されている設備の住所である。本システムは、タグ・リーダの住所を本システムの標準座標系にマッピングし、タグ・リーダによって発見された品目（そのＵＩＤによって表される）がタグ・リーダの付近にあると想定し、リーダの位置を品目の位置と関連付ける。
【００６１】
オブジェクト・レベル・データ・アクセス許可モデル
オブジェクト・モデルは、ＵＩＤ、属性、及び、どのシステム・ユーザが、どの属性、メソッド、及びルールのオーソリティを読み取った／書き込んだ／変更したのかについての定義を含むことができる。本システムは、そのユーザの各々に、大域的に一意の識別子を割り当てる。この識別子は、電子生産物（電子製品）コード（ｅＰＣ）、ｅＰＣのＥＰＣマネージャ部等に基づくことができる。
割り当てられた許可に応じて、そして標準化されたパラメータ化イベントを用いて、システム・ユーザは、導入されたオブジェクトのデータの書き込み、読み取り、及び変更を行う。オブジェクト・データのアクセスは、定義された許可設定によって異なる。以下は、記述された許可モデル(authorization model)を実現する仮想品目を表すＸＭＬ文書の一例を提示する。これは、しかしながら、単なる一例であり、便利な表現であればいずれでも使用可能である。
【００６２】
<virtual_item> 
<UID>xx.xxxxxxx.xxxxxx.xxxxxxxxx</UID>
<current_owner>
<OUID>xxxxxxx</OUID>
<change_authorization>
<OUID>xxxxxxx</OUID>
</change_authorization>
</current_owner>
<price>
<unit>USD</unit>
<value>2300000</value>
<read_authorization>
<OUID>xxxxxxx</OUID>
<OUID>yyyyyyy</OUID>
<OUID>zzzzzzz</OUID>
</read_authorization>
<write_authorization>
<OUID>xxxxxxx</OUID>
</write_authorization>
<change_authorization>
<OUID>xxxxxxx</OUID>
</change_authorization>
</price>
</virtual_item>
【００６３】
通信セキュリティ方式
本システムは、総括的認証及びセキュリティ方式（ディジタル認証及び暗号化に基づくもののような）を、コンポーネントとの通信及びコンポーネント間の通信、並びに他のシステム及び外部デバイスへの通信のために含んでいる。
【００６４】
２．１  企業間出荷のシナリオ
荷送人Ｙが製造業者Ｘから小売店Ｚに輸送している、高品質魚類製品の位置及び温度を本システムが追跡し記録するという一場面についてこれより説明する。
以下では、本システムが先に説明した機能をどのように実行するかについて概略的に説明する。製造業者Ｘは、製品を箱詰めし、ＲＦＩＤタグを各箱に取り付ける。ＲＦＩＤタグは、ＵＩＤを含み、加えて、有効期限、最高温度閾値、及び最高遭遇温度読み取り値（Ｔmax）を格納することができる。製造業者Ｘは箱を荷台に装荷し、能動型再使用可能温度センサ・デバイスを各荷台に取り付ける。あるいは、出費は増えるが、このようなセンサを各箱に取り付けることも可能である。これらのデバイスには、ＵＩＤを含み、加えて温度読み取り値及び最高遭遇温度読み取り値（Ｔmax）を格納することができるＲＦＩＤタグが取り付けられている。これらのデバイスは、周期的に、現在の温度を測定し、読み取り値をそれらに取り付けられているＲＦＩＤタグに格納する。温度が特定の閾値を超過すると、警報が発生する。小売店に到着するときには、センサ・デバイスの温度履歴記録に基づいて更新された有効期限及び最高遭遇温度データが、各箱のＲＦＩＤタグに書き込まれる。
【００６５】
製造業者Ｘは、荷送人Ｙが責任を負わなければならない小売店Ｚによって拒絶される箱（拒絶）、例えば、輸送中高温に曝された箱の数を、減らしたいと考える。荷送人Ｙは、出荷中の現在地及び温度の完全な視覚性を確保することによって、顧客の満足度を高め、市場専有率を獲得したいと考える。加えて、荷送人は、品質問題、及び請負人が原因で発生する窃盗を検出したいと考える。小売店Ｚは、到着時に傷んだ製品を識別し拒絶することができ、こうして返品を減らしつつ、同時に顧客の満足度を高めることによって、コストを削減したいと考える。
【００６６】
以下に、各当事者がその目標を達成するのに、本システムがどのように役立つかについて、詳細に説明する。図３は、製造業者Ｘ、荷送人Ｙ、及び小売店Ｚが、彼らそれぞれのファイアウオール３３ｘ、３３ｙ、３３ｚの後ろに、本システムのオブジェクト・インターフェース・コンポーネント（ＯＩＣ）３４ｘ、３４ｙ、３４ｚを調達し、個々に設置を実現する一実施態様を示す。加えて、彼らは、共同で、外部アプリケーション・サービス・プロバイダのタグ・コンポーネント（ＴＣ）３２、通信ミドルウェア・コンポーネント（ＣＭＣ）３６、コンテキスト認識インテリジェンス・コンポーネント（ＣＡＩＣ）３７、及びヒューマン・インターフェース・コンポーネント（ＨＩＣ）３８を用いる。外部アプリケーション・サービス・プロバイダは、これらのサービスを、インターネットのようなネットワークを通じて提供する。あるいは、各当事者が、サービス・プロバイダによって提供される本システムの一実施態様に加入することも可能である。この後者の場合、各当事者は、ＯＩＣを調達し設置する必要はない。更に別の代替案では、当事者の一人以上が、本システムの５つのコンポーネント全てを設置し、彼ら全てで用いるようにすることもできる。この場合、当事者は、サービス・プロバイダに加入する必要はなく、彼らのＣＭＣは、インターネットのようなネットワークを通じてイベントを送ることによって、通信することができる。
【００６７】
ＴＣから得られる仕様書、規格、最良の業界実例、及びその他の情報に基づいて、製造業者Ｘは、前述の製品及び場面の要件に合ったリード−ライトＲＦＩＤタグ及びインテロゲータ（例えば、能動又は受動型ＲＦＩＤタグ、周波数、リーダ範囲、内蔵温度センサ、メモリ・サイズ、価格点(price point)、ケースの材料、及び接合(bonding)の必要性）を調達する。ＴＣから得られる仕様書、規格、最良の業界実例、及びその他の情報に基づいて、荷送人Ｙ及び小売店Ｚは、各々、製造業者ＸのＲＦＩＤタグ及びシステムに合った、多数のＲＦＩＤインテロゲータ（読み取りのみが可能）を調達する。
【００６８】
製造業者Ｘが製品の箱を調達するとき、製造業者Ｘは、１つのＲＦＩＤタグを取り付け、システムにその一意の識別子、許容温度範囲、及び初期有効期限をシステムに導入する。図４は、この導入動作を示す。箱が製造され、タグが取り付けられる（ステップ２０）。製造業者のＯＩＣ接続タグ・リーダは、タグを検知し、そのＵＩＤを読み取る（ステップ２１）。ＯＩＣは、ＵＩＤを含むSEENイベントを発生し、ＣＭＣに送る（ステップ２２）。ＣＭＣは、それをＣＡＩＣに転送する（ステップ２３）。ＵＩＤに対するオブジェクトがわかっている場合、ＣＡＩＣは入力データにしたがって、オブジェクトのステータス及びステータス履歴ログを更新する（ステップ２４の「Ｙｅｓ」分岐、ステップ２８）。それ以外の場合、ＣＡＩＣは、イベントがNEW（新たな）仮想品目イベントであるか否か判定を行う（判断ステップ２５）。イベントがNEWオブジェクト・イベントである場合、ＣＡＩＣは、指定されたデータに応じてＵＩＤに新たな仮想品目を生成し（ステップ２６）、NEW仮想品目データを格納する（ステップ２７）。それ以外の場合、以下の動作が行われる。ＣＡＩＣはＵＩＤに対するOBJECT UNKNOWN（オブジェクト未知）イベントをＣＭＣに送る（ステップ４６）。ＣＭＣは、このイベントを製造業者の生産システムに転送し（ステップ４５）、生産システムは、属性、アクセス権、ルール、及び警報を備えたINTRODUCE（導入） 仮想品目イベントをＵＩＤに発生し、警報を発し、このイベントをＣＭＣに送る（ステップ４４）。ＣＭＣはこのイベントをＯＩＣに転送し（ステップ４３）、ＯＩＣは、ＵＩＤに対するNEW仮想品目イベントを生成し、ＣＭＣに送る（ステップ４２）。また、ＯＩＣは、データをタグに書き込む要求があるか否かについても判定を行う（ステップ４１）。要求がある場合、ＯＩＣはデータをタグに書き込む（ステップ４０）。この例示では、データは、「賞味（有効）期限」日(good until date)、温度閾値、及び最高遭遇温度読み取り値である（ステップ４０）。いずれの場合でも、NEW仮想品目イベントは、ＣＭＣによって、ＣＡＩＣに転送され（ステップ２３）、先に説明したように取り扱われる。
【００６９】
図５に示すように、製造業者Ｘが配送のために荷台を装荷するときに、製造業者Ｘは能動型温度センサを荷台に取り付け、センサのメモリをリセットし、これを活性化する（ステップ５０）。センサは、予定時刻毎に温度を測定し（ステップ５２）、測定温度を、タイム・スタンプと共に、タグ上の履歴ログにセーブする（ステップ５４）。温度が最高遭遇値を超過した場合、この新たな最大値もタグに格納する（ステップ５６）。
【００７０】
図６は、センサを付けた荷台への箱の装荷（ステップ６０）に対するシステムの応答を示す。製造業者のＯＩＣ接続タグ・リーダは、タグ及びそのＵＩＤを検知し（ステップ６２）、ＵＩＤにSEENイベントを生成し、ＣＭＣに送る（ステップ６４）。ＣＭＣはこれらのイベントをＣＡＩＣに転送する（ステップ６６）。ＣＡＩＣは、イベントからの入力データに応じて検知したＵＩＤによって識別された仮想品目のステータス及びステータス履歴ログを更新する（ステップ６８）。
【００７１】
荷送人ＹのＯＩＣ接続リーダがタグを検知すると、ＣＡＩＣはシステムを更新する。図７は、この更新動作を示す。荷送人のＯＩＣ接続タグ・リーダは、センサ・タグを含む荷台上のボックスのタグを検知し、そのＵＩＤ及びＴmaxデータを読み取る（ステップ７０）。ＯＩＣは、これらのデータによってSEENイベントを生成し、ＣＭＣに送る（ステップ７１）。ＣＭＣはイベントをＣＡＩＣに転送する（ステップ７２）。ＣＡＩＣは、受信した入力データにしたがって、対応する仮想品目のステータス及び履歴ログを更新する（ステップ７３）。ＣＡＩＣは、Ｔmaxが限度以内であるか否か判定を行う（ステップ７４）。以内でない場合、ＣＡＩＣは警報イベントをＣＭＣに送り（ステップ７４から「ｎｏ」分岐、ステップ７５）、ＣＭＣはこの警報を製造業者及び荷送人のＥＲＰアプリケーションに転送する（ステップ７６）。
【００７２】
出荷品の受領時に、小売店Ｚは、取り付けられているＲＦＩＤタグからの製品の実際の最高温度データ、及び有効期限の妥当性を判断する。図９は、この読み取り動作も示す。
【００７３】
傷んだ箱が検出された場合、これらを識別し、ＣＡＩＣは、ＨＩＣコンポーネントを用いて店の経営者に警報を発する。ＳＭＳ（ショート・メッセージ・サービス）メッセージ、ページャ・メッセージ、又は他のいずれかのお便利な形態のメッセージ送信をこの目的に用いることができる。図８は、この警報動作も示し、小売店のＯＩＣ接続タグ・リーダが、ＵＩＤ、最高温度Ｔmax及び温度履歴Ｔhistoryを担持するセンサ・タグを含む荷台上の箱のタグのＵＩＤを検知し読み取る（ステップ８０）。ＯＩＣは、ＵＩＤ、Ｔmax及びＴhistory情報を用いてＣＭＣSEENイベントを発生し、ＣＭＣに送る（ステップ８１）。ＣＭＣは、イベントをＣＡＩＣに転送する（ステップ８２）。ＣＡＩＣは、入力データにしたがって、仮想品目のステータス及び履歴ログを更新する。また、ＣＡＩＣは、Ｔmax及びＴhistory情報及び製造業者のルールに基づいて、ボックス毎に、新たな有効期限を計算する（ステップ８４）。ＣＡＩＣが、箱が傷んでいると判定した場合（判断ステップ８５から「Ｙｅｓ」分岐）、ＣＡＩＣは、ＵＩＤ及びＴmaxと共に警報イベントをＣＭＣに送り（ステップ８６）、ＣＭＣはこの警報をＨＩＣに転送する（ステップ８７）。次いで、ＨＩＣは、ＳＭＳメッセージを送り、小売店の店舗経営者に警報を発する（ステップ８８）。箱が傷んでいるか否かには係わらず、ＯＩＣは、タグにデータを書き込む要求があるか否か判定を行い（ステップ８９）、ある場合、ＣＡＩＣは、タグについてのＵＩＤ及びデータを用いて、WRITE DATAイベントを発生し、ＣＭＣに送る（ステップ９０）。ＣＭＣはこれらのイベントをＯＩＣに転送し（ステップ９１）、ＯＩＣは、「賞味（有効）期限」及びＴmaxデータをタグに書き込む（ステップ９２）。
【００７４】
本システムは、第三者のプロバイダからコンテキスト情報、例えば、交通及び天候情報を受信することができる。一般に、情報をシステムに導入するには、プロバイダに当該情報を押し込ませることによって、又はシステムに当該情報を引き込ませることによって行うことができる。このような情報を有することにより、本システムは、出荷の遅延、又は導入された品目の移動又は条件に影響を及ぼす可能性があるその他の状況を報告又は予測することが可能となる。図９は、プロバイダが情報を本システムに導入することによってこれを実現することを示す。この例示では、交通情報プロバイダが、ＵＩＤ及び属性を用いてINTRODUCE仮想状況イベントを生成し、このイベントをＣＭＣに送り（ステップ１２０）、ＣＭＣはこのイベントをＯＩＣに転送する（ステップ１２２）。受信したＯＩＣは、ＵＩＤ及びＣＭＣを用いて、NEW仮想状況イベントをＣＭＣに生成し（ステップ１２４）、ＣＭＣはこのイベントをＣＡＩＣに転送する（ステップ１２６）。ＣＡＩＣは、このイベントがNEW仮想状況イベント・タイプであると判断し（判断ステップ１２８の「Ｙｅｓ」分岐）、指定されたデータにしたがって、ＵＩＤに対して新たな仮想状況を生成し、新たな仮想状況データを格納する（ステップ１３２）。
【００７５】
２．２  双方向データ・フロー
本システムは、タグ上で、データ・フロー及び双方向データ・フローを設けることができる。図１０は、一場面を示す。タグ１５２が箱１５０に取り付けられている。このタグは、ＵＩＤを内蔵し、加えて、有効期限、最高温度閾値、最高遭遇温度読み取り値、及び価格を格納することができる。タグ１５２上の温度データは、例えば、その読み取り値をタグ１５２に書き込むことができる温度測定場（ステーション）において、又はタグ１５２に動作可能に結合されている温度センサによって、箱１５０の温度を測定する毎に更新することができる。
【００７６】
タグ１５２上のデータは、例えば、ＲＦＩＤ技術を用いて、タグ・リーダ１５８によって自動的に読み取ることができる。一実施形態では、タグ・リーダ１５８は周期的に、特定範囲内においてその周囲環境を「走査」する。別の実施形態では、タグ・リーダ１５８は、例えば、近接センサによって、その周囲環境を走査するように起動させられる。例えば、タグ１５２が移動して走査対象範囲内に入ったために、走査によって、有効な読み取りデータが戻ってきた場合（通信１５４によって）、タグ・リーダ１５８は、受信データをシステム１６６に送る（通信１６２によって）。この例では、システム１６６は、外部アプリケーション１７４によって以前に（通信１７２によって）導入された仮想品目１６８を維持しており、外部アプリケーション１７４もルール１７０を定義し、仮想品目１６８に付帯していたと仮定する。ルール１７０は、「そのタグに格納されている箱の最高遭遇温度が華氏４５度よりも高い場合、当日を新たな有効期限としてそのタグに書き込む」ように定義されている。ルール１７０は、システム１６６と互換性があれば、任意のフォーマット、シンタックス、又はコンピュータ・コードで定義することもできる。システム１６６が、タグ１５２から読み取った新たなデータを受信したときはいつでも、ルール１７０を実行する。ルール１７０が肯定的な結果を返した場合、システム１６６は、当日のような、新たな有効期限を計算し、新たな有効期限及びタグ１５２のＵＩＤをタグ・ライタ１６０に送り（通信１６４によって）、タグ・ライタ１６０にタグ１５２の有効期限データ・フィールドに新たな有効期限データを書き込ませる（通信１５６によって）。
【００７７】
図１１は、別の場面を示し、ここでは、外部アプリケーション１７４が周期的に、タグ１５２に格納されている箱１５０の最高遭遇温度の最新状態を、システム１６６に問い合わせる。この場面では、この場合もルール１７１として識別することができるロジックは、外部アプリケーション１７４の一部である。外部アプリケーション１７４は、タグ１５２のＵＩＤ、新たな有効期限、更新した価格、及び更新した取締情報(regulatory information)を収容するイベントを、システム１６６に送信する。このイベントが、システム１６６に、受信した有効期限、価格、及びＵＩＤをタグ・ライタ１６０に（通信１６４によって）送らせる。次いで、システム１６６は、タグ・ライタ１６０に、受信したデータをタグ１５２の対応するデータ・フィールドに書き込ませる。前述の通信は、ネットワーク、例えば、インターネット上を含む、あらゆる通信媒体を通じて行うことができる。
これらの場面では、タグ１５２に格納されているデータを読み取ることができるタグ・リーダによって、箱１５０の受領人は、追跡の間箱１５０が曝された温度に基づいた、有効期限及び価格を特定することができる。
【００７８】
図１２は、データ・フローのプロセスの一態様を示す。図示する例では、本システムは、第１品目に対して、該第１品目に結合されている第１タグを読み取ることによって、そのＵＩＤを含む属性情報を受信する（ステップ１２０２）。本システムは、同様に、第２品目についての属性情報、及び第２品目に結合されているセンサから自動的に読み取ったデータから得たコンテキスト情報も受信する（ステップ１２０４）。本システムは、この情報を用いて、仮想第１及び第２品目を保持する。また、本システムは、これらの品目間の関係を指定する関係情報も受信し、仮想関係を保持する（ステップ１２０８）。これらの情報を有することによって、システムは、少なくとも部分的に仮想品目の一方に基づいて、第１品目に関する警報条件を認識することができる（ステップ１２１０）。警報条件に応答して、本システムは、更新した属性情報を生成し、第１品目に書き込む（ステップ１２１２）。次いで、本システムは、タグ・ライタ・ステーションにおいて第１タグの存在を検出し（ステップ１２１４）、タグ・ライタ・ステーションに、更新した情報を第１タグに書き込ませる（ステップ１２１６）。
【００７９】
これらの場面では、警報条件を認識することができ、システム自体において、警報に応答し、更新情報を計算するルールを実行するか、あるいはこれをシステム外部のアプリケーションにおいて行うこともできる。後者の場合、アプリケーションは、システムから、システムが保持しているオブジェクトからの情報を受信し、更新属性情報を生成し、それを第１タグに書き込む要求と共に、それをシステムに供給する。
図１３は、データ・フローのプロセスの別の態様を示す。図示する例では、本システムは、第１品目に結合されている第１タグから第１タグ・リーダによって自動的に読み取られたタグ・データから得た第１品目に対する属性情報を受信する（ステップ１３０２）。また、本システムは、第１品目に対する更新属性情報も受信する（ステップ１３０４）。後に、本システムは、異なるタグ・ライタ・ステーションにおいて第１タグの存在を検出し（ステップ１３０６）、タグ・ライタ・ステーションで更新情報を第１タグに書き込ませる（ステップ１３０８）。この場面では、更新情報は、システム自体の内部で計算することができ、あるいはこれをシステム外部のアプリケーションにおいて行うこともできる。後者の場合、アプリケーションは、システムが保持しているオブジェクトからの情報をシステムから受信し、更新属性情報を生成し、これをタグに書き込む要求と共に、これをシステムに供給する。
【００８０】
３．  システムの別の実施態様
図１４に示すように、本発明によるシステムは、共有ＩＴＳ（品目追跡システム）、及び多数のローカルＩＴＳ、たいていの場合個人のＩＴＳを用いて実現することができる。本システムは、明示的な上位レベル共有ノードを有する必要はない。本システムの実施態様の中には、会社(corporation)の連合であり、会社の上には階層がない場合もある。別の実施態様では、会社レベルの上に、多数の上位共有ノードを有し、各々が恐らくは、特定の工業分野に対応する場合もある。一般に、支援する業界内部における同意を含む種々の検討事項によって、構造は変動される。
【００８１】
図１４において、既存のＥＲＰ（記号資源計画）システム１４０１は、製品の移動及び保管を管理するために用いられる、いずれかのローカル企業ソフトウェアとすることができる。企業（又は企業の一部）毎のＥＲＰシステムは、異なってもよい。
各企業は、多数のタグ・リーダ１４０２を有し、ディジタル的に識別可能なタグからのディジタル情報をローカルＩＴＳに供給する。一般に、タグ・リーダは、いずれかの品目又はコンテナから収集したディジタル・データを供給可能なハードウェア及びソフトウェアのいずれかの組み合わせである。リーダは、製造ライン上、保管場所内、出荷及び入荷区域内、装荷ドック、トラック又はその他の移動車両内部に設置することができ、手持ち型のワイヤレス接続デバイスとすることもできる。実施態様によっては、任意に、実際の物理的リーダとＩＴＳとの間に介入するハードウェア及びソフトウェアを有する場合もある。
【００８２】
図１４において、各ローカルＩＴＳ１４０３は、１つ以上のコンピュータ・システム上で実現可能なハードウェア及びソフトウェアのシステムである。このシステムは、通例、企業の他の部分と地理的に接近している(local)が、ローカルＥＲＰシステム及びタグ・リーダにしかるべく接続できるのであれば、物理的にどこに位置してもよい。通常、ＩＴＳは、単一の企業又は当該企業の一部にサービスを提供する。したがって、ローカルＩＴＳが１つよりも多い場合、各々を異なる企業によって運営することができる。また、ＩＴＳは、供給連鎖管理、業務計画、顧客関係管理、及びＩＴＳから得られるタイプのデータによって可能となった新たなソフトウェア・サービスに用いられるような、他の既存の企業ソフトウェア・システムにも接続することができる。
【００８３】
共有ＩＴＳ１４０４は、多数のローカルＩＴＳによって共有される品目追跡システムである。これは、一般に、多数のローカルＩＴＳシステムに接続し、更に、多数の別の供給ＩＴＳシステムにも接続することができる。また、共有ＩＴＳは、他の新たな及び既存の企業ソフトウェア・システムにも接続することができる。
ローカル及び共有ＩＴＳは、コンピュータ間通信技術のいずれでも可能なネットワーク接続部１４０５を通じて通信する。一般に、企業間では、通信はセキュリティのために暗号化され、ディジタル・セキュリティ証書又はその他のセキュリティ手段を用いて、通信に関与する者を認証する。通信媒体は、公共のインターネットを含んでもよい。この接続は、通常、タグ付品目の処置(disposition)を表すリアル・タイム、又はリアル・タイムに近いメッセージ、及び出荷文書、輸送車両などを表すその他の情報を受け渡す。
【００８４】
個々のサイト１４０６は、個々のサイトにおいて内部処理に対応するために必要なハードウェア及びソフトウェアの集合体である。サイトは、製造業者、流通業者、小売店、個人の家、修理工場、あるいはタグ付き商品を扱うその他のあらゆる場所、又は場所の一部とすることができる。
新たな及び既存のアプリケーション１４０７は、供給連鎖管理、業務計画、顧客関係管理、及びＩＴＳから得られるタイプのデータによって可能となった新たなソフトウェア・サービスに用いられるような、既存の企業ソフトウェア・システムである。ネットワーク接続部１４０８を通じて、これらのアプリケーションは、ＩＴＳに、ＩＴＳ及びその他の情報によって追跡されている品目の現在の状態及び過去の履歴に関して質問することができる。これらのクエリは、ＩＴＳシステムに記録されている状態を変化させることはなく、したがって、多少の有用性の損失はあるが、ＩＴＳ内の生データに対してクエリを処理するのではなく、永続的ストレージ（記憶媒体）に保持されているＩＴＳの状態のログを処理することによって、扱うことができる。
【００８５】
図１５は、品目追跡インフラストラクチャ内部における基本的ソフトウェア・コンポーネントを示す。リアル・タイム入力処理ソフトウェア１５０１は、タグ・リーダ、既存のＥＲＰシステム、及びその他のＩＴＳシステムからの処置(disposition)及びその他のメッセージを受け入れる。これらのメッセージは、ＸＭＬ又はその他のフォーマットとすることができる。メッセージは、物理的又は論理的な品目の作成、あるいはこれらの品目の処置又はステータスの変化を表すことができる。ソフトウェアのこの部分は、着信するメッセージを解釈し、データ記憶エレメント１５０２を参照し、メッセージの内容及び格納データに基づいて適切な処置を講じ、指定通りにデータ構造を更新し、恐らくはエラー・メッセージ又はその他の報告をメッセージ発信源に返送する。
【００８６】
データ構造及び永続的ストレージ１５０２は、ＩＴＳが追跡する論理的及び物理的品目の関係、状態及び履歴の表現を記録し保持する。例えば、このソフトウェアは、ある一意のタグが特定の洗剤の瓶に対応することを記録することができる。洗剤は、物理的に、トラック（ＩＴＳ内部における別の一意のタグ及び品目）上にあることもある箱（ＩＴＳ内で知られている別の一意のタグ及び品目）内に収容することができ、トラック自体の位置は、リアル・タイム入力処理ソフトウェア１５０１からのリアル・タイム・メッセージ及びソフトウェアの作用に応答して、周期的に更新することができる。また、データ構造は、洗剤がある出荷品（ＵＩＤを有する論理品目）の一部であることを記録することもできる。データ構造及び永続的ストレージは、ハードウェア又はソフトウェアに障害があっても、データ構造を保存する。永続的ストレージを構築するロバストな方法であれば、いずれでも用いることができる。例えば、ソフトウェア・データベース技術や磁気ディスク・ドライブを用いて、不揮発的に情報を記録することができる。
【００８７】
クエリ用のソフトウェア・インターフェース１５０３は、ＩＴＳと外部企業ソフトウェア・アプリケーションとの間にインターフェースを設ける。例えば、従来のＥＲＰ（企業資源計画）又はＳＣＭ（供給連鎖管理）システムがある品目の現行の実位置に関して更新を必要とする場合、クエリを送る。ＩＴＳ永続的ストレージは、処理に必要な情報を提供することができ、クエリ用インターフェースは、この情報を用いて、「所与の地理的領域内に現在ある特定品種のバッテリ（製品コードによって識別する）を全て報告する」というようなクエリを処理することができる。あるいは、「陳列棚に置かれている時間が４８時間以内のミルク・カートンを全て報告する」というようなクエリを処理することができる。
【００８８】
３．１  ソフトウェアのアップグレード
ＩＴＳインフラストラクチャ（図１６に示す）のコア３１０は、連続的に、１年３６５日、１日２４時間動作しなければならない。かなりの経済活動がシステムのある部分に依存するときに、保守又はシステムのアップグレードのためにシステムをダウンさせるのは現実的ではない。しかしながら、システムは、様々な方法でアップグレードする必要がある。以下に説明するアーキテクチャは、この必要性に対処する。
３種類のソフトウェア・アップグレードについて検討する。即ち、フィールド（即ち、プロパティ（特性））の追加又は削除、フィールド内容のセマンティック（semantic：意味的）通知を行うコード（即ち、コンピュータ・プログラム命令）の追加又は変更、及び主要なシステム・アップグレードである。
【００８９】
製造業者、流通業者、小売店、及びその他の者は、個々の動作の利便性のために、個々の項目（アイテム）又は項目群の表現に対して、データ・フィールドを追加又は削除しなければならない場合がある。例えば、品目を処理したときの温度を示すフィールドを追加することが望ましい場合もある。この情報は、例えば、長期信頼性及び製品の返品の研究には重要であるかもしれない。この処理温度フィールドは、現在の温度や、デバイスの輸送又は格納中に検知した最高温度のような既存の温度フィールドとは異なる情報を収容する。同様に、これは異なる扱いをする場合もある。例えば、製造業者は、信頼性の研究のために、処理温度値を長期間格納することを望むが、他の製造業者や、恐らくは他のいかなる機関にも明らかにはしたくないであろう。
【００９０】
データ・フィールドの追加又は削除のその他の例には、次のような場合が含まれる。購入されて後に返品された品目を小売店が記録したい。規制が変更し、ある法律が、この種の製品に販売期限を付けることが必要となった。そのフィールドには、製造業者によって記入され、流通業者及び小売店がそれに応じて行動を起こす。
別の例では、流通業者が、消費者によって製造業者に返品される品目に、返送運賃を提供する責任がある。流通業者は、「返送運賃負担者」というフィールドを追加し、流通業者の氏名を自動的に記入し、品目が返品されるときに、法的に責任のある当事者が請求されるようにすることを望む。このような流通業者情報は、履歴から得られる場合があり、得られない場合もある。しかしながら、追加のフィールドは、履歴に問い合わせを行うことなく、この料金を負担するのが誰かを明らかにする。
【００９１】
一般に、本システムは、あらゆる既存のオブジェクトに動的に新たなデータ・フィールド（即ち、プロパティ）を追加することができる。更に、オブジェクト・レコードは、プログラムを変更せずに、しかも同じ形式の以前又は今後のオブジェクトを変更する必要もなく、上位又は下位いずれの階層システムにも受け入れられる。
削除は、オブジェクトがある状態にあるときにしか意味がないデータ・フィールドには望ましい場合がある。例えば、出荷リスト又は梱包リストに関連するフィールドは、オブジェクトが、現出荷品の一部である品目を表すときにだけ有効となる。一旦出荷品が正式に受領されたなら、出荷情報フィールドを、アクティブ・データ構造から削除する（しかし履歴には保持する）。あるいは、無効フィールドが削除されない場合、これらには無効という印を付ける。
【００９２】
意味的挙動を実現するコードの追加又は変更によって、システムをアップグレードすることができる。一般に、継続的にシステムに新しい能力を追加し、古い機能性を見直すのは望ましいことである。このような変更には、どこに新しい能力を追加するか、誰がプログラミングを行うか、どのように検査するか、そして他のアクティビティに対する影響を最少に止めるにはどうすればよいか、というような多くの判断を要する。
意味的挙動（センマンティック・ビヘイビア）の追加又は変更を必要とする状況の例には、次のような場合が含まれる。新たな部員がコンソーシアムに加入し、その種の商品を扱う新たな機能性が必要となった。既存の機能性が変化した。例えば、販売期限日の設定を処理する方法が変わったり、あるいはトラックに装荷するためのより良い手順が開発された。
【００９３】
インフラストラクチャのどのエレメントに機能性を追加しても、新たなデータ・フィールドの追加が必要となる。
意味的挙動の変更には、システム全体をクラッシュする潜在的可能性がある。したがって、慎重に制御しながら、意味的挙動を変化させる新たなコードを検査し導入することが不可欠である。一般に、動作中のシステムを停止することなく、特定の品目タイプ及び特定の品目の意味的処理を変更することができる。更に、他のオブジェクトに対する挙動は変化しないことを高いレベルで保証する。
主要なシステムのアップグレードが可能であり、ソフトウェア全てを変更するアップグレード、ディスク・フォーマットのアップグレード、及びハードウェアのアップグレードを含む。一般に、本システムは、サービスの可視性を全く失うことなく、一方のハードウェア／ソフトウェア構成から他方の構成に、透過的に中央システムの動作を切り換えることができる。この手順は希であろう。
システムの信頼性の理由から、シャドー・システムを走らせることができる。このようなシステムも、主要なシステム・アップグレードの機構を備える。
【００９４】
図１６に示すように、アクティブなデータの格納は、全てのセマンティック（意味的）・メソッドから分離されている。コア６１０は、基本的機能性の小集合を備えるが、それ以外ではいずれのオブジェクト特定処理からも独立している。結果的に、コア１６１０は、新たなデータ・フィールド又は新たなセマンティック処理を追加するときに変更する必要がない。このようなコアは非常に一般的であり、その基本的な機能性、及び非常に高い信頼性に対して最適化することができる。コア１６１０のプログラミングが変化するのは希である。
本システムの別の部分は、プロセス間通信又は文書交換によって通信を行うので、コア１６１０は、他のコンポーネントが故障し、再起動させなければならない場合でも、動作し続けることができる。
【００９５】
コア１６１０は、以前のスナップショットから再起動することができる。次いで、以前のイベントを再生することによって（幕等元(idempotency)を想定する）、又は現在の状態を再現するために永続的ストレージから得られるものを用いることによって、最新状態にすることができる。以下で論ずるが、永続的ストレージ１６２０に引き渡されていない変更は、再実行しなければならない。
効率的にシステムの様々な要望全てに対応する機能の小集合について、以下に説明する。
【００９６】
図１６に示すように、無状態リアル・タイム・セマンティクス部１６３０は、次の動作を実行する。（１）ネットワークから処置メッセージを受け付ける。処置メッセージは常に少なくとも１つの品目を指定する。（２）指定された品目に対応するオブジェクト（複数のオブジェクト）を検索する。一般に、ロッキング(locking)を回避することができる。（３）オブジェクトからの情報を用いて、適切な意味的処理方法を選択する。（４）それ以外に必要なあらゆるオブジェクトを検索し、必要であれば、これらをロックする。（５）更新したオブジェクト・レコードを計算する。（６）変更をコア１６１０に受け渡し、全てのオブジェクト・レコードのロックを解除する。
リアル・タイム・セマンティクス部１６３０は、完全に無状態である。したがって、いつでもその任意の部分で停止させ、再起動し、動作を継続させることができる。これは、例えば、Ｊａｖａ（登録商標）機構を用いて新たなセマンティクス・メソッドを動的にロードし、いずれの障害から復元することも、容易にする。
【００９７】
着信する処置メッセージに適用するメソッドを選択するには、いくつかの方法がある。適切なコードは、オブジェクトのタイプ又はクラス、及び指示された処置双方によって決まる。例えば、輸送車両の装荷は、恐らく、殆どのオブジェクトにとって非常に類似していようが、「エンド・ユーザへの販売」処置は、品目のタイプに大きく依存する可能性がある。少なくとも２つの代替実施態様が可能である。（１）ＭＩＴ  Auto-ID centerが提案したｅＰＣにおいて用いられている明示的製品タイプ・フィールドを拠り所とする。（２）指定されたオブジェクト、及び恐らくはそのルート・タイプ・オブジェクトも調べ、品目タイプ識別子を得る。
【００９８】
第２の手法は、ｅＰＣ付番方式の展開に依存せず、いずれのタグ・システムとも動作する。更に、その無目的レベル(level of indirection)によって、広いクラスのオブジェクトを同じソフトウェアで処理することが可能となる。例えば、１つの製造業者の全ての洗剤製品は、同じコードで処理すればよく、別の製造業者のものは異なるコードを有することができる。最後に、個々の品目にフラグを付け、異なるコードをトリガするように、コア１６１０を設定することができる。このようにすることによって、小集合のオブジェクトに制限された新たなコードのライブ検査が可能となる。高性能を達成するためには、このコードをマルチ・スレッド化する。これによって、セマンティック・コードを発行する前に、オブジェクト（そして恐らく、当該オブジェクトによって参照されたあらゆるルート・オブジェクト）を取り込むことができる。
【００９９】
コア１６１０は、永続性を備えないように実現することができるという利点がある。柔軟性及び速度を得るためには、コア１６１０はコンピュータ・メモリ・サブシステムとすることができる。あるいは、コア１６１０を直接永続的ストレージ機構１６２０にマッピングすることもできる。
永続的ストレージ機構１６２０は、コア１６１０からのオブジェクト変更通知のストリームを取り込み、これらを永続的ストレージにコミットするモジュールである。記憶した情報から、システム状態の現スナップショットを素早く作成することができる。
【０１００】
履歴機構１６４０は、次のように設けられる。本システムには、２つのアクティビティ源がある。即ち、通例、個々の品目からのビープ又は信号を表す処置（デポジション）メッセージ、そして外部システムによる蓄積オブジェクト移動データに対するクエリである。オブジェクト移動ビープはコア１６１０を更新する。何故なら、これらは、品目の全母集団(universe)の状態に対する変化を表すが、以前の履歴へのアクセスを必要としないからである。外部クエリは、移動履歴及び現処置に関与するが、状態を変更する必要はない。
本システムは、履歴を蓄積することができ、更に、現状態の最新のビューも有するので、大きな非リアル・タイム・サーチ集約クエリ(non-real time search intensive query)に対して最適化することができる。これは本質的に読み出し専用であるので、容量の大きなクエリに対応するためには、容易に二重化することができる。
【０１０１】
履歴機構も永続的ストレージを必要とする。したがって、履歴機構は、永続的ストレージ機構１６２０内に組み込まれるのが通例である。
コア１６１０は、最少の機能性集合を有する。これは、オブジェクトを作成し拡張することができ、
（ａ）オブジェクトを作成し、
（ｂ）プロパティ名称−値対を追加又は削除する
機能を含む。
全てのオブジェクト名は一意であり、サイズは任意である。名称は、拡張可能な名称リストから取られ、激増を防止し、一定しない意味を有する矛盾する名称の作成を回避する。
【０１０２】
コア１６１０は、プロパティ値にアクセスし変更することができる。即ち、
（ａ）全てのプロパティ（名称−値対）を戻し、
（ｂ）プロパティ名称−値対を更新する、
ことができる。
コア１６１０は、名称付き集合所有権(named collection ownership)及びメンバシップのような、特殊化した（内蔵）プロパティ・リスト１７１０の機能性を有し、
（ａ）新たな正式−名称集合のオブジェクト・オーナー（ルート）を作成する能力、及び
（ｂ）名称付き集合のメンバを追加及び削除する能力
を含む。
最後に、コア１６１０は、非常に希にしか用いられないが、オブジェクト・ロッキング機能を有し、
（ａ）オブジェクト−提供署名をロックする能力、及び
（ｂ）オブジェクト−提供一致署名のロックを解除する能力
を含む。
【０１０３】
このコア１６１０の機能性の非常に小さい集合は、タグやリーダ、あるいは実ワールドにおける品目のサーチには殆ど用をなさない。これは、主要な長所である。データ構造は十分に一般的であるので、供給連鎖やその他のアプリケーションを通過する品目の意味によって変更する必要はない。コア１６１０のソフトウェアは、動作の小集合を実行することに非常に最適化されており、一方、セマンティック（意味）の変更は、無状態セマンティック・メソッドにおいて対処する。勿論、データ構造が大きくなるに連れて、多くの規則がこれに組み込まれ、セマンティック変更の中には、現行のオブジェクト構造を構築し直さなければならないものもある。しかしながら、これは、システム上でライブで行うことができ、コア１６１０のソフトウェア変更を伴わない。
【０１０４】
以下は、これらの構造をどのように用いることができるかについての、簡略化した例を示す。
#1147：{objectedID:#1147}{obj_Type:Base_EPC_Type}{Software_Version:2}
{Class:? Detergent”｝{PML：? http:.....”｝
{EPC_Type_Collection_Root:#341,#576.........}
#341:{ObjectID:#341}{ObjType:EPC_Object_Instance}
{EPC_Type_Collection_Member:#1147}{Container_Collection_Member:#3328}
#576:{ObjectID:#576}{ObjType:EPC_Object_Instance}
{EPC_Type_Collection_Member:#1147}{Container_Collection_Member:#3328}
#621:{ObjectID:#621}{ObjType:EPC_Object_Instance}
{EPC_Type_Collection_Member:#1147}{Container_Collection_Member:#3348}
#2287:{ObjectID:#2287}{ObjectType:ERP_Shipment}
{Shipment_Collection_Root:#3328.........}
{Shipment_Enterprise_Member:#3347}
{Shipment_System_Source:“R/3_4.6”}
#3328:{ObjectID:#3328}{ObjType:Container}
{Container_Description:“14 x 18 x 10 Cardboard Box”}
{Immediate_Location_Type:Follow_higher_level_container}
{Container_Collection_Root:#341,#576}
{Shipment_Collection_Member:#2287}
{Container_ollection_Member:#4421}
#4421:{ObjectID:#4421}{ObjType:Container}
{Container_Description:? 10,0001b Truck”}
{Immediate_Location_Type:GPS Long-Lat-Alt}
{Container_Collection_Root:#3328}
{Latitude:32N}{Longitude:60.45}{Altitude:327M}{Location_Last_Update:
1/12/2002 14:27}
#3348:{ObjectID:#3348}{ObjType:Container}
{Container_Description:? Warehouse Shelf”}
{Immediate_Location_Type:Fixed Storage Location}
{Storage_Location_LOcal:? Shelf3”
{Container_Collection_Root:#621...}
{Container_Collection_Member:#4462}
#4462:{ObjectID:#4462}{ObjType:Container}
{Container_Description:? Warehouse Region”}
{Immediate_Location_Type:Fixed Storage Location}
{Storage_Location_Local:? Regio 16”
{Container_Collection_Root:#3348...}
{Container_Collection_Member:#4481...}
#4481:{ObjectID:#4481}{ObjType:Container}
{Container_Description:? Warehouse”}
{Immediate_Location_Type:Top Level Fixed Location with Lat/Long/Alt}
{Container_Collection_Root:#4462...}
{Latitude:31N}{Longitude:60.45}{Altitude:100M}
【０１０５】
上の表は、かなり複雑な状況を記述しており、図１８及び図１９にも示されている。
この表に示すように、＃１１４７は、製品クラス「洗剤」を意味する。具体的な洗剤の瓶は、オブジェクト・インスタンス＃３４１、＃５７６、及び＃６２１によって表される。
図１８に示すように、これら洗剤瓶１８１０の内２つは、ボール箱１８２０内にある。箱はトラック１８３０上にあり、このトラックは、リアル・タイムで位置を報告するために、ＧＰＳ測地システムを有する。箱は、特定の出荷品の一部である。第３の洗剤瓶１９４０があり、これは、倉庫１９５０の領域１９７０内にある棚１９６０に保管されている。
【０１０６】
集合機構は、データ構造に大きな力を与える。例えば、
洗剤ＥＰＣの基本タイプ（＃１１４７）のオブジェクトＩＤが与えられると、集合に質問し、洗剤の全てのインスタンス、及びその現在地が得られる。
倉庫のオブジェクトＩＤが与えられると、倉庫内にある全ての品目、及びそれらの保管場所を得ることができる。
洗剤のいずれかのインスタンスのオブジェクトＩＤが与えられると、存在するのであれば、対応する出荷番号を得ることができる。
出荷品のオブジェクトＩＤが与えられると、全ての品目及びその位置を得ることができる。
トラックのオブジェクトＩＤが与えられると、そのトラック内にある全ての品目、及びそれらに関連する出荷文書を得ることができる。
【０１０７】
データの復元
データの復元は、重要な問題である。図２０は、ネットワーク２０１０のリーフにおいてビープが検出されたときから、そのビープの含意(implication)が永続的ストレージ２０２０に記録されるまでの、システムにおけるレイテンシを示す。共有（中央）サイト２０３０における突発故障を想定すると、復元は、現在ディスク上にある情報から始まり、未だ処理されていない全ての変更を考慮に入れることを含意する。
１つの復元手法は、ネットワーク・インフラストラクチャ自体２０６０内におけるある量の履歴を記録することである。例えば、確実な内部永続的データ・ストレージを有するために、発行−加入分散機構を構築することができる。別の手法では、ネットワークの各リーフ・ノードに永続的ストレージを有することがあげられる。
【０１０８】
必要な全ストレージ２０４０は、タグ・リーダからシステムの永続的ストレージまでの、システム全域における総レイテンシに等しい。
一般に、どのイベントに作用し、何が失われたかを確かにするのは容易ではない。更に、リアル・タイム・セマンティック部１６３０及びコア１６１０を通じたイベントの処理には、固有の順序がない。十分なイベントを再生して可能な限り最大の損失を補うようにすれば、全ての処理が幕等元であり順序に無関係であるならば、有効に作用する。この条件を満たすとき、呼び出される動作２０６０は、イベントが異なる順序で処理される場合、又は同じイベントが１回よりも多く処理される場合、究極的なシステム状態は同一となるような意味となる。
【０１０９】
位置の更新
価値が高い品目の一部、及びトラックのような輸送車両は、位置の周期的更新を行う、リアル・タイム位置探索システム（ＲＴＬＳ）によってタグ付けすることができる。例えば、カリフォルニア州サンタクララのWhereNet Corporationが提供するWhereTagタグは、２．４ＧＨｚ帯域でその識別子を局地区域にブロードキャストし、三角測量法によって位置を判断する。これらのタグは、秒単位から分単位までの、一定の間隔でブロードキャストし、タグに物理的にアクセスすることによってのみ変更することができる。
加えて、広域システムは、携帯電話又は低帯域幅衛星アップリンク・システムのような、従来の通信システムと連携して、ＧＰＳ（全地球測地衛星）受信機を用いて、周期的な位置の更新を行うことができる。基地局から通信システムにポールして現在地を確かめてもよく、また遠隔地からプログラムできる間隔で発呼してもよい。
【０１１０】
追跡システムの基本的な機能は、位置情報の報告を受信することである。単一の位置報告方法を有することは便利であるが、建物や倉庫のような狭い区域内部で緯度及び経度を用いると、不要な多くの余分な計算ステップを伴う危険性があり、したがって、一般には、基準ローカル・フレームが用いられる。広域での使用に適しているのは、ＧＰＳシステムから得られる緯度、経度、及び高度データである。
【０１１１】
バッチ識別
一般に、品目追跡システムは、あるリーダにおいて品目を察知したときの単なるビープよりも多くの情報が提供される。このような情報は、読み取った品目がバッチ状で近づきつつあるときの計画的処置であることが考えられる。例えば、「以下の品目が在庫から取り出され、出荷ｘのために箱詰めされている」。いずれの場所でも、本システムには、この出荷に関する情報が提供される。
このような情報は、直接システム・アプリケーション（例えば、ウェブ・ブラウザを用いたアプリケーション）に接続しタグ・リーダに近い端末から、又は適切なメッセージを追跡システムに送信することができるローカル・システムから間接的に得ることができる。
【０１１２】
品目は多くの場合まとまって到着するので、バッチの終了が記録されるまで、ビープを内部にキャッシュすることができる。次いで、リーダ又はローカル・システムは、追跡システムに、バッチにおける全ての品目に関する情報を含むメッセージを送る。
各バッチには、一意のＩＤを与えることができる。バッチ番号（バッチＩＤ）は、一群の品目に関する共通情報を簡潔に伝達する１つの方法である。各リーダは、デフォルトのバッチＩＤを有することができ、バッチＩＤが指定されていない場合、これを用いる。バッチＩＤを用いる場合、リーダからのメッセージは、次の形式とすることができる。
【０１１３】
タイムスタンプ、バッチID (例えば、９６ビットのｅＰＣ）、品目ID
このようなバッチの使用は、品目が読み取られる前に纏められてない場合に用いる、ソート機能を支援することができる。例えば、組立ラインは、一連の品目と、一続きのビンを有する場合がある。リーダは、各品目上のタグを読み取り、例えば、ビン１、２又は３に品目を入れるか否か判断する。各ビンは、例えば、異なる処置を指示する場合もある。リーダは、異なるバッチＩＤを各ビンと関連付け、各品目を、それが入れられるビンのバッチＩＤと関連付ける。
【０１１４】
バッチ指定のプリミティブは、一意のＩＤを有するリーダ、及び同様に一意のＩＤを有する出荷品を含むことができる。リーダを出荷品と関連付けて、一意のＩＤを有する特定のバッチを生成する。多数のバッチは、同一又は異なるリーダからでも、同じ出荷と関連付けることもできる。出荷に必要なプリミティブは、一意のＩＤ、ローカル出荷番号（例えば、ローカルＥＲＰ内で用いられる番号）、商品の宛先、目標配達日、及び目標配達時刻を含むことができる。
各品目を、リーダではなくバッチと関連付けることによって、情報を安全に、そして混乱することなく、繰り返すことができる。例えば、処置メッセージが、例えば、システム障害及び再起動のために、再度送信される場合、バッチ−品目対がリーダ−品目対の変わりに用いられていれば、システムの状態は変化しない。
【０１１５】
処置（デポジション）アクション
処置アクションは、タグ付品目に関係する、又は関連付けられたオブジェクト及び品目の階層についての状態変化を記述する。処置アクションは、例えば、品目の作成、即ち、品目の追跡への最初の導入、場所変更、在庫チェック、出荷、装荷、荷おろし、及び追跡の終了を含む。
処置アクション「品目の作成」は、製造業者、タイプ、生産日及び場所などのような、品目の初期プロパティを記録する。このアクションは、与えられたあるデータでタグを初期化することも含む場合がある。これは、一般に、品目の初期貯蔵場所の指示を含む。
【０１１６】
処置アクション「場所変更」は、品目を新たな所与の場所に移動する又は既に移動したことを示す。「在庫チェック」は、品目が、貯蔵場所において検知されたことを記録することを示す。
処置アクション「出荷」は、品目がある出荷品の一部として指定されることを示す。ローカルＥＲＰシステムにはわかっている出荷番号を与えればよい。
処置アクション「装荷」は、ある輸送車両に装荷している間に、品目が検知されることを示す。トラック又はその他の輸送ＩＤを出荷ＩＤに繋ぎ合わせばよい。
処置アクション「荷降ろし」は、ある車両の荷降ろし中に、品目が検知されることを示す。車両ＩＤを出荷ＩＤに繋ぎ合わせればよい。
処置アクション「逆転」(reversal)は、同一品目及び同一バッチに対する以前のあらゆる処置を事実上取り消すアクションである。これは、以前の処置を逆に行うために必要とされることが多い。例えば、逆転は、装荷した品目が多過ぎたときに行われる場合がある。このアクションは幕等元ではない。
処置アクション「追跡の終了」は、品目が追跡システムによって再度見られることが予期されないことを示す。このアクションは、例えば、小売店の販売において、又は品目のパッケージを開いて、ケースを再利用する場合に行うことができる。本システムは、後の保証又は履歴の目的のために、品目データを保管することができる。
他にも可能な処置は多数ある。処置の柔軟な指定が好ましい。
【０１１７】
出荷
出荷は、通例、品目−タイプ品質リストの形式で梱包リストを識別する。また、出荷は、これらの品目タイプの宛先への計画的な移動を規定する。宛先とは、住所がある顧客、又は同じ会社の別の場所が考えられる。追跡システムは、住所から、位置、例えば、緯度及び経度を判定するか、あるいは出荷記述の一部としてこの情報を受信する。
出荷は、ローカルＥＲＰシステムには知られている。追跡システムは、出荷情報を検索し、特定の品目を、出荷品リスト内の総括品目タイプと照合し、不一致を報告する。
特定の輸送車両と関連付けることができる。例えば、いくつかの異なる出荷、あるものは同じ住所に行き、あるものは異なる住所に行く１つ以上の計画的出荷品を、同じトラックに装荷することもできる。本システムは、トラックに正しく装荷されたことを検証することができる。また、本システムは、トラックを追跡するか又はその位置を推定し、商品の位置に関する問い合わせに応答することができる。
実際には、特定の論理的出荷は、数台の輸送車両にまたがる場合もある。この状況では、本システムは、論理的出荷ではなく、物理的出荷を追跡する。
本システムは、輸送車両を識別し、それと通信する方法を示す。したがって、本システムは、「サンフランシスコに向かっている私の肉の出荷品が汚染されているので、運転手の名前と移動電話の番号を教えて下さい」というような質問に応答することができる。
【０１１８】
輸送経路
「輸送経路」情報は、船舶又はトラックのような輸送車両の予測地理的経路に関する情報である。これは、都市や高速道路の交差点、個々の高速道路又は道路の名称、経度及び緯度などのような、一連の中間地点とすることができる。輸送経路は、明示的に与えてもよい。例えば、これを手作業で入力してもよい。あるいは、これを計算したり、あるいは推論してもよい。これについては、以下で説明する。輸送経路は、直接輸送車両に当てはまるが、特定の出荷には間接的に当てはまるに過ぎない。
【０１１９】
処置メッセージ
処置メッセージは、ある品目が規定時刻に検知され、例えば、別の貯蔵場所への移動、顧客への出荷というような、特定の処置のために意図されたバッチの一部であったことを示す。処置メッセージは、次の形式にすることができる。
タイムスタンプ、バッチＩＤ、品目ＩＤ
この簡潔なメッセージは、品目、リーダ、及びローカルＥＲＰシステムにはわかっている出荷番号を互いに結び付ける。同じ処置メッセージを繰り返し送信すると、追跡システムの状態を変化させないという非常に有利な特性が得られる。
タグ・メモリ
記載した本システムの目的及び機能性は、タグ付品目の追跡のみに関する。しかしながら、特定の用途では、タグを検知したときに、ある段階で品目タグにデータを書き込むことを必要とする場合もある。本システムは、このようなタグ・データをいずれの現場でも書き込んだり、読み出すことができる。
【０１２０】
本システムは、大規模なイベント報告を提供することができる。例えば、本システムは、特定の重大な出来事が発生したときに、他のアプリケーションに報告することができる。これは、例えば、出荷が顧客に到着したときにメッセージを送ることができ、これによって請求書を発行させることができる。
【０１２１】
３．２  企業間の可視性
本システムは、供給連鎖における品目の企業間可視性を可能にする。本システムは、品目が単一の企業内又は多数の企業間で移動する際の品目の位置というような、品目の可視処置情報を受信し、格納し、作成することができる。加えて、本システムは、品目を顧客の注文、出荷文書、及びその他の業務処理と関係付ける可視相関情報を受信し、格納し、作成することができる。本システムは、相関又は処置情報を、供給連鎖におけるいずれの関与者又は企業からも受信することができ、供給連鎖における他の関与者又は企業が見ることができる情報を作成することができる。
図２６に示すように、本システムは、品目を追跡し、非常に大規模な追跡情報にアクセスすることができる。例えば、このインフラストラクチャは、国中又は世界中の工場、倉庫、小売り販路、家庭を含む、多くの様々な設定で配置されている品目を追跡することができる。
【０１２２】
可視性の制御
一実施態様では、本システムは、可視性を制御することができる。言い換えると、品目追跡情報の部分集合のみを、供給連鎖における特定の関与者に見えるようにする。図２８に示すように、本システムは、品目の種々の属性に対して許可設定を指定する許可情報を受信することができる。本システムは、この許可情報を用いて、どの属性をどの企業に見えるようにするか決定する。例えば、図２８に示す許可モデルは、品目の宛先属性を発送元には見えるようにするが、製造業者には見えるようにしないことを指定する。可視性の制御については、見出し「追跡情報へのアクセスの制御」において、以下で更に詳しく論ずることにする。
【０１２３】
ワールド・モデル構造
図２７は、多数の企業が供給するワールド・モデル（ＷＭ）構造を示す。ワールド・モデルは、関係の表現、状態、及びＩＴＳが追跡している品目の履歴を記録し保持する構造である。ワールド・モデルは、２列構造として実現することができる。即ち、上位列の親ＷＭ２７１０は、特定の企業内部にある品目を追跡し、下位列のローカルＷＭ２７２０は、特定の企業内のある物理的な場所に位置する品目を追跡する。ローカルＷＭは、ローカルＩＴＳ１４０３（図４に示す）内部に収容することができ、親ＷＭは、共有ＩＴＳ１４０４内部に収容することができる。ネットワーク接続部１４０５を通じて、一方の企業の親ＷＭは、他の企業の親ＷＭ、又は当該企業内の別の部署即ち列の親ＷＭと通信することができる。
【０１２４】
図２７は、連合、即ち、ピア会社構成を示し、各企業は、他の企業と直接情報を共有する。本システムは、他の種類の構成にも対応可能である。例えば、図２９は、各企業の親ＷＭ２９２０が情報を中央ＷＭ２１９０に提供する、階層、即ち、コンソーシアム構成を示す。あるいは、連合及び階層構成を組み合わすこともできる。例えば、連合モデルにおける親ＷＭ２７１０の１つは、親ＷＭ２９２０のコンソーシアムの中央ＷＭ２９１０も代表することができる。
図２７では、各企業は、単一の親ＷＭ２７１０を有するように示されている。しかしながら、場合によっては、例えば、スケーラビリティ(scalability)の目的で、親ＷＭ２７１０を、図３０に示すように、親ＷＭ群３０１０のクラスタとして実現することもできる。各親ＷＭ３０１０は、企業内の異なる製品クラス集合に対応することができる。各親ＷＭ３０１０は、ローカルＷＭ２７１０、他の企業における他の親ＷＭ２１７０、及びＥＲＰシステムのような上位業務アプリケーションへの接続性も維持する。
【０１２５】
３．３  ワールド・モデル間のデータ通信及びコヒーレンス
以下の節では、図２７に示した連合アーキテクチャのような、分散アーキテクチャの多数のノードを通じてデータを伝達するシステム及び方法について説明する。
本方法は、ローカルＷＭ２７２０と親ＷＭ２７１０間における双方向通信を設ける。親ＷＭ２７１０は、追跡対象品目に関する変更（例えば、汚染肉のリコール通知、又は価格変更）を他のＷＭに報告することができる。逆に、ローカルＷＭ２７２０は、品目処置の変更（例えば、品目の作成、移動、又は終了）を親ＷＭ２７１０に報告することができる。
【０１２６】
各品目毎に、少なくとも１つの親ＷＭ２７１０が、当該品目の担当ＷＭとして指定される。連合全体におけるいずれのローカルＷＭ２７１０が受信した品目に関するいずれの情報も、担当ＷＭに報告される。このようにして、担当ＷＭは、品目の完全な履歴を保持する。担当ＷＭを二重化して、データ復元を改善することもできる。例えば、第２ＷＭ２７１０も当該品目の担当ＷＭとして指定することができ、この品目に関して受信したあらゆる情報が双方の担当ＷＭに送られる。
品目に関する情報を保持するその他の非担当ＷＭは、一旦「業務に重要な」変更を担当ＷＭに報告したならば、情報を自由に浄化・除去することができる。したがって、いずれのローカルＷＭ２７２０も、空のＷＭから再起動することができる。しかしながら、再起動前に報告されなかった変更は、これらの変更が再起動の前に内部ストレージにセーブされていない限り、失われてしまう。
【０１２７】
担当ＷＭへのデータ転送
ローカルＷＭ２７１０は、タグ・リード・データの多数のインスタンスを受信し、各インスタンスは、ローカル・ノードにおいて検出された品目に結合されているタグから読み取られた情報を含む。タグ・リード・データの多数のインスタンスは、一括して、品目の出荷において多数の品目に結合されたタグから読み取った情報を含むことができる。供給連鎖における出荷は、多くの場合、出荷内に収容される１つ以上のレベルの品目を収容する（例えば、出荷は、個々の品目を収容するケースを収容する荷台を収容する場合がある）。したがって、場合によっては、ローカルＷＭ２７２０は、出荷タグから読み取ったデータ、及び出荷内に収容されている品目に対するタグから読み取ったデータ（例えば、荷台、ケース、及び個々の品目）の双方を受信することができる。
【０１２８】
品目毎に、ローカルＷＭ２７２０は、タグ・リード・データを、当該品目の担当ＷＭに報告する。品目の担当ＷＭを決定するために、ローカルＷＭ２７２０は、品目と指定された担当ノードとの間の関連を保持するマッピング表を調べることができる。マッピング表には、品目のＵＩＤの全て又はいずれかの部分を用いて問い合わせることができる。
出荷品内の各品目を、指定した担当ＷＭにマッピングすることができる。異なる製品クラスに属する品目は、異なる指定担当ＷＭにマッピングすることができる。品目毎に、指定された担当ＷＭは、全てのノードにわたって同一とすることができ、あるいはノード毎に変更することもできる。言い換えると、各ノードは、それ自体のマッピング表を保持し、各マッピング表内の関連は、ノード毎に異なることも可能である。
【０１２９】
例えば、単一の企業内において、全ての業務重要品目の移動を、当該企業の親ＷＭに報告することを、動作ルールが決定することができる。親ＷＭは単一のＷＭでもクラスタでも可能である。一旦移動が親ＷＭに報告されると、この親ＷＭは、ある品目の移動を企業外部の別のＷＭに報告するように構成することができる。例えば、小売店が品目の移動を製造業者に報告すれば、一層効率的な供給連鎖の運用が可能となる。したがって、小売店レベルである道具が販売されたとき、ローカルＷＭは、担当ＷＭが同じ企業内部の親ＷＭであることを判断することができる。しかしながら、親ＷＭノードでは、親ＷＭは、同じ道具の担当ＷＭが異なる企業の親ＷＭであると判断することができる。一例の場合では、リモートＷＭはその特定の道具の製造業者に対応することができる。別の例の場合には、リモートＷＭは、道具の全メーカなどの業務の組み合わせを代表する場合もある。
【０１３０】
ある場合には、１つのノードを、他のノードの転送及び発送エージェントとして作用するように構成することができる。例えば、製造業者が、企業外部からの全ての更新に対して、単一の外部からアクセス可能なノードを特定することができる。このノードにおいて変更が一旦受信されると、ノードは、それ自体の内部の担当ＷＭマッピング表を調べ、製品クラスに応じて更新を分散することができる。これは、企業外部には見えないように、計算及びデータ格納負荷を拡散することができる。
【０１３１】
以下の節では、ＷＭ間で状態情報を交換するプロトコルの一実施態様について説明する。この実施態様は、状態交換メッセージを用いて、ＷＭ間で状態データを交換する。メッセージ・パラメータには、品目のＵＩＤ、品目の現状態、及び最後に状態が変化したときのタイム・スタンプが含まれる。状態交換の受信側は、承認メッセージで応答し、現在の既知の状態及びタイム・スタンプを示す。状態変更メッセージは、承認が受信されるまで、再度送られる。
【０１３２】
品目（アイテム）作成
製造業者（企業Ａ）の物理的サイトにおいて品目が最初に作成されるとき、物理サイトのローカルＷＭ（ワールド・モデルＷＭ＿ＡＬ１）は、「品目作成」処置アクションを受信する。次いで、ＷＭ＿ＡＬ１は、論理表現、例えば、品目のオブジェクト表現を作成し、このオブジェクトが「アクティブ、ダーティ」状態にあると指定する。
オブジェクトの状態は、「アクティブ」、「据置(deferred)」、「保留(pending)」、又は「ダーティ」フラグを含む、フラグの組み合わせを用いて指定することができる。「アクティブ」は、オブジェクトが当該オブジェクトの最新バージョンであることを表すことを意味する。「据置」は、他のあるワールド・モデルが一意のアクティブ・バージョンを有することを意味する。「保留」は、システムが正しい指定を取り込む間に用いられる一時的な指定である。「ダーティ」は、担当ＷＭに最後に報告してからステータスが変化しており、業務に重要であることを意味する。
【０１３３】
ＷＭ＿ＡＬ１は、次に、品目の作成を担当ＷＭ（ＷＭ＿ＡＰ）に報告する。この報告は、状態交換メッセージの形式を取ることができる。
ＷＭ＿ＡＰは、ローカル・オブジェクトを作成し、「据置」と指定する。次いで、ＷＭ＿ＡＰは、このオブジェクトを、ＷＭ＿ＡＬ１のWhereUsedリストに入れる。WhereUsedリストは、どのオブジェクトがどのローカルＷＭ内に位置するかを追跡するマッピングである。
ＷＭ＿ＡＰは、次に、状態変化及び承認メッセージをＷＭ＿ＡＬ１に送る。この状態変化及び承認メッセージは、親が新たに作成された品目と関連付けられることを望んでいるという情報を含むこともできる。承認を受信すると、ＷＭ＿ＡＬ１は、「ダーティ」の指定をオブジェクトから削除する。
【０１３４】
後続の業務重要変更
一旦品目を作成したなら、後続の業務重要変更も担当ＷＭに報告される。ＷＭ＿ＡＬ１は、オブジェクトの状態を「アクティブ、ダーティ」に変更し、状態交換メッセージを担当ＷＭ（ＷＭ＿ＡＰ）に送り、変更が記録されたというＷＭ＿ＡＰからの承認を受信すると、「ダーティ」フラグをクリアする。
【０１３５】
サイト外への移動
ＷＭ＿ＡＬ１がサイトの出口ゲートにおいて品目を検出したとき、ＷＭ＿ＡＬ１はこれを担当ＷＭに業務重要イベントとして報告する。ＷＭ＿ＡＬ１は、オブジェクト状態を「据置、ダーティ」に設定し、状態変更メッセージをＷＭ＿ＡＰに送る。ＷＭ＿ＡＰは、ローカル・オブジェクトを「据置」に更新し、承認をＷＭ＿ＡＬ１に送る。ＷＭ＿ＡＬ１は、承認を受信すると、ダーティ・フラグをクリアする。
【０１３６】
収集及び通信宛先情報
場合によっては、品目の宛先がわかっている場合もある。宛先は、同じ企業内の別のサイトの可能性もあり、あるいは宛先は別の企業の可能性もある。例えば、品目に関連する業務文書は、宛先情報を含んでいる場合もある。業務文書情報は、ＥＲＰ（企業計画システム）のような従来の企業ソフトウェア・システムとの通信によって取得する。例えば、業務情報は、品目タグの階層によって表される特定の出荷を、従来のシステムが理解する出荷及び注文番号と関係付ける。組織、サイト、出荷先住所は、全て、物理品目に割り当てられるＵＩＤと同様に一意のＵＩＤが関連付けられる。出荷の事前通知を受信する目標ＷＭは、出荷記録の１フィールド内に明示的に指定することができ、あるいは物理的品目の担当ＷＭを見つけるときに用いたのと同じ機構を用いて計算することが好ましい場合もある。
例えば、担当ＷＭ転送及び更新機構を用いると、出荷階層の事前通知を次のように送信することができる。出荷宛先レコードを、担当ＷＭがこの出荷品を受領する予定のＷＭであると予想されるＵＩＤによって作成することができる。一旦この出荷品が物理的に組み立てられ、この出荷品についての特定の品目タグがわかったなら、このタグ階層を、集荷宛先レコードに対する変更として記録することができる。このレコードに対するいかなる変更も、実際の目標宛先ＷＭとして設定されている担当ＷＭに自動的に通信することができる。一旦物理的な出荷品がそのＷＭに到着すれば、全てのタグ情報を有し、正確な出荷内容を完全に検証することができる。
他の場合では、商品の宛先は、システム内部ではわからない場合もある。これは、ＥＲＰシステムとの統合不足の結果である可能性がある。本システム全体は、両方の場合を扱うことができる。
【０１３７】
同じ企業内の別のサイトへの移動（サイトＡＬ２）
宛先がわかっている場合、ＷＭ＿ＡＰはオブジェクトをＷＭ＿ＡＬ２のWhereUsedリストに入れ、状態交換メッセージをＷＭ＿ＡＬ２に送る。品目がサイトＡＬ２に到着すると、ＷＭ＿ＡＬ２はオブジェクトの状態を「アクティブ、ダーティ」に変更し、状態交換メッセージをＷＭ＿ＡＰに送る。ＷＭ＿ＡＰはローカル・オブジェクトを変更し、状態交換及び承認メッセージで応答する。
場合によっては、宛先が前もって知らされていないこともある。品目が宛先サイトＡＬ２に到着すると、ＷＭ＿ＡＬ２は「保留、ダーティ」状態のローカル・オブジェクトを作成し、状態交換メッセージをＷＭ＿ＡＰに送る。ＷＭ＿ＡＰはそのローカル・オブジェクトを更新し、そのローカル・オブジェクトをＷＭ＿ＡＬ２の「WhereUsed」リストに移動し、ＭＷ＿ＡＬ１への状態交換及び承認メッセージで応答する。
【０１３８】
他の企業への移動（サイトＢＬ１）
宛先がわかっている場合、ＷＭ＿ＡＰは状態交換メッセージを宛先サイト（ＷＭ＿ＢＰ）の親ＷＭに送る。ＷＭ＿ＢＰは「据置」オブジェクトを作成し、これをＷＭ＿ＢＬ１のWhereUsedリストに入れる。ＷＭ＿ＢＰは、ＷＭ＿ＡＰへの状態交換及び承認メッセージで応答し、更に状態交換メッセージをＷＭ＿ＢＬ１にも送る。ＷＭ＿ＢＬ１は「据置」オブジェクトを作成し、これを着信リストに入れる。ＷＭ＿ＢＬ１は、ＷＭ＿ＢＰへの状態交換及び承認メッセージで応答する。
品目がサイトＢＬ１に到着すると、ＷＭ＿ＢＬ１はオブジェクトの状態を「アクティブ、ダーティ」に変更し、状態交換メッセージをＷＭ＿ＢＰに送る。ＷＭ＿ＢＰはローカル・オブジェクトを更新し、状態交換及び承認メッセージで応答する。次いで、ＷＭ＿ＢＰはダーティ・フラグをセットし、状態交換を担当ＷＰ、即ち、ＷＭ＿ＡＰに送る。ＷＭ＿ＡＰはそのローカル・オブジェクト及びWhereUsedリストを更新し、ＷＭ＿ＢＰへの状態交換及び承認メッセージで応答する。
【０１３９】
宛先が事前にはわかっておらず、品目がＢＬ１に到着した場合、ＷＭ＿ＢＬ１は「保留、アクティブ、ダーティ」フラグを作成し、状態交換メッセージをＷＭ＿ＢＰに送る。ＷＭ＿ＢＰは「保留、アクティブ、ダーティ」オブジェクトを作成し、これをＷＭ＿ＢＬ１のWhereUsedリストに入れ、ＷＭ＿ＢＬ１への状態交換及び承認メッセージで応答する。次いで、ＷＭ＿ＢＰは、状態交換を担当ＷＭ，即ち、ＷＭ＿ＡＰに送る。ＷＭ＿ＡＰは、そのローカル・オブジェクト及びWhereUsedリストを更新し、ＷＭ＿ＢＰへの状態交換及び承認メッセージで応答する。
【０１４０】
ＷＭ間のデータ通信量の削減
代替実施態様では、特定のローカルＷＭと特定の担当ＷＭとの間のように、出荷又は品目の階層内におけるあらゆる品目を担当ＷＭに報告しなくても済むように、２つのＷＭを構成することができる。どの品目を報告するかは、異なるＷＭ対間では異ならせることができる。
品目階層を定義する情報は、ローカルＷＭ及び担当ＷＭ双方に提供することができる。ローカル・ノードにおいて検出された品目毎に、ローカルＷＭは、提供された階層情報と突き合わせて、各品目を検証することができる。しかしながら、担当ＷＭに報告するときは、ローカルＷＭは階層内のあるレベル（例えば、最上レベル）の品目のみを、この階層より下の品目も全て検証したという追加の指示と共に報告することができる。
【０１４１】
メッセージ損失又は二重送信の下における信頼性
「保留」又は「ダーティ」状態は、確実に「アクティブ」又は「据置」状態に変換される。何故なら、承認が受信されるまで状態交換メッセージが自動的に再試行されるからである。場合によっては、例えば、ＷＭが永続的ストレージから再ブートした後に、二重送信を行うことができる。状態交換メッセージはタイムスタンプを担持しているので、据え置かれたエンティティが着信した更新よりも古い場合にのみ、これらに作用する。
ＮＴＰ（ネットワーク時間プロトコル）又はＧＰＳクロックのような従来の機構を用いて、ネットワーク全域でクロックの同期を取ることができる。しかしながら、本システムは、高度のクロック同期がなくても動作することができる。
【０１４２】
システムのコールド再スタート
本システムは、空のローカルＷＭで構築することができる。後に品目を検出したときにはいつでも、「保留」オブジェクトが作成される。一旦全ての品目を見たなら、ＷＭは完成する。
【０１４３】
周期的クリーンアップ
ローカルＷＭは、周期的に、「保留」又は「ダーティ」オブジェクト、又はある期間更新されていないオブジェクトの更新を要求することができる。ある期間参照されていないオブジェクトは、自由メモリに追い出すことができる。担当ＷＭは、ある期間参照されないオブジェクトを長期ストレージに追い出す、即ち、移動させることができる。
【０１４４】
３．４  国際取引における品目毎の識別
以下の場面では、輸入に関係する情報を扱う際の、政府の税関部門の必要性に対する、タグ付け及び追跡システム及び方法の技術について、図５４を参照しながら説明する。以下に説明する応用は、品目追跡システム（ＩＴＳ）のためのコア・ネットワーク状情報環境に基づいており、これをＩＴＳコアと呼ぶ。ＩＴＳコアは、国境を超える商品の輸入に関係する情報を扱うという本応用を支援するために、以下の機能性を提供する。
【０１４５】
・リーダによって読み取られた個々の品目を識別する、タグ・リーダ・システムからの情報を受信及び保持し、一般に、当該品目に意図した処置のようなコンテキスト情報を提供する。
・品目間の物理的関係を指定する情報を受信し保持する。このような関係の変化も含み、１つの品目が他方の中又は上にあるというようなことも含む。（例えば、ビンが箱の中にあり、箱は荷台の上にあり、荷台はコンテナの中に置かれ、コンテナは船舶上に置かれる）。
・拡張可能な形式で品目に関するプロパティ情報を受信し保持することにより、コアを用いるアプリケーションが、コアの再プログラムを全く必要とせずに、コアが保持している品目に関する情報に、新たな種類の情報を追加できるようにする。
・企業の境界を超えて、自己記述ＸＭＬ（拡張可能マークアップ言語）文書の形式のような、普遍的にアクセス可能な形式で、このような情報を提供する。
【０１４６】
・ＩＴＳコアは、品目間、更に一般的には、論理及び物理品目間の論理関係を指定する情報を提供し、受信し、保持する。例えば、ＩＴＳは、
（ａ）輸出供給元工場、
（ｂ）宛先の受領人、
（ｃ）担当輸入代理店
（ｄ）一意のタグ識別子を有する、輸入する特定製品のリスト、及び
（ｅ）品目のタイプ毎の特定の関税規則に対する一意の参照、
を指定する計画出荷に関する情報を受信する。
論理品目（ａ、ｂ、ｃ、ｅ）は、物理的品目として扱われ、ＩＴＳにおいて特定のエントリを有する。ＩＴＳは、入来する情報を用いて、物理的及び論理的品目間の論理関係を構築し維持する。これによって、例えば、入港する港において税関官吏による、出荷における物理的品目タグのいかなる読み取りも、直ちに対応する出荷文書、及び要求に関係する税関規則に関係付けることが可能となる。同様に、輸入側のいずれに対するいずれの参照も、直ちに出荷品（又は複数の出荷品）における品目のリストに導く。論理品目構造は、荷台、コンテナ、車両、及びその他の梱包単位、保管、又は輸送との関係を含む。船舶の位置は、周期的に更新することができ、したがって、ある港に入るように計画されている商品の位置について実際の知識が得られる。したがって、船舶が入港すると、関税部門は、正確な商品並びにそれらの輸送及び保管履歴を、紙の文書を調べる必要なく、知ることができる。この情報は、適切な人員を計画し、疑惑の輸入業者に照準を当て、それ以外では税関業務を支援するために用いることができる。
・ＩＴＳは、品目の移動の全履歴を、タグ・リーダ及びその他の情報源によって報告される通りに保持する。この情報は、税関機関(customs agency)が、自身の調査及び統計的目的のために用いることができる。また、この情報は、輸入業者、荷送人、及び彼らの出荷品の現在の位置及び処置を追跡する必要があるその他の者にも非常に価値がある。
【０１４７】
以下に記載する実施態様では、ｅＰＣが一意の品目識別子及び品目クラスを、ＥＡＮ（ヨーロッパ製品番号）又はＵＰＣ（統一製品コード）情報の拡張として収容し、一方ＰＭＬ（物理的マークアップ言語）文書が、品目の物理的記載を収容するために用いられる。
ＩＴＳコアは、公開され、非常にスケーラブルな、リアル・タイム物資追跡インフラストラクチャであり、ネットワーク状品目一意タグ(item-unique tag)のインフラストラクチャからのリアル・タイム物資情報を収集し、統合化し、企業のアプリケーションに分配する。このインフラストラクチャは、適したタグ・リーダと共に構築され、これらのリーダは、ネットワークを通じて１つ以上のＩＴＳシステムに接続されている。したがって、これらタグ付品目の移動は、品目がタグ・リーダによって報告される毎に、中央位置からリアル・タイムに追跡することができる。ネットワーク状タグは、企業と、スマート品目と呼ばれる一意に識別される有形及び無形品目、並びにこれらを保持し管理する保管人の集団との間に双方向通信経路を形成する。タグの一部をスマートとすれば、スマート品目が得られる。スマート品目及び機械は、エンド・ユーザがタグに書き込むあらゆる情報を収容し伝達する。
【０１４８】
ｅＰＣ、ＰＭＬ、サイズ、重量、価格、保証、履歴のような、商業用情報をタグに書き込むことに加えて、タグは、製品レベルの規則及び規制、税金及び料金情報、更新された取引契約規則、優先的扱い指示、１国以上の税関表、１国以上の輸入制限、保管指示、有害物管理情報、並びに税関サービスが出荷を迅速に処理し、近代化の目的を達成するために必要なその他のあらゆる情報を収容することもできる。
【０１４９】
ＩＴＳは、位置、状態、税関の処理ステータスに関する情報、及びシステム全体における全てのタグ付品目の処理に関するその他の情報を有する。この情報は、ＩＴＳから直接、又はＩＴＳからのデータを収集する既存の及び新たなアプリケーションを通じて得ることができる。ＩＴＳコアは、公開され、汎用的で、アプリケーションにはとらわれず独立しているので、米国だけでも毎秒２０，０００，０００イベントを超える、税関部門が扱うと予測される膨大な数のイベントを、従来の供給連鎖の管理や業務計画システムのような、コアの企業ソフトウェア・システムに負担をかけずに、処理することができる。ＩＴＳは、大量の個々の品目及び出荷単位を追跡するが、従来の供給連鎖管理システムは、通常、品目の両の追跡に関与するだけに過ぎない。例えば、ＩＴＳは２０，０００台の個々のカメラを追跡することができ、従来の供給連鎖管理システムは、これを単一のエントリと見なす。
【０１５０】
ここに記載するＩＴＳコア及びアプリケーションは、ある重要な機能性を提供する。
・関税部門から元の製造業者及び輸入業差への詳細な品目タイプに特定した通信。
・元の製造業者から関税部門への品目及び出荷計画に関する、安全で、認証された詳細な（荷台及び品目レベル、連番に特定）通信。
・起源地点から輸入港及びそれ以降の自動化したペーパーレスの商品追跡。
・紙の文書を調べる必要なく、各荷台又は品目上のタグは、予め報告した出荷計画を直接物理的輸入商品に結び付ける。
・広く実現した場合、ＩＴＳコアを用いたシステムのネットワーク型インスタンスは、ワールドの取引システムにおける商品の多くが位置する場所、意図した輸入港、及びこれら特定品目の予め交渉し計画した関税での取り扱いを、リアル・タイムの画像で示すことができる。
【０１５１】
ＩＴＳコアを用いた税関システムは、国内取引及び関税代理店やＰＧＡ（関与する政府関係機関）、並びに、輸入業者及び輸出業者、取引促進業者、外国のＧＰＡ、荷送り及び業務計画サービス、小売店及び製造業者にとって、ネットワーク状リアル・タイム物資データ・レポジトリとして機能することができる。
ＩＴＳコアは、アプリケーションにとらわれない、オープン・ネットワーク・システムであるので、そのデータは、データベースと全く同様に、あらゆる企業のアプリケーション環境によって利用することができ、その中に継ぎ目なく統合することができる。多次元リアル・タイム物資データは、あらゆるアプリケーションによって、供給連鎖の管理、顧客及び供給業者関係管理、製品ライフサイクル管理、財政管理、人材管理、セキュリティ及び業務の情報処理化(intelligence)等のような、種々の処理のための使用及び分析のための使用に供することができる。リアル・タイム物資データは、多くのコンポーネントを有することができるので、多次元である。例えば、ＩＴＳは、品目を移動した時刻、コンテナ内における品目の相対的位置、コンテナの位置、例えば「チェック済み及び承認済み」のような論理ステータス、担当の荷送人、意図した宛先などを追跡することができる。
【０１５２】
ＩＴＳコアの１つ以上のインスタンス及び支援アプリケーションは、メインフレーム、クライアント・サーバ、及び分散型ネットワーク環境上で機能し、今日用いられているインターネットと同じように、ローカル個人ネットワーク及び大域共同ネットワーク双方として展開することができる。エンド・ユーザは、個人的ネットワーク内のデスクトップ企業ポータル、インターネット、直接暗号化電話接続、パーソナル・ディジタル・アシスタント（ＰＤＡ）、並びに移動機器及び電話による音声接続(voice-over-telephone connection)を含む、多数の接触点を通じてＩＴＳデータにアクセスすることができる。
【０１５３】
図５４は、米国への商品の輸入、及び米国税関部門並びにその他の政府関係機関及び業務によるＩＴＳ情報の使用を伴う場面における、自動化ＩＴＳ情報フローの段階を示す。前述の機関や業務を総括的にここでは企業と呼ぶことにする。
図５４において、企業又は企業群は、矩形で表されており、それらの各ローカルＩＴＳ資源は、付随する楕円で表されており、情報のフローは、番号が付いた矢印によって表されており、図における番号は、以下の各段階の説明における見出しの番号に対応する。各企業のローカルＩＴＳ資源は、ＩＴＳコアの１つ以上のインスタンス及び支援アプリケーションとすることができ、これらが一体となって、ローカルＩＴＳネットワークを構成する。単一及び多数のネットワークを図示したのは、単に図を簡略化するために過ぎない。図５４に対応する場面は、次のように進んでいく。
【０１５４】
５４０１
小売店／エンド・ユーザが、国際的製造業者又は供給業者に発注し、製品の分類、個数、金額、契約条件等を指定する。
５４０２
製造業者は、小売店／エンド・ユーザの仕様にしたがって製品を生産し、ｅＰＣ及びＰＭＬ文書（ＰＭＬｓ）を各製品の品目特定タグ(item-unique tag)に割り当てて書き込み、この情報をＩＴＳに提供する。（あるいは、ＰＭＬ及びｅＰＣ以外のその他の情報は、タグに必要な記憶容量がない場合、ＩＴＳデータ記憶部のみに記録することもできる。）
製造業者は、価格、保証、製作費、製品分類、重量、サイズ、製造業者、出荷条件及び指示等のような関連する商業データを各製品のタグに書き込み、品目ＩＤを出荷のために用意する。この情報の全ては、必ずＩＴＳに提供されるので、この情報を用いることができるあらゆるアプリケーションが見ることができる。タグへの記憶は、ＩＴＳサイトへのネットワーク接続部に都合良くアクセスできない税関の官吏及びハンド・ヘルド・リーダを有するその他の者のために行われる。
製造業者は、出荷を封印し、出荷にはタグが付けられており、タグ上の情報は、出荷しようとしている品目と同一であることを確認し、データを中央及び共同米国関税部門のＩＴＳネットワークにアップロードする。同時に、製造業者は、発注情報を、広域荷送り及び業務計画サービスに送り、集荷及び転送してもらう。最後に、製造業者は、小売店に、出荷ステータスをリアル・タイムで通知する。
【０１５５】
５４０３
米国の税関は、更新した料金、特殊扱い及び保管指示、輸入規則及び規制、並びにその他の関連する規制情報を、自動的にＰＧＡ、広域荷送り及び業務計画サービスに送る。
５４０４
広域荷送り／業務計画サービスは、米国関税の規制及び税金情報を、ＩＴＳ、及びタグがこれに対応する範囲で、出荷する製品に関連がある出荷用箱、荷台、運搬ケースなどの上にあるタグに、適切な出荷階層で自動的に書き込む。次いで、広域荷送り／業務計画サービスは、ｅＰＣ並びに米国及び外国の関税の指定及び規制によって、出荷を集合化し分類する。製品及び出荷は、纏められ適切な階層に分けられ、荷台、箱、運搬ケース、及び配送車両（トラック、船、飛行機、車等）に割り当てられる。
出荷情報は、該当するローカル／外国のＧＰＡ及び税関に送られる。この情報は、概略的に、車両識別情報、輸入／規制情報、重量、潜在的な危険性、製造業者、ｅＰＣ、体積等を含む。データは、出荷される品目／箱／運搬ケースに割り当てられる。出荷ＩＤ情報は、配送車両のＧＰＳ（全地球測地衛星）及び出荷の電子的決済に用いることができる税関のスマート・パス（高速道路自動車スマート・パスと同様）にアップロードし、利用可能とすることができる。必要であれば、広域荷送り／業務計画サービスは、全ての進行中の出荷品に関してリアル・タイムの位置、状態、及びコンテキスト情報を、米国及び地方の税関、米国のブローカ、輸入業者及び業務計画サービス、製造業者、並びに小売店に提供することができる。次いで、出荷を実行し、業務計画サービスは、出荷品の位置、及び推定到着時刻を、外国の税関部門及びＰＧＡにアップロードする。
【０１５６】
５４０５
外国のＰＧＡ／税関は、リアル・タイムの事前出荷通知を全ての承認されている保管人に与え、出立する出荷タイミング、位置、及び日付を、米国税関と確認し記録する。更に、外国のＰＧＡ／税関は、出荷品が、製品及び出荷分類、業界及び出荷場所による最新の輸出要件を満たしていることを自動的に確認する。該当するＰＧＡ及び個人の保管人には、出荷が通知される。外国のＰＧＡ／税関は、出荷が全ての現行の輸出規制及び要件通りであること、該当するＰＧＡが適宜出荷を監視することも確認する。
最後に、外国のＰＧＡ／税関は、出荷保存及び取り扱い指示を対号する出荷港及び代理人に送る。
【０１５７】
５４０６
外国の税関機関／港は、該当する代理人に出荷が通知され、出荷が実行されるときに利用可能になることを確かめる。外国及び米国の代理人は、特定の商品に要求される、特殊な取り扱い及び保存指示を通信する。
５４０７
米国税関機関／港では、以下の活動が行われる。準拠する出荷／業務計画サービスの出荷品は、自動的に、現地の非破壊的読み取りシステムによって自動的に走査されつつ、港／国境入国場所(border entry location)を入力する。非破壊的タグ・リーダは、受領した製品が、ｅＰＣ及びＰＭＬにしたがって製造業者が識別し出荷した製品と同一であることを自動的に確認する。元のタグに書き込まれている全ての規制及びセキュリティ情報に対する遵守も確認される。出荷が間違っていたり、不正があった場合、各地の官吏に、手作業による検閲を実行し、しかるべき封じ込め処置を取るように、警告が与えられる。該当する官吏及びＰＧＡには、出荷が通知され、出荷が実行されるときに利用可能となる。米国税関機関／港は、出荷が全ての現行の料金、優先的取り扱い、保管要件、制限、規制等を遵守していることを自動的に確認することもできる。米国の税関は、入来する出荷について通知され、米国税関の統計のために必要な製品分類、価格、量、工業(industry)等により、リアル・タイムの出荷情報が与えられる。適切で正しい料金及び税金が自動的に徴収され入金される。全ての関係する出荷情報は、米国のブローカ及び輸入業者に送られる。タグの中には、出荷する品目の組成（例えば、タイヤはタイヤの材料のみを含有し、麻薬や密輸品を含有していない）を中継(relay)し、確認することができるものもある。
【０１５８】
５４０８
ブローカ／輸入業者は、自動的に正しい料金が徴収されたことを確認し、ローカルの業務計画サービス及び米国税関に、出荷のステータス及び条件を通知する。ブローカ／輸入業者は、更に、出荷が正しく、小売店及び製造業者の出荷条件に一致することを確認する。
５４０９
現地の出荷／業務計画サービスは、米国税関に出荷のステータス及び位置を通知し、出荷品を小売店／エンド・ユーザに配達する。
【０１５９】
５４１０
小売店／エンド・ユーザは、米国税関ＩＴＳにログ・オンすることができ、あるいは税関ＩＴＳからのステータス情報にアクセスできる別のシステムにアクセスして、いつでも正確な出荷ステータス、状態、及び位置を特定することができる。最後に、小売店／エンド・ユーザは、正しい集荷を確認し、製造業者に通知し、自動支払いを実行し、製造業者、荷送人、及び税関からの出荷文書に対して、出荷及びタグ情報を確認する。
図５４を参照しながら説明した以上の場面及びシステムには、以下の利点がある。
【０１６０】
１．取引及び経済成長
リアル・タイムで継ぎ目のない税関処理が、非破壊的タグを用いた検閲及び検査の使用によって達成することができる。出荷及び料金遵守レベルを高めることができる。リアル・タイムで自動化された商取引処理及び物資追跡ネットワークが提示され、ＰＧＡ及び個人的保管人を通じた危険及びセキュリティ管理システムと統合される。公正な取引実現に対するネットワーク状公共−個人共同及び調和及びその自動的保証が得られる。国際取引契約を自動的に管理し施行することができる。略奪的取引及び不公平な取引慣行の防止を、品目特定及びスマート・タグ技術及び模造品警報によって、大幅に改善することができる。自動料金適用及び更新によって、収益回収に伴う会計管理が自動化される。
【０１６１】
２．国境のセキュリティ
パスポートに埋め込んだスマート・カード又はタグ、旅行切符、運転免許書、又はその他の形態の国内又は国際ＩＤの使用によって、非常に危険な旅行者を自動的に特定し、到着に先だって取り押さえることができる。非破壊的個人識別システムを、リモート・タグ・リーダによって開発することができる。危険物、兵器、及び軍需品の出荷を前もって、そしてリアル・タイムで知ることができる。個人的企業及びＰＧＡの機密又は統制商品の輸出及び輸入に関する情報交換を改善することができる。
【０１６２】
３．麻薬取引
潜在的に麻薬の可能性がある出荷品の自動的、非破壊的識別を、危険性が高い出荷品の出荷品及び製品の遠隔測定（状態、温度、化学的組成等）の使用によって達成することができる。特定した危険性の高い荷送人及び国からの、特定した又は可能性が高い麻薬出荷に関するリアル・タイムのデータを取得することができ、これによって、ＰＧＡ通知、調整、及び資源割り当てを改善することができる。特定した運搬人に対するタグの事前の自動展開、目標設定技法の改良、及び阻止手段を得ることができる。
【０１６３】
４．犯罪的資金調達(Criminal Finance)
非破壊的調査インフラストラクチャは、自動出荷支払いを追跡し、実際の支払いを実際の出荷料金及び条件と照合することができる。偽った又は正しくない出荷支払い、犯罪的資金調達行為の潜在的なリアル・タイムの崩壊を自動的に識別することができる。ヨーロッパ連合を含むいくつかの国は、タグを実際の紙幣に埋め込むことを検討しており、大規模な現金移出をリアル・タイムで追跡可能となる。
【０１６４】
５．公共保護
許されない品物又は違法な品物によって生ずる潜在的に有害、危険、及び／又は命を脅かす状況の大幅な減少、並びにその事前管理及びリアル・タイムの追跡を改良することができる。ある業界、組織及び／又は外国に対する米国の禁輸及び制裁を、自動的にリアル・タイムで実現することができる。違法な商品及び／又は模造品の輸入を、自動的及びリアル・タイムの出荷品識別及び確認システムによって、大幅に減少させることができる。ｘ線バン(x-ray van)、ＲＦ及びマイクロ波飛行場セキュリティ・システムのような、非破壊検査技術は、選択タグを読むことができるようにすることにより、拡大し、最大化することができる。タグ情報を、ビデオ検出による画像認識技法と連携すれば、マルチメディア物資追跡が可能となる。
【０１６５】
６．管理責任
代理人の割り当ては、予測される出荷品、出荷品の性質（有害物質、生鮮食料品、出所等）に基づいて最適化でき、正しい代理人が正しいときに正しい場所で正しい出荷のために活用できることを保証する。代理人及び港の責任(accountability)は、出荷による一層信頼性が高く迅速な情報によって高まる可能性がある。精度が高い財務データ、輸入統計、格個人的及び公共の保管人についての資源及び物資を、リアル・タイムで自動的に追跡することができる。年に１回のそして暫定的なステータス及び検査報告を自動的に更新し、完成することができる。全てのＰＧＡ及び保管人に対するＧＡＯ（英国会計検査院）の勧告を自動的に実現することができる。ＵＰＣによるリアル・タイム輸入−輸出情報、製品分類、工業、製造業者、地理によって、リアル・タイムの国境状況の認識を達成することができる。
支払い更新のリアル・タイムの米国の収支、連邦会議予算事務局及び国庫に対する米国税関部門の情報、検査、出荷等の全履歴、並びにサービス品質の改良、即ち、自動料金、規制更新、統計情報を、個人及び公共の保管人によって共有することができる。
【０１６６】
前述の利点に加えて、以下のコスト削減も実現することができる。全てのタグに準拠した出荷に対する完全な又は殆ど完全なデータ精度並びにデータ入力冗長性の大幅な削減及びペーパーレス処理、手作業の検査に必要な税関職員の削減、自動出荷識別及び料金適用による、処理サイクル時間の大幅な改善、全てのタグ・システムに準拠した製造業者のための生産検証チームの訪問の減少、不正／模造品出荷の自動識別、全てのタグ付き出荷に対するＩＰＲ（知的財産権）差し押さえの改善、料金誤りの減少、正しい料金課金の確保、料金／税関及び取引の紛争減少、税関情報の改善による資源の最適化、輸入業者／輸出業者と自動出荷確認／ステータス情報を共有することによる、督促係(expeditor)からの金銭的節約、全ての追跡し目標とした物資に対する調査及び告発に対するＰＧＡのリアル・タイム調和の向上、全てのタグに準拠した出荷に対する非破壊的検査技術の利用による積荷強制検査(cargo enforcement examination)数の大幅な増加。
【０１６７】
税関部門は、このようなシステムを以下のように使用することにより、収益増大を実現することもできる。全てのタグ付き出荷に対する全ての現行の出荷契約及び税収入回収と調和した自動取引遵守、国境漏洩及び密輸の減少。料金回収の改良、より高い及び／又は新しいサービス料金に対する既存のサービス品質の向上、犯罪的物資、盗品及び模造品の差し止めの増加、私企業や別の政府関係機関に販売することができるリアル・タイム取引及び支払い収支情報等、次世代サービスを可能にする。
【０１６８】
３．５  品目のシナリオ(Item Scenario)
以下の節は、品目のシナリオについて説明する。
品目を作成するとき、次の場面（シナリオ）が起こり得る。品目を製造し、次いで特定の品目ＩＤと関連付ける。品目が製造から移動すると、最初のリーダにおいて追跡システムに入力する。そのステップは、（１）「新たな品目」を示す特性(disposition)及び全ての所望の品目のプロパティを作成し、（２）バッチＩＤ結合リーダ及び処置を作成することである。本システムは、一連の処置メッセージを察知し、これらを処理して、新たな品目のためのシステム・データを作成する。
品目を倉庫に転送するとき、以下の場面が起こり得る。転送に先だって、倉庫の作業員がシステムに、当該品目について計画したアクションを示す。リーダが固定した位置にあり、意図した位置に関して曖昧さがない場合、例えば、リーダが小さな保管室のドア上、又は保管室へ向かうコンベア・ベルト上にある場合、この情報は全てデフォルトとすることができる。そのステップは、（１）「処置−位置変更」を示す処置を作成する。（２）バッチＩＤ結合リーダ及び処置を作成することである。本システムは、位置の変化を示す一連の処置メッセージを察知する。
【０１６９】
品目を出荷するとき、以下の場面が起こり得る。通例、ローカルＥＲＰ又は業務計画システムは、エントリを有し、あるリストの品目タイプ及び量を所与の宛先においてある顧客に出荷すべきことを伝える。顧客は本人でもよい。システムは、以下の識別及び検証能力を備えているとよい。（１）出荷する特定の品目を識別する。（２）指定された品目のタイプ及び量が全て、実際に出荷に伴っていることを検証する。例えば、出荷及び梱包プロセスを内部ＥＲＰシステムに対して検証する。（３）特定の輸送車両に送られる予定の全ての出荷品、例えば、特定のトラックに装荷される出荷品を識別する。（４）全ての品目が実際に正しい輸送車両上に装荷されたことを検証する。
【０１７０】
配送の間、システムは、輸送車両の推定位置又は実際の位置を報告する。更に複雑な場面では、商品が輸送されている間に、再販売され、方向が変わることも考えられる。本システムは、正しい品目が各宛先において荷降ろしされることを検証する。本システムでは、任意に、宛先における出荷のＲＦＩＤ検知を、配送及び請求書発行の証拠として作用するようにさせることができる。本システムは、任意に、出荷の配達時刻を動的に捕捉し、内部配達時刻推定を更新することができる。
【０１７１】
これらのプリミティブを用いて、保管室から出荷に移る際に、以下のステップを実行することができる。ローカルＥＲＰシステムは、計画した出荷をローカルＩＴＳに報告する。保管室の係員は、システム・アプリケーションを用いて、リストから出荷ＩＤを選択し、SHIPMENTの処置タイプを選択し、ローカル・リーダＩＤを識別し、一意のバッチＩＤを生成する。係員は、既存の手順を用いて、倉庫から品目を引き出し、これらをリーダにかける。リーダは、一連の処置メッセージを、
タイムスタンプ、バッチＩＤ、品目ＩＤ
の形式でシステムに送る。
【０１７２】
係員は、システム・アプリケーション上でバッチの完了を指示する。システム・アプリケーションは、直ちに、足りない品目又は余分な品目のような、あらゆる不一致を指示することができる。これらの不一致は、逆転処置を用いることによって、この場で修正することができる。
【０１７３】
これらのプリミティブを用いて、出荷から輸送に移る際に、以下のステップを実行することができる。出荷係は、本システムを用いて、ある出荷品（既にシステムにはわかっている）がある輸送車両（例えば、トラック）に装荷されることを確認する。このアクションは、あるリーダ（トラックのための積み降ろしホームにある）を車両と関連付け、間接的に、出荷品の集合と関連付ける。その結果、バッチＩＤが得られる。リーダは、システムに、
タイム・スタンプ、バッチＩＤ、品目ＩＤ
の形式の一連の処置メッセージを送る。
【０１７４】
係員は、システム・アプリケーション上でバッチの完了を指示する。システム・アプリケーションは、直ちに、足りない品目又は余分な品目のような、あらゆる不一致を指示することができる。システムは、このトラックに装荷すべき出荷品の完全な集合を知っている。これらの不一致は、逆転処置を用いることによって、この場で修正することができる。いずれの特定の品目に関するシステムへのいずれのクエリも、それはこのトラック上にあり、ローカルＥＲＰシステムには知らせてある指定出荷ＩＤの一部であることを示す。したがって、ある品目がトラックから落下した場合、システム及びローカルＥＲＰシステム双方からの全ての情報を発見することができる。
【０１７５】
これらのプリミティブを用いて、輸送から受領に移る際に、以下のステップを実行することができる。トラックは、出荷地点の１つにおいて、積み降ろしホームに入る。本システムは、いずれの所与の出荷品についても、出荷宛先住所を既知のシステムの位置と関連付ける。受領係は、システム・アプリケーションを引き上げ、あるベンダによって配達が予定されている出荷品の集合を見せられる。あるいは、出荷係がトラックのＩＤを入力し、関連する出荷品のリストが与えられる。トラクタ−トレーラ・トラックのトラクタ部が道中で変化した場合、運転手は出荷指示、又はタグをも携行し、出荷品（複数の出荷品）を明確に識別することができる。最後に、係員は、元の出荷係（複数の出荷係）が用いたのと同じ輸送データ・オブジェクトを用いる。多数の供給源が出荷品を同じトラックに装荷する場合もある。
【０１７６】
多数の出荷品が関与しても、システム・アプリケーションは、どの品目をトラックから降ろすのか正確に知っている。処置形式は、「デフォルトの位置で積み降ろす」というように指示される。その結果、バッチＩＤが得られる。リーダは、一連の処置メッセージを、
タイムスタンプ  バッチＩＤ  品目ＩＤ
という形式でシステムに送る。
【０１７７】
係員は、システム・アプリケーション上でバッチの完了を指示する。本システムは、直ちに、余分な物質が降ろされたか否か、又は出荷品の一部がなおもトラック上に残っているか否か知らせることができる。
最後に、本システムは、出荷品が配達されたことを知り、請求メッセージを送ることができる。
【０１７８】
信頼性の問題
全てのメッセージは配信されるが、これらは任意の順序で出てくる場合があり、一部は再生される場合もある。本システムは、当該システムにおける種々のコンピュータのクラッシュや、蓄積されたメッセージにあり得る再生にも対処することができる。例えば、連鎖内の各コンピュータは、メッセージの集合を蓄積し、ディスクに記録することができる。上流側のコンピュータがクラッシュして再起動するとき、以前のメッセージの再生、又は内部に格納された未達メッセージと思われるものの再生を要求することができる。
【０１７９】
本システムは、イベントの任意の再生には影響されないようにすることができる。例えば、本システムは、以下の状況に遭遇する可能性がある。
タイムスタンプ１：品目Ｘが読み取られ、バッチＢ１の一部として報告される。
タイムスタンプ２：品目Ｘが読み取られ、バッチＢ１の一部として報告される。
このシーケンスは、単なる繰り返しであり、通例では、可能な限り低いレベルでフィルタ処理されるが、本システムに渡されることもある。
次に、操作者は、品目Ｘの移動は間違いであったことを発見し、逆を入力することもある。
タイムスタンプ３：品目Ｘを逆転する。
すると、本システムのある部分はクラッシュし、次の再生を生成する可能性がある。
タイムスタンプ２：品目Ｘを読み取り、バッチＢ１の一部として報告する。
恐らく、システムのクラッシュの仕方におけるある態様のために逆が再生されない場合、システムは、
タイムスタンプ１：品目Ｘが読み取られ、バッチＢ１の一部として報告される。
タイムスタンプ３：品目Ｘを逆転する。（バッチＢ１）
タイムスタンプ２：品目Ｘが読み取られ、バッチＢ１の一部として報告される。
を察知することになる。
しかしながら、正しい解釈は、品目Ｘの移動なしである。このような解釈を得るために、逆転を粘着性(stiky)にする。例えば、逆転を累積し、所与のバッチのあらゆる非回答イベントの後に再生すると効果的である。
【０１８０】
正確な分散クロック（＋／−数ミリ秒）によって、本システムは各処置のタイム・スタンプを、逆転を含む各品目と共に記録する。本システムは、受信した最後のメッセージよりも新しい処置メッセージを無視し、以前に記載したシーケンスで正しい結果を生成することができる。しかしながら、この方法は常に正しい結果を生成するとは限らない。
例えば、イベント及び対応するタイム・スタンプが次のようになっていると仮定する。
品目Ｘを移動する
タイムスタンプ１：品目Ｘが読み取られ、バッチＢ１の一部として報告される。
品目Ｘが再び移動する
タイムスタンプ２：品目Ｘが読み取られ、バッチＢ２の一部として報告される。
操作者は、品目Ｘの移動が誤りであったと考える
タイムスタンプ３：品目Ｘを逆転する。（バッチ２）
本システムはクラッシュし、あるいは他の何らかのイベントが混乱(scrambling)の原因となり、システムは、
タイムスタンプ２：品目Ｘが読み取られ、バッチＢ２の一部として報告される。
タイムスタンプ３：品目Ｘを逆転する。（バッチＢ２）
タイムスタンプ１：品目Ｘが読み取られ、バッチＢ１の一部として報告される。
を察知する。
【０１８１】
この品目について最後に受信したメッセージよりも新しいメッセージ以外全てを無視するという単純なアルゴリズムは、本システムがバッチＢ１メッセージを無視し、バッチＢ２メッセージは（正しく）無視されることを意味する。しかしながら、本システムは、品目ＸがバッチＢ１の前の状態にあると考えるが、これは誤りである。システム復元中における更に効果的なアルゴリズムは、復元タイム・ウィンドウ以内から得られる全てのメッセージをそのタイム・スタンプでソートし、次いで全てのメッセージを順に処理することである。
【０１８２】
３．６  情報検索のシナリオ(場面)
本システムは、人のレベルのクエリ・インターフェースを提供するために実現することができ、これは連携するシステムによって行うこともでき、あるいは双方で行うこともできる。
クエリの例、及び実現される場所には無関係な、クエリ・インターフェースの機能の一部は、次の通りである。
基本的なクエリは、特定品目はどこにあるか？である。例えば、この特定の薬のビンはどこにあるか？のクエリは、低コストで、従来のクエリ構築技法を用いて容易に実現される。このような技法は、個々の品目を分離するために、品目時間、製造業者等のような限定子の対話型選択を可能にするクエリ構築機構も提供することができる。即ち、ユーザは、実際の品目ＩＤを知らなくてもよく、ある日付けに製造され、ある薬局に出荷された薬品等を特定するように、システムに問い合わせさえすればよい。
【０１８３】
他のクエリには、特定のタイプの品目はどこにあるか？がある。例えば、全てのＤ−セル・バッテリはワールドのどこにあるか？である。多数の製造業者、多数の化学薬品の種別、梱包等によって、Ｄ−セル・バッテリには多数の品目タイプ（ｅＵＰＣ）があり得る。合理的なインターフェースであれば、多数のタイプに跨るクエリの構築を可能にする。
他のクエリには、所与の地域ではどこに品目があるか？、例えば、シアトルから１００マイル以内では、全てのサイズのＤバッテリはどこにあるか？、又は、所与の出荷範囲内では品目はどこにあるか？、例えば、シアトルから４時間以内では全てのサイズＤバッテリはどこにあるか？である。このようなクエリには、最初に異なる地理的位置からシアトルまでの予測出荷遅延の表を作成することによって対応することができる。この複雑に規定された地理では、本システムは、地理表内で品目を探索することができる。
【０１８４】
また、本システムは、所与のプロパティを有する全ての品目はどこにあるか？というようなクエリにも対応することができる。例えば、（現在の日付−製造日付）＞２年の全ての薬品瓶はどこにあるか？、２０００年１月１日から２００１年１月１日までの間にFirestoneが製造した全てのラジアル・タイヤはどこにあるか？、小売店の場所に転送させる前に、サイズＤのバッテリはどのくらいの期間保管室にあったか？、サイズＤのバッテリは、販売されるまで、どの暗いの期間小売店の陳列棚の上にあったか？、である。
本システムは、種々の統計的選択肢を提供するように実現することができ、例えば、平均、標準偏差、分散、最少、及び最大地の計算を行うことができる。したがって、本システムは、位置Ｘと位置Ｙとの間の平均出荷時間はどれくらいか？というようなクエリに対応することができる。例えば、Acme社が製造した製品をシカゴからシアトルに出荷するには、どれくらいかかるか？というクエリに対応することができる。
【０１８５】
上級クエリに対する実現戦略
互いに通信するＩＴＳ実施態様の連合及び、地空間アプリケーションを含む追加のアプリケーション・ソフトウェアからなるシステム全体は、受動型タグの単純な走査から収集されるデータを用い、動的に品目の位置を予測し、複雑なクエリに回答することができる。このようなクエリは、本発明以外では、品目毎に遥かに高価な位置追跡技術が必要となろう。
上級クエリの例には、通常の出荷方法を用いて４時間以内にシアトルに出荷することができるDuracellバッテリはどこにあるか？、コロラドを通る全ての道路が閉鎖されている。どの出荷品が影響を受ける可能性があるか？、挽き肉の全出荷品の現在予測位置はどこか？が含まれる。
【０１８６】
出荷遅延に関するクエリ
本システムは、いつ出荷品がトラックに装荷されるか、出荷品の宛先、そして宛先における出荷品の積み降ろしはいつ完了するか、把握している。したがって、本システムは、システム内に現れる開始位置及び終了位置の各対毎に、この情報を記録し集めることができる。このデータの蓄積によって、本システムは、出荷時間の統計、例えば、平均、モード、標準偏差、最大、最少等を計算することが可能となる。したがって、通常の出荷方法を用いれば４時間以内にシアトルに出荷できるDuracellバッテリはどこにあるか？というような、時間に基づくクエリも可能である。
【０１８７】
集荷遅延クエリに応答するには、いくつかの方法が可能である。例えば、第１の方法では、ステップは次の通りである。（１）Duracellバッテリに対応する全ての品目タイプを特定する。（２）品目タイプに基づいて、ある最大地理的領域（例えば、カナダ、アメリカ合衆国）内で、入手可能なバッテリの在庫を有するDuracellバッテリの全貯蔵場所を特定する。（３）過去にDuracellバッテリを受け取った、シアトルの統計的区域内にある全ての宛先を特定する。この動作は、シアトル、バッテリ品目タイプ、及び蓄積した履歴に基づく、単純な地理的探索である。（４）ステップ３からの宛先のリストに基づいて、これらの宛先での全ての平均出荷時間入力を求める。各出荷遅延毎に出発位置に注意すること。（５）ステップ４における出発位置の、ステップ２からの入手可能な在庫場所との交点を求める。（６）遅延に基づいて、ステップ５において特定した出発位置／宛先位置／平均遅延記録をソートする。平均遅延が４時間以下という基準を満たすものを選択する。（７）ステップ６は、クエリに対する回答を与えた。得られた場所は、マップ上に示すことができる。（８）出荷コストのようなその他の情報も、選択を絞るために利用できるので、例えば、本システムは、出荷コストが低い順に、可能な供給源を戻す。
【０１８８】
この方法は、過去においてシアトルに出荷するために用いられた出発位置のみを考慮する。探索は、出荷の履歴に関するセグメントの組み合わせを検査するように拡張することもでき、この場合、セグメントの和の全予測遅延が、ある許容度の範囲内で、所与の目標を超過しない。
前述の方法は、出荷時間とは無関係に、シアトルの最も安価なバッテリの供給源を見つけるように、容易に変更することができる。
【０１８９】
第１の方法は、出荷の遅延、及び可能な商品の供給源を、バッテリの出荷履歴に基づいて特定する。第２の方法は、市販の経路計画ソフトウェア及びサービスを用いる。これらの解法は既に受け入れられており、米国又はその他の国におけるいずれか２カ所間の最適な経路及び運転（又はその他の輸送）時間を推定する。この技術を基準として用いると、以下のステップを用いてクエリに回答することができる。（１）Duracellバッテリに対応する全ての品目タイプを特定する。（２）品目タイプに基づいて、ある最大地理的領域（例えば、カナダ、アメリカ合衆国）内で、入手可能なバッテリの在庫を有するDuracellバッテリの全貯蔵場所を特定する。（３）経路計画ソフトウェアを用いて、バッテリの在庫がある各場所からシアトルまでの運転時間の表を作成する。（４）表をソートし、シアトルからの運転時間が４時間以内にある保管場所を特定する。
第２の手法は、可能であるが、実際には頻繁に用いられていない出荷経路を特定する。例えば、税金及びその他の理由で、Duracellはカナダから米国には決してバッテリを出荷しないことが考えられる。前述の方法は、シアトルからの最も早いバッテリ供給源はバンクーバーであることを示すことができる。次いで、この供給源を用いるか否かは、業務上の判断となる。
【０１９０】
出荷中断クエリ
本システムは、全ての現出荷品の供給源及び宛先を把握している。また、本システムは、出発位置及び終点位置の各対毎に、各出荷の開始時間及び平均配達時間も把握している。したがって、コロラド州を抜ける全ての道路が閉鎖されている。どの出荷品が影響を受けるか？といようなクエリに応答することができる。
【０１９１】
出荷中断クエリに応答するには可能な方法がいくつかある。例えば、図２１を用いて例示した第１の方法では、ステップを次のようにすることができる。（１）移動中断の地理的領域、例えば、コロラド州を特定する。その領域を矩形２１１０で近似する。（２）現在の全出荷品、及び対象の時間期間に計画されているものを特定する。（３）各出荷毎に、次のステップを実行する。（ａ）出発位置２１３０及び終点位置２１４０の境界枠(bounding box)を形成する。（ｂ）境界枠が交差又は重複するか否か判定する。（ｃ）これらがどうしても交差する場合、中断の潜在的可能性があると見なされる。以下で説明するが、交差がない場合でも、例えば、高速道路、山、水路等によっては、中断があり得る。以下を参照のこと。
【０１９２】
この方法は、潜在的な中断の基本的かつ概略的な指示を与える。更に具体的な指示を形成するには、出発位置から終点位置までの直線経路７３０を見ればよい。移動の中断がこの線と交差する場合、潜在的な中断の指示が一層強くなる。
図２２を用いて示す更に正確な第２の方法では、輸送経路の観念がある。
第２の方法では、第１の方法のステップ１から５までを用いて、移動の中断８１０が特定の出荷品に影響を及ぼす可能性があるか否かを示す。境界枠が移動の中断と交差する場合、計画した輸送経路の詳細を、例えば、路点２２２０を検討することによって検査する。計画経路が移動中断矩形と交差する場合、中断の潜在的可能性はかなり高い。この図は、移動の中断が直線経路を封鎖することを示すが、実際には計画経路８１０を封鎖しない。
【０１９３】
図２３を用いて示す第３の方法では、更に詳しい経路を得ることができる。このような経路は、各経路の詳細を直接入力することによって、道路名によって、又は経路計画ソフトウェアを用いることによって、得ることができる。このような詳細情報は、確定している道路上での車両輸送に対する中断の一層正確な検出を可能にする。そのステップは、次の通りである。（１）高速道路又は封鎖される道路区間に関して移動中断２３１０を定義する。（２）時間枠内にある全ての出荷品のための全輸送経路２３２０を見つけ出す。（３）移動中断道路区間を、計画経路と照合する。これらが一致した場合、指示された経路は中断されている。
【０１９４】
リアル・タイム位置探索表現及びクエリ
リアル・タイム位置サーチ（探索）システム（ＲＴＬＳ）は、オブジェクトの連続的追跡を行うことができる。このような追跡は、通常、トランスポンダを用いて行われるが、トランスポンダは高価な場合もある。本システムは、安価な受動型ＲＦＩＤタグを担持するタグを採用し、ＲＴＬＳの適切な機能を与えることができる。
つまり、位置探索クエリには２つの基本的手法がある。第１の手法では、輸送システム（例えば、トラック、船舶、飛行機）がＲＴＬＳを有する。全ての輸送機関のリアル・タイム位置探索を監視し、本システムは、特定の品目から輸送機関に、したがって位置に関連付ける。第２の手法では、固定位置において受動型タグから読み取ることによって収集した情報、及び計画出荷に関する情報を用いて、品目の現在位置を近似する。この手法は、遥かに安価であり、ＲＴＬＳのインフラストラクチャを全く必要とせずに、輸送ＲＴＬＳ手法の利点の多くが得られる。また、これは、第三者の運搬業者(carrier)と共に動作することも可能である。
【０１９５】
輸送機関にＲＴＬＳ機能がある場合、公式の出荷プロセスは出荷を輸送モードと関連付ける。ＲＴＬＳ型タグを有するトラックのように、輸送機関自体がタグ付きオブジェクトである場合、本システムは、最新のＲＴＬＳ更新の時点に、正確な出荷の位置を知る。
位置探索クエリの一例は、挽き肉の全出荷品の推定現在地を示せ、である。ＲＴＬＳ方法は、これらのステップに従う。（１）所望の挽き肉出荷品の品目タイプを調べる。（２）この品目タイプの現在の全出荷品を見つけ出す。（３）各出荷品と関連付けられている輸送車両を特定する。（４）タグの最新ＲＴＬＳ更新を見つけることによって、タグ付きオブジェクトである輸送機関の位置を見つけ出す。（５）例えば、緯度及び経度に基づいて、現在地をグラフィックで示す。
【０１９６】
ＲＴＬＳ機能がないと、本システムは、いつ出荷品をトラックに装荷するか、出荷品の宛先、及び宛先における出荷品の荷降ろしがいつ完了するかを知る。したがって、本システムは、当該システム内に現れる出発位置及び終点位置の各対毎に、この情報を記録し、集めることができる。次いで、本システムは、平均の出荷時間を計算することができる。この情報によって、システムは、出荷の現在位置を、任意に信頼範囲と共に、推定することが可能となる。
この方法は、サンプル・クエリ（挽き肉の全出荷品の推定現在地を示す）に、次のように対応する。（１）所望の挽き肉出荷品の品目タイプを調べる。（２）以前の履歴に基づいて、これらの出荷品の平均出荷時間を求める。（３）この品目タイプの全ての現出荷品を見つけ出す。（３）出荷品毎に、記録されている開始時間及び現在の時刻と平均配達時間との間の差を比較する。この量は、完了している行程の割合を推定する。
【０１９７】
現在地は、いくつかの異なる方法で推定し表示することができる。
図２４を用いて示す直線方法では、配達行程全体を、出発位置から終点位置までの直接直線経路によって近似する。完了行程の推定割合２４１０を計算し、直線経路を想定することによって、出荷品の位置２４２０を推定することができる。この方法は、実世界の道路や高速道路には対応しないが、宛先に対する商品の位置について、容認可能な近似を与える。
【０１９８】
図２５を用いて示す別の手法では、先に論じたように、出荷品毎に詳細な経路を構築する。この手法は、例えば、経路区間２５１０〜２５１８の詳細なシーケンスを与えることができ、これを地図上で強調することができる。経路計画ソフトウェアは、経路上のいずれの所与の地点までの移動時間でも推定することができる。例えば、図２５では、各インターチェンジ地点までの推定運転時間を推定し、図示している。実際の出発時刻の知識に基づいて、本システムは、特定の道路上での特定の位置のレベルで、配達車両の現在地を推定することができる。この手法は、橋の閉鎖のように、わかっている輸送の中断の影響を判定する際に、特に有用である。
【０１９９】
４．品目追跡システムとタグ・リーダとの間のデータ転送
以下の節では、タグ・リーダとＩＴＳとの間にハードウェア及びソフトウェアが介入する、本システムの実施態様について説明する。あるいは、介入するハードウェア及びソフトウェアの機能性を、例えば、図１に示すＯＩＣ１０４の一部として、ＩＴＳに統合することもできる。
【０２００】
４．１  イベント・ルータ
本システムの一実施態様は、１つ以上のルータを用いて、ＩＴＳ及びタグ・リーダ間で情報を転送する。イベントは、ソフトウェア・エンティティ間で受け渡されるメッセージである。イベントを用いると、当該イベントの受信側にある事件を通知したり、要求を受信側に送ることができる。イベント・ルータは、種々のエンティティ間でイベントを分配するために用いることができる。適したイベント・ルータの例には、カリフォルニア州Mountain ViewのKnowNow Incorporatedから入手可能な、トピックに基づくKnowNow（登録商標）イベント・ルータ、又はオーストラリア国、QueenslandのDistributed Systems Technology Centerから入手可能な、コンテンツに基づくElvinメッセージング・サービスが含まれる。トピックに基づくイベント・ルータ及びコンテンツに基づくイベント・ルータを組み合わせて用いることもできる。
例示の目的で、特定の場面、在庫管理の場面における使用に関して、本発明を説明する。
【０２０１】
図３６は、在庫管理システムの一部として用いられる品目追跡システム（ＩＴＳ）に関する小売位置を示す。小売位置は店舗である。この店舗は、タグ付品目を含む在庫品目録を有する。タグ付品目が店舗内に持ち込まれたり、あるいは持ち出されると、これは位置監視システム３６１０によって検出される。
監視システム３６１０は、店舗内の１つ以上の位置に配置された多数のタグ・リーダを含む。また、監視システム３６１０は、在庫品目録内の各品目の現状態を格納するメモリも含む。状態は、品目が所与の位置に存在するか、又はその位置から持ち出されたかを示す。また、監視システム３６１０は、コンピュータ・ロジックも含み、いつ品目の状態が変化したか、例えば、いつ品目が所与の位置に追加されたか、又はそこから持ち出されたかを判定する。
【０２０２】
ロジックは、更に、品目の状態に変化を検出したときにはいつでも更新を送るように構成することができる。在庫品目録の更新は、品目のｅＰＣ、タグ・リーダのｅＰＣ、及びタイム・スタンプを含むイベントの形式を取ることができる。また、イベントは、変化が品目の追加か又は削除かを指定するIN/OUTパラメータも含むことができる。
一実施態様では、監視システム３６１０は、１つ以上のスマート陳列棚を含む。スマート陳列棚とは、物理的品目が当該陳列棚に追加されたり、そこから削除されたときに報告することができる陳列棚のことである。スマート陳列棚は、当該陳列棚上の１つ以上の位置に配置された多数のタグ・リーダを含む。また、スマート陳列棚は、品目が在庫品目録に追加されたのか、又はそこから削除されたのか判定を行うコンピュータ・ロジックを含む。
ＩＴＳ３６２０は、店舗の在庫品目録に掲載されている品目を含む多数の品目について追跡情報を保持する。品目が店舗に入ったとき、又は店舗から出たときにはいつでも、ＩＴＳは監視システム３６１０からイベントを受信し、そのデータ・ストレージを更新し、イベントを反映する。
【０２０３】
在庫プランナ３６４０−コンピュータ・プログラム解決手段−は、通常、周期的なスケジュールで動作し、在庫管理機能を実行する。店舗に関係する動作では、在庫プランナ３６４０は、ＩＴＳ３６２０から在庫データを検索し、店舗の在庫品を補充するか否か判定を行う。在庫プランナ３６４０は、早期警報エージェント（ＥＷＡ）３６３０から警告を受信することができ、早期警報エージェントは、在庫プランナに、その通常の周期的スケジュール以外に、少なくとも店舗に関係して、少なくとも在庫管理機能の一部を実行させることができる。即ち、ＥＷＡ３６３０は、在庫プランナ３６４０に警告を送り、在庫プランナに、店舗の在庫品の補充が必要か否か判定させることができる。品目が店舗に入るとき、及び店舗から出るときにはいつでも、そして任意に、これらが店舗のある部分から他の部分に移る場合にも、ＥＷＡは監視システム３６１０からイベントを受信する。このようなイベントにおいて受信した情報を用いて、ＥＷＡは在庫プランナ３６４０に警告を送るときを決定する。
【０２０４】
早期警報エージェント
ＥＷＡ３６３０は、警告を送るときを決定するロジックを含む。警告を送るか否かの判定は、１つ以上のルールを、在庫更新において受信した情報に適用することを含む。ルールは、ある状態、及びこの状態を満たしたときに実行するある行為を指定する。例えば、ルールは、在庫レベルが特定の値よりも低下したときにはいつでも警告を送るように指定することができる。
ＥＷＡ３６３０は、所定の１組のルールを適用することができ、あるいは、ＥＷＡ３６３０は、人工知能ロジックを含むことができ、ＥＷＡ３６３０にその挙動を、現在庫又は過去からの在庫パターンに応答して適合させることができる。人工知能ロジックによって、ＥＷＡは、近未来における在庫レベルの潜在的なばらつきを推定し、十分早期に潜在的に危険な状況を特定し、補正処置を講ずるようにすることができる。例えば、初期状態において、ルールは、在庫が１０を割ったときに、警報を発するように指定することができる。しかしながら、ＥＷＡ３６３０が、夏の季節中には他の季節中よりも遥かに頻繁に警報を送ることを検出すると、ＥＷＡ３６３０は、夏の季節の間閾値を１０から２０に増加させ、在庫プランナ３６４０に差し迫った在庫不足を早めに通知することによって、この季節変動に適合化することができる。この適応挙動は、人的介入を最少に抑えて、更にパラメータの調節やその他のあらゆる種類の手作業の較正の必要性も最少に抑えて行われる。
【０２０５】
ＥＷＡ３６３０は、現在及び過去の在庫データを検索し分析して、補充計画と実際の補充との間のずれというような傾向を検出し、今後の在庫の必要性について予測モデルを構築する。これらの傾向及び予測は、線形回帰、分類、回帰ツリー、又はその他の確率的アルゴリズムを用いて決定することができる。
一実施形態では、ＥＷＡ３６３０は、各補充計画、又は在庫に影響を及ぼし得る消費活動の潜在的変動を推定する（例えば、過去の移籍データから、Bob's Bottlesからの１２ｏｚ瓶の計画トラック積荷が、計画配達時刻後の６時間より前の４時間以内のいずれかの時刻に到着することを推定する。量は、要求量の９５％及び１００％の間である）。ＥＷＡ３６０は、過去に配達した在庫の種々の量に対する約束した配達時刻と実際の配達時刻とを比較して、計画したが未だ完了していない今後の補充活動のための実際の配達日及び量の予測を生成する。ＥＷＡ３６３０は、いくつかの個々の活動についての潜在的ばらつきの推定値を纏めて、在庫全体についての潜在的な変動の推定値を求める。これらのアルゴリズムは、分類や回帰ツリーのような判断ツリーを用いて実現することができる。
【０２０６】
別の実施態様では、個々の活動を考慮する代わりに、ＥＷＡ３６３０が補充及び消費の蓄積レベルを表す集計データに基づいて、予測モデルを構築する。これらのアルゴリズムは、条件付きガウス近似のような確率的推論モデルを用いて実現することができる。
ＥＷＡ３６３０が用いるアルゴリズムに関するこれ以上の詳細は、２００２年５月３１日に出願され、同時継続中の"Inventory Early Warning Agent"（在庫早期警報エージェント）と題する同時係属中の米国予備特許出願第６０／３８４，６３８号において見出すことができる。その内容は、ここで引用したことにより本願にも含まれることとする。
【０２０７】
在庫プランナ
在庫プランナ３６４０は、在庫補充計画を生成するアプリケーションであればいずれでも可能である。このような在庫プランナ３６４０の１つに、ＳＡＰ  ＡＧから入手可能なAdvanced Planner and Optimizer（ＡＰＯ）がある。
在庫プランナ３６４０は、補充計画を生成するロジックを含む。このロジックは、ウェア３６３０から警報を受信し、この警報に応答して補充が必要か否か判断する。
一実施形態では、在庫プランナ３６４０は、在庫全体について補充プランを生成する。ＥＷＡ３６３０は、在庫の一部を監視する。多数のＥＷＡ３６３０を組み合わせれば、在庫全体をカバーすることができる。在庫の一部分に関する警報が、在庫プランナ３６４０に、在庫全体について計画した補充を計画し直さなければならないか否かについての判断を行わせるきっかけとなる。
【０２０８】
この判断は、ＩＴＳ３６２０から在庫データを検索し、検索した在庫データに基づいて受容を判断又は予測することを含むことができる。例えば、製品Ｘに対する高い需要の傾向があれば、在庫プランナ３６４０に、製品Ｘだけでなく製品Ｙも増やすように計画させる。製品Ｙは、製品Ｘがその先行指標であることが知られている製品である。
図３７に示すように、イベント・ルータ（ＥＲ）３７１０のようなイベント・ルーティング・ミドルウェアを用いると、種々のエンティティ間、例えば、監視システム３６１０、ＩＴＳ３６２０、ＥＷＡ３６３０、及び在庫プランナ３６４０間でイベントを分散することができる。適したイベント・ルータの例には、カリフォルニア州、Mountain ViewのKnowNow Incorporatedから入手可能な、トピックに基づくKnowNow（登録商標）イベント・ルータ、又はオーストラリア国、QueenslandのDistributed Systems Technology Centerから入手可能な、コンテンツに基づくElvinメッセージング・サービスが含まれる。トピックに基づくイベント・ルータ及びコンテンツに基づくイベント・ルータを組み合わせて用いることもできる。
【０２０９】
コンテンツに基づくイベント転送
位置実施態様では、各メッセージの内容に基づいて、発行元から加入者にメッセージを転送する。各メッセージの内容は、多数のコンテンツ・フィールドに区分することができる。例えば、ｅＰＣを有する品目に関するメッセージ、01.0037F2.001508.000319F827は、次のコンテンツ・フィールドに分割することができる。
（１）ヘッダ：    01
（２）製造業者：  0037F2
（３）製品クラス：001508
（４）連番：      000319F827
（５）メッセージ・タイプ：seen@, request, response    seen@メッセージは、特定の場所で品目が検出されたことを報告するメッセージである。「要求」メッセージが、要求を加入者(subscriber)に送るために用いられ、「応答」メッセージが、要求された情報を公開するために用いられる。他のメッセージ・タイプも定義することができる。
加入者は、コンテンツ・フィールドの値に基づいて、メッセージ・フィルタを指定することができる。
（例えば、製造業者＝0037F2 & メッセージ・タイプ＝seen@）
【０２１０】
トピックに基づくイベント転送
代替実施態様では、トピックに応じてイベントを分類する。ソフトウェア・エンティティは、あるトピックに関連するイベントにしか関心がない場合がある。ソフトウェア・エンティティは、あるトピックのみに加入することができ、これらのトピックに関するイベントのみを受信し、他のトピックを受信しない。
【０２１１】
図３８は、ｅＰＣの構造に基づいたトピックの構造を示す。ｅＰＣのデータ・フィールドの各々、即ち、製造業者、製品クラス、及び連番について、別個のトピックを作成することができる。例えば、ｅＰＣを有する品目01.0037F2.001508.000319f827では、以下のトピックを作成することができる。
（１）＼centauri＼0037F2＼001508＼000319F827＼see@−−このトピックは、品目に関する「seen@」イベントをカバーする。
（２）＼centauri＼0037F2＼001508＼000319F827＼*−−このトピックは、トピック１に報告するイベントと、「要求」や「応答」イベントのような、品目に関する他のタイプのイベントとの双方を含む。
（３）＼centauri＼0037F2＼001508＼*−−このトピックは、トピック２に報告するイベントと、同じ製品クラス001508内の別の品目に関するイベントとの双方を含む。
（４）＼centauri＼0037F2＼*−−このトピックは、トピック３に報告する全てのイベントと、同じ製造業者0037F2を有する別の品目に関するイベントを含む。
【０２１２】
リーダに関するイベントについて、別個のトピックを作成することもできる。例えば、ePC 01.0B39C2.000815.004711F827を有するリーダには、以下のトピックを作成することができる。
（１）centauri＼oB39C2000815004711F827＼Have-Seen-ePC−−このトピックは、特定のｅＰＣを検出した特定のリーダに関するイベントをカバーする。
（２）centauri＼oB39C2000815004711F827＼*−−このトピックは、いずれかのｅＰＣを検出した特定のリーダに関するイベントをカバーする。
【０２１３】
トピックに基づくイベント・ルータは、トピック集合を有し、各トピックはアドレス、例えば、ＵＲＬを有する。イベントをトピックのアドレスに送ることにより、当該イベントをそのトピックに発行することができる。イベントを発行する適切なトピックのＵＲＬを決定するために、監視システム３６１０（図３７）のような発行エンティティは、拡張オブジェクト命名サービス（ＥＯＮＳ）３７２０を参照することができる。ＥＯＮＳ３７２９は、品目ｅＰＣ（又はリーダｅＰＣ）と１つ以上のＥＲとの間のマッピングを、その対応するトピックと共に保持している。ＥＯＮＳは、入力として品目（又はリーダ）のｅＰＣを取り込み、１つ以上の特定したトピックに対してＵＲＬ（複数のＵＲＬ）を戻す。ＥＯＮＳ２２０は、Oat Systems 及びMIT Auto-ID Centerによって開発されたＯＮＳのような従来のＯＮＳを拡張することによって実現することができる。これについては、Object Name Service Technical Manal（MIT Auto-ID Center 発行）に更に詳しく記載されている。従来のオブジェクト命名システムは、周知のインターネット用ドメイン・ネーム・システム（ＤＮＳ）に似ており、これに基づいている。
【０２１４】
発行のためのプロトコル・フロー
図３９に示すように、監視システム３６１０は、品目が在庫に追加されたこと、又は在庫から削除されたことを識別する。監視システム３６１０は、タグ識別子、リーダ識別子、及びタイム・スタンプを含むイベントを生成する。タグ・識別子は、変更した品目を特定する。リーダ識別子は、変化を検出したリーダを特定する。そして、タイムス・タンプは、変化を検出したときを特定する。
次いで、監視システム３６１０は、ＥＯＮＳ３７２０を参照して、イベントを送る先を決定する。監視システム３６１０は、ＥＯＮＳに、品目のｅＰＣ及びリーダのｅＰＣを供給し、逆にＥＯＮＳから、品目トピック及びリーダ・トピックのＵＲＬを受け取る。次に、監視システム３６１０は、イベントを両トピックに送る。
【０２１５】
品目トピック及びリーダ・トピックのＥＲ（１又は複数のＥＲ）は、イベントを１人以上の加入者に転送する。例えば、ＩＴＳは、品目トピックの加入者である可能性があり、ＥＷＡはリーダ・トピックの加入者である可能性がある。ＥＷＡは、ＥＲからイベントを受け取り、警報を在庫プランナに送るか否か判定を行う。
警報を送る場合、これが在庫プランナに在庫の補充を計画しなおさせるきっかけとなる。在庫品目録の現データを取得するために、在庫プランナはイベントを、在庫データを要求するＥＲに送ることができる。すると、ＥＲは、イベントをＩＴＳに転送し、要求された在庫データを在庫プランナに送ることによって応答する。
【０２１６】
加入のためのプロトコル・フロー
図４０に示すように、加入者が加入したいトピック毎に、加入者は最初にＥＯＮを参照して、所与のトピックに対するＥＲのアドレスを決定し、次いでトピックに発行されるイベントを待つ。
イベントを受信すると、加入者は、イベントに含まれるリーダ識別子を用いて、品目の位置を判定することができる。位置は、物理的位置（例えば、特定の経度、緯度及び高度）、又は論理的位置（例えば、コンテナＸＹＺの内側又はトラックＡＢＣ）でも可能である。また、加入者は、タグ識別子を用いて、品目についての追加情報の位置を探すこともできる。例えば、タグ識別子を用いて、品目のＰＭＬ（製品マークアップ言語）文書を検索することができる。
【０２１７】
図４１に示すように、ＥＯＮＳは、多数のタグ付品目（又はリーダ）と多数のＥＲとの間のマッピングを保持することができる。先に論じたように、マッピングは、品目キー及びリーダ・キーを含む多数のキーに対応する。ＥＯＮＳは、多数の監視システム３６１０、及びその他のタグ・リーダ・アプリケーションに仕える(service)ことができる。一実施態様では、ＥＯＮＳは、分散型サブシステムであり、マッピング情報、情報の位置を要求するクエリに応答するクエリ・サーバ、及びｅＰＣを受けて、ｅＰＣをＥＲ位置に分解するネーム・リゾルバ(name resolver)を含む。
図４２に示すように、特定のＥＲが多数のＩＴＳ（及びその他の加入者）に分散することができ、特定のＩＴＳが多数のＥＲに加入することができる。ユーザは、ＩＴＳ毎に所望の範囲を定義し、それに応じて分散方式を構成することができる。
【０２１８】
４．２  統合エンジン
図３１に示すように、本システムの一実施態様は、統合エンジン３１１０を用いることができ、統合エンジン３１１０は、ＩＴＳ及びタグ・リーダの仲介物として作用する。統合エンジン３１１０は、リーダとＩＴＳとの間の仲介ソフトウェア及びハードウェアとして実現することができる。あるいは、統合エンジン３１１０は、ＩＴＳに、例えば、図１のＯＩＣ１０４の一部として統合することができる。
【０２１９】
統合エンジン３１１０は、タグ・リーダ１０２及びその他のタイプのスマート品目と通信することができる。本明細書では、「スマート品目」とは、それ自体のデータを格納し、これを外部システムに伝達できる品目又は機械のことである。いずれの通信チャネル（例えば、無線周波数、赤外線）でも用いることができる。通信プロセスは、スマート品目内に格納されているデータの変化を招く可能性がある。更に洗練されたスマート品目も処理機能を有し、直接他のスマート品目と双方向処理を行い、例えば、共通の挙動について取り決めることができる。スマート品目は、一意の品目識別子（ＵＩＤ）及び品目のその他の品目属性を含む、異なるタイプのデータを格納し、伝達することができる。一部はセンサを有し、温度、湿度、加速度、又は位置のような環境データを記録することができる。伝達されるデータは、リアル・タイム・データ又は過去のデータ、あるいは双方とすることができる。
【０２２０】
スマート品目の例には、タグ対品目、ＲＦＩＤインテロゲータ、アクチュエータ・デバイス、認識商品(aware good)、及び埋め込みインターネット装置が含まれる。アクチュエータ・デバイスとは、何か（例えば、コンベア・ベルト、自動販売機）を動かし制御する機械のことである。認識商品とは、その環境に関する情報を検出できる商品（例えば、位置又は温度センサを装着した商品）のことである。
所与のセンサ又はアクチュエータ・デバイスに対する対応は、図３４に示すハードウェア・インターフェースの一例のような、ハードウェア・インターフェースを用いて実現される。統合エンジン３１１０は、異なるタイプのスマート品目３１２０からデータを収集し、収集したデータを、ＩＴＳ１０３を含む上位アプリケーション３１３０に供給する。また、統合エンジン３１１０は、データをスマート品目３１２０に書き込むこともできる。
【０２２１】
統合エンジン
統合エンジン３１１０は、種々のスマート品目３１２０からのデータの読み書きを行い、データを処理し、処理したデータをリアル・タイムで上位アプリケーション３１３０に供給する。このようにリアル・タイムで行うことは、データを受信したときに処理し、処理したときに供給することを意味する。また、統合エンジン３１１０は、上位アプリケーション３１３０からデータを受け取り、そのデータをスマート品目３１２０に書き込むこともできる。
データの処理は、データのフィルタ処理を含むことができる。例えば、１つのアプリケーションは、ＵＩＤ及び位置データを受信することにしか関心がなく、他のアプリケーションは、あるスマート品目からデータを収集することにしか関心がないという場合があり得る。データを要求するアプリケーション毎に、別個のフィルタを設けることができる。
【０２２２】
また、データの処理は、データの合算も含むことができる。データの合算では、データを互いに組み合わせて、上位データを生成する。例えば、トラック内に位置する品目のＵＩＤを、トラックからの温度読み取り値と組み合わせ、当該品目の温度読み取り値を生成する。データの合算によって、データを個々に扱うよりも、データを一層有意義にすることができる。また、合算によって、リアル・タイム・データを蓄積してバッチにし、リアル・タイムの代わりに、バッチ・データを、予め規定した間隔で送ることも可能となる。データには、収集の日時を用いて、タイム・スタンプを付けることができる。
統合エンジン３１１０は、基本的な読み取り及び書き込み機能性を備えた異なる種類のハードウェア・インターフェースとインターフェースするように構成されている。統合エンジン３１１０は、ハードウェア特定データ・フォーマットと汎用フォーマット、即ち、ある場合にはアプリケーション特定フォーマットとの間で変換を行う。このように、統合エンジン３１０は、アプリケーション３１３０からハードウェア特定性を秘匿する。
【０２２３】
図３２は、どのようにして多数の統合エンジン３１１０を用いて多数のスマート品目を管理することができるかを示す。各統合エンジン３１１０は、スマート品目がある特定の位置（例えば、工場、積み降ろしホーム、店舗）にデータを転送し、ここからデータを転送されるように割り当てることができる。アプリケーション３１３０は、１つ以上の統合エンジン３１１０に加入することができる。各統合エンジン３１１０は、ネスト状にした多数の統合エンジン３１１０として実現することができる。１つの統合エンジン３１１０の出力が、上位の統合エンジン３１１０への入力となることができる。
【０２２４】
図３３は、統合エンジン３１１０の実施態様の一例を示す。統合エンジン３１１０は、スマート品目との双方向処理に伴う全ての資源及びオブジェクトを管理し、プロセス全体を制御する。統合エンジン３１１０は、制御マネージャ３３１０、インテロゲータ・エージェント３３２０、処理エージェント３３３０、及び通信エージェント３３４０を含む。コンポーネントは、Ｊａｖａ（登録商標）、Ｃ＃、又はＣ＋＋オブジェクトのような、コンポーネントに基づく技術を含む従来のプログラミング技術を用いて実現することができる。
制御マネージャ３３１０は、統合エンジン３１１０とアプリケーション３１３０との間にプログラミング・インターフェースを提供する。プログラミング・インターフェースは、汎用（実施態様に特化しない）通信インターフェースを実現し、これには種々のアダプタをプラグインすることができる。アダプタは、特定の通信インターフェース（例えば、ＲＰＣ、ＣＯＭ、ＣＯＲＢＡ、ＪＭＳ、ＨＴＴＰ）と汎用通信インターフェースとの間で変換を行う。
【０２２５】
制御マネージャ３３１０は、アプリケーション３１３０からルールを受け取り、このルールを解釈し、クライアント・コマンドを受け取り、クライアント・コマンドを解釈し、該当するインテロゲータ・エージェント、処理エージェント、及び通信エージェントをインスタンス化して、ルールを実行する。ルールは、インテロゲータ・エージェント、処理エージェント、及び通信エージェントの挙動の種々の面を規定又は制約することができる。例えば、ルールは、どのデータをアプリケーションに供給するか（例えば、それがＵＩＤ又は位置データの場合、データのみを供給する）、どのデータをハードウェアに書き込むか（例えば、トラックの温度が所定の閾値未満に低下した場合、エアコンをオフにするコマンドを書き込む）、又は、いつデータを書き込むか（例えば、１日１回）について規定することができる。また、ルールは、どのように収集したデータを組み合わせて上位データを生成するか（例えば、トラック内に位置する品目のＵＩＤを、トラックの温度と組み合わせ、品目が過熱状態にないか否か判定する）についても規定することができる。制御マネージャ３１０は、データを受ける毎に、ルールを解釈し適用する。
【０２２６】
一実施態様では、制御マネージャ３３１０は、アプリケーションから受けたルールを格納するルール・レポジトリと、格納したルールを実行するルール・エンジンとを内蔵するか、又は何らかの方法でこれらに結合されている。アプリケーションから受けたルールは、ＵＭＬ（統一モデリング言語）モデル、ＥＢＪ（企業用Java（登録商標）Beans）ビーンズ、又はＸＭＬ（拡張可能マークアップ言語）文書として表すことができる。必要であれば、制御マネージャ３１０はルールを、ルール・エンジンによって用いられる内部フォーマットに変換する。
【０２２７】
インテロゲータ・エージェント３３２０は、ＲＦＩＤコントローラ・インターフェースのような単一のハードウェア・デバイス・インターフェース全体の制御を担当する。インテロゲータ・エージェント３３２０は、ハードウェア・インターフェース、制御マネージャ３３１０、及び処理エージェント３３３０とインターフェースする。インテロゲータ・エージェント３３２０は、ハードウェア・インターフェースからデータを受ける。インテロゲータ・エージェント３３２０は、ハードウェア・インターフェースの要件にしたがって構成することができる。例えば、あるハードウェア・インターフェースは同期ポーリングを必要とし、一方別のインターフェースはイベント又は割り込みを発生する。インテロゲータ・エージェント３３２０は、一般に、収集したデータの処理は全く行わず、代わりに、単に処理エージェント３３３０にデータを転送し処理させるだけである。
【０２２８】
処理エージェント３３３０は、データのフィルタ処理、合算、及び変換動作を担当する。処理エージェント３３３０は、制御マネージャ３３１０及びインテロゲータ・エージェント３３２０と双方向処理を行う。
データのフィルタ処理を実行する際、処理エージェント３３３０は、１つ以上のインテロゲータ・エージェントが収集したセンサ・データを受ける。処理エージェント３３３０は、ルール・エンジンを呼び出し、データのいずれかが、ルールによって指定された条件を満たすか否か判定を行う。条件を満たさないデータはいずれも転送されない。条件を満たすデータは、通信エージェント３３４０に転送される。
【０２２９】
データ合算を実行する際、処理エージェント３３３０は、所与のルールが要求する全データを受けるまで、受け取ったデータをバッファに格納しておく。
処理エージェント３３３０は、ハードウェア特定フォーマットでデータを受ける。処理エージェント３３３０は、マッピング表を用いて、ハードウェア特定フォーマットと、統合エンジン３１１０がアプリケーション３１３０に出力する汎用フォーマットとの間の変換を行う。
【０２３０】
データ・ロードは、多数の処理エンジン間で共有することができる。ある処理エージェント３３３０は、例えば、購入発注番号のようなある種の情報を含むデータのみを処理してもよい。このような場合、インテロゲータ・エージェント３３２０は、ハードウェアの種別（例えば、バー・コード・スキャナはバー・コード情報を発信する）、又はデータを記述するメタデータ（例えば、図３４を参照して説明した論理タグ・タイプに規定されているような）のいずれかに基づいて収集した情報のタイプを判定する。ある処理エージェント３３３０は、複雑なデータ、数個の処理エージェント３３３０の出力から合算したデータを処理してもよい。１つ又は複数の同じ処理エージェント３３３０が、同じタイプのデータを要求するアプリケーションを担当することができる。
【０２３１】
通信エージェント３３４０は、プッシュ・モデル又はプル・モデルのいずれかを用いて、アプリケーション３１３０にデータを供給することを担当する。アプリケーションは、明示的にスマート品目３１２０上でリード又はライト動作を実行することを要求することができ（プル・モード）、あるいはアプリケーションは、統合フレームワークがスマート品目３１２０からデータを受信したときに通知するように要求することができる（プッシュ・モード）。
通信エージェント３３４０は、１つ以上の処理エージェント３３３０からの処理済みデータを受け取り、このデータを全ての加入アプリケーション３１３０に供給する。通信エージェント３３４０は、加入アプリケーション３１３０及びそれらの各宛先パラメータのリストを保持している。通信エージェント３３４０は、複数の通信エージェント３３４０の集合とし、各通信エージェントが特定の通信インターフェース又はプロトコル（例えば、ＲＰＣ、ＣＯＭ、ＣＯＲＢＡ、ＪＭＳ、又はＨＴＴＰ）を実現することができる。
【０２３２】
処理したデータを直接加入アプリケーション３１３０に供給する代わりに、通信エージェント３３４０は、仲介物、即ち、イベント・ルータを用いることができる。イベント・ルータは、加入アプリケーションのリスト上に現れる。イベント・ルータとは、ソフトウェア・エンティティ間でメッセージ（イベント）を転送するサービスである。メッセージを用いて、ある出来事についてメッセージ受信側に通知したり、あるいは受信側にクエリを送ることができる。適したイベント・ルータの例には、カリフォルニア州、Mountain ViewのKnowNow Incorporatedから入手可能なKnowNowOイベント・ルータ、又はオーストラリア国、QueenslandのDistributed Systems Technology Centerから入手可能な、Elvinメッセージング・サービスが含まれる。一実施形態では、通信エージェント３４０は、外部アプリケーションが呼び出してＵＩＤ及び追加の品目データを検索することができるメソッドを有するデータ・オブジェクト（又はオブジェクトの集合）のフォーマットで、データを供給する。別の実施形態では、データ・フォーマットはＸＭＬである。ＸＭＬの利点は、それが柔軟性があり、拡張可能で、自己記述型(self-describing)で、データ交換に広く用いられていることである。
【０２３３】
ハードウェア・インターフェース
図３４は、一例としてのハードウェア・インターフェース３４００のブロック図である。ハードウェア・インターフェース３４００は、上位ソフトウェアが下層のハードウェア(underlying hardware)と双方向処理を行うことができるようにするソフトウェアである。現在、広範囲のＲＦＩＤ技術が多数のベンダから入手可能である。用途の場面に応じて、特定のタイプのタグを選択する必要がある（受動／能動型、読み取り専用／再書き込み可能等）。ハードウェア・インターフェースは、公開されている規格を用いて実現されるので、種々のベンダからの種々のＲＦＩＤ技術と共に用いることができるという利点がある。ハードウェア・インターフェースは、ハードウェア・デバイスからデータを読み取る要求、又はハードウェア・デバイスにデータを書き込む要求を受けることができる。ハードウェア・デバイスからのデータは、インテロゲータ・エージェント３３２０又は処理エージェント３３３０のいずれかに送ることができる。
【０２３４】
インターフェース３４００は、アブストラクション・レイヤ(abstraction layer)、サーバ３４１０を含み、インテロゲータ３４２０の詳細を秘匿する。サーバ３４１０は、ハードウェア依存インターフェースを通じて、インテロゲータ３４２０と通信する。実行時に、特定のサーバ３４１０のインスタンスが、１つのインテロゲータ３４２０のみを担当する。しかしながら、数個のアプリケーションが、同時に同じサーバ３４１０のインスタンスと通信することもできる。
【０２３５】
サーバ３４１０は、少なくとも２つの異なるタイプの読み取り要求に対応する。離散的読み取り要求は、現在読み取ることができるタグのみの情報を返す。連続読み取り要求は、前回の読み取り要求が行われて以来読み取られ、バッファされていた全てのタグの情報を返す。
サーバ３４１０は、書き込むデータを受け入れることができる。書き込むデータは、タグ上に格納するデータとすることができ、又はハードウェアの挙動を制御する制御データとすることもできる。例えば、スマート・コンベア・ベルトは、左のベルトと右のベルトとの間で切り換える制御データを受けることができ、スマート販売機は、品目の価格を調節したり、あるいは機械の温度を調節する制御データを受けることができる。
【０２３６】
加えて、サーバ３４１０は以下の機能を利用可能とする。
初期化
この機能は、インターフェース３４００を使用のために初期化する。全てのハードウェアは、通信ポート並びにソフトウェア・オブジェクト及びプロセスに必要なように、初期化される。ハードウェア特定詳細を、ハードウェア特定コンフィギュレーション・ファイルに設定することができる。
終了
この機能は、インターフェース３４００の使用を終了させる。これは、初期化とは逆の機能である。全てのハードウェアを解放し、通信ポートを閉鎖し、関与する全てのソフトウェア・オブジェクト及びプロセスを終了する（他のプロセスによって用いられていない限り）。これは、汎用終了機能である。ハードウェア特定詳細を、ハードウェア特定コンフィギュレーション・ファイルに設定することができる。
フラグ検出
この機能は、現在タグを読み取ることができるか否か、そしていくつのタグを読み取ることができるか検出する。
【０２３７】
論理タグ・タイプの定義
この機能は、所与のタグに対する論理タグ・タイプを定義する。論理タグ・タイプは、タグ上のデータの編成を記述する。図３５に示す電子タグ３５００の一例は、これを示す。図示のように、タグ上のユーザ・データは、物理的にｎ個の３２ビット・データ・ブロックで構成されている。しかしながら、論理的には、これは名前が付けられた３つのデータ・フィールドを有する。即ち、製品番号（「ARTNR」）３５１０、製品の説明（「ARTDESC」）３５２０、及びその価格（「PRICE」）３５３０である。図示のように、フィールドの長さ及び開始アドレスは、必ずしもブロック長及び開始アドレスと同一ではない。
論理タグ・タイプは、各データ・フィールドの名称、開始アドレス、及び長さ、そのデータ・タイプ（フィールドを容易にアプリケーション・データにマップするため）、並びにデータ・フィールド毎の記述を規定する。また、論理タグ・タイプは、タグ識別子を格納する位置も規定する。論理タグ・タイプの定義を延長して、他の情報を含むようにすることができる。
【０２３８】
論理タグ・タイプ記述及びフィールド名称の取得
この機能は、論理タグ・タイプに関する情報を取得する。これは、一般に、フィールド名、並びに、フィールドの長さ及びデータ・タイプを取得するために用いられる。
連続読み取りの開始／停止
この機能は、連続読み取り動作モードを開始又は停止する。
多数のタグからのフィールドの読み取り
この機能は、当該機能を実行した時点で読み取り可能な全てのタグの特定のフィールドからデータを読み取る。パラメータが、離散的又は連続的のどちらの読み取りモードを要求しているのかを指定する。連続モードでは、サーバは読み取った全てのタグの情報をバッファに格納する。連続モードで読み取り機能をコールする毎に、このバッファをクリアする。しかしながら、離散モードでは、バッファをクリアしない。
【０２３９】
特定のタグからのフィールドの読み取り
この機能は直前の機能と類似している。相違するのは、特定のタグＩＤを有する単一のタグからのみフィールドを読み取ることである。指定されたタグＩＤを有するタグを識別するためには、多数のタグを読み取る必要がある場合もある。
多数のタグへのフィールドの書き込み
この機能は、当該機能を実行した時点で書き込むことができる全てのタグの特定のフィールドに同じデータを書き込む。フィールドには名称が付けられており、タグに対して定義されたタグ・タイプによって異なる。同じデータを全てのタグに書き込む。この機能は、タグの大量書き込み、例えば、生産ラインの終点において用いることができる。
【０２４０】
特定のタグへのフィールドの書き込み
この機能は、タグ・リーダ−ライタの動作範囲において、特定のタグの特定のフィールドにデータを書き込む。フィールドには名称が付けられており、タグに対して定義されたタグ・タイプによって異なる。書き込まれるタグは、そのＵＩＤによって指定される。データは、指定されたフィールドのみに書き込まれる。指定されなかったタグ・フィールド内のデータはすべて、不変のまま残される。
また、データ・フィールドは、ハードウェアがその機能性に対応する限り、２つの書き込み機能のいずれかによってロックすることができる。フィールドは、同時に書き込みそしてロックすることができ、あるいは以前に書き込んだフィールドをロックして、そのデータを上書きしないようにすることもできる。
ハードウェア特定コール
あるハードウェアは、このインターフェースの範囲を超えて、ある機能性を提供できる場合がある。顧客がこの機能性を利用できるようにするために、この機能は、アプリエーションから直接ハードウェア特定コールを通過する機構を設けている。
【０２４１】
エラー処理
通信エラーが発生した場合、ハードウェア・デバイス３４２０又はサーバ３４１０は、例えば、ある動作を多数回再度試すことによって、最初に独力で問題を解決しようとする。その低レベルのエラー処理に失敗した場合、インターエース３４００は、何が悪かったのかに関する情報を提供し、アプリケーションが適切な処置を講ずることができるようにする。
エラー・タイプを規定する包括的エラー・コードに加えて、エラーの詳細な説明が与えられる。インターフェース３４００は、少なくとも以下のタイプのエラー状態を認識する。
（１）インテロゲータが応答しない。インテロゲータを初期化し損ねた。
（２）リード・エラー。ｎ個のタグを検出したが、ｍ個からしか正しく読みとれなかった（ｍ＜ｎ）。現場にタグがないというのは、エラー状態ではない。
（３）ライト・エラー。タグが無線場内になかったため、又はある特定の書き込み問題、例えば、ロックされたフィールド又は一般的な故障があったために、タグに書き込むことができなかった。
（４）ハードウェアが対応していない。データ・ロックのような機能は、全てのハードウェアが対応しているとは限らない。
【０２４２】
５．追跡情報の圧縮、フィルタ処理、及び暗号化
以下の節では、追跡情報を圧縮し、フィルタ処理し、又は暗号化した後に記号間で通信する実施態様について説明する。この実施態様は、生産者及び消費者が関与する場面のコンテキストで説明する。生産者又は消費者は、製造業者、流通業者、又は小売店、あるいはタグ付品目を扱うその他の場所又は場所の一部とすることができる。
【０２４３】
図４３に示すように、生産者４３０１は出荷品４３０３を消費者４３０２に送る。出荷品４３０３は、タグ付きコンテナ４３０５の中に数個のタグ付品目４３０４を含む。消費者４３０２が出荷品４３０４を受領すると、消費者のタグ・リーダ・システム４３０６がコンテナのタグ４３０７及び品目のタグ４３０８から情報を読み取る。出荷品１０３を検証するために、消費者１０２は、生産者４３０１からの出荷内容情報４３０９を必要とする。この出荷情報４３０９は、コンテナのＵＩＤ及びコンテナ内の全品目のＵＩＤを含むことができる。品目の色のような、各品目に関連する他の情報は、タグのＵＩＤに入れたり、タグ外部に格納することができる。通信ネットワーク４３０１、例えば、インターネットを通じて、消費者４３０２は生産者４３０１から出荷情報４３０９を受信し、生産者にステータス更新情報を送ることもできる。消費者の所在地にあるローカルＩＴＳ４３１１は、タグ・リーダ・システム４３０６から情報を検索し、タグ情報を出荷情報４３０９と照合する。
【０２４４】
図４５に示すように、生産者と消費者との間で追跡情報を通信する方法４５００は、生産者が複数の識別コードを受信することから開始することができる。各識別コードは、関連する品目を一意に識別する（４５１０）。
識別コードは、品目に結合されているタグから読み取ることができる。企業間オブジェクト追跡を可能にするために、各タグは、関連する品目のために一意の識別コード、例えば、図４６に示す電子製品コード（ｅＰＣ）４５００を担持する。ｅＰＣ４５００は、９６ビットで、８ビットのヘッダ（ビット０〜７）４５１０及び３つのデータ・フィールド、ｅＰＣマネージャ（ビット８〜３５）４６２０、オブジェクト・クラス（ビット３６〜５９）４６３０、及び連番（ビット６０〜９５）４６４０に区分されている。品目にタグ付けすることができる各組織は、ｅＰＣマネージャ・フィールドに一意のコードを有する。組織における各製品分類は、オブジェクト・クラス・フィールドに一意のコードを有する。製品の各個々の品目は、連番に一意のコードを有する。ｅＰＣ以外のＵＩＤも同様に用いることができる。
【０２４５】
生産者は、識別コードを１つ以上の識別コードの集合にソートする（４５２０）。識別コードの各集合は、特定の種別の品目に対応する（例えば、所与の製造業者からの全てのバスケットボール）。
識別コードの各集合毎に、生産者は、当該集合内の各識別コードに共通である、コードの冗長部分を認識する（４５３０）。例えば、図４７に示すように、所与の製造業者からの全バスケットボールのｅＰＣは、冗長部分４７０１を含む。即ち、ｅＰＣは同じｅＰＣマネージャ及びオブジェクト・クラスを共有する。この冗長性は、ｅＰＣの階層構造には固有である。
【０２４６】
生産者は、識別コードの１つ以上の集合を含む文書を作成する（４５４０）。しかしながら、このような文書では、ｅＰＣは、文書サイズの大きな割合を占める可能性がある。例えば、図４７に示すように、出荷文書は、出荷する品目毎のｅＰＣを含む品目レベル情報を収めている。品目数が増加すると、ｅＰＣは文書サイズの大部分となる。
文書サイズを縮小するために、生産者４３０１は、識別コードの各集合毎に、コードの冗長部分を一旦リストにまとめ、各タグを、省略したコードの冗長部分と共にリストに載せる（４５５０）。このように、ｅＰＣの階層的設計は、各ｅＰＣに伴う情報の圧縮を促進することができる。例えば、梱包されある場所に出荷される全てのバスケットボールには、出荷文書内の各バスケットボールの全ｅＰＣを含む必要はない。代わりに、図４８に示すように、出荷文書は、ｅＰＣプリフィックス４８０２の中にｅＰＣマネージャ及びオブジェクト・クラスのための１つのエントリ、並びに出荷される個々のバスケットボールの各々の連番４８０３だけを含めば済む。
【０２４７】
方法４５００と同様のマスキング技法は、出荷以外の他のコンテキストにも適用することができる。例えば、マスキングは、生産のコンテキストでは、生産順序(production order)のサイズを縮小するために適用することができる。新たな品目のラインを製造するための準備において、工場は、通例、品目毎のｅＰＣをリストに纏めた生産順序を生成する。これは、各ｅＰＣのヘッダ、ｅＰＣマネージャ、及びオブジェクト・クラスの部分までもが同一の事例である。方法４５００を生産順序に適用することによって、この冗長性を排除し、品目毎にｅＰＣ全てをリストに入れる代わりに、冗長な部分を省略し、連番のみをリストに纏めることができる。
【０２４８】
文書（出荷、生産、又はその他）サイズも、連番が連続しているときは、生産した品目毎に連番をリストに入れる必要がないことを認識することによって、一層縮小することができる。代わりに、以下に示すように、リストに入れる必要があるのは、最初に製作した品目（「EPC_BASE」）、及び生産した品目の総個数（例えば、１００）で全てである。品目の色のような、品目毎の追加情報は、以下に示すように、品目毎に個々に列挙することができる。
【０２４９】
<PRODUCTION_ORDER ID=1234566>
<ITEM_LIST QUANTITY=1000EPC_PREFIX=01.000A89.00016F>
<EPC_BASE>00168123</EPC_BASE>
<ITEM>
<COLOR>RED</COLOR>
</ITEM>
<ITEM>
<COLOR>BLUE</COLOR>
</ITEM>
<ITEM>
<COLOR>RED</COLOR>
</TTEM>
</TTEM_LIST>
</PRODUCTION_ORDER>
【０２５０】
供給連鎖に沿って、一般に、タグが付けられた品目と、タグが付けられていない品目とがある。更に、荷台又はパッケージのように、一部のタイプの品目のみにＲＦＩＤタグが付けられている場合もある。加えて、各企業が品目にタグを付ける場合もある。例えば、輸送会社がその出荷パッケージにタグを付け、それ自体の業務計画プロセスを自動化することができる。このように、品目、パッケージ、荷台、及びコンテナ・レベルでＲＦＩＤタグがある場合があり、これらのタグは異なる企業からのものであることもある。しかしながら、単純なリーダ／インテロゲータでは、例えば、品目のコンテナを品目から区別することができない。その結果、読み取られる全てのＵＩＤを中央システムに報告し、フィルタ処理しなければならない。このプロセスは非効率的であり、１日に何百万もの報告を処理しなければならないシステムには非常に厄介である。
【０２５１】
企業のｅＰＣマネージャは、オブジェクト・クラス及び連番の割り当てを制御する。企業は、当該企業が生産した品目のアクセサリとして用いられる物理的オブジェクトにそれ自体の方式を規定することもできる。例えば、複数の製造業者によって荷台及びパッケージは、それら自体のｅＰＣタグを有する場合も、有さない場合もある。しかしながら、輸送会社のコンテキストでは、実際に出荷される品目のためのコンテナがある。出荷品をドック間で転送するプロセスは、荷台又はパッケージの内容全体ではなく、荷台又はパッケージのみをチェックするだけで促進される。この手法は、輸送会社がコンテナにそれ自体のｅＰＣを付けることが必要となる。
リーダは、ある種別のｅＰＣパターンのみを取得するように構成することができる。例えば、リーダは、ｅＰＣのオブジェクト・クラス部分において文字「１」で始まるコンテナのみを登録するように構成することができる。実際のＸＭＬフィルタリング方式は、以下のような形式となる。
<Container_Class>01.1234566.1XXXXX</Container_Class> 
【０２５２】
この例では、ＸはｅＰＣを形成する文字列内のワイルドカードであり、リーダは、これらの位置ではあらゆるデータを受け入れる。このようにリーダを構成することによって、リーダは、読み込んだｅＰＣをフィルタ処理し、方式において指示されたコンテナ種別のみをチェックすることが可能となる。このように、フィルタ処理によって、リーダから監視アプリケーション、即ち、出荷確認プロセスのようなプロセスに送られるメッセージを削減することができる。
【０２５３】
図４９は、追跡情報にフィルタ処理を行う方法４９００を示す。フィルタ処理は、リーダ又はリーダ・システムによって、配送プロセス内の種々の段階において（即ち、種々の消費者によって）、そして特定の消費者内においても種々のレベルにおいて行うことができる。例えば、前述のように、フィルタ処理は、タグ−リーダ−レベルにて行うことができる。あるいは、又は加えて、消費者のＩＴＳは、タグ・リーダから受信したデータもフィルタ処理することができる。
個々の品目及び品目のコンテナを含む、複数の品目に伴う識別コードを検索する（４９１０）。各識別コード（例えば、ｅＰＣ）は、関連する品目を一意に識別する文字列である。識別コードは、タグ・リーダから、出荷文書から、又はＩＴＳ（共有又はローカル）というように、種々の発信源から検索することができる。
【０２５４】
各識別コード内には、品目が個別品目か、品目のコンテナかを示す文字が配されている（４９２０）。前述のように、コンテナは、個々の品目からは区別することができ、コンテナは、コードのオブジェクト・クラス部分の最初の文字に「１」を有する。しかしながら、その他の文字及び文字の位置も用いることができる。配された文字に基づいて、識別コードが個々の品目又はコンテナのどちらに対応するのかについて判定を行う（４９３０）。
このような判定がタグ−リーダ・レベルで行われる場合、タグ・リーダは、個々の品目を品目のコンテナから区別することができ、この区別を用いて、読み取った情報の受信者には関係のない読み取りをフィルタ処理で削除する。例えば、受信者が出荷会社である場合、品目の各コンテナのタグ情報だけは知りたいものの、品目自体のタグ情報は知りたくないことがある。このような場合、リーダ自体、又は本システムにおける上位のコンポーネントは、個々の品目に対してコードをフィルタ処理で削除し、コンテナに関するタグ情報のみを受信者に送ることができる。
【０２５５】
追跡情報へのアクセス制御
企業間計算機環境では、追跡情報は、多数の消費者によって用いられる可能性がある。しかしながら、生産者は必ずしも全ての消費者が同程度のアクセスを共有することを望んでいる訳ではない。例えば、製造業者は、「責任者」又は「品質等級」のような、出荷に関する情報を記録することができ、一部の消費者（例えば、税関事務所）はアクセスすることを許可されているが、他の消費者（例えば、小売店）はアクセスが許可されていない。
一実施態様では、追跡情報へのアクセスを制御する際、消費者に文書の一部のみを提供する。例えば、出荷会社は、出荷される商品の全量を知りさえすればよいが、出荷会社は商品の他の属性（例えば、色、価格）を知る（又は知ることを許可される）必要はない。
【０２５６】
しかしながら、単に符号化した同じ文書を全ての消費者に送る方が、一層効率的であり得る。したがって、代替実施態様では、全ての消費者に同じ文書を、符号化したフォーマットで供給する。次いで、各消費者に、文書の一部のみを復号化する選択手段を別個に供給する。符号化及び復号化は、外部システム４３１２、例えば、ＥＲＰシステムには完全に透過的とすることができる。言い換えると、追跡システムの入力及び出力は、平文の非符号化文書とすることができる。
【０２５７】
図５０に示すように、追跡情報へのアクセスを制御する方法５０００を実行する際、生産者は、品目の収集のための追跡情報を作成する。追跡情報は、品目の各々を、１つ以上の属性及び任意の対応する値として表す（５０１０）。生産者は、追跡情報を符号化する際、その対応する別個のコード化方式によって、追跡情報内の個別の各属性の各インスタンスを符号化する（５０２０）。生産者は、符号化した追跡情報を受信者に送り（５０３０）、受信者にアクセスを許可した属性は何か判定を行い（５０４０）、受信者にコード化方式の部分集合を供給する（５０５０）。部分集合は、受信者がアクセスを許可されている属性に対するコード化方式のみを含む。
方法５０００は、追跡情報をタグに格納する前、又は追跡情報を共有ＩＴＳに預託する(deposit)する前というように、追跡プロセスの種々の時点で実行することができる。方法５０００は、追跡情報が放出され、発信元が追跡情報へのアクセスを制御したいときにはいつでも実行することができる。
【０２５８】
図５１に示すように、追跡情報にアクセスするために方法５１００を実行する際、消費者は、品目の集合についての符号化追跡情報を受信する。追跡情報は、品目の各々を１つ以上の属性及び任意の対応する値として表し、追跡情報を符号化するには、追跡情報内の個別の各属性の各インスタンスを、その対応する個別のコード化方式によって符号化する（５１１０）。また、消費者は、コード化方式の部分集合も受信する。この部分集合は、受信者がアクセスを許可されている属性に対するコード化方式のみを含む（５１２０）。最後に、消費者は、受信者がアクセスを許可されている属性を復号化する（５１３０）。
【０２５９】
追跡情報は、物理的オブジェクトに付帯するタグの一部として、ＸＭＬ文書に格納することができる。リーダによって、消費者はタグからＸＭＬ文書を検索することができる。あるいは、消費者は、別の場所、例えば、共有ＩＴＳ又は別の計算機システムからＸＭＬ文書を検索することもできる。
文書種別定義（ＤＴＤ）又はＸＭＬ方式は、ＣＭＬ文書のメタデータを規定する。ＤＴＤは、ＸＭＬ文書に含めるか、又は別個に格納することができる。例えば、以下のに示すProductと呼ばれるＤＴＤは、ProductType、ProductID、Version、Vendor、SalePrice、ProducePlace、ProduceTime、ExpireTime、ResponsiblePerson、QualityGrade、及びWeightという属性フィールドを有する。
【０２６０】
<?xml version=“1.0”encoding=“UTF-8”?>
<!ELEMENT Product(ProductType,ProductID,Version,Vendor,Saleprice,
ProducePlace,ProduceTime,ExpireTIme,ResponsiblePerson,QualityGrade)>
<!ELEMENT productType(#PCDATA)>
<!ELEMENT productID(#PCDATA)>
<!ELEMENT Version(#PCDATA)>
<!ELEMENT Vendor(#PCDATA)>
<!ELEMENT SalePrice(#PCDATA)>
<!ELEMENT producePlace(#PCDATA)>
<!ELEMENT produceTime(#PCDATA)>
<!ELEMENT ExpireTime(#PCDATA)>
<!ELEMENT ResponsiblePerson(#PCDATA)>
<!ELEMENT QualityGrade(#PCDATA)>
<!ELEMENT productSet(#Product+)>
【０２６１】
このＤＴＤファイルに基づくＸＭＬ文書を以下に示す。
<?xml version=“1.0”encoding=“UTF-8”>
<!DOCTYPE ProductSet SYSTEM? ProductSet.dtd”>
<ProductSet>
<Product>
<ProductType>XXXX</ProductType>
<ProductID>45EF76345</ProductID>
<Version>E3DF67</Version>
<Vendor>AAA</Vendor>
<SalePrice>1988-12-28</SalePlace>
<ProducePlace>621</ProducePlace>
<ProduceTime>2000-12-28</PeoduceTime>
<ExpireTIme>2002-12-28</ExpireTime>
<ResponsiblePerson>KellyDe</ResponsiblePerson>
<QualityGrade>6</QualityGrade>
</Product>
<Product>
<ProductType>XXXY</ProductType>
<ProductID>45E003123</ProductID>
<Version>9FD56</Version>
<Vendor>BBB</Vendor>
<SalePrice>3.4</SalePrice>
<ProducePlace>621</ProducePlace>
<ProduceTime>2000-02-28</[ProduceTime>
<ExpireTime>2000-02-28</ExpireTime>
<ResponsiblePerson>Kevin Smith</ResponsiblePerson>
<QualityGrade>8</QualityGrade>
</Product>
</ProductSet>
【０２６２】
図５２は、ネットワーク５２４０において追跡情報をタグ付品目と通信するために用いられる文書、インデックス表、及び符号化文書のシステムを示す。生産者４３０１は、インデックス表５２３０を用いて、生産者のＸＭＬ文書５２１０を符号化ＸＭＬ文書５２１５に変換する。また、インデックス表は、生産者ＤＴＤファイル５２２０を符号化ＤＴＤファイル５２２５に変換する際にも用いることができる。消費者は、生産者からネットワークを通じて、符号化ＸＭＬ又は符号化ＤＴＤファイル５２６０／５２７０を受信する。消費者は、宛先インデックス表を用いて、符号化ＸＭＬ文書を消費者ＸＭＬ文書５２６５に、又は符号化ＤＴＤファイルを消費者ＤＴＤファイル５２７５に変換する。消費者は、消費者ＸＭＬ文書又は消費者ＤＴＤファイルを用いる。
【０２６３】
インデックス表５２３０は、生産者側においてＸＭＬ文書を生成する際に用いられる。インデックス表は、タグ名称をインデックス値に関係付ける。各属性フィールドは、当該属性を記述する対応のタグ名を有する。任意に、各属性フィールドは、対応する値も有する。タグ名は、一般に記述的であり、インデックスはタグ名のコード化である。コード化は、予期されるタグ番号に対して効率的であるように選択するとよい。先に論じたProductSetＸＭＬ文書を処理するためのインデックス表は、以下のように表すことができる。
【０２６４】
表                  
タグ名            インデックス
Product                  １
ProductType              ２
ProductID                ３
Version                  ４
Vendor                   ５
SalePrice                ６
ProducePlace             ７
ProduceTime              ８
ExpireTime               ９
ResponsiblePerson       １０
QualityGrade            １１
ProductSet              １２
上記のインデックス表におけるインデックス値は任意とすることができ、これによって、符号化ＸＭＬ文書は、インデックス表がなければ、解釈が困難となる。
【０２６５】
インデックス表に基づいて、ＸＬＭ文書を、符号化ＸＭＬ文書５２１５と呼ばれる中間データ文書に変換する。インデックス表を用いて作成した、前述のＸＭＬ文書に対応する符号化ＸＭＬ文書は、次の通りである。
<?xml version=? 1.0”encoding=? UTF-8”>
<!DOCTYPE 12 SYSTEM? 12.dtd”>
<12>
<1>
<2>XXXX</2>
<3>45EF76345</3>
<4>E3DF67</4>
<5>AAA</5>
<6>1988-12-28</6>
<7>621</7>
<8>2000-12-28</8>
<9>2002-12-28</9>
<10>KellyDe</10>
<11>6</11>
</1>
<1>
<2>XXXY</2>
<3>45E003123</3>
<4>9FD56</4>
<5>BBB</5>
<6>3.4</66>
<7>621</7>
<8>2000-02-28</8>
<9>2002-02-28</9>
<10>Kevin Smith</10>
<11>8</11>
</1>
</12>
【０２６６】
また、符号化ＤＴＤファイルは、元のＤＴＤファイルに基づいて生成する。先に示し、先に示したインデックス表を用いて生成した符号化ＤＴＤファイルは、次の通りである。
<?xml version=“1.0”encoding=“UTF-8”?>
<!ELEMENT 1(2,3,4,5,6,7,8,9,10,11)>
<!ELEMENT 1(#PCDATA)>
<!ELEMENT 2(#PCDATA)>
<!ELEMENT 3(#PCDATA)>
<!ELEMENT 4(#PCDATA)>
<!ELEMENT 5(#PCDATA)>
<!ELEMENT 6(#PCDATA)>
<!ELEMENT 7(#PCDATA)>
<!ELEMENT 8(#PCDATA)>
<!ELEMENT 9(#PCDATA)>
<!ELEMENT 10(#PCDATA)>
<!ELEMENT 11(#PCDATA)>
<!ELEMENT 12(1+)>
【０２６７】
消費者が文書を復号化するとき、消費者はタグ名を変更し、消費者自身の命名規則により良く対応するようにすることができる。
アクセスの制御に加えて、情報を符号化することの更に別の利点は、符号化したタグ名は、一般に記述的で非常に長い可能性がある、符号化しないタグ名よりも占める空間が少なくて済むことである。インデックス値は、先に例示した単純な数値インデックス方式におけるように、小さく纏まるように選択することができる。
タグのメモリ即ち空間は限られている。したがって、小さく纏ったインデックス値を用いることによって、より多くの追跡情報（例えば、属性フィールド）をタグ内に含ませることができる。同様に、追跡情報をネットワークを通じて伝達するときも、符号化情報は、非符号化バージョンよりも送信に用いる帯域幅を減らすことができる。
【０２６８】
図５３は、符号化ＸＭＬ文書を作成するために用いられる適切なインデックス表をチェックする方法を示す。最初に、システムは、インデックス表が更新を必要とするか否か確認するためにチェックする（５３１０）。必要としない場合、既存のインデックス表を用いて、符号化ＸＭＬ文書又は符号化ＤＴＤファイルを作成する。インデックス表が更新を必要とする場合、新たなインデックス表を作成し、次いでこれを用いて符号化ＸＭＬ文書又は符号化ＤＴＤファイルを作成する（５３３０）。
【０２６９】
符号化ＸＭＬ文書は、ネットワークを通じて変換されるか、又は物理的オブジェクトに付帯するスマート・タグに格納される。消費者側では、宛先インデックス表を用いて、文書を復号化する。インデックス表に関して、以下の例に示すように、宛先インデックス表は、タグ名をインデックス値に関係付ける。
表                  
タグ名            インデックス
Product                  １
ProductType              ２
ProductIdentification    ３
VersionNumber            ４
VendorName               ５
ProduceTime              ８
ExpireTime               ９
ProductSet              １２
【０２７０】
宛先インデックス表における全てのインデックスは、符号化文書を作成する際に用いた、対応するソース・インデックス表にもなければならない。しかしながら、インデックス表における全てのインデックスが、対応する宛先インデックス表にあるとは限らない。ＸＭＬ文書の消費者は、生産者が消費者に共有することを許可した属性フィールドのみについてのタグ名及びインデックスを受信する。例えば、ＸＭＬ文書が製造業者によって作成され、消費者が小売店であり、製造業者は、小売店が、ResponsiblePerson及びQualigyGradeと呼ばれる属性フィールドを見ることを望まない場合、これらのインデックスは小売店の宛先インデックス表には入っていない。
宛先インデックス表及びその対応するインデックス表における特定のインデックスには、異なるタグ名を付帯させることが可能である。したがって、消費者は、その用途に合わせるように、タグ名を変更することができる。例えば、上に示すように、消費者は、ProductIDをProductIdentificationと置き換え、VersionNumberをVersionNumberと置き換え、VendorNameをVendorと置き換えることができる。しかしながら、これらのタグの意味は、その関連する用途では同一でなければならない。
【０２７１】
上で示した宛先インデックス表及び符号化ＤＴＤファイルに基づいて、消費者は以下のＤＴＤファイルを得る。
<?xml version=“1.0”encoding=“UTF-8”?>
<!DOCTYPE ProductSet SYSTEM? ProductSet.dtd”>
<!ELEMENT Product(ProductType,ProductIdentification,VersionNumber,
VendorName,SalePrice,
ProducePlace,ProduceTime,ExpireTime)>
<!ELEMENT ProductType(#PCDATA)>
<!ELEMENT ProductIdentification(#PCDATA)>
<!ELEMENT VersionNumber(#PCDATA)>
<!ELEMENT VendorName(#PCDATA)>
<!ELEMENT SalePrice(#PCDATA)>
<!ELEMENT ProducePlace(#PCDATA)>
<!ELEMENT ProduceTime(#PCDATA)>
<!ELEMENT ExpireTime(#PCDATA)>
<!ELEMENT ProductSet(Product+)>
【０２７２】
上で示した宛先インデックス表及び符号化ＸＭＬ文書に基づいて、消費者は以下のＸＭＬ文書を得る。
<?xml version=? 1.0”encoding=? UTF-8”>
<!DOCTYPE ProductSet SYSTEM? ProductSet.dtd”>
<ProductSet>
<Product>
<ProductType>XXXX</ProductType>
<ProductIdentification>45EF76345</ProductIdentification>
<VersionNumber>E3DF67</VersionNumber>
<VendorName>AAA</VendorName>
<SalePrice>1988-12-28</SalePrice>
<ProducePlace>621</ProducePlace>
<ProduceTime>2000-12-28</ProduceTime>
<ExpireTime>2002-12-28</ExpireTime>
</Product>
<Product>
<ProductType>XXXY</ProductType>
<ProductIdentification>45E003123</ProductIdentification>
<VersionNumber>9FD56</VersionNumber>
<VendorName>BBB</VendorName>
<SalePrice>3.4</SalePrice>
<ProducePlace>621</ProducePlace>
<ProduceTime>2000-02-28</ProduceTime>
<ExpireTime>2002-02-28</ExpireTime>
</Product>
/ProductSet>
【０２７３】
本発明は、ディジタル電子回路、又はコンピュータ・ハードウェア、ソフトウェア、あるいはこれらの組み合わせにおいて実現することができる。本発明は、コンピュータ・プログラム生産物、即ち、情報担体、例えば、機械読み取り可能ストレージ又は伝搬信号に有形的に具現化し、データ処理装置、例えば、プログラム可能なプロセッサ、コンピュータ、又は多数のコンピュータによる実行のため、又はその動作を制御するためのコンピュータ・プログラムとして実現することができる。コンピュータ・プログラムは、コンパイル型言語又はインタプリタ型言語を含むあらゆる形態のプログラミング言語で書くことができ、単体のプログラムとして、あるいはモジュール、コンポーネント、サブルーチン、又は計算環境における使用に適したその他のユニットを含むあらゆる形態で展開することができる。コンピュータ・プログラムは、１つコンピュータ上で、あるいは１つのサイトにおいて、又は多数のサイトに分散され通信ネットワークで相互接続した多数のコンピュータ上で実行するように展開することができる。
【０２７４】
本発明の方法ステップは、コンピュータ・プログラムを実行する１つ以上のプログラム可能なプロセッサによって実行し、入力データを処理し、出力を発生することによって、本発明の機能を実行することができる。また、方法ステップは、特殊目的論理回路、例えば、ＦＰＧＡ（フィールド・プログラマブル・ゲート・アレイ）又はＡＳＩＣ（特定用途集積回路）によって実行することもでき、本発明の装置は、この特殊目的論理回路として実現することができる。
コンピュータ・プログラムの実行に適したプロセッサは、一例として、汎用及び特殊目的双方のコンピュータ、並びにディジタル・コンピュータのあらゆる種類のいずれか１つ以上のプロセッサを含む。一般に、プロセッサは、命令及びデータをリード・オンリ・メモリ又はランダム・アクセス・メモリ、あるいは双方から受け取る。コンピュータの必須エレメントは、命令を実行するプロセッサ、並びに命令及びデータを格納する１つ以上のメモリ・デバイスである。一般に、コンピュータは、データを格納する１つ以上の大容量記憶デバイス、例えば、磁気、光磁気ディスク、又は光ディスクも含むか、あるいは動作的に結合され、これらからのデータを受けるか又はこれらへデータを転送する。コンピュータ・プログラム命令及びデータを具現化するのに適した情報単体は、一例として、半導体メモリ、例えば、ＥＰＲＯＭ、ＥＥＰＲＯＭ、及びフラッシュ・メモリ・デバイス、内部ハード・ディスク及びリムーバブル・ディスクのような磁気ディスク、光磁気ディスク、並びにＣＤ−ＲＯＭ及びＤＶＤ−ＲＯＭディスクを含む、不揮発性メモリの全ての形態を含む。プロセッサ及びメモリは、特殊目的論理回路によって補強すること、又はこれらに組み込むことも可能である。
【０２７５】
ユーザとの双方向処理を行うためには、本発明を、ユーザに情報を表示するＣＲＴ（陰極線管）又はＬＣＤ（液晶ディスプレイ）のような表示装置を有するコンピュータと、キーボードと、マウス又はトラックボールのように、ユーザがコンピュータに入力を供給するポインティング・デバイスとを有するコンピュータ上で実現することができる。ユーザとの双方向処理を行うためには、他の種類のデバイスも同様に用いることができる。例えば、ユーザに与えるフィードバックは、視覚フィードバック、聴覚フィードバック、又は接触フィードバックのような、あらゆる形態の知覚フィードバックとすることができ、ユーザからの入力は、音響、音声、又は接触入力を含む、あらゆる形態で受けることができる。
【０２７６】
本発明は、バック・エンド・コンポーネント、例えば、データ・サーバを含む計算機システム、又はミドルウェア・コンポーネント、例えば、アプリケーション・サーバを含む計算機システム、又はフロント・エンド・コンポーネント、例えば、グラフィック・ユーザ・インターフェースを有するクライアント・コンピュータ又はユーザが本発明の実施態様と双方向処理を行うことができるウェブ・ブラウザを含むコンピュータ、あるいはこのようなバック・エンド、ミドルウェア、又はフロント・エンド・コンポーネントのあらゆる組み合わせにおいて実現することができる。システムのコンポーネントは、ディジタル通信のいずれの形態又は媒体、例えば、通信ネットワークによっても相互接続することができる。通信ネットワークの例には、ローカル・エリア・ネットワーク（「ＬＡＮ」）、ワイド・エリア・ネットワーク（「ＷＡＮ」）、及びインターネットが含まれる。
計算機システムは、クライアント及びサーバを含むことができる。クライアント及びサーバは、一般に互いから離れており、通例、通信ネットワークを通じて双方向処理を行う。クライアント及びサーバの関係は、それぞれのコンピュータ上で実行し、互いにクライアント−サーバ関係を有するコンピュータ・プログラムによって発生する。
【０２７７】
以上、特定的な実施形態及び場面に関して本発明を説明した。他の実施形態も本発明の範囲に該当する。例えば、本発明のステップは、異なる順序で実行することができ、それでも所望の結果を得ることができる。本システムは柔軟性があり、品目を追跡するための多くの業務方法を提供する。１つの方法では、インターネットのようなネットワーク上でサービスを分配するサービス・プロバイダによって提供されるシステムに、１人以上の消費者が加入する。この場合、顧客はコンポーネントもシステム全体も調達する必要がなく、これによって資本経費を節約する。あるいは、顧客は、システム全体のコンポーネントを調達することによって、運転コストを節約する。あるいは、本システムは、先に記載した業務方法のあらゆる組み合わせにも対応することができる。例えば、ある顧客は本システムに加入することができ、ある顧客は、コンポーネント又は本システム全体を調達することができる。
【０２７８】
その他の場面も本発明の範囲に該当する。本システムは、業界全域にわたって、個人規模から地球規模まで、ある範囲の新たな改良したアプリケーションの開拓を支援する。本システムの他の用途は、供給連鎖管理、物資追跡管理、セキュリティ及びアクセス制御、輸送、料金回収、販売時点情報管理への応用、及び手荷物運搬を含む。これらの例について以下に更に詳しく説明する。
【０２７９】
供給連鎖管理
ＲＦＩＤシステムは、組立プロセス（例えば、自動車又は農業機械の生産のような）全域を移動する高単位(high-unit)、高価値製品の識別に理想的に適している。また、ＲＦＩＤシステムは、箱、運搬ケース、及び荷台のような製品運搬機の永続的識別に必須の耐久性を提供する。
物資追跡及び管理
物資追跡及び管理への応用では、建物、構内、又はターミナルのような空間内部における機器、人、及び文書のフローを監視し、例えば、物資の制御を厳格化し、個人を含む品目を確実に追跡するものを含む。物資管理における特定の用途には、記録／文書の追跡、人の追跡、構内管理、及び機器の追跡が含まれる。
セキュリティ及び侵入制御
貴重な機器及び人材の移動及び使用は、機器に取り付けられた、あるいは機器又は人に付帯させたトランスポンダを通じて関しすることができる。また、トランスポンダは、クレジット・カード・サイズのセキュリティ・バッジ内に埋め込むこともできる。ホーム・セキュリティ・コール・システム及び建物の侵入は、セキュリティ及び侵入制御用途の２つの例である。
輸送
トランスポンダは、車両（例えば、航空機、貨車、トラック）に取り付けることができ、当該車両及びその内容物に関する重要な情報を収容することができる。輸送への応用には、航空機識別、貨車及び出荷コンテナの追跡、公共輸送機関の切符発売(ticketing)、並びに計量場への応用が含まれる。
料金回収
料金回収への応用では、トランスポンダを車両に取り付けることを伴う。トランスポンダは、前払い残高を特定するコードをリーダに送信し、リーダは自動的に前払い残高から料金を差し引く。
販売時情報管理
これらの用途には、小売り品目の電子的調査、偽造防止、及び販売業務処理が含まれ、大抵の場合、本質的に能動型タグである、低コストのトランスポンダをタグとして個々の小売り品目に取り付けることを伴う。
手荷物運搬
手荷物運搬への応用では、航空荷物に、スマート・ラベルのようなＲＦＩＤトランスポンダをタグとして取り付け、航空荷物運搬処理において、旅行客が空港に預けたときから、旅行客が彼の最終目的地に到着するときまで荷物を追跡する。
【図面の簡単な説明】
【０２８０】
【図１】本発明によるシステムを示すブロック図である。
【図２】一意の識別コードの一例を示す図である。
【図３】本システムの一実施態様を示すブロック図である。
【図４】品目導入プロセスを示すフロー図である。
【図５】温度センサ・デバイス及びＲＦＩＤタグの動作を示すフロー図である。
【図６】箱の荷台上への装荷のようなイベントに対するシステムの応答を示すフロー図である。
【図７】更新動作を示すフロー図である。
【図８】更新、読み取り、及び警報動作を示すフロー図である。
【図９】供給動作を示すフロー図である。
【図１０】警報認識、並びにタグへのデータ・フロー及びタグからのデータ・フローの一場面を示すブロック図である。
【図１１】警報認識、並びにタグへのデータ・フロー及びタグからのデータ・フローの別の場面を示すブロック図である。
【図１２】データ・フローのプロセスの一態様を示すフロー図である。
【図１３】データ・フローのプロセスの別の態様を示すフロー図である。
【図１４】本システムの一実施態様を示すブロック図である。
【図１５】本システム内部のソフトウェア・コンポーネントを示すブロック図である。
【図１６】追跡情報を格納し、変更し、問い合わせる機構を示すブロック図である。
【図１７】特性リスト機能性を示すブロック図である。
【図１８】出荷の場面を示すブロック図である。
【図１９】別の出荷の場面を示すブロック図である。
【図２０】データ復元機構を示すブロック図である。
【図２１】クエリ応答機構を示すブロック図である。
【図２２】クエリ応答機構を示すブロック図である。
【図２３】クエリ応答機構を示すブロック図である。
【図２４】クエリ応答機構を示すブロック図である。
【図２５】クエリ応答機構を示すブロック図である。
【図２６】インフラストラクチャの大規模実施態様を示すブロック図である。
【図２７】ワールド・モデル構造を示すブロック図である。
【図２８】許可モデルを示すブロック図である。
【図２９】ワールド・モデル構造を示すブロック図である。
【図３０】クラスタとして実現した親ノードを示すブロック図である。
【図３１】本システムの一実施態様を示すブロック図である。
【図３２】階層状になっている多数の統合エンジンを用いた一実施態様を示すブロック図である。
【図３３】統合エンジンを示すブロック図である。
【図３４】ハードウェア・インターフェースを示すブロック図である。
【図３５】電子タグを示すブロック図である。
【図３６】本発明による品目追跡システムと共に実現する在庫管理システムの基本構造のブロック図である。
【図３７】イベント・ルーチングを用いる一実施形態のブロック図である。
【図３８】図３８は、イベント・ルーチングのための主要構造の図である。
【図３９】公開のためのプロトコル・フローの図である。
【図４０】加入のためのプロトコル・フローの図である。
【図４１】イベント・ルータを突き止めるためのオブジェクト命名サービスのブロック図である。
【図４２】多数の品目追跡システム間で分散するためのイベント・ルータの使用を示す図である。
【図４３】生産者と消費者との間の通信システムのブロック図である。
【図４４】共有品目追跡システムを用いた、生産者と消費者との間の通信システムのブロック図である。
【図４５】追跡情報の伝達方法のフロー図である。
【図４６】電子生産物コード（ｅＰＣ）の構造を示す図である。
【図４７】マスキングをしない出荷文書を示す図である。
【図４８】マスキングをした出荷文書を示す図である。
【図４９】追跡情報のフィルタリング方法のフロー図である。
【図５０】追跡情報の伝達方法のフロー図である。
【図５１】追跡情報にアクセスする方法のフロー図である。
【図５２】追跡情報の伝達において用いられる文書、インデックス表、及び符号化文書のシステムを示す図である。
【図５３】適切なインデックス表が符号化ＸＭＬ文書を作成するために用いられていることをチェックする方法のフロー図である。
【図５４】顧客サービスとその他のエージェンシ及び業務との間の情報フローの一例を示すブロック図である。
【図１】
2005515135.tif 000003
【図２】
2005515135.tif 000004
【図３】
2005515135.tif 000005
【図４】
2005515135.tif 000006
【図５】
2005515135.tif 000007
【図６】
2005515135.tif 000008
【図７】
2005515135.tif 000009
【図８】
2005515135.tif 000010
【図９】
2005515135.tif 000011
【図１０】
2005515135.tif 000012
【図１１】
2005515135.tif 000013
【図１２】
2005515135.tif 000014
【図１３】
2005515135.tif 000015
【図１４】
2005515135.tif 000016
【図１５】
2005515135.tif 000017
【図１６】
2005515135.tif 000018
【図１７】
2005515135.tif 000019
【図１８】
2005515135.tif 000020
【図１９】
2005515135.tif 000021
【図２０】
2005515135.tif 000022
【図２１】
2005515135.tif 000023
【図２２】
2005515135.tif 000024
【図２３】
2005515135.tif 000025
【図２４】
2005515135.tif 000026
【図２５】
2005515135.tif 000027
【図２６】
2005515135.tif 000028
【図２７】
2005515135.tif 000029
【図２８】
2005515135.tif 000030
【図２９】
2005515135.tif 000031
【図３０】
2005515135.tif 000032
【図３１】
2005515135.tif 000033
【図３２】
2005515135.tif 000034
【図３３】
2005515135.tif 000035
【図３４】
2005515135.tif 000036
【図３５】
2005515135.tif 000037
【図３６】
2005515135.tif 000038
【図３７】
2005515135.tif 000039
【図３８】
2005515135.tif 000040
【図３９】
2005515135.tif 000041
【図４０】
2005515135.tif 000042
【図４１】
2005515135.tif 000043
【図４２】
2005515135.tif 000044
【図４３】
2005515135.tif 000045
【図４４】
2005515135.tif 000046
【図４５】
2005515135.tif 000047
【図４６】
2005515135.tif 000048
【図４７】
2005515135.tif 000049
【図４８】
2005515135.tif 000050
【図４９】
2005515135.tif 000051
【図５０】
2005515135.tif 000052
【図５１】
2005515135.tif 000053
【図５２】
2005515135.tif 000054
【図５３】
2005515135.tif 000055
【図５４】
2005515135.tif 000056
【国際調査報告】
2005515135.tif 000057