WO2019087349A1 - 金融取引制御システム、そのアプリケーション、それを用いた金融取引方法、および金融取引制御方法 - Google Patents

Abstract

【課題】　クレジット利用、デビッド利用などの金融取引において、利用者媒体の利用可否状態を制限することにより、確実に、第三者の成り済まし使用やスキミングによる不正使用の防止ができる金融取引制御システムを提供する。　【解決手段】　利用者のカードまたはアカウントの有効無効状態またはトランザクション受け入れ可否の状態を示す利用可否ステイタス情報の切り替えを制御する利用可否ステイタス情報状態制御手段を備える。利用可否ステイタス情報状態制御手段は利用可否ステイタス情報の無効状態をデフォルト設定として通常時無効状態に維持する。利用可否ステイタス情報を有効に切り替える旨の切り替えリクエスト情報、金融取引処理を開始する旨の金融取引処理リクエスト情報など利用者端末から送信される情報を受けて利用可否ステイタス情報を切り替える。有効状態に切り替えた後、所定条件により無効状態に切り替え戻す。

Description

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

　本発明は、クレジットカード、キャッシュカード等を用いた金融取引における不正防止の技術分野に属する。

　クレジットカード、キャッシュカード等のカードは高い利便性から広く普及している。
　その一方で、これらカード類を紛失したり盗難にあったりした場合、不正使用されるおそれがある。また、クレジットカード等はスキミング被害に合う恐れもある。
　クレジットカードやキャッシュカードの不正使用を防止するため、従来から様々な対策が採られている。

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

　さらに、本発明者は、利用者のクレジットカードやキャッシュカードの利用において、店頭などで使用する直前にアカウントを動的に有効化し、その後かならずクレジットカード、キャッシュカードを常時無効の状態に戻す処理が行われることを確保せしめた。
　また、本発明者は、現状世の中に数億枚出回っているクレジットカード、デビッドカード（キャッシュカード）などには一切変更を要せず、クレジット利用やデビッド利用を伴う金融取引を管理するサーバー側のアプリケーションの追加・変更のみで対応できるシステムを目指した。

　上記の技術的思想を具現化した金融取引制御システムは、クレジット利用またはデビット利用の金融取引管理システムに適用される金融取引制御システムであって、利用者のカードまたはアカウントの有効無効状態または前記利用者の前記カードまたは前記アカウントに対するトランザクション受け入れ可否の状態を示す利用可否ステイタス情報の切り替えを制御する利用可否ステイタス情報状態制御手段を備え、前記利用可否ステイタス情報状態制御手段が、前記利用可否ステイタス情報の無効状態をデフォルト設定として制御する無効デフォルト処理と、前記利用者が保持する利用者端末から送信される情報を受けて、前記利用可否ステイタス情報を切り替えるステイタス情報切り替え処理を実行することを特徴とする金融取引制御システムである。
　利用者端末から送信される情報としては、利用者が利用可否ステイタス情報の状態を意識して、利用可否ステイタス情報を有効状態に意図的に切り替える旨の切り替えリクエスト情報がある。また、利用者が利用可否ステイタス情報の状態は特段意識せず、利用者が金融取引処理を開始したい旨の金融取引処理リクエスト情報がある。

　本発明の金融取引制御システムは、いわば、カード不正使用防止システムとして利用できる。利用者のクレジットカードやキャッシュカードの利用において、店頭やＥＣサイトなどで使用する直前にだけ動的に利用者のカードまたはアカウントを有効化し、金融取引を完了した後にクレジットカード、キャッシュカードを無効の状態に戻す処理により、カード不正使用が防止できる。
　ここで、利用者のカードまたはアカウントの状態を考察すると、利用者のアカウントは無効状態がデフォルトとなっている。つまり、上記構成において、利用可否ステイタス情報状態制御手段により利用可否ステイタス情報が無効デフォルト処理により通常時無効状態に維持されている。
　本発明にかかる金融取引制御システムの第１の運用例としては、その通常時無効状態において、利用者端末から送信される情報が利用可否ステイタス情報の切り替えリクエスト情報である場合、利用可否ステイタス情報状態制御手段が利用可否ステイタス情報を有効に切り替える旨の切り替えリクエスト情報を受けた場合のみ、利用可否ステイタス情報が一時有効状態に切り替えられ、利用者端末から利用可否ステイタス情報を無効に切り替える旨の切り替えリクエスト情報を受ければ利用可否ステイタス情報を通常時無効状態に戻すという処理を行う運用がある。

　このようにアカウントがデフォルトとして通常時無効状態においておくという考え方は従来にはなく、利用者が使用する場合にのみ、利用可否ステイタス情報を自発的に細かく切り替えられることにより、カードの紛失時、盗難時のなりすまし使用や、スキミングなどの不正使用が有効に防止できる。
　ここで、利用者のカードまたはアカウントの無効状態、有効状態の切り替えは、金融取引において重要な設定条件の変更であるので、厳しい本人認証が求められる。そこで、カードまたはアカウントの無効／有効の切り替えに生体情報の認証を求める構成が好ましい。例えば、利用可否ステイタス情報状態制御手段が利用者により金融取引管理システム上で登録されている生体情報にアクセスする手段を備えた構成とする。そして、利用可否ステイタス情報状態制御手段が切り替えリクエスト情報の受け付けにあたり、切り替えリクエスト情報に含まれる生体情報と、金融取引管理システム上で登録されている生体情報との照合による認証処理に成功したことを条件としてステイタス情報切り替え処理を実行する構成とすれば良い。

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

　そこで、本発明者は、店舗やＥＣサイト（電子商取引サイト）での取引情報に対する利用者の承認終了情報の入力を必須とし、その承認終了情報の入力と、カードまたは利用者アカウントの有効・無効状態の利用可否ステイタス情報の切り替えを連動させる仕組みを発明した。

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

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

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

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

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

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

