(57)【要約】【課題】  本人認証のため、パスワードを入力させたり、利用者端末に確認メールを送信し返信を要求するだけでは、パスワードや利用者端末が盗難されると、本人になりすまして悪意者が認証処理することが可能である。【解決手段】  決済実行の同意確認依頼のフォーマットが管理されるフォーマット蓄積手段と、フォーマット毎に応答規則が管理される応答規則蓄積手段と、同意確認依頼を利用者端末に送信し、同意確認依頼通知に対する応答情報を上記応答規則と比較し、応答規則を満たす場合、決済を実行する決済手段を備える。【選択図】      図１
2006338355.tif 000002
【特許請求の範囲】
【請求項１】
利用者の取引を決済する決済装置であって、
利用者に上記決済実行の同意確認を求める確認依頼通知に関するフォーマットが管理されるフォーマット蓄積手段と、
上記フォーマットに対して利用者が応答する応答情報に関する応答規則が、利用者毎に対応づけられて管理される応答規則蓄積手段と、
上記フォーマットに沿って作成された確認依頼通知情報を利用者の連絡先へ送信し、利用者端末からの応答情報を受信し、該応答情報に関する連絡先となる利用者に対応づけられた応答規則を上記応答規則蓄積手段から参照し、受信した該応答情報が参照された該応答規則を満たすか否かを判定し、該判定結果が応答規則を満たす場合、上記取引の決済を実行する決済手段
を備えることを特徴とする決済装置。
【請求項２】
請求項１記載の決済装置であって、
上記フォーマットは複数管理され、上記応答規則は各フォーマット毎に定められ、
上記決済手段は、複数の上記フォーマットのいずれかを用いて確認依頼通知情報を作成し、使用したフォーマットに対応する上記利用者の応答規則を参照し上記応答情報を判定する
ことを特徴とする決済装置。
【請求項３】
請求項１記載の決済装置であって、
上記応答規則は、応答情報に含まれるべき特定の認証情報、および、応答情報における該認証情報の入力されるべき位置が規定される
ことを特徴とする決済装置。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、取引の決済を実行する決済装置に関する。
【背景技術】
【０００２】
インターネット上では、クレジットカード等による与信・決済の本人認証として、パスワードを入力させる方法が一般的である。
【０００３】
しかし、パスワードを使用した本人認証では、パスワードを盗用されると、カードによる不正決済を防止することが困難である。
【０００４】
これを解決するため、既に公開された特許文献の中には、利用者の携帯端末に決済すべき案件が存在する旨を電子メール送信して、利用者がメール内の承認ボタンを押すと自動的に決済機関へ返信メールが送信され、これに基づき決済を行う技術が記載される（特許文献１）。
【特許文献１】特開２００１−２５００６３
【発明の開示】
【発明が解決しようとする課題】
【０００５】
しかし、上記に示した電子メールによる確認でも、電子メールの宛先となる携帯端末が盗用されてしまえば、容易に不正決済が可能である。
【０００６】
本発明の目的は、パスワードや電子メールの宛先となる端末が盗まれたとしても、不正な決済を防ぐ決済装置を実現することにある。
【課題を解決するための手段】
【０００７】
本発明は、利用者の取引を決済する決済装置であって、利用者に上記決済実行の同意確認を求める確認依頼通知のフォーマットが管理されるフォーマット蓄積手段と、上記フォーマットに対して利用者が応答する応答情報に関する応答規則が、利用者毎に対応づけられて管理される応答規則蓄積手段と、上記フォーマットに沿って作成された確認依頼通知情報を利用者の連絡先へ送信し、利用者端末からの応答情報を受信し、該応答情報の連絡先である利用者に対応づけられた応答規則を上記応答規則蓄積手段から参照し、受信した該応答情報が参照された該応答規則を満たすか否かを判定し、該判定結果が応答規則を満たす場合、上記取引の決済を実行する決済手段を備えることを特徴とする。
【０００８】
さらに、本発明は、複数の上記フォーマットが管理され、上記応答規則は各フォーマット毎に定められ、上記決済手段は、複数の上記フォーマットのいずれかを用いて確認依頼通知情報を作成し、使用したフォーマットに対応する上記利用者の応答規則を参照し上記応答情報を判定することを特徴とする。
【０００９】
また、本発明の上記応答規則は、応答情報に含まれるべき特定の認証情報、および、該認証情報が応答情報において入力されるべき位置が規定されることを特徴とする。
【発明の効果】
【００１０】
本発明は、利用者に決済実行の同意確認通知に関してフォーマットが定められ、同意確認通知の応答情報が、このフォーマットに対応づけられた利用者の応答規則を満たすか否かで決済可否が判定されるため、パスワードや端末を盗んだ不正者は、この応答規則を知らない限りは決済を実行させることが出来なくなる。
【００１１】
さらに、本発明は、複数のフォーマットが管理され、そのフォーマット毎に利用者の応答規則が定められているため、パスワードや端末を盗んだ不正者は、確認依頼通知がどのフォーマットで作成されたのかを知らない限り、そして、そのフォーマットに対応する応答規則を知らない限り、決済を実行させることが出来なくなる。
【００１２】
さらに、本発明は、パスワードや端末を盗んだ不正者は、パスワードのような認証情報だけでなく、その認証情報を応答情報のどの位置に入力すべきかを知らない限り、決済を実行させることが出来なくなる。
【発明を実施するための最良の形態】
【００１３】
以下、クレジットカード決済を想定した本発明における実施形態を示す。尚、ここに示す実施例と同等の効果が生じるものであれば、本実施例にどのような変更を加えても構わない。
【００１４】
本発明におけるシステム全体の構成を図１に示す。本発明は、決済装置１００、購入者端末２００、店舗装置３００で構成される。
【００１５】
決済装置１００は、さらに、決済手段１１０、会員情報ＤＢ（データベース）１２０、決済情報ＤＢ１３０、定型文ＤＢ１４０、店舗情報ＤＢ１５０で構成される。
【００１６】
決済手段１１０は、予め利用者の応答規則や連絡先を管理しておき、店舗装置３００からの決済依頼を受け付けると、決済に関する同意確認依頼を複数のフォーマットのいずれかに基づき作成し、この決済の当事者となる利用者宛に電子メール送信する。そして、購入者端末２００から送信されてきた同意確認依頼に対する返信メールを受信し、その返信メールの内容を利用者の応答規則に照らして判定し、応答規則を満たしている場合に初めてこの決済を実行する。
【００１７】
また、決済手段１１０は、購入者端末２００や店舗装置３００からのカード決済利用の登録申請を受け付けるため、例えばHTML形式で作成されたウェブ情報を作成管理する。
【００１８】
会員情報ＤＢ１２０には、利用者の連絡先や応答規則が管理される。会員情報ＤＢ１２０で管理される会員情報テーブル５００は、図６に示すように、例えば、利用者が所有する決済カードを識別するカードＩＤ（識別情報）、利用者の氏名、利用者の連絡先となる電子メールダドレス、および、同意確認依頼を作成するためのフォーマット毎の応答規則で構成される。応答規則の詳細は、後述する。
【００１９】
決済情報ＤＢ１３０には、店舗装置３００からの決済依頼の情報および同意確認依頼に関する情報などが管理される。決済情報ＤＢ１３０で管理される決済情報テーブル６００は、図７に示すように、例えば、決済案件を識別する決済ＩＤ、決済依頼元の店舗を識別する店舗ＩＤ、本決済案件の支払者となる利用者のカードＩＤ、決済案件について店舗が独自に発行した取引ＩＤ、決済案件の発注あるいは取引が成立した取引日時、決済金額を示す利用金額、決済案件について店舗が独自に発行した店舗ＫＷ、同意確認依頼を生成する際に適用されたフォーマットを識別する定型文パターン、同意確認依頼に対する応答情報の判定結果、といった諸データ項目で構成される。
【００２０】
この内、店舗ＩＤ、カードＩＤ、取引ＩＤ、取引日時、利用金額、店舗ＫＷは、店舗装置３００から送信されてくる決済依頼情報に含まれる。決済ＩＤは、決済依頼を決済情報テーブル６００に書き込む際に決済手段１１０が新規生成する。定型文パターンは、決済手段１１０が同意確認依頼を生成するためフォーマットを選択した時点で記録される。確認結果は、決済手段１１０が応答情報を判定した時点で記録される。
【００２１】
定型文ＤＢ１４０には、同意確認依頼を作成するためのフォーマットが複数管理される。定型文ＤＢ１４０で管理される定型文テーブル７００は、図８に示すように、例えば、フォーマットの種別を示すパターン、実際のフォーマットを定義したデータ、の各データ項目で構成される。
【００２２】
フォーマットのデータは、購入者端末２００を介して同意確認依頼メールを受信した利用者が、同意確認依頼メールに採用されたのがどのフォーマットなのか識別可能なように、レイアウトや使用する語句など文面が異なるように特徴づけられている。
【００２３】
店舗情報ＤＢ１５０には、決済装置１００にカード決済を依頼してくる店舗に関する情報が管理される。店舗情報ＤＢ１５０で管理される店舗情報テーブル８００は、図９に示すように、例えば、決済装置１００内で店舗を識別するための店舗ＩＤ、店舗の名称である店舗名、店舗の連絡先である電子メールアドレス、の各データ項目で構成される。
【００２４】
購入者端末２００は、ネットワーク４００を介して決済装置１００・店舗装置３００が提供する、例えばHTML言語で記述されたウェブ情報を受信し表示するためのブラウザ手段２１０、および、決済装置１００や店舗装置３００との間で電子メールを送受信するメール手段２２０を備える。
【００２５】
購入者端末２００は、例えば、ＰＣ（パーソナルコンピュータ）や携帯電話、ＰＤＡ（Personal Data Assistant）端末などが想定されるが、上記のような手段を備えるものであれば、これらの製品に限定されることはない。
【００２６】
購入者端末２００は、決済装置１００にカード決済依頼ができる利用者毎に複数存在する。もちろん、購入者端末２００を共有している利用者においては、この限りではない。
【００２７】
尚、利用者がＰＣで店舗装置３００に対して注文を行っても、決済装置１００の会員登録の連絡先を携帯電話のメールアドレスを登録している場合は、決済確認依頼メールがＰＣではなく携帯電話へ着信することになる。したがって、このような場合は、同一の利用者が複数の購入端末２００を操作することになる。
【００２８】
店舗装置３００は、取引手段３１０、および、取引ＤＢ３２０で構成される。
【００２９】
取引手段３１０は、購入者端末２００に対して取引あるいは商品の情報を提供するための、例えばHTML言語で記述されたウェブ情報を作成管理・送信し、購入者端末２００からの注文情報を受信し、受信した注文情報を取引ＤＢ３２０で管理し、決済装置１００に対して決済依頼情報を送信する。
【００３０】
取引ＤＢ３２０で管理される取引テーブル（図を省略）には、購入者端末２００から受信した注文情報、および、取引手段３１０によって生成された各種情報が、取引手段３１０の命令のもと管理される。
【００３１】
購入者端末２００からの注文情報には、例えば、注文情報に含まれる利用者氏名、発送先あるいは連絡先、利用者のカードＩＤ、発注された取引あるいは商品の内訳や金額情報などが含まれる。
【００３２】
また、取引手段３１０が生成する情報には、例えば、注文を識別するための取引ＩＤ、利用者に提供する取引認証用の店舗ＫＷ、決済装置１００からの決済確認結果、注文受付の日時を示す取引日時、商品発送予定日、納品完了日時、返品情報、商品代金受領の有無、などが含まれる。
【００３３】
店舗装置３００は、決済装置１００に利用者のカード決済を依頼可能な店舗毎に複数存在する。
【００３４】
ネットワーク４００は、デジタル通信を可能とするのであれば、どのような通信回線でも構わない。また、有線回線か無線回線の区別も必要としない。また、有線回線と無線回線の混在であっても構わない。
【００３５】
図２に、本実施例における決済装置１００、購入者端末２００、店舗装置３００の間で行われる全体的な概要処理フローを示す。
【００３６】
Ｓ１で、購入者端末２００のメール手段２２０は、決済装置１００に対して、決済確認メールの返信文面のどこに決済確認情報を挿入するかを示す電子メールを送信することで、決済確認の応答規則に関する登録を申請する。この時、決済確認メールの各フォーマット毎に、購入者端末２００は電子メールを送信する。
【００３７】
Ｓ２で、決済装置１００の決済手段１１０は、Ｓ１で購入者端末２００が発信した電子メールを受信し、申請された応答規則を会員情報ＤＢ１２０へ蓄積する。
【００３８】
Ｓ３で、購入者端末２００のブラウザ手段２１０は、店舗装置３００が提供するウェブ情報を介して、注文情報を店舗装置３００へ送信する。
【００３９】
Ｓ４で、店舗装置３００の取引手段３１０は、Ｓ３で購入者端末２００が送信してきた注文情報を受信し、取引ＤＢ３２０に注文情報を蓄積する。この際、取引手段３１０は、この注文を識別するための取引ＩＤ、利用者に送信する取引認証用の店舗ＫＷを新規に生成し、この注文情報に対応づけて取引ＤＢ３２０に蓄積する。
【００４０】
Ｓ５で、店舗装置３００の取引手段３１０は、Ｓ４で生成した店舗ＫＷを注文受付確認情報とともに購入者端末２００へ送信する。具体的には、ウェブ情報として購入者端末２００のディスプレィ上に注文受付確認情報を表示しても、あるいは、購入者端末２００に対して電子メールで注文受付確認情報を送信しても構わない。
【００４１】
Ｓ６で、購入者端末２００のブラウザ手段２１０あるいはメール手段２２０が、店舗ＫＷを含む注文受付確認情報を受信する。
【００４２】
なお、Ｓ３〜Ｓ６については、店舗ＫＷの生成・送信以外は、既に一般的に行われているインターネットショッピングと同様の動きである。
【００４３】
Ｓ７で、店舗装置３００の取引手段３１０は、決済装置１００に対して、受注した取引に関するカード決済を依頼する。具体的な依頼方法は、決済装置１００の決済手段１１０が提供する決済依頼受付のウェブ情報に、取引手段３１０がアクセスし、そのウェブ情報に対して決済依頼情報を入力することが考えられる。あるいは、取引手段３１０が決済装置１００に電子メールで決済依頼情報を送信してもよい。
【００４４】
Ｓ８で、決済装置１００の決済手段１１０は、店舗装置３００からの決済依頼情報を受信する。
【００４５】
Ｓ９で、決済装置１００の決済手段１１０は、受信した決済依頼情報に含まれるカードＩＤに基づき利用者の連絡先を特定し、同意確認依頼情報を電子メール送信する。同意確認依頼情報は、決済手段１１０によって、定型文ＤＢ１４０で管理される複数のフォーマットのいずれかに基づいて作成される。
【００４６】
Ｓ１０で、購入者端末２００のメール手段２２０は、Ｓ９で決済装置１００が送信した同意確認依頼情報を受信する。
【００４７】
Ｓ１１で、購入者端末２００のメール手段２２０は、利用者によって編集入力された同意確認依頼情報に対する返信メールを、同意確認依頼情報を引用する形式で、決済装置１００へ電子メールを送信する。この返信メールは、Ｓ２で決済装置１００が登録した利用者の応答規則に従って、引用された同意確認依頼情報が編集される。また、この際、返信メールには、Ｓ６で利用者が入手した店舗装置３００発行の店舗ＫＷが含まれる。
【００４８】
Ｓ１２で、決済装置１００の決済手段１１０は、Ｓ１１で購入者端末２００から送信された返信メールを受信する。
【００４９】
Ｓ１３で、決済装置１００の決済手段１１０は、Ｓ１２で受信した返信メールが、同意確認依頼情報作成時に採用されたフォーマットに対応した利用者の応答規則を満たしているか否かを判断し、応答規則を満たしている場合は、この取引の決済を実行する。
【００５０】
以上が、本実施例における全体的な処理フローである。
【００５１】
次に、本実施例に関するより詳細な処理を、図３〜図５を用いて説明する。
【００５２】
図３に、決済処理装置１００の決済手段１１０が、クレジットカード利用者からの、決済確認依頼に対する返信メールの応答規則を登録する処理フローである。
【００５３】
なお、当該処理フローの処理開始以前に、決済手段１１０は、既に、購入者端末２００から、カード利用者のカードＩＤ、氏名、連絡先、および、同意確認依頼情報に用いられるフォーマット毎に定義した個人ＫＷを受信して、図６の会員情報テーブル５００に記録しているものとする。
【００５４】
記録された上記情報は、購入者端末２００のブラウザ手段２１０が、決済装置１００の決済手段１１０が提供した決済確認登録画面のウェブ情報に対して入力されることで、決済手段１１０に送信されるものとする。
【００５５】
なお、この決済確認登録画面には、申請された連絡先に対して、別途決済確認の応答規則を登録するための定義登録メールが送信されること、そして、その定義登録メールに対して個人ＫＷおよび店舗ＫＷをどこにどんな順序で挿入するかの応答規則の実例を編集入力し、決済装置１００へ電子メール返信する必要があることが記載されている。
【００５６】
個人ＫＷは、同意確認依頼された案件について利用者本人が返信していることを証明する認証情報の役割を果たす。本実施例では、フォーマット毎に個別に利用者が定義するが、全フォーマットに共通するものとしてもよい。また、利用者が定義せず決済手段１００が発行するようにすることも可能である。
【００５７】
Ｓ２１で、決済手段１１０は、会員情報テーブル５００の送信先に記録される電子メールアドレスに対して、同意確認依頼用の各フォーマットを用いた電子メールを購入者端末２００のメール手段２２０に送信する。
【００５８】
例えば、図８の定型文テーブル７００には、フォーマットがパターンＡとパターンＢの２種類登録されている。このため、決済手段１１０は、各フォーマットで作成された定義登録メールをそれぞれ購入者端末２００へ送信する。利用者はそれぞれの定義登録メールに応答規則の実例を編集入力して返信することになる。
【００５９】
Ｓ２２で、決済手段１１０は、購入者端末２００から定義登録メールの返信メールを受信する。この返信メール本文の例を、図１０に示す。
【００６０】
図１０の文例９００は、パターンＡのフォーマットで送信された定義登録メールに対する返信メールであり、文例１０００は、パターンＢの場合の返信メールである。いずれも、図８の定型文テーブル７００のデータ項目と比較すると、「■」「▲」という記号以外はフォーマットのデータと同一である。
【００６１】
この「■」と「▲」の記号は、先の決済確認登録画面上で、「■」は個人ＫＷを示し、「▲」は店舗ＫＷを示すものであり、これらの記号を使用して応答規則の実例を編集入力する旨の指示が記載されており、利用者はこの指示に従って返信メールを送信してくる。
【００６２】
Ｓ２３で、決済手段１１０は、受信した返信メールに基づき、各フォーマットに対する応答規則を会員情報テーブル５００に登録する。
【００６３】
たとえば、パターンＡの返信メールの文例９００の場合、フォーマットの「カード決済の」とある冒頭部分の直前に、個人ＫＷ、店舗ＫＷの順に編集入力して返信することが応答規則となる。尚、本実施例は、個人ＫＷと店舗ＫＷは続けて配置することが先の決済確認登録画で予め規定されているものとするが、個人ＫＷと店舗ＫＷをそれぞれ別の位置に入力することを許すようにしてもよい。
【００６４】
決済手段１１０は、返信メールの本文データの中で、「■▲」（あるいは「▲■」）の文字データがどこに記載されているかを特定する。この処理は、ワープロソフトやテキスト編集ソフトといったアプリケーションに搭載される検索機能と同様の処理で実現可能である。
【００６５】
そして、決済手段１１０は、返信メールの発信元の電子メールアドレスに基づき、会員情報テーブル５００の該当する利用者のレコードを特定し、例えば文例９００の場合、その定型Ａ項目の店舗ＫＷ関係項目には、「前」、すなわち、個人ＫＷが店舗ＫＷの前に位置することを示す情報を記録する。さらに、位置項目には、「＋「カー」」、すなわち、「カード決済の」という語句の直前に個人ＫＷおよび店舗ＫＷが編集入力されることを示す情報を記録する。この例では「＋」が個人ＫＷと店舗ＫＷが入る位置を示す。
【００６６】
さらに引き続いて、決済手段１１０は、パターンＢの返信メールの文例１０００に基づいて、会員情報テーブル５００の定型Ｂ項目の店舗ＫＷ関係項目および位置項目に、それぞれ文例１０００に示された内容を示す情報を記録する。
【００６７】
そして、決済手段１１０は、Ｓ２３で会員情報テーブル５００に応答規則情報を正常に登録できたら、Ｓ２４で、該当利用者の送信先の電子メールアドレスを用いて、応答確認依頼の登録が完了した旨の登録完了通知の電子メールを購入者端末２００へ送信して、一連の登録受付処理を完了する。
【００６８】
次に図４を用いて、決済装置１００の決済手段１１０が、店舗装置３００からの決済依頼情報を受信して、同意確認依頼の電子メールを作成し、購入者端末２００に対して送信する、という一連の同意確認依頼メール作成処理フローについて説明する。
【００６９】
Ｓ３１で決済手段１１０は、店舗装置３００からの決済依頼情報を受信する。決済依頼情報には、少なくとも、店舗ＩＤ、利用者のカードＩＤ、この取引の取引ＩＤ、取引日時、利用金額、店舗ＫＷが含まれる。
【００７０】
Ｓ３２で、決済手段１１０は、図７の決済情報テーブル６００に新規レコードを作成し、受信した決済依頼情報を識別するための決済ＩＤを新規生成し記録する。さらに、決済依頼情報に含まれる上記情報を記録する。
【００７１】
Ｓ３３で、決済手段１１０は、同意確認依頼メールを作成するために、図８の定型文テーブル７００を参照し、いずれかのフォーマットを選択し、フォーマットデータを読み込む。この際、Ｓ３２で作成した決済情報レコードの定型文パターン項目に、選択したフォーマットのパターンを記録する。
【００７２】
Ｓ３４で、決済手段１１０は、Ｓ３３で読込んだフォーマットデータを利用して、同意確認依頼メールを作成する。具体的には、フォーマットデータに、Ｓ３２で決済情報テーブル６００のレコードに記録した決済ＩＤ、取引ＩＤ、利用金額を挿入する。さらに、店舗ＩＤを参照し、図９の店舗情報テーブル８００から、対応する店舗名を特定し、店舗名を読み込んだフォーマットデータ内に挿入する。これで、同意確認依頼メールの本文が完成する。
【００７３】
Ｓ３５で、決済手段１１０は、該当する利用者の購入者端末２００へ、Ｓ３４で作成した同意確認依頼メールを電子メール送信する。送信先の電子メールアドレスは、Ｓ３２で記録した決済情報レコードのカードＩＤを参照し、図６の会員情報テーブル５００から対応する会員情報レコード内の送信先項目から電子メールアドレスを特定する。
【００７４】
以上が、決済処理装置１００の決済手段１１０における同意確認依頼メール作成処理フローである。
【００７５】
次に図５を用いて、決済装置１００の決済手段１１０が処理する決済実行処理フローを説明する。この処理は、購入者端末２００からの同意確認依頼メールに対する返信メールを受信し、この返信メールが応答規則を満たしているか否かを判定し、満たしている場合は該当する決済案件を実際に実行する、という一連の処理である。
【００７６】
Ｓ４１で、決済手段１１０は、購入者端末２００からの返信メールを受信する。図１１に返信メール文例１１００を示す。これは、図７の決済情報テーブル６００のレコード内容の決済案件について、図８の定型文テーブル７００におけるパターンＡが採用された同意確認依頼メールが購入者端末２００に送信された場合を想定している。
【００７７】
この返信メール文例１１００内で利用者が編集入力したのは、文例冒頭の「JPNＧＥＴ」の部分である。同意確認依頼メールを購入者端末２００で受信した利用者は、その文面（レイアウトや使用される語句など）から、パターンＡかＢのいずれのフォーマットが採用されたかを識別し、その識別したフォーマットに対応する応答規則に基づいて、受信メールを引用した返信メールを作成し、そこに個人ＫＷおよび店舗ＫＷを編集入力してから、決済装置１００へ返信する。
【００７８】
Ｓ４２で、決済手段１１０は、返信元（つまり利用者）の電子メールアドレス、および、返信メール文面上の決済ＩＤ、取引ＩＤなどに基づいて、決済情報テーブル６００から該当する決済情報レコードを特定する。
【００７９】
Ｓ４３で、決済手段１１０は、Ｓ４２で特定した決済情報レコードの定型文パターン項目から、同意確認依頼メールで採用したフォーマットのパターンを特定する。
【００８０】
Ｓ４４で、決済手段１１０は、Ｓ４２で特定した決済情報レコードから店舗ＫＷを識別し読み込み、かつ、カードＩＤを参照し、図６の会員情報テーブル５００で対応する会員情報レコードから、Ｓ４３で特定したフォーマットパターンに対応する個人ＫＷ、店舗ＫＷ関係、位置、の各項目データを識別し読込む。
【００８１】
Ｓ４５で、決済手段１１０は、Ｓ４４で読み込んだ個人ＫＷが、Ｓ４１で受信した返信メール内に存在するか否かを検索し、個人ＫＷと同一の語句が返信メールに存在しない場合は、Ｓ４９の処理へ進み決済拒否処理（後述）を行う。そして、個人ＫＷと同一の語句が返信メールに存在する場合は、Ｓ４６に進む。
【００８２】
Ｓ４６で、決済手段１１０は、Ｓ４４で読み込んだ店舗ＫＷが、Ｓ４１で受信した返信メール内に存在するか否かを検索し、店舗ＫＷと同一の語句が返信メールに存在しない場合は、Ｓ４９の処理へ進み決済拒否処理（後述）を行う。そして、店舗ＫＷと同一の語句が返信メールに存在する場合は、Ｓ４７に進む。
【００８３】
Ｓ４７で、決済手段１１０は、Ｓ４４で読み込んだ位置（個人ＫＷと店舗ＫＷがメールに入力される位置）、および、店舗ＫＷ関係（個人ＫＷが店舗ＫＷの前に連結されるのか、あるいは、後ろに連結されるのか）の情報に基づき、Ｓ４１で受信した返信メール内で、個人ＫＷと店舗ＫＷがこの２つの条件を満たすか否かを判定する。もし、この２つの条件を同時に満たすものでなければ、Ｓ４９の処理へ進み決済拒否処理（後述）を行う。逆に、この２つの条件を満たす場合は、Ｓ４８に進む。
【００８４】
Ｓ４８で、決済手段１１０は、Ｓ４１で受信した返信メールが利用者の応答規則に沿ったものであると判定し、Ｓ４２で特定した決済情報レコードの決済を実際に実行し、同レコードの確認結果項目に決済を実行したことを示す情報を記録する。この処理は、通常のカード決済における決済処理と同等の処理である。
【００８５】
Ｓ４９で、決済手段１１０は、Ｓ４１で受信した返信メールが利用者の応答規則に沿っていないと判定し、Ｓ４２で特定した決済情報レコードの確認結果項目に決済できないことを示す情報を記録する。そして、決済手段１１０は、店舗装置３００に対して、取引ＩＤに該当する取引について利用者本人と証明できない旨の決済拒否通知を電子メール送信する。そして、実際の決済処理は行わないままとする。
【００８６】
以上が、決済装置１００の決済手段１１０が行う一連の決済実行処理フローである。
【００８７】
なお、本実施例では、決済同意確認を登録すると、全ての取引案件について同意確認依頼メールが発行されるものとして説明したが、利用者や店舗の希望によって、例えば、取引金額が所定値以上のものに限ることも可能である。
【００８８】
利用者が上記のような限定を行う場合、決済同意確認の登録画面上から、決済同意確認を希望する取引金額の下限を入力し、決済装置１００は、図６の会員情報テーブル５００にこの情報を記録するための下限価格項目を設けてこれを記録する。
【００８９】
そして、決済装置３００は、Ｓ３２の決済情報登録ステップを処理すると、決済情報の利用金額が会員情報テーブル５００に記録された下限価格項目の金額と比較して、利用金額が下限価格未満ならば、同意確認メールを作成・送信せず、すぐにＳ４８の決済処理を行うのである。
【００９０】
一方、店舗側が上記のような限定を行う場合は、店舗装置３００が予め下限価格を決済装置３００に通知し、決済装置１００は、図９の店舗情報テーブル８００に下限価格項目をさらに設けて、通知された下限価格項目を記録する。
【００９１】
そして、決済装置３００は、Ｓ３２の決済情報登録ステップを処理すると、決済情報の利用金額が店舗情報テーブル８００に記録された下限価格項目の金額と比較して、利用金額が下限価格未満ならば、同意確認メールを作成・送信せず、すぐにＳ４８の決済処理を行うのである。
【００９２】
また、本実施例は、インターネットショピングを想定して説明したが、実際の店頭販売においてももちろん適用可能である。この場合、Ｓ３の購入依頼は、直接店舗におけるクレジットカードリーダーに利用者のカードを読み込ませることになる。また、Ｓ５の注文通知、つまり、店舗ＫＷの通知は、プリントされたレシートに印字したり、口頭その他で利用者に直接店員が伝達する場合が生じる。
【００９３】
また、本実施例では店舗ＫＷを発行したが、店舗装置３００が店舗ＫＷを発行せず、個人ＫＷだけで使用した応答規則を設定することも可能である。逆に、個人ＫＷを不要として、店舗ＫＷだけを使用した応答規則を設定することも可能である。いずれの場合においても、会員情報テーブル５００の店舗ＫＷ関係項目に相当する情報は管理しないことになる。
【００９４】
また、本実施例では、クレジットカード決済を想定して説明したが、取引に関するそれ以外の与信や決済形態にも適用することが可能である。
（付記１）利用者の取引を決済する決済装置であって、
利用者に上記決済実行の同意確認を求める確認依頼通知に関するフォーマットが管理されるフォーマット蓄積手段と、
上記フォーマットに対して利用者が応答する応答情報に関する応答規則が、利用者毎に対応づけられて管理される応答規則蓄積手段と、
上記フォーマットに沿って作成された確認依頼通知情報を利用者の連絡先へ送信し、利用者端末からの応答情報を受信し、該応答情報に関する連絡先となる利用者に対応づけられた応答規則を上記応答規則蓄積手段から参照し、受信した該応答情報が参照された該応答規則を満たすか否かを判定し、該判定結果が応答規則を満たす場合、上記取引の決済を実行する決済手段
を備えることを特徴とする決済装置。
（付記２）付記１記載の決済装置であって、
上記フォーマットは複数管理され、上記応答規則は各フォーマット毎に定められ、
上記決済手段は、複数の上記フォーマットのいずれかを用いて確認依頼通知情報を作成し、使用したフォーマットに対応する上記利用者の応答規則を参照し上記応答情報を判定する
ことを特徴とする決済装置。
（付記３）付記１記載の決済装置であって、
上記応答規則は、応答情報に含まれるべき特定の認証情報、および、応答情報における該認証情報の入力されるべき位置が規定される
ことを特徴とする決済装置。
（付記４）付記３記載の決済装置であって、
上記特定の認証情報は、利用者本人を示す本人認証情報、または、上記取引が真に存在することを証明する取引認証情報である
ことを特徴とする決済装置。
（付記５）付記４記載の決済装置であって、
上記応答規則は、上記本人認証情報と上記取引認証情報の２つの認証情報を含み、かつ、この２つの認証情報の位置関係を規定する
ことを特徴とする決済装置。
【図面の簡単な説明】
【００９５】
【図１】本発明のシステム構成例を示す図である。
【図２】本発明の全体処理フローを示す図である。
【図３】本発明の決済装置１００における、登録受付処理フローを示す図である。
【図４】本発明の決済装置１００における、同意確認依頼メール作成処理フロー示す図である。
【図５】本発明の決済装置１００における、決済実行処理フロー示す図である。
【図６】本発明の会員情報テーブル５００を示す図である。
【図７】本発明の決済情報テーブル６００を示す図である。
【図８】本発明の定型文テーブル７００を示す図である。
【図９】本発明の店舗情報テーブル８００を示す図である。
【図１０】本発明の登録メール文例９００、１０００を示す図である。
【図１１】本発明の返信メール文例１１００を示す図である。
【符号の説明】
【００９６】
１００  決済装置
１１０  決済手段
１２０  会員情報ＤＢ（データベース）
１３０  決済情報ＤＢ（データベース）
１４０  定型文ＤＢ（データベース）
１５０  店舗情報ＤＢ（データベース）
２００  購入者端末
２１０  ブラウザ手段
２２０  メール手段
３００  店舗装置
３１０  取引手段
３２０  取引ＤＢ（データベース）
４００  ネットワーク
５００  会員情報テーブル
６００  決済情報テーブル
７００  定型文テーブル
８００  店舗情報テーブル
９００  定義登録メール（パターンＡ）文例
１０００  定義登録メール（パターンＢ）文例
１１００  返信メール文例
【図１】
2006338355.tif 000003
【図２】
2006338355.tif 000004
【図３】
2006338355.tif 000005
【図４】
2006338355.tif 000006
【図５】
2006338355.tif 000007
【図６】
2006338355.tif 000008
【図７】
2006338355.tif 000009
【図８】
2006338355.tif 000010
【図９】
2006338355.tif 000011
【図１０】
2006338355.tif 000012
【図１１】
2006338355.tif 000013