JP6469886B2 - 決済確認画面選択装置 - Google Patents

Description

本発明は、様々なアプリケーションソフトが銀行の決済機能を呼び出す場合に、ユーザの確認を行う画面構成を選択する方法に関するものである。

パーソナルコンピュータやモバイル端末を活用したオンラインバンク、モバイルバンクのサービスが普及している。これらのサービスでは、銀行が残高照会、取引履歴照会、送金や公共料金支払い等の決済機能を持つアプリケーション（スマートフォン等の端末で動作するアプリケーションやサーバ側で動作するWebアプリケーション）を提供している。このとき、銀行が提供するアプリケーションを利用することで、ユーザは確認すべき内容を見ることができ、決済を実行することの判断をすることができる（銀行はユーザを騙すような画面を作らない）。特許文献１は、口座名義人の口座を銀行が信用度を評価し、評価点を第三者に開示する方法を開示しており、この評価点をユーザが参照することで決済の安全性の判断に利用することができる。

一方で、銀行が提供するインターネットバンク等のアプリケーションは、多数のユーザの多様な目的に対して画一的に対応する画面構成となっている。この場合、決済処理を行なおうとした場合には、不要な情報も表示されておりユーザが真に確認しなければならない情報への注目が困難な場合もある。

また、多数のユーザの多様な目的にそれぞれ対応するために、銀行は特定の画面を提供せずに、決済機能へのシステム接続機能を設けることも可能である。この決済機能に、銀行以外も含む個人、組織が開発した多様なアプリケーションを接続できるようにすることで、多様なユーザや多様な目的にそれぞれあったアプリケーションが登場し、ユーザの利便性を大きく向上する。またそれらのアプリケーションの提供者にとっても、提供者が運営しているサービスと、銀行サービスを連携したアプリケーションを開発することが可能となり、例えば銀行口座からの送金で支払いを完了するようなオンラインショッピングアプリを顧客に提供することが可能となる。ただしこの場合でも、ユーザの保護のためには、決済の最終的な確認画面は、個別のアプリケーションが自由にデザインするのではなく、銀行が画面への表示内容やユーザによる確認の入力方法を定義できるようにすることが望ましい。

特開2013-54487

ユーザが、銀行以外が提供する可能性のあるアプリケーションにより、銀行の決済機能を利用する場合、ユーザには確認すべき内容が漏れなく表示され、また、余分な情報が表示されていないことが望ましい。情報が過分に表示されているような場合には、ユーザは理解することを諦め、決済またはアプリケーションの利用を中断してしまうかもしれない。特許文献１に示される技術は、振込先の信頼度を数値としてユーザに示すことで、ユーザが振込の安全性を確認できる仕組みであるが、振込先の信頼度以外について、必要な情報を表示し、かつ、余分な情報を表示しないようにする仕組みについては含まれない。

本発明の課題は、様々なアプリケーションから呼び出すことが可能な銀行の決済機能について、決済内容の確認のための画面を、ユーザが確認すべき内容は表示し、同時にできるかぎり表示を減らすことで、余分な情報を表示しないことである。

銀行口座による決済を利用するアプリケーションが稼動する端末から、前記決済の情報を受け取り、前記銀行に連携するサーバが複数の決済確認画面のテンプレートを保持し、前記サーバは、前記アプリケーションからユーザを特定する情報、前記アプリケーションを特定する情報、送金元の口座を特定する情報、送金先の口座を特定する情報、金額からなる決済情報を受信し、前記決済情報と、過去に受信した決済情報を比較して前記決済情報による決済のリスク判定を行ない、前記端末に、前記決済のリスクに応じた決済確認画面のテンプレートを選択して送信し、前記ユーザによる前記決済確認画面を利用した決済確認を行わせる。

本発明により、より安全な決済機能を提供できる。

発明の全体を表す図である 端末、銀行サーバ、決済連携サーバの構成を表す図である 決済利用アプリ機能、決済確認画面機能、決済連携機能の処理フローを表す図である 店舗商品情報の構成を表す図である 画面テンプレートの構成を表す図である 決済確認画面を表す図である 決済確認画面の別例を表す図である 決済確認画面の別例を表す図である 取引履歴データの構成を表す図である 決済リスク判定機能の処理フローを表す図である。