　以上、本発明の金融取引制御システムを説明したが、クレジット利用またはデビット利用を行う際に使用する媒体と金融取引について説明する。
　利用媒体として、カード媒体がある。つまり、本発明の金融取引制御システムは、クレジットカードまたはキャッシュカードを用いて行われる金融取引の処理に適用できる。また、本発明の金融取引制御システムは、非カード型のＩＣデバイスを用いて行われる金融取引に適用できる。また、さらに、本発明の金融取引制御システムは、人体埋設型のマイクロＩＣデバイスを用いて行われる金融取引にも適用できる。

　本発明は、上記した金融取引制御システムに搭載される金融取引制御アプリケーションとして提供できる。
　また、本発明は、上記した金融取引制御システムを用いて行われるクレジット利用またはデビット利用を行う金融取引方法として提供できる。

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

　以下、本発明を実施するための最良の形態について実施例により具体的に説明する。なお、本発明はこれらの実施例に限定されるものではない。

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

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

　利用者端末２００は、スマートフォンなどの利用者が携帯する端末が好ましい。利用者端末２００は、利用者アプリケーション２１０、データ入力手段２２０、暗証コード入力手段２３０、通信手段２４０を備えている。
　利用者アプリケーション２１０は、金融取引制御システム１００との間でデータのやり取りをするアプリケーションである。この利用者アプリケーション２１０を搭載することにより利用者は利用者端末２００を介して、クレジット利用、デビット利用のサービスについて本発明のサービスを利用できる。
　データ入力手段２２０は、一般の携帯型端末が装備するタッチディスプレイや音声入力手段などの利用者インターフェイスを介して利用者よりデータの入力を受け付ける手段である。
　暗証コード入力手段２３０は、利用者から暗証コードの入力を受け付けるデバイスである。暗証コードが数字や文字である場合は、タッチディスプレイで暗証コードの入力が可能であるので、データ入力手段２２０が暗証コード入力手段２３０を兼用することができる。暗証コードが生体情報である場合、該当する生体情報を読み取るデバイスである。生体情報が指紋情報である場合、指紋読み取りデバイスであれば良い。生体情報が指やてのひらの静脈パターン情報である場合、静脈読み取りデバイスであれば良い。生体情報が虹彩情報である場合、虹彩読み取りデバイスであれば良い。
　通信手段２４０は、利用者端末２００が装備している通信機能で良い。

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

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

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

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

　与信管理部５２０は、金融機関や信販会社などが管理運営している一般の金融取引管理システムが装備している与信管理部と同様で良いが、後述するように、利用可否ステイタス情報の管理において、有効状態を維持している場合、金融取引制御システム１００の利用可否ステイタス情報状態制御手段１１０による利用可否ステイタス情報５１０の状態制御を優先し、与信管理に基づく無効状態を設定する場合、金融取引制御システム１００の利用可否ステイタス情報状態制御手段１１０による利用可否ステイタス情報５１０の状態制御よりも与信管理に基づく無効状態設定を優先する。詳しくは後述する。

　決済処理部５３０は、金融機関や信販会社などが管理運営している一般の金融取引管理システムが装備している決済処理部と同様で良く、利用可否ステイタス情報が有効状態と確認された条件下、店舗端末/ＥＣサイト４００から受信した金融取引情報を基に決済処理を行うものである。

　次に、金融取引制御システム１００の構成を詳しく述べる。
　利用可否ステイタス情報状態制御手段１１０は、利用者端末２００の利用者アプリケーション２１０から受け取った利用可否ステイタス情報の切り替えを依頼する切り替えリクエスト情報に基づいて、金融取引管理システム５００上で管理されている利用可否ステイタス情報５１０の有効／無効の状態の切り替えを制御する手段である。
　利用可否ステイタス情報状態制御手段１１０は、「無効デフォルト処理」と「ステイタス情報切り替え処理」を備えている。

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

　「ステイタス情報切り替え処理」は、利用者が保持する利用者端末２００の利用者アプリケーション２１０から送信される切り替えリクエスト情報を受け、利用可否ステイタス情報５１０をオンデマンドで切り替える処理である。このステイタス情報切り替え処理により、利用可否ステイタス情報５１０のデフォルト設定である無効状態をオンデマンドで一時的に有効状態に切り替えたり、一時的に有効状態になったものをデフォルト設定である無効状態に切り戻したりすることができる。
　従来技術では、一般的にはこの利用可否ステイタス情報５１０は有効状態であることが通常状態であり、無効状態である場合は何らかの異常状態や事故状態に陥っているものであった。例えば、クレジットカードやデビッドカードなどが盗難や紛失したため利用者から金融機関や信販会社の決済センターに対して、それらカード類を使用できないように使用停止の要求が出されている場合や、利用者のクレジット利用やデビッド利用を伴う過去の金融取引の口座引き落としが不能で当該利用者の与信がなくなった場合など何らかの異常状態に陥っている場合が想定されている。

　しかし、本発明では、金融取引制御システム１００が利用可否ステイタス情報状態制御手段１１０を装備することにより、金融取引管理システム５００上で管理されている利用可否ステイタス情報５１０の有効無効状態を利用者の発意により細かく切り替え制御を認めることで、クレジット利用またはデビット利用を伴う金融取引のセキュリティを向上せしめるものである。

