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

Description

本発明は、通信制御装置及び通信制御方法に関し、特に、同一の通信機器と複数のプロトコルを用いて通信可能な通信制御装置、通信制御方法、通信制御プログラム及び記憶媒体に関するものである。

PC（Personal Computer）からネットワークに接続された機器をネットワーク経由で機器の状態監視、機器への設定制御、機器の情報取得を行う手段として、ＳＮＭＰ（Simple Network Management Protocol）プロトコルを使って通信制御を行っていた。また最近では、ＳＮＭＰ以外のプロトコルでも、機器の状態監視、機器への設定制御、機器の情報取得を行う手段ができるようになった。例えば、PCからネットワークに接続された機器の情報を機器管理ソフトなどを用いて取得する場合、ＳＯＡＰ（Simple Object Access Protocol）のようにＸＭＬ（Extensible Markup Language）形式のメッセージを用いて機器の情報を取得できる（例えば、特許文献１を参照）。

また、同一出願人より、通信可能な機器とネットワークを介して接続している通信制御装置であって、当該通信制御装置が対応しているプロトコルによる通信の可否を前記機器に問い合わせ、該問い合わせに対する前記機器からの応答に基づいて前記機器は該プロトコルによる通信は不可能であると判断した場合に、該プロトコルによって通信するための通信手段をネットワークを介して接続している外部装置よりダウンロードし、該通信手段を用いて前記機器と通信する通信管理手段を有する通信制御装置について提案されている（例えば、特許文献２を参照）。
特開２００４−５３７０９１号公報 特開２００５−２０４２７９号公報

しかしながら、従来の方法では、アプリケーションがある機器に取得設定したい情報項目にアクセスする際、どのプロトコルで通信制御を行えば良いかが分からないといった問題があった。

また、特許文献２に開示されている従来技術は、プロトコルによる通信は不可能であると判断した場合に、通信手段を、ネットワークを介して接続している外部装置よりダウンロードしなければならず、制御が複雑で且つダウンロードするために処理に時間を要するといった問題がある。

また、特許文献１に開示されているＸＭＬ形式のメッセージを用いて機器の情報を取得する場合、その記述内容を定義できるものの、ＸＭＬデータの内容がメーカー依存であったり、機種依存であったりと言うように、その共通性は必ずしも担保されたものにはなっていない。

また、データが文字列である場合、ＳＯＡＰを用いて機器情報を取得するときのＸＭＬデータファイルは基本的にＵＴＦ−８（8-bit UCS Transformation Format）コードであるが、ＳＮＭＰの場合は言語毎のキャラクターコード（日本語の場合はＳｈｉｆｔ−ＪＩＳ）が使われると言うように、機器情報を取得するためのプロトコルによっては扱う文字コードの体系もプロトコル依存である。そのため、対応するプロトコルが増えるに従い、文字コードの違いも意識しなければならない。

本発明では、上記従来技術の問題点を鑑み、機器との通信を行う際に、アプリケーションプログラムの負担を軽減することができる通信制御装置、通信制御方法、通信制御プログラム及び記憶媒体を提供することを目的とする。

本発明は、係る課題を解決するために、同一通信機器と複数のプロトコルを用いて通信する通信制御装置であって、前記通信機器から取得可能な機器情報を識別する情報ＩＤ及び前記通信機器にアクセスする際の手順を示すアクセス手順が、プロトコルごとに対応付けて定義されているプロトコル情報ＩＤ定義ファイルと、同一機器情報を取得可能な各プロトコルを識別する複数のプロトコル識別子、各プロトコルに対応する複数の前記情報ＩＤ、及び複数の前記情報ＩＤを各プロトコルで共通化し１つのＩＤで示す共通情報ＩＤが、前記機器情報ごとに対応付けて定義されている共通情報ＩＤ定義ファイルと、同一機器情報を取得可能な各プロトコルを識別する複数のプロトコル識別子、各プロトコルに対応する複数の前記情報ＩＤ、前記情報ＩＤに基づき取得される機器情報値、及びプロトコルごとに異なる前記機器情報値を各プロトコルで共通化し１つの値で示す統一値が、前記機器情報ごとに対応付けて定義されているデータタイプ変換用データファイルと、処理の実行指示に従って、前記通信機器との通信処理を行う各プロトコルに対応する通信モジュールを制御する通信制御手段と、アプリケーションから前記機器情報の取得が要求されると、前記プロトコル情報ＩＤ定義ファイル及び／又は前記共通情報ＩＤ定義ファイルの定義情報に基づき、前記通信制御手段に対し、処理の実行を指示する情報制御手段と、前記通信機器から前記機器情報が取得されると、前記データタイプ変換用データファイルの定義情報に基づき、前記通信機器から取得された、プロトコルごとに異なる機器情報値を、統一された値に変換するデータタイプ変換手段と、を有し、前記情報制御手段は、前記共通情報ＩＤファイルを参照し、情報取得要求時に前記アプリケーションから受け取った共通情報ＩＤが存在するか否かを判定し、存在すると判定された場合に、前記共通情報ＩＤファイルから、前記共通情報ＩＤに対応付けて定義されている前記プロトコル識別子及び前記情報ＩＤを取得し、取得したプロトコル識別子に基づき特定された前記プロトコル情報ＩＤ定義ファイルを参照し、取得した情報ＩＤが存在するか否かを判定し、存在すると判定された場合に、前記プロトコル情報ＩＤ定義ファイルから、前記情報ＩＤに対応付けて定義されている前記アクセス手順を取得し、前記通信制御手段は、前記情報制御手段により取得されたアクセス手順に従って、前記通信機器との通信処理を行い、前記アプリケーションから要求された機器情報を取得し、前記データタイプ変換手段に対し、取得した機器情報を通知し、前記データタイプ変換手段は、前記共通情報ＩＤ定義ファイルを参照し、前記アプリケーションから受け取った共通情報ＩＤに基づき、前記共通情報ＩＤファイルから、前記共通情報ＩＤに対応付けて定義されている前記プロトコル識別子及び前記情報ＩＤを取得し、前記データタイプ変換用データファイルを参照し、取得したプロトコル識別子及び情報ＩＤに対応付けて定義されている前記機器情報値と一致する、前記通信制御手段により取得された機器情報の取得値を、該取得値と一致する前記機器情報値に対応付けて定義されている前記統一値に変換し、変換された機器情報が、前記アプリケーションに通知されることを特徴とする。

これによって、本発明の通信制御装置は、通信制御インタフェース、共通情報ＩＤ制御部、共通情報ＩＤＸＭＬファイル、プロトコル制御部、プロトコル情報ＩＤＸＭＬファイル及び通信ライブラリを備えて構成されるので、アプリケーションがプロトコルを意識させないで、機器との通信制御を行うことができる。

よって、機器との通信を行う際に、アプリケーションプログラムの負担を軽減することができる。

また、本発明は、係る課題を解決するために、同一通信機器と複数のプロトコルを用いて通信する通信制御装置における通信制御方法であって、処理の実行指示に従って、前記通信機器との通信処理を行う各プロトコルに対応する通信モジュールを制御する通信制御ステップと、アプリケーションから前記機器情報の取得が要求されると、前記通信機器から取得可能な機器情報を識別する情報ＩＤ及び前記通信機器にアクセスする際の手順を示すアクセス手順が、プロトコルごとに対応付けて定義されているプロトコル情報ＩＤ定義ファイル、及び／又は、同一機器情報を取得可能な各プロトコルを識別する複数のプロトコル識別子、各プロトコルに対応する複数の前記情報ＩＤ、及び複数の前記情報ＩＤを各プロトコルで共通化し１つのＩＤで示す共通情報ＩＤが、前記機器情報ごとに対応付けて定義されている共通情報ＩＤ定義ファイルの定義情報に基づき、前記通信制御ステップの処理の実行を指示する情報制御ステップと、前記通信機器から前記機器情報が取得されると、同一機器情報を取得可能な各プロトコルを識別する複数のプロトコル識別子、各プロトコルに対応する複数の前記情報ＩＤ、前記情報ＩＤに基づき取得される機器情報値、及びプロトコルごとに異なる前記機器情報値を各プロトコルで共通化し１つの値で示す統一値が、前記機器情報ごとに対応付けて定義されているデータタイプ変換用データファイルの定義情報に基づき、前記通信機器から取得された、プロトコルごとに異なる機器情報値を、統一された値に変換するデータタイプ変換ステップと、を有し、前記情報制御ステップは、前記共通情報ＩＤファイルを参照し、情報取得要求時に前記アプリケーションから受け取った共通情報ＩＤが存在するか否かを判定し、存在すると判定された場合に、前記共通情報ＩＤファイルから、前記共通情報ＩＤに対応付けて定義されている前記プロトコル識別子及び前記情報ＩＤを取得し、取得したプロトコル識別子に基づき特定された前記プロトコル情報ＩＤ定義ファイルを参照し、取得した情報ＩＤが存在するか否かを判定し、存在すると判定された場合に、前記プロトコル情報ＩＤ定義ファイルから、前記情報ＩＤに対応付けて定義されている前記アクセス手順を取得し、前記通信制御ステップは、前記情報制御ステップにより取得されたアクセス手順に従って、前記通信機器との通信処理を行い、前記アプリケーションから要求された機器情報を取得し、前記データタイプ変換ステップは、前記共通情報ＩＤ定義ファイルを参照し、前記アプリケーションから受け取った共通情報ＩＤに基づき、前記共通情報ＩＤファイルから、前記共通情報ＩＤに対応付けて定義されている前記プロトコル識別子及び前記情報ＩＤを取得し、前記データタイプ変換用データファイルを参照し、取得したプロトコル識別子及び情報ＩＤに対応付けて定義されている前記機器情報値と一致する、前記通信制御ステップにより取得された機器情報の取得値を、該取得値と一致する前記機器情報値に対応付けて定義されている前記統一値に変換し、変換された機器情報が、前記アプリケーションに通知されることを特徴とする。

また、本発明は、上記通信制御方法をコンピュータが制御可能にプログラミングしたことを特徴とする。

これによって、本発明の通信制御プログラムは、本発明の通信制御方法をコンピュータが制御可能なＯＳに従ってプログラミングすることにより、そのＯＳを備えたコンピュータであれば同じ処理方法により制御することができる。

また、本発明は、上記通信制御プログラムをコンピュータが読み取り可能な形式で格納したことを特徴とする。

これによって、本発明の通信制御プログラムを格納した記憶媒体は、通信制御プログラムをコンピュータが読み取り可能な形式で記憶媒体に格納することにより、この記憶媒体を持ち運ぶことにより何処でもプログラムを稼動することができる。

本発明によれば、機器との通信を行う際に、アプリケーションプログラムの負担を軽減することができる通信制御装置、通信制御方法、通信制御プログラム及び記憶媒体を提供することができる。

以下、本発明の好適な実施の形態について、図面を用いて詳細に説明する。

図１は、本発明の実施例１に係るネットワークシステムの一例を示している。

このネットワークシステムは、複数の情報処理装置ＷＳ１〜ＷＳｎ、及び、複数の画像形成装置ＭＦＰ１〜ＭＦＰｎが、ローカルエリアネットワークＬＡＮを介して接続されている。

画像形成装置ＭＦＰ１〜ＭＦＰｎは、通信制御装置を備え、ネットワークスキャナ機能、ネットワークプリンタ機能及び複写機能などの複数の画像形成機能を有するものである。また、それぞれの画像形成装置ＭＦＰ１〜ＭＦＰｎは、１つ以上の通信プロトコルを利用した通信が可能であり、実装されているプロトコルは、それぞれの画像形成装置ＭＦＰ１〜ＭＦＰｎにおいて異なる場合がある。

また、情報処理装置ＷＳ１〜ＷＳｎは、通信制御装置を備え、ローカルデータ処理機能及びネットワーク処理機能を有し、ローカルに作成した文書を、ローカルエリアネットワークＬＡＮ（Local Area Network）５０（以下、「ＬＡＮ４０」と言う。）を介して画像形成装置ＭＦＰ１〜ＭＦＰｎからプリントアウトするなどの通信機能も備えている。また、情報処理装置ＷＳ１〜ＷＳｎは、画像形成装置ＭＦＰ１〜ＭＦＰｎから種々の情報を取得する周辺機器管理ソフトウェアが実装されている。

情報処理装置ＷＳ１〜ＷＳｎのユーザは、周辺機器管理ソフトウェアを用いて、ＬＡＮ４０に接続されている画像形成装置ＭＦＰ１〜ＭＦＰｎの機器情報を適宜に収集することができる。

図２（a）は、本発明の実施例１に係る画像形成装置ＭＦＰ（ＭＦＰ１〜ＭＦＰｎ）の構成例を示している。

同図において、システム制御部１は、この画像形成装置ＭＦＰ１〜ＭＦＰｎの各部の制御処理、及び、通信処理などの各種制御処理を行うものであり、システムメモリ２は、システム制御部１が実行する制御処理プログラム、及び、処理プログラムを実行するときに必要な各種データなどを記憶するとともに、システム制御部１のワークエリアを構成するものであり、パラメータメモリ３は、この画像形成装置ＭＦＰ１〜ＭＦＰｎに固有な各種の情報を記憶するためのものであり、時計回路４は、現在時刻情報を出力するものである。

スキャナ５は、所定の解像度で原稿画像を読み取るためのものであり、プロッタ６は、所定の解像度で画像を記録出力するためのものであり、操作表示部７は、この画像形成装置ＭＦＰ１〜ＭＦＰｎを操作するためのもので、各種の操作キー、及び、各種の表示器からなる。

画像処理部８は、スキャナ５で読み取って得た画像データについて、種々の画像処理を適用するためのものであり、磁気ディスク装置９は、画像データや種々のプログラムファイルなどの多数のファイルを記憶するためのものである。

ＬＡＮＩ／Ｆ（interface）回路１０は、この画像形成装置ＭＦＰ１〜ＭＦＰｎをＬＡＮ４０に接続するためのものであり、ＬＡＮ伝送制御部１１は、ＬＡＮ４０を介して、他のデータ端末装置との間で種々のデータをやりとりするための各種所定のプロトコルスイートの通信制御処理を実行するためのものである。

これらの、システム制御部１、システムメモリ２、パラメータメモリ３、時計回路４、スキャナ５、プロッタ６、操作表示部７、画像処理部８、磁気ディスク装置９、及び、ＬＡＮ伝送制御部１０は、内部バス１４に接続されており、これらの各要素間でのデータのやりとりは、主としてこの内部バス１４を介して行われている。

図２（b）は、本発明の実施例１に係る情報処理装置ＷＳ（ＷＳ１〜ＷＳｎ）の構成例を示している。

同図において、ＣＰＵ（中央処理装置：Central Processing Unit）２１は、この情報処理装置ＷＳ１〜ＷＳｎの動作制御を行うものであり、ＲＯＭ（Read Only Memory）２２は、ＣＰＵ２１が起動時に実行するプログラムや必要なデータなどを記憶するためのものであり、ＲＡＭ（Random Access Memory）２３は、ＣＰＵ２１のワークエリアなどを構成するためのものである。

キャラクタジェネレータ２４は、図形文字の表示データを発生するためのものであり、時計回路２５は、現在日時情報を出力するためのものであり、ＬＡＮＩ／Ｆ回路２６は、この情報処理装置ＷＳ１〜ＷＳｎをＬＡＮ４０に接続するためのものであり、ＬＡＮ伝送制御部２７は、ＬＡＮ４０を介して、他のデータ端末装置との間で種々のデータをやりとりするための各種所定のプロトコルスイートの通信制御処理を実行するためのものである。

磁気ディスク装置２８は、システムソフトウェア（オペレーティングシステム（後述））、種々のアプリケーションプログラム、ワークデータ、ファイルデータ、画情報データなどの種々のデータを記憶するためのものであり、ＣＤ−ＲＯＭ（Compact Disk Read Only Memory）装置２９は、交換可能な記憶媒体であるＣＤ−ＲＯＭ３０のデータを読み込むためのものであり、ＣＲＴ（Cathode Ray Tube）画面表示装置３１は、この情報処理装置ＷＳ１〜ＷＳｎを操作するための画面を表示するためのものであり、表示制御部３２は、ＣＲＴ画面表示装置３１の表示内容を制御するためのものである。

キーボード装置３３は、この情報処理装置ＷＳ１〜ＷＳｎに種々のキー操作を行うためのものであり、画面指示装置３４は、ＣＲＴ画面表示装置３１の任意の点を指示するなどの操作作業を行うためのものであり、入力制御部３５は、キーボード装置３３及び画面指示装置３４の入力情報を取り込むなどするためのものである。

これらのＣＰＵ２１、ＲＯＭ２２、ＲＡＭ２３、キャラクタジェネレータ２４、時計回路２５、ローカルエリアネット伝送制御部２７、磁気ディスク装置２８、ＣＤ−ＲＯＭ装置２９、表示制御部３２、及び、入力制御部３５は、内部バス３６に接続されており、これらの各要素間のデータのやりとりは、主としてこの内部バス３６を介して行われる。

