JP2009501980A - 取引カードの即時発行システム及び方法 - Google Patents

Abstract

取引カードの即時発行システム及び方法は、その上にエンコードされたカード番号を有する記憶媒体を含む少なくとも１枚の未割り当て取引カードを含む。このシステムはまた、前記未割り当て取引カードを供給された申請人から申請情報を受け取り、前記申請情報の審査時に申請人が金融資金へのアクセスを承認されていることを示すとき、未割り当て取引カードを有効にして前記未割り当て取引カードを介して申請人に対し金融資金に対するアクセスが期限延長されるようにしたコンピュータシステムを含む。未割り当て取引カードは申請人に関する情報を示す可視標識を一切記載せず、前記未割り当て取引カードの記憶媒体に対し前記申請人に関する情報を一切エンコードしない。

Description

本発明は広く金融及びデータ取引システムに係り、より詳しくはオープンネットワーク上での金融及びデータ取引を実行するシステム及び方法に関するものである。

本出願は、米国籍企業であって米国を除く全ての国を指定する出願人グラティス・カード・インコーポレイテッド（Ｇｒａｔｉｓ Ｃａｒｄ， Ｉｎｃ．）と、米国市民であって米国のみを指定する出願人ジェイソン・ジュード・ホッグ（Ｊａｓｏｎ Ｊｕｄｅ Ｈｏｇｇ）及びパトリック・グラフ（Ｐａｔｒｉｃｋ Ｇｒａｆ）の名義において、２００５年７月１５日出願の米国特許出願第６０／７００，０４９号に基づく優先権を主張し、２００６年７月１４日にＰＣＴ国際特許出願として出願するものである。

図１は、現在行われている典型的なクレジットカード取引を示すものである。図１に示されるように、この過程は、クレジットカード保持者１００が販売業者施設１０２内の販売時点管理装置（例えば金銭登録機（レジ））に配置された係員にクレジットカードを提示することによって、処理１０１により表されるように始まる。これに応じて一般的には、係員は販売時点管理装置に結合されている磁気帯片読み取り器にカードを「通す」。このようにして、カード保持者の氏名及びクレジットカード番号を含むカード保持者の情報が、カード上の記憶媒体から販売時点管理装置へ転送される。

販売時点管理装置はカード保持者情報に取引情報（販売総額及び販売業者識別を含む）を複合させ、複合データ群を取得者あるいは第三者プロセッサ１０４へ、処理１０３により表されるように送信する。第三者プロセッサ１０４は、カード発行団体（例えばＶｉｓａやＡｍｅｒｉｃａｎ Ｅｘｐｒｅｓｓ等）の専有取引ネットワーク１０６へデータ群を転送することにより応答（処理１０５）し、これによってデータ群が発行銀行１０８へ処理１０７により表されるように送られる。

データ群を受け取ると、発行銀行１０８は提示金融取引をクレジット規約群に照合して、金融取引を承認するか拒絶するかのいずれかを行う。承認された場合には、その承認が同じ経路を逆順で遡行（処理１０９，１１１，１１３）し、販売業者の居所１０２の販売時点管理装置に達する。その後カード発行銀行１０８は、同様の複合データ取引群により、処理１１５に表されるように販売業者銀行１１０へ販売価格に等しい総額を送金する（通常、プロセッサは販売業者銀行１１０へ総額を送金する媒介として使用される）。支払期間が満了すると、カード保持者１００はカード発行銀行１０８に販売価格（に利息と金利手数料を加えたもの）を支払う（処理１１７）。

前述の方式は、若干の欠点を呈するものである。例えば、販売業者１０２と認証企業（この場合、カード発行銀行１０８）との間のデータ通信に専有ネットワークを使用するために、そのネットワークの設置ならびに保守にコストがかかる。このコストは、結局は販売業者１０２が負担することになる。専有ネットワークを使用することにおける別の欠点は、基盤及び経費上の制約のために販売業者の販売時点管理装置からは比較的少量のデータしか送信できない点にある。これは例えば、カード保持者にその月次明細にある所与の取引に関する詳細な情報を提示できないということを意味する。ある特定の状況では、既存のクレジットカード技術も、所与の取引の内容に関する情報を時折まさに含んでいる。しかしながら、この種の情報はその取引の実行と同時の時点では収集されない。代りに、それは取引実行後時間が十分に経過してから収集される。データ収集においてこの遅延が生ずると、ここで提示されている幾つかの利点が今日存在するクレジットカード技術の状況下では目下不可能となる。

前述の方式は、また本来的に他の欠点も有するものである。通常、個人識別情報はクレジットカード上に印刷あるいはエンボス加工され、かつ、その磁気帯片上にエンコードされる。このことにより、クレジットカード申請人がクレジットカードを承認された時点と申請人がクレジットカードを受け取ることができる時点との間には必然的に遅れが伴う（この介在期間中に申請人の個人情報がカード上に印刷されエンコードされる）。加えて、クレジットカードが使用する記憶機構が磁気帯片であるために、磁気帯片読み取り器が販売時点管理装置と適合していなければならない。これによりさらなる出費が発生し、小規模事業者にこの種のクレジットカードの受け入れを躊躇させる傾向をもたらす。さらに今日、クレジットカードへ電波方式認識（ＲＦＩＤ）装置を導入しようとする進行中の動向がある。この新規構想はまた相当の基盤投資を伴うものであり、そのことがここでも小規模事業者にこの種のクレジットカードの受け入れを躊躇させる傾向をもたらす。

一実施形態によれば、本方法は、店舗内での配布用に商店に対しカードを識別するカード番号をエンコードする記憶媒体を含む取引カードの供給源を提供するステップを含む。前記顧客が前記店舗内にいる間に、前記取引カードのうち１枚が顧客に配布される。前記顧客からクレジット申請情報が得られる。前記顧客が前記店舗内にいる間に、前記クレジット申請情報を審査用に遠隔コンピュータシステムへ通信し、前記配布取引カードを介して信用限度について前記顧客を承認すべきか判定する。前記顧客が前記店舗内にいる間に、前記顧客が承認されて前記配布カードを有効にしたことを示す前記通信に対する応答を受信する。配布取引カードは、前記顧客が前記店舗内にいる間に購入を取引するのに使用される。

別の実施形態によれば、本方法は、前記個人に対し信用限度を期限延長する取引カードを所有する個人に対し、少なくとも１枚の未割り当て取引カードを提供するステップを含む。前記未割り当て取引カードは、その上にエンコードされたカード番号を有する記憶媒体を含む。前記未割り当て取引カードの前記カード番号に、該未取引カードを提供した前記個人が関連付けられる。前記個人によって前記未割り当て取引関連を提供された申請人から申請情報を受け取る。申請情報は、前記カード番号を含む。前記申請情報に含まれる前記カード番号を調べ、前記個人が前記未割り当てカードを元々供給されていたか判定する。前記個人の取引カードが関連する口座に報償ポイントを供給し、前記申請人に前記未割り当て取引カードを配布したことについて前記個人に報償を与える。

別の実施形態によれば、本システムは、その上にエンコードされたカード番号を有する記憶媒体を含む少なくとも１枚の未割り当て取引カードを含む。このシステムはまた、前記未割り当て取引カードを提供された申請人から申請情報を受け取り、前記申請情報の審査時に前記申請人が前記信用限度について承認されたことを示すときに、未割り当て取引カードを有効にし該未割り当て取引カードを介して前記申請人に対し信用限度が期限延長されるようにしてある。未割り当て取引カードは申請人に関する情報を示す可視標識を一切記載せず、前記未割り当てカードの記憶媒体に対し前記申請人に関する情報を一切エンコードしない。

本願明細書に提示する各種実施形態を図面を参照して説明することとするが、図面中同様の参照符号は幾つかの図面を通じて同様の部分とアセンブリを表す。各種実施形態の参照によって、包含される本発明の要旨の範囲が限定されると解釈すべきではなく、本願明細書に添付した特許請求の範囲によってのみ限定されるものである。加えて、本明細書に記載するどの実施例も限定することを意図するものではなく、多数の可能な実施形態の一部を単に記載するに過ぎないものである。

図２に、本発明の一実施形態による金融取引、例えばクレジットカード取引やデビットカード取引やストアードバリューカード取引やプリペイドカード取引等を示す。図２に示すように、カード保持者２００はクレジットカードを販売時点管理装置２０２又はこの種の装置２０２を操作する係員へ提示することで取引を開始する（処理２０１）。無論、この取引は、オンライン商取引用に設計されたウェブサイト内へカード保持者の情報を入力する等して、通常のオンライン取引の流れで開始するものでもよい。例示のためにのみ、本願明細書の図面を参照して説明する取引は、係員の配置された（商店の）販売時点管理装置において行われるものとして説明する。また、ここでより馴染みのある呼称に合わせ、このカードを「クレジットカード」や「カード」あるいは「取引カード」と呼ぶことができる。事実、下記に説明するように、このカードはクレジットカード、デビットカード、ストアードバリューカード及び／又は健康管理データやクラブ会員データ等の各種形態のデータへアクセス可能であるデータアクセスカードとして機能させることができる。

このカードは、下記の特性を呈するようにできる。カード自体は、ポリマー製あるいは任意の適当な材料からなる基板（すなわち、カード本体）を含むものであってよい。記憶媒体が基板上に配置されたり、内部に埋設されたり、及び／又はその上に印刷されるものであってよい。記憶媒体は基板上に印刷されたバーコード等のように読み取り専用としてもよいし、あるいは磁気記憶媒体（例えば、磁気帯片）等のように読み書き可能としてもよい。一部実施形態によれば、クレジットカードはその上にバーコードと磁気帯片の両方を持たせることができる。一部実施形態によれば、カードを一意的に識別するカード番号は磁気帯片上及び／又はバーコード上にエンコードされる。また、クレジットカードはそこにカード番号を記憶させたＲＦＩＤデバイスを含んでいてもよい。一実施形態によれば、この記憶媒体は、それがバーコードや磁気帯片やＲＦＩＤデバイスであれ、カード保持者に関する個人情報を一切含んだりエンコードしたりすることはなく、かつ／又は記憶することがない。一部実施形態によれば、カード上の一（又は複数）の記憶媒体はカードを一意的に識別するカード番号だけを含みかつ／又は記憶する。一部実施形態によれば、カードの一（又は複数）の記憶媒体は個人識別番号（ＰＩＮ）を一切エンコード及び／又は記憶しない。

カードを受け取ると、係員は、バーコード読み取り装置、磁気帯片読取装置、ＲＦＩＤ送受信器等の入力装置へカードを与える。そこで、クレジットカードの記憶媒体上にエンコードされた情報が読み取られる。次にカード保持者は、キーパッド、キーボード、タッチスクリーンディスプレイ及び／又はＰＩＮ入力に適した任意の装置を介して、カード保持者及び係員のいずれかが販売時点管理装置内へ入力することのできる個人識別番号（ＰＩＮ）を要求されるかもしれない。クレジットカードからのデータ、ＰＩＮ、及び販売時点管理装置からの取引情報は、複数のデータパケットを埋めるために使用され、このデータパケットは提示取引の認証要求を構成する単一ユニットとして「パッケージ化」することができる。ここでより詳しく下記において各種パケットについて説明する。パッケージ化ユニットは下記に概略的に説明する方式に従って暗号化され、処理２０３に示すようにインターネット等のオープンネットワークを介して取引プラットフォーム２０４へ送信される。

ここでより詳細に説明するように、取引プラットフォーム２０４はカード発行銀行との一定程度の統合を維持することにより、認証決定に至る上でカード発行銀行に対しさらなる通信を必要とすることなく、取引の全てもしくは大半、又は一部（例えば、閾値ドル額未満の取引）を認証又は拒絶することができる。認証決定あるいは拒絶決定に至った後、認証／拒絶は処理２０５に示すように、オープンネットワーク（例えば、インターネット）を介して販売業者２０２へ返送される。

上記の実施形態は、本願明細書に説明する各種実施形態の実施に必須ではないが、特記される幾つかの利点を呈する。例えば、販売業者２０２と取引プラットフォーム２０４との間の通信はインターネット等のオープンネットワークを介して行われる。オープンネットワークを利用することにより、専有ネットワーク要素及び／又は回線に対する必要性が排除及び／又は低減され、これによって各取引の実行経費が低減されることとなる。また、インターネット等のオープンネットワークを介する通信は無料であるため、販売業者２０２と取引プラットフォーム２０４との間で比較的大量のデータが交換できるので、下記に説明するように、請求明細におけるよりよい分析が可能となる。さらに、信用枠、利息金額、手数料等の銀行が定める銀行規約はプラットフォームにより管理されるので、同じくオープンネットワークにより定期化システム統合／同期を介して行われる情報団体２０２と各種カード発行銀行２０６との間の定期的通信に対する必要性が低減され、同じ恩恵に得ることができる。

また特記すべき点は、一部実施形態において、クレジットカードが個人情報を一切含まないという点である。具体的には、カード表面に情報が印刷又はエンボス加工され、そうでなくとも提示されることは一切なく（例えば、カード保持者の名前がカードに記載されない）、またカード上の記憶媒体に個人情報がエンコードされ内部記憶又は内蔵されることも一切ない。この構成により、カード保持を希望する者は、有効な取引カードをほぼ即座に手中に収めることができる。例として図３に示すように、例えば商店の販売時点管理装置にて未割当無記名カードを提供することができる（処理３００）。「無記名」とは、そのカードが属する個人を識別するための情報を一切エンコード及び／又は記憶していないことを意味するものである。すなわちカード表面に個人名が記載されておらず、またそのカードの記憶媒体上にも記憶あるいはエンコードされた個人に関する氏名等他の識別情報を有するものではない。カードの記憶媒体には、口座番号ではなくカードを一意的に識別するカード番号だけを含ませるのであってもよい。

