JP2017107576A - 情報処理システムとそのアプリケーションの利用可能機能決定方法、並びに情報処理装置及びプログラム - Google Patents

Abstract

【課題】 指示の入力を受け付ける操作部と、該操作部が受け付けた指示に基づき情報処理動作する動作部とを備える情報処理システムにおいて、操作部にインストールしたアプリケーションが適切に動作しない事態を防止できるようにする。
【解決手段】 画像処理システム１において、操作部２０と本体１０とを相互に通信可能なモジュールとする。そして、操作部２０にアプリケーションをインストールする場合に、操作部２０で利用可能なリソースを示す操作部リソース情報及び本体１０で利用可能なリソースを示す本体リソース情報を取得する（Ｓ２，Ｓ４）。そして、インストールするアプリケーションが要求するリソースを示す要求リソース情報と、上記操作部リソース情報及び上記動作部リソース情報との比較に基づき、そのアプリケーションのインストール可否を決定する（Ｓ６，Ｓ１１）。
【選択図】 図５

Description

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

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

また、このような情報処理装置では、サーバ装置と通信可能に接続し、サーバ装置からアプリケーションをダウンロード及びインストールして機能を追加する際に、本体の組み合わせやリソースによりアプリケーションのインストール可否を決定することが知られている。
このようなアプリケーション等のプログラムのインストールに関連する技術としては、例えば特許文献１，２に記載のものが知られている。

特許文献１に記載の管理サーバは、アプリケーションのインストール先である画像形成装置のリソースの不足等でインストールできない場合、掃き出し処理によりリソースを解放してアプリケーションをインストールするようにしている。
特許文献２に記載の画像処理装置では、独立した各ユニットにインストールするプログラムの組み合わせ不一致で対応する機能が無効にならないように、その組み合わせ不一致が発生しないようにプログラムのバージョン変更を行うようにしている。

しかしながら、上述したような情報処理システムでは、次のような問題があった。
すなわち、アプリケーションをダウンロードしてインストールする仕組みにおいては、インストール先の装置のリソースをもとにインストール可否を決定している。従って、インストール先の装置が他の装置のリソースを利用してアプリケーションを実行する場合には、当該他の装置が十分にリソースを有しないため、インストールができても対応する機能を利用できない場合があるという問題があった。

また、特許文献１及び２のいずれに記載の発明も、インストール先の装置が利用する他の装置のリソースについては考慮しておらず、この問題を解決できない。
この発明は、上記の点に鑑みてなされたものであり、指示の入力を受け付ける操作部と、該操作部が受け付けた指示に基づき情報処理動作する動作部とを備える情報処理システムにおいて、操作部にインストールしたアプリケーションが適切に動作しない事態を防止できるようにすることを目的とする。

この発明は、指示の入力を受け付ける操作部と、該操作部が受け付けた指示に基づき情報処理動作する動作部とを備える情報処理システムであって、上記の目的を達成するため、上記操作部にアプリケーションをインストールする場合に、上記操作部で利用可能なリソースを示す操作部リソース情報及び上記動作部で利用可能なリソースを示す動作部リソース情報を取得し、インストールするアプリケーションが要求するリソースを示す要求リソース情報と、上記操作部リソース情報及び上記動作部リソース情報との比較に基づき、該アプリケーションのインストール可否を決定する決定手段を備えるものである。

上記構成によれば、指示の入力を受け付ける操作部と、該操作部が受け付けた指示に基づき情報処理動作する動作部とを備える情報処理システムにおいて、操作部にインストールしたアプリケーションが適切に動作しない事態を防止できるようにすることができる。

この発明の情報処理システムの第１実施形態である画像処理システムの利用環境を示す図である。 図１の画像処理システムのハードウェア構成を示すブロック図である。 図２に示した本体及び操作部のソフトウェア構成を操作部とネットワークの通信に関する機能と共に示す図である。 図１に示した操作部がサーバ装置からアプリケーションをダウンロードしてインストールする際の基本的な動作を説明するための図である。 図２に示した操作部によるアプリケーションのインストール時の処理を示すフローチャートである。 第２実施形態における操作部がダウンロードサーバからアプリケーションをダウンロードしてインストールする際の動作を説明するための図である。 同じく操作部がアプリケーションをインストールした後のリソース変化に伴う利用可能機能の変更処理を示すフローチャートである。 第３実施形態における操作部がサーバ装置からアプリケーションをダウンロードしてインストールする際の動作シーケンスを示す図である。 第４実施形態における操作部がサーバ装置に機能利用制限情報の変更を要求する際の動作シーケンスを示す図である。

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

この実施形態の一つの特徴は、画像処理システム１が行う以下の動作である。つまり、操作部２０にアプリケーションをインストールする場合に、インストール先の操作部２０で利用可能なリソースを示す操作部リソース情報及び本体１０で利用可能なリソースを示す本体（動作部）リソース情報を取得する。そして、インストールするアプリケーションが要求するリソースを示す要求リソース情報と、上記操作部リソース情報及び上記動作部リソース情報との比較に基づき、そのアプリケーションのインストール可否を決定する。以下、この動作を含む各動作について説明する。

