JP2013168017A

JP2013168017A - 情報処理装置、方法およびプログラム

Info

Publication number: JP2013168017A
Application number: JP2012030815A
Authority: JP
Inventors: Hiroaki Morimoto; 弘明守本
Original assignee: Canon Inc
Current assignee: Canon Inc
Priority date: 2012-02-15
Filing date: 2012-02-15
Publication date: 2013-08-29
Anticipated expiration: 2032-02-15
Also published as: US20160170691A1; JP5950608B2; US20130208298A1; US10185520B2

Abstract

【課題】新たなＯＳにおいては、幾つかの制約事項が想定され、該ＯＳ上で動作するアプリケーションやプリンタドライバでは、従来手法による印刷装置のメンテナンス処理が適切に実行できない場合がある。
【解決手段】印刷装置とＵＳＢ（ＵｎｉｖｅｒｓａｌＳｅｒｉａｌＢｕｓ）を介して接続されている情報処理装置であって、拡張ファイルに従い機能するポートモニタにより、アプリケーションで指定され、スプーラーを介して取得されたコマンド識別子に対応するメンテナンスコマンドをデータベースから取得し、前記取得されたメンテナンスコマンドを前記印刷装置に送信することを特徴とする。
【選択図】図８

Description

本発明は次世代のプリンタドライバアーキテクチャーによるメンテナンス動作を実行するための技術に関する

従来、特許文献１に記載されるように、レガシーアーキテクチャーによるプリンタドライバ（以後、レガシードライバ）は、ノズルクリーニング等のメンテナンス動作の実行を指示するメンテナンスコマンドを、印刷ジョブとしてプリンタに送信することが可能であった。
レガシードライバにおいては、ユーザーインターフェース（以後、ＵＩ）上にメンテナンスコマンド送信ボタンを設け、ユーザーはそのボタンを押下することで印刷ジョブとしてメンテナンスコマンドを送信していた。若しくは、外部アプリケーションを利用した場合、ユーザーが外部アプリケーションのグラフィカルユーザインターフェース（以後、ＧＵＩ）上で任意のプリンタを選択後、メンテナンスコマンド送信を指示するボタンを押下することで印刷ジョブとしてメンテナンスコマンドを送信していた。

特開２００６−１２０３７号公報

近年、デスクトップＰＣのみならずモバイルＰＣにも対応する新たなオペレーティングシステム（以後、ＯＳ）が発表されている。アプリケーションやプリンタドライバなどは、それら新たなＯＳに搭載される次世代アーキテクチャーへの対応が要求される。当然ながら、新たなＯＳにおいては、幾つかの制約事項が想定され、該ＯＳ上で動作するアプリケーションやプリンタドライバでは、上記した従来のメンテナンス方法が適切に実行できない場合がある。
本件は、そのような制約が課せられている場合においても、適切にプリンタに対して、メンテナンス動作の実行指示を実現可能な仕組みを提供することを目的とする。

上記課題を解決するための本発明は、印刷装置とＵＳＢ（ＵｎｉｖｅｒｓａｌＳｅｒｉａｌＢｕｓ）を介して接続されている情報処理装置であって、コマンド識別子とメンテナンスコマンドとを対応づけて管理するデータベースと、拡張ファイルに従い機能するポートモニタにより、アプリケーションで指定され、スプーラーを介して取得されたコマンド識別子に対応するメンテナンスコマンドを前記データベースから取得する取得手段と、前記拡張ファイルに従い機能するポートモニタにより、前記取得されたメンテナンスコマンドを前記印刷装置に送信する送信手段と、を有することを特徴とする。

本発明によれば、次世代アーキテクチャーであっても、適切にプリンタに対して、メンテナンス動作の実行指示を行い、メンテナンス処理を実行することができる。

