JP6198507B2 - 画像形成装置及びその制御方法、並びにプログラム - Google Patents

Description

本発明は、画像形成装置及びその制御方法、並びにプログラムに関し、特に、画像形成装置上のＷｅｂブラウザを介してクラウドサービスへアクセスするためのアクセス制御技術に関する。

クラウドサービスとしてインターネット上にサービスを公開してサービスを提供するビジネスが展開されている。プリントサーバもインターネット上のプリントサービスとして機能を提供することが求められてきている。クラウドサービスとしてサービスを提供することで、大規模なデータセンタ上にプリントサーバを配置し、顧客ごとのハードウェア管理が不要となる。また、サーバの負荷に応じてリソースを追加するようなことが容易に行えるなど様々なメリットがある。このため、プリンタがプリントサーバからインターネット越しに印刷データを取得して印刷を行う、プルプリントによる印刷システムが提供されている。

これまで、イントラネット上で運用されてきたプリントサーバへのアクセスはイントラネットに限定されており、プリントサーバに対して不正アクセスするのは非常に困難であった。しかし、インターネット上のクラウドサービスとしてプリントサーバを公開する場合、世界中のどこからでもアクセス可能なため、セキュリティが非常に重要である。セキュリティの重要性が増している昨今において、ＯＡｕｔｈと呼ばれる、認可の連携を実現させるための標準プロトコルが策定され、クラウドサービスとそのクライアントのやりとりで適用され始めている（非特許文献１，２参照）。ＯＡｕｔｈでは、ユーザやクライアントから移譲された権限を証明する情報として、トークンと呼ばれる情報を利用する。クラウドサービスは、クライアントから通知されるトークンの有効性を検証することで不正アクセスを防ぐことができる。

"Ｔｈｅ ＯＡｕｔｈ １．０ Ｐｒｏｔｏｃｏｌ"、［ｏｎｌｉｎｅ］ Ｅ． Ｈａｍｍｅｒ−Ｌａｈａｖ、２０１２年９月 ＜ＵＲＬ ｈｔｔｐ：／／ｔｏｏｌｓ．ｉｅｔｆ．ｏｒｇ／ｈｔｍｌ／ｒｆｃ５８４９＞ "Ｔｈｅ ＯＡｕｔｈ ２．０ Ａｕｔｈｏｒｉｚａｔｉｏｎ Ｆｒａｍｅｗｏｒｋ ｄｒａｆｔ−ｉｅｔｆ−ｏａｕｔｈ−ｖ２−３１"、［ｏｎｌｉｎｅ］ Ｄ． Ｈａｒｄｔ．、２０１２年９月 ＜ＵＲＬ ｈｔｔｐ：／／ｔｏｏｌｓ．ｉｅｔｆ．ｏｒｇ／ｈｔｍｌ／ｄｒａｆｔ−ｉｅｔｆ−ｏａｕｔｈ−ｖ２−３１＞

ここで、プリンタ、複写機、ファクシミリ等の機能を統合したマルチファンクション機としての複合機能装置（以下、「画像形成装置」と称する。）がＯＡｕｔｈクライアントとなりクラウドサービスと連携する場合を考える。この場合、ユーザが画像形成装置にクラウドサービスのリソースへのアクセスを権限移譲することで、画像形成装置はクラウドサービスと連携できるようになる。このような画像形成装置が、クラウドサービスを提供するサーバと連携して実際に印刷処理を行う場合、画像形成装置に備えられたＷｅｂブラウザによるＷｅｂアクセスを利用することが考えられる。

しかしながら、画像形成装置のＷｅｂブラウザによりサーバにアクセスするためにはユーザがサーバのＵＲＬを直接入力する必要がある。そのため、間違ったＵＲＬを入力するとアクセスエラーとなってしまうという課題がある。

本発明は、上記課題に鑑みて成されたものであり、画像形成装置がサーバにアクセスするためのアクセスボタンをＷｅｂブラウザ上に容易に作成することができ、ユーザの操作を簡略化することができる技術を提供することを目的とする。

上記目的を達成するために、請求項１記載の画像形成装置は、サーバとネットワークを介して通信可能な画像形成装置であって、前記サーバに前記画像形成装置の認証を要求する要求手段と、前記画像形成装置の前記認証に関する処理が成功したか否かを判断する判断手段と、前記判断手段により前記画像形成装置の前記認証に関する処理が成功したと判断された場合に前記サーバにアクセスするためのボタンを表示し、前記判断手段により前記画像形成装置の前記認証に関する処理が失敗したと判断された場合に前記ボタンを表示しない制御を行う制御手段と、を有し、前記ボタンへの指示が行われた場合にブラウザによる前記サーバへのアクセスが行われることを特徴とする。

本発明によれば、画像形成装置がサーバにアクセスするためのアクセスボタンをＷｅｂブラウザ上に容易に作成することができ、ユーザがデバイス上のＷｅｂブラウザでＵＲＬを入力することなく、操作を簡略化することができる。

本発明の第１の実施形態に係る画像形成装置が設置されたネットワーク環境の一例を示す図である。 図１における認可サーバと画像形成装置のハードウェア構成の一例を示すブロック図である。 図１における画像形成装置のソフトウェア構成の一例を示すブロック図である。 画像形成装置の外部メモリに記憶されるテーブル情報の一例を示す図であり、（ａ）デバイスユーザ管理テーブル、（ｂ）デバイス管理テーブルである。 画像形成装置の外部メモリに記憶されるテーブル情報の一例を示す図であり、（ａ）親トークン管理テーブル、（ｂ）Ｗｅｂブラウザお気に入り管理テーブルである。 認可サーバ連携クライアント起動時のクライアント情報登録・更新及びＷｅｂブラウザお気に入り情報の登録処理の流れを示すフローチャートである。 認可サーバ連携クライアント起動時のクライアント情報登録・更新及びＷｅｂブラウザお気に入り情報の登録処理の流れを示すフローチャートである。 画像形成装置から認可サーバに対して認可を行う流れを示すシーケンス図である。 認可サーバの外部メモリに記憶されるテーブル情報の一例を示す図であり、（ａ）ユーザ管理テーブル、（ｂ）クライアント管理テーブル、（ｃ）認可トークン管理テーブルである。 画像形成装置のＷｅｂブラウザ上に表示される画面の一例を示す図であり、（ａ）認可連携開始画面、（ｂ）ログイン画面、（ｃ）認可確認画面である。 本発明の第２の実施形態に係る画像形成装置の操作部に表示される初期画面の一例を示す図である。 初期画面上のセンド認証のお気に入りアクセスボタンが押下されたときに切り替わるＷｅｂブラウザ画面の一例を示す図である。 初期画面の表示処理の流れを示すフローチャートである。 起動アプリテーブルの一例を示す図であり、（ａ）図１０の初期画面が表示されたときのもの、（ｂ）（ａ）の起動アプリテーブルに対してセンドアプリが削除または停止されたものである。 センドアプリが削除または停止されたときの初期画面の一例を示す図である。 本発明の第３の実施形態に係る初期画面の表示処理の流れを示すフローチャートである。

以下、本発明の実施の形態を図面を参照して詳細に説明する。

［第１の実施形態］
図１は、本発明の第１の実施形態に係る画像形成装置が設置されたネットワーク環境の一例を示す図である。

画像形成装置３００は、ＬＡＮ（Ｌｏｃａｌ Ａｒｅａ Ｎｅｔｗｏｒｋ）１０１を介してＷＡＮ（Ｗｉｄｅ Ａｒｅａ Ｎｅｔｗｏｒｋ）１００に接続されている。ＷＡＮ１００では、Ｗｏｒｌｄ Ｗｉｄｅ Ｗｅｂ（ＷＷＷ）システムが構築されている。

画像形成装置３００には、印刷アプリケーションや帳票アプリケーションのように、リソースサービスを利用する１つまたは複数のリソースサービス連携アプリケーションがインストールされている。ユーザはそれらのリソースサービス連携アプリケーションを用いてリソースサービスを利用する。なお、リソースサービスは帳票サービスや印刷サービスには限定されるものではない。また、リソースサービス連携アプリケーションは帳票アプリケーションや印刷アプリケーションに限られるものではない。

認可サーバ（認証サーバ）２００は、上述したＯＡｕｔｈを実現するためのサーバ（情報処理装置）であり、認可サービスを提供する。

