特許 6446119 サーバおよびトークン発行方法

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

(12)【公報種別】特許公報(B2)

(11)【特許番号】6446119

(24)【登録日】2018年12月7日

(45)【発行日】2018年12月26日

(54)【発明の名称】サーバおよびトークン発行方法

(51)【国際特許分類】

   G06F 21/62 20130101AFI20181217BHJP

   G06F 21/33 20130101ALI20181217BHJP

   G06Q 20/40 20120101ALI20181217BHJP

【ＦＩ】

   G06F21/62

   G06F21/33

   G06Q20/40

【請求項の数】2

【全頁数】23

(21)【出願番号】特願2017-247331(P2017-247331)

(22)【出願日】2017年12月25日

(62)【分割の表示】特願2016-162143(P2016-162143)の分割

【原出願日】2016年8月22日

(65)【公開番号】特開2018-49667(P2018-49667A)

(43)【公開日】2018年3月29日

【審査請求日】2017年12月25日

(73)【特許権者】

【識別番号】000102728

【氏名又は名称】株式会社エヌ・ティ・ティ・データ

(74)【代理人】

【識別番号】110000752

【氏名又は名称】特許業務法人朝日特許事務所

(72)【発明者】

【氏名】廣川 昇平

【審査官】 平井 誠

(56)【参考文献】

【文献】 特開２０１５−００５２２２（ＪＰ，Ａ）

【文献】 特開２０１６−０３０３７７（ＪＰ，Ａ）

【文献】 特開２０１６−０７１５７０（ＪＰ，Ａ）

【文献】 米国特許出願公開第２０１４／０２３６７９２（ＵＳ，Ａ１）

【文献】 国際公開第２０１６／０９２６３０（ＷＯ，Ａ１）

【文献】 特開２００２−２０７７３９（ＪＰ，Ａ）

【文献】 特開２０１４−１０６６５２（ＪＰ，Ａ）

【文献】 遠藤 圭介 高橋 寛，ＦｉｎＴｅｃｈの鍵を握る２つの技術 金融分野のＡＰＩエコノミー −オープンＡＰＩが生み出す革新的なサービス，ＩＴソリューションフロンティア，日本，株式会社野村総合研究所，２０１６年 ７月２０日，Ｖｏｌ．３３ Ｎｏ．０８，06〜09

(58)【調査した分野】（Int.Cl.，ＤＢ名）

Ｇ０６Ｆ ２１／３０−４６，６０−６２

(57)【特許請求の範囲】

【請求項1】

ユーザのリソースに対してアクセスする権限が当該ユーザからクライアントに対して付与されたことを証明するトークンまたは当該トークンを取得するために使用されるトークンの要求を受け付けるトークン要求受付部と、
前記権限が付与された前記クライアントにより行われるまたは行われた前記リソースに対するアクセスに関する１以上の情報に基づいて、前記要求されたトークンの有効期間を設定する有効期間設定部と、
前記権限が付与された前記クライアントにより行われる前記リソースに対するアクセスの内容に基づいて、前記要求されたトークンの優先度を設定する優先度設定部と、
前記有効期間と前記優先度とが設定されたトークンを前記クライアントに対して発行するトークン発行部と
を備え、
前記優先度は、前記権限が付与された前記クライアントにより行われる前記リソースに対する他のアクセスを許可するか否かを判断するために参照される情報であることを特徴とするサーバ。

【請求項2】

コンピュータに実行されるトークン発行方法であって、
ユーザのリソースに対してアクセスする権限が当該ユーザからクライアントに対して付与されたことを証明するトークンまたは当該トークンを取得するために使用されるトークンの要求を受け付けるステップと、
前記権限が付与された前記クライアントにより行われるまたは行われた前記リソースに対するアクセスに関する１以上の情報に基づいて、前記要求されたトークンの有効期間を設定するステップと、
前記権限が付与された前記クライアントにより行われる前記リソースに対するアクセスの内容に基づいて、前記要求されたトークンの優先度を設定するステップと、
前記有効期間と前記優先度とが設定されたトークンを前記クライアントに対して発行するステップと
を備え、
前記優先度は、前記権限が付与された前記クライアントにより行われる前記リソースに対する他のアクセスを許可するか否かを判断するために参照される情報であることを特徴とするトークン発行方法。

【発明の詳細な説明】

【技術分野】

【0001】

本発明は、ユーザのリソースにアクセスする権限を当該ユーザから第三者に付与する技術に関する。

【背景技術】

【0002】

従来、残高照会や振込といった銀行サービスをインターネットを通じて利用者に提供するインターネットバンキングという仕組みが存在する。サービス開始当初は、ＩＤとパスワードを保持する利用者本人が当該システムを利用するのが原則であったが、近年、利用者の許可を得ることを条件として、第三者が利用者の口座情報にアクセスして、利用者のために家計簿を作成する等のサービスが提供されている。このようなサービスを提供する第三者は、利用者の口座情報にアクセスする権限が自身に付与されたことを証明するトークンを、認可サーバから発行してもらう。そして、発行されたトークンを、口座情報を管理するリソースサーバに提示することで、当該口座情報へのアクセスを許可してもらう。このような権限付与の仕組みは、例えばOAuth 2.0という標準プロトコルにより実現される（特許文献１参照）。

【先行技術文献】

【特許文献】

【0003】

【特許文献1】特開２０１５−１２５５１０号公報

【発明の概要】

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

【0004】

しかし、従来の権限付与の仕組みでは、トークンの有効期間が、アクセスの方法や範囲にかかわらず設定されており、必要以上の時間、権限を第三者に付与することにより、利用者の口座情報を危険にさらす可能性があった。

【0005】

本発明は、このような事情に鑑みてなされたものであり、権限が付与された第三者により行われるまたは行われたリソースに対するアクセスに関する情報に基づいてトークンの有効期間を設定することを可能にすることを目的とする。

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

