JP5950613B2 - プログラム及び情報処理装置、制御方法 - Google Patents

Description

本発明はプログラム間でパラメータを受け渡す技術に関する。

プリンタのメンテンスを行う際には特許文献１に示すようにプリンタにメンテナンス機能を実行させるメンテナンスコマンドを、スプーラーを利用してメンテナンスジョブとしてプリンタに送信することが可能であった。

特開２００７−１１４６９号公報

アプリケーションやプリンタドライバが特許文献１で開示されている環境とは異なる環境で動作する場合に特許文献１と同一の方法では情報処理装置とプリンタで適切なデータのやりとりができない可能性がある。よって、前述の異なる環境で動作する場合に、情報処理装置とプリンタで適切なデータのやりとりを可能とするための種々の対策が望まれていた。

上記の目的を達成するための本発明に係るプログラムは、コンピュータを、ユーザーが実行を指示する機能が第１の機能である場合はストリング型の領域外のデータを含むバイナリデータを前記ストリング型のデータに変換して第１のパラメータにセットして前記第１のパラメータを送り、ユーザーが実行を指示する機能が前記第１の機能とは異なる第２の機能である場合は前記第１のパラメータとは異なり前記第２の機能に対応する第２のパラメータを送るアプリケーション手段と、前記アプリケーション手段が送るパラメータが前記第１のパラメータである場合は前記第１のパラメータに含まれる前記ストリング型の前記データを前記バイナリデータに変換して印刷装置に前記バイナリデータを送信することを指示して、前記アプリケーション手段が送るパラメータが前記第２のパラメータである場合は前記第２のパラメータに対応する前記データを前記印刷装置に送信することを指示する送信手段として機能させる。

本発明によれば前述の異なる環境で望ましい動作をするプログラムを提供することが可能となる。

印刷装置と印刷装置に接続された情報処理装置によって構成される印刷システムを示すブロック図 レガシーアーキテクチャーによるプリンタドライバの構成を示すブロック図 レガシーアーキテクチャーによるプリンタドライバにおけるメンテナンス実行処理の流れを示すブロック図 次世代アーキテクチャーによるプリンタドライバの構成を示すブロック図 次世代アプリ４０１でメンテナンス機能用のボタンが実行された際の処理フローを示したフローチャート 次世代アプリ４０１が情報送信関数をコールされた際に呼び出されるポートモニタ用拡張ファイル４１２内の処理フローを示したフローチャート 実施形態１における次世代アプリ４０１のＵＩ画面例を示した一例 実施形態１における拡張スキーマ定義ファイル４１３を示す一例 実施形態１における次世代アプリ４０１の変形例として起動時にメイン画面を表示するまでの処理を示したフローチャート 実施形態１における次世代アプリ４０１の変形例を示すＵＩ画面例 画像ファイルを表示する次世代アプリ４０２の画面構成例 次世代アプリ４０２が画像ファイルを印刷装置４０７に送信する処理を示したフローチャート 次世代アプリ４０１起動時に印刷ボタン１１０７を表示するまでの処理の流れ

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

図１は情報処理装置１１０と情報処理装置１１０に接続された印刷装置１２０により構成される印刷システムの全体構成を示すブロック図の一例である。

図１において情報処理装置１１０は一般的なＰＣで構成される。後述するようなハードウェアで構成され、ＯＳとして、例えば米国マイクロソフト社のＷｉｎｄｏｗｓ（登録商標）７がインストールされている。無論ＯＳの種類はこれに限定されない。

情報処理装置１１０は入力Ｉ／Ｆ１１１、ＣＰＵ１１２、ＲＯＭ１１３、出力Ｉ／Ｆ１１４、外部記憶装置１１５、ＲＡＭ１１６、入力装置１１７、出力装置１１８、入出力Ｉ／Ｆ１１９を有する。ＲＯＭ１１３は初期化プログラムを保存し、外部記憶装置１１５はＯＳ、プリンタドライバやその他各種のデータが保存されている。

ＲＡＭ１１６は外部記憶装置１１５に保存される各種プログラムがワークメモリーとして使用する。

入力装置１１７はデータ入力や動作指示に使用され入力Ｉ／Ｆ１１１に接続されている。

出力装置１１８はデータ表示や状態の通知に使用され出力Ｉ／Ｆ１１４に接続されている。

印刷装置１２０はＲＡＭ１２１、ＲＯＭ１２２、プリントエンジン１２３、ＣＰＵ１２４、入出力Ｉ／Ｆ１２５から構成される。

情報処理装置１１０と印刷装置１２０はＵＳＢ（ＴＭ）ケーブル１３０により接続されており、互いに双方向通信が可能である。

ＵＳＢとはＵｎｉｖｅｒｓａｌ Ｓｅｒｉａｌ Ｂｕｓの略であり、双方向通信が可能な公知のインタフェースである。なお、以下では情報処理装置１１０の通信インタフェースとして、ＵＳＢインタフェースを例に説明を行うが、これに限定されない。例えば、無線通信に適用しても良いし、セントロニクスインタフェース、イーサーネットケーブルを介したＬＡＮインタフェース等を適用しても良い。

ＲＡＭ１２１はＣＰＵ１２４のワークメモリーとして使用され、受信したデータの一時保存用バッファとしても利用される。ＲＯＭ１２２は制御命令を保存している。プリントエンジン１２３はＲＡＭ１２１に保存されたデータに基づき印刷を行う。

ＣＰＵ１２４はＲＯＭ１２２に保存されている制御命令に従い印刷装置１２０を制御する。

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

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

図２は情報処理装置１１０に適用可能な従来の印刷システムであるレガシードライバを概念的に表したブロック図を示している。

アプリケーション２０１が作成した印刷データは、ＯＳの印刷サポート機能２０２を介しＵＩモジュール２１１から返却される印刷設定情報が付加され、スプールデータ２０５としてスプーラー２０３のプリントキュー２０４に一時的に保存される。

スプールデータ２０５はレガシードライバ２１０によって印刷装置２０７（構成要素は印刷装置１２０と同様）が解釈可能な印刷コマンドへ変換された後、ＵＳＢポートモニタ２０６へ出力される。
レガシードライバ２１０は前述のＵＩモジュール２１１に加え後述するグラフィックスドライバ２１３、ランゲージモニタ２１４の各モジュールから構成されるものである。

ＵＳＢポートモニタ２０６は入力された印刷コマンドを印刷装置２０７へ送信する。

