JP4498460B2 - ネットワーク装置及びその制御方法 - Google Patents

Description

本発明は、プリンタ等のデータ処理装置に装着可能なネットワーク装置およびその制御方法に関する。

近年、インターネットの普及により、印刷装置、複写機、ファクシミリ装置等のデータ処理装置をネットワークに接続して使用する形態が一般化してきた。例えば、印刷装置の場合、高速機やカラー機などの高価格機ではネットワークインターフェイスは内蔵される傾向にある。しかしながら、低価格なモノクロ機の場合には、ネットワークインターフェイスは本体には組み込まれず、ネットワークカードモジュールとして別に供給される形態が一般的である。

この場合、印刷装置本体とネットワークカードモジュールは個々にＣＰＵを持ったインテリジェントな形態となる。そして、通常は、ネットワークカードモジュール側にネットワーク経由での各種プリントサービスの統括制御を行なうプリントサーバ機能が設けられる。このようなネットワークカードモジュールは接続インターフェイスを介して印刷装置と通信を行ない、所望のサービスを実現する。

このことは、印刷装置側からすれば、負荷の重いネットワークサービスをネットワークカードモジュール側に依存することを可能にする。従って、相対的に印刷装置本体のＣＰＵや周辺ＩＣ等のパフォーマンスを下げることが可能となり、印刷装置本体のコスト削減をもたらす結果となる。

従来のネットワークインターフェイスは、例えばＬＰＲ（Line Printer Daemon Protocol:TCP/IPでプリンタ共有を行なうときに使うリモート印刷プロトコル）に代表されるような印刷データの送信ができればよかった。しかしながら、昨今では印刷装置に対する情報管理というニーズが高くなり、付加技術として各種の手段が提供されている。

その最も単純な例が、印刷データを送信するポートに情報管理データ（ジョブ制御言語＝Job Language）を付加する形態である。ジョブ制御言語は印刷データを送るポートを共有する形であるため、サービスポートを増加せずに済み、比較的実装が簡単である。しかしながら、一方、印刷データ受信中にデータが大量に送信されるとポートが占有されてしまい、情報管理データのやりとりが止まってしまうという問題がある。またネットワークにおけるＬＰＲプロトコルのような片方向型コネクションの場合には、そもそも情報取得ができないという欠点がある。

次の手法としては、ＳＮＭＰ／ＭＩＢを使った方式がある。これはデータ送受信用の専用ポートを使用し、標準規格であるＳＮＭＰ(Simple Network Management Protocol)を使うＭＩＢ（Management Information Base:管理情報データベース）である。しかしこの方式では、ＳＮＭＰを受信してユーザインタフェース（ＵＩ）を提供する専用クライアントプログラムの独自開発が必要となる。更に、この方式では、そもそも単純な情報のやり取りを行うプロトコルであるため、数字、文字列などの単純なデータベースしか提供できない。その結果、機器の構成を示すビットマップ画像などを用いたグラフィカルユーザインタフェース（ＧＵＩ）を構成する情報はクライアントプログラム側で所有しておかなければならない。このため、クライアントプログラムを機種毎に対応させなくてはいけないという問題点がある。

さらに最近ではＨＴＴＰプロトコルを用いた方式が主流となりつつある。この方式によれば、ネットワークカードモジュールはＨＴＴＰサービスを用いて、機器情報に関するＨＴＭＬデータやビットマップ画像といったＷＥＢコンテンツをクライアントに提供する。クライアントは一般的なＷＥＢブラウザを使用してネットワークカードモジュールから提供されたＷＥＢコンテンツを表示し、ＧＵＩを実現する。このようなＧＵＩにて操作を可能とすれば、個別のクライアントプログラムを提供しなくても、専用のクライアントプログラムを用いた場合と同様の効果を得ることが可能である。専用のクライアントプログラムがその機器に固有な多種多様の情報（メッセージ文字列、ビットマップ画像等）を管理する必要があるため、機器が自分の機種情報だけを持てばよい上記方式は短期間で製品を提供するためにはもっとも適する方法である。

しかしながら上記述べたいずれの手法もネットワークカードモジュールに予め組み込まれた静的な機能を提供するに止まるものであり、後から機能そのものを追加したり、或いは、組み込まれた機能による制御方法を変更するといった動的なサービスの追加はできなかった。

これに対して、データ処理装置上で動作可能なアプリケーションプログラムをネットワーク上の外部装置より取得して実行するシステムが特許文献１によって提案されている。また、最近になってＪａｖａ（米国Sun Microsystems, Inc.の登録商標）言語を用いて作成されたアプリケーションプログラムモジュールを機器に組み込み、機器上に実装されたＪａｖａ仮想マシン上で動作可能とするプラットフォーム技術が提案されている。この技術を用いることで印刷装置等の組み込み機器に後から新たな機能を機器に追加することが可能となってきている。

上述のＪａｖａ仮想マシンにはネットワーク通信機能を始め、組み込み機器を制御するために必要な各種機能を提供するためにアプリケーションプログラムインタフェース（ＡＰＩ）が備わっている。Ｊａｖａ言語で作成されたアプリケーションプログラムモジュールはこれらのＡＰＩを呼び出して、組み込み機器に対する制御やネットワークで接続されたホストコンピュータからの要求を処理する。

特開２０００−２９８５６１号公報

上記Ｊａｖａ仮想マシン上で提供されるＡＰＩは、ネットワーク通信に必要な機能を含んでおり、ネットワーク通信プロトコルの処理を行なう基本モジュールを共有する。従って、インテリジェント型のネットワークカードモジュールに、上記Ｊａｖａ環境を実装し、ネットワーク通信を実現することも可能であろう。

しかしながら、印刷装置本体と別個にＣＰＵを備えるインテリジェント型ネットワークカードモジュールの場合、共通化による開発コスト低減と量産効果による生産コスト削減のために、通常複数のモデルの印刷装置間で共用可能（複数種類の印刷装置に接続可能）な設計が求められる。

複数のモデルの機種に接続可能にするために、ネットワークカードモジュールには、各機種に応じたメッセージや、グラフィカルユーザインタフェースに必要な印刷装置のビットマップ画像等のリソースデータや、各モデル固有な情報等を全て保持しなければならない。この結果、これらの情報を記憶するための必要なＲＯＭ容量が増大し、コスト増加が発生する。

さらに、Ｊａｖａ仮想マシン上で動作するアプリケーションプログラムモジュールの種類によっては、特定の機種でしか機能しないものや、特定の機種のみで必要なもの（以下、これらを機種依存アプリケーションプログラムという）もある。このため、これらの機種依存アプリケーションプログラムをネットワークカードモジュール内に保持することは上記ＲＯＭ容量の増加と併せて記憶領域の効率的利用の点でも課題を生じる。

