JP2008506206A - クレジット口座のセキュリティシステム及びセキュリティ方法 - Google Patents

Abstract

カード所有者、商事業者、クレジットカード会社間の商取引を検証するためのシステム及び方法を開示する。カード所有者は、全クレジットカード番号を使用して商事業者より購入する。商事業者は、クレジットカード会社に承認を得るために取引承認要求を提示する。クレジットカード会社は、その取引承認要求の従来のクレジット承認を実行するとともに、カード所有者と取引承認要求を検証する。取引承認要求が、従来どおりクレジットカード会社により承認され、且つカード所有者により検証された後でのみ承認は商事業者へ送信される。カード所有者又はクレジットカード会社は、取引承認要求の検証を開始してもよい。１又は多くの事前検証基準が、取引承認要求に含まれるデータにより満たされた場合、取引承認要求は自動的に検証され得る。事前検証基準は、カード所有者により、はじめに決定及び／又は修正され得る。他のセキュリティ機能として、カード所有者は、彼らのクレジットカード／口座を、所望に応じて選択的に活動可能及び活動不可能にすることができる。クレジットカードそれ自体は、セキュリティの程度の表示を含む。
【選択図】図２２

Description

本発明は、概して電子商取引に関し、特に安全な商取引を提供するためのシステム及び方法に関する。さらに詳細には、本発明は口座所有者による電子購入の検証を容易にするためのシステム及び方法に関する。

電子取引、即ち電子手段による売買は現代社会において一般的なものとなってきた。インターネット（最も厳密にいうと、ワールドウェブサイト）のブームにのり、商取引は、コンピュータの所有者の家庭又はオフィスで行われるようになった。幾つかの理由から、より多くの人々が家庭やオフィスのコンピュータによりビジネス（例えばショッピング）を行うことを選択するようになってきた。例えば、インターネットを用いたビジネスは一般的に割引価格で商品を提供することから、消費者はインターネット取引に魅力を感じる。加えて、インターネットは１日２４時間アクセスすることができるから、消費者が都合のよい時に商品を購入できる。

電子購入の支払い時には、ほとんどの消費者がクレジットカードを主要な方法とする。クレジットカードは、カード所有者の予め決められクレジット口座を示すものである。カード所有者は、クレジットカードを使用して、商事業者から電子購入する。そして商事業者は、購入要求をクレジットカード会社に提示（全てのクレジットカード番号を転送することも含む）して購入許可を得ようとする。それから、クレジットカード会社は、商事業者にそのクレジットカード取引を許可或いは拒否する。もし、購入が承認されれば、クレジット口座からこの購入金額が引き落とされる。

クレジットカードは、カード所有者にとって多くの利点がある。例えばクレジットカード利用者は、口座の清算、確認及び貯金ができる一方で、銀行で費やす時間を短縮できる。加えてクレジットカードをもっていれば、多額の現金を持ち運ぶ必要がない。加えて、クレジットカードを使用すると、自動的に購入が承認される。一方、チェックや現金で購入を注文すると購入が承認されるのに時間がかかる。従って、電話やメールで購入する際にクレジットカードを使用するとメールで支払いが送られることに付随するような遅延が発生しない。

電子取引の増加により、カード所有者にとってクレジットカードのセキュリティについての関心が高まってきた。クレジットカードの使用妨害や不正使用を懸念してインターネットを通してクレジットカードを使用して商品を購入することを警戒するカード所有者もいる。これは、多くのインターネット・ウェブ・ページで使用される言語（HTML;HYPER TEXT MARKUP LANGUAGE）は、不安定で情報が転送されやすい手段であるという理由からもっともなことである。インターネットのセキュリティ問題の対策として、商事業者のネットワークにおいて、インターネット上の取引をセキュリティのための暗号化技術を用いている。しかし、このような暗号化技術は、技術に習熟した犯罪者により解読可能であるから、セキュリティに関心のある消費者にとっては何ら安心できるものではない。さらに、たとえクレジットカード番号の転送がセキュリティされたとしても、カード番号が受信コンピュータに蓄積されている限り、そのコンピュータに侵入することにより盗まれる可能性がある。加えてクレジットカード番号は、ポケットスキャナ等の機器により直接盗まれる可能性がある。そしてこのポケットスキャナは不誠実なウェイターや販売員により使用され得る。

幾つかの商業用口座（例えば、当座預金口座）にはデビットカードが使用できる。このデビットカードもまた、クレジットカードと同様の（その危険性はクレジットカードのそれを超えるものではないが）セキュリティ問題に直面している。デビットカードは、クレジットカードに類似するものであるが、購入時にクレジットカード番号とともにカード所有者の個人特定番号（ＰＩＮ）を提示しなければデビットカードでの取引が完了しない点で異なる。加えて、デビットカードにより、そのカードと連結する口座（一般的には当座預金口座）から資金を引き出すことができる。多くの場合において、デビットカード取引で使用されるＰＩＮは、デビットカードと連結する口座にアクセス（例えば、ＡＴＭ機や電話）するために使用されるＰＩＮと同じである。もしデビットカードを使用した購入取引が妨害されて、カードが不正に使用されたとき、それらを不正に取得した人は、デビットカード番号とＰＩＮを用いて購入することもできるし、またデビットカードに連結する口座から直接資金を引き出すこともできる。

クレジットカードの安全性向上の関心により、クレジットカード会社と商事業者は、安全な電子取引の方法を提供することが強いられている。例えば、特許文献１（米国特許第６，０１２，１４４号、出願人；Pickett）は、クレジットカード取引のセキュリティを維持するための方法を開示している。この方法は、クレジットカード番号を２つの部分に分けて、それぞれを、１以上のサーバーコンピュータの別個のデータ格納デバイスに格納する。このカード所有者は、クレジットカード番号のどの部分をそれぞれの格納デバイスに送るかを決定し、そしていくつかの処理コード（パスワード）確保する。この処理コードは、自動電話呼び出しにより、後にカード所有者から得られ、購入が検証される。この方法による検証はいくつかの不利な点がある。まず、ピケットの方法によると、クレジットカードの全番号は、そのまま商事業者へ転送されるわけではないから、カード所有者は多大な時間を消費する。即ち、カード所有者はクレジットカード番号を解析し、スライシングコードを算出しなければならない。さらには、取引を検証するためには、カード所有者はそのスライシングコードを思い出さなければならず、このスライシングコードは取引により異なる可能性がある。加えて、この方法を実施するためには、商事業者は、セキュリティソフトウェアを提供することが強いられるが、そのようなシステムを提供することに同意するかもしれないし、同意しないかもしれない。即ち、カード所有者が、そのようなシステムを具備していない商事業者から購入をしようとする場合は、何ら安全性が確保されない。

特許文献２（米国特許第５，９０３，７２１号、出願人；Sixtus）には、クレジットカード取引における改善されたセキュリティを提供するための代替方法が記載されている。シクストウスの方法は、カード所有者がインターネット上での購入することに関連する。カード所有者を検証するために使用される「トラストサーバ」は、カード所有者のＩＰ（インターネットプロトコル）アドレスとともに購入要求を受信する。トラストサーバで受信されたＩＰアドレスが、所有者に応じて登録されたＩＰアドレスと合致した場合、購入が確認されて「クレジット決済所」へ転送される。この「クレジット決済所」で、その購入が承認又は非承認される。この方法によると、クレジットカードの秘密事項を含むような情報は、安全でないネットワーク上で転送されない。但し、このような利点は、前述のトラストサーバに登録されたＩＰアドレスを保有するコンピュータからの取引に限定される。加えて、いくつかのインターネットサービスプロバイダ（ＩＰＳ）は、動的なＩＰＳアドレスを必要とする。このような一時的に使用されるＩＰＳアドレスは、ユーザがＩＰＳのネットワークにログオンする際に分配される。即ち、動的なＩＰアドレシングを採用するインターネットサービスプロバイダを持つカード所有者はシクストウスの方法による取引セキュリティシステムを利用することができない。

他の例として、特許文献３（米国特許第５，９９１，７３８号、出願人；Ogram）には、暗号化ソフトウェアを利用する方法が開示されている。オグラムの方法を採用して商事業者から商品を購入しようとするカード所有者は、商事業者のコンピュータから暗号化ソフトウェアをダウンロードする。この暗号化ソフトウェアは、商事業者への転送の前に、秘密事項を含むようないかなる情報をもコード化する。オグラムの方法の不利な点は、カード所有者による、セキュリティの安全な購入の検証プロセスを欠いているという点である。加えて、使用される暗号化技術は取引の間に妨害を受けたり、解読されたりすることもある。

米国特許第６，０１２，１４４号 米国特許第５，９０３，７２１号 米国特許第５，９９１，７３８号

安全でセキュリティの備えたクレジットカード取引処理を提供するためのシステムや方法が必要である。さらに、商事業者に分かりやすい、安全でセキュリティの備えたクレジットカード取引を提供するためのシステム及び方法も必要である。カード所有者がクレジットカード取引を検証でき、そして、カード所有者のクレジットカードに試みられた使用について即座に通知することを提供するシステムや方法もまた必要である。

本発明は、先行技術に関連する問題点を解決するものである。これは、商事業者に分かりやすい安全でセキュリティが備わったクレジットカード取引処理を可能とするシステム及び方法を提供することにより成し得る。本発明は、商事業者に承認が転送される前に、カード所有者によるそれぞれのクレジットカード取引の検証を可能とし、さらにカード所有者のクレジットカードに試みられた使用について即座に通知することを提供する。

口座所有者と商事業者との間の商取引を処理するためのコンピュータシステムを開示する。このコンピュータシステムは、データ及びコードを実行するための処理ユニット、及び前記データ及び前記コードを格納するメモリ装置を含む。前記格納され実行されたコードは商事業者通信モジュールを含み、取引承認要求を受信するために機能し、この取引承認要求は、完全な口座番号を含む。前記コードはさらに口座所有者通信モジュールを含み、該口座所有者通信モジュールは、口座所有者との別個の接続を促して、受信された取引承認要求を検証するために機能する。前記コードはさらに認可モジュールを含み、この認可モジュールは取引承認要求に応答するとともに、取引承認要求が口座所有者により検証された時のみ商事業者へ承認を転送するように機能する。

特定の実施形態において、認可モジュールは相互検証モジュールを含んでおり、この相互検証モジュールは、取引承認要求の受領に反応して口座所有者との接続を開始するために機能する。他の特定の実施形態では、コンピュータシステムはさらにネットワークインターフェイスを含み、相互検証モジュールは、このネットワークインターフェイスを介して、口座所有者への電子メッセージを転送するために機能する。この相互検証モジュールはさらに機能して、転送された電子メッセージの応答を受領したときに取引承認要求を検証する。

他の特定の実施形態において、コンピュータシステムはさらに電気通信装置を備える。含まれる相互検証モジュールは機能して、口座所有者に対し自動電話呼び出しをし、口座所有者に対し承認要求の一部を暗唱して、口座所有者から検証の指示を受ける。他の特定の実施形態では、前記相互検証モジュールが機能して、取引承認要求の一部が暗唱される前に認証コードを要求する。

必要に応じて、相互検証モジュールは口座所有者がシステムと通信を開始するまで機能しない。或いは、システムは口座所有者と接続を開始して係属中の取引承認要求を検証する。

特定の実施形態において、認可モジュールは口座所有者からの指示に応答する。この認可モジュールにより、口座所有者が追加の入力をせずに後の取引承認要求を自動的に検証できるような検証処理を、選択的になくすことができる。

他の特定の実施形態は、認可モジュールがマスタ検証モジュールを含む。口座所有者が、所定の期限が切れる前に取引承認要求を検証しなかった場合は、このマスタ検証モジュールは自動的に取引承認要求を拒否する。マスタ検証モジュールはさらに機能して、取引承認要求が拒否された場合に口座所有者へ通知を転送する。

他の特定の実施形態において、取引承認要求は第三者金融機関からの検証要求を含み、認可モジュールは機能して第三者金融機関へ検証の表示を転送する。

さらに、口座所有者と商事業者との間の安全でセキュリティを備えた商取引を提供するための方法が開示される。前記方法には、口座所有者の口座を特定する全口座番号を含む取引承認要求を受信する段階、商事業者からの別個の通信を介して取引承認要求を口座所有者に電子検証を行わせる段階、及び口座所有者により取引承認要求が検証された場合のみ商事業者に承認を転送する段階が含まれる。

特定の方法において、取引承認要求を口座所有者に電子検証を行わせる前記の段階は、口座所有者に取引承認要求を検証するように促す段階を含む。さらなる特定の方法においては、この口座所有者に取引承認要求を検証するように促す段階は、電子メッセージを送信する段階を含む。他の特定の方法においては、取引承認要求を検証する前記の段階に前記電子メッセージへの応答を受信する段階を含む。その他の特定の方法では、口座所有者に促す段階は、自動電話呼び出しを口座所有者に対し行う段階、口座所有者との接続を確立する段階、取引承認要求の少なくとも一部を暗唱する段階、口座所有者から検証の指示を受信する段階を含む。さらに特定の方法において、取引承認要求の少なくとも一部が暗唱される前に、口座所有者が確認される。

他の方法としては、コンピュータシステムと通信して口座所有者が検証処理を開始することを待つ段階を含む。特定の方法において、ネットワーク又は電話接続を介して、口座所有者により検証が開始されるとともに、ネットワーク又は電気通信装置を介して口座所有者からの接続要求を受信する段階、口座所有者との接続を確立する段階、口座所有者を認証する段階、口座所有者に取引承認要求の少なくとも一部を転送する段階、及び取引承認要求に関して口座所有者から検証の指示を受信する段階を含む。

必要に応じて、口座所有者は、選択的に検証処理をすることもできるし、無効にすることもできる。

