JP6463803B2 - サービス管理システム及びサービス管理方法 - Google Patents

Description

本発明は、ＡＰＩを利用したサービスを提供するためのサービス管理システム及びサービス管理方法に関する。

今日、銀行が保有している顧客に関する金融情報の利用促進を図るために、他のシステムとの連携が検討されている（例えば、非特許文献１）。このような銀行システムから情報を取得するための銀行ＡＰＩの公開も検討されている（例えば、非特許文献２）。ここで、銀行ＡＰＩ（Application Programming Interface）とは、残高照会や資金移動等、既存機能を個別にサービス化して、外部のアプリケーションから利用するために、ソフトウェアコンポーネントが互いにやり取りするために使用するインターフェースである。このような銀行ＡＰＩを公開することにより、モバイル端末を中心とした顧客金融行動を早期にキャッチアップできる。更に、非金融機関との連携により新規市場の創出も期待できる。

また、事業者に対して、ＡＰＩを利用して会計処理を支援する技術も検討されている（例えば、特許文献１）。この文献に記載された会計処理装置は、ウェブサーバと、ウェブサーバとＶＰＮ技術により接続されたＤＢと、ＤＢとＶＰＮ技術により接続されたスクレイピングサーバとを備える。ウェブサーバは、スクレイピングサーバにより取り込んだウェブ明細データを取引ごとに識別し、各取引を、各取引の取引内容の記載に基づいて、特定の勘定科目に自動的に仕訳する。ウェブサーバは、この際、取引内容の記載を形態素に分節し、各形態素に対応づけられた１又は複数の勘定科目の出現頻度を参照して、取引内容の記載が表す勘定科目を推測する。

特開２０１６−２１１４７号公報

株式会社みずほ銀行、「ＬＩＮＥでかんたん残高照会」、［online］、株式会社みずほ銀行ホームページ、［平成２９年５月２８日検索］、インターネット＜http://www.mizuhobank.co.jp/net_shoukai/line/index.html＞ 全国銀行協会、「現代的な「金融業」のあり方」、２０１６年３月、［online］、金融調査研究会、［平成２９年５月２８日検索］、インターネット＜http://www.zenginkyo.or.jp/fileadmin/res/news/news280341_1.pdf＞

オープンＡＰＩにおいてＵＲＬが解放された場合、ＵＲＬが流出し、ＤｏＳ（Denial of Service attack）やＤＤｏＳ（Distributed Denial of Service attack）等の攻撃の対象になる可能性がある。また、このオープンＡＰＩにおいては、通信可能なＩＰアドレス及びクライアント証明書を用いてアクセス制御することが基本であるが、パブリッククラウドのＩＰアドレスなど、広く解放せざる得ないケースも想定される。

オープンＡＰＩにおいては、ＩＤ及びパスワードがハッシュ化されてトークンとして固定されるＯＡｕｔｈ認証が用いられることがある。この場合、例えば、振込と住所変更が同じアクセス権範囲（スコープ）に設定される等、ＡＰＩ提供者による誤ったスコープ設定に起因する改ざんリスクも発生する。この場合、期限付きのアクセストークンを顧客が発行するような仕組みが必要となる。

上記課題を解決するサービス管理システムは、ワンタイムＵＲＬを管理する管理サーバと、サービスを提供するＡＰＩを有するＡＰＩ中継サーバと、前記サービスを利用するサービスサーバを備える。そして、前記管理サーバが、ユーザの本人認証に基づいて、前記ＡＰＩ中継サーバにアクセスするためのワンタイムＵＲＬを発行し、ユーザ情報に関連付けてワンタイムＵＲＬをＵＲＬ記憶部に記録し、ユーザ情報とともに前記ワンタイムＵＲＬを前記サービスサーバに提供し、サービス要求を受け付けるサービスサーバが、ユーザの本人認証を行ない、前記ユーザのユーザ情報に関連付けられたワンタイムＵＲＬを用いて、前記ＡＰＩ中継サーバに対して、サービス要求を送信する。

本発明によれば、ＡＰＩを利用したサービス提供において、安全性を高めることができる。

本実施形態のシステム概略図。 本実施形態の処理手順の説明図。 本実施形態の処理手順の説明図。

以下、図１〜図３に従って、サービス管理システム及びサービス管理方法を具体化した一実施形態を説明する。本実施形態では、ＡＰＩ中継サーバを介して、金融機関が提供するサービスを利用する場合を想定する。

