JP2012018530A - 画像形成装置及びアプリケーション管理プログラム - Google Patents

Abstract

【課題】アプリケーションを管理する管理機能を共通化し、同一の管理画面や操作手順をもってアプリケーションの管理を行えるようにして、ユーザビリティ等を向上させる。
【解決手段】本発明における画像形成装置は、アプリケーションの管理を行う管理手段と、前記管理手段とのＩＦを有する第１のアプリケーションと、前記管理手段とのＩＦを有しない第２のアプリケーションとのインストールを行うインストール手段と、前記管理手段とのＩＦを有し、前記第２のアプリケーションの情報を中継して前記管理手段に通知する管理中継手段と有し、前記インストール手段が、前記第１のアプリケーション又は前記第２のアプリケーションのインストールを行うとき、前記管理手段は、前記第１のアプリケーションのＩＦを介して前記第１のアプリケーションを管理し、前記管理中継手段のＩＦを介して前記第２のアプリケーションを管理する。
【選択図】図３

Description

本発明は、画像形成装置及びアプリケーション管理プログラムに関する。

近年、画像形成装置（MFP：Multi-Function Peripheral）は、ＣＰＵ（Central Processing Unit）の性能向上、メモリの大容量化、通信技術の高速化及びデジタル画像技術の高度化等、ＭＦＰに関連する技術の進化に伴い、単にデジタル複写機としての機能だけでなく、ネットワーク化されたファクシミリ、プリンタ及びスキャナ機能等の様々な機能を搭載し、利用者の環境において様々な場面で利用されている。

このような画像形成装置（以下ＭＦＰという）は、表示部、印刷部、撮像部などの画像形成処理で使用されるハードウェア資源を搭載するとともに、プリンタ、コピーまたはファクシミリなどの各ユーザサービスにそれぞれ固有の処理を行うアプリケーションを複数搭載し、またこれらのアプリケーションとハードウェア資源との間に介在して、ユーザサービスを提供する際に、複数のアプリケーションが共通的に必要とするハードウェア資源の管理、実行制御並びに画像形成処理を行う各種コントロールサービスからなるプラットフォームを備えている。このようなＭＦＰは、アプリケーションとコントロールサービスとを別個に設けているため、装置の出荷後においても、例えばプラグインという形で、新機能や拡張機能を容易にＭＦＰに追加できるようになっている。

ＭＦＰに搭載されるソフトウェアのうち、ＭＦＰ本来の機能を提供する標準アプリケーション（以下標準アプリという）は、出荷時に既にインストールされており、プリンタ、コピーまたはファクシミリといったＭＦＰ本来機能を提供するアプリケーションである。その一方、新機能や拡張機能用のアプリケーション（以下ＳＤＫアプリという）は、出荷後にインストールされることも多く、装置開発元（メーカー）以外にも、第三者（外部ベンダー等）により開発され、また提供されうるアプリケーションである。

この第三者によるアプリケーションに対応するため、ＭＦＰの装置開発元は、ＭＦＰにおいてＳＤＫ（Software Development Kit）といった汎用的なＩ／Ｆ（外部開発者向けのプラットフォーム）を用意することによって、ユーザや外部ベンダーなどがアプリケーションを開発し、画像処理装置での処理内容をある程度自由にカスタマイズできるようにしている。このように、近年の拡張性の高いＭＦＰにおいては、システムの基本機能を実現する自社製の標準アプリや、追加的に導入され、新機能や拡張機能を実現する他社製の外部アプリなど、様々な環境下で開発されたアプリケーションが動作できるよう設計されていることが知られている。

上述したように、近年のＭＦＰにおいては、標準アプリやＳＤＫアプリなど、様々な環境下で開発されたアプリケーションが動作できるようになっている。しかしながら、他社製のＳＤＫアプリなどの管理機構は、標準アプリのそれと異なっており、そのため以下のような問題がある。

図１は、従来のＭＦＰプラットフォーム構成図（アーキテクチャ構成図）である。図１のプラットフォーム１００においては、各種の本体内部の内部機能を利用して、例えばコピーアプリやプリンタアプリといった標準アプリＡ１３０、Ｂ１４０を実現している。また、本体内部の機能を利用したアプリケーション開発を可能にするため、外部公開向けのＳＤＫプラットフォーム１２０が配置され、外部アプリであるＳＤＫアプリＡ１５０、Ｂ１６０に対し、外部公開をしている外部向け機能を提供するものであるが、実質的には本体内部の内部機能との仲介的役割（インターフェース）を担っている。但し、ＳＤＫアプリＡ１５０、Ｂ１６０などからすると、直接的に本体内部の機能は見えないようになっており、あくまでＳＤＫプラットフォーム１２０の外部公開向け機能を利用することで、ＳＤＫアプリＡ１５０、Ｂ１６０自身のアプリケーションを実現する。これは、より一般に汎用的なＩ／Ｆ（ＳＤＫプラットフォーム１０５）を用意することによって、ユーザや外部ベンダーなどのアプリケーション開発を容易にするためである。なおまた第三者への内部機能詳細の公開を防止する意義もある。

さて、図１に示されるように、従来のＭＦＰには、プラットフォーム１００において、標準アプリ管理モジュール１０１を備え、標準アプリを管理するための管理機能（インストール、アンインストール、起動、停止、利用制限等）が搭載されている。また利用可能者判断ＤＢ１０２には、機器管理者があるアプリケーションの利用制限をあるユーザに対し設けた場合の情報を保持するＤＢである。標準アプリ管理モジュール１０１は、利用可能者判断ＤＢ１０２を参照し、ユーザ権限に応じて標準アプリの利用を制限する。