他の特定の方法としては、取引承認要求を電子検証する前記の段階は、口座所有者が所定の期間内に取引承認要求を行わない場合は、取引承認要求を無効とする段階を含む。さらに詳細には、取引承認要求が無効とされた場合に、口座所有者にこの通知が送られる。

他の特定の方法として、商事業者から取引承認要求を受信する前記の段階には、商事業者から検証要求を受信した第三者金融機関からの検証要求を受信する段階を含む。商事業者へ承認を転送する前記の段階は、第三者金融機関へ検証の表示を転送する段階を含む。

商事業者と口座所有者との間の特定の取引を事前に検証するためのシステム及び方法もまた開示される。特定の実施形態において、コンピュータシステムは、データ及びコードを処理するための処理ユニット、及び該データ及びコードを格納するためメモリ装置を備える。前記データには、口座所有者と関連する少なくとも一つの事前検証基準を含む。前記コードは、商事業者通信モジュールを含み、この商事業者通信モジュールは、商事業者から取引承認要求を受信する。また、前記コードは、認可モジュールを含む。前記認可モジュールは前記の検証基準と取引承認要求を比較し、前記検証基準を満たせば、自動的に取引承認要求を検証する。これにより、承認処理を完了する前に、口座所有者から取引承認要求の直接的な検証を得る必要がない。

特定の実施形態において、前記の事前検証基準は、複数の事前検証基準を含み、これは口座所有者に関連するものである。そして、この事前検証基準のいずれかが満たされれば、取引承認要求は検証される。他の実施形態においては、前記複数の検証基準の全てが満たされない限り取引承認要求は自動的に検証されない。有用な事前検証基準としては、例えば、商事業者の識別子、取引金額（例えば、購入価格）、取引日付、取引時間、又は他の基準等の口座所有者が便利であると考える基準が挙げられるが、これらに限定されない。必要に応じて、コードはさらにカード所有者通信モジュール及び／又は相互検証モジュールを含む。この相互検証モジュールは、口座所有者が事前検証基準の修正することを可能とする。一つの実施形態において、前記事前検証基準は、まず口座所有者により修正されない限りは、如何なる取引承認要求も検証されないように設定されている。或いは、初期の事前検証基準は口座所有者により決定される（例えば口座を開く時に）

口座所有者の口座を、選択的に活動可能及び活動不可能にするためのシステム及び方法もまた開示される。コンピュータシステムは、データ及びコードを処理するための処理ユニットと、該データ及びコードを格納するためのメモリ装置を含む。前記データは活動可能データを含み、該データは口座所有者に接続可能で、口座所有者の口座が活動可能な状態であることを示す。前記コードは商事業者から取引承認要求を受信する商事業者通信モジュール及び認可モジュールを含む。該認可モジュールは、取引承認要求を承認又は拒否し、これは、活動可能データの少なくとも一部及び口座の関連する口座の活動可能な状態に基づき決定される。これにより、口座所有者の要望に応じて口座を一時的に活動可能にしたり、活動不可能にしたりことができる。

特定の実施形態において、活動可能データは少なくとも一つの活動可能条件（例えば活動可能日時）を含み、もし取引承認要求がこの活動可能条件（例えば、購入日時が活動可能日時より後である）を満たした場合は、認可モジュールが機能して、取引承認要求を承認する。他の特定の実施形態では、活動可能データは、少なくとも一つの活動不可能条件（例えば活動不可能日時）をも含み、もし取引承認要求が活動可能条件を満たし、且つ活動不可能条件を満たさない場合（例えば購入日時が活動不可能日時より前である）のみ、認可モジュールは取引承認要求を承認する。

他の特定の実施形態において、口座所有者は自動活動可能基準及び自動付活動不可能基準を特定することができ、認可モジュールは自動的に前記基準を実装することができる。活動不可能条件としては、コンピュータシステムから受信する取引承認要求の所定の数（例えば、１）であってもよく、それから認可モジュールは機能して口座所有者の口座を自動的に活動不可能にすることができる。

他の特定の実施形態において、認可モジュールが相互活動可能モジュールを含み、この相互活動可能モジュールは機能して、口座所有者との接続を確立し、口座所有者を認証し、口座所有者に対し口座所有者の口座の最新の活動可能な状態を表示し、口座所有者から支持を受信して活動可能データを修正する。例えば、電話によって口座所有者と相互活動可能モジュールとの間の接続が確立され得る。さらに特定の実施形態において、相互活動可能モジュールが機能して、口座所有者から受けた指示（例えば、活動可能或いは活動不可能日時の）を格納する。

口座所有者と商事業者との間の商取引を容易にする方法もまた開示される。この方法には、口座所有者から活動不可能にするための指示を受信して一時的に口座を活動不可能にする段階、商事業者から取引承認要求を受信する段階、口座所有者が一時的に口座を活動不可能にしたか否かを決定する段階、及び口座が一時的に活動不可能にした場合は取引承認要求を拒否する段階を含む。

本発明は以下の図面を参照して記載され、図面中、略同様の要素に対しては同じ符号がつけられている。
本発明は、上記従来技術に係る課題を解決する。本発明は、安全且つ確実な電子取引を提供する新規なシステム並びに方法を提供する。本発明のシステム並びに方法は、口座所有者との各電子取引を検証するものである。
以下の説明において、多くの特定の詳細な形態が示される（例えば、クレジットカード会社により処理される検証、カード所有者によりなされる検証など）。これら詳細な説明は、本発明の全体的な理解をもたらすものとなる。
しかしながら、本発明は、これら詳細な説明において示された形態とは異なる形態で実施されてもよい。例えば、周知の電子商行為の詳細（例えば、電子クレジット要求／承認プロセス、コンピュータ・オペレーティング・システム、通信ソフトウェアなど）は、本明細書では、省略されている。なぜなら、これら詳細は、本発明を不必要に不明瞭にする可能性があるためである。

図１は、システム（１００）のブロック線図である。
システム（１００）は、カード所有者（１０２）、商事業者（１０４）、クレジットカード会社（１０６）及び第三者検証会社（１０８）から構成される。カード所有者（１０２）、商事業者（１０４）、クレジットカード会社（１０６）及び第三者検証会社（１０８）それぞれは、インターネットワーク（１１０）（例えば、インターネット）に接続する。この接続は、物理的ネットワークメディア（１１２（１−４））（例えば、電話回線、同軸ケーブルなど）によりなされる。カード所有者（１０２）、商事業者（１０４）、クレジットカード会社（１０６）及び検証会社（１０８）は、他の物理的ネットワークメディア（１１４）（例えば、電話回線）を介して通信可能な状態とされる。

カード所有者（１０２）は、クレジットカードを所有する者である。クレジットカードは、クレジットカード会社（１０６）により提供される口座を識別する数字（ナンバ）を備える。
商事業者（１０４）は、商品やサービスを提供する者である。カード所有者（１０２）はクレジットカードナンバを用いて、インターネットワーク（１１０）を介して、これら商品やサービスを購入可能である。カード所有者（１０２）は、全クレジットカードナンバを用いて、商事業者（１０４）から電子購入要求を作成する。この購入行為は、インターネットワーク（１１０）、物理的ネットワークメディア（１１４）上或いは個人的に行なわれる。購入要求の受領に応じて、商事業者（１０４）は、取引承認要求（TAR: transaction approval request）をクレジットカード会社（１０６）に提出する。

ＴＡＲは、その後、承認の前に、２つの部分の認可を受ける。或いは、拒絶が商事業者（１０４）に発行される。最初に、購入要求が、クレジットカード会社（１０６）により標準的なクレジット承認を受ける。クレジット承認の後、購入要求は、カード所有者（１０２）とともに、クレジットカード会社（１０６）又は検証会社（１０８）のいずれかにより検証される。
検証は、インターネットワーク（１１０）或いは物理的ネットワークメディア（１１４）上で実行される。検証の後、購入が、クレジットカード会社（１０６）に承認され、且つ、カード所有者（１０２）により検証された場合に、承認が、物理的ネットワーク（１１４）又はインターネットワーク（１１０）を介して、商事業者（１０４）に送信される。

この特定の実施形態において、クレジットカードは、電子取引を容易にする。本発明は、クレジットカードを用いた購入行為に限定されるべきものではない。本発明は、あらゆる種類の口座（例えば、デビットカード）とともに使用され、口座番号の送信を伴う電子取引を安全且つ確実に行なうことを可能とする。
以下の説明において、クレジットカード会社（１０６）は、検証プロセスを実行する。しかしながら、検証プロセスは、必要に応じて、第三者検証会社（１０８）が実行するものであってもよい。このような実施形態において、クレジットカード会社（１０６）は、検証要求を検証会社（１０８）に送信する。検証会社（１０８）は、その後、カード所有者（１０２）とともに取引要求を検証し、検証表示（検証表示は、取引要求が検証されたか否か、取引要求が拒否されたか否かなどを表示するものである）をクレジットカード会社（１０６）に送信する。

図２は、サーバ（２００）（例えば、HTTPインターネットサーバ）のブロック線図である。サーバ（２００）は、物理的ネットワークメディア（１１２（３））を介してインターネットワーク（１１０）に接続する。
この特定の実施形態において、サーバ（２００）は、クレジットカード会社（１０６）の取引サーバである。このサーバは、クレジットカード会社（１０６）とのクレジットカード取引を処理するためのものである。
サーバ（２００）は、処理ユニット（PU: Processing Unit）（２０２）、ネットワークインターフェイス（２０４）、システムバス（２０６）、不揮発性メモリ（２０８）、少なくとも１つの入力／出力（I/O: input/output）コントローラ（２１０）、システムクロック（２１２）、通信機器（２１４）及び作業メモリ（２１６）を備える。
ＰＵ（２０２）は、作業メモリ（２１６）内に格納されたデータ及びコードを実行し、サーバ（２００）に所望の機能（例えば、クレジットカード取引を処理するなど）を実行させる。システムバス（２０６）は、サーバ（２００）の様々なコンポーネント間の相互通信を可能とする。

サーバ（２００）は、ネットワークインターフェイス（２０４）を介して、インターネットワーク（１１０）上で通信を行う。ネットワークインターフェイス（２０４）（例えば、イーサネット（登録商標）・アダプタ・カード）は、データパケットをインターネットワーク（１１０）上に送信するとともにインターネットワーク（１１０）からのデータパケットを受信する。これにより、サーバ（２００）が、カード所有者（１０２）と商事業者（１０４）と、インターネットワーク（１１０）を介して通信することが可能となる。不揮発性メモリ（２０８）（例えば、リードオンリ・メモリや１又はそれ以上のハードディスクドライブ）は、データ及びコード（例えば、ブートコード及びプログラムなど）の格納機能を提供する。この結果、サーバ（２００）の電源が落とされたときであっても、データ及びコードは保持されることとなる。
Ｉ／Ｏコントローラ（２１０）は、サーバ（２００）のシステムアドミニストレータとして、ユーザ・インターフェースデバイス（図示せず）に対する接続を管理する。Ｉ／Ｏデバイスは、典型的には、キーボード、マウス、モニタ、プリンタ及びサーバ（２００）とアドミニストレータとの間の通信を容易にするその他デバイスを備える。サーバ（２００）は更に、システムクロック（２１２）を備える。システムクロック（２１２）は、適切な日付並びに時間を維持し、要求上に日付データ及び時間データを提供する。

サーバ（２００）は、更に、通信機器（２１４）（例えば、モデム或いは電話）を備える。通信機器（２１４）は、リモートシステム或いはリモートパーティとサーバ（２００）間のデータ通信又は音声通信のいずれかを確立する。リモートシステムの例として、カード所有者（１０２）、商事業者（１０４）又は検証会社（１０８）により所有されるコンピュータを挙げることができる。特定の実施形態において、カード所有者（１０２）との音声接続が、係属中のＴＡＲを検証するために用いられる。

作業メモリ（２１６）（例えば、ランダムアクセスメモリ）は、サーバ（２００）にダイナミックメモリを提供する。作業メモリ（２１６）は、実行可能コード（例えば、オペレーティングシステム（２１８））を備える。実行可能コードは、システムスタートアップの間、作業メモリ（２１６）内にロードされる。
オペレーティングシステム（２１８）は、作業メモリ（２１６）内にロードされた全ての他のモジュールの制御並びに実行を可能とする。作業メモリ（２１６）は更に、クレジット承認要求キュー（２２０）（CARQ: Credit Approval Request Queue）、カード所有者リストモジュール（２２４）、認可モジュール（２２６）、検証係属キュー（２２８）（VPQ: verification pending queue）、購入履歴モジュール（２３０）及び商事業者通信モジュール（２３２）を備える。上述のモジュール及びキューそれぞれは、初期化され、周知の従来技術を用いて、スタートアップ時に不揮発性メモリ（２０８）から作業メモリ（２１６）にロードされる。必要に応じて、上記のモジュール及びキューは、代わりの大量データ記憶装置から作業メモリ（２１６）にロードされる。この大量データ記憶装置として、限定するものではないが、ＣＤＲＯＭ、テープ或いは高容量のリムーバブルデータ記憶ディスク（例えば、Iomega's Jaz（登録商標）やZip（登録商標）ドライブ）を例示できる。

認可モジュール（２２６）は、ＴＡＲの承認及び検証を制御並びに調整を行う。上述の如く、第３者検証会社（１０８）が検証を処理する他の実施形態において、認可モジュール（２２６）は、検証に対する要求を検証会社（１０８）に送信し、検証会社（１０８）から検証表示を受信する。
送信された検証に対する要求は、購入要求に関連する情報（製品説明、購入価格、商事業者名或いは検証対象のカード所有者に取引を識別させるために役に立つ他の情報など）を備える。受信された検証表示は、例えば、コードを備える。このコードは、特定の取引がカード所有者により検証されたこと或いは拒否されたことを示す。必要に応じて、認可モジュールは、カード所有者（１０２）により与えられた指示に応じて、更に、検証プロセス（例えば、自動的に全ての取引或いは１つの特定の商事業者に対する取引を自動的に検証すること）を選択的に無効にすることも可能である。検証プロセスを無効にすることの指示は、一般的に、安全なネットワーク（例えば、電話或いはメール）上でカード所有者（１０２）によりなされるものである。

