JP2014232433A - 画像形成装置、サーバー装置、情報処理方法及びプログラム - Google Patents

Abstract

【課題】クラウドサービス上のユーザー情報が削除等された場合であっても、クラウドサービス上のデバイスリソースを編集可能とすることを目的とする。【解決手段】サーバーのユーザーと紐付かないデバイストークンを用いて、デバイスリソースとデバイスとを対応付けて管理し、課題を解決する。【選択図】図６

Description

本発明は、画像形成装置、サーバー装置、情報処理方法及びプログラムに関する。

近年インターネット上でＰＤＦ形式の電子文書を作成するサービスや電子文書を蓄積するサービス等が提供されている。このようなサービスを利用することでユーザーは、自身が所有する端末自体にＰＤＦ作成機能がない場合でもＰＤＦを作成できるようになる他、端末の記憶容量以上に電子文書を保管できるようにもなる。更に近年、クラウドサービスが一般化している（特許文献１）。

特開２０１２−２４３１１４号公報

クラウドサービスを提供するサーバーにおいて、デバイスリソースと、デバイスリソースを編集可能なユーザー情報と、を対応付けて管理している場合、サーバーにおいてユーザー情報が削除されるとデバイスリソースを編集できなくなる問題があった。

本発明は、サーバーにおいてユーザー情報が削除等された場合であっても、サーバー上のデバイスリソースを編集可能とすることを目的とする。

そこで、本発明は、デバイスの信用情報を含む、第１トークンの取得要求をサーバー装置に送信する第１トークン要求送信手段と、前記サーバー装置より前記デバイスの信用情報に対応する前記第１トークンを受信する第１トークン受信手段と、前記第１トークン受信手段により受信された前記第１トークンを記憶装置に記憶する記憶手段と、前記記憶手段により前記記憶装置に記憶された前記第１トークンを取得し、取得した前記第１トークンと、デバイスリソースを管理する管理手段を識別する識別情報と、を含む、第２トークンの取得要求をサーバー装置に送信する第２トークン要求送信手段と、前記サーバー装置より前記識別情報に対応する第２トークンを受信する第２トークン受信手段と、前記第２トークン受信手段により受信された前記第２トークンを含む、デバイスリソースに係る処理の要求を前記サーバー装置に送信するデバイスリソース要求送信手段と、を有する。

本発明によれば、サーバーにおいてユーザー情報が削除等された場合であっても、サーバー上のデバイスリソースを編集可能とすることができる。

デバイスリソース管理システムのシステム構成の一例を示す図である。 デバイスリソース管理システムを構成する各装置のハードウェア構成の一例を示す図である。 デバイスリソース管理システムを構成する各装置のソフトウェア構成の一例を示す図である。 認可サーバーが外部メモリに記憶するデータテーブルの一例を示す図である。 画像形成装置が外部メモリに記憶するデータテーブルの一例を示す図である。 シーケンス処理の一例を示す図（その１）である。 リソースサーバーが外部メモリに記憶するデバイスデータ管理テーブルの一例を示す図である。 シーケンス処理の一例を示す図（その２）である。 画面の一例を示す図である。 シーケンス処理の一例を示す図（その３）である。 アクセス権管理テーブルの一例を示す図である。 アクセス権設定処理のフローチャートである。

以下、本発明の実施形態について図面に基づいて説明する。

＜実施形態１＞
本実施形態においては、インターネット上で画像形成装置のデータを同期・保存するサービスと、保存したデータを編集するサービスと、がインターネット上のサーバー（サーバー装置）に設置されていることを想定している。
以降、上記サービスのように、インターネット上で機能を提供しているサービスを、リソースサービスと呼ぶ。
また本実施形態においては、画像形成装置上にインストールされたデータ同期アプリケーションがリソースサービスと連携することを想定している。
以降、データ同期アプリケーションのように、リソースサービスを利用するアプリケーションを、リソースサービス連携アプリケーションと呼ぶ。無論、リソースサービスは前記サービスには限られず、アプリケーションもデータ同期アプリケーションに限られるものではない。

更に本実施形態における権限の移譲ではＯＡｕｔｈの仕組みを利用する。ＯＡｕｔｈでは、ユーザーから移譲された権限を証明するための情報として、トークンと呼ばれる情報が利用される。ここで特に、ユーザーが画像形成装置に対して権限を移譲した場合のトークンを親トークンとする。本実施形態では、ユーザーの権限を画像形成装置のようなデバイスに移譲する。以下、例えば、画像形成装置上に印刷アプリケーション、帳票アプリケーションが存在する場合を考える。
この場合、ユーザーは、印刷アプリケーションからリソースサービスを利用する場合は印刷アプリケーションに、帳票アプリケーションからリソースサービスを利用する場合は帳票アプリケーションに、それぞれ個別に認可を与える必要がある。
ユーザーの立場で考えると、同一の画像形成装置からリソースサービスを利用する場合には、例えば、一度の認可操作でそれぞれのアプリケーションでリソースサービスを利用できるようになった方が、利便性が高い。
そこで、アプリケーションに権限を移譲させる際、ユーザーに代わり画像形成装置がアプリケーションに権限を移譲することで、ユーザーの認可操作の回数を低減させることができる。
即ち、ユーザーは、画像形成装置に権限を移譲した段階で、アプリケーションにも権限を移譲することを認めたこととなる。

但し、認可操作を一度で済ませる手段として、画像形成装置が取得した親トークンを、画像形成装置上のアプリケーションで共有できるようにするのは好ましくない。何故なら、親トークンを共有する全てのアプリケーションが全てのリソースサービスにアクセス可能となってしまうためである。これは、アプリケーションが共有された親トークンを用いてリソースサービスにアクセスした場合、リソースサービス側にてアクセス元のアプリケーションが特定できず、利用の可否を判断することができないためである。そこで、個々のリソースサービス連携アプリケーションは親トークンを直接使うのでなく、親トークンに移譲された情報を継承しつつ、アプリケーション毎に再移譲して発行されるトークンを用いるものとする。本実施形態において、親トークンをアプリケーション毎に再移譲して発行されたトークンを子トークンという。
更に本実施形態において、画像形成装置に対応した仮想的なサーバー上のユーザーをデバイスクライアントという。デバイスクライアントから移譲された権限を証明するための情報をデバイストークン、デバイスクライアントから画像形成装置に対して権限移譲した場合のトークンをデバイス親トークンという。更に、デバイス親トークンからアプリケーション毎に再移譲して発行されたデバイストークンをデバイス子トークンという。
本実施形態に係る権限移譲を利用したデバイスリソース管理システムは、図１に示すような構成のネットワーク上に実現される。

図１は、デバイスリソース管理システムのシステム構成の一例を示す図である。
ＷＡＮ１００は、Ｗｉｄｅ Ａｒｅａ Ｎｅｔｗｏｒｋであり、本実施形態ではＷｏｒｌｄ Ｗｉｄｅ Ｗｅｂ（ＷＷＷ）システムが構築されている。
ＬＡＮ１０１は、各構成要素を接続するＬｏｃａｌ Ａｒｅａ Ｎｅｔｗｏｒｋである。
認可サーバー２００は、ＯＡｕｔｈを実現するためのサーバーであり、認可サービスモジュールが実装されている。
リソースサーバー２１０は、データの同期・保存アプリケーションといったリソースサービスが実装されている。
なお、１台のリソースサーバーに設置されるリソースサービスは１つでもよく、複数でもよい。

クライアント端末２２０は、Ｗｅｂブラウザがインストールされている。
画像形成装置３００は、１つ又は複数のリソースサービス連携アプリケーションがインストールされている。
ユーザーはそれらのリソースサービス連携アプリケーションを用いてリソースサービスを利用する。また、認可サーバー２００、リソースサーバー２１０、クライアント端末２２０、画像形成装置３００は、それぞれＷＡＮ１００及びＬＡＮ１０１を介して接続されている。
なお、認可サーバー２００、リソースサーバー２１０、クライアント端末２２０、画像形成装置３００は、それぞれ個別のＬＡＮ上に構成されていてもよいし、同一のＬＡＮ上に構成されていてもよい。また、認可サーバー２００、リソースサーバー２１０は同一のサーバー装置上に構成されていてもよいし、別々のサーバー装置上に構成されてもよい。但し、本実施形態では、認可サーバー２００、リソースサーバー２１０は、別々のサーバー装置上に構成されているものとして説明を行う。

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

