JP2004519022A - 商決済を確認するためのシステムおよび方法 - Google Patents

Abstract

システムおよび方法が、カード所有者、商人、及びクレジットカード会社の間の商決済の確認のために開示される。カード所有者は完全なクレジットカード番号を使用して、商人から購入をする。商人は、クレジットカード会社（７０２）に承認のための決済承認要求を提示する。クレジットカード会社は、カード所有者（７１０）に決済承認要求を確認するだけでなく決済承認要求（７０４，７０６）の従来の信用承認をも実行する。決済承認要求がクレジットカード会社によって従来通りに承認され、カード所有者（７１４）によって確認された後にのみ、承認は商人へ送られる。カード所有者又はクレジットカード会社は、決済承認要求の確認を始めることができる。１つあるいは多くの前もっての確認基準が決済承認要求に含まれているデータによって満たされる場合、決済承認要求をまた自動的に確認することができる。カード所有者は前もっての確認基準を最初に決定しまたは修正することができる。

Description

【０００１】
（背景）
（発明の技術分野）
本発明は、概ね電子商取引に関し、より詳しくは、安全な電子決済を提供するためのシステム及び方法に関する。更に、本発明は口座所有者による電子購入の確認を促進するシステム及び方法に関する。
【０００２】
（従来技術の説明）
電子手段によって売買を行う電子商取引は、現代社会においてありふれたものになった。インターネット（最も明確にはワールドワイド・ウェブ）が社会主流化するにつれて、電子商取引はコンピュータによってどのような人の家にも或いはオフィスへも入ってくるようになった。いくつかの理由のために、ますます多くの人々が、彼らの家庭用コンピュータ或いは業務用コンピュータから取引（例えば、買物）をするようになってきた。例えば、インターネットに基づいたビジネスは概して割引価格で商品を提示するので、消費者はインターネット商取引に引きつけられる。さらに、インターネットは１日の内２４時間アクセスが可能であるため、消費者は都合のよい時に購入をすることができる。
【０００３】
ほとんどの電子購入の主な支払い手段はクレジットカードである。クレジットカードは、カード所有者の予め決められたクレジット口座を表わす。カード所有者はクレジットカードを使用して、商人から電子購入をする。商人は、購入認可のためにクレジットカード会社に購入要求を提示する（クレジットカード番号全体を送信することを含んで）。その後、クレジットカード会社は商人にクレジットカード決済を認可するか或いは否認する。購入が承認される場合、予め決められたクレジット口座は、購入額が引き落とされる。
【０００４】
クレジットカードは、カード所有者にとって多くの長所がある。例えば、クレジットカードにアクセスする人は、残高チェックと口座維持をすると同時に、銀行で費やす時間を少なくすることができる。さらに、クレジットカードは、多額の現金を運ぶ必要をなくす。さらに、小切手または為替によって購入承認が遅れる一方で、クレジットカードを使用する場合には購入承認は自動化される。したがって、電話または通信販売による購入を行なう場合、クレジットカードの使用は郵便で支払金額を送ることに関連した遅れをなくす。
【０００５】
電子商取引が増加した結果、クレジットカードの安全性はカード所有者にとっての主な関心事になった。いくらかのカード所有者は、クレジットカード番号の不正使用や傍受の恐れのために、クレジットカードを使用してインターネット上で商品を購入することを警戒している。ほとんどのインターネット・ウェブ・ページはハイパーテキスト・マークアップ言語（ＨＴＭＬ）で書かれており、この言語は情報転送するにあたって無防備な方法を使用するので、それらの恐れは当然である。インターネットの安全性の問題と戦うために、いくつかの商業ネットワークは、インターネット上でなされる決済を安全にするために暗号化技術を使用する。洗練された犯罪者はそのような暗号化技術を判読することができるので、関係のある消費者はほとんど安心することができない。さらに、クレジットカード番号の送信は安全であったとしても、カード番号は受信コンピュータに格納されているので、そのコンピュータに侵入することによって盗むことができる。さらに、不正なウェイター、店員およびその他同種のものによって使用されるポケットスキャナのような装置は、クレジットカード番号をカードから直接盗むことができる。
【０００６】
いくつかの商用口座（例えば当座預金口座）は、クレジットカードと同じ安全性の危さに直面するデビットカードを提示する（もし増加しなければ）。デビットカードはクレジットカードに似ているが、デビット取引を終えるために、購入の時にカード番号に加えてカード所有者の暗証番号（ＰＩＮ）を与えなければならない。さらに、デビットカードは、それがリンクされる口座（典型的には当座預金口座）から資金を取り出す。多くの場合、デビットカード取引で与えられたＰＩＮは、デビットカードがリンクされる口座にアクセスするために（例えばＡＴＭ機械あるいは電話によって）使用されるＰＩＮと同じである。デビットカードを使用してなされた購入取引が傍受されそして不正に使用される場合、泥棒が、関連するデビット口座から資金を直接取り出すとともに、デビットカード番号およびＰＩＮを使用して購入することができる。
【０００７】
改善されたクレジットカード安全性に対する関心は、安全な電子商決済を保証する方法を提供するように、クレジットカード会社および商人に圧力をかけた。例えば、米国特許６，０１２，１４４号（ピケット）は、クレジットカード番号を２つの部分に分割し１台以上のサーバコンピュータの分離データ記憶装置に各部分を格納することにより、インターネット・クレジットカード決済の安全性を維持する方法について記述している。カード所有者は、クレジットカード番号のどの部分が各記憶装置へ送られるかを決定し、次に、いくつかの処理コード（パスワード）を確保する。購入が確認されるように、処理コードは自動電話呼び出しによってカード所有者からその後得られる。この方法論にはいくつかの不利な点がある。最初に、ピケットの方法は、完全なクレジットカード番号がそのままでは商人に送信されないのでカード所有者は多大な時間を消費してしまう。もっと正確に言えば、カード所有者はクレジットカード番号を解析し、スライシングコードを算出しなければならない。さらに、カード所有者は決済を確認するためにスライシングコード（それは各決済毎に異なっていてもよい）を思い出さなければならない。さらに、セキュリティソフトウェアを提供する負担は商人に降りかかる。それはそのようなシステムを提供することに同意するかもしれないし、同意しないかもしれない。したがって、カード所有者がそのようなシステムのない商人から購入したければ、セキュリティは提供されない。
【０００８】
米国特許第５，９０３，７２１号（シクストウス）は、改善されたクレジットカード決済セキュリティを提供する代替の方法について記述している。シクストウスの方法は、インターネット上で購入をするカード所有者を含んでいる。カード所有者を確認するために使用される「トラストサーバ」は、カード所有者のＩＰ（インターネットプロトコル）アドレスと共に購入要求を受信する。トラストサーバによって受け取られたＩＰアドレスがそのカード所有者の登録済みのＩＰアドレスと一致する場合、購入が確認され、購入が承認されるか或いは否認される「クレジット決済所」へ転送される。機密事項を扱うクレジットカード情報が安全でないネットワーク上に送信されない一方で、決済は、トラストサーバで登録されたＩＰアドレスをもつコンピュータからのみ行うことができる。さらに、いくつかのインターネット・サービス・プロバイダー（ＩＳＰ）は動的なＩＰアドレシングを使用する。ユーザがＩＳＰのネットワークにログオンするときに一時的なＩＰアドレスが割り当てられる。したがって、動的なＩＰアドレシングを利用するインターネット・サービス・プロバイダを持っているカード所有者は、シクストウスによって教えられた決済セキュリティシステムを使用することができない。
【０００９】
別の例として、米国特許第５，９９１，７３８号（オグラム）は、暗号化ソフトウェアを利用する方法を教えている。オグラムの方法論を使用する商人から商品を購入したいカード所有者は、その商人のコンピュータから暗号化ソフトウェアをダウンロードする。暗号化ソフトウェアは商人への送信の前にどんな機密情報もコード化する。オグラムの方法論の１つの不都合な点は、カード所有者との安全な購入確認プロセスの不足である。さらに、使用された暗号化技術は送信の間に傍受され判読されることができる。
【００１０】
必要なものは、安全かつ信頼できるクレジットカード決済処理を提供するシステム及び方法である。さらに必要なものは、商人に透明な安全かつ着実なクレジットカード決済を提供するシステム及び方法である。さらに必要なものは、クレジットカード決済のカード所有者確認を促進し、カード所有者のクレジットカードの各試用の迅速な通知を提供するシステム及び方法である。
【００１１】
（発明の要約）
本発明は、商人に透明な安全かつ着実なクレジットカード決済処理を提供するシステム及び方法の提供により、従来技術に関連した問題を克服する。本発明は、商人に承認を送信するに先立って各クレジットカード決済のカード所有者確認を促進し、口座所有者にクレジットカードの各使用の試みを即座に通知する。
【００１２】
口座所有者と商人の間の商決済を処理するために、データとコードを実行するための処理ユニット、データとコードを格納するためのメモリ装置からなるコンピュータシステムが開示される。格納され実行されるコードは、決済承認要求を受信するために機能する商人通信モジュールを含んでおり、その通信モジュールは、完全な口座番号、受信された決済承認要求を確認するための口座所有者との個別の接続を促進するのに機能する口座所有者通信モジュール、及び決済承認要求に応答し決済承認要求が口座所有者によって確認される場合にのみ商人へ承認を送信するために機能する認可モジュールを含んでいる。
【００１３】
特定の実施形態では、認可モジュールは双方向型の確認モジュールを含んでいる。この確認モジュールは、決済承認要求の受信に応答し、口座所有者と接続を始めるのに機能する。更なる特定の実施形態では、コンピュータシステムはさらにネットワークインターフェイスを含んでおり、双方向型の確認モジュールはネットワークインターフェイスを介して口座所有者に電子メッセージを送信するために機能し、送信された電子メッセージへの返答の受信の際に決済承認要求を確認するためにさらに機能する。
【００１４】
他の特定の実施形態では、コンピュータシステムがさらに電子通信装置を含み、双方向型の確認モジュールは、口座所有者に自動電話呼び出しをするために機能し、口座所有者に決済承認要求の一部を唱え、口座所有者から確認指示を受ける。更に特定の実施形態では、双方向型の確認モジュールが、決済承認要求の一部を唱える前に認証コードを要求するために機能する。
【００１５】
随意的に、双方向型の確認モジュールは、口座所有者がシステムと通信を始めるのを待つ。代わりに、システムは、未決の決済承認要求を確認するために口座所有者と通信を始める。
【００１６】
特定の実施形態では、口座所有者からの指示に応答する認可モジュールが、口座所有者からの更なる入力なしにその後の決済承認要求を自動的に確認することにより、選択的に確認プロセスを無効にすることができる。
【００１７】
更に別の特定の実施形態において、認可モジュールは、口座所有者が前もって定義した期間の経過に先立って決済承認要求を確認していなければ自動的に決済承認要求を無効するマスター確認モジュールを含んでいる。マスター確認モジュールは、決済承認要求が無効される場合に口座所有者に通知を送信するためにさらに機能する。
【００１８】
更に別の特定の実施形態において、決済承認要求は、第三者金融機関からの確認要求を含み、認可モジュールは第三者金融機関に確認の証印を送るために機能する。
【００１９】
１つの方法がまた、口座所有者と商人の間の安全かつ着実な商決済の提供のために開示される。その方法は、商人からの個別の通信によって口座所有者に決済承認要求を電子的に確認して、口座所有者の口座を識別する完全な口座番号を含む決済承認要求を受信することを含んでいる。また、決済承認要求が口座所有者によって確認された場合にのみ、商人に承認を送信することを含んでいる。
【００２０】
特定の方法では、口座所有者に決済承認要求を確認するステップは、決済承認要求を確認するように口座所有者に促すことを含んでいる。更なる特定の方法では、口座所有者へ促すことは電子メッセージを送信することを含んでいる。更になる特定の方法では、決済承認要求を確認するステップは、電子メッセージへの返答を受信することを含んでいる。別の特定の方法では、口座所有者へ促すことが口座所有者に自動電話呼び出しをし、口座所有者との接続を確立し、決済承認要求の少なくとも１つの部分を唱え、口座所有者から確認指示を受けることを含んでいる。更に特定の方法では、口座所有者は、決済承認要求の少なくとも１つの部分を唱える前に認証がなされる。
【００２１】
代替の方法は、口座所有者がコンピュータシステムと通信をすることにより確認プロセスを始めるのを待つことを含んでいる。特定の方法において、確認は、ネットワークあるいは電話接続上の口座所有者によって始められ、ネットワークまたは電子通信の装置を介して口座所有者から接続要求を受信すること、口座所有者との接続を確立すること、口座所有者を認証すること、口座所有者へ決済承認要求の少なくとも１つの部分を送信すること、決済承認要求に関して口座所有者から確認指示を受信することを含んでいる。
【００２２】
随意的に、確認プロセスは、口座所有者によって選択的に有効或いは無効にされることができる。
【００２３】
別の特定の方法では、電子的に決済承認要求を確認するステップは、前もって定義した時間内に口座所有者が決済承認要求を確認しなければ決済承認要求を無効することを含んでいる。更に特定の方法において、決済承認要求が無効された場合、通知が口座所有者に送信される。
【００２４】
更に別の特定の方法では、商人から決済承認要求を受信するステップは、商人から決済承認要求を受け取った第三者金融機関から確認要求を受信することを含んでいる。商人に承認を送信するステップは、第三者金融機関への確認の証印を送ることを含んでいる。
【００２５】
商人と口座所有者の間で或る決済を前もって確認するためのシステム及び方法も開示される。特定の実施形態では、コンピュータシステムが、データおよびコードを処理するための処理ユニットと、データおよびコードを格納するためのメモリ装置とを含んでいる。データは、口座所有者に関連した少なくとも１つの前もっての確認基準を含んでいる。コードは、商人から決済承認要求を受信するための商人通信モジュール、および認可モジュールを含んでいる。認可モジュールは、前もっての確認基準と決済承認要求を比較する。もし前もっての確認基準が満たされるならば、決済承認要求を自動的に確認し、それにより承認プロセスを終えるに先立って口座所有者から決済承認要求の直接の確認を得る必要が除去される。
【００２６】
特定の実施形態では、前もっての確認基準は、口座所有者に関連した複数の前もっての確認基準を含んでおり、決済承認要求は、前もっての確認基準のいずれかの１つが満たされる場合、確認される。代わりの実施形態では、もし複数の前もっての確認基準がすべて満たされなければ、決済承認要求は自動的に確認されない。有用な前もっての確認基準の例は、制限はされないが、商人識別子、決済額（例えば購入代金）、決済日、決済時刻、或いは口座所有者が便利に感じるかもしれない他の基準を含んでいる。随意的に、コードはさらにカード所有者通信モジュール及び／又は口座所有者による前もっての確認基準の修正を促進する双方向型の確認モジュールを含んでいる。１つの実施形態では、前もっての確認基準が口座所有者によって修正されるまで、自動的に決済承認要求を確認することができないように、前もっての確認基準は最初にセットされる。代案として、口座所有者は初期の前もっての確認基準を決定することができる（例えば口座が開かれるときに）。
【００２７】
（詳細な説明）
本発明は、口座所有者に各電子決済を確認することにより安全かつ着実な電子決済を提供する新規なシステムおよび方法を提供し、これにより、先行技術に関連した問題を克服する。以下の記述では、多数の明確な詳細が発明についての完全な理解を提供するために述べられる。例えば、クレジットカード会社による前もっての確認、カード所有者によって始められる確認、等である。しかしながら、当業者は、本発明がこれらの明確な詳細とは別に実行されてもよいことを認識するであろう。他の例では、有名な電子商取引慣習（例えば電子の信用要求／承認プロセス、コンピュータ・オペレーティング・システム、通信ソフトなど）の詳細は、いたずらに本発明を不明瞭にしないように省略された。
【００２８】
本発明は、以下の図面を参照して説明される。この図面において、類似の参照番号は本質的に同様の要素を示す。
図１は、カード所有者１０２、商人１０４、クレジットカード会社１０６、および第三者確認会社１０８を含むシステム１００を示すブロック図であり、各々は物理的なネットワークメディア１１２（１‐４）（例えば電話線、同軸ケーブルなど）によってインターネットワーク１１０（例えばインターネット）に接続されている。カード所有者１０２、商人１０４、クレジットカード会社１０６、及び確認会社１０８はまた、別の物理的なネットワークメディア１１４（例えば電話線）を介して通信可能になっている。
【００２９】
カード所有者１０２は、クレジットカード会社１０６によって提供される口座を識別する番号をもつクレジットカードを所有する。商人１０４は、クレジットカード番号を使用して、カード所有者１０２によりインターネットワーク１１０を介して購入可能な品物あるいはサービスを提示する。カード所有者１０２は、クレジットカード番号全体の提供により、商人１０４からの電子購入要求をする。この購入はインターネットワーク１１０上、物理的なネットワークメディア１１４上、或いは個人で同様になされてもよい。購入要求の受取に応答する商人１０４は、クレジットカード会社１０６に決済承認要求（ＴＡＲ）を提示する。
【００３０】
その後、承認か否認が商人１０４に出される前に、ＴＡＲは２つの認可を受ける。最初に、購入要求はクレジットカード会社１０６による標準の信用承認を受ける。信用承認に続いて、購入要求は、クレジットカード会社１０６によって、あるいは確認会社１０８によってカード所有者１０２に確認される。確認は、インターネットワーク１１０あるいは物理的なネットワークメディア１１４のいずれかの上で実行される。確認に続いて、購入がクレジットカード会社１０６によって承認され、カード所有者１０２によって確認される場合、承認は、物理的なネットワークメディア１１４あるいはインターネットワーク１１０を介して商人１０４に送信される。
【００３１】
この特定の実施形態では、クレジットカードが電子商取引を促進する。しかしながら、当業者は、本発明がクレジットカードを使用してなされた購入に制限されないことを理解するであろう。口座番号の送信を含む安全かつ着実な電子決済を促進するために、本発明は、任意のタイプの口座（例えばデビットカード）と組み合わせて使用されてもよい。以下の記述では、クレジットカード会社１０６が確認プロセスを実行することがさらに理解される。しかしながら、確認プロセスは、第三者確認会社１０８によって随意的に実行されてもよい。そのような実施形態では、クレジットカード会社１０６は確認会社１０８に確認要求を送信する。その後、確認会社１０８は、カード所有者１０２に決済要求を確認し、クレジットカード会社１０６に確認（決済要求が確認されるか或いは無効にされるかを示して）の証印を送る。
【００３２】
図２は、物理的なネットワークメディア１１２（３）を介してインターネットワーク１１０に接続されたサーバ２００（例えばＨＴＴＰインターネットサーバ）のブロック図である。この特定の実施形態では、サーバ２００は、クレジットカード会社１０６の決済サーバであり、このサーバはクレジットカード会社１０６のためのクレジットカード決済処理をする。サーバ２００は、処理ユニット（ＰＵ）２０２、ネットワークインターフェイス２０４、システムバス２０６、不揮発性のメモリ２０８、少なくとも１つの入力／出力（Ｉ／Ｏ）コントローラー２１０、システムクロック２１２、電子通信装置２１４およびワーキングメモリ２１６を含んでいる。ＰＵ ２０２は、サーバ２００にその意図した機能（例えばクレジットカード決済の処理）を実行させるためにワーキングメモリ２１６に含まれているデータおよびコードを実行する。システムバス２０６は、サーバ２００の様々な構成要素間の相互通信を促進する。
【００３３】
サーバ２００は、ネットワークインターフェイス２０４を介してインターネットワーク１１０上で通信する。ネットワークインターフェイス２０４（例えばイーサネット（登録商標）・アダプタ・カード）はインターネットワーク１１０上にデータパケットを送信し、またインターネットワーク１１０からデータパケットを受信する。従って、サーバ２００がインターネットワーク１１０を介してカード所有者１０２及び商人１０４と通信することを可能にする。不揮発性のメモリ（例えば読み出し専用メモリ、あるいは１つ或いはそれ以上のハードディスクドライブ）は、サーバ２００の電源が落とされる場合さえ、保持されるデータおよびコード（例えばブーツコードおよびプログラム）のために記憶装置を提供する。Ｉ／Ｏコントローラー２１０は、サーバ２００のシステム管理者のためにユーザインターフェース装置（示されていない）のための接続を管理する。Ｉ／Ｏ装置は、典型的にはサーバ２００と管理者の間の通信を促進するキーボード、マウス、モニタ、プリンタおよび他のそのような装置を含んでいる。サーバ２００は、適切な日付および時刻を維持し、要求された日付と時刻のデータを提供するシステムクロック２１２をさらに含んでいる。
【００３４】
サーバ２００は、リモートシステム間あるいはメンバーとサーバ２００間のデータもしくは音声接続いずれかの確立のための電気通信装置２１４（例えばモデム、あるいは電話）を更に含む。リモートシステムの例は、カード所有者１０２、商人１０４あるいは確認会社１０８によって所有されたコンピュータを含む。特定の実施例では、カード所有者１０２との音声接続が未決の複数のＴＡＲを確認するために用いられる。
【００３５】
ワーキングメモリ２１６（例えばランダム・アクセス・メモリ）は、サーバ２００にダイナミックメモリを供給し、システム開始時にワーキングメモリ２１６に読み取られる実行可能なコード（例えば、オペレーティングシステム２１８）を含む。オペレーティングシステム２１８は、ワーキングメモリ２１６に読み取られた他の全てのモジュールの制御及び実行を促進する。
ワーキングメモリ２１６は更に信用承認要求キュー（ＣＡＲＱ）２２０、カード・所有者リストモジュール２２２、カード所有者通信モジュール２２４、認可モジュール２２６、確認未決キュー（ＶＰＱ）２２８、購入履歴モジュール２３０及び商人通信モジュール２３２を含む。
前述のモジュール及びキューの各々は初期化され、当業者に既知の方法を用いて、非揮発性のメモリ２０８からの起動でワーキングメモリ２１６に読み取られる。任意に、前述のモジュール及びキューは代わりの大量データ記憶装置からのワーキングメモリ２１６に読み取られることができ、これら装置は、ＣＤ−ＲＯＭ、テープあるいは高容量リムーバブルデータ格納ディスク（例えば、イオメガ（Ｉｏｍｅｇａ）のＪａｚ（登録商標）あるいはＺｉｐ（登録商標）を持つドライブ）を含むがこれらに限定はされない。
【００３６】
認可モジュール２２６は、複数のＴＡＲの承認および確認を制御し調整する。上記されるように、確認が第三者確認会社１０８によって処理される代わりの実施例では、認可モジュール２２６は確認会社１０８に確認のための要求を送信し、かつ確認会社１０８から確認の基準を受信するために作動する。
確認のための送信された要求は、製品詳細、購入代金、商人の名前のような購入要求あるいは確認のためのカード所有者への決済を識別するのに有用な他の情報と関係する情報を含む。
確認の受信された基準は、例えば、特定の決済がカード所有者によって確認されたか放棄されたことを示すコードを含む。随意に、カード所有者１０２によって与えられた指示に応答する認可モジュールは確認プロセス（例えば、自動的に特定の商人の決済あるいは全ての決済を確認する）を選択的に無効にするためにさらに機能する。
確認プロセスを無効にする指示は、確実なネットワーク上（例えば電話または郵便による）のカード所有者１０２によって通常開始される。
【００３７】
商人通信モジュール２３２は、商人１０４から複数のＴＡＲを受信し、またネットワーク・インターフェース２０４あるいは電気通信装置２１４を介して商人１０４に承認又は否認を送信する。
カード所有者通信モジュール２２４は、インターネットワーク１１０あるいは物理的なネットワークメディア１１４を介して、サーバ２００とカード所有者１０２の間の通信を管理する。カード所有者リストモジュール２２２は、現在の顧客（カード所有者１０２を含む）の個人及び口座情報を確認するためのデータベースである。当業者は、カード所有者リストモジュール２２２は典型的には大きなファイルであることを理解するであろう。
したがって、カード所有者リストモジュール２２２がメモリ２１６の中で示されている一方で、必要に応じて、カード所有者リスト２２２から出し入れされる、リスト全体の一部分を持つ非揮発性のメモリ２０８のような大量データ記憶システムに顧客ファイル全体が格納されることが理解されるべきである。
【００３８】
信用承認要求キュー（ＣＡＲＱ）２２０は、認可モジュール２２６によって従来の信用承認を待つ未決の複数のＴＡＲのための記憶装置を供給している。商人通信モジュール２３２は、定期的にネットワーク・インターフェース２０４及び商人１０４から任意に入って来る複数のＴＡＲがあるかどうかを決める電気通信装置２１４を得て、ＣＡＲＱ２２０に任意のそのような要求を送信する。
【００３９】
確認未決キュー（ＶＰＱ）２２８は、カード所有者１０２によって確認を待つ未決の複数のＴＡＲのための記憶装置を提供する。有効な口座に対応するものとして、ＴＡＲが確認され形式的な信用承認を得た後で、認可モジュール２２６はＣＡＲＱ２２０からＶＰＱ２２８に複数のＴＡＲを送信する。承認され否認されるまで、あるいは前もって定めた期間が経過するまでＴＡＲはＶＰＱ２２８に残る。
【００４０】
一旦ＴＡＲが承認されるかあるいは否認されれば、ＴＡＲの記録は購入履歴モジュール２３０へ送信される。購入履歴モジュール２３０は、前もって定めた期間（例えば３０日の期間）の間の以前の口座の活用に関する情報を格納する。
前もって定められた期間の経過の際、決済の書面での記録（例えば請求書、電子請求書など）のポイントがカード所有者１０２まで伝えられ、各有効期限が切れたＴＡＲは、ワーキングメモリ２１６からより永続的な記憶メディア（例えば磁気テープ）に送信される。
【００４１】
図３は、信用承認モジュール３０２、マスター確認モジュール３０４、双方向型の確認モジュール３０６及び商人応答モジュール３０８を含む認可モジュール２２６のブロック図を示す。信用承認モジュール３０２は、当業者に既知の手段によってＣＡＲＱ２２０に含まれている各ＴＡＲの従来の信用承認を実行する。
マスター確認モジュール３０４は、認可と確認のプロセスを調整し、認可モジュール２２６の全面的な制御を担う。双方向型の確認モジュール３０６は、カード所有者１０２に対する確認を実行する。商人応答モジュール３０８は、決済承認あるいは決済否認のいずれかの送信により、商人１０４と最後の通信を開始する。
【００４２】
図４は、本発明の特定の実施例での使用に適している信用承認要求データ構造４００の例を示す。当業者は、データ構造４００を、記録４０２（１−ｎ）のリンクしたリストと認めるであろう。各記録４０２（１−ｎ）は、未決のＴＡＲを表し、また、完全なクレジットカード番号４０４、購入詳細４０６、購入代金４０８、商人情報４１０、購入の日時の情報４１２、確認されたフラッグ４１４、確認が開始されたフラッグ４１５、承認されたフラッグ４１６、否認されたフラッグ４１８及びポインター４２０を含む。
完全なクレジットカード番号４０４、購入詳細４０６、購入代金４０８、商人情報４１０及び購入の日時の情報４１２は、サーバ２００によってＴＡＲを持つ商人１０４から受信される。
確認されたフラッグ４１４、承認されたフラッグ４１６、及び否認されたフラッグ４１８は、より詳細に以下に説明されるように認可プロセスに記録４０２の状態を示すために用いられる。
ポインター４２０は、リスト中の次の記録４０２（＋１）のメモリアドレスを示す。最後の記録４０２（ｎ）は、記録４０２（ｎ）がリスト中の最後の記録であることを示すリスト値４２２の終了を含む。
【００４３】
確認されたフラッグ４１４、確認が開始されたフラッグ４１５、承認されたフラッグ４１６、否認されたフラッグ４１８は、それぞれの記録の状態を示すシングル・ビット・フラッグである。確認されたフラッグ４１４は、関連するＴＡＲが確認されたかどうか（例えば、確認されたフラッグ４１４＝１）、ＴＡＲが確認されていないかどうか（例えば、確認されたフラッグ４１４＝０）を示す。確認が開始されたフラッグ４１５は、サーバ２００が、カード所有者１０２に対する確認プロセスを開始したかどうかを示す。
承認されたフラッグ４１６は、関連するＴＡＲが承認されたかどうか（例えば、承認されたフラッグ＝１）を示す。否認されたフラッグ４１８は、関連するＴＡＲが否認されたかどうか（例えば否認されたフラッグ＝１）を示す。
【００４４】
図５は、カード所有者リストモジュール２２２にカード所有者データを格納するのに適しているカード所有者データ構造５００の例を示す。当業者は、データ構造５００が記録５０２（１−ｎ）のリストにリンクされており、この記録リストは、クレジットカード会社１０６によって拡張される個々の有効なクレジット口座のための１つの記録５０２を持つことを認識するであろう。
各記録５０２は、関連するカード所有者に対して発行された完全なクレジットカード番号５０４、個人識別番号（ＰＩＮ）５０６、カード所有者情報５０８、コンタクト情報５１０、信用限度５１２、確認要求フラッグ５１４、確認開始フラッグ５１６及びポインター５１８を含む。
【００４５】
ＰＩＮ５０６は、確認プロセスの間カード所有者１０２を認証するため、あるいはカード所有者１０２が優先的なセッティング（例えば、確認が要求されたフラッグ５１４、確認開始フラッグ５１６等）をセットすることを可能とするために用いられるコードである。
カード所有者情報５０８は、カード所有者の姓名のような個人の情報、誕生日、社会保障番号及び／又は住所を含むが、これらに限定されない。
コンタクト情報５１０は、特にＴＡＲ確認のために、関連するカード所有者との通信に必要な情報を含む。コンタクト情報５１０は、電話番号、ポケットベル番号あるいはＥ−ｍａｉｌアドレスを含むがこれらに限定されない。信用限度５１２は、関連するカード所有者のための事前に決められた信用限度を示す。確認要求されたフラッグ５１４は、カード所有者１０２からそれ以上入力のない以後のＴＡＲを自動的に確認することにより、カード所有者１０２が例えば確認プロセスを選択的に無効にすることを可能にする。
この実施例では、確認要求フラッグ５１４はシングル・ビット・フラッグであり、１の値は確認プロセスが実行されるべきであることを示し、０の値は、カード所有者が確認プロセスをサスペンドすることを望むことを示す。
シングルビット確認開始フラッグ５１６は、カード所有者１０２が、サーバ２００が確認プロセスを開始することを望むのか、もしくはサーバ２００が、ユーザ１０２が確認プロセスを開始するのを待つべきであるかどうかを示す。
もし確認開始フラッグ５１６が、１の値を有する場合、双方向型の確認モジュール３０６は、カード所有者と関連する確認プロセス（例えば電子メールと自動電話呼び出しなど）を開始する。
もし確認開始フラッグ５１６が、０の値を有する場合、関連するカード所有者は確認を始めなければならない（例えば、ある場所からサーバ２００への通話、インターネットワーク１１０を介してサーバ２００にログオンする）。
ポインター５１８は、カード所有者データ構造５００の次の記録５０２の開始アドレスを示す。リスト指標５２０の終了は、記録５０２（ｎ）がデータ構造５００中の最後の記録であることを示す。
【００４６】
図６は、本発明の特定の実施例で用いるのに適している購入履歴データ構造６０６の例を示す。購入履歴データ構造６００は、各々が完全なクレジットカード番号６０４、購入情報６０６、購入代金６０８、商人情報６１０、確認の日時６１２及びポインター６１４を含んだ記録６０２（１−ｎ）のリンクしたリストである。
クレジットカード番号６０４は、関連するカード所有者との特定の決済を識別する。購入情報６０６は、カード所有者への決済を識別することを助ける情報（例えば製品詳細）を含む。
購入代金６０８は、購入に関係する費用を示す。商人情報６１０は、ＴＡＲを提示した商人を識別する。確認の日時６１２は、関連するカード所有者がＴＡＲを確認した時を示す。ポインター６１４は、データ構造６００の次の記録６０２のアドレスを示す。リスト指標６１６（ｎ）の終了は、記録６０２（ｎ）が購入履歴データ構造６００中の最後の記録であることを示す。
【００４７】
当業者は、上記の信用承認要求データ構造４００、カード所有者データ構造５００及び購入履歴データ構造６００が事実上典型的なものであり、他のデータ構造もまた、本発明で用いられてもよいことを理解するであろう。
従って、例示の目的でここに記載された特定のデータ構造は、本発明の必須要素であるとは考えられない。本発明の特定の実施例の実施形態の機能は、図１から図６を参照して説明される。
カード所有者１０２が品物あるいはサービスのオーダーを商人１０４に対して提示し、支払いの手段としてクレジットカード会社１０６によって割り当てられたクレジットカード番号を使用する時にプロセスは始まる。
商人１０４は、その後カード所有者１０２によって供給されたクレジットカード番号、購入に関する詳細、購入代金、購入日時の記述及び商人１０４を識別する情報を含むクレジットカード会社１０６への決済承認要求を送信する。
【００４８】
商人通信モジュール２３２（図２）は、定期的に商人１０４から任意に入って来るＴＡＲのためのネットワーク・インターフェース２０４及び電気通信装置２１４とポールする。
ＴＡＲが受信される時、商人通信モジュール２３２は、ＴＡＲに提供されるクレジットカード番号と一致するクレジットカード番号５０４を備えた記録５０２（図５）があるかどうかを決定するためにカード所有者リスト２２２を読み取る。
カード所有者リスト２２２中にそのような記録がない場合、商人通信モジュール２３２は、商人１０４に否認を送信する。
【００４９】
しかしながら、もし提示されたクレジットカード番号が、カード所有者リスト２２２内のクレジットカード番号５０２（ｘ）に一致するならば、その後、商人通信モジュール２３２は、フィールド４０４、４０６、４０８、４１０及び４１２を作るためのＴＡＲ中に備えられた情報を用いて信用承認要求記録４０２を作り、またＣＡＲＱ２２０内に新しい記録を格納する。最初に、確認されたフラッグ４１４、承認されたフラッグ４１６、否認されたフラッグ４１８は、全て０と等しく設定される。
【００５０】
認可モジュール２２６のマスター確認モジュール３０４は、定期的に未決の複数のＴＡＲのためにＣＡＲＱ２２０を読み取る。どのような未決の複数のＴＡＲも、フラッグ４１４、４１６及び４１８の状態に基づいて処理される。
例えば、第１ＴＡＲ記録４０２（１）の承認されたフラッグ４１６（１）が０に等しく設定された場合、次にマスター確認モジュール３０４は、ＴＡＲ４０２（１）の従来の信用承認を実行するために信用承認モジュール３０２を呼び出す。
【００５１】
信用承認モジュール３０２は、当業者に既知の手段によって従来の信用承認プロセスを実行する。従来の信用承認は典型的には、カード所有者１０２（ｘ）の信用限度５１２（ｘ）の残高と購入代金４０８（１）を比較する承認モジュール３０２を含むがこれに限定されない。
購入代金４０８（１）の合計とカード所有者１０２（ｘ）の残高が信用限度５１２（ｘ）より以下である場合、次に、承認モジュール３０２は、承認されたフラッグ４１６（１）が１に等しいように設定する。
もし口座に何らかの際立った不一致がある場合（例えば、支払い延滞分）、あるいは購入代金４０８（１）の合計とカード所有者１０２（ｘ）の残高が信用限度５１２（ｘ）より大きい場合、承認モジュール３０２は否認されたフラッグ４１８（１）を１に等しくなるように設定する。
【００５２】
ＣＡＲＱ２２０の次の読み取り間、マスター確認モジュール３０４が、適切な動作を決定するためにフラッグ４１４（１）、４１６（１）及び４１８（１）を再びチェックする。
ＴＡＲ記録４０２（１）が確認のためにまだ処理されていないので、確認フラッグ４１４（１）はまだ０に等しくなければならないことに注意する。もし否認されたフラッグ４１８（１）が１に等しくなるように設定された場合、その後、マスター確認モジュール３０４は、商人１０４に対する否認を送信するために商人応答モジュール３０８を呼び出し、ＣＡＲＱ２２０から記録４０２（１）を削除し、購入履歴モジュール２３０の中に否認された決済の記録６０２を書き込む。
もし承認されたフラッグ４１６（１）が、１と等しいように設定されたならば、次にマスター認可モジュール３０４は、カード所有者１０２（ｘ）が、選択的に確認プロセスを無効にしたかどうかを決定するために要求されたフラッグ５１４（ｘ）を検索する。
もし確認が要求されたフラッグ５１４（ｘ）が０に等しく設定された場合、次にマスター確認モジュール３０４は確認されたフラッグ４１６（１）を自動的に１に等しく設定し、ＣＡＲＱ２２０にＴＡＲ記録４０２（１）を残す。もし確認が要求されたフラッグ５１４（ｘ）が０に等しく設定された場合、次にマスター認可モジュール３０４は、カード所有者１０２（ｘ）による確認を待つためにＶＰＱ２２８にＴＡＲ記録４０２（１）を送信する。
【００５３】
またマスター確認モジュール３０４は、確認のためのＶＰＱ２２８中の任意の未決のＴＡＲ記録４０２を処理するためにＶＰＱ２２８を定期的（例えば、ＣＡＲＱ２２０の各読み取りの後に）に読み取る。
もし特定の記録４０２の確認されたフラッグ４１４が１に等しく設定される場合、確認されたフラッグ４１４は、記録４０２に対応するＴＡＲがカード所有者１０２（ｘ）によって確認されたことを示す。
初めてＴＡＲ記録４０２（１）がＶＰＱ２２８中で読み取られる時は、確認されたフラッグ４１４（１）及び確認開始フラッグ４１５（１）は両方が０に等しく設定されるべきである。
次にマスター確認モジュール３０４は、サーバ２００が確認プロセス（例えば、ユーザ１０２（ｘ）へ電子メールを送る、ユーザ１０２（ｘ）を呼び出す、ユーザ１０２（ｘ）へ通話を申し込む）を開始すべきかどうかを決定するため、あるいはサーバ２００が、ユーザ１０２（ｘ）が確認プロセスを始めることを待つべきであるかどうかを決めるために、カード所有者リスト２２２から記録５０２（ｘ）を検索する。
もし確認開始フラッグ５１６（ｘ）が０に等しく設定される場合、次にマスター確認モジュールは、確認が開始されたフラッグ４１５（１）を１に等しく設定する。
確認が開始されたフラッグを１に等しく設定することは、例えサーバ２００が確認プロセスを開始していなかったとしても、マスター確認モジュール３０４によってＶＰＱ２２８が読み取られる時には確認が要求されたフラッグ５１６（ｘ）をチェックする必要性を削除する。
【００５４】
もしＶＰＱ２２８中の記録４０２（１）の最初の読み取り中に、マスター確認モジュール３０４が、確認開始フラッグ５１６（ｘ）が１に等しく設定されたことを決定したならば、次にマスター確認モジュール３０４は、カード所有者１０２（ｘ）に確認プロセスを開始するために双方向型の確認モジュール３０６を呼び出す。
次に双方向型の確認モジュール３０６は、確認プロセスを開始し、確認が開始されたフラッグ４１５（１）を１に等しく設定し、処理のためにＶＰＱ２２８中の次の記録４０２を検索するマスター確認モジュール３０４に制御を戻す。
【００５５】
またマスター確認モジュール３０４は、ＶＰＱ２２８中の未決の複数のＴＡＲの実際の確認を処理するために双方向型の確認モジュール３０６を定期的に呼び出す。
未決の複数のＴＡＲの確認は、ＡＴＭカード購入のような従来技術の電子決済と比較される付加的なセキュリティが備えられ、ＴＡＲが本来受信された商人１０４との接続から独立したカード所有者（ｘ）との接続の確立により達成される。
ここで用いられるように、「接続を確立する」という表現は、最も広く可能な判断力で、ネットワーク接続を確立すること、モデム上でデータ接続を確立すること、電子通信装置上での音声接続を確立すること、電子メールを送受信することなどを含むがこれらに限定されずに解釈されることが理解される。
従って、カード所有者１０２は、インターネットワーク１１０を介してサーバ２００にログオンする、ネットワーク１１４を介してサーバ２００と直接のモデム接続をする、電話を介してサーバ２００へ電話をする、サーバ２００へ電子メールを送る、サーバ２００からの電子メールに応答する、あるいは電子通信の他の形式により、未決の決済承認要求を確認することができる。
代わりの実施例において、システム２００は、口座所有者１０２がいくらかの課金を事前に承認することを可能にするために修正することができる。例えば、カード所有者リスト２２２は、事前に承認した商人（あるいは他の望ましい基準）のためのフィールドを含むことができる。
その後、決済承認要求が処理されたとき、認可モジュール２２６は、関連するカード所有者の事前に承認した商人のリストと商人識別を比較することができ、また商人がリストに現われる場合、自動的にＴＡＲを確認する。
カード所有者１０２は、インターネットワーク１１０、ネットワーク１１４あるいは顧客データの更新をするための既知の他の手段を介して事前に承認されたリストを修正するためにシステム２００にアクセスすることができる。
【００５６】
図１から図３に示される本発明の特定の実施例で、双方向型の確認モジュール３０６は、カード所有者通信モジュール２２４、ネットワークインターフェース２０４及び電気通信装置２１４を介してカード所有者１０２通信する。
カード所有者通信モジュール２２４は、定期的にネットワークインターフェース２０４及び入って来る接続要求のための電気通信装置２１４（例えば、電子メール、ネットワーク接続、通話など）をポールし、また任意のそのような接続を確立する。
そのような通信プログラム（例えば、電子メールソフトウェア、ネットワーク・プロトコルなど）は、当業者に既知であり、従って本発明を不必要にあいまいに不明瞭にしないように詳細に記述されない。
【００５７】
双方向型の確認モジュール３０６は、カード所有者１０２との任意の確立している接続があるかどうかを決定するためにカード所有者通信モジュール２２４とポールし、各確立されたプロセスを処理する。
カード所有者１０２（ｘ）は、サーバ２００との接続を確立したと仮定すると、未決の複数のＴＡＲの確認は以下のように処理される。接続要求は、カード所有者１０２（ｘ）を識別するべきであり（例えば、クレジットカード番号によって）、カード所有者１０２（ｘ）を認証するために認可コード（例えば、個人識別番号（ＰＩＮ））を随意に含む。双方向型の確認モジュール３０６は、カード所有者リスト２２２からのカード所有者１０２（ｘ）に対応する記録５０２（ｘ）を検索するための接続要求の中で識別情報を用いる。
次に双方向型の確認モジュール３０６は、カード所有者を認証するためにＰＩＮ５０６（ｘ）と接続要求内のＰＩＮを比較する。ＰＩＮが一致しない場合、接続は終了する。ＰＩＮが一致する場合、確認プロセスは進む。
【００５８】
当業者は、正しくないＰＩＮが初めて受信される時にカード所有者１０２（ｘ）との接続を終了する必要がないと理解するであろう。例えば、従来のネットワーク・セキュリティ・システムは、典型的にはユーザとの接続を切断するのに先立ち、事前に決定した正しくないエントリーの数を許可する。代わりに、接続の追跡が開始される間に、システムにアクセスすることを試みるユーザを引き止めるようなセキュリティ対策を用いることができる。
【００５９】
次に、双方向型の確認モジュール３０６は、カード所有者１０２（ｘ）のクレジットカード番号５０４（ｘ）と一致するクレジットカード番号４０２を備える全てのＴＡＲのための確認が未決のキュー２２８を読み取る。
次に一致した各ＴＡＲは、確認されるためにカード所有者１０２（ｘ）に対して提示される。もしカード所有者１０２（ｘ）が特定の決済を確認する場合、次に双方向型の確認モジュール３０６は、１に等しいＴＡＲ記録の確認されたフラッグ４１４を設定する。もしカード所有者１０２（ｘ）が、決済を否認したならば（例えば、購入が許可されなかったので）、次に双方向型の確認モジュール３０６が１に等しいＴＡＲ記録の否認されたフラッグ４０８を設定する。
【００６０】
サーバ２００との確立された接続のタイプに依存して、カード所有者１０２（ｘ）に対し未決の複数のＴＡＲがあり、カード所有者１０２（ｘ）から確認の指示を受信することを提示する多くの可能な方法がある。例えば、もしカード所有者１０２がサーバ２００とＨＴＴＰ接続を確立した場合、次に、未決の複数のＴＡＲは、インターネット・ウェブ・ページの形式で表すことができる。
代わりに、カード所有者１０２（ｘ）とサーバ２００間の接続が電話音声接続である場合、次に、未決の複数のＴＡＲは、当業者に既知のような自動化されたテキストを音声に変換するシステムを介してカード所有者１０２（ｘ）へ提示することができる。次に、カード所有者１０２（ｘ）は、音声又はキーパッドのコマンド（例えば、確認するためのタッチ・ボタン１、あるいは否認するためのボタン２）を介して確認指示を送信することができる。
まだ別の例において、接続要求が電子メール応答の形式の場合、電子メール応答は、双方向型の確認モジュール３０６によって自動的に処理することができる確認指示（例えば、電子メールのタイトルで）を含むことができる。ＴＡＲを確認するために、任意の上記したタイプの接続を使用することは、本発明の新規性のある側面であると考えられる一方で、特定のタイプの接続が本発明の必須要素であるとは考えられていない。
【００６１】
双方向型の確認モジュール３０６がどのような接続をも処理した後、ＶＰＱ２２８を読み取り、１に等しく設定された確認されたフラッグ４１４あるいは否認されたフラッグ４１８を送信する任意のＴＡＲ記録をマスター確認モジュール３０４に制御は戻される。さらに、マスター確認モジュール３０４は、ＶＰＱ２２８に残る記録４０２を全て読み取り、システム・クロック２１２によって提供された日時と、購入日時フィールド４１２での値を比較する。もし生じる時間差が予め決定した時間（例えば、２４時間）を超過する場合、次に、マスター確認モジュール３０４は、１に等しい関連する記録４０２の否認されたフラッグ４１８を設定し、ＣＡＲＱ２２０に記録４０２を送信する。
【００６２】
ＣＡＲＱ２２０の次の読み取り中に、マスター確認モジュール３０４は、確認されたフラッグ４１４と承認されたフラッグ４１６の両方が１に等しく設定された任意のＴＡＲ記録を設け、記録のフィールド４１０において識別される商人へ承認を送信するために商人応答モジュールを呼び出し、ＣＡＲＱ２２０から記録を削除し、完成した決済を記録するために購入履歴データ２３０に記録６０２を書き込む。
否認されたフラッグ４１８が１に等しく設定されたと分かる記録は、否認が承認の代わりに識別された商人に対して送信されることを除いて同様に扱われる。
【００６３】
図７は、本発明に従ってＴＡＲを決済する方法７００を要約するフローチャートである。第１ステップ７０２で、商人通信モジュール２３２は、商人１０４からの完全なクレジットカード番号を含むＴＡＲを受信し、ＴＡＲ記録４０２を作り、ＣＡＲＱ２２０にＴＡＲ記録４０２を書き込む。第２ステップ７０４で、認可モジュール２２６は、従来の信用承認プロセスに対するＴＡＲ記録４０２を支配し、要求された信用が承認されるか否認されるかどうかを示すために承認されたフラッグ４１６あるいは否認されたフラッグ４１８を設定する。第３ステップ７０６では、要求された信用が承認されたか否認されたかどうかを、認可モジュール２２６は、フラッグ４１６と４１８から決定する。もし第３ステップ７０６で、要求された信用が承認されたと認可モジュール２２６が決定する場合、第４ステップ７０８で、認可モジュール２２６は、カード所有者１０２が選択的に確認プロセスを無効にしたかどうかを決定する。
確認プロセスが選択的に無効になっていない場合、第５ステップ７１０で、認可モジュール２２６がカード所有者１０２に決済を確認する。次に、第６ステップ７１２で、認可モジュール２２６は、ＴＡＲがカード所有者１０２によって確認されたかどうかを決定する。ＴＡＲが確認された場合、第７ステップ７１４で、商人通信モジュール２３２が商人１０４に決済承認を送信する。次に、第８ステップ７１６で、認可モジュール２２６は、さらに多くのＴＡＲ記録がＣＡＲＱ２２０にあるかどうかを決定する。ＣＡＲＱ２２０にこれ以上記録がない場合、方法７００は終了する。
【００６４】
第３のステップ７０６で、信用要求が否認されたと認可モジュール２２６が決定する場合、方法７００は第９のステップ７１８に進み、商人通信モジュール２３２は商人１０４に否認を送信する。第４のステップ７０８で、確認プロセスが選択的に無効になったと認可モジュール２２６が決定する場合、方法７００は第７のステップ７１４に進み、商人通信モジュール２３２は商人１０４に承認を送信する。第６のステップ７１２で、ＴＡＲがカード所有者１０２によって確認されていないと認可モジュール２２６が決定する場合、方法７００は第９のステップ７１８に進み、商人通信モジュール２３２は商人１０４に否認を送信する。最後に、第８のステップ７１６で、さらに多くの未決のＴＡＲ記録がＣＡＲＱ２２０にあると認可モジュール２２６が決定する場合、方法７００は、ＣＡＲＱ２２０中の次の記録を処理するために第１のステップ７０２に戻る。
【００６５】
図８は、本発明の特定の実施形態による、ＴＡＲ確認プロセスの選択的無効化を実施するための方法８００を要約するフローチャートである。第１のステップ８０２で、認可モジュール２２６が、ＣＡＲＱ２２０が空であるかどうか決定する。ＣＡＲＱ２２０が空でない場合、第２のステップ８０４で、認可モジュール２２６はＣＡＲＱ２２０中の第１のＴＡＲ記録を読み取る。次に、第３のステップ８０６で、認可モジュール２２６はカード所有者１０２に第１のＴＡＲを関連させて、カード所有者・リスト２２２から特定のカード所有者に対応するカード所有者記録５０２を検索する。第４のステップ８０８で、認可モジュール２２６は、商人１０４に承認を送信するに先立って、ＴＡＲがカード所有者１０２で確認されることをカード所有者１０２が要求したかどうかをカード所有者記録５０２から決定する。カード所有者確認が要求される（つまり有効にされる）と決定された場合、第５のステップ８１０で、認可モジュール２２６は関連するＴＡＲ記録をＶＰＱ２２８に転送する。次に、第６のステップ８１２で、認可モジュール２２６は、ＣＡＲＱ２２０中の最後の記録が処理されたかどうか決定し、もしそうであるならば方法８００は終了する。
【００６６】
第４のステップ８０８で、確認が要求されない（つまり無効にされる）と認可モジュール２２６が決定する場合、第７のステップ８１４で、確認フラグ４１４は、ＴＡＲが確認されたことを示すために自動的に１にセットされる。第６のステップ８１２で、ＣＡＲＱ２２０中の最後の記録が処理されていないと認可モジュール２２６が決定する場合、方法８００は、ＣＡＲＱ２２０中にある次の記録の処理を始めるために第２のステップ８０４に返る。
【００６７】
図９は、本発明による、ＴＡＲを確認する特定の方法９００を要約するフローチャートである。第１のステップ９０２で、認可モジュール２２６はＶＰＱ２２８が空であるかどうか決定する。ＶＰＱ２２８が空でない場合、第２のステップ９０４で、認可モジュール２２６はＶＰＱ２２８中の第１のＴＡＲ記録４０２を読み取る。第３のステップ９０６で、認可モジュール２２６は、ＴＡＲ記録４０２が以前に否認されたかどうか（例えば否認されたフラグ４１８＝１）を決定する。ＴＡＲ記録４０２が以前に否認されていない場合、第４のステップ９０８で、認可モジュール２２６は、現在のＴＡＲが以前に確認されたかどうか（例えば確認されたフラグ４１４＝１）を決定する。ＴＡＲがまだ確認されていない場合、第５のステップ９１０で、認可モジュール２２６は、サーバー２００によって確認プロセスが既に始まったかどうか（例えば、確認が始められたフラグ４１５＝１）を決定する。確認が始められたフラグ４１５が１に等しい場合、第６のステップ９１２で、認可モジュール２２６は、現在のＴＡＲがサーバー２００によって受信されてから、予め設定された時間が経過したかどうか（例えば、購入日時４１２を読み取り、システムクロック２１２と比較する）を決定する。予め設定された時間が経過している場合、第７のステップ９１４で、認可モジュール２２６は自動的にＴＡＲを否認し（例えば否認されたフラグ＝１をセット）、第８のステップ９１６でＣＡＲＱ２２０にＴＡＲ記録を転送する。第９のステップ９１８で、認可モジュール２２６は、ＶＰＱ２２８中の最後の記録が処理されたかどうか決定する。ＶＰＱ中の記録がすべて処理されている場合、第１０のステップ９２０で認可モジュール２２６は、ＶＰＱ２２８に残ったいかなるＴＡＲ記録に対してもカード所有者確認プロセスを実行する。
【００６８】
第１のステップ９０２で、ＶＰＱ２２８が空であることを認可モジュール２２６が決定する場合、方法９００は終了する。第３のステップ９０６で、処理中のＴＡＲ記録が否認されたと認可モジュール２２６が決定する場合、方法９００は第８のステップ９１６に直接進む。同様に、第４のステップ９０８で、処理中のＴＡＲ記録が以前に確認されたと認可モジュール２２６が決定する場合、方法９００は第８のステップ９１６に進む。
【００６９】
第５のステップ９１０で、確認が始められたフラグ４１５が０に等しいことを認可モジュール２２６が決定する場合、方法９００は第１１のステップ９２２に進み、認可モジュール２２６は更に、認可モジュール２２６によって確認プロセスが開始されるべきかどうか（例えば、確認が始められるフラグ５１６＝１をセット）を決定する。第１１のステップ９２２において、カード所有者１０２で確認プロセスを開始するべきものと認可モジュール２２６が決定する場合、第１２のステップ９２４で、サーバー２００はカード所有者１０２で確認プロセスを開始し、また第１３のステップ９２６で、確認が始められたフラグを１に等しくなるようセットする。その後、方法９００は第８のステップ９１６に進む。第１１のステップ９２２では、確認開始フラグ５１６が０に等しくセットされていることを認可モジュール２２６が決定する場合、方法９００は第１３のステップ９２６に直接進む。
【００７０】
第６のステップ９１２で、予め設定した時間が経過していないと認可モジュール２２６が決定する場合、方法９００は第８のステップ９１６に進む。第９のステップ９１８で、ＶＰＱ２２８に追加のＴＡＲ記録があることを認可モジュール２２６が決定する場合、方法９００は、次のＴＡＲ記録を処理するために第２のステップ９０４に戻る。
【００７１】
図１０は、未決の複数のＴＡＲをカード所有者１０２で確認する方法１０００を要約するフローチャートである。第１のステップ１００２で、カード所有者通信モジュール２２４は、カード所有者１０２からカード所有者通信要求（例えば電話呼出し、ネットワーク接続要求）があるかどうか決定するためにネットワーク・インタフェース２０４及び電気通信装置２１４を得て、カード所有者通信要求がある場合は、第２のステップ１００４で、認可モジュール２２６はカード所有者１０２との接続を確立するために双方向型確認モジュール３０６を呼び出す。第３のステップ１００６で、双方向型確認モジュール３０６がカード所有者１０２を認証し（例えば認証コードを要求する）、また第４のステップ１００８で、カード所有者１０２と関係する記録のためのＶＰＱ２２８を検索する。その後、第５のステップ１０１０で、双方向型確認モジュール３０６は、カード所有者１０２に未決のＴＡＲの少なくとも１部分（カード所有者の認識に十分である）を提示する。次に、第６のステップ１０１２で、双方向型確認モジュールは、提示されたＴＡＲを確認する指示をカード所有者１０２が送信したかどうか決定するために、確立した接続をポールする。カード所有者１０２からＴＡＲを確認する指示がない場合、第７のステップ１０１４で、双方向型確認モジュール３０６は、ＴＡＲを無効にする指示をカード所有者１０２が送信したかどうか決定する。ＴＡＲを無効にする指示がない場合、第８のステップ１０１６で、双方向型確認モジュール３０６は、カード所有者１０２に関連した最後の未決のＴＡＲが処理されたかどうか決定する。最後の未決のＴＡＲが処理された場合、第９のステップ１０１８で、双方向型確認モジュール３０６はカード所有者１０２との確立された接続を終了し、また方法１０００は、他のカード所有者から通信要求があるかどうか決定するためにステップ１００２に戻る。第１のステップ１００２で、カード所有者通信要求がないとカード所有者通信モジュール２２４が決定する場合、方法１０００は終了する。
【００７２】
第６のステップ１０１２で、提示されたＴＡＲを確認するように双方向型確認モジュール３０６がカード所有者１０２から指示を受ける場合、第１０のステップ１０２０で、双方向型確認モジュール３０６は、ＴＡＲ記録４０２の確認されたフラグ４１４を１の値にセットし、ＴＡＲが確認されたことを示す。その後、方法１０００は第５のステップ１０１０に戻る。同様に、第７のステップ１０１４で、双方向型確認モジュール３０６が、提示されたＴＡＲを無効にするようにカード所有者１０２から指示を受ける場合、第１１のステップ１０２２で、双方向型確認モジュール３０６は、ＴＡＲ記録４０２の否認されたフラグ４１８を１の値にセットし、ＴＡＲが無効にされたことを示す。その後、方法１０００は第５のステップ１０１０に戻る。
【００７３】
第８のステップ１０１６で、特定カード所有者のための最後の未決要求が処理されていないと双方向型確認モジュール３０６が決定する場合、方法１０００は特定カード所有者のための次のＴＡＲを処理するために第５のステップ１０１０に戻る。
【００７４】
図１１は、代替となるサーバー２００Ａのブロック図である。サーバー２００Ａは、この２００Ａが前もっての確認基準（ＰＶＣ）１１０２及び代替認可モジュール２２６Ａを含むということを除いて、図２のサーバー２００と同様に機能する。認可モジュール２２６Ａは、ＴＡＲの承認及び確認を制御あるいは調整し、認可モジュール２２６によって実行される機能に加えて、前もっての確認基準１１０２の必要条件を満たすＴＡＲを自動的に確認するために、前もっての確認基準１１０２を使用する。認可モジュール２２６Ａはカード所有者１０２による直接的な確認を待つ必要はないので、前もっての確認基準１１０２の使用は、迅速なＴＡＲ確認を促進する。
【００７５】
前もっての確認基準１１０２は、クレジットカード会社１０６の、カード所有者１０２を含んだ現在の各顧客に対する個別化した前もっての確認基準を含むデータベースである。前もっての確認基準は典型的には以下に限定されないが、商人識別子、最大購入代金、及び認可モジュール２２６Ａによって購入の自動確認がなされる期間である特定の日付を含む。当業者は、前もっての確認基準モジュール１１０２が、典型的には非常に大きなファイルになることを理解するであろう。したがって、前もっての確認基準モジュール１１０２がメモリ２１６中に示される一方で、顧客ファイル全体が、前もっての確認基準モジュール１１０２と必要に応じてやりとりするリスト全体の一部、例えば不揮発性メモリ２０８のようなものを持った大量データ格納システムに格納されることが理解されるべきである。
【００７６】
最初に、クレジットカード口座が開かれる際にクレジットカード会社１０６によって前もっての確認基準が決定され、その結果、前もっての確認基準によって購入を確認することはできない。言いかえれば、各口座に対する前もっての確認基準の初期のデフォルト値は、ＴＡＲが前もっての確認基準を満たすことができないようにセットされる（例えば最大購入代金＝０）。あるいは前もっての確認基準は、口座が開かれる際にカード所有者１０２によって決定されることもある（例えばクレジットカードを適用して）。いずれの場合も以下に記述されるように、カード所有者１０２は、安全なネットワーク上（例えば電話かモデム・アクセスを介する）のそれらの前もっての確認基準を修正することができる。
【００７７】
図１２は、信用承認モジュール３０２、代替マスター確認モジュール３０４Ａ、双方向型確認モジュール３０６、及び商人応答モジュール３０８を含む認可モジュール２２６Ａのブロック図を示す。信用承認モジュール３０２は、当業者によく知られた手段によって、ＣＡＲＱ２２０に含まれた各ＴＡＲに対して従来の信用承認を実行する。マスター確認モジュール３０４Ａは、前もっての確認基準を用いた確認を含む認可及び確認プロセスを調整し、認可モジュール２２６Ａの全体的制御に対して責任がある。双方向型確認モジュール３０６Ａはカード所有者１０２で確認を実行し、カード所有者１０２によって前もっての確認基準の修正を調整する。商人応答モジュール３０８は、決済承認あるいは決済否認のいずれかの送信により、商人１０４と最終通信を始める。
【００７８】
図１３は、本発明の特定実施形態での使用に適した前もっての確認基準データ構造１３００の例を示す。当業者は、データ構造１３００を、記録１３０２（１−ｎ）のリンクしたリストとして認識するであろう。各記録１３０２（１−ｎ）は、特定カード所有者に関連した前もっての確認基準を表し、完全なクレジットカード番号１３０４、第１の商人識別子１３０６（１）、ｒ番目の商人識別子１３０６（ｒ）、前もって確認された最大購入代金１３１０、１対の前もっての確認日付１３１２、その他の前もっての確認基準１３１４、及びポインター１３１６を含む。完全なクレジットカード番号１３０４は、前もっての確認基準記録１３０２（ａ）を特定カード所有者１０２（ａ）と関連させる。商人識別子１３０６（１−ｒ）は各々、各ＴＡＲに含まれる商人情報４１０に類似する情報を含む。商人識別子１３０６（１−ｒ）は、各カード所有者に対して、前もって確認されたある商人を各々識別する。前もって確認された商人から受信されたＴＡＲは、認可モジュール２２６Ａによって自動的に確認される。前もって確認された購入代金１３１０は、自動確認のための最大購入代金をセットする。前もって確認された購入代金１３１０よりも少ない購入代金４０８を含んだＴＡＲは、認可モジュール２２６Ａによって自動的に確認される。前もっての確認日付１３１２は開始日付及び終了日付を含む。前もっての確認日付１３１４の開始日付及び終了日付の間にある購入日付４１２を含むＴＡＲは、認可モジュール２２６Ａによって自動的に確認される。その他の前もっての確認基準１３１４は、特に上記にリストされたもの以外の特定の基準が、認可モジュール２２６ＡにＴＡＲを確認させるために使用されることを示すために含まれる。例えば、カード所有者１０２は購入が自動的に確認される時、特定の時刻の指定を望むこともある。このような場合については、その他の前もっての確認基準１３１４は開始時刻及び終了時刻を含む。ポインター１３１６（ａ）は、リスト中の次の記録１３１６（＋１）のメモリ・アドレスを示す。最後の記録１３０２（ｎ）は、記録１３０２（ｎ）がリスト中の最後の記録であることを示すリスト値１３１８のエンドを含む。
【００７９】
図１４は、本発明の特定の実施形態による、前もっての確認基準を使用してＴＡＲの自動確認を実行するための１つの方法８００Ａを要約するフローチャートである。第１のステップ８０２で、認可モジュール２２６ＡはＣＡＲＱ２２０が空であるかどうか決定する。ＣＡＲＱが空の場合、方法８００Ａは終了する。ＣＡＲＱ２２０が空でない場合、第２のステップ８０４で、認可モジュール２２６Ａは、ＣＡＲＱ２２０中の第１のＴＡＲ記録を読み取る。その後第３のステップ８０６で、認可モジュール２２６Ａは、カード所有者１０２に第１のＴＡＲを関連させ、特定のカード所有者に対応するカード所有者記録５０２をカード所有者リスト２２２から検索する。第４のステップ８０８で、認可モジュール２２６Ａは、商人１０４に承認を送信するに先立って、カード所有者１０２が、ＴＡＲがカード所有者１０２で確認されることを要求したかどうかをカード所有者記録５０２から決定する。カード所有者確認が要求される（つまり有効にされる）場合、次に第５のステップ８０９で、認可モジュール２２６Ａは、カード所有者１０２と関連した前もっての確認基準が満たされたかどうか決定する。第５のステップ８０９で前もっての確認要求の基準が満たされない場合、第６のステップ８１０で、認可モジュール２２６Ａは関連するＴＡＲ記録をＶＰＱ２２８に転送する。次に、第７のステップ８１２で、認可モジュール２２６Ａは、ＣＡＲＱ２２０中の最後の記録が処理されたかどうか決定し、もし処理されているならば方法８００Ａは終了する。
【００８０】
第４のステップ８０８で、確認が要求されない（つまり無効にされる）と認可モジュール２２６Ａが決定する場合、方法８００Ａは第８のステップ８１４に進み、認可モジュール２２６Ａは、ＴＡＲが確認されたことを示すために、確認されたフラグ４１４を１にセットする。同様に、第５のステップ８０９で認可モジュール２２６Ａが前もっての確認基準が満たされたと決定する場合、方法８００Ａは第８のステップ８１４に進み、認可モジュール２２６Ａは確認されたフラグ４１４を１にセットする。第７のステップ８１２で、ＣＡＲＱ２２０中の最後の記録が処理されていないと認可モジュール２２６Ａが決定する場合、方法８００Ａは、ＣＡＲＱ２２０中にある次の記録の処理を始めるために第２のステップ８０４戻る。
【００８１】
図１５は、図１４の方法の第５ステップ８０９（前もっての確認基準が満たされるかどうか決定する）を実行する１つの方法１５００を示すフローチャートである。第１のステップ１５０２で、認可モジュール２２６Ａは、ＴＡＲ中で識別されたカード所有者（例えばカード所有者１０２（ａ））に関連した前もっての確認基準１１０２の記録１３０２（ａ）を検索する。第２のステップ１５０４で認可モジュール２２６Ａは、記録１３０２（ａ）の商人識別子１３０６（ａ）（１−ｒ）の１つが、ＴＡＲに含まれた商人情報４１０に一致するかどうか決定する。記録１３０２（ａ）の商人識別子１３０６（ａ）（１−ｒ）のいずれもが商人を識別しない場合、第３のステップ１５０６で認可モジュール２２６Ａは、ＴＡＲの購入代金４０８が前もって確認された最大購入代金１３１０（ａ）未満であるかどうか決定する。ＴＡＲの購入代金４０８が、前もって確認された最大購入代金１３１０（ａ）未満でない場合、第４のステップ１５０８で、認可モジュール２２６Ａは、前もって確認された日付１３１２（ａ）の間にＴＡＲの購入日付４１２があるかどうか決定する。購入日付４１２が、前もって確認された日付１３１２（ａ）に指定された日付の間にない場合、第５のステップ１５１０で認可モジュール２２６Ａは、その他の前もっての確認基準１３１４（ａ）が満たされるかどうか決定する。その他の前もっての確認基準１３１４が満たされないか、カード所有者がその他の基準１３１４を指定しない場合、方法１５００は前もっての確認基準が満たされないと決定する。
【００８２】
第２のステップ１５０４で、認可モジュール２２６Ａは、記録１３０２（ａ）の商人識別子１３０６（１−ｒ）の１つが、ＴＡＲに含まれた商人情報４１０に一致するかどうか決定し、次に方法１５００は前もっての確認基準が満たされたと決定する。第３のステップ１５０６で、購入代金４０８が前もって確認された購入代金１３１０（ａ）未満であることを認可モジュール２２６Ａが決定する場合、方法１５００は、前もっての確認基準が満たされたと決定する。同様に、第４のステップ１５０８で、ＴＡＲ内の購入日付４１２が、前もって確認された購入日付１３１２（ａ）の間にあることを認可モジュール２２６Ａが決定する場合、方法１５００は前もっての確認基準が満たされたと決定する。最後に、第５のステップ１５１０で、認可モジュール２２６Ａが、その他の前もっての確認基準１３１４（ａ）が未決のＴＡＲによって満たされることを決定する場合、方法１５００は前もっての確認基準が満たされたと決定する。当業者は、方法１５００が、特定のＴＡＲは前もっての確認基準を満たすことを決定し、その他の基準（例えば最大購入代金）のいずれか１つが満たされる場合、自動的に確認されることを認識するであろう。
【００８３】
図１５Ａは、図１４の方法の実行ステップ８０９の代替となる方法１５００Ａを示すフローチャートであり、ここでは全ての前もっての確認基準は、ＴＡＲが自動的に確認される前に満たされていなければならない。第１のステップ１５０２で、認可モジュール２２６Ａは、認可モジュール２２６Ａによって処理されているＴＡＲ中で識別されたカード所有者（例えばカード所有者１０２（ａ））に関連する前もっての確認基準１１０２の記録１３０２（ａ）を検索する。第２のステップ１５０４Ａで認可モジュール２２６Ａは、記録１３０２（ａ）の商人識別子１３０６（１−ｒ）の１つがＴＡＲに含まれる商人情報４１０に一致するかどうか決定する。記録１３０２（ａ）の商人識別子１３０６（１−ｒ）のいずれも商人を識別しない場合、方法１５００Ａは、未決のＴＡＲによって前もっての確認基準が満たされないことを決定し、方法１５００Ａは終了する。しかしながら、記録１３０２（ａ）の商人識別子１３０６（１−ｒ）の１つが、ＴＡＲ中で識別された商人に一致する場合、方法１５００Ａは第３のステップ１５０６Ａに進み、認可モジュール２２６Ａは、ＴＡＲの購入代金４０８が前もって確認された最大購入代金１３１０（ａ）未満かどうか決定する。ＴＡＲの購入代金４０８が前もって確認された最大購入代金１３１０（ａ）未満でない場合、方法１５００Ａは前もっての確認基準が満たされないことを決定し、方法は終了する。ＴＡＲの購入代金４０８が前もって確認された最大購入代金１３１０（ａ）未満である場合、第４のステップ１５０８Ａで認可モジュール２２６Ａは、ＴＡＲの購入日付４１２が前もって確認された日付１３１２（ａ）の間にあるかどうか決定する。購入日付４１２が、前もって確認された日付１３１２（ａ）内に指定された日付の間にない場合、方法１５００Ａは前もっての確認基準が満たされないことを決定し、方法は終了する。購入日付４１２が、前もって確認された日付１３１２（ａ）内に指定された日付の間にある場合、第５のステップ１５１０Ａで認可モジュール２２６Ａは、その他の前もっての確認基準１３１４（ａ）が満たされるかどうか決定する。その他の前もっての確認基準１３１４（ａ）が満たされないか、カード所有者がその他の基準１３１４（ａ）を指定しない場合、方法１５００は前もっての確認基準が満たされないと決定し、方法１５００Ａは終了する。しかしながら、その他の前もっての確認基準１３１４（ａ）が満たされる場合、方法１５００は前もっての確認基準が満たされたと決定し、未決のＴＡＲは自動的に確認される。
【００８４】
図１６は、カード所有者１０２が、関連する前もっての確認基準１３０２を修正することを可能にする１つの方法１６００を要約するフローチャートである。双方向型確認モジュール３０６Ａは、双方向型確認モジュール３０６と同じ機能を実行することができるが、更に前もっての確認基準記録１３０２（１−ｎ）の修正を調整及び制御するためにも機能する。第１のステップ１６０２で、カード所有者通信モジュール２２４は、カード所有者１０２からカード所有者通信要求（例えば電話呼出し、ネットワーク接続要求など）があるかどうか決定するために、ネットワーク・インタフェース２０４及び電気通信装置２１４を得て、もしカード所有者通信要求があるならば、次にステップ１６０４で、双方向型確認モジュール３０６Ａはカード所有者１０２との接続を確立する。第３のステップ１６０６で、双方向型確認モジュールがカード所有者１０２を認証し（例えば認証コードを要求する）、第４のステップ１６０８で、双方向型確認モジュール３０６Ａが、カード所有者１０２に関連した前もっての確認基準１３０２を検索する。第５のステップ１６１０で、双方向型確認モジュール３０６Ａは、カード所有者１０２が前もっての確認基準１３０２の修正を望むかどうか決定する（例えば、予め記録されたメニューに対するタッチトーン応答を受信する）。カード所有者１０２が前もっての確認基準１３０２の修正を望む場合、第６のステップ１６１２で双方向型確認モジュール３０６Ａは、第１の前もっての確認基準を提示する（例えば商人識別子１３０６（１）をカード所有者１０２に）。次に第７のステップ１６１４で双方向型確認モジュール３０６Ａは、カード所有者１０２がステップ１６１２で提示された基準の修正を望むかどうか決定する。カード所有者１０２が、提示された前もっての確認基準１３０２を修正しないことを選択する場合、第８のステップ１６１６で双方向型確認モジュールは、カード所有者１０２が次の前もっての確認基準（例えば商人識別子１３０６（２））へ進むことを望むかどうか決定する。カード所有者１０２が前もっての確認基準の修正の継続を望まない場合、双方向型確認モジュール３０６Ａは、第９のステップ１６１８でカード所有者１０２との接続を終了する。
【００８５】
第１のステップ１６０２で、カード所有者からの通信要求がない場合、方法１６００は終了する。ステップ１６１０で、カード所有者１０２がいかなる前もっての確認基準の修正も望まない場合、方法１６００は第９のステップ１６１８に進み、双方向型確認モジュール３０６Ａはカード所有者１０２との接続を終了する。ステップ１６１４で、カード所有者１０２が示された前もっての確認データの修正を望む場合、双方向型確認モジュール３０６Ａは第１０のステップ１６２０を開始し、ここにおいて新しいデータはカード所有者１０２から受信され、この新しいデータは、方法１６００が第８のステップ１６１６に進む前に、提示された前もっての確認基準と置き換わる。第８のステップ１６１６で、カード所有者１０２から、前もっての確認基準１３０２に対してより多くの修正を行なうように指示を受ける場合、次に方法１６００はステップ１６１０に戻る。
【００８６】
本発明の特定の実施形態の記述はこれにて完了した。記述された特徴の多くは、本発明の範囲を逸脱せずに、代用、変更、省略されてもよい。例えば本発明は、ここに記述された種類のクレジットカード口座に加えて、安全な処理を要求する代替となる種類の口座（例えばデビット口座）で実行されてもよい。別の例として、第三者確認会社１０８は、クレジットカード会社１０６の代わりに、ここに記述された決済処理方法を使用し、次にクレジットカード会社１０６に確認の証印を送信してもよい。さらに、前もっての確認基準１１０２は個別のブロックとして図１１に示されているが、前もっての確認基準が、その代りにカード所有者リスト２２２のような他の記録内に格納されてもよいことを当業者は理解するであろう。同様に、カード所有者通信モジュール２２４及び双方向型確認モジュール３０６の機能性は、単一のオペレーションモジュールへ組み込むことができる。実際、本開示の機能モジュールは、本発明の明確な実例を提供するために組織され、或いは名付けられており、機能性の特定の分離は本発明の必須要素であると考えられていない。示された特定の実施形態からのこれら及びその他の変更は、特に以前の開示を考慮し、当業者にとって明白となるであろう。
【図面の簡単な説明】
【図１】
図１は、本発明に係るカード所有者、商人、クレジットカード会社、第三者確認会社の間のインターネットワークのブロック図である。
【図２】
図２は、ワーキングメモリおよび前記ワーキングメモリ内の認可モジュールを含む、図１のクレジットカード会社のサーバを示すブロック図である。
【図３】
図３は、図２の中で示される認可モジュールを詳述するブロック図である。
【図４】
図４は、図２の信用承認要求キュー中の決済承認要求記録を格納するための典型的なデータ構造を示すブロック図である。
【図５】
図５は、図２のカード所有者リストモジュールにカード所有者データを格納するための典型的なデータ構造を示すブロック図である。
【図６】
図６は、図２の購入履歴モジュールに決済記録を格納するための典型的なデータ構造を示すブロック図である。
【図７】
図７は、本発明によって安全かつ着実な電子決済を提供する１つの方法を要約するフローチャートである。
【図８】
図８は、図７の方法の第４のステップ（確認は無効にされるか？）を実行する１つの方法を要約するフローチャートである。
【図９】
図９は、図７の方法の第５のステップ（カード所有者確認）を実行する１つの方法を要約するフローチャートである。
【図１０】
図１０は、図７の方法の第５のステップ（カード所有者確認）を実行する代替の方法を要約するフローチャートである。
【図１１】
図１１は、前もっての確認基準を含む代替のサーバ、及び本発明により前もって決済を確認するために使用される代替の認可モジュールを示すブロック図である。
【図１２】
図１２は、図１１の代替の認可モジュールを詳述するブロック図である。
【図１３】
図１３は、図１１の前もっての確認基準の格納のための典型的なデータ構造を示すブロック図である。
【図１４】
図１４は、本発明によって安全かつ着実な電子決済を提供する別の方法を要約するフローチャートである。
【図１５】
図１５は、図１４の方法の第５のステップ（前もっての確認基準を満たすか？）を実行する１つの方法を要約するフローチャートである。
【図１５Ａ】
図１５Ａは、図１４の方法の第５のステップ（前もっての確認基準を満たすか？）を実行する代替の方法を要約するフローチャートである。
【図１６】
図１６は、カード所有者が該カード所有者の口座に関連した前もっての確認基準を修正するための１つの方法を要約するフローチャートである。
決定しまたは修正することができる。

