WO2019087416A1 - 金融取引制御システムおよびそのアプリケーションおよび金融取引制御方法 - Google Patents

Abstract

【課題】　クレジット利用、デビッド利用などの金融取引において、第三者の成り済まし使用やスキミングによる不正使用の防止ができる金融取引制御システムを提供する。　【解決手段】　利用者のアカウントごとに生成された金融取引処理アプリケーションファイルにオープン暗証コードとクローズ暗証コードを設定登録しておく。金融取引処理アプリケーションファイルのオープン処理には利用者端末より送信されたオープン暗証コードの認証を必要とし、その後、金融取引者からの金融取引情報を受けて金融取引処理アプリケーションファイルに金融取引情報を書き込む編集処理をすれば、利用者端末に対して金融取引情報に対する承認リクエストを送信して承認情報の返信を待ち、返信された承認情報に含まれているクローズ暗証コードの認証後、金融取引処理データの決済管理システムへの引き渡し処理と、金融取引処理アプリケーションファイルのクローズ処理を実行する。

Description

金融取引制御システムおよびそのアプリケーションおよび金融取引制御方法

　本発明は、クレジット利用、デビット利用を伴う金融取引における不正防止の技術分野に属する。

　クレジットカード、キャッシュカード等を利用した金融取引は高い利便性から広く普及している。近年は電子決済システムが普及しつつあり、スマートフォンなどに取り込んだクレジット機能アプリケーションやデビット機能アプリケーションを用いた電子決済も増えてきた。
　クレジット機能、デビット機能を利用した金融取引は便利であり、今後ますます普及が見込まれるが、その一方で不正使用に伴う問題もある。カード類を紛失したり盗難にあったりした場合、不正使用されるおそれがある。また、スキミング被害に合う恐れもある。
　クレジットカードやキャッシュカードの不正使用を防止するため、従来から様々な対策が採られている。

　クレジットカードの本人認証手段の１つとして本人のサインがある。
　伝統的な方法であるが、クレジットカード裏面のサイン欄に記入されている本人サインと、利用伝票にその場で利用者が記入した利用者サインを店員がその場で照合することで行われる。
　他のクレジットカードの本人認証手段として暗証番号がある。クレジットカードがＩＣチップ搭載しているＩＣカードである場合、ＩＣカードの記録情報として暗証コードを記憶させておき、上記のサインに代えてまたはサインと併用され、暗証番号が利用されることがある。例えば、店頭設置のクレジットカード決済端末にＰＩＮパッドが接続されており、ＰＩＮパッドを介して利用者から入力された暗証番号と、そのＩＣチップのメモリに記憶されている暗証番号を照合することで認証処理が行われる。

　他のクレジットカードの本人認証手段として顔画像確認がある。
　クレジットカードに顔写真が貼付されているものは従来から存在するが、例えば、図２５に示すように、特開平１０－２１７６５５号公報には、特殊印刷技術により、平面のプラスチック製のクレジットカードに対して、立体的な視認が可能な疑似３次元顔写真が印刷できる技術も紹介されている。

　他のクレジットカードの本人認証手段として生体情報による認証がある。
　クレジットカードがＩＣチップ搭載しているＩＣカードである場合、ＩＣカードの記録情報として生体情報を記憶させておき、例えば、店頭設置のクレジットカード決済端末に生体情報入力装置が接続されており、生体情報入力装置を介して利用者から入力された生体情報と、そのＩＣチップのメモリに記憶されている生体情報を照合することで行われる。

　例えば、図２６に示すように、特開２０１２－７３９０２号公報には、クレジットカードなどのＩＤカードのＩＣチップの記憶領域に生体情報を登録しておき、店頭設置のクレジットカード決済端末に生体情報取得用のデバイスが接続されており、デバイスを介して利用者から入力された生体情報と、そのＩＣチップのメモリに記憶されている生体情報を照合することで認証処理が行われる。

　また、例えば、図２７に示すように、特表２０１４－５１２５７９号公報には、生体情報を利用する特殊なＩＣカードタイプのクレジットカードが開示されている。クレジットカードの一部に指紋受容器と呼ばれる特殊なデバイスが設けられており、利用者がその指紋受容器に親指を接触させてクレジットカードを持ち、親指を指紋受容器に接触させて把持したまま、クレジットカード決済端末のカードリーダを通すことにより、クレジットカードのＩＣチップとクレジットカード決済端末とのデータ伝送ができるというものである。

特開平１０－２１７６５５号公報 特開２０１２－７３９０２号公報 特表２０１４－５１２５７９号公報

　しかしながら、上記した本人認証処理にはそれぞれ問題があった。
　クレジットカードの本人認証手段として本人のサインを用いる場合、セキュリティレベルが低い点が問題である。つまり、サインは偽書が可能な場合があり得る。重要な契約書などで書くサインは広いスペースが確保されており、書いたサインはそれなりに個性づけられており、契約社会の現在でもある程度有効性が担保されている。しかし、クレジットカードのサイン欄は小さく、簡略化したサインを使用することも多い。また、店頭のスタッフはかならずしもサイン認証に長けた者ばかりでなく、実質、サインの照合が簡略化されてしまうことも多い。

　次に、クレジットカードの本人認証手段として暗証番号を用いる場合も、セキュリティレベルが低い点が問題である。暗証番号は使用実態として４桁の番号に過ぎず、類推される場合もあり得るし、ある金融取引での決済端末入力時に第三者に流出してしまい、その後クレジットカードが不正使用される恐れがある。
　次に、クレジットカードの本人認証手段として顔画像を用いる場合、セキュリティレベルが十分ではない点が問題である。顔画像は貼り変えられる可能性もあり得るし、本人と年恰好がある程度近い人物であれば店員が気付かずに本人として取り扱う恐れもある。特に女性は化粧によってだいぶ変わり得るため成り済ましが起こり得る。
　次に、クレジットカードの本人認証手段として生体情報を用いる場合、セキュリティレベルは比較的高く担保されているが、生体情報を読み取るデバイスの装備が問題となる。クレジットカードは極めて広く普及しているため、クレジットカード決済端末の数は相当数に上る。ほとんどのクレジットカード決済端末はそのような生体情報の読み取りデバイスを装備していないため、現実問題としてクレジットカード決済端末に生体情報の読み取りデバイスを装備させることは難しいと言わざるを得ない。

　特表２０１４－５１２５７９号公報に開示された技術によれば、指紋受容器と呼ばれる特殊なデバイスはクレジットカード側に設けられるので、クレジットカード側の装備変更で済むと言える。しかし、親指を指紋受容器に接触させて把持したままクレジットカード決済端末のカードリーダを通すという使用条件が生じてしまう。つまり、これはカード利用者自身がクレジットカード決済端末を操作することを意味するが、店舗での使用状況は大半のケースにおいて、クレジットカード決済端末がカウンター内に設置されており、クレジットカードを利用者から手渡された店員がクレジットカード決済端末にクレジットカードを通して操作することがルーチン化されており、利用者自らがクレジットカード決済端末を使用することは店頭での混乱を招く。特表２０１４－５１２５７９号公報に開示された技術は、実際にはキャッシュカードを用いたＡＴＭ操作などが想定されており、利用者自身が端末を操作する場合に限られる。

　上記のように、クレジットカードの利用について様々なセキュリティレベルの本人認証処理が試行されているが、いずれも問題があり、クレジットカードの不正使用の問題を解決するには至っていない。
　ここで、利用者がクレジットカードやキャッシュカードの紛失や不正使用に気付いた場合、クレジットカードやキャッシュカードを無効化して被害を抑制する必要があった。

　例えば、紛失や盗難に気付いたカードの利用者からカード運営会社またはカード管理受託会社に対して、紛失・盗難にあったクレジットカードやキャッシュカードを無効にしたい旨の通知を電話やウェブサイトを介して通知する必要があった。通知を受けたカード運営会社自身またはカード管理受託会社が、カード会社の管理ホストコンピュータにおいて該当するクレジットカードやキャッシュカードの停止登録を行って対応することとなる。クレジットカードやキャッシュカードが無効化されると、例えば、クレジットカード決済端末を介してカード会社の管理ホストコンピュータに対して、該当するカードＩＤ番号を含むカードの利用要求の金融取引データが送信されてきても金融取引の認証をせず、利用不可の取り扱いとしていた。

　クレジットカードの利用停止及び再発行サービスは、カード会員がクレジットカードの紛失或いは不正使用に気付いて利用停止手続きを行うことによって初めて無効化できるものであり、時間が掛かっていた。また、一旦クレジットカードを利用停止すると再発行に時間と手間が掛かり、その間、カード会員はクレジットカードを利用できなくなるという問題がある。

　さらに、多数のクレジットカードを所持しているが、日常的には、それらの内、一部しか利用していない場合、利用してないクレジットカードの紛失或いは不正使用に気付き難いという問題がある。
　現在は、クレジットカード、キャッシュカードは正しく使用されることが大前提となっており、紛失や盗難にあった場合はイレギュラーの事故状態と捉える運用である。この運用である限り、紛失や盗難にあった場合にクレジットカードやキャッシュカードの利用停止手続が申請され、実際に利用停止処理が完了するまでクレジットカード、キャッシュカードは使用され得る状態に置かれてしまい、幾ばくかの被害が発生してしまう。

　上記問題点に鑑み、本発明は、クレジット利用、デビッド利用などの金融取引において、確実に、第三者の成り済まし使用やスキミングによる不正使用の防止ができる金融取引制御システムを提供することを目的とする。

　本発明者は、クレジットカード、キャッシュカードの不正使用の問題の解決に向けて、不正使用の防止を管理するアプリケーションおよびアプリケーションファイルの利用を思いついた。
　本発明の金融取引制御システムは、利用者のアカウントごとに生成された金融取引処理アプリケーションファイルと、利用者のアカウントに対する金融取引処理を制御する金融取引処理アプリケーションを備えた構成とし、金融取引処理アプリケーションファイルに、オープン処理に対するオープン暗証コードとクローズ処理に対するクローズ暗証コードが設定登録されており、金融取引処理アプリケーションが、利用者端末から金融取引処理リクエスト情報を受け、当該利用者のアカウントに対する金融取引処理アプリケーションファイルをオープンする“オープン処理”と、金融取引者から利用者のアカウントへの金融取引情報を受けて、金融取引処理アプリケーションファイルに金融取引情報を書き込む“編集処理”と、利用者端末に対して金融取引情報を承認するか否かを問う承認リクエストを送信し、利用者端末からの承認情報の返信を待つ“承認伺い処理”と、利用者端末からの承認情報の返信を条件として、金融取引処理アプリケーションファイルデータの決済管理システムへの“引き渡し処理”と、金融取引処理アプリケーションファイルの“クローズ処理”を実行することを特徴とするものである。

　このように、本発明の金融取引制御システムは、利用者のアカウントに対応した金融取引処理アプリケーションファイルを用い、当該ファイルを正常に開くオープン処理と、当該ファイルを正常終了するためのクローズ処理にそれぞれ暗証コードが設定されており、オープン暗証コードの照合によって金融取引処理アプリケーションファイルをオープンする“オープン処理”と、金融取引処理アプリケーションファイルに金融取引情報を書き込む“編集処理”までを行い、その後、利用者端末からの承認情報の返信を待つ“承認伺い処理”を入れることにより、利用者による使用状況の把握、承認を促し、クローズ暗証コードの照合を経て、金融取引処理アプリケーションファイルデータの決済管理システムへの“引き渡し処理”と、金融取引処理アプリケーションファイルの“クローズ処理”を実行することにより、シンプルで簡素な流れの中で、利用者による使用状況の把握、承認を確実に行うことができ、利用者が把握していない不正使用などを有効に防御することができる。

　金融取引に関する利用者ＩＤ情報が利用者媒体に保持されており、金融取引処理に際して利用者媒体を介して利用者ＩＤ情報がやり取りされる。
　利用者ＩＤ情報を保持する手段も多様なものが可能である。
　従来型のカード媒体に保持させてカードリーダを介して利用者ＩＤ情報を取得するもの、スマートフォンなどに保持させて端末を介して電子クレジット決済処理において利用者ＩＤ情報を取得するものもあり得る。
　次に、オープン暗証コード、クローズ暗証コードとして、多様なものが可能である。
　例えば、ＰＩＮコード、パスワード、バーコードなどの１次元コード、ＱＲコードなどの二次元コード、静脈や指紋や虹彩や声紋など利用者の生体情報などがある。

