JP2016100731A - 情報処理装置およびその制御方法、並びにプログラム - Google Patents

Abstract

【課題】画像処理装置上でバックグラウンド処理が実行された場合に、並列実行されるアプリケーションの実行処理速度が低下することのない情報処理装置及びその制御方法、並びにプログラムを提供する。【解決手段】バックグラウンドで処理を実行可能な情報処理装置１０１であって、アプリケーションからの要求に応じて処理が実行される際に、バックグラウンドにおける別の処理の実行を制御する制御手段を備える。制御手段は、アプリケーションからの要求に応じて、別の処理がバックグラウンドにて実行されないように抑制し、アプリケーションから抑制の解除の要求が指示されない場合、抑制を開始してから所定の期間が経過した際に、抑制を解除する。【選択図】図３

Description

本発明は、情報処理装置およびその制御方法、並びにプログラムに関する。

近年、画像処理装置では、自身の有するプログラムをバックグラウンドで実行させるものが存在する。例えば、特許文献１では、指示された処理の実行に長時間を要すると判断すると、その旨の警告と、ログイン中のユーザに対してログアウトの実行の可否を問合せるメッセージを画像形成装置上に表示する。ユーザによりログアウトの実行が選択されると、画像処理装置は、ユーザをログアウトさせ、指示された処理をバックグラウンド処理として実行する。これにより、指示された処理が長時間を要するような場合でも、画像処理装置はユーザがログアウトを行った上で当該処理を実行できる。

一方、画像処理装置は、一般的にスキャナやプリンタなどの各種機能をアプリケーション単位で動作させるアプリケーションプラットフォームを有している。アプリケーションプラットフォーム上で稼働するアプリケーションと画像処理装置が実行するバックグラウンド処理は、画像処理装置によりマルチタスクで処理され並列に実行される。そのため、画像処理装置がバックグラウンド処理としてＣＰＵを使用する処理を行うと、例えば画像処理装置上の操作画面に表示するＵＩ画面を提供するアプリの操作性が低下するなど、パフォーマンス低下の影響を与えてしまう。

そこで、特許文献２では、バックグラウンド処理を実行不可とするアプリケーションが起動中の場合はバックグラウンド処理を保留し、バックグラウンド処理を実行可とするアプリが起動中の場合はバックグラウンド処理を行うという制御を行う。

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

特許文献２は、アプリケーションを構成するプログラムに事前にバックグラウンド処理の実行可否の情報を定義し、その情報に基づいてバックグラウンド処理の制御を行っている。一方、画像処理装置において、多様な実行形態のアプリケーションに対し画像処理装置が実行可否の情報と起動状態のみでバックグラウンド処理の実行の制御を行うと、バックグラウンド処理を実行不可能な状態に陥れてしまう場合がある。例えば、Ｗｅｂアプリケーションとして提供されるアプリケーションでは、情報処理装置からアクセスされている限り、画像処理装置はアプリケーションを起動中と判定する。このため、Ｗｅｂアプリケーションがバックグラウンド処理を実行不可と宣言していると、ユーザが操作しているかどうかに関わらず、アクセスされている限り画像処理装置はバックグラウンド処理を実行できない。また、画像処理装置上の操作画面にＵＩ画面を表示するアプリケーションの場合、アプリケーションが障害により起動状態のまま処理を停止したとすると、画像処理装置はバックグラウンド処理を抑制し続けることとなる。その場合、画像処理装置は、アプリケーションを強制的に終了しない限りバックグラウンド処理を実行できなくなる。

本発明は上記問題を鑑み、より適切なバックグラウンド処理の抑制の制御を行うことを目的とする。

上記課題を解決するために本願発明は以下の構成を有する。すなわち、バックグラウンドで処理を実行可能な情報処理装置であって、アプリケーションからの要求に応じて処理が実行される際に、バックグラウンドにおける別の処理の実行を制御する制御手段を備え、前記制御手段は、前記アプリケーションからの要求に応じて、前記別の処理がバックグラウンドにて実行されないように抑制し、前記アプリケーションから前記抑制の解除の要求が指示されない場合、前記抑制を開始してから所定の期間が経過した際に、前記抑制を解除する。

本発明によれば、バックグラウンド処理からの影響を抑え、アプリケーションを安定して動作させることが可能となる。また、バックグラウンド処理の実行を必要以上に抑制する状態を避けることが可能となる。

第一の実施形態に係るシステムの構成例の図。 第一の実施形態に係る各装置のハードウェア構成例の図。 第一の実施形態に係る各装置のソフトウェア構成例の図。 第一の実施形態に係るプログラム例を示す図。 第一の実施形態に係るＡＰＩの定義例を示す図。 第一の実施形態に係る処理のフローチャート。 第一の実施形態に係るシーケンス図。 第二の実施形態に係るアプリケーションの構成例を示す図。 第二の実施形態に係るアプリケーション管理テーブルの構成例を示す図。 第二の実施形態に係る処理のフローチャート。 第二の実施形態に係る処理のフローチャート。 第三の実施形態に係る処理のフローチャート。

以下、本発明を実施するための形態について図面を用いて説明する。なお、以下の説明においてバックグラウンドを「ＢＧ」と記載し、プラットフォームを「ＰＭ」と記載する。また、アプリケーションを単に「アプリ」と記載する。

＜第一の実施形態＞
［システム構成］
本実施形態のシステム構成について、図１〜図３を用いて説明する。

図１は、本実施形態に係るシステム全体の構成例を示す。本システムは、ネットワーク１０２を介して、画像処理装置１００と情報処理装置１０１とが通信可能に接続される。画像処理装置１００は、画像形成装置、画像読取装置、画像送信機能などの各種画像処理機能を有する情報処理装置である。なお、画像処理装置１００は、プリンタ、コピー、ファクス及びスキャナや、それら複数の機能を一台の筐体で実現するＭＦＰ（Ｍｕｌｔｉ Ｆｕｎｃｔｉｏｎ Ｐｅｒｉｐｈｅｒａｌ）でもよく、特に限定するものではない。情報処理装置１０１は、Ｗｅｂブラウザなどを介し、画像処理装置１００の操作をリモートで行うことが可能な、ＰＣ（Ｐｅｒｓｏｎａｌ Ｃｏｍｐｕｔｅｒ）や携帯端末などの情報処理装置である。

図２は、本実施形態の画像処理装置１００と情報処理装置１０１のハードウェアの構成例を示す。画像処理装置１００は、情報処理装置１０１と通信を行うネットワーク装置２０１、キーボードなどユーザ操作を受け付けるユーザ入力装置２０２、液晶ディスプレイなど操作画面を表示するＵＩ表示装置２０３を有する。

更に画像処理装置１００は、装置全体を制御するＣＰＵ２０４、ワークスペースとして利用可能なＲＡＭ２０５、画像原稿を読み取る読取装置２０６、印刷動作を行う印刷装置２０７、および各種制御プログラムを記憶する記憶装置２０８を有する。画像処理装置１００を構成する各部位は、メインバス２００で接続され、相互にデータの送受信が可能である。なお、ユーザ入力装置２０２とＵＩ表示装置２０３を別々の装置として記載しているが、これらの装置が一体となった操作部が備えられてもよい。

情報処理装置１０１は、外部装置と通信を行うネットワーク装置２１１、装置全体を制御するＣＰＵ２１２、ワークスペースとして利用可能なＲＡＭ２１３、および各制御プログラムを記憶する記憶装置２１４を有する。また、情報処理装置１０１を構成する各部位は、メインバス２１０で接続され、相互にデータの送受信が可能である。

図３は、本実施形態の画像処理装置１００と情報処理装置１０１のソフトウェアの構成例を示す。図３に示す各機能部は、画像処理装置１００および情報処理装置１０１それぞれが有するＣＰＵ２０４、２１２が、記憶装置２０８、２１４に記憶される制御プログラムをＲＡＭ２０５、２１３上に読み出して実行することで実現される。

まず、情報処理装置１０１が備えるソフトウェアについて説明する。情報処理装置１０１は、通信部３００、Ｗｅｂブラウザ３１０を有する。通信部３００は、ネットワーク装置２１１を制御してＨＴＴＰ（Ｈｙｐｅｒ Ｔｅｘｔ Ｔｒａｎｓｆｅｒ Ｐｒｏｔｏｃｏｌ）通信を行うソフトウェアである。Ｗｅｂブラウザ３１０は、通信部３００を介して、画像処理装置１００のアップデート管理部３７１、ライフサイクル管理部３７３などのアプリから提供される操作画面（不図示）を表示する。また、Ｗｅｂブラウザ３１０は、表示された操作画面を通じて入力されたユーザからの入力情報を、通信部３００を介して画像処理装置１００へ送信する。なお、本実施形態では、画像処理装置１００との通信にＷｅｂブラウザ３１０を用いているが、アプリと通信するためのプロトコルに対応したソフトウェア構成であればよく、これに限定するものではない。

次に、画像処理装置１００が備えるソフトウェアについて説明する。画像処理装置１００は、ＯＳ（Ｏｐｅｒａｔｉｎｇ Ｓｙｓｔｅｍ）３２０、ＪａｖａＶＭ３２１、システム制御部３３０、アプリＰＦ３４０を有する。ＯＳ３２０は、プロセスの管理、メモリ管理及び入出力管理を実行する。ＪａｖａＶＭ３２１は、Ｊａｖａ（登録商標）プログラムを実行する仮想マシンであり、アプリＰＦ３４０の実行基盤である。

