(57)【要約】【課題】  アプリケーションプログラムでは、ＡＰＩを実行する前に、プリンタコントローラの機種ごとに利用可能かどうかを知ることができ、ＡＰＩの利用状況に応じた実装を可能とする。【解決手段】  アプリケーションプログラムに対して提供するＡＰＩについては、装着されるプリンタコントローラの機種によって利用可能かどうかをあらかじめ知る手段を提供する。【選択図】  図２
2008130016.tif 000002
【特許請求の範囲】
【請求項１】
印刷装置本体に装着可能な、前記印刷装置と別個のCPUを備えるネットワークカードにあって、
クライアントから前記ネットワークカードに具備している仮想マシン上で動作可能なアプリケーションプログラムを前記ネットワークカードに追加可能とする手段と、
印刷装置の制御およびクライアントとの通信制御を行なうアプリケーションプログラムが動作可能な仮想マシンと、
アプリケーションプログラムから利用可能なアプリケーションプログラムインタフェース(API)を実行したときに、ネットワークカードが装着される印刷装置に応じて機種を判断し、機種に応じた処理を行う機種差分吸収手段と、
機種差分吸収手段によって取得した情報を、アプリケーションプログラムインタフェース(API)に応じた情報に変更する情報変更手段と、
さらに、各前記APIが、機種別に利用可能状態かどうか判断する利用可否判断手段と、
前記利用可否判断手段にて利用可能かどうかの判断の結果をアプリケーションプログラムに対して通知する利用可否通知手段と
を備えることを特徴とするネットワークカード。
【請求項２】
前記請求項１に記載のネットワークカードにおいて、アプリケーションプログラムがアプリケーションプログラムインタフェース(API)の利用可否を知るために、APIに対応したIDを指定した利用可否判断用APIを備える
ことを特徴とするネットワークカード。
【請求項３】
前記請求項１に記載のネットワークカードにおいて、アプリケーションプログラムがアプリケーションプログラムインタフェース(API)の利用可否を知るために、各APIに対応した利用可否判断APIを備える
ことを特徴とするネットワークカード。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、プリンタ装置に装着されるネットワークカードに関するものである。
【背景技術】
【０００２】
近年、インターネットの普及により、印刷装置もネットワークで使われる形態が一般化してきた。通常、高速機やカラー機などの高価格機ではネットワークインターフェイスは内蔵される傾向にあるが、低価格なモノクロ機の場合には、ネットワークインターフェイスは本体には同梱されない。また、ネットワークカードモジュールとして別に供給される形態が一般的である。
【０００３】
この場合、印刷装置本体とネットワークカードモジュールは個々にCPUを持ったインテリジェントな形態である。また、通常ネットワークカードモジュール側にネットワーク経由での各種プリントサービスの統括制御を行なうプリントサーバ機能を備えている。また、印刷装置とネットワークカードモジュールは接続インターフェイスを介して通信を行ない所望のサービスを実装している。
【０００４】
このことは逆に負荷の重いネットワークサービスをネットワークカードモジュールに追い出すことが可能となり、相対的に印刷装置本体のCPUや周辺パフォーマンスを下げることが可能となり、印刷装置本体のコスト削減をもたらしている。
【０００５】
従来のネットワークインターフェイスは例えばLPR(RFC1179)に代表されるような印刷データの送信だけできればよかったが、昨今印刷装置に対する情報管理というニーズが高くなり、付加技術として各種の手段が提供されている。
【０００６】
最も単純な例が、印刷データを送信するポートに情報管理データ（ジョブ制御言語=Job Language）を付加する形態である。ジョブ制御言語は印刷データを送るポートを共有する形であるため、サービスポートを増加せずに済み、比較的実装が簡単である。しかし、印刷データ受信中にデータが大量に送信されるとポートを占有するため、情報管理データのやりとりが止まってしまうという問題がある。またネットワークにおけるLPRプロトコルのような片方向型コネクションの場合、そもそも情報取得ができないという欠点がある。
【０００７】
次の手法としては、SNMP/MIB(RFC1157)を使った方式がある。これはデータ送受信用の専用ポートを使用し、標準規格であるSNMP(Simple Network Management Protocol)を使う方法である。しかしこの方式はSNMPを受信してUIを提供する専用クライアントプログラムの独自開発が必要である。かつこの方式では、そもそも単純な情報のやり取りを行うプロトコルであるため、数字、文字列などの単純なデータベースしか提供できない。その結果、機器の構成を示すビットマップ画像などUIを構成する情報は、前記クライアントプログラムが所有せねばならず、それに伴いクライアントプログラムを機種対応しなくてはいけないという問題点がある。
【０００８】
さらに最近ではHTTPプロトコル(RFC1945,RFC2616)を用いた方式が主流となりつつある。この方式によれば、ネットワークカードモジュールの中にHTTPサービスを提供して、機器情報に関するHTMLデータやビットマップ画像といったWEBコンテンツを提供する。さらにクライアントは一般的なWEBブラウザを使用して前記WEBコンテンツをGUI上に表示し、操作を可能とすれば、クライアントプログラムを提供しなくても同様の効果を得ることが可能である。従来の方式ではクライアントプログラムが多種多様な機器に固有な情報（メッセージ文字列、ビットマップ画像）を管理する必要があっため、機器が自分の機種情報だけ持てばよい上記方式は短期間で製品を提供するためにはもっとも適する方法である。
【０００９】
しかしならが、上記述べたいずれの手段もネットワークカードモジュールに予め組み込まれた静的な機能の提供手段であって、後から機能そのものを追加するあるいは、組み込まれた機能による制御方法を変更するといった動的なサービスの追加ができなかった。
【００１０】
そこで最近になってJava（登録商標）言語を用いて作成されたアプリケーションプログラムモジュールを、組み込み機器上に実装するJava（登録商標）仮想マシン上で動作可能とするプラットフォーム技術が提案されている(Java（登録商標）:米国Sun Microsystems, Inc.の商標)。この技術を用いることで従来印刷装置等の組み込み機器に後から新たな機能を機器に追加することが可能となってきている。
【００１１】
上記述べたJava（登録商標）仮想マシンにはネットワーク通信機能を始め、組み込み機器を制御するために必要な各種機能を提供するためにアプリケーションプログラムインタフェース(API)が備わっておいる。そこで、上記Java（登録商標）言語で作成されたアプリケーションプログラムモジュールはこれらのAPIを呼び出して組み込み機器に対する制御やネットワークで接続されたホストコンピュータからの要求を処理する。
【００１２】
また、従来の技術でも、よりJava（登録商標）アプリケーションを効率的に開発可能にする環境を提供するために、PC上で動作するJava（登録商標）開発環境を提供するものも存在している。（例えば、特許文献１参照。）
【特許文献１】特開2005-038010号公報
【発明の開示】
【発明が解決しようとする課題】
【００１３】
上記Java（登録商標）仮想マシン上で提供されるAPIは、ネットワーク通信に必要な機能を含んでおり、ネットワーク通信プロトコルの処理を行う基本モジュールを共有するため、通常ネットワークカードモジュール上に実装される機能である。
【００１４】
しかしながらそれらのAPIについては、ネットワークカードモジュールが装着される印刷装置本体の機能に依存して、取得可能な情報が異なっていたり、印刷装置本体の機能によっては、情報自体が取得できないものもあった。このためJava（登録商標）言語でアプリケーションプログラムを作成しようとする場合には、装着される印刷装置の機能を意識して作成する必要があり、複数の印刷装置で動作する共通アプリケーションプログラムの開発を妨げていた。
【課題を解決するための手段】
【００１５】
本発明は上記問題点に鑑みてなされたものであり、
印刷装置本体に装着可能な、前記印刷装置と別個のCPUを備えるインテリジェント型ネットワークカードモジュールにあって、
ホストコンピュータ等のクライアントから前記ネットワークカードモジュールに具備しているJava（登録商標）仮想マシン上で動作可能なアプリケーションプログラムモジュールを前記ネットワークカードモジュールに追加可能とする手段を有し、
印刷装置の制御およびホストコンピュータ等のクライアントと通信制御を行なうアプリケーションプログラムが動作可能なJava（登録商標）仮想マシンを備え、
アプリケーションプログラムから利用可能なアプリケーションプログラムインタフェース(API)を実行したときに、ネットワークカードモジュールが装着される印刷装置に応じて機種を判断し、機種に応じた処理を行う機種差分吸収手段と、
機種差分吸収手段によって取得した情報を、アプリケーションプログラムインタフェース(API)に応じた情報に変更する情報変更手段、
さらに、各前記APIが、機種別に利用可能状態かどうか判断する利用可否判断手段と、前記利用可否判断手段にて利用可能かどうかの判断の結果をアプリケーションプログラムに対して通知する利用可否通知手段とから構成される。
【００１６】
さらに、前記ネットワークカードモジュールにあって、アプリケーションプログラムがアプリケーションプログラムインタフェース(API)の利用可否を知るために、APIに対応したIDを指定した利用可否判断用API手段とから構成される。
【００１７】
さらに、前記ネットワークカードモジュールにあって、アプリケーションプログラムがアプリケーションプログラムインタフェース(API)の利用可否を知るために、各APIに対応した利用可否判断API手段とから構成される。
【００１８】
さらに、前記ネットワークカードモジュールにあって、
電源投入時に、印刷装置本体の機種を特定する手段、とから構成される。
【００１９】
さらに、前記ネットワークカードモジュールにあって、
印刷装置本体の機種が未知のものであった場合に、未知な機種と特定された場合の処理を行う機種差分吸収手段、とから構成される。
【発明の効果】
【００２０】
本発明により、アプリケーションプログラムに対して提供するＡＰＩについては、装着されるプリンタコントローラの機種によって利用可能かどうかをあらかじめ知る手段を提供する。このことによりアプリケーションプログラムでは、ＡＰＩを実行する前に、プリンタコントローラの機種ごとに利用可能かどうかを知ることができ、ＡＰＩの利用状況に応じた実装を可能とする。
【発明を実施するための最良の形態】
【００２１】
（実施例１）
図１は、本発明の実施形態に関わる印刷システムのハードウェア構成を説明するブロック図である。1000はプリンタで、内部で大きくネットワークプリンタサーバ1500とプリンタコントローラ1600からなる異なる制御系を司る機器で構成されている。ネットワークプリントサーバ1500において、１はネットワークプリントサーバ用CPUである。ネットワークプリントサーバ用CPUは、書き換え可能なFlashROM３に記憶された制御プログラムに基づいて動作する。また、システムバス４に接続されるネットワークコントローラ(LANC5)を介してローカルエリアネットワーク(LAN2000)に接続されたホストコンピュータ等の複数の外部装置(不図示)と通信を行う。通信には、所定のネットワーク通信プロトコルを用いて、前記外部装置から送られる印刷データやプリンタ制御命令等の各種データ送受信要求を統括的に制御する。そして拡張インタフェースコントローラ(EXPC7)を介して接続されるプリンタコントローラ1501に対して適切なデータ転送制御を行なう。
【００２２】
RAM2はCPU1の主メモリ、ワークエリア等の一時記憶領域をして用いられる。
【００２３】
LED6はネットワークプリントサーバの動作状態を示す表示部として用いられている。例えば、ネットワークコントローラ(LANC5)とローカルエリアネットワーク(LAN2000)の電気的な接続状態(LINK)を表示する。あるいは、ネットワーク通信モード(10Baseや100Base、全二重、半二重)等の各種動作状態をLEDの点滅パターンや色で示すこと可能となっている。
【００２４】
さらにネットワークプリントサーバ1500とプリンタコントローラ1501を繋ぐ拡張インタフェース17は、図示しないコネクタで構成されている。そのため、ネットワークプリントサーバ1500のみが着脱し、同じ構成を持つ別のプリンタ1000にネットワークプリントサーバ1500を装着することも可能な構成となっている。
【００２５】
プリンタコントローラ1600において、８はプリンタコントローラ用CPUである。プリンタコントローラ用CPUは、ROM9に記憶された制御プログラム等あるいはディスクコントローラ(DKC15)を介して接続された外部メモリ１０に記憶された制御プログラムやリソースデータ(資源情報)等に基づいて動作する。また、システムバス１１に接続される各種デバイスとのアクセスを統括的に制御する。さらに、拡張インタフェースコントローラ(EXPC13)を介して接続されるネットワークプリントサーバ1500から受信される印刷データを基にラスタコントローラ１２によって出力画像情報を生成し、プリントエンジン１６に対して画像信号を出力する。
【００２６】
１４はCPU8の主メモリ、ワークエリア等として機能するRAMで、図示しない増設ポートに接続されるオプションRAMによりメモリ容量を拡張することができるように構成されている。
【００２７】
１８は操作パネル（操作部）でプリンタ１０００の動作モード等の設定や印刷データの取り消し等の操作を行なうためのボタンおよびプリンタ１０００の動作状態を示す液晶パネルやLED等の表示部が配されている。
【００２８】
なお、本図で示したプリンタエンジン１６は既知の印刷技術を利用するものであり、好適な実施系として例えば電子写真方式(レーザービーム方式)やインクジェット方式、昇華方(熱転写)方式等が挙げられる。
【００２９】
図２は、本発明の実施形態に好適な印刷システムにおけるプリンタ１０００内の制御機器であるネットワークプリントサーバ1500/プリンタコントローラ1600の各記憶デバイスに記憶された制御プログラム内のソフトウェア構成を説明するブロック図である。
【００３０】
なお上記各制御プログラムは各制御機器のCPUによってプログラムが解析され処理される。
【００３１】
1501はネットワークプリントサーバ1500の基本的なデータの入出力制御を統括するオペレーティングシステムである。さらに前記オペレーティングシステム1501内では、ファイルシステム1505、拡張インタフェースドライバ1506、およびネットワークインタフェースドライバ1507を内包する。
【００３２】
ファイルシステム1505では、プログラム/データ記憶部９との入出力制御を行なう。拡張インタフェースドライバ1506では、プリンタコントローラ1600と拡張インタフェース１７を介して通信制御を行なう。ネットワークインタフェースドライバ1507では、ローカルエリアネットワーク(LAN2000)の通信媒体を介して不図示のホストコンピュータ等の外部装置と通信を行なう。
【００３３】
1502はアプリケーションプログラムインタフェース(API)である。APIでは、ネットワークプリントサーバ1500で動作するユーザアプリケーション1503を提供する。さらに、プリンタ１０００やユーザアプリケーションの登録・管理を行う管理アプリケーション等のアプリケーションプログラムに対して前記オペレーティングシステムが備える各種機能を提供する。
【００３４】
また前記アプリケーションプログラムインタフェース1502で提供される機能は、以下のAPIを備える。
【００３５】
印刷データの送受信機能を提供するデータ転送API、ビットマップ画像や表示メッセージ等のリソースデータの入出力制御を行なうリソース制御API。
【００３６】
プリンタ1000の再起動や設定値の初期化や設定等の制御を行なうプリンタ制御API。印刷ジョブの取り消しや再印刷指示などを制御するジョブ制御API。ネットワークプリントサーバ1500の再起動や設定値の初期化や設定、およびアプリケーションプログラムの起動、登録、削除を行なうプリントサーバ制御API。ハードディスクドライブへの書き込み・読み出しなどを制御するハードディスク制御API、前記印刷装置の操作パネルの表示の切り替えなどを制御するパネルAPIなどである。これらのAPIは、ネットワークプリントサーバ1500と接続されるプリンタコントローラ1600の機能に応じて、取得可否や取得可能な情報の内容が異なるものも含んでいる。
【００３７】
また、1512は、上記各種APIの上位に位置する機種差分API吸収層であり、ネットワークプリントサーバ1500と接続されるプリンタコントローラ1600の機能差分によって生じる各種APIの機能差を吸収するためのミドルウェア層である。
【００３８】
1601はプリンタコントローラ1600の各種処理制御を統括するオペレーティングシステムである。そこでは内部にプリントエンジンとの通信制御を行なうプリントエンジン制御部1603およびネットワークプリントサーバ1500から参照されるビットマップ画像やエラーメッセージ等の機種依存リソースを内包している。さらにネットワークプリントサーバ上で動作する機種依存アプリケーションプログラム等を記憶する機種依存リソース/プログラム記憶部との入出力制御を行なうファイルシステム1604を内包している。
【００３９】
1602は拡張インタフェース制御部であり、拡張インタフェース１７を介してネットワークプリントサーバ1500との通信制御を行なう。さらに前記拡張インタフェース制御部は、制御種別毎に印刷データの入出力を制御するデータ転送論理インタフェースを備える。さらに機種依存リソース/プログラム記憶部９に記憶された各種データの入出力を制御するリソース制御論理インタフェース、プリンタ1000の再起動や設定値の初期化や設定等の制御を行なうプリンタ制御論理インタフェースを備える。また、印刷ジョブの取り消しや再印刷指示などを制御するジョブ制御論理インタフェースを備えている。さらに、各論理インタフェースを介してネットワークプリントサーバ1500から要求された命令をオペレーティングシステム1601に対して転送し、その処理結果をネットワークプリントサーバ1500に対して返信する。
【００４０】
図３は、ネットワークプリントサーバ1500で動作するアプリケーションプログラムの記述例であり、本発明の好適な一例としてJava（登録商標）言語による記述例を示している。図３の301に示される行は図２で説明したデータ転送APIを呼び出す例である。図中では、"printer.outdata("Test")"がデータ転送APIでここでは"Test"というテキストデータを印字データとしてプリンタコントローラを介してプリントエンジンから印刷せよという命令である。処理結果は"result"に数値型として格納される。
【００４１】
図３の302に示される行は前記301の行で指示された処理結果を出力する標準出力先を示す。例えば、プリンタ１０００の操作パネル17のLCD表示部やアプリケーションを呼び出し元であるホストコンピュータのブラウザ表示部にテキストメッセージ変換して表示する命令の記述例である。
【００４２】
図４は、本発明に係る印刷装置毎のＡＰＩの利用可否状態を静的に記憶しておく記憶テーブルの例である。４−ａでは、ＤｅｖｉｃｅＡのＡＰＩ利用可否を表しており、ＡＰＩaとｄに関しては利用可能であるが、ｂとｃに関しては不可であることを表している。同様に４−ｂでは、ＤｅｖｉｃｅＢにおいて、ＡＰＩaとｂが利用可能であることを表している。
【００４３】
図５は、本発明に係る、ユーザアプリケーションが、ＡＰＩ利用可否判断用のＡＰＩを利用し、利用可否を判断したいＡＰＩのＩＤを指定してＡＰＩを実行したときのフロー図である。
【００４４】
Ｓ５０１において、アプリケーションが利用可否を判断するＡＰＩに、利用可否を判断したいＡＰＩのＩＤを指定して、ＡＰＩを実行する。ＡＰＩが実行されると、Ｓ５０２において機種差分ＡＰＩ吸収層がプリンタコントローラ１５０１の機種を特定し、Ｓ５０３に進む。Ｓ５０３では、プリンタ毎のＡＰＩの利用可否を判断する静的テーブルから利用可否を判断しＳ５０４に進む。Ｓ５０４で、利用可能であると判断された場合には、Ｓ５０５に進み、アプリケーションに対して利用可能であることを通知して処理を終了する。Ｓ５０４で利用不可と判断された場合には、Ｓ５０６に進み、アプリケーションに対して利用不可であることを通知して処理を終了する。
【００４５】
（実施例２）
図６は、本発明に係る、ユーザアプリケーションが、ＡＰＩ利用可否判断用のＡＰＩを利用し、利用可否を判断したいＡＰＩのＩＤを指定してＡＰＩを実行したときのフロー図である。
【００４６】
実施例２では、実施例１とは異なり、利用可否を判断するための静的テーブルを保持するのではなく、ユーザアプリケーションから、ＡＰＩ利用可否判断用のＡＰＩを実行された時点で、そのＡＰＩが利用可能かをプリンタコントローラに問い合わせを行う。
【００４７】
そしてその結果から利用可否の結果をアプリケーションに通知する方式である。これは、オプション装置を装着することによって提供される機能（ファクスやハードディスクなど）が、装着されているかどうかを判断する場合などには、実施例２のような構成となる。
【００４８】
Ｓ６０１において、アプリケーションが利用可否を判断するＡＰＩに、利用可否を判断したいＡＰＩのＩＤを指定して、ＡＰＩを実行する。ＡＰＩが実行されると、Ｓ６０２において機種差分ＡＰＩ吸収層がプリンタコントローラ１５０１の機種を特定し、Ｓ６０３に進む。Ｓ６０３では、プリンタ毎のＡＰＩの利用可否を判断するためにプリンタコントローラ１５０１に問い合わせを行い利用可否を判断する。Ｓ６０４で、利用可能であると判断された場合には、Ｓ６０５に進み、アプリケーションに対して利用可能であることを通知して処理を終了する。Ｓ６０４で利用不可と判断された場合には、Ｓ６０６に進み、アプリケーションに対して利用不可であることを通知して処理を終了する。
【００４９】
（実施例３）
実施例１の実施例では、利用可否を判断するために、静的テーブルを保持し、実施例２では、動的に利用可否を判断するためにプリンタコントローラに問い合わせを実行している。実施例３では、この組み合わせによって、静的テーブルを利用しながら、動的に判断すべきＡＰＩに関しては動的に問い合わせを行う例を示す。
【００５０】
図７は、本発明に係る印刷装置毎のＡＰＩの利用可否状態を記憶しておく記憶テーブルの例である。７−ａでは、ＤｅｖｉｃｅＡのＡＰＩ利用可否を表しており、ＡＰＩaとｄに関しては利用可能であるが、ｂに関しては不可であり、ｃに関しては動的に問い合わせを行なうことを表している。同様に７−ｂでは、ＤｅｖｉｃｅＢにおいて、ＡＰＩaとｂが利用可能であることを表している。
【００５１】
図８は、本発明に係る、ユーザアプリケーションが、ＡＰＩ利用可否判断用のＡＰＩを利用し、利用可否を判断したいＡＰＩのＩＤを指定してＡＰＩを実行したときのフロー図である。
【００５２】
実施例３では、実施例１、２とは異なり、利用可否を判断するための静的テーブルを保持するものと、ユーザアプリケーションから、ＡＰＩ利用可否判断用のＡＰＩを実行された時点で、そのＡＰＩが利用可能かをプリンタコントローラに問い合わせを行う。そして、その結果から利用可否の結果をアプリケーションに通知する方式の両方を備えている。
【００５３】
これは、静的に利用可否が固定になるものと、オプション装置などを装着することによって提供される機能（ファクスやハードディスクなど）などが混在する場合には、実施例３のような構成となる。
【００５４】
Ｓ８０１において、アプリケーションが利用可否を判断するＡＰＩに、利用可否を判断したいＡＰＩのＩＤを指定して、ＡＰＩを実行する。ＡＰＩが実行されると、Ｓ８０２において機種差分ＡＰＩ吸収層がプリンタコントローラ１５０１の機種を特定し、Ｓ８０３に進む。Ｓ８０３では、プリンタ毎の性的テーブルから指定されたＩＤの利用可否状況を参照し、Ｓ８０４に進む。Ｓ８０４では、静的テーブルから静的に判断可能かを判断し、静的に判断可能な場合はＳ８０６に進む。Ｓ８０５において、静的テーブルから利用可のと判断された場合には、Ｓ８０６に進み、アプリケーションに対して利用可能であることを通知して処理を終了する。Ｓ８０５で利用不可と判断された場合には、Ｓ８０７に進み、アプリケーションに対して利用不可であることを通知して処理を終了する。また、Ｓ８０４で静的に判断できないと判断された場合には、Ｓ８０８に進む。Ｓ８０８では、プリンタ毎のＡＰＩの利用可否を判断するためにプリンタコントローラ１５０１に問い合わせを行い利用可否を判断する。Ｓ８０９で、利用可能であると判断された場合には、Ｓ８１０に進み、アプリケーションに対して利用可能であることを通知して処理を終了する。Ｓ８０９で利用不可と判断された場合には、Ｓ８１１において、アプリケーションに対して利用不可であることを通知して処理を終了する。
【００５５】
（実施例４）
実施例１から３では、アプリケーションがＡＰＩの利用可否を知るためには、ＩＤを指定した利用可否判断用のＡＰＩを実行する例を示したが、実施形態はそれに縛られるものではない。実施例４では、アプリケーションがＡＰＩの利用可否を知るために、そのＡＰＩに１対１に対応した利用可否確認ＡＰＩを用意するものである。
【００５６】
図９は、利用可否確認ＡＰＩの実施例である。getDeviceName()の利用可否を確認する場合には、対で用意されている、isAvailable_getDeviceName()を実行することにより、利用可否の判断を行うことが可能となる。isAvailable_getDeviceName()は、利用可能な場合にはtrue、利用不可の場合はfalseを返すことにより、アプリケーションは利用可否を知ることが可能となる。
【図面の簡単な説明】
【００５７】
【図１】本発明の実施形態に関わる印刷システムのハードウェア構成ブロック図。
【図２】本発明の実施形態に関わる印刷システムソフトウェア構成ブロック図。
【図３】本発明におけるアプリケーションプログラムのソースコード記述例。
【図４】本発明に係る印刷装置毎のＡＰＩの利用可否状態を静的に記憶しておく記憶テーブル。
【図５】本発明に係る、ユーザアプリケーションが、ＡＰＩ利用可否判断用のＡＰＩを利用し、利用可否を判断したいＡＰＩのＩＤを指定してＡＰＩを実行したときのフロー図。
【図６】本発明に係る、ユーザアプリケーションが、ＡＰＩ利用可否判断用のＡＰＩを利用し、利用可否を判断したいＡＰＩのＩＤを指定してＡＰＩを実行したときのフロー図。
【図７】本発明に係る印刷装置毎のＡＰＩの利用可否状態を記憶しておく記憶テーブル。
【図８】本発明に係る、ユーザアプリケーションが、ＡＰＩ利用可否判断用のＡＰＩを利用し、利用可否を判断したいＡＰＩのＩＤを指定してＡＰＩを実行したときのフロー図。
【図９】利用可否確認ＡＰＩ例。
【符号の説明】
【００５８】
１０００  プリンタ
１５００  ネットワークプリントサーバ
１６００  プリンタコントローラ
２０００  ローカルエリアネットワーク
１  CPU
２  RAM
３  フラッシュROM
４  システムバス
５  LANコントローラ
６  LED
７  拡張インタフェースコントローラ
８  CPU
９  ROM
１０  外部メモリ
１１  システムバス
１２  ラスタコントローラ
１３  拡張インタフェースコントローラ
１４  RAM
１５  ディスクコントローラ
１６  プリントエンジン
１７  拡張インタフェースバス
１８  操作パネル
【図１】
2008130016.tif 000003
【図２】
2008130016.tif 000004
【図３】
2008130016.tif 000005
【図４】
2008130016.tif 000006
【図５】
2008130016.tif 000007
【図６】
2008130016.tif 000008
【図７】
2008130016.tif 000009
【図８】
2008130016.tif 000010
【図９】
2008130016.tif 000011