JP2014216822A - 画像形成装置及び画像形成方法 - Google Patents

Abstract

【課題】セキュリティリスクを低くしつつアプリケーション間で情報の共用が可能な画像形成装置を提供する。【解決手段】サービス取得部８１０は、アプリ９６−１〜９６−ｎのインストール時に、アプリ９６−１〜９６−ｎのクラス情報を参照して、サービス９４−１〜９４−ｎをサーバ３００等から取得する。サービス登録部８２０は、サービス取得部８１０により取得されたサービス９４−１〜９４−ｎを、アプリ９６−１〜９６−ｎそれぞれに対応付けしてサービスレジストリ９３に格納する。情報共用制御部８３０は、アプリ９６−１〜９６−ｎが実行される際に、サービス登録部８２０によりアプリ９６−１〜９６−ｎに対応付けされたサービス９４−１〜９４−ｎの管理情報に基づいて他のアプリ９６−１〜９６−ｎとの間で共用データ９５により情報を共用させる。【選択図】図３

Description

本発明は、画像形成装置及び画像形成方法に係り、特にアプリケーションを実行可能な画像形成装置及び画像形成方法に関する。

従来から、文書や画像を印刷可能な複合機（Multifunctional Peripheral, MFP）等の画像形成装置において、アプリケーション（Application Software）をインストールし実行することが可能なものが存在する。
これらのアプリケーションにより、ＰＤＦ作成、名刺管理、帳簿管理等の機能を画像形成装置に追加可能になる。また、アプリケーションにより、ネットワークカメラ等の外部の機器との連携を行うことも可能である。

特許文献１を参照すると、このようなアプリケーションを格納する記憶手段を含み、記憶手段に格納された各種のアプリケーションを使用して画像処理を行う画像形成装置の技術が記載されている。

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

ここで、特許文献１の技術のように記憶手段に記憶されたアプリケーションを実行可能な従来の画像形成装置で、アプリケーション間で情報を共用する場合、ＯＳ（Operating System）に標準で用意された手段を使用するしかないという問題があった。
たとえば、従来の画像形成装置では、ＩＰ（Internet Protocol）のポートを開いて、ソケット通信を用いてアプリケーション間で情報を共用していた。つまり、アプリケーションが使用するパケットを他のアプリに公開して、情報の共用を行っていた。
このようにＯＳに標準で用意された手段で情報の共用を行うと、セキュリティリスクが高まるという問題があった。

本発明は、このような状況に鑑みてなされたものであって、上述の問題点を解消し、セキュリティリスクを低くしつつアプリケーション間で情報の共用が可能な画像形成装置を提供することを課題とする。

本発明の画像形成装置は、記憶手段に記憶された複数のアプリケーションを実行可能な画像形成装置において、前記記憶手段に記憶された前記アプリケーションから共用して呼び出し可能なサービスを取得するサービス取得手段と、該サービス取得手段により取得された前記サービスを、前記アプリケーションと対応付けして前記記憶手段に格納するサービス登録手段と、該サービス登録手段により対応付けされた前記サービスにより提供される情報を、前記記憶手段に格納された他の前記サービスとの間で共用させる情報共用制御手段とを備えることを特徴とする。
本発明の画像形成装置は、前記サービスは登録手段は、前記サービスを、前記記憶手段の保護された領域に格納することを特徴とする。
本発明の画像形成装置は、前記情報共用制御手段により共用された情報により、不正な処理を行った前記アプリケーションによる前記サービスの利用権限を不許可にするアプリケーション管理手段を備えることを特徴とする。
本発明の画像形成方法は、記憶手段に記憶された複数のアプリケーションを実行可能な画像形成装置により実行される画像形成方法において、前記記憶手段に記憶された前記アプリケーションから共用して呼び出し可能なサービスを取得し、取得された前記サービスを、前記アプリケーションと対応付けして前記記憶手段に格納し、対応付けされた前記サービスにより提供される情報を、前記記憶手段に格納された他の前記サービスとの間で共用させることを特徴とする。

本発明によれば、アプリケーションの管理情報を含むサービスを取得して、アプリケーションの実行時に、当該アプリケーションに対応付けされたサービスを実行し、管理情報に基づいて、他のアプリケーションとの間で情報を共用することで、ＯＳに標準で用意された手段によらずに情報の共用が可能となり、セキュリティリスクを低減した画像形成装置を提供することができる。

本発明の画像形成装置の実施の形態に係る内部構成を示す概略模式断面図である。 本発明の画像形成装置の実施の形態に係る制御構成を示すブロック図である。 本発明の実施の形態に係るプラットフォームの構成及びアプリ制御部の制御構成を示すブロック図である。 本発明の実施の形態に係るアプリインストール処理のフローチャートである。 本発明の実施の形態に係る一般アプリ実行処理のフローチャートである。 本発明の実施の形態に係る管理アプリ実行処理のフローチャートである。 本発明の実施の形態に係るアプリアンインストール処理のフローチャートである。 本発明のサーバ及び端末の実施の形態に係る制御構成を示すブロック図である。 本発明の実施の形態に係るアプリ開発処理のフローチャートである。

＜実施の形態＞
〔画像形成装置１の構成〕
まず、図１を参照して、本発明の画像形成装置１の実施の形態に係る構成について詳しく説明する。
図１によると、画像形成装置１は、原稿読取部２と、原稿給送部３と、本体部４と、スタックトレイ５と、操作パネル部６とを備えている。
原稿読取部２は、本体部４の上部に配設され、原稿給送部３は、原稿読取部２の上部に配設されている。スタックトレイ５は、本体部４の形成された記録紙の排出口４１側に配設され、また、操作パネル部６は、画像形成装置１のフロント側に配設されている。

原稿読取部２は、スキャナー２１と、プラテンガラス２２と、原稿読取スリット２３とを備えている。スキャナー２１は、露光ランプ、及びＣＣＤ(Charge Coupled Device)やＣＭＯＳ（Complementary Metal Oxide Semiconductor）撮像センサ等から構成され、原稿給送部３による原稿の搬送方向に移動可能に構成されている。プラテンガラス２２は、ガラス等の透明部材により構成された原稿台である。原稿読取スリット２３は、原稿給送部３による原稿の搬送方向と直交方向に形成されたスリットを有する。

プラテンガラス２２に載置された原稿を読み取る場合には、スキャナー２１は、プラテンガラス２２に対向する位置に移動され、プラテンガラス２２に載置された原稿を走査しながら原稿を読み取って画像データを取得して、取得した画像データを本体部４に出力する。
また、原稿給送部３により搬送された原稿を読み取る場合には、スキャナー２１は、原稿読取スリット２３と対向する位置に移動され、原稿読取スリット２３を介し、原稿給送部３による原稿の搬送動作と同期して原稿を読み取って画像データを取得し、取得した画像データを本体部４に出力する。

原稿給送部３は、原稿載置部３１と、原稿排出部３２と、原稿搬送機構３３とを備えている。原稿載置部３１に載置された原稿は、原稿搬送機構３３によって、１枚ずつ順に繰り出されて原稿読取スリット２３に対向する位置へ搬送され、その後、原稿排出部３２に排出される。なお、原稿給送部３は、可倒式に構成され、原稿給送部３を上方に持ち上げることで、プラテンガラス２２の上面を開放させることができる。

