JP2006338355A

JP2006338355A - 決済装置

Info

Publication number: JP2006338355A
Application number: JP2005162608A
Authority: JP
Inventors: Toshimi Yamada; 聡美山田; Hiroyasu Tanabe; 浩靖田邊
Original assignee: Fujitsu Ltd
Current assignee: Fujitsu Ltd
Priority date: 2005-06-02
Filing date: 2005-06-02
Publication date: 2006-12-14

Abstract

【課題】
本人認証のため、パスワードを入力させたり、利用者端末に確認メールを送信し返信を要求するだけでは、パスワードや利用者端末が盗難されると、本人になりすまして悪意者が認証処理することが可能である。
【解決手段】
決済実行の同意確認依頼のフォーマットが管理されるフォーマット蓄積手段と、フォーマット毎に応答規則が管理される応答規則蓄積手段と、同意確認依頼を利用者端末に送信し、同意確認依頼通知に対する応答情報を上記応答規則と比較し、応答規則を満たす場合、決済を実行する決済手段を備える。
【選択図】
図１

Description

本発明は、取引の決済を実行する決済装置に関する。

インターネット上では、クレジットカード等による与信・決済の本人認証として、パスワードを入力させる方法が一般的である。

しかし、パスワードを使用した本人認証では、パスワードを盗用されると、カードによる不正決済を防止することが困難である。

これを解決するため、既に公開された特許文献の中には、利用者の携帯端末に決済すべき案件が存在する旨を電子メール送信して、利用者がメール内の承認ボタンを押すと自動的に決済機関へ返信メールが送信され、これに基づき決済を行う技術が記載される（特許文献１）。
特開２００１−２５００６３

しかし、上記に示した電子メールによる確認でも、電子メールの宛先となる携帯端末が盗用されてしまえば、容易に不正決済が可能である。

本発明の目的は、パスワードや電子メールの宛先となる端末が盗まれたとしても、不正な決済を防ぐ決済装置を実現することにある。

本発明は、利用者の取引を決済する決済装置であって、利用者に上記決済実行の同意確認を求める確認依頼通知のフォーマットが管理されるフォーマット蓄積手段と、上記フォーマットに対して利用者が応答する応答情報に関する応答規則が、利用者毎に対応づけられて管理される応答規則蓄積手段と、上記フォーマットに沿って作成された確認依頼通知情報を利用者の連絡先へ送信し、利用者端末からの応答情報を受信し、該応答情報の連絡先である利用者に対応づけられた応答規則を上記応答規則蓄積手段から参照し、受信した該応答情報が参照された該応答規則を満たすか否かを判定し、該判定結果が応答規則を満たす場合、上記取引の決済を実行する決済手段を備えることを特徴とする。

さらに、本発明は、複数の上記フォーマットが管理され、上記応答規則は各フォーマット毎に定められ、上記決済手段は、複数の上記フォーマットのいずれかを用いて確認依頼通知情報を作成し、使用したフォーマットに対応する上記利用者の応答規則を参照し上記応答情報を判定することを特徴とする。

また、本発明の上記応答規則は、応答情報に含まれるべき特定の認証情報、および、該認証情報が応答情報において入力されるべき位置が規定されることを特徴とする。

本発明は、利用者に決済実行の同意確認通知に関してフォーマットが定められ、同意確認通知の応答情報が、このフォーマットに対応づけられた利用者の応答規則を満たすか否かで決済可否が判定されるため、パスワードや端末を盗んだ不正者は、この応答規則を知らない限りは決済を実行させることが出来なくなる。

さらに、本発明は、複数のフォーマットが管理され、そのフォーマット毎に利用者の応答規則が定められているため、パスワードや端末を盗んだ不正者は、確認依頼通知がどのフォーマットで作成されたのかを知らない限り、そして、そのフォーマットに対応する応答規則を知らない限り、決済を実行させることが出来なくなる。

さらに、本発明は、パスワードや端末を盗んだ不正者は、パスワードのような認証情報だけでなく、その認証情報を応答情報のどの位置に入力すべきかを知らない限り、決済を実行させることが出来なくなる。

