JP4616622B2 - 通信装置、通信制御方法、通信制御プログラム及び記録媒体 - Google Patents

Description

本発明は、通信装置、通信制御方法、通信制御プログラム及び記録媒体に関し、特に機器との通信を行う通信装置、通信制御方法、通信制御プログラム及び記録媒体に関する。

近年におけるプリンタ、ＦＡＸ、コピー機等の機器は、直接ネットワークに接続することが可能であり、機器の中にはネットワーク越しに当該機器の状態に関する情報や属性情報等の各種情報の提供が可能なものもある。

但し、サポートしているプロトコルが機器ごとに異なる場合があるため、複数の機器より情報を取得するアプリケーションは、それぞれの機器に対応したプロトコルによって各機器との通信を行う必要がある。

図１は、従来のアプリケーションとプロトコルとの関係を示す図である。図１において、アプリケーション５０１、アプリケーション５０２、及びアプリケーション５０３は、ソースコードを別にする別個のアプリケーションであるが、それぞれ機器から情報を取得する機能を有するものである。図１では、アプリケーション５０１、５０２及び５０３のそれぞれに、ＳＮＭＰｖ１、ＳＮＭＰｖ２、ＳＯＡＰ１．１、及びＳＯＡＰ１．２に対応した実装、すなわち、各プロトコルに対応したＡＰＩを呼び出すための実装がされていることが概念的に示されている。すなわち、従来は、アプリケーションごとに、各プロトコルに依存した処理が実装されていた。

しかしながら、図１のような形態では、ネットワーク上に新たに機器が追加された場合や、既存の機器のプロトコルがバージョンアップされた場合等、アプリケーション側で新たなプロトコルに対応する必要が生じた場合に、アプリケーションごとに新たなプロトコルに対応するための作業、すなわち、ソースコードの修正、コンパイル及びリンク等の作業が必要とされた。

かかる問題を回避する方法として、図２のような構成を採用することが一般的に考えられる。図２は、アプリケーションに対して共通化されたインタフェースを提供する層を設けた例を示す図である。

図２において、共通インタフェースモジュール５１１は、各プロトコルに依存した処理を吸収し、プロトコルごとに異なるＡＰＩを抽象化あるいは共通化した関数インタフェースを各アプリケーンに対して提供するためのモジュールである。したがって、アプリケーション５０１等の各アプリケーションは、共通インタフェースモジュール５１１によって提供される関数インタフェースを呼び出すことによってプロトコルの違いを意識することなく機器より情報を取得することができる。

なお、特許文献１には、機器ごとに異なるプロトコルを用いてそれぞれの機器より情報を取得するための発明が開示されている。
特開２０００−７６０３３号公報

しかしながら、図２のような構成を採用したとしても、新たなプロトコルに対応するためには、結局のところ共通インタフェースモジュール５１１のソースコードの修正、当該ソースコードのコンパイル及びリンク等の作業が必要とされる。

確かに、図２の場合は、共通インタフェースモジュール５１１のみを修正するだけでよいため、アプリケーションごとに修正を要する場合に比べ、作業負担の軽減が図られることになる。しかし、既存部分についてコンパイル及びリンク等を行うのはできるだけ避けたい。コンパイル及びリンク等を行うことにより、既存部分の品質が不安定となる場合があり、再度のテスト作業等が必要とされるからである。

本発明は、上記の点に鑑みてなされたものであって、新たなプロトコルによる通信に容易に対応することができる通信装置、通信制御方法、通信制御プログラム及び記録媒体の提供を目的とする。

そこで上記課題を解決するため、本発明は、通信可能な機器とネットワークを介して接続している通信装置であって、当該通信装置が対応しているプロトコルによる通信の可否を前記機器に問い合わせ、該問い合わせに対する前記機器からの応答に基づいて前記機器は該プロトコルによる通信は不可能であると判断した場合に、該プロトコルによって通信するための通信手段をネットワークを介して接続している外部装置よりダウンロードし、該通信手段を用いて前記機器と通信する通信管理手段を有することを特徴とする。

このような通信装置では、通信相手となる機器が対応しているプロトコルに対応していない場合であっても、外部装置より当該プロトコルによって通信するための通信手段を取得し、当該通信手段によって機器との通信を実現することができる。

また、上記課題を解決するため、本発明は、上記通信装置における通信制御方法、前記通信制御方法をコンピュータに実行させるための通信制御プログラム、又は前記通信制御プログラムを記録した記録媒体としてもよい。

本発明によれば、新たなプロトコルによる通信に容易に対応することができる通信装置、通信制御方法、通信制御プログラム及び記録媒体を提供することができる。

以下、図面に基づいて本発明の実施の形態を説明する。図３は、本発明の実施の形態における機器管理システムの構成例を示す図である。図３に示されるように本実施の形態における機器管理システム１は、機器管理サーバ１０と、ライブラリサーバ２０と、一台以上の画像形成装置（画像形成装置３１及び画像形成装置３２等）と、端末４０とがＬＡＮやインターネット等のネットワーク５０（有線又は無線の別は問わない。）を介して接続されることにより構成されている。

