JP2006528384A - Ｒｆｉｄ機能を有するｘｍｌプリンタシステム - Google Patents

Abstract

ＸＭＬシステムが、拡張マークアップ言語（ＸＭＬ）の入力データストリームに基づいて、バーコードラベル、タグ、切符、カード、又は他の媒体を印刷するように、及び／又は媒体の中に埋め込まれたＲＦＩＤ素子をコード化するように構成される。このＸＭＬシステムは、ネットワークに動作可能なように接続されたコンピュータシステムを備える。コンピュータシステムは、ＸＭＬ入力データストリームを受信、解析、及び処理し、かつスキーマ容器からＸＭＬデータストリームの中で識別されたスキーマを得るように構成されたＸＭＬプロセッサをさらに備える。このＸＭＬプロセッサは、得られたスキーマに基づいてＸＭＬデータストリームを検証する。スタイルシート容器からＸＭＬデータストリームの中で識別されたスタイルシートを得るように構成されたＸＳＬＴプロセッサも含まれる。このＸＳＬＴプロセッサは、得られたスタイルシートに基づいて、ＸＭＬ入力データストリームの中のデータを変換されたＸＭＬデータに変換する。さらに、ＸＳＬＦＯプロセッサは、スタイルシートの中に含まれたＸＳＬＦＯ命令に基づいて、変換されたＸＭＬデータをフォーマットされたＸＭＬデータにフォーマットする。次に、バーコードレンダリングサブシステムはフォーマットされたＸＭＬデータを受け取り、バーコードラベルのビットマップ表示を生成する。別の方法では、システムはＸＭＬ入力データストリームを受信及び処理するように構成されたＸＭＬプロセッサと、フォーマット用テンプレートを受信及び処理するように構成されたＺＰＬプロセッサと、ＸＭＬ入力データストリームの中に含まれたＸＭＬデータとフォーマット用テンプレートとの間の関連性を明らかにするように構成された可変データインテグレータと、フォーマット用テンプレートによって制御されたフォーマットに基づいて、関連付けられたＸＭＬデータをフォーマットするように構成されたフォーマッティングエンジンと、バーコードラベル、タグ、切符、カード、他の媒体の印刷可能な表示を生成し、及び／又はＲＦＩＤ素子用にコード化情報を作るように構成されたバーコードレンダリングエンジンとを備える。

Description

［関連出願との相互参照］
本出願は、２００３年１月１０日に出願された「XML Printer System」という名称の同時係属中の米国特許出願第１０／３３２，６０４号に対する優先権の利点を請求すると共に、この特許出願の一部継続出願である。この特許出願は、現在は米国特許第６，５４０，１４２号となっている、「Native XML Printer」という名称の２００２年７月１７日に出願された米国特許出願第１０／１９７，０１４号の一部継続出願であり、下記の仮出願からの優先権の利点を請求する。その仮出願は、１）「XML Printer Technology」という名称の２００２年１月４日に出願された米国仮特許出願第６０／３４５，３８９号と、２）「Bar Code Labeling Systems Having Machine Readable Standards」という名称の２００１年１２月１７日に出願された米国仮特許出願第６０／３４１，４２７号とである。これらの米国仮特許出願第６０／３４５，３８９号及び６０／３４１，４２７号は、参照することによってその全体が本願に組み込まれる。

［著作権に関する記述］
この特許文献の開示内容の一部には、著作権保護を受ける材料が含まれる。著作権の所有者は、特許文献又は特許の開示のいずれかによる複写には、それが特許局の特許のファイル又は記録の中に現れるため反対はしないが、そうでない場合は、それが何であれ、全ての著作権を留保する。

［技術分野］
本発明は全体的に、切符、タグ、カード、バーコードラベル、シート送り用紙（sheet fed paper）、連続用紙及び折り畳み用紙、プラスチック媒体などの媒体を印刷するため、また媒体の中に埋め込むことができるＲＦ（無線周波数）識別回路（ＲＦＩＤ）をコード化するための方法及び装置に関する。さらに詳細には、１つの実施形態では、そのような印刷された媒体を印刷する及び／又は既存のＺＰＬベース（ゼブラプログラミング言語）のフォーマット用テンプレートを用いてＸＭＬデータストリームに基づいてＲＦＩＤ装置をコード化するＸＭＬ（拡張マークアップ言語）用プリンタに関する。

バーコードを印刷するための、またバーコードプリンタにデータを送信するためのプリンタシステムは周知である。しかしながら、多くのそのようなシステムはデータのコード化に関して所有権で保護された方法を使用するため、そのような方法は他のバーコードプリンタと交換できるように使用することができない。また、周知のデータコード化方法は一般に、基礎をなすデータを人間が読み取ることができないようにする。このことは、コンピュータシステムに対しては障害にはならないが、下にあるバーコード素子の名前の中に現れる幾つかのデータを調査、ディバッグ、又は理解しようとする人にとっては耐え難い負担になる。この点において、ＸＭＬは多くの企業体によって採用されている公開された規格であり、人が読み取ることができる。ＸＭＬを使用することにより、人が読取りできない方法に関連する多くの問題及び陥穽を避けることができる。

バーコードのラベリングは、取引の多くの局面で高範囲にわたって使用されている。特に、１つの宛先から別の宛先に出荷される小包又は商品は、特定のバーコードラベルにより荷送人によって識別される。逆に、受け取られた商品もバーコードラベルを用いて識別され、受取人の在庫システムの中に入力される。多くの場合、商品の受取人は、荷送人が貼り付けるバーコードの形式及び内容を指示する。これは、「コンプライアンスラベリング（compliance labeling）」と呼ばれる。無論、バーコードのラベリングの利点を利用するように商品を出荷する必要はない。例えば、在庫管理システムは高範囲にバーコードのラベリングを利用して、施設の中又は施設間の様々な商品を追跡及びモニタする。

コンプライアンスラベリングは一般に、比較的大きな市場支配力すなわち購買力を有する商品の買い手によって使用される。彼らの経済力のために、彼らは供給業者すなわち売り手によって彼らに提供された製品に付けられたバーコードラベルの形式及び内容を指示することができる。これは供給業者にとっては負担になるが、供給業者がこの買い手と取り引きしたいと思う場合は、彼らはラベリングに関する買い手の要求に応じる必要がある。例えば、Wal-Mart, Inc.,などの大きな小売業者は、供給業者が自分たちのコンプライアンスラベリングに対する要求に応じるように要求する能力及び購買力を持っているだけではなく、このラベリングに対する要求事項に応じない供給業者を処罰することもできる。

さらに、こうしたバーコードのラベリングに関する要求事項は、コンプライアンスを要求する事業体の気まぐれで変わることがある。このため、供給業者は新しいラベリングに関する要求事項を満たし、修正されたバーコードを試験して、確実に全ての仕様に適合する必要がある。これは比較的効率が悪く、時間がかかる。それは金銭的な罰金に至る可能性があるようなエラーを発生させやすい。

無線周波数の識別（ＲＦＩＤ）は、製品がサプライチェーンを通って消費者に向けて移動するときにその製品を識別するために、バーコードラベリングに加えて又はそれの代わりにますます使用されるようになっている。コンプライアンスラベリングは、商品のパレット、カートン、及び個々の製品に対するＲＦＩＤタグの適用及びコード化を含むように拡張されている。製品に関するデータは、タグに書き込む及び／又はタグから読み取ることができる。製品の識別番号などのデータはタグ上に記憶することができ、一方固有のタグ識別番号（タグ及び関連する製品をシリーズ化する）などのデータをタグから取り出すことができる。

自己検証し、またバーコードラベルの形式又は内容の変化を実行するために大きなソフトウェアプログラミングの変更を要求しない、バーコードラベリングの情報を定義するための公開規格（open standard）を提供するようにという要求が存在する。データをバーコードプリンタに送る形式を使用するための要求も存在する。この場合データは、このデータを読み取る人が理解できる形式である。

ラベルのレイアウトを管理する現行のＺＰＬフォーマット用テンプレートを補足的に利用しながら、及び／又は印刷するラベルのレイアウトを管理するためにＸＳＬ（拡張スタイルシート言語）を使用する純粋なＸＭＬフォーマット用テンプレートを利用することによって、バーコード用プリンタシステムにＸＭＬで送信するためのデータをフォーマットするために、企業資源計画システム（enterprise resource planning system）（ＥＲＰ）を認めるようにというさらなる要求が存在する。さらに、ＲＦＩＤデータなどの他のデータが、ＲＦＩＤデータをコード化することが埋め込まれたＲＦＩＤ回路の中で行われるような装置又は他の自動識別装置に供給されるような形式を使用することに関する要求が存在する。ＲＦＩＤ回路から読み取られたＲＦＩＤデータをＥＲＰシステム又は他のホストコンピュータシステムに戻すための要求が存在する。

新規であると信じられている本発明の特徴は、添付の特許請求の範囲の中に詳細に記述されている。本発明はそのさらなる目的及び利点と共に、添付の図面と併せて下記の説明を参照すれば最も良く理解することができるであろう。

この書面による明細書では、接続語を含むために、離接的接続詞が使用される。定冠詞又は不定冠詞を使用することは、濃度（cardinality）を表示することを意図しない。特に、「定冠詞」が付いた物体若しくは事物又は「不定冠詞」が付いた物体若しくは事物は、複数のそのような物体若しくは事物をも記述することを意図する。

ここで図１を参照すると、ＸＭＬシステム１０の特定の実施形態のハイレベルのハードウェアのブロック図が全体的に示されている。図１から図６の実施形態では、システムの生来の又は自然の「言語」はＸＭＬであり、このためこのＸＭＬシステム１０は「生来のＸＭＬプリンタ」と呼ばれる。このＸＭＬシステム１０には、ＲＡＭ１４、ＲＯＭ１６、ハードディスク記憶装置１８、キャッシュメモリ２０、データベース記憶装置２２などの（「メモリサブシステム」２６とも呼ばれる）様々なハードウェア構成要素を含むコンピュータシステム又は処理システム１２が含まれる。このコンピュータシステム１２は、この技術分野で周知のように、コンピュータ、マイクロプロセッサ、ＲＩＳＣプロセッサ（縮小命令セットコンピュータ）、ＣＩＳＣプロセッサ（複雑命令セットコンピュータ）、メインフレームコンピュータ、ワークステーション、シングルチップコンピュータ、分散プロセッサ、サーバ、コントローラ、マイクロコントローラ、分散論理コンピュータなどの任意の適当な処理装置２８を含む。例えば、処理装置２８は、Intel Pentium（登録商標）マイクロプロセッサ、ｘ８６互換マイクロプロセッサ、又は等価装置とすることができる。

メモリサブシステム２６は、ＲＡＭ、ＥＰＲＯＭ（電気的プログラム可能ＲＯＭ）、フラッシュメモリ、ダイナミックメモリ、スタティックメモリ、ＦＩＦＯ（先入れ先出し）メモリ、ＵＦＯ（後入れ先出し）メモリ、円形メモリ（circular memory）、半導体メモリ、バブルメモリ、バッファメモリ、ディスクメモリ（disk memory）、光メモリ、キャッシュメモリなどの任意の適当な記憶要素を含む。磁気媒体上の固定記憶装置、半導体装置の中の記憶装置又は通信リンクを通してアクセス可能な遠隔の記憶装置のいずれであろうと、任意の適当なメモリの形態を使用できる。

ユーザーインターフェース３０はコンピュータシステム１２に接続されて、ユーザ及び／又はキーボードによって選択できるスイッチなどの各種の入力装置３６を含む。このユーザーインターフェースは、この技術分野では周知の、ＬＣＤディスプレイ、ＣＲＴ、様々なＬＥＤ表示器及び／又は音声出力装置などの適当な出力装置４０も含む。

コンピュータシステム１２と外部ソースとの間を通信するために、通信インターフェース４２がコンピュータシステムに動作可能なように接続されている。例えば、この通信インターフェース４２は、イーサネット（登録商標）ネットワーク、イントラネット、又は他の適当なネットワーク４３としてローカルエリアネットワークとすることができる。通信インターフェース４２は、インターネット４４を介して通信を容易にすることができる公衆交換電話網（ＰＳＴＮ）４６又はＰＯＴＳ（一般電話システム）と接続することもできる。専用のネットワーク及び遠く離れたネットワークも使用できる。任意の適当な市販の通信装置又はネットワークも、この技術分野では周知のように使用できる。

コンピュータシステム１２は、プリンタシステム５０にもさらに接続される。このプリンタシステム５０には、媒体／用紙制御システム５２、プリンタ用ドライバ５４及び印字ヘッド機構部５６が含まれる。バーコードラベルを印刷できる任意の適当なプリンタを使用できる。これらのプリンタには、各種のドットマトリックス、インクジェット、レーザ及び／又はサーマルプリンタが含まれる。無論、ドットマトリックスプリンタの品質は一般に低いため、ラベル出力をより接近してモニタする必要がある。好ましいことに、このプリンタシステム５０は熱転写プリンタである。例えば、このような好適なプリンタは、イリノイ州Vernon HillsのZebra Technologies Corporationから入手でき、モデルＸｉシリーズのバーコードプリンタ（ＸｉＩＩＩ＋，９０ＸｉＩＩＩ＋，９６ＸｉＩＩＩ＋，１１０ＸｉＩＩＩ＋，１４０ＸｉＩＩＩ＋，１７０ＸｉＩＩＩ＋，２２０ＸｉＩＩＩ＋，など）、２８００シリーズのバーコードプリンタ、モデルＺ４Ｍ、Ｚ６Ｍ、１０５ＳＬバーコードプリンタ、モデルＲ４Ｍプラス、Ｒ４０２、Ｒ−１４０プリンタ／エンコーダなどが含まれる。任意の適当なバーコードラベルプリンタも使用できる。

別の方法では、プリンタシステム５０には、印刷されたラベリング又は他の印刷された表示をその表面で受け取ることができるＲＦＩＤ（無線周波数識別）媒体のプログラミングを処理するための「非印刷」機構が含まれる。「プリンタシステム」という用語は、「ＲＦＩＤ」はその用語の一部ではないが、ＲＦＩＤの能力も含むシステムを含むことを意味する。さらに、「バーコードラベル」という用語が本願で使用されるが、この用語は紙のラベルに限定されるものではなく、例えば、チケット、タグ、カード、シート送り用紙、連続用紙及び折り畳み用紙、プラスチック媒体、ＲＦＩＤ回路に埋め込まれた媒体、及び他の自動識別装置を含む。本発明は、どのような種類の媒体にも適合する。

一般に、こうしたプリンタは、種々のモータ、ラベルカッタ、リボンハンドラ、センサなど（図示せず）を含む。さらに、このようなプリンタは、この技術分野では周知のように、媒体センサ、印字ヘッド用温度センサ、ヘッドオープンセンサ、リボンセンサなど（図示せず）の様々な制御入力部すなわちセンサを含む。このプリンタシステム５０は、コンピュータシステム１２の中に存在するプロセッサ２８とは別に１つ以上の付加的なプロセッサ６０を含む。別の方法では、コンピュータシステム１２の中のプロセッサ２８は、十分に強力である場合は、別の処理装置を必要とせずにプリンタシステム５０の機能を制御及び処理することができる。このためプリンタシステム５０の全ての機能は、プリンタシステムから物理的に離れたコンピュータ又はプロセッサによって制御することができる。インクジェットヘッドの制御に関するさらなる詳細は、１９９４年１２月１３日に発行され本発明の所有者が所有する「Thermal Transfer Printer With Controlled Ribbon Feed」という題名の米国特許第５，３７２，４３９号の中で見出すことができる。この米国特許第５，３７２，４３９号は、参照することによってその全体が本願に組み込まれる。