この印刷コマンドとは、そのデータを印刷装置１１０に送信すると、印刷装置１１０により印刷されるデータである。具体的例を示すと、グラフィックスドライバ２１３によりラスタライズ処理されたＲＧＢ各８ｂｉｔデータに対して、ＣＭＹＫ３２ｂｉｔデータに変換し、量子化を行い、さらにプリンタが解釈して印刷可能となったコマンドのことである。

ここでＵＩモジュール２１１は印刷装置２０７に対しメンテナンス動作を指示するメンテナンス処理指示部２１２を有することができる。

ユーザーはＵＩモジュール２１１が提供するＵＩ画面からメンテナンス動作を選択することで印刷装置２０７へメンテナンス動作の指示を行うことができる。

また、アプリケーション２０１は、ＯＳの双方向通信サポート機能２０２を使用して、レガシードライバ２１０のランゲージモニタ２１４がＵＳＢポートモニタを介して印刷装置２０７と双方向通信を行い、印刷装置２０７のステータス情報を表示する。

ここでいうＯＳの双方向通信サポート機能２０２とは、Ｍｉｃｒｏｓｏｆｔ ＤｅｖｅｌｏｐｅｒＮｅｔｗｏｒｋ（以下ＭＳＤＮ）で説明されている為、詳細な説明は記述しないが、例えばｂｉｄｉｒｅｃｔｉｏｎａｌ ｐｒｉｎｔｅｒ ｃｏｍｍｕｎｉｃａｔｉｏｎであり、ｂｉｄｉ ｓｐｏｏｌｅｒ ＡＰＩを利用してｂｉｄｉ ｓｃｈｅｍａという設定情報を介して印刷装置２０７とステータス情報の受け渡しを行うことが可能である。

図３ではレガシードライバにおけるメンテナンス実行処理の流れを示すブロック図である。

ＵＩモジュール２１１に含まれるメンテナンス処理指示部３０１（図２中では２１２）はユーザーからの指示に応じて印刷装置３０８が解釈可能なメンテナンス制御コマンドを作成しスプーラー３０２へ送信する。

ここでいうメンテナンス制御コマンドとは、Ｂｉｎａｒｙ形で制御される実行命令コマンドである。印刷装置２０７はＢｉｎａｒｙ型制御コマンドを受け取り動作する。

スプーラーへメンテナンス制御コマンドを送信する方法としては、ＭＳＤＮで説明されているＰｒｉｎｔＳｐｏｏｌｅｒ ＡＰＩを使用することが一般的である。

詳細な説明は記述しないが、前述した送信方法の１例としては以下の通りである。ＯｐｅｎＰｒｉｎｔｅｒ関数を使用して送信する印刷装置２０７を特定し、ＳｔａｒｔＤｏｃＰｒｉｎｔｅｒ関数、ＳｔａｒｔＰａｇｅＰｒｉｎｔｅｒ関数を使用して、印刷ジョブを開始し、ＷｒｉｔｅＰｒｉｎｔｅｒ関数でメンテナンス制御コマンドを書き込み、ＥｎｄＰａｇｅＰｒｉｎｔｅｒ関数、ＥｎｄＤｏｃＰｒｉｎｔｅｒ関数を使用して、印刷ジョブを終了することでメンテナンス制御コマンドを印刷ジョブとしてスプーラーを介して印刷装置に送信することが可能になる。

スプーラー３０２は受信したメンテナンス制御コマンドをスプールデータ３０４としてプリントキュー３０３へ一時的に保存する。

スプールデータ３０４はグラフィックスドライバ３０５、ランゲージモニタ３０６を経由しＵＳＢポートモニタ３０７へ出力される。

スプールデータ３０４のタイプによってはグラフィックスドライバ３０５を経由せずに直接ランゲージモニタ３０７を経由してＵＳＢポートモニタへ出力される場合もある。

ここで前記メンテナンス制御コマンドはグラフィックスドライバ３０５への入力時に、既に印刷装置３０８が解釈可能な体を成しているため、入力されたメンテナンスコマンドに対しグラフィックスドライバ３０５は前述の変換処理を実施する必要はない。

そのためメンテナンス処理指示部３０１はメンテナンスコマンド発行処理によりスプーラー３０２へ渡るジョブに前記変換処理実施の如何を示す情報を記し、グラフィックスドライバ３０５は前記変換処理の実施の如何を示す情報に従って変換動作を制御する。

ＵＳＢポートモニタ３０７は入力されたメンテナンス制御コマンドを印刷装置３０８へ送信することでメンテナンス動作が実行される。

＜実施形態１＞
次に図４から図８を参照し本発明の実施形態１について説明する。
本実施形態では後述する次世代アーキテクチャーによるプリンタドライバ（以後、次世代ドライバ）で利用されるポートモニタ用拡張ファイルと、拡張スキーマ定義ファイルが使用可能である場合を例として説明する。

本実施例ではＵＳＢポートモニタを対象としたポートモニタ用拡張ファイルとして説明するが、他ポートでもポートモニタ用拡張ファイルが動作すれば同じ構成で動作可能であることはいうまでも無い。

図４ではレガシードライバ２１０と構成の異なる印刷システムであり情報処理装置１１０に適用可能な次世代ドライバを概念的に表したブロック図を示す。

通常の印刷処理時の処理の流れを説明すると、アプリケーション４０１が作成した印刷データは、ＯＳの印刷サポート機能４０２を介し、スプールデータ４０５としてスプーラー４０３のプリントキュー４０４へ一時的に保存される。

スプールデータ４０５はグラフィックスドライバ４１１により印刷装置１２０が解釈可能な印刷コマンドへ変換される。
生成された印刷コマンドはＵＳＢポートモニタ４０６を経由し、印刷装置４０７へ到達する。

ここでファイル群４１０が次世代ドライバを構成するファイル群の一例である。

本発明で想定する新たなＯＳの次世代ドライバ４１０の構成要素には、レガシードライバ２１０の構成要素に含まれるＵＩモジュール２１１とランゲージモニタ２１４が含まれない。

次世代ドライバは印刷設定などの各種設定は、基本的にＯＳが用意するＵＩモジュールを使用する必要があり、基本的な印刷設定を行う分には十分であるが、多機能なプリンタベンダー独自のＧＵＩを持つことはできない。

しかし、次世代ドライバ４１０と紐づけられた外部アプリケーション４０１（以後、次世代アプリ）により各種設定を行うＧＵＩを提供することが可能になる。