以下、クレジットカード決済を想定した本発明における実施形態を示す。尚、ここに示す実施例と同等の効果が生じるものであれば、本実施例にどのような変更を加えても構わない。

本発明におけるシステム全体の構成を図１に示す。本発明は、決済装置１００、購入者端末２００、店舗装置３００で構成される。

決済装置１００は、さらに、決済手段１１０、会員情報ＤＢ（データベース）１２０、決済情報ＤＢ１３０、定型文ＤＢ１４０、店舗情報ＤＢ１５０で構成される。

決済手段１１０は、予め利用者の応答規則や連絡先を管理しておき、店舗装置３００からの決済依頼を受け付けると、決済に関する同意確認依頼を複数のフォーマットのいずれかに基づき作成し、この決済の当事者となる利用者宛に電子メール送信する。そして、購入者端末２００から送信されてきた同意確認依頼に対する返信メールを受信し、その返信メールの内容を利用者の応答規則に照らして判定し、応答規則を満たしている場合に初めてこの決済を実行する。

また、決済手段１１０は、購入者端末２００や店舗装置３００からのカード決済利用の登録申請を受け付けるため、例えばHTML形式で作成されたウェブ情報を作成管理する。

会員情報ＤＢ１２０には、利用者の連絡先や応答規則が管理される。会員情報ＤＢ１２０で管理される会員情報テーブル５００は、図６に示すように、例えば、利用者が所有する決済カードを識別するカードＩＤ（識別情報）、利用者の氏名、利用者の連絡先となる電子メールダドレス、および、同意確認依頼を作成するためのフォーマット毎の応答規則で構成される。応答規則の詳細は、後述する。

決済情報ＤＢ１３０には、店舗装置３００からの決済依頼の情報および同意確認依頼に関する情報などが管理される。決済情報ＤＢ１３０で管理される決済情報テーブル６００は、図７に示すように、例えば、決済案件を識別する決済ＩＤ、決済依頼元の店舗を識別する店舗ＩＤ、本決済案件の支払者となる利用者のカードＩＤ、決済案件について店舗が独自に発行した取引ＩＤ、決済案件の発注あるいは取引が成立した取引日時、決済金額を示す利用金額、決済案件について店舗が独自に発行した店舗ＫＷ、同意確認依頼を生成する際に適用されたフォーマットを識別する定型文パターン、同意確認依頼に対する応答情報の判定結果、といった諸データ項目で構成される。

この内、店舗ＩＤ、カードＩＤ、取引ＩＤ、取引日時、利用金額、店舗ＫＷは、店舗装置３００から送信されてくる決済依頼情報に含まれる。決済ＩＤは、決済依頼を決済情報テーブル６００に書き込む際に決済手段１１０が新規生成する。定型文パターンは、決済手段１１０が同意確認依頼を生成するためフォーマットを選択した時点で記録される。確認結果は、決済手段１１０が応答情報を判定した時点で記録される。

定型文ＤＢ１４０には、同意確認依頼を作成するためのフォーマットが複数管理される。定型文ＤＢ１４０で管理される定型文テーブル７００は、図８に示すように、例えば、フォーマットの種別を示すパターン、実際のフォーマットを定義したデータ、の各データ項目で構成される。

フォーマットのデータは、購入者端末２００を介して同意確認依頼メールを受信した利用者が、同意確認依頼メールに採用されたのがどのフォーマットなのか識別可能なように、レイアウトや使用する語句など文面が異なるように特徴づけられている。

店舗情報ＤＢ１５０には、決済装置１００にカード決済を依頼してくる店舗に関する情報が管理される。店舗情報ＤＢ１５０で管理される店舗情報テーブル８００は、図９に示すように、例えば、決済装置１００内で店舗を識別するための店舗ＩＤ、店舗の名称である店舗名、店舗の連絡先である電子メールアドレス、の各データ項目で構成される。

購入者端末２００は、ネットワーク４００を介して決済装置１００・店舗装置３００が提供する、例えばHTML言語で記述されたウェブ情報を受信し表示するためのブラウザ手段２１０、および、決済装置１００や店舗装置３００との間で電子メールを送受信するメール手段２２０を備える。

