以下、添付の図面を参照して本発明の好適な実施形態を説明する。
<第1実施形態>
図1は、第1実施形態に関わる印刷システムのハードウェア構成を説明するブロック図である。1000はプリンタであり、大きくはネットワークプリントサーバ1500とプリンタコントローラ1600からなり、それぞれ独立した制御系を有する。
ネットワークプリントサーバ1500は、ネットワークボードモジュールの形態で実現されたプリンタ1000に対して着脱可能なネットワーク装置である。ネットワークプリントサーバ1500において、1はネットワークプリントサーバ用CPUであり、書き換え可能なFlashROM3に記憶された制御プログラムに基づいて各種制御を実行する。例えば、システムバス4に接続されるネットワークコントローラ(LANC5)を介してローカルエリアネットワーク(LAN2000)に接続されたホストコンピュータ等の外部装置(不図示)と所定のネットワーク通信プロトコルを用いて通信する。これにより、例えば、外部装置から送られる印刷データやプリンタ制御命令等の各種データの送受信を統括的に制御し、拡張インタフェースコントローラ(EXPC7)を介して接続されるプリンタコントローラ1501に対して適切なデータ転送制御を行なう。またFlashROM3には、図4,5,6のフローチャートで示されるようなCPU1によって実行される制御プログラムも記憶されている。
RAM2はCPU1の主メモリ、ワークエリア等の一時記憶領域として用いられる。LED6はネットワークプリントサーバの動作状態を示す表示部として用いられており、例えばネットワークコントローラ(LANC5)とローカルエリアネットワーク(LAN2000)の電気的な接続状態(LINK)や、ネットワーク通信モード(10Baseや100Base、全二重、半二重)等の各種動作状態をLEDの点滅パターンや色で示すことが可能となっている。
拡張インタフェース17は、ネットワークプリントサーバ1500とプリンタコントローラ1600を接続するためのインタフェースであり、図示しないコネクタを含んで構成されている。ネットワークプリントサーバ1500は、このコネクタによってプリンタ1000(プリンタコントローラ1600)との着脱が可能となっており、同じ構成を持つ別のプリンタに当該ネットワークプリントサーバ1500を装着することも可能である。
外部周辺装置インターフェースコントローラ(EXIOC20)は、ネットワークプリントサーバ1500上に実装された外部周辺装置インタフェースであり、後述するプリンタ1000が接続される拡張インタフェースコントローラ7および拡張インタフェース17とは異なるものである。本実施形態において、外部周辺装置インタフェースの形式は特に言及しないが、例としてUSBインタフェースやIEEE1394インタフェースを挙げることができる。この外部周辺装置インタフェースを介して接続された外部周辺装置22と通信を行うことが可能であり、さらに外部周辺装置22をネットワークプリントサーバ1500側から制御することが可能である。
一方、プリンタコントローラ1600において、8はプリンタコントローラ用CPUであり、システムバス11に接続される各種デバイスとのアクセスを統括的に制御する。また、CPU8の制御の下、ラスタコントローラ12は、ネットワークプリントサーバ1500から拡張インタフェースコントローラ(EXPC13)を介して受信される印刷データに基づいて出力画像信号を生成し、プリントエンジン16に対して画像信号を出力する。以上のような処理は、ROM9に記憶された制御プログラム等、或いはディスクコントローラ(DKC15)を介して接続された外部メモリ10に記憶されている制御プログラムやリソースデータ(資源情報)等に基づいてCPU8が動作することにより実現される。
14はCPU8の主メモリ、ワークエリア等として機能するRAMであり、図示しない増設ポートに接続されるオプションRAMによりメモリ容量を拡張することができるように構成されている。18は操作パネルであり、プリンタ1000の動作モード等の設定や印刷データの取り消し等の操作を行なうためのボタンと、プリンタ1000の動作状態を示す液晶パネルやLED等の表示部等が配されている。なお、本図で示したプリンタエンジン16は既知の印刷技術を利用するものであり、好適な実施系として例えば電子写真方式(レーザービーム方式)やインクジェット方式、昇華方(熱転写)方式等が挙げられる。
図2は、図1に示したネットワークプリントサーバ1500およびプリンタコントローラ1600の各記憶部(例えば、FlashROM3、ROM9)に記憶された制御プログラムのソフトウェア構成を説明するブロック図である。なお、これらの制御プログラムはCPU1、8によって解析され実行される。
ネットワークプリントサーバ1500側において、1501はオペレーティングシステムであり、ネットワークプリントサーバ1500の基本的なデータ入出力制御を統括する。オペレーティングシステム1501は、プログラム/データ記憶部1509との入出力制御を行なうファイルシステム1505と、プリンタコントローラ1600と拡張インタフェース17を介して通信制御を行なう拡張インタフェースドライバ1506と、ローカルエリアネットワーク(LAN2000)の通信媒体を介してホストコンピュータ等の外部装置(不図示)と通信を行なうネットワークインタフェースドライバ1507と、外部周辺装置と外部周辺装置インタフェース(EXIO21)を介して通信制御を行う外部周辺装置インタフェースドライバ1510とを内包している。なお、プログラムデータ記憶部1509は、例えばFlashROM3により構成される。
1502はアプリケーションプログラムインタフェース(API)である。API1502は、ネットワークプリントサーバ1500で動作するユーザアプリケーション1503や管理アプリケーション1504等のアプリケーションプログラムに対してオペレーティングシステム1501が備える各種機能を提供する。なお、管理アプリケーション1504は、プリンタ1000やユーザアプリケーションの登録・管理を行うアプリケーションである。またAPI1502は、印刷データの送受信機能を提供するデータ転送API、ビットマップ画像や表示メッセージ及びアプリケーションプログラム等のリソースデータの入出力制御を行なうリソース制御API、プリンタ1000の再起動や設定値の初期化や設定等の制御を行なうプリンタ制御API、印刷ジョブの取り消しや再印刷指示などを制御するジョブ制御API、ネットワークプリントサーバ1500の再起動や設定値の初期化や設定、およびアプリケーションプログラムの起動、登録、削除を行なうプリントサーバ制御API等を備える。また、データ転送API、リソース制御API、プリンタ制御API、ジョブ制御APIによって提供される命令はプリンタコントローラ依存命令として図7で示されるような命令書式に変換した後、拡張インタフェース17を介してプリンタコントローラに転送される。
プリンタコントローラ1600側において、1601はプリンタコントローラ1600の各種処理制御を統括するオペレーティングシステムであり、プリントエンジン制御部1603及びファイルシステム1604を有する。プリントエンジン制御部1603は、プリントエンジンとの通信制御を行なう。ファイルシステム1604は機種依存リソース/プログラム記憶部1610との入出力制御を行なう。機種依存リソース/プログラム記憶部1610は、ネットワークプリントサーバ1500から参照されるビットマップ画像やエラーメッセージ等の機種依存リソース、及びネットワークプリントサーバ1500上で動作する機種依存アプリケーションプログラム等を記憶する。
1602は拡張インタフェース制御部であり、拡張インタフェース17を介してネットワークプリントサーバ1500との通信制御を行なう。拡張インタフェース制御部1602は、制御種別に応じた論理インターフェースを備える。例えば、印刷データの入出力を制御するデータ転送論理インタフェース、機種依存リソース/プログラム記憶部1610に記憶された各種データの入出力を制御するリソース制御論理インタフェース、プリンタ1000の再起動や設定値の初期化や設定等の制御を行なうプリンタ制御論理インタフェース、印刷ジョブの取り消しや再印刷指示などを制御するジョブ制御論理インタフェースを備える。各論理インタフェースは、ネットワークプリントサーバ1500から要求された命令をオペレーティングシステム1601に転送し、その処理結果をネットワークプリントサーバ1500に対して返信する。
図3は、ネットワークプリントサーバ1500で動作するアプリケーションプログラムの記述例であり、本実施形態の好適な一例としてJava言語による記述例を示している。図3の301に示される行は図2で説明したデータ転送APIを呼び出す例であり、“printer.outdata(“Test”)”がデータ転送APIである。これは“Test”というテキストデータを印字データとしてプリンタコントローラを介してプリントエンジンから印刷せよというプリンタコントローラ依存命令である。プリンタコントローラ1600にて当該命令に従って処理が実行されると、コントローラから受信した処理結果が変数“result”に数値型として変換されて格納される。
図3の302に示される行は301の行で指示された処理結果を標準出力先(例えばプリンタ1000の操作パネル18のLCD表示部やアプリケーションの呼び出し元であるホストコンピュータのブラウザ表示部)にテキストメッセージ変換して表示する命令の記述例である。
図4は、第1実施形態に係るネットワークプリントサーバ1500上で動作するアプリケーションプログラムの起動処理方法を示すフローチャートである。本処理は管理アプリケーション1504に含まれる。なお、S401〜S411及びS420〜S424は各処理ステップを示し、ローカルエリアネットワーク(LAN2000)に接続されたホストコンピュータ等の外部装置から本プリンタ1000に対してアプリケーションの起動要求を受信した場合の処理の流れに対応する。なお各ステップに対応する制御手順はネットワークプリントサーバ1500のFlashROM3に記憶されている。
なお、以下の動作例では、アプリケーションの実行時に、カラーパラメータに従ってアプリケーションプログラムの取得処理動作の切り替えを行う。まず、ステップS420において、ネットワークプリントサーバ1500であるところのネットワークカードモジュールが、接続されたプリンタ1000の機能能力情報を獲得する。そしてステップS421において、ステップS420で獲得した機能能力情報を後にアプリケーションプログラムから参照可能とするようにメモリに保存する。
ステップS401において、LAN2000を介して不図示のホストコンピュータ等の外部装置からアプリケーション起動要求命令を受信する。本実施形態において、アプリケーション起動要求命令は、URL(Uniform Resource Locator)などのアプリケーションを識別するための識別情報により起動すべきアプリケーションプログラムを特定する。ステップS402ではステップS401で受信したアプリケーション起動要求命令からアプリケーションを特定するURLを取得する。ステップS403では、取得したURLから、起動要求されているアプリケーションの当該プリンタ1000内における格納先情報を抽出する。例えば指定されたアプリケーションのURLが、
HTTP://192.168.0.215/abc/xyz.Java
の場合は、HTTP://はスキームであり、192.168.0.215 は本プリンタ装置自身のネットワークアドレスを示すものであるため、格納先情報として抽出される情報は、“/abc/xyx.Java” となる。
本実施形態では、格納先情報の文字列から、当該アプリケーションがプリントサーバ1500内の記憶部(例えばFlashROM3)に格納されているか、プリンタコントローラ1600内の記憶部(例えばROM9)に格納されているかを判定する。本実施形態では、“/dev/”で始まる格納先はプリンタコントローラ側であるとする。
よって、ステップS404では、ステップS403で抽出した格納先情報の文字列が“/dev/”で始まっているか否かを判定する。格納先情報の文字列が“/dev/”で始まっていない場合、起動すべきアプリケーションはネットワークプリントサーバ1600内にあると判断され、処理はステップS408へ進む。ステップS408では、ネットワークプリントサーバ1500内の記憶部に該当するアプリケーションプログラムが存在するか判定する。該当するアプリケーションプログラムが存在する場合にはステップS409へ進み、要求されたアプリケーションプログラムをネットワークプリントサーバ1500のRAM14にロードする。そしてステップS410へ進み、当該アプリケーションプログラムを起動して本処理を終了する。なお、ステップS408で該当するアプリケーションが存在しない場合は、ステップS411へ進み、要求元にエラーを通知して本処理を終了する。
一方、ステップS404で格納先情報の文字列が“/dev/”で始まっている場合には、起動要求されたアプリケーションの格納先がプリンタコントローラ1600であると判断し、ステップS422へ進む。ステップS422でプリンタ1000の機能能力情報を参照し、ステップS423で、当該機能能力の一つがカラーに対応するかどうかを判断する。そして、ステップS424において、接続されたプリンタ1000がカラー機かモノクロ機かに応じてアプリケーションプログラムの取得を切り替える。具体的には、実行アプリケーションを切り替えるために、アプリケーション格納先(取得先)の情報を変換する。例えば格納先情報が/dev/$COLOR_FUNC/calibration.javaと表現されているとする。ここで機能情報を元に、$COLOR_FUNCを補間する。例えばカラー機の場合は /dev/color/calibration.java、モノクロ機の場合は/dev/mono/calibration.javaとする。こうすることでアプリケーションの取得先の切替を行う。なお、本実施形態ではカラー対応か否かによって起動すべきアプリケーションを決定するが、他の機能能力(解像度等)のそれぞれに応じてアプリケーションの決定を制御するようにできることは言うまでもない。
ステップS405では、プリンタコントローラ1600に対して図2で説明したようなAPI(リソース制御API)を用いて、上記ステップS424で設定されたアプリケーションプログラムの取得要求を発行する。ステップS406では、プリンタコントローラ1600からの応答に基づいて、要求したアプリケーションプログラムが取得できたかどうかを判断する。要求したアプリケーションプログラムが取得できた場合には、ステップS407へ進み、取得したアプリケーションプログラムをネットワークプリントサーバ1500のRAM14にロードする。そしてステップS410へ進み、当該アプリケーションプログラムを起動して本処理を終了する。
ステップS406で、要求したアプリケーションプログラムがプリンタコントローラ1600から取得できなかったと判定された場合、及びステップS408でネットワークプリントサーバに要求されたアプリケーションが存在しないと判定された場合は、ステップS411へ進み、アプリケーション起動要求命令の送信元であるホストコンピュータに対してエラーを通知し、本処理を終了する。なお、以降、アプリケーション起動要求があった場合はステップS401からの処理を繰り返す。
以上のように、第1実施形態によれば、Java仮想マシン上に提供される情報(アプリケーション)を印刷装置の機種に依存するものとしないものに分類し、機種依存の情報を各印刷装置本体(プリンタコントローラ)へ、機種非依存の情報をネットワークカードモジュールに分けて格納することが可能となり、メモリ容量の低減、利用効率の向上を図ることができる。また、プリンタの機能に応じてアプリケーションを自動的に切り替え、適切なアプリケーションを実行することができる。
<第2実施形態>
第1実施形態では、ホストコンピュータ等の外部装置からのアプリケーションの起動要求に応じて、そのURLからそのアプリケーションの格納先を判断する場合を説明した。第2実施形態では、プリンタ1000の起動時に自動起動アプリケーションとして指定されたアプリケーションを起動する場合を説明する。なお、自動起動アプリケーションを指定するための情報は、ネットワークプリントサーバ1500の所定の記憶領域に予め格納されている。
図5は、ネットワークプリントサーバ1500上で動作するアプリケーションプログラムの、第2実施形態による起動処理方法を示すフローチャートである。なお、ステップS501〜S509及びステップS520〜S524は各処理ステップを示し、各ステップに対応する制御手順はネットワークプリントサーバ1500のFlashROM3に記憶されている。また、本処理も管理アプリケーション1504に含まれる。なお、以下では、ネットワークプリントサーバ1500に存在するアプリケーションがプリンタ1000の機能能力に適合しない場合には、ネットワークプリントサーバ1500が、プリンタ1000の機能能力に適合するアプリケーションをプリンタ1000から取得してきて、取得してきたアプリケーションを自動起動アプリケーションの代わりに起動する。また、プリンタ1000の機能例としてカラーパラメータを用い、アプリケーションの実行時には、カラーパラメータに従ってアプリケーションプログラムの取得処理動作の切り替えを行う例を説明する。
プリンタ1000が電源ON或いはリセットによって再起動されると、ステップS420において、ネットワークプリントサーバ1500であるところのネットワークカードモジュールが、接続されたプリンタ1000の機能能力情報を獲得する。そしてステップS421において、ステップS420で獲得した機能能力情報を後にアプリケーションプログラムから参照可能とするようにメモリに保存する。次に、ステップS501でネットワークプリントサーバ1500の所定の記憶領域に自動起動するアプリケーションの格納情報が存在するか判定する。自動起動するアプリケーションの格納情報が存在する場合はステップS502に進み、起動すべきアプリケーションの格納情報を取得する。格納情報はパス(格納先)とアプリケーションファイル名を含む。よって、ステップS503において、アプリケーションの格納先を表す文字列が“/dev/”で始まっているかの判定を行なう。
格納先を表す文字列が“/dev/”で始まっている場合、当該アプリケーションの格納先はプリンタコントローラ1600内であると判断し、ステップS504へ進む。
一方、ステップS503で格納先を表す文字列が“/dev/”で始まっていない場合には、起動要求されたアプリケーションの格納先がネットワークプリントサーバ1500であると判断し、ステップS522へ進む。ステップS522でプリンタ1000の機能能力情報を参照し、ステップS523で、起動要求されたアプリケーションがプリンタ1000に対応するかどうかを判断する。対応しない場合には、ステップS524において、アプリケーションプログラムの取得先を切り替える。具体的には、アプリケーションがモノクロ機用であり、プリンタ1000がカラー機である場合、アプリケーション格納先(取得先)の情報を変換する。例えば格納先情報が/server/mono/calibration.javaと表現されているとする。ここで機能能力情報を元に、/server/monoを補間する。例えば、カラー機の場合は /dev/color/calibration.javaとする。こうすることで、起動要求されたアプリケーションがプリンタ1000に適合しない場合には、アプリケーションの取得先の切替を行い、プリンタ1000に適合するアプリケーションをプリンタ1000から取得するようにする。一方、対応している場合には、ステップS506に進む。
ステップS504では、プリンタコントローラ1600に対して図2で説明したようなAPI(リソース制御API)を用いてアプリケーションプログラムの取得要求を発行する。ステップS505では、プリンタコントローラ1600からの応答に基づいて、要求したアプリケーションプログラムが取得できたかどうかを判断する。要求したアプリケーションプログラムが取得できたと判断された場合は、ステップS506へ進み、アプリケーションプログラムをネットワークプリントサーバ1500のRAM14にロードする。そしてステップS509へ進み、アプリケーションプログラムを起動して処理を終了する。
一方、ステップS505でプリンタコントローラ1600から要求したアプリケーションプログラムが取得できなかったと判断された場合、ステップS507で要求されたアプリケーションが存在しないと判定した場合には、ただちに本処理を終了する。
なお、ステップS501で自動起動するアプリケーションの格納情報が存在しないと判断した場合にも同様にただちに本処理を終了する。
以上説明したように、第2実施形態によれば、第1実施形態と同様の効果を維持しながら、アプリケーションの自動起動に対応することができる。特に、起動要求されたアプリケーションがプリンタ1000に適合しない場合には、プリンタ1000に適合するアプリケーションを取得してきて起動することができる。
<第3実施形態>
以上、第1及び第2実施形態ではアプリケーションの起動処理について説明した。第3実施形態では、アプリケーションの実行中における各種コマンド等の実行処理について説明する。本実施形態では、複数種類のコマンド処理機能をネットワークプリントサーバとプリンタコントローラに分散して保持することを可能とし、メモリの利用効率を向上させる。
図6は、第3実施形態によるネットワークプリントサーバ1500上で動作するアプリケーションプログラムに記述された命令の処理手順を示すフローチャートである。なお、S601〜S610、S620〜S623は各処理ステップを示す。なお各ステップに対応する制御手順はネットワークプリントサーバ1500のFlashROM3に記憶されている。
上述した図4もしくは図5に従ってアプリケーションプログラムが起動すると、まずステップS620においてプリンタ側の持つ機能能力情報を獲得し、獲得した機能能力情報を以降のプログラムから参照可能とできるようにネットワークプリントサーバの記憶領域に保存しておく。本実施形態では、カラー機である場合とモノクロ機である場合の例について説明する。
続いて、ステップS601において起動中のアプリケーションプログラム内に含まれる命令を1つ取り出し、解析処理を行なう。ステップS602において命令種別がプリンタコントローラ1600に依存する命令であると判断した場合には、ステップS621へ進み、先にステップS620で獲得しておいた機能能力情報を参照する。ここでもし、装着されたプリンタ1000がモノクロ機であり、その命令がカラー機専用のものである場合には、その命令を実行させることができない。よって、ステップS622からステップS623へ進み、命令コードを変換する、すなわち、モノクロ機でも実行可能なようにプログラム命令の変換処理を行う。
例えば、図9に示すように、命令がカラー機用のキャリブレーション関数(printer.color_calibration())であり、接続されているプリンタがモノクロ機であった場合は、図9に示されるようにモノクロ機用のキャリブレーション関数(printer.mono_calibration())に変換される。なお命令変換後に呼び出される関数は本体側のアプリケーションとして既にロードされている場合を想定しているが、変換の後でロードされていないと判断されたら、その時点でロードを行うようにしても構わない。
以上のようにしてステップS623の処理を終えると、ステップS603へ進む。なお、機能能力としてカラー機能が確認された場合は、ステップS622から直接ステップS603へ進む。ステップS603では、図7で示すようなプリンタコントローラ1600の命令書式に従って命令コードを変換し、ステップS604でその変換された命令コードを拡張インタフェース17介してプリンタコントローラ1600へ送信する。例えば図3で示した“printer.outdata(“test”)”というデータ転送APIの場合、図7の命令種別に「書き込み」を示す値(0)が、呼び出し番号の領域に印刷を指示する命令番号(例700)が、引数データ種別の領域に印刷するデータ“test”のデータ型が文字列データあることを示す値(1)が、引数データサイズの領域に“test”のデータサイズ(例:4321)が、引数データ領域に“test”の実データが格納された命令コードが設定され、プリンタコントローラ1600に転送される。
ステップS605では、プリンタコントローラ1600からの上記命令コード送信に対する応答の有無を判断し、応答があった場合にはステップS606へ進む。ステップS606では、プリンタコントローラ1600から返信された処理結果を受信する。プリンタコントローラ1600から返信された処理結果は図8に示されるような書式を有する。例えば、上記“printer.outdata(“test”)というデータ転送APIの場合、関数戻り値領域にはステップS604で送信された命令コードの処理結果を示す値が、応答データ種別には応答データ領域に含まれるデータの型が数値型であることを示す値(0)が、応答データサイズ領域には応答データ領域のデータサイズのバイト数を示す数値が、応答データ領域にはステップS604で指示された命令番号の応答データが格納されて返信される。さらにステップS607で元のプログラム命令に対応した処理結果の書式に変換する。そしてステップS609へ進む。なお、ステップS605において、送信した命令コードの応答がプリンタコントローラ1600から一定期間内に受信できなかった場合には、ただちにプログラム処理を終了する。
また、ステップS602においてプリンタコントローラ1600に依存する命令ではないと判定された場合には、ステップS608へ進み、ネットワークプリントサーバ1500によって当該プログラム命令を処理し、ステップS609へ進む。
ステップS609では、プログラム命令の処理結果をネットワークプリントサーバ1500の所定のメモリ空間に格納する。ステップS610で後続のプログラム命令の有無を確認し、次の命令が存在する場合には再度ステップS601へ戻り上記処理を繰り返す。次の命令が存在しない場合には処理を終了する。
以上のように第3実施形態によれば、実行中のアプリケーションプログラムが含むプログラム命令がプリンタコントローラに依存する命令であっても、これをプリンタコントローラに提供して実行させることができる。即ち、機種依存型の命令の実行機能をネットワークプリントサーバ1500側で保持している必要が無くなるので、メモリの容量低減、効率的利用が促進される。
上記各実施形態では、機能能力のうちのカラー機か否かの判定に基づいてアプリケーションプログラムの取得及び起動制御を行うが、これに限られるものではない。例えば、解像度1200dpiを持つかどうか、オプションエミュレーションを持つかどうかといった機能能力においても本発明を適用できることは明らかである。
また、上述の各実施形態は、アプリケーションプログラムの取得及び起動を行なう登録動作制御であったが、機能能力の判定に基づいて既に登録済みのアプリケーションを削除、或いは更新するように変形することも可能である。これらの変形例について、以下の第4及び第5実施形態で説明する。
<第4実施形態>
図10は、第4実施形態によるアプリケーションプログラムの自動更新処理を説明するフローチャートである。本実施形態は、ネットワークカードモジュールを移設した場合に本発明を適用する処理方法の一例を示すものであり、プリンタ1000の機能例としてカラーパラメータを用いる。また、既に起動(登録)されているアプリケーションプログラムについては、そのバージョン情報を比較することにより、更新処理動作を行なうかどうかを切り替る。なお、図10の各処理ステップをネットワークプリントサーバ1500のCPU1に実行させるための制御プログラムは、ネットワークプリントサーバ1500のFlashROM3に記憶されている。また、ステップS401〜S411、S420、S421は第1実施形態(図4)で説明した処理と同じである。
ステップS404で格納先情報の文字列が“/dev/”で始まっている場合には、起動要求されたアプリケーションの格納先がプリンタコントローラ1600であると判断し、ステップS1021へ進む。ステップS1021では、ステップS420、S421で獲得、保存された機能能力情報を参照する。ここでは、プリンタ1000の機能能力はカラーかどうかを判定する。そして、接続されたプリンタ1000がカラー機かモノクロ機かに応じて、ロードすべきアプリケーションプログラムの取得先とそのバージョン情報を獲得する。
ステップS1022では、ロードすべきアプリケーションが既に実行されているかどうかを判断する。ロードすべきアプリケーションが既にロードされて起動可能な状態である場合は、ステップS1023へ進み、当該ロード済みのアプリケーションのバージョン情報を取得する。そして、ステップS1024で、ステップS1023で取得されたロード済みのアプリケーションのバージョン情報と、ステップS1021で取得された取得先のアプリケーションプログラムのバージョン情報との比較を行う。ロード済みのプログラムのバージョンの方が古い場合には、ステップS1025へ進み、当該アプリケーションプログラムをロードさせるようにアプリケーション取得先(格納元)を切り替える。このとき古いアプリケーションの削除を行ってもよい。
一方、ステップS1022でロードすべきアプリケーションが起動されていないと判定された場合は、そのままステップS1025へ進み、当該アプリケーションプログラムをロードさせるようにアプリケーション取得先を切り替える。
また、ステップS1024におけるバージョンの比較の結果、ロード済みのアプリケーションプログラムのバージョンと取得先のアプリケーションプログラムのバージョンが同じか、ロード済みのアプリケーションプログラムのバージョンの方が新しい場合は、ロードする必要がないので、何も処理を行わず、ステップS410へ進み、当該アプリケーションを起動させる。
以上のように第4実施形態によれば、ネットワークプリントサーバ1500に登録済みのアプリケーションに起動要求が合った場合、ロード済みのアプリケーションのバージョンがプリンタコントローラに存在するアプリケーションプログラムのバージョンよりも古ければ、自動的に新しいバージョンのアプリケーションプログラムがロードされ、実行されることになる。
<第5実施形態>
第5実施形態は、不必要なアプリケーションプログラムの削除について説明する。図11は、第5実施形態によるネットワークプリントサーバ1500上で動作する、アプリケーションプログラムの自動削除処理を示すフローチャートである。なお、図11の各処理ステップをネットワークプリントサーバ1500のCPU1に実行させるための制御プログラムは、ネットワークプリントサーバ1500のFlashROM3に記憶されている。また、ステップS401〜S411、S420、S421は第1実施形態(図4)で説明した処理と同じである。
ステップS404で格納先情報の文字列が“/dev/”で始まっている場合には、起動要求されたアプリケーションの格納先がプリンタコントローラ1600であると判断し、ステップS1121へ進む。ステップS1121では、プリンタ1000の機能能力情報を参照する。ここでは、プリンタ1000の機能能力はカラーかどうか、とする。プリンタ1000の機能能力がカラーかモノクロか判定されれば、カラー用のモジュールとモノクロ用のモジュールのいずれかは不要なアプリケーションということになる。従って、ステップS1122において、ロード済みとなっているアプリケーションプログラムを検索し、ステップS1123において、当該機能能力に照らして不要なアプリケーションがあるか否かを判定する。本実施形態では、接続されたプリンタ1000がカラー機かモノクロ機かに応じて、ステップS1122で検索されたアプリケーションプログラムのうち不要なアプリケーションプログラムを抽出するが、機能能力はカラー/モノクロに限られないことは言うまでない。
不要なアプリケーションプログラムが検出された場合は、ステップS1124へ進み、不要アプリケーションの削除処理を行った後、ステップS1125に進む。一方、不要なアプリケーションが検出されなかった場合はステップS1123からステップS1125へ直接進む。ステップS1125でアプリケーション取得先を切り替え、ステップS405へ進む。ステップS405では、プリンタコントローラ1600に対して図2で説明したようなAPIを用いて、ステップS1125で指定されたアプリケーションプログラムの取得要求を発行する。
なお、上記各実施形態において、プリンタ1000の機能として、カラーかモノクロかをチェックすることにより処理の切替を行った。しかしながら、本発明はこれに限定されるものではない。例えばデバイス能力として、以下の表に示すような処理可能なカラー階調数、処理可能な解像度、エミュレーション機能、ステイプル機能等が挙げられる。カラー諧調や色数、解像度等については、接続されるプリンタの能力により影響を受ける部分のアプリケーション処理について切り替えを行い、影響を受けない部分は変換されないという実装が考えられる。また、「影響を受けない部分」のアプリケーションの動作に不都合がでないよう「影響を受ける部分」の機種の能力に応じた代替処理を作成することになる。また、エミュレーション機能やステイプル機能とかについては、その機能が無い訳であるので、全く他の代替処理を行わせる。装着されているエミュレータへのデータ切り替えを行わせたり、ステイプルの場合は、バナー処理印刷を追加したりすることが考えられる。
以上詳述したように、上記第1乃至第5実施形態によれば、機種依存部分をプリンタに持たせることで効率的なリソース配分を狙ったJavaアプリケーションプログラム機能を持つネットワークカードモジュールにおいて、あるプリンタに装着していたネットワークカードモジュールを他のプリンタ(異なる機種、異なる設定が施されているなど)へ移設した場合において、ネットワークカードモジュール上のアプリケーションの動作条件を、プリンタ/システムの組み合わせ(機能、能力)に応じて自動で切り分ける、さらにネットワークカードモジュールに登録されたアプリケーションを、プリンタ/システムの組み合わせ(機能、能力)に応じて、自動削除や自動更新を行う、ということで、アプリケーションの実行自由度を上げる、さらにリソースの有効活用を図ることができる。なお、不要なアプリケーションの削除の実行(削除すべきアプリケーションがあるか否かの判断を含めて)は図11に示したタイミングに限られるものではなく、任意のタイミングで実行するようによしてもよい。
<第6実施形態>
上記第3実施形態では、アプリケーションの実行において、処理すべきプログラム命令がプリンタコントローラに依存する場合に、とプリンタの機能能力情報に基づいて代替処理の命令コードに変換して実行した。第6実施形態では、プリンタコントローラに依存する命令を処理する場合に、当該ネットワークプリントサーバ1500に接続された外部周辺装置22によって代替実行が可能な場合に、外部周辺装置22によって当該命令を処理する。こうして、外部周辺装置22を活用可能とする。
ネットワークプリントサーバ1500は、外部周辺装置インタフェース21を介して接続された外部周辺装置22と通信を行うことが可能であり、さらに外部周辺装置22をネットワークプリントサーバ1500側から制御することが可能である。なお、第6実施形態においては、この外部周辺装置22として「プリンタパネル装置」が接続されているとして説明する。よって、図3の302に示される行の記述により、プリンタ自身が表示パネルを持っていなくても、301の行で指示された処理結果をこの外部周辺装置22(プリンタパネル装置)が備えるLCD表示部へ表示出力させることができる。
図12は第6実施形態によるネットワークプリントサーバ1500上で動作するアプリケーションプログラム内に記述された命令の処理方法を示すフローチャートである。とりわけ、デバイス側の代替機能処理を行う場合の例を示す。なお、図12において図6と同じ処理には同一のステップ番号を付してある。なお各ステップに対応する制御手順はネットワークプリントサーバ1500のFlashROM3に記憶されている。
図4もしくは図5等の処理によってアプリケーションプログラムが起動すると、ステップS920において、プリンタの持つ機能能力情報を獲得する。例えば、パネル機能があるか否か、カラー機か否か、最大分速20枚の印刷が可能か否か、600dpiの解像度か否か、等である。更に、本実施形態では、接続されている外部周辺装置の機能能力情報も取得する。本実施形態ではパネル機能を有する外部周辺装置が接続されているものとする。そして、獲得した機能能力情報を、以降のプログラムから参照可能なようにネットワークプリントサーバの記憶領域に保存しておく。
続いてステップS601においてアプリケーションプログラム内に含まれる命令を解析し、ステップS602においてその命令種別がプリンタコントローラ1600に依存する命令か否かを判定する。プリンタコントローラに依存する命令であると判断した場合には、ステップS921へ進み、先のステップS920に獲得しておいた機能能力情報を参照する。そして、ステップS922において、当該命令がプリンタコントローラ1600では処理できないが、外部周辺装置22によって代替処理をさせることができると判断した場合は、ステップS923へ進み、当該命令を代替処理の命令コード変換する。そして、ステップS608へ進み、当該命令をネットワークプリントサーバ1500から実行させる。他の場合はステップS922からステップS603へ進む。
例えば、その命令がパネルに表示を行うという場合で、プリンタがパネルレスであるような場合には、プリンタによってその命令を実行させることはできない。そこで、外部周辺機器に関する機能情報から、ネットワークプリントサーバの外部周辺装置インタフェースにパネルが接続されているか否かを判断する。本例のようにパネル機能を有する外部周辺装置22が接続されていると判断された場合、ネットワークプリントサーバは当該パネルに当該命令を代替処理させるべく、命令コードを変換(代替機能関数を呼び出す)する。そして、この命令コードをネットワークプリントサーバ1500から実行する。
上記以外の処理は第3実施形態と同様であるので説明を省略する。
以上詳述したように本発明によれば、機種依存部分をプリンタに持たせることで効率的なリソース配分を狙ったJavaアプリケーションプログラム機能を持つネットワークカードモジュールにおいて、プリンタが既に市場に投入されたものに装着する場合、つまり後からプリンタ側にリソースを持たせることが困難な場合においても、ネットワークカードモジュールのJavaアプリケーションにより、外部周辺装置を用いてプリンタの代替機能処理を行うことができ、既存のプリンタになんら改変を加えることなく、新たな機能を追加することが可能になる。また、ネットワークカードモジュールに外部周辺装置インタフェースを設け、装着された外部周辺装置をネットワークカードモジュールが制御することにより、より広範囲の機能追加が可能となる。
〔その他の実施形態〕
第1、第2実施形態において、アプリケーションプログラムの格納先の判定方法では、URLから抽出した文字列に“/dev/”が存在するか否かによって格納先を特定していた。しかしながら、この方法ではURL自身が格納先を文字列として記す結果となるため、格納先を内部情報として隠蔽化したい場合には適当ではない。そこでこの対処方法として、予めアプリケーションプログラムの名称毎に格納先を識別できるテーブルをネットワークプリントサーバ内の記憶部に保持しておき、このテーブル情報に基づいて格納先を特定するようにしてもよい。この手法によればURLに格納先を示す文字列を含む必要がなくなり、格納先情報を隠蔽化することが可能である。
以上、本発明のネットワーク装置をネットワークカードモジュール(ネットワークプリントサーバ1500)で実現した例を説明したが、実現の形態としてはカードに限られるものではなく、カートリッジタイプ等、データ処理装置本体への着脱が可能な形態であればどの様な形態であってもよい。
また、本発明のネットワーク装置として、プリンタに装着するモジュール(ネットワークプリントサーバ1500)を説明したが、ネットワーク装置の適用はプリンタに限られるものではない。例えば、複写機やファクシミリ等、各種のデータ処理装置に適用できることは明らかであろう。
以上説明したように、上記各実施形態によれば、ネットワークカードモジュール上で動作可能なアプリケーションプログラムモジュールの格納先を、当該アプリケーションプログラムの種類によって分ける。すなわち、機種非依存(共通)のプログラムであればネットワークカードモジュールのFlashROM等の記憶デバイスに格納し、機種依存のプログラムであれば、印刷装置本体(プリンタコントローラ)の記憶デバイスに格納することが可能となり、ネットワークカードモジュールおよび印刷装置本体の記憶デバイスをより効率的に利用できる。換言すれば、アプリケーションプログラムの機種依存性の有無によってアプリケーションプログラムの保存先を分散化することが可能となるため、共通モジュールであるネットワークカードに不必要なデータを保持する必要がなくなり、ネットワークカードモジュール側の記憶容量を削減できる。また別の観点からみた場合、機種依存のあるアプリケーションをネットワークカードモジュール側に保持しないことでユーザが誤って他の機種でしか動作しないアプリケーションプログラムを起動させてしまうといったミスを防止できるという効果も期待できる。なお、上記各実施形態で起動アプリケーションの変更や命令(関数)の変換には、例えばそれらを登録したテーブルを用いればよい。
さらにアプリケーションプログラムを実行する際にも、プログラム内の命令種別に応じて、命令処理をネットワークカードモジュール側、印刷装置本体側にそれぞれ分散化できるため命令処理の効率化が図れる。また、命令処理に関わる印刷装置本体の機種依存を含む固有情報をネットワークカードモジュールで保持する必要がなくなるため、ネットワークカードモジュール自身のプログラム容量を削減することが可能となる。また、将来新たな印刷装置本体が追加されてもネットワークカードモジュール側に改変を加える必要がなく、流用性の向上にも寄与する。
また別の観点からみた場合、機種依存のあるアプリケーションをネットワークカードモジュール(ネットワークプリントサーバ)側に保持しないので、ユーザが誤って他の機種でしか動作しないアプリケーションプログラムを起動させてしまうといったミスを防止できるという効果も期待できる。
以上説明したように、本発明によれば、移設時の不具合、さらにリソースの無駄を解決することができる。
また、本発明によれば、移設時に登録済みとなっているアプリケーションの中で不要なものを自動的に削除、自動更新処理を行うことで、さらにリソースの無駄を解消させることができる。
更に、本発明によれば、多少の機種依存部分の処理をネットワークモジュール側で行う、もしくはネットワークモジュールに接続された外部周辺装置を制御することにより、アプリケーションによってデータ処理装置に足りない新たな機能を追加することができる。