まず、操作部２０がサーバ装置２からアプリをダウンロードしてインストールする際の基本的な動作について説明する。なお、説明の便宜のため、後述するリソース情報のチェックに関する説明はここでは省略する。
図４は、その動作に供する説明図である。

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

サーバ装置２は、各種アプリのインストール用ファイルを管理するものであり、その各ファイルを記憶保持している。各アプリのインストール用ファイルはそれぞれ、アプリのプログラムを含む本体ファイルであるａｐｋファイル（android application package file）と、ａｐｋファイルに付した電子署名である署名データとを含む。

サーバ装置２は、操作部２０からダウンロード要求（依頼）を受けると、要求されたアプリのインストール用ファイルを読み出して操作部２０へ返信する。
操作部２０は、ダウンロード要求に応じて送信されてくるインストール用ファイルダウンロード（受信）した後、それに含まれている署名データをチェックして、ダウンロードしたアプリケーションをインストールしてよいか否か判断する。ここでは、署名が適正であれば、適正な供給元から供給されたプログラムであり、インストールしても害はないと認識し、インストール可と判断する。

なお、アプリケーションのインストール可と決定した場合にも、本体１０の機能の利用を制限することが可能である。この機能の利用制限として、アプリケーションをインストールしても本体１０の機能を全く利用可能（有効）にしない、一部の機能のみを利用可能にするなどがあり得る。

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

この処理において、ＣＰＵ２１はまずステップＳ１で、サーバ装置２に要求して選択されたアプリの要求リソース情報を取得（ダウンロード）する。この要求リソース情報は、アプリをインストールしてその機能を発揮するために要求されるハードウェアリソースを示す情報である。その例は、例えば表１に示すものである。

表１に示す通り、要求リソース情報は、そのアプリのインストール先である操作部２０側に要求されるリソースと、その操作部２０がアプリの機能を発揮させるに当たって利用する装置である本体１０側に要求されるリソースとをそれぞれ示すものである。
また、表１に示すように、アプリが提供する機能のうち、一定の範囲毎に、その機能を利用するために必要なハードウェアリソースを示すようにしてもよい。表１の例は、利用可能機能範囲の欄に記載した機能を利用するために、その右側２列に示すハードウェアリソースが、操作部２０側と本体１０側にそれぞれ必要であることを示す。「インストールのみ」は、インストール自体に必要なリソースであり、これが確保できない場合には、インストール自体実行できない。

なお、要求リソース情報に示されるハードウェアリソースの種類は、表１ではストレージの容量、ワークメモリの容量及びＣＰＵパワーである。しかし、これ以外にも、プリントエンジンやスキャナエンジンのカラー／モノクロ及び対応解像度、両面ユニットや後処理（ステープル、パンチ、製本など）ユニットの有無、ディスプレイの解像度などを記載することも考えられる。
以上のような要求リソース情報は、アプリのベンダーが作成して、アプリを提供するサーバ装置２に設定しておくものである。

図５の説明に戻ると、ＣＰＵ２１は、ステップＳ１の後ステップＳ２で、アプリのインストール先である操作部２０で利用可能なリソースを示す操作部リソース情報を取得する。この取得は、ステップＳ１で取得した要求リソース情報との対比に必要な範囲で行えばよい。また、比較に当たって、操作部２０が当該リソースを備えているか否かを示す情報が必要な場合（ディスプレイの解像度など）と、当該リソースに残量があるか否かを示す情報が必要な場合（ストレージの容量など）があるので、この点にも注意する。以下のステップＳ４でも同様である。

ＣＰＵ２１は次に、ステップＳ３へ進み、ステップＳ１で取得した要求リソース情報とステップＳ２で取得した操作部リソース情報とを比較して、操作部２０において、アプリのインストールに最低限必要なリソースを利用可能か否か判断する。

そして、その判断がＹＥＳの場合、ＣＰＵ２１は、ステップＳ４へ進み、操作部２０がアプリを実行する際に利用する本体１０において利用可能なリソースを示す本体リソース情報を、本体１０に要求して取得する。なお、本体１０が、本体１０側アプリの利用に供するリソースと、操作部２０を含む外部装置のアプリの利用に供するリソースとを分けて管理している場合には、後者の中で利用可能なリソースを示す情報を取得する。

ＣＰＵ２１は次に、ステップＳ５へ進み、ステップＳ１で取得した要求リソース情報とステップＳ４で取得した本体リソース情報とを比較して、本体１０において、アプリのインストールに最低限必要なリソースを利用可能か否か判断する。
そして、その判断がＹＥＳの場合、ＣＰＵ２１は、ステップＳ６において、選択されたアプリはインストール可と決定してステップＳ７へ進む。

ステップＳ３又はＳ５の判断がＮＯの場合、ＣＰＵ２１は、ステップＳ１１において、選択されたアプリはインストール否と決定してステップＳ１２へ進み、インストール処理を中断し、図５の処理を終了する。
以上のステップＳ３、Ｓ５、Ｓ６及びＳ１１において、ＣＰＵ２１は決定手段として機能する。