本体部４は、画像形成部７を備えると共に、給紙部４２と、用紙搬送路４３と、搬送ローラー４４と、排出ローラー４５とを備えている。給紙部４２は、それぞれサイズ又は向きが異なる記録紙を収納する複数の給紙カセット４２１と、給紙カセット４２１から記録紙を１枚ずつ用紙搬送路４３に繰り出す給紙ローラー４２２とを備えている。
給紙ローラー４２２、搬送ローラー４４、及び排出ローラー４５は、搬送部として機能する。記録紙は、この搬送部により搬送される。給紙ローラー４２２によって用紙搬送路４３に繰り出された記録紙は、搬送ローラー４４によって画像形成部７に搬送される。
そして、画像形成部７によって記録が施された記録紙は、排出ローラー４５によってスタックトレイ５に排出される。

操作パネル部６は、ＬＣＤ等の表示部と、スタートキー、テンキー、複写／ＦＡＸ送信／スキャナー等の動作モードの切り換えのボタン、選択された文書の印刷、送信、保存、又は記録等に関するジョブの実行に係る指示を行うためのボタンやタッチパネル等を備えている。つまり、操作パネル部６は、ユーザーによる画像形成装置１の各種ジョブの指示を取得する。また、操作パネル部６により、アカウント情報９０の各ユーザーの情報を入力・変更することもできる。

画像形成部７は、感光体ドラム７１と、露光部７２と、現像部７３と、転写部７４と、定着部７５とを備えている。
露光部７２は、レーザー装置やＬＥＤアレイやミラーやレンズ等を備えた光学ユニットであり、画像データに基づいて光等を出力して感光体ドラム７１を露光し、感光体ドラム７１の表面に静電潜像を形成する。
現像部７３は、トナーを用いて感光体ドラム７１に形成された静電潜像を現像する現像ユニットであり、静電潜像に基づいたトナー像を感光体ドラム７１上に形成させる。転写部７４は、現像部７３によって感光体ドラム７１上に形成されたトナー像を記録紙に転写させる。定着部７５は、転写部７４によってトナー像が転写された記録紙を加熱してトナー像を記録紙に定着させる。

｛画像形成装置１の制御構成｝
図２によると、画像形成装置１の原稿読取部２、原稿給送部３、搬送部（給紙ローラー４２２、搬送ローラー４４、排出ローラー４５）、操作パネル部６、及び画像形成部７（画像形成手段）は、制御部８に接続され、制御部８によって動作制御される。また、制御部８には、記憶部９（記憶手段）、画像処理部１０（画像処理手段）、ＦＡＸ送受信部１１、ネットワーク送受信部１２等が接続されている。

制御部８は、ＲＯＭ（Read Only Memory）、ＲＡＭ（Random Access Memory）等を備えたマイクロコンピュータ等の情報処理部である。ＲＯＭには画像形成装置１の動作制御を行うための制御プログラムが記憶されている。
制御部８及び画像処理部１０は、ＲＯＭに記憶されている制御プログラムを読み出し、この制御プログラムをＲＡＭに展開させることで、操作パネル部６から入力された所定の指示情報に応じて装置全体の制御を行う。
また、制御部８は、アプリ制御部８１（サービス取得手段、サービス登録手段、アプリケーション共用制御手段、アプリケーション管理手段）を備えている。

アプリ制御部８１は、アプリ９６−１〜９６−ｎ（Application Software、アプリケーション）のインストール、実行、アンインストール等の制御を行う。
アプリ制御部８１の詳細構成については、後述する。

記憶部９は、ＲＡＭ、ＲＯＭ、フラッシュメモリ等の半導体メモリやＨＤＤ（Hard Disk Drive）等の記憶媒体を用いた記憶手段である。
記憶部９に記憶されるデータの詳細についても、後述する。

画像処理部１０は、ＤＳＰ（Digital Signal Processor）やＧＰＵ（Graphics Processing Unit）等の制御演算手段である。画像処理部１０は、画像データに対して所定の画像処理を行う手段であり、拡大縮小、濃度調整、階調調整等の画像改善処理を含む各種画像処理を行う。
画像処理部１０は、原稿読取部２で読み取られた画像を、ＰＤＦやＴＩＦＦ等のフォーマットのファイル単位に変換した上で、記憶部９に記憶することが可能である。

ＦＡＸ送受信部１１は、ファクシミリの送受信を行う手段であり、通常の電話回線やＩＳＤＮ回線等と接続されている。また、ＦＡＸ送受信部１１は、受信したファクシミリ画像を、記憶部９に記憶する。また、ＦＡＸ送受信部１１は、記憶部９に記憶された画像データや印刷データを、画像形成部７で印刷する代わりにファクシミリ送信することもできる。

ネットワーク送受信部１２は、ネットワーク１００に接続するためのＬＡＮボードや無線ＬＡＮの送受信機や携帯電話網接続ボード等を含む、外部のネットワーク１００へ接続する手段である。ネットワーク１００は、ＬＡＮ、ＷＡＮ、携帯電話網等のネットワークである。
ネットワーク送受信部１２は、ネットワーク１００を介して、端末２００及びサーバ３００と接続される。ネットワーク送受信部１２は、端末２００からアプリ９６−１〜９６−ｎを、サーバ３００からはサービス９４−１〜９４−ｎを受信し、これに伴う各種指示を受信する。つまり、端末２００はアプリ９６−１〜９６−ｎを、サーバ３００はサービス９４−１〜９４−ｎをそれぞれ記憶している。また、ネットワーク送受信部１２は、各種通知を端末２００及びサーバ３００へ送信することも可能である。
端末２００及びサーバ３００は、画像形成装置１で実行可能なアプリ９６−１〜９６−ｎをインストールしたり作成したりする指示を行うことが可能である。加えて、端末２００及びサーバ３００は、ユーザーからの指示で、画像形成装置１の各種の制御を行うこともできる。また、後述するように、端末２００及びサーバ３００は、アプリ９６−１〜９６−ｎの開発を行うことも可能である。

なお、画像形成装置１において、制御部８、及び画像処理部１０は、ＧＰＵ内蔵ＣＰＵ等やチップ・オン・モジュールパッケージのように、一体的に形成されていてもよい。

（記憶部９の構成）
ここで、記憶部９に記憶されるデータについて説明する。記憶部９は、アカウント情報９０、機器設定９１、プラットフォーム９２、アプリ９６−１〜９６−ｎ（Application Software、アプリケーション）を記憶する。

アカウント情報９０は、ユーザーのアカウント毎に、ユーザーＩＤ、パスワード、権限情報、端末２００やサーバ３００のＩＰアドレス、メールアドレス、送信先、住所やクレジットカード番号等の各種情報を格納するデータベースである。
アカウント情報９０には、予め各ユーザーが操作パネル部６やユーザーの端末等から当該ユーザーの各種情報を入力して登録することが可能である。また、アカウント情報９０にはゲストとしてユーザーを登録することも可能である。

機器設定９１は、画像形成装置１で使用可能な機能についての情報、シリアル番号や製造番号や固有番号等を含む機器固有ＩＤ、メモリ容量、印刷設定、印刷枚数、課金情報等を含んでいる。

プラットフォーム９２は、図示しないＯＳ上で動作し、アプリ９６−１〜９６−ｎにより画像形成装置１の各機能を呼び出すためのＡＰＩ（Application Programming Interface）やミドルウェアやランタイム等を含むプログラムやデータである。プラットフォーム９２のＡＰＩ等は、アプリ９６−１〜９６−ｎをインストール、実行、アンインストールする際に利用される。
また、プラットフォーム９２は、アプリ９６−１〜９６−ｎから呼び出されるプログラム（クラス、ルーチン、関数等）であるサービス９４−１〜９４−ｎ（図３）と、これに関するデータも含んでいる。このサービス９４−１〜９４−ｎについては後述する。
なお、記憶部９には、プラットフォーム９２とは異なるＡＰＩによるアプリケーションを記憶させることも可能である。たとえば、記憶部９には、アプリ９６−１〜９６−ｎ以外のＷｅｂアプリ等のアプリケーション・ソフトウェア（以下「外部アプリ」という。）を記憶させることが可能である。しかしながら、この場合は、後述するような情報の共用等はできない。

