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

Description

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

サービス提供サイトから、ＡＰＩ（Application Programming Interface）を介して各種情報が提供されつつある。例えば、銀行が保有している顧客に関する金融情報の利用促進を図るために、他のシステムとの連携が検討されている（例えば、非特許文献１）。このような銀行システムから情報を取得するための銀行ＡＰＩの公開も検討されている（例えば、非特許文献２）。この銀行ＡＰＩは、残高照会や資金移動等、既存機能を個別にサービス化して、外部のアプリケーションから利用するために使用する。

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

また、権限の認可を行うためにOAuthによる認証を用いることもある。このOAuthは、ユーザの代理で、サーバにあるユーザのリソースへのアクセスを許可するための認証用のプロトコルである。OAuthを使用することで、エンドユーザはクライアントにユーザ名やパスワードを知らせることなく、リソースへの第三者アクセスを認可することができる。OAuthでは、ログインのために必要なユーザＩＤ及びパスワードを、ユーザ毎に割り当てるOAuth用トークン（アクセストークン）に置き換える。このOAuth用トークンにより、外部のサービスにはパスワードを知らせることなく、システム間の情報の共有が可能になる。

更に、ユーザの生体情報を用いたユーザ認証において、ＦＩＤＯ（登録商標）も検討されている。このＦＩＤＯでは、ユーザ端末に、予め登録された生体情報を用いて照合を行ない、照合を完了した場合、暗号化した認証情報であるＦＩＤＯ用トークンを認証サーバに送信する。

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

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

上述したＡＰＩを利用すれば、決められた処理を呼び出すだけでサービスを利用できるため、システム開発の手間が省ける。しかしながら、サービス提供サイトで提供されているすべてのサービスについて、ＡＰＩが準備されている訳ではない。ＡＰＩ未対応の場合には、従来のユーザＩＤ及びパスワード等を用いたユーザ認証によりログインし、スクレイピングにより、サービスを利用する必要がある。特に、ＡＰＩ対応済サービスの利用後にＡＰＩ未対応サービスを利用する場合、ログインが必要であり、手間がかかる。

また、OAuthを利用する場合、セキュリティが高い生体認証との組み合わせでの利用は想定されていなかった。

上記課題を解決するために、サービス管理システムは、クライアント端末と通信を行なう中継サーバに接続され、サービス提供を管理する。そして、前記サービス管理システムは、前記クライアント端末の利用者のユーザ認証の完了後に、前記中継サーバからアクセストークンを受信し、前記アクセストークンに基づいて、前記利用者のログイン状態を生成し、前記ログイン状態に基づいて、前記利用者が複数のサービスを利用可能なログイン画面のアドレス情報を、前記中継サーバに返信する。

本発明によれば、ユーザ情報を管理するサーバでユーザ認証を行なった認証結果を用いて、他のサーバが提供するサービスを利用することができる。

本実施形態のシステム概略図。 本実施形態のハードウェア構成の説明図。 本実施形態の処理手順の説明図。 本実施形態の処理手順の説明図。

以下、図１〜図４を用いて、サービス管理システムの一実施形態を説明する。
図１に示すように、本実施形態では、ユーザ端末１０、中継サーバ２０、ＡＰＩゲートウェイ３０、認証サーバ４０、銀行サーバ５０を用いる。ここで、ＡＰＩゲートウェイ３０、銀行サーバ５０が、サービス管理システムとして機能する。

ユーザ端末１０は、銀行サーバ５０を利用する顧客（ユーザ）が用いるコンピュータ端末（クライアント端末）である。ユーザ端末１０は、ユーザ認証を行なうための生体情報取得部１１、認証モジュール１２を備える。生体情報取得部１１は、利用者の生体情報（例えば、指紋等）を読み取り、その特徴量（生体識別情報）を算出するデバイスである。認証モジュール１２は、ユーザ認証のためのデータを生成する。このユーザ認証には、ＦＩＤＯ（登録商標）を用いる。このため、ユーザ端末１０に、生体情報取得部１１で読み取った本人の生体識別情報を登録しておく。そして、認証時には、認証モジュール１２が、登録されている生体識別情報を用いて照合を行なう。照合を完了した場合、認証モジュール１２は、ユーザ秘密鍵を使って、暗号化した認証用シリアルデータ（生体認証データとしてのＦＩＤＯ用トークン）を生成し、認証サーバ４０に送信する。