図３は、本発明の実施例１に係る情報処理装置ＷＳ（ＷＳ１〜ＷＳｎ）におけるソフトウェア構成の要部（部分）を示している。

アプリケーションプログラムＡＰは、システムを管理制御するためのオペレーティングシステムＯＳ（Operating System）を介して、種々の機能を実現する。ここで、アプリケーションプログラムＡＰは、特に、ユーザが直接利用するソフトウェアであり、例えば、ネットワーク上に接続している画像形成装置ＭＦＰ１〜ＭＦＰｎの状態を表示するなどの周辺機器管理システム（ソフトウェア）である。

オペレーティングシステムＯＳには、サービス層ＳＬ、ネットワーク層ＮＬ及びソケットライブラリＬＳが設けられている。

サービス層ＳＬは、機器及び機器を管理する機器管理サービス、機器情報やログ情報などの情報をＤＢ（データベース）で管理するＤＢサーバサービス及びログ出力を管理するログサーバサービスなどのサービス（ライブラリ）を集めた群である。

ネットワーク層ＮＬは、機器との通信制御、プロトコル管理、機器検索などの機能を備えたライブラリである。

ソケットライブラリＬＳは、ネットワーク対応アプリケーションにおいて、主にＴＣＰ／ＩＰネットワーク通信の制御や手順をＩ／Ｆとして提供したライブラリ（通信ライブラリ）である。

図４は、本発明の実施例１に係るネットワーク層ＮＬのより詳細な構成例を示している。

このネットワーク層ＮＬは、アプリケーションプログラムＡＰに対して機器との通信機能（情報の取得や設定など）を提供するための機能が実装されている層であり、共通Ｉ／Ｆ（共通ＡＰＩ）層、サービス層及びプロトコル層からなる。

共通Ｉ／Ｆ（共通ＡＰＩ）層ＡＰＩは、機器より取得する情報の種別などに依存しない抽象的なインタフェースをアプリケーションプログラムＡＰに対して提供するＡＰＩ（Application Program Interface）が実装されている層である。例えば、機器との通信を開始するための関数（Ｏｐｅｎ）、機器２０より情報を取得するための関数（Ｇｅｔ）、機器２０へ情報を設定するための関数（Ｓｅｔ）、機器２０との通信を終了するための関数（Ｃｌｏｓｅ）などが実装されている。共通ＡＰＩ層１３における各関数は、アプリケーションプログラムＡＰより与えられる抽象的なパラメータ（取得したい情報の種別など）や、通信を制御するためのパラメータ（タイムアウトなど）に基づいて、サービス層を呼び出す。

サービス層ＭＳは、機器情報サービスＭＳ１、機器検索サービスＭＳ２、共通ＩＤ管理サービスＭＳ３、プロトコル制御サービスＭＳ４及びＸＭＬ管理サービスＭＳ５など、それぞれのサービスに特化した機能を提供するモジュール群によって構成される。

機器情報サービスＭＳ１は、機器の各種情報の取得や設定などの機能を提供するモジュールである。機器情報サービスＭＳ１で取得や設定などが行われる機器情報について説明する。

図５は、本発明の実施例１に係る機器情報のカテゴリの例を示す図である。

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

図４に戻り、機器検索サービスＭＳ２は、ローカルエリアネットワークＬＡＮに接続している機器の検索機能を提供するモジュールである。

トラップサービスＭＳ３は、機器とのＳＮＭＰ通信において機器２０より送信されるトラップ（ＴＲＡＰ）を受信し、受信したトラップをアプリケーションプログラムＡＰに対して通知する機能を提供するモジュールである。宛先管理サービスＭＳ４は、メールの送信などにおける宛先に関する情報を管理するモジュールである。

共通ＩＤ管理サービスＭＳ５は、アプリケーションからのＩＤ要求に基づきプロトコル層を介して機器情報を取得し、その情報をアプリケーションに返す機能を提供するモジュールであり、プロトコル制御サービスＭＳ４は、各プロトコルのＩＤ管理、制御及びプロトコルの通信制御機能を提供するモジュールである。

ＸＭＬ管理サービスＭＳ６は、アプリケーションプログラムＡＰより要求されるプロトコルのＩＤ及びそのＩＤと関連付けされている機器の情報をＸＭＬファイルで管理し、共通ＩＤ管理からの要求に対して、管理しているＸＭＬファイルから該当する情報を検索し、それを共通ＩＤ管理サービスに返す機能を提供するモジュールである。

サービス層ＭＳは、共通ＡＰＩ層を介してアプリケーションプログラムＡＰより与えられる抽象的なパラメータや、プロトコルに関するパラメータ（通信に利用するプロトコルについて、その種別の指定や自動的な判断に任せる旨の指定）などに基づいて、プロトコル層を呼び出す。

プロトコル層ＰＬは、各プロトコルに依存したインタフェースによって、当該プロトコルによる機器などとの通信機能を上位層（ここではサービス層）に提供する層である。例えば、ＳＮＭＰ、ＦＴＰ（File Transfer Protocol）、ＨＴＴＰ（HyperText Transfer Protocol）及びＳＯＡＰなどによって通信するためのモジュールが実装されている。

図６は、本発明の実施例１に係る通信制御機能の主要な機能構成例を示す図である。

この通信制御機能は、共通情報ＩＤの管理及び制御を行う共通情報ＩＤ制御部５１と、共通情報ＩＤの情報を保存する共通情報ＩＤ定義ファイル（共通情報ＩＤＸＭＬファイル）５２、各プロトコルＩＤの管理、制御及びプロトコルの通信制御を行うプロトコル制御部５３、各プロトコルの管理、制御を行う各プロトコル管理部５４、各プロトコル毎の情報ＩＤの情報を保存するプロトコル情報ＩＤ定義ファイル（プロトコル情報ＩＤＸＭＬファイル）５５及び各プロトコルモジュールの制御を行う各プロトコルモジュール管理部５６とを備えて構成され、アプリケーションにプロトコルを意識させずに情報ＩＤだけで通信制御を行うことを目的としている。

では、通信制御機能で取り扱われる情報ＩＤを保存するプロトコル情報ＩＤ定義ファイル５５及び共通情報ＩＤ定義ファイル５２について説明する。

各プロトコルのプロトコル情報には、情報ＩＤ名、アクセス手順、戻り値及び制御関数などの項目が用意され、ＸＭＬ形式のファイル（プロトコル情報ＩＤＸＭＬファイル）として保存されている。

例えば、ＳＮＭＰプロトコルの場合、以下のような、情報ＩＤ名（１）、アクセス手順（２）、戻り値（３）及びネットワーク層ＮＬ内部の制御関数（４）の項目が用意されている。
（１）情報ＩＤ名：給紙トレイ名
（２）アクセス手順：Ｐｒｉｎｔｅｒ−ＭＩＢ ｐｒｔＩｎｐｕｔＮａｍｅ、Ｐｒｉｎｔｅｒ−ＭＩＢ ｐｒｔＩｎｐｕｔＤｅｓｃｒｉｐｔｉｏｎ
（３）戻り値：文字列型 給紙トレイ名
（４）制御関数： ＳＮＭＰ＿ＧｅｔＩｎｐｕｔＴｒａｙＮａｍｅ
アプリケーションは、給紙トレイ名称に関する機器情報を取得する場合、プロトコル名ＳＮＭＰを指定し、情報ＩＤに給紙トレイ名を指定することで、プロトコル情報ＩＤ定義ファイル５５内で該当するアクセス手順（アクセス手段）に従って制御関数ＳＮＭＰ＿ＧｅｔＩｎｐｕｔＴｒａｙＮａｍｅにより、機器から給紙トレイ名称に関する機器情報が取得され、戻り値として文字列型の給紙トレイ名称を取得することができる。

図７は、本発明の実施例１に係るアクセス手順のＸＭＬファイルの一例を示す図である。

図７では、機器情報カテゴリにおける給紙トレイについての情報を取得するための手順が定義されている。

情報ＩＤに給紙トレイ名が指定された場合、指定された情報ＩＤに該当する図７に示すアクセス手順に従って機器から給紙トレイ名の機器情報を取得する。

また、機器側から取得したい機器情報に幾つかのアクセス手順がある場合（同じ目的の情報ＩＤが複数存在する場合）は、アプリケーションが指定した機器に対して、どの情報ＩＤを使えば良いのか判断できない。そのような場合、複数に指定することも可能だが、アプリケーションに負担がかかる。そこで本発明では、次のようにしてアプリケーションの負担を軽減する。即ち、同じ目的の情報ＩＤが複数ある場合は、１つのＩＤとしてまとめた共通情報ＩＤ（各プロトコル共通の識別情報）を設け、共通情報ＩＤ、各プロトコルの情報ＩＤ、戻り値及びネットワーク層ＮＬ内部の制御関数といった項目が用意され、ＸＭＬ形式でＸＭＬファイル（共通情報ＩＤＸＭＬファイル及びプロトコル情報ＩＤＸＭＬファイル）として保存されている。

図８は、本発明の実施例１に係る機器名称に関する共通情報ＩＤ定義ファイル５２の一例を示す図である。

図７に示す共通情報ＩＤ定義ファイル５２の場合、機器名称を取得する方法には、「ＳＮＭＰプロトコルでＩＤ＝ｓｙｓＮａｍｅを指定する方法」、「ＳＯＡＰプロトコルでＩＤ＝ｓｙｓｔｅｍ．ｓｙｔｅｍｎａｍｅ．：１を指定する方法」及び「ＳＯＡＰプロトコルでＩＤ＝ｄｅｖｉｃｅ．ｎａｍｅ：１を指定する方法」の３つがあり、それぞれの取得方法について、このＸＭＬファイルでは定義されている。

アプリケーションは、機器名称に関する機器情報を取得する場合、共通情報ＩＤに機器名称（ＳｙｓｔｅｍＮａｍｅ）を指定することで、図７に示す３つの方法によって、機器から機器名称を取得することができる。

なお、Ｗｅｂサービスなどで機器側から機器名称を取得する場合、Ｗｅｂサービスで具体的に指定するパラメータなどの内容がメーカーによって異なる場合がある。例えば、Ａ社の場合は、「ｓｙｓｔｅｍ．ｓｙｓｔｅｍｎａｍｅ：１」でアクセスし、Ｂ社の場合は、「ｄｅｖｉｃｅ．ｎａｍｅ：１」でアクセスすることになっている場合などである。本実施例では、このように異なる複数のＷｅｂサービスでも対応できるように、考慮している。

また、共通情報ＩＤに記載されている各プロトコルの情報ＩＤに優先度を設けたいことがある。即ち、アプリケーションからでも指定できるようにすることと、共通情報ＩＤにプロトコル優先度という項目を設ける。その手順として、まずアプリケーションからプロトコルの優先度を指定する。次に、プロトコル優先度パラメータを用意して、情報ＩＤ検索処理の時、優先度の高いプロトコルから情報ＩＤの検索を行う。そして共通情報ＩＤにプロトコル優先度を指定して、情報ＩＤ検索処理の時、共通情報ＩＤに指定した優先度の高いプロトコルから情報ＩＤの検索を行う。

このような情報ＩＤを用いることで、機器側から機器情報を取得したい場合、ＳＮＭＰプロトコルやＳＯＡＰプロトコルなど、複数のプロトコルを介して機器との通信を行い、機器情報を取得することができる。

次に、通信制御機能において上述した情報ＩＤや各プロトコルの管理、制御などを行うプロトコル制御部５３、各プロトコル管理部５４及び各プロトコルモジュール管理部５６について図９〜１２を用いて説明する。

図９は、本発明の実施例１に係る通信制御機能（情報ＩＤがプロトコル情報ＩＤで指定可能な場合）の基本フローチャートである。図９（ａ）はＤｅｖｉｃｅＯｐｅｎ（）の基本フローチャートであり、（ｂ）はＤｅｖｉｃｅＧｅｔ（）の基本フローチャートであり、（ｃ）はＤｅｖｉｃｅＣｌｏｓｅ（）の基本フローチャートであり、（ｄ）はプロトコル別通信処理の基本フローチャートである。

まず、図９（a）のＤｅｖｉｃｅＯｐｅｎ（）は、アプリケーションに呼ばれた際、プロトコル指定パラメータに自動を指定しておくか否かを判断し（Ｓ１）、ＤｅｖｉｃｅＯｐｅｎ（）は、プロトコル指定の値が自動を指定された場合（Ｓ１でＹＥＳのルート）、プロトコル指定フラグをＯＮにしておく（Ｓ２）。その後、初期処理を行い（Ｓ３）、アプリケーションに返す。アプリケーションが機器側から取得したい機器情報の情報ＩＤを指定して図９（ｂ）のＤｅｖｉｃｅＧｅｔ（）を呼ぶ。ＤｅｖｉｃｅＧｅｔ（）は、プロトコル指定フラグがＯＮか否かを判断し（Ｓ１１）、プロトコル指定フラグがＯＮの時（Ｓ１１でＹＥＳのルート）、情報ＩＤを基に情報ＩＤ検索処理を呼び（Ｓ１２）、情報ＩＤ検索処理は、情報ＩＤを基に各プロトコルのプロトコル情報ＩＤ定義ファイル５５に登録されているかどうかを検索する（Ｓ１３）。その結果をＤｅｖｉｃｅＧｅｔ（）に返す。ＤｅｖｉｃｅＧｅｔ（）は、情報ＩＤが存在した場合（Ｓ１３でＹＥＳのルート）、検出されたプロトコルと情報ＩＤを基にプロトコル別通信処理を呼び（Ｓ１４）、ＤｅｖｉｃｅＧｅｔ（）は、プロトコル別通信処理からの通信結果（取得した機器情報）を基に戻り値を作成し、アプリケーションに返す（Ｓ１５）。一方、ステップＳ１３で情報ＩＤが存在しなかった場合（Ｓ１３でＮＯのルート）、その旨を通知する戻り値を作成し、アプリケーションに返す（Ｓ１５）。そしてアプリケーションがＤｅｖｉｃｅＣｌｏｓｅ（）を呼ぶ。ＤｅｖｉｃｅＣｌｏｓｅ（）は、図９（ｃ）のように後処理を行い（Ｓ２１）、その結果をアプリケーションに返す。

プロトコル別通信処理は、図９（ｄ）により情報ＩＤを基にプロトコル情報ＩＤ定義ファイル５５に登録されているかどうかを調べる（Ｓ２２）。登録されている場合は（Ｓ２２でＹＥＳのルート）、その情報ＩＤに関する情報（該当するアクセス手順）を取得し（Ｓ２３）、その情報に従って通信処理を行い（Ｓ２４）、通信結果（取得した機器情報）をＤｅｖｉｃｅＧｅｔ（）に返す（Ｓ２５）。

図１０は、本発明の実施例１に係る通信制御機能（情報ＩＤが共通情報ＩＤとプロトコル情報ＩＤの両方を指定可能な場合）の基本フローチャートである。図１０（ａ）はＤｅｖｉｃｅＯｐｅｎ（）の基本フローチャートであり、（ｂ）はＤｅｖｉｃｅＧｅｔ（）の基本フローチャートであり、（ｃ）はＤｅｖｉｃｅＣｌｏｓｅ（）の基本フローチャートであり、（ｄ）はプロトコル別通信処理の基本フローチャートである。

まず、図１０（a）のＤｅｖｉｃｅＯｐｅｎ（）は、アプリケーションに呼ばれた際、プロトコル指定パラメータに自動を指定しておくか否かを判断し（Ｓ３１）、ＤｅｖｉｃｅＯｐｅｎ（）は、プロトコル指定の値が自動を指定された場合は（Ｓ３１でＹＥＳのルート）、プロトコル指定フラグをＯＮにしておく（Ｓ３２）。その後、初期処理を行い（Ｓ３３）、アプリケーションに返す。

アプリケーションが機器側から取得したい機器情報の情報ＩＤを指定して図１０（ｂ）のＤｅｖｉｃｅＧｅｔ（）を呼ぶ。ＤｅｖｉｃｅＧｅｔ（）は、プロトコル指定フラグがＯＮか否かを判断し（Ｓ４１）、プロトコル指定フラグがＯＮの時（Ｓ４１でＹＥＳのルート）、まず、指定した情報ＩＤを共通情報ＩＤ定義ファイル５２に登録されているかどうかを調べ（Ｓ４２）、登録されている場合は（Ｓ４２でＹＥＳのルート）、その情報ＩＤの情報を取り出す（Ｓ４３）。情報ＩＤを基に情報ＩＤ検索処理を呼び（Ｓ４４）、情報ＩＤ検索処理は、情報ＩＤを基に各プロトコルのプロトコル情報ＩＤ定義ファイル５５に登録されているかどうかを検索する（Ｓ４５）。その結果をＤｅｖｉｃｅＧｅｔ（）に返す。ＤｅｖｉｃｅＧｅｔ（）は、情報ＩＤが存在した場合（Ｓ４５でＹＥＳのルート）、検出されたプロトコルと情報ＩＤを基にプロトコル別通信処理を呼び（Ｓ４６）、ＤｅｖｉｃｅＧｅｔ（）は、プロトコル別通信処理からの通信結果（取得した機器情報）を基に戻り値を作成し、アプリケーションに返す（Ｓ４７）。一方、ステップＳ４５で情報ＩＤが存在しなかった場合（Ｓ４５でＮＯのルート）、その旨を通知する戻り値を作成し、アプリケーションに返す（Ｓ４７）。そしてアプリケーションがＤｅｖｉｃｅＣｌｏｓｅ（）を呼ぶ。ＤｅｖｉｃｅＣｌｏｓｅ（）は、図１０（ｃ）のように後処理を行い（Ｓ４８）、その結果をアプリケーションに返す。

