JP6177020B2 - 認証システム、その制御方法、サービス提供装置およびコンピュータプログラム - Google Patents

Description

本発明は、認証システム、その制御方法、サービス提供装置およびコンピュータプログラムに関する。

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

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

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

画像形成装置がＯＡｕｔｈを利用してプリントサーバと連携する場合、ユーザが画像形成装置にプリントサーバの印刷ジョブへのアクセスする権限を移譲する。これにより、画像形成装置はプリントサーバの印刷ジョブの印刷データをダウンロードし、印刷を実行することができる。

また、複数のユーザが共有して画像形成装置を使用する場合、画像形成装置は複数ユーザの印刷ジョブをキューイングして制御する必要がある。この場合、画像形成装置への権限移譲をユーザ毎に行う際、画像形成装置はキューイングしている印刷ジョブ毎にトークンを保持する。

ここで、画像形成装置は、キューイングされた印刷ジョブを順次実行することで印刷処理を行うが、用紙切れなどによって印刷が実行されない場合、キューイングされている後続の印刷ジョブは待ち状態となる。一般的に、トークンは、不正利用を防ぐため有効期限が設けられており、長時間印刷が行われなければトークンの有効期限が切れることがある。有効期限が切れると、画像形成装置はプリントサーバから印刷データをダウンロードすることができない。画像形成装置はユーザ権限のトークンを更新することができないため、プリントサーバからの印刷データのダウンロードをユーザ権限ではなく、画像形成装置のプリンタ権限で実行することが考えられる。画像形成装置は有効期限が切れた場合でも、プリンタ権限が用いれば、トークンを更新し印刷を継続することが可能となる。

しかしながら、プリンタ権限により発行されたトークンを用いて印刷データをダウンロードする場合、プリンタ情報やユーザ情報はプリントサーバに送信されない。従って、悪意のある第三者がプリンタ権限により発行されたトークンを使用して、他ユーザの印刷データをダウンロードする可能性がある。結果、他ユーザの情報が漏洩し、セキュリティが確保されない。

特許文献１は、トークンを作成する第１の共通鍵と画像形成装置のデバイスＩＤを識別する第２の共通鍵を用いることによりセキュアに画像形成装置を特定するシステムを開示している。しかしながら、共通鍵が漏洩した場合にすべての印刷データに不正アクセスされるためセキュリティリスクが大きい。特許文献２は、サーバがユーザと関連付けてデバイス識別子を保持し、ユーザログイン時にデバイス識別子の検証を行うことで不正アクセスを防止することができる。しかしながら、ユーザがログインしない場合の不正アクセスを防ぐことはできない。

本発明は、印刷を実行する画像形成装置だけが認証によってプリントサーバから印刷データを取得する仕組みにより、不正ダウンロードを防止する認証システムを提供することを目的とする。

本発明の一実施形態の認証システムは、サービスを提供するサービス提供装置と、前記サービス提供装置が認証情報を求めることなくサービスを提供するために利用される認可情報を管理する認可サービス装置とを含む。前記認証システムは、前記認証システムと連携する情報処理装置の識別情報を前記サービス提供装置に登録する登録手段と、前記情報処理装置に対応する前記認可情報の発行に伴い、前記認可情報と前記情報処理装置の識別情報を紐付けて前記認可サービス装置に保存する保存手段と、前記サービスを受けるための要求と、発行された前記認可情報とを前記情報処理装置から取得したことに応じて、前記認可情報に紐付く前記情報処理装置の識別情報を前記認可サービス装置に問い合わせる問合せ手段と、前記問合せ手段による問い合わせの結果取得した情報処理装置の識別情報と、前記登録手段により登録されている情報処理装置の識別情報とが一致したことに応じて、前記要求に従い前記情報処理装置にサービスを提供する提供手段と、を備える。

本発明の認証システムによれば、印刷を実行する画像形成装置だけが認証によってプリントサーバから印刷データを取得する仕組みにより、不正ダウンロードを防止することが可能となる。

本発明の一実施形態のシステム構成例を示す図である。 各装置のハードウェア構成例を示す図である。 各装置のソフトウェアモジュール構成例を示す図である。 認可サーバが管理するテーブル情報を示す図である。 画像形成装置が管理するテーブル情報を示す図である。 プリントサーバで管理するテーブル情報を示す図である。 プリンタ登録のシーケンス図である。 Ｗｅｂブラウザから指示される印刷実行のシーケンス図である。 プリントサーバから送信され、表示される画面例である。 プルプリントのシーケンス図である。 印刷データ取得リクエスト時の認可トークン確認フローである。 ユーザ認可のシーケンス図である。 ユーザ認可の画面例である。 認証印刷のシーケンス図である。 認証印刷の印刷リクエスト確認フローである。 印刷完了通知受信時の認証印刷用プリンタの削除フローである。

（実施例１）
図１は、本実施形態の印刷システムの構成例を示す図である。印刷システムは、ＯＡｕｔｈを用いた認証を行い、不正ダウンロードを防止する認証システムとしても機能する。印刷システムは、認可サーバ２００、プリントサーバ２１０、クライアント端末２２０、画像形成装置３００を備える。クライアント端末２２０と画像形成装置３００は、ＷＡＮ（Ｗｉｄｅ Ａｒｅａ Ｎｅｔｗｏｒｋ）１００により、認可サーバ２００とプリントサーバ２１０と通信可能である。なお、本発明ではＷｏｒｌｄ Ｗｉｄｅ Ｗｅｂ（ＷＷＷ）システムが構築されているものとする。クライアント端末２２０と画像形成装置３００はＬＡＮ（Ｌｏｃａｌ Ａｒｅａ Ｎｅｔｗｏｒｋ）１０１により接続されている。また、認可サーバ２００とプリントサーバ２１０もＬＡＮ１０１により接続されている。

認可サーバ２００は、ＯＡｕｔｈを実現するために認可情報を管理する認可サービス装置である。プリントサーバ２１０は、クライアント端末２２０や画像形成装置３００からのリクエストを受けて、ユーザが作成した文書などの印刷データを提供するサービス提供装置である。クライアント端末２２０は、プリントサーバ２１０からサービスを受けて画像形成装置３００に印刷などを指示するユーザ装置である。画像形成装置３００は、リクエストを受付けてプリントサーバ２１０から印刷データなどを取得し、印刷を実行する情報処理装置である。なお、認可サーバ２００、プリントサーバ２１０、クライアント端末２２０、画像形成装置３００はそれぞれ個別のＬＡＮ上に構成されていてもよいし同一のＬＡＮ上に構成されていてもよい。また認可サーバ２００、プリントサーバ２１０は同一のサーバ上に構成されていてもよい。

本実施の一実施形態に係る印刷システムは、図２に示すような構成のサーバおよび画像形成装置から成るシステム上に実現される。図２は、認可サーバ２００と画像形成装置３００とがＷＡＮ１００およびＬＡＮ１０１を介して通信可能に接続されている様子を示す。まず、認可サーバ２００の構成について説明する。尚、図２に示されるハードウェアブロック図は一般的な情報処理装置のハードウェアブロック図に相当するものとし、本実施形態の認可サーバ２００には一般的な情報処理装置のハードウェア構成を適用できる。図２を用いて認可サーバ２００のハードウェア構成例を説明するが、本構成例はプリントサーバ２１０やクライアント端末２２０についても適用される。

図２に示すように、認可サーバ２００は、ＣＰＵ２３１、ＲＡＭ２３２、ＲＯＭ２３３、ＫＢＣ２３５、ＣＲＴＣ２３６、ＤＫＣ２３７、ＮＣ２３８、ＫＢ２３９、ＣＲＴ２４０、外部メモリ２４１を備える。ＣＰＵ２３１乃至ＮＣ２３８はシステムバス２３４により相互にデータを送受信することができる。ＣＰＵ（Ｃｅｎｔｒａｌ Ｐｒｏｃｅｓｓｉｎｇ Ｕｎｉｔ）２３１は、システムバス２３４に接続される各ブロックを制御する。また、ＣＰＵ２３１は、ＲＯＭ２３３のプログラム用ＲＯＭまたはハードディスク（ＨＤ）等の外部メモリ２４１に記憶されたＯＳやアプリケーション等のプログラムをＲＡＭ２３２にロードし実行する。ＲＯＭ（Ｒｅａｄ Ｏｎｌｙ Ｍｅｍｏｒｙ）２３３は、各種プログラムを記憶するユニットであり、フォントＲＯＭ、プログラムＲＯＭ、データＲＯＭを備える。ＲＡＭ（Ｒａｎｄｏｍ Ａｃｃｅｓｓ Ｍｅｍｏｒｙ）２３２は、ＣＰＵ２３１の主メモリ、ワークエリア等として機能する。なお、ＯＳとは、コンピュータ上で稼動するオペレーティングシステムの略語であり、以下オペレーティングシステムのことをＯＳと呼ぶ。後述する各シーケンスの処理はこのプログラムの実行により実現できる。

キーボードコントローラ（ＫＢＣ）２３５は、キーボード（ＫＢ）２３９や不図示のポインティングデバイスからのキー入力を制御する。ＣＲＴコントローラ（ＣＲＴＣ）２３６は、ＣＲＴディスプレイ２４０の表示を制御する。ディスクコントローラ（ＤＫＣ）２３７は各種データを記憶するハードディスク（ＨＤ）等の外部メモリ２４１におけるデータアクセスを制御する。ネットワークコントローラ（ＮＣ）２３８は、ＷＡＮ１００もしくはＬＡＮ１０１を介して接続された画像形成装置３００や他の機器との通信制御処理を実行する。尚、後述の全ての説明においては、特に断りのない限り、サーバにおける実行のハード上の主体はＣＰＵ２３１であり、ソフトウェア上の主体は外部メモリ２４１にインストールされたアプリケーションプログラムである。

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

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

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

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

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