印刷装置と情報処理装置とが接続されて構成される印刷システムを示すブロック図レガシーアーキテクチャーによるプリンタドライバに関連するモジュール構成を示すブロック図レガシーアーキテクチャーによるプリンタドライバにおけるメンテナンス処理の流れを説明するための図次世代アーキテクチャーによるプリンタドライバに関連するモジュール構成を示すブロック図次世代アーキテクチャーによるプリンタドライバにおけるメンテナンス処理の流れ説明するための図次世代アーキテクチャーによるユーティリティーアプリケーションのＵＩ画面の例を示した図実施形態１におけるアプリケーションの処理を説明するためのフローチャート実施形態１におけるポートモニタ用拡張ファイルに基づく処理を説明するためのフローチャート実施形態１における次世代ドライバで利用されるデータベースに格納されているメンテナンスコマンドデータを示す図実施形態２におけるアプリケーションの処理を説明するためのフローチャート実施形態２におけるポートモニタ用拡張ファイルに基づく処理を説明するためのフローチャート実施形態２における次世代ドライバで利用されるデータベースに格納されているメンテナンスコマンドデータを示す図実施形態３におけるアプリケーションの処理を説明するためのフローチャート実施形態３におけるポートモニタ用拡張ファイルに基づく処理を説明するためのフローチャート実施形態４におけるポートモニタ用拡張ファイルに基づく処理を説明するためのフローチャート実施形態４における印刷装置の処理を説明するためのフローチャート

以下、添付図面を参照して本発明の好適な実施の形態を詳しく説明する。尚、以下の実施の形態は特許請求の範囲に係る本発明を限定するものでなく、また本実施の形態で説明されている特徴の組み合わせの全てが本発明の解決手段に必須のものとは限らない。

図１は、情報処理装置１１０と情報処理装置１１０に接続された印刷装置１２０により構成される印刷システムの全体構成を示すブロック図の一例である。情報処理装置１１０は入力Ｉ／Ｆ１１１、ＣＰＵ１１２、ＲＯＭ１１３、出力Ｉ／Ｆ１１４、外部記憶装置１１５、ＲＡＭ１１６、入力装置１１７、出力装置１１８、入出力Ｉ／Ｆ１１９を有する。ＲＯＭ１１３は初期化プログラムを保存し、外部記憶装置１１５はＯＳ、プリンタドライバ、アプリケーションといったプログラムやその他各種のデータが保存されている。ＲＡＭ１１６は外部記憶装置１１５に保存される各種プログラムがワークメモリーとして使用する。入力装置１１７は、マウスやキーボードのほかに、タッチパネルなどで構成され、データ入力や動作指示に使用され入力Ｉ／Ｆ１１１に接続されている。出力装置１１８はデータ表示や状態の通知に使用され出力Ｉ／Ｆ１１４に接続されている。

印刷装置１２０はＲＡＭ１２１、ＲＯＭ１２２、プリントエンジン１２３、ＣＰＵ１２４、入出力Ｉ／Ｆ１２５から構成される。情報処理装置１１０と印刷装置１２０はＵＳＢ（ＵｎｉｖｅｒｓａｌＳｅｒｉａｌＢｕｓ）（ＴＭ）ケーブル１３０により接続されている。ＲＡＭ１２１はＣＰＵ１２４のワークメモリーとして使用され、受信したデータの一時保存用バッファとしても利用される。ＲＯＭ１２２は制御命令を保存している。プリントエンジン１２３はＲＡＭ１２１に保存されたデータに基づき印刷を行う。ＣＰＵ１２４はＲＯＭ１２２に保存されている制御命令に従い印刷装置１２０を制御する。

本実施形態においては情報処理装置１１０および印刷装置１２０の処理分担を前記のように示したが、処理の分担形態はこれに依らない。

ここでは図２、３を用いて従来の印刷システムであるレガシーアーキテクチャーによるプリンタドライバ（以後、レガシードライバ）を用いた印刷データの流れとそのアーキテクチャー上で実現されるメンテナンス実行処理の流れを説明する。