購入者端末２００は、例えば、ＰＣ（パーソナルコンピュータ）や携帯電話、ＰＤＡ（Personal Data Assistant）端末などが想定されるが、上記のような手段を備えるものであれば、これらの製品に限定されることはない。

購入者端末２００は、決済装置１００にカード決済依頼ができる利用者毎に複数存在する。もちろん、購入者端末２００を共有している利用者においては、この限りではない。

尚、利用者がＰＣで店舗装置３００に対して注文を行っても、決済装置１００の会員登録の連絡先を携帯電話のメールアドレスを登録している場合は、決済確認依頼メールがＰＣではなく携帯電話へ着信することになる。したがって、このような場合は、同一の利用者が複数の購入端末２００を操作することになる。

店舗装置３００は、取引手段３１０、および、取引ＤＢ３２０で構成される。

取引手段３１０は、購入者端末２００に対して取引あるいは商品の情報を提供するための、例えばHTML言語で記述されたウェブ情報を作成管理・送信し、購入者端末２００からの注文情報を受信し、受信した注文情報を取引ＤＢ３２０で管理し、決済装置１００に対して決済依頼情報を送信する。

取引ＤＢ３２０で管理される取引テーブル（図を省略）には、購入者端末２００から受信した注文情報、および、取引手段３１０によって生成された各種情報が、取引手段３１０の命令のもと管理される。

購入者端末２００からの注文情報には、例えば、注文情報に含まれる利用者氏名、発送先あるいは連絡先、利用者のカードＩＤ、発注された取引あるいは商品の内訳や金額情報などが含まれる。

また、取引手段３１０が生成する情報には、例えば、注文を識別するための取引ＩＤ、利用者に提供する取引認証用の店舗ＫＷ、決済装置１００からの決済確認結果、注文受付の日時を示す取引日時、商品発送予定日、納品完了日時、返品情報、商品代金受領の有無、などが含まれる。

店舗装置３００は、決済装置１００に利用者のカード決済を依頼可能な店舗毎に複数存在する。

ネットワーク４００は、デジタル通信を可能とするのであれば、どのような通信回線でも構わない。また、有線回線か無線回線の区別も必要としない。また、有線回線と無線回線の混在であっても構わない。

図２に、本実施例における決済装置１００、購入者端末２００、店舗装置３００の間で行われる全体的な概要処理フローを示す。

Ｓ１で、購入者端末２００のメール手段２２０は、決済装置１００に対して、決済確認メールの返信文面のどこに決済確認情報を挿入するかを示す電子メールを送信することで、決済確認の応答規則に関する登録を申請する。この時、決済確認メールの各フォーマット毎に、購入者端末２００は電子メールを送信する。

Ｓ２で、決済装置１００の決済手段１１０は、Ｓ１で購入者端末２００が発信した電子メールを受信し、申請された応答規則を会員情報ＤＢ１２０へ蓄積する。

Ｓ３で、購入者端末２００のブラウザ手段２１０は、店舗装置３００が提供するウェブ情報を介して、注文情報を店舗装置３００へ送信する。

Ｓ４で、店舗装置３００の取引手段３１０は、Ｓ３で購入者端末２００が送信してきた注文情報を受信し、取引ＤＢ３２０に注文情報を蓄積する。この際、取引手段３１０は、この注文を識別するための取引ＩＤ、利用者に送信する取引認証用の店舗ＫＷを新規に生成し、この注文情報に対応づけて取引ＤＢ３２０に蓄積する。

Ｓ５で、店舗装置３００の取引手段３１０は、Ｓ４で生成した店舗ＫＷを注文受付確認情報とともに購入者端末２００へ送信する。具体的には、ウェブ情報として購入者端末２００のディスプレィ上に注文受付確認情報を表示しても、あるいは、購入者端末２００に対して電子メールで注文受付確認情報を送信しても構わない。

Ｓ６で、購入者端末２００のブラウザ手段２１０あるいはメール手段２２０が、店舗ＫＷを含む注文受付確認情報を受信する。