図２において、ＣＰＵ２３１は、ＲＯＭ２３３のプログラム用ＲＯＭに記憶された、或いはハードディスク（ＨＤ）等の外部メモリ２４１からＲＡＭ２３２にロードされたＯＳやアプリケーション等のプログラムを実行する。ＣＰＵ２３１は、システムバス２３４に接続される各ブロックを制御する。ここでＯＳとはコンピュータ上で稼動するオペレーティングシステムの略語であり、以下、オペレーティングシステムのことをＯＳと呼ぶ。後述する認可サーバー２００に係る各シーケンスの処理はＣＰＵ２３１がプログラムを実行することにより実現される。
ＲＡＭ２３２は、ＣＰＵ２３１の主メモリ、ワークエリア等として機能する。
キーボードコントローラ（ＫＢＣ）２３５は、キーボード（ＫＢ）２３９やポインティングデバイスからのキー入力を制御する。
ＣＲＴコントローラ（ＣＲＴＣ）２３６は、ＣＲＴディスプレイ（ＣＲＴ）２４０の表示を制御する。
ディスクコントローラ（ＤＫＣ）２３７は、各種データを記憶するハードディスク（ＨＤ）等の外部メモリ２４１におけるデータアクセスを制御する。
ネットワークコントローラ（ＮＣ）２３８は、ＷＡＮ１００若しくはＬＡＮ１０１を介して接続された画像形成装置３００や他の機器との通信制御処理を実行する。

ＣＰＵ２３１が、ＲＯＭ２３３又は外部メモリ２４１等に記憶されたプログラムに基づき処理を実行することによって、認可サーバー２００のソフトウェア構成及び後述する認可サーバー２００のシーケンスに係る処理が実現される。
同様に、リソースサーバー２１０のＣＰＵ２３１が、リソースサーバー２１０のＲＯＭ２３３又は外部メモリ２４１等に記憶されたプログラムに基づき処理を実行する。このことによって、リソースサーバー２１０のソフトウェア構成及び後述するリソースサーバー２１０のシーケンスに係る処理、フローチャートに係る処理等が実現される。

次に、画像形成装置３００の構成について説明する。
ＣＰＵ３０１は、画像形成装置３００のＣＰＵであり、ＲＯＭ３０２や、外部メモリ３０３に記憶された制御プログラムに基づいてシステムバス３０４に接続される各ブロックを制御する。ＣＰＵ３０１の処理により生成された画像信号が、印刷部Ｉ／Ｆ３０５を介して、印刷部３０６に出力情報として出力される。また、ＣＰＵ３０１は、入力部３０７とネットワーク部３１０とを介して、認可サーバー２００との通信処理が可能となっており、画像形成装置３００内の情報等を認可サーバー２００に通知できる。
ＲＯＭ３０２内のプログラムＲＯＭには、ＣＰＵ３０１の制御プログラム等が記憶されている。ＲＯＭ３０２内のフォント用ＲＯＭには、出力情報を生成する際に使用されるフォントデータ等が記憶されている。ＲＯＭ３０２内のデータ用ＲＯＭには、ハードディスク等の外部メモリ３０３がない画像形成装置の場合、認可サーバー２００と送受信を行う情報等が記憶されている。

ＲＡＭ３０８は、ＣＰＵ３０１の主メモリや、ワークエリア等として機能するＲＡＭであり、図示しない増設ポートに接続されるオプションＲＡＭによりメモリ容量を拡張することができるように構成されている。また、ＲＡＭ３０８は、出力情報展開領域、環境データ格納領域、ＮＶＲＡＭ等に用いられる。
外部メモリ３０３は、メモリコントローラ（ＭＣ）３０９によりアクセスを制御される。外部メモリ３０３は、オプションとして接続され、フォントデータ、エミュレーションプログラム、フォームデータ等が記憶されている。また、操作部３１１は操作のためのスイッチ及びＬＥＤ表示器等で構成されている。また、スキャナ部Ｉ／Ｆ３１２は、スキャナ部３１３から受け取った画像データをＣＰＵ３０１に通知したり、ユーザーが操作部３１１を介して原稿の画像読み取り開始を指示すると、スキャナ部３１３に原稿読み取り指示を通知したりする。スキャナ部３１３は、スキャナ部Ｉ／Ｆ３１２を介して原稿読み取り指示を受け取ると、原稿を読み取り、読み取った原稿データをスキャナ部Ｉ／Ｆ３１２に返す。
ＣＰＵ３０１が、ＲＯＭ３０２又は外部メモリ３０３等に記憶されたプログラムに基づき処理を実行することによって、画像形成装置３００のソフトウェア構成及び後述する画像形成装置３００のシーケンスに係る処理が実現される。

図３は、認可サーバー２００、リソースサーバー２１０、クライアント端末２２０、画像形成装置３００のそれぞれのソフトウェア構成（モジュール構成）を示す図である。
認可サーバー２００は、認可サーバーモジュール６００を有する。
リソースサーバー２１０は、リソースサーバーモジュール７００を有する。
クライアント端末２２０は、ＷＷＷを利用するためのユーザーエージェントであるＷｅｂブラウザ２２００を有する。
画像形成装置３００は、ＯＳ８２０、仮想マシン８１０、アプリケーション管理フレームワーク８００、Ｗｅｂブラウザ９００、アプリケーション管理アプリケーション８３０、ローカルログインアプリケーション１０００を有する。また、画像形成装置３００は、認可サーバー連携クライアント５００、リソースサービス連携アプリケーション４００を更に有する。

ＯＳ８２０は、一般的にはリアルタイムＯＳが適用されるが、昨今ではＬｉｎｕｘ（登録商標）等の汎用ＯＳが使用されることもある。
仮想マシン８１０は、例えばＪａｖａ（登録商標）ＶＭがよく知られている。仮想マシン８１０は、ＯＳ８２０で制御されるアプリケーションとして動作する仮想的なアプリケーション実行環境である。
アプリケーション管理フレームワーク８００は、仮想マシン８１０が提供するアプリケーション実行環境上で動作する管理対象のアプリケーションのライフサイクルを管理する機能を有する。また、アプリケーション管理フレームワーク８００は、前記機能を制御するＩ／Ｆ及び各アプリケーション間での処理要求を仲介するためのＩ／Ｆ公開機能を有する。ライフサイクルとはアプリケーションのインストール、起動、停止、アンインストールを含むアプリケーションの状態を示す。本実施形態におけるアプリケーション管理フレームワーク８００は、ＯＳＧｉ（Ｏｐｅｎ Ｓｅｒｖｉｃｅｓ Ｇａｔｅｗａｙ ｉｎｉｔｉａｔｉｖｅ）アライアンスで規定されたＯＳＧｉ（登録商標）として説明する。
また、認可サーバー連携クライアント５００、１つ又は複数のリソースサービス連携アプリケーション４００、ローカルログインアプリケーション１０００は、仮想マシン８１０が提供するアプリケーション実行環境にて動作する各種アプリケーションである。また、これらアプリケーションは、アプリケーション管理フレームワーク８００にてライフサイクル管理されている。

アプリケーション管理アプリケーション８３０は、アプリケーション管理フレームワーク８００が公開するライフサイクル管理用の制御Ｉ／Ｆを介して、ユーザーからの各種アプリケーションのインストールや、開始リクエストを受け付け、実行する。
ここで認可サーバー連携クライアント５００、リソースサービス連携アプリケーション４００、ローカルログインアプリケーション１０００は、予め画像形成装置３００にインストールされていてもよい。また、これらのアプリケーションは、アプリケーション管理アプリケーション８３０及びアプリケーション管理フレームワーク８００を介して後から画像形成装置３００にインストールされてもよい。更に、画像形成装置３００は、ＷＷＷを利用するためのユーザーエージェントであるＷｅｂブラウザ９００を有する。

図４ａ−図４ｄは認可サーバー２００が外部メモリに記憶するデータテーブルである。これらデータテーブルは、認可サーバー２００の外部メモリではなく、ＬＡＮ１０１を介して通信可能に構成された別のサーバーに記憶するようにしてもよい。
図４ａに示すテーブルは、ユーザー管理テーブル１２００である。
ユーザー管理テーブル１２００には、ユーザーＩＤ１２０１、パスワード１２０２、ユーザー種別１２０３、ロール１２０４が項目として含まれる。
認可サーバー２００は、ユーザーＩＤ１２０１とパスワード１２０２との情報の組を検証し、正しければ認証情報を生成することで、各ユーザー若しくはクライアントを認証する機能を備える。ここで、ロール１２０４は、それぞれのユーザーがどういった権限を持つかを示す情報である。

図４ｂに示すテーブルは、クライアント管理テーブル１３００である。
クライアント管理テーブル１３００には、クライアントＩＤ１３０１、クライアント名１３０２、リダイレクトＵＲＬ１３０３、シリアル番号１３０４が項目として含まれる。
クライアントＩＤ１３０１は、ユーザー管理テーブル１２００のユーザーＩＤ１２０１と関連付いており、認可サーバー２００は互いに参照することができる。クライアント名１３０２、リダイレクトＵＲＬ１３０３は、後述のＯＡｕｔｈのシーケンス処理で利用される値である。そして、シリアル番号１３０４は、クライアントが画像形成装置３００であった場合に登録される値であり、画像形成装置をユニークに識別可能な値である。