一方、従来のＭＦＰには、ＳＤＫプラットフォーム１２０において、ＳＤＫアプリ管理モジュール１２１を備え、ＳＤＫアプリを管理する管理機能（インストール、アンインストール、起動、停止、利用制限等）を搭載するものの、ＳＤＫアプリＡ１５０、Ｂ１６０の管理は、あくまでＳＤＫアプリ管理モジュール１２１が行っているため、標準アプリとは異なる管理機構によりアプリは管理され、またＳＤＫアプリ管理モジュール１２１には、ユーザ権限に応じてＳＤＫアプリの利用を制限する機能がなかったため、ＳＤＫアプリ単位でユーザの利用を制限することができなかった。このように、標準アプリを管理するための管理機能とＳＤＫアプリを管理するための管理機能とは別途なものであるため、例えば以下のような不便が生じていた。
・ＳＤＫアプリをインストール（又はアンインストール）する際に、標準アプリと操作手順が異なるため、操作性等に不便がある。
・ＳＤＫアプリを起動・停止する際に、標準アプリと操作手順が異なるため、操作性等に不便がある。
・ＳＤＫアプリに対し利用制限をつける場合、ＳＤＫアプリ単位で利用制限をつけることができなかったため、意図しないユーザがＳＤＫアプリを不正に利用できる余地を残していた。

これらの理由からも、ＳＤＫアプリを管理・利用する際のユーザビリティやセキュリティの点に問題があった。なお例えば、特許文献１には、画像形成装置のセキュリティを高める目的で、ＭＦＰ上のアプリケーションのプリンタ、コピーといったＭＦＰの標準機能に関し、利用可能な機能制限する方法が開示されている。しかし、ＭＦＰ上のアプリケーションのプリンタ、コピーといったＭＦＰの標準機能に関し、利用可能な機能制限する方法を開示されているものであるため、ベンダーが開発したＳＤＫアプリを管理し利用可能な機能制限を行うという点にまでは対応できない。

本発明では上記のような問題に鑑みて、アプリケーションを管理する管理機能を全てのアプリケーションで共通化し、同一の管理画面や操作手順をもってアプリケーションの管理を行えるようにして、ユーザビリティ等を向上させる画像形成装置及びアプリケーション管理プログラムを提供することを目的とする。

上記の目的を達成するために、本発明に係る画像形成装置は、アプリケーションを追加可能な画像形成装置であって、アプリケーションの管理を行う管理手段と、前記管理手段とのＩＦを有する第１のアプリケーションと、前記管理手段とのＩＦを有しない第２のアプリケーションとのインストールを行うインストール手段と、
前記管理手段とのＩＦを有し、前記第２のアプリケーションの情報を中継して前記管理手段に通知する管理中継手段と、を有し、前記インストール手段が、前記第１のアプリケーション又は前記第２のアプリケーションのインストールを行うとき、前記管理手段は、前記第１のアプリケーションのＩＦを介して前記第１のアプリケーションを管理し、前記管理中継手段のＩＦを介して前記第２のアプリケーションを管理することを特徴とする。

また、上記の目的を達成するために、上記画像形成装置において、前記インストール手段により、前記第２のアプリケーションがインストールされたとき、前記第２のアプリケーションに対し、前記管理手段とのＩＦを生成するＩＦ生成手段を有し、前記管理手段は、前記第１のアプリケーションのＩＦを介して前記第１のアプリケーションを管理し、前記ＩＦ生成手段により生成されたＩＦを介して前記第２のアプリケーションを管理することを特徴とする。

また、上記の目的を達成するために、上記画像形成装置において、前記管理手段は、アプリケーションの利用可能者判断を行なう利用可能者判断手段を含み、前記管理手段は、前記第１のアプリケーションのＩＦを介して前記第１のアプリケーションの利用可能者判断を行い、前記ＩＦ生成手段により生成されたＩＦを介して前記第２のアプリケーションの利用可能者判断を行なうことを特徴とする。

なお、本発明の構成要素、表現または構成要素の任意の組合せを、方法、装置、システム、コンピュータプログラム、記録媒体、などに適用したものも本発明の態様として有効である。

本発明によれば、アプリケーションを管理する管理機能を全てのアプリケーションで共通化し、同一の管理画面や操作手順をもってアプリケーションの管理を行えるようにして、ユーザビリティ等を向上させる画像形成装置及びアプリケーション管理プログラムを提供することができる。

従来のＭＦＰプラットフォーム構成図である。 本実施形態に係るＭＦＰ１のハードウェア構成の一例を示す。 本実施形態に係るＭＦＰプラットフォーム構成図である。 アプリの一覧表示処理を説明するシーケンス図である。 アプリ管理画面におけるアプリ情報一覧表示例を示す。 標準アプリのインストール処理を説明するシーケンス図である。 ＳＤＫアプリのインストール処理を説明するシーケンス図である。 アプリ管理画面における利用者制限アプリ設定例（その１）を示す。 アプリ管理画面における利用者制限アプリ設定例（その２）を示す。 アプリの利用制限設定処理を説明するシーケンス図である。 標準アプリの利用制限処理を説明するシーケンス図である。 ＳＤＫアプリの利用制限処理を説明するシーケンス図である。

以下、本発明を実施するための最良の形態について図面を参照して説明する。

[システム構成]
（ハードウェア）
まず本実施形態に係るＭＦＰ（画像形成装置）のハードウェア構成について簡単に説明しておく。図２は、本実施形態に係るＭＦＰ１のハードウェア構成の一例を示す。本実施形態に係るＭＦＰ１は、操作パネル１１と、記憶メディアＩ／Ｆ１２と、コントローラ１３と、データ通信Ｉ／Ｆ１４と、スキャナ１５と、プロッタ１６と、ＨＤＤ（Hard Disk Drive）１７とから構成され、それぞれ相互に接続されている。