　本発明では“オープン暗証コード”と“クローズ暗証コード”という２つの暗証コードを設定登録する手法は高いセキュリティを達成する。
　従来のアプリケーションにおいて、立ち上げ時のオープン暗証コード（パスワード、生体情報）を設定するものは存在したが、終了時のクローズ暗証コード（パスワード、生体情報）を設定するものは存在しなかった。このようにアプリケーションのオープン時と、金融取引情報の内容確定と終了時の２回にわたって暗証コード入力を求めるという技術は、本発明者がオリジナルに発明した素晴らしい手法である。つまり、利用可否ステイタス情報状態制御手段の金融取引処理アプリケーションが、オープン時の金融取引処理アプリケーションファイルオープン処理において、切り替えリクエスト情報に含まれるオープン暗証コードと設定登録にかかるオープン暗証コードとの照合による認証処理を経て金融取引処理アプリケーションのオープン処理を行う。さらに、利用可否ステイタス情報状態制御手段の金融取引処理アプリケーションが、終了時にあたる承認確認処理において承認情報に含まれるクローズ暗証コードと設定登録にかかるクローズ暗証コードとの照合による認証処理を経て連続処理を実行して金融取引処理アプリケーションファイルをクローズする。このように、クレジット利用やデビット利用の利用開始直前にも利用者によるオープン暗証コード入力を求め、クレジット利用やデビット利用の利用終了時にも利用者によるクローズ暗証コード入力を求めるものである。

　なお、オープン暗証コード、クローズ暗証コードとして生体情報を用いる構成とすれば、利用者本人を認証することもできる。利用者端末がスマートフォンである場合、スマートフォンに利用者の生体情報読み取りデバイスが搭載されているものとする。店舗据え付けの生体情報読み取りデバイスを利用する構成であれば、悪意の店舗または端末がハッキングされている店舗で生体情報読み取りデバイスを利用すると、重要な生体情報自体が盗用・流出するおそれがあるが、自分が保持しているスマートフォンなどに装備された生体情報読み取りデバイスであれば、他者による盗用・流出するおそれが劇的に減少する。

　次に、本発明者は、さらに高いセキュリティレベルの運用も思いついた。
　クレジットカード、キャッシュカードは１日のうちで実際に使用する時間は極めて限られており、店頭での支払いなどの数十秒程度である。１日に数回使用するとしてもやはりクレジットカード、キャッシュカードを実際に使用する時間はわずかである。現在のシステムの運用は、そのわずかな時間のために、常時クレジットカード、キャッシュカードを有効な状態に固定し、紛失や盗難にあったことが発覚した場合にのみ無効化するものであるが、この考え方を逆転させ、常時クレジットカード、キャッシュカードを無効の状態に固定しておき、店頭などで使用する瞬間だけ動的に有効化する運用とすればもっとも安全である。かつ、クレジットカード、キャッシュカードの有効化の手段として本人自身が保持するスマートフォンなどの携帯端末を介して本人認証付きにて行うものであれば高いセキュリティレベルが達成できる。たとえ、紛失したり盗難にあったりしてもクレジットカード、キャッシュカードの拾得者にとって簡単には不正使用ができないこととなる。

　このように、アカウントがデフォルトとして通常時無効状態においておくという考え方は従来にはなく、利用者が使用する場合にのみ、利用可否ステイタス情報を自発的に細かく切り替えられることにより、カードの紛失時、盗難時のなりすまし使用や、スキミングなどの不正使用が有効に防止できる。

　そこで、本発明者は、利用者のクレジットカードやキャッシュカードの利用において、店頭などで使用する直前にアカウントを動的に有効化し、その後かならずクレジットカード、キャッシュカードを常時無効の状態に戻す処理を付加する拡張も行った。
　本発明の金融取引制御システムは、上記した基本構成に加えて、金融取引処理アプリケーションが、利用者のアカウントの有効無効状態または金融取引受け入れ可否の状態を示す利用可否ステイタス情報の切り替えを制御する利用可否ステイタス情報状態制御手段を備え、金融取引処理アプリケーションが、利用可否ステイタス情報を通常時は無効状態に維持する利用可否ステイタス情報状態制御手段を介した無効デフォルト処理を行い、利用者端末からの承認情報の返信を条件として、利用可否ステイタス情報の一時有効状態への切り替え処理と、引き渡し処理と、利用可否ステイタス情報の無効デフォルト処理と、クローズ処理を連続処理するものである。
　つまり、上記した基本の金融取引制御システムの処理の流れは、オープン処理→編集処理→承認伺い処理→引き渡し処理→クローズ処理の流れであったが、この改良型の金融取引制御システムの処理の流れは、無効デフォルト処理を通常時のデフォルト処理とし、オープン処理→編集処理→承認伺い処理→有効状態切り替え処理→引き渡し処理→無効デフォルト処理→クローズ処理の流れとして、さらにセキュリティレベルを向上させている。

　上記構成のように、金融取引処理アプリケーションは、利用可否ステイタス情報状態制御手段により、利用可否ステイタス情報が無効デフォルト処理により通常時無効状態に維持しておき、その通常時無効状態において、利用者端末から送信される情報が金融取引処理を開始する旨の金融取引処理リクエスト情報である場合、金融取引処理アプリケーションが利用者のアカウントに関する金融取引処理アプリケーションファイルをオンデマンドでオープンする「(1)オープン処理」を実行する。つまり『今からクレジット利用、デビット利用を行うので、その処理を受け付けるアプリケーションファイル（金融取引処理アプリケーションファイル）を立ち上げる』という処理を実行する。その金融取引処理アプリケーションが金融取引者（つまり、クレジット利用を行う店舗やクレジット利用を認めるＥＣサイト）からの利用者のアカウントに対する金融取引情報（つまりクレジットでの代金決済の要求）を受け付けると、金融取引処理アプリケーションファイルにその金融取引情報の内容を書き込む編集を受け付けて処理する「(2)編集処理」を実行する。さらに、利用者端末（スマートフォン）に対して金融取引情報を受け付けて正常終了して良いか否かを問う承認リクエストを送信する“承認リクエスト処理”と、承認リクエストに対する利用者端末からの承認情報の返信を待つ「(3)承認確認の伺い処理および受付処理」（例えば、スマートフォンの画面に取引内容の表示と、承認ボタンを表示し、その承認ボタンの押下または生体情報の入力を待つ処理）と、利用者端末からの承認情報の返信（承認ボタンの押下や生体情報の入力）を受け、承認確認処理で承認情報が確認されたことを条件として、利用可否ステイタス情報の一時有効状態へ切り替える「(4)利用可否ステイタス情報一時有効状態切り替え処理」と、金融取引処理アプリケーションファイルに書き込まれている金融取引情報を決済管理システムへ引き渡す「(5)金融取引処理の決済管理システムへの引き継ぎ処理」と、利用可否ステイタス情報の通常時無効状態へ戻す「(6)利用可否ステイタス情報の無効状態切り替え処理」と、金融取引処理アプリケーションファイルを終了してクローズする「(7)クローズ処理」を連続処理する。

　つまり、店舗からの金融取引情報またはＥＣサイトからの金融取引情報が決済管理システムに送信されても、金融取引処理アプリケーションが代理でその金融取引情報を金融取引処理アプリケーションファイルに受け付けておき、利用者からの承認ボタンの押下があるまでは、利用可否ステイタス情報の通常時無効状態を維持しておく。利用者からの承認ボタンの押下があると、一気に、(4)利用可否ステイタス情報一時有効状態切り替え処理と、(5)金融取引処理の決済管理システムへの引き継ぎ処理と、(6)利用可否ステイタス情報の無効状態切り替え処理と、(7)クローズ処理の一連の処理を連続処理する。

　一方、利用者端末には利用者アプリケーションがインストールまたはＡＳＰで利用可能となっている。利用者アプリケーションは金融取引制御システムとやり取りして金融取引制御を実行する。
　利用者アプリケーションには、金融取引処理リクエスト情報を作成する金融取引処理リクエスト情報作成処理と、作成した金融取引処理リクエスト情報を金融取引処理アプリケーションに送信する金融取引処理リクエスト情報送信処理と、承認情報を作成する承認情報作成処理と、作成した承認情報を金融取引処理アプリケーションに返信する承認情報返信処理を備えた構成となっている。
　単純にアカウントの有効・無効状態の切り替えを可能とする場合に比べ、上記構成では、利用者端末からの承認情報の返信を条件として、利用可否ステイタス情報の一時有効状態への切り替え処理と、金融取引処理アプリケーションファイルの決済管理システムへの引き渡し処理と、利用可否ステイタス情報の無効デフォルト処理と、金融取引処理アプリケーションファイルのクローズ処理を連続処理とすることにより、金融取引処理時以外は通常時無効状態が維持される。

　上記のように、連続処理となっていない場合、利用可否ステイタス情報の切り替え忘れや利用者がショッピングモールなどで滞留する数時間にわたり、利用者アカウントが有効状態になったまま放置される可能性がある。もし、利用者アカウントの有効状態の時間的制約を設けた場合、実際の店頭での店員とのやり取りや商品の引き渡し準備に時間が掛かったりすると利用者アカウントの有効状態が強制的に切り替わってしまうという不都合がある。もし、利用者アカウントの有効状態の時間的制約を長く設定しすぎると、しばらくは有効状態が継続されてしまい、スキミングによる不正キャッシングなどを完全には防止できない。

　このように、本発明の金融取引制御システムは、いわば、カード不正使用防止システムとして利用できる。金融取引処理アプリケーションは無効デフォルト処理によって通常時は金融取引が利用できず、利用者のクレジットカードやキャッシュカードの利用時にのみ、店頭やＥＣサイトなどで使用する際に、利用可否ステイタス情報の一時有効状態への切り替え処理をし、金融取引を完了した後に引き続き無効デフォルト処理を連続処理するため、カード不正使用が防止できる。

　上記のように、本発明の金融取引制御システムは、利用者の金融取引開始によって利用可否ステイタス情報の有効・無効状態が書き換えられるが、もっとも、金融機関側の与信情報に基づくアカウントの無効設定は書き換え不可とする運用がこのましい。つまり、利用者が与信オーバー状態や、利用者の利用代金の口座引き落としが失敗してクレジット利用が凍結された状態である場合には、金融機関側から与信情報に基づくアカウントの無効設定がされるが、その無効設定まで利用者が自由に書き換えることを許容する訳にはいかないからである。

　そこで、決済管理システム上の与信に基づいて設定される「利用者のアカウントの有効無効状態または利用者のアカウントに対する前記金融取引受け入れの有効無効状態を示す利用可否ステイタス情報」の設定が有効状態を示す設定の場合、決済管理システムが、利用可否ステイタス情報状態制御手段による利用可否ステイタス情報の切り替え制御を優先させて利用可否ステイタス情報の切り替えを受け入れ、逆に、決済管理システム上の与信に基づいて設定される「利用者のアカウントの有効無効状態または利用者のアカウントに対する金融取引受け入れの有効無効状態を示す利用可否ステイタス情報」の設定が無効状態を示す設定の場合、決済管理システムが利用可否ステイタス情報状態制御手段による利用可否ステイタス情報の切り替え制御を受け入れず、利用可否ステイタス情報の無効状態を維持するという取扱いとする。
　なお、上記のように、与信情報に基づく利用可否ステイタス情報の無効状態の設定を優先させ、利用者の操作による利用可否ステイタス情報の切り替え設定を不可とするか否かも運営主体の運用によって決めれば良い。例えば、与信情報に基づく利用可否ステイタス情報の無効状態の設定と、利用者の操作による利用可否ステイタス情報の切り替え設定のいずれを優先するかは運営主体の運用によって選択可能とする取り扱いも可能である。

　本発明の金融取引制御システムによれば、カード不正使用を防止できる。
　本発明の金融取引制御システムは、利用者のアカウントに対応した金融取引処理アプリケーションファイルを用い、当該ファイルを正常に開くオープン処理と、当該ファイルを正常終了するためのクローズ処理にそれぞれ暗証コードが設定されており、オープン暗証コードの照合によって金融取引処理アプリケーションファイルをオープンする“オープン処理”と、金融取引処理アプリケーションファイルに金融取引情報を書き込む“編集処理”までを行い、その後、利用者端末からの承認情報の返信を待つ“承認伺い処理”を入れることにより、利用者による使用状況の把握、承認を促し、クローズ暗証コードの照合を経て、金融取引処理アプリケーションファイルデータの決済管理システムへの“引き渡し処理”と、金融取引処理アプリケーションファイルの“クローズ処理”を実行することにより、シンプルで簡素な流れの中で、利用者による使用状況の把握、承認を確実に行うことができ、利用者が把握していない不正使用などを有効に防御することができる。