プリンタシステムのプロセッサ６０は、ＲＦＩＤトランシーバ６１にさらに動作可能なように接続される。このＲＦＩＤトランシーバ６１は動作可能なようにプロセッサ６０と、又は図１において点線で示すように、コンピュータシステム１２の処理装置２８に接続される。ＲＦＩＤトランシーバ６１がどこに存在するか又はどの処理要素にそれが接続されるかに関しては、本発明の範囲にとっては重要ではない。

ＲＦＩＤトランシーバ６１は、ＲＦＩＤトランスポンダ６２と通信して、このＲＦＩＤトランスポンダをプログラムするように構成される。ＲＦＩＤトランスポンダ６２は「チップ」形又は「チップレス」形とすることができ、こうしたＲＦＩＤトランスポンダの１つの一般的な形態は、「スマートラベル」の中で使用されることが多く、アンテナ及びＲＦＩＤ集積回路（図示せず）を含む。そのようなＲＦＩＤトランスポンダ６２は、ＤＣ電源の能動トランスポンダ及びバッテリーなしの受動トランスポンダの両方を含み、種々の形状係数の中で利用できる。「バーコードプリンタ」又は「バーコードシステム」という用語は、本願では「バーコード／ＲＦＩＤシステム」や「ＸＭＬシステム」などの用語と交換できるように使用される。またそのようなシステムは、例え「ＲＦＩＤ」という用語が必ずしも識別文字の一部でなくても、ＲＦＩＤデータをＲＦＩＤトランスポンダの中にコード化する能力を含む。システム１２は、ＲＦＩＤデータをＲＦＩＤトランスポンダの中にコード化する能力を含む必要がある。

ＲＦＩＤトランスポンダに関するさらなる詳細は、２００１年１０月２５日に出願され現在係争中の「Method And Apparatus For Associating On Demand Certain Selected Media And Value-Adding Elements」という名称の米国特許出願第１０／００１，３６４号の中に見出すことができる。この特許出願は、本願の譲受人が所有している。この米国特許出願第１０／００１，３６４号は、参照することによってその全体が本願に組み込まれる。

好ましいことに、コンピュータシステム１２及びプリンタシステム５０は共通の筐体の中に配置されているが、必ずしもこの方法で構成する必要はない。例えば、コンピュータシステム１２は、プリンタシステム５０とは別個の離れた筐体の中に収容することができる。

ここで図１〜図３を参照すると、図２はソフトウェアのハイレベルのブロック図の具体的な実施形態を例示し、一方図３はハイレベルのソフトウェアのブロック図とデータの流れ図とが組み合わされた具体的な実施形態を例示している。下記で説明するソフトウェアは、図１のコンピュータシステム１２のプロセッサ２８によって実行される。再度説明するが、プロセッサ２８は、コンピュータシステム１２及びプリンタシステム５０の両方に共通する機能を実行する。一斉に又は別個に機能することができる１つ以上のプロセッサが存在する。処理又は処理機能がコンピュータシステムによって若しくはコンピュータシステムの中で、又はプリンタシステムによって若しくはプリンタシステムの中で処理されるかどうかは本発明の範囲にとって重要なことではない。

図２〜図３に例示されたソフトウェアブロックには、ＸＭＬ（拡張マークアップ言語）プロセッサ７０（「ＸＭＬパーサー」とも呼ばれる）、ＸＳＬＴ（拡張スタイルシート言語変換）プロセッサ７４、ＸＳＬＦＯ（拡張スタイルシート言語フォーマッティングオブジェクト）プロセッサ７８、ビットマップ／バーコード／ＲＦＩＤレンダリングエンジン（rendering engine）８０、ＲＦＩＤトランシーバ６１及びプリンタドライバ５４（図１）が含まれる。無論、ＲＦＩＤトランシーバ６１は印刷されたラベルと共に使用されるか、又は単独で使用される。ＸＭＬシステム１０の機能及び基本的な構成は、ＲＦＩＤトランシーバを含む又は含まないことによって影響されない。

プリンタドライバ５４は、その機能が関連する処理装置の物理的な位置に依存して、コンピュータシステム１２の中の処理装置又はプリンタシステム５０の中の処理装置６０（図１）のいずれかによって実行される、前述した構成要素の実施例であることに注意されたい。繰り返すが、１つの処理装置が十分に強力である場合は、その処理装置はＸＭＬシステム１０の全ての機能を処理することができる。

ＸＭＬスキーマ容器８２（スキーマ容器）はＸＭＬプロセッサ７０に入力を与え、一方ＸＳＬＴスタイルシート容器８４（スタイルシート容器）はＸＳＬＴプロセッサ７４に入力を送る。企業資源計画（ＥＲＰ）システム８８も示されている。この企業資源計画システム８８は、例えば、ＸＭＬ入力データストリーム９０をＸＭＬプロセッサ７０に送信する倉庫管理システムとすることができる。ＥＲＰシステム８８は本質的に、バーコードラベルを印刷する又はＲＦＩＤデータをＲＦＩＤトランスポンダ６２にコード化する要求を開始し、バーコードを形成するＸＭＬデータ、ＲＦコード化データ、及び印刷又はコード化される可変のラベルフィールド又は要素フィールドを提供する。そのような可変のラベルフィールドは、例えば、幾つか又は全ての人が読取り可能なテキスト及び／又はラベル上に印刷される文字を含む。無論、どのような企業のコンピュータシステムも使用することができ、また本発明はある特定の種類の企業のコンピュータシステムと一緒に使用することには限定されない。

ＸＭＬデータを参照する場合、本願では２つの基本的な種類、すなわちＸＭＬ値のデータ及びＸＭＬ要素名が参照される。ＸＭＬ値のデータは、変更可能なデータすなわちデータ「１１２２グリーンストリート（1122 Green Street）」などの、バーコードラベル上に印刷される又はＲＦＩＤトランスポンダにコード化されることが望まれるデータである。このデータは、例えば、出荷住所に対応するＸＭＬ値のデータの一部である。ＸＭＬ要素名は、任意のラベル又は要素名が選択されてＸＭＬ値のデータを表すようなＸＭＬ言語のセマンティクスの一部である。その使用については、ＸＭＬ言語によって定義される。一般に、要素名は、角カッコの間に現れる（「＜要素名＞」）。

上述したように、周知のバーコードラベル及び他の自動識別システムは、専有のソフトウェアコード化方式を使用することが多い。さらに、そのような方式はエラーをもたらすことが多く、また下にある値のデータは通常、非技術系の人は読み取ることができない。既知のシステムでは、企業のシステムから送られた下にある値のデータの中にエラーが存在する場合、又はデータを見失う若しくはデータが正しくない場合、バーコードシステムは行うように命令されたことを印刷又はコード化するが、これは無論、バーコードラベル又はＲＦＩＤトランスポンダの中にエラーを発生させて、不正確な又は役に立たないものにしてしまう。

その上、コンプライアンスラベリング（compliance labeling）を処理するときに、既知のシステムはラベルの形式又は内容がコンプライアンスラベルの要求に従って変化するときに、コード化しているデータの中に大きな変更を要求する。バーコード又はＲＦＩＤトランスポンダの形式又は内容のそのような変更は、繰り返すがエラーを受け易く、このことは今度は、コンプライアンスを要求する事業体によって金銭的な罰金を要求される可能性がある。バーコードラベリングシステム内で問題が続くことによって、特にそのようなエラーがコンプライアンスを要求する者の事業を混乱させる場合、事業関係が損傷を受けることもある。

本願のＸＭＬシステム１０は、オープンフォーマット（open format）を使用する。特に、バーコードラベル又はＲＦＩＤトランスポンダのフォーマッティングに関する要求事項及び形式は、ＸＭＬ言語の中で全て定義される。その上、ＸＭＬはよく定義され全ての人が利用することができるだけでなく、プログラマでない人も最小の教育を受けるだけで、ＸＭＬのデータストリーム又はファイル（又はハードコピー）の中のデータ及び命令を理解することができる。

図２〜図３に示した様々なＸＭＬのソフトウェアブロックは市販されている。幾つかの異なる市販のＸＭＬプロセッサ７０は、互換性があるように又はほとんど修正せずに使用することができる。例えば、下記の市販のＸＭＬプロセッサ７０、すなわちIBM Corporationから入手可能な「XML for C++」、Microsoft Corporationから入手可能な「MSXML3」、Oracle Corporationから入手可能な「Oracle XML Developers Kit for C」、Thai Open Source Software Center, Ltd.から入手可能な「Expat」、又はApache Software Foundationから入手可能な「Xerces-C++」を使用できる。しかしながら、任意の適当なＸＭＬプロセッサも使用できる。

同様に、幾つかの種々の市販のＸＳＬＴプロセッサ７４は、互換性があるように又はほとんど修正せずに使用することができる。例えば、下記のＸＳＬＴプロセッサ７４，すなわちInfoteria Corporationから入手可能な「iXSLT」、Microsoft Corporationから入手可能な「MSXML3」、及びGnomeから入手可能な「Libxslt」を使用できる。しかしながら、任意の適当なＸＳＬＴプロセッサも使用できる。

また一方、幾つかの色々な市販のＸＳＬＦＯプロセッサ７８は、互換性があるように又はほとんど変更せずに使用することができる。例えば、下記のＸＳＬＦＯプロセッサ７８，すなわちRenderX Corporationから入手できる「XEP」、Antenna House Corporationから入手できる「XSL Formatter」、及びApache Software Foundationから入手できる「FOP」を使用できる。しかしながら、任意の適当なＸＳＬＦＯプロセッサも使用できる。

さらに図１〜図３を参照すると、プロセッサ７０は、外部ソース８８からＸＭＬ入力データストリーム９０を受け取る。例えば、この外部ソースは、倉庫管理システムなどのＥＲＰシステム８８とすることができる。ＸＭＬプロセッサ７０は本質的にＸＭＬ入力データストリーム９０を解析及び処理して、この技術分野では周知の「ツリー」構造のノードの組を発生する。図２〜図３に示されたソフトウェア処理ブロックの各々は「ツリー」のノード上で動作して、自分達の要求された機能を実行する。ＥＲＰシステム８８からのＸＭＬ入力データストリーム９０の中に含まれる下にある値のデータが処理されて、このデータを保持する「ラベル値ノードツリー」１００の中に入力される。

以下は様々なソフトウェア構成要素の動作の概要である。始めに、ＸＭＬ入力データストリーム９０は、他の必要なＸＭＬ文書又はファイルの名前及び位置を識別するテキストを含むことに注意されたい。１つのそのような文書は、「ＸＭＬスキーマ」又は「スキーマ」と呼ばれる。このスキーマは、下にある値のデータを含むＸＭＬ入力データストリームを確認するために使用される。この確認に合格すると、後で説明するが、スタイルシートが加えられる。スタイルシートの名前及び位置も、ＸＭＬ入力データストリーム９０の中で規定される。スタイルシートを適用することは、スタイルシートの指示のもとにＸＳＬＴプロセッサ７４によって処理され、下にあるＸＭＬ要素名及び／又は下にある値のデータを変換する。次に、データは、下にある値のデータのフォーマッティング及び「レイアウト」を処理するＸＳＬＦＯプロセッサ７８によって処理される。これには、例えば、フォントの種類、フォントの寸法、色などに基づいて下にある値のデータをフォーマットすることが含まれる。次に、下にある値のデータが、ビットマップ／バーコード／ＲＦＩＤレンダリングエンジン８０によって処理される。このレンダリングエンジン８０は、バーコードラベルのビットマップ９２、又は変換及びフォーマットされたデータに対応するＲＦＩＤトランスポンダに対するプログラミングコードのシーケンスを作り出す。レンダリングエンジン８０はスタイルシートの中に存在する「流入外来オブジェクト（instream foreign object）」を利用して、ビットマップの作成を方向付けることができる。ビットマップ９２は、次に、バーコードプリンタによってバーコードラベルを印刷するためにプリンタ用ドライバ５４（図１）に送られるか、又はＲＦＩＤトランスポンダ６２（図１）の中にコード化するためにＲＦＩＤトランシーバ６１に送られる。

前述したように、スキーマは、入力データストリーム９０の全体、特にエラーが一般的に発見される下にある値のデータを確認するような役目をする。実際には、エラーはバーコードラベルの形式又は内容に対して変更が行われる場合に、気が付かずに発生することが多い。

スキーマ文書の名前及び位置は、ＸＭＬ入力データストリーム９０の中に含まれる。このＸＭＬ入力データストリーム９０は、バーコードラベルを印刷及び／又はコード化するという要求に対応する。ＸＭＬプロセッサ７０はスキーマ検証モジュール１１０と連動して、下にある値のデータを確認する。スキーマを使用することは、スキーマが最終的な出力、すなわちバーコードラベル、「出荷ラベル」、又はＲＦＩＤタグのトランスポンダに関連するエラー及び脱落を防ぐため経済性に優れる。

ＸＭＬ入力データストリーム９０がエラーのために拒否されるすなわちフラグを立てられる場合、エラーメッセージがソース８８に送り返される。これによりエラーを訂正するために、フラグを立てたり人が介入するように促す。例えば、この特定の実施例では、ソースはＥＲＰシステム８８である。この方法では、データは最初に処理する前に点検されて、このデータが全ての要求されたラベル及びバーコードの規定に確実に適合するようにする。

これはコンプライアンスラベリングを処理する場合、特に有益である。既知のシステムでは、コンプライアンスの要求者は、供給業者にコンプライアンスラベリングに関する要求事項の変更を単に通知するだけである。ここで、供給業者がこれらの変更又は命令を解釈又は実行する場合にエラーを犯すと、コンプライアンスの要求者に向けて出荷される製品に付けられる作成されたラベル又はコード化されたＲＦＩＤトランスポンダにはエラーが含まれることになるため、将来の取引を危険にさらしたり、金銭的な罰金が加えられる可能性がある。

本発明では、コンプライアンスの要求者は、スキーマ及び／又はＸＳＬＴのスタイルシートに直接変更を加えることが好ましい。例えば、ラベルの物理的なレイアウトが変更される場合又は要素名が変更される場合、コンプライアンスの要求者はＸＳＬＴスタイルシートを変更することになる。同様に、下にある値のデータが加えられる又は削除される又は別の状況では制限される場合（例えば、郵便番号に対する新しい受け入れられる数値範囲）、コンプライアンスの要求者はスキーマを変更できる。この方法では、供給業者は単にそのＥＲＰシステム８８の出力を変更するだけで、その出力は確実に変更されたＸＭＬ入力データストリーム９０に適合する。ラベルの物理的なレイアウトのみが変更される場合、供給業者はどのような変更も全く行う必要はない。