システム制御部３３０は、コピーなど画像処理装置１００の基本的な機能を実現するプログラムであり、ＢＧ処理管理部３３１を有する。ＢＧ処理管理部３３１は、予めＢＧ処理であると定義されているプロセスの実行指示を受信した際、アプリＰＦ３４０などの別プロセスがＢＧ処理抑制フラグを立てているか（つまり、ＢＧ処理抑制フラグが“ｔｒｕｅ”か否か）問い合わせる。ＢＧ処理制御フラグの詳細については、後述する。別プロセス全てにおいてＢＧ処理抑制フラグが“ｔｒｕｅ”でなければ、ＢＧ処理管理部３３１は、ＢＧ処理の実行を該当するプロセスに指示する。別プロセスにおいて一つでもＢＧ処理抑制フラグが“ｔｒｕｅ”である場合、ＢＧ処理管理部３３１は、ＢＧ処理の実行は指示せずＢＧ処理抑制フラグの解除待ち状態となる。ＢＧ処理管理部３３１は、定期的に別プロセスのＢＧ処理抑制フラグの状態を確認し、別プロセス全てにおいてＢＧ処理抑制フラグが“ｆａｌｓｅ”なるまでＢＧ処理の実行を待機する。また、ＢＧ処理管理部３３１は、該当するプロセスにＢＧ処理の実行を指示した後も定期的に別プロセスのＢＧ処理抑制フラグの状態を確認する。そして、ＢＧ処理実行中に別プロセスで新たにＢＧ処理抑制フラグが“ｔｒｕｅ”となったことを検知した場合、ＢＧ処理管理部３３１は、該当するプロセスにＢＧ処理の実行の中断を指示し、ＢＧ処理抑制フラグの解除待ち状態となる。

アプリＰＦ３４０は、制御ＡＰＩ（Ａｐｐｌｉｃａｔｉｏｎ Ｐｒｏｇｒａｍ Ｉｎｔｅｒｆａｃｅ）を介して画像処理装置１００を制御するアプリを実行可能な実行基盤である。アプリＰＦ３４０は、フレームワーク３５０、およびアプリ記憶領域３６０を有する。フレームワーク３５０は、アプリのライフサイクル管理や依存関係管理を行うＯＳＧｉ（Ｏｐｅｎ Ｓｅｒｖｉｃｅｓ Ｇａｔｅｗａｙ ｉｎｉｔｉａｔｉｖｅ；登録商標）３５１、およびプラットフォームを構成するクラスライブラリ群３５２を有する。ライフサイクル管理や依存関係管理については、従来の技術を利用するものとし、ここでの詳細な説明は省略する。アプリ記憶領域３６０は、記憶装置２０８に保存されフレームワーク３５０上で管理されるアプリを記憶する。アプリ記憶領域３６０は、システムアプリ部３７０、およびアプリ部３８０を有する。

システムアプリ部３７０は、アプリＰＦ３４０を構成する機能を提供するアプリ群で構成される。システムアプリ部３７０は、アップデート管理部３７１、およびライフサイクル管理部３７３を有する。アップデート管理部３７１は、記憶装置２０８に書き込まれたファームウェアの更新を、フレームワーク３５０を介してシステム制御部３３０に指示するアプリケーションである。ライフサイクル管理部３７３は、フレームワーク３５０へ指示を出し、アプリ記憶領域３６０上のアプリのライフサイクル管理を行うアプリケーションである。また、アップデート管理部３７１およびライフサイクル管理部３７３は、アプリの操作を行う操作部（不図示）を提供し、通信部３７２／通信部３７４によりネットワーク装置２０１を介した情報処理装置１０１からのＨＴＴＰ通信によるアプリの操作指示を受信する。本実施形態では、アップデート管理部３７１およびライフサイクル管理部３７３は、ＪａｖａＳｅｒｖｌｅｔによるＷｅｂアプリとして説明するが、情報処理装置１０１と通信し操作部を提供するものであれば、これに限定するものではない。

アプリ部３８０は、画像処理装置１００を制御するためのアプリで構成される。本実施形態では、アプリ部３８０は、画像処理装置１００を制御するアプリとしてアプリＡ３８１を有する。また、アプリＡ３８１は、画像処理装置１００の制御を指示する際に、アプリＰＦ３４０から提供されるＢＧ処理抑制ＡＰＩを実行する機能を有する。

本実施形態における、アプリＡ３８１によるＢＧ処理抑制指示の実行方法、アプリＰＦ３４０が提供するＢＧ処理抑制ＡＰＩの構成、及びＢＧ処理抑制指示方法を、図４〜図６を用いて説明する。

図４は、アプリＡ３８１が、画像処理装置１００に対しＢＧ処理の抑制を含む制御指示を行うプログラムの一例を示す。アプリＡ３８１は、ＢＧ処理の抑制を含む制御指示を実行するＢＧ処理抑制処理部（記述４００）を有する。記述４００は、記述４０１〜４０３を有する。

記述４０１は、アプリＡ３８１が、アプリＰＦ３４０から提供されるＢＧ処理抑制ＡＰＩを実行しＢＧ処理の抑制を指示する定義部である。本実施形態では、アプリＡ３８１は、第一引数にアプリ名、第二引数に“１５０００”、第三引数に“ｔｒｕｅ”を取り、ＢＧ処理抑制ＡＰＩを実行する。なお、ＡＰＩの定義及び処理に関しては、図５、図６を用いて後述する。

記述４０２は、アプリＡ３８１が、画像処理装置１００の制御を指示するアプリ固有の定義部である。本実施形態では、例えばＵＩ表示装置２０３に操作画面を提供する操作部からの応答処理を行うなど、画像処理装置１００がＢＧ処理を実行しているとパフォーマンス低下の影響を受ける処理であるとする。

記述４０３は、アプリＡ３８１が、アプリＰＦ３４０から提供されるＢＧ処理抑制解除ＡＰＩを実行し、ＢＧ処理の抑制解除を指示する定義部である。本実施形態では、アプリＡ３８１は、第一引数にアプリ名を取り、ＢＧ処理抑制解除ＡＰＩを実行するものとする。なお、ＡＰＩの定義及び処理に関しては、図５、図６を用いて後述する。

図５は、アプリＰＦ３４０がクラスライブラリ群３５２としてアプリに提供する、画像処理装置１００のＢＧ処理抑制、及び抑制解除するための制御指示ＡＰＩの定義部分（クラス）の一例である。アプリＰＦ３４０は、ＢＧ処理管理部３３１に対してＢＧ処理の抑制制御指示を実行する、ＢＧ処理抑制ＡＰＩ部（記述５００）及びＢＧ処理の抑制解除制御指示を実行するためのＢＧ処理抑制解除ＡＰＩ部（記述５０１）を有する。

記述５００は、記述５０２、５０３を有する。記述５０２は、ＢＧ処理抑制ＡＰＩであるｓｅｔＢａｃｋｇｒｏｕｎｄＤｉｓａｂｌｅｄ関数の定義部である。記述５０２は、引数としてｋｅｙ（実行を指示したアプリの識別用オブジェクト）、ｄｉｓａｂｌｅｄＴｉｍｅ（ＢＧ処理の抑制期間）、ｄｉｓａｂｌｅｄＣａｎｃｅｌＦｌａｇ（ＢＧ処理抑制解除フラグ）を受け取る。その後、記述５０２は、受け取った引数にｓｅｔＢａｃｋｇｒｏｕｎｄＤｉｓａｂｌｅｄ関数の実行を表すフラグ（“ｔｒｕｅ”）を第一引数として加え、実処理としてｓｅｔＢａｃｋｇｒｏｕｎｄＩｎｈｉｂｉｔＳｔａｔｕｓ関数（記述５１０）を実行する。ここで第一引数として追加されるフラグを以下、「ＢＧ処理抑制フラグ」と呼ぶ。なお、記述５１０の内部処理の詳細は、図６を用いて後述する。

記述５０１で引数に指定するパラメータを説明する。第一引数ｋｅｙは、記述５０２のＢＧ処理抑制ＡＰＩを実行したアプリの識別用オブジェクトを指定する。これは、アプリＰＦ３４０が、ＢＧ処理の抑制を指示したアプリを特定するために使用する。そのため、ＢＧ処理の抑制を指示したアプリを一意に特定できればいずれの値を用いてもよく、本実施形態では、第一引数ｋｅｙとして、実行したアプリ名を設定するものとする。第二引数ｄｉｓａｂｌｅｄＴｉｍｅは、アプリがＢＧ処理を抑制する所定の期間を指定する。アプリＰＦ３４０は、記述５１０の内部処理で抑制期間のカウント処理を行い、カウントがゼロになったタイミングでＢＧ処理管理部３３１に対しＢＧ処理の抑制解除指示を行う。ここで、抑制期間として指定される値の単位は、どのようなものを用いてもよい。第三引数ｄｉｓａｂｌｅｄＣａｎｃｅｌＦｌａｇは、画像処理装置１００において特定のイベント発生時に、ＢＧ処理管理部３３１に対しＢＧ処理の抑制解除指示を実行するか否かを判定するためのＢＧ処理抑制解除フラグを指定する。なお、本実施形態において、特定のイベントとは、画像処理装置１００のシステムがスリープ状態に遷移する、または、ＵＩ表示装置２０３上の表示中画面がデフォルト画面へ遷移するイベントとする。

