JP2006148876A - 画像形成装置、情報処理方法、情報処理プログラム及び記録媒体 - Google Patents

Abstract

【課題】 画像形成装置に実装されるアプリケーションが当該画像形成装置におけるＡＰＩの実装状況を簡易に確認することのできる画像形成装置、情報処理方法、情報処理プログラム及び記録媒体の提供を目的とする。
【解決手段】 インタフェースが公開されている複数のプログラムを有し、前記インタフェースに基づいて作成されたアプリケーションを実行可能な画像形成装置であって、
前記アプリケーションからの要求に応じて、複数の前記プログラムによって構成されるグループごとに当該グループに係る実装状況を示す情報を提供する実装状況提供手段を有することにより上記課題を解決する。
【選択図】 図７

Description

本発明は、コピー／プリンタ／スキャナ／ファクシミリ／複合機／融合機等の画像形成装置、情報処理方法、情報処理プログラム、ＳＤメモリカード等の記録媒体に関する。

近年、コピー機能とプリンタ機能とスキャナ機能とファクシミリ機能を備える複合機や融合機が市販されるようになった。複合機や融合機は、コピーやプリンタとして機能する場合には、画像を印刷用紙に印刷することになり、コピーやスキャナとして機能する場合には、画像を読取原稿から読み取ることになり、ファクシミリとして機能する場合には、画像を電話回線を介して他の機器と授受することになる。
特開２００２−８４３８３号公報

複合機や融合機では、アプリケーションやプラットフォームと言った様々なプログラムにより様々な情報処理が実行される。複合機や融合機には、カラーコピー用のアプリケーションや、モノクロコピー用のアプリケーションや、ファクシミリ用のアプリケーションと言った様々なアプリケーションが実装される。

さて、カラーコピー用のアプリケーションをカラーコピー機にもモノクロコピー機にも実装できると、カラーコピー用のアプリケーションによるモノクロコピー用の操作画面をカラーコピー機でもモノクロコピー機でも利用できて便利である。同様に、画像形成装置の種々の機能用のアプリケーションを種々の画像形成装置に実装できると、画像形成装置の種々の機能用のアプリケーションを種々の画像形成装置で利用できて便利である。この場合、アプリケーションは画像形成装置毎に異なる各画像形成装置のＡＰＩを使い分ける必要がある。しかし、画像形成装置のＡＰＩの種類は数百種類にも至るのが通例であり、アプリケーションがこれを使い分けるのは困難である。

本発明は、上記の点に鑑みてなされたものであって、画像形成装置に実装されるアプリケーションが当該画像形成装置におけるＡＰＩの実装状況を簡易に確認することのできる画像形成装置、情報処理方法、情報処理プログラム及び記録媒体の提供を目的とする。

そこで上記課題を解決するため、本発明は、インタフェースが公開されている複数のプログラムを有し、前記インタフェースに基づいて作成されたアプリケーションを実行可能な画像形成装置であって、前記アプリケーションからの要求に応じて、複数の前記プログラムによって構成されるグループごとに当該グループに係る実装状況を示す情報を提供する実装状況提供手段を有することを特徴とする。

このような、画像形成装置では、アプリケーションが当該画像形成装置におけるＡＰＩの実装状況を簡易に確認することができる。

また、上記課題を解決するため、本発明は、上記画像形成装置における情報処理方法、前記情報処理方法を前記画像形成装置に実行させるための情報処理プログラム、又は前記情報処理プログラムを記録した記録媒体としてもよい。

本発明によれば、画像形成装置に実装されるアプリケーションが当該画像形成装置におけるＡＰＩの実装状況を簡易に確認することのできる画像形成装置、情報処理方法、情報処理プログラム及び記録媒体を提供することができる。

図１は、本発明の実施例に該当する融合機１０１を表す。図１の融合機１０１は、種々のハードウェア１１１と、種々のソフトウェア１１２と、融合機起動部１１３により構成される。

融合機１０１のハードウェア１１１としては、撮像部１２１と、印刷部１２２と、その他のハードウェア１２３が存在する。撮像部１２１は、読取原稿から画像（画像データ）を読み取るためのハードウェアである。印刷部１２２は、画像（画像データ）を印刷用紙に印刷するためのハードウェアである。

融合機１０１のソフトウェア１１２としては、種々のアプリケーション１３１と、種々のプラットフォーム１３２が存在する。これらのプログラムは、ＵＮＩＸ（登録商標）等のＯＳ（オペレーティングシステム）によりプロセス単位で並列的に実行される。

アプリケーション１３１としては、コピー用のアプリケーションであるコピーアプリ１４１、プリンタ用のアプリケーションであるプリンタアプリ１４２、スキャナ用のアプリケーションであるスキャナアプリ１４３、ファクシミリ用のアプリケーションであるファクシミリアプリ１４４、ネットワークファイル用のアプリケーションであるネットワークファイルアプリ１４５が存在する。そしてさらに、Ｗｅｂページの閲覧用のソフトウェアであるＷｅｂブラウザ１８１、Ｗｅｂページの配信用のソフトウェアであるＷｅｂサーバソフト１８２、ＣＳＤＫアプリ１４６やＪＳＤＫアプリ１４７の制御用のソフトウェアであるＳＤＫアプリケーションサービス（ＳＡＳ）１８３が存在する。

アプリケーション１３１は、専用のＳＤＫ（ソフトウェア開発キット）を使用して開発することができる。ＳＤＫを使用して開発したアプリケーション１３１をＳＤＫアプリと呼ぶ。専用のＳＤＫとしては、Ｃ言語でアプリケーション１３１を開発するための「ＣＳＤＫ」や、Ｊａｖａ（登録商標）言語でアプリケーション１３１を開発するための「ＪＳＤＫ」が提供される。ＣＳＤＫを使用して開発したアプリケーション１３１を「ＣＳＤＫアプリ」と呼び、ＪＳＤＫを使用して開発したアプリケーション１３１を「ＪＳＤＫアプリ」と呼ぶ。図１の融合機１０１にも、ＣＳＤＫアプリ１４６と、ＪＳＤＫアプリ１４７が存在する。図１の融合機１０１にはさらに、Ｊａｖａ（登録商標）言語で記述されたＪＳＤＫアプリ１４７とＣ言語で記述された他のソフトウェア１１２との仲介を行うソフトウェア１１２として、ＪＳＤＫプラットフォーム１４８が存在する。

プラットフォーム１３２としては、種々のコントロールサービス１５１、システムリソースマネージャ１５２、種々のハンドラ１５３が存在する。コントロールサービス１５１としては、ネットワークコントロールサービス（ＮＣＳ）１６１、ファクシミリコントロールサービス（ＦＣＳ）１６２、デリバリコントロールサービス（ＤＣＳ）１６３、エンジンコントロールサービス（ＥＣＳ）１６４、メモリコントロールサービス（ＭＣＳ）１６５、オペレーションパネルコントロールサービス（ＯＣＳ）１６６、サーティフィケーションコントロールサービス（ＣＣＳ）１６７、ユーザディレクトリコントロールサービス（ＵＣＳ）１６８、システムコントロールサービス（ＳＣＳ）１６９が存在する。ハンドラ１５３としては、ファクシミリコントロールユニットハンドラ（ＦＣＵＨ）１７１、イメージメモリハンドラ（ＩＭＨ）１７２が存在する。

ＮＣＳ１６１のプロセスは、ネットワーク通信の仲介を行う。ＦＣＳ１６２のプロセスは、ファクシミリのＡＰＩを提供する。ＤＣＳ１６３のプロセスは、蓄積文書の配信処理に関する制御を行う。ＥＣＳ１６４のプロセスは、撮像部１２１や印刷部１２２に関する制御を行う。ＭＣＳ１６５のプロセスは、メモリやハードディスクドライブに関する制御を行う。ＯＣＳ１６６のプロセスは、オペレーションパネルに関する制御を行う。ＣＣＳ１６７のプロセスは、認証処理や課金処理に関する制御を行う。ＵＣＳ１６８のプロセスは、ユーザ情報の管理に関する制御を行う。ＳＣＳ１６９のプロセスは、システムの管理に関する制御を行う。

