(57)【要約】【課題】  画像形成装置において、ファームウェアのバージョンアップによって、ＡＰＩの不整合が発生しても、そのためにアプリケーションが起動できなくなるのを防ぐ。【解決手段】  アプリケーションは、使用するＡＰＩを同定する情報を有し、画像形成装置のファームウェアは、提供可能なＡＰＩの一覧と当該ＡＰＩのインタフェース情報及びＡＰＩ不整合時の代替ＡＰＩ情報を有し、アプリケーションが使用するＡＰＩと提供するＡＰＩの間で不整合が生じると、前記代替ＡＰＩが呼ばれるようにアプリケーションを改変する方法によって課題を解決した。【選択図】図１
2011097365.tif 000002
【特許請求の範囲】
【請求項１】
アプリケーション及び当該アプリケーションが使用するＡＰＩ（Application Program Interface）の同定情報を有するアプリケーションデータ格納部と、
装置が提供するＡＰＩ及び当該ＡＰＩのインタフェース情報を有する提供ＡＰＩデータ格納部と、
前記アプリケーションデータ格納部のＡＰＩの同定情報と、前記提供ＡＰＩデータ格納部のＡＰＩのインタフェース情報に基づいて、前記アプリケーションが使用可能かどうかを判断するＡＰＩチェック処理部と、
前記ＡＰＩチェック処理部により、使用不可能と判断されたアプリケーションについて、前記提供ＡＰＩデータ格納部が提供するＡＰＩにより動作可能なように当該アプリケーションを改変するＡＰＩパッチあて処理部と、を有する
ことを特徴とする画像形成装置。
【請求項２】
請求項１の画像形成装置であって、
前記ＡＰＩチェック処理部は、ＡＰＩの使用可能かどうかの判断をアプリケーション起動時に行い、
前記ＡＰＩパッチあて処理部は、前記ＡＰＩチェック処理部が起動時に使用不可能と判断されたアプリケーションについて、動的に改変する
ことを特徴とする画像形成装置。
【請求項３】
請求項１又は２の画像形成装置であって、
前記ＡＰＩパッチあて処理部は、前記使用不可能なＡＰＩの代替可能なＡＰＩを呼び出すようにアプリケーションの改変を行なう
ことを特徴とする画像形成装置。
【発明の詳細な説明】
【技術分野】
【０００１】
画像形成装置において、ＡＰＩ（Application Program Interface）の利用技術に関するものである。
【背景技術】
【０００２】
ＭＦＰ（Multi Functional Peripheral；複合機）等の画像形成装置上でアプリケーションを動作させる際、ＭＦＰがアプリケーションに提供しているＡＰＩ（Application Program Interface）とアプリケーションが使用しているＡＰＩとの整合がなければ、アプリケーションを実行することはできない。この場合に、例えばファームウェアのバージョンアップによるＡＰＩセットの更新によってアプリケーションが利用可能なＡＰＩがなくなってしまうとアプリケーションが起動しなくなるという問題が生じる。ユーザにとってはなぜ起動に失敗したのかわからず、なおかつ利用したいアプリケーションを利用できない、という不利益をこうむることになる。
【０００３】
従来技術として、ＡＰＩの利用可否によるアプリケーション利用の可否を容易に判断する目的で、あらかじめＡＰＩの情報をＭＦＰ内部に格納し、アプリケーション側にも使用するＡＰＩの情報を添付し、その適合性で持って、利用可否を判断する、という方法がある（特許文献１参照）。この方法では、ユーザ情報格納部、ＭＦＰ情報格納部、ＡＰＩ情報格納部等の内容を参照してＡＰＩの利用可否を判定し、また、ＡＰＩが利用できないことにより、実行することができないアプリケーションの機能を判定して、ディスプレイにアプリケーションの一覧表示を行う際の表示方法を切り替える。
【０００４】
しかし、この方法では、ファームウェアのバージョンアップでＡＰＩセットの更新がされることにより、今まで使用できていたアプリケーションが使用できなくなる問題は解消されない。
【先行技術文献】
【特許文献】
【０００５】
【特許文献１】特開２００８−１０９４１６号公報
【発明の概要】
【発明が解決しようとする課題】
【０００６】
解決しようとする課題は、画像形成装置において、ＡＰＩのバージョンの不整合等によって動作しないアプリケーションを動作させることである。
【課題を解決するための手段】
【０００７】
本発明の画像形成装置は、アプリケーション及び当該アプリケーションが使用するＡＰＩ（Application Program Interface）の同定情報を有するアプリケーションデータ格納部と、装置が提供するＡＰＩ及び当該ＡＰＩのインタフェース情報を有する提供ＡＰＩデータ格納部と、前記アプリケーションデータ格納部のＡＰＩの同定情報と、前記提供ＡＰＩデータ格納部のＡＰＩのインタフェース情報に基づいて、前記アプリケーションが使用可能かどうかを判断するＡＰＩチェック処理部と、前記ＡＰＩチェック処理部により、使用不可能と判断されたアプリケーションについて、前記提供ＡＰＩデータ格納部が提供するＡＰＩにより動作可能なように当該アプリケーションを改変するＡＰＩパッチあて処理部と、を有することを特徴とする。
【発明の効果】
【０００８】
このため、アプリケーションが利用するＡＰＩと画像形成装置が利用するＡＰＩとの間での不整合により、アプリケーションが起動不可能であっても、前記改変されたアプリケーションが正しく動作を行うために、アプリケーションが起動可能となる。
【図面の簡単な説明】
【０００９】
【図１】本発明実施例の画像形成装置の機能ブロック図である。
【図２】本発明実施例の画像形成装置のソフトウェアの構造を示す階層図である。
【図３】本発明実施例の画像形成装置のフローチャートである。
【発明を実施するための形態】
【００１０】
本発明実施例に係る画像形成装置１０１について、以下に説明する。
【実施例１】
【００１１】
［構成］
図１は、本発明実施例の画像形成装置１０１の機能ブロック図である。
【００１２】
画像形成装置１０１は、アプリケーション起動受付部１１１、アプリケーション読み込み処理部１１３、アプリケーションデータ格納部１１５、ＡＰＩチェック処理部１１７、提供ＡＰＩデータ格納部１１９、ＡＰＩパッチあて処理部１２１、アプリケーション起動処理部１２３の各機能ブロックを有する。
【００１３】
画像形成装置１０１には、図示しないＣＰＵ（Central Processing Unit）、ＲＡＭ（Random Access Memory）、ＲＯＭ（Read Only Memory）を有して、これらがコンピュータを構成し、上記のアプリケーション起動受付部１１１、アプリケーション読み込み処理部１１３、アプリケーションデータ格納部１１５、ＡＰＩチェック処理部１１７、提供ＡＰＩデータ格納部１１９、ＡＰＩパッチあて処理部１２１、アプリケーション起動処理部１２３の各機能ブロックの機能は、前記コンピュータがプログラムを実行することにより、実現される。
【００１４】
以下に上記の各機能ブロックについて説明する。
【００１５】
アプリケーション起動受付部１１１は、ユーザからの操作パネルからの入力や接続された外部端末装置からの指示によって、画像形成装置の動作を実行させるためのプログラムであるアプリケーションを起動する（図１（１））。ここで言うアプリケーションとは、ファームウェアに含まれないインストール・アンインストール可能なプログラムである（ソフトウェアの構成については、詳細を後述）。例えばＪａｖａ（登録商標）によるＪａｖａ（登録商標）アプリケーションプログラム等である。そして、アプリケーション読み込み処理部１１３にアプリケーションの読み込みを指示する（図１（２））。
【００１６】
アプリケーション読み込み処理部１１３は、前記アプリケーション起動受付部１１１からの指示を受けてアプリケーションデータ格納部１１５に格納されているアプリケーションを読み込み（図１（３））、起動前のアプリケーションの利用不可ＡＰＩをチェックの指示（図１（４））と、起動可能な状態にアプリケーションを加工するための指示（図１（５））を行なう。
【００１７】
アプリケーションデータ格納部１１５は、アプリケーション及び当該アプリケーションが使用するＡＰＩ（Application Program Interface）の同定情報を格納する。アプリケーション読み込み処理部１１３からの要求に基づいて、アプリケーション及びアプリケーションが使用するＡＰＩの情報（インタフェース情報）を渡す。装置が提供するＡＰＩとアプリケーションが使用するＡＰＩのバージョンの不整合等のために、アプリケーションが実行不可能な場合がある。アプリケーションデータ格納部１１５は、インストールされるアプリケーションが使用しているＡＰＩの同定情報を有し、提供ＡＰＩデータ格納部１１９でそのＡＰＩを同定し、ＡＰＩがどのようなインタフェースのもとに作動するかについて調査可能とする。当該インタフェース情報に基づいて、後述の他機能部により、提供ＡＰＩとの比較（インタフェースの整合性）が行なわれる。
【００１８】
ＡＰＩチェック処理部１１７は、画像形成装置１０１が保有してアプリケーションに提供するＡＰＩとアプリケーションが利用しようとするＡＰＩとの相互のインタフェース情報を比較し、アプリケーションが利用不可能なＡＰＩを使用しているかどうかをチェック（図１（４））する。
【００１９】
提供ＡＰＩデータ格納部１１９は、画像形成装置１０１が保有してアプリケーションに提供するＡＰＩに関する情報（インタフェース情報）を格納する。ＡＰＩチェック処理部１１７からの要求に基づいて、前記ＡＰＩに関する情報を渡す（図１（５））。
【００２０】
ＡＰＩパッチあて処理部１２１は、ＡＰＩチェック処理部１１７が判断した、利用不可能なＡＰＩを有するアプリケーションについて、装置が提供するＡＰＩを実行するために、アプリケーションのＡＰＩのインタフェース部分についての置き換えが可能なものについては、置き換え可能な処理に動的に変更するようにアプリケーションを加工（改変処理、すなわちパッチあて処理）する（図１（６））。この置換動作については、使用時に動的に加工する方法以外に、画像形成装置の始動時にチェックを行なってあらかじめ加工しておく方法や、アプリケーションのインストール時にチェックを行なって加工するという方法をとってもよい。
【００２１】
アプリケーション起動処理部１２３は、ユーザからのアプリケーション起動要求を受け付けて、アプリケーションの起動を実行する（図１（７））。
【００２２】
アプリケーション起動処理部１２３は、アプリケーション読み込み処理部１１３によって、読み込まれたアプリケーションの最終イメージを使ってアプリケーションを起動する。アプリケーションの最終イメージとは、アプリケーションが加工によってイメージが変更されて最終的に出来上がったイメージのことを指す。
【００２３】
［ソフトウェア構成］
図２に、本画像形成装置のソフトウェアの構成を表す階層図を示す。
【００２４】
画像形成装置１０１のソフトウェアの最下層には、ＯＳ（Operating System）を含むファームウェアが存在し、画像形成装置の基本動作を管理するベースとして機能する。このファームウェアには、画像形成装置１０１の各種基本動作を行うための基本プログラムが含まれている。
【００２５】
また、ソフトウェアの最上層には、画像形成装置１０１の機能操作（例えば複写機能やファックス送受信機能等）を実行するための各アプリケーション（アプリケーションＡからアプリケーションＤの４種；ここでは例として４種挙げたが、数は４種に限らない）が存在する。
【００２６】
上記のファームウェアとアプリケーションとの間には、両者を仲介するミドルウェアが存在する。ミドルウェア中には、ＡＰＩ（Application Program Interface）を有して、アプリケーションは、ＡＰＩを呼ぶことにより、ファームウェア中の基本動作プログラムにアクセス可能となる。
【００２７】
ここで、図１に示した画像形成装置１０１中の各機能ブロックは、図２に示すように（図２中の「ＡＰＩ整合チェック、パッチあての各機能部」）ミドルウェアに属している。画像形成装置１０１のコンピュータが当該ミドルウェア中のプログラムを実行することにより、各機能ブロックの機能が実現する。
【００２８】
［フローチャート］
図３は、本発明実施例の画像形成装置１０１の動作の流れを示すフローチャートである。以下に動作の流れについて説明する。
【００２９】
Ｓ１１：ユーザは、画像形成装置１０１のアプリ起動メニューなどから利用したいアプリケーションを起動する。
【００３０】
Ｓ１３：アプリケーション起動受付部１１１が、ユーザから指定されたアプリケーションの読み込みをアプリケーション読み込み処理部１１３に指示する。
【００３１】
Ｓ１５：アプリケーション読み込み処理部１１３は、指定されたアプリケーション及び関連ＡＰＩの同定の情報を読み込む。
【００３２】
Ｓ１７：アプリケーション読み込み処理部１１３は、ＡＰＩチェック処理部１１７を起動し、提供ＡＰＩデータ格納部１１９からＭＦＰで利用できるＡＰＩの情報を参照する。
【００３３】
Ｓ１９：Ｓ１７で取得した情報に基づいて、ＡＰＩチェック処理部１１７は、アプリケーションが利用しているＡＰＩのなかで使用不可能なＡＰＩをチェックする。
【００３４】
Ｓ２１：利用不可なＡＰＩの呼び出しのなかでＭＦＰの中に代替可能なＡＰＩが存在していれば、ＡＰＩパッチ処理部において処理を置き換える。
【００３５】
Ｓ２３：Ｓ２１において、代替不可能なＡＰＩが存在するならばＳ２７に遷移する。存在しないならば、Ｓ２５に遷移する。
【００３６】
Ｓ２５：これまでの処理で加工されたアプリケーション実行イメージをアプリケーション起動処理部に渡してアプリケーションを起動する。
【００３７】
Ｓ２７：ユーザに対してアプリケーションが起動できない旨のメッセージを表示する。
【００３８】
上記フローチャートでは、不整合であっても代替可能であればメッセージを発することなく代替処理を行ないアプリケーションを起動したが、不整合なＡＰＩが存在した場合は、その旨をユーザに通知する機能（パネルでの表示やログの記録等）を提供するとしてもよい。
【００３９】
［パッチあて処理］
次に、実際にＡＰＩパッチあて処理部１２１で行なわれるパッチあて処理の具体的方法について説明する。
【００４０】
提供ＡＰＩデータ格納部１１９は、例えば以下の表１に示すデータを一つの記録単位（レコード）として、ＡＰＩの情報を保持する。この情報は、過去に提供してきたＡＰＩも含めたものが格納される必要がある。
【００４１】
【表１】
2011097365.tif 000003
【００４２】
すなわち、装置側（ファームウェア側）には、アプリケーションからＡＰＩが呼ばれていても、当該インタフェース（上記シグネチャ）が不整合等な場合には、代替として実行するＡＰＩを同定する情報（代替可能処理）を埋め込んでおく。
【００４３】
次に、アプリケーションデータ格納部１１５に保存されている、アプリケーションに付属するアプリケーションが利用するＡＰＩの情報の書式の例について以下の表２に示す。すなわち利用ＡＰＩの同定情報を埋め込んでおく。
【００４４】
【表２】
2011097365.tif 000004
【００４５】
このデータの書式の場合、例えば図３のフローチャートにおけるＳ１７は、以下のような処理になる。
【００４６】
（１）アプリケーションが利用するＡＰＩのすべてについて、そこに含まれる関数番号をキーにして、画像形成装置１０１が提供するＡＰＩの情報を検索する。
【００４７】
（２）該当レコードの利用可能・付加情報を見て、可能であれば何もしない。利用不可であれば、代替可能処理に示される処理に置き換える。具体的には、置き換え処理コードを動的に生成し、アプリケーションの実行処理に加えて呼び出し関数アドレスを書き換える、などの処理になる。
【００４８】
（３）上記（２）の置き換え処理において、場合によっては置き換え不可能な処理も出てくる可能性もあるが、その場合は、置き換え失敗となる。
【００４９】
［実施例の効果］
ファームウェアの更新により、すでにインストールされているアプリケーションが使用するＡＰＩとＭＦＰが提供するＡＰＩとの間で不整合が生じても、可能な限り実行することができる。
【００５０】
画像形成装置の開発者にとっては、すでに提供しているＡＰＩのうち、バージョンアップに伴い仕様変更が必要なＡＰＩがある場合、アプリケーションの開発者にＡＰＩの仕様変更を伝えた後で、そのＡＰＩに合わせたアプリを作成してもらう必要がある。その過渡期においても、ユーザに古いアプリケーションを一定期間使用してもらうという選択肢をとることも可能にする。
【００５１】
本実施例の画像形成装置においては、アプリケーションの改変をアプリケーションの実行時に行なうこととしたため、起動時やインストール時にアプリケーションの改変を行なう方法に比べて、真に必要なアプリケーションについてのみ改変処理を行なうために、多数の無用のアプリケーションについて、改変処理のためにＣＰＵ時間を無駄にするという問題が無くなる。
【００５２】
［その他］
本実施例においては、代替ＡＰＩを用いる例として、インタフェースの不整合を挙げたが、例えばインタフェースが同一であっても（受け渡し及び戻り値の数及び型が一致していても）処理内容が異なる（例えば、処理ルーチン内で新たな処理が付加されたり、戻り値が異なる結果をもたらす等）ために、当該ＡＰＩでは、正しく処理されない場合等についても、もちろん、代替ＡＰＩを使用する方法により問題解決可能である。
【符号の説明】
【００５３】
１０１  画像形成装置
１１１  アプリケーション起動受付部
１１３  アプリケーション読み込み処理部
１１５  アプリケーションデータ格納部
１１７  ＡＰＩチェック処理部
１１９  提供ＡＰＩデータ格納部
１２１  ＡＰＩパッチあて処理部
１２３  アプリケーション起動処理部
【図１】
2011097365.tif 000005
【図２】
2011097365.tif 000006
【図３】
2011097365.tif 000007