またＣＰＵ２１は、ステップＳ７へ進むと、選択されたアプリのインストール用ファイルをサーバ装置２からダウンロードする。そして、ステップＳ８でそのファイルの署名データを検証し、問題なければアプリのインストールを実行する。
次に、ＣＰＵ２１はステップＳ９で、ステップＳ１で取得した要求リソース情報と、ステップＳ２で取得した操作部リース情報と、ステップＳ４で取得した本体リソース情報とに基づき、インストールしたアプリの機能のうち現在利用可能なリソースで利用できないものを特定する。

そして、ステップＳ１０で、その特定した機能を無効化することを示す機能利用制限情報を登録し、図５の処理を終了する。このステップＳ９及びＳ１０において、ＣＰＵ２１は無効化手段として機能する。
以後、ＣＰＵ２１がそのアプリを実行する場合、機能利用制限情報を参照し、無効化した機能に関する動作は行わないようにする。機能利用制限情報を参照する機能は、ＯＳに設けても、アプリに設けてもよい。

以上の第１実施形態では、操作部２０が、自己にアプリをインストールする場合に、インストール先の操作部２０で利用可能なリソースを示す操作部リソース情報及び本体（動作部）１０で利用可能なリソースを示す本体リソース情報を取得する。そして、インストールするアプリが要求するリソースを示す要求リソース情報と、取得した操作部リソース情報及び本体リソース情報との比較に基づき、そのアプリのインストール可否を決定する。

したがって、インストール可の場合のみインストールを行うようにすることにより、リソース不足によりインストールが失敗する事態を防止することができる。
また、図５の処理ではインストール可否の判断基準をインストール自体が可能であるか否かに置いたが、アプリの一定範囲の機能（あるいは全ての機能）を利用可能であるか否かに置くこともできる。この基準を用いれば、アプリをインストールしたがそのアプリが動作しない、という事態を防止することができる。

また、第１実施形態では、操作部２０が、上記要求リソース情報と、操作部リソース情報及び本体リソース情報との比較に基づき、ダウンロードしたアプリの機能のうち現在の操作部２０及び本体１０のリソースでは利用できない機能を無効にするようにしている。従って、インストールしたアプリを実行する際に、リソース不足によりシステムがハングアップするような不具合を防止することができる。

なお、要求リソース情報に、ネットワークリソースを記載することもできる。操作部２０側のアプリが本体１０と外部装置との間で通信をするためのネットワーク３で大きな帯域を占有してしまうと、本体１０側のアプリと外部装置との間の通信に影響が出る恐れがある。これを防止するため、予め操作部２０のアプリケーションが利用できる帯域を登録しておくとよい。この登録は本体１０側で行うことが望ましい。従って、ネットワークリソースは、厳密には本体１０側のリソースとも操作部２０側のリソースとも言い難いが、本体１０側のリソースに含まれると考えることができる。

そして、表２に、ネットワーク中で利用可能な通信帯域幅に応じて、アプリ中で利用可能な通信機能を制限することを示す要求リソース情報の例を示す。表２の情報は例えば、１Ｍｂｐｓ（メガビット毎秒）の帯域が利用可能であればメール送信とブラウザが利用可能であり、１０Ｍｂｐｓの帯域が利用可能であればこれに加えて画像送信が利用可能であることを示す。

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

この第２実施形態は、第１の実施形態のサーバ装置２に対応し、アプリのインストール用ファイルを配布するダウンロードサーバ２ａに加え、アプリの利用許可を行う認証サーバ２ｂを設けた点である。
まず、第２の実施形態において操作部２０がアプリをダウンロードしてインストールする際の基本的な動作について説明する。

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

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

一方、署名データがないか、あっても正しいものでない場合（有効期限切れ等）、操作部２０は、認証サーバ２ｂにアクセスしてアクティベーションを実行する（３）。
この処理においては、操作部２０は、第１の実施形態の場合と同様に、上記要求リソース情報と、操作部リソース情報及び本体リソース情報との比較に基づき、アプリの機能のうち利用可能な機能を特定する。

また、ユーザからアプリのアクティベーションコードの入力を受け付ける。このアクティベーションコードは、ユーザがアプリを利用する権限があることを示すコードであり、ユーザ登録や料金の支払いと引き替えにアプリのベンダーが提供することが考えられる。また、アクティベーションコード毎に、利用できる機能の種類を制限することもできる。コード自体に利用可能な機能の情報を埋め込んでもよいし、認証サーバ２ｂが、各コードとそのコードで利用可能な機能との対応関係を権限情報として管理してもよい。

そして、操作部２０は、アプリの識別情報（アプリのファイル自体でもよい）と共に、利用したい機能の情報（上記特定した利用可能な機能の情報でよい）と、入力されたアクティベーションコードとを認証サーバ２ｂに送信し、アプリの利用許可（アクティベーション）を要求する。
認証サーバ２ｂでは、受信した情報と、自身が管理するアクティベーションコード毎の権限情報に基づき、アクティベーションコードの持ち主に、要求されたアプリについて要求された機能の利用を許可してよいか否か判断する。そして、その結果を操作部２０に返す。