図３は、図１の認可サーバ２００、プリントサーバ２１０、クライアント端末２２０、画像形成装置３００それぞれのソフトウェアモジュール構成例を示す図である。認可サーバ２００は、認可サーバモジュール６００を備える。認可サーバ２００のＣＰＵ２３１は、認可サーバモジュール６００を実行することで認可情報を発行したり、プリントサーバ２１０から認証リクエストを受けて認証を実施する。ここで、「認可」とは、リクエスト元のプリントサーバへのアクセスについて認証を行い、認証が有効であれば許可することを指す。また、「認証」とは、認可サーバ２００がプリントサーバ２１０から認証要求を受けて、リクエストの受け手であるプリントサーバがリクエストの送り手を「本人」であると確認する作業を指す。認証時には、ユーザＩＤ、パスワードと言った認証情報の入力が必要となるが、認可時には、既に発行済の認可情報で認証されるため認証情報の入力が必要ない。

プリントサーバ２１０は、プリントサーバモジュール７００を備える。プリントサーバ２１０のＣＰＵ２３１はプリントサーバモジュール７００を実行することにより画像形成装置を登録したり、認可サーバ２００に認証を要求する。プリントサーバモジュール７００によってクライアント端末２２０は、ＷＷＷを利用するためのユーザエージェントであるＷｅｂブラウザ１２００を備える。

画像形成装置３００は、アプリケーション管理フレームワーク８００、仮想マシン８１０、ＯＳ８２０、Ｗｅｂブラウザ８３０、アプリ管理部８４０、ローカルログイン部８５０、プルプリント部８６０を備える。また、画像形成装置３００は、認可サーバ連携部８７０、認証印刷部８８０を備える。アプリ管理部８４０乃至認証印刷部８８０はアプリケーションであり、画像形成装置３００のＣＰＵ３０１は、ＲＯＭ３０２、または外部メモリ３０３に記憶されたＯＳを実行する事で各アプリケーションを制御する。図３に示すＯＳ８２０には、一般的にはリアルタイムＯＳが使用されるが、昨今ではＬｉｎｕｘ（登録商標）等の汎用ＯＳが使用される事もある。次に、仮想マシン８１０は、例えばＪａｖａ（登録商標）ＶＭがよく知られている。この仮想マシン８１０は、ＯＳ８２０で制御されるアプリケーションとして動作する仮想的なアプリケーション実行環境である。

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

ローカルログイン部８５０、プルプリント部８６０、認可サーバ連携部８７０、認証印刷部８８０は、仮想マシン８１０が提供するアプリケーション実行環境にて動作する。また、これらアプリケーションは、アプリケーション管理フレームワーク８００にてライフサイクルが管理されている。アプリ管理部８４０は、アプリケーション管理フレームワーク８００が公開するライフサイクル管理用の制御Ｉ／Ｆを介して、ユーザからの各種アプリケーションのインストールや、開始リクエストを受け付け実行するアプリ管理アプリケーションである。

ここで、画像形成装置３００は、認可サーバ連携部８７０、認証印刷部８８０、ローカルログイン部８５０、およびプルプリント部８６０を既定で備えていてもよい。また、アプリ管理部８４０およびアプリケーション管理フレームワーク８００を介して、後からインストールされてもよい。さらに、画像形成装置３００は、ＷＷＷを利用するためのユーザエージェントであるＷｅｂブラウザ８３０を備える。

図４（Ａ）、図４（Ｂ）、図４（Ｃ）は、認可サーバ２００が外部メモリ２４１に記憶するデータテーブルである。図４に示す各データテーブルは、認可サーバ２００の外部メモリ２４１ではなく、ＬＡＮ１０１を介して通信可能に構成された別のサーバに記憶するよう構成されてもよい。

図４（Ａ）は、ユーザ管理テーブル１３００である。ユーザ管理テーブル１３００は、ユーザＩＤ１３０１、パスワード１３０２、ユーザ種別１３０３を備える。認可サーバ２００は、ユーザＩＤ１３０１、パスワード１３０２の情報の組を検証し、正しければ認証情報（トークン）を生成することで、各ユーザもしくはクライアントを認証する機能を備える。

図４（Ｂ）は、デバイス管理テーブル１４００である。デバイス管理テーブル１４００は、デバイスＩＤ１４０１、デバイス名１４０２、デバイス説明１４０３、リダイレクトＵＲＬ１４０４、シリアル番号１４０５から成る。デバイスＩＤ１４０１は、ユーザ管理テーブル１３００のユーザＩＤ１３０１と関連付いており、互いに参照可能となっている。デバイス名１４０２、デバイス説明１４０３、リダイレクトＵＲＬ１４０４は後述のＯＡｕｔｈのシーケンスで利用される値である。そして、シリアル番号１４０５はデバイスが画像形成装置３００で合った場合に登録される値であり、画像形成装置をユニークに識別可能な値である。なお、本テーブルは印刷機能やＦＡＸ機能を有するプリンタを想定しているが、これに限定されるものではなく、デバイスを一意に識別することが可能であれば任意の情報処理装置を管理することができる。

図４（Ｃ）は、認可トークン管理テーブル１５００である。認可トークン管理テーブル１５００は、認可トークンＩＤ１５０１、トークン種別１５０２、有効期限１５０３、スコープ１５０４、リフレッシュトークンＩＤ１５０５、リフレッシュ期限１５０６、デバイスＩＤ１５０７、ユーザＩＤ１５０８から成る。これら認可トークン管理テーブル１５００の処理詳細については後述する。

図５（Ａ）、図５（Ｂ）、図５（Ｃ）、図５（Ｄ）、図５（Ｅ）は、画像形成装置３００が外部メモリ３０３に記憶するデータテーブルである。図５（Ａ）は、デバイスユーザ管理テーブル１６００である。デバイスユーザ管理テーブル１６００は、ローカルログイン部８５０から参照、更新可能なように構成されている。また、本実施例では画像形成装置３００の外部メモリ３０３に記憶するよう記載しているが、画像形成装置３００がＬＡＮ１０１を介して通信可能な別サーバに記憶するよう構成されてもよい。

デバイスユーザ管理テーブル１６００は、デバイスユーザＩＤ１６０１、パスワード１６０２、ＩＣカード情報１６０３から成る。ローカルログイン部８５０は、画像形成装置３００の入力画面を用いてユーザからのユーザＩＤ、パスワードを受け付ける画面（不図示）を構成する。そして、入力されたユーザＩＤ、パスワードの組が、デバイスユーザＩＤ１６０１、パスワード１６０２の組と合っているか検証し、正しければデバイスユーザＩＤ１６０１の情報を含むログインコンテキストを生成することで、各ユーザを認証する機能を備える。

また、ローカルログイン部８５０は、画像形成装置３００に接続された不図示のＩＣカードリーダーからＩＣカード情報を取得し、ＩＣカード情報１６０３の情報と合っているか検証する。ＩＣカード情報が正しければ対応するデバイスユーザＩＤ１６０１の情報を含むログインコンテキストを生成する事で、各ユーザを認証する機能を備える事もできる。ここで、ログインコンテキストとは、認証を受けたユーザのデバイスユーザＩＤ１６０１の情報が設定されたオブジェクトである。ログインコンテキストにはユーザの属性情報、例えば、ユーザが所属するドメインやユーザの電子メールアドレス等の情報を設定するよう構成する事もできる。

図５（Ｂ）は、デバイス管理テーブル１７００である。デバイス管理テーブル１７００は、認可サーバ連携部８７０からのみ参照、更新可能なように構成されている。デバイス管理テーブル１７００は、デバイスＩＤ１７０１、デバイスシークレット１７０２、エンドポイントＵＲＬ１７０３、デバイス名１７０４、デバイス説明１７０５、リダイレクトＵＲＬ１７０６から成る。ここで、デバイスＩＤ１７０１、デバイスシークレット１７０２は、予め認可サーバ２００にて発行、記憶されたユーザＩＤ１３０１、パスワード１３０２にそれぞれ対応している。さらに、デバイス名１７０４、デバイス説明１７０５、リダイレクトＵＲＬ１７０６も、デバイス管理テーブル１４００に、デバイスＩＤ１４０１、デバイス名１４０２、リダイレクトＵＲＬ１４０４と同様のデータが格納されている。エンドポイントＵＲＬ１７０３は、認可サーバが公開するＯＡｕｔｈのためのエンドポイントのＵＲＬである。

図５（Ｃ）は、親トークン管理テーブル１８００である。親トークン管理テーブル１８００は、認可サーバ連携部８７０からのみ参照、更新可能なよう構成されている。親トークン管理テーブル１８００は、デバイスユーザＩＤ１８０１、認可トークンＩＤ１８０２、リフレッシュトークンＩＤ１８０３から成る。親トークン管理テーブル１８００の処理詳細については後述する。

図５（Ｄ）は、プリンタ情報テーブル１９００である。プリンタ情報テーブル１９００は、画像形成装置３００上のすべてのアプリケーションから参照、更新可能なよう構成されている。プリンタ情報テーブル１９００は、モデル名１９０１、ＵＲＬ１９０２、シリアル番号１９０３から成る。モデル名１９０１は、画像形成装置３００の機種を識別可能な名前である。ＵＲＬ１９０２は、プルプリント部８６０が印刷リクエストを受け付けるエンドポイントである。シリアル番号１９０３は画像形成装置３００毎に割り振られており、画像形成装置３００をユニークに識別可能な値である。