【0006】

上記の課題を解決するため、本発明は、ユーザの口座情報に対してアクセスする権限が当該ユーザからクライアントに対して付与されたことを証明するトークンまたは当該トークンを取得するために使用されるトークンの要求を受け付けるトークン要求受付部と、前記権限が付与された前記クライアントにより行われるまたは行われた前記口座情報に対するアクセスに関する１以上の情報に基づいて、前記要求されたトークンの有効期間を設定する有効期間設定部と、前記有効期間が設定されたトークンを前記クライアントに対して発行するトークン発行部とを備えるサーバを提供する。

【0007】

また、本発明は、コンピュータに実行されるトークン発行方法であって、ユーザの口座情報に対してアクセスする権限が当該ユーザからクライアントに対して付与されたことを証明するトークンまたは当該トークンを取得するために使用されるトークンの要求を受け付けるステップと、前記権限が付与された前記クライアントにより行われるまたは行われた前記口座情報に対するアクセスに関する１以上の情報に基づいて、前記要求されたトークンの有効期間を設定するステップと、前記有効期間が設定されたトークンを前記クライアントに対して発行するステップとを備えるトークン発行方法を提供する。

【0008】

また、本発明は、ユーザのリソースに対してアクセスする権限が当該ユーザからクライアントに対して付与されたことを証明するトークンまたは当該トークンを取得するために使用されるトークンの要求を受け付けるトークン要求受付部と、前記権限が付与された前記クライアントにより行われるまたは行われた前記リソースに対するアクセスに関する複数の情報の各々に基づいて複数の有効期間を特定し、当該特定した複数の有効期間のうち、最短の有効期間を、前記要求されたトークンの有効期間として設定する有効期間設定部と、前記有効期間が設定されたトークンを前記クライアントに対して発行するトークン発行部とを備えるサーバを提供する。

【0009】

また、本発明は、コンピュータに実行されるトークン発行方法であって、ユーザのリソースに対してアクセスする権限が当該ユーザからクライアントに対して付与されたことを証明するトークンまたは当該トークンを取得するために使用されるトークンの要求を受け付けるステップと、前記権限が付与された前記クライアントにより行われるまたは行われた前記リソースに対するアクセスに関する複数の情報の各々に基づいて複数の有効期間を特定し、当該特定した複数の有効期間のうち、最短の有効期間を、前記要求されたトークンの有効期間として設定するステップと、前記有効期間が設定されたトークンを前記クライアントに対して発行するステップとを備えるトークン発行方法を提供する。

【0010】

また、本発明は、ユーザのリソースに対してアクセスする権限が当該ユーザからクライアントに対して付与されたことを証明するトークンまたは当該トークンを取得するために使用されるトークンの要求を受け付けるトークン要求受付部と、前記権限が付与された前記クライアントにより行われるまたは行われた前記リソースに対するアクセスに関する１以上の情報に基づいて、前記要求されたトークンの有効期間を設定する有効期間設定部と、前記権限が付与された前記クライアントにより行われる前記リソースに対するアクセスの内容に基づいて、前記要求されたトークンの優先度を設定する優先度設定部と、前記有効期間と前記優先度とが設定されたトークンを前記クライアントに対して発行するトークン発行部とを備え、前記優先度は、前記権限が付与された前記クライアントにより行われる前記リソースに対する他のアクセスを許可するか否かを判断するために参照される情報であることを特徴とするサーバを提供する。

【0011】

また、本発明は、コンピュータに実行されるトークン発行方法であって、ユーザのリソースに対してアクセスする権限が当該ユーザからクライアントに対して付与されたことを証明するトークンまたは当該トークンを取得するために使用されるトークンの要求を受け付けるステップと、前記権限が付与された前記クライアントにより行われるまたは行われた前記リソースに対するアクセスに関する１以上の情報に基づいて、前記要求されたトークンの有効期間を設定するステップと、前記権限が付与された前記クライアントにより行われる前記リソースに対するアクセスの内容に基づいて、前記要求されたトークンの優先度を設定するステップと、前記有効期間と前記優先度とが設定されたトークンを前記クライアントに対して発行するステップとを備え、前記優先度は、前記権限が付与された前記クライアントにより行われる前記リソースに対する他のアクセスを許可するか否かを判断するために参照される情報であることを特徴とするトークン発行方法を提供する。

【0012】

また、本発明は、ユーザのリソースに対してアクセスする権限が当該ユーザからクライアントに対して付与されたことを証明するトークンを取得するために使用されるトークンの要求を受け付けるトークン要求受付部と、前記権限が付与された前記クライアントにより行われるまたは行われた前記リソースに対するアクセスに関する１以上の情報に基づいて、前記要求されたトークンの有効期間を設定する有効期間設定部と、前記有効期間が設定されたトークンを前記クライアントに対して発行するトークン発行部とを備えるサーバを提供する。

【0013】

また、本発明は、コンピュータに実行されるトークン発行方法であって、ユーザのリソースに対してアクセスする権限が当該ユーザからクライアントに対して付与されたことを証明するトークンを取得するために使用されるトークンの要求を受け付けるステップと、前記権限が付与された前記クライアントにより行われるまたは行われた前記リソースに対するアクセスに関する１以上の情報に基づいて、前記要求されたトークンの有効期間を設定するステップと、前記有効期間が設定されたトークンを前記クライアントに対して発行するステップとを備えるトークン発行方法を提供する。

【発明の効果】

【0014】

本発明によれば、権限が付与された第三者により行われるまたは行われたリソースに対するアクセスに関する情報に基づいてトークンの有効期間を設定することができる。

【図面の簡単な説明】

【0015】

【図1】権限付与システム１００の構成の一例を示す図である。

【図2】口座情報管理テーブル２１と、アクセストークン管理テーブル２２と、リフレッシュトークン管理テーブル２３の一例を示す図である。

【図3】ＩＢサーバ４の構成の一例を示す図である。

