JP6274328B2 - 情報処理システムとそのアプリケーションの利用可能機能決定方法、並びに情報処理装置及びプログラム - Google Patents
情報処理システムとそのアプリケーションの利用可能機能決定方法、並びに情報処理装置及びプログラム Download PDFInfo
- Publication number
- JP6274328B2 JP6274328B2 JP2017000453A JP2017000453A JP6274328B2 JP 6274328 B2 JP6274328 B2 JP 6274328B2 JP 2017000453 A JP2017000453 A JP 2017000453A JP 2017000453 A JP2017000453 A JP 2017000453A JP 6274328 B2 JP6274328 B2 JP 6274328B2
- Authority
- JP
- Japan
- Prior art keywords
- operation unit
- application
- resource information
- information processing
- information
- Prior art date
- Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
- Active
Links
Images
Landscapes
- Stored Programmes (AREA)
- Facsimiles In General (AREA)
Description
この発明は、操作部と動作部とを備えた情報処理システムとそのアプリケーションの利用可能機能決定方法、並びにこのような情報処理システムにおける操作部として機能する情報処理装置、及びコンピュータに情報処理システムを制御させるためのプログラムに関する。
従来から、複合機(MFP)等の情報処理装置では、操作部と動作部(本体)とを設け、操作部で受け付けたユーザの操作に応じて動作部が各種処理を行ったり、動作部の状態を操作部上に表示させたりすることが行われている。
また、このような情報処理装置では、サーバ装置と通信可能に接続し、サーバ装置からアプリケーションをダウンロード及びインストールして機能を追加する際に、本体の組み合わせやリソースによりアプリケーションのインストール可否を決定することが知られている。
このようなアプリケーション等のプログラムのインストールに関連する技術としては、例えば特許文献1,2に記載のものが知られている。
このようなアプリケーション等のプログラムのインストールに関連する技術としては、例えば特許文献1,2に記載のものが知られている。
特許文献1に記載の管理サーバは、アプリケーションのインストール先である画像形成装置のリソースの不足等でインストールできない場合、掃き出し処理によりリソースを解放してアプリケーションをインストールするようにしている。
特許文献2に記載の画像処理装置では、独立した各ユニットにインストールするプログラムの組み合わせ不一致で対応する機能が無効にならないように、その組み合わせ不一致が発生しないようにプログラムのバージョン変更を行うようにしている。
特許文献2に記載の画像処理装置では、独立した各ユニットにインストールするプログラムの組み合わせ不一致で対応する機能が無効にならないように、その組み合わせ不一致が発生しないようにプログラムのバージョン変更を行うようにしている。
しかしながら、上述したような情報処理システムでは、次のような問題があった。
すなわち、アプリケーションをダウンロードしてインストールする仕組みにおいては、インストール先の装置のリソースをもとにインストール可否を決定している。従って、インストール先の装置が他の装置のリソースを利用してアプリケーションを実行する場合には、当該他の装置が十分にリソースを有しないため、インストールができても対応する機能を利用できない場合があるという問題があった。
すなわち、アプリケーションをダウンロードしてインストールする仕組みにおいては、インストール先の装置のリソースをもとにインストール可否を決定している。従って、インストール先の装置が他の装置のリソースを利用してアプリケーションを実行する場合には、当該他の装置が十分にリソースを有しないため、インストールができても対応する機能を利用できない場合があるという問題があった。
また、特許文献1及び2のいずれに記載の発明も、インストール先の装置が利用する他の装置のリソースについては考慮しておらず、この問題を解決できない。
この発明は、上記の点に鑑みてなされたものであり、指示の入力を受け付ける操作部と、該操作部が受け付けた指示に基づき情報処理動作する動作部とを備える情報処理システムにおいて、操作部にインストールされたアプリケーションが適切に動作しない事態を防止できるようにすることを目的とする。
この発明は、上記の点に鑑みてなされたものであり、指示の入力を受け付ける操作部と、該操作部が受け付けた指示に基づき情報処理動作する動作部とを備える情報処理システムにおいて、操作部にインストールされたアプリケーションが適切に動作しない事態を防止できるようにすることを目的とする。
この発明は、指示の入力を受け付ける操作部と、該操作部が受け付けた指示に基づき情報処理動作する動作部とを備える情報処理システムであって、上記の目的を達成するため、上記操作部で利用可能なリソースを示す操作部リソース情報及び上記動作部で利用可能なリソースを示す動作部リソース情報を取得し、上記操作部にインストールされたアプリケーションが要求するリソースを示す要求リソース情報と、上記操作部リソース情報及び上記動作部リソース情報との比較に基づき、該アプリケーションの利用可能な機能を決定する決定手段を備えるものである。
上記構成によれば、指示の入力を受け付ける操作部と、該操作部が受け付けた指示に基づき情報処理動作する動作部とを備える情報処理システムにおいて、操作部にインストールされたアプリケーションが適切に動作しない事態を防止できるようにすることができる。
以下、この発明を実施するための形態について、図1〜図9を参照して具体的に説明する。
〔第1実施形態〕
図1は、この発明の情報処理システムの第1実施形態である画像処理システムの利用環境を示す図である。
〔第1実施形態〕
図1は、この発明の情報処理システムの第1実施形態である画像処理システムの利用環境を示す図である。
画像処理システム1は、通信機能を有するMFP(複合機:Multifunction Peripheral)であり、例えばプリンタ機能,スキャナ機能,コピー機能,FAX(ファクシミリ)通信機能を備えている。これらの機能に関わる処理は、ユーザが画像処理システム1を直接操作することによって実行することができる。また、図示しないクライアントPC(パーソナルコンピュータ)等の外部装置から受信した指示に従って実行することもできる。
また、画像処理システム1は、機能を追加するためのアプリケーションプログラム等のデータを送信する所定のサーバ装置2と、ネットワーク3を介して通信可能である。
また、画像処理システム1は、機能を追加するためのアプリケーションプログラム等のデータを送信する所定のサーバ装置2と、ネットワーク3を介して通信可能である。
図2は、図1の画像処理システム1のハードウェア構成を示すブロック図である。
この画像処理システム1は、図2に示すように、ユーザから指示の入力を受け付ける操作部20と、操作部20が受け付けた指示に基づき情報処理動作を実行する動作部である本体10とを備え、それらを例えば専用の通信路30により相互に通信可能に接続した構成である。この実施形態では、操作部20として、Android(登録商標)OSを用いて動作する携帯情報端末装置を使用している。また、操作部20の電源は、本体10から供給することができるが、操作部20は不図示の内部バッテリを備え、単独で動作させることもできる。また、本体10から操作部20へ電源を供給するための電源線は、この実施形態では通信路30と共通のものである。
この画像処理システム1は、図2に示すように、ユーザから指示の入力を受け付ける操作部20と、操作部20が受け付けた指示に基づき情報処理動作を実行する動作部である本体10とを備え、それらを例えば専用の通信路30により相互に通信可能に接続した構成である。この実施形態では、操作部20として、Android(登録商標)OSを用いて動作する携帯情報端末装置を使用している。また、操作部20の電源は、本体10から供給することができるが、操作部20は不図示の内部バッテリを備え、単独で動作させることもできる。また、本体10から操作部20へ電源を供給するための電源線は、この実施形態では通信路30と共通のものである。
また、本体10は、操作部20が受け付けた指示に応じた動作だけでなく、上述のように外部装置から受信した指示に応じた動作も行うことができる。また、通信路30は、例えばUSB(Universal Serial Bus)規格のものを用いることができる。しかし、有線、無線を問わず任意の規格のものでよい。1対1通信であっても、ネットワーク通信であってもよい。例えば、USBの他、シリアル、有線または無線LAN(ローカルエリアネットワーク)、ブルートゥース(Bluetooth:登録商標)、IrDA(Infrared Data Association)等を用いることが考えられる。
本体10は、CPU11、ROM12、RAM13、HDD14(ハードディスクドライブ)、通信I/F(インタフェース)15、接続I/F16、及びエンジン部17を備え、それらをシステムバス18により接続した構成としている。そして、CPU11が、RAM13をワークメモリとしてROM12又はHDD14に記憶されたプログラムを実行することにより、本体10全体を制御し、後述する各種機能を実現する。
HDD14は、不揮発性記憶媒体(記憶手段)であり、CPU11が実行する各種プログラムを含む各種データを格納(記憶)している。
通信I/F15は、ネットワーク3を介して外部装置と通信するためのインタフェースである。
接続I/F16は、通信路30を介して操作部20と通信するためのインタフェースである。ここではUSB規格のインタフェースとしている。
通信I/F15は、ネットワーク3を介して外部装置と通信するためのインタフェースである。
接続I/F16は、通信路30を介して操作部20と通信するためのインタフェースである。ここではUSB規格のインタフェースとしている。
なお、通信I/F15は、有線、無線を問わず任意の規格のものを採用可能である。接続I/F16と共通化してもよい。通信I/F15及び接続I/F16としてそれぞれ複数のI/Fを設けてもよい。
エンジン部17は、コピー機能,スキャナ機能,ファクス機能,プリンタ機能を実現させるための、汎用的な情報処理及び通信以外の処理を行うハードウェアである。例えば、原稿の画像をスキャンして読み取るスキャナ(画像読取部)、用紙等のシート材への印刷を行うプロッタ(画像形成部)、ファクス通信を行う通信部などを備えている。更に、印刷済みシート材を仕分けるフィニッシャや、原稿を自動給送するADF(自動原稿給送装置)のような特定のオプションを備えることもできる。
一方、操作部20は、CPU21、ROM22、RAM23、フラッシュメモリ24、通信I/F25、接続I/F26、及び操作パネル27を備え、それらをシステムバス28により接続した構成としている。そして、CPU21が、RAM23をワークメモリとしてROM22又はフラッシュメモリ24に記憶されたプログラムを実行することにより、操作部20全体を制御し、後述するアプリケーションのインストールに関する制御をはじめとする各種機能を実現する。
フラッシュメモリ24は、不揮発性記憶媒体(記憶手段)であり、CPU21が実行する各種プログラムを含む各種データを格納(記憶)している。
通信I/F25は、ネットワーク3を介してサーバ装置2等の外部装置と通信するためのインタフェースである。
通信I/F25は、ネットワーク3を介してサーバ装置2等の外部装置と通信するためのインタフェースである。
接続I/F26は、通信路30を介して本体10と通信するためのインタフェースである。ここではUSB規格のインタフェースとしている。
なお、通信I/F25は、有線、無線を問わず任意の規格のものを採用可能である。接続I/F26と共通化してもよい。通信I/F25及び接続I/F26としてそれぞれ複数のI/Fを設けてもよい。
なお、通信I/F25は、有線、無線を問わず任意の規格のものを採用可能である。接続I/F26と共通化してもよい。通信I/F25及び接続I/F26としてそれぞれ複数のI/Fを設けてもよい。
操作パネル27は、ユーザからの各種動作の実行や設定等の指示操作を受け付ける操作部と、画像処理システム1の動作状況や設定状態を表示する表示部とを備える操作表示手段である。この操作パネルは、例えばタッチパネルを積層した液晶表示装置(LCD)により構成することができる。さらに、これに加えて又はこれに代えて、ハードウェアキー等の操作部やランプ等の表示部を設けることもできる。
なお、図1のサーバ装置2は、ハードウェアとしては、CPU、ROM、RAM、通信I/F等を備えた公知のコンピュータでよい。
なお、図1のサーバ装置2は、ハードウェアとしては、CPU、ROM、RAM、通信I/F等を備えた公知のコンピュータでよい。
図3は、図2に示した本体10及び操作部20のソフトウェア構成を操作部20とネットワーク3の通信に関する機能と共に示す図である。
図3に示すように、本体10は、アプリケーション(以下「アプリ」ともいう)層101と、サービス層102と、オペレーティングシステム(以下「OS」という)層103とを含むソフトウェア群を備える。
図3に示すように、本体10は、アプリケーション(以下「アプリ」ともいう)層101と、サービス層102と、オペレーティングシステム(以下「OS」という)層103とを含むソフトウェア群を備える。
アプリ層101のソフトウェアは、ハードウェア資源を動作させて所定の機能を提供するためのソフトウェアである。例えば、コピーアプリ,スキャナアプリ,ファクスアプリ,プリンタアプリ等を備え、それらによってコピー機能,スキャナ機能,ファクス機能,プリンタ機能等の各種機能を提供することができる。
サービス層102のソフトウェアは、アプリ層101とOS層103との間に介在し、アプリ層101のソフトウェアに対し、本体10が備えるハードウェア資源を利用するためのインタフェースを提供する。より具体的には、ハードウェア資源に対する動作要求の受付及びその動作要求の調停を行う機能を備える。サービス層102が受け付ける動作要求には、スキャナによる読み取りやプロッタによる印刷等の要求が考えられる。
なお、このインタフェースの機能は、本体10のアプリ層101だけではなく、操作部20のアプリ層201に対しても提供する。すなわち、操作部20のアプリ層201にあるアプリも、サービス層102にアクセスすることにより、本体10のハードウェア資源(例えばエンジン部17)を利用して各種機能を実現することができる。
OS層103は、基本ソフトウェアであり、本体10が備えるハードウェアを制御する基本機能を提供する。サービス層102のソフトウェアは、各種アプリからのハードウェア資源の利用要求を、OS層103が解釈可能なコマンドに変換してOS層103に渡す。そして、OS層103のソフトウェアがそのコマンドを実行することにより、ハードウェア資源にアプリの要求に従った動作を行わせる。
操作部20が備えるアプリ層201、サービス層202及びOS層203も、階層構造については本体10側と同様である。アプリ層201のアプリが提供する具体的な機能や、サービス層202が受け付け可能な動作要求の種類は、本体10側とは異なる。操作部20が備えるアプリは、操作部20が備えるハードウェア資源を動作させて所定の機能を提供することもできるが、主として本体10が備える機能に関する操作や表示を行うためのUI(ユーザインタフェース)の機能を提供する。
図3に示す3aはLAN、3bは無線LAN・APである。
図3に示す3aはLAN、3bは無線LAN・APである。
なお、本体10側と操作部20側とで、OSは独立して動作するものとする。また、本体10と操作部20とが相互に通信可能であれば、OSが同じ種類である必要はない。例えば、本体ではLinux(登録商標)を用い、操作部20ではAndroid(登録商標)を用いることも可能である。
この画像処理システム1において、本体10と操作部20とは異なるOSにより制御されるため、本体10と操作部20との間の通信は、1装置内のプロセス間通信ではなく、異なる装置間の通信として行う。
操作部20が受け付けたユーザからの指示内容を本体10へ伝達する動作(コマンド通信)や、操作部20に表示させる情報を本体10から操作部20へ伝達する動作がこれに該当する。
操作部20が受け付けたユーザからの指示内容を本体10へ伝達する動作(コマンド通信)や、操作部20に表示させる情報を本体10から操作部20へ伝達する動作がこれに該当する。
この実施形態の一つの特徴は、画像処理システム1が行う以下の動作である。つまり、操作部20にアプリケーションをインストールする場合に、インストール先の操作部20で利用可能なリソースを示す操作部リソース情報及び本体10で利用可能なリソースを示す本体(動作部)リソース情報を取得する。そして、インストールするアプリケーションが要求するリソースを示す要求リソース情報と、上記操作部リソース情報及び上記動作部リソース情報との比較に基づき、そのアプリケーションのインストール可否を決定する。以下、この動作を含む各動作について説明する。
まず、操作部20がサーバ装置2からアプリをダウンロードしてインストールする際の基本的な動作について説明する。なお、説明の便宜のため、後述するリソース情報のチェックに関する説明はここでは省略する。
図4は、その動作に供する説明図である。
図4は、その動作に供する説明図である。
操作部20は、図4に示すように、図1のサーバ装置2とネットワーク3を介して通信可能である。
この操作部20は、ユーザからダウンロードしたいアプリの選択及びそのアプリのダウンロード指示を受け付けた場合に、そのアプリのダウンロードをサーバ装置2に要求する。
この操作部20は、ユーザからダウンロードしたいアプリの選択及びそのアプリのダウンロード指示を受け付けた場合に、そのアプリのダウンロードをサーバ装置2に要求する。
サーバ装置2は、各種アプリのインストール用ファイルを管理するものであり、その各ファイルを記憶保持している。各アプリのインストール用ファイルはそれぞれ、アプリのプログラムを含む本体ファイルであるapkファイル(android application package file)と、apkファイルに付した電子署名である署名データとを含む。
サーバ装置2は、操作部20からダウンロード要求(依頼)を受けると、要求されたアプリのインストール用ファイルを読み出して操作部20へ返信する。
操作部20は、ダウンロード要求に応じて送信されてくるインストール用ファイルダウンロード(受信)した後、それに含まれている署名データをチェックして、ダウンロードしたアプリケーションをインストールしてよいか否か判断する。ここでは、署名が適正であれば、適正な供給元から供給されたプログラムであり、インストールしても害はないと認識し、インストール可と判断する。
操作部20は、ダウンロード要求に応じて送信されてくるインストール用ファイルダウンロード(受信)した後、それに含まれている署名データをチェックして、ダウンロードしたアプリケーションをインストールしてよいか否か判断する。ここでは、署名が適正であれば、適正な供給元から供給されたプログラムであり、インストールしても害はないと認識し、インストール可と判断する。
なお、アプリケーションのインストール可と決定した場合にも、本体10の機能の利用を制限することが可能である。この機能の利用制限として、アプリケーションをインストールしても本体10の機能を全く利用可能(有効)にしない、一部の機能のみを利用可能にするなどがあり得る。
次に、図2に示した操作部20のCPU21によるアプリインストール時の処理について説明する。
図5は、その処理を示すフローチャートである。この処理は、リソース情報のチェックに関する処理を含むものである。
操作部20のCPU21は、ダウンロードしたいアプリの選択及びそのアプリのダウンロード指示を受け付けた場合に、図5に示す処理を開始する。アプリの選択及びダウンロード指示は、ユーザが操作パネル27を操作して行ってもよいし、予め設定された所定条件を満たした場合(設定時刻に達した場合など)に自動的に行われるようにしてもよい。
図5は、その処理を示すフローチャートである。この処理は、リソース情報のチェックに関する処理を含むものである。
操作部20のCPU21は、ダウンロードしたいアプリの選択及びそのアプリのダウンロード指示を受け付けた場合に、図5に示す処理を開始する。アプリの選択及びダウンロード指示は、ユーザが操作パネル27を操作して行ってもよいし、予め設定された所定条件を満たした場合(設定時刻に達した場合など)に自動的に行われるようにしてもよい。
この処理において、CPU21はまずステップS1で、サーバ装置2に要求して選択されたアプリの要求リソース情報を取得(ダウンロード)する。この要求リソース情報は、アプリをインストールしてその機能を発揮するために要求されるハードウェアリソースを示す情報である。その例は、例えば表1に示すものである。
表1に示す通り、要求リソース情報は、そのアプリのインストール先である操作部20側に要求されるリソースと、その操作部20がアプリの機能を発揮させるに当たって利用する装置である本体10側に要求されるリソースとをそれぞれ示すものである。
また、表1に示すように、アプリが提供する機能のうち、一定の範囲毎に、その機能を利用するために必要なハードウェアリソースを示すようにしてもよい。表1の例は、利用可能機能範囲の欄に記載した機能を利用するために、その右側2列に示すハードウェアリソースが、操作部20側と本体10側にそれぞれ必要であることを示す。「インストールのみ」は、インストール自体に必要なリソースであり、これが確保できない場合には、インストール自体実行できない。
また、表1に示すように、アプリが提供する機能のうち、一定の範囲毎に、その機能を利用するために必要なハードウェアリソースを示すようにしてもよい。表1の例は、利用可能機能範囲の欄に記載した機能を利用するために、その右側2列に示すハードウェアリソースが、操作部20側と本体10側にそれぞれ必要であることを示す。「インストールのみ」は、インストール自体に必要なリソースであり、これが確保できない場合には、インストール自体実行できない。
なお、要求リソース情報に示されるハードウェアリソースの種類は、表1ではストレージの容量、ワークメモリの容量及びCPUパワーである。しかし、これ以外にも、プリントエンジンやスキャナエンジンのカラー/モノクロ及び対応解像度、両面ユニットや後処理(ステープル、パンチ、製本など)ユニットの有無、ディスプレイの解像度などを記載することも考えられる。
以上のような要求リソース情報は、アプリのベンダーが作成して、アプリを提供するサーバ装置2に設定しておくものである。
以上のような要求リソース情報は、アプリのベンダーが作成して、アプリを提供するサーバ装置2に設定しておくものである。
図5の説明に戻ると、CPU21は、ステップS1の後ステップS2で、アプリのインストール先である操作部20で利用可能なリソースを示す操作部リソース情報を取得する。この取得は、ステップS1で取得した要求リソース情報との対比に必要な範囲で行えばよい。また、比較に当たって、操作部20が当該リソースを備えているか否かを示す情報が必要な場合(ディスプレイの解像度など)と、当該リソースに残量があるか否かを示す情報が必要な場合(ストレージの容量など)があるので、この点にも注意する。以下のステップS4でも同様である。
CPU21は次に、ステップS3へ進み、ステップS1で取得した要求リソース情報とステップS2で取得した操作部リソース情報とを比較して、操作部20において、アプリのインストールに最低限必要なリソースを利用可能か否か判断する。
そして、その判断がYESの場合、CPU21は、ステップS4へ進み、操作部20がアプリを実行する際に利用する本体10において利用可能なリソースを示す本体リソース情報を、本体10に要求して取得する。なお、本体10が、本体10側アプリの利用に供するリソースと、操作部20を含む外部装置のアプリの利用に供するリソースとを分けて管理している場合には、後者の中で利用可能なリソースを示す情報を取得する。
CPU21は次に、ステップS5へ進み、ステップS1で取得した要求リソース情報とステップS4で取得した本体リソース情報とを比較して、本体10において、アプリのインストールに最低限必要なリソースを利用可能か否か判断する。
そして、その判断がYESの場合、CPU21は、ステップS6において、選択されたアプリはインストール可と決定してステップS7へ進む。
そして、その判断がYESの場合、CPU21は、ステップS6において、選択されたアプリはインストール可と決定してステップS7へ進む。
ステップS3又はS5の判断がNOの場合、CPU21は、ステップS11において、選択されたアプリはインストール否と決定してステップS12へ進み、インストール処理を中断し、図5の処理を終了する。
以上のステップS3、S5、S6及びS11において、CPU21は決定手段として機能する。
以上のステップS3、S5、S6及びS11において、CPU21は決定手段として機能する。
またCPU21は、ステップS7へ進むと、選択されたアプリのインストール用ファイルをサーバ装置2からダウンロードする。そして、ステップS8でそのファイルの署名データを検証し、問題なければアプリのインストールを実行する。
次に、CPU21はステップS9で、ステップS1で取得した要求リソース情報と、ステップS2で取得した操作部リソース情報と、ステップS4で取得した本体リソース情報とに基づき、インストールしたアプリの機能のうち現在利用可能なリソースで利用できないものを特定する。
次に、CPU21はステップS9で、ステップS1で取得した要求リソース情報と、ステップS2で取得した操作部リソース情報と、ステップS4で取得した本体リソース情報とに基づき、インストールしたアプリの機能のうち現在利用可能なリソースで利用できないものを特定する。
そして、ステップS10で、その特定した機能を無効化することを示す機能利用制限情報を登録し、図5の処理を終了する。このステップS9及びS10において、CPU21は無効化手段として機能する。
以後、CPU21がそのアプリを実行する場合、機能利用制限情報を参照し、無効化した機能に関する動作は行わないようにする。機能利用制限情報を参照する機能は、OSに設けても、アプリに設けてもよい。
以後、CPU21がそのアプリを実行する場合、機能利用制限情報を参照し、無効化した機能に関する動作は行わないようにする。機能利用制限情報を参照する機能は、OSに設けても、アプリに設けてもよい。
以上の第1実施形態では、操作部20が、自己にアプリをインストールする場合に、インストール先の操作部20で利用可能なリソースを示す操作部リソース情報及び本体(動作部)10で利用可能なリソースを示す本体リソース情報を取得する。そして、インストールするアプリが要求するリソースを示す要求リソース情報と、取得した操作部リソース情報及び本体リソース情報との比較に基づき、そのアプリのインストール可否を決定する。
したがって、インストール可の場合のみインストールを行うようにすることにより、リソース不足によりインストールが失敗する事態を防止することができる。
また、図5の処理ではインストール可否の判断基準をインストール自体が可能であるか否かに置いたが、アプリの一定範囲の機能(あるいは全ての機能)を利用可能であるか否かに置くこともできる。この基準を用いれば、アプリをインストールしたがそのアプリが動作しない、という事態を防止することができる。
また、図5の処理ではインストール可否の判断基準をインストール自体が可能であるか否かに置いたが、アプリの一定範囲の機能(あるいは全ての機能)を利用可能であるか否かに置くこともできる。この基準を用いれば、アプリをインストールしたがそのアプリが動作しない、という事態を防止することができる。
また、第1実施形態では、操作部20が、上記要求リソース情報と、操作部リソース情報及び本体リソース情報との比較に基づき、ダウンロードしたアプリの機能のうち現在の操作部20及び本体10のリソースでは利用できない機能を無効にするようにしている。従って、インストールしたアプリを実行する際に、リソース不足によりシステムがハングアップするような不具合を防止することができる。
なお、要求リソース情報に、ネットワークリソースを記載することもできる。操作部20側のアプリが本体10と外部装置との間で通信をするためのネットワーク3で大きな帯域を占有してしまうと、本体10側のアプリと外部装置との間の通信に影響が出る恐れがある。これを防止するため、予め操作部20のアプリケーションが利用できる帯域を登録しておくとよい。この登録は本体10側で行うことが望ましい。従って、ネットワークリソースは、厳密には本体10側のリソースとも操作部20側のリソースとも言い難いが、本体10側のリソースに含まれると考えることができる。
そして、表2に、ネットワーク中で利用可能な通信帯域幅に応じて、アプリ中で利用可能な通信機能を制限することを示す要求リソース情報の例を示す。表2の情報は例えば、1Mbps(メガビット毎秒)の帯域が利用可能であればメール送信とブラウザが利用可能であり、10Mbpsの帯域が利用可能であればこれに加えて画像送信が利用可能であることを示す。
〔第2実施形態〕
次に、この発明の情報処理システムの第2実施形態について説明する。なお、第2の実施形態も、各装置の具体的な動作は一部異なるものの、ハードウェア構成及びソフトウェア構成は第1実施形態と同様であるため、図1〜図3のうちの必要な図を参照する。これは、第3実施形態以降も同様とする。
次に、この発明の情報処理システムの第2実施形態について説明する。なお、第2の実施形態も、各装置の具体的な動作は一部異なるものの、ハードウェア構成及びソフトウェア構成は第1実施形態と同様であるため、図1〜図3のうちの必要な図を参照する。これは、第3実施形態以降も同様とする。
この第2実施形態は、第1の実施形態のサーバ装置2に対応して、アプリのインストール用ファイルを配布するダウンロードサーバ2aに加え、アプリの利用許可を行う認証サーバ2bを設けたものである。
まず、第2の実施形態において操作部20がアプリをダウンロードしてインストールする際の基本的な動作について説明する。
まず、第2の実施形態において操作部20がアプリをダウンロードしてインストールする際の基本的な動作について説明する。
図6は、その動作に供する説明図であり、図4と同じ部分には同一符号を付している。
第2の実施形態では、操作部20は、図6に示すように、ダウンロードサーバ2a及び認証サーバ(アクティベーションサーバ)2bとネットワーク3を介して通信可能である。なお、ダウンロードサーバ2a及び認証サーバ2bを一体に構成することは妨げられない。
第2の実施形態では、操作部20は、図6に示すように、ダウンロードサーバ2a及び認証サーバ(アクティベーションサーバ)2bとネットワーク3を介して通信可能である。なお、ダウンロードサーバ2a及び認証サーバ2bを一体に構成することは妨げられない。
この操作部20は、アプリの選択及びダウンロード指示を受け付けた場合に、ダウンロードサーバ2aに選択されたアプリのインストール用ファイルのダウンロードを要求して、そのファイルをダウンロードする(1)。
その後、操作部20は、ダウンロードしたファイル中の署名データをチェックして、ダウンロードしたアプリをインストールしてよいか否か判断する(2)。
インストールしてよいと判断した場合には、第1実施形態の場合と同様な手順で、認証サーバ2bにアクセスすることなく、アプリのインストールを行う(4)。
その後、操作部20は、ダウンロードしたファイル中の署名データをチェックして、ダウンロードしたアプリをインストールしてよいか否か判断する(2)。
インストールしてよいと判断した場合には、第1実施形態の場合と同様な手順で、認証サーバ2bにアクセスすることなく、アプリのインストールを行う(4)。
一方、署名データがないか、あっても正しいものでない場合(有効期限切れ等)、操作部20は、認証サーバ2bにアクセスしてアクティベーションを実行する(3)。
この処理においては、操作部20は、第1の実施形態の場合と同様に、上記要求リソース情報と、操作部リソース情報及び本体リソース情報との比較に基づき、アプリの機能のうち利用可能な機能を特定する。
この処理においては、操作部20は、第1の実施形態の場合と同様に、上記要求リソース情報と、操作部リソース情報及び本体リソース情報との比較に基づき、アプリの機能のうち利用可能な機能を特定する。
また、ユーザからアプリのアクティベーションコードの入力を受け付ける。このアクティベーションコードは、ユーザがアプリを利用する権限があることを示すコードであり、ユーザ登録や料金の支払いと引き替えにアプリのベンダーが提供することが考えられる。また、アクティベーションコード毎に、利用できる機能の種類を制限することもできる。コード自体に利用可能な機能の情報を埋め込んでもよいし、認証サーバ2bが、各コードとそのコードで利用可能な機能との対応関係を権限情報として管理してもよい。
そして、操作部20は、アプリの識別情報(アプリのファイル自体でもよい)と共に、利用したい機能の情報(上記特定した利用可能な機能の情報でよい)と、入力されたアクティベーションコードとを認証サーバ2bに送信し、アプリの利用許可(アクティベーション)を要求する。
認証サーバ2bでは、受信した情報と、自身が管理するアクティベーションコード毎の権限情報に基づき、アクティベーションコードの持ち主に、要求されたアプリについて要求された機能の利用を許可してよいか否か判断する。そして、その結果を操作部20に返す。
認証サーバ2bでは、受信した情報と、自身が管理するアクティベーションコード毎の権限情報に基づき、アクティベーションコードの持ち主に、要求されたアプリについて要求された機能の利用を許可してよいか否か判断する。そして、その結果を操作部20に返す。
操作部20は、認証サーバ2bに利用が許可された場合、第1の実施形態の場合と同様にアプリをインストールし(4)、利用が許可された機能以外を無効化することを示す機能利用制限情報を登録する。このとき、アクティベーションに用いたアクティベーションコードは記憶しておく。
一方、利用が許可されなかった場合、インストールを中止する。なお、各種リソース情報に基づき特定した利用可能な機能の中から、実際に利用する機能の範囲を絞って再度アクティベーションを試みることができるようにしてもよい。
一方、利用が許可されなかった場合、インストールを中止する。なお、各種リソース情報に基づき特定した利用可能な機能の中から、実際に利用する機能の範囲を絞って再度アクティベーションを試みることができるようにしてもよい。
以上の手順により、認証サーバ2bによりアクティベーションを利用する場合でも第1の実施形態の場合と同様な、インストール可否の判断及び機能の制限を行うことができる。ただし、第2の実施形態の場合、アクティベーションコードにより得られるアプリの利用権限によっては、必要なハードウェアリソースがあってもアプリをインストールできなかったり機能を利用できなかったりする場合もある。
なお、図6の説明においては、適当な署名データがない場合にアクティベーションを行うとして説明したが、適当な署名データがある場合でもアクティベーションを行うようにしてもよい。
なお、図6の説明においては、適当な署名データがない場合にアクティベーションを行うとして説明したが、適当な署名データがある場合でもアクティベーションを行うようにしてもよい。
次に、操作部20へのアプリインストール後のリソース変化に伴う利用可能機能の変更処理について説明する。
図7は、その処理を示すフローチャートである。
操作部20のCPU21は、図6を用いて説明したようにアプリをインストールした後、定期的に図7に示す処理を開始する。
図7は、その処理を示すフローチャートである。
操作部20のCPU21は、図6を用いて説明したようにアプリをインストールした後、定期的に図7に示す処理を開始する。
そして、まずステップS21において、要求リソース情報、操作部リソース情報及び本体リソース情報を取得する。これらのうち操作部リソース情報及び本体リソース情報は、図5のステップS2及びS4で取得する情報と同じものであるが、この処理時点の情報を取得する。要求リソース情報は、図5のステップS1で取得した情報と同じものである。その都度ダウンロードサーバ2a(サーバ装置2)にアクセスして取得してもよいが、アプリのインストール時に操作部20に記憶させておき、これを取得するとよい。
CPU21は、次のステップS22で、取得した要求リソース情報、操作部リソース情報及び本体リソース情報に基づいて、アプリの機能のうち現在利用可能なハードウェアリソースで利用可能な機能を特定する。そして、利用可能な機能が前回処理時から変化しているか否か判断する。この判断手法は、第1の実施形態で説明したものと同様である。
メモリやハードディスクを増設したり、他のアプリをアンインストールしていたりすれば、利用可能なリソースが増加し、これにより利用可能な機能が増えることが考えられる。逆に、他の優先度が高い用途にリソースを確保されたり、ハードウェアの取り外しや故障等があったりして、利用可能なリソースが減少し、これにより利用可能な機能が減ることも考えられる。
いずれにせよ、利用可能な機能に変化があった場合、ステップS23に進み、CPUは、変化後の機能を利用するためにアクティベーションが必要か否か判断する。例えば、アプリのインストール時にアクティベーションを行っており、かつ利用可能な機能が増える場合は、その増えた機能の利用権限の有無を確認するため、アクティべーションが必要であると考えられる。逆に、アプリのインストール時に署名の確認のみでアクティベーションを行っていなかったり、利用可能な機能が減少したりした場合には、変化後の状態で利用が可能であることを改めて確認する必要はないと考えられる。
そして、CPU21は、ステップS23でアクティベーションが必要と判断した場合、ステップS24で、変化後の利用可能機能について、図6の(3)の場合と同様に、認証サーバ2bに利用許可を求める。ただし、アクティベーションコードは、アプリのインストール時に記憶しておいたものを用いる。
ステップS25で利用許可の有無を判断し、許可されていれば、ステップS26で、ステップS22で特定した変化後の利用可能機能に基づき機能利用制限情報を変更し、処理を終了する。
このことにより、以後は、処理時点での利用可能リソースに応じた機能を利用できるようになる。
ステップS25で利用許可の有無を判断し、許可されていれば、ステップS26で、ステップS22で特定した変化後の利用可能機能に基づき機能利用制限情報を変更し、処理を終了する。
このことにより、以後は、処理時点での利用可能リソースに応じた機能を利用できるようになる。
一方、ステップS25でNOの場合には、変化後の利用可能機能について利用権限の確認が取れないため、機能利用制限情報を変更せずに処理を終了する。この場合、処理以前から利用可能であった機能のみ利用可能である。
なお、この場合、実際に利用可能である機能と、リソース情報に基づき利用可能と判断される機能とが異なることになる。ステップS22での変化有無の判断には、実際に利用可能である機能を基準とするとよい。ただし、利用が拒否された機能を記憶しておき、アクティベーションコードの変更がない限り、同じ機能については許可の見込みがないため利用許可の要求をしないようにするとよい。
なお、この場合、実際に利用可能である機能と、リソース情報に基づき利用可能と判断される機能とが異なることになる。ステップS22での変化有無の判断には、実際に利用可能である機能を基準とするとよい。ただし、利用が拒否された機能を記憶しておき、アクティベーションコードの変更がない限り、同じ機能については許可の見込みがないため利用許可の要求をしないようにするとよい。
また、ステップS23でNOの場合には、変化後の利用可能機能を実際に利用できるようにすることに障害はないと考えられるため、そのままステップS26に進んで機能利用制限情報を更新する。
また、ステップS22でNOの場合には、以後の処理を行う必要がないため、そのまま処理を終了する。
また、ステップS22でNOの場合には、以後の処理を行う必要がないため、そのまま処理を終了する。
第2実施形態では、以上の処理により、操作部20が、アプリのインストール後も、操作部20及び本体10で利用可能なリソースを監視する。そして、リソースの制約のため無効にされていた機能がリソースの増加により利用可能となったことを検出すると、その利用可能となった機能を自動的に有効にすることができる。逆に、有効にされていた機能がリソースの減少により利用不可能となったことを検出すると、その利用不可能となった機能を自動的に無効にすることもできる。これらの機能変更に当たってアクティベーションが必要であれば、それも自動で行うことができる。
従って、インストール後のアプリにつき、利用可能なハードウェアリソースの変化に応じて利用可能な機能を調整し、可能な範囲で最大限の機能が利用できるような設定を自動で行うことができる。よって、インストールしたアプリの利用効率が向上する。
なお、リソースの監視は、操作部20及び本体10の一方のみで行ってもよい。このようにしても、その監視対象の箇所におけるリソース変化によって利用可能となった機能を自動的に有効にすることができる。
なお、リソースの監視は、操作部20及び本体10の一方のみで行ってもよい。このようにしても、その監視対象の箇所におけるリソース変化によって利用可能となった機能を自動的に有効にすることができる。
〔第3実施形態〕
次に、この発明の情報処理システムの第3実施形態について説明する。
この第3実施形態は、上述した第1実施形態と若干異なるだけなので、その部分についてのみ説明する。
次に、この発明の情報処理システムの第3実施形態について説明する。
この第3実施形態は、上述した第1実施形態と若干異なるだけなので、その部分についてのみ説明する。
この第3実施形態では、操作部20が、選択されたアプリをサーバ装置2からダウンロードしてインストールする際に、取得した操作部リソース情報及び本体リソース情報をサーバ装置2へ送信する。
サーバ装置2は、操作部20から、操作部リソース情報及び本体リソース情報を送信された場合に、これらと、アプリに関する要求リソース情報とを比較してアプリのインストール可否を決定し、その結果を操作部20に通知する。
サーバ装置2は、操作部20から、操作部リソース情報及び本体リソース情報を送信された場合に、これらと、アプリに関する要求リソース情報とを比較してアプリのインストール可否を決定し、その結果を操作部20に通知する。
この具体的処理について、図8を用いて説明する。
図8は、操作部20がサーバ装置2からアプリをダウンロードしてインストールする際の動作シーケンスを示す図である。
図8は、操作部20がサーバ装置2からアプリをダウンロードしてインストールする際の動作シーケンスを示す図である。
操作部20(のCPU21)は、ユーザによってインストールしたいアプリの選択及びダウンロード指示を受け付けると、図8に示すように、操作部リソース情報及び本体リソース情報を取得する(S201)。取得方法は第1の実施形態の場合と同様でよいが、どの範囲の情報が必要であるかは、予め設定しておくか、あるいはサーバ装置2に問い合わせる。
次に、操作部20は、それらのリソース情報と選択されたアプリの識別情報(アプリ情報)とをサーバ装置2へ送信する(S202)。ここで送信する操作部リソース情報及び本体リソース情報の一例を、表3に示す。
次に、操作部20は、それらのリソース情報と選択されたアプリの識別情報(アプリ情報)とをサーバ装置2へ送信する(S202)。ここで送信する操作部リソース情報及び本体リソース情報の一例を、表3に示す。
サーバ装置2は、操作部20からこれらの情報を受信すると、アプリ情報と対応する要求リソース情報と、受信した操作部リソース情報及び本体リソース情報とを比較して、アプリのインストール可否及び、インストールした場合に利用可能な機能を決定する(S203)。そして、その結果を操作部20に送信する(S204)。この機能が、決定手段としての機能に相当する。
操作部20は、サーバ装置から決定結果を受信すると、まずその結果からインストール可否を判断する。ここでインストール否であればユーザにその旨を通知して処理を終了するが、ここではインストール可であるとする(S205)。
この場合、操作部20は、サーバ装置2に対してアプリのインストール用ファイルのダウンロードを要求する(S206)。サーバ装置2はこの要求に応じて操作部20へインストール用ファイルを送信する(S207)。
これを受信した操作部20は、受信したファイルを用いてインストールを実行する(S208)と共に、ステップS204で受信した決定結果に基づき、機能利用制限情報を登録して(S209)、処理を終了する。
この場合、操作部20は、サーバ装置2に対してアプリのインストール用ファイルのダウンロードを要求する(S206)。サーバ装置2はこの要求に応じて操作部20へインストール用ファイルを送信する(S207)。
これを受信した操作部20は、受信したファイルを用いてインストールを実行する(S208)と共に、ステップS204で受信した決定結果に基づき、機能利用制限情報を登録して(S209)、処理を終了する。
以上の処理によっても、第1の実施形態の場合と同様、要求リソース情報と、操作部20が取得した操作部リソース情報及び本体リソース情報との比較に基づき、アプリのインストール可否を決定することができる。また、利用可能な機能も決定することができる。また、サーバ装置2がインストール可否及び利用可能機能の決定に係る処理を担うので、その分だけ第1の実施形態の場合より操作部20側の処理負担が減る。
なお、サーバ装置2は、ステップS203においてインストールは可能だが利用できない機能があると決定した場合、その結果を操作部20に通知することに代えて、次のようにすることもできる。
すなわち、まずインストール可能であることのみ操作部20に通知する。その後、操作部20から選択されたアプリのダウンロード要求を受けた場合に、そのアプリのインストール用ファイルとして、上記決定に基づき、利用可能な機能のみ有効にした状態のプログラムを含むインストール用ファイルを生成して、操作部20に送信する。
このようにすれば、操作部20側で機能利用制限情報を登録したり、機能利用制限情報に基づいて機能の制限をしたりしなくても、アプリが提供する機能のうち操作部及び動作部のリソースでは利用できない機能を無効にすることができる。この場合、サーバ装置2が無効化手段として機能する。
すなわち、まずインストール可能であることのみ操作部20に通知する。その後、操作部20から選択されたアプリのダウンロード要求を受けた場合に、そのアプリのインストール用ファイルとして、上記決定に基づき、利用可能な機能のみ有効にした状態のプログラムを含むインストール用ファイルを生成して、操作部20に送信する。
このようにすれば、操作部20側で機能利用制限情報を登録したり、機能利用制限情報に基づいて機能の制限をしたりしなくても、アプリが提供する機能のうち操作部及び動作部のリソースでは利用できない機能を無効にすることができる。この場合、サーバ装置2が無効化手段として機能する。
あるいは、サーバ装置2は、ステップS204で決定結果を通知することに代えて、サーバ装置2側で機能利用制限情報を作成して操作部20に送信し、これを登録させるようにしてもよい。この場合も、サーバ装置2が無効化手段として機能する。
なお、以上のようにサーバ装置2において集中的にダウンロード可否や利用可能機能の決定を行う場合、アプリのインストール先のシステム毎に、通知された空きリソースの情報と、それに応じて決定した利用可能機能とを対応付けて記憶させておくとよい。この例を表4に示す。
〔第4実施形態〕
次に、この発明の情報処理システムの第4実施形態について説明する。
この第4実施形態では、画像処理システム1が上述した第3実施形態と同様の動作に加え、以下に示す機能利用制限情報の変更に係る動作も行う。
図9は、その動作シーケンスを示す図である。
次に、この発明の情報処理システムの第4実施形態について説明する。
この第4実施形態では、画像処理システム1が上述した第3実施形態と同様の動作に加え、以下に示す機能利用制限情報の変更に係る動作も行う。
図9は、その動作シーケンスを示す図である。
操作部20は、随時操作部20及び本体10の利用可能リソースを監視しており、これが変化したことを検出すると(S301)、図9に示すように、サーバ装置2に対して利用可能機能に変化がないか確認を求める。すなわち、インストールされているアプリを示すアプリ情報と、操作部リソース情報及び本体リソース情報を、サーバ装置2に送信する(S302)。複数のアプリがインストールされている場合、複数のアプリ情報を送信すればよい。
サーバ装置2は、これらの情報を確認すると、アプリ情報と対応する要求リソース情報と、受信した操作部リソース情報及び本体リソース情報に基づき、利用可能な機能を決定する(S303)。そして、その結果を操作部20に送信する(S304)。
サーバ装置2は、これらの情報を確認すると、アプリ情報と対応する要求リソース情報と、受信した操作部リソース情報及び本体リソース情報に基づき、利用可能な機能を決定する(S303)。そして、その結果を操作部20に送信する(S304)。
操作部20は、サーバ装置2から決定結果を受信すると、その結果から利用可能機能に現状と比べて変化があったか否か判断する。ここで否であればそのまま処理を終了するが、ここでは変化があったとする(S305)。
この場合、操作部20は、サーバ装置2に対して利用可能機能の変更を要求する(S306)。サーバ装置2は、この要求を受けると、必要に応じて権限等も考慮して変更の可否を判断する(S307)。
ここでは問題ないものとすると、サーバ装置2は、操作部20に対して変更許可の応答を返す(S308)。操作部20は、これを受信すると、自身の機能利用制限情報を更新し(S309)、処理を終了する。
この場合、操作部20は、サーバ装置2に対して利用可能機能の変更を要求する(S306)。サーバ装置2は、この要求を受けると、必要に応じて権限等も考慮して変更の可否を判断する(S307)。
ここでは問題ないものとすると、サーバ装置2は、操作部20に対して変更許可の応答を返す(S308)。操作部20は、これを受信すると、自身の機能利用制限情報を更新し(S309)、処理を終了する。
以上の後、操作部20においては、アプリが提供する機能のうち、変更後の機能利用制限情報に従った機能が利用可能となる。ここで複数のアプリについて利用可能機能が変更されることもある。また、この変更により、利用可能機能が増える場合も減る場合もある。
なお、ステップS301において、監視すべきリソース情報に、頻繁に値が変わる項目(例えばストレージの空き容量など)があると、サーバ装置2へのアクセス頻度が多くなってしまう。そこで、このような場合には一定閾値以上の変化があった場合に値が変化したものと取り扱うとよい。
なお、ステップS301において、監視すべきリソース情報に、頻繁に値が変わる項目(例えばストレージの空き容量など)があると、サーバ装置2へのアクセス頻度が多くなってしまう。そこで、このような場合には一定閾値以上の変化があった場合に値が変化したものと取り扱うとよい。
以上の処理によれば、操作部20が、操作部20及び本体10で利用可能なリソースを監視し、利用可能なリソースに変化があった場合に、サーバ装置2に操作部リソース情報及び本体(動作部)リソース情報を送信して、アプリが提供する機能のうち利用できない機能の再決定を要求する。従って、リソースの変化により利用可能な機能が増減した場合に、速やかにこれをアプリの動作に反映させることができる。
〔この実施形態におけるプログラム〕
この発明の実施形態であるプログラムは、操作部20を制御するCPU21(コンピュータ)又は本体10を制御するCPU11(コンピュータ)に上述した機能を実現させるためのプログラムである。そして、このようなプログラムをコンピュータに実行させることにより、上述したような効果を得ることができる。
この発明の実施形態であるプログラムは、操作部20を制御するCPU21(コンピュータ)又は本体10を制御するCPU11(コンピュータ)に上述した機能を実現させるためのプログラムである。そして、このようなプログラムをコンピュータに実行させることにより、上述したような効果を得ることができる。
このようなプログラムは、はじめからコンピュータに備えるHDD(ハードディスク装置)、あるいはROMや他の不揮発性記憶媒体(フラッシュメモリ,EEPROM等)などに格納しておいてもよい。しかし、記録媒体であるCD−ROM、あるいはメモリカード,フレキシブルディスク,MO,CD−R,CD−RW,DVD+R,DVD+RW,DVD−R,DVD−RW,又はDVD−RAM等の不揮発性記録媒体に記録して提供することもできる。それらの記録媒体に記録されたプログラムをコンピュータにインストールして実行させることにより、上述した各手順を実行させることができる。
さらに、ネットワークに接続され、プログラムを記録した記録媒体を備える外部装置あるいはプログラムを記憶手段に記憶した外部装置からダウンロードし、コンピュータにインストールして実行させることも可能である。
さらに、ネットワークに接続され、プログラムを記録した記録媒体を備える外部装置あるいはプログラムを記憶手段に記憶した外部装置からダウンロードし、コンピュータにインストールして実行させることも可能である。
〔変形例〕
以上で実施形態の説明を終了するが、この発明において、各部の具体的な構成や処理の内容、データの形式や項目等は、実施形態で説明したものに限るものではない。
例えば、要求リソース情報に規定する機能は、表1より細かいものでもよい。表5に示すように、プレビュー機能の中で、選択可能な各プレビューサイズについて、異なる必要メモリ容量を規定することも考えられる。この場合、本体リソース情報中のワークメモリ容量の情報を、要求リソース情報と比較し、必要メモリ容量が本体10において利用可能なメモリ容量より大きい選択肢を無効にするようにすればよい。
操作部20のリソースではなくて、本体10のリソースにて作業を行うプレビュー画像の作成等は、ワークメモリへの画像データの展開が必要になるため、操作パネル27に表示できる操作画面(ユーザインターフェース)に影響を与えることになる。
以上で実施形態の説明を終了するが、この発明において、各部の具体的な構成や処理の内容、データの形式や項目等は、実施形態で説明したものに限るものではない。
例えば、要求リソース情報に規定する機能は、表1より細かいものでもよい。表5に示すように、プレビュー機能の中で、選択可能な各プレビューサイズについて、異なる必要メモリ容量を規定することも考えられる。この場合、本体リソース情報中のワークメモリ容量の情報を、要求リソース情報と比較し、必要メモリ容量が本体10において利用可能なメモリ容量より大きい選択肢を無効にするようにすればよい。
操作部20のリソースではなくて、本体10のリソースにて作業を行うプレビュー画像の作成等は、ワークメモリへの画像データの展開が必要になるため、操作パネル27に表示できる操作画面(ユーザインターフェース)に影響を与えることになる。
また、ユーザ毎に、該ユーザが利用可能なリソースが設定されている場合、その設定を行っている利用権限情報を参照し、ログイン中のユーザが利用可能なリソースの情報を、インストール可否や利用可能機能の決定に用いるとよい。装置がリソースを備えていても、ユーザがそのリソースを利用できなければ、アプリの機能を実行できないためである。操作部20と本体10の一方のみについて利用権限情報が規定されている場合、そちらのみについて利用権限情報を参照すればよい。
なお、一旦アプリをインストールした後でログインユーザが変更になったり利用権限情報が変更されたりした場合には、図7や図9で説明したように、利用可能なリソースが変化したとして取り扱えばよい。
なお、一旦アプリをインストールした後でログインユーザが変更になったり利用権限情報が変更されたりした場合には、図7や図9で説明したように、利用可能なリソースが変化したとして取り扱えばよい。
また、表6に示すように、複数のユーザの利用権限情報に基づき、各ユーザについて予め利用可能な機能を決定して機能利用制限情報として登録しておき、ログイン中のユーザに応じた機能利用制限情報を参照して機能の利用可否を制御するようにしてもよい。
表6には、表2と表5に従って各ユーザの利用可能機能を決定した例を示している。
表6には、表2と表5に従って各ユーザの利用可能機能を決定した例を示している。
また、前述した各実施形態では、操作部20にアプリをインストールする際の動作について説明した。しかし、本体10にアプリをインストールする場合でも、そのアプリが操作部20を利用するのであれば、本体10が本体10及び操作部20の利用可能リソースの情報を収集して同様な動作を行うことも可能である。
また、上述した各実施形態では画像処理システム1を、本体10と操作部20とを固定的に組み合わせて構成した例について説明したが、これには限られない。
操作部と本体(動作部)とを、ハードウェアコンポーネントとして全く別の装置としてもよい。例えば、スマートフォン等のモバイル端末を操作部とし、MFP等の画像処理装置を動作部として画像処理システムあるいは情報処理システムを構成してもよい。特に、操作部と動作部を無線で接続する場合には、これらは全く独立した装置として構成可能である。
操作部と本体(動作部)とを、ハードウェアコンポーネントとして全く別の装置としてもよい。例えば、スマートフォン等のモバイル端末を操作部とし、MFP等の画像処理装置を動作部として画像処理システムあるいは情報処理システムを構成してもよい。特に、操作部と動作部を無線で接続する場合には、これらは全く独立した装置として構成可能である。
また、操作部と動作部とは、1対1でなくてもよい。例えば、本体に有線接続された操作部がある画像処理装置を、モバイル端末からも操作できるようにすることが考えられる。あるいは、1台の画像処理装置を複数のモバイル端末から操作できるようにすることも考えられる。あるいはまた、1台のモバイル端末から操作対象を切り替えつつ複数の画像処理装置を操作できるようにすることも考えられる。
なお、操作部による操作の対象となる動作部が変更された場合には、変更後の組み合わせによる操作部リソース情報と動作部リソース情報とに基づき、アプリの利用可能機能を再度決定するようにするとよい。
なお、操作部による操作の対象となる動作部が変更された場合には、変更後の組み合わせによる操作部リソース情報と動作部リソース情報とに基づき、アプリの利用可能機能を再度決定するようにするとよい。
また、上述した操作部20と本体10の機能を、それぞれ複数台の装置が協働して実現する構成であってもよい。逆に、操作部20と本体10とが1つの筐体に収まっていてもよい。あるいは、操作部がアプリを実行する際に同時に又は選択的に複数の動作部を利用することがあってもよい。この場合、利用する全ての動作部から動作部リソース情報を収集して、要求リソース情報と比較すればよい。
また、情報処理システムを構成する1のモジュールが、スキャナやプロッタのような画像処理エンジンを備えていることも必須ではない。各モジュールは、任意の情報処理装置でよい。もちろん、情報処理以外の物理的な入力や出力を合わせて行う装置でもよい。
さらに、この発明は上述した実施形態に限定されるものではなく、特許請求の範囲に記載された技術思想に含まれる技術的事項の全てが対象となることは言うまでもない。
さらにまた、以上説明してきた実施形態、動作例及び変形例の構成は、相互に矛盾しない限り任意に組み合わせて実施可能であることは勿論である。
さらに、この発明は上述した実施形態に限定されるものではなく、特許請求の範囲に記載された技術思想に含まれる技術的事項の全てが対象となることは言うまでもない。
さらにまた、以上説明してきた実施形態、動作例及び変形例の構成は、相互に矛盾しない限り任意に組み合わせて実施可能であることは勿論である。
1:画像処理システム、2:サーバ装置、2a:ダウンロードサーバ、2b:認証サーバ、3:ネットワーク、3a:LAN、3b:無線LAN・AP、10:本体、11,21:CPU、12,22:ROM、13,23:RAM、14:HDD、15,25:通信I/F、16,26:接続I/F、17:エンジン部、18,28:システムバス、20:操作部、24:フラッシュメモリ、27:操作パネル、30:通信路、101,201:アプリ層、102,202:サービス層、103,203:OS層
Claims (9)
- 指示の入力を受け付ける操作部と、該操作部が受け付けた指示に基づき情報処理動作する動作部とを備える情報処理システムであって、
前記操作部で利用可能なリソースを示す操作部リソース情報及び前記動作部で利用可能なリソースを示す動作部リソース情報を取得し、前記操作部にインストールされたアプリケーションが要求するリソースを示す要求リソース情報と、前記操作部リソース情報及び前記動作部リソース情報との比較に基づき、該アプリケーションの利用可能な機能を決定する決定手段を備えることを特徴とする情報処理システム。 - 請求項1に記載の情報処理システムであって、
ユーザ毎に、該ユーザが利用可能なリソースを設定した利用権限情報を参照する手段を備え、
前記決定手段が前記決定に、前記操作部リソース情報及び/又は前記動作部リソース情報として、ログイン中のユーザに関する前記利用権限情報を用いることを特徴とする情報処理システム。 - 請求項1に記載の情報処理システムであって、
さらにサーバ装置を備え、
前記決定手段は、該サーバ装置に設け、前記操作部から、前記操作部リソース情報及び前記動作部リソース情報を送信された場合に、これを取得して該アプリケーションの利用可能な機能を決定し、その結果を前記操作部に通知することを特徴とする情報処理システム。 - 請求項1から3のいずれか一項に記載の情報処理システムであって、
前記操作部がモバイル端末であることを特徴とする情報処理システム。 - 請求項1から4のいずれか一項に記載の情報処理システムであって、
前記動作部が画像処理装置であることを特徴とする情報処理システム。 - 請求項1から3のいずれか一項に記載の情報処理システムであって、
前記操作部及び前記動作部の一方又は両方が情報処理装置であることを特徴とする情報処理システム。 - 指示の入力を受け付ける操作部と、該操作部が受け付けた指示に基づき情報処理動作する動作部とを備えた情報処理システムにおいて、
前記操作部で利用可能なリソースを示す操作部リソース情報及び前記動作部で利用可能なリソースを示す動作部リソース情報を取得し、前記操作部にインストールされたアプリケーションが要求するリソースを示す要求リソース情報と、前記操作部リソース情報及び前記動作部リソース情報との比較に基づき、該アプリケーションの利用可能な機能を決定することを特徴とするアプリケーションの利用可能機能決定方法。 - 指示の入力を受け付ける操作部と、該操作部が受け付けた指示に基づき情報処理動作する動作部とを備える情報処理システムにおける前記操作部として機能する情報処理装置であって、
前記操作部で利用可能なリソースを示す操作部リソース情報及び前記動作部で利用可能なリソースを示す動作部リソース情報を取得し、前記操作部にインストールされたアプリケーションが要求するリソースを示す要求リソース情報と、前記操作部リソース情報及び前記動作部リソース情報との比較に基づき、該アプリケーションの利用可能な機能を決定する決定手段を備えることを特徴とする情報処理装置。 - 指示の入力を受け付ける操作部と、該操作部が受け付けた指示に基づき情報処理動作する動作部とを備える情報処理システムを制御するコンピュータに、
前記操作部で利用可能なリソースを示す操作部リソース情報及び前記動作部で利用可能なリソースを示す動作部リソース情報を取得し、前記操作部にインストールされたアプリケーションが要求するリソースを示す要求リソース情報と、前記操作部リソース情報及び前記動作部リソース情報との比較に基づき、該アプリケーションの利用可能な機能を決定する機能を実現させるためのプログラム。
Priority Applications (1)
Application Number | Priority Date | Filing Date | Title |
---|---|---|---|
JP2017000453A JP6274328B2 (ja) | 2017-01-05 | 2017-01-05 | 情報処理システムとそのアプリケーションの利用可能機能決定方法、並びに情報処理装置及びプログラム |
Applications Claiming Priority (1)
Application Number | Priority Date | Filing Date | Title |
---|---|---|---|
JP2017000453A JP6274328B2 (ja) | 2017-01-05 | 2017-01-05 | 情報処理システムとそのアプリケーションの利用可能機能決定方法、並びに情報処理装置及びプログラム |
Related Parent Applications (1)
Application Number | Title | Priority Date | Filing Date |
---|---|---|---|
JP2013042611A Division JP6070286B2 (ja) | 2013-03-05 | 2013-03-05 | 情報処理システム、情報処理装置及びプログラム |
Publications (2)
Publication Number | Publication Date |
---|---|
JP2017107576A JP2017107576A (ja) | 2017-06-15 |
JP6274328B2 true JP6274328B2 (ja) | 2018-02-07 |
Family
ID=59059715
Family Applications (1)
Application Number | Title | Priority Date | Filing Date |
---|---|---|---|
JP2017000453A Active JP6274328B2 (ja) | 2017-01-05 | 2017-01-05 | 情報処理システムとそのアプリケーションの利用可能機能決定方法、並びに情報処理装置及びプログラム |
Country Status (1)
Country | Link |
---|---|
JP (1) | JP6274328B2 (ja) |
Families Citing this family (1)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
JP7050466B2 (ja) * | 2017-11-14 | 2022-04-08 | 株式会社サイバーリンクス | 認証システムおよび認証方法 |
Family Cites Families (7)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
JPH07271702A (ja) * | 1994-04-01 | 1995-10-20 | Canon Inc | スキャナプリンタサーバーシステムおよびスキャナプリンタサーバーシステムの有効機能管理方法 |
JP3898476B2 (ja) * | 2001-09-11 | 2007-03-28 | 株式会社リコー | 画像情報処理装置およびソフトウェア再構築方法 |
JP2004005419A (ja) * | 2002-03-25 | 2004-01-08 | Canon Inc | インストール処理装置、処理方法及び記憶媒体ならびにプログラム |
JP2007287066A (ja) * | 2006-04-20 | 2007-11-01 | Konica Minolta Business Technologies Inc | 画像処理装置、同装置におけるアプリケーションのインストール方法、及びアプリケーションのインストール処理プログラム |
JP4892464B2 (ja) * | 2007-02-16 | 2012-03-07 | 株式会社リコー | 画像処理装置、画像処理装置の制御方法、制御プログラム及び記録媒体 |
JP4994909B2 (ja) * | 2007-03-26 | 2012-08-08 | キヤノン株式会社 | プログラム管理装置及び方法 |
JP5814526B2 (ja) * | 2010-08-26 | 2015-11-17 | キヤノン株式会社 | 画像形成装置、画像形成装置の制御方法、およびプログラム |
-
2017
- 2017-01-05 JP JP2017000453A patent/JP6274328B2/ja active Active
Also Published As
Publication number | Publication date |
---|---|
JP2017107576A (ja) | 2017-06-15 |
Similar Documents
Publication | Publication Date | Title |
---|---|---|
JP4409970B2 (ja) | 画像形成装置、及び認証プログラム | |
CN102195961B (zh) | 图像形成系统以及图像形成方法 | |
JP6236816B2 (ja) | 画像処理システム、情報処理装置及びプログラム | |
JP6720519B2 (ja) | 情報処理装置、プログラムおよび情報処理システム | |
EP3213197B1 (en) | Information processing system, information processing device, and information processing method | |
JP6927276B2 (ja) | 情報処理システム、情報処理装置、情報処理方法およびプログラム | |
JP2018206147A (ja) | 印刷システムおよびプログラム | |
US8973103B2 (en) | Image forming apparatus, license server, terminal apparatus, method for installing application, and method for providing application file | |
JP6107172B2 (ja) | 画像処理システムとその機能の追加又は更新方法及びプログラム | |
JP2019032716A (ja) | 印刷システム、プリンタドライバプログラム | |
EP3299981B1 (en) | Image forming apparatus, method for controlling image forming apparatus, and storage medium | |
JP6102220B2 (ja) | 画像処理システム及びその情報処理方法 | |
JP5857589B2 (ja) | 印刷装置及び印刷システム | |
JP6070286B2 (ja) | 情報処理システム、情報処理装置及びプログラム | |
JP4425989B2 (ja) | 画像形成装置 | |
JP2012150577A (ja) | 画像処理装置、同装置におけるアプリケーションの移動処理方法及び移動処理プログラム | |
JP6274328B2 (ja) | 情報処理システムとそのアプリケーションの利用可能機能決定方法、並びに情報処理装置及びプログラム | |
JP6296025B2 (ja) | ネットワーク機器及び機能制限プログラム | |
JP2015094984A (ja) | 画像形成装置およびその制御方法、並びにプログラム | |
JP2010198334A (ja) | 画像処理装置、及び、プログラム | |
JP6424441B2 (ja) | 複合機、情報処理方法、情報処理プログラム、および情報処理システム | |
JP6790482B2 (ja) | 情報処理システム、情報処理装置、情報処理方法およびプログラム | |
JP5539073B2 (ja) | 認証システム、認証サービスの制御方法、プログラム | |
JP2015197837A (ja) | 印刷システム、端末装置、サーバ装置、印刷装置、端末装置の制御方法、サーバ装置の制御方法、印刷装置の制御方法及びプログラム | |
JP6916464B2 (ja) | サーバ用プリンタドライバプログラム |
Legal Events
Date | Code | Title | Description |
---|---|---|---|
A977 | Report on retrieval |
Free format text: JAPANESE INTERMEDIATE CODE: A971007 Effective date: 20171129 |
|
TRDD | Decision of grant or rejection written | ||
A01 | Written decision to grant a patent or to grant a registration (utility model) |
Free format text: JAPANESE INTERMEDIATE CODE: A01 Effective date: 20171212 |
|
A61 | First payment of annual fees (during grant procedure) |
Free format text: JAPANESE INTERMEDIATE CODE: A61 Effective date: 20171225 |
|
R151 | Written notification of patent or utility model registration |
Ref document number: 6274328 Country of ref document: JP Free format text: JAPANESE INTERMEDIATE CODE: R151 |