例えば、コンプライアンスの要求者がここで、９桁の郵便番号を最初の５桁の郵便番号の代わりに使用するように要求するとする。それに応じて、コンプライアンスの要求者はスキーマを変更して、第１及び第２の両方の郵便番号フィールドを要求する。また、第２のフィールドは、恐らく００００〜９９９９のようにある範囲内の数字の桁に制限される。コンプライアンスの要求者はスタイルシートを変更して、その変更を受け入れることもできる。それに応じて、供給業者は加えられた郵便番号フィールドをそのＥＲＰシステムの中に挿入して、それがＸＭＬシステム１０に送られたＸＭＬ入力データストリーム９０の中に現れるようにする必要がある。ＸＭＬ入力データストリーム９０に対するそのような変更が正確に実行されない場合、スキーマはＥＲＰシステム８８に報告されるエラーを発生することになるため、ラベルは印刷されず又はＲＦＩＤトランスポンダはコード化されない。

したがって、供給業者は容器８２，８４から変更されたスキーマ及び／又はスタイルシートにただアクセスしさえすればよい。この変更されたスキーマ及び／又はスタイルシートは受信される場合は自動的に下にある値のデータに加えられる。本質的に、バーコードラベル又はＲＦＩＤトランスポンダの形式及び内容に対する小さい変更及び極めて大きな変更は供給業者には見えない。また、そのようなバーコードラベル又はＲＦＩＤトランスポンダの内容に対する変更は、スキーマに基づいて検証される。これにより、供給業者は、コンプライアンスの要求者によって指示されたバーコードラベル又はＲＦＩＤトランスポンダの形式又は内容を変更するための費用を負担する必要はなく、またそのような変更を実施する場合にどのようなエラーも発生しない。何らかのエラーが存在する場合は、そのようなエラーはコンプライアンスの要求者が気付かずに作ってしまったものであり、この場合、コンプライアンスの要求者は供給業者を非難することはできない。

スキーマ文書は、ＸＭＬスキーマ容器８２から得られることが好ましい。１つの特定の実施形態では、スキーマ容器８２はＸＭＬシステム１０及びコンピュータシステム１２の外部にあり、このコンピュータシステムが接続されているネットワークすなわちインターネット又は任意の適当なネットワーク４３，４４を介してアクセスすることができる。スキーマ容器８２は、複数のスキーマ文書を含むことができる。このため、バーコードラベル又はＲＦＩＤトランスポンダを作成する様々な要求を表すＸＭＬ入力データストリーム９０は、容器８２の中の対応するスキーマの名前及び位置をそれぞれ指定することができる。ＸＭＬプロセッサ７０が要求を受け取ると、対応するスキーマがスキーマ容器８２から検索される。

別の実施形態では、スキーマ容器８２からネットワーク４２，４３を経由して得られたスキーマは他の場所で保持することができ、このためハードディスク１８又はデータベース２２などのメモリサブシステム２６（図１）の中に一時的に置くことができる。この方法では、同じスキーマが複数のＸＭＬ入力データストリーム９０又は直ぐ後のバーコードラベルの要求に対して使用される場合、ＸＭＬプロセッサ７０はネットワーク４２，４４を介して外部にある同じスキーマを検索する必要はなく、メモリサブシステム２６からそのスキーマを検索することができるため、より効率的である。この実施形態によれば、コンプライアンスの要求者は、ある時間においてのみ外部の容器８２の中のスキーマを変更又は修正することができる。例えば、コンプライアンスの要求者は、毎日午前１時にだけスタイルシートを変更することができる。このため、供給業者は、容器８２からメモリサブシステム２６の中に１日１回だけ、例えばコンプライアンスの要求者がスキーマの更新を行った後で、スキーマを更新すればよい。次に、供給業者は、メモリサブシステム２６の中に一時的に保管されたスキーマが、少なくとも更新が行われるように計画される時間までは最も新しいスキーマ文書であることが分かる。

スキーマが得られる位置には関係無く、スキーマ検証モジュール１１０は下にあるデータの照合及び検証を行う。このスキーマ検証モジュール１１０は、図２ではＸＭＬプロセッサ７０とは別のブロックとして示されているが、それは単に例示する目的のためにこの位置に示されているのであり、図面上でスキーマ検証モジュールが実行するデータであるラベル値ノードツリー１００に隣接して示すこともできる。しかしながら、このスキーマ検証モジュール１１０はＸＭＬプロセッサ７０の一部としてそれに組み込むこと、又はＸＭＬプロセッサ７０とは別個にして離すこともできる。

無論、スキーマもＸＭＬ文書であり、このためそれもＸＭＬプロセッサ７０によって処理される。従って、スキーマの処理結果は図３に示したＸＭＬスキーマノードツリー１１４であり、これは処理されたスキーマの「メモリ表示」又はワーキングモデルである。このＸＭＬスキーマノードツリー１１４は、この技術分野では周知の「文書オブジェクトモデル」（ＤＯＭ）の形式とすることができる。さらに、ＸＭＬスキーマノードツリー１１４は、ＸＭＬスキーマキャッシュ１１６の中に示されるように、効率を上げるためにキャッシュメモリの中に存在することができる。スキーマ検証モジュール１１０及び／又はＸＭＬプロセッサ７０はＸＭＬスキーマノードツリー１１４の中のデータ上で動作して、スキーマ文書に基づいて下にある値のデータを検証するその機能を実行する。

前述したように、エラーがＸＭＬ入力データストリーム９０の中に存在するとスキーマを適用することにより判断された場合、エラーメッセージが生成される。ＸＭＬ入力データストリーム９０が検証される場合、データは事実上「手付かずの」ままである。次に、ラベル値ノードツリー１００の中のデータが、ＸＳＬＴスタイルシートを用いてＸＳＬＴプロセッサ７４によって処理される。

別の方法では、下にある値のデータの検証が、スキーマを使用することではなく、文書様式定義（Document Type Definition）（ＤＴＤ）フォーマットに基づいて実行される。ＤＴＤを使用することは、この技術分野では周知のように、様々なＸＭＬ仕様書の中で詳細に規定されている。

スタイルシート文書は、ＸＳＬＴスタイルシート容器８４から得ることが好ましい。１つの特定の実施形態では、スタイルシート容器８４はＸＭＬシステム１０及びコンピュータシステム１２の外部にあり、このコンピュータシステムが接続されているネットワークすなわちインターネット又は任意の適当なネットワーク４３，４４を介してアクセスすることができる。スタイルシート容器８４は、複数のスタイルシートを含むことができる。このため、バーコードラベル又はＲＦＩＤトランスポンダを作成する様々な要求を表すＸＭＬ入力データストリーム９０は、容器８４の中の対応するスタイルシートの名前及び位置をそれぞれ指定することができる。ＸＭＬプロセッサ７０が要求を受け取ると、対応するスタイルシートがスタイルシート容器８４から検索される。

別の実施形態では、スタイルシート容器８４からネットワーク４３，４４を経由して得られたスタイルシートは他の場所で保持することができ、このためハードディスク１８又はデータベース２２などのメモリサブシステム２６（図１）の中に一時的に置くことができる。この方法では、同じスタイルシートが複数のＸＭＬ入力データストリーム９０又は直ぐ後のバーコードラベル又はＲＦＩＤトランスポンダの要求に対して使用される場合、ＸＭＬプロセッサ７０はネットワーク４３，４４を介して外部にある同じスタイルシートを検索する必要はなく、メモリサブシステム２６からそのスタイルシートを検索することができるため、より効率的である。

この実施形態によれば、コンプライアンスの要求者は、ある時間においてのみ外部のスタイルシート容器８４の中のスタイルシートを変更又は修正することができる。例えば、コンプライアンスの要求者は、毎日午前１時にだけスタイルシートを変更することができる。このため、供給業者は、スタイルシート容器８４からメモリサブシステム２６の中に１日１回だけ、例えばコンプライアンスの要求者がスタイルシートの更新を行った後で、スタイルシートを更新すればよい。次に、供給業者は、メモリサブシステム２６の中に一時的に保管されたスタイルシートが、少なくとも更新が行われるように計画される時間までは最も新しいスキーマ文書であることが分かる。

無論、スタイルシートもＸＭＬ文書であり、このためそれもＸＭＬプロセッサ７０によって処理される。従って、スタイルシートの処理結果は図３に示したＸＳＬＴスタイルシートノードツリー１２０であり、これは処理されたスタイルシートの「メモリ表示」又はワーキングモデルである。このＸＳＬＴスタイルシートノードツリー１２０は、この技術分野では周知の「文書オブジェクトモデル」（ＤＯＭ）の形式とすることができる。さらに、ＸＳＬＴスタイルシートノードツリー１２０は、ＸＳＬＴスタイルシートキャッシュ１２６の中に示されるように、効率を上げるためにキャッシュメモリの中に存在することができる。ＸＳＬＴプロセッサ７４はＸＳＬＴスタイルシートノードツリー１２０の中のデータ上で動作して、スタイルシートに基づいて下にある値のデータ又は下にある要素名を変換するその機能を実行する。

ＸＳＬＴスタイルシートが図３ではＸＭＬプロセッサ７０への入力として示されているが、ＸＳＬＴプロセッサ７４がこのスタイルシートを処理することに注意されたい。全てのＸＭＬ文書は最初に処理されて、その後の処理のために適当なデータ構造体の中に配置されるため、そのＸＳＬＴスタイルシートは最初にＸＭＬプロセッサ７０に送られる。

ＸＳＬＴプロセッサ７４は下にある値のデータを変更、保管、及び再配列するか、又は下にある値のデータに加えるか又は下にある値のデータの幾つかを削除する。例えば、スタイルシートの下方で、下にある値のデータをテーブル形式又は列の中に再配列することができる。特に、スタイルシートは、ＸＳＬＦＯフォーマッティング要素及び属性を加えることができる。

ラベル値ノードツリー１００の中の下にある値のデータが対応するスタイルシートに基づいて処理された後で、ＸＳＬＦＯインスタンスノードツリー（instance node tree）１３０が作られる。繰り返すが、ＸＳＬＦＯインスタンスノードツリー１３０は、この技術分野では周知の文書オブジェクトモジュールの形式にすることができる。このＸＳＬＦＯインスタンスノードツリー１３０には、ＸＳＬＦＯプロセッサ７８にフォーマッティング及びレイアウトに関して指示するＸＳＬＦＯ命令（レイアウト命令）が含まれる。次に、このＸＳＬＦＯプロセッサ７８はＸＳＬＦＯ命令を解釈し、そのような命令を下にある値のデータに適用して、この下にある値のデータを適当にフォーマット及びレイアウトする。ＸＳＬＦＯプロセッサ７８は、レンダリングの前に最終的なフォーマッティング出力を表すＸＳＬＦＯ領域ノードツリー１３０を生成する。

ここで図３に戻ると、「ＸＭＬ入力データストリーム用のコードセグメント１」という題名のコードセグメントが直ぐ下に示されている。このコードセグメント１は、ハードコピーでＸＭＬ入力データストリーム９０を例示する。これは例えば、ＥＲＰ又は倉庫管理システム８８によってＸＭＬシステム１０に送られる。行番号は単に明白にするために挿入されているものであり、コードの一部ではない。

コードセグメント１ ＸＭＬ入力データストリーム用のコードセグメント

ＸＭＬ入力データストリームはスキーマ文書を「ShipLabels.xsd」として識別し、この特定の実施例では、そのスキーマ文書は、コードセグメント１の中の行７に示すように、「D:/Projects/XML/Native/Docs」と呼ばれるディレクトリの中に見出すことができる。さらに、このＸＭＬ入力データストリームは、スタイルシート文書を「ShipLabels.xsl」として識別し、そのスタイルシート文書はまた、コードセグメント１の行３に示すように、「D:/Projects/XML/Native/Docs」と呼ばれるディレクトリの中に見出すことができる。無論、スキーマ文章及びスタイルシート文書は、例えばインターネットのアドレスによって識別されるようなどのような場所にでも配置することができる。

この特定の実施例は、印刷される３つの出荷ラベルに対する下にある値のデータ及び要素名を示す。各出荷ラベルは、次のような、すなわち、<name>、<address>、<city>、<state>、及び<zip>などの角ブラケットの間で定義されたＸＭＬ要素名を含む。第１の要素名<name>の値は「Albert Einstein」であり、第２の要素名<address>の値は「1234 Relative Way」、第３の要素名<city>の値は「Princeton」、第４の要素名<state>の値は「NJ」、また第５の要素名<zip>の値は「08540」である。これは下にある値のデータである。

ここで図３、コードセグメント１、及び「ＸＭＬスキーマ用のコードセグメント２」という名称のこの直ぐ後に示されるコードセグメントを参照する。このコードセグメント２は、コードセグメント１のＸＭＬ入力データストリームの中で規定されたＸＭＬスキーマ文書の形式のＸＭＬ文書の特定の実施例を例示している。行番号は、単に説明のために挿入されているものであり、コードの一部ではない。

コードセグメント２ ＸＭＬスキーマ用のコードセグメント

前述したように、スキーマは下にある値のデータを検証するために使用される。このことは、全ての必要なデータが存在すること、無関係のデータは存在しないこと、存在するデータは特定の範囲内にあることなどを判断するために調査を行う必要がある。任意の適当な検証方式が、アプリケーションに基づいてスキーマの中で指定される。ＸＭＬ言語がよく使用され、コードが極めて多数の要求事項を処理するために記述される。

例えば、上記のコードセグメント２の中で示したスキーマ文書は、要素名<address>に対応する下にある値のデータが、コードセグメント２の行５で示すように、ＸＭＬスキーマ仕様の中で定義されたようにストリングでなければならないと規定している。このスキーマ文書は、<name>、<address>、<city>、<state>、及び<zip>の要素名に対応する下にある値のデータは、コードセグメント２の中の行９〜１５によって示されたように指示された順序で存在しなければならないとも規定している。さらに、コードセグメント２で示されたこの特別なスキーマ文書は、要素ネーム<state>に対応する下にある値のデータが３つの州、すなわち「ＣＡ」、「ＮＪ」、又は「ＮＹ」の１つでなければならないと規定する。無論、これは単に短縮された実施例であり、専ら説明の目的であるため全ての州を含んではいない。コードセグメント２で示されたスキーマ文書は、要素名<zip>に対応する下にある値のデータが０００００から９９９９９の範囲になければならないとも規定している。ＸＭＬ入力データストリームの中のデータが上述したスキーマ基準のいずれかに適合しない場合は、スキーマ検証モジュール１１０はそれを不合格にして、エラーメッセージをソース８８に送り返すことが好ましい。

ここで、図３、コードセグメント１〜２、及び「ＸＳＬＴスタイルシート用のコードセグメント３」という題名の直ぐ後に示したコードセグメントを参照する。このコードセグメント３は、コードセグメント１のＸＭＬ入力データストリームの中で規定されたＸＳＬＴスタイルシート文書の形式のＸＭＬ文書の具体的な実施例を示している。行番号は、単に説明のために挿入されているものであり、コードの一部ではない。

コードセグメント３ ＸＳＬＴスタイルシート用のコードセグメント