リソースサーバ２１０は、インターネット上のデータを取得して印刷する印刷サービスやインターネット上で帳票データを生成する帳票サービスといったリソースサービスを提供する。なお、１台のリソースサーバに設置されるリソースサービスは１つでもよく、複数でもよい。

認可サーバ２００及びリソースサーバ２１０は、ＬＡＮ１０１を介してＷＡＮ１００に接続されている。

なお、認可サーバ２００、リソースサーバ２１０、及び画像形成装置３００はそれぞれ個別のＬＡＮ上に構成されていてもよいし、同一のＬＡＮ上に構成されていてもよい。また、認可サーバ２００及びリソースサーバ２１０は同一のサーバ上に構成されていてもよい。

例えば、ユーザが印刷アプリケーションを使ってリソースサービスを利用する場合には印刷アプリケーションに個別に認可を与える必要がある。同様に、ユーザが帳票アプリケーションを使ってリソースサービスを利用する場合にも帳票アプリケーションに個別に認可を与える必要がある。ユーザの立場で考えると、同一の画像形成装置を使ってリソースサービスを利用する場合、一度の認可操作でそれぞれのアプリケーションに認可を与えてリソースサービスを利用できるようになった方が、利便性が高い。

そこで、本実施形態では、ユーザの権限を画像形成装置のようなデバイスに移譲する。そして、アプリケーション（リソースサービス連携アプリケーション）に権限を移譲させる際、ユーザに代わり画像形成装置がアプリケーションに権限を移譲することで、ユーザの認可操作の回数を低減させる。即ち、ユーザは画像形成装置に権限を移譲した段階で、アプリケーションにも権限を移譲することを認めたこととする。上述したＯＡｕｔｈでは、ユーザから移譲された権限を証明するための情報として、トークンと呼ばれる情報を利用する。ユーザが画像形成装置に対して権限移譲した場合のトークンを親トークンと称する。

認可操作を一度で済ませる手段としては、例えば、画像形成装置が取得した親トークンを、画像形成装置上のアプリケーションで共有する方法が考えられる。しかしながら、この方法だと親トークンを共有するすべてのアプリケーションが全てのリソースサービスにアクセス可能となってしまい好ましくない。これは、アプリケーションが共有された親トークンを用いてリソースサービスにアクセスした場合、リソースサービス側にてアクセス元のアプリケーションが特定できず、利用の可否を判断することができないためである。

そこで、本実施形態では、個々のリソースサービス連携アプリケーションは親トークンを直接使うのでなく、親トークンに移譲された情報を継承しつつ、アプリケーション毎に再移譲して発行されるトークンを用いる。親トークンアプリケーション毎に再移譲して発行されたトークンを子トークンと称する。

図２は、図１における認可サーバ２００と画像形成装置３００のハードウェア構成の一例を示すブロック図である。

まず、認可サーバ２００のハードウェア構成について説明する。

認可サーバ２００は、一般的な情報処理装置のハードウェア構成を有する。なお、認可サーバ２００だけでなく、リソースサーバ２１０についても同様であるため、その説明は省略する。

図２において、ＣＰＵ２３１は、ＲＯＭ２３３のプログラム用ＲＯＭまたはハードディスク（ＨＤ）等の外部メモリ２４１からＲＡＭ２３２にロードされたＯＳ（Ｏｐｅｒａｔｉｎｇ Ｓｙｓｔｅｍ）やアプリケーション等のプログラムを実行する。そして、システムバス２３４に接続される各ブロックを制御する。

ＲＡＭ２３２は、ＣＰＵ２３１の主メモリ、ワークエリア等として機能する。キーボードコントローラ（ＫＢＣ）２３５は、キーボード（ＫＢ）２３９や不図示のポインティングデバイスからのキー入力を制御する。ＣＲＴコントローラ（ＣＲＴＣ）２３６は、ＣＲＴディスプレイ（ＣＲＴ）２４０の表示を制御する。

ディスクコントローラ（ＤＫＣ）２３７は、各種データを記憶するハードディスク（ＨＤ）等の外部メモリ２４１におけるデータアクセスを制御する。ネットワークコントローラ（ＮＣ）２３８は、ＷＡＮ１００もしくはＬＡＮ１０１を介して接続された画像形成装置３００や他の機器との通信制御処理を実行する。

なお、後述の全ての説明において、特に断りのない限り、サーバ上で実行される処理のハード上の主体はＣＰＵ２３１であり、ソフトウェア上の主体は外部メモリ２４１にインストールされたアプリケーションプログラムである。

次に、画像形成装置３００のハードウェア構成について説明する。

画像形成装置３００において、ＣＰＵ３０１は、ＲＯＭ３０２や外部メモリ３０３に記憶された制御プログラムに基づいてシステムバス３０４に接続される各ブロックを制御する。ＣＰＵ３０１の処理により生成された画像信号が、印刷部Ｉ／Ｆ３０５を介して、印刷部（画像形成装置エンジン）３０６に出力情報として出力される。また、ＣＰＵ３０１は、入力部３０７とネットワーク部３１０を介して認可サーバ２００との通信処理が可能となっており、画像形成装置３００内の情報等を認可サーバ２００に通知できる。

ＲＯＭ３０２内のプログラムＲＯＭには、ＣＰＵ３０１の制御プログラム等を記憶している。ＲＯＭ３０２内のフォント用ＲＯＭには、出力情報を生成する際に使用するフォントデータ等を記憶している。なお、ハードディスク等の外部メモリ３０３がない場合、ＲＯＭ３０２内のデータ用ＲＯＭには、認可サーバ２００と送受信を行う情報等が記憶されている。

ＲＡＭ３０８は、ＣＰＵ３０１の主メモリや、ワークエリア等として機能するＲＡＭであり、図示しない増設ポートに接続されるオプションＲＡＭによりメモリ容量を拡張することができるように構成されている。また、ＲＡＭ３０８は、出力情報展開領域、環境データ格納領域、ＮＶＲＡＭ等に用いられる。

外部メモリ３０３は、メモリコントローラ（ＭＣ）３０９によりアクセスを制御される。外部メモリ３０３は、オプションとして接続され、フォントデータ、エミュレーションプログラム、フォームデータ等を記憶する。操作部３１１は、操作のためのスイッチ及びＬＥＤ表示器等で構成されている。

図３は、図１における画像形成装置３００のソフトウェア構成の一例を示すブロック図である。

画像形成装置３００では、ＣＰＵ３０１がＲＯＭ３０２または外部メモリ３０３に記憶されたＯＳを実行することで各種アプリケーションを制御する。

図３において、アプリケーション管理フレームワーク８００は、例えばＪａｖａ（登録商標）ＶＭ等から成る仮想マシン８１０が提供するアプリケーション実行環境上で動作する管理対象のアプリケーションのライフサイクルを管理する機能を備えている。また、アプリケーション管理フレームワーク８００は、それを制御するＩ／Ｆ、各アプリケーション間での処理要求を仲介する機能を備えている。ライフサイクルとは、アプリケーションのインストール、起動、停止、アンインストールを含むアプリケーションの状態を示すものとする。本実施形態におけるアプリケーション管理フレームワーク８００は、ＯＳＧｉ（Ｏｐｅｎ Ｓｅｒｖｉｃｅｓ Ｇａｔｅｗａｙ ｉｎｉｔｉａｔｉｖｅ）アライアンスで規定されたＯＳＧｉ（登録商標）とする。

仮想マシン８１０は、ＯＳ８２０で制御されるアプリケーションとして動作する仮想的なアプリケーション実行環境である。ＯＳ（Ｏｐｅｒａｔｉｎｇ Ｓｙｓｔｅｍ）８２０は、一般的にはリアルタイムＯＳが使用されるが、昨今ではＬｉｎｕｘ（登録商標）等の汎用ＯＳが使用されることもある。

Ｗｅｂブラウザ９００は、ＷＷＷを利用するためのユーザエージェントである。

アプリケーション管理アプリケーション８３０は、アプリケーション管理フレームワーク８００が公開するライフサイクル管理用の制御Ｉ／Ｆを介して、ユーザからの各種アプリケーションのインストールや、開始リクエストを受け付けて実行する。

