JP2014179034A - 情報処理システム、情報処理装置及びプログラム - Google Patents

Abstract

【課題】 アプリケーション自身の機能によらず、アプリケーションの利用制限を容易に行えるようにする。
【解決手段】 画像処理システムにおいて、操作部が、選択されたアプリをダウンロードしてインストールした場合（Ｓ１〜Ｓ７）、そのアプリに付されていた署名に応じて、本体が備える機能のうち、インストールしたアプリが利用する機能の種類を登録する（Ｓ８，Ｓ９）ようにした。また、ユーザ毎に該ユーザに利用を許可する機能の種類を登録した権限情報及び、上記アプリが利用する機能の種類の情報に基づき、上記操作部を操作するユーザに、そのユーザが利用を許可されていない種類の機能を利用するアプリケーションを利用させないようにした。
【選択図】 図５

Description

この発明は、操作部と動作部とを備えた情報処理システム、このような情報処理システムにおける上記操作部として機能する情報処理装置、及びコンピュータに情報処理システムを制御させるためのプログラムに関する。

従来から、複合機（ＭＦＰ）等の情報処理システムでは、操作部と動作部（本体）とを設け、操作部で受け付けたユーザの操作に応じて動作部が各種処理を行ったり、動作部の状態を操作部上に表示させたりすることが行われている。

また、このような情報処理システムでは、認証サーバと通信可能に接続し、アプリケーションをインストールして機能を追加する際に、アプリケーションのインストール許可を、認証サーバを用いてアクティベーションする（有効にする）ことが知られている。
このようなアプリケーション等のプログラムのインストールに関連する技術としては、例えば特許文献１，２に記載のものが知られている。

特許文献１に記載のライセンス管理システムでは、通信可能な複合機にインストールすべきアプリケーションあるいは既にインストールされているアプリケーションに対し、その有効期限や利用回数（カウンタ値）を設定して制限可能にしている。
特許文献２に記載の情報処理装置では、選択された機能を特定するための情報がアプリケーションの起動条件として記録された設定ファイルを所定の記録媒体から取得する。そして、その起動条件に従い、上記選択された機能のみを利用可能（アプリケーションの機能を制限可能）にしている。

しかしながら、上述したような特許文献１及び２に記載の情報処理システムでは、次のような問題があった。
すなわち、アプリケーション自身に、そのアプリケーションの機能の利用を制限する機能を設けているため、アプリケーションがその利用を制限する機能を持っていない場合には、利用の制限ができなかった。また、他社製のアプリケーションなど、利用の制限に係る機能に自由にアクセスできない場合には、利用の制限について望み通りの制御ができないという問題があった。

この発明は、上記の点に鑑みてなされたものであり、アプリケーション自身の機能によらず、アプリケーションの利用制限を容易に行えるようにすることを目的とする。

この発明は、指示の入力を受け付ける操作部と、該操作部が受け付けた指示に基づき情報処理動作する動作部とを備える情報処理システムであって、上記の目的を達成するため、上記操作部が備えるアプリケーションと対応する電子署名に応じて、上記動作部が備える機能のうち上記アプリケーションが利用する機能の種類を示す機能情報を登録する登録手段を備えるものである。

上記構成によれば、上記の点に鑑みてなされたものであり、アプリケーション自身の機能によらず、アプリケーションの利用制限を容易に行えるようにすることができる。

この発明の情報処理システムの第１実施形態である画像処理システムの利用環境を示す図である。 図１の画像処理システムのハードウェア構成を示すブロック図である。 図２に示した本体及び操作部のソフトウェア構成を操作部とネットワークの通信に関する機能と共に示す図である。 図１に示した操作部がサーバ装置からアプリをダウンロードしてインストールする際の基本的な動作を説明するための図である。 図２に示した操作部によるアプリインストール時の処理を示すフローチャートである。 図２に示した操作部によるログイン要求時の処理を示すフローチャートである。 図６の処理により表示されるホーム画面の一例を示す図である。 図１に示した操作部によるアプリ更新時の処理を示すフローチャートである。 第２実施形態における操作部がダウンロードサーバからアプリケーションをダウンロードしてインストールする際の動作を説明するための図である。 同じく操作部によるアプリインストール時の処理を示すフローチャートである。 同じく操作部がサーバ装置へアプリの利用承認を求め、その結果を受信してアプリをインストールする際の動作シーケンスを示す図である。 第３実施形態における操作部がサーバ装置へアプリの署名を依頼し、その結果を受信してアプリをインストールする際の動作シーケンスを示す図である。 第４実施形態における操作部がサーバ装置へアプリの署名を依頼し、その結果を受信してアプリをインストールする際の動作シーケンスを示す図である。

以下、この発明を実施するための形態について、図１〜図１３を参照して具体的に説明する。
〔第１実施形態〕
図１は、この発明の情報処理システムの第１実施形態である画像処理システムの利用環境を示す図である。

画像処理システム１は、通信機能を有するＭＦＰ（複合機：Multifunction
Peripheral）であり、例えばコピー機能，スキャナ機能，プリンタ機能，ファクス（ＦＡＸ）通信機能を備えている。これらの機能に関わる処理は、ユーザが画像形成装置１を直接操作することによって実行することができる。また、図示しないクライアントＰＣ（パーソナルコンピュータ）等の外部装置から受信した指示に従って実行することもできる。
また、画像処理システム１は、機能を追加するためのアプリケーションプログラム等のデータを送信する所定のサーバ装置２と、ネットワーク３を介して通信可能である。

図２は、図１の画像処理システム１のハードウェア構成を示すブロック図である。
この画像処理システム１は、図２に示すように、ユーザから指示の入力を受け付ける操作部２０と、操作部２０が受け付けた指示に基づき情報処理動作を実行する動作部である本体１０とを備え、それらを例えば専用の通信路３０により相互に通信可能に接続した構成である。この実施形態では、操作部２０として、Ａｎｄｒｏｉｄ（登録商標）ＯＳを用いて動作する携帯情報端末装置を使用している。また、操作部２０の電源は、本体１０から供給することができるが、操作部２０は不図示の内部バッテリを備え、単独で動作させることもできる。また、本体１０から操作部２０へ電源を供給するための電源線は、この実施形態では通信路３０と共通のものである。

また、本体１０は、操作部２０が受け付けた指示に応じた動作だけでなく、上述のように外部装置から受信した指示に応じた動作も行うことができる。また、通信路３０は、例えばＵＳＢ（Universal Serial Bus）規格のものを用いることができる。しかし、有線、無線を問わず任意の規格のものでよい。１対１通信であっても、ネットワーク通信であってもよい。例えば、ＵＳＢの他、シリアル、有線または無線ＬＡＮ（ローカルエリアネットワーク）、ブルートゥース（Bluetooth：登録商標）、ＩｒＤＡ（Infrared Data Association）等を用いることが考えられる。

本体１０は、ＣＰＵ１１、ＲＯＭ１２、ＲＡＭ１３、ＨＤＤ１４（ハードディスクドライブ）、通信Ｉ／Ｆ（インタフェース）１５、接続Ｉ／Ｆ１６、及びエンジン部１７を備え、それらをシステムバス１８により接続した構成としている。
そして、ＣＰＵ１１が、ＲＡＭ１３をワークメモリとしてＲＯＭ１２又はＨＤＤ１４に記憶されたプログラムを実行することにより、本体１０全体を制御し、後述する各種機能を実現する。