操作部２０は、認証サーバ２ｂに利用が許可された場合、第１の実施形態の場合と同様にアプリをインストールし（４）、利用が許可された機能以外を無効化することを示す機能利用制限情報を登録する。このとき、アクティベーションに用いたアクティベーションコードは記憶しておく。
一方、利用が許可されなかった場合、インストールを中止する。なお、各種リソース情報に基づき特定した利用可能な機能の中から、実際に利用する機能の範囲を絞って再度アクティベーションを試みることができるようにしてもよい。

以上の手順により、認証サーバ２ｂによりアクティベーションを利用する場合でも第１の実施形態の場合と同様な、インストール可否の判断及び機能の制限を行うことができる。ただし、第２の実施形態の場合、アクティベーションコードにより得られるアプリの利用権限によっては、必要なハードウェアリソースがあってもアプリをインストールできなかったり機能を利用できなかったりする場合もある。
なお、図６の説明においては、適当な署名データがない場合にアクティベーションを行うとして説明したが、適当な署名データがある場合でもアクティベーションを行うようにしてもよい。

次に、操作部２０へのアプリインストール後のリソース変化に伴う利用可能機能の変更処理について説明する。
図７は、その処理を示すフローチャートである。
操作部２０のＣＰＵ２１は、図６を用いて説明したようにアプリをインストールした後、定期的に図７に示す処理を開始する。

そして、まずステップＳ２１において、要求リソース情報、操作部リソース情報及び本体リソース情報を取得する。これらのうち操作部リソース情報及び本体リソース情報は、図５のステップＳ２及びＳ４で取得する情報と同じものであるが、この処理時点の情報を取得する。要求リソース情報は、図５のステップＳ１で取得した情報と同じものである。その都度ダウンロードサーバ２ａ（サーバ装置２）にアクセスして取得してもよいが、アプリのインストール時に操作部２０に記憶させておき、これを取得するとよい。

ＣＰＵ２１は、次のステップＳ２２で、取得した要求リソース情報、操作部リソース情報及び本体リソース情報に基づいて、アプリの機能のうち現在利用可能なハードウェアリソースで利用可能な機能を特定する。そして、利用可能な機能が前回処理時から変化しているか否か判断する。この判断手法は、第１の実施形態で説明したものと同様である。

メモリやハードディスクを増設したり、他のアプリをアンインストールしていたりすれば、利用可能なリソースが増加し、これにより利用可能な機能が増えることが考えられる。逆に、他の優先度が高い用途にリソースを確保されたり、ハードウェアの取り外しや故障等があったりして、利用可能なリソースが減少し、これにより利用可能な機能が減ることも考えられる。

いずれにせよ、利用可能な機能に変化があった場合、ステップＳ２３に進み、ＣＰＵは、変化後の機能を利用するためにアクティベーションが必要か否か判断する。例えば、アプリのインストール時にアクティベーションを行っており、かつ利用可能な機能が増える場合は、その増えた機能の利用権限の有無を確認するため、アクティべーションが必要であると考えられる。逆に、アプリのインストール時に署名の確認のみでアクティベーションを行っていなかったり、利用可能な機能が減少したりした場合には、変化後の状態で利用が可能であることを改めて確認する必要はないと考えられる。

そして、ＣＰＵ２１は、ステップＳ２３でアクティベーションが必要と判断した場合、ステップＳ２４で、変化後の利用可能機能について、図６の（３）の場合と同様に、認証サーバ２ｂに利用許可を求める。ただし、アクティベーションコードは、アプリのインストール時に記憶しておいたものを用いる。
ステップＳ２５で利用許可の有無を判断し、許可されていれば、ステップＳ２６で、ステップＳ２２で特定した変化後の利用可能機能に基づき機能利用制限情報を変更し、処理を終了する。
このことにより、以後は、処理時点での利用可能リソースに応じた機能を利用できるようになる。

一方、ステップＳ２５でＮＯの場合には、変化後の利用可能機能について利用権限の確認が取れないため、機能利用制限情報を変更せずに処理を終了する。この場合、処理以前から利用可能であった機能のみ利用可能である。
なお、この場合、実際に利用可能である機能と、リソース情報に基づき利用可能と判断される機能とが異なることになる。ステップＳ２２での変化有無の判断には、実際に利用可能である機能を基準とするとよい。ただし、利用が拒否された機能を記憶しておき、アクティベーションコードの変更がない限り、同じ機能については許可の見込みがないため利用許可の要求をしないようにするとよい。

また、ステップＳ２３でＮＯの場合には、変化後の利用可能機能を実際に利用できるようにすることに障害はないと考えられるため、そのままステップＳ２６に進んで機能利用制限情報を更新する。
また、ステップＳ２２でＮＯの場合には、以後の処理を行う必要がないため、そのまま処理を終了する。

