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

Abstract

【課題】 スマートフォンを始めとする、アプリケーションの追加・削除を可能とするデバイス装置に複数のアプリケーションをインストールし、各アプリケーションがクラウドサービスと連携するケースを考える。従来技術では、クラウドサービスを利用するアプリケーション毎にユーザーが認可操作を行う事になり、操作が煩雑になってしまう。
【解決手段】 権限情報の取得要求を要求元であるアプリケーションから受け付けた場合に、ユーザーから移譲された権限をアプリケーションに対して更に移譲する要求を、第１の権限情報とともに認可サーバーシステムへ送信し、第１の権限情報に基づき発行された第２の権限情報を認可サーバーシステムから取得する。
【選択図】 図８

Description

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

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

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

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

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

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

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

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

特開２０１２−００８９５８号公報

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

ここでスマートフォンを始めとする、アプリケーションの追加・削除を可能とするデバイス装置に複数のアプリケーションをインストールし、各アプリケーションがクラウドサービスと連携するケースを考える。例えば、ＯＡｕｔｈのような権限移譲プロトコルを用いてユーザーはアプリケーションに権限を移譲するであろう。その場合は、ユーザーは以下のような操作フローを行う事になる。ユーザーは自身のデバイス装置にクラウドサービスと連携する第一のアプリケーションを追加する。次に、第一のアプリケーションを起動し、認可操作を行いクラウドサービスへのアクセス権限を第一のアプリケーションに委譲する。次に、ユーザーが第二のアプリケーションを追加した場合は、ユーザーは再度、認可操作を行い第二のアプリケーションに権限委譲を行う。つまり、追加するクラウドサービスを利用するアプリケーション毎にユーザーは認可操作を行う事になり、操作が煩雑になってしまう。

本発明は、上述した課題を解決するためのデバイス装置を提供することを目的の１つとする。

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

本発明によれば、従来よりも少ない回数の認可操作で複数の各アプリケーションに権限委譲を行う事ができる。

権限移譲システムの構成図。 各装置のハードウェア構成図。 各装置のソフトウェアモジュール構成図。 認可サーバーが管理するテーブル構造。 画像形成装置が管理するテーブル構造。 親トークン発行までのシーケンス。 認可処理に関連する画面。 子トークン発行までのシーケンス。 アプリケーション管理シーケンス。 アプリケーションの構成およびテーブル構造。

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

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

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

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

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

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

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

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

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

実施例１では、画像形成装置に特に有効な実施形態について説明する。スマートフォンのようなユーザー所有のデバイスのアプリケーションに権限を移譲する場合は、利便性は低いものの、自身が追加したアプリケーションへの操作であるため許容される操作であると言える。しかしながら、複数のユーザーで共有するデバイス、例えば、アプリケーションの追加・削除が可能な画像形成装置の場合は別である。画像形成装置に対するアプリケーションの追加は画像形成装置の管理者が行うことが通例であり、装置の一般利用者は追加されたアプリケーションを利用している認識はなく、画像形成装置に備わる機能を利用している認識しかしていない。そのため、何かしらの画像形成装置の機能（実際は追加されたアプリケーション）を利用するたびに認可操作を求められる事は、利便性が低いだけでなく、理由が理解できず煩雑に感じてしまう。また、権限移譲の際は利用者毎に認可操作が行われるので、装置の一般利用者が多ければ多いほど画像形成装置上で行われる認可操作は増加し、画像形成装置が占有されてしまい他のユーザーが利用できない状況も発生する。

そこで、上述したように、各アプリケーションに対する認可操作をより少ない回数、例えば、１回の認可操作で各アプリケーションに権限を移譲させる仕組みをデバイス装置、およびクラウドサービスに導入することが考えられる。つまり、１回の認可操作で取得した認可トークンをデバイス装置内のアプリケーション間で共有する方法が考えられる。

一方、クラウドサービスの提供元はアクセスしてくるアプリケーションを特定したいという要求がある。特に有償のクラウドサービスを提供する場合は不正利用を防止する目的でアクセス元のアプリケーションを限定したいという要求がある。ＯＡｕｔｈを用いて、この要求にこたえるためにはアプリケーションごとに認可操作する事になる。

前述の１回の認可操作で取得した認可トークンを画像形成装置内のアプリケーション間で共有する方法では、クラウドサービス側でアプリケーションを特定できない。実施例１では、画像形成装置を例にこの２つの矛盾した関係を解決するための実施形態を説明する。

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

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