操作パネル１１は、入力装置１１aと表示装置１１bとを有しており、入力装置１１aは、ハードキーなどで構成され、装置本体に各操作信号を入力するのに用いられる。また、表示装置１１bは、ディスプレイなどで構成され、例えば画像形成動作に関する各種情報を表示する。データ通信Ｉ／Ｆ１４は、インタフェース装置１４aを有しており、画像形成装置をネットワークやファックスなどのデータ伝送路に接続するインタフェースである。ＨＤＤ１７は、画像形成装置で取り扱われる受信文書データや読み取り画像データ、各アプリケーションにより利用されるデータなど、各種データを格納している。また、ＨＤＤ１７は、これらの各種データを、所定のファイルシステムやＤＢ（Data Base）により管理している。

ＨＤＤ１７に格納される各種データの中には、記録媒体１２bから入力されるデータを含む。記録媒体１２bは、記憶メディアＩ／Ｆ１２が有するドライブ装置１２aにセットされ各種データが記録媒体１２bからドライブ装置１２aを介してＨＤＤ１７に格納される。

コントローラ１３は、ＲＯＭ（Read Only Memory）１３a、ＲＡＭ（Random Access Memory）１３b、及びＣＰＵ（Central Processing Unit）１３cとを有しており、ＲＯＭ１３aは、画像形成装置が起動されるときに実行されるプログラムや各種データを格納している。また、ＲＡＭ１３bは、ＲＯＭ１３aやＨＤＤ１７から読み出された各種プログラムやデータを一時保持する。更に、ＣＰＵ１３cは、ＲＡＭ１３bが一時保持しているプログラムを実行する。コントローラ１３は、例えば、データ通信Ｉ／Ｆ１４を介して印刷データを受信した場合に、ＲＯＭ１３aからＲＡＭ１３b上に読み出された、ＰＤＬ（Page Description Language）を解釈可能なプログラム（ＰＤＬパーサ）をＣＰＵ１３cにより実行し、印刷データを解釈してビットマップイメージを生成する。

スキャナ１５は、画像読取装置１５aを有しており、読み取り面に配置された原稿を光学的に読み取り画像データを生成する。プロッタ１６は、印刷装置１６aを有しており、例えば、電子写真プロセス方式によってビットマップイメージを記録紙に印刷する。

このように、本実施形態に係るＭＦＰは、上記ハードウェア構成により、コピー、スキャナ、プリント、ファクシミリなど画像形成に係る基本的な機能を実現している。

（機能構成）
図３は、本実施形態に係るＭＦＰプラットフォーム構成図（アーキテクチャ構成図）である。本実施形態に係るＭＦＰ１は、標準アプリ及びＳＤＫアプリのアプリ管理を、プラットフォーム２００のアプリ管理モジュール２０１に一任することにより、全てのアプリ管理についてその一元化を図る。ここで、アプリ管理モジュール２０１が標準アプリ及びＳＤＫアプリの両方のアプリを管理するためには、標準アプリ及びＳＤＫアプリは、アプリ管理モジュール２０１に対するアプリ管理ＩＦを実装する必要がある。

しかしながら、既存（従来）のＳＤＫアプリはアプリ管理モジュール２０１に対するアプリ管理ＩＦを実装していないため（図１参照）、このままでは本実施形態に係るアーキテクチャに適用できない。といはいえ単純にＳＤＫアプリがアプリ管理ＩＦを実装するようにすればよいかというと問題がある。アプリ管理ＩＦは装置開発元（メーカー）の資産（即ち機密事項）であるため、ＳＤＫアプリ開発者である外部ベンダーにこれを詳細に公開することができないからである。そのため本実施形態に係るＭＦＰは、ＳＤＫプラットフォーム２２０には、ＳＤＫアプリ管理中継モジュール２２２やＳＤＫアプリ管理ＩＦ生成部２２１が設けられている。ＳＤＫアプリ管理中継モジュール２２２は、アプリのインストール時、アプリ管理モジュール２０１に代わってインストール可能なＳＤＫアプリの情報を取得し、アプリ管理モジュール２０１にその情報を伝達する。またＳＤＫアプリ管理ＩＦ生成部２２１は、ＳＤＫアプリがインストールされる度に、アプリ管理モジュール２０１に対するアプリ管理ＩＦをＳＤＫアプリロジック（内）に生成し、そのＳＤＫアプリと関連付ける。このような処理を行うことで、インストール時やインストール後において、外部ベンダーにアプリ管理モジュール２０１に対するアプリ管理ＩＦを公開することなく、アプリ管理モジュール２０１に対するアプリ管理ＩＦを実装していない既存のＳＤＫアプリもアプリ管理モジュール２０１にて管理できるようになる。以下説明していく。

プラットフォーム２００は、アプリ管理モジュール２０１を備え、標準アプリ及びＳＤＫアプリを管理するための管理機能（インストール、アンインストール、起動、停止、利用制限等）が搭載されている。また利用可能者判断ＤＢ２０２には、機器管理者があるアプリケーションの利用制限をあるユーザに対し設けた場合の情報を保持するＤＢである。アプリ管理モジュール２０１は、利用可能者判断ＤＢ２０２を参照し、標準アプリ及びＳＤＫアプリの利用を制限する。

標準アプリＡ２３０、標準アプリＢ２４０は、例えばコピーやプリンタといったＭＦＰ本来機能を提供するアプリケーションである。例えば標準アプリＡ２３０は、ＵＩ２３１と標準アプリロジック２３２で構成される。ＵＩ２３１は標準アプリＡ２３０の画面構成を持ち、標準アプリロジックＡ２３２に対し、各種要求を行う。標準アプリロジックＡ２３２は、ＵＩ２３１からの要求を解釈し、プラットフォーム２００の各内部機能部（非図示）に対して機能の実行要求等を行う。また、標準アプリロジックＡ２３２はアプリ管理ＩＦ２３３を実装（実現）しており、アプリ管理モジュール２０１が提供するＩＦによりこのＩＦを実装したこのロジックは、アプリ管理モジュール２０１によって管理されるための機能を持っている。

