(57)【特許請求の範囲】
【請求項１】
サーバ機能を備えるアプリケーションの動作プラットフォームであり、操作入力を受け付ける操作部と、前記操作入力に応じて動作する本体部と、を備える電子機器であって、
前記本体部は、
外部装置からの要求を受け付ける受信部と、
前記要求の内容と、前記電子機器の動作状態と、に応じて、処理が要求された前記操作部に対する電力の供給を制御する要求制御部と、を備える、
電子機器。
【請求項２】
サーバ機能を備えるアプリケーションの動作プラットフォームであり、操作入力を受け付ける操作部と、前記操作入力に応じて動作する本体部と、を備える電子機器と、前記電子機器と接続される外部装置とを備える情報処理システムであって、
前記本体部は、
前記外部装置からの要求を受け付ける受信部と、
前記要求の内容と、前記電子機器の動作状態と、に応じて、処理が要求された前記操作部に対する電力の供給を制御する要求制御部と、を備える、
情報処理システム。
【請求項３】
サーバ機能を備えるアプリケーションの動作プラットフォームであり、操作入力を受け付ける操作部と、前記操作入力に応じて動作する本体部と、を備える電子機器で実行される制御方法であって、
前記本体部が、外部装置からの要求を受け付ける受信ステップと、
前記本体部が、前記要求の内容と、前記電子機器の動作状態と、に応じて、処理が要求された前記操作部に対する電力の供給を制御する要求制御ステップと、
を含む制御方法。
【請求項４】
サーバ機能を備えるアプリケーションの動作プラットフォームであり、操作入力を受け付ける操作部と、前記操作入力に応じて動作する本体部と、を備える電子機器の前記本体部が備えるコンピュータを、
外部装置からの要求を受け付ける受信部と、
前記要求の内容と、前記電子機器の動作状態と、に応じて、処理が要求された前記操作部に対する電力の供給を制御する要求制御部、
として機能させるためのプログラム。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、電子機器、情報処理システム、制御方法およびプログラムに関する。
【背景技術】
【０００２】
組み込み機器の本体（本体部）と、組み込み機器で動作するアプリケーションソフトウェア（以下、単に「アプリ」と称する場合がある）の動作プラットフォームとなる操作部と、で構成されたシステムが知られている。
【０００３】
操作部で動作するアプリは、それ単体で機能が完結することは多くなく、ネットワークの外部モジュールと連携し、システムの一部としてユーザにサービスを提供することが多い。また、アプリ自身がサーバ機能を備え、ＰＣ（パーソナルコンピュータ）などで動作するリモートアプリから要求を受け付けてサービスを提供する場合がある。特許文献１では、外部ネットワークに配置されたリモート端末から、ホームネットワークに接続されているホーム機器にアクセスするためのアクセス制御システムが提案されている。
【発明の概要】
【発明が解決しようとする課題】
【０００４】
しかしながら、上記のようなサーバ機能を備えるアプリを用いるシステムでは、ユーザの利便性を低下させる場合があった。例えば、アプリに接続中であっても省電力化のために電源がオフにされる場合や、操作部のアップデート中などのようにアクセスを許可すべきでないのにアクセスされる場合があった。
【０００５】
本発明は、上記に鑑みてなされたものであって、ユーザの利便性を向上させることができる電子機器、情報処理システム、制御方法およびプログラムを提供することを目的とする。
【課題を解決するための手段】
【０００６】
上述した課題を解決し、目的を達成するために、本発明は、サーバ機能を備えるアプリケーションの動作プラットフォームであり、操作入力を受け付ける操作部と、前記操作入力に応じて動作する本体部と、を備える電子機器であって、前記本体部は、外部装置からの要求を受け付ける受信部と、前記要求の内容と、前記電子機器の動作状態と、に応じて、処理が要求された前記操作部に対する電力の供給を制御する要求制御部と、を備える。
【発明の効果】
【０００７】
本発明によれば、ユーザの利便性を向上させることができるという効果を奏する。
【図面の簡単な説明】
【０００８】
【図１】図１は、実施形態の情報処理システムの全体構成の一例を示すブロック図である。
【図２】図２は、実施形態のＭＦＰのハードウェア構成の例を示す図である。
【図３】図３は、実施形態のＭＦＰのソフトウェア構成の例を示す図である。
【図４】図４は、操作部で動作するアプリの一例を説明するための図である。
【図５】図５は、操作部で動作するアプリの他の例を説明するための図である。
【図６】図６は、実施形態にかかるＭＦＰのさらに詳細な構成を示すブロック図である。
【図７】図７は、実施形態の要求制御処理の一例を示すシーケンス図である。
【図８】図８は、実施形態の要求制御処理の他の例を示すシーケンス図である。
【図９】図９は、実施形態の要求制御処理の他の例を示すシーケンス図である。
【図１０】図１０は、実施形態にかかるクライアントおよびサーバのハードウェア構成例を示す説明図である。
【発明を実施するための形態】
【０００９】
以下に添付図面を参照して、この発明にかかる電子機器、情報処理システム、制御方法およびプログラムの一実施形態を詳細に説明する。
【００１０】
以下では、コピー機能、プリンタ機能、スキャナ機能およびファクス機能のうち少なくとも２つの機能を有する複合機（ＭＦＰ：Multifunction  Peripheral）として電子機器を実現した例を説明する。複合機の他に、複写機、プリンタ、スキャナ装置、ファクス装置等の画像形成装置に適用してもよい。また適用可能な電子機器は、画像形成装置に限られるものではなく、本体部と操作部とを備える電子機器であればどのような装置にも適用できる。
【００１１】
図１は、本実施形態の情報処理システムの全体構成の一例を示すブロック図である。図１に示すように、情報処理システムは、ＭＦＰ１と、クライアント４００と、サーバ３００と、がネットワーク３０で接続された構成となっている。図１では各装置を１台ずつ記載しているが、各装置を複数台備えるように構成してもよい。
【００１２】
ネットワーク３０は、インターネットなどのあらゆるネットワーク形態を適用できる。またネットワーク３０は、無線ネットワークでもよいし有線ネットワークでもよい。
【００１３】
ＭＦＰ１は、操作入力を受け付ける操作部２０と、操作入力に応じて動作する本体部１０と、を備える。クライアント４００は、ＰＣ（パーソナルコンピュータ）などの装置である。クライアント４００は、ＭＦＰ１の操作部２０等で動作するアプリにアクセスするアプリ（リモートアプリ）を備えている。サーバ３００は、Ｗｅｂサービスなどを提供する装置である。
【００１４】
次にＭＦＰ１のハードウェア構成の例について説明する。図２は、実施形態のＭＦＰ１のハードウェア構成の例を示す図である。本体部１０は、コピー機能、スキャナ機能、ファクス機能、および、プリンタ機能等の各種の機能を実現する。操作部２０は、ユーザの操作に応じた情報（操作入力）を受け付ける。なお、ユーザの操作を受け付けるとは、ユーザの操作に応じて入力される情報（画面の座標値を示す信号等を含む）を受け付けることを含む概念である。
【００１５】
本体部１０および操作部２０は、接続Ｉ／Ｆ（インタフェース）１６、専用の通信路４０および接続Ｉ／Ｆ２６を介して相互に通信可能に接続されている。通信路４０は、例えばＵＳＢ（Ｕｎｉｖｅｒｓａｌ  Ｓｅｒｉａｌ  Ｂｕｓ）規格を用いることができるが、有線か無線かを問わず任意の規格のものでもよい。
【００１６】
本体部１０は、操作部２０で受け付けた操作に応じた動作を行う。また、本体部１０は、クライアント４００等の外部装置とも通信可能であり、外部装置から受信した指示（印刷指示等）に応じた動作を行うこともできる。
【００１７】
まず本体部１０のハードウェア構成について説明する。図２に示すように、本体部１０は、ＣＰＵ１１と、ＲＯＭ１２と、ＲＡＭ１３と、ＨＤＤ（ハードディスクドライブ）１４と、通信Ｉ／Ｆ１５と、接続Ｉ／Ｆ１６と、エンジン部１７とを備える。ＣＰＵ１１、ＲＯＭ１２、ＲＡＭ１３、ＨＤＤ１４、通信Ｉ／Ｆ１５、接続Ｉ／Ｆ１６、および、エンジン部１７は、システムバス１８を介して相互に接続されている。
【００１８】
ＣＰＵ１１は本体部１０の動作を統括的に制御する。ＣＰＵ１１はＲＡＭ１３をワークエリア（作業領域）としてＲＯＭ１２またはＨＤＤ１４等に格納されたプログラムを実行することで、本体部１０全体の動作を制御し、上述したコピー機能、スキャナ機能、ファクス機能、プリンタ機能等の各種機能を実現する。
【００１９】
通信Ｉ／Ｆ１５は、ネットワーク３０と接続するためのインタフェースである。接続Ｉ／Ｆ１６は、通信路４０を介して操作部２０と通信するためのインタフェースである。
【００２０】
エンジン部１７は、コピー機能、スキャナ機能、ファクス機能およびプリンタ機能を実現させるための、汎用的な情報処理および通信以外の処理を行うハードウェアである。例えば、エンジン部１７は、原稿の画像をスキャンして読み取るスキャナ（画像読取部）、用紙等のシート材への印刷を行うプロッタ（画像形成部）、ファクス通信を行うファクス部などを備えている。エンジン部１７は、さらに、印刷済みシート材を仕分けるフィニッシャや、原稿を自動給送するＡＤＦ（自動原稿給送装置）のような特定のオプションを実現するためのハードウェアを備えていてもよい。
【００２１】
次に操作部２０のハードウェア構成について説明する。図２に示すように、操作部２０は、ＣＰＵ２１と、ＲＯＭ２２と、ＲＡＭ２３と、フラッシュメモリ２４と、通信Ｉ／Ｆ２５と、接続Ｉ／Ｆ２６と、操作パネル２７と、外部接続Ｉ／Ｆ２８と、を備える。ＣＰＵ２１、ＲＯＭ２２、ＲＡＭ２３、フラッシュメモリ２４、通信Ｉ／Ｆ２５、接続Ｉ／Ｆ２６、操作パネル２７、および外部接続Ｉ／Ｆ２８は、システムバス２９を介して相互に接続されている。
【００２２】
ＣＰＵ２１は、操作部２０の動作を統括的に制御する。ＣＰＵ２１は、ＲＡＭ２３をワークエリア（作業領域）としてＲＯＭ２２またはフラッシュメモリ２４等に格納されたプログラムを実行することで、操作部２０全体の動作を制御し、ユーザから受け付けた入力に応じた情報（画像）の表示などの各種機能を実現する。
【００２３】
通信Ｉ／Ｆ２５は、ネットワーク３０と接続するためのインタフェースである。接続Ｉ／Ｆ２６は、通信路４０を介して本体部１０と通信するためのインタフェースである。
【００２４】
操作パネル２７は、ユーザの操作に応じた各種の入力を受け付けるとともに、各種の情報（例えば受け付けた操作に応じた情報、ＭＦＰ１の動作状況を示す情報、設定状態などを示す情報など）を表示する。この例では、操作パネル２７は、タッチパネル機能を搭載した液晶表示装置（ＬＣＤ）で構成されるが、これに限られるものではない。例えばタッチパネル機能が搭載された有機ＥＬ表示装置で構成されてもよい。さらに、これに加えてまたはこれに代えて、ハードウェアキー等の操作部やランプ等の表示部を設けることもできる。
【００２５】
外部接続Ｉ／Ｆ２８は、例えばＩＣカードリーダー等と接続するためのインタフェースである。
【００２６】
次に、ＭＦＰ１のソフトウェア構成について説明する。図３は、実施形態のＭＦＰ１のソフトウェア構成の例を示す図である。図３に示すように、本体部１０は、アプリ層１０１、サービス層１０２およびＯＳ層１０３を有する。アプリ層１０１、サービス層１０２およびＯＳ層１０３の実体は、ＲＯＭ１２やＨＤＤ１４等（図２参照）に格納されている各種ソフトウェアである。ＣＰＵ１１が、これらのソフトウェアを実行することにより、各種の機能が提供される。
【００２７】
アプリ層１０１のソフトウェアは、ハードウェア資源を動作させて所定の機能を提供するためのアプリである。例えばアプリとしては、コピー機能を提供するためのコピーアプリ、スキャナ機能を提供するためのスキャナアプリ、ファクス機能を提供するためのファクスアプリ、および、プリンタ機能を提供するためのプリンタアプリなどが挙げられる。
【００２８】
サービス層１０２のソフトウェアは、アプリ層１０１とＯＳ層１０３との間に介在し、アプリに対し、本体部１０が備えるハードウェア資源を利用するためのインタフェースを提供するためのソフトウェアである。より具体的には、ハードウェア資源に対する動作要求の受付、動作要求の調停を行う機能を提供するためのソフトウェアである。サービス層１０２が受け付ける動作要求としては、スキャナによる読み取りやプロッタによる印刷等の要求が考えられる。
【００２９】
なおサービス層１０２によるインタフェースの機能は、本体部１０のアプリ層１０１だけではなく、操作部２０のアプリ層２０１に対しても提供される。すなわち操作部２０のアプリ層２０１（アプリ）も、サービス層１０２のインタフェース機能を介して、本体部１０のハードウェア資源（例えば図２のエンジン部１７）を利用した機能を実現することができる。
【００３０】
ＯＳ層１０３のソフトウェアは、本体部１０が備えるハードウェアを制御する基本機能を提供するための基本ソフトウェア（オペレーティングシステム）である。サービス層１０２のソフトウェアは、各種アプリからのハードウェア資源の利用要求を、ＯＳ層１０３が解釈可能なコマンドに変換してＯＳ層１０３に渡す。そして、ＯＳ層１０３のソフトウェアによりコマンドが実行されることで、ハードウェア資源は、アプリの要求に従った動作を行う。
【００３１】
同様に、操作部２０は、アプリ層２０１、サービス層２０２およびＯＳ層２０３を有する。操作部２０が備えるアプリ層２０１、サービス層２０２およびＯＳ層２０３も、階層構造については本体部１０と同様である。ただしアプリ層２０１のアプリにより提供される機能や、サービス層２０２が受け付け可能な動作要求の種類は、本体部１０とは異なる。アプリ層２０１のアプリは、操作部２０が備えるハードウェア資源を動作させて所定の機能を提供するためのソフトウェアであってもよいが、主として本体部１０が備える機能（コピー機能、スキャナ機能、ファクス機能およびプリンタ機能）に関する操作や表示を行うためのＵＩ（ユーザインタフェース）の機能を提供するためのソフトウェアである。
【００３２】
なお本実施形態では、機能の独立性を保つために、本体部１０のＯＳ層１０３のソフトウェアと、操作部２０のＯＳ層２０３のソフトウェアが互いに異なる。つまり本体部１０と操作部２０は、別々のオペレーティングシステムで互いに独立して動作する。例えば、本体部１０のＯＳ層１０３のソフトウェアとしてＬｉｎｕｘ（登録商標）を用い、操作部２０のＯＳ層２０３のソフトウェアとしてＡｎｄｒｏｉｄ（登録商標）を用いることが可能である。
【００３３】
以上のように、ＭＦＰ１において、本体部１０と操作部２０は別々のオペレーティングシステムで動作するため、本体部１０と操作部２０との間の通信は、共通の装置内のプロセス間通信ではなく、異なる装置間の通信として行われる。異なる装置間の通信の例は、操作部２０が受け付けた情報（ユーザからの指示内容）を本体部１０へ伝達する動作（コマンド通信）や、本体部１０が操作部２０へイベントを通知する動作等である。ここでは操作部２０が本体部１０へコマンド通信を行うことにより、本体部１０の機能を使用することができる。また本体部１０から操作部２０に通知するイベントには、本体部１０における動作の実行状況、本体部１０で設定された情報等が挙げられる。
【００３４】
また実施形態では、操作部２０への電力供給は、本体部１０から通信路４０を経由して行われているが、操作部２０の電源制御を、本体部１０の電源制御とは別に（独立して）行ってもよい。
【００３５】
また上述の実施形態では、本体部１０と操作部２０は、別々のオペレーティングシステムで互いに独立して動作しているが、これに限らず、例えば本体部１０と操作部２０が同じオペレーティングシステムで動作する形態であってもよい。また、本体部１０と操作部２０とが一体に構成されていてもよい。例えば、本体部１０と操作部２０のハードウェア構成は、図２のように分離されている必要はなく、１つのハードウェア構成上で本体部１０と操作部２０の機能が実現されていてもよい。
【００３６】
次に、操作部２０で動作するアプリの例について説明する。図４は、操作部２０で動作するアプリの一例を説明するための図である。図４の例は、操作部２０のアプリがクライアントとして、本体部１０またはサーバ３００などにアクセスしてサービスを受ける形態を示す。なお上記各図と同じ構成については同一の符号を付し説明を省略する。
【００３７】
図４に示すように、サーバ３００は、Ｈ／Ｗ３０３と、ＯＳ３０２と、Ｗｅｂアプリ３０１と、を備えている。Ｈ／Ｗ３０３は、ＣＰＵ、ＲＯＭ、ＲＡＭ、メモリ、通信Ｉ／Ｆ、ディスプレイなどのハードウェアである。ＯＳ３０２は、Ｈ／Ｗ３０３を制御する基本機能を提供するための基本ソフトウェアである。Ｗｅｂアプリ３０１は、Ｗｅｂサービスを提供するアプリケーションソフトウェアである。
【００３８】
本体部１０は、ハードウェア（Ｈ／Ｗ）１０４と、ＯＳ層１０３と、サービス層１０２と、標準コピーアプリ１０１ａと、標準スキャンアプリ１０１ｂと、を備えている。Ｈ／Ｗ１０４は、例えば図２で説明した本体部１０内のハードウェア構成に相当する。標準コピーアプリ１０１ａおよび標準スキャンアプリ１０１ｂは、例えば上述のコピーアプリおよびスキャナアプリに相当する。
【００３９】
この例では、操作部２０は、ハードウェア（Ｈ／Ｗ）２０４と、ＯＳ層２０３と、サービス層２０２と、アプリ２０１ａ、２０１ｂと、を備えている。Ｈ／Ｗ２０４は、例えば図２で説明した操作部２０内のハードウェア構成に相当する。アプリ２０１ａ、２０１ｂは、本体部１０のサービス層１０２に対する要求、および、サーバ３００のＷｅｂアプリ３０１に対する要求を送信することにより、本体部１０およびＷｅｂアプリ３０１の機能（サービス）を利用する。サーバ３００に対して要求を送信する場合、本体部１０はＮＡＴ（Network  Address  Translation）機能またはプロキシサーバ機能によりアプリ２０１ａ、２０１ｂからの要求を送信してもよい。
【００４０】
図５は、操作部２０で動作するアプリの他の例を説明するための図である。図５の例は、操作部２０のアプリが、例えばＷｅｂアプリ３０１と同様のサーバ機能を備え、クライアント４００で動作するリモートアプリから要求を受け付けてサービスを提供する形態を示す。なお上記各図と同じ構成については同一の符号を付し説明を省略する。
【００４１】
図５に示すように、クライアント４００は、Ｈ／Ｗ４０３と、ＯＳ４０２と、リモートアプリ４０１と、を備えている。Ｈ／Ｗ４０３は、ＣＰＵ、ＲＯＭ、ＲＡＭ、メモリ、通信Ｉ／Ｆ、ディスプレイなどのハードウェアである。ＯＳ４０２は、Ｈ／Ｗ４０３を制御する基本機能を提供するための基本ソフトウェアである。リモートアプリ４０１は、操作部２０にアクセスしてサービスを利用するアプリケーションソフトウェアである。
【００４２】
この例では、操作部２０は、Ｈ／Ｗ２０４と、ＯＳ層２０３と、サービス層２０２と、アプリ２０１ｃと、を備えている。アプリ２０１ｃは、例えばＷｅｂサーバなどのサーバ機能を備えるアプリケーションソフトウェアである。リモートアプリ４０１などの外部のアプリは、本体部１０のネットワークポートを経由してアプリ２０１ｃにアクセスする。
【００４３】
ＭＦＰ１のＩＰアドレスを１つにすれば、ＩＰのリソースの節約および煩雑さの低減が可能となる。ＩＰアドレスを１つとする仕組みの実現方法として、以下の方法がある：
（１）本体部１０に到着したパケットの宛先を操作部２０の内部ＩＰアドレスに変換して再送する（例えばＬｉｎｕｘ（登録商標）のiptableおよびsip6tables機能など）。
（２）要求（ＨＴＴＰリクエストなど）を本体部１０（サービス層１０２）で受付け、条件に応じて適切なサーバに要求を再送する（リバースプロキシ）。リバースプロキシは、認証・認可機能、暗号機能、負荷分散、キャッシュ、コンテンツの圧縮、および、速度調整等を行う。
【００４４】
図５では、リモートアプリ４０１が、本体部１０を介して操作部２０のアプリ２０１ｃへ要求を送信する例が示されている。
【００４５】
図５のような構成では、アプリ２０１ｃを動作させるときに、以下の（Ｐ１）および（Ｐ２）のような問題が生じうる。
【００４６】
（Ｐ１）電力モード制御
操作部２０は、ユーザがＭＦＰ１の付近にいる場合に使用されることが一般的である。ユーザがＭＦＰ１の付近にいない場合、省エネのために操作部２０が電源オフ（システムダウン）の状態になることがある。また、アプリ２０１ｃへ接続（開始）時に電源オンであっても、ユーザがＭＦＰ１の付近にいないため、接続中に電源オフになることがある。接続中の電源オフへの遷移は、アプリ２０１ｃ自身が電源モードロックのＡＰＩ（アプリケーションプログラミングインタフェース）等を使用して禁止することができる。しかし、アプリ２０１ｃの実装の煩雑さが増すことに加え、アプリ２０１ｃが禁止する機能の実装を忘れる可能性もある。さらに、電源モードロックのＡＰＩなどの特殊なＡＰＩを使用することは、別のＷｅｂプラットフォーム（コンテナ）への移植性、互換性を下げる。
【００４７】
（Ｐ２）アクセス制御
ＭＦＰ１の状態や設定に応じたアクセス制御方式が存在しない。例えば、アプリ２０１ｃが、本体部１０でスキャンした大規模のスキャン画像を、接続ケーブル等を経由して自身に転送するとする。このような場合、アプリ２０１ｃは、一定の転送レートを保証することが望ましい。しかし、例えばスキャン画像の転送途中に、クライアント４００からアプリ２０１ｃへ大量データの送信要求が送られると、一定の転送レートでの転送が実現できなくなる可能性がある。また、例えば操作部２０のアップデート中などのように、アプリ２０１ｃへのアクセスを抑制する必要が生じる場合がある。なおアップデートには、操作部２０のシステムデータ（アドレス帳など）、システム、および、モジュールなどのネットワーク経由でのアップデート、並びに、操作部２０のＳＤカードによるアップデートが含まれる。このような場合、クライアント４００からの要求にはサービス利用不可を示す応答（ステータスコード等）を返すべきであるが、そもそも、このような状態で操作部２０が動作している保証はない。また、アプリ２０１ｃは、リバースプロキシから再送された要求に応じることもできないかもしれない。その場合、リバースプロキシは、タイムアウトまで待たなければならず、またアプリ２０１ｃがどのような理由により応答できなかったのかも知ることができない。これでは効率も悪いし、クライアント４００に適切なステータスコードが返されることもない。
【００４８】
そこで本実施形態のＭＦＰ１は、クライアント４００からの要求を受け付けると、要求の内容と、機器（本体部１０と操作部２０）の状態と、設定等に応じて、要求に対する処理を制御する。これにより、上記（Ｐ１）および（Ｐ２）のような問題を解消し、ユーザの利便性を向上させることができる。
【００４９】
図６は、本実施形態にかかるＭＦＰ１のさらに詳細な構成を示すブロック図である。なお上記各図と同じ構成については同一の符号を付し説明を省略する。図６に示すように、ＭＦＰ１の本体部１０は、外部接続部６５１と、要求制御部６５２と、リソース管理部６５３と、電源制御部６５４と、コンテナ６６０と、ＨＤＤ１４と、設定記憶部６７１と、を備える。
【００５０】
設定記憶部６７１は、ＭＦＰ１に対する各種設定情報を記憶する。設定記憶部６７１は、ＨＤＤ１４などにより実現してもよいし、ＨＤＤ１４以外の記憶媒体を用いてもよい。
【００５１】
外部接続部６５１は、本体部１０のネットワーク処理（物理層〜トランスポート層）を行う。例えば外部接続部６５１は、クライアント４００からの要求を受付け（受信部）、受け付けた要求を要求制御部６５２に渡す。また外部接続部６５１は、要求制御部６５２から応答を受け取り、クライアント４００に返す。外部接続部６５１は、本体部１０のシステム停止状態でクライアント４００からの要求を受けた場合、要求をトリガーとして本体部１０を通電させる。
【００５２】
リソース管理部６５３は、ＭＦＰ１のリソースを管理する。例えばリソース管理部６５３は、定期的にリソースに関する情報（リソース情報）を要求制御部６５２に通知する。要求制御部６５２がリソース管理部６５３にアクセスしてリソース情報を取得してもよい。
【００５３】
電源制御部６５４は、操作部２０およびＨＤＤ１４などへの電力の供給を制御する。
【００５４】
コンテナ６６０は、アプリ６６２ａ、６６２ｂと、アプリ管理部６６１と、を備える。アプリ６６２ａ、６６２ｂは、例えば本体部１０で動作するＷｅｂアプリである。なおアプリ６６２ａ、６６２ｂを区別する必要がない場合は単にアプリ６６２という場合がある。アプリ管理部６６１は、アプリ６６２などの本体部１０で動作するアプリのインストール、アンインストール、および、状態確認などを行う。
【００５５】
要求制御部６５２は、要求の内容、機器の状態、設定記憶部６７１に記憶された設定情報に応じて、要求に対する処理を制御する。要求制御部６５２による制御処理の詳細は後述する。
【００５６】
なお外部接続部６５１、要求制御部６５２、リソース管理部６５３、および、電源制御部６５４は、例えば図３のサービス層１０２またはＯＳ層１０３の機能として実現できる。コンテナ６６０は、例えば図３のアプリ層１０１の機能として実現できる。
【００５７】
操作部２０は、操作部システム６３０と、コンテナ６１０と、メディア管理部６２０と、を備える。操作部システム６３０は、操作部２０の基盤となるシステムであり、例えば図３のＯＳ層２０３およびサービス層２０２に相当する。操作部システム６３０は、省エネ中に電源を復帰させる機能を備えてもよい。
【００５８】
コンテナ６１０は、アプリ６１２ａ、６１２ｂと、アプリ管理部６１１と、を備える。アプリ６１２ａ、６１２ｂは、例えば操作部２０で動作するＷｅｂアプリである。アプリ管理部６１１は、アプリ６１２ａ、６１２ｂなどの操作部２０で動作するアプリのインストール、アンインストール、および、状態確認などを行う。コンテナ６１０は、例えば図３のアプリ層２０１の機能として実現できる。なおアプリ６１２ａ、６１２ｂを区別する必要がない場合は単にアプリ６１２という場合がある。
【００５９】
メディア管理部６２０は、ＳＤカードなどの外部メディア７００との接続、外部メディア７００との間の情報の送受信などを行う。外部メディア７００は、例えば操作部２０のアップデートなどに使用される。メディア管理部６２０は、例えば図３のアプリ層２０１またはサービス層２０２の機能として実現できる。
【００６０】
以下、要求制御部６５２の機能についてさらに説明する。例えば要求制御部６５２は、要求の宛先（ＵＲＬ：Uniform  Resource  Locatorなど）が操作部２０のアプリ（アプリ６１２）である場合、電源制御部６５４を通して操作部２０を通電させる。なお、操作部２０が既に通電している場合、および、要求の宛先が本体部１０内のアプリ（アプリ６６２）の場合、操作部２０を通電する制御は不要である。操作部２０と本体部１０とは、例えばＵＳＢ等の電源・信号線（通信路４０）で接続される。本体部１０の電源制御部６５４は、ホストとしてデバイス側である操作部２０の電源制御を行うことができる。
【００６１】
要求制御部６５２は、操作部システム６３０から「接続可能」または「接続不可能」を示す通知（接続可能通知、または、接続不可能通知）を受信することで、アプリ６１２が接続可能の状態であるか、接続不可能の状態であるかを認識できる。接続不可能な状態とは、例えば、操作部２０が通電されていない状態、通電した直後の状態、システム停止の直前の状態、および、システム更新中の状態などである。
【００６２】
要求制御部６５２は、少なくとも要求の処理中は、操作部２０の電源オフを禁止する（電源モードロック）。例えば要求制御部６５２は、まず、要求情報を受けた本体部１０の電源オフを禁止する。要求制御部６５２は、要求情報の宛先がアプリ６１２であれば操作部２０の電源オフも禁止する。要求制御部６５２は、例えば電源モードロックのＡＰＩを用いることにより、本体部１０および操作部２０の電源オフを禁止する。アプリ６１２の処理が終了したら、要求制御部６５２は、電源モードのロックを必要に応じて解除する。電源モードロックは、操作部システム６３０のＡＰＩ等を使用してアプリ６１２が行うこともできるが、要求制御部６５２が実行することでアプリ６１２の実装の煩雑さを低減できる。
【００６３】
また要求制御部６５２は、少なくともアプリ６１２の要求を処理中は、システムモードロックを行う。例えば要求制御部６５２は、アプリ６１２の処理中に、本体部１０や操作部２０のシステムアップデート、並びに、設定情報およびアドレス帳などのシステム情報の更新が実行されないようにする。逆に、上述のシステムアップデートなどの処理が実行中に、アプリ６１２への要求が発生した場合、要求制御部６５２は、アプリ６１２が利用できないことを示す情報（５０３（Service  Unavailable）など）を返してもよい。
【００６４】
また要求制御部６５２は、機器の状態に応じて動的に要求を処理する。例えば、本体部１０および操作部２０（以下、単にシステムともいう）やアプリ６６２による伝送路（通信路４０）のリソース使用率が一定値を超えていた場合、アプリ６１２への要求の再送を行わず保留し、リソース使用率が一定値を下回った場合に要求を再送する。リソース管理部６５３は、このようなリソースの使用状況を測定し、リソースの変化に応じて、要求制御部６５２にリソース情報を通知する。
【００６５】
システム、アプリ６６２、および、アプリ６１２で、通信路４０のリソースを（同時に）共有することはできる。しかし、システムやアプリ６６２の伝送を優先したいといった要望や、共有によるスイッチングのオーバーヘッドの影響により、システム全体効率が下がる場合がある。
【００６６】
要求の再送を保留せずに、アプリ６１２への要求をリダイレクトするプロセスまたはスレッドの優先度を下げることで、システムに優先的にリソースを使用させる方法もある。また、システムリソースに対するロック機能を設けておき、ロック機能が利用できない場合は要求を保留する方法もある。ＣＰＵ（ＣＰＵ１１、ＣＰＵ２１）、ＲＡＭ（ＲＡＭ１３、ＲＡＭ２３）、および、通信路４０などの、アプリ６１２およびシステムのいずれも使用するリソースを一定時間確保したい場合、要求制御部６５２は、システムリソースのロック、および、ロック解除を行う。
【００６７】
要求制御部６５２は、要求の制御に関する設定情報を設定するためのＡＰＩを有している。設定された設定情報は、設定記憶部６７１に記憶される。例えば、通信路４０の使用率が８０％を越えているときには転送しない、などの設定情報が記憶される。
【００６８】
要求制御部６５２は、アプリ６１２が公開しているＵＲＬを知っている。このために、アプリ管理部６１１は、インストールおよびアンインストール時に、アプリ６１２が公開するＵＲＬを要求制御部６５２に通知する。アプリ６１２が公開するＵＲＬが動的に変更される場合は、アプリ管理部６１１は、ＵＲＬが公開された時点で、このＵＲＬを要求制御部６５２に通知する。要求制御部６５２は、同じＵＲＬを公開している他のアプリが既にインストールされている、または実行されている場合は、アプリ管理部６１１に対してエラー（ＮＧ）の応答を行う。エラーの応答を受けたアプリ管理部６１１は、アプリ６１２のインストールを失敗するなど、適切な処置を行う。
【００６９】
アプリ６１２は、要求制御部６５２に対し、要求のリダイレクト先を設定できる。例えばアプリ６１２は、要求のＵＲＬが「/opepane/app1」であった場合、リダイレクト先として「/machine/app1」を設定することができる。リダイレクト先の情報も、上述の設定情報を設定するためのＡＰＩを経由して設定することができ、設定記憶部６７１に保存される。
【００７０】
要求制御部６５２は、タイムアウトまでの時間を表すタイムアウト時間を有する。例えば要求制御部６５２は、アプリ６１２から、タイムアウト時間を超えて応答がない場合、アプリ６１２との通信を切断し、クライアント４００にエラーを返す。
【００７１】
次に、このように構成された本実施形態の情報処理システムによる要求制御処理について説明する。図７は、本実施形態の要求制御処理の一例を示すシーケンス図である。図７は、要求に応じて電力の供給を制御する場合の処理の例を示す。また図７では、例えば操作部２０が一定時間、使用されていなかったことにより、操作部２０が電源オフの状態であることを前提とする。
【００７２】
クライアント４００は、ＭＦＰ１内のいずれかのアプリに対する要求を送信する（ステップＳ１０１）。外部接続部６５１は、送信された要求を受け付け、要求制御部６５２に送信する（ステップＳ１０２）。本体部１０が停止中であれば、外部接続部６５１は、要求をトリガーとして本体部１０を通電させる。
【００７３】
要求制御部６５２は、要求の内容（ＵＲＬなど）を確認し、アクセス先（リダイレクト先）がアプリ６１２およびアプリ６６２のいずれであるかを判断する（ステップＳ１０３）。いずれにも該当しないＵＲＬであれば、クライアントにエラー（ＨＴＴＰの場合、４０４（Not  Found）など）を返す。
【００７４】
要求制御部６５２は、本体部１０の電源モードをロックし（ステップＳ１０４）、システムモードをロックする（ステップＳ１０５）。これにより、本体部１０の電源断およびシステム関連の操作が禁止される。要求制御部６５２は、電源制御部６５４に電源モードロックを実行させてもよい。また要求制御部６５２は、システムを管理する別のモジュールにシステムモードロックを実行させてもよい。
【００７５】
アクセス先のＵＲＬが、アプリ６１２が公開しているＵＲＬであった場合、以下のステップＳ１０６〜ステップＳ１２２までの処理が実行される。要求制御部６５２は、要求をアプリ６１２にリダイレクトする。このとき、操作部２０が電源オフの状態であれば、以下のステップＳ１０６〜ステップＳ１１４までの処理が実行される。
【００７６】
要求制御部６５２は、電源制御部６５４に電源操作（操作部２０の通電）の指示を送る（ステップＳ１０６）。電源制御部６５４は、操作部２０を通電した場合は通電したことを示す情報（受付ＯＫ）を返す（ステップＳ１０７）。ハードウェア異常など、何らかの理由で受付できない場合は、電源制御部６５４は、受付できなかったことを示す情報（受付ＮＧ）を返す。受付ＮＧの場合、要求制御部６５２は、一定回数のリトライを行ってもよい。一定回数のリトライ後も通電できなかった場合は、要求制御部６５２は、システムエラーを示すステータスコードおよびメッセージなどをクライアント４００に返す。
【００７７】
電源制御部６５４は、ＨＤＤ１４が通電されていない場合、通電する（ステップＳ１０８）。これにより、利用再開するまで時間のかかる物理ディスク（ＨＤＤ１４）を先に通電し、アプリ６１２が再開後にすぐに利用可能な状態にすることができる。また、電源制御部６５４は、操作部システム６３０に通電処理を指示する（ステップＳ１０９）。
【００７８】
操作部システム６３０は、アプリ管理部６１１を介してアプリ６１２を再開させる（ステップＳ１１０、ステップＳ１１１）。アプリ管理部６１１は、操作部２０が接続可能である旨の通知（接続可能通知）を要求制御部６５２に送信する（ステップＳ１１２）。要求制御部６５２は、操作部システム６３０から接続可能通知を受信する。要求制御部６５２は、電源操作に対する受付ＯＫを受けてから一定時間、待機する。一定時間内に接続可能通知が受信できない場合は、エラーが発生した旨を示すステータスコードおよびメッセージなどをクライアント４００に返す。
【００７９】
アプリ６１２は、再開されるとアプリ管理部６１１を通じて、ＨＤＤ１４が利用可能である旨の通知を受ける（ステップＳ１１３、ステップＳ１１４）。
【００８０】
要求制御部６５２は、操作部２０の電源モードとシステムモードをロックし、動作を制限する（ステップＳ１１５、ステップＳ１１６）。システムモードのロックは、複数種類があってもよい。例えば、ファームウェアの更新をロックする、アプリのインストールおよび更新をロックする、および、システムのデータ更新をロックする、などの種類がある。いずれのシステムモードのロックを実行するかは、例えば設定記憶部６７１の設定情報で設定される。
【００８１】
要求制御部６５２は、アプリ６１２に対して、要求を送信（リダイレクト）する（ステップＳ１１７）。本体部１０と操作部２０は、内部ネットワーク（通信路４０）により接続されている。リダイレクトの際、要求制御部６５２は、外部接続部６５１のネットワーク情報（ＩＰアドレス、サブネットなど）も合わせてアプリ６１２に通知する。アプリ６１２が、Ｗｅｂページのリンク等を作る際に、クライアント４００から接続可能なネットワーク情報が必要となるためである。
【００８２】
アプリ６１２は、要求を処理し（ステップＳ１１８）、応答（ＨＴＴＰレスポンスなど）を要求制御部６５２に返す（ステップＳ１１９）。要求制御部６５２は、応答情報（例えばＨＴＴＰのステータスコード「２００  ＯＫ」）を設定する（ステップＳ１２０）。
【００８３】
要求制御部６５２は、操作部２０の電源モードとシステムモードのロックを解除する（ステップＳ１２１、ステップＳ１２２）。要求制御部６５２は、本体部１０の電源モードとシステムモードのロックを解除する（ステップＳ１２３、ステップＳ１２４）。
【００８４】
要求制御部６５２は、外部接続部６５１を介してして、クライアント４００に応答を返す（ステップＳ１２５、ステップＳ１２６）。
【００８５】
図８は、本実施形態の要求制御処理の他の例を示すシーケンス図である。図８は、要求およびＭＦＰ１の状態に応じて操作部２０へのアクセスを制御する場合の処理の例を示す。
【００８６】
要求制御部６５２は、事前に接続可能通知を受信し（ステップＳ２０１）、アプリ６１２に接続可能であることがわかっている。
【００８７】
ステップＳ２０２からステップＳ２０８は、図７のステップＳ１０１からステップＳ１０５、ステップＳ１１５、および、ステップＳ１１６と同様であるため説明を省略する。
【００８８】
リソース管理部６５３は、定期的にリソース情報を、要求制御部６５２に通知する（ステップＳ２０９）。要求制御部６５２がリソース管理部６５３にアクセスしてリソース情報を取得してもよい（ステップＳ２１０）。リソース情報は、例えば、リソースの使用量を表す情報（リソース使用量）、および、リソースの使用率を表す情報（リソース使用率）などのように、現在のリソースの使用状況を表す情報である。これ以外の情報をリソース情報として用いてもよい。
【００８９】
要求制御部６５２は、要求の内容（サイズなど）、設定情報、および、リソース情報を確認し、アプリ６１２に要求をリダイレクトできるか否か、すなわち、要求されたアプリ６１２の実行を許可するか否かを判断する。要求をアプリ６１２に送信できる場合、要求制御部６５２は、要求をアプリ６１２に送信する（ステップＳ２１１）。アプリ６１２は、要求を処理し（ステップＳ２１２）、応答（ＨＴＴＰレスポンスなど）を要求制御部６５２に返す（ステップＳ２１３）。要求制御部６５２は、クライアント４００に返す応答情報（例えばＨＴＴＰのステータスコード「２００  ＯＫ」）を設定する（ステップＳ２１４）。
【００９０】
要求をアプリ６１２に送信できない場合、要求制御部６５２は、タイムアウト時間が経過するまで、または、リトライ回数に達するまで、ステップＳ２０９およびステップＳ２１０を繰り返してもよい。最終的に要求を送信できないと判断した場合、要求制御部６５２は、アプリ６１２の実行を許可しないことを示す情報をクライアント４００に返してもよい。例えば要求制御部６５２は、アプリ６１２が利用できないことを示す情報（５０３（Service  Unavailable）など）をクライアント４００に返す応答情報として設定する（ステップＳ２１５）。
【００９１】
ステップＳ２１６からステップＳ２２１は、図７のステップＳ１２１からステップＳ１２６と同様であるため説明を省略する。
【００９２】
なお、図８の要求制御処理は、要求のＵＲＬがアプリ６１２宛だった場合の処理を示している。要求のＵＲＬが本体部１０のアプリ６６２であった場合は、通信路４０のリソースは考慮に入れなくてもよい。
【００９３】
図９は、本実施形態の要求制御処理の他の例を示すシーケンス図である。図９は、操作部２０のモジュールがアップデート中のアクセス制御の例を示す。例えば操作部２０のアプリ管理部６１１などのモジュールのアップデート中に、アプリ６１２に対する要求が受信されたとする。
【００９４】
操作部システム６３０は、例えばメディア管理部６２０を用いて、外部メディアの情報を確認する（ステップＳ３０１、ステップＳ３０２）。例えばメディア管理部６２０は、ＳＤカードなどの外部メディア７００のデータがアプリ６１２の更新データなどのようにシステム動作に影響するデータである場合は、操作部システム６３０からの問い合わせに対して、システム動作に制約の発生するデータである旨を通知する。
【００９５】
操作部システム６３０は、要求制御部６５２に、動作制約（例えば操作部２０内のモジュールのアップデート中）が発生することを通知してもよい。例えば操作部システム６３０は、操作部２０のモジュールがアップデート中の場合は、アップデート中である旨の情報（イベント等）を要求制御部６５２に送信する（ステップＳ３０３）。
【００９６】
一方、ＳＤカード内のデータが、操作部システム６３０やアプリ６１２の更新などに関係のないデータである場合、メディア管理部６２０は、システム動作に関係のないデータである旨を操作部システム６３０に返す。この場合、要求制御部６５２には制約は発生しないため何も通知されない。また操作部システム６３０は、ＳＤカードなどの外部メディア７００が挿入されたことを知ることができる。
【００９７】
これにより、要求制御部６５２は、操作部２０のモジュールがアップデート中であり、操作部２０のアプリ管理部６１１に要求をリダイレクトできないことを事前に知ることができる。要求がリダイレクトできないことを知る方法はこれに限られるものではない。例えば、操作部２０のシステムモードのロックが失敗することを検知することにより、要求がリダイレクトできないと判断してもよい。
【００９８】
ステップＳ３０４からステップＳ３０６は、図７のステップＳ１０１からステップＳ１０３と同様であるため説明を省略する。
【００９９】
この例では、操作部２０に要求をリダイレクトができないため、要求制御部６５２は、アプリ６１２が利用できないことを示す情報（５０３（Service  Unavailable）など）をクライアント４００に返す応答情報として設定する（ステップＳ３０７）。
【０１００】
アクセス先のＵＲＬが、本体部１０のアプリ６６２が公開しているＵＲＬであった場合、以下のステップＳ３０８〜ステップＳ３１５までの処理が実行される。
【０１０１】
要求制御部６５２は、本体部１０の電源モードとシステムモードをロックし、動作を制限する（ステップＳ３０８、ステップＳ３０９）。要求制御部６５２は、アプリ６６２に対して、要求を送信（リダイレクト）する（ステップＳ３１０）。アプリ６６２は、要求を処理し（ステップＳ３１１）、応答（ＨＴＴＰレスポンスなど）を要求制御部６５２に返す（ステップＳ３１２）。要求制御部６５２は、応答情報（例えばＨＴＴＰのステータスコード「２００  ＯＫ」）を設定する（ステップＳ３１３）。要求制御部６５２は、本体部１０の電源モードとシステムモードのロックを解除する（ステップＳ３１４、ステップＳ３１５）。
【０１０２】
ステップＳ３１６からステップＳ３１７は、図７のステップＳ１２５からステップＳ１２６と同様であるため説明を省略する。
【０１０３】
このように本実施形態では、外部からの要求の内容と、機器の状態と、設定等に応じて、要求に対する処理を制御する。例えば電源モード制御では、操作部のアプリ向けの要求であった場合、操作部を通電状態にさせた後、システムダウンしないよう電力モードロックを行い、操作部のアプリに要求をリダイレクトする。例えばアクセス制御では、ＣＰＵ、メモリ、および、通信帯域などのシステムリソースの状況や操作部の状態に応じて、操作部のアプリが通信すべき状態かを判断し、通信すべき場合には操作部のアプリに要求をリダイレクトする。このような制御により、ユーザの利便性を向上させることができる。
【０１０４】
次に、本実施形態にかかるクライアント４００およびサーバ３００のハードウェア構成について図１０を用いて説明する。図１０は、本実施形態にかかるクライアント４００およびサーバ３００のハードウェア構成例を示す説明図である。
【０１０５】
本実施形態にかかるクライアント４００およびサーバ３００は、ＣＰＵ（Central  Processing  Unit）１００１などの制御装置と、ＲＯＭ（Read  Only  Memory）１００２やＲＡＭ（Random  Access  Memory）１００３などの記憶装置と、ネットワークに接続して通信を行う通信Ｉ／Ｆ１００４と、各部を接続するバス１０１１を備えている。
【０１０６】
本実施形態にかかるクライアント４００およびサーバ３００で実行されるプログラムは、ＲＯＭ１００２等に予め組み込まれて提供される。
【０１０７】
本実施形態にかかるクライアント４００およびサーバ３００で実行されるプログラムは、インストール可能な形式又は実行可能な形式のファイルでＣＤ−ＲＯＭ（Compact  Disk  Read  Only  Memory）、フレキシブルディスク（ＦＤ）、ＣＤ−Ｒ（Compact  Disk  Recordable）、ＤＶＤ（Digital  Versatile  Disk）等のコンピュータで読み取り可能な記録媒体に記録してコンピュータプログラムプロダクトとして提供されるように構成してもよい。
【０１０８】
さらに、本実施形態にかかるクライアント４００およびサーバ３００で実行されるプログラムを、インターネット等のネットワークに接続されたコンピュータ上に格納し、ネットワーク経由でダウンロードさせることにより提供するように構成してもよい。また、本実施形態にかかるクライアント４００およびサーバ３００で実行されるプログラムをインターネット等のネットワーク経由で提供または配布するように構成してもよい。
【０１０９】
本実施形態にかかるクライアント４００およびサーバ３００で実行されるプログラムは、コンピュータを上述したクライアント４００およびサーバ３００の各部として機能させうる。このコンピュータは、ＣＰＵ１００１がコンピュータ読取可能な記憶媒体からプログラムを主記憶装置上に読み出して実行することができる。
【符号の説明】
【０１１０】
１０  本体部
２０  操作部
３０  ネットワーク
４０  通信路
１０１ａ  標準コピーアプリ
１０１ｂ  標準スキャンアプリ
３００  サーバ
４００  クライアント
６１０  コンテナ
６１１  アプリ管理部
６１２ａ、６１２ｂ  アプリ
６２０  メディア管理部
６３０  操作部システム
６５１  外部接続部
６５２  要求制御部
６５３  リソース管理部
６５４  電源制御部
６６０  コンテナ
６６１  アプリ管理部
６６２ａ、６６２ｂ  アプリ
６７１  設定記憶部
７００  外部メディア
【先行技術文献】
【特許文献】
【０１１１】
【特許文献１】特開２０１２−２２２６７８号公報
【図１】
0006447288.tif 000002
【図２】
0006447288.tif 000003
【図３】
0006447288.tif 000004
【図４】
0006447288.tif 000005
【図５】
0006447288.tif 000006
【図６】
0006447288.tif 000007
【図７】
0006447288.tif 000008
【図８】
0006447288.tif 000009
【図９】
0006447288.tif 000010
【図１０】
0006447288.tif 000011