特許第6626466号(P6626466)IP Force 特許公報掲載プロジェクト 2015.5.11 β版

知財求人 - 知財ポータルサイト「IP Force」

▶ 日本電信電話株式会社の特許一覧
特許6626466API提供装置及びAPI使用権委譲の同意方法
<>
  • 特許6626466-API提供装置及びAPI使用権委譲の同意方法 図000002
  • 特許6626466-API提供装置及びAPI使用権委譲の同意方法 図000003
  • 特許6626466-API提供装置及びAPI使用権委譲の同意方法 図000004
  • 特許6626466-API提供装置及びAPI使用権委譲の同意方法 図000005
  • 特許6626466-API提供装置及びAPI使用権委譲の同意方法 図000006
  • 特許6626466-API提供装置及びAPI使用権委譲の同意方法 図000007
  • 特許6626466-API提供装置及びAPI使用権委譲の同意方法 図000008
  • 特許6626466-API提供装置及びAPI使用権委譲の同意方法 図000009
  • 特許6626466-API提供装置及びAPI使用権委譲の同意方法 図000010
  • 特許6626466-API提供装置及びAPI使用権委譲の同意方法 図000011
  • 特許6626466-API提供装置及びAPI使用権委譲の同意方法 図000012
  • 特許6626466-API提供装置及びAPI使用権委譲の同意方法 図000013
  • 特許6626466-API提供装置及びAPI使用権委譲の同意方法 図000014
  • 特許6626466-API提供装置及びAPI使用権委譲の同意方法 図000015
  • 特許6626466-API提供装置及びAPI使用権委譲の同意方法 図000016
  • 特許6626466-API提供装置及びAPI使用権委譲の同意方法 図000017
  • 特許6626466-API提供装置及びAPI使用権委譲の同意方法 図000018
  • 特許6626466-API提供装置及びAPI使用権委譲の同意方法 図000019
< >
(19)【発行国】日本国特許庁(JP)
(12)【公報種別】特許公報(B2)
(11)【特許番号】6626466
(24)【登録日】2019年12月6日
(45)【発行日】2019年12月25日
(54)【発明の名称】API提供装置及びAPI使用権委譲の同意方法
(51)【国際特許分類】
   G06Q 30/06 20120101AFI20191216BHJP
【FI】
   G06Q30/06