中継サーバ２０は、金融機関が提供する金融サービス（第１のサービス）を利用して新たなサービス（第２のサービス）を提供するサービスプロバイダのサーバコンピュータである。サービスプロバイダとしては、例えば、インターネットを介して金融サービスを提供する企業（所謂フィンテック企業）等がある。この中継サーバ２０は、銀行サーバ５０の金融サービスを利用するためのアクセストークン記憶部２２を備える。このアクセストークン記憶部２２には、ユーザＩＤに関連付けられ、ユーザが利用する銀行サーバ５０の金融サービスについてのアクセストークンが記録される。

ＡＰＩゲートウェイ３０は、ＡＰＩ（Application Programming Interface）を管理するゲートウェイサーバ（認可サーバ）である。このＡＰＩゲートウェイ３０は、金融サービスＡＰＩ３１及びオートログインＡＰＩ３２を備える。金融サービスＡＰＩ３１は、銀行の顧客に対して各種サービス（例えば、残高照会）を提供する。オートログインＡＰＩ３２は、金融サービスＡＰＩ３１が用意されていないサービス（ＡＰＩ未対応サービス）について、銀行サーバ５０との間でログイン状態のセッションを生成する。このセッションを用いて、ＡＰＩ未対応サービスにおける情報を提供する。

認証サーバ４０は、ユーザ認証（ここでは、ＦＩＤＯ（登録商標））を実行するサーバコンピュータである。認証サーバ４０では、ユーザ端末１０から受信した認証用シリアルデータを、ユーザ公開鍵を使って検証し、検証の結果が正しければユーザ認証を完了する。このため、認証サーバ４０は、ユーザＩＤに関連付けて、認証用シリアルデータを記録する認証情報記憶部４２を備える。

銀行サーバ５０は、顧客に対して金融サービスを提供する銀行のサーバコンピュータ（サービス提供サーバ）である。この銀行サーバ５０は、顧客に対して金融サービスを提供するための内部ＡＰＩを備える。銀行サーバ５０は、銀行の顧客に関する情報を記憶した顧客情報記憶部５２を備える。この顧客情報記憶部５２には、各顧客を特定するためのユーザＩＤ、この顧客を認証するためのパスワードが記録されている。

図２を用いて、ユーザ端末１０〜銀行サーバ５０を構成する情報処理装置Ｈ１０のハードウェア構成を説明する。情報処理装置Ｈ１０は、通信インタフェースＨ１１、入力装置Ｈ１２、表示装置Ｈ１３、記憶部Ｈ１４、プロセッサＨ１５を備える。なお、このハードウェア構成は一例であり、他のハードウェアにより実現することも可能である。

通信インタフェースＨ１１は、他の装置との間で通信経路を確立して、データの送受信を実行するインタフェースであり、例えばネットワークインタフェースカードや無線インタフェース等である。

入力装置Ｈ１２は、利用者等からの入力を受け付ける装置であり、例えばマウスやキーボード等である。表示装置Ｈ１３は、各種情報を表示するディスプレイ等である。

記憶部Ｈ１４は、ユーザ端末１０〜銀行サーバ５０の各種機能を実行するためのデータや各種プログラムを格納する記憶装置である。記憶部Ｈ１４の一例としては、ＲＯＭ、ＲＡＭ、ハードディスク等がある。

プロセッサＨ１５は、記憶部Ｈ１４に記憶されるプログラムやデータを用いて、ユーザ端末１０〜銀行サーバ５０における各処理を制御する。プロセッサＨ１５の一例としては、例えばＣＰＵやＭＰＵ等がある。このプロセッサＨ１５は、ＲＯＭ等に記憶されるプログラムをＲＡＭに展開して、各サービスのための各種プロセスを実行する。

（認証情報の登録処理）
まず、図３を用いて、認証情報の登録処理を説明する。ここでは、サービスプロバイダのサービスを利用するために生体識別情報を登録する。