第２実施形態では、以上の処理により、操作部２０が、アプリのインストール後も、操作部２０及び本体１０で利用可能なリソースを監視する。そして、リソースの制約のため無効にされていた機能がリソースの増加により利用可能となったことを検出すると、その利用可能となった機能を自動的に有効にすることができる。逆に、有効にされていた機能がリソースの増加により利用不可能となったことを検出すると、その利用不可能となった機能を自動的に無効にすることもできる。これらの機能変更に当たってアクティベーションが必要であれば、それも自動で行うことができる。

従って、インストール後のアプリにつき、利用可能なハードウェアリソースの変化に応じて利用可能な機能を調整し、可能な範囲で最大限の機能が利用できるような設定を自動で行うことができる。よって、インストールしたアプリの利用効率が向上する。
なお、リソースの監視は、操作部２０及び本体１０の一方のみで行ってもよい。このようにしても、その監視対象の箇所におけるリソース変化によって利用可能となった機能を自動的に有効にすることができる。

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

この第３実施形態では、操作部２０が、選択されたアプリをサーバ装置２からダウンロードしてインストールする際に、取得した操作部リソース情報及び本体リソース情報をサーバ装置２へ送信する。
サーバ装置２は、操作部２０から、操作部リソース情報及び本体リソース情報を送信された場合に、これらと、アプリに関する要求リソース情報とを比較してアプリのインストール可否を決定し、その結果を操作部２０に通知する。

この具体的処理について、図８を用いて説明する。
図８は、操作部２０がサーバ装置２からアプリをダウンロードしてインストールする際の動作シーケンスを示す図である。

操作部２０（のＣＰＵ２１）は、ユーザによってインストールしたいアプリの選択及びダウンロード指示を受け付けると、図８に示すように、操作部リソース情報及び本体リソース情報を取得する（Ｓ２０１）。取得方法は第１の実施形態の場合と同様でよいが、どの範囲の情報が必要であるかは、予め設定しておくか、あるいはサーバ装置２に問い合わせる。
次に、操作部２０は、それらのリソース情報と選択されたアプリの識別情報（アプリ情報）とをサーバ装置２へ送信する（Ｓ２０２）。ここで送信する操作部リソース情報及び本体リソース情報の一例を、表３に示す。

サーバ装置２は、操作部２０からこれらの情報を受信すると、アプリ情報と対応する要求リソース情報と、受信した操作部リソース情報及び本体リソース情報とを比較して、アプリのインストール可否及び、インストールした場合に利用可能な機能を決定する（Ｓ２０３）。そして、その結果を操作部２０に送信する（Ｓ２０４）。この機能が、決定手段としての機能に相当する。

操作部２０は、サーバ装置から決定結果を受信すると、まずその結果からインストール可否を判断する。ここでインストール否であればユーザにその旨を通知して処理を終了するが、ここではインストール可であるとする（Ｓ２０５）。
この場合、操作部２０は、サーバ装置２に対してアプリのインストール用ファイルのダウンロードを要求する（Ｓ２０６）。サーバ装置２はこの要求に応じて操作部２０へインストール用ファイルを送信する（Ｓ２０７）。
これを受信した操作部２０は、受信したファイルを用いてインストールを実行する（Ｓ２０８）と共に、ステップＳ２０４で受信した決定結果に基づき、機能利用制限情報を登録して（Ｓ２０９）、処理を終了する。

以上の処理によっても、第１の実施形態の場合と同様、要求リソース情報と、操作部２０が取得した操作部リソース情報及び本体リソース情報との比較に基づき、アプリのインストール可否を決定することができる。また、利用可能な機能も決定することができる。また、サーバ装置２がインストール可否及び利用可能機能の決定に係る処理を担うので、その分だけ第１の実施形態の場合より操作部２０側の処理負担が減る。

なお、サーバ装置２は、ステップＳ２０３においてインストールは可能だが利用できない機能があると決定した場合、その結果を操作部２０に通知することに代えて、次のようにすることもできる。
すなわち、まずインストール可能であることのみ操作部２０に通知する。その後、操作部２０から選択されたアプリのダウンロード要求を受けた場合に、そのアプリのインストール用ファイルとして、上記決定に基づき、利用可能な機能のみ有効にした状態のプログラムを含むインストール用ファイルを生成して、操作部２０に送信する。
このようにすれば、操作部２０側で機能利用制限情報を登録したり、機能利用制限情報に基づいて機能の制限をしたりしなくても、アプリが提供する機能のうち操作部及び動作部のリソースでは利用できない機能を無効にすることができる。この場合、サーバ装置２が無効化手段として機能する。

あるいは、サーバ装置２は、ステップＳ２０４で決定結果を通知することに代えて、サーバ装置２側で機能利用制限情報を作成して操作部２０に送信し、これを登録させるようにしてもよい。この場合も、サーバ装置２が無効化手段として機能する。

なお、以上のようにサーバ装置２において集中的にダウンロード可否や利用可能機能の決定を行う場合、アプリのインストール先のシステム毎に、通知された空きリソースの情報と、それに応じて決定した利用可能機能とを対応付けて記憶させておくとよい。この例を表４に示す。