図４ｃに示すテーブルは、認可トークン管理テーブル１４００である。
認可トークン管理テーブル１４００には、認可トークンＩＤ１４０１、トークン種別１４０２、有効期限１４０３、スコープ１４０４、リフレッシュトークンＩＤ１４０５、リフレッシュ期限１４０６、クライアントＩＤ１４０７が項目として含まれる。また、認可トークン管理テーブル１４００には、更に、ユーザーＩＤ１４０８、アプリケーションＩＤ１４０９が項目として含まれる。
図４ｄに示すテーブルは、スコープ管理テーブル１８００である。
スコープ管理テーブル１８００には、スコープ１８０１、ロール１８０２が項目として含まれる。

図５ａ−図５ｃは画像形成装置３００が外部メモリに記憶するデータテーブルである。
図５ａに示すテーブルは、デバイスユーザー管理テーブル１５００である。
デバイスユーザー管理テーブル１５００は、ローカルログインアプリケーション１０００から参照、更新可能なように構成されている。また、デバイスユーザー管理テーブル１５００は、本実施形態では画像形成装置３００の外部メモリに記憶されているものとして記載しているが、画像形成装置３００がＬＡＮ１０１を介して通信可能な別サーバーに記憶されていてもよい。
デバイスユーザー管理テーブル１５００には、ユーザーＩＤ１５０１、パスワード１５０２、ＩＣカード情報１５０３、権限情報１５０４が項目として含まれる。
ローカルログインアプリケーション１０００は、画像形成装置３００の入力画面を用いてユーザーからのユーザーＩＤ、パスワードを受け付ける画面を構成する。そして、ローカルログインアプリケーション１０００は、入力されたユーザーＩＤとパスワードとの組が、ユーザーＩＤ１５０１とパスワード１５０２との組とあっているか検証する。ローカルログインアプリケーション１０００は、組み合わせが正しければユーザーＩＤ１５０１の情報を含むログインコンテキストを生成することで、各ユーザーを認証する機能を備える。

また、ローカルログインアプリケーション１０００は、画像形成装置３００に接続されたＩＣカードリーダーを利用してＩＣカード情報を取得し、ＩＣカード情報１５０３のデータとあっているか検証する。ローカルログインアプリケーション１０００は、検証が正しければ対応するユーザーＩＤ１５０１の情報を含むログインコンテキストを生成することで、各ユーザーを認証するようにしてもよい。ここで、ログインコンテキストとは、認証を受けたユーザーのユーザーＩＤ１５０１の情報が含まれたオブジェクトである。ログインコンテキストには、その他に、ユーザー保持している権限の権限情報１５０４や、ユーザーの属性情報、例えば、ユーザーが所属するドメインやユーザーの電子メールアドレス等の情報が含まれてもよい。

図５ｂのテーブルは、デバイス管理テーブル１６００である。
デバイス管理テーブル１６００は、認可サーバー連携クライアント５００のみから参照、更新可能なように構成されている。
デバイス管理テーブル１６００には、クライアントＩＤ１６０１、クライアントシークレット１６０２、エンドポイントＵＲＬ１６０３、リダイレクトＵＲＬ１６０４が項目として含まれる。ここで、クライアントＩＤ１６０１、クライアントシークレット１６０２は、予め認可サーバー２００にて発行、記憶されたユーザーＩＤ１２０１、パスワード１２０２にそれぞれ対応している。リダイレクトＵＲＬ１６０４も認可サーバー２００のクライアント管理テーブルにクライアントＩＤ１３０１、クライアント名１３０２、画像形成装置３００のシリアル番号１３０４と共に登録されているリダイレクトＵＲＬのデータと同様のデータが格納されている。これら情報の登録方法としては、例えば、画像形成装置３００が、ＬＡＮ１０１、ＷＡＮ１００を介してオンラインで値を登録する方法や、ユーザーがキーボードや操作部等を介して、認可サーバー２００や画像形成装置３００にそれぞれ値を設定する方法がある。なお、エンドポイントＵＲＬ１６０３は、認可サーバーが公開するＯＡｕｔｈのためのエンドポイントのＵＲＬである。
クライアントシークレットは、信用情報の一例である。

図５ｃのテーブルは、親トークン管理テーブル１７００である。
親トークン管理テーブル１７００は、認可サーバー連携クライアント５００からのみ参照、更新可能なよう構成されている。
親トークン管理テーブル１７００には、ユーザーＩＤ１７０１、認可トークンＩＤ１７０２、リフレッシュトークンＩＤ１７０３が項目として含まれる。

ここで、デバイストークンの取得と、画像形成装置のデータを、リソースサーバー２１０上で画像形成装置を一意に識別してデータを管理する方法と、に関する本実施形態のシーケンス処理を、図６を用いて説明する。
図６ａのシーケンス処理は、デバイス親トークンの取得に関するものであり、認可サーバー連携クライアント５００が最初に起動等された際に一度だけ行われる処理である。
まず、認可サーバー連携クライアント５００は、認可サーバー２００に対してトークン取得要求を送信する（Ｓ１１０）。このトークン取得要求には、デバイス管理テーブル１６００のクライアントＩＤ１６０１、クライアントシークレット１６０２が含まれる。ここで、認可サーバー連携クライアント５００は、トークンに必要なスコープを要求することもできる。但し、本実施形態では、スコープを要求しなかったものとして説明する。
Ｓ１１０の処理は、第１トークン要求送信の処理の一例である。また、Ｓ１１０におけるトークン取得要求は、第１トークンの取得要求の一例である。

トークン取得要求を受信した認可サーバー２００は、トークン取得要求で受けつけたクライアントＩＤとクライアントシークレットとの組がユーザー管理テーブル１２００に登録されているユーザーＩＤ１２０１とパスワード１２０２との組とあっているか検証する。
トークン取得要求を受信する処理は、第１トークン要求受信の処理の一例である。
正しい場合、認可サーバー２００は、デバイス親トークンを生成して（Ｓ１２０）、前記デバイス親トークンの認可トークンＩＤを応答として認可サーバー連携クライアント５００に送信する（Ｓ１３０）。この際、認可サーバー２００は、更に、応答内容として同時に発行したリフレッシュトークンＩＤも含めて送信する。
Ｓ１３０の処理は、第１トークン送信の処理の一例である。
認可サーバー２００は、デバイス親トークンとして、認可トークンＩＤ１４０１に発行したトークンのＩＤ、トークン種別１４０２にデバイス親トークン、有効期限１４０３に有効期限、クライアントＩＤ１４０７にクライアントＩＤを登録する。この際、認可サーバー２００は、デバイス親トークンをリフレッシュするためのリフレッシュトークンを発行し、リフレッシュトークンＩＤ１４０５にリフレッシュトークンＩＤ、リフレッシュ期限１４０６にリフレッシュ期限を登録する。
デバイス親トークンの認可トークンＩＤ、リフレッシュトークンＩＤを受信した認可サーバー連携クライアント５００は、親トークン管理テーブル１７００に、デバイス親トークンの認可トークンＩＤ、リフレッシュトークンＩＤを記憶する（Ｓ１４０）。
認可トークンＩＤ、リフレッシュトークンＩＤを受信する処理は、第１トークン受信の処理の一例である。

続いて、図６ｂにてデバイス親トークンが発行されたあとのデバイス子トークンの取得と、画像形成装置のデータを、リソースサーバー２１０上で画像形成装置を一意に識別して管理する方法と、に関する本実施形態のシーケンス処理を説明する。
本シーケンス処理は、ユーザーが画像形成装置３００のリソースサービス連携アプリケーション４００を実行した際に行われるシーケンス処理である。なお、本シーケンス処理の前に、前述のデバイス親トークン取得のシーケンス処理が実施されている必要がある。
まず、リソースサービス連携アプリケーション４００は、認可サーバー連携クライアント５００のトークン取得インターフェースに対してトークン取得要求を送信する（Ｓ１５０）。ここで、リソースサービス連携アプリケーション４００は、トークンに必要なスコープを要求することもできる。本実施形態では、スコープＡが要求されたとして説明する。

トークン取得要求を受信した認可サーバー連携クライアント５００は、アプリケーション管理フレームワーク８００を介して、要求元のリソースサービス連携アプリケーション４００のアプリケーションＩＤを取得する（Ｓ１６０）。
リソースサービス連携アプリケーション４００は、デバイスリソースを管理する管理手段の一例である。また、アプリケーションＩＤは、前記管理手段を識別する識別情報の一例である。
認可サーバー連携クライアント５００は、親トークン管理テーブル１７００からステップＳ１４０にて保存したリフレッシュトークンＩＤを取得する。
認可サーバー連携クライアント５００は、取得したリフレッシュトークンＩＤと、デバイス管理テーブル１６００のクライアントＩＤと、クライアントシークレットと、を用いて、認可サーバー２００にトークンリフレッシュ要求を送信する（Ｓ１７０）。ここでは、デバイス親トークン取得のシーケンス処理の実行から、デバイス子トークン取得のシーケンス処理までの間に時間が経過し、デバイス親トークンの有効期限が切れていることとして説明している。しかし、現時刻がデバイス親トークンの有効期限内で合った場合、認可サーバー連携クライアント５００は、トークンリフレッシュ要求を送信せず、後述するＳ１１１のデバイス子トークン取得要求を送信してもよい。

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

