特開 2023-175082 認可システム、認可サーバー、制御方法、およびプログラム

(19)【発行国】日本国特許庁(JP)

(12)【公報種別】公開特許公報(A)

(11)【公開番号】P2023175082

(43)【公開日】2023-12-12

(54)【発明の名称】認可システム、認可サーバー、制御方法、およびプログラム

(51)【国際特許分類】

   G06F 21/33 20130101AFI20231205BHJP

   G06F 21/62 20130101ALI20231205BHJP

【ＦＩ】

G06F21/33

G06F21/62 318

【審査請求】未請求

【請求項の数】10

【出願形態】ＯＬ

(21)【出願番号】P 2022087348

(22)【出願日】2022-05-30

【公序良俗違反の表示】

（特許庁注：以下のものは登録商標）

１．ＱＲコード

(71)【出願人】

【識別番号】000001007

【氏名又は名称】キヤノン株式会社

(74)【代理人】

【識別番号】100126240

【弁理士】

【氏名又は名称】阿部 琢磨

(74)【代理人】

【識別番号】100124442

【弁理士】

【氏名又は名称】黒岩 創吾

(72)【発明者】

【氏名】鈴木 良介

(57)【要約】      （修正有）

【課題】認可サーバーがリソース所有者と直接的に権限委譲処理を行う場合においても、リソース所有者が間違えなくクライアントデバイスに対して権限委譲を行う認可システム、認可サーバー、制御方法及びプログラムを提供する。
【解決手段】要求されたリソースへの操作を許可するアクセストークンを発行する認可システムにおいて、認可サーバー１５１は、要求されたリソースにアクセスしようとするクライアント１１１から認可要求を受信する受信手段と、認可操作を行う端末１７１を特定する特定手段と、認可操作を行う端末１７１に認可処理を要求する要求手段と、認可処理の結果を受信する受信手段と、結果に応じてアクセストークンを発行しクライアント１１１に送信する送信手段と、を備える。認可要求には第１の確認コードを含み、認可処理の結果には第２の確認コードを含み、第１の確認コードと第２の確認コードを比較してアクセストークンの発行を制御する。
【選択図】図４

【特許請求の範囲】

【請求項1】

要求されたリソースへの操作を許可するアクセストークンを発行する認可サーバーから構成される認可システムであり、
前記リソースにアクセスしようとするクライアントから認可要求を受信する受信手段と、
認可操作を行う端末を特定する特定手段と、
認可操作を行う前記端末に認可処理を要求する要求手段と、
認可処理の結果を受信する受信手段と、
結果に応じて前記アクセストークンを発行し前記クライアントに送信する送信手段と、を備え、
前記認可要求には第１の確認コードを含み、
前記認可処理の結果には第２の確認コードを含み、
前記第１の確認コードと第２の確認コードを比較してアクセストークンの発行を制御する認可システム。

【請求項2】

前記第１の確認コードには、前記クライアントによって表示される形式情報を含むことを特徴とする請求項１に記載の認可システム。

【請求項3】

前記受信手段は認可要求の情報を受信し、
受信された前記認可要求の情報を複数格納する認可情報テーブルを保持する保存手段を具備し、
前記認可処理の結果を受信する際、前記認可情報テーブルのうち、前記第２の確認コードと同じ確認コードを持つレコードを更新する更新手段を備えることを特徴とする請求項２に記載の認可システム。

【請求項4】

要求されたリソースへの操作を許可するアクセストークンを発行する認可サーバーであって、
前記リソースにアクセスしようとするクライアントから認可要求を受信する受信手段と、
認可操作を行う端末を特定する特定手段と、
認可操作を行う前記端末に認可処理を要求する要求手段と、
認可処理の結果を受信する受信手段と、
結果に応じて前記アクセストークンを発行し前記クライアントに送信する送信手段と、を備え、
前記認可要求には第１の確認コードを含み、
前記認可処理の結果には第２の確認コードを含み、
前記第１の確認コードと第２の確認コードを比較してアクセストークンの発行を制御する認可サーバー。

【請求項5】

前記第１の確認コードには、前記クライアントによって表示される形式情報を含むことを特徴とする請求項４に記載の認可サーバー。

【請求項6】

前記受信手段は認可要求情報を受信し、
受信された前記認可要求情報を複数格納する認可情報テーブルを保持する保存手段を具備し、
前記認可処理の結果を受信する際、前記認可情報テーブルのうち、前記第２の確認コードと同じ確認コードを持つレコードを更新する更新手段を備えることを特徴とする請求項５に記載の認可サーバー。

【請求項7】