アプリケーション１３１とプラットフォーム１３２の仲介を行うソフトウェア１１２として、仮想アプリケーションサービス（ＶＡＳ）１３５が存在する。ＶＡＳ１３５は、アプリケーション１３１をクライアントとするサーバプロセスとして動作すると共に、プラットフォーム１３２をサーバとするクライアントプロセスとして動作する。ＶＡＳ１３５は、アプリケーション１３１から見てプラットフォーム１３２を隠蔽するラッピング機能を備え、プラットフォーム１３２のバージョンアップに伴うバージョン差を吸収する役割等を担う。

融合機起動部１１３は、融合機１０１の電源投入時に最初に実行される。これにより、ＵＮＩＸ（登録商標）等のＯＳが起動され、アプリケーション１３１やプラットフォーム１３２が起動される。これらのプログラムは、ハードディスクドライブやメモリカードに蓄積されており、ハードディスクドライブやメモリカードから再生されて、メモリに起動されることになる。

図２は、図１の融合機１０１に係るハードウェア構成図である。融合機１０１のハードウェア１１１としては、コントローラ２０１と、オペレーションパネル２０２と、ファクシミリコントロールユニット（ＦＣＵ）２０３と、撮像部１２１と、印刷部１２２が存在する。

コントローラ２０１は、ＣＰＵ２１１、ＡＳＩＣ２１２、ＮＢ２２１、ＳＢ２２２、ＭＥＭ−Ｐ２３１、ＭＥＭ−Ｃ２３２、ＨＤＤ（ハードディスクドライブ）２３３、メモリカードスロット２３４、ＮＩＣ（ネットワークインタフェースコントローラ）２４１、ＵＳＢデバイス２４２、ＩＥＥＥ１３９４デバイス２４３、セントロニクスデバイス２４４により構成される。

ＣＰＵ２１１は、種々の情報処理用のＩＣである。ＡＳＩＣ２１２は、種々の画像処理用のＩＣである。ＮＢ２２１は、コントローラ２０１のノースブリッジである。ＳＢ２２２は、コントローラ２０１のサウスブリッジである。ＭＥＭ−Ｐ２３１は、融合機１０１のシステムメモリである。ＭＥＭ−Ｃ２３２は、融合機１０１のローカルメモリである。ＨＤＤ２３３は、融合機１０１のストレージである。メモリカードスロット２３４は、メモリカード２３５をセットするためのスロットである。ＮＩＣ２４１は、ＭＡＣアドレスによるネットワーク通信用のコントローラである。ＵＳＢデバイス２４２は、ＵＳＢ規格の接続端子を提供するためのデバイスである。ＩＥＥＥ１３９４デバイス２４３は、ＩＥＥＥ１３９４規格の接続端子を提供するためのデバイスである。セントロニクスデバイス２４４は、セントロニクス仕様の接続端子を提供するためのデバイスである。

オペレーションパネル２０２は、オペレータが融合機１０１に入力を行うためのハードウェア（操作部）であると共に、オペレータが融合機１０１から出力を得るためのハードウェア（表示部）である。

図３は、図１の融合機１０１に係る外観図である。図３には、撮像部１２１の位置と、印刷部１２２の位置と、オペレーションパネル２０２の位置が図示されている。図３には更に、読取原稿のセット先となる原稿セット部３０１と、印刷用紙の給紙先となる給紙部３０２と、印刷用紙の排紙先となる排紙部３０３が図示されている。

オペレーションパネル２０２は、図４のように、タッチパネル３１１と、テンキー３１２と、スタートボタン３１３と、リセットボタン３１４と、機能キー３１５と、初期設定ボタン３１６により構成される。タッチパネル３１１は、タッチ操作で入力を行うためのハードウェア（タッチ操作部）であると共に、画面表示で出力を得るためのハードウェア（画面表示部）である。テンキー３１２は、キー（ボタン）操作で数字入力を行うためのハードウェアである。スタートボタン３１３は、ボタン操作でスタート操作を行うためのハードウェアである。リセットボタン３１４は、ボタン操作でリセット操作を行うためのハードウェアである。機能キー３１５は、キー（ボタン）操作でＣＳＤＫアプリ１４６やＪＳＤＫアプリ１４７による操作画面を表示させるためのハードウェアである。初期設定ボタン３１６は、ボタン操作で初期設定画面を表示させるためのハードウェアである。

原稿セット部３０１は、ＡＤＦ（自動原稿搬送装置）３２１と、フラットベッド３２２と、フラットベッドカバー３２３により構成される。給紙部３０２は、４個の給紙トレイにより構成される。排紙部３０３は、１個の排紙トレイにより構成される。ＡＤＦ３２１には、複数枚の読取原稿を重ねてセットすることができる。フラットベッド３２２には、読取原稿を下向きにセットする。

（ＪＳＤＫ）
図５は、図１のＪＳＤＫアプリ１４７とＪＳＤＫプラットフォーム１４８のクラス図である。ＪＳＤＫアプリ１４７とＪＳＤＫプラットフォーム１４８は、全体で１プロセスとして、同一プロセス上で実行される。ＪＳＤＫアプリ１４７とＪＳＤＫプラットフォーム１４８中の各ブロックは、それぞれこの１プロセス上のスレッドとして、スレッド単位で並列的に実行（マルチスレッド）される。ＪＳＤＫアプリ１４７とＪＳＤＫプラットフォーム１４８は、Ｊａｖａ（登録商標）コンパイラによりソースコードからバイトコードに一括翻訳されており、Ｊａｖａ（登録商標）仮想マシンにより逐次実行される。ＪＳＤＫアプリ１４７とＪＳＤＫプラットフォーム１４８は、Ｊａｖａ（登録商標） ２ Ｍｉｃｒｏ ＥｄｉｔｉｏｎのＰｅｒｓｏｎａｌ Ｂａｓｉｓ Ｐｒｏｆｉｌｅをベースとする実装となっている。

ＪＳＤＫアプリ１４７としては、ユーザアプリ５０１と、ＪＳＤＫ ＧＵＩ Ｍａｎａｇｅｒ５１１と、Ｔａｓｋ Ｂａｒ Ｍａｎａｇｅｒ５１２等が存在する。

ユーザアプリ５０１は、融合機１０１のユーザ（例えばベンダ）がＪＳＤＫを使用して開発したＪＳＤＫアプリである。ＪＳＤＫ ＧＵＩ Ｍａｎａｇｅｒ５１１は、他のＪＳＤＫアプリ（ユーザアプリ５０１等）を操作対象とする操作画面の表示等を行うＪＳＤＫアプリである。Ｔａｓｋ Ｂａｒ Ｍａｎａｇｅｒ５１２は、他のＪＳＤＫアプリ（ユーザアプリ５０１等）を操作対象とするタスクバーの表示等を行うＪＳＤＫアプリである。

ユーザアプリ５０１はここでは、スタンドアロンアプリケーションやアプレットと並ぶＪａｖａ（登録商標）アプリケーションであるＸｌｅｔである。ＪＳＤＫ ＧＵＩ Ｍａｎａｇｅｒ５１１とＴａｓｋ Ｂａｒ Ｍａｎａｇｅｒ５１２はここでは、独自の拡張を施したＸｌｅｔ（ＸｌｅｔＥｘ）である。

ＪＳＤＫプラットフォーム１４８には、ＪＳＤＫ Ｍａｉｎ５２１と、ＪＳＤＫ Ｅｎｖｉｒｏｎｍｅｎｔ５２２と、Ｌｏｃａｌｅ Ｍａｎａｇｅｒ５２３と、Ｘｌｅｔ Ｍａｎａｇｅｒ５３１と、Ｍｕｌｔｉ Ｘｌｅｔ Ｍａｎａｇｅｒ５３２と、ＪＳＤＫ Ｍａｎａｇｅｒ５３３と、Ｓｅｎｄ Ｍａｎａｇｅｒ５４１と、Ｅｖｅｎｔ Ｍａｎａｇｅｒ５４２と、Ｓｙｓｔｅｍ Ｅｖｅｎｔ Ｍａｎａｇｅｒ５４３と、Ｐａｎｅｌ Ｍａｎａｇｅｒ５４４と、Ｉｎｓｔａｌｌ Ｍａｎａｇｅｒ５４５と、Ｓｅｒｖｅｒ／Ｃｌｉｅｎｔ Ｍａｎａｇｅｒ５４６等のクラスが存在する。

ＪＳＤＫ Ｍａｉｎ５２１は、ＪＳＤＫシステムの起動設定を行うクラスである。ＪＳＤＫ Ｅｎｖｉｒｏｎｍｅｎｔ５２２は、ＪＳＤＫシステムの起動環境設定を行うクラスである。Ｌｏｃａｌｅ Ｍａｎａｇｅｒ５２３は、国際化対応（言語指定）を行うクラスである。