図１に示すように、本実施形態では、ユーザ端末１０、管理サーバ２０、銀行サーバ３０、サービスサーバ４０、ＡＰＩ中継サーバ５０を用いる。
ユーザ端末１０は、金融機関（銀行）が提供するサービスを利用する顧客が用いるコンピュータ端末である。このユーザ端末１０は、サービスサーバ４０から取得した情報を利用して、銀行との間で取引を行なう。ユーザ端末１０は、情報を入力するための入力部や情報を出力するための表示部を備える。

管理サーバ２０は、ユーザ端末１０からＡＰＩ中継サーバ５０のアクセスを支援するコンピュータシステムである。この管理サーバ２０は、ＡＰＩ中継サーバ５０にアクセスするためのＵＲＬを生成する。本実施形態では、ワンタイムＵＲＬを用いる。このワンタイムＵＲＬは、限られた時間或いは回数でリクエストを受け付ける。これにより、アクセス制限されたリソースに対しての未承認アクセスをより困難にすることができる。この管理サーバ２０は、制御部２１、ＵＲＬ記憶部２２を備えている。

図１に示す制御部２１は、制御手段（ＣＰＵ、ＲＡＭ、ＲＯＭ等）を備え、後述する処理（ＵＲＬ管理段階、ユーザ認証段階、ＵＲＬ確認段階等の各処理等）を行なう。そのためのサービス管理プログラムを実行することにより、制御部２１は、ＵＲＬ管理部２１１、ユーザ認証部２１２、ＵＲＬ確認部２１３として機能する。

ＵＲＬ管理部２１１は、ワンタイムＵＲＬを管理する処理を実行する。
ユーザ認証部２１２は、ワンタイムＵＲＬを利用するユーザを認証する処理を実行する。
ＵＲＬ確認部２１３は、ワンタイムＵＲＬの有効性を確認する処理を実行する。

ＵＲＬ記憶部２２には、ユーザに付与したワンタイムＵＲＬに関するＵＲＬ管理レコードが記録される。ＵＲＬ管理レコードは、ワンタイムＵＲＬを生成した場合に記録される。このＵＲＬ管理レコードには、ワンタイムＵＲＬ、ステータス、ユーザＩＤ、アクセストークンに関するデータが記録される。

ワンタイムＵＲＬデータ領域には、各ユーザに付与したワンタイムＵＲＬに関するデータが記録される。
ステータスデータ領域には、ワンタイムＵＲＬの有効性を判定するためのフラグが記録される。具体的には、ユーザ認証を完了した場合、ワンタイムＵＲＬを有効にするために、認証完了フラグが記録される。

ユーザＩＤデータ領域には、ワンタイムＵＲＬを付与したユーザを特定するための識別子に関するデータが記録される。
アクセストークンデータ領域には、各ユーザの認証（ここでは、OAuth認証）において用いられる認証情報に関するデータが記録される。

銀行サーバ３０は、利用者の口座を管理する銀行のコンピュータシステムである。この銀行サーバ３０は、顧客情報記憶部３２、口座情報記憶部３３を備えている。
顧客情報記憶部３２には、銀行の顧客である利用者に関する情報を管理するための顧客管理レコードが記録される。この顧客管理レコードは、顧客登録が行なわれた場合に記録される。顧客管理レコードには、ユーザＩＤ、パスワード、口座番号、取引状況に関する情報が記録される。

ユーザＩＤデータ領域には、各顧客を特定するための識別子に関するデータが記録される。
パスワードデータ領域には、この顧客を認証するために用いられるパスワードに関するデータが記録される。

口座番号データ領域には、この顧客が保有している口座に関する情報が記録されている。
取引状況データ領域には、この顧客と銀行との取引状況（例えばローン残高）等の情報が記録される。

口座情報記憶部３３には、銀行の顧客の口座に関する情報を管理するための口座管理レコードが記録される。この口座管理レコードは、口座が開設された場合に登録される。この口座管理レコードには、口座番号、入出金履歴、残高に関する情報が記録される。

口座番号データ領域には、この口座を特定するための識別子に関する情報が記録される。
入出金履歴データ領域には、この口座への入金やこの口座からの出金に関する情報（入出金日時、金額、入出金先口座等）に関するデータが含まれる。
残高データ領域には、この口座の現在の残高に関する情報が記録される。