以下、本発明の実施形態について、説明する。本実施形態では、銀行の決済機能を利用するアプリケーションについて、ユーザが決済の内容を確認する方法として、必要な情報を表示しつつ、不要な情報は表示しない決済確認画面をユーザに表示する方法を以下、図面を用いて示す。なお、以降では銀行における送金を例として示すが、銀行以外の業種や送金以外の分野でも、取引を実行するためにはユーザが内容を確認しなければならず、その取引の内容には、送金における送金元、送金先、金額のように、その取引に共通的な項目がある場合にも適用できる。

図1は、本発明の一実施形態のシステムの全体であり、端末110、銀行サーバ120、決済連携サーバ130、ネットワーク160からなる。端末110はユーザが利用する端末であり、たとえばスマートフォン、タブレット、パーソナルコンピュータである。銀行サーバ120は銀行の決済機能を提供するサーバである。決済連携サーバ130は、端末110等からの決済の依頼を受け付け、ユーザに適切な決済確認画面を選択して端末110によりユーザに確認させ、決済データを銀行サーバ120に送信するサーバである。決済連携サーバ130は、銀行に銀行システムの一部として設置してもよいし、銀行とは別の組織が設置したり、銀行システムとは独立して設置したりしてもよい。ネットワーク160は、例えばインターネット、携帯電話網、専用線である。

端末110は、決済利用アプリ機能111、ブラウザ機能112、決済確認画面機能114の各機能と店舗商品情報115を持つ。決済利用アプリ機能111は銀行の決済機能121を利用してユーザにサービスを提供するアプリケーションであり、たとえばオンラインショップでの買い物機能の提供するアプリケーションや、寄付を行うためのアプリケーション、資産管理アプリケーション、ゲーム（ゲーム内課金を行なうもの）等である（これらには限定されない）。決済利用アプリ機能111は、これらの目的に応じて別個のものを用意し、それぞれ異なるアプリケーションIDを持つものとする。決済利用アプリ機能111の詳細は後述する。ブラウザ機能112は一般的なWebブラウザの機能を提供する。決済確認画面機能114は、決済利用アプリ機能111による銀行サーバ120を利用する決済について、端末110のユーザの確認をとるための機能である。なおこれら決済利用アプリ機能111、ブラウザ機能112、決済確認画面機能114は、たとえばインターネット上のアプリケーションストア（アプリケーションの配布、販売サービス）からダウンロードし、端末110の記憶装置203にあらかじめ記憶しておくものとする。また、このとき決済利用アプリ機能111を特定するID（アプリケーションID）と名前（アプリケーション名）もダウンロードし、記憶装置203に対応付けて記憶しておくものとする（端末110は記憶装置203において、決済利用アプリ機能111とアプリケーションID、アプリケーション名を対応付けて記憶する）。なお決済利用アプリ機能111は、その目的に応じて、多様なアプリケーションが市場に提供されてもよく、この場合ユーザはそれらから利用するアプリケーションを任意に選択してよい。また決済確認画面機能114は、銀行を利用して決済を行なう場合に、ユーザが真に決済を行なおうとしていることを確認するための機能であり、複数の決済利用アプリ機能111で共有して利用してよい。店舗商品情報115は決済利用アプリ機能111が例えば買い物機能を持つとき、その決済利用アプリ機能111のために、店舗、商品とその金額、購入する場合の送金先の口座の情報等を記憶するデータベースであり、例えばインターネットからダウンロードし、端末110の記憶装置203にあらかじめ記憶しておくものとする。

銀行サーバ120は、外部から送金等の決済依頼を受け付けて決済処理を行う決済機能121と、多数のユーザの口座情報122を持つ。決済連携サーバ130は、端末110等から決済の依頼を受け付け、銀行サーバ120へ送信する決済連携機能131と、決済連携機能131から呼び出して決済のリスクを判定する決済リスク判定機能132、決済連携サーバ130を用いて、これまでに行われた決済情報を保持する取引履歴データ133、決済確認画面テンプレート134、ユーザを認証するための認証データ135を持つ。これらの詳細は後述する。

図２に端末110、銀行サーバ120、決済連携サーバ130の構成を示す。これらは、CPU201、メモリ202、記憶装置203、入力装置204、出力装置205、通信制御装置206とそれらを接続するバス207からなる。CPU201は記憶装置203からメモリ202へプログラムを読み込み、これを実行することで端末110または銀行サーバ120または決済連携サーバ130の全体の動作を制御する。以降、CPU201がメモリ202のプログラムを実行する処理を、端末110または銀行サーバ120または決済連携サーバ130の処理として記載する。記憶装置203は例えばハードディスクであり、プログラムや処理に必要なデータ、テーブルの情報を記憶する。入力装置204は例えばキーボードや出力装置205に組み込まれたタッチパネルである。出力装置205は例えばディスプレイである。通信制御装置206はネットワーク160に接続し他のシステムとの間で情報の授受を行う。

