JP2017021839A

JP2017021839A - 複数のサードパーティ・プラグインのチェーン化を制御する条件付きプログラミング論理を有するコンフィギュレーション・ファイルを用いての複数のサードパーティ・コードのプラグインをサポートするデジタル画像キャプチャおよび処理のシステム

Info

Publication number: JP2017021839A
Application number: JP2016186616A
Authority: JP
Inventors: テイラー・スミス; Smith Taylor; マシュー・パンコウ; Pankow Matthew; メリッサ・フュータック; Fiutak Melissa; シャオシュン・ジュウ; Xiaoshun Ju
Original assignee: Metrologic Instruments Inc
Current assignee: Metrologic Instruments Inc
Priority date: 2011-01-18
Filing date: 2016-09-26
Publication date: 2017-01-26
Also published as: EP2477138A1; US20110284625A1; CN102737215B; CN102737215A; EP2477138B1; JP2012150808A

Abstract

【課題】多層モジュール式ソフトウェア、およびプラグイン拡張可能なアーキテクチャをサポートする、手持可能なデジタル画像キャプチャおよび処理のシステムを提供する。
【解決手段】デジタル画像キャプチャおよび処理のシステムは、適したハードウェア・プラットホーム、通信プロトコルおよびユーザ・インターフェースを備える、画像を取り込む携帯電話、デジタル・カメラ、ビデオ・カメラ、移動演算端末および携帯型データ端末（ＰＤＴ）とすることができる。複数のサードパーティ・プラグインを制御（即ち、調整）するコンフィギュレーション・ファイルは、複数のサードパーティ・プラグインをチェーン化（即ち、順序付け）する条件付きプログラミング論理を含み、それにより、顧客が、複数のプラグイン間の対話およびコンフィギュレーションを可能にする。
【選択図】図１Ａ

Description

本開示は、１次元（１Ｄ）および２次元（２Ｄ）のバー・コード・シンボルを読み取る多様なデジタル画像処理モードを有する、手で支持できる携帯型のエリア・タイプのデジタル・バー・コード・リーダ、ならびにシステムの特徴および機能を変更および拡張する改善された方法に関する。

自動識別工業の現況は、（ｉ）業界により開発および採用されてきた様々なクラスのバー・コード・シンボル体系、および（ｉｉ）様々なユーザ環境でそのようなバー・コード・シンボル体系を読み取るために開発および使用されてきた装置の種類の点から理解することができる。

一般に、現在３つの主要なバー・コード・シンボル体系のクラスが存在する。即ち、ＵＰＣ／ＥＡＮ、Ｃｏｄｅ３９などのような１次元（１Ｄ）バー・コード・シンボル体系と、１Ｄスタックド・バー・コード・シンボル体系、Ｃｏｄｅ４９、ＰＤＦ４１７などと、２次元（２Ｄ）データ・マトリックス・シンボル体系とが存在する。またここ数年、業界のバー・コード・シンボルの読取りの必要を満たすために、レーザ走査ベースのバー・コード・シンボル・リーダおよび撮像ベースのバー・コード・シンボル・リーダが開発されてきた。

撮像ベースのバー・コード・シンボル・リーダは、レーザ走査ベースのバー・コード・シンボル・リーダに対して複数の利点を有する。即ち、それらは、ＰＤＦ４１７シンボル体系などのようなスタックド２Ｄシンボル体系を読み取る能力がより高く、データ・マトリックス・シンボル体系などのようなマトリックス２Ｄシンボル体系を読み取る能力がより高く、バー・コードの向きにかかわらずバー・コードを読み取る能力がより高く、製造コストがより低く、またＯＣＲ、セキュリティ・システムなどのような、バー・コード走査に関係しないこともあり得る他のアプリケーションで使用する潜在能力を有する。しかしながら、従来技術の撮像ベースのバー・コード・シンボル・リーダは、複数の短所および欠点を有する。

大部分の従来技術の手持ち式の光学読取デバイスは、バー・コード・プログラミング・メニューからバー・コードを読み取ることにより、または米国特許第５，９２９，４１８号に教示されているローカルのホスト処理装置を使用することにより、プログラムを書き換えることができる。しかしながら、これらのデバイスは通常、エンドユーザのアプリケーション環境に配備される前に、作業現場またはベンチ（仕事台）で、動作するようにプログラムされたモードで動作するように制限される。従って、そのような従来技術の撮像ベースのバー・コード読取システムの静的に設定された性質は、これらのシステムの性能、ならびにサードパーティ（第三者製造）製品（即ち、システムおよびデバイス）へ容易に組み込まれる能力を、制限してきた。

従来技術の撮像ベースのバー・コード・シンボル・リーダは、通常、バー・コード・メニューからバー・コード・シンボルを読み取ることによりプログラムされる任意の特定のシステム動作モード内で何れの復号化アルゴリズムを使用すべきかを管理するために、テーブルおよびバー・コード・メニューを使用する必要がある。

また、それぞれ参照により本明細書に組み込まれている、米国特許第６，３２１，９８９号、第５，９６５，８６３号、第５，９２９，４１８号、および第５，９３２，８６２号に開示されているように、そのような従来技術の撮像ベースのバー・コード・シンボル・リーダのハードウェア・プラットホームの複雑さが原因で、エンドユーザは、システムのプログラミング用のタイプのバー・コード・シンボルを読み取ることによりシステム内で制限された範囲の機能を変更すること以外は、カスタマイズされたアプリケーション要件に合わせてシステムの特徴および機能を変更することが許されない。

また、専用の画像処理ベースのバー・コード・シンボル読取デバイスは、通常、揮発性および不揮発性メモリの量などのような、非常に制限された資源を有する。従って、これらのデバイスは通常、汎用のコンピュータ・システムで一般に使用可能な豊富なツールをもたない。更に、顧客またはサードパーティは、従来の画像処理ベースのバー・コード・シンボル読取システムまたはデバイスの挙動を強化または変更する必要がある場合、デバイスの製造業者に連絡し、「標準」ソフトウェアの必要な変更や、デバイス内へ独自のソフトウェアを組み込む方法について、交渉する必要がある。これには、通常、相手先商標製造業者（ＯＥＭ）によるソフトウェアの再設計または再コンピレーションが伴う。このソフトウェア変更プロセスには、費用も時間もかかる。

また、従来技術の撮像ベースのバー・コード・シンボル・リーダの機械的、電気的、光学的、およびソフトウェア上の設計における制限の結果、そのような従来技術のリーダでは通常、（ｉ）ユーザは、レーザ走査ベースのバー・コード・シンボル・リーダおよびＰＤＦ４１７およびデータ・マトリックスなどのような２Ｄシンボル体系で容易かつ簡単に、高密度の１Ｄバー・コードを読み取ることができず、また（ｉｉｉ）エンドユーザは、そのようなシステムのハードウェア・プラットホーム、通信インターフェース、およびユーザ・インターフェースに関する詳細な知識がなければ、そのような従来技術のシステムの特徴および機能を変更することができなかった。

従って、従来技術の方法および装置の短所および欠点を回避する、デジタル撮像モジュールを含めての、デジタル撮像ベースのコード・シンボル読取システムの機能を変更および拡張する改善された方法および装置が、当技術分野で大いに必要とされている。

米国特許第５，９２９，４１８号米国特許第６，３２１，９８９号米国特許第５，９６５，８６３号米国特許第５，９３２，８６２号米国特許第５，９４２，７４１号米国特許第６，６１９，５４９号

従って、本開示の主な目的は、従来技術の方法および装置の短所および欠点を回避するように、サードパーティのコードのプラグイン（サードパーティ・コード・プラグイン）を用いて、システムの特徴および機能の変更を可能にする新規なデジタル画像キャプチャおよび処理のシステムを提供することである。

本開示の別の目的は、顧客、ＶＡＲ、およびサードパーティが、システムのＯＥＭに連絡して所望の改善をシステムに組み込む方法について交渉する必要なく、システムの１組の標準的な特徴および機能を変更および／または拡張できるようにする、デジタル画像キャプチャおよび処理のシステムを提供することである。

本開示の別の目的は、顧客、ＶＡＲ、およびサードパーティが、システムのハードウェア・プラットホーム、外部環境との通信、およびユーザ関連インターフェースに関する詳細な知識がなくても、ＯＥＭ仕様に従って独自のソフトウェアを独立して設計し、そのソフトウェアをシステムへプラグインし、それによりデバイスの挙動を効果的に変更できるようにする、画像キャプチャおよび処理のシステムを提供することである。

本開示の別の目的は、そのようなデジタル画像キャプチャおよび処理のシステムの顧客または任意のサードパーティに、基礎となるハードウェア、通信、およびユーザ関連インターフェースに干渉することなく、システムの挙動を強化または変更する方法および手段を提供することである。

本開示の別の目的は、そのようなデジタル画像キャプチャおよび処理のシステムのエンドユーザならびにサードパーティに、デバイスのハードウェアの詳細に関する知識を必要とすることなく、デバイスで独自のプラグイン・モジュールを設計、開発、およびインストールする方法および手段を提供することである。

本開示の別の目的は、相手先商標製造業者（ＯＥＭ）へ、ＯＥＭのプラグイン・モジュールをデジタル画像キャプチャおよび処理のシステムへインストールする方法および手段を提供することであり、この方法および手段は、サードパーティ・プラグインに関してのシステムの特徴および機能に対して確立された仕様を満たすという条件ではあるが、インストールされたサードパーティのプラグイン（ソフトウェア）・モジュールに関する知識なしでインストールする方法および手段である。

本開示の別の目的は、デジタル画像キャプチャおよび処理のシステムの顧客およびサードパーティに、独自のプラグイン・モジュールをインストールし、独自の必要性に従って互いに独立してデバイスの「標準」の挙動を強化または変更する方法および手段を提供することである。

本発明の別の目的は、システムのファームウェアとは独立してソフトウェア・プラグイン（例えば、アプリケーション）を開発および維持できる、デジタル画像キャプチャおよび処理のシステムに対して特別に設計されたモジュール式のソフトウェア開発プラットホームを提供することである。

本発明の別の目的は、サードパーティおよび顧客が、多様なアプリケーション環境におけるシステムの有用性および／または性能を更に改善するために、デジタル画像キャプチャおよび処理のシステム上で複数のプラグイン（例えば、アプリケーション）を互いに関連してインストールし動作させることができる、デジタル画像キャプチャおよび処理のシステムに対するモジュール式のソフトウェア開発プラットホームを提供することである。

本発明の別の目的は新規なデジタル画像キャプチャおよび処理のシステムを提供することであり、この新規なデジタル画像キャプチャおよび処理のシステムは、同じタイプの複数のサードパーティ・プラグインをサードパーティによりアプリケーション層でプログラムでき、これらの複数のサードパーティ・プラグインを制御（即ち、調整）するコンフィギュレーション・ファイルが、複数のサードパーティ・プラグインをチェーン化（chain
）する（即ち、順序付けする）条件付きプログラミング論理を含み、それにより、顧客は、複数のプラグイン間の対話（相互作用）およびコンフィギュレーションを可能にし、システムの機能を強化することができる。

本発明の別の目的は、バー・コード・シンボルの読み取り、パターン認識（バーコード
以外）、マーク認識（バーコード以外）、一意のフォント認識、２Ｄバー・コードで一般に見られる長いデータ列の高性能のフォーマッティング／解析（パース）、強化されたセキュリティのための暗号化／暗号解読などに使用できるデジタル画像キャプチャおよび処理のシステムを提供することである。

本開示の別の目的は、システムのハードウェア・プラットホーム、外部環境との通信、およびユーザ関連インターフェースに関する詳細な知識を必要とすることなく、設計者／製造業者により制約されたシステムの挙動の変更をサポートする画像キャプチャおよび処理のシステムを提供することである。

本開示の別の目的は、現在の撮像技術を使用して、従来のレーザ走査バー・コード・シンボル・リーダにより実現される速度および信頼性で、１Ｄおよび２Ｄバー・コード・シンボル体系を自動的に読み取ることが可能な、新規な手で支持できるデジタル撮像ベースのバー・コード・シンボル・リーダを提供することである。

本開示のこれらの目的および他の目的は、以下および本明細書に添付の特許請求の範囲で、より明らかに理解されるであろう。

本開示の目的をどのように実施するかをより良く理解するために、以下の例示的な実施形態の詳細な説明を、以下に簡単に説明する添付の図面と一緒に読むとよい。

図１Ａは、本開示の革新的なプラグイン・プログラミング方法を使用して変更および／または拡張できる多数の標準システムの特徴および機能を提供する様々なサブシステムをサポートすることが可能な多層のソフトウェア・システム・アーキテクチャを用いる、本開示のデジタル画像キャプチャおよび処理のシステムの概略図である。図１Ｂは、図１Ａに表す本開示のデジタル画像キャプチャおよび処理のシステムのシステム・アーキテクチャの概略図である。図１Ｃ１〜図１Ｃ３はともに、図１Ａおよび図１Ｂに表す本開示のデジタル画像キャプチャおよび処理のシステムのシステム・アーキテクチャにおいて提供されるそれぞれのサブシステムによりサポートされる特徴および機能を示す表である。図１Ｃ１〜図１Ｃ３はともに、図１Ａおよび図１Ｂに表す本開示のデジタル画像キャプチャおよび処理のシステムのシステム・アーキテクチャにおいて提供されるそれぞれのサブシステムによりサポートされる特徴および機能を示す表である。図１Ｃ１〜図１Ｃ３はともに、図１Ａおよび図１Ｂに表す本開示のデジタル画像キャプチャおよび処理のシステムのシステム・アーキテクチャにおいて提供されるそれぞれのサブシステムによりサポートされる特徴および機能を示す表である。図１Ｄは、ともにインターフェースされるデジタル・カメラ基板および印刷回路（ＰＣ）基板を使用して、図１Ａ〜図１Ｃ３に示す本開示のデジタル画像キャプチャおよび処理のシステムを実施できることを示す概略図である。図１Ｅは、単一の複合型のデジタル・カメラ／ＰＣ基板を使用して、図１Ａ〜図１Ｃ３に示す本開示のデジタル画像キャプチャおよび処理のシステムを実施できることを示す概略図である。図１Ｆは、サードパーティ製品内で、図１Ａ〜図１Ｅに示す本開示のデジタル画像キャプチャおよび処理のシステムを組み込みまたは実施できることを示す概略図であり、サードパーティ製品は、デジタル画像処理ベースのバー・コード・シンボル読取システム、ＯＣＲシステム、物体認識システム、携帯型データ端末（ＰＤＴ）、モバイル電話、コンピュータ・マウス型のデバイス、パーソナル・コンピュータ、キーボード、民生用機器、自動車、ＡＴＭ、販売機、回収機、小売用ＰＯＳベースの取引システム、２Ｄまたは２Ｄデジタイザ、およびＣＡＴ走査システム、自動車識別システム、包装検査システム、個人識別システムなどを含むが、これらのみに限定されるものではない。図２Ａは、本開示の第１の例示的な実施形態の手で支持できるデジタル撮像ベースのバー・コード・シンボル読取デバイスの背面斜視図である。図２Ｂは、本開示の第１の例示的な実施形態の手で支持できるデジタル撮像ベースのバー・コード・シンボル読取デバイスの前面斜視図である。図２Ｃは、本開示の第１の例示的な実施形態の手で支持できるデジタル撮像ベースのバー・コード・シンボル読取デバイスの立面左側側面図である。図２Ｄは、本開示の第１の例示的な実施形態の手で支持できるデジタル撮像ベースのバー・コード・シンボル読取デバイスの立面右側側面図である。図２Ｅは、本開示の第１の例示的な実施形態の手で支持できるデジタル撮像ベースのバー・コード・シンボル読取デバイスの立面背面図である。図２Ｆは、照射サブシステムおよび画像取込サブシステムに関連する構成要素を示す、本開示の第１の例示的な実施形態の手で支持できるデジタル撮像ベースのバー・コード・シンボル読取デバイスの立面正面図である。図２Ｇは、本開示の第１の例示的な実施形態の手で支持できるデジタル撮像ベースのバー・コード・シンボル読取デバイスの底面図である。図２Ｈは、本開示の第１の例示的な実施形態の手で支持できるデジタル撮像ベースのバー・コード・シンボル読取デバイスの上面背面図である。図２Ｉは、本開示の第１の例示的な実施形態の手で支持できるデジタル撮像ベースのバー・コード・シンボル読取デバイスの第１の斜視分解図である。図２Ｊは、本開示の第１の例示的な実施形態の手で支持できるデジタル撮像ベースのバー・コード・シンボル読取デバイスの第２の斜視分解図である。図２Ｋは、本開示の第１の例示的な実施形態の手で支持できるデジタル撮像ベースのバー・コード・シンボル読取デバイスの第３の斜視分解図である。図２Ｌ１は、図２Ａ〜図２Ｋに示す手で支持できるデジタル撮像ベースのバー・コード・シンボル読取デバイスのシステム設計を表す概略ブロック図である。図２Ｌ２は、図２Ｍに示す３層の演算プラットホームを使用して実現される多モードの画像処理ベースのバー・コード・シンボル読取サブシステムの概略ブロック図である。図２Ｍは、図２Ａ〜図２Ｌ２に示す手で支持できるデジタル撮像ベースのバー・コード・シンボル読取デバイスに対するシステムの実装形態を表す概略図である。図３Ａは、狭域および広域の画像キャプチャ動作モード中の、多モードの画像形成および検出サブシステムのＦＯＶ内の狭帯域照射の近視野と遠視野と狭域と広域との空間関係を示す概略図である。図３Ｂは、第１の例示的な実施形態の手で支持できるデジタル撮像ベースのバー・コード・シンボル読取デバイスの斜視部分切欠図であり、狭帯域透過型の光学フィルタ・システムを通じて可視の狭帯域の照射を送り、その狭帯域の照射で物体を照射するＬＥＤベースの多モード照射サブシステムを示し、また、照射された物体から反射された光線を収集して集束させる低域通過フィルタを画像感知アレイの前に含む画像形成光学系を示し、それにより、物体の画像が、狭帯域の照射内に含まれる光の光学成分のみを使用して形成および検出され、周囲光の他の成分はすべて、画像感知アレイにおける画像検出前に実質上除かれる。図３Ｃは、第１の例示的な実施形態の手で支持できるデジタル撮像ベースのバー・コード・シンボル読取デバイスで使用される光学構成要素の幾何学上の配置を示す概略図であり、赤色波長を反射する高域通過レンズ・エレメントが、画像形成レンズ・エレメントの前のデバイスの撮像窓に配置され、低域通過フィルタが、画像形成エレメント間の画像センサの前に配置され、狭帯域の照射内の光学構成要素のみを使用して画像感知アレイで物体を撮像し、周囲光の他の成分をすべて拒否する。図４は、本開示の手で支持できるデジタル撮像ベースのバー・コード・シンボル読取デバイスの３層のソフトウェア・アーキテクチャに関連するソフトウェア・モジュールを示す概略図であり、それらのソフトウェア・モジュールは、ソフトウェア・アーキテクチャのアプリケーション層内に常駐するメイン・タスク・モジュール、コードゲート・タスク・モジュール、狭域照射タスク・モジュール、Ｍｅｔｒｏｓｅｔタスク・モジュール、アプリケーション・イベント・マネージャ・モジュール、ユーザ・コマンド・テーブル・モジュール、コマンド・ハンドラ・モジュール、プラグイン・コントローラ、ならびにプラグイン・ライブラリおよびコンフィギュレーション・ファイルと、ソフトウェア・アーキテクチャのシステム・コア（ＳＣＯＲＥ）層内に常駐するタスク・マネージャ・モジュール、イベント・ディスパッチャ・モジュール、入出力マネージャ・モジュール、ユーザ・コマンド・マネージャ・モジュール、タイマ・サブシステム・モジュール、入出力サブシステム・モジュール、およびメモリ制御サブシステム・モジュールと、ソフトウェア・アーキテクチャのＬｉｎｕｘ（登録商標）オペレーティング・システム（ＯＳ）層内に常駐し、標準または専有の通信インターフェースを介して外部（ｈｏｓｔ０プラグイン開発プラットホーム）と動作可能に通信する、プラグイン・コントローラと動作可能に通信するＬｉｎｕｘカーネル（Ｋｅｒｎａｌ）・モジュール、Ｌｉｎｕｘ（登録商標）ファイル・システム・モジュール、およびデバイス・ドライバ・モジュールとである。図４Ａ１は、本開示の手で支持できるデジタル撮像ベースのバー・コード・シンボル読取デバイス内で用いられるＬＥＤベースの多モードの照射サブシステムから生成される狭域照射、近視野広域照射、および遠視野広域照射の範囲を示す概略図である。図４Ａ２は、本開示の手で支持できるデジタル撮像ベースのバー・コード・シンボル読取デバイスで用いられるＬＥＤベースの多モードの照射サブシステムによりサポートされる各照射モードの幾何学上の特質および特性を示す表である。図５は、本開示の撮像ベースのバー・コード読取システムのアプリケーション層内のタスクに対するプラグインを開発するコンピュータ・ソフトウェア開発プラットホームの例示的な実施形態の斜視図である。図６は、本開示の方法を実施することを伴うステップを示す高次の流れ図であり、本開示の撮像ベースのバー・コード・シンボル読取システムのシステム挙動（即ち、機能）は、製造業者定義の１組の制約（即ち、変更可能な特徴および特徴内の機能に課される制約）内で、エンドユーザがシステムのアプリケーション層内の任意の変更可能なタスクに対して「プラグイン・モジュール」（即ち、ライブラリ）を開発、インストール／配備、および設定（コンフィギュレーション）することにより、エンドユーザにより変更でき、その結果、エンド・ユーザは、システムのハードウェア・プラットホーム、環境との通信、および／またはユーザ・インターフェースに関する詳細な知識を必要とすることなく、システムの標準的な（即ち、事前指定の）特徴および機能を柔軟に変更および／または拡張き、カスタマイズされたエンドユーザ・アプリケーション要件を満たすことができる。図７Ａは、「変更可能な」メイン・タスクがシステムのアプリケーション層内で（イネーブルにされて）実行されるときに行われる動作を示す例示的な流れ図である。図７Ｂは、システムのアプリケーション層の画像処理ベースのバー・コード・シンボル読取サブシステム・ソフトウェア・モジュール内で「画像処理」と呼ばれるシステムの機能が実行されるときに行われる動作を示す例示的な流れ図である。図７Ｃは、システムのアプリケーション層の変更可能なメイン・タスク・ソフトウェア・モジュール内で「画像処理およびバー・コード復号化」と呼ばれるシステムの機能が実行されるときに行われる動作を示す例示的な流れ図である。図７Ｄは、システムのアプリケーション層の変更可能なメイン・タスク内で「データ出力手順」と呼ばれるシステムの機能が実行されるときに行われる動作を示す例示的な流れ図である。図７Ｅは、システムのアプリケーション層のデータ出力手順ソフトウェア・モジュール内で「データ・フォーマッティング手順」と呼ばれるシステムの機能が実行されるときに行われる動作を示す例示的な流れ図である。図７Ｆは、システムのアプリケーション層のデータ出力手順ソフトウェア・モジュール内で「スキャナ・コンフィギュレーション手順」と呼ばれるシステムの機能が実行されるときに行われる動作を示す例示的な流れ図である。図８は、本開示のデジタル画像キャプチャおよび処理のシステムの概略図であり、このシステムは、図４に示す多層ソフトウェア・アーキテクチャを有し、システムのアプリケーション層の複数のサードパーティ・ソフトウェア・プラグインのチェーン化をサポートするものであり、複数のサードパーティ・プラグイン・コードは、デジタル画像キャプチャおよび処理のシステムにおける複数のサードパーティ・プラグインの順序付け即ちチェーン化を制御する条件付き論理を有するコンフィギュレーション・ファイルを含む。