実施例１にかかる金融取引制御システム１００Ａの構成を簡単に示した図である。 実施例１にかかる金融取引制御システム１００Ａのクレジット利用の手続の流れを示すシステムブロック図（その１）である。 実施例１にかかる金融取引制御システム１００Ａのクレジット利用の手続の流れを示すシステムブロック図（その２）である。 実施例１にかかる金融取引制御システム１００Ａのクレジット利用の手続の流れを示すシステムブロック図（その３）である。 実施例１にかかる金融取引制御システム１００Ａのクレジット利用の手続の流れを示すシステムブロック図（その４）である。 実施例１にかかる金融取引制御システム１００Ａのクレジット利用の手続の流れを示すシステムブロック図（その５）である。 実施例１にかかる金融取引制御システム１００Ａの利用者端末２００での操作画面の例を示す図（その１）である。 実施例１にかかる金融取引制御システム１００Ａの利用者端末２００での操作画面の例を示す図（その２）である。 実施例２にかかる金融取引制御システム１００Ｂの構成を簡単に示した図である。 実施例２にかかる金融取引制御システム１００Ｂのクレジット利用の手続の流れを示すシステムブロック図（その１）である。 実施例２にかかる金融取引制御システム１００Ｂのクレジット利用の手続の流れを示すシステムブロック図（その２）である。 実施例２にかかる金融取引制御システム１００Ｂのクレジット利用の手続の流れを示すシステムブロック図（その３）である。 実施例２にかかる金融取引制御システム１００Ｂのクレジット利用の手続の流れを示すシステムブロック図（その４）である。 実施例２にかかる金融取引制御システム１００Ｂのクレジット利用の手続の流れを示すシステムブロック図（その５）である。 実施例２にかかる金融取引制御システム１００Ｂの利用者端末２００Ｂでの操作画面の例を示す図（その１）である。 実施例２にかかる金融取引制御システム１００Ｂの利用者端末２００Ｂでの操作画面の例を示す図（その２）である。 実施例３にかかる金融取引制御システム１００Ｃの構成を簡単に示した図である。 実施例３にかかる金融取引制御システム１００Ｃのクレジット利用の手続の流れを示すシステムブロック図（その１）である。 実施例３にかかる金融取引制御システム１００Ｃのクレジット利用の手続の流れを示すシステムブロック図（その２）である。 実施例３にかかる金融取引制御システム１００Ｃのクレジット利用の手続の流れを示すシステムブロック図（その３）である。 実施例３にかかる金融取引制御システム１００Ｃのクレジット利用の手続の流れを示すシステムブロック図（その４）である。 実施例３にかかる金融取引制御システム１００Ｃのクレジット利用の手続の流れを示すシステムブロック図（その５）である。 実施例３にかかる金融取引制御システム１００Ｃの利用者端末２００Ａでの操作画面の例を示す図（その１）である。 実施例３にかかる金融取引制御システム１００Ｃの利用者端末２００Ａでの操作画面の例を示す図（その２）である。 特開平１０－２１７６５５号公報に示す従来技術のクレジットカードを示す図である。 特開２０１２－７３９０２号公報に示す従来技術のクレジットカード利用システムを示す図である。 特表２０１４－５１２５７９号公報に示す従来技術のクレジットカードを示す図である。

　以下、本発明を実施するための最良の形態について実施例により具体的に説明する。なお、本発明はこれらの実施例に限定されるものではない。
　実施例１として、クレジットカードやキャッシュカードなどの利用者ＩＤ保持媒体３００を用いて金融取引処理を行う金融取引制御システム１００Ａの例を示す。金融取引処理アプリケーションファイル１１２Ａには、オープンする際のオープン暗証コードとクローズする際のクローズ暗証コードが設定されている例を示す。
　実施例２として、利用者ＩＤ保持媒体３００を不要とし、スマートフォン２００などに金融取引処理に必要な利用者ＩＤ情報などが電子化されたいわゆる電子クレジット金融取引処理や電子デビット金融取引処理を行う例を示す。
　実施例３として、実施例２と同様、利用者ＩＤ保持媒体３００を不要とした、いわゆる電子クレジット金融取引処理や電子デビット金融取引処理を行う例において、利用可否ステイタス情報、利用可否ステイタス情報状態制御手段を備え、通常時に無効デフォルト処理を行ってセキュリティレベルを向上させた例を示す。

　実施例１にかかる本発明の金融取引制御システム１００Ａおよびそれを利用する利用者アプリケーション２１０Ａについて説明する。
　図１は実施例１にかかる金融取引制御システム１００Ａおよび利用者アプリケーション２１０Ａの構成を簡単に示した図である。図１には、金融取引制御システム１００Ａおよび利用者アプリケーション２１０Ａのほか、利用者端末２００Ａ、利用者媒体３００、店舗端末/ＥＣサイト４００、決済管理システム５００Ａが示されている。

　金融取引制御システム１００Ａは、利用者によるクレジット利用またはデビット利用を伴う金融取引を制御するシステムである。
　金融取引制御システム１００Ａは、利用者端末２００Ａと決済管理システム５００Ａとの間に介在するものであるが、システムの構築箇所としては、利用者端末２００Ａ上に装備されていても良いし、決済管理システム５００Ａに装備されていても良い。この例では、決済管理システム５００Ａに装備されている例として示す。
　金融取引制御システム１００Ａは、少なくとも金融取引処理アプリケーション１１０Ａを備えており、さらに、本実施例１の構成では暗証コード認証手段１２０Ａも備えている。これらは詳しく後述する。

　利用者端末２００Ａは、スマートフォンなどの利用者が携帯する端末が好ましい。利用者端末２００Ａは、利用者アプリケーション２１０Ａ、データ入力手段２２０、暗証コード入力手段２３０、通信手段２４０を備えている。
　利用者アプリケーション２１０Ａは、金融取引制御システム１００との間でデータのやり取りをするアプリケーションである。この利用者アプリケーション２１０Ａを搭載することにより利用者は利用者端末２００Ａを介して、クレジット利用、デビット利用のサービスについて本発明の金融取引サービスを利用できる。
　データ入力手段２２０は、一般の携帯型端末が装備するタッチディスプレイや音声入力手段などの利用者インターフェイスを介して利用者よりデータの入力を受け付ける手段である。
　暗証コード入力手段２３０は、利用者から暗証コードの入力を受け付けるデバイスである。
　暗証コードがＰＩＮコードやパスワードである場合は、ＰＩＮパッド、キーボード、タッチパネルなどの入力デバイスがある。データ入力手段２２０が暗証コード入力手段２３０を兼用する構成でも良い。なお、暗証コードは４桁以上の数字・文字列が好ましい。利用者が入力するＰＩＮコードと利用者端末２００Ａの端末ＩＤ番号とを組み合わせるなど一定のアルゴリズムで計算したコードを暗証コードとして送信するものでも良い。
　また、暗証コードがバーコードの一次元コードやＱＲコードなどの二次元コードである場合、当該コードの読み取りリーダーやカメラなどの入力デバイスがある。
　暗証コードが生体情報である場合、生体情報としては、指紋情報、指静脈情報、手のひら静脈情報、虹彩情報、顔画像情報、声紋情報などがあり得る。この場合利用者端末２００Ａの暗証コード入力手段２３０は、対応する生体情報が読み取れるデバイス（指紋リーダー、静脈リーダー、虹彩リーダー、カメラ、マイクロフォンなどの音声入力装置など）が装備されているものとする。
　通信手段２４０は、利用者端末２００Ａが装備している通信機能で良い。

　次に、利用者媒体３００を説明する。
　利用者媒体３００は、クレジット利用時やデビッド利用時に用いる媒体であり、典型的には、磁気ストライプカード、ＩＣカード、非カード型のＩＣチップ埋設物、人体埋設型のマイクロＩＣチップなどがあり得る。利用者媒体３００には利用者ＩＤ情報、カード情報、金融取引に必要な情報などの各種情報が保持されており、店舗端末/ＥＣサイト４００に対して提示することにより、クレジット利用やデビッド利用を伴う金融取引を申し込むことができる。
　なお、利用者媒体３００を用いず、スマートフォンなどに金融取引で要求される利用者ＩＤ情報などを電子化した電子クレジット金融取引処理や電子デビット金融取引処理を行う金融取引制御システムについては実施例２において示す。

　次に、店舗端末/ＥＣサイト４００を説明する。
　店舗端末/ＥＣサイト４００は、決済管理システム５００Ａとの間での決済情報をやり取りする機能を備えた店舗に据え付けられた端末や、インターネット上の電子商取引可能なウェブサイトであり、利用者情報入力手段４１０、金融取引情報生成手段４２０、通信手段４３０を備えている。
　利用者情報入力手段４１０は、利用者媒体３００に対応したカードリーダであり、利用者媒体３００からカード情報や利用者ＩＤ情報などを読み取るデバイスである。
　金融取引情報生成手段４２０は、利用者が所望するクレジット利用、デビット利用のサービスに伴う金融取引情報を生成する手段である。例えば、カード情報、利用者ＩＤ情報、店舗情報/取引者情報、決済金額、決済管理システム５００ＡのＩＤ情報などを含む金融取引情報を生成し、通信手段４３０を介して、ネットワークを介して決済管理システム５００Ａに対して送信する。

　次に、決済管理システム５００Ａを説明する。
　決済管理システム５００Ａは、金融機関や信販会社などが管理運営しているシステムであり、利用可否ステイタス情報５１０、与信管理部５２０、決済処理部５３０を備えている。金融取引制御システム１００とのデータのやり取りができ、さらに、オンライン上で店舗端末/ＥＣサイト４００や利用者端末２００Ａとデータ通信可能となっている。

　ここで、利用可否ステイタス情報５１０とは、決済管理システム５００Ａ上で管理される利用者のアカウントの有効無効状態、または、利用者のアカウントに対する金融取引受け入れの有効無効状態を示す情報である。
　この構成例では、利用可否ステイタス情報５１０は、与信管理部５２０により管理されている例となっている。この利用可否ステイタス情報５１０が有効状態を示す場合、決済管理システム５００Ａは、当該利用者によるクレジット利用またはデビット利用を伴う金融取引を受け入れる取り扱いとなっている。逆に、この利用可否ステイタス情報５１０が無効状態を示す場合、決済管理システム５００Ａは、当該利用者によるクレジット利用またはデビット利用を伴う金融取引を拒否する取り扱いとなっている。
　本来は、与信に問題がないクレジット利用者、デビット利用者の利用可否ステイタス情報５１０は有効状態に維持されている。

　与信管理部５２０は、金融機関や信販会社などが管理運営している一般の決済管理システムが装備している与信管理部と同様で良い。利用可否ステイタス情報５１０の管理を行っている。

　決済処理部５３０は、金融機関や信販会社などが管理運営している一般の決済管理システムが装備している決済処理部と同様で良く、利用可否ステイタス情報が有効状態と確認された条件下、店舗端末/ＥＣサイト４００から受信した金融取引情報を基に決済処理を行うものである。
　なお、該当する利用者ＩＤ情報の金融取引情報が店舗端末/ＥＣサイト４００から送信されてくると、そのまま決済処理を行うのではなく、金融取引処理アプリケーション１１０Ａに金融取引情報を一旦引き渡し、金融取引処理アプリケーション１１０Ａでの処理に任せ、後述する金融取引処理アプリケーション１１０Ａの“金融取引情報データ引き渡し処理”により、金融取引処理アプリケーションファイル１１２Ａの金融取引情報のデータ内容が引き渡された後に、通常の決済処理（利用可否ステイタス情報の有効状態の確認、金融決済処理など）を実行する。
　なお、利用者の与信情報に基づく決済管理システム側による無効設定との優劣については実施例１と同様の処理で良い。

　次に、金融取引制御システム１００Ａの構成を詳しく述べる。
　金融取引制御システム１００Ａは、金融取引処理アプリケーション１１０Ａ、暗証コード認証手段１２０Ａを備えた構成となっている。

　先に、暗証コード認証手段１２０Ａについて説明する。
　金融取引制御システム１００Ａは、暗証コード認証手段１２０Ａを含んでおり、利用者端末２００Ａにも暗証コード入力手段２３０が含まれており、暗証コード認証手段１２０Ａが、利用者が暗証コード入力手段２３０を介して入力されて送信された暗証コードと、決済管理システム５００Ａ上で登録されている暗証コード情報との認証処理を行い、認証処理に成功したことを条件として金融取引処理アプリケーション１１０Ａの所定の処理を実行する取り扱いとする。

　実施例１では、利用者アプリケーション２１０Ａより“金融取引処理リクエスト情報”の送信に加え、“承認情報”の送信が求められる。前者は金融取引処理アプリケーションファイルのオープン処理に対応し、後者は金融取引処理アプリケーションファイルのクローズ処理に対応するものである。

　暗証コード認証手段１２０Ａは利用者端末２００Ａから送信されてくる金融取引処理のリクエスト情報や承認情報に含まれる暗証コードを抽出し、真正の利用者により決済管理システム５００Ａ上で事前に登録されている暗証コードデータにアクセスし、暗証コードが正しいものか否かをチェックすることにより利用者を認証する。