図２は、情報処理装置１１０に適用可能な従来の印刷システムであるレガシードライバに関連するモジュール構成を概念的に表した図である。
アプリケーション２０１が作成した印刷データは、ＯＳの印刷サポート機能２０２を介しＵＩモジュール２１１から返却される印刷設定情報が付加され、スプールデータ２０５としてスプーラー２０３のプリントキュー２０４に一時的に保存される。スプールデータ２０５は、レガシードライバ２１０によって印刷装置２０７（構成要素は印刷装置１２０と同様）が解釈可能な印刷コマンドへ変換された後、ＵＳＢポートモニタ２０６へ出力される。ここでレガシードライバ２１０は、前述のＵＩモジュール２１１に加え後述するグラフィックスドライバ２１３、ランゲージモニタ２１４の各モジュールから構成される。ＵＳＢポートモニタ２０６は入力された印刷コマンドを印刷装置２０７へ送信する。ここでＵＩモジュール２１１は、印刷装置２０７に対しメンテナンス動作を指示するメンテナンス処理指示部２１２を有することができる。ユーザーはＵＩモジュール２１１が提供するＵＩ画面からメンテナンス動作を選択することで印刷装置２０７へメンテナンス動作の指示を行う。

図３では、レガシードライバにおけるメンテナンス処理の流れを説明するための図を示す。
ＵＩモジュール２１１に含まれるメンテナンス処理指示部３０１（図２中では２１２）は、ユーザーからの指示に応じて印刷装置３０８が解釈可能なメンテナンスコマンドを作成しスプーラー３０２へ送信する。スプーラー３０２は受信したメンテナンスコマンドをスプールデータ３０４としてプリントキュー３０３へ一時的に保存する。スプールデータ３０４はグラフィックスドライバ３０５、ランゲージモニタ３０６を経由しＵＳＢポートモニタ３０７へ出力される。ここで前記メンテナンスコマンドは、グラフィックスドライバ３０５への入力時に、既に印刷装置３０８が解釈可能な形式である。そのため、入力されたメンテナンスコマンドに対して、グラフィックスドライバ３０５は、前述の変換処理を実施する必要はない。

メンテナンス処理指示部３０１は、メンテナンスコマンド発行処理によりスプーラー３０２へ渡るジョブに前記変換処理の実施の不要を示す情報を設定する。グラフィックスドライバ３０５はその実施不要を示す情報に従って、変換動作を実施しないよう制御する。その後、ＵＳＢポートモニタ３０７は、入力されたメンテナンスコマンドを印刷装置３０８へ送信することでメンテナンス動作が実行される。

＜実施形態１＞
図４〜９を参照し本発明の実施形態１について説明する。本実施形態では後述する次世代アーキテクチャーによるプリンタドライバ（以後、次世代ドライバ）で利用されるデータベースが１機種分のメンテナンスコマンド群を格納している場合を例として説明する。

図４ではレガシードライバと構成の異なる印刷システムであり情報処理装置１１０に適用可能な次世代ドライバに関連する構成を概念的に表した図である。本図では、アプリケーション、プリンタドライバ、ＯＳといったプログラムがＣＰＵにより実行された際に提供される各機能の主体として動作するモジュール構成の例を具体的に説明している。

アプリケーション４０１が作成した印刷データはＯＳの印刷サポート機能４０２を介し、スプールデータ４０５としてスプーラー４０３のプリントキュー４０４へ一時的に保存される。スプールデータ４０５はグラフィックスドライバ４１１により印刷装置１２０が解釈可能な印刷コマンドへ変換される。

次世代ドライバで利用されるデータベース４１２は、グラフィックスドライバ４１１や後述するポートモニタなどが参照可能なデータベースであり、印刷装置の機種に依存する各種情報やメンテナンスコマンドを格納することができる。

グラフィックスドライバ４１１は、印刷コマンドを生成する際に必要となる機種依存情報を、次世代ドライバで利用されるデータベース４１２から取得する。ここでファイル群４１０が次世代ドライバを構成するファイル群である。

一般的なアプリケーションからの印刷要求を受けて、グラフィックスドライバ４１１は印刷対象となる印刷装置に特化した画像処理パラメーターをデータベース４１２から取得して、印刷コマンドを生成する。その後、生成された印刷コマンドはＵＳＢポートモニタ４０６を経由し、印刷装置４０７へ到達する。これにより、次世代ドライバを含む印刷システムにおける印刷処理が実現される。