Ｘｌｅｔ Ｍａｎａｇｅｒ５３１は、１対１でＸｌｅｔのライフサイクルを管理するクラスである。ここでは、５個のＸｌｅｔのライフサイクルが１対１で５個のＸｌｅｔ Ｍａｎａｇｅｒ５３１によって管理される。Ｍｕｌｔｉ Ｘｌｅｔ Ｍａｎａｇｅｒ５３２は、全てのＸｌｅｔ Ｍａｎａｇｅｒ５３１のライフサイクルを管理するクラスである。ここでは、５個のＸｌｅｔ Ｍａｎａｇｅｒ５３１のライフサイクルが全て１個のＭｕｌｔｉ Ｘｌｅｔ Ｍａｎａｇｅｒ５３２によって管理される。ＪＳＤＫ Ｍａｎａｇｅｒ５３３は、ＪＳＤＫシステム全体のライフサイクルを管理するクラスである。例えば、Ｍｕｌｔｉ Ｘｌｅｔ Ｍａｎａｇｅｒ５３２，Ｓｅｎｄ Ｍａｎａｇｅｒ５４１，Ｅｖｅｎｔ Ｍａｎａｇｅｒ５４２，Ｓｙｓｔｅｍ Ｅｖｅｎｔ Ｍａｎａｇｅｒ５４３，Ｐａｎｅｌ Ｍａｎａｇｅｒ５４４，Ｉｎｓｔａｌｌ Ｍａｎａｇｅｒ５４５，Ｓｅｒｖｅｒ／Ｃｌｉｅｎｔ Ｍａｎａｇｅｒ５４６のライフサイクルが、ＪＳＤＫ Ｍａｎａｇｅｒ５３３によって管理される。

Ｓｙｓｔｅｍ Ｅｖｅｎｔ Ｍａｎａｇｅｒ５４３は、図１のプラットフォーム１３２からのシステムイベント（電力モード等）の管理を行うクラスである。Ｐａｎｅｌ Ｍａｎａｇｅｒ５４４は、１個のＸｌｅｔがオペレーションパネル２０２の画面を占有する際の調停等を行うクラスである。Ｉｎｓｔａｌｌ Ｍａｎａｇｅｒ５４５は、ＳＤｃａｒｄやＷｅｂからのインストールやアンインストールの管理を行うクラスである。

図５のＪＳＤＫシステムでは、ＡＰＩとして、ＪＳＤＫ ＡＰＩ５５１とＪＳＤＫ ＡＰＩ５５２等が存在する。なお、ＸｌｅｔとＸｌｅｔＥｘの差異として、オブジェクトにアクセスするのにＪＳＤＫ ＡＰＩ５５１の利用とＪＳＤＫプラットフォーム１４８へのアクセスが可能である点が挙げられる。図１の融合機１０１にはさらに、図５のＪＳＤＫシステムに係る要素として、Ｃ言語とＪａｖａ（登録商標）言語のインタフェースとなるＪＳＤＫ Ｓｅｓｓｉｏｎ５５３とＮａｔｉｖｅ ＪＳＤＫ Ｓｅｓｓｉｏｎ５５４等が存在する。図１の融合機１０１にはさらに、図５のＪＳＤＫシステムに係る要素として、Ｊａｖａ（登録商標）コンパイラによりソースコードからバイトコードに一括翻訳されたＪａｖａ（登録商標）プログラムを逐次実行するためのＪａｖａ（登録商標）仮想マシンであるＣＶＭ（コンパクト仮想マシン）５５５等が存在する。

（ＶＡＳ）
図６は、図１の融合機１０１に実装されているＡＰＩ１３３について説明するための図である。アプリケーション１３１からプラットフォーム１３２への処理要求の授受には、予め定義されている関数により処理要求を受容するＡＰＩ（アプリケーションプログラムインタフェース）１３３が利用される。ＡＰＩ１３３は、数百種類にも至る様々な種類のＡＰＩにより構成されている。

画像形成装置のＡＰＩは、複数種類のＡＰＩにより構成されるＡＰＩ群（ＡＰＩのグループ）として、画像形成装置の機能単位でグルーピングされている。画像形成装置のＡＰＩ群の種類としては、例えば、モノクロプリント機能に係るＡＰＩにより構成される「基本機能用ＡＰＩ群」と、カラープリント機能に係るＡＰＩにより構成される「ＣＯＬＯＲ機能用ＡＰＩ群」と、モノクロコピー機能に係るＡＰＩにより構成される「ＳＣＡＮ機能用ＡＰＩ群」と、ファクシミリ機能に係るＡＰＩにより構成される「ＦＡＸ機能用ＡＰＩ群」と、オペレーションパネル等の操作表示機能に係るＡＰＩにより構成される「ＯＣＳ機能用ＡＰＩ群」と、ローカルストレージ等の記憶機能に係るＡＰＩにより構成される「ＭＣＳ機能用ＡＰＩ群」が存在する。図６には、ＡＰＩ１３３を構成するＡＰＩにより構成されるＡＰＩ群が図示されている。なお、ＡＰＩ群の単位は、例えば、プロセス単位、ライブラリ（スタティックリンクライブラリ、シェアードライブラリ又はダイナミックリンクライブラリ等）単位、又はパッケージ単位（Ｊａｖａ（登録商標）Ｃｌａｓｓライブラリの場合）等によって定められ、また、それぞれの単位内において更に機能ごとに分割したものをＡＰＩ群としてもよい。

以下、融合機１０１におけるＡＰＩ１３３の実装状況のチェック処理について説明する。ここで、ＡＰＩ１３３の実装状況のチェック処理とは、ＪＳＤＫアプリ１４７が利用するＡＰＩが、当該ＪＳＤＫアプリ１４７が動作する融合機１０１において利用可能であるか否かを確認する処理をいう。

図７は、第一の実施の形態におけるＡＰＩの実装状況のチェック処理を説明するためのコラボレーション図である。図８は、第一の実施の形態におけるＡＰＩの実装状況のチェック処理を説明するためのフローチャートである。

まず、ＪＳＤＫアプリ１４７からＶＡＳ１３５に、当該融合機１０１のＡＰＩ群の実装状況に係る情報の提供要求が送信（Ｓ１）される。続いて、ＶＡＳ１３５は、当該融合機１０１内から当該融合機１０１の機種名を取得（Ｓ２）する。続いて、ＶＡＳ１３５は、画像形成装置の機種名と画像形成装置のＡＰＩの実装状況との対応表により、当該融合機１０１の機種名から当該融合機１０１のＡＰＩの実装状況を特定（Ｓ３）する。続いて、ＶＡＳ１３５は、当該融合機１０１のＡＰＩの実装状況から当該融合機１０１のＡＰＩ群の実装状況を特定（Ｓ４）する。例えば、基本機能用ＡＰＩ群を構成するＡＰＩが全種類とも実装されている場合には「基本機能用ＡＰＩ群は実装されている」となる。例えば、ＦＡＸ機能用ＡＰＩ群を構成するＡＰＩが１種類でも実装されていない場合には「ＦＡＸ機能用ＡＰＩ群は実装されていない」となる。続いて、ＶＡＳ１３５からＪＳＤＫアプリ１４７に、当該融合機１０１のＡＰＩ群の実装状況に係る情報が提供（Ｓ５）される。

そして、ＪＳＤＫアプリ１４７は、当該融合機１０１のＡＰＩ群の実装状況に応じて、画像形成処理や画像形成準備処理を実行（Ｓ６）する。例えば、カラーコピー用のアプリケーションであるＪＳＤＫアプリ１４７は、当該融合機１０１に「基本機能用ＡＰＩ群」と「ＣＯＬＯＲ機能用ＡＰＩ群」と「ＳＣＡＮ機能用ＡＰＩ群」とが実装されている場合には、カラーコピー用の操作画面とモノクロコピー用の操作画面とを当該融合機１０１の画面上に表示させる。例えば、当該融合機１０１に「基本機能用ＡＰＩ群」と「ＳＣＡＮ機能用ＡＰＩ群」とが実装されている場合には、モノクロコピー用の操作画面だけを当該融合機１０１の画面上に表示させる。

