JP2014099030A - デバイス装置、制御方法、およびそのプログラム。 - Google Patents

Abstract

【課題】 アプリケーションにユーザーの権限を移譲した場合において、デバイスにユーザーがログインしていない状態でアプリケーションがクラウドサービスを利用する場合、どのユーザーから移譲された権限を使わせれば良いのかが考えられていなかった
【解決手段】 デバイスがクラウドユーザー識別子をアプリケーションに応答することで、アプリケーションの利用するトークンの識別が可能となる。
【選択図】 図１４

Description

ユーザーの権限移譲に対応するデバイス装置、制御方法、およびそのプログラムに関する。

近年、ＰＤＦ形式の電子文書を作成するサービス、およびその電子文書を保存するサービスをインターネットを介して端末に提供するサーバーが広く運営されるようになった。ユーザーは端末を介してサービスを利用することで、その端末に電子文書の作成機能がない場合でも電子文書が作成できるようになる他、端末の記憶容量以上の電子文書を保存できるようにもなる。

更に、クラウドが注目されるに伴い、複数のサービスを連携させて新たな付加価値を創造する機会は益々増加している。例えば、サービスを利用し作成したＰＤＦ形式の電子文書が端末を経由することなく別のサービスに直接保存される、と言ったサービスの連携が可能である。その一方で、サービスが連携することにより課題が生まれる。

それは、ユーザーが望んだ以上の情報がサービス間で交換された場合、ユーザーデータや個人情報の漏えいリスクが高まると言うことである。サービス連携時に、ユーザーの望む結果を提供するためのサービス以外のサービスがユーザーデータ、個人情報等を取得することは望ましくない。一方で、サービスの提供者からするとサービス連携の仕組みは容易に実装できるものが好ましい。

このような状況において、ＯＡｕｔｈ（特許文献１、非特許文献１、および非特許文献２を参照）と呼ばれる認可の連携を実現させるための標準プロトコルが策定されている。ＯＡｕｔｈを複数のサービスに実装することで、例えば、ユーザーから特定の権限でサービスＡへのアクセスが認められた外部サービスＢは、ユーザーの認証情報を用いることなくサービスＡへアクセスできるようになる。このとき、サービスＡは外部サービスＢからアクセスされるデータ、および利用されるサービスの範囲と言った権限の内容をユーザーに対し明らかにした上で、外部サービスＢによるアクセスにユーザーの明示的な了承、即ち認可を必要とする構成になっている。ユーザーが認可画面を介して明示的に認可を行う行為を認可操作と言う。

ユーザーが認可操作を行うと、サービスＡは外部サービスＢに対してユーザーによって認可された特定の権限を与える。そして、外部サービスＢは、認可された権限でアクセスが認められることを証明するトークン、即ち認可トークンをサービスＡから直接的、または間接的に受け取る。以降、外部サービスＢはその認可トークンを用いてサービスＡにアクセスできる。ユーザーが認可操作を行った結果、サービスを利用する主体、先程の例で言えば外部サービスＢに認可トークンを保持させるための一連の流れを、ユーザーは外部サービスＢに権限を移譲する、と言う。なお、上述した通り、サービスを利用する主体に実際の権限を与えるのはサービスを利用させる主体であり、先程の例で言えば、ユーザーから認可操作が行われたことを確認したサービスＡが権限を与える。

なお、この技術はサービス間の連携にのみ使用されるわけではなく、ユーザーが操作する端末のアプリケーションがＯＡｕｔｈを用いてインターネット上のサービスと連携する形態でも利用されていることが知られている。例えば、アプリケーションの追加・削除が可能であるスマートフォンに複数のアプリケーションをインストールし、各アプリケーションがインターネット上のサービスと連携する形態である。その中でも、ソーシャル・ネットワーキング・サービス（以下、ＳＮＳと呼ぶ）と呼ばれるサービスと、スマートフォンのアプリケーションがＯＡｕｔｈを用いて連携する形態が代表的な例である。

スマートフォンにインストールされたアプリケーションは、ユーザーの代理としてＳＮＳにアクセスすることになる。ユーザーは、ＳＮＳを利用するのに必要な最小限の機能の権限、例えば記事を投稿する権限のみをアプリケーションに移譲することで、スマートフォンにＳＮＳの認証情報を保存させることなく、かつアプリケーションは適正な権限でＳＮＳと連携することができる。

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

アプリケーションにユーザーの権限を移譲した場合において、デバイスにユーザーがログインしていない状態でアプリケーションがクラウドサービスを利用する場合、どのユーザーから移譲された権限を使わせれば良いのかが考えられていなかった。
本発明は上述した課題を解決するためのデバイス装置を提供することを目的の１つとする。

本発明の一実施形に係るデバイス装置は、ネットワークを介して接続された外部装置へサービスを提供するサーバーシステム、および認可サーバーシステムと通信することが可能であり、前記サービスを利用するアプリケーションをインストールすることが可能なデバイス装置であって、ユーザーが持っている前記サービスを利用するための権限を前記デバイス装置に移譲することを許可する認可操作が行われたことに応じて前記認可サーバーシステムにより発行される第１の権限情報を取得する第１の取得手段と、予め設定された時刻においてバッチ実行を開始する前記アプリケーションから、前記サービスを利用するユーザーを識別するための識別情報を受信する受信手段と、受信された前記識別情報を基に、前記第１の権限情報を特定する特定手段と、ユーザーから移譲された権限を前記アプリケーションに対して更に移譲する要求を、特定された前記第１の権限情報とともに前記認可サーバーシステムへ送信し、前記第１の権限情報に基づき発行された第２の権限情報を前記認可サーバーシステムから取得することを特徴とする。

アプリケーションにユーザーの権限を移譲した場合において、デバイスにユーザーがログインしていない状態でアプリケーションがクラウドサービスを利用する場合であっても、アプリケーションは利用すべき権限を特定することができる。

システム構成図。 各装置のハードウェア構成図。 各装置のソフトウェアモジュール構成図。 認可サーバーで管理するテーブル構造図。 画像形成装置で管理するテーブル構造図。 親トークン発行までのシーケンス図。 認可確認画面、および認証画面。 子トークン発行までのシーケンス図。 アプリケーション管理シーケンス図。 アプリケーションの構成およびテーブル構造図。 トークン管理テーブル構造図。 バッチ処理設定までのシーケンス図。 バッチ設定画面。 バッチ処理時の子トークン発行までのシーケンス図。 タイマーサービス設定時間管理テーブル構造図。 バッチ実行時間管理テーブル構造図。

本願発明の実施例においては、インターネット上で帳票データを生成する帳票サービスと、インターネット上のデータを取得して印刷する印刷サービスとがインターネット上のサーバーに設置されていることを想定している。以降、帳票サービスや印刷サービスのように、ネットワークからデバイス装置へ提供されている機能をリソースサービスと呼ぶ。

本願発明の実施例においては端末であるデバイス装置として画像形成装置を例に説明する。画像形成装置上にインストールされた印刷アプリケーション、および帳票アプリケーションがリソースサービスを利用することを想定している。以降、印刷アプリケーションや帳票アプリケーションのようにリソースサービスを利用するアプリケーションをリソースサービス連携アプリケーションと呼ぶ。

更に、本願発明の実施例における権限の移譲の処理にはＯＡｕｔｈの仕組みを利用することとする。ＯＡｕｔｈでは、ユーザーから移譲された権限の範囲を特定するための情報をトークンと呼ばれるデータ形式で表現する。サービスを利用される主体、即ちリソースサービスを提供するサーバーは、トークンに基づいて特定される権限範囲で外部からのアクセスを許す。トークンを始めとする権限の範囲を特定するために用いられる情報を本実施例では権限情報と称する。また、サービスを利用する主体、即ち画像形成装置、またはリソースサービス連携アプリケーションに移譲される権限の範囲を規定する情報をスコープと称し、ユーザーが画像形成装置に対して権限移譲した場合に発行されるトークンを親トークンと称する。本実施例では、ユーザーの権限を画像形成装置のようなデバイス装置に移譲することも本願発明の実施例のポイントの１つである。

例えば、画像形成装置上に印刷アプリケーション、および帳票アプリケーションが存在する場合を考える。従来技術では、ユーザーは、印刷アプリケーションからリソースサービスを利用する場合は印刷アプリケーションに、帳票アプリケーションからリソースサービスを利用する場合は帳票アプリケーションに対してそれぞれ個別に認可操作を行う必要がある。ユーザーの立場で考えると、同一の画像形成装置からリソースサービスを利用する場合には、例えば一度の認可操作でそれぞれのアプリケーションからリソースサービスを利用できるようになった方が良い。そこで、アプリケーションに権限を移譲する際、ユーザーに代わり画像形成装置がアプリケーションに権限を移譲することでユーザーの認可操作の回数を低減させる。ユーザーは画像形成装置に権限を移譲した段階で、アプリケーションにも権限を移譲することを暗に認可したこととなる。

なお、本願発明の実施例では画像形成装置に権限を移譲する際にユーザーに認可操作を行わせるが、アプリケーションに権限を移譲する際にはユーザーに認可操作を行わせない。以上の様に、本実施例では、ユーザーの権限をデバイス装置に移譲することでユーザーの認可操作を従来よりも少ない回数に減らしつつ、将来的に追加される各アプリケーションへの権限移譲を可能にする。

ここで、アプリケーションへ権限移譲をする方法について説明する。アプリケーションへ権限移譲をする方法として始めに思いつく構成は、画像形成装置が取得した親トークンをアプリケーションで共有する形態にする形態であろう。しかし、アプリケーションが親トークンを共有する形態を取った場合、全てのアプリケーションに全く同じ権限が与えられたことになってしまいセキュリティ上好ましくない。