第三引数に“ｔｒｕｅ”を指定した場合、特定のイベント発生時に、ＢＧ処理管理部３３１に対しＢＧ処理の抑制解除指示を行う。つまり、特定のイベントが発生した場合には、ＢＧ処理の抑制を強制的に解除することとなる。ここで、スリープ状態遷移イベントとは、例えば、ユーザ入力装置２０２からの操作が何もないなど画像処理装置１００が一定期間動作していない状態で発生する省電力モードへの移行イベントである。また、デフォルト画面遷移イベントとは、スリープ状態遷移イベントと同様の条件下で発生する、ＵＩ表示装置２０３の表示を自動的にデフォルト画面（ホーム画面など）に戻すイベントである。すなわち、本実施形態において、特定のイベントは、画像処理装置１００の動作が待機状態に発生するものと定義され、アプリがＢＧ処理の抑制制御指示を実行する必要がない状態と判断できる。したがって、このようなイベントの発生を、抑制解除フラグの条件とする。なお、抑制解除フラグの条件は、画像処理装置１００の動作が待機状態と判断できる状態遷移イベントであればよく、これらに限定するものではない。

図５におけるＡＰＩの実装定義部分の説明に戻る。記述５０３は、記述５０２と同様にＢＧ処理抑制ＡＰＩであるｓｅｔＢａｃｋｇｒｏｕｎｄＤｉｓａｂｌｅｄ関数の定義部である。記述５０３は、引数として、第一引数ｋｅｙ、および第二引数ｄｉｓａｂｌｅｄＴｉｍｅを受け取る。その後、記述５０３は、受け取った引数に抑制解除フラグを示すｄｉｓａｂｌｅｄＣａｎｃｅｌＦｌａｇの値を“ｔｒｕｅ”として加えてｓｅｔＢａｃｋｇｒｏｕｎｄＤｉｓａｂｌｅｄ関数（記述５０２）を実行する。従って、アプリがＢＧ処理抑制ＡＰＩ部（記述５００）で提供されるＡＰＩを利用したＢＧ処理の抑制指示を行う場合、アプリは少なくともアプリ名などの自身のアプリの識別用オブジェクト、及びＢＧ処理の抑制期間を指定する必要がある。

記述５０１は、記述５０４を有する。記述５０４は、ＢＧ処理抑制解除ＡＰＩであるｓｅｔＢａｃｋｇｒｏｕｎｄＥｎａｂｌｅｄ関数の定義部である。記述５０４は、引数として、第一引数にｋｅｙ（実行したアプリの識別用オブジェクト）を受け取る。その後、記述５０４は、受け取った引数にｓｅｔＢａｃｋｇｒｏｕｎｄＥｎａｂｌｅｄ関数の実行を表すフラグ（“ｆａｌｓｅ”）を第一引数として加え、実処理としてｓｅｔＢａｃｋｇｒｏｕｎｄＩｎｈｉｂｉｔＳｔａｔｕｓ関数（記述５１１）を実行する。記述５０４の第一引数は、ｓｅｔＢａｃｋｇｒｏｕｎｄＤｉｓａｂｌｅｄ関数（記述５０２、５０３）の実行時に指定したｋｅｙと同一のものを指定し、本実施形態では実行したアプリ名を指定する。これは、アプリＰＦ３４０が、ＢＧ処理の抑制を指示していたアプリの抑制解除指示であることを特定するために使用される。また、記述５１１の内部処理では、記述５０４が実行された場合、ＢＧ処理の抑制期間、及びイベント発生時のＢＧ処理抑制解除フラグを考慮する必要がない。そのため、記述５０４の実行においては、記述５０２のようなｄｉｓａｂｌｅｄＴｉｍｅ、ｄｉｓａｂｌｅｄＣｈａｎｃｅｌＦｌａｇの指定を必要としていない。かつ、記述５０４では、記述５１１の実行のため内部的に適当な値を引数に設定している。本実施形態では、引数の値を順に“ｆａｌｓｅ”、ｋｅｙ（アプリ名）、“０”、“ｆａｌｓｅ”とする。

［処理フロー］
図６（ａ）は、アプリＰＦ３４０がクラスライブラリ群３５２としてアプリに提供する、画像処理装置１００のＢＧ処理を抑制及び抑制解除する制御指示を行うＡＰＩの内部処理のフローチャートである。すなわち、本処理は、図５で定義されるＢＧ処理抑制ＡＰＩ部（記述５００）及びＢＧ処理抑制解除ＡＰＩ部（記述５０１）が内部的に実行するｓｅｔＢａｃｋｇｒｏｕｎｄＩｎｈｉｂｉｔＳｔａｔｕｓ関数（記述５１０、５１１）の処理である。また、図６（ｂ）（ｃ）はそれぞれ、処理に付随してアプリＰＦ３４０が並列処理で実行する、イベント検知処理及びＢＧ処理抑制期間のカウント処理のフローチャートを示す。なお、図６中において、破線矢印は、処理中で用いられる値等の更新に伴って、他の処理の開始や判定の契機となるタイミングを示す。

まず、図６（ａ）を用いてｓｅｔＢａｃｋｇｒｏｕｎｄＩｎｈｉｂｉｔＳｔａｔｕｓ関数の処理について説明する。アプリからＢＧ処理抑制ＡＰＩ部（記述５００）またはＢＧ処理抑制解除ＡＰＩ部（記述５０１）が実行されると、Ｓ６０１にて、アプリＰＦ３４０は、アプリが実行したＡＰＩの判定を行う。この判定では、ｓｅｔＢａｃｋｇｒｏｕｎｄＩｎｈｉｂｉｔＳｔａｔｕｓ関数の第一引数で指定されるパラメータを用いる。パラメータが“ｔｒｕｅ”ならばｓｅｔＢａｃｋｇｒｏｕｎｄＤｉｓａｂｌｅｄ関数（記述５０２、５０３）が実行され、パラメータが“ｆａｌｓｅ”ならばｓｅｔＢａｃｋｇｒｏｕｎｄＥｎａｂｌｅｄ関数（記述５０１）が実行されたものとみなす。

ｓｅｔＢａｃｋｇｒｏｕｎｄＤｉｓａｂｌｅｄ関数が実行された場合（Ｓ６０１にてＹＥＳ）、Ｓ６０２にて、アプリＰＦ３４０は、実行したアプリの抑制解除フラグの指定を判定する。この判定には、ｓｅｔＢａｃｋｇｒｏｕｎｄＩｎｈｉｂｉｔＳｔａｔｕｓ関数（記述５１０）の第四引数で指定されるパラメータを用いる。フラグの指定が“ｔｒｕｅ”の場合（Ｓ６０２にてＹＥＳ）で、かつ、初回に行われる処理の場合、Ｓ６０３にて、アプリＰＦ３４０は、画像処理装置１００で所定のイベント（ここでは、スリープ／デフォルト画面遷移イベント）が発生したことを受け取るリスナーの登録を行う。初回でない場合は、リスナーの登録は行われない。イベント検知時の処理は、アプリＰＦ３４０において、ｓｅｔＢａｃｋｇｒｏｕｎｄＩｎｈｉｂｉｔＳｔａｔｕｓ関数（記述５１０）の処理と並列して実行される。

その後、Ｓ６０４にて、アプリＰＦ３４０は、実行を指示したアプリがｔｒｕｅの実行アプリ名のリストに登録済みのアプリか否かを判定する。ｔｒｕｅの実行アプリ名のリストとは、ＢＧ処理抑制ＡＰＩ部（記述５００）を実行したアプリ名を保存するものであり、プログラム上の可変長配列の変数などで定義される。なお、この判定には、ｓｅｔＢａｃｋｇｒｏｕｎｄＩｎｈｉｂｉｔＳｔａｔｕｓ関数（記述５１０）の第二引数で指定されるパラメータを用いる。

ｔｒｕｅの実行アプリ名のリストに実行を指示したアプリが登録済みである場合（Ｓ６０４にてＹＥＳ）、Ｓ６０７へ進む。ｔｒｕｅの実行アプリ名のリストに実行を指示したアプリが登録済みではない場合（Ｓ６０４にてＮＯ）、Ｓ６０５にて、アプリＰＦ３４０は、ｔｒｕｅの実行アプリ名のリストにアプリ名を登録する。その後、Ｓ６０６にて、アプリＰＦ３４０は、ｔｒｕｅの実行アプリカウント数をインクリメントする。ｔｒｕｅの実行アプリカウント数とは、ＢＧ処理抑制ＡＰＩ部（記述５００）を実行したアプリ数を保存するものであり、プログラム上の整数型の変数などで定義される。実行アプリカウント数は、後述するＢＧ処理抑制フラグの状態の更新判定に用いられる。Ｓ６０７にて、アプリＰＦ３４０は、スレッドが存在しない場合のみ、アプリの指定したＢＧ処理を抑制する期間の時間経過をカウントするためのスレッドを作成する。このスレッドは、図６（ｃ）に示す、アプリＰＦ３４０における、カウントスレッド６４０の処理としてｓｅｔＢａｃｋｇｒｏｕｎｄＩｎｈｉｂｉｔＳｔａｔｕｓ関数（記述５１０）の処理と並列して実行される。

Ｓ６０８にて、アプリＰＦ３４０は、アプリが指定したＢＧ処理を抑制する期間の設定更新処理を行う。ここでの設定更新には、ｓｅｔＢａｃｋｇｒｏｕｎｄＩｎｈｉｂｉｔＳｔａｔｕｓ関数（記述５１０）の第三引数で指定されるパラメータを用いる。カウントスレッド６４０の処理内でカウント中のｔｒｕｅの実行アプリ抑制期間に対し、アプリＰＦ３４０は、アプリ指定のパラメータで指定される抑制期間との論理和を取ることで更新を行う。更新されたｔｒｕｅの実行アプリ抑制期間は、図６（ｃ）に示すカウントスレッド６４０の処理内で参照される。その後、Ｓ６１４へ進む。