ローカルログインアプリケーション８４０は、ユーザからのユーザＩＤやパスワードの入力を受け付ける画面（不図示）を画像形成装置３００の操作部３１１に表示する機能を備える。

また、ローカルログインアプリケーション８４０は、入力されたユーザＩＤとパスワードの組が図４（ａ）に示すユーザＩＤ１５０１とパスワード１５０２の組と合っているか判定し、正しければユーザＩＤ１５０１の情報を含むログインコンテキストを生成する。ログインコンテキストとは、認証を受けたユーザのユーザＩＤ１５０１の情報が設定されたオブジェクトである。その他に、ユーザの属性情報、例えば、ユーザが所属するドメインやユーザの電子メールアドレス等の情報を設定するよう構成することもできる。

また、ローカルログインアプリケーション８４０は、画像形成装置３００に接続された不図示のＩＣカードリーダーからＩＣカード情報を取得する。そして、図４（ａ）に示すＩＣカード情報１５０３の情報と合っているか判定し、正しければ対応するユーザＩＤ１５０１の情報を含むログインコンテキストを生成することで、各ユーザを認証する。そのような機能を備えていてもよい。

認可サーバ連携クライアント４００（認可アプリケーション）は、後述する図６Ａ、図６Ｂに示す処理を実行し、認可サーバ２００に対してユーザ認可を行うアプリケーションである。リソースサービス連携アプリケーション５００は、上述したように、印刷アプリケーションや帳票アプリケーションのように、リソースサービスを利用する１つまたは複数のアプリケーションである。

ローカルログインアプリケーション８４０、認可サーバ連携クライアント４００、及びリソースサービス連携アプリケーション５００は、仮想マシン８１０上の実行環境にて動作する。また、これらのアプリケーションは、アプリケーション管理フレームワーク８００にてライフサイクル管理されている。

Ｗｅｂブラウザ９００、アプリケーション管理アプリケーション８３０、ローカルログインアプリケーション８４０、及びネットワーク状態定期監視９１０は、画像形成装置３００が予め備えるものとする。一方、認可サーバ連携クライアント４００及びリソースサービス連携アプリケーション５００は、アプリケーション管理アプリケーション８３０およびアプリケーション管理フレームワーク８００を介して後からインストールされるものである。

認可サーバ連携クライアント４００が利用されなくなった場合は、認可サーバ連携クライアント４００は、アプリケーション管理アプリケーション８３０およびアプリケーション管理フレームワーク８００を介してアンインストールされる。アプリケーション管理アプリケーション８３０は、図４（ｄ）に示すＷｅｂブラウザお気に入り管理テーブル１９００から、登録アプリケーション１９０３から認可サーバ連携クライアント４００と合致する情報を削除する（削除アプリケーション）。

次に、画像形成装置３００の外部メモリ３０３に記憶されるテーブル情報について図４（ａ）、図４（ｂ）、図５（ａ）、図５（ｂ）を参照して説明する。

図４（ａ）は、デバイスユーザ管理テーブルの一例を示す図である。

デバイスユーザ管理テーブル１５００は、ユーザＩＤ１５０１、パスワード１５０２、及びＩＣカード情報１５０３から成る。

図３に示すローカルログインアプリケーション８４０が、デバイスユーザ管理テーブル１５００の参照と更新が可能に構成されている。本実施形態では、デバイスユーザ管理テーブル１５００は、画像形成装置３００の外部メモリ３０３に記憶されているが、画像形成装置３００がＬＡＮ１０１を介して通信可能なサーバに格納されている構成であってもよい。

図４（ｂ）は、デバイス管理テーブルの一例を示す図である。

認可サーバ連携クライアント４００のみがデバイス管理テーブル１６００の参照と更新が可能に構成されている。

デバイス管理テーブル１６００は、クライアントＩＤ１６０１、クライアントシークレット１６０２、エンドポイントＵＲＬ１６０３、クライアント名１６０５、クライアント説明１６０６、リダイレクトＵＲＬ１６０７、及びアクセスＵＲＬ１６０８から成る。

クライアントＩＤ１６０１及びクライアントシークレット１６０２は、予め認可サーバ２００にて発行、記憶されたユーザＩＤ１３０１、パスワード１３０２にそれぞれ対応している。さらに、クライアント名１６０５、クライアント説明１６０６、リダイレクトＵＲＬ１６０７、及びアクセスＵＲＬ１６０８は、図８（ｂ）に示す認可サーバ２００のクライアント管理テーブル１４００に格納される。また、クライアント管理テーブル１４００には、クライアントＩＤ１４０１、画像形成装置３００のシリアル番号１４０５と共に登録されている情報と同様のデータが格納されている。

上述したクライアント情報を認可サーバ連携クライアント４００が認可サーバ２００に登録・更新するタイミングは、認可サーバ連携クライアント４００の起動時と認可連携開始時である。

エンドポイントＵＲＬ１６０３は、認可サーバ２００が公開するＯＡｕｔｈのためのエンドポイントのＵＲＬである。アクセスＵＲＬ１６０８は、認可サーバ連携クライアント４００が公開するＷｅｂブラウザからアクセスし、認可開始時にアクセスするＵＲＬと名称である。

図５（ａ）は、親トークン管理テーブルの一例を示す図である。

認可サーバ連携クライアント４００のみが親トークン管理テーブル１７００の参照、更新が可能に構成されている。

親トークン管理テーブル１７００は、ユーザＩＤ１７０１、認可トークンＩＤ１７０２、及びリフレッシュトークンＩＤ１７０３から成る。

図５（ｂ）は、Ｗｅｂブラウザお気に入り管理テーブルの一例を示す図である。

Ｗｅｂブラウザ９００と認可サーバ連携クライアント４００とアプリケーション管理アプリケーション８３０が、Ｗｅｂブラウザお気に入り管理テーブル１９００の参照と更新が可能に構成されている。

Ｗｅｂブラウザお気に入り管理テーブル１９００は、お気に入り名称１９０１、ＵＲＬ１９０２、及び登録アプリケーション１９０３から成る。ここで、お気に入り名称１９０１、ＵＲＬ１９０２、及び登録アプリケーション１９０３の値が登録されるタイミングは、認可サーバ連携クライアント４００の起動時である。Ｗｅｂブラウザお気に入り情報の登録の詳細については後述する。

お気に入り名称１９０１は、Ｗｅｂブラウザ９００によりお気に入りボタンとしてＧＵＩ上に提供される名称である。ＵＲＬ１９０２は、該お気に入りボタンを押下することで、Ｗｅｂブラウザの開始画面として起動するためのエンドポイントとなるＵＲＬである。登録アプリケーション１９０３は、該お気に入りボタンを登録したアプリケーションの名称である。有効／無効フラグ１９０４は、ネットワークの接続状態を識別するためのフラグ（識別情報）である。ネットワーク状態定期監視９１０（監視アプリケーション）によるネットワーク通信状態の監視結果から、ネットワーク接続断状態を認識したときにはフラグを無効とし、ネットワークが使用できない場合は一時的に利用できなくする。ネットワーク接続状態が正常に復旧すれば、該フラグが有効になる。

次に、認可サーバ連携クライアント４００の起動時に認可サーバ２００に対して実行するクライアント情報の登録または更新、Ｗｅｂブラウザお気に入り管理テーブルの生成について説明する。

アプリケーション管理フレームワーク８００は、Ｗｅｂブラウザお気に入り管理テーブル１９００に、登録アプリケーション１９０３が認可サーバ連携クライアント４００と合致する情報を確認する。存在しなければ、アプリケーション管理フレームワーク８００は、認可サーバ連携クライアント４００の存在を確認する。存在すれば、認可サーバ連携クライアント４００を起動し、以下に説明するクライアント情報登録・更新及びＷｅｂブラウザお気に入りの登録の処理を実行する。

図６Ａ及び図６Ｂは、認可サーバ連携クライアント４００起動時のクライアント情報登録・更新及びＷｅｂブラウザお気に入りテーブル生成処理の流れを示すフローチャートである。本実施形態では、特に断りのない限り、画像形成装置上で実行される処理のハード上の主体はＣＰＵ３０１であり、ソフトウェア上の主体は外部メモリ３０３にインストールされたアプリケーションプログラムである。