ユーザ端末１０は、ＩＤ／ＰＷ入力処理を実行する（ステップＳ１−１）。具体的には、サービスプロバイダのサービス利用を希望する顧客（ユーザ）は、ユーザ端末１０を用いて、中継サーバ２０にアクセスする。この場合、中継サーバ２０は、ユーザ端末１０のディスプレイに利用登録画面を出力する。この利用登録画面には、利用希望のサービスコードの選択欄、ユーザＩＤ、パスワードの入力欄が設けられている。この場合、利用登録画面において、利用希望のサービスコードを選択し、ユーザＩＤ、パスワードを入力する。そして、利用登録画面の送信ボタンが選択された場合、ユーザ端末１０は、利用登録画面に設定されたサービスコード、ユーザＩＤ、パスワードを中継サーバ２０に送信する。

次に、中継サーバ２０は、中継処理を実行する（ステップＳ１−２）。具体的には、中継サーバ２０は、サービスコードに対応して利用するＡＰＩのＡＰＩコードを特定する。そして、中継サーバ２０は、アクセストークン発行要求を、ＡＰＩゲートウェイ３０に送信する。このアクセストークン発行要求には、ＡＰＩコード、ユーザ端末１０から取得したユーザＩＤ、パスワードに関するデータを含める。

次に、ＡＰＩゲートウェイ３０は、中継処理を実行する（ステップＳ１−３）。具体的には、ＡＰＩゲートウェイ３０は、中継サーバ２０から取得したアクセストークン発行要求を、銀行サーバ５０に転送する。

次に、銀行サーバ５０は、ＩＤ／ＰＷ認証処理を実行する（ステップＳ１−４）。具体的には、銀行サーバ５０は、ＡＰＩゲートウェイ３０から取得したアクセストークン発行要求のユーザＩＤ、パスワードが顧客情報記憶部５２に記録されているかどうかを確認する。ユーザＩＤ、パスワードが顧客情報記憶部５２に記録されていない場合には、サービス提供を拒否する。また、ユーザＩＤ、パスワードが顧客情報記憶部５２に記録されている場合には、本人認証を完了する。

本人認証を完了した銀行サーバ５０は、アクセストークンの発行指示処理を実行する（ステップＳ１−５）。具体的には、銀行サーバ５０は、ＡＰＩゲートウェイ３０に対して、アクセストークンの発行指示を送信する。この発行指示には、ＡＰＩコード、ユーザＩＤに関するデータを含める。

次に、ＡＰＩゲートウェイ３０は、アクセストークンの発行処理を実行する（ステップＳ１−６）。具体的には、ＡＰＩゲートウェイ３０は、発行指示を受けたユーザＩＤ、ＡＰＩコード（利用可能ＡＰＩコード）についてのアクセストークンを発行する。そして、ＡＰＩゲートウェイ３０は、ユーザＩＤ、アクセストークンを中継サーバ２０に送信する。

次に、中継サーバ２０は、アクセストークンの保持処理を実行する（ステップＳ１−７）。具体的には、中継サーバ２０は、ＡＰＩゲートウェイ３０から受信したユーザＩＤ、アクセストークンをアクセストークン記憶部２２に記録する。そして、中継サーバ２０は、ユーザ端末１０にアクセストークン発行通知を送信する。

アクセストークン発行通知を受信したユーザ端末１０は、生体情報の取得処理を実行する（ステップＳ１−８）。具体的には、ユーザ端末１０は、生体情報取得部１１を用いて、生体情報の読み取りを指示するメッセージを、ディスプレイに出力する。ユーザは、生体情報取得部１１において、本人の生体情報の読み取り操作を行なう。

次に、ユーザ端末１０は、シリアルデータの生成処理を実行する（ステップＳ１−９）。具体的には、ユーザ端末１０の認証モジュール１２は、生体情報取得部１１において読み取った生体情報を用いて、認証用シリアルデータを生成する。なお、認証用シリアルデータを生成するための情報は、生体情報に限定されるものではない。例えば、ユーザ端末１０をユニークに特定できる端末固有情報を用いて、認証用シリアルデータを生成してもよい。

次に、ユーザ端末１０は、シリアルデータ、ＩＤの送信処理を実行する（ステップＳ１−１０）。具体的には、ユーザ端末１０は、認証用シリアルデータ、ユーザＩＤを中継サーバ２０に送信する。