次に図3により、本発明の形態の全体の処理フローを示す。図3は決済アプリ利用機能111と決済確認画面機能114、決済連携機能131の処理フローと、それらの連携を示す。本処理フローは、ユーザが端末110を使って購入する商品を選択し、銀行のユーザの口座から販売者に送金することで決済するまでの処理を示す。例として商品の購入を示すが、寄付、ゲーム内での課金等、決済が必要となる他のアプリケーションでもよい。

まず、たとえば端末110がモバイル端末の場合には、ユーザが端末110において、タッチパネルである入力装置204から決済アプリ機能111を起動するためのアイコンをタップすることで、端末110において決済利用アプリ機能111が開始する（ステップ311）。決済利用アプリ機能111は起動すると、ユーザのログイン処理を行う（ステップ312）。ログイン処理とは、端末110はユーザからたとえばユーザIDとパスワードの入力を受け、これを決済連携機能131へ送信する。ユーザIDとパスワードの送信は、端末110の通信制御装置206により、ネットワーク160のたとえばインターネットを用いて行う。決済連携機能131は、決済連携サーバ130の通信制御装置206によりこれを受信する。以降、端末やサーバ間のデータの送受信は同様に行うものとする。決済連携機能131は、たとえばあらかじめ入力装置204から入力を受け記憶装置203に記憶しているユーザIDとパスワードの組み合わせのリスト（認証データ135）と比較し、一致するものがあればログイン可と判断する（ステップ331）。ログイン可と判断できない場合は、決済連携機能131は処理を終了する。ログイン可と判断できた場合には、決済連携機能131は決済利用アプリ機能111にログイン可であることを通知する。なお銀行サーバ120や、端末110に対するログインと認証を別途行なってもよい。

ログインが完了した後、決済利用アプリ機能111は、ユーザに対して決済を利用する多様な機能を提供する。本実施の形態では、ユーザが端末111において買い物をしたい店舗を選択し、次にその店舗で販売している商品から購入する商品を決定する買い物機能を店舗商品情報115を、利用して提供する場合を例として述べる。

図4に、店舗商品情報115の構成を示す。店舗商品情報115は、店舗名411、店舗ID412、消費名413、商品ID414、金額415、送金先口座416からなるデータベースである。店舗名411は商品を販売する店舗の名称であり、店舗ID412はその店舗を特定するIDである。商品名413はそれぞれの店舗で販売される商品の名称であり、店舗名411ごとに複数あってもよい。商品ID414は商品名413の商品を特定するIDである。金額415は商品ID414の商品の金額である。送金先口座416は商品ID414の商品をユーザが購入する場合に金額415の金銭の送金を行なう先（店舗名411の店舗）の口座を特定する情報であり、例えば金融機関番号、支店番号、口座番号の組み合わせである（送金先口座の名義人の名前を含んでもよい）。

買い物機能として、決済利用アプリ機能111はまず、ユーザから店舗の選択を受ける（ステップ313）。具体的には、決済利用アプリ機能111が店舗商品情報115の店舗名411の一覧を出力装置205のディスプレイに表示し、ユーザから入力装置204のタッチパネルにより店舗の指定を受ける。次に決済利用アプリ機能111は、ステップ313で選択された店舗の商品の選択画面を表示し、ユーザから商品の選択を受ける（ステップ314）。これは店舗商品情報115において、ステップ313で選択を受けた店舗の店舗名411に対応する商品名413の一覧を出力装置205のディスプレイに表示しユーザから入力装置204のタッチパネルにより商品の指定を受けることにより行なう。この後、決済利用アプリ機能111は、例えばその商品の詳細の情報（金額415等）を表示する等して、ユーザが購入のための決済に進むか否かの判断を求める。
ユーザが購入のための決済に進むことを例えばタッチパネルで購入ボタンの押下で決定した場合、次に決済利用アプリ機能111は決済情報を端末110の決済確認画面機能14に送信する（ステップ315）。決済情報とは、決済利用アプリ機能111が銀行における決済を依頼するためのデータであり、送金元口座、送金先口座、金額、店舗ID、商品ID、アプリケーションID、アプリケーション名、テンプレート分類と、ユーザへのメッセージを含む。ここで送金元口座はユーザの資金が保管されている銀行口座を特定する情報（例えば金融機関番号、店舗番号、口座番号の組み合わせであり送金先口座の名義人の名前を含んでもよい）であり、端末110が、入力装置204から入力を受け記憶装置203にあらかじめ記憶しておくものとする。送金先口座、金額、店舗ID、商品IDはステップ314で選択した商品に対応する店舗商品情報115の送金先口座416、金額415、店舗ID412、商品ID414の情報である。テンプレート分類は端末110がユーザに決済の確認をする画面のテンプレートの分類を特定する情報であり、例えば「送金」「ゲーム内課金」「寄付」等である。このテンプレート分類は、決済利用アプリ機能111の提供者が指定し、決済利用アプリ機能111のプログラムの一部として、あらかじめ記憶装置203に記憶しておく。ユーザへのメッセージは、決済確認画面でユーザに表示する文字列であり、詳細は後述する。このメッセージは、決済利用アプリ機能111のプログラムの一部として、あらかじめ記憶装置203に記憶しておく。決済確認画面機能114は受け取った情報を決済連携サーバ130の決済連携機能131へ送信する(ステップ321)。