ここで、印刷装置のベンダは、前述のグラフィックスドライバ４１１及びポートモニタ用拡張ファイル４１３、さらに後述する図９、１２などで後述するような管理情報などを一緒にインストールするための次世代ドライバのインストーラプログラムを提供する。これにより、後述のＵＳＢポートモニタによる処理や次世代ドライバによる印刷制御を次世代アーキテクチャー上で実現できる。

なお、ポートモニタ用拡張ファイル４１３はＵＳＢポートモニタ４０６用に用意されるものとして本実施形態においては記載されている。しかしながら、他の接続形態により印刷装置と通信するためのポートモニタのために、同様の機能を拡張する拡張ファイルを用意して、後述されるような本発明に特徴的な処理を実現することも可能である。

本発明で想定する新たなＯＳ（例えばＷｉｎｄｏｗｓ（ＴＭ）８）の次世代ドライバの構成要素には、レガシードライバの構成要素に含まれるＵＩモジュール２１１がない。つまり、次世代ドライバは印刷設定などの各種設定を行うＧＵＩを持つことができない。しかしながら、後述する次世代ドライバに対応する外部アプリケーション（以後、次世代アプリ）により、各種設定を行うＧＵＩを提供することが可能である。次世代アプリと次世代ドライバは、該ドライバを識別する情報により紐づけを行う。

図５は、図４にて示した印刷システムにおいて実現されるメンテナンス処理の流れを説明するための図を示す。
次世代アプリ５０１はユーザーからの指示に応じて、印刷装置に対しての所望のメンテナンス動作を示すコマンドＩＤ（識別子）をスプーラー５０２へ送信する。スプーラー５０２は受信したコマンドＩＤを、プリントキュー５０３に蓄えることなく直接ＵＳＢポートモニタ５０４（以降、ポートモニタ５０４）へ渡す。その後、ポートモニタ５０４は、コマンドＩＤをポートモニタ用拡張ファイル５０５へ渡す。

ここで、ポートモニタ用拡張ファイル５０５は、ＪａｖａＳｃｒｉｐｔ（ＴＭ）により記述されるＯＳ機能を拡張するためのスクリプトファイルである。

ポートモニタ用拡張ファイル５０５は、受信したコマンドＩＤに対応するメンテナンスコマンドを、次世代ドライバで利用されるデータベース５０６を参照し取得する。その後、ポートモニタ用拡張ファイル５０５は、ポートモニタ５０４に対して、取得したメンテナンスコマンドの印刷装置５０７への送信を指示する。

レガシーアーキテクチャーにおいては、図３で示したように、スプーラーはメンテナンスコマンドを印刷ジョブとして扱う。一方、次世代アーキテクチャーにおいては、スプーラー４０３が印刷ジョブとしてメンテナンスコマンドを扱うことは制限されており、レガシーアーキテクチャーと同様な構成を採用することはできない。そのため代替手法として図５で示す処理を採用する必要がある。

図６は、印刷装置１２０に対してメンテナンス処理を指示するための次世代アプリ５０１のＵＩ画面構成の例を示す。このアプリケーションは、たとえば、印刷装置１２０のステータス表示や、印刷関連の設定を行うためのアプリケーションのリンク（ショートカット）などをまとめて提供するためのもので、ＯＳの同梱されるアプリケーションして提供されてもよい。

図６（ａ）では、次世代アプリ５０１の起動直後に表示されるメイン画面６１０を示す。メイン画面６１０にはステータス表示画面へのリンクボタン６１１、ユーティリティー機能表示画面へのリンクボタン６１２、マニュアル表示画面へのリンクボタン６１３を有する。ユーザーは、各画面へのリンクボタンを選択することで次世代アプリ５０１はユーザーに選択された画面を表示する。

図６（ｂ）は、図６（ａ）においてリンクボタン６１２を選択後に表示される、ユーティリティー機能選択画面６２０の画面構成を示す。画面６２０にはノズルクリーニングボタン６２１、ローラークリーニング６２２、インク拭き取りボタン６２３などといったメンテナンス処理のための指示ボタンが配置されている。ユーザーは実行したいメンテナンスに係るボタンを選択することで印刷装置５０７に対しメンテナンス処理の実行指示を行う。