リフレッシュされたデバイス親トークンを取得した認可サーバー連携クライアント５００は、受信した認可トークンＩＤ、リフレッシュトークンＩＤで親トークン管理テーブル１７００のデータを上書きし、再登録する（Ｓ１１００）。
そして、認可サーバー連携クライアント５００は、認可サーバー２００にデバイス子トークン取得要求を送信する（Ｓ１１１０）。認可サーバー連携クライアント５００は、デバイス親トークンの認可トークンＩＤと、デバイス管理テーブル１６００のクライアントＩＤ及びクライアントシークレットと、トークン取得要求で受けつけたスコープと、取得したアプリケーションＩＤと、を送信する。
Ｓ１１１０の処理は、第２トークン要求送信の処理の一例である。また、デバイス子トークン取得要求は、第２トークンの取得要求の一例である。

デバイス子トークン取得要求を受信した認可サーバー２００は以下の処理を実行する。
ここで、デバイス子トークン取得要求を受信する処理は、第２トークン要求受信の処理の一例である。
まず、認可サーバー２００は、デバイス子トークン取得要求に含まれるクライアントＩＤとクライアントシークレットとの組がユーザー管理テーブル１２００のユーザーＩＤ１２０１とパスワード１２０２との組とあっているかを検証する。正しい場合、認可サーバー２００は、デバイス子トークン取得要求に含まれる認可トークンＩＤが認可トークン管理テーブル１４００に登録されており、現時刻が有効期限内か否か、デバイス親トークンの有効性を確認する。更に、認可サーバー２００は、デバイス子トークン取得要求に含まれるクライアントＩＤがクライアントＩＤ１４０７と一致するか否かを検証する。全ての検証が正しい場合、認可サーバー２００は、デバイス子トークンを生成し（Ｓ１１２０）、応答として認可サーバー連携クライアント５００に送信する（Ｓ１１３０）。なお、認可サーバー２００は、タイマー等を有し、現時刻を取得することができるものとする。
Ｓ１１３０の処理は、第２トークン送信の処理の一例である。また、前記検証の処理は、第１トークン検証の処理の一例である。

ここで、認可サーバー２００は、新たにデバイス子トークンの認可トークンＩＤを発行する。認可サーバー２００は、認可トークン管理テーブル１４００のトークン種別１４０２にデバイス子トークン、アプリケーションＩＤ１４０９に取得したアプリケーションＩＤ、スコープ１４０４にデバイス子トークン取得要求に含まれるスコープを登録する。この際、認可サーバー２００は、子トークン取得要求で受けつけた認可トークンＩＤによって特定されるレコードのクライアントＩＤ１４０７のデータを引き継ぐ。結果、このとき発行されたデバイス子トークンには、画像形成装置を特定するためのクライアントＩＤ及びアプリケーションを特定するためのアプリケーションＩＤが紐付けされる。
なお、認可サーバー２００は、デバイス子トークンのリフレッシュトークンは発行しない。これは、トークンリフレッシュ要求するためにはクライアントＩＤ、クライアントシークレットが必要であるため、デバイス子トークンを利用する各アプリケーションではリフレッシュ要求はできないこととするためである。更には、各アプリケーションがリフレッシュトークンを漏洩することで、自由にトークンの有効期限を更新されてしまうセキュリティリスクをなくすためである。

そして、デバイス子トークンの認可トークンＩＤを受信した認可サーバー連携クライアント５００は、要求元のリソースサービス連携アプリケーション４００にデバイス子トークンの認可トークンＩＤを応答として送信する。
許可トークンＩＤの受信は、第２トークン受信の処理の一例である。
デバイス子トークンの認可トークンＩＤを取得したリソースサービス連携アプリケーション４００は、リソースサーバー２１０に認可トークンＩＤを含むリソース要求を送信する（Ｓ１１４０）。本リソース要求では、画像形成装置３００の宛先表データを送信し保存する要求や、リソースサーバー２１０に保存してある宛先表データを受信するための要求等がある。
Ｓ１１４０の処理は、デバイスリソース要求送信の処理の一例である。

リソース要求を受信したリソースサーバー２１０は、要求に含まれるデバイス子トークンの認可トークンＩＤを含むトークン検証要求を認可サーバー２００に対して送信する（Ｓ１１５０）。リソースサーバー２１０は、このトークン検証要求に、スコープを含めることができる。
リソース要求の受信は、デバイスリソース要求受信の処理の一例である。
トークン検証要求を受信した認可サーバー２００は、受信した認可トークンＩＤが認可トークン管理テーブル１４００に登録されているか否かを検証する（Ｓ１１６０）。また、認可サーバー２００は、現時刻が有効期限内か、及び、受信したスコープがスコープ１４０４に記憶されているスコープの範囲内かを検証する。そして、認可サーバー２００は、リソースサーバー２１０に検証結果を応答として送信する（Ｓ１１７０）。
前記検証の処理は、第２トークン検証の処理の一例である。

次に、リソースサーバー２１０は、認可サーバー２００に対して、デバイス子トークンの認可トークンＩＤのトークン情報取得要求を送信する（Ｓ１１８０）。
トークン情報取得要求を受信した認可サーバー２００は、認可トークン管理テーブル１４００から受信した認可トークンＩＤにて特定される情報を取得し、これらの情報を応答としてリソースサーバー２１０に送信する（Ｓ１１９０）。この応答には、例えば、スコープ１４０４、クライアントＩＤ１４０７、アプリケーションＩＤ１４０９のデータと、クライアントＩＤ１４０７にて特定されるクライアント管理テーブル１３００に登録されているシリアル番号１３０４のデータが含まれる。
トークン情報を取得したリソースサーバー２１０は、取得した情報を基に要求を受信したリソースに対するアクセスを許可するか拒否するかを判断する。ここでは、リソースサーバー２１０に予めアクセス可能なアプリケーションＩＤが設定されているものとする。リソースサーバー２１０は、この設定されているアプリケーションＩＤと、トークン情報から取得されたアプリケーションＩＤと、を比較することでアクセスを許可するかを検証する（Ｓ１２００）。検証の結果、アクセス許可と判断した場合、リソースサーバー２１０は、提供するサービスの処理を実施する（Ｓ１２１０）。例えば、画像形成装置の宛先表データの保存処理が要求されている場合、リソースサーバー２１０は、トークン情報から取得されたクライアントＩＤ１４０７に紐づけて宛先表データを保持する処理を実行する。
Ｓ１２１０の処理は、サービス実行の処理の一例である。
本処理により、画像形成装置を一意に特定してリソースサーバー２１０上で宛先表データを管理することが可能となる。サービス処理が終了した場合、リソースサーバー２１０は、リソースサービス連携アプリケーション４００に対して、リソース要求に対する結果等をリソース応答として送信する（Ｓ１２２０）。ここで、リソース要求が宛先表データを受信するための要求であった場合、リソース要求に対する結果等は、宛先表データとなる。

ここで、Ｓ１１５０からＳ１２００までの処理において、トークンの検証を認可サーバー２００、リソースサーバー２１０のそれぞれで行うよう説明した。しかし、リソースに対するアクセス可能なアプリケーションを認可サーバー２００で管理し、全ての検証を認可サーバー２００で行うようにしてもよい。また、本実施形態ではアクセス可能なアプリケーションの判断を、アプリケーションＩＤを用いて行うように説明した。しかしながら、リソースサーバー２１０は、トークン情報から取得できるスコープを基にアクセスの可否を判断するようにしてもよい。
リソース応答を受信したリソースサービス連携アプリケーション４００は、リソース応答を基に処理を行う。リソースサービス連携アプリケーション４００は、リソースサーバー２１０からリソース応答として宛先表データを取得した場合には、画像形成装置３００の宛先表データの設定を更新する処理を行う。
これら、デバイス親トークン取得のシーケンス処理及びデバイス子トークン取得のシーケンス処理によって、リソースサーバー２１０は、アクセスしてきた画像形成装置とアプリケーションとを識別することが可能となる。また、リソースサーバー２１０上で画像形成装置を一意に識別して、画像形成装置のデータを保持することが可能となる。

図７は、リソースサーバー２１０が外部メモリに記憶するデバイスデータ管理テーブルの一例を示す図である。このデバイスデータ管理テーブルは、画像形成装置３００のデータをリソースサーバー２１０上に保持するためのテーブルである。
デバイスデータ管理テーブル１９００は、リソースサーバー２１０から参照、更新可能なように構成されている。デバイスデータ管理テーブル１９００には、クライアントＩＤ１９０１、シリアル番号１９０２、データ１９０３が項目として含まれる。クライアントＩＤ１９０１、シリアル番号１９０２にはクライアント管理テーブル１３００のクライアントＩＤ１３０１、シリアル番号１３０４のそれぞれに対応した値が記録される。リソースサーバー２１０は、前述のステップＳ１１９０にて認可サーバー２００より取得された情報を基にデータを記録する。データ１９０３にはステップＳ１１４０で画像形成装置３００から送信された、例えば、宛先表データが記録される。