　次に、金融取引処理アプリケーション１１０Ａを説明する。
　金融取引処理アプリケーション１１０Ａは、金融取引制御システム１００ＡにインストールまたはＡＳＰで利用可能となっているアプリケーションであり、金融取引処理アプリケーション１１０Ａは常駐型でも良く、利用者端末２００Ａから送信されてくる金融取引処理のリクエスト情報に応じて立ち上げられるものであっても良い。ここでは常駐型とする。
　金融取引処理アプリケーション１１０Ａは、利用者ごとまたは金融取引ごとに用意される利用者アプリケーションファイル１１２Ａを備えた構成となっている。
　金融取引処理アプリケーション１１０Ａによってクレジット利用/デビット利用時にオンデマンドによる金融取引処理アプリケーションファイル１１２Ａのオープン処理、金融取引処理アプリケーションファイル１１２Ａを決済処理部５３０に引き渡すデータ引き渡し処理、金融取引処理アプリケーションファイル１１２Ａのクローズ処理を実行する。

　金融取引処理アプリケーションファイル１１２Ａは、金融取引処理アプリケーション１１０Ａにより処理される利用者ごとまたは金融取引ごとに用意されるアプリケーションファイルである。金融取引処理アプリケーション１１０Ａは金融取引処理アプリケーションファイル１１２Ａを用いて以下の処理を実行する。
　(1)利用者ごとまたは金融取引ごとに金融取引処理アプリケーションファイル１１２Ａをオンデマンドでオープンする「オープン処理」、(2)金融取引処理アプリケーションファイル１１２Ａのデータを編集する「編集処理」、(3)利用者による「承認確認」の伺い処理および受付処理、(4)金融取引処理の決済管理システム５００Ａへの引き継ぎ処理、(5)金融取引処理アプリケーションファイル１１２Ａのクローズ処理の各処理である。

　（１）金融取引処理アプリケーションファイル１１２Ａのオープン処理
　まず、金融取引処理アプリケーションファイル１１２Ａのオープン処理について説明する。“金融取引処理アプリケーションファイル１１２Ａのオープン処理”は金融取引処理の開始に応じてオンデマンドで実行される。ここでは、利用者アプリケーション２１０Ａからの利用者によるクレジット利用開始などのリクエストがあれば、金融取引処理アプリケーション１１０Ａは当該利用者のアカウントに対応する金融取引処理アプリケーションファイル１１２Ａを立ち上げる“金融取引処理アプリケーションファイルオープン処理”を実行する。

　（２）金融取引処理アプリケーションファイル１１２Ａのデータ編集処理
　金融取引処理アプリケーションファイル１１２Ａは利用者ＩＤごとに管理されており、オープンされるとデータの書き込みなどの編集が可能となる。ここでは、店舗端末/ＥＣサイト４００の金融取引情報生成手段４２０にて生成された金融取引情報が決済管理システム５００Ａに送信されてくると、決済処理部５３０は、金融取引処理アプリケーション１１０Ａに金融取引情報を引き渡す。金融取引処理アプリケーション１１０Ａは、利用者ＩＤ情報に対応する金融取引処理アプリケーションファイル１１２Ａに対して金融取引情報のデータを書き込むことで第三者（ここでは店舗端末/ＥＣサイト４００）による編集を一旦受け入れる扱いとする。

　（３）利用者に対する承認伺い処理および確認処理
　利用者に対する承認確認処理として、まず、利用者端末２００Ａに対して金融取引の受け付けを承認して金融取引を正常終了させる承認終了処理を実行しても良いかを問う“承認リクエスト”を送信し、“承認リクエスト”に対する利用者端末２００Ａからの承認情報の返信を待つ承認確認の伺い処理を行う。
　ここでは、この“承認リクエスト”には“クローズ暗証コード”の入力要求が設定されているものとする。つまり、金融取引処理アプリケーションファイル１１２Ａに正常にクローズさせるためクローズ用の暗証コードが設定されており、利用者に対して、このクローズ用の暗証コードを入力させる。
　この例では、承認用の“クローズ暗証コード”として利用者の生体情報が登録されているものとする。

　次に、利用者端末２００Ａからの“承認情報”の返信を受けて“承認情報”を確認する“承認確認処理”を行う。
　ここでは、この承認情報には利用者が入力した“クローズ暗証コード”が含まれているので、暗証コード認証手段１２０Ａを介して承認情報に含まれている“クローズ暗証コード”の認証が行われる。この例では利用者の生体情報がクローズ暗証コードである。
　このように、金融取引処理アプリケーションファイル１１２Ａを編集後にファイルを正常にクローズさせるためにクローズ用の暗証コードが設定されており、さらに高いセキュリティレベルが設けられている。

　（４）金融取引処理の決済管理システム５００Ａへの引き継ぎ処理
　金融取引処理アプリケーション１１０Ａは、“金融取引情報データ引き渡し処理”として、金融取引処理アプリケーションファイル１１２Ａに記録された金融取引情報のデータ内容を決済管理システム５３０へ引き渡す。
　なお、決済管理システム５３０は金融取引情報の引き渡しを受け、その後は通常の決済処理（利用可否ステイタス情報の有効状態の確認、金融決済処理など）が行われる。

　（５）金融取引処理アプリケーションファイル１１２Ａのクローズ処理
　最後に、金融取引処理アプリケーション１１０によって金融取引処理アプリケーションファイル１１２をクローズする“金融取引処理アプリケーションファイル終了処理”が実行される。
　ここでは、上記した（３）利用者に対する承認確認処理から（５）金融取引処理アプリケーションファイル１１２Ａのクローズ処理まで、利用者から送信された“承認情報”に含まれるクローズ用の暗証コードが認証されれば、一気に連続処理し、金融取引処理アプリケーションファイルの終了処理まで実行する運用となっている。

　次に、フローチャートおよび図面を参照しつつ、実施例１にかかる金融取引制御システム１００の処理の流れの概略を示す。
　ここでは、利用者媒体３００は、ＩＣカード型のクレジットカード３００とする。利用者が店舗に行って商品を購入してクレジット利用により金融取引決済を行うシーンを前提として説明する。なお、利用者がＥＣサイトにログインして商品を購入してクレジット利用やデビット利用による金融取引決済を行うシーンとしても同様に考えることができる。

　以下、一連のクレジット利用、デビット利用の手続の流れを図２～図５のシステムブロック図、図７および図８の金融取引制御システム１００Ａの利用者端末２００Ａでの操作画面の例を示す図を参照しつつ説明する。

　まず、利用者は、商品を選定し、クレジット利用の決済に先立ち、スマートフォン２００Ａを操作して利用者アプリケーション２１０Ａを立ち上げる（図２ステップＳ１）、例えば、利用者端末２００Ａのディスプレイ上に表示されている利用者アプリケーション２１０Ａのアイコンをタップする（図７（１））。なお、この段階で、利用者アプリケーション２１０Ａの使用権限を確認するため、パスワードを入力する運用も可能である。利用者端末２００Ａ上に利用者アプリケーション２１０Ａが立ち上がり、サービスメニューが示される（図７（２））。この例では“クレジットを利用する”、“デビットを利用する”という２つのメニューが表示されている。

　このクレジット利用開始ボタン押下（図７（３））により利用者アプリケーション２１０Ａは、利用者に対してオープン暗証コードの入力を要求するガイダンスを表示して入力を要求し（図７（４））、利用者から暗証コード入力手段２３０を介して入力された“オープン暗証コード”を得る（図２ステップＳ２）。ここでは生体情報として指紋情報が入力される（図７（５））。

　利用者アプリケーション２１０Ａは“金融取引処理リクエスト情報”を生成し（図２ステップＳ３）、利用者アプリケーション２１０Ａは、通信手段２４０を介して“金融取引処理リクエスト情報”と指紋情報である“オープン暗証コード”を金融取引制御システム１００Ａに送信する（図２ステップＳ４）。なお、実施例２では“金融取引処理リクエスト情報”が送信されたが、ここでは、“金融取引処理リクエスト情報”と“オープン暗証コード”が送信される。

　金融取引制御システム１００Ａは、送信されてきた“金融取引利用リクエスト情報”を受け付けると、“オープン暗証コード”を抽出し、暗証コード認証手段１２０Ａに入力し、オープン暗証コードの認証処理を実行させる（図２ステップＳ５）。暗証コード認証手段１２０Ａは、利用者アプリケーション２１０Ａから送信されてきた“オープン暗証コード情報”と、決済管理システム５００Ａ上で登録されている“オープン暗証コード情報”との認証処理を行い、認証処理に成功した場合は、金融取引処理アプリケーション１１０Ａに認証成功を通知し、金融取引処理アプリケーション１１０Ａは、該当する利用者ＩＤ情報に関連付けられた金融取引処理アプリケーションファイル１１２Ａのオープン処理を実行する（図２ステップＳ６）。
　なお、認証処理に失敗した場合は（図２ステップＳ５：Ｎ、図中には図示せず）、金融取引処理アプリケーション１１０Ａに認証不成立を通知し、金融取引処理を打ち切る。

　金融取引制御システム１００Ａ側において金融取引処理アプリケーションファイル１１２Ａのオープン処理が完了すれば、“金融取引利用開始ＯＫ”を示す情報を生成し（図１０ステップＳ６）、通信手段５４０を介して利用者端末２００Ａに返信され（図２ステップＳ７）、利用者端末２００Ａ上において“クレジット利用できます”という表示がなされ（図７（６））、クレジット利用を開始する（図２ステップＳ８）。

　次に、店舗やＥＣサイトでの利用に移る。
　利用者は、上記のように、利用者端末２００Ａにおいて、“クレジット利用できます。”という表示があれば、クレジット利用を開始する。
　利用者が店舗などで商品購入時にクレジットカード３００を提示し、店舗会計スタッフが、カードのタイプに応じて磁気ストライプリーダ、ＩＣカードリーダなどの利用者情報入力手段４１０から利用者ＩＤ情報を入力し（図３ステップＳ９）、店舗端末/ＥＣサイト４００の金融取引情報生成手段４２０を介してクレジットカードから利用者ＩＤ情報などクレジット利用に必要な諸情報および決済代金情報などを入力し、それら情報を基に金融取引情報を生成し（図３ステップＳ１０）、店舗端末/ＥＣサイト４００の通信手段４３０を介してそれら金融取引情報が決済管理システム５００Ａに送信する（図３ステップＳ１１）。
　なお、ＥＣサイトの利用の場合、決済用の入力画面を表示してクレジットカード番号や有効期限や暗証番号などの諸情報を入力すれば、ＥＣサイトにおいて金融取引情報が生成され、店舗端末/ＥＣサイト４００の通信手段４３０を介してそれら金融取引情報が決済管理システム５００Ａに送信される。

　本実施例１では、この段階ではまだ決済管理システム５００Ａは通常のクレジット処理を行わない。まず、決済処理部５３０は、金融取引情報を金融取引処理アプリケーション１１０Ａに渡す（図３ステップＳ１２）。
　なお、後述するように、決済処理部５３０は、金融取引処理アプリケーション１１０Ａから決済処理開始ＯＫの旨の情報を受け取った後は、通常の決済処理を実行する。

　金融取引処理アプリケーション１１０Ａは、受け取った金融取引情報の中から利用者ＩＤ情報を抽出して、オープン処理されている金融取引処理アプリケーションファイル１１２Ａと関連付けられている利用者ＩＤ情報か否かをチェックする（図３ステップＳ１３）。

　オープン処理されている金融取引処理アプリケーションファイル１１２Ａがある利用者ＩＤ情報である場合は（図３ステップＳ１３：Ｙ）、本発明の金融取引制御システム１００Ａの利用者であり、クレジット利用の金融取引処理中を意味するので、受け取った金融取引情報を該当する金融取引処理アプリケーションファイル１１２Ａに書き込む（図３ステップＳ１４）。

　次に、金融取引処理アプリケーションファイル１１２Ａの承認処理に進む。
　金融取引制御システム１００Ａは“承認伺い処理”を実行する。
　金融取引制御システム１００Ａは、利用者アプリケーション２１０Ａに対して金融取引を承認して金融取引を正常終了させる承認終了処理を実行しても良いかを問う“承認リクエスト”を送信し（図４ステップＳ１５）、“承認リクエスト”に対する利用者アプリケーション２１０Ａからの“承認情報”の返信を待つ。
　なお、この“承認伺い処理”は、金融取引制御システム１００Ａが自律的に利用者アプリケーション２１０Ａに対して送信して“承認情報”の入力を待つ形でも良いし、利用者アプリケーション２１０Ａ側が金融取引制御システム１００Ａに自発的にアクセスして“承認情報”の入力を行う形であっても良い。