次に、中継サーバ２０は、アクセストークンの登録確認処理を実行する（ステップＳ１−１１）。具体的には、中継サーバ２０は、ユーザ端末１０から取得したユーザＩＤが、アクセストークン記憶部２２に記録されていることを確認する。ユーザ端末１０から取得したユーザＩＤが、アクセストークン記憶部２２に記録されていない場合には、中継サーバ２０は、サービス提供を拒否する。

一方、ユーザ端末１０から取得したユーザＩＤが、アクセストークン記憶部２２に記録されている場合、中継サーバ２０は、シリアルデータ、ＩＤの転送処理を実行する（ステップＳ１−１２）。具体的には、中継サーバ２０は、生体情報登録要求をＡＰＩゲートウェイ３０に送信する。この生体情報登録要求には、認証用シリアルデータ、ユーザＩＤに関するデータを含める。

次に、ＡＰＩゲートウェイ３０は、シリアルデータ、ＩＤの転送処理を実行する（ステップＳ１−１３）。具体的には、ＡＰＩゲートウェイ３０は、中継サーバ２０から取得した生体情報登録要求を認証サーバ４０に転送する。

次に、認証サーバ４０は、シリアルデータ、ＩＤの登録処理を実行する（ステップＳ１−１４）。具体的には、認証サーバ４０は、生体情報登録要求に含まれる認証用シリアルデータを、ユーザＩＤに関連付けて認証情報記憶部４２に記録する。

（サービスの利用処理）
次に、図４を用いて、サービスの利用処理を説明する。
ここでは、ユーザ端末１０は、生体情報の読取処理を実行する（ステップＳ２−１）。具体的には、ユーザがサービスプロバイダのサービスを利用する場合、ユーザ端末１０を用いて、中継サーバ２０にアクセスする。この場合、中継サーバ２０は、ユーザ端末１０のディスプレイに認証画面を出力する。この認証画面には、ユーザＩＤの入力、生体情報の読み取りを指示するメッセージが含まれる。ユーザは、ユーザＩＤを入力し、生体情報取得部１１において、生体情報の読み取り操作を行なう。

次に、ユーザ端末１０は、シリアルデータ、ＩＤの送信処理を実行する（ステップＳ２−２）。具体的には、ユーザ端末１０は、読み取った生体情報の生体識別情報を用いて、認証用シリアルデータを生成する。そして、ユーザ端末１０は、サービス利用要求を中継サーバ２０に送信する。このサービス利用要求には、認証用シリアルデータ、ユーザＩＤに関するデータを含める。

次に、中継サーバ２０は、アクセストークンの確認処理を実行する（ステップＳ２−３）。具体的には、中継サーバ２０は、ユーザ端末１０から取得したユーザＩＤが、アクセストークン記憶部２２に記録されていることを確認する。ユーザ端末１０から取得したユーザＩＤが、アクセストークン記憶部２２に記録されていない場合には、中継サーバ２０は、サービス提供を拒否する。

ユーザ端末１０から取得したユーザＩＤが、アクセストークン記憶部２２に記録されている場合、中継サーバ２０は、シリアルデータ、ＩＤの転送処理を実行する（ステップＳ２−４）。具体的には、中継サーバ２０は、生体認証要求をＡＰＩゲートウェイ３０に送信する。この生体認証要求には、認証用シリアルデータ、ユーザＩＤに関するデータを含める。

次に、ＡＰＩゲートウェイ３０は、シリアルデータ、ＩＤの転送処理を実行する（ステップＳ２−５）。具体的には、ＡＰＩゲートウェイ３０は、中継サーバ２０から取得した生体認証要求を認証サーバ４０に転送する。

次に、認証サーバ４０は、シリアルデータ、ＩＤの認証処理を実行する（ステップＳ２−６）。具体的には、認証サーバ４０は、認証情報記憶部４２を用いて、ユーザＩＤに関連付けられた認証用シリアルデータを確認する。認証サーバ４０は、認証結果を中継サーバ２０に返信する。認証情報記憶部４２において、ユーザＩＤに関連付けられた認証用シリアルデータが登録されていない場合には、認証結果に認証不可フラグを含める。一方、認証情報記憶部４２において、ユーザＩＤに関連付けられた認証用シリアルデータが登録されている場合には、認証結果に認証完了フラグを含める。

