(57)【要約】【課題】  共通デバイスドライバなどで都度判断が必要な構成情報の取得において、SNMPを用いてテーブル構造のMIB情報を取得する場合、テーブルの個数が不明の場合には、一旦すべての情報を取得した後でなければ処理が出来ないといった問題がある。RFCやPWGの標準仕様においてテーブル構造で情報を保持しているMIB属性群に対して、テーブル内の最大のIndex数をテーブルの外部の記号拡張MIBの属性情報として単独で取得できるようにすること。【解決手段】  画像形成装置の構成情報のうち、デーブル構造内の情報数の上限値をテーブル外の別な情報として取得可能とすることで、共通デバイスドライバはデーブル内の所望の属性の組み合わせで情報を取得することが可能となる。【選択図】図５
2020102784.tif 000002
【特許請求の範囲】
【請求項１】
ネットワーク・インタフェイスを有する画像形成装置（１０４）において
類似の構成をテーブル情報として管理する構成情報管理手段、
デーブル内に含まれている構成要素をカウントするカウント手段（Ｓ３０３）、
カウント手段によって計数された情報を、前記の構成情報管理手段のテーブル外に設けられた別な情報（Ｓ３０４）として取得可能とすることを特徴とした画像形成装置と
画像形成装置から構成情報取得を行うホストＰＣ（１０１）において、
前記画像形成装置の構成情報管理手段のテーブル外に設けられた別な情報（Ｓ３０４）を取得する取得手段（Ｓ４０２）、前記取得手段によって得られた情報に基づいて、前記デーブル内の組み合わせた情報をまとめて取得可能とすることを特徴とするホストＰＣ（１０１）から構成される情報取得のための処理システム。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、標準のプロトコル技術とデータ構造を用いて、ホストＰＣ上のプリンタドライバから、画像形成装置の機器構成情報の取得に処理に関する。
【背景技術】
【０００２】
従来、ホストＰＣ上で動作する汎用ＯＳ上のプリンタドライバが画像形成装置から構成情報の取得を行う際には、画像形成装置メーカーが提供する専用のプリンタドライバで独自プロトコルと独自データ構造で通信を行っていた。
【０００３】
しかしながらネットワークに求められるセキュリティの高まりから、標準プロトコルと標準データ構造を用いた通信に置き換えることが求められている。
【０００４】
特許文献１では、標準プロトコルとしてＳＮＭＰ（Simple Network Management Protocol）が、標準のデータ構造としてＭＩＢ（Management Information Base）を用いて画像形成装置から構成情報の取得を行うことが開示されている。
【先行技術文献】
【特許文献】
【０００５】
【特許文献１】特開２００５−２５８７２１号公報
【発明の概要】
【発明が解決しようとする課題】
【０００６】
Microsoft社（以下、ＭＳ社）のWindows（登録商標）のＸＰ以降のバージョンから、Bidiインタフェース（Bi-directional interfaceの略称）をサポートしている。Bidiインタフェースは、Windowsスプーラにおけるインタフェースで、ポートモニタから取得される情報を上位のモジュールであるＯＳ（オペレーションシステム）や共通デバイスドライバに対して情報を双方向に受け渡すためのインタフェースである。BidiインタフェースはプロトコルとしてWSD（Web Services for Devices）とSNMPがサポートされており、Bidiを使わずにメーカー独自のプロトコルと独自のデータ構造による画像形成装置からの構成情報取得は推奨されなくなっている。
【０００７】
しかしながらBidiインタフェースの制約から、SNMPのプロトコル仕様とMIBのデータ構造の制約から以下のような問題がある。SNMPの仕様ではテーブル構造内のデータは、テーブルの個数が不明な場合テーブル内に配置されているOID（Object IDentifier）をIndexの数の分だけSNMPのGetNextオペレーションにより取得してから次のOIDに移る。
【０００８】
例：
Printer-MIB::prtInputMaxCapacity.1.1 = INTEGER: 250
Printer-MIB::prtInputMaxCapacity.1.2 = INTEGER: 1100
Printer-MIB::prtInputMaxCapacity.1.3 = INTEGER: 1100
Printer-MIB::prtInputMaxCapacity.1.4 = INTEGER: 550
Printer-MIB::prtInputMaxCapacity.1.5 = INTEGER: 550
Printer-MIB::prtInputCurrentLevel.1.1 = INTEGER: 0
Printer-MIB::prtInputCurrentLevel.1.2 = INTEGER: 550
Printer-MIB::prtInputCurrentLevel.1.3 = INTEGER: 550
Printer-MIB::prtInputCurrentLevel.1.4 = INTEGER: 55
Printer-MIB::prtInputCurrentLevel.1.5 = INTEGER: 275
prtInputMaxCapacity：給紙機構の最大積載能力
prtInputCurrentLevel：現在の給紙機構の残量
給紙機構が５段存在する場合にはprtInputMaxCapacityを５回取得してからprtInputCurrentLevelの５回取得を行う。
【０００９】
一方、共通デバイスドライバとしては給紙機構ごとに情報取得を行って都度判断をする必要がある。WSDとそのデータ構造が記載されたXML形式での構成情報取得においては、仕様として給紙機構ごとに情報取得が可能であるが通常のSNMPの情報取得方法では前述のとおり、給紙機構の全情報の取得完了でなければ処理が出来ないという課題がある。
【００１０】
さらに共通デバイスドライバはBidiインタフェースの先でどのようなプロトコルで画像形成装置から情報取得を行っているかの判別が困難である。また画像形成装置から取得した能力情報の解析部は共通デバイスドライバ内の同一のモジュールで処理するため、取得したデータ構造に極端に差異があるとデータのハンドリングが複雑になってしまうという問題もある。
【００１１】
本発明は、上述の少なくとも１つの課題を鑑みなされたものである。本発明は、画像形成装置の構成情報のうち、デーブル構造内の情報数の上限値をテーブル外の別な情報として取得可能とする。このことにより、共通デバイスドライバはデーブル内の所望の属性の組み合わせで情報を取得することが可能となる。
【課題を解決するための手段】
【００１２】
上記の課題を解決するために、本発明は、
ネットワーク・インタフェイスを有する画像形成装置（１０４）において
類似の構成をテーブル情報として管理する構成情報管理手段、
デーブル内に含まれている構成要素をカウントするカウント手段（Ｓ３０３）、
カウント手段によって計数された情報を、前記の構成情報管理手段のテーブル外に設けられた別な情報（Ｓ３０４）として取得可能とすることを特徴とした画像形成装置と
画像形成装置から構成情報取得を行うホストＰＣ（１０１）において、
前記画像形成装置の構成情報管理手段のテーブル外に設けられた別な情報（Ｓ３０４）を取得する取得手段（Ｓ４０２）、前記取得手段によって得られた情報に基づいて、前記デーブル内の組み合わせた情報をまとめて取得可能とすることを特徴とするホストＰＣ（１０１）から構成される情報取得のための処理システムである。
【発明の効果】
【００１３】
本発明に係る処理システムによれば、テーブル構造内の情報数の上限値をテーブル外の別な情報として取得可能とすることで、共通デバイスドライバはBidiインタフェースの制限を緩和した情報取得が可能となる。
【図面の簡単な説明】
【００１４】
【図１】システムの構成を示す簡略図
【図２】ハードウェア構成を示す図
【図３】画像形成装置の初期化処理フローを示す図
【図４】クライアントＰＣの情報取得の処理フローを示す図
【図５】画像形成装置とクライアントＰＣ間の通信例を示す図
【図６】prtInputTableの構成要素を示す図
【発明を実施するための形態】
【００１５】
以下、本発明を実施するための形態について図面を用いて説明する。以下の実施の形態は特許請求の範囲に係る発明を限定するものでなく、また実施の形態で説明されている特徴の組み合わせの全てが発明の解決手段に必須のものとは限らない。
【００１６】
まず図１を用いて、本発明に係る通信システムの一実施例の構成を説明する。
【００１７】
本実施形態に係る通信システムは、クライアントＰＣ１０１、１０２、１０３および画像形成装置１０４で構成される。画像形成装置１０４は操作部２００を持ち、操作部に画像形成装置１０４のＩＰアドレスなどのネットワーク接続情報や印刷ジョブの履歴などを表示することができる。
【００１８】
画像形成装置１０４とクライアントＰＣ１０１、１０２、１０３はＬＡＮ(Local Area Network)１０５を介して接続されており、クライアントＰＣ１０１、１０２、１０３はＬＡＮ１０５を介して画像形成装置１００と通信を行う。
【００１９】
図２は画像形成装置１０４の実施形態におけるハードウェア構成図である。
【００２０】
画像形成装置１０４はプリンタ２０５、ＦＡＸ２０７、スキャナ２０６、操作部２００、並びにこれらを制御するＣＰＵ２０４を備える。コピー動作に関しては、画像形成装置１００のＣＰＵがプリンタ２０５およびスキャナ２０６を連動して制御することにより実現している。
【００２１】
また、ＬＡＮ通信手段としてＬＡＮ  Ｉ／Ｆ２０８を備える。プリンタ２０５は、受信機能を実現するユニットであって、例えば同一ネットワークのＬＡＮに接続されたクライアントＰＣより受信されたプリントジョブに応じた画像を形成し、用紙に出力する処理を行う。ＦＡＸ２０７及びスキャナ２０６は送信機能を実現するユニットであって、スキャナ部にセットされた原稿画像を光学的に読み取り画像データとして用紙に出力する処理を行う。
【００２２】
有線ＬＡＮ  Ｉ／Ｆ２０８はイーサネット（登録商標）などにより構成されるＬＡＮに接続するためのネットワーク接続手段であって、同一のネットワークに接続されているクライアントＰＣと連携するために必要なインタフェースである。
【００２３】
ＣＰＵ２０４は、画像形成装置１００を構成する各種ハードウェア２００、２０５〜２０９の制御を動的に行うことで、画像形成装置１００が備える各機能を実現することが可能となる。ＣＰＵ２０４はバスラインにより各種ハードウェアに信号を送り、他のハードウェアと相互にデータ通信を行うことが可能となる。操作部２００は画像形成装置１００を利用するユーザがプリンタ２０５、ＦＡＸ２０７、スキャナ２０６を利用するためのユーザインターフェースである。
【００２４】
また、操作部２００はタッチパネルとして操作が可能となっている。なお、本実施形態では、画像形成装置の一例としてコピー機能やスキャン機能を有するＭＦＰ(Multi Function Peripheral)を例示したがこれに限定されるものではない。
【００２５】
例えば、プリンタやスキャナなど単機能のＳＦＰ(Single Function Peripheral)などに適用することもできる。また、３次元形状データに基づき立体物を形成する３Ｄプリンタなどに適用することもできる。また、遠隔会議システムのターミナル（クライアント）や、電子黒板などのデバイスに適用することもできる。
【００２６】
次に図３のフローチャートを用いて、本実施例における画像形成装置の処理フローについて説明する。
【００２７】
Ｓ３０１にて画像形成装置１０４処理が開始され、Ｓ３０１にて画像形成装置１０４のＣＰＵ２０４は給紙トレイ情報の初期化を開始する。Ｓ３０３においてプリンタ部２０５にて構成される給紙トレイ数のカウントを画像形成装置１０４のＣＰＵ２０４が行い、Ｓ３０４で給紙トレイ数を示すＯＩＤに値を反映させる。
【００２８】
ここで、給紙トレイ数を示すＯＩＤはＲＦＣやＰＷＧには定義が無いため以下のような企業独自の拡張ＭＩＢに定義追加を行う。
【００２９】
--------------------------------  記号拡張定義の例  ここから  ---------
-- canPrtInput sub-tree
-- プリンタ入力部の情報。
--   本来、これらの情報はRFC3805/Printer-MIBの入力グループに
--   追加したいものであるが、それは許されていない。
--   そのため、独自のプリンタ入力部として定義する。
--   このテーブルのインデックスはPrinter-MIBのインプットテーブルの
--   インデックスと対応する。
--   このテーブルのインデックス1の情報はPrinter-MIBのインプット
--   テーブルのインデックス1の装置に関する情報である。
【００３０】
canPrtInput OBJECT IDENTIFIER ::= { canXXXXX 100 }
canPrtInputTableCount OBJECT-TYPE
SYNTAX      Integer32
MAX-ACCESS  read-only
STATUS      current
DESCRIPTION
"prtInputTable内の給紙機構の数を表す。”         
::= { canPrtInput 1 }
--------------------------------  記号拡張定義の例  ここまで  ---------
次にＳ３０５において画像形成装置１０４のＣＰＵ２０４はRFC3805/PrinterMIBv2の給紙トレイ毎の詳細情報を格納するprtInputTable内の各属性に初期化後の情報を格納する。
【００３１】
ここでprtInputTable内の各属性情報はRFCで定義が定められており、そのツリー構成を図６に示す。属性の一例としては
６０１のprtInputMaxCapacity：入力サブユニット容量単位（CapacityUnit）による入力サブユニットの最大容量。
６０２のprtInputCurrentLeve：入力サブユニット容量単位（CapacityUnit）による入力サブユニットの現在容量。
等がRFC3805/PrinterMIBv2で規定されている。
【００３２】
その後、Ｓ３０６に遷移して処理終了となる。
【００３３】
図４のフローチャートを用いて、本実施例におけるホストＰＣの処理フローについて説明する。
【００３４】
Ｓ４０１にてホストＰＣ１０１の画像形成装置１０４に対する給紙トレイ情報に関わる情報取得処理が開始される。Ｓ４０２においてホストＰＣ１０１のＣＰＵ（不図示）は、画像形成装置１０４から前述の給紙トレイの数を示すcanPrtInputTableCountの取得を行う。
【００３５】
次にホストＰＣ１０１のＣＰＵは給紙トレイの最初の給紙段を指定するためにIndex情報を１で初期化する。Ｓ４０４においてホストＰＣ１０１のＣＰＵは画像形成装置１０４の給紙トレイ情報が格納されているテーブルの中から必要とする個々のOIDに対して情報取得を行う。
【００３６】
例として、ホストＰＣ１０１から画像形成装置１０４への情報取得のリクエスト：
【００３７】
【数１】
2020102784.tif 000003
【００３８】
画像形成装置104からホストPC101への情報取得の返信：
【００３９】
【数２】
2020102784.tif 000004
【００４０】
次に、Ｓ４０５において情報取得に使用したIndexの値と、Ｓ４０２で画像形成装置１０４から取得した給紙トレイ数が一致しているか否かをホストＰＣ１０１のＣＰＵが判断を行い、一致している場合はＳ４０７に処理遷移させ、異なっている場合にはＳ４０６に処理遷移する。
【００４１】
Ｓ４０７において給紙トレイ情報の取得完了となりホストＰＣ１０１のＣＰＵはＳ４０８で一連の処理を終了させる。Ｓ４０６に処理遷移した場合、ホストＰＣ１０１のＣＰＵは次に取得する給紙トレイのIndex情報をインクリメントし、再度Ｓ４０４に処理遷移させ次の給紙段情報を画像形成装置１０４から取得を行う。
【００４２】
次に図５を用いて、本実施例における画像形成装置１０４とホストＰＣ１０１と通信シーケンス例について説明する。
【００４３】
Ｓ５０１においては前述の図３の処理が完了しており、Ｓ５０２で図４のホストＰＣ１０１の処理が開始されるＳ５０３でホストＰＣ１０１が画像形成装置１０４に対して給紙トレイ数の問い合わせを行ない、返信値として２、つまり給紙トレイが２つ存在していることを得る。
【００４４】
Ｓ５０４においては図４の説明で用いたように、まず１つ目の給紙トレイ情報の取得を行い、その返信値を得る。その後Ｓ５０５では２つ目の給紙トレイ情報の取得を行い、その返信値を得る。給紙トレイ数は２である事からＳ５０６でシーケンス終了となる。
【００４５】
以上述べてきたように、本実施形態をとることにより、RFC（Request for Comments）やPWG（Printer Working Group）のテーブル構造で情報を保持しているMIB属性群に対して、テーブル内の最大のIndex数をテーブルの外部のMIB属性情報として単独で取得できるようにする。
【００４６】
共通デバイスドライバは画像形成装置のデーブル構造から情報取得を行う前に、前述の最大のIndex数の取得を行い、SNMPのGetオペレーションにて情報取得を行う。これにより、標準プロトコル技術を用いたプリンタドライバからの画像形成装置の情報取得において、通信量を最適化し効率よく情報収集が可能となる。
【符号の説明】
【００４７】
１０１  ホスＰＣ、１０４  画像形成装置、２００  操作部、２０４  ＣＰＵ
【図１】
2020102784.tif 000005
【図２】
2020102784.tif 000006
【図３】
2020102784.tif 000007
【図４】
2020102784.tif 000008
【図５】
2020102784.tif 000009
【図６】
2020102784.tif 000010