Claims (84)

1. 口座所有者と商人の間の商決済を確認するためのコンピュータシステムであって、
   データとコードを処理するための処理ユニットと、
   前記データ及びコードを格納するためのメモリ装置とからなり、
   前記コードは、
   完全な口座番号を含んでいる決済承認要求を受信するための前記商人との接続を促進するために機能する商人通信モジュール、
   前記決済承認要求を確認するための前記口座所有者との個々の接続を促進するために機能する口座所有者通信モジュール、
   及び、前記承認要求が前記口座所有者により確認された場合にのみ前記決済承認要求の受信に応答し、前記商人に承認を送信するための機能をする認可モジュールを含んでいる、
   コンピュータシステム。
2. 前記認可モジュールは、前記決済承認要求の受信に応答し、前記口座所有者との前記接続を始めるために機能する双方向型の確認モジュールを含むことを特徴とする請求項１のコンピュータシステム。
3. さらにネットワークインターフェイスを含み、前記双方向型の確認モジュールは、前記ネットワークインターフェイスを介して前記口座所有者に電子メッセージを送るために機能することを特徴とする、請求項２のコンピュータシステム。
4. 前記双方向型の確認モジュールは、前記口座所有者からの前記電子メッセージへの返答を受信することに応答する前記決済承認要求を確認するために機能することを特徴とする、請求項３のコンピュータシステム。
5. さらに電子通信装置を含み、前記双方向型の確認モジュールは、前記口座所有者に自動的に電話呼び出しをするために機能することを特徴とする、請求項２のコンピュータシステム。
6. 前記双方向型の確認モジュールは、
   前記口座所有者との電話接続を確立するため、
   前記口座所有者に対して前記決済承認要求の少なくとも１つの部分を唱えるため、
   及び、前記決済承認要求に関して前記口座所有者から確認指示を受信するため
   に機能することを特徴とする、請求項５のコンピュータシステム。