同様に、フラグの指定が“ｆａｌｓｅ”の場合には、（Ｓ６０２にてＮＯ）Ｓ６０９にて、アプリＰＦ３４０は、実行を指示したアプリがｆａｌｓｅの実行アプリ名のリストに登録済みのアプリか否かを判定する。ｆａｌｓｅの実行アプリ名のリストは、ＢＧ処理抑制ＡＰＩ部（記述５００）を実行したアプリ名を保存するものであり、プログラム上の可変長配列の変数などで定義される。なお、この判定には、ｓｅｔＢａｃｋｇｒｏｕｎｄＩｎｈｉｂｉｔＳｔａｔｕｓ関数（記述５１０）の第二引数で指定されるパラメータを用いる。

ｆａｌｓｅの実行アプリ名のリストに実行を指示したアプリが登録済みである場合（Ｓ６０９にてＹＥＳ）、Ｓ６１２へ進む。ｆａｌｓｅの実行アプリ名のリストに実行を指示したアプリが登録済みではない場合（Ｓ６０９にてＮＯ）、Ｓ６１０にて、アプリＰＦ３４０は、ｆａｌｓｅの実行アプリ名のリストにアプリ名を登録する。その後、Ｓ６１１にて、アプリＰＦ３４０は、ｆａｌｓｅの実行アプリカウント数をインクリメントする。ｆａｌｓｅの実行アプリカウント数は、ＢＧ処理抑制ＡＰＩ部（記述５００）を実行したアプリ数を保存するものであり、プログラム上の整数型の変数などで定義される。実行アプリカウント数は、後述するＢＧ処理抑制のフラグの状態の更新判定にて用いられる。Ｓ６１２にて、アプリＰＦ３４０は、スレッドが存在しない場合のみ、アプリの指定したＢＧ処理を抑制する期間の時間経過をカウントするためのスレッドを作成する。このスレッドは、アプリＰＦ３４０において、図６（ｃ）に示すカウントスレッド６４０の処理としてｓｅｔＢａｃｋｇｒｏｕｎｄＩｎｈｉｂｉｔＳｔａｔｕｓ関数（記述５１０）の処理と並列して実行される。

Ｓ６１３にて、アプリＰＦ３４０は、アプリの指定したＢＧ処理を抑制する期間の設定更新処理を行う。ここでの設定更新には、ｓｅｔＢａｃｋｇｒｏｕｎｄＩｎｈｉｂｉｔＳｔａｔｕｓ関数（記述５１０）の第三引数で指定されるパラメータを用いる。図６（ｃ）のカウントスレッド６４０の処理内でカウント中のｆａｌｓｅの実行アプリ抑制期間に対し、アプリＰＦ３４０は、アプリ指定のパラメータで指定される抑制期間との論理和を取ることで更新を行う。更新されたｆａｌｓｅの実行アプリ抑制期間は、図６（ｃ）のカウントスレッド６４０の処理内で参照される。その後、Ｓ６１４へ進む。

Ｓ６１４にて、アプリＰＦ３４０は、ｔｒｕｅ、ｆａｌｓｅ各々の両方の実行アプリカウント数を合計する。

Ｓ６１５にて、アプリＰＦ３４０は、合計の実行アプリカウント数からＢＧ処理抑制フラグの状態を更新する。合計の実行アプリカウント数が“０”の場合、アプリＰＦ３４０は、ＢＧ処理抑制フラグを“ｆａｌｓｅ”にする。合計の実行アプリカウント数が“１”以上の場合、アプリＰＦ３４０はＢＧ処理抑制フラグを“ｔｒｕｅ”にする。このＢＧ処理抑制フラグは、ＢＧ処理管理部３３１によりＢＧ処理の実行開始の可否の判定に用いられる。ＢＧ処理抑制フラグが“ｆａｌｓｅ”であれば、ＢＧ処理管理部３３１は該当するプロセスに対しＢＧ処理の実行を指示できる。

一方、ｓｅｔＢａｃｋｇｒｏｕｎｄＥｎａｂｌｅｄ関数（記述５０１）が実行された場合（Ｓ６０１にてＮＯ）、Ｓ６１６にて、アプリＰＦ３４０は、ＡＰＩを実行したアプリが、ｔｒｕｅ、ｆａｌｓｅ各々の実行アプリ名のリストに存在するかの情報を取得する。この取得には、アプリＰＦ３４０がｓｅｔＢａｃｋｇｒｏｕｎｄＩｎｈｉｂｉｔＳｔａｔｕｓ関数（記述５１１）の第二引数で指定されるパラメータを用いて、ｔｒｕｅ、ｆａｌｓｅ各々の実行アプリ名のリストの探索することで実現される。情報の取得後、Ｓ６１７にて、アプリＰＦ３４０は、実行したアプリの抑制解除フラグの指定を判定する。

Ｓ６１７の判定にてフラグが“ｔｒｕｅ”の場合、Ｓ６１８にて、アプリＰＦ３４０は、ｔｒｕｅ実行アプリ名のリストから当該アプリ名を削除する。その後、Ｓ６１９にて、アプリＰＦ３４０は、ｔｒｕｅの実行アプリカウント数をデクリメントする。そして、Ｓ６２０にて、アプリＰＦ３４０は、ｔｒｕｅの実行アプリカウント数が“０”か否か、すなわち、ＢＧ処理の抑制指示を行ったアプリが存在しているか否かを判定する。ｔｒｕｅの実行アプリカウント数が“０”でない場合（Ｓ６２０にてＮＯ）、Ｓ６２６へ進む。ｔｒｕｅの実行アプリカウント数が“０”である場合（Ｓ６２０にてＹＥＳ）、Ｓ６２１にて、アプリＰＦ３４０は、ｔｒｕｅの実行アプリ抑制期間を“０”に更新する。その後、Ｓ６２６へ進む。

同様に、Ｓ６１７の判定にてフラグが“ｆａｌｓｅ”の場合、Ｓ６２２にて、アプリＰＦ３４０は、ｆａｌｓｅ実行アプリ名のリストから当該アプリ名を削除する。その後、Ｓ６２３にて、アプリＰＦ３４０は、ｆａｌｓｅの実行アプリカウント数をデクリメントする。そして、Ｓ６２４にて、アプリＰＦ３４０は、ｆａｌｓｅの実行アプリカウント数が“０”か否か、すなわち、ＢＧ処理の抑制指示を行ったアプリが存在しているか否かを判定する。ｔｒｕｅの実行アプリカウント数が“０”である場合（Ｓ６２４にてＮＯ）、Ｓ６２６へ進む。ｆａｌｓｅの実行アプリカウント数が“０”である場合、Ｓ６２５にて、アプリＰＦ３４０は、ｆａｌｓｅの実行アプリ抑制期間を“０”に更新する。

Ｓ６２６にて、アプリＰＦ３４０は、ｔｒｕｅ、ｆａｌｓｅ各々の実行アプリカウント数の合算を行う。その後、Ｓ６１５へ進み、アプリＰＦ３４０は、合計の実行アプリカウント数からのＢＧ処理抑制フラグの状態の更新を行う。そして、本処理フローを終了する。

なお、Ｓ６１７の判定にて、第二引数指定のパラメータがｔｒｕｅおよびｆａｌｓｅのいずれの実行アプリ名のリストにも存在しなかった場合、アプリＰＦ３４０は以降の処理を実行せず、本処理フローを終了する。これは、アプリがｓｅｔＢａｃｋＧｒｏｕｎｄＤｉｓａｂｌｅｄ関数（記述５０２、５０３）を実行する前にｓｅｔＢａｃｋＧｒｏｕｎｄＥｎａｂｌｅｄ関数（記述５０１）を実行した場合に相当する。その場合、アプリＰＦ３４０は、ｓｅｔＢａｃｋｇｒｏｕｎｄＩｎｈｉｂｉｔＳｔａｔｕｓ関数（記述５１０、５１１）の処理を終了する。

次に、図６（ｂ）を用いて、イベント検知処理について説明する。図６（ａ）のＳ６０３でスリープ／デフォルト画面遷移イベント検知リスナーを登録した後、Ｓ６３１にて、アプリＰＦ３４０は、イベントの発生を検知した場合にそのリスナーに対応するイベント通知関数の処理を開始する。すなわち、アプリＰＦ３４０は、所定のイベントが発生しない限り、図６（ｂ）に示す処理を実行しない。

Ｓ６３２にて、アプリＰＦ３４０は、イベント検知フラグを“ｔｒｕｅ”に更新する。更新されたイベント検知フラグは、図６（ｃ）に示すカウントスレッド６４０の処理内で参照される。

最後に、図６（ｃ）を用いて、ＢＧ処理抑制期間のカウント処理について説明する。図６（ａ）のＳ６０８またはＳ６１２のいずれかにて、カウントスレッド６４０を作成した後、Ｓ６４１にて、アプリＰＦ３４０は、イベント検知フラグを“ｆａｌｓｅ”に設定する。本ステップは、アプリＰＦ３４０によりカウントスレッド６４０の作成時の初期化処理として実行される。以降、アプリＰＦ３４０は、実行アプリ抑制期間、及びイベント検知フラグの状態を元に、カウント処理を実行する。なお、実行アプリ抑制期間は、ｓｅｔＢａｃｋｇｒｏｕｎｄＩｎｈｉｂｉｔＳｔａｔｕｓ関数（記述５１０、５１１）の処理でも更新される。また、イベント検知フラグは、図６（ｂ）のイベント検知処理でも更新される。