上述したように、スタイルシートはデータを変換するために使用される。この特定の実施例では、コードセグメント３のスタイルシートは、２種類の名前空間、すなわち「バーコード形オブジェクト」として選択される「ｂｏ」形オブジェクト、及びＸＳＬＦＯプロセッサ７８に関連して前に説明されたフォーマッティングオブジェクトとして選択される「ｆｏ」形オブジェクトを定義する。このことは、この技術分野では周知のように、異なるオブジェクト間の区別を可能にする。スタイルシートは、幾つかのデータを変換させたり又は加えることまで行うことができる。例えば、コードセグメント１のＸＭＬ入力データストリームからの下にある値のデータ、すなわち「Einstein」、「1234 Relative Way」などは、行４０〜６２に示すように挿入される。

このスタイルシートは、フォーマッティング要素又はＸＳＬＦＯオブジェクトと呼ばれる各種の「ｆｏ」形の要素も発生させる。ＸＳＬＦＯオブジェクトには、ＸＳＬＦＯプロセッサ７８が「理解」して処理するレイアウト形命令が含まれる。「ｆｏ」の接頭語を有するコードの全ての行はＸＳＬＴプロセッサ７４によって解釈されるのではなく、ＸＳＬＦＯプロセッサ７８に送られることに注意されたい。

例えば、コードセグメント３の行２１は、行２２の<fo:block break-after = "page">の後に<xsl: template match= "label">を示している。これはＸＳＬＦＯプロセッサ７８によって、コードセグメント１で指定された３つの出荷ラベルの間に「ページの区切り」を置くことと解釈される。基本的に、それぞれがコードセグメント１の中で指定された下にある値のデータを含む新しい出荷ラベルが、ページの区切りに基づいて作られる。

さらに、この特定のスタイルシートは、行３１に示すように、「流入外来オブジェクト」が挿入されることを指定する。行３１は、流入外来オブジェクトを定義する行３１〜３７と共に、<fo:instream-foreign-object>として示される。流入外来オブジェクトは、ＸＳＬＴプロセッサ７４又はＸＳＬＦＯプロセッサ７８のいずれによっても処理されないことに注意されたい。流入外来オブジェクトは、正しくは、ビットマップ／バーコード／ＲＦＩＤレンダリングエンジン８０に送られて処理される。例えば、コードセグメント３の行３２〜３６は、「postnet」バーコード要素の定義を含む<bo:barcode>要素を挿入させる。この「postnet」バーコード要素は、後でビットマップ／バーコード／ＲＦＩＤレンダリングエンジン８０によって処理される。行３４で、ＸＳＬＴプロセッサ７４は、ＸＭＬ入力データストリームからの郵便番号を<bo:postnet>要素のテキストとして挿入させる。別の方法では、コードには示していないが、ＲＦＩＤ形の流入外来オブジェクトは、ＲＦＩＤトランスポンダをプログラムするためのコード化を定義する。

ここで、図３、コードセグメント１〜３、及び直ぐ後に示された「インスタンスノードツリー表示用のコードセグメント４」という題名のコードセグメントを参照する。コードセグメント４は、コードセグメント３のスタイルシートと共に、ＸＳＬＴプロセッサ７４によって作られたＸＳＬＦＯインスタンスノードツリー１３０の出力の表示の特定の実施例を示す。この出力は、ＸＳＬＦＯプロセッサ７８に送られたＸＳＬＦＯインスタンスノードツリーの表示である。行番号は、単に明白にするために挿入されているものであり、コードの一部ではない。

コードセグメント４ ＸＳＬＦＯインスタンスノードツリー表示用のコードセグメント

上記のコードセグメント４の２つの主要な部分、すなわち行４のコード<fo:layout-master-set>で始まる第１の部分と、行９の<fo:page-sequence master-name="all-labels>で始まる第２の部分を簡潔に説明する。このコード部分は基本的に、どのようなバーコードラベルが「見える」か又はどのようにそれを「レイアウトするか」及びどのように下にある値のデータがそのレイアウトの中に現れるかについて定義する。

例えば、コードセグメント１で示した下にある値のデータをフォーマットすることに関して、行１２〜１３に示した「bold 14pt Times」及び「text-align = "left"」のフォント属性が「Albert Einstein」という下にある値のデータに加えられるため、バーコードラベルが印刷されると、「Albert Einstein」という名前が１４ポイントのタイムズ（Times）フォントで印刷され、それはバーコードラベルの左側余白に整列される。この技術分野では周知であるが、ＸＳＬＦＯプロセッサ７８が解釈する多くの種類のフォーマッティング命令を指定することができる。

さらに、ＸＳＬＦＯインスタンスノードツリー１３０のこの特定の表示の実施例には、コードセグメント４の行２１〜２６で示すように、流入外来オブジェクトが含まれるが、この流入外来オブジェクトはＸＳＬＦＯプロセッサ７８によっては処理されない。流入外来オブジェクトは、正しくは、ビットマップ／バーコード／ＲＦＩＤレンダリングエンジン８０に送られて処理される。バーコード要素の種類及びＲＦＩＤトランスポンダ要素の種類はＸＳＬＦＯの仕様の中に含まれていないため、処理におけるこの時点では、ＸＳＬＦＯプロセッサ７８はバーコードラベルを印刷する方法又はＲＦＩＤトランスポンダをコード化する方法を「知らない」ことに注意されたい。正しくは、コードセグメント１〜２に示すように、下にある値のデータすなわち「Einstein」、「1234 Relative Way」などのテキスト情報のみを、テキストとしてバーコードラベル上に印刷することができる。ラベルに関しては、ＸＳＬＦＯプロセッサ７８はバーコード記号の作り方を「知らない」ため、実際のバーコード記号は現れない。ＲＦＩＤトランスポンダは、ＸＳＬＦＯプロセッサ７８がトランスポンダをコード化する方法を「知らない」ため、コード化されることはない。

ＸＳＬＦＯプロセッサ７８による処理結果が、ＸＳＬＦＯ領域ノードツリー１４０である。コードセグメント４の中の流入外来オブジェクトはＸＳＬＦＯプロセッサ７８によって処理されないが、ＸＳＬＦＯ領域ノードツリー１４０の１つ以上のノードの中でバーコード／ビットマップ／ＲＦＩＤレンダリングエンジン８０に送られる。流入外来オブジェクトの要素は<bo:barcode>と呼ばれ、コードセグメント４の行２１〜２６に示されている。バーコード／ビットマップ／ＲＦＩＤレンダリングエンジン８０は<bo:barcode>要素を受け取り、そのブロックに含まれたコードを処理する。例えば、レンダリングエンジン８０は、行２３〜２４すなわち<bo:postnet interpretation-line="none">08540<bo:postnet>を、この特定のノードを定義するときに「postnet」バーコード形の要素であると解釈する。多くの様々な「種類」のバーコード記号を、後で説明する対応する工業規格が定義するように定義することができる。

別の方法では、流入外来オブジェクトの要素がＲＦＩＤのコード化に関係する場合、レンダリングエンジン８０は、ＲＦＩＤトランシーバ６１（図１）によりＲＦＩＤトランスポンダ６２（図２）のプログラミング及びコード化を管理する特定の規格に基づいて、この流入外来オブジェクトを解釈する。バーコードを印刷する方法を規定するＸＭＬデータの要素及び属性のように、そのような要素及び属性は、ＲＦＩＤトランスポンダ６２などのＲＦＩＤタグの中にプログラムされるテキスト及び特徴を規定することもできる。基本的に、ＲＦＩＤ形の流入外来オブジェクトに基づくレンダリングは、ＲＦＩＤトランシーバ６１（図１）の動作を管理する。このため、無線周波数信号がＲＦＩＤトランシーバとＲＦＩＤトランスポンダとの間で送信されて、ＲＦＩＤトランスポンダのプログラミングを行う。

ＲＦＩＤトランシーバの動作は、ＩＳＯ／ＩＥＣなどの国際規格に基づくか、又はTexas Instruments (Tag-it)又はPhillips (I Code)などの売り手からの自社開発の規格に従う。例えば、動作はビシニティーカード（vicinity card）については国際標準化機構（ＩＳＯ）の規格１５６９３によって、プロクシミティーカード（proximity card）についてはＩＳＯ規格１４４４３によって管理される。ＩＳＯ規格１５６９３は、物理的な特性、無線周波数の電力及び信号のインターフェース、並びに衝突防止及び送信プロトコルについて記述している。送信プロトコルの仕様には、トランスポンダを読取り、書込み及びロックするための要求及び応答が含まれる。ＩＳＯ規格１５６９３は、ＲＦＩＤラベルのタグが含まれる場合は好ましく適切な規格であることに注意されたい。

バーコード記号として印刷される下にある値のデータは、コードセグメント４の行２４に示すように数値データ「０８５４０」である。この下にある値のデータは、コードセグメント１に示したAlbert Einsteinの住所に対する郵便番号である。この特定の実施例では、郵便番号だけがバーコード記号に送信される。無論、ありとあらゆる情報が、アプリケーションに基づいてバーコード記号に送信される。また、この特定の実施例では、コードセグメント４に示した流入外来オブジェクトが、コードセグメント１に示した３つの郵便番号に関係するだけである。他の下にある値のデータは、この実施例ではバーコード記号に送信されない。

ＸＭＬシステム１０は、必ずしもＸＳＬＴプロセッサ７４を備える必要がないことにも注意されたい。別の実施形態では、ＸＳＬＴプロセッサ７４又はそれと等価な装置はＸＭＬシステム１０から遠く離れて配置され、ＸＭＬ入力ストリーム内のＸＭＬデータを変換して、この変換されたデータをＸＭＬシステムに提供するように構成される。このため、ＸＭＬシステム１０は変換されたＸＭＬデータを受け取り、フォーマットされたＸＭＬデータに処理することができる。一般にＸＳＬＴプロセッサによって取り扱われた処理に相当する遠く離れたすなわち「別個の」処理は、スタイルシートに含まれたＸＳＬＦＯ命令に基づいている。この命令は、ＸＭＬシステム１０の中に存在する必要はなく又はそれに直接アクセス可能である必要もない。

ここで、コードセグメント４と共に図２〜図４を参照して、バーコード／ビットマップ／ＲＦＩＤレンダリングエンジン８０及び流入外来オブジェクトの処理に関する付加的な詳細を述べる。前述したように、レンダリングエンジン８０は、ＸＳＬＦＯプロセッサ７８が発生したＸＳＬＦＯ領域ノードツリー１４０の各ノードを処理する。この技術分野では周知のように、ＸＳＬＦＯ領域ノードツリー１４０は、文書オブジェクトモデルとしてメモリの中に表される。このため、多数のノードが存在できる。例えば、あるノードは流入外来オブジェクトを含み、他のノードは関連する要素名を、別のノードは関連するテキストデータを、別のノードは関連する属性を、等々を含むことができる。

図４のブロック１５０に示すように、ＸＳＬＦＯ領域ノードツリー１４０のノードが処理される。特に、レンダリングエンジン８０は、対応する流入外来オブジェクトによって定義された実際のバーコード記号又はＲＦＩＤのコード化を提供又は生成する方法を「知っている」。市販のＸＳＬＦＯプロセッサは、バーコード記号及びＲＦＩＤトランスポンダを表示するそのような流入外来オブジェクトを処理する方法を「知らない」ため、バーコード記号を生成又は提供すること又はＲＦＩＤトランスポンダをコード化することはできない。しかしながら、市販のＸＳＬＦＯプロセッサは、容認できる方法でテキストを提供することができ、またある種の流入外来オブジェクトさえも提供することができる。

特定のノードが流入外来オブジェクトを含まない場合は、それが例えばテキストデータを含み、次にこのノードが、ブロック１５４で例示するように、レンダリングエンジン８０ではなくＸＳＬＦＯプロセッサ７８の処理能力を利用することによる「標準的な」方法で処理されることを意味する。１つの実施形態では、非流入外来オブジェクト（non-instream foreign object）がＸＳＬＦＯプロセッサ７８に送り「戻される」、又はＸＳＬＦＯプロセッサは、ＸＳＬＦＯ領域ノードツリー１４０の中の特定のノードがそれによって処理するのが適当であると知らされる。

非流入外来オブジェクトを含むＸＳＬＦＯ領域ノードツリー１４０におけるノードの処理は、前述したように、ＸＳＬＦＯプロセッサ７８によって行われる。無論、種々の市販のＸＳＬＦＯプロセッサは、適当を例えば別のフォーマットに変換する。例えば、前述したAntenna House Corporationから入手できる「ＸＭＬフォーマッタ」と呼ばれるＸＳＬＦＯプロセッサは、ノードをWINDOWS（登録商標）の「装置独立形ビットマップ」フォーマットにする。前述したRenderX Corporationから入手可能な「ＸＥＰ」と呼ばれるこのＸＳＬＦＯプロセッサは、ノードを「ＰＤＦ」フォーマットにし、前述したApache Software Foundationから入手可能な「ＦＯＰ」と呼ばれるＸＳＬＦＯプロセッサは、ノードを「ＰＤＦ」フォーマットにすることもできる。

ＸＭＬシステム１０は、Apache Software Foundationから入手できる「ＦＯＰ」形のＸＳＬＦＯプロセッサ７８を利用することが好ましい。その理由は、このＸＳＬＦＯプロセッサは、処理することができない流入外来オブジェクトに直面する場合、サブルーチン又は他の処理機能を「呼び出す」ように構成されているからである。特に、このＸＳＬＦＯプロセッサは、処理することができない流入外来オブジェクトを取り扱うために、本願で説明されたレンダリングエンジンのソフトウェアブロック８０を呼び出すように設定される。

次に、ブロック１６０に示すように、ノードがバーコード又はＲＦＩＤトランスポンダを表示する流入外来オブジェクトを含み、ＸＳＬＦＯプロセッサ７８がこのバーコード又はＲＦＩＤトランスポンダを処理することができない場合、レンダリングエンジン８０は流入外来オブジェクトがＸＭＬシステム１０に固有の「namespace」を持っているかどうかを判断するために検査する。例えば、レンダリングエンジン８０は、流入外来オブジェクトに関連するnamespaceが「Zebra Technologies Corporation namespace」に対応するかどうかを決定するために検査する。namespaceの表記は、この技術分野では周知である。これはコードセグメント４の行３に、「xmlns:bo="http://www.zebra.com/2002/XSL/Barcode">」として示されている。このため、コードセグメント４に示すように、上記のように定義されたnamespaceが「bo」の接頭語を有する全ての要素に与えられる。この時、そのような「bo」の接頭語を有する要素は、レンダリングエンジン８０が処理するために利用できる。この「bo」接頭語形の要素は、バーコード形の流入外来オブジェクトに対応する。ＸＳＬＦＯプロセッサ７８は、そのような要素を処理する方法を「知らない」。

流入外来オブジェクトが適当なnamespaceに関連していない場合は、それはバーコード形の流入外来オブジェクトではないと仮定して、ＸＳＬＦＯプロセッサ７８に送り戻される。それは、ＸＳＬＦＯプロセッサは幾つかの限られた数の流入外来オブジェクトを処理することができるからである。このことは、ブロック１６０からブロック１５４への矢印１６２によって示される。しかしながら、一般に、流入外来オブジェクトに関連したデータが（バーコードのように）本質的に極めて独特であるという具体的な理由のために、流入外来オブジェクトが存在する又は作られる。このため、多くの市販の又は汎用のＸＳＬＦＯプロセッサはそれらを処理することはできない。