図７は、次世代アプリ５０１のコマンドＩＤの送信処理を説明するためのフローチャートである。
本処理が開始されると、Ｓ７０１では、前述のユーティリティー機能を選択する画面６２０を介したユーザーからの入力を受け付ける。Ｓ７０２において、次世代アプリ５０１は、入力情報に基づき特定された、ユーザーに指定されたメンテナンスコマンドに対応するコマンドＩＤを取得する。Ｓ７０３では取得したコマンドＩＤをスプーラー５０２へ渡し、本処理を終了する。

次に、図８は、ポートモニタ用拡張ファイル５０５に基づき動作するポートモニタ５０４のメンテナンスコマンドの送信処理を説明するためのフローチャートを示す。ここで、ＯＳなどで提供されるモジュールであるポートモニタ５０４は、次世代ドライバとともに印刷装置のベンダにより提供されるポートモニタ用拡張ファイル５０５を用いることで、本図で説明するような特別な処理を実行する。

Ｓ８０１において、ポートモニタ５０４は、スプーラー５０２を経て、コマンドＩＤを取得する。Ｓ８０２において、ポートモニタ５０４は、ポートモニタ用拡張ファイル５０５に従い、次世代ドライバで利用されるデータベース５０６を参照し、該取得したコマンドＩＤに対応するメンテナンスコマンドを取得する。Ｓ８０４において、ポートモニタ５０４は、ポートモニタ用拡張ファイル５０５に従い、該取得したメンテナンスコマンドの印刷装置５０７への送信を制御し、その後、本処理を終了する。

図９は、次世代ドライバで利用されるデータベース５０６に格納されているメンテナンスコマンドデータを概念的に示す。メンテナンスコマンドデータ９０１はそれぞれ１つのコマンドＩＤ９０２と対応付けがなされ、データベース５０６に格納されている。ポートモニタ用拡張ファイル５０５では、データベース５０６を参照することで、コマンドＩＤを基に送信すべきメンテナンスコマンドを特定する処理について記述されている。

ここで、メンテナンスコマンドデータ９０１とコマンドＩＤ９０２とを対応付ける情報は印刷装置のベンダにより提供される。また、コマンドＩＤとしては整数値の他にも文字列を使用することも可能である。

以上の処理により、メンテナンスコマンドを印刷ジョブとして送信できないような制限が課せられたＯＳ環境下であっても、適切に印刷装置に対しメンテナンス動作の実行指示を行うことが可能となる。

さらに、本実施形態においては、ポートモニタ用拡張ファイルの内容を閲覧しても、メンテナンスコマンド自体が直接記述されていない。メンテナンスコマンド自体は、データベース５０６に記述されている。これによりは、テキストファイルであるポートモニタ用拡張ファイルにメンテナンスコマンドを保持するよりは、コマンド自体の機密性を向上させることが可能となる。

＜実施形態２＞
以下、図１０〜１２を参照し、本発明における第二の実施形態を説明する。本実施形態では、次世代ドライバで利用されるデータベース５０６で、複数機種のそれぞれに対応するメンテナンスコマンドデータが管理されている際の処理を説明する。本実施形態では、実施形態１で説明した図４、図５で示す構成、処理の流れについては同等である。

図１０は、実施形態２における次世代アプリ５０１のコマンドＩＤおよび機種ＩＤの送信処理を説明するためのフローチャートである。
本処理が開始されると、Ｓ１００１では、前述のユーティリティー機能を選択する画面６２０を介したユーザーからの入力を受け付ける。Ｓ１００２において、次世代アプリ５０１は、入力情報に基づき特定された、ユーザーに指定されたメンテナンスコマンドに対応するコマンドＩＤを取得する。次に、Ｓ１００３では、次世代アプリ５０１は情報処理装置１１０に接続された印刷装置１２０に対して要求を送信し、該印刷装置１２０から機種を特定する機種ＩＤを取得する。Ｓ１００４では、取得したコマンドＩＤと機種ＩＤをスプーラー５０２へ渡し、本処理を終了する。

