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

Abstract

拡張を容易にして開発コストを削減可能な画像形成装置を提供する。機器制御プラットフォーム（２００）は、ＯＳ（２３０）上でハードウェア資源を管理する。標準アプリサービスＩＦ部（１１０）は、標準アプリ実行部（１００）の外部から標準アプリ（１２０）の機能を利用するためのインターフェイスを提供する。プラットフォームサービスＩＦ部（２１０）は、機器制御プラットフォーム（２００）の外部からハードウェア資源を利用するためのインターフェイスを提供する。標準機能サービス（３１０）は、標準アプリサービスＩＦ部（１１０）に対応した標準アプリ（１２０）の機能を利用させる。拡張機能サービス（３２０）は、プラットフォームサービスＩＦ部（２１０）に対応したハードウェア資源を利用させる。拡張アプリ管理部（３４０）は、標準機能サービス（３１０）並びに拡張機能サービス（３２０）を呼び出し可能な拡張アプリを管理し実行する。

Description

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

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

特許文献１によれば、各アプリの共通部分をアプリサービス及び共通システムサービスとして括りだし、このアプリサービス、共通システムサービス、及び汎用ＯＳによってプラットフォームを形成し、該プラットフォーム上にプリンターアプリ、コピーアプリ、及び各種アプリを搭載する画像形成装置の技術が記載されている。

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

しかしながら、特許文献１の技術では、様々な顧客の要望に対応したカスタマイズ（個別化）に対応するのに手間がかかり、開発コストがかかるという問題があった。

本発明は、このような状況に鑑みてなされたものであって、上述の問題点を解消することを課題とする。

本発明の画像形成装置は、オペレーティングシステム上でハードウェア資源を管理する機器制御プラットフォームと、該機器制御プラットフォームで管理された前記ハードウェア資源を利用する標準アプリケーションを実行する標準アプリケーション実行部と、該標準アプリケーション実行部により実行される前記前記標準アプリケーションの機能を利用させる標準機能サービス、前記ハードウェア資源を利用させる拡張機能サービス、及び前記標準機能サービス並びに前記拡張機能サービスをそれぞれ呼び出し可能な拡張アプリケーションを管理し実行させる拡張アプリケーション管理部を含む拡張アプリケーションプラットフォームとを備えることを特徴とする。
本発明の画像形成装置は、前記拡張アプリケーションプラットフォームが、前記オペレーティングシステムに機能を追加するためのオペレーティングシステムインストールサービスを備えることを特徴とする。
本発明の画像形成方法は、ハードウェア資源を備えた画像形成装置により実行される画像形成方法であって、オペレーティングシステム上で前記ハードウェア資源を管理し、管理された前記ハードウェア資源を利用する標準アプリケーションを実行し、実行される前記標準アプリケーションの機能を利用させ、前記ハードウェア資源を利用させる拡張アプリケーションを管理し実行させることを特徴とする。

本発明によれば、階層化された拡張アプリケーションプラットフォームから、標準アプリケーション及びハードウェア資源のそれぞれを利用可能であるため、カスタマイズが容易となり開発コストを低減可能な画像形成装置を提供することができる。

第一実施形態に係る画像形成装置のシステム構成を示すブロック図である 図１に示す画像形成装置の制御構成を示すブロック図である。 本実施形態に係る拡張アプリ実行処理のフローチャートである。 図３に示す標準アプリ機能利用処理の概念図である。 図３に示す各部制御用サービス利用処理の概念図である。 図３に示す機能追加処理の概念図である。 第二実施形態に係る画像形成装置の制御構成を示すブロック図である。 図７に示す画像形成装置による画像処理を説明するものであって、例えばコピーアプリの標準機能を説明するための図である。 図８のコピーアプリの標準機能に、例えば原稿を継ぎ足し複数枚の原稿を読み込ませてコピーする機能を追加（拡張）した場合を説明するための図である。 第三実施形態に係るプラットフォームサービスＩＦ部及び各部制御用サービスの詳細な構成を示すブロック図である。 第三実施形態に係る各部機能呼び出し処理のフローチャートである。 図１１に示すコンポーネント呼び出し処理の概念図である。 図１１に示す代替コンポーネント選択処理の概念図である。 第四実施形態に係る画像形成装置による画像処理を説明するフローチャートであって、例えば送信アプリの標準機能を説明するための図である。 図１４の送信アプリの標準機能に、例えば送信した原稿を控えとして印刷する機能を追加（拡張）した場合を説明するためのフローチャートである。 第五実施形態に係る画像形成装置の制御構成を示すブロック図である。 第五実施形態に係るパネルアプリ実行処理のフローチャートである。 図１７に示すＩＦ経由標準アプリ実行処理の概念図である。 図１７に示す標準アプリ直接実行処理の概念図である。

＜第一実施形態＞
〔第一実施形態の画像形成装置１のシステム構成〕
次に、図１により、本発明の第一実施形態に係る画像形成装置１のシステム構成について説明する。画像形成装置１は、画像処理部１１、原稿読取部１２、原稿給送部１３、搬送部１４、ネットワーク送受信部１５、操作パネル部１６、画像形成部１７、ＦＡＸ送受信部１８、及び記憶部１９等が、制御部１０に接続されている。各部は、制御部１０によって動作制御される。

制御部１０は、ＧＰＰ（General Purpose Processor）、ＣＰＵ（Central Processing Unit、中央処理装置）、ＭＰＵ（Micro Processing Unit）、ＤＳＰ（Digital Signal Processor）、ＧＰＵ（Graphics Processing Unit）、ＡＳＩＣ（Application Specific Processor、特定用途向けプロセッサー）等の情報処理部である。
制御部１０は、記憶部１９のＲＯＭやＨＤＤに記憶されている制御プログラムを読み出して、この制御プログラムをＲＡＭに展開させて実行することで、後述する機能ブロックの各部として動作させられる。また、制御部１０は、図示しない外部の端末や操作パネル部１６から入力された指示情報に応じて、装置全体の制御を行う。

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

原稿読取部１２は、セットされた原稿を読み取る（スキャン）。
原稿給送部１３は、原稿読取部１２で読み取られる原稿を搬送する。
搬送部１４は、給紙カセットから記録紙を搬送し、画像形成部１７で画像形成させ、その後にスタックトレイへ搬送する。
画像形成部１７は、ユーザーの出力指示により、記憶部１９に記憶され、原稿読取部１２で読み取られ、又は外部の端末から取得されたデータから記録紙への画像形成を行わせる。

ネットワーク送受信部１５は、ＬＡＮ、無線ＬＡＮ、ＷＡＮ、携帯電話網等の外部ネットワークに接続するためのＬＡＮボードや無線送受信機等を含むネットワーク接続部である。
ネットワーク送受信部１５は、データ通信用の回線ではデータを送受信し、音声電話回線では音声信号を送受信する。
ネットワーク送受信部１５は、ネットワークを介して、図示しないＰＣ（Personal Computer）やスマートフォンやＰＤＡ（Personal Data Assistant）や携帯電話等の外部の端末、サーバー等に接続されていてもよい。

操作パネル部１６は、ユーザーの指示を取得し、各種情報を表示する。
操作パネル部１６は、ユーザーの指示を取得する。このユーザーの指示は、後述する拡張アプリ４００（図２）（Application Software、アプリケーション）のインストールや使用の指示を含む。また、ユーザーの指示により、各ユーザーの情報を入力、変更することも可能である。このため、操作パネル部１６は、専用の制御部とＲＯＭやＲＡＭ等の記憶媒体を備えて、制御部１０と連携してＧＵＩ（Graphical User Interface）の制御を行ってもよい。拡張アプリ４００のインストールや使用時の操作パネル部１６の制御の詳細については後述する。
また、操作パネル部１６には、ＵＳＢメモリーやフラッシュメモリーカードの記憶媒体や記憶媒体を内蔵した外部機器を接続するための接続部が備えられていてもよい。

また、操作パネル部１６は、入力部２０と、表示部２１とを備えている。
入力部２０は、タッチパネルやボタン等によりユーザーの指示を取得する。入力部２０のボタンは、スタートキー、キャンセルキー、テンキーを含んでいてもよい。また、入力部２０のボタンは、コピー（複写）、ＦＡＸ送信、スキャナー等の動作モードの切り換えのボタン、選択された文書の印刷、送信、記録等に関するジョブの実行に係る指示のボタンを含んでいてもよい。また、入力部２０のタッチパネルは、抵抗膜方式や静電容量方式により、ユーザーが押下した座標や押圧等を検出してもよい。また、入力部２０は、表示部２１と一体的に形成されていてもよい。この場合、入力部２０は表示部２１上の座標を検出してもよい。また、タッチパネルがマルチタッチ対応の場合には、複数の座標や押圧等を検出してもよい。入力部２０は、静電容量方式のタッチパネルの場合、所定距離だけ離れた位置でも、ユーザーの指等を動かしたことを検知してもよい。また、入力部２０は、ユーザーの指等の移動による指示であるジェスチャー（gesture）による指示を取得してもよい。
入力部２０により入力されたユーザーの指示は、後述するパネルアプリ５２０（図２）や標準アプリ１２０や拡張アプリ４００のインストールや呼び出し等の指示を含む。また、ユーザーの指示により、各ユーザーの情報を入力、変更することも可能である。

表示部２１は、ＬＣＤ（Liquid Crystal Display）、ＯＥＬ（Organic Electro-Luminescence）、ＦＥＤ（Field Emission Display）等の平面ディスプレイパネル、プロジェクタ、ステータス表示用ＬＥＤ等である。入力部２０と表示部２１とが、一体的に形成されている場合、表示部２１は、上述の入力部２０のボタンを、いわゆる「ソフトウェアボタン」として表示してもよい。
表示部２１は、専用のブラウザー等で描画されたＧＵＩの各種画面を表示する。また、表示部２１は、記憶部１９（図２参照）に記憶された画像等も表示可能である。

ＦＡＸ送受信部１８は、ファクシミリの送受信を行うＦＡＸボード等である。
ＦＡＸ送受信部１８は、原稿読取部１２で読み取られた画像データやネットワーク送受信部１５から受信したファイル等を描画してファクシミリ送信する。また、ＦＡＸ送受信部１８は、記憶部１９に記憶され、ファクシミリ受信された画像データを画像形成部１７で画像形成させ、ネットワーク送受信部１５から外部の端末へ送信する。

記憶部１９は、ＲＯＭ（Read Only Memory）、ＲＡＭ（Random Access Memory）、フラッシュメモリー等の半導体メモリーやＨＤＤ（Hard Disk Drive）等の記憶媒体と、このコントローラー等を含む。
記憶部１９のＲＯＭやフラッシュメモリーやＨＤＤには、画像形成装置１の動作制御を行うための制御プログラム及びデータが記憶されている。これらの制御プログラム及びデータは、ファームウェアのような形式で提供されていてもよい。また、これらの制御プログラムとデータとは、実行時にＲＡＭ等に展開されて、制御部１０により実行される。
また、記憶部１９は、各種ジョブデータ、原稿読取部１２でスキャンされた画像データ、画像処理部１１で画像処理された画像データ、他の端末（図示せず）から送信された印刷文書等のファイル、接続された記憶媒体から読み出された各種ファイル、サムネイル画像のデータ等を記憶してもよい。
また、記憶部１９は、ユーザーのアカウント設定も記憶してもよい。また、記憶部１９には、ユーザー毎の文書ボックスの領域が含まれていてもよい。

なお、画像形成装置１において、制御部１０及び画像処理部１１は、ＧＰＵ内蔵ＣＰＵ等やチップ・オン・モジュールパッケージのように、一体的に形成されていてもよい。
また、制御部１０及び画像処理部１１は、ＲＡＭやＲＯＭやフラッシュメモリー等を内蔵していてもよい。

〔画像形成装置１の制御構成〕
次に、図２により、画像形成装置１の制御構成について説明する。
画像形成装置１は、三つの階層的なブロック構造として、制御部１０の回路上で、標準アプリ実行部１００（標準アプリケーション実行部）、機器制御プラットフォーム２００、拡張アプリプラットフォーム３００（拡張アプリケーションプラットフォーム）があり、拡張アプリプラットフォーム３００上で拡張アプリ４００が実行される構成となっている。制御部１０が本発明の制御プログラムを実行することにより、標準アプリ実行部１００、機器制御プラットフォーム２００、拡張アプリプラットフォーム３００が実現される。更に、制御部１０は、図２に示す制御構成に基づいて、拡張アプリ４００、標準アプリ１２０、ＯＳ２３０を実行することができる。

標準アプリ実行部１００は、機器制御プラットフォーム２００で管理されたハードウェア資源を利用する標準アプリ１２０を実行する。標準アプリ実行部１００は、機器制御プラットフォーム２００上にインストールされた標準アプリ１２０と、この標準アプリ１２０に対応するサービスを備えている。

機器制御プラットフォーム２００は、ＯＳ２３０（Operating System、オペレーティングシステム）上で、画像形成装置１全体のハードウェア資源を管理し、機能単位で各部を制御する。
機器制御プラットフォーム２００は、標準アプリ１２０の実行基盤となるＡＰＩ（Application Programming Interface）やミドルウェアやランタイムやリンカー等（以下、「ＡＰＩ等」という。）、ＯＳ２３０上のサービス（Service、Daemon、以下「サービス等」という。）、スクリプト言語や中間言語の翻訳や実行を行うインタプリター（Interpreter）やＪＩＴ（Just In Time compiler）やバーチャルマシン等（以下、「バーチャルマシン等」という。）を含むプログラムやデータである。また、拡張アプリプラットフォーム３００自体も、ＯＳ２３０上で動作している。

拡張アプリプラットフォーム３００は、標準アプリ１２０を呼び出して機能を利用し、機器制御プラットフォーム２００を呼び出してハードウェア資源を利用し、拡張アプリ４００を管理し実行させる。
拡張アプリプラットフォーム３００は、拡張アプリ４００の実行基盤となるＡＰＩ等やサービス等やバーチャルマシン等を含むプログラムやデータである。また、拡張アプリプラットフォーム３００自体も、ＯＳ２３０上で動作している。

拡張アプリ４００は、拡張アプリプラットフォーム３００上で各種処理を行うアプリのプログラム及びデータである。

より詳しく説明すると、標準アプリ実行部１００は、標準アプリ１２０、及び標準アプリサービスＩＦ部１１０（標準アプリケーションサービスインターフェイス部）を備えている。

標準アプリ１２０は、機器制御プラットフォーム２００上で各種処理を行うアプリのプログラム及びデータである。
標準アプリ１２０は、ユーザーの指示を取得し、このユーザーの指示により画像形成装置の各種機能を利用する。また、標準アプリ１２０は、例えば、Ｊａｖａ（登録商標）等の中間言語のアプリや、各種スクリプト言語等で記載されていてもよい。