このように、ＶＡＳ１３５は、当該融合機１０１へのＡＰＩの実装状況に係る情報を、当該融合機１０１へのＡＰＩ群の実装状況に係る情報として、当該融合機１０１のアプリケーション１３１に提供するのである。ＡＰＩ単位でなく、ＡＰＩ群単位（画像形成装置の機能単位）で提供されるのである。これにより、当該融合機１０１のアプリケーション１３１は、数百種類にも至るＡＰＩを個々に取り扱う煩わしさから開放されて、数百種類にも至るＡＰＩを簡単に使い分けることができるのである。さらに、ＡＰＩ群が画像形成装置の機能単位でグルーピングされているため、ＡＰＩ群を簡単に取り扱うことができる点も特筆すべき点である。

ここで、ＪＳＤＫアプリ１４７により当該融合機１０１の画面上に提供される操作画面の具体例について説明する。

図９の第１具体例において、ＪＳＤＫアプリ１４７は、当該融合機１０１のＡＰＩ群の実装状況の違いに応じて、当該融合機１０１の画面上に表示させる操作画面の種類を変化させる。当該融合機１０１に「基本機能用ＡＰＩ群」と「ＣＯＬＯＲ機能用ＡＰＩ群」と「ＳＣＡＮ機能用ＡＰＩ群」とが実装されている場合、図９Ａのように、カラーコピー用の操作画面とモノクロコピー用の操作画面とが当該融合機１０１の画面上に表示（Ｓ６に当たる）される。当該融合機１０１に「基本機能用ＡＰＩ群」と「ＳＣＡＮ機能用ＡＰＩ群」とが実装されている場合には、図９Ｂのように、モノクロコピー用の操作画面だけが当該融合機１０１の画面上に表示（Ｓ６に当たる）される。

図１０の第２具体例において、ＪＳＤＫアプリ１４７は、当該融合機１０１のＡＰＩ群の実装状況の違いに応じて、当該融合機１０１の画面上に表示させる操作画面上の表示物の種類を変化させる。当該融合機１０１に「基本機能用ＡＰＩ群」と「ＣＯＬＯＲ機能用ＡＰＩ群」と「ＳＣＡＮ機能用ＡＰＩ群」とが実装されている場合、図１０Ａのように、コピー用の操作画面上にはモノクロコピー用のボタン群とカラーコピー用のボタン群とが表示（Ｓ６に当たる）される。当該融合機１０１に「基本機能用ＡＰＩ群」と「ＳＣＡＮ機能用ＡＰＩ群」とが実装されている場合には、図１０Ｂのように、コピー用の操作画面上にはモノクロコピー用のボタン群だけが表示（Ｓ６に当たる）される。１個のボタンと１個のＡＰＩとが１対１で対応するようにしてもよいだろう。

なお、図９の第１具体例と図１０の第２具体例とを併用するようにしてもよい。また、図９の第１具体例や図１０の第２具体例を、ＡＰＩ群単位でのＡＰＩの実装状況の違いに応じて実施する代わりにＡＰＩ単位でのＡＰＩの実装状況の違いに応じて実施するようにしてもよい。ただし、ＡＰＩ群単位の方がＡＰＩ単位の方より簡単である。

次に、第二の実施の形態について説明する。第二の実施の形態では、ＡＰＩ１３３は、上位互換性が保証されていることを前提とする。すなわち、古いバージョンのＡＰＩ１３３に基づいて作成されたＪＳＤＫアプリ１４７は、新しいバージョンのＡＰＩ１３３上でも動作することが保証されていることを前提とする。本実施の形態において、かかる保証はＶＡＳ１３５によってもたらされる。すなわち、ＶＡＳ１３５は、ＡＰＩ１３３のバージョンアップと共にバージョンアップされ、古いバージョンのＡＰＩ１３３と新たしいバージョンのＡＰＩ１３３との仕様の差異を吸収することにより、ＡＰＩ１３３の上位互換性を確保する。したがって、ＶＡＳ１３５自体もバージョンを有しており、そのバージョンは、ＡＰＩ１３３における全てのＡＰＩ群を一つにまとめた単位に対するバージョンとしての意味がある。なお、全てのＡＰＩ群を一つにまとめた単位を以下「全ＡＰＩ群」という。

図１１は、第二の実施の形態におけるＡＰＩの実装状況のチェック処理を説明するためのフローチャートである。

ステップＳ２０１において、ＪＳＤＫアプリ１４７は、実装状況管理テーブルをメモリ上に構築し、その内容を初期化する。

図１２は、実装状況管理テーブルの初期化後の状態を示す図である。図１２に示されるように実装状況管理テーブル１４７１は、ＪＳＤＫアプリ１４７が利用するＡＰＩ群及びＡＰＩ（以下、それぞれを「利用ＡＰＩ群」、「利用ＡＰＩ」という。）のそれぞれについて、ＪＳＤＫアプリ１４７の動作確認済みバージョンと、有効性とを管理するテーブルである。動作確認済みバージョンは、当該ＪＳＤＫアプリ１４７の動作確認が行われた環境における各ＡＰＩ群及び各ＡＰＩのバージョンである。後述するように、ＪＳＤＫアプリ１４７は、自らが動作確認済みの各バージョンを認識しており、その認識に基づいて初期化処理において動作確認済みバージョンを実装状況管理テーブル１４７１に登録する。

有効性は、当該融合機１０１における各ＡＰＩ群及びＡＰＩの利用の可否を示す情報であり、ＡＰＩ群については、ＶＯＩＤ（利用不可）、ＲＥＡＤＹ（利用可）、又はＰＡＲＴＬＹ（一部利用可）のいずれかとなる。また、ＡＰＩについては、ＶＯＩＤ又はＲＥＡＤＹのいずれかとなる。各ＡＰＩ群及びＡＰＩの利用の可否については、以降の処理で判別するため、最初は、ＶＯＩＤに初期化される。

実装状況管理テーブル１４７１は、また、ＡＰＩ群とＡＰＩとの階層構造も表現している。すなわち、モノクロスキャンＡＰＩ群には、ｓｃａｎＦｕｎｃ００１、ｓｃａｎＦｕｎｃ００２及びｓｃａｎＦｕｎｃ００３が含まれ、カラースキャンＡＰＩ群には、モノクロスキャンＡＰＩ群に含まれるＡＰＩと、ｓｃａｎＦｕｎｃ００４が含まれることが表現されている。

なお、実装状況管理テーブル１４７１の「ＡＰＩ」の列における「ｓｅｌｆ」という記述は、ＡＰＩ群自身のことを意味する。したがって、図１２において、モノクロスキャンＡＰＩ群の動作確認済みバージョンは、「１．１０」であり、カラースキャンＡＰＩ群の動作確認済みバージョンは、「１．２０」である。

続いて、ＪＳＤＫアプリ１４７は、全ＡＰＩ群（ここではＶＡＳ１３５）の実装状況に係る情報としての実装バージョンをＶＡＳ１３５に問い合わせる（Ｓ２０２）。ここで、実装バージョンとは、当該融合機１０１に実際に実装されているバージョンをいう。

問い合わせは、図１３に示されるような実装状況取得関数を用いて行われる。図１３は、実装状況取得関数の例を示す図である。

実装状況取得関数は、ＡＰＩ群ごと及びＡＰＩごとに用意されている。いずれの関数もＯＵＴ型の引数に当該関数が対応するＡＰＩ群又はＡＰＩのバージョン情報を返却する。ここで、全ＡＰＩ群のバージョン情報の問い合わせには、「ｇｅｔＡＰＩＶｅｒｓｉｏｎ（）」が用いられる。

ｇｅｔＡＰＩＶｅｒｓｉｏｎ（）の呼び出しに応じ、ＶＡＳ１３５は、現在の実装バージョンをその引数に格納して返却する。

続いて、ＪＳＤＫアプリ１４７は、ｇｅｔＡＰＩＶｅｒｓｉｏｎ（）により返却された全ＡＰＩ群の実装バージョンと、実装状況管理テーブル１４７１に登録されている全ＡＰＩ群の動作確認済みバージョンとを比較する（Ｓ２０３）。実装バージョンと動作確認バージョンとが同じか又は実装バージョンの方が新しい場合（Ｓ２０３でＮｏ）、ＪＳＤＫアプリ１４７は、全ＡＰＩ群は利用可能であると判断する（Ｓ２０４）。なお、全ＡＰＩ群が利用可能である場合は、各利用ＡＰＩ群及び各利用ＡＰＩも利用可能であることが保証される。したがって、この場合、ＪＳＤＫアプリ１４７は、図１４に示されるように実装状況管理テーブル１４７１の全てのＡＰＩ群及びＡＰＩの有効性の値を「ＲＥＡＤＹ」とし、処理を終了する。

