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

Abstract

【課題】簡便にログイン可能とすると共に不正なアクセスを防止可能とすることができる。を目的とする。
【解決手段】Ｗｅｂアクセス認証なしの認可用の第１ＵＲＬと、Ｗｅｂアクセス認証ありの認可用の第２ＵＲＬと、を保持する保持手段と、第１ＵＲＬでリクエストを受け付けた場合、受け付けたリクエストの送信先アドレスが内部通信アドレスか否かを判定する判定手段と、判定手段により受け付けたリクエストの送信先アドレスが内部通信アドレスであると判定された場合、接続を許可し、判定手段により受け付けたリクエストの送信先アドレスが内部通信アドレスでないと判定された場合、接続を拒否する制御手段と、を有することによって課題を解決する。
【選択図】図９

Description

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

近年インターネット上でＰＤＦ形式の電子文書を作成するサービスや電子文書を蓄積するサービス等が提供されている。このようなサービスを利用することでユーザーは、自身が所有する端末自体にＰＤＦ作成機能がない場合でもＰＤＦを作成できるようになる他、端末の記憶容量以上に電子文書を保管できるようにもなる。これらのサービスを連携させることでサービス提供者は、ユーザーに付加価値を提供することができる。例えば作成したＰＤＦ形式の電子文書を、ユーザーが所有する端末を経由することなく、直接、インターネット上で保管できるようにもなる。その一方で、サービスが連携することにより、いくつかの課題が生まれる。
即ち、ユーザーが望んだ以上の情報がサービス間で交換されるので、ユーザーデータや個人情報の漏えいリスクがある。例えばインターネット上には複数のサービスが存在し、様々なサービス間でサービス連携が実現されるが、ユーザーが望む結果を提供するサービス以外のサービスがユーザーデータ、個人情報等を取得することは望ましくない。一方で、サービスの提供者からすると、サービス連携の仕組みは容易に実装できるものが好ましい。

このような状況において、ＯＡｕｔｈと呼ばれる、認可の連携を実現させるための標準プロトコルが策定されている。ＯＡｕｔｈについては以降で更に詳細に説明する。
ＯＡｕｔｈによれば、例えばあるサービスＡが管理するユーザーのデータに、そのユーザーから認められた外部サービスＢがアクセスすることができる。このときサービスＡは、外部サービスＢからアクセスされる範囲を明らかにした上で、外部サービスＢによるアクセスに対してユーザーの明示的な認可を得ることになっている。ユーザーが明示的に認可を行うことを認可操作と称する。
ユーザーが認可操作を行うと、外部サービスＢはサービスＡからアクセスを認められたことを証明するトークン（以下、認可トークンと称する）を受け取り、以降のアクセスはその認可トークンを用いて実現できる。
ここで認可トークンを用いると外部サービスＢは、ユーザーの認証情報なしに、認可を行ったユーザーの権限でサービスＡにアクセスできる。そのため、認可トークンを取得した外部サービスＢは、その認可トークンを厳重かつ適正に管理する責務を負う。
更に、特許文献１には、画像処理装置が、パスワードを画像処理装置の操作パネル又はネットワークを介して受信できるように２つのインターフェースを備えることが記載されている。

また近年の機器には、ＯＡｕｔｈを用いて、クラウドサービスと連携することでユーザーに付加価値を提供するものがある。
例えばソーシャル・ネットワーキング・サービス（以下、ＳＮＳと呼ぶ）と呼ばれるサービスがある。これらのサービスはスマートフォンから利用することができる。ＳＮＳには様々なものがあるが、特定のアプリケーションをスマートフォンにインストールして利用することで、そのＳＮＳを利用しやすくなることがある。例えば定期的に自分の居場所をＳＮＳに投稿したいユーザーは、スマートフォンの測位機能を使い、定期的に測位とＳＮＳへの投稿とを行うアプリケーションを利用すると、便利と感じるだろう。
ここでスマートフォンにインストールされたアプリケーションは、ＳＮＳにユーザーの代理でアクセスすることになる。このような場合にＯＡｕｔｈが利用されることがある。
ユーザーは、ＳＮＳを利用するのに必要な最小限の機能、例えば記事を投稿することをアプリケーションに許可することで、アプリケーションを介してＳＮＳを利用できるようになる。

特開２００４−２５９２６６号公報

ここで画像形成装置がＯＡｕｔｈクライアントとなりクラウドサービスと連携する場合を考える。ユーザーが画像形成装置にクラウドサービスのリソースへのアクセスを権限移譲することで、画像形成装置はクラウドサービスと連携できるようになる。しかし、画像処理装置は複数ユーザーで共有するため複数ユーザーのユーザー管理が行われることが多い。しかし、画像形成装置に権限移譲したユーザーのクラウドサービスのリソースに画像処理装置の全てのユーザーがアクセス可能となるのは好ましくなく、クラウドサービスのユーザーと画像形成装置のユーザーとの連携が必要となる。
クラウドサービスのユーザーと画像形成装置のユーザーとの連携の一つの解として、画像形成装置のユーザーに認可トークンを紐付けて保持し、画像形成装置へのログインしたユーザーに紐付いた認可トークンを利用してクラウドサービスにアクセスすることである。これによりクラウドサービスと画像形成装置のＳＳＯ（Ｓｉｎｇｌｅ Ｓｉｇｎ Ｏｎ）とを実現することができる。ここで画像形成装置のユーザーに認可トークンを紐付けするためには画像形成装置にログインした状態でＷｅｂブラウザを用いてユーザーが権限移譲する必要がある。

画像形成装置のログイン方法には画像形成装置の操作部からログインする方法とＷｅｂブラウザを使ってＷｅｂログインする方法とがある。しかしながら、画像形成装置上のＷｅｂブラウザを用いる場合、操作部からのログインで画像形成装置にログインし、かつ、ＷｅｂブラウザからのリクエストでＷｅｂログインを行う必要があった。したがって、ユーザーは２度も画像形成装置のログインを強いられることになり利便性を欠くという課題があった。

特許文献１では、画像処理装置が操作パネル又はネットワークを介してパスワードを受信できると記載されている。しかしながら、上述した課題については考慮されていなかった。

本発明はこのような問題点に鑑みなされたもので、簡便にログイン可能とすると共に不正なアクセスを防止可能とすることを目的とする。

そこで、本発明は、Ｗｅｂアクセス認証なしの認可用の第１ＵＲＬと、Ｗｅｂアクセス認証ありの認可用の第２ＵＲＬと、を保持する保持手段と、前記第１ＵＲＬでリクエストを受け付けた場合、受け付けたリクエストの送信先アドレスが内部通信アドレスか否かを判定する判定手段と、前記判定手段により前記受け付けたリクエストの送信先アドレスが内部通信アドレスであると判定された場合、接続を許可し、前記判定手段により前記受け付けたリクエストの送信先アドレスが内部通信アドレスでないと判定された場合、接続を拒否する制御手段と、を有する。

本発明によれば、簡便にログイン可能とすると共に不正なアクセスを防止可能とすることができる。