添付の図面内の図を参照して、本開示の手で支持できる撮像ベースのバー・コード・シンボル読取システムの様々な例示的な実施形態について詳細に説明する。図面では、同じエレメントは同じ参照番号を使用して示す。

［サードパーティ・コードのプラグインを用いてのシステムの特徴および機能の変更および／または拡張を可能にする多層ソフトウェア・ベースのシステム・アーキテクチャを用いる本開示のデジタル画像キャプチャおよび処理のシステムの概要］

本開示は、ＶＡＲ、ＯＥＭなど（即ち、元のシステム設計者以外）が、システムのハードウェア・プラットホーム、外部環境との通信、および／またはユーザ関連インターフェースに関する詳細な知識を所有することを必要とせずに、非常に広いクラスのデジタル画像キャプチャおよび処理のシステムおよびデバイスの標準システムの特徴および機能を変更および／または拡張できるようにする新規なシステム・アーキテクチャ、プラットホーム、および開発環境を提供することにより、レーザおよびデジタル撮像ベースのバー・コード・シンボル・リーダを含めての従来技術のデジタル画像キャプチャおよび処理のシステムおよびデバイスの短所および欠点に対処する。この新規な手法は、サードパーティ製品内で、出願人および譲受人であるＭｅｔｒｏｌｏｇｉｃＩｎｓｔｒｕｍｅｎｔｓ，Ｉｎｃ．（メトロロジック・インストルメンツ社）などのような熟達したデジタル・イメージャの設計者および製造業者のデジタル画像キャプチャおよび処理技術を用いたいと望むサードパーティにとって、多数の利益および利点を有するが、手元のエンドユーザ・アプリケーションの要件を満たすために、そのようなシステムの特徴および機能の変更および／または拡張プロセス中に貴重な知的財産およびノウ・ハウを犠牲にする、またはそれらを開示する危険を冒す必要がない。

図１Ａ〜図１Ｂに示すように、本開示のデジタル画像キャプチャおよび処理のシステム１０００は、本開示の革新的なプラグイン・プログラミング方法を使用して変更および／または拡張できる多数の標準システムの特徴および機能を提供する様々なサブシステムをサポートすることが可能な多層ソフトウェア・システム・アーキテクチャを用いる。本明細書に開示する本開示の例示的な実施形態では、そのようなサブシステムは、物体存在検出サブシステム、物体範囲検出サブシステム、物体速度検出サブシステム、物体寸法判定サブシステム、視野（ＦＯＶ）照射サブシステム、撮像形成および検出（ＩＦＤ）サブシステム、デジタル画像処理サブシステム、音声インジケータ出力サブシステム、視覚インジケータ出力サブシステム、電力管理サブシステム、画像時間／空間スタンピング・サブシステム、ネットワーク（ＩＰ）アドレス記憶サブシステム、遠隔監視／サービス提供サブシステム、入出力サブシステム、ならびにシステム制御および／または調整サブシステムを含み、示されたように全体として組み込まれている。

本明細書に開示する本開示の例示的な実施形態に関して、例示的な標準システムの特徴および関数が図１Ｃ１およびＣ２の表に説明されている。そのようなシステムの特徴（機能、feature）および機能（関数、function）について、本開示のデジタル画像キャプチ
ャおよび処理における特徴および機能を全体としてサポートするサブシステムと関連して以下に説明する。

システム・トリガ特徴（即ち、トリガ・イベント生成）：物体存在検出サブシステム
標準システム機能：
自動トリガ（即ち、ＩＲ物体存在検出）（例えば、ＯＮ（オン）、ＯＦＦ（オフ））
手動トリガ（例えば、ＯＮ、ＯＦＦ）
半自動トリガ（例えば、ＯＮ、ＯＦＦ）

物体範囲検出特徴：物体範囲検出サブシステム
標準システム機能：
（ＩＲベース）長／短範囲検出（例えば、ＯＮ、ＯＦＦ）
（ＩＲベース）量子化／増分範囲検出（例えば、ＯＮ、ＯＦＦ）

物体速度検出特徴：物体速度検出サブシステム
標準システム機能：
ＬＩＤＡＲベースの物体速度検出（例えば、ＯＮ、ＯＦＦ）
ＩＲ−ＰＵＬＳＥ−ＤＯＰＰＬＥＲ（ＩＲパルス・ドップラ）物体速度検出（例えば、ＯＮ、ＯＦＦ）

物体寸法判定特徴：物体寸法判定サブシステム
標準システム機能：
ＬＩＤＡＲベースの物体寸法判定（例えば、ＯＮまたはＯＦＦ）
構造化レーザ光物体寸法判定（例えば、ＯＮまたはＯＦＦ）

視野（ＦＯＶ）照射特徴：照射サブシステム
標準システム機能：
照射モード（例えば、周囲／ＯＦＦ、ＬＥＤ連続、およびＬＥＤストロボ／フラッシュ）
自動照射制御（即ち、ＯＮまたはＯＦＦ）
照射フィールド・タイプ（例えば、狭域近視野照射、広域遠視野照射、狭域視野の照射、広域視野の照射）

撮像形成および検出特徴：撮像形成および検出（ＩＦＤ）サブシステム
標準システム機能：
画像キャプチャ・モード（例えば、狭域画像キャプチャ・モード、広域画像キャプチャ・モード）
画像キャプチャ制御（例えば、単一フレーム、動画フレーム）
画像感知アレイの電子利得（例えば、１〜１０，０００）
画像感知アレイにより検出される各画像フレームに対する露出時間（例えば、ミリ秒単位でプログラム可能）
画像感知アレイ内の撮像画素の各ブロックに対する露出時間（例えば、ミリ秒単位でプログラム可能）
視野マーキング（例えば、１ドット・パターン、２ドット・パターン、４ドット・パターン、可視ライン・パターン、４ドットおよびライン・パターン）

デジタル画像処理特徴：デジタル画像処理サブシステム
標準システム機能：
画像感知アレイ上の画像クロッピング・パターン（例えば、ｘ１、ｙ２、ｘ２、ｙ２、ｘ３、ｙ３、ｘ４、ｙ４）
画像フレームの前処理（例えば、デジタル・フィルタ１、デジタル・フィルタ２、・・・、デジタル・フィルタｎ）
情報認識処理（例えば、第Ａのシンボル体系の認識、・・・、第Ｚのシンボル体系の認識、ＯＣＲを使用する英数字の文字列認識１、・・・、ＯＣＲを使用する英数字の文字列認識ｎ、およびテキスト認識プロセス）
後処理（例えば、デジタル・データ・フィルタ１、デジタル・データ・フィルタ２、・・・）
物体機能／特性セット認識（例えば、ＯＮまたはＯＦＦ）

音声インジケータ出力特徴：音声インジケータ出力サブシステム
標準システム機能：
音の大きさ（例えば、高、低、中の音量）
音の高さ（例えば、周波１、周波２、周波３、・・・、音声１、・・・、音声Ｎ）

視覚インジケータ出力特徴：視覚インジケータ出力サブシステム
標準システム機能：
インジケータの明るさ（例えば、高、低、中の明るさ）
インジケータの色（例えば、赤色、緑色、黄色、青色、白色）

電力管理特徴：電力管理サブシステム
標準システム機能：
電力動作モード（例えば、ＯＦＦ、ＯＮ連続、ＯＮエネルギ節約）
エネルギ節約モード（例えば、節約モード第１、節約モード第２、・・・、節約モードＭ）

画像時間／空間スタンピング特徴：画像時間／空間スタンピング・サブシステム
標準システム機能：
ＧＰＳベースの時間／空間スタンピング（例えば、ＯＮ、ＯＦＦ）
ネットワーク・サーバ時間割当て（例えば、ＯＮ、ＯＦＦ）

ネットワーク（ＩＰ）アドレス記憶特徴：ＩＰアドレス記憶サブシステム
標準システム機能：
手動ＩＰアドレス記憶（例えば、ＯＮ、ＯＦＦ）
ＤＨＣＰを介した自動ＩＰアドレス記憶（例えば、ＯＮ、ＯＦＦ）

遠隔監視／サービス提供特徴：遠隔監視／サービス提供サブシステム
標準システム機能：
ＴＣＰ／ＩＰ接続（例えば、ＯＮ、ＯＦＦ）
ＳＮＭＰエージェント（例えば、ＡＣＴＩＶＥ（アクティブ）またはＤＥＡＣＴＩＶＥ（デアクティブ））

入出力特徴：入出力サブシステム
標準システム機能：
データ通信プロトコル（例えば、ＲＳ−２３２シリアル、ＵＳＢ、ブルートゥース（登録商標）など）
出力画像ファイル形式（例えば、ＪＰＧ／ＥＸＩＦ、ＴＩＦＦ、ＰＩＣＴ、ＰＤＦなど）
出力動画ファイル形式（例えば、ＭＰＥＧ、ＡＶＩなど）
データ出力形式（例えば、ＡＳＣＩＩ）
キーボード・インターフェース（例えば、ＡＳＣＩＩ）
グラフィック表示（ＬＣＤ）インターフェース（例えば、ＡＣＴＩＶＥまたはＤＥＡＣＴＩＶＥ）

システム制御および／または調整特徴：システム制御および／または調整サブシステム
標準システム機能：
システム動作モード（例えば、システム・モード１、システム・モード２、・・・、システム・モードＮ）

図１Ｄに示すように、図１Ａ〜１Ｃ３に表す本開示のデジタル画像キャプチャおよび処理のシステム１０００は、ともにインターフェースされるデジタル・カメラ基板および印刷回路（ＰＣ）基板を使用して実施することができる。代替例として、図１Ｅに示すように、本開示のデジタル画像キャプチャおよび処理のシステム１０００はまた、示されるように単一の複合型のデジタル・カメラ／ＰＣ基板を使用して実施することもできる。

図１Ｆに示すように、本開示のデジタル画像キャプチャおよび処理のシステムは、例えば、画像処理ベースのバー・コード・シンボル読取システム、ＯＣＲシステム、物体認識システム、携帯型データ端末（ＰＤＴ）、モバイル電話、コンピュータ・マウス型デバイス、パーソナル・コンピュータ、キーボード、民生用機器、自動車、ＡＴＭ、販売機、回収機、小売用ＰＯＳベースの取引システム、２Ｄまたは２Ｄデジタイザ、およびＣＡＴ走査システム、自動車識別システム、包装検査システム、ならびに個人識別システムなどのサードパーティ製品内に組み込むこと、およびサードパーティ製品内で実施することができるが、その製品はこれらに限定されるものではない。

通常、本開示のデジタル画像キャプチャおよび処理のシステムは、上述のような１組の標準的な特徴および機能と、カスタマイズされたエンドユーザ・アプリケーション要件を満たす１組のカスタム特徴および機能とを有するものであり、カスタム特徴および機能は、典型的には、手元の特定のアプリケーション向けのそのような標準のシステムの特徴および機能を変更および／または拡張することを目的とする。

図２Ａ〜図５を参照して詳細に後述する例示的な実施形態では、本開示のデジタル画像キャプチャおよび処理のシステムは（第３の製品内にシステムが組み込まれたりそのシステム内で実施されるか否かにかかわらず）、通常、下記のものを備える。

即ち、視野（ＦＯＶ）を、前記ＦＯＶおいて撮像すべき物体上に投影し、画像キャプチャ・モードにおける照射動作中に物体から反射されて撮像された光を検出するデジタル・カメラ・サブシステムであって、物体の１または複数のデジタル画像が前記デジタル・カメラ・サブシステムにより形成および検出されるデジタル・カメラ・サブシステムと、デジタル画像を処理し、生もしくは処理済みの出力データを生成するか、または画像内にグラフィックで表される情報を認識もしくは取得し、認識した情報を表す出力データを生成するデジタル画像処理サブシステムと、前記出力データを、外部のホスト・システムまたは他の情報受取または応答デバイスへ伝送する入出力サブシステムと、上記のサブシステムの動作を制御および／または調整するシステム制御システムと、上記のサブシステムの１または複数のもの、ならびにデジタル画像キャプチャおよび処理のシステムの特徴および機能の実装をサポートする演算プラットホームとを備える。

演算プラットホームは、（ｉ）デジタル画像キャプチャおよび処理のシステムの元の設計者により書かれた元の製品コードを記憶するメモリと、（ｉｉ）元の製品コードを特定
のシーケンスで呼び出して実行することにより１または複数のアプリケーションを動作させるマイクロプロセッサとを含み、デジタル画像キャプチャおよび処理のシステムの標準的挙動を特徴付ける１組の標準的な特徴および機能をサポートする。

図６〜７Ｆを参照してより詳細に説明するように、これらの元の製品コードは、１組のプレース・ホルダを有し、このプレース・ホルダ内へ、付加価値再販業者（ＶＡＲ）や、相手先商標製造業者（ＯＥＭ）や、デジタル画像キャプチャおよび処理のシステムのエンドユーザを含むサードパーティが、サードパーティ製品コードを挿入またはプラグインすることができる。