処理３０２に示すように、無記名カードが申請人へ配布される。これは、例えば顧客が商品又はサービス購入の取引をしようとする時点で行われる。未割当の無記名カードソースが販売時点管理装置にて保持されているとすると、そこで係員は顧客に、彼又は彼女がクレジットカードを申し込みたいか、あるいはプリペイド／ストアードバリューカードを利用できるようにしたいのか、を尋ねることができる。顧客の回答が肯定であれば、係員はそのときにカードを顧客に供給することができる。無論、申請志望者は友人や他のカード保持者を含む任意の供給源から無記名カードを入手してもよい（下記で説明する）。

次に、取引プラットフォームのサーバ（下記にて詳述）に、申請人の申請情報と、カードを一意的に識別するカード番号とが与えられる（処理３０４）。ここで再び、販売時点管理装置にて無記名カードが顧客へ配布される場合には、顧客の申請情報は係員により販売時点管理装置へ入力することができ、それはその時点でインターネットや電話網等のネットワークを介して取引プラットフォームサーバへ通信される。さらに取引プラットフォームの従業員が（例えば、申請人へ電話を掛けることを通じて）申請人情報を受け取り、これら従業員によりサーバへ入力されることができる（あるいはサーバと通信状態にあるコンピュータ内へ入力することができる）。さらにまた、申請情報を入力できるよう構成されたウェブページ又は店内のスタンドへ申請人を案内してもよい（例えばカードには、ウェブページのアドレスを記載することができる）。申請人は彼又は彼女の申請情報をウェブページ内へ直接入力し、それにより彼又は彼女の申請情報をサーバへ通知することができる。通常、申請情報は任意の態様にてサーバに受信される。

申請情報自体には、個人の信用価値を決定すべく、信用調査を行う上で通常必要とされる情報を含ませることができる。例えば、この種の情報として、名前、住所、電話番号、及び／又は申請人の社会保険番号を含ませることができ、また職場やこの職場等での勤続年数等の雇用情報を含ませてもよい。申請情報は、申請人の金融取引を適切に処理するためにサーバが必要とする最低限の情報群で構成してもよい。一部実施形態によれば、サーバは申請人に関する広範な情報を記憶したデータベースへアクセス可能である。この種の情報には、健康情報や緊急時連絡先情報や家族情報等（これらその他の形式の情報は下記で説明する）が含まれてもよい。申請情報を受け取った時点で、前述の他の形式の情報は取引プラットフォームのサーバにより受信できなくなる。このようにして、サーバは申請人の申請に関する前述のデータベース内のテーブルを申請情報を用いて埋め、また申請人等に関する他のテーブルを最低限埋めることもできる。申請が最終的に承認された場合には、後日他の情報を申請人／カード保持者から収集でき、データベースの各種テーブルをより完全に埋めることができる。

申請情報を受け取った後、サーバはデータベース内の情報を入力して、申請人のカード番号に申請人の申請情報を関連付ける（処理３０６）。その後、申請の審査が行われる（処理３０８）。一部実施形態によれば、申請人に対し信用調査を行ってもよい。申請情報には、信用度点数サービス（例えば、フェア・アイザック社（Ｆａｉｒ Ｉｓｓａａｃ Ｃｏ．））に問い合わせて、個人に関する信用度点数（例えば、ＦＩＣＯスコア）を取得するのに十分な情報量を含ませることができる。例えば、情報団体のサーバはインターネット等のネットワークを介して信用度点数サービスと通信し、個人に関連する信用度点数を見つけることができる。信用度点数が特定の基準点を上回る場合には申請人は承認され、そうでない場合は拒絶される。他の実施形態によれば、申請人の申請情報はインターネット等のネットワークを介して１以上のカード発行銀行へ通知される。各カード発行銀行は各々申請情報を用いて独自の分析を行い、申請を拒絶するか承認するかをそれぞれ決定することができる。一部実施形態によれば、取引プラットフォームサーバは承認するカード発行銀行が提供するクレジット条件を比較し、カード番号に関連する銀行として最良のクレジット条件を提示するカード発行銀行を選択する。他の実施形態によれば、各カード発行銀行は入札額、例えば口座を獲得する上で取引プラットフォームに対して支払う総額を通知し、取引プラットフォームは例えば最高の入札額を提示する銀行を選択することができる。他の実施形態によれば、複数の銀行にカード番号を関連付け、申請人／将来のカード保持者が各購入ごとに銀行間で信用の拡張を選択できるようにすることができる。

分析がどのようになされるのかに関係なく、申請人が承認されたことを審査が示す場合、サーバはデータベース内へ情報を入力し、処理３１０に示すように申請人のカードに規約を関連付ける。例えば、信用度点数に基づき定められる支払い限度額をカードに関連付け（あるいはカード発行銀行が限度額を定め、この限度額を取引プラットフォームの銀行に通知することができ）、一般の不正防止データをカードに関連付ける等することができる（処理３１２）。その後そのカードが有効となり（処理３１４）、カードを使用して取引を実行し、例えば信用によって商品又はサービスを購入できる（あるいは下記に説明するように、デビットカードやストアードバリューカード等として購入取引する等の他の仕方で使用できる）こととなる。取引実行を促すべく、取引カードに割り当てられたＰＩＮを承認された申請人へ通知する。例えば、ＰＩＮはショートメッセージサービスメッセージや、無線又は他の装置により受信される電子メールや、販売時点管理装置等を介してカード保持者へ通知することができる。このＰＩＮは、恒久的なＰＩＮであってもよく、又は、特定の期間や特定の使用回数について、もしくは特定額未満の金額を有する取引に関連してのみ有効なものであってもよい。

他方で、申請が拒絶され、カードを有効にしない（３１６）ことを処理３１０が示す場合には、取引の履行にそのカードが使用できないこととなる。

処理３００〜３１４はほぼ即時に実行することができる。例えば、一部実施形態によれば、処理３００〜３１４は１分未満で実行することができ、他の実施形態ではこの種処理は３０秒、１５秒、及び／又は５秒未満で実行することができる。このようにして、例えば申請人が商店の販売時点管理装置において購入を開始する一方でカードを申請でき、実際に有効となったカードを入手し、申請人がそのカードを使用してその購入（と同様に他の販売業者における他の購入）を取引できる。カードが無記名であるため、カード保持者を識別する印刷をカードに載せる必要が全くなく、またカードの記憶媒体中にこの種の識別情報あるいはＰＩＮをエンコードする必要も全くない。したがって、申請処理後に、申請人を識別する情報をカード上に印刷し、その記憶媒体にエンコードするための待機期間は一切存在しない。

図２を参照して説明したように、本願明細書に記載した取引カードを用いて購入取引するために、販売時点管理装置（例えば、レジ）が所与のカードを読み取って、オーブンネットワークを介して取引プラットフォームのサーバへ情報を通信することができる。図４は、図２の販売時点管理装置２０２を備えた例示的なネットワーク環境を示す。図４から判るように、所与の販売業者店舗は複数の販売時点管理装置２０２を店舗内に設置して備える。各販売時点管理装置２０２は、ローカルエリアネットワーク（ＬＡＮ）４００へ結合することができる。図４のＬＡＮは、例示の目的としてのみ、イーサーネットネットワークとして描いてある。ＬＡＮ４００は任意の構造、任意のプロトコルを用いるものでよい。

各種販売時点管理装置２０２が、ＬＡＮ４００を介してサーバ４０２と通信する。サーバ４０２は、各販売時点管理装置２０２を介して行われた全取引に関する情報を蓄積するデータベース４０４を管理している。（通常、各取引は下記に説明するように取引識別子により識別される）。サーバ４０２は、ルータ４０６を介してインターネット等のオープンネットワーク４０８との間で情報を転送することができる。

図４のネットワーク環境は例示的なものであり、図解目的にのみ提示されるものである。他の多くの環境が存在することは、当業者には公知である。図５は、展開された取引のカーネルを表すものであり、各種ソフトウェアユニットは、販売時点管理装置２０２、サーバ４０２、これらの二つの組み合わせ及び／又は販売時点管理装置及び／又はサーバ４０２のいずれかと通信するコンピュータ装置のいずれかに記憶させ実行される。ここで、図５のカーネルを図４のネットワーク環境内で展開したとの前提から始めて説明するが、モジュールが任意のネットワーク環境内で使用するよう適用可能であることを当業者は理解するだろう。

図５に戻ると、販売時点管理装置２０２は磁気帯片、バーコード読取装置、又はＲＦＩＤ送受信器等の入力装置５００に結合されている。購入取引中、磁気帯片読取装置５００がカード上の磁気帯片を読み取るために用いられる。無論、カードの記憶媒体がバーコードである場合には、入力装置５００はバーコードスキャナにより実装できる。同様に、カードの記憶媒体がＲＦＩＤチップである場合には、入力装置５００はＲＦＩＤ送受信器により実装できる。入力装置５００がカードの記憶媒体を読み取ると、そこからカードを一意的に特定するカード番号が読み取られる。入力装置５００はキーパッドを含んでいてもよく、これを用いてカード保持者が個人識別番号（ＰＩＮ）を入力することができる。ＰＩＮコードとカード番号は、入力装置５００から販売時点管理装置２０２へ通信される。

販売時点管理装置２０２は、汎用の計算装置の構造を有する。すなわち、販売時点管理装置２０２は通常汎用目的コンピュータに存在する部品を含むものであり、すなわちソフトウェアとデータを記憶する１以上の段のメモリに結合されたプロセッサを含む。このプロセッサは入出力（Ｉ／Ｏ）バスを介して、モニタ等のディスプレイを含む、各種入力装置、出力装置、通信装置と通信し、キーボード、マウス、タッチパッド等の他のポインティング装置及び／又はスピーカと通信し、この種の装置を指名することができる。各種周辺装置もまた、ネットワークインタフェースカード、ハードディスクドライブ等の大量データ記憶装置や、ＣＤ ＲＯＭドライブ、ＤＶＤドライブ（読み取りと書き込みの両方が可能）等の着脱可能なメディアドライブや、無線インタフェース、磁気帯片読取装置、バーコード読取装置、ＲＦＩＤ送受信器等を含むＩ／Ｏバスを介してプロセッサと通信することができる。コンピュータが今日多数のチップセット及びアーキテクチャを採用していることを理解されたい。販売時点管理装置２０２は広義にはこの種の全てのチップセット及びアーキテクチャを意味し、ここで説明するカーネル及び各種ソフトウェア方法の各種実施形態はこの種の全てのチップセット及びアーキテクチャ上で実行することができる。

ＰＩＮコード及びカード番号抽出モジュール５０２は、販売時点管理装置２０２のメモリ内や又は販売時点管理装置２０２と通信及び／又はネットワーク接続した他の任意の装置内に常駐させることができ、そのプロセッサにより実行される。「モジュール」とは、販売時点管理装置２０２のプロセッサが実行可能な機能、オブジェクト、機能及び／又はオブジェクト群、及び／又はコンピュータの命令群（例えばマシンコード）等のソフトウェアの単位又は一部を意味する。無論モジュールが提供する機能は、１以上の特定用途向け集積回路（ＡＳＩＣ）の協調により、あるいは１以上のＡＳＩＣの協調と記憶装置に記憶されプロセッサにより実行されるソフトウェアモジュールにより、採用してもよい。入力装置５００がＰＩＮコードとカード番号を販売時点管理装置２０２へ通信すると、入力装置５００から販売時点管理装置２０２へ通信されるデータ群から、抽出モジュール５０２がカード番号とＰＩＮコードを読み取る。下記に説明するように、抽出モジュール５０２はＰＩＮコード及びカード番号情報を他のソフトウェアモジュールへ通信し、一部実施形態ではそれらをサーバ４０２に記憶させて実行する。

販売時点管理装置２０２は、サーバ４０２が管理するデータベース４０４と通信する。販売時点管理装置２０２がデータベース４０４と交信できるよう、アプリケーション・インタフェース（ＡＰＩ）５０４が配設されている。一部実施形態では、その店舗で販売された品目に関する情報を蓄積するように構成された複数のテーブルを含む方式に従い、データベース４０４が編成されている。データベース４０４にはまた他の情報も蓄積させてもよい。例えば、特定の販売業者が多数の店舗を経営する場合には、全店舗又はある区域内の全店舗で販売されている品目に関する情報をデータベース４０４に蓄積させてもよい。さらに、データベース４０４には商品在庫目録や供給元情報に関する情報や特定事業の経営に役立つ他の情報を蓄積させてもよい。図４のネットワーク構造と同様に、データベース４０４の方式が販売業者ごとに異なり、店舗ごとに異なっていてもよいことを当業者は理解するだろう。