【請求項の数】2
【全頁数】14
(21)【出願番号】特願2017-27690(P2017-27690)
(22)【出願日】2017年2月17日
(65)【公開番号】特開2018-133022(P2018-133022A)
(43)【公開日】2018年8月23日
【審査請求日】2018年7月24日
(73)【特許権者】
【識別番号】000004226
【氏名又は名称】日本電信電話株式会社
(74)【代理人】
【識別番号】100083806
【弁理士】
【氏名又は名称】三好 秀和
(74)【代理人】
【識別番号】100129230
【弁理士】
【氏名又は名称】工藤 理恵
(72)【発明者】
【氏名】鈴木 彩
【審査官】 田付 徳雄
(56)【参考文献】
【文献】 特開2012−194722(JP,A)
【文献】 米国特許第09338007(US,B1)
【文献】 特開2012−174189(JP,A)
【文献】 特開2009−129214(JP,A)
(58)【調査した分野】(Int.Cl.,DB名)
G06Q 10/00−99/00
(57)【特許請求の範囲】
【請求項1】
API(Application Programming Interface)提供装置において、
他のAPI提供装置が発行したユーザの識別情報を記憶する記憶部と、
前記他のAPI提供装置からユーザへのAPI使用権委譲の同意要求を受信する受信部と、
APIの使用権を委譲することに同意した前記ユーザの同意情報に基づき、前記記憶部から前記他のAPI提供装置に係る前記ユーザの識別情報を読み出して、前記ユーザの識別情報及び同意情報を含む伝文データを生成する生成部と、
前記同意要求に対して前記伝文データを前記ユーザの同意応答として前記他のAPI提供装置へ送信する送信部と
を備えることを特徴とするAPI提供装置。
【請求項2】
API(Application Programming Interface)提供装置で行うAPI使用権委譲の同意方法において、
前記API提供装置が、
他のAPI提供装置が発行したユーザの識別情報を記憶部に記憶するステップと、
前記他のAPI提供装置からユーザへのAPI使用権委譲の同意要求を受信するステップと、
APIの使用権を委譲することに同意した前記ユーザの同意情報に基づき、前記記憶部から前記他のAPI提供装置に係る前記ユーザの識別情報を読み出して、前記ユーザの識別情報及び同意情報を含む伝文データを生成するステップと、
前記同意要求に対して前記伝文データを前記ユーザの同意応答として前記他のAPI提供装置へ送信するステップと、
を行うことを特徴とするAPI使用権委譲の同意方法。
【発明の詳細な説明】
【技術分野】
【0001】
本発明は、API使用権委譲の同意応答やユーザのアカウントを管理する技術に関する。
【背景技術】
【0002】
クライアントアプリケーションがWeb−API(Web Application Programming Interface)を利用する際、API提供装置とのAPI利用認証を行う技術として、非特許文献1,2がある。
【先行技術文献】
【非特許文献】
【0003】
【非特許文献1】“OAth 2.0”、[online]、[平成29年2月6日検索]、<URL: https://oauth.net/2/>
【非特許文献2】“The OAuth 2.0 Authorization Framework,4.1. Authorization Code Grant”、[online]、[平成29年2月13日検索]、<URL: https://tools.ietf.org/html/rfc6749#section-4.1>
【発明の概要】
【発明が解決しようとする課題】
【0004】
APIの再販を行うビジネスモデルの場合、複数のAPI提供装置が多段に接続される。このとき、API利用認証において、複数のAPI提供装置がエンドユーザに対してAPI使用権委譲の同意をそれぞれ要求するため、エンドユーザは複数の同意要求に対して応答する必要があり、クライアントアプリケーション利用の利便性に欠けるという課題がある。また、その同意要求がAPI卸元事業者のAPI提供装置からエンドユーザに直接送信されるため、API卸元事業者をユーザやクライアントに隠ぺいしたいという要件を満たすことができない。
【0005】
本発明は、上記事情を鑑みてなされたものであり、API使用権委譲の同意に係るユーザの負担を改善し、API卸元事業者のAPI提供装置を隠ぺいすることを目的とする。
【課題を解決するための手段】
【0006】
以上の課題を解決するため、請求項1に係るAPI提供装置は、APIの使用権を委譲することに同意したユーザの同意情報に基づき、他のAPI提供装置から前記ユーザへのAPI使用権委譲の同意要求に対して同意を示す同意情報を送信する応答部を備えることを特徴とする。
【0007】
請求項2に係るAPI提供装置は、請求項1に記載のAPI提供装置において、自API提供装置の利用者と前記他のAPI提供装置の利用者がそれぞれ前記ユーザに発行したユーザの識別情報を関連付けて記憶する記憶部を更に備えることを特徴とする。
【0008】
請求項3に係るAPI使用権委譲の同意方法は、API提供装置で行うAPI使用権委譲の同意方法において、前記API提供装置が、APIの使用権を委譲することに同意したユーザの同意情報に基づき、他のAPI提供装置から前記ユーザへのAPI使用権委譲の同意要求に対して同意を示す同意情報を送信するステップを行うことを特徴とする。
【0009】
請求項4に係るAPI使用権委譲の同意方法は、請求項3に記載のAPI使用権委譲の同意方法において、前記ステップを行う前に、自API提供装置の利用者と前記他のAPI提供装置の利用者がそれぞれ前記ユーザに発行したユーザの識別情報を関連付けて記憶部に記憶するステップを行うことを特徴とする。
【発明の効果】
【0010】
本発明によれば、API使用権委譲の同意に係るユーザの負担を軽減し、API卸元事業者のAPI提供装置を隠ぺいすることができる。
【図面の簡単な説明】
【0011】
図1】システム構成を示す図である。
図2】システム全体の処理シーケンスを示す図である。
図3】APIリクエスト処理部11の処理フローを示す図である。
図4】認可リクエスト検証部13の処理フローを示す図である。
図5】ユーザ認証部14の処理フローを示す図である。
図6】APIリクエスト生成部15の処理フローを示す図である。
図7】APIレスポンス処理部16の処理フローを示す図である。
図8】ユーザ認証応答部17の処理フローを示す図である。
図9】認可コード発行部18の処理フローを示す図である。
図10】APIレスポンス生成部12の処理フローを示す図である。
図11】トークンリクエスト検証部19の処理フローを示す図である。
図12】アクセストークン発行部20の処理フローを示す図である。
図13】アクセストークン検証部21の処理フローを示す図である。
図14】アクセストークン変換部22の処理フローを示す図である。
図15】ユーザ認証情報の例を示す図である。
図16】アクセストークンの例を示す図である。
図17】認可コードの例を示す図である。
図18】本実施の形態と従来例との概説図である。
【発明を実施するための形態】
【0012】
上記課題を解決するため、本発明は、多段接続された複数のAPI提供装置において、API卸売事業者のAPI提供装置(上位API提供装置)に疑似ユーザ機能を具備する。そして、その疑似ユーザ機能で、API卸元事業者のAPI提供装置(下位API提供装置)からユーザへのAPI使用権委譲の同意要求に対し、API使用権の委譲に同意したユーザの同意情報に基づき、ユーザに代わりユーザの同意を自ら代理応答する。これにより、API使用権委譲の同意に係るユーザの負担を軽減し、API卸元事業者のAPI提供装置を隠ぺいしつつAPIを提供することができる。以下、本発明を実施する一実施の形態について図面を用いて説明する。
【0013】
本実施の形態に係るシステム構成を図1に示す。このシステム構成では、エンドユーザ利用端末1と、API利用装置3と、上位API提供装置5と、下位API提供装置7と、リソースサーバ9と、を備えて構成される。図1に示したAPI提供装置の接続構成は2段の例であり、例えば3段以上を多段接続してもよい。
【0014】
エンドユーザ利用端末1は、例えば携帯電話やスマートフォンなど、リソースサーバ9などで提供されるサービスをクライアント側で実行するための装置である。また、API利用装置3は、そのサービスをクライアント側で実行するアプリケーション又はその装置である。そのアプリケーションをエンドユーザ利用端末1の内部で実行してもよい。
【0015】
上位API提供装置5は、サービスに係るソフトウェアの機能をAPIとして提供する装置であり、API提供前にエンドユーザに対してAPI使用権委譲の同意を要求する「同意要求機能」、エンドユーザからの同意を受信済であれば下位API提供装置7からエンドユーザへのAPI使用権委譲の同意要求に対してユーザの同意を代理応答する「疑似ユーザ機能」などを備える。本実施の形態において上位API提供装置5はAPI卸売事業者により利用される。
【0016】
一方、下位API提供装置7は、API卸元事業者により利用され、上記同意要求機能などを備える。下位API提供装置7は、基本的には従来のAPI提供装置であり、その一方で上位API提供装置5は、従来のAPI提供装置に対して上記「疑似ユーザ機能」を追加して構成されている。
【0017】
また、上位API提供装置5は、下位API提供装置7に対してユーザの同意を代理応答するにあたり、下位API提供装置7へログインを行う必要がある。そこで、下位API提供装置7がエンドユーザに対して発行したユーザID及びパスワードを保持・管理する「ユーザアカウント管理機能」を更に備える。
【0018】
上位API提供装置5の構成例について説明する。本実施の形態において、上位API提供装置5は、図1に示したように、APIリクエスト処理部11と、APIレスポンス生成部12と、認可リクエスト検証部13と、ユーザ認証部14と、APIリクエスト生成部15と、APIレスポンス処理部16と、ユーザ認証応答部17と、認可コード発行部18と、トークンリクエスト検証部19と、アクセストークン発行部20と、アクセストークン検証部21と、アクセストークン変換部22と、ユーザ認証情報記憶部23と、認可コード記憶部24と、アクセストークン記憶部25と、を備えて構成される。
【0019】
図1では、従来のAPI提供装置に対する追加機能部に斜めハッチを施している。上述した「疑似ユーザ機能」は、APIリクエスト生成部15と、APIレスポンス処理部16と、ユーザ認証応答部17と、で構成される。また、上述した「ユーザアカウント管理機能」は、ユーザ認証情報記憶部23で構成される。これら4つの機能部が互いに連携して動作することにより、下位API提供装置7に対してログイン処理及びユーザ同意の代理応答処理を実行する。
【0020】
また、これら4つの機能部と後述するアクセストークン変換部22を除く他の全ての機能部は、従来のAPI提供装置が備える機能部であり、「OAuth 2.0」などで規定された認可サーバとして機能する。この認可サーバについては非特許文献1,2に詳しいが、簡易には、リソース利用の認証と認可の取得が成功した後にトークン(クライアントに対して発行されたアクセス認可を表す文字列であり、リソース側で認可された権限の範囲とアクセス期間を示す)を発行するサーバである。但し、本実施の形態では、「疑似ユーザ機能」でユーザの代理応答を行うため、APIリクエストに含まれるトークンを下位API提供装置7が発行したトークンに変換する必要がある。そこで、上位API提供装置5は、トークンを変換する「トークン変換機能」も更に備える。この「トークン変換機能」は、アクセストークン変換部22で構成される。
【0021】
下位API提供装置7は、認可サーバとして機能する従来のAPI提供装置である。具体的には、下位API提供装置7は、図1に示した上位API提供装置5から、APIリクエスト生成部15と、APIレスポンス処理部16と、ユーザ認証応答部17と、ユーザ認証情報記憶部23と、アクセストークン変換部22と、を除く機能部により構成される。
【0022】
リソースサーバ9は、所定のサービスを提供するサーバである。
【0023】
次に、上位API提供装置5の動作について説明する。
【0024】
まず、その動作を概説する。上位API提供装置5がAPI利用装置3(クライアント)からのAPI利用リクエストを受信すると、API使用権委譲の同意をユーザに要求する。ユーザの承諾後、上位API提供装置5から下位API提供装置7へAPI利用リクエストを送信する。その後、API使用権委譲の同意が下位API提供装置から上位API提供装置へ要求されるが、ユーザの同意を既に受信しているので、上位API提供装置5の疑似ユーザ機能が保存済のユーザ認証情報を利用して同意に自動応答し、認証プロセスを通過する。
【0025】
続いて、その動作を詳述する。図2は、システム全体の処理シーケンスである。図3図14は、上位API提供装置5を構成する各機能部の処理フローを示す図である。図15図17は、本処理シーケンスで用いる各種データの例を示す図である。
【0026】
なお、予めユーザとAPI卸売事業者とAPI卸元事業者との間で、「API使用権委譲について、ユーザが上位API提供装置5からの同意要求に対して同意を承諾したことを以て、下位API提供装置7からの同意要求も承諾したとみなす」ことが成立しているものとする。
【0027】
また、上位API提供装置5は、予め下位API提供装置7へユーザ登録を行い、払い出されたユーザ認証情報(ユーザID及びパスワード)を保存及び管理を行っているものとする。具体的には、上位API提供装置5のユーザ認証情報記憶部23が、上位API提供装置5のAPI卸売事業者がエンドユーザに既に発行したユーザIDをキーに、下位API提供装置7のAPI卸元事業者が上位API提供装置5(=疑似エンドユーザ)に発行したユーザID及びパスワードを関連付けて記憶する(後述する図15を参照)。
【0028】
まず、図2に示すように、エンドユーザが上位API提供装置5でクライアントアプリの利用を開始すると、APIのアクセスに係る認可リクエストがエンドユーザ利用端末1を介してAPI利用装置3から上位API提供装置5へ送信される。
【0029】
次に、上位API提供装置5は、図2のステップAの処理を実行する。図3(a)に示すように、APIリクエスト処理部11は、API利用装置3よりリダイレクトされたエンドユーザ利用端末1からの認可リクエストを受信し(ステップA1)、認可リクエスト検証部13へ該認可リクエストを送信する(ステップA2)。
【0030】
次に、上位API提供装置5は、図2のステップB,Cの処理を実行する。図4に示すように、認可リクエスト検証部13は、APIリクエスト処理部11から認可リクエストを受信し(ステップB1)、その認可リクエストに含まれるパラメータが規定に合致しているか否かを判定する(ステップB2)。その後、そのパラメータが規定に合致している場合、ユーザ認証部14へユーザ認証開始信号を送信する(ステップB3)。一方、そのパラメータが規定に合致しない場合、エラー信号を生成してAPI利用装置3へ送信する(ステップB4)。以降、ユーザ認証部14へユーザ認証開始信号を送信したものとする。
【0031】
その後、図5に示すように、ユーザ認証部14は、認可リクエスト検証部13からユーザ認証開始信号を受信し(ステップC1)、エンドユーザ利用端末1へユーザ認証画面及びAPI使用権委譲の同意画面の画面データを送信する(ステップC2)。そして、エンドユーザ利用端末1からユーザ認証情報及びAPI使用権委譲の同意に対する認可又は拒否の応答を受信し(ステップC3)、受信した応答に基づき、ユーザ認証が成功し、かつ、API使用権委譲の同意が認可されたかを判定する(ステップC4)。ユーザ認証が成功し、かつ、API使用権委譲の同意が認可された場合、APIリクエスト生成部15へ認可リクエスト開始信号を送信する(ステップC5)。一方、ユーザ認証が成功しない場合、又は、API使用権委譲の同意が認可されていない場合、エラー信号を生成してAPI利用装置3へ送信する(ステップC6)。
【0032】
以降、APIリクエスト生成部15へ認可リクエスト開始信号を送信したものとする。なお、上位API提供装置5は、ユーザ認証結果やユーザによるAPI使用権委譲への同意応答など、エンドユーザ利用端末1、API利用装置3又は下位API提供装置7との間でやりとりされた全てのデータをメモリやハードディスクなどに随時保存しておく。
【0033】
次に、上位API提供装置5は、図2のステップDの処理を実行する。図6(a)に示すように、APIリクエスト生成部15は、ユーザ認証部14から認可リクエスト開始信号を受信し(ステップD1)、その認可リクエストをAPI卸元事業者の下位API提供装置7へ送信する(ステップD2)。
【0034】
次に、上位API提供装置5は、図2のステップE,F,Gの処理を実行する。図7(a)に示すように、APIレスポンス処理部16は、API卸元事業者の下位API提供装置7からユーザ認証画面及びAPI使用権委譲の同意画面の画面データを受信し(ステップE1)、ユーザ認証応答部17に該画面データを送信する(ステップE2)。
【0035】
その後、図8に示すように、ユーザ認証応答部17は、APIレスポンス処理部16からユーザ認証画面及びAPI使用権委譲の同意画面の画面データを受信し(ステップF1)、ユーザ認証情報記憶部23に認証情報を問い合わせる(ステップF2)。そして、ユーザ認証及びAPI使用権委譲の同意に応答する伝文を組み立て、APIリクエスト生成部15に送信する(ステップF3)。
【0036】
その後、図6(b)に示すように、APIリクエスト生成部15は、ユーザ認証応答部17からユーザ認証及びAPI使用権委譲の同意に応答する伝文を受信し(ステップG1)、ユーザ同意応答をAPI卸元事業者の下位API提供装置7へ送信する(ステップG2)。
【0037】
ここで、ステップF,Gの動作を詳述する。ユーザは、予め下位API提供装置7からのAPI使用権委譲の同意要求に対して同意承諾を擬制し、また、既に上位API提供装置5に対してAPI使用権の委譲に同意を示している。それゆえ、ユーザ認証応答部17は、そのユーザの同意に基づき、下位API提供装置7へのログイン及びユーザ同意処理を自動で開始する。具体的には、ユーザ認証情報記憶部23(図15参照)から、対象ユーザのユーザID(上位API提供装置5が発行したユーザID)に対応する、下位API提供装置7のAPI卸元事業者が発行したユーザID及びパスワードを取得し、そのユーザID及びパスワードとユーザの同意を示す同意情報とに基づき下位API提供装置7へのログイン処理及び同意処理を実行する。
【0038】
次に、上位API提供装置5は、図2のステップHの処理を実行する。図7(b)に示すように、APIレスポンス処理部16は、API卸元事業者の下位API提供装置7から認可レスポンスを受信し(ステップH1)、その認可レスポンス内の認可コード(B)をAPIリクエスト生成部15に送信する(ステップH2)。
【0039】
次に、上位API提供装置5は、図2のステップIの処理を実行する。図6(c)に示すように、APIリクエスト生成部15は、APIレスポンス処理部16から認可コード(B)を受信し(ステップI1)、その認可コード(B)を含めたトークンリクエストをAPI卸元事業者の下位API提供装置7へ送信する(ステップI2)。
【0040】
次に、上位API提供装置5は、図2のステップJ,K,Lの処理を実行する。図7(c)に示すように、APIレスポンス処理部16は、API卸元事業者の下位API提供装置7からトークンレスポンスを受信し(ステップJ1)、そのトークンレスポンスに含まれるアクセストークン(B)をアクセストークン記憶部25(図16参照)に格納し(ステップJ2)、認可コード発行部18へ認可レスポンス開始信号を送信する(ステップJ3)。
【0041】
その後、図9に示すように、認可コード発行部18は、APIレスポンス処理部16から認可レスポンス開始信号を受信し(ステップK1)、認可コード(A)を発行して認可コード記憶部24(図17参照)に格納する(ステップK2)。そして、その認可コード(A)をAPIレスポンス生成部12に送信する(ステップK3)。
【0042】
その後、図10(a)に示すように、APIレスポンス生成部12は、認可コード発行部18から認可コード(A)を受信し(ステップL1)、エンドユーザ利用端末1へ該認可コード(A)を含む認可レスポンスを送信する(ステップL2)。この認可レスポンスは、API利用装置3へリダイレクトされる。
【0043】
次に、上位API提供装置5は、図2のステップM,N,O,Pの処理を実行する。図3(b)に示すように、APIリクエスト処理部11は、API利用装置3から認可コード(A)を含むトークンリクエストを受信し(ステップM1)、そのトークンリクエストをトークンリクエスト検証部19へ送信する(ステップM2)。
【0044】
その後、図11に示すように、トークンリクエスト検証部19は、APIリクエスト処理部11からトークンリクエストを受信し(ステップN1)、そのトークンリクエストに含まれるパラメータが規定に合致しているか否かを判定する(ステップN2)。そして、そのパラメータが規定に合致している場合、アクセストークン発行部20へトークン発行信号を送信する(ステップN3)。一方、そのパラメータが規定に合致しない場合、エラー信号を生成してAPI利用装置3へ送信する(ステップN4)。以降、アクセストークン発行部20へトークン発行信号を送信したものとする。
【0045】
その後、図12に示すように、アクセストークン発行部20は、トークンリクエスト検証部19からトークン発行信号を受信し(ステップO1)、アクセストークン(A)を発行してアクセストークン記憶部25に格納する(ステップO2)。そして、そのアクセストークン(A)をAPIレスポンス生成部12に送信する(ステップO3)。
【0046】
その後、図10(b)に示すように、APIレスポンス生成部12は、アクセストークン発行部20からアクセストークン(A)を受信し(ステップP1)、API利用装置3へ該アクセストークン(A)を含むトークンレスポンスを送信する(ステップP2)。
【0047】
次に、上位API提供装置5は、図2のステップQ,R,Sの処理を実行する。図3(c)に示すように、APIリクエスト処理部11は、API利用装置3からアクセストークン(A)を含むAPIリクエストを受信し(ステップQ1)、アクセストークン検証部21へ該APIリクエストを送信する(ステップQ2)。
【0048】
その後、図13に示すように、アクセストークン検証部21は、APIリクエスト処理部11からAPIリクエストを受信し(ステップR1)、そのAPIリクエストに含まれるアクセストークン(A)がアクセストークン記憶部25のアクセストークンに合致するか否かを確認し(ステップR2)、APIリクエストのパラメータが規定に合致しているか否かを判定する(ステップR3)。そして、アクセストークンが合致し、かつ、パラメータが規定に合致している場合、アクセストークン変換部22へAPIリクエストを送信する(ステップR4)。一方、アクセストークンが合致しない場合、又は、パラメータが規定に合致しない場合、エラー信号を生成してAPI利用装置3へ送信する(ステップR5)。以降、アクセストークン変換部22へAPIリクエストを送信したものとする。
【0049】
その後、図14に示すように、アクセストークン変換部22は、アクセストークン検証部21からアクセストークン(A)を含むアクセストークンAPIリクエストを受信し(ステップS1)、アクセストークン記憶部25へAPI卸元事業者の下位API提供装置7から受信したアクセストークン(B)を問い合わせて取得する(ステップS2)。そして、APIリクエスト内のアクセストークン(A)をアクセストークン(B)に変換し(ステップS3)、API卸元事業者の下位API提供装置7へ変換後のAPIリクエストを送信する(ステップS4)。
【0050】
最後に、上位API提供装置5は、図2のステップTの処理を実行する。図10(c)に示すように、APIレスポンス生成部12は、API卸元事業者の下位API提供装置7からAPIレスポンスを受信し(ステップT1)、API利用装置3へ該APIレスポンスを送信する(ステップT2)。
【0051】
以上より、本実施の形態によれば、API卸売事業者の上位API提供装置5が、API卸元事業者の下位API提供装置7からのAPI使用権委譲の同意要求に対してユーザの同意(同意情報)を代理応答するので、ユーザは複数のAPI提供装置からの各同意要求に応答不要となり、API使用権委譲の同意に係るユーザの負担を軽減し、ユーザやクライアントに対してAPI卸元事業者を隠ぺいすることができる(図18参照)。
【0052】
最後に、本実施の形態で説明した上位API提供装置5は、コンピュータで実現できる。また、上位API提供装置5としてコンピュータを機能させるためのAPI提供プログラム、そのAPI提供プログラムの記憶媒体を作成することも可能である。
【符号の説明】
【0053】
1…エンドユーザ利用端末
3…API利用装置
5…上位API提供装置
7…下位API提供装置
9…リソースサーバ
11…APIリクエスト処理部
12…APIレスポンス生成部
13…認可リクエスト検証部
14…ユーザ認証部
15…APIリクエスト生成部
16…APIレスポンス処理部
17…ユーザ認証応答部
18…認可コード発行部
19…トークンリクエスト検証部
20…アクセストークン発行部
21…アクセストークン検証部
22…アクセストークン変換部
23…ユーザ認証情報記憶部
24…認可コード記憶部
25…アクセストークン記憶部
図1
図2
図3
図4
図5
図6
図7
図8
図9
図10
図11
図12
図13
図14
図15
図16
図17
図18