例えば、印刷アプリケーションは印刷権限が必要だが帳票生成権限は不要である。また帳票アプリケーションは帳票生成権限が必要だが印刷権限は不要である。このように個々のアプリケーションがそれぞれ異なる目的のためのものであれば、それぞれのアプリケーションに必要な権限は異なるため、夫々のアプリケーションには出来る限り必要最低限の権限を与える形態がセキュリティ上は好ましい。

また、トークンを管理するサーバーは、想定していないアプリケーションからの接続を許可するとしても、どのようなアプリケーションからのアクセスであったのかの記録を残したいという要求も存在する。これは、例えば、より利用頻度の高いアプリケーションを特定し、そのアプリケーションの利用シーンに合わせて機能を拡張していくといった、リソースサービスの機能拡張への戦略を決めるうえで有用な情報である。また、リソースサービスを提供するサーバーは、トークンを用いてアクセスするリソースサービス連携アプリケーションが正規なアプリケーションであるかを認識する必要がある。でなければ、不正なアプリケーションにサービスを利用されてしまうことになる。

また、ユーザー管理機能を持たないようなデバイスの場合、同じデバイスに対して複数のユーザーがアプリケーションのバッチ処理実行を予約ができない、という問題がある。デバイスがユーザー管理機能を持つ場合は、デバイスのユーザー名に紐付けてクラウドアクセス用のトークンを管理すれば使い分けることができたが、デバイスユーザーが存在しない場合は、複数の認可トークンのどれを使ってよいかわからない。

さらに、アプリケーションのバッチ処理実行はデバイスにログインしていない状態でユーザーに成り代わってクラウドにアクセスする。そのため、認可トークンを複数アプリケーションや複数ユーザーの間で共有可能にした場合、ユーザーの介在しない状態で不正な成りすましが可能になってしまう、といった課題がある。

本願発明の実施例においては、個々のリソースサービス連携アプリケーションは親トークンを直接使うのでなく、デバイスに移譲された権限の内、アプリケーションが必要とする権限を更にアプリケーションに移譲する。そして、デバイスがアプリケーションに権限を移譲する際、トークンを管理するサーバーがアプリケーションの特定が可能なように移譲を行う。画像形成装置がリソースサービス連携アプリケーションに権限を再移譲した場合に発行されるトークンを子トークンと称する。親トークン、および子トークンの両方を発行するために必要な操作を認可連携と称する。

本実施例では、リソースサービスを利用し印刷を行う画像形成装置上の印刷アプリケーションの２つの動作について詳細に述べる。一つ目の動作は、ユーザーが画像形成装置にログインして印刷アプリケーションが動作する場合について述べる。二つ目は、ユーザーが画像形成装置にログインせず、予め設定した時刻に同じ印刷アプリケーションがバッチ実行する場合について述べる。本実施例における、このような同じ印刷アプリケーションの動作の違いは、前記印刷アプリケーションの起動のきっかけによって発現する。ユーザーが画像形成装置にログインしてアプリケーションを起動する場合と、予め設定した時刻にタイマーサービスによってアプリケーションがバッチ実行する場合である。なお、１つの印刷アプリケーションで２つの動作を行う形態を説明するが、夫々の機能を持つ２つの印刷アプリケーションを画像形成装置で動作させても良い。

本実施の形態に係る権限移譲システムは、図１に示すような構成のネットワーク上に実現される。１００は、Ｗｉｄｅ Ａｒｅａ Ｎｅｔｗｏｒｋ（ＷＡＮ１００）であり、本発明ではＷｏｒｌｄ Ｗｉｄｅ Ｗｅｂ（ＷＷＷ）システムが構築されている。１０１は各構成要素を接続するＬｏｃａｌ Ａｒｅａ Ｎｅｔｗｏｒｋ（ＬＡＮ１０１）である。

２００はＯＡｕｔｈを実現するための認可サーバーであり、認可サービスモジュールが設置されている。２１０はリソースサーバーであり、印刷サービスや帳票サービスといったリソースサービスが設置されている。なお１台のリソースサーバーに設置されるリソースサービスは１つでもよく、複数でもよい。３００は画像形成装置であり、１つまたは複数のリソースサービス連携アプリケーションがインストールされている。ユーザーはそれらのリソースサービス連携アプリケーションを用いてリソースサービスを利用する。また認可サーバー２００、リソースサービス２１０、画像形成装置３００はそれぞれＷＡＮ１００およびＬＡＮ１０１を介して接続されている。なお認可サーバー２００、リソースサービス２１０、画像形成装置３００はそれぞれ個別のＬＡＮ上に構成されていてもよいし同一のＬＡＮ上に構成されていてもよい。また認可サーバー２００、リソースサービス２１０は同一のサーバー上に構成されていてもよい。

また、認可サーバー、およびリソースサーバーは１台ではなく複数台で構成されるサーバー群であっても良い。認可サーバーシステムと称した場合、認可サービスモジュールを備えた１台のサーバー、または複数台のサーバー群を指しており、リソースサーバー２１０、および後述する画像形成装置３００は含まないサーバー群を意味する。リソースサーバーシステムについても同様であり、リソースサービスを備えた１台のサーバー、または複数台のサーバーを指している。サーバーシステムが複数台で構成される場合、サーバーシステムに備えられたモジュールは複数台のサーバーに分割して配置し、モジュールの一部を備えた複数台のサーバー同士が連携して機能を実行するようにしても良い。

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

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

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

ＲＯＭ３０２内のプログラムＲＯＭには、ＣＰＵ３０１の制御プログラム等を記憶している。ＲＯＭ３０２内のフォント用ＲＯＭには、出力情報を生成する際に使用するフォントデータ等を記憶している。ＲＯＭ３０２内のデータ用ＲＯＭには、ハードディスク等の外部メモリ３０３がない画像形成装置の場合、認可サーバー２００と送受信を行う情報等を記憶している。ＲＡＭ３０８は、ＣＰＵ３０１の主メモリや、ワークエリア等として機能するＲＡＭであり、図示しない増設ポートに接続されるオプションＲＡＭによりメモリ容量を拡張することができるように構成されている。また、ＲＡＭ３０８は、出力情報展開領域、環境データ格納領域、ＮＶＲＡＭ等に用いられる。外部メモリ３０３は、メモリコントローラ（ＭＣ）３０９によりアクセスを制御される。外部メモリ３０３は、オプションとして接続され、フォントデータ、エミュレーションプログラム、フォームデータ等を記憶する。また、操作部３１１は操作のためのスイッチ及びＬＥＤ表示器等で構成されている。尚、後述の全ての説明においては、特に断りのない限り画像形成装置における実行のハード上の主体はＣＰＵ３０１であり、ソフトウェア上の主体は外部メモリ３０３にインストールされたアプリケーションプログラムである。

図３は本実施の形態に係る、認可サーバー２００、リソースサーバー２１０、画像形成装置３００それぞれのモジュール構成を示す図である。なお認可サーバー２００、リソースサーバー２１０、画像形成装置３００は図２のものと同一である。認可サーバー２００は認可サーバーモジュール６００を持ち、認可サーバーモジュール６００はユーザー識別部６０１、クライアント検証部６０２、親トークン発行部６０３、子トークン発行部６１１、子トークン検証部６２０を持つ。リソースサーバー２１０はリソースサーバーモジュール７００を持ち、リソースサーバーモジュール７００は子トークン権限確認部７０１とリソース要求処理部７０２を持つ。

図中３００は画像形成装置３００である。画像形成装置３００はＣＰＵ３０１がＲＯＭ３０２、或いは外部メモリ３０３に記憶されたＯＳを実行する事で各アプリケーションを制御する。ここで８２０はそのＯＳであり、一般的にはリアルタイムＯＳが使用されるが、昨今ではＬｉｎｕｘ（登録商標）等の汎用ＯＳが使用される事もある。次に、８１０は仮想マシンであり、例えばＪａｖａ（登録商標）ＶＭがよく知られている。この仮想マシン８１０はＯＳで制御されるアプリケーションとして動作する仮想的なアプリケーション実行環境である。次に、８００はアプリケーション管理フレームワークである。８００は、仮想マシン８１０が提供するアプリケーション実行環境上で動作する管理対象のアプリケーションのライフサイクルを管理する機能と、それを制御するＩ／Ｆ、および各アプリケーション間での処理要求を仲介するためのＩ／Ｆ公開機能を備える。ライフサイクルとはアプリケーションのインストール、起動、停止、アンインストールを含むアプリケーションの状態を示すものとする。本実施例におけるアプリケーション管理フレームワーク８００は、ＯＳＧｉ（Ｏｐｅｎ Ｓｅｒｖｉｃｅｓ Ｇａｔｅｗａｙ ｉｎｉｔｉａｔｉｖｅ）アライアンスで規定されたＯＳＧｉ（登録商標）として説明する。

また、認可サーバー連携クライアント５００、１つまたは複数のリソースサーバー連携アプリケーション５００、ログインアプリケーション１０００は、仮想マシン８１０が提供するアプリケーション実行環境にて動作する各種アプリケーションである。また、これらアプリケーションはアプリケーション管理フレームワーク８００にてライフサイクル管理されている。なお、アプリケーション管理フレームワークは、後述するアプリケーション定義ファイルに記載された定義値に基づきアプリケーションの管理を行う。例えば、アプリケーションに固有に割り当てられているアプリケーションＩＤとインストールされている、もしくは開始されているアプリケーションの実態との紐づけ管理を行う。８３０はアプリケーション管理フレームワーク８００が公開するライフサイクル管理用の制御Ｉ／Ｆを介して、ユーザーからの各種アプリケーションのインストールや、開始リクエストを受け付け実行するアプリケーション管理アプリケーションである。