プロトコル別通信処理は、図１０（ｄ）により情報ＩＤを基にプロトコル情報ＩＤ定義ファイル５５に登録されているかどうかを調べる（Ｓ５１）。登録されている場合は（Ｓ５１でＹＥＳのルート）、その情報ＩＤに関する情報（該当するアクセス手順）を取得し（Ｓ５２）、その情報に従って通信処理を行い（Ｓ５３）、通信結果（取得した機器情報）をＤｅｖｉｃｅＧｅｔ（）に返す（Ｓ５４）。

図１１は、本発明の実施例１に係る通信制御機能（情報ＩＤがプロトコル情報ＩＤで指定可能な場合）の処理手順の一例を示しており、図１１のシーケンス図を参照して説明する。

なお、ここで、共通Ｉ／Ｆは、図４のネットワーク層ＮＬにおける共通インタフェース（共通ＡＰＩ：通信制御インタフェース）層ＡＰＩを示す。また、共通情報ＩＤ制御部５１は、図４のサービス層ＭＳにある共通ＩＤ管理サービスの制御を行うマネジャー（管理）である。また、プロトコル制御部５３は、各プロトコルＩＤの管理、制御及びプロトコルの通信制御（同図の各プロトコル管理部５４の制御）を行う。また、各プロトコル管理部５４は、図４のプロトコル層ＰＬにある各プロトコルへの制御を行うマネジャー（管理）である。また、ＸＭＬ管理は、共通情報ＩＤ定義ファイル５２及びプロトコル情報ＩＤ定義ファイル５５である。また、各プロトコルモジュール管理部５６は、図４のプロトコル層にあるＳＮＭＰ、ＦＴＰ、ＨＴＴＰ及びＳＯＡＰなどのプロトコルモジュール制御を行うマネジャー（管理）である。

まず、アプリケーションプログラムＡＰは、共通Ｉ／ＦのＯｐｅｎ関数を呼ぶ（１―１）。これにより、共通Ｉ／Ｆは、共通情報ＩＤ制御部５１、プロトコル制御部５３及び各プロトコル管理部５４に対してＯｐｅｎを要求し（１−２〜１−４）、共通情報ＩＤ制御部５１は、共通情報ＩＤ制御部５１内での初期化処理を行い、プロトコル指定が自動の場合、プロトコル制御部５３を介して各プロトコル管理部５４に対してＯｐｅｎを要求し（１−２〜１―４）、各プロトコル管理部５４は、各プロトコルの初期化処理を行い、Ｏｐｅｎ要求の処理を終えたことを共通情報ＩＤ制御部５１に通知する（１−５〜１−６）。

共通情報ＩＤ制御部５１は、プロトコル制御部５３から通知されたら、Ｏｐｅｎ要求の処理を終えたことを共通Ｉ／Ｆに通知し（１−７）、共通Ｉ／Ｆは、共通情報ＩＤ制御部５１から通知されたら、アプリケーションプログラムＡＰにＯｐｅｎ要求の処理を終えたことを通知する（１−８）。

次に、アプリケーションプログラムＡＰは、機器情報を取得するために共通Ｉ／Ｆに対して、取得したい機器情報に関するＩＤを引数（パラメータ）にＤｅｖｉｃｅＧｅｔ（）をコールすることで要求する（１−９）。ここで、機器情報に関するＩＤに、各プロトコルの情報ＩＤを指定する。

共通Ｉ／Ｆは、共通情報ＩＤ制御部５１に対して、取得したい機器情報に関するＩＤを要求し（１−１０）、共通情報ＩＤ制御部５１は、ＸＭＬ管理に、要求された情報ＩＤを基に、情報ＩＤがＸＭＬ形式で保持された定義ファイル５２、５５を検索するように要求する（１−１１）。

ＸＭＬ管理は、各プロトコル情報ＩＤ定義ファイル５５を参照して、指定されたＩＤについて調べ、指定されたＩＤが存在するか否かを判定し、存在していればＸＭＬに記載しているプロトコル名と情報ＩＤを共通情報ＩＤ制御部５１に通知する（１−１２）。ＳＮＭＰで取得したい機器情報に機器名称が要求された場合であれば、「ｓｙｓＮａｍｅ」を通知する。

共通情報ＩＤ制御部５１は、ＸＭＬ管理から得られたプロトコル名とその情報ＩＤをプロトコル制御部５３を介して各プロトコル管理部５４に通知し（１−１３〜１−１４）、各プロトコル管理部５４は、指定したプロトコル名の情報ＩＤをＸＭＬ管理に通知する（１−１５）。

ＸＭＬ管理は、指定されたプロトコル名の情報ＩＤを基に、各プロトコル情報ＩＤ定義ファイル５５を検索し、該当するプロトコル情報ＩＤ定義ファイル５５から情報ＩＤのアクセス手順を取得し、各プロトコル管理部５４に通知する（１−１６）。この時、各プロトコル管理部５４に通知される情報は、例えば、取得した機器情報に給紙トレイ名が要求された場合は、図７に示すアクセス手順のＸＭＬファイルから「ｐｒｔＩｎｐｕｔＮａｍｅ」というＰｒｉｎｔｅｒ−ＭＩＢオブジェクト名が、各プロトコル管理部５４へ通知される。

次いで、各プロトコル管理部５４は、各プロトコルモジュール管理部５６にプロトコル名とその情報ＩＤのアクセス手順を通知し（１−１７）、各プロトコルモジュール管理部５６は、指定されたプロトコル名のモジュールに対して、通知されたアクセス手順に従って、機器から機器情報を取得し（１−１８〜１−１９）、取得した機器情報を各プロトコル管理部５４に通知する（１―２０）。

また、１−１４から１−２１までの処理手順は、ＸＭＬ管理から得られた情報ＩＤが複数個存在する場合（例えば、ＳＯＯＰで取得したい機器情報が機器名称の場合、情報ＩＤが「ｓｙｓｔｅｍ．ｓｙｓｔｅｍｎａｍｅ：１」と「ｄｅｖｉｃｅ．ｎａｍｅ：１」の２つになる場合）、その数だけ処理手順を繰り返し、全ての情報ＩＤの機器情報を取得する。

各プロトコル管理部５４は、全ての情報ＩＤの機器情報をまとめ、プロトコル制御部５３を介して、共通情報ＩＤ制御部５１に通知し（１−２１〜１−２２）、共通情報ＩＤ制御部５１は、全ての情報ＩＤの機器情報を共通Ｉ／Ｆに通知し（１−２３）、共通Ｉ／Ｆは、アプリケーションプログラムＡＰに全ての情報ＩＤの機器情報を通知する（１−２４）。

これにより、アプリケーションプログラムＡＰは、取得した全ての情報ＩＤの機器情報に基づいて、適切な処理（情報表示など）を行う。そして、共通Ｉ／Ｆに「Ｃｌｏｓｅ」を要求する（１−２５）。

従って、共通Ｉ／Ｆは、共通Ｉ／Ｆ内での終了処理を行い、共通情報ＩＤ制御部５１に「Ｃｌｏｓｅ」を要求し（１−２６）、共通情報ＩＤ制御部５１は、共通情報ＩＤ制御部５１内での終了処理を行い、プロトコル制御部５３を介して各プロトコル管理部５４に「Ｃｌｏｓｅ」を要求し（１−２７〜１−２８）、各プロトコル管理部５４は、各プロトコル管理部５４内での終了処理を行い、プロトコル制御部５３を介して共通情報ＩＤ制御部５１に終了処理を終えたことを通知する（１−２９〜１−３０）。

共通情報ＩＤ制御部５１は、共通Ｉ／Ｆに終了処理を終えたことを通知し（１−３１）、共通Ｉ／Ｆは、アプリケーションプログラムＡＰに終了処理を終えたことを通知して（１−３２）、一連の通信制御機能の処理が終了する。

図１２は、本発明の実施例１に係る通信制御機能（情報ＩＤが共通情報ＩＤとプロトコル情報ＩＤの両方を指定可能な場合）の処理手順の一例を示しており、図１１のシーケンス図を参照して説明する。

まず、アプリケーションプログラムＡＰは、共通Ｉ／ＦのＯｐｅｎ関数を呼ぶ（２―１）。これにより、共通Ｉ／Ｆは、共通情報ＩＤ制御部５１、プロトコル制御部５３及び各プロトコル管理部５４に対してＯｐｅｎを要求し（２−２〜２−４）、共通情報ＩＤ制御部５１は、共通情報ＩＤ制御部５１内での初期化処理を行い、プロトコル指定が自動の場合、プロトコル制御部５３を介して各プロトコル管理部５４に対してＯｐｅｎを要求し（２−２〜２―４）、各プロトコル管理部５４は、各プロトコルの初期化処理を行い、Ｏｐｅｎ要求の処理を終えたことを共通情報ＩＤ制御部５１に通知する（２−５〜２−６）。

共通情報ＩＤ制御部５１は、プロトコル制御部５３から通知されたら、Ｏｐｅｎ要求の処理を終えたことを共通Ｉ／Ｆに通知し（２−７）、共通Ｉ／Ｆは、共通情報ＩＤ制御部５１から通知されたら、アプリケーションプログラムＡＰにＯｐｅｎ要求の処理を終えたことを通知する（２−８）。

次に、アプリケーションプログラムＡＰは、機器情報を取得するために共通Ｉ／Ｆに対して、取得したい機器情報に関するＩＤを引数（パラメータ）にＤｅｖｉｃｅＧｅｔ（）をコールすることで要求する（２−９）。ここで、機器情報に関するＩＤに、各プロトコルの情報ＩＤだけでなく、共通情報ＩＤも指定することが可能である。例えば、図８に示した機器名称を取得する場合、「Ｇｅｔ ＳｙｓｔｅｍＮａｍｅ」と要求すれば良い。

共通Ｉ／Ｆは、共通情報ＩＤ制御部５１に対して、取得したい機器情報に関するＩＤを要求し（２−１０）、共通情報ＩＤ制御部５１は、ＸＭＬ管理に、要求された情報ＩＤを基に、情報ＩＤがＸＭＬ形式で保持された定義ファイル５２、５５を検索するように要求する（２−１１）。

ＸＭＬ管理は、共通情報ＩＤ定義ファイル５２及び各プロトコル情報ＩＤ定義ファイル５５を参照して、指定されたＩＤについて調べ、指定されたＩＤが存在するか否かを判定し、存在していれば、要求されたＩＤが共通情報ＩＤの場合、ＸＭＬに記載しているプロトコル名と情報ＩＤを共通情報ＩＤ制御部５１に通知する（１−１２）。図８の例の場合であれば、「（ア）ＳＮＭＰプロトコルでＩＤ＝ｓｙｓＮａｍｅ。（イ）ＳＯＡＰプロトコルでＩＤ＝ｓｙｓｔｅｍ．ｓｙｓｔｅｍｎａｍｅ：１。（ウ）ＳＯＡＰプロトコルでＩＤ＝ｄｅｖｉｃｅ．ｎａｍｅ：１。」を通知する。また、要求された情報ＩＤがプロトコルの情報ＩＤの場合、プロトコル名とその情報ＩＤを共通情報ＩＤ制御部５１に通知する。

共通情報ＩＤ制御部５１は、ＸＭＬ管理から得られたプロトコル名とその情報ＩＤをプロトコル制御部５３を介して各プロトコル管理部５４に通知し（２−１３〜２−１４）、各プロトコル管理部５４は、指定したプロトコル名の情報ＩＤをＸＭＬ管理に通知する（２−１５）。

ＸＭＬ管理は、指定されたプロトコル名の情報ＩＤを基に、各プロトコル情報ＩＤ定義ファイル５５を検索し、該当するプロトコル情報ＩＤ定義ファイル５５から情報ＩＤのアクセス手順を取得し、各プロトコル管理部５４に通知する（２−１６）。この時、各プロトコル管理部５４に通知される情報は、例えば、取得した機器情報に給紙トレイ名が要求された場合は、図７に示すアクセス手順のＸＭＬファイルから「ｐｒｔＩｎｐｕｔＮａｍｅ」というＰｒｉｎｔｅｒ−ＭＩＢオブジェクト名が、各プロトコル管理部５４へ通知される。

次いで、各プロトコル管理部５４は、各プロトコルモジュール管理部５６にプロトコル名とその情報ＩＤのアクセス手順を通知し（２−１７）、各プロトコルモジュール管理部５６は、指定されたプロトコル名のモジュールに対して、通知されたアクセス手順に従って、機器から機器情報を取得し（２−１８〜２−１９）、取得した機器情報を各プロトコル管理部５４に通知する（２―２０）。

また、２−１４から２−２１までの処理手順は、ＸＭＬ管理から得られた全てのプロトコル名とその情報ＩＤが複数個存在する場合、その数だけ処理手順を繰り返し、全ての情報ＩＤの機器情報を取得する。

各プロトコル管理部５４は、全ての情報ＩＤの機器情報をまとめ、プロトコル制御部５３を介して、共通情報ＩＤ制御部５１に通知し（２−２１〜２−２２）、共通情報ＩＤ制御部５１は、全ての情報ＩＤの機器情報を共通Ｉ／Ｆに通知し（２−２３）、共通Ｉ／Ｆは、アプリケーションプログラムＡＰに全ての情報ＩＤの機器情報を通知する（２−２４）。

これにより、アプリケーションプログラムＡＰは、取得した全ての情報ＩＤの機器情報に基づいて、適切な処理（情報表示など）を行う。そして、共通Ｉ／Ｆに「Ｃｌｏｓｅ」を要求する（２−２５）。

従って、共通Ｉ／Ｆは、共通Ｉ／Ｆ内での終了処理を行い、共通情報ＩＤ制御部５１に「Ｃｌｏｓｅ」を要求し（２−２６）、共通情報ＩＤ制御部５１は、共通情報ＩＤ制御部５１内での終了処理を行い、プロトコル制御部５３を介して各プロトコル管理部５４に「Ｃｌｏｓｅ」を要求し（２−２７〜２−２８）、各プロトコル管理部５４は、各プロトコル管理部５４内での終了処理を行い、プロトコル制御部５３を介して共通情報ＩＤ制御部５１に終了処理を終えたことを通知する（２−２９〜２−３０）。

共通情報ＩＤ制御部５１は、共通Ｉ／Ｆに終了処理を終えたことを通知し（２−３１）、共通Ｉ／Ｆは、アプリケーションプログラムＡＰに終了処理を終えたことを通知して（２−３２）、一連の通信制御機能の処理が終了する。

以上のように、本発明の実施例１によれば、アプリケーションプログラムＡＰが、機器情報を取得する際に細かいパラメータの違い（アプリケーションがある機器に取得設定したい情報項目にアクセスする際、どのプロトコルで通信制御を行えば良いかが分からない）を意識することなく、共通情報ＩＤやプロトコル情報ＩＤを指定するだけで機器との通信が可能となり、アプリケーションプログラムＡＰの負担を軽減することができる。

また、機器との通信を行う際に、ネットワークを介して接続している外部装置より接続用モジュールをダウンロードするなど、機器との通信前に複雑な処理を行う必要がなく、接続までの処理時間を短縮することができる。

ＸＭＬ形式のメッセージを用いて機器情報を取得する場合、その記述内容を定義できるものの、ＸＭＬデータの内容がメーカー依存であったり、機種依存であったりと言うように、その共通性は必ずしも担保されたものにはなっていない。そのため、複数のプロトコルで取得できる機器情報のうち、同じ機器情報に対して取得要求した場合、各プロトコルから取得した機器情報の値が異なる場合がある。

本実施例では、上記の問題点を解決するため、複数のプロトコルで取得できる機器情報のうち、各プロトコルから取得した機器情報の値が異なる場合、それらを統一して扱えるようにするための通信制御機能について説明する。

本実施例と実施例１の異なる点は、実施例１の通信制御機能を基に、取得した機器情報の値を統一したデータタイプに変換するデータタイプ変換機能（データタイプ変換サービス）が付加された点である。

そのため、実施例１の説明で用いた、本実施例との共通点である図１のシステム構成や図２のハードウェア構成の例などについては、同一の符号を用いて説明を省略し、実施例１と異なるデータタイプ変換機能に関する内容を中心に説明する。

図１３は、本発明の実施例２に係る通信制御機能の主要な機能構成例を示す図である。