決済連携機能131は決済情報を受信すると、決済リスク判定機能132を呼び出す。決済リスク判定機能132は、受信した決済情報のリスクを判定し、「アプリケーション」「送金先口座」「金額」の各項目について端末110のユーザが確認をすべきか否かの情報と、基本テンプレートを選択するか否かの区別を出力する。決済リスク判定機能132の詳細は後述する。

次に決済連携機能131は、テンプレートを選択して端末110の決済確認画面機能114へ送信する（ステップ333）。テンプレートの選択とは、ステップ315で決済利用アプリ機能111が送信したテンプレート分類と、決済リスク判定機能132が出力したユーザが確認すべき項目、基本テンプレートを選択するか否かの情報から、ユーザの決済確認画面のテンプレートとして画面テンプレート134から１つ選択する処理である。

画面テンプレート134の構成を図5に示す。画面テンプレート134は図5に示すように、テンプレート分類501とアプリケーション確認502、送金先口座確認503、金額確認504、テンプレートデータ505の項目を持つデータベースである。テンプレート分類501はテンプレートの分類を示すものである。ステップ333における添付レートの選択では、まず、決済リスク判定機能132が基本テンプレートを選択するとした場合には、テンプレート分類501が「基本」であるテンプレートデータ505を（図5に示すように1件のみ）、そうでない場合には、テンプレート分類501決済情報として受信したテンプレート分類と一致するテンプレートデータ505を選択する（アプリケーション確認502等の3つの項目のONとOFFの組み合わせにより8件。図5では一部省略して記載）。また、アプリケーション確認502、送金先口座確認503、金額確認504は、複数のテンプレートデータ505を絞り込むために用いる項目であり、決済リスク判定機能が「アプリケーション」「送金先口座」「金額」の各項目について確認すべきと判断した場合にはON、確認すべきと判断しなかった場合にはOFFを条件として、テンプレートデータ505の絞込みを行なう。
テンプレートデータ505は、端末110のユーザが決済の確認を行う場合に端末110が表示する画面のテンプレートであり、例えばHTMLとスクリプト（画面の制御を中心としたプログラム）のファイルや、その他の形式のファイル、アプリケーションプログラム（画面表示を行なうプログラム）である。このテンプレートデータ505は、決済確認画面の表示内容を定義するとともに、条件に応じて表示内容を変更する方法を含む。テンプレートデータ505を端末110に表示した場合の決済確認画面のサンプルを図6および図7、図8に示す。
図6はテンプレート分類501が「基本」である場合や、「送金」の場合でアプリケーション確認502と送金先口座確認503、金額確認504の全てがONの場合のテンプレートデータ505の内容を端末110が画面表示をした場合の模式図である。決済確認画面601は、アプリケーションの確認部611、送金先口座の確認部612、金額の確認部613を目立つように持つ（目立つように持つとは、ユーザの視線が届きやすい範囲（例えば画面の上部）に配置したり、文字の大きさ、色、装飾等により他と異なって見えるように配置したりすることを言う）。これらの確認部は、表示内容を変更する部分として、アプリケーション名、送金先口座、金額を含む（図6では「<アプリケーション名>」のように不等号で項目名を囲んだ部分）。また決済確認画面601はOKボタン621、キャンセルボタン622を持つ。これらは端末110のユーザが決済を承認する場合、キャンセルする場合にそれぞれ押下するボタンである。

