JP5670001B1 - 取引システム、取引方法、ならびに、情報記録媒体 - Google Patents

Abstract

取引システム(101)は、サーバ(121)と、第1端末(141)と、第2端末(161)と、を備える。ユーザは、第1端末(141)を介して第1認証が成功することにより、サーバ(121)にログインする。ユーザから、第1端末(141)を介して取引の指示を受け付けると、サーバ(121)は、第2端末(161)に伝達すべき通知を生成する。サーバ(121)から通知が伝達されると、第2端末(161)は、ユーザの第2認証を試みる。第2認証が成功すると、第2端末(161)は、ユーザに取引の詳細を提示する。取引の詳細が提示されたユーザにより、取引の確認がされると、サーバ(121)は、取引を実行する。

Description

本発明は、サーバへのログインに第1認証を要し、ログイン後に指示された取引の実行に第2認証を要する取引システムにおいて安全性を高めるのに好適な取引システムに関する。

従来から、サーバへのログインに第1認証を要し、ログイン後に指示された取引の実行に第2認証を要する取引システムが提案されている。たとえばインターネットバンキングにおいては、インターネット経由でコンピュータやスマートホンなどのアクセス端末を介してサーバにアクセスする際に、ユーザ名と第1パスワードを用いてログインし(第1認証)、ログイン後は、特段の認証を要せずに残高照会や取引履歴照会などができるものの、振込や振替、新たな定期預金の申込等の際には、第2パスワードを要する(第2認証)こととしているシステムが広く使われている。

第1認証や第2認証では、ユーザがあらかじめ定めたパスワードを利用することができる。また、ユーザに対してあらかじめ配布された乱数表から、抜き出す桝目の位置をサーバがユーザに指示し、ユーザがその桝目内の数字や文字を指定する、という手法を用いるものもある。また、アクセス端末を介して第1認証を行った後、これが成功すると、サーバが携帯電話に1回限りの取引パスワードを伝達し、第2認証では、アクセス端末にこの取引パスワードを入力してサーバに伝達させることで、取引を行うシステムも提案されている(特許文献1段落0033参照)。

特表2004-509409号公報

近年、アクセス端末で動作するブラウザに寄生して動作するコンピュータウィルスが、ユーザとサーバとのやりとりを監視して、たとえば、振込先や振込金額等の取引の内容を書き換えることにより、不正に金員を取得する攻撃が生じている。このような攻撃を、MITB(Man In The Browser)攻撃と呼ぶ。

MITB攻撃は、サーバとアクセス端末との間でやりとりされる取引の内容を、ユーザから見えないように書き換えるだけで達成できるため、第1認証と第2認証を単に組み合わせるだけでは、これを防止することが難しい。そこで、このような攻撃を、効果的に防止する技術が求められている。

本発明は、上記のような課題を解決するためのもので、サーバへのログインに第1認証を要し、ログイン後に指示された取引の実行に第2認証を要する取引システムにおいて安全性を高めるのに好適な取引システムを提供することを目的とする。

本発明に係る取引システムは、
サーバと、第1端末と、第2端末と、を備える取引システムであって、
前記第1端末を介して第1認証が成功することにより前記サーバにログインしたユーザから、前記第1端末を介して取引の指示を受け付けると、前記サーバは、前記第2端末に伝達すべき通知を生成し、
前記サーバから前記通知が伝達されると、前記第2端末は、前記ユーザの第2認証を試み、
前記第2認証が成功すると、前記第2端末は、前記ユーザに前記取引の詳細を提示し、
前記取引の詳細が提示された前記ユーザにより、前記取引の確認がされると、前記サーバは、前記取引を実行する
ように構成する。

本発明によれば、サーバへのログインに第1認証を要し、ログイン後に指示された取引の実行に第2認証を要する取引システムにおいて安全性を高めるのに好適な取引システムを提供することができる。

本発明の実施例に係る取引システムの概要を示す説明図である。 本発明の実施例に係る取引システムにおける情報のやりとりの様子を示す説明図である。 本発明の実施例に係るサーバにおける処理の流れを示すフローチャートである。 本発明の実施例に係る第1端末に表示されるログインフォームの表示例である。 本発明の実施例に係る第1端末に表示される振込フォームの表示例である。 本発明の実施例に係る第1端末に表示される待機フォームの表示例である。 本発明の実施例に係る第2端末に伝達される通知の表示例である。 本発明の実施例に係る第2端末にて起動する専用アプリケーションの認証フォームの表示例である。 本発明の実施例に係る第2端末にてリトライを求める認証フォームの表示例である。 本発明の実施例に係る第1端末にて取引が中止された旨を示す待機フォームの表示例である。 本発明の実施例に係る第2端末に表示される中止フォームの表示例である。 本発明の実施例に係る第1端末にて第2認証が成功した旨を示す待機フォームの表示例である。 本発明の実施例に係る第2端末に表示される確認フォームの表示例である。 本発明の実施例に係る第1端末にて取引が完了した旨を示す待機フォームの表示例である。 本発明の実施例に係る第2端末にて取引が完了した旨を示す完了フォームの表示例である。 本発明の実施例に係る第2端末に表示される確認フォームの表示例である。

以下に本発明の実施形態を説明する。なお、本実施形態は説明のためのものであり、本願発明の範囲を制限するものではない。したがって、当業者であればこれらの各要素もしくは全要素をこれと均等なものに置換した実施形態を採用することが可能であるが、これらの実施形態も本発明の範囲に含まれる。

図1は、本発明の実施例に係る取引システムの概要を示す説明図である。以下、本図を参照して説明する。

本実施形態に係る取引システム101は、サーバ121と、第1端末141と、第2端末161と、を備える。

サーバ121は、インターネットバンキング等のサービスを提供する。

第1端末141は、サーバ121に、コンピュータ通信網181を介して通信可能に接続され、ユーザがサーバ121にアクセスするために使用する。ユーザは、第1端末141を介して、サーバ121に第1認証によりログインする。典型的には、第1端末141としては、パーソナルコンピュータが採用されるが、スマートフォン等の携帯端末を利用しても良い。前者の場合には、第1端末141とサーバ121とは、光ケーブルなどを利用したインターネット接続プロバイダを介して接続される。

第2端末161は、サーバ121に、コンピュータ通信網181を介して通信可能に接続され、サーバ121にログイン済みのユーザが、第1端末141を介してサーバ121に指示した取引の内容を、ユーザが確認するために使用する。典型的には、第2端末161としては、スマートフォン等の携帯端末が採用されるが、パーソナルコンピュータ等を利用しても良い。前者の場合には、第2端末161とサーバ121とは、無線などを利用した携帯電話通信網を介して接続される。