ＨＤＤ１４は、不揮発性記憶媒体（記憶手段）であり、ＣＰＵ１１が実行する各種プログラムを含む各種データを格納（記憶）している。
通信Ｉ／Ｆ１５は、ネットワーク３を介して外部装置と通信するためのインタフェースである。
接続Ｉ／Ｆ１６は、通信路３０を介して操作部２０と通信するためのインタフェースである。ここではＵＳＢ規格のインタフェースとしている。

なお、通信Ｉ／Ｆ１５は、有線、無線を問わず任意の規格のものを採用可能である。接続Ｉ／Ｆ１６と共通化してもよい。通信Ｉ／Ｆ１５及び接続Ｉ／Ｆ１６としてそれぞれ複数のＩ／Ｆを設けてもよい。

エンジン部１７は、コピー機能，スキャナ機能，プリンタ機能，ファクス機能を実現させるための、汎用的な情報処理及び通信以外の処理を行うハードウェアである。例えば、原稿の画像をスキャンして読み取るスキャナ（画像読取部）、用紙等のシート材への印刷を行うプロッタ（画像形成部）、ファクス通信を行う通信部などを備えている。更に、印刷済みシート材を仕分けるフィニッシャや、原稿を自動給送するＡＤＦ（自動原稿給送装置）のような特定のオプションを備えることもできる。

一方、操作部２０は、ＣＰＵ２１、ＲＯＭ２２、ＲＡＭ２３、フラッシュメモリ２４、通信Ｉ／Ｆ２５、接続Ｉ／Ｆ２６、及び操作パネル２７を備え、それらをシステムバス２８により接続した構成としている。そして、ＣＰＵ２１が、ＲＡＭ２３をワークメモリとしてＲＯＭ２２又はフラッシュメモリ２４に記憶されたプログラムを実行することにより、操作部２０全体を制御し、後述するアプリケーションのインストールに関する制御をはじめとする各種機能を実現する。

フラッシュメモリ２４は、不揮発性記憶媒体（記憶手段）であり、ＣＰＵ２１が実行する各種プログラムや後述する各種データを格納（記憶）している。
通信Ｉ／Ｆ２５は、ネットワーク３を介してサーバ装置２等の外部装置と通信するためのインタフェースである。

接続Ｉ／Ｆ２６は、通信路３０を介して本体１０と通信するためのインタフェースである。ここではＵＳＢ規格のインタフェースとしている。
なお、通信Ｉ／Ｆ２５は、有線、無線を問わず任意の規格のものを採用可能である。接続Ｉ／Ｆ２６と共通化してもよい。通信Ｉ／Ｆ２５及び接続Ｉ／Ｆ２６としてそれぞれ複数のＩ／Ｆを設けてもよい。

操作パネル２７は、ユーザからの各種動作の実行や設定等の指示操作を受け付ける操作部と、画像処理システム１の動作状況や設定状態を表示する表示部とを備える操作表示手段である。この操作パネルは、例えばタッチパネルを積層した液晶表示装置（ＬＣＤ）により構成することができる。さらに、これに加えて又はこれに代えて、ハードウェアキー等の操作部やランプ等の表示部を設けることもできる。
なお、図１のサーバ装置２は、ハードウェアとしては、ＣＰＵ、ＲＯＭ、ＲＡＭ、通信Ｉ／Ｆ等を備えた公知のコンピュータでよい。

図３は、図２に示した本体１０及び操作部２０のソフトウェア構成を操作部２０とネットワーク３の通信に関する機能と共に示す図である。
図３に示すように、本体１０は、アプリケーション（以下「アプリ」ともいう）層１０１と、サービス層１０２と、オペレーティングシステム（以下「ＯＳ」という）層１０３とを含むソフトウェア群を備える。

アプリ層１０１のソフトウェアは、ハードウェア資源を動作させて所定の機能を提供するためのソフトウェアである。例えば、コピーアプリ，スキャナアプリ，プリンタアプリ，ファクスアプリ等を備え、それらによってコピー機能，スキャナ機能，プリンタ機能，ファクス機能等の各種機能を提供することができる。

サービス層１０２のソフトウェアは、アプリ層１０１とＯＳ層１０３との間に介在し、アプリ層１０１のソフトウェアに対し、本体１０が備えるハードウェア資源を利用するためのインタフェースを提供する。より具体的には、ハードウェア資源に対する動作要求の受付及びその動作要求の調停を行う機能を備える。サービス層１０２が受け付ける動作要求には、スキャナによる読み取りやプロッタによる印刷等の要求が考えられる。

なお、このインタフェースの機能は、本体１０のアプリ層１０１だけではなく、操作部２０のアプリ層２０１に対しても提供する。すなわち、操作部２０のアプリ層２０１にあるアプリも、サービス層１０２にアクセスすることにより、本体１０のハードウェア資源（例えばエンジン部１７）を利用して各種機能を実現することができる。

ＯＳ層１０３は、基本ソフトウェアであり、本体１０が備えるハードウェアを制御する基本機能を提供する。サービス層１０２のソフトウェアは、各種アプリからのハードウェア資源の利用要求を、ＯＳ層１０３が解釈可能なコマンドに変換してＯＳ層１０３に渡す。そして、ＯＳ層１０３のソフトウェアがそのコマンドを実行することにより、ハードウェア資源にアプリの要求に従った動作を行わせる。

操作部２０が備えるアプリ層２０１、サービス層２０２及びＯＳ層２０３も、階層構造については本体１０側と同様である。アプリ層２０１のアプリが提供する具体的な機能や、サービス層２０２が受け付け可能な動作要求の種類は、本体１０側とは異なる。操作部２０が備えるアプリは、操作部２０が備えるハードウェア資源を動作させて所定の機能を提供することもできるが、主として本体１０が備える機能に関する操作や表示を行うためのＵＩ（ユーザインタフェース）の機能を提供する。

なお、本体１０側と操作部２０側とで、ＯＳは独立して動作するものとする。また、本体１０と操作部２０とが相互に通信可能であれば、ＯＳが同じ種類である必要はない。例えば、本体ではＬｉｎｕｘ（登録商標）を用い、操作部２０ではＡｎｄｒｏｉｄ（登録商標）を用いることも可能である。

この画像処理システム１において、本体１０と操作部２０とは異なるＯＳにより制御されるため、本体１０と操作部２０との間の通信は、１装置内のプロセス間通信ではなく、異なる装置間の通信として行う。
操作部２０が受け付けたユーザからの指示内容を本体１０へ伝達する動作（コマンド通信）や、操作部２０に表示させる情報を本体１０から操作部２０へ伝達する動作がこれに該当する。

この実施形態の一つの特徴は、画像処理システム１が行う以下の動作である。つまり、操作部２０が備えるアプリケーションと対応する電子署名に応じて、本体（動作部）１０が備える機能のうち、そのアプリケーションによる利用を許可する機能の種類を設定する。以下、この動作を含む各動作について説明する。

まず、操作部２０がサーバ装置２からアプリをダウンロードしてインストールする際の基本的な動作について説明する。
図４は、その動作に供する説明図である。