また、上記のようなＪａｖａアプリケーションプログラム機能を持つネットワークカードモジュールを考えた場合、一度ある印刷装置本体に装着して使用していた環境からネットワークカードモジュールを別の環境に移設した場合において、接続される印刷装置本体の持つ機能の差異によって、もしくは前の環境で設定されていた値によって、ネットワークカードモジュールの動作に不具合が発生する可能性がある。或いは、不具合は発生しないもののリソースに無駄を生じさせる場合が存在する。

更に、印刷装置本体が既に市場に投入されたものである場合には、後からプリンタ側にリソースを持たせることが困難な場合も存在する。

本発明は、上記のような移設時の不具合、或いはリソースの無駄を解決することを目的とする。

上記の目的を達成するための本発明の一態様によるネットワーク装置は以下の構成を備える。即ち、
データ処理装置に対して着脱可能であり、データ処理装置に装着されることにより当該データ処理装置とネットワークとを接続し、前記データ処理装置の機能の実行を指示するアプリケーションを実行することが可能なネットワーク装置であって、
装着されたデータ処理装置が有する機能を示す機能情報を取得する取得手段と、
前記取得手段で取得した機能情報に基づき、前記ネットワーク装置の記憶装置に格納されているアプリケーションの中から前記データ処理装置が有する機能に適合しないアプリケーションを抽出する抽出手段と、
前記抽出手段で抽出されたアプリケーションを前記記憶装置から削除する削除手段とを備える。

本発明によれば、移設時の不具合、さらにリソースの無駄を解決することができる。

第１実施形態に関わる印刷システムのハードウェア構成を示すブロック図である。 第１実施形態に関わる印刷システムのソフトウェア構成を示すブロック図である。 アプリケーションプログラムのソースコード記述例を示す図である。 第１実施形態によるアプリケーションプログラムの起動処理方法を示すフローチャートである。 第２実施形態によるアプリケーションプログラムの起動処理方法を示すフローチャートである。 第３実施形態による、アプリケーションプログラム内に記述された命令の処理方法を示すフローチャートである。 プリンタコントローラに対する命令コード書式を示す図である。 プリンタコントローラから返信される命令処理結果の書式を示す図である。 第３実施形態によるコマンドの変換を説明する図である。 第４実施形態によるアプリケーションプログラムの起動処理方法を示すフローチャートである。 第５実施形態によるアプリケーションプログラムの起動処理方法を示すフローチャートである。 第６実施形態による、アプリケーションプログラム内に記述された命令の処理方法を示すフローチャートである。

以下、添付の図面を参照して本発明の好適な実施形態を説明する。

＜第１実施形態＞
図１は、第１実施形態に関わる印刷システムのハードウェア構成を説明するブロック図である。１０００はプリンタであり、大きくはネットワークプリントサーバ１５００とプリンタコントローラ１６００からなり、それぞれ独立した制御系を有する。

ネットワークプリントサーバ１５００は、ネットワークボードモジュールの形態で実現されたプリンタ１０００に対して着脱可能なネットワーク装置である。ネットワークプリントサーバ１５００において、１はネットワークプリントサーバ用ＣＰＵであり、書き換え可能なFlashROM３に記憶された制御プログラムに基づいて各種制御を実行する。例えば、システムバス４に接続されるネットワークコントローラ（ＬＡＮＣ５）を介してローカルエリアネットワーク（ＬＡＮ２０００）に接続されたホストコンピュータ等の外部装置（不図示）と所定のネットワーク通信プロトコルを用いて通信する。これにより、例えば、外部装置から送られる印刷データやプリンタ制御命令等の各種データの送受信を統括的に制御し、拡張インタフェースコントローラ（ＥＸＰＣ７）を介して接続されるプリンタコントローラ１５０１に対して適切なデータ転送制御を行なう。またFlashROM３には、図４，５，６のフローチャートで示されるようなＣＰＵ１によって実行される制御プログラムも記憶されている。

ＲＡＭ２はＣＰＵ１の主メモリ、ワークエリア等の一時記憶領域として用いられる。ＬＥＤ６はネットワークプリントサーバの動作状態を示す表示部として用いられており、例えばネットワークコントローラ（ＬＡＮＣ５）とローカルエリアネットワーク（ＬＡＮ２０００）の電気的な接続状態（ＬＩＮＫ）や、ネットワーク通信モード（10Baseや100Base、全二重、半二重）等の各種動作状態をＬＥＤの点滅パターンや色で示すことが可能となっている。

拡張インタフェース１７は、ネットワークプリントサーバ１５００とプリンタコントローラ１６００を接続するためのインタフェースであり、図示しないコネクタを含んで構成されている。ネットワークプリントサーバ１５００は、このコネクタによってプリンタ１０００（プリンタコントローラ１６００）との着脱が可能となっており、同じ構成を持つ別のプリンタに当該ネットワークプリントサーバ１５００を装着することも可能である。

外部周辺装置インターフェースコントローラ（ＥＸＩＯＣ２０）は、ネットワークプリントサーバ１５００上に実装された外部周辺装置インタフェースであり、後述するプリンタ１０００が接続される拡張インタフェースコントローラ７および拡張インタフェース１７とは異なるものである。本実施形態において、外部周辺装置インタフェースの形式は特に言及しないが、例としてＵＳＢインタフェースやＩＥＥＥ１３９４インタフェースを挙げることができる。この外部周辺装置インタフェースを介して接続された外部周辺装置２２と通信を行うことが可能であり、さらに外部周辺装置２２をネットワークプリントサーバ１５００側から制御することが可能である。

一方、プリンタコントローラ１６００において、８はプリンタコントローラ用ＣＰＵであり、システムバス１１に接続される各種デバイスとのアクセスを統括的に制御する。また、ＣＰＵ８の制御の下、ラスタコントローラ１２は、ネットワークプリントサーバ１５００から拡張インタフェースコントローラ（ＥＸＰＣ１３）を介して受信される印刷データに基づいて出力画像信号を生成し、プリントエンジン１６に対して画像信号を出力する。以上のような処理は、ＲＯＭ９に記憶された制御プログラム等、或いはディスクコントローラ（ＤＫＣ１５）を介して接続された外部メモリ１０に記憶されている制御プログラムやリソースデータ（資源情報）等に基づいてＣＰＵ８が動作することにより実現される。