この次世代アプリ４０１が使用可能なＯＳの機能は限定され、レガシードライバのＵＩモジュール２１１で使用可能であったメンテナンス制御コマンドを印刷ジョブとしてスプールすることはできない場合がある。

また、レガシードライバ２１０のランゲージモニタ２１４が無いかわりに、次世代アプリ４０１が印刷装置４０７と双方向通信を行うための新しい構成要素としてポートモニタ用拡張ファイル４１２が用意されている。

このポートモニタ用拡張ファイル４１２は、次世代ドライバ４１０の構成要素として提供可能である。また、ポートモニタ用拡張ファイル４１２は、ＪａｖａＳｃｒｉｐｔ（登録商標）により記述され、ＯＳ機能を拡張する為のスクリプトファイルである。さらに、ポートモニタ用拡張ファイル４１２は、次世代アプリ４０１がＯＳ機能を利用して双方向通信を行った際にＣＰＵ１１２により実行されるポートモニタ４０６が呼び出して実行するスクリプトファイルである。ポートモニタ用拡張ファイル４１２により、印刷装置４０７からの情報の取得や、情報の送信が可能になる。

本実施例ではＵＳＢポートモニタ用の拡張ファイルとして説明するが、ポートモニタが拡張ファイルに対応し、次世代ドライバ４１０の構成として使用可能となる構成であればＵＳＢポートに限るものでないことは明らかである。

また、本実施例ではポートモニタ拡張ファイルはスクリプトファイルとして説明するが、例えばダイナミックリンクライブラリとして提供し、ポートモニタがポートモニタ拡張ファイル４１２をロードして使用可能な次世代ドライバ４１０の構成であれば動作は可能であり、スクリプトファイルに限定されるものではない。

次世代アプリ４０１は、印刷装置４０７と双方向通信を行う際には、ＯＳの双方向通信サポート機能４０８を使用して、拡張スキーマ定義ファイル４１３に定義してあるスキーマと、スクリプトで記述されたポートモニタ用拡張ファイル４１２を利用して、印刷装置４０７と双方向通信を行うことが可能になる。

この次世代アプリ４０１がポートモニタ用拡張ファイル４１２を介して双方向通信を行う際に情報の受け渡しを行う為に使用するパラメータ内には、スキーマをセットすることが可能である。スキーマは値（Ｖａｌｕｅ）と値（Ｖａｌｕｅ）に対応するスキーマパスで構成されている。以降記載するスキーマはこのパラメータ内のスキーマを意味するものとする。

ポートモニタ用拡張ファイル４１２は、次世代アプリ４０１がＢｉｄｉ Ｐｒｉｎｔｅｒ ｃｏｍｍｕｎｉｃａｔｉｏｎのＧｅｔ機能を使用すると、スプーラーを介してＵＳＢポートモニタから呼び出され、スキーマ内に格納された印刷装置４０７の返却したステータス情報を取得し解析処理することが可能である。

またポートモニタ用拡張ファイル４１２は、次世代アプリ４０１がＢｉｄｉ Ｐｒｉｎｔｅｒ ｃｏｍｍｕｎｉｃａｔｉｏｎのＳｅｔ機能を使用すると、スプーラーを介してＵＳＢポートモニタ４０６から呼び出される。その後ポートモニタ用拡張ファイル４１２は、アプリケーションが格納したスキーマ内のＳｔｒｉｎｇ型のデータを取得し、印刷装置４０７にＵＳＢポートモニタ４０６を介してデータを送信することが可能である。

本明細書ではＢｉｄｉ Ｐｒｉｎｔｅｒ ｃｏｍｍｕｎｉｃａｔｉｏｎのパラメータ内のスキーマのＶａｌｕｅはＢｉｎａｒｙ型の情報（バイナリデータ）を扱えないものとする。バイナリデータを扱えない状況の具体例としてはＳｔｒｉｎｇ型で扱うことのできる領域を超えている領域外のデータをＶａｌｕｅに含めることができない場合が考えられる。

前述したように、次世代アプリ４０１は、メンテナンス制御コマンドを印刷ジョブとしてスプールすることはできないが、印刷装置４０７と双方向通信を行うことは可能なため、前述したポートモニタ用拡張ファイル４１２のＳｅｔ機能を使用することで印刷装置４０７に送信することが可能になる。

次に図５〜図８を使用して、次世代アプリ４０１から実際にメンテナンス制御コマンドを印刷装置４０７に送信する具体例を示す。

図７は、次世代アプリ４０１のＵＩ画面例を示した１例である。

７１０が次世代アプリの起動直後に表示されるメイン画面であり、内部に各種機能を実行するためのボタンが配置されている。

ボタン７１１は、印刷装置４０７の詳細操作、機能説明を記載されたテキストファイルを表示するためのボタンであり、本ボタンをユーザーが実行した時に、印刷装置４０７の詳細操作、機能説明を記載されたテキストファイルを表示する。

ボタン７１２は、プリンタメンテナンス機能Ａを実行するためのボタンであり、本ボタンをユーザーが実行した時に、プリンタメンテナンス機能Ａが実行される。プリンタメンテナンス機能Ａ用のメンテナンス制御コマンドはポートモニタ用拡張ファイル４１２内に記述されている。

ボタン７１３は、プリンタメンテナンス機能Ｂを実行するためのボタンであり、本ボタンをユーザーが実行した時に、プリンタメンテナンス機能Ｂが実行される。プリンタメンテナンス機能Ｂ用のメンテナンス制御コマンドは、ポートモニタ用拡張ファイル４１２内に記述されていない為、次世代アプリ４０１内に格納されている。

ここでは次世代アプリ４０１のＵＩ画面例として上記の画面構成を示したが、この構成に限られることはなく他の画面構成でもあっても構わない。

図８は、拡張スキーマ定義ファイル４１３を示す一例であり、ＸＭＬのマークアップ言語で記述されている。

プリンタメンテナンス機能Ａ用のスキーマは、ＶａｌｕｅＴｙｐｅはＢＩＤＩ＿ＢＯＯＬ型、ａｃｃｅｓｓＴｙｐｅはＳｅｔ、スキーマパスは￥￥Ｐｒｉｎｔｅｒ．Ｍａｉｎｔｅｎａｎｃｅ．Ｃｏｍｍａｎｄ：ＴｙｐｅＡとして定義されている。