アプリ９６−１〜９６−ｎは、画像形成装置１の機能を使用可能に構成された、例えば名刺管理やＰＤＦ作成や帳簿管理やグループ管理等のアプリケーションである。
アプリ９６−１〜９６−ｎは、ユーザーがインストールし、画像形成装置１の各機能を呼び出して所望の機能を実現させるための「一般アプリ」と、これらの一般アプリを管理する「管理アプリ」とを含んでいる。

なお、記憶部９は、端末２００や画像形成装置１の操作パネル部６で指示された各種ジョブデータ、原稿読取部２によってスキャンされた画像データ、画像処理部１０で画像処理された画像データ、ユーザーの端末から送信された印刷文書のデータ、外部の記録媒体から読み出された各種ファイル、サムネイル画像のデータ等を記憶してもよい。
また、記憶部９には、ユーザー毎の保存フォルダの領域が含まれていてもよい。また、記憶部９には、外部アプリがインストールされていてもよい。

｛プラットフォーム９２の構成及びアプリ制御部８１の制御構成｝
次に、図３を参照して、本発明の画像形成装置１の実施の形態に係るプラットフォーム９２の構成及びアプリ制御部８１の制御構成の詳細について説明する。
プラットフォーム９２は、サービスに関するデータとして、サービスレジストリ９３を含んでいる。
アプリ制御部８１は、サービス取得部８１０（サービス取得手段）、サービス登録部８２０（サービス登録手段）、情報共用制御部８３０（情報共用制御手段）、アプリ管理部８４０（アプリケーション管理手段）を備えている。

（プラットフォーム９２の構成）
サービスレジストリ９３は、サービス９４−１〜９４−ｎを登録するためのデータベース等である。
サービスレジストリ９３は、プラットフォーム９２のＡＰＩを利用して、サービス９４−１〜９４−ｎをアプリ９６−１〜９６−ｎに、それぞれ対応付けて登録、削除可能である。
また、サービスレジストリ９３は、サービス９４−１〜９４−ｎの間で共用される記憶領域である共用データ９５を含んでいる。
サービスレジストリ９３は、記憶部９の保護された記憶領域に確保されることが好ましい。つまり、サービスレジストリ９３は、プラットフォーム９２内のサービス９４−１〜９４−ｎ以外のプログラムからの直接のアクセスに対しては保護され、参照や書き換えが不可能であるように構成してもよい。

サービス９４−１〜９４−ｎは、サービス９４−１〜９４−ｎは、対応付けされたアプリ９６−１〜９６−ｎから共用して呼び出し可能なプログラム等である。つまり、サービス９４−１〜９４−ｎは、サービスレジストリ９３に登録された場合、他のアプリ９６−１〜９６−ｎからも共用され、他のアプリ９６−１〜９６−ｎからも呼び出し可能でとなる。しかしながら、サービス９４−１〜９４−ｎは、外部アプリからは利用できない。
サービス９４−１〜９４−ｎは、呼び出し可能なサービスについての管理情報と、実行ファイルとを含んで構成される。

サービス９４−１〜９４−ｎの管理情報は、クラスパスやパッケージ等のクラスを参照するための情報、機能の説明やクラス名等の情報、対応付けされたアプリ９６−１〜９６−ｎの情報を含んでいる。この対応付けされたアプリ９６−１〜９６−ｎについての情報としては、対応付けされたアプリ９６−１〜９６−ｎのファイルシステム上のパス、改ざんを防ぐためのファイルのハッシュ情報、アプリ９６−１〜９６−ｎによるサービス９４−１〜９４−ｎの利用権限、管理アプリ又は一般アプリの種別、サービス９４−１〜９４−ｎの間で共用する情報の形式、共用する情報の記憶領域の容量やメモリ空間上の位置等の情報を含ませることが可能である。アプリ９６−１〜９６−ｎによるサービス９４−１〜９４−ｎの利用権限は、既定（デフォルト）では、対応付けされたアプリ９６−１〜９６−ｎ以外でも利用可能な設定になるよう構成される。なお、特定のアプリ９６−１〜９６−ｎのみ利用可能な利用権限を設定することも可能である。この場合、他のアプリ９６−１〜９６−ｎがインストールされて依存関係のある場合は、当該アプリ９６−１〜９６−ｎからも呼び出し可能なように、利用権限を設定することもできる。
また、サービス９４−１〜９４−ｎの管理情報に、アプリ９６−１〜９６−ｎの実行時に、実行したジョブ状況、使用しているリソース、ログ等を含ませることが可能である。また、この管理情報には、使用リソースの情報やインクルードファイル等を含んでいてもよい。

サービス９４−１〜９４−ｎの実行ファイルは、中間言語のファイルやｅｘｅファイルやＤＬＬ（Dynamic Linking Library）等のバイナリのファイルである。この実行ファイルは、ｊａｒ形式等で提供されるアーカイブファイル等として構成されてもよい。サービス９４−１〜９４−ｎの実行ファイルは、アプリ９６−１〜９６−ｎで情報を共用し通信を行うためのクラスや画像形成装置１の各機能を呼び出すためのクラス等を含んでいる。つまり、原稿読取部２、原稿給送部３、本体部４、スタックトレイ５、操作パネル部６、画像形成部７、画像処理部１０、ＦＡＸ送受信部１１、ネットワーク送受信部１２等の各部の機能については、アプリ制御部８１がアプリ９６から、対応づけされたサービス９４を呼び出し実行することで使用可能となる。
以下で、サービス９４−１〜９４−ｎのいずれか一つを示す場合、単にサービス９４という。

アプリ９６−１〜９６−ｎは、プラットフォーム９２上で動作する実行ファイルと、クラス情報を含む各種データとを含んで構成される。アプリ９６−１〜９６−ｎは、例えば、ｊａｒ形式や独自形式のインストール用ファイルによりインストールされる。

アプリ９６−１〜９６−ｎのクラス情報は、呼び出す機能に基づいた各クラスのクラス識別子、クラスパス、パッケージ名、一般アプリと管理アプリの種別等を示すデータである。アプリ９６−１〜９６−ｎのクラス情報により、対応付けされたサービス９４−１〜９４−ｎのクラスが呼び出される。

アプリ９６−１〜９６−ｎの実行ファイルは、例えばＪａｖａ（登録商標）アプリケーションの中間言語のファイルや、「ネイティブ」のｅｘｅファイル等からなるアプリケーションのバイナリのファイルである。
この他にも、アプリ９６−１〜９６−ｎは必要なデータを含んでいてもよい。
以下で、アプリ９６−１〜９６−ｎのいずれか一つを示す場合には、単にアプリ９６という。

アプリ９６−１〜９６−ｎは、サービス９４−１〜９４−ｎを使用しないと、情報を共用したり、他のアプリ９６−１〜９６−ｎと通信したりする機能を使用できないように構成される。これにより、画像形成装置１のインストール時に海賊版のアプリ９６−１〜９６−ｎを排除でき、セキュリティを確保可能となる。

上述のように、記憶部９は、アプリケーションの実行ファイルであるアプリ９６−１〜９６−ｎを記憶するアプリケーション記憶手段として機能する。また、記憶部９は、アプリ９６−１〜９６−ｎのそれぞれに対応付けられたサービス９４−１〜９４−ｎをサービスレジストリ９３に登録し記憶するサービス記憶手段として機能する。また、記憶部９は、アプリ９６−１〜９６−ｎを実行する際のＡＰＩ等を提供するプラットフォーム９２を記憶するプラットフォーム記憶手段として機能する。