操作部２０は、図４に示すように、図１のサーバ装置２とネットワーク３を介して通信可能である。
この操作部２０は、ブラウザあるいは適当なクライアントアプリケーション等により、ユーザからダウンロードしたいアプリの選択及びそのアプリのダウンロード指示を受け付けた場合に、そのアプリのダウンロードをサーバ装置２に要求する。

サーバ装置２は、各種アプリのインストール用ファイル２１０を管理するものであり、その各ファイルを記憶保持している。図ではインストール用ファイル２１０を１つしか示していないが、サーバ装置２は、複数のアプリについてそれぞれインストール用ファイル２１０を保持していてよい。
各アプリのインストール用ファイル２１０はそれぞれ、アプリのプログラムを含む本体ファイルであるａｐｋファイル（android application package file）２１１と、ａｐｋファイル２１１に付した電子署名（以下単に「署名」といった場合には電子署名を指す）である署名データ２１２とを含む。なお、アプリのインストール用ファイル２１０に署名データ２１２が含まれている場合、そのアプリは「署名の付されたアプリ」であるという。

サーバ装置２は、操作部２０からダウンロード要求（依頼）を受けると、要求されたアプリのインストール用ファイル２１０を読み出して操作部２０へ返信する。
操作部２０は、ダウンロード要求に応じて送信されてくるインストール用ファイル２１０をダウンロード（受信）した後、それに署名データ２１２が含まれていれば、その署名データ２１２をチェック（照合）して、ダウンロードしたインストール用ファイル２１０に係るアプリをインストールしてよいか否か等の判断を行う。

ここで、その判断を判り易くするため、まず、操作部２０が一般的な署名の照合を行うものとして、その照合に関する操作部２０及びサーバ装置２の構成及び動作について、もう少し詳しく説明する。
（ａ）サーバ装置２は、秘密鍵を予め記憶保持している。署名を検証する端末に相当する操作部２０には、その秘密鍵と対になる公開鍵を予め記憶保持させておく。

（ｂ）サーバ装置２は、操作部２０からダウンロード要求を受けると、要求されたアプリに係るａｐｋファイル２１１を読み出す。そして、ａｐｋファイル２１１にハッシュ関数をかけてハッシュ値を計算し、取得する。この取得したハッシュ値を秘密鍵で暗号化したものが署名となる。この署名を、ａｐｋファイル２１１に署名データ２１２として付し、これらをインストール用ファイル２１０として操作部２０へ返信する。なお、署名データ２１２を含むインストール用ファイル２１０を予め用意しておいてもよい。

（ｃ）操作部２０は、ダウンロード要求に応じて送信されてくるインストール用ファイル２１０をダウンロードした後、それに含まれている署名データ２１２を用いて署名の照合を行う。つまり、インストール用ファイル２１０に含まれているａｐｋファイル２１１及び署名データ２１２のうち、ａｐｋファイル２１１にハッシュ関数をかけてハッシュ値を取得し、署名データ２１２を公開鍵で復号してハッシュ値（サーバ装置２側で計算したもの）を取得する。
（ｄ）操作部２０は、取得した２つのハッシュ値を比較し、一致していればａｐｋファイル２１１の改竄なし（正しい署名である）、一致していなければａｐｋ２１１ファイルの改竄あり（正しい署名ではない）と判断する。

また、この実施形態では、操作部２０がダウンロードしたアプリをインストールしてよいか否か、および、そのアプリが本体１０のどの機能を利用するものであるか等の判断を行うため、ダウンロードしたアプリに付された署名の種類の判別も行う。その判別は、上述した署名の照合方法に従い、どの公開鍵を用いて署名の正当性を確認できたかにより行うことができる。
そのため、実際には、サーバ装置２側が複数の秘密鍵を保持し、操作部２０には、その複数の秘密鍵にそれぞれと対になる複数の公開鍵を保持させておく。

操作部２０は、上記（ｄ）の判断を行う場合、ダウンロード要求に応じて送信されてくるインストール用ファイル２１０に含まれている署名データ２１２を、自己が保持している複数の公開鍵を使って順次復号してハッシュ値を得る。このとき、インストール用ファイル２１０に含まれているａｐｋファイル２１１から計算したハッシュ値と一致するハッシュ値が得られた公開鍵の種類により、署名の種類を判別する。よって、署名の種類は、この署名を作成するときに用いた秘密鍵の種類（＝対になる公開鍵の種類）で決まることになる。

操作部２０は、ダウンロード要求に応じて送信されてくるインストール用ファイル２１０に含まれている署名の種類を判別した後、予め記憶保持されている情報を参照する。この情報は、署名情報テーブルに登録するものとし、例えば表１に示すように、署名の種類（各パターン）と、その各署名が付されているアプリのインストール可否と、そのアプリが利用する本体１０の機能との対応関係の設定内容を示している。

操作部２０は、参照した情報に基づき、ダウンロードしたインストール用ファイル２１０に含まれている署名データ２１２（アプリに付された署名）が適正と判断した場合に、その署名の種類に応じてインストール可否を判断する。
表１の例では、操作部２０は、アプリに付されている署名がパターンＢ〜Ｈのいずれかであれば、インストール可と決定（判断）する。ダウンロードしたアプリに付されている署名がパターンＡであれば、そのアプリに含まれている署名が適正であっても、インストール否と決定する。
なお、アプリに付す署名の種類は、サーバ装置２においてアプリをダウンロード可能とする際に、アプリの登録者あるいはサーバ装置２の管理者が選択してサーバ装置２に対して設定しておく。

操作部２０はまた、ダウンロードしたアプリのインストール可と決定した場合、そのアプリに付されている署名の種類に応じて、そのアプリが利用する本体１０の機能を登録する。この登録内容として、アプリをインストールしても本体１０の機能を全く利用しない（表１のパターンＨに対応）、一部の機能のみを利用する（表１のパターンＣ〜Ｇに対応）などがあり得る。また、ユーザの権限によらず該当アプリの起動を許可しない（表１のパターンＡ，Ｂ及び署名なしに対応）という内容もあり得る。

すなわち、操作部２０は、ダウンロードしたアプリに付されている署名の種類に応じて、本体１０が備える機能のうち、そのアプリが利用する機能の種類（機能範囲）を、機能情報として登録する。この機能情報は、アプリ情報テーブルに登録し、例えば表２に示すように、ダウンロードしたアプリの名称（他の識別情報でもよい）毎に、本体１０が備える機能のうち、そのアプリが利用する機能を登録する。

次に、図２に示した操作部２０のＣＰＵ２１によるアプリインストール時の処理について説明する。
図５は、その処理を示すフローチャートである。
操作部２０のＣＰＵ２１は、ダウンロードしたいアプリの選択及びそのアプリのダウンロード要求を受け付けた場合に、図５に示す処理を開始する。アプリの選択及びダウンロード要求は、ユーザが操作パネル２７を操作して行ってもよいし、予め設定された所定条件を満たした場合（設定時刻に達した場合など）に自動的に行われるようにしてもよい。

この処理において、ＣＰＵ２１はまずステップＳ１で、選択されたアプリのインストール用ファイル２１０をサーバ装置２からダウンロードする。
そして、ステップＳ２でそのインストール用ファイル２１０に署名データ２１２が含まれているか否かを判断し、含まれていればステップＳ３で上述したようにその署名データ２１２について署名の検証（種類の判別を含む）を行う。