プリンタメンテナンス機能Ｂ用のスキーマは、ＶａｌｕｅＴｙｐｅはＢＩＤＩ＿ＳＴＲＩＮＧ型、ａｃｃｅｓｓＴｙｐｅはＳｅｔ、スキーマパスは￥￥Ｐｒｉｎｔｅｒ．Ｍａｉｎｔｅｎａｎｃｅ．Ｄｉｒｅｃｔ：ＴｙｐｅＢとして定義されている。

ここでは図７に提示した次世代アプリ４０１のサポートするメンテナンス機能に合わせた数のスキーマしか表示していないが、例えばステータス取得用のスキーマ等、その他の機能に応じて定義しておく必要があることはいうまでもない。

また、メンテナンス機能Ｂ用のスキーマパスをメンテナンス制御コマンドの直接送信を想像しやすい名称にしているが、スキーマパスの名称は自由である。

図５は、次世代アプリ４０１でメンテナンス機能用のボタンが実行された際の処理フローを示したフローチャートである。

次世代アプリ４０１のフローチャートはＣＰＵ１１２が外部記憶装置１１５に記憶されているプログラムに基づき処理を実行することによって各ステップの処理が実現される。

図６は、次世代アプリ４０１が情報送信関数をコールされた際に呼び出されるポートモニタ用拡張ファイル４１２内の処理フローを示したフローチャートである。

この二つのフローチャートを使用して、次世代アプリ４０１でボタン７１２とボタン７１３のプリンタメンテナンス機能を実行する際の処理フローを説明する。

（次世代アプリによるプリンタメンテナンス機能Ａの処理）
ボタン７１２が実行された場合は、Ｓ５０１で、実行するメンテナンス機能がポートモニタ用拡張ファイル４１２内でサポートされているかを判断する。ボタン７１２のメンテナンス機能Ａは、ポートモニタ拡張ファイル４１２内にＢｉｎａｒｙ型のメンテナンス制御コマンドが予め記述されている為、Ｓ５０２に進む。

なお、Ｓ５０１の判断はユーザーから受け付けたボタンが７１２であるか７１３であるかを判断することにより行なっても構わない。

Ｓ５０２では、次世代アプリ４０１がパラメータにプリンタメンテナンス機能Ａ用のスキーマをセットし、Ｓ５０５に進む。ここでプリンタメンテナンス機能Ａ用のスキーマのスキーマパスはポートモニタ拡張ファイルの既知の機能を呼び出すことを示す情報を入力している。

本実施形態で既知の機能とはポートモニタ拡張ファイル内又はポートモニタ拡張ファイルが読みだすことのできるファイル内に記載されている機能を示している。

Ｓ５０５では、次世代アプリ４０１が情報送信関数をコールして次世代アプリ４０１は処理を終了する。

本明細書で情報送信関数とはＢｉｄｉ Ｐｒｉｎｔｅｒ ｃｏｍｍｕｎｉｃａｔｉｏｎで用いられる関数であり、情報送信関数をコールすることでスキーマがセットされたパラメータをポートモニタ用拡張ファイル４１２に送ることができる。

（ポートモニタ用拡張ファイルによるプリンタメンテナンス機能Ａの処理）
ポートモニタ用拡張ファイル４１２は、次世代アプリ４０１が情報送信関数をコールした後で呼び出され、Ｓ６０１に進む。

Ｓ６０１では、受け取ったパラメータを解析し、Ｓ６０２に進む。

Ｓ６０２では、解析した結果から受け取ったパラメータの種類を判別する。受け取ったパラメータは、ポートモニタ拡張ファイル４１２内の既知の機能名として判別され、Ｓ６０３に進む。

Ｓ６０３では、ポートモニタ拡張ファイルが予め持っているＢｉｎａｒｙ型の、受け取ったパラメータに対応するメンテナンス制御コマンドをＵＳＢポートモニタ４０６に出力して処理を終了する。

なお、ポートモニタ拡張ファイルが予め持っているＢｉｎａｒｙ型のデータはメンテナンス制御コマンドに限られない。具体的には印刷装置４０７の電源を切ったり、自動的に印刷装置４０７の電源の切る時間の設定を行ったり、といったプリンタ動作を制御するプリンタ制御コマンドが考えられる。

さらに、印刷装置４０７がＳｔｒｉｎｇ型のメンテナンス制御コマンドを受け取ることができる場合はＵＳＢポートモニタ４０６に出力するメンテナンス制御コマンドはＢｉｎａｒｙ型に限らずＳｔｒｉｎｇ型であってもよい。

ＵＳＢポートモニタ４０６は印刷装置４０７にメンテナンス制御コマンドを送信し、印刷装置４０７は受け取ったメンテナンス制御コマンドを実行する。

これによりボタン７１２が実行された際に、メンテナンス機能Ａが実行されることとなる。

（次世代アプリによるプリンタメンテナンス機能Ｂの処理）
次にボタン７１３が実行された場合は、Ｓ５０１で、実行するメンテナンス機能がポートモニタ用拡張ファイル４１２でサポートされているかを判断し、ボタン７１３のメンテナンス機能Ｂは、ポートモニタ拡張ファイル４１２内にメンテナンス制御コマンドが記述されていない為、Ｓ５０３に進む。

なお、前述のようにＳ５０１の判断はユーザーから受け付けたボタンが７１２であるか７１３であるかを判断することにより行なっても構わない。

Ｓ５０３では、次世代アプリ４０１がパラメータにプリンタメンテナンス機能Ｂ用のスキーマをセットし、Ｓ５０４に進む。ここでセットされたプリンタメンテナンス機能Ｂ用のスキーマのスキーマパスには、メンテナンス制御コマンドを次世代アプリ４０１から渡すことを意味する直接送信モードを示す情報を入力している。

Ｓ５０４では、次世代アプリ４０１内に格納されているプリンタメンテナンス機能Ｂ用のメンテナンス制御コマンドをＳｔｒｉｎｇ型にデータ変換を行い、パラメータ内のスキーマのＶａｌｕｅにセットする。Ｓ５０４のＳｔｒｉｎｇ型へのデータ変換方法は後で詳細に説明する。

Ｓ５０５では、次世代アプリ４０１が情報送信関数をコールして次世代アプリ４１０は処理を終了する。

（ポートモニタ用拡張ファイルによるプリンタメンテナンス機能Ｂの処理）
ポートモニタ用拡張ファイル４１２は、次世代アプリ４０１が情報送信関数をコールした後で呼び出される。以下にポートモニタ用拡張ファイル４１２が実行する処理を説明する。

なお、既に説明したステップについては説明を省略する。