なお、Ｓ３〜Ｓ６については、店舗ＫＷの生成・送信以外は、既に一般的に行われているインターネットショッピングと同様の動きである。

Ｓ７で、店舗装置３００の取引手段３１０は、決済装置１００に対して、受注した取引に関するカード決済を依頼する。具体的な依頼方法は、決済装置１００の決済手段１１０が提供する決済依頼受付のウェブ情報に、取引手段３１０がアクセスし、そのウェブ情報に対して決済依頼情報を入力することが考えられる。あるいは、取引手段３１０が決済装置１００に電子メールで決済依頼情報を送信してもよい。

Ｓ８で、決済装置１００の決済手段１１０は、店舗装置３００からの決済依頼情報を受信する。

Ｓ９で、決済装置１００の決済手段１１０は、受信した決済依頼情報に含まれるカードＩＤに基づき利用者の連絡先を特定し、同意確認依頼情報を電子メール送信する。同意確認依頼情報は、決済手段１１０によって、定型文ＤＢ１４０で管理される複数のフォーマットのいずれかに基づいて作成される。

Ｓ１０で、購入者端末２００のメール手段２２０は、Ｓ９で決済装置１００が送信した同意確認依頼情報を受信する。

Ｓ１１で、購入者端末２００のメール手段２２０は、利用者によって編集入力された同意確認依頼情報に対する返信メールを、同意確認依頼情報を引用する形式で、決済装置１００へ電子メールを送信する。この返信メールは、Ｓ２で決済装置１００が登録した利用者の応答規則に従って、引用された同意確認依頼情報が編集される。また、この際、返信メールには、Ｓ６で利用者が入手した店舗装置３００発行の店舗ＫＷが含まれる。

Ｓ１２で、決済装置１００の決済手段１１０は、Ｓ１１で購入者端末２００から送信された返信メールを受信する。

Ｓ１３で、決済装置１００の決済手段１１０は、Ｓ１２で受信した返信メールが、同意確認依頼情報作成時に採用されたフォーマットに対応した利用者の応答規則を満たしているか否かを判断し、応答規則を満たしている場合は、この取引の決済を実行する。

以上が、本実施例における全体的な処理フローである。

次に、本実施例に関するより詳細な処理を、図３〜図５を用いて説明する。

図３に、決済処理装置１００の決済手段１１０が、クレジットカード利用者からの、決済確認依頼に対する返信メールの応答規則を登録する処理フローである。

なお、当該処理フローの処理開始以前に、決済手段１１０は、既に、購入者端末２００から、カード利用者のカードＩＤ、氏名、連絡先、および、同意確認依頼情報に用いられるフォーマット毎に定義した個人ＫＷを受信して、図６の会員情報テーブル５００に記録しているものとする。

記録された上記情報は、購入者端末２００のブラウザ手段２１０が、決済装置１００の決済手段１１０が提供した決済確認登録画面のウェブ情報に対して入力されることで、決済手段１１０に送信されるものとする。

なお、この決済確認登録画面には、申請された連絡先に対して、別途決済確認の応答規則を登録するための定義登録メールが送信されること、そして、その定義登録メールに対して個人ＫＷおよび店舗ＫＷをどこにどんな順序で挿入するかの応答規則の実例を編集入力し、決済装置１００へ電子メール返信する必要があることが記載されている。

個人ＫＷは、同意確認依頼された案件について利用者本人が返信していることを証明する認証情報の役割を果たす。本実施例では、フォーマット毎に個別に利用者が定義するが、全フォーマットに共通するものとしてもよい。また、利用者が定義せず決済手段１００が発行するようにすることも可能である。

Ｓ２１で、決済手段１１０は、会員情報テーブル５００の送信先に記録される電子メールアドレスに対して、同意確認依頼用の各フォーマットを用いた電子メールを購入者端末２００のメール手段２２０に送信する。

例えば、図８の定型文テーブル７００には、フォーマットがパターンＡとパターンＢの２種類登録されている。このため、決済手段１１０は、各フォーマットで作成された定義登録メールをそれぞれ購入者端末２００へ送信する。利用者はそれぞれの定義登録メールに応答規則の実例を編集入力して返信することになる。

