JP2004129220A

JP2004129220A - Image forming apparatus and version check method

Info

Publication number: JP2004129220A
Application number: JP2003195193A
Authority: JP
Inventors: Kunihiro Akiyoshi; 秋吉　邦洋; Hiroyuki Tanaka; 田中　浩行; Mitsuo Ando; 安藤　光男
Original assignee: Ricoh Co Ltd
Current assignee: Ricoh Co Ltd
Priority date: 2002-07-31
Filing date: 2003-07-10
Publication date: 2004-04-22

Abstract

<P>PROBLEM TO BE SOLVED: To check a difference between a version of an API in a system side service such as a control service and a version of an API to be used by an application. <P>SOLUTION: In the image forming apparatus equipped with an application for performing processes on image forming and a system service for performing processes of a system side on the basis of a request by using an API from the application, the apparatus is provided with an acquisition means for obtaining version information of APIs used by the application for the system service and version information of APIs of the system service, and a comparison means for comparing, API by API, versions of te APIs used by the application for the system service with versions of the APIs of the system service. <P>COPYRIGHT: (C)2004,JPO

Description

【０００１】
【発明の属する技術分野】
この発明は、コピー、プリンタ、スキャナおよびファクシミリなどの画像形成処理にかかるユーザサービスを提供するアプリケーションのバージョン不整合による不具合発生を未然に防止することを可能とする技術に関する。
【０００２】
【従来の技術】
近年では、プリンタ、コピー、ファクシミリ、スキャナなどの各装置の機能を１つの筐体内に収納した画像形成装置（以下、「複合機」という。）が知られている。この複合機は、１つの筐体内に表示部、印刷部および撮像部などを設けるとともに、プリンタ、コピーおよびファクシミリ装置にそれぞれ対応した３種類のソフトウェアを設け、これらのソフトウェアを切り替えることによって、当該装置をプリンタ、コピー、スキャナまたはファクシミリ装置として動作させるものである。
【０００３】
このような従来の複合機では、プリンタ、コピー、ファクシミリ、スキャナなどの各機能単位でアプリケーションプログラムが起動され、ハードウェア資源にアクセスする機能を持ち合わせている。その際、アプリケーションプログラムが前提とするオペレーティングシステム（ＯＳ）と、実際のオペレーティングシステム（ＯＳ）のバージョンが同じことが前提となるが、例えば、ＯＳがバージョンアップして、アプリケーションとの間でバージョン差が生じた場合、今まで使えていた機能が使えなくなったり、アプリケーションそのものが起動しなくなったりすることがある。
【０００４】
このため、従来の複合機では、ＯＳがバージョンアップされた場合、それに伴ってアプリケーションをコンパイルし直すなどして、常に整合性のとれたバージョン関係にあることが要請されている。
【０００５】
【特許文献１】
特開２００２−８２８０６号公報
【０００６】
【発明が解決しようとする課題】
ところで、このような従来の複合機では、プリンタ、コピー、スキャナおよびファクシミリ装置に対応するソフトウェアをそれぞれ別個に設けているため、各ソフトウェアの開発に多大の時間を要する。このため、出願人は、表示部、印刷部および撮像部などの画像形成処理で使用されるハードウェア資源を有し、プリンタ、コピーまたはファクシミリなどの各ユーザサービスにそれぞれ固有の処理を行うアプリケーションを複数搭載し、これらのアプリケーションとハードウェア資源との間に介在して、ユーザサービスを提供する際に、アプリケーションの少なくとも２つが共通的に必要とするハードウェア資源の管理、実行制御並びに画像形成処理を行う各種コントロールサービスからなるプラットホームを備えた画像形成装置（複合機）を発明した。
【０００７】
このような新規な複合機では、アプリケーションとコントロールサービスが別個に設けられているため、複合機の出荷後にユーザもしくは第三者であるサードベンダが新規なアプリケーションを開発して複合機に搭載することが可能であり、これによって多種多様な機能を提供することが可能となっている。
【０００８】
このような新規な複合機では、アプリケーションの少なくとも２つが共通的に必要とするサービスを提供するコントロールサービスがアプリケーションと別個に設けられているので、新規アプリケーションを開発する場合、各種コントロールサービスとのプロセス間通信を実現する処理をソースコードで記述する必要がある。
【０００９】
そして、新規アプリケーションを開発する場合は、各コントロールサービスが提供するアプリケーションプログラムインタフェース（ＡＰＩ：関数、イベントを含む）を正確に把握した上で開発しなければならない。しかし、各コントロールサービスのアプリケーションプログラムインタフェース（ＡＰＩ）がデバッグや機能追加によってバージョンアップが繰り返されると、ベンダーはどのバージョンに合わせてアプリケーション開発をすればよいかが非常に分かり難くなり、アプリが使用するＡＰＩのバージョンとコントロールサービスにおけるＡＰＩのバージョンとが異なる場合も生じ得る。この場合にアプリを実行するとエラーが発生し、複合機のシステムに影響を及ぼす恐れがある。
【００１０】
このことは、固定的な複数の機能を寄せ集めた従来の複合機では問題にならなかった新規な課題である。また、上記コントロールサービス以外にも、アプリケーションにＡＰＩを用いてサービスを提供するモジュールが導入された場合には、同様の問題がある。
【００１１】
この発明は上記に鑑みてなされたもので、コントロールサービスなどのシステム側のサービスにおけるＡＰＩのバージョンと、アプリケーションが使用するＡＰＩのバージョンの違いをチェックする技術を提供することを目的とする。
【００１２】
【課題を解決するための手段】
上記目的を達成するため、請求項１に記載の発明は、画像形成処理に関する処理を行うアプリケーションと、前記アプリケーションからのＡＰＩを用いた要求に基づきシステム側の処理を行うシステムサービスとを備えた画像形成装置であって、前記アプリケーションがシステムサービスに対して使用するＡＰＩのバージョン情報と、当該システムサービスが有するＡＰＩのバージョン情報を取得する取得手段と、前記アプリケーションが前記システムサービスに対して使用するＡＰＩのバージョンを、ＡＰＩ単位に、前記システムサービスが有するＡＰＩのバージョンと比較する比較手段とを有する。
【００１３】
本発明によれば、アプリが使用するＡＰＩ単位毎のバージョン情報とシステムサービスのＡＰＩ単位毎のバージョン情報を取得し、対応するＡＰＩ同士のバージョンが同じか否かをチェックする。ＡＰＩ単位にチェックするので、例えば、アプリが使用していないシステムサービス側のＡＰＩが変更、追加、あるいは削除されて、システムサービスのＡＰＩ全体のバージョンが変わっても、アプリの動作に影響を与えないことを判断できる。
【００１４】
請求項２に記載の発明は、請求項１の記載において、前記アプリケーションが前記システムサービスに対して使用するＡＰＩのセットのバージョンと、前記システムサービスが有するＡＰＩのセットのバージョンとを比較する手段を更に有し、ＡＰＩのセットのバージョンが異なっている場合にのみ、前記比較手段による比較を行う。
【００１５】
本発明によれば、ＡＰＩのセットのバージョンが異なっている場合にのみＡＰＩ単位の比較を行うので、効率良くバージョンチェックを行うことができる。
【００１６】
請求項３に記載の発明は、請求項１の記載において、前記アプリケーションは、前記システムサービスに対して使用するＡＰＩのバージョン情報を、前記アプリケーションの実行プログラム中に備え、前記取得手段が、当該ＡＰＩのバージョン情報を、前記アプリケーションから取得する。
【００１７】
本発明によれば、ＡＰＩのバージョン情報を、アプリケーションの実行プログラム中に備えるので、アプリケーションからバージョン情報を取得することができる。
【００１８】
請求項４に記載の発明は、請求項３の記載において、前記アプリケーションから前記バージョン情報を取得するために前記アプリケーションを仮起動させるものである。本発明によれば、通常起動をする場合と比較して、画像形成装置のリソースを実質的に確保することがないので効率的にバージョンチェックすることができる。また、通常起動をすることなくバージョンチェックをすることができるので、通常起動することにより画像形成装置に影響を及ぼす恐れがなくなる。
【００１９】
請求項５に記載の発明は、請求項３の記載において、前記システムサービスは複数のシステムサービスを含み、前記アプリケーションは、当該複数のシステムサービスに対して使用するＡＰＩのバージョン情報を、システムサービス毎に備え、前記取得手段は、前記アプリケーションからあるシステムサービスに対応するＡＰＩのバージョン情報を取得した場合に、当該システムサービスから、当該システムサービスが有するＡＰＩのバージョン情報を取得する。
【００２０】
本発明によれば、アプリが使用する複数のシステムサービスに対してＡＰＩのバージョンチェックを行うことが可能となる。
【００２１】
請求項６に記載の発明は、請求項１の記載において、前記アプリケーションが前記システムサービスに対して使用するＡＰＩのバージョン情報を格納したファイルを備え、前記取得手段が、当該ＡＰＩのバージョン情報を、前記ファイルから取得する。本発明によれば、バージョン情報を記録したファイルを画像形成装置に格納しておくことによりバージョンチェックが可能となる。
【００２２】
請求項７に記載の発明は、請求項１の記載において、前記比較手段による比較を前記アプリケーションのインストール前に行う場合において、前記アプリケーションが前記システムサービスに対して使用する全てのＡＰＩのバージョンが、前記システムサービスが有する対応するＡＰＩのバージョンと一致する場合に、当該アプリケーションがインストール可能であることを表示する。
【００２３】
本発明によれば、バージョンチェックの結果、どのアプリケーションをインストールしてよいかを確認することができる。
【００２４】
請求項８に記載の発明は、請求項１ないし７のうちいずれか１項の記載において、前記画像形成装置は、前記画像形成装置におけるハードウェア資源の制御を行うコントロールサービスと、コントロールサービスをサーバとしたクライアントプロセスとして動作し、前記アプリケーションをクライアントとしたサーバプロセスとして動作する仮想アプリケーションサービスとを有し、前記システムサービスは、アプリケーションからのＡＰＩを用いた要求を受信するコントロールサービスと、前記仮想アプリケーションサービスを含む。
【００２５】
また、請求項９に記載の発明は、請求項８の記載において、前記仮想アプリケーションサービスは前記取得手段及び前記比較手段を有するものである。
【００２６】
請求項１０〜１８に記載の発明は、上記の画像形成装置が実行するバージョンチェック方法の発明であり、請求項１９〜２３に記載の発明は、画像形成装置にバージョンチェックの処理を実行させるプログラムの発明である。
【００２７】
請求項２４に記載の発明は、画像形成処理に関する処理を行うアプリケーションからの要求に基づきシステム側の処理を行うシステムサービスを備えた画像形成装置で実行される当該アプリケーションのプログラムであって、画像形成装置に、前記システムサービスからの要求に基づき、仮起動するか通常起動するかを判断する手順と、仮起動の場合に、前記システムサービスと通信することにより、アプリケーションに関する情報を前記システムサービスに提供する手順とを実行させるプログラムである。
【００２８】
本発明によれば、仮起動をすることができるアプリケーションを提供することが可能となる。
【００２９】
請求項２５に記載の発明は、上記のプログラムを記録したコンピュータ読み取り可能な記録媒体である。
【００３０】
【発明の実施の形態】
以下に添付図面を参照して、この発明の実施の形態にかかる画像形成装置の好適な実施の形態を詳細に説明する。
【００３１】
（実施の形態１）
図１は、この発明の実施の形態１である画像形成装置（以下、「複合機」という）の構成を示すブロック図である。図１に示すように、複合機１００は、白黒レーザプリンタ（Ｂ＆Ｗ　ＬＰ）１０１と、カラーレーザプリンタ（Ｃｏｌｏｒ　ＬＰ）１０２と、スキャナ、ファクシミリ、ハードディスク、メモリ、ネットワークインタフェースなどのハードウェアリソース１０３を有するとともに、プラットホーム１２０とアプリケーション１３０と仮想アプリケーションサービス（ＶＡＳ：Ｖｉ　ｒｔｕａｌ　Ａｐｐｌｉｃａｔｉｏｎ　Ｓｅｒｖｉｃｅ）１４０から構成されるソフトウェア群１１０とを備えている。
【００３２】
仮想アプリケーションサービス（ＶＡＳ）１４０は、アプリケーション１３０とプラットホーム１２０の間に配置される。ＶＡＳ１４０は、アプリケーション（以下、アプリともいう）１３０の各アプリが初めて登録されるときに、同時に登録処理が行われ、アプリから見るとプラットホーム１２０のサービス層として認識され、サービス層から見るとアプリとして認識されるように登録される。すなわち、ＶＡＳ１４０は、コントロールサービスをサーバとしたクライアントプロセスとして動作し、かつアプリケーションをクライアントとしたサーバプロセスとして動作するものである。
【００３３】
このＶＡＳ１４０はその基本機能としてラッピング機能を備えている。この機能により、アプリ１３０とプラットホーム１２０との間のバージョン差を吸収すると共に、コントロールサービスからのメッセージを取捨選択してプラットホーム１２０を意図的に隠蔽することができる。また、アプリ１３０とコントロールサービスとの間で隠蔽すべきＡＰＩを隠蔽し、特定のＡＰＩだけを開示して重要なＡＰＩの秘匿性を確保することができる。
【００３４】
しかし、バージョン差を吸収するラッピング機能があったとしても、ＶＡＳ１４０についてはコントロールサービス側と整合性がとれるようにバージョンアップが行われるので、アプリケーションとＶＡＳ１４０との間でバージョンの不整合が生じる恐れがあり、その場合、実行時におけるエラーが発生する。
【００３５】
そこで、実行時におけるエラー発生を防止するため、アプリとＶＡＳ１４０の全体バージョン同士を比較して、バージョンが一致しているか否かをチェックする機能を有している。
【００３６】
なお、ここで、ＶＡＳ１４０の全体バージョンとは、ＶＡＳ１４０が提供するＡＰＩのセットのバージョンであり、アプリの全体バージョンとは、アプリがＶＡＳ１４０に対して使用するＡＰＩのセットのバージョンである。
【００３７】
また、アプリがＶＡＳ１４０に対して使用するＡＰＩ毎のバージョンをチェックする機能も有している。この機能を有することにより、アプリとＶＡＳの全体バージョンが違っていても、各ＡＰＩ同士を比較することにより、アプリケーションが動作できると判断した場合には、バージョンの整合性がとれていると判断することができる。
【００３８】
プラットホーム１２０は、アプリケーションからの処理要求を解釈してハードウェア資源の獲得要求を発生させるコントロールサービスと、一または複数のハードウェア資源の管理を行い、コントロールサービスからの獲得要求を調停するシステムリソースマネージャ（ＳＲＭ）１２３と、汎用ＯＳ１２１とを有する。
【００３９】
コントロールサービスは、複数のサービスモジュールから形成され、ＳＣＳ（システムコントロールサービス）１２２と、ＥＣＳ（エンジンコントロールサービス）１２４と、ＭＣＳ（メモリコントロールサービス）１２５と、ＯＣＳ（オペレーションパネルコントロールサービス）１２６と、ＦＣＳ（ファックスコントロールサービス）１２７と、ＮＣＳ（ネットワークコントロールサービス）１２８とから構成される。
【００４０】
また、このプラットホーム１２０における各サービスは、前記アプリケーション１３０からの処理要求を受信し、所定のサービスをアプリケーションに提供するためのアプリケーションプログラムインタフェース（ＡＰＩ）を有している。なお、本明細書では、上記サービスを提供するための関数の他、アプリケーションからプラットフォーム１２０側に通知されるイベント、プラットフォーム１２０側からアプリケーションに通知されるイベントを含めてＡＰＩと称することとする。
【００４１】
汎用ＯＳ１２１は、ＵＮＩＸ（登録商標）などの汎用オペレーティングシステムであり、プラットホーム１２０並びにアプリケーション１３０の各ソフトウェアをそれぞれプロセスとして並列実行する。
【００４２】
ＳＲＭ１２３のプロセスは、ＳＣＳ１２２とともにシステムの制御およびリソースの管理を行うものである。ＳＲＭ１２３のプロセスは、スキャナ部やプリンタ部などのエンジン、メモリ、ＨＤＤファイル、ホストＩ／Ｏ（セントロＩ／Ｆ、ネットワークＩ／Ｆ、ＩＥＥＥ１３９４　Ｉ／Ｆ、ＲＳ２３２Ｃ　Ｉ／Ｆなど）のハードウェア資源を利用する上位層からの要求にしたがって調停を行い、実行を制御する。
【００４３】
具体的には、このＳＲＭ１２３は、要求されたハードウェア資源の利用が可能であるか（他の要求により利用されていないかどうか）を判断し、利用可能であれば要求されたハードウェア資源が利用可能である旨を上位層に伝える。また、ＳＲＭ１２３は、上位層からの要求に対してハードウェア資源の利用スケジューリングを行い、要求内容（例えば、プリンタエンジンにより紙搬送と作像動作、メモリ確保、ファイル生成など）を直接実施している。
【００４４】
ＳＣＳ１２２のプロセスは、アプリ管理、操作部制御、システム画面表示、ＬＥＤ表示、リソース管理、割り込みアプリ制御などを行う。
【００４５】
ＥＣＳ１２４のプロセスは、白黒レーザプリンタ（Ｂ＆Ｗ　ＬＰ）１０１、カラーレーザプリンタＣｏｌｏｒ　ＬＰ）１０２、スキャナ、ファクシミリなどからなるハードウェアリソース１０３のエンジンの制御を行う。
【００４６】
ＭＣＳ１２５のプロセスは、画像メモリの取得および解放、ハードディスク装置（ＨＤＤ）の利用、画像データの圧縮および伸張などを行う。
【００４７】
ＦＣＳ１２７のプロセスは、システムコントローラの各アプリ層からＰＳＴＮ／ＩＳＤＮ網を利用したファクシミリ送受信、ＢＫＭ（バックアップＳＲＡＭ）　で管理されている各種ファクシミリデータの登録／引用、ファクシミリ読みとり、ファクシミリ受信印刷、融合送受信を行うためのＡＰＩを提供する。
【００４８】
ＮＣＳ１２８のプロセスは、ネットワークＩ／Ｏを必要とするアプリケーションに対して共通に利用できるサービスを提供するためのプロセスであり、ネットワーク側から各プロトコルによって受信したデータを各アプリケーションに振り分けたり、アプリケーションからデータをネットワーク側に送信する際の仲介を行う。具体的には、ｆｔｐｄ，　ｈｔｔｐｄ，　ｌｐｄ，　ｓｎｍｐｄ，　ｔｅｌｎｅｔｄ，　ｓｍｔｐｄなどのサーバデーモンや、同プロトコルのクライアント機能などを有している。
【００４９】
ＯＣＳ１２６のプロセスは、オペレータ（ユーザ）と本体間の情報伝達手段となるオペレーションパネル（操作パネル）の制御を行う。ＯＣＳ１２６は、オペレーションパネルからキー押下をキーイベントとして取得し、取得したキーに対応したキーイベント関数をＳＣＳ１２２に送信するＯＣＳプロセスの部分と、アプリケーション１３０またはコントロールサービスからの要求によりオペレーションパネルに各種画面を描画出力する描画関数やその他オペレーションパネルに対する制御を行う関数などが予め登録されたＯＣＳライブラリの部分とから構成される。このＯＣＳライブラリは、アプリケーション１３０およびコントロールサービスの各モジュールにリンクされて実装されている。なお、ＯＣＳ１２６のすべてをプロセスとして動作させるように構成しても良く、あるいはＯＣＳ１２６のすべてをＯＣＳライブラリとして構成しても良い。
【００５０】
アプリケーション１３０は、ページ記述言語（ＰＤＬ）、ＰＣＬおよびポストスクリプト（ＰＳ）を有するプリンタ用のアプリケーションであるプリンタアプリ１１１と、コピー用アプリケーションであるコピーアプリ１１２と、ファクシミリ用アプリケーションであるファックスアプリ１１３と、スキャナ用アプリケーションであるスキャナアプリ１１４と、ネットワークファイル用アプリケーションであるネットファイルアプリ１１５と、工程検査用アプリケーションである工程検査アプリ１１６とを有している。これらの各アプリは、その起動時にＶＡＳ１４０に対して自プロセスのプロセスＩＤとともにアプリ登録要求メッセージを送信し、アプリ登録要求メッセージを受信したＶＡＳ１４０によって、起動したアプリに対する登録が行われるようになっている。
【００５１】
アプリケーション１３０の各プロセス、コントロールサービスの各プロセスは、関数呼び出しとその戻り値送信およびメッセージの送受信によってプロセス間通信を行いながら、コピー、プリンタ、スキャナ、ファクシミリなどの画像形成処理にかかるユーザサービスを実現している。
【００５２】
このように、実施の形態１にかかる複合機１００には、複数のアプリケーション１３０および複数のコントロールサービスが存在し、いずれもプロセスとして動作している。そして、これらの各プロセス内部には、一または複数のスレッドが生成されて、スレッド単位の並列実行が行われる。そして、コントロールサービスがアプリケーション１３０に対し共通サービスを提供しており、このため、これらの多数のプロセスが並列動作、およびスレッドの並列動作を行って互いにプロセス間通信を行って協調動作をしながら、コピー、プリンタ、スキャナ、ファクシミリなどの画像形成処理にかかるユーザサービスを提供するようになっている。また、複合機１００には、サードベンダなどの第三者がコントロールサービス層の上のアプリケーション層に新規アプリ１１７、１１８を開発して搭載することが可能となっている。図１では、この新規アプリ１１７、１１８を搭載した例を示している。
【００５３】
なお、実施の形態１にかかる複合機１００では、複数のアプリケーション１３０のプロセスと複数のコントロールサービスのプロセスとが動作しているが、アプリケーション１３０とコントロールサービスのプロセスをそれぞれ単一の構成とすることも可能である。また、各アプリケーション１３０は、アプリケーションごとに追加または削除することができる。
【００５４】
図２に複合機１００のハードウェア構成例を示す。
【００５５】
複合機１００は、コントローラ１６０と、オペレーションパネル１７５と、ファックスコントロールユニット（ＦＣＵ）１７６と、プリンタ等の画像形成処理に特有のハードウェア資源であるエンジン部１７７とを含む。コントローラ１６０は、ＣＰＵ１６１と、システムメモリ１６２と、ノースブリッジ（ＮＢ）１６３と、サウスブリッジ（ＳＢ）１６４と、ＡＳＩＣ１６６と、ローカルメモリ１６７と、ＨＤＤ１６８と、ネットワークインターフェースカード（ＮＩＣ）１６９と、ＳＤカード用スロット１７０と、ＵＳＢデバイス１７１と、ＩＥＥＥ１３９４デバイス１７２と、セントロニクス１７３とを含む。なお、メモリ１６２、１６７はＲＡＭ、ＲＯＭ等を含む。ＦＣＵ１７６およびエンジン部１７７は、コントローラ１６０のＡＳＩＣ１６６にＰＣＩバス１７８で接続されている。
【００５６】
ＣＰＵ１６１が、複合機１００にインストールされるアプリケーション、コントロールサービス等のプログラムを、メモリから読み出して実行する。
【００５７】
図３は、実施の形態１にかかる複合機１００のＶＡＳ１４０の構成と、ＶＡＳ１４０と各アプリ、コントロールサービス層１５０および汎用ＯＳ１２１との関係を示すブロック図である。なお、図３では、アプリケーション１３０の例として、プリンタアプリ１１１、コピーアプリ１１２、新規アプリ１１７、１１８を示しているが、他のアプリでも同様の構成である。
【００５８】
仮想アプリケーションサービス（ＶＡＳ）１４０のプロセスには、ディスパッチャ１４５と、制御スレッド１４４と、バージョン情報取得スレッド１４３と、全体バージョンチェックスレッド１４２と、ＡＰＩ単位バージョンチェックスレッド１４１とが動作している。また、アプリは使用ＡＰＩテーブル２１２を有し、ＶＡＳ１４０は全ＡＰＩテーブル２１１を有している。なお、アプリケーションの起動（仮起動含む）時、ＶＡＳ１４０の起動時には、使用ＡＰＩテーブル２１２、全ＡＰＩテーブル２１１はそれぞれ、例えば、ＲＡＭ２１０に展開される。
【００５９】
ディスパッチャ１４５は、アプリケーション１３０やコントロールサービスからのメッセージ受信を監視し、受信したメッセージに応じて制御スレッド１４４、バージョン情報取得スレッド１４３、全体バージョンチェックスレッド１４２、ＡＰＩ単位バージョンチェックスレッド１４１に処理要求を行うものである。実施の形態１の複合機１００では、ディスパッチャ１４５により、仮起動もしくは通常起動したアプリとＶＡＳ１４０との間で行われるプロセス間通信を行うことができる。なお、仮起動とは、アプリケーションとＶＡＳとが通信をするためだけにアプリケーションを仮に起動することであり、詳細については後述する。
【００６０】
制御スレッド１４４は、ディスパッチャ１４４を介して送られてくる各アプリが使用するＡＰＩ単位毎のバージョン情報や各アプリの全体バージョン情報などを、全体バージョンチェックスレッド１４２、ＡＰＩ単位バージョンチェックスレッド１４１にそれぞれ渡したり、各スレッド１４１〜１４３間における処理順序を制御したり、各スレッド１４１〜１４３からの処理要求をディスパッチャ１４５に伝えたりする。
【００６１】
また、ＡＰＩ単位バージョンチェックスレッド１４１は、アプリがＶＡＳ１４０に対して使用するＡＰＩ単位毎のバージョン情報と、ＶＡＳ１４０の全ＡＰＩ単位毎のバージョン情報とを取得して、対応するＡＰＩ同士のバージョンを比較して、同じか否かをチェックするものである。
【００６２】
また、全体バージョンチェックスレッド１４２は、各アプリ毎の全体バージョン情報と、ＶＡＳ１４０の全体バージョン情報とを取得して、全体バージョン同士が同じか否かをチェックするものである。このスレッドの機能を有することにより、まず全体バージョン同士を比較して、全体バージョン同士が同じであれば整合性が有りと言えるので、ＡＰＩ単位毎のバージョンチェックを行う必要がなくなり、処理を簡略化することができる。そして、ＡＰＩ単位毎のバージョンチェックは、全体バージョンが違っている場合にのみ行えばよい。
【００６３】
バージョン情報取得スレッド１４３は、ＡＰＩ単位バージョンチェックスレッド１４１で必要なアプリが使用するＡＰＩ単位毎のバージョン情報とＶＡＳのＡＰＩ単位毎のバージョン情報を取得したり、全体バージョンチェックスレッド１４２で必要なアプリの全体バージョン情報とＶＡＳの全体バージョン情報を取得するものである。
【００６４】
本実施の形態では、新規アプリのインストール時にバージョンチェックを行うが、まだアプリが起動されていないためプロセス間通信を使って情報を取得することができない。従って、バージョン情報取得スレッド１４３は、対象となるアプリを仮起動させて、プロセス間通信によりアプリから必要な情報を取得する。なお、アプリから取得する情報として、ＡＰＩ単位毎のバージョン情報以外にもプロダクトＩＤ（ベンダー、アプリ、バージョンから一義的に決定される）、ベンダー名、アプリケーション名、全体バージョン、リソース情報等を取得することも可能である。
【００６５】
なお、図３のように複数のスレッド１４１〜１４４を用いる構成とする代わりに、スレッド１４１〜１４４を１つのスレッドとして構成してもよい。その場合、その１つのスレッドが、本実施の形態におけるバージョンチェックの一連の処理（バージョン情報取得、バージョンチェック）を実行する。なお、ＶＡＳ１４０のプログラムは、ＳＤカード、ＣＤ−ＲＯＭ等の記録媒体に格納して配布できる。また、ネットワークを介して配布することもできる。また、このプログラムは、例えば、ＳＤカードを複合機に挿入することにより複合機にインストールすることができる。また、ＳＤカードから起動することもできる。
【００６６】
図４は、本発明のバージョンチェックの方法の概要を説明するための図である。図４に示すように、アプリケーションの実行ファイルに当該アプリケーションがＶＡＳ１４０に対して使用するＡＰＩのバージョン情報（バージョンテーブル）を含めておく。同様に、ＶＡＳ１４０の実行ファイルにも、ＶＡＳが有しているＡＰＩのバージョン情報（バージョンテーブル）を含めておく。なお、一般に、アプリケーションがＶＡＳ１４０に対して使用する複数のＡＰＩは、ＶＡＳ１４０が有している複数のＡＰＩの一部である。
【００６７】
ＶＡＳ１４０が有するＡＰＩのバージョン情報は、ＡＰＩ毎のバージョンと、ＡＰＩのセットとしてのバージョンである。また、アプリケーションが有するバージョン情報は、ＡＰＩ毎のバージョンと、ＡＰＩのセットとしてのバージョンを有している。アプリケーションが使用するＡＰＩセットのバージョンは、アプリケーションを作成するときに使用したＶＡＳのＡＰＩセットのバージョンと同じである。
【００６８】
実行ファイルにバージョン情報を含めるには、例えば、図４に示すように、バージョン情報をインクルードファイルとして作成しておき、作成したプログラムにインクルードしてコンパイルする。
【００６９】
ＶＡＳ１４０は、仮起動されたアプリからプロセス間通信によりアプリが使用するＡＰＩのバージョン情報を取得し、当該バージョン情報と、ＶＡＳが有するＡＰＩのバージョン情報とをＡＰＩ毎に比較して、アプリケーションがインストール可能かどうかを判断する。また、ＡＰＩセットのバージョン同士を比較し、これらが異なる場合にのみＡＰＩ毎のバージョン比較をしてもよい。なお、ＶＡＳ１４０は、アプリが使用するバージョン情報のテーブル全体を取得して比較処理を行ってもよいし、アプリが使用するＡＰＩのバージョン情報をＡＰＩ毎に１つずつ取得して対応するＡＰＩバージョンとの比較を行ってもよい。
【００７０】
更に、上記のようにバージョン情報を実行ファイルに含める代わりに、アプリのバージョン情報を別ファイルとして複合機１００に格納しておき、ＶＡＳ１４０がそのファイルを参照するようにしてもよい。
【００７１】
バージョン情報はＶＡＳが参照できさえすればよく、バージョン情報を複合機１００内に保持する方法は上記の方法以外の種々の方法を用いることができる。
【００７２】
さて、アプリが作成された後に、ＶＡＳ１４０のＡＰＩセットのバージョンが上がり、アプリが使用するＡＰＩセットのバージョンと、ＶＡＳが有するＡＰＩセットのバージョンとが異なる場合が起こり得る。
【００７３】
例えば、図５の例では、ＡＰＩ　Ｎｏ．＝２５１のバージョンが（１０１）→（１０２）にバージョンアップしたために、ＶＡＳ１４０のＡＰＩセットのバージョンが（１．００）→（１．０１）となっている。
【００７４】
この場合、ＡＰＩセットを比較しただけでは、バージョンが異なるので、アプリとＶＡＳとの整合性がないと判断され得るが、実際には、ＡＰＩ　Ｎｏ．２５１はアプリで使用しないＡＰＩであるため、アプリは問題なく動作できる。従って、ＡＰＩ毎の比較を行うことにより、ＡＰＩセット同士のバージョンが異なっていても、アプリが問題なく動作できると判断できる。
【００７５】
次に、アプリケーションの仮起動について説明する。仮起動は、複合機のリソースを使用することになるアプリの通常起動（アプリ本来の機能を奏するための起動を通常起動と呼ぶ）とは別の起動である。仮起動では、アプリはアプリ本来の動作に必要なメモリ確保等のリソース取得を行わず、ＶＡＳ１４０とのプロセス間通信処理のみを行う。そして、アプリは、ＶＡＳ１４０がバージョンチェックを含むアプリに関するチェックを行うために必要な情報をＶＡＳ１４０に提供する。仮起動したアプリのプロセスは、ＶＡＳ１４０との通信処理が終了すれば終了する。また、アプリの仮起動に関する機能は、アプリ本来の機能によらず、本実施の形態における複合機１００で動作するアプリに共通する機能である。従って、例えば、ベンダーがアプリを開発する場合、ベンダーに、仮起動の機能を含むプログラムテンプレートを提供し、そのプログラムテンプレートを用いてベンダーが複合機用のアプリを開発することができる。なお、上記のバージョンチェックを実現するためには、例えば、ベンダーが、アプリ開発に使用したＡＰＩとそのバージョンを記録したインクルードファイルを作成し、アプリのコンパイル時にインクルードする。
【００７６】
アプリが仮起動の機能を持つことにより、通常起動をすることなくＶＡＳとの通信によりＶＡＳにアプリ情報を提供でき、ＶＡＳがアプリのチェックを行うことができる。従って、ＡＰＩバージョン等の整合性がとれていないアプリを通常起動することによりアプリが異常動作し、複合機に影響を与える恐れがなくなる。
【００７７】
図６に、仮起動の機能を含むアプリのプログラム記述（メイン関数）の概要を示す。なお、この記述を上記のプログラムテンプレートとして提供する。
【００７８】
図６に示すように、このプログラム記述は、アプリケーションを仮起動するか通常起動するかを引数（−ｖ）によって指定する。これにより、ＶＡＳがアプリを起動する際に、通常起動と仮起動とを容易に使い分けることができる。すなわち、引数（−ｖ）を使って仮起動を指定すると、仮起動が実行され、アプリ情報提供処理がなされる。また、仮起動が指定されていない場合は、通常起動を行って、アプリ本来の動作を行う。
【００７９】
なお、後述するアプリ起動時、あるいは、アプリ起動後の実行時にバージョンチェックする場合は、この通常起動処理が選択される。
【００８０】
このように仮起動の機能を有するアプリのプログラムは、ＳＤカード、ＣＤ−ＲＯＭ等の記録媒体に格納して配布できる。また、ネットワークを介して配布することもできる。また、このプログラムは、例えば、ＳＤカードを複合機に挿入することにより複合機にインストールすることができる。また、ＳＤカードから起動することもできる。
【００８１】
次に、アプリインストール時にバージョンチェックを行う場合の複合機の動作について、図７のフローチャートを用いて説明する。図８は、図７の中のバージョンチェック処理のサブルーチンを示すフローチャートである。
【００８２】
まず、図７に示すように、ユーザがオペレーションパネル上のキーやボタンを使ってアプリのインストール処理を選択すると（ステップＳ５０１）、ＳＣＳ（システムコントロールサービス）１２２からＶＡＳ１４０にアプリインストール処理の開始を要求し（ステップＳ５０２）、ＶＡＳ１４０がインストール対象エリア内のアプリを仮起動させる（ステップＳ５０３）。この仮起動は、前述したように、インストールするアプリ内の各種情報をプロセス間通信を使ってＶＡＳ１４０に通知し、ＶＡＳがバージョンチェック処理を行うためのものである（ステップＳ５０４）。
【００８３】
ステップＳ５０４におけるバージョンチェック処理の詳細を図８を用いて説明する。
【００８４】
図８に示すように、アプリから通知された情報にアプリの全体バージョン情報（ＡＰＩセットのバージョン情報）が含まれているか否かを判断し（ステップＳ６０１）、全体バージョン情報が含まれている場合は、ＶＡＳ１４０のＡＰＩの全体バージョンと比較し、同じであれば（ステップＳ６０２）、バージョンの不整合はなく、ＶＡＳ１４０は当該アプリケーションに対して動作保証する（ステップＳ６０３）。なお、動作保証するとは、例えば、当該アプリに対応づけてＡＰＩバージョンに関して問題ない旨のフラグを記録しておくことである。
【００８５】
また、図８のステップＳ６０１もしくはステップＳ６０２おいて、ＮＯであった場合には、ステップＳ６０４に移行し、アプリが使用するＡＰＩのバージョンと、それに対応したＶＡＳ１４０のＡＰＩのバージョンとが、アプリが使用するＡＰＩ毎に１つ１つ比較され、全て同じバージョンであるか否かが判断され、同じであれば上記ステップＳ６０３にてＶＡＳ１４０のサポート範囲内として動作保証する（ステップＳ６０３）。しかしステップＳ６０４でバージョンの異なるＡＰＩがあった場合は、ＶＡＳ１４０のサポート範囲外となるため、その旨を記録する（ステップＳ６０５）。
【００８６】
このように、図８のステップＳ５０４のサブルーチンでバージョンチェック処理を行った後、他にインストール処理を行うアプリが無くなるまで上記ステップＳ５０３に戻り、上記バージョンチェック処理が繰り返される（ステップＳ５０５）。
【００８７】
インストール処理するアプリが無くなった場合は、ステップＳ５０６でインストール時に取得したアプリの情報に基づいてインストール画面をオペレーションパネル上などに生成し、各種情報を表示する（ステップＳ５０６）。例えば、インストール処理された複数のアプリのバージョンチェック結果に基づいて動作保証の有無を表示する。これにより、ユーザは、正式なインストール要求すべきアプリをインストール画面から容易に選択することができ（ステップＳ５０７）、選択されたアプリのみを最終的にインストール処理する（ステップ５０８）。
【００８８】
上記したように、実施の形態１では、アプリのインストール時に、ＶＡＳによってアプリを仮起動させ、プロセス間通信を利用してバージョン情報を含むアプリに関する情報を取得して、バージョンチェック行うことができるので、動作保証されたアプリのみを選択的にインストール処理することができる。
【００８９】
また、インストール時の他、アプリの通常起動時に本発明のバージョンチェック処理を行うことができる。アプリを仮起動させるか通常起動させるかは、図６のメイン関数記述例に示したように、引数（−ｖ）を用いるか否かで決まり、通常起動時にも勿論プロセス間通信を使ってアプリのバージョン情報などが取得できるため、バージョンチェック処理を行うことができる。このアプリの起動時におけるバージョンチェックは、既にインストールされているアプリを初めて起動する場合などに有効である。また、アプリのバージョン情報を別ファイルに持たせておけばプロセス間通信を行わず、ＶＡＳが当該ファイルを参照することによりチェックを行うことができる。
【００９０】
さらに、アプリ起動後の実行時にもバージョンチェック処理を行うことができる。アプリ起動後の実行時には、プロセス間通信が使えるため、アプリの通常起動時におけるバージョンチェックと同じように適切なタイミングでバージョンチェックを行うことができる。
【００９１】
また、アプリの実行時におけるバージョンチェックとして、例えば、アプリ側でＡＰＩの引数の中にバージョン情報を入れておき、そのＡＰＩをアプリが使用するときにＶＡＳ１４０にＡＰＩのバージョンを通知し、ＶＡＳ１４０がそのバージョンをチェックするようにしてもよい。ＶＡＳ１４０が、ＡＰＩのバージョン差があると判断したときは、ＶＡＳ１４０がそのＡＰＩの要求をサービス層まで伝えないようにする。更に、アプリの実行処理を中止し、オペレーションパネル上にエラー表示を行って、ユーザにその旨を通知するようにしてもよい。バージョン差がない場合には、アプリの実行がそのまま継続して行われる。
【００９２】
なお、バージョンチェック処理をＶＡＳ１４０側でなく、アプリ側で行ってもよい。その場合、アプリがＶＡＳ１４０からＶＡＳ１４０の有するＡＰＩのバージョン情報を取得し、バージョンチェック処理を行う。そして、インストール時であればバージョン差があるか否かをＶＡＳ１４０に伝える。また、起動時、実行時であれば、バージョン差がなければ起動もしくは実行を継続し、バージョン差があれば、例えば、その旨のオペレーションパネル上に表示し、処理を終了する。
【００９３】
このように、実施の形態１にかかる複合機では、ＶＡＳ１４０が、アプリが使用するＡＰＩ単位毎のバージョン情報とＶＡＳのＡＰＩ単位毎のバージョン情報を取得し、対応するＡＰＩ同士のバージョンが同じか否かをチェックする。従って、アプリが使用していないＶＡＳ１４０のＡＰＩが変更、追加、あるいは削除されて、ＶＡＳのＡＰＩ全体（ＡＰＩセット）のバージョンが変わっても、両者間の整合性に影響を与えないことを判断できる。全体バージョン同士を単純比較する場合と比べると、ＶＡＳのバージョン差の吸収範囲が広くなって、利用可能なアプリを増やすことができる。
【００９４】
また、実施の形態１にかかる複合機では、ＶＡＳ１４０が最初に全体バージョンを比較し、全体バージョンが異なっている場合のみＡＰＩ単位のバージョンチェックをすることができるので、バージョンチェック処理を効率良く、かつ迅速に行うことができる。また、予め必要なバージョン情報を持たせたアプリの実行ファイルを使うことにより、アプリの仮起動や通常起動の際のプロセス間通信により、ＶＡＳが所望のバージョン情報を取得することができる。
【００９５】
また、アプリのインストール時にバージョンチェックする場合、ＶＡＳ１４０がアプリを仮起動させて、アプリが使用するＡＰＩ単位毎のバージョン情報を得ることができるので、通常起動をする場合と比較して効率的にバージョンチェックすることができる。
【００９６】
（実施の形態２）
次に、実施の形態２について説明する。実施の形態１では、図４に示すように、アプリはアプリがＶＡＳ１４０に対して使用するＡＰＩのバージョン情報を有し、ＶＡＳ１４０はそのバージョン情報をチェックしていた。
【００９７】
さて、複合機におけるＶＡＳ１４０は、図１に示すように全てのコントロールサービスをカバーするのではなく、一部のコントロールサービスのみをカバーするように構成することもできる。実施の形態２では、ＶＡＳ１４０を介さずに直接アプリと通信を行うコントロールサービスに対するＡＰＩのバージョンもチェックできる構成について説明する。なお、以下の説明において、ＶＡＳ、コントロールサービスを含めてそれぞれ“システム”と呼ぶ。
【００９８】
実施の形態２では、図９に示すように、アプリは、ＶＡＳ１４０に対して使用するＡＰＩのバージョン情報の他、ＶＡＳ１４０を介さずに通信を行うコントロールサービスに対して使用するＡＰＩのバージョン情報を有している。ＶＡＳ１４０は、アプリからこれらのバージョン情報を取得し、該当するシステムからそのシステムのＡＰＩのバージョン情報を取得し、バージョン比較を行う。
【００９９】
図９に示すように、アプリは、各システム毎にバージョン情報のテーブルを有していてもよいし、アプリが使用する全システムについてのバージョン情報を１つのテーブルに保持していてもよい。この場合、テーブル内でどのシステムのＡＰＩかは識別できる。図９の場合、各テーブルは、ＡＰＩ毎のバージョンに加えてＡＰＩセットのバージョンも保持している。なお、アプリは、図１０に示すような、システム毎のＡＰＩセットのバージョンを保持したテーブルを持っていてもよい。
【０１００】
なお、図９に示す各バージョン情報は、アプリなどのプログラムの実行ファイル内に保持する他、別ファイルに備えておいてもよい。その場合、ＶＡＳ１４０はプロセス間通信でなく、そのファイルを開くことによりバージョン情報を取得する。バージョン情報を保持するにはその他にも種々の方法が可能である。
【０１０１】
図１１に、図９の構成における、ＶＡＳによるバージョンチェック処理のフローチャートを示す。なお、図１１のフローは、ＶＡＳが、アプリからバージョン情報のテーブルを順次取得することを前提としている。また、インストール時のバージョンチェック処理を示している。
【０１０２】
まず、ＶＡＳがアプリから１つのテーブルを取得する（ステップＳ７０１）。そして、そのテーブルがどのシステムに対応するものであるかを判断する（ステップＳ７０２）。次に、該当するシステムが有するバージョン情報のテーブルをそのシステムから取得する（ステップＳ７０３）。
【０１０３】
次に、アプリから取得したテーブルと、システムから取得したテーブルとを比較し、全バージョン（ＡＰＩセットのバージョン）が一致するか否かを判断する（ステップＳ７０４）。一致する場合には、そのシステムに対してはバージョンが整合している旨を記録する（ステップＳ７０６）。そして、アプリ側から取得すべきテーブルが他に無ければバージョンチェック処理を終了する。他にあればステップＳ７０１からの処理を繰り返す。
【０１０４】
ステップＳ７０４にて、一致していない場合には、アプリがそのシステムに対して使用するＡＰＩ毎にバージョンをチェックする（ステップＳ７０５）。全ＡＰＩのバージョンが同じであれば、そのシステムに対してはバージョンが整合している旨を記録する（ステップＳ７０６）。また、１つでもバージョンの異なるＡＰＩがある場合には、バージョンが整合していない旨を記録する。このとき、どのＡＰＩのバージョンが整合していないかを記録しておいてもよい。そして、アプリ側から取得すべきテーブルが他に無ければバージョンチェック処理を終了する。他にあればステップＳ７０１からの処理を繰り返す。
【０１０５】
バージョンチェック処理が終了した後、ＶＡＳ１４０は、例えば、そのアプリが使用する全てのシステムに対してバージョンが一致していれば、そのアプリがインストール可能であることをオペレーションパネルに表示し、１つでもバージョンの不一致があるシステムがあれば、バージョンに不一致がある旨を表示する。バージョンに不一致がある旨を表示する際、どのシステムのどのＡＰＩに不一致があるかを表示してもよい。
【０１０６】
本実施の形態により、ＶＡＳ１４０に対するＡＰＩのみならず、ＶＡＳ１４０を介さずに通信を行うＡＰＩのバージョンもチェックできる。
【０１０７】
（実施の形態３）
実施の形態１にかかる複合機１００は、ＶＡＳ１４０が全アプリケーションに対して１つのみ存在するものであった。この実施の形態２にかかる複合機９００では、各アプリごとに一つのＶＡＳを起動し、各ＶＡＳは対応するアプリとの間でバージョンチェック処理を行うようにする。
【０１０８】
図１２は、実施の形態３にかかる複合機９００の構成を示すブロック図である。図１２に示すように、複合機９００では、複数の仮想アプリケーションサービス（ＶＡＳ）９４１〜９４８がアプリケーション１３０の各アプリごとに動作している点が、実施の形態１にかかる複合機１００と異なっている。
【０１０９】
ＶＡＳ９４１〜９４８は、プリンタアプリ１１１、コピーアプリ１１２、ファックスアプリ１１３、スキャナアプリ１１４、ネットファイルアプリ１１５、工程検査アプリ１１６、新規アプリ１１７および１１８に対応して、バージョンチェック処理を行う。
【０１１０】
図１３は、実施の形態３にかかる複合機９００のＶＡＳ９４１〜９４８の構成と、ＶＡＳ９４１〜９４８と各アプリ、コントロールサービス層１５０および汎用ＯＳ１２１との関係を示すブロック図である。なお、図１３では、アプリケーション１３０として、プリンタアプリ１１１、コピーアプリ１１２、新規アプリ１１７、１１８の例を示し、さらにこれら各アプリに対応したＶＡＳ９４１、９４２、９４７および９４８を例として示しているが、他のアプリを使用する場合も同様の構成である。
【０１１１】
また、実施の形態３にかかる複合機９００では、実施の形態１の複合機１００と異なり、図１３に示すように、各ＶＡＳ９４１〜９４８と各アプリとの間にはＶＡＳ制御プロセス（デーモン）９０１が動作している。このＶＡＳ制御プロセス（デーモン）９０１は、ＶＡＳが提供する全ＡＰＩのバージョン情報を有している。
【０１１２】
仮想アプリケーションサービス（ＶＡＳ）９４１〜９４８のプロセスは、ディスパッチャ１４５と、ＡＰＩ単位バージョンチェックスレッド１４１と、全体バージョンチェックスレッド１４２と、バージョン情報取得スレッド１４３とが動作している。
【０１１３】
実施の形態３の複合機９００における各スレッドの機能は、実施の形態１で説明したものと同様である。なお、スレッド１４１〜１４３を１つのスレッドとしてもよい。
【０１１４】
また、ＶＡＳの構成として上記の構成の他、図１４（ａ）〜（ｃ）に示す構成をとることもできる。
【０１１５】
図１４（ａ）は、各アプリケーションに対して起動されるＶＡＳを、親ＶＡＳの子プロセスとする場合であり、親ＶＡＳ自体は画面制御権（ユーザインターフェース）を持たない。図１４（ｂ）は、親ＶＡＳ自体が画面制御権（ユーザインターフェース）を持つ場合である。図１４（ｃ）は、各アプリケーションに対応するＶＡＳの機能をスレッドとして起動する場合を示している。
【０１１６】
例えば、図１４（ｃ）の場合において、アプリが本起動していない時点では、アプリ対応のＶＡＳスレッドは起動されていない。アプリのインストール時に、アプリと対応付けられない１つのＶＡＳがアプリの仮起動を行い、バージョンチェックを行う。その後、アプリの本起動時に各アプリに対応したＶＡＳのスレッドが起動される。
【０１１７】
なお、本発明は、上記の実施の形態に限定されることなく、特許請求の範囲内において、種々変更・応用が可能である。
【０１１８】
【発明の効果】
上記のように、本発明によれば、アプリが使用するＡＰＩ単位毎のバージョン情報とＶＡＳ等のシステムサービス側のＡＰＩ単位毎のバージョン情報を比較し、対応するＡＰＩ同士のバージョンが同じか否かをチェックできるので、アプリを正常に使用できるか否かを判断することができる。
【図面の簡単な説明】
【図１】本発明の実施の形態１における複合機のソフトウェア構成を示すブロック図である。
【図２】本発明の実施の形態１における複合機のハードウェア構成を示すブロック図である。
【図３】本発明の実施の形態１における複合機のＶＡＳの構成と各アプリとコントロールサービス層と汎用ＯＳとの関係を示すブロック図である。
【図４】本発明の実施の形態１におけるバージョンチェック方法を説明するための図である。
【図５】本発明の実施の形態１におけるバージョンチェック方法を説明するための図である。
【図６】本発明の実施の形態１における仮起動可能なアプリのプログラム記述例である。
【図７】アプリインストール時におけるバージョンチェックのシーケンスを説明するためのフローチャートである。
【図８】図７の中のバージョンチェック処理を示すフローチャートである。
【図９】本発明の実施の形態２におけるバージョンチェックの方法を説明するための図である。
【図１０】本発明の実施の形態２においてアプリが有するテーブルの例である。
【図１１】本発明の実施の形態２におけるバージョンチェック処理の手順を示すフローチャートである。
【図１２】本発明の実施の形態３における複合機のソフトウェア構成を示すブロック図である。
【図１３】本発明の実施の形態３における複合機のＶＡＳの構成と、ＶＡＳと各アプリ、コントロールサービス層および汎用ＯＳとの関係を示すブロック図である。
【図１４】本発明の実施の形態におけるＶＡＳの構成例を示す図である。
【符号の説明】
１００　複合機
１０１　白黒レーザプリンタ
１０２　カラーレーザプリンタ
１０３　ハードウェアリソース
１１０　ソフトウェア群
１１１　プリンタアプリ
１１２　コピーアプリ
１１３　ファックスアプリ
１１４　スキャナアプリ
１１５　ネットファイルアプリ
１１６　工程検査アプリ
１１７、１１８　新規アプリ
１２０　プラットホーム
１２１　汎用ＯＳ
１２２　ＳＣＳ
１２３　ＳＲＭ
１２４　ＥＣＳ
１２５　ＭＣＳ
１２６　ＯＣＳ
１２７　ＦＣＳ
１２８　ＮＣＳ
１３０　アプリケーション
１４０、９４１〜９４８　仮想アプリケーションサービス（ＶＡＳ）
１４１　ＡＰＩ単位バージョンチェックスレッド
１４２　全体バージョンチェックスレッド
１４３　バージョン情報取得スレッド
１４４　制御スレッド
１４５　ディスパッチャ
１５０　コントロールサービス層
２０１　ラッピング処理情報ファイル
２１０　ＲＡＭ
２１１　全ＡＰＩテーブル
２１２　使用ＡＰＩテーブル
９００　複合機
９０１　ＶＡＳ制御プロセス[0001]
TECHNICAL FIELD OF THE INVENTION
The present invention relates to a technique capable of preventing a problem from occurring due to a version mismatch of an application that provides a user service for image forming processing such as copying, a printer, a scanner, and a facsimile.
[0002]
[Prior art]
2. Description of the Related Art In recent years, an image forming apparatus (hereinafter, referred to as a “multifunction peripheral”) in which functions of respective apparatuses such as a printer, a copier, a facsimile, and a scanner are housed in one housing has been known. This multifunction peripheral is provided with a display unit, a printing unit, an imaging unit, and the like in a single housing, and is provided with three types of software corresponding to a printer, a copying machine, and a facsimile machine, and by switching these softwares, Is operated as a printer, copier, scanner or facsimile machine.
[0003]
In such a conventional multifunction peripheral, an application program is started for each functional unit such as a printer, a copy, a facsimile, and a scanner, and has a function of accessing hardware resources. At this time, it is assumed that the version of the operating system (OS) assumed by the application program is the same as the version of the actual operating system (OS). When this occurs, functions that have been used up to now may not be used, or the application itself may not be started.
[0004]
For this reason, in the conventional multifunction peripheral, when the OS is upgraded, it is required that the application is recompiled in accordance with the upgrade so that the multifunction peripheral always has a consistent version relationship.
[0005]
[Patent Document 1]
JP 2002-82806 A
[Problems to be solved by the invention]
By the way, in such a conventional multifunction peripheral, software corresponding to a printer, a copier, a scanner, and a facsimile machine is separately provided, and therefore, it takes a lot of time to develop each software. For this reason, the applicant has an application that has hardware resources used in image forming processing such as a display unit, a printing unit, and an imaging unit and performs processing specific to each user service such as a printer, a copy or a facsimile. When providing a user service by interposing between a plurality of applications and hardware resources, management, execution control, and image forming processing of hardware resources required by at least two of the applications in common Invented an image forming apparatus (multifunction peripheral) equipped with a platform composed of various control services for performing the following.
[0007]
In such a new MFP, the application and the control service are provided separately. Therefore, after the MFP is shipped, the user or a third-party third party must develop a new application and install it in the MFP. This makes it possible to provide a wide variety of functions.
[0008]
In such a new multifunction peripheral, a control service that provides a service commonly required by at least two of the applications is provided separately from the application. Therefore, when a new application is developed, a process with various control services is performed. It is necessary to describe the process for implementing inter-communication in source code.
[0009]
When a new application is developed, the application program interface (API: including functions and events) provided by each control service must be accurately grasped before development. However, if the version of the application program interface (API) of each control service is repeatedly updated by debugging or adding functions, it becomes very difficult for the vendor to know which version to develop the application for, and the API used by the application becomes difficult. May be different from the API version in the control service. In this case, when the application is executed, an error occurs, which may affect the multifunction peripheral system.
[0010]
This is a new problem which has not been a problem in a conventional multifunction peripheral having a plurality of fixed functions. In addition, there is a similar problem when a module that provides a service to an application using an API other than the control service is introduced.
[0011]
The present invention has been made in view of the above, and an object of the present invention is to provide a technique for checking a difference between an API version in a system service such as a control service and an API version used by an application.
[0012]
[Means for Solving the Problems]
In order to achieve the above object, the invention according to claim 1 provides an image having an application for performing processing related to image forming processing and a system service for performing processing on a system side based on a request using an API from the application. A forming apparatus, comprising: acquisition means for acquiring version information of an API used by the application for a system service, version information of an API included in the system service, and an API used by the application for the system service And a comparing unit that compares, for each API, the version of the API with the version of the API that the system service has.
[0013]
According to the present invention, version information for each API unit used by an application and version information for each API unit of a system service are acquired, and it is checked whether the versions of the corresponding APIs are the same. Since the API is checked in units of API, even if the API of the system service not used by the application is changed, added, or deleted, and the version of the entire API of the system service is changed, the operation of the application is not affected. You can judge that.
[0014]
According to a second aspect of the present invention, in the first aspect, means for comparing a version of a set of APIs used by the application with respect to the system service and a version of the set of APIs possessed by the system service is provided. Further, only when the versions of the set of APIs are different, the comparison by the comparing means is performed.
[0015]
According to the present invention, the API unit comparison is performed only when the API set versions are different, so that the version check can be performed efficiently.
[0016]
According to a third aspect of the present invention, in the first aspect, the application includes, in an execution program of the application, version information of an API used for the system service, and the acquisition unit includes the API. From the application.
[0017]
According to the present invention, since the version information of the API is provided in the execution program of the application, the version information can be acquired from the application.
[0018]
According to a fourth aspect of the present invention, in the third aspect, the application is provisionally activated to acquire the version information from the application. According to the present invention, it is possible to efficiently check the version, since resources of the image forming apparatus are not substantially secured as compared with the case of normal startup. In addition, since the version check can be performed without performing the normal startup, there is no possibility that the normal startup will affect the image forming apparatus.
[0019]
According to a fifth aspect of the present invention, in the third aspect, the system service includes a plurality of system services, and the application transmits version information of an API used for the plurality of system services for each system service. In a case where the acquisition unit acquires version information of an API corresponding to a certain system service from the application, the acquisition unit acquires the API version information of the system service from the system service.
[0020]
According to the present invention, it is possible to check the version of an API for a plurality of system services used by an application.
[0021]
According to a sixth aspect of the present invention, in the first aspect, the application further comprises a file in which version information of an API used by the application for the system service is stored, and wherein the acquisition unit stores the version information of the API, Obtain from the file. According to the present invention, the version check can be performed by storing the file in which the version information is recorded in the image forming apparatus.
[0022]
According to a seventh aspect of the present invention, in the first aspect, when the comparison by the comparing unit is performed before the installation of the application, all API versions used by the application for the system service are: If the version of the corresponding API included in the system service matches, it indicates that the application can be installed.
[0023]
According to the present invention, as a result of the version check, it is possible to confirm which application may be installed.
[0024]
According to an eighth aspect of the present invention, in the image forming apparatus according to any one of the first to seventh aspects, the image forming apparatus includes a control service for controlling hardware resources in the image forming apparatus, and a control service for controlling the hardware resources in the image forming apparatus. A virtual application service that operates as a client process using the application as a client, and a virtual application service that operates as a server process using the application as a client. The system service includes a control service that receives a request using an API from the application, and a virtual application service. Including services.
[0025]
According to a ninth aspect of the present invention, in the ninth aspect, the virtual application service includes the acquisition unit and the comparison unit.
[0026]
The invention according to claims 10 to 18 is an invention of a version check method executed by the image forming apparatus, and the invention according to claims 19 to 23 is a program for causing an image forming apparatus to execute a version check process. Invention.
[0027]
According to a twenty-fourth aspect of the present invention, there is provided a program for an application which is executed by an image forming apparatus having a system service for performing a process on a system side based on a request from an application for performing a process related to an image forming process. A step of determining whether the apparatus is to be provisionally activated or to be normally activated based on a request from the system service, and providing information on an application to the system service by communicating with the system service in the case of the provisional activation. And a program for executing the procedure.
[0028]
According to the present invention, it is possible to provide an application that can be provisionally activated.
[0029]
According to a twenty-fifth aspect of the present invention, there is provided a computer-readable recording medium recording the above-mentioned program.
[0030]
BEST MODE FOR CARRYING OUT THE INVENTION
Hereinafter, preferred embodiments of an image forming apparatus according to an embodiment of the present invention will be described in detail with reference to the accompanying drawings.
[0031]
(Embodiment 1)
FIG. 1 is a block diagram illustrating a configuration of an image forming apparatus (hereinafter, referred to as a “multifunction peripheral”) according to a first embodiment of the present invention. As shown in FIG. 1, the multifunction peripheral 100 includes a black-and-white laser printer (B & W LP) 101, a color laser printer (Color LP) 102, and hardware resources 103 such as a scanner, a facsimile, a hard disk, a memory, and a network interface. In addition, a software group 110 including a platform 120, an application 130, and a virtual application service (VAS: Virtual Application Service) 140 is provided.
[0032]
A virtual application service (VAS) 140 is located between the application 130 and the platform 120. The VAS 140 performs a registration process when each application of the application (hereinafter, also referred to as an application) 130 is registered for the first time, and is recognized as a service layer of the platform 120 when viewed from the application, and as an application when viewed from the service layer. Registered to be recognized. That is, the VAS 140 operates as a client process using the control service as a server, and operates as a server process using the application as a client.
[0033]
The VAS 140 has a wrapping function as its basic function. With this function, the version difference between the application 130 and the platform 120 can be absorbed, and messages from the control service can be selectively selected to conceal the platform 120 intentionally. Further, it is possible to hide an API to be hidden between the application 130 and the control service, and to disclose only a specific API to secure confidentiality of an important API.
[0034]
However, even if there is a wrapping function that absorbs the version difference, the VAS 140 is upgraded so as to be consistent with the control service side, so there is a possibility that version inconsistency may occur between the application and the VAS 140. Yes, and in that case, an error occurs at the time of execution.
[0035]
Therefore, in order to prevent an error from occurring at the time of execution, a function is provided for comparing the entire version of the application and the VAS 140 and checking whether the versions match.
[0036]
Here, the entire version of the VAS 140 is a version of an API set provided by the VAS 140, and the entire version of the application is a version of an API set used by the application with respect to the VAS 140.
[0037]
The application also has a function of checking the version of each API used by the VAS 140 for the API. With this function, even if the entire version of the application and the VAS are different, if it is determined that the application can be operated by comparing the APIs, it is determined that the version is consistent. be able to.
[0038]
The platform 120 interprets a processing request from an application to generate a hardware resource acquisition request, and a system resource manager that manages one or more hardware resources and arbitrates the acquisition request from the control service. (SRM) 123 and a general-purpose OS 121.
[0039]
The control service is formed from a plurality of service modules, and includes an SCS (system control service) 122, an ECS (engine control service) 124, an MCS (memory control service) 125, an OCS (operation panel control service) 126, and an FCS. (Fax control service) 127 and NCS (network control service) 128.
[0040]
Each service in the platform 120 has an application program interface (API) for receiving a processing request from the application 130 and providing a predetermined service to the application. In this specification, an API includes an event notified from the application to the platform 120 and an event notified from the platform 120 to the application, in addition to the function for providing the service.
[0041]
The general-purpose OS 121 is a general-purpose operating system such as UNIX (registered trademark), and executes each software of the platform 120 and the application 130 in parallel as a process.
[0042]
The process of the SRM 123, together with the SCS 122, controls the system and manages resources. The process of the SRM 123 uses hardware resources such as an engine such as a scanner unit and a printer unit, a memory, an HDD file, and a host I / O (centro I / F, network I / F, IEEE 1394 I / F, RS232C I / F, etc.). Arbitration is performed according to a request from the upper layer to be used, and execution is controlled.
[0043]
Specifically, the SRM 123 determines whether the requested hardware resource can be used (whether or not the requested hardware resource is not used by another request). Communicate availability to upper layers. The SRM 123 also schedules use of hardware resources in response to a request from an upper layer, and directly implements the contents of the request (for example, paper transport and image forming operation, memory reservation, file generation, and the like by a printer engine). .
[0044]
The process of the SCS 122 performs application management, operation unit control, system screen display, LED display, resource management, interrupt application control, and the like.
[0045]
The process of the ECS 124 controls an engine of a hardware resource 103 including a black and white laser printer (B & W LP) 101, a color laser printer Color LP) 102, a scanner, a facsimile, and the like.
[0046]
The process of the MCS 125 performs acquisition and release of an image memory, use of a hard disk device (HDD), compression and decompression of image data, and the like.
[0047]
The process of the FCS 127 includes facsimile transmission / reception using PSTN / ISDN network from each application layer of the system controller, registration / quotation of various facsimile data managed by BKM (backup SRAM), facsimile reading, facsimile reception printing, fusion transmission / reception. Provides an API to do so.
[0048]
The process of the NCS 128 is a process for providing a service that can be used in common to applications that require network I / O, and distributes data received from the network by each protocol to each application, or distributes data from the application to the data. Mediation when sending to the network side. Specifically, it has server daemons such as ftpd, httpd, lpd, snmpd, telnetd, and smtpd, and client functions of the same protocol.
[0049]
The process of the OCS 126 controls an operation panel (operation panel) serving as information transmission means between the operator (user) and the main body. The OCS 126 obtains a key press from the operation panel as a key event, and transmits a key event function corresponding to the obtained key to the SCS 122, and displays various screens on the operation panel in response to a request from the application 130 or the control service. A drawing function for drawing and outputting, a function for controlling the operation panel, and the like are configured from a part of the OCS library registered in advance. This OCS library is implemented by being linked to each module of the application 130 and the control service. Note that all of the OCS 126 may be configured to operate as a process, or all of the OCS 126 may be configured as an OCS library.
[0050]
The application 130 includes a printer application 111 that is a printer application having a page description language (PDL), PCL, and PostScript (PS), a copy application 112 that is a copy application, and a fax application 113 that is a facsimile application. , A scanner application 114 as a scanner application, a network file application 115 as a network file application, and a process inspection application 116 as a process inspection application. Each of these applications transmits an application registration request message together with the process ID of its own process to the VAS 140 at the time of activation, and the VAS 140 that has received the application registration request message registers the activated application. .
[0051]
Each process of the application 130 and each process of the control service realize user services related to image forming processing such as copy, printer, scanner, and facsimile while performing inter-process communication by calling a function, transmitting a return value thereof, and transmitting and receiving a message. are doing.
[0052]
As described above, in the multifunction peripheral 100 according to the first embodiment, there are a plurality of applications 130 and a plurality of control services, all of which operate as processes. Then, one or a plurality of threads are generated inside each of these processes, and the threads are executed in parallel. Then, the control service provides a common service to the application 130. For this reason, these many processes perform parallel operation and thread parallel operation, perform inter-process communication with each other, and perform cooperative operation. User services related to image forming processes such as copying, printing, scanning, and facsimile are provided. In addition, the MFP 100 allows a third party such as a third vendor to develop and install new applications 117 and 118 in the application layer above the control service layer. FIG. 1 shows an example in which the new applications 117 and 118 are mounted.
[0053]
In the multifunction peripheral 100 according to the first embodiment, a plurality of processes of the application 130 and a plurality of processes of the control service are operating. However, each of the application 130 and the control service process has a single configuration. Is also possible. Further, each application 130 can be added or deleted for each application.
[0054]
FIG. 2 illustrates a hardware configuration example of the multifunction peripheral 100.
[0055]
The multifunction peripheral 100 includes a controller 160, an operation panel 175, a fax control unit (FCU) 176, and an engine unit 177 that is a hardware resource specific to image forming processing such as a printer. The controller 160 includes a CPU 161, a system memory 162, a north bridge (NB) 163, a south bridge (SB) 164, an ASIC 166, a local memory 167, an HDD 168, a network interface card (NIC) 169, and an SD card. , A USB device 171, an IEEE 1394 device 172, and a Centronics 173. Note that the memories 162 and 167 include a RAM, a ROM, and the like. The FCU 176 and the engine unit 177 are connected to the ASIC 166 of the controller 160 via a PCI bus 178.
[0056]
The CPU 161 reads a program such as an application and a control service installed in the multifunction peripheral 100 from the memory and executes the program.
[0057]
FIG. 3 is a block diagram illustrating a configuration of the VAS 140 of the multifunction peripheral 100 according to the first embodiment and a relationship between the VAS 140, each application, the control service layer 150, and the general-purpose OS 121. Although FIG. 3 shows the printer application 111, the copy application 112, and the new applications 117 and 118 as examples of the application 130, other applications have the same configuration.
[0058]
In the process of the virtual application service (VAS) 140, a dispatcher 145, a control thread 144, a version information acquisition thread 143, an overall version check thread 142, and an API unit version check thread 141 operate. The application has a used API table 212, and the VAS 140 has an entire API table 211. When the application is started (including the temporary start) and when the VAS 140 is started, the used API table 212 and the entire API table 211 are respectively expanded in the RAM 210, for example.
[0059]
The dispatcher 145 monitors reception of a message from the application 130 or the control service, and issues a processing request to the control thread 144, the version information acquisition thread 143, the entire version check thread 142, and the API unit version check thread 141 according to the received message. Things. In the multifunction peripheral 100 according to the first embodiment, the dispatcher 145 can perform interprocess communication performed between the provisionally activated or normally activated application and the VAS 140. The term "temporary activation" means that the application is temporarily activated only for communication between the application and the VAS, and the details will be described later.
[0060]
The control thread 144 passes version information for each API unit used by each application transmitted via the dispatcher 144 and overall version information of each application to the overall version check thread 142 and the API unit version check thread 141, respectively. And controls the processing order among the threads 141 to 143 and transmits processing requests from the threads 141 to 143 to the dispatcher 145.
[0061]
Further, the API unit version check thread 141 obtains version information for each API unit used by the application with respect to the VAS 140 and version information for each API unit of the VAS 140, and compares the versions of the corresponding APIs. To check whether they are the same.
[0062]
The overall version check thread 142 acquires overall version information of each application and overall version information of the VAS 140, and checks whether the overall versions are the same. By having this thread function, first, all versions are compared, and if the entire versions are the same, it can be said that there is consistency. Therefore, it is not necessary to perform a version check for each API unit, and processing is simplified. can do. Then, the version check for each API unit may be performed only when the entire version is different.
[0063]
The version information acquisition thread 143 acquires the version information for each API unit used by the application required by the API unit version check thread 141 and the version information for each API unit of the VAS. It acquires the entire version information and the overall version information of the VAS.
[0064]
In this embodiment, a version check is performed when a new application is installed. However, since the application has not been started yet, information cannot be obtained using inter-process communication. Therefore, the version information acquisition thread 143 temporarily activates the target application, and acquires necessary information from the application through inter-process communication. In addition, as information to be obtained from the application, a product ID (uniquely determined from a vendor, an application, and a version), a vendor name, an application name, an overall version, resource information, and the like are obtained in addition to the version information for each API unit. It is also possible.
[0065]
Instead of using a plurality of threads 141 to 144 as shown in FIG. 3, the threads 141 to 144 may be configured as one thread. In that case, the one thread executes a series of version check processing (version information acquisition, version check) in the present embodiment. Note that the program of the VAS 140 can be stored in a recording medium such as an SD card or a CD-ROM and distributed. It can also be distributed via a network. Further, this program can be installed in the multifunction peripheral by inserting an SD card into the multifunction peripheral, for example. It can also be activated from an SD card.
[0066]
FIG. 4 is a diagram for explaining the outline of the version check method of the present invention. As shown in FIG. 4, the version file (version table) of the API used by the application with respect to the VAS 140 is included in the execution file of the application. Similarly, the execution file of the VAS 140 also contains version information (version table) of the API possessed by the VAS. Note that, in general, the plurality of APIs used by the application with respect to the VAS 140 are a part of the plurality of APIs included in the VAS 140.
[0067]
The version information of the API that the VAS 140 has is a version for each API and a version as a set of APIs. The version information of the application includes a version for each API and a version as a set of APIs. The version of the API set used by the application is the same as the version of the API set of the VAS used when creating the application.
[0068]
In order to include the version information in the executable file, for example, as shown in FIG. 4, the version information is created as an include file, and is included in the created program and compiled.
[0069]
The VAS 140 acquires the version information of the API used by the application from the provisionally activated application by inter-process communication, compares the version information with the version information of the API included in the VAS for each API, and installs the application. Determine whether or not. Further, the versions of the API set may be compared with each other, and only when the versions are different, the version of each API may be compared. The VAS 140 may obtain the entire table of the version information used by the application and perform the comparison process, or may obtain the version information of the API used by the application one by one for each API and determine the corresponding API version. May be compared.
[0070]
Further, instead of including the version information in the execution file as described above, the version information of the application may be stored in the MFP 100 as a separate file, and the VAS 140 may refer to the file.
[0071]
As long as the VAS can refer to the version information, various methods other than the above-described methods can be used as a method of retaining the version information in the multifunction peripheral 100.
[0072]
Now, after the application is created, the version of the API set of the VAS 140 is increased, and the API set used by the application may differ from the API set version of the VAS.
[0073]
For example, in the example of FIG. = 251 has been upgraded from (101) to (102), so the version of the API set of the VAS 140 has been changed from (1.00) to (1.01).
[0074]
In this case, since the versions are different only by comparing the API sets, it may be determined that there is no consistency between the application and the VAS. Since the API 251 is not used in the application, the application can operate without any problem. Therefore, by comparing the APIs, it can be determined that the application can operate without any problem even if the API sets have different versions.
[0075]
Next, temporary activation of the application will be described. The provisional activation is different from the normal activation of the application that uses the resources of the multifunction peripheral (the activation for performing the original function of the application is called the normal activation). In the provisional activation, the application does not acquire resources such as memory reservation necessary for the original operation of the application, and performs only the process of inter-process communication with the VAS 140. Then, the application provides the VAS 140 with information necessary for the VAS 140 to perform a check on the application including the version check. The process of the provisionally activated application ends when the communication processing with the VAS 140 ends. Further, the function related to the provisional activation of the application is a function common to the application operating on the MFP 100 according to the present embodiment, regardless of the original function of the application. Therefore, for example, when a vendor develops an application, the vendor can be provided with a program template including a function of provisional activation, and the vendor can use the program template to develop an application for a multifunction peripheral. To implement the above version check, for example, a vendor creates an include file that records the API used for application development and its version, and includes it when compiling the application.
[0076]
Since the application has the function of provisionally starting, the application information can be provided to the VAS through communication with the VAS without performing normal startup, and the VAS can check the application. Therefore, there is no danger that the application abnormally operates by normally starting the application whose API version or the like is inconsistent, thereby affecting the MFP.
[0077]
FIG. 6 shows an outline of a program description (main function) of an application including a provisional activation function. This description is provided as the above program template.
[0078]
As shown in FIG. 6, this program description specifies whether the application is provisionally activated or normally activated by an argument (-v). Thereby, when the VAS starts the application, it is possible to easily use the normal start and the provisional start. That is, when the provisional activation is designated using the argument (-v), the provisional activation is executed, and the application information providing process is performed. If provisional activation is not specified, normal activation is performed to perform the original operation of the application.
[0079]
Note that, when the version is checked at the time of starting an application to be described later or at the time of execution after the start of the application, the normal start processing is selected.
[0080]
The application program having the provisional activation function as described above can be stored in a recording medium such as an SD card or a CD-ROM and distributed. It can also be distributed via a network. Further, this program can be installed in the multifunction peripheral by inserting an SD card into the multifunction peripheral, for example. It can also be activated from an SD card.
[0081]
Next, an operation of the multifunction peripheral when a version check is performed when an application is installed will be described with reference to a flowchart of FIG. FIG. 8 is a flowchart showing a subroutine of the version check process in FIG.
[0082]
First, as shown in FIG. 7, when the user selects an application installation process using keys and buttons on the operation panel (step S501), the SCS (system control service) 122 requests the VAS 140 to start the application installation process. Then (step S502), the VAS 140 provisionally starts the application in the installation target area (step S503). As described above, this temporary activation is for notifying the VAS 140 of various information in the application to be installed using inter-process communication, and the VAS performs a version check process (step S504).
[0083]
Details of the version check process in step S504 will be described with reference to FIG.
[0084]
As shown in FIG. 8, it is determined whether or not the information notified from the application includes the entire version information of the application (the version information of the API set) (step S601). Is compared with the entire API version of the VAS 140, and if they are the same (step S602), there is no version mismatch, and the VAS 140 guarantees the operation of the application (step S603). Note that guaranteeing the operation means, for example, recording a flag indicating that there is no problem with the API version in association with the application.
[0085]
If NO in step S601 or step S602 in FIG. 8, the process proceeds to step S604, in which the version of the API used by the application and the version of the API of the VAS 140 corresponding to the API are used by the application. Each API is compared one by one, and it is determined whether all versions are the same. If they are the same, the operation is guaranteed within the support range of the VAS 140 in the above step S603 (step S603). However, if there is an API of a different version in step S604, the API is out of the support range of the VAS 140, and the fact is recorded (step S605).
[0086]
As described above, after performing the version check process in the subroutine of step S504 in FIG. 8, the process returns to step S503 until there is no other application to be installed, and the version check process is repeated (step S505).
[0087]
If there is no application to be installed, an installation screen is generated on an operation panel or the like based on the information of the application acquired at the time of installation in step S506, and various information is displayed (step S506). For example, whether or not operation is guaranteed is displayed based on the result of version check of a plurality of applications that have been installed. As a result, the user can easily select an application for which a formal installation request is to be made from the installation screen (step S507), and finally installs only the selected application (step 508).
[0088]
As described above, in the first embodiment, when the application is installed, the application can be provisionally activated by the VAS, and information about the application including the version information can be obtained using the inter-process communication, and the version can be checked. In addition, only the application whose operation is guaranteed can be selectively installed.
[0089]
Further, the version check processing of the present invention can be performed at the time of normal startup of the application in addition to the time of installation. Whether the application is provisionally started or normally started depends on whether or not the argument (-v) is used, as shown in the example of the description of the main function in FIG. Version information can be obtained, so that a version check process can be performed. The version check at the time of starting the application is effective when, for example, starting an already installed application for the first time. If the version information of the application is stored in a separate file, communication between processes is not performed, and the VAS can perform a check by referring to the file.
[0090]
Further, the version check process can be performed at the time of execution after the application is started. At the time of execution after the application is started, inter-process communication can be used, so that the version check can be performed at appropriate timing in the same manner as the version check at the time of normal startup of the application.
[0091]
In addition, as a version check at the time of executing the application, for example, version information is inserted in the argument of the API on the application side, and when the API is used by the application, the VAS 140 is notified of the API version, and the VAS 140 checks the version. The version may be checked. If the VAS 140 determines that there is an API version difference, the VAS 140 does not transmit the API request to the service layer. Furthermore, the execution process of the application may be stopped, an error display may be performed on the operation panel, and the user may be notified of the display. If there is no version difference, the execution of the application is continued as it is.
[0092]
Note that the version check process may be performed on the application side instead of the VAS 140 side. In this case, the application acquires the version information of the API included in the VAS 140 from the VAS 140 and performs a version check process. Then, at the time of installation, whether or not there is a version difference is notified to the VAS 140. If it is a startup or an execution, if there is no version difference, the startup or the execution is continued.
[0093]
As described above, in the MFP according to the first embodiment, the VAS 140 acquires the version information for each API unit used by the application and the version information for each API unit of the VAS, and determines whether the versions of the corresponding APIs are the same. Check if. Therefore, even if the API of the VAS 140 not used by the application is changed, added, or deleted, and the version of the entire API of the VAS (API set) is changed, it is possible to determine that the consistency between the two is not affected. . Compared to the case where the entire versions are simply compared with each other, the absorption range of the VAS version difference is broadened, and the number of available applications can be increased.
[0094]
In the MFP according to the first embodiment, the VAS 140 first compares the entire version, and can perform the version check for each API only when the entire version is different, so that the version check process can be performed efficiently and Can be done quickly. Further, by using an application execution file having necessary version information in advance, the VAS can acquire desired version information by inter-process communication at the time of provisional activation or normal activation of the application.
[0095]
Also, when the version is checked at the time of installing the application, the VAS 140 can temporarily start the application and obtain the version information for each API unit used by the application. You can check.
[0096]
(Embodiment 2)
Next, a second embodiment will be described. In the first embodiment, as shown in FIG. 4, the application has version information of the API used by the application with respect to the VAS 140, and the VAS 140 checks the version information.
[0097]
Now, the VAS 140 in the multifunction peripheral may be configured not to cover all control services as shown in FIG. 1, but to cover only some control services. In the second embodiment, a configuration will be described in which an API version for a control service that directly communicates with an application without using the VAS 140 can be checked. In the following description, the VAS and the control service are each called a “system”.
[0098]
In the second embodiment, as shown in FIG. 9, the application has, in addition to the version information of the API used for the VAS 140, the version information of the API used for the control service that performs communication without passing through the VAS 140. are doing. The VAS 140 acquires these version information from the application, acquires the API version information of the system from the corresponding system, and performs version comparison.
[0099]
As shown in FIG. 9, the application may have a version information table for each system, or may hold version information for all systems used by the application in one table. In this case, the API of which system can be identified in the table. In the case of FIG. 9, each table holds the version of the API set in addition to the version for each API. Note that the application may have a table holding the version of the API set for each system as shown in FIG.
[0100]
Note that the version information shown in FIG. 9 may be stored in an executable file of a program such as an application or may be provided in another file. In that case, the VAS 140 acquires the version information by opening the file instead of inter-process communication. Various other methods are possible to hold the version information.
[0101]
FIG. 11 shows a flowchart of the version check processing by the VAS in the configuration of FIG. Note that the flow in FIG. 11 is based on the premise that the VAS sequentially obtains the version information table from the application. Also, a version check process at the time of installation is shown.
[0102]
First, the VAS acquires one table from the application (step S701). Then, it is determined which system the table corresponds to (step S702). Next, a version information table of the corresponding system is acquired from the system (step S703).
[0103]
Next, the table acquired from the application is compared with the table acquired from the system, and it is determined whether or not all versions (API set versions) match (step S704). If they match, the fact that the versions match for the system is recorded (step S706). Then, if there is no other table to be obtained from the application, the version check processing ends. If there is another, the processing from step S701 is repeated.
[0104]
If they do not match in step S704, the version is checked for each API used by the application for the system (step S705). If the versions of all APIs are the same, the fact that the versions are consistent is recorded for the system (step S706). If there is at least one API with a different version, the fact that the versions do not match is recorded. At this time, it may be recorded which API version does not match. Then, if there is no other table to be obtained from the application, the version check processing ends. If there is another, the processing from step S701 is repeated.
[0105]
After the end of the version check process, for example, if the version matches all the systems used by the application, the VAS 140 displays on the operation panel that the application can be installed, and displays If there is a system with a version mismatch, a message indicating that there is a version mismatch is displayed. When displaying that there is a version mismatch, it may be displayed which API of which system has a mismatch.
[0106]
According to the present embodiment, it is possible to check not only the API for the VAS 140 but also the version of the API that performs communication without passing through the VAS 140.
[0107]
(Embodiment 3)
The MFP 100 according to the first embodiment has only one VAS 140 for all applications. In the MFP 900 according to the second embodiment, one VAS is activated for each application, and each VAS performs a version check process with the corresponding application.
[0108]
FIG. 12 is a block diagram illustrating a configuration of a multifunction peripheral 900 according to the third embodiment. As shown in FIG. 12, the multifunction peripheral 900 differs from the multifunction peripheral 100 according to the first embodiment in that a plurality of virtual application services (VAS) 941 to 948 operate for each application of the application 130. I have.
[0109]
The VASs 941 to 948 perform a version check process corresponding to the printer application 111, the copy application 112, the fax application 113, the scanner application 114, the net file application 115, the process inspection application 116, and the new applications 117 and 118.
[0110]
FIG. 13 is a block diagram illustrating a configuration of the VASs 941 to 948 of the multifunction peripheral 900 according to the third embodiment and a relationship between the VASs 941 to 948 and each application, the control service layer 150, and the general-purpose OS 121. Note that FIG. 13 illustrates an example of the printer application 111, the copy application 112, and the new applications 117 and 118 as the applications 130, and further illustrates the VASs 941, 942, 947, and 948 corresponding to these applications as examples. The same configuration is used when other applications are used.
[0111]
Further, in the multifunction peripheral 900 according to the third embodiment, unlike the multifunction peripheral 100 according to the first embodiment, as shown in FIG. 13, a VAS control process (daemon) 901 is provided between each VAS 941 to 948 and each application. Is working. The VAS control process (daemon) 901 has version information of all APIs provided by the VAS.
[0112]
In the processes of the virtual application services (VAS) 941 to 948, a dispatcher 145, an API version check thread 141, an entire version check thread 142, and a version information acquisition thread 143 are operating.
[0113]
The function of each thread in the multifunction peripheral 900 according to the third embodiment is the same as that described in the first embodiment. Note that the threads 141 to 143 may be one thread.
[0114]
Further, in addition to the above-described configuration, the configuration of the VAS may be the configuration shown in FIGS.
[0115]
FIG. 14A shows a case where the VAS started for each application is a child process of the parent VAS, and the parent VAS itself does not have a screen control right (user interface). FIG. 14B shows a case where the parent VAS itself has a screen control right (user interface). FIG. 14C shows a case in which the VAS function corresponding to each application is activated as a thread.
[0116]
For example, in the case of FIG. 14C, the VAS thread corresponding to the application is not activated at the time when the application is not fully activated. At the time of installing the application, one VAS that is not associated with the application temporarily starts the application and checks the version. Thereafter, when the application is fully activated, a VAS thread corresponding to each application is activated.
[0117]
It should be noted that the present invention is not limited to the above-described embodiment, and various modifications and applications are possible within the scope of the claims.
[0118]
【The invention's effect】
As described above, according to the present invention, the version information for each API unit used by the application is compared with the version information for each API unit on the system service side such as the VAS, and whether the versions of the corresponding APIs are the same is determined. Can be checked, so that it can be determined whether the application can be used normally.
[Brief description of the drawings]
FIG. 1 is a block diagram illustrating a software configuration of a multifunction peripheral according to a first embodiment of the present invention.
FIG. 2 is a block diagram illustrating a hardware configuration of the multifunction peripheral according to the first embodiment of the present invention.
FIG. 3 is a block diagram illustrating a configuration of a VAS of the multifunction peripheral and a relationship between each application, a control service layer, and a general-purpose OS according to the first embodiment of the present invention.
FIG. 4 is a diagram for explaining a version check method according to the first embodiment of the present invention.
FIG. 5 is a diagram for explaining a version check method according to the first embodiment of the present invention.
FIG. 6 is a program description example of a provisionally startable application according to the first embodiment of the present invention.
FIG. 7 is a flowchart illustrating a version check sequence at the time of application installation.
FIG. 8 is a flowchart showing a version check process in FIG. 7;
FIG. 9 is a diagram for explaining a version check method according to the second embodiment of the present invention.
FIG. 10 is an example of a table included in an application according to the second embodiment of the present invention.
FIG. 11 is a flowchart illustrating a procedure of a version check process according to the second embodiment of the present invention.
FIG. 12 is a block diagram illustrating a software configuration of a multifunction peripheral according to Embodiment 3 of the present invention.
FIG. 13 is a block diagram illustrating a configuration of a VAS of a multifunction peripheral according to a third embodiment of the present invention and a relationship between the VAS, each application, a control service layer, and a general-purpose OS.
FIG. 14 is a diagram illustrating a configuration example of a VAS according to an embodiment of the present invention.
[Explanation of symbols]
100 MFP 101 Black and White Laser Printer 102 Color Laser Printer 103 Hardware Resources 110 Software Group 111 Printer Application 112 Copy Application 113 Fax Application 114 Scanner Application 115 Net File Application 116 Process Inspection Application 117, 118 New Application 120 Platform 121 General-purpose OS
122 SCS
123 SRM
124 ECS
125 MCS
126 OCS
127 FCS
128 NCS
130 Application 140, 941-948 Virtual Application Service (VAS)
141 API unit version check thread 142 Overall version check thread 143 Version information acquisition thread 144 Control thread 145 Dispatcher 150 Control service layer 201 Wrapping processing information file 210 RAM
211 All API table 212 API table used 900 MFP 901 VAS control process