図６Ａにおいて、アプリケーション管理フレームワーク８００により起動された認可サーバ連携クライアント４００は、画像形成装置３００のデバイス情報を取得する（ステップＳ６０１，Ｓ６０２）。ここで取得するデバイス情報には、プリンタモデル名、プリンタ名、設置場所、シリアル番号が含まれる。

次に、認可サーバ連携クライアント４００は、ステップＳ６０２で取得したデバイス情報を用いてクライアント名とクライアント説明を生成する。生成するクライアント名とクライアント説明は、図４（ｂ）に示すような文字列である。本実施形態では、クライアント名にプリンタモデル名を、クライアント説明にプリンタ名と設置場所を用いている。このクライアント名やクライアント説明は、後述の認可確認画面２００３に表示されるので、画像形成装置３００をユーザが識別できる文字列であることが望ましい。なお、プリンタ名、設置場所はユーザにより任意の値に変更可能であり、変更が行われた場合には合わせてクライアント名、クライアント説明も変更する必要がある。

次に、認可サーバ連携クライアント４００は、画像形成装置３００のアドレス情報取得を行う（ステップＳ６０４）。アドレス情報には、ループバックＩＰｖ４アドレス、ループバックＩＰｖ６アドレスが含まれる。

次に、認可サーバ連携クライアント４００は、ステップＳ６０４において取得したアドレス情報をもとにデバイスブラウザ用リダイレクトＵＲＬを生成する（ステップＳ６０５）。具体的には、認可サーバ連携クライアント４００は、ループバックＩＰｖ４アドレス、ループバックＩＰｖ６アドレスからデバイスブラウザ用リダイレクトＵＲＬをＦＱＤＮ（Ｆｕｌｌｙ Ｑｕａｌｉｆｉｅｄ Ｄｏｍａｉｎ Ｎａｍｅ）として生成する。生成されたデバイスブラウザ用リダイレクトＵＲＬは、図４（ｂ）に示すようなリダイレクトＵＲＬ１６０７となる。本実施形態では、転送プロトコルにｈｔｔｐｓを用いており、デバイスブラウザ用リダイレクトＵＲＬのエンドポイントとしてｒｅｄｉｒｅｃｔ／ｄｅｖｉｃｅとしている。

次に、認可サーバ連携クライアント４００は、デバイス管理テーブル１６００を既に保持しているか判定する（ステップＳ６０６）。デバイス管理テーブル１６００が作成されていないと判定した場合には、ステップＳ６０７に進む一方、デバイス管理テーブル１６００を既に保持していると判定した場合には、図６ＢのステップＳ６１４へ進む。

ステップＳ６０７では、認可サーバ連携クライアント４００は、ステップＳ６０３，Ｓ６０５にて生成したクライアント名、クライアント説明、リダイレクトＵＲＬと、Ｓ６０２にて取得したシリアル番号を用いて認可サーバ２００にクライアント登録要求を行う。そして、クライアント登録要求が成功したかどうかを判定する（ステップＳ６０８）。クライアント登録要求が成功した場合は、ステップＳ６０９へ進む一方、成功していない場合にはステップＳ６１１へ進む。

ステップＳ６０９では、認可サーバ連携クライアント４００は、認可サーバ２００からクライアント登録応答（認証結果）としてクライアントＩＤとクライアントシークレットを受け取る。そして、認可サーバ連携クライアント４００は、クライアントＩＤ、クライアントシークレット、クライアント名、クライアント説明、及びリダイレクトＵＲＬを用いて図４（ｂ）に示すようなデバイス管理テーブル１６００を生成する（ステップＳ６１０）。そして、外部メモリ３０３に保存する（ステップＳ６１０）。さらに認可サーバ連携クライアント４００は、認可サーバ連携クライアント４００が公開するＷｅｂブラウザからアクセスするためのＵＲＬ及びお気に入り名称を生成し、アクセスＵＲＬ１６０８としてデバイス管理テーブル１６００に登録する（ステップＳ６１０）。また、デバイス管理テーブル１６００のエンドポイントＵＲＬ１６０３には、認可サーバ２００のエンドポイントが登録される（ステップＳ６１０）。

図６Ｂにおいて、ステップＳ６１４では、認可サーバ連携クライアント４００は、外部メモリ３０３に保存されているデバイス管理テーブル１６００のクライアント名１６０５、クライアント説明１６０６、及びリダイレクトＵＲＬ１６０７の値を参照する。そして、ステップＳ６０３で生成したクライアント名及びクライアント説明、並びにステップＳ６０５で生成したリダイレクトＵＲＬと比較して変更があるか否かを判定する。なお、クライアント名、クライアント説明に利用するプリンタ名と設置場所は変更可能である。

ステップＳ６１４の判定結果から変更されている場合には、認可サーバ連携クライアント４００は、認可サーバ２００にクライアント更新要求を行う（ステップＳ６１５）。クライアント更新要求には、デバイス管理テーブル１６００のクライアントＩＤ１６０１、クライアントシークレット１６０２を通知する。さらに、ステップＳ６０３，Ｓ６０５で生成したクライアント名、クライアント説明、リダイレクトＵＲＬ、及びステップＳ６０２で取得したシリアル番号を通知する。

次に、認可サーバ連携クライアント４００は、クライアント登録要求が成功したか否かを判定する（ステップＳ６１６）。クライアント更新要求に成功した場合、認可サーバ連携クライアント４００は、クライアント更新要求で通知した情報でデバイス管理テーブル１６００を更新し（ステップＳ６１７）、図６ＡのステップＳ６１１へ移行する。ステップＳ６１６でクライアント登録要求が成功していない場合には、そのまま図６ＡのステップＳ６１１へ進む。

図６Ａにおいて、ステップＳ６１１では、認可サーバ連携クライアント４００は、デバイス管理テーブル１６００にクライアントシークレット１６０２が存在するかを判定する。クライアントシークレット１６０２が存在すると判定した場合は、ステップＳ６１２へ移行する一方、存在しないと判定した場合は本処理を終了する。

ステップＳ６１２では、認可サーバ連携クライアント４００は、デバイス管理テーブル１６００のアクセスＵＲＬ１６０８の情報を取得する。そして、取得したアクセスＵＲＬ１６０８を含むお気に入り情報をＷｅｂブラウザお気に入り管理テーブル１９００に登録し（ステップＳ６１３）、本処理を終了する。なお、図６には図示されていないが、画像形成装置３００は、ステップＳ６１３で登録されたお気に入り情報に基づいて、図１０に示すようなお気に入りアクセスボタン２９０６が配置された初期画面２９００を表示する。図１０に示す初期画面２９００上のお気に入りアクセスボタン９０６は、認可サーバ２００の認証サービスに認証を依頼した認可トークンを発行してもらうためのＵＲＬにアクセスするショートカットボタンである。

次に、画像形成装置３００にログインした状態でＷｅｂブラウザ９００を用いてユーザが権限移譲する方法について図７、図８（ａ）〜図８（ｃ）、図９（ａ）〜図８（ｃ）を参照して説明する。

図７は、画像形成装置３００から認可サーバ２００に対して認可を行う流れを示すシーケンス図である。図示のシーケンスは、ユーザが画像形成装置３００を最初に利用する際に、画像形成装置３００のＷｅｂブラウザを用いて一度だけ行われる。

まず、ローカルログインアプリケーション８４０が提供する入力画面上からユーザが画像形成装置３００にログインする（Ｓ７０１）。そして、ローカルログインアプリケーション８４０は、ログインしたユーザのユーザＩＤを含むログインコンテキストを生成する（Ｓ７０２）。

図１０に示す初期画面２９００上のお気に入りアクセスボタン９０６が押下されると、Ｗｅｂブラウザ９００から認可サーバ連携クライアント４００に認可連携を開始するためのＵＲＬへアクセスする指示を行う（Ｓ７０３）。ここで、Ｗｅｂブラウザ９００は、図９（ａ）に示すような認可連携開始画面２００１を表示する。そして、Ｗｅｂブラウザ９００からの指示に応じてログインアプリケーション特定を行う（Ｓ７０４）。そして、認可サーバ連携クライアント４００は、デバイス情報更新要否の判断を行い（Ｓ７０５）、デバイス情報更新が必要な場合には、認可サーバ２００にデバイス情報更新要求を行う。