Ｓ６０２で解析した結果から受け取ったパラメータの種類を判別する。受け取ったパラメータ内に格納されているメンテナンス制御コマンドを直接送信するモードと判別してＳ６０４に進む。

Ｓ６０４では、受け取ったパラメータ内に格納されているＳｔｒｉｎｇ型のメンテナンス制御コマンドをＢｉｎａｒｙ型のメンテナンス制御コマンドに変換し、Ｓ６０５に進む。Ｓ６０４のＳｔｒｉｎｇ型のメンテナンス制御コマンドをＢｉｎａｒｙ型に変換する方法は後で詳細に説明する。

Ｓ６０５では、変換したＢｉｎａｒｙ型のメンテナンス制御コマンドをポートモニタに出力して処理を終了する。

ＵＳＢポートモニタ４０６は印刷装置４０７にＢｉｎａｒｙ型のメンテナンス制御コマンドを送信し、印刷装置４０７は受け取ったメンテナンス制御コマンドを実行する。

これによりボタン７１３が実行された際に、メンテナンス機能Ｂが実行されることとなる。

なお、メンテナンス制御コマンドは次世代アプリ４０１がＢｉｎａｒｙ型のメンテナンス制御コマンドをＳｔｒｉｎｇ型に予め変換された形式で保持しておいても構わない。変換された形式で保持する場合はＳｔｒｉｎｇ型のメンテナンス制御コマンドをパラメータに含めて次世代アプリ４０１が情報送信関数をコールすることでポートモニタ用拡張ファイル４１２がメンテナンス制御コマンドを扱うことが可能となる。このように構成した場合はＳ５０４のＳｔｒｉｎｇ型へのデータ変換は不要である。

（既知の機能と直接送信モードの差異）
例えば情報処理装置１１０のシステム環境上の制約でポートモニタ用拡張ファイル４１２のファイルサイズが限られているものとする。こうした状況において、既知の機能としてポートモニタ用拡張ファイル４１２に用意することのできるメンテナンス制御コマンドは限られる。よって、印刷装置の複数機種で共通のメンテナンス制御コマンドは既知の機能としてポートモニタ用拡張ファイル４１２に用意する。そして、次世代アプリ４０１内に印刷装置の機種ごとにカスタマイズされたメンテナンス制御コマンドを用意することにより、ポートモニタ用拡張ファイル４１２の肥大化を防ぐことができる。

＜Ｂｉｎａｒｙ型とＳｔｒｉｎｇ型とのデータ変換例＞
次に次世代アプリ４０１のＳ５０４のＳｔｒｉｎｇ型へのデータ変換と、ポートモニタ用拡張ファイル４１２のＳ６０４のＢｉｎａｒｙ型へのデータ変換方法について詳細に説明する。

ここでは、＠Ｃｌｅａｎｉｎｇというメンテナンス制御コマンドを送信する場合の変換例を以下に示す。

＠Ｃｌｅａｎｉｎｇというメンテナンス制御コマンドを送信したい場合、送信するためのＢｉｎａｒｙ型データは以下の１０ｂｙｔｅの配列となる。

１６進数表記 “０ｘ４０，０ｘ４３，０ｘ６ｃ，０ｘ６５，０ｘ６１，０ｘ６ｅ，０ｘ６９，０ｘ６ｅ，０ｘ６７，０ｘ０ａ”
１０進数表記 “６４，６７，１０８，１０１，９７，１０５，１１０，１０５，１０３，１０”
Ｓ５０４では、この１ｂｙｔｅの配列のメンテナンス制御コマンドを、１ｂｙｔｅ毎に２文字のＳｔｒｉｎｇ型データにＡＳＣＩＩ文字コードでエンコードして変換を行う。

具体的には、各値を１６で割った値で１文字、および１６で割ったときの余りを１文字として変換を行い、送信データの全てに対してこの変換を行う。

なお、値が１０〜１５になった場合は、大文字のＡ〜Ｆの文字をセットするとあらかじめルールを決めておき、Ｂｉｎａｒｙ型データ逆変換時はその対応に基づき処理を行う。

上記アルゴリズムでＢｉｎａｒｙ型データからＳｔｒｉｎｇ型データに変更した場合、例えば、６４は、４，０と変換され、１０８は、６，Ｃと変換されＳｔｒｉｎｇ型データとして格納される。

Ｓ５０４で、前記Ｂｉｎａｒｙ型データ全てを変換した結果、Ｓｔｒｉｎｇ型データは、
“４，０，４，３，６，Ｃ，６，５，６，１，６，Ｅ，６，９，６，Ｅ，６，７，０，Ａ”
となる。次世代アプリ４０１が１ｂｙｔｅの配列としてパラメータにセットを行う。

このようにしてＢｉｎａｒｙ型データを、Ｓｔｒｉｎｇ型データに変換を行うことが可能である。

次にポートモニタ用拡張ファイル４１１のＳ６０４で受け取った前記Ｓｔｒｉｎｇ型データは、１０進数で表現すると、
“５２，４８，５２，５１，５４，６７，５４，５３，５２，４９，５４，６９，５４，５７，５４，６９，５４，５５，４８，６５”
となる。これをＳ６０４ではＢｉｎａｒｙ型データに逆変換を行う。

最初の文字を、値が４８（“０”）から５７（“９”）のときは、値から４８をマイナスし、値が６５（“Ａ”）から７０（“Ｆ”）のときは、値から５５をマイナスし、１ｂｙｔｅの上位４ｂｉｔとしてセットする。

次の文字を、値が４８から５７のときは、値から４８をマイナスし、値が６５から７０のときは、５５をマイナスし、１ｂｙｔｅの下位４ｂｉｔとしてセットする。

例えば、５２、４８の文字列は、０ｘ４０， ５４、６７の文字列は、０ｘ６ｃ と逆変換されることになる。

以上のように全ての文字列を変換すると、
１６進数 “０ｘ４０，０ｘ４３，０ｘ６ｃ，０ｘ６５，０ｘ６１，０ｘ６ｅ，０ｘ６９，０ｘ６ｅ，０ｘ６７，０ｘ０ａ”
に逆変換されることになる。

このようにしてＳｔｒｉｎｇ型データで受け取ったデータ配列を、Ｂｉｎａｒｙ型データに逆変換を行うことが可能である。