本実施形態では、第1端末141と、第2端末161と、は、相互に通信できる必要はない。すなわち、第1端末141とサーバ121との間の通信に係る通信網と、第2端末161とサーバ121との間の通信に係る通信網と、は、上記のように、異なる通信経路を経ることが典型的である。ただし、第1端末141と、第2端末161と、は、ユーザが同時に手元に置いて利用することを想定しているので、両者が無線LANやBluetooth(登録商標)などにより相互通信できることがありうるほか、共通するゲートウェイを経由して、サーバ121と通信する場合もある。

このほか、第1端末141と、第2端末161と、は、異なる端末を用いるのが典型的であるが、用途によっては、同じ端末を利用しても良い。

図2は、本発明の実施例に係る取引システムにおける情報のやりとりの様子を示す説明図である。以下、本図を参照して説明する。なお、この説明では、第1認証にはユーザ名と第1パスワードを利用し、第2認証には第2パスワードを利用することを想定する。その他の態様については、後述する。

本図に示すように、まず、ユーザが、第1端末141にユーザ名と第1パスワードを入力すると(201)、第1端末141は、サーバ121へユーザ名と第1パスワードを送る(202)。サーバ121にて、ユーザ名と第1パスワードに対する第1認証が成功すると(203)、サーバ121からその結果が第1端末141に送られる(204)。

この後は、ユーザが、第1端末141を介して、残高照会や入出金履歴照会など、危険性が比較的低い低リスク手続を指示すると(205)、サーバ121にて、低リスク手続が実行され(206)、サーバ121からその結果が第1端末141に送られる(207)。

一方、ユーザが、第1端末141を介して、振込、振替、定期預金申込、各種金融商品購入などの取引のほか、パスワードやユーザ登録情報の変更など、危険性が比較的高い高リスク手続(取引)を指示すると(208)、サーバ121から、第2端末161へ、当該高リスク手続の内容を示す通知が伝達される(209)。

サーバ121から第2端末161へ通知を伝達するには、第2端末161にて動作するアプリケーションに対するプッシュ通知を採用することができるほか、携帯電話通信網を介したSMS(Short Message Service)や電子メールを利用する伝達を採用することもできる。

このほか、サーバ121が、通知の内容を、暗号化された文字列、1次元コード、2次元コードなどのコードを符号化して第1端末141の画面に表示し、ユーザが、第2端末161が備えるカメラ等を利用して画面に表示されたコードを撮影し、第2端末161が撮影されたコードから通知を得ることとしても良い。

第2端末161は、サーバ121から通知が伝達されると、ユーザに対して第2パスワードの入力を求める(210)。第2端末161とサーバが協働して第2パスワードに対する第2認証が成功すると(211)、第2端末161は、通知に指定された取引の内容を、第2端末161の画面に表示して(212)、ユーザに知らせる。

ユーザが、第2端末161の画面に表示された取引の内容を確認する入力を、第2端末161に対して行うと(213)、その旨がサーバ121に伝達され(214)、サーバ121にて、高リスク手続が実行され(215)、サーバ121からその結果が第1端末141に送られる(216)。

また、高リスク手続が実行されると、その結果が第2端末161にも送られ(217)、ユーザに取引の内容を予告する表示を消去して、実行された取引の結果を表示することとする。

本実施例では、ユーザが第2端末161に入力した第2パスワードが、サーバ121へと送られ、サーバ121において第2認証が行われる。従来のインターネットバンキングにおいては、1台のアクセス端末から第1パスワードと第2パスワードを入力することとするのが通例であったが、本態様では、異なる端末から第1パスワードと第2パスワードを入力することから、一方の端末がコンピュータウィルスに侵されていたとしても、MITB攻撃による被害をできるだけ防止することができる。

なお、第2パスワードとしては、あらかじめユーザとサーバ121の間で定められた文字列や記号列を採用しても良いし、ワンタイムパスワードを採用しても良い。

ワンタイムパスワードの態様としては、(1)まず、サーバ121の運営者からユーザに配布された乱数表(各桝目には、数字や文字、図形等の符号が記入されている)からいずれの桝目を抜き出すか、を、第1端末141もしくは第2端末161の画面にてユーザに指示し、抜き出された乱数表内の符号を並べた文字列を、第2端末161にて入力する手法が考えられる。(2)このほか、サーバ121がワンタイムパスワードを第1端末141の画面に表示し、ユーザが第2端末161から当該表示されたワンタイムパスワードを入力することとしても良い。(3)さらに、サーバ121が第1端末141の画面に乱数表を表示し、ユーザは、自身に割り当てられた抜き出し規則に基づいて桝目から符号を抜き出し、抜き出された乱数表内の符号を並べた文字列を、第2端末161にて入力する手法を採用することもできる。

本実施例では、第2認証が成功するまで、取引の内容は、第2端末161の画面には表示されない。したがって、第2端末161を紛失したり盗難に合った場合に、それに気付かずに高リスク手続を開始した場合であっても、取引の内容が漏洩しない、という利点がある。

本実施例において、第2端末161の画面に表示されたこれから行おうとする取引の内容を見たユーザは、これを実行しても良ければ、確認の指示を行う。最も単純な確認の手法は、取引を実行するためのオブジェクト(画面に表示されたボタンやリンク等)をタップやクリックしたり、リターンキーを押圧操作する等である。

上記のように、本実施例では、第2認証に際して、ユーザが第2パスワードの入力を行うが第2認証には、種々の変形がありうる。また、本実施例では、取引の内容とともに画面に表示されたボタンやリンク等をタップやクリックする等により、取引の実行に対するユーザの確認をとっているが、確認にも種々の変形がありうる。これらの変形例については後述する。

さて、インターネットバンキング等においては、サーバ121は、ウェブサーバとして機能し、第1端末141では、サーバ121にアクセスするためのブラウザプログラムが動作する。本実施例においては、第1端末141は、従来のブラウザをそのまま利用することができる。そこで、以下では、サーバ121が第1端末141や第2端末161と協働する処理の流れについて説明する。

図3は、本発明の実施例に係るサーバにおける処理の流れを示すフローチャートである。以下、本図を参照して説明する。本図に示すサーバ処理は、サーバ121がサーバ用プログラムを実行することによって実行される。また、これに呼応して、第1端末141ではブラウザのプログラムが実行され、第2端末161では、専用アプリケーションのプログラムが実行される。