ＣＰＵ２１は、次にステップＳ４へ進み、その検証結果からダウンロードしたインストール用ファイル２１０に含まれている署名が正しい署名（問題なし）と判断すればステップＳ５へ進む。
ステップＳ５では、ＣＰＵ２１が、表１に示した情報を参照して、ダウンロードしたインストール用ファイル２１０に含まれている署名の種類がインストール可であるか否かを判断する。
そして、インストール可であれば、ステップＳ６において、ダウンロードしたインストール用ファイル２１０に係るアプリはインストール可と決定してステップＳ７へ進む。

ステップＳ２，Ｓ４，又はＳ５の判断がＮＯの場合、ＣＰＵ２１は、ステップＳ１０において、ダウンロードしたインストール用ファイル２１０に係るアプリはインストール否と決定してステップＳ１１へ進み、インストール処理を中止する。
ＣＰＵ２１は、次にステップＳ１２へ進み、ダウンロードしたインストール用ファイル２１０を破棄し、図５の処理を終了する。このとき、インストールが許可できない旨をユーザに通知するとよい。

一方、ＣＰＵ２１は、ステップＳ７へ進むと、ダウンロードしたインストール用ファイル２１０に係るアプリのインストールを実行する。そして、ステップＳ８で、署名情報テーブル（表１）を参照し、インストール用ファイル２１０に含まれている署名の種類に応じて、本体１０が備える機能のうち、インストールしたアプリが利用する機能を特定する。
そして、ステップＳ９で、その特定した機能の種類（機能範囲）を、アプリの識別情報と対応付けてアプリ情報テーブル（表２）に追加登録し、図５の処理を終了する。

以上のステップＳ３、Ｓ８、Ｓ９が登録手順の処理であり、これらのステップにおいて、ＣＰＵ２１は登録手段として機能する。
以後、ＣＰＵ２１は、アプリ情報テーブルを参照することにより、インストールしたアプリが利用する本体１０の機能を把握することができる。また、ステップＳ９での登録及びその登録に必要な情報を得る過程において、登録に係るアプリ自体の機能は利用しないため、正しい署名が付されたアプリでれば、どのようなアプリについても、アプリが利用する本体１０の機能を把握することができる。

なお、操作部２０は、ユーザ毎にそのユーザに利用を許可する本体１０の機能の種類を登録した権限情報を記憶している。そして、操作部２０を利用しようとするユーザをパスワード等により認証し、各ユーザに、権限情報に登録されている機能のみ利用を許可するようにしている。なお、この権限情報は、本体１０が記憶しているものであってもよい。
この権限情報は、例えば表３に示す権限情報テーブルに、ユーザ名と、利用を許可する機能を示す利用権限とを対応付けて登録することができる。

また、権限情報テーブルにおいては、各ユーザに利用を許可するアプリを示す情報も登録する。アプリ情報テーブル（表２）を参照し、各ユーザが利用可能な機能のみを利用するアプリのアプリ名を、利用可能アプリとして登録すればよい。
表３において、例えば、ユーザSuzukiは、コピー、スキャナ、プリンタ、ファクスの機能が利用できるため、表２に登録されている全てのアプリが利用できる。また、ユーザTanakaは、スキャナ機能のみが利用できるので、スキャナ機能のみ利用し、他の機能を利用しないScanToクラウド及びScanToMeアプリのみを利用できる。ユーザSatohは、コピーとプリンタの機能が利用できるので、この範囲の機能のみを利用する、エコ・コピー及び機密印刷アプリのみを利用できる。

ユーザSaitoのように本体１０の機能の利用権限がないユーザもあり得る。この場合でも本体１０の機能を利用しないアプリがあれば、そのアプリについては利用可能である。そのようなアプリとして、操作マニュアル、サイネージ、カレンダーアプリ、ニュース表示アプリ、天気予報表示アプリ、ＴｏＤｏタスク管理ソフト、画像ビューワなどが考えられる。

この利用可能アプリの登録は、アプリを新たにインストールした時や、ユーザの利用権限を変更した時に更新するとよい。また、ユーザがログインする度に、その時点の利用権限及びアプリ情報テーブルを参照して、ログインしたユーザに係る情報を生成するようにしてもよい。

なお、アプリのインストールの際には、表３の利用権限に関係なくインストールを行うことができる（ただし、インストールの可否を規定する権限情報を設けてもよい）。従って、ユーザにとって、アプリのインストールは可能であるが利用はできない、ということも発生し得る。

いずれにせよ、操作部２０においては、各ユーザに対し、利用を許可するアプリのみ利用できるようにし、利用を許可しないアプリについては、利用させないようにする。具体的には、操作画面に、利用を許可するアプリの起動用アイコンを表示する一方、利用を許可しないアプリの起動用アイコンを表示しないようにすることが考えられる。

次に、この点に関連して、図２に示した操作部２０のＣＰＵ２１によるログイン要求時の処理について説明する。
図６は、その処理を示すフローチャートである。
操作部２０のＣＰＵ２１は、ユーザの操作によるログイン要求，ユーザＩＤ，及びパスワードの入力を受け付けた場合に、図６に示す処理を開始し、まずステップＳ２１において、そのユーザＩＤ及びパスワードに基づいてユーザ認証を実行する。

すなわち、ＣＰＵ２１は、入力されたユーザＩＤ及びパスワードの組み合わせがいずれかの登録ユーザのものと一致するか否かを判断し、一致した場合にはユーザ認証が成功、一致しなかった場合にはユーザ認証が失敗とする。もちろん、他にログイン名等を用いた認証処理を行ってもよい。
ＣＰＵ２１は、次にステップＳ２２へ進み、ユーザ認証の結果が成功か失敗かを判断し、失敗した場合には、直ちに図６の処理を終了する。また、ユーザ認証が成功した場合には、ステップＳ２３へ進み、ユーザを本体１０にログインさせる。

その後、ステップＳ２４へ進み、ＣＰＵ２１は、権限情報テーブル（表３）を参照し、操作パネル２７の表示部上に、本体１０の機能のうちログインしたユーザが利用権限を有する機能に係る操作画面を起動するためのアイコンを表示する。
その後、ＣＰＵ２１はステップＳ２５で、アプリ情報テーブル（表２）と権限情報テーブル（表３）とを参照し、上述のように、操作部２０にインストールされているアプリのうちログインしたユーザに利用を許可するアプリを特定する。

そして、ＣＰＵ２１は、ステップＳ２６で利用を許可するアプリがあったか否か判断する。ここでなければそのまま処理を終了するが、あればステップＳ２７に進む。そして、操作部２の表示部上のホーム画面に、操作部２０が備えるアプリのうち、ログインしたユーザに利用を許可するアプリを起動するためのアイコンを表示して、処理を終了する。利用を許可しないアプリについては、アイコンは表示しないようにする。このことにより、ユーザに当該アプリを利用させないようにすることができる。