この図6の決済確認画面601は、アプリケーション、送金先口座、金額のそれぞれを画面の目立つ位置で確認を求めるための画面である。一方で、それらの全ての確認が必須ではない場合や、全ての確認を求めようとするとユーザの確認する内容が多くなり、確認が疎かになると判断される場合もある。そこで、テンプレート分類501が例えば「送金」でも、複数のテンプレートデータ505を用意する。図7は金額確認504のみがONの場合のテンプレートデータ505の内容を端末110が画面表示をした場合の模式図である。決済確認画面J01は、図6と同様に金額の確認部613を持つが、アプリケーションの確認部611は画面下の目立たない部分に移動している。また、送金先口座の確認部612は省略している。

図8は、テンプレート分類501が「ゲーム内課金」である場合で、アプリケーション確認502と送金先口座確認503、金額確認504の全てがOFFの場合のテンプレートデータ505の内容を端末110が画面表示した場合の模式図である。決済確認画面801は、メッセージ欄802、80３とOKボタン804、キャンセルボタン805、アプリケーションの確認部806、金額確認部807を持つ。メッセージ欄801、802は、決済利用アプリ機能111が決済情報として送信した内容を埋め込む部分である。また、OKボタン804、キャンセルボタン805の表示内容についても同様である。

図6、図7、図8に示すアプリケーション名、送金先口座、金額の表示を変更する部分および、図8の各メッセージ欄やボタンへのメッセージの埋め込みは、決済連携機能131のステップ333のテンプレート選択処理で行なう（もしくは、端末110の決済確認画面機能114のステップ322の決済確認画面表示のときに行なう）。

次に端末110の決済確認画面機能114は、テンプレートを受信し、これを画面に表示し、ユーザの確認を受ける（ステップ322）。この処理では例えばHTMLであるテンプレートに従って、出力装置205に図6、図7、図8に示すような画面を表示し、OKボタンやキャンセルボタンのいずれかの押下を受けるものである。ユーザがキャンセルボタンを押下した場合には、ユーザが決済を中止する意図を示したものとして、決済確認画面機能114は以降の処理を行わない。ユーザがOKボタンを押した場合には、ユーザが決済する意図を示したものとして、決済確認画面機能114は、決済指示情報を決済連携サーバ130の決済連携機能131へ送信する（ステップ323）。ここで決済指示情報とは、ステップ321で受信した決済情報と同様のものである。決済連携機能131は、この決済指示情報を受信すると、情報を取引履歴データ133に記録した上で銀行サーバ120へ送信する（ステップ334）。取引履歴データ133は決済連携サーバ130を用いて行なわれた決済の情報を蓄積するデータベースである。これの構成を図9に示す。取引履歴データ133は、日付901、アプリケーションID902、ユーザID903、送金元口座904、送金先口座905、金額906の項目を持つ。取引履歴データ133への記録においては、日付901はその取引を行なう日付（例えば当日の日付）、アプリケーションID902、送金元口座904、送金先口座905、金額906は決済指示情報として受信したそれぞれの項目を記録する。ユーザID903はステップ331で受信したものを記録する。

銀行サーバ120は受信した決済情報に基づいて決済を行ない（送金元口座から送金先口座へ金額で指定された金額の送金を行なう）、この結果（送金が成功したか否かの情報）を決済連携機能131へ送信する。決済連携機能131は同様にこの結果を決済利用アプリ機能111へ送信し（ステップ335）、決済利用アプリ機能111はこの結果を受信し（ステップ316）、例えば画面に送金の成否を表示して終了する（決済利用アプリ機能111の目的に応じた処理を行ってもよい）。