Ｓ２２で、決済手段１１０は、購入者端末２００から定義登録メールの返信メールを受信する。この返信メール本文の例を、図１０に示す。

図１０の文例９００は、パターンＡのフォーマットで送信された定義登録メールに対する返信メールであり、文例１０００は、パターンＢの場合の返信メールである。いずれも、図８の定型文テーブル７００のデータ項目と比較すると、「■」「▲」という記号以外はフォーマットのデータと同一である。

この「■」と「▲」の記号は、先の決済確認登録画面上で、「■」は個人ＫＷを示し、「▲」は店舗ＫＷを示すものであり、これらの記号を使用して応答規則の実例を編集入力する旨の指示が記載されており、利用者はこの指示に従って返信メールを送信してくる。

Ｓ２３で、決済手段１１０は、受信した返信メールに基づき、各フォーマットに対する応答規則を会員情報テーブル５００に登録する。

たとえば、パターンＡの返信メールの文例９００の場合、フォーマットの「カード決済の」とある冒頭部分の直前に、個人ＫＷ、店舗ＫＷの順に編集入力して返信することが応答規則となる。尚、本実施例は、個人ＫＷと店舗ＫＷは続けて配置することが先の決済確認登録画で予め規定されているものとするが、個人ＫＷと店舗ＫＷをそれぞれ別の位置に入力することを許すようにしてもよい。

決済手段１１０は、返信メールの本文データの中で、「■▲」（あるいは「▲■」）の文字データがどこに記載されているかを特定する。この処理は、ワープロソフトやテキスト編集ソフトといったアプリケーションに搭載される検索機能と同様の処理で実現可能である。

そして、決済手段１１０は、返信メールの発信元の電子メールアドレスに基づき、会員情報テーブル５００の該当する利用者のレコードを特定し、例えば文例９００の場合、その定型Ａ項目の店舗ＫＷ関係項目には、「前」、すなわち、個人ＫＷが店舗ＫＷの前に位置することを示す情報を記録する。さらに、位置項目には、「＋「カー」」、すなわち、「カード決済の」という語句の直前に個人ＫＷおよび店舗ＫＷが編集入力されることを示す情報を記録する。この例では「＋」が個人ＫＷと店舗ＫＷが入る位置を示す。

さらに引き続いて、決済手段１１０は、パターンＢの返信メールの文例１０００に基づいて、会員情報テーブル５００の定型Ｂ項目の店舗ＫＷ関係項目および位置項目に、それぞれ文例１０００に示された内容を示す情報を記録する。

そして、決済手段１１０は、Ｓ２３で会員情報テーブル５００に応答規則情報を正常に登録できたら、Ｓ２４で、該当利用者の送信先の電子メールアドレスを用いて、応答確認依頼の登録が完了した旨の登録完了通知の電子メールを購入者端末２００へ送信して、一連の登録受付処理を完了する。

次に図４を用いて、決済装置１００の決済手段１１０が、店舗装置３００からの決済依頼情報を受信して、同意確認依頼の電子メールを作成し、購入者端末２００に対して送信する、という一連の同意確認依頼メール作成処理フローについて説明する。

Ｓ３１で決済手段１１０は、店舗装置３００からの決済依頼情報を受信する。決済依頼情報には、少なくとも、店舗ＩＤ、利用者のカードＩＤ、この取引の取引ＩＤ、取引日時、利用金額、店舗ＫＷが含まれる。

Ｓ３２で、決済手段１１０は、図７の決済情報テーブル６００に新規レコードを作成し、受信した決済依頼情報を識別するための決済ＩＤを新規生成し記録する。さらに、決済依頼情報に含まれる上記情報を記録する。

Ｓ３３で、決済手段１１０は、同意確認依頼メールを作成するために、図８の定型文テーブル７００を参照し、いずれかのフォーマットを選択し、フォーマットデータを読み込む。この際、Ｓ３２で作成した決済情報レコードの定型文パターン項目に、選択したフォーマットのパターンを記録する。