Ｓ６４２にて、アプリＰＦ３４０は、ｆａｌｓｅ実行アプリ抑制期間が経過しているか否かを判定する。ｆａｌｓｅ実行アプリによるＢＧ処理抑制期間中であれば（Ｓ６４２にてＮＯ）、アプリＰＦ３４０はその時点でＳ６４８以降のｔｒｕｅ、ｆａｌｓｅ各々の実行アプリ抑制期間カウント処理を実行する。

ｆａｌｓｅ実行アプリ抑制期間が経過していた場合（Ｓ６４２にてＹＥＳ）、Ｓ６４３にて、アプリＰＦ３４０は、ｔｒｕｅ実行アプリ抑制期間が経過しているか否かを判定する。ｔｒｕｅ実行アプリによるＢＧ処理抑制期間が経過済みであれば（Ｓ６４３にてＹＥＳ）、アプリＰＦ３４０は、その時点でＳ６４５以降のＢＧ処理抑制フラグの解除処理を実行する。

ｔｒｕｅ実行アプリ抑制期間が経過していなかった場合（Ｓ６４３にてＮＯ）、Ｓ６４４にて、アプリＰＦ３４０は、イベント検知フラグが“ｔｒｕｅ”か否かを確認する。イベント検知フラグが“ｔｒｕｅ”の場合（Ｓ６４４にてＹＥＳ）、すなわち、ＢＧ処理抑制期間のカウント処理中にスリープ／デフォルト画面遷移イベントが発生していれば、アプリＰＦ３４０は、Ｓ６４５以降のＢＧ処理抑制フラグの解除処理を実行する。イベント検知フラグが“ｆａｌｓｅ”の場合（Ｓ６４４にてＮＯ）、アプリＰＦ３４０は、Ｓ６４８以降のｔｒｕｅ、ｆａｌｓｅ各々の実行アプリ抑制期間カウント処理を実行する。

Ｓ６４５にて、アプリＰＦ３４０は、ｔｒｕｅ、ｆａｌｓｅ各々の実行アプリ名のリストから登録されていた実行アプリ名を全て削除する。Ｓ６４６にて、アプリＰＦ３４０は、ｔｒｕｅ、ｆａｌｓｅ各々の実行アプリ抑制期間を“０”に更新する。Ｓ６４７にて、アプリＰＦ３４０は、ＢＧ処理抑制フラグの状態を“ｆａｌｓｅ”に更新する。そして、本処理フローを終了する。

Ｓ６４８にて、アプリＰＦ３４０は、カウントスレッド６４０の処理を一定時間スリープさせる。その後、Ｓ６４９にて、アプリＰＦ３４０は、一定時間、カウントスレッド６４０の処理をスリープさせた時間の分ｔｒｕｅ、ｆａｌｓｅ各々の実行アプリ抑制期間を減算して更新する。そして、アプリＰＦ３４０はＳ６４２以降の判定処理を繰り返す。

［処理シーケンス］
次に、本実施形態におけるアプリからの画像処理装置１００のＢＧ処理を抑制する処理について、図７を用いて説明する。図７は、アプリＡ３８１がＢＧ処理抑制指示ＡＰＩ及びＢＧ処理抑制解除ＡＰＩを実行する際の、アプリＰＦ３４０によるＢＧ処理抑制指示及び抑制解除指示の処理手順を示すシーケンス図である。また、図７は、管理者７２０によるアップデート管理部３７１を介したＢＧ処理実行手順のシーケンスも示す。

Ｓ７０１〜Ｓ７０７は、アプリＡ３８１の処理ステップを表しており、本実施形態では、図４に記載のＢＧ処理抑制処理部（記述４００）からの処理を実行する。Ｓ７１１〜Ｓ７１４は、ＢＧ処理抑制指示ＡＰＩの指示により並列に開始されるアプリＰＦ３４０のイベント検知処理及びＢＧ処理抑制期間のカウント処理の処理ステップを表す。Ｓ７２１〜Ｓ７３８は、ＢＧ処理抑制指示ＡＰＩの指示とは独立して実行される管理者７２０からのＢＧ処理実行指示の処理ステップを表す。

Ｓ７０１にて、アプリＡ３８１は、ＢＧ処理抑制ＡＰＩ（記述５０２）を使用したＢＧ処理の抑制をアプリＰＦ３４０に指示する。本実施形態では、アプリＡ３８１が図４の記述４０１で記載される引数を有した状態でＢＧ処理抑制ＡＰＩを実行する。

Ｓ７０２にて、アプリＰＦ３４０は、アプリＡ３８１からのＢＧ処理抑制指示に基づくＢＧ処理抑制フラグの更新処理として、当該フラグを“ｔｒｕｅ”にする。Ｓ７０２で行われる処理の詳細は、図６のＳ６０１〜Ｓ６０８、Ｓ６１４、及びＳ６１５に該当する。Ｓ７０２の処理に付随して、Ｓ７０３にて、アプリＰＦ３４０は、アプリＡ３８１が指定したＢＧ処理の抑制期間をカウントするカウントスレッド６４０を作成する。Ｓ７０２で行われる処理の詳細は、図６（ａ）のＳ６０７もしくはＳ６１２に該当する。

Ｓ７０４にて、アプリＡ３８１は、画像処理装置１００に対する制御指示を行う。Ｓ７０４で行われる処理は図４の記述４０２に該当し、アプリＡ３８１の有する固有の機能である。Ｓ７０５にて、アプリＡ３８１は、ＢＧ処理抑制解除ＡＰＩ（記述５０４）を使用した、ＢＧ処理の抑制解除をアプリＰＦ３４０に指示する。本実施形態では、アプリＡ３８１が図４の記述４０３で記載される引数を有した状態で、ＢＧ処理抑制解除ＡＰＩを実行する。Ｓ７０６にて、アプリＰＦ３４０は、アプリＡ３８１からのＢＧ処理抑制解除指示に基づくＢＧ処理抑制フラグの更新処理として、当該フラグを“ｆａｌｓｅ”にする。Ｓ７０６で行われる処理の詳細は、図６（ａ）のＳ６０１、Ｓ６１６〜Ｓ６１９、Ｓ６２６、及びＳ６１５に該当する。Ｓ７０６の処理に付随して、Ｓ７０７にて、アプリＰＦ３４０は、アプリＡ３８１が指定したＢＧ処理の抑制期間のカウントをゼロに更新する。Ｓ７０７で行われる処理の詳細は、図６（ａ）のＳ６２０〜Ｓ６２１に該当する。

Ｓ７１１にて、アプリＰＦ３４０は、カウントスレッド６４０を介して、アプリＡ３８１の指定したＢＧ処理の抑制期間のカウントをカウントがゼロ以下になるまで繰り返す。Ｓ７１１で行われる処理の詳細は、図６（ｃ）のＳ６４１〜Ｓ６４４、Ｓ６４８、及びＳ６４９の一連の処理に該当する。また、Ｓ７１２として、Ｓ７１１の内部で行われる、カウントスレッド６４０が実行する抑制期間のカウント処理の詳細は、図６（ｃ）のＳ６４８、およびＳ６４９に該当する。

ここで、Ｓ７１３では、スリープ／デフォルト画面遷移イベントを検知した場合、または、アプリＡ３８１が指定したＢＧ処理の抑制期間のカウントが経過した場合の処理を記載している。すなわち、イベント検知処理の処理（図６（ｂ））が実行され、かつ図６（ｃ）のＳ６４４の判定が行われた状態、または、図６のＳ６４３の判定がＹｅｓの場合に該当する。

Ｓ７１３の条件が満たされた場合、Ｓ７１４にて、カウントスレッド６４０は、ＢＧ処理抑制フラグを“ｆａｌｓｅ”に更新する。Ｓ７１４で行われる処理の詳細は、図６（ｃ）のＳ６４５〜Ｓ６４７に該当する。

Ｓ７２１にて、管理者７２０は、Ｗｅｂブラウザ３１０に対し、アップデート管理部３７１へアクセスするＵＲＬ（Ｕｎｉｆｏｒｍ Ｒｅｓｏｕｒｃｅ Ｌｏｃａｔｏｒ）を入力し、接続を要求する。Ｓ７２２にて、Ｗｅｂブラウザ３１０は、通信部３００を介してＨＴＴＰ Ｒｅｑｕｅｓｔをアップデート管理部３７１へ送信する。Ｓ７２３にて、アップデート管理部３７１は、ＨＴＴＰ Ｒｅｑｕｅｓｔに対し、アップデート管理操作画面を構成するＨＴＭＬデータ（不図示）をＨＴＴＰ Ｒｅｓｐｏｎｓｅとして通信部３７２を介してＷｅｂブラウザ３１０に送信する。Ｓ７２４にて、Ｗｅｂブラウザ３１０は、受け取ったＨＴＭＬデータを解析し、Ｗｅｂブラウザ３１０上にアップデート管理操作画面の表示を行う。

Ｓ７２５にて、管理者７２０は、Ｗｅｂブラウザ３１０に対し、記憶装置２０８に書き込まれたファームウェアをＢＧ処理で更新する指示を入力し、その指示の実行をアップデート管理部３７１へ要求する。Ｓ７２６にて、Ｗｅｂブラウザ３１０は、通信部３００を介してＨＴＴＰ Ｒｅｑｕｅｓｔをアップデート管理部３７１へ送信する。Ｓ７２７にて、アップデート管理部３７１は、Ｗｅｂブラウザ３１０からのリクエストを受け、ＢＧ処理管理部３３１に対しファームウェアの更新のＢＧ処理の実行を指示する。