以上により、図3の全体の処理が完了する。次に、決済連携機能131から呼び出される決済リスク判定機能132の処理について図10のフローチャートを用いて説明する。決済リスク判定機能132は、決済連携機能131が受信した決済情報について、取引履歴データ133を用いてそのリスクの大きさ、ユーザが何を確認すればよいのかを判断する機能である。取引リスク判定機能132は、ユーザへのアプリケーションの確認、送金先口座の確認、金額確認は必要（この状態をONとする）であるとして処理を開始し、まず、全ユーザによる当該アプリの利用回数をチェックする（ステップ911）。この処理は、決済連携機能131が受信した決済指示情報の中のアプリケーションIDが、取引履歴データ133のアプリケーションID902と一致するレコードの件数を数える。この件数が一定回数（例えば50回。この回数は決済連携サーバ130が入力装置204から入力を受けて記憶装置203にあらかじめ記憶しておくものとする。以降の「一定の回数」も同様とする）以上である場合には（ステップ912）、アプリケーション確認をユーザが確認する必要がないものと判断し（アプリケーション確認をOFFとする）（ステップ931）、ステップ915へ進む。ステップ912の判断が一定の回数未満の場合には、次に、当該ユーザによる当該アプリの利用回数を数える（ステップ913）。この処理は、決済連携機能131が受信した決済指示情報の中のアプリケーションIDが取引履歴データ133のアプリケーションID902と一致し、かつステップ331で受信したユーザIDが取引履歴データ133のユーザID903と一致するレコードの件数を数える。この件数が一定回数（例えば4回。ステップ911よりも少ない回数とする）以上である場合には（ステップ914）、ステップ931へ進む。ステップ914の判断が一定の回数未満の場合には、次に全ユーザによる当該送金先の利用回数をチェックする（ステップ91５）。以上の処理では、ユーザを限定せずに、当該アプリが多数回（50回以上）利用されている場合には、そのアプリケーションは安全であると判断し、そうでない場合でも、当該決済を行なおうとしているユーザが数回（4回）利用している場合には、ユーザの利用経験があるため安全であると判断することを意味する。

ステップ915、916、917、918、932では、それぞれステップ911、912、913、914、931と同様の処理を、アプリケーションIDではなく送金先口座により行なう。すなわち、ステップ915、91７では決済指示情報の中のアプリケーションIDの代わりに送金先口座と、取引履歴データ133の送金先口座905の一致するレコードの件数を数え、ステップ932では送金先口座をユーザが確認する必要がないものと判断する（送金先確認をOFFとする）。

次に取引履歴データ133から、決済指示情報で受信したアプリケーションIDがアプリケーションID902と一致し、かつ決済指示情報で受信した金額が金額902以下であるレコードの件数を数える（ステップ91９）。この件数が一定回数（例えば50回）以上である場合には（ステップ920）、金額をユーザが確認する必要がないものと判断し（金額確認をOFFとする）（ステップ933）、ステップ923へ進む。ステップ92０の判断が一定の回数未満の場合には、次に、当該ユーザによる当該アプリの決済金額をチェックする（ステップ921）。この処理は、決済連携機能131が受信した決済指示情報の中のアプリケーションIDがアプリケーションID902と一致し、かつ決済指示情報で受信した金額が金額902以下であり、かつステップ331で受信したユーザIDが取引履歴データ133のユーザID903と一致するレコードの件数を数える。この件数が一定回数（例えば4回。ステップ919より少ない回数とする）以上である場合には（ステップ922）、ステップ933へ進む。ステップ922の判断が一定回数未満の場合には、次に少数取引またはクレーム存在をチェックする（ステップ923）。

少数取引とは、当該決済のアプリ、送金先が限られた回数しか利用されていない場合であり、ステップ911の利用回数が一定の回数（例えば２０回）以下であるか、あるいはステップ915の送金先としての利用回数が一定の回数（例えば20回）以下である場合に、少数取引（リスクが高い）と判断する。また、過去に行なわれた取引について、詐欺等の不正があったとしてユーザから申しであったことが決済連携サーバ130の記憶装置203にその送金先口座が記憶されている場合には、決済指示情報の送金先口座と比較して一致するか確認する。一致する場合には、クレーム存在と判断する。少数取引と判断するかクレーム存在と判断した場合には（ステップ924）、端末110がユーザに決済の意思を確認する画面は基本テンプレートを用いるものと決定する（ステップ934）。

以上により決済リスク判定機能132は、「アプリケーション」「送金先口座」「金額」の各項目について端末10のユーザが確認すべきか否かの情報と、基本テンプレートを選択するか否かの決定を行い、これを決済連携機能131が前述のように利用するように出力して終了する。

次に、本発明の形態における決済リスク判定機能の処理タイミングについて述べる。図3に示した処理フローは、ユーザが購入する商品を選択した後に、決済リスク判定機能132が動作し、ユーザに対して決済確認画面表示を行なう。この場合、取引履歴データ133に大量の履歴が蓄積されているような場合には、決済リスク判定機能132の動作に時間を要し、ユーザに即時に決済確認画面を表示できず、ユーザが商品を購入することをやめてしまう可能性がある。そこで、図3の処理フローを一部変えるのみで、全体のユーザへの決済確認画面の表示を高速化する方法について示す。