〔第４実施形態〕
次に、この発明の情報処理システムの第４実施形態について説明する。
この第４実施形態では、画像処理システム１が上述した第３実施形態と同様の動作に加え、以下に示す機能利用制限情報の変更に係る動作も行う。
図９は、その動作シーケンスを示す図である。

操作部２０は、随時操作部２０及び本体１０の利用可能リソースを監視しており、これが変化したことを検出すると（Ｓ３０１）、図９に示すように、サーバ装置２に対して利用可能機能に変化がないか確認を求める。すなわち、インストールされているアプリを示すアプリ情報と、操作部リソース情報及び本体リソース情報を、サーバ装置２に送信する（Ｓ３０２）。複数のアプリがインストールされている場合、複数のアプリ情報を送信すればよい。
サーバ装置２は、これらの情報を確認すると、アプリ情報と対応する要求リソース情報と、受信した操作部リソース情報及び本体リソース情報に基づき、利用可能な機能を決定する（Ｓ３０３）。そして、その結果を操作部２０に送信する（Ｓ３０４）。

操作部２０は、サーバ装置から決定結果を受信すると、その結果から利用可能機能に現状と比べて変化があったか否か判断する。ここで否であればそのまま処理を終了するが、ここでは変化があったとする（Ｓ３０５）。
この場合、操作部２０は、サーバ装置２に対して利用可能機能の変更を要求する（Ｓ３０６）。サーバ装置２は、この要求を受けると、必要に応じて権限等も考慮して変更の可否を判断する（Ｓ３０７）。
ここでは問題ないものとすると、サーバ装置２は、操作部２０に対して変更許可の応答を返す（Ｓ３０８）。操作部２０は、これを受信すると、自身の機能利用制限情報を更新し（Ｓ３０９）、処理を終了する。

以上の後、操作部２０においては、アプリが提供する機能のうち、変更後の機能利用制限情報に従った機能が利用可能となる。ここで複数のアプリについて利用可能機能が変更されることもある。また、この変更により、利用可能機能が増える場合も減る場合もある。
なお、ステップＳ３０１において、監視すべきリソース情報に、頻繁に値が変わる項目（例えばストレージの空き容量など）があると、サーバ装置２へのアクセス頻度が多くなってしまう。そこで、このような場合には一定閾値以上の変化があった場合に値が変化したものと取り扱うとよい。

以上の処理によれば、操作部２０が、操作部２０及び本体１０で利用可能なリソースを監視し、利用可能なリソースに変化があった場合に、サーバ装置２に操作部リソース情報及び動作部リソース情報を送信して、アプリが提供する機能のうち利用できない機能の再決定を要求する。従って、リソースの変化により利用可能な機能が増減した場合に、速やかにこれをアプリの動作に反映させることができる。

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

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

〔変形例〕
以上で実施形態の説明を終了するが、この発明において、各部の具体的な構成や処理の内容、データの形式や項目等は、実施形態で説明したものに限るものではない。
例えば、要求リソース情報に規定する機能は、表１より細かいものでもよい。表５に示すように、プレビュー機能の中で、選択可能な各プレビューサイズについて、異なる必要メモリ容量を規定することも考えられる。この場合、本体リソース情報中のワークメモリ容量の情報を、要求リソース情報と比較し、必要メモリ容量が本体１０において利用可能なメモリ容量より大きい選択肢を無効にするようにすればよい。
操作部２０のリソースではなくて、本体１０のリソースにて作業を行うプレビュー画像の作成等は、ワークメモリへの画像データの展開が必要になるため、操作パネル２７に表示できる操作画面（ユーザインターフェース）に影響を与えることになる。

また、ユーザ毎に、該ユーザが利用可能なリソースが設定されている場合、その設定を行っている利用権限情報を参照し、ログイン中のユーザが利用可能なリソースの情報を、インストール可否や利用可能機能の決定に用いるとよい。装置がリソースを備えていても、ユーザがそのリソースを利用できなければ、アプリの機能を実行できないためである。操作部２０と本体１０の一方のみについて利用権限情報が規定されている場合、そちらのみについて利用権限情報を参照すればよい。
なお、一旦アプリをインストールした後でログインユーザが変更になったり利用権限情報が変更されたりした場合には、図７や図９で説明したように、利用可能なリソースが変化したとして取り扱えばよい。

また、表６に示すように、複数のユーザの利用権限情報に基づき、各ユーザについて予め利用可能な機能を決定して機能利用制限情報として登録しておき、ログイン中のユーザに応じた機能利用制限情報を参照して機能の利用可否を制御するようにしてもよい。
表６には、表２と表５に従って各ユーザの利用可能機能を決定した例を示している。

また、前述した各実施形態では、操作部２０にアプリをインストールする際の動作について説明した。しかし、本体１０にアプリをインストールする場合でも、そのアプリが操作部２０を利用するのであれば、本体１０が本体１０及び操作部２０の利用可能リソースの情報を収集して同様な動作を行うことも可能である。

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