Ｓ７２８、Ｓ７２９にて、ＢＧ処理管理部３３１は、ＢＧ処理を実行可能な状態であるか否かを、ＢＧ処理抑制フラグを有する各処理部に確認し、各々のフラグの状態を受け取る。本実施形態では、アプリＰＦ３４０がＢＧ処理抑制フラグを有しており、ＢＧ処理管理部３３１はアプリＰＦ３４０に対しＢＧ処理抑制フラグの状態を確認する。

ＢＧ処理抑制フラグが一つでも“ｔｒｕｅ”である場合、ＢＧ処理管理部３３１は、Ｓ７３０におけるＢＧ処理抑制フラグの解除待ち状態となる。つまり、ＢＧ処理抑制が複数のアプリから重複して指示されている場合、全てのフラグが解除されるまで抑制が継続される。Ｓ７３０の処理では、Ｓ７３１にて、ＢＧ処理管理部３３１は、ＢＧ処理抑制フラグが全て“ｆａｌｓｅ”になるまでループ処理を実行する。すなわち、Ｓ７３２、Ｓ７３３におけるＢＧ処理抑制フラグの状態の確認、及びＳ７３４における一定時間のＷａｉｔ処理である。Ｓ７３２、Ｓ７３３の処理は、Ｓ７２８、Ｓ７２９と同等の処理である。

ＢＧ処理抑制フラグが全て“ｆａｌｓｅ”である場合、ＢＧ処理管理部３３１は、Ｓ７３５におけるＢＧ処理実行開始状態となる。Ｓ７３５の状態では、ＢＧ処理管理部３３１がＳ７２７のようにＢＧ処理の実行指示を受けた場合に、Ｓ７３６として、該当するプロセスにＢＧ処理の実行を指示する。本実施形態では、アップデート管理部３７１からのファームウェアの更新のＢＧ処理の実行を、ファームウェアの更新を行うプロセスに対し指示する。

Ｓ７３７にて、アップデート管理部３７１は、一連の処理終了後に、リクエストに対する処理の完了通知画面を構成するＨＴＭＬデータ（不図示）をＨＴＴＰ Ｒｅｓｐｏｎｓｅとして通信部３７２を介してＷｅｂブラウザ３１０に送信する。Ｓ７３８にて、Ｗｅｂブラウザ３１０は、受け取ったＨＴＭＬデータを解析し、Ｗｅｂブラウザ３１０上に処理の完了通知画面の表示を行う。

以上、第一の実施形態では、アプリがＢＧ処理抑制を指示する間は、画像処理装置１００におけるＢＧ処理の実行を抑制することができる。このことから、画像処理装置１００はアプリを安定して動作させる事が実現可能となる。

また、アプリがＢＧ処理の抑制を指示する際にＢＧ処理の抑制を解除する情報を付与することで、画像処理装置１００はＢＧ処理の抑制を自発的に解除しＢＧ処理を実行することができる。このことから、画像処理装置１００はＢＧ処理の実行を必要以上に抑制する状態を避けることが可能となる。

なお、本実施形態では、アップデート管理部３７１がＢＧ処理管理部３３１に対しＢＧ処理実行を指示する際に、管理者７２０からのＷｅｂブラウザ３１０を介した実行指示を行っている。しかしながら、ＢＧ処理管理部３３１がＢＧ処理実行の指示を受け、ＢＧ処理抑制フラグの状態を判断してＢＧ処理を実行する事が可能であれば、この構成に限定するものではない。従って、例えば、アップデート管理部３７１がＵＩ表示装置２０３に操作画面を有し、管理者７２０からの操作画面を介したＢＧでのアップデート指示を行う形式でもよいし、特定の日時の経過で自動的にＢＧでのアップデート指示を行う形式でもよい。また、画像処理装置１００で実行されたジョブのログを定期的に収集するジョブログ管理部（不図示）におけるＢＧでのログ収集の実行のような、異なる処理からのＢＧ処理の実行指示でもよい。

＜第二の実施形態＞
次に本発明の第二の実施形態を説明する。第一の実施形態の構成では、ＢＧ処理抑制ＡＰＩを実行するアプリが大量に存在する場合、結果として画像処理装置１００のＢＧ処理を長期間にわたって実行不可能な状態に陥れてしまう。例えば、画像処理装置１００のＵＩ表示装置２０３に操作画面を提供するアプリの場合、ＢＧ処理実行により操作性低下の影響を受けてしまう。そのため、アプリＰＦ３４０がアプリに対しＢＧ処理の抑制指示を許可し、結果として画像処理装置１００のＢＧ処理実行を長期間の抑制を継続することは妥当である。一方、例えば画像処理装置１００で実行されたジョブのログを定期的に収集するアプリなど、ＢＧ処理が発生したとしてもパフォーマンスに大きく影響しないアプリの場合、ＢＧ処理抑制ＡＰＩによりＢＧ処理を抑制してまで自身の処理を実行する必要性は低い。

上記アプリの特性から、第二の実施形態では、アプリＰＦ３４０がＢＧ処理抑制ＡＰＩを実行するアプリの種類や状態に応じて、ＢＧ処理抑制ＡＰＩの実行に制限を設ける処理を追加する。以下、図８〜図１１を用いて第一の実施との差分を説明する。

第二の実施形態では、ＢＧ処理抑制ＡＰＩの実行時に制限を受けるアプリとそうでないアプリを予め定義する。本実施形態において、ＢＧ処理抑制に対する制限を受けないアプリに分類されるものは、ＵＩ表示装置２０３に操作画面を提供するアプリ（以下「ＬＵＩアプリ」）、システムアプリ、ログインアプリ、起動処理中のアプリである。このようなアプリは、主にユーザの操作性に関するパフォーマンスが要求されるアプリであることから、制限を受けないアプリに分類される。また、たとえＢＧ処理抑制中に特定のイベントが発生した場合でも、その抑制は解除不可として扱われる。上記以外のアプリは、ＢＧ処理抑制ＡＰＩの実行時に制限を受けるアプリに分類される。こちらに分類されるアプリは、ＧＢ処理抑制の実行自体が制限されるものとして扱われる。ここで、システムアプリとは、システムアプリ部３７０上に存在するアプリＰＦ３４０を構成する機能を提供するアプリである。また、ログインアプリとは、画像処理装置１００においてユーザ認証に関わる処理を行うアプリである。更に、起動処理中のアプリとは、フレームワーク３５０により停止状態から起動開始中に状態を変化している最中のアプリである。

図８〜図１０を用いて、上記に示した制限を受けないアプリの判断方法について説明する。また、図１１を用いて、ＢＧ処理抑制ＡＰＩの実行に制限を設けた際のＢＧ処理抑制ＡＰＩの内部処理について説明する。

図８は、アプリＰＦ３４０が有する、ＢＧ処理抑制ＡＰＩの実行時に制限を受けないアプリの構成、及びマニフェストファイル（以下「ＭＦ」）の一例である。ＭＦとは、フレームワーク３５０を構成するＯＳＧｉ３５１により、アプリのライフサイクル及び依存関係などを管理するためのメタデータを記載したものである。アプリＰＦ３４０が有するアプリは、自身の機能を構成するＪＡＲファイルに加え、ＭＦを有しているものとする。

図８（ａ）は、ライフサイクル管理部３７３のアプリの構成及びＭＦの一例である。ライフサイクル管理部３７３は、自身の機能を構成するＪＡＲファイル８００及びＭＦ８０１を有する。ＭＦ８０１は、フレームワーク３５０上で機能するための一般的なメタデータ８０２に加えシステムアプリ設定宣言８０３を有する。システムアプリ設定宣言８０３を有するアプリは、フレームワーク３５０によりシステムアプリとして判断され、システムアプリ部３７０で管理される。また、システムアプリ設定宣言８０３を有しないアプリは、フレームワーク３５０により一般のアプリとして判断されアプリ部３８０で管理される。本実施形態では、システムアプリ設定宣言８０３を有するアプリは、ＢＧ処理抑制ＡＰＩの実行時に制限を受けない。

図８（ｂ）は、アプリＡ３８１のアプリの構成及びＭＦの一例である。アプリＡ３８１は、自身の機能を構成するＪＡＲファイル８１０及びＭＦ８１１を有する。ＭＦ８１１は、フレームワーク３５０上で機能するための一般的なメタデータ８０２に加え最小画面サイズ宣言８１３を有する。最小画面サイズ宣言８１３は、ＬＵＩアプリが画像処理装置１００のＵＩ表示装置２０３上に画面を表示する際に必要とする最小の画面サイズを定義する宣言である。これは、画像処理装置１００が有するＵＩ表示装置２０３が、画像処理装置１００の機種ごとに異なる場合があるため、画像処理装置１００でＬＵＩアプリが表示可能か否かの判断に用いられる。本実施形態では、最小画面サイズ宣言８１３を有するアプリは、ＬＵＩアプリと判断されＢＧ処理抑制ＡＰＩの実行時に制限を受けない。

図８（ｃ）は、ログインアプリ８２０のアプリの構成及びＭＦの一例である。ここで、本実施形態では、第一の実施形態の構成に加え、アプリＰＦ３４０は、システムアプリ部３７０にログインアプリ８２０を有する。ログインアプリ８２０は、自身の機能を構成するＪＡＲファイル８２１及びＭＦ８２２を有する。ＭＦ８２２は、フレームワーク３５０上で機能するための一般的なメタデータ８２３に加えログインアプリ設定宣言８２４を有する。ログインアプリ設定宣言８２４を有するアプリは、フレームワーク３５０により認証を行うログインアプリとして判断されシステムアプリ部３７０で管理される。本実施形態では、ログインアプリ設定宣言８２４を有するアプリはＢＧ処理抑制ＡＰＩの実行時に制限を受けない。