ＳＤＫプラットフォーム２２０は、上述のＳＤＫアプリ管理ＩＦ生成部２２１を搭載する。ＳＤＫアプリ管理ＩＦ生成部２２１は、アプリ管理モジュール２０１で管理可能なＳＤＫ用のアプリ管理ＩＦを生成する。このＳＤＫ用のアプリ管理ＩＦは、ＳＤＫアプリがインストールされる都度生成され、そのＳＤＫアプリと関連付けられ搭載される。例えばＳＤＫアプリＡの管理ＩＦ２５３は、ＳＤＫアプリＡ２５０がインストールされＳＤＫアプリロジックＡ２５２が搭載されることにより生成され、またＳＤＫアプリＡ２５０と関連付けられる。

ＳＤＫアプリＡ２５０、ＳＤＫアプリＢ２６０は、例えば新機能や拡張機能を提供するアプリケーションであり、外部ベンダー等により開発されたアプリケーションである。例えばＳＤＫアプリロジックＡ２５２は、ＳＤＫアプリＡ２５０のＵＩ２５１からの要求を解釈し、プラットフォーム２００の各内部機能部（非図示）に対して機能の実行要求等を行う。またＳＤＫアプリロジックＡ２５２は、ＳＤＫアプリ管理ＩＦ生成部２２１によりアプリ管理ＩＦ２５３を実装（実現）しており、アプリ管理モジュール２０１が提供するＩＦによりこのＩＦを実装したこのロジックは、アプリ管理モジュール２０１によって管理されるための機能を持っている。

ＳＤＫアプリ管理中継モジュール２２２は、インストール時、インストール可能なＳＤＫアプリの情報を取得し、アプリ管理モジュール２０１にその情報を伝達する。ＳＤＫアプリ管理中継モジュール２２２は、中継を行うため当然ながらアプリ管理モジュール２０１とのＩＦを有する。

以上のように、プラットフォーム２００のアプリ管理モジュール２０１は、アプリ管理を行うためのＩＦ（即ちアプリ管理ＩＦ）を提供している。また標準アプリロジック及びＳＤＫアプリロジックを含むアプリロジックは、それぞれのＵＩからの機能実行要求を解釈するとともに、アプリ管理モジュール２０１に対するアプリ管理ＩＦを実装しているため、アプリ管理モジュール２０１により管理されることが可能となっている。このように標準アプリロジック及びＳＤＫアプリいずれもに対し、アプリ管理モジュール２０１に対する共通のアプリ管理ＩＦが提供されるので、ユーザはアプリの種類を意識することなく共通の管理が可能となる。つまりアプリ管理モジュール２０１が各アプリの管理を行う場合、アプリの各アプリ管理ＩＦを通じ、共通の管理要求でもってアプリ管理を実現できる。

[実施形態１]
本実施形態の概要としては、例えばアプリケーションのソフトウェアが入った記録媒体（メモリ等）をＭＦＰ１に接続すると、ＭＦＰ１の表示装置１１（タッチパネル・ディスプレイ）にアプリ管理画面において、インストール可能なアプリケーション一覧が表示される。この中からユーザがインストールを行おうとするアプリケーションを選択しインストール操作を行うことにより、そのアプリケーションのインストール処理が行われる。ここで、アプリケーションとは、標準アプリ及びＳＤＫアプリを含み、いずれのアプリであっても同一の管理画面から同一の操作手順をもってインストール操作を行うことができる。

（アプリの一覧表示処理）
図４は、アプリの一覧表示処理を説明するシーケンス図である。以下、図面を参照しながら説明する。なお、標準アプリについては出荷時既に搭載されているものと述べたが、例えば装置開発元（メーカー）が新たな標準アプリを出荷後の時点で開発したケースなど、事後的にインストールを行うことも可能である。

アプリケーションのソフトウェアが入った記録媒体がＭＦＰ１に接続されたタイミング、もしくは明示的にユーザがアプリ管理画面においてインストール可能なアプリケーション一覧の表示を操作したタイミング等により、アプリ管理モジュール２０１に対しインストール可能なアプリケーション情報の一覧表示の要求が行われる（Ｓ１０）。

アプリ管理モジュール２０１は、標準アプリについては、自らインストール可能な標準アプリ情報の取得する（Ｓ１１）。一方ＳＤＫアプリについては、ＳＤＫアプリ管理中継モジュール２２２に対しＳＤＫアプリ情報取得要求を行うと（Ｓ１２）、ＳＤＫアプリ管理中継モジュール２２２がインストール可能なＳＤＫアプリ情報の取得を行い（Ｓ１３）、これをアプリ管理モジュール２０１に返答する（Ｓ１４）。アプリ管理モジュール２０１がＳＤＫアプリについて、ＳＤＫアプリ管理中継モジュール２２２を介してＳＤＫアプリ情報を取得するのは、アプリ管理モジュール２０１は、プラットフォームが異なるよう設計されているため、直接ＳＤＫアプリとのやり取りができないためである（図３参照）。

アプリ管理モジュール２０１は、取得したインストール可能な標準アプリ情報及びＳＤＫアプリ情報をアプリ管理画面において一覧表示する。

図５は、アプリ管理画面におけるアプリ情報一覧表示例を示す。図に示されるように、標準アプリ及びＳＤＫアプリを含め同一のアプリ管理画面においてインストール可能なアプリ情報が一覧表示されるので、インストール時ユーザはアプリの種類を意識せず、インストール操作を進めることができる。