サービスサーバ４０は、ユーザ端末１０に対して、金融サービスを提供するサービスプロバイダ（いわゆるFintech企業）のコンピュータシステムである。サービスサーバ４０は、ユーザ端末１０からのアクセスに応じて、ＡＰＩ中継サーバ５０を介して、銀行サーバ３０から各種情報を取得し、この情報を加工や編集を行なって、ユーザ端末１０に提供する。このサービスサーバ４０は、ユーザ情報記憶部４２を備える。

ユーザ情報記憶部４２には、ユーザのワンタイムＵＲＬに関するユーザ管理レコードが記録される。ユーザ管理レコードは、ユーザ登録が行なわれた場合に記録される。このユーザ管理レコードには、アクセストークン、ワンタイムＵＲＬに関するデータを含んで構成される。

アクセストークンデータ領域には、各ユーザの認証（ここでは、OAuth認証）において用いられる認証情報に関するデータが記録される。
ワンタイムＵＲＬデータ領域には、各ユーザに付与したワンタイムＵＲＬに関するデータが記録される。

ＡＰＩ中継サーバ５０は、ユーザ端末１０やサービスサーバ４０からのアクセスに応じて、顧客の口座に関する情報を提供するコンピュータシステムである。このＡＰＩ中継サーバ５０は、ファサードＡＰＩ５１、業務ＡＰＩ５２を備えている。ここで、各ＡＰＩは、銀行サーバ３０における情報連携を行なうためのアプリケーションサービスインターフェースである。

ファサードＡＰＩ５１は、複数の業務ＡＰＩ５２のインターフェースとなるＡＰＩである。
業務ＡＰＩ５２は、銀行サーバ３０における各種業務と連携するＡＰＩである。業務には、銀行サーバ３０の口座情報記憶部３３に記録された口座管理情報を用いて、利用者の取引についての決済を行なう振込等がある。

次に、図２〜図３に従って、上記のように構成されたシステムにおいて実行される処理手順について説明する。
（サービス利用前処理）
まず、図２を用いて、サービス利用前処理を説明する。この処理は、ユーザ端末１０を用いて、管理サーバ２０で取引を行なう前に実行される。

ここでは、ユーザ端末１０は、事前認証開始処理を実行する（ステップＳ１−１）。具体的には、ユーザは、ユーザ端末１０を用いて、管理サーバ２０にアクセスする。
この場合、管理サーバ２０の制御部２１は、ワンタイムＵＲＬの仮確保処理を実行する（ステップＳ１−２）。具体的には、制御部２１のＵＲＬ管理部２１１は、ＡＰＩ中継サーバ５０にアクセス可能なワンタイムＵＲＬを生成する。そして、ＵＲＬ管理部２１１は、生成したワンタイムＵＲＬを記録したＵＲＬ管理レコードを生成し、ＵＲＬ記憶部２２に記録する。

次に、管理サーバ２０の制御部２１は、認証要求処理を実行する（ステップＳ１−３）。具体的には、制御部２１のユーザ認証部２１２は、ユーザ端末１０に対して、セッション情報を含めた認証要求を送信する。

この場合、ユーザ端末１０は、認証画面の表示処理を実行する（ステップＳ１−４）。具体的には、ユーザ端末１０は、表示部に認証画面を出力する。この認証画面には、ユーザＩＤ、パスワードを入力するためのユーザ設定欄が設けられている。

次に、ユーザ端末１０は、認証情報の入力処理を実行する（ステップＳ１−５）。具体的には、ユーザは、認証画面に、銀行サーバ３０を利用するためのユーザＩＤ、パスワードを入力する。そして、ユーザ端末１０は、セッション情報を含めた認証情報を管理サーバ２０に送信する。認証情報には、認証画面に入力されたユーザＩＤ、パスワードに関するデータを含める。

次に、管理サーバ２０の制御部２１は、認証依頼処理を実行する（ステップＳ１−６）。具体的には、制御部２１のユーザ認証部２１２は、ユーザ端末１０から認証情報を受信し、銀行サーバ３０に対して、セッション情報を含めた認証依頼を送信する。この認証依頼には、ユーザ端末１０から取得したユーザＩＤ、パスワードに関するデータを含める。

次に、銀行サーバ３０は、認証処理を実行する（ステップＳ１−７）。具体的には、銀行サーバ３０は、認証依頼に含まれるユーザＩＤ、パスワードが、顧客情報記憶部３２に登録されているかどうかを確認する。ユーザＩＤ、パスワードが記録された顧客管理レコードを抽出した場合には、認証を完了する。そして、銀行サーバ３０は、セッション情報を含めた認証結果を管理サーバ２０に返信する。この認証結果には、認証を完了した場合には完了フラグを設定し、認証を完了できなかった場合にはエラーフラグを設定する。