ここで、各プログラムは、コンパクトディスク、フレキシブルディスク、ハードディスク、光磁気ディスク、ディジタルビデオディスク、磁気テープ、ROM(Read Only Memory)、EEPROM(Electrically Erasable Programmable ROM)、フラッシュメモリ、半導体メモリ等のコンピュータ読み取り可能な非一時的(non-transitory)情報記録媒体に記録することができる。この情報記録媒体は、サーバ121、第1端末141、第2端末161を構成するコンピュータとは独立して配布・販売することができる。

一般には、コンピュータは、非一時的(non-transitory)情報記録媒体に記録されたプログラムを、一時的(temporary)記憶装置であるRAM(Random Access Memory)に読み出してから、CPU(Central Processing Unit)あるいはプロセッサが読み出されたプログラムに含まれる指令を実行する。ただし、ROMとRAMを一つのメモリ空間にマッピングして実行することが可能なアーキテクチャでは、ROMに格納されたプログラムに含まれる指令を、直接CPUが読み出して実行する。

さらに、上記のプログラムは、プログラムが実行されるコンピュータとは独立して、コンピュータ通信網等の一時的(transitory)伝送媒体を介して、配布装置等から、サーバ121、第1端末141、第2端末161等へ配布・販売することができる。上記のように、サーバ121、第1端末141、第2端末161等では、CPUあるいはプロセッサ等がRAM等と協働して、NIC(Network Interface Card)やディスプレイ、マイク、スピーカなどを制御する。

まず、サーバ121は、種々の初期化を行ってから(ステップS301)、コンピュータ通信網を介して送られてきたパケットを受信し(ステップS302)、その内容を調べる(ステップS303)。

サーバ121にて受信されたパケットが、第1端末141から送信されたアクセス要求であれば(ステップS303;アクセス要求)、ユーザ名とパスワードを入力するためのログインフォームを、第1端末141へ送信して(ステップS304)、ステップS302に戻る。なお、アクセス要求は、第1端末141で動作するブラウザにおいて、ユーザがサーバ121のURL(Universal Resource Locator)を指定することにより、第1端末141からサーバ121へ送信される。

第1端末141で動作するブラウザは、ログインフォームを受信すると、これを画面に表示する。図4は、本発明の実施例に係る第1端末に表示されるログインフォームの表示例である。以下、本図を参照して説明する。

ログインフォーム401には、ユーザ名欄402と、パスワード欄403と、ログインボタン404と、が、が用意されている。ユーザが、自身の口座に割り当てられたユーザ名をユーザ名欄402に入力し、パスワード欄403をログイン用パスワードに入力してから、ログインボタン404をクリックすると、第1端末141からサーバ121へログイン要求が送信される。

さて、サーバ121にて受信されたパケットが、第1端末141から送信されたログイン要求であれば(ステップS303;ログイン要求)、ログイン要求に指定されたユーザ名とパスワードにより、第1認証を試みる(ステップS305)。第1認証が失敗すれば(ステップS305;失敗)、サーバ121は、ログインに失敗した旨のエラー応答を第1端末141に送信して(ステップS306)、ステップS302に戻る。

一方、第1認証が成功すれば(ステップS305;成功)、サーバ121は、残高照会、取引履歴照会などの低リスク手続や、振込、振替、定期預金の申込、金融商品の申込、パスワードの変更などの高リスク手続などへのリンクが配置された開始フォームを、第1端末141へ送信し(ステップS307)、ステップS302へ戻る。

開始フォームを受信した第1端末141は、ブラウザ画面にこれを表示し、ユーザに所望の手続を選択させる。すると、選択された手続に応じた要求が、第1端末141からサーバ121へ送信される。

たとえば、ユーザが、開始フォームから振込のリンクを選択したとする。すると、振込フォームが生成されて、第1端末141へ送信される。

振込フォームの生成および送信は、取引自体の実行をともなわない単なるページ遷移に相当するので、低リスク手続と考えることができる。

一般に、サーバ121にて受信されたパケットが、第1端末141から送信された低リスク手続要求であれば(ステップS303;低リスク手続要求)、サーバ121は、当該要求に応じた低リスク手続を実行して(ステップS308)、その結果フォームを、第1端末141へ送信し(ステップS309)、ステップS302に戻る。なお、結果フォームには、その後に各種処理を実行するためのリンクが配置されている。

さて、第1端末141に振込フォームが送信されると、第1端末141のブラウザは、画面に振込フォームを表示する。図5は、本発明の実施例に係る第1端末に表示される振込フォームの表示例である。

振込フォーム411には、振込先を指定するための、銀行名欄412、支店名欄413、口座種類欄414、口座番号欄415、口座名義人名称欄416、振込金額欄417、実行ボタン418が配置されている。ユーザが、振込先情報を各欄412-417に入力した後に、実行ボタン418をクリックすると、第1端末141からサーバ121へ、振込要求が送信される。この振込要求は、高リスク取引である。なお、本例では、振込先情報を1つのフォームにて入力しているが、複数の順序付けられたページ遷移によって、順次振込先情報を順次入力することとしても良い。また、銀行名欄412、支店名欄413、口座種類欄414、口座番号欄415が入力されたら、当該口座の名義人名称をサーバ121がデータベースから取得して、口座名義人名称欄416を補完することにより、ユーザの直接入力を省略することとしても良い。このほか、あらかじめ登録した振込先を簡易に選択するためのリストボックスを用意するなどにより、ユーザの入力を助けることとしても良い。

MITB攻撃では、ここで送信される振込要求の内容を書き換えて、攻撃者の口座に送金がされるようにするのである。

さて、サーバ121にて受信されたパケットが、第1端末141から送信された高リスク手続要求であれば(ステップS303;高リスク手続要求)、サーバ121は、高リスク手続要求に指定された手続(取引)に対して取引IDを割り当てて、取引IDと取引の内容とを示す通知を生成する(ステップS310)。取引IDは、ユーザが指定した高リスク手続に紐付けられており、サーバ121は、取引IDにより、当該高リスク手続を指定したユーザが誰であるか、当該高リスク手続の要求に使われた第1端末141はどの端末か、当該高リスク手続の進捗状況はどの段階であるか、などの情報を管理する。

そして、サーバ121は、第1端末141に対して、高リスク手続要求に指定された手続(取引)の内容および取引IDを示す待機フォームを、第1端末141に送信する(ステップS311)。