7. 前記双方向型の確認モジュールは、前記口座所有者に対する前記決済承認要求の少なくとも１つの部分を唱える前記ステップに先立って、前記口座所有者から認証コードを要求するために機能することを特徴とする、請求項６のコンピュータシステム。
8. 前記認可モジュールは、前記口座所有者が該口座所有者との接続を始めるのを待つために機能する双方向型の確認モジュールを含んでいることを特徴とする、請求項１のコンピュータシステム。
9. さらにネットワークインターフェイスを含み、前記双方向型の確認モジュールは、前記ネットワークインターフェイスを介して前記口座所有者からの通信を待つために機能することを特徴とする、請求項８のコンピュータシステム。
10. さらにネットワークインターフェイスを含み、前記双方向型の確認モジュールは、
    前記ネットワークインターフェイスを介して前記口座所有者から接続要求を受信するため、
    前記口座所有者とのネットワーク接続を確立するため、
    前記口座所有者を認証するため、
    前記口座所有者に前記承認要求の少なくとも１つの部分を送信するため、
    及び、前記承認要求に関して前記口座所有者から確認指示を受信するため
    に機能することを特徴とする、請求項８のコンピュータシステム。
11. さらに電気通信装置を含み、前記双方向型の確認モジュールは、前記口座所有者からの電話呼び出しを待つために機能することを特徴とする、請求項８のコンピュータシステム。
12. さらに電気通信装置を含み、前記双方向型の確認モジュールは、
    前記口座所有者からの電話呼び出しを受けるため、
    前記口座所有者を認証するため、
    前記口座所有者に対して前記承認要求の少なくとも１つの部分を唱えるため、
    及び、前記承認要求に関して前記口座所有者から確認指示を受信するため
    に機能することを特徴とする、請求項８のコンピュータシステム。