実施形態２においては、後述する処理でデータベース５０６内の特定機種用のメンテナンスコマンドを利用するために、次世代アプリ５０１がコマンドＩＤに加え、印刷装置から機種ＩＤを取得している。なお、次世代アプリ５０１によるコマンドＩＤの取得と機種ＩＤの取得の処理順は、どちらを先に行っても良い。また、Ｓ１００３における機種ＩＤの取得は、印刷装置からの取得以外にも、ユーザーにより手動で入力させることにより実現しても良い。

図１１は、実施形態２における、ポートモニタ用拡張ファイル５０５に基づき動作するポートモニタ５０４のメンテナンスコマンドの送信処理を説明するためのフローチャートを示す。
Ｓ１１０１において、ポートモニタ５０４は、スプーラー５０２を経て、コマンドＩＤと機種ＩＤを取得する。Ｓ１１０２において、ポートモニタ５０４は、ポートモニタ用拡張ファイル５０５に従い、データベース５０６を参照し、該取得したコマンドＩＤと機種ＩＤから対応するメンテナンスコマンドを取得する。Ｓ１１０４において、ポートモニタ５０４は、ポートモニタ用拡張ファイル５０５に従い、該取得したメンテナンスコマンドの印刷装置５０７への送信を制御し、その後、本処理を終了する。

図１２は、次世代ドライバで利用されるデータベース５０６に格納されている複数機種分のメンテナンスコマンドデータを概念的に示す。メンテナンスコマンドデータ１２０１はそれぞれ１つの機種ＩＤ１２０２と１つのコマンドＩＤ１２０３に対応付けがなされ、データベース５０６に格納されている。ポートモニタ用拡張ファイル５０５では、データベース５０６を参照することで、機種ＩＤとコマンドＩＤから、送信すべきメンテナンスコマンドを特定する処理について記述されている。

ここで、メンテナンスコマンドデータと機種ＩＤとコマンドＩＤとを対応付ける情報は印刷装置のベンダにより提供される。また、機種ＩＤやコマンドＩＤとしては、整数値や文字列を任意に使用することも可能である。

また、１つのデータベース５０６に複数機種分のメンテナンスコマンドデータを格納する場合、機種毎に対応しているメンテナンス動作が異なる状況が想定されうる。そのため図１２では、ある機種が対応していないメンテナンス動作については、該当する欄を空欄などであらわし、そのメンテナンス動作に非対応であることを示す。一例として図１２では、機種ＩＤ“Ｂ”に対応する機種はコマンドＩＤ“３”で示されるメンテナンスコマンドは空欄となっており、非対応であることを示している。また、図１２において非対応コマンドは空欄により示されているが、“Ｎｏｎｅ”等の非対応コマンドであることを表す予約文字を示してもよい。

以上の処理により、メンテナンスコマンドを印刷ジョブとして送信できないような制限が課せられたＯＳ環境下であっても、機種を考慮したうえで、適切に印刷装置に対しメンテナンス動作の実行指示を行うことが可能となる。

＜実施形態３＞
以下、図１３、図１４を参照し、本発明における第三の実施形態を説明する。本実施形態は、実施形態２の拡張であり、構成や処理内容については、ほぼ共通する。差異としては、データベース５０６に格納されているメンテナンスコマンドデータが複数機種に対応するか否かを判別し、その結果に応じて後の処理を切り替える点である。

図１３は、実施形態３における次世代アプリ５０１のコマンドＩＤ、機種ＩＤの送信処理を説明するためのフローチャートである。図１０と同様な処理に関しては同じ符号を付与してあり、その説明は、ここでは割愛する。

Ｓ１３０１において、次世代アプリ５０１は、データベース５０６は複数機種をサポートしているかを判定する。この判定では、あらかじめデータベース５０６に、複数機種分のメンテナンスコマンドデータが格納されているか否かの情報を格納しておき、アプリケーションがその情報を参照することで判定を行う。Ｓ１３０１の判定結果で、サポートしていると判定された場合には、Ｓ１００３へ進む。その後、Ｓ１３０２において取得した情報（コマンドＩＤのみ、またはコマンドＩＤと機種ＩＤ）をスプーラー５０２へ渡し、本処理を終了する。

