JP6748667B2 - Api提供システム、認証サーバ、api提供方法、及びプログラム - Google Patents

Api提供システム、認証サーバ、api提供方法、及びプログラム Download PDF

Info

Publication number
JP6748667B2
JP6748667B2 JP2018052047A JP2018052047A JP6748667B2 JP 6748667 B2 JP6748667 B2 JP 6748667B2 JP 2018052047 A JP2018052047 A JP 2018052047A JP 2018052047 A JP2018052047 A JP 2018052047A JP 6748667 B2 JP6748667 B2 JP 6748667B2
Authority
JP
Japan
Prior art keywords
authentication
api
providing
intermediary
user
Prior art date
Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
Active
Application number
JP2018052047A
Other languages
English (en)
Other versions
JP2019164590A (ja
Inventor
俊博 井上
俊博 井上
Original Assignee
楽天銀行株式会社
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by 楽天銀行株式会社 filed Critical 楽天銀行株式会社
Priority to JP2018052047A priority Critical patent/JP6748667B2/ja
Publication of JP2019164590A publication Critical patent/JP2019164590A/ja
Application granted granted Critical
Publication of JP6748667B2 publication Critical patent/JP6748667B2/ja
Active legal-status Critical Current
Anticipated expiration legal-status Critical

Links

Images

Description

本発明は、API提供システム、認証サーバ、API提供方法、及びプログラムに関する。
従来、API(Application Programming Interface)を利用して各種サービスを提供する技術が知られている。例えば、特許文献1には、認証装置と、APIを利用したサービスを提供するサービス提供装置と、サービスの提供を仲介するサービス仲介装置と、を含むシステムにおいて、認証装置によるユーザの認証が成功した場合に、サービスを利用するためのトークンを発行し、サービス仲介装置に送信することが記載されている。サービス仲介装置は、サービス提供装置に認証情報を送信し、サービス提供装置からのサービスの仲介を行う。
また例えば、特許文献2には、電子商取引システムを通じて銀行システム内のAPIを利用する場合に、銀行システムが電子商取引システムに対してトークンを発行し、電子商取引システムが保有するトークンを利用してAPIを提供するシステムが記載されている。このシステムでは、トークン発行時の認証だけでなく、決済の際に電子商取引システムで暗証番号を入力させることによって、二段階の認証が行われる。
特許特5458888号公報 特許特6255070号公報
上記のような技術では、APIの利用を仲介する仲介システムに認証情報が管理されるため、仲介システムは、悪意のある第三者の攻撃対象になりがちである。この点、複数のAPIを提供する場合に、これら複数のAPIで共通のトークンを発行したとすると、第三者にトークンが漏えいすると全てのAPIが悪用される可能性があり、セキュリティ性を高めることはできない。
本発明の目的は、仲介システムを介して複数のAPIを提供する場合のセキュリティを高めることが可能なAPI提供システム、認証サーバ、API提供方法、及びプログラムを提供することである。
上記課題を解決するために、本発明に係るAPI提供システムは、仲介システムを介して複数のAPIを提供するAPI提供システムであって、ユーザ端末から前記仲介システムに第1のAPIの利用要求が送信された場合に、当該利用要求に基づくリダイレクトを受けて、前記ユーザ端末との間で第1の認証を行う第1認証手段と、前記第1の認証が成功した場合に、前記ユーザ端末にユーザ認証情報を発行し、前記仲介システムに、前記第1のAPIを利用するための第1の認証情報を発行する第1発行手段と、前記仲介システムから受信した前記第1の認証情報に基づいて、前記第1のAPIを提供する第1提供手段と、前記ユーザ端末から前記仲介システムに第2のAPIの利用要求が送信された場合に、当該利用要求に基づくリダイレクトを受けて、前記ユーザ端末との間で、前記第1発行手段により発行された前記ユーザ認証情報に基づく第2の認証を行う第2認証手段と、前記第2の認証が成功した場合に、前記仲介システムに、前記第2のAPIを利用するための第2の認証情報を発行する第2発行手段と、前記仲介システムから受信した前記第2の認証情報に基づいて、前記第2のAPIを提供する第2提供手段と、を含むことを特徴とする。
実施形態に係るAPI提供システムの一例を示す図である。 ユーザが仲介システム2のサービスを利用する様子を示す画面遷移図である。 更新系APIが利用される場合の画面遷移図である。 本実施形態において実現される機能を示す機能ブロック図である。 ユーザデータベースの一例を示す図である。 口座データベースの一例を示す図である。 本実施形態において実行される処理のフロー図である。 本実施形態において実行される処理のフロー図である。 本実施形態において実行される処理のフロー図である。 本実施形態において実行される処理のフロー図である。
[1.API提供システムの全体構成]
以下、本発明に係る実施形態の例について図面に基づき詳細に説明する。図1は、実施形態に係るAPI提供システムの一例を示す図である。図1に示すように、例えば、API提供システム1は、インターネットなどのネットワークNを介し、仲介システム2及びユーザ端末30の各々とデータ送受信可能である。
API提供システム1は、複数のAPIを提供するシステムであり、少なくとも1つのコンピュータを含む。各APIは、仲介システム2に公開されている。このため、API提供システム1と仲介システム2とは連携可能であり、各APIに係る機能は、仲介システム2を介してユーザに間接的に提供される。APIの機能としては、任意の内容であってよく、例えば、金融サービス、電子商取引、保険サービス、旅行予約サービス、又はSNS(Social Networking Service)に係る機能がAPIを利用してユーザに提供されるようにしてもよい。
本実施形態では、金融機関がAPI提供システム1を管理し、APIを利用して金融サービスを提供する場合を一例として説明する。金融機関は、金融取引に関する業務を営む組織であり、例えば、銀行や信用金庫といった預貯金取扱金融機関だけでなく、証券会社であってもよい。本実施形態では、金融機関が銀行であり、ユーザは、銀行の口座を開設済みであるものとする。なお、ユーザは、法人であってもよいし、個人(個人事業主を含む)であってもよい。
例えば、API提供システム1は、サーバコンピュータであるAPI提供サーバ10を含む。API提供サーバ10は、制御部11、記憶部12、及び通信部13を含む。制御部11は、例えば、少なくとも1つのマイクロプロセッサを含む。記憶部12は、例えば、RAM等の主記憶部やハードディスク等の補助記憶部を含む。制御部11は、記憶部12に記憶されたプログラムやデータに従って処理を実行する。通信部13は、有線通信又は無線通信用の通信インタフェースを含む。通信部13は、インターネットやLANなどのネットワークを介して外部機器とのデータ送受信が可能である。
仲介システム2は、API提供システム1と連携するシステムであり、少なくとも1つのコンピュータを含む。例えば、仲介システム2は、API提供システム1が公開するAPIを利用し、ユーザの業務を支援するサービスを提供する。本実施形態では、APIを利用して金融サービスが提供される場合を説明するので、仲介システム2は、経費精算や給与振込などの会計業務を支援するシステム(例えば、いわゆるクラウド会計システム)である場合を一例として説明する。
例えば、仲介システム2は、サーバコンピュータである仲介サーバ20を含む。仲介サーバ20は、制御部21、記憶部22、及び通信部23を含む。制御部21、記憶部22、及び通信部23のハードウェア構成は、それぞれ制御部11、記憶部12、及び通信部13と同様であってよい。
ユーザ端末30は、ユーザが操作するコンピュータであり、例えば、パーソナルコンピュータ、携帯電話(スマートフォンを含む)、又は携帯情報端末(タブレット型端末を含む)である。ユーザ端末30は、制御部31、記憶部32、通信部33、操作部34、及び表示部35を含む。制御部31、記憶部32、及び通信部33のハードウェア構成は、それぞれ制御部11、記憶部12、及び通信部13と同様であってよい。操作部34は、入力デバイスであり、例えば、タッチパネルやマウスなどのポインティングデバイス又はキーボードである。表示部35は、例えば、液晶ディスプレイ又は有機ELディスプレイである。
なお、記憶部12,22,32に記憶されるものとして説明するプログラムやデータは、コンピュータ読み取り可能な情報記憶媒体(例えば、USBメモリ又はSDカード)に記憶されたものが各コンピュータに供給されるようにしてもよいし、ネットワークを介して各コンピュータに供給されるようにしてもよい。また、上記説明した各コンピュータのハードウェア構成は、上記の例に限られず、例えば、情報記憶媒体を読み取る読取部(例えば、SDカードスロット)、又は、外部機器と直接的に通信するための入出力部(例えば、USB端子)が備えられていてもよい。
[2.API提供システムが実行する処理の概要]
API提供システム1は、仲介システム2を介して複数のAPIを提供する。ここでは、APIの一例として、口座情報を参照するためのAPI(以降、参照系APIと記載する。)と、口座情報を更新するためのAPI(以降、更新系APIと記載する。)と、を説明する。なお、API提供システム1が提供するAPIは3つ以上であってもよい。
参照系APIは、口座情報を参照する機能が関連付けられている。例えば、ユーザが、仲介システム2のサービスを利用して、入出金明細や口座残高を参照する場合に、参照系APIが利用される。更新系APIは、口座情報を更新する機能が関連付けられている。例えば、ユーザが、仲介システム2のサービスを利用して、振込、入金、又は出金をする場合に、更新系APIが利用される。
図2は、ユーザが仲介システム2のサービスを利用する様子を示す画面遷移図である。図2に示すように、ユーザがユーザ端末30を操作して仲介システム2にアクセスすると、仲介システム2のログイン画面G1が表示部35に表示される。仲介システム2のユーザアカウントとパスワードがログイン画面G1から入力され、仲介システム2において正当性が確認されると、ユーザは仲介システム2にログインする。
ユーザが仲介システム2にログインすると、仲介システム2が提供する種々のサービスを利用するためのメニュー画面G2が表示部35に表示される。例えば、ユーザは、メニュー画面G2から、経費申請、経費承認、入出金明細照会、経費や給与などの振込処理、残高照会、及び入出金処理といったサービスを利用することができる。例えば、ユーザが、メニュー画面G2から入出金明細参照の項目を選択すると、API提供システム1に移動する旨のメッセージが表示され、ユーザが同意すると、API提供システム1へのリダイレクトが実行される。
リダイレクトが実行されると、API提供システム1のログイン画面G3が表示部35に表示される。API提供システム1のユーザアカウントとパスワードがログイン画面G3から入力され、ユーザの正当性が確認されると、例えば、API提供システム1は、Cookieを発行してユーザ端末30に送信し、OAuth2.0に基づくトークンを発行して仲介システム2に送信する。
Cookieは、ウェブブラウザで用いられるユーザの識別情報である。本実施形態では、参照系APIを利用するための認証でCookieが発行されるので、Cookieは、当該認証を受けたユーザであることを証明する情報ということもできる。Cookieは、仲介システム2ではなく、ユーザ端末30に保持される。
OAuth2.0は、認証プロトコルの一種であり、例えば、管理主体の異なる複数のシステム間で連携する場合に利用される。トークンは、APIの利用が認可されたことを証明する情報である。本実施形態では、ユーザは仲介システム2を介してAPIを間接的に利用するので、仲介システム2が、ユーザの代わりにAPIに対してリクエストを送信するために、トークンが用いられる。このため、トークンは、ユーザ端末30ではなく、仲介システム2に保持される。
本実施形態では、複数のAPIで共通のトークンが用いられるのでなく、APIごとに異なるトークンが発行される。以降、参照系APIで使用されるトークンを参照系トークンと記載し、更新系APIで使用されるトークンを更新系トークンと記載する。図2の例では、参照系APIが利用されるので、参照系トークンが発行されることになる。
仲介システム2は、API提供システム1から受信した参照系トークンを利用し、参照系APIにリクエストを送信する。API提供システム1は、仲介システム2から受信した参照系トークンの正当性を確認すると、参照系APIの応答として、ユーザの入出金明細を取得して仲介システム2に送信する。仲介システム2は、受信した入出金明細に基づいて、ユーザ端末30に入出金明細画面G4を表示させる。
図3は、更新系APIが利用される場合の画面遷移図である。図3に示すように、ユーザが、メニュー画面G2から振込処理の項目を選択すると、振込内容を入力するための振込内容入力画面G5が表示部35に表示される。ユーザが振込内容入力画面G5から振込先や振込金額等を入力して所定の振込指示をすると、API提供システム1に移動する旨のメッセージが表示され、ユーザが同意すると、API提供システム1へのリダイレクトが実行される。
リダイレクトが実行されると、ユーザ端末30に記憶されていたCookie(参照系APIの利用時に発行されたCookie)がAPI提供システム1に送信される。API提供システム1は、受信したCookieの正当性を確認すると、口座の暗証番号を入力するための暗証番号入力画面G6をユーザ端末30に表示させる。ユーザが、口座(ここでは、ユーザが勤務する会社の口座)の暗証番号を入力し、正当性が確認されると、API提供システム1は、更新系トークンを発行し、仲介システム2に送信する。
仲介システム2は、API提供システム1から受信した更新系トークンを利用し、更新系APIにリクエストを送信する。API提供システム1は、仲介システム2から受信した更新系トークンの正当性を確認すると、更新系APIの応答として、振込処理を実行して実行結果を仲介システム2に送信する。仲介システム2は、受信した振込の実行結果に基づいて、ユーザ端末30に振込完了画面G7を表示させる。
以上のように、本実施形態のAPI提供システム1は、参照系APIの利用時にCookieを発行してユーザ端末30に送信し、更新系APIの利用要求(詳細後述)が送信された場合に、ユーザが有効なCookieを保有するか否かを確認する。API提供システム1は、Cookieの正当性を確認したうえで暗証番号を入力させることで、参照系APIを利用するユーザと、更新系APIを利用するユーザと、の同一性を確認し、セキュリティを高めるようにしている。以降、API提供システム1の構成の詳細について説明する。
[3.本実施形態において実現される機能]
図4は、本実施形態において実現される機能を示す機能ブロック図である。図4に示すように、ここでは、主にAPI提供システム1で実現される機能を説明する。例えば、API提供システム1では、参照系API100、更新系API101、データ記憶部102、第1認証部103、第1発行部104、第1提供部105、第2認証部106、第3認証部107、第2発行部108、及び第2提供部109が実現される。データ記憶部102は記憶部12を主として実現され、他の各機能は制御部11を主として実現される。
[参照系API]
参照系API100は、本発明に係る第1のAPIの一例である。このため、本実施形態で参照系API100と記載した箇所は、第1のAPIと読み替えることができる。第1のAPIは、API提供システム1が提供する複数のAPIのうちの何れかであればよく、参照系API100及び更新系API101以外の他のAPI(例えば、ユーザの基本情報を参照するためのAPIや住所などの登録情報を変更するためのAPIなど)を提供する場合には、当該他のAPIが第1のAPIに相当してもよい。先述したように、参照系API100は、口座情報を参照する機能が関連付けられており、本実施形態では、後述する口座データベースを参照する。
[更新系API]
更新系API101は、本発明に係る第2のAPIの一例である。このため、本実施形態で更新系API101と記載した箇所は、第2のAPIと読み替えることができる。第2のAPIは、API提供システム1が提供する複数のAPIのうち、第1のAPIとは異なるAPIであればよい。本実施形態では、セキュリティレベルが互いに異なる複数のAPIが存在し、第2のAPIは、第1のAPIよりもセキュリティレベルが高いものとする。このため、第2のAPIは、第1のAPIよりも複雑な認証が必要であり、本実施形態では、第2のAPIは、第1のAPIよりも利用時に必要な認証回数が多いものとする。先述したように、更新系API101は、口座情報を更新する機能が関連付けられており、本実施形態では、後述する口座データベースを更新する。
[データ記憶部]
データ記憶部102は、APIを提供するために必要なデータを記憶する。ここでは、データ記憶部102が記憶するデータの一例として、ユーザに関する各種情報を格納するためのユーザデータベースと、口座に関する各種情報を格納するための口座データベースと、を説明する。
図5は、ユーザデータベースの一例を示す図である。図5に示すように、ユーザデータベースには、ユーザアカウント、ユーザ名、パスワード、Cookie、参照系トークン、更新系トークン、及び口座識別情報が格納される。ユーザデータベースに格納されるユーザアカウントとパスワードは、API提供システム1にログインするための認証情報である。ユーザアカウントは、ユーザがAPI提供システム1に利用登録した際に発行され、パスワードは、利用登録後に任意のものを設定可能である。
Cookieは、参照系トークン発行時に生成されたCookieである。参照系トークンが発行されていないユーザについては、ユーザデータベースにCookieは格納されない。Cookieは、特に有効期限が存在しなくてもよいが、本実施形態では、Cookieは、有効期限が設定されている。有効期限を示す情報は、Cookieの内部に組み込まれていてもよいし、Cookieとは別の情報として管理されていてもよい。
参照系トークンは、参照系API100の利用が認可されたことを証明する情報である。参照系トークンは、本発明に係る第1の認証情報に相当する。このため、本実施形態で参照系トークンと記載した箇所は、第1の認証情報と読み替えることができる。参照系トークンは、公知の認証プロトコルを利用して発行されるようにすればよく、本実施形態では、OAuth2.0を利用する場合を説明する。
例えば、参照系トークンは、アクセストークンと、リフレッシュトークンと、を含む。アクセストークンとリフレッシュトークンとは、それぞれ有効期限が設定されており、リフレッシュトークンの有効期限は、アクセストークンの有効期限よりも長い。通常のリクエストでは、リフレッシュトークンは送信されずアクセストークンだけが送信され、リフレッシュトークンは、アクセストークンを再発行する場合に送信される。
更新系トークンは、更新系API100の利用が認可されたことを証明する情報である。更新系トークンは、本発明に係る第2の認証情報に相当する。このため、本実施形態で更新系トークンと記載した箇所は、第2の認証情報と読み替えることができる。更新系トークンは、公知のプロトコルを利用して発行されるようにすればよく、本実施形態では、OAuth2.0を利用する場合を説明する。
更新系トークンは、参照系トークンと同様、アクセストークンとリフレッシュトークンとを含んでもよいが、本実施形態では、アクセストークンだけが発行されるものとする。詳細は後述するが、更新系トークンの有効期限は、参照系トークンの有効期限よりも短く、ワンタイム化されているものとする。なお、口座識別情報は、口座を識別するための情報であればよく、例えば、支店名、口座番号、及び口座名義人である。
図6は、口座データベースの一例を示す図である。図6に示すように、口座データベースには、銀行の支店名、口座を識別する口座番号、口座名義人、残高情報、暗証番号、及び入出金明細情報が格納される。暗証番号は、口座の暗証番号であり、口座開設時等に指定された暗証番号である。入出金明細情報は、口座の入出金の履歴を示す情報であり、例えば、日付、入出金額、及び入出金者といった情報が格納される。例えば、口座データベースに格納された各情報は、参照系API100によって参照される。また例えば、口座データベースに格納された残高情報及び入出金明細情報は、更新系API101によって更新される。
[第1認証部]
第1認証部103は、ユーザ端末30から仲介システム2に参照系API100の利用要求が送信された場合に、当該利用要求に基づくリダイレクトを受けて、ユーザ端末30との間でログイン認証を行う。
利用要求は、利用対象となるAPIを識別するための情報を含み、所定形式のデータが送信されることで利用要求が行われるようにすればよい。利用要求は、ユーザ端末30から仲介システム2に対してなされる要求のうち、API提供システム1が提供するAPIの利用が必要なもの(又は、APIの利用を予定しているもの)である。本実施形態では、参照系API100又は更新系API101の何れかが利用されるので、利用要求には、これらの何れを利用するかを識別するための情報(例えば、メニュー画面G2のどの項目が選択されたかを示す情報等)が含まれているものとする。
なお、ユーザ端末30から受信する要求の中には、API提供システム1が提供するAPIを利用しないもの(例えば、メニュー画面G2における経費申請等)もあるので、仲介システム2は、API提供システム1が提供するAPIを利用する要求がどれであるかを特定可能となっている。例えば、仲介システム2は、メニュー画面G2の入出金明細照会の項目が選択された旨の通知を受信した場合には、参照系APIの利用要求であると判定し、メニュー画面G2の振込処理の項目が選択された旨の通知を受信した場合には、更新系APIの利用要求であると判定する。
参照系API100の利用要求は、ユーザが操作部34から所定の操作を行った場合に、ユーザ端末30から仲介システム2に送信される。本実施形態では、メニュー画面G2において入出金明細参照の項目を選択する操作を一例として説明するので、ユーザ端末30から仲介システム2に対し、入出金明細参照の項目が選択された旨の通知が送信されることが、参照系API100の利用要求が送信されることに相当する。仲介システム2において、当該通知が受信された場合に、参照系API100にリクエストを送信するようになっている。なお、入出金明細参照以外にも、残高照会の項目をするための操作が行われた場合に、参照系API100の利用要求が送信されてもよい。
なお、リダイレクトは、公知の方法で実行されるようにすればよく、仲介システム2側で実行されてもよいし、ユーザ端末30側で実行されてもよい。例えば、Apacheで.htaccessファイルに所定のルールを記載しておくことによって、仲介システム2側でリダイレクトが実行されてもよいし、JavaScript(登録商標)を利用してユーザ端末30側でリダイレクトが実行されてもよい。
ログイン認証は、本発明に係る第1の認証の一例である。このため、本実施形態でログイン認証と記載した箇所は、第1の認証と読み替えることができる。第1の認証は、API提供システム1とユーザ端末30との間で行われる認証であればよい。本実施形態のように、ログイン画面G3から入力されたユーザアカウントとパスワードを利用したログイン認証以外にも、第1の認証は、種々の認証方法を利用可能である。例えば、顔認証や指紋認証などの生体認証であってもよいし、物理トークンや携帯機器PINを利用した認証であってもよい。他にも例えば、ICカードを利用した認証であってもよいし、二次元コード等のコード情報を利用した認証であってもよい。
例えば、第1認証部103は、ユーザ端末30から受信した認証情報(ユーザが入力した認証情報)と、ユーザデータベースに格納された認証情報と、に基づいて、ログイン認証を実行する。本実施形態のように、ユーザアカウントとパスワードの組み合わせを利用する場合には、第1認証部103は、ユーザ端末30から受信したユーザアカウントとパスワードの組み合わせと、ユーザデータベースに格納されたユーザアカウントとパスワードの組み合わせと、が一致するか否かを判定する。第1認証部103は、これらが一致する場合には認証成功と判定し、これらが一致しない場合には認証失敗と判定する。なお、認証成功と判定されるためには、必ずしも認証情報が一致しなければならないわけではなく、例えば、生体認証を利用する場合には、顔認証又は指紋認証における画像の一致度が100%でなくても、閾値以上であれば認証成功と判定してもよい。
[第1発行部]
第1発行部104は、ログイン認証が成功した場合に、ユーザ端末30にCookieを発行し、仲介システム2に、参照系API100を利用するための参照系トークンを発行する。
Cookieは、本発明に係るユーザ認証情報の一例である。このため、本実施形態でCookieと記載した箇所は、ユーザ認証情報と読み替えることができる。ユーザ認証情報は、第1の認証が成功したユーザ(又はユーザ端末30)を識別する情報である。本実施形態では、参照系API100を利用する場合のログイン認証が第1の認証に相当するので、Cookieは、当該ログイン認証が成功したユーザを識別する情報といえる。なお、ユーザ認証情報は、Cookieに限られず、例えば、電子証明書、暗号キー、又はパスコードといった情報であってもよい。
なお、ユーザ認証情報の発行方法自体は、公知の種々の手法を適用可能であり、ユーザ認証情報の内容に応じたアルゴリズムを用意しておき、第1発行部104は、当該アルゴリズムに基づいて、ユーザ認証情報を発行すればよい。本実施形態のように、Cookieをユーザ認証情報として利用する場合には、例えば、第1発行部104は、PHP(Hypertext Preprocessor)におけるsetcookie関数に基づいて、Cookieを発行してもよい。
例えば、Cookieには、特に有効期限が設定されていなくてもよいが、本実施形態では、第1発行部104は、Cookieに有効期限を設定する。Cookieの有効期限は、任意の長さであればよく、例えば、10分〜1時間程度であってもよいし、それ以下又はそれ以上であってもよい。Cookieの有効期限は、ユーザ端末30がAPI提供システム1にアクセスした場合に延長されるようにしてもよい。
参照系トークンは、本発明に係る第1の認証情報の一例である。このため、本実施形態で参照系トークンと記載した箇所は、第1の認証情報と読み替えることができる。第1の認証情報は、第1のAPIの利用が認証されたユーザを識別する情報である。なお、第1の認証情報は、トークンに限られず、例えば、電子証明書、暗号キー、又はパスコードといった情報であってもよい。ただし、第1の認証情報は、ユーザ認証情報とは異なる情報であるものとする。第1の認証情報の発行方法自体は、公知の種々の手法を適用可能であり、第1の認証情報の内容に応じたアルゴリズムを用意しておき、第1発行部104は、当該アルゴリズムに基づいて、第1の認証情報を発行すればよい。本実施形態のように、トークンを第1の認証情報として利用する場合には、例えば、OAuth2.0で実装されているトークン生成方法を利用すればよい。
例えば、参照系トークンには、特に有効期限が設定されていなくてもよいが、本実施形態では、第1発行部104は、参照系トークンに有効期限を設定する。参照系トークンの有効期限は、任意の長さであればよく、例えば、参照系トークンのアクセストークン(以降、単に参照系アクセストークンと記載する。)については10分〜1時間程度とし、参照系トークンのリフレッシュトークン(以降、単に参照系リフレッシュトークンと記載する。)については、数時間程度としてもよい。
なお、本実施形態では、Cookieの有効期限と、参照系アクセストークンの有効期限と、を同じ長さにして、参照系アクセストークンの有効期限が切れた場合に、Cookieも無効とする場合を説明するが、これらの長さは異なってもよい。例えば、Cookieの有効期限を参照系アクセストークンの有効期限よりも短く設定することで、後述するCookie認証のセキュリティレベルを上げるようにしてもよい。
[第1提供部]
第1提供部105は、仲介システム2から受信した参照系トークンに基づいて、参照系API100を提供する。例えば、第1提供部105は、仲介システム2から参照系トークンを受信し、当該参照系トークンの正当性を確認する。第1提供部105は、仲介システム2から受信した参照系トークンと、ユーザデータベースに格納された参照系トークンと、が一致するか否かを判定する。第1提供部105は、これらが一致しない場合には、参照系API100を提供せず、これらが一致する場合に、参照系API100を提供する。
なお、APIを提供するとは、APIが有する機能を提供することであり、APIに関連付けられたプログラムを実行して処理結果を返すことを意味する。参照系API100であれば、口座データベースを参照する機能が関連付けられているので、第1提供部105は、口座データベースに格納された支店名、口座番号、口座残高、及び入出金明細情報の少なくとも1つを送信することによって、参照系API100を提供する。例えば、第1提供部105は、入出金明細情報を送信することによって、入出金明細を参照させ、口座残高の数値を送信することによって、口座残高を参照させる。
本実施形態では、参照系トークンに有効期限が設定されているので、第1提供部105は、参照系トークンに設定された有効期限に基づいて、参照系API100を提供する。第1提供部105は、リアルタイムクロック等を利用して現在日時を取得し、参照系トークンに設定された有効期限が経過しているか否かを判定する。本実施形態では、第1提供部105は、参照系アクセストークンに設定された有効期限が経過しているか否かを判定することになる。第1提供部105は、有効期限が経過していると判定した場合は参照系API100を提供せず、有効期限が経過していないと判定された場合は参照系API100を提供する。
[第2認証部]
第2認証部106は、ユーザ端末30から仲介システム2に更新系API101の利用要求が送信された場合に、当該利用要求に基づくリダイレクトを受けて、ユーザ端末30との間で、第1発行部104により発行されたCookieに基づくCookie認証を行う。なお、リダイレクト処理自体は、参照系APIの利用要求が送信された場合と同様の処理で実行されてよい。
更新系API101の利用要求は、ユーザが操作部34から所定の操作を行った場合に、ユーザ端末30から仲介システム2に送信される。本実施形態では、メニュー画面G2において振込処理が選択され、その後に振込内容入力画面G5から振込内容を入力する操作を一例として説明するが、利用要求は、予め定められた操作が行われた場合に送信されるようにすればよく、例えば、経費申請を承認する操作であってもよい。
Cookie認証は、本発明に係る第2の認証の一例である。このため、本実施形態でCookie認証と記載した箇所は、第2の認証と読み替えることができる。第2の認証は、第1の認証を実行したユーザとの同一性を確認するための認証であり、第2の認証は、第1の認証が成功した際にユーザ端末30に送信されたユーザ認証情報を利用して行われる。本実施形態では、Cookieがユーザ認証情報に相当する場合を説明するので、Cookie認証を例に挙げるが、ユーザ認証情報が電子証明書、暗号キー、又はパスコードであれば、これらの正当性を確認することが第2の認証であってもよい。即ち、第2の認証は、第1の認証が成功したユーザしか知りえない(第1の認証が成功したユーザのユーザ端末30でしか記憶しえない)情報の有無を確認するための認証といえる。
例えば、第2認証部106は、ユーザ端末30に対してCookieを要求し、ユーザ端末30から受信したCookieと、ユーザデータベースに格納されたCookieと、に基づいて、Cookie認証を実行する。第2認証部106は、これらが一致するか否かを判定する。第2認証部106は、これらが一致する場合には認証成功と判定し、これらが一致しない場合には認証失敗と判定する。別の言い方をすれば、第2認証部106は、ユーザ端末30から受信したCookieがユーザデータベースに存在するか否かを判定する。第2認証部106は、ユーザ端末30から受信したCookieがユーザデータベースに存在する場合には認証成功と判定し、存在しない場合には認証失敗と判定する。
本実施形態では、Cookieに有効期限が設定されているので、第2認証部106は、Cookieに設定された有効期限に基づいて、Cookie認証を行う。第2認証部106は、リアルタイムクロック等を利用して現在日時を取得し、Cookieに設定された有効期限が経過しているか否かを判定する。第2認証部106は、有効期限が経過していると判定した場合は認証失敗とし、有効期限が経過していない場合は認証成功とする。
なお、Cookieの有効期限が経過しているか否かは、ユーザ端末30において判定されてもよい。この場合、第2認証部106は、ユーザ端末30から当該判定結果だけを受信するようにしてもよい。例えば、第2認証部106は、Cookieの有効期限が経過していない旨の判定結果を受信した場合は認証失敗とし、Cookieの有効期限が経過している旨の判定結果を受信した場合は認証成功としてもよい。また、第2認証部106によりCookie認証が失敗したと判定された場合は、第1認証部103によるログイン認証が再び実行され、Cookieの再発行と、参照系トークンの再発行と、が実行されてもよい。
[第3認証部]
第3認証部107は、第2の認証が成功した場合に、ユーザ端末30との間で暗証番号認証を行う。
暗証番号認証は、本発明に係る第3の認証の一例である。このため、本実施形態で暗証番号認証と記載した箇所は、第3の認証と読み替えることができる。第3の認証は、第2の認証とは異なる認証方法であればよい。本実施形態では、第2の認証は、第1の認証時に発行されたユーザ認証情報が用いられる認証なので、第3の認証は、第1の認証前からユーザとAPI提供システム1とが互いに保有している認証情報を利用して実行される。また例えば、第1の認証、第2の認証、及び第3の認証の各々で用いられる認証情報は、異なるデータベースで別管理することによってセキュリティ性を高めてもよい。
例えば、本実施形態では、第2の認証でCookieが利用され、第3の認証で暗証番号が利用される場合を説明するが、第3の認証では、第2の認証で用いられるCookie以外の情報が用いられるようにすればよく、暗証番号以外にも、電子証明書、暗号キー、又はパスコードが利用されてもよい。また例えば、第3の認証は、第1の認証と同じ認証方法(例えば、ログイン認証等)であってもよいが、本実施形態では、よりセキュリティ性を高めるために、第3の認証が第1の認証と異なる認証方法とし、暗証番号認証が用いられる場合を説明する。
例えば、第3認証部107は、暗証番号認証が行われる場合に、更新系API101の利用要求の内容をユーザ端末30に表示させてもよい。利用要求の内容とは、更新系API101に対する命令内容であり、更新系API101のプログラムの引数となりうる情報である。例えば、更新系API101によって振込処理が実行される場合には、振込先の口座情報や振込金額といった情報である。また例えば、更新系API101によって入出金処理が実行される場合には、入出金額や入出金者といった情報である。
例えば、第3認証部107は、Cookie認証が成功した場合に、図3に示す暗証番号入力画面G6をユーザ端末30に表示させる。第3認証部107は、仲介システム2から受信した利用要求に含まれる情報を参照し、更新系API101の利用要求の内容を取得する。第3認証部107は、当該取得した内容に基づいて、暗証番号入力画面G6の表示内容を決定し、ユーザ端末30に表示させる。
なお、更新系API101の利用要求の内容は、暗証番号が入力される前に表示されるようにすればよく、必ずしも暗証番号を入力する画面と同じ画面で表示させなくてもよい。例えば、更新系API101の利用要求の内容は、暗証番号入力画面G6を表示させる前の画面で表示させてもよいし、暗証番号入力画面G6のポップアップとして表示されてもよい。
[第2発行部]
第2発行部108は、Cookie認証が成功した場合に、仲介システム2に、更新系API101を利用するための更新系トークンを発行する。
更新系トークンは、本発明に係る第2の認証情報の一例である。このため、本実施形態で更新系トークンと記載した箇所は、第2の認証情報と読み替えることができる。第2の認証情報は、第2のAPIの利用が認証されたユーザを識別する情報である。なお、第2の認証情報は、トークンに限られず、例えば、電子証明書、暗号キー、又はパスコードといった情報であってもよい。ただし、第2の認証情報は、ユーザ認証情報及び第1の認証情報とは異なる情報であるものとする。第2の認証情報の発行方法自体は、公知の種々の手法を適用可能であり、第2の認証情報の内容に応じたアルゴリズムを用意しておき、第2発行部108は、当該アルゴリズムに基づいて、第2の認証情報を発行すればよい。本実施形態のように、トークンを第2の認証情報として利用する場合には、例えば、OAuth2.0で実装されているトークン生成方法を利用すればよい。
本実施形態では、更新系API101の利用要求を受信した場合に、Cookie認証と暗証番号認証が実行されるので、第2発行部108は、Cookie認証が成功し、かつ、暗証番号認証が成功した場合に、更新系トークンを発行する。第2発行部108は、Cookie認証又は暗証番号認証の何れか一方でも失敗した場合には、更新系トークンを発行せず、Cookie認証と暗証番号認証の両方が成功した場合に、更新系トークンを発行する。
例えば、更新系トークンには、特に有効期限が設定されていなくてもよいが、本実施形態では、第2発行部108は、更新系トークンに有効期限を設定する。更新系トークンの有効期限は、任意の長さであればよく、参照系トークンと同じ長さとしてもよいが、本実施形態では、第2発行部108は、Cookieに、参照系トークンよりも短い有効期限を設定する場合を説明する。例えば、参照系トークンの有効期限を10分〜1時間程度とする場合、更新系トークンの有効期限は数十秒〜数分程度であってもよい。
なお、本実施形態では、第2発行部108は、更新系トークンのアクセストークン(以降、単に更新系アクセストークンと記載する。)だけを発行し、更新系トークンのリフレッシュトークン(以降、単に更新系リフレッシュトークンと記載する。)は発行しないものとして説明するが、更新系リフレッシュトークンを発行してもよい。ただし、この場合も、更新系リフレッシュトークンの有効期限は、参照系リフレッシュトークンの有効期限よりも短いものとする。
また例えば、第2発行部108は、更新系トークンに基づく更新系API101の利用期間が所定期間未満となるように、更新系トークンを発行してもよい。当該所定期間は、任意の長さを設定すればよいが、例えば、更新系トークンのアクセストークン(以降、単に更新系アクセストークンと記載する。)については数十秒〜数分程度とし、更新系トークンを実質的にワンタイム化してもよい。例えば、第2発行部108は、利用期間が1分未満の更新系トークンを発行する。
なお、第2発行部108は、更新系トークンに基づく更新系API101の提供回数(利用回数)が所定回数未満となるように、更新系トークンを発行してもよい。即ち、有効期限ではなく、更新系トークンの使用回数に上限値を設けるようにしてもよい。例えば、上限値としては、1回に限られず、2回又は3回以上であってもよいが、上限値を少なく設定した方がセキュリティを高くすることができる。この場合、更新系API101の提供回数を示す情報は、ユーザデータベース等に格納しておけばよい。後述する第2提供部109は、更新系API101の提供回数が上限値に達したか否かを判定し、更新系トークンの有効性を判断してもよい。
なお、上記では、Cookie認証が成功した場合に、第2発行部108が更新系トークンを発行する処理を説明したが、Cookie認証が失敗した場合には、第1認証部103は、ユーザ端末30との間で再度のログイン認証を行うようにしてもよい。再度のログイン認証は、1回目と全く同じ方法であってもよいし、1回目とは異なる認証方法であってもよい。例えば、1回目のログイン認証は、ユーザアカウントパスワードの組み合わせを利用して、再度のログイン認証は、当該組み合わせに追加して他の情報を利用してもよい。
第1発行部104は、再度のログイン認証が成功した場合に、ユーザ端末30に新たなCookieを発行する。Cookieの発行方法自体は、先述した通りである。この場合に、第2認証部106は、新たなCookieに基づく再度のCookie認証を行うようにしてもよい。Cookie認証の認証方法自体も、先述した通りである。再度のCookie認証が成功した場合には、暗証番号認証に進むようにすればよい。
[第2提供部]
第2提供部109は、仲介システム2から受信した更新系トークンに基づいて、更新系API101を提供する。例えば、第2提供部109は、仲介システム2から更新系トークンを受信し、当該更新系トークンの正当性を確認する。第2提供部109は、仲介システム2から受信した更新系トークンと、ユーザデータベースに格納された更新系トークンと、が一致するか否かを判定する。第2提供部109は、これらが一致しない場合には、更新系API101を提供せず、これらが一致する場合に、更新系API101を提供する。
なお、APIを提供するという言葉の意味は、第1提供部105で説明した通りである。更新系API101であれば、口座データベースに格納された口座情報を更新する機能が関連付けられているので、第2提供部109は、口座データベースに格納された口座情報に基づいて振込処理を実行したり入出金処理を実行したりすることによって、更新系API101を提供する。なお、口座情報を更新とは、口座情報の内容を変更することであり、例えば、口座残高の数値を変更したり、入出金明細情報に情報を追加したりすることである。
例えば、第2提供部109は、振込処理によって振り込まれた金額に基づいて、口座残高を減少させ、振込内容に基づいて、入出金明細情報を更新する。また例えば、第2提供部109は、入金処理によって入金された金額に基づいて、口座残高を増加させ、入金内容に基づいて、入出金明細情報を更新する。また例えば、第2提供部109は、出金処理によって出金された金額に基づいて、口座残高を減少させ、出金内容に基づいて、入出金明細情報を更新する。
本実施形態では、参照系トークンよりも短い有効期限が更新系トークンに設定されているので、第2提供部109は、更新系トークンに設定された、参照系トークンよりも短い有効期限に基づいて、第2のAPIを提供することになる。第2提供部109は、リアルタイムクロック等を利用して現在日時を取得し、更新系トークンに設定された有効期限が経過しているか否かを判定する。第2提供部109は、有効期限が経過していると判定した場合は更新系API101を提供せず、有効期限が経過していないと判定された場合は更新系API101を提供する。
[仲介システムとユーザ端末で実現される機能]
仲介システム2では、例えば、仲介サーバ20の記憶部22は、仲介システム2のユーザアカウントとパスワードなどのデータベースを記憶する。ユーザによる仲介システム2へのログインは、当該データベースに基づいて実行される。また例えば、記憶部22は、ユーザアカウントに関連付けて、第1発行部104が発行した参照系トークンと、第2発行部108が発行した更新系トークンと、を記憶する。また例えば、API提供システム1のユーザアカウントと、仲介システム2のユーザアカウントと、が連携されてもよく、これらの対応関係が記憶部22に記憶されてもよい。同様の対応関係は、API提供システム1のデータ記憶部102に記憶されてもよい。
ユーザ端末30では、例えば、記憶部32は、第1発行部104が発行したCookieを記憶する。また例えば、制御部31は、操作部34が受け付けた操作内容を、通信部33を介してAPI提供システム1又は仲介システム2に送信する。また例えば、制御部31は、通信部33を介してAPI提供システム1又は仲介システム2から受信したデータに基づいて、図2及び図3で説明した各種画面を表示部35に表示させる。
[4.本実施形態において実行される処理]
図7−図10は、本実施形態において実行される処理のフロー図である。図7−図10に示す処理は、制御部11が記憶部12に記憶されたプログラムに従って動作し、制御部21が記憶部22に記憶されたプログラムに従って動作し、制御部31が記憶部32に記憶されたプログラムに従って動作することによって実行される。これらの処理は、各機能ブロックが実行する処理の一例である。
図7に示すように、まず、ユーザ端末30において、仲介システム2が提供するサービスのアプリケーションが起動したり、仲介システム2のウェブサイトのURLが入力されたりすると、制御部31は、仲介システム2にアクセスする(S1)。仲介システム2においては、アクセスを受け付けると、仲介サーバ20の制御部21は、ユーザ端末30に対し、ログイン画面G1の表示データを送信する(S2)。表示データは、ユーザ端末30に画面を表示させるためのデータであればよく、例えば、HTMLデータであってもよいし、アプリ内の画面フレームにはめ込む画像やテキストであってもよい。
ユーザ端末30においては、表示データを受信すると、制御部31は、ログイン画面G1を表示部35に表示させる(S3)。ログイン画面G1から入力されたユーザアカウントとパスワードが仲介システム2に送信され、仲介サーバ20の制御部21は、ログイン認証を実行する(S4)。S3においては、ユーザ端末30は、ユーザがログイン画面G1で入力したユーザアカウントとパスワードの組み合わせを送信し、S4においては、仲介システム2は、記憶部22に記憶された当該組み合わせと一致するか否かを判定する。
S4におけるログイン認証が失敗した場合、所定のエラーメッセージがユーザ端末30に表示され、S3の処理に戻る。一方、S4におけるログイン認証が成功すると、仲介サーバ20の制御部21は、所定のログイン処理を実行し、ユーザ端末30に対し、メニュー画面G2の表示データを送信する(S5)。
ユーザ端末30においては、表示データを受信すると、制御部31は、メニュー画面G2を表示部35に表示させる(S6)。制御部31は、操作部34の検出信号に基づいて、仲介システム2に対し、ユーザの要求を送信する(S7)。S7においては、会計業務支援サービスに係る種々の要求が送信されてよいが、ここでは説明の簡略化のために、入出金明細の照会要求、又は、振込処理の実行要求の何れかが送信される場合を説明する。例えば、入出金明細の照会要求は、メニュー画面G2の入出金明細照会の項目が選択された場合に送信され、振込処理の実行要求は、メニュー画面G2の振込処理の項目が選択された後に、振込内容入力画面G5において振込内容が入力された場合に送信される。
仲介システム2においては、要求を受信すると、仲介サーバ20の制御部21は、参照系API100又は更新系API101の何れの利用要求を受信したかを判定する(S8)。S8においては、入出金明細の照会要求であれば、参照系API100の利用要求であると判定され、振込処理の実行要求であれば、更新系API101の利用要求であると判定される。
参照系API100の利用要求であると判定された場合(S8;参照系)、制御部21は、ユーザの参照系トークンが記憶部22に記録されているか否かを判定する(S9)。S9においては、制御部21は、仲介システム2のユーザアカウントに関連付けて、参照系トークンが記憶部22に記憶されているか否かを判定する。参照系トークンが記録されていないと判定された場合(S9;N)、仲介システム2とAPI提供システム1との間で、参照系トークンを発行するための参照系トークン発行処理が実行される(S10)。
図8は、参照系トークン発行処理の詳細を示す図である。図8に示すように、仲介システム2において、仲介サーバ20の制御部21は、API提供システム1へのリダイレクトを実行する(S101)。API提供システム1のURLが予め記憶部22に記憶されており、S101においては、制御部21は、当該URLに基づいてリダイレクトを実行する。なお、先述したように、API提供システム1へのリダイレクトが実行される旨を予めユーザ端末30に表示させ、ユーザの同意を得てもよいし、リダイレクト処理がユーザ端末30において実行されてもよい。
S101におけるリダイレクトが実行されると、ユーザ端末30がAPI提供システム1にアクセスし、API提供システム1において、API提供サーバ10の制御部11は、ユーザ端末30に対し、ログイン画面G3の表示データを送信する(S102)。
ユーザ端末30においては、表示データを受信すると、制御部31は、ログイン画面G3を表示部35に表示させる(S103)。ログイン画面G3から入力されたユーザアカウントとパスワードがAPI提供システム1に送信され、API提供サーバ10の制御部11は、ログイン認証を実行する(S104)。S104においては、ユーザ端末30は、ユーザがログイン画面G3で入力したユーザアカウントとパスワードの組み合わせを送信し、API提供システム1は、ユーザデータベースに格納された当該組み合わせと一致するか否かを判定する。
S104におけるログイン認証が失敗した場合、所定のエラーメッセージがユーザ端末30に表示され、S103の処理に戻る。一方、S104におけるログイン認証が成功すると、API提供サーバ10の制御部11は、所定のログイン処理を実行してCookieを発行し、ユーザ端末30に対し、Cookieを送信する(S105)。S105においては、制御部11は、リアルタイムクロック等から取得した現在日時の所定時間後の時間をCookieの有効期限に設定する。先述したように、Cookieは、所定の関数に基づいて発行されるようにすればよい。なお、S104におけるログイン処理が成功した後は、ユーザ端末30がAPI提供システム1と通信する場合には、API提供システム1のユーザアカウントが適宜送信されるものとする。ユーザ端末30においては、Cookieを受信すると、制御部31は、Cookieを記憶部32に記録する(S106)。
また、API提供サーバ10の制御部11は、仲介システム2に対し、所定の認可コードを送信する(S107)。S107で送信される認可コードは、ログイン認証が成功し、参照系トークンの発行が許可されたことを示す情報である。仲介システム2においては、認可コードを受信すると、仲介サーバ20の制御部21は、参照系トークンの発行要求を送信する(S108)。参照系トークンの発行要求は、例えば、OAuth2.0のプロトコルで定められた所定形式の情報が送信されることで行われる。
API提供システム1においては、発行要求を受信すると、API提供サーバ10の制御部11は、参照系トークンを発行する(S109)。S109においては、制御部11は、記憶部12のユーザデータベースに、API提供システム1のユーザアカウントと関連付けて、発行した参照系トークンを格納する。制御部11は、仲介システム2に対し、S109で発行した参照系トークンを送信する(S110)。仲介システム2においては、参照系トークンを受信すると、仲介サーバ20の制御部21は、参照系トークンを記憶部22に記録する(S111)。S111においては、例えば、制御部21は、仲介システム2のユーザアカウントと関連付けて、参照系トークンを記録する。
以上の処理によって参照系トークンが発行されると、図7に戻り、仲介システム2においては、仲介サーバ20の制御部21は、S10で発行された参照系トークンに基づいて、参照系API100の利用要求を送信する(S11)。参照系API100の利用要求には、参照する口座を識別するための情報が含まれているものとする。例えば、仲介サーバ20の記憶部22に、ユーザごとに支店名と口座番号の組み合わせを記憶しておき、当該組み合わせを利用要求に含めてもよいし、API提供システム1と仲介システム2とで互いのユーザアカウントを連携しておき、API提供システム1又は仲介システム2のユーザアカウントを利用要求に含めることで、ユーザの口座が特定されてもよい。
API提供システム1においては、参照系API100の利用要求を受信すると、API提供サーバ10の制御部11は、ユーザデータベースに基づいて、参照系アクセストークンが有効か否かを判定する(S12)。S12においては、制御部11は、参照系アクセストークンの有効期限内であるか否かを判定する。
参照系アクセストークンが有効であると判定された場合(S12;Y)、制御部11は、口座データベースに基づいて、参照系API100の応答として、仲介システム2に対し、入出金明細の照会結果を送信する(S13)。S13においては、制御部11は、参照系API100の利用要求に基づいて、参照対象となる口座を特定する。そして、制御部11は、当該口座の入出金明細情報を取得して、照会結果として送信する。
仲介システム2においては、入出金明細の照会結果を受信すると、仲介サーバ20の制御部21は、受信した照会結果に基づいて、ユーザ端末30に対し、入出金明細画面G4の表示データを送信する(S14)。ユーザ端末30においては、表示データを受信すると、入出金明細画面G4を表示部35に表示させる(S15)。なお、ユーザがメニュー画面G2に戻る操作をした場合には、S6の処理に戻る。
一方、S12において、参照系アクセストークンが無効であると判定された場合(S12;N)、図9に移り、制御部11は、仲介システム2に対し、参照系アクセストークンが無効である旨の無効エラー通知を送信する(S16)。無効エラー通知は、例えば、OAuth2.0のプロトコルで定められた所定形式の情報が送信されることで行われる。
仲介システム2においては、無効エラー通知を受信すると、仲介サーバ20の制御部21は、記憶部22に記憶された参照系リフレッシュトークンを送信する(S17)。API提供システム1においては、参照系リフレッシュトークンを受信すると、API提供サーバ10の制御部11は、記憶部12に記憶されたユーザデータベースに基づいて、受信したリフレッシュトークンが有効か否かを判定する(S18)。S18においては、制御部11は、リフレッシュトークンの有効期限内であるか否かを判定する。
参照系トークンのリフレッシュトークンが無効であると判定された場合(S18;N)、制御部11は、仲介システム2に対し、リフレッシュトークンが無効である旨の無効エラー通知を送信し(S19)、S10の参照系トークン発行処理に移行する。この場合、図8に示す参照系トークン発行処理が再び実行され、ログイン認証が成功すると、ユーザ端末30にCookieが送信され、仲介システム2に新たな参照系トークンが送信される。
一方、S18において、参照系リフレッシュトークンが有効であると判定された場合(S18;Y)、制御部11は、参照系アクセストークンを再発行し、仲介システム2に対し、当該再発行した参照系アクセストークンを送信する(S20)。S20の処理は、S109の処理と同様であるが、S20では、参照系アクセストークンだけが発行される。なお、参照系リフレッシュトークンの有効期限は延長されるようにしてよい。
仲介システム2においては、参照系アクセストークンを受信すると、仲介サーバ20の制御部21は、参照系アクセストークンを記憶部22に記録する(S21)。S21においては、例えば、制御部21は、仲介システム2のユーザアカウントと関連付けて、参照系アクセストークンを記録する。その後、S11の処理に移行する。
一方、図7のS8において、更新系API101の利用要求であると判定された場合(S8;更新系)、図10に移り、制御部21は、API提供システム1に対し、更新系アクセストークンの発行要求を送信する(S22)。更新系アクセストークンの発行要求は、例えば、OAuth2.0のプロトコルで定められた所定形式の情報が送信されることで行われる。
API提供システム1においては、要求を受信すると、API提供サーバ10の制御部11は、ユーザ端末30との間でCookie認証を実行する(S23)。S23においては、API提供サーバ10は、ユーザ端末30にCookieの送信を要求し、ユーザ端末30は、当該要求に応じて、記憶部32に記憶されたCookie(S106で記録されたCookie)を送信する。
なお、Cookieに有効期限を設定する場合には、S23において、制御部11は、Cookieが有効期限内であるか否かを判定してもよいし、ユーザ端末30においてCookieが有効期限内であるか否かが判定されてもよい。更に、ユーザ端末30においてCookieが有効ではないと判定された場合には、S23のCookie認証が実行されることなく、S10における参照系トークン発行処理が実行され、Cookieが再発行されてもよい。
S23において、Cookie認証に失敗した場合(S23;N)、仲介システム2とAPI提供システム1との間で参照系トークン発行処理が実行され(S24)、S22の処理に戻る。S24の処理は、S10の処理と同様であり、図8に示す参照系トークン発行処理が実行され、ログイン認証が成功すると、ユーザ端末30にCookieが送信され、仲介システム2に新たな参照系トークンが送信される。これにより、S22の処理に戻ると、S23において、Cookie認証が成功する。
一方、S23において、Cookie認証に成功した場合(S23;Y)、API提供サーバ10の制御部11は、ユーザ端末30に対し、暗証番号入力画面G6の表示データを送信する(S25)。なお、S22における更新系アクセストークンの発行要求とともに、振込内容入力画面G5において入力された振込内容が送信され、S25においては、制御部11は、当該振込内容を含む暗証番号入力画面G6の表示データを送信してもよい。
ユーザ端末30においては、表示データを受信すると、制御部31は、暗証番号入力画面G6を表示部35に表示させる(S26)。S26においては、振込内容とともに、暗証番号を入力することができる状態となる。暗証番号入力画面G6から入力された暗証番号がAPI提供システム1に送信され、API提供サーバ10の制御部11は、暗証番号認証を実行する(S27)。S27においては、ユーザ端末30は、ユーザが暗証番号入力画面G6で入力した暗証番号を送信し、API提供システム1は、口座データベースに格納された暗証番号と一致するか否かを判定する。
S27における暗証番号認証が失敗した場合、所定のエラーメッセージがユーザ端末30に表示され、S26の処理に戻る。一方、S27における暗証番号認証が成功すると、API提供サーバ10の制御部11は、仲介システム2に対し、所定の認可コードを送信する(S28)。S28で送信される認可コードは、暗証番号認証が成功し、更新系アクセストークンの発行が許可されたことを示す情報である。仲介システム2においては、認可コードを受信すると、仲介サーバ20の制御部21は、更新系アクセストークンの発行要求を送信する(S29)。
API提供システム1においては、発行要求を受信すると、API提供サーバ10の制御部11は、更新系アクセストークンを発行する(S30)。S30においては、制御部11は、記憶部12のユーザデータベースに、API提供システム1のユーザアカウントと関連付けて、発行した更新系アクセストークンを格納する。制御部11は、仲介システム2に対し、S30で発行した更新系アクセストークンを送信する(S31)。
仲介システム2においては、更新系アクセストークンを受信すると、仲介サーバ20の制御部21は、更新系アクセストークンを記憶部22に格納する(S32)。S32においては、例えば、制御部21は、仲介システム2のユーザアカウントと関連付けて、更新系アクセストークンを記録する。制御部21は、発行された更新系アクセストークンに基づいて、更新系API101の利用要求を送信する(S33)。更新系API100の利用要求には、振込内容を示す情報が含まれていてもよいし、振込内容は、S22の処理の時点で送信されていてもよい。
API提供システム1においては、更新系API101の利用要求を受信すると、API提供サーバ10の制御部11は、ユーザデータベースに基づいて、更新系アクセストークンが有効か否かを判定する(S34)。S34においては、制御部11は、アクセストークンの有効期限内であるか否かを判定する。
更新系アクセストークンが無効であると判定された場合(S34;N)、更新系アクセストークンが無効である旨の無効エラー通知が仲介システム2に送信され、S22の処理に戻る。この場合、更新系アクセストークンの発行がやり直される。一方、更新系アクセストークンが有効であると判定された場合(S34;Y)、制御部11は、更新系API101の応答として、振込処理を実行する(S35)。S35においては、制御部11は、振込内容入力画面G5において入力された内容の振込を実行し、口座データベースを更新する。
制御部11は、仲介システム2に対し、S35における振込処理の実行結果を送信する(S36)。仲介システム2においては、振込処理の実行結果を受信すると、仲介サーバ20の制御部21は、受信した実行結果に基づいて、ユーザ端末30に対し、振込完了画面G7の表示データを送信する(S37)。ユーザ端末30においては、表示データを受信すると、振込完了画面G7を表示部35に表示させる(S38)。なお、ユーザがメニュー画面G2に戻る操作をした場合には、S6の処理に戻る。
API提供システム1によれば、参照系API100の利用要求が送信された場合のログイン認証でCookieが発行されてユーザ端末30に記憶され、更新系API101の利用要求が送信された場合にCookie認証が実行される。これにより、参照系API100を利用するユーザが更新系API101を利用しようとしていること(即ち、参照系の権限を与えたユーザ端末30と同じ端末であること)を確認することができるので、仲介システム2を介して複数のAPIを提供する場合のセキュリティを高めることができる。また、更新系API101を利用するためには、少なくとも、参照系API100の利用時のログイン認証と、Cookie認証と、の2段階の認証をする必要があるため、セキュリティ性を高めることができる。また、更新系の認証ではログイン認証が行われないので、ユーザがユーザアカウントとパスワードを2回入力するといった手間を省くことができる。更に、異なる種類の認証情報を用いることで、よりセキュリティ性を高めることができる。
また、更新系API101を利用するための暗証番号認証は、Cookie認証が成功しないと実行されないので、更新系API101を利用するための認証を複数回実行することで、セキュリティを効果的に高めることができる。また、暗証番号認証を実行する場合には、更新系API101を利用するためには、少なくとも、参照系API100の利用時のログイン認証、Cookie認証、及び暗証番号認証の3段階の認証をする必要があるため、セキュリティ性を効果的に高めることができる。更に、これら3つの認証を異なる種類の認証情報で実行することで、よりセキュリティ性を高めることができる。
また、更新系API101を利用するための暗証番号認証の際に、振込内容が表示されるので、悪意のある第三者による不正な振込に未然に気付くことができる。例えば、仲介システム2がハッキング等の不正アクセスを受け、ユーザの身に覚えのない振込が第三者によって試みられたり(例えば、振込内容入力画面G5においてユーザが振込内容を入力することなく、第三者の手によって振込内容が不正に入力される等)、ユーザによる振込手続き中に第三者によって不正に割り込まれて振込先や金額の改ざんがなされようとしたりしている(例えば、振込内容入力画面G5においてユーザが振込内容を入力してから、暗証番号入力画面G6が表示されるまでの間に、第三者によって改ざんが行われる)ことを発見することができる。
また、Cookieに有効期限を設けることで、セキュリティを効果的に高めることができる。
また、更新系アクセストークンの有効期限を、参照系アクセストークンの有効期限よりも短く設定することで、セキュリティを効果的に高めることができる。
また、更新系アクセストークンに基づく更新系API101の提供回数や利用期間に制限を設けることで、セキュリティを効果的に高めることができる。例えば、更新系アクセストークンをワンタイム化することで、セキュリティを効果的に高めることができる。
また、Cookie認証に失敗した場合には、参照系トークン発行処理が実行され、ログイン認証からやり直されるので、セキュリティを効果的に高めることができる。
[5.変形例]
なお、本発明は、以上に説明した実施の形態に限定されるものではない。本発明の趣旨を逸脱しない範囲で、適宜変更可能である。
例えば、Cookie認証の後に暗証番号認証が実行される場合を説明したが、Cookie認証の前に暗証番号認証が実行されてもよい。また例えば、API提供システム1は、第3認証部107を省略し、暗証番号認証は省略してもよい。
また例えば、API提供システム1では、参照系API100、更新系API101、データ記憶部102、第1認証部103、第1発行部104、第1提供部105、第2認証部106、第3認証部107、第2発行部108、及び第2提供部109が、API提供サーバ10で実現される場合を説明したが、これら各機能は、API提供システム1内の複数のコンピュータで分担されてもよい。
例えば、API提供システム1がAPI提供サーバ10とは別にデータベースサーバを有する場合には、データ記憶部102は、データベースサーバにより実現されてもよい。また例えば、API提供システム1がAPI提供サーバ10とは別に認証サーバを有する場合には、参照系API100、更新系API101、第1提供部105、及び第2提供部109がAPI提供サーバ10によって実現され、第1認証部103、第1発行部104、第2認証部106、第3認証部107、及び第2発行部108が認証サーバによって実現されてもよい。
また例えば、API提供システム1が、複数のAPI提供サーバ10を有する場合には、第1のAPI提供サーバ10によって参照系API100が実現され、第2のAPI提供サーバ10によって更新系API101が実現されてもよい。また例えば、API提供システム1が、複数の認証サーバを有する場合には、第1の認証サーバによって、第1認証部103と第1発行部104が実現され、第2の認証サーバによって、第2認証部106、第3認証部107、及び第2発行部108が実現されてもよい。
また例えば、API提供システム1のAPIによって金融サービスが提供される場合を説明したが、APIが提供するサービスは、任意のサービスであってよい。例えば、電子商取引において、商品ページを参照する参照系APIと、商品ページの編集するための編集系APIと、のセキュリティレベルを分けて、編集系APIに実施形態で説明したCookie認証を導入してもよい。また例えば、保険サービスにおいて、保険商品の参照をするための閲覧系APIと、保険商品の編集をするための編集系APIと、のセキュリティレベルを分けて、編集系APIに実施形態で説明したCookie認証を導入してもよい。また例えば、旅行予約サービスにおいて、旅行商品の閲覧をするための閲覧系APIと、旅行商品の編集をするための編集系APIと、のセキュリティレベルを分けて、編集系APIに実施形態で説明したCookie認証を導入してもよい。また例えば、SNSにおいて、自分や他人の投稿を閲覧するための閲覧系APIと、新規投稿をするための投稿系APIと、のセキュリティレベルを分けて、投稿系APIに実施形態で説明したCookie認証を導入してもよい。
1 API提供システム、10 API提供サーバ、11,21,31 制御部、12,22,32 記憶部、13,23,33 通信部、2 仲介システム、20 仲介サーバ、30 ユーザ端末、34 操作部、35 表示部、G1 ログイン画面、G2 メニュー画面、G3 ログイン画面、G4 入出金明細画面、G5 振込内容入力画面、G6 暗証番号入力画面、G7 振込完了画面、100 参照系API、101 更新系API、102 データ記憶部、103 第1認証部、104 第1発行部、105 第1提供部、106 第2認証部、107 第3認証部、108 第2発行部、109 第2提供部。

Claims (10)

  1. 仲介システムを介して複数のAPIを提供するAPI提供システムであって、
    ユーザ端末から前記仲介システムに第1のAPIの利用要求が送信された場合に、当該利用要求に基づくリダイレクトを受けて、前記ユーザ端末との間で第1の認証を行う第1認証手段と、
    前記第1の認証が成功した場合に、前記ユーザ端末にユーザ認証情報を発行し、前記仲介システムに、前記第1のAPIを利用するための第1の認証情報を発行する第1発行手段と、
    前記仲介システムから受信した前記第1の認証情報に基づいて、前記第1のAPIを提供する第1提供手段と、
    前記ユーザ端末から前記仲介システムに第2のAPIの利用要求が送信された場合に、当該利用要求に基づくリダイレクトを受けて、前記ユーザ端末との間で、前記第1発行手段により発行された前記ユーザ認証情報に基づく第2の認証を行う第2認証手段と、
    前記第2の認証が成功した場合に、前記仲介システムに、前記第2のAPIを利用するための第2の認証情報を発行する第2発行手段と、
    前記仲介システムから受信した前記第2の認証情報に基づいて、前記第2のAPIを提供する第2提供手段と、
    を含み、
    前記第1認証手段は、前記第2の認証が失敗した場合に、前記ユーザ端末との間で再度の前記第1の認証を行い、
    前記第1発行手段は、前記再度の第1の認証が成功した場合に、前記ユーザ端末に新たなユーザ認証情報と、前記仲介システムに新たな前記第1の認証情報と、を発行し、
    前記第1提供手段は、前記仲介システムから受信した前記新たな第1の認証情報に基づいて、前記第1のAPIを提供し、
    前記第2認証手段は、前記新たなユーザ認証情報に基づく再度の前記第2の認証を行う、
    ことを特徴とするAPI提供システム。
  2. 前記第1発行手段は、前記第1の認証情報に有効期限を設定し、
    前記第1発行手段は、前記再度の第1の認証が成功した場合に、前記新たな第1の認証情報に新たな有効期限を設定する、
    ことを特徴とする請求項1に記載のAPI提供システム。
  3. 前記API提供システムは、前記第2の認証が成功した場合に、前記ユーザ端末との間で第3の認証を行う第3認証手段を更に含み、
    前記第2発行手段は、前記第2の認証が成功し、かつ、前記第3の認証が成功した場合に、前記第2の認証情報を発行する、
    ことを特徴とする請求項1又は2に記載のAPI提供システム。
  4. 前記第3認証手段は、前記第3の認証が行われる場合に、前記第2のAPIの利用要求の内容を前記ユーザ端末に表示させる、
    ことを特徴とする請求項3に記載のAPI提供システム。
  5. 前記第1発行手段は、前記ユーザ認証情報に有効期限を設定し、
    前記第2認証手段は、前記ユーザ認証情報に設定された有効期限に基づいて、前記第2の認証を行う、
    ことを特徴とする請求項1〜4の何れかに記載のAPI提供システム。
  6. 前記第1発行手段は、前記第1の認証情報に有効期限を設定し、
    前記第1提供手段は、前記第1の認証情報に設定された有効期限に基づいて、前記第1のAPIを提供し、
    前記第2発行手段は、前記第2の認証情報に、前記第1の認証情報よりも短い有効期限を設定し、
    前記第2提供手段は、前記第2の認証情報に設定された、前記第1の認証情報よりも短い有効期限に基づいて、前記第2のAPIを提供する、
    ことを特徴とする請求項1〜5の何れかに記載のAPI提供システム。
  7. 前記第2発行手段は、前記第2の認証情報に基づく前記第2のAPIの提供回数又は利用期間が所定回数又は所定期間未満となるように、前記第2の認証情報を発行する、
    ことを特徴とする請求項1〜6の何れかに記載のAPI提供システム。
  8. 仲介システムを介して複数のAPIを提供するための認証サーバであって、
    ユーザ端末から前記仲介システムに第1のAPIの利用要求が送信された場合に、当該利用要求に基づくリダイレクトを受けて、前記ユーザ端末との間で第1の認証を行う第1認証手段と、
    前記第1の認証が成功した場合に、前記ユーザ端末にユーザ認証情報を発行し、前記仲介システムに、前記第1のAPIを利用するための第1の認証情報を発行する第1発行手段と、
    前記ユーザ端末から前記仲介システムに第2のAPIの利用要求が送信された場合に、当該利用要求に基づくリダイレクトを受けて、前記ユーザ端末との間で、前記ユーザ認証情報に基づく第2の認証を行う第2認証手段と、
    前記第2の認証が成功した場合に、前記仲介システムに、前記第2のAPIを利用するための第2の認証情報を発行する第2発行手段と、
    を含み、
    前記第1認証手段は、前記第2の認証が失敗した場合に、前記ユーザ端末との間で再度の前記第1の認証を行い、
    前記第1発行手段は、前記再度の第1の認証が成功した場合に、前記ユーザ端末に新たなユーザ認証情報と、前記仲介システムに新たな前記第1の認証情報と、を発行し
    記第2認証手段は、前記新たなユーザ認証情報に基づく再度の前記第2の認証を行う、
    ことを特徴とする認証サーバ。
  9. 仲介システムを介して複数のAPIを提供するAPI提供方法であって、
    ユーザ端末から前記仲介システムに第1のAPIの利用要求が送信された場合に、当該利用要求に基づくリダイレクトを受けて、前記ユーザ端末との間で第1の認証を行う第1認証ステップと、
    前記第1の認証が成功した場合に、前記ユーザ端末にユーザ認証情報を発行し、前記仲介システムに、前記第1のAPIを利用するための第1の認証情報を発行する第1発行ステップと、
    前記仲介システムから受信した前記第1の認証情報に基づいて、前記第1のAPIを提供する第1提供ステップと、
    前記ユーザ端末から前記仲介システムに第2のAPIの利用要求が送信された場合に、当該利用要求に基づくリダイレクトを受けて、前記ユーザ端末との間で、前記ユーザ認証情報に基づく第2の認証を行う第2認証ステップと、
    前記第2の認証が成功した場合に、前記仲介システムに、前記第2のAPIを利用するための第2の認証情報を発行する第2発行ステップと、
    前記仲介システムから受信した前記第2の認証情報に基づいて、前記第2のAPIを提供する第2提供ステップと、
    を含み、
    前記第1認証ステップは、前記第2の認証が失敗した場合に、前記ユーザ端末との間で再度の前記第1の認証を行い、
    前記第1発行ステップは、前記再度の第1の認証が成功した場合に、前記ユーザ端末に新たなユーザ認証情報と、前記仲介システムに新たな前記第1の認証情報と、を発行し、
    前記第1提供ステップは、前記仲介システムから受信した前記新たな第1の認証情報に基づいて、前記第1のAPIを提供し、
    前記第2認証ステップは、前記新たなユーザ認証情報に基づく再度の前記第2の認証を行う、
    ことを特徴とするAPI提供方法。
  10. ユーザ端末から仲介システムに第1のAPIの利用要求が送信された場合に、当該利用要求に基づくリダイレクトを受けて、前記ユーザ端末との間で第1の認証を行う第1認証手段、
    前記第1の認証が成功した場合に、前記ユーザ端末にユーザ認証情報を発行し、前記仲介システムに、前記第1のAPIを利用するための第1の認証情報を発行する第1発行手段、
    前記ユーザ端末から前記仲介システムに第2のAPIの利用要求が送信された場合に、当該利用要求に基づくリダイレクトを受けて、前記ユーザ端末との間で、前記ユーザ認証情報に基づく第2の認証を行う第2認証手段、
    前記第2の認証が成功した場合に、前記仲介システムに、前記第2のAPIを利用するための第2の認証情報を発行する第2発行手段、
    としてコンピュータを機能させ、
    前記第1認証手段は、前記第2の認証が失敗した場合に、前記ユーザ端末との間で再度の前記第1の認証を行い、
    前記第1発行手段は、前記再度の第1の認証が成功した場合に、前記ユーザ端末に新たなユーザ認証情報と、前記仲介システムに新たな前記第1の認証情報と、を発行し
    記第2認証手段は、前記新たなユーザ認証情報に基づく再度の前記第2の認証を行う、
    プログラム。
JP2018052047A 2018-03-20 2018-03-20 Api提供システム、認証サーバ、api提供方法、及びプログラム Active JP6748667B2 (ja)

Priority Applications (1)

Application Number Priority Date Filing Date Title
JP2018052047A JP6748667B2 (ja) 2018-03-20 2018-03-20 Api提供システム、認証サーバ、api提供方法、及びプログラム

Applications Claiming Priority (1)

Application Number Priority Date Filing Date Title
JP2018052047A JP6748667B2 (ja) 2018-03-20 2018-03-20 Api提供システム、認証サーバ、api提供方法、及びプログラム

Publications (2)

Publication Number Publication Date
JP2019164590A JP2019164590A (ja) 2019-09-26
JP6748667B2 true JP6748667B2 (ja) 2020-09-02

Family

ID=68064525

Family Applications (1)

Application Number Title Priority Date Filing Date
JP2018052047A Active JP6748667B2 (ja) 2018-03-20 2018-03-20 Api提供システム、認証サーバ、api提供方法、及びプログラム

Country Status (1)

Country Link
JP (1) JP6748667B2 (ja)

Family Cites Families (6)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US7801775B1 (en) * 1999-03-29 2010-09-21 Amazon.Com, Inc. Method and system for authenticating users when conducting commercial transactions using a computer
JP2008197973A (ja) * 2007-02-14 2008-08-28 Mitsubishi Electric Corp ユーザ認証システム
US8726347B2 (en) * 2007-04-27 2014-05-13 International Business Machines Corporation Authentication based on previous authentications
US9130927B2 (en) * 2012-07-02 2015-09-08 Sk Planet Co., Ltd. Single certificate service system and operational method thereof
JP6265733B2 (ja) * 2013-12-25 2018-01-24 キヤノン株式会社 権限管理サーバー及び権限管理方法
US10298561B2 (en) * 2015-06-30 2019-05-21 Vmware, Inc. Providing a single session experience across multiple applications

Also Published As

Publication number Publication date
JP2019164590A (ja) 2019-09-26

Similar Documents

Publication Publication Date Title
JP2016181242A (ja) 秘密情報にアクセスするための、多重パーティ及び多重レベルの承認を可能にするシステム及び方法
KR20020015932A (ko) 데이터 센터에서 카드 정보를 처리하는 방법
US20050086068A1 (en) System and method for electronic wallet conversion
JP6448813B2 (ja) 情報処理装置および情報処理方法
JP5850587B1 (ja) 個人情報口座バンキング
CN102346832A (zh) 电子通信的增强的安全性
KR20100045059A (ko) 결제계좌와 연계된 복수의 가맹점카드 별 가상계좌 운영방법 및 시스템과 이를 위한 기록매체
KR100622086B1 (ko) 개인 식별을 위한 인증키 제공 시스템 및 방법
JP5484823B2 (ja) カードレス決済のための情報処理装置、カードレス決済システム、カードレス決済方法、キャッシュレス決済方法およびプログラム
JP2005084822A (ja) 不正利用通知方法、および不正利用通知プログラム
JP6748667B2 (ja) Api提供システム、認証サーバ、api提供方法、及びプログラム
KR20160006652A (ko) 결제계좌와 결제수단 연계 방법
KR20080022826A (ko) 비대면 채널을 통한 보안정보 제공방법 및 시스템과 이를위한 프로그램 기록매체
JP6247410B1 (ja) 振込制御システム、金融機関システム、会計システム、振込制御システムの制御方法、金融機関システムの制御方法、会計システムの制御方法、及びプログラム
JP2019087063A (ja) 入出金代行システム
JP5160803B2 (ja) 法人用ポイント交換システム及び画面制御方法
KR20100045047A (ko) 결제계좌와 연계된 복수의 체크카드 별 가상계좌 운영방법 및 시스템과 이를 위한 기록매체
KR101041113B1 (ko) 금융교육과 연계되는 금융상품 운용방법 및 시스템과 이를위한 프로그램 기록매체
KR20090001923A (ko) 수입금융 대표한도 설정 방법 및 시스템과 이를 위한프로그램 기록매체
KR20090093273A (ko) 학생증 겸용 카드발급 처리 방법 및 시스템과 이를 위한프로그램 기록매체
KR20090104215A (ko) 금매매 처리 방법 및 시스템과 이를 위한 프로그램기록매체
KR20070107846A (ko) 뱅킹 서버를 이용한 회원가입 처리 방법 및 시스템과 이를위한 프로그램 기록매체
JP2008217487A (ja) 金融処理システム、口座ロック方法
KR101004081B1 (ko) 자산유동화증권 투자처리 시스템
JP3934100B2 (ja) 金融取引方法およびシステム

Legal Events

Date Code Title Description
A621 Written request for application examination

Free format text: JAPANESE INTERMEDIATE CODE: A621

Effective date: 20181218

A977 Report on retrieval

Free format text: JAPANESE INTERMEDIATE CODE: A971007

Effective date: 20191119

A131 Notification of reasons for refusal

Free format text: JAPANESE INTERMEDIATE CODE: A131

Effective date: 20191203

A521 Written amendment

Free format text: JAPANESE INTERMEDIATE CODE: A523

Effective date: 20200131

A131 Notification of reasons for refusal

Free format text: JAPANESE INTERMEDIATE CODE: A131

Effective date: 20200519

A521 Written amendment

Free format text: JAPANESE INTERMEDIATE CODE: A523

Effective date: 20200713

TRDD Decision of grant or rejection written
A01 Written decision to grant a patent or to grant a registration (utility model)

Free format text: JAPANESE INTERMEDIATE CODE: A01

Effective date: 20200721

A61 First payment of annual fees (during grant procedure)

Free format text: JAPANESE INTERMEDIATE CODE: A61

Effective date: 20200807

R150 Certificate of patent or registration of utility model

Ref document number: 6748667

Country of ref document: JP

Free format text: JAPANESE INTERMEDIATE CODE: R150