本開示の新規な原理によれば、１または複数のサードパーティ・コード（「プラグイン」）が１組のプレース・ホルダへ挿入またはプラグインされ、デジタル画像キャプチャおよび処理のシステムの標準的な特徴および機能を拡張させるように、およびその標準的な挙動をデジタル画像キャプチャおよび処理のシステム向けのカスタム挙動に変更するように、動作する。

本開示の殆どの実施形態では、デジタル画像キャプチャおよび処理のシステムは、光透過窓を有する筐体を更に備え、ＦＯＶは、光透過窓を通って、ＦＯＶで撮像すべき物体上へ投影される。また典型的に、これらの元の製品コードならびにサードパーティ製品コードは、演算プラットホームのメモリ構造でサポートされる１または複数のライブラリに維持される。通常、そのようなメモリは、それぞれ異なるアクセス速度および性能特性を有する様々な種類のメモリを有するメモリ・アーキテクチャを備える。

本開示の原理によれば、付加価値再販業者（ＶＡＲ）や相手先商標製造業者（ＯＥＭ）などのようなエンドユーザは、元のシステム設計者により設定された仕様に従ってそのようなサードパーティ・コード（即ち、プラグイン）を書くことができ、これらのカスタム・コードをプレース・ホルダにプラグインすることができ、それにより、デジタル画像キャプチャおよび処理のシステムの標準的な特徴および機能の永久的な変更を行うことなく、デジタル画像キャプチャおよび処理のシステム（またはシステムが組み込まれるサードパーティ製品又はシステムが実施されるサードパーティ製品）の特徴および機能を変更および拡張することができ、また、デジタル画像キャプチャおよび処理のシステムの標準的な挙動をデジタル画像キャプチャおよび処理のシステム向けのカスタム挙動に変更することができる。

本開示の幾つかの例示的な実施形態では、デジタル・カメラ・システムは、デジタル画像形成および検出サブシステムを備え、デジタル画像形成および検出サブシステムは、（ｉ）ＦＯＶを、光透過窓を通してＦＯＶで撮像すべき物体上へ投影する画像形成光学系と、（ｉｉ）画像感知アレイのセンサ・エレメントがイネーブルとされる画像キャプチャ・モードにおける照射動作中に物体から反射されて撮像された光を検出する画像感知アレイとを有し、画像感知アレイ上に形成された物体の１または複数のデジタル画像を検出するように構成され、デジタル・カメラ・システムは更に、画像キャプチャ・モード中に光透過窓を通るものでありＦＯＶ内にある照射フィールドを生成および投影する照射アレイを有する照射サブシステムと、画像形成および検出サブシステムにより検出されたこれらのデジタル画像を取り込んでバッファリングする画像取込みおよびバッファリング・サブシステムとを備える。

画像感知アレイは、エリア・タイプの画像感知アレイおよびリニア・タイプの画像感知アレイからなる群から選択されるデジタル画像感知構造により実現することができる。

システムの演算プラットホーム内で用いられるメモリは、デジタル画像キャプチャおよ
び処理のシステムの機能を構成するために使用されるシステム・パラメータを維持することが好ましい。例示的な実施形態では、メモリは、オペレーティング・システム（ＯＳ）層、システム・コア（ＳＣＯＲＥ）層、およびアプリケーション層を特徴とし、前記デジタル撮像ベースのコード・シンボル読取システム内のトリガ・イベントの生成に応答する、３層モジュール式ソフトウェア・アーキテクチャをサポートするメモリ・アーキテクチャを備える。ＯＳ層は、ＯＳカーネル・モジュール、ＯＳファイル・システム・モジュール、およびデバイス・ドライバ・モジュールからなる群から選択される１または複数のソフトウェア・モジュールを含む。ＳＣＯＲＥ層は、タスク・マネージャ・モジュール、イベント・ディスパッチャ・モジュール、入出力マネージャ・モジュール、ユーザ・コマンド・マネージャ・モジュール、タイマ・サブシステム・モジュール、入出力サブシステム・モジュール、およびメモリ制御サブシステム・モジュールからなる群から選択される１または複数のソフトウェア・モジュールを含む。アプリケーション層は、コード・シンボル復号化モジュール、機能プログラミング・モジュール、アプリケーション・イベント・マネージャ・モジュール、ユーザ・コマンド・テーブル・モジュール、およびコマンド・ハンドラ・モジュールからなる群から選択される１または複数のソフトウェア・モジュールを含む。

照射サブシステムから投影される照射のフィールドは、発光ダイオード（ＬＥＤ）のアレイから生成される狭帯域の照射とすることができる。また、デジタル画像処理サブシステムは典型的に、取り込まれたデジタル画像を処理して、デジタル画像内にグラフィックで表される１または複数のコード・シンボルを読み取るように適合され、読み取った１または複数のコード・シンボルを表すシンボル・キャラクタ・データの形で出力データを生成する。各コード・シンボルは、１Ｄバー・コード・シンボル、２Ｄバー・コード・シンボル、およびデータ・マトリックス・タイプのコード・シンボル構造からなる群から選択されるバー・コード・シンボルとすることができる。

本開示のこれらの態様および他の態様は、以下および特許請求の範囲で明らかになるであろう。従ってこの時点で、図１Ａ〜１Ｆに示す本開示のデジタル画像キャプチャおよび処理のシステムの様々な例示的な実施形態について、図２Ａ〜５を参照してここで詳細に説明することが適当である。図２Ａ〜５に示すこれらのそれぞれの例示的な実施形態では、本開示のデジタル画像キャプチャおよび処理のシステム１０００は、示されたシステムまたは製品の構造、特徴、および機能へ組み込まれるか又は構造、特徴、および機能で実施される。これらの例示的な実施形態について説明した後、本開示のプラグイン・プログラミング方法の技術上の態様について、図６〜７Ｅを参照して詳細に説明する。

［本開示の例示的な実施形態の手で支持できるデジタル撮像ベースのバー・コード読取デバイス］

図２Ａ〜２Ｌ２を参照して、本開示の第１の例示的な実施形態の手で支持できるデジタル撮像ベースのバー・コード・シンボル読取デバイス１を詳細に示す。デバイス１は、ハンドル部分２Ａとヘッド部分２Ｂとを有する手で支持できる筐体２を備え、ヘッド部分２Ｂは、高域通過（赤色波長を反射する）の光学フィルタ・エレメント４Ａを有する光透過窓３を備える。より詳細に後述するように、高域通過光学フィルタ・エレメント４Ａは、内部に取り付けられた低域通過光学フィルタ・エレメント４Ｂ内で協働し、低域通過光学フィルタ・エレメント４Ｂは高域通過光学フィルタ・エレメント４Ａと協働する。これらの高域通過フィルタ・エレメント４Ａおよび低域通過フィルタ・エレメント４Ｂは、狭帯域光学フィルタ・システム４を提供するように協働するものであり、狭帯域光学フィルタ・システム４は、筐体のヘッド部分に組み込まれ、狭帯域の照射（例えば、６３３ナノメートル）のみが撮像動作中に筐体を出入りすることを可能にする。

図２Ｉ、２Ｊ、および２Ｋに最もよく示されているように、例示的な実施形態の手で支持できる筐体２は、左側の筐体ハンドル半部２Ａ１および右側の筐体ハンドル半部２Ａ２と、ハンドル半部２Ａ１とハンドル半部２Ａ２との間に取り付けられる脚状構造２Ａ３と、筐体の半部内に提供される１対の隔置された開口２Ｄ１および２Ｄ２にスナップ嵌めされて枢動するトリガ・スイッチ構造２Ｃと、ハンドル半部２Ａ１および２Ａ２を合わせたときにそれらにより形成される凹部内に光透過窓３が形成および支持されるものであり、システムにより提供されるすべてのＬＥＤ照射アレイを支持する光透過窓パネル５と、電気光学構成エレメントを支持するものであり、ハンドル筐体半部内に直交して取り付けられるＰＣ基板７に動作可能に接続される光学ベンチ６と、筐体ハンドル半部２Ａ１および２Ａ２と接続され、筐体のヘッド部分を囲う上部筐体部分２Ｂ１と、手で支持できる筐体のヘッド部分の後端部内に取り付けられた光パイプ構造１０および発光ダイオード（ＬＥＤ）９のアレイ上へ取り付けられる光パイプ・レンズ・エレメント７と、上部筐体部分２Ｂ１ならびに左側ハンドル半部２Ａ１および右側ハンドル半部２Ａ２をともに保持し、光透過窓パネル５を間に挟み、光透過窓パネル５に対してあるレベルの衝撃保護を提供する前面バンパ構造２Ｅとを備える。

本開示の他の可能な実施形態では、手で支持できる筐体の形状は、異なる可能性および場合がある。更に他の適用分野では、筐体は、手で支持できるようにする必要すらなく、机もしくは台の上の表面で静止して支持されるように、または商業用もしくは産業用の適用分野で使用されるように、設計される場合がある。

［本開示の手で支持できるデジタル画像ベースのバー・コード読取デバイスのシステム設計モデルとしての概略ブロック機能図］

図２Ｌ１のシステム設計モデルに示すように、例示的な実施形態の手で支持できるデジタル撮像ベースのバー・コード・シンボル読取デバイス１は、ＩＲベースの物体存在および範囲検出サブシステム１２と、狭域の画像キャプチャ・モード、近視野広域の画像キャプチャ・モード、および遠視野広域の画像キャプチャ・モードを有する多モード・エリア・タイプの画像形成および検出（即ち、カメラ）サブシステム１３と、狭域の照射モード、近視野広域の照射モード、および遠視野広域の照射モードを有する多モードＬＥＤベースの照射サブシステム１４と、自動露光測定および照射制御サブシステム１５と、画像取込みおよびバッファリング・サブシステム１６と、図２Ｌ２に示し、詳細に述べる画像処理ベースのバー・コード・シンボル読取りの５つのモードを有する多モード画像処理バー・コード・シンボル読取サブシステム１７と、入出力サブシステム１８と、ユーザ由来の制御作動信号をデバイスへ送る手動作動可能なトリガ・スイッチ２Ｃと、システム・モード・コンフィギュレーション・パラメータ・テーブル７０と、示したように前述のサブシステムのそれぞれと統合されるシステム制御サブシステム１８とを備える。

ＩＲベースの物体存在および範囲検出サブシステム１２の主な機能は、多モード画像形成および検出サブシステム１３のＦＯＶ内でＩＲベースの物体検出フィールド２０を自動的に生成し、物体検出フィールド（２０Ａ、２０Ｂ）の所定の領域内で物体の存在を検出し、制御作動信号Ａ１を生成することである。制御作動信号Ａ１は、システム制御サブシステム１９へ供給され、システムの物体検出フィールド内で物体がいつどこで検出されたかを示す。

第１の例示的な実施形態では、多モード画像形成および検出（即ち、カメラ）サブシステム１３は、撮像すべき物体上で視野（ＦＯＶ）２３を生成する画像形成（カメラ）光学系２１と、照射および画像取得／キャプチャ動作中に物体から反射されて撮像された光を検出するＣＭＯＳエリア画像感知アレイ２２とを有する。

第１の例示的な実施形態では、多モードＬＥＤベースの照射サブシステム１４の主な機能は、狭域照射フィールド２４、近視野広域照射フィールド２５、および遠視野広域照射フィールド２５を生成することである。これらのフィールドはそれぞれ、狭い光学帯域幅を有し、それぞれ、狭域および広域の撮像モード中に多モード画像形成および検出サブシステム１３のＦＯＶ内に制限される。この構成は、多モード照射サブシステム１４から送られて、照射された物体から反射される光のみが最終的に狭帯域の透過型の光学フィルタ・サブシステム４を透過することが確実になるように設計されるものであり、このサブシステム４は、（１）パネル５の直前の光透過開口３に取り付けられた高域通過（即ち、赤色波長を反射する）フィルタ・エレメント４Ａ、および（２）図３Ｃに示すように画像感知アレイ２２の前またはパネル５の後の任意の場所に取り付けられる低域通過フィルタ・エレメント４Ｂにより実現される。図５Ａ４は、狭帯域透過スペクトル・フィルタ・サブシステム４の結果として得られる合成伝送特性を示し、多モード照射サブシステム１４で用いられるＬＥＤ照射アレイからの発光のスペクトル特性に対してプロットしたものである。

狭帯域組込型光学フィルタ・サブシステム４の主な機能は、ＣＭＯＳ画像感知アレイ２２のみが、多モード照射サブシステム１４に関連するＬＥＤドライバ回路３０により駆動される３セットのＬＥＤベースの照射アレイ２７、２８、および２９により透過される狭帯域可視照射を受け取るようにすることであり、集光光学系により収集される周囲光の他の全ての成分は画像感知アレイ２２で実質上拒否され、それにより改善されたＳＮＲを提供し、従ってシステムの性能を改善する。

自動露光測定および照射制御サブシステム１５の主な機能は２つあり、それらは、（１）画像感知アレイ２２辺りでシステムの光学系により収集される光子エネルギー（即ち、光）のパワー密度［ジュール／ｃｍ］をリアルタイムで測定し、良好な画像形成および検出に必要な露出の量を示す自動露出制御信号を生成すること、そして（２）システム制御サブシステム１９により提供される照射アレイ選択制御信号と組み合わせて、多モード照射サブシステムで選択されたＬＥＤアレイ２７、２８、および／または２９の出力パワーを自動的に駆動および制御して、システムのＦＯＶ内の物体がＬＥＤベースの照射に対して最適に露出され、画像感知アレイ２２で最適の画像が形成および検出されるようにすることである。

画像取込みおよびバッファリング・サブシステム１６の主な機能は、（１）システムの画像形成光学系２１により２Ｄ画像感知アレイ２２上へ集束された２Ｄ画像全体を検出すること、（２）取り込まれた画像フレームの選択された対象領域に対して、または検出された画像全体に対して、デジタル画素データ３１のフレームを生成すること、次いで（３）取り込まれた画像データの各フレームをバッファリングすることである。特に、例示的な実施形態では、ＷｅｌｃｈＡｌｌｙｎに譲渡され参照により本明細書に組み込まれる米国特許第５，９３２，８６２号および第５，９４２，７４１号で対処されている画像フレームの上書きならびに画像キャプチャおよび復号化プロセスの同期に関連する問題を解消するために、それぞれの画像キャプチャおよび処理サイクル中、または処理サイクルの特定の段階中に、単一の２Ｄ画像フレーム（３１）が取り込まれる。

多モードの撮像ベースのバー・コード・シンボル読取サブシステム１７の主な機能は、システム動作の狭域照射と広域照射の両方のモード中に、画像取込みおよびバッファリング・サブシステム１６により取り込まれてバッファリングされた画像を処理することである。そのような画像処理動作は、図１４〜２５に示し詳細に述べる画像ベースのバー・コード復号化方法を含む。

入出力サブシステム１８の主な機能は、外部のホスト・システムおよびデバイスとの標
準および／または専有の通信インターフェースをサポートし、そのようなインターフェースを用いてそのような外部のホスト・システムまたはデバイスへ処理された画像データなどを出力することである。そのようなインターフェース、およびそのようなインターフェースを実施する技術の例は、全体として参照により本明細書に組み込まれる米国特許第６，６１９，５４９号で得られる。

システム制御サブシステム１９の主な機能は、示されるように、組み込まれた各サブシステム・コンポーネントに、ある所定の程度の制御または管理の信号サービスを提供することである。このサブシステムは、プログラムされたマイクロプロセッサにより実施できるが、例示的な実施形態では、図１１Ａ〜１３Ｌに表し詳細に述べるように、図２Ｍに示す演算プラットホームでサポートされる３層ソフトウェア・アーキテクチャにより実施される。

手で支持できる筐体に組み込まれた手動作動可能トリガ・スイッチ２Ｃの主な機能は、ユーザがトリガ・スイッチ２Ｃを手動で押したときに制御作動信号を生成できるようにすること、そしてこの制御作動信号を、本明細書に詳細に説明する複合のシステムおよびサブシステムの制御動作を実施する際に使用するために、システム制御サブシステム１９へ提供することである。

システム・モード・コンフィギュレーション・パラメータ・テーブル７０の主な機能は、例示的な実施形態のシステムによりサポートされ、複合動作中に必要に応じてシステム制御サブシステム１９により読み取って使用できる、それぞれのプログラム可能なシステム動作モードに対する１組のコンフィギュレーション・パラメータを記憶する（不揮発性／永続的メモリ内に）ことである。

各サブシステムの詳細な構造および機能について詳細に説明した。

［本開示の手で支持できるデジタル撮像ベースのバー・コード読取デバイスのシステム実装モデルとしての概略図］

図２Ｂは、図２Ａ〜２Ｌに示す手で支持できるデジタル撮像ベースのバー・コード・シンボル読取デバイス１に対するシステム実装形態の概略図を示す。このシステム実装形態に示すように、バー・コード・シンボル読取デバイスは複数のハードウェア構成要素を使用して実現され、ハードウェア構成要素は下記のものを含む。ＬＥＤベースの多モード照射サブシステム１４および自動露光測定および照射制御サブシステム１５により実行される電子機能を実現するコンポーネントを保持する照射基板３３。２５Ｍｈｚのマスタクロック、７フレーム／秒、１２８０×１０２４の分解能で動作し、ランダムにアクセス可能な関心領域（ＲＯＩ）ウィンドゥ機能を有する、高分解能（１２８０×１０２４の７ビットの６ミクロン画素寸法）のＣＭＯＳ画像感知アレイ２２を保持し、多モード画像形成および検出サブシステム１３により実行される電子機能を実現するＣＭＯＳカメラ基板３４。ＣＰＵ基板３５（即ち、演算プラットホーム）であって、（ｉ）２００ｍＨｚの１．０コア電圧で動作し、１６ビットで１００Ｍｈｚの外部バス速度を有するＩｎｔｅｌ（登録商標）Ｓａｂｉｎａｌの３２ビットのマイクロプロセッサＰＸＡ２１０３６、（ｉｉ）拡張可能な（例えば、７＋メガバイト）Ｉｎｔｅｌ（登録商標）Ｊ３非同期１６ビット・フラッシュ・メモリ３７、（ｉｉｉ）１６メガバイトの１００ＭＨｚのＳＤＲＡＭ３８、（ｉｖ）カメラのタイミングの制御および画像取得プロセスの駆動を行うように構成された、５０Ｍｈｚのクロック周波数および６０ＭＢ／秒のデータ速度で動作するＸｉｌｉｎｘＳｐａｒｔａｎＩＩＦＰＧＡＦＩＦＯ３９、（ｖ）システムの他のサブシステムを実現するためのマルチメディア・カード・ソケット４０、（ｖｉ）Ｉ２Ｃバスにより調整可能なＭＣＵに対する電力管理モジュール４１、ならびに（ｖｉｉ）１対のＵＡＲ
Ｔ４２Ａおよび４２Ｂの対（ＩＲＤＡポート用とＪＴＡＧポート用）を含むＣＰＵ基板３５。入出力サブシステム１８により実行される機能を実現するインターフェース基板４３。鉛筆形状のＩＲベースの物体感知信号を送受信するための１対のＩＲＬＥＤおよびフォトダイオード１２Ａを含むサブシステム１２を実現する、ＩＲベースの物体存在および範囲検出回路４４。