機器管理サーバ１０は、端末４０からの要求に応じて画像形成装置３１等の機器より当該機器の属性情報や状態情報等（以下、「機器情報」という。）を取得し、取得した情報を端末４０に対して提供するための機能が実装されているコンピュータである。

ライブラリサーバ２０は、それぞれ特定のプロトコルによって機器と通信するためのライブラリ（以下、「プロトコルモジュールライブラリ」という。）を複数管理しているコンピュータである。例えば、ライブラリサーバ２０は、ＳＮＭＰ（Simple Network Management Protocol）ｖ１用を始め、ＳＮＭＰｖ２用、ＳＮＭＰｖ３用、ＳＯＡＰ（Simple Object Access Protocol）１．１用及びＳＯＡＰ１．２用等のプロトコルモジュールライブラリを管理している。なお、プロトコルモジュールライブラリは、ＯＳ（Ｏｐｅｒａｔｉｏｎ Ｓｙｓｔｅｍ）のベンダ等より提供されている。

画像形成装置３１等は、機器の具体例であり、機器管理サーバ１０からの所定のプロトコルによる要求に応じて機器情報を提供することが可能である。

端末４０は、機器管理システム１のユーザが直接利用するＰＣ（Personal Computer）、ＰＤＡ（Personal Digital(Data) Assistants）、又は携帯電話等の端末である。端末４０には、機器管理サーバ１０の機能を利用するためのクライアントアプリケーションが実装されており、ユーザは、当該クライントアプリケーションを操作することによって、各機器の情報を確認することができる。

次に、機器管理サーバ１０の詳細について説明する。図４は、本発明の実施の形態における機器管理サーバのハードウェア構成例を示す図である。図４の機器管理サーバ１０は、それぞれバスBで相互に接続されているドライブ装置１００と、補助記憶装置１０２と、メモリ装置１０３と、演算処理装置１０４と、インタフェース装置１０５とを有するように構成される。

機器管理サーバ１０での処理を実現する機器管理プログラムは、CD―ROM等の記録媒体１０１によって提供される。機器管理プログラムを記録した記録媒体１０１がドライブ装置１００にセットされると、機器管理プログラムが記録媒体１０１からドライブ装置１００を介して補助記憶装置１０２にインストールされる。

補助記憶装置１０２は、インストールされた機器管理プログラムを格納すると共に、必要なファイルやデータ等を格納する。

メモリ装置１０３は、機器管理プログラムの起動指示があった場合に、補助記憶装置１０２から機器管理プログラムを読み出して格納する。演算処理装置１０４は、メモリ装置１０３に格納された機器管理プログラムに従って機器管理サーバ１０に係る機能を実行する。インタフェース装置１０５は例えばモデム、ルータ等で構成され、図３のネットワーク５０に接続するために用いられる。

図５は、機器管理サーバの機能構成例を示す図である。図５において、機器管理サーバ１０に実装されている機能は、アプリケーション層１１、共通インタフェース層１２、コントロール層１３及びプロトコル層１４の４つの層に分けることができる。

アプリケーション層１１は、端末４０におけるクライアントアプリケーション４１に対して各種サービスを提供するための各種アプリケーションが実装されている層である。本実施の形態においては、機器情報をクライアントアプリケーション４１に提供するためのアプリケーションとしてアプリケーション１１１ａ、１１１ｂ、及び１１１ｃ等が実装されている。

共通インタフェース層１２は、アプリケーション層１１の各アプリケーションがプロトコルを意識せずに機器情報を取得することができるよう、プロトコルごとに異なるＡＰＩを抽象化あるいは共通化した関数インタフェース（以下、「共通インタフェース」という。）をアプリケーション層１１に対して提供するための層である。本実施の形態においては、プロトコルモジュール管理手段１２１が共通インタフェースを提供するためのモジュールとして実装されている。プロトコルモジュール管理手段１２１は、アプリケーション層１１に対しては、共通インタフェースを提供するという役割を果たし、その共通インタフェースを介して、コントロール層１３におけるプロトコル毎のプロトコルモジュールライブラリの制御機能を提供する。なお、一つのプロトコルモジュール管理手段１２１は、アプリケーション層１１の各アプリケーションより共通的に利用される。

図６は、共通インタフェースのインタフェース仕様の例を示す図である。図６より、共通インタフェースのインタフェース名（関数名）は、「ＧｅｔＤｅｖｉｃｅ」であり、ａｄｄｒｅｓｓ、Ｃａｔｅｇｏｒｙ、及びＤａｔａの３つの引数が定義されていることが分かる。ａｄｄｒｅｓｓは、機器情報の取得先とする機器のＩＰアドレスを指定するための引数である。Ｃａｔｅｇｏｒｙは、取得する機器情報のカテゴリの名前（カテゴリ名）を指定するための引数である。Ｄａｔａは、機器より返却される情報が格納されるメモリ領域へのポインタを指定するための引数である。アプリケーションは、機器との通信がいかなるプロトコルで行われようとも、ＧｅｔＤｅｖｉｃｅ関数を呼び出せば目的とする機器情報を得ることができる。