　利用者端末２００Ａは、“承認リクエスト”を受信すると、ディスプレイ上に「ご利用の取引内容をご確認ください」というメッセージと、商品購入代金、クレジット支払回数などのクレジット利用内容を表示し、“承認ボタン”を表示して押下を促す（図８（１））。この例では“承認する”というボタンと“承認しない”というボタンが表示される。
　利用者が“承認ボタン”を押下すると（図４ステップＳ１６、図８（２））、利用者アプリケーション２１０Ａは、利用者に対してクローズ暗証コードの入力を要求するガイダンスを表示し（図８（３））、利用者から暗証コード入力手段２３０を介して入力された“クローズ暗証コード”を得る（図４ステップＳ１７）。ここでは生体情報として指紋情報が入力されるものとする（図８（４））。
　なお、“承認しない”ボタンを押下した場合の運用は限定されないが、例えば、利用者アプリケーション２１０Ａはこの金融取引が利用者による正当な取引ではないとして（例えば、不正使用者による不正取引とみなして）、決済処理部５３０には決済処理ＮＧの旨を通知し、金融取引処理を強制終了する。

　金融取引制御システム１００Ａは、利用者端末２００Ａからの“承認情報”の返信（図４ステップＳ１８）を受けて“承認確認処理”を実行する。ここでは、この承認情報には“クローズ暗証コード”が設定されているので、“クローズ暗証コード”を抽出し、暗証コード認証手段１２０Ａに入力し、クローズ暗証コードの認証処理を実行させる（図４ステップＳ１９）。
　暗証コード認証手段１２０Ａは、利用者アプリケーション２１０Ａから送信されてきた“クローズ暗証コード情報”と、決済管理システム５００Ａ上で登録されている“クローズ暗証コード情報”との認証処理を行う。
　認証処理に成功した場合は（図４ステップＳ１９：Ｙ）、金融取引処理アプリケーション１１０Ａに認証成功を通知（図４ステップＳ２０）する。金融取引処理アプリケーション１１０Ａは決済処理ＯＫの旨の情報とともに金融取引情報のデータ内容を決済管理システム５３０Ａへ引き渡す（図５ステップＳ２１）。
　なお、認証処理に失敗した場合は（図中には図示せず）、金融取引処理アプリケーション１１０Ａに認証不成立を通知する。金融取引処理アプリケーション１１０Ａは決済処理ＮＧの旨の情報を決済管理システム５３０へ引き渡す（図中には図示せず）。

　承認確認処理で“承認情報”が確認されたこと、つまり、クローズ用の暗証コードの入力を条件として、金融取引処理アプリケーション１１０Ａは決済処理ＯＫの旨の情報とともに、金融取引処理アプリケーションファイル１１２Ａの金融取引情報のデータ内容を決済管理システム５３０へ引き渡す（図５ステップＳ２１）。

　決済管理システム５３０は金融取引情報の引き渡しを受け、その後は通常の決済処理を開始する。
　与信管理部５２０が与信に基づいた場合の利用可否ステイタス情報５１０の設定が“有効状態”つまり“無効状態の設定ではない”か否かをチェックし（図５ステップＳ２２）、与信管理部５２０の与信情報に基づく設定が“無効状態の設定ではない”場合には、決済処理部５３０に与信情報が有効である旨を通知し（図５ステップＳ２３）、金融取引情報から利用者ＩＤ情報などクレジット利用に必要な諸情報および決済代金情報を抽出し、クレジット決済処理が実行され（図５ステップＳ２４）、店舗端末/ＥＣサイト４００にクレジット利用が成立した旨を示す情報が返信される（図５ステップＳ２５）。
　もし、与信情報に基づく与信管理部５２０による利用可否ステイタス情報５１０の設定が“無効状態”を示す設定の場合は（図中には図示せず）、金融取引処理アプリケーション１１０Ａは、利用者端末２００Ａから送信された承認終了処理にかかわらず、金融取引処理アプリケーション１１０Ａは決済処理ＮＧの旨の情報を決済管理システム５３０へ引き渡す。結局クレジット処理が不成立となる。
決済処理部５３０から店舗端末/ＥＣサイト４００にクレジット利用が不成立である旨を示す情報が返信される（図中には図示せず）。

　金融取引処理アプリケーション１１０Ａは、“金融取引処理アプリケーションファイル終了処理”を実行し、金融取引処理アプリケーションファイル１１２Ａをクローズする（図６ステップＳ２６）。
　利用者アプリケーション２１０Ａには、クレジット処理が完了した旨が表示され（図８（５））、必要に応じて、利用者アプリケーション２１０Ａを終了し（図８（６））、利用者アプリケーション２１０Ａが閉じられる（図８（７））。さらに、利用者アプリケーション２１０Ａのアイコン選択を解除する（図８（８））。
　なお、上記したステップＳ１３において、オープン処理されている金融取引処理アプリケーションファイル１１２Ａがある利用者ＩＤ情報ではない場合は（図中には図示せず）、本発明の金融取引制御システム１００Ａの利用者とは異なる他者の利用（つまり、本発明の利用者ではない一般の利用者）であるため、決済処理部５３０に対して、決済処理開始ＯＫの情報とともに金融取引情報を返し、決済処理部５３０Ａは、金融取引情報を基に、通常の決済処理を開始する。

　実施例２として、利用者ＩＤ保持媒体３００を不要とし、スマートフォン２００などに金融取引処理に必要な利用者ＩＤ情報などが電子化されたいわゆる電子クレジット金融取引処理や電子デビット金融取引処理を行う例を示す。
　なお、以下、一例として、利用者端末２００Ｂの電子決済アプリケーション２６０Ｂおよび利用者媒体アカウント情報２７０Ｂと、決済処理部５３０の利用者媒体アカウント情報５６０Ｂを用いた電子決済の例を説明するが、本発明は、このような電子決済に用いる利用者端末２００Ｂの電子決済アプリケーション２６０Ｂおよび利用者媒体アカウント情報２７０Ｂや、決済処理部５３０の利用者媒体アカウント情報５６０Ｂ自体には限定されずそれらが何であっても良く、利用者端末２００Ｂの利用者アプリケーション２１０Ｂと金融取引制御システム１００Ｂの金融取引処理アプリケーション１１０Ｂおよび金融取引処理アプリケーションファイル１１２Ｂの働きにより不正使用防止の用に供するものである。

　実施例２にかかる金融取引制御システム１００Ｂの構成は、少なくとも金融取引処理アプリケーション１１０Ｂ、暗証コード認証手段１２０Ｂを備えており、実施例１で示した図１の構成と同様であるのでここでは説明を省略する。

　実施例２にかかる利用者端末２００Ｂは、少なくとも利用者アプリケーション２１０Ｂ、データ入力手段２２０、暗証コード入力手段２３０、通信手段２４０に加え、カメラ２５０Ｂ、電子決済アプリケーション２６０Ｂ、利用者媒体アカウント情報２７０Ｂを備えている。
　利用者アプリケーション２１０Ｂは、実施例１と同様、金融取引制御システム１００Ｂとの間でやり取りし、実施例１で示した（１）金融取引処理アプリケーションファイル１１２Ａのオープン処理、（３）利用者に対する承認伺い処理および確認処理を行う機能を備えている。
　データ入力手段２２０、暗証コード入力手段２３０、通信手段２４０は、実施例１に示したものと同様で良く、ここでの詳しい説明は省略する。

　電子決済アプリケーション２６０Ｂは、電子クレジット決済や電子デビット決済のために使用するアプリケーションである。利用者端末２００Ｂを用いて金融機関などが提供する多様な電子決済を行うためのアプリケーションである。近年、同様の電子決済アプリケーションが提供されているが、本発明では、電子決済アプリケーション２６０Ｂとして、普及しつつある公知のアプリケーションを含めることができる。例えば、アップルペイ（ＴＭ）、アマゾンペイ（ＴＭ）など多様なものが提供され始めている。

　利用者媒体アカウント情報２７０Ｂは、電子決済アプリケーション２６０Ｂにおいて利用される利用者媒体のアカウント情報である。名称は、利用する電子決済アプリケーション２６０Ｂにおいて異なる場合があるが、それら電子決済アプリケーション２６０Ｂにおいて、従来の利用者ＩＤ情報の保持においてカード媒体を必要としたものが電子化された情報として保持されるものである。

　カメラ２５０Ｂは、スマートフォンなどの利用者端末が装備しているカメラでも良い。例えば、クレジットカード媒体をカメラ２５０Ｂで撮影して画像認識することにより、保持されている利用者ＩＤ情報を利用者媒体アカウント情報２７０Ｂとして電子決済アプリケーション２６０Ｂに登録する際に使用する。セキュリティコードなどは手入力する場合もある。

　なお、利用する電子決済アプリケーション２６０Ｂにおいて、利用者媒体アカウント情報２７０Ｂの登録手順や、登録に要する本人認証のやり方などは異なることはあり得るが、本発明では、電子決済アプリケーション２６０Ｂおよび利用者媒体アカウント情報２７０Ｂの登録や利用手順などには限定されず、各種の電子決済アプリケーション２６０Ｂおよび利用者媒体アカウント情報２７０Ｂが正常に登録されているものとする。

　次に、実施例２にかかる決済管理システム５００Ｂについて説明する。
　決済管理システム５００Ｂは、実施例１と同様、金融機関や信販会社などが管理運営しているシステムであり、金融取引制御システム１００Ｂとのデータのやり取りができ、さらに、オンライン上で店舗端末/ＥＣサイト４００や利用者端末２００Ｂとデータ通信可能となっている。この例では、金融取引制御システム１００Ｂは、決済管理システム５００Ｂに含まれている例であるが、別のコンピュータリソースにインストールされている構成も可能であることは言うまでもない。

　決済管理システム５００Ｂは、実施例１と同様、利用可否ステイタス情報５１０、与信管理部５２０、決済処理部５３０、通信手段５４０を備え、本実施例２では、さらに利用者媒体アカウント情報５６０Ｂを備えている。
　利用者媒体アカウント情報５６０Ｂは、利用者端末２００Ｂ上で作成された利用者媒体アカウント情報２７０Ｂに対応するものであり、電子決済アプリケーション２６０Ｂと決済処理部５３０とのやり取りにおいて利用される利用者媒体のアカウント情報である。この利用者媒体アカウント情報５６０Ｂと利用者媒体アカウント情報２７０Ｂとの連動によって、電子クレジット処理、電子デビット処理などが進められる。

　次に、フローチャートおよび図面を参照しつつ、実施例２にかかる金融取引制御システム１００Ｂの処理の流れの概略を示す。なお、実施例１に示した金融取引制御システム１００Ａの処理の流れの概略と同様の部分については詳しい説明は省略することとする。

　図１０に示した流れは実施例の図２に示した流れと同様で良い。つまり、クレジット利用の決済に先立つ利用者アプリケーション２１０Ｂの立ち上げ処理（図１０ステップＳ３１）、暗証コード入力手段２３０を介した“オープン暗証コード”の入力処理（図１０ステップＳ３２）、利用者アプリケーション２１０Ｂを用いた“金融取引処理リクエスト情報”の生成処理（図１０ステップＳ３３）、利用者アプリケーション２１０Ｂによる“金融取引処理リクエスト情報”と“オープン暗証コード”の金融取引制御システム１００Ｂへの送信処理（図１０ステップＳ３４）、暗証コード認証手段１２０Ｂによるオープン暗証コードの認証処理（図１０ステップＳ３５）、利用者アプリケーション２１０Ｂによる金融取引処理アプリケーションファイルのオープン処理（図１０ステップＳ３６）、金融取引処理開始の準備完了の旨の利用者端末２００Ｂへの返信処理（図１０ステップＳ３７）、クレジット利用開始ＯＫの表示処理（図１０ステップＳ３８）までは実施例１の図２のステップＳ１からＳ８までと同様で良い。

　次に、店舗やＥＣサイトでの金融取引利用に移る。
　本実施例２では、利用者端末２００Ｂにインストールされている電子決済アプリケーション２６０Ｂが利用される。
　利用者は電子決済アプリケーション２６０Ｂを用いて、店舗やＥＣサイトで電子クレジット決済利用などを通じて商品購入などの金融取引処理を開始する。電子クレジット決済利用の手順などは、利用する電子決済アプリケーション２６０Ｂの手順に従って行うものとする。
　ここでは、電子決済アプリケーション２６０Ｂから利用者媒体アカウント情報２７０Ｂが、店舗やＥＣサイトでの電子決済の仕組みに応じて取り込まれる（図１１ステップＳ３９）。ここでは、利用者媒体情報入力手段４１０を通じて利用者媒体アカウント情報２７０Ｂが取り込まれる。