権限移譲システムのシステム構成の一例を示す図である。 認可サーバーや画像形成装置のハードウェア構成の一例を示す図である。 認可サーバー、リソースサーバー、クライアント端末、画像形成装置それぞれのモジュール構成の一例を示す図である。 ユーザー管理テーブルの一例を示す図である。 クライアント管理テーブルの一例を示す図である。 認可トークン管理テーブルの一例を示す図である。 デバイスユーザー管理テーブルの一例を示す図である。 デバイス管理テーブルの一例を示す図である。 親トークン管理テーブルの一例を示す図である。 認可サーバー連携クライアント起動時のクライアント情報の登録・更新の処理の一例を示すフローチャートである。 画像形成装置のＷｅｂブラウザを用いての親トークンを取得するシーケンスの一例を示す図である。 クライアント端末のＷｅｂブラウザを用いての親トークンを取得するシーケンスの一例を示す図である。 認可連携開始を確認する画面の一例を示す図である。 ログイン画面の一例を示す図である。 認可確認画面の一例を示す図である。 認可サーバー連携クライアントが認可連携開始リクエストを受け付けた後、ログインアプリケーションを特定する処理とデバイス情報更新要否を判断する処理との一例を示すフローチャートである。 親トークンが発行されたあとの子トークンの取得に関するシーケンスの一例を示す図である。

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

＜実施形態１＞
本実施形態においては、インターネット上で帳票データを生成する帳票サービスと、インターネット上のデータを取得して印刷する印刷サービスとが、インターネット上のサーバーにインストールされていることを想定している。
以降、帳票サービスや印刷サービスのように、インターネット上で機能を提供しているサービスを、リソースサービスと呼ぶ。
また本実施形態においては、画像形成装置上にインストールされた印刷アプリケーション及び帳票アプリケーションがリソースサービスを利用することを想定している。
以降、印刷アプリケーションや帳票アプリケーションのように、リソースサービスを利用するアプリケーションを、リソースサービス連携アプリケーションと呼ぶ。無論、リソースサービスは帳票サービス、印刷サービスには限られず、アプリケーションも帳票アプリケーション、印刷アプリケーションに限られるものではない。

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

そこで、アプリケーションに権限を移譲させる際、ユーザーに代わり画像形成装置がアプリケーションに権限を移譲することで、ユーザーの認可操作の回数を低減させる。
即ち、ユーザーは画像形成装置に権限を移譲した段階で、アプリケーションにも権限を移譲することを認めたこととなる。
但し認可操作を一度で済ませる手段として画像形成装置が取得した親トークンを画像形成装置上のアプリケーションで共有できるようにすると親トークンを共有する全てのアプリケーションが全てのリソースサービスにアクセス可能となってしまい好ましくない。これは、共有された親トークンを用いてアプリケーションがリソースサービスにアクセスした場合、リソースサービス側がアクセス元のアプリケーションを特定できず、利用の可否を判断することができないためである。そこで、個々のリソースサービス連携アプリケーションは親トークンを直接使うのでなく、親トークンに移譲された情報を継承しつつ、アプリケーション毎に再移譲して発行されるトークン用いる。親トークンアプリケーション毎に再移譲して発行されたトークンを子トークンと称する。

図１は、権限移譲システムのシステム構成の一例を示す図である。
Ｗｉｄｅ Ａｒｅａ Ｎｅｔｗｏｒｋ（ＷＡＮ１００）は、本実施形態ではＷｏｒｌｄ Ｗｉｄｅ Ｗｅｂ（ＷＷＷ）システムが構築されている。Ｌｏｃａｌ Ａｒｅａ Ｎｅｔｗｏｒｋ（ＬＡＮ）１０１は、各構成要素を接続する。
認可サーバー２００は、ＯＡｕｔｈを実現するためのサーバーあり、認可サービスモジュールがインストールされている。
リソースサーバー２１０は、印刷サービスや帳票サービスといったリソースサービスがインストールされている。尚、１台のリソースサーバーにインストールされるリソースサービスは１つでもよく、複数でもよい。２２０はクライアント端末であり、Ｗｅｂブラウザがインストールされている。

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

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

ＲＡＭ２３２は、ＣＰＵ２３１の主メモリ、ワークエリア等として機能する。
キーボードコントローラ（ＫＢＣ）２３５は、キーボード２３９や不図示のポインティングデバイスからのキー入力を制御する。
ＣＲＴコントローラ（ＣＲＴＣ）２３６は、ＣＲＴディスプレイ２４０の表示を制御する。
ディスクコントローラ（ＤＫＣ）２３７は、各種データを記憶するハードディスク（ＨＤ）等の外部メモリ２４１におけるデータアクセスを制御する。
ネットワークコントローラ（ＮＣ）２３８は、ＷＡＮ１００若しくはＬＡＮ１０１を介して接続された画像形成装置３００や他の機器との通信制御処理を実行する。
尚、上述したように、ＣＰＵ２３１が、プログラムを実行することによってアプリケーション（モジュール）が実現されるが、説明の簡略化のため、アプリケーションが処理を行う様に説明する場合もある。

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

ＲＡＭ３０８は、ＣＰＵ３０１の主メモリや、ワークエリア等として機能するＲＡＭであり、図示しない増設ポートに接続されるオプションＲＡＭによりメモリ容量を拡張することができるように構成されている。また、ＲＡＭ３０８は、出力情報展開領域、環境データ格納領域、ＮＶＲＡＭ等に用いられる。
外部メモリ３０３は、メモリコントローラ（ＭＣ）３０９によりアクセスを制御される。外部メモリ３０３は、オプションとして接続され、フォントデータ、エミュレーションプログラム、フォームデータ等を記憶する。また、操作部３１１は、操作のためのスイッチ及びＬＥＤ表示器等で構成されている。
ＣＰＵ３０１が、ＲＯＭ３０２や、外部メモリ３０３に記憶されたプログラムに基づいて処理を実行することによって、後述するフローチャートや画像形成装置３００のモジュール構成が実現される。尚、ＣＰＵ３０１が、プログラムを実行することによってアプリケーションが実現されるが、説明の簡略化のため、アプリケーションが処理を行う様に説明する場合もある。

図３は、認可サーバー２００、リソースサーバー２１０、クライアント端末２２０、画像形成装置３００それぞれのモジュール構成の一例を示す図である。尚、認可サーバー２００、リソースサーバー２１０、クライアント端末２２０、画像形成装置３００は図２のものと同一である。
認可サーバー２００は、認可サーバーモジュール６００を有する。
リソースサーバー２１０は、リソースサーバーモジュール７００を有する。
クライアント端末２２０は、ＷＷＷを利用するためのユーザーエージェントであるＷｅｂブラウザ１２００を有する。
ＯＳ８２０は、一般的にはリアルタイムＯＳが使用されるが、昨今ではＬｉｎｕｘ（登録商標）等の汎用ＯＳが使用される事もある。
仮想マシン８１０は、例えばＪａｖａ（登録商標）ＶＭがよく知られている。この仮想マシン８１０は、ＯＳで制御されるアプリケーションとして動作する仮想的なアプリケーション実行環境である。

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

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

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