（アプリ制御部８１の制御構成）
サービス取得部８１０は、アプリ９６−１〜９６−ｎのインストール時に、サービス９４−１〜９４−ｎをサーバ３００等から取得する。この際、サービス取得部８１０は、アプリ９６−１〜９６−ｎの少なくともクラス情報をサーバ３００に送信し、サーバ３００に適切なサービス９４−１〜９４−ｎを選択させてもよい。
サービス登録部８２０は、サービス取得部８１０により取得されたサービス９４−１〜９４−ｎを、アプリ９６−１〜９６−ｎそれぞれに対応付けしてサービスレジストリ９３に格納する。この際、サービスレジストリ９３は保護された領域であるため、サービス登録部８２０は、例えば、特権アクセス等により、サービス９４−１〜９４−ｎを格納することが可能である。
情報共用制御部８３０は、サービス登録部８２０によりアプリ９６−１〜９６−ｎに対応付けされたサービス９４−１〜９４−ｎの管理情報を参照して、共用する情報を書き込み読み出す領域（以下、「共用領域」という。）を共用データ９５内に確保し、他のアプリ９６−１〜９６−ｎとの間で情報を共用させる。情報共用制御部８３０も、特権アクセス等により、共用領域を共用データ９５内に確保可能である。また、情報共用制御部８３０は、アプリ９６−１〜９６−ｎが実行される実行開始時、実行中に対応付けされたサービス９４−１〜９４−ｎが呼び出された際、及び実行終了時に、この共用領域を共用データ９５内に確保したり、解放したりすることが可能である。
アプリ管理部８４０は、他のアプリ９６−１〜９６−ｎを管理する管理アプリの実行時に、情報共用制御部８３０により共用された共用データ９５の共用領域を読み出して監視する。アプリ管理部８４０は、不正な処理をしたアプリ９６−１〜９６−ｎによるサービス９４−１〜９４−ｎの利用権限を許可又は不許可にするよう、当該サービス９４−１〜９４−ｎの管理情報を書き換えることが可能である。

また、アプリ制御部８１は、アプリ９６−１〜９６−ｎを画像形成装置１の記憶部９にインストールするインストール手段として機能する。
また、アプリ制御部８１は、アプリ９６−１〜９６−ｎの実行ファイルをＲＡＭに展開して実行ファイルを実行するアプリケーション実行手段として機能する。つまり、アプリ制御部８１は、アプリ９６−１〜９６−ｎを実行した際に、プラットフォーム９２が提供するＡＰＩを使用して、画像形成装置１の機能制御と情報取得が可能である。
また、アプリ制御部８１は、アプリ９６−１〜９６−ｎのそれぞれに対応付けられたサービス９４−１〜９４−ｎを読み出してＲＡＭに展開し、アプリ９６−１〜９６−ｎからサービス９４−１〜９４−ｎが呼び出された際にサービス９４−１〜９４−ｎの実行ファイルを実行するサービス実行手段としても機能する。
また、アプリ制御部８１は、アプリ９６−１〜９６−ｎのアンインストール時に、サービス９４−１〜９４−ｎの依存関係を参照して、サービス９４−１〜９４−ｎのインストールを行うインストール制御手段、又はアンインストールの制御を行うアプリアンインストール手段としても機能する。

〔画像形成装置１によるアプリインストール処理〕
ここで、図４を参照して、本発明の画像形成装置１の実施の形態によるアプリインストール処理の説明を行う。
この例では、端末２００からアプリ９６を画像形成装置１にリモートインストールする際の処理について説明する。
アプリインストール処理は、主に制御部８が、記憶部９に記憶されたプログラム等を各部と協働し、ハードウェア資源を用いて実行する。
以下で、図４のフローチャートを参照して、アプリインストール処理をステップ毎に詳細に説明する。

（ステップＳ１０１）
まず、アプリ制御部８１は、サービス取得部８１０を用いて、アプリインストール送付処理を行う。
ユーザーは、端末２００により、例えば、光学ドライブで、記憶媒体に記憶されたアプリ９６を読み込ませ、アプリ９６のインストーラ等のプログラムを起動する。すると、端末２００は、アプリインストール部２２０（図８）により、画像形成装置１をネットワーク１００上で検索して、ログインを行う。
アプリ制御部８１は、アカウント情報９０を参照して認証を行う。
認証が成功した場合、アプリ制御部８１は、端末２００からアプリ９６を取得して、プラットフォーム９２のＡＰＩにより記憶部９に格納し、登録情報等を書き込む。

（ステップＳ１０２）
次に、アプリ制御部８１は、サービス取得部８１０を用いて、サービス取得処理を行う。
アプリ制御部８１は、記憶部９に格納されたアプリ９６のクラス情報をサーバ３００に送信して、サービス９４を要求する。この際に、アプリ制御部８１は、端末２００からログインされたユーザーアカウントによりサーバ３００へログインしてもよい。

サーバ３００は、受信したクラス情報に基づいて、必要なサービス９４をデータベースから検索し、画像形成装置１に送信する。
この際、クラス情報が不正であった場合には、エラー情報を画像形成装置１に返す。なお、アプリ９６が不正な海賊版等であった場合には、エラー情報を返すのに加えて、サーバ３００の管理者にメール等で通知することも可能である。
アプリ制御部８１は、サーバ３００から送信されたサービス９４をネットワーク送受信部１２で受信して、記憶部９に記憶させる。

（ステップＳ１０３）
次に、アプリ制御部８１は、サービス登録部８２０を用いて、サービス登録処理を行う。
アプリ制御部８１は、サービス９４を取得した場合、プラットフォーム９２のＡＰＩを利用して、記憶部９に格納されたアプリ９６と対応付けるよう、管理情報に書き込む。そして、アプリ制御部８１は、取得したサービス９４を、サービスレジストリ９３に格納する。この際、アプリ制御部８１は、アプリ９６が、取得したサービス９４を利用可能となるようにサービス９４の管理情報の対応付けを設定する。つまり、アプリ制御部８１は、図３の例で示すように、例えば、アプリ９６−１はサービス９４−１と、アプリ９６−２はサービス９４−２と、アプリ９６−ｎはサービス９４−ｎと対応付けして、サービスレジストリ９３に格納する。
また、この際、アプリ制御部８１は、既に同種のサービス９４がサービスレジストリ９３に登録されている場合（以下、「依存関係」がある場合という。）は、そのサービス９４とアプリ９６とを対応付けしてもよい。つまり、アプリ制御部８１は、アプリ９６−２を、サービス９４−１に対応付けするような処理も可能である。同様に、アプリ制御部８１は、サービス９４−１〜９４−ｎの間に、例えばクラスの継承等の依存関係があった場合には、その依存関係についてもサービスレジストリ９３に登録する。

その後、アプリ制御部８１は、インストールが終了した旨、端末２００へ送信する。
以上により、本発明の実施の形態に係るアプリインストール処理を終了する。

なお、アプリ制御部８１は、画像形成装置１に、例えばアプリ９６が記録されたフラッシュメモリや光学記録媒体をＵＳＢ等で接続し、これからアプリ９６−１〜９６−ｎをインストールすることも可能である。また、アプリ制御部８１は、サーバ３００からアプリ９６−１〜９６−ｎをインストールすることも可能である。
また、アプリ制御部８１は、アプリ９６−１〜９６−ｎと対応付けられたサービス９４−１〜９４−ｎを記録媒体に記録しておき、サーバ３００にアクセスせずに直接インストールすることも可能である。