図１４は、全ＡＰＩ群について実装バージョンが古くないと判断された場合の実装状況管理テーブルの更新状態を示す図である。図１４に示される実装状況管理テーブル１４７１は、全てのＡＰＩ群及びＡＰＩの有効性の値が「ＲＥＡＤＹ」とされている。このように、全ＡＰＩ群に対して、実装バージョンが古くないと判断された場合は、各利用ＡＰＩ群及び利用ＡＰＩのそれぞれのバージョンをチェックする必要はなく、ＪＳＤＫアプリ１４７は、効率的に各利用ＡＰＩ群及びＡＰＩの利用可否の判断を行うことができる。

一方、実装バージョンの方が動作確認バージョンよりも古い場合（Ｓ２０３でＹｅｓ）、ＪＳＤＫアプリ１４７は、各利用ＡＰＩ群（図１２によれば、のモノクロスキャンＡＰＩ群及びカラースキャンＡＰＩ群）のバージョンを実装状況取得関数によってＶＡＳ１３５に問い合わせる（Ｓ２０５）。

続いて、ＪＳＤＫアプリ１４７は、ＶＡＳ１３５より返却される各利用ＡＰＩ群の実装バージョンと、実装状況管理テーブル１４７１に登録されている各利用ＡＰＩ群の動作確認済みバージョンとを比較し（Ｓ２０６）、両者が同一又は実装バージョンの方が新しい利用ＡＰＩ群については利用可能であると判断する（Ｓ２０７）。この場合、当該利用ＡＰＩ群だけでなく、当該利用ＡＰＩ群に属するＡＰＩについても利用可能であることが保証される。したがって、ＪＳＤＫアプリ１４７は、図１５に示されるように、実装状況管理テーブル１４７１における当該利用ＡＰＩ群とそれに属する全ての利用ＡＰＩの有効性の値を「ＲＥＡＤＹ」とする。

図１５は、一つの利用ＡＰＩ群について実装バージョンが古くないと判断された場合の実装状況管理テーブルの更新状態を示す図である。図１５では、モノクロスキャンＡＰＩ群の実装バージョンが古くないと判断され、それに伴って、モノクロスキャンＡＰＩ群とモノクロスキャンＡＰＩ群に属する利用ＡＰＩ（ｓｃａｎＦｕｎｃ００１、ｓｃａｎＦｕｎｃ００２、ｓｃａｎＦｕｎｃ００３）の有効性が「ＲＥＡＤＹ」とされた状態が示されている。このように、一つのＡＰＩ群に対して、実装バージョンが古くないと判断された場合は、当該ＡＰＩ群に属する各利用ＡＰＩのそれぞれのバージョンをチェックする必要はなく、ＪＳＤＫアプリ１４７１は、効率的に各ＡＰＩの利用可否の判断を行うことができる。

一方、実装バージョンの方が古い利用ＡＰＩ群については、当該利用ＡＰＩ群に属する各利用ＡＰＩについて実装バージョンと動作確認済みバージョンとの比較が行われる。すなわち、ＪＳＤＫアプリ１４７は、当該利用ＡＰＩ群に属する各利用ＡＰＩの実装バージョンを実装状況取得関数によってＶＡＳ１３５より取得し（Ｓ２０８）、取得された実装バージョンと、実装状況管理テーブル１３５に登録されている当該利用ＡＰＩの動作確認済みバージョンとを比較する（Ｓ２０９）。

比較の結果、ＪＳＤＫアプリ１４７は、両者が同一又は実装バージョンの方が新しい場合は（Ｓ２０９でＮｏ）、当該利用ＡＰＩは利用可能であると判断し、実装状況管理テーブル１４７１における当該利用ＡＰＩの有効性を「ＲＥＡＤＹ」とする（Ｓ２１０）。一方、実装バージョンの方が古い場合は（Ｓ２０９でＹｅｓ）、当該利用ＡＰＩは利用不可であると判断し（Ｓ２１１）、その有効性は「ＶＯＩＤ」のままとする。

動作確認バージョンの方が古いと判断された各利用ＡＰＩ群について、それぞれの属する全ての利用ＡＰＩに対する利用可否の判断が完了すると（Ｓ２１２でＹｅｓ）、ＪＳＤＫアプリ１４７は、実装状況管理テーブル１４７１を参照して当該各利用ＡＰＩ群の利用の可否を次のように判断する（Ｓ２１３）。まず、利用ＡＰＩ群に属する全ての利用ＡＰＩが利用可能（ＲＥＡＤＹ）な場合は、当該利用ＡＰＩ群は利用可能であると判断し、実装状況管理テーブル１４７１における当該利用ＡＰＩの有効性を「ＲＥＡＤＹ」とする。また、利用ＡＰＩ群に属する全ての利用ＡＰＩが利用不可（ＶＯＩＤ）の場合は、当該利用ＡＰＩ群は利用不可であると判断し、実装状況管理テーブル１４７１における当該利用ＡＰＩ群の有効性を「ＶＯＩＤ」のままとする。また、利用ＡＰＩ群に属する一部のみの利用ＡＰＩが利用可能（ＲＥＡＤＹ）な場合は、当該利用ＡＰＩ群は一部利用可であると判断し、実装状況管理テーブル１４７１における当該利用ＡＰＩ群の有効性を「ＰＡＲＴＬＹ」とする。ただし、当該利用ＡＰＩ群が実現する特有の機能（例えば、カラースキャン機能）にとって必須の利用ＡＰＩの有効性が「ＶＯＩＤ」の場合は、当該利用ＡＰＩ群の有効性を「ＶＯＩＤ」のままとする。

図１６は、各利用ＡＰＩの利用可否の判断結果に基づいて利用ＡＰＩ群の利用可否が判断された場合の実証状況管理テーブルの更新状態を示す図である。図１６の実装状況管理テーブル１４７１には、カラースキャンＡＰＩ群について、それに属するモノクロスキャンＡＰＩ群の有効性が「ＲＥＡＤＹ」であり、ｓｃａｎＦｕｎｃ００４が「ＶＯＩＤ」であることから、その有効性が「ＶＯＩＤ」と判断された結果が反映されている。すなわち、カラースキャン機能を実現するためには、ｓｃａｎＦｕｎｃ００４の利用が必須であるため、カラースキャンＡＰＩ群の有効性は「ＰＡＲＴＬＹ」ではなく、「ＶＯＩＤ」とされる。

続いて、全ての利用ＡＰＩ群に対する利用可否の判断が完了すると（Ｓ２１４でＹｅｓ）、ＪＳＤＫアプリ１４７は、実装状況管理テーブル１４７１を参照して全ＡＰＩ群に対する利用の可否を次のように判断する（Ｓ２１５）。まず、全ての利用ＡＰＩ群が利用可能（ＲＥＡＤＹ）な場合は、全ＡＰＩ群は利用可能であると判断し、実装状況管理テーブル１４７１における全ＡＰＩ群の有効性を「ＲＥＡＤＹ」とする。また、全ＡＰＩ群に属する全ての利用ＡＰＩ群が利用不可（ＶＯＩＤ）の場合は、全ＡＰＩ群は利用不可であると判断し、実装状況管理テーブル１４７１における全ＡＰＩ群の有効性を「ＶＯＩＤ」のままとする。また、全ＡＰＩ群に属する全ての利用ＡＰＩ群が利用不可ではないが、利用不可（ＶＯＩＤ）又は一部利用可（ＰＡＲＴＬＹ）の利用ＡＰＩ群が含まれている場合は、全ＡＰＩ群は一部利用可であると判断し、実装状況管理テーブル１４７１における全ＡＰＩ群の有効性を「ＰＡＲＴＬＹ」とする。

図１７は、各利用ＡＰＩ群の利用可否の判断結果に基づいて全ＡＰＩ群の利用可否が判断された場合の実証状況管理テーブルの更新状態を示す図である。図１７の実装状況管理テーブル１４７１には、モノクロスキャンＡＰＩ群の有効性が「ＲＥＡＤＹ」であり、カラースキャンＡＰＩ群の有効性が「ＶＯＩＤ」であることから、全ＡＰＩ群の有効性が「ＰＡＲＴＬＹ」と判断された結果が反映されている。

