(57)【要約】【課題】外部からの不正アクセス等を防止しセキュリティを向上させることができる電子機器、情報処理システム、制御方法およびプログラムを提供する。【解決手段】クライアント装置と接続され、アプリケーションが動作する電子機器であって、アプリケーションへのアクセス要求をクライアント装置から受信する受信部と、電子機器にログインしている第１のユーザ、または、第１のユーザ以外の第２のユーザであるアクセスユーザの認証を認証部に要求する認証制御部と、認証部によりアクセスユーザが認証された場合に、アクセスユーザによるアプリケーションへのアクセスを制御する要求制御部と、を備える。【選択図】図５
2017049838.tif 000002
【特許請求の範囲】
【請求項１】
クライアント装置と接続され、アプリケーションが動作する電子機器であって、
前記アプリケーションへのアクセス要求を前記クライアント装置から受信する受信部と、
前記電子機器にログインしている第１のユーザ、または、前記第１のユーザ以外の第２のユーザであるアクセスユーザの認証を認証部に要求する認証制御部と、
前記認証部により前記アクセスユーザが認証された場合に、前記アクセスユーザによる前記アプリケーションへのアクセスを制御する要求制御部と、
を備える電子機器。
【請求項２】
前記認証制御部は、前記第１のユーザが認証されていないことを示す通知情報を前記クライアント装置に送信し、
前記受信部は、さらに、前記通知情報に対して前記クライアント装置が送信した前記第１のユーザの認証情報を受信し、
前記認証制御部は、受信された前記認証情報を用いて前記第１のユーザである前記アクセスユーザの認証を前記認証部に要求する、
請求項１に記載の電子機器。
【請求項３】
前記認証制御部は、前記第１のユーザを特定し、特定した前記第１のユーザの識別情報を含む前記通知情報を前記クライアント装置に送信する、
請求項２に記載の電子機器。
【請求項４】
前記アプリケーションの認証方式を定める設定情報を記憶する記憶部をさらに備え、
前記認証制御部は、前記設定情報で定められる認証方式による認証を前記認証部に要求する、
請求項１に記載の電子機器。
【請求項５】
前記認証方式は、前記ログインしているユーザを認証する方式、特定の権限を有するユーザを認証する方式、および、前記アプリケーションが前記認証部として認証する方式、の少なくとも１つである、
請求項４に記載の電子機器。
【請求項６】
前記認証制御部は、前記アクセスユーザが認証された場合に、前記アクセスユーザが認証されたことを示す認証チケットを前記クライアント装置に送信する、
請求項１に記載の電子機器。
【請求項７】
前記認証チケットは、認証の有効期限を示す情報を含む、
請求項６に記載の電子機器。
【請求項８】
クライアント装置と、前記クライアント装置に接続され、アプリケーションが動作する電子機器と、を備える情報処理システムであって、
前記電子機器は、
前記アプリケーションへのアクセス要求を前記クライアント装置から受信する受信部と、
前記電子機器にログインしている第１のユーザ、または、前記第１のユーザ以外の第２のユーザであるアクセスユーザの認証を認証部に要求する認証制御部と、
前記認証部により前記アクセスユーザが認証された場合に、前記アクセスユーザによる前記アプリケーションへのアクセスを制御する要求制御部と、を備える、
情報処理システム。
【請求項９】
クライアント装置と接続され、アプリケーションが動作する電子機器で実行される制御方法であって、
前記アプリケーションへのアクセス要求を前記クライアント装置から受信する受信ステップと、
前記電子機器にログインしている第１のユーザ、または、前記第１のユーザ以外の第２のユーザであるアクセスユーザの認証を認証部に要求する認証制御ステップと、
前記認証部により前記アクセスユーザが認証された場合に、前記アクセスユーザによる前記アプリケーションへのアクセスを制御する要求制御ステップと、
を含む制御方法。
【請求項１０】
前記認証制御ステップは、前記第１のユーザが認証されていないことを示す通知情報を前記クライアント装置に送信し、
前記受信ステップは、さらに、前記通知情報に対して前記クライアント装置が送信した前記第１のユーザの認証情報を受信し、
前記認証制御ステップは、受信された前記認証情報を用いて前記第１のユーザである前記アクセスユーザの認証を前記認証部に要求する、
請求項９に記載の制御方法。
【請求項１１】
前記認証制御ステップは、前記第１のユーザを特定し、特定した前記第１のユーザの識別情報を含む前記通知情報を前記クライアント装置に送信する、
請求項１０に記載の制御方法。
【請求項１２】
前記アプリケーションの認証方式を定める設定情報を記憶する記憶部をさらに備え、
前記認証制御ステップは、前記設定情報で定められる認証方式による認証を前記認証部に要求する、
請求項９に記載の制御方法。
【請求項１３】
前記認証方式は、前記ログインしているユーザを認証する方式、特定の権限を有するユーザを認証する方式、および、前記アプリケーションが前記認証部として認証する方式、の少なくとも１つである、
請求項１２に記載の制御方法。
【請求項１４】
前記認証制御ステップは、前記アクセスユーザが認証された場合に、前記アクセスユーザが認証されたことを示す認証チケットを前記クライアント装置に送信する、
請求項９に記載の制御方法。
【請求項１５】
前記認証チケットは、認証の有効期限を示す情報を含む、
請求項１４に記載の制御方法。
【請求項１６】
クライアント装置と接続され、アプリケーションが動作するコンピュータに、
前記アプリケーションへのアクセス要求を前記クライアント装置から受信する受信ステップと、
前記コンピュータにログインしている第１のユーザ、または、前記第１のユーザ以外の第２のユーザであるアクセスユーザの認証を認証部に要求する認証制御ステップと、
前記認証部により前記アクセスユーザが認証された場合に、前記アクセスユーザによる前記アプリケーションへのアクセスを制御する要求制御ステップと、
を実行させるためのプログラム。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、電子機器、情報処理システム、制御方法およびプログラムに関する。
【背景技術】
【０００２】
組み込み機器などの電子機器は、例えばＷｅｂシステムを構成するクライアント装置に対して機能を提供するためのアプリケーション（以下、単に「アプリ」と称する場合がある）を有する場合がある。さらに、電子機器の出荷後に、必要に応じてアプリを利用して機能を拡張する仕組みが知られている。以下では、電子機器で動作しＷｅｂシステムから利用できるアプリをＷｅｂアプリと称する場合がある。Ｗｅｂアプリは、出荷後の電子機器に外部からアクセスできる機能を追加する仕組みとして便利であるが、成りすましを許すなどのセキュリティホールになる危険性がある。
【０００３】
一方、ＭＦＰ（Multifunction  Peripheral）のように、ユーザごとに課金、利用履歴、および、情報等を管理することが厳密に求められる電子機器では、通常、複数人が同時にログインすることはできず、一人のユーザがログインして当該電子機器を占有する。あるユーザのログイン中、ＭＦＰの操作は、当該ユーザの権限の範囲で操作することができる。
【発明の概要】
【発明が解決しようとする課題】
【０００４】
セキュリティの対策が不十分であると、例えば、あるユーザのログイン中に、別のユーザがネットワーク上のＰＣ（パーソナルコンピュータ）等の装置からＷｅｂアプリ等を経由して、ログイン中のユーザの権限で電子機器の機能が操作される可能性がある。例えば、ユーザＡのログイン中に、ユーザＢがＷｅｂアプリ経由でユーザＡにしか閲覧および編集の権限がないファイルを操作したり、ユーザＢが指示した印刷処理をユーザＡに課金してしまうかもしれない。
【０００５】
特許文献１は、ネットワーク間に存在するファイアーウォールセキュリティホールへの攻撃およびその乗っ取りによる不正アクセスを簡易に防止する技術を提案している。しかし特許文献１の技術は、例えばＷｅｂアプリを経由した機器操作の成りすましの防止には適用できない。
【０００６】
本発明は、上記に鑑みてなされたものであって、外部からの不正アクセス等を防止しセキュリティを向上させることができる電子機器、情報処理システム、制御方法およびプログラムを提供することを目的とする。
【課題を解決するための手段】
【０００７】
上述した課題を解決し、目的を達成するために、本発明は、クライアント装置と接続され、アプリケーションが動作する電子機器であって、前記アプリケーションへのアクセス要求を前記クライアント装置から受信する受信部と、前記電子機器にログインしている第１のユーザ、または、前記第１のユーザ以外の第２のユーザであるアクセスユーザの認証を認証部に要求する認証制御部と、前記認証部により前記アクセスユーザが認証された場合に、前記アクセスユーザによる前記アプリケーションへのアクセスを制御する要求制御部と、を備える。
【発明の効果】
【０００８】
本発明によれば、外部からの不正アクセス等を防止しセキュリティを向上させることができるという効果を奏する。
【図面の簡単な説明】
【０００９】
【図１】図１は、第１の実施形態の情報処理システムの全体構成の一例を示すブロック図である。
【図２】図２は、本実施形態のＭＦＰのハードウェア構成の例を示すブロック図である。
【図３】図３は、本実施形態にかかるクライアントおよびサーバのハードウェア構成例を示す説明図である。
【図４】図４は、本実施形態にかかるＭＦＰの機能構成の一例を示すブロック図である。
【図５】図５は、Ｗｅｂアプリ管理部のさらに詳細な機能構成の一例を示すブロック図である。
【図６】図６は、アクセス制御処理の概要について説明するための図である。
【図７】図７は、アクセス制御処理の一例を示すシーケンス図である。
【図８】図８は、変形例でのアクセス制御処理の概要について説明するための図である。
【図９】図９は、変形例でのアクセス制御処理の一例を示すシーケンス図である。
【図１０】図１０は、第２の実施形態のＭＦＰのハードウェア構成の例を示す図である。
【図１１】図１１は、第２の実施形態のＭＦＰのソフトウェア構成の例を示す図である。
【図１２】図１２は、本実施形態にかかるＭＦＰの機能構成の一例を示すブロック図である。
【図１３】図１３は、本実施形態でのアクセス制御処理の一例を示すシーケンス図である。
【発明を実施するための形態】
【００１０】
以下に添付図面を参照して、この発明にかかる電子機器、情報処理システム、制御方法およびプログラムの一実施形態を詳細に説明する。
【００１１】
以下では、コピー機能、プリンタ機能、スキャナ機能およびファクス機能のうち少なくとも２つの機能を有する複合機（ＭＦＰ）として電子機器を実現した例を説明する。複合機の他に、複写機、プリンタ、スキャナ装置、ファクス装置等の画像形成装置に適用してもよい。また適用可能な電子機器は、画像形成装置に限られるものではない。
【００１２】
（第１の実施形態）
図１は、第１の実施形態の情報処理システムの全体構成の一例を示すブロック図である。図１に示すように、情報処理システムは、ＭＦＰ１０と、クライアント装置としてのクライアント２０と、サーバ３０と、がネットワーク４０で接続された構成となっている。図１では各装置を１台ずつ記載しているが、各装置を複数台備えるように構成してもよい。
【００１３】
ネットワーク４０は、インターネットなどのあらゆるネットワーク形態を適用できる。またネットワーク４０は、無線ネットワークでもよいし有線ネットワークでもよい。
【００１４】
ＭＦＰ１０は、コピー機能、プリンタ機能、スキャナ機能およびファクス機能のうち少なくとも２つの機能を有するとともに、クライアント２０などの外部装置などから利用されるアプリ（Ｗｅｂアプリ）を有する。
【００１５】
クライアント２０は、ＰＣなどの装置である。クライアント２０は、ＭＦＰ１０で動作するアプリにアクセスするアプリ（リモートアプリ）を備えている。サーバ３０は、Ｗｅｂサービスなどを提供する装置である。
【００１６】
次にＭＦＰ１０のハードウェア構成の例について説明する。図２は、本実施形態のＭＦＰ１０のハードウェア構成の例を示すブロック図である。
【００１７】
図２に示すように、ＭＦＰ１０は、ＣＰＵ（Central  Processing  Unit）１０１と、ＲＯＭ（Read  Only  Memory）１０２と、ＲＡＭ（Random  Access  Memory）１０３と、ＨＤＤ（Hard  Disk  Drive）１０４と、エンジン１０５と、操作パネル１０６と、通信Ｉ／Ｆ（インタフェース）１０７とを備えている。上記各部は、システムバス１２１を介して相互に接続されている。
【００１８】
ＣＰＵ１０１は、ＭＦＰ１０の動作を統括的に制御する。ＣＰＵ１０１は、ＲＡＭ１０３を作業領域として、ＲＯＭ１０２またはＨＤＤ１０４等に格納されたプログラムを実行することで、ＭＦＰ１０全体の動作を制御し、上述したコピー機能、スキャナ機能、ファクス機能、プリンタ機能等の各種機能や、後述する各種機能を実現する。通信Ｉ／Ｆ１０７は、ネットワーク４０と接続するためのインタフェースである。エンジン１０５は、画像形成エンジン等であり、例えば、白黒プロッタ、ドラムカラープロッタ、スキャナまたはファクスユニット等である。操作パネル１０６は、タッチスクリーンやキーボード等を有する。例えば、タッチスクリーンは、タッチパネル機能を搭載した液晶表示装置（LCD：Liquid  Crystal  Display）や有機ＥＬ（Electro  Luminescence）表示装置である。キーボードは、ハードウェアキーの集合である。
【００１９】
操作パネル１０６は、単に画面を表示するための表示装置であってもよい。また、Ｂｌｕｅｔｏｏｔｈ（登録商標）等でＭＦＰ１０と接続されて動作するデバイスを、操作パネル１０６の代わりに用いてもよい。
【００２０】
次にクライアント２０およびサーバ３０のハードウェア構成について図３を用いて説明する。図３は、本実施形態にかかるクライアント２０およびサーバ３０のハードウェア構成例を示す説明図である。
【００２１】
本実施形態にかかるクライアント２０およびサーバ３０は、ＣＰＵ２０１などの制御装置と、ＲＯＭ２０２やＲＡＭ２０３などの記憶装置と、ネットワーク４０に接続して通信を行う通信Ｉ／Ｆ２０４と、各部を接続するバス２１１を備えている。
【００２２】
次にＭＦＰ１０の機能構成について説明する。図４は、本実施形態にかかるＭＦＰ１０の機能構成の一例を示すブロック図である。図４に示すように、ＭＦＰ１０は、Ｗｅｂアプリサービス１１と、組み込みブラウザ２１と、組み込みアプリ２２と、ＳＤＫアプリ２３と、記憶部２４と、リモートＡＰＩ（Application  Programming  Interface）３１と、内部ＡＰＩ３２と、本体機能３３と、を備えている。
【００２３】
Ｗｅｂアプリサービス１１は、必要に応じて（アドオンなどにより）Ｗｅｂアプリを追加できる仕組みである。Ｗｅｂアプリサービス１１は、Ｗｅｂアプリ管理部１３と、追加されたＷｅｂアプリ１２ａ、１２ｂを含む。Ｗｅｂアプリ１２ａ、１２ｂを区別する必要がないときは単にＷｅｂアプリ１２という場合がある。Ｗｅｂアプリ１２の個数は２に限られるものではなく、任意の個数とすることができる。
【００２４】
本体機能３３は、コピー機能、プリンタ機能、スキャナ機能およびファクス機能などの機能、並びに、ファイルシステムへのアクセス機能などの、ＭＦＰ１０の基本的な機能である。本体機能３３は、認証部３４を備えている。認証部３４は、ＭＦＰ１０を利用するユーザを認証する認証処理を実行する。認証部３４による認証処理は、例えば内部ＡＰＩ３２を介して利用することができる。
【００２５】
リモートＡＰＩ３１は、例えばサーバ３０が有するＷｅｂアプリ３０ａなどの外部モジュールから本体機能３３を呼び出すためのＡＰＩ（ＡＰＩ群）である。リモートＡＰＩ３１は、例えばＷｅｂＡＰＩの形式で提供される。
【００２６】
内部ＡＰＩ３２は、ＭＦＰ１０の内部モジュールから本体機能３３を呼び出すためのＡＰＩ（ＡＰＩ群）である。内部ＡＰＩ３２は、例えば関数（メソッド）およびＷｅｂＡＰＩの形式で提供される。
【００２７】
組み込みブラウザ２１は、ＭＦＰ１０上で動作するブラウザである。組み込みブラウザ２１は、一般的なＷｅｂサーバのサイト画面の他、ＭＦＰ１０上で動作するＷｅｂアプリ１２が生成するＷｅｂ  ＵＩ（ユーザインタフェース）を表示してもよい。
【００２８】
組み込みアプリ２２は、ＭＦＰ１０に予め組み込まれ、本体機能３３を利用するためのアプリである。組み込みアプリ２２は、例えばＵＩを有し、ユーザから直接使用される。
【００２９】
ＳＤＫアプリ２３は、ＭＦＰ１０の出荷後、必要に応じて（アドオンなどにより）インストールされるアプリである。ＳＤＫアプリ２３は、例えば内部ＡＰＩ３２を使用する。
【００３０】
記憶部２４は、ＭＦＰ１０による各種機能で用いられる各種情報を記憶する。記憶部２４は、例えば図２のＲＡＭ１０３、ＨＤＤ１０４などにより実現される。
【００３１】
Ｗｅｂアプリ管理部１３は、Ｗｅｂアプリ１２のインストール、アンインストール、および、情報取得などの管理を行う。Ｗｅｂアプリ１２は、インストール時または起動中などに、Ｗｅｂアプリ管理部１３に公開するＵＲＬ（Uniform  Resource  Locator）を登録する。Ｗｅｂアプリ管理部１３は、クライアント２０からのリクエスト（要求）を受付け、リクエストに含まれるＵＲＬに対応するＷｅｂアプリ１２にリクエストを送る。Ｗｅｂアプリ１２はＭＦＰ１０内で動作する内部モジュールであるため、リモートＡＰＩ３１の他、内部ＡＰＩ３２も呼び出すことができる。
【００３２】
図５は、Ｗｅｂアプリ管理部１３のさらに詳細な機能構成の一例を示すブロック図である。図５に示すように、Ｗｅｂアプリ管理部１３は、受信部５１と、認証制御部５２と、要求制御部５３と、を備えている。
【００３３】
受信部５１は、クライアント２０などの外部装置から各種情報を受信する。例えば受信部５１は、Ｗｅｂアプリ１２へのアクセス要求、および、ユーザの認証情報などをクライアント２０から受信する。
【００３４】
認証制御部５２は、認証部３４を用いた認証処理を制御する。例えば認証制御部５２は、Ｗｅｂアプリ１２へアクセスするユーザであるアクセスユーザの認証を認証部３４に要求する。アクセスユーザは、ＭＦＰ１０にログインしているユーザ（第１のユーザ）の場合もあるし、ＭＦＰ１０にログインしているユーザでないユーザ（第２のユーザ）の場合もある。
【００３５】
要求制御部５３は、クライアント２０などの外部装置からの各種要求に対する処理を制御する。要求制御部５３は、例えばアクセスユーザが認証された場合に、アクセスユーザによるＷｅｂアプリ１２へのアクセスを制御する。
【００３６】
次に、このように構成された本実施形態のＭＦＰ１０によるアクセス制御処理の概要について説明する。本実施形態では、あるユーザ（ユーザＡ）がＭＦＰ１０にログイン中に、リモートからＷｅｂアプリ１２へのリクエストが送信された場合、Ｗｅｂアプリ管理部１３が、Ｗｅｂアプリ１２により予め設定された認証方式（認証不要とする方式であってもよい）でユーザ認証を行うように、認証部３４に要求する。ユーザ認証が必要な場合、認証されていないことを示す通知情報をクライアント２０に送信する。当該通知情報を受けたクライアント２０は、ユーザＩＤおよびパスワード等の認証情報とともに、ＭＦＰ１０に再度リクエストを送信する。この認証情報により認証された場合、Ｗｅｂアプリ管理部１３は、Ｗｅｂアプリ１２へ当該リクエストを送るとともに、クライアント２０に認証チケットを発行する。クライアント２０は、これ以降、Ｗｅｂアプリ１２へのリクエストを送信するときに当該認証チケットを使用する。
【００３７】
このように本実施形態では、Ｗｅｂアプリ管理部１３が、Ｗｅｂアプリ１２にアクセスするユーザを認証部３４を用いて認証する制御を行う（認証制御部）。これにより、Ｗｅｂアプリなどを経由して電子機器に不正にアクセスすることを防止しセキュリティを向上させることが可能となる。
【００３８】
ここで、成りすましの脅威について説明する。例えばユーザＡが、操作パネル１０６などを使用してＭＦＰ１０にログインしているものとする。ユーザＡが、組み込みアプリ２２やＳＤＫアプリ２３を操作すると、その操作に応じて各アプリが内部ＡＰＩ３２を呼び出し本体機能３３が動作する。本体機能３３は、ログイン中のユーザＡの権限の範囲で動作する。例えば、ＳＤＫアプリ２３が内部ＡＰＩ３２のうちカラーコピー実行のＡＰＩを呼び出したとき、ユーザＡにカラーコピー実行の権限があればカラーコピーが実行される。また、例えばＳＤＫアプリ２３が、あるファイルを読み込むＡＰＩを呼び出したとき、ユーザＡに当該ファイルへの読み込み権限があれば、当ファイルを読み込むことができる。
【００３９】
ユーザＡのログイン中に、ユーザＢがクライアント２０からＷｅｂアプリ１２にリクエストを送信し、Ｗｅｂアプリ１２がそのリクエストに応じて、カラーコピー実行やファイル読み込みなどの内部ＡＰＩ３２を呼び出したとする。アクセス権限が適切に管理されていなかった場合、ログイン中のユーザＡの権限で本体機能３３が実行される可能性がある。例えば、ユーザＢの操作でカラーコピーが実行され、ユーザＡに課金してしまうかもしれない。Ｗｅｂアプリ１２が、内部ＡＰＩ３２を使用せず、ワンショット認証を伴うリモートＡＰＩ３１のみを使用して実装していればこのような状況を回避しうる。しかし、リモートＡＰＩ３１は機能が制限されているため利便性が低下するおそれがある。また、そもそもＷｅｂアプリ１２が誤って実装される可能性もある。Ｗｅｂアプリ１２はＭＦＰ１０内で動作するため、ＭＦＰ１０内のファイルシステムにアクセスできるなどの利便性を失うことは望ましくない。
【００４０】
成りすましの防止のため、内部ＡＰＩ３２の呼び出し元を特定し、呼び出し元がＷｅｂアプリ１２であった場合に、内部ＡＰＩ３２を実行させない方式も考えられる。しかし、このような方式では、Ｗｅｂアプリ１２の利便性が損なわれる、実装が煩雑になる、および、そもそも呼び出し元を特定できない場合には実現できない、という問題がある。
【００４１】
成りすましの防止のため、ユーザがログイン状態の場合、リクエストに対し現在システムが利用できない旨を示す応答（「System  Busy」など）を送信する方式も考えられる。しかしこの場合、リモートからＭＦＰ１０を使用する場合の利便性が著しく下がる。
【００４２】
これに対して本実施形態のＭＦＰ１０は、利便性を低下させずに、不正アクセス等を防止しセキュリティを向上させることができる。以下、ログイン中のユーザによるＷｅｂアプリ１２へのアクセスを認証する例について説明する。図６は、この例でのアクセス制御処理の概要について説明するための図である。
【００４３】
図６に示すように、アクセス制御処理は以下のように実行される。
（１）Ｗｅｂアプリ管理部１３は、クライアント２０からのＷｅｂアプリ１２に対するリクエストを受け付ける。
（２）Ｗｅｂアプリ管理部１３は、内部ＡＰＩ３２を呼び出しログイン中のユーザを確認する。ユーザＡがログイン中であることが特定されたものとする。なおログイン状態の取得処理は、ログイン状態が変化したときに内部ＡＰＩ３２からイベント通知する形式でもよい。
（３）Ｗｅｂアプリ管理部１３は、クライアント２０に対して、未認証である旨の通知を返す。例えば、現在ログイン中のユーザであるユーザＡで認証されていないという情報を含む通知が返される。この通知は、認証されるべきユーザ名などの情報を含んでもよい。
（４）クライアント２０は、この通知を受けて、元のリクエストにユーザＡのユーザＩＤおよびパスワード等の認証情報を加えたリクエストを、Ｗｅｂアプリ管理部１３に送信する。クライアント２０は、ベーシック認証方式、ダイジェスト認証などを使用して認証情報を送信できる。なお、クライアント２０が例えばＷｅｂＡＰＩを使用してログイン中のユーザ（ユーザＡ）を確認し、最初のリクエストにユーザＡの認証情報を含めるように構成してもよい。これにより（１）〜（３）の処理を省略することができる。
（５）Ｗｅｂアプリ管理部１３は、内部ＡＰＩ３２を使用して認証結果を取得する。
（６）Ｗｅｂアプリ管理部１３は、認証に成功した場合、該当するＵＲＬを登録したＷｅｂアプリ１２を呼び出す。例えばＷｅｂアプリ管理部１３は、Ｊａｖａ（登録商標）  Ｓｅｒｖｌｅｔの「doGet（）」、「doPost（）」などのメソッドを用いてＷｅｂアプリ１２を呼び出す。
（７）Ｗｅｂアプリ１２は、リクエストに応じて処理を実行し、処理を終了すると応答をＷｅｂアプリ管理部１３に送信する。
（８）Ｗｅｂアプリ管理部１３は、クライアント２０にレスポンス（応答）を返す。このときＷｅｂアプリ管理部１３は、認証チケットを渡してもよい。クライアント２０は、認証チケットを使用することで、再度認証情報を送る必要がなくなる。認証チケットの実装には、例えばクッキー（Ｃｏｏｋｉｅ）を利用することができる。
【００４４】
図７は、この例でのアクセス制御処理の一例を示すシーケンス図である。
【００４５】
クライアント２０は、ＭＦＰ１０のＷｅｂアプリ管理部１３に対して、Ｗｅｂアプリ１２に対するリクエスト（アクセス要求）を送信する（ステップＳ１０１）。Ｗｅｂアプリ管理部１３の受信部５１は、このリクエストを受信する。Ｗｅｂアプリ管理部１３は、例えば内部ＡＰＩ３２を用いて、認証部３４にユーザのログイン状態の取得を要求する（ステップＳ１０２）。認証部３４は、ログイン状態をＷｅｂアプリ管理部１３に送信する（ステップＳ１０３）。
【００４６】
あるユーザがログイン中であった場合、Ｗｅｂアプリ管理部１３は、未認証である旨の通知をクライアント２０に送信する（ステップＳ１０４）。この通知に、ログイン中のユーザを識別する識別情報を含めてもよい。
【００４７】
クライアント２０は、通知に含まれる識別情報などで特定されるユーザの認証情報を含むリクエストを、Ｗｅｂアプリ管理部１３に送信する（ステップＳ１０５）。このユーザが、Ｗｅｂアプリ１２へアクセスするアクセスユーザに相当する。Ｗｅｂアプリ管理部１３は、リクエストに含まれる認証情報による認証処理を認証部３４に要求する（ステップＳ１０６）。認証部３４は、要求に応じて認証処理を実行し、認証結果を送信する（ステップＳ１０７）。認証された場合（認証結果＝認証ＯＫ）、Ｗｅｂアプリ管理部１３は、受信したリクエストをＷｅｂアプリ１２に送信する（ステップＳ１０８）。
【００４８】
Ｗｅｂアプリ１２は、リクエストに応じた処理（リクエスト処理）を実行し（ステップＳ１０９）、処理の結果などを含むレスポンスをＷｅｂアプリ管理部１３に送信する（ステップＳ１１０）。Ｗｅｂアプリ管理部１３は、認証チケットなどを含むレスポンスをクライアント２０に送信する（ステップＳ１１１）。
【００４９】
Ｗｅｂアプリ管理部１３で行う処理をＷｅｂアプリ１２で行ってもよいが、一般的には認証処理は共通である特性を持つため、Ｗｅｂアプリ管理部１３が認証処理を制御するように構成している。これにより、各Ｗｅｂアプリ１２の実装負荷を減らすことができるとともに、そもそも各Ｗｅｂアプリ１２が認証処理に関する実装を忘れることを防止できる。
【００５０】
認証チケットは有効期限を設定してもよい。例えば認証チケットの有効期限は、以下のように設定できる。
・タイムアウト値の時間経過まで
・ユーザＡがログアウトするまで
・ユーザＡがログアウト後、別のユーザがログインするまで
【００５１】
また、Ｗｅｂアプリ１２をユーザＡの権限で処理しているときに、ＭＦＰ１０の操作パネル１０６などからユーザＢがログインしようとした場合、以下のような処理を実行してもよい。
・ユーザＢはログインさせない。
・Ｗｅｂアプリ１２の処理が完了するまで一定時間待ち、一定時間経過しても処理が完了しない場合はユーザＢをログインさせない。
・即時に、または、Ｗｅｂアプリ１２の処理の完了を一定時間待ち、ユーザＢをログインさせる。ログイン後、Ｗｅｂアプリ管理部１３は、Ｗｅｂアプリ１２の処理を例外等で停止させ、クライアント２０にエラーのレスポンスを返す。現在の認証チケットは無効にする。
【００５２】
図７のステップＳ１０３でいずれのユーザもログインしていない状態（未ログイン状態）であった場合、クライアント２０のユーザの認証は実行しなくてもよい。すなわち、ステップＳ１０４〜ステップＳ１０７までの処理は実行しなくてもよい。
【００５３】
（変形例）
図６および図７の例では、ログイン中のユーザでの認証が必要となる。このため、クライアント２０は、ログイン中となる可能性があるユーザ（例えば全ユーザ）の認証情報を持っていなければならない。例えば、Ｗｅｂアプリ１２が単にリモートから設定ファイルを読み込む機能のみを有するとしても、クライアント２０は全ユーザの認証情報を有していなければならない。
【００５４】
そこで、Ｗｅｂアプリ１２が、自身の認証方式を設定し、Ｗｅｂアプリ管理部１３が、設定された認証方式に従い認証処理を制御するように構成してもよい。図８および図９は、このように構成する変形例を説明する図である。図８は、本変形例でのアクセス制御処理の概要について説明するための図である。
【００５５】
図８に示すように、本変形例のＭＦＰ１０−２は、Ｗｅｂアプリサービス１１−２と、組み込みブラウザ２１と、組み込みアプリ２２と、ＳＤＫアプリ２３と、記憶部２４と、リモートＡＰＩ３１と、内部ＡＰＩ３２と、本体機能３３と、を備えている。Ｗｅｂアプリサービス１１−２以外の機能は図４と同様であるため同一の符号を付し説明を省略する。
【００５６】
Ｗｅｂアプリサービス１１−２は、Ｗｅｂアプリ１２−２ａ、１２−２ｂと、Ｗｅｂアプリ管理部１３−２を備えている。
【００５７】
Ｗｅｂアプリ１２−２ａ、１２−ｂ（以下、単にＷｅｂアプリ１２−２という場合がある）は、認証方式をＷｅｂアプリ管理部１３−２に対して設定する機能（認証設定）が追加される点が、上記実施形態のＷｅｂアプリ１２と異なっている。認証方式は、Ｗｅｂアプリ１２ごとに設定できるようにしてもよい。
【００５８】
Ｗｅｂアプリ管理部１３−２は、Ｗｅｂアプリ１２−２から設定された認証方式を定める設定情報を記憶部２４などに記憶する機能、および、認証方式に従いＷｅｂアプリ１２−２の認証処理を制御する点が、上記実施形態のＷｅｂアプリ管理部１３と異なっている。
【００５９】
本変形例のアクセス制御処理は以下のように実行される。
（１）Ｗｅｂアプリ１２−２は、インストール時または実行中に、Ｗｅｂアプリ管理部１３−２へ認証設定を行う。認証設定はどのような方法で実現してもよい。例えば、認証設定用のＡＰＩを用いる方法、および、Ｗｅｂアプリ１２−２が記憶部２４の設定ファイルなどに認証方式を定める設定情報を記憶し、Ｗｅｂアプリ管理部１３−２が設定ファイルに記憶された設定情報によって定められる認証方式を確認する方法などを適用できる。認証方式は、Ｗｅｂアプリ１２−２ごとに設定してもよい。例えば、クライアント２０からのリクエストが特権ユーザ（特定の権限を有するユーザの一例）の認証を必要とするＷｅｂアプリ１２−２であれば、特権ユーザで認証する認証方式を設定してもよい。
（２）Ｗｅｂアプリ管理部１３−２は、クライアント２０からＷｅｂアプリ１２−２にアクセスするリクエストを受付ける。
（３）Ｗｅｂアプリ管理部１３−２は、リクエストを受付けたＷｅｂアプリ１２−２の認証方式に従い、認証処理を制御する。例えば上記のように特権ユーザで認証する認証方式が設定されたＷｅｂアプリ１２−２へのリクエストであった場合、Ｗｅｂアプリ管理部１３−２は、内部ＡＰＩ３２等を使用して特権ユーザでの認証処理を制御する。
（４）認証された場合、Ｗｅｂアプリ管理部１３−２は、該当するＷｅｂアプリ１２−２を呼び出す。例えばＷｅｂアプリ管理部１３−２は、Ｊａｖａ  Ｓｅｒｖｌｅｔの「doGet（）」、「doPost（）」などのメソッドを用いてＷｅｂアプリ１２−２を呼び出す。
（５）Ｗｅｂアプリ１２−２の処理が終了したら、Ｗｅｂアプリ管理部１３−２は、クライアント２０にレスポンスを返す。
【００６０】
クライアント２０にレスポンスを返すときに、認証チケットは返さなくてもよい。認証設定にて、認証を必要としない設定にし、Ｗｅｂアプリ１２−２自体が独自に認証処理を実装することもできる。
【００６１】
変形例では、ログイン中のユーザの権限で操作が可能となるため、Ｗｅｂアプリ１２−２はセキュリティを低下させないように実装する必要がある。例えば、内部ＡＰＩ３２を呼び出すときに認証チケットを使用する方法、および、内部ＡＰＩ３２を呼び出す宣言をマニフェストファイルに記載するといった方法を併用してもよい。
【００６２】
設定する認証方式はどのような方式であってもよい。例えば、ログインしているユーザ（ログイン中のユーザ）を認証する方式、特定の権限を有するユーザを認証する方式、および、Ｗｅｂアプリ１２−２自身が認証部として認証処理を実行する方式などの認証方式を適用できる。特定の権限を有するユーザは、例えば、特権ユーザ、および、匿名（Ａｎｏｎｙｍｏｕｓ）ユーザなどである。また、これらの方式のうち２以上を組み合わせた認証方式を適用してもよい。例えば、ログイン中のユーザ、および、Ａｎｏｎｙｍｏｕｓユーザのいずれでも認証可能にする認証方式を適用してもよい。
【００６３】
図９は、変形例でのアクセス制御処理の一例を示すシーケンス図である。
【００６４】
まず、Ｗｅｂアプリ１２−２は、自身の認証方式をＷｅｂアプリ管理部１３−２に通知し認証設定を行う（ステップＳ２０１）。Ｗｅｂアプリ管理部１３−２は、通知された認証方式を例えば記憶部２４に記憶する（ステップＳ２０２）。
【００６５】
クライアント２０は、ＭＦＰ１０−２のＷｅｂアプリ管理部１３−２に対して、Ｗｅｂアプリ１２−２にアクセスするリクエストを送信する（ステップＳ２０３）。Ｗｅｂアプリ管理部１３−２は、リクエストを受けたＷｅｂアプリ１２−２に対応する認証方式を記憶部２４から取得する（ステップＳ２０４、ステップＳ２０５）。
【００６６】
Ｗｅｂアプリ管理部１３−２は、取得した認証方式で定められる認証処理を認証部３４に要求する（ステップＳ２０６）。認証方式で定められるユーザが、Ｗｅｂアプリ１２−２へアクセスするアクセスユーザとなる。例えばログイン中のユーザで認証する認証方式の場合は、ログイン中のユーザがアクセスユーザである。この場合、図６および図７と同様の方法により、ログイン中のユーザを特定してもよい。
【００６７】
認証部３４は、要求に応じて認証処理を実行し、認証結果を送信する（ステップＳ２０７）。Ｗｅｂアプリ１２−２自身が認証する認証方式の場合は、ステップＳ２０６およびステップＳ２０７に相当する処理をＷｅｂアプリ１２−２が実行する。
【００６８】
ステップＳ２０８〜ステップＳ２１１は、図７のステップＳ１０８〜ステップＳ１１１と同様の処理であるため説明を省略する。
【００６９】
（第２の実施形態）
第２の実施形態は、上記変形例のように認証設定を行う形態を、本体（本体部）と、アプリの動作プラットフォームとなる操作部と、で構成された電子機器に適用した例を説明する。図６などのようにログイン中のユーザで認証する形態に適用することもできる。
【００７０】
図１０は、第２の実施形態のＭＦＰ１０−３のハードウェア構成の例を示す図である。本体部４００は、コピー機能、スキャナ機能、ファクス機能、および、プリンタ機能等の各種の機能を実現する。操作部３００は、ユーザの操作に応じた情報（操作入力）を受け付ける。なお、ユーザの操作を受け付けるとは、ユーザの操作に応じて入力される情報（画面の座標値を示す信号等を含む）を受け付けることを含む概念である。
【００７１】
本体部４００および操作部３００は、接続Ｉ／Ｆ（インタフェース）４０６、専用の通信路３５０および接続Ｉ／Ｆ３０６を介して相互に通信可能に接続されている。通信路３５０は、例えばＵＳＢ（Universal  Serial  Bus）規格を用いることができるが、有線か無線かを問わず任意の規格のものでもよい。
【００７２】
本体部４００は、操作部３００で受け付けた操作に応じた動作を行う。また、本体部４００は、クライアント２０等の外部装置とも通信可能であり、外部装置から受信した指示（印刷指示等）に応じた動作を行うこともできる。
【００７３】
まず本体部４００のハードウェア構成について説明する。図１０に示すように、本体部４００は、ＣＰＵ４０１と、ＲＯＭ４０２と、ＲＡＭ４０３と、ＨＤＤ４０４と、通信Ｉ／Ｆ４０５と、接続Ｉ／Ｆ４０６と、エンジン４０７とを備える。ＣＰＵ４０１、ＲＯＭ４０２、ＲＡＭ４０３、ＨＤＤ４０４、通信Ｉ／Ｆ４０５、接続Ｉ／Ｆ４０６、および、エンジン４０７は、システムバス４０８を介して相互に接続されている。
【００７４】
ＣＰＵ４０１は本体部４００の動作を統括的に制御する。ＣＰＵ４０１はＲＡＭ４０３をワークエリア（作業領域）としてＲＯＭ４０２またはＨＤＤ４０４等に格納されたプログラムを実行することで、本体部４００全体の動作を制御し、上述したコピー機能、スキャナ機能、ファクス機能、プリンタ機能等の各種機能を実現する。
【００７５】
通信Ｉ／Ｆ４０５は、ネットワーク４０と接続するためのインタフェースである。接続Ｉ／Ｆ４０６は、通信路３５０を介して操作部３００と通信するためのインタフェースである。
【００７６】
エンジン４０７は、コピー機能、スキャナ機能、ファクス機能およびプリンタ機能を実現させるための、汎用的な情報処理および通信以外の処理を行うハードウェアである。例えば、エンジン４０７は、原稿の画像をスキャンして読み取るスキャナ（画像読取部）、用紙等のシート材への印刷を行うプロッタ（画像形成部）、ファクス通信を行うファクス部などを備えている。エンジン４０７は、さらに、印刷済みシート材を仕分けるフィニッシャや、原稿を自動給送するＡＤＦ（自動原稿給送装置）のような特定のオプションを実現するためのハードウェアを備えていてもよい。
【００７７】
次に操作部３００のハードウェア構成について説明する。図１０に示すように、操作部３００は、ＣＰＵ３０１と、ＲＯＭ３０２と、ＲＡＭ３０３と、フラッシュメモリ３０４と、通信Ｉ／Ｆ３０５と、接続Ｉ／Ｆ３０６と、操作パネル３０７と、外部接続Ｉ／Ｆ３０８と、を備える。ＣＰＵ３０１、ＲＯＭ３０２、ＲＡＭ３０３、フラッシュメモリ３０４、通信Ｉ／Ｆ３０５、接続Ｉ／Ｆ３０６、操作パネル３０７、および外部接続Ｉ／Ｆ３０８は、システムバス３０９を介して相互に接続されている。
【００７８】
ＣＰＵ３０１は、操作部３００の動作を統括的に制御する。ＣＰＵ３０１は、ＲＡＭ３０３をワークエリア（作業領域）としてＲＯＭ３０２またはフラッシュメモリ３０４等に格納されたプログラムを実行することで、操作部３００全体の動作を制御し、ユーザから受け付けた入力に応じた情報（画像）の表示などの各種機能を実現する。
【００７９】
通信Ｉ／Ｆ３０５は、ネットワーク４０と接続するためのインタフェースである。接続Ｉ／Ｆ３０６は、通信路３５０を介して本体部４００と通信するためのインタフェースである。
【００８０】
操作パネル３０７は、ユーザの操作に応じた各種の入力を受け付けるとともに、各種の情報（例えば受け付けた操作に応じた情報、ＭＦＰ１０−３の動作状況を示す情報、設定状態などを示す情報など）を表示する。この例では、操作パネル３０７は、タッチパネル機能を搭載した液晶表示装置（ＬＣＤ）で構成されるが、これに限られるものではない。例えばタッチパネル機能が搭載された有機ＥＬ表示装置で構成されてもよい。さらに、これに加えてまたはこれに代えて、ハードウェアキー等の操作部やランプ等の表示部を設けることもできる。
【００８１】
外部接続Ｉ／Ｆ３０８は、例えばＩＣカードリーダー等と接続するためのインタフェースである。
【００８２】
次に、ＭＦＰ１０−３のソフトウェア構成について説明する。図１１は、本実施形態のＭＦＰ１０−３のソフトウェア構成の例を示す図である。図１１に示すように、本体部４００は、アプリ層４１１、サービス層４１２およびＯＳ層４１３を有する。アプリ層４１１、サービス層４１２およびＯＳ層４１３の実体は、ＲＯＭ４０２やＨＤＤ４０４等（図１０参照）に格納されている各種ソフトウェアである。ＣＰＵ４０１が、これらのソフトウェアを実行することにより、各種の機能が提供される。
【００８３】
アプリ層４１１のソフトウェアは、ハードウェア資源を動作させて所定の機能を提供するためのアプリである。例えばアプリとしては、コピー機能を提供するためのコピーアプリ、スキャナ機能を提供するためのスキャナアプリ、ファクス機能を提供するためのファクスアプリ、および、プリンタ機能を提供するためのプリンタアプリなどが挙げられる。
【００８４】
サービス層４１２のソフトウェアは、アプリ層４１１とＯＳ層４１３との間に介在し、アプリに対し、本体部４００が備えるハードウェア資源を利用するためのインタフェースを提供するためのソフトウェアである。より具体的には、ハードウェア資源に対する動作要求の受付、動作要求の調停を行う機能を提供するためのソフトウェアである。サービス層４１２が受け付ける動作要求としては、スキャナによる読み取りやプロッタによる印刷等の要求が考えられる。
【００８５】
なおサービス層４１２によるインタフェースの機能は、本体部４００のアプリ層４１１だけではなく、操作部３００のアプリ層３１１に対しても提供される。すなわち操作部３００のアプリ層３１１（アプリ）も、サービス層４１２のインタフェース機能を介して、本体部４００のハードウェア資源（例えば図１０のエンジン４０７）を利用した機能を実現することができる。
【００８６】
ＯＳ層４１３のソフトウェアは、本体部４００が備えるハードウェアを制御する基本機能を提供するための基本ソフトウェア（オペレーティングシステム）である。サービス層４１２のソフトウェアは、各種アプリからのハードウェア資源の利用要求を、ＯＳ層４１３が解釈可能なコマンドに変換してＯＳ層４１３に渡す。そして、ＯＳ層４１３のソフトウェアによりコマンドが実行されることで、ハードウェア資源は、アプリの要求に従った動作を行う。
【００８７】
同様に、操作部３００は、アプリ層３１１、サービス層３１２およびＯＳ層３１３を有する。操作部３００が備えるアプリ層３１１、サービス層３１２およびＯＳ層３１３も、階層構造については本体部４００と同様である。ただしアプリ層３１１のアプリにより提供される機能や、サービス層３１２が受け付け可能な動作要求の種類は、本体部４００とは異なる。アプリ層３１１のアプリは、操作部３００が備えるハードウェア資源を動作させて所定の機能を提供するためのソフトウェアであってもよいが、主として本体部４００が備える機能（コピー機能、スキャナ機能、ファクス機能およびプリンタ機能）に関する操作や表示を行うためのＵＩ（ユーザインタフェース）の機能を提供するためのソフトウェアである。
【００８８】
なお本実施形態では、機能の独立性を保つために、本体部４００のＯＳ層４１３のソフトウェアと、操作部３００のＯＳ層３１３のソフトウェアが互いに異なる。つまり本体部４００と操作部３００は、別々のオペレーティングシステムで互いに独立して動作する。例えば、本体部４００のＯＳ層４１３のソフトウェアとしてＬｉｎｕｘ（登録商標）を用い、操作部３００のＯＳ層３１３のソフトウェアとしてＡｎｄｒｏｉｄ（登録商標）を用いることが可能である。
【００８９】
以上のように、ＭＦＰ１０−３において、本体部４００と操作部３００は別々のオペレーティングシステムで動作するため、本体部４００と操作部３００との間の通信は、共通の装置内のプロセス間通信ではなく、異なる装置間の通信として行われる。異なる装置間の通信の例は、操作部３００が受け付けた情報（ユーザからの指示内容）を本体部４００へ伝達する動作（コマンド通信）や、本体部４００が操作部３００へイベントを通知する動作等である。ここでは操作部３００が本体部４００へコマンド通信を行うことにより、本体部４００の機能を使用することができる。また本体部４００から操作部３００に通知するイベントには、本体部４００における動作の実行状況、本体部４００で設定された情報等が挙げられる。
【００９０】
また実施形態では、操作部３００への電力供給は、本体部４００から通信路３５０を経由して行われているが、操作部３００の電源制御を、本体部４００の電源制御とは別に（独立して）行ってもよい。
【００９１】
また上述の実施形態では、本体部４００と操作部３００は、別々のオペレーティングシステムで互いに独立して動作しているが、これに限らず、例えば本体部４００と操作部３００が同じオペレーティングシステムで動作する形態であってもよい。また、本体部４００と操作部３００とが一体に構成されていてもよい。例えば、本体部４００と操作部３００のハードウェア構成は、図１０のように分離されている必要はなく、１つのハードウェア構成上で本体部４００と操作部３００の機能が実現されていてもよい。
【００９２】
次にＭＦＰ１０−３の機能構成について説明する。図１２は、本実施形態にかかるＭＦＰ１０−３の機能構成の一例を示すブロック図である。図１２では、図４と同様の機能については同一の符号を付し、説明を省略する。
【００９３】
図１２に示すように、ＭＦＰ１０−３の操作部３００は、Ｗｅｂアプリサービス１１−３と、組み込みブラウザ２１と、組み込みアプリ２２と、ＳＤＫアプリ２３と、操作部システム４１と、を備えている。またＭＦＰ１０−３の本体部４００は、外部接続部５４と、要求管理部５５と、電源制御部５６と、記憶部２４と、内部ＡＰＩ３２と、本体機能３３と、を備えている。Ｗｅｂアプリサービス１１−３は、Ｗｅｂアプリ１２−２ａ、１２−２ｂと、Ｗｅｂアプリ管理部１３−３と、を備えている。
【００９４】
Ｗｅｂアプリ管理部１３−３は、Ｗｅｂアプリ１２−２のインストール、アンインストール、および、情報取得などの管理を行う。本実施形態のＷｅｂアプリ管理部１３−３は、図５の認証制御部５２および要求制御部５３に相当する機能を備える必要がない。後述するように、これらの機能は本体部４００の要求管理部５５が備える。
【００９５】
操作部システム４１は、操作部３００の基盤となるシステムであり、例えば図１１のＯＳ層３１３およびサービス層３１２に相当する。
【００９６】
外部接続部５４は、本体部４００のネットワーク処理（物理層〜トランスポート層）を行う。例えば外部接続部５４は、クライアント２０からの要求を受付け（受信部）、受け付けた要求を要求管理部５５に渡す。また外部接続部５４は、要求管理部５５から応答を受け取り、クライアント２０に返す。外部接続部５４は、本体部４００のシステム停止状態でクライアント２０からの要求を受けた場合、要求をトリガーとして本体部４００を通電させる。
【００９７】
要求管理部５５は、クライアント２０などの外部装置からの要求を管理する。例えば要求管理部５５は、リクエスト（ＨＴＴＰリクエストなど）を受付け、条件に応じて適切な宛先（Ｗｅｂアプリ１２−２など）に要求を再送する（リバースプロキシ）。要求管理部５５は、認証・認可機能、暗号機能、負荷分散、キャッシュ、コンテンツの圧縮、および、速度調整等を行ってもよい。
【００９８】
要求管理部５５は、認証制御部５２と、要求制御部５３と、を備える。認証制御部５２および要求制御部５３の機能は、図５と同様であるため説明を省略する。電源制御部５６は、操作部３００および記憶部２４などへの電力の供給を制御する。
【００９９】
なお外部接続部５４、要求管理部５５、および、電源制御部５６は、例えば図１１のサービス層４１２またはＯＳ層４１３の機能として実現できる。また、電源制御部５６により電源を制御する機能は備えなくてもよい。
【０１００】
次に、このように構成された本実施形態のＭＦＰ１０−３によるアクセス制御処理について説明する。図１３は、本実施形態でのアクセス制御処理の一例を示すシーケンス図である。
【０１０１】
まず、Ｗｅｂアプリ１２−２は、自身の認証方式を、Ｗｅｂアプリ管理部１３−３を介して要求管理部５５に通知し認証設定を行う（ステップＳ３０１、ステップＳ３０２）。要求管理部５５は、通知された認証方式を例えば記憶部２４に記憶する（ステップＳ３０３）。ここでは、Ｗｅｂアプリ１２−２の認証方式が、ログイン中のユーザで認証する方式であるものとして説明する。そして、あるユーザ（ユーザＡとする）がＭＦＰ１０−３にログインしたものとする。この場合、認証部３４は、ユーザＡのＭＦＰ１０−３のログインを認証する（ステップＳ３０４）。
【０１０２】
この後、クライアント２０が、ＭＦＰ１０−３に対して、Ｗｅｂアプリ１２−２にアクセスするリクエストを送信する（ステップＳ３０５）。ＭＦＰ１０−３の外部接続部５４は、リクエストを受信し、受信したリクエストを要求管理部５５に送信する（ステップＳ３０６）。
【０１０３】
要求管理部５５は、本体部４００の電源モードのロックを電源制御部５６に依頼する（ステップＳ３０７）。電源制御部５６は、ロックが正常に完了したら、完了したことを示す情報（受付ＯＫ）を要求管理部５５に送信する（ステップＳ３０８）。これにより、本体部４００の電源断およびシステム関連の操作が禁止される。要求管理部５５は、電源制御部５６に電源モードロックを実行させてもよい。また要求管理部５５は、システムを管理する別のモジュールにシステムモードロックを実行させてもよい。
【０１０４】
要求管理部５５は、要求の内容（ＵＲＬなど）を確認し、アクセス先がＷｅｂアプリ１２−２であるかを判断する（ステップＳ３０９）。要求管理部５５は、リクエストを受けたＷｅｂアプリ１２−２に対応する認証方式を記憶部２４から取得する（ステップＳ３１０、ステップＳ３１１）。
【０１０５】
Ｗｅｂアプリ１２−２の認証方式が、ログイン中のユーザで認証する方式である場合、要求管理部５５は、例えば内部ＡＰＩ３２を用いて、認証部３４にユーザのログイン状態の取得を要求する（ステップＳ３１２）。認証部３４は、ログイン状態を要求管理部５５に送信する（ステップＳ３１３）。
【０１０６】
あるユーザがログイン中であった場合、要求管理部５５は、未認証である旨の通知を、外部接続部５４を介してクライアント２０に送信する（ステップＳ３１４、ステップＳ３１５）。この通知に、ログイン中のユーザを識別する識別情報を含めてもよい。
【０１０７】
クライアント２０は、通知に含まれる識別情報などで特定されるユーザの認証情報を含むリクエストを、外部接続部５４を介して要求管理部５５に送信する（ステップＳ３１６、ステップＳ３１７）。このユーザが、Ｗｅｂアプリ１２−２へアクセスするアクセスユーザに相当する。要求管理部５５（認証制御部５２）は、リクエストに含まれる認証情報による認証処理を認証部３４に要求する（ステップＳ３１８）。認証部３４は、要求に応じて認証処理を実行し、認証結果を送信する（ステップＳ３１９）。
【０１０８】
この後、Ｗｅｂアプリ１２−２にアクセスするために、以下のステップＳ３２０〜ステップＳ３３１までの処理が実行される。要求管理部５５は、リクエストをＷｅｂアプリ１２−２にリダイレクトする。このとき、操作部３００が電源オフの状態であれば、以下のステップＳ３２０〜ステップＳ３２５までの処理が実行される。
【０１０９】
要求管理部５５は、電源制御部５６に電源操作（操作部３００の通電）の指示を送る（ステップＳ３２０）。電源制御部５６は、操作部３００を通電した場合は通電したことを示す情報（受付ＯＫ）を返す（ステップＳ３２１）。ハードウェア異常など、何らかの理由で受付できない場合は、電源制御部５６は、受付できなかったことを示す情報（受付ＮＧ）を返す。受付ＮＧの場合、要求管理部５５は、一定回数のリトライを行ってもよい。一定回数のリトライ後も通電できなかった場合は、要求管理部５５は、システムエラーを示すステータスコードおよびメッセージなどをクライアント２０に返す。
【０１１０】
電源制御部５６は、操作部システム４１に通電処理を指示する（ステップＳ３２２）。操作部システム４１は、Ｗｅｂアプリ管理部１３−３を介してＷｅｂアプリ１２−２を再開させる（ステップＳ３２３、ステップＳ３２４）。操作部システム４１は、操作部３００が接続可能である旨の通知（接続可能通知）を要求管理部５５に送信する（ステップＳ３２５）。要求管理部５５は、操作部システム４１から接続可能通知を受信する。要求管理部５５は、電源操作に対する受付ＯＫを受けてから一定時間、待機する。一定時間内に接続可能通知が受信できない場合は、エラーが発生した旨を示すステータスコードおよびメッセージなどをクライアント２０に返す。
【０１１１】
要求管理部５５は、操作部３００の電源モードのロックを電源制御部５６に依頼する（ステップＳ３２６）。電源制御部５６は、ロックが正常に完了したら、完了したことを示す情報（受付ＯＫ）を要求管理部５５に送信する（ステップＳ３２７）。
【０１１２】
要求管理部５５（要求制御部５３）は、Ｗｅｂアプリ１２−２に対して、リクエストを送信（リダイレクト）する（ステップＳ３２８）。本体部４００と操作部３００は、内部ネットワーク（通信路３５０）により接続されている。リダイレクトの際、要求管理部５５（要求制御部５３）は、外部接続部５４のネットワーク情報（ＩＰアドレス、サブネットなど）も合わせてＷｅｂアプリ１２−２に通知する。Ｗｅｂアプリ１２−２が、Ｗｅｂページのリンク等を作る際に、クライアント２０から接続可能なネットワーク情報が必要となるためである。
【０１１３】
Ｗｅｂアプリ１２−２は、リクエストを処理し（ステップＳ３２９）、応答（ＨＴＴＰレスポンスなど）を要求管理部５５に返す（ステップＳ３３０）。要求管理部５５は、応答情報（例えばＨＴＴＰのステータスコード「２００  ＯＫ」）を設定する（ステップＳ３３１）。
【０１１４】
要求管理部５５は、操作部３００の電源モードのロックを解除することを電源制御部５６に依頼する（ステップＳ３３２）。電源制御部５６は、ロック解除が正常に完了したら、完了したことを示す情報（受付ＯＫ）を要求管理部５５に送信する（ステップＳ３３３）。要求管理部５５は、本体部４００の電源モードのロックを解除することを電源制御部５６に依頼する（ステップＳ３３４）。電源制御部５６は、ロック解除が正常に完了したら、完了したことを示す情報（受付ＯＫ）を要求管理部５５に送信する（ステップＳ３３５）。
【０１１５】
要求管理部５５は、外部接続部５４を介して、クライアント２０に応答を返す（ステップＳ３３６、ステップＳ３３７）。要求管理部５５は、応答に認証チケットを含めてもよい。クライアント２０は、これ以降、Ｗｅｂアプリ１２−２へのリクエストを送信するときに当該認証チケットを使用することができる。
【０１１６】
この後、例えばユーザＡがログオフし、他のユーザがログインしたとする。この場合、認証部３４は、ユーザＢのＭＦＰ１０−３のログインを認証する（ステップＳ３３８）。このように他のユーザがログインした場合は、ステップＳ３３７で送信された認証チケットは無効となる。クライアント２０は、これ以降もＷｅｂアプリ１２−２にアクセスする場合は、ユーザＢでの認証が必要となる。
【０１１７】
本実施形態では、操作部３００と本体部４００の電源を独立に制御できる。このため、要求管理部５５（認証制御部５２）が認証処理を行った結果、ユーザが認証されなかった場合、操作部３００を通電する必要がなくなり、ネットワークトラフィックも減る。
【０１１８】
上記実施形態にかかる電子機器（ＭＦＰ）で実行されるプログラムは、ＲＯＭ１０２等に予め組み込まれて提供される。
【０１１９】
上記実施形態にかかる電子機器で実行されるプログラムは、インストール可能な形式又は実行可能な形式のファイルでＣＤ−ＲＯＭ（Compact  Disk  Read  Only  Memory）、フレキシブルディスク（ＦＤ）、ＣＤ−Ｒ（Compact  Disk  Recordable）、ＤＶＤ（Digital  Versatile  Disk）等のコンピュータで読み取り可能な記録媒体に記録してコンピュータプログラムプロダクトとして提供されるように構成してもよい。
【０１２０】
さらに、上記実施形態にかかる電子機器で実行されるプログラムを、インターネット等のネットワークに接続されたコンピュータ上に格納し、ネットワーク経由でダウンロードさせることにより提供するように構成してもよい。また、上記実施形態にかかる電子機器で実行されるプログラムをインターネット等のネットワーク経由で提供または配布するように構成してもよい。
【０１２１】
上記実施形態にかかる電子機器で実行されるプログラムは、コンピュータを上述した電子機器の各部として機能させうる。このコンピュータは、ＣＰＵ１０１がコンピュータ読取可能な記憶媒体からプログラムを主記憶装置上に読み出して実行することができる。
【符号の説明】
【０１２２】
１０  ＭＦＰ
１１  Ｗｅｂアプリサービス
１２ａ、１２ｂ  Ｗｅｂアプリ
１３  Ｗｅｂアプリ管理部
２０  クライアント
２１  組み込みブラウザ
２２  組み込みアプリ
２３  ＳＤＫアプリ
２４  記憶部
３０  サーバ
３１  リモートＡＰＩ
３２  内部ＡＰＩ
３３  本体機能
３４  認証部
４０  ネットワーク
４１  操作部システム
５１  受信部
５２  認証制御部
５３  要求制御部
５４  外部接続部
５５  要求管理部
５６  電源制御部
【先行技術文献】
【特許文献】
【０１２３】
【特許文献１】特開２００６−０９４３７７号公報
【図１】
2017049838.tif 000003
【図２】
2017049838.tif 000004
【図３】
2017049838.tif 000005
【図４】
2017049838.tif 000006
【図５】
2017049838.tif 000007
【図６】
2017049838.tif 000008
【図７】
2017049838.tif 000009
【図８】
2017049838.tif 000010
【図９】
2017049838.tif 000011
【図１０】
2017049838.tif 000012
【図１１】
2017049838.tif 000013
【図１２】
2017049838.tif 000014
【図１３】
2017049838.tif 000015