例示的な実施形態では、バー・コード・リーダにより支持される画像形成光学系２１は、バー・コード・リーダの縁部から約７０ｍｍという、標的までの公称焦点距離で、１０３ｍｍの視野を提供する。視野（ＦＯＶ）の最小寸法は、標的まで約１０ｍｍという公称焦点距離で、６２ｍｍである。光学系のパラメータの予備試験を図４Ｂに示す（図４Ｂ上の距離は、バー・コード・シンボル・リーダ内で縁部から約８０ｍｍのところに位置する画像感知アレイ２２の位置から得られる）。図４Ｃに示すように、画像形成光学系の被写界深度は、１つの狭いモジュール当たり５ミルの分解能を有するバー・コードに対する約６９ｍｍから、１つの狭いモジュール当たり１３ミルの分解能を有するバー・コードに対する１８１ｍｍまで変動する。

多モード照射サブシステム１４は、撮像窓から短い距離と長い距離との両方に位置するバー・コードの高コントラストの画像を生成するのに十分な照射で、バー・コード・シンボル・リーダの光学視野（ＦＯＶ）２３をカバーするように設計される。照射サブシステムはまた、２つの目的を有する狭域（薄い高さ）標的ビーム２４を提供するものであり、２つの目的は、（ａ）リーダの光学視野がどこにあるかをユーザに示すこと、および（ｂ）バー・コードが適正に位置合わせされている場合に、画像のほんの数行の迅速な走査を可能にし、超高速のバー・コード復号化を試みることとである。バー・コードが、復号するための直線的に照射される画像となるように位置合わせされていない場合、視野全体が広域照射フィールド２５または２６で照射され、視野全体の画像が画像キャプチャおよびバッファリング・サブシステム１６により取得され、多モード・バー・コード・シンボル読取サブシステム１７により処理され、その視野内に存在するバー・コード・シンボルの読み取りを向きにかかわらず確かなものとする。

バー・コード・シンボル・リーダで用いられるインターフェース基板４３は、バー・コード・シンボル・リーダが外界と通信するためのハードウェア通信インターフェースを提供する。システムで実施されるインターフェースは、典型的に、ＲＳ２３２、キーボード・ウェッジ、および／もしくはＵＳＢ、または上記の何らかの組合せ、ならびに手元の特定のアプリケーションにより必要とされる又は要求される他のものを含む。

［狭域および広域の狭帯域の照射によりそれぞれサポートされる狭域（リニア）および広域の撮像モード中のエリア・タイプ画像形成および検出（即ち、カメラ）サブシステムの仕様］

図３Ｂ〜３Ｅに示すように、多モードの画像形成および検出（ＩＦＤ）サブシステム１３は、狭域画像キャプチャ・モード（即ち、画像感知アレイの中心の周りの画素の中心の数列のみがイネーブルされる）と、広域画像キャプチャ動作モード（即ち、画像感知アレイ内のすべての画素がイネーブルされる）とを有する。画像形成および検出サブシステム１３のＣＭＯＳ画像感知アレイ２２は、画像感知アレイに、照射され撮像される物体上の視野（ＦＯＶ）２３を提供する画像形成光学系２１を有する。示されるように、このＦＯＶは、バー・コード・リーダに組み込まれた多モード照射サブシステム１４により照射される。

多モード照射サブシステム１４は、光透過窓パネル５に取り付けられて光透過窓４Ａのあたりに配される３つの異なるＬＥＤベースの照射アレイ２７、２８、および２９を含む
。各照射アレイは、異なる動作モード中にバー・コード・リーダのＦＯＶの異なる部分を照射するように設計される。多モード照射サブシステム１４の狭域（リニア）照射モード中、２３により示すＦＯＶの中央の狭域広域部分が、図３Ａに示す狭域照射アレイ２７により照射される。ＩＲ物体存在および範囲検出サブシステム１２がＦＯＶの近視野部分で物体を検出することに応答して作動される多モード照射サブシステム１４の近視野広域照射モード中、ＦＯＶの近視野広域部分は、図３Ａに示す近視野広域照射アレイ２８により照射される。ＩＲ物体存在および範囲検出サブシステム１２がＦＯＶの遠視野部分で物体を検出することに応答して作動される多モード照射サブシステム１４の遠視野広域照射モード中、ＦＯＶの遠視野広域部分は、図３Ａに示す遠視野広域照射アレイ２９により照射される。図３Ａでは、画像形成および検出サブシステム１３のＦＯＶのこれらの狭帯域の照射フィールドならびに遠視野および近視野部分の間の空間関係を示す。

図３Ｂでは、多モードＬＥＤベースの照射サブシステム１４が、図３Ｃに示す狭帯域透過タイプの光学フィルタ・サブシステム４を通して可視の狭帯域照射を送るところが示され、サブシステム１４は、手で支持できるデジタル撮像ベースのバー・コード・シンボル読取デバイス内に組み込まれている。多モード照射サブシステム１４からの狭帯域の照射は、画像形成および検出サブシステム１３の画像形成光学系のＦＯＶで物体を照射し、そこから反射されて散乱する光線は、高域通過の光学フィルタ４Ａおよび低域通過の光学フィルタ４Ｂを通って透過され、最終的に画像感知アレイ２２上へ集束され、集束されて検出される画像を画像感知アレイ２２上に形成するが、周囲光の他のすべての成分は、画像感知アレイ２２における画像検出に到達する前に実質上排除される。特に、例示的な実施形態では、赤色波長を反射する高域通過の光学フィルタ・エレメント４Ａは、画像形成光学系２１の前でデバイスの撮像窓に配置され、低域通過の光学フィルタ・エレメント４Ｂは、画像形成光学系２１の集束レンズ・エレメント間で画像感知アレイ２２の前に配置される。これは、バー・コード・リーダ内に組み込まれる狭帯域の光学フィルタ・サブシステム４を形成し、ＦＯＶ内の物体が、サブシステム１４から生成される狭帯域の照射内のスペクトル成分のみを使用して画像感知アレイ２２で確実に撮像されることを可能とし、更に、この狭い範囲（例えば、１５ｎｍ）の外側の他のすべての周囲光の成分を実質的に排除する。

［本開示の手で支持できる画像ベースのバー・コード読取システムで用いられる多モードのＬＥＤベースの照射サブシステムの仕様］

例示的な実施形態では、ＬＥＤベースの多モードの照射サブシステム１４は、狭域照射アレイ２７、近視野広域照射アレイ２８、および遠視野広域照射アレイ２９を備える。サブシステム１４の３つの照射アレイにより生成される３つの狭帯域の照射フィールドを、図４Ａ１に概略的に示す。狭域照射アレイ２７は、独立して動作可能な２つのアレイ、即ち、近視野狭域照射アレイおよび遠視野狭域照射アレイとして実現することができ、これらは、広域撮像の動作モード中に自動のＩＲベースの物体存在および範囲検出サブシステム１２の近視野および遠視野で標的物体が検出されると作動する。しかしながら、例示の目的で、本開示の第１の例示的な実施形態は、図４Ａ１に示すように、システムの動作範囲の実質上全体にわたって照射するように設計された単一フィールド狭域（リニア）照射アレイのみを用いる。

狭域（リニア）照射アレイ２７は、それぞれ、円筒形のレンズ２７Ｂ１および２７Ｂ２を備え、光透過窓パネル５の左側部分および右側部分に取り付けられる、２対のＬＥＤ光源２７Ａ１および２７Ａ２を含む。画像形成および検出サブシステム１３の狭域画像キャプチャ・モード中、狭域（リニア）照射アレイ２７は、システムのＦＯＶ内に光学帯域幅が狭い狭域照射フィールド２４を生成する。例示的な実施形態では、狭域照射フィールド２４は、遠視野で１０ｍｍ未満の高さを有し、実質上、直線または幾分平面の照射フィー
ルドの外観をもたらす。

例示的な実施形態では、近視野広域照射アレイ２８は、図４Ｂに示すように光透過窓パネル５の上部部分および下部部分にレンズを取り付けられていない２セットの（頂部が平らな）ＬＥＤ光源２８Ａ１〜２８Ａ６および２８Ａ７〜２８Ａ１３を含む。画像形成および検出サブシステム１３の近視野広域画像キャプチャ・モード中、近視野広域照射アレイ２８は、システムのＦＯＶ内で光学帯域幅が狭い近視野広域照射フィールド２５を生成する。

例示的な実施形態では、それぞれ、遠視野広域照射アレイ２９は、球形（即ち、平凸）レンズ２９Ｂ１〜２９Ｂ６および２９Ｂ７〜２９Ｂ１３を備え、光透過窓パネル５の上部部分および下部部分に取り付けられる２セットのＬＥＤ光源２９Ａ１〜２９Ａ６および２９Ａ７〜２９Ａ１３を含む。画像形成および検出サブシステム１３の遠視野広域画像キャプチャ・モード中、遠視野広域照射アレイ２９は、システムのＦＯＶ内で光学帯域幅が狭い遠視野広域照射ビームを生成する。

［本開示の手で支持できるデジタル画像ベースのバー・コード読取デバイスの３層ソフトウェア・アーキテクチャの仕様］

図４に示すように、本開示の手で支持できるデジタル撮像ベースのバー・コード・シンボル読取デバイス１は、３層のソフトウェア・アーキテクチャを備え、（１）ソフトウェア・アーキテクチャのアプリケーション層内に常駐するメイン・タスク・モジュール、コードゲート・タスク（CodeGate Task）・モジュール、メトロセット・タスク（Metrosrt Task）・モジュール、アプリケーション・イベント・マネージャ・モジュール、ユーザ・コマンド・テーブル・モジュール、コマンド・ハンドラ・モジュール、プラグイン・コントローラ（マネージャ）、ならびにプラグイン・ライブラリおよびコンフィギュレーション・ファイルと、（２）ソフトウェア・アーキテクチャのシステム・コア（ＳＣＯＲＥ）層内に常駐するタスク・マネージャ・モジュール、イベント・ディスパッチャ・モジュール、入出力マネージャ・モジュール、ユーザ・コマンド・マネージャ・モジュール、タイマ・サブシステム・モジュール、入出力サブシステム・モジュール、およびメモリ制御サブシステム・モジュールと、（３）ソフトウェア・アーキテクチャのＬｉｎｕｘオペレーティング・システム（ＯＳ）層内に常駐するＬｉｎｕｘ（登録商標）カーネル・モジュール、Ｌｉｎｕｘ（登録商標）ファイル・システム・モジュール、およびデバイス・ドライバ・モジュールとを備える。

撮像ベースのバー・コード・シンボル・リーダのオペレーティング・システム層は、Ｌｉｎｕｘ（登録商標）オペレーティング・システムに基づくが、他のオペレーティング・システムを使用できること（例えば、Ｍｉｃｒｏｓｏｆｔ（登録商標）Ｗｉｎｄｏｗｓ（登録商標）、ＭａｘＯＸＳ、Ｕｎｉｘ（登録商標）など）、また、設計は、メイン・アプリケーション・ソフトウェア層とオペレーティング・システム層との間で独立性を提供し、従って、潜在的にアプリケーション・ソフトウェア層を他のプラットホームへ輸送できるようにすることが好ましいことが理解される。更に、本開示のシステム設計原理は、共通のソフトウェア・コンポーネントの広範な使用により将来の他の製品に対するシステムの拡張性を提供し、それにより、そのような製品の設計を容易にし、開発時間を低減させ、かつロバスト性を保障するはずである。

例示的な実施形態では、上記の特徴は、ＳＣＯＲＥと呼ばれるシステム・コア・ソフトウェア層の上で動作する、イベント駆動式のマルチタスクで潜在的にマルチユーザのアプリケーション層を実施することを通じて実現される。ＳＣＯＲＥ層は、製品アプリケーション・ソフトウェアと静的にリンクされ、従って、システムのアプリケーション・レベル
または層で動作する。ＳＣＯＲＥ層は、アプリケーションへ１組のサービスを提供し、このサービスは、アプリケーションが基礎となるオペレーティング・システムの詳細を知ることを必要としないようにするものであるが、すべてのオペレーティング・システムＡＰＩは、もちろん、アプリケーションに対して使用可能である。ＳＣＯＲＥソフトウェア層は、製品アプリケーションが動作するために、リアルタイムのイベント駆動式のＯＳ独立型の枠組みを提供する。イベント駆動式アーキテクチャは、イベントを検出する手段を作り（必ずしも必要ではないが、通常は、ハードウェアの割込みが発生したときに作る）、そのイベントをアプリケーションに通知してリアルタイムで処理するようにすることにより、達成される。イベントの検出および通知は、ＳＣＯＲＥソフトウェア層により提供される。ＳＣＯＲＥ層はまた、同時に動作している可能性のあるソフトウェア・タスクの開始および取消しを行う手段、従って、本開示のソフトウェア・システムのマルチタスクの性質を、アプリケーション製品に提供する。

［本開示の撮像ベースのバー・コード・リーダ内で用いられるシステム・ソフトウェア・アーキテクチャのＳＣＯＲＥ層内のソフトウェア・モジュールの仕様］

ＳＣＯＲＥ層は、アプリケーション層に複数のサービスを提供する。

タスク・マネージャは、製品アプリケーション動作中の任意の時点で特有のアプリケーション・タスク（スレッド）の実行および取消しを行う手段を提供する。

イベント・ディスパッチャは、すべての種類の内部および外部の同期および非同期イベントを信号発信および送達する手段を提供する。

アプリケーションに対して同期か非同期かにかかわらず、イベントが発生したとき、イベント・ディスパッチャは、これらのイベントをアプリケーション・イベント・マネージャへディスパッチし（送り）、アプリケーション・イベント・マネージャは、現在の状態に基づいてアプリケーションにより必要とされるようにイベントに作用する。例えば、特定のイベントおよびアプリケーションの現在の状態に基づいて、アプリケーション・イベント・マネージャは、新しいタスクを開始するか、それとも現在動作しているタスクを停止させるか、あるいはそれ以外のことを行うか、または何も行わずにイベントを完全に無視するかを決めることができる。

入出力マネージャは、入出力デバイスの行動を監視し、そのような行動が検出されたときに適当なイベントをアプリケーションに信号発信する手段を提供する。

入出力マネージャ・ソフトウェア・モジュールは、バックグラウンドで動作し、外部のデバイスおよびユーザ接続の行動を監視し、そのような行動が検出されると、適当なイベントをアプリケーション層へ信号で伝える。入出力マネージャは、アプリケーションと並列に動作し、シリアル・ポート、ユーザ・トリガ・スイッチ２Ｃ、バー・コード・リーダ、ネットワーク接続などのハードウェア・デバイスから非同期で来る入出力信号に反応する、優先度の高いスレッドである。これらの信号およびアプリケーションからの任意の入出力要求（またはその欠如）に基づいて、入出力マネージャは適当なシステム・イベントを生成し、これらのシステム・イベントは、可能な限り迅速に、イベント・ディスパッチャを通ってアプリケーション・イベント・マネージャへ送達される。

ユーザ・コマンド・マネージャは、ユーザ・コマンドを管理する手段を提供し、アプリケーションにより提供されるユーザ・コマンド・テーブルを使用し、ユーザにより入力されるデータに基づいて適当なユーザ・コマンド・ハンドラを実行する。

入出力サブシステム・ソフトウェア・モジュールは、入出力接続を生成および削除するため、および外部のシステムおよびデバイスと通信するための手段を提供する。

タイマ・サブシステムは、すべての種類の論理タイマを生成、削除、および使用する手段を提供する。

メモリ制御サブシステムは、標準の動的メモリ管理機能と完全にコンパチブルのデバイスおよび収集されたデータをバッファリングする手段を、多レベル動的メモリを管理するインターフェースに提供する。メモリ制御サブシステムは、動的メモリのスレッドレベル管理のための手段を提供する。メモリ制御サブシステムのインターフェースは、標準Ｃメモリ管理機能と完全にコンパチブルである。このシステム・ソフトウェア・アーキテクチャは、複数のユーザに対してもデバイスの接続性を提供するように設計され、複数のユーザは、デバイスを用いて動作するための異なるレベルの権限を有し得る。

ユーザ・コマンド・マネージャは、ユーザ・コマンドを入力すること、およびそのコマンドの対処の責務を負うアプリケーション・モジュールを実行することのための標準的な方法を提供する。ユーザ・コマンド・テーブルに記述された各ユーザ・コマンドは、ユーザ入力ごとにユーザ・コマンド・マネージャにより開始できるタスクであるが、開始されるのは、特定のユーザの権限がコマンドのセキュリティ・レベルに一致する場合のみである。

イベント・ディスパッチャ・ソフトウェア・モジュールは、新しいタスクを開始すること、現在動作しているタスクを停止すること、または何か行うこと、もしくは何も行わずにイベントを単に無視することを含むイベントを、アプリケーション・イベント・マネージャへ信号発信および送達する手段を提供する。

［本開示の撮像ベースのバー・コード・リーダで用いられるシステム・ソフトウェア・アーキテクチャのアプリケーション層内のソフトウェア・モジュールの仕様］

本開示のシステム内で用いられる画像処理ソフトウェアは、画素データを含む取り込まれた画像のフレーム内でバー・コードの位置を特定して認識するバー・コード読取機能を実行する。画像処理ソフトウェアのモジュール型設計は、バー・コード・シンボルの読み取りに関係するか否かにかかわらず、他の潜在的なアプリケーションに将来使用できる豊富な１組の画像処理機能、例えば、光学文字認識（ＯＣＲ）および検証（ＯＣＶ）、様々な表面上の直接にマークされたシンボルの読み取りおよび検証、顔認識および他の生体識別などを提供する。