次に、中継サーバ２０は、オートログインＡＰＩ呼出処理を実行する（ステップＳ２−７）。具体的には、中継サーバ２０は、認証サーバ４０から取得した認証結果に認証不可フラグが含まれている場合には、サービス提供を拒否する。一方、認証結果に認証完了フラグが含まれている場合には、中継サーバ２０は、オートログインＡＰＩの利用要求を、ＡＰＩゲートウェイ３０に送信する。この利用要求には、ユーザＩＤに関するデータを含める。

次に、ＡＰＩゲートウェイ３０は、アクセストークンの確認処理を実行する（ステップＳ２−８）。具体的には、ＡＰＩゲートウェイ３０は、利用要求に応じて、オートログインＡＰＩを呼び出す。このオートログインＡＰＩは、オートログイン要求に含まれるユーザＩＤに関連付けられたアクセストークンを確認する。

次に、ＡＰＩゲートウェイ３０は、ＩＤ送信処理を実行する（ステップＳ２−９）。具体的には、ＡＰＩゲートウェイ３０は、オートログイン要求を銀行サーバ５０に送信する。このオートログイン要求には、ユーザＩＤに関するデータを含める。

次に、銀行サーバ５０は、ＩＤに基づいた認証処理を実行する（ステップＳ２−１０）。具体的には、銀行サーバ５０の内部ＡＰＩは、顧客情報記憶部５２に、ユーザＩＤが登録されているかどうかを確認する。

次に、銀行サーバ５０は、他の認証処理のスキップ処理を実行する（ステップＳ２−１１）。具体的には、銀行サーバ５０は、顧客情報記憶部５２に、ユーザＩＤが登録されていることを確認した場合、パスワード等を用いた他の認証は省略し、ユーザＩＤ及びパスワードを用いた認証処理に準じたログインを許可する。

次に、銀行サーバ５０は、トップ画面ＵＲＬの返信処理を実行する（ステップＳ２−１２）。具体的には、銀行サーバ５０は、トップ画面のＵＲＬ（トップ画面ＵＲＬ）を中継サーバ２０に返信する。このトップ画面には、ユーザＩＤ及びパスワードを用いてログインしたときに出力されるログインメニューの各要素が含まれる。

次に、中継サーバ２０は、トップ画面ＵＲＬの取得処理を実行する（ステップＳ２−１３）。具体的には、中継サーバ２０は、トップ画面ＵＲＬを取得する。この場合、中継サーバ２０は、銀行サーバ５０との間で、本人認証済みのセッションを維持する。
次に、中継サーバ２０は、トップ画面の要求処理を実行する（ステップＳ２−１４）。具体的には、中継サーバ２０は、取得したトップ画面ＵＲＬを用いて、トップ画面（ログイン画面）を要求する。
次に、銀行サーバ５０は、トップ画面の送信処理を実行する（ステップＳ２−１５）。具体的には、銀行サーバ５０は、トップ画面ＵＲＬに対応したトップ画面を中継サーバ２０に送信する。

次に、中継サーバ２０は、スクレイプ処理を実行する（ステップＳ２−１６）。具体的には、中継サーバ２０は、トップ画面ＵＲＬを用いてトップ画面を解析し、トップ画面に含まれる要素を抽出する。
次に、中継サーバ２０は、サービス画面の要求処理を実行する（ステップＳ２−１７）。具体的には、中継サーバ２０は、抽出した要素に基づいて、サービス画面を取得するためのＵＲＬを特定する。そして、中継サーバ２０は、特定したＵＲＬを用いて、銀行サーバ５０にサービス画面を要求する。

次に、銀行サーバ５０は、サービス画面の返信処理を実行する（ステップＳ２−１８）。具体的には、銀行サーバ５０は、画面要求を受けたサービス画面を、中継サーバ２０に返信する。
次に、中継サーバ２０は、スクレイプ処理を実行する（ステップＳ２−１９）。具体的には、中継サーバ２０は、取得したサービス画面を解析し、サービス画面に含まれる要素を抽出する。そして、中継サーバ２０は、抽出した要素を用いて、ユーザ提供画面を構築し、ユーザ端末１０に送信する。
次に、ユーザ端末１０は、画面表示処理を実行する（ステップＳ２−２０）。具体的には、ユーザ端末１０は、ユーザ提供画面を出力する。