標準アプリ１２０は、例えば、コピーアプリ１２１、プリンターアプリ１２２、ＦＡＸアプリ１２３等が、工場出荷状態で既にインストールされていてもよい。
コピーアプリ１２１は、操作パネル部１６からのユーザーによるコピーの指示を取得すると、原稿読取部１２から原稿を読み取って、画像形成部１７により画像形成させる。
プリンターアプリ１２２は、外部の端末（図示せず）からの指示等により、ネットワーク送受信部１５で受信したＰＤＬ（Page Description Language）等のファイルを描画して、画像形成部１７により画像形成させる。また、プリンターアプリ１２２は、操作パネル部１６によるユーザーの指示により、記憶部１９の文書ボックス内のファイル等を描画して、画像形成部１７により画像形成させてもよい。
ＦＡＸアプリ１２３は、ユーザーの操作パネル部１６からのファクシミリ送信の指示を取得すると、原稿読取部１２から原稿を読み取って、ＦＡＸ送受信部１８によりファクシミリ送信する。また、ＦＡＸアプリ１２３は、外部の端末から受信したファイル等を描画して、ＦＡＸ送受信部１８により送信してもよい。また、ＦＡＸアプリ１２３は、ＦＡＸ送受信部１８により受信されたファクシミリの画像データを、画像形成部１７により画像形成させる。また、ＦＡＸアプリ１２３は、受信されたファクシミリの画像データを記憶部１９の文書ボックスに記憶してもよい。
なお、画像形成装置１の使用開始後に標準アプリ１２０がインストールされてもよい。つまり、例えば、ＦＡＸ送受信部のＦＡＸボードが取り付けられた際に、ＦＡＸアプリ１２３がインストールされる等の処理が行われてもよい。
また、ハードウェアの構成に関わらず、独自の標準アプリ１２０をユーザーがインストールすることも可能である。

標準アプリサービスＩＦ部１１０は、標準アプリ実行部１００の外部から標準アプリ１２０の機能を利用するためのインターフェイスを提供する。
標準アプリサービスＩＦ部１１０は、例えば、Ｊａｖａ（登録商標）等のクラス、Ｊａｖａ（登録商標）言語上のインターフェイス、ルーチン、関数、ヘッダーファイル、オブジェクト、ライブラリー等として提供されていてもよい。また、標準アプリサービスＩＦ部１１０は、ＯＳ２３０上のサービス等として提供されていてもよい。また、標準アプリサービスＩＦ部１１０は、標準アプリ１２０毎に異なるインターフェイスを提供していてもよい。
また、標準アプリサービスＩＦ部１１０は、標準アプリ１２０を呼び出して実行、インストール、設定の変更、削除等を行うことも可能である。

機器制御プラットフォーム２００は、プラットフォームサービスＩＦ部２１０（プラットフォームサービスインターフェイス部）、各部制御用サービス２２０、及びＯＳ２３０を備えている。

プラットフォームサービスＩＦ部２１０は、機器制御プラットフォーム２００の外部からハードウェア資源を利用するためのインターフェイスを提供する。
プラットフォームサービスＩＦ部２１０は、各部制御用サービス２２０を呼び出して、画像形成装置１の各部のハードウェア資源を利用させる。プラットフォームサービスＩＦ部２１０は、例えば、ＡＰＩ等、又はＯＳ２３０上のサービス等として提供されていてもよい。また、プラットフォームサービスＩＦ部２１０は、Ｃ言語の構造体、Ｃ＋＋言語のクラス、その他のオブジェクト、ルーチン、関数、ヘッダーファイル、オブジェクト、ライブラリー等（以下、「クラス等」という。）として提供されていてもよい。また、プラットフォームサービスＩＦ部２１０は、例えば、Ｊａｖａ（登録商標）等の中間言語で提供されていてもよい。

各部制御用サービス２２０は、画像形成装置１の機能に対応する各部を適切な方式で制御するサービス等である。
各部制御用サービス２２０は、例えば、プラットフォームサービスＩＦ部２１０からの呼び出しに対応して、画像処理部１１、操作パネル部１６、ネットワーク送受信部１５等を操作する。また、各部制御用サービス２２０は、コピー機能、ネットワークスキャン機能、文書ボックス機能等を呼び出すことができる。
また、各部制御用サービス２２０は、製品系列別に、異なるサービス等、ＡＰＩ等、クラス等を組み合わせたものがファームウェアに含まれていてもよい。

各部制御用サービス２２０は、画像処理機能サービス２２１、デバイス操作サービス２２２、及びネットワーク通信サービス２２３を含んでいる。

画像処理機能サービス２２１は、画像処理のデータの作成や変換や出力に関するサービスを提供する。画像処理機能サービス２２１は、例えば、原稿読取部１２で解像度や色等を設定して原稿読取した画像データを記憶部１９に記憶させ、画像処理部１１に記憶部１９の画像データや文書データ（図示せず）を画像処理させる。また、画像処理機能サービス２２１は、ファイル等から、画像形成部１７で画像形成する画像データを描画する。

デバイス操作サービス２２２は、各部のデバイスを制御するためのサービス等を提供する。デバイス操作サービス２２２は、例えば、原稿読取部１２から取得した画像データを記憶部１９に記憶し、操作パネル部１６の表示部２１に表示されるブラウザー上に画像を描画し、描画された画像データを画像形成部１７に送信して画像形成させ、記憶部１９に記憶された画像データをＦＡＸ送受信部１８でファクシミリ送信させる。
また、デバイス操作サービス２２２は、画像形成装置１にオプション機器、例えばフィニッシャーが存在した場合は製本やステープル等、ＩＣカードや生体認証によるユーザー認証部が存在した場合は当該ユーザー認証部によるユーザー認証、カメラが存在した場合はカメラ画像の取得や視線検出等の各機能を呼び出すことも可能である。また、デバイス操作サービス２２２は、例えば搬送部のモーターの一つを駆動させるといった、より機器のハードウェアの構成に近い制御を行ってもよい。また、デバイス操作サービス２２２は、各部の状態の取得等の処理も行ってもよい。

ネットワーク通信サービス２２３は、ネットワークの送受信に関するサービス等を提供する。ネットワーク通信サービス２２３は、例えば、ネットワーク送受信部１５（図１）から、ＴＣＰ／ＩＰやＵＤＰの各種プロトコルにより、他の画像形成装置（図示せず）やサーバーや端末等の間でファイル等の送受信を行う。たとえば、ネットワーク通信サービス２２３は、スキャンした画像データ、文書ボックスのファイル等を送受信することも可能である。なお、ネットワーク通信サービス２２３は、ＦＡＸ送受信部１８によるファクシミリ送受信の画像データの送受信、ユーザー認証部が存在した場合はユーザー認証結果、カメラが存在した場合は映像データの送受信等を行うことも可能である。また、ネットワーク通信サービス２２３は、画像形成装置１の各部の状態、各部の機能の呼び出しの結果等についても、送受信可能である。

ＯＳ２３０は、画像形成装置１の各部を制御する。ＯＳ２３０としては、例えば、Ｌｉｎｕｘ（登録商標）等の汎用ＯＳ、組み込み（Embedded）向けのＯＳ、リアルタイムＯＳ等を使用することができる。また、ＯＳ２３０のカーネルやコア等のスケジュール管理や基本ハードウェアを管理するプログラムやデータ等はファームウェアに含まれていてもよい。また、ＯＳ２３０は、別途、デバイスドライバーやスクリプト等の制御プログラムを追加可能であってもよい。このデバイスドライバーは、パフォーマンスを重視した言語であるＣ言語、Ｃ＋＋言語、アセンブラ言語等で作成されていてもよい。

拡張アプリプラットフォーム３００は、標準機能サービス３１０、拡張機能サービス３２０、ＯＳインストールサービス３３０（オペレーティングシステムインストールサービス）、及び拡張アプリ管理部３４０（拡張アプリケーション管理部）を備えている。

標準機能サービス３１０は、標準アプリサービスＩＦ部１１０に対応した標準アプリ１２０の機能を利用させるサービス等である。
標準機能サービス３１０は、拡張アプリ４００からの各標準アプリ１２０の各機能を指定した呼び出しを受け、標準アプリサービスＩＦ部１１０に送信して、当該標準アプリ１２０の当該機能を実行させる。

拡張機能サービス３２０は、プラットフォームサービスＩＦ部２１０に対応したハードウェア資源を利用させるサービス等である。
拡張機能サービス３２０は、拡張アプリ４００からの画像形成装置１の各部の機能を指定した呼び出しを受け、プラットフォームサービスＩＦ部２１０に送信して、当該各部の当該機能を実行させる。

拡張アプリ管理部３４０は、標準機能サービス３１０及び拡張機能サービス３２０を呼び出し可能な拡張アプリ４００を管理し実行する。
拡張アプリ管理部３４０は、拡張アプリ４００のインストール、画像形成装置１から使用可能な状態とするアクティベーション、実行、実行終了、アンインストール等を拡張アプリプラットフォーム３００のＡＰＩにより管理する（以下、これらの処理を拡張アプリ４００の「ライフサイクル」の管理という。）。
また、拡張アプリ管理部３４０は、操作パネル部１６等から認証情報を取得した場合、拡張アプリ４００をアクティベーションして、使用可能な状態としてもよい。

ＯＳインストールサービス３３０は、ＯＳ２３０に機能を追加するためのサービス等である。
ＯＳインストールサービス３３０は、ＯＳ２３０上にデバイスドライバーやスクリプト等の制御プログラムをインストールする。この場合、ＯＳインストールサービス３３０は、ＲＯＭやフラッシュメモリー等に記憶されたファームウェアは変更せず、追加的な変更を行ってもよい。この上で、ＯＳインストールサービス３３０は、ＯＳ２３０の設定ファイルの内容を変更することも可能である。このため、ＯＳインストールサービス３３０は、例えば、「ｖａｒ」等のディレクトリーに保存されたファイルを作成、変更、削除等したり、レジストリー等のデータベースを変更したりしてもよい。
なお、ＯＳインストールサービス３３０は、ファームウェアの一部又は全体を変更又はアップデート等することも可能である。

拡張アプリ４００は、拡張アプリプラットフォーム３００上で実行されるアプリケーションのプログラム及びデータである。拡張アプリ４００は、標準機能サービス３１０を呼び出して標準アプリ１２０の機能を利用し、拡張機能サービス３２０を呼び出して画像形成装置１の各部の機能を利用し、又はＯＳインストールサービス３３０を呼び出してＯＳ２３０への追加の機能をインストールする等の処理を実行することが可能である。このため、拡張アプリ４００により、画像形成装置１単体では使用できない各種処理を行わせることが可能となる。
また、拡張アプリ４００は、拡張アプリプラットフォーム３００上で動作する実行ファイルと、クラス情報を含む各種データとを含んで構成されてもよい。この場合、拡張アプリ４００の実行ファイルは、例えば、各種スクリプト言語のファイルや、Ｊａｖａ（登録商標）アプリの中間言語のファイルや、「ネイティブ」の実行ファイル等のアプリのバイナリのファイルであってもよい。拡張アプリ４００は、処理スピードや必要メモリー容量等のリソースの制限が少ない場合はスクリプト言語のファイルや中間言語のファイルで記載されていてもよい。また、拡張アプリ４００は、リソースの制限がある場合にはパフォーマンスに優れるＣ言語やＣ＋＋言語やアセンブラ言語等で記載されていてもよい。拡張アプリ４００は、この他にも、必要なデータを含んでいてもよい。
拡張アプリ４００は、例えば、ＯＣＲ（Optical Character Recognition、光学文字認識）、監視カメラアプリ、ウォーターマーク作成、請求書作成、社員名簿管理、伝票管理、契約書管理、名刺管理、ＰＤＦ作成、帳簿管理、グループ管理等の実用アプリを含む。また、拡張アプリ４００は、ＯＳ２３０上のデバイスドライバーやファームウェア等の追加変更を行うインストーラーアプリ、その他の管理アプリ等であってもよい。
また、複数の拡張アプリ４００が備えられていてもよい。また、拡張アプリ４００は、画像形成装置１や他の端末等（図示せず）からインストールされて記憶部１９に記憶されてもよい。また、拡張アプリ４００は、外部の記憶媒体に記憶されていてもよい。また、拡張アプリ４００は、画像形成装置１の機種固有情報に対応して実行可能か否かが選択されてもよい。また、各拡張アプリ４００をインストールや実行する場合、当該画像形成装置１と対応付けられて使用可能な状態にする「アクティベーション」が必要であってもよい。なお、画像形成装置１の機種毎に別々の拡張アプリ４００がインストールされてもよい。

なお、図２に示す各部は、記憶部１９のＨＤＤやフラッシュメモリー等に記憶された制御プログラムをＲＡＭ等に読み出して、制御部１０が実行することで実現することが可能である。
また、図２に示す各部は、図１に示すハードウェア資源である各部にアクセスして制御したり、各種データの読み書き、送受信等を行うことが可能である。

〔画像形成装置１による拡張アプリ実行処理〕
次に、図３〜図６を参照して、本発明の実施形態に係る画像形成装置１による拡張アプリ実行処理の説明を行う。
本実施形態の拡張アプリ実行処理は、拡張アプリ４００を実行し、呼び出される標準アプリ１２０やハードウェア資源の機能に対応した処理を行う。また、拡張アプリ実行処理にて、ＯＳ２３０上へのデバイスドライバーのインストール等も行う。
本実施形態に係る拡張アプリ実行処理は、主に画像形成装置１の制御部１０が、記憶部１９に記憶されたプログラムを、各部と協働し、ハードウェア資源を用いて実行する。
以下で、図３のフローチャートを参照して、拡張アプリ実行処理の詳細をステップ毎に説明する。

（ステップＳ１０１）
まず、拡張アプリ管理部３４０が、拡張アプリ実行開始処理を行う。
拡張アプリ管理部３４０は、接続された記憶媒体、図示しないサーバーや端末等から拡張アプリ４００がインストールされ、ユーザーから実行の指示があった場合、この拡張アプリ４００の実行を開始させる。
なお、拡張アプリ管理部３４０は、デバイスドライバーのインストーラーアプリであった場合に、インストールせずに実行させてもよい。

（ステップＳ１０２）
ここで、標準機能サービス３１０が、標準アプリ１２０を呼び出すか否かを判断する。標準機能サービス３１０は、拡張アプリ４００が標準アプリ１２０の機能を利用するための呼び出しを行う場合にＹｅｓ、それ以外の場合はＮｏと判断する。
Ｙｅｓの場合、標準機能サービス３１０は、処理をステップＳ１０３に進める。
Ｎｏの場合、標準機能サービス３１０は、処理をステップＳ１０４に進める。

（ステップＳ１０３）
標準アプリ１２０の呼び出しを行う場合、標準機能サービス３１０及び標準アプリサービスＩＦ部１１０が、標準アプリ機能利用処理を行う。
図４によると、標準機能サービス３１０は、拡張アプリ４００からの拡張アプリ管理部３４０を介した標準機能サービス３１０の呼び出しがあった場合、これを標準アプリサービスＩＦ部１１０に通知する。
標準アプリサービスＩＦ部１１０は、拡張アプリプラットフォーム３００の標準機能サービス３１０から呼び出された機能に対応する標準アプリ１２０の機能を呼び出して、実行させる。
標準アプリサービスＩＦ部１１０は、例えば、コピーアプリ１２１を呼び出す場合、コピーの開始の画面を操作パネル部１６に表示してもよい。また、標準アプリサービスＩＦ部１１０は、コピーの解像度や色等のプロパティーを表示する等、アプリの一部を呼び出して当該機能を利用させてもよい。また、標準アプリサービスＩＦ部１１０は、プリンターアプリ１２２を呼び出す場合、拡張アプリ４００が取得したり指定したりした各種ジョブデータやファイル等を出力させてもよい。また、標準アプリサービスＩＦ部１１０は、ＦＡＸアプリ１２３を呼び出す場合、受信したファクシミリの画像データを指定して拡張アプリ４００に取得させたり、拡張アプリ４００に指定されたファイル等を送信させたりしてもよい。また、標準アプリサービスＩＦ部１１０は、拡張アプリ４００から標準アプリ１２０をインストールしたり、削除したり、設定変更をしたりしてもよい。