要求されたリソースへの操作を許可するアクセストークンを発行する認可サーバーから構成される認可システムの制御方法であり、
前記リソースにアクセスしようとするクライアントから認可要求を受信するステップと、
認可操作を行う端末を特定するステップと、
認可操作を行う前記端末に認可処理を要求するステップと、
認可処理の結果を受信するステップと、
結果に応じて前記アクセストークンを発行し前記クライアントに送信するステップを備え、
前記認可要求には第１の確認コードを含み、
前記認可処理の結果には第２の確認コードを含み、
前記第１の確認コードと第２の確認コードを比較してクセストークンの発行を制御する制御方法。

【請求項8】

前記第１の確認コードには、前記クライアントによって表示される形式情報を含むことを特徴とする請求項７に記載の制御方法。

【請求項9】

認可要求情報を受信するステップを含み、
受信された前記認可要求情報を複数格納する認可情報テーブルを保持する保存ステップを含み、
前記認可処理の結果を受信する際、前記認可情報テーブルのうち、前記第２の確認コードと同じ確認コードを持つレコードを更新する更新ステップを含むことを特徴とする請求項８に記載の制御方法。

【請求項10】

請求項７乃至９のいずれか１項に記載の制御方法を認可システムに実行させるためのコンピュータプログラム。

【発明の詳細な説明】

【技術分野】

【0001】

本発明は、ユーザーのリソースの権限委譲を可能とする認可システム、認可サーバー、制御方法、およびプログラムに関する。

【背景技術】

【0002】

クラウドのｗｅｂサービスでＯＡｕｔｈ２．０による権限委譲を実現している。特許文献１ではシステム連携を設定する際にユーザーは、クライアントと認可サーバーの両方をウェブブラウザで操作し、認可操作を行うことで、ユーザーの権限をクライアントに委譲できることについて開示している。クライアントは、委譲されたユーザーの権限を用いて、ユーザーのリソースにアクセスでき、システム連携が実現する。一方、Ｇｒａｎｔ Ｎｅｇｏｔｉａｔｉｏｎ ａｎｄ Ａｕｔｈｏｒｉｚａｔｉｏｎ Ｐｒｏｔｏｃｏｌ、通称ｇｎａｐと呼ばれるプロトコルがある。ｇｎａｐでは、クライアントから認可処理が要求されると、認可サーバーとリソース所有者がインタラクションを行い、その結果に基づきクライアントにアクセストークンを発行することで権限委譲する方法が提案されている。この方法を利用すれば、ウェブブラウザを持たないようなデバイスでも、安全に権限移譲を行うことができる。

【先行技術文献】

【特許文献】

【0003】

【特許文献1】特許５６２３２３４

【発明の概要】

【発明が解決しようとする課題】

【0004】

ｇｎａｐには、認可サーバーにアクセス要求をしたときに受信するＵＲＬ情報をクライアントデバイスに表示し、ウェブブラウザを持つデバイス（例えばスマートフォン等）でアクセスして権限委譲を行う方法が開示されている。しかしこの方法は、クライアントデバイスがＵＲＬ情報（文字列、あるいはＱＲコード等）を表示する必要があるため、クライアントデバイスが備える表示装置によっては採用できない場合がある。そのような場合には、認可サーバーがリソース所有者と直接的に通信を行う方法によってクライアントデバイスにアクセストークンを発行する方法がある。

【0005】

しかしながら、認可サーバーがリソース所有者と直接的に通信を行ってしまうと、どのクライアントデバイスに対する認可処理をおこなっているのか、リソース所有者がわかりにくいという課題があった。

【0006】

本発明は、前述の課題を鑑みてなされたものであり、認可サーバーがリソース所有者と直接的に権限委譲処理を行う場合においても、リソース所有者が間違えなくクライアントデバイスに対して権限委譲を行えることを目的とする。

【課題を解決するための手段】

【0007】

本発明の一実施形に係る認可システムは、要求されたリソースへの操作を許可するアクセストークンを発行する認可サーバーから構成される認可システムであり、前記リソースにアクセスしようとするクライアントから認可要求を受信する受信手段と、認可操作を行う端末を特定する特定手段と、認可操作を行う前記端末に認可処理を要求する要求手段と、認可処理の結果を受信する受信手段と、結果に応じて前記アクセストークンを発行し前記クライアントに送信する送信手段と、を備え、前記認可要求には第１の確認コードを含み、前記認可処理の結果には第２の確認コードを含み、前記第１の確認コードと第２の確認コードを比較してアクセストークンの発行を制御することを特徴とする。

【発明の効果】

【0008】

本発明によれば、認可サーバーはクライアントデバイスが送信したアクセスリクエスト時に受け付けた確認コードと、認可確認時に受け付けた確認コードを比較できる。このためリソース所有者が誤ったクライアントデバイスに対してアクセストークンを発行することを防止できる。