図４Ｂは、クライアント管理テーブル１４００の一例を示す図である。クライアント管理テーブル１４００は、クライアントＩＤ１４０１、クライアント名１４０２、クライアント説明１４０３、リダイレクトＵＲＬ１４０４、シリアル番号１４０５から成る。クライアントＩＤ１４０１は、ユーザー管理テーブル１３００のユーザーＩＤ１３０１と関連付いており、互いに参照可能となっている。クライアント名１４０２、クライアント説明１４０３、リダイレクトＵＲＬ１４０４は、後述のＯＡｕｔｈのシーケンスで利用される値である。そして、シリアル番号１４０５は、クライアントが画像形成装置３００であった場合に登録される値であり、画像形成装置をユニークに識別可能な値である。
図４Ｃは、認可トークン管理テーブル１５００の一例を示す図である。認可トークン管理テーブル１５００は、認可トークンＩＤ１５０１、トークン種別１５０２、有効期限１５０３、スコープ１５０４、リフレッシュトークンＩＤ１５０５、リフレッシュ期限１５０６、クライアントＩＤ１５０７、ユーザーＩＤ１５０８から成る。これら認可トークン管理テーブル１５００の詳細については後述する。

図５Ａ、図５Ｂ、図５Ｃは、画像形成装置３００が外部メモリに記憶するデータテーブルの一例を示す図である。
図５Ａは、デバイスユーザー管理テーブル１５０００の一例を示す図である。デバイスユーザー管理テーブル１５０００は、ローカルログインアプリケーション１０００、Ｗｅｂログインアプリケーション１１００から参照、更新可能なように構成されている。また、本実施形態では画像形成装置３００の外部メモリに記憶するよう記載しているが、画像形成装置３００がＬＡＮ１０１を介して通信可能な別サーバーにて構成するようにしてもよい。
デバイスユーザー管理テーブル１５０００は、ユーザーＩＤ１５０１０、パスワード１５０２０、ＩＣカード情報１５０３０から成る。

ローカルログインアプリケーション１０００は、画像形成装置３００の入力画面を用いてユーザーからのユーザーＩＤ、パスワードを受け付ける画面を構成する。そして、ローカルログインアプリケーション１０００は、入力されたユーザーＩＤ、パスワードの組が、ユーザーＩＤ１５０１０、パスワード１５０２０の組と合っているか検証し、正しければユーザーＩＤ１５０１０の情報を含むログインコンテキストを生成する。ローカルログインアプリケーション１０００は、このことで、各ユーザーを認証する機能を有する。また、ローカルログインアプリケーション１０００は、画像形成装置３００に接続されたＩＣカードリーダーからＩＣカード情報を取得し、ＩＣカード情報１５０３０の情報と合っているか検証する。そして、ローカルログインアプリケーション１０００は、正しければ対応するユーザーＩＤ１５０１０の情報を含むログインコンテキストを生成することで、各ユーザーを認証するようにしてもよい。

Ｗｅｂログインアプリケーション１１００は、ＷｅｂブラウザからユーザーのユーザーＩＤ、パスワードを受け付ける画面を構成する。そして、Ｗｅｂログインアプリケーション１１００は、入力されたユーザーＩＤ、パスワードの組が、ユーザーＩＤ１５０１０、パスワード１５０２０の組と合っているか検証する。Ｗｅｂログインアプリケーション１１００は、正しければユーザーＩＤ１５０１０の情報を含むログインコンテキストを生成することで、各ユーザーを認証する機能を有する。ここで、ログインコンテキストとは、認証を受けたユーザーのユーザーＩＤ１５０１０の情報が設定されたオブジェクトである。尚、ログインコンテキストは、その他に、ユーザーの属性情報、例えば、ユーザーが所属するドメインやユーザーの電子メールアドレス等の情報、を設定するよう構成することもできる。なお、Ｗｅｂログインアプリケーション１１００にてログインが成功することで、Ｗｅｂブラウザ９００又は１２００から認可サーバー連携クライアント４００、リソースサービス連携アプリケーション５００を使用することが可能となる。

図５Ｂは、デバイス管理テーブル１６００の一例を示す図である。デバイス管理テーブル１６００は、認可サーバー連携クライアント４００のみから参照、更新可能なように構成されている。デバイス管理テーブル１６００は、クライアントＩＤ１６０１、クライアントシークレット１６０２、エンドポイントＵＲＬ１６０３、クライアント名１６０５、クライアント説明１６０６、リダイレクトＵＲＬ１６０７から成る。ここで、クライアントＩＤ１６０１、クライアントシークレット１６０２は、予め認可サーバー２００にて発行、記憶されたユーザーＩＤ１３０１、パスワード１３０２にそれぞれ対応している。クライアント名１６０５、クライアント説明１６０６、リダイレクトＵＲＬ１６０７も認可サーバー２００のクライアント管理テーブルにクライアントＩＤ１４０１、画像形成装置３００のシリアル番号１４０５と共に登録されている情報と同様のデータが格納されている。
これらのクライアント情報を認可サーバー連携クライアント４００が認可サーバー２００に登録・更新方法するタイミングは、例えば、認可サーバー連携クライアント４００の起動時と認可連携開始時とである。クライアント情報の登録・更新の詳細については後述する。エンドポイントＵＲＬ１６０３は、認可サーバーが公開するＯＡｕｔｈのためのエンドポイントのＵＲＬである。

図５Ｃは、親トークン管理テーブル１７００の一例を示す図である。親トークン管理テーブル１７００は、認可サーバー連携クライアント４００からのみ参照、更新可能なよう構成されている。親トークン管理テーブル１７００は、ユーザーＩＤ１７０１、認可トークンＩＤ１７０２、リフレッシュトークンＩＤ１７０３から成る。親トークン管理テーブル１７００の詳細については後述する。
認可サーバー連携クライアント４００は、アプリケーション起動時に認可サーバー２００にクライアント情報の登録・更新を行う。

図６は、認可サーバー連携クライアント４００起動時のクライアント情報の登録・更新の処理の一例を示すフローチャートである。
アプリケーション管理フレームワーク８００により起動された認可サーバー連携クライアント４００は（Ｓ１．１）、まず画像形成装置３００のデバイス情報を取得する（Ｓ１．２）。ここで取得するデバイス情報は、プリンタモデル名、プリンタ名、設置場所、シリアル番号である。
次に認可サーバー連携クライアント４００は、Ｓ１．２で取得したデバイス情報を用いてクライアント名とクライアント説明とを生成する（Ｓ１．３）。認可サーバー連携クライアント４００が生成するクライアント名とクライアント説明とは図５Ｂの例に示すような文字列である。本実施形態ではクライアント名にプリンタモデル名を、クライアント説明にプリンタ名と設置場所とを用いている。クライアント名やクライアント説明は後述の認可確認画面１８０３に表示されるためユーザーが識別できる文字列であることが望ましい。ここでプリンタ名、設置場所はユーザーにより任意の値に変更可能であり、変更が行われた場合には合わせてクライアント名、クライアント説明も変更される。