（アプリのインストール処理１：標準アプリ）
図６は、標準アプリのインストール処理を説明するシーケンス図である。次に、図５のアプリ管理画面のアプリ情報一覧から、インストール可能なアプリのうち、ユーザが標準アプリＡのインストールを選択したものとする。

標準アプリＡインストール指示を受けると（Ｓ２０）、アプリ管理モジュール２０１は、標準アプリインストールモジュールに対し、標準アプリＡのインストール要求を行う（Ｓ２１）。標準アプリインストールモジュールは、標準アプリのインストール処理を担う機能部である（図３では非図示であるがプラットフォーム２００内に配置される）。そして標準アプリＡのインストール処理により、ＵＩ２３１、標準アプリＡロジック２３２、アプリ管理ＩＦ２３３がＭＦＰ１に組み込まれる（Ｓ２２）。標準アプリインストールモジュールは、インストールが完了すると、アプリ管理モジュール２０１に対しインストール完了通知を行う（Ｓ２３）。

インストールが完了すると、アプリ管理モジュール２０１は、標準アプリＡのアプリ管理ＩＦ２３３に対し、アプリ管理ＩＦの情報の取得要求を行う（Ｓ２４）。これを受け、アプリ管理ＩＦ２３３は、アプリ管理ＩＦの情報を返答する（Ｓ２５）。

アプリ管理モジュール２０１は、利用可能者判断ＤＢ２０２に対し、標準アプリＡのアプリ管理ＩＦの情報の登録要求を行う（Ｓ２６）。これを受け、利用可能者判断ＤＢ２０２は、標準アプリＡのアプリ管理ＩＦの情報の登録を行い、登録完了通知を返答する（Ｓ２７）。

（アプリのインストール処理２：ＳＤＫアプリ）
図７は、ＳＤＫアプリのインストール処理を説明するシーケンス図である。図５のアプリ管理画面のアプリ情報一覧から、インストール可能なアプリのうち、ユーザがＳＤＫアプリＡのインストールを選択したものとする。

ＳＤＫアプリＡインストール指示を受けると（Ｓ２０）、アプリ管理モジュール２０１は、ＳＤＫアプリ管理中継モジュール２２２に対し、ＳＤＫアプリＡのインストール要求を行うと（Ｓ３１）、ＳＤＫアプリ管理中継モジュール２２２がＳＤＫアプリインストールモジュールに対し、ＳＤＫアプリＡのインストール要求を行う（Ｓ３２）。ＳＤＫアプリインストールモジュールは、ＳＤＫアプリのインストール処理を担う機能部である（図３では非図示であるがＳＤＫプラットフォーム２２０内に配置される）。そしてＳＤＫアプリＡのインストール処理により、ＵＩ２５１、ＳＤＫアプリＡロジック２５２がＭＦＰ１に組み込まれる（Ｓ３３）。ＳＤＫアプリインストールモジュールは、インストールが完了すると、アプリ管理モジュール２０１に対しインストール完了通知を行う（Ｓ３４）。

インストールが完了すると、アプリ管理モジュール２０１は、ＳＤＫアプリ管理ＩＦ生成部２２１に対し、アプリ管理ＩＦ生成要求を行う（Ｓ３５）。ＳＤＫアプリ管理ＩＦ生成部２２１は、ＳＤＫアプリＡのアプリ管理ＩＦ２５３を生成する（Ｓ３６）。ＳＤＫアプリ管理ＩＦ生成部２２１は、アプリ管理ＩＦ２５３の生成が完了すると、アプリ管理モジュール２０１に対しアプリ管理ＩＦ生成完了通知を行う（Ｓ３７）。

アプリ管理ＩＦ２５３が生成されると、アプリ管理モジュール２０１は、ＳＤＫアプリＡのアプリ管理ＩＦ２５３に対し、アプリ管理ＩＦの情報の取得要求を行う（Ｓ３８）。これを受け、アプリ管理ＩＦ２５３は、アプリ管理ＩＦ２５３の情報を返答する（Ｓ３９）。

アプリ管理モジュール２０１は、利用可能者判断ＤＢ２０２に対し、ＳＤＫアプリＡのアプリ管理ＩＦ２５３の情報の登録要求を行う（Ｓ４０）。これを受け、利用可能者判断ＤＢ２０２は、ＳＤＫアプリＡのアプリ管理ＩＦ２５３の情報の登録を行い、登録完了通知を返答する（Ｓ４１）。

ＳＤＫアプリを開発した外部ベンダー視点で見た場合、ＳＤＫアプリＡ２５０とアプリ管理モジュール２０１とのやり取りはブラックボックス化されているため、外部ベンダーに対しては、アプリ管理モジュール２０１のアプリ管理ＩＦを公開することなく、ＳＤＫアプリＡ２５０はアプリ管理モジュール２０１の管理下によるインストールを行うことができるようになっている。

以上のように、本実施形態に係るＭＦＰ１は、アプリ管理画面において、インストール可能なアプリケーション一覧を表示し、またこの中からユーザがインストールを行おうとするアプリケーション（標準アプリ及びＳＤＫアプリを含む）を選択しインストール操作を行うことにより、そのアプリケーションのインストール処理を行うので、ユーザはアプリの種類を意識せず、標準アプリ及びＳＤＫアプリのアプリであっても同一の管理画面から同一の操作手順をもってインストール操作を行うことができる。

また、同一の管理画面から同一の操作手順をもってインストール操作を行うにあたって、標準アプリ及びＳＤＫアプリにおいて共通のアプリ管理モジュール２０１を利用する必要があるところ、ＳＤＫアプリ管理中継モジュール２２２がＳＤＫアプリとアプリ管理モジュール２０１との中継機能を担うので、外部ベンダーに対してはアプリ管理モジュール２０１のアプリ管理ＩＦを公開することなく、上述のように標準アプリ及びＳＤＫアプリのアプリであっても同一の管理画面から同一の操作手順をもってインストール操作を行うことができる。