【図面の簡単な説明】

【0009】

【図1】ネットワーク構成を示す図である。

【図2】本実施の形態に係る、プリンタ１１１と、認可サーバー１５１の構成を示す図。

【図3】本実施の形態に係る、機能構成を示す図。

【図4】本実施の形態に係る、権限移譲処理全体のフローを説明する図。

【図5】本実施の形態に係る、アクセストークン取得処理のフローチャート。

【図6】本実施の形態に係る、認可サーバーの各種処理のフローチャート。

【図7】本実施の形態に係る、権限移譲処理に利用するＪＳＯＮデータの例。

【図8】本実施の形態に係る、権限移譲処理開始時の画面の例。

【図9】本実施の形態に係る、認可処理画面の例。

【図10】本実施の第２の形態に係る、アクセストークン取得処理のフローチャート。

【図11】本実施の第３の形態に係る、権限移譲処理に表示する画面の例。

【図12】本実施の第３の形態に係る、認可サーバーの各種処理のフローチャート。

【図13】本実施の第３の形態に係る、認可処理失敗時のＪＳＯＮデータの例。

【発明を実施するための形態】

【0010】

＜実施例１＞
以下、本発明を実施するための形態について図面を用いて説明する。本実施の形態に係る権限委譲システムは、図１に示すような構成のネットワーク上に実現される。

【0011】

１００は、Ｗｉｄｅ Ａｒｅａ Ｎｅｔｗｏｒｋ（ＷＡＮ１００）であり、本発明ではＷｏｒｌｄ Ｗｉｄｅ Ｗｅｂ（ＷＷＷ）システムが構築されている。１１０、１５０、１７０は各構成要素を接続するＬｏｃａｌ Ａｒｅａ Ｎｅｔｗｏｒｋ（ＬＡＮ１１０、ＬＡＮ１５０、ＬＡＮ１７０）である。

【0012】

１５２はユーザーのリソースを管理するリソースサーバーであり、１１１はリソースサーバー１５２上のリソースにアクセスするプリンタ（クライアント）である。ここでクライアントがリソースサーバー１５２上のリソースにアクセスするためには、リソース所有者であるユーザーがクライアントに権限を委譲する必要がある。１５１はクライアントの要求に応じてリソースへのアクセス許可の証拠となるアクセストークンを発行する認可サーバーである。１７１はクライアントが権限委譲を要求した際に認可確認画面を表示するユーザー端末である。

【0013】

認可サーバー１５１、リソースサーバー１５２はそれぞれＬＡＮ１５０を介してＷＡＮ１００と接続されている。また同様にクライアントはＬＡＮ１１０を介して、ユーザー端末１７１はＬＡＮ１７０を介して、それぞれＷＡＮ１００と接続されている。なお認可サーバー１５１、リソースサーバー１５２はそれぞれ個別のＬＡＮ上に構成されていてもよいし同一のＬＡＮ上に構成されていてもよい。同様に、同一のＰＣまたはサーバーコンピューター上に構成されていてもよい。また、認可サーバー１５１、リソースサーバー１５２は図１ではそれぞれが１台として描かれているが複数のサーバーから構成されたサーバーシステムでも良い。例えば、複数台のサーバーをクラスタ化して認可サーバー１５１を構成しても良い。なお、本願発明においてサーバーシステムと称した場合は、少なくとも１台のサーバーから構成された特定のサービスを提供する装置を指すものとする。

【0014】

図２（Ａ）は本実施の形態に係る認可サーバー１５１、リソースサーバー１５２，ユーザー端末１７１のハードウェア構成を示す図である。尚、図２（Ａ）に示されるハードウェアブロック図は一般的な情報処理装置のハードウェアブロック図に相当するものとし、本実施形態のサーバーコンピューターには一般的な情報処理装置のハードウェア構成を適用できる。また、図２（Ｂ）は本実施の形態に係るプリンタ１１１の構成を示す図である。

【0015】

図２（Ａ）（Ｂ）において、ＣＰＵ２０１は、ＲＯＭ２０３のプログラム用ＲＯＭに記憶された、或いは記憶装置２１１からＲＡＭ２０２にロードされたＯＳやアプリケーション等のコンピュータプログラムを実行する。ここでＯＳとはコンピュータ上で稼動するオペレーティングシステムの略語であり、以下オペレーティングシステムのことをＯＳと呼ぶ。後述する各フローチャートの処理はこのプログラムの実行により実現できる。ＲＡＭ２０２は、ＣＰＵ２０１の主メモリ、ワークエリア等として機能する。入力装置２０５はキーボード等の入力装置であり、利用者からの入力を受け付ける。ディスプレイ２０６は各種情報を表示する。