さて、第1端末141のブラウザは、待機フォームを受信すると、これを画面に表示する。図6は、本発明の実施例に係る第1端末に表示される待機フォームの表示例である。

本図に示すように、待機フォーム421では、取引内容欄422内に、サーバ121が受け付けた高リスク手続の内容が表示されている。また、進捗状況欄423内に、第2認証待機中である旨が表示されている。

サーバ121は、高リスク手続の進捗状況が変化すると、その旨を、第1端末141に送信する。第1端末141では、待機フォーム421に指定されたスクリプトが、サーバ121から進捗状況の報告が送信されることを待ち受けており、報告が受信されると、進捗状況欄423に新たな状況を表示する。当該スクリプトにおいても、取引IDが仕様される。

さらに、待機フォーム421には、中止ボタン424が用意されている。第2端末161を介した第2認証および確認がされる前に、中止ボタン424をユーザが操作すると、その旨の要求が第1端末141からサーバ121へ送信され、サーバ121では、当該取引IDに係る取引の中止を、低リスク手続として実行する。具体的には、当該取引IDによる取引が中止された旨を、取引IDに紐付けてデータベース等に記録する。その結果を示す結果フォームが、サーバ121から第1端末141へ送られて、第1端末141のブラウザが当該結果フォームを画面に表示する。

なお、MITB攻撃では、待機フォーム421に表示される取引内容欄422の内容が、攻撃者の口座等に変更されて表示されている場合もあるし、元の振込先の情報に改変されている場合もある。しかしながら、本実施例では、第1端末141からサーバ121に指示された取引の内容が、そのまま、第2端末161にも伝達される。

引き続き、サーバ121は、第1端末141からログインしているユーザに対してあらかじめ登録されている第2端末161の宛先情報をデータベースから取得して(ステップS312)、当該第2端末161へ、生成された通知を伝達して(ステップS313)、ステップS302に戻る。

通知の伝達には、第2端末161にて動作する専用アプリケーションに対するプッシュ通知を採用することができる。プッシュ通知が第2端末161に到着すると、典型的には、第2端末161のオペレーティングシステムが用意している通知領域が自動的にポップアップ等してその旨が表示される。図7は、本発明の実施例に係る第2端末に伝達される通知の表示例である。本図に示す例では、第2端末161のホーム画面431内に、高リスク手続に関する通知が到着した旨の通知432が表示される。

さて、第2端末161のホーム画面431内に表示された通知432をユーザがタップあるいはクリックしたり、通知センターにて通知の一覧を表示して、当該通知432をタップあるいはクリックしたり、通知に係る専用アプリケーションのアイコンをタップあるいはクリックすると、当該専用アプリケーションが起動される。また、第2端末161の仕様によっては、通知が到着すると、自動的に専用アプリケーションが起動するように設定することも可能である。

このほか、第2端末161に割り当てられたSMSやメールアドレスなどに、上記専用アプリケーションと同様の機能を果たすウェブアプリケーションへのURLを送信することとしても良い。この態様では、ユーザが当該URLを選択すると、第2端末161のブラウザが起動されて、ウェブアプリケーションが実行されることになる。

なお、サーバ121が、通知の内容を、暗号化された文字列、1次元コード、2次元コードなどのコードを符号化して第1端末141の待機フォーム421に表示し、ユーザが、専用アプリケーションを起動して、第2端末161が備えるカメラ等を利用して、待機フォーム421に表示されたコードを撮影することで、第2端末161が撮影されたコードから通知を得ることとしても良い。

さて、通知が伝達された第2端末161にて専用アプリケーションが起動すると、第2端末161の画面には、認証フォームが表示される。図8は、本発明の実施例に係る第2端末にて起動する専用アプリケーションの認証フォームの表示例である。

本図に示すように、認証フォーム441には、パスワード欄442と認証ボタン443が用意されているほか、メッセージ欄444には、第2認証のためのパスワードを入力すべき旨の指示が表示されている。ユーザがパスワード欄442に取引用パスワードを入力して、認証ボタン443をタップあるいはクリックすると、第2端末161からサーバ121へ取引IDおよび取引用パスワードが指定された認証要求が送信される。

サーバ121にて受信されたパケットが、第2端末161から送信された認証要求であれば(ステップS303;認証要求)、サーバ121は、第2認証を試みる(ステップS314)。第2認証では、以下の情報が精査される。
(1)認証要求に指定されている取引IDに係る高リスク手続が続行中であるか(中止されていないか)。
(2)当該取引IDに係る送信元の第2端末161に対して、通知を送信しているか。
(3)認証要求に指定された取引用パスワードが、当該取引IDに係る高リスク手続を指定したユーザのパスワードとして正当なものであるか。

これらがいずれも成立すれば、第2認証が成功したことになる。第2認証が失敗し、その失敗が連続して閾回数未満であれば(ステップS314;閾回数未満失敗)、サーバ121は、第2端末161に対して、ユーザに取引用パスワードの再入力をするよう指示して(ステップS315)、ステップS302に戻る。

図9は、本発明の実施例に係る第2端末にてリトライを求める認証フォームの表示例である。第2端末161の認証フォーム441では、サーバ121から再入力を求められた旨が、メッセージ欄444に表示されており、ユーザは、再度取引用パスワードの入力を行うことができる。

第2認証が失敗し、その失敗が連続して閾回数以上であれば(ステップS314;閾回数以上失敗)、サーバ121は、第1端末141および第2端末161に対して、当該取引の中止を連絡して(ステップS316)、ステップS302に戻る。

第1端末141では、中止の連絡を受信したスクリプトが、待機フォーム421の表示を更新する。図10は、本発明の実施例に係る第1端末にて取引が中止された旨を示す待機フォームの表示例である。本図に示すように、待機フォーム421の進捗状況欄423内には、取引が中止された旨が表示されており、中止ボタン424が隠され、かわりに了解ボタン425が表示されている。了解ボタン425をユーザが操作すると、ブラウザは、開始フォーム等に遷移する。

第2端末161では、専用アプリケーションが中止の連絡を受信すると、画面表示が更新され、中止フォームが表示される。図11は、本発明の実施例に係る第2端末に表示される中止フォームの表示例である。本図に示すように、中止フォーム451のメッセージ欄452には、取引が中止された旨が表示される。また、了解ボタン453をタップすると、メッセージ欄452の内容が消去され、専用アプリケーションの管理フォーム等が表示される。

一方、第2認証が成功すると(ステップS314;成功)、サーバ121は、第1端末141および第2端末161に対して、認証成功の旨を報告して(ステップS317)、ステップS302に戻る。