なお、ここで説明したＢｉｎａｒｙデータとＳｔｒｉｎｇデータの変換、逆変換のアルゴリズムはＡＳＣＩＩ文字コードを使用した例である。前述の変換を行うことで例えばＳｔｒｉｎｇ型データとしてプログラム間でＡＳＣＩＩ文字コードしか扱えないような環境であったとしても、Ｂｉｎａｒｙ型データをやりとりすることができる。

要は次世代アプリ４０１とポートモニタ用拡張ファイル４１２であらかじめ決められた方式で変換を行えばよく、別アルゴリズムでも変換可能であることはいうまでもない。

また、このＢｉｎａｒｙ型とＳｔｒｉｎｇ型のデータ相互変換はメンテナンス制御コマンドにのみあてはまる変換ではなく、すべてのデータに対して有効である。

次に図９および図１０として、次世代アプリ４０１の変形例を示す。

図９は、次世代アプリ４０１起動時にメイン画面を表示するまでの処理を示したフローチャートである。

Ｓ９０１では、次世代アプリ４０１起動時に使用可能なドライバが次世代ドライバ４１０か、レガシードライバ２１０かを判断する。判断方法としては、例えばプリンタドライバ名称を決められたルールで分けておいても判断可能であるし、プリンタドライバの構造を判別するＯＳのＡＰＩを利用できる環境であればそれを利用する。使用するドライバが次世代ドライバ４０１であれば、Ｓ９０２に進み、レガシードライバ２１０の場合は、Ｓ９０５に進む。

Ｓ９０２では、次世代ドライバ４１０が接続されているポートを判別し、ポートモニタ用拡張ファイル４１２を有するポートかを判断する。印刷装置４０７と接続しているポートがポートモニタ用拡張ファイル４１２を有するポートであればＳ９０３に進み、ポートモニタ用拡張ファイル４１２非対応のポートであればＳ９０５に進む。

Ｓ９０３では、印刷装置４０７への情報送信が可能なタイミングかどうかを判断する。これは例えば印刷中の状態で双方向通信の情報送信を試みることにより判断する。そして、すでに印刷中の状態で双方向通信の情報送信を試みた際にポートモニタ側での排他制御ができない場合には、印刷に影響を与えてしまうため、実行不可能なタイミングとして判断する。情報送信実行可能なタイミングであればＳ９０４に進み、実行不可能なタイミングであれば、Ｓ９０５に進む。

Ｓ９０４では、メンテナンス制御コマンドを印刷装置に送信可能な為、次世代アプリ４０１のメイン画面に図１０に示す１００１のようにメンテナンス機能ボタンを表示する。

Ｓ９０５ではメンテナンス制御コマンドを印刷装置に送信できない環境であり、図１０に示す１００５の通りメンテナンス機能ボタンを非表示とし、実行可能な機能ボタンのみ表示する。この場合は、プリンタマニュアル表示ボタンのみが表示されることとなる。

あるいは、常に図１０の１００１のようにプリンタメンテナンスＡ１００３、プリンタメンテナンスＢ１００４を表示しておき、ユーザーがボタンを実行した時にＳ５０１の処理の前に、Ｓ９０１、Ｓ９０２、Ｓ９０３の判断を行う構成としてもよい。このように構成した場合、メンテナンス制御コマンドを印刷装置に送信不可能な状態の際には、図１０の１００７のように機能の実行できないことや、その理由や、回避策等をＧＵＩ上に表示する。

以上の形態により、図４に示す環境下であっても次世代アプリから適切に印刷装置に対しメンテナンス機能の実行指示を行うことが可能となった。

また本明細書ではポートモニタ用拡張ファイルが、ユーザーが自由に閲覧することができるテキストファイルの形式で保存されている。よって、ポートモニタ用拡張ファイル４１２がメンテナンス制御コマンドを保持しなくてもメンテナンス機能を実行できるようになる。これにより、メンテナンス制御コマンドをテキストファイルに記載しなくて済み、メンテナンス制御コマンドの機密性が向上する。

また別の効果として、次世代ドライバ４１０がＯＳに予め組み込む形態のプリンタドライバで、かつ将来の印刷装置４０７でも利用可能な汎用ドライバ形態であった場合、予めポートモニタ用拡張ファイル４１２内にメンテナンス制御コマンドを持つ形態だと、将来の印刷装置４０７用のメンテナンス機能の拡張に対応できないという問題を回避することが可能になった。

＜実施形態２＞
次に実施形態２として、図１１〜図１３を使用して、画像ファイルの表示が可能な次世代アプリ４０２と、次世代ドライバ４１０のポートモニタ用拡張ファイル４１２を使用して、印刷装置４０７に画像ファイルを送信する印刷制御方法について説明する。

図１１は画像ファイルを表示する次世代アプリ４０２の画面構成例である
次世代アプリ起動時に表示されるメイン画面が１１０１および１１０４である。

情報処理装置１１０内に格納されているＪＰＥＧやＴＩＦＦ，ＢＭＰ等各種画像ファイルフォーマットで作成された画像ファイルを開き、メイン画面の中央部の画像表示領域（１１０２および１１０５）に表示を行うことが可能である。

また、メイン画面（１１０１および１１０４）上部の表示領域（１１０３および１１０６）は図に示すように表示している画像ファイルのファイル名称を表示することが可能である。

また、メイン画面（１１０１および１１０４）下部の表示領域には、印刷実行ボタン（１１０７）を表示することが可能であり、印刷実行ボタンが押下された際には、次世代ドライバ４１０のポートモニタ用拡張ファイル４１２を使用して、印刷装置４０７に画像ファイルを直接送信することが特徴である。

通常のアプリケーションが印刷処理を実行する際には、次世代ドライバ４１０のグラフィックスドライバ４１１を使用して、画像データをデバイス解像度に併せてレンダリング処理を行い、得られたＲＧＢ画像ファイルに対して色処理、量子化処理、プリンタ制御コマンドへの変換処理を行い、得られた印刷コマンドを印刷装置４０７に送信することが一般的である。

また、画像ファイルを直接受け取って印刷処理することが可能な印刷装置４０７の場合、レンダリング処理後の画像ファイルを次世代ドライバ４１０のグラフィックスドライバ４１１が、印刷装置４０７が処理可能な画像ファイルフォーマットに変換する。その後、変換した画像ファイルを印刷装置４０７に送信し、印刷装置４０７内部で画像ファイルを直接処理して印刷する方法も一般的である。

しかし、前述した２つの印刷処理は、データ変換処理回数も増え、処理負荷も高くなる為、非力なＣＰＵ１１２を使用する情報処理装置１１０では処理時間が遅くなる懸念がある。また、印刷装置４１０の対応解像度にレンダリング処理を行うことが一般的である為、情報処理装置１１０のＲＡＭ１１６の使用量が増大するという懸念もある。