【0016】

記憶装置２１１は各種データを記憶するハードディスク（ＨＤ）２１１やフロッピー（登録商標）ディスク（ＦＤ）等である。ＮＩＣ２０７はネットワークに接続されて、ネットワークに接続された他の機器との通信制御処理を実行する。尚、後述の全ての説明においては、特に断りのない限り実行のハード上の主体はＣＰＵ２０１であり、ソフトウェア上の主体は記憶装置２１１にインストールされたアプリケーションプログラムである。またアプリケーションプログラムはＮＩＣ２０７を制御してネットワーク間のデータ通信を行う。プリンタエンジン２１２は、アプリケーションプログラムによって生成されたビットマップデータを用紙面上に永久固着画像として加熱定着処理する。

【0017】

図３は本実施の形態に係る、プリンタ１１１、認可サーバー１５１、リソースサーバー１５２、ユーザー端末１７１の機能構成を示す図である。図３（Ａ）はプリンタ１１１、図３（Ｂ）は認可サーバー１５１、図３（Ｃ）はリソースサーバー１５２、図３（Ｄ）はユーザー端末１７１の機能構成をそれぞれ示す。プリンタ１１１は印刷処理部３０１と、アクセストークン取得部３０２を持つ。認可サーバー１５１は認可リクエスト管理部３２１、認可確認部３２２、アクセストークン発行部３２３を持つ。リソースサーバー１５２はデータ管理部３３１を持つ。ユーザー端末１７１はブラウザ３４１とメーラー３４２を持つ。

【0018】

プリンタ１１１のアクセストークン取得部３０２は、印刷処理部３０１で行う印刷処理に先立ち、認可サーバー１５１からアクセストークンを取得する。認可サーバー１５１の認可リクエスト管理部３２１は、プリンタ１１１（クライアント）のアクセストークン取得部３０２から送信されるアクセス要求に従い、アクセス要求処理を制御する。認可確認部３２２は、クライアントから送信される情報に基づいて特定されたユーザー端末１７１に対する認可確認処理を制御する。なお本実施例において認可確認リクエストとはユーザー端末１７１が受信可能なメールアドレスに対して、認可確認部が生成する認可確認画面のＵＲＬを送信するものとする。ユーザー端末１７１のメーラー３４２は上記のように送信されたメールを不図示のメールサーバーから受信して表示する。

【0019】

ユーザー端末１７１は利用者の操作に基づき、上記メールで送信されたＵＲＬをブラウザ３４１でアクセスすることによって、認可確認画面を表示する。利用者の操作に基づきブラウザ３４１は認可応答を認可サーバー１５１の認可確認部３２２に送信する。アクセストークン発行部３２３は認可確認部３２２の処理結果に基づき、アクセストークンを発行する。

【0020】

アクセストークン発行部３２３がアクセストークンを発行すると、プリンタ１１１のアクセストークン取得部３０２は認可リクエスト管理部３２１からアクセストークンを取得できる。このアクセストークンを用いて、プリンタ１１１の印刷処理部３０１は、リソースサーバー１５２のデータ管理部３３１から印刷データのリストや印刷データそのものを受信し、プリンタエンジン２１２を制御して印刷処理を実行する。

【0021】

図４には上述したクライアントがアクセストークンを要求してからリソースサーバーからリソース（印刷データのリストや印刷データそのもの）を取得するまでの全体のフローが図示されている。

【0022】

本実施例において、認可サーバー１５１にアクセス要求するクライアントは、アクセス要求する前に認可サーバー１５１に登録されている必要がある。クライアントを認可サーバー１５１に登録する方法は公知の方法を用いるものとし、具体的な方法は省略する。

【0023】

図５のフローチャートを用いて、上述したプリンタ１１１のアクセストークン取得部３０２の動作についての詳細を説明する。まずアクセストークン取得部３０２は、利用者ＩＤの入力を受け付けるための画面をプリンタ１１１のディスプレイ２０６に表示し利用者ＩＤの入力を受け付ける（Ｓ５０１）。利用者ＩＤの入力を受け付けると、アクセストークン取得部３０２は確認コードを発行する（Ｓ５０２）。確認コードとは、プリンタ１１１のディスプレイ２０６に表示可能であり、ユーザー端末１７１にて入力可能なアクセストークン取得部３０２がランダムに生成する文字列であり、形式情報である。

【0024】

続いてアクセストークン取得部３０２は、プリンタ１１１のディスプレイ２０６にＳ５０２で生成した確認コードが含まれる画面を表示する（Ｓ５０３）。続いてアクセストークン取得部３０２は、Ｓ５０１で受け付けた利用者ＩＤとＳ５０２で生成した確認コードを含むアクセス要求を認可サーバー１５１に送信する（Ｓ５０４）。