また、操作部と動作部とは、１対１でなくてもよい。例えば、本体に有線接続された操作部がある画像処理装置を、モバイル端末からも操作できるようにすることが考えられる。あるいは、１台の画像処理装置を複数のモバイル端末から操作できるようにすることも考えられる。あるいはまた、１台のモバイル端末から操作対象を切り替えつつ複数の画像処理装置を操作できるようにすることも考えられる。
なお、操作部による操作の対象となる動作部が変更された場合には、変更後の組み合わせによる操作部リソース情報と動作部リソース情報とに基づき、アプリの利用可能機能を再度決定するようにするとよい。

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

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

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

特開２００８−２４２６６０号公報 特開２０１２−８０５７８号公報

この発明は、操作部と動作部とを備えた情報処理システムとそのアプリケーションの利用可能機能決定方法、並びにこのような情報処理システムにおける操作部として機能する情報処理装置、及びコンピュータに情報処理システムを制御させるためのプログラムに関する。

また、特許文献１及び２のいずれに記載の発明も、インストール先の装置が利用する他の装置のリソースについては考慮しておらず、この問題を解決できない。
この発明は、上記の点に鑑みてなされたものであり、指示の入力を受け付ける操作部と、該操作部が受け付けた指示に基づき情報処理動作する動作部とを備える情報処理システムにおいて、操作部にインストールされたアプリケーションが適切に動作しない事態を防止できるようにすることを目的とする。

この発明は、指示の入力を受け付ける操作部と、該操作部が受け付けた指示に基づき情報処理動作する動作部とを備える情報処理システムであって、上記の目的を達成するため、上記操作部で利用可能なリソースを示す操作部リソース情報及び上記動作部で利用可能なリソースを示す動作部リソース情報を取得し、上記操作部にインストールされたアプリケーションが要求するリソースを示す要求リソース情報と、上記操作部リソース情報及び上記動作部リソース情報との比較に基づき、該アプリケーションの利用可能な機能を決定する決定手段を備えるものである。

上記構成によれば、指示の入力を受け付ける操作部と、該操作部が受け付けた指示に基づき情報処理動作する動作部とを備える情報処理システムにおいて、操作部にインストールされたアプリケーションが適切に動作しない事態を防止できるようにすることができる。

この発明の情報処理システムの第１実施形態である画像処理システムの利用環境を示す図である。 図１の画像処理システムのハードウェア構成を示すブロック図である。 図２に示した本体及び操作部のソフトウェア構成を操作部とネットワークの通信に関する機能と共に示す図である。 図２に示した操作部がサーバ装置からアプリケーションをダウンロードしてインストールする際の基本的な動作を説明するための図である。 図２に示した操作部によるアプリケーションのインストール時の処理を示すフローチャートである。 第２実施形態における操作部がダウンロードサーバからアプリケーションをダウンロードしてインストールする際の動作を説明するための図である。 同じく操作部がアプリケーションをインストールした後のリソース変化に伴う利用可能機能の変更処理を示すフローチャートである。 第３実施形態における操作部がサーバ装置からアプリケーションをダウンロードしてインストールする際の動作シーケンスを示す図である。 第４実施形態における操作部がサーバ装置に機能利用制限情報の変更を要求する際の動作シーケンスを示す図である。

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

またＣＰＵ２１は、ステップＳ７へ進むと、選択されたアプリのインストール用ファイルをサーバ装置２からダウンロードする。そして、ステップＳ８でそのファイルの署名データを検証し、問題なければアプリのインストールを実行する。
次に、ＣＰＵ２１はステップＳ９で、ステップＳ１で取得した要求リソース情報と、ステップＳ２で取得した操作部リソース情報と、ステップＳ４で取得した本体リソース情報とに基づき、インストールしたアプリの機能のうち現在利用可能なリソースで利用できないものを特定する。

この第２実施形態は、第１の実施形態のサーバ装置２に対応して、アプリのインストール用ファイルを配布するダウンロードサーバ２ａに加え、アプリの利用許可を行う認証サーバ２ｂを設けたものである。
まず、第２の実施形態において操作部２０がアプリをダウンロードしてインストールする際の基本的な動作について説明する。

第２実施形態では、以上の処理により、操作部２０が、アプリのインストール後も、操作部２０及び本体１０で利用可能なリソースを監視する。そして、リソースの制約のため無効にされていた機能がリソースの増加により利用可能となったことを検出すると、その利用可能となった機能を自動的に有効にすることができる。逆に、有効にされていた機能がリソースの減少により利用不可能となったことを検出すると、その利用不可能となった機能を自動的に無効にすることもできる。これらの機能変更に当たってアクティベーションが必要であれば、それも自動で行うことができる。

操作部２０は、サーバ装置２から決定結果を受信すると、その結果から利用可能機能に現状と比べて変化があったか否か判断する。ここで否であればそのまま処理を終了するが、ここでは変化があったとする（Ｓ３０５）。
この場合、操作部２０は、サーバ装置２に対して利用可能機能の変更を要求する（Ｓ３０６）。サーバ装置２は、この要求を受けると、必要に応じて権限等も考慮して変更の可否を判断する（Ｓ３０７）。
ここでは問題ないものとすると、サーバ装置２は、操作部２０に対して変更許可の応答を返す（Ｓ３０８）。操作部２０は、これを受信すると、自身の機能利用制限情報を更新し（Ｓ３０９）、処理を終了する。