図５（Ｅ）は、印刷キュー管理テーブル２０００である。印刷キュー管理テーブル２０００は、プルプリント部８６０からのみ参照、更新可能なよう構成されている。印刷キュー管理テーブル２０００は、ＵＲＬ２００１、ジョブＩＤ２００２、プリンタＩＤ２００３、デバイスジョブＩＤ２００４から成る。プルプリント部８６０は、印刷リクエストを受け付けた順番に印刷キュー管理テーブル２０００に印刷ジョブ情報として印刷リクエストで渡されるＵＲＬ２００１、ジョブＩＤ２００２、プリンタＩＤ２００３を登録する。またプルプリント部８６０は、印刷キュー管理テーブル２０００に印刷ジョブ情報を登録する際にデバイスジョブＩＤ２００４を発行し登録する。デバイスジョブＩＤ２００３は、プルプリント部８６０内で印刷ジョブを識別するユニークな識別子である。プルプリント部８６０は、印刷キュー管理テーブルの印刷ジョブを登録された順に印刷実行する。

図６（Ａ）、図６（Ｂ）、図６（Ｃ）、図６（Ｄ）はプリントサーバ２１０が外部メモリに記憶するデータテーブルである。図６に示すデータテーブルは、プリントサーバ２１０の外部メモリ３０３ではなく、ＬＡＮ１０１を介して通信可能に構成された別のサーバに記憶するよう構成されてもよい。

図６（Ａ）は、ドキュメント管理テーブル２１００である。ドキュメント管理テーブル２１００は、ジョブＩＤ２１０１、ドキュメント名２１０２、ユーザ名２１０３、データパス２１０４から成る。プリントサーバ２１０は、ドキュメントを受信するとドキュメントをユニークに識別可能なジョブＩＤ２１０１を発行し、データパス２１０４にドキュメントデータを保存する。ドキュメント名２１０２とユーザ名２１０３には、ドキュメント受信時に指定された値が保存される。

図６（Ｂ）は、ジョブ管理テーブル２２００である。ジョブ管理テーブル２２００は、ジョブＩＤ２２０１、ドキュメントＩＤ２２０２、ステータス２２０３、プリンタＩＤ２２０４、デバイスジョブＩＤ２２０５から成る。プリントサーバ２１０は印刷リクエストを受信すると、印刷ジョブをユニークに識別可能なジョブＩＤ２２０１を発行する。ドキュメントＩＤ２２０２、プリンタＩＤ２２０４、デバイスジョブＩＤ２２０５には、印刷リクエスト時に指定された値が保存される。またドキュメントＩＤ２２０２は、ドキュメント管理テーブル２１００のドキュメントＩＤ２１０１と関連づいており、互いに参照可能である。ステータス２２０３は、印刷ジョブの状態を表し、“印刷待ち”、“印刷中”、“印刷済み”、“エラー終了”などの状態が格納される。プリントサーバ２１０は印刷リクエストを受信すると“印刷待ち”、プルプリント部８６０から印刷データダウンロードリクエストを受信すると“印刷中”にステータス２２０３を変更する。プリントサーバ２１０は、プルプリント部８６０からの印刷結果通知をもとに、最終的にステータス２２０３を“印刷済み”または“エラー終了”に変更する。

図６（Ｃ）は、マイプリンタ管理テーブル２３００である。マイプリンタ管理テーブル２３００は、マイプリンタ名２３０１、プリンタＩＤ２３０２、ユーザ名２３０３から成る。ユーザはプリントサーバ２１０に登録されているプリンタ一覧からプリンタを選択し、マイプリンタを登録する。マイプリンタ名２３０１は、ユーザにより任意に指定されたマイプリンタの名前である。プリンタＩＤ２３０２は、マイプリンタと紐づくプリンタをユニークに識別するＩＤであり、プリンタ管理テーブル２４００のプリンタＩＤ２４０１と関連づいており、互いに参照可能となっている。ユーザ名２３０３はマイプリンタを作成したユーザ名である。

図６（Ｄ）は、プリンタ管理テーブル２４００である。プリンタ管理テーブル２４００は、プリンタＩＤ２４０１、プリンタ名２４０２、モデル名２４０３、ＵＲＬ２４０４、シリアル番号２４０５、種別２４０６から成る。プリントサーバ２１０は、プリンタ登録リクエストを受信すると、プリンタをユニークに識別可能なプリンタＩＤ２４０１を発行する。プリンタＩＤ２４０１、プリンタ名２４０２、モデル名２４０３、ＵＲＬ２４０４、シリアル番号２４０５には、プリンタ登録リクエストで指定された値が保存される。プリンタ名２４０２は、ユーザにより任意に指定されたプリンタの名前である。モデル名２４０３、ＵＲＬ２４０４、シリアル番号２４０５には、画像形成装置３００が保持するプリンタ情報テーブル１９００のモデル名１９０１、ＵＲＬ１９０２、シリアル番号１９０３がそれぞれ保存される。種別２４０６には、認証印刷用にプリンタの場合に“認証印刷”が保存される。

＜画像形成装置３００のプリンタ登録＞
本実施の形態における画像形成装置３００への権限移譲ではＯＡｕｔｈの仕組みを利用する。画像形成装置３００への権限移譲は画像形成装置３００上の認可サーバ連携部８７０が担う。

ＯＡｕｔｈの仕組みの概要を説明する。まず、管理者ユーザは、プリンタ情報を認可サーバ２００に登録する。管理者ユーザは、認可サーバ連携部８７０を介して、起動時に画像形成装置３００のプリンタモデル、プリンタ名、設置場所、リダイレクトＵＲＬ、シリアル番号を認可サーバ２００に登録する。認可サーバ２００は、プリンンタ情報をデバイス管理テーブル１４００に保存する。なおデバイス名１４０２にプリンタモデルを、デバイス説明１４０３にプリンタ名と設置場所を保存する。

また、認可サーバ２００は、プリンタ登録が行われると、クライアントをユニークに識別可能なユーザＩＤ１３０１とパスワード１３０２を発行し、ユーザ管理テーブル１３００に保存する。ユーザ管理テーブル１３００のユーザ種別１３０３は“デバイス”、“ユーザ”、“管理者ユーザ”があり、認証の対象を示す。プリンタ登録処理の場合、ユーザ種別１３０３には、“デバイス”が格納される。認可サーバ２００は、発行したユーザＩＤ１３０１をデバイス管理テーブル１４００のデバイスＩＤ１４０１にも保存する。認可サーバ連携部８７０は、プリンタ登録の結果としてデバイスＩＤ１４０１とパスワード１６０２を受け取り、それぞれデバイス管理テーブル１７００のデバイスＩＤ１７０１、デバイスシークレット１７０２に保持する。エンドポイントＵＲＬ１７０３には、認可サーバ２００の接続エンドポイントが保持される。デバイス名１７０４、デバイス説明１７０５、リダイレクトＵＲＬ１７０６には、プリンタ登録に用いたプリンタ情報が保持される。

＜画像形成装置３００のへの権限移譲＞
ＯＡｕｔｈでは、ユーザやクライアントから移譲された権限の証明するための情報として、トークンと呼ばれる情報を利用する。特に、ユーザやクライアントが画像形成装置３００に対して権限移譲した場合のトークンを親トークンと称する。ユーザによる画像形成装置への権限移譲とは、ユーザが画像形成装置に対しサーバへアクセスする権限を譲ることを云う。

また同一の画像形成装置３００から複数種類のサーバを利用する場合には、例えば、一度の権限移譲で画像形成装置３００上のそれぞれのアプリケーションでサーバを利用できるようになった方が効率的である。そこで、画像形成装置３００上のアプリケーションにユーザ権限を移譲させる際、ユーザに代わり画像形成装置３００がアプリケーションに権限を移譲することで、権限移譲の回数を低減させる。即ち、ユーザは、画像形成装置３００に権限を移譲した段階で、アプリケーションにも権限を移譲することを認めたこととなる。

ただし、権限移譲を一度で済ませる手段として、画像形成装置３００が取得した親トークンを、画像形成装置３００上のアプリケーションで共有すると、親トークンを共有する全てのアプリケーションがサーバにアクセス可能となってしまい好ましくない。これは、アプリケーションが共有された親トークンを用いてプリントサーバにアクセスした場合、プリントサーバがアクセス元のアプリケーションを特定できず、利用の可否を判断する事ができないためである。そこで、画像形成装置３００上の個々のアプリケーションは親トークンを直接使うのでなく、親トークンに移譲された情報を継承しつつ、アプリケーション毎に再移譲して発行されるトークンを用いる。つまり、アプリケーション専用の認可情報である。親トークンアプリケーション毎に再移譲して発行されたトークンを子トークンと称する。

本実施例において、プルプリント部８６０はプルプリント部８６０のプリンタ権限を画像形成装置３００に移譲し、画像形成装置３００が親トークンを取得する。さらに画像形成装置３００が親トークンを用いて子トークンを取得し、プリンタ権限を再びプルプリント部８６０に移譲する。