【0025】

続いてアクセストークン取得部３０２は、Ｓ５０４で送信したアクセス要求に対する応答を受信する（Ｓ５０５）。Ｓ５０５で受信した応答内容が認可処理を継続する内容だった場合、アクセストークン取得部３０２は、受信した内容に基づき、認可継続要求を認可サーバー１５１に送信する（Ｓ５０９）。Ｓ５０５で受信した応答内容がアクセストークンを含む場合、アクセストークン取得部３０２は、受信したアクセストークンをＲＡＭ２０２に格納して、印刷処理部３０１を起動してアクセストークン取得の処理を完了する（Ｓ５０８）。もしＳ５０７でアクセストークンが含まれない場合、アクセストークン取得部３０２はエラー情報をプリンタ１１１のディスプレイ２０６に表示して、Ｓ５０１からの処理を繰り返す（Ｓ５１０）。

【0026】

なお、Ｓ５０５で認可サーバーからレスポンスを受信する際に、同時にＩＤトークンを受信してもよい。ＩＤトークンは認可処理を行った利用者をリソースサーバー１５２で識別するために利用する。

【0027】

印刷処理部３０１は上述のように取得したアクセストークン及びＩＤトークンを用いて、リソースサーバー１５２のデータ管理部３３１から情報を取得する。アクセストークン及びＩＤトークンを用いたリソースサーバーからの情報取得の方法は当該業者に知られている一般的な方法で実現することができるため、説明を省略する。

【0028】

続いて認可サーバー１５１の動作について図６のフローチャートを用いて説明する。図６（Ａ）はクライアント（プリンタ１１１）からアクセス要求を受け付けた際の認可リクエスト管理部３２１のフローチャートである。

【0029】

まず認可リクエスト管理部３２１は、認可サーバー１５１のクライアントからアクセス要求を受信する（Ｓ６０１）。ここで受信するアクセス要求には、上述した利用者ＩＤと確認コードが含まれる。続いて認可リクエスト管理部３２１は、認可サーバー１５１の記憶装置２１１に保存されている利用者テーブルに、Ｓ６０１で受信した利用者ＩＤが含まれているか確認する（Ｓ６０２）。利用者テーブルとは、利用者ＩＤと利用者に対してメッセージ通知するための宛先情報（本実施例においてはメールアドレス）が関連付けられているテーブルであり、例えば次のようなテーブルである。

【0030】

【表1】

【0031】

ここで利用者ＩＤはクライアントから通知されるＩＤであり、ユーザーＩＤは後述する認可画面で入力されるＩＤである。ユーザーＩＤは認可確認部３２２で認証処理を行うときに利用される。利用者ＩＤとユーザーＩＤは重複しない限り同じＩＤを登録してもかまわない。利用者テーブルへの登録は、本システムの利用に先立ち、利用者の申請に基づき登録される。

【0032】

上記利用者テーブルにＳ６０１で受信した利用者ＩＤが登録されていない場合、認可リクエスト管理部３２１はクライアントにエラーを送信してアクセス要求処理を終了する（Ｓ６０６）。

【0033】

上記利用者テーブルにＳ６０１で受信した利用者ＩＤが登録されている場合、認可リクエスト管理部３２１は利用者ＩＤに対応するメールアドレスに送信する、専用の認可画面を表示するための認可ＵＲＬを新規に発行する。この認可ＵＲＬにユーザー端末１７１のブラウザ３４１がアクセスすると、ユーザーＩＤとパスワード、及び確認コードを受け付ける認可画面が表示される。その後認可リクエスト管理部３２１は上記対応するメールアドレスに発行したＵＲＬを含むメールを送信する（Ｓ６０３）。

【0034】

続いて認可リクエスト管理部３２１は、クライアントに送信するクライアントが認可継続要求を行う際に必要となる認可継続要求用アクセストークンを発行して、認可ＵＲＬ、確認コード、ユーザーＩＤとともに認可情報テーブルに保存する。認可情報テーブルとは、クライアントからアクセス要求を受け取ってからアクセストークンを渡すまでに間の情報を保持するテーブルであり、例えば次のようなテーブルである。

【0035】

【表2】

【0036】

認可情報テーブルの認可状況は認可状況を表し、後述で説明する認可応答処理で認可確認部３２２によって”許可”、もしくは”拒否”に設定される。初期値は”ｎｕｌｌ”である。なお、認可情報テーブルに登録されたレコードは、登録後一定時間経過すると自動的に削除されるようにしてもよい。表２にはこれらの情報が複数格納されている。

【0037】