機器情報のカテゴリについて説明する。図７に示されるように機器情報はいくつかのカテゴリに分類することができる。図７は、機器情報のカテゴリを説明するための図である。図７においては、表形式によって、各カテゴリのカテゴリ名と各カテゴリに属する情報とが示されている。図７より、例えば、機器情報のカテゴリとしては、給紙トレイに関する情報（給紙情報）、排紙トレイに関する情報（排紙情報）、サポートされているエミューレーションに関する情報（エミュレーション）、サポートされているフォントに関する情報（フォント）、ジョブに関する情報（ジョブ情報）、及びプロトコルのサポートの有無に関する情報（プロトコルサポート）等があることが分かる。また、給紙情報には、給紙トレイ名、用紙サイズ、及び状態等の情報が含まれることがわかる。

したがって、給紙情報を得たい場合には、ＧｅｔＤｅｖｉｃｅ関数のＣａｔｅｇｏｒｙ引数に「給紙情報」と指定すれば、Ｄａｔａ引数に給紙トレイ名、用紙サイズ、及び状態等の情報が返却されることになる。

図５に戻る。プロトコル層１４は、機器との通信において利用されるプロトコルに特化したＡＰＩが実装されている層であり、プロトコルの種別ごとにそれぞれのプロトコルに特化したプロトコルモジュールライブラリが実装されている。本実施の形態においては、ＳＮＭＰｖ１用のプロトコルモジュールライブラリであるプロトコルモジュールライブラリ１４１ａと、ＳＮＭＰｖ２用のプロトコルモジュールライブラリであるプロトコルモジュールライブラリ１４１ｂとが既に実装されている。なお、以下においてプロトコルモジュールライブラリ１４１ａ等を総称する場合、「プロトコルモジュールライブラリ１４１」という。

コントロール層１３は、プロトコル層１４と共通インタフェース層１２との仲介役としての役割を担う層であり、プロトコル層１４においてプロトコルごとに異なるＡＰＩをプロトコル間で共通化し、動的に呼び出すことが可能な（静的にリンクしていなくても実行時に呼び出すことが可能な）インタフェースを共通インタフェース層１２に対して提供するための層である。コントロール層１３における各モジュールは、プロトコル層１４におけるプロトコルモジュールライブラリ１４１に対応させて実装されており、本実施の形態においては、プロトコルモジュールライブラリ１４１ａに対するプロトコルモジュール制御手段１３１ａと、プロトコルモジュールライブラリ１４１ｂに対するプロトコルモジュール制御手段１３１ｂとが実装されている。なお、以下においてコントロール層１３における各モジュールを総称する場合、「プロトコルモジュール制御手段１３１」という。

プロトコルモジュール管理テーブル１２２及びプロトコル制御関数名一覧ファイル１２３は、プロトコルモジュール管理手段１２１が、プロトコルモジュール制御手段１３１を呼び出すために必要な情報を管理しているテーブル又はファイルである。

図８は、プロトコルモジュール管理テーブルの構成例を示す図である。図８に示されるように、プロトコルモジュール管理テーブル１２２は、機器管理サーバ１０が現在対応しているプロトコルの種別ごとにプロトコル名、プロトコルモジュール制御手段名、プロトコルモジュールライブラリ名及びプロトコル制御関数名一覧ファイル名等を管理している。

プロトコル名は、プロトコルの名前である。プロトコルモジュール制御手段名は、プロトコルモジュール制御手段１３１のファイル名（ＤＬＬ名）である。プロトコルモジュールライブラリ名は、プロトコルモジュールライブラリ１４１のファイル名（ＤＬＬ名）である。プロトコル制御関数名一覧ファイル名は、後述されるプロトコル制御関数名一覧ファイル１２３のファイル名である。

図９は、プロトコル制御関数名一覧ファイルに管理されている情報を説明するための図である。図９に示されるように、プロトコル制御関数名一覧ファイル１２３には機器情報のカテゴリごとに、カテゴリ名及び関数名等を管理している。なおプロトコル制御関数名一覧ファイル１２３は、プロトコルモジュール制御手段１３１ごとに定義されている。したがって、プロトコルモジュール制御手段１３１ごとに各カテゴリに対する関数名を異なるものとすることができる。但し、関数の戻り値の型や引数情報については共通化されたものに従う必要があり、その範囲内において各プロトコルモジュール制御手段１３１のインタフェースは共通化されているといえる。

プロトコルモジュール管理テーブル１２２及びプロトコル制御関数名一覧ファイル１２３を利用して、プロトコルモジュール管理手段１２１がどのようにしてプロトコルモジュール制御手段１３１を呼び出すかについて説明する。

図１０は、プロトコルモジュール管理手段がプロトコルモジュール制御手段を呼び出すためのソースコードの例を示す図である。すなわち、図１０に示されるソースコードは、プロトコルモジュール管理手段１２１におけるＧｅｔＤｅｖｉｃｅ関数内の処理の一部として実装されているものである。