データベース４０４が採用する方式は販売業者ごとに様々でありうるが、通常、データベースは各取引の詳細を記載した記録を蓄積するテーブルを含む。この種のテーブルは、ここでは「取引テーブル」５０６として説明する。取引テーブル５０６は通常、取引識別子５０８を用いて各取引を一意的に識別するよう編成され、すなわち取引識別子５０８を取引テーブル５０６用の主要キーとすることができる。複数のフィールド５１０を、各取引識別子５０８に関連付けることができる。これらのフィールド５１０は、取引に含まれる各品目に関する情報を保管するものである。例えば、このフィールドは下記のうちの１以上を含む。すなわち、（１）取引に含まれる各品目の在庫品管理者ユニット（ａ ｓｔｏｃｋ ｋｅｅｐｅｒ ｕｎｉｔ）（ＳＫＵ）番号、（２）取引に含まれる各品目の価格、（３）取引に含まれる各品目の内部説明、（４）取引に含まれる各品目の外部説明、（５）取引に含まれる各品目の一般的な説明、（６）取引に含まれる各品目が分類される区分、（７）取引に含まれる各品目に関連する売上税と、（８）取引を行ったデータ、（９）取引が行われた時点、（１０）取引が行われた特定の店舗を示す識別子、（１１）取引が行われた特定の販売時点管理装置を示す識別子、（１２）取引の日時において特定の販売時点管理装置を操作する従業員を示す識別子、（１３）特定取引を取引するのに使用される支払い方法の指示、例えば現金やクレジットカード等の指示と、（１４）取引総額、（１５）取引種の指示、例えば購入、返済、還付やデータ問い合わせ等の指示、及び／又は（１６）取引の対象及び／又は環境を記述する他の任意の情報、である。列挙した通常の多様な情報、すなわち取引総額、日付、時間及び／又は場所（販売業者及び市／国の識別）を超える情報は、「レベル３データ」と呼ばれる。

販売時点管理装置２０２が取引に含まれる各品目を読み取った後に、支払い技法を選択することができる。販売時点管理装置２０２は、取引カードを介して実行する取引種について、例えばカードをクレジットカード、デビットカード及び／又はストアードバリューカードとして使用するかどうかを問い合わせる画面を示すことができる（前記したように、取引カードは一取引の文脈内でクレジットカードとして、別の取引ではデビットカードとして、さらに別の取引の文脈ではストアードバリューカードとして使用することができる）。販売時点管理装置２０２はＡＰＩ５０４を用いて、実行中の取引を一意的に参照する新規取引識別子５０８を作成する。そこで、取引に関する取引種別とレベル３データを、取引識別子５０８に関連させて取引テーブル５０６に記憶させることができる。一部実施形態によれば、ＰＩＮ及びカード番号抽出器５０２もまた取引種を捕捉し、下記に説明するように取引種データを第２の暗号化モジュール５２２へ送る。

モニタモジュール５１２はＡＰＩ５０４と交信し、取引テーブル５０６内で新規取引識別子５０８の作成を監視する。新規取引識別子の作成を監視する際、モニタモジュール５１２がデータ抽出モジュール５１４を呼び出しその動作を開始させる。

一部実施形態によれば、データ抽出モジュール５１４はＡＰＩ５０４と交信して新規取引に関連する取引識別子を含むレベル３データを抽出する。他の実施形態によれば、データ抽出モジュール５１４はＡＰＩ５０４と交信し、レベル３データの全量未満を抽出する。例えば、データ抽出モジュール５１４は取引識別子と取引総額のみをデータベース４０４から取得するのでもよい。例示目的としてのみ、本文書はデータベース４０４からレベル３データの全範囲を取得するものとしてデータ抽出モジュール５１４を説明する。

データ抽出モジュール５１４がデータベース４０４からデータを抽出できるように、図５に示すカーネルの実装時点で、この種の抽出を可能にする情報がデータ抽出モジュールに供給される。例えば、データ抽出モジュール５１４のコード及び／又はデータ空間は、取引テーブル５０６の名前とデータを捕捉しようとしている各種フィールド５１０の名前に照らして変更してもよい。

レベル３データは、データ抽出モジュール５１４に捕捉されると、メモリ５１６の一領域へ入力されて第１の暗号化モジュール５２０へ転送される。第１の暗号化モジュール５２０の転送に先立ち、十全性モジュール５１８が捕捉データを調べ、ＰＩＮ及びカード番号抽出器５０２と交信して下記を保証する。すなわち、（１）データ抽出モジュールが少なくとも全額と取引識別子とを捕捉すること、（２）ＰＩＮ及びカード番号抽出器５０２がカード番号及びＰＩＮを捕捉すること、である。前述のデータを捕捉していなかった場合にはエラーが示され、取引に相対するカーネルの処理は中断する。一方で前述のデータを捕捉した場合には、メモリ５１６の記憶データが第１の暗号化ユニット５２０へ送られる。

第１の暗号化ユニット５２０は、ＰＩＮ及びカード番号抽出器５０２とが捕捉したＰＩＮを暗号鍵として用いてレベル３データと取引種データ（取引種データは図５に示すようにＰＩＮ及びカード番号抽出器５０２とから受信する）を暗号化し、それによって第１の暗号化オブジェクト６００を作成する。図６に第１の暗号化オブジェクト６００を示す。第１の暗号化オブジェクト６００は、第１の暗号化モジュール５２０から第２の暗号化モジュール５２２へ送られる。

第２の暗号化モジュール５２２は第１の暗号化オブジェクト６００を受け取り、そこにカード番号を添付し、添付データ群を作成する。（図５に示すように、カード番号はＰＩＮ及びカード番号抽出機５０２から得る）。そこで、販売業者パスワードを鍵として用いて添付データ群を暗号化し、それによって第２の暗号化オブジェクト６０２を取得する。第２の暗号化オブジェクト６０２を図６に示す。第２の暗号化オブジェクト６０２は第２の暗号化モジュール５２２から第３の暗号化モジュール５２４へ送られる。一部実施形態によれば、販売業者パスワードは６４，１２８，２５６，５１２ビット値又はオープンネットワークに送信されたときに第２の暗号化オブジェクト６０２が侵入者により復号されないよう保護する別の適当な長さ値としてある。販売業者パスワードは通常、販売業者と取引プラットフォームにおいて必要な、選択された従業員群だけが知るようにされ、秘密を保っている。一部実施形態によれば、販売業者パスワードが販売業者のサーバ４０２へのカーネルの実装時点でカーネルのコード及び／又はデータ空間内へ入力される。

第３の暗号化モジュール５２４が第２の暗号化オブジェクト６００を受信し、販売業者識別子、店舗識別子、販売時点管理装置識別子とをそこに添付して、添付データ群を作成する。販売業者識別子は、販売業者を一意的に識別する値（例えば、取引がそのターゲットの店舗にて行われたかを示す値）である。店舗識別子は、取引が行われる特定店舗を一意的に示す値（例えば、ターゲットのどの店舗において取引が行われるかを示す値）である。販売時点管理装置識別子は、取引が行われる特定の販売時点管理装置２０２を一意的に識別する値（例えば、どのレジにて取引が行われるかを示す値）である。販売業者識別子や店舗識別子や販売時点管理装置識別子は、ＡＰＩ５０４を介してデータベース４０４から取得される。一部実施形態によれば、販売業者のサーバ４０２に対し図５のカーネルの実装時点で、この種の情報を含むデータベース４０４内の一（又は複数）のテーブルとフィールドの名前とが第３の暗号化モジュール５２４内へ入力（例えば、第３の暗号化モジュール５２４のコード及び／又はデータ空間内に入力）され、これによりそれはＡＰＩ５０４と交信してこの種情報を取得することができる。第３の暗号化モジュール５２４はそこで取引プラットフォーム２０４に関連する公開鍵を用いて添付データ群を暗号化し、搬送オブジェクト６０４を作る。搬送オブジェクト６０４を図６に示す。一部実施形態によれば、公開鍵は６４ビット値か１２８ビット値か２５６ビット値か５１２ビット値とするか、あるいはオープンネットワークに沿う送信時に搬送オブジェクト６０４が侵入者により復号されないよう保護するのに適した他の長さの値とする。搬送オブジェクト６０４は、ＳＳＬモジュール５２６が使用するＳＳＬ暗号鍵と共に安全ソケット層（ＳＳＬ）モジュール５２６へ送られる。一部実施形態によれば、前述のＳＳＬ暗号鍵は乱数発生器により生成され、公開鍵は第３の暗号化モジュール５２４内へ直接ハードウェアにて暗号化することができる。

ＳＳＬモジュール５２６は搬送データオブジェクト６０４を受け取り、ＳＳＬ暗号鍵を用いて搬送オブジェクトを暗号化し、暗号化搬送オブジェクト６０６を作る。暗号化搬送オブジェクト６０６を図６に示す。図５は別の実施形態による第３の暗号化モジュール５２４内の乱数発生器が生成するＳＳＬ暗号鍵を示すものであるが、ＳＳＬ暗号鍵はＳＳＬモジュール５２６により生成することができる。

ＳＳＬ層５２６は、オープンネットワーク４０８を介して取引プラットフォームサーバへ通信すべく、暗号化搬送オブジェクトを送信制御プロトコル／インターネットプロトコル（ＴＣＰ／ＩＰ）モジュール５２８へ送る。（図４の例示的ネットワーク環境によれば、搬送オブジェクトはルータ４０６を介してオープンネットワーク４０８へ配信される１以上のパケットとして通信される）。

取引プラットフォームのサーバ上で実行するソフトウェアシステムの例示実施形態を、図７に示す。取引プラットフォームのサーバは、汎用コンピュータ装置と少なくとも同様の要素を含むよう構築されている。すなわち、取引プラットフォームのサーバは通常汎用コンピュータ内に存在する部品を含むものであり、すなわちソフトウェアとデータを記憶する１以上の段のメモリに結合されたプロセッサを含む。このプロセッサは入出力（Ｉ／Ｏ）バスを介してモニタ等のディスプレイを含む、各種入力装置、出力装置、通信装置と通信し、キーボード、マウス、タッチパッド等の他のポインティング装置及び／又はスピーカと通信してこの種の装置を指名することができる。各種周辺装置もまた、ネットワークインタフェースカードやハードディスクドライブや他の大量データ記憶装置、ＣＤＲＯＭドライブやＤＶＤドライブ（読み取りと書き込みの両方が可能）等の着脱自在のメディアドライブ、無線インタフェース、磁気帯片読取装置、ＲＦＩＤ送受信器等を含むＩ／Ｏバスを介してプロセッサと通信することができる。サーバが現時点で多数のチップセットとアーキテクチャを用いることを理解されるだろう。この文書を通じ、取引プラットフォームのサーバは単一として、すなわちあたかもそれが単一マシンであるとして言及することにする。無論、サーバは実際にここに説明する機能を実行する上で協働する複数のサーバで構成してもよい。例えば、２以上のサーバはここに説明する全ての機能を個別に実行することができ、それらは負荷均衡化装置により割り当てられるように、クライアント（すなわち、様々なサイトに実装された各種取引カーネル）を取り扱うことができる。また、第１のサーバがここに説明する下位群の処理を実行し、ここに説明した別の下位群の処理を実行する第２のサーバと通信することができる意味において、２以上のサーバを協働させてもよい。

図７の機能の説明は、例示目的としてのみ、信用取引を参照して提供するものである。ここで説明するように、同じ基盤を用いてデビット取引やストアードバリュー取引やデータアクセス取引やそれらの組み合わせを処理する。

図７のソフトウェアシステムは１以上のパケットを受け取るＴＣＰ／ＩＰモジュール７００を含み、そのペイロードを組み合わせて暗号化搬送オブジェクト６０６を作り上げる。ＴＣＰ／ＩＰモジュール７００は１以上のパケットから暗号化搬送オブジェクト６０６を再構成し、暗号化搬送オブジェクト６０６をＳＳＬモジュール７０２へ送る。ＳＳＬモジュール７０２はＳＳＬ暗号鍵を用いて暗号化搬送オブジェクトを復号し、搬送データオブジェクト６０４を作る。（ＳＳＬモジュール７０２は安全確保されたＳＳＬセッションを開始した交渉によってＳＳＬ暗号鍵へのアクセスできることが当業者には理解されるだろう）。搬送データオブジェクト６０４はそこで第１の復号モジュール７０４へ送られる。

第１の復号モジュール７０４は、ＡＰＩ７０８を介してデータベース７０６へアクセスできる。データベース７０６は、下記により詳しく説明するものと同様に、カード保持者ごとの金融データと他データとを含む。一部実施形態によれば、第１の復号モジュール７０４はデータベース７０６へアクセスして取引プラットフォームの秘密鍵を取得し、そこで搬送オブジェクト６０４を復号し、第２の復号オブジェクト６０２と添付販売業者識別子と店舗識別子とレジ識別子とを作る。他の実施形態によれば、第１の復号モジュール７０４は前述の秘密鍵をそのコード空間内へハードコード化するか、あるいはメモリの一領域から秘密鍵へアクセスする。いずれにせよ、第２の暗号化オブジェクト６０２と添付の販売業者識別子と店舗識別子とレジ識別子とが第２の復号モジュール７１０へ送られる。

第２の暗号復号モジュール７１０もまた、ＡＰＩ７０８を介してデータベース７０６へアクセスできる。第２の暗号復号モジュール７１０は、販売業者のパスワードを入手するために、第１の復号モジュール７０４から渡される販売業者識別子を用いる。例えば販売業者パスワードを得るために、データベース７０６内のテーブルへのアクセスに対する鍵として販売業者識別子を使用することができる。このようにして、第２の復号モジュール７１０は販売業者識別子を販売業者パスワードへ関連付けるテーブルへアクセスすることができ、販売業者識別子を販売業者パスワードを取得する鍵として使用することができる。販売業者パスワードはそこで第２の暗号化オブジェクト６０２を復号するのに用いられ、第１の暗号化オブジェクト６００に添付されたカード番号、販売業者識別子、店舗識別子、レジ識別子とを与える。第１の暗号化オブジェクト６００と前述の添付データは、第３の復号モジュール７１２へ与えられる。