（ステップＳ１０４）
ここで、拡張機能サービス３２０が、画像形成装置１の各部の機能を呼び出すか否かを判断する。拡張機能サービス３２０は、拡張アプリ４００が画像形成装置１のハードウェア資源を利用するため各部の機能を呼び出す場合にＹｅｓ、それ以外の場合はＮｏと判断する。
Ｙｅｓの場合、拡張機能サービス３２０は、処理をステップＳ１０５に進める。
Ｎｏの場合、拡張機能サービス３２０は、処理をステップＳ１０６に進める。

（ステップＳ１０５）
各部の機能を呼び出す場合、拡張機能サービス３２０及びプラットフォームサービスＩＦ部２１０が、各部制御用サービス利用処理を行う。
図５によると、拡張機能サービス３２０は、拡張アプリ４００からの拡張アプリ管理部３４０を介した拡張機能サービス３２０の呼び出しがあった場合、これをプラットフォームサービスＩＦ部２１０に通知する。
プラットフォームサービスＩＦ部２１０は、拡張アプリプラットフォーム３００の拡張機能サービス３２０から呼び出されると、呼び出された機能に対応する各部制御用サービス２２０の各機能を呼び出して、画像形成装置１のハードウェア資源を利用させる。
プラットフォームサービスＩＦ部２１０は、例えば、画像処理機能サービスに対応した機能を呼び出す場合、拡張アプリ４００から画像データ等を取得して、又は原稿読取部１２から原稿を読み出して画像データとして記憶し、又は記憶された画像データを記憶部１９から読み出し、画像処理の機能を特定して実行させる。この場合、プラットフォームサービスＩＦ部２１０は、例えば、画像処理機能サービス２２１に対応した機能を呼び出す場合、画像データの拡大、縮小、回転、色変換、ノイズ除去、フォーマット変換、文字認識、透かし認識等の処理を画像処理機能サービス２２１により実行させる。また、プラットフォームサービスＩＦ部２１０は、例えば、デバイス操作サービス２２２に対応した機能を呼び出す場合、操作パネル部１６への描画、ＦＡＸ送受信部１８の制御、ユーザー認証、搬送部１４の駆動、各部のステータスの取得等の処理をデバイス操作サービス２２２により実行させる。また、プラットフォームサービスＩＦ部２１０は、ネットワーク通信サービス２２３に対応した機能を呼び出す場合、ネットワーク送受信部１５により、各種プロトコルを用いたファイルの送受信、ストリーミング、認証データの送受信等をネットワーク通信サービス２２３により実行させる。

（ステップＳ１０６）
ここで、ＯＳインストールサービス３３０が、デバイスドライバーのインストール等を行うか否かを判断する。ＯＳインストールサービス３３０は、ＯＳ２３０上にデバイスドライバー等のインストール等を行う場合にＹｅｓ、それ以外の場合はＮｏと判断する。
Ｙｅｓの場合、ＯＳインストールサービス３３０は、処理をステップＳ１０７に進める。
Ｎｏの場合、ＯＳインストールサービス３３０は、拡張アプリ実行処理を終了する。

（ステップＳ１０７）
デバイスドライバー等のインストール等を行う場合、ＯＳインストールサービス３３０が、機能追加処理を行う。
図６によると、ＯＳインストールサービス３３０は、デバイスドライバー等をインストールする場合、拡張アプリ４００から、拡張アプリ管理部３４０、拡張機能サービス３２０を介して取得したデバイスドライバー等を記憶部１９に記憶する。ＯＳインストールサービス３３０は、その後、ＯＳ２３０の設定を変更等する。これにより、ＯＳ２３０上に機能を追加可能となる。
なお、ＯＳインストールサービス３３０は、ファームウェアの書き換えを行ってもよい。この場合、ＯＳインストールサービス３３０は、拡張アプリ４００から、上述のデバイスドライバーと同様に取得したファームウェアを、フラッシュメモリーやＨＤＤに書き込む。
以上により、本実施形態に係る拡張アプリ実行処理を終了する。

以上のように構成することで、以下のような効果を得ることができる。
近年、スマートフォンやタブレット等のモバイル向端末のビジネス活用の進展、クラウド・サービスやソーシャル・ネットワーキング・サービス（ＳＮＳ）の普及等によりＩＴ基盤自体が激変し、ＩＴ技術の進化のスピードに対応することが必要となっている。
しかしながら、特許文献１に記載されたような従来のプラットフォームでは、カスタマイズや拡張が容易ではなく、開発コストがかかっていた。
これに対して、本実施形態の画像形成装置１は、ＯＳ２３０上でハードウェア資源を管理する機器制御プラットフォーム２００と、機器制御プラットフォーム２００で管理されたハードウェア資源を利用する標準アプリ１２０を実行する標準アプリ実行部１００と、標準アプリ実行部１００により実行される標準アプリ１２０から標準アプリサービスＩＦ部１１０に対応した機能を利用させる標準機能サービス３１０、プラットフォームサービスＩＦ部２１０に対応したハードウェア資源を利用させる拡張機能サービス３２０、及び標準機能サービス３１０並びに拡張機能サービス３２０を呼び出し可能な拡張アプリ４００を管理し実行させる拡張アプリ管理部３４０を含む拡張アプリプラットフォーム３００とを備えることを特徴とする。
このように構成することで、階層化された拡張アプリプラットフォーム３００により、拡張アプリ４００から、標準アプリ１２０の機能又は各部に対応するハードウェア資源をそれぞれ利用可能となる。このため、顧客に合わせて構成を変更するカスタマイズが容易となり、開発コストを低減する画像形成装置を提供できる。
つまり、本実施形態の画像形成装置１は、標準アプリ１２０の機能を利用するだけでよい場合は、スクリプト言語等で素早く開発を行うことができる。逆に、ハードウェア資源を直接制御するカスタマイズの必要がある場合、標準アプリ１２０を経由せず、各部の機能を呼び出すことが可能となる。このように、本実施形態の画像形成装置１は、様々な顧客の要望に対応して、必要なカスタマイズのレベルの違いを、階層化された拡張アプリプラットフォーム３００で吸収する。これにより、必要なカスタマイズのレベルの違いに容易に対応できる。また、階層化したサービスの拡張を行うことで、カスタマイズの対応範囲を明確にして、拡張アプリ４００の開発を容易にすることが可能である。また、わざわざレベルの異なるＳＤＫ（Software Development Kit）とＮＤＫ（Native Development Kit）等を用意する必要もなくなる。
また、本実施形態の画像形成装置１は、プラットフォームを階層化するソフトウェアアーキテクチャーであるため、顧客の所望する新しいサービスへの対応した製品に対応した画像形成装置１を、開発期間を短くして提供できる。つまり、顧客が求める新しい技術をいち早く反映させ、最適な性能と機能を備えた画像形成装置の製品を安く早く提供することが可能となる。

また、本実施形態に係る画像形成装置１は、拡張アプリプラットフォーム３００が、ＯＳ２３０に機能を追加するためのＯＳインストールサービス３３０を更に備えることを特徴とする。
このように構成することで、ＯＳ２３０上の機能をファームウェアを変更せずに拡張することも可能となり、ファームウェア更新によるテスト等の開発費用等を削減できる。また、ＯＳ２３０に機能を追加する度にファームウェア全体を更新する必要もなくなり、ユーザーの使い勝手を向上させられる。

また、本実施形態に係る画像形成装置１は、標準アプリ実行部１００の外部から標準アプリ１２０の機能を利用するためのインターフェイスを提供する標準アプリサービスＩＦ部１１０と、機器制御プラットフォーム２００の外部からハードウェア資源を利用するためのインターフェイスを提供するプラットフォームサービスＩＦ部２１０とを更に備えることを特徴とする。
このように構成することで、標準アプリ１２０と機器制御プラットフォーム２００とで統一した形式のインターフェイスを提供することが容易となり、拡張アプリ４００を統一した開発環境で作成しやすくなり、開発コストを削減することができる。
また、標準アプリ１２０の機能と、機器制御プラットフォーム２００により利用されるハードウェア資源とを別々に拡張アプリ４００から実行可能となる。このため、拡張アプリ４００の実行時のスピード等のパフォーマンスを向上させることができる。

なお、上述の実施形態では、拡張アプリ４００から標準アプリ１２０等が呼び出される例について説明したものの、標準アプリ１２０や各部制御用サービス２２０やＯＳ２３０等からそれぞれ拡張アプリ４００が呼び出されてもよい。また、標準アプリサービスＩＦ部１１０により、標準アプリ１２０間で機能を呼び出してもよい。

また、拡張アプリ４００は、画像形成装置１の各機能を呼び出して所望の機能を実現させるための「一般アプリ」と、これらの一般アプリを管理する「管理アプリ」とを含んでいてもよい。
このように構成することで、拡張アプリ４００により画像形成装置１を柔軟に制御することが可能となり、又、セキュリティを高めることができる。

また、上述の実施形態では、標準アプリ１２０及び拡張アプリ４００は既に記憶部１９に記憶されている状態であるように説明した。
しかしながら、画像形成装置１に接続した外部の記憶媒体（図示せず）、外部のサーバーに接続した記憶媒体、ネットワーク経由で接続された外部の端末等から、別途、標準アプリ１２０及び拡張アプリ４００をインストールして記憶部１９に記憶させることも可能である。この場合、当該標準アプリ１２０及び拡張アプリ４００は、インストールしたユーザー、画像形成装置１、又は端末からのみ使用可能なように設定してもよい。
このように構成することで、機能拡張を柔軟に実現することができ、管理コストを低減できる。

また、画像形成装置１の記憶部１９には、標準アプリや拡張アプリ４００とは異なる種類のアプリを記憶させることも可能である。たとえば、記憶部１９には、拡張アプリ４００以外のＷｅｂアプリ等（以下「外部アプリ」という。）や、ユーザーのデータ等を記憶させてもよい。外部アプリは画像形成装置１の操作パネル部１６のユーザーの指示で呼び出して、画像形成装置１に読み込んで実行させてもよい。
このように構成することで、拡張アプリプラットフォーム３００のアプリと外部アプリとを柔軟に使い分けて、ユーザーの使い勝手をよくすることができる。

＜第二実施形態＞
次に、図７〜図９により、本発明の第二実施形態に係る画像形成装置について説明する。
まず、図７により、本発明の第二実施形態に係る画像形成装置の制御構成について説明する。
第二実施形態の画像形成装置は、第一実施形態の画像形成装置１（図１）と同様のシステム構成である。また、第二実施形態の画像形成装置において、第一実施形態の画像形成装置１（図２）と同一の番号は同一の構成要素を示す。
図７によると、第二実施形態の画像形成装置では、標準アプリ１２０に、各種標準アプリ１２４が、例えば、工場出荷状態で既にインストールされている。

各種標準アプリ１２４は、後述の送信アプリ等を含んでいる。この送信アプリは、機能を拡張させたものであり、詳細は後述するが、例えば、送信した原稿を控えとして印刷するなどの機能を追加したものである。

第二実施形態の画像形成装置において、コピーアプリ１２１、プリンターアプリ１２２、ＦＡＸアプリ１２３、各種標準アプリ１２４等は、次の（１）〜（５）の汎用インターフェイスを有し、後述の拡張機能サービス３２０による設定によってそれぞれの汎用インターフェイスの利用がＯＮ／ＯＦＦされるようになっている。また、以下のデバイスとは、ハードウェア資源である。
（１）アプリケーションサービス側が提供するインターフェイスは、１デバイス入力−複数デバイス出力とする単位で構成するが、中断／継続を繰り返すことにより、複数デバイス入力−複数デバイス出力を可能とするインターフェイスとすること。
（２）使用者側からサービスへの要求は、入出力デバイスを指定するが、その入力デバイス指定に“指定なし”を指定ことで、入力済み画像の編集のみを実施可能とするインターフェイスとすること。
（３）中断オプションを備え、画像入力後に出力を開始することなく、サービスの中断を可能とする構成とすること。
（４）終了オプションを備え、先に要求したサービス内容が終了しても、終了判断をサービスの使用者側でコントロールできる構成とすること。
（５）出力先補正オプションを備え、使用者側で指定した出力先に対して何らかのシステム上の都合により出力できなかった場合、適切な出力先にシステム側で自動的に補正するかどうかを、使用者側で指定できる構成とすること。
なお、汎用インターフェイスの詳細については後述する。
また、第二実施形態に係る画像形成装置の使用開始後に標準アプリ１２０がインストールされてもよい。つまり、例えば、ＦＡＸ送受信部のＦＡＸボードが取り付けられた際に、ＦＡＸアプリ１２３がインストールされる等の処理が行われてもよい。
また、ハードウェアの構成に関わらず、独自の標準アプリ１２０をユーザーがインストールすることも可能である。

〔第二実施形態の画像形成装置による画像処理〕
次に、図８〜図９により、本発明の第二実施形態に係る画像形成装置による画像処理の説明を行う。なお、以下においては、例えば、図７に示した標準アプリ１２０内のコピーアプリ１２１による処理の場合で説明する。また、図８ではコピーアプリの標準機能について説明し、図９ではコピーアプリの標準機能に、例えば原稿を継ぎ足し複数枚の原稿を読み込ませてコピーする機能を追加（拡張）した場合として説明する。

まず、図８に示すように、ユーザーは操作パネル部１６でコピー設定を行い、操作パネル部１６のスタートボタンを押下すると（ステップＳ２０１）、サービス開始となる（ステップＳ２０２）。ここでのコピー設定は、例えば操作パネル部１６でコピーを選択したりすることである。ここで、コピーアプリ１２１から提供される汎用インターフェイスは、（Ｓｃａｎ Ｔｏ Ｐｒｉｎｔ）となっているものとする。すなわち、入力がＳｃａｎで出力がＰｒｉｎｔとなることを示している。

次いで、機器制御プラットフォーム２００の各部制御用サービス２２０の画像処理機能サービス２２１の処理に伴って提供されるインターフェイス（Ｓｃａｎ Ｔｏ Ｐｒｉｎｔ）により、画像処理開始となる（ステップＳ２０３）。
このとき、原稿読取部１２が原稿の読み込み（スキャン）を開始する（ステップＳ２０４）。ここで読み込まれた画像データは、例えば、上述した記憶部１９の文書ボックス内に保存される。画像形成部１７は、保存された画像データに基づいて画像形成し、さらに記録紙に印刷（印刷開始）する（ステップＳ２０５）。
印刷が完了すると、各部制御用サービス２２０の画像処理機能サービス２２１の処理が終了となり（ステップＳ２０６）、コピーアプリ１２１の処理も終了となる（ステップＳ２０７）。
なお、原稿読取部１２による原稿の読み込み（スキャン）、画像形成部１７により画像形成等は、各部制御用サービス２２０の画像処理機能サービス２２１及びデバイス操作サービス２２２から提供される制御に関わるサービスによって行われる。

以上がコピーアプリ１２１の標準機能である。
次に、図９を参照し、この標準機能に対し、例えば原稿を継ぎ足し複数枚の原稿を読み込ませてコピーする機能を追加（拡張）した場合の画像処理について説明する。なお、この場合の機能は、上述した（１）〜（５）のうち、（１）の汎用インターフェイスの利用が拡張機能サービス３２０によりＯＮされることにより追加（拡張）されるものである。

まず、図９に示すように、ユーザーは操作パネル部１６でコピー設定を行う。ここでのコピー設定は、操作パネル部１６でコピーを選択したりすることであるが、上述した機能の追加（拡張）の利用を選択したりすることも含まれる。
すなわち、例えば上述した機能の追加（拡張）により、操作パネル部１６に連続読み込みモードのＯＮ／ＯＦＦを選択できる内容が表示されるようになっているものとする。この場合、ユーザーが連続読み込みモードのＯＮを選択することで、連続読み込みモードにすることができる（ステップＳ２１０）。
そして、原稿をセットし、操作パネル部１６のスタートボタンを押下することで（ステップＳ２１１）、連続読み込み開始となり（ステップＳ２１２）、サービス開始となる（ステップＳ２１３）。
ここで、コピーアプリ１２１から提供される汎用インターフェイスは、（Ｓｃａｎ ＴｏＰｒｉｎｔ）となっているものとする。すなわち、入力がＳｃａｎで出力がＰｒｉｎｔとなることを示している。また、機能の追加（拡張）による中断オプションがＯＮになっていることも含まれる。