本願に記載された市販のＸＳＬＦＯプロセッサは、必ずしも全ての流入外来オブジェクトを処理することができないことはない。しかしながら、それらのプロセッサは、バーコード記号及びＲＦＩＤのコード化に対応する流入外来オブジェクトを処理することはできない。

流入外来オブジェクトが適当なnamespaceを有していると仮定すると、ブロック１７０はバーコードの種類を決定するために、流入外来オブジェクトの中の要素を判断する。例えば、流入外来オブジェクトがコードセグメント４の行２１〜２６に示されている。より具体的には、バーコードに対応する正しいnamespaceを示す「bo」の接頭語を有するバーコード要素が、コードセグメント４の行２３〜２４に示すように、「postnet」というバーコードの種類を持つように示されている。これは、<bo:postnet interpretation-line="none">08540</bo:postnet>のように示される。コードセグメント４の行４１〜４２は、別の流入外来オブジェクトに対する同様のバーコード要素、すなわちコードセグメント１の中に示した「Steven Hawking」の住所に対応する次の印刷すべきバーコードラベルを示す。

どのようなバーコードの種類も、アプリケーションに基づいて流入外来オブジェクトの中で規定することができる。バーコードの種類は、周知のバーコードの規格に基づいている。例えば、バーコードの種類はバーコード記号のpostnet形に限定されることはなく、例えば、「Industrial 2 of 5」、「PDF 417」、「UPC」などに基づく。バーコードの「種類」は、バーの厚さ、バー間の空間の幅に対するバーの厚さの比率など印刷されるバーコード記号の基本的な構造を規定する。各特定の周知のバーコード規格が、具体的に定義される。

次に、バーコードの種類が流入外来オブジェクトから確認された後で、この流入外来オブジェクトの属性が解釈されて、ブロック１７６に示すようにバーコードの特性が決定される。この特性は、バーコード記号が作成される方法を変更することができる。例えば、「postnet」形バーコードの１つの属性は、コードセグメント４の行２３〜２４に「interpretation-line="none"」として見ることができる。この技術分野では周知のように、「interpretation-line="none"」は、特定のバーコード記号と一緒には対応する人が読むことができるテキストは発生されないことを意味する。バーコード要素に関連する属性の別の実施例はバーコード記号の高さであり、これはまた流入外来オブジェクトの中で属性として規定される。

流入外来オブジェクトから得たバーコードの種類及び属性を用いて、レンダリングエンジン８０は次に、ブロック１８０に示すように、バーコード記号に変換される実際のノードのテキストデータを得る。この実施例では、実際のバーコードデータは、コードセグメント４の行２４で逆角カッコ間に示されたように（>80540<）、郵便番号「80540」である。数値データ「80540」からバーコード記号の（例えば、線形バーコード用の）線すなわちバーを表すビットマップへ物理的に変換することは、例えばZebra Technologies Corporationで市販されているバーコードラベルプリンタの中に含まれたソフトウェアルーチンによって実行される。そのような適当なバーコードプリンタは、例えば、Xi シリーズのバーコードプリンタ、90XiIII Plus、96XiIII Plus、140XiIII Plus、170XiIII Plus、220XiIII Plus、2800 シリーズのバーコードプリンタ、モデル Z4M、Z6M、105SL バーコードプリンタ、モデルR4Mplus、R402、R-140プリンタ／エンコーダなどとすることができる。Zebra Technologies Corporationから市販されているバーコードプリンタの中に含まれたこうした周知のソフトウェアルーチンすなわちアルゴリズムは、極めて効率的であるため、バーコードが高速に印刷される。

線形バーコードについては、テキストデータを一連の白黒のバーに変換することによって、ビットマップが作られる。これらの白黒のバーの相対的な幅は、バーコード記号に対する工業規格に適合している。テキストデータは、バーコードがバーコードスキャナによって読み取られるときに、バーコードの検証を可能にするためにコード化の前に加えられるチェック文字を有する。このチェック文字は、使用する記号に基づいて必要な場合又は任意な場合がある。記号をコード化する要求事項に従って、バーはバーのモジュールにグループ化される。テキストデータは、記号に基づいてコード化の間に圧縮される。記号の仕様により定義されるように、バーは１つ以上の「ファインダ」バーに先行する及び／又はそれらの後に続く。

記号によって要求される適当なコード化及び適当な物理的な寸法に必要な場合、別のアルゴリズムを適用することができる。バーの長さ、細いバーの幅、太いバーの細いバーに対する比率、及び他の記号に特有なパラメータは、ＸＭＬデータの中の属性によって規定される。さらに、バーコードのビットマップは、ＸＭＬデータ内の属性で指定するように回転することができる（通常は９０°刻み）。

二次元のバーコードについては、ビットマップはテキストデータを種々の独特な記号アルゴリズムに基づいてビットパターンに変換することによって与えられる。二次元のバーコードは一般に、線形のバーコードよりも多くのテキストデータをコード化することを可能にする。コード化アルゴリズムには、例えば、データ圧縮、エラーチェック及び補正、データの冗長度レベルの変更、モジュール化、ファインダのパターン、並びに記号が定義する他のアルゴリズムが含まれる。ユーザが指定可能な記号特有のパラメータは、ＸＭＬデータ内の属性によって指定することができる。この場合、記号アルゴリズムによって生成されたビットマップは、ＸＭＬデータの中の属性が指定するように拡大及び／又は回転することができる。

ブロック１８０によってバーコード記号を表示するビットマップが一旦生成されると、そのビットマップは次に「マスタ」ビットマップすなわち「ラベル」ビットマップ１８４の中に配置されるか又はそれと併合される。このラベルビットマップは、ブロック１８２に示すように、出荷ラベル全体の像を示している。この出荷ラベルには、人が読めるテキスト、他のテキスト又は文字、及びバーコード記号が含まれる。前述したビットマップを分離する、すなわちテキスト用のビットマップ及びバーコード記号用のビットマップとすることができるし、処理が進むにつれて１つのマスタビットマップを使用する又は「配置する」こともできることに注意されたい。その点において、レンダリングエンジン８０が動作するツリーすなわちデータ構造体は「ＸＳＬＦＯ領域ノードツリー」と呼ばれ、それは種々の「領域」を含むことを意味することに注意されたい。そのような領域は、様々な又は個別のビットマップ又はビットマップ部分に対応する。しかしながら、任意の数の適当なビットマップ構造体も使用できる。ビットマップの正確な構造又は構成又はビットマップの数は、本発明の範囲に該当しない。

例えば、ＸＳＬＦＯプロセッサ７８はテキストを生成するときに、「その」テキストをある特定のビットマップの中に配置することがある。そのようなテキストは、前述した名前「Albert Einstein」に対応する。このテキストはまたバーコード記号と一緒に出荷ラベルに印刷されるため、「マスタ」すなわち「ラベル」ビットマップ１８４は全ての要素ビットマップを含むことになる。最終的な「マスタ」ビットマップ１８４は次にプリンタドライバ５４（図１）に送られて、出荷ラベルが印刷される。

ここで、図４〜図５を参照する。図５はコードセグメント１で指定した第１のバーコードの出荷ラベルに対する前述した処理の最終的な出力の表示１９０である。テキストデータが対応するスタイルシートに基づいて与えられてフォーマットされ、一方郵便番号１９２も前述したように、レンダリングエンジン８０によってバーコード記号の形式で与えられる。単に例証するために、図５に示したフォントの寸法又はフォントの種類は、コードセグメント３で示した対応するスタイルシートの中で指定されたものと同じではないことに注意されたい。

ブロック１７０に戻ってそれを参照する。流入外来オブジェクトが適当なnamespaceを有していると仮定すると、この流入外来オブジェクトがバーコード形でない場合は、ブロック１７０で流入外来オブジェクトの中の要素が解釈されて、それがＲＦＩＤ形であるかどうかが判断される。任意のバーコードの種類を前述したように流入外来オブジェクトの中で指定できるのと同様に、任意のＲＦＩＤトランスポンダの種類もアプリケーションに基づいて流入外来オブジェクトに中で指定することができる。ＲＦＩＤトランスポンダの種類は、周知のＲＦＩＤ規格に基づく。例えば、ＲＦＩＤの種類はＩＳＯ１５６９３ＲＦＩＤコード化の種類に限定されることはなく、例えば、Tag-it 又は I- Code ＲＦＩＤコード化の種類などであっても良い。ＲＦＩＤの種類は、データの記憶容量、データのアドレス指定方式、送信周波数、受信周波数、製造番号及びデータロッキングなどの独自の特徴などの、コード化されるＲＦＩＤデータの基本構造を指定する。それぞれの特定された既知のＲＦＩＤ規格は、前述したように具体的に定義される。

次に、流入外来オブジェクトがＲＦＩＤ形であると決定された後で、流入外来オブジェクトの属性が解釈されて、ブロック１８３に示すように、ＲＦＩＤトランスポンダの特性が決定される。どのブロックに書き込むか、ブロックをライトプロテクト（ロック）するかどうか、書込みの失敗をリトライするかどうか、プログラミングの間にトランシーバのアンテナの下のタグの位置決めなどの、ＲＦＩＤトランスポンダをコード化する方法を、この特性は変更することができる。

流入外来オブジェクトから得られたＲＦＩＤトランスポンダの種類及び属性を用いて、レンダリングエンジン８０は次に、ブロック１８５に示すように、ＲＦＩＤトランスポンダのコード化に変換される実際のノードのテキストデータを得る。例えば、実際のＲＦＩＤのコード化は郵便番号「08540」とすることができる。この郵便番号は、ＡＳＣＩＩ文字として「Tag-it」トランスポンダのブロック０及び１に配置することができる（「Tag-it」の各ブロックが４バイトのデータを保持するため）。Tag-itトランスポンダは、それぞれが４バイトのデータを有する８つのブロックすなわち全体で３２バイトのユーザデータを保持することができる。実際のＲＦＩＤコード化データを表す数値データからＲＦＩＤトランスポンダの中のコード化するために適当な形式への物理的な変換は、例えばZebra Technologies Corporationで市販されているプリンタ及びシステムの中に含まれたソフトウェアルーチンによって実行される。

例えば、モデルR-140及びモデルR402などの幾つかのバーコードプリンタ／エンコーダを使用することができる。Zebra Technologies Corporationから市販されているシステムの中に含まれたそのようなソフトウェアルーチンすなわち「固有のアルゴリズム（native algorithm）」は極めて効率的であり、このため、バーコード及びＲＦＩＤトランスポンダのコード化は高速で実行される。

ＲＦＩＤトランスポンダのコード化が一旦ブロック１８５によって生成されると、ブロック１８７に示すように、ＲＦＩＤ固有のデータ構造が与えられる。このブロックは、前述したように、ＲＦＩＤ固有のデータ構造をＲＦＩＤ固有のプリンタアルゴリズムを用いてＲＦＩＤトランスポンダに与えて、ＲＦＩＤトランシーバ６１（図１）を制御して、ＲＦＩＤトランスポンダ６２（図２）の読取り及びコード化を行う。このことは基本的に、プログラム可能なメモリ装置がプログラムされるのとほぼ同様な方法でＲＦＩＤトランスポンダを「プログラムする」。

ここで、図６を参照すると、別の実施形態が示されている。同じ構造体を示すために、同じ参照番号が使用される。この特定の実施形態では、ＸＭＬシステム１０は全ての場合にＸＭＬプリンタ装置を含む又は特に使用する必要はない。この実施形態では、例えば、外部の要求者１９４が、バーコードラベルを印刷できるようにビットマップにされるＸＭＬ入力データストリームを持つことを希望する。この印刷は、遠く離れて行われる。別の方法では、外部の要求者１９４がＲＦＩＤトランスポンダをコード化することを要求する。このため、外部の要求者１９４は、インターネット又は他のネットワーク４３，４４を経由して要求をＸＭＬサーバ２００に送る。この要求は、図１〜図３及びコードセグメント１〜４に関連して前述したＸＭＬ入力データストリームと同じ形式である。この要求は、この技術分野では周知のように、ＳＯＡＰ（単純オブジェクトアクセスプロトコル（Simple Object Access Protocol））などのＸＭＬデータを含むプロトコルの形式とすることもできる。

これに応えて、ＸＭＬサーバ２００のコンピュータシステム１２は、ＸＭＬ入力データストリームを処理することができる。前述した同じ処理機能の全ては、バーコードなどに関してビットマップはプリンタのドライバには送られないことを除いて、この実施形態で実行される。それどころか、この技術分野では周知のように、ビットマップは「ＪＰＥＧ」又は「ＰＮＧ」フォーマットなどの任意の適当なフォーマットに変換される。ＪＰＥＧ又はＰＮＧファイルは、次に、外部の要求者１９４に送り戻される。この外部の要求者１９４は次に、適当なプリンタのドライバのためにＪＰＥＧ又はＰＮＧファイルをフォーマットして、バーコードラベルを印刷及び／又は表示する。ＲＦＩＤトランスポンダに関しては、コード化されたデータはデータファイルの形式で要求者に送り戻される。データファイルのどのような適当な形式も使用できる。このため、本発明はバーコード用のレンダリングサーバ及び／又はＲＦＩＤ用のレンダリングサーバとして機能することができ、必ずしも印刷又はコード化の機能を直接実行する必要はない。別の方法では、データの出力表示は、適当な工業規格によって定義されているScalable Vector Graphicフォーマット（ＳＶＧ）とすることができる。

図１のＸＭＬシステムの別の実施形態は、ここで図７〜図８に示されている。これらの図面は、図２〜図６に示した「固有の」ＸＭＬシステム１０ではなく、「混成の」ＸＭＬシステム３００を示す。この実施形態は、図１に示したコンピュータシステム１２及びプリンタシステム５０と共にさらに使用することができ、また同じ参照番号が同じ構造又は要素を示すために使用されることに注意されたい。

この実施形態では、混成のＸＭＬプリンタシステム３００は、ＺＰＬデータテンプレートに基づくＸＭＬデータを受け取ることができる。これらのテンプレートは、ＺＰＬ Ｉ及び／又はＺＰＬ ＩＩ及びそれら全ての変形例などのＺＰＬ言語（Zebra Programming Language）に適合する。このＺＰＬ言語は、命令を定義するために「カレット」文字及び２文字の命令コードを使用するフォーマッティング言語である。例えば、「^XA」命令は新しいラベルフォーマットの開始を定義し、「^XZ」命令はラベルフォーマットの終端を定義する。

ＺＰＬ言語は、制御命令を示す「ティルデ」命令も含む。例えば、命令「~JR」は、プリンタが直ちに動作するプリンタリセット命令であり、バーコードラベルの実際のフォーマッティングには実のところ重要な影響は与えない。ＺＰＬ Ｉ及びＺＰＬ ＩＩは、本発明の所有者であるVernon Hills, IllinoisのZebra Technologies Corporationによって開発された。ＺＰＬは本願ではＺＰＬ ＩＩと区別なく使用されることに注意されたい。