この通信制御機能は、共通情報ＩＤ制御部５１、共通情報ＩＤ定義ファイル５２、プロトコル制御部５３、各プロトコル管理部５４、プロトコル情報ＩＤ定義ファイル５５、各プロトコルモジュール管理部５６の他、取得した機器情報の値を統一したデータタイプに変換し、データタイプの管理を行うデータタイプ管理部５７及びデータタイプ変換用のデータを保持するデータタイプ変換用データファイル５８とを備えて構成され、アプリケーションにプロトコルにおけるデータタイプの相違を意識させることなく通信制御を行うことを目的としている。

では、通信制御機能でデータタイプを変換する際に用いられるデータタイプ変換用データファイル５７について説明する。

図１４（ａ）は、トナーに関する共通情報ＩＤ定義ファイル（ＸＭＬファイル）の一例を示している。また、図１４（ｂ）は、異なる値をまとめたＸＭＬファイルの一例を示しており、複数のプロトコルで取得できる機器情報のうち、各プロトコルから取得した機器情報の値が異なる場合、それらを統一して扱えるようにするためのデータタイプ変換用データファイル５８である。

例えば、機器のトナーの色を取得するには、ＳＮＭＰとＳＯＡＰの各プロトコルで取得でき、ＳＮＭＰで取得するか、ＳＯＡＰで取得するかは、機器側がサポートしているプロトコルに依存する場合について考えてみる。

ここで、「ＳＮＭＰで取得できるトナーの色は、数字で返す」、「ＳＯＡＰで取得できるトナーの色は、文字列で返す」と言うように、機器側が機器情報を返す値が統一されていない場合には、アプリケーションの機器情報を取得する処理において、数字を文字列に変換（データタイプを変換）するという処理を行うこととなり、負担がかかる。

そこで、本実施例では、図１４（ａ）にある「Ｔｏｎｅｒ」のＩＤを使って、トナー情報を取得する。

図１４（ａ）の共通情報ＩＤ定義ファイルでは、「Ｔｏｎｅｒ」をＳＮＭＰとＳＯＡＰのどちらかを用いることで、取得できる旨が定義されている。また、「ＶＡＬＵＥ」は、ＳＮＭＰもしくはＳＯＡＰの値を統一した値にするための識別子である。ここで、「ＶａｌｕｅＩＤ」は「ＴｏｎｅｒＶａｌｕｅ」であり、図１４（ｂ）のデータタイプ変換用データファイルを参照する際、「ＴｏｎｅｒＶａｌｕｅ」を参照する。

もし、ＳＮＭＰで取得した場合は、ｎａｍｅ＝"ＳＮＭＰ"、ｖａｌｕｅ＝"ｔｏｎｎｅｒ"の欄を見る。

また、ＳＯＡＰで取得した場合は、ｎａｍｅ＝"ＳＯＡＰ"、ｖａｌｕｅ＝"ｐｒｉｎｔｅｒ．ｔｏｎｎｅｒ．１"の欄を見る。

ＳＮＭＰの場合、「ｔｏｎｎｅｒ」の値が「０２」で得られた場合、以下のようにｖａｌｕｅ＝"２"の"２"を「Ｔｏｎｅｒ」の値として、アプリケーションに返す。

また、ＳＯＡＰの場合、「ｐｒｉｎｔｅｒ．ｔｏｎｎｅｒ．１」の値が"Ｒｅｄ"で得られた場合、以下のようにｖａｌｕｅ＝"２"の"２"を「Ｔｏｎｅｒ」の値として、アプリケーションに返す。

このようにして、取得された機器情報の値が数字であっても文字であっても、統一されたデータタイプに変換され、アプリケーションに返すことができる。

次に、通信制御機能において上述した、取得した機器情報の値を統一したデータタイプに変換し、データタイプの管理を行うデータタイプ管理部５８について図１５〜１７を用いて説明する。

図１５は、本発明の実施例２に係る通信制御機能におけるＤｅｖｉｃｅＧｅｔ（）の基本フローチャートである。以下の説明において、ＤｅｖｉｃｅＯｐｅｎ（）、ＤｅｖｉｃｅＣｌｏｓｅ（）及びプロトコル別通信処理については、図１０を用いて説明する。

まず、図１０（ａ）のＤｅｖｉｃｅＯｐｅｎ（）は、アプリケーションに呼ばれた際、プロトコル指定パラメータに自動を指定しておくか否かを判断し（Ｓ３１）、ＤｅｖｉｃｅＯｐｅｎ（）は、プロトコル指定の値が自動を指定された場合は（Ｓ３１でＹＥＳのルート）、プロトコル指定フラグをＯＮにしておく（Ｓ３２）。その後、初期処理を行い（Ｓ３３）、アプリケーションに返す。

アプリケーションが機器側から取得したい機器情報の情報ＩＤを指定して図１５のＤｅｖｉｃｅＧｅｔ（）を呼ぶ。ＤｅｖｉｃｅＧｅｔ（）は、プロトコル指定フラグがＯＮか否かを判断し（Ｓ４１）、プロトコル指定フラグがＯＮの時（Ｓ４１でＹＥＳのルート）、まず、指定した情報ＩＤを共通情報ＩＤ定義ファイル５２に登録されているかどうかを調べ（Ｓ４２）、登録されている場合は（Ｓ４２でＹＥＳのルート）、その情報ＩＤの情報を取り出す（Ｓ４３）。情報ＩＤを基に情報ＩＤ検索処理を呼び（Ｓ４４）、情報ＩＤ検索処理は、情報ＩＤを基に各プロトコルのプロトコル情報ＩＤ定義ファイル５５に登録されているかどうかを検索する（Ｓ４５）。その結果をＤｅｖｉｃｅＧｅｔ（）に返す。ＤｅｖｉｃｅＧｅｔ（）は、情報ＩＤが存在した場合（Ｓ４５でＹＥＳのルート）は、検出されたプロトコルと情報ＩＤを基にプロトコル別通信処理を呼び（Ｓ４６）、通信結果から得られた値を基にデータタイプ変換処理を呼び（Ｓ２０１）、ＤｅｖｉｃｅＧｅｔ（）は、通信結果（取得した機器情報）と変換結果（統一したデータタイプ）を基に戻り値を作成し、アプリケーションに返す（Ｓ４７）。一方、ステップＳ４５で情報ＩＤが存在しなかった場合（Ｓ４５でＮＯのルート）、その旨を通知する戻り値を作成し、アプリケーションに返す（Ｓ２０２）。そしてアプリケーションがＤｅｖｉｃｅＣｌｏｓｅ（）を呼ぶ。ＤｅｖｉｃｅＣｌｏｓｅ（）は、図１０（ｃ）のように後処理を行い（Ｓ４８）、その結果をアプリケーションに返す。

プロトコル別通信処理は、図１０（ｄ）により情報ＩＤを基にプロトコル情報ＩＤ定義ファイル５５に登録されているかどうかを調べる（Ｓ５１）。登録されている場合は（Ｓ５１でＹＥＳのルート）、その情報ＩＤに関する情報（該当するアクセス手順）を取得し（Ｓ５２）、その情報に従って通信処理を行い（Ｓ５３）、通信結果（取得した機器情報）をＤｅｖｉｃｅＧｅｔ（）に返す（Ｓ５４）。

図１６は、本発明の実施例２に係る通信制御機能におけるデータタイプ変換処理の基本フローチャートである。

データタイプ変換処理は、共通情報ＩＤ定義ファイル５２及びデータタイプ変換用データファイル５８を取得し（Ｓ２１１）、共通情報ＩＤの情報を基に、共通情報ＩＤ定義ファイル５２及びデータタイプ変換用データファイル５８から共通情報ＩＤに関連する情報を取り出す（Ｓ２１２）。そして指定された共通情報ＩＤの情報を基に、共通情報ＩＤに関連する情報が取り出せたかを調べる（Ｓ２１３）。取り出せた場合は（Ｓ２１３がＹＥＳのルート）、プロトコル別通信処理の通信結果と共通情報ＩＤに関連する情報とを基に、各プロトコルから取得した情報を統一した値に変換し（Ｓ２１４）、変換結果（統一されたデータタイプ）をＤｅｖｉｃｅＧｅｔ（）に返す（Ｓ２１５）。

図１７は、本発明の実施例２に係る通信制御機能の処理手順の一例を示しており、図１７のシーケンス図を参照して説明する。

まず、アプリケーションプログラムＡＰは、共通Ｉ／ＦのＯｐｅｎ関数を呼ぶ（３―１）。これにより、共通Ｉ／Ｆは、共通情報ＩＤ制御部５１、プロトコル制御部５３及び各プロトコル管理部５４に対してＯｐｅｎを要求し（３−２〜３−４）、共通情報ＩＤ制御部５１は、共通情報ＩＤ制御部５１内での初期化処理を行い、プロトコル指定が自動の場合、プロトコル制御部５３を介して各プロトコル管理部５４に対してＯｐｅｎを要求し（３−２〜３―４）、各プロトコル管理部５４は、各プロトコルの初期化処理を行い、Ｏｐｅｎ要求の処理を終えたことを共通情報ＩＤ制御部５１に通知する（３−５〜３−６）。

共通情報ＩＤ制御部５１は、プロトコル制御部５３から通知されたら、Ｏｐｅｎ要求の処理を終えたことを共通Ｉ／Ｆに通知し（３−７）、共通Ｉ／Ｆは、共通情報ＩＤ制御部５１から通知されたら、アプリケーションプログラムＡＰにＯｐｅｎ要求の処理を終えたことを通知する（３−８）。

次に、アプリケーションプログラムＡＰは、機器情報を取得するために共通Ｉ／Ｆに対して、取得したい機器情報に関するＩＤを引数（パラメータ）にＤｅｖｉｃｅＧｅｔ（）をコールすることで要求する（３−９）。ここで、機器情報に関するＩＤに、各プロトコルの情報ＩＤだけでなく、共通情報ＩＤも指定することが可能である。例えば、図８に示した機器名称を取得する場合、「Ｇｅｔ ＳｙｓｔｅｍＮａｍｅ」と要求すれば良い。

共通Ｉ／Ｆは、共通情報ＩＤ制御部５１に対して、取得したい機器情報に関するＩＤを要求し（３−１０）、共通情報ＩＤ制御部５１は、ＸＭＬ管理に、要求された情報ＩＤを基に、情報ＩＤがＸＭＬ形式で保持された定義ファイル５２、５５を検索するように要求する（３−１１）。

ＸＭＬ管理は、共通情報ＩＤ定義ファイル５２及び各プロトコル情報ＩＤ定義ファイル５５を参照して、指定されたＩＤについて調べ、指定されたＩＤが存在するか否かを判定し、存在していれば、要求されたＩＤが共通情報ＩＤの場合、ＸＭＬに記載しているプロトコル名と情報ＩＤを共通情報ＩＤ制御部５１に通知する（３−１２）。図８の例の場合であれば、「（ア）ＳＮＭＰプロトコルでＩＤ＝ｓｙｓＮａｍｅ。（イ）ＳＯＡＰプロトコルでＩＤ＝ｓｙｓｔｅｍ．ｓｙｓｔｅｍｎａｍｅ：１。（ウ）ＳＯＡＰプロトコルでＩＤ＝ｄｅｖｉｃｅ．ｎａｍｅ：１。」を通知する。また、要求された情報ＩＤがプロトコルの情報ＩＤの場合、プロトコル名とその情報ＩＤを共通情報ＩＤ制御部５１に通知する。

共通情報ＩＤ制御部５１は、ＸＭＬ管理から得られたプロトコル名とその情報ＩＤをプロトコル制御部５３を介して各プロトコル管理部５４に通知し（３−１３〜３−１４）、各プロトコル管理部５４は、指定したプロトコル名の情報ＩＤをＸＭＬ管理に通知する（３−１５）。

ＸＭＬ管理は、指定されたプロトコル名の情報ＩＤを基に、各プロトコル情報ＩＤ定義ファイル５５を検索し、該当するプロトコル情報ＩＤ定義ファイル５５から情報ＩＤのアクセス手順を取得し、各プロトコル管理部５４に通知する（３−１６）。この時、各プロトコル管理部５４に通知される情報は、例えば、取得した機器情報に給紙トレイ名が要求された場合は、図７に示すアクセス手順のＸＭＬファイルから「ｐｒｔＩｎｐｕｔＮａｍｅ」というＰｒｉｎｔｅｒ−ＭＩＢオブジェクト名が、各プロトコル管理部５４へ通知される。

次いで、各プロトコル管理部５４は、各プロトコルモジュール管理部５６にプロトコル名とその情報ＩＤのアクセス手順を通知し（３−１７）、各プロトコルモジュール管理部５６は、指定されたプロトコル名のモジュールに対して、通知されたアクセス手順に従って、機器から機器情報を取得し（３−１８〜３−１９）、取得した機器情報を各プロトコル管理部５４に通知する（３―２０）。

また、３−１４から３−２１までの処理手順は、ＸＭＬ管理から得られた全てのプロトコル名とその情報ＩＤが複数個存在する場合、その数だけ処理手順を繰り返し、全ての情報ＩＤの機器情報を取得する。

各プロトコル管理部５４は、全ての情報ＩＤの機器情報をまとめ、プロトコル制御部５３を介して、共通情報ＩＤ制御部５１に通知し（３−２１〜３−２２）、共通情報ＩＤ制御部５１は、情報ＩＤが共通情報ＩＤの場合、共通情報ＩＤ定義ファイル５２に記載されている各プロトコルの情報ＩＤの値を統一した値に変換し、まとめるようにデータタイプ管理部５７に依頼する（３−２３）。

データタイプ管理部５７は、共通情報ＩＤ定義ファイル５２及びデータタイプ変換用データファイル５７（図１４（ｂ）参照）の取得依頼をＸＭＬ管理に通知し（３−２４）、ＸＭＬ管理は、共通情報ＩＤをキーとし、共通情報ＩＤの情報とデータタイプ変換用データファイル５８から共通情報ＩＤに関連する情報を取り出し、データタイプ管理部５７に通知し（３−２５）、データタイプ管理部５７は、ＸＭＬ管理から取得した情報を参考に、各プロトコルの情報ＩＤの値を統一した値に変換し、変換後の値を、まとめて共通情報ＩＤ制御部５１に通知する（３−２６）。

共通情報ＩＤ制御部５１は、全ての情報ＩＤの機器情報を共通Ｉ／Ｆに通知し（３−２７）、共通Ｉ／Ｆは、アプリケーションプログラムＡＰに全ての情報ＩＤの機器情報を通知する（３−２８）。

これにより、アプリケーションプログラムＡＰは、取得した全ての情報ＩＤの機器情報に基づいて、適切な処理（情報表示など）を行う。そして、共通Ｉ／Ｆに「Ｃｌｏｓｅ」を要求する（３−２９）。

従って、共通Ｉ／Ｆは、共通Ｉ／Ｆ内での終了処理を行い、共通情報ＩＤ制御部５１に「Ｃｌｏｓｅ」を要求し（３−３０）、共通情報ＩＤ制御部５１は、共通情報ＩＤ制御部５１内での終了処理を行い、プロトコル制御部５３を介して各プロトコル管理部５４に「Ｃｌｏｓｅ」を要求し（３−３１〜３−３２）、各プロトコル管理部５４は、各プロトコル管理部５４内での終了処理を行い、プロトコル制御部５３を介して共通情報ＩＤ制御部５１に終了処理を終えたことを通知する（３−３３〜３−３４）。

共通情報ＩＤ制御部５１は、共通Ｉ／Ｆに終了処理を終えたことを通知し（３−３５）、共通Ｉ／Ｆは、アプリケーションプログラムＡＰに終了処理を終えたことを通知して（３−３６）、一連の通信制御機能の処理が終了する。

以上のように、本発明の実施例２によれば、アプリケーションプログラムＡＰは、機器情報を取得する際に細かいパラメータの違い（複数のプロトコルで取得できる機器情報のうち、各プロトコルで取得された機器情報の値が異なること）を意識することなく、共通情報ＩＤを指定するだけで機器との通信が可能となり、アプリケーションプログラムＡＰの負担を軽減することができる。
また、各プロトコルにおけるデータの相違を吸収することができるので、アプリケーションプログラムＡＰを実装する際の開発作業にかかる負担が軽減される。

各プロトコルから取得するデータが文字列である場合、ＳＯＡＰを用いて機器情報を取得するときのＸＭＬデータファイルは、基本的にＵＴＦ−８コードであるが、ＳＮＭＰの場合は、言語毎のキャラクターコード（日本語の場合はＳｈｉｆｔ−ＪＩＳ）が使われると言うように、機器情報を取得するためのプロトコルによって、扱う文字コード体系もプロトコル依存である。そのため、対応するプロトコルが増えるに従い、文字コードの違いも意識しなければならない。

本実施例では、上記の問題点を解決するため、複数のプロトコルで取得できる機器情報のうち、各プロトコルから取得した機器情報の値が文字列である場合、それらの文字コードをアプリケーションが指定する文字コードに変換し、扱えるようにするための通信制御機能について説明する。