次いで、機器制御プラットフォーム２００の各部制御用サービス２２０の画像処理機能サービス２２１の処理に伴って提供されるインターフェイス（Ｓｃａｎ Ｔｏ Ｂｏｘ）により、画像処理開始となる（ステップＳ２１４）。ここで、Ｂｏｘとは、例えば、上述した記憶部１９の文書ボックスである。
このとき、原稿読取部１２が原稿の読み込み（スキャン）を開始する（ステップＳ２１５）。読み込まれた画像データは、上記同様に、例えば、記憶部１９の文書ボックス内に保存される（保存済原稿Ｐａｇｅ１）。

ここで、原稿読取部１２による原稿の読み込みが完了すると、各部制御用サービス２２０の画像処理機能サービス２２１の処理に伴うインターフェイス（Ｓｃａｎ Ｔｏ Ｂｏｘ）の提供処理が中断となり（ステップＳ２１６）、コピーアプリ１２１から提供される汎用インターフェイスの提供処理も中断となる（ステップＳ２１７、Ｓ２１８）。
続いて、次の原稿をセットし（ステップＳ２１９）、操作パネル部１６のスタートボタンを押下することで、読み込み継続となり（ステップＳ２２０）、サービス開始となる（ステップＳ２２１）。
ここで、コピーアプリ１２１から提供される汎用インターフェイスは、上記同様に、（Ｓｃａｎ ＴｏＰｒｉｎｔ）となっている。すなわち、入力がＳｃａｎで出力がＰｒｉｎｔとなることを示している。また、機能の追加（拡張）による中断オプションがＯＮになっていることも含まれる。

次いで、機器制御プラットフォーム２００の各部制御用サービス２２０の画像処理機能サービス２２１の処理に伴って提供されるインターフェイス（Ｓｃａｎ Ｔｏ Ｂｏｘ）により、画像処理開始となる（ステップＳ２２２）。ここで、Ｂｏｘとは、上記同様に、上述した記憶部１９の文書ボックスである。
このとき、原稿読取部１２が原稿の読み込み（スキャン）を開始する（ステップＳ２２３）。読み込まれた画像データは、上記同様に、例えば、記憶部１９の文書ボックス内に保存される（保存済原稿Ｐａｇｅ１ Ｐａｇｅ２）。

ここで、原稿読取部１２による原稿の読み込みが完了すると、各部制御用サービス２２０の画像処理機能サービス２２１の処理に伴うインターフェイス（Ｓｃａｎ Ｔｏ Ｂｏｘ）の提供処理が中断となり（ステップＳ２２４）、コピーアプリ１２１から提供される汎用インターフェイスの提供処理も中断となる（ステップＳ２２５、Ｓ２２６）。
そして、原稿の読み込みが終了となると（ステップＳ２２７）、例えば操作パネル部１６の読み込み終了ボタンを押下することで（ステップＳ２２８）、サービス継続となる（ステップＳ２２９）。なお、読み込み終了ボタンを押下することで、上述した中断オプションはＯＮからＯＦＦに変更される。
ここで、コピーアプリ１２１から提供される汎用インターフェイスは、（Ｎｏｎｅ ＴｏＰｒｉｎｔ）となっている。すなわち、入力が無しで出力がＰｒｉｎｔとなることを示している。また、機能の追加（拡張）による中断オプションがＯＦＦになっていることも含まれる。

次いで、機器制御プラットフォーム２００の各部制御用サービス２２０の画像処理機能サービス２２１の処理に伴って提供されるインターフェイス（Ｓｃａｎ Ｔｏ Ｂｏｘ）により、画像処理開始となる（ステップＳ２３０）。ここで、Ｂｏｘとは、上記同様に、上述した記憶部１９の文書ボックスである。
続いて、画像形成部１７は、記憶部１９の文書ボックス保存された画像データ（保存済原稿Ｐａｇｅ１ Ｐａｇｅ２）に基づいて画像形成し、さらに記録紙に印刷（印刷開始）する（ステップＳ２３１）。

ここで、記録紙への印刷が完了すると、各部制御用サービス２２０の画像処理機能サービス２２１の処理に伴うインターフェイス（Ｓｃａｎ Ｔｏ Ｂｏｘ）の提供処理が終了となり（ステップＳ２３２）、コピーアプリ１２１から提供される汎用インターフェイスの提供処理も終了となる（ステップＳ２３３）。

以上のように構成することで、以下のような効果を得ることができる。
上述したように、アプリをインストールし実行させるためには、画像処理装置に搭載されているＯＳの基本的な機能を利用できるように、それぞれのアプリケーションを開発する必要がある。
また、アプリケーションの開発に際しては、開発コストがかからないように、効率良く行うことも必要となってくる。
ここで、上述した特許文献１でのアーキテクチャーは、アプリサービス、共通システムサービス及び汎用ＯＳによるプラットフォームと、このプラットフォーム側が提供する機能を利用するアプリケーションという２つの層で構成されている。
この構成により、アプリケーションの開発は、共通のプラットフォームを使用することが可能となり、開発効率を向上させることができる。

ところが、アプリケーション側は、プラットフォーム側が提供する以上の機能を提供することができないという問題があった。

これに対して、本実施形態の画像形成装置、画像形成方法及び画像形成プログラムによれば、標準アプリケーションの機能の拡張を、拡張機能サービスによる設定により行うことができることから、プラットフォーム（機器制御プラットフォーム）側が提供する機能の影響を受けずに標準アプリケーションの機能の拡張を行うことができる。

なお、以上においては、上述したコピーアプリ１２１が提供する（１）〜（５）の汎用インターフェイスのうち、（１）の汎用インターフェイスに相当するものについて説明したが、この例に限るものではない。
すなわち、例えば（２）の汎用インターフェイスにより、入力済み画像の編集のみを行うことができる機能の追加（拡張）が可能となる。また、例えば（３）の汎用インターフェイスにより、画像入力後に出力を開始することなく、サービスの中断を行うことができる機能の追加（拡張）が可能となる。また、例えば（４）の汎用インターフェイスにより、先に要求したサービス内容が終了した後の終了判断をサービスの使用者側でコントロールできる機能の追加（拡張）が可能となる。また、例えば（５）の汎用インターフェイスにより、使用者側で指定した出力先でのトラブルに対し、システム側が自動的に適切な出力先を補正することを指定できる機能の追加（拡張）が可能となる。

また、上述したコピーアプリ１２１が提供する（１）〜（５）の汎用インターフェイスを任意に組み合わせることで、本実施形態の画像形成装置の機能の利用の利便性を高めることができる。なお、このようなコピーアプリ１２１が提供する（１）〜（５）の汎用インターフェイスの利用及び組み合わせは、上述した拡張機能サービス３２０の更新によって行われるため、新たな機能が追加（拡張）されたコピーアプリ１２１をインストールすることなしに、ユーザーの要望に応じた機能の追加（拡張）を行うことができる。
また、標準アプリ１２０のコピーアプリ１２１に限らず、標準アプリ１２０のプリンターアプリ１２２、ＦＡＸアプリ１２３、各種標準アプリ１２４等においても、コピーアプリ１２１と同様に、上述した（１）〜（５）の汎用インターフェイスが予め組み込まれているため、拡張機能サービス３２０の更新により、ユーザーの要望に応じた機能の追加（拡張）を行うことができる。

このように、本実施形態では、機器制御プラットフォーム２００によりオペレーティングシステム（ＯＳ２３０）上でハードウェア資源が管理され、標準アプリケーション実行部（標準アプリ実行部１００）により機器制御プラットフォーム２００で管理されたハードウェア資源を利用する標準アプリケーション（標準アプリ１２０）が実行され、拡張アプリケーションプラットフォーム（拡張アプリプラットフォーム３００）に含まれる拡張アプリケーション管理部（拡張アプリ管理部３４０）により、標準アプリケーション実行部（標準アプリ実行部１００）により実行される標準アプリケーション（標準アプリ１２０）の機能を利用させる標準機能サービス３１０、ハードウェア資源を利用させる拡張機能サービス３２０、及び標準機能サービス３１０並びに拡張機能サービス３２０をそれぞれ呼び出し可能な拡張アプリケーション（拡張アプリ４００）が管理されて実行され、標準アプリケーション（標準アプリ１２０）には、機能の拡張に対応したハードウェア資源を利用するための汎用インターフェイスが設けられ、前記汎用インターフェイスは、拡張機能サービス３２０による設定によって利用可能とされている構成としている。
これにより、標準アプリケーションの機能の拡張を、拡張機能サービス３２０による設定により行うことができることから、プラットフォーム（機器制御プラットフォーム）側が提供する機能の影響を受けずに標準アプリケーションの機能の拡張を行うことができる。

また、本実施形態では、標準アプリ１２０の機能の追加（拡張）は、拡張機能サービス３２０の更新のみでよいことから、個別製品仕様への対応を柔軟かつ効率良く行うことができる。
また、本実施形態では、標準アプリ実行部１００により実行される標準アプリ１２０から標準アプリサービスＩＦ部１１０に対応した機能を利用させる標準機能サービス３１０、プラットフォームＩＦ部サービスＩＦ２１０に対応したハードウェア資源を利用させる拡張機能サービス３２０、及び標準機能サービス３１０並びに拡張機能サービス３２０を呼び出し可能な拡張アプリ４００を管理し実行させる拡張アプリ管理部３４０を含む拡張アプリプラットフォーム３００を備えている。
これにより、拡張アプリ４００から、標準アプリ１２０の機能又は各部に対応するハードウェア資源をそれぞれ利用可能となり、顧客に合わせて構成を変更するカスタマイズが容易となり、開発コストの低減が図れる。
つまり、本実施形態の画像形成装置は、標準アプリ１２０の機能を利用するだけでよい場合は、スクリプト言語等で素早く開発を行うことができる。逆に、ハードウェア資源を直接制御するカスタマイズの必要がある場合、標準アプリ１２０を経由せず、各部の機能を呼び出すことが可能となる。

また、本実施形態では、標準アプリ実行部１００の外部から標準アプリ１２０の機能を利用するためのインターフェイスを提供する標準アプリサービスＩＦ部１１０を備えている。これにより、機器制御プラットフォーム２００の間で統一した形式のインターフェイスを提供することが容易となり、拡張アプリ４００を統一した開発環境で作成しやすくなり、開発コストを削減することができる。
また、機器制御プラットフォーム２００により利用されるハードウェア資源を容易に拡張アプリ４００から実行可能となる。このため、拡張アプリ４００の実行時のスピード等のパフォーマンスを向上させることができる。

なお、本実施形態での画像形成装置の記憶部１９には、標準アプリ１２０や拡張アプリ４００とは異なる種類のアプリを記憶させることも可能である。たとえば、記憶部１９には、拡張アプリ４００以外のＷｅｂアプリ等（以下「外部アプリ」という。）や、ユーザーのデータ等を記憶させてもよい。外部アプリは本実施形態の画像形成装置の操作パネル部１６のユーザーの指示で呼び出して、本実施形態の画像形成装置に読み込んで実行させてもよい。
このように構成することで、拡張アプリプラットフォーム３００のアプリと標準アプリ１２０とを柔軟に使い分けでき、ユーザーの使い勝手をよくすることができる。
また、本実施形態では、本発明を画像形成装置に適用した場合で説明したが、この例に限らず、各種情報処理装置にも適用可能である。つまり、ネットワークスキャナー、スキャナーをＵＳＢ等で別途接続したサーバー等を用いるような構成であってもよい。また、アプリをインストール可能な情報処理装置であるＰＣ、スマートフォン、携帯電話、オフィス機器、産業用機器等にも適用可能である。

＜第三実施形態＞
次に、図１０〜図１３により、本発明の第三実施形態に係る画像形成装置について説明する。
第三実施形態の画像形成装置は、第一実施形態の画像形成装置１（図１）と同様のシステム構成、機能構成である。

〔プラットフォームサービスＩＦ部２１０、各部制御用サービス２２０の詳細な構成〕
図１０により、プラットフォームサービスＩＦ部２１０及び各部制御用サービス２２０の詳細な構成について説明する。
プラットフォームサービスＩＦ部２１０は、各部制御用サービス２２０により第三実施形態の画像形成装置の各部を呼び出してハードウェア資源を利用させる。このため、プラットフォームサービスＩＦ部２１０は、拡張機能サービス３２０から利用可能な各機能に対応したインターフェイスをそれぞれ備えている。

より具体的に説明すると、プラットフォームサービスＩＦ部２１０は、例えば、拡張機能サービス３２０からの利用する機能に対応したインターフェイスとして、画像処理機能サービスＩＦ２１１、デバイス操作サービスＩＦ２１２、及びネットワーク通信サービスＩＦ２１３を含んでいる。
画像処理機能サービスＩＦ２１１は、画像処理のデータの作成や変換や出力に関する機器制御プラットフォーム２００の機能に対応するインターフェイスである。
デバイス操作サービスＩＦ２１２は、各部のデバイスを制御するための機器制御プラットフォーム２００の機能に対応するインターフェイスである。
ネットワーク通信サービスＩＦ２１３は、ネットワークの送受信に関する機器制御プラットフォーム２００の機能に対応するインターフェイスである。

各部制御用サービス２２０は、プラットフォームサービスＩＦ部２１０を介して利用されるハードウェア資源の各機能に対応した共通のインターフェイスを含むコンポーネント２２１を組み合わせたサービスとして構成される。
コンポーネント２２１は、例えば、ＡＰＩ等やクラス等のプログラムのコンポーネント（部品、Component）及びデータであり、共通の呼び出し規約等のインターフェイスで相互に接続され、データを送受信することが可能である。各コンポーネント２２１は、ハードウェア資源の機能の利用に必要なパフォーマンスに対応して、アセンブラ言語等の低級言語〜スクリプト言語等の高級言語により記載される。また、コンポーネント２２１は、複数の階層に対応して配置され、階層間で接続されて構成されてもよい。図１０の例では、コンポーネント２２１ａ〜コンポーネント２２１ｈが、上位層、中位層、下位層の三層に対応して配置されている例を示している（これらのうち一つを示す際には、単に「コンポーネント２２１」という。）。コンポーネント２２１は、各層の間で接続される際に、層間で共通のインターフェイスによりデータを変換してもよい。また、コンポーネント２２１は、プラットフォームサービスＩＦ部２１０を介して利用される機能に対応するインターフェイス用にそれぞれデータを変換してもよい。図１０の例では、上位層のコンポーネント２２１ｇとコンポーネント２２１ｈは、プラットフォームサービスＩＦ部２１０の画像処理機能サービスＩＦ２１１、デバイス操作サービスＩＦ２１２、及びネットワーク通信サービスＩＦ２１３に対応するように共通のインターフェイスでデータを変換する。

また、各部制御用サービス２２０は、図１０の例の場合には、プラットフォームサービスＩＦ部２１０の画像処理機能サービスＩＦ２１１に対応した画像処理機能サービス、デバイス操作サービスＩＦ２１２に対応したデバイス操作サービス、及びネットワーク通信サービスＩＦ２１３に対応したネットワーク通信サービスとして機能させることが可能である。