【図4】ユーザ管理テーブル４０９の一例である。

【図5】クライアント管理テーブル４１０の一例である。

【図6】認可コード管理テーブル４１２と、アクセストークン管理テーブル４１３と、リフレッシュトークン管理テーブル４１４の一例を示す図である。

【図7】有効期間テーブル４１５の一例を示す図である。

【図8】処理履歴管理テーブル４１６の一例を示す図である。

【図9】権限付与処理の一例を示すシーケンス図である。

【図10】アクセストークン発行処理の一例を示すフロー図である。

【図11】アクセス処理の一例を示すシーケンス図である。

【図12】アクセストークン再発行処理の一例を示すシーケンス図である。

【図13】優先度テーブルの一例を示す図である。

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

【0016】

１．実施形態
１−１．権限付与システム１００の構成
図１は、本発明の一実施形態に係る権限付与システム１００の構成の一例を示す図である。この権限付与システム１００は、１以上のユーザ装置１と、１以上のクライアント装置２と、１以上の銀行サーバ３と、インターネットバンキング機能提供サーバ（以下、「ＩＢサーバ」）４とを有する。ユーザ装置１とクライアント装置２とＩＢサーバ４とは、インターネット等の通信回線５により相互接続される。銀行サーバ３とＩＢサーバ４とは、専用線等の通信回線６により相互接続される。

【0017】

１−２．ユーザ装置１の構成
ユーザ装置１は、クライアント装置２が提供するサービスと、ＩＢサーバ４が提供するサービスのユーザが使用するコンピュータである。例えば、スマートフォンやタブレット端末等の携帯型のコンピュータや、据え置き型のコンピュータである。ユーザ装置１は、具体的には、ＣＰＵ等の演算処理装置と、フラッシュメモリ等のメモリと、タッチセンサ等の入力装置と、液晶ディスプレイ等の表示装置と、データ通信カード等の通信モジュール等を備える。ユーザ装置１では、演算処理装置が、メモリに記憶されるプログラムを実行することで、ユーザエージェント１０の機能が実現される。ユーザエージェント１０は、具体的にはウェブブラウザである。

【0018】

ユーザ装置１のユーザは、銀行サーバ３またはＩＢサーバ４に記憶される自身のリソースにアクセスする権限を有している。また、このユーザは、当該リソースにアクセスする権限を、クライアント装置２上で機能するクライアント２０に付与する権限を有している。

【0019】

１−３．クライアント装置２の構成
クライアント装置２は、銀行サーバ３またはＩＢサーバ４に記憶される、ユーザ装置１のユーザのリソースにアクセスして、当該リソースに基づいてユーザにサービスを提供するサービス事業者が使用するコンピュータである。例えば、サーバである。クライアント装置２は、具体的には、ＣＰＵ等の演算処理装置と、ＨＤＤ等の記憶装置と、データ通信カード等の通信モジュール等を備える。クライアント装置２では、演算処理装置が、記憶装置に記憶されるプログラムを実行することで、クライアント２０の機能が実現される。クライアント２０は、具体的には家計簿アプリケーションである。より具体的には、銀行サーバ３またはＩＢサーバ４に記憶される、ユーザ装置１のユーザの口座情報にアクセスして、当該口座情報に基づいてユーザのために家計簿を自動で作成するアプリケーションである。クライアント２０は、家計簿を自動で作成するにあたり、ユーザの口座情報にアクセスする権限の付与を当該ユーザから受ける。

【0020】

クライアント２０の記憶装置には、口座情報管理テーブル２１と、アクセストークン管理テーブル２２と、リフレッシュトークン管理テーブル２３とが記憶される。

【0021】

図２（ａ）は、口座情報管理テーブル２１の一例を示す図である。口座情報管理テーブル２１は、ユーザ装置１のユーザの口座ごとに作成され、ＩＢサーバ４から取得されたユーザの口座情報が登録される。口座情報管理テーブル２１の各レコードは、日付と、入金金額と、出金金額と、残高と、摘要の各フィールドにより構成される。

【0022】

図２（ｂ）は、アクセストークン管理テーブル２２の一例を示す図である。アクセストークン管理テーブル２２は、ＩＢサーバ４によりクライアント２０に対して発行されるアクセストークンを管理するためのテーブルである。ここで、アクセストークンとは、ユーザ装置１のユーザの口座情報にアクセスする権限が当該ユーザからクライアント２０に付与されたことを証明する認証情報である。具体的には、ランダムな文字列である。アクセストークン管理テーブル２２の各レコードは、アクセストークンと、アクセストークンの有効期限と、アクセストークンのスコープの各フィールドにより構成される。ここで、アクセストークンのスコープは、当該アクセストークンにより権限が付与されていることが証明されるアクセスの範囲を示し、アクセスの種類と、ユーザ装置１のユーザを識別するユーザＩＤ（銀行ごとに異なる）と、アクセスの処理方式と、照会期間とにより構成される。ここで、アクセスの処理方式のうち、オフライン方式は、ＩＢサーバ４に記憶されるリソースにアクセスするものであり、オンライン方式は、銀行サーバ３に記憶されるオリジナルのリソースにアクセスするものである。

【0023】

図２（ｃ）は、リフレッシュトークン管理テーブル２３の一例を示す図である。リフレッシュトークン管理テーブル２３は、ＩＢサーバ４によりクライアント２０に対して発行されるリフレッシュトークンを管理するためのテーブルである。ここで、リフレッシュトークンとは、アクセストークンを取得するために使用される認証情報である。より具体的には、アクセストークンの再発行を要求する権限を有することを証明する認証情報である。リフレッシュトークンは、ランダムな文字列からなる。リフレッシュトークン管理テーブル２３の各レコードは、リフレッシュトークンと、リフレッシュトークンの有効期限と、リフレッシュトークンのスコープの各フィールドにより構成される。ここで、リフレッシュトークンのスコープは、当該リフレッシュトークンを使用して取得されるアクセストークンにより権限が付与されていることが証明されるアクセスの範囲を示し、アクセスの種類と、ユーザＩＤと、アクセスの処理方式と、照会期間とにより構成される。

