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

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

▶ みずほ情報総研株式会社の特許一覧
特許6750063サービス管理システム及びサービス管理方法
<>
  • 特許6750063-サービス管理システム及びサービス管理方法 図000002
  • 特許6750063-サービス管理システム及びサービス管理方法 図000003
  • 特許6750063-サービス管理システム及びサービス管理方法 図000004
  • 特許6750063-サービス管理システム及びサービス管理方法 図000005
  • 特許6750063-サービス管理システム及びサービス管理方法 図000006
  • 特許6750063-サービス管理システム及びサービス管理方法 図000007
< >
(19)【発行国】日本国特許庁(JP)
(12)【公報種別】特許公報(B1)
(11)【特許番号】6750063
(24)【登録日】2020年8月14日
(45)【発行日】2020年9月2日
(54)【発明の名称】サービス管理システム及びサービス管理方法
(51)【国際特許分類】
   G06Q 40/02 20120101AFI20200824BHJP
   G06F 21/33 20130101ALI20200824BHJP
【FI】
   G06Q40/02
   G06F21/33
【請求項の数】5
【全頁数】15
(21)【出願番号】特願2019-65309(P2019-65309)
(22)【出願日】2019年3月29日
【審査請求日】2019年3月29日
(73)【特許権者】
【識別番号】592131906
【氏名又は名称】みずほ情報総研株式会社
(73)【特許権者】
【識別番号】592052416
【氏名又は名称】株式会社 みずほ銀行
(73)【特許権者】
【識別番号】390009531
【氏名又は名称】インターナショナル・ビジネス・マシーンズ・コーポレーション
【氏名又は名称原語表記】INTERNATIONAL BUSINESS MACHINES CORPORATION
(74)【代理人】
【識別番号】100105957
【弁理士】
【氏名又は名称】恩田 誠
(74)【代理人】
【識別番号】100068755
【弁理士】
【氏名又は名称】恩田 博宣
(72)【発明者】
【氏名】十川 恵美
(72)【発明者】
【氏名】石川 貴幸
(72)【発明者】
【氏名】矢野 裕和
(72)【発明者】
【氏名】河本 敏孝
(72)【発明者】
【氏名】西本 聡
(72)【発明者】
【氏名】須藤 泰自
(72)【発明者】
【氏名】倉重 圭一
(72)【発明者】
【氏名】▲高▼橋 恵理子
【審査官】 鈴木 和樹
(56)【参考文献】
【文献】 特開2019−8525(JP,A)
【文献】 特開2018−32088(JP,A)
【文献】 早川勝、ほか1名,最終回 FinTechの鍵「API」の作り方 非機能要求の考え方が独特 リスクの見極め方を知ろう,日経SYSTEMS,日本,日経BP社,2017年 2月26日,第287号,p.70−75
【文献】 遠藤圭介、ほか1名,金融分野のAPIエコノミー −オープンAPIが生み出す革新的なサービス−,ITソリューションフロンティア[online],2016年11月25日,第33巻,第8号,p.6−9,Internet<URL:https://www.nri.com/~/media/PDF/jp/opinion/teiki/it_solution/2016/ITSF160802.pdf>
【文献】 大野上総、ほか1名,ビジネスエコシステムを実現するBankVisionのAPI公開,UNISYS TECHNOLOGY REVIEW,日本ユニシス株式会社,2017年 8月31日,第37巻,第2号,p.35−46
【文献】 中村啓佑,OAuth2.0に対する脅威と対策:金融オープンAPIの一段の有効活用に向けて,IMES DISCUSSION PAPER SERIES[online],日本銀行,2017年12月 1日,第2017−J−16号,p.1−28,Internet<URL:http://www.imes.boj.or.jp/research/papers/japanese/17-J-16.pdf>
(58)【調査した分野】(Int.Cl.,DB名)
G06Q 10/00 − 99/00
G06F 21/33
(57)【特許請求の範囲】
【請求項1】
第1サービス提供部に接続され、APIの利用を管理するAPIゲートウェイに接続された第2サービス提供部を含むサービス管理システムであって、
前記第2サービス提供部は、顧客コード、顧客が利用するAPIについてのAPI管理コードに関連付けて、取引可否判定情報を記録したAPI管理情報記憶部を備え、
前記第2サービス提供部が、
顧客を認証した場合、前記顧客が利用するサービスについて、前記顧客の顧客コードに対して、API管理コードを発行し、前記API管理情報記憶部に記録し、
各顧客の顧客状況に応じて、取引可否判定情報を記録し、
前記第1サービス提供部からアクセストークンを取得したAPIゲートウェイから、前記アクセストークンに対応するAPI管理コードを取得し、
前記API管理情報記憶部から、前記API管理コードに関連付けられた取引可否判定情報を取得し、前記取引可否判定情報に基づいて、サービスの提供可否を判定することを特徴とするサービス管理システム。
【請求項2】
前記第2サービス提供部は、顧客コードに関連付けて顧客状況を記録し、
前記API管理情報記憶部には、前記API管理コードに関連付けて、顧客に提供する各サービスを特定するためのサービスコードが記録されており、
前記第2サービス提供部は、前記顧客に対する特定のサービスについての停止情報を取得した場合、前記停止情報を取得したサービスコードに対して取引停止フラグを記録することを特徴とする請求項1に記載のサービス管理システム。
【請求項3】
前記顧客状況において、前記停止情報の解除を検知した場合、前記API管理コードに対して、取引可否判定情報として、API管理コードの要更新フラグを記録することを特徴とする請求項2に記載のサービス管理システム。
【請求項4】
金融サービスを提供する前記第2サービス提供部におけるネットバンキングサービス利用時の顧客コード及びパスワードによる認証に基づいて発行されたアクセストークンを用いることを特徴とする請求項1〜3の何れか一項に記載のサービス管理システム。
【請求項5】
第1サービス提供部に接続され、APIの利用を管理するAPIゲートウェイに接続された第2サービス提供部を含むサービス管理システムを用いて、サービスを管理する方法であって、
前記第2サービス提供部は、顧客コード、顧客が利用するAPIについてのAPI管理コードに関連付けて、取引可否判定情報を記録したAPI管理情報記憶部を備え、
前記第2サービス提供部が、
顧客を認証した場合、前記顧客が利用するサービスについて、前記顧客の顧客コードに対して、API管理コードを発行し、前記API管理情報記憶部に記録し、
各顧客の顧客状況に応じて、取引可否判定情報を記録し、
前記第1サービス提供部からアクセストークンを取得したAPIゲートウェイから、前記アクセストークンに対応するAPI管理コードを取得し、
前記API管理情報記憶部から、前記API管理コードに関連付けられた取引可否判定情報を取得し、前記取引可否判定情報に基づいて、サービスの提供可否を判定することを特徴とするサービス管理方法。
【発明の詳細な説明】
【技術分野】
【0001】
本発明は、利用者に対して、APIを利用してサービスを提供するためのサービス管理システム及びサービス管理方法に関する。
【背景技術】
【0002】
サービス提供サイトから、API(Application Programming Interface)を介して各種情報が提供されつつある。銀行システムから情報を取得するための銀行APIの公開も検討されている(例えば、非特許文献1)。この銀行APIは、残高照会や資金移動等、既存機能を個別にサービス化して、外部のアプリケーションから利用するために使用する。そこで、事業者に対して、APIを利用して会計処理を支援する技術も検討されている(例えば、特許文献1)。
【0003】
また、権限の認可を行うためにOAuthによる認証を用いることもある。このOAuthは、ユーザの代理で、サーバにあるユーザのリソースへのアクセスを許可するための認証用のプロトコルである。OAuthを使用することで、エンドユーザはクライアントにユーザ名やパスワードを知らせることなく、リソースへの第三者アクセスを認可することができる。OAuthでは、ログインのために必要な顧客ID及びパスワードを、ユーザ毎に割り当てるOAuth用トークン(アクセストークン)に置き換える。このOAuth用トークンにより、外部のサービスにはパスワードを知らせることなく、システム間の情報の共有が可能になる。
【先行技術文献】
【特許文献】
【0004】
【特許文献1】特開2016−21147号公報
【非特許文献】
【0005】
【非特許文献1】全国銀行協会、「現代的な「金融業」のあり方」、2016年3月、[online]、金融調査研究会、[平成30年11月14日検索]、インターネット<http://www.zenginkyo.or.jp/fileadmin/res/news/news280341_1.pdf>
【発明の概要】
【発明が解決しようとする課題】
【0006】
アクセストークンを利用する場合、顧客毎にAPIの利用停止や利用停止解除が困難である。また、APIの機能のまとまりであるスコープ毎に利用停止や利用停止解消が困難である。
【課題を解決するための手段】
【0007】
上記課題を解決するために、サービス管理システムは、第1サービス提供部に接続され、APIの利用を管理するAPIゲートウェイに接続された第2サービス提供部を含む。更に、前記第2サービス提供部は、顧客コード、顧客が利用するAPIについてのAPI管理コードに関連付けて、取引可否判定情報を記録したAPI管理情報記憶部を備える。そして、前記第2サービス提供部が、顧客を認証した場合、前記顧客が利用するサービスについて、前記顧客の顧客コードに対して、API管理コードを発行し、前記API管理情報記憶部に記録し、各顧客の顧客状況に応じて、取引可否判定情報を記録し、前記第1サービス提供部からアクセストークンを取得したAPIゲートウェイから、前記アクセストークンに対応するAPI管理コードを取得し、前記API管理情報記憶部から、前記API管理コードに関連付けられた取引可否判定情報を取得し、前記取引可否判定情報に基づいて、サービスの提供可否を判定する。
【発明の効果】
【0008】
本発明によれば、APIを利用して、的確なサービスを提供することができる。
【図面の簡単な説明】
【0009】
図1】本実施形態のシステム概略図。
図2】本実施形態のハードウェア構成の説明図。
図3】本実施形態のデータの説明図であって、(a)は顧客管理情報、(b)はAPIID管理テーブル、(c)はAPI利用履歴情報、(d)は顧客ID、アプリID、サービスコード、APIID、APIID更新フラグ、API取引停止フラグの関係の説明図。
図4】本実施形態の処理手順の説明図。
図5】本実施形態の処理手順の説明図。
図6】本実施形態の処理手順の説明図。
【発明を実施するための形態】
【0010】
以下、図1図6を用いて、サービス管理システムの一実施形態を説明する。
図1に示すように、本実施形態では、ユーザ端末10、サービス提供サーバ20、APIゲートウェイ30、銀行サーバ40、担当者端末50を用いる。
【0011】
(ハードウェア構成の説明)
図2を用いて、ユーザ端末10〜担当者端末50を構成する情報処理装置H10のハードウェア構成を説明する。情報処理装置H10は、通信装置H11、入力装置H12、表示装置H13、記憶部H14、プロセッサH15を備える。なお、このハードウェア構成は一例であり、他のハードウェアにより実現することも可能である。
【0012】
通信装置H11は、他の装置との間で通信経路を確立して、データの送受信を実行するインタフェースであり、例えばネットワークインタフェースカードや無線インタフェース等である。
【0013】
入力装置H12は、利用者等からの入力を受け付ける装置であり、例えばマウスやキーボード等である。表示装置H13は、各種情報を表示するディスプレイ等である。
記憶部H14は、ユーザ端末10〜担当者端末50の各種機能を実行するためのデータや各種プログラムを格納する記憶装置である。記憶部H14の一例としては、ROM、RAM、ハードディスク等がある。
【0014】
プロセッサH15は、記憶部H14に記憶されるプログラムやデータを用いて、ユーザ端末10〜担当者端末50における各処理を制御する。プロセッサH15の一例としては、例えばCPUやMPU等がある。このプロセッサH15は、ROM等に記憶されるプログラムをRAMに展開して、各サービスのための各種プロセスを実行する。
【0015】
プロセッサH15は、自身が実行するすべての処理についてソフトウェア処理を行うものに限られない。例えば、プロセッサH15は、自身が実行する処理の少なくとも一部についてハードウェア処理を行なう専用のハードウェア回路(例えば、特定用途向け集積回路:ASIC)を備えてもよい。すなわち、プロセッサH15は、(1)コンピュータプログラム(ソフトウェア)に従って動作する1つ以上のプロセッサ、(2)各種処理のうち少なくとも一部の処理を実行する1つ以上の専用のハードウェア回路、或いは(3)それらの組み合わせ、を含む回路(circuitry)として構成し得る。プロセッサは、CPU並びに、RAM及びROM等のメモリを含み、メモリは、処理をCPUに実行させるように構成されたプログラムコード又は指令を格納している。メモリすなわちコンピュータ可読媒体は、汎用又は専用のコンピュータでアクセスできるあらゆる利用可能な媒体を含む。
【0016】
(各機能部の説明)
ユーザ端末10は、銀行サーバ40を利用する顧客(ユーザ)が用いるコンピュータ端末である。
【0017】
サービス提供サーバ20は、金融機関が提供する金融サービスを利用して新たなサービスを提供するサービスプロバイダのサーバコンピュータ(第1サービス提供部)である。サービスプロバイダとしては、例えば、インターネットを介して金融サービスを提供する企業(所謂フィンテック企業)等がある。このサービス提供サーバ20は、銀行サーバ40の金融サービスを利用するためのアクセストークン記憶部を備える。このアクセストークン記憶部には、顧客IDに関連付けられ、ユーザが利用する銀行サーバ40の金融サービスについてのアクセストークン、リフレッシュトークンが記録される。
【0018】
APIゲートウェイ30は、APIを管理するゲートウェイサーバである。このAPIゲートウェイ30は、金融サービスAPIを備える。金融サービスAPIは、銀行の顧客に対して各種サービス(例えば、残高照会)を提供する。APIゲートウェイ30は、APIを利用可能なアプリケーションのアプリIDを登録した利用可能アプリテーブルを保持する。更に、APIゲートウェイ30は、発行日時、APIIDに関連付けて、発行したアクセストークン、リフレッシュトークンを記録するトークン情報記憶部を備える。このAPIゲートウェイ30では、サービス提供者(アプリケーション)と顧客との組み合わせを特定するためのAPIIDを基本として使用し、OAuth認証により顧客IDとAPIIDを結びつける。そして、後述するように、このAPIIDを暗号化して含めたアクセストークンを発行する。
【0019】
銀行サーバ40は、顧客に対して金融サービスを提供する銀行のサーバコンピュータ(第2サービス提供部)である。
銀行サーバ40は、制御部41、顧客情報記憶部42、API管理情報記憶部43、API利用情報記憶部44を備える。
【0020】
制御部41は、サービス管理プログラムを実行することにより、ユーザ認証部410、API管理部411、サービス管理部412として機能する。
ユーザ認証部410は、顧客情報記憶部42を用いて、顧客を認証する処理を実行する。
【0021】
API管理部411は、顧客が利用するAPIを管理する処理を実行する。
サービス管理部412は、APIを介して、各種サービスを提供する処理を実行する。本実施形態では、銀行サーバ40は、口座照会API、残高照会API、入出金明細照会API等を用いて、各種情報をサービス提供サーバ20に提供する。
【0022】
図3(a)に示すように、顧客情報記憶部42には、顧客管理情報420が記録される。この顧客管理情報420には、顧客ID、パスワード、口座識別子、取引履歴に関するデータが記録される。
【0023】
顧客IDデータ領域には、各顧客を特定するための識別子に関するデータが記録される。本実施形態では、ネットバンキングサービス利用時に用いる顧客コードを顧客IDとして記録する。
【0024】
パスワードデータ領域には、この顧客を認証するためのパスワードに関するデータが記録される。本実施形態では、ネットバンキングサービス利用時に、本人認証に用いるパスワードを記録する。
【0025】
口座識別子データ領域には、この顧客が保有する口座を特定するための識別子(本支店コード、預金種別、口座番号等)に関するデータが記録される。
取引履歴データ領域には、この顧客との取引履歴に関するデータが記録される。この取引履歴には、パスワード変更、パスワードロック等の顧客状況に関する情報も含まれる。
【0026】
図3(b)に示すように、API管理情報記憶部43には、APIID管理テーブル430が記録される。このAPIID管理テーブル430には、顧客ID、アプリID、サービスコード、APIID、APIID更新フラグ、認可解除日時、APIID更新理由、API取引停止フラグ、停止日時に関するデータが記録される。本実施形態では、APIID更新フラグ及びAPI取引停止フラグを取引可否判定情報として用いる。
【0027】
顧客IDデータ領域には、各顧客を特定するための識別子(顧客コード)に関するデータが記録される。
アプリIDデータ領域には、この顧客が利用するアプリケーションを特定するための識別子に関するデータが記録される。
【0028】
サービスコードデータ領域には、このアプリケーションにおいて、APIを利用するサービスを特定するための識別子に関するデータが記録される。
APIIDデータ領域には、サービス提供者(アプリケーション)のサービスと顧客との組み合わせを特定するための識別子(API管理コード)に関するデータが記録される。
【0029】
APIID更新フラグデータ領域には、APIIDの更新要否を特定するためのフラグが記録される。本実施形態では、このデータ領域には、更新なしフラグ又は要更新フラグのいずれかが記録される。更新なしフラグが記録されている場合にはAPI取引を許容し、要更新フラグが記録されている場合にはAPI取引を拒否する。要更新フラグが記録されている場合、API取引を再開するためには、改めてOAuth認証(API利用のための本人認証)が必要となる。ここで、新たなOAuth認証要求によりOAuth認証を完了した場合にはAPI利用を再開できる。
認可解除日時データ領域には、APIの利用認可を解除した年月日に関するデータが記録される。
【0030】
APIID更新理由データ領域には、APIIDの更新理由を特定するための識別子に関するデータが記録される。APIIDの更新理由としては、APIに起因する理由や顧客側に起因する理由、バックオフィスに起因する理由がある。APIに起因する理由としては、APIのリボーク(無効化)等がある。顧客側に起因する理由としては、パスワード変更、パスワードロック等がある。バックオフィスに起因する理由としては、バックオフィスからの停止解除指示等がある。
【0031】
API取引停止フラグデータ領域には、APIを用いて取引の可否を判定するためのフラグが記録される。本実施形態では、このデータ領域には、取引停止判定フラグとして、停止解除フラグ又は停止フラグのいずれかが記録される。停止解除フラグが記録されている場合にはAPI取引を許容し、停止フラグが記録されている場合にはAPI取引を拒否する。API取引停止フラグは、顧客の要望やバックオフィスの判断により設定される。API取引利用停止フラグを停止解除フラグに変更した場合、APIID更新フラグが記録され、その後、OAuth認証を完了した場合にはAPI利用を再開できる。
停止日時データ領域には、APIの利用を停止した年月日及び時刻に関するデータが記録される。
【0032】
図3(c)に示すように、API利用情報記憶部44には、API利用履歴情報440が記録される。このAPI利用履歴情報440には、APIID、アプリID、サービスコード、利用日時に関する情報が記録される。
【0033】
APIIDデータ領域には、サービス提供者(アプリケーション)のサービスと顧客との組み合わせを特定するための識別子(API管理コード)に関するデータが記録される。
アプリIDデータ領域には、この顧客が利用するアプリケーションを特定するための識別子に関するデータが記録される。
【0034】
サービスコードデータ領域には、APIを利用したサービスを特定するための識別子に関するデータが記録される。
利用日時データ領域には、APIを利用した年月日及び時刻に関するデータが記録される。
【0035】
図3(d)に示すように、顧客IDに対して、顧客が利用する複数のアプリケーションについてのアプリIDを設定することができる。更に、各アプリIDに対して、APIを利用するサービスを特定するための複数のサービスコードを関連付ける。更に、各サービスコードに対して、APIIDが関連付けられ、各APIIDに対してAPIID更新フラグ、API取引停止フラグを設定することができる。このAPIID更新フラグ、API取引停止フラグにより、顧客に提供するサービス毎にAPIを利用した取引を制御する。APIゲートウェイ30では、外部企業毎の管理は可能であるが、顧客毎にサービス停止をできない。一方、APIID更新フラグ、API取引停止フラグにより、顧客毎にサービス提供可否を制御することができる。ここで、APIID更新フラグを用いることにより、取引を再開するためには、改めてOAuth認証(API利用のための本人認証)を要求する。例えば、パスワードを変更する場合には、APIID更新フラグにより、有効なアクセストークンの利用を停止し、再度アクセストークンを再発行させることができる。また、API取引停止フラグにより、アクセストークンが有効な場合にも、APIの利用を制御することができる。
【0036】
また、図1に示すように、銀行サーバ40には、担当者端末50が接続される。担当者端末50は、銀行のバックオフィスの担当者が用いるコンピュータ端末である。
【0037】
(アクセストークンの発行処理)
まず、図4を用いて、アクセストークンの発行処理を説明する。
まず、ユーザ端末10は、OAuth認証リクエスト処理を実行する(ステップS1−1)。具体的には、サービス提供サーバ20を利用する場合には、ユーザは、ユーザ端末10を用いて、サービス提供サーバ20にアクセスする。そして、ユーザ端末10は、OAuth認証要求を送信する。
次に、サービス提供サーバ20は、リダイレクト要求処理を実行する(ステップS1−2)。具体的には、サービス提供サーバ20は、ユーザ端末10に対して、リダイレクト要求を送信する。このリダイレクト要求には、リダイレクト先(APIゲートウェイ30)のアドレス、サービス提供サーバ20を特定するためのアプリIDに関する情報を含める。このアプリIDにより、サービス提供サーバ20を用いるサービス提供者を特定することができる。そして、リダイレクト要求を受信したユーザ端末10は、APIゲートウェイ30にリダイレクトする。
【0038】
次に、APIゲートウェイ30は、アプリ認証処理を実行する(ステップS1−3)。具体的には、APIゲートウェイ30は、リダイレクト要求に含まれるアプリIDが利用可能アプリテーブルに記録されているかどうかを確認する。利用可能アプリテーブルにアプリIDが記録されている場合には、APIを利用可能なアプリと判定する。
【0039】
利用可能アプリと判定したAPIゲートウェイ30は、リダイレクト要求処理を実行する(ステップS1−4)。具体的には、APIゲートウェイ30は、ユーザ端末10に対して、リダイレクト要求を送信する。このリダイレクト要求には、リダイレクト先(銀行サーバ40)のアドレス、ユーザ認証要求に関する情報を含める。そして、リダイレクト要求を受信したユーザ端末10は、銀行サーバ40にリダイレクトする。
【0040】
次に、銀行サーバ40の制御部41は、認証画面の送信処理を実行する(ステップS1−5)。具体的には、制御部41のユーザ認証部410は、ユーザ端末10に対して認証画面を送信する。この認証画面には、顧客ID、パスワードの入力欄が設けられている。
【0041】
次に、ユーザ端末10は、認証画面の出力処理を実行する(ステップS1−6)。具体的には、ユーザ端末10は、ディスプレイに認証画面を出力する。
次に、ユーザ端末10は、顧客ID、パスワードの送信処理を実行する(ステップS1−7)。具体的には、ユーザ端末10は、認証画面に入力された顧客ID、パスワードを、銀行サーバ40に送信する。
【0042】
次に、銀行サーバ40の制御部41は、認証処理を実行する(ステップS1−8)。具体的には、制御部41のユーザ認証部410は、ユーザ端末10から取得した顧客ID、パスワードが顧客情報記憶部42に記録されているかどうかを確認する。顧客ID、パスワードが記録されている場合には、認証を完了する。一方、顧客ID、パスワードが記録されておらず、認証を完了できない場合には、エラーメッセージをユーザ端末10に送信する。
【0043】
次に、銀行サーバ40の制御部41は、認可画面の送信処理を実行する(ステップS1−9)。具体的には、制御部41のユーザ認証部410は、ユーザ端末10に認可画面を送信する。この認可画面には、APIの利用を希望するサービス内容(スコープ)の設定欄が設けられている。
【0044】
次に、ユーザ端末10は、認可画面の出力処理を実行する(ステップS1−10)。具体的には、ユーザ端末10は、ディスプレイに認可画面を出力する。
次に、ユーザ端末10は、認可スコープ送信処理を実行する(ステップS1−11)。具体的には、ユーザ端末10は、認可画面において設定された認可スコープを含めたAPIID発行要求を銀行サーバ40に送信する。
【0045】
次に、銀行サーバ40の制御部41は、APIIDの発行処理を実行する(ステップS1−12)。具体的には、制御部41のAPI管理部411は、APIIDを発行し、顧客コード、アプリIDに関連付けたAPIID管理テーブル430を生成し、API管理情報記憶部43に記録する。更に、API管理部411は、ユーザ端末10から取得したスコープ(サービスコード)を、APIID管理テーブル430に記録する。なお、初期段階では、APIID更新フラグデータ領域には、更新なしフラグを記録する。また、認可解除日時、APIID更新理由、API取引停止フラグ、停止日時の各データ領域は空欄にしておく。そして、API管理部411は、APIゲートウェイ30に対して、APIID発行メッセージを送信する。
【0046】
次に、図5に示すように、APIID発行メッセージを受信したAPIゲートウェイ30は、認可コード発行処理を実行する(ステップS2−1)。具体的には、APIゲートウェイ30は、認可コードを発行する。
【0047】
次に、APIゲートウェイ30は、リダイレクト要求処理を実行する(ステップS2−2)。具体的には、APIゲートウェイ30は、ユーザ端末10に対して、リダイレクト要求を送信する。このリダイレクト要求には、リダイレクト先(サービス提供サーバ20)のアドレス、認可コードに関する情報を含める。そして、ユーザ端末10は、サービス提供サーバ20にリダイレクトする。
【0048】
次に、サービス提供サーバ20は、アクセストークン発行要求処理を実行する(ステップS2−3)。具体的には、サービス提供サーバ20は、APIゲートウェイ30に対してアクセストークン発行要求を送信する。このアクセストークン発行要求には、認可コードを含める。
【0049】
次に、アクセストークン発行要求を取得したAPIゲートウェイ30は、アクセストークン発行処理を実行する(ステップS2−4)。具体的には、APIゲートウェイ30は、アクセストークンを生成する。この場合、APIゲートウェイ30は、APIIDを暗号化してアクセストークンに含める。そして、APIゲートウェイ30は、発行したアクセストークンを、発行日時に関連付けてトークン情報記憶部に記録する。
【0050】
次に、APIゲートウェイ30は、リフレッシュトークン発行処理を実行する(ステップS2−5)。具体的には、APIゲートウェイ30は、アクセストークンを再発行するためのリフレッシュトークンを生成する。そして、APIゲートウェイ30は、発行したリフレッシュトークンを、発行日時に関連付けてトークン情報記憶部に記録する。次に、APIゲートウェイ30は、サービス提供サーバ20に対して、アクセストークン、リフレッシュトークンを送信する。
【0051】
次に、サービス提供サーバ20は、アクセストークン連携処理を実行する(ステップS2−6)。具体的には、サービス提供サーバ20は、アクセストークン情報記憶部に、顧客IDに関連付けて、アクセストークン、リフレッシュトークンを記録する。
【0052】
(API管理処理)
次に、図5を用いて、API管理処理を説明する。
ここでは、銀行サーバ40の制御部41は、ステータス管理処理を実行する(ステップS3−1)。具体的には、制御部41のAPI管理部411は、定期的に顧客情報記憶部42にアクセスし、顧客管理情報420の取引履歴において顧客状況を確認する。顧客管理情報420の顧客状況において、パスワード変更、パスワードロック等のサービス利用停止と判定した場合には、API管理部411は、APIID更新フラグ(要更新フラグ)をAPIID管理テーブル430に記録する。更に、API管理部411は、APIID管理テーブル430に認可解除日時、APIID更新理由を記録する。
【0053】
また、銀行サーバ40の制御部41は、バックオフィス対応処理を実行する(ステップS3−2)。具体的には、顧客からAPIの利用について停止要望を取得した場合や、担当者がAPIの利用停止を判断した場合には、バックオフィスの担当者は、担当者端末50を用いて、銀行サーバ40にアクセスする。制御部41のAPI管理部411は、担当者端末50からAPIの利用停止情報を取得した場合には、APIID管理テーブル430のAPI取引停止フラグデータ領域に停止フラグを記録する。この場合、API管理部411は、APIID管理テーブル430に停止日時を記録する。
【0054】
また、銀行サーバ40の制御部41は、履歴確認処理を実行する(ステップS3−3)。具体的には、必要に応じて、バックオフィスの担当者が、APIの利用状況を確認する場合、担当者端末50において、APIIDを指定する。そして、担当者端末50を用いて、銀行サーバ40にアクセスし、APIIDを指定した履歴確認要求を送信する。この場合、制御部41のAPI管理部411は、指定されたAPIIDのAPI利用履歴情報440をAPI利用情報記憶部44から取得する。そして、API管理部411は、取得したAPI利用履歴情報440を担当者端末50に出力する。
【0055】
(サービス提供時処理)
次に、図6を用いて、サービス提供時処理を説明する。
まず、ユーザ端末10は、API利用処理を実行する(ステップS4−1)。具体的には、ユーザが、APIを利用して、サービス提供者のサービスを利用する場合には、サービス提供サーバ20にアクセスする。
【0056】
次に、サービス提供サーバ20は、API利用要求処理を実行する(ステップS4−2)。具体的には、サービス提供サーバ20は、APIゲートウェイ30に対してAPI利用要求を送信する。このAPI利用要求には、ユーザのアクセストークンを含める。
【0057】
次に、APIゲートウェイ30は、アクセストークン検証処理を実行する(ステップS4−3)。具体的には、APIゲートウェイ30は、トークン情報記憶部にアクセストークンが登録されているかどうかを確認する。
【0058】
次に、APIゲートウェイ30は、有効期限内かどうかについての判定処理を実行する(ステップS4−4)。具体的には、APIゲートウェイ30は、トークン情報記憶部に記録されている発行日時からの経過時間を算出する。経過時間が有効期間を経過していない場合には、有効期限内と判定する。
【0059】
有効期限内でないと判定した場合(ステップS4−4において「NO」の場合)、APIゲートウェイ30は、エラー応答処理を実行する(ステップS4−5)。具体的には、APIゲートウェイ30は、サービス提供サーバ20に対してエラーメッセージを送信する。この場合、サービス提供サーバ20は、リフレッシュトークンをAPIゲートウェイ30に送信し、新たなアクセストークンを取得する。
【0060】
一方、有効期限内と判定した場合(ステップS4−4において「YES」の場合)、APIゲートウェイ30は、APIIDの抽出処理を実行する(ステップS4−6)。具体的には、APIゲートウェイ30は、アクセストークンを復号してAPIIDを取得する。
【0061】
次に、APIゲートウェイ30は、APIIDの送信処理を実行する(ステップS4−7)。具体的には、APIゲートウェイ30は、抽出したAPIIDを含めたAPI利用要求を銀行サーバ40に送信する。
【0062】
次に、銀行サーバ40の制御部41は、APIIDの確認処理を実行する(ステップS4−8)。具体的には、制御部41のAPI管理部411は、APIIDに基づき、API管理情報記憶部43に記録されたAPIID管理テーブル430を特定する。
【0063】
次に、銀行サーバ40の制御部41は、API利用可能かどうかについての判定処理を実行する(ステップS4−9)。具体的には、制御部41のAPI管理部411は、APIID管理テーブル430のAPIID更新フラグ、API取引利用停止フラグを確認する。そして、API管理部411は、APIID管理テーブル430に要更新フラグ及び停止フラグが記録されていない場合にはAPI利用可能と判定する。一方、APIID管理テーブル430に要更新フラグ、停止フラグの少なくとも何れかが記録されている場合には、API利用不可と判定する。
【0064】
API利用不可と判定した場合(ステップS4−9において「NO」の場合)、銀行サーバ40の制御部41は、エラー応答処理を実行する(ステップS4−10)。具体的には、制御部41のAPI管理部411は、APIゲートウェイ30を介して、サービス提供サーバ20にエラーメッセージを返信する。
【0065】
一方、API利用可能と判定した場合(ステップS4−9において「YES」の場合)、銀行サーバ40の制御部41は、正常応答処理を実行する(ステップS4−11)。具体的には、銀行サーバ40の制御部41は、API利用履歴情報440を生成し、API利用情報記憶部44に記録する。次に、サービス管理部412は、サービスコードに応じたサービスを実行する。例えば、残高照会サービスの場合、サービス管理部412は、顧客IDに関連付けられた口座識別子の口座残高を取得する。そして、サービス管理部412は、このサービス結果(例えば、口座残高)を、APIゲートウェイ30を介して、サービス提供サーバ20に返信する。
【0066】
以上、本実施形態によれば、以下のような効果を得ることができる。
(1)本実施形態では、銀行サーバ40の制御部41は、APIIDの発行処理を実行する(ステップS1−12)。ここでは、銀行サーバ40の制御部41は、ステータス管理処理を実行する(ステップS3−1)。これにより、顧客とサービス提供者とを関連付けた識別子により、API利用を制御することができる。
【0067】
(2)本実施形態では、銀行サーバ40の制御部41は、バックオフィス対応処理を実行する(ステップS3−2)。これにより、顧客とサービス提供者との関係に基づいて、顧客からの要望や銀行の判断に応じて、API利用を制御することができる。
【0068】
(3)本実施形態では、銀行サーバ40の制御部41は、履歴確認処理を実行する(ステップS3−3)。これにより、サービス提供者やサービス毎に、APIの利用状況を確認することができる。
【0069】
(4)本実施形態では、銀行サーバ40の制御部41は、API利用可能かどうかについての判定処理を実行する(ステップS4−9)。これにより、顧客状況や銀行サーバ40のサービス提供状況に応じて、API利用の可否を判定することができる。
【0070】
本実施形態は、以下のように変更して実施することができる。本実施形態及び以下の変更例は、技術的に矛盾しない範囲で互いに組み合わせて実施することができる。
・上記実施形態では、OAuth認証に用いる項目は、ネットバンキングサービス利用時に用いる顧客ID、パスワードに限定されるものではない。例えば、キャッシュカード利用時に用いる顧客番号、暗証番号や、顧客の生体情報を用いたFIDO(登録商標)も利用可能である。
【0071】
・上記実施形態では、銀行サーバ40の制御部41は、ステータス管理処理(ステップS3−1)、バックオフィス対応処理(ステップS3−2)を実行する。ここで、複数のサービスコードや、複数のAPIIDを関連付けておくことにより、所定のサービス、APIを停止した場合、関連付けられたサービスやAPIも停止するようにしてもよい。この場合には、API管理情報記憶部43において、関連する複数のサービスコードや、複数のAPIIDを関連付けた関連API管理テーブルを記録しておく。そして、API管理部411は、サービスやAPIの停止を検知した場合、関連API管理テーブルを用いて、関連するサービスコードやAPIIDを特定し、APIID更新フラグデータ領域に要更新フラグ、API取引停止フラグデータ領域に停止フラグを記録する。
【0072】
・上記実施形態では、銀行サーバ40における金融サービスの利用に適用したが、適用対象は金融サービスに限定されるものではなく、各種サービスに適用することができる。
【符号の説明】
【0073】
10…ユーザ端末、20…サービス提供サーバ、30…APIゲートウェイ、40…銀行サーバ、41…制御部、42…顧客情報記憶部、43…API管理情報記憶部、44…API利用情報記憶部、50…担当者端末。
【要約】
【課題】APIを利用して、的確なサービスを提供するためのサービス管理システム及びサービス管理方法を提供する。
【解決手段】銀行サーバ40は、顧客コード、顧客が利用するAPIについてのAPI管理コードに関連付けて、取引可否判定情報を記録したAPI管理情報記憶部43を備える。銀行サーバ40が、顧客を認証した場合、顧客が利用するサービスについて、顧客の顧客コードに対して、API管理コードを発行し、API管理情報記憶部43に記録し、各顧客の顧客状況に応じて、取引可否判定情報を記録し、サービス提供サーバ20からアクセストークンを取得したAPIゲートウェイ30から、アクセストークンに対応するAPI管理コードを取得し、API管理情報記憶部43から、API管理コードに関連付けられた取引可否判定情報を取得し、取引可否判定情報に基づいて、サービスの提供可否を判定する。
【選択図】図1
図1
図2
図3
図4
図5
図6