本実施例と実施例１の異なる点は、実施例１の通信制御機能を基に、取得した機器情報の文字列を指定された文字コードに変換する文字コード変換機能（文字コード変換サービス）が付加された点である。

そのため、実施例１の説明で用いた、本実施例との共通点である図１のシステム構成や図２のハードウェア構成の例などについては、同一の符号を用いて説明を省略し、実施例１と異なる文字コード変換機能に関する内容を中心に説明する。

図１８は、本発明の実施例３に係る通信制御機能の主要な機能構成例を示す図である。

この通信制御機能は、共通情報ＩＤ制御部５１、共通情報ＩＤ定義ファイル５２、プロトコル制御部５３、各プロトコル管理部５４、プロトコル情報ＩＤ定義ファイル５５、各プロトコルモジュール管理部５６、データタイプ管理部５７及びデータタイプ変換用データファイル５８の他、取得した機器情報の文字列を指定された文字コードに変換する文字コード変換部５９を備えて構成され、アプリケーションにプロトコルにおける文字コードの違いを意識させることなく通信制御を行うことを目的としている。

次に、通信制御機能において上述した、取得した機器情報の文字列を指定された文字コードに変換する文字コード変換部５９について図１８〜２２を用いて説明する。

図１９は、本発明の実施例３に係る通信制御機能におけるデータタイプ変換処理の基本フローチャートである。ＤｅｖｉｃｅＯｐｅｎ（）、ＤｅｖｉｃｅＧｅｔ（）、ＤｅｖｉｃｅＣｌｏｓｅ（）及びプロトコル別通信処理については、図１０及び１５で説明した処理手順と同じため、これらの説明は省略する。

まず、データタイプ変換処理は、図１５のＤｅｖｉｃｅＧｅｔ（）から呼ばれた際に、共通情報ＩＤ定義ファイル５２及びデータタイプ変換用データファイル５８を取得し（Ｓ２１１）、共通情報ＩＤの情報を基に、共通情報ＩＤ定義ファイル５２及びデータタイプ変換用データファイル５８から共通情報ＩＤに関連する情報を取り出す（Ｓ２１２）。そして指定された共通情報ＩＤの情報を基に、共通情報ＩＤに関連する情報が取り出せたかを調べる（Ｓ２１３）。取り出せた場合は（Ｓ２１３がＹＥＳのルート）、取り出した情報が文字列かを調べる（Ｓ３０１）。文字列である場合は（Ｓ３０１がＹＥＳのルート）、文字コード変換処理を呼ぶ（Ｓ３０２）。その後、プロトコル別通信処理の通信結果と共通情報ＩＤに関連する情報とを基に、各プロトコルから取得した情報を統一した値に変換し（Ｓ２１４）、変換結果（統一したデータタイプ）をＤｅｖｉｃｅＧｅｔ（）に返す（Ｓ２１５）。

図２０は、本発明の実施例３に係る通信制御機能におけるＳｅｔＣｈａｒＣｏｄｅ（）の基本フローチャートであり、ＳｅｔＣｈａｒＣｏｄｅ（）は、アプリケーションが取得したい機器情報の文字コードを指定する関数である。

まず、ＳｅｔＣｈａｒＣｏｄｅ（）は、アプリケーションから呼ばれた際に、アプリケーションが取得したい機器情報（変換したい機器情報）の文字コードを指定し、メモリ（ＲＡＭ２３）上に一時記憶し（Ｓ３１１）、文字コードを一時記憶したことを通知する（Ｓ３１２）。

図２１は、本発明の実施例３に係る通信制御機能における文字コード変換処理の基本フローチャートである。

まず、文字コード変換処理は、データタイプ変換処理に呼ばれた際に、メモリ（ＲＡＭ２３）上に一時記憶しておいた文字コードを読み出し（Ｓ３２１）、取り出した共通情報ＩＤに関連する情報の文字列を、読み出した文字コードへ変換する（Ｓ３２２）。文字コード変換結果を、戻り値としてデータタイプ変換処理に返す（Ｓ３２３）。

図２２は、本発明の実施例３に係る通信制御機能の処理手順の一例を示しており、図２２のシーケンス図を参照して説明する。

まず、アプリケーションプログラムＡＰは、あらかじめ共通Ｉ／Ｆに使用したい文字コードを通知する（４−１）。共通Ｉ／Ｆは、文字コード変換部５９に文字コードを通知し（４−２）、文字コード変換部５９は、文字コードをメモリ（ＲＡＭ２３）上などに一時記憶し、記憶したことを共通I/Fに通知する（４−３）。そして、共通Ｉ／Ｆは、アプリケーションプログラムＡＰに記憶したことを通知する（４−４）。

次に、アプリケーションプログラムＡＰは、共通Ｉ／ＦのＯｐｅｎ関数を呼ぶ（４―５）。これにより、共通Ｉ／Ｆは、共通情報ＩＤ制御部５１、プロトコル制御部５３及び各プロトコル管理部５４に対してＯｐｅｎを要求し（４−６〜４−８）、共通情報ＩＤ制御部５１は、共通情報ＩＤ制御部５１内での初期化処理を行い、プロトコル指定が自動の場合、プロトコル制御部５３を介して各プロトコル管理部５４に対してＯｐｅｎを要求し（４−６〜４−８）、各プロトコル管理部５４は、各プロトコルの初期化処理を行い、Ｏｐｅｎ要求の処理を終えたことを共通情報ＩＤ制御部５１に通知する（４−９〜４−１０）。

共通情報ＩＤ制御部５１は、プロトコル制御部５３から通知されたら、Ｏｐｅｎ要求の処理を終えたことを共通Ｉ／Ｆに通知し（４−１１）、共通Ｉ／Ｆは、共通情報ＩＤ制御部５１から通知されたら、アプリケーションプログラムＡＰにＯｐｅｎ要求の処理を終えたことを通知する（４−１２）。

次に、アプリケーションプログラムＡＰは、機器情報を取得するために共通Ｉ／Ｆに対して、取得したい機器情報に関するＩＤを引数（パラメータ）にＤｅｖｉｃｅＧｅｔ（）をコールすることで要求する（４−１３）。ここで、機器情報に関するＩＤに、各プロトコルの情報ＩＤだけでなく、共通情報ＩＤも指定することが可能である。例えば、図８に示した機器名称を取得する場合、「Ｇｅｔ ＳｙｓｔｅｍＮａｍｅ」と要求すれば良い。

共通Ｉ／Ｆは、共通情報ＩＤ制御部５１に対して、取得したい機器情報に関するＩＤを要求し（４−１４）、共通情報ＩＤ制御部５１は、ＸＭＬ管理に、要求された情報ＩＤを基に、情報ＩＤがＸＭＬ形式で保持された定義ファイル５２、５５を検索するように要求する（４−１５）。

ＸＭＬ管理は、共通情報ＩＤ定義ファイル５２及び各プロトコル情報ＩＤ定義ファイル５５を参照して、指定されたＩＤについて調べ、指定されたＩＤが存在するか否かを判定し、存在していれば、要求されたＩＤが共通情報ＩＤの場合、ＸＭＬに記載しているプロトコル名と情報ＩＤを共通情報ＩＤ制御部５１に通知する（４−１６）。図８の例の場合であれば、「（ア）ＳＮＭＰプロトコルでＩＤ＝ｓｙｓＮａｍｅ。（イ）ＳＯＡＰプロトコルでＩＤ＝ｓｙｓｔｅｍ．ｓｙｓｔｅｍｎａｍｅ：１。（ウ）ＳＯＡＰプロトコルでＩＤ＝ｄｅｖｉｃｅ．ｎａｍｅ：１。」を通知する。また、要求された情報ＩＤがプロトコルの情報ＩＤの場合、プロトコル名とその情報ＩＤを共通情報ＩＤ制御部５１に通知する。

共通情報ＩＤ制御部５１は、ＸＭＬ管理から得られたプロトコル名とその情報ＩＤをプロトコル制御部５３を介して各プロトコル管理部５４に通知し（４−１７〜４−１８）、各プロトコル管理部５４は、指定したプロトコル名の情報ＩＤをＸＭＬ管理に通知する（４−１９）。

ＸＭＬ管理は、指定されたプロトコル名の情報ＩＤを基に、各プロトコル情報ＩＤ定義ファイル５５を検索し、該当するプロトコル情報ＩＤ定義ファイル５５から情報ＩＤのアクセス手順を取得し、各プロトコル管理部５４に通知する（４−２０）。この時、各プロトコル管理部５４に通知される情報は、例えば、取得した機器情報に給紙トレイ名が要求された場合は、図７に示すアクセス手順のＸＭＬファイルから「ｐｒｔＩｎｐｕｔＮａｍｅ」というＰｒｉｎｔｅｒ−ＭＩＢオブジェクト名が、各プロトコル管理部５４へ通知される。

次いで、各プロトコル管理部５４は、各プロトコルモジュール管理部５６にプロトコル名とその情報ＩＤのアクセス手順を通知し（４−２１）、各プロトコルモジュール管理部５６は、指定されたプロトコル名のモジュールに対して、通知されたアクセス手順に従って、機器から機器情報を取得し（４−２２〜４−２３）、取得した機器情報を各プロトコル管理部５４に通知する（４−２４）。

また、４−１８から４−２５までの処理手順は、ＸＭＬ管理から得られた全てのプロトコル名とその情報ＩＤが複数個存在する場合、その数だけ処理手順を繰り返し、全ての情報ＩＤの機器情報を取得する。

各プロトコル管理部５４は、全ての情報ＩＤの機器情報をまとめ、プロトコル制御部５３を介して、共通情報ＩＤ制御部５１に通知し（４−２４〜４−２６）、共通情報ＩＤ制御部５１は、情報ＩＤが共通情報ＩＤの場合、共通情報ＩＤ定義ファイル５２に記載されている各プロトコルの情報ＩＤの値を統一した値に変換し、まとめるようにデータタイプ管理部５７に依頼する（４−２７）。

データタイプ管理部５７は、共通情報ＩＤ定義ファイル５２及びデータタイプ変換用データファイル５７（図１４（ｂ）参照）の取得依頼をＸＭＬ管理に通知し（４−２８）、ＸＭＬ管理は、共通情報ＩＤをキーとし、共通情報ＩＤの情報とデータタイプ変換用データファイル５８から共通情報ＩＤに関連する情報を取り出し、データタイプ管理部５７に通知し（４−２９）、データタイプ管理部５７は、ＸＭＬ管理から取得した情報を参考に、各プロトコルの情報ＩＤの値を統一した値に変換し、変換後の値をまとめ。また、共通情報ＩＤ制御部５１から共通情報ＩＤの値もしくはデータタイプ変換後の値が文字列の場合、文字コード変換部５９に文字列を通知する（４−３０）。

文字コード変換部５９は、メモリ（ＲＡＭ２３）上に一時記憶していた文字コードに文字列を変換し、変換した文字列をデータタイプ管理部５７に通知し（４−３１）、データタイプ管理部５７は、共通情報ＩＤの値、データタイプ変換後の値及び文字コード変換後の値の各情報を共通情報ＩＤ制御部５１に通知する（４−３１）。

共通情報ＩＤ制御部５１は、全ての情報ＩＤの機器情報を共通Ｉ／Ｆに通知し（４−３２）、共通Ｉ／Ｆは、アプリケーションプログラムＡＰに全ての情報ＩＤの機器情報を通知する（４−３３）。

これにより、アプリケーションプログラムＡＰは、取得した全ての情報ＩＤの機器情報に基づいて、適切な処理（情報表示など）を行う。そして、共通Ｉ／Ｆに「Ｃｌｏｓｅ」を要求する（４−３４）。

従って、共通Ｉ／Ｆは、共通Ｉ／Ｆ内での終了処理を行い、共通情報ＩＤ制御部５１に「Ｃｌｏｓｅ」を要求し（４−３５）、共通情報ＩＤ制御部５１は、共通情報ＩＤ制御部５１内での終了処理を行い、プロトコル制御部５３を介して各プロトコル管理部５４に「Ｃｌｏｓｅ」を要求し（４−３６〜４−３７）、各プロトコル管理部５４は、各プロトコル管理部５４内での終了処理を行い、プロトコル制御部５３を介して共通情報ＩＤ制御部５１に終了処理を終えたことを通知する（４−３８〜４−３９）。

共通情報ＩＤ制御部５１は、共通Ｉ／Ｆに終了処理を終えたことを通知し（４−４０）、共通Ｉ／Ｆは、アプリケーションプログラムＡＰに終了処理を終えたことを通知して（４−４１）、一連の通信制御機能の処理が終了する。

以上のように、本発明の実施例３によれば、アプリケーションプログラムＡＰは、機器情報を取得する際に、プロトコルによって扱う文字コード体系による文字コードの違いを意識することなく、共通情報ＩＤを指定するだけで自動的に文字コード変換を行うことができ、機器との通信が可能となり、アプリケーションプログラムＡＰの負担を軽減することができる。

また、各プロトコルにおける文字コードの相違を吸収することができるので、アプリケーションプログラムＡＰを実装する際の開発作業にかかる負担が軽減される。

本実施例では、複数のプロトコルで取得できる機器情報のうち、各プロトコルから取得した機器情報の値が文字列である場合、それらの文字コードを統一して扱えるようにするための通信制御機能について説明する。

本実施例と実施例１及び３の異なる点は、実施例３の通信制御機能を基に、取得した機器情報の文字列を統一した文字コードに変換する統一文字コード変換機能が付加された点である。

そのため、実施例１及び３の説明で用いた、本実施例との共通点である図１のシステム構成や図２のハードウェア構成の例などについては、同一の符号を用いて説明を省略し、実施例１と異なる統一文字コード変換機能に関する内容を中心に説明する。

図２３は、本発明の実施例４に係るネットワーク層ＮＬの構成例を示す図である。

このネットワーク層ＮＬは、アプリケーションプログラムＡＰに対して機器との通信機能（情報の取得や設定など）を提供するための機能が実装されている層であり、共通Ｉ／Ｆ（共通ＡＰＩ）層、サービス層及びプロトコル層からなる。

共通Ｉ／Ｆ（共通ＡＰＩ）層ＡＰＩは、機器より取得する情報の種別などに依存しない抽象的なインタフェースをアプリケーションプログラムＡＰに対して提供するＡＰＩ（Application Program Interface）が実装されている層である。例えば、機器との通信を開始するための関数（Ｏｐｅｎ）、機器２０より情報を取得するための関数（Ｇｅｔ）、機器２０へ情報を設定するための関数（Ｓｅｔ）、機器２０との通信を終了するための関数（Ｃｌｏｓｅ）などが実装されている。共通ＡＰＩ層１３における各関数は、アプリケーションプログラムＡＰより与えられる抽象的なパラメータ（取得したい情報の種別など）や、通信を制御するためのパラメータ（タイムアウトなど）に基づいて、サービス層を呼び出す。

サービス層ＭＳは、機器情報サービスＭＳ１、機器検索サービスＭＳ２、共通ＩＤ管理サービスＭＳ３、プロトコル制御サービスＭＳ４及びＸＭＬ管理サービスＭＳ５など、それぞれのサービスに特化した機能を提供するモジュール群によって構成される。

本実施例では、このサービス層ＭＳのモジュール群に、文字コードサービスＭＳ７が機能追加されている。

文字コードサービスＭＳ７は、文字コードの取得や文字コードの変換など、文字コードに関する機能を提供するモジュール（文字コード取得方法を管理する管理手段）である。

図２４は、本発明の実施例４に係る通信制御機能の主要な機能構成例を示す図である。

この通信制御機能は、共通情報ＩＤ定義ファイル５２、プロトコル制御部５３、各プロトコル管理部５４、プロトコル情報ＩＤ定義ファイル５５、各プロトコルモジュール管理部５６の他、取得した機器情報の文字列を統一した文字コードに変換する統一文字コード変換部６０及び統一文字コード変換用のデータを保持する統一文字コード変換用データファイル６１とを備えて構成され、アプリケーションにプロトコルにおける文字コードの違いを意識させることなく通信制御を行うことを目的としている。

では、通信制御機能で文字コードを変換する際に用いられる統一文字コード変換用データファイル６１について説明する。

図２５（ａ）は、文字コードに関する共通情報ＩＤ定義ファイル（ＸＭＬファイル）の一例を示している。また、図２５（ｂ）は、文字コードに関するＸＭＬファイルの一例を示しており、複数のプロトコルで取得できる機器情報のうち、各プロトコルから取得した機器情報の文字列を統一して扱えるようにするための統一文字コード変換用データファイル（文字コード取得方法）６１である。

これらのファイルは、アプリケーションがシステム名などの機器情報を取得する際、その情報がどのような文字コード体系になっているかを通知しないと文字化け現象が発生することが考えられる。そこで、アプリケーションの文字化けを防ぐために、機器情報とその情報に使われている文字コードをアプリケーション側に提供しようというものである。