以上、本実施形態によれば、デバイスリソース（例えば、宛先表データ）とデバイス（画像形成装置）とを対応付けて管理することができる。そのため、サーバー上でユーザー情報が削除された場合でも、デバイスリソースを管理し、編集等することができる。

＜実施形態２＞
上述した実施形態１に示したように、デバイスリソースとデバイスとを対応付けて管理すると、サーバーにログインしたどのユーザーがデバイスリソースを編集してよいのか否かの制御ができなくなってしまう。
以下、本実施形態では、デバイスのデバイスリソースを編集できるユーザーがサーバーにあるデバイスリソースを編集できるようにする処理について説明を行う。

親トークン取得に関する本実施形態のシーケンス処理等を図８、図９を用いて説明する。
本シーケンス処理は、ユーザーが画像形成装置３００を最初に利用する際に一度だけ行われる操作である。
まずユーザーが画像形成装置３００においてローカルログインアプリケーション１０００が提供するログイン手段を用いて画像形成装置３００にログインする（Ｓ２１０）。ここでユーザーＩＤがｕｓｅｒ００１のユーザーがログインしたとする。すると、ローカルログインアプリケーション１０００は、ｕｓｅｒ００１を含むログインコンテキストを生成し、アプリケーション管理フレームワーク８００を介して各アプリケーションから取得可能なようにＲＡＭ３０８に格納する（Ｓ２２０）。
次に、ユーザーは、画像形成装置３００を操作してＷｅｂブラウザ９００を起動等する。Ｗｅｂブラウザ９００は、ユーザーの操作に基づいて、認可サーバー連携クライアント５００の認可連携を開始するためのＵＲＬへアクセスする（Ｓ２３０）。ここで認可サーバー連携クライアント５００は、図９ａに示すような認可連携開始を確認する画面２００１を応答に含めて送信するようにしてもよい。

認可サーバー連携クライアント５００は、認可連携の開始を受け付けると以下の処理を行う。即ち、認可サーバー連携クライアント５００は、デバイス管理テーブル１６００のエンドポイントＵＲＬ１６０３に記載のＵＲＬに対してＯＡｕｔｈの認可リクエストをするようＷｅｂブラウザ９００にリダイレクト要求を送信する（Ｓ２４０）。この認可リクエストには、デバイス管理テーブル１６００のクライアントＩＤ１６０１、リダイレクトＵＲＬ１６０４の情報が含まれる。また、ＯＡｕｔｈでは、認可を受けたい権限範囲を示すスコープを認可リクエストに含めるようにすることもできる。本実施形態では、スコープとしてスコープＡがリクエストされたとして説明する。
認可リクエストを受信した認可サーバー２００は、ユーザーを認証するために図９ｂに示すログイン画面２００２をＷｅｂブラウザ９００に応答として送信する（Ｓ２５０）。ユーザーは、Ｗｅｂブラウザ９００に示されたログイン画面２００２に対して、ユーザーＩＤ、パスワードを入力しログインを実行する（Ｓ２６０）。

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

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

認可応答を受けた認可サーバー連携クライアント５００は、認可サーバー２００に対してトークン要求を送信する（Ｓ２１００）。このトークン要求には、認可応答で取得した認可コードの認可トークンＩＤ、デバイス管理テーブル１６００のクライアントＩＤ１６０１、クライアントシークレット１６０２、リダイレクトＵＲＬ１６０４のデータが含まれる。
トークン要求を受信した認可サーバー２００は、以下の検証を行い、正しい場合は親トークンを生成する（Ｓ２１１０）。
認可サーバー２００は、トークン要求で受けつけたクライアントＩＤとクライアントシークレットとの組が、ユーザー管理テーブル１２００に登録されているユーザーＩＤ１２０１とパスワード１２０２との組とあっているか検証する。次に、認可サーバー２００は、トークン要求で受けつけた認可コードの認可トークンＩＤが、認可トークン管理テーブル１４００に登録されているか、現時刻が有効期限内かを検証する。そして、認可サーバー２００は、トークン要求で受けつけたクライアントＩＤと認可トークン管理テーブル１４００の認可トークンＩＤで特定されるクライアントＩＤ１４０７のデータとがあっているかを検証する。更には、認可サーバー２００は、トークン要求で受信したリダイレクトＵＲＬとクライアント管理テーブル１３００のリダイレクトＵＲＬ１３０３のデータとがあっているかを検証する。

ここで、認可サーバー２００は、認可トークン管理テーブル１４００にカラムを追加し、認可コード発行時に前記カラムにリダイレクトＵＲＬを登録しておく。そして、認可サーバー２００は、トークン要求で受信したリダイレクトＵＲＬと前記カラムのリダイレクトＵＲＬとを比較し、あっているか否かを検証するようにしてもよい。
これら全ての検証が正しい場合、認可サーバー２００は、親トークンを生成して、親トークンの認可トークンＩＤを認可サーバー連携クライアント５００に親トークン応答として送信する（Ｓ２１２０）。この際、認可サーバー２００は、同時に発行したリフレッシュトークンＩＤも含めて親トークン応答として送信する。

認可サーバー２００は、親トークンとしては、認可トークンＩＤ１４０１に発行したトークンのＩＤ、トークン種別１４０２に親トークン、有効期限１４０３に有効期限を登録する。また、認可サーバー２００は、認可コードから引き継ぐデータとして、クライアントＩＤ１４０７にクライアントＩＤ、ユーザーＩＤ１４０８にユーザーＩＤを登録する。この際、認可サーバー２００は、親トークンをリフレッシュするためのリフレッシュトークンを発行し、リフレッシュトークンＩＤ１４０５にリフレッシュトークンＩＤ、リフレッシュ期限１４０６にリフレッシュ期限を登録する。
親トークン応答を受信した認可サーバー連携クライアント５００は、アプリケーション管理フレームワーク８００を介して画像形成装置３００にログインしているユーザーのログインコンテキストを取得する（Ｓ２１３０）。
認可サーバー連携クライアント５００が親トークン応答から親トークンを取得する処理は、第３トークンを取得する処理の一例である。なお、Ｓ２１００のトークン要求を送信する処理及びＳ２１２０の親トークンを受信する処理を、第３トークンを取得する処理の一例としてもよい。
そして、認可サーバー連携クライアント５００は、ログインコンテキストからデバイスユーザーＩＤを取得し、親トークン管理テーブル１７００に、デバイスユーザーＩＤ、親トークンの認可トークンＩＤ、リフレッシュトークンＩＤを保存する（Ｓ２１４０）。
ここで、デバイスユーザーＩＤとは、ユーザーＩＤ１５０１の情報のことである。
そして、認可サーバー連携クライアント５００は、認可連携完了の旨を示す画面をＷｅｂブラウザ９００に応答し（Ｓ２１５０）、処理を終了する。

続いて、親トークンが発行されたあとの子トークンの取得及びリソースサーバーに対するアクセス権設定に関する本実施形態のシーケンス処理を、図１０を用いて説明する。
本シーケンス処理は、ユーザーがリソースサーバー２１０に保存されている画像形成装置３００のデータに対してアクセス権を設定する場合に行われるシーケンス処理である。なお、前述の親トークン取得のシーケンス処理が実施されている必要がある。
まずユーザーが画像形成装置３００においてローカルログインアプリケーション１０００が提供するログイン手段を用いて画像形成装置３００にログインする（Ｓ３１０）。ここでユーザーＩＤがｕｓｅｒ００１のユーザーがログインしたとする。
すると、ローカルログインアプリケーション１０００は、ｕｓｅｒ００１を含むログインコンテキストを生成し、アプリケーション管理フレームワーク８００を介して各アプリケーションから取得可能なようにＲＡＭ３０８に格納する（Ｓ３２０）。なお、前述の親トークン取得のシーケンス処理の後に連続して処理を実行する場合は、再度ログインする必要はなく、次のＳ３３０からのシーケンス処理となる。

ユーザーは、画像形成装置３００を操作してリソースサービス連携アプリケーション４００のアプリケーション画面にアクセスする（Ｓ３３０）。このアプリケーション画面は例えば、リソースサービス連携アプリケーション４００が画像形成装置のデータを同期・保存するアプリケーションであった場合は、対象となるデータを選択しアクセス権を設定するための画面等である。ここでアプリケーション画面にアクセスするとは、例えば、画像形成装置３００が備える操作パネル上からアプリケーションを選択することを指す。なお、アプリケーションは、アプリケーション管理フレームワーク８００によって開始状態とされ、操作パネル上に選択可能な状態で表示される。