以後、ＪＳＤＫアプリ１４７は、実装状況管理テーブル１４７１を参照して図９又は図１０において説明したような画面の表示制御や、その他の動作制御を行う。

次に、ＪＳＤＫアプリ１４７に、自らの動作確認済みバージョンを認識させるための処理について説明する。当該処理は、ＪＳＤＫアプリ１４７の開発又はテスト工程において行われる。

図１８は、ＪＳＤＫアプリに動作確認済みバージョンを認識させるための処理を説明するための図である。

まず、開発者によってＪＳＤＫアプリ１４７のソースコードが作成される（Ｓ２５１）。続いて、ソースコードのコンパイル及びリンクが行われＪＳＤＫアプリ１４７の実行オブジェクトが作成され（Ｓ２５２）、当該実行オブジェクトが所定の記録媒体（例えば、ＳＤカード）に格納される（Ｓ２５３）。当該ＳＤカードが動作確認用の融合機１０１に挿入されると（Ｓ２５４）、ＳＡＳ１８３は、ＪＳＤＫアプリ１４７を当該融合機１０１にインストールし、起動する。ＳＡＳ１８３によって起動されたＪＳＤＫアプリ１４７は、実装状況取得関数を用いて、各利用ＡＰＩ群及び利用ＡＰＩのバージョンを取得し（Ｓ２５５）、その内容をＳＤカードにおける当該ＪＳＤＫアプリ１４７のソースコードに書き込む（Ｓ２５６）。

図１９は、ＪＳＤＫアプリのソースコードに書き込まれたＡＰＩ群及びＡＰＩのバージョンの例を示す図である。図１９では、ＪＳＤＫアプリ１４７のソースコードに埋め込まれているマクロの値としてＡＰＩ群及びＡＰＩのバージョンが書き込まれた例が示されている。以後、ＳＤカードに書き込まれたソースコードに基づいてＪＳＤＫアプリ１４７を再コンパイル及びリンクし、それによって作成された実行モジュールの動作が当該融合機１０１において確認されれば、当該ＪＳＤＫアプリ１４７に動作確認バージョンを認識させたことになる。

なお、動作確認済みバージョンをソースコードに書き込むのではなく、所定のファイルに保存しておき、ＪＳＤＫアプリ１４７がその動作時に当該所定のファイルを読み込むことで動作確認済みバージョンを認識するようにしてもよい。

ところで、第二の実施の形態では、ＪＳＤＫアプリ１４７がＡＰＩ群又はＡＰＩの利用可否の判断を行う例について説明した。しかし、ＡＰＩ群又はＡＰＩの利用可否の判断は必ずしもＪＳＤＫアプリ１４７が行う必要はなく、ＶＡＳ１３５にその判断を行わせ、ＪＳＤＫアプリ１４７はその判断結果を受け取るようにしてもよい。そこで、第三の実施の形態として、ＶＡＳ１３５がＡＰＩ群及びＡＰＩの利用可否の判断を行う例を説明する。なお、以下において明記しない点については第二の実施の形態と同じ条件である。

図２０は、第三の実施の形態におけるＡＰＩの実装状況のチェック処理を説明するためのフローチャートである。

ステップＳ３０１において、ＪＳＤＫアプリ１４７は、実装状況管理テーブルをメモリ上に構築し、その内容を初期化する。この処理によって、実装状況管理テーブル１４７は、図１２に示されるような状態となる。

続いて、ＪＳＤＫアプリ１４７は、全ＡＰＩ群（ここではＶＡＳ１３５）の利用の可否をＶＡＳ１３５に問い合わせる（Ｓ３０２）。

問い合わせは、図１３に示されるような実装状況取得関数を用いて行われる。但し、第三の実施の形態では、その利用方法が異なる。すなわち、第三の実施の形態における実装状況取得関数の引数はＩＮ型の引数であり、呼び出し側のＪＳＤＫアプリ１４７が動作確認済みバージョンを指定する。そして、戻り値としてＲＥＡＤＹ、ＰＡＲＴＬＹ、ＶＯＩＤを示す値として割り当てられた整数値（０、１、２）が返却される。したがって、全ＡＰＩ群の利用可否の問い合わせには、「ｇｅｔＡＰＩＶｅｒｓｉｏｎ（“１．５０”）」が呼び出される。

ｇｅｔＡＰＩＶｅｒｓｉｏｎ（）の呼び出しに応じ、ＶＡＳ１３５は、全ＡＰＩ群の実装バージョンを取得し、その実装バージョンと、ｇｅｔＡＰＩＶｅｒｓｉｏｎ（）の引数に渡された動作確認バージョンとを比較する。比較の結果、実装バージョンと動作確認バージョンとが同じか又は実装バージョンの方が新しい場合、ＶＡＳ１３５は、全ＡＰＩ群は利用可能であると判断し、その判断結果（ＲＥＡＤＹ）を返却する。一方、実装バージョンの方が動作確認バージョンよりも古い場合、ＶＡＳ１３５は、一部利用可（ＰＡＲＴＬＹ）を返却する。

ＶＡＳ１３５から返却された値が「ＲＥＡＤＹ」である場合（Ｓ３０３で「ＲＥＡＤＹ」）、ＪＳＤＫアプリ１４７は、図１４に示されるように実装状況管理テーブル１４７１の全てのＡＰＩ群及びＡＰＩの有効性の値を「ＲＥＡＤＹ」とし、処理を終了する。

一方、ＶＡＳ１３５から返却された値が「ＰＡＲＴＬＹ」である場合（Ｓ３０３で「ＰＡＲＴＬＹ」）、ＪＳＤＫアプリ１４７は、実装状況取得関数の引数に各利用ＡＰＩ群の動作確認済みバージョンを指定することによって各利用ＡＰＩ群の利用の可否をＶＡＳ１３５に問い合わせる（Ｓ３０５）。

実装状況取得関数の呼び出しに応じ、ＶＡＳ１３５は、各利用ＡＰＩ群の実装バージョンを取得し、その実装バージョンと、実装状況取得関数の引数に渡された動作確認バージョンとを比較する。比較の結果、実装バージョンと動作確認バージョンとが同じか又は実装バージョンの方が新しい場合、ＶＡＳ１３５は、当該利用ＡＰＩ群は利用可能であると判断し、その判断結果（ＲＥＡＤＹ）を返却する。一方、実装バージョンの方が動作確認バージョンよりも古い場合、ＶＡＳ１３５は、一部利用可（ＰＡＲＴＬＹ）を返却する。

ＶＡＳ１３５から返却された値が「ＲＥＡＤＹ」である場合（Ｓ３０６で「ＲＥＡＤＹ」）、ＪＳＤＫアプリ１４７は、図１５に示されるように、実装状況管理テーブル１４７１における当該利用ＡＰＩ群とそれに属する全てのＡＰＩの有効性の値を「ＲＥＡＤＹ」とする。

一方、ＶＡＳ１３５から返却された値が「ＰＡＲＴＬＹ」である場合（Ｓ３０６で「ＰＡＲＴＬＹ」）、ＪＳＤＫアプリ１４は、実装状況取得関数の引数に当該利用ＡＰＩ群に属する各利用ＡＰＩの動作確認済みバージョンを指定することによって各利用ＡＰＩの利用の可否をＶＡＳ１３５に問い合わせる（Ｓ３０８）。

実装状況取得関数の呼び出しに応じ、ＶＡＳ１３５は、各利用ＡＰＩの実装バージョンを取得し、その実装バージョンと、実装状況取得関数の引数に渡された動作確認バージョンとを比較する。比較の結果、実装バージョンと動作確認バージョンとが同じか又は実装バージョンの方が新しい場合、ＶＡＳ１３５は、当該利用ＡＰＩは利用可能であると判断し、その判断結果（ＲＥＡＤＹ）を返却する。一方、実装バージョンの方が動作確認バージョンよりも古い場合、ＶＡＳ１３５は、利用不可（ＶＯＩＤ）を返却する。

ＶＡＳ１３５から返却された値が「ＲＥＡＤＹ」である場合（Ｓ３０９で「ＲＥＡＤＹ」）、ＪＳＤＫアプリ１４７は、実装状況管理テーブル１４７１における当該利用ＡＰＩの有効性を「ＲＥＡＤＹ」とする（Ｓ３１０）。一方、ＶＡＳ１３５から返却された値が「ＶＯＩＤ」である場合（Ｓ３０９でＹｅｓ）、ＪＳＤＫアプリ１４７は、実装状況管理テーブル１４７１における当該利用ＡＰＩの有効性を「ＶＯＩＤ」のままとする（Ｓ３１１）。