３００は画像形成装置であり、１つまたは複数のリソースサービス連携アプリケーションがインストールされている。ユーザーはそれらのリソースサービス連携アプリケーションを用いてリソースサービスを利用する。また認可サーバー２００、リソースサービス２１０、画像形成装置３００はそれぞれＷＡＮ１００およびＬＡＮ１０１を介して接続されている。なお認可サーバー２００、リソースサービス２１０、画像形成装置３００はそれぞれ個別のＬＡＮ上に構成されていてもよいし同一のＬＡＮ上に構成されていてもよい。また認可サーバー２００、リソースサービス２１０は同一のサーバー上に構成されていてもよい。

本実施の形態に係る権限移譲システムは、図２に示すような構成のサーバーおよび画像形成装置から成るシステム上に実現される。図２は、認可サーバー２００と画像形成装置３００とがＷＡＮ１００およびＬＡＮ１０１を介して通信可能に接続されている様子を示す。

まず、認可サーバー２００の構成について説明する。尚、図２に示されるハードウェアブロック図は一般的な情報処理装置のハードウェアブロック図に相当するものとし、本実施形態の認可サーバー２００には一般的な情報処理装置のハードウェア構成を適用できる。また認可サーバー２００だけでなく、リソースサーバー２１０についても同様である。図２において、ＣＰＵ２０１は、ＲＯＭ２０３のプログラム用ＲＯＭに記憶された、或いはハードディスク（ＨＤ）等の外部メモリ２１１からＲＡＭ２０２にロードされたＯＳやアプリケーション等のプログラムを実行しシステムバス２０４に接続される各ブロックを制御する。ここでＯＳとはコンピュータ上で稼動するオペレーティングシステムの略語であり、以下オペレーティングシステムのことをＯＳと呼ぶ。後述する各シーケンスの処理はこのプログラムの実行により実現できる。ＲＡＭ２０２は、ＣＰＵ２０１の主メモリ、ワークエリア等として機能する。

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

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

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

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

外部メモリ３０３は、メモリコントローラ（ＭＣ）３０９によりアクセスを制御される。外部メモリ３０３は、オプションとして接続され、フォントデータ、エミュレーションプログラム、フォームデータ等を記憶する。また、操作部３１１は操作のためのスイッチ及びＬＥＤ表示器等で構成されている。尚、後述の全ての説明においては、特に断りのない限り画像形成装置における実行のハード上の主体はＣＰＵ３０１であり、ソフトウェア上の主体は外部メモリ３０３にインストールされたアプリケーションプログラムである。

図３は本実施の形態に係る、認可サーバー２００、リソースサーバー２１０、画像形成装置３００それぞれのモジュール構成を示す図である。図３に示す何れのモジュールも、図２で示した各装置のＣＰＵが外部メモリにインストールされたアプリケーションプログラムをＲＡＭを利用して実行することで実現されるモジュールである。認可サーバー２００は認可サーバーモジュール６００を備え、リソースサーバー２１０はリソースサーバーモジュール７００を備えている。

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

また、認可サーバー連携クライアント４００、１つまたは複数のリソースサーバー連携アプリケーション５００、ログインアプリケーション１０００は、仮想マシン８１０が提供するアプリケーション実行環境にて動作する各種アプリケーションである。また、これらアプリケーションはアプリケーション管理フレームワーク８００にてライフサイクル管理されている。なお、アプリケーション管理フレームワークは、後述するアプリケーション定義ファイルに記載された定義値に基づきアプリケーションの管理を行う。例えば、アプリケーションに固有に割り当てられているアプリケーションＩＤと、インストールされている、もしくは開始されているアプリケーションの実態との紐づけ管理を行う。アプリケーションＩＤはアプリケーションを識別するための識別情報であり、各アプリケーションに固有、または特定のグループに所属するアプリケーションに共通な情報である。８３０はアプリケーション管理フレームワーク８００が公開するライフサイクル管理用の制御Ｉ／Ｆを介して、ユーザーからの各種アプリケーションのインストールや、開始リクエストを受け付け実行するアプリケーション管理アプリケーションである。
ここで認可サーバー連携クライアント４００、リソースサーバー連携アプリケーション５００およびログインアプリケーション１０００は、画像形成装置が既定で備えていてもよく、またアプリケーション管理アプリケーション８３０、およびアプリケーション管理フレームワーク８００を介して後からインストールされてもよい。さらに、画像形成装置３００はＷＷＷを利用するためのユーザーエージェントであるＷｅｂブラウザ９００を備える。なお、アプリケーション管理フレームワーク８００におけるアプリケーションのインストール、開始のシーケンスについては後述する。

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Claims (13)

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

Images