呼び出す対象とするプロトコルモジュール制御手段１３１（以下、「カレントプロトコルモジュール制御手段」という。）のプロトコルモジュール制御手段名をプロトコルモジュール管理テーブル１２２より読み込み（Ｓ１１）、更に、カレントプロトコルモジュール制御手段に対応したプロトコル制御関数名一覧ファイル１２３よりＧｅｔＤｅｖｉｃｅ関数のＣａｔｅｇｏｒｙ引数に指定されたカテゴリに対する関数（以下、「カレント関数」という。）の関数名を取得する（Ｓ１２）。プロトコルモジュール制御手段１３１をロードし（Ｓ１３）、カレント関数のアドレスを取得した後（Ｓ１４）、カレント関数を呼び出す（Ｓ１５）。カレント関数を呼び出すことによってＧｅｔＤｅｖｉｃｅ関数のＤａｔａ引数に機器情報が格納され、ＧｅｔＤｅｖｉｃｅ関数の呼び出し元、すなわち、アプリケーション１１１ａ等は、機器情報を取得することができる。

このように、プロトコルモジュール管理手段１２１のソースコードにおいては、プロトコルモジュール制御手段１３１の呼び出しが静的に記述されておらず、プロトコルモジュール管理テーブル１２２及びプロトコル制御関数名一覧ファイル１２３の定義にしたがって動的に呼び出すことが可能となっている。したがって、各プロトコルモジュール制御手段１３１のインタフェースの呼び出しは、図に示されるような共通化された手順によって行うことができる。また、プロトコルモジュール管理テーブル１２２を変更するだけで、プロトコルモジュール管理手段１２１のソースコードを修正することなく、呼び出す対象とするプロトコルモジュール制御手段１３１を変更することができる。

図５に戻る。アクセス手順情報１３２ａやアクセス手順情報１３２ｂ（以下、総称する場合「アクセス手順情報１３２」という。）は、プロトコルモジュール制御手段１３１がプロトコルモジュールライブラリ１４１を呼び出すために必要な情報が定義されている情報である。図１１は、アクセス手順情報の構成例を示す図である。図１１に示されるように、アクセス制御手順情報１３２には、機器情報のカテゴリに属する情報ごとに当該情報をプロトコルモジュールライブラリ１４１が識別するための文字列が定義されている。例えば、給紙情報に属する給紙トレイ名を取得する場合は、「ｐｒｔＩｎｐｕｔＮａｍｅ」という文字列をプロトコルモジュールライブラリ１４１のＡＰＩの引数に指定すればよいことが分かる。

次に、ライブラリサーバ２０について説明する。図１２は、ライブラリサーバにおけるプロトコルモジュールライブラリの管理形態を説明するための図である。図１２に示されるように、ライブラリサーバ２０は、パッケージ一覧テーブル２１と、複数のプロトコルモジュールパッケージ（プロトコルモジュールパッケージ２２１、２２２及び２２３等）を管理している。

プロトコルモジュールパッケージは、プロトコルの種別ごとにプロトコルモジュール制御手段１３１、プロトコルモジュールライブラリ１４１、プロトコル制御関数名一覧ファイル１２３及びアクセス手順情報１３２を一つの圧縮ファイルにまとめたものである。

パッケージ一覧テーブル２１は、ライブラリサーバ２０において管理されているプロトコルモジュールパッケージの一覧情報を管理するテーブルである。図１３は、パッケージ一覧テーブルの構成例を示す図である。

図１３に示されるように、パッケージ一覧テーブル２１は、ライブラリ管理サーバ２０において管理されている各プロトコルモジュールパッケージ２２１について、プロトコル名、ポート番号、パッケージ名及びパッケージ構成等を管理している。

プロトコル名は、プロトコルモジュールパッケージが対応しているプロトコルの名前である。ポート番号は、当該プロトコルのポート番号である。パッケージ名は、プロトコルモジュールパッケージの名前（ファイル名）である。パッケージ構成は、プロトコルモジュールパッケージに含まれているプロトコルモジュール制御手段１３１、プロトコルモジュールライブラリ１４１、プロトコル制御関数名一覧ファイル１２３、及びアクセス手順情報１３２等の名前の集合である。

以下、図５の機器管理サーバの処理手順について説明する。図１４は、機器管理サーバによる画像形成装置からの機器情報の取得処理を説明するためのシーケンス図である。

ステップＳ１０１においてアプリケーション１１１ａが、クライアントアプリケーション４１からの要求に応じて、機器情報を取得すべくプロトコルモジュール管理手段１２１のＧｅｔＤｅｖｉｃｅ関数を呼び出す。ここでは、画像形成装置３１の「給紙情報」が要求されたものとする。

ステップＳ１０１に続いて、プロトコルモジュール管理手段１２１は、プロトコルモジュール管理テーブル１２２に登録されているそれぞれのプロトコルモジュール制御手段１３１に対して、画像形成装置３１がそれぞれのプロトコルをサポートしているか否かの確認を要求する。