１４はＣＰＵ８の主メモリ、ワークエリア等として機能するＲＡＭであり、図示しない増設ポートに接続されるオプションＲＡＭによりメモリ容量を拡張することができるように構成されている。１８は操作パネルであり、プリンタ１０００の動作モード等の設定や印刷データの取り消し等の操作を行なうためのボタンと、プリンタ１０００の動作状態を示す液晶パネルやＬＥＤ等の表示部等が配されている。なお、本図で示したプリンタエンジン１６は既知の印刷技術を利用するものであり、好適な実施系として例えば電子写真方式（レーザービーム方式）やインクジェット方式、昇華方（熱転写）方式等が挙げられる。

図２は、図１に示したネットワークプリントサーバ１５００およびプリンタコントローラ１６００の各記憶部（例えば、FlashROM３、ＲＯＭ９）に記憶された制御プログラムのソフトウェア構成を説明するブロック図である。なお、これらの制御プログラムはＣＰＵ１、８によって解析され実行される。

ネットワークプリントサーバ１５００側において、１５０１はオペレーティングシステムであり、ネットワークプリントサーバ１５００の基本的なデータ入出力制御を統括する。オペレーティングシステム１５０１は、プログラム／データ記憶部１５０９との入出力制御を行なうファイルシステム１５０５と、プリンタコントローラ１６００と拡張インタフェース１７を介して通信制御を行なう拡張インタフェースドライバ１５０６と、ローカルエリアネットワーク（ＬＡＮ２０００）の通信媒体を介してホストコンピュータ等の外部装置（不図示）と通信を行なうネットワークインタフェースドライバ１５０７と、外部周辺装置と外部周辺装置インタフェース（ＥＸＩＯ２１）を介して通信制御を行う外部周辺装置インタフェースドライバ１５１０とを内包している。なお、プログラムデータ記憶部１５０９は、例えばFlashROM３により構成される。

１５０２はアプリケーションプログラムインタフェース（ＡＰＩ）である。ＡＰＩ１５０２は、ネットワークプリントサーバ１５００で動作するユーザアプリケーション１５０３や管理アプリケーション１５０４等のアプリケーションプログラムに対してオペレーティングシステム１５０１が備える各種機能を提供する。なお、管理アプリケーション１５０４は、プリンタ１０００やユーザアプリケーションの登録・管理を行うアプリケーションである。またＡＰＩ１５０２は、印刷データの送受信機能を提供するデータ転送ＡＰＩ、ビットマップ画像や表示メッセージ及びアプリケーションプログラム等のリソースデータの入出力制御を行なうリソース制御ＡＰＩ、プリンタ１０００の再起動や設定値の初期化や設定等の制御を行なうプリンタ制御ＡＰＩ、印刷ジョブの取り消しや再印刷指示などを制御するジョブ制御ＡＰＩ、ネットワークプリントサーバ１５００の再起動や設定値の初期化や設定、およびアプリケーションプログラムの起動、登録、削除を行なうプリントサーバ制御ＡＰＩ等を備える。また、データ転送ＡＰＩ、リソース制御ＡＰＩ、プリンタ制御ＡＰＩ、ジョブ制御ＡＰＩによって提供される命令はプリンタコントローラ依存命令として図７で示されるような命令書式に変換した後、拡張インタフェース１７を介してプリンタコントローラに転送される。

プリンタコントローラ１６００側において、１６０１はプリンタコントローラ１６００の各種処理制御を統括するオペレーティングシステムであり、プリントエンジン制御部１６０３及びファイルシステム１６０４を有する。プリントエンジン制御部１６０３は、プリントエンジンとの通信制御を行なう。ファイルシステム１６０４は機種依存リソース／プログラム記憶部１６１０との入出力制御を行なう。機種依存リソース／プログラム記憶部１６１０は、ネットワークプリントサーバ１５００から参照されるビットマップ画像やエラーメッセージ等の機種依存リソース、及びネットワークプリントサーバ１５００上で動作する機種依存アプリケーションプログラム等を記憶する。

１６０２は拡張インタフェース制御部であり、拡張インタフェース１７を介してネットワークプリントサーバ１５００との通信制御を行なう。拡張インタフェース制御部１６０２は、制御種別に応じた論理インターフェースを備える。例えば、印刷データの入出力を制御するデータ転送論理インタフェース、機種依存リソース／プログラム記憶部１６１０に記憶された各種データの入出力を制御するリソース制御論理インタフェース、プリンタ１０００の再起動や設定値の初期化や設定等の制御を行なうプリンタ制御論理インタフェース、印刷ジョブの取り消しや再印刷指示などを制御するジョブ制御論理インタフェースを備える。各論理インタフェースは、ネットワークプリントサーバ１５００から要求された命令をオペレーティングシステム１６０１に転送し、その処理結果をネットワークプリントサーバ１５００に対して返信する。

図３は、ネットワークプリントサーバ１５００で動作するアプリケーションプログラムの記述例であり、本実施形態の好適な一例としてＪａｖａ言語による記述例を示している。図３の３０１に示される行は図２で説明したデータ転送ＡＰＩを呼び出す例であり、“printer.outdata(“Test”)”がデータ転送ＡＰＩである。これは“Test”というテキストデータを印字データとしてプリンタコントローラを介してプリントエンジンから印刷せよというプリンタコントローラ依存命令である。プリンタコントローラ１６００にて当該命令に従って処理が実行されると、コントローラから受信した処理結果が変数“result”に数値型として変換されて格納される。

図３の３０２に示される行は３０１の行で指示された処理結果を標準出力先（例えばプリンタ１０００の操作パネル１８のＬＣＤ表示部やアプリケーションの呼び出し元であるホストコンピュータのブラウザ表示部）にテキストメッセージ変換して表示する命令の記述例である。

図４は、第１実施形態に係るネットワークプリントサーバ１５００上で動作するアプリケーションプログラムの起動処理方法を示すフローチャートである。本処理は管理アプリケーション１５０４に含まれる。なお、Ｓ４０１〜Ｓ４１１及びＳ４２０〜Ｓ４２４は各処理ステップを示し、ローカルエリアネットワーク（ＬＡＮ２０００）に接続されたホストコンピュータ等の外部装置から本プリンタ１０００に対してアプリケーションの起動要求を受信した場合の処理の流れに対応する。なお各ステップに対応する制御手順はネットワークプリントサーバ１５００のFlashROM３に記憶されている。

なお、以下の動作例では、アプリケーションの実行時に、カラーパラメータに従ってアプリケーションプログラムの取得処理動作の切り替えを行う。まず、ステップＳ４２０において、ネットワークプリントサーバ１５００であるところのネットワークカードモジュールが、接続されたプリンタ１０００の機能能力情報を獲得する。そしてステップＳ４２１において、ステップＳ４２０で獲得した機能能力情報を後にアプリケーションプログラムから参照可能とするようにメモリに保存する。