次に、管理サーバ２０の制御部２１は、認証完了かどうかについての判定処理を実行する（ステップＳ１−８）。具体的には、制御部２１のユーザ認証部２１２は、銀行サーバ３０から取得した認証結果に基づいて、認証完了か否かを判定する。ここでは、完了フラグが設定された認証結果を取得した場合に、認証完了と判定する。

エラーフラグが設定された認証結果を取得し、認証完了でないと判定した場合（ステップＳ１−８において「ＮＯ」の場合）、管理サーバ２０の制御部２１は、ワンタイムＵＲＬの解放処理を実行する（ステップＳ１−９）。具体的には、制御部２１のユーザ認証部２１２は、セッション情報に基づいて、このユーザ端末１０に割り当てたワンタイムＵＲＬを特定し、ＵＲＬ記憶部２２に記録されているＵＲＬ管理レコードを削除する。

一方、完了フラグが設定された認証結果を取得し、認証完了と判定した場合（ステップＳ１−８において「ＹＥＳ」の場合）管理サーバ２０の制御部２１は、ワンタイムＵＲＬのユーザとの関連付け処理を実行する（ステップＳ１−１０）。具体的には、制御部２１のユーザ認証部２１２は、ＵＲＬ記憶部２２に記録されたＵＲＬ管理レコードにおいて、ワンタイムＵＲＬに関連付けて、ステータスとして認証完了フラグを記録するとともに、認証を完了したユーザＩＤを記録する。

次に、管理サーバ２０の制御部２１は、トークン及びワンタイムＵＲＬの提供処理を実行する（ステップＳ１−１１）。具体的には、制御部２１のユーザ認証部２１２は、ユーザＩＤを暗号化した固有コードを含めたアクセストークンを生成する。このアクセストークンにより、OAuth認証において利用者を特定することができる。ユーザ認証部２１２は、ＵＲＬ管理レコードにおいて、ワンタイムＵＲＬに関連付けて、アクセストークンを記録する。そして、ユーザ認証部２１２は、リダイレクト要求をユーザ端末１０に送信する。このリダイレクト要求には、アクセストークン及びワンタイムＵＲＬ、リダイレクト先アドレスに関するデータを含める。

次に、ユーザ端末１０は、リダイレクト処理を実行する（ステップＳ１−１２）。具体的には、リダイレクト要求を受信したユーザ端末１０は、サービスサーバ４０にアクセスする。この場合、ユーザ端末１０は、管理サーバ２０から取得したアクセストークン及びワンタイムＵＲＬをサービスサーバ４０に転送する。

次に、サービスサーバ４０は、ワンタイムＵＲＬの保存処理を実行する（ステップＳ１−１３）。具体的には、サービスサーバ４０は、リダイレクトにより取得したワンタイムＵＲＬを、アクセストークンに関連付けてユーザ情報記憶部４２に登録する。そして、サービスサーバ４０は、ユーザ端末１０に対して、事前認証完了メッセージを送信する。

次に、ユーザ端末１０は、完了表示処理を実行する（ステップＳ１−１４）。具体的には、ユーザ端末１０は、表示部に、事前認証を完了したことを示すメッセージを出力する。

（サービス利用時の処理）
次に、図３を用いて、サービス利用時の処理を説明する。
まず、ユーザ端末１０は、ログイン要求処理を実行する（ステップＳ２−１）。具体的には、ユーザは、サービスサーバ４０を利用する場合、アクセス画面を出力する。このアクセス画面には、ユーザの生体情報の読取指示を含める。この場合、ユーザは、ユーザ端末１０の認証デバイスを用いて、生体情報の読取操作を行なう。そして、ユーザ端末１０は、ログイン要求を、サービスサーバ４０に送信する。このログイン要求には、生体認証に基づいて特定されたアクセストークンを含める。

次に、サービスサーバ４０は、アクセストークンの取得処理を実行する（ステップＳ２−２）。具体的には、サービスサーバ４０は、ユーザ端末１０から、アクセストークンを含めたログイン要求を取得する。

次に、サービスサーバ４０は、ログイン処理を実行する（ステップＳ２−３）。具体的には、サービスサーバ４０は、ユーザ端末１０から取得したアクセストークンが、ユーザ情報記憶部４２に記録されているかどうかを確認する。アクセストークンが、ユーザ情報記憶部４２に記録されている場合には、ログインを許可し、サービスメニュー画面をユーザ端末１０に返信する。なお、アクセストークンが、ユーザ情報記憶部４２に記録されていない場合には、ログインを拒否して、エラーメッセージをユーザ端末１０に返信する。