ＺＰＬ言語仕様に関する詳細は、「ZPL II Programming Guide Volume One: Command Reference for X.10」という題名の製造業者の品番45541LB及び「ZPL II Programming Guide Volume Two: The X.10 Environment」という題名の製造業者の品番45542LBの文書の中に見出すことができる。これらの文書は、下記のインターネットのウェブアドレス、すなわち「www.zebra.com/SS/manuals.htm」のZebra Technologies Corporationのウェブサイトで見つけてダウンロードすることができる。上記の文書は、参照することによってその全体が本願に組み込まれる。図７〜図９の実施形態では、プリンタシステムの「言語」はＺＰＬ及びＸＭＬの両方の混成であり、このためＸＭＬシステム１０は「混成ＸＭＬプリンタ」と呼ぶことができる。

周知のように、ＺＰＬベースのプリンタは、「オンデマンド印刷」及び「記憶されたラベルフォーマット」を取り扱うことができる。オンデマンド印刷は、印刷すべきラベルデータを含むデータストリームがプリンタに送られると、そのデータストリームは直ちに印刷されることを意味する。記憶されたラベルフォーマットとは、ラベル用のテンプレートが前もって作成されてプリンタにダウンロードされることを意味する。このテンプレートは、次に、内部的にプリンタの中に呼び戻されて、印刷すべきラベルデータを含む後で送信されるデータストリームと一緒に使用される。

下記の説明でより明確になるであろうが、図２〜図６の固有のＸＭＬプリンタシステムの実施形態と図７〜図８の混成のＸＭＬプリンタシステムの実施形態との間の１つの相違点は、混成のＸＭＬプリンタシステムの実施形態では、データのテンプレートがＺＰＬの中で事前に定義されて、最初にプリンタにダウンロードされることである。図７〜図８の混成の実施形態は、図２〜図６の実施形態の固有のＸＭＬプリンタシステムと既知のＺＰＬプリンタとの組合せではないことにも注意されたい。それは固有のＸＭＬモードとＺＰＬモードとの間を単に切り換える「２式が１体になった（two-in-one）」プリンタではない。

図７〜図８の混成のＸＭＬプリンタシステムは、ＸＳＬＴがＸＳＬテンプレートの中に埋め込まれたＸＳＬフォーマッティング要素と一緒にラベルを定義及びレイアウトするために使用されるという点で、図２〜図６の固有のＸＭＬプリンタシステムとは異なっている。図２〜図６の固有のＸＭＬプリンタシステムの実施形態の中でラベルのレイアウト及びフォーマッティングを処理するために、会社（すなわち、売り手）はＸＳＬフォーマッティングオブジェクトを用いてラベルのレイアウトを準備及び定義する必要があり、多くの場合、固有のＸＭＬプリンタの実施形態の中で前述したように、ＸＳＬスタイルシート及びＸＳＬスキーマも用意する必要がある。企業体のＥＲＰシステム８８が先ず第１に、ＸＳＬフォーマッティングオブジェクトなど（すなわち、ＸＳＬスタイルシート及びスキーマ）を用いて適格なＸＭＬデータを送信することができる場合、ＺＰＬテンプレートを使用する必要はない。このことは、企業体が完全に互換性のあるＸＭＬ ＥＲＰシステムへの完全なスイッチを既に作っているため、全てのＺＰＬの形状に対する要求を不要にすることを示している。

しかしながら、進んで又は喜んで「純粋なＸＭＬ」へのそのシステムの「完全な変換」に投資をしない会社もある。その理由は、そのような会社は印刷すべきラベルに対する古いＺＰＬテンプレートにかなり大きな投資を行っているからである。多くの会社は、ＸＭＬデータを取引工程から取引工程に容易に送ることができるようにインフラを構築している。それは、ＸＭＬ互換フォーマットの中でそのようなデータを送信することは、業界基準になりつつあるからである。多くの会社及び業界全体がデータに対してＸＭＬフォーマットを使用する方向に向かって動いているが、そのような会社は、単に完全に互換性のあるＸＭＬフォーマットへの切り替えを行うために、自身のテンプレート用データベースのインフラの中で自身の投資を廃棄することを望んでいない。

このため、図７〜図８の混成のＸＭＬプリンタの実施形態は、ＸＭＬフォーマットのデータを用いて現行のＺＰＬテンプレートを使用できるようにしている。ＥＲＰシステム８８は、適格なＸＭＬへの「完全な」切り替えは経済的な理由のためにまだ行われていないため、現行のＺＰＬテンプレートを引き続き使用できる。このように、ＸＳＬのスタイルシート、スキーマ及びフォーマッティングオブジェクトは、まだＥＲＰ側では実現されていない。また、混成のＸＭＬプリンタシステムは、そのような環境では費用効率が高い解決策を提供する。

ここで、図７及びコードセグメント５を参照する。直ぐ下に示した「コードセグメント５−ＺＰＬダウンロード可能なテンプレート」という名称のコードセグメントは、ＺＰＬフォーマット用テンプレートの具体的な実施例を示す。このテンプレートは、実際のバーコードラベルを印刷する前に混成のＸＭＬプリンタシステム３００に送信され、また将来の印刷ジョブのためにプリンタシステムのメモリに保管される。行番号は単に明白にするために挿入されているものであり、コードの一部ではない。

コードセグメント５−ＺＰＬダウンロード可能なテンプレート

この技術分野では周知であるが、行１及び１４で示した命令（^XA、^XZ）は、ＺＰＬ言語の中で規定されたように、テンプレートの始めと終わりを定義する。行２は、混成のプリンタシステム３００にダウンロードされたフォーマット用テンプレートが、混成プリンタのメモリの中の「E:SHIPLABL.ZPL」で定義された位置に記憶されることを示す。ここで、「E:」は記憶装置の識別子を表し、この記憶装置は例えばディスクドライブとすることができる。しかしながら、どのような適当な記憶装置も使用できる。この命令が含まれることにより、このフォーマット用テンプレートが保存されることを示す。行３〜６は、ＺＰＬプログラミング言語によって送られた種々のプリンタの設定及び初期化命令の幾つかを示す。

ここで、行７を参照する。関連したパラメータ「N」を有する「^AO」命令は、テキストフィールドがフォント番号ゼロを用いて標準的な（「N」）方向に（すなわち、フォントは回転されない）作られることを意味する。ここで、「５８，５８」は、印刷されるテキストの（ドットの）高さ及び幅を表す。ＺＰＬ言語の中で規定されるように、「^FO188, 169」はフィールドの原点を定義するため、テキストは座標188, 169に位置決めされる（すなわち、ラベルの始点から横方向に１８８ドット及び縦方向に１６９ドット）。

フィールド番号命令「^FN999」（パラメータ「999」がついたFN命令）は、後になってプリンタにダウンロードされる可変の情報を含む可変フィールドを定義する。その点では、これは標準的なＺＰＬとはいくらか異なっている。標準的なＺＰＬでは、テンプレートに「^FN」命令を受け取ると、この命令と一緒にデータは送られない。その理由は、テンプレートが後で呼び出されると、その可変データの位置を規定する後に続く「^FN」命令が送られ、その後にデータ自身が続くからである。しかしながら、この混成の実施形態では、幾つかの「関連性」データが、「^FD」フィールドデータ命令が示すように、「^FN」命令の直ぐ後に与えられる。この特定の実施形態では、「^FN」命令の直ぐ後に続くが「^FD」フィールドデータ命令によって先導されるデータは、「name」として示される。これは後になってＥＲＰ又は倉庫システムから送られたＸＭＬデータに適合するデータである。このため、コードセグメント５で示されたテンプレートを混成のＸＭＬプリンタシステム３００が受け取ると、そのテンプレートはプリンタのメモリに記憶され、さらに「name」とフィールド「999」との間の「関連性」も記憶される。

同様に、行８では、「address」とフィールド「998」との間の関連性が記憶され、行９では、「city」とフィールド「997」との間の関連性が記憶される、等々である。例えば、「name」、「address」、「city」などによって表されたフィールドは、ＥＲＰシステム８８によってＸＭＬデータとして送られる実際のデータではないことに注意されたい。正確に言えば、「name」、「address」及び「city」は、フィールド位置又は識別子、すなわち、それぞれ「999」、「998」及び「997」が付いてＥＲＰシステムによって後で送られるデータに関連する「タグ」又は「関連性」である。

ここで、行１２を参照する。「^BY」命令は、それに従うバーコード命令に対するデフォルトパラメータを定義する。この場合、４のパラメータは、細いバーの幅が４ドットであると定義する。「^FO」命令は、印刷すべきバーコードが座標188, 488に置かれるであろうと定義する。「^BZ」命令は、バーコードのフォーマットがpostnet形で、標準的な方向（パラメータがＮ）、高さが３５ドット（パラメータが３５）、かつ人が読取り可能な解釈行はない（パラメータがＮ）というバーコードを定義する。さらに、パラメータ995を有する「FN」命令は、ダウンロードされるＸＭＬデータの「name」を「995」として識別されるラベルフィールドと「zip」の属性を有するデータ命令「^FD」によって定義されるラベルフィールドとの間の関連性を規定する。命令「^FD」は、さらに「zip」が実際に印刷されるバーコードを作るためにダウンロードされるＸＭＬデータの「name」であると規定する。印刷される実際のバーコードは、図９に示すように郵便番号３０４である。

無論、テキストフィールドが、図９に示すようにバーコード自身と同様に、バーコードラベル３０５上に印刷される。そのようなフィールドは、例えば名前３０６、住所３０８、都市３１０、州３１２，及びテキストの郵便番号３１４を含む。

このように、この実施形態では、コードセグメント５に示したテンプレートは混成のＸＭＬプリンタシステム３００の中に記憶されて、実際の「仕事」は行われない（すなわち、ラベルはまだ印刷されない）。要約すると、行７〜１１はテキストフィールドを定義し、行１２はバーコードを定義する。これらのテキストフィールドは、前述したように他のパラメータと共に、後でＥＲＰシステム８８から送られる実際のＸＭＬデータと相関される関連性と一緒に定義される。コードセグメント５のテンプレートは、どのフィールドが固定で、どのフィールドが可変であるかを定義する。可変のフィールドは、可変の名前（「^FD」命令によって記憶される）を有する。この可変の名前は、後でダウンロードされる印刷されるラベルに対応するデータと相関される又は「関連付けられる」。

このように、図７〜図８の混成の実施形態では、「^FD」命令（すなわち、「name」に続く）は、実際のＸＭＬデータの中で送られる可変の名前を決定する。このＸＭＬデータは、バーコードラベル上に印刷される実際のデータではなく、結局のところテンプレートのダウンロードの後に続く

上記のコードセグメント５のフォーマット用テンプレートがどのように動作中に使用されるかを確かめるために、「コードセグメント６−ＺＰＬテンプレートと共に使用するダウンロードされたＸＭＬデータ」という題名のコードセグメント６が、直ぐ後に示されている。行番号は単に明白にするために挿入されているものであり、コードの一部ではない。

コードセグメント６−ＺＰＬテンプレートと共に使用するダウンロードされたＸＭＬデータ

コードセグメント６は、コードセグメント５のフォーマット用テンプレートが最初に混成のＸＭＬプリンタシステムにダウンロードされた後で、ＥＲＰシステム８８又は倉庫管理システムが混成のＸＭＬプリンタシステム３００に送る実際のＸＭＬデータストリームを表す。コードセグメント５及び６の特定の実施例では、使用される倉庫管理システムは、例えば、Oracle社の倉庫管理システムである（「Oracleシステム」又は「Oracle WMS」）。無論、OracleやSAPなどの、どのようなビジネスシステムも使用できる。この特定の実施例では、Oracleのシステムはデータをそのデータベースから収集して、そのデータをプリンタに送信するための特定のＸＭＬフォーマットでフォーマットする。この特定の実施例がOracleのシステムを使用するため、コードセグメント６のテンプレートはOracleのＸＭＬセマンティクスを使用する。

その点においては、Oracleの倉庫管理システムが使用する特定のＸＭＬセマンティクスは、この技術分野では周知の「label.dtd」として識別される「DTD」すなわち文書の種類の定義により、コードセグメント６の行２の中で定義される。また、この技術分野では周知のように、ＥＲＰシステム８８すなわちOracleのシステムは、ＸＭＬデータが印刷されるフォーマットを指定する能力がある。背景技術を説明すると、こうしたシステムは、Oracle又はＥＲＰシステムと使用している特定のバーコードプリンタとの間のフォーマット変換を処理する顧客の「ミドルウェア」のソフトウェアシステムに接続するように設計されているため、この能力は初めから、Oracleのシステム及び他のＥＲＰシステムの中に構築されている。本願の混成プリンタは、そのような「ミドルウェア」システムに対する必要性を除いている。

しかしながら、Oracleのシステムによって送信されたＸＭＬデータは、コードセグメント６の行３で、「_FORMAT」と呼ばれる属性を有する「labels」と呼ばれるＸＭＬ要素が存在することを指定する。この属性は、特定のフォーマット用テンプレートを使用するように指定する。この特定の実施例では、送信されたＸＭＬデータと共に使用するためのフォーマット用テンプレートは、「E:SHIPLABL.ZPL」として識別される。これはコードセグメント５に示すように、混成のＸＭＬプリンタシステム３００の中に前に記憶されたフォーマット用テンプレートであり、またそれはＺＰＬベースのフォーマット用テンプレートである。このため、以前ダウンロードされた、また混成のＸＭＬプリンタシステム３００のメモリの中に記憶されたフォーマット用テンプレートは、「E:SHIPLABL.ZPL」によって指定された位置から呼び出すことができる。

行３は、「_QUANTITY」、「_PRINTERNAME」及び「_JOBNAME」などの幾つかの付加的な「labels」要素の属性も含んでいる。属性「_QUANTITY」は印刷するバーコードラベルの数を指定し、一方属性「_PRINTERNAME」及び「_JOBNAME」は、混成のＸＭＬプリンタシステム３００が必要としないレガシーフィールドであるが、それにもかかわらず、そのようなデータは前述したように、最初はミドルウェアのソフトウェアに接続するために作られたため、Oracleのデータの中に含まれている。

コードセグメント６は、それぞれ行５〜１１、１２〜１８、及び１９〜２５に示すように、「label」データの３つのグループを含む。これらの「label」データの３つのグループは、コードセグメント１すなわち、それぞれ行８〜１４、１５〜２１、及び２２〜２８に似ているように見えることに注意されたい。その理由は、両方のコードセグメントがそれぞれ「Albert Einstein」、「Steven Hawking」及び「Richard Feynman」を指し、住所、都市、州、及び郵便番号のデータに対して関連するフィールドを有しているからである。このため、コードセグメント６に示したデータは、印刷すべき３つの個別のラベルに対応する。しかしながら、印刷される３つのラベルのそれぞれに対して、全ての住所情報はテキストで印刷されるが、郵便番号フィールドだけは実際にバーコードで印刷されることに注意されたい。これは、コードセグメント５の行１２のテンプレートの中で、「^BZ」命令が定義したからである。

コードセグメント５及び６を参照すると、コードセグメント６に示したOracleシステムによって送信されたデータが次に、コードセグメント５に示した対応するフォーマット用テンプレートに関連付けられる。例えば、コードセグメント６の行６では、「name」の可変の名前は、実際のＸＭＬテキストデータである「Albert Einstein」に対応する。コードセグメント５の前に保存したテンプレートを使用して、コードセグメント５の行７に示すように、「name」（その内容は「Albert Einstein」）とフィールド番号「999」との間に関連性が作られる。次に、ＸＭＬデータの「Albert Einstein」がフィールド番号「999」によって定義されたメモリに保存される。

