JP2004501476A

JP2004501476A - データ埋め込みを伴うデータパッケージテンプレート

Info

Publication number: JP2004501476A
Application number: JP2002507314A
Authority: JP
Inventors: ワルムズリー，　サイモン，　ロバート; ラプスタン，　ポール
Original assignee: シルバーブルック　リサーチ　ピーティワイ　リミテッド
Priority date: 2000-06-30
Filing date: 2000-06-30
Publication date: 2004-01-15
Anticipated expiration: 2020-06-30
Also published as: AU2000253747A1; DE60045318D1; ATE490516T1; IL153715A0; CN100361145C; CN1265318C; CN1667648A; AU2000253747B2; ZA200210184B; JP4689935B2; IL153715A; CN1454369A

Abstract

任意のコード化方式を用いてデータをコード化し、いずれの任意形状にも印刷することのできる包括的データパッケージテンプレートが、記載される。テンプレートは、データ領域の位置を突き止め、配向するよう読み取られる任意の形状になされた一定の背景パターンを備えている。データは、格納されている情報を抽出するようデコードされる複数のドットを含む。
【選択図】図８

Description

【０００１】
【発明の技術分野】
本発明は、データ埋め込みを伴うデータパッケージテンプレート、タグに関する。
【０００２】
限定はしないが特には、ドットベースのデータパッケージテンプレートフォーマット構造、すなわちタグフォーマット構造（ＴＦＳ）に関する。
【０００３】
【発明に対する背景】
本発明に関する種々の方法、システムおよび装置は、本発明の出願人または譲受人によって２０００年５月２４日に出願された以下の同時係属出願において開示されている。
ＰＣＴ／ＡＵ００／００５１８，ＰＣＴ／ＡＵ００／００５１９，ＰＣＴ／ＡＵ００／００５２０，ＰＣＴ／ＡＵ００／００５２１，ＰＣＴ／ＡＵ００／００５２３，ＰＣＴ／ＡＵ００／００５２４，ＰＣＴ／ＡＵ００／００５２５，ＰＣＴ／ＡＵ００／００５２６，ＰＣＴ／ＡＵ００／００５２７，ＰＣＴ／ＡＵ００／００５２８，ＰＣＴ／ＡＵ００／００５２９，ＰＣＴ／ＡＵ００／００５３０，ＰＣＴ／ＡＵ００／００５３１，ＰＣＴ／ＡＵ００／００５３２，ＰＣＴ／ＡＵ００／００５３３，ＰＣＴ／ＡＵ００／００５３４，ＰＣＴ／ＡＵ００／００５３５，ＰＣＴ／ＡＵ００／００５３６，ＰＣＴ／ＡＵ００／００５３７，ＰＣＴ／ＡＵ００／００５３８，ＰＣＴ／ＡＵ００／００５３９，ＰＣＴ／ＡＵ００／００５４０，ＰＣＴ／ＡＵ００／００５４１，ＰＣＴ／ＡＵ００／００５４２，ＰＣＴ／ＡＵ００／００５４３，ＰＣＴ／ＡＵ００／００５４４，ＰＣＴ／ＡＵ００／００５４５，ＰＣＴ／ＡＵ００／００５４７，ＰＣＴ／ＡＵ００／００５４６，ＰＣＴ／ＡＵ００／００５５４，ＰＣＴ／ＡＵ００／００５５６，ＰＣＴ／ＡＵ００／００５５７，ＰＣＴ／ＡＵ００／００５５８，ＰＣＴ／ＡＵ００／００５５９，ＰＣＴ／ＡＵ００／００５６０，ＰＣＴ／ＡＵ００／００５６１，ＰＣＴ／ＡＵ００／００５６２，ＰＣＴ／ＡＵ００／００５６３，ＰＣＴ／ＡＵ００／００５６４，ＰＣＴ／ＡＵ００／００５６６，ＰＣＴ／ＡＵ００／００５６７，ＰＣＴ／ＡＵ００／００５６８，ＰＣＴ／ＡＵ００／００５６９，ＰＣＴ／ＡＵ００／００５７０，ＰＣＴ／ＡＵ００／００５７１，ＰＣＴ／ＡＵ００／００５７２，ＰＣＴ／ＡＵ００／００５７３，ＰＣＴ／ＡＵ００／００５７４，ＰＣＴ／ＡＵ００／００５７５，ＰＣＴ／ＡＵ００／００５７６，ＰＣＴ／ＡＵ００／００５７７，ＰＣＴ／ＡＵ００／００５７８，ＰＣＴ／ＡＵ００／００５７９，ＰＣＴ／ＡＵ００／００５８１，ＰＣＴ／ＡＵ００／００５８０，ＰＣＴ／ＡＵ００／００５８２，ＰＣＴ／ＡＵ００／００５８７，ＰＣＴ／ＡＵ００／００５８８，ＰＣＴ／ＡＵ００／００５８９，ＰＣＴ／ＡＵ００／００５８３，ＰＣＴ／ＡＵ００／００５９３，ＰＣＴ／ＡＵ００／００５９０，ＰＣＴ／ＡＵ００／００５９１，ＰＣＴ／ＡＵ００／００５９２，ＰＣＴ／ＡＵ００／００５９４，ＰＣＴ／ＡＵ００／００５９５，ＰＣＴ／ＡＵ００／００５９６，ＰＣＴ／ＡＵ００／００５９７，ＰＣＴ／ＡＵ００／００５９８，ＰＣＴ／ＡＵ００／００５１６，ＰＣＴ／ＡＵ００／００５１７およびＰＣＴ／ＡＵ００／００５１１
【０００４】
これらの同時係属出願の開示は、相互参照によって本明細書中に組み込まれる。
【０００５】
更に、本発明に関する種々の方法、システムおよび装置は、本発明の出願人または譲受人によって同時に出願された以下の同時係属出願のＰＣＴ出願に開示されている。すなわちＰＣＴ／ＡＵ００／００７５４，ＰＣＴ／ＡＵ００／００７５５およびＰＣＴ／ＡＵ００／００７５６である。
【０００６】
これらの同時係属出願の開示は、相互参照によって本願明細書に組み込まれる。
【０００７】
とりわけ関連するのは、参照番号ＰＥＣ０２として以後、本明細書中で引用するＰＣＴ特許出願番号ＰＣＴ／ＡＵ００／００５１７、発明の名称「印刷ページタグエンコーダ」である。
【０００８】
現在、店から購入されるほぼすべての商品は、パッケージ上に、ある記述を持つバーコードを含んでいる。このバーコードは、製品番号によって目的物を識別する便利な方法を提供する。製品番号の正確な解釈は、バーコードの種類に依存している。倉庫在庫追尾システムはユーザーに自らの製品番号範囲を定義させる一方、店の在庫品は、或る会社からの製品が別の会社からの製品と重ならないように、より普遍的にコード化されていなければならない。
【０００９】
バーコード自体は多数のフォーマットで指定されている。旧バーコードフォーマットほど、ラインの形で表示される文字を含んでいる。白黒ラインの組合せは、バーコードが含む情報を記述している。多くの場合、完全なバーコードを形成する２種類のライン、すなわち、文字（情報自体）と、より良好な光学的認識のためにブロックを分割するラインである。情報はバーコード毎に変化してもよいが、ブロックを分割するラインは一定のままである。従って、ブロックを分割するラインは、バーコードの一定の構造構成要素の一部として考えることができる。
【００１０】
バーコードは、抽出データを更なる処理のためにコンピュータへ渡すライトペン、ガンリーダおよびスキャナ等の専用の読取装置を用いて読み取られる。
【００１１】
抽出データが正しく読み取られることを確保する助けとして、未熟な形態のエラー検出としてのチェックサムが導入された。より最近のバーコードフォーマットは、リード‐ソロモンのような冗長コード化方式を用いている。かかる方式は、開示されたＵＳ５，５９１，９５６のようなアズテック二次元バーコードで利用されている。多くの場合、冗長コード化の度合いはユーザー選択式である。
【００１２】
二次元バーコードが開発されていて、そこでは、データは一次元から抽出されるライン列として情報を格納する代わりに、情報が二次元でコード化される。元のバーコードと全く同様に、二次元バーコードは、より良好な光学的認識のための情報と構造構成要素とを含んでいる。図１は、日本のデンソーによって開発され、ＵＳ５，７２６，４３５で開示されているクイックレスポンス（ＱＲ）コードの一実施例を示している。注目すべきは、バーコードセルが次の２領域から成り立っていることである。すなわち、（バーコードに格納されているデータに依存する）データ領域および定位置検出パターンである。定位置検出パターンは読取装置により使われて、セル自体の位置を突き止めることを助け、次にセル境界の位置を突き止め、読取装置がセル本来の配向を決定できるようにする。この配向は、第４コーナーパターンが存在しないという事実によって決定できる。
【００１３】
利用可能なバーコードの範囲に伴うひとつの問題は、これらのバーコードを生成するためのハードウエアが、特定のバーコードフォーマットに限定されてしまっていることである。プリンタがますます組み込まれるようになってくるにつれて、これらバーコードのリアルタイム印刷に対する要望が高まってきている。
【００１４】
【発明の目的】
本発明の目的は、データ埋め込みを伴うデータパッケージテンプレートを提供することである。
【００１５】
更に、本発明の目的は、包括的なコード化方式をサポートする包括的なタグフォーマット構造を提供することである。
【００１６】
本発明の他の目的は、以下の説明から明らかになるであろう。
【００１７】
【発明の概要】
唯一の形態である必要はなく、すなわち実際には最も広い形態である一形態において、本発明は、以下を備えるデータパッケージテンプレートに在住する。すなわち、
任意の形状になされた一定の背景パターン；および、
任意の形状になされた少なくともひとつのデータ領域；
【００１８】
前記データ領域は、コード化方式によって決定された位置に配置されるデータドットを含む。
【００１９】
別の形式において、本発明は、複数のドットから形成されたデータパッケージテンプレート内のデータをパッケージ化する方法に在住し、この方法は以下のステップを含む。すなわち、
前記データパッケージ内の各ドット位置に対するエントリのビット配列を構成するステップであって、前記エントリの配列は、前記各ドットが一定背景パターンの一部であるのか、またはデータ領域の一部であるのかを定義し；
前記データ領域への格納のために前記データをコード化するステップ；および、
前記データを用いてコード化された前記複数のドットを印刷するステップ。
【００２０】
【好ましい実施の形態の詳細な説明】
発明をより完全に理解し、実施できるようにするために、本発明の好ましい実施の形態を、単に例示の目的で、添付図面を参照してここに説明する。
【００２１】
本出願において、用語タグは、データと、データを保持したり、位置を突き止めたり、あるいは読み取ることを助けるように描写されなければならない他のすべての成分（位置検出パターン、ブランクスペース、囲み等）との組合せを参照するために用いられる。従って、タグは以下の成分を含む。すなわち、
【００２２】
・少なくともひとつのデータ領域。データ領域は、タグのためにある。タグデータ領域（単数／複数）は、（任意に冗長コード化され、おそらくは単にチェックサムされた）コード化データを含む。データのビットは、タグコード化方式によって指定される位置でデータ領域内に配置される。
【００２３】
・普通には、一定の位置検出パターンを含む一定の背景パターン。これらは、タグ読取装置がタグ位置を突き止めるのを助ける。それらは、二次元タグの場合に、位置を突き止めるのが容易でかつ配向および透視情報を含むかもしれない成分を含む。一定の背景パターンは、データ領域を囲むブランク領域のようなパターンや、位置検出パターンを含んでいてもよい。これらのブランクパターンは、データ領域間にどのような干渉もないことを確保することによって、データの符号化を支援してもよい。
【００２４】
説明を容易にするため、データパッケージテンプレートは、バーコードスキャナ等の一般的な光学認識の点から説明する。言うまでもなく、この概念は触覚認識あるいは聴覚認識にも等しく適用できる。
【００２５】
大半のタグコード化方式には、少なくとも何らかの一定背景パターンがあるが、必ずしもそれを全てが必要としているわけではない。例えば、タグデータ領域が物理的スペースに囲まれて、読取手段が非光学的位置決定機構（例えば、データ読取装置に対する表面の物理的位置合わせ）を用いる場合、位置検出パターンは必要ではない。
【００２６】
異なるタグコード化方式は異なる大きさのタグを有し、物理的タグ領域を一定の位置検出パターンとデータ領域にそれぞれ割り当てる。例えば、図１に示すように、ＱＲコードは、タグの縁部に位置検出パターンのための３つの固定ブロック１０を持ち、残部にデータ領域１１を持つ。対照的に、図２、図３および図４に示すＮｅｔｐａｇｅタグ構造は、円形ロケータ成分２０、配向成分２１、およびいくつかのデータ領域を含んでいる。図２は、解像度非依存形式の、Ｎｅｔｐａｇｅタグの一定背景パターンを示す。図３は、図２と同じであるが、データ領域３０がＮｅｔｐａｇｅタグへ追加されている。図４は、Ｎｅｔｐａｇｅタグのためのドット配置と１６００ｄｐｉへのレンダリングの実施例である。図４において、データの単一ビットは、データ領域内のブロックを形成するよう多くの物理的出力ドットによって表示されている。
【００２７】
データ領域はタグ用データを含んでいる。タグのコード化フォーマットによっては、データの単一ビットを、多数の物理的な印刷ドットによって表示してもよい。正確なドット数は、出力解像度およびターゲット読取／走査解像度に依存する。図５は、従来のバーコードからのライン部に及ぼす解像度の影響を示している。解像度Ｒでレンダリングされる場合、ライン部は、幅２ドット×高さ５ドットのようにレンダリングされてもよい。２倍の解像度（２Ｒ）でレンダリングされる同じラインは、各次元において２倍多くのドットによって表示される。
【００２８】
更なる実施例として、図１に示すＱＲコードにおいて、単一ビットは、暗いモジュールまたは明るいモジュールにより表示され、この場合、暗いモジュールまたは明るいモジュールの正確なドット数は、レンダリング解像度およびターゲット読取／走査解像度に依存している。例えば、図６を参照すると、データモジュールは、印刷ドットの１正方形ブロック（バイナリ１に対しすべてオン６０、または、バイナリ０に対しすべてオフ６１）によって表示されてもよい。
【００２９】
ここで、データの単一ビットは、任意の印刷形状による印刷タグで表示されてもよい。最小形状は単一の印刷ドットであり、最大形状は理論的にそのタグ全体である。例えば、両次元における多数の印刷ドットから構成されるマクロドットである。
【００３０】
理想の包括的タグ定義構造は、データの各ビットから任意の印刷形状を生成することを可能にしている。
【００３１】
元のデータビット数と、読取／走査機構を介する後続の読み出しのためにそれらのビットを印刷タグに配置する要望とを与えれば、元のビット数をタグ内に直接配置することも、あるいは何らかの方法で冗長コード化することもできる。正確な冗長コード化の形式は、タグフォーマットに依存している。
【００３２】
タグのデータ領域内のデータビットの配置は、コード化方式で用いられる冗長機構に直接関係する。データビットは、バーストエラーがタグデータ全体で平均化されるように、一緒に二次元に配置されてもよく、従って普通は訂正可能である。例えば、リード−ソロモン符号語のすべてのビットは、タグデータ領域全体にわたって広げられて、バーストエラーの潜在的な影響を最小化する。
【００３３】
データのコード化方式とタグデータ領域の形状と大きさとは密接にリンクされているので、包括的なタグフォーマット構造を備えることが望ましい。これにより、同一データ構造とレンダリングの実施の形態とを用いて、種々のタグフォーマットをレンダリングすることが可能になる。
【００３４】
本発明のタグフォーマット構造（ＴＦＳ）は、ドットベースのデータパッケージテンプレートである。それは、ドットで構成される任意形状のデータパッケージの定義と、データ自体がデータパッケージ内のドットとしてどのように格納されるかの定義を可能にする。ＴＦＳは最適化されており、その結果、タグはリアルタイムでレンダリングできる。ＴＦＳは、タグの境界ボックス内に各ドット位置用のエントリを含んでいる。各エントリは、そのドットが一定背景パターンの一部−普通は一定位置検出パターンを含む−であるか、またはタグのデータ成分の一部であるかを特定する。
【００３５】
ＴＦＳは、タグの境界ボックス内でそれぞれのドット位置毎にひとつのエントリを含むという点で、ビットマップに類似している。従って、ＴＦＳはＴａｇＨｅｉｇｈｔ×ＴａｇＷｉｄｔｈのエントリを有し、ここで、ＴａｇＷｉｄｔｈはライン次元におけるタグ用の境界ボックスの大きさに一致し、ＴａｇＨｅｉｇｈｔはドット次元におけるタグ用の境界ボックスの大きさに一致している。タグ用のＴＦＳエントリの単一ラインは、タグライン構造と呼ばれている。
【００３６】
ＴＦＳは、それに関連付けられた以下のパラメータを有する。すなわち、
・ＴａｇＷｉｄｔｈは、タグ用の境界ボックスの（ドットでの）幅であり、
・ＴａｇＨｅｉｇｈｔは、タグ用の境界ボックスの（ドットでの）高さであり、
・ＥｎｔｒｙＷｉｄｔｈは、ＴＦＳの各エントリのビット数（最小２）であり、
・ＮｕｍＴａｇＤａｔａＢｉｔｓは、各タグと関連するデータビット数（最小０）である。
【００３７】
特定のタグインスタンスをコード化するには、タグに挿入されるべきデータが供給される必要がある。すなわち、
【００３８】
・ＴａｇＤａｔａは、タグデータ領域に格納される実際のデータを含むＮｕｍＴａｇＤａｔａＢｉｔｓビットの配列である。これらのビットは、タグコード化方式に従って既に冗長コード化されていることが好ましい。
【００３９】
ＴＦＳにおける各エントリは、下位ビット（ビット０）に従って解釈される。すなわち、
【００４０】
・ビット０がクリアであれば（＝０）、このエントリに対する出力ドットは一定の背景パターンの一部である。ドット値自体はビット１から生じる。ビット１＝０の場合、出力は０であり、ビット１＝１であれば、出力値＝１である。
【００４１】
・ビット０がセットされると（＝１）、このエントリに対する出力ドットは、ＴａｇＤａｔａ配列から生じる。エントリの残りのビット（ビット１からＮｕｍＴａｇＤａｔａＢｉｔｓ−１）は、使用されるべきＴａｇＤａｔａビットのアドレスを含んでいる。
【００４２】
ＴＦＳにおける各エントリは単独に解釈され、状態情報に何ら依存しない。複数のレンダリングエンジンがページの異なる部分を処理している場合（例えば、タグが２つ以上のレンダリングエンジンに分けられてもよい）に必要になるかもしれない。エントリへのランダムアクセスが可能であるためには、これは重要である。
【００４３】
印刷ドットの大きさがあまりに小さい場合、タグはいくつかの方法のうちのひとつで拡大縮小することができる。タグ自体は、ＴＦＳのエントリ数を増加させる各次元でのＮドットまで拡大縮小されてもよい。代替として、ＴＦＳジェネレータからの出力は、標準ビットマップ拡大縮小技術、例えば、ピクセル複製またはスーパーサンプルの平均化、によって拡大することができる。
【００４４】
例えば、元のＴＦＳが２１×２１のエントリであり、拡大縮小がそれぞれ元のドットに対し単純な２×２ドットであった場合、ＴＦＳは、４２×４２まで増加されることになる。新しいＴＦＳを旧いものから生成するには、ＴＦＳの各ラインにわたり各エントリが反復されてから、ＴＦＳの各ラインが反復される。正味のエントリ数は４倍（２×２）に増加する。
【００４５】
ＴＦＳは、単純な拡大縮小の代わりにマクロドットの作成を可能にする。図７と、そこに記載されている３×３ドットタグの単純な実施例を参照すると、タグの物理的に大きな印刷形式が望まれてもよく、ここで、例えば、それぞれ元のドットは７×７の印刷ドットによって表示されてもよい。７による複製が、（各次元におけるＴＦＳの大きさを７倍に増加させるか、タグジェネレータが出力した出力を拡大するかのいずれかによって）元のＴＦＳの各次元で行われる場合、９セットの７×７正方形ブロックが生じるであろう。代わりに、ＴＦＳにおけるそれぞれ元のドットは、７×７ドット定義の円形状ドットで置き換えてもよい。図８はその結果を示す。
【００４６】
従って、ＴＦＳの解像度が高ければ高い程、より多くの印刷ドットが各マクロドットのために印刷することができ、ここで、マクロドットは、タグの単一データビットを表している。マクロドットの生成に利用できるドットが多ければ多い程、マクロドットのパターンはより複雑になるかもしれない。例えば、図４は、データビットを（１６００ｄｐｉにおいて）平均８ドット×８ドットで表すようにレンダリングされるＮｅｔｐａｇｅタグ構造を示しているが、実際のドット構造は、その形状が正方形ではない。これにより、Ｎｅｔｐａｇｅタグはその後、どの配向においても読み取られることができる。
【００４７】
非常に単純な実施例を、図７の９ドットタグにより示す。タグ位置突き止めを支援する３ドットの一定背景パターンがあり、残りの６ドットがデータに用いられる。これは、タグ内に６ビットのデータを格納できることを意味している。
【００４８】
しかし、元の３ビットはそれらの逆数を加えることによって冗長コード化されているので、その６ビットは、実際には元データの３ビットを表すだけのものと仮定する。例えば、元のデータの３ビットが１１１である場合、６ビットは１０１０１０となる。元のデータの３ビットが１０１である場合、結果として生じる６ビットは１００１１０となる。
【００４９】
タグ内のドット位置の関係は、データの冗長コード化を考慮するよう選択されている。この単純な実施例では、タグの頂部ラインは、常に１１１である。第２のラインは、最初の２データビットを含んでいる。データコード化方式を知っていると、最初の２ビットは互いの逆数でなければならない。従って、第２のラインの１１１は決して得られることはないが、１０１，０１１，１００および０１０は得ることができる。同じことは、タグの第３のラインにも当てはまる。従って、１１１の一定パターンは、タグが生成される場合に所定の一定領域以外で得られることはない。
【００５０】
以下のパラメータは単純なタグ設計を要約する。すなわち、
・ＴａｇＷｉｄｔｈ＝３
・ＴａｇＨｅｉｇｈｔ＝３
・ＥｎｔｒｙＷｉｄｔｈ＝４（１＋３、下位ビット用の１と、６データビットへのインデックスとなる３）
・ＮｕｍＴａｇＤａｔａＢｉｔｓ＝６
【００５１】
図７を参照すると、ＴＦＳの第１のラインは、００１０，００１０，００１０であって、格納されているデータに関係なく常にオンである３ドットを表している。ＴＦＳにおける第２のラインの第１のエントリは、０００１であって、このタグのためのＴａｇＤａｔａ配列のビット０の内容が、このドット位置における出力でなければならないことを示している。第２のラインの第２のエントリは、このドット位置で出力されるべきＴａｇＤａｔａ配列のビット１の内容のための００１１である。ＴＦＳにおける第２のラインの第３のエントリは、ビット２の内容のための０１０１である。
【００５２】
ＴＦＳの第３のラインの第１のエントリは、１００１であって、ＴａｇＤａｔａ配列のビット４の内容がこのドット位置で出力されなければならないことを示している。ライン２、エントリ２は、ビット５のための１０１１であり、ＴＦＳにおけるライン２、エントリ３は、０１１１であって、タグに対しＴａｇＤａｔａ配列のビット３に何が格納されていようとも、このドット位置で出力されなければならないことを示している。
【００５３】
従って、ＴＦＳ全体は以下となる（エントリ順の配列）。すなわち、
００１０，００１０，００１０
０００１，００１１，０１０１
１００１，１０１１，０１１１
【００５４】
注意すべきは、コード１１０１と１１１１は、これらが存在しないデータビット６と７（我々はデータビット０〜５しか持っていない）を指しているため、決して用いられない点である。
【００５５】
上記ＴＦＳを与えると、６ビットのいずれのセットに対してもタグを生成することが可能であり、即ち、６ビット長のＴａｇＤａｔａ配列を与えることが可能である。６ビットが１０１０１０である場合、９ビット位置におけるタグエンコーダからの出力は以下となる。すなわち、
・１（一定）
・１（一定）
・１（一定）
・１（データビット０から）
・０（データビット１から）
・１（データビット２から）
・１（データビット４から）
・０（データビット５から）
・０（データビット３から）
【００５６】
６ビットが１００１１０である場合、９ビット位置におけるタグエンコーダからの出力は以下となる。すなわち、
・１（一定）
・１（一定）
・１（一定）
・１（データビット０から）
・０（データビット１から）
・０（データビット２から）
・１（データビット４から）
・０（データビット５から）
・１（データビット３から）
【００５７】
再び図１を参照すると、サンプルＱＲコードタグは、２１ブロック×２１ブロックである。各ブロックが単一ドットから構成されているのであれば、ＱＲコードタグは２１ドット×２１ドットである。更に、データ領域には２４９のデータブロックがあり、２４９ビットを表している。ＴａｇＷｉｄｔｈとＴａｇＨｅｉｇｈｔの基本パラメータは、ここで両方とも＝２１にセットできる。ＥｎｔｒｙＷｉｄｔｈ＝９である（１＋８、下位ビット用の１と、２４９データビットへのインデックスとなる８）。ＮｕｍＴａｇＤａｔａＢｉｔｓ＝２４９である。従って、タグフォーマット構造は、合計４４１エントリ（２１×２１）となり、各エントリは９ビットである。最初の７つのエントリは、出力ドット一定の１を定義する０００００００１０であり、エントリ８は出力ドット一定の０を定義する０００００００００である。次のエントリはｘｘｘｘｘｘｘｘ１であり、ここで、ｘｘｘｘｘｘｘｘは、第１のライン上の第９ブロックを表すビット数のアドレスである。ブロックが２４９データビットのビット１２９から生じているのであれば、ｘｘｘｘｘｘｘｘは１００００００１である。ブロックが２４９データビットのビット６２から生じているのであれば、ｘｘｘｘｘｘｘｘは００１１１１１０である。合計５つのこれらデータ参照エントリがあり、０００００００００と、７つのエントリの０００００００１０が後に続いてラインを完成させる。
【００５８】
タグフォーマット構造の第２のラインは００００００１０であり、５つのエントリの０００００００００、１つのエントリの００００００１０、１つのエントリの０００００００００が後に続き、それぞれ１，０，０，０，０，０，１および０、の８つの一定のデータ出力ドットを表す。次いで、タグの第２行に対する２４９データビットの種々のビットを指す、データ参照の５つのエントリがある。
【００５９】
タグフォーマット構造の最終ラインは、７つのエントリの００００００１０、１つのエントリの０００００００００、次いで、タグの最終行にある種々のデータビットを指す１３のエントリである。ＴａｇＤａｔａは、タグデータ領域に格納されるべき実際のデータを含む２４９ビットの配列である。これらのビットは、ＱＲタグコード化体系に従って既に冗長コード化されていなければならない。
【００６０】
本発明のタグフォーマット構造は、上記同時係属中のＰＣＴ出願、参照番号ＰＥＣ０２に開示されているタイプのタグエンコーダに実装されてもよい。本明細書中では、タグエンコーダの操作を簡潔に要約する。
【００６１】
タグエンコーダ（ＴＥ）は、タグ使用可能な用途にとっての機能を提供し、（Ｋインクまたは代替物を限られた環境でタグに対して用いてもよいが）普通は、印刷ヘッドのところにＩＲインクの存在が必要である。ＴＥは、印刷されるページの固定データをコード化するとともに、特定のタグデータ値をエラー訂正可能コード化タグへコード化し、引き続き、エラー訂正可能コード化タグはそのページ上へ赤外線または黒いインクで印刷される。ＴＥは、タグを三角形のグリッド上に置いて、横および縦の両方向の配向を可能にしてもよい。基本タグ構造は１６００ｄｐｉでレンダリングされる一方、タグデータは（１６００ｄｐｉでの最小サイズの１ドットを有する）任意の形状になされたマクロドットとしてコード化されてもよい。
【００６２】
ＴＥは、入力として以下を取る。すなわち、
・縦／横フラグ、
・単一タグの構造を定義するテンプレート、
・（ページに対し固定された）固定データビット数、
・固定データビットを冗長コード化する否か、または既にコード化されているものとしてビットを処理するかどうかを定義するフラグ、
・各レコードが、タグの与えられたライン上にタグに対する可変データビットを含んでいる可変データビットレコード数、
・可変データビットを冗長コード化する否か、または既にコード化されているものとしてビットを処理するかどうかを定義するフラグ。
【００６３】
タグエンコーダ（ＴＥ）からの出力は、タグデータが印刷されるべき箇所の１６００ｄｐｉ二段レイヤーである。出力は、１ビット幅ＦＩＦＯを経由している。タグはその後、タグ検出装置によって読み取りできる赤外線吸収インクで印刷されるのが好ましい。
【００６４】
タグエンコーダ（ＴＥ）の概念実装により、タグが、固定および可変データ成分と同様、可変構造を有することができたとしても、ＴＥは範囲制約を特定のコード化パラメータに確実に課す。しかし、これらの制約は、バッファサイズおよびアドレス指定ビット数の直接的な結果であり、最も見込みのあるコード化シナリオのために選択される。バッファサイズおよび対応するアドレス指定を調整して他の実装における任意のコード化パラメータを許可するのは、簡単なことである。
【００６５】
ＴＥは、二段タグビットストリームを二段タグＦＩＦＯに書き込む。ＴＥは、基本タグ構造を持つコード化タグデータを併合し、ドットを出力ＦＩＦＯ内へ後続の印刷のために正しい順序で配置する責任を負っている。コード化タグデータは、実行中にデータビットから生成されて、バッファスペースを最小化する。
【００６６】
ＴａｇＤａｔａ配列は、固定および可変成分に分割される。例えば、タグが５１２ビットのデータを保持している場合、これらビットのいくつかは、すべてのタグに対し固定されてもよい。いくつかは、タグ毎に変化してもよい。例えば、統一商品コードは、国別コードおよび会社コードを許可している。これらのビットはタグ毎に変化しないので、これらのビットは、多数のタグを生成する場合、バンド幅を低減させるためにタグジェネレータにリロードできる。別の実施例は、Ｎｅｔｐａｇｅタグジェネレータである。単一の印刷ページは、図２〜４に示す形式の多数のＮｅｔｐａｇｅタグを含んでいる。ページＩＤは、各タグ内の残りのデータが各タグに対して異なるかもしれないが、すべてのタグにわたって一定である。各タグに対し、タグエンコーダに渡される可変データの量を減らすことによって、エンコーダに対する全体的なバンド幅を低減することができる。
【００６７】
エンコーダの実施の形態により、これらのパラメータは、黙示的か、明示的のいずれかであり、システムによってレンダリング可能なタグの大きさを制限してもよい。例えば、ソフトウェアタグエンコーダは完全に可変であってもよく、他方、ハードウエアタグエンコーダはタグデータビットの最大数を有していてもよい。
【００６８】
外部エンコーダによってコード化されるＴａｇＤａｔａビットの完全数を受け入れる代わりに、タグエンコーダは、基本的な非冗長コード化データビットを受け入れ、各タグに対する要求に応じてそれらをコード化してもよい。これは、バンド幅の大幅な節約をもたらすことができる。Ｎｅｔｐａｇｅタグの場合では、同時係属中のＰＣＴ出願ＰＥＣ０２に記載のように、元のデータの１２０ビットだけがタグ毎に提供され、タグエンコーダはこれらの１２０ビットを３６０ビットにコード化する。タグエンコーダに内蔵された冗長エンコーダを有することにより、必要とする有効バンド幅は、２／３まで低減される。
【００６９】
上記のＴＦＳの説明では、ビット０は、出力ドットがエントリとともに直ちに格納される（ビット１が出力ビット値を含む）かどうか、または、より高いビットがアドレスを形成してＴａｇＤａｔａ構造を参照するかどうか、を定義している。それは異なるビット位置決めを用いて同じ情報を表すためのわずかな変更である。
【００７０】
特定種類のタグに対する記憶装置要件を低減するために、ＴＦＳは二重間接参照を用いることができる。上記の説明において、ＴＦＳエントリのビット０がセットされる場合、上位ビットは、使用されるべきＴａｇＤａｔａ配列からビットのアドレスを形成する。しかし、もしＴＦＳにおけるエントリの合計数が大きく、ＴＦＳの与えられたラインに対する異なるビットの最大数がＮｕｍＴａｇＤａｔａＢｉｔｓより比較的小さければ、二重間接参照を用いるのが便利であろう。
【００７１】
二重間接参照を用いて、ＴＦＳのデータアドレスエントリは第２の配列を指し、ＴＦＳラインの終端に格納される。第２の配列は、使用するＴａｇＤａｔａ配列内の実アドレスを含んでいる。例えば、タグの与えられたライン上で用いられる８つの異なるデータビットだけが常にある場合、ＥｎｔｒｙＷｉｄｔｈは、４（データビットを参照するのに必要か否か、または、直接ビット１を使用するのに必要かどうかを決定する１ビット）にセットされてもよい。ビット０が１の場合、ビット１〜３は、アドレス０〜７を形成するよう用いられる。アドレスは、ＴａｇＤａｔａ配列を指す８つのｎ−ビットエントリのテーブルを参照する。ＴａｇＤａｔａ配列に５１２エントリがあれば、ｎ＝９である。ＴａｇＷｉｄｔｈ＝１００であれば、基本コード化は、ＴＦＳの各ラインに対し１０００ビット（１００×１０ビット）を使用しているであろう。もし二重間接参照が用いられ、タグの与えられたライン上で用いられる８つの異なるデータビットだけが常にあれば、ＴＦＳの各ラインは、４７２ビット（１００×４ビット＋８×９ビット）を必要とする。節減は約５０％であり、用途によっては有用な係数であろう。
【００７２】
別の修正は、二段出力からコントーン（ｃｏｎｔｏｎｅ）出力へ変更することである。本発明において、各出力ドットは、通常オンかオフのいずれかである。ビット０＝０であれば、ビット１は使用する出力ビットを含んでいる。これは、より大きいビット数を形成するよう容易に拡張できる。例えば、４ビットコントーンの印刷が要求されると、即ちビット０＝０であると、出力はビット１〜３により形成される４ビットである。もちろん、ＥｎｔｒｙＷｉｄｔｈは適切に増加されることを必要とする。
【００７３】
同様に、ＴａｇＤａｔａ配列を指すアドレスは、ｎ番目のエントリを指すものであり、ここで、エントリが単一ビットである代わりに、（各コントーン出力ドットでのビット数による）複数のビットである。
【００７４】
完全なＴＦＳが、ローカルに、例えば、チップ上に格納される場合、それは、行方向または列方向のいずれかでアクセスされて、横および縦方向を提供することができる。タグフォーマット構造が、ローカルに格納されず（即ち、外部メモリ）、１度に１ラインずつアクセスされる場合、構造の２つのコピー−一方は横方向印刷用で、他方は縦方向印刷用−を有していることが好ましい。
【００７５】
例えば、同時係属中のＰＣＴ出願ＰＥＣ０２では、タグエンコーダがＡＳＩＣ上にある一方で、ＴＦＳは外部ＤＲＡＭ内にある。ＡＳＩＣに内蔵される記憶装置を低減するため、ＴＦＳのカレントラインのみが１度にロードされる。ＴＦＳへのアクセスはラインベースであるため、それらは外部ＤＲＡＭに格納される２つのＴＦＳ構造−一方は横方向印刷用で、他方は縦方向印刷用−であることを必要とする。理論的に、それらは任意に異なることができる。しかし、実際問題として、それらは、９０度回転された同一のＴＦＳである。
【００７６】
明細書全体にわたって、発明をいずれかひとつの実施の形態または特長の特定の集合に制限することなく、本発明の好ましい実施の形態を説明することを目的としてきた。関連技術に精通する者は、特定の実施の形態から変形を実現するであろうが、それにもかかわらず、それらは本発明の適用範囲内に収まる。
【図面の簡単な説明】
【図１】従来技術の二次元クイックレスポンスコードを示す。
【図２】Ｎｅｔｐａｇｅタグ背景パターンを示す。
【図３】図２に示すＮｅｔｐａｇｅタグ内のデータ領域を示す。
【図４】１６００ｄｐｉで描写されるデータを有するＮｅｔｐａｇｅタグの拡大図である。
【図５】タグ成分上の出力解像度の効果を示す。
【図６】二次元クイックレスポンスコードにおけるデータ表現を示す。
【図７】単純な３×３タグ構成を示す。
【図８】図７のタグの拡大バージョンを示す。
【符号の説明】
１０…固定ブロック
１１…データ領域
２０…円形ロケータ成分
２１…配向成分
３０…データ領域
６０…オン
６１…オフ