13. 前記口座所有者からの指示に応答する前記認可モジュールは、前記口座所有者からの更なる入力なしに後の決済承認要求を自動的に確認するために機能することを特徴とする、請求項１のコンピュータシステム。
14. 前記認可モジュールは、前記承認要求が前記口座所有者によって確認されていない場合に、前もって決められた期間の経過に反応し、前記承認要求を無効するために機能するマスター確認モジュールを含んでいることを特徴とする、請求項１のコンピュータシステム。
15. 前記マスター確認モジュールは、前記決済承認要求が無効にされる場合に、前記口座所有者に通知を送信するためにさらに機能することを特徴とする、請求項１４のコンピュータシステム。
16. 前記決済承認要求が第三者金融機関からの確認要求であり、
    前記認可モジュールが前記第三者金融機関に確認の証印を送るために機能することを特徴とする、請求項１のコンピュータシステム。
17. コンピュータシステム中で口座所有者と商人の間の商決済を確認するための方法であって、
    前記商人から決済承認要求を受信することであって、前記承認要求は前記口座所有者の口座を識別する完全な口座番号を含んでいる、前記受信をすること、
    前記商人との前記通信から独立した前記口座所有者との通信を介して前記口座所有者に前記決済承認要求を電子的に確認すること、
    及び、前記決済承認要求が前記口座所有者によって確認される場合にのみ、前記商人に承認を送信すること
    からなる方法。