図９（ａ）は、フレームワーク３５０上で管理される、アプリＰＦ３４０上に存在するアプリのアプリ管理テーブルの構成例を示す。アプリ管理テーブルは、記憶装置２０８などにて保持される。フレームワーク３５０は、アプリＰＦ３４０上に存在するアプリの有するＭＦの情報をアプリ管理テーブルに登録する。フレームワーク３５０は、起動状態情報管理を行うため、アプリ管理テーブルを用いる。アプリ管理テーブルは、ｂｕｎｄｌｅ９００、ｓｔａｔｅ９０１、メタデータ情報９０２、ＳｙｓｔｅｍＡｐｐｌｉｃａｔｉｏｎＴｙｐｅ９０３、およびＭｉｎｉｍｕｍＣｏｎｓｏｌｅＳｉｚｅ９０４を有する。

ｂｕｎｄｌｅ９００は、アプリ記憶領域３６０上に存在するアプリ名である。本実施形態では、フレームワーク３５０が、アプリが有するＭＦに記載のアプリ名（Ｂｕｎｄｌｅ−Ｎａｍｅ）を登録する。そのため、フレームワーク３５０がｂｕｎｄｌｅ９００に登録するアプリ名としては、ライフサイクル管理部３７３を“ＬｉｆｅＣｙｃｌｅＭａｎａｇｅｍｅｎｔＳｅｒｖｉｃｅ”のアプリ名として登録している。同様に、アップデート管理部３７１を“ＵｐｄａｔｅＭａｎａｇｅｍｅｎｔＳｅｒｖｉｃｅ”、アプリＡ３８１を“ＡｐｐｌｉＡ”としてそれぞれ登録している。また、本実施形態で加えたログインアプリ８２０を“ＬｏｇｉｎＡｐｐｌｉｃａｔｉｏｎ”、及び第一の実施形態にて示した構成から新たに加えるアプリＢ９１０を“ＡｐｐｌｉＢ”としてそれぞれ登録している。ここで、アプリＢ９１０は、アプリＡ３８１においてＢＧ処理の抑制を含む制御指示を行う処理実装部（図４）と同等の処理を有する。また、アプリＢ９１０は、アプリ部３８０で管理されるアプリであり、かつ、ＬＵＩアプリではないアプリである。また、アプリＢ９１０は、フレームワーク３５０により、その起動状態が「停止状態」であるアプリとする。そのため、図９（ａ）に示す状態では、アプリＢ９１０は、アプリＰＦ３４０によりＢＧ処理抑制ＡＰＩの実行時に制限を受けるアプリと判断される。

ｓｔａｔｅ９０１は、フレームワーク３５０が管理する、ｂｕｎｄｌｅ９００に記載されたアプリの起動状態を示す。本実施形態では、ライフサイクル管理部３７３、アップデート管理部３７１、アプリＡ３８１、ログインアプリ８２０は、「起動状態（ＡＣＴＩＶＥ）」となっている。また、アプリＢ９１０は、インストールはされているが起動されていない「停止状態（ＩＮＳＴＡＬＬＥＤ）」となっている。メタデータ情報９０２は、アプリが所有するＭＦに記載された一般的なメタデータを示す。本実施形態では、例えばアプリのバージョン情報（ｖｅｒｓｉｏｎ）などが記載されているものとする。

ＳｙｓｔｅｍＡｐｐｌｉｃａｔｉｏｎＴｙｐｅ９０３は、アプリが所有するＭＦに記載されたシステム／ログインアプリ設定宣言を有する。本実施形態では、図８（ａ）、ライフサイクル管理部３７３、アップデート管理部３７１がシステムアプリ設定宣言８０３（“ＳｙｓｔｅｍＡｐｐｌｉｃａｔｉｏｎ”）を有する。また、図８（ｃ）に示すように、ログインアプリ８２０がログインアプリ設定宣言８２４（“ＬｏｇｉｎＳｅｒｖｉｃｅ”）を有する。ＭｉｎｉｍｕｍＣｏｎｓｏｌｅＳｉｚｅ９０４は、アプリが所有するＭＦに記載された最小画面サイズ宣言を有する。本実施形態では、図８（ｂ）に示すように、アプリＡ３８１が、最小画面サイズ宣言８１３（６４０ｘ４００）を有する。

図９（ｂ）、（ｃ）は、フレームワーク３５０が、図９（ａ）に示す状態から、アプリＢ９１０の起動状態を変化させた際のアプリ管理テーブルである。詳細については図１０を用いて説明する。

図１０は、ライフサイクル管理部３７３のアプリのライフサイクル管理における、アプリＢ９１０の起動処理の手順を示すフローチャートである。

Ｓ１００１にて、画像処理装置１００の管理者１０００は、Ｗｅｂブラウザ３１０に対し、ライフサイクル管理部３７３へアクセスするＵＲＬを入力し接続を要求する。Ｗｅｂブラウザ３１０は、通信部３００を介してＨＴＴＰ Ｒｅｑｕｅｓｔをライフサイクル管理部３７３に送信する。

Ｓ１００２にて、ライフサイクル管理部３７３は、ライフサイクル管理要操作画面を構成するＨＴＭＬデータ（不図示）を、通信部３７４を介してＷｅｂブラウザ３１０に送信する。Ｗｅｂブラウザ３１０は、受け取ったＨＴＭＬデータを解析し、Ｗｅｂブラウザ３１０上にライフサイクル管理操作画面の表示を行う。

Ｓ１００３にて、管理者１０００は、Ｗｅｂブラウザ３１０に対し、アプリＢ９１０を起動する指示を入力し、その指示の実行をライフサイクル管理部３７３へ要求する。Ｗｅｂブラウザ３１０は、通信部３００を介してＨＴＴＰ Ｒｅｑｕｅｓｔをライフサイクル管理部３７３に送信する。

Ｓ１００４にて、ライフサイクル管理部３７３は、Ｗｅｂブラウザ３１０から実行指示を受け、フレームワーク３５０に対しアプリＢ９１０の起動を開始する指示を送信する。このとき、フレームワーク３５０は、アプリＢ９１０の起動処理を開始するとともに、アプリ管理テーブルにて管理されているアプリＢ９１０のｓｔａｔｅ９０１を「ＳＴＡＲＴＩＮＧ」に更新する。この状態のアプリ管理テーブルを、図９（ｂ）に示す。フレームワーク３５０は、アプリＢ９１０のｓｔａｔｅ９０１を「ＩＮＳＴＡＬＬＥＤ」から「ＳＴＡＲＴＩＮＧ」に変化させ、これにより、アプリＢ９１０が起動処理中のアプリであることを示す。この状態の時、アプリＢ９１０は、アプリＰＦ３４０によりＢＧ処理抑制の実行に制限を受けないアプリと判断される。

Ｓ１００５にて、フレームワーク３５０は、アプリＢ９１０の起動処理を完了させ、アプリ管理テーブルにて管理されているアプリＢ９１０のｓｔａｔｅ９０１を「ＡＣＴＩＶＥ」に更新する。この状態のアプリ管理テーブルを、図９（ｃ）に示す。フレームワーク３５０は、アプリＢ９１０のｓｔａｔｅ９０１を「ＳＴＡＲＴＩＮＧ」から「ＡＣＴＩＶＥ」に変化させ、これにより、アプリＢ９１０が起動状態のアプリであることを示す。この状態の時、アプリＢ９１０は、アプリＰＦ３４０によりＢＧ処理抑制の実行に制限を受けるアプリと判断される。

Ｓ１００６にて、ライフサイクル管理部３７３は、一連の処理終了後にリクエストに対する処理の完了通知画面を構成するＨＴＭＬデータ（不図示）を、通信部３７４を介してＷｅｂブラウザ３１０に送信する。Ｗｅｂブラウザ３１０は、受け取ったＨＴＭＬデータを解析し、Ｗｅｂブラウザ３１０上に処理の完了通知画面の表示を行う。そして、本処理フローを終了する。

なお、本実施形態では、フレームワーク３５０がアプリのライフサイクル管理を実行するため、管理者１０００からのＷｅｂブラウザ３１０を介したライフサイクル管理部３７３による実行指示を行っている。しかしながら、例えばユーザ入力装置２０２を介してフレームワーク３５０に対する要求指示コマンドを入力するなど、管理者１０００がフレームワーク３５０に対しライフサイクル管理の要求を指示できる構成を有していればよい。そのため、この構成に限定するものではない。

図１１は、アプリＰＦ３４０がアプリに提供する、画像処理装置１００のＢＧ処理を抑制及び抑制解除する制御指示を行うＡＰＩの内部処理のフローチャートである。なお、図６に記載したステップ番号と同一のステップ番号の処理は、図６の処理と同等である。そのため、図６からの差分のステップのみ説明する。

ｓｅｔＢａｃｋＧｒｏｕｎｄＤｉｓａｂｌｅｄ関数（記述５０２、５０３）が実行された場合（Ｓ６０１にてＹＥＳ）、Ｓ１１０１にて、アプリＰＦ３４０は、フレームワーク３５０が有するアプリ管理テーブルから実行したアプリの情報を取得する。アプリＰＦ３４０が取得する情報は、実行したアプリのｂｕｎｄｌｅ９００の列に対応する、ｓｔａｔｅ９０１、ＳｙｓｔｅｍＡｐｐｌｉｃａｔｉｏｎＴｙｐｅ９０３、およびＭｉｎｉｍｕｍＣｏｎｓｏｌｅＳｉｚｅ９０４である。