＜プリントサーバへのプリンタ登録＞
図７は、クライアント端末２２０のＷｅｂブラウザ上で管理者権限を持つユーザがプリントサーバ２１０にプリンタを登録するシーケンスである。なお、管理者ユーザが、クライアント端末２２０のＷｅｂブラウザ１２００を用いて認可サーバ２００でユーザ認証が行われているものとする。Ｗｅｂブラウザ１２００とプリントサーバ２１０間の接続はユーザ認証時に認可サーバ２００により発行される認証情報により認証状態が保持されている。プリントサーバ２１０は、Ｗｅｂブラウザ１２００からのリクエストに付加される認証情報を取得することができ、ログインユーザを知ることができる。また、プリンタ登録は管理者権限を持つユーザのみ実行可能である。具体的にはプリントサーバ２１０は、プリンタ登録のためのリクエスト（後述のＳ１２、Ｓ１４）を受け付けると、ユーザ種別１３０３が“管理者ユーザ”の場合のみアクセスを許可する

まず、プリントサーバ２１０は、Ｗｅｂブラウザからプリンタ登録画面リクエストを受け付けると、図９（Ａ）に示すプリンタ登録画面２５００を返す（Ｓ１１）。プリンタ登録画面２５００は、プリンタ名とＩＰアドレスの入力欄２５０１とプリンタ登録ボタン２５０２から構成される。プリンタ登録ボタン２５０２がユーザにより押下されたタイミングで、プリンタ名とＩＰアドレスの入力欄２５０１に入力されているプリンタ名とＩＰアドレスをパラメータとしてプリントサーバ２１０にプリンタ登録リクエストされる（Ｓ１２）。プリントサーバ２１０は、プリンタ登録リクエストを受け付けると、図９（Ｂ）に示すスクリプトを生成し、Ｗｅｂブラウザ１２００に返す。ここで生成されるスクリプトは、プリンタ情報取得スクリプトである。プリンタ情報取得スクリプトはＷｅｂブラウザ１２００上で実行されるプログラムであり、後述のＳ１３、Ｓ１４の処理がＷｅｂブラウザ上で実行されるよう構成される。

Ｓ１３において、Ｗｅｂブラウザ１２００は、プリンタ情報取得スクリプトを用いて、プルプリント部８６０にプリンタ情報取得リクエストし、プリンタ情報を取得する（Ｓ１３）。プルプリント部８６０は、プリンタ情報取得リクエストを受け付けると、プリンタ情報テーブル１９００のモデル名１９０１、ＵＲＬ１９０２、シリアル番号１９０３をプリンタ情報として返す。次に、Ｗｅｂブラウザ１２００は、プリンタ情報取得スクリプトを用いて、取得したプリンタ情報をプリントサーバ２１０に送信する（Ｓ１４）。プリントサーバ２１０は、受信したモデル名、ＵＲＬ、シリアル番号とＳ１２のプリンタ登録リクエストで取得したプリンタ名をプリンタ管理テーブル２４００に保存する。プリンタＩＤ２４０１はプリントサーバ２１０がプリンタ登録時に発行し保存する。プリントサーバ２１０は、プリンタ登録に成功するとプリンタ登録成功画面（不図示）をＷｅｂブラウザ１２００に返す。

＜プリントサーバのマイプリンタ登録＞
ユーザは、マイプリンタをプリントサーバ２１０に登録することができる。マイプリンタ登録は、プリントサーバ２１０が提供するマイプリンタ登録画面（不図示）で行うことができる。マイプリンタ登録画面では、管理者権限を持つユーザが、登録したプリンタ管理テーブル２４００のプリンタの一つを選択しマイプリンタ名を入力できる。プリントサーバ２１０は、入力されたマイプリンタ名と選択されたプリンタのプリンタＩＤ２４０１とログインユーザのユーザ名をそれぞれマイプリンタ管理テーブル２３００に保存する。

ユーザが不正に登録されたプリンタ（マイプリンタ）を利用してドキュメントを印刷すると、ユーザ情報が漏洩する恐れがある。したがってプリントサーバ２１０へのプリンタ登録できるユーザを管理者権限をもつユーザのみに限定することで、悪意のあるユーザにより不正なプリンタが登録されることを防ぐことができる。

＜Ｗｅｂブラウザから印刷＞
図８は、クライアント端末２２０のＷｅｂブラウザ１２００上でユーザがドキュメントを選択し、プルプリント部８６０に印刷リクエストを行うまでを示したシーケンスである。なお、Ｗｅｂブラウザ１２００を用いて認可サーバ２００でユーザ認証が行われているものとし、Ｗｅｂブラウザ１２００とプリントサーバ２１０間の接続はユーザ認証時に認可サーバ２００により発行された認証情報により認証状態が保持されている。プリントサーバ２１０はＷｅｂブラウザからのリクエストに付加される認証情報を取得することができ、ログインユーザを知ることができる。

まず、プリントサーバ２１０はドキュメント一覧画面取得を受け付けると、ドキュメント管理テーブル２１００からログインユーザのドキュメント情報を取得する。プリントサーバ２１０は、図９（Ｃ）に示すドキュメント一覧画面２５０４を生成しＷｅｂブラウザに返す（Ｓ２１）。図９（Ｃ）のドキュメント一覧画面２５０４は、印刷処理の対象となるドキュメントの選択画面であり、ドキュメント選択チェックボックス２５０５、ドキュメント名２５０６、印刷ボタン２５０７から成る。ドキュメント名２５０６はドキュメント管理テーブル２１００のドキュメント名２１０２であり、対応するドキュメントＩＤ２１０１がドキュメント一覧画面２５０４内に保持される。

印刷ボタン２５０７がユーザにより押下されたタイミングで、ドキュメント選択チェックボックス２５０５で選択されているドキュメントのドキュメントＩＤがプリントサーバ２１０に印刷リクエストされる（Ｓ２２）。Ｓ２２において、印刷リクエストを受信したプリントサーバ２１０は、マイプリンタ管理テーブル２３００からログインユーザのユーザ名に紐付くマイプリンタ情報を取得し、図９（Ｄ）に示すマイプリンタ一覧画面２５０８を生成しＷｅｂブラウザに返す。

図９（Ｄ）のマイプリンタ一覧画面２５０８は、マイプリンタ選択ラジオボタン２５０９、マイプリンタ名２５１０、印刷ボタン２５１１から成る。マイプリンタ名２５１０は、マイプリンタ管理テーブル２３００のマイプリンタ名２３０１であり、対応するプリンタＩＤ２３０２がマイプリンタ一覧画面２５０８内に保持される。印刷ボタン２５１１がユーザにより押下されたタイミングにマイプリンタ選択ラジオボタン２５０９で選択されているマイプリンタのプリンタＩＤがプリントサーバ２１０に印刷リクエストされる（Ｓ２３）。ユーザは管理者権限を持つユーザが登録したプリンタ（マイプリンタ）を指定して印刷実行するため、不正なプリンタに印刷リクエストされることを防ぐことができる。

プリントサーバ２１０は、Ｓ２４において、ジョブ管理テーブル２２００に印刷ジョブを登録する。プリントサーバ２１０は、印刷ジョブ登録時にジョブＩＤ２２０１を発行し登録する。ドキュメントＩＤはＳ２２において通知されたドキュメントＩＤであり、プリンタＩＤ２２０４はＳ２３において通知されたプリンタＩＤである。プリントサーバ２１０は、ステータス２２０３を“印刷待ち”に設定する。次にプリントサーバ２１０は、図９（Ｂ）に示すスクリプトを生成しＷｅｂブラウザ１２００に返す。ここで生成されるスクリプトは、印刷を指示するための印刷スクリプトである。印刷スクリプトはＷｅｂブラウザ１２００上で実行されるプログラムであり、後述のＳ２５、Ｓ２７、Ｓ２９の処理がＷｅｂブラウザ１２００上で実行されるよう構成される。

まず、Ｓ２５において、Ｗｅｂブラウザ１２００は印刷スクリプトを用いて、プルプリント部８６０にイベント登録リクエストを行う。イベント登録リクエストには、プリントサーバ２１０のＵＲＬとプリンタＩＤが指定される。イベント登録リクエストを受け付けたプルプリント部８６０は、イベント通知先にプリントサーバＵＲＬとプリンタＩＤを設定する。このとき、プルプリント部８６０は、イベント通知先を印刷キュー管理テーブル２０００のＵＲＬ２００１およびプリンタＩＤ２００３に設定してもよく、別のテーブルで管理してもよい。イベント通知先の設定が完了すると、プルプリント部８６０は、設定完了を示す応答をＷｅｂブラウザ１２００に返す。

次に、Ｓ２７において、Ｗｅｂブラウザ１２００は印刷スクリプトを用いて、プルプリント部８６０に印刷リクエストを行う。印刷リクエストには印刷データ取得するためのプリントサーバ２１０のＵＲＬ、ジョブＩＤ、プリンタＩＤを指定する。印刷リクエストで指定するジョブＩＤは、Ｓ２４で生成したジョブＩＤ２２０１であり、プリンタＩＤはＳ２３において指定されたプリンタＩＤ２３０２である。印刷リクエストを受け付けたプルプリント部８６０は、印刷リクエスト情報を印刷キュー管理テーブル２０００に追加する。印刷リクエストで付加されるプリントサービスＵＲＬ、ジョブＩＤ、プリンタＩＤをそれぞれＵＲＬ２００１、ジョブＩＤ２００２、プリンタＩＤ２００３に保存する。さらに、プルプリント部８６０は、デバイスジョブＩＤ２００４を生成し保存する。プルプリント部８６０は、印刷リクエストのレスポンスとして生成したデバイスジョブＩＤ２００４を返す。