例えば、機器情報を取得する際、様々なプロトコルを使用する。例えば、ＳＮＭＰやＳ
ＯＡＰなどが代表的なものである。ＳＮＭＰの文字コードは、各ＭＩＢ（Management Information Base）に使用する文字コードＭＩＢというものがある。

図２５の例では、ｓｙｓＮａｍｅというＭＩＢ ＩＩ オブジェクト名の場合、ｐｒｔＬｏｃａｌｉｚａｔｉｏｎＣｈａｒａｃｔｅｒＳｅｔの値で文字コードＭＩＢを参照するという意味であり、その文字コードＭＩＢを参照する際のキーワードがＣｏｄｅで表されている。

ｐｒｔＬｏｃａｌｉｚａｔｉｏｎＣｈａｒａｔｅｒＳｅｔには、他のプロトコルとの整合性を保つために、世界共通の文字コード（参考ＵＲＬ：http://www.iana.org/assignments/character-sets）を設定値として、アプリケーションに提供する。ここで言う世界共通の文字コードとは、コンピュータを使った情報交換が円滑にできるように国際標準として定めた文字セット（キャラクタセット）のうち、文字セットの中で一つ一つの文字を識別するために固有の番号を割り当てられたものである。

例えば、ｐｒｔＬｏｃａｌｉｚａｔｉｏｎＣｈａｒａｃｔｅｒＳｅｔの値が１０６の場合、ＵＴＦ−８の文字コードになる。

また、ＳＯＡＰの場合は、ＸＭＬデータに記載されているｅｎｃｏｄｉｎｇの値に世界共通の文字コードと同じコードが設定されているため、その設定値をそのままアプリケーションに返す。例えば、＜？ＸＭＬ Ｖｅｒｓｉｏｎ＝"１．０" ｅｎｃｏｄｉｎｇ＝"ＵＴＦ―８"＞の場合、ＵＴＦ−８が文字コードである。

このように、アプリケーションに機器情報を返す際、その情報の文字コードとして、世界で統一された（世界共通の）文字コードを返すことによって、文字化けを防ぐことができる。

次に、通信制御機能において上述した、取得した機器情報の文字列を統一した文字コードに変換する統一文字コード変換部６０について図２６〜２８を用いて説明する。

図２６は、本発明の実施例４に係る通信制御機能におけるＤｅｖｉｃｅＧｅｔ（）の基本フローチャートである。以下の説明において、ＤｅｖｉｃｅＯｐｅｎ（）、ＤｅｖｉｃｅＣｌｏｓｅ（）及びプロトコル別通信処理については、図９を用いて説明する。

まず、図９（ａ）のＤｅｖｉｃｅＯｐｅｎ（）は、アプリケーションに呼ばれた際、プロトコル指定パラメータに自動を指定しておくか否かを判断し（Ｓ１）、ＤｅｖｉｃｅＯｐｅｎ（）は、プロトコル指定の値が自動を指定された場合（Ｓ１でＹＥＳのルート）、プロトコル指定フラグをＯＮにしておく（Ｓ２）。その後、初期処理を行い（Ｓ３）、アプリケーションに返す。アプリケーションが機器側から取得したい機器情報の情報ＩＤを指定して図２６のＤｅｖｉｃｅＧｅｔ（）を呼ぶ。ＤｅｖｉｃｅＧｅｔ（）は、プロトコル指定フラグがＯＮか否かを判断し（Ｓ１１）、プロトコル指定フラグがＯＮの時（Ｓ１１でＹＥＳのルート）、情報ＩＤを基に情報ＩＤ検索処理を呼び（Ｓ１２）、情報ＩＤ検索処理は、情報ＩＤを基に各プロトコルのプロトコル情報ＩＤ定義ファイル５５に登録されているかどうかを検索する（Ｓ１３）。その結果をＤｅｖｉｃｅＧｅｔ（）に返す。ＤｅｖｉｃｅＧｅｔ（）は、情報ＩＤが存在した場合（Ｓ１３でＹＥＳのルート）、検出されたプロトコルと情報ＩＤを基にプロトコル別通信処理を呼ぶ（Ｓ１４）。ＤｅｖｉｃｅＧｅｔ（）は、プロトコル別通信処理からの通信結果に対して、取得した情報が文字列であるかを調べる（Ｓ４０１）。文字列であった場合（Ｓ４０１でＹＥＳのルート）、統一文字コード変換処理を呼び（４０２）、ＤｅｖｉｃｅＧｅｔ（）は、通信結果（取得した機器情報）と変換結果（統一した文字コード）とを基に戻り値を作成し、アプリケーションに返す（Ｓ１５）。一方、ステップＳ４０１で取得した情報が文字列でなかった場合（Ｓ４０１でＮＯのルート）、統一文字コード変換処理を呼ばず、ＤｅｖｉｃｅＧｅｔ（）は、プロトコル別通信処理からの通信結果（取得した機器情報）を基に戻り値を作成し、アプリケーションに返す（Ｓ１５）。

また、ステップＳ１３で情報ＩＤが存在しなかった場合（Ｓ１３でＮＯのルート）、その旨を通知する戻り値を作成し、アプリケーションに返す（Ｓ１５）。そしてアプリケーションがＤｅｖｉｃｅＣｌｏｓｅ（）を呼ぶ。ＤｅｖｉｃｅＣｌｏｓｅ（）は、図９（ｃ）のように後処理を行い（Ｓ２１）、その結果をアプリケーションに返す。

プロトコル別通信処理は、図９（ｄ）により情報ＩＤを基にプロトコル情報ＩＤ定義ファイル５５に登録されているかどうかを調べる（Ｓ２２）。登録されている場合は（Ｓ２２でＹＥＳのルート）、その情報ＩＤに関する情報（該当するアクセス手順）を取得し（Ｓ２３）、その情報に従って通信処理を行い（Ｓ２４）、通信結果（取得した機器情報）をＤｅｖｉｃｅＧｅｔ（）に返す（Ｓ２５）。

図２７は、本発明の実施例４に係る通信制御機能における統一文字コード変換処理の基本フローチャートである。

統一文字コード変換処理は、取得した文字コードに関する情報を基に、統一文字コード変換用データファイルを参照し（Ｓ４１１）、該当する統一文字コードに変換する（Ｓ４１２）。そして、変換結果（統一した文字コード）をＤｅｖｉｃｅＧｅｔ（）に返す（Ｓ４１３）。

図２８は、本発明の実施例４に係る通信制御機能の処理手順の一例を示しており、図２８のシーケンス図を参照して説明する。

まず、アプリケーションプログラムＡＰは、共通Ｉ／ＦのＯｐｅｎ関数を呼ぶ（５−１）。これにより、共通Ｉ／Ｆは、プロトコル制御部５３を介して各プロトコル管理部５４に対してＯｐｅｎを要求し（５−２〜５−３）、各プロトコル管理部５４は、各プロトコルの初期化処理を行い、Ｏｐｅｎ要求の処理を終えたことを、プロトコル制御部５３を介して共通Ｉ／Ｆ管理に通知する（５−４〜５―５）。また、共通Ｉ／Ｆは、プロトコル制御部５３から通知されたら、アプリケーションプログラムＡＰにＯｐｅｎ要求の処理を終えたことを通知する（５−６）。

次に、アプリケーションプログラムＡＰは、機器情報を取得するために共通Ｉ／Ｆに対して、取得したい機器情報に関する情報ＩＤを引数（パラメータ）にＤｅｖｉｃｅＧｅｔ（）をコールすることで要求する（５−７）。共通Ｉ／Ｆは、プロトコル制御部５３を介して各プロトコル管理部５４に対して、取得したい機器情報に関する情報ＩＤを要求し（５−８〜５−９）、各プロトコル管理部５４は、共通Ｉ／Ｆから要求された取得したい機器情報に関する情報ＩＤの各ＩＤについて、ＸＭＬ管理に、要求された情報ＩＤを基に、情報ＩＤがＸＭＬ形式で保持された情報ＩＤ定義ファイル５２、５５を検索するように要求する（５−１０）。

ＸＭＬ管理は、文字コードに関する共通情報ＩＤ定義ファイル（図２５参照）から情報ＩＤについての情報を取得し、各プロトコル管理部５４に通知する（５−１１）。例えば、取得したい機器情報が機器名称で、情報ＩＤがｓｙｓＮａｍｅの場合、共通情報ＩＤ定義ファイルからは、「＜Ｐｒｏｐｅｒｔｙ ＩＤ＝"ｓｙｓＮａｍｅ" ｃｏｎｔｒｏｌｌｅｒ＝"ＳｔｒｉｎｇＰｒｏｐｅｒｔｙＣｏｎｔｒｏｌｌｅｒ" ｃｏｎｔｒｏｌｌｅｒＴｙｐｅ＝"Ｇｅｔ"＞、＜Ｐａｒａｍ ＩＤ＝"１" ｎａｍｅ＝"Ｃｏｄｅ"， ｖａｌｕｅ＝"ｐｒｔＬｏｃａｌｉｚａｔｉｏｎＣｈａｒａｃｔｅｒＳｅｔ" ／＞、＜Ｐａｒａｍ ＩＤ＝"１" ｎａｍｅ＝"ｍｉｂＮａｍｅ"， ｖａｌｕｅ＝"ｓｙｓＮａｍｅ"＞」という情報が得られる。ここで、「Ｐｒｏｐｅｒｔｙ ＩＤ」は、情報ＩＤ名を表し、「ｃｏｎｔｒｏｌｌｅｒ」は、ネットワーク層ＮＬ内部での制御関数名を表し、「ｃｏｎｎｔｒｏｌｌｅｒＴｙｐｅ」は、処理動作概要を表す（「Ｇｅｔ」は、「取得」と言う意味）。また、「Ｐａｒａｍ ＩＤ」は、各種プロトコル情報を表し、「ｎａｍｅ」は、ネットワーク層ＮＬ内部での記述子を表し、「Ｖａｌｕｅ」は、プロトコル内容に関する情報を表す。また、「Ｃｏｄｅ」は、文字コードに関する情報であり、文字コード情報元がｐｒｔＬｏｃａｌｉｚａｔｉｏｎＣｈａｒａｃｔｅｒＳｅｔのＭＩＢオブジェクトＩＤで表される。また、「ｍｉｂＮａｍｅ」は、ＭＩＢオブジェクト名であり、「ｓｙｓＮａｍｅ」の情報元がｓｙｓＮａｍｅのＭＩＢオブジェクトＩＤで表される。

各プロトコル管理５４は、ＸＭＬ管理から得られた情報を各プロトコルモジュール管理部５６に通知し（５−１２）、各プロトコルモジュール管理５６は、ＸＭＬ管理から得られた情報を基に指定したプロトコル名のモジュールに対して、機器側から機器情報を取得して、各プロトコル管理部５４に通知する（５−１３〜５−１５）。例えば、ｓｙｓＮａｍｅとｐｒｔＬｏｃａｌｉｚａｔｉｏｎＣｈａｒａｃｔｅｒＳｅｔのＭＩＢオブジェクトＩＤの値を機器側から取得する。

次いで、各プロトコル管理部５４は、取得した情報の中に文字コード（Ｃｏｄｅ）に関する情報がある場合、文字コードの情報（ｐｒｔＬｏｃａｌｉｚａｔｉｏｎＣｈａｒａｃｔｅｒＳｅｔに関する情報）を文字コード管理部６０に通知する（５−１６）。

文字コード管理部６０は、文字コードの情報を基にＸＭＬ管理に統一文字コードへの変換を通知する（５−１７）。文字コード管理部６０が通知する文字コードの情報は、文字コードをＩＤや略号など、プロトコルによって表現が異なっている。例えば、ＳＮＭＰの場合は、Ｐｒｉｎｔｅｒ−ＭＩＢのｐｒｔＬｏｃａｌｉｚａｔｉｏｎＣｈａｒａｃｔｅｒＳｅｔの値が、世界共通の文字コード（参照ＵＲＬ：http://www.iana.org/assignments/character-sets）のＭＩＢｅｎｕｍ番号（ＩＤ）で表されており、Ｓｈｉｆｔ−ＪＩＳの場合は、１７もしくは２０２４である。

また、ＳＯＡＰの場合は、ＸＭＬデータに記載されているｅｎｃｏｄｉｎｇが文字コードを表しており、ＸＭＬデータが、＜？ＸＭＬ Ｖｅｒｓｉｏｎ＝"１．０" ｅｎｃｏｄｉｎｇ＝"ＵＴＦ―８"＞の場合、ＵＴＦ−８が文字コードである。

このように、各プロトコルによって異なる文字コードの情報を、統一した文字コードに変換し、変換結果を返すようにする。

ＸＭＬ管理は、文字コードの情報を基に統一文字コードに変換し、変換結果（統一文字コード）を文字コード管理部６０に通知する（５−１８）。例えば、文字コードをＭＩＢｅｎｕｍ番号として返す場合、ＸＭＬデータに記載されているｅｎｃｏｄｉｎｇがＵＴＦ−８であれば、ＵＴＦ−８をキーに、図２５（ｂ）の統一文字コード変換用データファイル６１を参照し、１０６に変換される。

文字コード管理部６０は、統一文字コードを各プロトコル管理部５４に通知し（５−１９）、各プロトコル管理部５４は、機器情報及び統一文字コードを、プロトコル制御部５３を介して共通Ｉ／Ｆに通知し（５−２０〜５−２１）、共通Ｉ／Ｆは、アプリケーションプログラムＡＰに機器情報及び統一文字コードを通知する（５−２２）。

そして、アプリケーションプログラムＡＰは、共通Ｉ／ＦにＣｌｏｓｅを要求し（５−２３）、共通Ｉ／Ｆは、プロトコル制御部５３を介して各プロトコル管理部５４にＣｌｏｓｅを要求し（５−２４〜５−２５）、各プロトコル管理部５４は、各プロトコル管理部５４内での終了処理を行い、プロトコル制御部５３を介して共通Ｉ／Ｆに終了処理を終えたことを通知する（５−２６〜５−２７）。それにより、共通Ｉ／Ｆは、アプリケーションプログラムＡＰに終了処理を終えたことを通知する（５−３０）。

以上のように、本発明の実施例４によれば、アプリケーションプログラムＡＰは、機器情報を取得する際に、文字コードを取得する必要がなく、プロトコルによって扱う文字コード体系による文字コードの違いを意識することなく、機器との通信が可能となり、アプリケーションプログラムＡＰの負担を軽減することができる。

本実施例では、複数のプロトコルで取得できる機器情報のうち、各プロトコルから取得した機器情報の値が文字列であり、かつ文字列の文字コードに関する情報がない場合でも、扱えるようにするための通信制御機能について説明する。

本実施例と実施例１及び３の異なる点は、実施例３の通信制御機能を基に、取得した機器情報の文字列について文字コードの解析を行う文字コード解析機能が付加された点である。

そのため、実施例１及び３の説明で用いた、本実施例との共通点である図１のシステム構成や図２のハードウェア構成の例などについては、同一の符号を用いて説明を省略し、実施例１と異なる文字コード解析機能に関する内容を中心に説明する。

図２９は、本発明の実施例５に係る通信制御機能の主要な機能構成例を示す図である。

この通信制御機能は、共通情報ＩＤ定義ファイル５２、プロトコル制御部５３、各プロトコル管理部５４、プロトコル情報ＩＤ定義ファイル５５、各プロトコルモジュール管理部５６、統一文字コード変換部６０及び統一文字コード変換用データファイル６１の他、取得した機器情報の文字列の文字コードを解析する文字コード解析部６２を備えて構成され、各プロトコルから取得した機器情報の文字列の文字コードに関する情報がない場合でも、アプリケーションにプロトコルにおける文字コードの違いを意識させることなく通信制御を行うことを目的としている。

次に、通信制御機能において上述した、取得した機器情報の文字列を統一した文字コードに変換する統一文字コード変換部６０について図３０〜３２を用いて説明する。

図３０は、本発明の実施例５に係る通信制御機能におけるＤｅｖｉｃｅＧｅｔ（）の基本フローチャートである。以下の説明において、ＤｅｖｉｃｅＯｐｅｎ（）、ＤｅｖｉｃｅＣｌｏｓｅ（）及びプロトコル別通信処理については、図９を用いて説明する。