なおまた、インストール処理過程において、ＳＤＫアプリに対してＳＤＫアプリ管理ＩＦ生成部２２１によりアプリ管理モジュール２０１に対するアプリ管理ＩＦが生成されるので、ＳＤＫアプリはアプリ管理モジュール２０１アプリ管理ＩＦを実装する必要がない。つまりＳＤＫアプリのインストール後においても、外部ベンダーに対してはアプリ管理モジュール２０１のアプリ管理ＩＦを公開することなく、標準アプリ及びＳＤＫアプリのアプリであっても同一の管理画面から同一の操作手順をもってアプリ管理（アンインストール、起動、停止、利用制限等）を行うことができる。利用制限については実施形態２で詳しく後述する。

[実施形態２]
本実施形態の概要としては、ＭＦＰ１の表示装置１１（タッチパネル・ディスプレイ）にアプリ管理画面において、標準アプリ及びＳＤＫアプリを利用するユーザの利用者制限を同一の管理画面から同一の操作手順をもって設定することができるものである。これは実施形態１のインストール処理過程において、ＳＤＫアプリに対してＳＤＫアプリ管理ＩＦ生成部２２１によりアプリ管理モジュール２０１に対するアプリ管理ＩＦが生成されたことにより可能となっている。以下説明する。

（アプリの利用制限設定処理）
図８は、アプリ管理画面における利用者制限アプリ設定例（その１）を示す。ここでは、上述のインストール処理を経て、ＭＦＰ１には、標準アプリＡ２３０、標準アプリＢ２４０、ＳＤＫアプリＡ２５０、ＳＤＫアプリＢ２６０の４つのアプリがインストールされているものとする。アプリ管理画面において、アプリの利用者制限を設定する場合、まず制限対象とするアプリケーションを選択する。例えばＳＤＫアプリＡ２５０に対して利用者制限を行いたい場合、リストから「ＳＤＫアプリＡ」を選択し、「ユーザ権限設定」ボタンを押下する（図９へ遷移）。

図９は、アプリ管理画面における利用者制限アプリ設定例（その２）を示す。ＳＤＫアプリＡの利用者制限を設定する場合、制限の対象となる具体的なユーザ選択及びそのユーザに与えるユーザ権限を設定する。例えば、ユーザ「Ｕｓｅｒ０１」に対し「ｇｕｅｓｔ」レベルの権限を選択し、「ＯＫ」ボタンを押下する。これにより、ユーザ「Ｕｓｅｒ０１」は「ｇｕｅｓｔ」に与えられた権限の範囲内でＳＤＫアプリＡを利用することができるようになる。

図１０は、アプリの利用制限設定処理を説明するシーケンス図である。上述図８、９の操作により、利用可能者設定指示がなされると（Ｓ５０）、アプリ管理モジュール２０１は、
利用可能者判断ＤＢ２０２に対し、利用可能者設定要求を行う（Ｓ５１）。これを受けて利用可能者判断ＤＢ２０２は、利用可能者設定を行い（Ｓ５２）、アプリ管理モジュール２０１に対し、利用可能者設定完了通知を行う（Ｓ５３）。

例えば上述の如く、図８、９において、ユーザ「Ｕｓｅｒ０１」に対し「ｇｕｅｓｔ」レベルの権限が選択された場合、利用可能者判断ＤＢ２０２は、「ＳＤＫアプリＡ」−「Ｕｓｅｒ０１」−「ｇｕｅｓｔ」というように利用可能者の設定（登録）を行う。

なお、利用可能者判断ＤＢ２０２は、利用可能者をＤＢ登録し、また利用可能者をＤＢに基づき判断する（後述）ことから、利用可能者判断部とも読み替えることができる。また本シーケンスでは、利用可能者設定登録を説明したが、利用可能者の変更や削除についても同様に行えることは言うまでもない。

（アプリの利用制限処理１：標準アプリ）
図１１は、標準アプリの利用制限処理を説明するシーケンス図である。上述の利用可能者設定がなされてから、利用可能者設定に基づき、ユーザに対し標準アプリの利用制限を行う処理について説明する。

標準アプリＡのＵＩ２５１は、ユーザに対し標準アプリＡのＵＩ（画面）を提供する。ユーザは、ＵＩ（画面）を操作して標準アプリＡの実行（利用）要求を行うとする（Ｓ６０）。ＵＩ２５１は、これを受けて標準アプリＡロジック２３２に対し実行（利用）要求を行う（Ｓ６１）。標準アプリＡロジック２３２は、アプリを実行する前にそのユーザ（利用者）が利用可能者であるか否かを判断する必要があるため、アプリＩＦ２３３を介して、アプリ管理を統括的に行っているアプリ管理モジュール２０１に対し、利用可能者判断要求を行う（Ｓ６２）。判断にあたっては、アプリ名、利用者名の情報が必要なため、利用可能者判断要求にこれら情報が含まれる。

アプリ管理モジュール２０１は、これを受け、利用可能者判断ＤＢ２０２に対し、利用可能者判断要求を行うと（Ｓ６３）、利用可能者判断ＤＢ２０２は、利用可能者をＤＢに基づき利用可能者か否かの判断を行なう（Ｓ６４）。なお上述の如く利用可能者判断ＤＢ２０２は、利用可能者をＤＢ登録し、また利用可能者をＤＢに基づき判断することから、利用可能者判断部とも読み替えることができる。