無限ループ内のコードゲート（ＣｏｄｅＧａｔｅ）・タスクは、以下のタスクを実行する。このタスクは、視野（ＦＯＶ）の中央にある「薄い」狭い水平領域を照射して、その領域のデジタル画像を取得する。次いで、より詳細に述べる本開示の画像処理バー・コード・シンボル読取サブシステム１７によりサポートされる画像処理ソフトウェア設備を使用して、画像データの取り込まれたフレーム内に表されるバー・コード・シンボルの読み取りを試みる。バー・コード・シンボルの読み取りに成功した場合、サブシステム１７は、その復号されたデータを特別の復号データ・バッファに保存する。成功しなかった場合、復号データ・バッファを消去する。次いで、ループを継続する。コードゲート・タスク・ルーチンは決して自然に終了（退出）しない。このルーチンは、他のイベントに反応するときに、システム内の他のモジュールにより取り消すことができる。例えば、ユーザがトリガ・スイッチ２Ｃを引いたとき、ＴＲＩＧＧＥＲ＿ＯＮというイベントが、アプリケーションへ通知される。このイベントの処理を担うアプリケーション・ソフトウェアは、コードゲート・タスクが動作しているかどうかを検査し、動作している場合、このコード
ゲート・タスクを取り消し、次いでメイン・タスクを開始する。コードゲート・タスクはまた、ユーザがバー・コード・リーダを物体から離したとき、またはユーザがバー・コード・リーダから物体を離したときに通知されるＯＢＪＥＣＴ＿ＤＥＴＥＣＴ＿ＯＦＦイベントで、取り消されることができる。コードゲート・タスク・ルーチンは、「半自動でトリガされる」システム・モードのプログラムされた動作が本開示の照射および撮像プラットホームでインプリメント（実施）されるときにイネーブルされる（メイン・タスクによる）。

狭域照射タスクは、「手動トリガ」システム・モードのプログラムされた動作が本開示の照射および撮像プラットホームでインプリメントされるときにイネーブルされる（メイン・タスクによる）簡単なルーチンである。しかしながら、このルーチンはコードゲート・タスクと同時にはイネーブルにされない。図１３Ｄのイベントの流れ図に示すように、コードゲート・タスクまたは狭域照射タスクが、メイン・タスク・ルーチンでイネーブルにされて本明細書に記載する多様な種類のシステム動作を実現する。

撮像ベースのバー・コード・シンボル・リーダがコンフィギュレーションされるシステム・モードに応じて、メイン・タスクは典型的には異なった形で実行される。例えば、撮像ベースのバー・コード・シンボル・リーダが、半自動トリガの複数試行の１Ｄ／２Ｄ単一読取りモードにコンフィギュレーション（構成）されるとき、メイン・タスクは最初に、復号データ・バッファがコードゲート・タスクにより復号されたデータを含むか否かを検査する。含む場合、メイン・タスクは、データ出力手順を実行することによりそのデータをユーザへ直ちに送り出し、退出する。含まない場合、ループ内で、メイン・タスクは、視野の領域全体を照射して、その領域の全フレーム画像を取得する。取り込まれた画像のバー・コード・シンボルの読み取りを試みる。バー・コード・シンボルの読み取りに成功した場合、メイン・タスクは、データ出力手順を実行することによりそのデータをユーザへ直ちに送り出し、退出する。成功しなかった場合、ループを継続する。特に、読み取りに成功すると、データ出力手順を実行する前に、メイン・タスクは、「リーダ・プログラミング」コマンドまたはコマンドのシーケンスに関して、復号されたデータを分析する。必要な場合、ＭｅｔｒｏＳｅｌｅｃｔ（メトロセレクト）機能を実行する。メイン・タスクは、他のイベントに反応したとき、システム内の他のモジュールにより取り消すことができる。例えば、本開示のバー・コード・リーダは、ＭｅｔｒｏＳｅｌｅｃ（登録商標）およびＭｅｔｒｏｓｅｔ（登録商標）などのような標準のＭｅｔｒｏｌｏｇｉｃ（メトロロジック）のコンフィギュレーション方法を使用して再構成することができる。ＭｅｔｒｏＳｅｌｅｃｔ機能は、メイン・タスク中に実行される。

Ｍｅｔｒｏｓｅｔ機能は、特別なＭｅｔｒｏｓｅｔ（メトロセット）タスクにより実行される。ＦｏｃｕｓＲＳ２３２ソフトウェア・ドライバは、その通信ラインで特別なＮＵＬＬ信号を検出すると、アプリケーションへＭＥＴＲＯＳＥＴ＿ＯＮ（メトロセット・オン）イベントを通知する。このイベントの処理を担うアプリケーション・ソフトウェアは、Ｍｅｔｒｏｓｅｔタスクを開始する。Ｍｅｔｒｏｓｅｔタスクが完了すると、スキャナは通常動作へ戻る。

プラグイン・コントローラ（即ち、マネージャ）の機能は、コンフィギュレーション・ファイルを読み取り、プラグインおよびコンフィギュレーション・ファイル・ライブラリ内でプラグイン・ライブラリを見つけて、プラグインをオペレーティング・システムのメモリへインストールすることであり、オペレーティング・システムは、将来のアクセスのために、プラグインがインストールされた場所を示すアドレスをプラグイン・マネージャへ戻す。より詳細に後述するように、プラグイン開発プラットホームは、画像処理ベースのバー・コード・シンボル読取システムの特徴および機能を強化、拡張、および／または変更するプラグインの開発をサポートするものであり、開発された後、開発されたプラグ
インをオペレーティング・システム層のファイル・システムにアップロードし、そのプラグインのアドレスをアプリケーション層内のプラグインおよびコンフィギュレーション・ファイル・ライブラリに記憶する。

他のシステム動作モードは、システムによりサポートされる適当なソフトウェア・システムの変更を行うことにより、本開示の照射および撮像プラットホーム上で容易に実施することができる。

［本開示の撮像ベースのバー・コード・リーダで用いられるシステム・ソフトウェア・アーキテクチャのアプリケーション層内のオペレーティング・システム層ソフトウェア・モジュール］

トリガ・ドライバを含むデバイス・ドライバ・ソフトウェア・モジュールは、撮像ベースのデバイスで用いられるハードウェア・ベースの手動作動式トリガ・スイッチ２Ｃとのソフトウェア接続を確立する手段と、撮像ベースのデバイス上で画像取得機能を実施（インプリメント）する画像取得ドライバと、撮像ベースのデバイス上で物体検出機能を実施するＩＲドライバとを提供する。

デバイス駆動ソフトウェア・モジュールは、本開示の撮像ベースのバー・コード・シンボル・リーダで用いられるハードウェアベースの手動作動式トリガ・スイッチ２Ｃとのソフトウェア接続を確立するトリガ・ドライバと、撮像ベースのバー・コード・シンボル・リーダ上で画像取得機能を実施する画像取得ドライバと、撮像ベースのバー・コード・シンボル・リーダ上で物体検出機能を実施するＩＲドライバとを含む。

［本開示の原理に従ってデジタル画像キャプチャおよび処理のシステム内のシステム特徴および機能を変更および／または拡張する方法および装置］

図６〜７Ｆを次に参照して、本開示のデジタル画像キャプチャおよび処理のシステム内の標準システムの特徴および機能を拡張する方法および装置について説明する。本開示の新規なプラグイン・プログラミング方法論に関して、図６〜８に記載の本明細書に説明および開示するデジタル画像キャプチャおよび処理のシステムの何れのものをも参照できることが理解されるが、限定ではなく例示の目的で、図２Ａ〜５に示すデジタル撮像ベースのバー・コード読取システムも参照されたい。

図６のブロックＡに示すように、第１のステップは、撮像ベースのバー・コード・シンボル読取システム（多層ソフトウェア・アーキテクチャを有する）の「システム設計者」が、システムの何れの「特徴」（アプリケーション層で呼び出されるタスクによりインプリメントされる）および任意の所与の特徴の何れの機能が、システムのハードウェア・プラットホームや外部環境との通信インターフェースやユーザ・インターフェースに関する詳細な知識をもたないエンドユーザおよび／またはサードパーティ（元の設計者および製造業者以外、例えば、ＶＡＲ、エンドユーザ、顧客など）により変更可能および／または拡張可能であるかを決定することを含む。システム設計者によるこのステップは、他者によるシステム変更に関する制約を確立するが、エンドユーザ・アプリケーションのカスタム要求を満たすためにシステムをどのように変更できるかに関する自由度を提供する。

そのような判断に基づいて、図６のブロックＢに示すように、システム設計者は、本開示の画像処理ベースのバー・コード読取システムを設計および作成するものであり、システム設計者以外の者（例えば、エンドユーザおよびサードパーティ）は、ブロックＡでシステム設計者（即ち、元の製品／システムの設計者）により指定される元の製品／システムの特徴および機能を変更および／または拡張することを許される。

図６のブロックＣに示すように、次いでシステム設計者以外の者が、１組の特定のエンドユーザ・アプリケーション要求を満たすために、何れの変更可能および／または拡張可能なシステムの特徴および機能を変更および／または拡張したいと望むかを決定する。

図６のブロックＤに示すように、それぞれの変更可能な特徴／機能をシステム内で変更するために、システム設計者以外の者が、「プラグイン・モジュール」（サードパーティ・コードまたは「ソフトウェア・オブジェクト」）を開発し、設計されたカスタム・システム特徴をインプリメントし、その後に、多層システムのアプリケーション層の適したライブラリ（１または複数）内にプラグイン・モジュール（即ち、サードパーティ・コード）をインストールする。

図６のブロックＥに示すように、システム設計者以外の者が、ホスト・システムから通信を送ることにより、または機能を再構成するバー・コード・シンボルを読み取ることにより、システム内のそれぞれの変更可能および／または拡張可能な特徴に関連する機能を再コンフィギュレーションする。

本開示のシステムの特徴／機能の変更方法論に関する簡単な概要を提供したが、これらの方法ステップについて、特に図４および図６〜７Ｆを参照してより詳細に説明する。

例示的な実施形態では、図４に示すプラグインおよびコンフィギュレーション・ファイル・ライブラリに記憶された各プラグイン・モジュールは、１組のソフトウェア・ライブラリ（オブジェクト・モジュール）およびコンフィギュレーション・ファイルからなる。これらは、ホストＰＣで実施されるプラグイン開発プラットホームなどの外部のホスト・システムから、画像処理ベースのバー・コード・シンボル読取システムへダウンロードされることができ、、システムのＯＳ層と通信するために様々な標準または専有の通信プロトコルを使用することができる。画像処理ベースのバー・コード・シンボル読取システムでは、この動作は、ホスト・システムから適当なコマンドが受け取られると、Ｍｅｔｒｏｓｅｔタスクまたはユーザ・コマンド・マネージャにより実行される（ソフトウェア・ブロック図を参照）。ダウンロードが完了すると、プラグイン・ファイルは、画像処理ベースのバー・コード・シンボル読取システムのファイル・システムに記憶される。

すべてのプラグイン・モジュール（即ち、サードパーティ・コード）の管理は、図４に示すプラグイン・コントローラにより実行される。プラグイン・コントローラは、プラグイン・モジュールをファイル・システムから画像処理ベースのバー・コード・シンボル読取システムの実行可能なメモリーへロード（インストール）し、プラグイン・ライブラリとアプリケーションとの動的リンクを実行する動作、プラグイン・モジュールをアンロード（アンインストール）する動作、プラグイン・モジュール（即ち、サードパーティ・コード）の実行可能なアドレス（即ち、プレース・ホルダ）をアプリケーションに提供する動作、プラグイン・コンフィギュレーション・ファイルに記述されたプラグイン・エンゲージメント規則などのような、プラグイン・モジュールに関する追加の情報をアプリケーションに提供する動作などの動作を実行することができる。

画像処理ベースのバー・コード・シンボル読取システムの任意のタスクは、プラグイン・モジュールに関するプラグイン・コントローラからの情報を要求することができ、かつ／またはそれに関する動作を要求することができる。１組の所定の特徴に対して、アプリケーション・タスクは、サードパーティ・プラグイン・モジュールを使用できるかを検査することをプラグイン・コントローラに要求することができ、そのようなモジュールが使用可能である場合、そのモジュールをインストールして、その実行可能アドレスならびにプラグイン・エンゲージメント規則を提供することができる。次いで、これらのタスクは
、このモジュールを、特定の特徴を実施する「標準」モジュールの代わりに又はそれと共に実行することができる。プラグイン・モジュールのエンゲージメント規則、即ち、プラグイン・モジュールを「標準」モジュールに対する交換モジュールとして実行するか又はコンプリメンタリ（ｃｏｍｐｌｉｍｅｎｔａｒｙ）・モジュールとして実行すべきかの判断は、特定の特徴に対して固有のものであり得る。これらの規則はまた、コンプリメンタリ・プラグイン・モジュールを、最初に、または「標準」モジュールの前に最初に実行するべきか、それとも後で実行するべきかを指定することができる。更に、プラグイン・モジュールは、最初に実行される場合、「標準」モジュールも呼び出すべきか否かをデバイスに示し、それにより、デバイスの挙動の変更を可能にすることができる。プログラミング・インターフェースは、プラグインの機能を可能にする特徴に対して事前定義され、サードパーティがデバイスに対して独自のソフトウェアを開発できるようにする。

第１の非常に簡単な例として、画像処理ベースのバー・コード・シンボル読取システムの相手先商標製造業者（ＯＥＭ）がシステムの「標準」画像前処理モジュール（即ち、実行可能なバイナリ形式の「元の製品コード」）を供給する場合を考慮する。典型的に、この画像前処理モジュールは、システムが視野（ＦＯＶ）内の物体の画像を取得した後に、システムのメイン・タスクにより実行される。本開示の原理によれば、顧客は、独自の画像前処理ソフトウェアをプラグイン・モジュール（即ち、「サードパーティ・コード」）として、多層ソフトウェア・ベースのシステムに提供することができる。特に、サードパーティ・コードは、典型的に、実行可能なバイナリ形式で表される。プラグインは、例えば、以下で表される形式を有する「画像前処理プラグイン・コンフィギュレーション・ファイル」に記述することができる。

//画像前処理コンフィギュレーション・ファイル
//タイプパラメータライブラリ関数
IMGPREPR: libimgprepr_plugin.so.1 ->PluginImgprepr
IMGPREPR_PROGMD: libimgprepr_plugin.so.1 ->PluginImgpreprProgmd
IMGPREPR_PROGBC: libimgprepr_plugin.so.1 ->PluginImgpreprProgbc

図１６Ｂに示す流れ図は画像前処理プラグインの論理を示す。

第２のより興味深い例として、図７Ｃに示す画像処理およびバーコード復号化プラグインを考慮する。画像処理ベースのバー・コード・シンボル読取システムの相手先商標製造業者は、図７Ａに示すように、システムが画像を取得した後にメイン・タスクにより通常は実行されるシステムの「標準」画像処理およびバーコード復号化モジュールを供給する。本開示の原理によれば、顧客は、顧客独自の画像処理およびバーコード復号化ソフトウェアをプラグイン・モジュールとして多層のソフトウェア・ベースのシステムに提供することができる。プラグインは、例えば、以下で表される形式を有する「画像処理およびバーコード復号化プラグイン・コンフィギュレーション・ファイル」に記述することができる。

//復号プラグイン・コンフィギュレーション・ファイル
//タイプパラメータライブラリ関数
DECODE: 0x02: libdecode_plugin.so.1 ->PluginDecode

上記で、「ＤＥＣＯＤＥ」は、画像処理およびバーコード復号化プラグインを識別するキーワードであり、「０ｘ０２」は、プラグインのエンゲージメント規則を識別する値であり、「ｌｉｂｄｅｃｏｄｅ＿ｐｌｕｇｉｎ．ｓｏ．１」は、デバイスのファイル・システムのプラグイン・ライブラリの名称であり、「ＰｌｕｇｉｎＤｅｃｏｄｅ」は、顧客特有の画像処理およびバーコード復号化機能を実施するプラグイン関数（機能）の名称であ
る。

この特定のプラグインのエンゲージメント規則を示す値として使用される値「ｐａｒａｍ」の個々のビットは、以下の意味を有することができる。

ビット意味
００＝標準をコンプリメント（compliment）、１＝標準と交換
１（ビット０＝＝０の場合）０＝標準機能前に呼び出す、１＝標準機能後に呼び出す２リザーブ
・・・・・・

従って、値「０ｘ０２」は、顧客プラグインが交換ではなくコンプリメンタリのモジュールであり（ビット「０」は０である）、標準モジュールの実行後に実行されるべきである（ビット「１」は１である）ことを意味する。

第３の例として、図７Ｅに示す画像処理およびバーコード復号化プラグインを考慮する。画像処理ベースのバー・コード・シンボル読取システムの相手先商標製造業者は、図７Ａに示すように、システムが画像を取得した後にメイン・タスクにより通常は実行されるシステムの「標準」画像処理およびバーコード復号化モジュールを供給する。本開示の原理によれば、顧客は、顧客独自の画像処理およびバーコード復号化ソフトウェアをプラグイン・モジュールとして、多層のソフトウェア・ベースのシステムに提供することができる。プラグインは、例えば、以下で表される形式を有する「画像処理およびバーコード復号化プラグイン・コンフィギュレーション・ファイル」に記述することができる。

//データ・フォーマッティング・プラグイン・コンフィギュレーション・ファイル
//タイプパラメータライブラリ関数
PREFORMAT: libformat_plugin.so.1 ->PluginPreformat
FORMAT_PROGMD: libformat_plugin.so.1 ->PluginFormatProgmd
FORMAT_PROGBC: libformat_plugin.so.1 ->PluginFormatProgbc

図１６Ｅに示すブロック図は、データ・フォーマッティング・手順プラグインの論理を示す。