以上、本実施形態によれば、以下のような効果を得ることができる。
（１）本実施形態によれば、銀行サーバ５０におけるＩＤ／ＰＷ認証処理（ステップＳ１−４）を完了した場合、ＡＰＩゲートウェイ３０は、アクセストークンの発行処理を実行する（ステップＳ１−６）。中継サーバ２０は、アクセストークンを保持し（ステップＳ１−７）、ユーザ端末１０からシリアルデータ、ＩＤを取得し、認証サーバ４０において、シリアルデータ、ＩＤを登録する。これにより、OAuthで利用されているアクセストークンと、生体認証で利用されるシリアルデータとを関連付けることができる。

（２）本実施形態によれば、ユーザ端末１０からシリアルデータ、ＩＤを取得した中継サーバ２０は、アクセストークンの確認処理（ステップＳ２−３）、シリアルデータ、ＩＤの転送処理（ステップＳ２−４）を実行する。認証サーバ４０は、ＡＰＩゲートウェイ３０から転送されたシリアルデータ、ＩＤの認証処理を実行する（ステップＳ２−６）。これにより、アクセストークンを有するユーザについて、生体認証を行なうことができる。

（３）本実施形態によれば、中継サーバ２０は、オートログインＡＰＩ呼出処理を実行する（ステップＳ２−７）。ＡＰＩゲートウェイ３０は、アクセストークンの確認処理（ステップＳ２−８）、ＩＤ送信処理（ステップＳ２−９）を実行する。銀行サーバ５０は、ＩＤに基づいた認証処理（ステップＳ２−１０）、トップ画面ＵＲＬの返信処理（ステップＳ２−１２）を実行する。中継サーバ２０は、トップ画面ＵＲＬの取得処理を実行する（ステップＳ２−１３）。これにより、オートログインＡＰＩにより、銀行サーバ５０においてログイン状態のセッションを生成することができる。そして、中継サーバ２０は、このトップ画面を用いたスクレイプ処理（ステップＳ２−１６）により、サービス画面を取得し、このサービス画面を用いたスクレイプ処理（ステップＳ２−１９）により、ユーザ端末１０に、ユーザ提供画面を出力する。従って、ＡＰＩ未対応サービスについて、ログインメニューから任意の要素にアクセスできる。

本実施形態は、以下のように変更して実施することができる。本実施形態及び以下の変更例は、技術的に矛盾しない範囲で互いに組み合わせて実施することができる。
・上記実施形態では、生体認証はＦＩＤＯ（登録商標）認証に限定されるものではない。また、銀行サーバ５０の金融サービスを中継サーバ２０が、ユーザの代理で利用する場合の認証は、OAuthに限定されるものではない。

・上記実施形態では、銀行サーバ５０における金融サービスの利用に適用したが、適用対象は金融サービスに限定されるものではなく、各種サービスに適用することができる。具体的には、ユーザ情報を管理するサーバ（第１のサーバ）でユーザ認証を行なった認証結果を用いて、連携する他のサーバ（第２のサーバ）が提供する各種サービスを利用する場合に用いることができる。

・上記実施形態では、銀行サーバ５０は、ＩＤ／ＰＷ認証処理を実行する（ステップＳ１−４）。ユーザが利用するサービスを提供するシステムにおける認証方法は、ＩＤ／ＰＷに限定されるものではない。例えば、ここで、ＦＩＤＯ（登録商標）等の生体認証を用いることも可能である。

・上記実施形態では、ユーザ端末１０は、ＩＤ／ＰＷ入力処理を実行する（ステップＳ１−１）。そして、中継サーバ２０、ＡＰＩゲートウェイ３０は、中継処理（ステップＳ１−２，Ｓ１−３）を実行し、銀行サーバ５０は、ＩＤ／ＰＷ認証処理を実行する（ステップＳ１−４）。銀行サーバ５０が、ユーザＩＤ、パスワードを取得する方法は、これに限定されるものではない。例えば、中継サーバ２０にアクセスしたユーザ端末１０からのリダイレクトにより、銀行サーバ５０が、ユーザ端末１０からユーザＩＤ、パスワードを直接的に取得するようにしてもよい。この場合、リダイレクト時に、中継サーバ２０を特定するための情報を含める。そして、銀行サーバ５０は、ユーザ端末１０から取得したユーザＩＤ、パスワードの認証結果に基づいて、中継サーバ２０に対するアクセストークンの発行指示処理を実行する（ステップＳ１−５）。