次に認可サーバー連携クライアント４００は、画像形成装置３００のアドレス情報取得を行う（Ｓ１．４）。画像形成装置３００のアドレス情報には、ＩＰｖ４アドレス、ループバックＩＰｖ４アドレス、手動ＩＰｖ６アドレス、リンクローカルＩＰｖ６アドレス、ステートレスＩＰｖ６アドレスがある。また、画像形成装置３００のアドレス情報には更に、ステートフルＩＰｖ６アドレス、ループバックＩＰｖ６アドレス、ホスト名がある。ここでＩＰｖ４アドレス、手動ＩＰｖ６アドレス、リンクローカルＩＰｖ６アドレス、ステートレスＩＰｖ６アドレス、ステートフルＩＰｖ６アドレス、ホスト名はネットワーク環境により変更される可能性がある。
次に認可サーバー連携クライアント４００は、Ｓ１．４において取得したアドレス情報を基にクライアント端末用リダイレクトＵＲＬとデバイスブラウザ用リダイレクトＵＲＬとを生成する（Ｓ１．５）。クライアント端末用リダイレクトＵＲＬは、クライアント端末２２０のＷｅｂブラウザ１２００から接続可能なＵＲＬである。認可サーバー連携クライアント４００は、クライアント端末用リダイレクトＵＲＬをＩＰｖ４アドレス、手動ＩＰｖ６アドレス、ステートフルＩＰｖ６アドレス、ホスト名をＦＱＤＮとして生成する。ＦＱＤＮは、Ｆｕｌｌｙ Ｑｕａｌｉｆｉｅｄ Ｄｏｍａｉｎ Ｎａｍｅの略である。また、認可サーバー連携クライアント４００は、デバイスブラウザ用リダイレクトＵＲＬは、ループバックＩＰｖ４アドレス、ループバックＩＰｖ６アドレスをＦＱＤＮとして生成する。図５ＢにおけるリダイレクトＵＲＬ１６０７は、クライアント端末用リダイレクトＵＲＬとデバイスブラウザ用リダイレクトＵＲＬとを含む例である。
デバイスブラウザ用リダイレクトＵＲＬは、Ｗｅｂアクセス認証なしの認可用の第１ＵＲＬの一例である。クライアント端末用リダイレクトＵＲＬは、Ｗｅｂアクセス認証ありの認可用の第２ＵＲＬの一例である。
本実施形態では転送プロトコルにｈｔｔｐｓを用いており、クライアント端末用リダイレクトＵＲＬのエンドポイントとしてｒｅｄｉｒｅｃｔ、デバイスブラウザ用リダイレクトＵＲＬのエンドポイントとしてｒｅｄｉｒｅｃｔ／ｄｅｖｉｃｅとしている。

次に認可サーバー連携クライアント４００は、デバイス管理テーブル１６００を既に保持しているか否かを確認する（Ｓ１．６）。認可サーバー連携クライアント４００は、デバイス管理テーブル１６００を既に保持している場合は、Ｓ１．１０に処理を進め、デバイス管理テーブル１６００を保持していない場合は、Ｓ１．７に処理を進める。
Ｓ１．７において、認可サーバー連携クライアント４００は、Ｓ１．３やＳ１．５において生成したクライアント名、クライアント説明、リダイレクトＵＲＬとＳ１．２において取得したシリアル番号とを含むクライアント登録要求を認可サーバー２００に送信する。
続いて、認可サーバー連携クライアント４００は、認可サーバー２００からクライアント登録応答としてクライアントＩＤとクライアントシークレットとを受け取り（Ｓ１．８）、デバイス管理テーブル１６００を生成し、保持する（Ｓ１．９）。ここで認可サーバー連携クライアント４００は、デバイス管理テーブルにはＳ１．３やＳ１．５において生成したクライアント名、クライアント説明、リダイレクトＵＲＬをそれぞれ保持しエンドポイントＵＲＬには認可サーバー２００のエンドポイントを保持する。

一方、Ｓ１．１０において、認可サーバー連携クライアント４００は、以下の比較を行う。即ち、認可サーバー連携クライアント４００は、保持しているデバイス管理テーブル１６００のクライアント名１６０５、クライアント説明１６０６、リダイレクトＵＲＬ１６０７に変更がないかＳ１．３やＳ１．５において生成したものと比較する（Ｓ１．１０）。クライアント名、クライアント説明に利用するプリンタ名、設置場所は変更可能である。また、クライアント端末用リダイレクトＵＲＬに利用するＩＰｖ４アドレス、手動ＩＰｖ６アドレス、リンクローカルＩＰｖ６アドレス、ステートレスＩＰｖ６アドレス、ステートフルＩＰｖ６アドレス、ホスト名も変更可能である。変更されている場合には、認可サーバー連携クライアント４００は、認可サーバー２００にクライアント更新要求を行う。
ここでクライアント更新要求には、デバイス管理テーブル１６００のクライアントＩＤ１６０１、クライアントシークレット１６０２が含まれる。また、クライアント更新要求には、Ｓ１．３やＳ１．５で生成されたクライアント名、クライアント説明、リダイレクトＵＲＬと、Ｓ１．２で取得されたシリアル番号が含まれる。
クライアント更新要求に成功すると、認可サーバー連携クライアント４００は、クライアント更新要求で通知した情報でデバイス管理テーブル１６００を更新する（Ｓ１．１２）。

次に、親トークン取得に関する本実施形態のシーケンスを説明する。図７Ａは、画像形成装置３００のＷｅｂブラウザ９００を用いて親トークンを取得するシーケンスである。図７Ｂは、クライアント端末２２０のＷｅｂブラウザ１２００を用いて親トークンを取得するシーケンスである。本シーケンスは、ユーザーが画像形成装置３００を最初に利用する際に、画像形成装置３００のＷｅｂブラウザ９００又はクライアント端末２２０のＷｅｂブラウザ１２００を用いて一度だけ行われる操作に係る処理である。
最初に画像形成装置３００のＷｅｂブラウザ９００を用いて親トークンを取得するシーケンス等を、図７Ａ等を用いて説明する。
まずローカルログインアプリケーション１０００が提供する画像形成装置３００の入力画面を用いたログイン手段を用いてユーザーが画像形成装置３００にログインする（Ｓ２．１）。ここでユーザーＩＤがｕｓｅｒ００１のユーザーがログインしたとする。すると、ローカルログインアプリケーション１０００は、ｕｓｅｒ００１を含むログインコンテキストを生成する（Ｓ２．２）。

次に、Ｗｅｂブラウザ９００は、ユーザー操作等に基づいて、認可サーバー連携クライアント４００の認可連携を開始するためにデバイスブラウザ用認可ＵＲＬへアクセスする（Ｓ２．３）。ここでデバイスブラウザ用認可ＵＲＬへのアクセスを受け付けると、認可サーバー連携クライアントは、デバイスブラウザ用認可ＵＲＬをＷｅｂログインが不要なＵＲＬとして取り扱う。つまり、上述したように認可サーバー連携クライアント４００を使用する場合、Ｗｅｂログインアプリケーション１１００にログインする必要があった。しかし、Ｓ２．３の処理を実行することで、ユーザーは、一度、ローカルログインアプリケーション１０００にログインした後に、認可サーバー連携クライアント４００を使用するために再度ログインする必要がなくなり、操作性が向上する。
なお、認可サーバー連携クライアント４００は、図８Ａに示すような認可連携開始を確認する画面１８０１をＷｅｂブラウザ９００に対して応答するようにしてもよい。
認可サーバー連携クライアント４００は、認可連携の開始を受け付けたら、ログインアプリケーションを特定する（Ｓ２．４）。このことにより認可サーバー連携クライアント４００によってローカルログインと特定される。ログインアプリケーション特定の詳細は後述する。
次に、認可サーバー連携クライアント４００は、デバイス情報更新の要否判断を行い、デバイス情報更新が必要な場合には認可サーバー２００にデバイス情報更新要求を行う（Ｓ２．５）。デバイス情報更新要否判断の詳細は後述する。