図７に、表３に示したユーザSatohがログインした場合に図６の処理により表示されるホーム画面の例を示す。
図７に示すホーム画面５００には、アイコン５０１〜５０４が表示される。このうちアイコン５０１は、本体１０が備えるコピー機能に係る操作画面を起動するためのアイコンである。アイコン５０２は、同じくプリンタ機能係る操作画面を起動するためのアイコンである。アイコン５０３は、操作部２０にインストールされているエコ・コピーアプリを起動するためのアイコンである。アイコン５０４は、同じく機密印刷アプリを起動するためのアイコンである。ホーム画面５００には、ユーザSatohが利用権限を有する機能及びその範囲の機能のみを利用するアプリを起動するためのアイコンのみ表示されている。

従って、図６の処理によれば、ユーザに利用権限のない機能に関するアイコンや、ユーザに利用権限のない機能を利用するアプリ（利用を許可できないアプリ）を起動するためのアイコンを表示しないようにして、これらの機能及びアプリの利用を禁止することができる。
図６のステップＳ２５乃至Ｓ２７の処理において、ＣＰＵ２１は禁止手段として機能する。

なお、利用を許可できないアプリを起動するためのアイコンをホーム画面に表示しつつ、そのアプリ実行時にエラーとし、その旨を示す情報をホーム画面に表示することによっても、同様なアプリの利用禁止自体は可能である。

また、アプリが利用する本体１０の機能は、１つとは限らない。表４に示すように、複数の機能を利用するアプリがあってもよい。この場合も、アプリが使用する機能の種類は、アプリに付された署名の種類と対応付けて署名情報テーブル（表１）に登録しておく。
例えば、ScanToクラウド＆印刷アプリは、スキャナとプリンタの両方の機能を利用するため、これら両方の機能について利用権限を持つユーザのみに利用を許可できることになる。
表５に、表３と同じ利用権限を持つユーザにこれらのアプリの利用を許可できるか否かを示した。

ところで、操作部２０においては、一旦インストールしたアプリについて、バージョンアップ等により更新することも可能である。次に、操作部２０のＣＰＵ２１によるこのアプリ更新時の処理について説明する。
図８は、その処理を示すフローチャートである。
操作部２０のＣＰＵ２１は、更新したいアプリの選択及びそのアプリの更新の指示を受け付けた場合に、図８に示す処理を開始する。アプリの選択及び更新指示は、ユーザが操作パネル２７を操作して行ってもよいし、予め設定された所定条件を満たした場合（設定時刻に達した場合など）に自動的に行われるようにしてもよい。

この処理において、ＣＰＵ２１はまずステップＳ３１で、選択されたアプリのインストール用ファイル２１０をサーバ装置２からダウンロードする。
ＣＰＵ２１は次に、ステップＳ３２において、ダウンロードしたインストール用ファイル２１０の属性からプログラムバージョンを取得して、それとインストール済みアプリのバージョンと比較し、両バージョンが同一か否かを判断する。

そして、その判断がＹＥＳの場合、ＣＰＵ２１は、ステップＳ３４へ進み、ダウンロードしたインストール用ファイル２１０に署名データ２１２が含まれているか否かを判断する。そして、含まれている場合にはステップＳ３５でその署名を検証すると共に、ステップＳ３６で、その署名がインストール済みのアプリに付されていた署名と同一種類の署名か否かを判断する。

ステップＳ３６でＮＯの場合、アプリのバージョンは更新されていないが署名が更新されたことがわかる。そこで、ステップＳ３８〜Ｓ４５において、図５のステップＳ５〜Ｓ１２と同様に、今回アプリに付されている署名の種類に応じて、アプリのインストール（又はインストール中止）及び、そのアプリが利用する機能の登録を行う。
また、ステップＳ３４で署名データ２１２がない場合は、アプリのインストールを許可できないため、インストール中止に係る処理を行う（Ｓ４３〜Ｓ４５）。ステップＳ３６で署名が同一である場合は、新たにインストールを行う必要がないため、やはりインストール中止に係る処理を行う（Ｓ４３〜Ｓ４５）。

また、ステップＳ３３でバージョンが異なる場合、ＣＰＵ２１はステップＳ３７で署名データ２１２に係る検証を行い、アプリに付されている署名の種類に応じて、アプリのインストール（又はインストール中止）及び、そのアプリが利用する機能の登録を行う（Ｓ３８〜Ｓ４５）。この場合、アプリがバージョンアップされていると考えられるため、現在インストールされているアプリと署名の種類が同じであっても、インストールを行うものである。しかし、今回アプリに正当な署名が付されていなかったり、インストールを許可できない種類の署名が付されていたりした場合には、インストールは行わない。

なお、ステップＳ３３でバージョンが異なっても、ダウンロードしたインストール用ファイル２１０が現在インストールされているアプリより古いバージョンのものであった場合、インストールを中止するか、又は中止するか否かをユーザに問い合わせるとよい。
以上の処理により、アプリのバージョンアップを行うと共に、バージョンアップ後のアプリに付された署名の種類に応じて、アプリ情報テーブルの内容を更新することができる。なお、アプリのバージョンが変わらない場合でも、アプリに付された署名の種類が変わっていれば、アプリ情報テーブルの内容を更新することができる。
以上の図８の処理において、ＣＰＵ２１は更新手段として機能する。

以上の第１実施形態では、操作部２０が、アプリのインストール時に、そのアプリに付されていた署名（自己が備えるアプリと対応する署名）に応じて、本体１０が備える機能のうちそのアプリが利用する機能の種類を登録する。従って、アプリが備える機能に依存せずに、アプリが利用する機能を特定可能である。
このことにより、ユーザの利用権限と照らし合わせ、ユーザ毎に、そのユーザに利用権限のない機能を利用するアプリの利用を制限するといった対応を、アプリが備える機能に依存せずに行うことができる。

上述の実施形態では、この利用制限を、操作部２０が、ユーザ毎にそのユーザに利用を許可する本体１０の機能の種類を登録した権限情報を参照し、操作部２０を操作するユーザに、そのユーザが利用を許可されていない種類の機能を利用するアプリを利用させないようにすることにより行っている。

それによって、操作部２０を操作するユーザが、自身が利用を許可されていない種類の機能を、アプリの利用を通じて利用してしまうことを防止できる。そして、この利用制限は、制限対象のアプリ自体の機能には依存せずに行うことができる。
従って、画像形成システム１のメーカーと、アプリのメーカーとが異なり、画像形成システム１のメーカーにおいてアプリのプログラムの詳細が把握できない場合であっても、適切な利用制限を行うことができる。

さらに、操作部２０は、アプリを再インストールすることによって、そのアプリと対応する署名を更新することができる。つまり、プログラムが同一バージョンでも署名を変えたアプリを再インストールすることにより、そのアプリに付された署名（に応じた利用機能の登録）を更新することができる。従って、アプリをサーバ装置２に登録する際に、アプリの機能と対応しない誤った種類の署名を付してしまったような場合であっても、これを容易に修正可能である。

なお、操作部２０が、予め定められた特殊モードの設定時にのみ、アプリのインストール済み一覧に、ユーザが利用できないアプリも含めて表示し、更新したいアプリとして選択できるようにしてもよい。そして、その更新時に、そのアプリに付された署名を更新することもできる。そして、表１のパターンＢの署名を付す等して、市販のアプリをインストールだけして起動しないように設定しておき、後からサーバ装置２で別の署名を付したバージョンアップ版のアプリをインストールすることで、アプリを起動可能にすることも考えられる。