利用可否が「ＰＡＲＴＬＹ」と判断された利用ＡＰＩ群について、それぞれの属する全ての利用ＡＰＩに対する利用可否の問い合わせが完了すると（Ｓ３１２でＹｅｓ）、ＪＳＤＫアプリ１４７は、実装状況管理テーブル１４７１を参照して当該利用ＡＰＩ群の利用の可否を次のように判断する（Ｓ３１３）。まず、利用ＡＰＩ群に属する全ての利用ＡＰＩが利用可能（ＲＥＡＤＹ）な場合は、当該利用ＡＰＩ群は利用可能であると判断し、実装状況管理テーブル１４７１における当該利用ＡＰＩの有効性を「ＲＥＡＤＹ」とする。また、利用ＡＰＩ群に属する全ての利用ＡＰＩが利用不可（ＶＯＩＤ）の場合は、当該利用ＡＰＩ群は利用不可であると判断し、実装状況管理テーブル１４７１における当該利用ＡＰＩ群の有効性を「ＶＯＩＤ」のままとする。また、利用ＡＰＩ群に属する一部のみの利用ＡＰＩが利用可能（ＲＥＡＤＹ）な場合は、当該利用ＡＰＩ群は一部利用可であると判断し、実装状況管理テーブル１４７１における当該利用ＡＰＩ群の有効性を「ＰＡＲＴＬＹ」とする。ただし、当該利用ＡＰＩ群が実現する特有の機能（例えば、カラースキャン機能）にとって必須の利用ＡＰＩの有効性が「ＶＯＩＤ」の場合は、当該利用ＡＰＩ群の有効性を「ＶＯＩＤ」のままとする。

続いて、全ての利用ＡＰＩ群に対する利用可否の問い合わせが完了すると（Ｓ３１４でＹｅｓ）、ＪＳＤＫアプリ１４７は、実装状況管理テーブル１４７１を参照して全ＡＰＩ群に対する利用の可否を次のように判断する（Ｓ３１５）。まず、全ての利用ＡＰＩ群が利用可能（ＲＥＡＤＹ）な場合は、全ＡＰＩ群は利用可能であると判断し、実装状況管理テーブル１４７１における全ＡＰＩ群の有効性を「ＲＥＡＤＹ」とする。また、全ＡＰＩ群に属する全ての利用ＡＰＩ群が利用不可（ＶＯＩＤ）の場合は、全ＡＰＩ群は利用不可であると判断し、実装状況管理テーブル１４７１における全ＡＰＩ群の有効性を「ＶＯＩＤ」のままとする。また、全ＡＰＩ群に属する全ての利用ＡＰＩ群が利用不可ではないが、利用不可（ＶＯＩＤ）又は一部利用可（ＰＡＲＴＬＹ）の利用ＡＰＩ群が含まれている場合は、全ＡＰＩ群は一部利用可であると判断し、実装状況管理テーブル１４７１における全ＡＰＩ群の有効性を「ＰＡＲＴＬＹ」とする。

このように、ＶＡＳ１３５に利用可否の判断を行わせても、第二の実施の形態の場合と同様の結果を得ることができる。なお、上記においては、ＡＰＩ群ごとＡＰＩごとにＪＳＤＫアプリ１４７から問い合わせが行われる例について説明したが、例えば、ＪＳＤＫアプリ１４７から一括して利用可否の問い合わせが行われ、ＶＡＳ１３５が、ＪＳＤＫアプリ１４７のバックグラウンドにおいて各ＡＰＩ群及び各ＡＰＩの利用可否を判断し、その判断結果に基づいて実装状況管理テーブル１４７１を作成するようにしてもよい。

また、ＶＡＳ１３５が行うものとして説明した処理をＪＳＤＫアプリ１４７を起動するプロセス（例えば、ＳＡＳ１８３）に行わせるようにしてもよい。

ところで、上記において説明した、ＡＰＩの実装状況のチェック処理を実行するタイミングは、ＪＳＤＫアプリ１４７の実行時のみならず、ＪＳＤＫアプリ１４７のインストール時でもよい。図２１は、ＡＰＩの実装状況のチェック処理を伴ったＪＳＤＫアプリのインストール処理を説明するためのフローチャートである。

ユーザが、ＪＳＤＫアプリ１４７（動作確認バージョンの認識済みのもの）の格納されたＳＤカードを融合機１０１に挿入し（Ｓ４０１）、融合機１０１の電源をＯＮにすると（Ｓ４０２）、融合機１０１のＳＡＳ１８３は、アプリケーションのインストール機能を起動し、ＳＤカード内のＪＳＤＫアプリ１４７のリストをオペレーションパネル２０２に表示させる（Ｓ４０３）。

ユーザが、オペレーションパネル２０２に表示されたリストの中からインストール対象とするＪＳＤＫアプリ１４７を選択し、インストールの開始を指示すると（Ｓ４０４）、ＳＡＳ１８３はＳＤカードから選択されたＪＳＤＫアプリ１４７を読み出し、そのコピーをＨＤＤ２３３内に作成する（Ｓ４０５）。コピーが完了すると、ＳＡＳ１８３は、当該ＪＳＤＫアプリ１４７をＡＰＩチェックモードで起動する（Ｓ４０６）。

ＡＰＩチェックモードで起動されたＪＳＤＫアプリ１４７は、本来の機能を実現するための処理ではなく、図８、図１１又は図２０において説明したようなＡＰＩの実装状況のチェック処理を実行し（Ｓ４０７）、そのチェック結果、すなわち、実装状況管理テーブル１４７１の内容を、ＳＤカード又はＨＤＤ２３３内に保存する。

以後、当該ＪＳＤＫアプリ１４７が起動された際は、当該ＪＳＤＫアプリ１４７は、その度ごとに実装状況のチェック処理を行う必要はなく、保存されたチェック結果を参照して図９又は図１０において説明したような画面の表示制御や、その他の動作制御を行えばよい。但し、ＪＳＤＫアプリ１４７のインストール後に、ＶＡＳ１３５やＡＰＩ１３３のバージョンアップが行われる可能性が考えられる。かかる可能性を考慮して、ＳＡＳ１８３にそのようなバージョンアップを常に監視させてもよい。ＳＡＳ１８３は、バージョンアップを検出すると、インストール済みのＪＳＤＫアプリ１４７をＡＰＩチェックモードで起動し、そのチェック結果を改めて保存させるといった具合である。

なお、利用不可と判断されたＡＰＩ群又はＡＰＩについては、ネットワークを介して所定のファイルサーバより自動的にダウンロードすることにより、当該ＡＰＩ群等にかかる機能を利用可能としてもよい。

（変形例）
図１の融合機１０１は、本発明「画像形成装置」の実施例に該当するものであり、図１の融合機１０１によって実行される情報処理は、本発明「情報処理方法」の実施例に該当するものである。図１のＶＡＳ１３５やＪＳＤＫアプリ１４７は、本発明「情報処理プログラム」の実施例に該当するものであり、図１のＶＡＳ１３５やＪＳＤＫアプリ１４７が記録されたＣＤ−ＲＯＭやＤＶＤ−ＲＯＭやＳＤメモリカードは、本発明「記録媒体」の実施例に該当するものである。