ステップＳ４０１において、ＬＡＮ２０００を介して不図示のホストコンピュータ等の外部装置からアプリケーション起動要求命令を受信する。本実施形態において、アプリケーション起動要求命令は、ＵＲＬ（Uniform Resource Locator）などのアプリケーションを識別するための識別情報により起動すべきアプリケーションプログラムを特定する。ステップＳ４０２ではステップＳ４０１で受信したアプリケーション起動要求命令からアプリケーションを特定するＵＲＬを取得する。ステップＳ４０３では、取得したＵＲＬから、起動要求されているアプリケーションの当該プリンタ１０００内における格納先情報を抽出する。例えば指定されたアプリケーションのＵＲＬが、
HTTP://192.168.0.215/abc/xyz.Java
の場合は、HTTP://はスキームであり、192.168.0.215 は本プリンタ装置自身のネットワークアドレスを示すものであるため、格納先情報として抽出される情報は、“/abc/xyx.Java” となる。

本実施形態では、格納先情報の文字列から、当該アプリケーションがプリントサーバ１５００内の記憶部（例えばFlashROM３）に格納されているか、プリンタコントローラ１６００内の記憶部（例えばＲＯＭ９）に格納されているかを判定する。本実施形態では、“/dev/”で始まる格納先はプリンタコントローラ側であるとする。

よって、ステップＳ４０４では、ステップＳ４０３で抽出した格納先情報の文字列が“/dev/”で始まっているか否かを判定する。格納先情報の文字列が“/dev/”で始まっていない場合、起動すべきアプリケーションはネットワークプリントサーバ１６００内にあると判断され、処理はステップＳ４０８へ進む。ステップＳ４０８では、ネットワークプリントサーバ１５００内の記憶部に該当するアプリケーションプログラムが存在するか判定する。該当するアプリケーションプログラムが存在する場合にはステップＳ４０９へ進み、要求されたアプリケーションプログラムをネットワークプリントサーバ１５００のＲＡＭ１４にロードする。そしてステップＳ４１０へ進み、当該アプリケーションプログラムを起動して本処理を終了する。なお、ステップＳ４０８で該当するアプリケーションが存在しない場合は、ステップＳ４１１へ進み、要求元にエラーを通知して本処理を終了する。

一方、ステップＳ４０４で格納先情報の文字列が“/dev/”で始まっている場合には、起動要求されたアプリケーションの格納先がプリンタコントローラ１６００であると判断し、ステップＳ４２２へ進む。ステップＳ４２２でプリンタ１０００の機能能力情報を参照し、ステップＳ４２３で、当該機能能力の一つがカラーに対応するかどうかを判断する。そして、ステップＳ４２４において、接続されたプリンタ１０００がカラー機かモノクロ機かに応じてアプリケーションプログラムの取得を切り替える。具体的には、実行アプリケーションを切り替えるために、アプリケーション格納先（取得先）の情報を変換する。例えば格納先情報が/dev/$COLOR_FUNC/calibration.javaと表現されているとする。ここで機能情報を元に、$COLOR_FUNCを補間する。例えばカラー機の場合は /dev/color/calibration.java、モノクロ機の場合は/dev/mono/calibration.javaとする。こうすることでアプリケーションの取得先の切替を行う。なお、本実施形態ではカラー対応か否かによって起動すべきアプリケーションを決定するが、他の機能能力（解像度等）のそれぞれに応じてアプリケーションの決定を制御するようにできることは言うまでもない。

ステップＳ４０５では、プリンタコントローラ１６００に対して図２で説明したようなＡＰＩ（リソース制御ＡＰＩ）を用いて、上記ステップＳ４２４で設定されたアプリケーションプログラムの取得要求を発行する。ステップＳ４０６では、プリンタコントローラ１６００からの応答に基づいて、要求したアプリケーションプログラムが取得できたかどうかを判断する。要求したアプリケーションプログラムが取得できた場合には、ステップＳ４０７へ進み、取得したアプリケーションプログラムをネットワークプリントサーバ１５００のＲＡＭ１４にロードする。そしてステップＳ４１０へ進み、当該アプリケーションプログラムを起動して本処理を終了する。

ステップＳ４０６で、要求したアプリケーションプログラムがプリンタコントローラ１６００から取得できなかったと判定された場合、及びステップＳ４０８でネットワークプリントサーバに要求されたアプリケーションが存在しないと判定された場合は、ステップＳ４１１へ進み、アプリケーション起動要求命令の送信元であるホストコンピュータに対してエラーを通知し、本処理を終了する。なお、以降、アプリケーション起動要求があった場合はステップＳ４０１からの処理を繰り返す。

以上のように、第１実施形態によれば、Ｊａｖａ仮想マシン上に提供される情報（アプリケーション）を印刷装置の機種に依存するものとしないものに分類し、機種依存の情報を各印刷装置本体（プリンタコントローラ）へ、機種非依存の情報をネットワークカードモジュールに分けて格納することが可能となり、メモリ容量の低減、利用効率の向上を図ることができる。また、プリンタの機能に応じてアプリケーションを自動的に切り替え、適切なアプリケーションを実行することができる。

＜第２実施形態＞
第１実施形態では、ホストコンピュータ等の外部装置からのアプリケーションの起動要求に応じて、そのＵＲＬからそのアプリケーションの格納先を判断する場合を説明した。第２実施形態では、プリンタ１０００の起動時に自動起動アプリケーションとして指定されたアプリケーションを起動する場合を説明する。なお、自動起動アプリケーションを指定するための情報は、ネットワークプリントサーバ１５００の所定の記憶領域に予め格納されている。

図５は、ネットワークプリントサーバ１５００上で動作するアプリケーションプログラムの、第２実施形態による起動処理方法を示すフローチャートである。なお、ステップＳ５０１〜Ｓ５０９及びステップＳ５２０〜Ｓ５２４は各処理ステップを示し、各ステップに対応する制御手順はネットワークプリントサーバ１５００のFlashROM３に記憶されている。また、本処理も管理アプリケーション１５０４に含まれる。なお、以下では、ネットワークプリントサーバ１５００に存在するアプリケーションがプリンタ１０００の機能能力に適合しない場合には、ネットワークプリントサーバ１５００が、プリンタ１０００の機能能力に適合するアプリケーションをプリンタ１０００から取得してきて、取得してきたアプリケーションを自動起動アプリケーションの代わりに起動する。また、プリンタ１０００の機能例としてカラーパラメータを用い、アプリケーションの実行時には、カラーパラメータに従ってアプリケーションプログラムの取得処理動作の切り替えを行う例を説明する。