【0024】

１−４．銀行サーバ３の構成
銀行サーバ３は、銀行が管理するサーバである。銀行サーバ３は、具体的には、ＣＰＵ等の演算処理装置と、ＨＤＤ等の記憶装置と、データ通信カード等の通信モジュール等を備える。銀行サーバ３の記憶装置には、口座情報管理テーブル３０が記憶される。口座情報管理テーブル３０は、ユーザ装置１のユーザの口座ごとに作成され、ユーザのオリジナルの口座情報が登録される。口座情報管理テーブル３０の各レコードは、日付と、入金金額と、出金金額と、残高と、摘要の各フィールドにより構成される。口座情報管理テーブル３０の構成は、口座情報管理テーブル２１と同様のため、図示を省略する。
なお、銀行（普通銀行）は、あくまで金融機関の一例であり、他の実施形態では、信託銀行やクレジットカード会社や保険会社等の他の金融機関によりサーバが管理されてもよい。

【0025】

１−５．ＩＢサーバ４の構成
図３は、ＩＢサーバ４の構成の一例を示す図である。ＩＢサーバ４は、銀行サーバ３に対してインターネットバンキングの機能を提供するインターネットバンキング事業者が管理するサーバである。ＩＢサーバ４は、具体的には、ＣＰＵ等の演算処理装置と、ＨＤＤ等の記憶装置と、データ通信カード等の通信モジュール等を備える。ＩＢサーバ４では、演算処理装置が、記憶装置に記憶されるプログラムを実行することで、ユーザ装置１のユーザからクライアント２０に対してアクセス権限を付与するための各種機能が実現される。これらの機能については後述する。

【0026】

ＩＢサーバ４の記憶装置には、ユーザ管理テーブル４０９と、クライアント管理テーブル４１０と、口座情報管理テーブル４１１と、認可コード管理テーブル４１２と、アクセストークン管理テーブル４１３と、リフレッシュトークン管理テーブル４１４と、有効期間テーブル４１５と、処理履歴管理テーブル４１６とが記憶される。

【0027】

図４は、ユーザ管理テーブル４０９の一例である。ユーザ管理テーブル４０９は、インターネットバンキングを利用する、ユーザ装置１のユーザの認証情報と個人情報を管理するためのテーブルである。ユーザ管理テーブル４０９の各レコードは、ユーザＩＤと、パスワードと、氏名と、住所とにより構成される。

【0028】

図５は、クライアント管理テーブル４１０の一例である。クライアント管理テーブル４１０は、ＩＢサーバ４からアクセストークンの発行を受けるクライアント２０の認証情報を管理するためのテーブルである。クライアント管理テーブル４１０の各レコードは、クライアント２０を識別するクライアントＩＤと、パスワードとにより構成される。

【0029】

口座情報管理テーブル４１１は、ユーザ装置１のユーザの口座ごとに作成され、銀行サーバ３から取得されたユーザの口座情報が登録される。ＩＢサーバ４は、口座情報管理テーブル４１１を、定期的に銀行サーバ３の口座情報管理テーブル３０に同期させる。口座情報管理テーブル４１１の各レコードは、日付と、入金金額と、出金金額と、残高と、摘要の各フィールドにより構成される。口座情報管理テーブル４１１の構成は、口座情報管理テーブル２１と同様のため、図示を省略する。

【0030】

図６（ａ）は、認可コード管理テーブル４１２の一例を示す図である。認可コード管理テーブル４１２は、クライアント２０に対して発行された認可コードに関する情報を管理するためのテーブルである。ここで、認可コードとは、アクセストークンとリフレッシュトークンを取得するために使用される認証情報である。より具体的には、アクセストークンとリフレッシュトークンの発行を要求する権限を有することを証明する認証情報である。認可コードは、ランダムな文字列からなる。認可コード管理テーブル４１２の各レコードは、認可コードと、クライアントＩＤと、認可コードの有効期限と、認可コードの要求時にクライアント２０からＩＢサーバ４に送信されるリダイレクトＵＲＩの各フィールドにより構成される。

【0031】

図６（ｂ）は、アクセストークン管理テーブル４１３の一例を示す図である。アクセストークン管理テーブル２２は、ＩＢサーバ４によりクライアント２０に対して発行されるアクセストークンを管理するためのテーブルである。アクセストークン管理テーブル４１３の各レコードは、アクセストークンと、クライアントＩＤと、アクセストークンの有効期限と、アクセストークンのスコープの各フィールドにより構成される。アクセストークンのスコープは、アクセスの種類と、ユーザＩＤと、アクセスの処理方式と、照会期間とにより構成される。

【0032】

図６（ｃ）は、リフレッシュトークン管理テーブル４１４の一例を示す図である。リフレッシュトークン管理テーブル４１４は、ＩＢサーバ４によりクライアント２０に対して発行されるリフレッシュトークンを管理するためのテーブルである。リフレッシュトークン管理テーブル４１４の各レコードは、リフレッシュトークンと、クライアントＩＤと、リフレッシュトークンの有効期限と、リフレッシュトークンのスコープと、アクセストークンの再発行回数の各フィールドにより構成される。リフレッシュトークンのスコープは、アクセスの種類と、ユーザＩＤと、アクセスの処理方式と、照会期間とにより構成される。

【0033】