利用可能者判断ＤＢ２０２は、利用可能者判断結果通知を行う（Ｓ６５）。結果は、実行ＯＫ又は実行ＮＧが通知される。また実行ＯＫの場合、そのユーザ権限が通知される。

アプリ管理モジュール２０１は、利用可能者判断結果通知をアプリＩＦ２３３へ返答する。そしてこの利用可能者判断結果通知は、アプリＩＦ２３３から標準アプリＡロジック２３２に通知される（Ｓ６６）。標準アプリＡロジック２３２は、利用可能者判断結果通知に従って、実行ＯＫの場合、ユーザ権限の範囲内において標準アプリＡを実行する。実行ＮＧの場合、標準アプリＡを実行しない。標準アプリＡの実行結果は、ＵＩ２５１、つまりユーザに対して通知される（Ｓ６８）。

（アプリの利用制限処理２：ＳＤＫアプリ）
図１２は、ＳＤＫアプリの利用制限処理を説明するシーケンス図である。上述の利用可能者設定がなされてから、利用可能者設定に基づき、ユーザに対しＳＤＫアプリの利用制限を行う処理を示す。但しここでは、図１１の標準アプリのケースと同様で、図１１の標準アプリを図１２でＳＤＫアプリに読み替えればよいため、再度の説明は省略するものとする。

いずれのケースにおいても、アプリケーションは、アプリ管理ＩＦを介し、アプリ管理モジュール２０１（さらには利用可能者判断ＤＢ２０２）を利用できる。つまり、アプリ管理画面において、ユーザはアプリの種類を意識せず、標準アプリ及びＳＤＫアプリのアプリであっても同一の管理画面から同一の操作手順をもってアプリの利用制限の設定を行うことができる。

[補足]
以上の実施形態についてその内容を整理しここで補足しておく。これまで、アプリ管理には、アプリのインストール、アンインストール、起動、停止、利用制限等が挙げられると述べた。

（実施形態１について）
実施形態１においては、インストール時にＳＤＫアプリ管理中継モジュール２２２がＳＤＫアプリとアプリ管理モジュール２０１との中継機能を担うことにより、標準アプリ及びＳＤＫアプリのいずれのアプリであっても同一の管理画面から同一の操作手順をもってインストール操作を行うことができることを説明した。またその中継機能を具現化した例として、アプリ管理画面において、標準アプリ及びＳＤＫアプリを含め、インストール可能なアプリケーション一覧を表示する実施形態を示した。

また、実施形態１のインストール処理過程において、ＳＤＫアプリに対してＳＤＫアプリ管理ＩＦ生成部２２１によりアプリ管理モジュール２０１に対するアプリ管理ＩＦが生成される。これはインストール後において、標準アプリと同様に、ＳＤＫアプリもまたアプリ管理モジュール２０１によりアプリ管理を目的とするためである。

（実施形態２について）
そしてインストール後においては、標準アプリと同様、ＳＤＫアプリもまたアプリ管理モジュール２０１によりアプリ管理できるようになる。実施形態１のインストール処理過程において、ＳＤＫアプリに対してＳＤＫアプリ管理ＩＦ生成部２２１によりアプリ管理モジュール２０１に対するアプリ管理ＩＦが生成されたからである。その結果、アンインストール、起動、停止、利用制限等を含め、アプリ管理が一元的に、例えば標準アプリ及びＳＤＫアプリいずれのアプリであっても同一の管理画面から同一の操作手順をもってアプリ管理（アンインストール、起動、停止、利用制限等）を行うことができる。これを踏まえ実施形態２においては、そのアプリ管理うちの一つを具現化した例として、アプリ管理画面において、標準アプリ及びＳＤＫアプリに対する利用制限を行う実施形態を示したものである。従って、アプリ管理うちアンインストール、起動、停止等についても、標準アプリ及びＳＤＫアプリいずれのアプリであっても同一の管理画面から同一の操作手順をもって行うことができることは言うまでもない。

[総括]
以上本実施形態に係るＭＦＰ１は、アプリ管理（インストール、アンインストール、起動、停止、利用制限等）に利用するアプリ管理モジュールを標準アプリとＳＤＫアプリで共通化することで、これらアプリ管理の操作を同一の操作画面から同一の操作でもって行うことができる。具体的には、
・標準アプリと同じ手順でＳＤＫアプリのインストール・アンインストールを操作できる。
・標準アプリと同じ手順でＳＤＫアプリの起動・停止を操作できる。
・標準アプリと同じ操作でＳＤＫアプリの利用制限を行える。ＳＤＫアプリ単位でも利用制限が付加できるため、アプリの目的に応じて利用可能なユーザの設定を行うことができるため、予期せぬユーザが機器に影響を及ぼすようなアプリを利用不可にできる。
・アプリ管理の操作手順が標準アプリとＳＤＫアプリで統一されるため、複数の操作手順を使用する必要がなくなり、アプリ管理方法を習得が容易となる。またアプリ管理コストを抑えることができる。

以上即ち本実施形態によれば、アプリケーションを管理する管理機能を全てのアプリケーションで共通化し、同一の管理画面や操作手順をもってアプリケーションの管理を行えるようにして、ユーザビリティ等を向上させる画像形成装置等を提供することが可能となる。

各実施形態に基づき本発明の説明を行ってきたが、上記各実施形態にあげたその他の要素との組み合わせなど、ここで示した要件に本発明が限定されるものではない。これらの点に関しては、本発明の主旨をそこなわない範囲で変更することが可能であり、その応用形態に応じて適切に定めることができる。また、本発明の構成要素、表現または構成要素の任意の組合せを、方法、装置、システム、コンピュータプログラム、記録媒体、などに適用したものも本発明の態様として有効である。