Ｓ２９において、Ｗｅｂブラウザ１２００は印刷スクリプトを用いて、デバイスジョブＩＤをプリントサーバ２１０に通知する。プリントサーバ２１０は受信したデバイスジョブＩＤをジョブ管理テーブル２２００のデバイスジョブＩＤ２２０５に保持する。また、この時点でプリントサーバ２１０は、ジョブ管理テーブル２２００のステータス２２０３の設定を“印刷待ち”から“印刷中”に更新する。そして、プリントサーバ２１０は、Ｓ２１と同様のドキュメント一覧画面をＷｅｂブラウザ１２００に返す。別の形態として、プリントサーバ２１０は、印刷中を示す画面をＷｅｂブラウザ１２００に送信してもよい。

以上が、Ｗｅｂブラウザを用いてプルプリント部８６０に印刷リクエストを行う際のシーケンスである。ここで、印刷リクエスト（Ｓ２２、Ｓ２７）は一つのドキュメントＩＤでしか行われていないが、ドキュメント一覧画面２５０４で選択されたドキュメントが複数の場合には選択数に応じて複数回のリクエストが行われる。

＜プルプリント＞
図１０は、画像形成装置３００が印刷データを取得する際に認可サーバ２００からトークンを取得し、該トークンを用いてプリントサーバ２１０から印刷データを取得する処理を説明するシーケンスである。本明細書では、Ｗｅｂブラウザ１２００から指示することにより画像形成装置が印刷データを取得し、印刷を実行することをプルプリントと呼ぶものとする。プルプリント部８６０は、印刷キュー管理テーブル２０００に印刷ジョブが登録されている場合に先頭の印刷ジョブを取得し、印刷処理を開始する。プルプリント部８６０による印刷ジョブの実行は、印刷キュー管理テーブル２０００に登録された順に１ジョブずつ処理される。

まず、Ｓ３１１において、プルプリント部８６０は、認可サーバ連携部８７０に“プルプリント”のスコープを指定してトークン取得要求を行う。認可サーバ連携部８７０は、Ｓ３１１で受信したスコープとデバイス管理テーブル１７００のデバイスＩＤ１７０１、デバイスシークレット１７０２をパラメータとして認可サーバ２００に親トークン取得要求を行う（Ｓ３１２）。

認可サーバ２００は、ユーザ管理テーブル１３００を用いて親トークン取得要求で受け取ったデバイスＩＤとデバイスシークレットで認証を行う。認可サーバ２００は、ユーザ管理テーブル１３００にデバイスＩＤとデバイスシークレットの対が存在し、かつユーザ種別がデバイスである場合に認証成功と判断する。認可サーバ２００は認証成功後、親トークン取得要求で受け取ったスコープ（プルプリント）とデバイスＩＤを認可トークン管理テーブル１５００のスコープ１５０４とデバイスＩＤ１５０７にそれぞれ登録する。

ここで認可サーバ２００はトークン種別１５０２を“親トークン”として認可トークンＩＤ１５０１を発行・保存し、同時に有効期限も保存する（Ｓ３１３）。親トークンの有効期限は任意の期限が設定されてもよいが、本実施形態では、認可サーバ２００は、有効期限を親トークン取得要求を受け付けた時間の３ヶ月後とする。認可サーバ２００は、生成した親トークン（認可トークンＩＤ１５０１）を認可サーバ連携部８７０に応答する（Ｓ３１４）。

次に、認可サーバ連携部８７０は、受け取った親トークンを使って認可サーバ２００に子トークン取得要求を行う（Ｓ３１５）。認可サーバ２００は、子トークン取得要求で得られた親トークンと一致する認可トークン管理テーブル１５００の認可トークンＩＤ１５０１を検索し、親トークンのレコード情報をもとに子トークンを生成する。子トークンは認可サーバ２００によって認可トークンＩＤ１５０１が新たに発行・保存され、トークン種別１５０２には“子トークン”、デバイスＩＤ１５０７は親トークンのデバイスＩＤ１５０７を保存される（Ｓ３１６）。子トークンの有効期限は任意の期限が設定されてもよいが、本実施形態では、認可サーバ２００は、有効期限を子トークン取得要求を受け付けた時間の２４時間後とする。以上の処理により、認可情報の発行に伴って該認可情報と画像形成装置３００の識別情報とが紐付けて認可サーバ２００にて管理が可能となる。

認可サーバ２００は、生成した子トークン（認可トークンＩＤ１５０１）を認可サーバ連携部８７０に応答し、さらに認可サーバ連携部８７０がプルプリント部８６０に応答する（Ｓ３１７）。プルプリント部８６０は、印刷キュー管理テーブル２０００のＵＲＬ２００１（プリントサーバ２１０）にアクセスし、印刷データ取得リクエストを行う（Ｓ３１８）。このとき、プルプリント部８６０は、印刷データ取得リクエストにＳ３１７で取得した子トークンとジョブＩＤ２００２、プリンタＩＤ２００３を付加する。換言すれば、プルプリント部８６０は、クライアント装置からサービスを受けるための要求を受け付けて、認可サーバ２００から認可情報を取得し、当該認可情報とサービスを受けるための要求をプリントサーバ２１０に送信する。プリントサーバ２１０は、印刷データ取得リクエストを受け付けるとリクエスト検証を行う（Ｓ３１９）。リクエスト検証の詳細については図１１を用いて後述する。プリントサーバ２１０は、リクエスト検証に成功すると印刷データ取得リクエストされたジョブＩＤ２２０１の印刷データをプルプリント部８６０に渡し、プルプリント部８６０によって印刷が実行される。以上の処理により、プリントサーバ２１０はアクセス元のアプリケーションを特定し、利用の可否を判断する事が可能となる。

＜印刷データ取得リクエストの検証＞
図１１は、プリントサーバ２１０がプルプリント部８６０から印刷データ取得リクエスト（Ｓ３１８）を受け付け、印刷データ取得リクエストの検証を行う処理フローである。

プリントサーバ２１０は、プルプリント部８６０からの印刷データ取得リクエストを受け付けると（Ｓ４１）、印刷データ取得リクエストに付加される子トークンの有効性確認を認可サーバ２００に問合せる（Ｓ４２）。認可サーバ２００は、認可トークン管理テーブル１５００に子トークンと一致する認可トークンＩＤ１５０１があるか、また現在時刻が有効期限１５０３内かどうか検証した結果をプリントサーバ２１０に返す。プリントサーバ２１０は、問合せの結果取得した認可サーバ２００からの子トークン検証結果が無効だった場合、プルプリント部８６０に印刷エラーを返す（Ｓ４３、Ｓ４７）。問合せの結果取得した認可サーバ２００からの子トークン検証結果が有効だった場合、Ｓ４４で、プリントサーバ２１０は、認可サーバ２００に子トークンに紐づくスコープとシリアル番号の取得を依頼する。認可サーバ２００は、子トークンの認可トークンＩＤと一致する認可トークンＩＤ１５０１のスコープと発行したデバイスＩＤ（１４０１、１５０７）で紐づくシリアル番号１４０５をプリントサーバ２１０に返す。

プリントサーバ２１０は、認可サーバ２００から取得したスコープが“プルプリント”であることを確認する。また、プリントサーバ２１０は認可サーバ２００から取得したシリアル番号と印刷データ取得リクエストで画像形成装置３００から取得したプリンタＩＤに両方に一致するプリンタがプリンタ管理テーブル２４００に存在するか確認する（Ｓ４５）。プリントサーバ２１０は、プリンタが登録されていない場合、プルプリント部８６０に印刷エラーを返す（Ｓ４５、Ｓ４８）。

プリントサーバ２１０は、プリンタが登録されている場合、印刷データ取得リクエストで渡されたジョブＩＤとプリンタＩＤがジョブ管理テーブル２２００のジョブＩＤ２２０１とプリンタＩＤ２２０４に一致するかどうか確認する（Ｓ４６）。プリントサーバ２１０は、Ｓ４６においてジョブＩＤとプリンタＩＤが一致しない場合、プルプリント部８６０に印刷エラーを返す（Ｓ４６、Ｓ４８）。プリントサーバ２１０は、Ｓ４６においてジョブＩＤとプリンタＩＤが一致する場合、ジョブＩＤ２２０１の印刷データをプルプリント部８６０に返す（Ｓ４６、Ｓ４７）。以上の処理により、サービスを受けるための要求と発行された認可情報がプリントサーバ２１０に送信され、画像形成装置の識別情報の問い合わせが実行される。そして、プリントサーバ２１０は問合せの結果取得した画像形成装置の識別情報と、登録している画像形成装置の識別情報が一致したことに応じて、画像形成装置にサービスを提供することが可能となる。

上記説明したように、ユーザは、管理者権限を持つユーザにより登録された信頼されたプリンタから作られたマイプリンタを指定して印刷リクエストを行う。印刷リクエストを受けたプリントサーバ２１０は、印刷データ取得リクエストの検証において、信頼されたプリンタのシリアル番号と、権限移譲により発行された子トークンに紐づくシリアル番号の一致を検証する。印刷データ取得リクエストの検証により、ユーザが印刷リクエストした印刷データが印刷リクエストしたプリンタ以外に送信されることを防ぐことができる。なお、本実施形態では、プリントサーバや印刷を実行する画像形成装置を例に説明したが、本実施形態の仕組みは、印刷サービス以外のサービスを提供するサーバや画像形成装置以外の情報処理装置に適用可能である。