図１１に示した次世代アプリ４０２と次世代ドライバ４１０とポートモニタ用拡張ファイル４１２を使用して情報処理装置１１０の処理負荷および使用メモリ量を削減した印刷制御方法について図１２を用いて説明する。

図１２は、次世代アプリ４０２が画像ファイルを印刷装置４０７に送信する処理の流れを示したフローチャートである。

次世代アプリ４０２は、印刷ボタン１１０７が押下されるとＳ１２０１を処理する。

Ｓ１２０１では、双方向通信を行う際のスキーマに直接送信モードを示す情報をセットし、Ｓ１２０２に進む。

Ｓ１２０２では、印刷装置４０７が直接画像ファイルを受けっとって印刷する為の制御情報を、送信する画像ファイルに付加し、Ｓ１２０３に進む。制御情報とは印刷装置４０７が画像ファイルを直接印刷する処理を行うための情報である。

Ｓ１２０３では、送信する画像ファイルのサイズを確認し、一度に送信可能な範囲のサイズに分割し、Ｓ１２０４に進む。

このように画像ファイルを分割することでＢｉｄｉ Ｐｒｉｎｔｅｒ ｃｏｍｍｕｎｉｃａｔｉｏｎを用いてやりとりするパラメータ内のデータのサイズ、又は印刷装置４０７が一度に受け取ることができるデータのサイズに上限があったとしても画像ファイルを送信することが可能である。

Ｓ１２０４では、分割された画像ファイルのデータをＳｔｒｉｎｇ型に変換した後、パラメータ内のスキーマにセットする。

Ｓ１２０５では、次世代アプリ４０１が情報送信関数をコールする。次世代アプリ４０１が情報送信関数をコールすると、図６に示すポートモニタ用拡張ファイル４１２の処理フローを実行する。パラメータには直接送信モードが指定されている為、ポートモニタ用拡張ファイル４１２はＳｔｒｉｎｇ型データをＢｉｎａｒｙ型データに変換後、ポートモニタがデータを印刷装置４０７に送信する。

Ｓ１２０６では、画像ファイルの全データ送信が完了したかを判断し、すべてのデータ送信が完了したら、処理を終了する。またすべてのデータ送信が完了していない場合は、Ｓ１２０４からＳ１２０６を繰り返し実行する。
印刷装置４０７は、受信した画像ファイルを処理し、印刷を行う。

図１３は、次世代アプリ４０１起動時に印刷ボタン１１０７を表示するまでの処理の流れを示す。

これは前述した次世代アプリ４０１の印刷機能は、次世代ドライバ４１０のポートモニタ用拡張ファイル４１２を使用することが前提である為、ユーザーが印刷機能を実行可能な時のみ印刷ボタン１１０７を表示することが望まれる。

Ｓ１３０１はＳ９０１と、Ｓ１３０２はＳ９０２と、Ｓ１３０４とＳ９０３はそれぞれ同様であるため、説明を省略する。

Ｓ１３０４では、現在表示している画像ファイルの画像フォーマットが、印刷装置４０７が直接受け取って印刷可能なフォーマットであるかどうか判断する。印刷装置４０７が直接受け取って印刷可能な画像フォーマットであればＳ１３０５へ進み、印刷不可能な画像フォーマットの時はＳ１３０６に進む。

Ｓ１３０４の印刷可能なフォーマットであるかを判断する方法としては次の通りである。印刷装置４０７が印刷可能な拡張子の一覧を次世代アプリ４０１が外部記憶装置１１５に保存しておき、次世代アプリ４０１が画像ファイルのフォーマットがその一覧に含まれているか否かを判断する。あるいは次世代アプリ４０１が印刷装置４０７に印刷装置４０７が印刷可能な拡張子の一覧を問い合わせても良い。

Ｓ１３０５では、画像フォーマットを印刷装置に直接送信可能な状態の為、次世代アプリ４０１のメイン画面に図１１に示す１１０７の印刷ボタンを表示する。

Ｓ１３０６ではメ画像フォーマットを印刷装置に直接送信不可能な状態の為、図１１に示す１１０１の通り印刷ボタンを非表示とする。

以上、実施例２で示してきた通り、次世代アプリ４０２と次世代ドライバ４１０とポートモニタ用拡張ファイル４１２を使用して画像データを直接印刷装置４０７に送信し、印刷処理を行うことが可能になる。

さらに印刷装置４０７が対応していないフォーマットの画像ファイルを情報処理装置１１０が送信せずに済む。

＜他の実施形態＞
上記実施形態では、アプリケーションの一例としてメンテナンス機能実行や、画像ファイルの直接送信を例に説明したが、この例に限られることはない。

例えば本実施形態が動作する環境であれば、印刷装置に直接データを送信したいと考える任意のアプリケーションで実現可能であり、本発明はその場合でも有効である。

又、上記実施形態では、情報処理装置としてパーソナルコンピュータを想定したが、この例に限られることはない。例えば携帯電話、ＤＶＤビデオプレーヤー、ゲーム、セットトップボックス、インターネット家電等、同様な使用方法が可能な任意の端末に対して実現することができ、本発明はその場合でも有効である。

又、上記実施形態では、印刷装置としてプリンタを例示しているが、印刷装置として他に、複写機、ファクシミリ、および印刷、スキャナ、ファックスの機能などを備える複合機などのいずれかが、本発明の適用対象となり得る。

又、上記実施形態では、ＰＣと印刷装置の間のインタフェースとして、ＵＳＢインタフェースを用いたが、このインタフェースに限られない。これは次世代ドライバが印刷装置と双方向通信を行う際に、ポートモニタ用拡張ファイルが使用可能で、同様の実施形態が可能となる全てのポートに対して有効になる。

本発明の目的は前述した実施例の機能を実現するソフトウエアのプログラムコードを記録した記録媒体を、システムあるいは装置に供給し、そのシステムあるいは装置のコンピュータまたはＣＰＵまたはＭＰＵ）が記録媒体に格納されたプログラムコードを読み出し実行することによっても、達成されることは言うまでもない。

この場合、記憶媒体から読み出されたプログラムコード自体が前述した実施形態の機能を実現することとなり、そのプログラムコードを記憶した記憶媒体は本発明を構成することになる。