上述のプラグインは、本開示の原理に従ってシステムの可能な特徴および機能をシステム設計者以外の者により変更できるように開発される多くの種類のプラグイン（オブジェクト）の幾つかの例を提供する。プラグイン・モジュールを開発でき画像処理ベースのバー・コード・シンボル読取システム内におよびインストールできる他のシステムの特徴および機能は、ＩＲベースの物体存在および範囲検出サブシステム１２、多モードのエリア・タイプの画像形成および検出（即ち、カメラ）サブシステム１３、多モードのＬＥＤベースの照射サブシステム１４、自動露光測定および照射制御サブシステム１５、画像取込みおよびバッファリング・サブシステム１６、多モードの画像処理バー・コード・シンボル読取サブシステム１７、入出力サブシステム１８、手動作動可能トリガ・スイッチ２Ｃ、システム・モード・コンフィギュレーション・パラメータ・テーブル７０、システム制御サブシステム１８、ならびに画像処理ベースのバー・コード・シンボル読取システムに組み込むことができる任意の他のサブシステム、というようなシステムによりサポートされ実行される機能に関する制御を含むが、これに限定されるものではない。

ＯＥＭシステム設計者以外の者により生成できるプラグイン・モジュールの構造および機能について説明したが、次に図４および５を参照して本開示のプラグイン開発プラットホームの例示的な実施形態について説明する。

例示的な実施形態では、システム（例えば、ＭｅｔｒｏｌｏｇｉｃＦｏｃｕｓ（商標）１６９０画像処理バー・コード・リーダ）のシステム設計者／ＯＥＭは、例えば以下のソフトウェア・ツールを含むＣＤをプラグイン開発者へ提供する。

・Ｌｉｎｕｘ（登録商標）ＰＣ用のＡｒｍＬｉｎｕｘ（登録商標）Ｔｏｏｌｃｈａｉｎ（ツールチェーン）
このディレクトリは、ＩＢＭコンパチブルのＬｉｎｕｘ（登録商標）ＰＣ向けのＡｒｍ
Ｌｉｎｕｘ（登録商標）クロスコンパイル・ツールチェーン（ｃｒｏｓｓ−ｃｏｍｐｉｌｉｎｇｔｏｏｌｃｈａｉｎ）・パッケージを含む。

・Ｃｙｇｗｉｎ用のＡｒｍＬｉｎｕｘ（登録商標）ツールチェーン
このディレクトリは、ＩＢＭ（登録商標）コンパチブルのＷｉｎｄｏｗｓ（登録商標）ＰＣ向けのＡｒｍＬｉｎｕｘ（登録商標）クロスコンパイル・ツールチェーン・パッケージを含む。Ｃｙｇｗｉｎソフトウェアは、このクロスコンパイル・ツールチェーンを使用する前にインストールしなければならない。

・プラグイン・サンプル
このディレクトリは、サンプル・プラグイン開発プロジェクトを含む。このプラグイン・ソフトウェアは、Ｌｉｎｕｘ（登録商標）ＰＣ用のＡｒｍＬｉｎｕｘ（登録商標）ツールチェーンを使用するＩＢＭコンパチブルのＬｉｎｕｘ（登録商標）ＰＣ上で、またはＣｙｇｗｉｎ用のＡｒｍＬｉｎｕｘ（登録商標）ツールチェーンを使用するＣｙｇｗｉｎソフトウェアがインストールされたＷｉｎｄｏｗｓ（登録商標）ＰＣ上で、コンパイルしなければならない。

・ＦＷＺＭａｋｅｒ
このディレクトリは、Ｗｉｎｄｏｗｓ（登録商標）ＰＣ用のプログラムＦＷＺＭａｋｅｒのインストール・パッケージを含む。このプログラムは、Ｆｏｃｕｓ１６９０スキャナへダウンロードされるＦＷＺファイルを構築するために使用される。

・ＬａｔｅｓｔＭｅｔｒｏｌｏｇｉｃ（登録商標）Ｆｏｃｕｓ（商標）ソフトウェア
このディレクトリは、ＬａｔｅｓｔＭｅｔｒｏｌｏｇｉｃ（登録商標）Ｆｏｃｕｓ（商標）スキャナ・ソフトウェアを有するＦＷＺファイルを含む。

プラグイン・ソフトウェア開発プロセスの第１のステップは、ホスト／開発者のコンピュータ・システムに上記のツールをインストールすることにより、プラグイン開発者プラットホームを構成することを伴う。次のステップは、画像処理バー・コード・リーダへ、システム・ソフトウェアを、図１０および１１に示すシステムの通信ポートとプラグイン開発者コンピュータとの間の通信ケーブルを使用して、ホスト・プラグイン開発者プラットホームを介して、インストールすることを伴う。

プラグイン・ソフトウェアを開発するために、プラグイン開発者プラットホーム（即ち、Ｌｉｎｕｘ（登録商標）ＰＣ）上、またはＷｉｎｄｏｗｓ（登録商標）Ｃｙｇｗｉｎ内に、対応する共有ライブラリを開発することができ、次いで、適正なプラグイン・コンフィギュレーション・ファイルを開発することができる。次いで、プラグイン・コンフィギュレーション・ファイルは、プラグイン、例えば、ＭｅｔｒｏｌｏｇｉｃのＦｏｃｕｓ（商標）の画像処理バー・コード・リーダなどのような画像キャプチャおよび処理デバイスを開発する場合、「／ｕｓｒ」ディレクトリへロードされる。この例示的な実施形態では、プラグイン・コンフィギュレーション・ファイルの各行は、プラグイン関数に関する情報を以下の形式で含む。

plug-in type: parameter: filename ->function_name

上記で、ｐｌｕｇ−ｉｎｔｙｐｅは、サポートされるプラグイン・タイプのキーワードの１つであり、フィールド区切り文字「：」が続く。

上記で、ｐａｒａｍｅｔｅｒは、幾つかのプラグイン関数に対して特有の一意の意味を有する数（１０進数、または０ｘが先行する場合１６進数とすることができる）である。パラメータはまた、「呼出しモード」と呼ばれ、プラグインをどのように呼び出すべきかに関する何らかの特有の情報を提供することができる。パラメータは、必要とされるものではなく、省略することができる。指定される場合、パラメータには、フィールド区切り文字「：」が続かなければならない。

上記で、ｆｉｌｅｎａｍｅは、共有ライブラリの名称であり、ファイル名区切り文字「−＞」が続く。ファイル名は、ライブラリへのフルパス（full-path）を含むことができ
る。パスが省略される場合、ライブラリは、Ｆｏｃｕｓスキャナ内の「／ｕｓｒ／ｌｏｃａｌ／ｌｉｂ」または「／ｕｓｒ／ｌｉｂ／」ディレクトリに位置するものとする。従って、共有ライブラリは、プラグイン・コンフィギュレーション・ファイルにより指定されるスキャナ内の正しいディレクトリにロードされることが重要である。

上記で、ｆｕｎｃｔｉｏｎ＿ｎａｍｅは、対応するプラグインＣ関数の名称である。

特に、プラグイン・コンフィギュレーション・ファイルはまた、単一行のＣ式コメントを含むことができる。

何れのプラグイン関数（システム設計者によりサポートされる）がプラグイン・モジュール（即ち、「オブジェクト」）に含まれるべきかを決定するのは、プラグイン開発者の裁量の範囲内である。共有ライブラリが構築され、プラグイン開発プラットホーム（図４および５に示す）上にコンフィギュレーション・ファイルが準備された後、プラグイン開発者は、ＦＷＺファイルを生成し、Ｗｉｎｄｏｗｓ（登録商標）ＰＣ上のＦＷＺＭａｋｅｒプログラムを使用して、コンフィギュレーション・ファイルおよび共有ライブラリをＦＷＺファイルの中に含ませることができる。その後、ＦＷＺファイルは、例えば、ＭｅｔｒｏｌｏｇｉｃのＭｅｔｒｏｓｅｔプログラムのフラッシュ・ユーティリティ・ツールを使用して、ＭｅｔｒｏｌｏｇｉｃのＦｏｃｕｓ（商標）画像処理バー・コード・リーダにダウンロードすることができる。

ＭｅｔｒｏｌｏｇｉｃのＦｏｃｕｓ（商標）画像処理バー・コード・リーダ用のプラグイン・ソフトウェアをインストールする場合、動的メモリ割当てを使用しないことが推奨され、動的に割り当てるのではなく静的バッファを有することが推奨される。ファイルシステムに関する限り、ファイル内にデータを記憶する必要がある場合、不揮発性フラッシュ・メモリにデータを記憶するためには「／ｕｓｒ／」および「／ｕｓｒ／ｌｏｃａｌ」などの位置が推奨され、「／ｔｍｐ」ディレクトリは、データをＲＡＭに記憶するために使用することができる。

［デジタル画像キャプチャおよび処理のシステムのプログラミング・バーコードおよびプログラミング・モード］

例示的な実施形態では、本開示の画像処理バー・コード・リーダのコンフィギュレーションは、特別なプログラミング・バーコードを走査することを介して、またはホスト・コンピュータ（即ち、プラグイン開発コンピュータ）からリーダへ同等のデータを送ること
により、変更することができる。プログラミング・バーコードは、通常、Ｆｎ３という符号語（codeword）を有するＣｏｄｅ１２８シンボルである。

プログラミング・バーコードを走査するとき、リーダは、いわゆるプログラミング・モードにないこともある。リーダがプログラミング・モードではないとき、プログラミング・バーコードの影響は、即時であると想定される。一方、リーダがプログラミング・モードにあるとき、プログラミング・モード中に読み取られるすべてのプログラミング・バーコードの影響は、リーダがプログラミング・モードを終了した時点で生じる。

プラグイン・ソフトウェアのコンフィギュレーションの目的でリザーブされた１組の特別なプログラミング・バーコードが存在する。これらのバーコードは少なくとも４つのデータ文字を有し、最初の３つのデータ文字は「９９０」である。復号プラグインは、「９９００ｘｘ」で始まる６文字の長さを有するプログラミング・バーコードを使用することが推奨される（必ずしもというわけではない）。画像前処理プラグインは、「９９０１ｘｘ」で始まる６文字の長さを有するプログラミング・バーコードを使用することが推奨される（必ずしもというわけではない）。フォーマッティング・プラグインは、「９９０２ｘｘ」で始まる６文字の長さを有するプログラミング・バーコードを使用することが推奨される（必ずしもというわけではない）。

本開示の原理に従ってプラグイン・モジュールが開発された後、プラグインは、単に、空のプラグイン・コンフィギュレーション・ファイルをダウンロードすることにより、アンインストールすることができる。例えば、復号プラグインをアンインストールするには、図１０に示すＯＳ層内のファイル・システムの「／ｕｓｒ」ディレクトリへ空の「ｄｅｃｏｄｅ．ｐｌｕｇｉｎ」ファイルをダウンロードする。

［例示的な実施形態の復号プラグインに関する詳細］

復号プラグインの目的は、システムに提供される標準バーコード復号化に対する交換またはコンプリメンタリのバーコード復号化ソフトウェアを提供することである。復号プラグインは、以下のプラグイン関数を有することができる。

DECODE; DECODE_ENABLE2D; DECODE_PROGMD; DECODE_PROGBC

［復号（DECODE）プラグイン関数］

この関数は、メモリ内の所与の画像からバーコード復号化を実行するために呼び出される。画像は、８ビット画素の２次元アレイとしてメモリ内で表されている。アレイの第１の画素は、画像の左上隅部を表す。

関数プロトタイプ：
int /* 戻り：復号されたバーコードの数、誤り場合は負 */
(*PLUGIN_DECODE)(
void *p_image, /* 入力：画像へのポインタ */
int size_x, /* 入力：列数 */
int size_y, /* 入力：行数 */
int pitch, /* 入力：行サイズ、バイト単位 */
DECODE_RESULT *p_decode_results, /* 出力：復号結果 */
int max_decodes, /* 入力：可能な最大復号結果 */
int *p_cancel_flag); /* 入力：NULLではない場合、取消しフラグへのポインタ */

ｐ＿ｄｅｃｏｄｅ＿ｒｅｓｕｌｔｓは、復号プラグイン関数（機能）が、ＤＥＣＯＤＥ＿ＲＥＳＵＬＴ構造のアレイの形でバーコード復号化の１または複数の結果を記憶するメモリ内の位置を指すことに留意されたい（もちろん、プラグインが所与の画像内の１または複数のバーコードの復号に成功した場合）。可能な復号結果の最大数（即ち、アレイの寸法）は、ｍａｘ＿ｄｅｃｏｄｅｓで与えられる。プラグインは、復号に成功したバーコードの数（即ち、アレイｐ＿ｄｅｃｏｄｅ＿ｒｅｓｕｌｔｓ内のポピューレートされた要素の数）、または誤りの場合は負の数を、戻さなければならない。

ｐ＿ｃａｎｃｅｌ＿ｆｌａｇがＮＵＬＬではない場合、復号化プロセスを継続するべきか、それとも可能な限り早く停止するべきかを示す整数フラグ（「取消しフラグ（Cancel
flag）」と呼ばれる）を指す。このフラグが０である場合、復号化プロセスは継続する
ことができる。このフラグがゼロではない場合、復号化プロセスは可能な限り早く停止しなければならない。復号化プロセスを中止（アボート）させる理由は、例えば、タイム・アウトであり得る。復号化プロセスを中止させる待ち時間を可能な限り短くするために、十分な頻度で取消しフラグを検査することが推奨される。

取消しフラグは、復号化プラグイン（またはそれに関する任意のプラグイン）を中止できる唯一の方法ではないことに留意されたい。状況に応じて、システムは、復号化プラグインが動作しているスレッドを任意の時点で急に停止することを決めることができる。

構造ＤＥＣＯＤＥ＿ＲＥＳＵＬＴ

構造ＤＥＣＯＤＥ＿ＲＥＳＵＬＴは、以下の形式を有する。

#define MAX_DECODED_DATA_LEN 4096
#define MAX_SUPPL_DATA_LEN 128
typedef struct {
int x;
int y;
} BC_POINT;
typedef struct {
BC_POINT BCPts[4]; /* バーコードの４つの隅部の座標 */
} BC_BOUNDS;

ＢＣ＿ＢＯＵＮＤＳ構造内のアレイ・エレメント（即ち、隅部）の順序は、次の通りである。

０−左上
１−右上
２−右下
３−左下

typedef struct {
int decode_result_index; /* 復号結果の索引、０から開始*/
int num_decode_results; /* 復号結果の総数から１を引いた値(即ち、０ベース) */
char SymId[32]; /* シンボル体系識別子文字 */
int Symbology; /* 復号されたバーコードのシンボル体系識別子番号 */
int Modifier; /* 復号されたバーコードの追加情報 */
int DecId; /* リザーブ */
int Class; /* １Ｄの場合は１、２Ｄの場合は２ */
unsigned char Data[MAX_DECODED_DATA_LEN]; /* 復号されたデータ、ＮＵＬＬ文字を含み得る */
int Length; /* 復号されたバーコード内の文字数 */
unsigned char SupplData[MAX_SUPPL_DATA_LEN]; /* 補足コードのデータ */
int SupplLength; /* 補足コードのデータ内の文字数 */
unsigned char LinkedData[MAX_DECODED_DATA_LEN];
int LinkedLength;
BC_BOUNDS C_Bounds; /* １次バーコードに対する境界 */
BC_BOUNDS S_Bounds; /* 補足バーコードに対する境界 */
} DECODE_RESULT;

それぞれのポピューレートされたＤＥＣＯＤＥ＿ＲＥＳＵＬＴ構造の最初の２つのメンバは、アレイに復号結果のゼロ・ベースの索引を含まなければならず（即ち、第１の復号結果は、ｄｅｃｏｄｅ＿ｒｅｓｕｌｔ＿ｉｎｄｅｘ＝０、第２の復号結果は、ｄｅｃｏｄｅ＿ｒｅｓｕｌｔ＿ｉｎｄｅｘ＝１、など以下同様にこのような結果をユウサなければならない）、また復号に成功したバーコードのゼロ・ベースの総数（戻された値から１を引いた値に等しいはずである）を含まなければならない。

ＤＥＣＯＤＥ＿ＲＥＳＵＬＴ構造のＳｙｍＩｄメンバは、バーコード・シンボル体系を記述する最大３１のＮＵＬＬで終了する文字（NULL-terminated Characters）の列（ストリング）を有することができる。これは情報を提供する目的のみで使用される。以下の値は、幾つかの知られているバーコード・シンボル体系に推奨される。

"AZTEC" Aztec
"CBR" Codabar
"CBK_A" Codablock A
"CBK_F" Codablock F
"C11" Code 11
"C128" Code 128
"C39" Code 39
"C93" Code 93
"DM" Datamatrix
"S2O5" Straight 2 of 5
"I2O5" Interleaved 2 of 5
"MC" MexiCode
"PDF" Code PDF
"QR" Code QR
"RSS-E" Code RSS-E
"RSS-EST" Code RSS-EST
"RSS14-LIM" Code RSS Limited
"RSS14" Code RSS-14
"RSS14-ST" Code RSS-ST
"UPC" Code UPC/EAN

ＤＥＣＯＤＥ＿ＲＥＳＵＬＴ構造のシンボル体系メンバは、復号されたバーコード・シンボル体系の識別（ＩＤ）を含まなければならない。以下のシンボル体系ＩＤは、知られているバーコード・シンボル体系に使用しなければならない。

MBCD_SYM_C128 Code 128
MBCD_SYM_C39 Code 39
MBCD_SYM_ITF Interleaved 2 of 5
MBCD_SYM_C93 Code 93
MBCD_SYM_CBR Codabar
MBCD_SYM_UPC Code UPC/EAN
MBCD_SYM_TPEN Telepen
MBCD_SYM_RSS14 Code RSS-14
MBCD_SYM_RSSE Code RSS-E
MBCD_SYM_RSSL Code RSS Limited
MBCD_SYM_MTF Matrix 2 of 5
MBCD_SYM_ATF Airline 2 of 5
MBCD_SYM_STF Straight 2 of 5
MBCD_SYM_MPLY MSI Plessey
MBCD_SYM_C11 Code 11
MBCD_SYM_PDF Code PDF
MBCD_SYM_PN Postnet
MBCD_SYM_DM Datamatrix
MBCD_SYM_MC MaxiCode
MBCD_SYM_QR Code QR
MBCD_SYM_AZ Aztec
MBCD_SYM_MICROPDF MicroPDF
MBCD_SYM_CBLA 1Codablock A
MBCD_SYM_CBLF Codablock F
MBCD_SYM_UNKNOWN ユーザ定義のシンボル体系

