(57)【要約】【課題】ＡＰＩを利用して、的確なサービスを提供するためのサービス管理システム及びサービス管理方法を提供する。【解決手段】銀行サーバ４０は、顧客コード、顧客が利用するＡＰＩについてのＡＰＩ管理コードに関連付けて、取引可否判定情報を記録したＡＰＩ管理情報記憶部４３を備える。銀行サーバ４０が、顧客を認証した場合、顧客が利用するサービスについて、顧客の顧客コードに対して、ＡＰＩ管理コードを発行し、ＡＰＩ管理情報記憶部４３に記録し、各顧客の顧客状況に応じて、取引可否判定情報を記録し、サービス提供サーバ２０からアクセストークンを取得したＡＰＩゲートウェイ３０から、アクセストークンに対応するＡＰＩ管理コードを取得し、ＡＰＩ管理情報記憶部４３から、ＡＰＩ管理コードに関連付けられた取引可否判定情報を取得し、取引可否判定情報に基づいて、サービスの提供可否を判定する。【選択図】図１
2020166469.tif 000002
【特許請求の範囲】
【請求項１】
第１サービス提供部に接続され、ＡＰＩの利用を管理するＡＰＩゲートウェイに接続された第２サービス提供部を含むサービス管理システムであって、
前記第２サービス提供部は、顧客コード、顧客が利用するＡＰＩについてのＡＰＩ管理コードに関連付けて、取引可否判定情報を記録したＡＰＩ管理情報記憶部を備え、
前記第２サービス提供部が、
顧客を認証した場合、前記顧客が利用するサービスについて、前記顧客の顧客コードに対して、ＡＰＩ管理コードを発行し、前記ＡＰＩ管理情報記憶部に記録し、
各顧客の顧客状況に応じて、取引可否判定情報を記録し、
前記第１サービス提供部からアクセストークンを取得したＡＰＩゲートウェイから、前記アクセストークンに対応するＡＰＩ管理コードを取得し、
前記ＡＰＩ管理情報記憶部から、前記ＡＰＩ管理コードに関連付けられた取引可否判定情報を取得し、前記取引可否判定情報に基づいて、サービスの提供可否を判定することを特徴とするサービス管理システム。
【請求項２】
前記第２サービス提供部は、顧客コードに関連付けて顧客状況を記録し、
前記ＡＰＩ管理情報記憶部には、前記ＡＰＩ管理コードに関連付けて、顧客に提供する各サービスを特定するためのサービスコードが記録されており、
前記第２サービス提供部は、前記顧客に対する特定のサービスについての停止情報を取得した場合、前記停止情報を取得したサービスコードに対して取引停止フラグを記録することを特徴とする請求項１に記載のサービス管理システム。
【請求項３】
前記顧客状況において、前記停止情報の解除を検知した場合、前記ＡＰＩ管理コードに対して、取引可否判定情報として、ＡＰＩ管理コードの要更新フラグを記録することを特徴とする請求項２に記載のサービス管理システム。
【請求項４】
金融サービスを提供する前記第２サービス提供部におけるネットバンキングサービス利用時の顧客コード及びパスワードによる認証に基づいて発行されたアクセストークンを用いることを特徴とする請求項１〜３の何れか一項に記載のサービス管理システム。
【請求項５】
第１サービス提供部に接続され、ＡＰＩの利用を管理するＡＰＩゲートウェイに接続された第２サービス提供部を含むサービス管理システムを用いて、サービスを管理する方法であって、
前記第２サービス提供部は、顧客コード、顧客が利用するＡＰＩについてのＡＰＩ管理コードに関連付けて、取引可否判定情報を記録したＡＰＩ管理情報記憶部を備え、
前記第２サービス提供部が、
顧客を認証した場合、前記顧客が利用するサービスについて、前記顧客の顧客コードに対して、ＡＰＩ管理コードを発行し、前記ＡＰＩ管理情報記憶部に記録し、
各顧客の顧客状況に応じて、取引可否判定情報を記録し、
前記第１サービス提供部からアクセストークンを取得したＡＰＩゲートウェイから、前記アクセストークンに対応するＡＰＩ管理コードを取得し、
前記ＡＰＩ管理情報記憶部から、前記ＡＰＩ管理コードに関連付けられた取引可否判定情報を取得し、前記取引可否判定情報に基づいて、サービスの提供可否を判定することを特徴とするサービス管理方法。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、利用者に対して、ＡＰＩを利用してサービスを提供するためのサービス管理システム及びサービス管理方法に関する。
【背景技術】
【０００２】
サービス提供サイトから、ＡＰＩ（Application Programming Interface）を介して各種情報が提供されつつある。銀行システムから情報を取得するための銀行ＡＰＩの公開も検討されている（例えば、非特許文献１）。この銀行ＡＰＩは、残高照会や資金移動等、既存機能を個別にサービス化して、外部のアプリケーションから利用するために使用する。そこで、事業者に対して、ＡＰＩを利用して会計処理を支援する技術も検討されている（例えば、特許文献１）。
【０００３】
また、権限の認可を行うためにOAuthによる認証を用いることもある。このOAuthは、ユーザの代理で、サーバにあるユーザのリソースへのアクセスを許可するための認証用のプロトコルである。OAuthを使用することで、エンドユーザはクライアントにユーザ名やパスワードを知らせることなく、リソースへの第三者アクセスを認可することができる。OAuthでは、ログインのために必要な顧客ＩＤ及びパスワードを、ユーザ毎に割り当てるOAuth用トークン（アクセストークン）に置き換える。このOAuth用トークンにより、外部のサービスにはパスワードを知らせることなく、システム間の情報の共有が可能になる。
【先行技術文献】
【特許文献】
【０００４】
【特許文献１】特開２０１６−２１１４７号公報
【非特許文献】
【０００５】
【非特許文献１】全国銀行協会、「現代的な「金融業」のあり方」、２０１６年３月、［online］、金融調査研究会、［平成３０年１１月１４日検索］、インターネット＜http://www.zenginkyo.or.jp/fileadmin/res/news/news280341_1.pdf＞
【発明の概要】
【発明が解決しようとする課題】
【０００６】
アクセストークンを利用する場合、顧客毎にＡＰＩの利用停止や利用停止解除が困難である。また、ＡＰＩの機能のまとまりであるスコープ毎に利用停止や利用停止解消が困難である。
【課題を解決するための手段】
【０００７】
上記課題を解決するために、サービス管理システムは、第１サービス提供部に接続され、ＡＰＩの利用を管理するＡＰＩゲートウェイに接続された第２サービス提供部を含む。更に、前記第２サービス提供部は、顧客コード、顧客が利用するＡＰＩについてのＡＰＩ管理コードに関連付けて、取引可否判定情報を記録したＡＰＩ管理情報記憶部を備える。そして、前記第２サービス提供部が、顧客を認証した場合、前記顧客が利用するサービスについて、前記顧客の顧客コードに対して、ＡＰＩ管理コードを発行し、前記ＡＰＩ管理情報記憶部に記録し、各顧客の顧客状況に応じて、取引可否判定情報を記録し、前記第１サービス提供部からアクセストークンを取得したＡＰＩゲートウェイから、前記アクセストークンに対応するＡＰＩ管理コードを取得し、前記ＡＰＩ管理情報記憶部から、前記ＡＰＩ管理コードに関連付けられた取引可否判定情報を取得し、前記取引可否判定情報に基づいて、サービスの提供可否を判定する。
【発明の効果】
【０００８】
本発明によれば、ＡＰＩを利用して、的確なサービスを提供することができる。
【図面の簡単な説明】
【０００９】
【図１】本実施形態のシステム概略図。
【図２】本実施形態のハードウェア構成の説明図。
【図３】本実施形態のデータの説明図であって、（ａ）は顧客管理情報、（ｂ）はＡＰＩＩＤ管理テーブル、（ｃ）はＡＰＩ利用履歴情報、（ｄ）は顧客ＩＤ、アプリＩＤ、サービスコード、ＡＰＩＩＤ、ＡＰＩＩＤ更新フラグ、ＡＰＩ取引停止フラグの関係の説明図。
【図４】本実施形態の処理手順の説明図。
【図５】本実施形態の処理手順の説明図。
【図６】本実施形態の処理手順の説明図。
【発明を実施するための形態】
【００１０】
以下、図１〜図６を用いて、サービス管理システムの一実施形態を説明する。
図１に示すように、本実施形態では、ユーザ端末１０、サービス提供サーバ２０、ＡＰＩゲートウェイ３０、銀行サーバ４０、担当者端末５０を用いる。
【００１１】
（ハードウェア構成の説明）
図２を用いて、ユーザ端末１０〜担当者端末５０を構成する情報処理装置Ｈ１０のハードウェア構成を説明する。情報処理装置Ｈ１０は、通信装置Ｈ１１、入力装置Ｈ１２、表示装置Ｈ１３、記憶部Ｈ１４、プロセッサＨ１５を備える。なお、このハードウェア構成は一例であり、他のハードウェアにより実現することも可能である。
【００１２】
通信装置Ｈ１１は、他の装置との間で通信経路を確立して、データの送受信を実行するインタフェースであり、例えばネットワークインタフェースカードや無線インタフェース等である。
【００１３】
入力装置Ｈ１２は、利用者等からの入力を受け付ける装置であり、例えばマウスやキーボード等である。表示装置Ｈ１３は、各種情報を表示するディスプレイ等である。
記憶部Ｈ１４は、ユーザ端末１０〜担当者端末５０の各種機能を実行するためのデータや各種プログラムを格納する記憶装置である。記憶部Ｈ１４の一例としては、ＲＯＭ、ＲＡＭ、ハードディスク等がある。
【００１４】
プロセッサＨ１５は、記憶部Ｈ１４に記憶されるプログラムやデータを用いて、ユーザ端末１０〜担当者端末５０における各処理を制御する。プロセッサＨ１５の一例としては、例えばＣＰＵやＭＰＵ等がある。このプロセッサＨ１５は、ＲＯＭ等に記憶されるプログラムをＲＡＭに展開して、各サービスのための各種プロセスを実行する。
【００１５】
プロセッサＨ１５は、自身が実行するすべての処理についてソフトウェア処理を行うものに限られない。例えば、プロセッサＨ１５は、自身が実行する処理の少なくとも一部についてハードウェア処理を行なう専用のハードウェア回路（例えば、特定用途向け集積回路：ＡＳＩＣ）を備えてもよい。すなわち、プロセッサＨ１５は、（１）コンピュータプログラム（ソフトウェア）に従って動作する１つ以上のプロセッサ、（２）各種処理のうち少なくとも一部の処理を実行する１つ以上の専用のハードウェア回路、或いは（３）それらの組み合わせ、を含む回路（circuitry）として構成し得る。プロセッサは、ＣＰＵ並びに、ＲＡＭ及びＲＯＭ等のメモリを含み、メモリは、処理をＣＰＵに実行させるように構成されたプログラムコード又は指令を格納している。メモリすなわちコンピュータ可読媒体は、汎用又は専用のコンピュータでアクセスできるあらゆる利用可能な媒体を含む。
【００１６】
（各機能部の説明）
ユーザ端末１０は、銀行サーバ４０を利用する顧客（ユーザ）が用いるコンピュータ端末である。
【００１７】
サービス提供サーバ２０は、金融機関が提供する金融サービスを利用して新たなサービスを提供するサービスプロバイダのサーバコンピュータ（第１サービス提供部）である。サービスプロバイダとしては、例えば、インターネットを介して金融サービスを提供する企業（所謂フィンテック企業）等がある。このサービス提供サーバ２０は、銀行サーバ４０の金融サービスを利用するためのアクセストークン記憶部を備える。このアクセストークン記憶部には、顧客ＩＤに関連付けられ、ユーザが利用する銀行サーバ４０の金融サービスについてのアクセストークン、リフレッシュトークンが記録される。
【００１８】
ＡＰＩゲートウェイ３０は、ＡＰＩを管理するゲートウェイサーバである。このＡＰＩゲートウェイ３０は、金融サービスＡＰＩを備える。金融サービスＡＰＩは、銀行の顧客に対して各種サービス（例えば、残高照会）を提供する。ＡＰＩゲートウェイ３０は、ＡＰＩを利用可能なアプリケーションのアプリＩＤを登録した利用可能アプリテーブルを保持する。更に、ＡＰＩゲートウェイ３０は、発行日時、ＡＰＩＩＤに関連付けて、発行したアクセストークン、リフレッシュトークンを記録するトークン情報記憶部を備える。このＡＰＩゲートウェイ３０では、サービス提供者（アプリケーション）と顧客との組み合わせを特定するためのＡＰＩＩＤを基本として使用し、OAuth認証により顧客ＩＤとＡＰＩＩＤを結びつける。そして、後述するように、このＡＰＩＩＤを暗号化して含めたアクセストークンを発行する。
【００１９】
銀行サーバ４０は、顧客に対して金融サービスを提供する銀行のサーバコンピュータ（第２サービス提供部）である。
銀行サーバ４０は、制御部４１、顧客情報記憶部４２、ＡＰＩ管理情報記憶部４３、ＡＰＩ利用情報記憶部４４を備える。
【００２０】
制御部４１は、サービス管理プログラムを実行することにより、ユーザ認証部４１０、ＡＰＩ管理部４１１、サービス管理部４１２として機能する。
ユーザ認証部４１０は、顧客情報記憶部４２を用いて、顧客を認証する処理を実行する。
【００２１】
ＡＰＩ管理部４１１は、顧客が利用するＡＰＩを管理する処理を実行する。
サービス管理部４１２は、ＡＰＩを介して、各種サービスを提供する処理を実行する。本実施形態では、銀行サーバ４０は、口座照会ＡＰＩ、残高照会ＡＰＩ、入出金明細照会ＡＰＩ等を用いて、各種情報をサービス提供サーバ２０に提供する。
【００２２】
図３（ａ）に示すように、顧客情報記憶部４２には、顧客管理情報４２０が記録される。この顧客管理情報４２０には、顧客ＩＤ、パスワード、口座識別子、取引履歴に関するデータが記録される。
【００２３】
顧客ＩＤデータ領域には、各顧客を特定するための識別子に関するデータが記録される。本実施形態では、ネットバンキングサービス利用時に用いる顧客コードを顧客ＩＤとして記録する。
【００２４】
パスワードデータ領域には、この顧客を認証するためのパスワードに関するデータが記録される。本実施形態では、ネットバンキングサービス利用時に、本人認証に用いるパスワードを記録する。
【００２５】
口座識別子データ領域には、この顧客が保有する口座を特定するための識別子（本支店コード、預金種別、口座番号等）に関するデータが記録される。
取引履歴データ領域には、この顧客との取引履歴に関するデータが記録される。この取引履歴には、パスワード変更、パスワードロック等の顧客状況に関する情報も含まれる。
【００２６】
図３（ｂ）に示すように、ＡＰＩ管理情報記憶部４３には、ＡＰＩＩＤ管理テーブル４３０が記録される。このＡＰＩＩＤ管理テーブル４３０には、顧客ＩＤ、アプリＩＤ、サービスコード、ＡＰＩＩＤ、ＡＰＩＩＤ更新フラグ、認可解除日時、ＡＰＩＩＤ更新理由、ＡＰＩ取引停止フラグ、停止日時に関するデータが記録される。本実施形態では、ＡＰＩＩＤ更新フラグ及びＡＰＩ取引停止フラグを取引可否判定情報として用いる。
【００２７】
顧客ＩＤデータ領域には、各顧客を特定するための識別子（顧客コード）に関するデータが記録される。
アプリＩＤデータ領域には、この顧客が利用するアプリケーションを特定するための識別子に関するデータが記録される。
【００２８】
サービスコードデータ領域には、このアプリケーションにおいて、ＡＰＩを利用するサービスを特定するための識別子に関するデータが記録される。
ＡＰＩＩＤデータ領域には、サービス提供者（アプリケーション）のサービスと顧客との組み合わせを特定するための識別子（ＡＰＩ管理コード）に関するデータが記録される。
【００２９】
ＡＰＩＩＤ更新フラグデータ領域には、ＡＰＩＩＤの更新要否を特定するためのフラグが記録される。本実施形態では、このデータ領域には、更新なしフラグ又は要更新フラグのいずれかが記録される。更新なしフラグが記録されている場合にはＡＰＩ取引を許容し、要更新フラグが記録されている場合にはＡＰＩ取引を拒否する。要更新フラグが記録されている場合、ＡＰＩ取引を再開するためには、改めてOAuth認証（ＡＰＩ利用のための本人認証）が必要となる。ここで、新たなOAuth認証要求によりOAuth認証を完了した場合にはＡＰＩ利用を再開できる。
認可解除日時データ領域には、ＡＰＩの利用認可を解除した年月日に関するデータが記録される。
【００３０】
ＡＰＩＩＤ更新理由データ領域には、ＡＰＩＩＤの更新理由を特定するための識別子に関するデータが記録される。ＡＰＩＩＤの更新理由としては、ＡＰＩに起因する理由や顧客側に起因する理由、バックオフィスに起因する理由がある。ＡＰＩに起因する理由としては、ＡＰＩのリボーク（無効化）等がある。顧客側に起因する理由としては、パスワード変更、パスワードロック等がある。バックオフィスに起因する理由としては、バックオフィスからの停止解除指示等がある。
【００３１】
ＡＰＩ取引停止フラグデータ領域には、ＡＰＩを用いて取引の可否を判定するためのフラグが記録される。本実施形態では、このデータ領域には、取引停止判定フラグとして、停止解除フラグ又は停止フラグのいずれかが記録される。停止解除フラグが記録されている場合にはＡＰＩ取引を許容し、停止フラグが記録されている場合にはＡＰＩ取引を拒否する。ＡＰＩ取引停止フラグは、顧客の要望やバックオフィスの判断により設定される。ＡＰＩ取引利用停止フラグを停止解除フラグに変更した場合、ＡＰＩＩＤ更新フラグが記録され、その後、OAuth認証を完了した場合にはＡＰＩ利用を再開できる。
停止日時データ領域には、ＡＰＩの利用を停止した年月日及び時刻に関するデータが記録される。
【００３２】
図３（ｃ）に示すように、ＡＰＩ利用情報記憶部４４には、ＡＰＩ利用履歴情報４４０が記録される。このＡＰＩ利用履歴情報４４０には、ＡＰＩＩＤ、アプリＩＤ、サービスコード、利用日時に関する情報が記録される。
【００３３】
ＡＰＩＩＤデータ領域には、サービス提供者（アプリケーション）のサービスと顧客との組み合わせを特定するための識別子（ＡＰＩ管理コード）に関するデータが記録される。
アプリＩＤデータ領域には、この顧客が利用するアプリケーションを特定するための識別子に関するデータが記録される。
【００３４】
サービスコードデータ領域には、ＡＰＩを利用したサービスを特定するための識別子に関するデータが記録される。
利用日時データ領域には、ＡＰＩを利用した年月日及び時刻に関するデータが記録される。
【００３５】
図３（ｄ）に示すように、顧客ＩＤに対して、顧客が利用する複数のアプリケーションについてのアプリＩＤを設定することができる。更に、各アプリＩＤに対して、ＡＰＩを利用するサービスを特定するための複数のサービスコードを関連付ける。更に、各サービスコードに対して、ＡＰＩＩＤが関連付けられ、各ＡＰＩＩＤに対してＡＰＩＩＤ更新フラグ、ＡＰＩ取引停止フラグを設定することができる。このＡＰＩＩＤ更新フラグ、ＡＰＩ取引停止フラグにより、顧客に提供するサービス毎にＡＰＩを利用した取引を制御する。ＡＰＩゲートウェイ３０では、外部企業毎の管理は可能であるが、顧客毎にサービス停止をできない。一方、ＡＰＩＩＤ更新フラグ、ＡＰＩ取引停止フラグにより、顧客毎にサービス提供可否を制御することができる。ここで、ＡＰＩＩＤ更新フラグを用いることにより、取引を再開するためには、改めてOAuth認証（ＡＰＩ利用のための本人認証）を要求する。例えば、パスワードを変更する場合には、ＡＰＩＩＤ更新フラグにより、有効なアクセストークンの利用を停止し、再度アクセストークンを再発行させることができる。また、ＡＰＩ取引停止フラグにより、アクセストークンが有効な場合にも、ＡＰＩの利用を制御することができる。
【００３６】
また、図１に示すように、銀行サーバ４０には、担当者端末５０が接続される。担当者端末５０は、銀行のバックオフィスの担当者が用いるコンピュータ端末である。
【００３７】
（アクセストークンの発行処理）
まず、図４を用いて、アクセストークンの発行処理を説明する。
まず、ユーザ端末１０は、OAuth認証リクエスト処理を実行する（ステップＳ１−１）。具体的には、サービス提供サーバ２０を利用する場合には、ユーザは、ユーザ端末１０を用いて、サービス提供サーバ２０にアクセスする。そして、ユーザ端末１０は、OAuth認証要求を送信する。
次に、サービス提供サーバ２０は、リダイレクト要求処理を実行する（ステップＳ１−２）。具体的には、サービス提供サーバ２０は、ユーザ端末１０に対して、リダイレクト要求を送信する。このリダイレクト要求には、リダイレクト先（ＡＰＩゲートウェイ３０）のアドレス、サービス提供サーバ２０を特定するためのアプリＩＤに関する情報を含める。このアプリＩＤにより、サービス提供サーバ２０を用いるサービス提供者を特定することができる。そして、リダイレクト要求を受信したユーザ端末１０は、ＡＰＩゲートウェイ３０にリダイレクトする。
【００３８】
次に、ＡＰＩゲートウェイ３０は、アプリ認証処理を実行する（ステップＳ１−３）。具体的には、ＡＰＩゲートウェイ３０は、リダイレクト要求に含まれるアプリＩＤが利用可能アプリテーブルに記録されているかどうかを確認する。利用可能アプリテーブルにアプリＩＤが記録されている場合には、ＡＰＩを利用可能なアプリと判定する。
【００３９】
利用可能アプリと判定したＡＰＩゲートウェイ３０は、リダイレクト要求処理を実行する（ステップＳ１−４）。具体的には、ＡＰＩゲートウェイ３０は、ユーザ端末１０に対して、リダイレクト要求を送信する。このリダイレクト要求には、リダイレクト先（銀行サーバ４０）のアドレス、ユーザ認証要求に関する情報を含める。そして、リダイレクト要求を受信したユーザ端末１０は、銀行サーバ４０にリダイレクトする。
【００４０】
次に、銀行サーバ４０の制御部４１は、認証画面の送信処理を実行する（ステップＳ１−５）。具体的には、制御部４１のユーザ認証部４１０は、ユーザ端末１０に対して認証画面を送信する。この認証画面には、顧客ＩＤ、パスワードの入力欄が設けられている。
【００４１】
次に、ユーザ端末１０は、認証画面の出力処理を実行する（ステップＳ１−６）。具体的には、ユーザ端末１０は、ディスプレイに認証画面を出力する。
次に、ユーザ端末１０は、顧客ＩＤ、パスワードの送信処理を実行する（ステップＳ１−７）。具体的には、ユーザ端末１０は、認証画面に入力された顧客ＩＤ、パスワードを、銀行サーバ４０に送信する。
【００４２】
次に、銀行サーバ４０の制御部４１は、認証処理を実行する（ステップＳ１−８）。具体的には、制御部４１のユーザ認証部４１０は、ユーザ端末１０から取得した顧客ＩＤ、パスワードが顧客情報記憶部４２に記録されているかどうかを確認する。顧客ＩＤ、パスワードが記録されている場合には、認証を完了する。一方、顧客ＩＤ、パスワードが記録されておらず、認証を完了できない場合には、エラーメッセージをユーザ端末１０に送信する。
【００４３】
次に、銀行サーバ４０の制御部４１は、認可画面の送信処理を実行する（ステップＳ１−９）。具体的には、制御部４１のユーザ認証部４１０は、ユーザ端末１０に認可画面を送信する。この認可画面には、ＡＰＩの利用を希望するサービス内容（スコープ）の設定欄が設けられている。
【００４４】
次に、ユーザ端末１０は、認可画面の出力処理を実行する（ステップＳ１−１０）。具体的には、ユーザ端末１０は、ディスプレイに認可画面を出力する。
次に、ユーザ端末１０は、認可スコープ送信処理を実行する（ステップＳ１−１１）。具体的には、ユーザ端末１０は、認可画面において設定された認可スコープを含めたＡＰＩＩＤ発行要求を銀行サーバ４０に送信する。
【００４５】
次に、銀行サーバ４０の制御部４１は、ＡＰＩＩＤの発行処理を実行する（ステップＳ１−１２）。具体的には、制御部４１のＡＰＩ管理部４１１は、ＡＰＩＩＤを発行し、顧客コード、アプリＩＤに関連付けたＡＰＩＩＤ管理テーブル４３０を生成し、ＡＰＩ管理情報記憶部４３に記録する。更に、ＡＰＩ管理部４１１は、ユーザ端末１０から取得したスコープ（サービスコード）を、ＡＰＩＩＤ管理テーブル４３０に記録する。なお、初期段階では、ＡＰＩＩＤ更新フラグデータ領域には、更新なしフラグを記録する。また、認可解除日時、ＡＰＩＩＤ更新理由、ＡＰＩ取引停止フラグ、停止日時の各データ領域は空欄にしておく。そして、ＡＰＩ管理部４１１は、ＡＰＩゲートウェイ３０に対して、ＡＰＩＩＤ発行メッセージを送信する。
【００４６】
次に、図５に示すように、ＡＰＩＩＤ発行メッセージを受信したＡＰＩゲートウェイ３０は、認可コード発行処理を実行する（ステップＳ２−１）。具体的には、ＡＰＩゲートウェイ３０は、認可コードを発行する。
【００４７】
次に、ＡＰＩゲートウェイ３０は、リダイレクト要求処理を実行する（ステップＳ２−２）。具体的には、ＡＰＩゲートウェイ３０は、ユーザ端末１０に対して、リダイレクト要求を送信する。このリダイレクト要求には、リダイレクト先（サービス提供サーバ２０）のアドレス、認可コードに関する情報を含める。そして、ユーザ端末１０は、サービス提供サーバ２０にリダイレクトする。
【００４８】
次に、サービス提供サーバ２０は、アクセストークン発行要求処理を実行する（ステップＳ２−３）。具体的には、サービス提供サーバ２０は、ＡＰＩゲートウェイ３０に対してアクセストークン発行要求を送信する。このアクセストークン発行要求には、認可コードを含める。
【００４９】
次に、アクセストークン発行要求を取得したＡＰＩゲートウェイ３０は、アクセストークン発行処理を実行する（ステップＳ２−４）。具体的には、ＡＰＩゲートウェイ３０は、アクセストークンを生成する。この場合、ＡＰＩゲートウェイ３０は、ＡＰＩＩＤを暗号化してアクセストークンに含める。そして、ＡＰＩゲートウェイ３０は、発行したアクセストークンを、発行日時に関連付けてトークン情報記憶部に記録する。
【００５０】
次に、ＡＰＩゲートウェイ３０は、リフレッシュトークン発行処理を実行する（ステップＳ２−５）。具体的には、ＡＰＩゲートウェイ３０は、アクセストークンを再発行するためのリフレッシュトークンを生成する。そして、ＡＰＩゲートウェイ３０は、発行したリフレッシュトークンを、発行日時に関連付けてトークン情報記憶部に記録する。次に、ＡＰＩゲートウェイ３０は、サービス提供サーバ２０に対して、アクセストークン、リフレッシュトークンを送信する。
【００５１】
次に、サービス提供サーバ２０は、アクセストークン連携処理を実行する（ステップＳ２−６）。具体的には、サービス提供サーバ２０は、アクセストークン情報記憶部に、顧客ＩＤに関連付けて、アクセストークン、リフレッシュトークンを記録する。
【００５２】
（ＡＰＩ管理処理）
次に、図５を用いて、ＡＰＩ管理処理を説明する。
ここでは、銀行サーバ４０の制御部４１は、ステータス管理処理を実行する（ステップＳ３−１）。具体的には、制御部４１のＡＰＩ管理部４１１は、定期的に顧客情報記憶部４２にアクセスし、顧客管理情報４２０の取引履歴において顧客状況を確認する。顧客管理情報４２０の顧客状況において、パスワード変更、パスワードロック等のサービス利用停止と判定した場合には、ＡＰＩ管理部４１１は、ＡＰＩＩＤ更新フラグ（要更新フラグ）をＡＰＩＩＤ管理テーブル４３０に記録する。更に、ＡＰＩ管理部４１１は、ＡＰＩＩＤ管理テーブル４３０に認可解除日時、ＡＰＩＩＤ更新理由を記録する。
【００５３】
また、銀行サーバ４０の制御部４１は、バックオフィス対応処理を実行する（ステップＳ３−２）。具体的には、顧客からＡＰＩの利用について停止要望を取得した場合や、担当者がＡＰＩの利用停止を判断した場合には、バックオフィスの担当者は、担当者端末５０を用いて、銀行サーバ４０にアクセスする。制御部４１のＡＰＩ管理部４１１は、担当者端末５０からＡＰＩの利用停止情報を取得した場合には、ＡＰＩＩＤ管理テーブル４３０のＡＰＩ取引停止フラグデータ領域に停止フラグを記録する。この場合、ＡＰＩ管理部４１１は、ＡＰＩＩＤ管理テーブル４３０に停止日時を記録する。
【００５４】
また、銀行サーバ４０の制御部４１は、履歴確認処理を実行する（ステップＳ３−３）。具体的には、必要に応じて、バックオフィスの担当者が、ＡＰＩの利用状況を確認する場合、担当者端末５０において、ＡＰＩＩＤを指定する。そして、担当者端末５０を用いて、銀行サーバ４０にアクセスし、ＡＰＩＩＤを指定した履歴確認要求を送信する。この場合、制御部４１のＡＰＩ管理部４１１は、指定されたＡＰＩＩＤのＡＰＩ利用履歴情報４４０をＡＰＩ利用情報記憶部４４から取得する。そして、ＡＰＩ管理部４１１は、取得したＡＰＩ利用履歴情報４４０を担当者端末５０に出力する。
【００５５】
（サービス提供時処理）
次に、図６を用いて、サービス提供時処理を説明する。
まず、ユーザ端末１０は、ＡＰＩ利用処理を実行する（ステップＳ４−１）。具体的には、ユーザが、ＡＰＩを利用して、サービス提供者のサービスを利用する場合には、サービス提供サーバ２０にアクセスする。
【００５６】
次に、サービス提供サーバ２０は、ＡＰＩ利用要求処理を実行する（ステップＳ４−２）。具体的には、サービス提供サーバ２０は、ＡＰＩゲートウェイ３０に対してＡＰＩ利用要求を送信する。このＡＰＩ利用要求には、ユーザのアクセストークンを含める。
【００５７】
次に、ＡＰＩゲートウェイ３０は、アクセストークン検証処理を実行する（ステップＳ４−３）。具体的には、ＡＰＩゲートウェイ３０は、トークン情報記憶部にアクセストークンが登録されているかどうかを確認する。
【００５８】
次に、ＡＰＩゲートウェイ３０は、有効期限内かどうかについての判定処理を実行する（ステップＳ４−４）。具体的には、ＡＰＩゲートウェイ３０は、トークン情報記憶部に記録されている発行日時からの経過時間を算出する。経過時間が有効期間を経過していない場合には、有効期限内と判定する。
【００５９】
有効期限内でないと判定した場合（ステップＳ４−４において「ＮＯ」の場合）、ＡＰＩゲートウェイ３０は、エラー応答処理を実行する（ステップＳ４−５）。具体的には、ＡＰＩゲートウェイ３０は、サービス提供サーバ２０に対してエラーメッセージを送信する。この場合、サービス提供サーバ２０は、リフレッシュトークンをＡＰＩゲートウェイ３０に送信し、新たなアクセストークンを取得する。
【００６０】
一方、有効期限内と判定した場合（ステップＳ４−４において「ＹＥＳ」の場合）、ＡＰＩゲートウェイ３０は、ＡＰＩＩＤの抽出処理を実行する（ステップＳ４−６）。具体的には、ＡＰＩゲートウェイ３０は、アクセストークンを復号してＡＰＩＩＤを取得する。
【００６１】
次に、ＡＰＩゲートウェイ３０は、ＡＰＩＩＤの送信処理を実行する（ステップＳ４−７）。具体的には、ＡＰＩゲートウェイ３０は、抽出したＡＰＩＩＤを含めたＡＰＩ利用要求を銀行サーバ４０に送信する。
【００６２】
次に、銀行サーバ４０の制御部４１は、ＡＰＩＩＤの確認処理を実行する（ステップＳ４−８）。具体的には、制御部４１のＡＰＩ管理部４１１は、ＡＰＩＩＤに基づき、ＡＰＩ管理情報記憶部４３に記録されたＡＰＩＩＤ管理テーブル４３０を特定する。
【００６３】
次に、銀行サーバ４０の制御部４１は、ＡＰＩ利用可能かどうかについての判定処理を実行する（ステップＳ４−９）。具体的には、制御部４１のＡＰＩ管理部４１１は、ＡＰＩＩＤ管理テーブル４３０のＡＰＩＩＤ更新フラグ、ＡＰＩ取引利用停止フラグを確認する。そして、ＡＰＩ管理部４１１は、ＡＰＩＩＤ管理テーブル４３０に要更新フラグ及び停止フラグが記録されていない場合にはＡＰＩ利用可能と判定する。一方、ＡＰＩＩＤ管理テーブル４３０に要更新フラグ、停止フラグの少なくとも何れかが記録されている場合には、ＡＰＩ利用不可と判定する。
【００６４】
ＡＰＩ利用不可と判定した場合（ステップＳ４−９において「ＮＯ」の場合）、銀行サーバ４０の制御部４１は、エラー応答処理を実行する（ステップＳ４−１０）。具体的には、制御部４１のＡＰＩ管理部４１１は、ＡＰＩゲートウェイ３０を介して、サービス提供サーバ２０にエラーメッセージを返信する。
【００６５】
一方、ＡＰＩ利用可能と判定した場合（ステップＳ４−９において「ＹＥＳ」の場合）、銀行サーバ４０の制御部４１は、正常応答処理を実行する（ステップＳ４−１１）。具体的には、銀行サーバ４０の制御部４１は、ＡＰＩ利用履歴情報４４０を生成し、ＡＰＩ利用情報記憶部４４に記録する。次に、サービス管理部４１２は、サービスコードに応じたサービスを実行する。例えば、残高照会サービスの場合、サービス管理部４１２は、顧客ＩＤに関連付けられた口座識別子の口座残高を取得する。そして、サービス管理部４１２は、このサービス結果（例えば、口座残高）を、ＡＰＩゲートウェイ３０を介して、サービス提供サーバ２０に返信する。
【００６６】
以上、本実施形態によれば、以下のような効果を得ることができる。
（１）本実施形態では、銀行サーバ４０の制御部４１は、ＡＰＩＩＤの発行処理を実行する（ステップＳ１−１２）。ここでは、銀行サーバ４０の制御部４１は、ステータス管理処理を実行する（ステップＳ３−１）。これにより、顧客とサービス提供者とを関連付けた識別子により、ＡＰＩ利用を制御することができる。
【００６７】
（２）本実施形態では、銀行サーバ４０の制御部４１は、バックオフィス対応処理を実行する（ステップＳ３−２）。これにより、顧客とサービス提供者との関係に基づいて、顧客からの要望や銀行の判断に応じて、ＡＰＩ利用を制御することができる。
【００６８】
（３）本実施形態では、銀行サーバ４０の制御部４１は、履歴確認処理を実行する（ステップＳ３−３）。これにより、サービス提供者やサービス毎に、ＡＰＩの利用状況を確認することができる。
【００６９】
（４）本実施形態では、銀行サーバ４０の制御部４１は、ＡＰＩ利用可能かどうかについての判定処理を実行する（ステップＳ４−９）。これにより、顧客状況や銀行サーバ４０のサービス提供状況に応じて、ＡＰＩ利用の可否を判定することができる。
【００７０】
本実施形態は、以下のように変更して実施することができる。本実施形態及び以下の変更例は、技術的に矛盾しない範囲で互いに組み合わせて実施することができる。
・上記実施形態では、OAuth認証に用いる項目は、ネットバンキングサービス利用時に用いる顧客ＩＤ、パスワードに限定されるものではない。例えば、キャッシュカード利用時に用いる顧客番号、暗証番号や、顧客の生体情報を用いたＦＩＤＯ（登録商標）も利用可能である。
【００７１】
・上記実施形態では、銀行サーバ４０の制御部４１は、ステータス管理処理（ステップＳ３−１）、バックオフィス対応処理（ステップＳ３−２）を実行する。ここで、複数のサービスコードや、複数のＡＰＩＩＤを関連付けておくことにより、所定のサービス、ＡＰＩを停止した場合、関連付けられたサービスやＡＰＩも停止するようにしてもよい。この場合には、ＡＰＩ管理情報記憶部４３において、関連する複数のサービスコードや、複数のＡＰＩＩＤを関連付けた関連ＡＰＩ管理テーブルを記録しておく。そして、ＡＰＩ管理部４１１は、サービスやＡＰＩの停止を検知した場合、関連ＡＰＩ管理テーブルを用いて、関連するサービスコードやＡＰＩＩＤを特定し、ＡＰＩＩＤ更新フラグデータ領域に要更新フラグ、ＡＰＩ取引停止フラグデータ領域に停止フラグを記録する。
【００７２】
・上記実施形態では、銀行サーバ４０における金融サービスの利用に適用したが、適用対象は金融サービスに限定されるものではなく、各種サービスに適用することができる。
【符号の説明】
【００７３】
１０…ユーザ端末、２０…サービス提供サーバ、３０…ＡＰＩゲートウェイ、４０…銀行サーバ、４１…制御部、４２…顧客情報記憶部、４３…ＡＰＩ管理情報記憶部、４４…ＡＰＩ利用情報記憶部、５０…担当者端末。
【図１】
2020166469.tif 000003
【図２】
2020166469.tif 000004
【図３】
2020166469.tif 000005
【図４】
2020166469.tif 000006
【図５】
2020166469.tif 000007
【図６】
2020166469.tif 000008