アプリケーション画面にアクセスされたリソースサービス連携アプリケーション４００は、アプリケーション管理フレームワーク８００からログインコンテキストを取得し、ログインユーザーの権限をチェックする（Ｓ３４０）。リソースサービス連携アプリケーション４００は、本権限チェックを、ログインコンテキストに含まれる権限情報１５０４のデータを基に行う。例えば権限情報１５０４がａｄｍｉｎであればそのユーザーは管理者としての権限を持ち、ｕｓｅｒであれば一般者としての権限を持つことになる。権限のチェックは、リソースサービス連携アプリケーション４００が扱う対象データとユーザーの権限情報に応じたレベルとに応じてその後の処理を切り分けるために行われる。例えば、リソースサービス連携アプリケーション４００は、画像形成装置の宛先表データを保存・同期する場合、ユーザーが管理者である場合はアクセス権設定できるが、一般者であった場合には行えない、等の判断を行う。この様な処理により、画像形成装置のユーザーの権限に応じて、クラウド上での画像形成装置データへのアクセス方法を変えることができる。

次に、リソースサービス連携アプリケーション４００は、アプリケーション管理フレームワーク８００に登録されている認可サーバー連携クライアント５００のトークン取得インターフェースに対してトークン取得要求を送信する（Ｓ３５０）。この際、リソースサービス連携アプリケーション４００は、取得したログインコンテキストとスコープとをトークン取得要求に含める。本実施形態では、スコープＡが引き続き要求されたとして説明する。なお、スコープは、ユーザーが管理者で宛先表データにアクセス要求する場合のスコープをスコープＡ、ユーザーが管理者でシステム設定情報にアクセス要求をする場合のスコープをスコープＢ等と定義される。ユーザーの権限と対象データとに応じてスコープが定義され、リソースサービス連携アプリケーション４００は、トークン取得要求する際にトークン取得要求に含めるスコープを切り替える。
トークン取得要求を受信した認可サーバー連携クライアント５００は、アプリケーション管理フレームワーク８００を介して、要求元のリソースサービス連携アプリケーション４００のアプリケーションＩＤを取得する（Ｓ３６０）。

アプリケーションＩＤを取得した認可サーバー連携クライアント５００は、以下の処理を行う。
まず、認可サーバー連携クライアント５００は、取得したログインコンテキストが有効かどうかアプリケーション管理フレームワーク８００を介して検証する。そして、認可サーバー連携クライアント５００は、正しい場合はログインコンテキストに紐づいたデバイスユーザーＩＤを取得する。なお、このログインコンテキストの検証は、認可サーバー連携クライアント５００で実施するよう説明したが、別の方法でもよい。例えば、ログインコンテキストのインスタンス生成をアプリケーション管理フレームワーク８００のみが行えるようにし、インスタンスが生成されていることによって、正当であると判断するようにしてもよい。

次に、認可サーバー連携クライアント５００は、取得したデバイスユーザーＩＤをキーに親トークン管理テーブル１７００からリフレッシュトークンＩＤを取得する。このとき、親トークン管理テーブル１７００にユーザーＩＤが登録されていない場合、認可サーバー連携クライアント５００は、親トークン取得シーケンス処理を実施するようユーザーに促す画面を提示するようにしてもよい。また、認可サーバー連携クライアント５００は、Ｗｅｂブラウザ９００を起動し、親トークン取得シーケンスの処理を自動的に開始するようにしてもよい。
認可サーバー連携クライアント５００は、取得したリフレッシュトークンＩＤ、デバイス管理テーブル１６００のクライアントＩＤ、クライアントシークレットを用いて、認可サーバー２００にトークンリフレッシュ要求を送信する（Ｓ３７０）。なお、ここでは、親トークン取得シーケンス処理の実行から、子トークン取得のシーケンス処理までの間に時間が経過し、親トークンの有効期限が切れていることとして説明した。しかし、親トークンの有効期限内で合った場合、認可サーバー連携クライアント５００は、トークンリフレッシュ要求を送信せず、後述するＳ３１１０の子トークン取得要求を送信してもよい。

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

リフレッシュされた親トークンを取得した認可サーバー連携クライアント５００は、受信した認可トークンＩＤ、リフレッシュトークンＩＤにて、親トークン管理テーブルの情報を上書きし、再登録する（Ｓ３１００）。
そして、認可サーバー連携クライアント５００は、認可サーバー２００に子トークン取得要求を送信する（Ｓ３１１０）。その際、認可サーバー連携クライアント５００は、親トークンの認可トークンＩＤ、デバイス管理テーブル１６００のクライアントＩＤ、クライアントシークレット、トークン取得要求で受けつけたスコープ、取得したアプリケーションＩＤを送信する。
Ｓ３１１０の処理は、第４トークン要求送信の処理の一例である。また、前記スコープは、アクセス範囲情報の一例である。

子トークン取得要求を受信した認可サーバー２００は、以下の処理を実行する。
まず、認可サーバー２００は、子トークン取得要求に含まれるクライアントＩＤとクライアントシークレットとの組がユーザー管理テーブル１２００のユーザーＩＤ１２０１とパスワード１２０２との組とあっているかを検証する。正しい場合、認可サーバー２００は、子トークン取得要求に含まれる認可トークンＩＤが認可トークン管理テーブル１４００に登録されており、現時刻が有効期限内か確認する。更に、認可サーバー２００は、子トークン取得要求に含まれるクライアントＩＤがクライアントＩＤ１４０７のデータと一致するか否かを検証する。
また、認可サーバー２００は、アクセス要求してきたユーザーがそのスコープにアクセスしてよいかを検証する。まず、認可サーバー２００は、要求されたスコープにアクセス権を持つロールをスコープ管理テーブル１８００のロール１８０２より取得する。次に、認可サーバー２００は、子トークン要求に含まれるユーザーＩＤを基にユーザーが保持しているアクセス権をユーザー管理テーブル１２００のロール１２０４より取得する。認可サーバー２００は、これらのロールが一致するか否かを検証する。
全ての検証が正しい場合、認可サーバー２００は、子トークンを生成し（Ｓ３１２０）、応答として認可サーバー連携クライアント５００に送信する（Ｓ３１３０）。

ここで、認可サーバー２００は、子トークンには新たに認可トークンＩＤを発行する。認可サーバー２００は、認可トークン管理テーブル１４００のトークン種別１４０２に子トークン、アプリケーションＩＤ１４０９に取得したアプリケーションＩＤ、スコープ１４０４に子トークン取得要求に含まれるスコープを登録する。この際、認可サーバー２００は、子トークン取得要求で受けつけた認可トークンＩＤによって特定されるレコードのクライアントＩＤ１４０７、ユーザーＩＤ１４０８のデータを引き継ぐ。結果、このとき発行した子トークンには、ユーザーを特定するためのユーザーＩＤ、画像形成装置を特定するためのクライアントＩＤ及びアプリケーションを特定するためのアプリケーションＩＤが紐づけられる。なお、認可サーバー２００は、子トークンにはリフレッシュトークンは発行しない。これは、トークンリフレッシュ要求するためにはクライアントＩＤ、クライアントシークレットが必要であるため、子トークンを利用する各アプリケーションではリフレッシュ要求はできないこととするためである。更には、各アプリケーションがリフレッシュトークンを漏洩することで、自由にトークンの有効期限を更新されてしまうセキュリティリスクをなくすためである。

そして、子トークンの認可トークンＩＤを受信した認可サーバー連携クライアント５００は、要求元のリソースサービス連携アプリケーション４００に子トークンの認可トークンＩＤを応答として送信する。
ここで、子トークンの許可トークンＩＤの受信は、第４トークン受信の一例である。
子トークンの認可トークンＩＤを取得したリソースサービス連携アプリケーション４００は、リソースサーバー２１０に認可トークンＩＤを含むリソース要求を送信する（Ｓ３１４０）。
Ｓ３１４０の処理は、アクセス制御要求送信の処理の一例である。また、リソース要求は、アクセス制御処理の要求の一例である。
リソース要求を受信したリソースサーバー２１０は、要求に含まれる子トークンの認可トークンＩＤのトークン検証要求を認可サーバー２００に対して送信する（Ｓ３１５０）。リソースサーバー２１０は、このトークン検証要求に、スコープを含めることができる。
トークン検証要求を受信した認可サーバー２００は、受信した認可トークンＩＤが、認可トークン管理テーブル１４００に登録されているか検証する（Ｓ３１６０）。また、認可サーバー２００は、現時刻が有効期限内か、及び、受信したスコープがスコープ１４０４に記憶されているスコープの範囲内かを検証する。そして、認可サーバー２００は、検証結果をリソースサーバー２１０に応答として送信する（Ｓ３１７０）。