第３の復号モジュール７１２は、カード番号を含む、今説明したデータを受け取り、ＡＰＩ７０８を介してデータベース７０６にアクセスする。第３の復号モジュール７１２はカード番号を用い、データベース７０６からカード識別子とＰＩＮとを取得する。カード番号は、カード番号をカード識別子へ、そしてＰＩＮへ直接に又は間接に関連付けるテーブルへアクセスする鍵として使用することができる。例えば、カード番号をカード識別子及びＰＩＮコード識別子に関連付けるテーブルへアクセスするのに、カード番号を用いることができる。そこでＰＩＮコード識別子を用いて、ＰＩＮを得るためにＰＩＮコード識別子をＰＩＮに関連付けるテーブルにアクセスすることができる。ＰＩＮは暗号化フォーマットにて記憶させてあり、悪用できないようにされていることは当業者には理解されるだろう。それを記憶したテーブルからの検索時に、要求タスクがこの種の復号を要請する適切なアクセスレベルを有するものと仮定し、ＰＩＮは復号される。ＰＩＮの受け取り時に、第３の復号モジュール７１２が第１の暗号化オブジェクト６００を復号し、カード番号、販売業者識別子、店舗識別子、レジ識別子と併せてレベル３データを作る。（無論、図５を参照して説明したように、第１の暗号化オブジェクト６００のペイロードは一部事例では総額と取引識別子しか含まない）。

前述のデータは残高調査モジュール７１４へ送られ、このモジュールが各種復号モジュール７０４，７１０，７１２同様、ＡＰＩ７０８を介してデータベース７０６へアクセスできる。まず、残高調査モジュール７１４が、カード番号に関連する現在の残高及び信用限度を、データベース７０６から取得する。残高調査モジュール７１４は、例えばカード識別子に対する関連カード詳細情報を含むテーブルにアクセスすることができる。そこで、第３の復号モジュール７１２により得られるカード識別子を現在の残高を照会する鍵として用い、信用限度を得る。この現在の残高と提示取引総額の合算値を、信用限度と比較する。合算値が信用限度を上回る場合、提示取引を拒絶することができる（後程、下記に説明）。それ以外は、処理フローは不正調査モジュール７１６へ移行する。

不正調査モジュール７１６は、ＡＰＩ７０８を介してデータベース７０６へアクセスできる。不正調査モジュール７１６は、データベース７０６からカード番号に関連する不正指針規約を取得する。一部実施形態によれば、規約の一部あるいは全部をカード保持者が決定してもよい（下記に説明する）。また、規約の一部又は全てを、カード保持者からの入力無しで生成されるシステム規約としてもよい。提示取引と最新の取引のパラメータを、不正指針規約と比較することができる。不正指針規約を調査した結果の１つが陽性であった場合にはカード保持者に連絡を取ることができる。カード保持者には、取引プラットフォームの従業員が電話を通じて接触することができる（カード保持者の電話番号を含むカード保持者の連絡先情報が図８に示すように主口座とカード識別子に関連するテーブルに記憶させてあることに留意されたい）。カード保持者にはその自己識別特徴（例えば、電話に応答する個人は自身を特定するよう要請され、カード番号に関連するＰＩＮを問い合わせることができる）を確認するよう要請することができ、また取引が適法であることを確認するよう要請される。加えて、カード保持者はショートメッセージサービス（ＳＭＳ）モジュール７１８の処理を介して連絡をとることができる。例えば、ＳＭＳモジュール７１８はカード保持者の携帯電話（この番号はカード保持者に関連させてデータベース７０６内に記憶させてある）へＳＭＳメッセージを送信し、カード保持者に提示取引を承認すべきであることを確認するよう要求することができる。確認された取引が承認されるためには、カード保持者は肯定的に応答しなければならず、また彼のＰＩＮコードを入力しなければならない。ＳＭＳモジュール７１８は応答メッセージを受け取り、それを不正調査モジュール７１６へ返信する。返信メッセージが提示取引を承認すべきでないことを示す場合には提示取引は拒絶（後述）され、カードは凍結（同様に後述）される。返信メッセージが、取引が適法でありカードに関連するＰＩＮを含むことを示す場合には、実行フローはプロフィール調査モジュール７２０へ続く。

プロフィール調査モジュール７２０は、子カード上で作動する。「子」カードは、親カードが関連付けられているのと同じ主口座（図８を参照して説明される）に関連するカードである。この種の関連付けの効果は、親カード及び関連する任意の数の子カードが同じ資金から支払われ、すなわち同じ信用限度から、同じストアードバリュー値から、プリペイドサービスあるいは商品の同じ残高から及び／又は同じ点検口座あるいは銀行口座から支払われる点にある。親カードに関連するカード保持者は主口座に関連する全ての口座の取引を表す明細を受け取り、それにより親カードのカード保持者が親カードとあらゆる子カードの両方を介して行われた取引を表す明細を受け取ることとなる。親カードは下記により詳細に説明するように、子カードの支払い許可に対し規約を設定することができる。例えば、親がカード保持者である状況を想定する。親は、彼の息子又は娘が使用する子口座を作成することができる。子口座が生成する請求額は、親口座上の請求額へ組み込まれる。親は、子口座に対し規約を割り当てることができる。例えば、親は一つの規約に子口座を関連付け、子口座が指定単位時間ごとに選択されたレベルの負債（例えば、毎月２５０ドル）までを負担するようにできる。他の規約としては無制限に、（１）あるＳＫＵあるいはＳＫＵ分類の購入を不許可（一例として：購入品がアルコールであることを示すＳＫＵの購入を不許可）とし、（２）ある販売業者や販売業者種別及び／又は販売業者カテゴリで行われる購入を不許可とし、（３）ある販売業者や販売業者種別及び／又は販売業者カテゴリで行われる購入だけを許可する。この目的に合わせ、一部実施形態によれば、データベース７０６にはそこに記憶させた各種販売業者識別子に関する販売業者種別及び／又は販売業者カテゴリを関連付ける１以上のテーブルを記憶させる。プロフィール調査モジュール７２０は、カード番号に関連する規約（それがある場合）を検索し、提示取引を規約に照らし調査することにより動作する。不正調査モジュール７１６を参照して説明したように、規約が少しでも違反されている場合には、取引を許可するために親カードのカード保持者に連絡をとることができる。

例えばプロフィール調査モジュール７２０は、一（又は複数）の子カードにそれを制御する親カードを関連付けるテーブルにアクセスすることによって動作させることができる。プロフィール調査モジュール７２０は、テーブルを調べてカード識別子（まず第３の復号ユニット７１２により検索）が親カードに対応するものとして提示されたかどうか判定することができる。そこで発見されない場合、このカードは子カードではないので、親カードが課す規約に関連付けされることは一切ない。そうではなく発見された場合、それは子カードであるので、関連する規約を有するであろう。この種の状況にあっては、前述のテーブルは前述の値にそのカード向けに選択された規約を実行する実行可能なコードを指し示すポインタを関連付けるさらに別のテーブルへの鍵として使用可能な値を子カードに関連付けることもできる。実行可能なコードがそこで実行されて、前記したように規約が違反されたかどうか判定される。

残高調査モジュール７１４、不正調査モジュール７１６、プロフィール調査モジュール７２０のいずれかが取引を許可すべきでないと示す場合には、制御は拒絶／凍結モジュール７２２へ移行する。拒絶／凍結モジュール７２２は取引を拒絶し、提示取引が拒絶されたことを示すメッセージを販売時点管理装置へ送信する（販売時点管理装置へのこの種のメッセージ返信の仕組みに関する詳細は下記に示す）。加えて、不正調査モジュール７１６がその購入が不正であることを示す場合には、そのカードに関連する口座は凍結され、そのカードが再び有効になるまで将来の一切の取引が許可されないこととなる。

残高調査モジュール７１４、不正調査モジュール７１６、プロフィール調査モジュールのそれぞれが取引を許可すべきであると示す場合には、制御は取引記録モジュール７２４へ移行する。取引記録モジュールは、レベル３データを含む３個の復号モジュール７０４，７１０，７１２が復号したデータをデータベース７０６へ入力する。例えば、販売業者が割り当てるものとは異なる取引識別子が、取引に割り当てられる。新規に割り当てられた取引識別子が識別する新規の記録が、取引に関連する詳細に新規に割り当てられた取引識別子を関連付けるテーブル内に作成される。その後、レベル３データを含め３個の復号モジュール７０４，７１０，７１２が再生するデータを用いて新規記録の各種フィールドが埋められる。（販売業者の取引識別子もまた新規に割り当てられた識別子に関連して前述のテーブル内に記憶させられ、それによって取引プラットフォームの取引識別子と販売業者の取引識別子との間の関連が保存される）。

前記したように、販売業者に配置された販売時点管理装置は取引の拒絶／承認を通知される。一部実施形態によれば、図９に示す構造を有するメッセージがＳＳＬモジュール７０２とＴＣＰ／ＩＰモジュール７００を介して販売業者のサーバ４０２上で実行する前述のカーネルへ送信される。図９からわかるように、このメッセージは提示された取引が承認あるいは拒絶されたかどうかの表示９００と販売業者により割り当てられた取引識別子９０２と販売業者識別子と店舗識別子とレジ識別子９０４とを含む。

図９のメッセージはカーネルのＴＣＰ／ＩＰモジュール５２８により受け取られ（図５）、ＳＳＬモジュール５２６へ送られ、そこで復号される。そのペイロードが承認モジュール５３０へ転送され、これがＡＰＩ５０４を用いて承認あるいは拒絶に関する情報でもってデータベース４０４を更新する。（提示取引が承認あるいは拒絶されたかどうかを示す９００には、図９のメッセージに含まれる販売業者の取引識別子９０２が関連付けてある）。一部実施形態によれば、販売業者のサーバ４０２にカーネルを実装する時点で、承認モジュール５３０はこの種情報の入力用に適当なテーブル及びフィールド名を含むよう変更される（例えば、承認モジュール５３０のコード及び／又はデータ空間はこの種の情報の入力に適した場所のテーブル名とフィールド名を含むよう変更される）。その後、販売業者識別子や店舗識別子やレジ識別子９０４を用いて適当な販売時点管理装置２０２に対する拒絶／承認に関する情報をどのように配信するかの決定に使用され、取引識別子を用いて適当な取引を拒絶／承認する。

前述の説明に記載したように、一部実施形態によれば、所与の取引の対象であるレベル３データが収集され、取引の実行と同時に所定時点で図７のソフトウェアシステムへ通信され、データベース７０６内に記憶させられる。これが、本発明の実施に不可欠ではないが特記すべき幾つかの利点を提供する。例えば、レベル３データは取引の実行期間中に捕捉されてデータベース７０６内へ入力される（取引後の実行とは対照的に）ため、ソフトウェアシステムはレベル３データを調べ、この種のレベル３データを各種規約と比較対照し、提示取引を承認あるいは拒絶すべきか判定する。下記に説明するように、カード保持者は特定の商品や商品分類や商品範疇が取引の対象である場合に潜在的に不正であるとして提示取引を識別する不正検出規約を選択することができる。明らかに、取引の対象となる商品の自己識別特徴に関するデータが取引実行後まで欠落しあるいは収集されていないかのいずれかである場合、この種規約を課すことはできない。下記にも説明するように、カード保持者は「子カード」からの許容可能支出を規定する規約を特注することができる。例えば、カード保持者は特定の商品あるいは商品分類がその対象となる取引の実行を子カードが禁止されていることを特定することができる。ここでも、所与の取引の対象となる商品の自己識別特徴に関するデータが取引の実行後まで欠落あるいは収集されないかのいずれかである場合、この種規約を課すことはできない。最後に、レベル３データを収集し、取引と同時に記憶させるため、カード保持者には彼又は彼女のカードに関連するあらゆるカードを用いて購入された品目（例えば、子カードを介して購入された品目を含む）の自己識別特徴及びこの種の取引を行ったカード番号の自己識別特徴に関する情報を提示することができる。この種の情報は、ウェブサイトあるいはコールセンターを介して実時間であるいはほぼ実時間で提供することができる。

一部実施形態によれば、データベース７０６は図８に示すように編成することができる。図８から見て取れるように、データベースはカード番号８００、すなわち取引カードの記憶媒体上にエンコード／記憶／収容され、そのカードを一意的に識別するデータ群にカード識別子８０２を関連付けることができる。カード識別子８０２は、データベース７０６内のカード番号８００に一意的に関連付けられたデータ群（例えば、整数）である。カード識別子は片や、主口座番号８０４に関連付けてある。

主口座番号８０４は、取引カードを介してアクセスすることのできる各口座の全ての口座情報８０６を一意的に関連付け、カードを介してアクセスすることのできる全てのカード保持者情報８０８もまた関連付けるデータ群である。例えば、主口座番号にはカードを介してアクセスすることのできる各口座の残高が関連付けられている。かくして、これに（カードをクレジットカードとして使用する際に）信用残高を、（カードをデビットカードとして使用する際に）銀行口座残高を、かつ／又は（カードをストアードバリューカード、例えばギフトカードやプリペイド商品及び／又はサービスカード等として使用する際に）ストアードバリュー残高を関連付けることができる。主口座番号８０４には全ての詳細、例えばカードを介してアクセスすることのできる各口座を介して行われる全ての取引のレベル３データを関連付ける。さらに、主口座番号８０４にはカードを規定する各規約、例えば利息規約や延滞料金規約や不正検出規約や子口座支出規約を関連付けてある。さらにまた、主口座番号８０４にはカードを通じてアクセスすることのできる各口座に結び付けられた金融状況に関する情報、例えば信用供与をクレジットカードとしてのカード使用にまで拡張する銀行に関連付けてある。一般に、クレジットカードやデビットカード及び／又はストアードバリューカードとしてカード容量に必要とされかつ／又は関連付けられる各データ単位は、直接又は間接のいずれかで主口座番号に関連付けられる。