次に、Ｗｅｂブラウザ９００は、デバイス管理テーブル１６００のエンドポイントＵＲＬ１６０３に記載のＵＲＬ（ここでは認可サーバ２００のＵＲＬ）に対して、ＯＡｕｔｈの認可リクエストを行う（Ｓ７０８）。この認可リクエストには、デバイス管理テーブル１６００のクライアントＩＤ１６０１、リダイレクトＵＲＬ１６０７の情報が含まれる。認可リクエストに含まれるリダイレクトＵＲＬはデバイスブラウザ用リダイレクトＵＲＬであり、Ｓ７０３において受け付けたリクエストのＦＱＤＮと一致するＵＲＬを用いる。また、ＯＡｕｔｈでは、認可を受けたい権限範囲を示すスコープを認可リクエストに含むよう構成することもできる。本実施形態では、スコープとしてスコープＡがリクエストされたものとして説明する。

認可リクエストを受け付けた認可サーバ２００は、ユーザ認証を行うために、図９（ｂ）に示すログイン画面２００２を生成してＷｅｂブラウザ９００に表示するように応答する（Ｓ７０９）。ユーザはＷｅｂブラウザ９００に表示されたログイン画面１２０２に対して、ユーザＩＤ及びパスワードを入力してログインを実行する（Ｓ７１０）。

認可サーバ２００は、受け付けたユーザＩＤとパスワードの組が図８（ａ）に示すユーザ管理テーブル１３００に登録されている情報と合っているかを判定し、合っている場合はユーザＩＤに紐づいた認証情報を生成して次の処理を実行する。そして、認可サーバ２００は、認可リクエストに含まれているクライアントＩＤとリダイレクトＵＲＬの組みが、図８（ｂ）に示すクライアント管理テーブル１４００に登録されている情報と合っているか検証する。検証の結果が正しければ、認可サーバ２００は、クライアント管理テーブル１４００のクライアント名１４０２、クライアント説明１４０３を取得し、図９（ｃ）に示す認可確認画面２００３を生成してＷｅｂブラウザ９００に表示するように応答する（Ｓ７１１）。その際、認証情報をＷｅｂブラウザ９００に対してＣｏｏｋｉｅ情報として格納して応答する。なお、本実施形態では、認可確認画面２００３にクライアント名１４０２、クライアント説明１４０３を表示するようにしたが、ログインしているユーザの情報を表示するよう構成することもできる。

次に、ユーザがＷｅｂブラウザ９００に表示された認可確認画面２００３で許可を選択すると（Ｓ７１２）、許可を受けた認可サーバ２００は次の処理を実行する。まず、認可サーバ２００は、認可トークン管理テーブル１８００に認可コードを発行して登録する。その際、認可トークンＩＤ１８０１に発行したトークンのＩＤ、トークン種別１８０２に認可コード、有効期限１８０３をユーザＩＤ１８０８に登録する。そして、認可リクエスト時に受け付けたクライアントＩＤをクライアントＩＤ１８０７、Ｗｅｂブラウザ９００からＣｏｏｋｉｅとして送信された認証情報に紐づくユーザＩＤをユーザＩＤ１８０８に登録する。そして、認可応答として、認可コードの認可トークンＩＤを付与したリダイレクトＵＲＬ（ここでは認可サーバ連携クライアント４００）に対してＷｅｂブラウザ９００を認可応答（リダイレクト要求）する（Ｓ７１３）。

認可応答を受けた認可サーバ連携クライアント４００は、認可サーバ２００に対してトークン要求を行う（Ｓ７１４）。このトークン要求には、認可応答で取得した認可コードの認可トークンＩＤ、図４（ｂ）に示すデバイス管理テーブル１６００のクライアントＩＤ１６０１、クライアントシークレット１６０２、リダイレクトＵＲＬ１６０７を含む。

トークン要求を受けた認可サーバ２００は以下の検証を行い、正しい場合は親トークンを生成する（Ｓ７１５）。すなわち、認可サーバ２００は、トークン要求で受けつけたクライアントＩＤ、クライアントシークレットの組が、図８（ａ）に示すユーザ管理テーブル１３００に登録されているユーザＩＤ１３０１、パスワード１３０２の組と合っているか検証する。次に、認可サーバ２００は、トークン要求で受けつけた認可コードの認可トークンＩＤが、図８（ｃ）に示す認可トークン管理テーブル１８００に登録されているか、有効期限内かを検証する。そして、トークン要求で受けつけたクライアントＩＤとリダイレクトＵＲＬがそれぞれ認可トークン管理テーブル１８００の認可トークンＩＤで特定されるクライアントＩＤ１８０７とリダイレクトＵＲＬ１４０４と合っているかを検証する。ここで、リダイレクトＵＲＬ１４０４は、クライアント管理テーブル１４００ではなく、認可トークン管理テーブル１８００にカラムを追加し、認可コード発行時に登録して、該追加カラムと検証するよう構成することもできる。

上述した全ての検証が正しい場合には、認可サーバ２００は、親トークンを生成して、親トークンの認可トークンＩＤを認可サーバ連携クライアント４００に応答する（Ｓ７１６）。このときの応答には、同時に発行したリフレッシュトークンＩＤも含まれる。親トークンとしては、認可トークンＩＤ１８０１に発行したトークンのＩＤ、トークン種別１８０２に親トークン、有効期限１８０３、および、認可コードから引き継ぐ情報として、クライアントＩＤ１８０７、ユーザＩＤ１８０８が登録される。親トークンをリフレッシュするためのリフレッシュトークンＩＤが、認可トークン管理テーブル１８００のリフレッシュトークンＩＤ１８０５、リフレッシュ期限１８０６に登録される。

親トークンの認可トークンＩＤ、リフレッシュトークンＩＤを取得した認可サーバ連携クライアント４００は、ローカルログインアプリケーション８４０から取得したログインコンテキストからデバイスユーザＩＤを取得する。そして、認可サーバ連携クライアント４００は、図５（ａ）に示す親トークン管理テーブル１７００に、デバイスユーザＩＤ、親トークンの認可トークンＩＤ、及びリフレッシュトークンＩＤを格納する（Ｓ７１７）。

次に、認可サーバ連携クライアント４００は、認可連携完了の旨を示す画面（不図示）をＷｅｂブラウザ９００に応答し（Ｓ７１８）、本処理を終了する。

本実施形態では、リソースサービスを利用するリソースサービス連携アプリケーション５００が画像形成装置３００に追加インストールされた場合に、認可サーバ連携クライアント４００を起動する。これにより、必要なケースに限定してお気に入りアクセスボタンを提供することが可能となる。また、ＵＲＬの入力の手間も省ける。

次に、認可サーバ２００の外部メモリ２４１に記憶されるテーブル情報について図８（ａ）〜図８（ｃ）を参照して説明する。なお、図示のテーブル情報は、認可サーバ２００の外部メモリ２４１ではなく、ＬＡＮ１０１を介して通信可能に構成された別のサーバ（不図示）に記憶するよう構成してもよい。

図８（ａ）は、ユーザ管理テーブルの一例を示す図である。

ユーザ管理テーブル１３００は、ユーザＩＤ１３０１、パスワード１３０２、及びユーザ種別１３０３から成る。認可サーバ２００は、ユーザＩＤ１３０１とパスワード１３０２の組を利用して、ユーザにより入力されたユーザＩＤとパスワードを判定し、正しければユーザＩＤに紐づいた認証情報を生成することで、各ユーザまたは各クライアントを認証する機能を備える。

図８（ｂ）は、クライアント管理テーブルの一例を示す図である。

クライアント管理テーブル１４００は、クライアントＩＤ１４０１、クライアント名１４０２、クライアント説明１４０３、リダイレクトＵＲＬ１４０４、及びシリアル番号１４０５から成る。

クライアントＩＤ１４０１は、ユーザ管理テーブル１３００のユーザＩＤ１３０１と関連付いており、互いに参照可能となっている。クライアント名１４０２、クライアント説明１４０３、及びリダイレクトＵＲＬ１４０４は、後述のＯＡｕｔｈのシーケンスで利用される値である。シリアル番号１４０５は、クライアントが画像形成装置等のデバイスである場合に登録される値であり、画像形成装置をユニークに識別可能な値である。

図８（ｃ）は、認可トークン管理テーブルの一例を示す図である。