　本発明では、従来とは発想を逆転させ、利用可否ステイタス情報状態制御手段１１０は、利用可否ステイタス情報５１０のデフォルト設定を“無効状態”として制御する「無効デフォルト処理」を行う。つまり、利用可否ステイタス情報５１０は通常時（デフォルト設定時）は、利用可否ステイタス情報状態制御手段１１０により“無効状態”に維持される。
　このように、従来の金融取引管理システム５００の管理では、利用可否ステイタス情報５１０は通常時（デフォルト設定時）は“有効状態”が維持され、何らかの不都合が発生した場合にのみ例外的に“無効状態”に切り替えられるものであった。しかし、本発明では、金融取引管理システム５００に対して金融取引制御システム１００が介在しており、金融取引制御システム１００の利用可否ステイタス情報状態制御手段１１０により、金融取引管理システム５００上の利用可否ステイタス情報５１０が「無効デフォルト処理」を行い、通常時は“無効状態”に維持される。

　利用可否ステイタス情報状態制御手段１１０が、利用者端末２００から利用可否ステイタス情報を有効に切り替える旨の切り替えリクエスト情報を受けた場合のみ、利用可否ステイタス情報５１０が一時的に“有効状態”に切り替えられる。さらに、その後、利用者端末２００の利用者アプリケーション２１０から利用可否ステイタス情報５１０を無効に切り替える旨の切り替えリクエスト情報を受け付ければ、利用可否ステイタス情報５１０を通常時“無効状態”に戻す処理が行われる。

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

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

　次に、暗証コード入力手段１２０について説明する。
　金融取引制御システム１００が暗証コード認証手段１２０を含む構成の場合、利用者端末２００の利用者アプリケーション２１０の切り替えリクエスト情報の受付にあたり、情報入力者による暗証コードの入力を要求する運用となる。
　利用者端末２００は暗証コード入力手段２３０が装備されており、情報入力者は暗証コード入力手段２３０を介して暗証コードを入力して切り替えリクエスト情報に暗証コード情報を付して金融取引制御システム１００に対して送信する。
　金融取引制御システム１００は、切り替えリクエスト情報の受け付けにあたり、暗証コード認証手段１２０が、金融取引管理システム５００上で登録されている暗証コード情報と切り替えリクエスト情報に含まれる暗証コード情報との認証処理を行い、認証処理に成功したことを条件としてステイタス情報切り替え処理を実行する取り扱いとする。

　暗証コード認証手段１２０は、セキュリティのさらなる向上のために装備する構成である。利用者端末２００からの利用可否ステイタス情報５１０の切り替えリクエスト情報の送信が利用者本人によりなされたものか否かを確認するため、暗証コード入力を求め、利用者を認証するものである。暗証コードとしては、例えば、暗証番号（ＰＩＮコード）、生体情報などがあり得る。
　暗証コードが暗証番号の場合は４桁以上の数字・文字列が好ましい。この場合利用者端末２００の暗証コード入力手段２３０はタッチパネル上に表示されるＰＩＮパッドなどが良い。なお、利用者が入力するＰＩＮコードと利用者端末２００の端末ＩＤ番号とを組み合わせるなど一定のアルゴリズムで計算したコードを暗証コードとして送信するものでも良い。

　暗証コードが生体情報の場合、生体情報としては、指紋情報、指静脈情報、手のひら静脈情報、虹彩情報、顔画像情報、声紋情報などがあり得る。この場合利用者端末２００の暗証コード入力手段２３０は、対応する生体情報が読み取れるデバイス（指紋リーダー、静脈リーダー、虹彩リーダー、カメラ、マイクロフォンなどの音声入力装置など）が装備されているものとする。

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

　次に、フローチャートおよび図面を参照しつつ、実施例１にかかる金融取引制御システム１００の処理の流れの概略を示す。
　ここでは、利用者媒体３００は、ＩＣカード型のクレジットカード３００とする。利用者が店舗に行って商品を購入してクレジット利用により金融取引決済を行うシーンを前提として説明する。なお、利用者がＥＣサイトにログインして商品を購入してクレジット利用やデビット利用による金融取引決済を行うシーンとしても同様に考えることができる。
　利用者端末２００は指紋認証機能付きのスマートフォン２００とする。スマートフォン２００には利用者アプリケーション２１０、データ入力手段２２０、暗証コード入力手段２３０、通信手段２４０が装備されているものとする。なお、この例では、データ入力手段２２０はタッチパネルディスプレイであり、暗証コードは４桁の番号情報であり、データ入力手段２２０が暗証コード入力手段２３０を兼用する構成とする。

　以下、一連のクレジット利用、デビット利用の手続の流れを図２～図５のシステムブロック図および図１９～図２１のフローチャートを参照しつつ説明する。また、図６は不正利用時の取扱いを示したシステムブロック図であり、図２２は不正利用時の取扱いを示したフローチャートである。それら図中には、適宜利用可否ステイタス情報５１０の有効状態、無効状態の切り替えの様子が併せて図示されている。

　なお、図７と図８は実施例１にかかる金融取引制御システム１００の利用者端末２００での操作画面の例を示す図である。
　まず、利用者は、商品を選定し、クレジット利用の決済に先立ち、スマートフォン２００を操作して利用者アプリケーション２１０を立ち上げ（図２、図１９ステップＳ１）、例えば「クレジット利用開始ボタン」を押下する。例えば、利用者端末２００のディスプレイ上に表示されている利用者アプリケーション２１０のアイコンをタップする（図７（１））。

　利用者アプリケーション２１０が立ち上がると“切り替えリクエスト情報”の生成の有無を確認する画面（図７（２））が表示される。例えば、タッチパネルディスプレイには、「クレジットカードは現在無効状態です。」というメッセージが表示され、“クレジットカードを有効状態にする”というボタンが表示されており、当該ボタンの押下（図７（３））により“切り替えリクエスト情報”を自動生成できる。
　クレジットカードを有効状態にするというボタン押下（図７（３））により“切り替えリクエスト情報”の生成が開始される。