認可サーバー連携クライアントは、本実施例の場合、印刷アプリケーション、帳票アプリケーション、ＦＡＸアプリケーション、スキャンアプリケーションである。これらアプリケーションは、本実施例で後述するアクセストークンを用いたリソースサーバーへのアクセスにより、アプリケーション実行に必要なリソースを、リソースサーバーから取得する。リソースは、リソースサーバー２１０が印刷サービスの場合、印刷可能な文書のリストである。印刷アプリケーションは、印刷サービスと連携し、印刷サービスのリソースである印刷可能な文書を取得する。印刷アプリケーションは、印刷可能な文書のリストを取得したことに応じてリソースサーバーからリストに記載された文書をダウンロードし、その文書を印刷する機能を持つ。この機能の実施は、ユーザーが画像形成装置３００にログインし、アプリケーションが起動し処理を実行する場合と、予めユーザーが実行時間を指定して自動的に処理を実行する場合がある。後者の場合、指定時間になったら後述するタイマーサービスからのイベント通知を受け、通知を受けた印刷アプリケーションが起動し処理を実行する場合がある。指定時間の際に、タイマーサービスからのイベント通知によりアプリケーションを実行することをバッチ実行と呼ぶ。バッチ実行は、ユーザーからの指示に応じて実行する処理ではなく、ユーザーが設定した指定時間、または予め設定された指定時間に実行することを指す。

認可サーバー連携クライアントが帳票サービスの場合、印刷サービスと同様、帳票アプリケーションはリソースサーバーから作成可能な帳票のリストを取得し、リスト記載の帳票を取得し、印刷する機能を持つ。認可サーバー連携クライアントがＦＡＸサービスの場合、印刷サービスと同様に、ＦＡＸアプリケーションは、リソースサーバーからＦＡＸ送信可能なＦＡＸ文書のリストを取得し、リスト記載のＦＡＸ文書、ＦＡＸ番号を取得し、ＦＡＸ送信する機能を持つ。印刷アプリケーション同様、帳票アプリケーション、ＦＡＸアプリケーションも、ユーザーの画像形成装置３００へのログイン後にユーザーから指示されたことに応じて処理を開始する実行と、バッチ実行の両者が可能である。

タイマーサービス１１００は、アプリケーション管理フレームワーク８００上で動作するアプリケーションの一種である。タイマーサービス１１００は、アプリケーション管理フレームワーク上で動作する各種アプリケーションに対してタイマーイベントの通知を行う機能を持つ。また、タイマーサービスは、各種アプリケーションからアクセス可能なタイマー設定インターフェースを持つ。例えば、リソースサーバー連携アプリケーション５００は、タイマーサービスに対してタイマー設定インターフェースを用いてイベント通知時間を設定することができる。タイマーサービス１１００は、タイマーイベントの通知の対象となるアプリケーションのＩＤと、タイマー設定時間を保持することができる。タイマーサービス１１００は、タイマー設定時間になると、アプリケーションＩＤに相当するアプリケーションに対しタイマーイベントを通知する。タイマーイベントの通知を受けたアプリケーションは、自動的にアプリケーション動作を行うことが可能となる。例えば、ユーザー操作などのアプリケーションに対する明示的な動作指示がなくても、タイマーサービスのタイマーイベントの通知設定が行われることにより、設定時間におけるバッチ実行が可能となる。

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

図４ａ、図４ｂ、図４ｃは認可サーバー２００が外部メモリに記憶するデータテーブルである。これらデータテーブルは、認可サーバー２００の外部メモリではなく、ＬＡＮ１０１を介して通信可能に構成された別のサーバーに記憶するよう構成する事も出来る。
図４ａはユーザー管理テーブル１２００である。ユーザー管理テーブル１２００は、ユーザーＩＤ１２０１、パスワード１２０２、ユーザー種別１２０３から成る。認可サーバー２００は、ユーザーＩＤ１２０１、パスワード１２０２の情報の組を検証し、正しければ認証情報を生成することで、各ユーザーもしくはクライアントを認証する機能を備える。

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

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

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

ログインコンテキストとは、認証を受けたユーザーのユーザーＩＤ１５０１の情報が設定されたオブジェクトであり、その他に、ユーザーの属性情報、例えば、ユーザーが所属するドメインやユーザーの電子メールアドレス等の情報を設定するよう構成する事もできる。ユーザーが画像形成装置３００にログインしている間、画像形成装置３００はログインコンテキストを保持し、内部のプログラムモジュールが画像形成装置３００のリソースを使用するときはログインコンテキストを利用してセキュアにアクセスを行う。

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

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

ここで、親トークン取得に関する本実施形態のシーケンスを図６、図７を用いて説明する。本シーケンスは、ユーザーが画像形成装置３００を最初に利用する際に一度だけ行う操作である。例えば、認可サーバー連携クライアント４００を画像形成装置３００にインストールし、その後、ユーザーが始めて画像形成装置３００を利用する際に図６で示すフローを行う形態が好ましい。まず、ユーザーが画像形成装置３００においてログインアプリケーション１０００が提供するログイン手段を用いて画像形成装置３００にログインする（Ｓ１．１）。ここでユーザーＩＤがｕｓｅｒ００１ のユーザーがログインしたとする。すると、ログインアプリケーション１０００はｕｓｅｒ００１を含むログインコンテキストを生成し、アプリケーション管理フレームワーク８００を介して各アプリケーションから取得可能なようＲＡＭ３０８に格納する（Ｓ１．２）。

次に、ユーザーは画像形成装置３００を操作してブラウザ９００を実行する。そして、ブラウザ９００を用いて認可サーバー連携クライアント５００の認可連携を開始するためのＵＲＬへアクセスする（Ｓ１．３）。ここで認可サーバー連携クライアント５００は図７ａに示すような認可連携開始を確認する画面１８０１を応答するよう構成しても良い。認可サーバー連携クライアント５００は、認可連携の開始を受け付けたら、デバイス管理テーブル１６００のエンドポイントＵＲＬ１６０３に記載のＵＲＬに対して、ＯＡｕｔｈの認可リクエストをするようブラウザ９００にリダイレクト要求する（Ｓ１．４）。この認可リクエストには、デバイス管理テーブル１６００のクライアントＩＤ１６０１、リダイレクトＵＲＬ１６０４の情報が含まれる。また、ＯＡｕｔｈでは、認可を受けたい権限範囲を示すスコープを認可リクエストに含むよう構成する事もできる。本実施例では、スコープとしてスコープＡがリクエストされたとして説明する。

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

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

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

ここで、リダイレクトＵＲＬ１３０３はクライアント管理テーブル１３００ではなく、認可トークン管理テーブル１４００にカラムを追加し、認可コード発行時に登録して、該追加カラムと検証するよう構成する事もできる。これらすべての検証が正しい場合に認可サーバー２００は親トークンを生成して、親トークンの認可トークンＩＤを認可サーバー−連携クライアント５００に応答するこの際、応答内容として同時に発行したリフレッシュトークンＩＤも含む（Ｓ１．１２）。親トークンとしては、認可トークンＩＤ１４０１に発行したトークンのＩＤ、トークン種別１４０２に親トークン、有効期限１４０３、および、認可コードから引き継ぐ情報として、クライアントＩＤ１４０７、ユーザーＩＤ１４０８を登録する。この際、親トークンをリフレッシュするためのリフレッシュトークンを発行し、リフレッシュトークンＩＤ１４０５、リフレッシュ期限１４０６に登録する。リフレッシュのフローについては後述する。なお、リフレッシュトークンのように権限情報を再発行するために必要な情報を、本願発明では再発行情報と称する。

親トークンの認可トークンＩＤ、リフレッシュトークンＩＤを取得した認可サーバー連携クライアント５００は、アプリケーション管理フレームワーク８００を介して画像形成装置３００にログインしているユーザーのログインコンテキストを取得する（Ｓ１．１３）。そして、認可サーバー連携クライアント５００は、ログインコンテキストからデバイスユーザーＩＤを取得し、親トークン管理テーブル１７００に、デバイスユーザーＩＤ、親トークンの認可トークンＩＤ、リフレッシュトークンＩＤを保存する（Ｓ１．１４）。そして、認可サーバー連携クライアント５００は、不図示の認可連携完了の旨を示す画面をブラウザ９００に応答し、処理を終了する。以上が、ユーザーが持っているサービスを利用するための権限をデバイス装置である画像形成装置３００に移譲することを許可する認可操作が行われたことで、デバイス装置に権限が移譲されるための構成、およびフローとなる。ユーザーの権限を委譲された画像形成装置３００は、ユーザーに代わり各アプリケーションに権限を移譲していく。

続いて、ユーザーの権限を委譲された画像形成装置３００が、ユーザーに代わりアプリケーションに権限を移譲するためのシーケンスを図８を用いて説明する。本シーケンスは、ユーザーが画像形成装置３００に備えるリソースサービス連携アプリケーション４００を実行する際に行われるシーケンスである。なお、親トークン取得のシーケンスが実施されている必要がある。まず、ユーザーが画像形成装置３００においてログインアプリケーション１０００が提供するログイン手段を用いて画像形成装置３００にログインする（Ｓ２．１）。ここでユーザーＩＤがｕｓｅｒ００１ のユーザーがログインしたとする。すると、ログインアプリケーション１０００はｕｓｅｒ００１を含むログインコンテキストを生成し、アプリケーション管理フレームワーク８００を介して各アプリケーションから取得可能なようＲＡＭ３０８に格納する（Ｓ２．２）。なお、親トークン取得のシーケンスの後に連続して実行する場合は、再度ログインする必要はなく、次のＳ２．３からの操作シーケンスとなる。

次に、ユーザーは画像形成装置３００を操作してリソースサービス連携アプリケーション４００のアプリケーション画面（不図示）にアクセスする（Ｓ２．３）。このアプリケーション画面は例えば、リソース連携アプリケーション４００が印刷アプリケーションであった場合は印刷する文書を選択する画面であり、帳票アプリケーションであった場合は、作成する帳票を選択する画面である。ここでアプリケーション画面にアクセスするとは、例えば、画像形成装置３００が備える操作パネル上にアプリケーション管理フレームワーク８００にて開始状態とされている各アプリケーションが選択可能に表示されており、その中から当該アプリケーションを選択する事を指す。