また、サーバ３００は、サービス９４を、アプリ９６のみから利用可能なように暗号化し、暗号キー等を送信してもよい。
また、アプリ制御部８１は、サービス登録部８２０を用いて、サービス９４の管理情報が不正であった場合には、サービスレジストリ９３に格納せずエラーを報知してもよい。また、アプリ制御部８１は、サービス登録部８２０により機器設定９１を読み出し、サービス９４から呼び出したクラスにて使用できない機能があった場合、「オプションの××が必要です」「この機種では対応していません」等のメッセージを操作パネル部６や端末２００に報知することも可能である。

〔画像形成装置１による一般アプリ実行処理〕
次に、図５を参照して、本発明の実施の形態に係る一般アプリ実行処理の詳細について説明する。
この例では、インストールされている一般アプリであるアプリ９６−１が実行される例を示す。一般アプリであるアプリ９６−１は、サービス９４−１と対応付けられている。このため、一般アプリであるアプリ９６−１は、サービス９４−１により他のアプリ９６−２〜９６−ｎと情報を共用可能である。
この一般アプリ実行処理も、主に制御部８が記憶部９に記憶されたプログラム等を各部と協働し、ハードウェア資源を用いて実行する。

（ステップＳ２０１）
まず、アプリ制御部８１は、情報共用制御部８３０を用いて、アプリ共用情報作成処理を行う。
アプリ制御部８１は、例えば、操作パネル部６や端末２００からのユーザーの指示を取得して、記憶部９にインストールされた一般アプリであるアプリ９６−１の実行を開始する。
この際、アプリ制御部８１は、アプリ９６−１の実行ファイルの実行の前に、プラットフォーム９２のＡＰＩによりサービスレジストリ９３を参照する。この例では、アプリ制御部８１は、一般アプリのアプリ９６−１のインストール時にサービスレジストリ９３に登録されたサービス９４−１を読み出す。
そして、アプリ制御部８１は、共用データ９５内に、共用する情報の領域である共用領域を確保する。この例では、サービス９４−１の管理情報に基づいて、サービス９４−１が他のサービス９４−２〜９４−ｎと共用するための共用領域を確保する。

（ステップＳ２０２）
次に、アプリ制御部８１は、情報共用制御部８３０を用い、アプリ実行処理を行う。
アプリ制御部８１は、アプリ９６−１の実行ファイルをＨＤＤ等から読み出し、ＲＡＭ等に展開して実行する。
この際、アプリ制御部８１は、共用データ９５内の共用領域を用いて、情報を共用させる。上述の例において、アプリ制御部８１は、サービス９４−１により確保された共用領域により、他のサービス９４−２〜９４−ｎとの間で情報を共用させる。アプリ制御部８１は、アプリ９６−１が実行したジョブの状況、アプリ９６−１やサービス９４−１により記憶部９に確保された又は使用された記憶領域のサイズ、共用領域のサイズ等のリソース（資源）、アプリ９６−１から呼び出されたサービス９４−１のクラスのログ等の情報を共用させることが可能である。また、アプリ制御部８１は、この共用された情報によって、下記で示すように、アプリ９６−１の不正な処理を、管理アプリに管理、監視させることが可能になる。
また、アプリ制御部８１は、アプリ９６−１により画像形成装置１の機能を使用するクラスが呼び出された場合、サービス９４−１を用いてこの機能を使用させることが可能である。この場合、アプリ制御部８１は、サービス９４−１により機器設定９１を読み出して、使用可能な機能を選択して処理する。
以上により、本発明の実施の形態に係る一般アプリ実行処理を終了する。

〔画像形成装置１による管理アプリ実行処理〕
次に、図６を参照して、本発明の実施の形態に係る画像形成装置１による管理アプリ実行処理の詳細について説明する。
この例では、管理アプリであるアプリ９６−２が実行される例を示す。この管理アプリ実行処理では、アプリ９６−２が、管理用のサービス９４−２により、共用される情報を提供している一般アプリであるアプリ９６−１を管理、監視する。アプリ９６−２は、工場出荷時に画像形成装置１にインストールされていても、後から「ウィルス検知ソフト」のように後からインストールされてもよい。
この画像形成装置１による管理アプリ実行処理も、主に制御部８が記憶部９に記憶されたプログラム等を各部と協働し、ハードウェア資源を用いて実行する。

（ステップＳ２１１）
まず、アプリ制御部８１は、アプリ管理部８４０を用いて、アプリ管理用情報取得処理を行う。
アプリ制御部８１は、管理アプリにより一般アプリの情報を取得する。この例では、アプリ制御部８１は、管理アプリであるアプリ９６−２により、他の一般アプリであるアプリ９６−１及び９６−３〜９６−ｎ（他のアプリ９６）を監視する。この際、アプリ制御部８１は、アプリ９６−２に対応付けられたサービス９４−２により、サービス９４−１及び９４−３〜９４−ｎ（他のサービス）により確保された共用領域を参照して、共有された情報を取得する。
アプリ制御部８１は、共用データ９５内に、アプリ９６に対応付けられたサービス９４により共有領域が確保され、共用された情報が読み取り可能になった場合、これを参照する。上述の例では、アプリ制御部８１は、例えば、管理アプリであるアプリ９６−２に対応付けられたサービス９４−２により、アプリ９６−１に対応付けられたサービス９４−１により共用された情報を参照する。また、アプリ制御部８１は、他のサービス９４の管理情報を読み出したり、書き換えたりすることも可能である。
アプリ制御部８１は、このような共用された情報や管理情報により、一般アプリである他のアプリ９６を監視する。アプリ制御部８１は、他のアプリ９６の状況によって、共用領域を含む記憶部９の記憶領域の容量の調整や解放や取得、プロセスの実行時間や順番等の調整や配分等を行う。
また、アプリ制御部８１は、アプリ９６−２により不正アプリの判定を行ってもよい。アプリ制御部８１は、所定のヒューリスティックな判定基準に従って、一般アプリである他のアプリ９６が、不正な処理を行っているか否かについても監視する。アプリ制御部８１は、例えば、一般アプリであるアプリ９６−１が、共有された情報のリソースやクラスのログ等により、バッファオーバーランのような不正なメモリ操作による攻撃を行った、アカウント情報９０や印刷データをネットワーク１００から不正に送信した、といった何らかの悪意行為を行った場合、不正な処理であると判断する。

（ステップＳ２１２）
次に、アプリ制御部８１は、アプリ管理部８４０を用いて、一般アプリの管理が必要か否かを判定する。アプリ制御部８１は、例えば、管理アプリであるアプリ９６−２の判定により、他の一般アプリであるアプリ９６−１が不正な処理を行っていたと判断した場合には、Ｙｅｓと判定する。それ以外の場合、アプリ制御部８１は、Ｎｏと判定する。
Ｙｅｓの場合、アプリ制御部８１は、処理をステップＳ２１３に進める。
Ｎｏの場合、アプリ制御部８１は、管理アプリ実行処理を終了する。