前述の構成は、本発明にとって不可欠ではないが特記すべき幾つかの利点を呈する。例えば、カード番号８００に関連する取引カードが盗難にあったと仮定すると、カード番号８１０等の別のカード番号を有する別のカードを（新規カード識別子８１２により）主口座番号に再関連付けすることができる。こうすると、全ての口座情報８０６とカード保持者情報８０８は所定場所に止まり、この種の情報は一切失われない。

図８の構成において本来的に別の利点が発生するということは、本発明の実施に不可欠ではないが特記すべきことである。図８に示すように、２個以上のカード番号８００，８１０を同じ主口座番号８０４に関連付けることができる。その結果、カード保持者は２枚の取引カード、すなわち例えば１枚が個人使用向けで１枚が仕事向けに所有するよう選ぶことができる。（本例では特定の主口座番号８０４に関連する二つのカード番号８００，８１０を説明するが、任意の数のカード番号８００，８１０を同じ主口座番号８０４に関連付けることもできる）。かくして、一回の明細あるいはウェブページはカード保持者に口座の破綻８１４を提示し、例えば各カードごとの総支出を示し、あるいはカードごとの全てのレベル３データ（例えば、それに関連する各品目と経費）を取引単位を基本に提示することすらできる。

一部実施形態によれば、取引は取引カードを使用することなく行われてもよく、むしろ携帯電話及び／又は個人的携帯情報機器等の無線装置を介して行われる。図示する目的のみにより、下記の例示実施形態を携帯電話を参照して説明する。先に説明したように、取引は販売時点管理装置２０２にて始められ、ここで購入する品目に関連するバーコードが係員により走査される。この時点で、係員はカード保持者に彼の携帯電話番号を尋ね（そうでなければ、携帯電話番号を取得、例えばカード保持者にカード保持者の携帯電話番号を捕捉する特定の番号に掛けさせ、販売時点管理装置２０２へ通信させるか、その電話番号を販売時点管理装置２０２や販売時点管理装置２０２及び／又は販売業者のサーバ４０２のいずれかと交信状態にあるコンピュータシステムへ通信させ）、携帯電話番号を販売時点管理装置２０２へ入力する。

販売時点管理装置２０２はそこで、図５を参照して前記したように、レベル３データをデータベース４０４内へ入力する。ここでも、このことで監視モジュール５１２は取引テーブル５０６内で新規取引識別子５０８の作成を監視し、それによって下記を除き前記した事象群を伝搬させる。第１の暗号化モジュール５２０はカード保持者の携帯電話の電話番号を用いてレベル３データを暗号化し、図１０に示すように第１の暗号化オブジェクト１０００を作るよう指示する。次に、第２の暗号化モジュール５２２が携帯電話番号を第１の暗号化オブジェクトに添付（カード番号をそこに配置する代りに）し、添付データ群を先に説明したように販売業者のパスワードをもって暗号化し、第２の暗号化データ群１００２を作る。残りのカーネル機能は、先に説明した通りである。

取引プラットフォームのサーバでは、大半の処理は下記を除き図７を参照して前記したものと同様である。第１の暗号化オブジェクトと添付データとを送ると、第３の復号ユニット７１２は携帯電話番号がカード番号の所定箇所に挿入されていることを検出する（例えば、携帯電話番号と取引カード番号が異なる長さであると言う事実により、この種の検出を行うことができる）。携帯電話番号をカード番号の所定箇所に挿入されたことを検出すると、第３の復号ユニット７１２は携帯電話番号を復号鍵として使用し、第１の復号オブジェクトを復号する。その後、第３の復号ユニット７１２は携帯電話番号をもってＳＭＳモジュール７２８を起動する。ＳＭＳモジュール７２８はそこに提供された電話番号へＳＭＳメッセージを送信する。ＳＭＳメッセージは、取引の全額と提示取引を実行しようとする販売業者店舗の名前を示す。このメッセージがユーザに取引を確認するかあるいは拒否するかのいずれかを促す。ユーザが取引を確認した場合、彼は彼のＰＩＮを電話へ入力し、アプレット及び／又は他形式の実行可能なコードがＰＩＮにユーザのカード番号を束ね（アプレット及び／又は他形式の実行可能なコードはカード番号をそのコード又はデータ空間内に含むよう先に変更され）、提示取引を確認すべきことを示す応答を生成し、そこにユーザのカード番号とそれに関連するＰＩＮを含める。一部実施形態では、取引を確認しあるいは拒否する応答メッセージは装置が規定する無線インターネット接続を介して通信され、ＳＳＬプロトコルを介して暗号化される。応答メッセージは、第３の復号ユニット７１２へ返信される。応答メッセージが取引を拒絶した場合、そのときは図７を参照して前記したように取引は拒絶される。他方で、応答メッセージが取引を承認する場合、そのときは第３の暗号化モジュール７１２がデータベース７０６にアクセスし、前述のようにカード番号に基づきユーザのＰＩＮを検索する。検索されたＰＩＮが携帯電話に入力されＳＭＳモジュール７２８を介して第３の暗号化モジュール７１２へ送られたＰＩＮに一致した場合、そのときは処理は図７を参照して前述したように継続する（すなわち、残高調査と不正検査とプロフィール調査が例によって行われる）。

前述の効果は、カード保持者がただ彼の携帯電話番号を販売時点管理装置２０２の係員へ提供するだけで購入を取引できる点にある。一（又は複数）の品目が係員により走査された後、カード保持者はＳＭＳを受け取り、カード保持者が総額の修正を確認するよう要求する。カード保持者は、ＳＭＳに対し肯定的に応答することで確認し、彼のＰＩＮを入力する。

一部実施形態によれば、カード保持者は携帯電話等の無線装置を用い、図５のカーネルと交信するよう構成された無線の販売時点管理を持たない売主と取引することができる。無線は、アプレットを用いてプログラムして取引の総金額と販売業者識別子とカード保持者の取引カードに関連するＰＩＮ番号の入力を可能にする。一部実施形態によれば、アプレットはカード保持者のカード番号へのアクセスを有する実装にて構成してある。アプレットはそこで、カード番号と販売業者識別子と取引の総額と取引種別を記述する取引種別データユニットとをパケット内へ複合し、このパケットをまず暗号鍵としてＰＩＮを用いて暗号化し、続いてＳＳＬを用いて暗号化する。図７のソフトウェアシステムでは、パケットはまずＳＳＬモジュール７０２により、続いて第３の復号モジュール７１２により復号される。その後に、処理は前述したように進行する。

先に説明したように、図５のカーネルと図７のソフトウェアシステムは協働して各種の取引を実行でき、図６の暗号化搬送オブジェクト内に担持されたデータを可変することでこの種各種取引を達成することができる。例えば、前述の基盤は協働して「私的クラブ購入」を行うことができる。私的クラブ購入は、会員資格を必要とする販売業者（例えば、Ｓａｍのクラブ、映画貸し出し店等）にて行われる購入である。例えば、個人が映画レンタル店から映画を借りたいと望む筋書きを考える。この種店舗は通常、購入を行うためには会員カードの提示を必要とする。会員カードは通常、会員口座に関連する番号をエンコードする記憶媒体（バーコードや磁気帯片等）を担持している。この種の会員カードは、ここでの基盤に鑑み陳腐化している。

最初のステップとして、カード保持者は彼の会員口座番号（あるいは彼の会員カードの記憶媒体にエンコードされた番号等のそれに関連する他の識別番号）に彼の主要口座を関連付けることができる。彼の映画を借りるときに、カード保持者はここに開示した種の取引カードを提示し、映画の貸し出しの購入と彼の会員口座の提示の両方を行う。従業員は前述したようにカードを機械にさっと通し、前記事象を始動させる。しかしながら、この文脈では、取引種データは私的クラブ購入が行われていることを示す値に設定される。（レベル３データは借りようとしている映画の題名等を記述するデータを担持している）。すなわち、映画貸し出し販売業者を識別する販売業者識別子を有する暗号化搬送オブジェクト、特定の店舗を識別する店舗識別子、特定の販売時点管理装置を識別する販売時点管理装置識別子、説明したばかりのレベル３データ、説明したばかりの取引種別データを有する暗号化搬送オブジェクトが、図７のソフトウェアシステムへ通信される。

暗号化搬送オブジェクトを受け取ると、システムを担持するオブジェクトは下記を除き前記したように振る舞う。すなわち、システムは私的クラブ会員番号（又はそれに関連する他の番号）に主口座とカード識別子を関連付けるデータベース７０６内のテーブルへアクセスする。システムは、前述の会員番号を取得し、そこに示した要素に加え図９の応答パケット内のその番号を返信する。このため、販売時点管理装置は金融取引に関する承認／拒絶情報を提供され、またカード保持者の会員番号もまた提供される。かくして、２枚のカードを用いて私的クラブ取引を完了する必要性は排除される。

前述の基盤は、データ取得取引の実行に使用することもできる。データ取得取引は、カード識別子と主口座に関連する情報を取得するのにカードを使用する取引である。この種被検索情報は、単純化し得る。例えば、被検索情報は個人が実際に一つの組織の会員であるかどうか（例えば、個人が健康クラブの会員であるかどうか）を示すようにもできる。そうでなければ、この情報はカード保持者の健康情報を示すように複雑化することもできる。データ取得取引の文脈では、基盤は前述したように下記の例外をもって振る舞い、それを健康管理施設（病院や診療所等）へ健康管理を提供する彼のカードを用いるカード保持者を参照して説明する。

まず初期事項として、カード保持者はどの種のデータを検索できるかを識別する一群の規約をデータベース７０６内に規定する。例えば、この規約はそれらの個々の販売業者識別子により識別される各種機関によりカードから検索することのできる健康管理データから検索することができる。

健康管理施設では、カードを機械に「通して」その上の記憶媒体を読み取り、前記した一連の事象が生起する。しかしながら、この文脈では、カード保持者は無意識であり、かくして入力すべきＰＩＮを「９１１」としたり、あるいは他の何らかの予め定められたＰＩＮとすることができる。取引種別データは、データ取得取引が実行されていることを示す値に設定する。（記憶識別子と販売時点管理識別子レベル３データは存在しないかあるいはダミーデータを充填できるが、一部事例では、これらのフィールドを埋めて応答メッセージを健康管理施設内の適切な取引実行装置へ配信できるようにしてある）。かくして、健康管理施設とカード番号と説明したばかりの取引種別データを識別する販売業者識別子を有する暗号化搬送オブジェクトが、図７のソフトウェアシステムへ通信される。（ここでも、幾つかの事例において、店舗識別子と販売時点管理識別子にて埋めることができる）。

暗号化搬送オブジェクトを受け取ると、システムは下記を除き前記したように動作する。販売業者識別子が健康管理施設に対応し、取引識別データがデータ取得取引に対応すると識別すると、第３の暗号化モジュールはレベル３データが存在しないが故に迂回される。そこで、ソフトウェアシステムはデータベース７０６にアクセスし、販売業者識別子に関連するデータへのアクセスを規定する規約を取得する。例えば、データベース７０６には各販売業者識別子や主口座やデータ取得取引に応答してそこへ返信することのできるカード保持者データを有するカード識別子に関連するテーブルを含めることができる。ソフトウェアシステムはそこで規約を実行し、規約を与えられることで健康管理施設へ返信するよう許可されたデータを返信する。かくして、ここに説明する取引カードは任意の各種組織へ任意の各種情報を供給するのに使用することができる。

前述の取引を実行できるようにするため、図７のフロントエンドモジュールはカード保持者がログインするウェブサイトを提供することができる。ウェブサイトはまたカード保持者が、健康管理データ、保険データ、クラブ会員データ、ユーザ専用データを含めた他の任意のデータを含む任意のデータを彼のカードに関連付けられるようにする。ウェブサイトはまた、カード保持者を例えば販売業者単位（事業者単位）に基づきこの種データに対するアクセスを規定する規約へ関連付けることができるようにする１以上のウェブページ構造を提示する。

図２〜図１０について説明したシステムの一部特徴は特記すべきものであるが、本発明の実施にとって不可欠のものではない。例えば図２から分かるように、取引システムは交換関係者を一切含まず、それゆえそれに関連するシステム構成要素と課金は排除される。例えば、図１のシステムとは対照的に、図２のシステムが私的ネットワーク回線や要素を一切必要としないことが分かる。かくして、この種ネットワーク回線及び要素の作成と保守に責任を負う交換関係者は、取引の実行過程から排除される。それ故、それらの交換サービスを提供する販売業者が通常負担する経費は取り除かれる。しかしながら、一部実施形態によれば、最小数のネットワーク回線及び／又は要素を活用することができる。

取引プラットフォームが維持するデータベースは、信用限度や不正規約や銀行間あるいは団体間に基づき通常課せられる他の規約を含めるフィールドを有するテーブルを含む。図７のソフトウェアシステムは、カード保持者とカード発行銀行によるデータベースへアクセスできるフロントエンド７２６を含む。カード発行銀行は規約、例えばフロントエンドモジュール７２６を介して所与のカード番号に関連する信用限度や不正検出規約等を設定することができる。カード発行銀行により設定された規約は、規約を適用するカード番号に関連してデータベース７０６内に収容される。そのため、取引プラットフォームのサーバは取引を拒絶あるいは承認する目的でカード発行銀行の情報システムを用いて各提示取引を通信する必要はない。その代りに、期間中に１以上の取引を個別に承認した後、取引プラットフォームのサーバはカード発行銀行の情報システムを定期的（例えば、日常的を基本）に更新することができる。