第1端末141では、第2認証の成功の報告を受信したスクリプトが、待機フォーム421の表示を更新する。図12は、本発明の実施例に係る第1端末にて第2認証が成功した旨を示す待機フォームの表示例である。本図に示すように、待機フォーム421の進捗状況欄423内には、第2認証は成功しており、第2端末161におけるユーザの確認待ちであることが表示される。

一方、第2端末161では、専用アプリケーションが認証成功の報告を受信すると、表示が認証フォームから確認フォームに切り替わる。図13は、本発明の実施例に係る第2端末に表示される確認フォームの表示例である。本図に示すように、確認フォーム461では、メッセージ欄462に、今回の取引の内容の詳細が表示される。取引の内容の詳細は、先に受信された通知により、第2端末161では、既に取得されている。そこで、認証成功の報告に指定された取引IDと受信済みの通知の内容とを照合することで、メッセージ欄462に高リスク手続の内容を表示することができる。

このほか、通知自体には高リスク手続の内容は指定せず、第2認証が成功してから、サーバ121から第2端末161に伝達される成功の報告に、高リスク手続の内容を指定することとしても良い。

このほか、確認フォーム461には、確認ボタン463が用意されている。ユーザが確認ボタン463をタップあるいはクリックすると、第2端末161からサーバ121へ、取引IDを指定する確認要求が送信される。

なお、取引の内容に誤りがあった場合には、第1端末141のブラウザに表示されている待機フォーム421で中止ボタン424を操作すれば良い。ただし、確認フォーム461に別途中止ボタンを設けて、これをユーザがタップ等すると、取引が中止されるように構成しても良い。

さて、サーバ121にて受信されたパケットが、第2端末161から送信された確認要求であれば(ステップS303;確認要求)、サーバ121は、当該確認要求の整合性を検査する(ステップS318)。具体的には、以下のような事項が検査される。
(1)確認要求に指定されている取引IDに係る高リスク手続が続行中であるか(中止されていないか)。
(2)確認要求の送信元の端末が、当該取引IDについての第2認証を成功させた第2端末161であるか。

確認要求が、この検査をパスしなければ(ステップS318;失敗)、取引を続行できないことになるので、制御はステップS316に進み、取引が中止される。

一方、確認要求がこの検査をパスすれば(ステップS318;成功)、サーバ121は、高リスク手続を実行する(ステップS319)。すなわち、本実施例では、取引IDに紐付けられた振込送金が行われることになる。また、取引IDに紐付けられる取引の進捗状況は、完了済に更新される。

そして、サーバ121は、第1端末141および第2端末161に対して、取引完了の旨を報告して、(ステップS320)、ステップS302に戻る。

第1端末141では、取引完了の報告を受信したスクリプトが、待機フォーム421の表示を更新する。図14は、本発明の実施例に係る第1端末にて取引が完了した旨を示す待機フォームの表示例である。本図に示すように、待機フォーム421の進捗状況欄423および取引内容欄422には、取引が完了した旨が表示される。また、取引が完了したので、中止ボタン424が隠され、かわりに了解ボタン425が表示されている。了解ボタン425をユーザが操作すると、ブラウザは、開始フォーム等に遷移する。

一方、第2端末161では、専用アプリケーションが認証成功の報告を受信すると、表示が確認フォームから完了フォームに切り替わる。図15は、本発明の実施例に係る第2端末にて取引が完了した旨を示す完了フォームの表示例である。完了フォーム471では、履歴欄472にこれまでに完了した取引の履歴がスクロール可能に表示されている。また、了解ボタン473をタップすると、専用アプリケーションの管理フォーム等が表示される。

なお、第2端末161で動作する専用アプリケーションは、サーバ121から通知が伝達されると、画面に表示されるフォームを、自動的に認証フォーム441に切り替えることとするのが望ましい。なお、専用アプリケーションが、複数のサーバ121における通知に対応する場合には、サーバ121ごとにタブを用意して、一連のフォームによる処理をサーバ121ごとに切り替えられるようにすれば良い。

さて、サーバ121にて受信されたパケットが、その他の種類のパケットであれば(ステップS303;その他)、サーバ121は、対応する処理を実行して(ステップS321)、ステップS302に戻る。

このように、本実施例では、ログインに係る第1認証は、サーバ121にユーザがアクセスするための第1端末141から行われ、高リスク手続(取引)に係る第2認証は、サーバ121から通知が伝達された第2端末161から行われる。そして、第2認証が成功してから、第2端末161に取引の内容がユーザに提示され、内容を第2端末161にて確認した後に、取引が実行される。

このため、MITB攻撃を受けた場合であっても、MITB攻撃が生じることがない経路を介してユーザに取引の内容が伝達されるので、被害を防止することができる。

また、本実施例では、第2認証において、第2端末161からパスワードを入力することを要する。したがって、第2端末161が紛失、盗難されていることに気付かずに、取引を開始しようとした場合であっても、第2端末161の拾得者に、取引の内容が漏洩することがない。

なお、ユーザが第2端末161にて入力した情報により、第2認証が行われているから、取引の確認は、必ずしも第2端末161から行う必要はなく、第1端末141にて行ってもよい。この場合には、後述するように、第2端末161にて表示される取引の内容をユーザが吟味することを促す技術と組み合わせるのが好適である。

さて、上記の説明では、サーバ121、第1端末141、第2端末161の動作の理解を容易にするため、たとえばエラーが生じた場合の処理等については、適宜省略している。しかしながら、システムの設計やサイトの構成に応じて、これらの動作や制御の流れを、適宜変更することが可能である。

上記実施例では、ユーザが第2端末161において第2パスワードが入力し、第2認証が成功するまで、高リスク手続の内容は、第2端末161の画面には表示されないこととしていた。本実施例は、第2認証を自動化するものである。

本実施例では、サーバ121が通知の内容を暗号化し、第2端末161が暗号化された通知の復号を試みて、これに成功した場合には、第2認証が成功したものとみなす。この態様では、第2端末161は、認証用トークンとして機能することとなる。

本実施例では、暗号システムとして、サーバ121と第2端末161とが、時刻同期する共通鍵をそれぞれ生成する態様を採用することができる。すなわち、サーバ121では、サーバ121が生成した共通鍵により通知を暗号化する。暗号化から当該共通鍵の有効期限が切れるまでに、暗号化された通知が第2端末161に伝達されると、第2端末161は、第2端末161が生成した共通鍵により暗号化された通知を復号する。