このために、まず決済利用アプリ機能111はステップ312のログイン時に、アプリケーションIDも決済連携機能131に送信する。決済連携機能131はこの時点で、ユーザID、アプリケーションIDを得ることができるため、決済リスク判定機能132を呼び出し、そのステップ911、913の取引履歴データ133のチェックを完了する（なお、決済利用アプリ機能111は、チェックの完了を待たずに処理を進めてよい）。これにより、決済連携機能131は、決済指示情報を受け取る前に、決済リスク判定機能132の一部を完了できる。

さらに、ユーザの指示により端末110がステップ313の店舗選択を行なった場合に、図4に示す店舗商品情報115の送金先口座416により、今後のユーザの操作によっては送金が行なわれる先の口座を推測することができる（一般のオンラインショップでは、店舗や商品の選択は画面を戻ること等によりキャンセル可能であるため、ここで得られた送金先口座416が必ず、送金先になるものではない）。口座の推測ができた場合には、決済利用アプリ機能111はこれを決済連携機能131へ送信する。決済連携機能131はこの段階でユーザIDと送金先口座をこのタイミングに得ることで、決済リスク判定機能132のステップ915、917の取引履歴データ133のチェックを完了させる。これにより、決済リスク判定機能132のうち、完了した部分をさらに増やすことができる。なお、決済利用アプリ機能111において、ユーザが店舗の選択をやり直した場合は、再度、同様にステップ915、917のチェックまでを行なう。

また、ユーザの指示により端末110がステップ314の商品選択を行なった場合に、端末110は店舗商品情報115により、その商品の金額を抽出し、これを決済連携機能131へ送信する。決済連携機能131はこの段階でユーザIDと金額、アプリケーションIDを得ているため、決済リスク判定機能132のステップ919、92１を完了させる。

以上により、決済利用アプリ機能111がステップ314までにある間に、決済リスク判定機能132の処理のうち、取引履歴データ133を使ってチェックしなければならないことのチェックを開始できる。この結果を用いることで、決済利用アプリ機能111の315の後に決済リスク判定機能132が呼び出されたときには、先にチェックしている情報を利用することで、処理を迅速に終了することが可能となる。

次にWebアプリケーションの利用について述べる。ここまでは、端末110の記憶装置203に格納した決済利用アプリ機能111について述べたが、同様の処理は端末110のブラウザ機能112を用いても実現可能である。具体的には、端末110のブラウザ機能112を利用して、例えばオンラインショップの買い物を行い（Webを用いるオンラインゲーム等、その他のアプリケーションでもより）、その支払いのために銀行の決済を利用する。この場合、オンラインショップのWebサーバ（オンラインショップの機能を提供するWebサーバ。決済利用アプリ機能111と同様の画面をHTMLとして端末110のブラウザ機能へ配信）が、ユーザの操作するブラウザ機能112に対して商品の選択等の画面を提供し、ユーザが購入する商品を決定した場合等、オンラインショップのWebサーバがその購入のための決済情報を決済連携サーバ130へ送信し（直接送信する、またはブラウザ機能112を経由して送信）、決済連携サーバ130が決済連携機能131、決済リスク判定機能132の処理を行い、さらに決済確認画面機能114と同様の画面をHTMLとして端末110のブラウザ機能112へ配信する。これにより、Web環境においてもオンラインショップ等の様々なWebサーバが決定した決済情報について、決済連携サーバ130がそのリスクを判断して、適切な決済確認画面をブラウザ機能112へ表示させることができる。

以上の実施例により、様々なアプリケーションに対して銀行の決済機能を利用可能とする場合に、ユーザがその決済を確認するための適切な画面を提供することが可能となる。具体的には利用するアプリケーション、送金先、金額について、不要な情報に埋没せずにユーザが真に確認する必要がある項目のみを画面に表示することができる。これにより、様々なアプリケーションに対し、銀行の決済機能へのアクセスを安全に実現できる。

110 端末
111 決済利用アプリ機能
112 ブラウザ機能
114 決済確認画面機能
115 店舗商品情報
120 銀行サーバ
121 決済機能
122 口座情報
130 決済連携サーバ
131 決済連携機能
132 決済リスク判定機能
133 取引履歴データ
134 画面テンプレート
135 認証データ

Claims (8)