（実施例２）
実施例２におけるシステム構成、ハードウェア構成、ソフトウェアモジュール、認可サーバで管理するテーブル構造、画像形成装置で管理するテーブル構造、プリントサーバで管理するテーブル構造は前述の実施例１の内容と同じである。また実施例１で説明した、＜画像形成装置３００のプリンタ登録＞、＜画像形成装置３００のへの権限移譲＞、＜プリントサーバのプリンタ登録＞、＜プルプリント＞についても同じ内容である。

＜認証印刷におけるユーザの権限移譲＞
本実施例において、ユーザはプリントサーバ２１０へのデータ取得や印刷リクエストする権限を画像形成装置３００上の認証印刷部８８０に移譲し、認証印刷を実行する。本明細書では、ローカルログインによる認証に基づいた印刷を認証印刷と呼ぶものとする。ユーザの権限移譲による親トークン取得に関する本実施形態のシーケンスを図１２、図１３を用いて説明する。本シーケンスは、ユーザが画像形成装置３００を最初に利用する際に、画像形成装置３００のＷｅｂブラウザ８３０を用いて一度だけ行う操作である。

図１２に示すように、まず、ローカルログイン部８５０が提供する画像形成装置３００の入力画面を用いて、ユーザが画像形成装置３００にログインする（Ｓ５１１）。ここでユーザＩＤがｕｓｅｒ００１のユーザがログインしたとすると、ローカルログイン部８５０はｕｓｅｒ００１を含むログインコンテキストを生成する（Ｓ５１２）。

次に、ユーザは、画像形成装置３００を操作してブラウザ８３０を実行する。そして、ブラウザ８３０を用いて認可サーバ連携部８７０の認可連携を開始するための認可ＵＲＬへアクセスする（Ｓ５１３）。認可サーバ連携部８７０は、図１３（Ａ）に示すような認可連携開始を確認する画面２６００を応答するよう構成しても良い。

認可サーバ連携部８７０は、認可連携の開始を受け付けたら、ローカルログイン部８５０からログインコンテキストを取得する（Ｓ５１４）。そして認可サーバ連携部８７０は、デバイス管理テーブル１７００のエンドポイントＵＲＬ１７０３に記載のＵＲＬに対して、ＯＡｕｔｈの認可リクエストをするようブラウザ８３０にリダイレクト要求する（Ｓ５１５）。この認可リクエストには、デバイス管理テーブル１７００のデバイスＩＤ１７０１、リダイレクトＵＲＬ１７０６の情報が含まれる。また、ＯＡｕｔｈでは、認可を受けたい権限範囲を示すスコープを認可リクエストに含むよう構成する事もできる。本実施例では、スコープとして“認証印刷”がリクエストされたとして説明する。

認可リクエストを受け付けた認可サーバ２００は、ユーザを認証するために図１３（Ｂ）に示すログイン画面２６０１をブラウザ８３０に応答する（Ｓ５１６）。ユーザは、ブラウザ８３０に示されたログイン画面２６０１に対して、ユーザＩＤ、パスワードを入力しログインを実行する（Ｓ５１７）。認可サーバ２００は、受け付けたユーザＩＤ、パスワードの組がユーザ管理テーブル１３００に登録されている情報と合っているかを検証し、合っている場合はユーザＩＤに紐づいた認証情報を生成して次の処理を実行する。

認可サーバ２００は、認可リクエストに含まれているデバイスＩＤ１７０１とリダイレクトＵＲＬ１７０６の組みが、デバイス管理テーブル１４００に登録されている情報と合っているか検証する。検証の結果正しければ、デバイス管理テーブル１４００のデバイス名１４０２、デバイス説明１４０３を取得し、図１３（Ｃ）に示す認可確認画面２６０２を生成しブラウザ８３０に応答する（Ｓ５１８）。その際、認証情報をブラウザ８３０に対してＣｏｏｋｉｅ情報として格納して応答する。なお、本実施例では、認可確認画面２６０２にデバイス名１３０２、デバイス説明１４０３を表示するよう説明したが、ここにログインしているユーザの情報を表示するよう構成する事もできる。また認可リクエストにスコープを含む場合は、当該スコープの範囲を説明する情報を認可確認画面２６０２に表示するよう構成する事も出来る。

次に、ユーザは、ブラウザ８３０に表示された認可確認画面２６０２で許可を押下する（Ｓ５１９）。許可を受け付けた認可サーバ２００は、次の処理を実行する。認可サーバ２００は、認可トークン管理テーブル１５００に認可コードを発行し登録する。その際、認可トークンＩＤ１５０１に発行した認可トークンのＩＤ、トークン種別１５０２に認可コード、有効期限１５０３、および、認可リクエスト時に受け付けたデバイスＩＤをデバイスＩＤ１５０７、ログインユーザのユーザＩＤ１５０８を登録する。そして、認可サーバ２００は、認可応答として、認可トークンＩＤ１５０１とトークン種別１５０２（認可コード）を付与したリダイレクトＵＲＬを用いてブラウザ８３０にリダイレクト要求する（Ｓ５２０）。

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

トークン要求を受けた認可サーバ２００は以下の検証を行い、正しい場合は親トークンを生成する（Ｓ５２２）。認可サーバ２００は、トークン要求で受けつけたデバイスＩＤ、デバイスシークレットの組が、ユーザ管理テーブル１３００に登録されているユーザＩＤ１３０１、パスワード１３０２の組と合っているか検証する。次に、トークン要求で受けつけた認可トークンＩＤ１５０１、トークン種別１５０２（認可コード）が、認可トークン管理テーブル１５００に登録されているか、有効期限内かを検証する。そして、トークン要求で受け付けたデバイスＩＤとリダイレクトＵＲＬがそれぞれ認可トークン管理テーブル１５００の認可トークンＩＤで特定されるデバイスＩＤ１５０７とリダイレクトＵＲＬ１４０４と一致するかを検証する。これらすべての検証が正しい場合に、認可サーバ２００は親トークンを生成して、親トークンの認可トークンＩＤ１５０１を認可サーバ連携部８７０に応答する。この際、応答内容として同時に発行したリフレッシュトークンＩＤ１５０５も含む（Ｓ５２３）。

親トークンについて、認可トークンＩＤ１５０１に発行したトークンのＩＤ、トークン種別１５０２に親トークン、有効期限１５０３、および、認可コードから引き継ぐ情報として、デバイスＩＤ１５０７、ユーザＩＤ１５０８を登録する。この際、認可サーバ２００は、親トークンをリフレッシュするためのリフレッシュトークンを発行し、リフレッシュトークンＩＤ１５０５、リフレッシュ期限１５０６に登録する。リフレッシュのフローについては後述する。

親トークンの認可トークンＩＤ、リフレッシュトークンＩＤを取得した認可サーバ連携部８７０は、Ｓ５２４においてローカルログイン部８５０から取得したログインコンテキストからデバイスユーザＩＤを取得する。そして認可サーバ連携部８７０は親トークン管理テーブル１８００に、デバイスユーザＩＤ、親トークンの認可トークンＩＤ、リフレッシュトークンＩＤを保存する（Ｓ５２４）。そして、認可サーバ連携部８７０は、不図示の認可連携完了の旨を示す画面をブラウザ８３０に応答し、処理を終了する（Ｓ５２５）。

＜認証印刷＞
図１４は、ユーザが画像形成装置３００の操作画面上でログインを実行し、認証用アプリケーションである認証印刷部８８０を用いてプリントサーバ２１０のドキュメントを印刷する認証印刷のシーケンスである。なお、前述の認証印刷におけるユーザの権限移譲が実施されている必要がある。

まず、ローカルログイン部８５０が提供する画像形成装置３００の入力画面を用いたログイン手段を用いてユーザが画像形成装置３００にログインする（Ｓ６１１）。ここでユーザＩＤがｕｓｅｒ００１のユーザがログインしたとする。すると、ローカルログイン部８５０はｕｓｅｒ００１を含むログインコンテキストを生成し、アプリケーション管理フレームワーク８００を介して各アプリケーションから取得可能なようＲＡＭ３０８に格納する（Ｓ６１２）。なお、前述の親トークン取得のシーケンスの後に連続して実行する場合は、再度ログインする必要はなく、次のＳ６１３からの操作シーケンスとなる。

次に、ユーザは画像形成装置３００を操作して認証印刷部８８０のドキュメント一覧画面（不図示）にアクセスする（Ｓ６１３）。これは、プリントサーバ２１０のドキュメントを選択し印刷指示する操作画面を求めるための操作である。

ドキュメント一覧画面２５０４にアクセスされた認証印刷部８８０は、ローカルログイン部８５０からログインコンテキストを取得する（Ｓ６１４）。そして、認可サーバ連携部８７０に対してトークン取得要求を行う（Ｓ６１５）。この際、Ｓ６１４で取得したログインコンテキストを要求に含める。なお、ここでトークンに必要なスコープを要求するよう構成する事もできる。本実施例では、スコープに“認証印刷”が要求されたとして説明する。

次に、認可サーバ連携部８７０は、取得したログインコンテキストに紐づいたデバイスユーザＩＤをキーに、親トークン管理テーブル１８００からリフレッシュトークンＩＤ１８０３を取得する。この時、親トークン管理テーブル１８００にユーザＩＤが登録されていない場合は、親トークン取得シーケンスを実施するようユーザに促す画面（不図示）を提示するよう構成する事もできる。また、場合によってはブラウザ８３０を起動し、親トークン取得シーケンスを自動的に開始するよう構成するでも良い。