商事業者通信モジュール（２３２）は、ネットワークインターフェイス（２０４）又は通信機器（２１４）を介して、商事業者（１０４）からＴＡＲを受信し、承認或いは拒否を商事業者に送信する。カード所有者通信モジュール（２２４）は、サーバ（２００）とカード所有者（１０２）間のインターネットワーク（１１０）又は物理的ネットワークメディア（１１４）を介した通信を管理する。カード所有者リストモジュール（２２２）は、データベースであり、このデータベースは、クレジットカード会社（１０６）の現在の顧客（カード所有者（１０２）を含む）に対する個人情報及び口座情報を格納する。
カード所有者リストモジュール（２２２）は、典型的には非常に大きなファイルとなる。したがって、カード所有者リストモジュール（２２２）がメモリ（２１６）内で示されるとき、顧客ファイル全体が、大量データ格納システム（不揮発性メモリ（２０８）など）に格納されてもよい。また、全リストの一部が、必要に応じて、カード所有者リスト（２２２）内外に交換されてもよい。

クレジット承認要求キュー（２２０）（CARQ: Credit Approval Request Queue）は、係属中のＴＡＲに対する格納機能を提供する。この係属中のＴＡＲとは、認可モジュール（２２６）による従来のクレジット承認を待っている状態のものを意味する。
商事業者通信モジュール（２３２）は、定期的にネットワークインターフェイス（２０４）と通信機器（２１４）を確認し、商事業者からの新たなＴＡＲが存在するか否かを判定し、任意のこのような要求をＣＡＲＱ（２２０）に送信する。

検証係属キュー（２２８）（VPQ: Verification Pending Queue）は、カード所有者による検証を待っている状態の係属中のＴＡＲを格納する機能を提供する。認可モジュール（２２６）は、ＣＡＲＱ（２２０）からＶＰＱ（２２８）へ、ＴＡＲを送信する。このＴＡＲの送信は、ＴＡＲが、有効な口座に対応するものと確認され、従来のクレジット承認を通過した後に行なわれる。検証がなされるまで、拒否がなされるまで、所定の期間が経過するまで、ＴＡＲはＶＰＱ（２２８）内に存する状態を保つ。

ひとたびＴＡＲが承認され、或いは、拒否されると、ＴＡＲの記録が、購入履歴モジュール（２３０）へ送信される。購入履歴モジュール（２３０）は、所定期間（例えば３０日の期間）における過去の口座活動の情報を格納する。取引の記載された記録（例えば、請求書、電子請求書など）がカード所有者（１０２）に運ばれてから所定の期間が経過すると、各期限切れのＴＡＲが作業メモリ（２１６）からより恒久的な格納メディア（例えば、磁気テープ）に送信される。

図３は、認可モジュール（２２６）のブロック線図を示す。
認可モジュール（２２６）は、クレジット承認モジュール（３０２）、マスタ検証モジュール（３０４）、相互検証モジュール（３０６）及び商事業者応答モジュール（３０８）を備える。
クレジット承認モジュール（３０２）は、各ＴＡＲに対する従来式のクレジット承認を実行する。各ＴＡＲは、周知の方法により、ＣＡＲＱ（２２２）内に含まれるものとなっている。マスタ検証モジュール（３０５）は、認可プロセス及び検証プロセスを調整し、認可モジュール（２２６）の全体的な制御を司る。相互検証モジュール（３０６）は、カード所有者（１０２）との検証を実行する。商事業者応答モジュール（３０８）は、取引承認或いは取引拒否を送信することにより、商事業者（１０４）との最終的な通信を執り行う。

図４は、クレジット承認要求のデータ構造（４００）の一例を示す。このデータ構造（４００）は、本発明の特定の実施形態とともに好適に使用可能である。当業者であれば、データ構造（４００）は、記録（４０２（１−ｎ））の連結されたリストとして認識可能である。
各記録（４０２（１−ｎ））は、係属中のＴＡＲを表し、全クレジットカードナンバ（４０４）、購入説明（４０６）、購入価格（４０８）、商事業者情報（４１０）、購入日時情報（４１２）、検証フラグ（４１４）、検証着手フラグ（４１５）、承認フラグ（４１６）、拒否フラグ（４１８）及びポインタ（４２０）を備える。全クレジットカードナンバ（４０４）、購入説明（４０６）、購入価格（４０８）、商事業者情報（４１０）及び購入日時情報（４１２）は、ＴＡＲとともに商事業者（１０４）から送信されサーバ（２００）により受信される。
検証フラグ（４１４）、承認フラグ（４１６）及び拒否フラグ（４１８）は、認可プロセスにおける各記録（４０２）の状態を示すために用いられる。このことに関しては、下記において詳述される。
ポインタ（４２０）は、リスト中の次の記録（４０２（＋１））のメモリアドレスを示す。最後の記録（４０２（ｎ））は、最終のリスト値（４２２）を備え、リスト値（４２２）は、記録（４０２（ｎ））がリスト中の最後の記録であることを表す。

検証フラグ（４１４）、検証着手フラグ（４１５）、承認フラグ（４１６）及び拒否フラグ（４１８）は、シングルビットのフラグであり、これらは各記録の状態を示す。
検証フラグ（４１４）は、関連するＴＡＲが検証されたか否か（例えば、検証フラグ（４１４）＝１）又はＴＡＲが検証されていないか否か（例えば、検証フラグ（４１４）＝０）を示す。
検証着手フラグ（４１５）は、サーバ（２００）がカード所有者（１０２）との検証プロセスを着手したか否かを示す。
承認フラグ（４１６）は、関係するＴＡＲが承認されたか否か（例えば、承認フラグ＝１）を示す。
拒否フラグ（４１８）は、関係するＴＡＲが拒否されたか否か（例えば、拒否フラグ＝１）を示す。

図５は、カード所有者データ構造（５００）の一例を示す。このデータ構造（５００）は、カード所有者リストモジュール（２２２）内のカード所有者データを格納するのに好適に利用される。当業者であれば、データ構造（５００）を、記録（５０２（１−ｎ））の連結されたリストとして認識可能である。
各記録（５０２）は、関係するカード所有者に発行された全クレジットカードナンバ（５０４）、個人識別ナンバ（５０６）（PIN: personal identification number）、カード所有者情報（５０８）、コンタクト情報（５１０）、クレジット限界（５１２）、検証要求フラグ（５１４）、着手検証フラグ（５１６）及びポインタ（５１８）を備える。

ＰＩＮ（５０６）は、コードであり、検証プロセスの間、カード所有者（１０２）を認証するため若しくはカード所有者が選好セッティング（例えば、検証要求フラグ（５１４）、着手検証フラグ（５１６）など）をセットするために、このコードは用いられる。
カード所有者情報（５０８）は、限定するものではないが、カード所有者の氏名、誕生日、社会保障番号及び／又は住所などといった個人情報を備える。
コンタクト情報（５１０）は、関係するカード所有者との受信、特にＴＡＲ検証のための通信に必要とされる情報を備える。コンタクト情報（５１０）は、限定するものではないが、電話番号、ポケットベルの番号或いはＥメールアドレスを含む。
クレジット限界（５１２）は、関係するカード所有者に予め設定されたクレジット限界を示す。
検証要求フラグ（５１４）は、カード所有者（１０２）が選択的に検証プロセスを無効にすることを可能とする。無効化される検証プロセスは、例えば、カード所有者からの更なる入力なしに自動的に後に続くＴＡＲを検証するプロセスである。この実施形態において、検証要求フラグ（５１４）は、シングルビットのフラグである。値「１」は、検証プロセスが実行されるべきことを意味し、値「０」は、カード所有者が検証プロセスを一時停止したい場合を意味する。
シングルビットの着手検証フラグ（５１６）は、カード所有者（１０２）が、サーバ（２００）が検証プロセスを着手することを望んでいるか否か或いはサーバ（２００）が、ユーザが検証プロセスを着手することを待つべきか否かを示す。着手検証フラグ（５１６）が値「１」を有するならば、相互検証モジュール（３０６）は、関係するカード所有者と検証プロセス（例えば、Ｅメール、オートメーション化した電話など）を開始する。着手検証フラグ（５１６）が、値「０」を有するならば、関係するカード所有者は検証（例えば、サーバ（２００）に電話をかける、インターネットワーク（１１０）を介してサーバ（２００）にログオンするなど）を着手しなければならない。
ポインタ（５１８）は、カード所有者データ構造（５００）内の次の記録（５０２）の開始アドレスを示す。リスト末端インディケータ（５２０）は、記録（５０２（ｎ））がカード所有者データ構造（５００）内の最後の記録であることを示す。

図６は、購入履歴データ構造（６０６）の一例を示す。このデータ構造（６０６）は、本発明の特定の実施形態に好適に使用可能である。
購入履歴データ構造（６００）は、記録（６０２（１−ｎ））の連結されたリストである。記録（６０２（１−ｎ））それぞれは、全クレジットカードナンバ（６０４）、購入情報（６０６）、購入価格（６０８）、商事業者情報（６１０）、検証日時（６１２）及びポインタ（６１４）を備える。
クレジットカードナンバ（６０４）は、関係するカード所有者との特定の取引を識別する。
購入情報（６０６）は、カード所有者に対して取引を識別させることを助ける情報（例えば、製品説明など）を含む。
購入価格（６０８）は、購入に関連する費用を示す。
商事業者情報（６１０）は、ＴＡＲを提出した商事業者を識別する。
検証日時（６１２）は、仮に検証が行なわれた場合、関連するカード所有者がＴＡＲを検証した日時を指し示す。
ポインタ（６１４）は、データ構造（６００）内の次の記録（６０２）のアドレスを指し示す。
リスト末端インディケータ（６１６（ｎ））は、記録（６０２（ｎ））が購入履歴データ構造（６００）内の最後の記録であることを示す。

上記のクレジット承認要求データ構造（４００）、カード所有者データ構造（５００）及び購入履歴データ構造（６００）は、その性質からみて例示的なものに過ぎないことは、当業者には理解されるべきである。したがって、本発明に他のデータ構造や類似のデータ構造が利用されてもよい。したがって、本明細書において一例として示された特定のデータ構造は、本発明の必要不可欠な発明特定事項として捉えられるべきものではない。

図１乃至図６を参照して、本発明の特定の実施形態の操作について説明する。
カード所有者（１０２）が、商事業者（１０４）に商品やサービスに対して注文書を提出すると、プロセスが開始する。プロセスは、支払手段としてクレジットカード会社（１０６）が割り当てたクレジットカードナンバを用いる。
商事業者（１０４）は、その後、取引承認要求をクレジットカード会社（１０６）に送信する。この取引承認要求は、カード所有者（１０２）により与えられたクレジットカード番号、購入に関する説明、購入価格、購入日時及び商事業者（１０４）を識別する情報を備える。

商事業者通信モジュール（２３２）（図２参照）は、周期的にネットワークインターフェイス（２０４）並びに通信機器（２１４）を確認し、商事業者（１０４）から新たなＴＡＲが存するか否かを確認する。
ＴＡＲが受信されると、商事業者通信モジュール（２３２）は、カード所有者リスト（２２２）をスキャンし、ＴＡＲを備えるクレジットカードナンバと一致するクレジットカードナンバ（５０４）を備える記録（５０２）（図５参照）が存するか否か判定する。もし、カード所有者リスト（２２２）内にこのような記録が存しない場合、その後、商事業者通信モジュール（２３２）は、拒否を商事業者（１０４）に送信する。

しかしながら、提供されたクレジットカードナンバが、カード所有者リスト（２２２）内のクレジットカードナンバ（５０２（ｘ））に一致する場合には、その後、商事業者通信モジュール（２３２）は、クレジット承認要求記録（４０２）を作成する。この作成には、ＴＡＲとともに提供された情報が用いられる。これにより、フィールド（４０４，４０６，４０８，４１０，４１２）が作られ、ＣＡＲＱ（２２０）内に新たな記録が格納される。
最初に、検証フラグ（４１４）、承認フラグ（４１６）及び拒否フラグ（４１８）が全て「ゼロ」の値に等しい値にセットされる。

認可モジュール（２２６）のマスタ検証モジュール（３０４）は、定期的にＣＡＲＱ（２２０）をスキャンし、係属中のＴＡＲを確認する。フラグ（４１４，４１６，４１８）の状態に基づき、任意の係属中のＴＡＲが処理される。例えば、第１のＴＡＲ記録（４０２（１））の承認フラグ（４１６（１））がゼロに等しい値にセットされている場合、その後、マスタ検証モジュール（３０４）は、クレジット承認モジュール（３０２）を呼び出し、ＴＡＲ（４０２（１））の従来のクレジット承認を実行する。

クレジット承認モジュール（３０２）は、当業者に周知の方法で、従来型のクレジット承認プロセスを実行する。限定するものではないが、従来のクレジット承認は、典型的には、購入価格（４０８（１））とカード所有者（１０２（ｘ））のクレジット限界（５１２（ｘ））に対して残存しているカード所有者（１０２（ｘ））の残高とを比較するクレジット承認モジュール（３０２）を備える。
購入金額（４０８（１））とカード所有者（１０２（ｘ））の残存する残高の合計が、クレジット限界（５１２（ｘ））を下回るか等しい状態となると、クレジット承認モジュール（３０２）は、承認フラグ（４１６（１））を「１」に等しい値にセットする。或いは、購入金額（１）とカード所有者（１０２（ｘ））の残存する残高が、クレジット限界（５１２（ｘ））以上であるならば、その後、クレジット承認モジュール（３０２）は、拒否フラグ（４１８（１））を「１」に等しい値にセットする。