　利用者アプリケーション２１０は、データ入力手段２２０であるタッチパネルディスプレイ上に利用者に対して暗証コードの入力を要求するガイダンスを表示し（図７（４））、利用者から暗証コード入力手段２３０（データ入力手段２２０で兼用）を介して入力された暗証コードを得る（図２、図１９ステップＳ２）。ここでは４桁の暗証コードが入力される。
　“切り替えリクエスト情報”が生成される（図２、図１９ステップＳ３）。
　利用者アプリケーション２１０は、通信手段２４０を介して“切り替えリクエスト情報”と“暗証コード”を金融取引制御システム１００に送信する（図２、図１９ステップＳ４）。

　金融取引制御システム１００は、ネットワークを介して送信されてくる“切り替えリクエスト情報”の待ち状態にある。ここで、図２に示すように、利用可否ステイタス情報５１０は“無効状態”になっている。

　金融取引制御システム１００は、送信されてきた“切り替えリクエスト情報”を受け付けると、“暗証コード”を抽出し、暗証コード認証手段１２０に入力し、暗証コードの認証処理を実行させる（図２、図１９ステップＳ５）。
　暗証コード認証手段１２０は、金融取引管理システム５００上で登録されている“暗証コード情報”にアクセスし（図示せず）、利用者アプリケーション２１０から送信されてきた“暗証コード情報”と、金融取引管理システム５００上で登録されている“暗証コード情報”との認証処理を行い（図２、図１９ステップＳ５）、認証処理に成功した場合は（図２、図１９ステップＳ５：Ｙ）、利用可否ステイタス情報状態制御手段１１０に認証成功を通知（図２、図１９ステップＳ６）し、認証処理に失敗した場合は（図２、図１９ステップＳ５：Ｎ、図２には図示せず）、利用可否ステイタス情報状態制御手段１１０に認証不成立を通知し、利用可否ステイタス情報５１０の切り替え処理を打ち切る（図２、図１９ステップＳ７、図２には図示せず）。
　認証に成功した場合、利用可否ステイタス情報状態制御手段１１０は、ステイタス情報切り替え処理に進む。
　この処理例の前提では、金融取引管理システム５００は、与信に基づく利用可否ステイタス情報５１０の無効設定を優先するという原則で制御を実行している。

　利用可否ステイタス情報状態制御手段１１０は、与信管理部５２０が与信情報に基づいた場合の利用可否ステイタス情報５１０の設定が“有効状態”つまり“無効状態の設定ではない”か否かをチェックし（図３、図１９ステップＳ８）、与信管理部５２０の与信情報に基づく設定が“無効状態の設定ではない”場合には（図３、図１９ステップＳ８：Ｙ）、金融取引管理システム５００は、利用可否ステイタス情報状態制御手段１１０による利用可否ステイタス情報５１０の切り替え制御を優先させて利用可否ステイタス情報５１０の切り替えを受け入れ、ステイタス情報切り替え処理を実行する（図３、図１９ステップＳ９）。
　なお、利用可否ステイタス情報状態制御手段１１０が利用可否ステイタス情報５１０の状態を直接切り替えるプログラムでも良く、利用可否ステイタス情報状態制御手段１１０が金融取引管理システム５００の与信管理部５２０に利用可否ステイタス情報５１０の状態の切り替えを依頼し、与信管理部５２０が利用可否ステイタス情報５１０を切り替えるプログラムでも良い。

　図２、図１９のステップＳ９の結果、利用可否ステイタス情報５１０の状態は有効状態に切り替わっている。
　もし、与信情報に基づく与信管理部５２０による利用可否ステイタス情報５１０の設定が“無効状態”を示す設定の場合は（図３、図１９ステップＳ８：Ｎ、図３中には図示せず）、利用可否ステイタス情報状態制御手段１１０は、当該与信管理部５２０による“無効設定”を優先し、利用者端末２００から送信された利用可否ステイタス情報の切り替えリクエスト情報を受け入れず、利用可否ステイタス情報５１０の“無効状態”を維持する取り扱いとし、利用可否ステイタス情報５１０の切り替え処理を打ち切る（図３、図１９ステップＳ１０、図３中には図示せず）。

　利用者端末２００のディスプレイ上には、例えば「クレジットカードは現在有効状態です。」と表示され、利用可否ステイタス情報５１０がデフォルト状態である“無効状態”から“有効状態”に切り替わったことが表示される（図７（５））。その後、利用者がクレジット利用またはデビット利用を行う。

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

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

　利用者は、所望のクレジット利用、デビット利用が終了すれば、再び、利用可否ステイタス情報５１０の状態を無効に戻すことができる。
　利用者は、クレジット利用やデビット利用の金融取引が完了すれば再び“切り替えリクエスト情報”を生成するため、利用者アプリケーション２１０を操作する（図５、図２１ステップＳ１９）。例えば、タッチパネルディスプレイには、「クレジットカードは現在有効状態です。」というメッセージが表示され、 “クレジットカードを無効状態にする”というボタンが表示されており、当該ボタンの押下（図８（１））により“切り替えリクエスト情報”を自動生成できる。

　利用者アプリケーション２１０は、データ入力手段２２０であるタッチパネルディスプレイを介して利用者に対して暗証コードの入力を要求し（図８（２））、暗証コード入力手段２３０（データ入力手段２２０で兼用）を介して入力された暗証コードを得る（図５、図２１ステップＳ２０）。ここでは４桁の暗証コードが入力される。
　利用者アプリケーション２１０は“切り替えリクエスト情報”を生成する（図５ステップＳ２１）。
　利用者アプリケーション２１０は、通信手段２４０を介して“切り替えリクエスト情報”と“暗証コード情報”を金融取引制御システム１００に送信する（図５、図２１ステップＳ２２）。

　金融取引制御システム１００は、送信されてきた“切り替えリクエスト情報”を受け付けると、“暗証コード”を抽出し、暗証コード認証手段１２０に入力し、暗証コードの認証処理を実行させる（図５、図２１ステップＳ２３）。
　暗証コード認証手段１２０は、“暗証コード情報”の認証処理を行い（図５、図２１ステップＳ２３）、認証処理に成功した場合は（図５、図２１ステップＳ２３：Ｙ）、利用可否ステイタス情報状態制御手段１１０に認証成功を通知（図５、図２１ステップＳ２４）する。