ここで、Ｓ１３０４の判定には、複数機種分の情報をデータベース５０６に対し命名規則を設け、ファイル名から判定する手法も適用でき、その判定手法はそれら例に限定されない。

図１４は、実施形態３における、ポートモニタ用拡張ファイル５０５に基づき動作するポートモニタ５０４のメンテナンスコマンドの送信処理を説明するためのフローチャートを示す。
Ｓ１４０１において、ポートモニタ５０４は、スプーラー５０２を経て、コマンドＩＤを取得する。Ｓ１４０２において、ポートモニタ５０４は、スプーラー５０２を経て、機種ＩＤを取得できたかを判定する。ここで、機種ＩＤも取得できたと判定された場合には、Ｓ１４０３において、ポートモニタ５０４は、ポートモニタ用拡張ファイル５０５に従い、データベース５０６を参照し、該取得したコマンドＩＤと機種ＩＤから、対応するメンテナンスコマンドを取得する。一方、Ｓ１４０２で、機種ＩＤが取得できなかったと判定された場合には、Ｓ１４０４において、ポートモニタ５０４は、ポートモニタ用拡張ファイル５０５に従い、データベース５０６を参照し、該取得したコマンドＩＤのみから、対応するメンテナンスコマンドを取得する。その後、Ｓ１４０５において、ポートモニタ５０４は、ポートモニタ用拡張ファイル５０５に従い、該取得したメンテナンスコマンドの印刷装置５０７への送信を制御し、その後、本処理を終了する。

＜実施形態４＞
以下、図１５と図１６を参照し、本発明における第四の実施形態を説明する。本実施形態ではメンテナンス実行処理において、ポートモニタ５０４がデータベース５０６からメンテナンスコマンドの取得に失敗した際の処理に関する。前述したように、次世代ドライバはＧＵＩ画面の表示機能を持たないので、前述のユーティリティー機能を選択する画面６２０を介したユーザーからのメンテナンス実行指示の入力に対して、メンテナンスコマンドの取得の失敗を通知できない。本実施形態では、その点を考慮した例外処理を具体的に説明するものである。

図１５は、ポートモニタ用拡張ファイル５０５に基づき動作するポートモニタ５０４のメンテナンスコマンドの送信処理を説明するためのフローチャートを示す。
Ｓ１５０１は、ポートモニタ５０４が実行するデータベース５０６からメンテナンスコマンドを取得する処理である。具体的には、前述の実施形態１〜３において説明したいずれかの処理が実行されることになる。次に、Ｓ１５０２では、ポートモニタ５０４が、メンテナンスコマンドの取得に成功したか否かの判定を行う。メンテナンスコマンドの取得に成功した場合はＳ１５０３へ進み、失敗した場合にはＳ１５０４に進む。

Ｓ１５０３では、ポートモニタ５０４が、取得したメンテナンスコマンドを送信バッファへ格納する。一方、Ｓ１５０４では、ポートモニタ５０４が、メンテナンスコマンドの代わりにエラー発生用データを送信バッファへ格納する。その後、Ｓ１５０５において、ポートモニタ５０４が、バッファ内の情報の印刷装置５０７への送信を制御し、その後、本処理を終了する。

図１６は、図１５でポートモニタ５０４から送信されたデータを受信した印刷装置１２０の動作を説明するためのフローチャートである。
Ｓ１６０１において、印刷装置１２０はポートモニタ５０４から送信されたデータを受信する。Ｓ１６０２では、受信したデータがエラー発生用データか否かの判定を行う。ここで、受信したデータがエラー発生用データならばＳ１６０３へ進み、そうでなければＳ１６０５に進む。

Ｓ１６０３では、印刷装置５０７は、エラー発生用データに従い、エラー状態へ遷移する。このタイミングで、印刷装置でエラーが発生したことが、印刷装置の操作部やネットワークを介したエラー出力により、ユーザーに通知される。なお、特定のエラー発生用データに従うエラーに関しては、メンテナンス実行が失敗した旨の通知を行うものとしてもよい。Ｓ１６０４では、エラー状態が解消されるまでエラー処理を継続する。エラー状態の解除手段としては、印刷装置５０７にエラー解除ボタンを設け、ユーザーがそのボタンを押下することにより印刷装置５０７のエラー状態を解消する手法が一例として挙げられる。Ｓ１６０５において印刷装置５０７は受信したデータに従い処理を実行する。ここでは、メンテナンスコマンドデータに応じた動作を実行することになる。その後、本処理は終了する。