（ステップＳ２１３）
アプリ制御部８１は、アプリ管理部８４０を用いて、一般アプリであるアプリ９６が不正な処理を行っていた場合、一般アプリ管理処理を行う。
アプリ制御部８１は、管理アプリにより、一般アプリのサービス９４の共用領域等を調整したり、サービス９４の利用権限を許可したり不許可にしたりする。アプリ制御部８１は、例えば、一般アプリであるアプリ９６−１が不正な処理を行っていた場合、管理アプリであるアプリ９６−２により、アプリ９６−１がサービス９４−１を利用できないようにアプリ９６−１の管理情報を書き換えて、アクセスのブロック等を行う。この場合、アプリ制御部８１は、アプリ９６−１に例外を発生させる等により、アプリ９６−１に通知することも可能である。
また、アプリ制御部８１は、不正な処理を行っていた一般アプリ９６自体の実行を停止したり、ログを記憶部９に書き込んだり、管理者にメール送信したりすることも可能である。
以上により、本発明の実施の形態に係る管理アプリ実行処理を終了する。

なお、情報の共用や通信等の機能を利用しない場合、アプリ９６は、サービス９４を使用しないで実行することも可能である。
しかしながら、対応付けされたサービス９４がないと、アプリ９６が起動しないように構成することも可能である。

〔画像形成装置１によるアプリアンインストール処理〕
次に、図７を参照して、本発明の実施の形態に係るアプリアンインストール処理の詳細について説明する。
アプリ制御部８１は、アプリ９６をアンインストールする際に、サービス９４の依存関係を考慮した上でアンインストールを行う。この際に、アプリ９６とサービス９４との対応付けも変更する。以下では、アプリ９６−１をアンインストールする例について説明する。
画像形成装置１によるアプリアンインストール処理も、主に制御部８が記憶部９に記憶されたプログラム等を各部と協働し、ハードウェア資源を用いて実行する。

（ステップＳ３０１）
まず、アプリ制御部８１は、サービス登録部８２０を用いて、サービス依存関係検索処理を行う。
アプリ制御部８１は、インストールされている他のアプリ９６の必要クラス情報を読み出して、アンインストールするアプリ９６に対応付けられたサービス９４も削除して良いか否かについて検索する。たとえば、アプリ制御部８１は、アプリ９６−１をアンインストールする場合、サービス９４−１が他のアプリ９６−２〜９６−ｎでも使用されるか否かを検索する。

（ステップＳ３０２）
次に、アプリ制御部８１は、サービス登録部８２０を用いて、依存関係があったか否かを判定する。アプリ制御部８１は、他のアプリ９６でもサービス９４が使用されていた場合、依存関係ありとして、Ｙｅｓと判定する。上述の例では、サービス９４−１が他のアプリ９６−２〜９６−ｎのいずれかでも使用される場合、Ｙｅｓと判定する。アプリ制御部８１は、それ以外の場合は、依存関係なしとして、Ｎｏと判定する。
Ｙｅｓの場合、アプリ制御部８１は、処理をステップＳ３０３に進める。
Ｎｏの場合、アプリ制御部８１は、処理をステップＳ３０４に進める。

（ステップＳ３０３）
依存関係があった場合、アプリ制御部８１は、サービス登録部８２０を用いて、依存関係解消処理を行う。
アプリ制御部８１は、サービス９４の依存関係があった場合には、プラットフォーム９２のＡＰＩにより、依存関係があったサービス９４を残し、管理情報のみ書き換える。
たとえば、アプリ９６−１をアンインストールする際に、アプリ９６−３もサービス９４−１を使用しており、依存関係がある場合、アプリ制御部８１は、サービス９４−１の管理情報からアプリ９６−１の対応付けのみ削除して、アプリ９６−３がサービス９４−１をそのまま利用可能にする。
これにより、依存関係があるサービス９４があった場合でも、アプリ９６のアンインストール時に意識することなく、他のアプリ９６を利用し続けることが可能となる。
その後、アプリ制御部８１は、処理をステップＳ３０５に進める。

（ステップＳ３０４）
依存関係がなかった場合、アプリ制御部８１は、サービス登録部８２０を用いて、サービス削除処理を行う。
アプリ制御部８１は、プラットフォーム９２のＡＰＩにより、アンインストールするアプリ９６に対応付けられたサービス９４をサービスレジストリ９３から削除する。上述の例では、アンインストールするのがアプリ９６−１の場合、アプリ制御部８１は、サービス９４−１を削除する。
その後、アプリ制御部８１は、処理をステップＳ３０５に進める。

（ステップＳ３０５）
ここで、アプリ制御部８１は、サービス登録部８２０を用いて、アプリ削除処理を行う。
アプリ制御部８１は、プラットフォーム９２のＡＰＩにより、アプリ９６を記憶部９から削除し、登録情報も削除する。
また、この際、アプリ制御部８１は、サービス９４を残したか否かをサーバ３００に送信してもよい。サーバ３００は、その旨を記憶手段にログとして記録することが可能である。
以上により、本発明の実施の形態に係るアプリアンインストール処理を終了する。

〔端末２００とサーバ３００とによるアプリ開発処理〕
次に、図８と図９とを参照して、本発明の実施の形態に係るアプリ開発処理の詳細について説明する。
図８には、図２の端末２００、サーバ３００の概略構成を示すブロック図が示されている。下記で、端末２００、サーバ３００により、アプリ９６を開発する例を示す。
以下で、まず、このアプリ開発に必要な端末２００とサーバ３００の構成について説明する。

｛端末２００の制御構成｝
端末２００は、ユーザーのＰＣ（Personal Computer）やスマートフォン等である。また、端末２００は、制御手段や記憶手段や入力手段や表示手段やネットワーク入出力手段等のハードウェア資源を備えている。
端末２００は、画像形成装置１で実行可能なアプリ９６を作成するためのＳＤＫ（Software Development Kit）がインストールされている。
端末２００は、機能ブロックとして、アプリ開発部２１０（アプリケーション開発手段）及びアプリインストール部２２０（インストール手段）を備えている。

アプリ開発部２１０は、プラットフォーム９２用のＳＤＫを実行し、アプリ９６−１〜９６−ｎを作成するための手段である。
アプリ開発部２１０は、プラットフォーム９２用のアプリ９６のソースコードを作成し、ソースコードデバッガ等によりデバッグし、コンパイル等を行って実行ファイルを作成可能である。また、アプリ開発部２１０は、クラス情報を作成して、これをアプリ９６に含めることが可能である。また、アプリ開発部２１０は、所定の命名規則に従ったサービス９４用のクラスを作成することも可能である。また、アプリ開発部２１０は、既にサーバ３００のサービスＤＢ３１０に格納されている「作成済み」のクラスについても、クラスのカタログにより、クラスファイル９７−１〜９７−ｎを参照して、閲覧することが可能である。

アプリインストール部２２０は、記憶手段に記憶されたアプリ９６−１〜９６−ｎにより、画像形成装置１にアプリ９６−１〜９６−ｎのリモートインストールを行うための手段である。
アプリインストール部２２０は、リモートインストールの際、図示しない外部記録媒体に記憶されたアプリ９６−１〜９６−ｎを読み取って、端末２００の記憶手段に記憶し、又、読み取られたアプリ９６−１〜９６−ｎを、ネットワーク１００を介して画像形成装置１に送信する。

また、端末２００は、画像形成装置１に対して、印刷、スキャン、リモートスキャン、ファクシミリ送受信等のジョブの指示を行うことも可能である、

｛サーバ３００の制御構成｝
サーバ３００は、ＰＣ／ＡＴ互換機サーバやクラウド上のサーバである。
サーバ３００は、ユーザーがＳＤＫで作成したアプリ９６を端末２００から取得し、このアプリ９６で利用するためのサービス９４を作成する。
サーバ３００は、サービスＤＢ３１０（サービスデータベース）、アプリ取得部３２０（アプリケーション取得手段）、サービス作成部３３０（サービス作成手段）を備えている。