認可サーバー連携クライアント４００は、Ｓ２．４で特定したローカルログインアプリケーション１０００に対して、Ｓ２．２で生成されたログインコンテキストを要求する（Ｓ２．６）。
ログインコンテキストの要求を受けたローカルログインアプリケーション１０００は、前記要求に対応して、ログインコンテキストを要求元の認可サーバー連携クライアント４００に送信する（Ｓ２．７）。
認可サーバー連携クライアント４００は、デバイス管理テーブル１６００のエンドポイントＵＲＬ１６０３に記載のＵＲＬに対して、ＯＡｕｔｈの認可リクエストをするようＷｅｂブラウザ９００にリダイレクト要求する（Ｓ２．８）。この認可リクエストには、デバイス管理テーブル１６００のクライアントＩＤ１６０１、リダイレクトＵＲＬ１６０７の情報が含まれる。認可リクエストに含まれるリダイレクトＵＲＬはデバイスブラウザ用リダイレクトＵＲＬであり、Ｓ２．３において受け付けたリクエストのＦＱＤＮと一致するＵＲＬである。また、ＯＡｕｔｈでは、認可を受けたい権限範囲を示すスコープを認可リクエストに含むようにしてもよい。本実施形態では、スコープとしてスコープＡがリクエストされたとして説明する。

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

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

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

認可サーバー２００は、これら全ての検証が正しい場合に、親トークンを生成して、親トークンの認可トークンＩＤを認可サーバー連携クライアント４００に応答する。この際、認可サーバー２００は、同時に発行したリフレッシュトークンＩＤも応答内容に含めて送信する（Ｓ２．１６）。認可サーバー２００は、親トークンとしては、認可トークンＩＤ１５０１に発行したトークンのＩＤ、トークン種別１５０２に親トークン、有効期限１５０３に有効期限を登録する。また、認可サーバー２００は、認可コードから引き継ぐ情報として、クライアントＩＤ１５０７、ユーザーＩＤ１５０８を登録する。また、認可サーバー２００は、親トークンをリフレッシュするためのリフレッシュトークンを発行し、リフレッシュトークンＩＤをリフレッシュトークンＩＤ１５０５に、リフレッシュ期限をリフレッシュ期限１５０６に登録する。リフレッシュに関する処理については後述する。

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

次に、クライアント端末２２０のＷｅｂブラウザ１２００を用いて親トークンを取得する処理等を、図７Ｂ等を用いて説明する。
まずＷｅｂログインアプリケーション１１００が提供する入力画面を用いたログイン手段を用いてユーザーがＷｅｂブラウザ１２００で画像形成装置３００にログインする（Ｓ３．１）。ここでユーザーＩＤがｕｓｅｒ００１のユーザーがログインしたとする。すると、ローカルログインアプリケーション１０００は、ｕｓｅｒ００１を含むログインコンテキストを生成する（Ｓ３．２）。
次に、Ｗｅｂブラウザ１２００は、ユーザー操作等に基づいて、認可サーバー連携クライアント４００の認可連携を開始するためのクライアント端末用ブラウザ用認可ＵＲＬへアクセスする（Ｓ３．３）。ここで認可サーバー連携クライアント４００は、図８Ａに示すような認可連携開始を確認する画面１８０１を応答するようにしてもよい。

認可サーバー連携クライアント４００は、認可連携の開始を受け付けたら、ログインアプリケーションを特定する（Ｓ３．４）。このことによって認可サーバー連携クライアント４００によってＷｅｂログインと特定される。ログインアプリケーション特定の詳細は後述する。
次に、認可サーバー連携クライアント４００は、デバイス情報更新要否を判断し、デバイス情報更新が必要な場合には認可サーバー２００にデバイス情報更新要求を行う（Ｓ３．５）。デバイス情報更新要否判断の詳細は後述する。
認可サーバー連携クライアント４００は、Ｓ３．４で特定したＷｅｂログインアプリケーション１１００に対して、Ｓ３．２で生成されたログインコンテキストを要求する（Ｓ３．６）。
ログインコンテキストの要求を受けたＷｅｂログインアプリケーション１１００は、前記要求に対応して、ログインコンテキストを要求元の認可サーバー連携クライアント４００に送信する（Ｓ３．７）。

認可サーバー連携クライアント４００は、デバイス管理テーブル１６００のエンドポイントＵＲＬ１６０３に記載のＵＲＬに対して、ＯＡｕｔｈの認可リクエストをするようＷｅｂブラウザ１２００にリダイレクト要求する（Ｓ３．８）。この認可リクエストには、デバイス管理テーブル１６００のクライアントＩＤ１６０１、リダイレクトＵＲＬ１６０７の情報が含まれる。認可リクエストに含まれるリダイレクトＵＲＬはクライアント端末用リダイレクトＵＲＬであり、Ｓ３．３において受け付けたリクエストのＦＱＤＮと一致するＵＲＬである。
Ｓ３．９〜Ｓ３．１６については前述のＳ２．９〜Ｓ２．１６における画像形成装置３００のＷｅｂブラウザ９００がクライアント端末２２０のＷｅｂブラウザ１２００になっているだけであるため説明の簡略化のため省略する。

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

図９は、認可サーバー連携クライアント４００が認可連携開始リクエストを受け付けた後、ログインアプリケーションを特定する処理とデバイス情報更新の要否を判断する処理との一例を示すフローチャートである。図９に示す処理は、図７ＡにおけるＳ２．４〜Ｓ２．７、図７ＢにおけるＳ３．４〜Ｓ３．７の詳細な処理である。
認可サーバー連携クライアント４００は、認可連携開始リクエストを受け付けると、まず画像形成装置３００のデバイス情報を取得し（Ｓ４．１）、クライアント名、クライアント説明を生成する（Ｓ４．２）。Ｓ４．１のデバイス情報の取得、Ｓ４．２のクライアント名、クライアント説明の生成については図６におけるＳ１．２、Ｓ１．３と同様のため説明を省略する。

次に認可サーバー連携クライアント４００は、認可連携開始リクエストの送信先ＩＰアドレスを取得する（Ｓ４．３）。ここで送信先ＩＰアドレスはＷｅｂブラウザで指定される宛先ＵＲＬのＦＱＤＮであり、本実施形態では、ループバックアドレス又は画像形成装置のＩＰアドレスが指定される可能性がある。
また認可サーバー連携クライアント４００は、認可連携開始リクエストの受付ＵＲＬも取得する（Ｓ４．４）。認可サーバー連携クライアント４００の認可開始受付ＵＲＬはデバイスブラウザ用認可ＵＲＬ又はクライアント端末ブラウザ用認可ＵＲＬの二つがあり、Ｗｅｂブラウザで指定されたＵＲＬが取得される。