図７は、有効期間テーブル４１５の一例を示す図である。有効期間テーブル４１５は、アクセストークンの有効期間を設定するために参照されるテーブルである。この有効期間テーブル４１５では、アクセス権限が付与されたクライアント２０により行われるまたは行われたリソースに対するアクセスに関する情報ごとに有効期間が対応付けられている。ここで、このアクセスに関する情報は、要求されたアクセストークンが発行された後にクライアント２０によりリソースに対して行われるアクセス（言い換えると、将来のアクセス）に関する情報と、要求されたアクセストークンが発行される前にクライアント２０によりリソースに対して行われたアクセス（言い換えると、過去のアクセス）に関する情報とに分けられる。将来のアクセスに関する情報は、言い換えると、アクセストークンのスコープの情報であり、処理方式と、照会範囲とが含まれる。ここで、照会範囲には、照会期間と、照会対象の口座数と、照会対象の入出金明細数とが含まれる。処理方式に対応付けられる有効期間については、セキュリティの観点から、オンライン方式に対応付けられる有効期間の方が、オフライン方式に対応付けられる有効期間よりも短めに設定されている。照会範囲に対応付けられる有効期間については、クライアント２０の利便性の観点から、照会範囲の値に比例するように設定されている。一方、過去のアクセスに関する情報には、処理時間と、アクセス回数（言い換えると、アクセストークンの再発行回数）と、直近のアクセス日時とが含まれる。ここで、処理時間とは、ＩＢサーバ４がクライアント２０からアクセス要求を受信してから、要求されたアクセスを実行するまでに要する時間である。処理時間とアクセス回数に対応付けられる有効時間については、クライアント２０の利便性の観点から、その値に比例するように設定されている。直近のアクセス日時に対応付けられる有効時間については、セキュリティの観点から、負の比例関係となるように設定されている。

【0034】

図８は、処理履歴管理テーブル４１６の一例を示す図である。処理履歴管理テーブル４１６は、アクセス権限が付与されたクライアント２０により行われたリソースに対するアクセスの履歴を管理するためのテーブルである。処理履歴管理テーブル４１６は、クライアント２０ごとに作成される。この処理履歴管理テーブル４１６の各レコードは、日時と、処理時間と、アクセスのスコープの各フィールドにより構成される。アクセスのスコープは、アクセスの種類と、ユーザＩＤと、アクセスの処理方式と、照会期間とにより構成される。

【0035】

次に、ＩＢサーバ４で実現される各種機能について説明する。具体的には、認可取得部４０１と、トークン要求受付部４０２と、有効期間設定部４０３と、アクセストークン発行部４０４と、リフレッシュトークン発行部４０５と、アクセス要求受付部４０６と、処理実行部４０７と、トークン再要求受付部４０８とについて説明する。

【0036】

認可取得部４０１は、クライアント２０により生成された認可要求を受け付けると、ユーザ装置１のユーザから、当該ユーザのリソースにアクセスする権限をクライアント２０に付与することに対する認可を取得する。その際、認可取得部４０１は、ユーザから認可を取得するのに先立ち、ユーザ管理テーブル４０９を参照して、当該ユーザの認証を行う。この認証に成功すると、認可取得部４０１は、アクセス権限をクライアント２０に付与することに対する認可をユーザから取得する。認可をユーザから取得すると、認可取得部４０１は、クライアント２０に対して認可コードを発行する。

【0037】

トークン要求受付部４０２は、認可コードを発行されたクライアント２０により生成される、アクセストークンの要求を受け付ける。この要求を受け付けると、トークン要求受付部４０２は、クライアント管理テーブル４１０を参照して、クライアント２０を認証する。この認証に成功すると、トークン要求受付部４０２は、受け付けた要求に含まれる認可コードの有効性を検証する。具体的には、認可コード管理テーブル４１２を参照して、認可コードの有効期限が経過しているか否かを検証する。

【0038】

有効期間設定部４０３は、トークン要求受付部４０２による認証および検証が成功すると、トークン要求受付部４０２により要求が受け付けられたアクセストークンの有効期間を設定する。その際、有効期間設定部４０３は、有効期間テーブル４１５を参照しつつ、認可取得部４０１により受け付けられた認可要求に基づいて有効期間を設定する。具体的には、有効期間設定部４０３は、認可要求に含まれるクライアントＩＤとアクセスのスコープに基づいて複数の有効期間を特定し、特定した複数の有効期間のうち、最短の有効期間を、要求されたアクセストークンの有効期間として設定する。ここで、最短の有効期間をアクセストークンの有効期間として設定しているのは、セキュリティの観点から、アクセストークンに設定される有効期間は短い方が好ましいからである。

【0039】

アクセストークン発行部４０４は、有効期間設定部４０３により有効期間が設定されたアクセストークンを、クライアント２０に対して発行する。アクセストークンを発行すると、アクセストークン発行部４０４は、現在の時点から、設定された有効期間が経過した後の時点である有効期限を算出し、発行したアクセストークンと、認可取得部４０１により受け付けられた認可要求に含まれるクライアントＩＤおよびアクセスのスコープとに対応付けて、アクセストークン管理テーブル４１３に登録する。

【0040】

リフレッシュトークン発行部４０５は、リフレッシュトークンをクライアント２０に対して発行する。リフレッシュトークンを発行すると、リフレッシュトークン発行部４０５は、現在の時点から、銀行ごとに設定される所定の有効期間が経過した後の時点である有効期限を算出し、発行したリフレッシュトークンと、認可取得部４０１により受け付けられた認可要求に含まれるクライアントＩＤおよびアクセスのスコープとに対応付けて、リフレッシュトークン管理テーブル４１４に登録する。

【0041】

アクセス要求受付部４０６は、クライアント２０から送信されるアクセス要求を受け付ける。アクセス要求を受け付けると、アクセス要求受付部４０６は、クライアント管理テーブル４１０を参照して、クライアント２０を認証する。この認証に成功すると、アクセス要求受付部４０６は、受け付けたアクセス要求に含まれるアクセストークンの有効性を検証する。具体的には、アクセストークン管理テーブル４１３を参照して、アクセストークンの有効期限が経過しているか否かを検証する。アクセストークンの有効性を検証すると、アクセス要求受付部４０６は、要求されたアクセスが権限の範囲内のものであるか否かを検証する。具体的には、アクセストークン管理テーブル４１３を参照して、受け付けたアクセス要求に含まれるアクセストークンとアクセストークンのスコープの組が登録されているか否かを判断する。