すなわち、プロトコルモジュール管理手段１２１は、各プロトコルモジュール制御手段１３１のプロトコルモジュール制御手段名（ＤＬＬ名）をプロトコルモジュール管理テーブル１２２を参照して特定し、さらに、各プロトコルモジュール制御手段１３１においてプロトコルのサポートを確認するための関数（以下、「サポート確認関数」という。）の関数名をそれぞれのプロトコル制御関数名一覧ファイル１２３を参照して特定して（Ｓ１０２）、図１０において説明した手順によって各プロトコルモジュール制御手段１３１のサポート確認関数を呼び出す（Ｓ１０３）。

例えば、プロトコル制御関数名一覧ファイル１２３が図９のように定義されている場合は、サポート確認関数の関数名は、「ＧｅｔＳｕｐｐｏｒｔＰｒｏｔｏｃｏｌ」と特定することができる。

なお、各プロトコルモジュール制御手段１３１のサポート確認関数の呼び出しは、それぞれ別スレッドとして並列に実行される。

ステップＳ１０３に続いてステップＳ１０４に進み、各プロトコルモジュール制御手段１３１は、それぞれ対応しているプロトコルモジュールライブラリ１４１に対してプロトコルのサポートの確認を要求する。プロトコルモジュールライブラリ１４１が、画像形成装置３１に対してプロトコルのサポートを確認するためのパケットを送信すると、当該パケットに対する応答としてサポートの有無についての情報が画像形成装置３１より返信される（Ｓ１０６）。サポートの有無は、プロトコルモジュールライブラリ１４１を経て、サポート確認関数の返却情報としてプロトコルモジュール制御手段１３１よりプロトコルモジュール管理手段１２１に対して通知される（Ｓ１０７、Ｓ１０８）。

それぞれ別スレッドにおいて呼び出した全てのプロトコルモジュール制御手段１３１からサポートの有無が通知されると、ステップＳ１０９に進み、プロトコルモジュール管理手段１２１は、現在機器管理サーバ１０が対応しているプロトコルの中で、画像形成装置３１においてもサポートされているものがあるか否かを判断する。

ここで、サポートされている旨を返却したプロトコル制御手段１３１があれば、プロトコル管理手段１２１は、後述するステップＳ１１８以降の処理によって、当該プロトコル制御手段１３１を利用して画像形成装置３１より機器情報（給紙情報）を取得する。

一方、全てのプロトコルモジュール制御手段１３１がサポートされていない旨を返却した場合、すなわち、このままでは画像形成装置３１より機器情報を取得することが不可能な場合は、ステップＳ１１０に進み、プロトコルモジュール管理手段１２１は、ライブラリサーバ２０に対して、パッケージ一覧テーブル２１（図１３）に管理されている情報（以下、「パッケージ一覧情報」という。）の送信を要求する。

ステップＳ１１０に続いてステップＳ１１１に進み、プロトコルモジュール管理手段１２１からの要求に応じ、パッケージ一覧情報がライブラリサーバ２０より返信される。

ステップＳ１１１に続いて、プロトコルモジュール管理手段１２１は、パッケージ一覧情報に含まれているそれぞれのプロトコルのポート番号に基づいてポートスキャンを実行し、画像形成装置３１において開いているポートを検出することにより、画像形成装置３１がサポートしているプロトコルを判断する（Ｓ１１２、Ｓ１１３、Ｓ１１４）。全てのポートについてポートスキャンをするのではなく、実際に利用しうるポートについてのみポートスキャンを実行することにより処理効率の向上を図ることができる。

画像形成装置３１がサポートしているプロトコル（以下、「サポートプロトコル」という。）を判断できた場合は、ステップＳ１１５に進み、プロトコルモジュール管理手段１２１は、パッケージ一覧情報に基づいてサポートプロトコルに対応したプロトコルモジュールパッケージ（以下、「サポートパッケージ」という。）のパッケージ名を特定し、ライブラリサーバ２０に対してサポートパッケージの提供を要求することにより、サポートパッケージをライブラリサーバ２０よりダウンロードする（Ｓ１１６）。

ステップＳ１１６に続いてステップＳ１１７に進み、プロトコルモジュール管理手段１２１は、サポートパッケージを機器管理サーバ１０に適用する。具体的には、サポートパッケージが解凍され、サポートパッケージに含まれているプロトコルモジュール制御手段１３１、プロトコルモジュールライブラリ１４１、プロトコル制御関数名一覧ファイル１２３、及びアクセス手順情報１３２が、所定のフォルダに配置される。ここで所定のフォルダとは、サポートパッケージに含まれている各ファイルが、機器管理サーバ１０の処理の実行時に配置されるべきフォルダである。したがって、各ファイルが所定のフォルダに配置されることにより、これらのファイルが実行時に利用可能となる。更に、サポートパッケージに含まれていたプロトコルモジュール制御手段１３１等の情報がプロトコルモジュール管理テーブル１２２に追加される。

図１５は、更新されたプロトコルモジュール管理テーブルの例を示す図である。図１５においては、ＳＮＭＰｖ３に対するプロトコルモジュールパッケージが新たに適用された場合の例を示している。３行名のレコードが新たに追加されたものに該当する。