本発明の実施に不可欠ではないが特記すべき点は、データベース７０６にカード識別子を銀行識別子へ関連付けるテーブルを含まることができる点である。銀行識別子は、所与のカードに対応する金融機関の自己識別情報を示す。前述のテーブル内の銀行識別子を単純に変更することで、所与のカードに関連する銀行は変更される。このようにして、カード保持者はクレジットカードの切り換えを迫られることなく一つの銀行から別の銀行へ自分の残高を効果的に送金することができる（取引プラットフォームは単純に銀行識別子を変えるだけである）。

同様に、データベース７０６にはカード種識別子にカード識別子を関連付けるテーブルを含ませることができる。カード種識別子は、カードにより裏付けられた一（又は複数）の取引の種別を識別する。すなわち、カード種別識別子はカードがクレジットカードかデビットカードかストアードバリューカードか健康管理管理カードか他形式のカードか、あるいは前記の一部又は全部の組み合わせかどうか示すものである。すなわち、例えば一つの文脈において単一の取引カードをクレジットカードとして使用し、別の文脈においてデビットカードとして使用することができる。換言すれば、データベース方式はカード番号をカードの記憶媒体に記憶させデータベース７０６内に入力するメカニズムを提示し、カード識別子に関連付ける。カード識別子は他方、カードが裏付ける取引種を識別するカード種別識別子あるいはカードを介してアクセスする情報に関連するものである。カード種別識別子とカード識別子は、カードをクレジットカードやストアードバリューカードや健康情報カード等として機能するようにすべく編成し埋めたテーブル群に関連するものである。

例えば、前記したように、データベースはカードをクレジットカードとして機能させるに十分な情報を含むテーブル群を含む。これらのテーブルは、他の情報の中でもとりわけ、カードの信用限度に関する情報やカードに関する利息規約やカードに関する延滞手数料規約やカードに関連するカード発行銀行の自己識別情報やカード発行銀行の情報システムとの接触を可能にするアドレス情報（例えば、ＩＰアドレスやポート情報や物理アドレス等）や同様の情報を含む。これらのテーブル内のデータはカード保持者が使用することで所与のカードに関連付けることができ、すなわちカード識別子はこれらのテーブル内の鍵として使用することができる。

第２群のテーブルにより、カードをデビットカードとして機能させることができる。これらのテーブルは、他の情報の中でもとりわけ、カードに関連する口座の口座番号と配信番号の検査や検査口座の残高に関する情報や類似の情報を含む。ここでも、これらのテーブル内のデータはカード保持者が使用することで所与のカードに関連付けることができ、すなわちカード識別子はこれらのテーブル内の鍵として使用することができる。

第３群のテーブルにより、カードをストアードバリューカードとして機能させることができる。ストアードバリューカードは、プリペイド商品やサービスに対してアクセスできるようにするカード（例えば、プリペイド電話カードやギフトカード等）である。これらのテーブルは、他の情報の中でもとりわけ利用可能な残高に関する情報や残高を使用することのできる一（又は複数）の商店や残高使用時のあらゆる制限に関する規約や類似の他の情報を含む。ここでも、これらのテーブル内のデータはカード識別子を使用して所与のカードに関連付けることができ、すなわちカード識別子をこれらのテーブル内の鍵として使用することができる。

さらに別のテーブル群により、カードを健康記録アクセスカードとして機能させることができる。健康記録アクセスカードは、図７のデータベース７０６等のデータベース内に記憶させた健康情報へのアクセスを可能にするカードである。これらのテーブルは、他の情報の中でもとりわけカード保持者が保持する健康保険、カード保持者が保持する歯科保険、カード保持者の生命統計値、カード保持者のアレルギー、カード保持者が受けた外科処置、カード保持者の医師ならびに他の健康管理プロバイダに関する情報や、個人健康記録、電子的健康記録、支払い破産宣告、分担金計算、ならびに清算や他の情報等を含む。ここでも、これらのテーブル内のデータにはカード識別子を用いて所与のカードを関連付けることができ、すなわちカード識別子はこれらのテーブルにおける鍵として使用することができる。

図３について説明したように、有効な取引カードを申請人が所有できるように迅速に配布するための方式は先に説明した。図１１は、現在のカード保持者が取引プラットフォームに代わって取引カードを配布することができ、そのことにより報奨金を受け取ることのできる方法を示すものである。取引カードの配布者として活動したいカード保持者は、無記名の未割当取引カードの供給を要請することができる。これに応じ、取引プラットフォームはこの種の未割当無記名カードをカード保持者に提供する（処理１１００）。処理１１０２に示すようにこのカード保持者は、無記名カードの一つをカード保持者になりたいだろうと考える理由のある人物（友人や同僚等）へ配布する。このような配布の前あるいは後に、データベース７０６内で配布カードとカード保持者を関連付ける（処理１１０４）。例えば、そのカードを配布した相手のカード保持者に対応する配布された無記名カード及びカード識別子のそれぞれのカード番号を関連付けるようテーブルを埋めることができる。このテーブルには、カード保持者が未割当カードを配布する人物（すなわち、将来の申請人）を識別する情報が含まれるよう埋めてもよい。処理１１０４は、例えばフロントエンドモジュール７２６により提示されるウェブサイトにおいて、カード保持者により行われることができる。

処理１１０４の後、図３を参照して説明するように申請に関する処理が進行する。しかしながら、処理１１０６に示すように、カード保持者が無記名カードを供給した相手の人物が承認されたとき、申請人の識別情報が処理１１０４においてカード保持者が供給する識別情報に合致した場合には、配布カード保持者の口座に報償ポイントが付加される（これにより、カード保持者が例えばショッピングセンターにおいてそこから生ずるあらゆる申請に対し貸し付けられることを期待して大量の未割当取引カードを要求することを防ぎ、山積みのカードを残さないようにできる）。また、報償ポイントに加え、あるいはこれに代えて、カード保持者の口座に金額総額を貸し付けることができる。処理１１０２において行われる関連付け処理により、取引プラットフォームのサーバは報償ポイントを加算するカードを適切に識別できる。申請人のカード承認時に、取引のプラットフォームのソフトウェアシステムは承認されたばかりのカード番号がこの種のカード保持者のカード識別子に関連するかどうか判定すべく、カードを受け取って配布されたカード保持者のカード識別子に未割当カード番号を関連付けるテーブルを調査することができる。それが関連する場合には対応するカード識別子が取得される。次に、カード識別子を主口座に関連付けるテーブルにアクセスし、カードを配布したカード保持者の主口座を取得することができる。その後、主口座番号に対する報償ポイント残高に関するテーブルにアクセスし、ポイント残高を更新して追加の報奨ポイントを反映する。

一部実施形態によれば、たとえカード保持者がカードを供給した人物を拒絶したとしても、配布カード保持者の口座にはポイントが供給される（処理１１０８）。一部実施形態によれば、報償ポイントを販売業者によりこの種の用途に割り当てられた品目に対して使用可能としても、あるいは一般的な報奨プログラムの文脈において使用可能としてもよい。一定の金額がカード保持者の口座に授与された場合には、その金額をあらゆる商品やサービスに使うことができる。

図６を参照して説明するように、一部実施形態の取引システムにより所与の取引を記述するレベル３データの通信が可能になる。例えばカード保持者が、石鹸、ソーダ、紙タオルを総額１５ドル取引したと仮定すると、図５のカーネルから図７のソフトウェアシステムへ通信される情報は、総額１５ドルについて価格８ドルの石鹸と、価格４ドルのソーダと、価格３ドルの紙タオルを含む取引であると識別する情報を含む。図７のソフトウェアシステムは情報を受け取り、前述したように、１５ドルの取引を識別する取引識別子を作成する。各購入品目（及びそれに関連する経費）は、取引識別子を関連付けられる。すなわち、この種実施形態によれば、データベース７０６は特定の販売業者や商店や各購入品目や各購入品目経費や取引総額に関するデータを含む。この種のレベル３データの提示により、これまで不可能とされた幾つかの機能が可能になる。

レベル３データの提示により可能となる機能の一例は、疑義解決策の向上に関する。今日、クレジットカードの保持者が自分の明細を点検して特定の課金が多すぎると考える場合に、カード保持者はその課金に疑義を挟むことができる。先の例を続けると、カード保持者が受け取る明細が、取引を１５ドルではなく総額２５ドルであると提示していた場合、カード保持者は自分のクレジットカード会社に連絡をとって取引が総額で２５ドルではなく１５ドルのはずだと言明することができる。その結果、２５ドルのうち１０ドルだけが問題である、すなわち自分が２５ドル借りているとは思っていないとしても１５ドルは借りがあるとカード保持者が認めているという事実にもかかわわらず、２５ドルの取引全体が疑義があると識別されてしまうかもしれない。一部事例では従来のクレジットカード会社が取引内容に関する詳細情報を受け取らないために、また別の事例では従来のクレジットカード会社が採用するソフトウェアシステムが特定の品目に関連する経費の係争を規定していないために、取引全体に疑義を挟む必要がある。この疑義に応じてカード発行銀行はカード保持者の残高から２５ドルの取引を（この疑義が解消されるまで）除外し、その取引については販売業者の銀行へ資金を全く送金せず、カード保持者が彼が実際借りていると認める１５ドルまでも送金しない。このようにして、疑義のある１０ドル分が解決されるまで、取引業者は両当事者が借りていると認める１５ドルをも受け取ることができない。

図１２の方法によれば、単に取引単位に基づくのものとは対照的に、品目単位に基づいて疑義を記録することができる。図１２に示すように、疑義のある品目に関する情報をカード保持者から取得することができる（処理１２００）。例えば、カード保持者は取引プラットフォームの従業員に電話をし、疑義のある品目を説明することができる。例えば、カード保持者は日付と販売業者と疑義のある品目を説明することができる。通常、カード保持者はレベル３データの全量を列挙して疑義のある品目を一意的に特定することができる。従業員は、その特定の取引と疑義のある品目が識別されるまで、提供されたレベル情報を用いてデータベースにアクセスする。（取引対象である特定の品目に関連する特定の費用を識別する処理は、フロントエンドモジュール７２６が提示するウェブサイトを介して行うことができる。例えばログイン後に、カード保持者は取引内の品目に疑義を挟むオプションを選択することができる。ウェブサイトはそこで一連のフィールドを提示し、カード保持者が特定の品目に疑義を挟めるようにする。例えば、ウェブサイトはカード保持者が特定の期間内、例えば所与の日に行われた全ての取引を調査できるようにする第１のフィールドを提示することができる。これに応答して、一群の取引概要、例えば日付や販売業者や総額により識別される取引リストをユーザに提示することができる。特定の概要を選択することにより、取引対象である各品目とそれに関連する費用のリストを提示させることができる。特定の費用について疑義を挟むべく、カード保持者は疑義を挟む品目を選択し、それに関連するフィールド内へ疑義の説明を入力することができる。）従業員との電話での会話を通じて疑義が挟まれた例に戻ると、疑義品目が構成する取引の取引識別子を発見する（処理１２０２）。次に、識別された取引の識別された品目に関連する費用に疑義を挟むべく、１以上のテーブル内に一つの記録を作成する（処理１２０４）。例えば、明細が品目の購入額をカード保持者が本当の価格と確信するものとは異なる価格で反映している場合、この記録では一つの品目に関連する価格に疑義を挟むことができる。また、カード保持者がその品目の購入を完全に否定している場合、この記録は品目に関連する費用に疑義を挟むことができる。疑義を記述する記録には、疑義品目の説明と所与の品目に関連する費用に疑義を挟むカード保持者の根拠に関するデータフィールドを含めることができる。疑義品目に関連する費用は、疑義が解消される時点までカードに関連する残高から取り除かれる（処理１２０６）。疑義解消時に（本開示範囲を逸脱するも、当業者には理解される）、カードに関連する残高に対し適切な金額を払い戻すことができる。最後に処理１２０８に示すように、解決対象である疑義テーブル内へ、処理１２０４にて作成された記録への参照を入力することができる。

レベル３データの収集から得られる別の機能は、支払い明細の分析達成することができることである。一部実施形態によれば、レベル３データの一部又は全てを請求明細に含めることができる。一部実施形態によれば、カード保持者は自分のカードに関連する明細に提示されるレベル３データの量を選択することができる。例えば、フロントエンド７２６（図７）はカード保持者が自分の明細に提示する詳細のレベルを選択できるようにするウェブサイトを提示することができる。ウェブサイトにより、例えばカード保持者は提示された全ての利用可能なレベル３データを示すことができる。この場合、明細はこの明細に提示された各取引ごとに収集された全てのレベル３データを提示する。ウェブサイトはユーザに所定種のレベル３データだけ、例えば商品／サービスの説明や商品／サービスの分類や商品／サービスのＳＫＵ等の説明だけを選択して提示できるようにもできる。かくして、明細には各取引ごとに各取引を構成する商品／サービスと各取引を構成する各商品／サービスの分類と各取引を構成する各商品／サービスのＳＫＵ等のそれぞれの説明を提示することができる。無論、ウェブサイトはユーザに彼の明細に３レベルデータが一切提示されないよう選ばせてもよく、この場合明細は通常の取引情報（取引の販売業者と日付と総額）を提示する。