認可サーバー連携クライアント４００は、Ｓ４．４で取得した受付ＵＲＬがデバイスブラウザ用認可ＵＲＬか否かを判定する（Ｓ４．５）。認可サーバー連携クライアント４００は、Ｓ４．４で取得した受付ＵＲＬがデバイスブラウザ用認可ＵＲＬであった場合は、Ｓ４．６に進み、デバイスブラウザ用認可ＵＲＬでなかった場合は、Ｓ４．１２に進む。
Ｓ４．６において、認可サーバー連携クライアント４００は、Ｓ４．３で取得した送信先ＩＰアドレスがループバックＩＰｖ４アドレス又はループバックＩＰｖ６アドレスか否かを判断する。認可サーバー連携クライアント４００は、Ｓ４．３で取得した送信先ＩＰアドレスがループバックＩＰｖ４アドレス又はループバックＩＰｖ６アドレスであった場合、Ｓ４．８に進む。一方、認可サーバー連携クライアント４００は、Ｓ４．３で取得した送信先ＩＰアドレスがループバックＩＰｖ４アドレスでもループバックＩＰｖ６アドレスでもなかった場合、Ｓ４．７に進む。
送信先ＩＰアドレスは、送信先アドレスの一例である。また、ループバックＩＰｖ４アドレスやループバックＩＰｖ６アドレスは、内部通信アドレスの一例である。
Ｓ４．７において、認可サーバー連携クライアント４００は、Ｗｅｂブラウザに対してエラー画面を応答する。

一方、Ｓ４．８〜Ｓ４．９において、認可サーバー連携クライアント４００は、クライアント情報の変更の有無を判断する。
認可サーバー連携クライアント４００は、認可サーバー連携クライアント４００が保持するデバイス管理テーブル１６００のクライアント名１６０５、クライアント説明１６０６とＳ４．２で生成したクライアント名、クライアント説明とを比較する。そして、認可サーバー連携クライアント４００は、変更があるか否かを判断する（Ｓ４．８）。認可サーバー連携クライアント４００は、変更があった場合は、Ｓ４．９に進み、変更がなかった場合、Ｓ４．１１に進む。
Ｓ４．９において、認可サーバー連携クライアント４００は、認可サーバー２００にクライアント更新要求を行う。ここで、クライアント更新要求は、エンドポイントＵＲＬ１６０３に対して行われる。また、クライアント更新要求には、クライアントＩＤ１６０１、クライアントシークレット１６０２、Ｓ４．２で生成されたクライアント名、クライアント説明、リダイレクトＵＲＬ１６０７、Ｓ４．１で取得されたシリアル番号が含まれる。

認可サーバー連携クライアント４００は、Ｓ４．２で生成したクライアント名、クライアント説明でデバイス管理テーブル１６００を更新する（Ｓ４．１０）。
認可サーバー連携クライアント４００は、ローカルログインアプリケーション１０００からログインコンテキストを取得する（Ｓ４．１１）。ここでＳ４．１１の処理は、図７ＡにおけるＳ２．６、Ｓ２．７に対応している。

一方、Ｓ４．１２において、認可サーバー連携クライアント４００は、Ｓ４．３で取得した送信先ＩＰアドレスをＦＱＤＮとしてクライアント端末用リダイレクトＵＲＬを作成する。
そして認可サーバー連携クライアント４００は、Ｓ４．１２で作成したクライアント端末用リダイレクトＵＲＬがリダイレクトＵＲＬ１６０７に含まれるか否かを確認する（Ｓ４．１３）。認可サーバー連携クライアント４００は、Ｓ４．１２で作成したクライアント端末用リダイレクトＵＲＬがリダイレクトＵＲＬ１６０７に含まれる場合、Ｓ４．１７に進み、リダイレクトＵＲＬ１６０７に含まれない場合、Ｓ４．１４に進む。
Ｓ４．１４において、認可サーバー連携クライアント４００は、リダイレクトＵＲＬ１６０７にＳ４．１２で作成したクライアント端末用リダイレクトＵＲＬを加える。
一方、Ｓ４．１７において、認可サーバー連携クライアント４００は、デバイス管理テーブル１６００のクライアント名１６０５、クライアント説明１６０６とＳ４．２で生成したクライアント名、クライアント説明とを比較して更新（又は変更）がないか確認する。認可サーバー連携クライアント４００は、更新があると判定すると、Ｓ４．１５に進み、更新がないと判定すると、Ｓ４．1８に進む。

Ｓ４．１５において、認可サーバー連携クライアント４００は、認可サーバー２００にクライアント更新要求を行う。クライアント更新要求は、エンドポイントＵＲＬ１６０３に対して行われる。Ｓ４．１４からＳ４．１５に遷移した場合、クライアント更新要求には、以下の情報が含まれる。つまり、クライアントＩＤ１６０１、クライアントシークレット１６０２、Ｓ４．２で生成されたクライアント名、クライアント説明、Ｓ４．１４で生成されたリダイレクトＵＲＬ、Ｓ４．１で取得されたシリアル番号が含まれる。一方、Ｓ４．１７からＳ４．１５に遷移した場合、クライアント更新要求には、以下の情報が含まれる。つまり、クライアントＩＤ１６０１、クライアントシークレット１６０２、Ｓ４．２で生成されたクライアント名、クライアント説明、Ｓ４．１２で生成されたリダイレクトＵＲＬ、Ｓ４．１で取得されたシリアル番号が含まれる。なお、Ｓ４．１７からＳ４．１５に遷移した場合、Ｓ４．１２で生成されたリダイレクトＵＲＬは、デバイス管理テーブル１６００のリダイレクトＵＲＬ１６０７に含まれるリダイレクトＵＲＬであるため、クライアント更新要求に含めないようにしてもよい。

次に、Ｓ４．１６において、認可サーバー連携クライアント４００は、デバイス管理テーブルの更新の処理を行う。尚、Ｓ４．１４、Ｓ４．１５を経てＳ４．１６に遷移してきた場合、認可サーバー連携クライアント４００は、Ｓ４．２に生成したクライアント名、クライアント説明、Ｓ４．１４で生成したリダイレクトＵＲＬでデバイス管理テーブル１６００を更新する。一方、Ｓ４．１７、Ｓ４．１５を経てＳ４．１６に遷移してきた場合、認可サーバー連携クライアント４００は、Ｓ４．２に生成したクライアント名、クライアント説明、Ｓ４．１２で生成したリダイレクトＵＲＬでデバイス管理テーブル１６００を更新する。上述したように、Ｓ４．１７、Ｓ４．１５を経てＳ４．１６に遷移してきた場合、認可サーバー連携クライアント４００は、Ｓ４．２に生成したクライアント名、クライアント説明、でデバイス管理テーブル１６００を更新するようにしてもよい。
続いて、認可サーバー連携クライアント４００は、Ｗｅｂログインアプリケーション１１００からログインコンテキストを取得する（Ｓ４．１８）。ここでＳ４．１８の処理は、図７ＢにおけるＳ３．６、Ｓ３．７に対応している。
つまり、認可サーバー連携クライアント４００は、Ｓ４．５の処理結果を用いて受付ＵＲＬがデバイスブラウザ用のＵＲＬであると判定した場合、ログインアプリケーションをローカルログインアプリケーションと特定する。一方、認可サーバー連携クライアント４００は、受付ＵＲＬがデバイスブラウザ用のＵＲＬではないと判定した場合、ログインアプリケーションをＷｅｂログインアプリケーションと特定する。