認可サーバ連携部８７０は取得したリフレッシュトークンＩＤ１８０３と、デバイス管理テーブル１７００のデバイスＩＤ１７０１、デバイスシークレット１７０２を用いて、認可サーバ２００にトークンリフレッシュ要求を行う（Ｓ６１６）。ここで、親トークンの有効期限内で合った場合は、トークンリフレッシュ要求を実施せず、Ｓ６２０の子トークン取得要求を実施しても良い。

トークンリフレッシュ要求を受けた認可サーバ２００は、以下の処理を実行する。まず、トークンリフレッシュ要求に含まれるデバイスＩＤ、デバイスシークレットの組がユーザ管理テーブル１３００のユーザＩＤ１３０１とパスワード１３０２の組と合っているかを検証する。正しい場合は、トークンリフレッシュ要求に含まれるリフレッシュトークンＩＤが認可トークン管理テーブル１５００に登録されており、リフレッシュ期限内か確認する。

さらに、トークンリフレッシュ要求に含まれるデバイスＩＤがデバイスＩＤ１５０７と一致するか検証する。全ての検証が正しい場合は、再発行した親トークンの認可トークンＩＤと、リフレッシュトークンＩＤを認可サーバ連携クライアント５００に応答する（Ｓ６１８）。リフレッシュの方法としては、新たに認可トークンＩＤ、リフレッシュトークンＩＤを発行して、認可トークン管理テーブル１５００に登録する。この際、トークンリフレッシュ要求で受けつけたリフレッシュトークンＩＤによって特定されるレコードのトークン種別１５０２、スコープ１５０４、デバイスＩＤ１５０７、ユーザＩＤ１５０８を引き継ぐ。また、引き継ぎ後、元のリフレッシュトークンＩＤは再度リフレッシュできないよう無効化、より具体的には有効期限を強制的に期限切れにする事も出来るし、リフレッシュトークンＩＤは新規発行せず、引き継ぐよう構成する事も可能である。

リフレッシュされた親トークンを取得した認可サーバ連携部８７０は、受け付けた認可トークンＩＤ、リフレッシュトークンＩＤにて、親トークン管理テーブル１８００の情報を上書きし、再登録する（Ｓ６１９）。そして、親トークンの認可トークンＩＤと、デバイス管理テーブル１７００のデバイスＩＤ、デバイスシークレット、トークン取得要求で受けつけたスコープを用いて、認可サーバ２００に子トークン取得要求を行う（Ｓ６２０）。

子トークン取得要求を受けた認可サーバ２００は、以下の処理を実行する。まず、子トークン取得要求に含まれるデバイスＩＤ、デバイスシークレットの組がユーザ管理テーブル１３００のユーザＩＤ１３０１とパスワード１３０２の組と合っているかを検証する。正しい場合は、子トークン取得要求に含まれる認可トークンＩＤが認可トークン管理テーブル１５００に登録されており、有効期限内か確認する。

さらに、子トークン取得要求に含まれるデバイスＩＤがデバイスＩＤ１５０７と一致するか検証し、全ての検証が正しい場合は、Ｓ６２１で子トークンを生成し、認可サーバ連携部８７０に応答する（Ｓ６２２）。実施例１と同様に、認可サーバ２００は子トークンについて新たに認可トークンＩＤを発行する。認可サーバ２００は、トークン種別１５０２を子トークン、スコープ１５０４に子トークン取得要求に含まれるスコープを、認可トークン管理テーブル１５００に登録する。この際、子トークン取得要求で受けつけた認可トークンＩＤによって特定されるレコードのデバイスＩＤ１５０７、ユーザＩＤ１５０８を引き継ぐ。結果、この時発行した子トークンには、ユーザを特定するためのユーザＩＤ、画像形成装置を特定するためのデバイスＩＤが紐づく。また、有効期限１５０３は実施例１と異なり、１時間など、期限を短く設定してもよい。これは、例えば、プリンタ情報が管理者ユーザによりプリントサーバに登録されていない場合があり、セキュリティ上、長時間トークンを保持しないことが望ましいからである。

そして、子トークンの認可トークンＩＤを取得した認可サーバ連携部８７０は、要求元の認証印刷部８８０に子トークンの認可トークンＩＤを応答する。子トークンの認可トークンＩＤを取得した証印刷部８８０は、プリントサーバ２１０に認可トークンＩＤを含むドキュメント一覧取得を行う（Ｓ６２３）。つまり、認証印刷部８８０は、権限の移譲をユーザから受け、当該ユーザによる操作画面を要求する操作に応じて認可サーバから認可情報を取得し、当該認可情報とサービスを受けるための要求をプリントサーバ２１０に送信する。プリントサーバ２１０は、ドキュメント一覧取得リクエストに含まれる子トークンの認可トークンＩＤのリクエスト検証処理を認可サーバ２００に依頼する（Ｓ６２４）。印刷リクエスト検証は、図１５を用いて後述する。

認証印刷部８８０は受け取ったドキュメント一覧からドキュメント一覧画面を生成し表示する（Ｓ６２６）。ここで表示するドキュメント一覧画面は、図９（Ｃ）のＷｅｂブラウザのドキュメント一覧画面２５０４と類似の画面である。ドキュメント一覧画面で印刷ボタンがユーザに押下されると（Ｓ６１３）、認証印刷部８８０は、プリントサーバ２１０に子トークンの認可トークンＩＤ、ドキュメントＩＤ、プリンタ情報を含む印刷リクエストを行う（Ｓ６２３）。ここで印刷リクエストに付加されるドキュメントＩＤは、ドキュメント一覧画面でユーザによって選択されたドキュメントのドキュメントＩＤである。また印刷リクエストに付加されるプリンタ情報は、認証印刷部８８０がプリンタ情報テーブル１９００から取得し、モデル名１９０１、ＵＲＬ１９０２、シリアル番号１９０３が含まれる。印刷リクエストを受けたプリントサーバ２１０は、印刷リクエストのリクエスト検証を行う（Ｓ６２４）。この印刷リクエスト検証の詳細は後述する。

Ｓ６３０〜Ｓ６３６において、プリントサーバ２１０が印刷リクエストから印刷ジョブを生成し、認証印刷部８８０がプルプリント部８６０に印刷リクエストする。当該フローは、実施例１記載の図８におけるＳ２４〜Ｓ２９における印刷スクリプトの処理に相当するが、ここでは認証印刷部８８０がこの処理を担う。図８におけるＳ２４〜Ｓ２９の詳細は実施例１に記載しているためＳ６３０〜Ｓ６３６の詳細は省略する。Ｓ６３７において認証印刷部８８０は印刷リクエストが完了すると印刷リクエスト完了画面（付図示）を生成し表示する。

＜認証印刷における印刷リクエスト検証＞
図１５は、プリントサーバ２１０が、図１４のＳ６２４で、認証印刷部８８０からの印刷リクエストを検証する処理フローである。プリントサーバ２１０は、Ｓ６２９で印刷リクエストを検証する際に、以下の処理を行う。プリントサーバ２１０は、印刷リクエストでドキュメントＩＤ、子トークン、プリンタ情報（モデル名１９０１、ＵＲＬ１９０２、シリアル番号１９０３）を受け取る（Ｓ７１）、まず認可サーバへ子トークンの検証をリクエストする（Ｓ７２）。Ｓ７２で、子トークンの検証リクエストを受け付けた認可サーバ２００は、受け付けた子トークンの認可トークンＩＤが、認可トークン管理テーブル１５００に登録されているか、有効期限内かを検証し、検証処理結果をプリントサーバ２１０に応答する。

プリントサーバ２１０は、Ｓ７３で認可サーバ２００からの検証結果で子トークンが無効だった場合には、Ｓ７５で印刷エラーを認証印刷部８８０に返す。認可サーバ２００からの検証結果で子トークンが有効だった場合、プリントサーバ２１０は認可サーバ２００に対して、子トークンの認可トークンＩＤに紐づくスコープとシリアル番号を要求する（Ｓ７４）。認可サーバ２００は、認可トークン管理テーブル１５００から受け付けた子トークンの認可トークンＩＤで特定されるスコープ１５０４とデバイスＩＤ（１４０１、１５０７）で紐づくシリアル番号１４０５を取得しプリントサーバ２１０に応答する。プリントサーバ２１０は、認可サーバ２００から取得したスコープが“認証印刷”であることを確認する。またプリントサーバ２１０は認可サーバ２００から取得したシリアル番号と一致するシリアル番号１４０５を持つプリンタがプリンタ管理テーブル２４００に存在するか確認する（Ｓ７６）。

Ｓ７６でプリンタが登録されてなかった場合、Ｓ７７でプリントサーバ２１０は認証印刷用のプリンタを一時的にプリンタ管理テーブル２４００に登録する。ここで登録するプリンタのプリンタＩＤ２４０１は、プリントサーバ２１０が発行・保存する。モデル名２４０３、ＵＲＬ２４０４、シリアル番号２４０５はＳ７１の印刷リクエストで受け取ったプリンタ情報を保存する。また、認証印刷用のプリンタとして種別２４０６に“認証印刷”を保存する。そしてＳ７６でシリアル番号が一致したプリンタ、またはＳ７７で登録したプリンタで印刷を実行する（Ｓ７８）。