サービスＤＢ３１０は、画像形成装置１で実行可能なサービスのクラスファイル９７−１〜９７−ｎを格納するデータベースである。
クラスファイル９７−１〜９７−ｎは、例えば、機能別に分類されたサービスのクラスのソースファイル、パッケージファイル、オブジェクト（object）ファイル、実行可能ファイル等である。クラスファイル９７−１〜９７−ｎには、機能別に、例えば、プラットフォーム９２のＡＰＩを利用したログ出力、ＸＭＬ分析、ＨＴＴＰ通信等のクラスが、それぞれ含まれている。また、クラスファイル９７−１〜９７−ｎには、例えば、機能別に、アプリ９６−１〜９６−ｎから呼び出されるクラス識別子、インクルードパス、パッケージパス、サービスを実行するためのリンク等も含まれている。このクラス識別子等は、所定の命名規則で作成されているため、開発時に重複する機能のクラスを作成するのを防ぐことができ、開発負担を軽減可能となる。クラスファイル９７−１〜９７−ｎは、サーバ３００の管理者がチェックして重複や不具合（バグ）がないことを確認可能である。
また、サービスＤＢ３１０は、クラスファイル９７−１〜９７−ｎに含まれるクラスのパッケージ名や呼び出し可能なクラスの識別名やヘルプ等の情報であるカタログも格納されている。このカタログは、端末２００等にインストールされたＳＤＫから参照可能である。
以下で、クラスファイル９７−１〜９７−ｎのいずれか一つを示す場合には、単にクラスファイル９７という。

アプリ取得部３２０は、端末２００でアプリ９６−１〜９６−ｎを作成した際に、当該アプリ９６−１〜９６−ｎのクラス情報を取得する。この際、アプリ取得部３２０は、アプリ９６−１〜９６−ｎのクラス情報だけでなく、ソースファイルや実行ファイル等も取得可能である。
なお、アプリ取得部３２０は、アプリ９６−１〜９６−ｎが画像形成装置１にインストールされる際にも、アプリ９６−１〜９６−ｎのクラス情報を取得可能である。

サービス作成部３３０は、アプリ９６−１〜９６−ｎのクラス情報に含まれている、クラスの情報に基づいて、機能単位でサービスＤＢ３１０からクラスファイル９７−１〜９７−ｎを検索する。サービス作成部３３０は、サービスのクラスファイル９７−１〜９７−ｎが検索された場合、これを基にサービス９４−１〜９４−ｎを作成する。
また、サービス作成部３３０は、作成したサービス９４−１〜９４−ｎを再利用可能な形式のサービスのクラスファイル９７−１〜９７−ｎとして、サービスＤＢ３１０に保存しておくことも可能である。
また、サービス作成部３３０は、アプリ９６−１〜９６−ｎに対応付けられたサービス９４−１〜９４−ｎを画像形成装置１や端末２００に送信することも可能である。

サービス作成部３３０は、ＨＤＤやフラッシュメモリ等の記憶手段に記憶されたプログラムをＣＰＵ等の制御手段が実行することで実現可能である。
サービスＤＢ３１０は、サーバ３００の制御手段が実行するＳＱＬ等の各種データベースサーバにより、データを記憶手段に格納し読み出すことで実現可能である。
なお、サーバ３００は、開発ユーザーの権限を示す開発アカウントが記憶されたデータベースを備えていてもよい。

｛アプリ開発処理の詳細｝
次に、図９のフローチャートを参照して、端末２００とサーバ３００とによるアプリ開発処理の詳細について説明する。
このアプリ開発処理は、端末２００及びサーバ３００のそれぞれで、制御手段が記憶手段に記憶されたプログラム等を各部と協働し、ハードウェア資源を用いて実行する。

（ステップＳ４０１）
まず、端末２００のアプリ開発部２１０は、アプリ送付処理を行う。
アプリ開発部２１０は、サービス９４が必要な場合、ユーザーがＳＤＫで作成したアプリ９６の実行ファイル及び／又はソースファイルを、サーバ３００に送信する。この際、アプリ開発部２１０は、アプリ９６にクラス情報を付加して送信する。
なお、この際、アプリ開発部２１０は、開発アカウント等でサーバ３００にユーザーをログインさせてもよい。

（ステップＳ４０２）
次に、サーバ３００のアプリ取得部３２０は、サービス取得処理を行う。
アプリ取得部３２０は、ネットワーク１００を介して、端末２００からアプリ９６の実行ファイル及び／又はソースファイルを取得する。サービス作成部３３０は、この取得されたアプリ９６を、一旦、記憶手段に格納し、クラス情報を抽出する。

（ステップＳ４０３）
次に、サーバ３００のサービス作成部３３０は、サービス作成処理を行う。
サービス作成部３３０は、アプリ９６のクラス情報から、アプリ９６が呼び出す機能を特定し、必要なクラスを特定する。そして、サービス作成部３３０は、サービスＤＢ３１０から、この必要なクラスが含まれるクラスファイル９７を、アプリ９６が呼び出す機能に基づいて検索する。この際、サービス作成部３３０は、開発アカウントのユーザーの所属別や権限別でクラスファイル９７を検索することも可能である。
サービス作成部３３０は、クラスファイル９７が検索された場合、これをまとめてサービス９４を作成し、作成したサービス９４を端末２００に送信する。この送信されたサービス９４は、画像形成装置１での動作確認の際にのみ用いられるように管理情報に記載することも可能である。

ここで、サーバ３００のサービス作成部３３０は、サービスＤＢ３１０からクラスファイル９７が検索できなかった場合、アプリ９６自体に呼び出す機能に基づいたクラスが含まれているか否かを判断する。
サービス作成部３３０は、アプリ９６自体にクラスが含まれている場合、クラスファイル９７の候補としてサービスＤＢ３１０に格納する。このクラスファイル９７の候補は、サーバ３００の管理者ユーザーがチェック等可能である。
また、サービス作成部３３０は、サーバ３００の管理者ユーザー自体がクラスファイル９７を作成して、サービスＤＢ３１０に記憶することが可能である。
このような構成により、同じサービスや機能の重複開発を回避できる。
以上により、本発明の実施の形態に係るアプリ開発処理を終了する。

｛アプリインストール時のサービス作成｝
なお、サーバ３００のサービス作成部３３０は、アプリのインストール時に直接サービス９４を作成することも可能である。この場合、図４のステップＳ１０１において、アプリ９６のクラス情報を取得した際に、このクラス情報に基づいて、対応するサービス９４を作成する。

具体的に説明すると、まず、アプリ取得部３２０が上述の図９のステップＳ４０２のサービス取得処理と同様に、アプリ９６の少なくともクラス情報を取得する。
サーバ３００のサービス作成部３３０は、受信したアプリ９６のクラス情報に基づき、アプリ９６が呼び出す機能を特定して、実行時にサービス９４が必要か否かを判断する。サービス作成部３３０は、サービス９４が必要であると判断された場合には、その必要なクラスを特定する。
サービス作成部３３０は、サービス９４が必要であり、必要なクラスがある場合、サービスＤＢ３１０から、この必要なクラスが含まれるクラスファイル９７を、アプリ９６が呼び出す機能に基づいて検索する。
サービス作成部３３０は、サービスＤＢ３１０から検索されたクラスファイル９７があった場合、これをまとめてサービス９４を作成する。サービス作成部３３０は、作成したサービス９４を画像形成装置１に送信する。この際、サービス作成部３３０は、サービス９４の管理情報に、ログインされたユーザーのＩＤ等や作成日時等の個別情報を暗号化して付加してもよい。