18. 前記カード所有者に前記決済承認要求を確認する前記ステップが、決済承認要求を確認するよう前記口座所有者に促すことを含むことを特徴とする、請求項１７の方法。
19. 前記口座所有者に促しをする前記ステップは、前記口座所有者への電子メッセージの送信を含むことを特徴とする、請求項１８の方法。
20. 前記口座所有者に前記決済承認要求を確認する前記ステップは、前記電子メッセージへの返答を受信することを含むことを特徴とする、請求項１９の方法。
21. 前記口座所有者に促しをする前記ステップは、前記口座所有者に自動電話呼び出しをすることを含むことを特徴とする、請求項１８の方法。
22. 前記口座所有者に自動電話呼び出しをする前記ステップは、
    前記口座所有者との電話接続を確立すること、
    前記口座所有者に対して前記決済承認要求の少なくとも１つの部分を唱えること、
    及び、前記決済承認要求に関して前記口座所有者から確認指示を受信すること
    からなることを特徴とする、請求項２１の方法。
23. 前記口座所有者に自動電話呼び出しをする前記ステップは、前記口座所有者に対して前記決済承認要求の少なくとも１つの部分を唱える前記ステップに先立って、前記口座所有者から認証コードを受信することをさらに含むことを特徴とする、請求項２２の方法。
24. 前記口座所有者に前記決済承認要求を電子的に確認する前記ステップが、前記コンピュータシステムとの通信を開始するために前記口座所有者を待つことを含むことを特徴とする、請求項１７の方法。
25. 前記コンピュータシステムとの前記通信が、ネットワーク通信を介して前記口座所有者によって始められることを特徴とする請求項２４の方法。
26. 前記口座所有者に前記決済承認要求を電子的に確認する前記ステップが、
    ネットワークを介して前記口座所有者から接続要求を受信すること、
    前記口座所有者とのネットワーク接続を確立すること、
    前記口座所有者を認証すること、
    前記口座所有者に前記決済承認要求の少なくとも一部分を送信すること、
    前記決済承認要求に関して前記口座所有者から確認の指示を受信すること、
    を含むことを特徴とする請求項２４の方法。