Claims

An image forming apparatus comprising: an application that performs a process related to an image forming process; and a system service that performs a process on a system side based on a request using an API from the application,
Acquisition means for acquiring version information of an API used by the application for a system service, and version information of an API possessed by the system service;
An image forming apparatus comprising: a comparing unit that compares an API version used by the application for the system service with an API version of the system service for each API.

Means for comparing a version of a set of APIs used by the application for the system service with a version of the set of APIs included in the system service;
The image forming apparatus according to claim 1, wherein the comparison unit performs the comparison only when the versions of the set of APIs are different.

The application includes, in an execution program of the application, version information of an API used for the system service,
The image forming apparatus according to claim 1, wherein the obtaining unit obtains version information of the API from the application.

The image forming apparatus according to claim 3, wherein the application is provisionally started to acquire the version information from the application.

The system service includes a plurality of system services,
The application includes, for each system service, version information of an API used for the plurality of system services,
4. The image forming apparatus according to claim 3, wherein, when acquiring the API version information corresponding to a certain system service from the application, the acquiring unit acquires the API version information of the system service from the system service. 5. .

A file storing version information of an API used by the application for the system service;
The image forming apparatus according to claim 1, wherein the obtaining unit obtains version information of the API from the file.

In the case where the comparison by the comparing unit is performed before the installation of the application,
2. The application according to claim 1, wherein if the version of all APIs used by the application with respect to the system service matches the version of the corresponding API of the system service, the application is installed. Image forming apparatus.