ＣＡＲＱ（２２０）の次のスキャンの間、マスタ検証モジュール（３０４）は再度、フラグ（４１４（１）、４１６（１）、４１８（１））を再検査し、適切な動作を決定する。検証フラグ（４１４（１））は、「０」に等しい値とされている点は重要である。なぜなら、ＴＡＲ記録（４０２（１））は、検証のための処理を施されていないためである。拒否フラグ（４１８（１））が「１」に等しい値にセットされる場合、その後、マスタ検証モジュール（３０４）は、商事業者応答モジュール（３０８）を呼び出し、拒否を商事業者（１０４）に送信する。更に、マスタ検証モジュール（３０４）は、記録（４０２（１））をＣＡＲＱ（２２０）から除去し、購入履歴モジュール（２３０）内に拒否された取引の記録（６０２）を書き込む。承認フラグ（４１６（１））が「１」に等しい値にセットされる場合には、マスタ認可モジュール（３０４）が、検証要求フラグ（５１４（ｘ））を検索し、カード所有者（１０２（ｘ））が、選択的に検証プロセスを無効化したか否かを判定する。検証要求フラグ（５１４（ｘ））が「０」に等しい値にセットされている場合には、その後、マスタ検証モジュール（３０４）は、自動的に、検証フラグ（４１６）を「１」に等しい値にセットし、ＣＡＲＱ（２２０）内にＴＡＲ記録（４０２（１））を残す。検証要求フラグ（５１４（ｘ））が「０」に等しい値であるならば、その後、マスタ認可モジュール（３０４）は、ＴＡＲ記録（４０２（１））をＶＰＱ（２２８）に送信し、カード所有者（１０２（ｘ））による検証を待つ。

マスタ検証モジュール（３０４）は、更に、周期的にＶＰＱ（２２８）をスキャンし（例えば、ＣＡＲＱ（２２０）の各スキャンの後）、検証のためＶＰＱ（２２８）内に係属しているＴＡＲ記録（４０２）を処理する。特定の記録（４０２）の検証フラグ（４１４）が、「１」に等しい値にセットされる場合には、記録（４０２）に対応するＴＡＲが、カード所有者（１０２（ｘ））により検証されたことを示す。ＴＡＲ記録（４０２（１））がＶＰＱ（２２８）内でスキャンされた最初の時、検証フラグ（４１４（１））及び検証着手フラグ（４１５（１））は、ともに「０」に等しい値にセットされているべきである。
マスタ検証モジュール（３０４）はその後、カード所有者リスト（２２２）から記録（５０２（ｘ））を検索し、サーバ（２００）が検証プロセスを開始すべきか否か（例えば、Ｅメールをユーザ（１０２（ｘ））に送信すること、ポケットベルでユーザ（１０２（ｘ））を呼び出すこと、ユーザ（１０２（ｘ））に電話をかけるなど）を決定する。或いは、サーバ（２００）が、ユーザ（１０２（ｘ））が検証を開始するのを待つべきか否かを決定する。
着手検証フラグ（５１６（ｘ））が、「０」に等しい値にセットされている場合には、その後、マスタ検証モジュールは、検証着手フラグ（４１５（１））を「１」に等しい値にセットする。サーバ（２００）が検証プロセスを開始しなかった場合であっても、検証着手フラグを「１」に等しい値にセットすることは、マスタ検証モジュール（３０４）により、ＶＰＱ（２２８）がスキャンされるたびに、検証要求フラグ（５１６（ｘ））がチェックされる必要性を取り除くことに寄与することとなる。

ＶＰＱ（２２８）内における記録（４０２（１））の最初のスキャンの間、マスタ検証モジュール（３０４）は、着手検証フラグ（５１６（ｘ））が「１」に等しい値にセットされたことを判定し、その後、マスタ検証モジュール（３０４）は、相互検証モジュール（３０６）を呼び出し、カード所有者（１０２（ｘ））とともに検証プロセスを開始する。
相互検証モジュール（３０６）は、その後、検証プロセスを開始し、検証着手フラグ（４１５（１））を「１」に等しい値にセットし、その後、制御を検証モジュール（３０４）に返す。検証モジュール（３０４）は、処理のためにＶＰＱ（２２８）内で次の記録（４０２）を検索する。

マスタ検証モジュール（３０４）は、更に、周期的に相互検証モジュール（３０６）を呼び出し、ＶＰＱ（２２８）内に係属しているＴＡＲの実際の検証を実行する。係属中のＴＡＲの検証は、カード所有者（１０２（ｘ））との接続を確立することによりなされる。カード所有者（１０２（ｘ））との接続は、ＴＡＲが元々受信された商事業者（１０４）との接続とは別個独立のものであり、このことは、従来技術に係る電子取引（例えば、ＡＴＭカード購入など）と比較して、追加的な安全性をもたらす結果となる。
本明細書中で用いられる、「接続を確立する」との用語は、可能な限り広く解釈されるべきものであり、限定するものではないが、ネットワーク接続を確立すること、モデムを介したデータ接続を確立すること、通信機器を介した音声接続を確立すること、Ｅメールを送受信することなどを意味するものである。
このようにして、カード所有者（１０２）は、インターネットワーク（１１０）を介して、サーバ（２００）にログオンすることにより、係属中の取引承認要求を検証することが可能となる。また、カード所有者（１０２）は、ネットワーク（１１４）を介して、サーバ（２００）にモデムを用いて直接的に接続することが可能となる。また、カード所有者（１０２）は、電話を介して、サーバ（２００）にダイアルすることが可能となる。更には、カード所有者（１０２）は、サーバ（２００）にＥメールを送信することやサーバ（２００）からのＥメールに応答することが可能となる。或いは、カード所有者（１０２）は、他の形態の電子通信を実行することが可能となる。

変更形態において、システム（２００）が変更され、口座所有者が、予めある程度の課金を承認可能となるようにしてもよい。例えば、カード所有者リスト（２２２）が、予め承認された商事業者（或いは、他の望ましい判断基準）用のフィールドを備えるようにしてもよい。その後、取引承認要求が処理されると、認可モジュール（２２６）は、商事業者識別子を関連するカード所有者の予め承認された商事業者リストと対比し、商事業者がリスト上に現れるならば、自動的にＴＡＲを検証する。カード所有者（１０２）は、システム（２００）にアクセス可能であり、インターネットワーク（１１０）、ネットワーク（１１４）、或いは、顧客データを更新するための既知の他の手段を介して、このような予め承認されたリストを変更可能である。

図１乃至図３に示す本発明の特定の実施形態において、相互検証モジュール（３０６）は、カード所有者通信モジュール（２２４）、ネットワークインターフェイス（２０４）、通信機器（２１４）を介して、カード所有者（１０２）と通信する。
カード所有者通信モジュール（２２４）は定期的にネットワークインターフェイス（２０４）及び通信機器（２１４）を確認し、新たになされた接続要求（例えば、Ｅメール、ネットワーク接続、電話受信など）の有無を確認し、このような接続を確立する。このような通信プログラム（例えば、Ｅメールソフトウェア、ネットワークプロトコルなど）は、本技術分野においては当業者に周知のものであり、本発明を不必要に不明瞭とする可能性があるため、本明細書においては詳述しない。

相互検証モジュール（３０６）は、カード所有者通信モジュール（２２４）を確認し、カード所有者（１０２）との確立された接続が存在するか否かを判定し、各確立された接続の処理を行う。カード所有者（１０２（ｘ））がサーバ（２００）との接続を確立したことを仮定すると、係属中のＴＡＲの検証は、以下のようにして執り行われる。
接続要求が、カード所有者（１０２（ｘ））を識別する（例えば、クレジットカード番号によって）。そして、必要に応じて、接続要求は、認証コード（例えば、個人識別番号（PIN: personal identification number））を備え、カード所有者を認証する。相互検証モジュール（３０６）は、接続要求中の識別情報を用いて、カード所有者リスト（２２２）からカード所有者（１０２（ｘ））に対応する記録（５０２（ｘ））を検索する。その後、相互検証モジュール（３０６）は、接続要求内で提供されたＰＩＮとＰＩＮ（５０６（ｘ））を比較し、カード所有者を認証する。もし、ＰＩＮが一致しない場合、接続は終了する。ＰＩＮが一致する場合、検証プロセスが引き続き行なわれる。

不適切なＰＩＮが受信された最初のときに、カード所有者（１０２（ｘ））との接続が終了する必要はないことは理解されるべきことである。例えば、従来のネットワークセキュリティシステムは、典型的には、ユーザとの接続を打ち切る前に、所定回数の不適切な入力（エントリ）を許容する。他の形態においては、接続先の追跡を開始する間、システムにアクセスしようとするユーザを引き止めるような安全性確保のための手段が採用される。

続いて、相互検証モジュール（３０６）は、カード所有者（１０２（ｘ））のクレジットカード番号（５０４（ｘ））に一致するクレジットカード番号（４０２）を備える全てのＴＡＲに対する検証係属キュー（２２８）をスキャンする。合致するＴＡＲそれぞれは、検証する或いは無効化するカード所有者（１０２（ｘ））に表示される。カード所有者（１０２（ｘ））が、特定の取引を検証する場合には、その後、相互検証モジュール（３０６）がＴＡＲ記録の検証フラグ（４１４）を「１」に等しい値にセットする。カード所有者（１０２（ｘ））が、取引を無効化する場合（例えば、購入が認可されたものでないため）、その後、相互検証モジュール（３０６）は、ＴＡＲ記録の拒否フラグ（４１８）を「１」に等しい値にセットする。

係属中のＴＡＲをカード所有者（１０２（ｘ））に表示し、カード所有者（１０２（ｘ））から検証指示を受信することを可能とする方法は多数存在する。これら方法は、サーバ（２００）に対する接続の種類によって定まるものである。例えば、カード所有者（１０２）がサーバ（２００）とＨＴＴＰ接続をする場合においては、係属中のＴＡＲは、インターネットウェブページの形式で表示される。他の形態として、カード所有者（１０２（ｘ））とサーバ（２００）間の接続が、電話音声接続によるものであるならば、係属中のＴＡＲは、自動音声システムを介して、カード所有者（１０２（ｘ））に提示される。これらの手法は、本技術分野において当業者によく知られたものである。
カード所有者（１０２（ｘ））は、音声或いはキーパッド入力（コマンド）（例えば、ボタン１を押し、検証をおこなうこと或いはボタン２を押して無効化すること）を介して、検証指示を送信する。更に他の実施形態において、接続要求がＥメール応答の形式である場合には、Ｅメール応答は、相互検証モジュール（３０６）により自動的に処理される検証指示（例えば、Ｅメールの件名タイトル内で）を備えることができる。ＴＡＲを検証するための上記種類の接続は、本発明の新規な特徴として捉えることも可能である一方で、本発明の必要不可欠な発明特定事項として如何なる種類の接続も捉えられるべきものではない。

相互検証モジュール（３０６）が接続要求を処理した後、制御がマスタ検証モジュール（３０４）へ戻される。マスタ検証モジュール（３０４）は、ＶＰＱ（２２８）をスキャンし、ＴＡＲ記録を送信する。このＴＡＲ記録の検証フラグ（４１４）或いは拒否フラグ（４１８）は「１」に等しい値にセットされている。
更に、マスタ検証モジュール（３０４）は、ＶＰＱ（２２８）内に存する全ての記録（４０２）をスキャンし、購入日時フィールド（４１２）内の値をシステムクロック（２１２）により与えられる日時と比較する。結果として生ずる時間差が、所定の時間間隔（例えば、２４時間）を越える場合には、その後、マスタ検証モジュール（３０４）は、関連する記録（４０２）の拒否フラグ（４１８）を「１」に等しい値にセットし、記録（４０２）をＣＡＲＱ（２２０）に送信する。

ＣＡＲＱ（２２０）の次のスキャンの間、マスタ検証モジュール（３０４）は、検証フラグ（４１４）及び承認フラグ（４１６）がともに「１」に等しい値にセットされたＴＡＲ記録を探し、商事業者応答モジュールを呼び出し、記録のフィールド（４１０）内において識別された商事業者に承認を送信し、ＣＡＲＱ（２２０）から記録を除去するとともに購入履歴データ（２３０）に記録（６０２）を書き込み、完了した取引を文書化する。拒否フラグ（４１８）が「１」に等しい値にセットされた記録は、同様に取扱われるが、拒否が、承認の代わりに識別された商事業者に送信される点で異なる。

図７は、本発明に係るＴＡＲを処理する方法（７００）をまとめたフローチャートである。
第１の段階（７０２）において、商事業者通信モジュール（２３２）は、全クレジット番号を備えるＴＡＲを商事業者（１０４）から受信し、ＴＡＲ記録（４０２）を作成するとともに、ＴＡＲ記録（４０２）をＣＡＲＱ（２２０）内に書き込む。
第２の段階（７０４）において、認可モジュール（２２６）により、ＴＡＲ記録（４０２）に対して従来型のクレジット承認プロセスを適用し、承認フラグ（４１６）又は拒否フラグ（４１８）をセットして、要求されたクレジットが承認されたか拒否されたかを示す。
第３の段階（７０６）において、認可モジュール（２２６）が、フラグ（４１６，４１８）に基づき、要求されたクレジットが承認されたか拒否されたかを判定する。第３の段階において、認可モジュール（２２６）が要求されたクレジットが承認されたことを判定するならば、第４の段階（７０８）において、認可モジュール（２２６）は、カード所有者（１０２）が選択的に検証プロセスを無効化したか否かを判定する。検証プロセスが選択的に無効化されていない場合には、第５の段階（７１０）において、認可モジュール（２２６）はカード所有者（１０２）と取引を検証する。その後、第６の段階（７１２）において、検証モジュール（２２６）は、ＴＡＲがカード所有者（１０２）により検証されたか否かを決定する。ＴＡＲが検証された場合には、第７の段階（７１４）において、商事業者通信モジュール（２３２）が取引承認を商事業者（１０４）に送信する。続いて、第８の段階（７１６）において、認可モジュール（２２６）は、更なるＴＡＲ記録がＣＡＲＱ（２２０）内に存在するか否かを判定する。ＣＡＲＱ（２２０）内にそれ以上の記録が存在しない場合には、方法（７００）は終了する。