本発明の実施例に該当する融合機を表す図である。 図１の融合機に係るハードウェア構成図である。 図１の融合機に係る外観図である。 オペレーションパネルを表す図である。 図１のＪＳＤＫアプリとＪＳＤＫプラットフォームのクラス図である。 図１の融合機に実装されているＡＰＩについて説明するための図である。 第一の実施の形態におけるＡＰＩの実装状況のチェック処理を説明するためのコラボレーション図である。 第一の実施の形態におけるＡＰＩの実装状況のチェック処理を説明するためのフローチャートである。 操作画面の第１具体例について説明するための画面図である。 操作画面の第２具体例について説明するための画面図である。 第二の実施の形態におけるＡＰＩの実装状況のチェック処理を説明するためのフローチャートである。 実装状況管理テーブルの初期化後の状態を示す図である。 実装状況取得関数の例を示す図である。 全ＡＰＩ群について実装バージョンが古くないと判断された場合の実装状況管理テーブルの更新状態を示す図である。 一つの利用ＡＰＩ群について実装バージョンが古くないと判断された場合の実装状況管理テーブルの更新状態を示す図である。 各利用ＡＰＩの利用可否の判断結果に基づいて利用ＡＰＩ群の利用可否が判断された場合の実証状況管理テーブルの更新状態を示す図である。 各利用ＡＰＩ群の利用可否の判断結果に基づいて全ＡＰＩ群の利用可否が判断された場合の実証状況管理テーブルの更新状態を示す図である。 ＪＳＤＫアプリに動作確認済みバージョンを認識させるための処理を説明するための図である。 ＪＳＤＫアプリのソースコードに書き込まれたＡＰＩ群及びＡＰＩのバージョンの例を示す図である。 第三の実施の形態におけるＡＰＩの実装状況のチェック処理を説明するためのフローチャートである。 ＡＰＩの実装状況のチェック処理を伴ったＪＳＤＫアプリのインストール処理を説明するためのフローチャートである。

符号の説明

１０１ 融合機
１１１ ハードウェア
１１２ ソフトウェア
１１３ 融合機起動部
１２１ 撮像部
１２２ 印刷部
１２３ その他のハードウェア
１３１ アプリケーション
１３２ プラットフォーム
１３３ アプリケーションプログラムインタフェース
１３４ エンジンインタフェース
１３５ 仮想アプリケーションサービス
１４１ コピーアプリ
１４２ プリンタアプリ
１４３ スキャナアプリ
１４４ ファクシミリアプリ
１４５ ネットワークファイルアプリ
１４６ ＣＳＤＫアプリ
１４７ ＪＳＤＫアプリ
１４８ ＪＳＤＫプラットフォーム
１５１ コントロールサービス
１５２ システムリソースマネージャ
１５３ ハンドラ
１６１ ネットワークコントロールサービス
１６２ ファクシミリコントロールサービス
１６３ デリバリコントロールサービス
１６４ エンジンコントロールサービス
１６５ メモリコントロールサービス
１６６ オペレーションパネルコントロールサービス
１６７ サーティフィケーションコントロールサービス
１６８ ユーザディレクトリコントロールサービス
１６９ システムコントロールサービス
１７１ ファクシミリコントロールユニットハンドラ
１７２ イメージメモリハンドラ
１８１ Ｗｅｂブラウザ
１８２ Ｗｅｂサーバソフト
１８３ ＳＤＫアプリケーションサービス
２０１ コントローラ
２０２ オペレーションパネル
２０３ ファクシミリコントロールユニット
２１１ ＣＰＵ
２１２ ＡＳＩＣ
２２１ ＮＢ
２２２ ＳＢ
２３１ ＭＥＭ−Ｐ
２３２ ＭＥＭ−Ｃ
２３３ ＨＤＤ
２３４ メモリカードスロット
２３５ メモリカード
２４１ ＮＩＣ
２４２ ＵＳＢデバイス
２４３ ＩＥＥＥ１３９４デバイス
２４４ セントロニクスデバイス
３０１ 原稿セット部
３０２ 給紙部
３０３ 排紙部
３１１ タッチパネル
３１２ テンキー
３１３ スタートボタン
３１４ リセットボタン
３１５ 機能キー
３１６ 初期設定ボタン
３２１ ＡＤＦ
３２２ フラットベッド
３２３ フラットベッドカバー
５０１ ユーザアプリ
５１１ ＪＳＤＫ ＧＵＩ Ｍａｎａｇｅｒ
５１２ Ｔａｓｋ Ｂａｒ Ｍａｎａｇｅｒ
５２１ ＪＳＤＫ Ｍａｉｎ
５２２ ＪＳＤＫ Ｅｎｖｉｒｏｎｍｅｎｔ
５２３ Ｌｏｃａｌｅ Ｍａｎａｇｅｒ
５３１ Ｘｌｅｔ Ｍａｎａｇｅｒ
５３２ Ｍｕｌｔｉ Ｘｌｅｔ Ｍａｎａｇｅｒ
５３３ ＪＳＤＫ Ｍａｎａｇｅｒ
５４１ Ｓｅｎｄ Ｍａｎａｇｅｒ
５４２ Ｅｖｅｎｔ Ｍａｎａｇｅｒ
５４３ Ｓｙｓｔｅｍ Ｅｖｅｎｔ Ｍａｎａｇｅｒ
５４４ Ｐａｎｅｌ Ｍａｎａｇｅｒ
５４５ Ｉｎｓｔａｌｌ Ｍａｎａｇｅｒ
５４６ Ｓｅｒｖｅｒ／Ｃｌｉｅｎｔ Ｍａｎａｇｅｒ
５４７ Ａｕｔｈｅｎｔｉｃａｔｉｏｎ Ｍａｎａｇｅｒ
５５１ ＪＳＤＫ ＡＰＩ
５５２ ＪＳＤＫ ＡＰＩ
５５３ ＪＳＤＫ Ｓｅｓｓｉｏｎ
５５４ Ｎａｔｉｖｅ ＪＳＤＫ Ｓｅｓｓｉｏｎ
５５５ ＣＶＭ

Claims (14)

1. インタフェースが公開されている複数のプログラムを有し、前記インタフェースに基づいて作成されたアプリケーションを実行可能な画像形成装置であって、
   前記アプリケーションからの要求に応じて、複数の前記プログラムによって構成されるグループごとに当該グループに係る実装状況を示す情報を提供する実装状況提供手段を有することを特徴とする画像形成装置。
2. 前記アプリケーションは、前記実装状況提供手段によって提供される前記実装状況を示す情報に基づいて、当該アプリケーションの動作制御を行うことを特徴とする請求項１記載の画像形成装置。
3. 前記アプリケーションは、前記実装状況提供手段によって提供される前記プログラムの実装状況を示す情報に基づいて、当該アプリケーションが提供する機能を制限することを特徴とする請求項２記載の画像形成装置。
4. 前記アプリケーションは、前記実装状況提供手段によって提供される前記プログラムの実装状況を示す情報に基づいて、当該画像形成装置の操作パネルに表示させる画面の内容を変化させることを特徴とする請求項２又は３記載の画像形成装置。
5. 前記アプリケーションは、前記実装状況提供手段によって提供される前記プログラムの実装状況を示す情報に基づいて制限されない機能の操作は可能となるように前記画面を表示させることを特徴とする請求項４記載の画像形成装置。
6. 前記実装状況提供手段によって提供される前記プログラムの実装状況を示す情報に応じて、当該グループに属する前記プログラムごとの実装状況を判断することを特徴とする請求項１乃至５いずれか一項記載の画像形成装置。
7. インタフェースが公開されている複数のプログラムを有し、前記インタフェースに基づいて作成されたアプリケーションを実行可能な画像形成装置における情報処理方法であって、
   前記アプリケーションからの要求に応じて、複数の前記プログラムによって構成されるグループごとに当該グループに係る実装状況を示す情報を提供する実装状況提供手順を有することを特徴とする情報処理方法。
8. 前記アプリケーションは、前記実装状況提供手順において提供される前記実装状況を示す情報に基づいて、当該アプリケーションの動作制御を行うことを特徴とする請求項７記載の情報処理方法。
9. 前記アプリケーションは、前記実装状況提供手順において提供される前記プログラムの実装状況を示す情報に基づいて、当該アプリケーションが提供する機能を制限することを特徴とする請求項８記載の情報処理方法。
10. 前記アプリケーションは、前記実装状況提供手順において提供される前記プログラムの実装状況を示す情報に基づいて、当該画像形成装置の操作パネルに表示させる画面の内容を変化させることを特徴とする請求項８又は９記載の情報処理方法。
11. 前記アプリケーションは、前記実装状況提供手順において提供される前記プログラムの実装状況を示す情報に基づいて制限されない機能の操作は可能となるように前記画面を表示させることを特徴とする請求項１０記載の情報処理方法。
12. 前記実装状況提供手順において提供される前記プログラムの実装状況を示す情報に応じて、当該グループに属する前記プログラムごとの実装状況を判断することを特徴とする請求項７乃至１１いずれか一項記載の情報処理方法。
13. 請求項７乃至１２いずれか一項記載の情報処理方法をコンピュータに実行させるための情報処理プログラム。
14. 請求項１３記載の情報処理プログラムを記録したコンピュータ読取可能な記録媒体。

Images