ステップＳ１１７に続いてステップＳ１１８に進み、プロトコルモジュール管理手段１２１は、新たに適用されたプロトコルモジュール制御手段１３１に実装されている、給紙情報を取得するための関数（以下、「給紙情報取得関数」）を呼び出すことにより、給紙情報の取得をプロトコルモジュール制御手段１３１に要求する。

詳しくは、プロトコルモジュール管理手段１２１は、更新されたプロトコルモジュール管理テーブル１２２（図１５）を参照して、新たに追加されたプロトコルモジュール制御手段１３１のプロトコルモジュール制御手段名（ＤＬＬ名）及びプロトコル制御関数一覧ファイル名を特定し、更に、当該プロトコル制御関数一覧ファイル名によって特定されるプロトコル制御関数一覧ファイル１２３より、給紙情報カテゴリに対応づけられている関数名（図９においては「ＧｅｔＩｎｔｒａｙＩｎｆｏ」）を取得することにより給紙情報取得関数の関数名を特定する。

そして、特定されたプロトコルモジュール制御手段名と給紙情報取得関数の関数名に基づいて図１０において説明した処理を実行し、給紙情報取得関数を呼び出す。

ステップＳ１１８に続いてステップステップＳ１１９に進み、プロトコルモジュール制御手段１３１は、アクセス手順情報１３２に基づいてプロトコルモジュールライブラリ１４１に対して給紙情報を要求する。

ステップＳ１１９に続いてステップＳ１２０に進み、プロトコルモジュールライブラリ１４１は、対応しているプロトコル（ここでは、「ＳＮＭＰｖ３」）によって画像形成装置３１と通信することにより、画像形成装置３１より給紙情報を取得する（Ｓ１３１）。給紙情報は、プロトコルモジュール制御手段１３１及びプロトコルモジュール管理手段１２１を経て（Ｓ１２２、Ｓ１２３）、ＧｅｔＤｅｖｉｃｅ関数の返却情報としてアプリケーション１１１ａに返却される（Ｓ１２４）。

上述したように、本実施の形態における機器管理サーバ１０によれば、プロトコルモジュール管理手段１２１は、機器がサポートしているプロトコルを判断し、当該プロトコルに対応したプロトコルモジュールパッケージをライブラリサーバ２０よりダウンロードする。ここで、プロトコルモジュール管理手段１２１は、プロトコルモジュール管理テーブル１２２を変更することにより呼び出す対象とするプロトコルモジュール制御手段１３１を変更することができる。したがって、通信相手となる機器がサポートしているプロトコルに機器管理サーバ１０が対応していない場合であっても、必要なモジュールを獲得し、プロトコルモジュール管理手段１２１のソースコードの修正等を要することなく簡便な処理によって当該モジュールを利用可能とすることができる。

一度利用可能としたプロトコルについては、その情報がプロトコルモジュール管理手段１２１に登録されるため、再度当該プロトコルによって通信する必要が生じた場合は、ダウンロード等の処理を繰り返す必要はない。

また、プロトコルモジュール管理手段１２１は、プロトコルの別に関係なく共通化されたインタフェース（ＧｅｔＤｅｖｉｃｅ関数）によって各アプリケーションからの要求を受け付けることができる。したがって、各アプリケーションについても新たなプロトコルに対応に応じてソースコード等の修正を行う必要は無い。

なお、本実施の形態においては、ライブラリサーバ２０というプロトコルモジュールパッケージの管理を専門に行うサーバを立てた例について説明したが、プロトコルモジュールパッケージは、それぞれの機器に管理させるようにしてもよい。この場合、機器管理サーバ１０は、通信相手となる機器よりＦＴＰ等によって当該機器に対応したプロトコルモジュールパッケージをダウンロードすればよい。

ところで、近年においては、ある特定の機能に特化した組み込み機器においてもＷｅｂサーバとして機能するもの等、コンピュータと同等の情報処理を実行することができるものが提供されている。例えば、融合機、又は複合機と呼ばれる、プリンタ、コピー、又はファクシミリ等の複合サービスに固有の処理を行う複数のアプリケーションを有する画像形成装置もかかる機器に該当する。

したがって、このような画像形成装置を用いて、本実施の形態における機器管理サーバ１０を構成しても本発明の効果を同様に得ることができる。例えば、図１６は、機器管理サーバに画像形成装置を用いて構成した機器管理システムの構成例を示す図である。図１６中、図５と同一部分には同一符号を付し、その説明は省略する。図１６において、操作パネル６１は、画像形成装置６０における各種のアプリケーション１１１ａ〜１１１ｃ等に対する操作手段をユーザに提供する、例えば、液晶画面を有するパネルである。図１６に示される機器管理システムにおいては、機器管理サーバ１０の代わりに画像形成装置６０が構成要素となっている。そして、画像形成装置６０には、機器管理サーバ１０に実装されていたものと同様の機能が実装されている。したがって、画像形成装置６０は、画像形成装置３１等の他の画像形成装置との通信に必要なプロトコルに自動的に対応することができ、当該プロトコルに基づく通信によって、他の画像形成装置の機器情報を操作パネル６１に表示させることができる。