【0042】

処理実行部４０７は、アクセス要求受付部４０６による認証および検証が成功すると、アクセス要求受付部４０６により要求が受け付けられたアクセスを許可する。ここで、アクセスとは、残高や入出金明細等の口座情報の照会である。アクセスは、例えば、ＩＢサーバ４が有するＡＰＩ（Application Programming Interface）を呼び出すことにより行われる。処理実行部４０７は、要求された処理を実行すると、実行した処理の日時と、処理時間と、アクセスのスコープとを対応付けて、処理履歴管理テーブル４１６に登録する。

【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】

２−１．変形例１
上記の実施形態に係るクライアント２０は家計簿アプリケーションであるが、ユーザ装置１のユーザの口座情報にアクセスして、当該口座情報に基づいてユーザにサービスを提供する他のアプリケーションであってもよい。例えば、会計帳簿を作成する会計アプリケーションや、銀行の口座間で金銭を移動させる金銭移動（具体的には、決済または送金）アプリケーションであってもよい。

【0069】

２−２．変形例２
上記の実施形態に係るＩＢサーバ４は、アクセストークンを発行する認可サーバの機能と、リソースを保持して、当該リソースに対するアクセス要求を処理するリソースサーバの機能を兼ね備えているが、各機能につき別々のサーバを構築してもよい。

【0070】

２−３．変形例３
上記の実施形態に係る権限付与システム１００では、ＩＢサーバ４により銀行サーバ３に対してインターネットバンキングの機能が提供されているが、銀行サーバ３自体がインターネットバンキングの機能（すなわち、ＩＢサーバ４の機能）を有し、通信回線５に接続されてもよい。

【0071】

２−４．変形例４
上記の実施形態では、ユーザから認可を取得する方法として、「The OAuth 2.0 Authorization Framework」（[online] D. Hardt、2016年8月 ＜URL http://tools.ietf.org/html/rfc6749＞）に規定されるAuthorization Code Grant方式が採用されているが、これに代えて、同仕様書に規定されるImplicit Grant方式や、Resource Owner Password Credentials Grant方式や、Client Credentials Grant方式が採用されてもよい。

【0072】

２−５．変形例５
上記の実施形態に係るアクセストークン発行処理のステップＳｂ３において、有効期間設定部４０３は、ユーザが複数の銀行に口座を有する場合に、それら複数の銀行の口座の合計を、照会対象の口座数として特定してもよい。

【0073】

２−６．変形例６
上記の実施形態に係るアクセストークン発行処理のステップＳｂ５において、有効期間設定部４０３は、処理履歴管理テーブル４１６を参照してアクセスの処理時間を特定し、有効期間テーブル４１５を参照して、その特定した処理時間に対応付けられている有効時間を特定しているが、処理履歴管理テーブル４１６を参照して特定したアクセスの処理時間を、有効期間としてもよい。

【0074】

２−７．変形例７
上記の実施形態に係るアクセストークン発行処理において、有効期間設定部４０３は、ステップＳｂ１〜Ｓｂ７に加えてまたはいずれかと代えて、クライアント２０によるアクセスに関する他の情報に基づいて有効期間を特定してもよい。例えば、有効期間設定部４０３は、認可要求に示されるアクセスの種類に基づいて有効期間を特定してもよい。ここで、アクセスの種類には、口座情報の照会と、口座情報の更新が含まれる。口座情報の更新とは、具体的には、振込や振替といった口座間の金銭の移動のことである。アクセスの種類に対応付けられる有効期間については、口座情報の更新に対応付けられる有効期間の方が、口座情報の照会に対応付けられる有効期間よりも短めに設定される。

【0075】

または、有効期間設定部４０３は、認可要求により、照会対象の口座情報の種類が示される場合には、その口座情報の種類に基づいて有効期間を特定してもよい。ここで、口座情報の種類には、残高と、入出金明細と、ユーザの個人情報とが含まれる。口座情報の種類に対応付けられる有効期間については、残高に対応付けられる有効期間の方が、入出金明細に対応付けられる有効期間よりも短めに設定される。

【0076】

２−８．変形例８
上記の実施形態に係るアクセストークン発行処理において、有効期間設定部４０３は、ステップＳｂ１〜Ｓｂ７のすべてを実行しなくてもよい。

【0077】

２−９．変形例９
上記の実施形態に係るアクセストークン発行処理のステップＳｂ１〜Ｓｂ７において、有効期間設定部４０３は、有効期間テーブル４１５を参照せずに、クライアント２０によるアクセスに関する情報ごとに用意された所定の数式を用いて有効期間を特定してもよい。

【0078】

２−１０．変形例１０
上記の実施形態に係る有効期間テーブル４１５において、処理方式に対応付けられる有効期間について、クライアント２０の利便性の観点から、オンライン方式に対応付けられる有効期間の方を、オフライン方式に対応付けられる有効期間よりも長めに設定するようにしてもよい。また、直近のアクセス日時に対応付けられる有効時間について、クライアント２０の利便性の観点から、正の比例関係となるように設定してもよい。

【0079】

２−１１．変形例１１
上記の実施形態に係るアクセストークン発行処理のステップＳｂ８において、有効期間設定部４０３は、クライアント２０の利便性の観点から、特定した複数の有効期間のうち、最も長い有効期間を特定するようにしてもよい。

【0080】