クライアント情報の更新処理において、認可サーバー連携クライアント４００は、クライアント情報に変更がある場合にのみ認可サーバー２００にクライアント更新要求を行うことで認可サーバー２００の負荷を下げることができる。
また、認可サーバー連携クライアント４００は、アドレス情報を固定アドレス、可変アドレス、動的アドレスに分類している。本実施形態において固定アドレスは、ループバックＩＰｖ４アドレスとループバックＩＰｖ６アドレスとであり変更がないアドレスである。また、本実施形態において可変アドレスは、ＩＰｖ４アドレス、手動ＩＰｖ６アドレス、ステートフルＩＰｖ６アドレス、ホスト名でありユーザーが変更可能なアドレスである。また、本実施形態において動的アドレスは、リンクローカルＩＰｖ６アドレス、ステートレスＩＰｖ６アドレスであり自動で動的に割り当てられるため起動時に変更される可能性が高いアドレスである。
認可サーバー連携クライアント４００は、起動時のクライアント情報の登録におけるクライアント端末用リダイレクトＵＲＬに可変アドレスを利用し、デバイスブラウザ用リダイレクトＵＲＬに固定アドレスを利用している。そして、認可サーバー連携クライアント４００は、可変アドレスに変更があった場合（つまり、Ｓ４．４で取得した送信先ＩＰアドレスがデバイス管理テーブルのリダイレクトＵＲＬに含まれない場合）にのみクライアント情報更新を行う。その結果、クライアント情報更新の頻度を下げ認可サーバー２００の負荷を下げることができる。

次に、動的アドレスは変更される可能性が高く、変更の度に認可サーバー連携クライアント４００が認可サーバー２００にクライアント情報の変更を行うと認可サーバー２００の負荷が高くなってしまう。例えば朝の始業時に社内の画像形成装置３００を起動するという運用を行った場合、認可サーバー２００に対して全ての画像形成装置３００から一斉にクライアント情報の変更要求が行われ認可サーバー２００の負荷が集中してしまう。そこで認可サーバー連携クライアント４００は、認可連携開始リクエストに動的アドレスが使われた場合にのみ動的アドレスからリダイレクトＵＲＬを生成し、クライアント情報の変更を行うことで頻繁にクライアント情報の変更が行われることを防ぐことができる。認可サーバー連携クライアント４００は、固定アドレスや可変アドレスから生成したリダイレクトＵＲＬも認可連携開始リクエストの度にクライアント情報を変更するようにしてもよい。しかしながら、固定アドレスや可変アドレスは頻繁に利用されるためクライアント情報の変更頻度も増えてしまう。一方、動的アドレスは固定アドレスや可変アドレスに比べて使用頻度が低い。そのため、認可サーバー連携クライアント４００は、起動時に最初から登録するのではなく、必要になったときのみ登録することで、クライアント情報の変更のリクエストが減り、認可サーバー２００の負荷を抑えることができる。つまり、認可サーバー連携クライアント４００は、リダイレクトＵＲＬの種類に応じて、認可サーバー２００に登録するタイミングを変更することによって、認可サーバー２００の負荷を抑えることができる。

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

次に、ユーザーは画像形成装置３００を操作してリソースサービス連携アプリケーション５００のアプリケーション画面にアクセスする（Ｓ５．３）。このアプリケーション画面は例えば、リソースサービス連携アプリケーション５００が印刷アプリケーションであった場合は印刷する文書を選択する画面であり、帳票アプリケーションであった場合は、作成する帳票を選択する画面である。ここでアプリケーション画面にアクセスするとは、以下のことを指す。即ち、例えば、画像形成装置３００が有する操作パネル上にアプリケーション管理フレームワーク８００にて開始状態の各アプリケーションが選択可能に表示されており、ユーザーがその中から該当するアプリケーションを選択することを指す。
対応するアプリケーション画面にアクセスされたリソースサービス連携アプリケーション５００は、ローカルログインアプリケーション１０００からログインコンテキストを取得する（Ｓ５．４）。
そして、リソースサービス連携アプリケーション５００は、アプリケーション管理フレームワーク８００に登録されている認可サーバー連携クライアント４００のトークン取得インターフェースに対してトークン取得要求を行う（Ｓ５．５）。この際、リソースサービス連携アプリケーション５００は、取得したログインコンテキストをトークン取得要求に含める。尚、ここで、リソースサービス連携アプリケーション５００は、トークンに必要なスコープを要求するよう構成することもできる。本実施形態では、スコープＡが引き続き要求されたとして説明する。

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

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

リフレッシュされた親トークンを取得した認可サーバー連携クライアント４００は、受け付けた認可トークンＩＤ、リフレッシュトークンＩＤにて、親トークン管理テーブル１７００の情報を上書きし、再登録する（Ｓ５．９）。
認可サーバー連携クライアント４００は、親トークンの認可トークンＩＤ、デバイス管理テーブル１６００のクライアントＩＤ、クライアントシークレット、トークン取得要求で受けつけたスコープを用いて、認可サーバー２００に子トークン取得要求を行う（Ｓ５．１０）。
子トークン取得要求を受けた認可サーバー２００は、以下の処理を実行する。まず、認可サーバー２００は、子トークン取得要求に含まれるクライアントＩＤとクライアントシークレットとの組がユーザー管理テーブル１３００のユーザーＩＤ１３０１とパスワード１３０２の組と合っているかを検証する。認可サーバー２００は、正しい場合は、子トークン取得要求に含まれる認可トークンＩＤが認可トークン管理テーブル１５００に登録されており、有効期限内か確認する。
更に、認可サーバー２００は、子トークン取得要求に含まれるクライアントＩＤがクライアントＩＤ１５０７と一致するか検証し、全ての検証が正しい場合は、子トークンを生成する（Ｓ５．１１）。

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

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

次に、リソースサーバー２１０は、認可サーバー２００に対して、子トークンの認可トークンＩＤのトークン情報取得を要求する（Ｓ５．１７）。
トークン情報取得要求を受けた認可サーバー２００は、認可トークン管理テーブル１５００から受け付けた認可トークンＩＤにて特定される情報を取得し、取得した情報をリソースサーバー２１０に応答する（Ｓ５．１８）。この応答には、例えば、スコープ１５０４、クライアントＩＤ１５０７、ユーザーＩＤ１５０８の情報が含まれる。更には、認可サーバー２００は、クライアントＩＤ１５０７にて特定されるクライアント管理テーブル１４００に登録されているシリアル番号１４０５を含むよう構成することもできる。
トークン情報を取得したリソースサーバー２１０は、取得した情報を基に要求を受け付けたリソースに対するアクセスを許可するか拒否するかを判断する。リソースサーバー２１０は、シリアル番号やクライアントＩＤを基に画像形成装置３００を識別し、ユーザーにより許可された画像形成装置３００のみアクセスを許可する。また、同様に、リソースサーバー２１０は、トークン情報から取得できるスコープやユーザーＩＤを基にアクセスの可否を判断するようにしてみよい。
判断の結果、アクセス許可と判断した場合は、リソースサーバー２１０は、リソースサービス連携アプリケーション５００に対して、リソースを応答する（Ｓ５．１９）。ここで、リソースは例えば、リソースサーバー２１０が印刷サービスであった場合は印刷可能な文書のリストであり、帳票サービスであった場合は、作成可能な帳票のリストである。

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