　次に、店舗端末/ＥＣサイト４００の金融取引情報生成手段４２０を介してクレジット利用に必要な諸情報および決済代金情報などを入力し、それら情報を基に金融取引情報を生成し（図１１ステップＳ４０）、店舗端末/ＥＣサイト４００の通信手段４３０を介してそれら金融取引情報が決済管理システム５００Ｂに送信される（図１１ステップＳ４１）。

　ここでは、金融取引情報は決済処理部５３０の利用者媒体アカウント情報５６０Ｂに渡され、利用者媒体アカウント情報２７０Ｂと利用者媒体アカウント情報５６０Ｂが対応し合うものであるか確認されるものとする。確認されなければ、電子決済運用主体により電子決済ができない扱いとなる。ここでは確認されたものとする。
　この段階ではまだ決済管理システム５００Ｂは通常のクレジット処理を行わない。まず、決済処理部５３０は、金融取引情報を金融取引処理アプリケーション１１０Ｂに渡す（図１１ステップＳ４２）。

　金融取引処理アプリケーション１１０Ｂは、受け取った金融取引情報の中から利用者ＩＤ情報を抽出して、オープン処理されている金融取引処理アプリケーションファイル１１２Ｂと関連付けられている利用者ＩＤ情報か否かをチェックする（図１１ステップＳ４３）。

　オープン処理されている金融取引処理アプリケーションファイル１１２Ｂがある利用者ＩＤ情報である場合は（図１１ステップＳ４３：Ｙ）、本発明の金融取引制御システム１００Ｂの利用者であり、クレジット利用の金融取引処理中を意味するので、受け取った金融取引情報を該当する金融取引処理アプリケーションファイル１１２Ｂに書き込む（図１１ステップＳ４４）。

　次に、金融取引処理アプリケーションファイル１１２Ｂの承認処理に進む。
　金融取引制御システム１００Ｂは“承認伺い処理”および“承認処理”を実行する。
　図１２に示す“承認リクエスト”の送信処理（図１２ステップＳ４５）、　利用者による“承認ボタン”処理（図１２ステップＳ４６、図１６（１）（２））、利用者に対するクローズ暗証コードの入力処理（図１２ステップＳ４７、図１６（３）（４））、利用者端末２００Ｂからの“承認情報”の返信処理（図１２ステップＳ４８）、金融取引制御システム１００Ｂにおけるクローズ暗証コードの認証処理（図１２ステップＳ４９）は、実施例１の図４で示したステップＳ４５からステップＳ４９までと同様で良い。

　承認確認処理で“承認情報”が確認されたこと、つまり、クローズ用の暗証コードの入力を条件として、金融取引処理アプリケーション１１０Ｂは決済処理ＯＫの旨の情報とともに、金融取引処理アプリケーションファイル１１２Ｂの金融取引情報のデータ内容を決済管理システム５３０へ引き渡す（図１３ステップＳ５０）。
　この例では図１６（１）に示すように、“承認する”というボタンと“承認しない”というボタンが表示されるが、“承認しない”ボタンを押下した場合の運用は限定されないが、例えば、実施例１と同様、利用者アプリケーション２１０Ｂはこの金融取引が利用者による正当な取引ではないとして（例えば、不正使用者による不正取引とみなして）、決済処理部５３０Ｂには決済処理ＮＧの旨を通知し、金融取引処理を強制終了する。

　決済処理部５３０Ｂの利用者媒体アカウント情報５６０Ｂは、金融取引情報の引き渡しを受け、その後は所定の決済処理を開始する。
　与信管理部５２０の利用可否ステイタス情報５１０の設定の確認処理（図１３ステップＳ５２）、（図１３ステップＳ５３）、決済処理部５３０Ｂによる金融取引情報を基にしたクレジット決済処理の実行（図１３ステップＳ５４）、店舗端末/ＥＣサイト４００にクレジット利用が成立した旨を示す情報の返信（図１３ステップＳ５５）が実行される。

　最後に、金融取引処理アプリケーション１１０Ｂは、“金融取引処理アプリケーションファイル終了処理”を実行し、金融取引処理アプリケーションファイル１１２Ｂをクローズする（図１４ステップＳ５６）。
　利用者アプリケーション２１０Ｂには、クレジット処理が完了した旨が表示され（図１６（５））、必要に応じて、利用者アプリケーション２１０Ｂを終了し（図１６（６））、利用者アプリケーション２１０Ｂが閉じられる（図１６（７））。さらに、利用者アプリケーション２１０Ｂのアイコン選択を解除する（図１６（８））。

　このように、本実施例２の金融取引制御システム１００Ｂの場合、カード媒体を伴わない電子クレジット利用や電子デビット利用のシステム構成においても、金融取引制御システム１００Ｂ，金融取引処理アプリケーション１１０Ｂ，金融取引処理アプリケーションファイル１１２Ｂ、暗証コード認証手段１２０Ｂを用いて、金融取引処理に対する、ファイルオープン用の暗証コード、ファイルクローズ用の暗証コードを用いた認証処理を取り入れることができ、高いセキュリティレベルを獲得することができる。従来技術には、本願発明のように、利用者ごとのアプリケーションファイルを用いて、アプリケーションファイルを開く処理と、閉じる処理の２回にわたって暗証コードを要求する電子決済システムはない。高いセキュリティ処理の確実な実行が担保される。
　なお、上記したステップＳ４３において、オープン処理されている金融取引処理アプリケーションファイル１１２Ｂがある利用者ＩＤ情報ではない場合は（図中には図示せず）、本発明の金融取引制御システム１００Ｂの利用者とは異なる他者の利用（つまり、本発明の利用者ではない一般の利用者）であるため、決済処理部５３０に対して、決済処理開始ＯＫの情報とともに金融取引情報を返し、決済処理部５３０は、金融取引情報を基に、通常の決済処理を開始する。

　実施例３として、利用可否ステイタス情報、利用可否ステイタス情報状態制御手段を備え、通常時に無効デフォルト処理を行ってセキュリティレベルを向上させた例を示す。ここでは、実施例２と同様、利用者ＩＤ保持媒体３００を不要とした、いわゆる電子クレジット金融取引処理や電子デビット金融取引処理を行う例として示す。

　図１７は実施例３にかかる金融取引制御システム１００Ｃの構成例を示す図である。図１７に示すように、実施例３にかかる金融取引制御システム１００Ｃは少なくとも金融取引処理アプリケーション１１０Ｃ、暗証コード認証手段１２０Ｃを備えている。
　ここで、本実施例３では、金融取引処理アプリケーション１１０Ｃが、利用可否ステイタス情報状態制御手段１１１Ｃと、利用者ごとまたは金融取引ごとに用意される利用者アプリケーションファイル１１２Ｃを備えた構成となっている。

　利用可否ステイタス情報状態制御手段１１１Ｃは、金融取引処理アプリケーション１１０Ｃが利用者端末２００Ｃの利用者アプリケーション２１０Ｃから受け取った金融取引情報のリクエストに基づいて、決済管理システム５００Ｃで管理されている利用可否ステイタス情報５１０Ｃの有効／無効の状態の切り替えを制御する手段である。

　ここで、利用可否ステイタス情報５１０Ｃとは、決済管理システム５００Ｃ上で管理される利用者のアカウントの有効無効状態、または、利用者のアカウントに対する金融取引受け入れの有効無効状態を示す情報である。
　利用可否ステイタス情報５１０Ｃは、与信管理部５２０により管理されており、この利用可否ステイタス情報５１０Ｃが有効状態を示す場合、決済管理システム５００Ｃは、当該利用者によるクレジット利用またはデビット利用を伴う金融取引を受け入れる取り扱いとなっている。逆に、この利用可否ステイタス情報５１０Ｃが無効状態を示す場合、決済管理システム５００Ｃは、当該利用者によるクレジット利用またはデビット利用を伴う金融取引を拒否する取り扱いとなっている。
　本来は、与信に問題がないクレジット利用者、デビット利用者の利用可否ステイタス情報５１０Ｃは有効状態に維持するが、本発明では、金融取引制御システム１００Ｃの利用可否ステイタス情報状態制御手段１１１Ｃにより、利用可否ステイタス情報５１０Ｃの状態制御がなされる仕組みとなっている。

　利用可否ステイタス情報状態制御手段１１１Ｃは、「無効デフォルト処理」と「ステイタス情報切り替え処理」を備えている。
　「無効デフォルト処理」は、利用可否ステイタス情報状態制御手段１１１Ｃが決済管理システム５００Ｃの利用可否ステイタス情報５１０Ｃの状態をデフォルト（通常時状態）として無効状態にするものであり、この無効デフォルト処理により、利用可否ステイタス情報５１０Ｃの状態がデフォルト設定として“無効状態”に制御される。

　「ステイタス情報切り替え処理」は、利用者が保持する利用者端末２００Ｃの利用者アプリケーション２１０Ｃから送信される金融取引のリクエスト情報や承認情報を受けて、利用可否ステイタス情報５１０Ｃの無効状態/有効状態をオンデマンドで切り替える処理である。つまり、金融取引処理アプリケーション１１０Ｃは、利用可否ステイタス情報状態制御手段１１１Ｃの「ステイタス情報切り替え処理」によって、利用可否ステイタス情報５１０Ｃのデフォルト設定である無効状態をオンデマンドで一時的に有効状態に切り替えたり、一時的に有効状態になったものを「無効デフォルト処理」によってデフォルト設定である無効状態に切り戻したりすることができる。

　従来技術では、一般的にはこの利用可否ステイタス情報５１０Ｃは有効状態であることが通常状態であり、無効状態である場合は何らかの異常状態や事故状態に陥っているものであった。例えば、クレジットカードやデビッドカードなどが盗難や紛失したため利用者から金融機関や信販会社の決済センターに対して、それらカード類を使用できないように使用停止の要求が出されている場合や、利用者のクレジット利用やデビッド利用を伴う過去の金融取引の口座引き落としが不能で当該利用者の与信がなくなった場合など何らかの異常状態に陥っている場合が想定されている。
　しかし、本発明では、金融取引制御システム１００Ｃは、金融取引処理アプリケーション１１０Ｃを装備し、利用可否ステイタス情報状態制御手段１１１Ｃにより、決済管理システム５００Ｃ上で管理されている利用可否ステイタス情報５１０Ｃの有効無効状態を利用者の金融取引処理の間だけ細かく切り替え制御を認めることで、クレジット利用またはデビット利用を伴う金融取引のセキュリティを向上せしめるものである。

　従来の決済管理システム５００Ｃの管理では、利用可否ステイタス情報５１０Ｃは通常時（デフォルト設定時）は“有効状態”が維持され、何らかの不都合が発生した場合にのみ例外的に“無効状態”に切り替えられるものであった。
　しかし、本発明では、従来とは発想を逆転させ、利用可否ステイタス情報状態制御手段１１１Ｃは、利用可否ステイタス情報５１０Ｃのデフォルト設定を“無効状態”として制御する「無効デフォルト処理」を行う。つまり、利用可否ステイタス情報５１０Ｃは通常時（デフォルト設定時）は、利用可否ステイタス情報状態制御手段１１１Ｃにより“無効状態”に維持される。これにより、利用者が気付かないうちに第三者が不正使用を試みようとしてもクレジット利用やデビット利用ができず高いセキュリティが維持できる。

　金融取引処理アプリケーション１１０Ｃは金融取引処理の開始の際に利用者アプリケーション２１０Ｃから金融取引処理のリクエストを受け、金融取引処理の実行に伴い、一時的に利用可否ステイタス情報５１０Ｃを有効状態に切り替え、金融取引処理が完了すれば、自動的に通常時無効状態に戻すものである。

　次に、利用者の与信情報に基づく決済管理システム側による無効設定との優劣について述べる。
　上記のように、金融取引制御システム１００Ｃの利用可否ステイタス情報状態制御手段１１１Ｃは、決済管理システム５００Ｃの利用可否ステイタス情報５１０Ｃの有効／無効の状態の切り替えを制御する機能を備えているが、利用者の与信情報に基づく決済管理システム側による無効設定は書き換え不可とすることが好ましい。与信情報に基づく無効設定は、利用者自身の支払い能力欠如が判明した状況や、利用者に与えられた決済の信用枠を超える取引がなされようとしている状況に基づいて、それ以上の金融取引の成立を阻止するための決済管理システム側からのいわば強制的措置であるので、この措置を利用者が自由に切り替えられる機能まで付与することは明らかに行き過ぎである。
　そこで、決済管理システム５００Ｃは、与信に基づく利用可否ステイタス情報５１０Ｃの無効設定を優先するという原則で制御を実行する。