以上、本発明の好ましい実施例について詳述したが、本発明は係る特定の実施形態に限定されるものではなく、特許請求の範囲に記載された本発明の要旨の範囲内において、種々の変形・変更が可能である。

従来のアプリケーションとプロトコルとの関係を示す図である。 アプリケーションに対して共通化されたインタフェースを提供する層を設けた例を示す図である。 本発明の実施の形態における機器管理システムの構成例を示す図である。 本発明の実施の形態における機器管理サーバのハードウェア構成例を示す図である。 機器管理サーバの機能構成例を示す図である。 共通インタフェースのインタフェース仕様の例を示す図である。 機器情報のカテゴリを説明するための図である。 プロトコルモジュール管理テーブルの構成例を示す図である。 プロトコル制御関数名一覧ファイルに管理されている情報を説明するための図である。 プロトコルモジュール管理手段がプロトコルモジュール制御手段を呼び出すためのソースコードの例を示す図である。 アクセス手順情報の構成例を示す図である。 ライブラリサーバにおけるプロトコルライブラリの管理形態を説明するための図である。 パッケージ一覧テーブルの構成例を示す図である。 機器管理サーバによる画像形成装置からの機器情報の取得処理を説明するためのシーケンス図である。 更新されたプロトコルモジュール管理テーブルの例を示す図である。 機器管理サーバに画像形成装置を用いて構成した機器管理システムの構成例を示す図である。

符号の説明

１ 機器管理システム
１０ 機器管理サーバ
２０ ライブラリサーバ
２１ パッケージ一覧テーブル
２２１ プロトコルモジュールパッケージ
３１、３２、６０ 画像形成装置
４０ 端末
４１ クライアントアプリケーション
５０ ネットワーク
１００ ドライブ装置
１０１ 記録媒体
１０２ 補助記憶装置
１０３ メモリ装置
１０４ 演算処理装置
１０５ インタフェース装置
１１１ａ、１１１ｂ、１１１ｃ アプリケーション
１２１ プロトコルモジュール管理手段
１２２ プロトコルモジュール管理テーブル
１２３ プロトコル制御関数名一覧ファイル
１３１、１３１ａ、１３１ｂ プロトコルモジュール制御手段
１３２、１３２ａ、１３２ｂ アクセス手順情報
１４１、１４１ａ、１４１ｂ プロトコルモジュールライブラリ
５０１、５０２、５０３ アプリケーション
５１１ 共通インタフェースモジュール
Ｂ バス

Claims (14)

1. 通信可能な機器とネットワークを介して接続している通信装置であって、
   複数の前記機器が利用するプロトコルの種別に対して共通の第一のインタフェースを介して機器情報の取得要求を受け付ける通信管理手段と、
   前記プロトコルごとに当該プロトコルに特化した第二のインタフェースを介して機器情報の取得要求を受け付け、当該プロトコルに基づいて前記機器との通信を行うプロトコル手段と、
   前記プロトコル手段ごとに対応し、前記プロトコルの種別に対して共通化された第三のインタフェースを介して機器情報の取得要求を前記通信管理手段より受け付け、対応する前記プロトコル手段に機器情報の取得要求を行う制御手段とを有し、
   前記通信管理手段は、機器情報の取得要求に応じ、該取得要求に係る前記機器に対してポートスキャンを実行することにより該機器の対応しているプロトコルを判断し、該機器が対応しているプロトコルに係る前記プロトコル手段及び該プロトコル手段に対応する前記制御手段として当該通信装置を機能させるためのプログラムを外部装置よりダウンロードし、当該プログラムが機能させる前記制御手段及び前記プロトコル手段を用いて前記機器より機器情報を取得する通信装置。
2. 前記通信管理手段は、機器情報の取得要求に応じ、それぞれの前記制御手段及び前記プロトコル手段を介して、該プロトコル手段が対応するプロトコルによる通信の可否を該取得要求に係る前記機器に問い合わせ、該問い合わせに対する前記機器からの応答に基づいて該プロトコルによる前記機器との通信は不可能であると判断した場合に、前記ポートスキャンを実行する請求項１記載の通信装置。
3. 前記外部装置は、それぞれ異なるプロトコルに対応した複数の前記プログラムを管理しており、
   前記通信管理手段は、前記外部装置が管理している前記複数のプログラムの一覧情報を前記外部装置より取得し、該一覧情報において前記複数のプログラムのそれぞれに応じて示されているポート番号に基づいて前記機器に対してポートスキャンを実行する請求項１又は２記載の通信装置。
4. 当該通信装置が有する前記制御手段及び前記プロトコル手段の一覧情報を管理する通信手段一覧管理手段とを有し、
   前記通信管理手段は、前記通信手段一覧管理手段に管理されている前記一覧情報に登録されている前記制御手段及び前記プロトコル手段を介して、該プロトコル手段が対応するプロトコルによる通信の可否を前記機器に問い合わせ、
   前記通信管理手段は、前記外部装置よりダウンロードしたプログラムが機能させる前記制御手段及び前記プロトコル手段を前記一覧情報に追加する請求項１乃至３いずれか一項記載の通信装置。