このほか、本実施例に対して、公開鍵暗号を採用することもできる。すなわち、ユーザは、通知先とする第2端末161により、公開鍵と秘密鍵のペアを生成する。そして、第2端末161をサーバ121に登録する際に、その公開鍵をサーバ121に伝達する。サーバ121では、通知を送る際には、公開鍵で暗号化し、第2端末161では、暗号化された通知を、秘密鍵で復号する。

なお、時刻同期暗号には、サーバ121と第2端末161でシードを共有する必要があるが、一方から他方へシードを伝達する際には、公開鍵暗号を利用することで、よりセキュリティを向上させることができる。

なお、上記の態様では、第2認証は自動的に実行され、第2パスワードは必ずしも必要とされないが、そこで、ユーザによる認証を十分に行うために、第2パスワードを利用することとしても良い。

すなわち、第2認証が成功し、高リスク手続の内容が第2端末161の画面に表示された後に、第2端末161は、ユーザに対して取引パスワードの入力を求める。

そして、第2端末161とサーバ121が協働して、入力された取引パスワードによる認証(第3認証)を行う。第3認証が成功すれば、ユーザによる取引の確認がされたものとみなして、サーバ121は、取引を実行する。

この態様は、見かけ上は、現在広く用いられているインターネットバンキングの態様に類似するが、本態様では、取引の内容がサーバ121において暗号化され、第2端末161にて復号されるので、第1端末141に対するMITB攻撃を無効化できる。すなわち、ユーザは、第1端末141にて自身が入力した振込先や振込金額等の情報と、第2端末161にて表示される振込先や振込金額等の情報と、が、一致していなければ、何らかの攻撃があったものと判定することができる。

MITB攻撃を抑制するためには、第2認証が成功した後に第2端末161の画面に表示される高リスク手続(取引)の内容を、ユーザが十分に吟味する必要がある。

すなわち、ユーザは、第1端末141にて入力した高リスク手続の内容と、第2端末161にて表示される高リスク手続の内容と、が、一致しているか否かを確認する必要がある。したがって、両者の対比を促すことが、MITBその他の攻撃による被害を抑制する上で望ましい。本実施例は、第2端末161にて表示される取引の内容を、ユーザが十分に確認するよう促す。本実施例は、第2認証が自動的に行われる態様において、取引パスワードによる確認のかわりに利用することもできる。

図16は、本発明の実施例に係る第2端末に表示される確認フォームの表示例である。以下、本図を参照して説明する。

本図に示す確認フォーム461では、メッセージ欄462に、今回の取引の内容の詳細が表示されているが、その一部が伏せ字になっている。伏せ字にする部分は、振込先の口座名義人の名前、銀行名、支店名、口座番号などの文字や数字の一部のいずれでも良い。また、本実施例では、伏せ字にする箇所は、第2端末161がランダムに決定する。

そして、確認ボタン463にかえて、複数の選択肢ボタン464が用意されている。

本図に示す例では、振込先の口座名義人の名称の一文字が伏せ字(本図では「*」で表現されている)になっており、選択肢ボタン464には、その伏せ字に対する回答が列挙されている。ここで提示される選択肢ボタン464には、正解が1つ含まれるほか、誤答が複数用意されている。

ユーザは、自身が行おうとする取引の内容を知得しているはずであるから、伏せ字にされた部分を充填することは容易なはずである。また、MITB攻撃によって振込先の書き換えが起きていても、伏せ字にされた部分を吟味しようとするので、十分な吟味が可能であり、攻撃に容易に気付くことができる。

ユーザが、複数の選択肢ボタン464から正解を選ぶと、第2端末161は、ユーザによる確認がされたものとみなして、サーバ121に確認要求を送信する。また、不正解であれば、取引の内容をもう一度見直すよう警告が表示された上で、再度同じ確認フォーム461における入力が求められる。

なお、選択肢ボタン464を使うのではなく、ユーザが伏せ字にされた部分を入力するためのテキストフィールドやリストボックスなどを用意するとともに、確認ボタン463を設けることとしても良い。この場合には、ユーザが正解を選択した上で、確認ボタン463が操作されれば、サーバ121に確認要求を送信する。

また、上記の説明では、確認のための入力は、第2端末161で行われているが、第1端末141で行うこととしても良い。本実施例では、伏せ字にされた部分をユーザに補充させることで、第2端末161において表示された取引の内容をユーザが吟味したことが保証されるからである。この態様では、第2端末161にてランダムに伏せ字箇所を決めた場合には、第2端末161からサーバ121に正解を伝える、あるいは、第1端末141にて入力された回答を、サーバ121を経由して第2端末161に伝達して、第2端末161に判定させる、などの手法を採用することができる。

このほか、上記の説明では、セキュリティを向上させる観点から、ログイン時の第1認証と取引実行時の第2認証の2種類を採用している。しかしながら、専用のアプリケーションを用いずに、従来から利用されている携帯電話宛メールを介した取引システムなどに適用する場合には、取引実行時の第2認証を省略したり、第2認証のタイミングをずらしたり、ユーザの確認のための入力を与える先を携帯電話以外とすることも可能である。

すなわち、ユーザは、第1端末141を介してサーバ121にログインし、サーバ121が、第1端末141を介して前記ユーザから取引の指示を受け付けると、サーバは、第2端末に伝達すべき通知を生成する。

この通知には、取引の内容(たとえば、振込先の名義人名称、銀行名、支店名、口座の種類名、口座番号、振込金額)の詳細が指定されるが、その一部を伏せ字にする。たとえば、振込先銀行「ABC銀行」支店名「DEF店」口座種類「GHI口座」口座番号「JKL」名義人「MNOP QRS」振込金額「TUVWXYZ円」の取引を行おうとしたときに、伏せ字にする箇所(以下では「*」で表す)をランダムに決めて、以下のような取引内容を生成する。

「A*C銀行*EF店GHI口座、口座番号*KL、名義人M*OP QR*にTUV*XYZ円を振り込もうとしています。この振込が正しければ、*により伏せ字になっている部分の文字・数字を並べた確認コードを、インターネットバンキングにログインしている端末から入力してください。」

伏せ字にする箇所は、1つでも良いし、複数でも良い。また、あらかじめ定めた箇所(たとえば、口座番号の下4桁)を必ず伏せ字にすることとしても良いし、ランダムに決めることとしても良い。

そして、サーバ121は、ユーザに割り当てられた第2端末161に、電子メールもしくはSMSにより、伏せ字により一部が伏せられた取引の内容を指定した通知を送信する。