第３の段階（７０６）において、認可モジュール（２２６）が、クレジット要求が拒否されたことを判定する場合には、その後、方法（７００）は、第９の段階（７１８）に進む。第９の段階（７１８）において、商事業者通信モジュール（２３２）は、拒否を商事業者（１０４）に送信する。
第４の段階（７０８）において、認可モジュール（２２６）が、検証プロセスが選択的に無効化されたことを判定する場合には、その後、方法（７００）は、第７の段階（７１４）に進む。第７の段階（７１４）において、商事業者通信モジュール（２３２）は、承認を商事業者（１０４）に送信する。
第６の段階（７１２）において、認可モジュール（２２６）が、ＴＡＲがカード所有者（１０２）により検証されなかったことを判定すると、方法（７００）は第９の段階（７１８）に進む。第９の段階（７１８）において、商事業者通信モジュール（２３２）は拒否を商事業者（１０４）に送信する。
最後に、第８の段階（７１６）において、認可モジュール（２２６）が、更なる係属中のＴＡＲ記録がＣＡＲＱ（２２０）内に存在することを判定すると、方法（７００）は第１の段階（７０２）に戻り、ＣＡＲＱ（２２０）内の次の記録を処理する。

図８は、本発明の特定の実施形態にしたがうＴＡＲ検証プロセスを選択的に無効化することを実行する方法（８００）をまとめたフローチャートである。
第１の段階（８０２）において、認可モジュール（２２６）は、ＣＡＲＱ（２２０）が空の状態であるか否かを判定する。ＣＡＲＱ（２２０）が空の状態でない場合には、その後、第２の段階（８０４）において、認可モジュール（２２６）がＣＡＲＱ（２２０）内の第１のＴＡＲ記録を読み取る。
その後、第３の段階（８０６）において、認可モジュール（２２６）は第１のＴＡＲとカード所有者（１０２）を関連付け、カード所有者リスト（２２２）から特定のカード所有者に対応するカード所有者記録（５０２）を検索する。
第４の段階（８０８）において、商事業者（１０４）へ承認を送信する前に、ＴＡＲがカード所有者（１０２）と検証されることを、カード所有者（１０２）が要求したか否かについて、認可モジュール（２２６）は、カード所有者記録（５０２）に基づき判定する。カード所有者検証が要求されると判定される（即ち、実行可能となる）ならば、その後、第５の段階（８１０）において、認可モジュール（２２６）が関連するＴＡＲ記録をＶＰＱ（２２８）に送信する。
続いて、第６の段階（８１２）において、認可モジュール（２２６）が、ＣＡＲＱ（２２０）内の最後の記録が処理されたか否かを判定し、処理されている場合には、方法（８００）は終了する。

第４の段階（８０８）において、認可モジュール（２２６）が、検証が要求されていない（即ち、無効化された状態である）ことを判定するならば、第７の段階（８１４）において、検証フラグ（４１４）が自動的に「１」に等しい値にセットされ、ＴＡＲが検証されたことを指し示す。第６の段階（８１２）において、認可モジュール（２２６）が、ＣＡＲＱ（２２０）内の最後の記録が処理されていないと判定するならば、その後、方法（８００）は第２の段階（８０４）に戻り、ＣＡＲＱ（２２０）内の次の記録の処理を開始する。

図９は、本発明にしたがうＴＡＲを検証する特定の方法（９００）をまとめたフローチャートである。
第１の段階（９０２）において、認可モジュール（２２６）は、ＶＰＱ（２２８）が空の状態であるか否かを判定する。ＶＰＱ（２２８）が空の状態でない場合には、第２の段階（９０４）において、認可モジュール（２２６）が、ＶＰＱ（２２８）内の第１のＴＡＲ記録（４０２）を読み取る。
第３の段階（９０６）において、認可モジュール（２２６）は、ＴＡＲ記録（４０２）が前もって、拒否されたか否か（例えば、拒否フラグ（４１８）＝１であるか否か）を判定する。ＴＡＲ記録（４０２）が前もって拒否されていない状態にある場合には、その後、第４の段階（９０８）において、認可モジュール（２２６）は、現状のＴＡＲが前もって検証されたか否か（例えば、検証フラグ（４１４）＝１であるか否か）を判定する。ＴＡＲが未だ検証されていない場合には、その後、第５の段階（９１０）において、認可モジュール（２２６）が、検証プロセスが既にサーバ（２００）により開始されたか否か（例えば、検証着手フラグ（４１５）＝１であるか否か）を判定する。検証着手フラグ（４１５）が「１」に等しい値である場合には、第６の段階（９１２）において、認可モジュール（２２６）が、現状のＴＡＲがサーバ（２００）により受信されてから、所定の期間が経過しているか否かを判定する（例えば、購入日時（４１２）を読取り、システムクロック（２１２）と比較する）。
所定の期間が経過している場合には、第７の段階（９１４）において、認可モジュール（２２６）は自動的にＴＡＲを無効化する（例えば、拒否フラグ＝１の状態にセットする）。そして、第８の段階（９１６）において、認可モジュール（２２６）は、ＴＡＲ記録をＣＡＲＱ（２２０）に送信する。
第９の段階（９１８）において、認可モジュール（２２６）は、ＶＰＱ（２２８）内の最後の記録が処理されたか否かを判定する。ＶＰＱ内の全ての記録が処理されているならば、第１０の段階（９２０）において、認可モジュール（２２６）は、ＶＰＱ（２２８）内に残存するＴＡＲ記録に対してカード所有者検証プロセスを実行する。

第１の段階（９０２）において、認可モジュール（２２６）が、ＶＰＱ（２２８）が空の状態であることを判定すると、方法（９００）は終了する。
第３の段階（９０６）において、認可モジュール（２２６）が、処理中のＴＡＲ記録が拒否されたことを判定すると、方法（９００）は、直接的に第８の段階（９１６）に進む。同様に、第４の段階（９０８）において、認可モジュール（２２６）が、処理中のＴＡＲ記録が前もって承認されたことを判定すると、方法（９００）は、第８の段階（９１６）に進む。

第５の段階（９１０）において、認可モジュール（９１６）が、検証着手フラグ（４１５）が「０」に等しい値であると判定すると、方法（９００）は、第１１の段階（９２２）へ進む。第１１の段階（９２２）において、認可モジュール（２２６）は更に、検証プロセスが認可モジュール（２２６）により着手されるべきか否かを判定する（例えば、着手検証フラグ（５１６）＝１とすべきか否か）。第１１の段階（９２２）において、認可モジュール（２２６）が、カード所有者（１０２）と検証プロセスを開始することを判定するならば、第１２の段階（９２４）において、サーバ（２００）が、カード所有者（１０２）との検証プロセスを開始する。そして、第１３の段階（９２６）において、着手検証フラグが「１」に等しい値にセットされる。
その後、方法（９００）は、第８の段階（９１６）に進む。第１１の段階（９２２）において、認可モジュール（２２６）が、着手検証フラグ（５１６）が「０」に等しい値であることを判定するならば、その後、方法（９００）は直接的に第１３の段階（９２６）へ進む。

第６の段階（９１２）において、認可モジュール（２２６）が、所定の時間間隔が経過したことを判定する場合には、方法（９００）は、第８の段階（９１６）に進む。第９の段階（９１８）において、認可モジュール（２２６）が、ＶＰＱ（２２８）内に更なるＴＡＲ記録が存在することを判定する場合には、方法（９００）は、第２の段階（９０４）に戻り、次のＴＡＲ記録を処理する。

図１０は、カード所有者（１０２）と係属中のＴＡＲの検証を行なう方法（１０００）をまとめたフローチャートである。
第１の段階（１００２）において、カード所有者通信モジュール（２２４）が、ネットワークインターフェイス（２０４）と通信機器（２１４）を確認し、カード所有者からのカード所有者通信要求（例えば、電話受信、ネットワーク接続要求など）の有無を判定する。カード所有者通信要求が存する場合には、第２の段階（１００４）において、認可モジュール（２２６）が相互検証モジュール（３０６）を呼び出し、カード所有者（１０２）との接続を確立する。
第３の段階（１００６）において、相互検証モジュール（３０６）は、カード所有者（１０２）を認証する（例えば、認証コードを要求する）。そして、第４の段階（１００８）において、相互検証モジュール（３０６）は、ＶＰＱ（２２８）を検索し、カード所有者（１０２）に関連する記録を探し出す。
その後、第５の段階（１０１０）において、相互検証モジュール（３０６）は、係属中のＴＡＲの少なくとも一部（カード所有者が認識するのに十分な程度に）をカード所有者（１０２）に表示する。続いて、第６の段階（１０１２）において、相互検証モジュールは、確立された接続を確認し、カード所有者（１０２）が指示を送信し、表示されたＴＡＲを検証するか否かを判定する。カード所有者（１０２）からのＴＡＲを検証することに対する指示が存在しない場合には、第７の段階（１０１４）において、相互検証モジュール（３０６）が、カード所有者が、ＴＡＲを無効化する指示を送信したか否かを判定する。ＴＡＲを無効化する指示が存在しない場合には、その後、第８の段階（１０１６）において、相互検証モジュール（３０６）は、カード所有者（１０２）に関連する最新の係属中ＴＡＲが処理されたか否かを判定する。最新の継続中ＴＡＲが処理されている場合には、第９の段階において、相互検証モジュール（３０６）は、カード所有者（１０２）との確立された接続を終了し、方法（１０００）は段階（１００２）に戻り、他のカード所有者からの通信要求が存在するか否かを判定する。
第１の段階（１００２）において、カード所有者通信モジュール（２２４）が、カード所有者通信要求が存在しないことを判定するならば、方法（１０００）は終了する。

第６の段階において、相互検証モジュール（３０６）が、カード所有者（１０２）が提示されたＴＡＲを検証することの指示を受信すると、第１０の段階（１０２０）において、相互検証モジュール（３０６）は、ＴＡＲ記録（４０２）の検証フラグ（４１４）を「１」の値にセットする。これにより、ＴＡＲが検証されたことが示されることとなる。
その後、方法（１０００）は第５の段階（１０１０）に戻る。同様に、第７の段階（１０１４）において、相互検証モジュール（３０６）が、カード所有者（１０２）が提示されたＴＡＲを無効化する指示を受信すると、その後、第１１の段階（１０２２）において、相互検証モジュール（３０６）が、ＴＡＲ記録（４０２）の拒否フラグ（４１８）を「１」の値にセットする。このことは、ＴＡＲが無効化されたことを示す。その後、方法（１０００）は、第５の段階（１０１０）に戻る。

第８の段階（１０１６）において、相互検証モジュール（３０６）が、特定のカード所有者に対する最新の継続中要求が処理されていないことを判定する場合には、方法（１０００）は、第５の段階（１０１０）に戻り、特定のカード所有者に対する次の係属中ＴＡＲを処理する。

図１１は、変更形態に係るサーバ（２００Ａ）のブロック線図である。
サーバ（２００Ａ）は、図２に示すサーバ（２００）と同様であるが、サーバ（２００Ａ）が事前検証基準（PVC: pre-verification criteria）（１１２）及び変更形態に係る認可モジュール（２２６Ａ）を備える点で異なる。
認可モジュール（２２６Ａ）は、検証モジュール（２２６）により実行される機能に加えて、ＴＡＲの承認及び検証を制御するとともに調整する。認可モジュール（２２６Ａ）は、事前検証基準（１１０２）の要件に合致するＴＡＲを自動的に検証する。事前検証基準（１１０２）の使用は、ＴＡＲの検証の加速を促す。なぜなら、認可モジュール（２２６Ａ）は、カード所有者（１０２）による直接的な検証を待つ必要がないためである。

事前検証基準（１１０２）は、データベースであり、このデータベースは、クレジットカード会社（１０６）の現状の顧客それぞれに対する個別の事前検証基準を備え、カード所有者もこのデータベースに含まれている。事前検証基準（１１０２）は、典型的には（本発明を限定するものではないが）、商事業者識別子、最大購入金額及び認可モジュール（２２６Ａ）により自動的に検証されることが可能な購入日間の特定の日数を備える。事前検証基準（１１０２）は、典型的には非常に大きなファイルとなる。したがって、事前検証基準モジュール（１１０２）がメモリ（２１６）内で示されている間、顧客ファイル全体は、大規模データ格納システム（例えば、不揮発性メモリ（２０８））内に格納される。そして、必要に応じて、全リストの一部が、事前検証基準モジュール（１１０２）内外へスワップ（出し入れ）される。

最初に、事前検証基準が、クレジットカード会社（１０６）により決定される。これは、クレジットカード口座が開かれたときに行なわれる。したがって、この時点で、事前検証基準により検証される購入は存在しない。
言い換えると、各口座に対する事前検証基準の最初のデフォルト値は、いかなるＴＡＲも事前検証基準を満たさないように設定される（例えば、最大購入金額＝０と設定される）。他の形態として、事前検証基準が、口座が開かれたときに、カード所有者（１０２）により決定されてもよい（例えば、カード所有者がクレジットカードを申し込むときに）。いずれの場合も、カード所有者（１０２）は、安全性を確保されたネットワーク上（例えば、電話やモデムによるアクセスなど）でカード所有者の事前検証基準を変更することができる。このことは、下記において説明される。