認可情報テーブルのＩＤトークンは、クライアントに対して発行するＩＤトークンであり、これも認可確認部３２２によって設定される。最後に認可リクエスト管理部３２１は認可継続要求用アクセストークンを含む応答をクライアントに送信する（Ｓ６０５）。

【0038】

図６（Ｂ）はユーザー端末１７１のブラウザ３４１から認可ＵＲＬに対してアクセス要求を受け付けた際の認可確認部３２２のフローチャートである。まず認可確認部３２２は認可ＵＲＬに対するアクセスを受け付ける（Ｓ６１１）。続いて認可確認部３２２は認可画面を表示するためのＨＴＭＬをブラウザ３４１に送信し、認可画面の操作結果である認可情報を受信する（Ｓ６１２）。この認可情報には、認可を許可するか拒否するかの情報と、ユーザーＩＤとパスワード、確認コード、認可ＵＲＬが含まれる。Ｓ６１２で受信したデータが認可を拒否するものであれば、認可確認部３２２は認可情報テーブルからＳ６１３で受信した認可ＵＲＬと同一のレコードの認可状況を”拒否”に更新する（Ｓ６２０）。

【0039】

Ｓ６１２で受信した認可情報が認可を許可するものである場合、認可確認部３２２はＳ６１３で受信したユーザーＩＤと認可ＵＲＬが認可情報テーブルに登録されている情報と等しいか確認する（Ｓ６１４）。等しくない場合、認可確認部３２２はユーザー端末１７１のブラウザ３４１にユーザーＩＤが正しくない旨を表示するデータを返信して、Ｓ６１２に戻る（Ｓ６１５）。登録情報が正しかった場合、認可確認部３２２はＳ６１３で受信したユーザーＩＤとパスワードで認証処理を行う（Ｓ６１６）。正しく認証できない場合、認可確認部３２２はユーザー端末１７１のブラウザ３４１にパスワードが正しくない旨を表示するデータを返信して、Ｓ６１２に戻る（Ｓ６１７）。

【0040】

正しく認証できた場合、認可確認部３２２はＳ６１３で受信した確認コードが認可情報テーブルに登録されている情報と等しいか確認する（Ｓ６１８）。確認コードが正しくない場合、認可確認部３２２はユーザー端末１７１のブラウザ３４１に確認コードが正しくない旨を表示するデータを返信して、Ｓ６１２に戻る（Ｓ６１９）。確認コードが正しい場合、認可確認部３２２はアクセストークン発行部３２３で、Ｓ６１６で認証したユーザーのＩＤトークンを発行して対応する認可情報テーブルのレコードを更新するとともに、認可状況を”許可”に更新する（Ｓ６２０）。最後に認可確認部３２２はＳ６１３で受信した認可ＵＲＬにアクセスできないようにして処理を終了する（Ｓ６２１）。

【0041】

図６（Ｃ）はクライアント（プリンタ１１１）から認可継続要求を受け付けた際の認可リクエスト管理部３２１のフローチャートである。まず認可リクエスト管理部３２１は、認可サーバー１５１のクライアントから認可継続要求を受信する（Ｓ６２１）。ここで受信する認可継続要求は、図６（Ａ）のＳ６０５で認可リクエスト管理部３２１が送信した認可継続要求用アクセストークンを含む応答に対応してクライアントが送信するものであり、認可継続要求用アクセストークンが含まれる。続いて認可リクエスト管理部３２１はＳ６２１で受信した認可継続要求用アクセストークンに対応するレコードを認可情報テーブルから検索し、認可状況を確認する（Ｓ６２２）。

【0042】

Ｓ６２２で認可情報テーブルから見つからなかった場合（Ｓ６２３）、認可リクエスト管理部３２１はエラー応答をクライアントに送信する（Ｓ６２７）。Ｓ６２２で認可情報テーブルの対応するレコードの認可状況が”拒否”である場合（Ｓ６２４）、認可リクエスト管理部３２１は認可拒否応答をクライアントに送信する（Ｓ６２８）。Ｓ６２２で認可情報テーブルの対応するレコードの認可状況が”許可”である場合（Ｓ６２５）、認可リクエスト管理部３２１はアクセストークン発行部３２３でアクセストークンを発行する。更に認可情報テーブルに登録されているＩＤトークンとともにクライアントに送信する（Ｓ６２６）。Ｓ６２５で認可情報テーブルの対応するレコードの認可状況が”許可”でない場合、図６（Ａ）のＳ６０５と同様、認可リクエスト管理部３２１は認可継続要求用アクセストークンを含む応答をクライアントに送信する（Ｓ６２９）。

【0043】