　つまり、決済管理システム５００Ｃ上の与信管理部５２０が管理する与信情報に基づいて設定される利用可否ステイタス情報５１０Ｃの設定が“有効状態”を示す設定の場合には、決済管理システム５００Ｃは、利用可否ステイタス情報状態制御手段１１１Ｃによる利用可否ステイタス情報５１０Ｃの切り替え制御を優先させて利用可否ステイタス情報５１０Ｃの切り替えを受け入れる。一方、利用可否ステイタス情報５１０Ｃの設定が“無効状態”を示す設定の場合、決済管理システム５００Ｃが、当該“無効設定”を優先し、利用可否ステイタス情報状態制御手段１１１Ｃによる利用可否ステイタス情報５１０Ｃによる切り替え制御（つまり、有効状態への切り替え処理）を受け入れず、利用可否ステイタス情報５１０Ｃの“無効状態”を維持する取り扱いとする。

　次に、金融取引処理アプリケーションファイル１１２Ｃを説明する。
　金融取引処理アプリケーションファイル１１２Ｃは、金融取引処理アプリケーション１１０Ｃにより処理される利用者ごとまたは金融取引ごとに用意されるアプリケーションファイルである。金融取引処理アプリケーション１１０Ｃは金融取引処理アプリケーションファイル１１２Ｃを用いて以下の処理を実行する。
　(11)利用者ごとまたは金融取引ごとに金融取引処理アプリケーションファイル１１２Ｃをオンデマンドでオープンする「オープン処理」、(12)金融取引処理アプリケーションファイル１１２Ｃのデータを編集する「編集処理」、(13)利用者による「承認確認」の伺い処理および受付処理、(14)利用可否ステイタス情報５１０Ｃの一時有効状態切り替え処理、(15)金融取引処理の決済管理システム５００Ｃへの引き継ぎ処理、(16)利用可否ステイタス情報５１０Ｃの無効状態切り替え処理、(17)金融取引処理アプリケーションファイル１１２Ｃのクローズ処理の各処理である。

　（１１）金融取引処理アプリケーションファイル１１２Ｃのオープン処理
　金融取引処理アプリケーションファイル１１２Ｃのオープン処理については、実施例１で示した（１）金融取引処理アプリケーションファイル１１２Ａのオープン処理と同様であり、ここでは省略する。

　（１２）金融取引処理アプリケーションファイル１１２Ｃのデータ編集処理
　金融取引処理アプリケーションファイル１１２Ｃのデータ編集処理については実施例１で示した（２）金融取引処理アプリケーションファイル１１２Ａのデータ編集処理と同様であり、ここでは省略する。

　（１３）利用者に対する承認伺い処理および確認処理
　利用者に対する承認伺い処理、承認確認処理とも、実施例１で示した（３）利用者に対する承認伺い処理、承認確認処理と同様でありここでは省略する。

　（１４）利用可否ステイタス情報５１０Ｃの一時有効状態切り替え処理
　なお、承認確認処理で“承認情報”が確認されたこと、つまり、クローズ用の暗証コードが認証されたことを条件として、金融取引処理アプリケーション１１０Ｃは、利用可否ステイタス情報状態制御手段１１１Ｃを介して、既に説明した利用可否ステイタス情報５１０Ｃをデフォルト無効状態から一時有効状態へ切り替える“一時有効状態切り替え処理”を実行させる。

　（１５）金融取引処理の決済管理システム５００Ｃへの引き継ぎ処理
　金融取引処理アプリケーション１１０Ｃは、“金融取引情報データ引き渡し処理”として、金融取引処理アプリケーションファイル１１２Ｃに記録された金融取引情報のデータ内容を決済管理システム５３０へ引き渡す。
　なお、決済管理システム５３０は金融取引情報の引き渡しを受け、その後は通常の決済処理（利用可否ステイタス情報の有効状態の確認、金融決済処理など）が行われる。

　（１６）利用可否ステイタス情報５１０Ｃの無効状態切り替え処理
　上記した金融取引処理の決済管理システム５００Ｃへの引き継ぎ処理を実行した後、金融取引処理アプリケーション１１０Ｃは、利用可否ステイタス情報状態制御手段１１１Ｃを介して、利用可否ステイタス情報状態制御手段１１０Ｃによる、利用可否ステイタス情報５１０Ｃのデフォルト無効状態へ切り戻す“デフォルト無効状態切り替え処理”が行われる。

　（１７）金融取引処理アプリケーションファイル１１２Ｃのクローズ処理
　最後に、金融取引処理アプリケーション１１０Ｃによって金融取引処理アプリケーションファイル１１２Ｃをクローズする“金融取引処理アプリケーションファイル終了処理”が実行される。
　ここでは、上記した（１３）利用者に対する承認確認処理から（１７）金融取引処理アプリケーションファイル１１２Ｃのクローズ処理まで、利用者から送信された“承認情報”に含まれるクローズ用の暗証コードが認証されれば、一気に連続処理し、金融取引処理アプリケーションファイルの終了処理まで実行する運用となっている。

　次に、フローチャートおよび図面を参照しつつ、実施例３にかかる金融取引制御システム１００Ｃの処理の流れの概略を示す。なお、実施例１に示した金融取引制御システム１００Ａの処理の流れの概略と同様の部分、実施例２に示した金融取引制御システム１００Ｂの処理の流れの概略と同様の部分については詳しい説明は省略することとする。

　以下、一連のクレジット利用、デビット利用の手続の流れを図１８～図２２のシステムブロック図を参照しつつ説明する。なお、図２３と図２４は実施例３にかかる金融取引制御システム１００Ｃの利用者端末２００Ｃでの操作画面の例を示す図である。それら図中には、適宜利用可否ステイタス情報５１０Ｃの有効状態、無効状態の切り替えの様子が併せて図示されている。

　図１８に示した流れは実施例１の図２に示した流れと同様で良い。つまり、クレジット利用の決済に先立つ利用者アプリケーション２１０Ｃの立ち上げ処理（図１８ステップＳ５１）、暗証コード入力手段２３０を介した“オープン暗証コード”の入力処理（図１８ステップＳ５２）、利用者アプリケーション２１０Ｃを用いた“金融取引処理リクエスト情報”の生成処理（図１８ステップＳ５３）、利用者アプリケーション２１０Ｃによる“金融取引処理リクエスト情報”と“オープン暗証コード”の金融取引制御システム１００Ｃへの送信処理（図１８ステップＳ５４）、暗証コード認証手段１２０Ｃによるオープン暗証コードの認証処理（図１８ステップＳ５５）、利用者アプリケーション２１０Ｃによる金融取引処理アプリケーションファイルのオープン処理（図１８ステップＳ５６）、金融取引処理開始の準備完了の旨の利用者端末２００Ｃへの返信処理（図１８ステップＳ５７）、クレジット利用開始ＯＫの表示処理（図１８ステップＳ５８）までは実施例１の図２のステップＳ１からＳ８までと同様で良い。

　次に、店舗やＥＣサイトでの金融取引利用に移る。
　利用者は、上記のように、クレジット利用開始ボタン押下した後、“クレジット利用できます。”という表示があれば、クレジット利用を開始する。
　図１９に示した流れは実施例２の図１１に示した流れと同様で良い。つまり、電子決済アプリケーション２６０Ｃから利用者媒体アカウント情報２７０Ｃの取り込み処理（図１９ステップＳ５９）、店舗端末/ＥＣサイト４００の金融取引情報生成手段４２０を介した金融取引情報の生成処理（図１９ステップＳ６０）、金融取引情報の決済管理システム５００Ｃへの送信処理（図１９ステップＳ６１）、決済処理部５３０Ｃから金融取引情報の金融取引処理アプリケーション１１０Ｃへの引き渡し処理（図１９ステップＳ６２）、オープン処理されている金融取引処理アプリケーションファイル１１２Ｃと関連付けられている利用者ＩＤ情報か否かのチェック処理（図１９ステップＳ６３）、金融取引情報の金融取引処理アプリケーションファイル１１２Ｂへの編集・書き込み処理（図１９ステップＳ６４）は、実施例２の図１１に示したステップＳ３９からステップＳ４４までと同様で良い。

　次に、金融取引処理アプリケーションファイル１１２Ｃの承認処理に進む。
　まず、金融取引制御システム１００Ｃは“承認伺い処理”を実行する。
　利用者アプリケーション２１０Ｃに対して金融取引を承認して金融取引を正常終了させる承認終了処理を実行しても良いかを問う“承認リクエスト”を送信し、“承認リクエスト”に対する利用者アプリケーション２１０Ｃからの“承認情報”の返信を待つ（図２０ステップＳ６６）。
　なお、この“承認伺い処理”は、金融取引制御システム１００Ｃが自律的に利用者アプリケーション２１０Ｃに対して送信して“承認情報”の入力を待つ形でも良いし、利用者アプリケーション２１０Ｃ側が金融取引制御システム１００Ｃに自発的にアクセスして“承認情報”の入力を行う形であっても良い。

　利用者端末２００Ｃは、“承認リクエスト”を受信すると、ディスプレイ上に「ご利用の取引内容をご確認ください」というメッセージと、商品購入代金、クレジット支払回数などのクレジット利用内容を表示し、“承認ボタン”を表示して押下を促す（図２４（１））。この例では“承認する”というボタンと“承認しない”というボタンが表示される。
　利用者が“承認ボタン”を押下すると（図２０ステップＳ６６、図２４（２））、利用者アプリケーション２１０Ｃは、利用者に対してクローズ暗証コードの入力を要求するガイダンスを表示し（図２４（３））、利用者から暗証コード入力手段２３０を介して入力された“クローズ暗証コード”を得る（図２０ステップＳ６７）。ここでは生体情報として指紋情報が入力されるものとする（図２４（４））。
　なお、“承認しない”ボタンを押下した場合の運用は限定されないが、例えば、実施例１と同様、利用者アプリケーション２１０Ｂはこの金融取引が利用者による正当な取引ではないとして（例えば、不正使用者による不正取引とみなして）、決済処理部５３０Ｃには決済処理ＮＧの旨を通知し、金融取引処理を強制終了する。

　なお、上記の図１８の金融取引処理アプリケーションファイルのオープン処理から、図１９の各処理を経て、図２０の金融取引処理アプリケーションファイルのクローズ処理の流れは、利用者端末２００Ｃと金融取引制御システム１００Ｃとの間でアクセスを維持したままでも良い。つまり、図１８で説明した利用者アプリケーション２１０Ｃによる金融取引処理アプリケーションファイル１１２Ｃのオープン処理において確立した利用者アプリケーション２１０Ｃと金融取引処理アプリケーション１１２Ｃとのアクセスが維持されたままとし、図１９で説明した各処理を経て、図２０および図２１で説明する上記の金融取引処理アプリケーションファイル１１２Ｃのクローズ処理を開始し、“承認伺い処理”の段階に進んだことをもって利用者が利用者端末２００Ｃを介して“承認情報”の入力、“クローズ暗証コード”の入力に進む形でも良い。

　金融取引制御システム１００Ｃは、利用者端末２００Ｃからの“承認情報”の返信（図２０ステップＳ６８）を受けて“承認確認処理”を実行する。ここでは、この承認情報には“クローズ暗証コード”が設定されているので、“クローズ暗証コード”を抽出し、暗証コード認証手段１２０Ｃに入力し、クローズ暗証コードの認証処理を実行させる（図２０ステップＳ６９）。暗証コード認証手段１２０Ｃは、利用者アプリケーション２１０Ｃから送信されてきた“クローズ暗証コード情報”と、決済管理システム５００Ｃ上で登録されている“クローズ暗証コード情報”との認証処理を行い、認証処理に成功した場合は（図２０ステップＳ６９：Ｙ）、金融取引処理アプリケーション１１０Ｃに認証成功を通知し、認証処理に失敗した場合は（図中には図示せず）、利用可否ステイタス情報状態制御手段１１０Ｃに認証不成立を通知し、利用可否ステイタス情報状態制御手段１１０Ｃは金融取引情報のデータ内容を決済管理システム５３０へ引き渡す（図中には図示せず）。なお、ここでは利用可否ステイタス情報５１０Ｃは一度も書き換えられることなく“デフォルト無効状態”のままであり、決済管理システム５３０が通常のクレジット処理を実行するため、結局クレジット処理が不成立となる。

　認証に成功した場合、金融取引処理アプリケーション１１０Ｃは、与信管理部５２０が与信に基づいた場合の利用可否ステイタス情報５１０Ｃの設定が“有効状態”つまり“無効状態の設定ではない”か否かをチェックし（図２０ステップＳ７０）、与信管理部５２０の与信情報に基づく設定が“無効状態の設定ではない”場合には、決済管理システム５００Ｃは、利用可否ステイタス情報状態制御手段１１１Ｃによる利用可否ステイタス情報５１０Ｃの切り替え制御を実行する（図２０ステップＳ７１）。