図１２は、認可モジュール（２２６Ａ）のブロック線図であり、認可モジュール（２２６Ａ）は、クレジット承認モジュール（３０２）、変更形態に係るマスタ検証モジュール（３０４Ａ）、相互検証モジュール（３０６）及び商事業者応答モジュール（３０８）を備える。クレジット承認モジュール（３０２）は、ＣＡＲＱ（２２０）内に含まれるＴＡＲそれぞれに対して従来型のクレジット承認を実行する。この承認手法は、本技術分野においては周知のものである。
マスタ検証モジュール（３０４Ａ）は、認可及び検証プロセスを調整し、この検証プロセスには、事前検証基準を用いた検証も含まれる。また、マスタ検証モジュール（３０４Ａ）は、認可モジュール（２２６Ａ）の全体的な制御を担う。
相互検証モジュール（３０６Ａ）は、カード所有者（１０２）との検証を実行し、カード所有者（１０２）による事前検証基準の変更を調整補助する。商事業者応答モジュール（３０８）は、商事業者（１０４）との最終的な通信を開始し、この通信は、取引承認又は取引拒否のいずれかを送信することにより行なわれる。

図１３は、事前検証基準のデータ構造（１３００）の一例を示す。このデータ構造（１３００）は、本発明の特定の実施形態に好適に利用可能である。本技術分野の当業者であれば、データ構造（１３００）は、記録（１３０２（１−ｎ））の連結されたリストとして認識することが可能である。記録（１３０２（１−ｎ））それぞれは、特定のカード所有者に関連する事前検証基準を表し、記録（１３０２（１−ｎ））それぞれは、全クレジットカード番号（１３０４）、第１の商事業者識別子（１３０６（１））、ｒ番目の商事業者識別子（１３０６（ｒ））、最大事前検証購入金額（１３０６（１））、１組の事前検証日（１３１２）、その他雑多な事前検証基準（１３１４）及びポインタ（１３１６）を備える。
全クレジットカード番号（１３０４）は、事前検証基準記録（１３０２（ａ））を特定のカード所有者（１０２（ａ））に関連付ける。商事業者識別子（１３０６（１−ｒ））それぞれは、各ＴＡＲ内に含まれる商事業者情報（４１０）と同様の情報を含む。商事業者識別子（１３０６（１−ｒ））それぞれは、カード所有者それぞれに対する特定の事前検証された商事業者を識別する。事前に検証された商事業者から受信されたＴＡＲは、自動的に認可モジュール（２２６Ａ）により検証される。事前検証購入金額（１３１０）は、自動検証に対する最大購入金額を設定する。事前検証購入金額（１３１０）を下回る購入金額を含むＴＡＲは、自動的に認可モジュール（２２６Ａ）により検証される。事前検証日（１３１２）は、開始日及び終了日を含む。事前検証日の開始日と終了日の間に存する購入日（４１２）を含むＴＡＲは、認可モジュール（２２６Ａ）により自動的に検証される。
その他雑多な事前検証基準（１３１４）は、上記に挙げられた特定の基準以外の特定の基準を現わすものであり、この雑多な事前検証基準（１３１４）によっても、認可モジュール（２２６Ａ）は、ＴＡＲを検証することとなる。例えば、購入が自動的に検証される日の特定の時間を特定することを欲することが可能となる。このような場合、雑多な事前検証基準（１３１４）は、開始時間と停止時間を含む。ポインタ（１３１６（ａ））は、リスト中の次の記録（１３１６（ａ＋１））のメモリアドレスを指し示す。最後の記録（１３０２（ｎ））は、リスト終端値（１３１８）を備え、この終端値は、記録（１３０２（ｎ））がリスト中最後の記録であることを指し示す。

図１４は、本発明の特定の実施形態に関し、事前検証基準を用いたＴＡＲの自動検証を実行するための一つの方法（８００Ａ）の概要を示すフローチャート図である。第１段階（８０２）において、認可モジュール（２２６Ａ）はＣＡＲＱ（２２０）が空であるか否かを決定する。ＣＡＲＱが空であるとき、方法（８００Ａ）は終了する。ＣＡＲＱ（２２０）が空ではないときは、第２段階において、認可モジュール（２２６Ａ）は、ＣＡＲＱ（２２０）の第１ＴＡＲ記録を読み取る。それから第３段階（８０６）で、認可モジュール（２２６Ａ）はカード所有者（１０２）と第１ＴＡＲを関連付けて、カード所有者リスト（２２２）から特定のカード所有者と一致するカード所有者記録（５０２）を検索する。第４段階において、認可モジュール（２２６Ａ）は、商事業者（１０４）へ承認を送信する前にカード所有者（１０２）が、カード所有者（１０２）によりＴＡＲが検証されることを要求したかどうかを決定し、これはカード所有者記録（５０２）から行われる。カード所有者の検証が要求された（すなわち有効である）場合、第５段階において、認可モジュール（２２６Ａ）は、カード所有者（１０２）に関連する事前検証基準を満たしているかどうか決定する。第４段階の（８０９）において、事前検証要件を満たしていない場合、第６段階（８１０）において、認可モジュール（２２６Ａ）は、関連するＴＡＲ記録をＶＰＱ（２２８）へ転送する。次に、第７段階（８１２）において、認可モジュール（２２６Ａ）は、ＣＡＲＱ（２２０）の最後の記録が処理されたかどうか決定する。処理されていれば、方法（８００Ａ）は終了する。

第４段階（８０８）において、認可モジュール（２２６Ａ）が、検証は要求されなかった（即ち、無効となった）と決定した時は、方法（８００Ａ）は第８段階（８１４）へ進む。そこで、認可モジュール（２２６Ａ）は検証フラグ（４１４）を１に設定し、ＴＡＲが検証されたことを示す。同様に、第５段階（８０９）において、認可モジュール（２２６Ａ）が事前検証基準を満たしていると決定した場合は、方法（８００Ａ）は第８段階（８１４）へ進み、そこで認可モジュール（２２６Ａ）は検証フラグ（４１４）を１に設定する。第７段階（８１２）において認可モジュール（２２６Ａ）がＣＡＲＱ（２２０）の最後の記録が処理されていないと決定したときは、方法（８００Ａ）は第２段階（８０４）へ戻り、ＣＡＲＱ（２２０）の次の記録を処理し始める。

図１５は、図１４の方法の（事前検証基準は満たされたかどうか決定する）第５段階（８０９）を実行する方法（１５００）の概要を示すフローチャート図である。第１段階（１５０２）において、認可モジュール（２２６Ａ）は、ＴＡＲで特定されるカード所有者（例えば、カード所有者（１０２）（ａ））と関連する事前検証基準（１１０２）の記録（１３０２）（ａ）を検索する。第２段階（１５０４）において、認可モジュール（２２６Ａ）は、記録（１３０２）（ａ）の商事業者識別子（１３０６（ａ）（１−ｒ））の一つがＴＡＲに含まれる商事業者情報（４１０）と一致するか否かを決定する。もし、記録（１３０２）（ａ）のいずれの商事業者（１３０６（ａ）（１−ｒ））とも一致しなかったとき、第３段階（１５０６）において、認可モジュール（２２６Ａ）は、ＴＡＲの購入価格（４０８）が最大事前検証購入価格（１３１０（ａ））より低いかどうか決定する。ＴＡＲの購入価格（４０８）が最大事前検証購入価格（１３１０（ａ））より低くない場合は、第４段階（１５０８）において、認可モジュール（２２６Ａ）はＴＡＲの購入日（４１２）が事前検証日（１３１２（ａ））の範囲内であるか否かを決定する。購入日（４１２）が事前検証日（１３１２（ａ））で特定された日の範囲外である場合、第５段階（１５１０）において、認可モジュール（２２６Ａ）は、雑多の事前検証基準（１３１４（ａ））が満たされるか否かを決定する。雑多の事前検証基準（１３１４）が満たされない場合、或いはカード所有者が雑多の基準（１３１４）をなんら特定しない場合、方法（１５００）は事前検証基準が満たされていないと決定する。

第２段階（１５０４）において、認可モジュール（２２６Ａ）が、記録（１３０２（ａ））の商事業者識別子（１３０６（１−ｒ））の一つが、ＴＡＲに含まれる商事業者情報（４１０）と一致すると決定したとき、方法（１５００）は事前検証基準が満たされたと決定する。第３段階（１５０６）において、認可モジュール（２２６Ａ）が、購入価格（４０８）が事前検証購入価格（１３１０（ａ））より下であると決定したとき、方法（１５００）は事前検証基準が満たされたと決定する。同様に、第４段階（１５０８）において、認可モジュール（２２６Ａ）が、ＴＡＲの購入日（４１２）が事前検証購入日（１３１２（ａ））の範囲内であると決定すると、方法（１５００）は、事前検証基準が満たされたと決定する。最後に、第５段階（１５１０）において、認可モジュール（２２６Ａ）が、雑多の事前検証基準（１３１４（ａ））が係属中のＴＡＲにより満たされたと決定したとき、方法（１５００）は、事前検証基準が満たされたと判断する。もし、さまざまな基準のうちいずれか（例えば、最大購入価格）を満たせば、方法（１５００）が、特定のＴＡＲが事前検証基準を満たすと決定し、自動的に検証されることはいうまでもない。

図１５Ａは、図１４の方法の段階（８０９）を実行するための他の方法（１５００Ａ）の概要を示すフローチャート図である。この図によると、事前検証基準のすべてが、ＴＡＲが自動的に検証される前に満たされなければならない。第１段階（１５０２）において、認可モジュール（２２６Ａ）は、事前検証基準１（１０２）の記録（１３０２）（ａ）を検索する。前記事前検証基準（１１０２）は、認可モジュール（２２６Ａ）により処理されているＴＡＲにおいて特定されるカード所有者（例えば、カード所有者（１０２（ａ）））に関連するものである。第２段階（１５０４Ａ）において、認可モジュール（２２６Ａ）は記録（１３０２（ａ））の商事業者識別子（１３０６（１−ｒ））の一つがＴＡＲに含まれる商事業者情報（４１０）と一致するか否かを決定する。記録（１３０２（ａ））の商事業者識別子（１３０６（１−ｒ））が商事業者を特定できない場合、方法（１５００Ａ）は、係属中のＴＡＲにより事前検証基準が満たされないと決定する。そして方法（１５００Ａ）は終了する。しかしながら、記録（１３０２（ａ））の商事業者識別子（１３０６（１−ｒ））のうちの一つでもＴＡＲで特定される商事業者と一致したときは、方法（１５００Ａ）は第３段階（１５０６Ａ）へ進む。そこで認可モジュール（２２６Ａ）はＴＡＲの購入価格（４０８）が最大事前検証購入価格（１３１０（ａ））より下であるか否かを決定する。ＴＡＲの購入価格（４０８）が最大事前検証購入価格（１３１０（ａ））より下ではない場合、方法（１５００Ａ）は事前検証基準が満たされないと決定し、該方法は終了する。ＴＡＲの購入価格（４０８）が最大事前検証購入価格（１３１０（ａ））より下である場合、第４段階（１５０８Ａ）において、認可モジュール（２２６Ａ）は、ＴＡＲの購入日（４１２）が事前検証日（１３１２（ａ））の範囲内であるか否かを決定する。購入日（４１２）が事前検証日（１３１２（ａ））で特定された日の範囲内ではない場合、方法（１５００Ａ）は、事前検証基準が満たされないと決定し、該方法は終了する。購入日（４１２）が事前検証日（１３１２（ａ））において特定される日の範囲内である場合、第５段階（１５１０Ａ）において、認可モジュール（２２６Ａ）は、雑多の事前検証基準（１３１４（ａ））が満たされているか否かを決定する。雑多の事前検証基準（１３１４（ａ））が満たされない場合、或いはカード所有者が雑多の事前検証基準（１３１４（ａ））を特定していない場合は、方法（１５００）は、事前検証基準が満たされないと決定し、該方法は終了する。しかしながら、雑多の事前検証基準（１３１４（ａ））が満たされて、方法（１５００）が事前検証基準は満たされたと決定したときは、係属中のＴＡＲは自動的に検証される。

図１６は、カード所有者（１０２）が関連する事前検証基準（１３０２）を修正する一つの方法（１６００）の概要を示すフローチャート図である。相互検証モジュール（３０６Ａ）は、相互検証モジュール（３０６）と同様の機能を示すが、さらに機能して、事前検証基準記録（１３０２（１−ｎ））の修正を調整し制御する。第１段階（１６０２）において、カード所有者通信モジュール（２２４）は、カード所有者からのカード所有者通信要求（例えば、電話呼び出し、ネットワーク接続要求等）が存するか否かを決定する。これは、ネットワークインターフェイス（２０４）及び通信機器（２１４）を用いて行われる。もしカード所有者通信要求が存すれば、第２段階（１６０４）において、相互検証モジュール（３０６Ａ）はカード所有者（１０２）との接続を確立する。第３段階（１６０６）において、相互検証モジュールはカード所有者（１０２）を認証する（例えば、認証コードを要求して）。そして第４段階（１６０８）において、相互検証モジュール（３０６Ａ）はカード所有者（１０２）と関連する事前検証基準（１３０２）を検索する。第５段階（１６１０）において、相互検証モジュール（３０６Ａ）は、カード所有者（１０２）が事前検証基準（１３０２）の修正を希望するか否かを決定する（例えば事前に記録されたメニューに対してプッシュ式の反応を受信する）。相互検証モジュール（３０６Ａ）が、カード所有者（１０２）は事前検証基準（１３０２）の修正を希望していると決定すると、第６段階１６１２において、相互検証モジュール（３０６Ａ）は、最初の事前検証基準（例えば、商事業者識別子（１３０６（１）（１））をカード所有者（１０２）に提示する。次に、第７段階（１６１４）において、相互検証モジュール（３０６Ａ）は、カード所有者（１０２）が段階（１６１２）で提示された基準の修正を希望するか否かを決定する。カード所有者（１０２）が提示された事前検証基準（１３０２）の修正を希望しない場合は、第８段階（１６１６）において、相互検証モジュールは、カード所有者（１０２）が次の事前検証基準（例えば、商事業者識別子（１３０６（２））に進むことを希望するか否かを決定する。カード所有者（１０２）が事前検証基準の修正を続けることを希望しない場合は、相互検証モジュール（３０６Ａ）は、第９段階（１６１８）においてカード所有者（１０２）との接続を終わらせる。