次に、リソースサーバー２１０は、認可サーバー２００に対して、子トークンの認可トークンＩＤのトークン情報取得要求を送信する（Ｓ３１８０）。
トークン情報取得要求を受信した認可サーバー２００は、認可トークン管理テーブル１４００から受信した認可トークンＩＤにて特定されるデータを取得し、取得したデータ（トークン情報）を応答としてリソースサーバー２１０に送信する（Ｓ３１９０）。この応答には、例えば、スコープ１４０４、クライアントＩＤ１４０７、ユーザーＩＤ１４０８、アプリケーションＩＤ１４０９のデータが含まれる。更には、この応答には、クライアントＩＤ１４０７にて特定されるクライアント管理テーブル１３００に登録されているシリアル番号１３０４のデータが含まれる。
トークン情報取得要求を受信したリソースサーバー２１０は、取得したトークン情報を基に、リソース要求に係るリソースに対するアクセスを許可するか拒否するかを判断する。まず、リソースサーバー２１０に予めアクセス可能なアプリケーションＩＤが設定されているとし、その設定されているアプリケーションＩＤと、トークン情報から取得されたアプリケーションＩＤと、を比較する。これにより、リソースサーバー２１０は、アクセス元が正しいリソースサービス連携アプリケーション４００であるかを検証する（Ｓ３２００）。次に、リソースサーバー２１０は、取得したシリアル番号を基にデバイスデータ管理テーブル１９００より対象となるデータを特定し、アクセス権を設定する（Ｓ３２１０）。

図１１にて、アクセス権の設定に関して説明する。図１１は、アクセス権管理テーブル２１００の一例を示す図である。アクセス権管理テーブル２１００は、リソースサーバー２１０から参照、更新可能なように構成されている。アクセス権管理テーブル２１００は、クライアントＩＤ２１０１、シリアル番号２１０２、ユーザーＩＤ２１０３、アクセス権２１０４を項目として含む。クライアントＩＤ２１０１、シリアル番号２１０２は、デバイスデータ管理テーブル１９００のクライアントＩＤ１９０１、シリアル番号１９０２のそれぞれに対応した値が記録される。ユーザーＩＤ２１０３にはトークン情報から取得されたユーザーＩＤ、アクセス権２１０４には編集、参照といったアクセスレベルが記録される。本設定に基づいて、どのユーザーがどのデバイスリソース管理システムのデータにアクセス可能かが決定される。

本アクセス設定に関して図１２のアクセス権設定処理のフローチャートを用いて説明を行う。
まず、リソースサーバー２１０は、対象となる画像形成装置のデータ・処理が複数のユーザーで共有可能か否かをチェックする（Ｓ４１０）。例えば、ユーザーＡが画像形成装置Ａ、Ｂ、Ｃ、３台の宛先表データに対して編集アクセス権を持ち、更にそれらの宛先表データが常に同じになるような同期設定をしたとする。同じく、ユーザーＢが画像形成装置Ｃ、Ｄ、Ｅ、３台の宛先表データに対して編集アクセス権を持ち、更にそれら宛先表データが常に同じになるような同期設定をしたとする。この場合、ユーザーＡが画像形成装置Ａ、Ｂ、Ｃの何れかの宛先表データを編集すると、サーバー上のデータ及び画像形成装置Ａ、Ｂ、Ｃのデータが全て同じものになる。その後、ユーザーＢの設定に基づいて、画像形成装置Ｃの宛先表データがＤ、Ｅにも同様に設定されてしまう。このような場合、ユーザーＡの設定が本来アクセスしてはならない画像形成装置にまで及んでしまう。このため画像形成装置の宛先表データに対しては複数のユーザーから編集の共有をしてはいけないことになる。なお、本チェック処理の判断基準は、リソースサーバーの機能、対象となる画像形成装置のデータ、操作するユーザーの権限等に応じてそれぞれ異なる判断基準となる。

ステップＳ４１０でのチェックにより共有してよい場合、リソースサーバー２１０は、アクセス権を追加する処理を行う（Ｓ４２０）。共有してはいけない場合、リソースサーバー２１０は、対象となるデータに既存のアクセス権設定が既にあるかをチェックする（Ｓ４３０）。アクセス設定が無い場合には、リソースサーバー２１０は、通常通りアクセス権を追加する処理を行う（Ｓ４２０）。
アクセス権設定が既にある場合、リソースサーバー２１０は、アクセス設定されているユーザーが新たなアクセス許可を求めているユーザーと同じか否かをチェックする（Ｓ４４０）。同じ場合、リソースサーバー２１０は、特に処理を行わない。異なる場合、リソースサーバー２１０は、既存のアクセス設定を解除し、新規に新しいアクセス設定を行う（Ｓ４５０）。

このような処理により特定のデータに複数のユーザーからのアクセス設定を行うことを防ぐことが可能となる。なお、本実施形態では、ユーザー単位での共有を前提で説明を行った。しかし、ユーザーグループ単位でのアクセス権制御を行う様にしてもよい。この場合、ユーザーグループＡに所属の特定権限を持ったユーザーの何れかがアクセス設定を行った場合、リソースサーバー２１０は、そのユーザーグループＡに属する同様の権限を持つユーザー全てからのアクセス許可を与える。また、共有できない場合に異なるユーザーグループＢのユーザーがアクセス許可を設定しようとした場合、リソースサーバー２１０は、ユーザーグループＡからのアクセス許可を全て削除し、ユーザーグループＢからのアクセス許可を設定する。

以上、アクセス設定が終了したら、リソースサーバー２１０は、リソースサービス連携アプリケーション４００に対して、設定結果を応答して送信する（Ｓ３２２０）。
ここで、Ｓ３１５０からＳ３２００まで、トークンの検証を認可サーバー２００、リソースサーバー２１０のそれぞれで行うよう説明した。しかし、リソースに対するアクセス可能なアプリケーションを認可サーバー２００で管理し、全ての検証を認可サーバー２００で行うようにしてもよい。
リソース応答を受信したリソースサービス連携アプリケーション４００は、受信したデータを基に前述のアプリケーション画面を構成し、ユーザーに応答する（Ｓ３２３０）。

これら、子トークンの取得及びリソースサーバーに対するアクセス権設定によって、サーバー上のどのユーザーが、サーバー上に保持されている画像形成装置のデータにアクセスしてよいかを決定することが可能となる。
この後、クライアント端末２２０よりリソースサーバー２１０で提供するサービスにログインし、利用する際、そのユーザーがアクセス設定した画像形成装置のデータが提示され、各種操作（編集や配信設定等）を実施することが可能となる。

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

以上、上述した各実施形態によれば、クラウドサービス上のユーザー情報が削除等された場合であっても、クラウドサービス上のデバイスリソースを編集可能とすることができる。

以上、本発明の好ましい実施形態について詳述したが、本発明は係る特定の実施形態に限定されるものではなく、特許請求の範囲に記載された本発明の要旨の範囲内において、種々の変形・変更が可能である。

Claims (11)

1. デバイスの信用情報を含む、第１トークンの取得要求をサーバー装置に送信する第１トークン要求送信手段と、
   前記サーバー装置より前記デバイスの信用情報に対応する前記第１トークンを受信する第１トークン受信手段と、
   前記第１トークン受信手段により受信された前記第１トークンを記憶装置に記憶する記憶手段と、
   前記記憶手段により前記記憶装置に記憶された前記第１トークンを取得し、取得した前記第１トークンと、デバイスリソースを管理する管理手段を識別する識別情報と、を含む、第２トークンの取得要求をサーバー装置に送信する第２トークン要求送信手段と、
   前記サーバー装置より前記識別情報に対応する第２トークンを受信する第２トークン受信手段と、
   前記第２トークン受信手段により受信された前記第２トークンを含む、デバイスリソースに係る処理の要求を前記サーバー装置に送信するデバイスリソース要求送信手段と、
   を有する画像形成装置。
2. 前記画像形成装置にログインしているユーザーの権限情報に対応する第３トークンを取得する取得手段と、
   前記取得手段により取得された前記第３トークンと、デバイスの信用情報と、前記管理手段を識別する識別情報と、前記ユーザーの権限情報に対応するアクセス範囲情報と、を含む、第４トークンの取得要求をサーバー装置に送信する第４トークン要求送信手段と、
   前記サーバー装置より前記識別情報に対応する第４トークンを受信する第４トークン受信手段と、
   前記第４トークン受信手段により受信された前記第４トークンを含む、サーバー装置上のデバイスリソースに対するアクセス制御処理の要求を前記サーバー装置に送信するアクセス制御要求送信手段と、
   を更に有する請求項１記載の画像形成装置。