１０…ユーザ端末、１１…生体情報取得部、１２…認証モジュール、２０…中継サーバ、２２…アクセストークン記憶部、３０…ＡＰＩゲートウェイ、３１…金融サービスＡＰＩ、３２…オートログインＡＰＩ、４０…認証サーバ、４２…認証情報記憶部、５０…銀行サーバ、５２…顧客情報記憶部。

Claims (6)

1. クライアント端末と通信を行なう中継サーバ及び認証サーバに接続され、サービス提供を管理するサービス管理システムであって、
   前記サービス管理システムが、
   前記中継サーバから、前記クライアント端末の利用者のユーザ認証情報が前記認証サーバに送信され、前記認証サーバにおいて前記クライアント端末の利用者のユーザ認証の完了後に、前記中継サーバからアクセストークンに関連付けられたユーザＩＤを受信し、
   前記ユーザＩＤに関連付けられたアクセストークンに基づいて、前記利用者のログイン状態を生成し、
   前記ログイン状態に基づいて、前記利用者が複数のサービスを利用可能な各要素が含まれるメニュー画面のアドレス情報を、前記中継サーバに返信し、
   前記中継サーバにおいて、前記アドレス情報に基づいたスクレイプ処理を実行させることを特徴とするサービス管理システム。
2. 前記サービス管理システムは、認可サーバとサービス提供サーバとを含んで構成され、
   前記認可サーバは、
   前記中継サーバからアクセストークンに関連付けられたユーザＩＤを取得し、
   前記サービス提供サーバに対して、ログイン状態の生成を要求することを特徴とする請求項１に記載のサービス管理システム。
3. クライアント端末と通信を行なう中継サーバ及び認証サーバに接続されたサービス管理システムを用いて、サービスを提供する方法であって、
   前記中継サーバは、
   前記クライアント端末の利用者のユーザ認証情報を前記認証サーバに送信し、
   前記認証サーバからユーザ認証結果を取得し、前記ユーザ認証結果においてユーザ認証の完了情報を取得した場合、前記サービス管理システムにアクセストークンに関連付けられたユーザＩＤを送信し、
   前記サービス管理システムは、前記ユーザＩＤに関連付けられたアクセストークンに基づいて、前記利用者のログイン状態を生成し、
   前記ログイン状態に基づいて、前記利用者が複数のサービスを利用可能な各要素が含まれるメニュー画面のアドレス情報を、前記中継サーバに返信し、
   前記中継サーバは、前記アドレス情報に基づいてスクレイプ処理を実行することを特徴とするサービス管理方法。
4. 前記サービス管理システムは、認可サーバとサービス提供サーバとを含んで構成され、
   前記認可サーバは、
   前記中継サーバからアクセストークンに関連付けられたユーザＩＤを取得し、
   前記サービス提供サーバに対して、ログイン状態の生成を要求することを特徴とする請求項３に記載のサービス管理方法。
5. 前記中継サーバは、
   ユーザＩＤと関連付けて前記アクセストークンをアクセストークン記憶部に記録し、
   前記クライアント端末から、前記利用者の生体認証情報に基づく生体認証データ及びユーザＩＤを取得し、前記ユーザＩＤと関連付けられたアクセストークンが前記アクセストークン記憶部に記録されている場合、前記生体認証データ及びユーザＩＤを前記認証サーバに送信して記憶させ、
   新たなアクセスにおいて、前記クライアント端末から生体認証データを取得して、前記認証サーバに転送し、前記認証サーバから前記生体認証データを用いたユーザ認証結果を取得することを特徴とする請求項３又は４に記載のサービス管理方法。
6. 前記中継サーバは、前記クライアント端末から、生体識別情報をユーザ秘密鍵で暗号化して受信し、
   前記生体識別情報を用いてユーザ認証を行なう認証サーバから、ユーザ公開鍵で復号した生体識別情報を用いてユーザ認証を行なった認証結果を取得し、
   前記認証結果に基づいて、アクセストークンに関連付けられたユーザＩＤを用いて、前記サービス管理システムにログインすることを特徴とする請求項５に記載のサービス管理方法。

Images