同様に、ＸＭＬデータ「1234 Relative Way」はフィールド番号「998」によって定義されたメモリに保存され、ＸＭＬデータ「Princeton」はフィールド番号「997」によって定義されたメモリに保存され、ＸＭＬデータ「NJ」はフィールド番号「996」によって定義されたメモリに保存されることなどがある。一旦ＸＭＬデータ入力ストリームに含まれた全てのデータが対応するテンプレートに関連付けられて、メモリの中に格納されると、ラベルが印刷される。

ここで、図７及び図８を参照すると、図７は混成のＸＭＬプリンタシステム３００の特定の実施形態のハイレベルな機能ブロック図を示し、一方図８は混成のＸＭＬプリンタシステムの特定の実施形態のハイレベルなソフトウェアのブロック図とデータの流れ図との組合せを例示している。この混成のＸＭＬプリンタシステム３００は、固有のＸＭＬプリンタシステムに関連して前述したように、企業資源計画（ＥＲＰ）システム８８からデータを受信する。このデータには、ＸＭＬデータ及び／又はＺＰＬテンプレートデータなどのＸＭＬの構成要素及びＺＰＬの構成要素の両方が含まれる。

図７のハイレベルのブロック図には、ＸＭＬプロセッサの１種であるＳＡＸプロセッサ３２０を使用している図面が例示されている。背景技術を説明すると、ＳＡＸプロセッサ（ＸＭＬ用の簡単なＡＰＩ（Simple API for XML））は、図２〜図６の固有のＸＭＬプリンタシステムに関連して前に説明したＸＭＬプロセッサが使用するＤＯＭ処理モデル（文書オブジェクトモデル（Document Object Model））を使用しない。

前述したように、ＤＯＭベースのＸＭＬプロセッサは、この技術分野では周知のように、その処理工程を実行するために、メモリの中にノードツリーを作る。このことは、図２〜図６の実施形態に関連して前に説明したように、ＸＳＬ形の処理を実行しているときに必要である。その結果、全てのデータがメモリに記憶され、このため大きなメモリを占有することになる。しかしながら、ＳＡＸプロセッサはＸＭＬシンタックス及びデータストリームを解釈し、この技術分野では周知のように、それはメモリの中にノードツリーを構築するのではなく、イベント処理部によって処理される「イベント」を作る。ＳＡＸプロセッサは極めてメモリ効率が良く、多量のＸＭＬデータを処理する場合には望ましい。

しかしながら、図７〜図８のこの別の実施形態では、ＸＳＬ形の処理は好ましいことに実行されないため、メモリの中のノードツリーに基づいた処理は必要とされない。その結果、厳密にＤＯＭを根拠にしたＸＭＬプロセッサを用いるのではなく、図７に示すように、ＳＡＸプロセッサが使用される。「ＳＡＸ」という用語は単に、ＸＭＬ言語のデータ及びシンタックスを取り扱う方法に関する仕様のことを指す。例えば、この実施形態の中で使用できる市販のＸＭＬプロセッサは、Thai Open Source Software Center, Ltdから入手可能な「Expat」ＸＭＬプロセッサである。このＸＭＬプロセッサの特定のモデルはＤＯＭベースのＸＭＬプロセッサ又は非ＤＯＭベースのＳＡＸプロセッサの両方の機能を実行する能力を有するが、この実施形態の目的に対しては、このプロセッサは非ＤＯＭベースのＸＭＬプロセッサとして構成されることが好ましく、このためＳＡＸプロセッサと呼ばれる。しかしながら、任意の適当なＤＯＭベース又は非ＤＯＭベースのＸＭＬプロセッサを使用できる。

図７には、ＳＡＸプロセッサ３２０に加えて、ＺＰＬプロセッサ３２２も示されている。次に、ＳＡＸプロセッサ３２０及びＺＰＬプロセッサ３２２からのデータ経路は、可変データ集積部（Variable Data Integration）３２８と名付けられたブロックに向けられる。この可変データ集積ブロック３２８は、ＥＲＰシステム８８から受信されたＸＭＬデータを結合して、コードセグメント５のＺＰＬテンプレートに関連して前に説明したように、このデータをＺＰＬテンプレートが前に定義したフィールドに当てはめる又は「関連付ける」。基本的に、この工程では、実際のＸＭＬデータ、例えば名前「Albert Einstein」が、コードセグメント５のテンプレートの「999」によって定義された位置に保管され、他の場合も同様である。

次に、データは、ビットマップ／バーコード／ＲＦＩＤレンダリングブロック３３０によって処理される。この処理は、周知の市販のＺＰＬプリンタの中で使用される既知のＺＰＬビットマップ処理と同様である。例えば、Illinois州Vernon HillsのZebra Technologies Corporationから市販されている次の周知のＺＰＬプリンタ、すなわちZebra Models XiIII+, 90XiIII+. 96XiIII+. 110XiIII+, 140XiIII+, 170XiIII+, 220XiIII+, Model Z4M, Z6M, 105SL Model R4Mplus, R402, R-140プリンタ／エンコーダ、及びZebra Technologies Corporationから市販されている任意のModel Xiシリーズのバーコードプリンタは、ＺＰＬビットマップ／バーコード処理を実行することができるソフトウェア、ハードウェア、及び／又はファームウェアを備えている。ビットマップ／バーコード／ＲＦＩＤレンダリングブロック３３０は好ましいことに、どのようなＸＳＬＦＯ処理も使用せずに実行され、またＸＳＬＴスタイルシート又はスキーマも使用されないことに注意されたい。このＸＳＬＦＯ処理は、固有のＸＭＬプリンタシステムの実施形態では必要とされていた。しかしながら、ＸＳＬＴ処理及びスキーマの取扱いは塾考されており、対象の発明の範囲及び精神の中にある。

さらに、ＲＦＩＤトランシーバ６１は、ビットマップ／バーコード／ＲＦＩＤレンダリングブロック３３０に動作的に結合されて、ＲＦＩＤトランスポンダ６２との通信を容易にする。ＲＦＩＤのトランシーバ６１及びトランスポンダ６２は、図１、図２及び図６の実施形態に関連して前に図示及び説明されたトランシーバ及びトランスポンダに類似しているか又は同様である。

好ましいことにバーコードのパラメータがＸＭＬデータの中で属性として指定されずに、むしろフォーマット用テンプレートの中でＺＰＬ命令のパラメータによって指定されることを除いて、バーコードは固有のＸＭＬプリンタの実施形態に対して前に説明されたように処理される。例えば、ＺＰＬ命令「^BY2,2,100」は、線形のバーコードに対して、細いバーの幅が２ドット、太いバーの幅の細いバーの幅に対する比率が２、及びバーの高さが１００ドットであると指定する。

ビットマップが処理された後で、それはプリンタドライバ５４に向けて送られる。このことは、図１にも示されている。このプリンタドライバ５４は、関連する処理装置の物理的な位置に従って、機能がコンピュータシステム１２の中の処理装置又は処理装置６０（図１）のいずれかで処理される、前述した構成要素の実施例である。繰り返すと、１つの処理装置が十分に強力である場合は、その処理装置は混成のＸＭＬプリンタシステム３００に対する全ての機能を処理することができる。

ここで、図１、図７及び図８を参照すると、図８は、ハイレベルのソフトウェアのブロック図とデータの流れ図とが組み合わされた特定の実施形態を例示している。下記に説明されるソフトウェアは、図１のコンピュータシステム１２のプロセッサ２８によって実行される。繰り返すと、プロセッサ２８は、コンピュータシステム１２及びプリンタシステム５０の両方に共通した機能を実行することができる。一致して又は別個に機能する１つ以上のプロセッサが存在する。処理又は処理機能がコンピュータシステムによって若しくはコンピュータシステムの中で実行される又はプリンタシステムによって又はプリンタシステムの中で実行されるかどうかは、本発明の範囲に対して重要ではない。

以下に説明されるように、図８に示した処理工程を通過する複数の「経路」が、ＳＡＸプロセッサ３２０の管理のもとで生じる可能性がある。しかしながら、そのような複数の「経路」は必ずしも線形ではないため、図８には特定の線又は矢印で示された正確な経路は必然的に示されていない。図８に正確な始点及び終点を持たない反復処理が描かれている。もっと正確に言うと、経路によって生じた動作又は結果が示されているため、プロセス制御がＳＡＸプロセッサ３２０に戻る「別の経路」が、図８に点線で示されている。これは、経路が反復していること及びＳＡＸプロセッサ３２０が処理が終わる前に何回もループするすなわち反復することを示す省略方法である。

単に説明するために、図８に例示した処理を通過する第１の「経路」の中で、ＺＰＬテンプレートが混成のＸＭＬプリンタシステム３００に最初に送られる。この場合、印刷される実際のデータはまだ送られない。第２の「経路」では、後で説明されるが、印刷されるバーコードラベルを表すＸＭＬデータが、以前保存されたＺＰＬテンプレートに基づいて印刷するためにプリンタシステムに送られる。

図８に示すように、データ入力ストリーム３４０がＥＲＰシステム８８から受信される。前述したように、このストリーム３４０はＸＭＬデータ及び／又はＺＰＬテンプレートのデータを含む。ＳＡＸ処理ブロック３２０は、最初にデータ入力ストリーム３４０を受信して解析する。ＳＡＸプロセッサはＳＡＸモードで動作するＸＭＬプロセッサであるため、ＳＡＸ処理ブロック３２０はＸＭＬプロセッサによって実際に実行されることに注意されたい。このため、ＸＭＬプロセッサ又はＸＭＬ処理ブロックという語句は、ＳＡＸプロセッサ又はＳＡＸ処理ブロックという語句と交換することができる。しかしながら、前述したように、ＸＭＬプロセッサはＳＡＸモードで動作することが好ましく、このためＳＡＸプロセッサ３２０と呼ばれる。

最初に、ＳＡＸ処理ブロック３２０は、標準的なＸＭＬ構文規則をデータ入力ストリームに適用して、この入力データストリーム３４０が適格なＸＭＬデータであるかどうかを判断する。図８のＳＡＸ処理ブロックは基本的に図７のＳＡＸプロセッサと同じであり、図７は幾つかのハードウェアを示し、図８はデータの流れを示していることに注意されたい。ＳＡＸプロセッサ及びＳＡＸ処理ブロックという用語は、本願では区別なく使用される。

ＳＡＸ処理ブロック３２０が、データ入力ストリームがＸＭＬシンタックスに適合していないと判断すると、そのデータ入力ストリームはＺＰＬに基づいているとみなされる。このため、ＳＡＸ処理ブロック３２０はさらに処理を行うために、このデータ入力ストリーム３４０をＺＰＬ処理ブロック３２２に向けて送る。図８のＺＰＬ処理ブロック３２２は基本的に、図７のＺＰＬプロセッサと同じであり、図７は幾つかのハードウェアを示し、図８はデータの流れを示していることに注意されたい。ＺＰＬプロセッサ及びＺＰＬ処理ブロックという用語は、本願では区別なく使用される。

次に、ＺＰＬ処理ブロック３２２は、ＺＰＬフォーマット用テンプレートを表すデータ入力ストリーム３４０を処理すなわち解析する。ＺＰＬ処理ブロック３２２は、フォーマット用テンプレートの処理を開始させる「ラベル開始（beginning of label）」命令（^XA）を受信することが好ましい。このフォーマット用テンプレートは、コードセグメント５に示されている。

種々のＺＰＬ命令は処理を制御し、ラベルのフィールドを定義し、基本的に印刷すべきデータを確定及び定義する。プリンタ制御命令及び他の命令は、この処理の段階で受信される。全てのフォーマット用テンプレートがダウンロードされると、ＺＰＬ処理ブロック３２２は、フォーマット用テンプレートを保存させる「ラベル終了（end of label）」命令（^XZ）に出会う。対応する識別子「E:SHIPLABL.ZPL」（コードセグメント５の行２に示されている）を有する^DF命令は、ＺＰＬ処理ブロック３２２に対して、フォーマット用テンプレートが好ましいことに、プリンタシステムの内部の「E:」装置上に「shiplabl.zpl」というファイル名で保存されていることを示すことに注意されたい。無論、フォーマット用テンプレートはプリンタシステムの内部に保存される必要はなく、ネットワークサーバ上又は通信ネットワークを介してアクセス可能な遠隔位置などのどのような記憶位置にも保存することができる。

この^DF（ダウンロード用フォーマット）ＺＰＬ命令は、どのラベルフォーマットを直接印刷するのではなく保存すべきかを示す。全てのテンプレートデータが受信されたことを示す^XZが発生したときに、この保存が実際に行われる。

さらに図８において、「ＺＰＬラベルフォーマット」と名付けられたブロック（３５２）は、データ記憶装置を表すことに注意されたい。これは、入力ストリームから到来するテンプレート用データがデータ記憶装置に記憶されることを示す。データ記憶装置３５２から線が出ていくことにより、データが少し後でさらなる処理のためにデータ記憶装置から検索されることが示される。データの流路は、ブロック３６０から記憶装置を通りブロック３５６に向かうが、これは線形の流れではない実際の「制御流れ」を示していない。

「ＺＰＬラベルフォーマットの呼出し」と名付けられたブロック３５６が、前述したように「ＺＰＬラベルフォーマットの保存」と名付けられたブロック３６０に接続されて示されているが、処理は直線的ではないため、データの流れは必ずしも「ＺＰＬラベルフォーマットの保存」ブロック３６０から「ＺＰＬラベルフォーマットの呼出し」ブロック３５６に続く又は流れることはない。むしろ、全体の工程は前述したように繰返しであり、この最初の「経路」では、ブロック３６０に示すようにＺＰＬラベルのフォーマットが保存された後で、入力データストリームの制御は点線３７０で示すように、処理を継続するためにＳＡＸ処理ブロック３２０に戻る。入力データストリーム３４０の中に別の処理するデータがない場合は、処理は終了し別のデータがダウンロードされるのを待ち受ける。

図７〜図８に例示された処理部を通る第２の「経路」では、ＥＲＰシステム８８は、実際のＸＭＬデータを送信する。このＸＭＬデータは、前にダウンロードされたＺＰＬテンプレートに基づいて、混成のＸＭＬプリンタシステム３００によって処理される。例えば、ＳＡＸ処理ブロック３２０は、ラベルデータが後に続くように指定する適格なＸＭＬデータを受け取る。実際のデータを処理するために、「ＺＰＬラベルフォーマットの呼出し」と名付けられたブロック３５６に示すように記憶されたＺＰＬフォーマットが呼び出されて、到来するＸＭＬデータストリームと一緒に呼び出されたフォーマット用テンプレートが使用される。

ＳＡＸ処理ブロック３２０はＸＭＬのシンタックスを処理して、入力データストリーム３４０が定義した種々の要素及び属性を決定する。この実施形態では、「_FORMAT」属性を受け取ると、入力データストリーム３４０は一時的に遮断され、入力データはプリンタシステム３００の中に記憶されたフォーマット用テンプレートから到来するため、フォーマット用テンプレートの中に埋め込まれたＺＰＬ命令はＺＰＬ処理ブロック３２２によって解釈される。一旦フォーマット用テンプレートの中の命令が解釈されると、入力データストリーム３４０は再度ＳＡＸ処理ブロック３２０に到来し、このブロック３２０はＸＭＬデータの処理を続行する。

