画像形成装置
【課題】 画像形成装置において、アプリケーションと複数種の通信プロトコルデーモンとの間でのデータの授受に関するプログラム部分の開発に時間とコストがかかっていた。
【解決手段】 本発明の画像形成装置は、アプリケーションと通信プロトコルデーモンとの間に統一したインタフェースを持たせたインタフェースライブラリ群からなる統一インタフェース層を備えることにより、アプリケーションは前記統一インタフェースに従って開発を行えばよく、開発の時間及びコストを削減可能となった。さらに、ＳＮＭＰなどの小サイズかつ多数回の通信が行われるプロトコルについての統一インタフェース層でのオーバヘッドによる遅延をなくすために、通信プロトコルを判断してＳＮＭＰなどの通信では、統一インタフェース層を介さない直接通信を行う方式とした。
【解決手段】 本発明の画像形成装置は、アプリケーションと通信プロトコルデーモンとの間に統一したインタフェースを持たせたインタフェースライブラリ群からなる統一インタフェース層を備えることにより、アプリケーションは前記統一インタフェースに従って開発を行えばよく、開発の時間及びコストを削減可能となった。さらに、ＳＮＭＰなどの小サイズかつ多数回の通信が行われるプロトコルについての統一インタフェース層でのオーバヘッドによる遅延をなくすために、通信プロトコルを判断してＳＮＭＰなどの通信では、統一インタフェース層を介さない直接通信を行う方式とした。
【発明の詳細な説明】
【技術分野】
【０００１】
画像形成装置において、アプリケーションの開発コスト低減のために通信プロトコルデーモンとの間に統一インタフェースを提供することに関し、さらに仲介インタフェース層のオーバヘッドによる遅延を回避する技術に関するものである。
【背景技術】
【０００２】
画像形成装置では、外部装置との間で通信を行ってデータのやり取りを行う。その際の通信には、種々のプロトコルがある。例えば、インターネットでのブラウザ・サーバ間のデータのやりとりに使われるＨＴＴＰ（HyperText Transfer Protocol）や、ネットワークに接続された通信機器を監視・制御するためのＳＮＭＰ（Simple Network Management Protocol）や、パラレルインタフェースを用いてのセントロニクス仕様に基づくプロトコルや、ＵＳＢインタフェースを用いてのＵＳＢ規格に基づくプロトコル等がある。
【０００３】
画像形成装置では、これらの各プロトコルの通信を受け持つ通信プロトコルデーモンを有し、画像形成装置の画像処理を行う種々のアプリケーションとの間でデータの授受を行い外部装置とのデータ通信を行う。
【０００４】
この前記複数のアプリケーションと前記複数の通信プロトコルデーモンとの通信を受け持つインタフェースプログラム部をそれぞれに作成すると開発に時間がかかり、高コスト化を招き又バグの発生の可能性やバグの見落としの可能性が高かった。
【０００５】
そこで、従来技術として通信プロトコルデーモンからの接続通知に応じて、該接続通知をアプリケーションに仲介する仲介アプリケーションを備える方法がある（特許文献１参照）。
【０００６】
しかし、この方法では、仲介アプリケーションが受け持つのは、前記した接続通知に関する部分だけであり、接続通知要求後のデータ通信は通信プロトコルデーモンとアプリケーションの間で直接行うため、依然としてこれらの通信部分のインタフェースをそれぞれのアプリケーション及びプロトコル毎に開発する必要があった。
【特許文献１】特開２００４−１４２５号公報
【発明の開示】
【発明が解決しようとする課題】
【０００７】
解決しようとする問題点は、画像形成装置において、画像形成処理を行うアプリケーションと外部装置の通信を受け持つ通信プロトコルデーモンとの間の通信インタフェースを統一して、通信に関するプログラムの開発コストを下げると共に、統一インタフェースによるパフォーマンスの低下を抑制する点である。
【課題を解決するための手段】
【０００８】
本発明の画像形成装置は、画像形成に関する処理を行うアプリケーションと、複数種の通信プロトコルに従って通信を行う複数種の通信プロトコルデーモンと、を備えて外部装置との間で通信を行う画像形成装置であって、前記アプリケーションと前記プロトコルデーモンとの間でデータの授受を統一したインタフェースにより行う統一インタフェース層を有し、前記アプリケーションは、前記統一インタフェース層とのデータ授受のための統一アプリケーションインタフェースを備え、前記通信プロトコルデーモンは、前記統一インタフェース層とのデータ授受のための統一デーモンインタフェースを備えることを最も主要な特徴とする。
【０００９】
さらに、本発明の画像形成装置は前記画像形成装置であって、前記アプリケーションは、通信が所定のプロトコルであるかどうかを判断するプロトコル判断部と、前記プロトコル判断部で所定のプロトコルと判断された場合には、該プロトコルの通信を受け持つ前記通信プロトコルデーモンとの直接のデータ授受を行う特定プロトコル直接アプリケーションインタフェース部と、を有し、前記所定のプロトコルを受け持つ前記通信プロトコルデーモンは、前記特定プロトコル直接アプリケーションインタフェース部との間でデータの授受を行う特定プロトコル直接デーモンインタフェース部を有することを特徴とする。
【発明の効果】
【００１０】
本発明の画像形成装置は、画像形成に関する処理を行うアプリケーションと、複数種の通信プロトコルに従って通信を行う複数種の通信プロトコルデーモンと、を備えて外部装置との間で通信を行う画像形成装置であって、前記アプリケーションと前記通信プロトコルデーモンとの間でデータの授受を統一したインタフェースにより行う統一インタフェース層を有し、前記アプリケーションは、前記統一インタフェース層とのデータ授受のための統一アプリケーションインタフェースを備え、前記通信プロトコルデーモンは、前記統一インタフェース層とのデータ授受のための統一デーモンインタフェースを備えることを最も主要な特徴とするため、アプリケーションの開発の際には、統一インタフェース層で規定してあるインタフェースに従って、アプリケーションの設計・開発を行うことが可能であり、開発時間の短期化及び開発コストの低下が実現した。
【００１１】
さらに、本発明の画像形成装置は前記画像形成装置であって、前記アプリケーションは、通信が所定のプロトコルであるかどうかを判断するプロトコル判断部と、前記プロトコル判断部で所定のプロトコルと判断された場合には、該プロトコルの通信を受け持つ前記通信プロトコルデーモンとの直接のデータ授受を行う特定プロトコル直接アプリケーションインタフェース部と、を有し、前記所定のプロトコルを受け持つ前記通信プロトコルデーモンは、前記特定プロトコル直接アプリケーションインタフェース部との間でデータの授受を行う特定プロトコル直接デーモンインタフェース部を有することを特徴とするため、ＳＮＭＰ通信におけるような、小サイズでかつ多数回の通信が行われて、統一インタフェース層のオーバヘッドによる遅延が問題となるような場合には、アプリケーションと通信プロトコルデーモンとの直接の通信を行うため遅延の問題が無くなった。これにより、開発の短期化と性能のバランスがとれたアプリケーションの開発が可能となった。
【発明を実施するための最良の形態】
【００１２】
画像形成装置において、アプリケーションと通信プロトコルデーモンとの通信部分の開発に時間がかかるという問題について、統一インタフェース層を前記アプリケーションと前記通信プロトコルデーモンとの間に介在させることにより解決した。また、ＳＮＭＰなどの小サイズ・多数回の通信が行われるプロトコルにおける統一インタフェース層でのオーバヘッドによる遅延の問題については、アプリケーションがプロトコルを判断して、その判断結果に基づき通信プロトコルデーモンとの直接の通信を行うことにより問題点を解決した。
【実施例１】
【００１３】
［構成］
図１は、本発明の実施例に係わる画像形成装置１０１の機能ブロック図である。
【００１４】
画像形成装置１０１は、大きくハードウェア群１５０、ソフトウェア群１２０、ハードウェアインタフェース群１６０に分かれる。
【００１５】
ハードウェア群１５０は、印刷エンジン１５１、スキャナ１５３、記憶・制御部１５７と、を有する。
【００１６】
ソフトウェア群１２０は、機能毎のアプリケーションである、印刷アプリケーション１１１、複写アプリケーション１１３、ファクスアプリケーション１１５、スキャナアプリケーション１１７、転送アプリケーション１１９を有し、通信プロトコルデーモンである、ＵＳＢ（Universal Serial Bus）デーモン１３１、セントロニクスデーモン１３２、公衆回線網デーモン１３３、ＦＴＰ（File Transfer Protocol）デーモン１３４、ＨＴＴＰ（HyperText Transfer Protocol）デーモン１３５、ＳＮＭＰ（Simple Network Management Protocol）デーモン１３６を有し、前記アプリケーション（１１１〜１１９）と前記通信プロトコルデーモン（１３１〜１３６）との間に介在する統一インタフェース層１２１を有する。
【００１７】
ハードウェアインタフェース群１６０は、ＵＳＢインタフェース１６１、セントロニクスインタフェース１６２、公衆回線網インタフェース１６３、ネットワークインタフェース１６５を有する。
【００１８】
また、画像形成装置は、外部装置である、ホストＰＣ１；２０１、ホストＰＣ２；２０２、ホストＰＣ３；２０３、ＦＡＸ３０１、サーバ４０１、画像形成装置２；５０１と図１に示すようにハードウェアインタフェース群１６０の各種インタフェースを通して接続している。
【００１９】
以下に各機能部について説明する。
【００２０】
印刷エンジン１５１は、印刷を行うハードウェア機能部である。
【００２１】
スキャナ１５３は、原稿の画像を読み取るハードウェア機能部である。
【００２２】
記憶・制御部１５７は、半導体メモリ及び磁気回転ディスク装置からなる記憶装置と、ＣＰＵ及び周辺制御回路からなる制御装置と、を有し、画像形成装置全体の制御を司る機能部である。
【００２３】
印刷アプリケーション１１１は、画像形成装置の印刷の画像形成に関する処理の機能を画像形成装置のコンピュータに実行させるプログラム機能部である。
【００２４】
複写アプリケーション１１３は、画像形成装置の複写の画像形成に関する処理の機能を画像形成装置のコンピュータに実行させるプログラム機能部である。
【００２５】
ファクスアプリケーション１１５は、画像形成装置のファクスの画像形成に関する処理の機能を画像形成装置のコンピュータに実行させるプログラム機能部である。
【００２６】
スキャナアプリケーション１１７は、画像形成装置のスキャナ１５３での画像形成に関する処理の機能を画像形成装置のコンピュータに実行させるプログラム機能部である。
【００２７】
転送アプリケーション１１９は、画像形成装置のファイル転送の画像形成に関する処理の機能を画像形成装置のコンピュータに実行させるプログラム機能部である。
【００２８】
上記の各アプリケーションは、統一インタフェース層１２１（後述）との間でのデータの授受に関するインタフェース部であるアプリケーションインタフェース部（１１１ｉ、１１３ｉ、１１５ｉ、１１７ｉ、１１９ｉ）を有する。
【００２９】
次に複数種ある通信プロトコルデーモンについて説明する。
【００３０】
ＵＳＢデーモン１３１は、ＵＳＢ規格での通信のデータ授受を受け持つデーモンである。
【００３１】
セントロニクスデーモン１３２は、セントロニクス仕様のパラレルインタフェースでの通信のデータ授受を受け持つデーモンである。
【００３２】
公衆回線網デーモン１３３は、公衆回線網を通しての通信のデータ授受を受け持つデーモンである。
【００３３】
ＦＴＰデーモン１３４は、File Transfer Protocolを用いての通信のデータ授受を受け持つデーモンである。
【００３４】
ＨＴＴＰデーモン１３５は、HyperText Transfer Protocolを用いての通信のデータ授受を受け持つデーモンである。
【００３５】
ＳＮＭＰデーモン１３６は、Simple Network Management Protocolを用いての通信のデータ授受を受け持つデーモンである。
【００３６】
上記の通信プロトコルデーモンは、統一インタフェース層１２１（後述）との間でのデータの授受に関する統一デーモンインタフェースであるデーモンインタフェース部（１３１ｉ、１３２ｉ、１３３ｉ、１３４ｉ、１３５ｉ、１３６ｉ）を有する。
【００３７】
統一インタフェース層１２１は、前記アプリケーション（１１１，１１３，１１５，１１７，１１９）と通信デーモンプロトコル（１３１、１３２，１３３，１３４，１３５，１３６）との間に介在するプログラムである。統一インタフェース層は、独立したプロセスを実行するアプリケーションプログラムではなく、必要時に他プログラム（通信プロトコルデーモン）から起動されるライブラリプログラムの集合である。統一インタフェース層１２１には、アプリケーションとの間の統一したインタフェースを提供するアプリケーション統一インタフェースライブラリ群１２１ａｌと通信プロトコルデーモンとの間のインタフェースを提供する通信プロトコルデーモンインタフェースライブラリ群１２３ｄｌと、を有する。統一インタフェース層１２１のより詳細な構造については、インタフェースの説明の項で後述する。
【００３８】
次にハードウェアインタフェース群１６０の各インタフェースについて説明する。
【００３９】
ＵＳＢインタフェース１６１は、ＵＳＢ規格のインタフェースのハードウェアであり、例えば図１に示すようにホストＰＣ１；２０１と接続してホストＰＣ１；２０１から印刷データを受信する。
【００４０】
セントロニクスインタフェース１６２は、セントロニクス仕様のインタフェースのハードウェアであり、例えば図１に示すようにホストＰＣ２；２０２と接続してホストＰＣ２；２０２から印刷データを受信する。
【００４１】
公衆回線網インタフェース１６３は、電話回線での通信接続のためのインタフェースであり、公衆回線を通して他のＦＡＸ装置３０１と接続している。
【００４２】
ネットワークインタフェース１６５は、ネットワークのインタフェースであり、例えば図１に示すように、ネットワークを通してホストＰＣ３；２０３やサーバ４０１や画像形成装置２；５０１と接続している。
【００４３】
［統一インタフェース層及びアプリケーションインタフェース部］
図２を用いて統一インタフェース層１２１とアプリケーションとのインタフェースについて、その詳細を説明する。
【００４４】
図２は、アプリケーションの一例としての印刷アプリケーション１１１と統一インタフェース層とのさらに詳細な構造を示したものである。印刷アプリケーション１１１以外の他のアプリケーションでもその構造は同様である。
【００４５】
印刷アプリケーション１１１のアプリケーションインタフェース部１１１ｉには、以下の１０個のインタフェースが備わっている。
【００４６】
印刷アプリケーション側が発呼の通信の開始のインタフェースＯｐｅｎ（）１１１ｏ、同（印刷アプリケーション側が発呼の；以下省略）通信の終了のインタフェースＣｌｏｓｅ（）１１１ｃ、同データの読取Ｒｅａｄ（）１１１ｒ、同データの書込Ｗｒｉｔｅ（）１１１ｗ、同通信状態の把握ＣｈｅｃｋＳｔａｔｕｓ（）１１１ｓの５個のインタフェースと、統一インタフェース層１２１側からの発呼に応答する印刷アプリケーションにとっては受信側の通信の開始のインタフェースＲＯｐｅｎ（）１１１ｒｏ、同（統一インタフェース層１２１側からの発呼に応答する印刷アプリケーションにとっては受信側の；以下省略）通信の終了のインタフェースＲＣｌｏｓｅ（）１１１ｒｃ、同データの読取ＲＲｅａｄ（）１１１ｒｒ、同データの書込ＲＷｒｉｔｅ（）１１１ｒｗ、同通信状態の把握ＲＣｈｅｃｋＳｔａｔｕｓ（）１１１ｒｓの５個のインタフェースとの１０個のインタフェースを有する。
【００４７】
統一インタフェース層１２１は、前記１０個のインタフェースに呼応する１０個のインタフェースであるアプリ統一インタフェースライブラリ群１２１ａｌ（プログラムライブラリの集合）と、通信プロトコルデーモン（１３１〜１３６）から呼び出される通信プロトコルデーモンインタフェースライブラリ群１２３ｄｌ（プログラムライブラリの集合）と、から構成される。
【００４８】
アプリ統一インタフェースライブラリ群１２１ａｌは、通信プロトコルデーモン（１３１〜１３６）側が発呼の通信の開始のインタフェースＯｐｅｎ＿ＬＩＢ（）１２１ｏ、同（通信プロトコルデーモン側が発呼の；以下省略）通信の終了のインタフェースＣｌｏｓｅ＿ＬＩＢ（）１２１ｃ、同データの読取Ｒｅａｄ＿ＬＩＢ（）１２１ｒ、同データの書込Ｗｒｉｔｅ＿ＬＩＢ（）１２１ｗ、同通信状態の把握ＣｈｅｃｋＳｔａｔｕｓ＿ＬＩＢ（）１２１ｓの５個のインタフェースと、アプリケーション（１１１〜１１９）側からの発呼に応答する通信プロトコルデーモン（１３１〜１３６）にとっては受信側の通信の開始のインタフェースＲＯｐｅｎ＿ＬＩＢ（）１２１ｒｏ、同（アプリケーション（１１１〜１１９）側からの発呼に応答する通信プロトコルデーモン（１３１〜１３６）にとっては受信側の；以下省略）通信の終了のインタフェースＲＣｌｏｓｅ＿ＬＩＢ（）１２１ｒｃ、同データの読取ＲＲｅａｄ＿ＬＩＢ（）１２１ｒｒ、同データの書込ＲＷｒｉｔｅ＿ＬＩＢ（）１２１ｒｗ、同通信状態の把握ＲＣｈｅｃｋＳｔａｔｕｓ＿ＬＩＢ（）１２１ｒｓの５個のインタフェースとの１０個のインタフェースを有する。
【００４９】
さらに、通信プロトコルデーモンインタフェースライブラリ群１２３ｄｌは、ＵＳＢデーモン１３１から呼び出されるＵＳＢデーモン対応ライブラリ群１２３ｕ、セントロニクスデーモン１３２から呼び出されるセントロニクスデーモン対応ライブラリ群１２３ｃ、公衆回線網デーモン１３３から呼び出される公衆回線網デーモンライブラリ群１２３ｋ、ＦＴＰデーモン１３４から呼び出されるＦＴＰデーモン対応ライブラリ群１２３ｆ、ＨＴＴＰデーモン１３５から呼び出されるＨＴＴＰデーモン対応ライブラリ群１２３ｈ、ＳＮＭＰデーモン１３６から呼び出されるＳＮＭＰデーモン対応ライブラリ群１２３ｓとからなる。
【００５０】
［シーケンス］
図３のシーケンス図を用いて実際の通信におけるアプリケーションインタフェース部と統一インタフェース層１２１の役割について説明する。本説明においては一例として、アプリケーションは印刷アプリケーション１１１を用いて、ＨＴＴＰ通信についてＨＴＴＰデーモンとの間でのデータ授受を行う場合について説明を行う。他のアプリケーション及び他の通信プロトコルデーモンでもアプリケーションインタフェース部と統一インタフェース層１２１の役割は同様である。
【００５１】
図３（Ａ）は、画像形成装置１０１が、外部のＨＴＴＰサーバ（例えばサーバ４０１）に対して通信を開始する際のシーケンスについて説明した図である。
【００５２】
Ｓ１：ユーザによるＨＴＴＰのデータ取得要求が発生すると印刷アプリケーション１１１は、アプリケーションインタフェース部１１１ｉの通信開始のインタフェースＯｐｅｎ（）１１１ｏをコールする。
【００５３】
Ｏｐｅｎ（）１１１ｏのコールの際には、各パラメータがセットされる。
【００５４】
プロトコルを示すＰＲＯＴＯＣＯＬには、ＨＴＴＰを指定する。
【００５５】
ｂｕｆｆｅｒでやり取りを行うデータ構造を示すＤａｔａＳｔｒｕｃｔｕｒｅには、定義済みのＨＴＴＰ用のデータ構造であるＨＴＴＰｄｓを指定する。
【００５６】
データを格納するｂｕｆｆｅｒのポインタには、ｂｕｆｆｅｒを指定する。
【００５７】
戻り値を格納するＳｔａｔｕｓには、Ｓｔａｔｕｓを指定する。
【００５８】
上記ＨＴＴＰは、ＨＴＴＰ通信を表す定数である。
【００５９】
ＨＴＴＰｄｓは、定義済みのＨＴＴＰのデータ交換のためのデータ構造。
【００６０】
ｂｕｆｆｅｒとＳｔａｔｕｓは確保されたデータ領域である。
【００６１】
Ｓ２：印刷アプリケーションからコールされたＯｐｅｎ（）１１１ｏを受けて、統一インタフェース層中の通信の開始の受信側インタフェースであるＲＯｐｅｎ＿ＬＩＢ１１１ｒｏが前記定義された各パラメータを受け取る。
【００６２】
Ｓ３：ＨＴＴＰデーモン対応ライブラリ群１２３ｕ中のライブラリが前記ＲＯｐｅｎ＿ＬＩＢ（）１２１ｒｏを受けてＨＴＴＰデーモン１３５のインタフェースに変換する。
【００６３】
Ｓ４：前記Ｓ３で受けたインタフェースの処理をＨＴＴＰデーモン１３５自身の内部処理を行う。
【００６４】
Ｓ５：ＨＴＴＰデーモン１３５は、外部装置であるサーバ４０１へのＨＴＴＰの通信開始を要求する。
【００６５】
Ｓ６：ＨＴＴＰデーモン１３５はサーバ４０１からの通信開始の受諾を受信する。
【００６６】
Ｓ７：前記通信開始の受諾についてＨＴＴＰデーモンが内部処理を行う。
【００６７】
Ｓ８：統一インタフェース層１２１のＨＴＴＰデーモン対応ライブラリ１２３ｕがコールされる。
【００６８】
Ｓ９：前記ＨＴＴＰデーモン対応ライブラリ群がＳ２で呼ばれたＲＯｐｅｎ＿ＬＩＢの戻り値であるＳｔａｔｕｓ中のデータを受諾ＯＫとしてセットする。
【００６９】
Ｓ１０：Ｓ１で印刷アプリケーションからコールされたＯｐｅｎの戻り値Ｓｔａｔｕｓ中の受諾ＯＫのパラメータを取得する。
【００７０】
Ｓ１１：以降は、同様の流れにのっとり、Ｒｅａｄ（）１１１ｒによりデータの読取が行われ、Ｃｌｏｓｅ（）１１１ｃにより通信が終了される。
【００７１】
次に、図３（Ｂ）を用いて、外部装置である例えばホストＰＣ３；２０３から画像形成装置１０１の内部のＨＴＴＰサーバに通信を開始する際の統一インタフェース層とアプリケーションインタフェース部での流れについて説明する。
【００７２】
本説明では、画像形成装置１０１の内部ＨＴＴＰサーバは、印刷アプリケーション１１１が受け持つという前提の下に説明する。
【００７３】
Ｓ２１：ＨＴＴＰデーモン１３５は、画像形成装置１０１の内部ＨＴＴＰサーバへの通信開始要求を受信する。
【００７４】
Ｓ２２：ＨＴＴＰデーモン１３５の内部処理が行われる。
【００７５】
Ｓ２３：前記内部処理により統一インタフェース層１２１のＨＴＴＰデーモン対応ライブラリ群１２３ｈがコールされる。
【００７６】
Ｓ２４：前記ＨＴＴＰデーモン対応ライブラリ群１２３ｈにより統一インタフェース層のアプリケーションへ向けての通信開始Ｏｐｅｎ＿ＬＩＢ（）１２１ｏがコールされる。このとき前記Ｓ２と同様に各パラメータがセットされる。Ｓ２と異なるのは、Ｓｔａｔｕｓ中にアプリケーションを指定する値がセットされる。
【００７７】
Ｓ２５：Ｓ２４のＯｐｅｎ＿ＬＩＢ（）１２１ｏを受けて、印刷アプリケーション中のＲＯｐｅｎ（）１１１ｒｏが各パラメータを受け継いで起動される。この後印刷アプリケーション中の内部ＨＴＴＰサーバに関する処理が行われる。
【００７８】
Ｓ２６：Ｓ２５の戻り値としてＳｔａｔｕｓ中の通信開始の受諾ＯＫのパラメータがセットされ、その値が送信される。
【００７９】
Ｓ２７：Ｓ２４の戻り値としてＳｔａｔｕｓを受ける。
【００８０】
Ｓ２８：ＨＴＴＰデーモン対応ライブラリ群が戻り値Ｓｔａｔｕｓを解析してＨＴＴＰデーモンにデータを受け渡す。
【００８１】
Ｓ２９：ＨＴＴＰデーモンでの内部処理が行われる。
【００８２】
Ｓ３０：画像形成装置１０１内部のＨＴＴＰサーバの通信開始受諾を送信する。
【００８３】
Ｓ３１：以降は、データ読取要求によるデータ読取、通信終了要求による通信終了と続く。
【００８４】
［実施例の効果］
本発明実施例の画像形成装置により、アプリケーションと通信プロトコルデーモンとの間が統一したインタフェースに行われるため、アプリケーションの開発時の通信プロトコルの開発が簡略化され、低コスト化につながった。
【００８５】
統一インタフェース層１２１は、通信プロトコルデーモン（１３１〜１３６）によってコールされるライブラリ群であり、独立したアプリケーションとして起動するのではないため、独立プロセスとしてのＣＰＵタイムやメモリ資源を奪うことなく高速での処理が可能となった。
【実施例２】
【００８６】
本発明実施例２の画像形成装置について説明する。実施例２の画像形成装置は、統一インタフェース層１２１の構造が実施例１の画像形成装置と異なるのでその点を中心に説明する。
【００８７】
［構成］
実施例２の画像形成装置の全体構成は、図１に示す実施例１の画像形成装置と同じであるので、説明を省略する。
【００８８】
［統一インタフェース層及びアプリケーションインタフェース部］
実施例２の統一インタフェース層１２１及び印刷アプリケーション１１１のアプリケーションインタフェース部１１１ｉの構造について図４に示す。
【００８９】
実施例１にあった、印刷アプリケーション１１１のアプリケーションインタフェース部１１１ｉの統一インタフェース層１２１側からの発行に応答する印刷アプリケーションにとっては受信側の５つのインタフェース１１１ｒｏ、１１１ｒｃ、１１１ｒｒ、１１１ｒｗ、１１１ｒｓが存在せず、変わりに統一インタフェース層１２１に設けられた通知手段である、Ｎｏｔｉｆｙ（）１２１ｎにより、印刷アプリケーションに、通信の要求通知が伝えられる。
【００９０】
同様に印刷アプリケーション側にも通信の要求通知手段であるＮｏｔｉｆｙ（）１１１ｎが設けられて、統一インタフェース層に通信の要求を通知する。
【００９１】
［シーケンス］
図５のシーケンス図を用いて、実施例２の通信におけるアプリケーションインタフェース部１１１ｉと統一インタフェース層１２１の役割について説明する。本説明においては一例として、印刷アプリケーション１１１を用いてのＨＴＴＰ通信に関する、印刷アプリケーションとＨＴＴＰデーモンとの間でのデータ授受を行う場合について説明を行う。他のアプリケーション及び他の通信プロトコルデーモンでもアプリケーションインタフェース部と統一インタフェース層１２１の役割は同様である。
【００９２】
図５（Ａ）は、画像形成装置１０１が、外部のＨＴＴＰサーバ（例えばサーバ４０１）に対して通信を開始する際のシーケンスについて説明した図である。
【００９３】
Ｓ６１からＳ６８までの動作のシーケンスは、実施例１において図３（Ａ）を用いて説明したＳ１からＳ８までの流れと同じなので省略する。以下にＳ６９以降の動作について説明する。
【００９４】
Ｓ６９：Ｓ６１コールされたＯｐｅｎ（）がスレッド停止状態であったものを統一インタフェース層１２１のＮｏｔｉｆｙ（）１２１ｎにより再開させる。その際にＮｏｔｉｆｙ（）にＳｔａｔｕｓパラメータを渡す。
【００９５】
Ｓ７０：Ｓ６９によるＳｔａｔｕｓ値を受信する。
【００９６】
Ｓ７１：以降は、同様の流れにのっとり、Ｒｅａｄ（）１１１ｒによりデータの読取が行われ、Ｃｌｏｓｅ（）１１１ｃにより通信が終了される。
【００９７】
次に、図５（Ｂ）を用いて、外部装置である例えばホストＰＣ３；２０３から画像形成装置１０１の内部のＨＴＴＰサーバに通信を開始する際の統一インタフェース層とアプリケーションインタフェース部での流れについて説明する。
【００９８】
本説明では、画像形成装置１０１の内部ＨＴＴＰサーバは、印刷アプリケーション１１１が受け持つという前提の下に説明する。
【００９９】
Ｓ８１からＳ８３までの動作のシーケンスは、実施例１において図３（Ｂ）を用いて説明したＳ２１からＳ２３までの流れと同じなので省略する。以下にＳ８４以降の動作について説明する。
【０１００】
Ｓ８４：統一インタフェース層１２１のＮｏｔｉｆｙ（）１２１ｎにより、印刷アプリケーションに対し、内部サーバへの通信開始要求が通知される。
【０１０１】
Ｓ８５：Ｓ８４のＮｏｔｉｆｙ（）１２１ｎにより印刷アプリケーション１１１のＷｅｂサーバアプリケーション関連スレッドが起動する。
【０１０２】
Ｓ８６：印刷アプリケーション１１１がＯｐｅｎ（）１１１ｏにより、通信開始要求に応じる。
【０１０３】
Ｓ８７：統一インタフェース層１２１は、Ｏｐｅｎ＿ＬＩＢ（）１２１ｏにより、通信開始の応答を受信する。
【０１０４】
以降Ｓ８８からＳ９１の動作は、図３（Ｂ）を用いて説明したＳ２８からＳ３１の動作と同じであるので説明を省略する。
【０１０５】
ふたつあるＮｏｔｉｆｙ（）１１１ｎ及び１２１ｎでは、パラメータとしてＳｔａｔｕｓを渡す例について説明を行ったが、パラメータとしてイベントを渡せる形であっても良い。
【０１０６】
［実施例２の効果］
アプリケーションインタフェース部及び統一インタフェース層の両方にＮｏｔｉｆｙ（）を設けて通信の要求を通知する方法をとることにより、実施例１に比べて両方のインタフェース層の構造を簡単にすることが可能となった。
【実施例３】
【０１０７】
本発明実施例３の画像形成装置について説明する。
【０１０８】
実施例１の画像形成装置では、アプリケーションと通信プロトコルデーモンとの間の通信を全て統一インタフェース層１２１を介して行ったが、ＳＮＭＰ（Simple Network Management Protocol）などの小サイズで多数回の通信が行われるプロトコルでは、統一インタフェース層１２１がライブラリ群により構成されているような比較的オーバヘッドの少ない方法であっても、累積による遅延が問題となる場合がある。そこで、実施例３では特定プロトコルに関しては、統一インタフェース層１２１を経由せずに直接通信プロトコルデーモンとの通信を行う直接インタフェース部（特定プロトコル直接デーモンインタフェース部）を有する画像形成装置について説明する。
【０１０９】
［構成］
実施例３の画像形成装置のハードウェア構成は、実施例１の画像形成装置と同じである。図１でいうところのソフトウェア群１２０部分についてのみ違いがあるので、実施例３のソフトウェア群１２０の構成について図６を用いて説明する。
【０１１０】
図６では、アプリケーションの例として転送アプリケーション１１９を用いて説明するが、他アプリケーションでもその構成は同様である。
【０１１１】
画像形成装置の転送アプリケーション１１９は、大きく分けて通信部に関しての処理を行う通信処理部１１９ｙと転送アプリケーション処理部１１９ｘの二つに分かれる。実施例１の画像形成装置との違いは、通信処理部１１９ｙ中の構成の違いである。実施例１では通信処理部１１９ｙ中にはアプリケーションインタフェース部１１９ｉだけが存在したが、実施例３の画像形成装置では、さらに、プロトコル判断部１１９ｐ及び直接インタフェース部１１９ｄ（特定プロトコル直接デーモンインタフェース部）と、を有する。
【０１１２】
プロトコル判断部１１９ｐは、通信を行うプロトコルが何であるかを判断して、所定のプロトコルの場合は、統一インタフェース層１２１を介しての通信を行うアプリケーションインタフェース部ではなく、直接通信プロトコルデーモンとの通信を行う直接インタフェース部１１９ｄに通信を引き渡す。
【０１１３】
所定のプロトコルとは、前述したように小サイズかつ多数回の通信が行われる実施例３ではＳＮＭＰ通信のプロトコルである。
【０１１４】
直接インタフェース部１１９ｄは、ＳＮＭＰデーモンとの間での直接の通信を行うための通信プロトコルに合わせたインタフェースを有し、統一インタフェース層１２１を介さずに通信を行うためそのオーバヘッドによる遅延が無くなった。
【０１１５】
上記ＳＮＭＰ以外のプロトコルに関しては、実施例１で説明した統一インタフェース層１２１を介しての通信を行う。
【０１１６】
［通信のシーケンス］
図７を用いて実施例３の画像形成装置での、ＳＮＭＰ通信のシーケンスについて説明する。
【０１１７】
図７（Ａ）は、転送アプリケーション１１９からＳＮＭＰデーモン１３５を通して外部装置である画像形成装置２；５０１へのＳＮＭＰでの通信開始要求の説明である。
【０１１８】
Ｓ４１：転送アプリケーション１１９は、直接インタフェースによる画像形成装置２；５０１の機器状態確認のための通信の要求を開始する。転送アプリケーション内部のプロトコル判断部１１９ｐは、プロトコルがＳＮＭＰであると判断して、直接インタフェース１１９ｄを用いてＳＮＭＰプロトコルデーモンに通信開始要求を行う。
【０１１９】
Ｓ４２：ＳＮＭＰデーモンは、Ｓ４１の通信開始要求を受信しＳＮＭＰデーモンでの内部処理を行って、ネットワークインタフェースから送信するためのデータを形成する。
【０１２０】
Ｓ４３：ＳＮＭＰデーモンは、画像形成装置２；５０１にＳＮＭＰでの通信開始の要求を送信する。
【０１２１】
Ｓ４４：画像形成装置２；５０１からのＳＮＭＰでの通信開始の受諾を受信する。
【０１２２】
Ｓ４５：ＳＮＭＰデーモン１３５での内部処理を行って、転送アプリケーション１１９への送信のためのデータ形成を行う。
【０１２３】
Ｓ４６：転送アプリケーション１１９は、直接インタフェース部１１９ｄにより画像形背装置２；５０１の通信開始受諾を受信して、転送アプリケーション内部の処理を開始する。
【０１２４】
次に図７（Ｂ）を用いて、外部装置である画像形成装置２；５０１から画像形成装置１０１へのＳＮＭＰでの通信開始要求がある際のＳＮＭＰデーモン１３５及び転送アプリケーション１１９の動作の流れについて説明する。
【０１２５】
Ｓ５１：ＳＮＭＰデーモン１３５は、画像形成装置２；５０１からＳＮＭＰでの通信開始の要求を受信する。
【０１２６】
Ｓ５２：ＳＮＭＰデーモン１３５内部での処理が行われる。
【０１２７】
Ｓ５３：転送アプリケーション１１９は、Ｓ５２のＳＮＭＰデーモンでの内部処理によるＳＮＭＰの通信開始要求を受信する。
【０１２８】
Ｓ５４：転送アプリケーション１１９は、Ｓ５３の通信開始要求による内部処理を行った後、ＳＮＭＰデーモン１３５に対して、直接インタフェースにより通信開始要求を受諾する旨を送信する。
【０１２９】
Ｓ５５：ＳＮＭＰデーモン１３５は、直接インタフェースによりＳ５４の受諾を受信してその内部処理を行う。
【０１３０】
Ｓ５６：ＳＮＭＰデーモン１３５は、画像形成装置２；５０１に対しＳＮＭＰでの通信開始受諾を送信する。
【０１３１】
Ｓ５７：以降は、ＳＮＭＰでの小サイズ多数回の通信が画像形成装置２；５０１と画像形成装置１０１との間でやりとりが行われ通信が終了する。
【０１３２】
［実施例３の効果］
実施例３の画像形成装置により、統一インタフェース層１２１を用いてアプリケーションの通信部の開発コストを下げることと、ＳＮＭＰのような小サイズかつ多数回の通信が行われるプロトコルに関しては、直接インタフェースにより通信を行うことにより統一インタフェース層でのオーバヘッドによる遅延をなくすことができ、性能とコストを兼ね合わせた画像形成装置を実現することが可能となった。
【０１３３】
［その他］
本発明実施例では、アプリケーションについて機能毎に分かれた複数のアプリケーションからなる構成としたが、全ての機能を含めてひとつのアプリケーションとする構成であってもよい。
【０１３４】
本発明実施例では、アプリケーションとして主要と思われる５つの機能について記載し説明したが、その他の機能のアプリケーションが加わっていても構わないし、又、実施例で示した５機能が全て揃っていない場合であっても構わない。
【０１３５】
同様に本発明実施例では、主要な６つの通信プロトコルデーモンに関して記載し説明したがその他の通信プロトコルに対応していても構わない。又、実施例で示した６プロトコルが全て揃っていない場合であっても構わない。
【０１３６】
本発明実施例では、統一インタフェース層１２１は通信プロトコルデーモン（１３１〜１３６）から呼び出されるプログラムライブラリの集合である構成としたが、統一インタフェース層１２１はアプリケーション（１１１〜１１９）から呼び出されるプログラムライブラリの集合である構成であってもよい。また、通信プロトコルデーモンとアプリケーションとのそれぞれから呼び出されるプログラムライブラリの集合の混合であっても良い。
【０１３７】
また、統一インタフェース層はプログラムライブラリの集合ではなく独立したアプリケーションであっても良い。
【図面の簡単な説明】
【０１３８】
【図１】本発明実施例１の画像形成装置の機能ブロック図である（実施例１、２）。
【図２】本発明実施例１の画像形成装置のアプリケーションインタフェースと統一インタフェース層の詳細図である（実施例１）。
【図３】本発明実施例１の画像形成装置の通信のシーケンス図である（実施例１）。
【図４】本発明実施例２の画像形成装置のアプリケーションインタフェースと統一インタフェース層の詳細図である（実施例２）。
【図５】本発明実施例２の画像形成装置の通信のシーケンス図である（実施例２）。
【図６】本発明実施例３の画像形成装置のソフトウェア層の構造図である（実施例３）。
【図７】本発明実施例３の画像形成装置の通信のシーケンス図である（実施例３）。
【符号の説明】
【０１３９】
１０１ 画像形成装置
１１１ 印刷アプリケーション（アプリケーション）
１１１ｄ 直接インタフェース部（特定プロトコル直接アプリケーションインタフェース部）
１１１ｉ アプリケーションインタフェース部（統一アプリケーションインタフェース）
１１１ｐ プロトコル判断部
１１１ｏ 発呼側Ｏｐｅｎインタフェース（通信の開始のインタフェース）
１１１ｃ 発呼側Ｃｌｏｓｅインタフェース（通信の終了のインタフェース）
１１１ｒ 発呼側Ｒｅａｄインタフェース（データの読取のインタフェース）
１１１ｗ 発呼側Ｗｒｉｔｅインタフェース（データの書込のインタフェース）
１１１ｓ 発呼側ＣｈｅｃｋＳｔａｔｕｓインタフェース（通信状態の把握のインタフェース）
１１１ｒｏ 受信側Ｏｐｅｎインタフェース（通信の開始のインタフェース）
１１１ｒｃ 受信側Ｃｌｏｓｅインタフェース（通信の終了のインタフェース）
１１１ｒｒ 受信側Ｒｅａｄインタフェース（データの読取のインタフェース）
１１１ｒｗ 受信側Ｗｒｉｔｅインタフェース（データの書込のインタフェース）
１１１ｒｓ 受信側ＣｈｅｃｋＳｔａｔｕｓインタフェース（通信状態の把握のインタフェース）
１１３ 複写アプリケーション（アプリケーション）
１１５ ファクスアプリケーション（アプリケーション）
１１７ スキャナアプリケーション（アプリケーション）
１１９ 転送アプリケーション（アプリケーション）
１１９ｐ プロトコル判断部（実施例３）
１２０ ソフトウェア群
１２１ 統一インタフェース層
１２１ａｌ アプリ統一インタフェースライブラリ群
１２１ｄｌ 通信デーモンプロトコルライブラリ群
１３１ ＵＳＢデーモン（通信プロトコルデーモン）
１３１ｉ デーモンインタフェース部（統一デーモンインタフェース）
１３２ セントロニクスデーモン（通信プロトコルデーモン）
１３２ｉ デーモンインタフェース部（統一デーモンインタフェース）
１３３ 公衆回線網デーモン（通信プロトコルデーモン）
１３３ｉ デーモンインタフェース部（統一デーモンインタフェース）
１３４ ＦＴＰデーモン（通信プロトコルデーモン）
１３４ｉ デーモンインタフェース部（統一デーモンインタフェース）
１３５ ＨＴＴＰデーモン（通信プロトコルデーモン）
１３５ｉ デーモンインタフェース部（統一デーモンインタフェース）
１３６ ＳＮＭＰデーモン（通信プロトコルデーモン）
１３６ｉ デーモンインタフェース部（統一デーモンインタフェース）
１５０ ハードウェア群
１６０ ハードウェアインタフェース群
２０１ ホストＰＣ１（外部装置）
２０２ ホストＰＣ２（外部装置）
２０３ ホストＰＣ３（外部装置）
３０１ ＦＡＸ（外部装置）
４０１ サーバ（外部装置）
５０１ 画像形成装置２（外部装置）
【技術分野】
【０００１】
画像形成装置において、アプリケーションの開発コスト低減のために通信プロトコルデーモンとの間に統一インタフェースを提供することに関し、さらに仲介インタフェース層のオーバヘッドによる遅延を回避する技術に関するものである。
【背景技術】
【０００２】
画像形成装置では、外部装置との間で通信を行ってデータのやり取りを行う。その際の通信には、種々のプロトコルがある。例えば、インターネットでのブラウザ・サーバ間のデータのやりとりに使われるＨＴＴＰ（HyperText Transfer Protocol）や、ネットワークに接続された通信機器を監視・制御するためのＳＮＭＰ（Simple Network Management Protocol）や、パラレルインタフェースを用いてのセントロニクス仕様に基づくプロトコルや、ＵＳＢインタフェースを用いてのＵＳＢ規格に基づくプロトコル等がある。
【０００３】
画像形成装置では、これらの各プロトコルの通信を受け持つ通信プロトコルデーモンを有し、画像形成装置の画像処理を行う種々のアプリケーションとの間でデータの授受を行い外部装置とのデータ通信を行う。
【０００４】
この前記複数のアプリケーションと前記複数の通信プロトコルデーモンとの通信を受け持つインタフェースプログラム部をそれぞれに作成すると開発に時間がかかり、高コスト化を招き又バグの発生の可能性やバグの見落としの可能性が高かった。
【０００５】
そこで、従来技術として通信プロトコルデーモンからの接続通知に応じて、該接続通知をアプリケーションに仲介する仲介アプリケーションを備える方法がある（特許文献１参照）。
【０００６】
しかし、この方法では、仲介アプリケーションが受け持つのは、前記した接続通知に関する部分だけであり、接続通知要求後のデータ通信は通信プロトコルデーモンとアプリケーションの間で直接行うため、依然としてこれらの通信部分のインタフェースをそれぞれのアプリケーション及びプロトコル毎に開発する必要があった。
【特許文献１】特開２００４−１４２５号公報
【発明の開示】
【発明が解決しようとする課題】
【０００７】
解決しようとする問題点は、画像形成装置において、画像形成処理を行うアプリケーションと外部装置の通信を受け持つ通信プロトコルデーモンとの間の通信インタフェースを統一して、通信に関するプログラムの開発コストを下げると共に、統一インタフェースによるパフォーマンスの低下を抑制する点である。
【課題を解決するための手段】
【０００８】
本発明の画像形成装置は、画像形成に関する処理を行うアプリケーションと、複数種の通信プロトコルに従って通信を行う複数種の通信プロトコルデーモンと、を備えて外部装置との間で通信を行う画像形成装置であって、前記アプリケーションと前記プロトコルデーモンとの間でデータの授受を統一したインタフェースにより行う統一インタフェース層を有し、前記アプリケーションは、前記統一インタフェース層とのデータ授受のための統一アプリケーションインタフェースを備え、前記通信プロトコルデーモンは、前記統一インタフェース層とのデータ授受のための統一デーモンインタフェースを備えることを最も主要な特徴とする。
【０００９】
さらに、本発明の画像形成装置は前記画像形成装置であって、前記アプリケーションは、通信が所定のプロトコルであるかどうかを判断するプロトコル判断部と、前記プロトコル判断部で所定のプロトコルと判断された場合には、該プロトコルの通信を受け持つ前記通信プロトコルデーモンとの直接のデータ授受を行う特定プロトコル直接アプリケーションインタフェース部と、を有し、前記所定のプロトコルを受け持つ前記通信プロトコルデーモンは、前記特定プロトコル直接アプリケーションインタフェース部との間でデータの授受を行う特定プロトコル直接デーモンインタフェース部を有することを特徴とする。
【発明の効果】
【００１０】
本発明の画像形成装置は、画像形成に関する処理を行うアプリケーションと、複数種の通信プロトコルに従って通信を行う複数種の通信プロトコルデーモンと、を備えて外部装置との間で通信を行う画像形成装置であって、前記アプリケーションと前記通信プロトコルデーモンとの間でデータの授受を統一したインタフェースにより行う統一インタフェース層を有し、前記アプリケーションは、前記統一インタフェース層とのデータ授受のための統一アプリケーションインタフェースを備え、前記通信プロトコルデーモンは、前記統一インタフェース層とのデータ授受のための統一デーモンインタフェースを備えることを最も主要な特徴とするため、アプリケーションの開発の際には、統一インタフェース層で規定してあるインタフェースに従って、アプリケーションの設計・開発を行うことが可能であり、開発時間の短期化及び開発コストの低下が実現した。
【００１１】
さらに、本発明の画像形成装置は前記画像形成装置であって、前記アプリケーションは、通信が所定のプロトコルであるかどうかを判断するプロトコル判断部と、前記プロトコル判断部で所定のプロトコルと判断された場合には、該プロトコルの通信を受け持つ前記通信プロトコルデーモンとの直接のデータ授受を行う特定プロトコル直接アプリケーションインタフェース部と、を有し、前記所定のプロトコルを受け持つ前記通信プロトコルデーモンは、前記特定プロトコル直接アプリケーションインタフェース部との間でデータの授受を行う特定プロトコル直接デーモンインタフェース部を有することを特徴とするため、ＳＮＭＰ通信におけるような、小サイズでかつ多数回の通信が行われて、統一インタフェース層のオーバヘッドによる遅延が問題となるような場合には、アプリケーションと通信プロトコルデーモンとの直接の通信を行うため遅延の問題が無くなった。これにより、開発の短期化と性能のバランスがとれたアプリケーションの開発が可能となった。
【発明を実施するための最良の形態】
【００１２】
画像形成装置において、アプリケーションと通信プロトコルデーモンとの通信部分の開発に時間がかかるという問題について、統一インタフェース層を前記アプリケーションと前記通信プロトコルデーモンとの間に介在させることにより解決した。また、ＳＮＭＰなどの小サイズ・多数回の通信が行われるプロトコルにおける統一インタフェース層でのオーバヘッドによる遅延の問題については、アプリケーションがプロトコルを判断して、その判断結果に基づき通信プロトコルデーモンとの直接の通信を行うことにより問題点を解決した。
【実施例１】
【００１３】
［構成］
図１は、本発明の実施例に係わる画像形成装置１０１の機能ブロック図である。
【００１４】
画像形成装置１０１は、大きくハードウェア群１５０、ソフトウェア群１２０、ハードウェアインタフェース群１６０に分かれる。
【００１５】
ハードウェア群１５０は、印刷エンジン１５１、スキャナ１５３、記憶・制御部１５７と、を有する。
【００１６】
ソフトウェア群１２０は、機能毎のアプリケーションである、印刷アプリケーション１１１、複写アプリケーション１１３、ファクスアプリケーション１１５、スキャナアプリケーション１１７、転送アプリケーション１１９を有し、通信プロトコルデーモンである、ＵＳＢ（Universal Serial Bus）デーモン１３１、セントロニクスデーモン１３２、公衆回線網デーモン１３３、ＦＴＰ（File Transfer Protocol）デーモン１３４、ＨＴＴＰ（HyperText Transfer Protocol）デーモン１３５、ＳＮＭＰ（Simple Network Management Protocol）デーモン１３６を有し、前記アプリケーション（１１１〜１１９）と前記通信プロトコルデーモン（１３１〜１３６）との間に介在する統一インタフェース層１２１を有する。
【００１７】
ハードウェアインタフェース群１６０は、ＵＳＢインタフェース１６１、セントロニクスインタフェース１６２、公衆回線網インタフェース１６３、ネットワークインタフェース１６５を有する。
【００１８】
また、画像形成装置は、外部装置である、ホストＰＣ１；２０１、ホストＰＣ２；２０２、ホストＰＣ３；２０３、ＦＡＸ３０１、サーバ４０１、画像形成装置２；５０１と図１に示すようにハードウェアインタフェース群１６０の各種インタフェースを通して接続している。
【００１９】
以下に各機能部について説明する。
【００２０】
印刷エンジン１５１は、印刷を行うハードウェア機能部である。
【００２１】
スキャナ１５３は、原稿の画像を読み取るハードウェア機能部である。
【００２２】
記憶・制御部１５７は、半導体メモリ及び磁気回転ディスク装置からなる記憶装置と、ＣＰＵ及び周辺制御回路からなる制御装置と、を有し、画像形成装置全体の制御を司る機能部である。
【００２３】
印刷アプリケーション１１１は、画像形成装置の印刷の画像形成に関する処理の機能を画像形成装置のコンピュータに実行させるプログラム機能部である。
【００２４】
複写アプリケーション１１３は、画像形成装置の複写の画像形成に関する処理の機能を画像形成装置のコンピュータに実行させるプログラム機能部である。
【００２５】
ファクスアプリケーション１１５は、画像形成装置のファクスの画像形成に関する処理の機能を画像形成装置のコンピュータに実行させるプログラム機能部である。
【００２６】
スキャナアプリケーション１１７は、画像形成装置のスキャナ１５３での画像形成に関する処理の機能を画像形成装置のコンピュータに実行させるプログラム機能部である。
【００２７】
転送アプリケーション１１９は、画像形成装置のファイル転送の画像形成に関する処理の機能を画像形成装置のコンピュータに実行させるプログラム機能部である。
【００２８】
上記の各アプリケーションは、統一インタフェース層１２１（後述）との間でのデータの授受に関するインタフェース部であるアプリケーションインタフェース部（１１１ｉ、１１３ｉ、１１５ｉ、１１７ｉ、１１９ｉ）を有する。
【００２９】
次に複数種ある通信プロトコルデーモンについて説明する。
【００３０】
ＵＳＢデーモン１３１は、ＵＳＢ規格での通信のデータ授受を受け持つデーモンである。
【００３１】
セントロニクスデーモン１３２は、セントロニクス仕様のパラレルインタフェースでの通信のデータ授受を受け持つデーモンである。
【００３２】
公衆回線網デーモン１３３は、公衆回線網を通しての通信のデータ授受を受け持つデーモンである。
【００３３】
ＦＴＰデーモン１３４は、File Transfer Protocolを用いての通信のデータ授受を受け持つデーモンである。
【００３４】
ＨＴＴＰデーモン１３５は、HyperText Transfer Protocolを用いての通信のデータ授受を受け持つデーモンである。
【００３５】
ＳＮＭＰデーモン１３６は、Simple Network Management Protocolを用いての通信のデータ授受を受け持つデーモンである。
【００３６】
上記の通信プロトコルデーモンは、統一インタフェース層１２１（後述）との間でのデータの授受に関する統一デーモンインタフェースであるデーモンインタフェース部（１３１ｉ、１３２ｉ、１３３ｉ、１３４ｉ、１３５ｉ、１３６ｉ）を有する。
【００３７】
統一インタフェース層１２１は、前記アプリケーション（１１１，１１３，１１５，１１７，１１９）と通信デーモンプロトコル（１３１、１３２，１３３，１３４，１３５，１３６）との間に介在するプログラムである。統一インタフェース層は、独立したプロセスを実行するアプリケーションプログラムではなく、必要時に他プログラム（通信プロトコルデーモン）から起動されるライブラリプログラムの集合である。統一インタフェース層１２１には、アプリケーションとの間の統一したインタフェースを提供するアプリケーション統一インタフェースライブラリ群１２１ａｌと通信プロトコルデーモンとの間のインタフェースを提供する通信プロトコルデーモンインタフェースライブラリ群１２３ｄｌと、を有する。統一インタフェース層１２１のより詳細な構造については、インタフェースの説明の項で後述する。
【００３８】
次にハードウェアインタフェース群１６０の各インタフェースについて説明する。
【００３９】
ＵＳＢインタフェース１６１は、ＵＳＢ規格のインタフェースのハードウェアであり、例えば図１に示すようにホストＰＣ１；２０１と接続してホストＰＣ１；２０１から印刷データを受信する。
【００４０】
セントロニクスインタフェース１６２は、セントロニクス仕様のインタフェースのハードウェアであり、例えば図１に示すようにホストＰＣ２；２０２と接続してホストＰＣ２；２０２から印刷データを受信する。
【００４１】
公衆回線網インタフェース１６３は、電話回線での通信接続のためのインタフェースであり、公衆回線を通して他のＦＡＸ装置３０１と接続している。
【００４２】
ネットワークインタフェース１６５は、ネットワークのインタフェースであり、例えば図１に示すように、ネットワークを通してホストＰＣ３；２０３やサーバ４０１や画像形成装置２；５０１と接続している。
【００４３】
［統一インタフェース層及びアプリケーションインタフェース部］
図２を用いて統一インタフェース層１２１とアプリケーションとのインタフェースについて、その詳細を説明する。
【００４４】
図２は、アプリケーションの一例としての印刷アプリケーション１１１と統一インタフェース層とのさらに詳細な構造を示したものである。印刷アプリケーション１１１以外の他のアプリケーションでもその構造は同様である。
【００４５】
印刷アプリケーション１１１のアプリケーションインタフェース部１１１ｉには、以下の１０個のインタフェースが備わっている。
【００４６】
印刷アプリケーション側が発呼の通信の開始のインタフェースＯｐｅｎ（）１１１ｏ、同（印刷アプリケーション側が発呼の；以下省略）通信の終了のインタフェースＣｌｏｓｅ（）１１１ｃ、同データの読取Ｒｅａｄ（）１１１ｒ、同データの書込Ｗｒｉｔｅ（）１１１ｗ、同通信状態の把握ＣｈｅｃｋＳｔａｔｕｓ（）１１１ｓの５個のインタフェースと、統一インタフェース層１２１側からの発呼に応答する印刷アプリケーションにとっては受信側の通信の開始のインタフェースＲＯｐｅｎ（）１１１ｒｏ、同（統一インタフェース層１２１側からの発呼に応答する印刷アプリケーションにとっては受信側の；以下省略）通信の終了のインタフェースＲＣｌｏｓｅ（）１１１ｒｃ、同データの読取ＲＲｅａｄ（）１１１ｒｒ、同データの書込ＲＷｒｉｔｅ（）１１１ｒｗ、同通信状態の把握ＲＣｈｅｃｋＳｔａｔｕｓ（）１１１ｒｓの５個のインタフェースとの１０個のインタフェースを有する。
【００４７】
統一インタフェース層１２１は、前記１０個のインタフェースに呼応する１０個のインタフェースであるアプリ統一インタフェースライブラリ群１２１ａｌ（プログラムライブラリの集合）と、通信プロトコルデーモン（１３１〜１３６）から呼び出される通信プロトコルデーモンインタフェースライブラリ群１２３ｄｌ（プログラムライブラリの集合）と、から構成される。
【００４８】
アプリ統一インタフェースライブラリ群１２１ａｌは、通信プロトコルデーモン（１３１〜１３６）側が発呼の通信の開始のインタフェースＯｐｅｎ＿ＬＩＢ（）１２１ｏ、同（通信プロトコルデーモン側が発呼の；以下省略）通信の終了のインタフェースＣｌｏｓｅ＿ＬＩＢ（）１２１ｃ、同データの読取Ｒｅａｄ＿ＬＩＢ（）１２１ｒ、同データの書込Ｗｒｉｔｅ＿ＬＩＢ（）１２１ｗ、同通信状態の把握ＣｈｅｃｋＳｔａｔｕｓ＿ＬＩＢ（）１２１ｓの５個のインタフェースと、アプリケーション（１１１〜１１９）側からの発呼に応答する通信プロトコルデーモン（１３１〜１３６）にとっては受信側の通信の開始のインタフェースＲＯｐｅｎ＿ＬＩＢ（）１２１ｒｏ、同（アプリケーション（１１１〜１１９）側からの発呼に応答する通信プロトコルデーモン（１３１〜１３６）にとっては受信側の；以下省略）通信の終了のインタフェースＲＣｌｏｓｅ＿ＬＩＢ（）１２１ｒｃ、同データの読取ＲＲｅａｄ＿ＬＩＢ（）１２１ｒｒ、同データの書込ＲＷｒｉｔｅ＿ＬＩＢ（）１２１ｒｗ、同通信状態の把握ＲＣｈｅｃｋＳｔａｔｕｓ＿ＬＩＢ（）１２１ｒｓの５個のインタフェースとの１０個のインタフェースを有する。
【００４９】
さらに、通信プロトコルデーモンインタフェースライブラリ群１２３ｄｌは、ＵＳＢデーモン１３１から呼び出されるＵＳＢデーモン対応ライブラリ群１２３ｕ、セントロニクスデーモン１３２から呼び出されるセントロニクスデーモン対応ライブラリ群１２３ｃ、公衆回線網デーモン１３３から呼び出される公衆回線網デーモンライブラリ群１２３ｋ、ＦＴＰデーモン１３４から呼び出されるＦＴＰデーモン対応ライブラリ群１２３ｆ、ＨＴＴＰデーモン１３５から呼び出されるＨＴＴＰデーモン対応ライブラリ群１２３ｈ、ＳＮＭＰデーモン１３６から呼び出されるＳＮＭＰデーモン対応ライブラリ群１２３ｓとからなる。
【００５０】
［シーケンス］
図３のシーケンス図を用いて実際の通信におけるアプリケーションインタフェース部と統一インタフェース層１２１の役割について説明する。本説明においては一例として、アプリケーションは印刷アプリケーション１１１を用いて、ＨＴＴＰ通信についてＨＴＴＰデーモンとの間でのデータ授受を行う場合について説明を行う。他のアプリケーション及び他の通信プロトコルデーモンでもアプリケーションインタフェース部と統一インタフェース層１２１の役割は同様である。
【００５１】
図３（Ａ）は、画像形成装置１０１が、外部のＨＴＴＰサーバ（例えばサーバ４０１）に対して通信を開始する際のシーケンスについて説明した図である。
【００５２】
Ｓ１：ユーザによるＨＴＴＰのデータ取得要求が発生すると印刷アプリケーション１１１は、アプリケーションインタフェース部１１１ｉの通信開始のインタフェースＯｐｅｎ（）１１１ｏをコールする。
【００５３】
Ｏｐｅｎ（）１１１ｏのコールの際には、各パラメータがセットされる。
【００５４】
プロトコルを示すＰＲＯＴＯＣＯＬには、ＨＴＴＰを指定する。
【００５５】
ｂｕｆｆｅｒでやり取りを行うデータ構造を示すＤａｔａＳｔｒｕｃｔｕｒｅには、定義済みのＨＴＴＰ用のデータ構造であるＨＴＴＰｄｓを指定する。
【００５６】
データを格納するｂｕｆｆｅｒのポインタには、ｂｕｆｆｅｒを指定する。
【００５７】
戻り値を格納するＳｔａｔｕｓには、Ｓｔａｔｕｓを指定する。
【００５８】
上記ＨＴＴＰは、ＨＴＴＰ通信を表す定数である。
【００５９】
ＨＴＴＰｄｓは、定義済みのＨＴＴＰのデータ交換のためのデータ構造。
【００６０】
ｂｕｆｆｅｒとＳｔａｔｕｓは確保されたデータ領域である。
【００６１】
Ｓ２：印刷アプリケーションからコールされたＯｐｅｎ（）１１１ｏを受けて、統一インタフェース層中の通信の開始の受信側インタフェースであるＲＯｐｅｎ＿ＬＩＢ１１１ｒｏが前記定義された各パラメータを受け取る。
【００６２】
Ｓ３：ＨＴＴＰデーモン対応ライブラリ群１２３ｕ中のライブラリが前記ＲＯｐｅｎ＿ＬＩＢ（）１２１ｒｏを受けてＨＴＴＰデーモン１３５のインタフェースに変換する。
【００６３】
Ｓ４：前記Ｓ３で受けたインタフェースの処理をＨＴＴＰデーモン１３５自身の内部処理を行う。
【００６４】
Ｓ５：ＨＴＴＰデーモン１３５は、外部装置であるサーバ４０１へのＨＴＴＰの通信開始を要求する。
【００６５】
Ｓ６：ＨＴＴＰデーモン１３５はサーバ４０１からの通信開始の受諾を受信する。
【００６６】
Ｓ７：前記通信開始の受諾についてＨＴＴＰデーモンが内部処理を行う。
【００６７】
Ｓ８：統一インタフェース層１２１のＨＴＴＰデーモン対応ライブラリ１２３ｕがコールされる。
【００６８】
Ｓ９：前記ＨＴＴＰデーモン対応ライブラリ群がＳ２で呼ばれたＲＯｐｅｎ＿ＬＩＢの戻り値であるＳｔａｔｕｓ中のデータを受諾ＯＫとしてセットする。
【００６９】
Ｓ１０：Ｓ１で印刷アプリケーションからコールされたＯｐｅｎの戻り値Ｓｔａｔｕｓ中の受諾ＯＫのパラメータを取得する。
【００７０】
Ｓ１１：以降は、同様の流れにのっとり、Ｒｅａｄ（）１１１ｒによりデータの読取が行われ、Ｃｌｏｓｅ（）１１１ｃにより通信が終了される。
【００７１】
次に、図３（Ｂ）を用いて、外部装置である例えばホストＰＣ３；２０３から画像形成装置１０１の内部のＨＴＴＰサーバに通信を開始する際の統一インタフェース層とアプリケーションインタフェース部での流れについて説明する。
【００７２】
本説明では、画像形成装置１０１の内部ＨＴＴＰサーバは、印刷アプリケーション１１１が受け持つという前提の下に説明する。
【００７３】
Ｓ２１：ＨＴＴＰデーモン１３５は、画像形成装置１０１の内部ＨＴＴＰサーバへの通信開始要求を受信する。
【００７４】
Ｓ２２：ＨＴＴＰデーモン１３５の内部処理が行われる。
【００７５】
Ｓ２３：前記内部処理により統一インタフェース層１２１のＨＴＴＰデーモン対応ライブラリ群１２３ｈがコールされる。
【００７６】
Ｓ２４：前記ＨＴＴＰデーモン対応ライブラリ群１２３ｈにより統一インタフェース層のアプリケーションへ向けての通信開始Ｏｐｅｎ＿ＬＩＢ（）１２１ｏがコールされる。このとき前記Ｓ２と同様に各パラメータがセットされる。Ｓ２と異なるのは、Ｓｔａｔｕｓ中にアプリケーションを指定する値がセットされる。
【００７７】
Ｓ２５：Ｓ２４のＯｐｅｎ＿ＬＩＢ（）１２１ｏを受けて、印刷アプリケーション中のＲＯｐｅｎ（）１１１ｒｏが各パラメータを受け継いで起動される。この後印刷アプリケーション中の内部ＨＴＴＰサーバに関する処理が行われる。
【００７８】
Ｓ２６：Ｓ２５の戻り値としてＳｔａｔｕｓ中の通信開始の受諾ＯＫのパラメータがセットされ、その値が送信される。
【００７９】
Ｓ２７：Ｓ２４の戻り値としてＳｔａｔｕｓを受ける。
【００８０】
Ｓ２８：ＨＴＴＰデーモン対応ライブラリ群が戻り値Ｓｔａｔｕｓを解析してＨＴＴＰデーモンにデータを受け渡す。
【００８１】
Ｓ２９：ＨＴＴＰデーモンでの内部処理が行われる。
【００８２】
Ｓ３０：画像形成装置１０１内部のＨＴＴＰサーバの通信開始受諾を送信する。
【００８３】
Ｓ３１：以降は、データ読取要求によるデータ読取、通信終了要求による通信終了と続く。
【００８４】
［実施例の効果］
本発明実施例の画像形成装置により、アプリケーションと通信プロトコルデーモンとの間が統一したインタフェースに行われるため、アプリケーションの開発時の通信プロトコルの開発が簡略化され、低コスト化につながった。
【００８５】
統一インタフェース層１２１は、通信プロトコルデーモン（１３１〜１３６）によってコールされるライブラリ群であり、独立したアプリケーションとして起動するのではないため、独立プロセスとしてのＣＰＵタイムやメモリ資源を奪うことなく高速での処理が可能となった。
【実施例２】
【００８６】
本発明実施例２の画像形成装置について説明する。実施例２の画像形成装置は、統一インタフェース層１２１の構造が実施例１の画像形成装置と異なるのでその点を中心に説明する。
【００８７】
［構成］
実施例２の画像形成装置の全体構成は、図１に示す実施例１の画像形成装置と同じであるので、説明を省略する。
【００８８】
［統一インタフェース層及びアプリケーションインタフェース部］
実施例２の統一インタフェース層１２１及び印刷アプリケーション１１１のアプリケーションインタフェース部１１１ｉの構造について図４に示す。
【００８９】
実施例１にあった、印刷アプリケーション１１１のアプリケーションインタフェース部１１１ｉの統一インタフェース層１２１側からの発行に応答する印刷アプリケーションにとっては受信側の５つのインタフェース１１１ｒｏ、１１１ｒｃ、１１１ｒｒ、１１１ｒｗ、１１１ｒｓが存在せず、変わりに統一インタフェース層１２１に設けられた通知手段である、Ｎｏｔｉｆｙ（）１２１ｎにより、印刷アプリケーションに、通信の要求通知が伝えられる。
【００９０】
同様に印刷アプリケーション側にも通信の要求通知手段であるＮｏｔｉｆｙ（）１１１ｎが設けられて、統一インタフェース層に通信の要求を通知する。
【００９１】
［シーケンス］
図５のシーケンス図を用いて、実施例２の通信におけるアプリケーションインタフェース部１１１ｉと統一インタフェース層１２１の役割について説明する。本説明においては一例として、印刷アプリケーション１１１を用いてのＨＴＴＰ通信に関する、印刷アプリケーションとＨＴＴＰデーモンとの間でのデータ授受を行う場合について説明を行う。他のアプリケーション及び他の通信プロトコルデーモンでもアプリケーションインタフェース部と統一インタフェース層１２１の役割は同様である。
【００９２】
図５（Ａ）は、画像形成装置１０１が、外部のＨＴＴＰサーバ（例えばサーバ４０１）に対して通信を開始する際のシーケンスについて説明した図である。
【００９３】
Ｓ６１からＳ６８までの動作のシーケンスは、実施例１において図３（Ａ）を用いて説明したＳ１からＳ８までの流れと同じなので省略する。以下にＳ６９以降の動作について説明する。
【００９４】
Ｓ６９：Ｓ６１コールされたＯｐｅｎ（）がスレッド停止状態であったものを統一インタフェース層１２１のＮｏｔｉｆｙ（）１２１ｎにより再開させる。その際にＮｏｔｉｆｙ（）にＳｔａｔｕｓパラメータを渡す。
【００９５】
Ｓ７０：Ｓ６９によるＳｔａｔｕｓ値を受信する。
【００９６】
Ｓ７１：以降は、同様の流れにのっとり、Ｒｅａｄ（）１１１ｒによりデータの読取が行われ、Ｃｌｏｓｅ（）１１１ｃにより通信が終了される。
【００９７】
次に、図５（Ｂ）を用いて、外部装置である例えばホストＰＣ３；２０３から画像形成装置１０１の内部のＨＴＴＰサーバに通信を開始する際の統一インタフェース層とアプリケーションインタフェース部での流れについて説明する。
【００９８】
本説明では、画像形成装置１０１の内部ＨＴＴＰサーバは、印刷アプリケーション１１１が受け持つという前提の下に説明する。
【００９９】
Ｓ８１からＳ８３までの動作のシーケンスは、実施例１において図３（Ｂ）を用いて説明したＳ２１からＳ２３までの流れと同じなので省略する。以下にＳ８４以降の動作について説明する。
【０１００】
Ｓ８４：統一インタフェース層１２１のＮｏｔｉｆｙ（）１２１ｎにより、印刷アプリケーションに対し、内部サーバへの通信開始要求が通知される。
【０１０１】
Ｓ８５：Ｓ８４のＮｏｔｉｆｙ（）１２１ｎにより印刷アプリケーション１１１のＷｅｂサーバアプリケーション関連スレッドが起動する。
【０１０２】
Ｓ８６：印刷アプリケーション１１１がＯｐｅｎ（）１１１ｏにより、通信開始要求に応じる。
【０１０３】
Ｓ８７：統一インタフェース層１２１は、Ｏｐｅｎ＿ＬＩＢ（）１２１ｏにより、通信開始の応答を受信する。
【０１０４】
以降Ｓ８８からＳ９１の動作は、図３（Ｂ）を用いて説明したＳ２８からＳ３１の動作と同じであるので説明を省略する。
【０１０５】
ふたつあるＮｏｔｉｆｙ（）１１１ｎ及び１２１ｎでは、パラメータとしてＳｔａｔｕｓを渡す例について説明を行ったが、パラメータとしてイベントを渡せる形であっても良い。
【０１０６】
［実施例２の効果］
アプリケーションインタフェース部及び統一インタフェース層の両方にＮｏｔｉｆｙ（）を設けて通信の要求を通知する方法をとることにより、実施例１に比べて両方のインタフェース層の構造を簡単にすることが可能となった。
【実施例３】
【０１０７】
本発明実施例３の画像形成装置について説明する。
【０１０８】
実施例１の画像形成装置では、アプリケーションと通信プロトコルデーモンとの間の通信を全て統一インタフェース層１２１を介して行ったが、ＳＮＭＰ（Simple Network Management Protocol）などの小サイズで多数回の通信が行われるプロトコルでは、統一インタフェース層１２１がライブラリ群により構成されているような比較的オーバヘッドの少ない方法であっても、累積による遅延が問題となる場合がある。そこで、実施例３では特定プロトコルに関しては、統一インタフェース層１２１を経由せずに直接通信プロトコルデーモンとの通信を行う直接インタフェース部（特定プロトコル直接デーモンインタフェース部）を有する画像形成装置について説明する。
【０１０９】
［構成］
実施例３の画像形成装置のハードウェア構成は、実施例１の画像形成装置と同じである。図１でいうところのソフトウェア群１２０部分についてのみ違いがあるので、実施例３のソフトウェア群１２０の構成について図６を用いて説明する。
【０１１０】
図６では、アプリケーションの例として転送アプリケーション１１９を用いて説明するが、他アプリケーションでもその構成は同様である。
【０１１１】
画像形成装置の転送アプリケーション１１９は、大きく分けて通信部に関しての処理を行う通信処理部１１９ｙと転送アプリケーション処理部１１９ｘの二つに分かれる。実施例１の画像形成装置との違いは、通信処理部１１９ｙ中の構成の違いである。実施例１では通信処理部１１９ｙ中にはアプリケーションインタフェース部１１９ｉだけが存在したが、実施例３の画像形成装置では、さらに、プロトコル判断部１１９ｐ及び直接インタフェース部１１９ｄ（特定プロトコル直接デーモンインタフェース部）と、を有する。
【０１１２】
プロトコル判断部１１９ｐは、通信を行うプロトコルが何であるかを判断して、所定のプロトコルの場合は、統一インタフェース層１２１を介しての通信を行うアプリケーションインタフェース部ではなく、直接通信プロトコルデーモンとの通信を行う直接インタフェース部１１９ｄに通信を引き渡す。
【０１１３】
所定のプロトコルとは、前述したように小サイズかつ多数回の通信が行われる実施例３ではＳＮＭＰ通信のプロトコルである。
【０１１４】
直接インタフェース部１１９ｄは、ＳＮＭＰデーモンとの間での直接の通信を行うための通信プロトコルに合わせたインタフェースを有し、統一インタフェース層１２１を介さずに通信を行うためそのオーバヘッドによる遅延が無くなった。
【０１１５】
上記ＳＮＭＰ以外のプロトコルに関しては、実施例１で説明した統一インタフェース層１２１を介しての通信を行う。
【０１１６】
［通信のシーケンス］
図７を用いて実施例３の画像形成装置での、ＳＮＭＰ通信のシーケンスについて説明する。
【０１１７】
図７（Ａ）は、転送アプリケーション１１９からＳＮＭＰデーモン１３５を通して外部装置である画像形成装置２；５０１へのＳＮＭＰでの通信開始要求の説明である。
【０１１８】
Ｓ４１：転送アプリケーション１１９は、直接インタフェースによる画像形成装置２；５０１の機器状態確認のための通信の要求を開始する。転送アプリケーション内部のプロトコル判断部１１９ｐは、プロトコルがＳＮＭＰであると判断して、直接インタフェース１１９ｄを用いてＳＮＭＰプロトコルデーモンに通信開始要求を行う。
【０１１９】
Ｓ４２：ＳＮＭＰデーモンは、Ｓ４１の通信開始要求を受信しＳＮＭＰデーモンでの内部処理を行って、ネットワークインタフェースから送信するためのデータを形成する。
【０１２０】
Ｓ４３：ＳＮＭＰデーモンは、画像形成装置２；５０１にＳＮＭＰでの通信開始の要求を送信する。
【０１２１】
Ｓ４４：画像形成装置２；５０１からのＳＮＭＰでの通信開始の受諾を受信する。
【０１２２】
Ｓ４５：ＳＮＭＰデーモン１３５での内部処理を行って、転送アプリケーション１１９への送信のためのデータ形成を行う。
【０１２３】
Ｓ４６：転送アプリケーション１１９は、直接インタフェース部１１９ｄにより画像形背装置２；５０１の通信開始受諾を受信して、転送アプリケーション内部の処理を開始する。
【０１２４】
次に図７（Ｂ）を用いて、外部装置である画像形成装置２；５０１から画像形成装置１０１へのＳＮＭＰでの通信開始要求がある際のＳＮＭＰデーモン１３５及び転送アプリケーション１１９の動作の流れについて説明する。
【０１２５】
Ｓ５１：ＳＮＭＰデーモン１３５は、画像形成装置２；５０１からＳＮＭＰでの通信開始の要求を受信する。
【０１２６】
Ｓ５２：ＳＮＭＰデーモン１３５内部での処理が行われる。
【０１２７】
Ｓ５３：転送アプリケーション１１９は、Ｓ５２のＳＮＭＰデーモンでの内部処理によるＳＮＭＰの通信開始要求を受信する。
【０１２８】
Ｓ５４：転送アプリケーション１１９は、Ｓ５３の通信開始要求による内部処理を行った後、ＳＮＭＰデーモン１３５に対して、直接インタフェースにより通信開始要求を受諾する旨を送信する。
【０１２９】
Ｓ５５：ＳＮＭＰデーモン１３５は、直接インタフェースによりＳ５４の受諾を受信してその内部処理を行う。
【０１３０】
Ｓ５６：ＳＮＭＰデーモン１３５は、画像形成装置２；５０１に対しＳＮＭＰでの通信開始受諾を送信する。
【０１３１】
Ｓ５７：以降は、ＳＮＭＰでの小サイズ多数回の通信が画像形成装置２；５０１と画像形成装置１０１との間でやりとりが行われ通信が終了する。
【０１３２】
［実施例３の効果］
実施例３の画像形成装置により、統一インタフェース層１２１を用いてアプリケーションの通信部の開発コストを下げることと、ＳＮＭＰのような小サイズかつ多数回の通信が行われるプロトコルに関しては、直接インタフェースにより通信を行うことにより統一インタフェース層でのオーバヘッドによる遅延をなくすことができ、性能とコストを兼ね合わせた画像形成装置を実現することが可能となった。
【０１３３】
［その他］
本発明実施例では、アプリケーションについて機能毎に分かれた複数のアプリケーションからなる構成としたが、全ての機能を含めてひとつのアプリケーションとする構成であってもよい。
【０１３４】
本発明実施例では、アプリケーションとして主要と思われる５つの機能について記載し説明したが、その他の機能のアプリケーションが加わっていても構わないし、又、実施例で示した５機能が全て揃っていない場合であっても構わない。
【０１３５】
同様に本発明実施例では、主要な６つの通信プロトコルデーモンに関して記載し説明したがその他の通信プロトコルに対応していても構わない。又、実施例で示した６プロトコルが全て揃っていない場合であっても構わない。
【０１３６】
本発明実施例では、統一インタフェース層１２１は通信プロトコルデーモン（１３１〜１３６）から呼び出されるプログラムライブラリの集合である構成としたが、統一インタフェース層１２１はアプリケーション（１１１〜１１９）から呼び出されるプログラムライブラリの集合である構成であってもよい。また、通信プロトコルデーモンとアプリケーションとのそれぞれから呼び出されるプログラムライブラリの集合の混合であっても良い。
【０１３７】
また、統一インタフェース層はプログラムライブラリの集合ではなく独立したアプリケーションであっても良い。
【図面の簡単な説明】
【０１３８】
【図１】本発明実施例１の画像形成装置の機能ブロック図である（実施例１、２）。
【図２】本発明実施例１の画像形成装置のアプリケーションインタフェースと統一インタフェース層の詳細図である（実施例１）。
【図３】本発明実施例１の画像形成装置の通信のシーケンス図である（実施例１）。
【図４】本発明実施例２の画像形成装置のアプリケーションインタフェースと統一インタフェース層の詳細図である（実施例２）。
【図５】本発明実施例２の画像形成装置の通信のシーケンス図である（実施例２）。
【図６】本発明実施例３の画像形成装置のソフトウェア層の構造図である（実施例３）。
【図７】本発明実施例３の画像形成装置の通信のシーケンス図である（実施例３）。
【符号の説明】
【０１３９】
１０１ 画像形成装置
１１１ 印刷アプリケーション（アプリケーション）
１１１ｄ 直接インタフェース部（特定プロトコル直接アプリケーションインタフェース部）
１１１ｉ アプリケーションインタフェース部（統一アプリケーションインタフェース）
１１１ｐ プロトコル判断部
１１１ｏ 発呼側Ｏｐｅｎインタフェース（通信の開始のインタフェース）
１１１ｃ 発呼側Ｃｌｏｓｅインタフェース（通信の終了のインタフェース）
１１１ｒ 発呼側Ｒｅａｄインタフェース（データの読取のインタフェース）
１１１ｗ 発呼側Ｗｒｉｔｅインタフェース（データの書込のインタフェース）
１１１ｓ 発呼側ＣｈｅｃｋＳｔａｔｕｓインタフェース（通信状態の把握のインタフェース）
１１１ｒｏ 受信側Ｏｐｅｎインタフェース（通信の開始のインタフェース）
１１１ｒｃ 受信側Ｃｌｏｓｅインタフェース（通信の終了のインタフェース）
１１１ｒｒ 受信側Ｒｅａｄインタフェース（データの読取のインタフェース）
１１１ｒｗ 受信側Ｗｒｉｔｅインタフェース（データの書込のインタフェース）
１１１ｒｓ 受信側ＣｈｅｃｋＳｔａｔｕｓインタフェース（通信状態の把握のインタフェース）
１１３ 複写アプリケーション（アプリケーション）
１１５ ファクスアプリケーション（アプリケーション）
１１７ スキャナアプリケーション（アプリケーション）
１１９ 転送アプリケーション（アプリケーション）
１１９ｐ プロトコル判断部（実施例３）
１２０ ソフトウェア群
１２１ 統一インタフェース層
１２１ａｌ アプリ統一インタフェースライブラリ群
１２１ｄｌ 通信デーモンプロトコルライブラリ群
１３１ ＵＳＢデーモン（通信プロトコルデーモン）
１３１ｉ デーモンインタフェース部（統一デーモンインタフェース）
１３２ セントロニクスデーモン（通信プロトコルデーモン）
１３２ｉ デーモンインタフェース部（統一デーモンインタフェース）
１３３ 公衆回線網デーモン（通信プロトコルデーモン）
１３３ｉ デーモンインタフェース部（統一デーモンインタフェース）
１３４ ＦＴＰデーモン（通信プロトコルデーモン）
１３４ｉ デーモンインタフェース部（統一デーモンインタフェース）
１３５ ＨＴＴＰデーモン（通信プロトコルデーモン）
１３５ｉ デーモンインタフェース部（統一デーモンインタフェース）
１３６ ＳＮＭＰデーモン（通信プロトコルデーモン）
１３６ｉ デーモンインタフェース部（統一デーモンインタフェース）
１５０ ハードウェア群
１６０ ハードウェアインタフェース群
２０１ ホストＰＣ１（外部装置）
２０２ ホストＰＣ２（外部装置）
２０３ ホストＰＣ３（外部装置）
３０１ ＦＡＸ（外部装置）
４０１ サーバ（外部装置）
５０１ 画像形成装置２（外部装置）
【特許請求の範囲】
【請求項１】
画像形成に関する処理を行うアプリケーションと、複数種の通信プロトコルに従って通信を行う複数種の通信プロトコルデーモンと、を備えて外部装置との間で通信を行う画像形成装置であって、
前記アプリケーションと前記通信プロトコルデーモンとの間でデータの授受を統一したインタフェースにより行う統一インタフェース層を有し、
前記アプリケーションは、前記統一インタフェース層とのデータ授受のための統一アプリケーションインタフェースを備え、
前記通信プロトコルデーモンは、前記統一インタフェース層とのデータ授受のための統一デーモンインタフェースを備える
ことを特徴とする画像形成装置。
【請求項２】
請求項１の画像形成装置であって、
前記統一アプリケーションインタフェースは、前記通信プロトコルデーモンから呼びだされるプログラムライブラリの集合と、前記アプリケーションから呼びだされるプログラムライブラリの集合との少なくとも一方から構成される
ことを特徴とする画像形成装置。
【請求項３】
請求項１の画像形成装置であって、
前記統一アプリケーションインタフェースは、独立したアプリケーションから構成される
ことを特徴とする画像形成装置。
【請求項４】
請求項１から３のいずれかの画像形成装置であって、
前記アプリケーション層の前記統一アプリケーションインタフェースは、前記アプリケーションと前記通信プロトコルデーモンとの間での、双方向の通信の開始と、通信の終了と、データの読取と、データの書込と、通信状態の把握とに関するインタフェースを有する
ことを特徴とする画像形成装置。
【請求項５】
請求項１から４のいずれかの画像形成装置であって、
前記アプリケーションは、通信が所定のプロトコルであるかどうかを判断するプロトコル判断部と、
前記プロトコル判断部で所定のプロトコルと判断された場合には、該プロトコルの通信を受け持つ前記通信プロトコルデーモンとの直接のデータ授受を行う特定プロトコル直接アプリケーションインタフェース部と、を有し、
前記所定のプロトコルを受け持つ前記通信プロトコルデーモンは、前記特定プロトコル直接アプリケーションインタフェース部との間でデータの授受を行う特定プロトコル直接デーモンインタフェース部を有する
ことを特徴とする画像形成装置。
【請求項１】
画像形成に関する処理を行うアプリケーションと、複数種の通信プロトコルに従って通信を行う複数種の通信プロトコルデーモンと、を備えて外部装置との間で通信を行う画像形成装置であって、
前記アプリケーションと前記通信プロトコルデーモンとの間でデータの授受を統一したインタフェースにより行う統一インタフェース層を有し、
前記アプリケーションは、前記統一インタフェース層とのデータ授受のための統一アプリケーションインタフェースを備え、
前記通信プロトコルデーモンは、前記統一インタフェース層とのデータ授受のための統一デーモンインタフェースを備える
ことを特徴とする画像形成装置。
【請求項２】
請求項１の画像形成装置であって、
前記統一アプリケーションインタフェースは、前記通信プロトコルデーモンから呼びだされるプログラムライブラリの集合と、前記アプリケーションから呼びだされるプログラムライブラリの集合との少なくとも一方から構成される
ことを特徴とする画像形成装置。
【請求項３】
請求項１の画像形成装置であって、
前記統一アプリケーションインタフェースは、独立したアプリケーションから構成される
ことを特徴とする画像形成装置。
【請求項４】
請求項１から３のいずれかの画像形成装置であって、
前記アプリケーション層の前記統一アプリケーションインタフェースは、前記アプリケーションと前記通信プロトコルデーモンとの間での、双方向の通信の開始と、通信の終了と、データの読取と、データの書込と、通信状態の把握とに関するインタフェースを有する
ことを特徴とする画像形成装置。
【請求項５】
請求項１から４のいずれかの画像形成装置であって、
前記アプリケーションは、通信が所定のプロトコルであるかどうかを判断するプロトコル判断部と、
前記プロトコル判断部で所定のプロトコルと判断された場合には、該プロトコルの通信を受け持つ前記通信プロトコルデーモンとの直接のデータ授受を行う特定プロトコル直接アプリケーションインタフェース部と、を有し、
前記所定のプロトコルを受け持つ前記通信プロトコルデーモンは、前記特定プロトコル直接アプリケーションインタフェース部との間でデータの授受を行う特定プロトコル直接デーモンインタフェース部を有する
ことを特徴とする画像形成装置。
【図１】
【図２】
【図３】
【図４】
【図５】
【図６】
【図７】
【図２】
【図３】
【図４】
【図５】
【図６】
【図７】
【公開番号】特開２００９−１６９９０５（Ｐ２００９−１６９９０５Ａ）
【公開日】平成２１年７月３０日（２００９．７．３０）
【国際特許分類】
【出願番号】特願２００８−１０３７８（Ｐ２００８−１０３７８）
【出願日】平成２０年１月２１日（２００８．１．２１）
【出願人】（０００００６１５０）京セラミタ株式会社 (13,173)
【Ｆターム（参考）】
【公開日】平成２１年７月３０日（２００９．７．３０）
【国際特許分類】
【出願日】平成２０年１月２１日（２００８．１．２１）
【出願人】（０００００６１５０）京セラミタ株式会社 (13,173)
【Ｆターム（参考）】
[ Back to top ]