第１段階（１６０２）において、カード所有者から通信要求がない場合は、方法（１６００）は終了する。段階（１６１０）において、カード所有者（１０２）が事前検証基準の修正を希望しない場合は、方法（１６００）は第９段階（１６１８）へと進む。この第９段階では、相互検証モジュール（３０６Ａ）がカード所有者との接続を終了させる。段階（１６１４）において、カード所有者（１０２）が提示された事前検証データの修正を希望すれば、相互検証モジュール（３０６Ａ）は第１０段階（１６２０）を開始する。この第１０段階において、カード所有者から新たなデータが受信されて、方法（１６００）が第８段階（１６１６）へ進む前に、提示された事前検証基準が新たなデータで上書きされる。第８段階（１６１６）において、カード所有者（１０２）から、事前検証基準（１３０２）のさらに他の修正の指示を受けたときは、方法（１６００）は段階（１６１０）に戻る。

図１７は、他の代替のサーバ（２００Ｂ）を示すブロック図である。サーバ（２００Ｂ）は図２のサーバ（２００）及び／または図１１のサーバ（２００Ａ）と類似した機能をもつが、サーバ（２００Ｂ）は活動可能データベース（１７０２）及び代替の認可モジュール（２２６Ｂ）を備える点で異なる。認可モジュール（２２６Ｂ）はＴＡＲの承認と検証を制御及び調整する。認可モジュール（２２６）及び（２２６Ａ）により実行される機能に加えて、認可モジュール（２２６Ｂ）はカード所有者（１０２）の口座の活動可能な状態を評価する。認可モジュール（２２６Ｂ）は、カード所有者（１０２）のクレジット口座が活動可能である／活動可能であった日時と対応する取引日時を含むようないかなるＴＡＲをも自動的に拒否する。クレジット口座の活動不可能な期間内の取引を含むすべてのＴＡＲを自動的に拒否することにより、不正使用者が、前記カード所有者のクレジット口座を用いて不正購入を首尾よく果たすことを減らすことができる。

活動可能データベース（１７０２）は、クレジットカード会社（１０６）の最新の消費者の活動可能データ／条件を含み、前記消費者にはカード所有者（１０２）も含まれる。活動可能条件には、口座を活動可能にするか、或いは活動不可能にするかのいずれかとなるようにカード所有者（１０２）により入力される特定の日及び／または時間、カード所有者が口座を活動可能にする又は活動不可能にした時の特定の日時、或いはカード所有者（１０２）によって定義された特定の他の活動可能及び活動不可能基準を含むがこれらに限定されない。例えば、カード所有者（１０２）は、クレジットカードが活動可能にされる期間をある時間帯に特定することができる。他の例としては、あらかじめ決められた取引承認要求の数（例えば、１）を越えると、カード所有者（１０２）のクレジットカードを自動的に活動不可能にさせることができる。口座が開かれる（例えば、申請書上で）とき、或いは口座が開かれた後のいずれかのときにおいて、カード所有者（１０２）はそのような基準を定義することきる。口座が開かれた後においては、カード所有者接続モジュール（２２４）を介してサーバ（２００Ｂ）と遠隔接続することにより、カード所有者（１０２）はそのような基準を定義することきる。

活動可能データベース（１７０２）は、概して、大容量のファイルである。それゆえ、活動可能データベース（１７０２）がメモリ２１６で示される間は、全消費者ファイルは、大抵、不揮発性メモリ（２０８）であるような大量データ格納システムに格納される。これは、活動可能データベース（１７０２）中及び外にスワップされている全データベースの一部を用いて行われる。

図１８は、認可モジュール（２２６Ｂ）のブロック図であり、この認可モジュール（２２６Ｂ）はクレジット承認モジュール（３０２）、代替のマスタ検証モジュール（３０４Ｂ）、相互検証モジュール（３０６）、商事業者応答モジュール（３０８）、及び相互活動可能モジュール（１８０２）を含む。クレジット承認モジュール（３０２）は、ＣＡＲＱ（２２０）に含まれる各ＴＡＲの従来のクレジット承認を実行する。これは、従来の方法で行われる。マスタ承認モジュール（３０４Ｂ）は認可及び承認処理を調整し、この調整には、口座の活動可能な状態を決定する段階を含む。また、マスタ承認モジュール（３０４Ｂ）は認可モジュール（２２６Ｂ）の全体の制御に関与する。相互検証モジュール（３０６）はカード所有者（１０２）との検証を実行する。商事業者応答モジュール（３０８）は、取引承認或いは取引拒否のいずれかを転送することにより商事業者（１０４）と通信する。相互活動可能モジュール（１８０２）は、カード所有者（１０２）に関連する口座の活動可能な状態の修正を調整する。カード所有者（１０２）との接続を確立し、カード所有者（１０２）を認証した後（例えば、カード所有者通信モジュール（２２４）を介して）、相互活動可能モジュール（１８０２）は機能して、カード所有者（１０２）の口座の最新の口座の活動可能な状態を表示し、カード所有者（１０２）からの修正指示を受信し、関連する口座の活動可能な状態を変更する。必要に応じて、相互活動可能モジュール（１８０２）は機能して、カード所有者（１０２）を相互検証モジュール（３０６）へ送る。認可モジュール（２２６Ｂ）もまた認可モジュール（２２６Ａ）の機能を含む場合、カード所有者（１０２）は、係属中のＴＡＲを検証できる、或いは事前検証基準を修正することができる。

図１９は、本発明の活動可能データベース（１７０２）で使用するのに適した活動可能データ構造（１９００）の一例を示す。活動可能データ構造（１９００）は、クレジットカード会社（１０６）の消費者口座（カード所有者（１０２）の口座を含む）に関連する活動可能記録（１９０２（１）−１９０２（ｎ））の連結リストを含む。各記録（１９０２（１−ｎ））は、口座識別子（例えば、クレジットカード番号）フィールド（１９０４）、及び活動可能及び活動不可能条件／入力の系列を含む。前記系列は、自動活動可能日時フィールド（１９０６）、自動活動不可能日時フィールド（１９０８）、最初の活動可能フィールド（１９１０（１））、最初の活動不可能フィールド（１９１２（１））、最後の活動可能フィールド（１９１０（ｒ））、最後の活動不可能フィールド（１９１２（ｒ））、及びポインターフィールド（１９１４）を含み、該ポインターフィールド（１９１４）は次の活動可能記録（１９０２）をポイントする。活動可能記録（１９０２（ｎ））は、ポインタ（１９１４）の代わりに、「リストの終わり」記録（１９１６）を含み、活動可能記録（１９０２（ｎ））が活動可能データベース（１７０２）の最後の活動可能記録であることが示される。

クレジットカード番号フィールド（１９０４）は、各活動可能記録（１９０２）のキーフィールドであり、クレジットカード会社（１０６）の特定の消費者（例えば、カード所有者（１０２）を含む）と関連する活動可能設定／入力を示すために使用される。自動活動可能及び活動不可能日時フィールド（１９０６）及び（１９０８）は、カード所有者（１０２）に関連する自動活動可能及び活動不可能データを格納する。例えば、カード所有者（１０２）が自動活動可能フィールド（１９０６）を設定して、毎朝８ａ．ｍ．に彼らのクレジットカードを自動的に活動可能にするようにすることができる。また、自動活動不可能フィールド（１９０８）を設定して、毎晩８ｐ．ｍ．に彼らのクレジットカードを自動的に活動不可能にすることができる。他の選択肢としては、カード所有者（１０２）が自動活動可能フィールド（１９０６）及び自動活動不可能フィールド（１９０８）を設定して、各月の平日の間、或いは週末の間、彼らのクレジットカードを自動的に活動不可能にすることができる。カード所有者（１０２）は、所望の自動「オン−オフ」スケジュールを立てることができる。活動可能日時フィールド（１９１０（ｘ）（１））は、クレジットカード所有者が始めにクレジットカードを活動可能にした日時を格納し、このフィールド（ｘ）でカード所有者（１０２）と関連する活動可能記録（１９０２（ｘ））を表示する（例えば、記録（１９０２（１）（１）））。活動不可能日時フィールド（１９１２（ｘ）（１））は、カード所有者（１０２）が選択的に彼らのクレジットカードを（取引が行われないようにするべく）活動不可能にした最初の日時を示す。（例えば、電話、安全なウェブサイト等により）追加の活動可能及び活動不可能フィールドは各記録（１９０２）に加えられることにより、カード所有者がクレジットカードを後に活動可能及び活動不可能にすることができる。最後の（即ち、最新の）活動可能記録（１９１０（ｘ）（ｒ））及び活動不可能記録（１９１２（ｘ）（ｒ））がカード所有者（１０２）の活動可能記録（１９０２（ｘ））に格納される。その後、ポインタ（１９１４（ｘ））により、次の活動可能記録（１９０２（ｘ＋１））がポイントされる。最終の活動可能記録（１９０２（ｎ））は、ポインタ（１９１４）の代わりに、「リストの終わり」のインディケータ（１９１６）を有し、これにより、活動可能記録（１９０２（ｎ））が活動可能データベース（１７０２）の最終の記録であることを示す。データ構造（１９００）は、リスト化して簡単に示されるが、データ構造（１９００）は、同様のデータフィールドをもつ記録を含む関連するデータベースを実行することができる。

マスタ検証モジュール（３０４Ｂ）は、各活動可能記録（１９０２）に格納された活動可能データを次のように用いる。一度、ＴＡＲが受信され、特定のカード所有者と関連付けられると、マスタ検証モジュール（３０４Ｂ）は、ＴＡＲに含まれる購入日時に基づいてカード所有者の口座の活動可能な状態を決定する。購入日時がカード所有者のクレジットカードが活動不可能にされる間の範囲内である場合、マスタ検証モジュール（３０４Ｂ）は機能して、自動的にＴＡＲを拒否する。記録（１９０２（１−ｎ））に示されるように、活動不可能購入日時は、自動活動不可能日時フィールド（１９０８）により定義されるいかなる日時とも対応する。或いは、活動不可能購入日時は、活動不可能日時及び記録（１９０２）に格納される次の再活動可能日時との間の期間のいずれとも対応する。例えば、自動活動不可能日時フィールド（１９０８）が、カード所有者の口座が各週末のはじめに自動的に活動不可能にされたと決定し、且つ、ＴＡＲが週末の時間帯に相当する購入日時を有していると受信した時、マスタ検証モジュール（３０４Ｂ）は機能して、拒否フラグ（４１８）を１の値となるように設定する。例えば、（カード所有者が問題の週末の間にカードを再活動可能にしない限り、）購入が週末に行われた場合は拒否される。他の例としては、活動不可能日時フィールド（１９１２（ｘ）（１））に格納される活動不可能日時の後であって、且つ活動可能日時フィールド（１９１０（ｘ）（２））に格納された再活動可能日より前に購入が行われたときもまた、ＴＡＲは拒否される。

実施形態として記載されるごとく、活動可能及び活動不可能フィールド（１９１０（ｘ）（１））−（１９１０（ｘ）（ｒ））及び（１９１２（ｘ）（１））−（１９１２（ｘ）（ｒ））に格納される情報、及びフィールド（１９０４（１））及び（１９０６（１））に格納される自動活動可能及び活動不可能データは、全て承認処理の間に評価される。すなわち、カード所有者（１０２）は、自動活動不可能にされた後であって、且つ次の自動的に活動可能とするまでに、口座を活動可能にすることができる。これは、単に、記録（１９０２）の新しい活動可能入力（１９１０）により行われる。したがって、自動的に活動可能とする／活動不可能にすることと、後に口座所有者が行う活動可能／活動不可能にすることは対立しない。むしろ、全ての活動可能／活動不可能データ（自動、又は別途入力されたデータ）は、時間軸において等しく有効なポイントとして考えられる。

データベース（１７０２）に活動可能及び活動不可能データを格納することにより、他の特定の利点を得ることができる。取引が開始された後、何日かの間、ＴＡＲがクレジットカード会社に送信されなかった場合、カード所有者は、先の取引のＴＡＲが拒否される心配なく、彼らのカードを活動不可能にさせることができる。ＴＡＲを受信したとき、マスタ検証モジュール（３０４Ｂ）は機能して、ＴＡＲに含まれる購入日時と、各活動可能記録（１９１０（ｘ）（１））−（１９１０（ｘ）（ｒ））及び各活動不可能記録（１９１２（ｘ）（１））−（１９１２（ｘ）（ｒ））を比較する。したがって、ＴＡＲとともに含まれる購入日時が正しく、且つ活動可能な状態と合致する限り、ＴＡＲは、処理されるために先に記載したクレジット承認及び検証処理へ進む。