なお、サービス作成部３３０は、クラス情報が不正であった場合、すなわちサービスＤＢ３１０からサービス９４が検索できなかった場合には、エラー情報を画像形成装置１に返す。
また、アプリ９６が不正な海賊版等であった場合には、エラー情報を返すのに加えて、サーバ３００の管理者にメール等で通知することも可能である。
また、サーバ３００のサービス作成部３３０は、サービス９４の作成時に、サーバ３００の記憶手段に記憶して、同一のアプリ９６のインストールの際に利用してもよい。

以上のように構成することで、以下のような効果を得ることができる。
本発明の画像形成装置１は、アプリ９６−１〜９６−ｎのインストール時に、アプリ９６−１〜９６−ｎのクラス情報を参照して、サービス９４−１〜９４−ｎをサーバ３００等から取得するサービス取得部８１０と、サービス取得部８１０により取得されたサービス９４−１〜９４−ｎを、アプリ９６−１〜９６−ｎそれぞれに対応付けしてサービスレジストリ９３に格納するサービス登録部８２０と、アプリ９６−１〜９６−ｎが実行される際に、サービス登録部８２０によりアプリ９６−１〜９６−ｎに対応付けされたサービス９４−１〜９４−ｎの管理情報に基づいて他のアプリ９６−１〜９６−ｎとの間で情報を共用させる情報共用制御部８３０とを備えることを特徴とする。
このように構成することで、ＯＳに標準で備えられた手段によらないで、アプリ９６間で情報の共用や通信が可能となる。この際、共用した情報は、アプリ９６間でしか使えない。また、正規にインストールされた画像形成装置用のアプリ９６以外の、例えばウェブブラウザ上で実行される不正なプログラムや、外部機器からは、サービス９４にアクセスできない。このため、セキュリティリスクを低減することが可能となる。
また、画像形成装置１は、サービス９４を取得してアプリ９６と対応付けして記憶する必要がある。つまり、サービス９４がなければ情報の共用が不可能となるため、セキュリティリスクを低下させられる。
さらに、アプリ９６間で、共用した情報に加えて、サービス９４の共用も可能となる。このため、記憶部９の記憶領域や制御部８で実行するプロセス数等のリソースを節約できる。
加えて、アプリ９６間で、サービス９４に含まれるクラスにより簡単に情報を共用することが可能であるため、他のアプリ９６との連携が必要なアプリ９６の開発を容易にすることができる。

また、本発明の実施の形態に係る画像形成装置１は、情報共用制御部８３０により共用された共用データ９５に基づいて、プリ９６−１〜９６−ｎによるサービス９４−１〜９４−ｎの利用権限を許可又は不許可にすることを特徴とする。
これにより、バックグラウンドで実行する管理アプリのアプリ９６で他の一般アプリを管理、監視をすることができる。つまり、管理アプリにより、一般アプリのサービス９４の利用権限を設定、削除できるため、何らかの悪意行為を発見、禁止できる。また、実行中のアプリ９６のリソースの調整や配分、自動管理が可能となる。
これにより、画像形成装置１のセキュリティリスクを低減させ、動作を安定化させられる。

また、本発明の実施の形態に係るサーバ３００は、画像形成装置１で実行可能なサービス９４−１〜９４−ｎのクラスを格納したクラスファイル９７−１〜９７−ｎを記憶するサービスＤＢ３１０と、画像形成装置１により実行されるアプリ９６−１〜９６−ｎを取得するアプリ取得部３２０と、取得されたアプリ９６−１〜９６−ｎが呼び出す機能に基づいてサービスＤＢ３１０を検索し、検索されたクラスファイル９７−１〜９７−ｎに基づいてアプリ９６−１〜９６−ｎが呼び出すサービス９４−１〜９４−ｎを作成するサービス作成部３３０とを備えることを特徴とする。
これにより、同じ機能のサービス９４の重複開発を回避し、開発を効率化することが可能となる。

また、画像形成装置１は、アプリ９６の少なくともクラス情報をサーバ３００に送信する。サーバ３００では、取得したアプリ９６のクラス情報を検証して、逐一、サービス９４を作成して送信する。
このため、ユーザーが海賊版や改造等された不正なアプリ９６を画像形成装置１にインストールしようとしても、サーバ３００により発見することが可能となり、不正なアプリ９６の流通を抑制することが可能となる。

なお、本発明は、画像形成装置以外の各種情報処理装置にも適用可能である。つまり、ネットワークスキャナ、スキャナーをＵＳＢ等で別途接続したサーバ等を用いるような構成であってもよい。また、アプリケーションをインストール可能な情報処理装置であるＰＣ、スマートフォン、携帯電話、オフィス機器、産業用機器等にも適用可能である。

なお、上記実施の形態の構成及び動作は例であって、本発明の趣旨を逸脱しない範囲で適宜変更して実行することができることは言うまでもない。

１ 画像形成装置
２ 原稿読取部
３ 原稿給送部
４ 本体部
５ スタックトレイ
６ 操作パネル部
７ 画像形成部
８ 制御部
９ 記憶部
１０ 画像処理部
１１ ＦＡＸ送受信部
１２ ネットワーク送受信部
２１ スキャナー
２２ プラテンガラス
２３ 原稿読取スリット
３１ 原稿載置部
３２ 原稿排出部
３３ 原稿搬送機構
４１ 排出口
４２ 給紙部
４３ 用紙搬送路
４４ 搬送ローラー
４５ 排出ローラー
７１ 感光体ドラム
７２ 露光部
７３ 現像部
７４ 転写部
７５ 定着部
８１ アプリ制御部
９０ アカウント情報
９１ 機器設定
９２ プラットフォーム
９３ サービスレジストリ
９４、９４−１〜９４−ｎ サービス
９５ 共用データ
９６、９６−１〜９６−ｎ アプリ
９７、９７−１〜９７−ｎ クラスファイル
１００ ネットワーク
２００ 端末
２１０ アプリ開発部
２２０ アプリインストール部
３００ サーバ
３１０ サービスＤＢ
３２０ アプリ取得部
３３０ サービス作成部
４２１ 給紙カセット
４２２ 給紙ローラー
８１０ サービス取得部
８２０ サービス登録部
８３０ 情報共用制御部
８４０ アプリ管理部

Claims (4)

1. 記憶手段に記憶された複数のアプリケーションを実行可能な画像形成装置において、
   前記記憶手段に記憶された前記アプリケーションから共用して呼び出し可能なサービスを取得するサービス取得手段と、
   該サービス取得手段により取得された前記サービスを、前記アプリケーションと対応付けして前記記憶手段に格納するサービス登録手段と、
   該サービス登録手段により対応付けされた前記サービスにより提供される情報を、前記記憶手段に格納された他の前記サービスとの間で共用させる情報共用制御手段とを備える
   ことを特徴とする画像形成装置。
2. 前記サービスは登録手段は、前記サービスを、前記記憶手段の保護された領域に格納する
   ことを特徴とする請求項１に記載の画像形成装置。
3. 前記情報共用制御手段により共用された情報により、不正な処理を行った前記アプリケーションによる前記サービスの利用権限を不許可にするアプリケーション管理手段を備える
   ことを特徴とする請求項１又は２に記載の画像形成装置。
4. 記憶手段に記憶された複数のアプリケーションを実行可能な画像形成装置により実行される画像形成方法において、
   前記記憶手段に記憶された前記アプリケーションから共用して呼び出し可能なサービスを取得し、
   取得された前記サービスを、前記アプリケーションと対応付けして前記記憶手段に格納し、
   対応付けされた前記サービスにより提供される情報を、前記記憶手段に格納された他の前記サービスとの間で共用させる
   ことを特徴とする画像形成方法。

Images