アプリケーション画面にアクセスされたリソースサービス連携アプリケーション４００は、アプリケーション管理フレームワーク８００からログインコンテキストを取得する（Ｓ２．４）。そして、アプリケーション管理フレームワーク８００に登録されている認可サーバー連携クライアント５００のトークン取得インターフェースに対してトークン取得要求を行う（Ｓ２．５）。この際、取得したログインコンテキストを要求に含める。なお、ここでトークンに必要なスコープを要求するよう構成する事もできる。本実施例では、スコープＡが引き続き要求されたとして説明する。トークン取得要求を受けた認可サーバー連携クライアント５００は、アプリケーション管理フレームワーク８００を介して、要求元のリソースサービス連携アプリケーション４００のアプリケーションＩＤを取得する（Ｓ２．６）。アプリケーションＩＤ取得のシーケンスについては後述する。

アプリケーションＩＤを取得した認可サーバー連携クライアント５００は以下の処理を行う。まず、取得したログインコンテキストが有効かどうかアプリケーション管理フレームワーク８００を介して検証する。そして、正しい場合はログインコンテキストに紐づいたデバイスユーザーＩＤを取得する。なお、このログインコンテキストの検証は、認可サーバー連携クライアント５００で実施するよう説明したが、ログインコンテキストのインスタンス生成をアプリケーション管理フレームワーク８００のみ行えるよう構成とする。なお、インスタンスが生成されている事によって、正当であると判断するよう構成する事もできる。次に、認可サーバー連携クライアント５００は、取得したデバイスユーザーＩＤをキーに親トークン管理テーブル１７００からリフレッシュトークンＩＤを取得する。この時、親トークン管理テーブル１７００にユーザーＩＤが登録されていない場合は、親トークン取得シーケンスを実施するようユーザーに促す画面（不図示）を提示するよう構成する事もできる。また、場合によってはブラウザ９００を起動し、親トークン取得シーケンスを自動的に開始するよう構成するでも良い。

認可サーバー連携クライアント５００は取得したリフレッシュトークンＩＤと、デバイス管理テーブル１６００のクライアントＩＤ、クライアントシークレットを用いて、認可サーバー２００にトークンリフレッシュ要求を行う（Ｓ２．７）。ここでは、親トークン取得シーケンスの実行から子トークン取得のシーケンスまでの間に時間が経過し、親トークンの有効期限が切れている事として説明している。しかし、親トークンの有効期限内であった場合は、トークンリフレッシュ要求を実施せず、Ｓ２．１１の子トークン取得要求を実施するでも良い。

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

リフレッシュされた親トークンを取得した認可サーバー連携クライアント５００は、受け付けた認可トークンＩＤ、リフレッシュトークンＩＤにて、親トークン管理テーブルの情報を上書きし、再登録する（Ｓ２．１０）。そして、親トークンの認可トークンＩＤと、デバイス管理テーブル１６００のクライアントＩＤ、クライアントシークレット、トークン取得要求で受けつけたスコープ、および、取得したアプリケーションＩＤを用いて、認可サーバー２００に子トークン取得要求を行う（Ｓ２．１１）。ここで子トークン取得要求に含めるアプリケーションＩＤがリソースサービス連携アプリケーション４００による改竄の余地がない事は後述する。子トークン取得要求は、ユーザーから移譲された権限を前記アプリケーションに対して更に移譲する要求と同等である。

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

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

そして、子トークンの認可トークンＩＤを取得した認可サーバー連携クライアント５００は要求元のリソースサービス連携アプリケーション４００に子トークンの認可トークンＩＤを応答する。子トークンの認可トークンＩＤを取得したリソースサービス連携アプリケーション４００は、リソースサーバー２１０に認可トークンＩＤを含むリソース要求を行う（Ｓ２．１４）。

リソース要求を受けたリソースサーバー２１０は、要求に含まれる子トークンの認可トークンＩＤのトークン検証を認可サーバー２００に対して要求する（Ｓ２．１５）。このトークン検証要求には、スコープを含める事ができる。トークン検証要求を受けた認可サーバー２００は、受け付けた認可トークンＩＤが、認可トークン管理テーブル１４００に登録されているか、有効期限内か、および、受け付けたスコープがスコープ１４０４の範囲内かを検証（Ｓ２．１６）し、検証結果をリソースサーバー２１０に応答する（Ｓ２．１７）。

次に、リソースサーバー２１０は認可サーバー２００に対して、子トークンの認可トークンＩＤのトークン情報取得を要求する（Ｓ２．１８）。トークン情報取得要求を受けた認可サーバー２００は、認可トークン管理テーブル１４００から受け付けた認可トークンＩＤにて特定される情報を取得し、それら情報をリソースサーバー２１０に応答する（Ｓ２．１９）。この応答には、例えば、スコープ１４０４、クライアントＩＤ１４０７、ユーザーＩＤ１４０８、アプリケーションＩＤ１４０９の情報を含む。さらには、クライアントＩＤ１４０７にて特定されるクライアント管理テーブル１３００に登録されているシリアル番号１３０４を含むよう構成する事もできる。

トークン情報を取得したリソースサーバー２１０は、取得した情報を元に要求を受け付けたリソースに対するアクセスを許可するか拒否するかを判断する。ここでは、リソースサーバー２１０に予めアクセス可能なアプリケーションＩＤが設定されているとし、その設定されているアプリケーションＩＤと、トークン情報から取得されたアプリケーションＩＤを比較することでアクセスを許可するかを検証する（Ｓ２．２０）。検証の結果、アクセス許可と判断された場合は、リソースサービス連携アプリケーション４００に対して、リソースを応答する（Ｓ２．２１）。リソースは、例えば、リソースサーバー２１０が印刷サービスであった場合は印刷可能な文書のリストであり、帳票サービスであった場合は、作成可能な帳票のリストである。なお、リソースサーバー２１０は、リソースサービス連携アプリケーション４００を画像形成装置３００へ配信する配信サーバーからアプリケーションＩＤを取得することで、アプリケーションＩＤを予め設定することができる。または、リソースサービス連携アプリケーション４００を開発した開発者からの申請を受けて、リソースサーバー２１０の管理者が手動でアプリケーションＩＤを設定しても良い。

ここで、Ｓ２．１５から、Ｓ２．２０まで、トークンの検証を認可サーバー２００、リソースサーバー２１０それぞれで行うよう説明した。しかし、リソースに対するアクセス可能なアプリケーションを認可サーバー２００で管理し、全ての検証を認可サーバー２００で行うよう構成する事も可能である。また、本実施例ではアクセス可能なアプリケーションの判断をアプリケーションＩＤを用いて実施するよう説明した。しかし、トークン情報から取得できるシリアル番号やクライアントＩＤを元に画像形成装置３００を識別し、アクセスの可否を判断するよう構成する事もできる。また、同様に、トークン情報から取得できるスコープやユーザーＩＤを元にアクセスの可否を判断するよう構成する事もできる。リソース応答を受け付けたリソースサービス連携アプリケーション４００は、受信したデータを元に前述のアプリケーション画面を構成し、ユーザーに応答する（Ｓ２．２２）。

これら、親トークン取得のシーケンス、および子トークン取得のシーケンスによって、ユーザーの認可操作を１回に抑え、かつリソースサーバー２１０はアクセスしてきたアプリケーションを識別する事が可能となる。また、リソースサーバー２１０は、子トークンを世紀に取得したリソースサービス連携アプリケーション４００からのアクセスであることを認識することもできる。

次に、リソースサービス連携アプリケーション４００が認可サーバー連携クライアント５００へのトークン取得要求をする方法および、認可サーバー連携クライアント５００が要求元のアプリケーションＩＤを取得する方法について説明する。

図１０ａはインストールするアプリケーションのアプリケーションファイルの構成を示す図である。アプリケーションファイル１９００は、アプリケーション定義ファイル１９０１、アプリケーションの実態であるアプリケーション１９０２から成る。また、アプリケーションファイルはアプリケーション定義ファイル１９０１、アプリケーション１９０２を含む形で暗号化されており、復号するための鍵はライセンスファイル１９１０に記載されている。また、アプリケーション定義ファイル１９０１は、アプリケーションを一意に識別するためのアプリケーションＩＤと、アプリケーションのバージョン、およびアプリケーション名が記述されている。また、アプリケーション定義ファイル１９０１は、その他にも、アプリケーションが消費する記憶領域等のリソース量の定義や、アプリケーションを開始するときに実行するクラスのクラスパス等が記載されている。

図１０ｂは、アプリケーションをインストールする際に必要となるライセンスファイルの構成を示す図である。ライセンスファイル１９１０は、アプリケーションファイル１９００を復号するためのアプリケーション復号鍵１９１１から成る。またライセンスファイル１９１０は、アプリケーション管理アプリケーション８３０にて保持しされている秘密鍵で復号可能なよう公開鍵にて暗号化されている。これらの構成により、アプリケーション管理アプリケーション８３０にて保持されている秘密鍵が漏洩しない限りは、アプリケーション定義ファイル１９０１、およびアプリケーション１９０２は改竄出来ないよう保護されている。

図１０ｃはアプリケーション管理フレームワーク８００にて管理されるアプリケーション管理テーブル１９２０である。アプリケーション管理テーブル１９２０は、アプリケーションＩＤ１９２１、バージョン１９２２、アプリケーション名１９２３、保存場所１９２４、状態１９２５から成る。

また、アプリケーション管理フレームワーク８００は、各アプリケーションが実行され、ＲＡＭ３０８上に展開された状態であるアプリケーションオブジェクトをリストで管理している。リスト上に登録されている各アプリケーションオブジェクトは、アプリケーション管理テーブル１９２０の情報とアプリケーションＩＤで紐づいており、アプリケーション管理テーブル１９２０の各情報を参照可能に構成されている。また、アプリケーションオブジェクトのリストは、アプリケーション管理フレームワーク８００のＩ／Ｆを介してアプリケーション管理アプリケーション８３０から取得可能なよう構成されている。