以上の処理によれば、操作部２０が、操作部２０及び本体１０で利用可能なリソースを監視し、利用可能なリソースに変化があった場合に、サーバ装置２に操作部リソース情報及び本体（動作部）リソース情報を送信して、アプリが提供する機能のうち利用できない機能の再決定を要求する。従って、リソースの変化により利用可能な機能が増減した場合に、速やかにこれをアプリの動作に反映させることができる。

Claims (9)

1. 指示の入力を受け付ける操作部と、該操作部が受け付けた指示に基づき情報処理動作する動作部とを備える情報処理システムであって、
   前記操作部にアプリケーションをインストールする場合に、前記操作部で利用可能なリソースを示す操作部リソース情報及び前記動作部で利用可能なリソースを示す動作部リソース情報を取得し、インストールするアプリケーションが要求するリソースを示す要求リソース情報と、前記操作部リソース情報及び前記動作部リソース情報との比較に基づき、該アプリケーションのインストール可否を決定する決定手段を備えることを特徴とする情報処理システム。
2. 請求項１に記載の情報処理システムであって、
   前記要求リソース情報と、前記操作部リソース情報及び前記動作部リソース情報との比較に基づき、インストール時に前記アプリケーションの機能のうち現在の操作部及び動作部のリソースでは利用できない機能を無効にする無効化手段を備えることを特徴とする情報処理システム。
3. 請求項２に記載の情報処理システムであって、
   前記操作部が、前記操作部及び前記動作部の少なくとも一方で利用可能なリソースを監視し、その結果と、インストール済みのアプリケーションの要求リソース情報との比較に基づき、前記インストール済みのアプリケーションの無効にされていた機能を利用するためのリソースが利用可能になったと判断した場合に、該機能を有効にする手段を備えることを特徴とする情報処理システム。
4. 請求項１乃至３に記載の情報処理システムであって、
   ユーザ毎に、該ユーザが利用可能なリソースを設定した利用権限情報を参照する手段を備え、
   前記操作部リソース情報及び／又は前記動作部リソース情報として、ログイン中のユーザに関する前記利用権限情報を用いることを特徴とする情報処理システム。
5. 請求項１に記載の情報処理システムであって、
   さらにサーバ装置を備え、
   前記決定手段は、該サーバ装置に設け、前記操作部から、前記操作部リソース情報及び前記動作部リソース情報を送信された場合に、これを取得して該アプリケーションのインストール可否を決定し、その結果を前記操作部に通知することを特徴とする情報処理システム。
6. 請求項５に記載の情報処理システムであって、
   前記サーバ装置が、前記要求リソース情報と、前記操作部リソース情報及び前記動作部リソース情報との比較に基づき、インストール時に前記アプリケーションの機能のうち現在の操作部及び動作部のリソースでは利用できない機能を無効にすることを決定し、前記操作部に通知する無効化手段を備えることを特徴とする情報処理システム。
7. 請求項６に記載の情報処理システムであって、
   前記操作部が、前記操作部及び前記動作部の少なくとも一方で利用可能なリソースを監視し、利用可能なリソースに変化があった場合に、前記サーバ装置に操作部リソース情報及び動作部リソース情報の少なくとも一方を送信して、前記利用できない機能の再決定を要求する手段を備え、
   前記サーバ装置が、前記操作部から前記再決定を要求された場合に、該要求に係るアプリケーションの要求リソース情報と、受信した前記操作部リソース情報及び前記動作部リソース情報の少なくとも一方とに基づき、インストール済みのアプリケーションの機能のうち現在の操作部及び動作部の少なくとも一方のリソースでは利用できない機能を決定し、その結果を前記操作部に通知する手段を備えることを特徴とする情報処理システム。
8. 指示の入力を受け付ける操作部と、該操作部が受け付けた指示に基づき情報処理動作する動作部とを備える情報処理システムにおける前記操作部として機能する情報処理装置であって、
   当該操作部にアプリケーションをインストールする場合に、当該操作部で利用可能なリソースを示す操作部リソース情報及び前記動作部で利用可能なリソースを示す動作部リソース情報を取得し、インストールするアプリケーションが要求するリソースを示す要求リソース情報と、前記操作部リソース情報及び前記動作部リソース情報との比較に基づき、該アプリケーションのインストール可否を決定する決定手段を備えることを特徴とする情報処理装置。
9. 指示の入力を受け付ける操作部と、該操作部が受け付けた指示に基づき情報処理動作する動作部とを備える情報処理システムを制御するコンピュータに、
   前記操作部にアプリケーションをインストールする場合に、前記操作部で利用可能なリソースを示す操作部リソース情報及び前記動作部で利用可能なリソースを示す動作部リソース情報を取得し、インストールするアプリケーションが要求するリソースを示す要求リソース情報と、前記操作部リソース情報及び前記動作部リソース情報との比較に基づき、該アプリケーションのインストール可否を決定する機能を実現させるためのプログラム。

Images