以上の形態により、前述されたＵＩモジュールを持たない次世代ドライバを利用する際にも、メンテナンスコマンドの取得に失敗したなどの理由で、メンテナンスの実行ができない場合に、そのエラーをユーザーに対し通知することが可能である。

＜その他の実施形態＞
また、本発明は、以下の処理を実行することによっても実現される。即ち、上述した実施形態の機能を実現するソフトウェア（プログラム）を、ネットワーク又は各種記憶媒体を介してシステム或いは装置に供給し、そのシステム或いは装置のコンピュータ（またはＣＰＵやＭＰＵ等）がプログラムを読み出して実行する処理である。

さらに、本発明には、上述した実施形態の適宜組み合わせることにより構成されたシステムやその機能も含まれるものとする。

Claims

印刷装置と接続されている情報処理装置であって、
コマンド識別子とメンテナンスコマンドとを対応づけて管理するデータベースと、
拡張ファイルに従い機能するポートモニタにより、アプリケーションで指定され、スプーラーを介して取得されたコマンド識別子に対応するメンテナンスコマンドを前記データベースから取得する取得手段と、
前記拡張ファイルに従い機能するポートモニタにより、前記取得されたメンテナンスコマンドを前記印刷装置に送信する送信手段と、を有することを特徴とする情報処理装置。
前記取得手段は、前記印刷装置から取得した機種識別子と前記コマンド識別子とを用いて、前記データベースから対応するメンテナンスコマンドを取得することを特徴とする請求項１に記載の情報処理装置。
前記取得手段は、前記データベースが機種ごとにメンテナンスコマンドを管理していない場合には、前記コマンド識別子のみを用いて、前記データベースから対応するメンテナンスコマンドを取得することを特徴とする請求項２に記載の情報処理装置。
前記送信手段は、前記取得手段がメンテナンスコマンドの取得に失敗した場合には、前記印刷装置によりエラーを通知するために、エラー用のデータを印刷装置に送信することを特徴とする請求項１乃至３のいずれか１項に記載の情報処理装置。
印刷装置とＵＳＢ（ＵｎｉｖｅｒｓａｌＳｅｒｉａｌＢｕｓ）を介して接続されている情報処理装置であって、
コマンド識別子とメンテナンスコマンドとを対応づけて管理するデータベースと、
拡張ファイルに従い機能するポートモニタにより、アプリケーションで指定され、スプーラーを介して取得されたコマンド識別子に対応するメンテナンスコマンドを前記データベースから取得する取得手段と、
前記拡張ファイルに従い機能するポートモニタにより、前記取得されたメンテナンスコマンドを、前記ＵＳＢを介して前記印刷装置に送信する送信手段と、を有し、
前記送信手段は、前記取得手段がメンテナンスコマンドの取得に失敗した場合には、前記印刷装置によりエラーを通知するために、エラー用のデータを印刷装置に送信することを特徴とする情報処理装置。
印刷装置と接続されている情報処理装置における方法であって、
コマンド識別子とメンテナンスコマンドとを対応づけてデータベースで管理する工程と、
拡張ファイルに従い機能するポートモニタにより、アプリケーションで指定され、スプーラーを介して取得されたコマンド識別子に対応するメンテナンスコマンドを前記データベースから取得する取得工程と、
前記拡張ファイルに従い機能するポートモニタにより、前記取得されたメンテナンスコマンドを前記印刷装置に送信する送信工程と、を有することを特徴とする方法。
ポートモニタにより、アプリケーションで指定され、スプーラーを介して取得されるコマンド識別子を用いてデータベースから対応するメンテナンスコマンドを取得させ、印刷装置に対して当該メンテナンスコマンドを送信させるための拡張ファイルをインストールするようコンピュータを機能させるためのプログラム。