ＳＡＸプロセッサ３２０の制御のもとで処理部を通過する別の経路は、前述したように、様々な「事象」を開始させる。例えば、「可変データＳＡＸ事象」３７６が始動されて、フォーマット用テンプレートの中の様々なフィールドが対応する又は「関連付けられた」受信されるＸＭＬデータで占められる。このことは、「ＸＭＬ変数のＺＰＬラベルフォーマット変数への適合」と名付けられたブロック３８０によって示される。基本的に、ＸＭＬ入力データストリーム３４０の中の変数は、フォーマット用テンプレートの中のフィールドに関連付けられる。例えば、この工程では、コードセグメント６に示した実際のＸＭＬデータ「Albert Einstein」（図９の３０６）などのＸＭＬ変数は、コードセグメント５のＺＰＬテンプレートの中のラベル変数「name」などのＺＰＬラベルフォーマット変数に適合する。

ＳＡＸプロセッサ３２０は、「ラベルＳＡＸ事象の開始」３８４及び「他のＳＡＸ事象」３８８などの前述された仕事を処理するためにさらに別の事象を開始する。ＳＡＸプロセッサ３２０の制御のもとで図８の処理部を通過するこの経路又は他の経路は、「処理事象」と名付けられたブロック３９０によって処理される「他のＳＡＸ事象」を発生させる。例えば、こうした「他の」事象には、「プリンタ速度設定事象」、「印刷するラベル量の設定事象」、「メディア選択事象」、「使用するリボン選択事象」、「用紙選択事象」、「３００ｄｐｉプリンタの使用事象」、「６００ｄｐｉプリンタの使用事象」、「可変データ事象」などが含まれる。

そのような事象の数は事実上無制限であり、ハードウェアのプリンタシステムの種類、構成及び能力によって管理される。基本的に、プリンタの全ての外観及び機能は、入力データストリーム３４０の中で送られたコードを使用することによって制御される。このことは、ＸＭＬデータストリームによって記述されたラベルを印刷することができるか又は印刷するように構成されているかどうか、また印刷できない場合は、選択的にエラー情報を戻すことが可能かどうかを、プリンタが決定することを可能にする。OracleベースのＸＭＬデータに対応するコードセグメント６において、限られた数の「他の命令」だけが示されているが（すなわち、quantity = 1 及び printer name = printer 1、両方とも行３に示されている）、前述したように、基本的には、プリンタの中で制御されるどのような機能又は機構もＸＭＬ入力データストリームの中で指定することができる。このように、実際のＸＭＬ入力データストリームとプリンタの制御コードとの間には緊密な結合が存在する。

また、命令に呼応してＳＡＸ処理ブロック３２０が生成するこうした「他の」命令及び対応する「他の事象」は、Oracleのシステムの一部又はそれに固有のものではなく、このためOracleのシステムは必ずしもこれらの命令が何をするのか又はこれらの命令をどのように使用するのかを「知らない」ことを注意されたい。命令及びその後に生成される事象が意味をなすのは、そのようなダウンロードされた命令がＳＡＸ処理の間に適合される場合だけである。

「ラベル要素の終了」事象（</label>）を受け取るとラベルは完成し、ここで印刷される。この時、制御はラベルを印刷させるＺＰＬフォーマッティングエンジン処理部３９４に向けられる。好ましいことに、ＺＰＬフォーマッティングエンジン処理部３９４には、ビットマップ／バーコード／ＲＦＩＤレンダリングの機能が含まれる。このため、ブロック３９４は、ＺＰＬフォーマッティングエンジンと呼ばれる。この組み合わされた機能により、テキスト、バーコード、及びラベル上の他のフィールドの各々に対してビットマップが決定され、適当に回転及び拡大された個々のビットマップが１つのラベルのビットマップ３９６に統合され、完成されたラベルのビットマップがプリンタエンジン（すなわち、図１のプリンタドライバ５４）に送られて、媒体上に物理的に印刷される。前述したように、ＺＰＬフォーマッティングエンジン処理部３９４は、例えば、Illinois州Vernon HillsのZebra Technologies Corporationから市販されているプリンタの中の種々の市販のＺＰＬプリンタの中に見出すことができる。これには次のプリンタモデル、すなわちXiIII+, 90XiIII+. 96XiIII+. 110XiIII+, 140XiIII+, 170XiIII+, 220XiIII+, Model Z4M, Z6M, 105SL Model R4Mplus, R402, R-140プリンタ／エンコーダ、及び任意のModel Xiシリーズのバーコードプリンタが含まれる。

ＺＰＬフォーマッティングエンジン処理部３９４は基本的に、印刷すべきラベルの中に含まれたフィールドの全てを決定し、かつ各フィールドに対して何をすべきであるかを決定する。例えば、このＺＰＬフォーマッティングエンジン処理部３９４は、コードセグメント６の行６に示したデータ「Albert Einstein」（図９の３０６）を含むフィールドが、フォント番号がゼロを用いて標準的な（「N」）方向で、またコードセグメント５の行７で示すように、高さが５８ドット、幅が５８ドット、及びフィールド原点の座標が１８８，１６９で印刷されることを決定する。

このように、ＺＰＬフォーマッティングエンジン処理部３９４は、フォーマット用テンプレートによって定義されたフィールドの全てを、対応するＸＭＬデータと一緒に検査し、また基本的にテキスト又はバーコードを表すラベル上にドット（又はビット）を作る方法を決定する。バーコードのフィールドは、フィールドを規定するバーコード記号に基づいて適当なビットマップ生成アルゴリズムをフィールドパラメータに適用することによってフォーマット及び作成される。このバーコード記号は、線形バーコードの横方向及び縦方向のサイジング及び二次元バーコードの拡大を説明する。

また、ＲＦＩＤトランシーバ６１はＺＰＬフォーマッティングエンジン処理部３９４に動作的に結合されて、ＲＦＩＤトランスポンダ６２との通信を容易にする。ＲＦＩＤのトランシーバ６１及びトランスポンダ６２は、図１、図２、図６及び図７の実施形態に関連して前に図示及び説明されたトランシーバ及びトランスポンダに類似しているか又は同様である。

ここで、コードセグメント７を参照する。直ぐ後に示された「コードセグメント７−ＲＦＩＤ及びデータロギング命令付きのＺＰＬダウンロード可能なテンプレート」という題名のコードセグメントは、幾つかのＲＦＩＤ及びデータロギング命令が加えられたコードセグメント５を示す。これらの加えられたコードにより、ＲＦＩＤタグからの読取り及びそれへの書込みが行われ、ＲＦＩＤデータがホストコンピュータに記録される。行番号は、単に明白にするために挿入されているものであり、コードの一部ではない。

コードセグメント７−ＲＦＩＤ及びデータロギング命令付きのＺＰＬダウンロード可能なテンプレート

行１４にタグ書込み（^WT）命令が含まれることにより、パラメータ９９５を有するフィールド番号命令^FNによって示された、フィールド番号９９５によって規定されるデータが、ＲＦＩＤタグに書き込まれる（コード化される）ことが示される。この実施例では、フィールド番号９９５に関連するＸＭＬデータは郵便番号である。第１のラベルに対する実際の郵便番号データ「08540」がＲＦＩＤタグ上にコード化されることになる。

行１６に固有のタグＩＤ読取り（^RI）命令を含むことにより、タグＩＤ番号がタグから読み取られて、行１６にパラメータ「tagid」を有する^FD命令によって指定されるように、「tagid」と名付けられたＸＭＬ変数に関連付けられる。さらに、タグから読み取られたデータは、フィールド番号９９４に関連付けられる（パラメータが９９４の^FN命令）。また行１５のテキストフィールドがフィールド番号９９４を有しているため、ＲＦＩＤタグから読み取られたタグＩＤは、ラベル上の位置１８８，３９４にテキストとして印刷される。

行３，８，９，１０，１１，１２，及び１６上の新しいＺＰＬ命令「ＸＭＬへのログ」（^LX）は、後でホストコンピュータに送信するために、幾つかのフィールドデータをデータログの中に保存すべきであることを示す。行３上の^LXE:LOG04128.XML命令は、このラベル用のログデータをE:装置の中の「LOG04128.XML」と呼ばれるファイルの中に保存すべきであることを示す。行８，９，１０，１１，１２，及び１６の^LX命令は、これらのフィールドに関連したデータを前に指定された名前が付いたログの中に保存すべきであることを示す。例えば、行８の^LX命令が処理されると、「name」フィールドに関連したデータがログされる。第１のラベルに関してログされる実際のデータは、コードセグメント６の行６に示すように「Albert Einstein」である。行１６上で^LXに対してログされるデータは、タグから読み取られた固有のタグＩＤである。この実施例の目的に関して、タグから読み取られた第１のラベルに対する固有のタグＩＤは「1248002001」であると仮定する。

上記のコードセグメント７のフォーマット用テンプレートの中にデータがどのように示されているかを調べるために、ホストコンピュータを参照すると、直ぐ後の「コードセグメント８−アップロードされたＸＭＬデータ」という題名のコードセグメント８が示されている。行番号は、単に明白にするために挿入されているものであり、コードの一部ではない。

コードセグメント８−アップロードされたＸＭＬデータ

プリンタがログデータをアップロードすることを要求されると、プリンタはコードセグメント８に示したものと同様のＸＭＬデータストリームを形成する。このデータはラベルを印刷するためにプリンタに送られたＸＭＬデータに極めて良く似ているが、付け加えられたものが幾つかある。「ルート」要素が加えられて、２つ以上の完成した印刷ジョブからのデータを同じＸＭＬストリームの中に戻すことができる。ログファイルの名前は、行２に示した_LOGFILE属性の中で指定することができる。ＲＦＩＤタグから読み込まれたデータは、行１０，１８及び２６に「tagid」変数として含まれる。このデータをホストコンピュータが受け取ると、このホストコンピュータはＩＤが「1248002001」のＲＦＩＤタグがAlbert Einsteinに出荷された商品を識別するために使用されたことを知る。このデータは、後で照会するためにホストコンピュータのデータベースの中に記憶することができる。この実施例は固有のタグ識別子と共に示されるが、ＲＦＩＤタグに書き込まれた又はそこから読み取られたどのようなデータも同様な方法でホストコンピュータに報告することができる。

混成のプリンタシステムは、プリンタの制御及びラベルテンプレート用言語に対してＺＰＬを使用することに限定されない。ＺＰＬ以外の他の専売の又は非専売のプリンタ制御言語（ＰＣＬ）は、ＸＭＬをＰＣＬから区別することができる限り、同様の方法で使用できる。

固有のＸＭＬプリンタシステム及び混成のＸＭＬプリンタシステム含む、本発明によるＸＭＬシステムの特定の実施形態を、本発明が作成され使用される方法を例証するために説明してきた。本発明及びその様々な見地の他の各種の変形例及び修正例を実現することは当業者にとって容易であり、かつ本発明は説明された特定の実施形態に限定されないことは理解されたい。このため、本願で開示及び請求される基本的な内在する原理の真の精神及び範囲に入るありとあらゆる修正例、変形例又は等価なものを本発明がカバーするものと考える。

本発明に係るＸＭＬシステムの特定の実施形態のハイレベルのハードウェアのブロック図である。 ＸＭＬシステムの特定の実施形態のハイレベルのソフトウェアのブロック図である。 ＸＭＬシステムの特定の実施形態のハイレベルのソフトウェアのブロック図とデータの流れ図との組合せを示す図である。 ビットマップ／バーコード及び／又は無線周波数識別（ＲＦＩＤ）レンダリングエンジンの特定の実施形態のハイレベルのソフトウェアのブロック図である。 図１〜図４のＸＭＬシステムに基づいて作られたバーコードラベルの具体的な表示である。 バーコード及び／又はＲＦＩＤレンダリングサーバとして構成されたＸＭＬシステムの別の実施形態の具体的な実施例である。 ＸＭＬシステムの別の具体的な実施形態のハイレベルのソフトウェアのブロック図である。 ＸＭＬシステムの特定の別の実施形態のハイレベルのソフトウェアのブロック図とデータの流れ図との組合せを示す図である。 図７〜図８のＸＭＬシステムに基づいて作られたバーコードラベルの具体的な表示である。

Claims (12)

1. メモリサブシステムと、ネットワークに動作可能なように接続される通信インターフェースとを有するコンピュータシステムと、
   ＸＭＬ入力データストリームを受信及び処理するように構成されたＸＭＬプロセッサと、
   フォーマット用テンプレートを受信及び処理するように構成されたＺＰＬプロセッサと、
   前記ＸＭＬ入力データストリームの中に含まれたＸＭＬデータと、前記フォーマット用テンプレートとの間の関連性を明らかにするように構成された可変データインテグレータと、
   前記フォーマット用テンプレートによって制御されたフォーマットに基づいて、前記関連付けられたＸＭＬデータをフォーマットするように構成されたフォーマッティングエンジンと、
   前記関連付けられフォーマットされたＸＭＬデータを受け取り、バーコードラベル、タグ、切符、カード、又は他の媒体の印刷可能な表示を生成し、及び／又はＲＦＩＤ素子用にコード化情報を作るように構成されたバーコードレンダリングエンジンと
   を備える、ＸＭＬの入力データストリーム及びフォーマット用テンプレートに基づいて、バーコードラベル、タグ、切符、カード、又は他の媒体を印刷する、及び／又は媒体の中に埋め込まれたＲＦＩＤ素子をコード化するＸＭＬシステム。
2. 前記ＸＭＬプロセッサが前記フォーマット用テンプレートの中に埋め込まれた命令に基づいて複数の事象を発生する請求項１に記載のシステム。
3. 前記事象が、プリンタ速度設定事象と、印刷するラベル量の設定事象と、メディア選択事象と、使用するリボン選択事象と、用紙選択事象と、３００ｄｐｉプリンタの使用事象と、６００ｄｐｉプリンタの使用事象と、可変データ事象とからなるグループから選択される請求項２に記載のシステム。
4. 前記フォーマット用テンプレートが前記ＸＭＬプロセッサに送られ、ダウンロードされるＸＭＬデータと共に使用するために保存される、ここで、前記ＸＭＬデータのダウンロードはその後で行われる、請求項１に記載のシステム。
5. 前記フォーマット用テンプレートがＺＰＬベースのフォーマット用テンプレートである請求項１に記載のシステム。
6. 前記コンピュータシステムが前記ＲＦＩＤ素子内のコード化されたデータを読み取る請求項１に記載のシステム。
7. ネットワークに動作可能なように接続されたホストコンピュータをさらに備える請求項１に記載のシステム。
8. ネットワークに動作可能なように接続されたホストコンピュータをさらに備える請求項６に記載のシステム。
9. 前記ＲＦＩＤ素子から読み取られたデータが前記ホストコンピュータに送信される請求項８に記載のシステム。
10. 前記コンピュータシステムに動作可能なように接続されたプリンタをさらに備える請求項１に記載のシステム。
11. 前記プリンタがＺＰＬベースのプリンタ制御言語に基づいて制御される請求項１０に記載のシステム。
12. 前記プリンタが非ＺＰＬベースのプリンタ制御言語に基づいて制御される請求項１０に記載のシステム。

Images