プリンタ１０００が電源ＯＮ或いはリセットによって再起動されると、ステップＳ４２０において、ネットワークプリントサーバ１５００であるところのネットワークカードモジュールが、接続されたプリンタ１０００の機能能力情報を獲得する。そしてステップＳ４２１において、ステップＳ４２０で獲得した機能能力情報を後にアプリケーションプログラムから参照可能とするようにメモリに保存する。次に、ステップＳ５０１でネットワークプリントサーバ１５００の所定の記憶領域に自動起動するアプリケーションの格納情報が存在するか判定する。自動起動するアプリケーションの格納情報が存在する場合はステップＳ５０２に進み、起動すべきアプリケーションの格納情報を取得する。格納情報はパス（格納先）とアプリケーションファイル名を含む。よって、ステップＳ５０３において、アプリケーションの格納先を表す文字列が“/dev/”で始まっているかの判定を行なう。

格納先を表す文字列が“/dev/”で始まっている場合、当該アプリケーションの格納先はプリンタコントローラ１６００内であると判断し、ステップＳ５０４へ進む。

一方、ステップＳ５０３で格納先を表す文字列が“/dev/”で始まっていない場合には、起動要求されたアプリケーションの格納先がネットワークプリントサーバ１５００であると判断し、ステップＳ５２２へ進む。ステップＳ５２２でプリンタ１０００の機能能力情報を参照し、ステップＳ５２３で、起動要求されたアプリケーションがプリンタ１０００に対応するかどうかを判断する。対応しない場合には、ステップＳ５２４において、アプリケーションプログラムの取得先を切り替える。具体的には、アプリケーションがモノクロ機用であり、プリンタ１０００がカラー機である場合、アプリケーション格納先（取得先）の情報を変換する。例えば格納先情報が/server/mono/calibration.javaと表現されているとする。ここで機能能力情報を元に、/server/monoを補間する。例えば、カラー機の場合は /dev/color/calibration.javaとする。こうすることで、起動要求されたアプリケーションがプリンタ１０００に適合しない場合には、アプリケーションの取得先の切替を行い、プリンタ１０００に適合するアプリケーションをプリンタ１０００から取得するようにする。一方、対応している場合には、ステップＳ５０６に進む。

ステップＳ５０４では、プリンタコントローラ１６００に対して図２で説明したようなＡＰＩ（リソース制御ＡＰＩ）を用いてアプリケーションプログラムの取得要求を発行する。ステップＳ５０５では、プリンタコントローラ１６００からの応答に基づいて、要求したアプリケーションプログラムが取得できたかどうかを判断する。要求したアプリケーションプログラムが取得できたと判断された場合は、ステップＳ５０６へ進み、アプリケーションプログラムをネットワークプリントサーバ１５００のＲＡＭ１４にロードする。そしてステップＳ５０９へ進み、アプリケーションプログラムを起動して処理を終了する。

一方、ステップＳ５０５でプリンタコントローラ１６００から要求したアプリケーションプログラムが取得できなかったと判断された場合、ステップＳ５０７で要求されたアプリケーションが存在しないと判定した場合には、ただちに本処理を終了する。

なお、ステップＳ５０１で自動起動するアプリケーションの格納情報が存在しないと判断した場合にも同様にただちに本処理を終了する。

以上説明したように、第２実施形態によれば、第１実施形態と同様の効果を維持しながら、アプリケーションの自動起動に対応することができる。特に、起動要求されたアプリケーションがプリンタ１０００に適合しない場合には、プリンタ１０００に適合するアプリケーションを取得してきて起動することができる。

＜第３実施形態＞
以上、第１及び第２実施形態ではアプリケーションの起動処理について説明した。第３実施形態では、アプリケーションの実行中における各種コマンド等の実行処理について説明する。本実施形態では、複数種類のコマンド処理機能をネットワークプリントサーバとプリンタコントローラに分散して保持することを可能とし、メモリの利用効率を向上させる。

図６は、第３実施形態によるネットワークプリントサーバ１５００上で動作するアプリケーションプログラムに記述された命令の処理手順を示すフローチャートである。なお、Ｓ６０１〜Ｓ６１０、Ｓ６２０〜Ｓ６２３は各処理ステップを示す。なお各ステップに対応する制御手順はネットワークプリントサーバ１５００のFlashROM３に記憶されている。

上述した図４もしくは図５に従ってアプリケーションプログラムが起動すると、まずステップＳ６２０においてプリンタ側の持つ機能能力情報を獲得し、獲得した機能能力情報を以降のプログラムから参照可能とできるようにネットワークプリントサーバの記憶領域に保存しておく。本実施形態では、カラー機である場合とモノクロ機である場合の例について説明する。

続いて、ステップＳ６０１において起動中のアプリケーションプログラム内に含まれる命令を１つ取り出し、解析処理を行なう。ステップＳ６０２において命令種別がプリンタコントローラ１６００に依存する命令であると判断した場合には、ステップＳ６２１へ進み、先にステップＳ６２０で獲得しておいた機能能力情報を参照する。ここでもし、装着されたプリンタ１０００がモノクロ機であり、その命令がカラー機専用のものである場合には、その命令を実行させることができない。よって、ステップＳ６２２からステップＳ６２３へ進み、命令コードを変換する、すなわち、モノクロ機でも実行可能なようにプログラム命令の変換処理を行う。

例えば、図９に示すように、命令がカラー機用のキャリブレーション関数（printer.color_calibration()）であり、接続されているプリンタがモノクロ機であった場合は、図９に示されるようにモノクロ機用のキャリブレーション関数（printer.mono_calibration()）に変換される。なお命令変換後に呼び出される関数は本体側のアプリケーションとして既にロードされている場合を想定しているが、変換の後でロードされていないと判断されたら、その時点でロードを行うようにしても構わない。

以上のようにしてステップＳ６２３の処理を終えると、ステップＳ６０３へ進む。なお、機能能力としてカラー機能が確認された場合は、ステップＳ６２２から直接ステップＳ６０３へ進む。ステップＳ６０３では、図７で示すようなプリンタコントローラ１６００の命令書式に従って命令コードを変換し、ステップＳ６０４でその変換された命令コードを拡張インタフェース１７介してプリンタコントローラ１６００へ送信する。例えば図３で示した“printer.outdata(“test”)”というデータ転送ＡＰＩの場合、図７の命令種別に「書き込み」を示す値（０）が、呼び出し番号の領域に印刷を指示する命令番号（例７００）が、引数データ種別の領域に印刷するデータ“test”のデータ型が文字列データあることを示す値（１）が、引数データサイズの領域に“test”のデータサイズ（例：４３２１）が、引数データ領域に“test”の実データが格納された命令コードが設定され、プリンタコントローラ１６００に転送される。