より具体的に説明すると、画像処理機能サービスは、画像処理のデータの作成や変換や出力に関するサービスを提供する。画像処理機能サービスは、例えば、原稿読取部１２で解像度や色等を設定して原稿読取した画像データを記憶部１９に記憶させ、画像処理部１１に記憶部１９の画像データや文書データ（図示せず）を画像処理させる。また、画像処理機能サービスは、ファイル等から、画像形成部１７で画像形成する画像データを描画する。

デバイス操作サービスは、各部のデバイスを制御するためのサービス等を提供する。デバイス操作サービスは、例えば、原稿読取部１２から取得した画像データを記憶部１９に記憶し、操作パネル部１６の表示部に表示されるブラウザー上に画像を描画し、描画された画像データを画像形成部１７に送信して画像形成させ、記憶部１９に記憶された画像データをＦＡＸ送受信部１８でファクシミリ送信させる。
また、デバイス操作サービスは、第三実施形態の画像形成装置にオプション機器、例えばフィニッシャーが存在した場合は製本やステープル等、ＩＣカードや生体認証によるユーザー認証部が存在した場合は当該ユーザー認証部によるユーザー認証、カメラが存在した場合はカメラ画像の取得や視線検出等の各機能を呼び出すことも可能である。また、デバイス操作サービスは、例えば搬送部のモーターの一つを駆動させるといった、より機器のハードウェアの構成に近い制御を行ってもよい。また、デバイス操作サービスは、各部の状態の取得等の処理も実行してもよい。

ネットワーク通信サービスは、ネットワークの送受信に関するサービス等を提供する。ネットワーク通信サービスは、例えば、ネットワーク送受信部１５（図１）から、ＴＣＰ／ＩＰやＵＤＰの各種プロトコルにより、他の画像形成装置（図示せず）やサーバーや端末等の間でファイル等のデータを送受信する。たとえば、ネットワーク通信サービスは、スキャンした画像データ、文書ボックスのファイル等を送受信することも可能である。なお、ネットワーク通信サービスは、ＦＡＸ送受信部１８によるファクシミリ送受信の画像データの送受信、ユーザー認証部が存在した場合はユーザー認証結果、カメラが存在した場合は映像データの送受信等を行うことも可能である。また、ネットワーク通信サービスは、第三実施形態の画像形成装置の各部の状態、各部の機能の呼び出しの結果等についても、送受信可能である。

なお、図１０の例では、各コンポーネント２２１は、層間で接続されているものの、同一層内で接続されたり、層を跨いで接続されたり、ループを形成するよう接続されたりしてもよい。また、対応するハードウェア資源が異なったりバージョンが異なったりするものの、共通のインターフェイスを含むコンポーネント２２１が備えられていてもよい。これにより、後述するように、動的に接続先を変更して代替するコンポーネント２２１を動的に選択可能である。また、よりハードウェアに近い下位層のコンポーネント２２１については低級言語で記載し、上位層のコンポーネント２２１は高級言語で記載するといった構成も可能である。また、コンポーネント２２１のいずれかを拡張アプリ４００から拡張機能サービス３２０を使用してインストールしたり、ネットワークボード等をインストールする際等に、コンポーネント２２１をインストールしたりすることも可能である。

なお、図２、図１０に示す各部は、記憶部１９のＨＤＤやフラッシュメモリー等に記憶された制御プログラムをＲＡＭ等に読み出して、制御部１０が実行することで実現することが可能である。
また、図２、図１０に示す各部は、図１に示すハードウェア資源である各部にアクセスして制御、各種データの読み書き、送受信等することが可能である。

〔第三実施形態の画像形成装置による各部機能呼び出し処理〕
次に、図１１〜図１３により、本発明の第三実施形態に係る画像形成装置による各部機能呼び出し処理の説明を行う。
本実施形態の各部機能呼び出し処理では、拡張アプリ４００から、拡張アプリ管理部３４０と拡張機能サービス３２０とを介して、第三実施形態の画像形成装置の機能に対応するハードウェア資源が呼び出される。この際、拡張機能サービス３２０により呼び出される機能に対応したプラットフォームサービスＩＦ部２１０のインターフェイスから、各部制御用サービス２２０のコンポーネント２２１が動的に構成される。
本実施形態に係る各部機能呼び出し処理は、主に制御部１０が、記憶部１９に記憶されたプログラムを、各部と協働し、ハードウェア資源を用いて実行する。以下で、図１１のフローチャートを参照して、各部機能呼び出し処理の詳細をステップ毎に説明する。

（ステップＳ３０１）
まず、拡張アプリ管理部３４０及び拡張機能サービス３２０が、各部機能呼び出し開始を行う。
拡張アプリ管理部３４０は、接続された記憶媒体、図示しないサーバーや端末等から拡張アプリ４００がインストールされ、ユーザーから実行の指示があった場合、この拡張アプリ４００の実行を開始する。
拡張アプリ管理部３４０により実行された拡張アプリ４００は、拡張アプリ管理部３４０を介して拡張機能サービス３２０を呼び出す。
拡張機能サービス３２０は、この呼び出しにより、ハードウェア資源を利用するための機能を指定してプラットフォームサービスＩＦ部２１０に通知する。

（ステップＳ３０２）
次に、プラットフォームサービスＩＦ部２１０はインターフェイス特定処理を行う。
プラットフォームサービスＩＦ部２１０は、拡張機能サービス３２０に指定された機能に対応するインターフェイスを特定する。
図１２の例では、ハードウェア資源として原稿読取部１２にアクセスしてスキャン機能を利用したい場合、プラットフォームサービスＩＦ部２１０は、デバイス操作サービスＩＦ２１２をインターフェイスとして特定する。

（ステップＳ３０３）
次に、プラットフォームサービスＩＦ部２１０及び各部制御用サービス２２０は、コンポーネント呼び出し処理を行う。
プラットフォームサービスＩＦ部２１０は、特定したインターフェイスを介して、各部制御用サービス２２０を呼び出す。
各部制御用サービス２２０は、呼び出されたインターフェイスに接続された各コンポーネント２２１を介して、接続された本実施形態の画像形成装置の各部の機能の呼び出しを試みる。
図１２の例では、原稿読取部１２のスキャン機能を利用するため、まずは、デバイス操作サービスＩＦ２１２から、接続されたコンポーネント２２１ｈ、コンポーネント２２１ｆ、コンポーネント２２１ｃの順に、原稿読取部１２へのアクセスを試みる。

（ステップＳ３０４）
次に、各部制御用サービス２２０は、機能の呼び出しが成功したか否かを判断する。各部制御用サービス２２０は、接続されたコンポーネント２２１を介して、拡張機能サービス３２０に指定された機能が呼び出せた場合は、Ｙｅｓと判断する。各部制御用サービス２２０は、当該機能に対応するコンポーネント２２１が存在しない、又は、当該機能に対応する各部に接続できない等で、ハードウェア資源の対応する機能を呼び出せない場合、機能が呼び出しに失敗したとして、Ｎｏと判断する。図１２の例では、各部制御用サービス２２０は、コンポーネント２２１ｃに原稿読取部１２が接続されていないため、Ｎｏと判断する。
Ｙｅｓの場合、各部制御用サービス２２０は、処理をステップＳ３０７に進める。
Ｎｏの場合、各部制御用サービス２２０は、処理をステップＳ３０５に進める。

（ステップＳ３０５）
機能の呼び出しに失敗した場合、各部制御用サービス２２０は、代替接続があるか否かを判断する。各部制御用サービス２２０は、プラットフォームサービスＩＦ部２１０のインターフェイスから接続された各コンポーネント２２１を探索し、指定された機能を呼び出し可能なコンポーネント２２１の代替接続がある場合、Ｙｅｓと判断する。各部制御用サービス２２０は、探索の結果、代替接続がなかった場合は、Ｎｏと判断する。
Ｙｅｓの場合、各部制御用サービス２２０は、処理をステップＳ３０６に進める。
Ｎｏの場合、各部制御用サービス２２０は、処理をステップＳ３０８に進める。

（ステップＳ３０６）
代替接続があった場合、各部制御用サービス２２０は、代替コンポーネント選択処理を行う。
各部制御用サービス２２０は、各コンポーネント２２１を探索された代替接続に切り替えて選択する。この際、各部制御用サービス２２０は、この代替接続のルートを記憶部１９に記憶しておいてもよい。
図１３の例によると、各部制御用サービス２２０は、デバイス操作サービスＩＦ２１２から、代替接続として、コンポーネント２２１ｈ、コンポーネント２２１ｅ、コンポーネント２２１ｂ、原稿読取部１２の順で接続する。

（ステップＳ３０７）
ここで、各部制御用サービス２２０は、接続された各コンポーネントを介して、実際に画像形成装置の各部の機能の呼び出しを行う。
各部制御用サービス２２０は、接続又は代替接続された各コンポーネント２２１間でデータを送受信して、原稿読取部１２を制御する。
図１２、図１３の例では、各部制御用サービス２２０は、原稿読取部１２から原稿の画像データを取得して、デバイス操作サービスＩＦ２１２に送信する。画像データは、拡張機能サービス３２０に送信される。
これにより、画像形成装置のハードウェア資源を利用することが可能になる。

各部制御用サービス２２０は、例えば、画像処理機能サービスに対応した機能を呼び出す場合、拡張アプリ４００から画像データ等を取得して、画像処理の機能を特定して実行する。この場合、各部制御用サービス２２０は、原稿読取部１２により原稿を読み出して画像データとして記憶し、又は記憶された画像データを記憶部１９から読み出し、画像データの拡大、縮小、回転、色変換、ノイズ除去、フォーマット変換、文字認識、透かし認識等の処理を画像処理機能サービスにより実行する。また、各部制御用サービス２２０は、例えば、デバイス操作サービスに対応した機能を呼び出す場合、操作パネル部１６への描画、ＦＡＸ送受信部１８の制御、ユーザー認証、搬送部１４の駆動、各部のステータスの取得等の処理をデバイス操作サービスにより実行する。また、各部制御用サービス２２０は、ネットワーク通信サービスに対応した機能を呼び出す場合、ネットワーク送受信部１５により、各種プロトコルを用いたファイルの送受信、ストリーミング、認証データの送受信等をネットワーク通信サービスにより実行する。
その後、各部制御用サービス２２０は、各部機能呼び出し処理を終了する。

（ステップＳ３０８）
代替接続がない等で機能を呼び出せない場合、各部制御用サービス２２０は、エラー通知処理を行う。
各部制御用サービス２２０は、プラットフォームサービスＩＦ部２１０に機能を呼び出せない旨の通信を行う。これを受信したプラットフォームサービスＩＦ部２１０は、拡張機能サービス３２０に通知する。この通知を最終的に取得した拡張アプリ４００は、エラー表示やログ記載等の処理を行う。
以上により、本実施形態に係る各部機能呼び出し処理を終了する。

以上のように構成することで、以下のような効果を得ることができる。
近年、スマートフォンやタブレット等のモバイル向けの端末のビジネスへの活用の進展、クラウド・サービスやソーシャル・ネットワーキング・サービス（ＳＮＳ）の普及等によりＩＴ基盤自体が激変し、ＩＴ技術の進化のスピードに対応することが必要となっている。
しかしながら、特許文献１に記載されたような従来のプラットフォームでは、製品毎に別々にプラットフォームを作成する必要があり、開発コストがかかっていた。
これに対して、本実施形態の画像形成装置は、ＯＳ２３０上でハードウェア資源を管理する機器制御プラットフォーム２００と、機器制御プラットフォーム２００で管理されたハードウェア資源を利用する標準アプリ１２０を実行する標準アプリ実行部１００と、標準アプリ実行部１００により実行される標準アプリ１２０の機能を利用させる標準機能サービス３１０、ハードウェア資源を利用させる拡張機能サービス３２０、及び標準機能サービス３１０並びに拡張機能サービス３２０をそれぞれ呼び出し可能な拡張アプリ４００を管理し実行させる拡張アプリ管理部３４０を含む拡張アプリプラットフォーム３００と、機器制御プラットフォーム２００の外部から拡張機能サービス３２０に対応したハードウェア資源を利用するためのインターフェイスを提供するプラットフォームサービスＩＦ部２１０とを備え、機器制御プラットフォーム２００は、プラットフォームサービスＩＦ部２１０を介して利用されるハードウェア資源の各機能に対応した共通のインターフェイスを含むコンポーネント２２１を組み合わせて構成される各部制御用サービス２２０を含むことを特徴とする。
このように構成することで、製品系列が異なっても同一のプラットフォームを作成でき、様々な製品系列へ展開するプラットフォームとしての再利用性を高めることができる。また、機器の性能等に依拠したコンポーネント２２１を用意することで、同一の製品系列内で性能が異なっても同一の機器制御プラットフォーム２００を使用でき、スケーラブル化が可能となる。つまり、製品が単機能のプリンター〜ＭＦＰのように異なる製品系列であっても、容易にコンポーネント２２１により各部制御用サービス２２０を作成することが可能となり、開発コストを低減できる。また、新技術の投入のしやすさを目的としたコンポーネント２２１の組み合わせも可能となる。
また、パフォーマンスがあまり必要ないコンポーネント２２１を最初にＪａｖａ（登録商標）スクリプト等の高級言語で作成しておき、Ｃ言語等の低級言語で最適化したコンポーネント２２１を製品の展開に合わせて提供するといったことも可能になる。また、新しい製品を開発する際や顧客要望にあった新しい技術を取り込む場合に、機器制御プラットフォーム２００内部のコンポーネント２２１を入れ替えたとしても、標準アプリ１２０及び拡張アプリ４００への影響はなくなり、容易に対応可能となる。

また、階層化された拡張アプリプラットフォーム３００により、拡張アプリ４００から、標準アプリ１２０の機能又は各部に対応するハードウェア資源をそれぞれ利用可能となる。このため、顧客に合わせて構成を変更するカスタマイズが容易となり、開発コストを低減する画像形成装置を提供できる。
つまり、本実施形態の画像形成装置は、様々な個客の要望に対応する点やあらゆるカスタマイズに対応することを考慮すると、標準アプリ１２０の機能を利用するだけでよい場合は、スクリプト言語等で素早く開発を行うことができる。逆に、ハードウェア資源を直接制御するカスタマイズが必要な場合、標準アプリ１２０を経由せず、各部の機能を呼び出すことが可能となる。このように、本実施形態の画像形成装置は、これらの必要なカスタマイズのレベルの違いを、階層化された拡張アプリプラットフォーム３００で吸収することで、必要なカスタマイズのレベルの違いに容易に対応できる。また、階層化したサービスの拡張を行うことで、カスタマイズの対応範囲を明確にして、拡張アプリ４００の開発を容易にすることが可能である。また、わざわざレベルの異なるＳＤＫ（Software Development Kit）とＮＤＫ（Native Development Kit）等を用意する必要もなくなる。
また、本実施形態の画像形成装置は、プラットフォームを階層化するソフトウェアアーキテクチャーであるため、様々な個客要望に応じたカスタマイズに対応させることができる。このため、個客の所望する新しいサービスへの対応した製品の開発期間を短くし、顧客が求める新しい技術をいち早く反映させ、最適な性能と機能を備えた画像形成装置の製品を安く早く提供することが可能となる。