〔第２実施形態〕
次に、この発明の情報処理システムの第２実施形態である画像処理システムについて説明する。なお、第２の実施形態も、各装置の具体的な動作は一部異なるものの、ハードウェア構成及びソフトウェア構成は第１実施形態と同様であるため、図１〜図３のうちの必要な図を参照する。これは、第３実施形態以降も同様とする。

この第２実施形態では、第１実施形態のサーバ装置２に代えて、アプリのインストール用ファイルを配布するダウンロードサーバ２ａと、アプリの利用承認（許可）を行う承認装置である認証サーバ２ｂを設けている。なお、ダウンロードサーバ２ａ及び認証サーバ２ｂを一体に構成することも妨げられない。
まず、第２の実施形態において操作部２０がアプリをダウンロードしてインストールする際の基本的な動作について説明する。

図９は、その動作に供する説明図であり、図４と共通の部分には同一符号を付している。
第３の実施形態では、操作部２０は、図９に示すように、ダウンロードサーバ２ａ及び認証サーバ（アクティベーションサーバ）２ｂとネットワーク３を介して通信可能である。

この操作部２０は、アプリの選択及びダウンロード指示を受け付けた場合に、ダウンロードサーバ２ａに選択されたアプリのインストール用ファイル２１０のダウンロードを要求して、そのファイルをダウンロードする（１）。
その後、操作部２０は、ダウンロードしたインストール用ファイル２１０中の署名データ２１２をチェックして、ダウンロードしたアプリをインストールしてよいか否か判断する（２）。この判断は、第１実施形態と同様な手順（図５のステップＳ２〜Ｓ５）で行う。
インストールしてよいと判断（インストール可と決定）した場合には、第１実施形態と同様な手順（図１０のステップＳ７）で、認証サーバ２ｂにアクセスすることなく、アプリのインストールを行う。

一方、署名がないか、あっても正しいものでない（有効期限切れ等）場合、操作部２０は、認証サーバ２ｂにアクセスしてアクティベーションを実行する（３）。
このアクティベーションに際して、操作部２０は、ユーザからアプリのアクティベーションコードの入力を受け付ける。このアクティベーションコードは、ユーザがアプリを利用する権限があることを示すコードであり、ユーザ登録や料金の支払いと引き替えにアプリのベンダーが提供することが考えられる。

そして、操作部２０は、アプリの識別情報（アプリのファイル自体でもよい）と共に、入力されたアクティベーションコードを認証サーバ２ｂに送信し、アプリの利用承認（アクティベーション）を要求する。
認証サーバ２ｂでは、アクティベーションコード毎に利用を承認するアプリを示す承認アプリ一覧テーブル２２１（権限情報）を管理しており、アプリの利用承認の要求を受けると、次の判断を行う。つまり、受信した情報と、承認アプリ一覧テーブル２２１に基づき、アクティベーションコードの持ち主に、要求されたアプリの利用を承認してよいか否か判断する。そして、その結果を操作部２０に返す。
また、認証サーバ２ｂは、アプリの利用を承認する場合、そのアプリが利用する本体１０の機能の情報、すなわちアプリ情報テーブル（表２）の機能カテゴリの欄に登録すべき情報を、承認結果と合わせて操作部２０に渡す。

操作部２０は、認証サーバ２ｂに利用が承認された場合、第１の実施形態の場合と同様にアプリをインストールし（４）、そのアプリが利用する機能の種類をアプリ情報テーブルに登録する。このとき、アクティベーションに用いたアクティベーションコードは記憶しておく。
一方、利用が許可されなかった場合、インストールを中止する。

以上の手順により、署名による確認に代えて認証サーバ２ｂによりアクティベーションを利用する場合でも第１の実施形態の場合と同様な、インストール可否の判断及び機能の制限を行うことができる。
なお、図９の説明においては、適当な署名がない場合にアクティベーションを行うとして説明したが、適当な署名がある場合でもアクティベーションを行うようにしてもよい。

次に、図２に示した操作部２０のＣＰＵ２１によるアプリインストール時の処理について説明する。
図１０は、その処理を示すフローチャートであり、図５と同じ処理には同じステップ番号を付している。

操作部２０のＣＰＵ２１は、ダウンロードしたいアプリの選択及びそのアプリのダウンロード要求を受け付けた場合に、図１０に示す処理を開始する。
この処理では、ＣＰＵ２１は、ステップＳ２又はＳ４の判断がＮＯの場合、ステップＳ５２，Ｓ５３で次の処理を行う。
この具体的処理について、図１１も用いて説明する。
図１１は、操作部２０がサーバ装置へアプリの利用承認を求め、その結果を受信してアプリをインストールする際の動作シーケンスを示す図である。

操作部２０（のＣＰＵ２１）は、ユーザからアプリのアクティベーションコードの入力を受け付け、そのアプリの識別情報と共に、入力されたアクティベーションコードを認証サーバ２ｂに送信し、アプリの利用承認を求める（Ｓ１０１：図１０のＳ５２と対応）。
認証サーバ２ｂは、操作部２０からこれらの情報を受信し、アプリの利用承認を求められると、上述したようにアクティベーションコードの持ち主に、要求されたアプリの利用を承認してよいか否か判断する（Ｓ１０２）。そして、その利用承認の結果（アクティベーション結果）を操作部２０に送信する（Ｓ１０３）。また、利用を承認する場合には、該当アプリが利用する本体１０の機能を示す情報も合わせて送信する。

操作部２０は、その利用承認の結果を受信すると、それに基づきアプリのインストール可否を判断する（Ｓ１０４：図１０のＳ５３と対応）。利用が承認されていればインストール可（アクティベーション成功）、承認されていなければインストール不可である。
そして、インストール可の場合、操作部２０はそのアプリのインストールを実行する（Ｓ１０５：図１０のＳ７と対応）。

その後、操作部２０は、ステップＳ５１で、上記利用承認結果（と共に渡された情報）に基づき、本体１０が備える機能のうち、そのアプリが利用する機能の種類を特定し、その情報をアプリ情報テーブル（表２）に登録する（Ｓ１０６：図１０のＳ５１及びＳ９と対応）。その処理が完了すると、図１０の処理を終了する。

一方、上記利用承認の結果が利用承認されなかったこと（アクティベーション失敗）を示すものであった場合には、図１１での図示は省略したが、図１０のステップＳ５３でＮＯとなる。そして操作部２０は、ステップＳ１０において、ダウンロードしたインストール用ファイル２１０に係るアプリはインストール否と決定してステップＳ１１へ進み、インストール処理を中止する。
ＣＰＵ２１は、次にステップＳ１２へ進み、ダウンロードしたインストール用ファイル２１０を破棄し、図１０の処理を終了する。

第２実施形態では、以上の処理により、操作部２０が、自己にアプリをインストールする際に、認証サーバ２ｂ（所定の承認装置）に対してそのアプリの利用承認を求める。そして、認証サーバ２ｂによる利用承認があった場合には、そのアプリによる利用を許可する機能の種類を、その利用承認に基づき設定する。それによって、署名のないアプリをインストールすることも可能になる。
なお、アプリが既にインストールされている状態で、アクティベーションのみ行うようにすることもできる。この場合も、認証サーバ２ｂは、図１１のステップＳ１０２及びＳ１０３の場合と同様に、利用承認可否の判断とその結果の送信を行う。