　なお、切り替え制御は、利用可否ステイタス情報状態制御手段１１１Ｃが利用可否ステイタス情報５１０Ｃの状態を直接切り替えるプログラムでも良く、利用可否ステイタス情報状態制御手段１１１Ｃが決済管理システム５００Ｃの与信管理部５２０に利用可否ステイタス情報５１０Ｃの状態の切り替えを依頼し、与信管理部５２０が利用可否ステイタス情報５１０Ｃを切り替えるプログラムでも良い。
　図２０のステップＳ７０の結果、利用可否ステイタス情報５１０Ｃの状態は一時的に有効状態に切り替わる。

　なお、与信情報に基づく与信管理部５２０による利用可否ステイタス情報５１０Ｃの設定が“無効状態”を示す設定の場合は（図中には図示せず）、利用可否ステイタス情報状態制御手段１１０Ｃは、当該与信管理部５２０による“無効設定”を優先し、利用者端末２００Ｃから送信された承認終了処理にかかわらず、利用可否ステイタス情報５１０Ｃの“無効状態”を維持する取り扱いとし、利用可否ステイタス情報状態制御手段１１１Ｃは金融取引情報のデータ内容を決済管理システム５３０へ引き渡す（図示せず）。なお、ここでは利用可否ステイタス情報５１０Ｃは一度も書き換えられることなく無効状態のままであるので、決済管理システム５３０が通常のクレジット処理を実行することはできず、結局クレジット処理が不成立となる。

　承認確認処理で“承認情報”が確認されたこと、つまり、クローズ用の暗証コードの入力を条件として、金融取引処理アプリケーション１１０Ｃは決済処理ＯＫの旨の情報とともに、金融取引処理アプリケーションファイル１１２Ｃの金融取引情報のデータ内容を決済管理システム５３０へ引き渡す（図２１ステップＳ７２）。
　決済管理システム５３０は金融取引情報の引き渡しを受け、その後は通常の決済処理（利用可否ステイタス情報の有効状態の確認、金融決済処理など）を開始する（図２１ステップＳ７３）。

　決済処理部５３０は、金融取引情報から利用者ＩＤ情報などクレジット利用に必要な諸情報および決済代金情報を抽出し、利用可否ステイタス情報５１０Ｃの状態が有効状態であるか否かをチェックし（図２１ステップＳ７４）、利用可否ステイタス情報５１０Ｃの状態が“有効状態”であれば、クレジット決済処理が実行され（図２１ステップＳ７５）、店舗端末/ＥＣサイト４００にクレジット利用が成立した旨を示す情報が返信される（図２１ステップＳ７６）。なお、決済処理部５３０において、利用可否ステイタス情報５１０Ｃの状態が“無効状態”であれば（図中には図示せず）、クレジット決済処理が拒絶され、決済処理部５３０Ｃから店舗端末/ＥＣサイト４００にクレジット利用が不成立である旨を示す情報が返信される（図中には図示せず）。

　利用可否ステイタス情報状態制御手段１１０Ｃは、利用可否ステイタス情報５１０Ｃの通常時無効状態へ切り戻す“通常時無効状態切り替え処理”を自動的に実行する（図２２ステップＳ７７）。
　金融取引処理アプリケーション１１０Ｃは、“金融取引処理アプリケーションファイル終了処理”を実行し、金融取引処理アプリケーションファイル１１２Ｃをクローズする（図２２ステップＳ７８）。

　ここでは、図２０のステップＳ６９から図２２のステップＳ７８まで、利用者からの“承認情報”が確認されたこと、つまり、クローズ用の暗証コードの入力があれば、一気に連続処理し、金融取引処理アプリケーションファイルのクローズ処理まで実行する運用となっている。
　このように、実施例３の金融取引制御システム１００Ｃでは、クレジット利用を実行すると、一連の処理として利用可否ステイタス情報が無効状態に切り戻される。利用可否ステイタス情報が無効状態に切り戻された旨の表示がされる（図２４（５））。

　必要に応じて、利用者アプリケーション２１０Ｃを終了し（図２４（６））、利用者アプリケーション２１０Ｃが閉じられる（図２４（７））。さらに、利用者アプリケーション２１０Ｃのアイコン選択を解除する（図２４（８））。

　以上、本発明の金融取引制御システム１００、その利用者アプリケーション２１０の構成例における好ましい実施形態を図示して説明してきたが、本発明の技術的範囲を逸脱することなく種々の変更が可能であることは理解されるであろう。

　本発明の金融取引制御システムは、種々のクレジット利用システム、種々のデビット利用システムに広く適用することができる。

　１００　金融取引制御システム
　１１０　金融取引処理アプリケーション
　１１１　利用可否ステイタス情報状態制御手段
　１１２　金融取引処理アプリケーションファイル
　１２０　暗証コード認証手段
　２００　利用者端末
　２１０　利用者アプリケーション
　２２０　データ入力手段
　２３０　暗証コード入力手段
　２４０　通信手段
　２５０　カメラ
　２６０　電子決済アプリケーション
　２７０　利用者媒体アカウント情報
　３００　利用者ＩＤ保持媒体
　４００　店舗端末/ＥＣサイト
　４１０　利用者情報入力手段
　４２０　金融取引情報生成手段
　４３０　通信手段
　５００　決済管理システム
　５１０　利用可否ステイタス情報
　５２０　与信管理部
　５３０　決済処理部
　５４０　通信手段
　５６０　利用者媒体アカウント情報

Claims (11)

1. 　クレジット利用またはデビット利用の決済管理システムに適用される金融取引制御システムであって、
   　利用者のアカウントごとに生成された金融取引処理アプリケーションファイルと、前記利用者のアカウントに対する金融取引処理を制御する金融取引処理アプリケーションを備え、
   　前記金融取引処理アプリケーションファイルに、オープン処理に対するオープン暗証コードとクローズ処理に対するクローズ暗証コードが設定登録されており、
   　前記金融取引処理アプリケーションが、前記利用者端末より送信された前記金融取引処理リクエスト情報に含まれているオープン暗証コードを認証した後、当該利用者のアカウントに対する前記金融取引処理アプリケーションファイルをオープンするオープン処理と、
   　金融取引者から前記利用者のアカウントへの金融取引情報を受けて、前記金融取引処理アプリケーションファイルに前記金融取引情報を書き込む編集処理と、
   　前記利用者端末に対して前記金融取引情報を承認するか否かを問う承認リクエストを送信し、前記利用者端末からの承認情報の返信を待つ承認伺い処理と、
   　前記利用者端末より返信された前記承認情報に含まれているクローズ暗証コードを認証した後、前記金融取引処理アプリケーションファイルデータの前記決済管理システムへの引き渡し処理と、前記金融取引処理アプリケーションファイルのクローズ処理を実行することを特徴とする金融取引制御システム。
2. 　前記オープン暗証コードが前記利用者の生体情報を含むものであり、
   　前記クローズ暗証コードが前記利用者の生体情報を含むものであることを特徴とする請求項１に記載の金融取引制御システム。
3. 　前記金融取引に関する前記利用者ＩＤ情報が利用者媒体に保持されており、前記金融取引処理に際して前記利用者媒体を介して前記利用者ＩＤ情報がやり取りされる請求項１または２に記載の金融取引制御システム。
4. 　前記金融取引に関する前記利用者ＩＤ情報が前記利用者端末に保持されており、前記金融取引処理に際して前記利用者端末を介して前記利用者ＩＤ情報がやり取りされる請求項１または２に記載の金融取引制御システム。
5. 　前記金融取引処理アプリケーションが、前記利用者のアカウントの有効無効状態または金融取引受け入れ可否の状態を示す利用可否ステイタス情報の切り替えを制御する利用可否ステイタス情報状態制御手段を備え、
   　前記金融取引処理アプリケーションが、前記利用可否ステイタス情報を通常時は無効状態に維持する前記利用可否ステイタス情報状態制御手段を介した無効デフォルト処理を行い、
   　前記利用者端末からの前記承認情報の返信を条件として、前記利用可否ステイタス情報の一時有効状態への切り替え処理と、前記引き渡し処理と、前記利用可否ステイタス情報の前記無効デフォルト処理と、前記クローズ処理を連続処理することを特徴とする１から４のいずれかに記載の金融取引制御システム。
6. 　前記決済管理システム上の与信情報に基づいて設定される前記利用者のアカウントの有効無効状態または前記利用者の前記アカウントに対する前記金融取引受け入れの有効無効状態を示す前記利用可否ステイタス情報の設定が有効状態を示す設定の場合、前記決済管理システムが、前記利用可否ステイタス情報状態制御手段による前記利用可否ステイタス情報の切り替え制御を優先させて前記利用可否ステイタス情報の切り替えを受け入れ、
   　前記決済管理システム上の前記与信情報に基づいて設定される前記利用者のアカウントの有効無効状態または前記利用者の前記アカウントに対する前記金融取引受け入れの有効無効状態を示す前記利用可否ステイタス情報の設定が無効状態を示す設定の場合、前記決済管理システムが、前記利用可否ステイタス情報状態制御手段による前記利用可否ステイタス情報の切り替え制御を受け入れず、前記利用可否ステイタス情報の無効状態を維持することを特徴とする請求項５に記載の金融取引制御システム。
7. 　前記決済管理システム上の与信情報に基づいて設定される前記利用者のアカウントの有効無効状態または前記利用者の前記アカウントに対する前記金融取引受け入れの有効無効状態を示す前記利用可否ステイタス情報の設定が有効状態を示す設定の場合、前記決済管理システムが、前記利用可否ステイタス情報状態制御手段による前記利用可否ステイタス情報の切り替え制御を優先させて前記利用可否ステイタス情報の切り替えを受け入れ、
   　前記決済管理システム上の前記与信情報に基づいて設定される前記利用者のアカウントの有効無効状態または前記利用者の前記アカウントに対する前記金融取引受け入れの有効無効状態を示す前記利用可否ステイタス情報の設定が無効状態を示す設定の場合、前記決済管理システムが、前記与信情報に基づく前記利用可否ステイタス情報の無効状態の設定を優先するか、前記利用可否ステイタス情報状態制御手段による前記利用可否ステイタス情報の切り替え制御を優先するかを選択可能としたことを特徴とする請求項５に記載の金融取引制御システム。
8. 　前記利用者端末にインストールまたはＡＳＰで利用可能であり、請求項１から７のいずれかに記載の金融取引制御システムとやり取りする利用者アプリケーションであって、
   　前記金融取引処理リクエスト情報を作成する金融取引処理リクエスト情報作成処理と、作成した前記金融取引処理リクエスト情報を前記金融取引処理アプリケーションに送信する金融取引処理リクエスト情報送信処理と、
   　前記承認情報を作成する承認情報作成処理と、作成した前記承認情報を前記金融取引処理アプリケーションに返信する承認情報返信処理を備えたことを特徴とする利用者アプリケーション。
9. 　前記クレジット利用または前記デビット利用が、クレジットカードまたはキャッシュカードを用いて行われる金融取引であることを特徴とする請求項８に記載の利用者アプリケーション。
10. 　前記クレジット利用または前記デビット利用が、非カード型のＩＣデバイスまたは人体埋設型のマイクロＩＣデバイスを用いて行われる金融取引であることを特徴とする請求項８に記載の利用者アプリケーション。
11. 　クレジット利用またはデビット利用の決済管理システムに適用される金融取引制御方法であって、
    　利用者のアカウントごとに生成された金融取引処理アプリケーションファイルと、前記利用者のアカウントに対する金融取引処理を制御する金融取引処理アプリケーションを用い、
    　前記金融取引処理アプリケーションファイルに、オープン処理に対するオープン暗証コードとクローズ処理に対するクローズ暗証コードが設定登録されており、
    　前記金融取引処理アプリケーションが、前記利用者端末より送信された前記金融取引処理リクエスト情報に含まれているオープン暗証コードを認証した後、当該利用者のアカウントに対する前記金融取引処理アプリケーションファイルをオープンするオープン処理と、
    　金融取引者から前記利用者のアカウントへの金融取引情報を受けて、前記金融取引処理アプリケーションファイルに前記金融取引情報を書き込む編集処理と、
    　前記利用者端末に対して前記金融取引情報を承認するか否かを問う承認リクエストを送信し、前記利用者端末からの承認情報の返信を待つ承認伺い処理と、
    　前記利用者端末より返信された前記承認情報に含まれているクローズ暗証コードを認証した後、前記金融取引処理アプリケーションファイルデータの前記決済管理システムへの引き渡し処理と、前記金融取引処理アプリケーションファイルのクローズ処理を実行することを特徴とする金融取引制御方法。

Images