3. 前記第４トークン要求送信手段は、前記ユーザーの権限情報に応じて、前記第４トークンの取得要求に含まれる前記アクセス範囲情報を切り替える請求項２記載の画像形成装置。
4. デバイスの信用情報を含む、第１トークンの取得要求を画像形成装置より受信する第１トークン要求受信手段と、
   前記第１トークン要求受信手段により受信された前記第１トークンの取得要求に含まれる前記デバイスの信用情報に対応する前記第１トークンを生成し、生成した前記１トークンを前記画像形成装置に送信する第１トークン送信手段と、
   前記第１トークン送信手段により送信された前記第１トークンと、前記画像形成装置のデバイスリソースを管理する管理手段を識別する識別情報と、を含む、第２トークンの取得要求を前記画像形成装置より受信する第２トークン要求受信手段と、
   前記第２トークン要求受信手段により受信された前記第２トークンの取得要求に含まれる前記第１トークンの有効性を検証する第１トークン検証手段と、
   前記第１トークン検証手段により前記第１トークンの有効性が検証された場合、前記第２トークンの取得要求に含まれる前記識別情報に対応する第２トークンを生成し、生成した前記第２トークンを前記画像形成装置に送信する第２トークン送信手段と、
   前記第２トークン送信手段により送信された前記第２トークンを含む、デバイスリソースに係る処理の要求を前記画像形成装置より受信するデバイスリソース要求受信手段と、
   前記デバイスリソース要求受信手段により受信された前記第２トークンを検証する第２トークン検証手段と、
   前記第２トークン検証手段により前記第２トークンが有効であると検証された場合、前記第２トークンに対応する前記識別情報で識別される管理手段に前記デバイスリソースに対するアクセスが許可されているか否かを検証する検証手段と、
   前記検証手段により前記管理手段に前記デバイスリソースに対するアクセスが許可されていると検証された場合、画像形成装置ごとに管理されているデバイスリソースのうち、前記要求に関するデバイスリソースに係る処理を実行するサービス実行手段と、
   を有するサーバー装置。
5. 画像形成装置が実行する情報処理方法であって、
   デバイスの信用情報を含む、第１トークンの取得要求をサーバー装置に送信する第１トークン要求送信ステップと、
   前記サーバー装置より前記デバイスの信用情報に対応する前記第１トークンを受信する第１トークン受信ステップと、
   前記第１トークン受信ステップにより受信された前記第１トークンを記憶装置に記憶する記憶ステップと、
   前記記憶ステップにより前記記憶装置に記憶された前記第１トークンを取得し、取得した前記第１トークンと、デバイスリソースを管理する管理ステップを識別する識別情報と、を含む、第２トークンの取得要求をサーバー装置に送信する第２トークン要求送信ステップと、
   前記サーバー装置より前記識別情報に対応する第２トークンを受信する第２トークン受信ステップと、
   前記第２トークン受信ステップにより受信された前記第２トークンを含む、デバイスリソースに係る処理の要求を前記サーバー装置に送信するデバイスリソース要求送信ステップと、
   を含む情報処理方法。
6. 前記画像形成装置にログインしているユーザーの権限情報に対応する第３トークンを取得する取得ステップと、
   前記取得ステップにより取得された前記第３トークンと、デバイスの信用情報と、前記管理ステップを識別する識別情報と、前記ユーザーの権限情報に対応するアクセス範囲情報と、を含む、第４トークンの取得要求をサーバー装置に送信する第４トークン要求送信ステップと、
   前記サーバー装置より前記識別情報に対応する第４トークンを受信する第４トークン受信ステップと、
   前記第４トークン受信ステップにより受信された前記第４トークンを含む、サーバー装置上のデバイスリソースに対するアクセス制御処理の要求を前記サーバー装置に送信するアクセス制御要求送信ステップと、
   を更に含む請求項５記載の情報処理方法。
7. デバイスの信用情報を含む、第１トークンの取得要求を画像形成装置より受信する第１トークン要求受信ステップと、
   前記第１トークン要求受信ステップにより受信された前記第１トークンの取得要求に含まれる前記デバイスの信用情報に対応する前記第１トークンを生成し、生成した前記１トークンを前記画像形成装置に送信する第１トークン送信ステップと、
   前記第１トークン送信ステップにより送信された前記第１トークンと、前記画像形成装置のデバイスリソースを管理する管理ステップを識別する識別情報と、を含む、第２トークンの取得要求を前記画像形成装置より受信する第２トークン要求受信ステップと、
   前記第２トークン要求受信ステップにより受信された前記第２トークンの取得要求に含まれる前記第１トークンの有効性を検証する第１トークン検証ステップと、
   前記第１トークン検証ステップにより前記第１トークンの有効性が検証された場合、前記第２トークンの取得要求に含まれる前記識別情報に対応する第２トークンを生成し、生成した前記第２トークンを前記画像形成装置に送信する第２トークン送信ステップと、
   前記第２トークン送信ステップにより送信された前記第２トークンを含む、デバイスリソースに係る処理の要求を前記画像形成装置より受信するデバイスリソース要求受信ステップと、
   前記デバイスリソース要求受信ステップにより受信された前記第２トークンを検証する第２トークン検証ステップと、
   前記第２トークン検証ステップにより前記第２トークンが有効であると検証された場合、前記第２トークンに対応する前記識別情報で識別される管理ステップに前記デバイスリソースに対するアクセスが許可されているか否かを検証する検証ステップと、
   前記検証ステップにより前記管理ステップに前記デバイスリソースに対するアクセスが許可されていると検証された場合、画像形成装置ごとに管理されているデバイスリソースのうち、前記要求に関するデバイスリソースに係る処理を実行するサービス実行ステップと、
   を含む情報処理方法。
8. コンピュータに、
   デバイスの信用情報を含む、第１トークンの取得要求をサーバー装置に送信する第１トークン要求送信ステップと、
   前記サーバー装置より前記デバイスの信用情報に対応する前記第１トークンを受信する第１トークン受信ステップと、
   前記第１トークン受信ステップにより受信された前記第１トークンを記憶装置に記憶する記憶ステップと、
   前記記憶ステップにより前記記憶装置に記憶された前記第１トークンを取得し、取得した前記第１トークンと、デバイスリソースを管理する管理ステップを識別する識別情報と、を含む、第２トークンの取得要求をサーバー装置に送信する第２トークン要求送信ステップと、
   前記サーバー装置より前記識別情報に対応する第２トークンを受信する第２トークン受信ステップと、
   前記第２トークン受信ステップにより受信された前記第２トークンを含む、デバイスリソースに係る処理の要求を前記サーバー装置に送信するデバイスリソース要求送信ステップと、
   を実行させるためのプログラム。
9. 前記コンピュータに、
   デバイスの信にログインしているユーザーの権限情報に対応する第３トークンを取得する取得ステップと、
   前記取得ステップにより取得された前記第３トークンと、デバイスの信用情報と、前記管理ステップを識別する識別情報と、前記ユーザーの権限情報に対応するアクセス範囲情報と、を含む、第４トークンの取得要求をサーバー装置に送信する第４トークン要求送信ステップと、
   前記サーバー装置より前記識別情報に対応する第４トークンを受信する第４トークン受信ステップと、
   前記第４トークン受信ステップにより受信された前記第４トークンを含む、サーバー装置上のデバイスリソースに対するアクセス制御処理の要求を前記サーバー装置に送信するアクセス制御要求送信ステップと、
   を更に実行させるための請求項８記載のプログラム。
10. 前記第４トークン要求送信ステップでは、前記ユーザーの権限情報に応じて、前記第４トークンの取得要求に含まれる前記アクセス範囲情報を切り替える請求項９記載のプログラム。
11. コンピュータに、
    デバイスの信用情報を含む、第１トークンの取得要求を画像形成装置より受信する第１トークン要求受信ステップと、
    前記第１トークン要求受信ステップにより受信された前記第１トークンの取得要求に含まれる前記デバイスの信用情報に対応する前記第１トークンを生成し、生成した前記１トークンを前記画像形成装置に送信する第１トークン送信ステップと、
    前記第１トークン送信ステップにより送信された前記第１トークンと、前記画像形成装置のデバイスリソースを管理する管理ステップを識別する識別情報と、を含む、第２トークンの取得要求を前記画像形成装置より受信する第２トークン要求受信ステップと、
    前記第２トークン要求受信ステップにより受信された前記第２トークンの取得要求に含まれる前記第１トークンの有効性を検証する第１トークン検証ステップと、
    前記第１トークン検証ステップにより前記第１トークンの有効性が検証された場合、前記第２トークンの取得要求に含まれる前記識別情報に対応する第２トークンを生成し、生成した前記第２トークンを前記画像形成装置に送信する第２トークン送信ステップと、
    前記第２トークン送信ステップにより送信された前記第２トークンを含む、デバイスリソースに係る処理の要求を前記画像形成装置より受信するデバイスリソース要求受信ステップと、
    前記デバイスリソース要求受信ステップにより受信された前記第２トークンを検証する第２トークン検証ステップと、
    前記第２トークン検証ステップにより前記第２トークンが有効であると検証された場合、前記第２トークンに対応する前記識別情報で識別される管理ステップに前記デバイスリソースに対するアクセスが許可されているか否かを検証する検証ステップと、
    前記検証ステップにより前記管理ステップに前記デバイスリソースに対するアクセスが許可されていると検証された場合、画像形成装置ごとに管理されているデバイスリソースのうち、前記要求に関するデバイスリソースに係る処理を実行するサービス実行ステップと、
    を実行させるためのプログラム。

Images