まず、図９（ａ）のＤｅｖｉｃｅＯｐｅｎ（）は、アプリケーションに呼ばれた際、プロトコル指定パラメータに自動を指定しておくか否かを判断し（Ｓ１）、ＤｅｖｉｃｅＯｐｅｎ（）は、プロトコル指定の値が自動を指定された場合（Ｓ１でＹＥＳのルート）、プロトコル指定フラグをＯＮにしておく（Ｓ２）。その後、初期処理を行い（Ｓ３）、アプリケーションに返す。アプリケーションが機器側から取得したい機器情報の情報ＩＤを指定して図２６のＤｅｖｉｃｅＧｅｔ（）を呼ぶ。ＤｅｖｉｃｅＧｅｔ（）は、プロトコル指定フラグがＯＮか否かを判断し（Ｓ１１）、プロトコル指定フラグがＯＮの時（Ｓ１１でＹＥＳのルート）、情報ＩＤを基に情報ＩＤ検索処理を呼び（Ｓ１２）、情報ＩＤ検索処理は、情報ＩＤを基に各プロトコルのプロトコル情報ＩＤ定義ファイル５５に登録されているかどうかを検索する（Ｓ１３）。その結果をＤｅｖｉｃｅＧｅｔ（）に返す。ＤｅｖｉｃｅＧｅｔ（）は、情報ＩＤが存在した場合（Ｓ１３でＹＥＳのルート）、検出されたプロトコルと情報ＩＤを基にプロトコル別通信処理を呼ぶ（Ｓ１４）。ＤｅｖｉｃｅＧｅｔ（）は、プロトコル別通信処理からの通信結果に対して、取得した情報が文字列であり、かつ文字コードに関する情報があるかを調べる（Ｓ５０１）。文字列で、かつ文字コードに関する情報があった場合（Ｓ５０１でＹＥＳのルート）、統一文字コード変換処理を呼び（４０２）、ＤｅｖｉｃｅＧｅｔ（）は、通信結果（取得した機器情報）と変換結果（統一した文字コード）を基に戻り値を作成し、アプリケーションに返す（Ｓ１５）。一方、ステップＳ５０１で取得した情報が文字列でなかった場合（Ｓ５０１で「文字列でない場合」のルート）、統一文字コード変換処理を呼ばず、ＤｅｖｉｃｅＧｅｔ（）は、プロトコル別通信処理からの通信結果（取得した機器情報）を基に戻り値を作成し、アプリケーションに返す（Ｓ１５）。また、ステップＳ５０１で取得した情報が文字列で、かつ文字コードに関する情報がない場合（Ｓ５０１で「文字コードに関する情報がない場合」のルート）、文字データ解析処理を呼び（Ｓ５０２）、解析処理後、解析結果（文字コードの情報）を基に、統一文字コード変換処理を行い（Ｓ４０２）、ＤｅｖｉｃｅＧｅｔ（）は、統一文字コード変換処理からの変換結果を基に戻り値を作成し、アプリケーションに返す（Ｓ１５）。

また、ステップＳ１３で情報ＩＤが存在しなかった場合（Ｓ１３でＮＯのルート）、その旨を通知する戻り値を作成し、アプリケーションに返す（Ｓ１５）。そしてアプリケーションがＤｅｖｉｃｅＣｌｏｓｅ（）を呼ぶ。ＤｅｖｉｃｅＣｌｏｓｅ（）は、図９（ｃ）のように後処理を行い（Ｓ２１）、その結果をアプリケーションに返す。

プロトコル別通信処理は、図９（ｄ）により情報ＩＤを基にプロトコル情報ＩＤ定義ファイル５５に登録されているかどうかを調べる（Ｓ２２）。登録されている場合は（Ｓ２２でＹＥＳのルート）、その情報ＩＤに関する情報（該当するアクセス手順）を取得し（Ｓ２３）、その情報に従って通信処理を行い（Ｓ２４）、通信結果（取得した機器情報）をＤｅｖｉｃｅＧｅｔ（）に返す（Ｓ２５）。

図３１は、本発明の実施例５に係る通信制御機能における文字コード解析処理の基本フローチャートである。

文字コード解析処理は、取得した機器情報の文字列に対して文字コードの解析を行い（Ｓ５１１）、解析結果（解析後の文字コード）をＤｅｖｉｃｅＧｅｔ（）に返す（Ｓ５１２）。

図３２は、本発明の実施例５に係る通信制御機能の処理手順の一例を示しており、図３２のシーケンス図を参照して説明する。

まず、アプリケーションプログラムＡＰは、共通Ｉ／ＦのＯｐｅｎ関数を呼ぶ（６−１）。これにより、共通Ｉ／Ｆは、プロトコル制御部５３を介して各プロトコル管理部５４に対してＯｐｅｎを要求し（６−２〜６−３）、各プロトコル管理部５４は、各プロトコルの初期化処理を行い、Ｏｐｅｎ要求の処理を終えたことを、プロトコル制御部５３を介して共通Ｉ／Ｆ管理に通知する（６−４〜６―５）。また、共通Ｉ／Ｆは、プロトコル制御部５３から通知されたら、アプリケーションプログラムＡＰにＯｐｅｎ要求の処理を終えたことを通知する（６−６）。

次に、アプリケーションプログラムＡＰは、機器情報を取得するために共通Ｉ／Ｆに対して、取得したい機器情報に関する情報ＩＤを引数（パラメータ）にＤｅｖｉｃｅＧｅｔ（）をコールすることで要求する（６−７）。共通Ｉ／Ｆは、プロトコル制御部５３を介して各プロトコル管理部５４に対して、取得したい機器情報に関する情報ＩＤを要求し（６−８〜６−９）、各プロトコル管理部５４は、共通Ｉ／Ｆから要求された取得したい機器情報に関する情報ＩＤの各ＩＤについて、ＸＭＬ管理に、要求された情報ＩＤを基に、情報ＩＤがＸＭＬ形式で保持された情報ＩＤ定義ファイル５２、５５を検索するように要求する（６−１０）。

ＸＭＬ管理は、文字コードに関する共通情報ＩＤ定義ファイル（図２５（ａ）参照）から情報ＩＤについての情報を取得し、各プロトコル管理部５４に通知する（６−１１）。

各プロトコル管理５４は、ＸＭＬ管理から得られた情報を各プロトコルモジュール管理部５６に通知し（６−１２）、各プロトコルモジュール管理５６は、ＸＭＬ管理から得られた情報を基に指定したプロトコル名のモジュールに対して、機器側から機器情報を取得して、各プロトコル管理部５４に通知する（６−１３〜６−１５）。例えば、ｓｙｓＮａｍｅとｐｒｔＬｏｃａｌｉｚａｔｉｏｎＣｈａｒａｃｔｅｒＳｅｔのＭＩＢオブジェクトＩＤの値を機器側から取得する。

ここで、各プロトコル管理部５４は、取得した情報の中に文字コードに関する情報が含まれているかどうかを調べ、文字コードに関する情報が含まれていない場合には、文字コード解析部６２に機器情報（文字列）を通知する（６−１６）。

文字コード解析部６２は、機器情報に書かれている文字コードを解析し、解析結果（文字コードの情報）を各プロトコル管理部５４に通知し（６−１７）、各プロトコル管理部５４は、解析結果を文字コード管理６０に通知する（６−１８）。

また、各プロトコル管理部５４は、取得した情報の中に文字コードに関する情報が含まれているかどうかを調べた際に、文字コードに関する情報が含まれている場合には、各プロトコル管理部５４は、取得した文字コードの情報を文字コード管理部６０に通知する（６−１８）。

文字コード管理部６０は、文字コードの情報を基にＸＭＬ管理に統一文字コードへの変換を通知する（６−１９）。

ＸＭＬ管理は、文字コードの情報を基に統一文字コードに変換し、変換結果（統一文字コード）を文字コード管理部６０に通知する（６−２０）。例えば、文字コードをＭＩＢｅｎｕｍ番号として返す場合、ＸＭＬデータに記載されているｅｎｃｏｄｉｎｇがＵＴＦ−８であれば、ＵＴＦ−８をキーに、図２５（ｂ）の統一文字コード変換用データファイル６１を参照し、１０６に変換される。

文字コード管理部６０は、統一文字コードを各プロトコル管理部５４に通知し（６−２１）、各プロトコル管理部５４は、機器情報及び統一文字コードを、プロトコル制御部５３を介して共通Ｉ／Ｆに通知し（６−２２〜６−２３）、共通Ｉ／Ｆは、アプリケーションプログラムＡＰに機器情報及び統一文字コードを通知する（６−２４）。

そして、アプリケーションプログラムＡＰは、共通Ｉ／ＦにＣｌｏｓｅを要求し（６−２５）、共通Ｉ／Ｆは、プロトコル制御部５３を介して各プロトコル管理部５４にＣｌｏｓｅを要求し（６−２６〜６−２７）、各プロトコル管理部５４は、各プロトコル管理部５４内での終了処理を行い、プロトコル制御部５３を介して共通Ｉ／Ｆに終了処理を終えたことを通知する（６−２８〜６−２９）。それにより、共通Ｉ／Ｆは、アプリケーションプログラムＡＰに終了処理を終えたことを通知する（６−３０）。

以上のように、本発明の実施例５によれば、アプリケーションプログラムＡＰは、機器情報を取得する際に、文字コードを取得する必要がなく、プロトコルによって扱う文字コード体系による文字コードの違いを意識することなく、機器との通信が可能となり、アプリケーションプログラムＡＰの負担を軽減することができる。

また、機器情報の文字列から文字コードを判別しているので、文字コードを判別する処理を行う必要がなく、各プロトコルにおける文字コードの相違を吸収することができるので、アプリケーションプログラムＡＰを実装する際の開発作業にかかる負担が軽減される。

本実施例では、これまでに説明した実施例３、４及び５の通信制御機能を組み合わせ、機器情報の値である文字列を適切な文字コードに変換する通信制御機能について説明する。

本実施例は、実施例３の文字コード変換処理、実施例４の統一文字コード変換処理及び実施例５の文字コード解析処理を組み合わせ、取得した機器情報の文字列に対して統一文字コード変換又は文字コード解析処理を行い、変換又は解析結果を基に、文字コード変換処理を用いて、文字コードの変換を行う通信制御機能である。

そのため、実施例１、３、４及び５の説明で用いた、本実施例との共通点である図１のシステム構成や図２のハードウェア構成の例などについては、同一の符号を用いて説明を省略し、文字コードに関する内容を中心に説明する。

図３３は、本発明の実施例６に係る通信制御機能の主要な機能構成例を示す図である。

この通信制御機能は、共通情報ＩＤ定義ファイル５２、プロトコル制御部５３、各プロトコル管理部５４、プロトコル情報ＩＤ定義ファイル５５、各プロトコルモジュール管理部５６、文字コード変換部５９、統一文字コード変換部６０、統一文字コード変換用データファイル６１及び文字コード解析部６２とを備えて構成され、アプリケーションにプロトコルにおける文字コードの違いを意識させることなく通信制御を行うことを目的としている。

図３４は、本発明の実施例６に係る通信制御機能の処理手順の一例を示しており、図３４のシーケンス図を参照して説明する。

まず、アプリケーションプログラムＡＰは、共通Ｉ／ＦのＯｐｅｎ関数を呼ぶ（７−１）。これにより、共通Ｉ／Ｆは、プロトコル制御部５３を介して各プロトコル管理部５４に対してＯｐｅｎを要求し（７−２〜７−３）、各プロトコル管理部５４は、各プロトコルの初期化処理を行い、アプリケーションプログラムＡＰから指定された文字コードがある場合は、指定文字コードを文字コード変換部５９に通知する（７−４）。

文字コード変換部５９は、指定文字コードが存在するかどうかを調べるために、文字コード管理部６１に指定文字コードを通知し（７−５）、文字コード管理部６１は、指定文字コードをXML管理に通知する（７−６）。XML管理は、文字コードに関する共通情報ＩＤ定義ファイル（図２５（ａ）参照）を参照し、指定文字コードが存在するかどうかを調べ、その結果を文字コード管理部６１に通知し（７−７）、文字コード管理部６１は、結果を文字コード変換部５９に通知し（７−８）、文字コード変換部５９は、結果を各プロトコル管理部５４に通知し（７−９）、各プロトコル管理部５４は、各プロトコルの初期化処理を行い、Ｏｐｅｎ要求の処理を終えたことを、プロトコル制御部５３を介して共通Ｉ／Ｆ管理に通知する（７−１０〜７−１１）。

また、共通Ｉ／Ｆは、各プロトコル管理部５４から通知されたら、アプリケーションにＯｐｅｎ要求の処理を終えたことを通知する（７−１２）。

次に、アプリケーションプログラムＡＰは、機器情報を取得するために共通Ｉ／Ｆに対して、取得したい機器情報に関する情報ＩＤを引数（パラメータ）にＤｅｖｉｃｅＧｅｔ（）をコールすることで要求する（７−１３）。共通Ｉ／Ｆは、プロトコル制御部５３を介して各プロトコル管理部５４に対して、取得したい機器情報に関する情報ＩＤを要求し（７−１４〜７−１５）、各プロトコル管理部５４は、共通Ｉ／Ｆから要求された取得したい機器情報に関する情報ＩＤの各ＩＤについて、ＸＭＬ管理に、要求された情報ＩＤを基に、情報ＩＤがＸＭＬ形式で保持された情報ＩＤ定義ファイル５２、５５を検索するように要求する（７−１６）。

ＸＭＬ管理は、文字コードに関する共通情報ＩＤ定義ファイル（図２５（ａ）参照）から情報ＩＤについての情報を取得し、各プロトコル管理部５４に通知する（７−１７）。

各プロトコル管理部５４は、ＸＭＬ管理から得られた情報を各プロトコルモジュール管理部５６に通知し（７−１８）、各プロトコルモジュール管理部５６は、ＸＭＬ管理から得られた情報を基に指定したプロトコル名のモジュールに対して、機器側から機器情報を取得して、各プロトコル管理部５４に通知する（７−１９〜７−２１）。

ここで、各プロトコル管理部５４は、取得した情報の中に文字コードに関する情報が含まれているかどうかを調べ、文字コードに関する情報が含まれていない場合には、文字コード解析部６２に機器情報（文字列）を通知する（７−２２）。

文字コード解析部６２は、機器情報に書かれている文字コードを解析し、解析結果（文字コードの情報）を各プロトコル管理部５４に通知し（７−２３）、各プロトコル管理部５４は、解析結果を文字コード管理部６０に通知する（７−２４）。

また、各プロトコル管理部５４は、取得した情報の中に文字コードに関する情報が含まれているかどうかを調べた際に、文字コードに関する情報が含まれている場合には、各プロトコル管理部５４は、取得した文字コードの情報を文字コード管理部６０に通知する（７−２４）。

文字コード管理部６０は、文字コードの情報を基にＸＭＬ管理に統一文字コードへの変換を通知する（７−２５）。

ＸＭＬ管理は、文字コードの情報を基に統一文字コードに変換し、変換結果（統一文字コード）を文字コード管理部６０に通知する（７−２６）。例えば、文字コードをＭＩＢｅｎｕｍ番号として返す場合、ＸＭＬデータに記載されているｅｎｃｏｄｉｎｇがＵＴＦ−８であれば、ＵＴＦ−８をキーに、図２５（ｂ）の統一文字コード変換用データファイル６１を参照し、１０６に変換される。

文字コード管理部６０は、統一文字コードを各プロトコル管理部５４に通知し（７−２７）、各プロトコル管理部５４は、機器情報及び統一文字コードを文字コード変換部５９へ通知し（７−２８）、文字コード変換部５９は、文字コード解析部６２の解析結果である文字コードとあらかじめ指定された指定文字コードとを比較し、互いの文字コードが異なる場合、機器情報及び統一文字コードを指定文字コードに変換し、変換した機器情報及び指定文字コードを各プロトコル管理部５４に通知する（７−２９）。解析結果である文字コードと指定文字コードが一致する場合は、文字コード変換を行わない。

各プロトコル管理部５４は、変換した機器情報及び指定文字コードを、プロトコル制御部５３を介して共通Ｉ／Ｆに通知し（７−３０〜７−３１）、共通Ｉ／Ｆは、アプリケーションプログラムＡＰに機器情報及び統一文字コードを通知する（７−３２）。

そして、アプリケーションプログラムＡＰは、共通Ｉ／ＦにＣｌｏｓｅを要求し（７−３３）、共通Ｉ／Ｆは、プロトコル制御部５３を介して各プロトコル管理部５４にＣｌｏｓｅを要求し（７−３４〜７−３５）、各プロトコル管理部５４は、各プロトコル管理部５４内での終了処理を行い、プロトコル制御部５３を介して共通Ｉ／Ｆに終了処理を終えたことを通知する（７−３６〜７−３７）。それにより、共通Ｉ／Ｆは、アプリケーションプログラムＡＰに終了処理を終えたことを通知する（７−３８）。

以上のように、本発明の実施例６によれば、アプリケーションプログラムＡＰは、機器情報を取得する際に、文字コードを取得する必要がなく、プロトコルによって扱う文字コード体系による文字コードの違いを意識することなく、自動的に文字コード変換を行って機器との通信が可能となり、アプリケーションプログラムＡＰの負担を軽減することができる。

また、機器情報の文字列から文字コードを判別しているので、文字コードを判別する処理を行う必要がなく、各プロトコルにおける文字コードの相違を吸収することができるの
また、各プロトコルにおける文字コードの相違を吸収することができるので、アプリケーションプログラムＡＰを実装する際の開発作業にかかる負担が軽減される。

なお、上述した実施例では、図１に示したようなネットワークシステムに本発明を適用した場合について説明したが、それ以外の適宜な通信制御装置について、本発明を同様にして適用することができる。