また、本実施形態に係る画像形成装置は、各部制御用サービス２２０のコンポーネント２２１は、複数の階層に対応して配置され、階層間で接続されて構成されることを特徴とする。
このように構成することで、機器制御プラットフォーム２００で統一した形式のインターフェイスにより必要な下位層のコンポーネント２２１を提供することができ、開発の手間を省いて開発コストを削減できる。また、高級言語〜低級言語で作成されたコンポーネント２２１を階層に応じて用意することも可能となり、機能を呼び出す際のパフォーマンスを高めることができる。このため、標準アプリ１２０及び拡張アプリ４００の実行時のスピード等を向上させることができる。
また、上述の各部機能呼び出し処理で示したように、複数の代替接続により動的に各部制御用サービス２２０の構成を変更できるため、工場出荷後に画像形成装置の構成が変わった場合でも容易に対応できる。また、オプション機器等を接続した場合、オプションボード等をアップグレードした場合等であっても、代替接続で各部制御用サービス２２０にすぐ変更して機能を利用可能であるため、サポートコストも削減できる。
また、一般的にプラットフォーム上で動くアプリの開発を容易にするために、共通のインターフェイスでコンポーネント２２１を接続することが可能であるため、アプリ開発を容易にすることができる。

また、第三実施形態に係る画像形成装置は、標準アプリ実行部１００の外部から標準アプリ１２０の機能を利用するためのインターフェイスを提供する標準アプリサービスＩＦ部１１０を更に備えることを特徴とする。
このように構成することで、機器制御プラットフォーム２００の間で統一した形式のインターフェイスを提供することが容易となり、拡張アプリ４００を統一した開発環境で作成しやすくなり、開発コストを削減することができる。
また、機器制御プラットフォーム２００により利用されるハードウェア資源を容易に拡張アプリ４００から実行可能となる。このため、拡張アプリ４００の実行時のスピード等のパフォーマンスを向上させることができる。

以上をまとめると、従来、特許文献１の技術では、低価格のプリンターや高機能なＭＦＰといった製品系列に対応して別々にプラットフォームを作成する必要があり、開発コストがかかるという問題があった。
これに対して、本実施形態によれば、ハードウェア資源の各機能に対応した共通のインターフェイスを含むコンポーネント（部品）を組み合わせて構成される各部制御用サービスにより、製品系列が異なっても同一のプラットフォームを作成でき、開発コストを低減できる画像形成装置を提供することができる。

＜第四実施形態＞
次に、図１４〜図１５により、本発明の第四実施形態に係る画像形成装置について説明する。
第三実施形態の画像形成装置は、第一実施形態の画像形成装置１（図１）と同様のシステム構成であり、第一実施形態の画像形成装置１、第二実施形態の画像形成装置と同様の機能構成（図２、図７）である。

また、プラットフォームサービスＩＦ部２１０（図２、図７）は、機器制御プラットフォーム２００の外部からハードウェア資源を利用するためのインターフェイスを提供する。
プラットフォームサービスＩＦ部２１０は、各部制御用サービス２２０を呼び出して、第四実施形態に係る画像形成装置の各部のハードウェア資源を利用させる。プラットフォームサービスＩＦ部２１０は、例えば、ＡＰＩ等、又はＯＳ２３０上のサービス等として提供されていてもよい。また、プラットフォームサービスＩＦ部２１０は、Ｃ言語の構造体、Ｃ＋＋言語のクラス、その他のオブジェクト、ルーチン、関数、ヘッダーファイル、オブジェクト、ライブラリー等（以下、「クラス等」という。）として提供されていてもよい。また、プラットフォームサービスＩＦ部２１０は、例えば、Ｊａｖａ（登録商標）等の中間言語で提供されていてもよい。
また、プラットフォームサービスＩＦ部２１０は、次の（１）〜（６）の汎用インターフェイスを有し、標準アプリ１２０からの要求に従い、前記当する汎用インターフェイスを提供する。なお、以下のデバイスとは、ハードウェア資源である。
（１）プラットフォーム側が提供する画像処理サービスを、１デバイス入力−１デバイス出力とする単位で構成すること。
（２）入出力デバイスには、任意ストレージ（たとえば記憶部１９）に割り当てられる文書ボックスと呼ぶデバイスを含め、その文書ボックスデバイスを複数の画像処理サービスで指定することにより、画像処理サービス間の連携を可能とする構成とすること。
（３）出力デバイスに、同一文書ボックスを指定することで、既に文書ボックスに保存されている画像ページに対して、画像ページを追加することができる構成とすること。
（４）文書ボックスに保存されているページ単位に出力方法の設定を可能とし、その設定を変更することで、画像出力方法を変更できる構成とすること。
（５）文書ボックスに保存されているページの削除、順番変更を可能とする構成とすること。
（６）入出力デバイスを同一の文書ボックスに指定することで、ボックス保存画像を、ボックス出力方法に応じた画像に編集することができる構成とすること。
なお、汎用インターフェイスの詳細については後述する。

〔第四実施形態の画像形成装置による画像処理〕
次に、図１４〜図１５により、本発明の第四実施形態に係る画像形成装置による画像処理の説明を行う。なお、以下においては、例えば、図２、図７に示した標準アプリ１２０の各種標準アプリ１２４内の送信アプリがネットワーク送信を行う場合で説明する。また、図１４では送信アプリの標準機能について説明し、図１５では送信アプリの標準機能に、例えば送信した原稿を控えとして印刷する機能を追加（拡張）した場合として説明する。

まず、図１４に示すように、ユーザーは原稿をセットし、操作パネル部１６で送信設定を行い、操作パネル部１６のスタートボタンを押下すると（ステップＳ４０１）、サービス開始となる（ステップＳ４０２）。ここでの送信設定は、例えば操作パネル部１６で相手先（Ｈｏｓｔ）を選択したりすることである。ここで、送信アプリから提供されるインターフェイスは、（Ｓｃａｎ Ｔｏ Ｈｏｓｔ）となっているものとする。すなわち、入力がＳｃａｎで出力がＨｏｓｔとなることを示している。

次いで、機器制御プラットフォーム２００の各部制御用サービス２２０の画像処理サービス２２１の処理に伴って提供される汎用インターフェイス（Ｓｃａｎ Ｔｏ Ｈｏｓｔ）により、画像処理開始となる（ステップＳ４０３）。ここで、各部制御用サービス２２０の画像処理サービス２２１の処理に伴って提供される汎用インターフェイス（Ｓｃａｎ Ｔｏ Ｈｏｓｔ）は、上述したプラットフォームサービスＩＦ部２１０が提供する（１）〜（６）の汎用インターフェイスのうち、（１）の汎用インターフェイスに相当するものである。
このとき、原稿読取部１２が原稿の読み込み（スキャン）を開始する（ステップＳ４０４）。ここで読み込まれた画像データは、例えば、記憶部１９の文書ボックス内に保存される。画像形成部１７が保存された画像データに基づいて画像形成した後、ネットワーク送受信部１５による送信開始によってＨｏｓｔへ送信される（ステップＳ４０５）。ネットワーク送受信部１５による送信が完了すると、各部制御用サービス２２０の画像処理サービス２２１の処理が終了となり（ステップＳ４０６）、送信アプリの処理も終了となる（ステップＳ４０７）。
なお、原稿読取部１２による原稿の読み込み（スキャン）、画像形成部１７による画像形成、ネットワーク送受信部１５による送信等は、画像処理サービス２２１、デバイス操作サービス２２２及びネットワーク通信サービス２２３から提供される制御に関わるサービスによって行われる。

以上が送信アプリの標準機能である。
次に、図１５を参照し、この標準機能に対し、送信した原稿を控えとして印刷する機能を追加（拡張）した場合の画像処理について説明する。なお、この場合の機能の追加（拡張）は、送信した原稿を控えとして印刷するように開発された新たな送信アプリをインストール（又は更新）することにより行われる。

まず、図１５に示すように、ユーザーは原稿をセットし、操作パネル部１６で送信設定を行い、操作パネル部１６のスタートボタンを押下すると（ステップＳ４１０）、サービス開始となる（ステップＳ４１１）。
ここでの送信設定においては、例えば、機能が追加（拡張）された送信アプリにより、操作パネル部１６に相手先（Ｈｏｓｔ）の選択項目と、送信設定（控え印刷あり）の選択項目が表示されているものとする。ここで、送信設定（控え印刷あり）を選択し、さらに相手先（Ｈｏｓｔ）を選択する。
また、送信アプリから提供されるインターフェイスは、（Ｓｃａｎ Ｔｏ Ｈｏｓｔ＆Ｐｒｉｎｔ）となっているものとする。すなわち、入力がＳｃａｎで出力がＨｏｓｔ＆Ｐｒｉｎｔとなることを示している。

次いで、機器制御プラットフォーム２００の各部制御用サービス２２０の画像処理サービス２２１の処理に伴って提供される汎用インターフェイス（Ｓｃａｎ Ｔｏ Ｂｏｘ）により、画像処理開始となる（ステップＳ４１２）。ここで、Ｂｏｘとは、例えば、上述した記憶部１９の文書ボックスである。
また、各部制御用サービス２２０の画像処理サービス２２１の処理に伴って提供される汎用インターフェイス（Ｓｃａｎ Ｔｏ Ｂｏｘ）は、上述したプラットフォームサービスＩＦ部２１０が提供する（１）〜（６）の汎用インターフェイスのうち、（１）の汎用インターフェイスに相当するものである。
このとき、原稿読取部１２が原稿の読み込み（スキャン）を開始する（ステップＳ４１３）。読み込まれた画像データは、上記同様に、例えば、記憶部１９の文書ボックス内に保存される。

ここで、原稿読取部１２による原稿の読み込みが完了すると、各部制御用サービス２２０の画像処理サービス２２１の処理に伴う汎用インターフェイス（Ｓｃａｎ Ｔｏ Ｂｏｘ）の提供処理が終了となる（ステップＳ４１４）。続いて、各部制御用サービス２２０の画像処理サービス２２１の処理に伴って提供される汎用インターフェイス（Ｂｏｘ Ｔｏ Ｈｏｓｔ）により、画像処理開始となる（ステップＳ４１５）。
ここで、各部制御用サービス２２０の画像処理サービス２２１の処理に伴って提供される汎用インターフェイス（Ｂｏｘ Ｔｏ Ｈｏｓｔ）は、上述したプラットフォームサービスＩＦ部２１０が提供する（１）〜（６）の汎用インターフェイスのうち、（１）の汎用インターフェイスに相当するものである。
このとき、画像形成部１７は、記憶部１９の文書ボックス内に保存された画像データに基づいて画像形成した後、ネットワーク送受信部１５による送信開始によってＨｏｓｔへ送信される（ステップＳ４１６）。ネットワーク送受信部１５による送信が完了すると、各部制御用サービス２２０の画像処理サービス２２１の処理に伴う汎用インターフェイス（Ｂｏｘ Ｔｏ Ｈｏｓｔ）の提供処理が終了となる（ステップＳ４１７）。
続いて、各部制御用サービス２２０の画像処理サービス２２１の処理に伴って提供される汎用インターフェイス（Ｂｏｘ Ｔｏ Ｐｒｉｎｔ）により、画像処理開始となる（ステップＳ４１８）。

ここで、各部制御用サービス２２０の画像処理サービス２２１の処理に伴って提供される汎用インターフェイス（Ｂｏｘ Ｔｏ Ｐｒｉｎｔ）は、上述したプラットフォームサービスＩＦ部２１０が提供する（１）〜（６）の汎用インターフェイスのうち、（１）の汎用インターフェイスに相当するものである。
このとき、画像形成部１７は、記憶部１９の文書ボックス内に保存された画像データに基づいて画像形成し、さらに記録紙に印刷（印刷開始）する（ステップＳ４１９）。記録紙への印刷が完了すると、各部制御用サービス２２０の画像処理サービス２２１の処理に伴う汎用インターフェイス（Ｂｏｘ Ｔｏ Ｐｒｉｎｔ）の提供処理が終了となり（ステップＳ４２０）、送信アプリの処理も終了となる（ステップＳ４２１）。
なお、原稿読取部１２による原稿の読み込み（スキャン）、画像形成部１７による画像形成、ネットワーク送受信部１５による送信等は、上記同様に、画像処理サービス２２１、デバイス操作サービス２２２及びネットワーク通信サービス２２３から提供される制御に関わるサービスによって行われる。

なお、以上においては、上述したプラットフォームサービスＩＦ部２１０が提供する（１）〜（６）の汎用インターフェイスのうち、（１）の汎用インターフェイスに相当するものについて説明したが、この例に限るものではない。
すなわち、例えば（２）の汎用インターフェイスにより、文書ボックスデバイスを複数の画像処理サービスで指定することにより、画像処理サービス間の連携を可能とする機能の追加（拡張）が可能となる。また、例えば（３）の汎用インターフェイスにより、既に文書ボックスに保存されている画像ページに対して、画像ページを追加することができる機能の追加（拡張）が可能となる。また、例えば（４）の汎用インターフェイスにより、文書ボックスに保存されているページ単位に出力方法の設定を変更することができる機能の追加（拡張）が可能となる。また、例えば（５）の汎用インターフェイスにより、文書ボックスに保存されているページの削除、順番変更を行うことができる機能の追加（拡張）が可能となる。また、例えば（６）の汎用インターフェイスにより、ボックス保存画像を、ボックス出力方法に応じた画像に編集することができる機能の追加（拡張）が可能となる。

いずれにしても、プラットフォームサービスＩＦ部２１０が提供する汎用インターフェイスを上述した（１）〜（６）とすることで、機器制御プラットフォーム２００側の変更を行うことなく、新たな送信アプリのインストール（又は更新）により行われる新たな機能の追加（拡張）を行うことができる。
また、送信アプリに限らず、標準アプリ１２０のコピーアプリ１２１、プリンターアプリ１２２、ＦＡＸアプリ１２３、各種標準アプリ１２４等においても、機器制御プラットフォーム２００側の変更を行うことなく、新たな機能の追加（拡張）を行うことができる。
また、上述した（１）〜（６）の汎用インターフェイスを組み合わせて利用することで、あらゆる機能への応用が可能となる。

このように、本実施形態では、機器制御プラットフォーム２００によりオペレーティングシステム（ＯＳ２３０）上でハードウェア資源が管理され、標準アプリケーション実行部（標準アプリ実行部１００）により機器制御プラットフォーム２００で管理されたハードウェア資源を利用する標準アプリケーション（標準アプリ１２０）が実行され、拡張アプリケーションプラットフォーム（拡張アプリプラットフォーム３００）に含まれる拡張アプリケーション管理部（拡張アプリ管理部３４０）により、標準アプリケーション実行部（標準アプリ実行部１００）により実行される標準アプリケーション（標準アプリ１２０）の機能を利用させる標準機能サービス３１０、ハードウェア資源を利用させる拡張機能サービス３２０及び標準機能サービス３１０並びに拡張機能サービス３２０をそれぞれ呼び出し可能な拡張アプリケーション（拡張アプリ４００）が管理されて実行され、プラットフォームサービスインターフェイス部（プラットフォームサービスＩＦ部２１０）により機器制御プラットフォーム２００の外部から標準アプリケーション（標準アプリ１２０）の機能の拡張に対応したハードウェア資源を利用するための汎用インターフェイスが提供される。
これにより、プラットフォーム（機器制御プラットフォーム２００）側が提供する機能の制約が無くなることから、プラットフォーム（機器制御プラットフォーム２００）側を更新することなく、アプリケーション（アプリ）による機能の拡張を行うことができる。

