(57)【要約】【課題】  Ｗｅｂブラウザの使用ライセンスがない場合は、リソースサービスと連携する際のブラウザ表示は、表示項目を制限してリソースサービスとの連携に不要なブラウザ機能を使用できないようにする。【解決手段】  Ｗｅｂブラウザと、ネットワーク上のリソースサーバが提供するリソースサービスと連携するアプリケーションを有する画像形成装置とその制御方法であって、ローカルログインしたユーザによる前記Ｗｅｂブラウザの起動に応じて、リソースサービスとの連携を指示する指示部を含む画面を表示し、ユーザのＷｅｂブラウザの使用ライセンスの有効／無効と、リソースサービスとの連携の有効／無効を判定し、その判定されたＷｅｂブラウザの使用ライセンスの有効／無効、及びリソースサービスとの連携の有効／無効に応じて、表示項目を制限した画面を表示する。【選択図】  図１３
2015075902.tif 000002
【特許請求の範囲】
【請求項１】
Ｗｅｂブラウザと、ネットワークを介してリソースサーバが提供するリソースサービスと連携するアプリケーションを有する画像形成装置であって、
ローカルログインしたユーザによる前記Ｗｅｂブラウザの起動に応じて、リソースサービスとの連携を指示する指示部を含む画面を表示する表示手段と、
前記ユーザの前記Ｗｅｂブラウザの使用ライセンスの有効／無効と、前記リソースサービスとの連携の有効／無効を判定する判定手段と、
前記判定手段により判定された前記Ｗｅｂブラウザの使用ライセンスの有効／無効、及び前記リソースサービスとの連携の有効／無効に応じて、表示項目を制限した画面を表示する表示制御手段と、
を有することを特徴とする画像形成装置。
【請求項２】
前記画面は、前記画像形成装置が前記リソースサーバにアクセスするための認可設定の開始を指示する画面であることを特徴とする請求項１に記載の画像形成装置。
【請求項３】
前記指示部に関連付けて、前記Ｗｅｂブラウザの使用ライセンスの有効／無効と、前記リソースサービスとの連携の有効／無効、及び認可サーバのＵＲＬを記憶する記憶手段を更に有することを特徴とする請求項１又は２に記載の画像形成装置。
【請求項４】
前記指示部は、画面に表示されるＷｅｂブラウザショートカットであることを特徴とする請求項１乃至３のいずれか１項に記載の画像形成装置。
【請求項５】
前記Ｗｅｂブラウザの使用ライセンスの有効／無効と、前記リソースサービスとの連携の有効／無効とに対応して、画面の表示を制限する表示項目のリストを記憶する項目制限記憶手段を更に有することを特徴とする請求項１乃至４のいずれか１項に記載の画像形成装置。
【請求項６】
前記表示制御手段は、前記判定手段が、前記Ｗｅｂブラウザの使用ライセンスが無効で、かつ、前記リソースサービスとの連携が有効と判定した場合、前記Ｗｅｂブラウザの使用ライセンスが無効の場合に実施できない機能に関連した表示項目を制限し、
前記判定手段が、前記Ｗｅｂブラウザの使用ライセンスが有効で、かつ、前記リソースサービスとの連携が有効と判定した場合、前記リソースサービスのＵＲＬの表示を制限することを特徴とする請求項１乃至５のいずれか１項に画像形成装置。
【請求項７】
前記リソースサービスと連携するアプリケーションが追加されると、当該追加したアプリケーションの起動時に前記Ｗｅｂブラウザショートカットを含む情報の登録を行う登録手段を更に有することを特徴とする請求項４に記載の画像形成装置。
【請求項８】
前記項目制限記憶手段は、前記リソースサーバに設けられていることを特徴とする請求項５に記載の画像形成装置。
【請求項９】
前記判定手段は、前記表示手段に表示された前記指示部への前記ユーザの指示に応じて判定することを特徴とする請求項１乃至８のいずれか１項に記載の画像形成装置。
【請求項１０】
Ｗｅｂブラウザと、ネットワークを介してリソースサーバが提供するリソースサービスと連携するアプリケーションを有する画像形成装置を制御する制御方法であって、
ローカルログインしたユーザによる前記Ｗｅｂブラウザの起動に応じて、リソースサービスとの連携を指示する指示部を含む画面を表示する表示工程と、
前記ユーザの前記Ｗｅｂブラウザの使用ライセンスの有効／無効と、前記リソースサービスとの連携の有効／無効を判定する判定工程と、
前記判定工程で判定された前記Ｗｅｂブラウザの使用ライセンスの有効／無効、及び前記リソースサービスとの連携の有効／無効に応じて、表示項目を制限した画面を表示する表示制御工程と、
を有することを特徴とする画像形成装置の制御方法。
【請求項１１】
コンピュータを、請求項１乃至９のいずれか１項に画像形成装置として機能させるためのプログラム。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、画像形成装置、その制御方法とプログラムに関するものである。
【背景技術】
【０００２】
近年、プリント機能、スキャナ機能、ＦＡＸ機能、文書保管機能等、様々な機能を備えた画像形成装置がネットワーク上のＷｅｂサーバと接続されて、ＰＤＦ形式の電子文書を作成するサービスや電子文書を蓄積するサービス等を提供している。このようなサービスを利用することでユーザは、自身が所有する端末自体にＰＤＦ作成機能がない場合でもＰＤＦを作成できるようになる他、端末の記憶容量以上に電子文書を保管できるようにもなる。
【０００３】
また近年、クラウドが一般化するに伴い、前述のような複数のサービスを連携させて付加価値を創造する機会がますます増加している。このようにサービスを連携させることでサービス提供者はユーザに付加価値を提供することができる。例えば作成したＰＤＦ形式の電子文書を、ユーザが所有する端末を経由することなく、直接インターネット上で保管できるようにもなる。その一方で、サービスが連携することにより、いくつかの課題が生まれる。例えば、ユーザが望んだ以上の情報がサービス間で交換されるので、ユーザデータや個人情報が漏えいするというリスクがある。インターネット上には複数のサービスが存在し、様々なサービス間でサービス連携が実現されるが、ユーザが望む結果を提供するサービス以外のサービスがユーザデータ、個人情報等を取得することは望ましくない。一方で、サービスの提供者からすると、サービス連携の仕組みは容易に実装できるものが好ましい。
【０００４】
このような状況において、ＯＡｕｔｈと呼ばれる、認可の連携を実現させるための標準プロトコルが策定されている。ＯＡｕｔｈについては以降でさらに詳細に説明する。このＯＡｕｔｈによれば、例えばあるサービスＡが管理するユーザのデータに、そのユーザから認められた外部サービスＢがアクセスすることができる。このときサービスＡは、外部サービスＢからアクセスされる範囲を明らかにした上で、外部サービスＢによるアクセスに対してユーザの明示的な認可を得ることになっている。ここで、ユーザが明示的に認可を行うことを認可操作と称する。ユーザが認可操作を行うと、外部サービスＢはサービスＡからアクセスを認められたことを証明するトークン（以下、認可トークン）を受け取り、以降のアクセスはその認可トークンを用いて実現できる。この認可トークンを用いると外部サービスＢは、ユーザの認証情報なしに、認可を行ったユーザの権限でサービスＡにアクセスできる。そのため、ユーザから認可を受け認可トークンを取得した外部サービスＢは、その認可トークンを厳重かつ適正に管理する責務を負う。これにより、ユーザの個人情報の漏洩リスクを回避しながら、ユーザが望むサービスを利用した連携結果をサービス提供者が容易に提供することが可能となっている。
【０００５】
いま画像形成装置がＯＡｕｔｈクライアントとなってクラウドサービスと連携する場合、ユーザが画像形成装置にクラウドサービスのリソースへのアクセスを権限を移譲することで、画像形成装置はクラウドサービスと連携できるようになる。画像処理装置は複数ユーザで共有可能なため、複数のユーザの管理を行うことが一般的である。従って、画像形成装置に権限を移譲したユーザのクラウドサービスのリソースに、画像処理装置の全てのユーザがアクセス可能となるのは好ましくなく、クラウドサービスのユーザと画像形成装置のユーザの連携が必要となる。クラウドサービスのユーザと画像形成装置のユーザとを連携するためには、画像形成装置のユーザに認可トークンを紐付けて保持する。そして、画像形成装置へログインしたユーザに紐付いた認可トークンを利用してクラウドサービスにアクセスすることで、クラウドサービスのユーザの認可を行ったユーザの権限の範囲で、連携するクラウドサービスへのアクセスが可能となる。
【０００６】
ここで画像形成装置のユーザに認可トークンを紐付けるために、画像形成装置にログインした状態でＷｅｂブラウザを用いてユーザが権限を移譲する必要がある。このときユーザは、認可トークンを紐づけるためのプロバイダとなるアプリケーションにアクセスするためのアドレス（ＵＲＬ）をＷｅｂブラウザのアドレス指定領域に手入力する。プロバイダとなるアプリケーションは、認可トークンを発行するための認証をクラウドサービス（認証サービス）に依頼（リダイレクト）し、ユーザはＷｅｂブラウザ上で認証を行う。こうしてユーザがＷｅｂブラウザ上で認証を完了すると、認証サービスが発行した認可トークンをそのプロバイダが取得し、それをユーザと紐づけて画像形成装置に保持する。これにより、画像形成装置のユーザに紐づけてクラウドサービスのユーザの権限を委譲することができる。
【０００７】
ここでユーザの権限の移譲時に求められるＷｅｂブラウザの機能は、通常の使用時に求められる機能と異なる。そのため、ユーザの権限の移譲時には、Ｗｅｂブラウザの一部機能の使用を制限することになる。Ｗｅｂブラウザの機能を制限する方法としては、例えば特許文献１により提案されている。この特許文献１では、操作指示の制限内容を設定し、設定された制限内容に対応するツール部分のユーザによる選択を不可状態にすることで、Ｗｅｂブラウザの一部機能の使用を制限している。
【先行技術文献】
【特許文献】
【０００８】
【特許文献１】特開２００６−１５５５２２号公報
【非特許文献】
【０００９】
【非特許文献１】"The OAuth 1.0 Protocol"、[online] E. Hammer-Lahav、2012年9月 ＜URL http://tools.ietf.org/html/rfc5849＞
【非特許文献２】"The ＯＡｕｔｈ 2.0 Authorization FＲＡＭework draft-ietf-OAuth-v2-31"、[online] D. Hardt.、2012年9月 ＜URL http://tools.ietf.org/html/draft-ietf-OAuth-v2-31＞
【発明の概要】
【発明が解決しようとする課題】
【００１０】
Ｗｅｂブラウザは、外部サイトにアクセスして閲覧するためのクライアントアプリケーションであり、画像形成装置上に予め配置されている。通常、Ｗｅｂブラウザを使用する際、ユーザはＷｅｂブラウザの使用ライセンスを購入して画像形成装置にインストールする必要がある。Ｗｅｂブラウザが画像形成装置上に配置されていても、ライセンスがインストールされていなければ、ユーザはＷｅｂブラウザを起動できない。
【００１１】
一方、前述したように画像形成装置をＯＡｕｔｈクライアントとしてクラウドサービスと連携するためには、ユーザはＷｅｂブラウザを操作して認証を行いユーザの権限を移譲する必要がある。ここでもＷｅｂブラウザのライセンスがインストールされていなければＷｅｂブラウザは使用できない。
【００１２】
一方で、クラウドサービスと連携することを目的としてＷｅｂブラウザを使用する場合には、Ｗｅｂブラウザの使用ライセンスがインストールされていなくてもＷｅｂブラウザの使用を許可したい。また、Ｗｅｂブラウザの使用ライセンスがインストールされていない場合に、Ｗｅｂブラウザの使用を許可してしまうと、使用ライセンスを購入したユーザとの間で不公平が生じてしまう。
【００１３】
本発明の目的は、上記従来技術の問題点を解決することにある。
【００１４】
本発明の特徴は、Ｗｅｂブラウザの使用ライセンスがないユーザでも連携を指示でき、Ｗｅｂブラウザの使用ライセンスがないユーザとの間で不公平を生じさせることなくＷｅｂブラウザを使用してリソースサービスと連携する技術を提供することにある。
【課題を解決するための手段】
【００１５】
上記目的を達成するために本発明の一態様に係る画像形成装置は以下のような構成を備える。即ち、
Ｗｅｂブラウザと、ネットワーク上のリソースサーバが提供するリソースサービスと連携するアプリケーションを有する画像形成装置であって、
ローカルログインしたユーザによる前記Ｗｅｂブラウザの起動に応じて、リソースサービスとの連携を指示する指示部を含むブラウザ画面を表示する表示手段と、
前記ユーザの前記Ｗｅｂブラウザの使用ライセンスの有効／無効と、前記リソースサービスとの連携の有効／無効を判定する判定手段と、
前記判定手段により判定された前記Ｗｅｂブラウザの使用ライセンスの有効／無効、及び前記リソースサービスとの連携の有効／無効に応じて、表示項目を制限した画面を表示する表示制御手段と、を有することを特徴とする。
【発明の効果】
【００１６】
本発明によれば、通常のＷｅｂブラウザの使用ライセンスが無効でかつ、クラウドサービスとの連携がされている場合に、表示項目を制限した画面を表示する。これにより、Ｗｅｂブラウザの使用ライセンスがあるユーザとの間で不公平を生じさせることなくＷｅｂブラウザを使用してリソースサービスとの連携を指示できる。
【図面の簡単な説明】
【００１７】
【図１】本実施形態１に係る通信システムの構成を示す図。
【図２】本実施形態１に係る認可サーバと画像形成装置のハードウェア構成を示すブロック図。
【図３】本実施形態１に係る認可サーバ、リソースサーバ、画像形成装置それぞれのソフトウェアモジュールの構成を示す図
【図４】実施形態１に係る認可サーバが外部メモリに記憶するデータテーブルを説明する図。
【図５】実施形態１に係る画像形成装置が外部メモリに記憶するデータテーブルを説明する図。
【図６】実施形態１における表示項目制限リストの一例を示す図。
【図７】リソースサービス連携がされていない、又は、リソースサービス連携ブラウザ表示ではない通常Ｗｅｂブラウザにより表示される画面の一例を示す図。
【図８】使用ライセンスがインストールされていて、リソースサービス連携ブラウザ表示であるＷｅｂブラウザにより表示される画面の一例を示す図。
【図９】Ｗｅｂブラウザの使用ライセンスが未インストールで、リソースサービス連携ブラウザ表示であるＷｅｂブラウザにより表示される画面の一例を示す図。
【図１０】実施形態１に係る認可サーバ連携クライアントの起動時のクライアント情報の登録や更新及びＷｅｂブラウザショートカットの登録処理を説明するフローチャート。
【図１１】実施形態１に係る画像形成装置による親トークンの取得シーケンスを説明する図。
【図１２】実施形態１に係る画像形成装置のＷｅｂブラウザで表示される、ユーザを認証するためにログイン画面の一例を示す図（Ａ）と、実施形態１に係る画像形成装置のＷｅｂブラウザにより表示される認可確認画面の一例を示す図（Ｂ）。
【図１３】実施形態１に係る画像形成装置のＷｅｂブラウザが画面を表示する際に図６の表示項目制限に従って表示項目を決定する処理を説明するフローチャート。
【図１４】本発明の実施形態２に係るＷｅｂブラウザショートカットテーブルの一例を示す図。
【図１５】実施形態２に係る画像形成装置が表示項目制限リストを取得する処理を説明するフローチャート。
【発明を実施するための形態】
【００１８】
以下、添付図面を参照して本発明の実施形態を詳しく説明する。尚、以下の実施形態は特許請求の範囲に係る本発明を限定するものでなく、また本実施形態で説明されている特徴の組み合わせの全てが本発明の解決手段に必須のものとは限らない。
【００１９】
本実施形態では、インターネット上で帳票データを生成する帳票サービスと、インターネット上のデータを取得して印刷する印刷サービスとが、インターネット上のサーバに設置されていることを想定している。以降、帳票サービスや印刷サービスのように、インターネット上で機能を提供しているサービスを「リソースサービス」と呼ぶ。
【００２０】
また本実施形態では、画像形成装置にインストールされた印刷アプリケーション及び帳票アプリケーションがリソースサービスを利用することを想定している。以降、印刷アプリケーションや帳票アプリケーションのように、リソースサービスを利用するアプリケーションを「連携アプリケーション」と呼ぶ。無論、リソースサービスは帳票サービス、印刷サービスには限られず、連携アプリケーションも帳票アプリケーション、印刷アプリケーションに限られるものではない。
【００２１】
更に、実施形態における権限の移譲ではＯＡｕｔｈの仕組みを利用する。ＯＡｕｔｈでは、ユーザから移譲された権限を証明するための情報として、トークンと呼ばれる情報を利用する。
【００２２】
ユーザは、印刷アプリケーションからリソースサービスを利用する場合は印刷アプリケーションに、帳票アプリケーションからリソースサービスを利用する場合は帳票アプリケーションに、それぞれ個別に認可を与える必要がある。ユーザの立場で考えると、同一の画像形成装置からリソースサービスを利用する場合には、例えば、一度の認可操作でそれぞれの連携アプリケーションでリソースサービスを利用できるようになった方が利便性が高い。
【００２３】
そこで本実施形態では、ユーザの権限を画像形成装置のようなデバイス機器に移譲する。そして、連携アプリケーションに権限を移譲させる際、ユーザに代わって画像形成装置が連携アプリケーションに権限を移譲することにより、ユーザの認可操作の回数を低減させる。即ち、ユーザは画像形成装置に権限を移譲した段階で、連携アプリケーションにも権限を移譲することを認めたこととする。ユーザが画像形成装置に対して権限を移譲した場合のトークンを「親トークン」と称する。
【００２４】
ユーザの認可操作を一度で済ませる手法として、画像形成装置が取得した親トークンを、画像形成装置の連携アプリケーションで共有する方法が考えられる。しかしながら、この方法では、親トークンを共有する全ての連携アプリケーションが全てのリソースサービスにアクセス可能となってしまい好ましくない。これは、連携アプリケーションが共有された親トークンを用いてリソースサービスにアクセスした場合、リソースサービス側でアクセス元の連携アプリケーションが特定できず、利用の可否を判断することができないためである。そこで、本実施形態では、個々の連携アプリケーションは、親トークンを直接使うのでなく、親トークンに移譲された情報を継承しつつ、連携アプリケーション毎に再移譲して発行されるトークン用いる。ここで、親トークンを連携アプリケーション毎に再移譲して発行されたトークンを「子トークン」と称する。
【００２５】
図１は、本実施形態１に係る通信システムの構成を示す図である。
【００２６】
ＷＡＮ１００はWide Area Networkであり、本実施形態１ではWorld Wide Web（WWW）システムが構築されている。ＬＡＮ１０１は、各構成要素を接続するローカルエリアネットワークである。認可サーバ２００は、ＯＡｕｔｈを実現するための認可サーバであり、認可サービスモジュールを有している。リソースサーバ２１０は、印刷サービスや帳票サービスといったリソースサービスを有している。尚、１台のリソースサーバに設置されるリソースサービスは１つでもよく複数でもよい。画像形成装置３００は例えば印刷や画像の読み取り等が可能な複合機で、１つ又は複数の連携アプリケーションをインストールしている。更に、新たな連携アプリケーションをインストールして追加することもできる。ユーザは画像形成装置３００の連携アプリケーションを用いてリソースサービスを利用できる。また認可サーバ２００、リソースサービス２１０、画像形成装置３００はそれぞれＷＡＮ１００及びＬＡＮ１０１を介して接続されている。尚、認可サーバ２００、リソースサービス２１０、画像形成装置３００はそれぞれ個別のＬＡＮ上に設けられていてもよく、同一のＬＡＮ上に設けられていてもよい。また認可サーバ２００、リソースサービス２１０は同一のサーバ上に構成されていてもよい。
【００２７】
図２は、本実施形態１に係る認可サーバ２００と画像形成装置３００のハードウェア構成を示すブロック図である。ここで認可サーバ２００と画像形成装置３００とは、ＷＡＮ１００及びＬＡＮ１０１を介して通信可能に接続されている。
【００２８】
まず、認可サーバ２００の構成について説明する。尚、図２に示されるハードウェアブロック図は一般的な情報処理装置のハードウェアブロック図に相当するものとし、本実施形態１の認可サーバ２００には一般的な情報処理装置のハードウェア構成を適用できる。また認可サーバ２００だけでなく、リソースサーバ２１０についても同様である。
【００２９】
ＣＰＵ２０１は、ＲＯＭ２０３のプログラムＲＯＭに記憶された、或いはハードディスク（ＨＤ）等の外部メモリ２１１からＲＡＭ２０２にロードされたＯＳやアプリケーション等のプログラムを実行する。そして、システムバス２０４に接続された各ブロックを制御する。ここでＯＳとはコンピュータ上で稼動するオペレーティングシステムの略語であり、以下オペレーティングシステムのことをＯＳと呼ぶ。後述する各シーケンスの処理はこのプログラムの実行により実現できる。ＲＡＭ２０２は、ＣＰＵ２０１の主メモリ、ワークエリア等として機能する。キーボードコントローラ（ＫＢＣ）２０５は、キーボード２０９や不図示のポインティングデバイスからのキー入力を制御する。表示制御部２０６は、表示部２１０への表示を制御する。ディスクコントローラ（ＤＫＣ）２０７は各種データを記憶するハードディスク等の外部メモリ２１１へのアクセスを制御する。ネットワークコントローラ（ＮＣ）２０８は、ＷＡＮ１００もしくはＬＡＮ１０１を介して接続された画像形成装置３００や他の機器との通信制御処理を実行する。
【００３０】
尚、後述の全ての説明においては、特に断りのない限りサーバにおける実行のハード上の主体はＣＰＵ２０１であり、ソフトウェア上の主体は外部メモリ２１１にインストールされたアプリケーションプログラムである。
【００３１】
次に、画像形成装置３００の構成について説明する。
【００３２】
ＣＰＵ３０１は、ＲＯＭ３０２や、外部メモリ３０３からＲＡＭ３０８に展開された制御プログラムに基づいてシステムバス３０４に接続される各ブロックを制御する。ＣＰＵ３０１の処理により生成された画像信号が、印刷部Ｉ／Ｆ３０５を介して印刷部（プリンタエンジン）３０６に印刷データとして出力され印刷される。またＣＰＵ３０１は、入力部３０７とネットワーク部３１０を介して認可サーバ２００との通信処理が可能であり、画像形成装置３００の情報等を認可サーバ２００に通知できる。ＲＯＭ３０２内のプログラムＲＯＭには、ＣＰＵ３０１の制御プログラム等が記憶されている。ＲＯＭ３０２内のフォントＲＯＭは、印刷データや表示データを生成する際に使用するフォントデータ等を記憶している。ＲＯＭ３０２内のデータＲＯＭは、ハードディスク等の外部メモリ３０３がない画像形成装置の場合、認可サーバ２００と送受信を行う情報等を記憶している。ＲＡＭ３０８は、ＣＰＵ３０１の主メモリや、ワークエリア等として機能するＲＡＭであり、図示しない増設ポートに接続されるオプションＲＡＭによりメモリ容量を拡張することができるように構成されている。また、ＲＡＭ３０８は、出力情報の展開領域、環境データ格納領域、ＮＶＲＡＭ等に用いられる。外部メモリ３０３は、メモリコントローラ（ＭＣ）３０９によりアクセスが制御される。外部メモリ３０３はオプションとして接続され、フォントデータ、エミュレーションプログラム、フォームデータ等を記憶する。また、操作部３１１は、ユーザにより操作されるスイッチ及び、ユーザへのメッセージなどを表示する、タッチパネル機能を有する表示器等を備えている。スキャナ部３１３は、原稿を読み取って、その原稿の画像に対応する画像データを生成する。スキャナ部Ｉ／Ｆ３１２はＣＰＵ３０１とスキャナ部３１３とのインタフェースを司る。尚、後述の全ての説明においては、特に断りのない限り画像形成装置３００における実行のハード上の主体はＣＰＵ３０１であり、ソフトウェア上の主体は外部メモリ３０３にインストールされたアプリケーションプログラムである。
【００３３】
図３は、本実施形態１に係る認可サーバ２００、リソースサーバ２１０、画像形成装置３００それぞれのソフトウェアモジュールの構成を示す図である。
【００３４】
図において、認可サーバ２００は、認可サーバモジュール６００を有し、リソースサーバ２１０は、リソースサーバモジュール７００を有する。
【００３５】
画像形成装置３００では、ＣＰＵ３０１がＲＯＭ３０２、或いは外部メモリ３０３に記憶されたＯＳ８２０を実行することで各アプリケーションを制御して図４のソフトウェアモジュールの機能を実現する。ＯＳ８２０は一般的にはリアルタイムＯＳが使用されるが、昨今ではＬｉｎｘ（登録商標）等の汎用ＯＳが使用されることもある。仮想マシン８１０は、例えばＪａｖａ（登録商標）ＶＭがよく知られている。この仮想マシン８１０はＯＳで制御されるアプリケーションとして動作する仮想的なアプリケーション実行環境である。アプリケーション管理フレームワーク８００は、仮想マシン８１０が提供するアプリケーションの実行環境上で動作する管理対象のアプリケーションのライフサイクルを管理する機能を備えている。併せてそれを制御するＩ／Ｆ、各アプリケーション間での処理要求を仲介するＩ／Ｆ公開機能を備えている。ここでライフサイクルは、アプリケーションのインストール、起動、停止、アンインストールを含むアプリケーションの状態を示す。
【００３６】
本実施形態１に係るアプリケーション管理フレームワーク８００は、ＯＳＧｉ（Open Services Gateway initiative）アライアンスで規定されたＯＳＧｉ（登録商標）として説明する。認可サーバ連携クライアント４００、ローカルログインアプリケーション１０００、Ｗｅｂログインアプリケーション１１００、リソースサービスと連携する連携アプリケーション５００は、仮想マシン８１０上の実行環境で動作する。また、これらアプリケーションは、アプリケーション管理フレームワーク８００にてライフサイクル管理されている。アプリケーション管理アプリケーション８３０は、アプリケーション管理フレームワーク８００が公開するライフサイクル管理用の制御Ｉ／Ｆを介して、ユーザからの各種アプリケーションのインストールや、開始リクエストを受け付けて実行する。
【００３７】
ここでアプリケーション管理アプリケーション８３０、ローカルログインアプリケーション１０００、Ｗｅｂブラウザ９００及びネットワーク状態定期監視９１０は、画像形成装置３００が既定で持っているものである。認可サーバ連携クライアント４００、連携アプリケーション５００は、アプリケーション管理アプリケーション８３０及びアプリケーション管理フレームワーク８００を介して後からインストールされる。Ｗｅｂブラウザ９００は、ｗｗｗを利用するためのユーザエージェントである。
【００３８】
図４は、実施形態１に係る認可サーバ２００が外部メモリ２１１に記憶するデータテーブルを説明する図である。これらデータテーブルは、認可サーバ２００の外部メモリではなく、ＬＡＮ１０１を介して通信可能に構成された別のサーバに記憶されていても良い。
【００３９】
図４（Ａ）は、ユーザ管理テーブルの一例を示す図である。このユーザ管理テーブルは、クライアント（デバイスを含むユーザと、そのユーザのＩＤ、パスワードを関連付けて記憶している
ユーザ管理テーブルは、ユーザＩＤ１２０１、パスワード１２０２、ユーザ種別１２０３を有する。認可サーバ２００は、ユーザＩＤ１２０１、パスワード１２０２の情報の組を検証し、正しければ認証情報を生成することで、各ユーザもしくはクライアントを認証する機能を備える。ここではユーザ種別として、ユーザとクライアント（デバイス）とがある。
【００４０】
図４（Ｂ）は、クライアント管理テーブルの一例を示す図である。このクライアント管理テーブルは、クライアントの情報を記憶している。
【００４１】
クライアント管理テーブルは、クライアントＩＤ１３０１、クライアント名１３０２、クライアント説明１３０３、リダイレクトＵＲＬ１３０４、シリアル番号１３０５を有する。クライアントＩＤ１３０１は、図４（Ａ）のユーザ管理テーブルのユーザＩＤ１２０１と関連付いており、互いに参照可能となっている。クライアント名１３０２、クライアント説明１３０３、リダイレクトＵＲＬ１３０４は、後述のＯＡｕｔｈのシーケンスで利用される値である。シリアル番号１３０５は、クライアントが画像形成装置３００の場合に登録される値であり、画像形成装置３００をユニークに識別可能な値である。
【００４２】
このクライアント管理テーブルには、図４（Ａ）のユーザ管理テーブルのユーザＩＤ（dev0000000）のクライアント情報が登録されている。
【００４３】
図４（Ｃ）は、認可トークン管理テーブルの一例を示す図で、認可サーバ２００が許可したクライアントやユーザ、認可サーバが発行したトークンの情報を記憶している。
【００４４】
認可トークン管理テーブルは、認可トークンＩＤ１４０１、トークン種別１４０２、有効期限１４０３、スコープ１４０４、リフレッシュトークンＩＤ１４０５、リフレッシュ期限１４０６、クライアントＩＤ１４０７、ユーザＩＤ１４０８を有する。これら認可トークン管理テーブルの処理詳細については後述する。
【００４５】
ここで例えば、認可トークンＩＤが「AT_000001」の親トークンは、リソースＡに関して、ユーザ（uid00000001）が画像形成装置（dev00000001）に対して権限を移譲した場合のトークンを示す。
【００４６】
図５は、実施形態１に係る画像形成装置３００が外部メモリ３０３に記憶するデータテーブルを説明する図である。
【００４７】
図５（Ａ）は、デバイスユーザ管理テーブルの一例を示す図である。このデバイスユーザ管理テーブルは、画像形成装置３００のユーザのＩＤとそのユーザのパスワード、ＩＣカード情報を関連付けて記憶している。
【００４８】
デバイスユーザ管理テーブルは、ローカルログインアプリケーション１０００、Ｗｅｂログインアプリケーション１１００から参照、更新可能である。また本実施形態１では、これらテーブルを画像形成装置３００の外部メモリ３０３に記憶するとしているが、画像形成装置３００がＬＡＮ１０１を介して通信可能な別のサーバに構成しても良い。デバイスユーザ管理テーブルは、ユーザＩＤ１５０１、パスワード１５０２、ＩＣカード情報１５０３を含む。ローカルログインアプリケーション１０００は、画像形成装置３００の入力画面を用いてユーザからのユーザＩＤ、パスワードの入力を受け付ける画面（不図示）を表示する。そして、その画面を介して入力されたユーザＩＤ、パスワードの組が、このデバイスユーザ管理テーブルのユーザＩＤ１５０１、パスワード１５０２の組と合致するか否かを検証する。そして合致したときはユーザＩＤ１５０１の情報を含むログインコンテキストを生成することで、各ユーザを認証する。
【００４９】
また、ローカルログインアプリケーション１０００は、画像形成装置３００に接続されたＩＣカードリーダ（不図示）からＩＣカード情報を取得する。そして、ＩＣカード情報１５０３の情報と合致するかを検証し、合致したときは対応するユーザＩＤ１５０１の情報を含むログインコンテキストを生成することで、各ユーザを認証する。Ｗｅｂログインアプリケーション１１００は、Ｗｅｂブラウザ９００からユーザのユーザＩＤ、パスワードを受け付ける画面（不図示）を表示する。そして、その画面を介して入力されたユーザＩＤ、パスワードの組が、ユーザＩＤ１５０１、パスワード１５０２の組と一致するかを検証し、一致すればユーザＩＤ１５０１の情報を含むログインコンテキストを生成することで、各ユーザを認証する。ここで、ログインコンテキストとは、認証を受けたユーザのユーザＩＤ１５０１の情報が設定されたオブジェクトである。その他に、ユーザの属性情報、例えば、ユーザが所属するドメインやユーザの電子メールアドレス等の情報を設定するよう構成することもできる。
【００５０】
図５（Ｂ）は、デバイス管理テーブルの一例を示す図である。
【００５１】
デバイス管理テーブルは、認可サーバ連携クライアント４００のみから参照、更新可能である。デバイス管理テーブルは、クライアントＩＤ１６０１、クライアントシークレット１６０２、エンドポイントＵＲＬ１６０３、クライアント名１６０５、クライアント説明１６０６、リダイレクトＵＲＬ１６０４、アクセスＵＲＬ１６０８を有する。ここで、クライアントＩＤ１６０１、クライアントシークレット１６０２は、予め認可サーバ２００で発行、記憶されたユーザ管理テーブル（図４（Ａ））のユーザＩＤ１２０１、パスワード１２０２にそれぞれ対応している。更に、クライアント名１６０５、クライアント説明１６０６、リダイレクトＵＲＬ１６０７、アクセスＵＲＬ１６０８も、認可サーバ２００のクライアント管理テーブル（図４（Ｂ））に格納される。また図４（Ｂ）のクライアント管理テーブルのクライアントＩＤ１３０１、画像形成装置３００のシリアル番号１３０５と共に登録されている情報と同様のデータが格納されている。これらのクライアント情報を認可サーバ連携クライアント４００が認可サーバ２００に登録・更新するタイミングは、認可サーバ連携クライアント４００の起動時と認可連携の開始時である。このクライアント情報の登録及び更新の詳細については後述する。
【００５２】
エンドポイントＵＲＬ１６０３は、認可サーバ２００が公開するＯＡｕｔｈのためのエンドポイントのＵＲＬである。アクセスＵＲＬ１６０８は、認可サーバ連携クライアント４００が公開するＷｅｂブラウザからアクセスし、認可開始時にアクセスするＵＲＬとショートカット名称を含む。
【００５３】
図５（Ｃ）は、親トークン管理テーブルの一例を示す図である。この親トークン管理テーブルは、ユーザが画像形成装置３００に権限を移譲した場合に発行される親トークンを管理している。
【００５４】
親トークン管理テーブルは、認可サーバ連携クライアント４００からのみ参照、更新可能である。親トークン管理テーブルは、ユーザＩＤ１７０１、認可トークンＩＤ１７０２、リフレッシュトークンＩＤ１７０３を有する。認可トークンＩＤ１７０２、リフレッシュトークンＩＤ１７０３は、図４（Ｃ）の認可トークン管理テーブルに対応している。親トークン管理テーブルの処理詳細については後述する。
【００５５】
図５（Ｄ）は、Ｗｅｂブラウザショートカットテーブルの一例を示す図である。
【００５６】
Ｗｅｂブラウザショートカットテーブルは、Ｗｅｂブラウザ９００、認可サーバ連携クライアント４００及びアプリケーション管理アプリケーション８３０からの参照、更新が可能である。Ｗｅｂブラウザショートカットテーブルは、ショートカット名称１８０１、ＵＲＬ１８０２、登録アプリケーション１８０３を有する。ここで、ショートカット名称１８０１、ＵＲＬ１８０２、登録アプリケーション１８０３を登録するタイミングは、認可サーバ連携クライアント４００の起動時である。Ｗｅｂブラウザショートカット情報の登録の詳細については後述する。
【００５７】
ショートカット名称１８０１は、Ｗｅｂブラウザ９００のショートカットボタン（指示部）としてＧＵＩ上に提供される名称である。ＵＲＬ１８０２は、ショートカットボタンを押下することで、Ｗｅｂブラウザ９００の開始画面として起動するためのエンドポイントとなるＵＲＬである。登録アプリケーション１８０３は、ショートカットボタンを登録したアプリケーションの名称である。有効／無効フラグ１８０４は、認可サーバ連携クライアント４００の起動処理が正常に終了した時に、リソースサービス連携が成功したと判断し有効となるフラグである。また、ネットワーク状態定期監視９１０がチェックするネットワーク通信状態の監視結果から、ネットワーク接続切断状態を認識した際には、この有効／無効フラグ１８０４を無効とし、ネットワークが使用できない場合は一時的に利用できなくする。ネットワーク状態が正常に復旧すれば、有効／無効フラグ１８０４を有効に設定する。使用ライセンス有無フラグ１８０５は、Ｗｅｂブラウザ９００の使用ライセンスがインストールされているか否かを判断するためのフラグである。この使用ライセンスは、アプリケーション管理アプリケーション８３０、及び、アプリケーション管理フレームワーク８００を介してインストールされる。アプリケーション管理アプリケーション８３０は、使用ライセンスがインストール／アンインストールされたときに、使用ライセンス有無フラグ１８０５の情報を更新する。このＷｅｂブラウザショートカットテーブルの作成時は、認可サーバ連携クライアント４００がアプリケーション管理アプリケーション８３０から使用ライセンスのインストールの有無の情報を取得する。
【００５８】
図６は、実施形態１における表示項目制限リストの一例を示す図である。
【００５９】
この表示項目制限リストは、Ｗｅｂブラウザ９００、認可サーバ連携クライアント４００及びアプリケーション管理アプリケーション８３０からの参照、更新が可能である。Ｗｅｂブラウザ表示項目１９０１にある表示項目に対して、通常Ｗｅｂブラウザ実行時、又は、リソースサービス連携ブラウザ実行時にどの項目を表示するかを管理しているリストである。Ｗｅｂブラウザ９００は、画像形成装置３００の操作部３１１に表示する際に、この表示項目制限リストを参照し、表示する項目を制御する。通常Ｗｅｂブラウザ１９０２は、使用ライセンスがインストールされており、リソースサービス連携がされていない、又は、リソースサービス連携ブラウザ表示ではないときに表示する項目である。
【００６０】
図７は、リソースサービス連携がされていない、又は、リソースサービス連携ブラウザ表示ではない通常Ｗｅｂブラウザにより表示される画面の一例を示す図である。
【００６１】
図６のリソースサービス連携時ブラウザ（Ｗｅｂブラウザライセンスあり）１９０３は、そのＷｅｂブラウザの使用ライセンスがインストールされており、リソースサービス連携ブラウザ表示のときに表示する項目を示す。本実施形態１では、セキュリティの観点から、印刷ボタン、設定−ページメモ、ＵＲＬを非表示としている。
【００６２】
図８は、使用ライセンスがインストールされていて、リソースサービス連携ブラウザ表示であるＷｅｂブラウザにより表示される画面の一例を示す図である。
【００６３】
前述の図７と比較すると明らかなように、図８では、リソースサービスと連携しているため、リソースサービスにアクセスするための認可設定の開始を指示するボタンが表示されている。また図８では、図６の設定に対応して、図７の印刷ボタン、ページメモ、及びアドレスバーのＵＲＬ表示が表示されていない。
【００６４】
図６のリソースサービス連携時ブラウザ（Ｗｅｂブラウザライセンスなし）１９０４は、使用ライセンスが未インストールで、リソースサービス連携ブラウザ表示時に表示する項目である。ここでは、Ｗｅｂブラウザの使用ライセンスを購入したユーザとの間で不公平が生じてしまうことのないように、限定された表示項目となる。
【００６５】
図９は、Ｗｅｂブラウザの使用ライセンスが未インストールで、リソースサービス連携ブラウザ表示であるＷｅｂブラウザにより表示される画面の一例を示す図である。
【００６６】
ここでも図６の設定に対応して、図７に示すタイトル、印刷ボタン、ホームボタン、お気に入りボタン、履歴、ページメモ、アドレスバー、ＵＲＬ等が非表示となっている。
【００６７】
認可サーバ連携クライアント４００は、アプリケーションの起動時に認可サーバ２００にクライアント情報の登録や更新及びＷｅｂブラウザショートカットの登録を行う。
【００６８】
図１０は、実施形態１に係る認可サーバ連携クライアント４００の起動時のクライアント情報の登録や更新及びＷｅｂブラウザショートカットの登録処理を説明するフローチャートである。尚、このフローチャートで示す処理は、ＣＰＵ３０１がプログラムＲＯＭに記憶されているプログラムを実行することにより実現されるが、ここでは各処理の主体を図３に示すソフトウェアモジュールとして説明する。
【００６９】
先ずＳ１００１で、アプリケーション管理フレームワーク８００は、認可サーバ連携クライアント４００を起動する。次にＳ１００２に進み認可サーバ連携クライアント４００は、画像形成装置３００のデバイス情報を取得する。ここで取得するデバイス情報には、プリンタモデル名、プリンタ名、設置場所、シリアル番号が含まれる。次にＳ１００３に進み認可サーバ連携クライアント４００は、Ｓ１００２で取得したデバイス情報を用いてクライアント名とクライアント説明を生成する。ここで生成するクライアント名とクライアント説明は、例えば図５（Ｂ）の例に示すような文字列である。本実施形態１では、クライアント名にプリンタモデル名を、クライアント説明にプリンタ名と設置場所を用いている。しかし、クライアント名やクライアント説明は後述の認可確認画面に表示されるため画像形成装置３００をユーザが識別できる文字列であることが望ましい。ここでプリンタ名、設置場所はユーザにより任意の値に変更可能であり、変更が行われた場合には合わせてクライアント名、クライアント説明も変更する必要がある。
【００７０】
次にＳ１００４に進んで認可サーバ連携クライアント４００は、画像形成装置３００のアドレス情報を取得する。このアドレス情報には、ＩＰｖ４アドレス、ループバックＩＰｖ４アドレス、手動ＩＰｖ６アドレス、リンクローカルＩＰｖ６アドレス、ステートレスＩＰｖ６アドレス、ステートフルＩＰｖ６アドレス、ループバックＩＰｖ６アドレス、ホスト名がある。ここでＩＰｖ４アドレス、手動ＩＰｖ６アドレス、リンクローカルＩＰｖ６アドレス、ステートレスＩＰｖ６アドレス、ステートフルＩＰｖ６アドレス、ホスト名は、ネットワーク環境により変更される可能性がある。次にＳ１００５に進み認可サーバ連携クライアント４００は、Ｓ１００４で取得したアドレス情報を基に、デバイスブラウザ用リダイレクトＵＲＬを生成する。デバイスブラウザ用リダイレクトＵＲＬは、ループバックＩＰｖ４アドレス、ループバックＩＰｖ６アドレスをＦＱＤＮとして生成する。
【００７１】
図５（Ｂ）に示すリダイレクトＵＲＬ１６０７は、生成したデバイスブラウザ用リダイレクトＵＲＬの一例である。本実施形態１では、転送プロトコルにhttpsを用いており、デバイスブラウザ用リダイレクトＵＲＬのエンドポイントとしてredirect/deviceとしている。
【００７２】
次にＳ１００６に進み認可サーバ連携クライアント４００は、図５（Ｂ）のデバイス管理テーブルを既に保持しているか否か判定する。ここでデバイス管理テーブルが作成されていないと判定した場合はＳ１００７に進む。Ｓ１００７で認可サーバ連携クライアント４００は、Ｓ１００３，Ｓ１００５で生成したクライアント名、クライアント説明、リダイレクトＵＲＬと、Ｓ１００２で取得したシリアル番号とで、認可サーバ２００にクライアントの登録要求を行う。次にＳ１００８に進み、認可サーバ連携クライアント４００は、認可サーバ２００からクライアントの登録要求に対する登録応答としてクライアントＩＤとクライアントシークレットを受け取る。そしてＳ１００９に進み認可サーバ連携クライアント４００は、デバイス管理テーブル（図５（Ｂ））を生成し、それを外部メモリ３０３に保持してＳ１０１３に進む。これとともに認可サーバ連携クライアント４００は、認可サーバ連携クライアント４００が公開するＷｅｂブラウザからアクセスするためのＵＲＬ及びショートカット名称を生成し、それをデバイス管理テーブルにアクセスＵＲＬ１６０８として保持する。ここでデバイス管理テーブルは、Ｓ１００３，Ｓ１００５で生成したクライアント名、クライアント説明、リダイレクトＵＲＬをそれぞれ保持し、エンドポイントＵＲＬ１６０３には、認可サーバ２００のエンドポイントを保持する。
【００７３】
一方、Ｓ１００６で認可サーバ連携クライアント４００がデバイス管理テーブルを保持していると判定したときはＳ１０１０に進む。Ｓ１０１０で認可サーバ連携クライアント４００は、クライアント名１６０５、クライアント説明１６０６、リダイレクトＵＲＬ１６０７に変更がないか、Ｓ１００３，Ｓ１００５の生成結果と比較する。クライアント名、クライアント説明に利用するプリンタ名と設置場所に利用するＩＰｖ４アドレス、手動ＩＰｖ６アドレス、リンクローカルＩＰｖ６アドレス、ステートレスＩＰｖ６アドレス、ステートフルＩＰｖ６アドレス、ホスト名は変更可能である。Ｓ１０１０で変更されていないと判定したときはＳ１０１３に進むが、変更されていると判定するとＳ１０１１に進み、認可サーバ連携クライアント４００は認可サーバ２００にクライアント更新要求を行う。このクライアント更新要求では、デバイス管理テーブルのクライアントＩＤ１６０１、クライアントシークレット１６０２、Ｓ１００３，Ｓ１００５で生成したクライアント名、クライアント説明、リダイレクトＵＲＬを通知する。更に、Ｓ１００２で取得したシリアル番号も通知する。そしてクライアント更新要求に成功するとＳ１０１２に進み、認可サーバ連携クライアント４００は、クライアント更新要求で通知した情報でデバイス管理テーブルを更新してＳ１０１３に進む。
【００７４】
Ｓ１０１３で認可サーバ連携クライアント４００は、デバイス管理テーブルにクライアントシークレット１６０２が存在するかを判定する。ここでクライアントシークレット１６０２が存在すると判定するとＳ１０１４に進み、存在しないと判定した場合は、この処理を終了する。Ｓ１０１４で認可サーバ連携クライアント４００は、デバイス管理テーブルのアクセスＵＲＬ１６０８を取得し、アプリケーション管理アプリケーション８３０からＷｅｂブラウザの使用ライセンスの有無情報を取得する。そしてＳ１０１５に進み、その取得した情報を基に、図５（Ｄ）に示すようなＷｅｂブラウザショートカットテーブルを生成し、それを外部メモリ３０３に保持して、この処理を終了する。
【００７５】
以上説明した処理により、図５（Ｂ）に示すようなデバイス管理テーブルを作成或いは更新でき、そのデバイス管理テーブルにクライアントシークレットが存在するときは、図５（Ｄ）に示すようなＷｅｂブラウザショートカットテーブルを生成する。
【００７６】
図１１は、実施形態１に係る画像形成装置による親トークンの取得シーケンスを説明する図である。図１１は、画像形成装置３００のＷｅｂブラウザ９００を用いた親トークン取得シーケンスを示しており、このシーケンスは、ユーザが画像形成装置３００を最初に利用する際に、画像形成装置３００のＷｅｂブラウザ９００を用いて一度だけ行う操作である。
【００７７】
まずＳ１１０１で、ユーザが、ローカルログインアプリケーション１０００が提供する画像形成装置３００の入力画面を用いたログイン手段を用いて画像形成装置３００にログインする。ここでユーザＩＤが「user001」のユーザがログインしたとする。これによりＳ１１０２で、ローカルログインアプリケーション１０００は、この「user001」を含むログインコンテキストを生成する。次にＳ１１０３で、ユーザがＷｅｂブラウザを起動するＷｅｂブラウザ９００がＷｅｂブラウザショートカットテーブル（図５（Ｄ））を参照して、画像形成装置３００の操作部３１１にショートカットを表示する。そしてユーザは、そのショートカットを選択してＷｅｂブラウザ９００を実行する。そしてＷｅｂブラウザ９００を用いて認可サーバ連携クライアント４００の認可連携を開始するためのＵＲＬ１８０２へアクセスする。このとき、Ｗｅｂブラウザ９００は、前述した、例えば図９に示すような認可連携開始を確認する画面を表示する。この場合の表示項目は、表示条件によって制限される。制限項目決定方法についての詳細は後述する。図９は、表示条件がリソースサービス連携時ブラウザ（Ｗｅｂブラウザの使用ライセンスなし）の場合を示す。
【００７８】
認可サーバ連携クライアント４００は、認可連携の開始を受け付けたら、Ｓ１１０４のログインアプリケーション特定によりローカルログインと特定する。次にＳ１１０５で、デバイス情報の更新の要否を判断し、デバイス情報の更新が必要な場合は認可サーバ２００にデバイス情報の更新要求を行う。Ｓ１１０６で認可サーバ連携クライアント４００は、ローカルログインアプリケーション１０００にログインコンテキストを要求する。これに応答してＳ１１０７で、ローカルログインアプリケーション１０００は、認可サーバ連携クライアント４００にログインコンテキストを送る。
【００７９】
そしてＳ１１０８でＷｅｂブラウザ９００は、デバイス管理テーブルのエンドポイントＵＲＬ１６０３に記載のＵＲＬに対して、ＯＡｕｔｈの認可リクエストを要求するリダイレクト要求を送信する。このＯＡｕｔｈの認可リクエストには、デバイス管理テーブル（図５（Ｂ））のクライアントＩＤ１６０１、リダイレクトＵＲＬ１６０７の情報が含まれる。この認可リクエストに含まれるリダイレクトＵＲＬは、デバイスブラウザ用リダイレクトＵＲＬであり、Ｓ１１０３で受け付けたリクエストのＦＱＤＮと一致するＵＲＬを用いる。また、ＯＡｕｔｈでは、認可を受けたい権限範囲を示すスコープを認可リクエストに含ませることもできる。本実施形態１では、スコープとしてスコープＡがリクエストされたとして説明する。
【００８０】
この認可リクエストを受け付けた認可サーバ２００は、Ｓ１１０９で、ユーザを認証するためにログイン画面をＷｅｂブラウザ９００に応答する。このときのログイン画面の一例を図１２（Ａ）に示す。
【００８１】
図１２（Ａ）は、実施形態１に係る画像形成装置のＷｅｂブラウザで表示される、ユーザを認証するためにログイン画面の一例を示す図である。
【００８２】
次にＳ１１１０でユーザは、Ｗｅｂブラウザ９００に示されたログイン画面（図１２（Ａ）に対して、ユーザＩＤ、パスワードを入力してログインを実行する。これにより認可サーバ２００は、受け付けたユーザＩＤ、パスワードの組がユーザ管理テーブル（図４（Ａ））に登録されている情報と一致するか否かを検証し、一致する場合はユーザＩＤに紐づいた認証情報を生成して次の処理を実行する。認可サーバ２００は、認可リクエストに含まれているクライアントＩＤとリダイレクトＵＲＬの組みが、図４（Ｂ）のクライアント管理テーブルに登録されている情報と一致するかを検証する。検証の結果、一致するとＳ１１１１で、クライアント管理テーブル（図４（Ｂ））のクライアント名１３０２、クライアント説明１３０３を取得し、認可確認画面を生成してＷｅｂブラウザ９００に応答する。その際、認証情報をＷｅｂブラウザ９００に対してCookie情報として格納して応答する。
【００８３】
図１２（Ｂ）は、実施形態１に係る画像形成装置のＷｅｂブラウザにより表示される認可確認画面の一例を示す図である。
【００８４】
ここではユーザに対して、ユーザのデータへのアクセスの許可が求められていて、それに対して「許可」または「拒否」のボタンをクリックするように求めている。
【００８５】
尚、本実施形態１では、認可確認画面にクライアント名１３０２、クライアント説明１３０３を表示しているが、ここにログインしているユーザの情報を表示するようにしても良い。
【００８６】
次にＳ１１１２でユーザは、Ｗｅｂブラウザ９００に表示された認可確認画面で許可ボタンをクリックすると、許可を受けた認可サーバ２００は、認可トークン管理テーブル（図４（Ｃ）に認可コードを発行して登録する。ここでは認可トークンＩＤ１４０１に発行したトークンのＩＤ、トークン種別１４０２に認可コード、有効期限１４０３、スコープ１４０４を登録する。そして、認可リクエスト時に受け付けたクライアントＩＤをクライアントＩＤ１４０７に、Ｗｅｂブラウザ９００からCookieとして送信された認証情報に紐づくユーザＩＤをユーザＩＤ１４０８に登録する。そしてＳ１１１３で認可応答として、認可サーバ２００は、認可コードの認可トークンＩＤを付与してリダイレクトＵＲＬに対してＷｅｂブラウザ９００をリダイレクト要求する。
【００８７】
この認可応答を受けた認可サーバ連携クライアント４００は、Ｓ１１１４で、認可サーバ２００に対してトークン要求を行う。このトークン要求は、認可応答で取得した認可コードの認可トークンＩＤ、デバイス管理テーブル（図５（Ｂ）のクライアントＩＤ１６０１、クライアントシークレット１６０２、リダイレクトＵＲＬ１６０７を含む。
【００８８】
このトークン要求を受けた認可サーバ２００は以下の検証を行い、正しい場合はＳ１１１５で親トークンを生成する。認可サーバ２００は、トークン要求で受けつけたクライアントＩＤ、クライアントシークレットの組が、ユーザ管理テーブル（図４（Ａ））に登録されているユーザＩＤ１２０１、パスワード１２０２の組と合っているか検証する。
【００８９】
次に、トークン要求で受けつけた認可コードの認可トークンＩＤが、認可トークン管理テーブル（図４（Ｃ）に登録されているか、有効期限内かを検証する。そして、トークン要求で受けつけたクライアントＩＤとリダイレクトＵＲＬがそれぞれ認可トークン管理テーブルの認可トークンＩＤで特定されるクライアントＩＤ１４０７と、リダイレクトＵＲＬ１３０４と一致するか否かを検証する。ここで、リダイレクトＵＲＬ１３０４はクライアント管理テーブルではなく、認可トークン管理テーブルにカラムを追加し、認可コード発行時に登録して、その追加したリダイレクトＵＲＬと検証するよう構成しても良い。
【００９０】
こうして、これら全ての検証が正しい場合に認可サーバ２００は親トークンを生成して、親トークンの認可トークンＩＤを認可サーバ連携クライアント４００に応答する（Ｓ１１１６）。この際、応答内容として同時に発行したリフレッシュトークンＩＤも含む。親トークンとしては、認可トークンＩＤ１４０１に発行したトークンＩＤ、トークン種別１４０２に親トークン、有効期限１４０３、及び、認可コードから引き継ぐ情報として、クライアントＩＤ１４０７、ユーザＩＤ１４０８を登録する。この際、親トークンをリフレッシュするためのリフレッシュトークンを発行し、リフレッシュトークンＩＤ１４０５、リフレッシュ期限１４０６に登録する。
【００９１】
親トークンの認可トークンＩＤ、リフレッシュトークンＩＤを取得した認可サーバ連携クライアント４００は、Ｓ１１０６，Ｓ１１０７においてローカルログインアプリケーション１０００から取得したログインコンテキストからデバイスユーザＩＤを取得する。そして、図５（Ｃ）の親トークン管理テーブルに、デバイスユーザＩＤ、認可トークンＩＤ、リフレッシュトークンＩＤを保存する（Ｓ１１１７）。次にＳ１１１８で認可サーバ連携クライアント４００は、認可連携完了の旨を示す画面をＷｅｂブラウザ９００に応答して処理を終了する。
【００９２】
図１３は、実施形態１に係る画像形成装置のＷｅｂブラウザ９００が画面を表示する際に図６の表示項目制限に従って表示項目を決定する処理を説明するフローチャートである。尚、このフローチャートで示す処理は、ＣＰＵ３０１がプログラムＲＯＭに記憶されているプログラムを実行することにより実現される。
【００９３】
Ｗｅｂブラウザ９００が実行されるとまずＳ１３０１で、認可サーバ連携クライアント４００は、図５（Ｄ）のＷｅｂブラウザショートカットテーブルを参照し、Ｗｅｂブラウザ使用ライセンスの有／無フラグ１８０５を確認する。ここで使用ライセンスがあると判定するとＳ１３０２に進み、使用ライセンスがないと判定するとＳ１３０３に進む。Ｓ１３０２或いはＳ１３０３で、有効／無効フラグ１８０４を確認して、認可サーバ連携クライアント４００が有効かどうかを判定する。Ｓ１３０２で認可サーバ連携クライアント４００が有効と判定するとＳ１３０５に進み、図６のＷｅｂブラウザの使用ライセンスありの場合のリソースサービス連携ブラウザの表示項目１９０３を取得してＳ１３０７に進む。一方、Ｓ１３０２で認可サーバ連携クライアント４００が有効でないときはＳ１３０４に進み、図６の通常Ｗｅｂブラウザの表示項目１９０２を取得してＳ１３０７に進む。
【００９４】
またＳ１３０３で、認可サーバ連携クライアント４００が有効と判定するとＳ１３０６に進み、図６のＷｅｂブラウザの使用ライセンスなしの場合のリソースサービス連携ブラウザの表示項目１９０４を取得してＳ１３０７に進む。一方、Ｓ１３０３で認可サーバ連携クライアント４００が有効でないときは、そのまま処理を終了する。そしてＳ１３０７では、取得した表示制限情報に従って表示項目が制限されたＷｅｂブラウザ９００を起動する。
【００９５】
（認可サーバ連携クライアントのアンインストール）
認可サーバ連携クライアント４００が利用されなくなる場合は、アプリケーション管理アプリケーション８３０及びアプリケーション管理フレームワーク８００を介してアンインストールする。アプリケーション管理アプリケーション８３０は、図５（Ｄ）のＷｅｂブラウザショートカットテーブルから、登録アプリケーション１８０３が認可サーバ連携クライアント４００と合致する情報を削除する。
【００９６】
以上説明したように実施形態１によれば、Ｗｅｂブラウザの使用ライセンスが無い場合でも、リソースサービス連携が有効であればＷｅｂブラウザの使用が可能となる。また、表示項目を制限したＷｅｂブラウザを表示することで、使用ライセンスを購入したユーザとの間で不公平を生じさせることなくＷｅｂブラウザを使用することができる。
【００９７】
［実施形態２］
前述の実施形態１では、表示項目制限のリスト（図６）を記憶する表示項目制限記憶部が画像形成装置３００の外部メモリ３０３である例を説明した。しかし、この場合は、表示項目制限リストを更新するときには、画像形成装置を１台１台更新しなければならなく、複数台管理している環境においては手間となる。また、連携するリソースサービスによっても制限する表示項目が異なる場合がある。そこで実施形態２では、表示項目制限記憶部をリソースサーバ２１０に設け、画像形成装置３００がリソースサーバ２１０からその表示項目制限リストを取得する例を説明する。
【００９８】
実施形態２のシステム構成、各種サーバの構成、画像形成装置３００の構成、認可サーバ２００、リソースサーバ２１０、画像形成装置３００それぞれのモジュール構成については、実施形態１の図１〜図３と同様のため、それらの説明を省略する。また認可サーバ２００が外部メモリ２１１に記憶するデータテーブルも図４と同様であるため、それらの説明を省略する。また画像形成装置３００が外部メモリ３０３に記憶するデータテーブルも図５と同様のため説明を省略する。図５（Ｄ）のＷｅｂブラウザショートカットテーブルは、図１４に示すＷｅｂブラウザショートカットテーブルに変更する。
【００９９】
図１４は、本発明の実施形態２に係るＷｅｂブラウザショートカットテーブルの一例を示す図である。図１４における２００１〜２００５は、図５（Ｄ）の１８０１〜１８０５に対応しているので、それらの説明を省略する。
【０１００】
図１４と図５（Ｄ）との差異は、表示項目制限リスト取得日時２００６が追加されている点にある。表示項目制限リスト取得日時２００６には、リソースサーバ２１０から表示項目制限リスト１９００を取得した日時を記録する。
【０１０１】
前述の図６の表示項目制限リストは、リソースサーバ２１０が外部メモリ２１１にテーブルとして記憶される。このテーブルの情報に関しては前述の実施形態１の図６と同様であるため、その説明を省略する。
【０１０２】
また、認可サーバ連携クライアント４００起動時のクライアント情報の登録・更新及びＷｅｂブラウザショートカットの登録の処理も前述の実施形態１と同様であるため、その説明を省略する。
【０１０３】
図１５は、実施形態２に係る画像形成装置３００が表示項目制限リストを取得する処理を説明するフローチャートである。尚、このフローチャートで示す処理は、ＣＰＵ３０１がプログラムＲＯＭに記憶されているプログラムを実行することにより実現されるが、ここでは各処理の主体を図３に示すソフトウェアモジュールとして説明する。
【０１０４】
Ｓ１５０１で、連携アプリケーション５００は画像形成装置３００へのユーザのログインを受け付けるとＳ１５０２に進み、連携アプリケーション５００は、ログインに成功したか否かを判定する。ログインに成功するとＳ１５０３に進み、連携アプリケーション５００はＷｅｂブラウザショートカットＵＲＬ２００２にアクセスしたか否かを判定する。Ｓ１５０３でアクセスしたと判定するとＳ１５０４に進み、連携アプリケーション５００は、リソースサーバ２１０から図６の表示項目制限リストを取得するように試みる。尚、Ｓ１５０２でログインに失敗した場合、或いはＳ１５０３でＷｅｂブラウザショートカットＵＲＬ２００２にアクセスしていないときは、処理を終了する。
【０１０５】
Ｓ１５０５で連携アプリケーション５００は、表示項目制限リストが取得できたか否かを判定し、取得できていなければＳ１５０６に進んで、デフォルト制限情報を設定してＳ１５０７に進む。デフォルト制限情報は、画像形成装置３００が元々有しているものでもよく、或いは、親トークンの取得時に、認可サーバ２００から取得した情報であってもよい。
【０１０６】
一方、Ｓ１５０５で表示項目制限リストが取得できたと判定した場合はＳ１５０７に進み、連携アプリケーション５００は、図１４のＷｅｂブラウザショートカットテーブルを参照し、Ｗｅｂブラウザ使用ライセンスの有／無フラグ２００５を確認する。Ｓ１５０７でＷｅｂブラウザ使用ライセンスがあると判定したときはＳ１５０８に進み、許可サーバ連携クライアント４００が有効かどうかを判定する。許可サーバ連携クライアント４００が有効であればＳ１５１１に進み、図６のリソースサービス連携時ブラウザ（Ｗｅｂブラウザライセンスあり）１９０３の表示項目の制限情報を取得してＳ１５１３に進む。Ｓ１５０８で許可サーバ連携クライアントが無効であればＳ１５１０に進み、図６の通常Ｗｅｂブラウザ（Ｗｅｂブラウザライセンスあり）１９０２の表示項目の制限情報を取得してＳ１５１３に進む。
【０１０７】
またＳ１５０７でＷｅｂブラウザ使用ライセンスがないと判定したときはＳ１５０９に進み、許可サーバ連携クライアントが有効かどうかを判定する。許可サーバ連携クライアントが有効であればＳ１５１２に進み、図６のリソースサービス連携時ブラウザ（Ｗｅｂブラウザライセンスなし）１９０４の表示項目の制限情報を取得してＳ１５１３に進む。またＳ１５０９で許可サーバ連携クライアントが有効でなければ、そのまま処理を終了する。
【０１０８】
以上説明したように実施形態２によれば、リソースサービスごとに表示項目の制限を行うことができるという効果がある。
【０１０９】
（その他の実施形態）
また、本発明は、以下の処理を実行することによっても実現される。即ち、上述した実施形態の機能を実現するソフトウェア（プログラム）を、ネットワーク又は各種記憶媒体を介してシステム或いは装置に供給し、そのシステム或いは装置のコンピュータ（又はＣＰＵやＭＰＵ等）がプログラムを読み出して実行する処理である。
【図１】
2015075902.tif 000003
【図２】
2015075902.tif 000004
【図３】
2015075902.tif 000005
【図４】
2015075902.tif 000006
【図５】
2015075902.tif 000007
【図６】
2015075902.tif 000008
【図１０】
2015075902.tif 000009
【図１１】
2015075902.tif 000010
【図１３】
2015075902.tif 000011
【図１４】
2015075902.tif 000012
【図１５】
2015075902.tif 000013
【図７】
2015075902.tif 000014
【図８】
2015075902.tif 000015
【図９】
2015075902.tif 000016
【図１２】
2015075902.tif 000017