また、本発明の通信制御機能は、実施例１〜６で説明した処理手順を通信制御プログラムとして設計・開発し、開発したプログラムをＣＰＵ２１において実行する（演算処理する）ことで機能する。よって、コンピュータなどのＣＰＵ２１を備えた情報処理装置ＷＳ１〜ＷＳｎが読み取り可能な記憶媒体に格納することができる。

最後に、上記実施例に挙げた形状に、その他の要素との組み合わせなど、ここで示した要件に、本発明が限定されるものではない。

これらの点に関しては、本発明の主旨をそこなわない範囲で変更することが可能であり、その応用形態に応じて適切に定めることができる。

本発明の実施例１に係るネットワークシステムの一例を示す図である。 本発明の実施例１に係る画像形成装置の構成例を示す図である。 本発明の実施例１に係る情報処理装置の構成例を示す図である。 本発明の実施例１に係る情報処理装置におけるソフトウェア構成の要部（部分）を示す図である。 本発明の実施例１に係るネットワーク層のより詳細な構成例を示す図である。 本発明の実施例１に係る機器情報のカテゴリの例を示す図である。 本発明の実施例１に係る通信制御機能の主要な機能構成例を示す図である。 本発明の実施例１に係るアクセス手順のＸＭＬファイルの一例を示す図である。 本発明の実施例１に係る機器名称に関する共通情報ＩＤ定義ファイルの一例を示す図である。 本発明の実施例１に係る通信制御機能（情報ＩＤがプロトコル情報ＩＤで指定可能な場合）におけるＤｅｖｉｃｅＯｐｅｎ（）の基本フローチャートである。 本発明の実施例１に係る通信制御機能（情報ＩＤがプロトコル情報ＩＤで指定可能な場合）におけるＤｅｖｉｃｅＧｅｔ（）の基本フローチャートである。 本発明の実施例１に係る通信制御機能（情報ＩＤがプロトコル情報ＩＤで指定可能な場合）におけるＤｅｖｉｃｅＣｌｏｓｅ（）の基本フローチャートである。 本発明の実施例１に係る通信制御機能（情報ＩＤがプロトコル情報ＩＤで指定可能な場合）におけるプロトコル別通信処理の基本フローチャートである。 本発明の実施例１に係る通信制御機能（情報ＩＤが共通情報ＩＤとプロトコル情報ＩＤの両方を指定可能な場合）におけるＤｅｖｉｃｅＯｐｅｎ（）の基本フローチャートである。 本発明の実施例１に係る通信制御機能（情報ＩＤが共通情報ＩＤとプロトコル情報ＩＤの両方を指定可能な場合）におけるＤｅｖｉｃｅＧｅｔ（）の基本フローチャートである。 本発明の実施例１に係る通信制御機能（情報ＩＤが共通情報ＩＤとプロトコル情報ＩＤの両方を指定可能な場合）におけるＤｅｖｉｃｅＣｌｏｓｅ（）の基本フローチャートである。 本発明の実施例１に係る通信制御機能（情報ＩＤが共通情報ＩＤとプロトコル情報ＩＤの両方を指定可能な場合）におけるプロトコル別通信処理の基本フローチャートである。 本発明の実施例１に係る通信制御機能（情報ＩＤがプロトコル情報ＩＤで指定可能な場合）の処理手順の一例を示すシーケンス図である。 本発明の実施例１に係る通信制御機能（情報ＩＤが共通情報ＩＤとプロトコル情報ＩＤの両方を指定可能な場合）の処理手順の一例を示すシーケンス図である。 本発明の実施例２に係る通信制御機能の主要な機能構成例を示す図である。 本発明の実施例２に係るトナーに関する共通情報ＩＤ定義ファイルの一例を示す図である。 本発明の実施例２に係るデータタイプ変換用データファイルの一例を示す図である。 本発明の実施例２に係る通信制御機能におけるＤｅｖｉｃｅＧｅｔ（）の基本フローチャートである。 本発明の実施例２に係る通信制御機能におけるデータタイプ変換処理の基本フローチャートである。 本発明の実施例２に係る通信制御機能の処理手順の一例を示すシーケンス図である。 本発明の実施例３に係る通信制御機能の主要な機能構成例を示す図である。 本発明の実施例３に係る通信制御機能におけるデータタイプ変換処理の基本フローチャートである。 本発明の実施例３に係る通信制御機能におけるＳｅｔＣｈａｒＣｏｄｅ（）の基本フローチャートである。 本発明の実施例３に係る通信制御機能における文字コード変換処理の基本フローチャートである。 本発明の実施例３に係る通信制御機能の処理手順の一例を示すシーケンス図である。 本発明の実施例４に係るネットワーク層の構成例を示す図である。 本発明の実施例４に係る通信制御機能の主要な機能構成例を示す図である。 本発明の実施例４に係る文字コードに関する共通情報ＩＤ定義ファイルの一例を示す図である。 本発明の実施例４に係る統一文字コード変換用データファイルの一例を示す図である。 本発明の実施例４に係る通信制御機能におけるＤｅｖｉｃｅＧｅｔ（）の基本フローチャートである。 本発明の実施例４に係る通信制御機能における統一文字コード変換処理の基本フローチャートである。 本発明の実施例４に係る通信制御機能の処理手順の一例を示すシーケンス図である。 本発明の実施例５に係る通信制御機能の主要な機能構成例を示す図である。 本発明の実施例５に係る通信制御機能におけるＤｅｖｉｃｅＧｅｔ（）の基本フローチャートである。 本発明の実施例５に係る通信制御機能における文字コード解析処理の基本フローチャートである。 本発明の実施例５に係る通信制御機能の処理手順の一例を示すシーケンス図である。 本発明の実施例６に係る通信制御機能の主要な機能構成例を示す図である。 本発明の実施例６に係る通信制御機能の処理手順の一例を示すシーケンス図である。

符号の説明

１ システム制御部
２ システムメモリ
３ パラメータメモリ
４ 時計回路
５ スキャナ
６ プロッタ
７ 操作表示部
８ 画像処理部
９、２８ 磁気ディスク装置
１０、２６ ＬＡＮ Ｉ／Ｆ
１１、２７ ＬＡＮ伝送制御装置
１４、３６ バス
２１ ＣＰＵ
２２ ＲＯＭ
２３ ＲＡＭ
２４ キャラクタジェネレータ
２５ 時計回路
２９ ＣＤ−ＲＯＭ装置
３１ ＣＲＴ画面表示装置
３２ 表示制御部
３３ キーボード装置
３４ 画面指示装置
３５ 入力制御部
５１ 共通情報ＩＤ制御部
５２ 共通情報ＩＤ定義ファイル（共通情報ＩＤＸＭＬファイル）
５３ プロトコル制御部
５４ 各プロトコル管理部
５５ プロトコル情報ＩＤ定義ファイル（プロトコル情報ＩＤＸＭＬファイル）
５６ 各プロトコルモジュール管理部
５７ データタイプ管理部
５８ データタイプ変換用データファイル
５９ 文字コード変換部
６０ 文字コード管理部
６１ 統一文字コード変換用データファイル
６２ 文字コード解析部
６１ 統一文字コード変換用データファイル
ＡＰ アプリケーションプログラム
ＯＳ オペレーティングシステム
ＳＬ サービス層
ＮＬ ネットワーク層
ＬＳ ソケットライブラリ（通信ライブラリ）
ＡＰＩ 共通インタフェース（共通ＡＰＩ：通信制御インタフェース）層
ＭＳ サービス層
ＭＳ５ 共通ＩＤ管理サービス
ＭＳ６ ＸＭＬ管理サービス
ＭＳ７ 文字コードサービス
ＰＬ プロトコル層
ＷＳ１〜ＷＳｎ 情報処理装置
ＭＦＰ１〜ＭＦＰｎ 画像形成装置

Claims (9)

1. 同一通信機器と複数のプロトコルを用いて通信する通信制御装置であって、
   前記通信機器から取得可能な機器情報を識別する情報ＩＤ及び前記通信機器にアクセスする際の手順を示すアクセス手順が、プロトコルごとに対応付けて定義されているプロトコル情報ＩＤ定義ファイルと、
   同一機器情報を取得可能な各プロトコルを識別する複数のプロトコル識別子、各プロトコルに対応する複数の前記情報ＩＤ、及び複数の前記情報ＩＤを各プロトコルで共通化し１つのＩＤで示す共通情報ＩＤが、前記機器情報ごとに対応付けて定義されている共通情報ＩＤ定義ファイルと、
   同一機器情報を取得可能な各プロトコルを識別する複数のプロトコル識別子、各プロトコルに対応する複数の前記情報ＩＤ、前記情報ＩＤに基づき取得される機器情報値、及びプロトコルごとに異なる前記機器情報値を各プロトコルで共通化し１つの値で示す統一値が、前記機器情報ごとに対応付けて定義されているデータタイプ変換用データファイルと、
   処理の実行指示に従って、前記通信機器との通信処理を行う各プロトコルに対応する通信モジュールを制御する通信制御手段と、
   アプリケーションから前記機器情報の取得が要求されると、前記プロトコル情報ＩＤ定義ファイル及び／又は前記共通情報ＩＤ定義ファイルの定義情報に基づき、前記通信制御手段に対し、処理の実行を指示する情報制御手段と、
   前記通信機器から前記機器情報が取得されると、前記データタイプ変換用データファイルの定義情報に基づき、前記通信機器から取得された、プロトコルごとに異なる機器情報値を、統一された値に変換するデータタイプ変換手段と、を有し、
   前記情報制御手段は、
   前記共通情報ＩＤファイルを参照し、情報取得要求時に前記アプリケーションから受け取った共通情報ＩＤが存在するか否かを判定し、存在すると判定された場合に、前記共通情報ＩＤファイルから、前記共通情報ＩＤに対応付けて定義されている前記プロトコル識別子及び前記情報ＩＤを取得し、取得したプロトコル識別子に基づき特定された前記プロトコル情報ＩＤ定義ファイルを参照し、取得した情報ＩＤが存在するか否かを判定し、存在すると判定された場合に、前記プロトコル情報ＩＤ定義ファイルから、前記情報ＩＤに対応付けて定義されている前記アクセス手順を取得し、
   前記通信制御手段は、
   前記情報制御手段により取得されたアクセス手順に従って、前記通信機器との通信処理を行い、前記アプリケーションから要求された機器情報を取得し、前記データタイプ変換手段に対し、取得した機器情報を通知し、
   前記データタイプ変換手段は、
   前記共通情報ＩＤ定義ファイルを参照し、前記アプリケーションから受け取った共通情報ＩＤに基づき、前記共通情報ＩＤファイルから、前記共通情報ＩＤに対応付けて定義されている前記プロトコル識別子及び前記情報ＩＤを取得し、前記データタイプ変換用データファイルを参照し、取得したプロトコル識別子及び情報ＩＤに対応付けて定義されている前記機器情報値と一致する、前記通信制御手段により取得された機器情報の取得値を、該取得値と一致する前記機器情報値に対応付けて定義されている前記統一値に変換し、
   変換された機器情報が、前記アプリケーションに通知されることを特徴とする通信制御装置。
2. 前記情報制御手段は、
   前記プロトコル情報ＩＤ定義ファイルを参照し、情報取得要求時に前記アプリケーションから受け取った情報ＩＤが存在するか否かを判定し、存在すると判定された場合に、前記プロトコル情報ＩＤ定義ファイルから、前記情報ＩＤに対応付けて定義されている前記アクセス手順を取得し、前記通信制御手段に対し、取得したアクセス手順を通知することを特徴とする請求項１に記載の通信制御装置。
3. 前記情報制御手段は、
   情報取得要求時に前記アプリケーションから受け取ったプロトコルの優先度を示す設定に基づき、各プロトコルに対応する前記プロトコル情報ＩＤ定義ファイルのうち、優先度の高いプロトコルに対応する前記プロトコル情報ＩＤ定義ファイルから参照し、前記アプリケーションから受け取った情報ＩＤの存在判定を行うことを特徴とする請求項１又は２に記載の通信制御装置。
4. 文字コードを変換する文字コード変換手段を有し、
   前記文字コード変換手段は、
   前記通信制御手段により取得された機器情報の文字列値を、情報取得要求時に前記アプリケーションから指定された文字コードに変換することを特徴とする請求項１ないし３のいずれか一項に記載の通信制御装置。
5. 同一機器情報を取得可能な各プロトコルに対応する複数の文字コード及び該文字コードに対応する文字セットを識別する共通文字コードが対応付けて定義されている文字コード変換用データファイルを有し、
   前記文字コード変換手段は、
   前記通信制御手段により取得された機器情報に、文字コードを示す文字コード情報が含まれていた場合に、前記文字コード変換用データファイルを参照し、前記文字コード変換用データファイルに定義されている前記文字コードと一致する前記文字コード情報を、該文字コード情報と一致する前記文字コードに対応付けて定義されている前記共有文字コードに変換することを特徴とする請求項４に記載の通信制御装置。
6. 文字コードを解析する文字コード解析手段を有し、
   前記文字コード解析手段は、
   前記通信制御手段により取得された機器情報に、前記文字コード情報が含まれていなかった場合に、前記機器情報の文字コードを解析し、
   前記文字コード変換手段は、
   前記文字コード変換用データファイルを参照し、前記文字コード変換用データファイルに定義されている前記文字コードと一致する、前記文字コード解析手段による解析結果の文字コード情報を、該文字コード情報と一致する前記文字コードに対応付けて定義されている前記共有文字コードに変換することを特徴とする請求項５に記載の通信制御装置。
7. 同一通信機器と複数のプロトコルを用いて通信する通信制御装置における通信制御方法であって、
   処理の実行指示に従って、前記通信機器との通信処理を行う各プロトコルに対応する通信モジュールを制御する通信制御ステップと、
   アプリケーションから前記機器情報の取得が要求されると、前記通信機器から取得可能な機器情報を識別する情報ＩＤ及び前記通信機器にアクセスする際の手順を示すアクセス手順が、プロトコルごとに対応付けて定義されているプロトコル情報ＩＤ定義ファイル、及び／又は、同一機器情報を取得可能な各プロトコルを識別する複数のプロトコル識別子、各プロトコルに対応する複数の前記情報ＩＤ、及び複数の前記情報ＩＤを各プロトコルで共通化し１つのＩＤで示す共通情報ＩＤが、前記機器情報ごとに対応付けて定義されている共通情報ＩＤ定義ファイルの定義情報に基づき、前記通信制御ステップの処理の実行を指示する情報制御ステップと、
   前記通信機器から前記機器情報が取得されると、同一機器情報を取得可能な各プロトコルを識別する複数のプロトコル識別子、各プロトコルに対応する複数の前記情報ＩＤ、前記情報ＩＤに基づき取得される機器情報値、及びプロトコルごとに異なる前記機器情報値を各プロトコルで共通化し１つの値で示す統一値が、前記機器情報ごとに対応付けて定義されているデータタイプ変換用データファイルの定義情報に基づき、前記通信機器から取得された、プロトコルごとに異なる機器情報値を、統一された値に変換するデータタイプ変換ステップと、を有し、
   前記情報制御ステップは、
   前記共通情報ＩＤファイルを参照し、情報取得要求時に前記アプリケーションから受け取った共通情報ＩＤが存在するか否かを判定し、存在すると判定された場合に、前記共通情報ＩＤファイルから、前記共通情報ＩＤに対応付けて定義されている前記プロトコル識別子及び前記情報ＩＤを取得し、取得したプロトコル識別子に基づき特定された前記プロトコル情報ＩＤ定義ファイルを参照し、取得した情報ＩＤが存在するか否かを判定し、存在すると判定された場合に、前記プロトコル情報ＩＤ定義ファイルから、前記情報ＩＤに対応付けて定義されている前記アクセス手順を取得し、
   前記通信制御ステップは、
   前記情報制御ステップにより取得されたアクセス手順に従って、前記通信機器との通信処理を行い、前記アプリケーションから要求された機器情報を取得し、
   前記データタイプ変換ステップは、
   前記共通情報ＩＤ定義ファイルを参照し、前記アプリケーションから受け取った共通情報ＩＤに基づき、前記共通情報ＩＤファイルから、前記共通情報ＩＤに対応付けて定義されている前記プロトコル識別子及び前記情報ＩＤを取得し、前記データタイプ変換用データファイルを参照し、取得したプロトコル識別子及び情報ＩＤに対応付けて定義されている前記機器情報値と一致する、前記通信制御ステップにより取得された機器情報の取得値を、該取得値と一致する前記機器情報値に対応付けて定義されている前記統一値に変換し、
   変換された機器情報が、前記アプリケーションに通知されることを特徴とする通信制御方法。
8. 請求項７に記載の通信制御方法をコンピュータが制御可能にプログラミングしたことを特徴とする通信制御プログラム。
9. 請求項８に記載の通信制御プログラムをコンピュータが読み取り可能な形式で格納したことを特徴とする記憶媒体。

Images