次に、ユーザ端末１０は、サービス要求処理を実行する（ステップＳ２−４）。具体的には、ログインが許可された場合、ユーザは、サービスメニュー画面において、所望のサービスを選択する。例えば、サービスとしては、振込処理依頼等がある。この場合、ユーザ端末１０は、サービスメニュー画面において選択されたサービスについてのサービス要求をサービスサーバ４０に送信する。

次に、サービスサーバ４０は、ワンタイムＵＲＬの特定処理を実行する（ステップＳ２−５）。具体的には、サービスサーバ４０は、ユーザ情報記憶部４２から、アクセストークンに関連付けられたワンタイムＵＲＬを取得する。

次に、サービスサーバ４０は、ワンタイムＵＲＬにアクセス処理を実行する（ステップＳ２−６）。具体的には、サービスサーバ４０は、ワンタイムＵＲＬに対して、サービス要求を送信する。

次に、ＡＰＩ中継サーバ５０は、ＵＲＬ照会処理を実行する（ステップＳ２−７）。具体的には、ＡＰＩ中継サーバ５０のファサードＡＰＩ５１は、管理サーバ２０に対して、ＵＲＬ照会要求を送信する。このＵＲＬ照会要求には、サービスサーバ４０から取得したワンタイムＵＲＬを含める。

ＵＲＬ照会要求を取得した管理サーバ２０の制御部２１は、ワンタイムＵＲＬの確認処理を実行する（ステップＳ２−８）。具体的には、制御部２１のＵＲＬ確認部２１３は、ＵＲＬ照会要求のワンタイムＵＲＬのステータスを確認する。ここで、ＵＲＬ記憶部２２において、ワンタイムＵＲＬに対して、認証完了フラグ、ユーザＩＤが関連付けられている場合には、ワンタイムＵＲＬは有効と判定する。一方、ワンタイムＵＲＬに対して、ユーザＩＤが関連付けられていない場合には、ワンタイムＵＲＬは無効と判定する。そして、ＵＲＬ確認部２１３は、ＡＰＩ中継サーバ５０に確認結果を返信する。この確認結果には、ワンタイムＵＲＬの有効フラグ又は無効フラグを含める。

次に、ＡＰＩ中継サーバ５０は、ワンタイムＵＲＬの妥当性の検証処理を実行する（ステップＳ２−９）。具体的には、ＡＰＩ中継サーバ５０のファサードＡＰＩ５１は、管理サーバ２０から取得した確認結果に基づいて、ワンタイムＵＲＬの妥当性を検証する。ここでは、有効フラグを含む確認結果を取得した場合には、ワンタイムＵＲＬは妥当と判定する。

一方、無効フラグを含む確認結果を取得した場合には、ファサードＡＰＩ５１は、ワンタイムＵＲＬは妥当でないと判定し、サービスサーバ４０に対して、エラーメッセージを返信する。この場合、サービスサーバ４０はユーザ端末１０に対して、サービスを利用できないことを示すメッセージを返信する。

ワンタイムＵＲＬは妥当と判定したＡＰＩ中継サーバ５０は、業務ＡＰＩコール処理を実行する（ステップＳ２−１０）。具体的には、ＡＰＩ中継サーバ５０のファサードＡＰＩ５１は、サービスサーバ４０からのサービス要求に応じた業務ＡＰＩ５２を呼び出す。

次に、ＡＰＩ中継サーバ５０は、サービス依頼処理を実行する（ステップＳ２−１１）。具体的には、ＡＰＩ中継サーバ５０の業務ＡＰＩ５２は、銀行サーバ３０に対してサービス要求を送信する。

次に、銀行サーバ３０は、サービス処理を実行する（ステップＳ２−１２）。具体的には、銀行サーバ３０は、サービス要求に基づいて、サービス処理（例えば、口座情報記憶部３３を用いた振込処理）を実行する。そして、銀行サーバ３０は、処理結果をＡＰＩ中継サーバ５０に返信する。

次に、ＡＰＩ中継サーバ５０は、結果取得処理を実行する（ステップＳ２−１３）。具体的には、ＡＰＩ中継サーバ５０のファサードＡＰＩ５１は、銀行サーバ３０から、サービス処理結果を取得する。