Claims

データパッケージテンプレートであって、
任意の形状になされた一定の背景パターンおよび、
任意の形状になされた少なくともひとつのデータ領域を備え、
前記データ領域は、コード化方式によって決定された位置に配置されるデータドットを含む、
データパッケージテンプレート。
前記任意の形状になされた一定の背景パターンは、前記データ領域の位置を突き止めるよう読み取り可能な少なくともひとつのロケータ成分を含む、
請求項１記載のデータパッケージテンプレート。
前記データパッケージテンプレートは二次元である、
請求項１記載のデータパッケージテンプレート。
前記データパッケージテンプレートは二次元であり、前記任意の形状になされた一定の背景パターンは、前記少なくともひとつのデータ領域の配向を識別するよう読み取り可能な配向成分を含む、
請求項１記載のデータパッケージテンプレート。
前記ロケータ成分が円形である、
請求項２記載のデータパッケージテンプレート。
前記背景パターンおよび前記データドットは、光学式スキャナによって読み取り可能な、光学的に読み取り可能な要素である、
請求項１記載のデータパッケージテンプレート。
前記背景パターンおよび前記データドットは、触覚型スキャナによって読み取り可能な触覚要素である、
請求項１記載のデータパッケージテンプレート。
前記コード化方式は、各ドットが前記背景パターンの一部であるか、または前記データ領域の一部であるか、そして前記ドットが前記データ領域の一部である場合にはデータであるか否かについて識別する、
請求項１記載のデータパッケージテンプレート。
前記ドットが二段である、
請求項１記載のデータパッケージテンプレート。
前記ドットが連続階調である、
請求項１記載のデータパッケージテンプレート。
複数のドットから形成されたデータパッケージテンプレート内のデータをパッケージ化する方法であって、
前記データパッケージ内の各ドット位置に対するエントリのビット配列を構成するステップであって、前記エントリの配列は、前記各ドットが一定背景パターンの一部であるのか、またはデータ領域の一部であるのかを定義し、
前記データ領域への格納のために前記データをコード化するステップ、および、
前記データを用いてコード化された前記複数のドットを印刷するステップを含む方法。
前記ドットは二段ドットとして印刷される、
請求項１１記載の方法。
前記ドットは連続階調ドットとして印刷される、
請求項１１記載の方法。
前記コード化ステップは冗長符号化を含む、
請求項１１記載の方法。
前記コード化ステップは二重間接参照を含む、請求項１１記載の方法。