Ｓ１１０２にて、アプリＰＦ３４０は、取得したアプリ情報に基づき、実行したアプリがＢＧ処理抑制の実行に制限を受けるアプリか否かを判定する。すなわち、アプリＰＦ３４０が、実行したアプリのｓｔａｔｅ９０１が「ＳＴＡＲＴＩＮＧ」であるか否かを判定する。もしくは、アプリの種類判別として、ＳｙｓｔｅｍＡｐｐｌｉｃａｔｉｏｎＴｙｐｅ９０３がＳｙｓｔｅｍＡｐｐｌｉｃａｔｉｏｎ／ＬｏｇｉｎＳｅｒｖｉｃｅであるか、ＭｉｎｉｍｕｍＣｏｎｓｏｌｅＳｉｚｅ９０４に記載があるか否かを判定する。つまり、ＢＧ処理抑制の実行に制限を受けないという所定の条件を満たすか否かが判定される。

実行したアプリがＢＧ処理抑制の実行に制限を受けないアプリであれば（Ｓ１１０２にてＹＥＳ）、アプリＰＦ３４０は、Ｓ６０２以降の処理を開始する。制限を受けるアプリである場合（Ｓ１１０２にてＮＯ）、アプリＰＦ３４０は、Ｓ６０２以降の処理を行わずに、ｓｅｔＢａｃｋｇｒｏｕｎｄＩｎｈｉｂｉｔＳｔａｔｕｓ関数（記述５１０）の処理を終了する。

以上、第二実施形態では、ＢＧ処理抑制ＡＰＩを実行可能なアプリに制限を設けることで、不要なＢＧ処理抑制ＡＰＩの実行により画像処理装置１００のＢＧ処理が長期間実行不可能な状態に陥ることを回避できる。

なお、本実施形態では、アプリＰＦ３４０がＢＧ処理抑制ＡＰＩの実行可能なアプリの特定のため独自に拡張したＭＦの項目を用いる。しかしながら、アプリＰＦ３４０が、ＢＧ処理抑制を実行可能とする条件を一意に特定可能な項目をアプリが有していれば、この構成に限定するものではない。また、アプリＰＦ３４０は、ＢＧ処理抑制ＡＰＩの実行可能なアプリとしてＬＵＩアプリ、システムアプリ、ログインアプリ、起動処理中のアプリを対象とした。しかしながら、画像処理装置１００でＢＧ処理が実行された際にパフォーマンス低下の影響が懸念される処理を有するアプリであれば、他の種類のアプリでもよい。また、ＢＧ処理抑制の実行に制限を受けるか否かの条件において、画像処理装置の機能やアプリの機能に応じた上記以外の条件を用いても構わない。

＜第三の実施形態＞
本発明の第三の実施形態を説明する。第二の実施形態では、ＢＧ処理抑制を実行可能なアプリが、特定のアプリに限定されている。しかしながら、当該条件を満たさないアプリであってもＢＧ処理の実行によりパフォーマンス低下の影響を受けてしまうアプリが存在する可能性がある。そのため、当該条件を満たさないアプリがＢＧ処理抑制ＡＰＩを実行した場合の処理を変更する。以下、図１２を用いて第二の実施形態からの差分を説明する。

図１２は、アプリＰＦ３４０がアプリに提供する、画像処理装置１００のＢＧ処理を抑制及び抑制解除する制御指示を行うＡＰＩの内部処理のフローチャートである。なお、図１１に記載されたステップ番号と同一のステップ番号の処理は、図１１の処理と同等である。そのため、図１１からの差分のみ説明する
Ｓ１１０２の判定の結果、実行したアプリがＢＧ処理抑制の実行に制限を受けないアプリである場合（Ｓ１１０２にてＹＥＳ）、アプリＰＦ３４０は、Ｓ６０２以降の処理を開始する。制限を受けるアプリであった場合（Ｓ１１０２にてＮＯ）、アプリＰＦ３４０は、Ｓ６０３以降の処理を開始する。すなわち、アプリＰＦ３４０は、アプリが実行したＢＧ処理抑制ＡＰＩを記述５０３のｓｅｔＢａｃｋＧｒｏｕｎｄＤｉｓａｂｌｅｄ関数の実行とみなす。つまり、アプリＰＦ３４０がアプリに対し、イベント検知をした場合には、強制的にＢＧ処理抑制を解除するような状態に制限してＢＧ処理抑制ＡＰＩの実行を許可する、ということである。

以上、第三の実施形態では、ＢＧ処理抑制の実行可能なアプリに設けた制限を変更することで、アプリからの過剰なＢＧ処理抑制の実行により画像処理装置１００のＢＧ処理が長期間実行不可能な状態になることを回避できる。

なお、本発明は、具体的に開示された実施形態に限定されるものではなく、特許請求の範囲から逸脱することなく種々の変形や変更が可能である。

＜その他の実施形態＞
本発明は、上述の実施形態の１以上の機能を実現するプログラムを、ネットワーク又は記憶媒体を介してシステム又は装置に供給し、そのシステム又は装置のコンピュータにおける１つ以上のプロセッサーがプログラムを読出し実行する処理でも実現可能である。また、１以上の機能を実現する回路（例えば、ＡＳＩＣ）によっても実現可能である。

１００…画像処理装置、１０１…情報処理装置、３４０…アプリＰＦ、フレームワーク３５０、３７１…アップデート管理部、３７３…ライフサイクル管理部

Claims (12)

1. バックグラウンドで処理を実行可能な情報処理装置であって、
   アプリケーションからの要求に応じて処理が実行される際に、バックグラウンドにおける別の処理の実行を制御する制御手段を備え、
   前記制御手段は、
   前記アプリケーションからの要求に応じて、前記別の処理がバックグラウンドにて実行されないように抑制し、
   前記アプリケーションから前記抑制の解除の要求が指示されない場合、前記抑制を開始してから所定の期間が経過した際に、前記抑制を解除することを特徴とする情報処理装置。
2. 前記制御手段は、予め設定されたイベントが発生した場合、前記所定の期間に関わらず、前記抑制を解除することを特徴とする請求項１に記載の情報処理装置。
3. 前記アプリケーションからの要求には、前記所定の期間に前記イベントが発生した場合に、前記抑制の解除が可能か否かの設定を含むことを特徴とする請求項２に記載の情報処理装置。
4. 前記制御手段は、前記アプリケーションから前記所定の期間の設定を受け付けることを特徴とする請求項１乃至３のいずれか一項に記載の情報処理装置。
5. 前記制御手段は、バックグラウンドにて処理が実行されないように抑制されている間に、前記アプリケーションとは異なる別のアプリケーションから更に抑制が要求され、かつ、前記アプリケーションから設定された期間と前記別のアプリケーションから設定された期間とが異なる場合、より遅く終了する期間まで、前記抑制を継続することを特徴とする請求項４に記載の情報処理装置。
6. 前記制御手段は、複数のアプリケーションからバックグラウンドにて処理が実行されないように要求されている場合、
   前記複数のアプリケーションのいずれかから前記抑制の解除の要求を受け付けた場合には当該抑制を継続し、
   前記複数のアプリケーションのすべてから前記抑制の解除の要求を受け付けた場合に前記抑制を解除することを特徴とする請求項５に記載の情報処理装置。
7. アプリケーションの情報を保持する保持手段を更に有し、
   前記制御手段は、アプリケーションからバックグラウンドにおける処理の抑制の要求を受け付けた場合、当該アプリケーションの情報を前記保持手段から取得し、当該アプリケーションの種類に応じて、前記バックグラウンドにおける処理の抑制を実行するか否かを切り替えることを特徴とする請求項１乃至６のいずれか一項に記載の情報処理装置。
8. 前記保持手段にて保持される、前記バックグラウンドにおける処理の抑制の実行に関するアプリケーションの情報を受け付ける手段を更に有することを特徴とする請求項７に記載の情報処理装置。
9. 前記制御手段は、前記アプリケーションの種類に応じて、前記バックグラウンドにおける処理の抑制を許可または不可、もしくは、抑制している最中に予め設定されたイベントが発生した際には当該抑制を解除する、のいずれかとして実行を制御することを特徴とする請求項７または８に記載の情報処理装置。
10. 前記イベントは、前記情報処理装置が待機状態にとなった際に発生するイベントであることを特徴とする請求項２または９に記載の情報処理装置。
11. バックグラウンドで処理を実行可能な情報処理装置の制御方法であって、
    アプリケーションからの要求に応じて処理が実行される際に、バックグラウンドにおける別の処理の実行を制御する制御工程を有し、
    前記制御工程において、
    前記アプリケーションからの要求に応じて、前記別の処理がバックグラウンドにて実行されないように抑制し、
    前記アプリケーションから前記抑制の解除の要求が指示されない場合、前記抑制を開始してから所定の期間が経過した際に、前記抑制を解除することを特徴とする情報処理装置の制御方法。
12. コンピュータを、
    アプリケーションからの要求に応じて処理が実行される際に、バックグラウンドにおける別の処理の実行を制御する制御手段として機能させ、
    前記制御手段は、
    前記アプリケーションからの要求に応じて、前記別の処理がバックグラウンドにて実行されないように抑制し、
    前記アプリケーションから前記抑制の解除の要求が指示されない場合、前記抑制を開始してから所定の期間が経過した際に、前記抑制を解除することを特徴とするプログラム。

Images