プログラムコードを供給するための記憶媒体としては、例えば、フレキシブルディスク、ハードディスク、ＳＳＤ、光ディスク、光磁気ディスク、ＣＤ−ＲＯＭ、ＣＤ−Ｒ、磁気テープ、不揮発性のメモリカード、ＲＯＭ、ＤＶＤなどを用いることができる。

また、コンピュータが読み出したプログラムコードを実行することにより、前述した実施例の機能が実現されるだけでなく、そのプログラムコードの指示に基づき、コンピュータ上で稼動しているＯＳなどが実際の処理の一部または全部を行い、その処理によって前述した実施例の機能が実現される場合も含まれることは言うまでもない。

さらに、記憶媒体から読み出されたプログラムコードが、コンピュータに挿入された機能拡張ボードやコンピュータに接続された機能拡張ユニットに備わるメモリに書きこまれた後、そのプログラムコードの指示に基づき、その機能拡張ボードや機能拡張ユニットに備わるＣＰＵなどが実際の処理の一部または全部を行い、その処理によって前述した実施形態の機能が実現される場合も含まれることは言うまでもない。

Claims (11)

1. コンピュータを、
   ユーザーが実行を指示する機能が第１の機能である場合はストリング型の領域外のデータを含むバイナリデータを前記ストリング型のデータに変換して第１のパラメータにセットして前記第１のパラメータを送り、ユーザーが実行を指示する機能が前記第１の機能とは異なる第２の機能である場合は前記第１のパラメータとは異なり前記第２の機能に対応する第２のパラメータを送るアプリケーション手段と、
   前記アプリケーション手段が送るパラメータが前記第１のパラメータである場合は前記第１のパラメータに含まれる前記ストリング型の前記データを前記バイナリデータに変換して印刷装置に前記バイナリデータを送信することを指示して、前記アプリケーション手段が送るパラメータが前記第２のパラメータである場合は前記第２のパラメータに対応する前記データを前記印刷装置に送信することを指示する送信手段として機能させることを特徴とするプログラム。
2. 前記第１の機能は印刷装置の機種ごとに異なるメンテナンス制御コマンドを印刷装置に送信指示するための機能であり、前記第２の機能は印刷装置の複数機種で共通のメンテナンス制御コマンドを印刷装置に送信指示するための機能であり、前記バイナリデータ及び前記第２のパラメータに対応する前記データはメンテナンス制御コマンドであることを特徴とする請求項１に記載のプログラム。
3. コンピュータを、
   アプリケーション起動時に、前記印刷装置に対応するポートがポートモニタ用拡張ファイルを有するポートである場合に前記第１の機能及び前記第２の機能を実行するためのボタンを表示して、前記印刷装置に対応するポートがポートモニタ用拡張ファイルを有さないポートである場合に前記第１の機能及び前記第２の機能を実行するためのボタンを表示しない制御をする制御手段として機能させることを特徴とする請求項１または２に記載のプログラム。
4. 前記バイナリデータは画像ファイルであり、前記画像ファイルに基づいて前記印刷装置が印刷することを特徴とする請求項１乃至３のいずれか１項に記載のプログラム。
5. コンピュータを、
   前記印刷装置に対応するポートがポートモニタ用拡張ファイルを有するポートである場合に前記画像ファイルの印刷指示をユーザーから受け付けるボタンを表示する表示手段として機能させることを特徴とする請求項１乃至４のいずれか１項に記載のプログラム。
6. ユーザーが実行を指示する機能が第１の機能である場合はストリング型の領域外のデータを含むバイナリデータを前記ストリング型のデータに変換して第１のパラメータにセットして前記第１のパラメータを送り、ユーザーが実行を指示する機能が前記第１の機能とは異なる第２の機能である場合は前記第１のパラメータとは異なり前記第２の機能に対応する第２のパラメータを送るアプリケーション手段と、
   前記アプリケーション手段が送るパラメータが前記第１のパラメータである場合は前記第１のパラメータに含まれる前記ストリング型の前記データを前記バイナリデータに変換して印刷装置に前記バイナリデータを送信することを指示して、前記アプリケーション手段が送るパラメータが前記第２のパラメータである場合は前記第２のパラメータに対応する前記データを前記印刷装置に送信することを指示する送信手段と、を有することを特徴とする情報処理装置。
7. 前記第１の機能は印刷装置の機種ごとに異なるメンテナンス制御コマンドを印刷装置に送信指示するための機能であり、前記第２の機能は印刷装置の複数機種で共通のメンテナンス制御コマンドを印刷装置に送信指示するための機能であり、前記バイナリデータ及び前記第２のパラメータに対応する前記データはメンテナンス制御コマンドであることを特徴とする請求項６に記載の情報処理装置。
8. アプリケーション起動時に、前記印刷装置に対応するポートがポートモニタ用拡張ファイルを有するポートである場合に前記第１の機能及び前記第２の機能を実行するためのボタンを表示して、前記印刷装置に対応するポートがポートモニタ用拡張ファイルを有さないポートである場合に前記第１の機能及び前記第２の機能を実行するためのボタンを表示しない制御をする制御手段を有することを特徴とする請求項６または７に記載の情報処理装置。
9. 前記バイナリデータは画像ファイルであり、前記画像ファイルに基づいて前記印刷装置が印刷することを特徴とする請求項６乃至８のいずれか１項に記載の情報処理装置。
10. 前記印刷装置に対応するポートがポートモニタ用拡張ファイルを有するポートである場合に前記画像ファイルの印刷指示をユーザーから受け付けるボタンを表示する表示手段を有することを特徴とする請求項６乃至９のいずれか１項に記載の情報処理装置。
11. 情報処理装置において実行される制御方法であって、
    ユーザーが実行を指示する機能が第１の機能である場合はストリング型の領域外のデータを含むバイナリデータを前記ストリング型のデータに変換して第１のパラメータにセットして前記第１のパラメータを送り、ユーザーが実行を指示する機能が前記第１の機能とは異なる第２の機能である場合は前記第１のパラメータとは異なり前記第２の機能に対応する第２のパラメータを送るアプリケーション工程と、
    前記アプリケーション工程が送るパラメータが前記第１のパラメータである場合は前記第１のパラメータに含まれる前記ストリング型の前記データを前記バイナリデータに変換して印刷装置に前記バイナリデータを送信することを指示して、前記アプリケーション工程が送るパラメータが前記第２のパラメータである場合は前記第２のパラメータに対応する前記データを前記印刷装置に送信することを指示する送信工程と、を有することを特徴とする制御方法。

Images