Ｓ３４で、決済手段１１０は、Ｓ３３で読込んだフォーマットデータを利用して、同意確認依頼メールを作成する。具体的には、フォーマットデータに、Ｓ３２で決済情報テーブル６００のレコードに記録した決済ＩＤ、取引ＩＤ、利用金額を挿入する。さらに、店舗ＩＤを参照し、図９の店舗情報テーブル８００から、対応する店舗名を特定し、店舗名を読み込んだフォーマットデータ内に挿入する。これで、同意確認依頼メールの本文が完成する。

Ｓ３５で、決済手段１１０は、該当する利用者の購入者端末２００へ、Ｓ３４で作成した同意確認依頼メールを電子メール送信する。送信先の電子メールアドレスは、Ｓ３２で記録した決済情報レコードのカードＩＤを参照し、図６の会員情報テーブル５００から対応する会員情報レコード内の送信先項目から電子メールアドレスを特定する。

以上が、決済処理装置１００の決済手段１１０における同意確認依頼メール作成処理フローである。

次に図５を用いて、決済装置１００の決済手段１１０が処理する決済実行処理フローを説明する。この処理は、購入者端末２００からの同意確認依頼メールに対する返信メールを受信し、この返信メールが応答規則を満たしているか否かを判定し、満たしている場合は該当する決済案件を実際に実行する、という一連の処理である。

Ｓ４１で、決済手段１１０は、購入者端末２００からの返信メールを受信する。図１１に返信メール文例１１００を示す。これは、図７の決済情報テーブル６００のレコード内容の決済案件について、図８の定型文テーブル７００におけるパターンＡが採用された同意確認依頼メールが購入者端末２００に送信された場合を想定している。

この返信メール文例１１００内で利用者が編集入力したのは、文例冒頭の「JPNＧＥＴ」の部分である。同意確認依頼メールを購入者端末２００で受信した利用者は、その文面（レイアウトや使用される語句など）から、パターンＡかＢのいずれのフォーマットが採用されたかを識別し、その識別したフォーマットに対応する応答規則に基づいて、受信メールを引用した返信メールを作成し、そこに個人ＫＷおよび店舗ＫＷを編集入力してから、決済装置１００へ返信する。

Ｓ４２で、決済手段１１０は、返信元（つまり利用者）の電子メールアドレス、および、返信メール文面上の決済ＩＤ、取引ＩＤなどに基づいて、決済情報テーブル６００から該当する決済情報レコードを特定する。

Ｓ４３で、決済手段１１０は、Ｓ４２で特定した決済情報レコードの定型文パターン項目から、同意確認依頼メールで採用したフォーマットのパターンを特定する。

Ｓ４４で、決済手段１１０は、Ｓ４２で特定した決済情報レコードから店舗ＫＷを識別し読み込み、かつ、カードＩＤを参照し、図６の会員情報テーブル５００で対応する会員情報レコードから、Ｓ４３で特定したフォーマットパターンに対応する個人ＫＷ、店舗ＫＷ関係、位置、の各項目データを識別し読込む。

Ｓ４５で、決済手段１１０は、Ｓ４４で読み込んだ個人ＫＷが、Ｓ４１で受信した返信メール内に存在するか否かを検索し、個人ＫＷと同一の語句が返信メールに存在しない場合は、Ｓ４９の処理へ進み決済拒否処理（後述）を行う。そして、個人ＫＷと同一の語句が返信メールに存在する場合は、Ｓ４６に進む。

Ｓ４６で、決済手段１１０は、Ｓ４４で読み込んだ店舗ＫＷが、Ｓ４１で受信した返信メール内に存在するか否かを検索し、店舗ＫＷと同一の語句が返信メールに存在しない場合は、Ｓ４９の処理へ進み決済拒否処理（後述）を行う。そして、店舗ＫＷと同一の語句が返信メールに存在する場合は、Ｓ４７に進む。