The image forming apparatus includes a control service that controls hardware resources in the image forming apparatus, and a virtual application service that operates as a client process using the control service as a server and operates as a server process using the application as a client. Have
The image forming apparatus according to claim 1, wherein the system service includes a control service for receiving a request using an API from an application, and the virtual application service.

The image forming apparatus according to claim 8, wherein the virtual application service includes the acquisition unit and the comparison unit.

A version checking method of an API executed by an image forming apparatus including an application for performing a process related to an image forming process and a system service for performing a process on a system side based on a request using the API from the application,
An acquisition step of acquiring version information of an API used by the application for a system service and version information of an API included in the system service;
A comparing step of comparing an API version used by the application for the system service with an API version of the system service for each API.

Comparing the version of the set of APIs that the application uses for the system service with the version of the set of APIs that the system service has;
The version checking method according to claim 10, wherein the comparison in the comparing step is performed only when the versions of the API set are different.

The application includes, in an execution program of the application, version information of an API used for the system service,
The version check method according to claim 10, wherein in the obtaining step, the version information of the API is obtained from the application.

13. The version check method according to claim 12, wherein the application is provisionally started to acquire the version information from the application.

The system service includes a plurality of system services,
The application includes, for each system service, version information of an API used for the plurality of system services,
13. The version check method according to claim 12, wherein, in the obtaining step, when version information of an API corresponding to a certain system service is obtained from the application, version information of an API of the system service is obtained from the system service. .