図１３は、子カードを規定する１以上の規約を設定する方法を示すものである。前記したように、子カードは親カードの下位口座の口座に対応する。親カードのカード保持者は、例えば図７のソフトウェアシステムのフロントエンドモジュール７２６が提示するウェブサイトへログオンすることにより、子カード用に１以上の規約を設定することができる（処理１３００）。例えば一部実施形態によれば、ウェブサイトはウェブサイトへログイン中のカード保持者のカード番号を入力するフィールドを提示する。ウェブサイトはまた、カード番号に対応するパスワード及び／又はＰＩＮを入力するフィールドを提示する。カード保持者は、自分のカード番号とパスワード及び／又はＰＩＮを入力してログインする。それによって図７のソフトウェアシステムは、ウェブサイトの特定のユーザが特定のカード番号に対応するものとして識別する。そうでなければ、ウェブサイトはカード保持者に関連する（ひいては彼のカード番号等に関連する）ユーザ名を入力するフィールドと、パスワードを入力する別のフィールドとを提示することができる。ログインは、これらのフィールドにおけるデータ入力時に実行される。

ログイン時に、カード保持者には自分の口座に含まれるオプションメニューが提示される。例えば、カード保持者が残高を含む自分の明細の実時間提示を調査し、他方、自分のカード番号に関連するあらゆる口座に関連する最近の取引を調査し、自分のカード番号に関連する医療情報や保険情報等の情報を調査及び／又は入力し、彼のカード番号を規定する個人特化不正規約を設定し、時間の経過と共に彼のＰＩＮを自動的に変更するよう規約を設定しかつ／又は自分の親口座に対応する子口座を規定する規約を設定できるようにするメニューを、カード保持者に提示することができる。処理１３０２に示すように、カード保持者は子口座を規定する規約を設定するオプションを選択する。処理１３０４に示すように、この種の指定に応答してウェブサイトは処理１３００にて入力された親カード番号に対応する子カード番号のリストを提示する。例えば、図７のソフトウェアシステムは、子カード番号を親カード番号に直接あるいは間接のいずれかで関連付けるデータベース７０６内の特定のテーブルを調べる。処理１３００中に入力された親カード番号に関連する全ての子カード番号が、識別されて提示される。一部実施形態によれば、子カードに関連するカード保持者の名前もまた提示される。親カード保持者はそこで、リストからカード番号を選択する（処理１３０６）。

その後、ウェブサイトは子カードに適用可能な規約をカスタマイズするフィールドを提示する。例えばウェブサイトは、親が子口座に規約を関連付けるフィールドを提示し、指定された単位時間ごとに指定されたレベルまでの負債（例えば、毎月２５０ドル）を子口座が負えるようにする。他の規約は、無制限に下記を含む。すなわち、（１）所定のＳＫＵやＳＫＵ分類やＳＫＵ範疇の購入が出来ないようにする（例えば、ＳＫＵの購入を禁止し、購入された品目がアルコールであることを示す）、（２）所定の販売業者や業者種別及び／又は販売業者かてごりにおいて行われる購入を禁止する、かつ／又は（３）所定の販売業者において行われる購入だけを許可する。カード保持者は子カードに対して適用する規約を選択し、関連した規約データを入力する（例えば、カード保持者が子カードを１月当たり２５０ドルの限度に制限したい場合、そのときは「２５０」を出費限度フィールド内に、「月」を単位時間内に、例えば頻度プルダウンメニューから選択して入力することができる）（処理１３１０）。最後に処理１３１２に示すように、子カードに処理１３１０で選択される規約を関連付ける。

図１３を参照して説明したように、カード保持者は彼のカード及び／又は子カードに割り当てる不正トリガーを選択することができる。子カード用に規定された規約についても当てはまるように、不正トリガーは例えば図７のソフトウェアシステムのフロントエンドモジュール７２６が提示するウェブへのログオンにより規定することができる（処理１４００、図１４）。直前に説明したように、一部実施形態によれば、ウェブサイトはそのウェブサイトにログインしようとしているカード保持者のカード番号を入力するフィールドを提示する。ウェブサイトは、カード番号に対応するユーザ名やパスワード及び／又はＰＩＮを入力するフィールドもまた示す。カード保持者は、彼のカード番号とパスワード及び／又はＰＩＮを入力してログインする。図７のソフトウェアシステムはそれによって、特定のカード番号に対応するものとしてウェブサイトの特定ユーザを識別する。

図１３を参照して説明したように、ログイン後に、ユーザは不正トリガーの特化を可能にする選択肢を選択する。その後に、ウェブサイトはカード保持者にカードに適用することのできる不正トリガーの各種分類を提示することで応答する（処理１４０２）。例えばボックス１４０４内に示すように、ウェブサイトはカード保持者へ、下記を指定するためにデータ入力可能なフィールド群を提示することができる。（１）単位期間当たりに支出することのできる最大金額。この限度を上回る支出は全て不正と見なされ、例えば１日で５０００ドルを超える支出は全て不正であると見なされる。（２）一回の取引での最大購入額。この最大購入額を上回る支出は全て不正であると見なされ、例えば５０００ドルを超える支出は全て不正であると見なされる。（３）不正であると見なされる特定の商品群。例えば宝飾品を購入しようとしていることを示すＳＫＵを有するレベル３データを含んだ取引は不正であると見なされる。（４）所与のパーセントを超える支出の増額。例えば図７のソフトウェアシステムは直近のＮ（Ｎ＝３０，６０，９０等）日にわたる所与のカード保持者の支出を追尾可能であって一日当たりに支出された中間額又は平均額を算出可能であり、その平均及び／又は中間額を指定されたパーセントを超えて上回った一日あたりの支出は不正であると見なされる。（５）指定された販売業者分類、例えば宝飾店での購入は全て不正であると見なされる。（６）指定された特定の販売業者、例えば指定された販売業者に対応する販売業者識別子を有する取引は全て不正であると見なされる。（７）指定された特定の商品又はサービス、例えば指定された商品及び／又はサービスに対応するＳＫＵを有するレベル３データを含む取引は全て不正であると見なされる。（８）指定された地理上の区域、例えば所与の区域（州、国、大陸等）内に商店が位置することを示すレベル３データを有する取引は全て不正であると見なされる。

カード保持者は、彼がカードに適用を希望する不正規約に対応するフィールドのいずれかにデータを入力することができる（処理１４０６）。例えば、５０００ドルを超える支出額は不正であると見なされるように規定するために、カード保持者は「最大許容可能な支出額（ドル）」と名付けたフィールドへ「５０００」を入力することができる。最後に処理１４０８に示すように、図７のソフトウェアシステムは選択された規約を処理１４００中に入力されたカード番号に関連付ける。

図１３を参照して同様に触れたように、カード保持者は彼のカードに関連するＰＩＮを変更する方式を選択することができる。図１３と図１４を参照して説明したように、カード保持者はウェブサイトへログインすることによりＰＩＮ変更方式の選択を始めることができる（処理１５００）。それによって図７のソフトウェアシステムは、特定のカード番号に対応するものとしてウェブサイトの特定のユーザを特定する。

図１３と図１４を参照して説明したように、ログイン後にユーザは彼のカードに関連するＰＩＮの自動変更できるようにするオプションを選択する。その後、ウェブサイトはカードに適用することのできる各種変更方式をカード保持者へ提示することで応答する（処理１５０２）。例えばボックス１５０４に示すように、ウェブサイトはカード保持者へ、下記を指定するためにデータ入力可能なフィールド群を提示することができる。すなわち、（１）指定した時間単位ごとにＰＩＮを増加させる指定の数量、例えばＰＩＮを毎週５だけ増加させる、（２）指定した単位時間ごとにＰＩＮを減少させる指定の数量、例えばＰＩＮを毎週５だけ減少させる、（３）指定のＰＩＮ群のそれぞれを指定の期間について有効とする、例えば５個のＰＩＮからなる指定群において、群内の第１のＰＩＮを１週にわたり有効とし、次週は群内の第２のＰＩＮを有効とし、以下同様とする、（４）各単位時間ごとにＰＩＮに対し右回転処理を行うオプション、例えば１週間後にＰＩＮ４３０５を５４３０、次週後に０５４３、以下同様とする、（５）各単位時間ごとにＰＩＮに対し左回転処理を行うオプション、例えば１週間後にＰＩＮ４３０５を３０５４、次週後にそれを０５４３、以下同様とする、（６）ＰＩＮを有効とする期間を指定し、この期間経過後には新規のＰＩＮを無作為に選択する、例えば毎週新規ＰＩＮを無作為に選択し（例えば、カード保持者はウェブサイト内にログインして新規ＰＩＮを知ることができ、又は所定の電話番号に電話して双方向音声認識を介し新規ＰＩＮ番号を知ることができ、かつ／又は保持者にＰＩＮをメールする）、（７）選択された期間の経過に伴いＰＩＮに乗算する指定の数量、例えば毎日ＰＩＮに２を乗算する、（８）指定した期間の経過に伴いＰＩＮを除算する指定の数量、例えば毎日ＰＩＮを２で除算する、かつ／又は（９）前述のアルゴリズムを含む任意のアルゴリズムに従って変化するＰＩＮの動的部分に対し後付け添付し、又は先付け添付するＰＩＮの静的部分、例えば静的部分、１２３４５を選択し、これに対し動的部分９９を後付け添付し、１２３４５９９からなるＰＩＮを作り、これは動的部分を１だけ増数させることで変更するよう指定した場合には１２３４５１００へ変化させることができる。ＰＩＮに対し、例えば指定数量Ｎを乗算する等の数学的演算を施す場合には、得られる量は切り捨てされたり、あるいは適当な桁数の値に至るまで演算されたりすることを理解されたい。しかしながら、一部実施形態によれば、ＰＩＮは所定長ではなく、むしろ所定範囲内の任意の長さ、例えば４桁〜５６桁の間の任意の長さとしてもよい。またＰＩＮに対して、例えば指定数量ＮにてＰＩＮを除算する等の数学的処理を施す場合には、得られる量は最も近い数値に丸め処理されたり、あるいは整数値に至るまで演算されたりすることを理解されたい。

カード保持者は、彼がカードへ適用を望むＰＩＮ変更方式に対応するフィールドのいずれかへデータを入力することができる（処理１５０６）。例えば、彼のカードに関連するＰＩＮを毎週５だけ増加させるべきことを規定すべく、カード保持者は「ＰＩＮ増加数量」と名付けられたフィールドへ「５」を入力し、「ＰＩＮ増加期間」と名付けられたフィールドへ「毎週」を入力することができる。最後に処理１５０８に示すように、図７のソフトウェアシステムが、選択された規約を処理１５００中に入力されたカード番号に関連付ける。

別の実施形態によれば、図７のソフトウェアシステムは一度のみ使用できるＰＩＮを選択することをサポートすることができる。例えば、カード保持者は彼のカード番号に常時関連するＰＩＮを選択することができる（前述のように、フロントエンドモジュール７２６により供給されるウェブサイトの使用による）。これに加え、カード保持者は使用可能だが一度限り使用可能なＰＩＮを選択することができる（ここでも、前述したフロントエンドモジュール７２６が提供するウェブサイトの使用による）。取引実行の際、図７のソフトウェアシステムが図６のうちの一つ等の暗号化搬送オブジェクトを受け取ると、第３の復号モジュール７１２はまず図７を参照して説明したように、「通常」ＰＩＮを用いて復号を試行することができる。復号が失敗したと仮定すると、第３の復号モジュール７１２がカード番号に関連する「一度限りの」ＰＩＮを用いて復号を試行する。これに成功すると、この取引は先に説明したように実行され、一度限りのＰＩＮはこれ以降使用不能とされる。この種の一度限りのＰＩＮは、カード保持者がなじみのない電子商取引ウェブサイトを使用しているときや、自分のＰＩＮ入力が監視されているのではないかと思う場合等の、彼の「通常」ＰＩＮを販売業者へ提供することに気がすすまない状況で有用である。ＰＩＮは一度しか使用できないため、ＰＩＮ入力がウェブサイトにより監視され捕捉されたとしても問題にはならない。

本発明の別の実施形態によれば、図１６Ａと図１６Ｂを参照して説明するように、前述の取引方式を用いて販売業者間で商品を返品することができる。例えば、図１６Ａは典型的なオンライン購入構成を表し、そこでカード保持者１６００はオンライン販売業者１６０２から品目を注文する。カード保持者１６００は、オンライン販売業者から品目を受け取る（処理１６０１）。これに応答し、カード発行銀行１６０４は品目価格をオンライン販売業者の銀行へ転送する（処理１６０３）。次に、支払い期限の満了時に、カード保持者１６００は品目価格に等しい総額を銀行１６０４に支払う（処理１６０５）。

図１６Ｂは、商品の販売業者間の返品構成の一例を表す。図１６Ｂの構成では、カード保持者１６００はその品目を煉瓦及びモルタル販売業者１６０６へ返品する（処理１６０７）。返品時にカード保持者１６００は煉瓦及びモルタル販売業者へ彼の領収書を提示し、業者はその情報を用いて特定のカード保持者が煉瓦及びモルタル商店１６０６にて特定の販売業者の特定商品返品を取引しようとしていることを取引プラットフォームに示す。取引プラットフォームは、前述の情報を用いて規約データベースにアクセスし、煉瓦及びモルタル販売業者からオンライン販売業者へ送金する総額を決定する。取引プラットフォームのサーバはそこで、煉瓦及びモルタル販売業者からオンライン販売業者の銀行へ、決定された額に等しい資金の送金を開始する（処理１６０９）。前述の規約準拠額は個々の販売業者によって予め同意を得ることができ、交換対象である特定商品あるいは交換対象商品分類の関数とすることができ、加えて販売業者間交換に関与する二つの特定の販売業者関数とすることができる。