また、本実施形態では、アプリケーション（アプリ）の開発に際しては、機能の拡張のみでよいことから、個別製品仕様への対応を柔軟かつ効率良く行うことができる。
また、本実施形態では、標準アプリ実行部１００により実行される標準アプリ１２０から標準アプリサービスＩＦ部１１０に対応した機能を利用させる標準機能サービス３１０、プラットフォームＩＦ部サービスＩＦ２１０に対応したハードウェア資源を利用させる拡張機能サービス３２０、及び標準機能サービス３１０並びに拡張機能サービス３２０を呼び出し可能な拡張アプリ４００を管理し実行させる拡張アプリ管理部３４０を含む拡張アプリプラットフォーム３００を備えている。
これにより、拡張アプリ４００から、標準アプリ１２０の機能又は各部に対応するハードウェア資源をそれぞれ利用可能となり、顧客に合わせて構成を変更するカスタマイズが容易となり、開発コストの低減が図れる。
つまり、本実施形態の画像形成装置は、標準アプリ１２０の機能を利用するだけでよい場合は、スクリプト言語等で素早く開発を行うことができる。逆に、ハードウェア資源を直接制御するカスタマイズの必要がある場合、標準アプリ１２０を経由せず、各部の機能を呼び出すことが可能となる。

以上をまとめると、従来、特許技術１では、プラットフォーム側が提供する機能には制約があるため、プラットフォームが提供する既存の機能以上のアプリケーション開発を行うことができない。このようなことから、アプリケーションによる機能を拡張するためには、プラットフォーム側を更新する必要があるという問題があった。
これに対して、本実施形態の画像形成装置、画像形成方法及び画像形成プログラムによれば、プラットフォーム（機器制御プラットフォーム）側が提供する機能の制約が無くなることから、プラットフォーム（機器制御プラットフォーム）側を更新することなく、アプリケーションによる機能の拡張を行うことができる。

＜第五実施形態＞
次に、図１６〜図１９により、本発明の第五実施形態に係る画像形成装置について説明する。
まず、図１６により、本発明の第五実施形態に係る画像形成装置の制御構成について説明する。
第五実施形態の画像形成装置は、第一実施形態の画像形成装置１（図１）と同様のシステム構成である。また、第二実施形態の画像形成装置において、第一実施形態の画像形成装置１（図２）と同一の番号は同一の構成要素を示す。

第五実施形態の画像形成装置は、階層的なブロック構造として、標準アプリ実行部１００（標準アプリケーション実行部）、機器制御プラットフォーム２００、拡張アプリプラットフォーム３００（拡張アプリケーションプラットフォーム）、及び拡張アプリ４００を備えている。制御部１０が本発明の制御プログラムを実行することにより、標準アプリ実行部１００、機器制御プラットフォーム２００、拡張アプリプラットフォーム３００が実現される。さらに、制御部１０は、図１６に示す制御構成に基づいて、拡張アプリ４００、標準アプリ１２０、ＯＳ２３０を実行することができる。具体的には、拡張アプリプラットフォーム３００上で拡張アプリ４００が実行される構成となっている。また、拡張アプリプラットフォーム３００とは別に、標準アプリ１２０を管理し実行するパネル処理実行部５００を備えている。パネル処理実行部５００も、制御部１０が本発明の制御プログラムを実行することにより実現される。

本実施形態のパネル処理実行部５００は、パネルアプリ５２０を実行することで、操作パネル部１６の動作に対応する処理、各標準アプリ１２０間での共通の処理、及び標準アプリ１２０を呼び出す処理を実行する。
また、パネル処理実行部５００は、標準アプリサービスＩＦ部１１０により標準アプリ１２０を呼び出すか、又は直接、標準アプリ１２０を呼び出す。

パネル処理実行部５００は、パネルアプリ５２０を含んでいる。
パネルアプリ５２０は、操作パネル部１６の処理の専用アプリである。パネルアプリ５２０は、操作パネル部１６の動作に対応する処理、各標準アプリ１２０間での共通の処理、及び標準アプリ１２０を呼び出す処理のプログラムやデータ等を含んでいる。
パネルアプリ５２０は、操作パネル部１６の動作に対応する処理として、例えば、操作パネル部１６の入力部２０からのユーザーの指示や表示部２１への表示等の動作に対応した処理を含んでいてもよい。具体的には、パネルアプリ５２０は、例えば、入力部２０のボタンの状態により各部の状態を表示したり、各標準アプリ１２０や拡張アプリ４００を選択して実行させる画面等を表示したりする処理を含んでいてもよい。
また、パネルアプリ５２０は、各標準アプリ１２０間の共通の処理として、各標準アプリ１２０間で共通で使用されるＧＵＩの入力や表示、各標準アプリ１２０に対応したジョブに関する共通の処理等を含んでいてもよい。また、パネルアプリ５２０は、共通の処理として、例えば、専用のブラウザー等により、共通で使用されるＧＵＩの入力部２０による入力や表示部２１への表示等の処理を含んでいてもよい。また、パネル処理実行部５００は、共通の処理の結果を表示部２１で表示、画像形成部１７で記録、ネットワーク送受信部１５で送信等することで、出力してもよい。また、パネル処理実行部５００は、標準アプリ１２０の管理を行ってもよい。なお、各標準アプリ１２０間の共通の処理は、全ての標準アプリ１２０間で共通でなくてもよく、例えば、二つ以上の標準アプリ１２０間で共通の処理であってもよい。
また、パネルアプリ５２０は、標準アプリ１２０を呼び出す処理として、例えば、標準アプリサービスＩＦ部１１０を介して標準アプリ１２０を呼び出すか、又は、標準アプリ１２０を直接呼び出す処理が含まれていてもよい。また、標準アプリ１２０を呼び出す処理において、標準アプリ１２０の一部を呼び出して機能を利用する処理が含まれていてもよい。
また、パネルアプリ５２０は、製品毎に異なる画面のデータを変更することで、共通の操作体系で使用可能なように構成してもよい。また、パネルアプリ５２０は、拡張アプリ４００を呼び出す処理を含んでいてもよい。
なお、パネルアプリ５２０は、工場出荷時のファームウェアに含まれていてもよい。また、パネルアプリ５２０は、ＯＳインストールサービス３３０によるファームウェアの更新時等に、更新や変更等されてもよい。

〔第五実施形態の画像形成装置によるパネルアプリ実行処理〕
次に、図１７〜図１９を参照して、本発明の第五実施形態に係る画像形成装置によるパネルアプリ実行処理の説明を行う。
本実施形態のパネルアプリ実行処理は、パネルアプリ５２０により、操作パネル部１６の動作に対応する処理、又は標準アプリ１２０間で共通の処理を実行する。また、標準アプリサービスＩＦ部１１０経由、又は直接に、標準アプリ１２０が呼び出される。
本実施形態に係るパネルアプリ実行処理は、主に本実施形態の画像形成装置の制御部１０が、記憶部１９に記憶されたプログラムを、各部と協働しハードウェア資源を用いて実行する。
以下で、図１７のフローチャートを参照して、パネルアプリ実行処理の詳細をステップ毎に説明する。

（ステップＳ５０１）
まず、パネル処理実行部５００が、パネルアプリ実行開始処理を行う。
パネル処理実行部５００は、本実施形態の画像形成装置の電源ボタン（図示せず）がオンにされ、又は操作パネル部１６の入力部２０のボタンの押下により省電力状態から復帰した場合等に、パネルアプリ５２０の実行を開始する。
パネル処理実行部５００は、パネルアプリ５２０の処理により、ユーザーの操作パネル部１６の入力部２０からの指示を取得する。
また、パネル処理実行部５００は、ジョブのデータをネットワーク送受信部１５やＦＡＸ送受信部１８等から取得してもよい。

（ステップＳ５０２）
次に、パネル処理実行部５００が、パネル動作の処理を実行するか否かを判断する。パネル処理実行部５００は、操作パネル部１６の動作に対応する処理を実行する場合は、Ｙｅｓと判断する。パネル処理実行部５００は、それ以外の場合は、Ｎｏと判断する。
Ｙｅｓの場合、パネル処理実行部５００は、処理をステップＳ５０３に進める。
Ｎｏの場合、パネル処理実行部５００は、処理をステップＳ５０４に進める。

（ステップＳ５０３）
パネル動作の処理を実行する場合、パネル処理実行部５００が、パネル動作対応処理を行う。
パネル処理実行部５００は、操作パネル部１６の入力部２０から取得したユーザーの指示に対応したパネル動作の処理を実行する。
パネル処理実行部５００は、例えば、入力部２０の動作モード等のボタンの状態に対応した各部の状態の画像をブラウザー等で描画して、表示部２１に表示する。この場合、パネル処理実行部５００は、各種標準アプリ１２０の取得した各部の状態のデータを記憶部１９から読み出して表示してもよい。また、パネル処理実行部５００は、機器制御プラットフォーム２００により各部の機能を呼び出して、各部の状態を取得してもよい。また、パネル処理実行部５００は、各標準アプリ１２０の機能を呼び出すための選択画面を、表示部２１に表示してもよい。また、パネル処理実行部５００は、拡張アプリ４００の選択やインストールのための画面を表示部２１に表示してもよい。
その後、パネル処理実行部５００は、パネルアプリ実行処理を終了する。なお、パネル処理実行部５００は、パネルアプリ実行処理を終了後、操作パネル部１６の入力部２０からの指示やジョブのデータの取得をまた待つ。

（ステップＳ５０４）
パネル動作の処理を実行しない場合、パネル処理実行部５００が、標準アプリ１２０間で共通の処理を行うか否かを判断する。パネル処理実行部５００は、各標準アプリ１２０間の共通の処理を行う場合、Ｙｅｓと判断する。パネル処理実行部５００は、それ以外の場合、Ｎｏと判断する。
Ｙｅｓの場合、パネル処理実行部５００は、処理をステップＳ５０５に進める。
Ｎｏの場合、パネル処理実行部５００は、処理をステップＳ５０６に進める。

（ステップＳ５０５）
標準アプリ１２０間で共通の処理を行う場合、パネル処理実行部５００が、標準アプリ間共通処理を行う。
パネル処理実行部５００は、ＧＵＩの処理として、例えば、エラー画面や認証画面等の各種画面を操作パネル部１６の表示部２１に表示してもよい。また、パネル処理実行部５００は、各標準アプリ１２０の機能を呼び出すための画面等を表示部２１に表示してもよい。また、パネル処理実行部５００は、例えば、各標準アプリ１２０に対応したジョブに関する共通の処理を実行してもよい。パネルアプリ５２０は、例えば、ネットワーク送受信部１５やＦＡＸ送受信部１８経由で受信した画像データや文書データを、プリンターアプリ１２２はＦＡＸアプリ１２３に送信してもよい。
また、パネル処理実行部５００は、これらの共通の処理の結果を操作パネル部１６の表示部２１等に表示したり、画像形成部１７で記録紙に記録したり、ネットワーク送受信部１５でサーバー（図示せず）や端末等に送信したりして出力してもよい。また、パネル処理実行部５００は、各標準アプリ１２０のインストール、設定の変更、削除等の管理を行うための画面を表示部２１に表示してもよい。
その後、パネル処理実行部５００は、パネルアプリ実行処理を終了する。

（ステップＳ５０６）
ここで、パネル処理実行部５００が、標準アプリ１２０を呼び出すか否かを判断する。パネル処理実行部５００は、ユーザーの指示やジョブのデータ等により、標準アプリ１２０の機能を利用するための呼び出しを行う場合にＹｅｓと判断する。パネル処理実行部５００は、それ以外の場合、つまり操作パネル部１６の動作に対応する処理を行う場合にはＮｏと判断する。
Ｙｅｓの場合、パネル処理実行部５００は、処理をステップＳ５０７に進める。
Ｎｏの場合、パネル処理実行部５００は、パネルアプリ実行処理を終了する。

（ステップＳ５０７）
標準アプリ１２０の呼び出しを行う場合、パネル処理実行部５００が、標準アプリサービスＩＦ部１１０経由で標準アプリ１２０を呼び出すか否かを判断する。パネル処理実行部５００は、標準アプリ１２０の機能を利用するための呼び出しが、標準アプリサービスＩＦ部１１０経由であった場合、Ｙｅｓと判断する。パネル処理実行部５００は、それ以外の場合、つまり、標準アプリ１２０を直接呼び出す場合には、Ｎｏと判断する。
Ｙｅｓの場合、パネル処理実行部５００は、処理をステップＳ５０８に進める。
Ｎｏの場合、パネル処理実行部５００は、処理をステップＳ５０９に進める。

（ステップＳ５０８）
標準アプリサービスＩＦ部１１０経由で標準アプリ１２０を呼び出す場合、パネル処理実行部５００及び標準アプリサービスＩＦ部１１０が、ＩＦ経由標準アプリ実行処理を行う。
図１８によると、パネル処理実行部５００は、呼び出したい標準アプリ１２０の機能を標準アプリサービスＩＦ部１１０に通知する。標準アプリサービスＩＦ部１１０は、この通知に対応した標準アプリ１２０を実行させて機能を利用させ、その結果等をパネル処理実行部５００に通知する。
標準アプリサービスＩＦ部１１０は、例えば、コピーアプリ１２１を呼び出す場合、コピーの開始の画面を操作パネル部１６に表示してもよい。また、標準アプリサービスＩＦ部１１０は、プリンターアプリ１２２を呼び出す場合、拡張アプリ４００が取得したり指定したりした各種ジョブのデータ等を出力させてもよい。また、標準アプリサービスＩＦ部１１０は、ＦＡＸアプリ１２３を呼び出す場合、受信したファクシミリの画像データを指定して拡張アプリ４００に取得させたり、拡張アプリ４００に指定されたファイル等を送信させたりしてもよい。また、標準アプリサービスＩＦ部１１０は、標準アプリ１２０をインストールしたり、削除したり、設定変更をしたりしてもよい。
なお、パネル処理実行部５００は、拡張アプリ４００の選択やインストールに関するユーザーの指示が入力部２０に入力された場合には、標準アプリサービスＩＦ部１１０を介意して拡張アプリプラットフォーム３００へ送信してもよい。
その後、パネル処理実行部５００は、パネルアプリ実行処理を終了する。

（ステップＳ５０９）
直接標準アプリ１２０を呼び出す場合、パネル処理実行部５００が、標準アプリ直接実行処理を行う。
図１９よると、パネル処理実行部５００は、上述の標準アプリサービスＩＦ部１１０と同様に、各標準アプリ１２０を呼び出して機能を利用させてもよい。
また、パネル処理実行部５００は、標準アプリ１２０の機能の一部を呼び出して当該機能を利用させるといった、より標準アプリ１２０の内部の処理に対応した処理を行ってもよい。パネル処理実行部５００は、例えば、コピーアプリ１２１を呼び出す場合、コピーの解像度や色等のプロパティーを取得して、表示部２１に表示してもよい。また、パネル処理実行部５００は、例えば、プリンターアプリ１２２を呼び出す場合、印刷するために記憶部１９に記憶されたジョブや文書ボックス内の文書ファイルの一覧を取得して、表示部２１に表示してもよい。また、パネル処理実行部５００は、例えば、ＦＡＸアプリ１２３を呼び出す場合、ファクシミリ受信した画像データや受信元の一覧や、送信待ちの文書データの一覧等を取得して、表示部２１に表示してもよい。

なお、パネル処理実行部５００は、各標準アプリ１２０を呼び出して実行している状態で、他の標準アプリ１２０の機能の一部を呼び出すような処理を行ってもよい。パネル処理実行部５００は、例えば、ＦＡＸアプリ１２３等の実行時に、このコピーアプリ１２１の文書ファイルの一覧を表示部２１に表示する処理を呼び出してもよい。
また、パネル処理実行部５００は、複数の標準アプリ１２０を呼び出して、ウィンドウやタブ表示で分けて表示させるといった処理を行ってもよい。また、パネル処理実行部５００は、バーチャルマシン等を用いて、保護されたメモリー領域で各標準アプリ１２０を呼び出してもよい。
また、パネル処理実行部５００は、各部の機能を呼び出す場合、プラットフォームサービスＩＦ部２１０により、ハードウェア資源を直接呼び出して利用してもよい。この場合は、プラットフォームサービスＩＦ部２１０が、呼び出された機能に対応する各部制御用サービス２２０の各機能を呼び出して利用させる。
以上により、本実施形態に係るパネルアプリ実行処理を終了する。