認可トークン管理テーブル１８００は、認可トークンＩＤ１８０１、トークン種別１８０２、有効期限１８０３、スコープ１８０４、リフレッシュトークンＩＤ１８０５、リフレッシュ期限１８０６、クライアントＩＤ１８０７、及びユーザＩＤ１８０８から成る。

上記実施形態によれば、認可サーバに画像形成装置の認証を要求し、認証を要求された認可サーバから認証結果を受信する。そして、受信した認証結果が成功を示す場合に認可サーバのＵＲＬを含むお気に入り情報を登録し、該お気に入り情報に基づいてＷｅｂブラウザにより認可サーバにアクセスするためのボタンを表示する。これにより、画像形成装置がサーバにアクセスするためのアクセスボタンをＷｅｂブラウザ上に容易に作成することができ、ユーザがデバイス上のＷｅｂブラウザでＵＲＬを入力することなく、操作を簡略化することができる。

［第２の実施形態］
本発明の第２の実施の形態では、図１〜図２に示す構成が上記第１の実施の形態と同じであり、第１の実施の形態と同様の部分については、同一の符号を用いてその説明を省略する。以下に、上記第１の実施の形態と異なる点のみを説明する。

図１０は、本発明の第２の実施形態に係る画像形成装置の操作部に表示される初期画面の一例を示す図である。

図１０において、初期画面（メインメニュー）２９００は、ＣＰＵ３０１により操作部３１１に表示される初期画面である。初期画面２９００は、画像形成装置３００の電源ＯＮ時に最初に表示される。なお、以下の説明では、画像形成装置３００の電源をＯＮしてから、操作部３１１にユーザが操作可能な画面として最初に表示される画面を初期画面と呼ぶこととする。

また、初期画面２９００は、画像形成装置内に存在するアプリケーション（以下、単に「アプリ」とする）にアクセスするためのポータル画面になっている。そのため、コピーアプリやセンドアプリなどの各種アプリにアクセスするためのアプリボタンが表示されている。

さらに、初期画面２９００には、Ｗｅｂブラウザ９００のお気に入りリストのＵＲＬにアクセスするためのボタン（以下、「お気に入りアクセスボタン」と呼ぶ）も表示可能である。

初期画面２９００には、コピーアプリの画面に表示を切り替えるコピーボタン２９０１が表示されている。また、初期画面２９００には、センドアプリの画面に表示を切り替えるセンドボタン２９０２も表示されている。また、初期画面２９００には、Ｗｅｂブラウザ９００の画面に表示を切り替えるＷｅｂブラウザボタン２９０３も表示されている。さらに、初期画面２９００には、Ｗｅｂブラウザ９００のお気に入りリストに登録されている各ＵＲＬにアクセスするためのお気に入りアクセスボタン２９０４，２９０５，２９０６も表示されている。

次に、お気に入りアクセスボタン２９０５を押下したときに表示される画面の説明を行う。なお、お気に入りアクセスボタン２９０５には、センドアプリが指定するＷｅｂコンテンツへのＵＲＬが対応づけて記憶されている。このＷｅｂコンテンツは、センドアプリで送信を行う際に必要なＩＤとパスワードを登録するためのＷｅｂコンテンツとする。このＷｅｂコンテンツは、センドアプリが削除もしくは停止されている場合にはアクセスできない。

お気に入りアクセスボタン２９０５が押下されると、図１１に示すＷｅｂブラウザ画面１０００に表示が切り替わる。すなわち、お気に入りアクセスボタン２９０５に対応づけられたＵＲＬのＷｅｂコンテンツが表示される。

図１１に示すＷｅｂブラウザ画面１０００は、タイトル表示領域１００１、Ｗｅｂコンテンツ表示領域１００２、設定項目表示領域１００３から構成されている。

タイトル表示領域１００１は、Ｗｅｂコンテンツ表示領域１００２に表示するＷｅｂコンテンツを表すタイトル文字列が表示される領域である。

Ｗｅｂコンテンツ表示領域１００２は、特定のＵＲＬに対応するＷｅｂコンテンツを取得し、このＷｅｂコンテンツをＷｅｂページとして表したものが表示される領域である。Ｗｅｂコンテンツは、ＨＴＭＬ（ＨｙｐｅｒＴｅｘｔ ｍａｒｋｕｐ Ｌａｎｇｕａｇｅ）などで記載されている。このＨＴＭＬの解釈や、解釈した結果をもとにＷｅｂページを表示する処理は、一般的なＷｅｂブラウザと同じであるため、詳細の記載は省略する。なお、お気に入りアクセスボタンが押下された場合、ここでの特定のＵＲＬとは、お気に入りアクセスボタンに対応づけられたＵＲＬアドレスとなる。また、図１０に示すＷｅｂブラウザボタン２９０３が押下されてＷｅｂブラウザ画面に切り替わった場合、Ｗｅｂコンテンツ表示領域１００２には何も表示されないこととする。

設定項目表示領域１００３は、Ｗｅｂブラウザに関する設定項目が表示される領域であり、ここには１００４〜１０１３の設定項目を表すボタンが表示される。これらのボタンの説明を行う。

１００４は戻るボタンである。このボタンが押下されると、Ｗｅｂコンテンツ表示領域１００２に表示したＷｅｂコンテンツを、表示した順番とは逆に過去に遡って表示させることができる。

１００５は進むボタンである。このボタンが押下されると、戻るボタン１００４で過去に表示したＷｅｂコンテンツを表示した後、表示した順番にＷｅｂコンテンツを再度表示させることができる。

１００６は中止ボタンである。このボタンが押下されると、Ｗｅｂサーバ（リソースサーバ２１０等）からＷｅｂコンテンツを読み込んでいる最中に、そのＷｅｂコンテンツの読み込みを中断させることができる。

１００７は再読み込みボタンである。このボタンが押下されると、Ｗｅｂコンテンツ表示領域１００２に現在表示されているＷｅｂコンテンツを再度Ｗｅｂサーバから再取得して表示させることができる。

１００８はホームボタンである。画像形成装置３００の外部メモリ３０３には予め決められた１つのＵＲＬがホームアドレスとして登録されている。このホームボタンが押下されると、このホームアドレスのＷｅｂコンテンツをワンタッチ操作でＷｅｂコンテンツ表示領域１００２に表示させることができる。

１００９は印刷ボタンである。このボタンが押下されると、Ｗｅｂコンテンツ表示領域１００２に現在表示しているＷｅｂコンテンツを印刷するための印刷指示画面が表示される。

１０１０は、お気に入りボタンである。このボタンが押下されると、外部メモリ３０３に格納されているお気に入りリストのＵＲＬ（アクセス先）の中から、ユーザが所望するＵＲＬを選択する画面が表示される。この画面においてＵＲＬが選択されると、そのＵＲＬのＷｅｂコンテンツを取得してＷｅｂコンテンツ表示領域１００２に表示させることができる。なお、お気に入りボタン１０１０が押下されて表示されるＵＲＬは、通常お気に入りリストのＵＲＬのみであり、後述する一時お気に入りのＵＲＬは表示されない（非表示）。

１０１１はメニューボタンである。このボタンが押下されると、Ｗｅｂブラウザに関する様々な設定（表示や印刷や動作に関する設定）を行うための画面が表示される。

１０１２は、ＵＲＬ入力および表示ボタン（以下、「ＵＲＬボタン」と呼ぶ）である。Ｗｅｂコンテンツ表示領域１００２に現在表示しているＷｅｂページのＷｅｂコンテンツ格納先を示すＵＲＬが、このボタン上に表示される。ここでは、「ｈｔｔｐ：／／１２７．０．０．１／ｓｅｎｄ／ＩＤ．ｈｔｍｌ」というＵＲＬが表示されている。

また、ＵＲＬボタン１０１２をユーザが押下することで、ＵＲＬを手入力で入力するためのソフトキーボード画面が表示される（不図示）。ここで、ユーザが所望するＵＲＬを入力すると、そのアドレスがＵＲＬボタン上に表示されると共に、Ｗｅｂコンテンツ表示領域１００２にＷｅｂコンテンツをＷｅｂページとして表示させることができる。

１０１３は、ＵＲＬ入力履歴表示ボタンである。このボタンが押下されると、ＵＲＬボタン１０１２において、ユーザが過去に入力したＵＲＬを指定する画面が表示される（不図示）。ここで、過去に入力したＵＲＬを指定することができる。