このときに通知されるアプリが利用する機能に係る情報が、アプリ情報テーブルにおける機能カテゴリの登録内容と異なる場合、これを更新するようにするとよい。このようにすれば、第１の実施形態において説明した、アプリに付す署名が更新されていた場合と同じ結果となる。
従って、例えば当初は機能カテゴリ「アプリ起動不可」の状態で配布され、インストールしたアプリを、課金確認後に起動可能にする（実際の利用機能と対応する情報を登録する）ような場合に、アプリの再ダウンロードが不要である。そして、その分だけ処理効率の向上につながる。

〔第３実施形態〕
次に、この発明の情報処理システムの第３実施形態である画像処理システムについて説明する。
この第３実施形態は、上述した第２実施形態と若干異なるだけなので、その部分についてのみ説明する。

この第３実施形態では、操作部２０のＣＰＵ２１が、図１０のステップＳ５２，Ｓ５３に当たる部分で次の処理を行う。
この具体的処理について、図１２も用いて説明する。

図１２は、操作部２０が認証サーバ２ｂへアプリの署名を依頼し、その結果を受信してアプリをインストールする際の動作シーケンスを示す図である。
操作部２０（のＣＰＵ２１）は、認証サーバ２ｂへアプリの利用承認を求める際、ダウンロードしたインストール用ファイル２１０中のａｐｋファイル２１１と、入力されたアクティベーションコードとを認証サーバ２ｂに送信する。そして、ａｐｋファイル２１１に対する署名を依頼する（Ｓ２０１）。

認証サーバ２ｂは、操作部２０からこれらの情報を受信し、署名の依頼を受けると、図１１のステップＳ１０２の場合と同様に、アクティベーションコードの持ち主に対し要求に係るアプリの利用を承認してよいか否か判断する（Ｓ２０２）。
そして、承認結果及びアプリの種別に応じた署名を受信したａｐｋファイル２１１に付し（Ｓ２０３）、操作部２０に返信する（Ｓ２０４）。

承認結果が承認不可であれば、表１に示したパターンＡやパターンＢのように、アプリの起動を不可とすることを示す署名を付す（インストールは可でもよい）。承認結果が承認可であれば、同じくパターンＣ〜Ｈのように、インストールが可で、アプリが利用する本体１０の機能の種類を示す署名を付す。署名が付された状態のａｐｋファイル２１１は、インストール用ファイル２１０と同じ形式とするとよい。
以上の機能を果たす認証サーバ２ｂは、この実施形態では認証装置として機能する。

操作部２０は、署名が付されたａｐｋファイル２１１を受信すると、その署名を検証し、署名の種類に基づき署名情報テーブルを参照してアプリのインストール可否を判断する（Ｓ２０５）。
そして、インストール可の場合、操作部２０はそのアプリのインストールを実行する（Ｓ２０６）。

その後、操作部２０は、ａｐｋファイル２１１に付された署名の種類に応じて、本体１０が備える機能のうち、インストールしたアプリが利用する機能を特定し、その情報をアプリ情報テーブル（表２）に登録する（Ｓ２０７）。

この第３実施形態では、以上の処理により、操作部２０が、認証サーバ２ｂ（所定の認証装置）に対してそのアプリの機能を実現するためのプログラムに対する署名を依頼する。そして、その依頼に応じた署名が付されたプログラムを、認証サーバ２ｂから受信すると、そのプログラムに付された署名を、上記アプリと対応する署名として用いる。このことにより、第２実施形態と同様の効果を得ることができる。

なお、特注アプリなどの場合、アプリに事前に署名を付しておくことが難しい場合もある。しかし、このような場合でも、図１２の処理によれば、認証サーバ２ｂにａｐｋファイル２１１の識別情報とその利用機能の情報を登録しておくだけで、操作部２０は、事後的に、署名の付されたアプリのデータを入手することができる。そして、初めから署名の付されたアプリをダウンロードした場合と同様な手順で、インストール可否の判断及び利用機能の登録を行うことができる。

操作部２０にＳＤカード（登録商標）等の記録媒体を装着して、特別に管理者が許可したＡｎｄｒｏｉｄマーケット上等の署名なしアプリを記録媒体経由でインストールしたい場合などにも、上述の動作で利用許可を与えることができる。これらのことについては、後述する第４実施形態でも同様とする。

〔第４実施形態〕
次に、この発明の情報処理システムの第４実施形態である画像処理システムについて説明する。
この第４実施形態は、上述した第３実施形態と若干異なるだけなので、その部分についてのみ説明する。

この第４実施形態では、操作部２０のＣＰＵ２１が、図１０のステップＳ５２，Ｓ５３で次の処理を行う。
この具体的処理について、図１３も用いて説明する。
図１３は、操作部２０がサーバ装置へアプリの署名を依頼し、その結果を受信してアプリをインストールする際の動作シーケンスを示す図である。なお、図１２と対応する部分に、同じ符号を付している。

図１３の処理は、操作部２０がａｐｋファイル２１１及びアクティベーションコードを認証サーバ２ｂではなくダウンロードサーバ２ａに送信する点と、それを受信したダウンロードサーバ２ａの動作が図１２と異なるのみである。また図１３の処理では、基本的には、操作部２０に、署名がない状態のアプリあるいは利用を許可できない状態のアプリをインストールし、その後ダウンロードサーバ２ａに対してアプリへの署名を求めることを想定している。

そして、ダウンロードサーバ２ａは、それらの情報を受信し、署名の依頼を受けると、図１１のステップＳ１０２の場合と同様に、アクティベーションコードの持ち主に対し要求に係るアプリの利用を承認してよいか否か判断する（Ｓ３０１）。
そして、承認してよい場合（Ｓ３０２のＹｅｓ）、受信したａｐｋファイル２１１に係るアプリと同じ名称のアプリのインストール用ファイル２１０を検索する（Ｓ３０３）。そして、発見されれば、これを操作部２０に送信する（Ｓ２０４）。
このインストール用ファイル２１０は、図４を用いて説明した通り、署名データ２１２を含むものである。

一方、ダウンロードサーバ２ａは、利用を承認できない場合や、インストール用ファイルがみつからない場合は、受信したａｐｋファイル２１１を、署名を付さない状態でインストール用ファイルとして操作部２０に返す。
以上により、操作部２０は、図１２の場合と同様、署名の依頼に応じて、アクティベーションの成否及びアプリが利用する機能に応じた署名の付された（又は署名のない）インストール用ファイル２１０を受信することができる。

このことにより、第３の実施形態の場合と同様な効果を得ることができる。さらに、ダウンロードサーバ２ａにおいて新たにａｐｋファイルに署名を付す必要がないため、どのアプリにどの署名を付すべきかという情報を管理する必要がない。また、ダウンロードサーバ２ａから操作部２０に送信するインストール用ファイル２１０が最新のものであれば、実質的に、署名を付す際にアプリのアップデートを行うことができる。
このような特徴は、まずアプリのデバッグ版を操作部２０にインストールし、その後これをリリース版に置き換えるような場合に有用である。

〔この実施形態におけるプログラム〕
この発明の実施形態であるプログラムは、操作部２０を制御するＣＰＵ２１（コンピュータ）に上述した機能を実現させるためのプログラムである。そして、このようなプログラムをコンピュータに実行させることにより、上述したような効果を得ることができる。