通知を受信した第2端末161に表示された取引の内容を見たユーザは、伏せ字にされた箇所を埋めるべき文字、数字、記号を、先頭から順に並べて、これを確認コードとする。上記の例では、確認コードは「BDJNSW」となる。

そして、ユーザが、確認コードを、第1端末141に入力する。サーバ121は、第1端末141から入力された確認コードが、通知を生成した際に伏せ字にした部分の文字や数字を並べた列と一致するのであれば、ユーザが、取引を実行することを了承する確認があったものとみなす。最も単純には、確認があれば、それだけで、取引を実行しても良い。すなわち、取引パスワードによる第2認証を省略することも可能である。通知の一部が伏せ字になっているため、たとえば、伏せ字にする箇所を口座番号から必ず選ぶこととすれば、口座番号という情報の漏洩を防止することができるからである。

また、上記のように、伏せ字から得た確認コードを用いるとともに、第1端末141や第2端末161を介してユーザに取引パスワードの入力をさせて、さらなる認証を行ってから、取引を実行することとしても良い。

第2端末161にて通知を見たユーザが、MITB攻撃等により振込先が改変されていることに気付いた場合には、第1端末141から中止ボタン424を操作する等により、振込を中止することができる。取引に覚えがない場合には、ログインのためのユーザ名やパスワードが漏洩している可能性があるため、サーバ121の管理者に連絡をとることになる。

従来から、あらかじめユーザに配布された乱数表の中から抜き出す位置をサーバ121が指定して、その位置の文字や数字を入力することにより、認証を行うシステムは提案されている。しかしながら、本態様では、取引の内容に応じて乱数表に相当する抜き出しの対象の文字列が動的に変化するため、固定された乱数表よりもセキュリティを向上させることができる。また、伏せ字から確認コードを得るためには、ユーザが取引の内容を精査することが必須となるため、よく内容を調べずに取引を実行してしまう不注意を抑制することができ、MITB攻撃も効果的に防止することができる。

以下では、上記各実施例にかえて、あるいは、加えて、適用可能な種々の技術について説明する。

(登録の手順)
上記の各実施例においては、第2端末161として、ユーザが自身のアカウントに対応付けてあらかじめサーバ121に登録した端末を利用することを想定している。登録には、以下のような手順を採用することができる。

まず、ユーザは、口座契約時に、自身の連絡先電話番号を登録しておく。そして、自身の口座に紐付けたい新たな第2端末161にて専用アプリケーションを動作させ、ユーザ名とログインパスワードを入力する。

専用アプリケーションからサーバ121へのログインが成功したら、サーバ121は、当該ユーザの連絡先電話番号に対して架電し、登録用の認証コードを音声により伝える。

ユーザが新たな第2端末161の専用アプリケーションから、認証コードを入力すると、サーバ121にて照合が行われ、これが合致していれば、新たな第2端末161が通知先として、当該ユーザのアカウントに紐付けられる。

(ワンタイムパスワード)
第1認証の手法として、ユーザに割り当てられている第2端末161における専用アプリケーションをあらかじめ起動しておくことを必要条件とする態様がある。

すなわち、第2端末161における専用アプリケーションは、起動時にサーバ121にアクセスし、自身が動作していることをサーバ121に通知する。サーバ121は、第1端末141からログイン要求があると、指定されたユーザ名に対応付けられる第2端末161において、専用アプリケーションが動作しており、かつ、ログイン要求に指定されたパスワードが正当である場合に、第1認証を成功させ、ユーザによるログインを認める。

この態様では、ログインパスワードとして固定のものを採用することができるほか、第2端末161の専用アプリケーションがサーバ121にアクセスした時点で、サーバ121から乱数表を取得し、ユーザが乱数表の中から、ユーザに割り当てられた抜き出しルールに基づいて桝目の中身を抜き出したワンタイムパスワードを得て、これをログインパスワードとすることもできる。

この態様では、ユーザが取引を実行しようとする際には、第2端末161にて専用アプリケーションが動作済みであるから、上記実施例のように、サーバ121は、通知を送る際にも、第2端末161で動作済みの専用アプリケーションに送信すれば良いことになる。

取引パスワードや、取引の確認のための入力は、上記のように、第2端末161から行っても良いし、第1端末141から行っても良い。

本態様によれば、ユーザに、通知用の端末を複数割り当てることができる。通知用の端末のいずれかを第2端末161として使用したい場合には、その端末にて、専用アプリケーションを動作させ、サーバ121にアクセスしてから、第1端末141経由でログインを開始すれば良い。

この態様では、ある通知用端末(たとえば、日頃よく使用する携帯電話通信網に接続可能な携帯電話)が紛失・盗難に合った場合でも、他の通知用端末(たとえば、Wifi接続のみ可能なタブレット端末)により第2認証を行うことで、紛失・盗難に合った通知用端末の登録を解除することができる。

(伏せ字による認証)
上記実施例では、伏せ字による認証では、当該伏せ字にされた元の文字・数字を確認コードとしてユーザに入力させることとしていたが、確認コードとして、正解の選択肢に割り当てられたランダムな文字列を採用することもできる。
たとえば、上記の振込先の例で、常に、口座番号の下2桁を伏せ字とする態様では、以下のような通知が送られる。

「ABC銀行DEF店GHI口座、口座番号J**、名義人MNOP QRSにTUVWXYZ円を振り込もうとしています。この振込が正しければ、**により伏せ字になっている部分を以下の3つの選択肢から選び、その選択肢の確認コードを、入力してください。
** が AB ならば、確認コードは531338、
** が KL ならば、確認コードは123456、
** が QR ならば、確認コードは789012」

正解は、KLであるから、確認コードは、123456となる。

一般に、伏せ字にする部分が銀行名や支店名、名義人名称などの場合には、伏せ字にされる文字が、英字やカナ、漢字などの入力が比較的難しい文字となることがありうる。本態様では、確認コードは、サーバ121が生成するので、第1端末141や第2端末161において入力が容易な字種(たとえば上記のように、数字のみ)からなるように構成することができ、ユーザの利便を図ることができる。

携帯電話で構成される第2端末161に通知が電子メールで送られ、確認コードを第1端末141に入力するような場合に、単にサーバ121から1つの確認コードを送る態様では、MITB攻撃を防ぐことは難しく、取引の内容を一緒に送ったとしても、その内容をユーザが精査しなければ、MITB攻撃が成功してしまうことがある。しかしながら本体用では、ユーザに取引の内容を精査させることになるので、確認コードの入力先が第1端末141と第2端末161のいずれであっても、MITB攻撃を効果的に防止することが可能である。