次に、ＡＰＩ中継サーバ５０は、業務ＡＰＩコール処理を実行する（ステップＳ２−１４）。具体的には、ＡＰＩ中継サーバ５０のファサードＡＰＩ５１は、業務ＡＰＩ５２を呼び出し、サービス処理結果をサービスサーバ４０に返信する。

次に、サービスサーバ４０は、処理結果の送信処理を実行する（ステップＳ２−１５）。具体的には、サービスサーバ４０は、サービス処理結果に基づいて、サービス要求を更新する。そして、サービスサーバ４０は、ユーザ端末１０に対して、処理結果を送信する。

次に、ユーザ端末１０は、完了表示処理を実行する（ステップＳ２−１６）。具体的には、ユーザ端末１０は、サービスサーバ４０から取得した処理結果を、表示部に出力する。

本実施形態によれば、以下のような効果を得ることができる。
（１）本実施形態では、管理サーバ２０の制御部２１は、ワンタイムＵＲＬの仮確保処理を実行する（ステップＳ１−２）。認証完了と判定した場合（ステップＳ１−８において「ＹＥＳ」の場合）管理サーバ２０の制御部２１は、ワンタイムＵＲＬのユーザとの関連付け処理を実行する（ステップＳ１−１０）。これにより、ユーザ認証に基づいて、ワンタイムＵＲＬを付与することができる。

（２）本実施形態では、管理サーバ２０の制御部２１は、トークン及びワンタイムＵＲＬの提供処理を実行する（ステップＳ１−１１）。ユーザ端末１０は、リダイレクト処理を実行する（ステップＳ１−１２）。サービスサーバ４０は、ワンタイムＵＲＬの保存処理を実行する（ステップＳ１−１３）。これにより、サービスサーバ４０は、ＡＰＩ中継サーバ５０にアクセスするためのワンタイムＵＲＬを取得することができる。

（３）本実施形態では、サービスサーバ４０は、ワンタイムＵＲＬの特定処理（ステップＳ２−５）、ワンタイムＵＲＬにアクセス処理（ステップＳ２−６）を実行する。この場合、ＡＰＩ中継サーバ５０は、ＵＲＬ照会処理を実行する（ステップＳ２−７）。ワンタイムＵＲＬを用いることにより、外部から、業務ＡＰＩ５２への攻撃を抑制することができる。

また、上記実施形態は以下のように変更してもよい。
・上記実施形態では、ＵＲＬ記憶部２２には、ユーザに付与したワンタイムＵＲＬに関するＵＲＬ管理レコードが記録される。このＵＲＬ管理レコードには、ワンタイムＵＲＬ、ステータス、ユーザＩＤ、アクセストークンに関するデータが記録される。ここで、ワンタイムＵＲＬに利用条件を設定してもよい。利用条件としては、例えば、利用上限金額を用いることができる。この場合、ＵＲＬ管理レコードに、利用条件として利用上限金額、ステータスとして利用金額の累積額を記録する。そして、ＡＰＩ中継サーバ５０は、ワンタイムＵＲＬの妥当性の検証処理（ステップＳ２−９）において、サービス要求に係る利用金額を管理サーバ２０に送信する。この場合、管理サーバ２０の制御部２１は、ワンタイムＵＲＬの確認処理（ステップＳ２−８）において、ＵＲＬ確認部２１３は、利用金額を加算した利用金額の累積額を算出する。そして、ＵＲＬ確認部２１３は、ＵＲＬ記憶部２２に記録された利用金額の累積額が利用上限金額に達していないかどうかを確認する。ここで、利用金額の累積額が利用上限金額に達していない場合に、ＵＲＬ確認部２１３は、ＵＲＬ記憶部２２のＵＲＬ管理レコードにおいて利用金額の累積額を更新し、ワンタイムＵＲＬの有効フラグを含めた確認結果を返信する。一方、利用金額の累積額が利用上限金額を超える場合、ＵＲＬ確認部２１３は、ワンタイムＵＲＬの無効フラグを含めた確認結果を返信する。

また、利用条件として、有効期間を用いてもよい。この場合には、ＵＲＬ確認部２１３は、現在日時を特定し、この現在日時が有効期間に含まれる場合に、ＵＲＬ確認部２１３は、ワンタイムＵＲＬの有効フラグを含めた確認結果を返信する。一方、現在日時が有効期間に含まれない場合、ＵＲＬ確認部２１３は、ワンタイムＵＲＬの無効フラグを含めた確認結果を返信する。そして、ＵＲＬ管理部２１１は、有効期間を渡過したＵＲＬ管理レコードを削除する。