27. 前記コンピュータシステムとの前記通信が、電話接続を介して前記口座所有者によって始められることを特徴とする請求項２４の方法。
28. 前記口座所有者に前記決済承認要求を電子的に確認する前記ステップが、
    前記口座所有者からの電話呼び出しを受けること、
    前記口座所有者を認証すること、
    前記口座所有者に前記決済承認要求の少なくとも一部分を唱えること、
    前記決済承認要求に関して前記口座所有者から確認の指示を受信すること、
    を含むことを特徴とする請求項２４の方法。
29. 前記口座所有者に前記決済承認要求を電子的に確認する前記ステップを、前記口座所有者によって選択的に有効あるいは無効にすることができることを特徴とする、請求項１７の方法。
30. 前記口座所有者に前記決済承認要求を電子的に確認する前記ステップが、もし前記決済承認要求が予め決定した時間内に前記口座所有者によって確認されない場合、前記承認要求を自動的に無効にすることを含むことを特徴とする、請求項１７の方法。
31. 前記決済承認要求が無効にされるとき前記口座所有者に通知を送信することを更に含む請求項３０の方法。
32. 前記商人からの前記決済承認要求を受信する前記ステップが、前記商人から前記決済承認要求を受信した第三者金融機関からの確認要求を受信することを含み、
    前記商人へ承認を送信する前記ステップが、前記第三者金融機関へ確認の証印を送信することを含む、
    ことを特徴とする請求項１７の方法。