ステップＳ６０５では、プリンタコントローラ１６００からの上記命令コード送信に対する応答の有無を判断し、応答があった場合にはステップＳ６０６へ進む。ステップＳ６０６では、プリンタコントローラ１６００から返信された処理結果を受信する。プリンタコントローラ１６００から返信された処理結果は図８に示されるような書式を有する。例えば、上記“printer.outdata(“test”)というデータ転送ＡＰＩの場合、関数戻り値領域にはステップＳ６０４で送信された命令コードの処理結果を示す値が、応答データ種別には応答データ領域に含まれるデータの型が数値型であることを示す値（０）が、応答データサイズ領域には応答データ領域のデータサイズのバイト数を示す数値が、応答データ領域にはステップＳ６０４で指示された命令番号の応答データが格納されて返信される。さらにステップＳ６０７で元のプログラム命令に対応した処理結果の書式に変換する。そしてステップＳ６０９へ進む。なお、ステップＳ６０５において、送信した命令コードの応答がプリンタコントローラ１６００から一定期間内に受信できなかった場合には、ただちにプログラム処理を終了する。

また、ステップＳ６０２においてプリンタコントローラ１６００に依存する命令ではないと判定された場合には、ステップＳ６０８へ進み、ネットワークプリントサーバ１５００によって当該プログラム命令を処理し、ステップＳ６０９へ進む。

ステップＳ６０９では、プログラム命令の処理結果をネットワークプリントサーバ１５００の所定のメモリ空間に格納する。ステップＳ６１０で後続のプログラム命令の有無を確認し、次の命令が存在する場合には再度ステップＳ６０１へ戻り上記処理を繰り返す。次の命令が存在しない場合には処理を終了する。

以上のように第３実施形態によれば、実行中のアプリケーションプログラムが含むプログラム命令がプリンタコントローラに依存する命令であっても、これをプリンタコントローラに提供して実行させることができる。即ち、機種依存型の命令の実行機能をネットワークプリントサーバ１５００側で保持している必要が無くなるので、メモリの容量低減、効率的利用が促進される。

上記各実施形態では、機能能力のうちのカラー機か否かの判定に基づいてアプリケーションプログラムの取得及び起動制御を行うが、これに限られるものではない。例えば、解像度１２００ｄｐｉを持つかどうか、オプションエミュレーションを持つかどうかといった機能能力においても本発明を適用できることは明らかである。

また、上述の各実施形態は、アプリケーションプログラムの取得及び起動を行なう登録動作制御であったが、機能能力の判定に基づいて既に登録済みのアプリケーションを削除、或いは更新するように変形することも可能である。これらの変形例について、以下の第４及び第５実施形態で説明する。

＜第４実施形態＞
図１０は、第４実施形態によるアプリケーションプログラムの自動更新処理を説明するフローチャートである。本実施形態は、ネットワークカードモジュールを移設した場合に本発明を適用する処理方法の一例を示すものであり、プリンタ１０００の機能例としてカラーパラメータを用いる。また、既に起動（登録）されているアプリケーションプログラムについては、そのバージョン情報を比較することにより、更新処理動作を行なうかどうかを切り替る。なお、図１０の各処理ステップをネットワークプリントサーバ１５００のＣＰＵ１に実行させるための制御プログラムは、ネットワークプリントサーバ１５００のFlashROM３に記憶されている。また、ステップＳ４０１〜Ｓ４１１、Ｓ４２０、Ｓ４２１は第１実施形態（図４）で説明した処理と同じである。

ステップＳ４０４で格納先情報の文字列が“/dev/”で始まっている場合には、起動要求されたアプリケーションの格納先がプリンタコントローラ１６００であると判断し、ステップＳ１０２１へ進む。ステップＳ１０２１では、ステップＳ４２０、Ｓ４２１で獲得、保存された機能能力情報を参照する。ここでは、プリンタ１０００の機能能力はカラーかどうかを判定する。そして、接続されたプリンタ１０００がカラー機かモノクロ機かに応じて、ロードすべきアプリケーションプログラムの取得先とそのバージョン情報を獲得する。

ステップＳ１０２２では、ロードすべきアプリケーションが既に実行されているかどうかを判断する。ロードすべきアプリケーションが既にロードされて起動可能な状態である場合は、ステップＳ１０２３へ進み、当該ロード済みのアプリケーションのバージョン情報を取得する。そして、ステップＳ１０２４で、ステップＳ１０２３で取得されたロード済みのアプリケーションのバージョン情報と、ステップＳ１０２１で取得された取得先のアプリケーションプログラムのバージョン情報との比較を行う。ロード済みのプログラムのバージョンの方が古い場合には、ステップＳ１０２５へ進み、当該アプリケーションプログラムをロードさせるようにアプリケーション取得先（格納元）を切り替える。このとき古いアプリケーションの削除を行ってもよい。

一方、ステップＳ１０２２でロードすべきアプリケーションが起動されていないと判定された場合は、そのままステップＳ１０２５へ進み、当該アプリケーションプログラムをロードさせるようにアプリケーション取得先を切り替える。

また、ステップＳ１０２４におけるバージョンの比較の結果、ロード済みのアプリケーションプログラムのバージョンと取得先のアプリケーションプログラムのバージョンが同じか、ロード済みのアプリケーションプログラムのバージョンの方が新しい場合は、ロードする必要がないので、何も処理を行わず、ステップＳ４１０へ進み、当該アプリケーションを起動させる。

以上のように第４実施形態によれば、ネットワークプリントサーバ１５００に登録済みのアプリケーションに起動要求が合った場合、ロード済みのアプリケーションのバージョンがプリンタコントローラに存在するアプリケーションプログラムのバージョンよりも古ければ、自動的に新しいバージョンのアプリケーションプログラムがロードされ、実行されることになる。

＜第５実施形態＞
第５実施形態は、不必要なアプリケーションプログラムの削除について説明する。図１１は、第５実施形態によるネットワークプリントサーバ１５００上で動作する、アプリケーションプログラムの自動削除処理を示すフローチャートである。なお、図１１の各処理ステップをネットワークプリントサーバ１５００のＣＰＵ１に実行させるための制御プログラムは、ネットワークプリントサーバ１５００のFlashROM３に記憶されている。また、ステップＳ４０１〜Ｓ４１１、Ｓ４２０、Ｓ４２１は第１実施形態（図４）で説明した処理と同じである。