次に、画像形成装置３００にアプリケーションをインストールするシーケンスと、各アプリケーションを開始するシーケンスを、図９を用いて説明する。また、図８で説明したシーケンスと同じ処理に関しては共通のシーケンス番号とし、説明を省略する。まず、アプリケーションのインストールシーケンスについて説明する。ユーザーは、不図示のＰＣ（パーソナルコンピューター）に備えるＷｅｂブラウザを用いて、画像形成装置３００のアプリケーション管理アプリケーション８３０が備えるアプリケーション管理画面（不図示）にアクセスする（Ｓ３．１）。アプリケーション管理アプリケーション８３０は、アプリケーション管理画面を応答する（Ｓ３．２）。このとき、アプリケーション管理アプリケーション８３０へのアクセス認証として不図示のログイン画面を表示し、認証を実施するよう構成する事もできる。

次にユーザーは、アプリケーション管理画面に、インストールするアプリケーションファイル１９００、およびライセンスファイル１９１０をアップロードし、インストール指示を行う（Ｓ３．３）。本実施例では、アプリケーションとして、リソースサービス連携アプリケーション４００として印刷アプリケーションがアップロードされたとして説明する。アプリケーションファイル１９００、およびライセンスファイル１９１０を受け付けたアプリケーション管理アプリケーション８３０は以下の処理を行う。アプリケーション管理アプリケーション８３０が保持している秘密鍵でライセンスファイルを復号する。復号に成功するとライセンスファイル１９１０からアプリケーション復号鍵１９１１を取得する。次に、受け付けたアプリケーションファイル１９００をアプリケーション復号鍵１９１１で復号する。復号したアプリケーションファイルより、アプリケーション定義ファイル１９０１を取得し定義内容を解析する。アプリケーション復号鍵１９１１にて復号でき、さらにアプリケーション定義ファイル１９０１が解析出来たことにより、アプリケーション定義ファイル１９０１内に記載の内容は正当であると判断できる。

また、アプリケーションファイル１９００はアプリケーション定義ファイル１９０１とアプリケーション１９０２の署名値が記載されたファイルを保持するよう構成する事も可能であり、その場合は、アプリケーション復号鍵１９１１にて復号後に署名値を検証する事で、アプリケーションＩＤに改竄が無いことをより高度に担保することもできる。なお、アプリケーションファイル１９００をアプリケーション復号鍵１９１１で復号化出来なかった場合、および／または署名値が不正なものであった場合、アプリケーションが改竄された恐れがあるため、インストール対象のアプリケーションはインストールされない。

次に、アプリケーション管理アプリケーション８３０は、復号したことで取得したアプリケーション定義ファイル１９０１、およびアプリケーション１９０２を、アプリケーション管理フレームワーク８００のＩ／Ｆを介して画像形成装置３００に保存する。その際、アプリケーション定義ファイルを展開し、アプリケーションＩＤ、バージョン等の情報と共に保存場所をアプリケーション管理テーブル１９２０に記憶する（Ｓ３．５）。また、その際、アプリケーションの状態１９２５に「インストール済み」として登録する。

次に、アプリケーションの開始シーケンスについて説明する。なお、画像形成装置３００には、リソースサービス連携アプリケーション４００、および認可サーバー連携クライアント４００が既にインストールされているものとする。

ユーザーは、不図示のＰＣ（パーソナルコンピューター）、または画像形成装置３００が備えるＷｅｂブラウザを用いてアプリケーション管理アプリケーション８３０に対して、認可サーバー連携クライアント４００を開始するよう指示する（Ｓ３．６）。アプリケーション管理アプリケーション８３０は、アプリケーション管理テーブル１９２０の情報を基に認可サーバー連携クライアント４００の保存場所を特定し、アプリケーション管理フレームワーク８００のＩ／Ｆを介してアプリケーションの起動開始を指示する。

アプリケーション開始指示を受けた認可サーバー連携クライアント４００は、子トークン取得要求を受け付けるためのインターフェースをアプリケーション管理フレームワーク８００に登録する。登録を受けたアプリケーション管理フレームワーク８００は、インターフェースを記憶する。インターフェース登録が完了した認可サーバー連携クライアント４００は、アプリケーション管理フレームワーク８００にアプリケーション開始を応答する（Ｓ３．８）。

アプリケーション管理フレームワーク８００は、認可サーバー連携クライアント４００の状態１９２５を開始状態に変更し、開始されたアプリケーションオブジェクトをアプリケーションオブジェクトリストにて保持する（Ｓ３．９）。アプリケーションオブジェクトは、アプリケーションの実態を有するインスタンスと同義である。

次に、ユーザーは、不図示のＰＣ（パーソナルコンピューター）、または画像形成装置３００が備えるＷｅｂブラウザ（不図示）を用いて、アプリケーション管理アプリケーション８３０に対し、リソースサービス連携アプリケーション４００を開始するよう指示する（Ｓ３．１０）。アプリケーション管理アプリケーション８３０は、アプリケーション管理テーブル１９２０の情報を基にリソースサービス連携アプリケーション４００の保存場所を特定し、アプリケーション管理フレームワーク８００を介してアプリケーションの起動開始を指示する。アプリケーション開始指示を受けたリソースサービス連携アプリケーション４００は、アプリケーションの初期化処理を実行し、アプリケーション管理フレームワーク８００に対してアプリケーション開始を応答する（Ｓ３．１１）。アプリケーション管理フレームワーク８００は、リソースサービス連携アプリケーション４００の状態１９２５を“開始”に変更し、開始されたアプリケーションオブジェクトをアプリケーションオブジェクトリストにて保持する（Ｓ３．１２）。

上記シーケンスによって、アプリケーション管理フレームワーク８００は画像形成装置３００にインストールされている各アプリケーションを開始し、各アプリケーションのアプリケーション定義ファイルに記載されているアプリケーションＩＤを各アプリケーションオブジェクトから参照可能なように保持する事ができる。また、アプリケーション管理フレームワーク８００は、アプリケーションからインターフェース登録を受け付ける事で、他のアプリケーションから登録されたインターフェースを実行可能に保持する事ができる。この時、インターフェース登録の方法としては、インターフェースが定義されたクラスへのクラスパス（クラス定義への参照パス）を渡す。

次に、Ｓ２．３にてリソースサービス連携アプリケーション４００のアプリケーション画面にユーザーがアクセスした際のシーケンスの詳細を説明する。リソースサービス連携アプリケーション４００は、前述したように、Ｓ２．４にてログインコンテキストを取得後、Ｓ２．５にて認可サーバー連携クライアント４００にトークン取得要求を行う。その際、リソースサービス連携アプリケーション４００は、Ｓ３．１３にて、アプリケーション管理フレームワーク８００に対して登録されているインターフェースの取得要求を行う。インターフェース取得要求を受けたアプリケーション管理フレームワーク８００は、要求元のアプリケーションをアプリケーションオブジェクトのリストより特定し、アプリケーション定義ファイルに記載されているアプリケーションＩＤを取得する（Ｓ３．１４）。ここで、本実施例ではインターフェース取得要求を行ったアプリケーションオブジェクトの特定方法として、インターフェース取得要求の引数に、アプリケーションのオブジェクトを参照として格納するよう構成する。ただし、インターフェース取得要求元のアプリケーションオブジェクトの特定方法としては記載の方法に限定せず、例えば、仮想マシン８１０が備える要求元を逆引きするような機能を利用し特定する事も考えられる。

そして、アプリケーション管理フレームワーク８００は、登録されている認可サーバー連携クライアント４００から登録されたインターフェース定義クラスのクラスパスから、参照先のインターフェース定義クラスを実体化してオブジェクト生成するようリクエストする（Ｓ３．１５）。この際、取得したリソースサービス連携アプリケーション４００のアプリケーションＩＤをオブジェクト生成リクエストに設定する。オブジェクト生成リクエストを受けた認可サーバー連携クライアント４００は、アプリケーションＩＤが設定されたインターフェース定義クラスのオブジェクトを生成し、アプリケーション管理フレームワーク８００に応答する。そして、アプリケーション管理フレームワーク８００は生成されたインターフェースクラスのオブジェクトをリソースサービス連携アプリケーション４００に応答する（Ｓ３．１６）。

認可サーバー連携クライアント４００のインターフェースのオブジェクトを取得したリソースサービス連携アプリケーション４００は、インターフェース定義クラスに定義されているトークン取得要求を実行する（Ｓ２．５）。認可サーバー連携クライアント（５００）は、トークン取得要求を受けたインターフェース定義クラスのオブジェクトに設定されたアプリケーションＩＤを取得する（Ｓ２．６）。これらシーケンスによって、アプリケーションによる改竄を防止した形で、アプリケーションＩＤを認可サーバー連携クライアント４００にて取得する事が可能となる。

以上の形態により、１回の認可操作で同一の画像形成装置内の複数のアプリケーションのそれぞれに認可操作することなく、子トークンを発行する事ができ利便性が向上する。また、クラウドサービス側にてアクセス元のアプリケーションを改竄されること無く識別する事が可能となる。

次に、予め設定した時刻にタイマーサービスがタイマーイベント通知をアプリケーションに行い、アプリケーションがバッチ実行する場合について説明する。以下、リソースサービス連携アプリケーション４００が、ログインユーザーが介在しない状態でタイマーサービスによって起動し、バッチ実行する場合を示す。ユーザーが画像形成装置にログインしてアプリケーションを起動する場合、認可サーバー連携クライアント５００は親トークン管理テーブル１７００を参照していた。それは、画像形成装置が親トークンをログインコンテキストに紐付けて保存するためである。一方、予め設定した時刻にタイマーサービスによってアプリケーションがバッチ実行する場合、前記認可サーバー連携クライアント５００はバッチ実行親トークン管理テーブル２７００を参照する。