1. 銀行口座による決済を利用するアプリケーションが稼動する端末から、決済の情報を受け取り、銀行による決済に連携する決済連携サーバであって、
   複数の決済確認画面のテンプレートを保持する手段と、
   前記アプリケーションからユーザを特定する情報、前記アプリケーションを特定する情報、送金元の口座を特定する情報、送金先の口座を特定する情報、金額からなる決済情報を受信する手段と、
   前記決済情報と、過去に受信した決済情報を比較して前記決済情報による決済のリスクを判定する手段と、
   前記端末に、前記決済のリスクに応じた決済確認画面のテンプレートを選択して送信する手段を有し、
   前記ユーザによる前記決済確認画面を利用した決済確認を可能とすることを特徴とした決済連携サーバ。
2. 請求項1に記載の決済連携サーバにおいて、
   前記テンプレートを保持する手段は、前記決済確認画面のテンプレートとして、複数の分類ごとにテンプレートを保持し、
   前記受信する手段は、前記端末から、利用するテンプレートの分類を特定する情報を受信し、
   前記送信する手段は、前記テンプレートの選択においては、前記特定された分類のテンプレートの中から、前記決済のリスクに応じた前記決済確認画面のテンプレートを選択して前記端末へ送信することを特徴とする決済連携サーバ。
3. 請求項1または請求項２のいずれかに記載の決済連携サーバにおいて、
   前記リスクを判定する手段は、前記過去に受信した決済情報において、前記アプリケーションが利用された回数と、前記送金先の口座が利用された回数と、今回の決済金額以上の決済が行なわれた回数を用いて、前記決済のリスクを判定することを特徴とした決済連携サーバ。
4. 請求項3に記載の決済連携サーバにおいて、
   前記リスクを判定する手段は、
   前記過去に受信した決済情報において、前記アプリケーションが利用された回数を抽出し、前記回数が一定の回数以上である場合には、アプリケーションの確認を省略または目立たないように置いた前記テンプレートを選択する第1のリスク判定と、前記過去に受信した決済情報において、前記送金先が利用された回数を抽出し、前記回数が一定の回数以上である場合には、前記送金先の確認を省略または目立たないように置いた前記テンプレートを選択する第2のリスク判定と、
   前記過去に受信した決済情報において、前記決済情報の金額以上の金額の決済が行なわれた回数を抽出し、前記回数が一定の回数以上である場合には、
   前記金額の確認を省略または目立たないように置いた前記テンプレートを選択する第3のリスク判定の少なくとも１つのリスク判定を行なうことを特徴とした決済連携サーバ。
5. 請求項２に記載の決済連携サーバにおいて、
   前記保持する手段は、前記アプリケーションが表示内容を決定できる領域を含む、メッセージ欄付きテンプレートを保持し、
   前記アプリケーションから前記分類を特定する情報として、前記メッセージ欄付きテンプレートを含む前記分類を特定する情報を送信された場合であり、前記リスクとして、高いリスクがあると判断した場合には、前記メッセージ欄付きテンプレートではなく、前記アプリケーションの確認、前記送金先の確認、前記金額の確認を、他の項目と区別して表示可能な前記テンプレートを選択する手段をさらに有することを特徴とする決済連携サーバ。
6. 請求項3に記載の決済連携サーバにおいて、
   前記リスクを判定する手段は、
   前記端末から前記アプリケーションを特定する情報を受信したときに、前記アプリケーションが利用された回数について、第４のリスク判定を行い、
   前記端末から送金先口座に関する情報を受信したときに、前記送金先口座が利用された回数について、第５のリスク判定を行い、
   前記端末から決済金額を受信したときに、前記今回の決済金額以上の決済が行なわれた回数について、第６のリスク判定を行なうことを特徴とする決済連携サーバ。
7. 請求項２に記載の決済連携サーバに接続する端末であって、
   前記アプリケーションは、銀行決済を行なう場合に、前記決済情報と前記テンプレートの分類を前記決済連携サーバに送信する手段と、
   前記決済連携サーバから前記決済確認画面のテンプレートを受信すると、前記テンプレートを用いて、前記ユーザに前記決済確認を行なう手段と、
   前記ユーザが決済を行なうことに同意した場合には、前記決済連携サーバに決済を指示する情報を送信する手段とを有することを特徴とする端末。
8. 請求項１に記載の決済連携サーバにおいて、
   前記決済連携サーバがWebサーバとしての機能を持ち、
   前記受信する手段は、Web端末としての機能を持つ前記端末または、前記アプリケーションの機能を持つWebサーバから、前記決済情報を受信することを特徴とする決済連携サーバ。

Images