以上のように構成することで、以下のような効果を得ることができる。
特許文献１に記載されたような従来のプラットフォームでは、各サービスにかかる画面の制御や、入力部の操作等の制御を各アプリが別々に実行している。このような構成のプラットフォームにおいては、アプリをコピー、プリンター、ＦＡＸ等の機能によって分けている場合、共通する処理であっても各アプリに含める冗長な構成とする必要があり、記憶領域を無駄に消費していた。
これに対して、本実施形態の画像形成装置は、ＯＳ２３０上でハードウェア資源を管理する機器制御プラットフォーム２００と、機器制御プラットフォーム２００で管理されたハードウェア資源を利用する標準アプリ１２０を実行する標準アプリ実行部１００と、標準アプリ実行部１００により実行される標準アプリ１２０から標準アプリサービスＩＦ部１１０に対応した機能を利用させる標準機能サービス３１０、プラットフォームサービスＩＦ部２１０に対応したハードウェア資源を利用させる拡張機能サービス３２０、及び標準機能サービス３１０並びに拡張機能サービス３２０を呼び出し可能な拡張アプリ４００を管理し実行させる拡張アプリ管理部３４０を含む拡張アプリプラットフォーム３００と、拡張アプリプラットフォーム３００とは別に、パネルアプリ５２０を実行することで、ユーザーの指示を取得する操作パネル部１６に対応する処理、複数の標準アプリ１２０間で共通の処理、及び標準アプリ１２０を呼び出す処理を実行するパネル処理実行部５００とを備えることを特徴とする。
このように構成することで、操作パネル部１６にかかる共通の処理がまとめられ、冗長な部分をなくすことが可能な構成となる。つまり、複数の標準アプリ１２０間で共通の処理をまとめることができ、記憶部１９の記憶領域を節約できる。また、必要に応じて、標準アプリ１２０を呼び出す処理を専用のパネル処理実行部５００で実行することで、標準アプリ１２０から標準アプリ１２０を呼び出すような再帰的な呼び出しを行う必要もなくなり、スタック等の記憶容量も節約することができる。

また、従来のプラットフォームでは、複数のアプリ間で共通の処理が製品毎に変更が必要な処理であった場合、プラットフォーム自体に変更が必要になってしまっていた。よって、プラットフォーム側を先行して開発していた場合には、製品開発時にも変更を加える必要があり、プラットフォームの開発者のユーザーに負担が発生していた。また、製品開発のタイミングでのプラットフォームの変更となるため、開発時間がかかってしまっていた。このため、開発コストがかかっていた。
これに対して、本実施形態の画像形成装置は、操作パネル部１６に対応する処理を拡張アプリプラットフォーム３００とは別に、専用の共通の処理をまとめたパネルアプリ５２０としてパネル処理実行部５００で実行する。これにより、製品毎に、パネルアプリ５２０のみ変更するだけでよくなり、プラットフォームの開発者のユーザーに負担がかからなくなる。また、パネルアプリ５２０に配置すべきで、各標準アプリ１２０にまたがるＧＵＩのエラー画面や認証画面といった各標準アプリ１２０で共通な画面について、各標準アプリ１２０の開発時にいちいち作成してテストする必要がなくなる。また、製品毎に変更したいような画面をパネルアプリ５２０に含めることによって、製品毎に効率的な開発を行うことが可能となる。
また、操作パネル部１６の共通の処理においては、パネルアプリ５２０の動作確認のみを行えばよいため、開発時間を短縮できる。また、拡張アプリプラットフォーム３００の完成前であっても、エミュレーター等でパネルアプリ５２０の動作確認を行うことができるため、開発のタイミングに沿って、操作パネル部１６の機能の実装が可能となる。
このため、開発効率を向上させ、開発コストを削減できる。

また、本実施形態の画像形成装置は、階層化された拡張アプリプラットフォーム３００により、拡張アプリ４００から、標準アプリ１２０の機能又は各部に対応するハードウェア資源をそれぞれ利用可能となる。このため、顧客に合わせて構成を変更するカスタマイズが容易となり、開発コストを低減する画像形成装置を提供できる。

また、本実施形態に係る画像形成装置は、標準アプリ実行部１００の外部から標準アプリ１２０の機能を利用するためのインターフェイスを提供する標準アプリサービスＩＦ部１１０を備え、パネル処理実行部５００は、標準アプリサービスＩＦ部１１０により標準アプリ１２０を実行するか、直接、標準アプリ１２０を実行することが可能であることを特徴とする。
このように構成することで、標準アプリサービスＩＦ部１１０により標準アプリ１２０を実行すると、標準アプリ１２０を実行するための処理を容易に実現することが可能となり、開発コストを削減できる。また、パネルアプリ５２０と拡張アプリ４００とで共通するインターフェイスで標準アプリ１２０を呼び出すことが可能となる。よって、操作性や見た目を統一して、ユーザーの使い勝手を向上させることができる。
また、標準アプリサービスＩＦ部１１０により、操作パネル部１６から、各標準アプリ１２０と同様のインターフェイスで拡張アプリプラットフォーム３００、拡張アプリ４００と相互アクセスすることが可能となり、操作パネル部１６と拡張アプリ４００との連携を行うことが容易となる。
一方、パネル処理実行部５００は、直接、標準アプリ１２０を実行することも可能である。これにより、拡張アプリ４００からはアクセスできないような標準アプリ１２０の一部の機能を利用することが可能となる。また、より速度等のパフォーマンスの低下を起こさずに、標準アプリ１２０を使用することが可能となる。これにより、操作パネル部１６から呼び出す必要がある各標準アプリ１２０の機能を柔軟に引き出し、ユーザーのカスタマイズ等の要求を容易に実現することが可能となる。

また、標準アプリ１２０と機器制御プラットフォーム２００とで統一した形式のインターフェイスを提供することが容易となり、拡張アプリ４００を統一した開発環境で作成しやすくなり、開発コストを削減することができる。
また、標準アプリ１２０の機能と、機器制御プラットフォーム２００により利用されるハードウェア資源とを別々に拡張アプリ４００から実行可能となる。このため、拡張アプリ４００の実行時のスピード等のパフォーマンスを向上させることができる。

なお、上述の第五実施形態では、パネル処理実行部５００にてパネルアプリ５２０を実行するように記載したものの、標準アプリ実行部１００によりパネルアプリ５２０を実行してもよい。また、標準アプリサービスＩＦ部１１０に、パネルアプリ５２０の機能が含まれるような構成であってもよい。
このように構成することで、パネル処理実行部５００の開発を容易にし、全体の開発コストを削減することが可能となる。

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

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

本発明の画像形成装置は、制御部を備え、前記制御部は、オペレーティングシステム上でハードウェア資源を管理する機器制御プラットフォームと、該機器制御プラットフォームで管理された前記ハードウェア資源を利用する標準アプリケーションを実行する標準アプリケーション実行部と、該標準アプリケーション実行部により実行される前記標準アプリケーションの機能を利用させる標準機能サービス、前記ハードウェア資源を利用させる拡張機能サービス、及び前記標準機能サービス並びに前記拡張機能サービスをそれぞれ呼び出し可能な拡張アプリケーションを管理し実行させる拡張アプリケーション管理部を含む拡張アプリケーションプラットフォームとを備え、前記機器制御プラットフォームは、特定の機能に対応する前記ハードウェア資源を制御する各部制御用サービスを含み、前記拡張アプリケーション管理部が前記拡張アプリケーションを実行するとき、前記標準機能サービスは、標準アプリケーションを呼び出すか否かを判断し、前記拡張アプリケーションから前記拡張アプリケーション管理部を介した前記標準機能サービスの呼び出しがあると、標準アプリケーションを呼び出し、前記拡張機能サービスは、各部制御用サービスを呼び出すか否かを判断し、前記拡張アプリケーションから前記拡張アプリケーション管理部を介した前記拡張機能サービスの呼び出しがあると、各部制御用サービスを呼び出すことを特徴とする。
本発明の画像形成方法は、ハードウェア資源を備えた画像形成装置により実行される画像形成方法であって、オペレーティングシステム上で前記ハードウェア資源を管理し、機器制御プラットフォームにより、管理された前記ハードウェア資源を利用する標準アプリケーションを実行し、前記標準アプリケーション実行部にて実行される前記標準アプリケーションの機能を利用させる標準機能サービス、前記ハードウェア資源を利用させる拡張機能サービス、及び前記標準機能サービス並びに前記拡張機能サービスをそれぞれ呼び出し可能な拡張アプリケーションを管理し実行させる拡張アプリケーション管理部を含む拡張アプリケーションプラットフォームにより、前記拡張アプリケーションを管理し実行させ、前記機器制御プラットフォームは、特定の機能に対応する前記ハードウェア資源を制御する各部制御用サービスを含み、前記拡張アプリケーション管理部により前記拡張アプリケーションが実行されるとき、前記標準機能サービスは、標準アプリケーションを呼び出すか否かを判断し、前記拡張アプリケーションから前記拡張アプリケーション管理部を介した前記標準機能サービスの呼び出しがあると、標準アプリケーションを呼び出し、前記拡張機能サービスは、各部制御用サービスを呼び出すか否かを判断し、前記拡張アプリケーションから前記拡張アプリケーション管理部を介した前記拡張機能サービスの呼び出しがあると、各部制御用サービスを呼び出すことを特徴とする。

Claims (19)

1. 制御部を備え、前記制御部は、
   オペレーティングシステム上でハードウェア資源を管理する機器制御プラットフォームと、
   該機器制御プラットフォームで管理された前記ハードウェア資源を利用する標準アプリケーションを実行する標準アプリケーション実行部と、
   該標準アプリケーション実行部により実行される前記標準アプリケーションの機能を利用させる標準機能サービス、前記ハードウェア資源を利用させる拡張機能サービス、及び前記標準機能サービス並びに前記拡張機能サービスをそれぞれ呼び出し可能な拡張アプリケーションを管理し実行させる拡張アプリケーション管理部を含む拡張アプリケーションプラットフォームとを備える
   ことを特徴とする画像形成装置。
2. 前記拡張アプリケーションプラットフォームは、前記オペレーティングシステムに機能を追加するためのオペレーティングシステムインストールサービスを備える
   ことを特徴とする請求項１に記載の画像形成装置。
3. 前記標準アプリケーション実行部の外部から前記標準アプリケーションの機能を利用するためのインターフェイスを提供する標準アプリケーションサービスインターフェイス部と、
   前記機器制御プラットフォームの外部から前記ハードウェア資源を利用するためのインターフェイスを提供するプラットフォームサービスインターフェイス部とを備える
   ことを特徴とする請求項１に記載の画像形成装置。
4. 前記標準アプリケーションには、機能の拡張に対応した前記ハードウェア資源を利用するための汎用インターフェイスが設けられ、
   前記汎用インターフェイスは、前記拡張機能サービスによる設定によって利用可能とされている
   ことを特徴とする請求項１に記載の画像形成装置。
5. 前記拡張機能サービスによる設定は、前記拡張機能サービスの更新によって行われる
   ことを特徴とする請求項１に記載の画像形成装置。
6. 前記機器制御プラットフォームの外部から前記拡張機能サービスに対応した前記ハードウェア資源を利用するためのインターフェイスを提供するプラットフォームサービスインターフェイス部を更に備え、
   前記機器制御プラットフォームは、前記プラットフォームサービスインターフェイス部を介して利用される前記ハードウェア資源の各機能に対応した共通のインターフェイスを含むコンポーネントを組み合わせて構成される各部制御用サービスを含む
   ことを特徴とする請求項１に記載の画像形成装置。
7. 前記各部制御用サービスの前記コンポーネントは、複数の階層に対応して配置され、前記階層間で接続されて構成される
   ことを特徴とする請求項６に記載の画像形成装置。
8. 前記標準アプリケーション実行部の外部から前記拡張機能サービスに対応した前記標準アプリケーションの機能を利用するためのインターフェイスを提供する標準アプリケーションサービスインターフェイス部を備える
   ことを特徴とする請求項６に記載の画像形成装置。
9. 前記機器制御プラットフォームの外部から前記標準アプリケーションの機能の拡張に対応した前記ハードウェア資源を利用するための汎用インターフェイスを有しているプラットフォームサービスインターフェイス部とを備える
   ことを特徴とする請求項１に記載の画像形成装置。
10. 前記機器制御プラットフォームは、画像処理に関わるサービスを提供する画像処理サービスを有し、
    機能が拡張された前記標準アプリケーションからの要求に従い、前記画像処理サービスの処理に伴って前記汎用インターフェイスが提供される
    ことを特徴とする請求項９に記載の画像形成装置。
11. 前記拡張アプリケーションプラットフォームとは別に、ユーザーの指示を取得する操作パネル部に対応する処理、複数の前記標準アプリケーション間での共通の処理、及び前記標準アプリケーションを呼び出す処理を実行するパネル処理実行部とを備える
    ことを特徴とする請求項１に記載の画像形成装置。
12. 前記標準アプリケーション実行部の外部から前記標準アプリケーションの機能を利用するためのインターフェイスを提供する標準アプリケーションサービスインターフェイス部を備え、
    前記パネル処理実行部は、前記標準アプリケーションサービスインターフェイス部により前記標準アプリケーションを呼び出す
    ことを特徴とする請求項１１に記載の画像形成装置。
13. ハードウェア資源を備えた画像形成装置により実行される画像形成方法であって、
    オペレーティングシステム上で前記ハードウェア資源を管理し、
    管理された前記ハードウェア資源を利用する標準アプリケーションを実行し、
    実行される前記標準アプリケーションの機能を利用させ、前記ハードウェア資源を利用させる拡張アプリケーションを管理し実行させる
    ことを特徴とする画像形成方法。
14. 前記標準アプリケーションには、機能の拡張に対応した前記ハードウェア資源を利用するための汎用インターフェイスが設けられ、
    前記汎用インターフェイスは、前記拡張機能サービスによる設定によって利用可能とされている
    ことを特徴とする請求項１３に記載の画像形成方法。
15. 前記拡張機能サービスによる設定は、前記拡張機能サービスの更新によって行われる
    ことを特徴とする請求項１３に記載の画像形成方法。
16. 外部から前記ハードウェア資源を利用するためのインターフェイスを提供し、
    利用される前記ハードウェア資源の各機能に対応した共通のインターフェイスを含むコンポーネントを組み合わせて前記ハードウェア資源を管理する
    ことを特徴とする請求項１３に記載の画像形成方法。
17. プラットフォームサービスインターフェイス部により前記機器制御プラットフォームの外部から前記標準アプリケーションの機能の拡張に対応した前記ハードウェア資源を利用するための汎用インターフェイスを提供する
    ことを特徴とする請求項１３に記載の画像形成方法。
18. 前記機器制御プラットフォームに含まれる、画像処理に関わるサービスを提供する画像処理サービスの処理に伴い、機能が拡張された前記標準アプリケーションからの要求に従って前記汎用インターフェイスが提供される
    ことを特徴とする請求項１７に記載の画像形成方法。
19. 前記拡張アプリケーションの管理と実行とは別に、ユーザーの指示を取得する操作パネル部に対応する処理、複数の前記標準アプリケーション間での共通の処理、及び前記標準アプリケーションを呼び出す処理を実行する
    ことを特徴とする請求項１３に記載の画像形成方法。

Images