本実施形態において、画像形成装置３００は、デバイスブラウザ用認可ＵＲＬとクライアント端末用認可ＵＲＬとを設け、デバイスブラウザ用認可ＵＲＬはＷｅｂログインなしでアクセス可能だが、内部通信のみにアクセス制限している。そして、画像形成装置３００は、デバイスブラウザ用認可ＵＲＬからのアクセスの場合にはローカルログインユーザーに認可トークンを紐付け、クライアント端末用認可ＵＲＬからのアクセスの場合にはＷｅｂログインユーザーに認可トークンを紐づける。デバイスブラウザを用いた場合であってもローカルログイン一度のみのログインで認可することができ、更にＷｅｂログインなしのデバイスブラウザ用認可ＵＲＬは内部通信のみしかアクセスできない。そのためセキュアである。

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

以上、上述した各実施形態によれば、簡便にログイン可能とすると共に不正なアクセスを防止可能とすることができる。

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

Claims (13)

1. Ｗｅｂアクセス認証なしの認可用の第１ＵＲＬと、Ｗｅｂアクセス認証ありの認可用の第２ＵＲＬと、を保持する保持手段と、
   前記第１ＵＲＬでリクエストを受け付けた場合、受け付けたリクエストの送信先アドレスが内部通信アドレスか否かを判定する判定手段と、
   前記判定手段により前記受け付けたリクエストの送信先アドレスが内部通信アドレスであると判定された場合、接続を許可し、前記判定手段により前記受け付けたリクエストの送信先アドレスが内部通信アドレスでないと判定された場合、接続を拒否する制御手段と、
   を有する画像形成装置。
2. 前記制御手段は、前記判定手段により前記受け付けたリクエストの送信先アドレスが内部通信アドレスであると判定された場合、接続を許可し、認可トークンと、前記第１ＵＲＬの画面を介してログインしたユーザーのユーザー情報と、を紐づけてトークン管理データに登録する請求項１記載の画像形成装置。
3. 前記制御手段は、前記第２ＵＲＬでリクエストを受け付けた場合、接続を許可する請求項１又は２記載の画像形成装置。
4. 前記制御手段は、前記第２ＵＲＬでリクエストを受け付けた場合、接続を許可し、認可トークンと、前記第２ＵＲＬの画面を介してログインしたユーザーのユーザー情報と、を紐づけてトークン管理データに登録する請求項３記載の画像形成装置。
5. Ｗｅｂアクセス認証なしの認可用の第１ＵＲＬと、Ｗｅｂアクセス認証ありの認可用の第２ＵＲＬと、を認可サーバーに登録する登録手段を更に有し、
   前記登録手段は、ＵＲＬの種類に応じて、前記認可サーバーに登録するタイミングを変更する請求項１乃至４何れか１項記載の画像形成装置。
6. 前記登録手段は、
   前記リクエストの送信先アドレスが可変アドレスであり、かつ、前記可変アドレスに基づくＵＲＬが登録されていない場合、前記登録されていない前記可変アドレスに基づくＵＲＬを前記第２ＵＲＬとして前記認可サーバーに登録し、
   前記リクエストの送信先アドレスが動的アドレスである場合、前記動的アドレスを取得することに応じて前記動的アドレスに基づくＵＲＬを前記第２ＵＲＬとして前記認可サーバーに登録する請求項５記載の画像形成装置。
7. 画像形成装置が実行する情報処理方法であって、
   Ｗｅｂアクセス認証なしの認可用の第１ＵＲＬと、Ｗｅｂアクセス認証ありの認可用の第２ＵＲＬと、を保持する保持ステップと、
   前記第１ＵＲＬでリクエストを受け付けた場合、受け付けたリクエストの送信先アドレスが内部通信アドレスか否かを判定する判定ステップと、
   前記判定ステップにより前記受け付けたリクエストの送信先アドレスが内部通信アドレスであると判定された場合、接続を許可し、前記判定ステップにより前記受け付けたリクエストの送信先アドレスが内部通信アドレスでないと判定された場合、接続を拒否する制御ステップと、
   を含む情報処理方法。
8. コンピュータに、
   Ｗｅｂアクセス認証なしの認可用の第１ＵＲＬと、Ｗｅｂアクセス認証ありの認可用の第２ＵＲＬと、を保持する保持ステップと、
   前記第１ＵＲＬでリクエストを受け付けた場合、受け付けたリクエストの送信先アドレスが内部通信アドレスか否かを判定する判定ステップと、
   前記判定ステップにより前記受け付けたリクエストの送信先アドレスが内部通信アドレスであると判定された場合、接続を許可し、前記判定ステップにより前記受け付けたリクエストの送信先アドレスが内部通信アドレスでないと判定された場合、接続を拒否する制御ステップと、
   を実行させるためのプログラム。
9. 前記制御ステップでは、前記判定ステップにより前記受け付けたリクエストの送信先アドレスが内部通信アドレスであると判定された場合、接続を許可し、認可トークンと、前記第１ＵＲＬの画面を介してログインしたユーザーのユーザー情報と、を紐づけてトークン管理データに登録する請求項８記載のプログラム。
10. 前記制御ステップでは、前記第２ＵＲＬでリクエストを受け付けた場合、接続を許可する請求項８又は９記載のプログラム。
11. 前記制御ステップでは、前記第２ＵＲＬでリクエストを受け付けた場合、接続を許可し、認可トークンと、前記第２ＵＲＬの画面を介してログインしたユーザーのユーザー情報と、を紐づけてトークン管理データに登録する請求項１０記載のプログラム。
12. Ｗｅｂアクセス認証なしの認可用の第１ＵＲＬと、Ｗｅｂアクセス認証ありの認可用の第２ＵＲＬと、を認可サーバーに登録する登録ステップを更に有し、
    前記登録ステップでは、ＵＲＬの種類に応じて、前記認可サーバーに登録するタイミングを変更する請求項８乃至１１何れか１項記載のプログラム。
13. 前記登録ステップでは、
    前記リクエストの送信先アドレスが可変アドレスであり、かつ、前記可変アドレスに基づくＵＲＬが登録されていない場合、前記登録されていない前記可変アドレスに基づくＵＲＬを前記第２ＵＲＬとして前記認可サーバーに登録し、
    前記リクエストの送信先アドレスが動的アドレスである場合、前記動的アドレスを取得することに応じて前記動的アドレスに基づくＵＲＬを前記第２ＵＲＬとして前記認可サーバーに登録する請求項１２記載のプログラム。

Images