図１１ａは、トークン要求管理テーブル１９２０である。トークン要求管理テーブル１９２０は認可サーバー連携クライアント５００からのみ参照、および更新可能なように構成されている。トークン要求管理テーブル１９２０は、アプリケーションＩＤ１９２１、ステートＩＤ１９２２から成る。ここでアプリケーションＩＤ１９２１、ステートＩＤ１９２２は、後述する図１２のＳ４．５ により取得、作成されるアプリケーションＩＤ、ステートＩＤ１９２２に対応する。ステートＩＤ１９２２は、図１２に示した後述するバッチ実行用親トークン取得の一連のシーケンスにおいて、親トークン取得のセッションを管理するためのＩＤである。リソースサービス連携アプリケーション４００から認可サーバー連携クライアント５００へのトークン取得要求時に、前記認可サーバー連携クライアント５００によって生成される。

以降、一連のシーケンスにおいて、生成されたステートＩＤはリソースサービス連携アプリケーション４００と認可サーバー連携クライアント５００の間の要求／応答のセッションのＩＤとして使用される。また同様に、ステートＩＤは、認可サービス連携クライアント５００と認可サーバー２００の間の要求／応答のセッションＩＤとしても使用される。

図１１ｃは、バッチ実行用親トークン管理テーブル２７００である。バッチ実行用親トークン管理テーブル２７００は、認可サーバー連携クライアント５００からのみ参照、および更新可能なように構成されている。バッチ実行用親トークン管理テーブル２７００は、アプリケーションＩＤ２７０１、クラウドユーザーＩＤ２７０２、認可トークンＩＤ２７０３、リフレッシュトークンＩＤ２７０４、ステートＩＤ２７０５からなる。バッチ実行用親トークン管理テーブル２７００の処理詳細については後述する。バッチ実行用親トークン管理テーブル２７００は、親トークン管理テーブル１７００と同様に親トークンを管理する。ユーザーが画像形成装置３００にログインし、クラウドサービスと連携するアプリケーションを実行する場合、認可サーバー連携クライアント５００は、親トークン管理テーブル１７００を選択し、使用する。対して、ログインユーザーが介在せず、バッチ実行でクラウドサービスと連携したアプリケーションを実行する場合、認可サーバー連携クライアント５００は、バッチ実行用親トークン管理テーブル２７００を選択し、使用する。

クラウドサービスと連携するアプリケーションが実行可能な画像形成装置３００がユーザー管理機能を持たない場合、ユーザーの区別がつかないため使用する親トークンが定まらず、複数のユーザーでバッチ予約することができない。また、仮に画像系瀬装置３００がユーザー管理機能を持つ場合でも、デバイスのログインユーザーＩＤに紐付けてクラウドアクセス用のトークンを管理すれば使い分けることができるが、ログインコンテキストはログインしている状態でしか存在しないため親トークンを特定できない。さらに、バッチ実行はデバイスにログインしていない状態でユーザーに成り代わってクラウドにアクセスするため、トークンをアプリ間で共有可能にすると、アプリケーションの不正な成りすましによってトークンが不正に発行されてしまう。そこで、クラウド上のリソースサーバー２１０がクラウドユーザーＩＤで管理されていることが保障されているため、バッチ実行用親トークン管理テーブル２７００においては、親トークンを識別情報であるクラウドユーザーＩＤに紐付けて管理する。

図１３ｂは、バッチ設定画面を示す。バッチ設定画面には、後述するクラウドユーザーＩＤと共に、リソースサービス連携アプリケーション４００がバッチ実行される時間を設定する。時間設定は、複数時間が設定可能で、設定単位は時、分である。時刻の設定は、バッチ実行を開始する時間を画面から入力して、設定ボタンを押下することで設定される。

図１６は、タイマー設定時間管理テーブル３０００である。タイマー設定時間管理テーブル３０００は、画像形成装置３００のタイマーサービス１１００、リソースサービス連携アプリケーション４００、認可サーバー連携クライアント５００から参照、更新可能なように構成されている。タイマー設定時間管理テーブル３０００は、アプリケーションＩＤ３００１とバッチ実行時間３００２から成る。タイマー設定時間管理テーブル３０００の処理詳細については後述する。

図１７は、バッチ実行時間管理テーブル４０００である。バッチ実行時間管理テーブル４０００は、リソースサービス連携アプリケーション４００から参照、更新可能なように構成されている。バッチ実行時間管理テーブル４０００には、クラウドユーザーＩＤ４００１と、バッチ実行時間４００２から成る。バッチ実行時間管理テーブル４０００の処理詳細については後述する。

ここで、バッチ実行用親トークン取得に関する本実施形態のシーケンスを図１１、図１２、図１３、図１６を用いて説明する。ユーザーが画像形成装置にログインしてアプリケーションを起動する場合、認可サーバー連携クライアント５００は親トークン取得を図６のシーケンスで実施していた。一方、予め設定した時刻にタイマーサービスによってアプリケーションがバッチ実行する場合、認可サーバー連携クライアント５００はバッチ実行用親トークン取得を図１２のシーケンスで実施する。

本シーケンスは、ユーザーが画像形成装置３００でバッチ実行を行うアプリケーションの各々において、最初にバッチ実行を設定する際に行う操作である。まずユーザーが画像形成装置３００においてログインアプリケーション１０００が提供するログイン手段を用いて画像形成装置３００にログインする（Ｓ４．１）。ここでユーザーＩＤがｕｓｅｒ００１ のユーザーがログインしたとする。すると、ログインアプリケーション１０００はｕｓｅｒ００１を含むログインコンテキストを生成し、アプリケーション管理フレームワーク８００を介して各アプリケーションから取得可能なようＲＡＭ３０８に格納する（Ｓ４．２）。

次に、ユーザーは画像形成装置３００を操作してブラウザ９００を実行する。そして、ブラウザ９００を用いてリソースサービス連携アプリケーション４００にアクセスし、バッチ設定を開始するためのリソースサービス連携アプリケーション４００のＵＲＬへアクセスする（Ｓ４．３）。バッチ設定開始のためのリソースサービス連携アプリケーション４００のＵＲＬアクセスは、ブラウザ９００から直接ＵＲＬ を指定してもよいし、画像形成装置３００の入力画面を用いて、図１３ａに示すようなバッチ設定開始画面を構成してもよい。ユーザーによるＵＲＬ指定により、リソースサービス連携アプリケーション４００のバッチ設定開始が指示されたら、リソースサービス連携アプリケーション４００は、認可サーバー連携クライアント５００に対し、トークン保存要求を出す（Ｓ４．４）。

トークン取得要求を受けた認可サーバー連携クライアント５００は、アプリケーション管理フレームワーク８００を介して、要求元のリソースサービス連携アプリケーション４００のアプリケーションＩＤを取得する（Ｓ４．５）。アプリケーションＩＤを取得した認可サーバー連携クライアント５００は、トークン保存要求に対してＵＵＩＤを生成し、ステートＩＤとして発行する。同時に認可サーバー連携クライアント５００は、アプリケーションＩＤとステートＩＤを図１１ｃに示された親トークン管理テーブル２７００に保存する。

次に認可サーバー連携クライアント５００は、リソースサービス連携アプリケーション４００に対し、ステートＩＤを通知する（Ｓ４．６）。トークン取得要求に対してステートＩＤの通知を受けたリソースサービス連携アプリケーション４００は、ステートＩＤとデバイス管理テーブル１６００のエンドポイントＵＲＬ１６０３から取得したＵＲＬと共に、認可サーバー連携クライアント５００にＯＡｕｔｈの認可リクエストをするようブラウザ９００にリダイレクト要求する（Ｓ４．７）。この認可リクエストには、デバイス管理テーブル１６００のクライアントＩＤ１６０１、リダイレクトＵＲＬ１６０４、前記認可サーバー連携クライアント５００から通知されたステートＩＤ１９２１の情報が含まれる。リダイレクト要求を受け付けたブラウザ９００は認可サーバー連携クライアント５００に対してリダイレクトし、認可連携の開始を要求する（Ｓ４．８）。

認可サーバー連携クライアント５００は、認可連携の開始を受け付けたら、デバイス管理テーブル１６００のエンドポイントＵＲＬ１６０３に記載のＵＲＬに対して、ＯＡｕｔｈの認可リクエストをするようブラウザ９００にリダイレクト要求する（Ｓ４．９）。この認可リクエストには、デバイス管理テーブル１６００のクライアントＩＤ１６０１、リダイレクトＵＲＬ１６０４、前記認可サーバー連携クライアント５００から通知されたステートＩＤ１９２１の情報が含まれる。また、ＯＡｕｔｈでは、認可を受けたい権限範囲を示すスコープを認可リクエストに含むよう構成する事もできる。本実施例では、スコープとしてスコープＡがリクエストされたとして説明する。またＯＡｕｔｈでは、ステートを認可リクエストに含むよう構成することもできる。本実施例では、ステートとして認可サーバー連携クライアント５００がトークン保存要求時に生成したステートＩＤがリクエストされたとして説明する。

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

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

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

ここで、リダイレクトＵＲＬ１３０３はクライアント管理テーブル１３００ではなく、認可トークン管理テーブル１４００にカラムを追加し、認可コード発行時に登録して、該追加カラムと検証するよう構成する事もできる。これらすべての検証が正しい場合に認可サーバー２００は親トークンを生成して、親トークンの認可トークンＩＤを認可サーバー−連携クライアント５００に応答する。この際、応答内容として同時に発行したリフレッシュトークンＩＤも含む（Ｓ４．１７）。親トークンとしては、認可トークンＩＤ１４０１に発行したトークンのＩＤ、トークン種別１４０２に親トークン、有効期限１４０３、および認可コードから引き継ぐ情報として、クライアントＩＤ１４０７、ユーザーＩＤ１４０８を登録する。この際、親トークンをリフレッシュするためのリフレッシュトークンを発行し、リフレッシュトークンＩＤ１４０５、リフレッシュ期限１４０６に登録する。リフレッシュのフローについては後述する。