Ｓ４７で、決済手段１１０は、Ｓ４４で読み込んだ位置（個人ＫＷと店舗ＫＷがメールに入力される位置）、および、店舗ＫＷ関係（個人ＫＷが店舗ＫＷの前に連結されるのか、あるいは、後ろに連結されるのか）の情報に基づき、Ｓ４１で受信した返信メール内で、個人ＫＷと店舗ＫＷがこの２つの条件を満たすか否かを判定する。もし、この２つの条件を同時に満たすものでなければ、Ｓ４９の処理へ進み決済拒否処理（後述）を行う。逆に、この２つの条件を満たす場合は、Ｓ４８に進む。

Ｓ４８で、決済手段１１０は、Ｓ４１で受信した返信メールが利用者の応答規則に沿ったものであると判定し、Ｓ４２で特定した決済情報レコードの決済を実際に実行し、同レコードの確認結果項目に決済を実行したことを示す情報を記録する。この処理は、通常のカード決済における決済処理と同等の処理である。

Ｓ４９で、決済手段１１０は、Ｓ４１で受信した返信メールが利用者の応答規則に沿っていないと判定し、Ｓ４２で特定した決済情報レコードの確認結果項目に決済できないことを示す情報を記録する。そして、決済手段１１０は、店舗装置３００に対して、取引ＩＤに該当する取引について利用者本人と証明できない旨の決済拒否通知を電子メール送信する。そして、実際の決済処理は行わないままとする。

以上が、決済装置１００の決済手段１１０が行う一連の決済実行処理フローである。

なお、本実施例では、決済同意確認を登録すると、全ての取引案件について同意確認依頼メールが発行されるものとして説明したが、利用者や店舗の希望によって、例えば、取引金額が所定値以上のものに限ることも可能である。

利用者が上記のような限定を行う場合、決済同意確認の登録画面上から、決済同意確認を希望する取引金額の下限を入力し、決済装置１００は、図６の会員情報テーブル５００にこの情報を記録するための下限価格項目を設けてこれを記録する。

そして、決済装置３００は、Ｓ３２の決済情報登録ステップを処理すると、決済情報の利用金額が会員情報テーブル５００に記録された下限価格項目の金額と比較して、利用金額が下限価格未満ならば、同意確認メールを作成・送信せず、すぐにＳ４８の決済処理を行うのである。

一方、店舗側が上記のような限定を行う場合は、店舗装置３００が予め下限価格を決済装置３００に通知し、決済装置１００は、図９の店舗情報テーブル８００に下限価格項目をさらに設けて、通知された下限価格項目を記録する。

そして、決済装置３００は、Ｓ３２の決済情報登録ステップを処理すると、決済情報の利用金額が店舗情報テーブル８００に記録された下限価格項目の金額と比較して、利用金額が下限価格未満ならば、同意確認メールを作成・送信せず、すぐにＳ４８の決済処理を行うのである。

また、本実施例は、インターネットショピングを想定して説明したが、実際の店頭販売においてももちろん適用可能である。この場合、Ｓ３の購入依頼は、直接店舗におけるクレジットカードリーダーに利用者のカードを読み込ませることになる。また、Ｓ５の注文通知、つまり、店舗ＫＷの通知は、プリントされたレシートに印字したり、口頭その他で利用者に直接店員が伝達する場合が生じる。

また、本実施例では店舗ＫＷを発行したが、店舗装置３００が店舗ＫＷを発行せず、個人ＫＷだけで使用した応答規則を設定することも可能である。逆に、個人ＫＷを不要として、店舗ＫＷだけを使用した応答規則を設定することも可能である。いずれの場合においても、会員情報テーブル５００の店舗ＫＷ関係項目に相当する情報は管理しないことになる。