ＤＥＣＯＤＥ＿ＲＥＳＵＬＴ構造の変更子（Modifier）メンバは、復号されたバーコードに関する追加の情報を含む。変更子の値は、通常、ビットの結合されたものである。これらの値は様々シンボル体系に対して固有であり、多くのシンボル体系は変更子を一切使用しない。変更子が使用されない場合、このメンバは０に設定するべきである。変更子をサポートする幾つかのシンボル体系に対して、可能な値を以下に提示する。

Ｃｏｕｐｏｎ（クーポン）変更子
MBCD_MODIFIER_COUP Ｃｏｕｐｏｎのコード

ＵＰＣ変更子ビット・フラグ定数
MBCD_MODIFIER_UPCA UPC-A
MBCD_MODIFIER_UPCE UPC-E
MBCD_MODIFIER_EAN8 EAN-8
MBCD_MODIFIER_EAN13 EAN-13
MBCD_MODIFIER_SUPP2 ２桁捕捉
MBCD_MODIFIER_SUPP5 ５桁補足

Ｃｏｄｅ１２８変更子ビット・フラグ定数
MBCD_MODIFIER_C128A 開始文字Aを有するCode128
MBCD_MODIFIER_C128B 開始文字Bを有するCode128
MBCD_MODIFIER_C128C 開始文字Cを有するが、EAN128でないCode128
MBCD_MODIFIER_EAN128 EAN-128
MBCD_MODIFIER_PROG プログラミング・ラベル（他のすべての事柄に優先）
MBCD_MODIFIER_AIM_AI AIMアプリケーション・インジケータを有するCode128

Ｃｏｄｅ３９変更子ビット・フラグ定数
MBCD_MODIFIER_ITPHARM イタリアの製薬

Ｃｏｄａｂａｒ変更子ビット・フラグ定数
MBCD_MODIFIER_CBR_DF Double-Field Codabar（２フィールド・コーダバー）

ＰＯＳＴＮＥＴｉＭｏｄｉｆｉｅｒビット・フラグ定数
MBCD_MODIFIER_PN POSTNET（ポストネット）
MBCD_MODIFIER_JAP 日本郵便
MBCD_MODIFIER_AUS オーストラリア郵便
MBCD_MODIFIER_PLANET PLANET（プラネット）
MBCD_MODIFIER_RM ロイヤル・メール
MBCD_MODIFIER_KIX ＫＩＸコード
MBCD_MODIFIER_UPU57 UPU (５７バー)
MBCD_MODIFIER_UPU75 UPU (７５バー)

Ｄａｔａｍａｔｒｉｘ変更子ビット・フラグ定数
MBCD_MODIFIER_ECC140 ECC 000-140
MBCD_MODIFIER_ECC200 ECC 200
MBCD_MODIFIER_FNC15 ECC 200、ＦＮＣ１は第１または第５の位置
MBCD_MODIFIER_FNC26 ECC 200、ＦＮＣ１は第２または第６の位置
MBCD_MODIFIER_ECI ECC 200、ＥＣＩプロトコル実施
MBCD_MODIFIER_FNC15_ECI ECC 200、ＦＮＣ１は第１まは第５の位置、ＥＣＩプロトコル
MBCD_MODIFIER_FNC26_ECI ECC 200、ＦＮＣ１は第２または第６の位置、ＥＣＩプロトコル
MBCD_MODIFIER_RP リーダ・プログラミング・コード

ＭａｘｉＣｏｄｅ変更子ビット・フラグ定数
MBCD_MODIFIER_MZ モード０のシンボル
MBCD_MODIFIER_M45 モード４または５のシンボル
MBCD_MODIFIER_M23 モード２または３のシンボル
MBCD_MODIFIER_M45_ECI モード４または５のシンボル、ＥＣＩプロトコル
MBCD_MODIFIER_M23_ECI モード２または３のシンボル、ＥＣＩプロトコル

ＤＥＣＯＤＥ＿ＲＥＳＵＬＴ構造のＤｅｃＩｄメンバは現在使用されておらず、０に設定するべきである。

ＤＥＣＯＤＥ＿ＲＥＳＵＬＴ構造のＣｌａｓｓメンバは、１または２に設定しなければならない。復号されたバーコードが、ＵＰＣ、Ｃｏｄｅ３９、ＲＳＳなどのような通常のリニア・バーコードである場合、このクラスは１に設定するべきである。復号されたバーコードが、ＣｏｄｅＰＤＦ、Ｄａｔａｍａｔｒｉｘ、Ａｚｔｅｃ、ＭａｘｉＣｏｄｅなどのような２Ｄシンボル体系である場合、このクラスは２に設定するべきである。

ＤＥＣＯＤＥ＿ＲＥＳＵＬＴ構造のＤａｔａメンバは、復号されたデータを含む。このメンバは、ＭＡＸ＿ＤＥＣＯＤＥＤ＿ＤＡＴＡ＿ＬＥＮバイトまでのデータを含むことができる。

ＤＥＣＯＤＥ＿ＲＥＳＵＬＴ構造のＬｅｎｇｔｈメンバは、何バイトの復号されたデータがＤａｔａ内に記憶されるかを指定する。

ＤＥＣＯＤＥ＿ＲＥＳＵＬＴ構造のＳｕｐｐｌＤａｔａメンバは、クーポンなどのようなバーコードの補足部分内で復号されたデータを含む。このメンバは、ＭＡＸ＿ＤＥＣＯＤＥＤ＿ＤＡＴＡ＿ＬＥＮバイトまでのデータを含むことができる。

ＤＥＣＯＤＥ＿ＲＥＳＵＬＴ構造のＳｕｐｐｌＬｅｎｇｔｈメンバは、何バイトの復号されたデータがＳｕｐｐｌＤａｔａに記憶されるかを指定する。

ＤＥＣＯＤＥ＿ＲＥＳＵＬＴ構造のＬｉｎｋｅｄＤａｔａメンバは、ＲＳＳ／ＰＤＦの合成体などのような合成バーコードの２次的部分においての復号されたデータを含む。このメンバは、ＭＡＸ＿ＤＥＣＯＤＥＤ＿ＤＡＴＡ＿ＬＥＮバイトまでのデータを含むことができる。

ＤＥＣＯＤＥ＿ＲＥＳＵＬＴ構造のＬｉｎｋｅｄＬｅｎｇｔｈメンバは、何バイトの復号されたデータがＬｉｎｋｅｄＤａｔａに記憶されるかを指定する。

ＤＥＣＯＤＥ＿ＲＥＳＵＬＴ構造のＣ＿ＢｏｕｎｄｓおよびＳ＿Ｂｏｕｎｄｓメンバは、現在使用されていない。

［ＤＥＣＯＤＥプラグイン呼出しモード］

ＤＥＣＯＤＥプラグインは、以下の呼出しモード値を有することができる。

ビット値
０ <-- ０＝標準をコンプリメント、１＝標準と交換
１ <-- （ビット０＝＝０の場合）０＝標準関数前に呼び出す、１＝標準関数後に呼び出す

デフォルトの呼出しモード値は０であり、デフォルトではＤＥＣＯＤＥプラグインは、標準のＦｏｃｕｓバーコード復号化ソフトウェアに対するコンプリメンタリ・モジュールであると見なされ、標準関数（標準機能）前に実行されることを意味する。この場合、標準関数は、ＤＥＣＯＤＥプラグインから戻った結果が負およびｍａｘ＿ｄｅｃｏｄｅｓ未満ではない場合にのみ呼び出される。

［ＤＥＣＯＤＥ＿ＥＮＡＢＬＥ２Ｄプラグイン関数］

この関数は、スキャナが２Ｄシンボル体系（ＰＤＦ４１７、Ｄａｔａｍａｔｒｉｘなど）の復号化を許すか又は許さないべきである動作モードに入ったことをプラグインに通知するために呼び出される。デフォルトで、２Ｄシンボル体系の復号化は許される。

関数プロトタイプ：
void
(*PLUGIN_ENABLE2D)(int enable); /* 入力：０＝ディスエーブル、１＝イネーブル */

例えば、Ｆｏｃｕｓスキャナがリニア・モード（全方向モードとは異なる）で働くように構成されるとき、２Ｄシンボル体系の復号化は許可されない。

［ＤＥＣＯＤＥ＿ＰＲＯＧＭＤプラグイン関数］

この関数は、スキャナがプログラミング・モードに入ったことをプラグインに通知する
ために呼び出される。

関数プロトタイプ：
void
(*PLUGIN_PROGMD)(int progmd); /* 入力：１＝入る、０＝通常の退出、（−１）＝アボ
ート */

［ＤＥＣＯＤＥ＿ＰＲＯＧＢＣプラグイン関数］

この関数は、コンフィギュレーションの目的でプラグインにより使用され得るプログラミング・バーコードをスキャナが今走査したところであることをプラグインに通知するために呼び出される。

関数プロトタイプ：
int /* 戻り：成功の場合は１、バーコードが無効の場合は０、誤りの場合は負 */
(*PLUGIN_PROGBC)(unsigned char *bufferptr,
int data_len);

［本開示の例示的な実施形態の画像前処理プラグインに関する詳細］

画像前処理プラグインの目的は、プラグインが画像取得の直後でバーコード復号化の前に何らかの特別な画像処理を実行できるようにすることである。画像前処理プラグインは、以下のプラグイン関数を有することができる。

IMGPREPR; IMGPREPR_PROGMD; IMGPREPR_PROGBC

［ＩＭＧＰＲＥＰＲプラグイン関数］

この関数は、画像前処理を実行するために呼び出される。画像は、８ビット画素の２次元アレイとして、メモリ内で表されている。アレイの第１の画素は、画像の左上隅部を表す。

関数プロトタイプ：
int /* 戻り：前処理が行われた場合は１、そうでない場合は０、誤りの場合は負 */
(*PLUGIN_IMGPREPR)(
void *p_image, /* 入力：画像へのポインタ */
int size_x, /* 入力：列数 */
int size_y, /* 入力：行数 */
int pitch, /* 入力：行サイズ、バイト単位 */
void **pp_new_image, /* 出力：新しい画像へのポインタ*/
int *p_new_size_x, /* 出力：新しい列数 */
int *p_new_size_y, /* 出力：新しい行数 */
int *p_new_pitch); /* 出力：新しい行サイズ、バイト単位 */

ＩＭＧＰＲＥＰＲプラグイン関数が成功して行われた場合、１を戻し、ｐｐ＿ｎｅｗ＿ｉｍａｇｅで示されるメモリ内の位置に新しい画像のアドレスを記憶する。新しい画像の寸法は、ｐ＿ｎｅｗ＿ｓｉｚｅ＿ｘ、ｐ＿ｎｅｗ＿ｓｉｚｅ＿ｙ、およびｐ＿ｎｅｗ＿ｐｉｔｃｈにより示される位置に記憶される。

理由が何であれ前処理が実行されなかった場合、ＩＭＧＰＲＥＰＲプラグイン関数は０
を戻さなければならない。

戻される負の値は誤りを示す。

［ＩＭＧＰＲＥＰＲ＿ＰＲＯＧＭＤプラグイン関数］

この関数は、スキャナがプログラミング・モードに入ったことをプラグインに通知するために呼び出される。

［ＩＭＧＰＲＥＰＲ＿ＰＲＯＧＢＣプラグイン関数］

関数プロトタイプ：
int /* 戻り：成功の場合は１、バーコードが無効である場合は０、誤りの場合は負 */
(*PLUGIN_PROGBC)(unsigned char *bufferptr,
int data_len);

［例示的な実施形態のフォーマッティング・プラグインに関する詳細］

フォーマッティング・プラグインの目的は、標準データ・フォーマッティング・ソフトウェアに、交換またはコンプリメンタリのソフトウェアを提供することである。フォーマッティング・プラグイン・コンフィギュレーション・ファイルは、「ｆｏｒｍａｔ．ｐｌｕｇｉｎ」という名称を有し、スキャナ内の「／ｕｓｒ」ディレクトリにロードされなければならない。

フォーマッティング・プラグインは、現在、以下のプラグイン関数を有することができる。
PREFORMAT; FORMAT_PROGMD; FORMAT_PROGBC

［ＰＲＥＦＯＲＭＡＴプラグイン関数］

この関数は、データが実際にフォーマットされて送り出される前に、復号されたバーコード・データの必要な変換を実行するために呼び出される。

関数プロトタイプ：
int /* 戻り：プリフォーマットが行われた場合は１、そうでない場合は０、誤りの場
合は負 */
(*PLUGIN_PREFORMAT)(
DECODE_RESULT *decode_results, /* 入力：復号結果 */
DECODE_RESULT *new_decode_results); /* 出力：プリフォーマットされた復号結果 */

ＰＲＥＦＯＲＭＡＴプラグイン関数が成功して行われた場合、１を戻し、ｎｅｗ＿ｄｅｃｏｄｅ＿ｒｅｓｕｌｔｓで示されるメモリ内の位置に新しい復号結果を記憶する。

理由が何であれプリフォーマッティングが実行されなかった場合、ＰＲＥＦＯＲＭＡＴプラグイン関数は０を戻さなければならない。

負の値が戻されると誤りを示す。

ＤＥＣＯＤＥ＿ＲＥＳＵＬＴ構造に関する詳細は、ＤＥＣＯＤＥプラグイン関数の項を参照されたい。

［ＦＯＲＭＡＴ＿ＰＲＯＧＭＤプラグイン関数］

関数プロトタイプ：
void
(*PLUGIN_PROGMD)(int progmd); /* 入力：１＝入る、０＝通常退出、（−１）＝アボート */

［ＦＯＲＭＡＴ＿ＰＲＯＧＢＣプラグイン関数］

上記のシステムの特徴／関数の変更の方法は、多様なアプリケーション環境で実行することができ、本明細書に上述した画像処理ベースのバー・コード・シンボル読取システムに限定されるものではない。通常、アプリケーション・ソフトウェア層と、少なくとも画像キャプチャ機構および画像処理機構とをサポートするあらゆる画像キャプチャおよび処理システムまたはデバイスが、本開示を実行するのに適している。従って、画像を取り込む携帯電話、デジタル・カメラ、ビデオ・カメラ、ならびに携帯型または移動型の演算端末、および携帯型データ端末（ＰＤＴ）はすべて、本開示を実施できる適切なシステムである。

また、上述のプラグイン開発技法を使用してシステムの特徴および機能を変更する前述の設備を有する、図４に示す本開示の画像処理バー・コード・シンボル読取システムのアプリケーション層は、画像キャプチャおよび処理機能をサポートし且つ適したユーザ／通信インターフェースを備える従来の移動式の演算デバイス、ＰＤＡ、ポケット型パーソナル・コンピュータ（ＰＣ）、および他の携帯型のデバイスで実行するように移植できることが理解される。

上述した本開示の画像キャプチャおよび処理システムは、ＣＭＯＳセンサ、トリガ・スイッチなどを装備するＰａｌｍ（登録商標）、ＰｏｃｋｅｔＰＣ（登録商標）、Ｍｏｂｉ
ｌｅＰＣ（登録商標）、ＪＶＭ（登録商標）などのような様々なハードウェア演算プラットホームで実施することができる。そのような例示的な実施形態では、本開示の３層システム・ソフトウェア・アーキテクチャは、低層のＬｉｎｕｘ（登録商標）ＯＳ（本明細書で記載）をＰａｌｍ、ＰｏｃｋｅｔＰＣ、Ａｐｐｌｅ（登録商標）ＯＳＸなどのような任意のオペレーティング・システム（ＯＳ）と交換することにより、容易に変更することができる。

更に、本明細書に述べた中間層のＳＣＯＲＥサブシステムが、何らかの形式の画像センサ、トリガ・スイッチなどを装備する特有のハードウェア・プラットホームをサポートするという条件、および同じ（または類似の）上層の「コード・シンボル読取システム」アプリケーションが、そのプラットホームに対してコンパイルされるという条件で、任意の汎用の（移動式の）演算デバイスは、図２Ａ〜５に示し、本明細書に詳細に述べたシステムのバー・コード・シンボル読取機能を有する画像キャプチャおよび処理システムへと変換することができる。本開示のそのような代替実施形態では、サードパーティである顧客が、基礎となるハードウェア・プラットホーム、通信プロトコル、および／またはユーザ・インターフェースのいかなる知識も必要とすることなく、独自のソフトウェア・プラグインを書き、汎用移動演算プラットホーム上で実現される画像キャプチャおよび処理デバイスの挙動を強化または変更することを可能にすることができる。

［高性能の機能に関しての画像キャプチャおよび処理システムのモジュール式のソフトウェア・アーキテクチャのサードパーティ・プログラミングの技法］

上述のように、すべてのプラグイン・モジュールの管理は、図４に示すプラグイン・コントローラにより実行され、このコントローラは、例えば、プラグイン・モジュールをファイル・システムからシステムの実行可能なメモリにロード（インストール）し、プラグイン・ライブラリとアプリケーションとの動的リンクを実行すること、プラグイン・モジュールをアンロード（アンインストール）すること、プラグイン・モジュール（即ち、サードパーティ・コード）の実行可能なアドレス（即ち、プレース・ホルダ）をアプリケーションに提供すること、およびプラグイン・コンフィギュレーション・ファイルに記述されたプラグイン・エンゲージメント規則などのようなプラグイン・モジュールに関する追加の情報をアプリケーションに提供することなどの動作を実行できる。

１組の所定の特徴に対して、アプリケーション・タスクは、サードパーティ・プラグイン・モジュールを使用できるかを検査することを、プラグイン・コントローラに要求することができ、そのようなモジュールが使用可能である場合、そのモジュールをインストールして、その実行可能アドレスならびにプラグイン・エンゲージメント規則を提供することができる。次いで、これらのタスクは、そのモジュールを、特定の特徴を実施する「標準」モジュールの代わりに、またはそれと共に、実行することができる。プラグイン・モジュールのエンゲージメント規則、即ち、プラグイン・モジュールを「標準」モジュールに対する交換モジュールとして実行すべきか又はコンプリメンタリ・モジュールとして実行すべきかの判断は、特定の特徴に対して固有のものであり得る。これらの規則はまた、コンプリメンタリ・プラグイン・モジュールを、「標準」モジュールの前に第１に実行するべきか、それとも後で実行するべきかを指定することができる。更に、プラグイン・モジュールは、第１に実行される場合、「標準」モジュールも呼び出すべきか否かをデバイスに示し、それにより、デバイスの挙動の変更を可能にすることができる。プログラミング・インターフェースは、プラグイン関数（機能）を可能にする特徴に対して事前定義され、従って、サードパーティがデバイスに対して独自のソフトウェアを開発できるようにする。