このようなプログラムは、はじめからコンピュータに備えるＨＤＤ（ハードディスク装置）、あるいはＲＯＭや他の不揮発性記憶媒体（フラッシュメモリ，ＥＥＰＲＯＭ等）などに格納しておいてもよい。しかし、記録媒体であるＣＤ−ＲＯＭ、あるいはメモリカード，フレキシブルディスク，ＭＯ，ＣＤ−Ｒ，ＣＤ−ＲＷ，ＤＶＤ＋Ｒ，ＤＶＤ＋ＲＷ，ＤＶＤ−Ｒ，ＤＶＤ−ＲＷ，又はＤＶＤ−ＲＡＭ等の不揮発性記録媒体に記録して提供することもできる。それらの記録媒体に記録されたプログラムをコンピュータにインストールして実行させることにより、上述した各手順を実行させることができる。
さらに、ネットワークに接続され、プログラムを記録した記録媒体を備える外部装置あるいはプログラムを記憶手段に記憶した外部装置からダウンロードし、コンピュータにインストールして実行させることも可能である。

〔変形例〕
以上で実施形態の説明を終了するが、この発明において、各部の具体的な構成や処理の内容、データの形式や項目等は、実施形態で説明したものに限るものではない。
例えば、操作部２０が、アプリが利用する機能の種類（機能範囲）を、例えば表６に示すように、電子署名の種類に対応する、アプリのベンダー名（ベンダーコード）に応じて登録することもできる。
また、表１〜表５に規定する機能は、より細かいものでもよい。

また、上述した各実施形態では画像処理システム１を、本体１０と操作部２０とを固定的に組み合わせて構成した例について説明したが、これには限られない。
操作部と本体（動作部）とを、ハードウェアコンポーネントとして全く別の装置としてもよい。例えば、スマートフォン等のモバイル端末を操作部とし、ＭＦＰ等の画像処理装置を動作部として画像処理システムあるいは情報処理システムを構成してもよい。特に、操作部と動作部を無線で接続する場合には、これらは全く独立した装置として構成可能である。

また、操作部と動作部とは、１対１でなくてもよい。例えば、本体に有線接続された操作部がある画像処理装置を、モバイル端末からも操作できるようにすることが考えられる。あるいは、１台の画像処理装置を複数のモバイル端末から操作できるようにすることも考えられる。あるいはまた、１台のモバイル端末から操作対象を切り替えつつ複数の画像処理装置を操作できるようにすることも考えられる。

また、上述した操作部２０と本体１０の機能を、それぞれ複数台の装置が協働して実現する構成であってもよい。逆に、操作部２０と本体１０とが１つの筐体に収まっていてもよい。あるいは、操作部がアプリを実行する際に同時に又は選択的に複数の動作部を利用することがあってもよい。

また、情報処理システムを構成する１のモジュールが、スキャナやプロッタのような画像処理エンジンを備えていることも必須ではない。各モジュールは、任意の情報処理装置でよい。もちろん、情報処理以外の物理的な入力や出力を合わせて行う装置でもよい。
さらに、この発明は上述した実施形態に限定されるものではなく、特許請求の範囲に記載された技術思想に含まれる技術的事項の全てが対象となることは言うまでもない。
さらにまた、以上説明してきた実施形態、動作例及び変形例の構成は、相互に矛盾しない限り任意に組み合わせて実施可能であることは勿論である。

１：画像処理システム、２：サーバ装置、２ａ：ダウンロードサーバ、２ａ：認証サーバ、３：ネットワーク、３ａ：ＬＡＮ、３ｂ：無線ＬＡＮ・ＡＰ、１０：本体、１１，２１：ＣＰＵ、１２，２２：ＲＯＭ、１３，２３：ＲＡＭ、１４：ＨＤＤ、１５，２５：通信Ｉ／Ｆ、１６，２６：接続Ｉ／Ｆ、１７：エンジン部、１８，２８：システムバス、２０：操作部、２７：操作パネル、３０：通信路、１０１，２０１：アプリ層、１０２，２０２：サービス層、１０３，２０３：ＯＳ層、２１０：インストール用ファイル、２１１：ａｐｋファイル、２１２：署名データ、２２１：承認アプリ一覧テーブル

特開２０１１−２９７８号公報 特開２００９−１４０３４７号公報

Claims (8)

1. 指示の入力を受け付ける操作部と、該操作部が受け付けた指示に基づき情報処理動作する動作部とを備える情報処理システムであって、
   前記操作部が備えるアプリケーションと対応する電子署名に応じて、前記動作部が備える機能のうち前記アプリケーションが利用する機能の種類を示す機能情報を登録する登録手段を備えることを特徴とする情報処理システム。
2. 請求項１に記載の情報処理システムであって、
   ユーザ毎に該ユーザに利用を許可する前記動作部の機能の種類を登録した権限情報及び、前記登録手段が登録した機能情報に基づき、前記操作部を操作するユーザに、該ユーザが利用を許可されていない種類の機能を利用するアプリケーションを利用させないようにする禁止手段を備えることを特徴とする情報処理システム。
3. 請求項１又は２に記載の情報処理システムであって、
   前記操作部にアプリケーションを再インストールすることによって該アプリケーションと対応する電子署名を更新する更新手段を備えることを特徴とする情報処理システム。
4. 請求項１乃至３のいずれか一項に記載の情報処理システムであって、
   前記操作部にアプリケーションをインストールする際に、所定の承認装置に対して該アプリケーションの利用承認を求める手段を備え、
   前記登録手段は、前記承認装置による利用承認があった場合には、前記インストールするアプリケーションが利用する機能の種類を、該利用承認に基づき登録することを特徴とする情報処理システム。
5. 請求項１乃至４のいずれか一項に記載の情報処理システムであって、
   前記操作部にアプリケーションをインストールする際に、所定の認証装置に対して該アプリケーションの機能を実現するためのプログラムに対する電子署名を依頼する手段と、
   該依頼に応じた電子署名が付されたプログラムを、前記認証装置から受信する手段とを備え、
   該プログラムに付された電子署名を、前記アプリケーションと対応する電子署名として用いることを特徴とする情報処理システム。
6. 請求項１乃至５のいずれか一項に記載の情報処理システムであって、
   前記登録手段は、前記アプリケーションが利用する機能の種類を、前記電子署名に対応する、アプリケーションのベンダー名に応じて登録することを特徴とする情報処理システム。
7. 指示の入力を受け付ける操作部と、該操作部が受け付けた指示に基づき情報処理動作する動作部とを備える情報処理システムにおける前記操作部として機能する情報処理装置であって、
   当該操作部が備えるアプリケーションと対応する電子署名に応じて、当該動作部が備える機能のうち前記アプリケーションが利用する機能の種類を示す機能情報を登録する登録手段を備えることを特徴とする情報処理装置。
8. 指示の入力を受け付ける操作部と、該操作部が受け付けた指示に基づき情報処理動作する動作部とを備える情報処理システムを制御するコンピュータを、
   前記操作部が備えるアプリケーションと対応する電子署名に応じて、前記動作部が備える機能のうち前記アプリケーションが利用する機能の種類を示す機能情報を登録する登録手段として機能させるためのプログラム。

Images