5. ネットワークを介して接続しているクライアント装置からの要求に応じ、前記機器情報を前記クライアント装置に送信する機器情報提供手段を有し、
   前記機器情報提供手段は、前記第一のインタフェースを介して前記通信管理手段に前記機器情報の取得を要求する請求項１乃至４いずれか一項記載の通信装置。
6. 複数の前記機器情報提供手段を有し、
   前記通信管理手段は、前記複数の機器情報提供手段より共通的に利用される請求項５記載の通信装置。
7. 通信可能な機器とネットワークを介して接続している通信装置が実行する通信制御方法であって、
   複数の前記機器が利用するプロトコルの種別に対して共通の第一のインタフェースを介して機器情報の取得要求を受け付ける通信管理手順と、
   前記プロトコルごとに当該プロトコルに特化した第二のインタフェースを介して機器情報の取得要求を受け付け、当該プロトコルに基づいて前記機器との通信を行うプロトコル手順と、
   前記プロトコル手順ごとに対応し、前記プロトコルの種別に対して共通化された第三のインタフェースを介して機器情報の取得要求を前記通信管理手順より受け付け、対応する前記プロトコル手順に機器情報の取得要求を行う制御手順とを有し、
   前記通信管理手順は、機器情報の取得要求に応じ、該取得要求に係る前記機器に対してポートスキャンを実行することにより該機器の対応しているプロトコルを判断し、該機器が対応しているプロトコルに係る前記プロトコル手順及び該プロトコル手順に対応する前記制御手順を当該通信装置に実行させるプログラムを外部装置よりダウンロードし、当該プログラムが実行させる前記制御手順及び前記プロトコル手順を用いて前記機器より機器情報を取得する通信制御方法。
8. 通信可能な機器とネットワークを介して接続している通信装置を、
   複数の前記機器が利用するプロトコルの種別に対して共通の第一のインタフェースを介して機器情報の取得要求を受け付ける通信管理手段と、
   前記プロトコルごとに当該プロトコルに特化した第二のインタフェースを介して機器情報の取得要求を受け付け、当該プロトコルに基づいて前記機器との通信を行うプロトコル手段と、
   前記プロトコル手段ごとに対応し、前記プロトコルの種別に対して共通化された第三のインタフェースを介して機器情報の取得要求を前記通信管理手段より受け付け、対応する前記プロトコル手段に機器情報の取得要求を行う制御手段として機能させ、
   前記通信管理手段は、機器情報の取得要求に応じ、該取得要求に係る前記機器に対してポートスキャンを実行することにより該機器の対応しているプロトコルを判断し、該機器が対応しているプロトコルに係る前記プロトコル手段及び該プロトコル手段に対応する前記制御手段として当該通信装置を機能させるためのプログラムを外部装置よりダウンロードし、当該プログラムが機能させる前記制御手段及び前記プロトコル手段を用いて前記機器より機器情報を取得する通信制御プログラム。
9. 前記通信管理手段は、機器情報の取得要求に応じ、それぞれの前記制御手段及び前記プロトコル手段を介して、該プロトコル手段が対応するプロトコルによる通信の可否を該取得要求に係る前記機器に問い合わせ、該問い合わせに対する前記機器からの応答に基づいて該プロトコルによる前記機器との通信は不可能であると判断した場合に、前記ポートスキャンを実行する請求項８記載の通信制御プログラム。
10. 前記外部装置は、それぞれ異なるプロトコルに対応した複数の前記プログラムを管理しており、
    前記通信管理手段は、前記外部装置が管理している前記複数のプログラムの一覧情報を前記外部装置より取得し、該一覧情報において前記複数のプログラムのそれぞれに応じて示されているポート番号に基づいて前記機器に対してポートスキャンを実行する請求項９記載の通信制御プログラム。
11. 当該通信装置が有する前記制御手段及び前記プロトコル手段の一覧情報を管理する通信手段一覧管理手段とを有し、
    前記通信管理手段は、前記通信手段一覧管理手段に管理されている前記一覧情報に登録されている前記制御手段及び前記プロトコル手段を介して、該プロトコル手段が対応するプロトコルによる通信の可否を前記機器に問い合わせ、
    前記通信管理手段は、前記外部装置よりダウンロードしたプログラムが機能させる前記制御手段及び前記プロトコル手段を前記一覧情報に追加する請求項８乃至１０いずれか一項記載の通信制御プログラム。
12. ネットワークを介して接続しているクライアント装置からの要求に応じ、前記機器情報を前記クライアント装置に送信する機器情報提供手段を有し、
    前記機器情報提供手段は、前記第一のインタフェースを介して前記通信管理手段に前記機器情報の取得を要求する請求項８乃至１１いずれか一項記載の通信制御プログラム。
13. 複数の前記機器情報提供手段を有し、
    前記通信管理手段は、前記複数の機器情報提供手段より共通的に利用される請求項１２記載の通信制御プログラム。
14. 請求項８乃至１３いずれか一項記載の通信制御プログラムを記録したコンピュータ読み取り可能な記録媒体。
    

Images