　認証に成功した場合、利用可否ステイタス情報状態制御手段１１０は、ステイタス情報切り替え処理に進む。
　金融取引管理システム５００は、利用可否ステイタス情報状態制御手段１１０による利用可否ステイタス情報５１０の切り替えを受け入れ、ステイタス情報切り替え処理を実行する（図５、図２１ステップＳ２５）。
　なお、利用可否ステイタス情報状態制御手段１１０が利用可否ステイタス情報５１０の状態を直接切り替えるプログラムでも良く、利用可否ステイタス情報状態制御手段１１０が金融取引管理システム５００の与信管理部５２０に利用可否ステイタス情報５１０の状態の切り替えを依頼し、与信管理部５２０が利用可否ステイタス情報５１０を切り替えるプログラムでも良い。

　認証処理に失敗した場合は（図５、図２１ステップＳ２３：Ｎ、図５中には図示せず）、利用可否ステイタス情報状態制御手段１１０に認証不成立を通知し、利用可否ステイタス情報５１０の切り替え処理を打ち切る（図５、図２１ステップＳ２６、図５中には図示せず）する。
　図５、図２１のステップＳ２５の結果、利用可否ステイタス情報５１０の状態はデフォルト設定の“無効状態”に切り戻されている。
　この結果、金融取引管理システム５００、利用可否ステイタス情報５１０の状態は図２の冒頭に示す初期状態に戻る。必要に応じて、利用者アプリケーション２１０を終了し（図８（４））、利用者アプリケーション２１０が閉じられる（図８（５））。さらに、利用者アプリケーション２１０のアイコン選択を解除する（図８（６））。

　次に、第三者による成り済ましの不正利用があった場合について説明する。
　図６は、第三者による成り済ましの不正利用があった場合にセキュリティが確保されていることを示すシステム図である。図２２は不正利用があった場合の処理の流れを示すフローチャートである。
　クレジットカードやキャッシュカードなどが窃盗・詐取された場合や、スキミングなどによりカードが偽造され、当該カードを不正利用しようとする第三者が本人に成り済まして店頭でクレジット利用、デビット利用を行った場合の処理の流れを示している。

　不正利用者が店舗やＥＣサイトなどで商品購入時に窃盗・詐取または偽造したクレジットカード３００を提示し、使用を試みる。利用者情報入力手段４１０からクレジットカード３００に保持されている利用者ＩＤ情報など金融取引に必要な情報が入力される（図６、図２２ステップＳ１'）。ここでは利用者本人の正しい利用者ＩＤ情報が入力されるものとする。店舗会計スタッフが、店舗端末/ＥＣサイト４００の金融取引情報生成手段４２０を介してクレジットカードから利用者ＩＤ情報などクレジット利用に必要な諸情報および決済代金情報などを入力し、それら情報を基に金融取引情報を生成し（図６、図２２ステップＳ２'）、利用者端末４００の通信手段４３０を介してそれら金融取引情報が金融取引管理システム５００に送信される（図６、図２２ステップＳ３'）。

　金融取引管理システム５００の決済処理部５３０が、利用者ＩＤ情報などクレジット利用に必要な諸情報および決済代金情報を受け付け（図６、図２２ステップＳ４'）、利用可否ステイタス情報５１０の状態が有効状態であるか否かをチェックすると（図６、図２２ステップＳ５'）、利用可否ステイタス情報５１０の状態が通常時“無効状態”であるため（図６、図２２ステップＳ５：Ｎ、図６中には図示せず）、クレジット決済処理が不可で拒絶され（図６、図２２ステップＳ６'）、店舗端末/ＥＣサイト４００にクレジット利用が不成立で使用不能の旨を示す情報が返信される（図６、図２２ステップＳ７'）。このように、カードの窃盗・詐取、偽造などに利用者本人が気付いていない場合でも、不正利用が確実に防止できる。

　実施例２にかかる本発明の金融取引制御システム１００Ａについて説明する。
　以下、実施例２にかかる本発明の金融取引制御システム１００Ａについて説明するが、実施例１と同様の部分については説明を適宜省略することとする。
　実施例１では、利用可否ステイタス情報５１０が無効デフォルト処理により通常時無効状態にあり、その状態を利用者が意識的に自ら“有効状態”に切り替えたり、“無効状態”に切り戻したりするものであったが、本実施例２は、利用可否ステイタス情報５１０が無効デフォルト処理により通常時無効状態にある点は同様であるが、利用者は金融取引処理の開始時に金融取引処理のリクエストを入力して金融取引処理を開始した後、金融取引処理の実行に伴って、金融取引制御システム１００Ａが自動的に通常時無効状態に戻すものである。
　図９は実施例２にかかる金融取引制御システム１００Ａの構成を簡単に示した図である。図９には、金融取引制御システム１００Ａのほか、利用者端末２００Ａ、利用者媒体３００、店舗端末/ＥＣサイト４００、金融取引管理システム５００Ａが示されている。
　金融取引制御システム１００Ａは、実施例１と同様、利用者端末２００Ａと金融取引管理システム５００Ａとの間に介在するものであるが、システムの構築箇所としては、利用者端末２００Ａ上に装備されていても良いし、金融取引管理システム５００Ａ上に装備されていても良い。この例では、金融取引管理システム５００Ａ上に装備されている例として示す。