A file storing version information of an API used by the application for the system service;
The version check method according to claim 10, wherein in the obtaining step, the version information of the API is obtained from the file.

When performing the comparison by the comparing step before installing the application,
11. The application according to claim 10, wherein if the versions of all APIs used by the application for the system service match the corresponding API versions of the system service, the application is installable. Version check method.

The image forming apparatus includes a control service that controls hardware resources in the image forming apparatus, and a virtual application service that operates as a client process using the control service as a server and operates as a server process using the application as a client. Have
17. The version checking method according to claim 10, wherein the plurality of system services include a control service for receiving a request using an API from an application, and the virtual application service.

The version check method according to claim 17, wherein the virtual application service performs the obtaining step and the comparing step.

An image forming apparatus including: an application that performs processing related to image forming processing; and a system service that performs processing on the system side based on a request using an API from the application.
An acquisition procedure for acquiring version information of an API used by the application for a system service, and version information of an API included in the system service;
A program for executing a comparison procedure of comparing an API version used by the application for the system service with an API version of the system service for each API.

Causing the application to further execute a procedure of comparing a version of a set of APIs used for the system service with a version of the set of APIs included in the system service;
20. The program according to claim 19, wherein the comparison procedure is executed only when the versions of the set of APIs are different.

Version information of an API used by the application for the system service is provided in an execution program of the application,
20. The program according to claim 19, wherein in the acquiring step, a step of acquiring version information of the API from the application is executed.

A file storing version information of an API used by the application for the system service;
20. The non-transitory computer-readable storage medium according to claim 19, wherein in the acquiring step, a step of acquiring version information of the API from the file is executed.

When performing the comparison in the comparison procedure before installing the application,
If the version of all APIs used by the application for the system service matches the version of the corresponding API included in the system service, a step of displaying that the application can be installed is executed. Item 19. The program according to Item 19.

A program of the application executed by the image forming apparatus having a system service that performs processing on the system side based on a request from an application that performs processing related to image forming processing.
Based on a request from the system service, a procedure of determining whether to start temporarily or to start normally,
A step of providing information on an application to the system service by communicating with the system service in the case of temporary activation.

A computer-readable recording medium recording the program according to any one of claims 19 to 24.