次に、操作部３１１に初期画面２９００を表示するための処理を図１２を用いて説明する。

図１２は、操作部３１１に初期画面２９００を表示するための処理の流れを示すフローチャートである。

画像形成装置３００の電源ＯＮを検知すると、ＣＰＵ３０１は、起動処理として外部メモリ３０３に格納されているプログラムを読み出してステップＳ１１０１〜Ｓ１１０９の処理を行う。

まず、ＣＰＵ３０１は、外部メモリ３０３に格納されている起動アプリテーブルを参照し、起動するアプリが存在するかを判定する（ステップＳ１１０１）。起動アプリテーブルとは、画像形成装置３００で起動可能なアプリの名称と、このアプリが初期画面２９００に表示するボタン情報と、このアプリが指定するＷｅｂコンテンツ情報とが関連付けられたテーブルである。ボタン情報は、初期画面２９００のボタン上に表示する文言と、ボタン上に表示する画像情報とからなる。Ｗｅｂコンテンツ情報は、アプリが初期画面２９００にお気に入りアクセスボタンを表示する情報である。このＷｅｂコンテンツ情報は、ＷｅｂコンテンツのＵＲＬと、初期画面２９００のお気に入りアクセスボタン上に表示する文言と、画像情報とからなる。例えば、図１３（ａ）に示すセンドアプリの場合、ボタン情報をもとにして初期画面２９００に図１０に示すセンドボタン２９０２が表示され、Ｗｅｂコンテンツ情報をもとにして初期画面２９００にお気に入りアクセスボタン２９０５が表示される。

なお、ユーザが初期画面２９００でお気に入りアクセスボタン２９０５を押下すると、図１１に示すＷｅｂコンテンツ表示領域１００２に「ｈｔｔｐ：／／１２７．０．０．１／ｓｅｎｄ／ＩＤ．ｈｔｍｌ」のＷｅｂコンテンツが表示される。また、ボタン情報もしくはＷｅｂコンテンツ情報の文言は、タイトル表示領域１００１にも表示される。また、ボタン情報もしくはＷｅｂコンテンツ情報の画像は、一般的なお気に入りのＦａｖｉｃｏｎの画像と同じ役割をもつ。

ステップＳ１１０１で起動するアプリが存在すると判定した場合（ステップＳ１１０１でＹＥＳ）、ＣＰＵ３０１は、起動アプリテーブルを参照し、ボタン情報が存在するかどうかの判定を行う（ステップＳ１１０２）。ボタン情報が存在すると判定した場合、ＣＰＵ３０１は、起動アプリテーブルからこのアプリに対応するボタン情報を取得し、これをもとに初期画面２９００にボタンを表示する（ステップＳ１１０３）。一方、ボタン情報が存在しないと判定した場合は、ステップＳＳ１１０４へ進む。なお、起動アプリテーブルの情報をもとに、初期画面２９００にボタンを表示する処理は、一般的な処理と同じであるため、詳細な説明は省略する。

ステップＳ１１０４では、ＣＰＵ３０１は、起動アプリテーブルを参照し、Ｗｅｂコンテンツ情報が存在するかどうかを判定する。Ｗｅｂコンテンツ情報が存在しないと判定した場合はステップＳ１１０１に戻る。一方、Ｗｅｂコンテンツ情報が存在すると判定した場合、ステップＳ１１０５へ進む。

ステップＳ１１０５では、ＣＰＵ３０１は、起動するアプリがＷｅｂブラウザ９００かどうかを、起動アプリテーブルをもとに判定する（アプリ判定手段の一例）。これは、ＷｅｂブラウザのＷｅｂコンテンツ情報は、お気に入りリストのことであり、Ｗｅｂブラウザ以外の他のアプリのＷｅｂコンテンツからなる一時お気に入りの処理とは、異なる処理を行うためである。以降では、Ｗｅｂブラウザのもつお気に入りリストを、通常お気に入りリスト（第１のお気に入り情報）と呼ぶ。

まず、起動するアプリがＷｅｂブラウザではない場合（ステップＳ１１０５がＮＯの場合）の処理を説明する。

ＣＰＵ３０１は、起動アプリテーブルを参照し、起動するアプリのＷｅｂコンテンツ情報を一時お気に入りリスト（第２のお気に入り情報）に登録する（ステップＳ１１０７）。ここで、一時お気に入りリストについて説明する。

一時お気に入りリストは、通常お気に入りリストに登録されるお気に入りと同じ情報（ＵＲＬ、文言、画像の情報）をもつ。ただし、この一時お気に入りリストは、ＲＡＭ３０８に格納されるお気に入りリストであり、画像形成装置３００の電源ＯＦＦにより消去される。そのため、画像形成装置３００の電源をＯＮにした最初の状態では、一時お気に入りリストには何も登録されていない。また、この一時お気に入りは、Ｗｅｂブラウザ画面上のお気に入りボタン４１０を押下しても表示されないこととする（お気に入りボタン４１０で表示するのは、通常お気に入りリストのみとする）。

ステップＳ１１０７の後、ＣＰＵ３０１は、Ｗｅｂブラウザ９００を既に起動済みかどうかを確認する（ステップＳ１１０８）。Ｗｅｂブラウザ９００を起動済みの場合、ＣＰＵ３０１は、起動アプリテーブルのこのアプリのＷｅｂコンテンツ情報をもとに、初期画面２９００にお気に入りアクセスボタンを表示する（ステップＳ１１０９）。一方、Ｗｅｂブラウザ９００を起動していない場合、ステップＳ１１０１に戻る。なお、Ｗｅｂブラウザ９００を起動していない場合には、ステップＳ１１０９の表示処理を行わないのは、Ｗｅｂブラウザ９００を起動するときに一時お気に入りリストをまとめて表示する（ステップＳ１１０６）ためである。

次に、起動するアプリがＷｅｂブラウザの場合（ステップＳ１１０５がＹＥＳの場合）の処理を説明する。

ＣＰＵ３０１は、外部メモリ３０３に格納されている通常お気に入りリストと、ＲＡＭ３０８に格納されている一時お気に入りリストの各ＵＲＬを、お気に入りアクセスボタンとして初期画面２９００に表示する（ステップＳ１１０６）。そして、ステップＳ１１０１に戻る。ＣＰＵ３０１は、起動アプリテーブルを参照し、起動していないアプリがある場合は、ステップＳ１１０２〜１１０９の処理を繰り返す。そして、起動していないアプリが存在しなくなった場合（ステップＳ１１０１がＮＯの場合）、ＣＰＵ３０１は、本処理を終了する。なお、図１３（ａ）に示す起動アプリテーブルの場合、これらの起動処理を行うことで初期画面２９００を表示する。

上記のように、起動時に各アプリのＷｅｂコンテンツ情報を一時お気に入りリストに登録して表示することで、ユーザの手入力なしにＷｅｂコンテンツにアクセス可能となる。これにより、ユーザの入力の手間や誤入力を防ぐことができる。

次に、画像形成装置３００の電源をＯＦＦにしたときの処理について説明する。

画像形成装置３００の電源ＯＦＦを電源管理部１２１で検知すると、ＣＰＵ３０１は、ＲＡＭ３０８に格納されている一時お気に入りリストが存在するかどうかを確認し、存在する場合はこのリストを削除する。例えば、図１３（ａ）に示す起動アプリテーブルの場合、図１２に示す起動処理により、一時お気に入りリストにはセンドアプリとＷｅｂブラウザ９００のＷｅｂコンテンツ情報が登録されている。ここでセンドアプリを削除もしくは停止すると、起動アプリテーブルは図１３（ｂ）となる。この状態で、画像形成装置３００の電源をＯＦＦし、次に当該電源をＯＮにすると、図１２に示す起動処理により、図１４に示す初期画面が操作部３１１に表示される。図１４と図１０を比べると、図１４ではセンドアプリに対応するセンドボタン２９０２とお気に入りアクセスボタン２９０５が表示されていない。

このように、画像形成装置３００の電源ＯＦＦ時に一時お気に入りリストを削除することで、次に画像形成装置３００の電源がＯＮにしたときに、アクセスできないお気に入りアクセスボタンが初期画面に表示されることはない。これにより、ユーザの操作性を向上することができる。