また、本実施例では、クレジットカード決済を想定して説明したが、取引に関するそれ以外の与信や決済形態にも適用することが可能である。
（付記１）利用者の取引を決済する決済装置であって、
利用者に上記決済実行の同意確認を求める確認依頼通知に関するフォーマットが管理されるフォーマット蓄積手段と、
上記フォーマットに対して利用者が応答する応答情報に関する応答規則が、利用者毎に対応づけられて管理される応答規則蓄積手段と、
上記フォーマットに沿って作成された確認依頼通知情報を利用者の連絡先へ送信し、利用者端末からの応答情報を受信し、該応答情報に関する連絡先となる利用者に対応づけられた応答規則を上記応答規則蓄積手段から参照し、受信した該応答情報が参照された該応答規則を満たすか否かを判定し、該判定結果が応答規則を満たす場合、上記取引の決済を実行する決済手段
を備えることを特徴とする決済装置。
（付記２）付記１記載の決済装置であって、
上記フォーマットは複数管理され、上記応答規則は各フォーマット毎に定められ、
上記決済手段は、複数の上記フォーマットのいずれかを用いて確認依頼通知情報を作成し、使用したフォーマットに対応する上記利用者の応答規則を参照し上記応答情報を判定する
ことを特徴とする決済装置。
（付記３）付記１記載の決済装置であって、
上記応答規則は、応答情報に含まれるべき特定の認証情報、および、応答情報における該認証情報の入力されるべき位置が規定される
ことを特徴とする決済装置。
（付記４）付記３記載の決済装置であって、
上記特定の認証情報は、利用者本人を示す本人認証情報、または、上記取引が真に存在することを証明する取引認証情報である
ことを特徴とする決済装置。
（付記５）付記４記載の決済装置であって、
上記応答規則は、上記本人認証情報と上記取引認証情報の２つの認証情報を含み、かつ、この２つの認証情報の位置関係を規定する
ことを特徴とする決済装置。

本発明のシステム構成例を示す図である。本発明の全体処理フローを示す図である。本発明の決済装置１００における、登録受付処理フローを示す図である。本発明の決済装置１００における、同意確認依頼メール作成処理フロー示す図である。本発明の決済装置１００における、決済実行処理フロー示す図である。本発明の会員情報テーブル５００を示す図である。本発明の決済情報テーブル６００を示す図である。本発明の定型文テーブル７００を示す図である。本発明の店舗情報テーブル８００を示す図である。本発明の登録メール文例９００、１０００を示す図である。本発明の返信メール文例１１００を示す図である。

符号の説明

１００決済装置
１１０決済手段
１２０会員情報ＤＢ（データベース）
１３０決済情報ＤＢ（データベース）
１４０定型文ＤＢ（データベース）
１５０店舗情報ＤＢ（データベース）
２００購入者端末
２１０ブラウザ手段
２２０メール手段
３００店舗装置
３１０取引手段
３２０取引ＤＢ（データベース）
４００ネットワーク
５００会員情報テーブル
６００決済情報テーブル
７００定型文テーブル
８００店舗情報テーブル
９００定義登録メール（パターンＡ）文例
１０００定義登録メール（パターンＢ）文例
１１００返信メール文例

Claims

利用者の取引を決済する決済装置であって、
利用者に上記決済実行の同意確認を求める確認依頼通知に関するフォーマットが管理されるフォーマット蓄積手段と、
上記フォーマットに対して利用者が応答する応答情報に関する応答規則が、利用者毎に対応づけられて管理される応答規則蓄積手段と、
上記フォーマットに沿って作成された確認依頼通知情報を利用者の連絡先へ送信し、利用者端末からの応答情報を受信し、該応答情報に関する連絡先となる利用者に対応づけられた応答規則を上記応答規則蓄積手段から参照し、受信した該応答情報が参照された該応答規則を満たすか否かを判定し、該判定結果が応答規則を満たす場合、上記取引の決済を実行する決済手段
を備えることを特徴とする決済装置。
請求項１記載の決済装置であって、
上記フォーマットは複数管理され、上記応答規則は各フォーマット毎に定められ、
上記決済手段は、複数の上記フォーマットのいずれかを用いて確認依頼通知情報を作成し、使用したフォーマットに対応する上記利用者の応答規則を参照し上記応答情報を判定する
ことを特徴とする決済装置。
請求項１記載の決済装置であって、
上記応答規則は、応答情報に含まれるべき特定の認証情報、および、応答情報における該認証情報の入力されるべき位置が規定される
ことを特徴とする決済装置。