ステップＳ４０４で格納先情報の文字列が“/dev/”で始まっている場合には、起動要求されたアプリケーションの格納先がプリンタコントローラ１６００であると判断し、ステップＳ１１２１へ進む。ステップＳ１１２１では、プリンタ１０００の機能能力情報を参照する。ここでは、プリンタ１０００の機能能力はカラーかどうか、とする。プリンタ１０００の機能能力がカラーかモノクロか判定されれば、カラー用のモジュールとモノクロ用のモジュールのいずれかは不要なアプリケーションということになる。従って、ステップＳ１１２２において、ロード済みとなっているアプリケーションプログラムを検索し、ステップＳ１１２３において、当該機能能力に照らして不要なアプリケーションがあるか否かを判定する。本実施形態では、接続されたプリンタ１０００がカラー機かモノクロ機かに応じて、ステップＳ１１２２で検索されたアプリケーションプログラムのうち不要なアプリケーションプログラムを抽出するが、機能能力はカラー／モノクロに限られないことは言うまでない。

不要なアプリケーションプログラムが検出された場合は、ステップＳ１１２４へ進み、不要アプリケーションの削除処理を行った後、ステップＳ１１２５に進む。一方、不要なアプリケーションが検出されなかった場合はステップＳ１１２３からステップＳ１１２５へ直接進む。ステップＳ１１２５でアプリケーション取得先を切り替え、ステップＳ４０５へ進む。ステップＳ４０５では、プリンタコントローラ１６００に対して図２で説明したようなＡＰＩを用いて、ステップＳ１１２５で指定されたアプリケーションプログラムの取得要求を発行する。

なお、上記各実施形態において、プリンタ１０００の機能として、カラーかモノクロかをチェックすることにより処理の切替を行った。しかしながら、本発明はこれに限定されるものではない。例えばデバイス能力として、以下の表に示すような処理可能なカラー階調数、処理可能な解像度、エミュレーション機能、ステイプル機能等が挙げられる。カラー諧調や色数、解像度等については、接続されるプリンタの能力により影響を受ける部分のアプリケーション処理について切り替えを行い、影響を受けない部分は変換されないという実装が考えられる。また、「影響を受けない部分」のアプリケーションの動作に不都合がでないよう「影響を受ける部分」の機種の能力に応じた代替処理を作成することになる。また、エミュレーション機能やステイプル機能とかについては、その機能が無い訳であるので、全く他の代替処理を行わせる。装着されているエミュレータへのデータ切り替えを行わせたり、ステイプルの場合は、バナー処理印刷を追加したりすることが考えられる。

以上詳述したように、上記第１乃至第５実施形態によれば、機種依存部分をプリンタに持たせることで効率的なリソース配分を狙ったJavaアプリケーションプログラム機能を持つネットワークカードモジュールにおいて、あるプリンタに装着していたネットワークカードモジュールを他のプリンタ（異なる機種、異なる設定が施されているなど）へ移設した場合において、ネットワークカードモジュール上のアプリケーションの動作条件を、プリンタ／システムの組み合わせ（機能、能力）に応じて自動で切り分ける、さらにネットワークカードモジュールに登録されたアプリケーションを、プリンタ／システムの組み合わせ（機能、能力）に応じて、自動削除や自動更新を行う、ということで、アプリケーションの実行自由度を上げる、さらにリソースの有効活用を図ることができる。なお、不要なアプリケーションの削除の実行（削除すべきアプリケーションがあるか否かの判断を含めて）は図１１に示したタイミングに限られるものではなく、任意のタイミングで実行するようによしてもよい。

＜第６実施形態＞
上記第３実施形態では、アプリケーションの実行において、処理すべきプログラム命令がプリンタコントローラに依存する場合に、とプリンタの機能能力情報に基づいて代替処理の命令コードに変換して実行した。第６実施形態では、プリンタコントローラに依存する命令を処理する場合に、当該ネットワークプリントサーバ１５００に接続された外部周辺装置２２によって代替実行が可能な場合に、外部周辺装置２２によって当該命令を処理する。こうして、外部周辺装置２２を活用可能とする。

ネットワークプリントサーバ１５００は、外部周辺装置インタフェース２１を介して接続された外部周辺装置２２と通信を行うことが可能であり、さらに外部周辺装置２２をネットワークプリントサーバ１５００側から制御することが可能である。なお、第６実施形態においては、この外部周辺装置２２として「プリンタパネル装置」が接続されているとして説明する。よって、図３の３０２に示される行の記述により、プリンタ自身が表示パネルを持っていなくても、３０１の行で指示された処理結果をこの外部周辺装置２２（プリンタパネル装置）が備えるＬＣＤ表示部へ表示出力させることができる。

図１２は第６実施形態によるネットワークプリントサーバ１５００上で動作するアプリケーションプログラム内に記述された命令の処理方法を示すフローチャートである。とりわけ、デバイス側の代替機能処理を行う場合の例を示す。なお、図１２において図６と同じ処理には同一のステップ番号を付してある。なお各ステップに対応する制御手順はネットワークプリントサーバ１５００のFlashROM３に記憶されている。

図４もしくは図５等の処理によってアプリケーションプログラムが起動すると、ステップＳ９２０において、プリンタの持つ機能能力情報を獲得する。例えば、パネル機能があるか否か、カラー機か否か、最大分速２０枚の印刷が可能か否か、６００ｄｐｉの解像度か否か、等である。更に、本実施形態では、接続されている外部周辺装置の機能能力情報も取得する。本実施形態ではパネル機能を有する外部周辺装置が接続されているものとする。そして、獲得した機能能力情報を、以降のプログラムから参照可能なようにネットワークプリントサーバの記憶領域に保存しておく。

続いてステップＳ６０１においてアプリケーションプログラム内に含まれる命令を解析し、ステップＳ６０２においてその命令種別がプリンタコントローラ１６００に依存する命令か否かを判定する。プリンタコントローラに依存する命令であると判断した場合には、ステップＳ９２１へ進み、先のステップＳ９２０に獲得しておいた機能能力情報を参照する。そして、ステップＳ９２２において、当該命令がプリンタコントローラ１６００では処理できないが、外部周辺装置２２によって代替処理をさせることができると判断した場合は、ステップＳ９２３へ進み、当該命令を代替処理の命令コード変換する。そして、ステップＳ６０８へ進み、当該命令をネットワークプリントサーバ１５００から実行させる。他の場合はステップＳ９２２からステップＳ６０３へ進む。