なお、図１３（ａ）及び図１３（ｂ）に示す起動アプリテーブルでは、ボタン情報とＷｅｂコンテンツ情報は、それぞれ１つしか存在しない場合になっているが、複数存在していても上述の処理を行うことができる。

［第３の実施形態］
第１の実施形態では、起動アプリテーブルを参照し、Ｗｅｂブラウザ以外のアプリに対応づけられているＷｅｂコンテンツ情報は、すべて一時お気に入りリストに登録していた。しかし、常にアクセス可能なＷｅｂコンテンツの場合、一時お気に入りリストではなく、通常お気に入りリストに登録してもよい。

本実施例では、特定の条件を満たす場合、Ｗｅｂブラウザ以外のアプリに対応づけられているＷｅｂコンテンツ情報を、通常お気に入りリストに登録する実施形態を、図１５を用いて説明する。なお、基本的な処理や制御は第１の実施形態と同じであるため、第１の実施形態と異なる点のみを説明する。

図１５は、本発明の第３の実施形態に係る初期画面の表示処理の流れを示すフローチャートである。

図１５において、ステップＳ１１０５では、起動するアプリがＷｅｂブラウザではない場合、常にアクセス可能なＷｅｂコンテンツかどうかの判定を行う（ステップＳ１４０１〜Ｓ１４０４）。この判定処理の説明を行う。

ステップＳ１４０１では、ＣＰＵ３０１は、外部メモリ３０３の起動アプリテーブルを参照する。そして、起動するアプリのＷｅｂコンテンツ情報のＵＲＬが、外部メモリ３０３に格納されている通常お気に入りリストのいずれかのＵＲＬと類似するかどうかを判定する（ステップＳ１４０１）。例えば、起動するアプリのＷｅｂコンテンツ情報のＵＲＬが、通常お気に入りリストのＵＲＬと一致する、もしくはＵＲＬのホスト名が同じである場合に、類似すると判断する。

ステップＳ１４０１で類似しないと判断した場合、ＣＰＵ３０１は、第１の実施形態と同じく、ステップＳ１１０７〜Ｓ１１０９の処理を行う。一方、類似すると判断した場合、ＣＰＵ３０１は、このＷｅｂコンテンツ情報を通常お気に入りリストに登録する（ステップＳ１４０２）。この後、ＣＰＵ３０１は、第１の実施形態と同じく、Ｗｅｂブラウザ９００が起動済みかどうかの確認を行う（ステップＳ１４０３）。この結果、Ｗｅｂブラウザ９００が起動している場合、第１の実施形態と同じく、通常お気に入りリストに追加したこのアプリのＷｅｂコンテンツ情報を、お気に入りアクセスボタンとして初期画面に表示する（ステップＳ１４０４）。一方、Ｗｅｂブラウザ９００が起動していない場合、第１の実施形態と同じく、何も処理を行わずにこのアプリの起動処理を終了する（ステップＳ１１０１に戻る）。

このように、通常お気に入りリストに登録されているＵＲＬと類似する場合、常にアクセス可能なＷｅｂコンテンツとみなし、通常お気に入りリストに登録することができる。これにより、ユーザが手作業で通常お気に入りリストにお気に入りを登録する手間がなくなり、操作性が向上する。

上記実施形態では、図１５のステップＳ１４０１の類似判定において、ＵＲＬを用いたが、別の判定方法を用いてもよい。例えば、起動アプリテーブルの文言や画像情報などの別の情報を用いて類似判定を行うことが可能である。

また、本発明は、以下の処理を実行することによっても実現される。即ち、上述した実施形態の機能を実現するソフトウェア（プログラム）を、ネットワーク又は各種記憶媒体を介してシステム或いは装置に供給し、そのシステム或いは装置のコンピュータ（またはＣＰＵやＭＰＵ等）がプログラムを読み出して実行する処理である。

２００ 認可サーバ
３００ 画像形成装置
４００ 認可サーバ連携クライアント
５００ リソースサービス連携アプリケーション
８３０ アプリケーション管理アプリケーション
９００ Ｗｅｂブラウザ
１５００ デバイスユーザ管理テーブル
１６００ デバイス管理テーブル
１７００ 親トークン管理テーブル
１９００ Ｗｅｂブラウザショートカット管理テーブル

Claims (9)

1. サーバとネットワークを介して通信可能な画像形成装置であって、
   前記サーバに前記画像形成装置の認証を要求する要求手段と、
   前記画像形成装置の前記認証に関する処理が成功したか否かを判断する判断手段と、
   前記判断手段により前記画像形成装置の前記認証に関する処理が成功したと判断された場合に前記サーバにアクセスするためのボタンを表示し、前記判断手段により前記画像形成装置の前記認証に関する処理が失敗したと判断された場合に前記ボタンを表示しない制御を行う制御手段と、を有し、
   前記ボタンへの指示が行われた場合にブラウザによる前記サーバへのアクセスが行われることを特徴とする画像形成装置。
2. 前記ボタンへの指示が行われた場合にブラウザによる前記サーバへのアクセスが行われ、ユーザ認証をするためのログイン画面が表示されることを特徴とする請求項１に記載の画像形成装置。
3. 前記サーバからパスワードを取得する取得手段を有し、
   前記判断手段はさらに前記取得手段により取得された前記パスワードが存在するか否かを判断し、
   前記制御手段は前記判断手段により前記パスワードが存在すると判断された場合に前記サーバにアクセスするためのボタンを表示し、前記判断手段により前記パスワードが存在しないと判断された場合に前記ボタンを表示しない制御を行うことを特徴とする請求項１又２に記載の画像形成装置。
4. 前記制御手段は前記サーバにアクセスするための前記ボタンを、コピー機能を利用するためのコピーボタンと共にメニュー画面に表示する制御を行うことを特徴とする請求項１乃至３のいずれか１項に記載の画像形成装置。
5. サーバとネットワークを介して通信可能な画像形成装置の制御方法であって、
   前記サーバに前記画像形成装置の認証を要求する要求工程と、
   前記画像形成装置の前記認証に関する処理が成功したか否かを判断する判断工程と、
   前記判断工程で前記画像形成装置の前記認証に関する処理が成功したと判断された場合に前記サーバにアクセスするためのボタンを表示し、前記判断工程で前記画像形成装置の前記認証に関する処理が失敗したと判断された場合に前記ボタンを表示しない制御を行う制御工程と、を有し、
   前記ボタンへの指示が行われた場合にブラウザによる前記サーバへのアクセスが行われることを特徴とする画像形成装置の制御方法。
6. サーバとネットワークを介して通信可能な画像形成装置の制御方法をコンピュータに実行させるプログラムであって、
   前記画像形成装置の制御方法は、
   前記サーバに前記画像形成装置の認証を要求する要求工程と、
   前記画像形成装置の前記認証に関する処理が成功したか否かを判断する判断工程と、
   前記判断工程で前記画像形成装置の前記認証に関する処理が成功したと判断された場合に前記サーバにアクセスするためのボタンを表示し、前記判断工程で前記画像形成装置の前記認証に関する処理が失敗したと判断された場合に前記ボタンを表示しない制御を行う制御工程と、を有し、
   前記ボタンへの指示が行われた場合にブラウザによる前記サーバへのアクセスが行われることを特徴とするプログラム。
7. 前記ボタンへの指示が行われた場合にブラウザによる前記サーバへのアクセスが行われ、ユーザ認証をするためのログイン画面が表示されることを特徴とする請求項６に記載のプログラム。
8. 前記画像形成装置の制御方法は、前記サーバからパスワードを取得する取得工程を有し、
   前記判断工程はさらに前記取得工程で取得された前記パスワードが存在するか否かを判断し、
   前記制御工程は前記判断工程で前記パスワードが存在すると判断された場合に前記サーバにアクセスするためのボタンを表示し、前記判断工程で前記パスワードが存在しないと判断された場合に前記ボタンを表示しない制御を行うことを特徴とする請求項６又７に記載のプログラム。
9. 前記制御工程は前記サーバにアクセスするための前記ボタンを、コピー機能を利用するためのコピーボタンと共にメニュー画面に表示する制御を行うことを特徴とする請求項６乃至８のいずれか１項に記載のプログラム。

Images