図７は、クライアント（プリンタ１１１）と認可サーバー１５１間で通信するデータの一例である。７０１は上述したアクセス要求の一例であり、アクセスを行うリソースと行う操作を示す”ａｃｃｅｓｓ＿ｔｏｋｅｎ”属性を含む。またアクセス要求を行ったクライアントの情報を示す”ｃｌｉｅｎｔ”属性を含む。またＩＤトークンを要求するための”ｓｕｂｊｅｃｔ”属性を含む。また、利用者ＩＤを含む”ｕｓｅｒ”属性が含む。更に”ｃｌｉｅｎｔ”属性には確認コードを示す”ｃｈｅｃｋ＿ｃｏｄｅ”属性が含まれている。認可要求情報である。

【0044】

７０２は上述した認可継続応答の一例であり、認可継続要求用アクセストークンを示す”ａｃｃｅｓｓ＿ｔｏｋｅｎ”属性が含まれている。７０３は上述したアクセストークンを含む応答の一例であり、アクセストークンを示す”ａｃｃｅｓｓ＿ｔｏｋｅｎ”属性と、ＩＤトークンを含む”ｓｕｂｊｅｃｔ”属性が含まれている。

【0045】

図８はプリンタ１１１のアクセストークン取得部３０２と印刷処理部３０１がプリンタ１１１のディスプレイ２０６に表示する画面の一例である。図８（Ａ）はアクセストークン取得部３０２が図５のＳ５０１で表示する利用者ＩＤを受け付けるための画面の一例であり、利用者ＩＤを入力する８０１と入力終了時に押下する決定ボタン８０２を持つ。

【0046】

図８（Ｂ）はアクセストークン取得部３０２が図５のＳ５０３で表示する確認コードを表示する画面の一例であり、確認コード８１１を持つ。図８（Ｃ）は印刷処理部３０１が表示する画面の一例であり、印刷対象のデータを選択するための印刷データリスト８２１と、印刷データリストに表示されている印刷データを切り換えるためのボタン８２２と、印刷を開始するためのボタン８２３を持つ。

【0047】

印刷処理部３０１は認可サーバー１５１から取得したアクセストークンとＩＤトークンを用いて、リソースサーバー１５２のデータ管理部３３１から、利用者が印刷可能なデータのリストを受取り印刷データリストに追加する。また、印刷処理部３０１はボタン８２３が押下されると、認可サーバー１５１から取得したアクセストークンとＩＤトークンを用いてリソースサーバー１５２のデータ管理部３３１から選択された印刷データリストを受信して印刷処理を実行する。

【0048】

図９は認可リクエスト管理部３２１がユーザー端末１７１のディスプレイに表示する認可画面の一例である。９０１はユーザーＩＤを入力するためのテキストボックス、９０２はパスワードを入力するためのテキストボックスである。９０３は確認コードを入力するためのテキストボックスである。

【0049】

ボタン９０４は要求された認可を許可する際に押下するボタンであり、９０１及至９０３の項目が入力されていない状態では押下不可の状態にするのが望ましい。

【0050】

ボタン９０５は要求された認可を拒否する際に押下するボタンである。

【0051】

本実施の形態によれば、クライアントデバイスは利用開始時に生成した確認コードを認可サーバーに送信して認可処理を要求する。認可サーバーはユーザー端末から認可情報と確認コードを受信して、認可処理を要求したときの確認コードと比較してアクセストークンをクライアントに発行するか制御する。このため、誤ったクライアントデバイスからの認可要求に対して認可処理を行うことを防止することが可能になる。

【0052】

＜実施例２＞
上述した実施例では、クライアント（プリンタ１１１）は利用開始時に確認コードを生成していた。本実施例ではクライアントに予め登録されている確認コードを利用して認可処理を行う。

【0053】

本実施例のプリンタ１１１には、予め確認コードがランダムに割り振られており、確認コードをＱＲコード形式で符号化したものと、符号化前のＱＲコードがデバイスに付与される。本実施例におけるプリンタ１１１のアクセストークン取得部３０２の処理を図１０のフローチャートを用いて説明する。なお図１０のフローチャートの各ステップのうち、図５と同じステップについては同じ番号を付与して説明は省略する。

【0054】

利用者ＩＤの入力を受け付けると、アクセストークン取得部３０２はプリンタ１１１のデータＲＯＭ２０３或いは記憶装置２１１に予め設定された確認コードを読み取る（Ｓ１００１）。続いてアクセストークン取得部３０２は、Ｓ５０１で受け付けた利用者ＩＤとＳ１００１で取得した確認コードを含むアクセス要求を認可サーバー１５１に送信する（Ｓ１００２）。移行の処理は図５と同じであるため説明を省略する。

【0055】