例えば、その命令がパネルに表示を行うという場合で、プリンタがパネルレスであるような場合には、プリンタによってその命令を実行させることはできない。そこで、外部周辺機器に関する機能情報から、ネットワークプリントサーバの外部周辺装置インタフェースにパネルが接続されているか否かを判断する。本例のようにパネル機能を有する外部周辺装置２２が接続されていると判断された場合、ネットワークプリントサーバは当該パネルに当該命令を代替処理させるべく、命令コードを変換（代替機能関数を呼び出す）する。そして、この命令コードをネットワークプリントサーバ１５００から実行する。

上記以外の処理は第３実施形態と同様であるので説明を省略する。

以上詳述したように本発明によれば、機種依存部分をプリンタに持たせることで効率的なリソース配分を狙ったＪａｖａアプリケーションプログラム機能を持つネットワークカードモジュールにおいて、プリンタが既に市場に投入されたものに装着する場合、つまり後からプリンタ側にリソースを持たせることが困難な場合においても、ネットワークカードモジュールのＪａｖａアプリケーションにより、外部周辺装置を用いてプリンタの代替機能処理を行うことができ、既存のプリンタになんら改変を加えることなく、新たな機能を追加することが可能になる。また、ネットワークカードモジュールに外部周辺装置インタフェースを設け、装着された外部周辺装置をネットワークカードモジュールが制御することにより、より広範囲の機能追加が可能となる。

〔その他の実施形態〕
第１、第２実施形態において、アプリケーションプログラムの格納先の判定方法では、ＵＲＬから抽出した文字列に“/dev/”が存在するか否かによって格納先を特定していた。しかしながら、この方法ではＵＲＬ自身が格納先を文字列として記す結果となるため、格納先を内部情報として隠蔽化したい場合には適当ではない。そこでこの対処方法として、予めアプリケーションプログラムの名称毎に格納先を識別できるテーブルをネットワークプリントサーバ内の記憶部に保持しておき、このテーブル情報に基づいて格納先を特定するようにしてもよい。この手法によればＵＲＬに格納先を示す文字列を含む必要がなくなり、格納先情報を隠蔽化することが可能である。

以上、本発明のネットワーク装置をネットワークカードモジュール（ネットワークプリントサーバ１５００）で実現した例を説明したが、実現の形態としてはカードに限られるものではなく、カートリッジタイプ等、データ処理装置本体への着脱が可能な形態であればどの様な形態であってもよい。

また、本発明のネットワーク装置として、プリンタに装着するモジュール（ネットワークプリントサーバ１５００）を説明したが、ネットワーク装置の適用はプリンタに限られるものではない。例えば、複写機やファクシミリ等、各種のデータ処理装置に適用できることは明らかであろう。

以上説明したように、上記各実施形態によれば、ネットワークカードモジュール上で動作可能なアプリケーションプログラムモジュールの格納先を、当該アプリケーションプログラムの種類によって分ける。すなわち、機種非依存（共通）のプログラムであればネットワークカードモジュールのFlashROM等の記憶デバイスに格納し、機種依存のプログラムであれば、印刷装置本体（プリンタコントローラ）の記憶デバイスに格納することが可能となり、ネットワークカードモジュールおよび印刷装置本体の記憶デバイスをより効率的に利用できる。換言すれば、アプリケーションプログラムの機種依存性の有無によってアプリケーションプログラムの保存先を分散化することが可能となるため、共通モジュールであるネットワークカードに不必要なデータを保持する必要がなくなり、ネットワークカードモジュール側の記憶容量を削減できる。また別の観点からみた場合、機種依存のあるアプリケーションをネットワークカードモジュール側に保持しないことでユーザが誤って他の機種でしか動作しないアプリケーションプログラムを起動させてしまうといったミスを防止できるという効果も期待できる。なお、上記各実施形態で起動アプリケーションの変更や命令（関数）の変換には、例えばそれらを登録したテーブルを用いればよい。

さらにアプリケーションプログラムを実行する際にも、プログラム内の命令種別に応じて、命令処理をネットワークカードモジュール側、印刷装置本体側にそれぞれ分散化できるため命令処理の効率化が図れる。また、命令処理に関わる印刷装置本体の機種依存を含む固有情報をネットワークカードモジュールで保持する必要がなくなるため、ネットワークカードモジュール自身のプログラム容量を削減することが可能となる。また、将来新たな印刷装置本体が追加されてもネットワークカードモジュール側に改変を加える必要がなく、流用性の向上にも寄与する。

また別の観点からみた場合、機種依存のあるアプリケーションをネットワークカードモジュール（ネットワークプリントサーバ）側に保持しないので、ユーザが誤って他の機種でしか動作しないアプリケーションプログラムを起動させてしまうといったミスを防止できるという効果も期待できる。

以上説明したように、本発明によれば、移設時の不具合、さらにリソースの無駄を解決することができる。
また、本発明によれば、移設時に登録済みとなっているアプリケーションの中で不要なものを自動的に削除、自動更新処理を行うことで、さらにリソースの無駄を解消させることができる。
更に、本発明によれば、多少の機種依存部分の処理をネットワークモジュール側で行う、もしくはネットワークモジュールに接続された外部周辺装置を制御することにより、アプリケーションによってデータ処理装置に足りない新たな機能を追加することができる。

Claims (3)

1. データ処理装置に対して着脱可能であり、データ処理装置に装着されることにより当該データ処理装置とネットワークとを接続し、前記データ処理装置の機能の実行を指示するアプリケーションを実行することが可能なネットワーク装置であって、
   装着されたデータ処理装置が有する機能を示す機能情報を取得する取得手段と、
   前記取得手段で取得した機能情報に基づき、前記ネットワーク装置の記憶装置に格納されているアプリケーションの中から前記データ処理装置が有する機能に適合しないアプリケーションを抽出する抽出手段と、
   前記抽出手段で抽出されたアプリケーションを前記記憶装置から削除する削除手段とを備えることを特徴とするネットワーク装置。
2. 前記機能情報は、前記データ処理装置がカラーの機能を備えているかモノクロの機能を備えているかを示す情報を含むことを特徴とする、請求項１に記載のネットワーク装置。
3. データ処理装置に対して着脱可能であり、データ処理装置に装着されることにより当該データ処理装置とネットワークとを接続し、前記データ処理装置の機能の実行を指示するアプリケーションを実行することが可能なネットワーク装置の制御方法であって、
   装着されたデータ処理装置が有する機能を示す機能情報を取得する取得工程と、
   前記取得工程で取得した機能情報に基づき、前記ネットワーク装置の記憶装置に格納されているアプリケーションの中から前記データ処理装置が有する機能に適合しないアプリケーションを抽出する抽出工程と、
   前記抽出工程で抽出されたアプリケーションを前記記憶装置から削除する削除工程とを備えることを特徴とするネットワーク装置の制御方法。

Images