その後、オンライン販売業者１６０２は品目価格に等しい金額をカード発行銀行１６０４に送金（処理１６１１）し、カード発行銀行１６０４は品目金額に等しい金額をカード保持者の口座に振り込む（処理１６１３）。かくして、カード保持者１６００は自由に第１の販売業者（オンライン販売業者１６０２等）からの購入を行い、商品を第２の販売業者（煉瓦及びモルタル販売業者１６０６等）へ返品する。この返品構成が可能であるのは、特定の商品あるいは商品分類の交換時にある販売業者から別の販売業者へ送金される額に対する同意が取引プラットフォームのサーバと交信状態にあるデータベースに保存されているからである。

図１７は、カード保持者間での資金の無線交換方式を示す。この方式は、携帯電話内のプロセッサ上で稼働するアプレットが付随する。このアプレットは、カード保持者に下記のデータを入力するよう要請する入力促進モジュール１７００を含む。すなわち、（１）彼又は彼女が他のカード保持者へ望む送金額、（２）カード保持者のＰＩＮコード、（３）受取人の携帯電話番号である。前述のデータはデータ群へとまとめられ、前述の原理に従って動作することのできる暗号化ユニット１７０２により暗号化される。そこで、図７のＳＳＬインターネット接続取引プラットフォームを介して暗号化データ群が通信される。

フロントエンドでは、取引を始めた電話番号を抽出し、これを用いてカード保持者電話番号にＰＩＮコードを関連付けるデータベース１７０４に問い合わせる。このようにして対応するＰＩＮコードがモジュール１７０６へ返送され、ＰＩＮコードを復号鍵として使用する復号モジュール１７０８へ供給される。

その後、ＰＩＮに対応する口座内の資金の利用可能性を調査する。一実施形態によれば、ＰＩＮ又は電話番号を用い、カード識別番号をＰＩＮ又は電話番号に関連付けるデータベース１７１０へアクセスすることができる。検索されたカード識別コードはそこで資金調査モジュール１７１２へ送信され、このモジュールがＰＩＮ／電話番号に対応する口座が提示交換できるだけの十分な資金を有するかどうかを判定する。そうである場合には交換取引され、モジュール１７１４によりＳＭＳが受取人の電話番号へ送信されて彼又は彼女に資金の交換を通知する。

個人間の資金交換もまたフロントエンドモジュール７２６から提示されたウェブサイトを介してオンラインで行い、図１７を参照して説明したように通常進めることができる。

図１８は、直前に説明した個人間取引の例示実施形態を示す。図１８に示すように、取引プラットフォーム１８００は二つの銀行１８０２，１８０４のそれぞれを介して金融資金（信用限度とデビット口座と支払い口座と貯蓄口座とストアードバリュー及び／又はプリペイド口座）へのアクセスを期限延長する。原則として、プラットフォーム１８００は銀行の数によらず資金へのアクセスを期限延長する。説明のため、個人間の資金送金をクレジットカードからの送金を参照して説明する。資金の送金は、任意種の口座から任意種の口座へと行うことができる。ここでも説明のためにだけ、取引プラットフォームが８人の特定の人物を取り扱い、各人がクレジットカードとして機能する取引カードを所有するものと仮定する。カード保持者のうち４人が銀行１８０２を介して信用限度にアクセスし、その一方で他の４人が銀行１８０４を介して信用限度にアクセスする。かくして、図１８に示すように、各カード発行銀行１８０２，１８０４によって各カード保持者ごとに口座が維持される。この種の一つの口座は参照符号１８０６により特定され、別のこの種口座は参照符号１８０８により特定される。

信用口座１８０６に関連するカード保持者が口座１８０８に関連する特定の個人へ資金を送金するものと仮定すると、この種の資金は口座１８０８に関連する特定の個人に対し即座に利用可能にできる。取引プラットフォームは、各銀行１８０２，１８０４に口座１８１０，１８１２を保有している。銀行１８０２に口座を有する全てのカード保持者が口座１８１０に預けたプリペイド口座資金を有し、その一方で銀行１８０４に口座を有する全てのカード保持者が口座１８１２に預けたプリペイド口座資金を有する。ブラットフォームは、プリペイド口座１８１０，１８１２に預けられた資金の各カード保持者の持分の追尾を継続するデータベース７０６を保有している。クレジット口座１８０６からクレジット口座１８０８に関連するカード保持者への送金は、クレジット口座１８０６からプリペイド口座１８１２へ送金され、データベース１７０６は直ちに更新され、（１）送金された金額だけ口座１８１２が増額されたことを反映し、（２）信用口座１８０８に関連するカード保持者が送金された金額だけ増額されたプリペイド口座の持分を有することを反映する。すなわち、金融口座１８０８に関連するカード保持者はプリペイド口座から彼の持分を直ちに引き落とし、例えばプリペイド取引としてこの種の購入を取引することで商品あるいはサービスの購入を行うことができ、それはそのプリペイド口座１８１２から資金を引き落とし、データベース７０６を直ちに更新してこの種取引を反映することを意味する。そうでなければ、クレジット口座１８０８に関連するカード保持者は受け取った資金が彼の信用口座１８０８か又は他の任意の口座へ送金されることを特定することができる。この種の送金はそこで、その金額がプリペイド口座１８１２から引き落とされ、信用口座１８０８へ預けられたことを反映すべく、例えばデータベース７０６と銀行１８０４のコンピュータシステムを同期させるその日の終了時点で完了する。

上記した各種実施形態は、例示のためだけに提供するものであり、本発明を限定するものと解釈してはならない。当業者は本願明細書に図示し説明した例示実施形態と応用例に従うことなく、かつ特許請求の範囲に記載する本発明の真の趣旨及び範囲から逸脱することなく、本発明に対し為すことのできる各種改変や変形を即座に認識するだろう。

典型的なクレジットカード取引を示す図である。 本発明の一実施形態によるクレジットカード取引を示す図である。 そこに関連する用途が承認された時点でほぼ同時に取引カードを有効にすることのできる方法を示す図である。 図５のカーネルを展開することのできる例示ネットワーク環境を示す図である。 図４の例示ネットワーク実施形態において展開することのできるカーネルの例示実施形態を示す図である。 図５のカーネルから図７のソフトウェアシステムへ通信するメッセージの例示実施形態を示す図である。 取引プラットフォームにより操作される１以上のサーバが実行することのできるソフトウェアシステムの例示実施形態を示す図である。 図７のデータベースが実装する方式の例示実施形態を示す図である。 図７のソフトウェアシステムから図５のカーネルへ通信するメッセージの例示実施形態を示す図である。 図５のカーネルから図７のソフトウェアシステムへ通信するメッセージの例示実施形態を示す図である。 将来の申請人に対する無記名未割当カードを配布するカード保持者に報償を与える方法の例示実施形態を示す図である。 取引内の品目に関連する経費に対し疑義を挟めるようにする方法の例示実施形態を示す図である。 子カードの使用を規定する規約を設定あるいは変更する方法の例示実施形態を示す図である。 ユーザ選択可能な不正検出規約を設定あるいは変更する方法の例示実施形態を示す図である。 ユーザ選択可能なアルゴリズムＰＩＮ修正規約を設定あるいは変更する方法の例示実施形態を示す図である。 商品の販売業者間交換を可能にする方式の例示実施形態を示す図である。 商品の販売業者間交換を可能にする方式の例示実施形態を示す図である。 個人間資金交換の例示実施形態を示す図である。 個人間資金交換の別の例示実施形態を示す図である。

Claims (22)

1. カードを特定するカード番号をエンコードした記憶媒体を含む取引カードを、店舗内での配布のため商店に提供するステップと、
   顧客が前記店舗内にいる間に、前記取引カードのうち１枚を前記顧客へ配布するステップと、
   前記顧客からクレジット申請情報を取得するステップと、
   前記顧客が前記店舗内にいる間に、前記配布取引カードを介して期限延長される信用限度について前記顧客を承認すべきか判定するために、前記クレジット申請情報を審査用に遠隔コンピュータシステムへ通信するステップと、
   前記顧客が前記店舗内にいる間に、前記顧客が承認されかつ前記配布カードが有効になったことを示す前記通信に対する応答を受信するステップと、
   前記顧客が前記店舗内にいる間に、購入を取引するために前記配布取引カードを使用するステップと、を含む方法。
2. 前記有効な取引カードの前記記憶媒体が、前記カードが有効になる前にそこにエンコードされていた情報以外は一切エンコードされない、請求項１記載の方法。
3. 前記有効なカードの前記記憶媒体が前記顧客に関する情報を一切エンコードされない、請求項１記載の方法。
4. 前記有効なカードの前記記憶媒体が個人識別番号（ＰＩＮ）を一切エンコードされない、請求項１記載の方法。
5. 前記有効なカードの前記記憶媒体がカード番号のみをエンコードされる、請求項１記載の方法。
6. 前記有効なカードが前記顧客に関する情報を示す可視標識を一切記載しない、請求項１記載の方法。
7. 前記有効なカードが前記顧客名に関する情報を示す可視標識を一切記載しない、請求項１記載の方法。
8. 前記遠隔コンピュータシステムにより前記申請情報を受け取るステップと、
   前記申請情報を複数の銀行へ送信するステップで、前記複数の銀行がそれぞれ前記クレジット申請情報の独自の審査を実行し、前記カードを介して期限延長する信用限度について前記顧客を承認すべきか判定するステップと、
   前記複数の銀行のそれぞれが実行する前記複数の審査それぞれの結果を受け取るステップと、をさらに含む、請求項１記載の方法。
9. 個人に対し信用限度を期限延長する取引カードを所有する個人に対し、エンコードされたカード番号を有する記憶媒体を含む未割り当て取引カードを少なくとも１枚提供するステップと、
   前記未割り当て取引カードの前記カード番号に前記未割り当て取引カードを提供された前記個人を関連付けるステップと、
   前記個人によって前記未割り当て取引カードを提供された申請人から、前記カード番号を含む申請情報を受け取るステップと、
   前記申請情報に含まれる前記カード番号を調べ、前記個人が前記未割り当てカードを元々供給されていたか判定するステップと、
   前記申請人に前記未割り当て取引カードを配布した前記個人に報償を与えるために、前記個人の取引カードが関連する口座に報償ポイントを供与するステップと、を含む方法。
10. 前記申請情報を審査し、前記未割り当て取引カードを介して期限延長される信用限度について前記申請人を承認すべきか判定するステップをさらに含む、請求項９記載の方法。
11. 前記申請情報の審査行為が、前記口座に対する前記報償ポイントの供与行為を行う事業者とは異なる事業者により行われる、請求項１０記載の方法。
12. 前記申請情報の審査行為が銀行により行われる、請求項１１記載の方法。
13. 前記口座に対する前記報償ポイントの供与行為が、前記未割り当て取引カードを介して期限延長される信用限度について前記申請人を承認する時に調整される、請求項９記載の方法。
14. 前記未割り当て取引カード上に含まれる前記記憶媒体が、バーコードを含む、請求項９記載の方法。
15. 前記未割り当て取引カード上に含まれる前記記憶媒体が、磁気帯片を含む、請求項９記載の方法。
16. エンコードされたカード番号を有する記憶媒体を含む、少なくとも１枚の未割り当て取引カードと、
    前記未割り当て取引カードを提供された申請人から申請情報を受け取り、前記申請情報の審査の結果前記申請人が信用限度について承認されたことを示すときに、前記未割り当て取引カードを有効にして前記未割り当て取引カードを介して前記申請人に対する前記信用限度が期限延長されるようにしたコンピュータシステムと、を備え、
    前記未割り当て取引カードが、前記申請人に関する情報を示す可視標識を一切記載せず、前記未割り当て取引カードの前記記憶媒体上に前記申請人に関する情報を一切エンコードしない、システム。
17. 前記コンピュータシステムが、前記未割り当て取引カードの前記カード番号に、信用限度を期限延長する取引カードを所有しかつ前記未割り当て取引カードが元々供給されていた個人を関連付けるデータベースを有する、請求項１６記載のシステム。
18. 前記コンピュータシステムが、前記個人が前記未割り当て取引カードを元々供給されていたか判定するために前記申請情報に含まれる前記カード番号を調べ、前記申請人に前記未割り当て取引カードを配布したことについて前記個人に報償を与えるために前記個人の取引カードが関連する口座に報償ポイントを供与するようプログラムされた、請求項１７記載のシステム。
19. 前記未割り当て取引カードがクレジットカードとして機能するように、前記コンピュータシステムが前記データベース内に情報を入力するようプログラムされた、請求項１６記載のシステム。
20. 前記未割り当て取引カードがストアードバリューカードとして機能するように、前記コンピュータシステムが前記データベース内に情報を入力するようプログラムされた、請求項１６記載のシステム。
21. 前記未割り当て取引カードがデビットカードとして機能するように、前記コンピュータシステムが前記データベース内に情報を入力するようプログラムされた、請求項１６記載のシステム。
22. 前記未割り当て取引カードがクレジットカード、ストアードバリューカード、及びデビットカードとして機能するように、前記コンピュータシステムが前記データベース内に情報を入力するようプログラムされた、請求項１６記載のシステム。

Images