１ ＭＦＰ
１１ 操作部（操作パネル）
１１ａ 入力装置
１１ｂ 表示装置
１２ 記憶メディアＩ／Ｆ
１２ａ ドライブ装置
１２ｂ 記録媒体
１３ コントローラ（部）
１３ａ ＲＯＭ
１３ｂ ＲＡＭ
１３ｃ ＣＰＵ
１４ データ通信Ｉ／Ｆ
１４ａ インターフェース装置
１５ スキャナ
１５ａ 画像読取装置
１６ プロッタ
１６ａ 印刷装置
１７ ＨＤＤ
１００ プラットフォーム
１０１ 標準アプリ管理モジュール
１０２ 利用可能者判断ＤＢ
１２０ ＳＤＫプラットフォーム
１２１ ＳＤＫアプリ管理モジュール
１３０ 標準アプリＡ
１３１ ＵＩ
１３２ 標準アプリＡロジック
１３３ アプリ管理ＩＦ
１４０ 標準アプリＢ
１４１ ＵＩ
１４２ 標準アプリＢロジック
１４３ アプリ管理ＩＦ
１５０ ＳＤＫアプリＡ
１５１ ＵＩ
１５２ ＳＤＫアプリＡロジック
１５３ アプリ管理ＩＦ
１６０ ＳＤＫアプリＢ
１６１ ＵＩ
１６２ ＳＤＫアプリＢロジック
１６３ アプリ管理ＩＦ
２００ プラットフォーム
２０１ 標準アプリ管理モジュール
２０２ 利用可能者判断ＤＢ
２２０ ＳＤＫプラットフォーム
２２１ ＳＤＫアプリ管理ＩＦ生成部
２２２ ＳＤＫアプリ管理中継モジュール
２３０ 標準アプリＡ
２３１ ＵＩ
２３２ 標準アプリＡロジック
２３３ アプリ管理ＩＦ
２４０ 標準アプリＢ
２４１ ＵＩ
２４２ 標準アプリＢロジック
２４３ アプリ管理ＩＦ
２５０ ＳＤＫアプリＡ
２５１ ＵＩ
２５２ ＳＤＫアプリＡロジック
２５３ アプリ管理ＩＦ
２６０ ＳＤＫアプリＢ
２６１ ＵＩ
２６２ ＳＤＫアプリＢロジック
２６３ アプリ管理ＩＦ

特開２００３−２２９９８６号公報

Claims (6)

1. アプリケーションを追加可能な画像形成装置であって、
   アプリケーションの管理を行う管理手段と、
   前記管理手段とのＩＦを有する第１のアプリケーションと、前記管理手段とのＩＦを有しない第２のアプリケーションとのインストールを行うインストール手段と、
   前記管理手段とのＩＦを有し、前記第２のアプリケーションの情報を中継して前記管理手段に通知する管理中継手段と、
   を有し、
   前記インストール手段が、前記第１のアプリケーション又は前記第２のアプリケーションのインストールを行うとき、前記管理手段は、前記第１のアプリケーションのＩＦを介して前記第１のアプリケーションを管理し、前記管理中継手段のＩＦを介して前記第２のアプリケーションを管理すること、
   を特徴とする画像形成装置。
2. 前記インストール手段により、前記第２のアプリケーションがインストールされたとき、前記第２のアプリケーションに対し、前記管理手段とのＩＦを生成するＩＦ生成手段を有し、
   前記管理手段は、前記第１のアプリケーションのＩＦを介して前記第１のアプリケーションを管理し、前記ＩＦ生成手段により生成されたＩＦを介して前記第２のアプリケーションを管理すること、
   を特徴とする請求項１記載の画像形成装置。
3. 前記管理手段は、アプリケーションの利用可能者判断を行なう利用可能者判断手段を含み、
   前記管理手段は、前記第１のアプリケーションのＩＦを介して前記第１のアプリケーションの利用可能者判断を行い、前記ＩＦ生成手段により生成されたＩＦを介して前記第２のアプリケーションの利用可能者判断を行なうこと、
   を特徴とする請求項２記載の画像形成装置。
4. アプリケーションを追加可能な画像形成装置であるコンピュータを、
   アプリケーションの管理を行う管理手段と、
   前記管理手段とのＩＦを有する第１のアプリケーションと、前記管理手段とのＩＦを有しない第２のアプリケーションとのインストールを行うインストール手段と、
   前記管理手段とのＩＦを有し、前記第２のアプリケーションの情報を中継して前記管理手段に通知する管理中継手段
   として機能させるためのプログラムであって、
   前記インストール手段が、前記第１のアプリケーション又は前記第２のアプリケーションのインストールを行うとき、前記管理手段は、前記第１のアプリケーションのＩＦを介して前記第１のアプリケーションを管理し、前記管理中継手段のＩＦを介して前記第２のアプリケーションを管理すること、
   を特徴とするアプリケーション管理プログラム。
5. 前記インストール手段により、前記第２のアプリケーションがインストールされたとき、前記第２のアプリケーションに対し、前記管理手段とのＩＦを生成するＩＦ生成手段として機能させるためのプログラムであって、
   前記管理手段は、前記第１のアプリケーションのＩＦを介して前記第１のアプリケーションを管理し、前記ＩＦ生成手段により生成されたＩＦを介して前記第２のアプリケーションを管理すること、
   を特徴とする請求項４記載のアプリケーション管理プログラム。
6. 前記管理手段は、アプリケーションの利用可能者判断を行なう利用可能者判断手段を含み、
   前記管理手段は、前記第１のアプリケーションのＩＦを介して前記第１のアプリケーションの利用可能者判断を行い、前記ＩＦ生成手段により生成されたＩＦを介して前記第２のアプリケーションの利用可能者判断を行なうこと、
   を特徴とする請求項５記載のアプリケーション管理プログラム。

Images