２−１２．変形例１２
上記の実施形態に係るアクセストークン発行処理のステップＳｂ８において、有効期間設定部４０３は、特定した複数の有効期間を所定の数式に代入して算出することにより、一の有効期間を特定するようにしてもよい。ここで、所定の数式は、例えば、以下のように表される。
（数１）
ｙ＝（ａｘ₁＋ｂｘ₂＋ｃｘ₃＋ｄｘ₄＋ｅｘ₅＋ｆｘ₆＋ｇｘ₇）／（ａ＋ｂ＋ｃ＋ｄ＋ｅ＋ｆ＋ｇ）

【0081】

数１の式において、ｙは求める有効期間を表し、ｘ₁〜ｘ₇はステップＳｂ１〜Ｓｂ７で特定される有効期間を表し、ａ〜ｇは係数を表す。ここで、係数ａ〜ｇは、ステップＳｂ１〜Ｓｂ７で特定される有効期間ごとに異なるように設定されてもよい。すなわち、有効期間設定部４０３は、ステップＳｂ１〜Ｓｂ７で特定した複数の有効期間の各々に対して、当該有効期間を特定するために参照した情報に応じた重み付けを行うようにしてもよい。例えば、アクセスの処理方式に基づいて特定した有効期間に対して、照会対象の入出金明細数に基づいて特定した有効期間よりも大きい重みを付けるようにしてもよい。あるいは、係数ａ〜ｇは、一律に「１」に設定されてもよい。すなわち、有効期間設定部４０３は、ステップＳｂ１〜Ｓｂ７で特定した複数の有効期間の各々に対して重み付けを行わなくてもよい。

【0082】

２−１３．変形例１３
上記の実施形態において、アクセストークンは、その有効期間を示す文字列を含むような文字列としてもよい。同様に、リフレッシュトークンは、その有効期間を示す文字列を含むような文字列としてもよい。

【0083】

２−１４．変形例１４
上記の実施形態において、ＩＢサーバ４は、アクセストークンのスコープに応じて当該アクセストークンに優先度を設定し、クライアント２０からアクセス要求を受け付けた際に、アクセストークンに設定された優先度と、要求されたアクセスの種類に対応付けられた優先度とを比較することで、当該アクセスを許可するか否かを判断するようにしてもよい。

【0084】

アクセストークンに優先度を設定するために、ＩＢサーバ４は、優先度設定部の機能を有してもよい。この優先度設定部の機能は、ＩＢサーバ４の演算処理装置が、記憶装置に記憶されるプログラムを実行することで実現される。この優先度設定部は、認可取得部４０１により受け付けられた認可要求に含まれるアクセスのスコープに基づいて、トークン要求受付部４０２により要求が受け付けられたアクセストークンの優先度を設定する。その際、優先度設定部は、後述する優先度テーブルを参照して、アクセストークンの優先度を設定する。ここで、優先度とは、アクセス権限が付与されたクライアント２０により行われるリソースに対するアクセスを許可するか否かを判断するために参照される情報である。

【0085】

図１３は、優先度テーブルの一例を示す図である。この優先度テーブルでは、アクセスの種類ごとに優先度が対応付けられている。優先度の高さは、優先度を示す数字の大きさに比例する。

【0086】

優先度設定部は、上記の実施形態に係るアクセストークン発行処理において、有効期間設定部４０３により最も短い有効期間が特定されると（ステップＳｂ８）、優先度テーブルを参照しつつ、認可要求に示されるアクセスの種類に基づいて、発行されるアクセストークンの優先度を設定する。例えば、認可要求に示されるアクセスの種類が「決済（振替）」の場合には、アクセストークンの優先度として「２」を設定する（図１３参照）。優先度設定部が優先度を設定すると、アクセストークン発行部４０４は、ステップＳｂ９において、アクセスのスコープに代えて、設定された優先度を、アクセストークンと有効期限とクライアントＩＤと対応付けて、アクセストークン管理テーブル４１３に登録する。リフレッシュトークン発行部４０５は、ステップＳｂ１０において、アクセスのスコープに代えて、設定された優先度を、リフレッシュトークンと有効期限とクライアントＩＤと対応付けて、リフレッシュトークン管理テーブル４１４に登録する。

【0087】

アクセストークンに優先度が設定された場合、上記の実施形態に係るアクセス処理のステップＳｃ４において、アクセス要求受付部４０６は、要求されたアクセスが権限の範囲内のものであるか否かを検証するために、受け付けたアクセス要求に含まれるアクセストークンの優先度が、要求されたアクセスの種類に対応付けられた優先度以上であるか否かを判断する。ここで、アクセス要求に含まれるアクセストークンの優先度は、アクセストークン管理テーブル４１３を参照することにより特定され、要求されたアクセスの種類に対応付けられた優先度は、優先度テーブルを参照することにより特定される。この判断の結果、アクセストークンの優先度が、要求されたアクセスの種類の優先度未満である場合には（すなわち、権限の範囲内でない場合には）、アクセス要求受付部４０６はクライアント２０に対してエラー応答を送信する。一方、アクセストークンの優先度が、要求されたアクセスの種類の優先度以上である場合には（すなわち、権限の範囲内である場合には）、処理実行部４０７は、要求されたアクセスを許可する（ステップＳｃ５）。

【0088】

また、アクセストークンに優先度が設定された場合、上記の実施形態に係るアクセストークン再発行処理のステップＳｄ４において、トークン再要求受付部４０８は、受け付けたアクセストークン再要求に含まれるアクセストークンのスコープが、権限の範囲内であるか否かを検証するために、受け付けたアクセストークン再要求に含まれるリフレッシュトークンの優先度が、受け付けたアクセストークン再要求に示されるアクセスの種類に対応付けられた優先度以上であるか否かを判断する。ここで、アクセストークン再要求に含まれるリフレッシュトークンの優先度は、リフレッシュトークン管理テーブル４１４を参照することにより特定され、受け付けたアクセストークン再要求に示されるアクセスの種類の優先度は、優先度テーブルを参照することにより特定される。この判断の結果、リフレッシュトークンの優先度が、受け付けたアクセストークン再要求に示されるアクセスの種類の優先度未満である場合には（すなわち、権限の範囲内でない場合には）、トークン再要求受付部４０８はクライアント２０に対してエラー応答を送信する。一方、リフレッシュトークンの優先度が、受け付けたアクセストークン再要求に示されるアクセスの種類の優先度以上である場合には（すなわち、権限の範囲内である場合には）、ＩＢサーバ４は、図１０に示すアクセストークン発行処理を実行する（ステップＳｄ５）。