　実施例２にかかる金融取引制御システム１００Ａは、少なくとも利用可否ステイタス情報状態制御手段１１０Ａ、暗証コード認証手段１２０Ａを備えている。
　利用可否ステイタス情報状態制御手段１１０Ａは、実施例１で説明した「無効デフォルト処理」を行うほか、本実施例２では、トランザクション受付アプリケーション１１１によるクレジット利用/デビット利用時にオンデマンドによるトランザクション受付アプリケーションファイル１１２のオープン処理、利用可否ステイタス情報の有効化処理、金融取引処理、利用可否ステイタス情報の無効化処理、トランザクション受付アプリケーションファイル１１２のクローズ処理を実行する。

　通常時の「無効デフォルト処理」は、実施例１と同様のものであり、無効デフォルト処理を実行することにより、金融取引管理システム５００Ａの利用可否ステイタス情報５１０は通常時無効状態が維持される。これにより、利用者が気付かないうちに第三者が不正使用を試みようとしてもクレジット利用やデビット利用ができず高いセキュリティが維持できる。

　実施例２にかかる利用可否ステイタス情報状態制御手段１１０Ａは、第三者からの金融取引情報のリクエストを受け付けて処理するトランザクション受付アプリケーション１１１を備えている。
　トランザクション受付アプリケーション１１１は常駐型でも良く、利用者端末２００Ａの操作に応じて立ち上げられるものであっても良い。

　トランザクション受付アプリケーション１１１は、利用者の金融取引情報を管理するアプリケーションであり、利用者ごとにトランザクション受付アプリケーションファイル１１２をオンデマンドで生成したり、トランザクション受付アプリケーションファイル１１２のデータを編集したり、利用者に対する承認確認処理を実行したり、金融取引処理の金融取引管理システム５００Ａへの引き継ぎ処理を実行したり、トランザクション受付アプリケーションファイル１１２のクローズ処理を実行したりするアプリケーションである。
　本実施例２では、トランザクション受付アプリケーション１１１にはクローズ暗証コードが設けられており、後述するように承認確認処理、金融取引処理の引き継ぎ処理、トランザクション受付アプリケーションファイル１１２の消去処理という一連のクローズ処理を一気に実行する際に認証が行われる。
　なお、利用者アプリケーション２１０を真正の利用者が操作していることの確認は、利用者アプリケーション２１０の立ち上げ時に暗証コードの入力などが要求されており、利用者アプリケーション２１０の操作が真正の利用者によりなされていることは確認されているものとする。

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

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

　次に、“トランザクション受付アプリケーションファイルクローズ処理”は、トランザクション受付アプリケーション１１１が立ち上がっているトランザクション受付アプリケーションファイルをクローズする処理であるが、ここでは、トランザクション受付アプリケーション１１１が、第三者（ここでは店舗端末/ＥＣサイト４００）からの金融取引情報を受け、トランザクション受付アプリケーションファイル１１２に対して金融取引情報を編集したことをきっかけとして開始する。ここで、クローズ処理として６つの処理を伴うものとする。

　第１の処理は、利用者端末２００Ａに対して金融取引の受け付けを承認して金融取引を正常終了させる承認終了処理を実行しても良いかを問う“承認終了リクエスト”を送信し、“承認終了リクエスト”に対する利用者端末２００Ａからの承認終了情報の返信を待つ“承認終了伺い処理”である。
　ここでは、この承認終了情報には“クローズ暗証コード”が設定されているものとする。つまり、トランザクション受付アプリケーションファイル１１２を編集後にファイルを正常にクローズさせるにもクローズ用の暗証コードが設定されており、さらに高いセキュリティレベルが設けられている。

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

　第３の処理は、承認終了確認処理で“承認終了情報”が確認されたこと、つまり、クローズ用の暗証コードの入力を条件として、利用可否ステイタス情報状態制御手段１１０Ａが利用可否ステイタス情報の通常時無効状態から一時有効状態へ切り替える“一時有効状態切り替え処理”である。

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

　第５の処理は、利用可否ステイタス情報状態制御手段１１０Ａによる、利用可否ステイタス情報５１０の通常時無効状態へ切り戻す“通常時無効状態切り替え処理”である。

　第６の処理は、トランザクション受付アプリケーション１１１によってトランザクション受付アプリケーションファイル１１２をクローズする“トランザクション受付アプリケーションファイル終了処理”である。
　ここでは、第３の処理から第６の処理まで、利用者からの“承認終了情報”が確認されたこと、つまり、クローズ用の暗証コードの入力があれば、一気に連続処理し、トランザクション受付アプリケーションファイルのクローズ処理まで実行する運用となっている。

　次に、利用者端末２００Ａについて説明する。
　利用者端末２００Ａは、スマートフォンなどの利用者が携帯する端末が好ましく、実施例１と同様、利用者アプリケーション２１０Ａ、データ入力手段２２０、暗証コード入力手段２３０、通信手段２４０を備えている。

　利用者アプリケーション２１０Ａは、金融取引制御システム１００Ａとの間でデータのやり取りをするアプリケーションであり、実施例１の利用者アプリケーション２１０と同様の機能を備えているが、実施例２では、“金融取引処理リクエスト情報”の送信に加え、“承認終了情報”の送信が求められる。前者はトランザクション受付アプリケーションファイルのオープン処理に対応し、後者はトランザクション受付アプリケーションファイルのクローズ処理に対応するものである。

　データ入力手段２２０は、一般の携帯型端末が装備するタッチディスプレイや音声入力手段などの利用者インターフェイスを介して利用者よりデータの入力を受け付ける手段である。

　暗証コード入力手段２３０は、実施例１と同様、利用者から暗証コードの入力を受け付けるデバイスである。実施例２では、暗証コードとして、オープン暗証コードの入力、クローズ暗証コードの入力があるので、暗証コード入力手段２３０はそれらに対応する手段である。両者とも生体情報であれば、生体情報入力デバイスとなる。
　利用者媒体３００および店舗端末/ＥＣサイト４００は、実施例１と同様で良いのでここでは説明を省略する。

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

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

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