また、利用条件として、利用上限回数を用いてもよい。この場合、ＵＲＬ管理レコードに、利用条件として利用上限回数、ステータスとして利用回数を記録する。そして、管理サーバ２０の制御部２１は、ワンタイムＵＲＬの確認処理（ステップＳ２−８）において、ＵＲＬ確認部２１３は、利用回数に「１」を加算した現在回数を算出する。そして、ＵＲＬ確認部２１３は、現在回数が利用上限回数以下の場合に、ＵＲＬ確認部２１３は、ＵＲＬ記憶部２２のＵＲＬ管理レコードにおいて利用回数を更新し、ワンタイムＵＲＬの有効フラグを含めた確認結果を返信する。一方、利用回数が利用上限回数に達した場合、ＵＲＬ確認部２１３は、ワンタイムＵＲＬの無効フラグを含めた確認結果を返信する。そして、ＵＲＬ管理部２１１は、利用回数が利用上限回数に達したＵＲＬ管理レコードを削除する。

また、利用条件として、利用可能時間帯を用いてもよい。この場合には、現在時刻が利用可能時間帯に含まれる場合に、ＵＲＬ確認部２１３は、ワンタイムＵＲＬの有効フラグを含めた確認結果を返信する。一方、現在時刻が利用可能時間帯に含まれない場合、ＵＲＬ確認部２１３は、ワンタイムＵＲＬの無効フラグを含めた確認結果を返信する。
また、利用条件として、取引種別を用いてもよい。この場合、管理サーバ２０の制御部２１は、サービスサーバ４０に対して、取引種別毎に異なるワンタイムＵＲＬを提供する。

・上記実施形態では、ユーザ端末１０は、事前認証開始処理を実行する（ステップＳ１−１）。ユーザ端末１０が、この処理を、定期的に実行するようにしてもよい。この場合には、ワンタイムＵＲＬの有効期間を決めておき、有効期間の経過を検知したユーザ端末１０が事前認証開始処理を実行する。
・上記実施形態では、管理サーバ２０の制御部２１は、ワンタイムＵＲＬの仮確保処理を実行する（ステップＳ１−２）。ここでは、ユーザ毎にワンタイムＵＲＬをＵＲＬ記憶部２２に記録する。このワンタイムＵＲＬは、ユーザ毎に付与する場合に限定されるものではない。例えば、所定の有効期間は同じワンタイムＵＲＬを付与してもよい。

・上記実施形態では、管理サーバ２０の制御部２１は、トークン及びワンタイムＵＲＬの提供処理を実行する（ステップＳ１−１１）。これに代えて、ワンタイムＵＲＬの特定処理（ステップＳ２−５）において、サービスサーバ４０が管理サーバ２０にアクセスし、アクセストークンに関連付けられた有効なワンタイムＵＲＬを取得するようにしてもよい。ここで、ＵＲＬ記憶部２２に、アクセストークンに関連付けられた有効なワンタイムＵＲＬが記録されていない場合には、サービスサーバ４０はサービス提供を拒否する。この場合には、サービスサーバ４０のユーザ情報記憶部４２にワンタイムＵＲＬを保持させることなく、ワンタイムＵＲＬによりＡＰＩ中継サーバ５０にアクセスできる。

・上記実施形態では、金融機関が提供するＡＰＩサービスにおいて、ワンタイムＵＲＬを用いる。ワンタイムＵＲＬの適用対象は、銀行ＡＰＩに限定されるものではない。

１０…ユーザ端末、２０…管理サーバ、２１…制御部、２２…ＵＲＬ記憶部、２１１…ＵＲＬ管理部、２１２…ユーザ認証部、２１３…ＵＲＬ確認部、３０…銀行サーバ、３２…顧客情報記憶部、３３…口座情報記憶部、４０…サービスサーバ、４２…ユーザ情報記憶部、５０…ＡＰＩ中継サーバ、５１…ファサードＡＰＩ、５２…業務ＡＰＩ。

Claims (4)