【0089】

以上説明した本変形例によれば、アクセスの種類ごとに異なるアクセストークンを発行する必要がない。

【0090】

２−１５．変形例１５
上記の変形例１４に係るアクセス処理のステップＳｃ４において、アクセストークンの優先度が、要求されたアクセスの種類の優先度未満である場合に（すなわち、権限の範囲内でない場合に）、アクセス要求受付部４０６は、当該アクセストークンを失効させてもよい。具体的には、当該アクセストークンに関する情報をアクセストークン管理テーブル４１３から削除してもよい。

【0091】

２−１６．変形例１６
上記の変形例１４に係るアクセス処理のステップＳｃ４において、ＩＢサーバ４からエラー応答を受信したクライアント２０は、当該エラー応答の受信を受けて、ＩＢサーバ４に拒否されたアクセスの権限をユーザ装置１のユーザから取得するようにしてもよい。言い換えると、クライアント２０は、ＩＢサーバ４により拒否されたアクセス要求に含まれていたアクセストークンよりも高い優先度が設定されたアクセストークンをＩＢサーバ４から取得するようにしてもよい。優先度の高いアクセストークンを取得するために、クライアント２０は、ユーザエージェント１０に連携依頼を促して取得し、図９に示す権限付与処理を開始してもよい。

【0092】

なお、ここで実行される権限付与処理内のアクセストークン発行処理において、アクセストークン発行部４０４は、生成したアクセストークンをアクセストークン管理テーブル４１３に登録するのに伴い、当該アクセストークンよりも優先度の低いアクセストークンであって、共通のクライアントＩＤおよびユーザＩＤと対応付けられているアクセストークンを削除するようにしてもよい（ステップＳｂ９）。また、リフレッシュトークン発行部４０５は、生成したリフレッシュトークンをリフレッシュトークン管理テーブル４１４に登録するのに伴い、当該リフレッシュトークンよりも優先度の低いリフレッシュトークンであって、共通のクライアントＩＤおよびユーザＩＤと対応付けられているリフレッシュトークンを削除するようにしてもよい（ステップＳｂ１０）。

【0093】

あるいは、アクセストークン発行部４０４が優先度の低いアクセストークンを削除する代わりに、リフレッシュトークン発行部４０５がリフレッシュトークンの発行を省略するようにしてもよい。リフレッシュトークンの発行が省略されることで、新たに生成されたアクセストークンの再発行が不可能となり、新たに生成されたアクセストークンの使用機会が制限されることになる。あるいは、リフレッシュトークン発行部４０５は、アクセストークンと同じ有効期間を、リフレッシュトークンの有効期間として設定するようにしてもよい。

【0094】

２−１７．変形例１７
上記の変形例１４に係るアクセストークン発行処理において、有効期間設定部４０３は、ステップＳｂ１〜Ｓｂ８を実行せずに、銀行ごとに設定される所定の有効期間を、発行されるアクセストークンの有効期間として特定してもよい。

【0095】

２−１８．変形例１８
上記の実施形態では、クライアント２０ごとにアクセストークンおよびリフレッシュトークンが発行されているが、複数のクライアント２０からなるグループ単位でアクセストークンおよびリフレッシュトークンが発行されてもよい。

【0096】

２−１９．変形例１９
上記の実施形態に係るアクセストークン発行処理のステップＳｂ１０において、リフレッシュトークン発行部４０５は、ステップＳａ２で取得された認可要求に示されるアクセスの種類に基づいて、リフレッシュトークン発行部４０５の有効期間を設定してもよい。ここで、アクセスの種類には、口座情報の照会と、口座情報の更新が含まれる。アクセスの種類に対応付けられる有効期間については、口座情報の更新に対応付けられる有効期間の方が、口座情報の照会に対応付けられる有効期間よりも短めに設定される。

【0097】

２−２０．変形例２０
上記の実施形態に係る権限付与処理において、リフレッシュトークンのみの発行が、クライアント２０からＩＢサーバ４に対して要求されてもよい。

【0098】

２−２１．変形例２１
上記の実施形態または変形例に係るＩＢサーバ４において実行されるプログラムは、磁気ディスク、光ディスク、光磁気ディスク、メモリ等の記憶媒体に記憶された状態で提供されてもよい。また、当該プログラムは、インターネット等の通信回線を介してダウンロードされてもよい。

【符号の説明】

【0099】

１…ユーザ装置、２…クライアント装置、３…銀行サーバ、４…ＩＢサーバ、５…通信回線、６…通信回線、１０…ユーザエージェント、２０…クライアント、２１…口座情報管理テーブル、２２…アクセストークン管理テーブル、２３…リフレッシュトークン管理テーブル、３０…口座情報管理テーブル、１００…権限付与システム、４０１…認可取得部、４０２…トークン要求受付部、４０３…有効期間設定部、４０４…アクセストークン発行部、４０５…リフレッシュトークン発行部、４０６…アクセス要求受付部、４０７…処理実行部、４０８…トークン再要求受付部、４０９…ユーザ管理テーブル、４１０…クライアント管理テーブル、４１１…口座情報管理テーブル、４１２…認可コード管理テーブル、４１３…アクセストークン管理テーブル、４１４…リフレッシュトークン管理テーブル、４１５…有効期間テーブル、４１６…処理履歴管理テーブル

【図1】

【図2】

【図3】

【図4】

【図5】

【図6】

【図7】

【図8】

【図9】

【図10】

【図11】

【図12】

【図13】