親トークンを取得した認可サーバー連携クライアント５００は、認可サーバー２００に対し、親トークンを送信するとともにクラウドユーザーのＩＤを要求する（Ｓ４．１８）。クラウドユーザーのＩＤを要求された認可サーバー２００は、まず、クラウドユーザーＩＤ要求に含まれる親トークンが認可トークン管理テーブル１４００の親トークンＩＤ１４０１に含まれているかを検証する。含まれている場合は、クラウドユーザーＩＤ要求に含まれる親トークンＩＤがリフレッシュ期限内か確認する。さらに、トークンリフレッシュ要求に含まれるクライアントＩＤがクライアントＩＤ１４０７と一致するか検証し、全ての検証が正しい場合は、認可トークン管理テーブル１４００の、前記クラウドユーザーＩＤ要求に含まれる親トークンＩＤに一致する、ユーザーＩＤ１４０８のクラウドユーザーＩＤを返す（Ｓ４．１９）。

クラウドユーザーＩＤを取得した認可サーバー連携クライアント５００は、図１１ｃの親トークン管理テーブル２７００に、アプリケーションＩＤ、クラウドユーザーＩＤ、親トークンの認可トークンＩＤ、リフレッシュトークンＩＤ、ステートＩＤを保存する（Ｓ４．２０）。そして、認可サーバー連携クライアント５００は、リソースサービス連携アプリケーション４００に対し、クラウドユーザーＩＤの取得をリクエストするようブラウザ９００にリダイレクト要求をする（Ｓ４．２１）。この際のＵＲＬは、自身が内部に持つバッチ設定ＵＲＬとなる。リダイレクト要求を受けたブラウザ９００は、リソースサービス連携アプリケーション４００に対し、バッチ設定画面を表示するようバッチ設定ＵＲＬにリダイレクトする（Ｓ４．２２）。バッチ設定画面を表示するようにリクエストされたリソースサービス連携アプリケーション４００は、ステートＩＤを基にトークン保存要求を出して認証されたクラウドユーザーを識別するため、ステートＩＤを送信して認可サーバー連携クライアント５００に対してクラウドユーザーＩＤ取得要求を出す（Ｓ４．２３）。クラウドユーザーＩＤ取得要求を受けた認可サーバー連携クライアント５００は、通知されたステートＩＤを基に親トークン管理テーブル２７００の、前記クラウドユーザーＩＤにマッチするクラウドユーザーＩＤを返却する（Ｓ４．２４）。

トークン保存要求にマッチしたクラウドユーザーＩＤを通知されたリソースサービス連携アプリケーション４００は、前記クラウドユーザーＩＤと共に図１３ｂに示すようなバッチ設定画面をブラウザ９００に表示する（Ｓ４．２５）。ユーザーはバッチ設定画面図１３ｂを参照してバッチ実行時間を設定する（４．２６）。

バッチ実行時間設定は、次のように行われる。ユーザーのバッチ設定画面の入力内容を受けたリソースサービス連携アプリケーション４００が、画像形成装置３００のタイマーサービス１１００を介し、図１６のタイマー設定時間管理テーブル３０００のアプリケーションＩＤ３００１に自身のアプリケーションＩＤを、タイマー通知時間３００２にバッチ実行時間を設定する。同時にリソースサービス連携アプリケーション４００は、図１７のバッチ実行時間管理テーブル４０００に対して、クラウドユーザーＩＤをクラウドユーザーＩＤ４００１に、バッチ実行時間をバッチ実行時間４００２に設定する。

図３に示したタイマーサービス１１００は、画像形成装置３００のアプリケーションの要求に応じて図１６のタイマー設定時間管理テーブルにタイマー設定元アプリケーションのＩＤとタイマー通知時間を設定する機能を持つ。タイマーサービス１１００は、アプリケーションＩＤ毎に時間を管理し、アプリケーションが予め設定した時刻になると、アプリケーションに対してタイマーイベントを通知する機能を持つ。

続いて、親トークンが発行されたあと、設定したバッチ実行時間に達したリソースサービス連携アプリケーション４００が、子トークンを取得して処理を実行するに至る本実施の形態のシーケンスを、図１４を用いて説明する。

ユーザーが画像形成装置にログインしてアプリケーションを起動する場合、リソースサービス連携アプリケーション４００は図８のシーケンスで子トークンの取得、およびアプリケーション処理を実施していた。一方、予め設定した時刻にタイマーサービスによってアプリケーションがバッチ実行する場合、リソースサービス連携アプリケーション４００は図１４のシーケンスで子トークンの取得、およびアプリケーション処理を実施する。

本シーケンスは、設定された時刻において、タイマーサービス１１００からリソースサービス連携アプリケーション４００に対しタイマーイベントが通知され、バッチ実行される際に行われるシーケンスである。なお、図１２に示す親トークン取得のシーケンスが実施されている必要がある。

画像形成装置３００内で管理する時間において、タイマーサービス１１００に設定されたバッチ実行時間に達した場合、タイマーサービス１１００は、設定されたアプリケーションＩＤに相当するアプリケーションにタイマーイベントを通知する。本実施例の場合、先にＳ４．２６ でリソースサービス連携アプリケーション４００により設定された時刻に、タイマーサービス１１００がリソースサービス連携アプリケーション４００にタイマーイベントを通知する（Ｓ５．１）。リソースサービス連携アプリケーション４００は、タイマー通知を受け取るとバッチ実行管理テーブル４０００を参照して、タイマー通知時間に相当するバッチ実行時間４００２を検索し、該当するクラウドユーザーＩＤ４００１を取得する。そして、アプリケーション管理フレームワーク８００に登録されている認可サーバー連携クライアント５００のトークン取得インターフェースに対してトークン取得要求を行う（Ｓ５．２）。この際、先に取得したクラウドユーザーＩＤを要求に含める。なお、ここでトークンに必要なスコープを要求するよう構成する事もできる。本実施例では、スコープＡが引き続き要求されたとして説明する。トークン取得要求を受けた認可サーバー連携クライアント５００は、アプリケーション管理フレームワーク８００を介して、要求元のリソースサービス連携アプリケーション４００のアプリケーションＩＤを取得する（Ｓ５．３）。

アプリケーションＩＤとクラウドユーザーＩＤを取得した認可サーバー連携クライアント５００は以下の処理を行う。認可サーバー連携クライアント５００は、取得したクラウドユーザーＩＤをキーに親トークン管理テーブル２７００からリフレッシュトークンＩＤを取得する。この時、親トークン管理テーブル２７００にクラウドユーザーＩＤが登録されていない場合は、親トークン取得シーケンスを実施するようユーザーに促す画面（不図示）を提示するよう構成する事もできる。また、場合によってはブラウザ９００を起動し、親トークン取得シーケンスを自動的に開始するよう構成するでも良い。バッチ実行用親トークン管理テーブル２７００は、実施例１で述べた親トークン管理テーブル１７００と同様に親トークンを管理する。ユーザーが画像形成装置３００にログインしてクラウドサービスと連携したアプリケーションを実行する場合、画像形成装置３００は、親トークン管理テーブル１７００を選択し、使用する。対して、ログインユーザーが介在せず、バッチ実行でクラウドサービスと連携したアプリケーションを実行する場合、画像形成装置３００は、バッチ実行用親トークン管理テーブル２７００を選択し、使用する。

認可サーバー連携クライアント５００は取得したリフレッシュトークンＩＤと、デバイス管理テーブル１６００のクライアントＩＤ、クライアントシークレットを用いて認可サーバー２００にトークンリフレッシュ要求を行う（Ｓ５．４）。ここでは、親トークン取得シーケンスの実行から、子トークン取得のシーケンスまでの間に時間が経過し、親トークンの有効期限が切れている事として説明している。しかし、親トークンの有効期限内である場合は、トークンリフレッシュ要求を実施せず、Ｓ５．８の子トークン取得要求を実施するでも良い。

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

リフレッシュされた親トークンを取得した認可サーバー連携クライアント５００は、受け付けた認可トークンＩＤ、リフレッシュトークンＩＤにて親トークン管理テーブルの情報を上書きし、再登録する（Ｓ５．７）。そして、親トークンの認可トークンＩＤと、デバイス管理テーブル１６００のクライアントＩＤ、クライアントシークレット、トークン取得要求で受けつけたスコープ、および、取得したアプリケーションＩＤを用いて、認可サーバー２００に子トークン取得要求を行う（Ｓ５．８）。ここで子トークン取得要求に含めるアプリケーションＩＤがリソースサービス連携アプリケーション４００による改竄の余地がない事は後述する。

子トークン取得要求を受けた認可サーバー２００は以下の処理を実行する。まず、子トークン取得要求に含まれるクライアントＩＤ、クライアントシークレットの組がユーザー管理テーブル１２００のユーザーＩＤ１２０１とパスワード１２０２の組と合っているか否かを検証する。正しい場合は、子トークン取得要求に含まれる認可トークンＩＤが認可トークン管理テーブル１４００に登録されており、有効期限内であるか否かを確認する。さらに、子トークン取得要求に含まれるクライアントＩＤがクライアントＩＤ１４０７と一致するか検証し、全ての検証が正しい場合は、子トークンを生成し（Ｓ５．９）認可サーバー連携クライアント５００に応答する（Ｓ５．１０）。

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

そして、子トークンの認可トークンＩＤを取得した認可サーバー連携クライアント５００は要求元のリソースサービス連携アプリケーション４００に子トークンの認可トークンＩＤを応答する。子トークンの認可トークンＩＤを取得したリソースサービス連携アプリケーション４００は、リソースサーバー２１０に認可トークンＩＤを含むリソース要求を行う（Ｓ５．１１）。リソース要求を受けたリソースサーバー２１０は、要求に含まれる子トークンの認可トークンＩＤのトークン検証を認可サーバー２００に対して要求する（Ｓ５．１２）。このトークン検証要求には、スコープを含める事ができる。