認証印刷の場合、プリントサーバ２１０にプリンタが登録されていない場合がある。プリントサーバ２１０はプリンタ登録されていないため、実施例１に記載した印刷データ取得リクエストのトークン検証（Ｓ４５、Ｓ４６）を行うことができない。そこで、認証印刷時にユーザが権限移譲して生成される認可トークンに紐づくシリアル番号を用いて、プリントサーバ２１０が印刷リクエスト受付時に認証印刷用のプリンタを登録する（Ｓ７７）。プリントサーバ２１０にプリンタが登録されていない場合に認証印刷用プリンタが登録することで印刷データ取得リクエスト時のトークン検証を行うことができるようになる。このときプリンタ管理テーブル２４００に登録された例がｐｒｉ０００００４のレコードである。この時点で、図７を用いて説明した、Ｓ１５のプリンタ登録処理に類似する処理が行われたことになる。そして、プリントサーバ２１０は、Ｓ６３０において、ジョブ管理テーブル２２００に印刷ジョブを登録し、Ｓ６３７までの処理を行う。

＜印刷データ取得リクエストの検証＞
印刷データ取得リクエストの検証は、実施例１で前述した印刷データ取得リクエストの検証と同じ内容である。Ｓ４５（図１１）のプリントサーバ２１０の処理フローにおいて、デバイスＩＤとプリンタＩＤが一致するプリンタは図１５のＳ７７において一時的に登録されたプリンタ（種別２４０６が“認証印刷”）となる。

＜印刷完了通知＞
図１６はプリントサーバ２１０がプルプリント部８６０から印刷結果通知を受け付けた際の処理フローである。まず、プリントサーバ２１０は、印刷結果通知でプリンタＩＤ、印刷完了したデバイスジョブＩＤとその印刷結果を受け取る（Ｓ８１）。そしてプリントサーバ２１０は、ジョブ管理テーブル２２００から印刷結果通知で受け取ったプリンタＩＤとデバイスジョブＩＤの両方とも一致するジョブを検索しステータスを印刷結果で更新する（Ｓ８２）。印刷結果通知が完了を示す場合、プリントサーバ２１０はステータス２２０３を“印刷済み”に更新し、一方、エラーを示す場合、“エラー終了”に更新する。

次に、プリントサーバ２１０は、プリンタ管理テーブルから印刷結果通知で受け取ったプリンタＩＤと一致するプリンタを検索し種別２４０６が“認証印刷”かどうか確認する（Ｓ８３）。プリンタの種別２４０６が“認証印刷”だった場合、プリントサーバ２１０は、印刷結果通知で受け取ったプリンタＩＤと一致し、かつステータス２２０３に印刷結果が保存されていない印刷中のジョブがジョブ管理テーブル２２００に存在するか確認する（Ｓ８４）。印刷結果通知で受け取ったプリンタＩＤで印刷中のジョブがない場合、プリンタ管理テーブル２４００から印刷結果通知で受け取ったプリンタＩＤと一致するプリンタを削除する（Ｓ８５）。

認証印刷用プリンタは、プリントサーバ２１０が印刷リクエスト受付時にプリンタを登録していない場合に登録されるが、印刷が完了すれば不要になる。また、登録された認証印刷用プリンタは、管理者権限を持つユーザによって登録されたプリンタであるため、登録状態を保つことはセキュリティ上好ましくない。従って、プリントサーバ２１０が印刷結果通知を受け取った際に、認証印刷用プリンタで印刷中のジョブがない場合にプリンタを削除する。これにより不要なリソースを減らすこともできる（Ｓ８３、Ｓ８４）。

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

２００ 認可サーバ
２１０ プリントサーバ
２２０ クライアント端末
３００ 画像形成装置

Claims (12)

1. サービスを提供するサービス提供装置と、前記サービス提供装置が認証情報を求めることなくサービスを提供するために利用される認可情報を管理する認可サービス装置とを含む認証システムであって、
   前記認証システムと連携する情報処理装置の識別情報を前記サービス提供装置に登録する登録手段と、
   前記情報処理装置に対応する前記認可情報の発行に伴い、前記認可情報と前記情報処理装置の識別情報を紐付けて前記認可サービス装置に保存する保存手段と、
   前記サービスを受けるための要求と、発行された前記認可情報とを前記情報処理装置から取得したことに応じて、前記認可情報に紐付く前記情報処理装置の識別情報を前記認可サービス装置に問い合わせる問合せ手段と、
   前記問合せ手段による問い合わせの結果取得した情報処理装置の識別情報と、前記登録手段により登録されている情報処理装置の識別情報とが一致したことに応じて、前記要求に従い前記情報処理装置にサービスを提供する提供手段と、を備える
   ことを特徴とする認証システム。
2. 前記情報処理装置の識別情報の登録は、当該情報処理装置の管理者権限を有するユーザ装置または当該情報処理装置の操作画面を介して実行される
   ことを特徴とする請求項１に記載の認証システム。
3. 前記情報処理装置は、
   前記ユーザ装置から前記サービスを受けるための要求を受け付けて、前記認可サービス装置から前記認可情報を取得し、当該認可情報と前記サービスを受けるための要求を前記問合せ手段に送信する要求手段と、
   前記サービスを受けるための要求を前記問合せ手段に行う権限の移譲をユーザから受け、当該ユーザによる前記操作画面を要求する操作に応じて前記認可サービス装置から前記認可情報を取得し、当該認可情報と前記サービスを受けるための要求を前記問合せ手段に送信する移譲手段とを備える
   ことを特徴とする請求項２に記載の認証システム。
4. 前記認可サービス装置は、前記移譲手段からの要求に応じて、前記操作画面上での操作を行ったユーザに紐付く認可情報を生成して前記移譲手段に送信する
   ことを特徴とする請求項３に記載の認証システム。
5. 前記移譲手段は、
   前記認可サービス装置から取得した前記ユーザに紐付く認可情報の有効性の検証処理を前記問合せ手段に要求し、
   前記問合せ手段から前記認可情報が有効であることを示す検証処理結果を受け取った場合に、前記操作画面を表示する
   ことを特徴とする請求項４に記載の認証システム。
6. 前記登録手段は、
   前記移譲手段から取得した認可情報に紐付く前記情報処理装置の識別情報が登録されているかを判断し、当該情報処理装置の識別情報が登録されている場合に、当該情報処理装置に前記サービスを提供し、
   前記情報処理装置の識別情報が登録されていない場合に、当該情報処理装置の識別情報を一時的に登録する
   ことを特徴とする請求項３乃至５のいずれか１項に記載の認証システム。
7. 前記登録手段は、前記情報処理装置が前記提供されたサービスに応じた処理の実行を完了した場合に、前記登録手段は、前記一時的に登録した前記情報処理装置の識別情報を削除する
   ことを特徴とする請求項６記載の認証システム。
8. 前記提供手段が提供するサービスは、印刷ジョブの提供であり、
   前記情報処理装置は、前記提供された印刷ジョブに基づく印刷処理を実行する
   ことを特徴とする請求項１乃至７のいずれか１項に記載の認証システム。
9. 前記提供手段が提供するサービスは、印刷ジョブの提供であり、
   前記情報処理装置は、前記提供された印刷ジョブに基づく印刷処理を実行し、
   前記操作画面は、前記印刷処理の対象となるドキュメントの選択画面である
   ことを特徴とする請求項２乃至７のいずれか１項に記載の認証システム。
10. サービスを提供するサービス提供装置と、前記サービス提供装置が認証情報を求めることなくサービスを提供するために利用される認可情報を管理する認可サービス装置とを含む認証システムの制御方法であって、
    前記認証システムと連携する情報処理装置の識別情報を前記サービス提供装置に登録する登録工程と、
    前記情報処理装置に対応する前記認可情報の発行に伴い、前記認可情報と前記情報処理装置の識別情報を紐付けて前記認可サービス装置にて管理する管理工程と、
    前記サービスを受けるための要求と、発行された前記認可情報とを前記情報処理装置から取得したことに応じて、前記認可情報に紐付く前記情報処理装置の識別情報を前記認可サービス装置に問い合わせる問合せ工程と、
    前記問合せ工程による問い合わせの結果取得した情報処理装置の識別情報と、前記登録工程において登録されている情報処理装置の識別情報とが一致したことに応じて、前記要求に従い前記情報処理装置にサービスを提供する提供工程と、を有する
    ことを特徴とする制御方法。
11. サービス提供装置が認証情報を求めることなくサービスを提供するために利用される認可情報を管理する認可サービス装置と通信可能な前記サービス提供装置であって、
    前記サービス提供装置と連携する情報処理装置の識別情報を登録する登録手段と、
    前記サービスを受けるための要求と、発行された前記認可情報とを前記情報処理装置から取得したことに応じて、前記認可情報に紐付く前記情報処理装置の識別情報を前記認可サービス装置に問い合わせる問合せ手段と、
    前記問合せ手段による問い合わせの結果取得した情報処理装置の識別情報と、前記登録手段により登録されている情報処理装置の識別情報とが一致したことに応じて、前記要求に従い前記情報処理装置にサービスを提供する提供手段と、を備える前記サービス提供装置。
12. 請求項１１に記載のサービス提供装置が備えるコンピュータにより実行されるコンピュータプログラムであって、
    前記サービス提供装置と連携する情報処理装置の識別情報を登録する処理と、
    前記サービスを受けるための要求と、発行された前記認可情報とを前記情報処理装置から取得したことに応じて、前記認可情報に紐付く前記情報処理装置の識別情報を前記認可サービス装置に問い合わせる処理と、
    前記問い合わせる処理の結果取得した情報処理装置の識別情報と、前記登録する処理により登録されている情報処理装置の識別情報とが一致したことに応じて、前記要求に従い前記情報処理装置にサービスを提供する処理と、を前記コンピュータに実行させる
    ことを特徴とするコンピュータプログラム。
    

Images