上記実施形態は、適宜その要素の一部のみを利用したり、実施例を組み合わせて利用したりすることができ、それらの実施態様も、本発明の技術的範囲に含まれる。

本発明によれば、サーバへのログインに第1認証を要し、ログイン後に指示された取引の実行に第2認証を要する取引システムにおいて安全性を高めるのに好適な取引システムを提供することができる。

101 取引システム
121 サーバ
141 第1端末
161 第2端末
181 コンピュータ通信網
401 ログインフォーム
402 ユーザ名欄
403 パスワード欄
404 ログインボタン
411 振込フォーム
412 銀行名欄
413 支店名欄
414 口座種類欄
415 口座番号欄
416 口座名義人名称欄
417 振込金額欄
418 実行ボタン
421 待機フォーム
422 取引内容欄
423 進捗状況欄
424 中止ボタン
425 了解ボタン
431 ホーム画面
432 通知
441 認証フォーム
442 パスワード欄
443 認証ボタン
444 メッセージ欄
451 中止フォーム
452 メッセージ欄
453 了解ボタン
461 確認フォーム
462 メッセージ欄
463 確認ボタン
464 選択肢ボタン
471 完了フォーム
472 履歴欄
473 了解ボタン

Claims (11)

1. サーバと、第1端末と、第2端末と、を備える取引システムであって、
   前記第1端末を介して前記サーバにログインしたユーザから、前記第1端末を介して取引の指示を受け付けると、前記サーバは、前記第2端末に伝達すべき通知を生成し、
   前記通知が前記サーバから前記第2端末へ伝達されると、前記第2端末は、前記ユーザに前記取引の詳細の一部を隠して提示し、
   前記第1端末または前記第2端末は、前記隠された一部を補充する入力を前記ユーザに促し、
   前記第1端末または前記第2端末に対する前記ユーザからの前記入力が、前記隠された一部と一致すれば、前記サーバは、前記ユーザによる前記取引に対する確認がされたものとみなす
   ことを特徴とする取引システム。
2. 前記サーバは、前記通知に、前記取引の詳細の一部を隠した内容を指定し、
   前記第2端末は、前記通知に指定された前記内容を提示することにより、前記取引の詳細の一部を隠して提示し、
   前記第1端末または前記第2端末に対する前記ユーザからの前記入力は、前記サーバに伝達され、
   前記サーバは、前記伝達された入力が、前記隠された一部と一致するか否かを判定し、一致すると判定されれば、前記確認がされたものとみなす
   ことを特徴とする請求項1に記載の取引システム。
3. 前記サーバは、前記通知に、前記取引の詳細を指定し、
   前記第2端末は、前記通知に指定された前記取引の詳細の一部を隠して提示して、前記隠された一部を補充する入力を前記ユーザに促し、
   前記ユーザからの前記入力は、前記第2端末に対してなされ、
   前記第2端末は、前記第2端末に対する前記ユーザからの前記入力が前記隠された一部と一致するか否かを判定して、一致すると判定されれば、前記ユーザによる前記確認がされた旨を、前記サーバに伝達する
   ことを特徴とする請求項1に記載の取引システム。
4. 前記サーバは、前記第1端末を介して前記隠された一部を補充する入力を前記ユーザに促し、前記ユーザからの前記入力は、前記第1端末に対してなされ、前記第1端末に対する前記ユーザからの前記入力が前記隠された一部と一致すれば、前記ユーザによる前記確認がされたものとみなす
   ことを特徴とする請求項1に記載の取引システム。
5. 前記ユーザが前記第1端末を介して第1認証が成功することにより前記サーバにログインした後に、前記サーバは、前記第1端末を介して前記取引の指示を受け付け、
   前記サーバから前記通知が伝達されると、前記第2端末は、前記ユーザの第2認証を試み、
   前記第2認証が成功すると、前記第2端末は、前記取引の詳細の一部を隠して提示する
   ことを特徴とする請求項1から4のいずれか1項に記載の取引システム。
6. 前記サーバから伝達される前記通知は、前記サーバにおいて暗号化され、
   前記第2端末は、前記サーバから伝達された前記暗号化された前記通知の復号を試みて、前記復号の成否により、前記第2認証の成否を定める
   ことを特徴とする請求項5に記載の取引システム。
7. 前記ユーザによる前記取引に対する前記確認がされたものとみなされると、前記サーバは、前記取引を実行する
   ことを特徴とする請求項1に記載の取引システム。
8. 前記サーバは、前記第1端末を介して、文字列コード、1次元コード、もしくは、2次元コードを前記通知として生成し、前記生成された前記文字列コード、1次元コード、もしくは、2次元コードを前記ユーザに提示し、
   前記提示された前記文字列コード、1次元コード、もしくは、2次元コードを前記第2端末が撮影することにより、前記通知が前記サーバから前記第2端末へ伝達される
   ことを特徴とする請求項1に記載の取引システム。
9. 前記サーバが前記通知を前記第2端末へプッシュすることにより、前記通知が前記サーバから前記第2端末へ伝達される
   ことを特徴とする請求項1に記載の取引システム。
10. サーバと、第1端末と、第2端末と、を備える取引システムが実行する取引方法であって、
    前記サーバが、前記第1端末を介して前記サーバにログインしたユーザから、前記第1端末を介して取引の指示を受け付けると、前記サーバが、前記第2端末に伝達すべき通知を生成する工程と、
    前記通知が前記サーバから前記第2端末へ伝達されると、前記第2端末が、前記ユーザに前記取引の詳細の一部を隠して提示する工程と、
    前記第1端末または前記第2端末が、前記隠された一部を補充する入力を前記ユーザに促す工程と、
    前記第1端末または前記第2端末に対する前記ユーザからの前記入力が、前記隠された一部と一致すれば、前記サーバが、前記ユーザによる前記取引に対する確認がされたものとみなす工程と、
    を備えることを特徴とする取引方法。
11. サーバ用コンピュータを、請求項1に記載の取引システムにおけるサーバとして機能させるサーバ用プログラムが記録された非一時的な第1の情報記録媒体と、
    端末用コンピュータを、請求項1に記載の取引システムにおける第2端末として機能させる第2端末用プログラムが記録された非一時的な第2の情報記録媒体と、
    を備えることを特徴とする情報記録媒体。

Images