33. 請求項１７の方法を電子装置に実行させるために、内部に具体化されたコードを有するコンピュータ読み取り可能媒体。
34. 請求項１８の方法を電子装置に実行させるために、内部に具体化されたコードを有するコンピュータ読み取り可能媒体。
35. 請求項１９の方法を電子装置に実行させるために、内部に具体化されたコードを有するコンピュータ読み取り可能媒体。
36. 請求項２０の方法を電子装置に実行させるために、内部に具体化されたコードを有するコンピュータ読み取り可能媒体。
37. 請求項２１の方法を電子装置に実行させるために、内部に具体化されたコードを有するコンピュータ読み取り可能媒体。
38. 請求項２２の方法を電子装置に実行させるために、内部に具体化されたコードを有するコンピュータ読み取り可能媒体。
39. 請求項２３の方法を電子装置に実行させるために、内部に具体化されたコードを有するコンピュータ読み取り可能媒体。
40. 請求項２４の方法を電子装置に実行させるために、内部に具体化されたコードを有するコンピュータ読み取り可能媒体。
41. 請求項２５の方法を電子装置に実行させるために、内部に具体化されたコードを有するコンピュータ読み取り可能媒体。
42. 請求項２６の方法を電子装置に実行させるために、内部に具体化されたコードを有するコンピュータ読み取り可能媒体。
43. 請求項２７の方法を電子装置に実行させるために、内部に具体化されたコードを有するコンピュータ読み取り可能媒体。
44. 請求項２８の方法を電子装置に実行させるために、内部に具体化されたコードを有するコンピュータ読み取り可能媒体。
45. 請求項２９の方法を電子装置に実行させるために、内部に具体化されたコードを有するコンピュータ読み取り可能媒体。
46. 請求項３０の方法を電子装置に実行させるために、内部に具体化されたコードを有するコンピュータ読み取り可能媒体。
47. 請求項３１の方法を電子装置に実行させるために、内部に具体化されたコードを有するコンピュータ読み取り可能媒体。
48. 請求項３２の方法を電子装置に実行させるために、内部に具体化されたコードを有するコンピュータ読み取り可能媒体。
49. 口座所有者と商人の間の商決済を確認するためのコンピュータシステムであって、
    データとコードを処理するための処理ユニットと、
    前記データと前記コードを格納するための記憶装置とからなり、
    前記コードは、前記口座所有者と関連する完全な口座番号を含む決済承認要求を受信するための前記商人との接続を促進するために機能する商人通信モジュールを含み、
    前記データは、前記口座所有者と関連する少なくとも１つの前もっての確認基準を含み、
    前記コードは、前記決済承認要求に応答し、前記決済承認要求と前記前もっての確認基準を比較するため、及びもし前記少なくとも１つの前もっての確認基準が満たされれば、前記決済承認要求を確認するために機能する認可モジュールを更に含んでいる、
    コンピュータシステム。