図１１の１１１０は本実施例のプリンタ１１１のアクセストークン取得部３０２が送信するアクセス要求に含まれる確認コードの一例である。本実施例の認可確認部３２２は、アクセス要求に含まれる確認コードの”ｆｏｒｍａｔ”属性が”ＱＲ”である場合、ＱＲ画像を読み取り可能なプログラムを含む認可確認画面を生成し、ユーザー端末１７１に送信する。

【0056】

図１１の１１１０は上述の確認コードをＱＲコード形式で符号化したＱＲコード１１０１が印刷されたシールであり、プリンタ１１１の出荷時にプリンタ１１１の本体に張り付けられている。なお、図１１の１１１０のＱＲコードは、本体に張り付けたシールが破れたり汚れたりした場合に備え、印刷処理部３０１で紙面に印刷できるようにしてもかまわない。

【0057】

図１１の１１２０は本実施例の認可確認部３２２が生成するＱＲ画像を読み取り可能なプログラムを含む認可確認画面の一例であり、ＱＲコードの撮影を開始するためのボタンと、読み取った確認コードを表示するテキストボックス１１２１が含まれている。

【0058】

本実施の形態によれば、クライアントデバイスは予め登録された確認コードを認可サーバーに送信して認可処理を要求する。予め登録された認可コードは、ＱＲコード形式でクライアントデバイス読み取り可能なように設置されている。このためＱＲコードの表示能力を有さないディスプレイをもつクライアントにおいても、認可コードをユーザー端末に備え付けられた撮像装置を用いて読み取ることが可能になる。

【0059】

＜実施例３＞
上述した実施例では、認可確認部３２２は認可確認画面の操作結果に基づき、認可情報テーブルのその元となるレコードの認可状況を更新していた。本実施例の認可確認部３２２は同じ確認コードを持つレコードの認可状況も更新する。

【0060】

本実施例におけるプリンタ１１１のアクセストークン取得部３０２の処理を図１２（Ａ）のフローチャートを用いて説明する。なお図１２（Ａ）のフローチャートの各ステップのうち、図６（Ｂ）と同じステップについては同じ番号を付与して説明は省略する。

【0061】

本実施例における認可確認部３２２のユーザー端末１７１のブラウザ３４１から認可ＵＲＬに対してアクセス要求を受け付けた際の処理を図１２（Ａ）のフローチャートを用いて説明する。なお、図１２のフローチャートの各ステップのうち、図６（Ｂ）と同じステップについては同じ番号を付与して説明は省略する。

【0062】

確認コードが正しくない場合、認可確認部３２２はＳ６１２で受信した確認コードが設定されている認可情報テーブルのレコードを検索し、存在する場合には、そのレコードの認可状況を”不正”に更新する（Ｓ１２０１）。その後の処理は図６（Ｂ）のＳ６１９と同じである。

【0063】

続いて本実施例におけるクライアント（プリンタ１１１）から認可継続要求を受け付けた際の認可リクエスト管理部３２１の処理を図１２（Ｂ）のフローチャートを用いて説明する。なお図１２（Ｂ）のフローチャートの各ステップのうち、図６（Ｃ）と同じステップについては同じ番号を付与して説明は省略する。

【0064】

認可情報テーブルの認可状況に”不正”が設定されている場合、認可リクエスト管理部３２１は認可中断応答をクライアントに送信する（Ｓ１２１１）。認可中断応答を受けたクライアント（プリンタ１１１）は実行中の認可処理を中断する。

【0065】

図１３は上述した認可状況に”不正”が設定されている場合の認可継続応答の一例である。

【0066】

本実施の形態によれば、認可確認部３２２はユーザー端末から送信される認可情報に含まれる確認コードと同値になる認可情報テーブルのレコードの認可状況を更新し、該レコードを要求したクライアントに対する認可処理を失敗させる。このため、認可コードを発行或いは登録されたクライアントでエラー表示を行うことができるので、利用者は別のクライアントからの認可要求に対して認可処理したことを認識しやすくなる。

【0067】

＜その他の実施例＞
本発明は、上述の実施形態の１以上の機能を実現するプログラムを、ネットワーク又は記憶媒体を介してシステム又は装置に供給し、そのシステム又は装置のコンピュータにおける１つ以上のプロセッサがプログラムを読出し実行する処理でも実現可能である。また、１以上の機能を実現する回路（例えば、ＡＳＩＣ）によっても実現可能である。

【符号の説明】

【0068】

１１１ クライアント
１５１ 認可サーバー
１５２ リソースサーバー
１７１ ユーザー端末

【図1】

【図2】

【図3】

【図4】

【図5】

【図6】

【図7】

【図8】

【図9】

【図10】

【図11】

【図12】

【図13】