図２０は、本発明の特定の実施形態に関し、ＴＡＲを処理する方法（２０００）の概要を示すフローチャート図である。第１段階（２００２）において、サーバ（２００Ｂ）の商事業者通信モジュール（２３２）はＴＡＲを受信し、このＴＡＲには、商事業者（１０４）からの口座識別子（例えば、クレジットカード番号）を含み、ＴＡＲ記録（４０２）を生成し、ＣＡＲＱ（２２０）にＴＡＲ記録（４０２）を書き込む。第２段階（２００４）において、認可モジュール（２２６Ｂ）は、カード所有者（１０２）が選択的に彼らのクレジットカードを活動不可能にしたか否かを決定する。もし、活動不可能にしていない場合、第３段階（２００６）において、認可モジュール（２２６Ｂ）は、ＴＡＲ記録（４０２）に従来のクレジット承認処理を施す。そして、認可モジュール（２２６Ｂ）は、承認フラグ（４１６）又は拒否フラグ（４１８）を設定して、要求されたクレジットが承認されるか、又は拒否されるかを示す。第４段階（２００８）において、認可モジュール（２２６Ｂ）は、フラグ（４１６）及びフラグ（４１８）によって、要求されたクレジットが承認されるか拒否されるかを決定する。第４段階（２００８）において、認可モジュール（２２６Ｂ）は、要求されたクレジットが承認されたと決定すると、第５段階（２０１０）において、認可モジュール（２２６Ｂ）は、カード所有者が選択的に検証処理を無効にしたか否かを決定する。検証処理が選択的に無効にされなかった場合、第６段階（２０１２）において、認可モジュール（２２６Ｂ）はカード所有者（１０２）とともに取引を検証する。次に、第７段階（２０１４）において、認可モジュール（２２６Ｂ）は、ＴＡＲがカード所有者（１０２）により検証されたか否かを決定する。ＴＡＲが検証された場合、第８段階（２０１６）において、商事業者モジュール（２３２）は商事業者（１０４）へ取引承認を転送する。次に、第９段階２０１８において、認可モジュール（２２６Ｂ）はＣＡＲＱ（２２０）に他のＴＡＲ記録が存するか否かを決定する。ＣＡＲＱ（２２０）にもはや記録が存在しない場合、方法（２０００）は終了する。

第２段階（２００４）において、認可モジュール（２２６Ｂ）が、カード所有者（１０２）が彼らのカードを活動不可能にしたと決定したとき、方法（２０００）は、第１０段階（２０２０）へ進む。この第１０段階において、商事業者通信モジュール（２３２）は商事業者（１０４）へ拒否を送信する。第４段階（２００８）において、認可モジュール（２２６Ｂ）はクレジット要求が拒否されたことを決定すると、方法（２０００）は第１０段階（２０２０）へ進む。この第１０段階において、商事業者通信モジュール（２３２）は商事業者（１０４）へ拒否を転送する。第５段階（２０１０）において、認可モジュール（２２６Ｂ）は、検証処理が選択的に拒否されたことを決定すると、方法（２０００）は第８段階（２０１６）へ進む。この第８段階において、商事業者通信モジュール（２３２）は商事業者（１０４）へ承認を転送する。第７段階（２０１４）において、認可モジュール（２２６Ｂ）が、ＴＡＲはカード所有者により検証されなかったと決定すると、方法（２０００）は第１０段階（２０２０）へ進む。この第１０段階において、商事業者通信モジュール（２３２）は商事業者（１０４）へ拒否を送信する。最後に、第９段階２０１８において、認可モジュール（２２６Ｂ）が、ＣＡＲＱ（２２０）に他の係属中のＴＡＲ記録が存在すると決定した時、方法（２０００）は第１段階（２００２）に戻り、ＣＡＲＱ（２２０）の次の記録を処理する。

図２１は、カード所有者（１０２）が、カード所有者の口座の活動可能な状態を修正することを可能とするための方法（２１００）の概要を示すフローチャート図である。第１段階（２１０２）において、カード所有者通信モジュール（２２４）は、カード所有者（１０２）からのカード所有者通信要求（例えば、電話呼び出し、ネットワーク要求等）が存するか否かを決定する。これは、ネットワークインターフェイス（２０４）及び通信機器（２１４）を投じて行われる。カード所有者通信要求が存在する場合は、第２段階２１０４において、相互活動可能モジュール（１８０２）はカード所有者（１０２）との接続を確立する。第３段階（２１０６）において、相互活動可能モジュール（１８０２）がカード所有者（１０２）を認証し（例えば、認証コードを要求する）、第４段階（２１０８）において、相互活動可能モジュール（１８０２）が、カード所有者（１０２）に関連するクレジットカード口座の活動可能な状態を検索する。第５段階（２１１０）において、相互活動可能モジュール（１８０２）は、カード所有者（１０２）がクレジットカードの活動可能な状態の修正を希望するか否かを決定する。（例えば、事前に記録したメニューからのプロンプトを受信する）カード所有者（１０２）が口座の活動可能な状態の修正を希望するとき、方法（２１００）は第６段階（２１１２）へ進む。この第６段階において、カード所有者（１０２）はクレジット口座の活動可能な状態を設定することができる。この活動可能な状態の設定には、必要に応じて、自動活動可能及び活動不可能日時、或いは他の活動可能／活動不可能データを定義することも含まれる。第７段階（２１１４）において、相互活動可能モジュール（１８０２）はカード所有者（１０２）との接続を終了させる。

第５段階（２１１０）において、カード所有者がクレジットカードの活動可能な状態の修正を希望しない場合は、方法（２１００）は第７段階（２１１４）へ進み、カード所有者（１０２）との接続を終了させる。必要に応じて、相互活動可能モジュール（１８０２）は、代わりにカード所有者（１０２）を相互検証モジュール（３０６）（又は（３０６Ａ））に、又は他のいくつかのサービスモジュールに転送してもよい。そこで、カード所有者は相互検証モジュール（３０６）（又は（３０６Ａ））にＴＡＲを検証するように指示する、或いは事前検証基準（１３０２）の修正を指示する。

図２２は、本発明に関し、商取引を行うための方法（２２００）の概要を示すフローチャート図である。この方法は、カード所有者（１０２）が選択的にクレジット口座を活動可能及び活動不可能にすることを含む。第１段階（２２０２）において、カード所有者（１０２）が従来の方法を介してクレジットカードを活動可能にする。前記従来の方法としては、クレジットカードが最初に郵送で受け取られた際に、自動サービスを呼び出す方法が挙げられる。最初の活動可能日時は、カード所有者（１０２）に関連する活動可能データベース（１７０２）にある記録（１９０２（ｘ））の第１活動可能フィールド（例えば、活動可能日時フィールド（１９１０（１）（１））に格納される。第２段階（２２０４）において、カード所有者（１０２）は、クレジットカードを用いて１又はそれ以上の購入を行う。そして、第３段階（２２０６）において、カード所有者（１０２）は、クレジットカードを活動不可能にする。この活動不可能にすることは、例えば、カード所有者通信モジュール（２２４）を介してサーバ（２００Ｂ）と接続することにより行われる。或いは、前記活動不可能にすることは、相互活動可能モジュール（１８０２）に指示して、関連する活動可能記録（１９０２）（例えば、活動不可能日時（１９１２（１）（１））における）における活動不可能日時を記録することにより行われる。次に、第４段階（２２０８）において、カード所有者（１０２）は、彼らが更なる商取引を行う必要があるか否かを決定する。もし、さらなる商取引を希望する場合は、カード所有者（１０２）は、再度サーバ（２００Ｂ）と接続し、クレジットカードを再度活動可能にする。これは、相互活動可能モジュール（１８０２）に対し、次の活動可能日時（例えば、活動可能日時（１９１０（１）（２）））を記録するように指示することにより行われる。そして、更なる購入が成立する。

しかしながら、段階（２２０８）において、追加の取引が必要ではない場合、カード所有者（１０２）に関連するクレジット口座は活動不可能な状態及び保護された状態を維持する。これにより、カード所有者（１０２）の口座の不正使用が防がれる。

図２３は、表面（２３０２）及び裏面（２３０４）を有するクレジットカード（２３００）を示す。クレジットカード（２３００）の表面（２３０２）は口座表示を有する。この口座表示は、口座番号（２３０６）、有効期限（２３０８）、カード所有者（例えば、カード所有者（１０２））の氏名（２３１０）を含む。カード（２３００）の表面（２３０２）には、セキュリティ表示（２３１２）もまた含まれる。

口座番号（２３０６）、有効期限（２３０８）及び氏名（２３１０）はクレジットカードの一般的な特徴であり、これらはカード所有者（１０２）のクレジット口座に関連する。セキュリティ表示（２３１２）は、しかしながら、創作的な機能である。この機能により、カード（２３００）による取引は、１又はそれ以上のセキュリティ機能により保護されていることが示される。このセキュリティ機能には、本発明のセキュリティ機能が含まれるが、これに限定されるものではない。セキュリティ表示（２３１２）により、クレジットカード（２３００）及び／又は関連するクレジット口座番号（２３０６）を用いて違法な取引をすることが困難であると、不正使用者に警告を発することができる。このように違法な取引をすることが困難である理由は、購入は、口座所有者の検証を要求するからである。

クレジットカード（２３００）の裏面（２３０４）は、磁気ストライプ（２３１４）、署名フィールド（２３１６）、第２セキュリティ表示（２３１８）を含む。磁気ストライプ（２３１４）は、電子可読の口座データを含み、カード（２３００）はカードリーダに通され得る。署名フィールド（２３１６）は、カード所有者（１０２）がクレジットカード（２３００）に署名するための部分である。最後に、第２セキュリティ表示は、創作的な機能である。この機能により、クレジットカード（２３００）と連結する口座と関連する取引セキュリティ機能の、より詳細な記載を提示することができる。セキュリティ表示（２３１８）（表示（２３１２）であるような）は、違法にクレジットカード（２３００）を使用することが特に困難であると示す。これにより、不正使用を思いとどまらせることができる。口座所有者の検証が要求されることを示す表示は、効果的である。なぜなら、たとえ他のセキュリティ機能が完全に実行されない場合でも、不正使用を実質的に減らすことができるからである。

以上が、本発明の特定の実施形態の説明である。本発明から逸脱しない限り、本明細書に記載された特徴の多くは、他と置き換えても、変更されても、省略されてもよい。例えば、本発明は、本明細書に記載されるクレジットカードタイプの口座に加えて、セキュリティを備えた処理を必要とする口座（例えば、デビット口座）の代替タイプとのコンジャンクションにおいて実行されてもよい。他の例としては、クレジットカード会社（１０６）と代わって、第三者検証会社（１０８）が本明細書に記載される取引処理方法を採用してもよい。そして、第三者検証会社が検証表示をクレジットカード会社（１０６）に転送してもよい。さらに、図１１は、事前検証基準（１１０２）を別個のブロックで示す。事前検証基準は、代わりにカード所有者リスト（２２２）であるような他の記録内に格納されてもよい。同様に、カード所有者通信モジュール（２２４）及びモジュール（３０６）の機能を組み合わせて、単一の機能モジュールとしてもよい。事実、本明細書で開示した機能的なモジュールはまとめられて標識することにより本発明がより明確に示された。また、機能を特別に分離することは、本発明の本質的要素に影響しない。前述の形態及び特定の実施形態から逸脱した他の形態は、特に前述の開示により、当業者にとって明らかなものである。

本発明に関し、カード所有者、商事業者、クレジットカード会社、第三者検証会社間のインターネットワークのブロック図である。 図１のクレジットカード会社のサーバを示すブロック図であり、このサーバは作業メモリ及び該作業メモリ内に認可モジュールを含む。 図２で示される認可モジュールを詳しく示すブロック図である。 図２のクレジット承認要求キュー（Ｑｕｅｕｅ）中の取引承認要求記録を格納するための例示的なデータ構造を示すブロック図である。 図２のカード所有者リストモジュールにカード所有者データを格納するための例示的なデータ構造を示すブロック図である。 図２の購入履歴モジュール内に取引記録を格納するための例示的なデータ構造を示すブロック図である。 本発明における、安全でセキュリティが備わった電子取引を提供するための方法の概要を示すフローチャート図である。 図７の方法の第４段階（検証は可能？）を実行するための方法の概要を示すフローチャート図である。 図７の方法の第５段階（カード所有者による検証）を実行するための方法の概要を示すフローチャート図である。 図７の方法の第５段階（カード所有者による検証）を実行するためのその他の方法を示すフローチャート図である。 本発明に関し、代替サーバを示すブロック図であって、この代替サーバは事前検証基準及び代替認可モジュールを含み、これらは事前に検証した取引に使用される。 図１１の代替認可モジュールの詳細を示すブロック図である。 図１１の事前検証基準を格納するための例示的なデータ構造を示すブロック図である。 本発明に関し、安全でセキュリティの備わった電子取引を提供するための他の方法の概要を示すフローチャート図である。 図１４の方法の第４段階（事前検証基準は満たされたか？）を実行する方法の概要を示すフローチャート図である。 図１４の方法の第５段階（事前検証基準は満たされたか？）を実行するための他の方法の概要を示すフローチャート図である。 カード所有者が、カード所有者の口座に関連する事前検証基準を修正する方法の概要を示すフローチャート図である。 本発明に関し、活動可能データベースを含む代替のサーバを示すブロック図であり、該活動可能データベースは活動可能データ及び活動不可能データを格納するために使用される。 図１７の代替の認可モジュールの詳細を示すブロック図である。 図１７の活動可能データベース中に活動可能データを格納するための例示的なデータ構造を示す 本発明に関し、電子取引を処理するための他の方法の概要を示すフローチャート図である。 カード所有者が、カード所有者の口座の活動可能な状態を修正することを可能とするための方法の概要を示すフローチャート図である。 本発明に関し、口座を選択的に活動可能／活動不可能にするための方法の概要を示すフローチャート図である。 関連する口座所有者の口座が１又はそれ以上のセキュリティ機能により保護されること示すセキュリティ表示を有するクレジットカードを示す。

Claims (44)

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. 前記セキュリティ表示が、
    前記少なくとも一つのセキュリティ機能が、前記クレジット口座に関連する口座所有者により前記クレフィット口座が選択的に活動可能及び活動不可能にされることを含むこと
    を示す請求項４１に記載のカード。

Images