トークン検証要求を受けた認可サーバー２００は、受け付けた認可トークンＩＤが、認可トークン管理テーブル１４００に登録されているか、有効期限内か、および、受け付けたスコープがスコープ１４０４の範囲内かを検証（Ｓ５．１３）し、検証結果をリソースサーバー２１０に応答する（Ｓ５．１４）。次に、リソースサーバー２１０は認可サーバー２００に対して、子トークンの認可トークンＩＤのトークン情報取得を要求する（Ｓ５．１５）。

トークン情報取得要求を受けた認可サーバー２００は、認可トークン管理テーブル１４００から受け付けた認可トークンＩＤにて特定される情報を取得し、それら情報をリソースサーバー２１０に応答する（Ｓ５．１６）。この応答には、例えば、スコープ１４０４、クライアントＩＤ１４０７、ユーザーＩＤ１４０８、アプリケーションＩＤ１４０９の情報を含む。さらには、クライアントＩＤ１４０７にて特定されるクライアント管理テーブル１３００に登録されているシリアル番号１３０４を含むよう構成する事もできる。トークン情報を取得したリソースサーバー２１０は、取得した情報を元に要求を受け付けたリソースに対するアクセスを許可するか拒否するかを判断する。ここでは、リソースサーバー２１０に予めアクセス可能なアプリケーションＩＤが設定されているとし、その設定されているアプリケーションＩＤと、トークン情報から取得されたアプリケーションＩＤを比較することでアクセスを許可するかを検証する（Ｓ５．１７）。検証の結果、アクセス許可と判断された場合は、リソースサービス連携アプリケーション４００に対して、リソースを応答する（Ｓ５．１８）。

ここで、リソースは例えば、リソースサーバー２１０が印刷サービスであった場合は印刷可能な文書のリストであり、帳票サービスであった場合は、作成可能な帳票のリストである。また、ＦＡＸサービスであった場合はＦＡＸ送信可能なＦＡＸ文書、ＦＡＸ送信先のリストであり、スキャンサービスの場合はスキャン文書の格納先リストである。ここで、Ｓ５．１２から、Ｓ５．１７まで、トークンの検証を認可サーバー２００、リソースサーバー２１０それぞれで行うよう説明したが、リソースに対するアクセス可能なアプリケーションを認可サーバー２００で管理し、全ての検証を認可サーバー２００で行うよう構成する事も可能である。

また、本実施例ではアクセス可能なアプリケーションの判断をアプリケーションＩＤを用いて実施するよう説明したが、トークン情報から取得できるシリアル番号やクライアントＩＤを元に画像形成装置３００を識別し、アクセスの可否を判断するよう構成する事もできる。また、同様に、トークン情報から取得できるスコープやユーザーＩＤを元にアクセスの可否を判断するよう構成する事もできる。

実施例１によれば、１回の認可操作で同一の画像形成装置内の複数のアプリケーションのそれぞれに認可操作することなく、子トークンを発行する事ができ利便性が向上する。と共に、クラウドサービス側にてアクセス元のアプリケーションを改竄されること無く識別する事が可能となる。

また、実施例１によれば、画像形成装置３００にバッチ処理を登録することで、リソースサービス連携アプリケーション４００の不正なリソースアクセスを防止しつつ、ユーザーがログインすることなくバッチ処理が実行でき、利便性が向上する。これと共に、クラウドサービス側にてアクセス元のアプリケーションを詐称されることなく安全にリソースアクセスを許可することが可能となる。

さらに、実施例１においてはリソースサービス連携アプリケーション４００のバッチ実行について言及した。画像形成処理装置３００のユーザーは、予めバッチ処理設定を行っておくことで、リソースサービス連携アプリケーション４００について、バッチ処理と、ユーザーログインによる実行を使い分けることが可能になり、利便性が向上する。

［その他の実施例］
本願発明の実施例１では、親トークンを発行する必要があるという前提で説明したが、予め認可サーバー連携クライアント４００がユーザー毎に親トークンを管理している状態でも良い。この場合、画像形成装置３００に認可サーバー連携クライアント４００がインストールされた段階で親トークンが使用でき、画像形成装置３００を利用するユーザーが増加することには対処し難くなるが、子トークンを発行する処理に対応は可能である。

本願発明の実施例１では、リソースサービスとして帳票サービス、および印刷サービスと言った画像処理サービスを例に説明したが、これに限らずその他のサービス、例えばゲームアプリケーション、または音楽のコンテンツ配信サービスであっても良い。また、端末であるデバイス装置として画像形成装置を例に説明したが、これに限らずその他のデバイス装置、例えば、スマートフォン、または音楽機器であっても良い。また、リソースサービス連携アプリケーションとして帳票アプリケーション、印刷アプリケーションを説明したが、これに限らずその他のアプリケーション、例えば、アプリケーション管理ソフト、または音楽アプリケーションであっても良い。このように、本願発明を実施する各主体に制限はない。更に、リソースサービスは複数あることを前提に説明したが、単体であっても良い。

２００ 認可サーバー
２１０ リソースサーバー
３００ 画像形成装置
４００ 認可サーバー連携クライアント
５００ リソースサーバー連携アプリケーション
８００ アプリケーション管理フレームワーク
９００ Ｗｅｂブラウザ
１０００ ログインアプリケーション

Claims (11)

1. ネットワークを介して接続された外部装置へサービスを提供するサーバーシステム、および認可サーバーシステムと通信することが可能であり、前記サービスを利用するアプリケーションをインストールすることが可能なデバイス装置であって、
   ユーザーが持っている前記サービスを利用するための権限を前記デバイス装置に移譲することを許可する認可操作が行われたことに応じて前記認可サーバーシステムにより発行される第１の権限情報を取得する第１の取得手段と、
   予め設定された時刻においてバッチ実行を開始する前記アプリケーションから、前記サービスを利用するユーザーを識別するための識別情報を受信する受信手段と、
   受信された前記識別情報を基に、前記第１の権限情報を特定する特定手段と、
   ユーザーから移譲された権限を前記アプリケーションに対して更に移譲する要求を、特定された前記第１の権限情報とともに前記認可サーバーシステムへ送信し、前記第１の権限情報に基づき発行された第２の権限情報を前記認可サーバーシステムから取得する第２の取得手段とを有するデバイス装置。
2. 前記第１の取得手段は、前記ユーザーによりバッチ設定の要求が行われた際に前記第１の権限情報を取得することを特徴とする請求項１に記載のデバイス装置。
3. 前記第２の取得手段は、ユーザーからの認可操作を受け付けることなく、第２の権限情報を前記認可サーバーシステムから取得することを特徴とする請求項１または２に記載のデバイス装置。
4. 要求元である前記アプリケーションは、前記第２の取得手段から前記第２の権限情報を取得し、取得された前記第２の権限情報を用いて前記サービスを受けることを特徴とする請求項１乃至３の何れか１項に記載のデバイス装置
5. 前記第２の取得手段は、要求元である前記アプリケーションのアプリケーションＩＤを取得し、ユーザーから移譲された権限を前記アプリケーションに対して更に移譲する要求を、前記第１の権限情報、および前記アプリケーションＩＤとともに前記認可サーバーシステムへ送信し、前記アプリケーションＩＤに紐付けて管理される前記第２の権限情報を前記認可サーバーシステムから取得することを特徴とする請求項１乃至４の何れか１項に記載のデバイス装置。
6. 要求元である前記アプリケーションが前記第２の取得手段から前記第２の権限情報を取得し、取得された前記第２の権限情報を用いて前記サービスを受ける際、前記アプリケーションから送信された前記第２の権限情報に紐付けて管理されているアプリケーションＩＤが前記サーバーシステムに予め設定されている場合に、要求元である前記アプリケーションは前記サービスを受けることを特徴とする請求項５に記載のデバイス装置。
7. 前記デバイス装置は、
   仮想マシンにより提供されるアプリケーション実行環境上で動作するアプリケーションのライフサイクルを管理するフレームワークを更に有し、
   前記フレームワークは、前記アプリケーションが改竄されていないことを確認してインストールを行う際に、前記アプリケーションのアプリケーションＩＤを管理し、
   前記第２の取得手段は、前記フレームワークを介して前記アプリケーションＩＤを取得することを特徴とする請求項５または６に記載のデバイス装置。
8. 前記サーバーシステムは、印刷サービス、および帳票サービスの内、少なくとも１つの画像処理サービスを提供するサーバーシステムであり、
   前記デバイス装置は印刷部、およびスキャナ部の内、少なくとも１つの画像処理部を備えた画像形成装置であることを特徴とする請求項１乃至７の何れか１項に記載のデバイス装置。
9. 前記デバイス装置はスマートフォンであることを特徴とする請求項１乃至７の何れか１項に記載のデバイス装置。
10. ネットワークを介して接続された外部装置へサービスを提供するサーバーシステム、および認可サーバーシステムと通信することが可能であり、前記サービスを利用するアプリケーションをインストールすることが可能なデバイス装置を制御する制御方法であって、
    第１の取得手段は、ユーザーが持っている前記サービスを利用するための権限を前記デバイス装置に移譲することを許可する認可操作が行われたことに応じて前記認可サーバーシステムにより発行される第１の権限情報を取得し、
    受信手段は、予め設定された時刻においてバッチ実行を開始する前記アプリケーションから、前記サービスを利用するユーザーを識別するための識別情報を受信し、
    特定手段は、受信された前記識別情報を基に、前記第１の権限情報を特定し、
    第２の取得手段は、ユーザーから移譲された権限を前記アプリケーションに対して更に移譲する要求を、特定された前記第１の権限情報とともに前記認可サーバーシステムへ送信し、前記第１の権限情報に基づき発行された第２の権限情報を前記認可サーバーシステムから取得することを特徴とする制御方法。
11. 請求項１０に記載の制御方法を実行するためのプログラム。

Images