上述のように、各プラグイン・モジュールに対するコンフィギュレーション・ファイル
は、「ｐａｒａｍ」で示されるプログラム可能なパラメータを含み、その個々のビット値は、プラグインのエンゲージメント規則を示すために使用され、従って、例えば、顧客のプラグインが交換モジュールではなくコンプリメンタリ・モジュールであるか否かを示し、従って、プラグイン・モジュールを標準モジュールの実行後に実行するべきであることを示すために使用される。

上述のプラグイン・モジュール・コンフィギュレーション・ファイルにおける「ｐａｒａｍ」ビットを使用することで、標準モジュール後のプラグイン・モジュールの実行を示すことが可能であるが、より複雑（複合的）なプログラミング論理をプラグイン・コンフィギュレーション・ファイルに追加することにより、より大きい利益を得る多くのアプリケーションが存在し、顧客は、同じタイプ（例えば、復号化またはフォーマッティング）の複数のサードパーティ・プラグインのチェーン化または順番付けを行うことにより、より複雑なシステム、システム上の挙動をプログラムすることができる。

具体的には、デジタル画像キャプチャおよび処理のシステムにおける複数のサードパーティ・プラグインの順序付けまたはチェーン化を制御（即ち、調整）するコンフィギュレーション・ファイルにおいて「条件付き」プログラミング論理（即ち、条件付きプログラミング論理を含む簡単なスクリプト）を提供することにより、顧客は、デジタル画像キャプチャおよび処理のシステムへ、より複雑なシステム挙動をプログラムすることができる。例えば、復号段階中、複数のプラグインを構成して、それらのプラグインが同時または順次に実行できるようにすることができる。フォーマッティング段階中、１つのプラグインの出力が、次または後のプラグインへの入力を提供することができ、以下同様にこのような構成とすることができる。そのような条件付き論理を、複数のサードパーティ・プラグインに対するコンフィギュレーション・ファイルに提供することにより、サードパーティは、複数のプラグイン間の相互作用（対話）およびコンフィギュレーションを可能にし、強化されたシステムの機能を実現する。

本開示のモジュール式のソフトウェア開発プラットホーム上のプラグイン・コンフィギュレーション・ファイルに対するこのような改善は、個々のサードパーティ・プラグイン・コードが、様々なタイプ入出力関係に従って互いに作用して通信し、それによりイメージャの機能を強化する。例示的な実施形態では、この技法を使用するとき、同じタイプ（例えば、復号化またはフォーマッティング）の複数（例えば、最高で１０個）のアプリケーション・プラグインを共にチェーン化、順番付け、または順序付けして、プラグインが個々に提供できる機能よりも多くの機能を提供することができる。また、そのようなプラグインは、本明細書に述べたように、容易にインストール、削除、順番付け、およびイネーブル／ディスエーブルすることができる。

例示として、３つの独立したプラグイン（例えば、運転免許証解析プラグイン、搭乗券解析プラグイン、およびＴＳＡセキュリティ・プラグイン）がメモリへロードされ、次いで、様々に相互作用（対話）するように構成される（コンフィギュレーション・ファイルによる）場合を考慮する。これらの３つのプラグインの相互作用を制御するコンフィギュレーション・ファイルは、例えば、次のような１または複数の「ＩＦ［］，ＴＨＥＮ［
］」文を有し得る「条件付き」プログラミング論理を含む。

（ａ）ＩＦ（もし）運転免許証の解析に成功したら、搭乗券に対する処理をスキップする。
ＴＨＥＮ（つぎに）ＴＳＡセキュリティ・プラグインが、ホスト出力なしで、姓および名前をメモリ・バンクに記憶する。
（ｂ）ＩＦ（もし）運転免許証の解析に失敗したら、ＴＨＥＮ（つぎに）搭乗券に対して処理を継続する。
ＴＨＥＮ（つぎに）ＴＳＡセキュリティ・プラグインが、ホスト出力なしで、搭乗券から姓および名前をメモリ・バンクに記憶する。
（ｃ）ＴＳＡセキュリティ・プラグインのメモリ・バンクがどちらも一杯であるとき、名前を比較する。
ＩＦ（もし）一致したならば、ＴＨＥＮ（つぎに）Ｂｅｅｐ音（ビーという音）音を作動させて緑色ＬＥＤをフラッシュさせる。
ＩＦ（もし）一致しないならば、ＴＨＥＮ（つぎに）Ｒａｚｚ音（不快な音）を作動させて赤色ＬＥＤをフラッシュさせる。
動作後、メモリ・バンクをクリアにする。

本明細書に述べたように、プラグインの機能は、本開示によるあらゆるデジタル画像キャプチャおよび処理のシステムで多数の機能を可能にすることができ、それらは、例えば、（ｉ）画像からのデータの抽出（バー・コードの読み取り、フォントの認識、マークの認識、パターンの認識、色のマッチングなど）、（ｉｉ）ホスト・システムへ送る前に行う、画像から抽出されたデータの形式の変更、（ｉｉｉ）入ってくる走査されたデータを見て、競合するプログラミング・コマンドに一致する場合に、そのデータをシステムが適切に応答できるようにターゲット・コマンドへと変換させる変換ライブラリを提供することによる、競合するスキャナ・コンフィギュレーションのエミュレーション、（ｉｖ）成功、失敗、またはステップが任意の所与のプラグイン・モジュールによりトリガされることに基づくユーザ応答（例えば、電子音／ＬＥＤ／振動）の変更を含む。

画像キャプチャおよび処理システムでのプラグイン・チェーンの使用は、運転免許証解析、自動車解析、クーポン解析、調剤文書解析などを伴う多くの適用分野を有する。

例示的な実施形態のデジタル画像キャプチャおよび処理のシステムのプラグイン・アーキテクチャを使用する幾つかの主要な利点は、（ｉ）コア動作ファームウェアを変更することなく、ソフトウェア・プログラムを個々に追加／除去することができる能力と、（ｉｉ）独立して開発されたソフトウェア・プログラムが、従うための１組のＡＰＩ／プロトコルを与えられて互いに相互作用することができる能力と、および（ｉｉｉ）製品シリアル番号や製品グループＩＤなどのような一意のデバイス識別子に基づいて、ソフトウェア・プログラムを一意的に作動／ライセンス供与することができる能力とを含む。

［容易に想到される幾つかの変更形態］

ＣＭＯＳ画像感知アレイ技術について、本開示の好ましい実施形態で使用されると説明したが、代替実施形態では、ＣＣＤタイプの画像感知アレイ技術、ならびに他の種類の画像検出技術を使用できることが理解される。

本明細書で詳細に述べたバー・コード・リーダの設計は、例えば、イーサネットＴＣＰ／ＩＰなどのような産業界で一般に使用されるインターフェースを有する産業用または商業用の固定位置バー・コード・リーダ／イメージャで使用するために、容易に適合させることができる。システムにイーサネットＴＣＰ／ＩＰポートを提供することにより、複数の有用な特徴が可能なものとなり、それらは、例えば、インターネットを介したそのようなバー・コード読取システムへのマルチユーザ・アクセス、単一のユーザ・アプリケーションからのネットワーク上の複数のバー・コード読取システムの制御、ライブ動画動作におけるそのようなバー・コード読取システムの効率的な使用、そのようなバー・コード読取システムのウェブ・サービス提供、即ち、インターネット・ブラウザからシステムまたはシステムネットワークを制御することなどである。

本開示の例示的な実施形態について、１Ｄおよび２Ｄバー・コード構造を伴う様々なタ
イプのバー・コード・シンボル読取アプリケーションに関連して説明したが、本開示は、限定されるものではないが、バー・コード・シンボル構造、英数字の文字認識ストリング、手書き、および現在当技術分野で周知の又は将来開発される多様なデータ形式を含めての、任意の機械読取可能な表示や、データ形式や、図形符号化された形の情報を読み取る（即ち、認識する）ために使用できることが理解される。これ以降、「コード・シンボル」という用語は、グラフィック（図形）的に符号化された情報の構造および他の形式を保持するそのようなすべての情報を含むものと見なされるものとする。

また、本開示の撮像ベースのバー・コード・シンボル・リーダはまた、多様なユーザ・アプリケーションにおいて、運転免許証、許可証、クレジット・カード、デビット・カードなどに印刷された写真やマークを含む様々な種類のグラフィック画像を取り込んで処理するために使用することもできる。

例示的な実施形態のバー・コード・シンボル読取システムで用いられる画像キャプチャおよび処理の技術は、本明細書に開示する新規な教示の利益を有する当業者には容易に明らかな様々な方法で変更できることが理解される。本開示の例示的な実施形態のそのようなすべての変更形態および変形形態は、特許請求の範囲により定義する本開示の範囲および精神の範囲内にあると見なされる。

Claims

デジタル画像キャプチャおよび処理のシステムの標準的な特徴および機能を変更および／または拡張する方法であって、
（ａ）１組の標準的な特徴および機能と、演算プラットホームとを有する前記デジタル画像キャプチャおよび処理のシステムを提供するステップであって、前記演算プラットホームは、（ｉ）前記デジタル画像キャプチャおよび処理のシステムの元の設計者により書かれた元の製品コードを記憶するメモリと、（ｉｉ）前記元の製品コードを特定のシーケンスで呼び出して実行することにより１または複数のアプリケーションを動作させるマイクロプロセッサとを含み、それにより、前記デジタル画像キャプチャおよび処理のシステムの標準的な挙動を特徴付ける前記１組の標準的な特徴および機能をサポートするものであり、前記１または複数の元の製品コードは１組のプレース・ホルダを有し、前記１組のプレース・ホルダ内へは、付加価値再販業者（ＶＡＲ）、相手先商標製造業者（ＯＥＭ）、および前記デジタル画像キャプチャおよび処理のシステムのエンドユーザを含むサードパーティが、サードパーティ製品コードを挿入またはプラグインすることができるものである、ステップと、
（ｂ）前記１組のプレース・ホルダへ複数のサードパーティ・コードをプラグインするステップであって、前記デジタル画像キャプチャおよび処理のシステムの前記特徴および機能を変更および／または拡張させるように動作させ、それにより前記デジタル画像キャプチャおよび処理のシステムの前記標準的な挙動を、前記デジタル画像キャプチャおよび処理のシステム向けのカスタム挙動に変更または拡張させるものであり、前記複数のサードパーティ・コードは、前記デジタル画像キャプチャおよび処理のシステムの前記複数のプラグインのチェーン化を制御する条件付きプログラミング論理を有するコンフィギュレーション・ファイルを含むものであり、前記複数のプラグインのチェーン化は前記複数のプラグイン間の相互作用およびコンフィギュレーションを提供する、ステップと
を備える方法。
請求項１に記載の方法であって、前記１または複数の元の製品コードおよび前記サードパーティ製品コードが、１または複数のライブラリで維持される実行可能バイナリ・コードを備え、前記メモリが、それぞれ異なるアクセス速度および性能特性を有する異なる種類のメモリを有するメモリ・アーキテクチャを備える、方法。
請求項１に記載の方法であって、前記ステップ（ｂ）は、付加価値再販業者（ＶＡＲ）や相手先商標製造業者（ＯＥＭ）などのようなエンドユーザまたはサードパーティが、前記元のシステム設計者により設定された仕様に従って前記複数のサードパーティ・コードを書くことを更に含む、方法。
請求項１に記載の方法であって、前記ステップ（ａ）は、前記デジタル画像キャプチャおよび処理のシステムを、サードパーティ製品へ組み込むことまたはサードパーティ製品内へと実施することを更に含み、前記サードパーティ製品は、画像処理ベースのバー・コード・シンボル読取システム、携帯型データ端末（ＰＤＴ）、モバイル電話、コンピュータ・マウス型デバイス、パーソナル・コンピュータ、キーボード、民生用機器、自動車、ＡＴＭ、販売機、回収機、小売用ＰＯＳベースの取引システム、２Ｄまたは２Ｄデジタイザ、ＣＡＴ走査システム、自動車識別システム、包装検査システム、および個人識別システムを含む群から選択されるものである、方法。
請求項１に記載の方法であって、前記ステップ（ｂ）の後に、エンドユーザが前記デジタル画像キャプチャおよび処理のシステムを使用して、デジタル・カメラ・サブシステムで物体の１または複数のデジタル画像を形成および検出することを更に含み、デジタル画像処理サブシステムが、前記１または複数のデジタル画像を処理し、前記１または複数のデジタル画像から、バー・コードの読み取り、フォントの認識、マークの認識、パターンの認識、および／または色のマッチングのためのデータを抽出する、方法。
１組の標準的な特徴および機能と、カスタマイズされたエンドユーザ・アプリケーション要求を満たす１組のカスタムの特徴および機能とを有するデジタル画像キャプチャおよび処理のシステムであって、
視野（ＦＯＶ）を、前記視野内に撮像すべき物体上に投影し、画像キャプチャ・モードにおいて照射動作中に前記物体から反射されて撮像される光を検出するデジタル・カメラ・サブシステムであって、前記画像キャプチャ・モードでは、前記物体の１または複数のデジタル画像が前記デジタル・カメラ・サブシステムにより形成および検出されるものである、デジタル・カメラ・サブシステムと、
前記１または複数のデジタル画像を処理し、生もしくは処理済みのデータを生成するか、または前記１または複数のデジタル画像内にグラフィックで表される情報を認識または取得し、認識された前記情報を表す出力データを生成するデジタル画像処理サブシステムと、
前記出力データを、外部のホスト・システムまたは他の情報受信または応答デバイスへ送る入出力サブシステムと、
前記デジタル・カメラ・サブシステム、前記デジタル画像処理サブシステム及び前記入出力サブシステムの動作を制御および／または調整するシステム制御サブシステムと、
前記デジタル・カメラ・サブシステム、前記デジタル画像処理サブシステム、前記入出力サブシステム及び前記システム制御サブシステムの１または複数のもの、ならびに前記デジタル画像キャプチャおよび処理のシステムの前記特徴および機能の実施をサポートする演算プラットホームと
を備え、
前記演算プラットホームは、（ｉ）前記デジタル画像キャプチャおよび処理のシステムの元の設計者により書かれた複数の元の製品コードを記憶するメモリと、（ｉｉ）前記元の製品コードを特定のシーケンスで呼び出して実行することにより１または複数のアプリケーションを動作させるマイクロプロセッサとを含み、前記デジタル画像キャプチャおよび処理のシステムの標準的な挙動を特徴付ける１組の標準的な特徴および機能をサポートするものであり、
前記複数の元の製品コードは１組のプレース・ホルダを有し、前記プレース・ホルダ内へは、付加価値再販業者（ＶＡＲ）、相手先商標製造業者（ＯＥＭ）、および前記デジタル画像キャプチャおよび処理のシステムのエンドユーザを含むサードパーティが、複数のサードパーティ製品コードを挿入またはプラグインすることができるものであり、
前記１組のプレース・ホルダへプラグインされた複数のサードパーティ製品コードは、前記デジタル画像キャプチャおよび処理のシステムの前記特徴および機能を拡張させ、前記デジタル画像キャプチャおよび処理のシステムの前記標準的な挙動を、前記デジタル画像キャプチャおよび処理のシステム向けのカスタムの挙動へと変更するように動作し、
前記サードパーティにより操作される前記外部のホスト・コンピュータ・システムは、前記入出力サブシステムとインターフェースされて、（ｉ）前記複数のサードパーティ製品コードを前記メモリへロードし、（ｉｉ）前記複数のサードパーティ製品コードを前記１組のプレース・ホルダへプラグインし、前記デジタル画像キャプチャおよび処理のシステムの前記標準的な特徴および機能を永久的に変更することなく、前記デジタル画像キャプチャおよび処理のシステムの前記特徴および機能を拡張し、前記デジタル画像キャプチャおよび処理のシステムの前記標準的な挙動を、前記デジタル画像キャプチャおよび処理のシステム向けの前記カスタムの挙動へと変更するようにされ、
前記複数のサードパーティ製品コードは、前記デジタル画像キャプチャおよび処理のシステムにおけるＡＰＩプロトコルの組を介した前記複数のプラグインのチェーン化を制御する条件付きプログラミング論理を有するコンフィギュレーション・ファイルを含むものであり、前記複数のプラグインのチェーン化は前記複数のプラグイン間の相互作用およびコンフィギュレーションを提供する、
デジタル画像キャプチャおよび処理のシステム。
請求項６に記載のデジタル画像キャプチャおよび処理のシステムであって、光透過窓を有する筐体を備え、前記視野（ＦＯＶ）が、前記視野内に撮像すべき物体上へ前記光透過窓を通って投影され、前記筐体が前記デジタル・カメラ・サブシステム、前記デジタル画像処理サブシステム及び前記入出力サブシステムを内蔵する、デジタル画像キャプチャおよび処理のシステム。
請求項６に記載のデジタル画像キャプチャおよび処理のシステムであって、前記複数の元の製品コードおよび前記サードパーティ製品コードがそれぞれ、１または複数のライブラリで維持される実行可能バイナリ・コードを備える、デジタル画像キャプチャおよび処理のシステム。
請求項６に記載のデジタル画像キャプチャおよび処理のシステムであって、付加価値再販業者（ＶＡＲ）や相手先商標製造業者（ＯＥＭ）などのエンドユーザが、前記元のシステム設計者により設定された仕様に従って前記１または複数のサードパーティ製品コードを書くことができる、デジタル画像キャプチャおよび処理のシステム。
請求項６に記載のデジタル画像キャプチャおよび処理のシステムであって、サードパーティ製品内へ組み込まれる又は前記サードパーティ製品へと実施されるものであり、前記サードパーティ製品は、画像処理ベースのバー・コード・シンボル読取システム、携帯型データ端末（ＰＤＴ）、モバイル電話、コンピュータ・マウス型デバイス、パーソナル・コンピュータ、キーボード、民生用機器、自動車、ＡＴＭ、販売機、回収機、小売用ＰＯＳベースの取引システム、１Ｄまたは２Ｄデジタイザ、ＣＡＴ走査システム、自動車識別システム、包装検査システム、および個人識別システムを含む群から選択されるものであり、前記デジタル画像処理サブシステムは、２Ｄデジタル画像を処理し、前記２Ｄデジタル画像から、バー・コードの読み取り、フォントの認識、マークの認識、パターンの認識、および／または色のマッチングのためのデータを抽出する、デジタル画像キャプチャおよび処理のシステム。