1. ユーザの本人認証を行なうための認証情報及びユーザ識別情報を保持するＡＰＩサービス提供サーバと、ユーザに付与したワンタイムＵＲＬを管理する管理サーバと、サービスを提供するＡＰＩを有するＡＰＩ中継サーバと、前記サービスを利用するサービスサーバを含むサービス管理システムであって、
   前記管理サーバが、ユーザ端末からユーザの本人認証を行なうための認証情報及びユーザ識別情報を取得し、前記認証情報及びユーザ識別情報を含めた認証依頼を前記ＡＰＩサービス提供サーバに送信し、
   前記管理サーバが、前記ＡＰＩサービス提供サーバにおいて前記認証情報を用いたユーザの本人認証に基づいて認証完了結果を取得した場合、前記ＡＰＩ中継サーバにアクセスするためのワンタイムＵＲＬを発行し、前記ユーザ識別情報に関連付けて前記ワンタイムＵＲＬ、サービス利用上限をＵＲＬ記憶部に記録し、
   前記ユーザ識別情報に対応したアクセストークンとともに前記ワンタイムＵＲＬを前記サービスサーバに提供し、
   サービス要求を受け付けたサービスサーバが、前記アクセストークンを用いて、ユーザの本人認証を行ない、前記アクセストークンに関連付けられたワンタイムＵＲＬを用いて、前記ＡＰＩ中継サーバに対して、前記ＡＰＩサービス提供サーバにおけるサービス内容を含めたサービス要求を送信し、
   前記サービス要求を受信した前記ＡＰＩ中継サーバが、前記サービス内容を含めた前記ワンタイムＵＲＬの妥当性の確認要求を前記管理サーバに送信し、
   前記管理サーバは、前記確認要求のサービス内容が、前記ワンタイムＵＲＬに関連付けられたサービス利用上限を超えたと判定した場合、前記サービス要求を拒否する確認結果を、前記ＡＰＩ中継サーバを介して前記サービスサーバに返信することを特徴とするサービス管理システム。
2. 前記管理サーバにおいて、前記ワンタイムＵＲＬに関連付けて、有効期間を記録し、
   サービス要求を受け付けたサービスサーバが、ワンタイムＵＲＬの確認要求を前記管理サーバに送信し、
   前記管理サーバは、前記ワンタイムＵＲＬの有効期間を経過した場合には、前記ワンタイムＵＲＬの利用を拒否する確認結果を前記サービスサーバに返信することを特徴とする
   請求項１に記載のサービス管理システム。
3. 前記ＡＰＩ中継サーバは、前記管理サーバから前記ワンタイムＵＲＬの妥当性の確認結果を取得できた場合に、前記ＡＰＩサービス提供サーバにアクセスするＡＰＩコールを行なうことを特徴とする請求項１又は２に記載のサービス管理システム。
4. ユーザの本人認証を行なうための認証情報及びユーザ識別情報を保持するＡＰＩサービス提供サーバと、ユーザに付与したワンタイムＵＲＬを管理する管理サーバと、サービスを提供するＡＰＩを有するＡＰＩ中継サーバと、前記サービスを利用するサービスサーバを含むサービス管理システムを用いて、サービス提供を管理する方法であって、
   前記管理サーバが、ユーザ端末からユーザの本人認証を行なうための認証情報及びユーザ識別情報を取得し、前記認証情報及びユーザ識別情報を含めた認証依頼を前記ＡＰＩサービス提供サーバに送信し、
   前記管理サーバが、前記ＡＰＩサービス提供サーバにおいて前記認証情報を用いたユーザの本人認証に基づいて認証完了結果を取得した場合、前記ＡＰＩ中継サーバにアクセスするためのワンタイムＵＲＬを発行し、前記ユーザ識別情報に関連付けて前記ワンタイムＵＲＬ、サービス利用上限をＵＲＬ記憶部に記録し、
   前記ユーザ識別情報に対応したアクセストークンとともに前記ワンタイムＵＲＬを前記サービスサーバに提供し、
   サービス要求を受け付けたサービスサーバが、前記アクセストークンを用いて、ユーザの本人認証を行ない、前記アクセストークンに関連付けられたワンタイムＵＲＬを用いて、前記ＡＰＩ中継サーバに対して、前記ＡＰＩサービス提供サーバにおけるサービス内容を含めたサービス要求を送信し、
   前記サービス要求を受信した前記ＡＰＩ中継サーバが、前記サービス内容を含めた前記ワンタイムＵＲＬの妥当性の確認要求を前記管理サーバに送信し、
   前記管理サーバは、前記確認要求のサービス内容が、前記ワンタイムＵＲＬに関連付けられたサービス利用上限を超えたと判定した場合、前記サービス要求を拒否する確認結果を、前記ＡＰＩ中継サーバを介して前記サービスサーバに返信することを特徴とするサービス管理方法。

Images