　この例では、利用者媒体３００は、ＩＣカード型のクレジットカード３００とし、利用者が店舗に行って商品を購入してクレジット利用により金融取引決済を行うシーンを前提として説明する。なお、利用者がＥＣサイトにログインして商品を購入してクレジット利用やデビット利用による金融取引決済を行うシーンとしても同様に考えることができる。
　利用者端末２００Ａは指紋認証機能付きのスマートフォンとする。スマートフォンには利用者アプリケーション２１０Ａ、データ入力手段２２０、暗証コード入力手段２３０、通信手段２４０が装備されているものとする。なお、この例では、データ入力手段２２０はタッチパネルディスプレイであり、暗証コードは４桁の番号情報であり、データ入力手段２２０が暗証コード入力手段２３０を兼用する構成とする。

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

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

　利用者アプリケーション２１０Ａが立ち上がると“クレジット利用開始”を確認する画面（図１５（２））が表示される。このクレジット利用開始ボタン押下（図１５（３））により“金融取引利用リクエスト情報”が生成される（図１０、図２３ステップＳ３２）。
　利用者アプリケーション２１０Ａは、通信手段２４０を介して“金融取引利用リクエスト情報”を金融取引制御システム１００Ａに送信する（図１０、図２３ステップＳ３３）。

　金融取引制御システム１００Ａは、送信されてきた“金融取引利用リクエスト情報”を受け付けると、利用可否ステイタス情報状態制御手段１１０Ａは、トランザクション受付アプリケーション１１１に対して、金融取引利用リクエスト情報を通知し（図１０、図２３ステップＳ３４）、該当する利用者ＩＤ情報に関連付けられたトランザクション受付アプリケーションファイル１１２をオープン処理する（図１０、図２３ステップＳ３５）。

　トランザクション受付アプリケーション１１１は、トランザクション受付アプリケーションファイル１１２のオープン処理を実行すれば、利用可否ステイタス情報状態制御手段１１０Ａ、金融取引制御システム１００Ａは“金融取引利用開始ＯＫ”を示す情報を生成し（図１０、図２３ステップＳ３６）、通信手段５４０を介して利用者端末２００に返信される（図１０、図２３ステップＳ３７）。
　利用者アプリケーション２１０は、“金融取引利用開始ＯＫ”を示す情報を受ければ、利用者端末２００Ａのディスプレイ上に、例えば、“クレジットカードは現在有効状態です。クレジット利用できます。”などの金融取引処理が可能である表示を行う（図１５（４））（図１０、図２３ステップＳ３８）。

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

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

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

　オープン処理されているトランザクション受付アプリケーションファイル１１２がある利用者ＩＤ情報ではない場合は（図１１、図２４ステップＳ４３：Ｎ）、他の利用者であるため、決済処理部５３０Ａに対して、決済処理開始ＯＫの情報とともに金融取引情報を返し（図１１、図２４ステップＳ４４）、決済処理部５３０Ａは、金融取引情報を基に、通常の決済処理を開始する。
　オープン処理されているトランザクション受付アプリケーションファイル１１２がある利用者ＩＤ情報である場合は（図１１、図２４ステップＳ４３：Ｙ）、本発明の金融取引制御システム１００Ａの利用者であり、クレジット利用の処理中を意味するので、受け取った金融取引情報を該当するトランザクション受付アプリケーションファイル１１２に書き込む（図１１、図２４ステップＳ４５）。

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

　利用者端末２００Ａは、“承認終了リクエスト”を受信すると、ディスプレイ上に「ご利用の取引内容をご確認ください」というメッセージと、商品購入代金、クレジット支払回数などのクレジット利用内容を表示し、“承認終了ボタン”を表示して押下を促す（図１６（１））。
　利用者が“承認終了ボタン”を押下すると（図１２、図２５ステップＳ４７、図１６（２））、利用者アプリケーション２１０Ａは、利用者に対してクローズ暗証コードの入力を要求するガイダンスを表示し（図１６（３））、利用者から暗証コード入力手段２３０を介して入力された“クローズ暗証コード”を得る（図１２ステップＳ４８）。ここでは生体情報として指紋情報が入力されるものとする（図１６（４））。
　なお、上記の図１０のトランザクション受付アプリケーションファイルのオープン処理から、図１１の各処理を経て、図１２のトランザクション受付アプリケーションファイルのクローズ処理の流れは、利用者端末２００Ａと金融取引制御システム１００との間でアクセスを維持したままでも良い。つまり、図１０、図２３で説明した利用者アプリケーション２１０Ａによるトランザクション受付アプリケーションファイルのオープン処理（ステップＳ３４～Ｓ３８）において確立した利用者アプリケーション２１０Ａとトランザクション受付アプリケーション１１１とのアクセスが維持されたままとし、図１１、図２４で説明した各処理を経て、図１２、図２５～図２６で説明する上記のトランザクション受付アプリケーションファイル１１２のクローズ処理を開始し、“承認終了伺い処理”の段階に進んだことをもって利用者が利用者端末２００を介して“承認終了情報”の入力、“クローズ暗証コード”の入力に進む形でも良い。

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

　認証に成功した場合、利用可否ステイタス情報状態制御手段１１０Ａは、与信管理部５２０が与信に基づいた場合の利用可否ステイタス情報５１０の設定が“有効状態”つまり“無効状態の設定ではない”か否かをチェックし（図１２、図２５ステップＳ５３）、与信管理部５２０の与信情報に基づく設定が“無効状態の設定ではない”場合には（図１２、図２５ステップＳ５３：Ｙ）、金融取引管理システム５００Ａは、利用可否ステイタス情報状態制御手段１１０Ａによる利用可否ステイタス情報５１０の切り替え制御を優先させて利用可否ステイタス情報５１０の切り替えを受け入れ、ステイタス情報切り替え処理を実行する（図１２、図２５ステップＳ５４）。

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

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

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

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

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

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

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