50. 前記少なくとも１つの前もっての確認基準が複数の前もっての確認基準を含み、
    もし、前記複数の前もっての確認基準の少なくとも１つが満たされれば、前記認可モジュールが前記決済承認要求を確認するために機能する、
    ことを特徴とする請求項４９のコンピュータシステム。
51. 前記少なくとも１つの前もっての確認基準が複数の前もっての確認基準を含み、
    前記複数の前もっての確認基準の全てが満たされる場合に限り、前記認可モジュールが前記決済承認要求を確認するために機能する、
    ことを特徴とする、請求項４９のコンピュータシステム。
52. 前記口座所有者によって、前記前もっての確認基準が決定されることを特徴とする、請求項４９のコンピュータシステム。
53. 前記口座所有者から接続要求を受信するため、
    前記口座所有者との接続を確立するため、
    前記口座所有者を認証するため、
    前記前もっての確認基準の少なくとも１つを前記口座所有者に提示するため、
    前記口座所有者からの前記前もっての確認基準の１つのための修正指示を受信するため、
    に機能する、口座所有者通信モジュールを更に含む、請求項４９のコンピュータシステム。
54. 前記口座所有者からの前記修正指示を受信する前には、前記決済承認要求によって、いかなる前記前もっての確認基準も満たすことができないことを特徴とする請求項５３のコンピュータシステム。
55. 前記前もっての確認基準は、少なくとも１つの商人識別子を含むことを特徴とする請求項４９のコンピュータシステム。
56. 前記決済商人要求の受信に応答する前記認可モジュールが、
    各前記商人識別子と、前記決済承認要求を送信する前記商人を比較するため、及び、
    前記決済承認要求を送信する商人が前記商人識別子の１つによって識別される場合、前記決済承認要求を確認するため、
    に機能することを特徴とする請求項５５のコンピュータシステム。
57. 前記前もっての確認基準が、前もって確認された最大購入代金を含むことを特徴とする請求項４９のコンピュータシステム。
58. 前記決済承認要求の受信に応答する前記認可モジュールが、
    前記前もって確認された最大購入代金を前記決済承認要求に含まれる購入代金と比較するため、及び、
    前記決済承認要求に含まれる購入代金が、前もって確認された前記最大購入代金未満である場合、前記決済承認要求を確認するため、
    に機能することを特徴とする請求項５７のコンピュータシステム。
59. 前記前もっての確認基準が、開始日付及び終了日付を含むことを特徴とする請求項４９のコンピュータシステム。
60. 前記決済承認要求の受信に応答する前記認可モジュールが、
    前記決済承認要求に含まれる購入日付を、前記開始日付及び終了日付と比較するため、及び、
    前記購入日付が前記開始日付と終了日付の間にある場合、前記決済承認要求を確認するため、
    に機能することを特徴とする請求項５９のコンピュータシステム。
61. コンピュータシステム中で、口座所有者と商人の間の商決済を確認するための方法であって、
    前記口座所有者に関連した少なくとも１つの前もっての確認基準を格納すること、
    前記商人から、前記口座所有者と関連した完全な口座番号を含む決済承認要求を受信すること、
    前記前もっての確認基準と前記決済承認要求を比較すること、
    前記前もっての確認基準が満たされる場合、前記決済承認要求を確認すること、
    を含む方法。
62. 少なくとも１つの前もっての確認基準を格納する前記ステップが、複数の前もっての確認基準を格納することを含み、前記前もっての確認基準の少なくとも１つが満たされる場合、前記決済承認要求を確認する前記ステップが前記決済承認要求を確認することを含むことを特徴とする請求項６１の方法。
63. 少なくとも１つの前もっての確認基準を格納する前記ステップが、複数の前もっての確認基準を格納することを含み、前記前もっての確認基準がすべて満たされる場合にのみ、前記決済承認要求を確認する前記ステップが前記決済承認要求を確認することを含むことを特徴とする請求項６１の方法。
64. 前記少なくとも１つの前もっての確認基準が、前記口座所有者によって決定されることを特徴とする請求項６１の方法。
65. 前記口座所有者との接続を確立すること、
    前記口座所有者を認証すること、
    前記口座所有者が、前記口座所有者に関連した前記前もっての確認基準を修正することを可能にすること、
    を更に含む請求項６１の方法。
66. 前記口座所有者による修正に先立って、前記前もっての確認基準は満たされることができないことを特徴とする請求項６５の方法。
67. 前記前もっての確認基準が、少なくとも１つの商人識別子を含むことを特徴とする請求項６１の方法。
68. 前記前もっての確認基準が複数の商人識別子を含み、前記商人が前記複数の商人識別子の１つによって識別される場合、前記決済承認要求が確認されることを特徴とする請求項６７の方法。
69. 前記前もっての確認基準が、前もって確認された最大購入代金を含むことを特徴とする請求項６１の方法。
70. 前記決済承認要求で識別された購入代金が前記前もって確認された購入代金未満である場合、前記決済承認要求が確認されることを特徴とする請求項６９の方法。
71. 前記前もっての確認基準が、少なくとも１つの前もっての確認日付を含むことを特徴とする請求項６１の方法。
72. 前記前もっての確認基準は、少なくとも１対の前もっての確認日付を含み、前記決済承認要求に含まれる決済日付が、前記前もって確認された日付の間にある場合、前記決済承認要求が確認されることを特徴とする請求項７１の方法。
73. 電子装置に請求項６１の方法を実行させるために、内部に具体化されたコードを有するコンピュータ読み取り可能媒体。
74. 電子装置に請求項６２の方法を実行させるために、内部に具体化されたコードを有するコンピュータ読み取り可能媒体。
75. 電子装置に請求項６３の方法を実行させるために、内部に具体化されたコードを有するコンピュータ読み取り可能媒体。
76. 電子装置に請求項６４の方法を実行させるために、内部に具体化されたコードを有するコンピュータ読み取り可能媒体。
77. 電子装置に請求項６５の方法を実行させるために、内部に具体化されたコードを有するコンピュータ読み取り可能媒体。
78. 電子装置に請求項６６の方法を実行させるために、内部に具体化されたコードを有するコンピュータ読み取り可能媒体。
79. 電子装置に請求項６７の方法を実行させるために、内部に具体化されたコードを有するコンピュータ読み取り可能媒体。
80. 電子装置に請求項６８の方法を実行させるために、内部に具体化されたコードを有するコンピュータ読み取り可能媒体。
81. 電子装置に請求項６９の方法を実行させるために、内部に具体化されたコードを有するコンピュータ読み取り可能媒体。
82. 電子装置に請求項７０の方法を実行させるために、内部に具体化されたコードを有するコンピュータ読み取り可能媒体。
83. 電子装置に請求項７１の方法を実行させるために、内部に具体化されたコードを有するコンピュータ読み取り可能媒体。
84. 電子装置に請求項７２の方法を実行させるために、内部に具体化されたコードを有するコンピュータ読み取り可能媒体。

Images