　実施例３として、実施例２の構成と処理に加えて、トランザクション受付アプリケーションファイルのオープン処理とクローズ処理の両方に暗証コードの入力を求めるというものである。
　実施例３にかかる金融取引制御システム１００Ａの構成は、実施例２で示した図９の構成と同様であるのでここでは説明を省略する。

　実施例３にかかる金融取引制御システム１００Ａは、少なくとも利用可否ステイタス情報状態制御手段１１０Ａ、暗証コード認証手段１２０Ａを備えている。
　利用可否ステイタス情報状態制御手段１１０Ａは、トランザクション受付アプリケーション１１１を備え、トランザクション受付アプリケーションファイル１１２を取り扱う。トランザクション受付アプリケーション１１１は常駐型でも良く、利用者端末２００の操作に応じて立ち上げられるものであっても良い。トランザクション受付アプリケーションファイル１１２はオンデマンドでオープン認証により生成・オープン処理が実行され、金融取引処理実行に伴ってクローズ認証により自動的にクローズ処理が実行される。

　本実施例３では、このトランザクション受付アプリケーションファイル１１２について、ファイルオープン時の認証に用いる“オープン暗証コード”と、ファイルクローズ時の認証に用いる“クローズ暗証コード”の２つの暗証コードが設定されている点が特徴となっている。
　利用可否ステイタス情報状態制御手段１１０Ａは、実施例１で説明した「無効デフォルト処理」を行うほか、本実施例２で説明した、トランザクション受付アプリケーション１１１によるクレジット利用/デビット利用時にオンデマンドによるトランザクション受付アプリケーションファイル１１２のオープン処理、利用可否ステイタス情報の有効化処理、金融取引処理、利用可否ステイタス情報の無効化処理、トランザクション受付アプリケーションファイル１１２のクローズ処理を実行するものであるが、トランザクション受付アプリケーションファイル１１２のオープン処理時にはオープン暗証コードによる認証処理、トランザクション受付アプリケーションファイル１１２のクローズ処理時にはクローズ暗証コードによる認証処理が実行される。

　次に、フローチャートおよび図面を参照しつつ、実施例３にかかる金融取引制御システム１００Ａの処理の流れの概略を示す。なお、実施例２に示した金融取引制御システム１００の処理の流れの概略と同様の部分については詳しい説明は省略することとする。
　実施例３の処理では、実施例２において図１０を参照して説明した処理の流れに比べて、トランザクション受付アプリケーション１１１によるトランザクション受付アプリケーションファイル１１２のオープン処理までの流れが異なるので、この部分について図１７のシステムブロック図、図１８の操作画面の例、図２７のフローチャートにより説明する。実施例２の処理と同様のものについては同じ処理ステップ番号を付して説明する。異なる処理については新たな処理ステップの番号を付している。

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

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

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

　金融取引制御システム１００Ａは、送信されてきた“金融取引利用リクエスト情報”を受け付けると、“オープン暗証コード”を抽出し、暗証コード認証手段１２０Ａに入力し、オープン暗証コードの認証処理を実行させる（図１７、図２７ステップＳ１０２）。暗証コード認証手段１２０Ａは、利用者アプリケーション２１０Ａから送信されてきた“オープン暗証コード情報”と、金融取引管理システム５００Ａ上で登録されている“オープン暗証コード情報”との認証処理を行い、認証処理に成功した場合は（図１７、図２７ステップＳ１０２：Ｙ）、利用可否ステイタス情報状態制御手段１１０Ａに認証成功を通知（図１７、図２７ステップＳ１０３）し、利用可否ステイタス情報状態制御手段１１０Ａは、実施例２と同様、図１０、図２３で説明した利用者アプリケーション２１０Ａによるトランザクション受付アプリケーションファイルのオープン処理（ステップＳ３４～Ｓ３８）を実行する。
　認証処理に失敗した場合は（図１７、図２７ステップＳ１０２：Ｎ、図１０中には図示せず）、利用可否ステイタス情報状態制御手段１１０Ａに認証不成立を通知し、金融取引処理を打ち切る（図１７、図２７ステップＳ１０４、図１７中には図示せず）。

　利用者は、実施例２と同様、クレジット利用開始ボタン押下した後、金融取引制御システム１００Ａ側においてトランザクション受付アプリケーションファイルのオープン処理が完了すれば、利用者端末２００Ａ上に“クレジット利用できます。”という表示がなされ（図１８（６））、クレジット利用を開始する。
　クレジット利用の各処理は、実施例２で説明したものと同様で良い（図１１～図１４、図２４～図２６））。

　このように、本実施例３の金融取引制御システム１００Ａの場合、トランザクション受付アプリケーションファイル１１２には、ファイルオープン用の暗証コードが設定されており、さらに編集後にファイルを正常にクローズさせるにもファイルクローズ用の暗証コードが設定されており、アプリケーションファイルを開く処理と、閉じる処理の２回にわたって暗証コードを要求するシステムは従来技術にはない。高いセキュリティと無効デフォルト処理の確実な実行が担保される。

　本発明にかかる金融取引制御システム１００の処理ステップをコンピュータプログラムとして記述されたものとして、コンピュータ読み込み可能な記憶媒体に担持させた形やコンピュータネットワークを介したダウンロードの形にて提供することができる。
　また、本発明にかかる金融取引制御システム１００を利用する利用者アプリケーション２１０も同様である。
　また、利用者アプリケーション２１０は、ＡＳＰとしてネットワーク経由で利用させることもできる。本発明にかかる金融取引制御システム１００を利用者端末２００上に構築する場合、金融取引制御システム１００をＡＳＰとしてネットワーク経由で利用させることもできる。

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

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

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

Claims (16)

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

Images