ネットワークで金融取引を行うためのシステム及び方法
【課題】支払い取引をより確実に処理し、不正取引、マネーローンダリング、及び未成年のギャンブルに対して取引先及び銀行を保護し、かつインターネットのゲーム、旅行、及び電子商品を顧客が購入することなど特別なリスクをもたらすことが分かる電子商取引の領域で他の不正行為を制限するシステムを提供する。
【解決手段】金融取引システムの種々の実施形態により、取引先、インターネット支払いサービスプロバイダ、承継銀行、及びカード機構に対する動作及び取引処理プロトコルが確立され、かつ支払い及び金融取引をモニタし、確実に処理するための自動化システムを作成する。
【解決手段】金融取引システムの種々の実施形態により、取引先、インターネット支払いサービスプロバイダ、承継銀行、及びカード機構に対する動作及び取引処理プロトコルが確立され、かつ支払い及び金融取引をモニタし、確実に処理するための自動化システムを作成する。
【発明の詳細な説明】
【技術分野】
【０００１】
一般に、顧客が（インターネット上で又は別の方法で）取引先に対して支払カード（例えば、クレジットカード又はデビットカード）を使用することを希望する場合、この取引先は承継銀行に対して電子許可要求を送る。承継銀行はこの電子許可要求を、カード発行会社のネットワーク（card issuer network）（例えば、ビザ、マスタカード、アメリカンイクスプレス、又はプライベートカード発行会社のネットワーク）を介して発行銀行（すなわち、顧客に支払カード発行した銀行又は金融機関）に渡す。発行銀行は、顧客が利用可能な十分なクレジットを持っていること、支払いを滞納していないこと、及び提供される全ての情報（例えば、カード番号、カード検証値番号（card verification value number）、及びカード所有者の詳細）が正しいことを検証する。発行銀行は次に、支払いを許可する電子メッセージをカード発行会社のネットワークを介して承継銀行に送り、この承継銀行は電子メッセージを取引先に送る。取引先はこの許可メッセージを、発行銀行による将来の支払いの証拠として受け入れる。資金の実際の移動は、決済処理と呼ばれる後の段階で発生する。
【０００２】
インターネット又は他のネットワーク上で発生する支払カードによる取引は、カード所有者と取引先は取引が発生するときに通常一緒にいないため、対面支払い取引では必ずしも存在しない危険が伴う。さらに、ギャンブルや成人向け娯楽などの幾つかの電子商取引部門では、支払カードによる取引を信頼できるものにし、かつ不正行為や他の悪用を防止するために、システムに対する要求を更に強調する付加的な公共の関心が高まっている。
【発明の概要】
【課題を解決するための手段】
【０００３】
本発明の種々の実施形態により、（１）支払い取引をより確実に処理し、（２）不正取引、マネーローンダリング、及び未成年のギャンブルに対して取引先及び銀行を保護するのに役立ち、かつ（３）インターネットのゲーム、旅行、及び電子商品を顧客が購入することなど特別なリスクをもたらすことが分かる電子商取引の領域で他の不正行為を制限するのを支援する、電子商取引部門に対するより安全な金融取引が提供される。上記の目標を達成するために、金融取引システムの種々の実施形態により、（１）取引先、インターネット支払いサービスプロバイダ、承継銀行、及びカード機構（card scheme）に対する動作及び取引処理プロトコルが確立され、かつ（２）支払い及び金融取引をモニタし、確実に処理するための自動化システムが提供される。本願で説明された種々の実施形態を２つ以上組み合わせて、１つ以上のこれらの目標に適合するシステム又は方法を提供することができる。
【０００４】
本発明の種々の実施形態によれば、オンライン取引先との金融取引を処理するためのシステムが提供される。このシステムは、（１）資金を顧客の口座からオンライン取引先に移動する要求を受信し、（２）この資金を移動する要求を受信する動作に応答して、資金の少なくとも一部をオンライン取引先のエスクロー勘定に支払うように割り当て、かつ（３）資金の一部をオンライン取引先のエスクロー勘定に支払うように割り当てることに応答して、より短い所定の期間又は入金取消し又は払い戻し要求がシステムによって受信されるまで、割り当てられた資金の一部をエスクロー勘定に保管するように構成された支払いサービスプロバイダ用モジュールを備えている。さらに、１つの実施形態では、この要求は、ネットワークを介して支払いサービスプロバイダ用モジュールと通信する取引先のコンピュータ装置から受信される。
【０００５】
１つの実施形態では、この支払いサービスプロバイダ用モジュールは、各オンライン取引先に定期的に一致報告書（reconciliation report）を作成するようにさらに構成される。この一致報告書は、受信された振り込み要求及びエスクロー勘定に割り当てられた資金の部分を列挙している。別の種々の実施形態では、この支払いサービスプロバイダ用モジュールは、顧客の口座から取引先に前に振り込まれた資金に対する入金取消し要求又は返金要求を受信し、そして入金取消し要求又は返金要求を受信することに応答して、この入金取消し要求又は返金要求に対してエスクロー勘定に保管された資金を供給するようにさらに構成される。
【０００６】
さらに別の実施形態では、このシステムは、要求に対して１つ以上の不正検出フィルタを適用するように構成された不正防止用モジュールも備えている。この不正検出フィルタは、（１）顧客の口座に関連する第１の位置を要求をオンライン取引先に送るために使用された顧客のコンピュータ装置に関連する第２の位置と比較して、第１の位置が第２の位置の第１の所定の許容できる距離の外側にある場合、この要求は潜在的に不正であるとして印を付ける機能と、（２）顧客のイーメールアドレスに関連した第３の位置を第２の位置と比較して、この第３の位置が第２の位置の第２の所定の許容できる距離の外側にある場合、この要求は潜在的に不正であるとして印を付ける機能と、（３）顧客の口座に対する顧客の請求書送付先に関連する第４の位置を第２の位置と比較して、この第４の位置が第２の位置の第３の所定の許容できる距離の外側にある場合、この要求は潜在的に不正であるとして印を付ける機能と、（４）顧客の識別番号を金融取引を行うことを禁止された人物のリストと比較して、顧客の識別番号がリスト上の人物の１人と一致する場合、この要求は潜在的に不正であるとして印を付ける機能と、及び／又は（５）顧客の口座の識別番号を金融取引を行うことを禁止された口座のリストと比較して、この顧客の口座の識別番号がリストの口座の１つと一致する場合、この要求は潜在的に不正であるとして印を付ける機能と、を含むことができる。
【０００７】
本発明の種々の実施形態によれば、顧客から受信した払い戻し要求に対して資金を供給する方法が提供される。この方法には、（１）１人以上の顧客に関連した１つ以上の口座から取引先に支払われる資金の比率によって資金が供給されるエスクロー勘定を取引先（例えば、オンライン取引先）に対して開設するステップと、（２）特定の顧客に関連した口座から取引先に対して前に行われた支払いに対する払い戻し要求を受信するステップと、そして（３）エスクロー勘定に保管された資金を用いて、この払い戻し要求に資金を供給するステップと、が含まれる。１つの実施形態では、この払い戻し要求に対して資金を供給するステップは、議論せずに行われる。さらに、種々の実施形態によれば、この払い戻し要求は、入金取消し要求又は返金要求である。
【０００８】
その上、さらに別の実施形態では、この方法には、資金の一部が特定の期間（例えば、少なくとも６ヶ月）エスクロー勘定に保管されていることに呼応して、エスクロー勘定の資金の一部を取引先に振り込むステップも含まれる。別の実施形態では、この方法にはさらに、（１）特定の期間にわたって取引先が受け取る払い戻し要求の数が減少することを受けて、取引先がエスクロー勘定に支払う資金の比率を減少するステップと、（２）前記特定の期間にわたって取引先が受け取る払い戻し要求の数が増加することを受けて、取引先がエスクロー勘定に支払う資金の比率を増加するステップと、がさらに含まれる。さらに別の実施形態では、この方法には、払い戻し要求に対して潜在的に不正な払い戻し要求を識別するように構成された１つ以上の不正検出フィルタを利用するステップが含まれる。これらの不正検出フィルタは、本発明の１つの実施形態に基づいて、コンピュータが読取り可能な媒体上で実行される不正防止用モジュールによって動作される。
【０００９】
本発明の種々の実施形態により、（１）顧客に関連した口座から以前取引先に対して行われた支払いに対する払い戻し要求を受信するステップと、（２）取引先に関連した口座の中に保管された資金から、議論せずに顧客に対する払い戻し要求に資金を供給するステップとを有する、顧客に対する払い戻し要求に資金を供給する方法が提供される。この払い戻し要求は、種々の実施形態によれば、入金取消し要求又は返済要求とすることができる。さらに、１つの実施形態によれば、顧客に関連した口座を保持する金融機関からの払い戻し要求が受け取られて、払い戻し要求に対する資金が、顧客に関連した口座を保持する金融機関に対して支払われる。
【００１０】
本発明の種々の他の実施形態によれば、オンライン取引先に対して顧客から受信された潜在的に不正なオンライン金融取引を識別するための不正防止システムが提供される。この不正防止システムには、１人以上の顧客から受信された１つ以上の金融取引のそれぞれに対して、前述された１つ以上の不正検出フィルタを利用するように構成された不正防止用モジュールが含まれる。さらに、種々の実施形態では、この不正検出フィルタには、（１）１つ以上の続いて起こる金融取引に関連した情報を不正行為用データベースの中に記憶された金融取引と比較して、１つ以上の続いて起こる金融取引のそれぞれの顧客の口座、顧客の識別番号、又は顧客の請求書送付先が不正行為用データベースの中に記憶された金融取引のいずれかと一致する場合、潜在的に不正であるとして１つ以上の続いて起こる金融取引に印を付ける機能と、（２）第１の位置を第３の位置と比較して、この第１の位置が第３の位置の第１の所定の許容できる距離の外側にある場合、潜在的に不正であるとしてこの金融取引に印を付ける機能と、も含まれる。さらに、この第２の位置が国を含む実施形態では、不正検出フィルタは、第２の位置を取引先と金融取引を行うことが禁止されている国のリストと比較し、この第２の位置が国のリスト上にある場合は、金融取引を行うことが禁止される機能をさらに含む。
【００１１】
別の実施形態では、金融取引を行うことが禁止されている口座のリストは、盗難口座のリストである。さらに別の実施形態では、第１の位置は、顧客の口座を管理する金融機関に関連した位置である。そして、別の実施形態では、第１の位置は、顧客の口座に関連した請求書送付先である。種々の他の実施形態によれば、第１の位置、第２の位置、第３の位置、そして第４の位置は、国、地方、州、地域、市、又は１つ以上の郵便番号によって規定された郵便区域とすることができる。さらに、１つの実施形態では、人物のリスト及び／又は口座のリストは、政府当局によって発行される。
【００１２】
さらに、本発明の１つの実施形態では、不正検出フィルタが、取引先の住所に基づいて選択される。本発明の別の実施形態では、この不正検出フィルタは、第２の位置に基づいて選択される。そして、本発明のさらに別の実施形態では、この不正検出フィルタは、第１の位置に基づいて選択される。
【００１３】
別の実施形態では、システムは、顧客に対する払い戻し要求を受信するように構成された支払いサービスプロバイダ用モジュールをさらに備えて、不正防止用モジュールが払い戻しを要求する顧客のアイデンティティをオンライン取引先に関連した職員、管理者、又は所有者のリストと比較するようにさらに構成される。顧客が管理者、職員、又は所有者のリスト上にある場合は、不正防止用モジュールは、潜在的に不正であるとしてこの払い戻し要求に印を付ける。
【００１４】
本発明のさらに別の実施形態によれば、金融取引はギャンブル支払い要求であり、不正防止用モジュールは取引先から支払いを受け取るために顧客が指定した口座の識別番号を、取引先に賭け金を入れるために顧客が使用する口座の識別番号と比較するようにさらに構成される。支払いを受け取るために指定された口座の識別番号が、賭け金を取引先に入れるために使用された口座の識別番号と一致しない場合、この不正防止用モジュールは、潜在的に不正であるとしてこの払い戻し要求に印を付ける。さらに別の実施形態では、この不正防止用モジュールは、払い戻し要求の中で規定された金額が、払い戻しを受け取るために指定された口座に移動されないようにさらに構成される。別の実施形態では、払い戻し要求を受け取るために指定された口座が第１の支払いカードに関連し、取引先に賭け金を入れるために使用される口座が第２の支払いカードに関連し、そして不正防止用モジュールが、第１の支払いカードを第２の支払いカードと比較するようにさらに構成される。第１の支払いカードが第２の支払いカードと一致しない場合は、不正防止用モジュールは潜在的に不正であるとしてこの払い戻し要求に印を付ける。
【００１５】
本発明の種々の実施形態によれば、顧客の強制された支出動作を監視するシステムが提供される。このシステムはプロセッサ及びメモリを備えると共に、このプロセッサが（１）取引先と金融取引を行うために、顧客からの１つ以上の要求のそれぞれに関連した、資金の総額を含む情報をメモリの中に記憶し、（２）取引先と金融取引を行うために、資金の新しい金額を含む新しい要求を受信し、（３）この新しい要求を受信すると、メモリに記憶された資金の総額を修復し、（４）資金の総額及び新しい要求の中の資金の額の合計を所定の許容できる限度と比較し、そして（５）この合計が所定の許容できる限度を超えた場合、顧客、この顧客に関連した支払いソース、又は所定の許容できる限度が超過された取引先の１つ以上に通知する、ように構成される。特定の実施形態では、メモリの中に記憶された情報には、各要求が取引先によって受信されたデータが更に含まれ、かつプロセッサが特定の期間内にメモリの中に記憶された資金の総額と新しい要求の中の資金の額のとの合計を、所定の許容できる限度と比較するようにさらに構成される。
【００１６】
本発明の種々の他の実施形態によれば、顧客の強制されたギャンブル動作を監視する別のシステムが提供される。このシステムは前述されたシステムと似通っているが、プロセッサが、新しい要求の中の金融取引の種類に対してメモリの中に記憶された資金の総額を修復し、かつこの資金の総額と新しい要求の中の資金の額との合計を、新しい要求の中の金融取引の種類に関連した所定の許容できる限度と比較するようにさらに構成される。本発明の種々の実施形態では、取引の種類は、顧客に関連した口座から取引先に資金を移動する要求、又は前に取引先に移動した資金を用いて賭け金を入れる要求とすることができる。さらに、１つの実施形態では、要求及び新しい要求は、顧客に関連した１つ以上のコンピュータ装置からネットワークを介して取引先に関連したコンピュータ装置によって受信される。メモリの中に記憶された情報が、取引先が受信した要求の日付を含むような特定の実施形態では、プロセッサは、特定の期間内に顧客によって要求された資金の総額と新しい要求の中の資金の額のとの合計を、所定の許容できる限度と比較するようにさらに構成される。別の実施形態では、プロセッサは、この合計が所定の許容できる限度を超える場合、新しい要求が処理されないようにさらに構成される。
【００１７】
本発明の種々の実施形態によれば、顧客の強制された支出動作を監視するための第３のシステムが提供される。このシステムは前述された第１のシステムに類似しているが、要求に関連した情報には取引先が要求を受信した日付が含まれている。この第３のシステムの処理は、所定の期間内にメモリの中に記憶された取引の総数を修復し、取引の総数を所定の許容できる限度と比較し、そして取引の総数が所定の許容できる限度を超えた場合、顧客、この顧客に関連した支払いソース、又は限度が超過された取引先の１つ以上に通知する、ように更に構成される。
【００１８】
本発明の種々の実施形態では、オンライン取引先に対して行われた金融取引に対する税務会計システムが提供される。この税務会計システムはメモリとプロセッサを具備し、このメモリは１つ以上の税の種類及び１つ以上の税管轄（tax jurisdiction）のそれぞれに対する対応する税率を記憶するように構成される。プロセッサは、（１）オンライン取引先に対して行われた金融取引に関連した情報を顧客から受信し、（２）金融取引に関連した情報を受信すると、金融取引に関連した１つ以上の税管轄を識別し、（３）金融取引に関連した１つ以上の税管轄を識別すると、１つ以上の税の種類が１つ以上の税管轄に関係付けられているかどうかを決定するためにメモリに問合せを行い、（４）１つ以上の税の種類が１つ以上の税管轄に関係付けられていることが判断されると、支払い義務がある税額を決定するために、金融取引に関連した情報に対する１つ以上の税の種類のそれぞれに対して対応する税率を適用し、そして（５）支払い義務がある税額が決定されると、１つ以上の関連する税務当局に支払うべき税額を振り込む、ように構成される。種々の実施形態では、税管轄はオンライン取引先の住所、顧客の位置、及び／又は顧客が金融取引を行うために使用するコンピュータ装置の位置に関係付けられている。
【００１９】
さらに別の実施形態では、プロセッサが、金額を１つ以上の関連する税務当局に電子資金振替システムを介して振り込むようにさらに構成される。別の実施形態では、プロセッサが、支払い義務がある税額及び特定の期間にわたる金融取引情報を用いて、１つ以上の関連した税務当局に振り込まれた金額をメモリに記憶するようにさらに構成される。さらに別の実施形態では、プロセッサが、１つ以上の関連した税務当局のそれぞれに対して会計報告書を作成するように特に構成され、この会計報告書は関連した税務当局に支払い義務がある税額、関連した税務当局に振り込まれた税額、及び税金が関連した税務当局に支払われた金融取引に関連した情報の少なくとも一部を含んでいる。
【００２０】
本発明の種々の他の実施形態によれば、オンライン取引先に対して行われた金融取引を処理するためのシステムが提供される。このシステムは支払いサービスプロバイダ用モジュールを具備し、この支払いサービスプロバイダ用モジュールは、（１）顧客の所在地に関連した第１の位置と要求を発生したコンピュータ装置の第２の位置とを含む、顧客の口座からオンライン取引先に資金を移動する要求を受信し、（２）この要求を受信すると、第１の位置、第２の位置、及びオンライン取引先の住所を、オンライン取引先に対する資金の移動を規定する位置のリストと比較し、（３）第１の位置、第２の位置、及びオンライン取引先の住所が位置のリストの位置と一致する場合、１つ以上の監督機関が第１の位置、第２の位置、又はオンライン取引先の住所において、顧客の口座からオンライン取引先への資金の移動を規制するかどうかを決定し、そして、（４）１つ以上の監督機関が第１の位置、第２の位置、又はオンライン取引先の住所において、オンライン取引先への資金の移動を規制すると決定する場合、１人以上の顧客、取引先、又は金融取引に関連した顧客の口座に関連した銀行に対して、資金の移動が管理される１つ以上の規制の種類を通知する、ように構成される。規制の種類には、１つ以上の移動の禁止、移動の制限、又は移動への課税が含まれる。１つの実施形態では、第２の位置は要求を発生したコンピュータ装置に対して発行されたインターネットプロトコルに関連付けられる。
【００２１】
本発明の種々の実施形態によれば、オンライン取引先に対して行われた金融取引を処理するための第２のシステムが提供される。このシステムは支払いサービスプロバイダ用モジュールを具備し、この支払いサービスプロバイダ用モジュールは、（１）顧客の所在地に関連した第１の位置と要求を発生したコンピュータ装置の第２の位置とを含む、顧客の口座とオンライン取引先との間で金融取引を行うための要求（例えば、オンライン取引先に対してギャンブルの賭け金を入力する要求、資金をオンライン取引先に移動する要求、又はオンライン取引先に対して入力された１つ以上のギャンブルの賭け金のために生じた支払いに対する要求）を受信し、（２）この要求を受信すると、第１の位置、第２の位置、及びオンライン取引先の住所を、オンライン取引先に対して行われた金融取引を規定する位置のリストと比較し、（３）第１の位置、第２の位置、又は取引先の住所が位置のリストの位置と一致する場合、１つ以上の監督機関が第１の位置、第２の位置、又はオンライン取引先の住所において、オンライン取引先に対して行われた金融取引を規制するかどうかを決定し、そして、（４）１つ以上の監督機関が第１の位置、第２の位置、又は取引先の住所において、金融取引を規制すると決定する場合、１人以上の顧客、取引先、又は金融取引に関連した顧客の口座に関連した銀行に対して、金融取引が管理される規制の種類を通知するように構成される。
【００２２】
１つの実施形態では、支払いサービスプロバイダ用モジュールは、１つ以上の監督機関が第１の位置、第２の位置、又はオンライン取引先の住所において、オンライン取引先と行われる金融取引を規制すると決定されたことに対応して、金融取引が取引先と行われることを禁止するようにさらに構成される。さらに、さらに別の実施形態では、この支払いサービスプロバイダ用モジュールは、１つ以上の監督機関が第１の位置、第２の位置、又はオンライン取引先の住所において、オンライン取引先と行われる金融取引を規制することが確認されたことに対応して、１つ以上のオンライン取引先又は顧客の口座に関連した銀行に通知するようにさらに構成される。
【００２３】
本発明の様々な実施形態をこのようにして一般的な用語で説明してきたが、ここで添付の図面を参照する。これらの図面は、必ずしも縮尺通りには描かれていない。
【図面の簡単な説明】
【００２４】
【図１】本発明の種々の実施形態による金融取引処理システムの、ハイレベル・ブロック図である。
【図２】本発明の種々の実施形態による金融取引処理システムの中の様々な契約関係を例示する図である。
【図３Ａ】本発明の１つの実施形態によるコンピュータ装置の概略図である。
【図３Ｂ】本発明の別の実施形態によるコンピュータ装置の概略図である。
【図４】本発明の種々の実施形態による金融取引処理システムを例示する概略図である。
【図５】本発明の種々の実施形態による取引先用モジュールのブロック図である。
【図６】本発明の種々の実施形態によるＩＰＳＰ用モジュールのブロック図である。
【図７Ａ】本発明の種々の実施形態による不正防止用サブモジュールのブロック図である。
【図７Ｂ】本発明の種々の実施形態による不正防止用サブモジュールのフローチャートである。
【図８】本発明の種々の実施形態によるＡＳＰ用モジュールのブロック図である。
【図９Ａ】本発明の種々の実施形態による委任取引処理のフローチャートである。
【図９Ｂ】本発明の種々の実施形態による委任取引処理のフローチャートである。
【図１０Ａ】本発明の種々の実施形態による決済取引処理のフローチャートである。
【図１０Ｂ】本発明の種々の実施形態による決済取引処理のフローチャートである。
【図１１】本発明の種々の実施形態による入金取消し取引処理のフローチャートである。
【図１２】本発明の種々の実施形態による顧客支払い取引処理のフローチャートである。
【図１３】本発明の１つの実施形態による委任取引要求処理のフローチャートである。
【図１４】本発明の１つの実施形態による決済取引要求処理のフローチャートである。
【図１５】本発明の１つの実施形態による強制支出動作を監視する方法のフローチャートである。
【図１６】本発明の１つの実施形態による強制ギャンブル動作を監視する方法のフローチャートである。
【図１７】本発明の１つの実施形態に基づいて、金融取引上で支払い義務がある税金を決定する方法のフローチャートである。
【図１８】本発明の１つの実施形態に基づいて、非合法又は規制の対象になる金融取引を識別する方法のフローチャートである。
【発明を実施するための形態】
【００２５】
ここで添付した図面を参照して、本発明の種々の実施形態をより完全に説明する。これらの図面には、本発明の実施形態の全てではないが、幾つかが示されている。実際に、この発明は多くの異なった形態で具体化することができるが、本願に記載された実施形態に限定されると解釈してはならない。むしろ、この開示内容が適切な法的必要条件を満足するように、これらの実施形態が提供される。同じ参照番号は全体を通して同じ要素を指す。
【００２６】
概要 全体として、本発明の種々の実施形態により、（１）支払い取引をより確実に処理し、（２）不正取引、マネーローンダリング、及び未成年のギャンブルに対して取引先及び銀行を保護するのに役立ち、かつ（３）インターネットのゲーム、旅行、及び電子商品を顧客が購入することなど特別なリスクをもたらすことが分かる電子商取引の領域で他の不正行為を制限するのを支援する、電子商取引部門に対する改良された金融取引処理システムが提供される。上記の目標を達成するために、金融取引システムの種々の実施形態により、（１）取引先、インターネット支払いサービスプロバイダ、承継銀行、及びカード機構に対する動作及び取引処理プロトコルが確立され、かつ（２）支払い及び関連した金融取引を監視及び処理するための改良された自動化システムが提供される。
【００２７】
例えば、本発明の種々の実施形態では、回転保存エスクロー勘定（rolling reserve escrow account）が各取引先に対して設定され、承継銀行又は発行銀行に対して損失の危険を減少させる態様で資金が割り当てられる。例えば、１つの実施形態によれば、取引先が受信した払い戻し（例えば、入金取消し及び返金）要求を処理するために、十分な資金を確実に利用可能にすることによって、損失の危険が低減される。１つの実施形態によれば、取引先に支払われる資金の一定の割合が保存され、一定の期間（例えば、６ヶ月、１年、又は３年）エスクロー勘定に移動されて、資金がその期間に使用されない場合は、その資金は取引先に送り戻される。回転保存エスクロー勘定に資金供給される金は取引先の潜在的利益から取り出されるため、マネーローンダリング計画に対して取引先の機能を用いることは魅力的でないことになる。さらに、種々の実施形態によれば、取引先が入金取消し要求を議論できる立場が限定されるため、争うために許容できる立場は、承継銀行又は発行銀行に対する損失のリスク（例えば、不正フラグで印が付けられている取引）をほとんど増加しない。別の実施形態では、取引先はどのような立場でも、入金取消し要求を争うことは認められない。このため、種々の実施形態によれば、回転保存エスクロー勘定により払い戻し要求を処理するための資金源が確実にされ、顧客に対する損失のリスクが低減され、そして顧客がオンラインの金融取引に従事する可能性が増加される。さらに、払い戻し要求に対して取引先が資金供給すると、承継銀行及び発行銀行に対する損失の危険が減少され、また取引先に対するより好都合な取引条件が生じる（例えば、より低い取引料金又はより低い入金取消し料金）。
【００２８】
別の実施例のように、本発明の種々の実施形態では、金融取引システムの参加者は、互いに地域の監督機関に従うように要求する。例えば、１つの実施形態では、取引先がコンプライアンスから外れる場合、インターネットの支払いサービスプロバイダ（これは後で、より詳細に説明される）、承継銀行、及びカード機構は、その取引先と取引を行うことを拒絶するであろう。別の方法では、１つの実施形態では、規則を順守しない参加者に罰金を科すことにしている。さらに、顧客は、規則を順守しない取引先と取引を行うことを拒絶することもある。このプロトコルを確立することによって、この金融取引システムは、地域の監督機関に従う参加者に対して市場刺激策を提供するようにしている。
【００２９】
金融取引システムの参加者には、本発明の種々の実施形態によれば、オンラインの顧客、オンラインの取引先、インターネット支払いサービスプロバイダ（ＩＰＳＰ）、承継銀行、発行銀行、又はカード機構が含まれる。このＩＰＳＰは取引先と承継銀行との間で動作し、取引先に支払いに関連したサービスを提供するものであり、ネットワーク上の取引先と承継銀行との間のインターフェースである。さらに、ＩＰＳＰは、会計サービスプロバイダ（ＡＳＰ）と契約して、ＩＰＳＰが取引先に対して提供する支払いサービスに関連した会計管理サービスを提供する。
【００３０】
図１は、本発明の種々の実施形態に基づいて、どのように様々な参加者が互いに結び付けられるかに関するハイレベルの概略図を例示している。例えば、参加者は取引情報を電子的にネットワーク（例えば、インターネット、プライベート・ネットワーク、又はプライベートＬＡＮネットワーク）を介して交換することができる。特に、取引情報には、顧客の支払いカードに関連した口座から取引先の口座に金を移動するための、取引先からの許可要求、顧客の口座から取引先の口座に金を移動することを許可する発行銀行からの許可メッセージ、金を取引先の口座から顧客の口座に移動することを要求する発行銀行からの払い戻し（例えば、入金取消し又は返金）要求、及び特定の期間（例えば、２４時間、４８時間、又は１週間）の間に処理された全ての取引についての各取引先に対する決済要求が含まれる。
【００３１】
前述された実施形態は、オンライン取引先から商品及びサービスを購入するために、口座に関連した支払いカード（例えば、デビットカード、クレジットカード、プリペイドカード、又は近接カード（proximity card））を使用することを説明しているが、種々の他の実施形態では、購入するために他の種類の支払いモードも使用できる。例えば、別の支払いモードには、口座に関連した支払いトークン（payment token）（例えば、物理的又は電子的なトークン）を使用すること又は口座に関連した番号（例えば、口座番号及びその口座にアクセスするためのパスワード）を使用することが含まれる。別の支払いモードには、例えばアイリススキャン、指紋、及び音声認識など、口座に関連した生物測定データを使用することによって支払いを許可する動作が含まれる。支払いは、口座番号とワンタイム・パスワードの組合せによって許可されることもある。このワンタイム・パスワードはトークンによって又は電話、イーメール、又はショート・メッセージ・サービス（「ＳＭＳ」）を介して提供される。
【００３２】
簡単に前述されたように、種々の実施形態によるこの金融取引システムは、（１）参加者に対して動作及び処理プロトコルを、また（２）金融取引を高度のセキュリティを用いて処理するように適合された自動監視及び処理システム（例えば、コンピュータのソフトウェア及び／又はハードウェア）を提供する。これらのプロトコル及び自動システムは、電子商取引において危険を招く可能性がある不正な取引や他の悪用から顧客及び参加者を保護するように機能する。システムが実行するプロトコルの種々の実施例は、以下のＡ節で詳細に説明され、自動システムの種々の実施形態は下記のＢ節で説明される。金融取引システムを通して処理される様々な取引の代表的な流れは、Ｃ節でより詳細に説明される。
【００３３】
Ａ．代表的なプロトコル
この金融取引システムの種々の実施形態により、参加者に対する動作及び処理プロトコルが提供される。種々の実施形態によれば、これらのプロトコルは、組織犯罪や取引先との取引を用いるマネーローンダリング計画を阻止し、一般にオンライン金融取引に関連した不正で認められていない取引になる危険を減少させると共に、承継銀行及び発行銀行に対して損失が生じる危険を減少させ、そして政府又は地域の規制を順守する可能性が増加される目的を果たす。例えば、本発明の種々の実施形態によれば、参加者は地域の又は管轄の監督機関を順守することを実証できる必要があり、また特定の期間の間（例えば、２年、３年、又は５年）に処理された取引の検査可能な記録を保持する必要がある。さらに、プロトコルは各参加者が他の参加者と契約を締結する前に、地域の法的な要求事項の順守を実証することを要求し、またプロトコルは参加者が、他の参加者が地域の監督機関と良い状態にあることを定期的に検証することを要求する。取引先及びＩＰＳＰに対して確立される種々の例示的なプロトコルが、以下に説明される。
【００３４】
取引先
本発明の種々の実施形態によれば、取引先は会社の管理者、職員、及び受益株主（beneficial shareholder）の身元を全て開示し、またどのような変化もＩＰＳＰに報告することが要求される。このリストが提供されることを要求すること、またこのリストを組織犯罪に関連していると疑われた人及び事業体のリストと比較することは、組織犯罪の仲間がマネーローンダリング又は他の不法な目的のために取引先の事業を使用することを阻止するために有用である。
【００３５】
さらに、本発明の種々の実施形態によれば、取引先は、承継銀行、発行銀行、及び顧客に対して不正取引からの損失が生じる危険を減らすために役に立つ１つ以上の措置を取るように要求される。例えば、種々の実施形態によれば、取引先は、（１）全ての関連した法的な要求事項を順守することを実証すること、（２）何らかの契約上の義務が破られたときには罰金を支払うこと、（３）オンライン取引の間に提供された支払い情報及び顧客情報を検証するために、取引先のコンピュータ装置上でアドレス検証、年令検証、及び身元検証用ソフトウェアを使用すること、（４）受信された支払い及び顧客情報に対して初期不正チェックを実行し、またその後で無作為に又は定期的にチェックを実行すること、又は（５）ＩＰアドレスを用いてシステムにアクセスする顧客、又は取引が不正と考えられる管轄に関連した請求書送付先を提供する顧客に注意すること、が要求される。
【００３６】
さらに、種々の実施形態によれば、取引先は、取引先の事業に関連して不正使用が生じる危険を緩和する、すなわち不正使用がある場合、取引先と取引を行うことが明らかにされた社会的な影響を緩和するプロトコル（例えば、取引先がオンラインゲームの業者であるか又は成人向けの娯楽の提供者である場合は、強制的な支出）を実行するように要求される。例えば、取引先は、その事業の社会的な影響に関して忠告及び支援のリソース（例えば、ヘルプラインや有用な情報を与えるウェブサイト用の無料通話の電話番号、又はカウンセラーについての窓口案内）を提供するように要求される。さらに、１つの実施形態によれば、取引先は、顧客が顧客サービスを呼んで取引に関する問合せを行うために、顧客の支払いカードのステートメントに対して取引先の名前及び無料電話番号を提供するように要求される。本発明の種々の実施形態によれば、顧客サービスの代表者は、２４／７を利用できる。
【００３７】
ＩＰＳＰ
本発明の種々の実施形態によれば、ＩＰＳＰは、組織犯罪の集団などがマネーローンダリングをするために取引先の事業を用いることを阻止することに役立つために、また種々の参加者に対してオンライン金融取引に関連した危険を減らすために、１つ以上の下記の安全対策を実行するように要求される。すなわち、これらの安全対策は、（１）払い戻し要求を処理する各取引先に対して、前述された回転保存エスクロー勘定を設定すること、（２）不審な行動を特定するために取引を監視すること、（３）支払いカードベース当たりの取引の回数及び金額を監視すること、（４）追跡及び監査するために、別個の流れの中で各取引先（又はウェブサイト）に対する取引を継続すること、（５）特定の期間（例えば、１年、２年、又は５年）にわたって監査トライアル（audit trial）を作り取引情報を記憶するために、取引情報を定期的（例えば、２秒又は１０秒ごと）にセーブすること、（６）カード所有者の身元を確認すること、（７）ＩＰＳＰに対して会社の管理者及び受益株主を開示するように取引先に要求すること、（８）インターネットのギャンブル業者からカード所有者に対する賞金の支払いを制限すること、及び該当する許可リスト（sanction list）（例えば、米国における「特別指定国家リスト」）に対して受取人の名前を審査すること、（９）適切な地域の法律及び規制のもとで許可を受けるように、また金融及び法律上の良い状態を保つように取引先に要求すること、（１０）契約上の義務に違反していることが判明した業者を罰する（例えば、業者との契約を終了する又は業者に罰金を科することによって）こと、（１１）良く規制された管轄の中で動作する幾つかの層１の（Tier 1）承継銀行を用いて、それらの銀行に認定されること、（１２）セキュリティ保護されたカード所有者の情報を保持するために、取引先が方式、手順及び規格を実行することを要求すること（例えば、ビザ（VISA）の口座情報セキュリティ（「ＡＩＳ」）プログラムによって認定されること）、そして（１３）マネーローンダリングに関する金融活動作業部会（Financial Action Task Force on Money Laundering）の勧告（例えば、www.FATF-GAFI.org）を運用及び適用することである（例えば、付属書Ａに添付したInternational Monetary Fundによって公表された「Anti-Money Laundering/Combating Terrorist Financing Methodology (with FATF 40+9 incorporated)」を参照されたい）。さらに、種々の実施形態では、不正であることが判明した又は不正であると決定された、ＩＰＳＰによって処理された取引に関する情報を記憶するために、ＩＰＳＰは図１に示されている不正用データベース４２保持している。１つの実施形態によれば、ＩＰＳＰにより、参加者が取引を処理するときにこの不正用データベースを使用できるようになるため、発行銀行、承継銀行、取引先、及び顧客に対して損失が生じる危険を更に減らすことができる。ＩＰＳＰは自身の口座や不正用データベースを管理し、処理する取引を調停し、また取引先に対して一致報告書を発行することができるが、別の実施形態によれば、ＩＰＳＰは１つ以上のこれらのサービスを提供するために、ＡＳＰと契約することができる。
【００３８】
さらに、本発明の１つの実施形態による例示的なプロトコルは、ＩＰＳＰが各取引先に対して別個の企業体（例えば、ＳＧ１、ＳＧ２、ＳＧ３、など）を作り、これらの企業体がＩＰＳＰ及び／又はＡＳＰの指揮の下で、企業体に関連した特定の取引先に対して受信された資金を管理するように動作することを要求する。このことは、図１４に関連してより詳細に説明される。種々の実施形態によれば、この事業形態は、各取引先の動作を分離する。さらに、種々の実施形態によれば、この事業形態は、この事業形態により、金融取引システム及び顧客を保護するために保持されているエスクロー資金を確実に公正で客観的に制御する合法的な形態が提供される。
【００３９】
承継銀行
本発明の種々の実施形態によれば、例示的なプロトコルは、発行銀行及び顧客に対してオンライン取引に関連した危険を減少させるために、承継銀行が１つ以上の下記の安全対策を実行するように要求する。すなわち、これらの安全対策は、（１）顧客が確実に賞金又はクレジットを取引先から自身の支払いカードに受け取ることができるように、オンライン取引先のクレジット活動を監視すること（例えば、VISAが後援しているクレジット所有者資金移動（cardholder funds transfer）（ＣＦＴ）パイロット及びMasterCardが後援しているマネー・フロー・パイロット）、（２）全てのカード機構に対する規定（card scheme regulation）がＩＰＳＰと取引先に確実に伝達されること、（３）取引情報がカード機構及び発行銀行によって指示された正しいデータ要素を確実に有していること、そして（４）ＩＰＳＰが該当する規制体系を確実に順守することである。
【００４０】
参加者の間の協定
本発明の種々の実施形態によれば、１つ以上のシステムプロトコルが参加者間の協定に組み込まれて、確立されたプロトコルを確実に順守するようにされる。例えば、図２は、本発明の種々の実施形態に基づいて、参加者間の契約関係の概略図を例示している。特に、承継銀行３６、ＩＰＳＰ３４、及び各取引先３１、３２、３３は、三者間処理契約（three-way processing contract）４５に参加することができる。この三者間処理契約は、取引を処理する方法に関して各当事者の義務を示している。この協定４５は各当事者に、地域の監督機関と良好な関係を保つこと、職員、管理者、及び受益株主の更新されたリストを別の関係者に提供すること、取引情報に対して身元の検証及び不正行為の調査を行うこと、及び特定の期間（例えば、１年、３年、５年）にわたって取引情報を保存することを要求する。さらに、１つの実施形態によれば、協定４５は、取引先が払い戻し要求を議論することができる１つ以上の場所を備えることができる。別の実施形態によれば、協定４５は、不渡りのために取引先３１、３２、３３に対して請求できる料金を定めることができる。
【００４１】
さらに、承継銀行３６及び合え４は、信託契約４７に加入することができる。この信託契約４７は、ＩＰＳＰが各取引先のために精算を要求したとき（例えば、毎日又は毎週）、ＩＰＳＰが取引データ上で実行すべき特定の不正チェックを行う。
【００４２】
ＡＳＰ３５及び取引先３１、３２、３３は、エスクロー契約４９に加入することができる。このエスクロー契約４９は、どのようにＡＳＰが取引先のために回転保存エスクロー勘定を管理するかを示している（例えば、エスクロー勘定に対して取り出される資金の割合、その資金がエスクロー勘定に保管される期間、又は一致報告書の書式）。
【００４３】
さらに、ＡＳＰ３５及びＩＰＳＰ３４は、サービス契約４３に加入することができる。このサービス契約４３は、ＡＳＰがＩＰＳＰに提供した会計サービスに関連した各当事者の義務を示している（例えば、ＡＳＰとＩＰＳＰとの間で交換されたデータの書式及び接近可能性、ＡＳＰがＩＰＳＰ３４に対して又はＩＰＳＰ３４のために作成した概略報告の種類及び書式、１人以上の参加者に支払うことができる料金の計算、又は取引先に対して一致報告書を承認するための承認手順）。その他に、１つの実施形態では、ＡＳＰ３５は契約４３によって、ＩＰＳＰ３４又はＩＰＳＰ３４の代わりにＡＳＰ３５によって処理された取引に関して、取引先３１、３２、３３からの問合せに応答するように要求される。さらに、別の実施形態では、ＡＳＰ３５は、（ａ）入金取消し要求に関連した、ＩＰＳＰ３４の代わりにＡＳＰ３５によって処理された全ての取引データを識別するように、また（ｂ）この識別されたデータを取引先３１、３２、３３に転送して、入金取消し要求に関連して取引先３１、３２、３３が行うことを希望するさらに別の動作は、もしあれば、何であるかを確認するように要求される。
【００４４】
Ｂ．取引を監視及び処理するための自動システム
当業者によって明らかなように、本発明は、方法、取引処理システム、又はコンピュータプログラム製品として具体化される。従って、本発明は完全にハードウェアの実施形態、完全にソフトウェアの実施形態、又はソフトウェアとハードウェアの態様を組み合わせた実施形態の形をとることができる。さらに、本発明は、記憶媒体の中で具体化されたコンピュータが読取り可能な記憶媒体（例えば、コンピュータソフトウェア）上でコンピュータプログラム製品の形をとることができる。より具体的に説明すると、本発明は、ウェブで実行されるコンピュータソフトウェアの形をとることができる。ハードディスク、ＣＤ−ＲＯＭ、光記憶装置、又は磁気記憶装置を含む任意の適当なコンピュータが読取り可能な記憶媒体を使用することができる。
【００４５】
本発明の実施形態に基づいて、方法、装置（すなわち、システム）及びコンピュータプログラム製品のブロック図及びフローチャートを参照して、本発明は下記のように説明される。ブロック図及びフローチャートの各ブロック、及びブロック図及びフローチャートの中のブロックの組合せは、それぞれコンピュータプログラム命令が実行することができることは理解されよう。これらのコンピュータプログラム命令は、汎用コンピュータ、特殊目的のコンピュータ、又は他のプログラム可能なデータ処理装置にロードされて、コンピュータ又は他のプログラム可能なデータ処理装置上で実行されるこれらの命令が、フローチャートのブロックの中で指定された機能を実行するための手段を作り出すような装置を作る。
【００４６】
コンピュータ又は他のプログラム可能なデータ処理装置を特定の方法で機能させることができるこれらのコンピュータプログラムの命令を、コンピュータが読取り可能なメモリの中に記憶して、コンピュータが読取り可能なメモリの中に記憶された命令が、フローチャートのブロックの中で指定された機能を実行するコンピュータが読取り可能な命令を含む製品を作ることもできる。コンピュータプログラムの命令をコンピュータ又は他のプログラム可能なデータ処理装置にロードし、一連の動作ステップをコンピュータ又は他のプログラム可能な装置上で実行させて、コンピュータの実行による処理を行い、コンピュータ又は他のプログラム可能な装置上で実行される命令がフローチャートのブロックの中で指定された機能を実行するステップを提供することもできる。
【００４７】
従って、ブロック図及びフローチャートのブロックは、指定された機能を実行する手段の組合せ、指定された機能を実行するステップの組合せ及び指定された機能を実行するプログラム命令の手段に対応する。ブロック図及びフローチャートの各ブロック及びブロック図及びフローチャートの中のブロックの組み合わせは、指定された機能若しくはステップ、又は特殊目的のハードウェア及びコンピュータ命令の組み合わせを実行する特殊目的のハードウェアベースのシステムによって実行されることができることも理解されよう。
【００４８】
本願で説明される種々の実施形態では、「コンピュータ」又は「コンピュータ装置」という用語が参照される。そのようなコンピュータは、例えば、メインフレーム、ディスクトップ、ノートブック又はラップトップ、データ収集・記憶装置などの手持ち式装置（hand held device）とする、又は例えば無線電話などの他の装置の中に組み込まれた処理装置とすることができる。幾つかの具体例では、コンピュータは、ネットワークを介してデータ又はプロセッサにアクセスするために使用される「ダム」ターミナルとすることができる。図３Ａを参照すると、本発明の種々の実施形態の態様を実行するために使用できるコンピュータ装置の１つの実施形態が例示されている。図３Ａでは、定義されたステップを実行するために、マイクロプロセッサなどのプロセッサ１が、ソフトウェア命令を実行するために使用される。このプロセッサは電源装置１７から給電され、電源装置１７は必要な場合、他の構成要素にも電力を供給する。プロセッサ１は、一般に１６又は３２ビット幅（例えば、並列）のデータバス５を用いて通信する。このデータバス５は、主としてプロセッサとメモリとの間にデータやプログラム命令を運ぶために使用される。種々の実施形態では、メモリは、動作している間のみコンテンツを保持するＲＡＭ又は他の形態の主記憶装置２と考えられる。又はメモリは常にメモリのコンテンツを保持するＲＯＭ、ＥＰＲＯＭ、ＥＥＰＲＯＭ、フラッシュ、又は他の種類のメモリなどの不揮発性メモリ３とすることができる。メモリは、多量のデータを記憶するディスク記憶装置などの補助記憶装置４とすることもできる。幾つかの実施形態では、このディスク記憶装置は、専用バス（図示せず）の代わりにＩ／Ｏバス６を用いてプロセッサと通信することができる。補助記憶装置は、フロッピー（登録商標）ディスク、ハードディスク、コンパクトディスク、ＤＶＤ、又はコンピュータ技術に熟練している人には周知の他の任意の種類の大量記憶装置とすることができる。
【００４９】
プロセッサ１は、Ｉ／Ｏバス６を用いて様々な周辺機器又は外部装置とも通信する。種々の実施形態では、周辺Ｉ／Ｏコントローラ７が、種々の入力／出力装置を接続するために適当なＲＳ−２３２、ＲＳ４２２、ＤＩＮ、又は他のインターフェースなどの標準的なインターフェースを提供するために使用される。代表的な入力／出力装置には、ローカルプリンタ１８、モニタ８、キーボード９、及びマウス１０又は他の一般的なポインティング装置（例えば、ローラーボール、トラックパッド、ジョイステックなど）が含まれる。
【００５０】
プロセッサ１は、多くの場合、通信Ｉ／Ｏコントローラ１１を用いて外部通信ネットワークとも通信し、またＸ．２５、ＩＳＤＮ、ＤＳＬ、ケーブルモデムなどのデータ通信指向のプロトコル１２など種々のインターフェースを使用することができる。この通信コントローラ１１は、標準的な通信回線１３とインターフェースで接続しかつ通信するために、モデム（図示せず）を組み込むこともできる。最後に、この通信Ｉ／Ｏコントローラは、ＬＡＮを介して通信するために、イーサネット（登録商標）用インターフェースを組み込むことができる。これらのインターフェースのいずれかは、インターネット、イントラネット、ＬＡＮ、又は他のデータ通信機器などの広域ネットワークにアクセスするために使用することができる。
【００５１】
さらに、プロセッサ１は、無線インターフェース１６と通信することができる。この無線インターフェース１６は、例えばＩＥＥＥ ８０２．１１プロトコル、８０２．１５．４プロトコル、又はＣＤＭＡ２０００ １ｘ ＥＶ−ＤＯ、ＧＰＲＳ、Ｗ−ＣＤＭＡ、又は他のプロトコルなどの標準的な３Ｇ無線電気通信プロトコルの１つを用いて、他の装置と無線で通信するためにアンテナ１５と動作可能なように接続される。
【００５２】
使用できる処理システムの別の実施形態は、図３Ｂに示されている。この実施形態では、ローカルクライアント用コンピュータ２６ａ又はリモートクライアント用コンピュータ２６ｂのどちらかと通信するサーバ２０を含む分散型通信及び処理アーキテクチャが示されている。このサーバ２０は、主として、データベース２２（例えば、ＳＱＬデータベース）と通信するプロセッサ２１を備えている。このデータベース２２は、主記憶装置２４の形態だけではなく補助記憶装置の形態とみなすことができる。このプロセッサは、通常はＬＡＮ２５と接続するＩ／Ｏコントローラ２３を用いて、外部装置とも通信する。このＬＡＮは、ネットワークで結ばれたプリンタ２８及びローカルクライアント用コンピュータ２６ａに対する接続性を提供する。これらの装置は、必ずしも同じ部屋の中に配置する必要はないが、サーバと同じ施設の中に配置できる。リモート装置との通信は主として、ＬＡＮ２５から通信機器を介してインターネットなどのワイドエリアネットワーク２７にデータを方向付けることによって達成される。リモートクライアント用コンピュータ２６ｂはウェブブラウザを実行して、このリモートクライアント用コンピュータ２６ｂが、必要に応じて、データをワイドエリアネットワーク２７を通りＬＡＮ２５を介してサーバ２０に送信することによって、サーバとの相互作用ができるようにする。さらに、ウェブブラウザは、例えば、Java（登録商標） Script and Microsoft.netで開発されたユーザーインターフェースを備えることができる。
【００５３】
データネットワークの技術に優れた人は、多くの別の代わりの技術やアーキテクチャも実行可能であり、また本発明の種々の実施形態を実行するために使用できることを理解するであろう。図３Ａ及び図３Ｂで例示された実施形態は、様々な方法でまた本発明の範囲の中で修正することができる。
【００５４】
図４は、本発明の種々の実施形態に基づいて、各参加者と関連付けられ、また１つ以上のネットワーク１１５（例えば、プライベートネットワーク、プライベートＬＡＮネットワーク、又はインターネット）を介して互いに通信するコンピュータ装置１０１〜１０９を例示している。例えば、１つの実施形態によれば、ＩＰＳＰ３４は、ＩＰＳＰゲートウェイ４０を介して取引先３１、３２、３３及び承継銀行３６にアクセス可能であり、このＩＰＳＰゲートウェイ４０は、ＩＰＳＰネットワークを取引先３１、３２、３３及び承継銀行３６が利用しているネットワークに接続している。種々の実施形態によれば、ＩＰＳＰゲートウェイ４０は、ハードウェア、ソフトウェア、又はそれらの両者の組合せとして完全に実現することができる。１つの実施形態では、このＩＰＳＰゲートウェイ４０は、ＩＰＳＰネットワークへのアクセスを選択的に許可することによって、ＩＰＳＰ３４にまたＩＰＳＰ３４から送信された情報のセキュリティを確実にしている。例えば、ＩＰＳＰ３４と契約関係がない取引先３１、３２、３３及び承継銀行３６は、ＩＰＳＰゲートウェイ４０によってＩＰＳＰネットワークへのアクセスが拒絶される。
【００５５】
さらに、本発明の種々の実施形態によれば、承継銀行３６はカード機構用ネットワークを利用して、発行銀行３７、３８、３９と情報を交換することができる。カード機構用ネットワークの実施例には、ビザ、マスタカード、及びアメリカンイクスプレスのネットワークが含まれるが、これらに限定されることはない。
【００５６】
図３Ａ及び図３Ｂに関連して前に説明したように、種々の実施形態によれば、取引先３１、３２、３３、ＩＰＳＰ３４、承継銀行３６、及び発行銀行３７、３８、３９は、１つ以上のコンピュータ装置（例えば、１つ以上のサーバ、ＳＱＬサーバ、又はウェブサーバ）に関連付けられ、また１つ以上のこれらのコンピュータ装置は、金融取引を処理するために自動システムを備えることができる。例えば、システム１００は、取引先のシステム１０１、１０２、１０３上で動作するように構成された取引先用モジュール２００、ＩＰＳＰのシステム１０４上で動作するように構成されたＩＰＳＰ用モジュール、及びＡＳＰのシステム１０５上で動作するように構成されたＡＳＰ用モジュールを提供する。これらのモジュール２００、３００、４００は、１つの実施形態によれば、各参加者に対する処理機能を自動化する。これらのモジュールは、ハードウェア、ソフトウェア、又はそれらの両者の組合せとして完全に実現することができる。
【００５７】
さらに、１つの実施形態によれば、このＡＳＰ用モジュール４００は、ＩＰＳＰ３４がＡＳＰ３５と契約して口座関連のサービスを提供する場合は、ＡＳＰシステム１０５上で動作するように構成することができ、又は別の実施形態では、ＡＳＰ用モジュール４００は、ＩＰＳＰのシステム１０４上で動作するように構成することができる。これらのモジュールの種々の実施形態は、図５〜図８に関連して以下により詳細に説明される。
【００５８】
取引先用モジュール
図５は、本発明の種々の実施形態による取引先用モジュール２００のブロック図を例示している。種々の実施形態によれば、取引先用モジュール２００は、取引先のシステム１０１、１０２、１０３上で動作し、取引先が取引を処理するために実行する工程の少なくとも一部を自動化する。例えば、この取引先用モジュール２００は、ステップ２０２として示される許可要求を処理するように構成される。ステップ２０２では、取引先用モジュール２００は、顧客から支払い要求を受け取る。この支払い要求には、顧客の氏名、請求書送付先、イーメールアドレス、クレジットカード番号、ＣＶＶ２番号、支払い金額、又はカード発行会社名の幾つか又は全てが含まれている。次に、この取引先用モジュール２００は、クレジットカードの番号が有効な番号であるかどうか、また全ての欄が吸入されているかどうかを検証することなどにより、受信した支払い情報の書式を検証する。この取引先用モジュール２００は、顧客情報を３Ｄ秘密ソフトウェア・プラグイン（3-D secure software plug in）に関連して前に記憶した識別番号及びパスワードと比較するようにさらに構成される（例えば、Visaによる検証及びMasterCardによるSecureCode）。書式が正しい場合、取引先用モジュール２００は許可要求を発生し、それをさらに処理するためにＩＰＳＰシステム１０４に送る。
【００５９】
本発明の種々の実施形態によれば、この取引先用モジュール２００はまた、ステップ２０６で示されているように、受け取った取引要求に対して基本的な不正チェックを実行するように構成される。この基本的な不正チェック用ステップ２０６は、例えば、クレジットカード番号を盗まれたクレジットカード番号のリストと比較する動作、顧客によって与えられた請求書送付先が支払いカード用の請求書送付先と一致することを確認する動作、与えられた請求書送付先を顧客が最初に取引先に登録したときに提供した請求書送付先と比較する動作、又はカード発行会社名がそのカード用の銀行照合番号（ＢＩＮ）と一致することを検証する動作を含むことができる。さらに、不正チェック用ステップ２０６は、図５に示されているように、許可要求がＩＰＳＰに送られた後で（ステップ２０２）、又は許可要求を作成及び送信する前に実行される（図示せず）。１つの実施形態では、不正チェック用ステップ２０６は、許可要求が送信された後（ステップ２０２）であるが、発行銀行との合意の前に実行される。
【００６０】
潜在的な問題が不正チェック用ステップ２０６で発見されない場合は、取引先用モジュール２００は、ステップ２１０で示されているように、顧客の年令と身元を検証する。例えば、年令は、有権者登録の記録又は運転免許証の記録などのカード所有者に関する政府の記録を確認することによって、又は電子年令及び／又は身元確認サービス（例えば、ＵＫベースのＧＢグループが提供する「ＵＲＵ」サービス）とネットワーク接続を確立し、そして顧客の情報をこのサービスに与えることによって検証される。このサービスは、種々の実施形態によれば、顧客の情報を政府又は他の公文書と比較して、公共の身元と年令を検証する。１つの実施形態では、取引先用モジュール２００は、顧客が取引先に対して新しい口座を設立しているときに、年令・身元検証ステップ２１０を実行することができる。ステップ２１０の処理は、定期的に繰り返されるか、又は後で無作為に現在の顧客の身元及び年令を再検証する。さらに、図５に示されている実施形態では、年令・身元検証ステップ２１０は、不正チェック用ステップ２０６及び承認要求ステップ２０２の後で発生するように示されている。しかしながら、別の実施形態では、この年令・身元検証ステップ２１０は、承認要求ステップ２０２又は不正チェック用ステップ２０６の前に行うことができる。
【００６１】
顧客の年令及び身元が年令・身元検証ステップ２１０で検証されない場合、又は不正チェック用ステップ２０６が取引に関する潜在的な問題を発見した場合は、取引先用モジュール２００は、１つの実施形態によれば、ステップ２０８に示されているように、顧客に取引は拒絶されると知らせ、またＩＰＳＰに取引を拒絶すべきであると通知する。
【００６２】
さらに、種々の実施形態による取引先用モジュール２００は、特定の期間（例えば、セッション当たり、２４時間、又は１週間）取引先のウェブサイト上で使った金額を顧客に表示又は通知するように構成される。この情報により、顧客は取引先のウェブサイトに関連した強制的な行動を避けることができる。その上、取引先用モジュール２００は、取引先が維持している顧客に対する取引ログに顧客がアクセスできるように構成される。さらに、取引先用モジュール２００は、例えば、損失限界（例えば、ギャンブル取引）又はこの取引先のウェブサイトで使った時間及び／又は金額などに対して自主規制のガイドラインを構築するように構成される。
【００６３】
マネーローンダリングを防ぐために、この取引先用モジュール２００は、選択された金額（例えば、１５．０００ドル又は２０，０００ドル）を超える全ての取引を検査するために、マネーローンダリング防止用ソフトウェア（例えば、有効なデータを、付属書Ａとして添付された、International Monetary Fundが公表している「Anti-Money Laundering/Combating Terrorist Financing Methodology (with FATF 40+9 incorporated)」の中に記載されているパラメータと比較するソフトウェア）を実行するようにさらに構成することができる。ソフトウェアによる検査には、身元確認及び再確認、続いて検証された個人又は会社に対する確認がある。
【００６４】
ＩＰＳＰモジュール
図６は、本発明の種々の実施形態によるＩＰＳＰモジュール３００のフローチャートを例示している。１つの実施形態によれば、このＩＰＳＰモジュール３００は、ＩＰＳＰシステム１０４上で動作するように構成される。ステップ３０２で動作が開始すると、１つの実施形態によれば、ＩＰＳＰモジュール３００は、取引先のシステム１０１、１０２、１０３から受け取った許可要求を処理する。各許可要求には、特定の取引に対する支払い情報、及び顧客の氏名、顧客のイーメールアドレス、及び取引を開始するために顧客が使用するコンピュータ装置のＩＰアドレスなどの取引に関連する顧客情報が含まれる。本発明の種々の実施形態によれば、このＩＰＳＰモジュール３００は次に、許可要求を承継銀行のシステム１０６に送り、この承継銀行のシステム１０６はこの許可要求を該当する発行銀行のシステム１０７、１０８、１０９に転送する。図９Ａ及び図９Ｂに関連して以下により詳細に説明するが、種々の実施形態によれば、ＩＰＳＰモジュール３００は、発行銀行のシステム１０７、１０８、１０９から承継銀行のシステム１０６を介して、取引を許可する又は拒絶すると記載された許可メッセージを受け取り、その許可メッセージを取引先のシステム１０１、１０２、１０３に送る。
【００６５】
種々の実施形態によれば、ステップ３０４では、ＩＰＳＰモジュール３００は、自身が処理した取引情報（例えば、許可要求、入金取消し要求、払い戻し要求、及び決済要求）を保存する。この保存された取引情報は、会計監査の目的、顧客当たり、支払いカード当たり、又は取引先ベース当たりの取引の種類及び頻度を監視するため、及び決済要求を作成して、この決済要求に応じて受け取った資金の支払いを割り当てるために使用することができる。例えば、許可、入金取消し、及び払い戻し要求は、定期的に、例えば毎秒又は１０秒ごと、又はＩＰＳＰモジュール３００が受信しそして取引情報を処理するたびといった取引ベース当たりに保存することができる。これらの要求は、ある期間（例えば１日又は１週間又はそれ以上）保存することができる。さらに、種々の実施形態によれば、取引先が電子商取引に対応する１つ以上のウェブサイトを有する場合、これらの要求を取引先ベース当たり（又はＵＲＬ (ユニフォーム・リソース・ロケータ）（Uniform Resource Locator）当たり）で保存することができる。このＩＰＳＰモジュール３００は、各取引先に対する許可要求を定期的（例えば、毎日又は毎週）に各取引先に対する決済要求ファイルの中に集めて、この取引先に対する決済要求をバッチファイルの形で、決済するために承継銀行のシステム１０６に送る。このことは、ステップ３１０に関連して以下に説明される。このＩＰＳＰモジュール３００は、グループ化した取引情報を別個のファイルとして一定の期間（例えば、１年、２年、又は３年）保存することができる。
【００６６】
本発明の種々の実施形態では、ＩＰＳＰモジュール３００はまた、不正防止用サブシステム３５０を実行するように構成される。このことは、図６のステップ３０６として示され、また取引はシステム１００による決済を受ける必要があることを確認するために、図７Ａ及び図７Ｂに関してより詳細に以下に説明される。例えば、支払いカード番号が盗まれた支払いカード番号のリストに列挙されている、顧客のＩＰアドレスの国が支払いカードが発行された国と一致していない、又は顧客が国家制裁リスト（national sanctions list）（例えば、米国の「Specially Designated Nationals list」）に載っている場合、ＩＰＳＰモジュール３００は取引を決済するために提出しない。図６に示されている実施形態では、不正防止用サブシステム３５０の実行は、許可要求処理ステップ３０２及び取引情報保存ステップ３０４の後で生ずるように示されている。しかしながら、本発明の別の実施形態によれば、ステップ３０２において許可要求を承継銀行のシステム１０６に送る前に、又はステップ３０４において取引情報を保存する前に、ＩＰＳＰモジュール３００はステップ３０６を実行することができる。
【００６７】
本発明の種々の実施形態によれば、不正防止用サブモジュール３５０が、ステップ３０６において取引に対する潜在的な不正行為を検出した場合、ＩＰＳＰモジュール３００は、ステップ３０８に示されているように、該当する当事者に疑わしい不正行為を通知するように構成されている。この該当する当事者には、種々の実施形態によると、承継銀行３６（この銀行は、通知を発行銀行に送る）、発行銀行３７、３８、３９（直接接続されている）、取引先３１、３２、３３、及び／又は顧客が含まれる。さらに、ＩＰＳＰモジュール３００は、種々の実施形態によれば、ステップ３１２に示されているように、潜在的に不正な取引に関する情報を不正用データベース４２に記憶する。この不正用データベース４２は、後続する取引を分析するために、ＩＰＳＰモジュール３００に利用される。さらに、１つの実施形態では、不正用データベース４２は、カード発行会社ネットワーク及び／又は承継銀行にアクセスして、受信された取引を分析することができる。さらに、この不正用データベース４２は、１つ以上の下記の欄、すなわち、顧客の名前、住所、ＩＰアドレス、支払い情報（例えば、カード又は口座番号）、電話番号、及び前の不正行為を識別するコード又は説明を含むことができる。
【００６８】
ステップ３１０に示されているように、不正防止用サブモジュール３５０がステップ３０６において潜在的な不正行為を検出しない場合は、ＩＰＳＰモジュール３００は、種々の実施形態によれば、決済要求を作成して、それを承継銀行のシステム１０６又は発行銀行のシステム１０７、１０８、１０９に送信する。この決済要求は、特定の期間（例えば、１日又は１週間）の間にＩＰＳＰモジュール３００が受け取った許可、入金取消し、及び払い戻し要求に基づいている。決済要求には、１つの実施形態によれば、ＩＰＳＰモジュール３００及び取引先用モジュール２００により潜在的な不正行為として検出されなかった取引のみが含まれる。別の方法では、決済要求には、ＩＰＳＰモジュール３００又は取引先用モジュール２００により潜在的に不正であるとして検出された１つ以上の取引が含まれるが、それらの取引は潜在的に不正であるとして決済要求の中でマークされるか又はフラグが立てられる。
【００６９】
前述したように、ＩＰＳＰモジュール３００は、ステップ３０６で不正防止用サブモジュール３５０を実行する。本発明の種々の実施形態による例示的な不正防止用サブモジュール３５０が、図７Ａ及び図７Ｂに示されている。図７Ａに示されているように、この不正防止用サブモジュール３５０は、本願で「不正検出フィルタ」と呼ばれる種々のステップを実行して、潜在的に不正な取引行為を検出し、特定の不正検出フィルタの結果又は不正検出フィルタのグループの結果の組合せにより取引を阻止する又はその取引にフラグを立てるように構成される。ステップ３５２〜３６８は、本発明の種々の実施形態によれば、不正防止用サブモジュール３５０によって実行される幾つかの不正検出フィルタを示す。図７Ｂは、どの不正検出フィルタを取引情報に適用するかを決定するために、不正防止用サブモジュール３５０によって実行されるステップを例示している。
【００７０】
例えば、図７Ａのステップ３５２に示されているように、この不正防止用サブモジュール３５０は、支払いカードの情報を盗まれた支払いカードを識別するリストと比較することができる。さらに、ステップ３５４に示されているように、不正防止用サブモジュール３５０は、支払いカードを発行した金融機関に関連した位置を、顧客のコンピュータ装置に関連したＩＰアドレスに対応する位置と比較することができる。顧客のコンピュータ装置に関連したＩＰアドレスは、取引情報を取引先のシステム１０１、１０２、１０３が最初に受信したときに、取引先用モジュール２００によって（例えば、取引先用モジュール２００の中に組み込まれたＩＰアドレス検出用ソフトウェアを用いることによって）得ることができる。さらに、不正防止用サブモジュール３５０は、顧客のコンピュータ装置のＩＰアドレスに関連した位置を顧客の請求書送付先と比較して、顧客のコンピュータ装置の位置が請求書送付先の特定の半径内にある（例えば、５０マイル）ことを確認する。同様に、不正防止用サブモジュール３５０は、ステップ３５６に示されているように、支払いカードを発行した金融機関に関連した位置を、顧客が与えたイーメールアドレスに関連した位置と比較する、又はステップ３５７に示されているように、顧客のコンピュータ装置のＩＰアドレスの位置を、顧客が与えたイーメールアドレスに関連した位置と比較することができる。上記で比較された位置は、１つ以上の国、地方、州、地域、郡、市、又は１つ以上の郵便番号によって定義された郵便区域を含むことができる。
【００７１】
さらに、ステップ３５８に示されているように、不正防止用サブモジュール３５０は、支払いカードの銀行識別番号（ＢＩＮ）を疑わしいＢＩＮのリストと比較することができ、またステップ３６０では、この不正防止用サブモジュール３５０は、ウェブメールのイーメールアドレス（例えば、HOTMAIL 又は YAHOOのイーメールアドレス）を有する顧客が開始した取引を識別して、それにフラグを立てることができる。さらに、ステップ３６２に示されているように、不正防止用サブモジュール３５０は、顧客の情報を、政府の管轄内で取引先との金融取引に従事することを禁止されている人に対する政府編集のリストと比較することができる。顧客が、米国が発行した「Specially Designated Nationals list」のような司法権が発行した金融制裁を受ける人、グループ、及び事業体のリストで確認される場合、取引は拒絶される。同様に、ステップ３６８に示されているように、不正防止用サブモジュール３５０は、顧客のコンピュータ装置のＩＰアドレスに関連した国を、特定の管轄内で取引先と取引をすることを禁止されている国のリストと比較することができ、ＩＰアドレスの国がリスト上にある場合は、取引は拒絶される。さらに、ステップ３６７に示されているように、不正防止用サブモジュール３５０は、顧客の情報をオンライン取引先の職員、管理者、又は所有者のリストと比較することができ、顧客がこのリストに載っている場合は、取引は潜在的に不正であるとしてフラグが立てられるか又は拒絶される。
【００７２】
種々の実施形態によれば、不正防止用サブモジュール３５０は、ステップ３６４に示されているように、特定の期間（例えば、１月、１年）にわたって各顧客又は各カードに対する取引の回数を監視するようにさらに構成することができる。さらに、ステップ３６６に示されているように、不正防止用サブモジュール３５０は、特定の期間にわたって各顧客又はカードに対する取引の種類（例えば、ギャンブル取引、旅行の取引、成人向け娯楽の取引）を監視するように構成することができる。カード当たり又は顧客当たりのベースで取引の回数及び種類を監視することによって、不正防止用サブモジュール３５０は、本発明の種々の実施形態によれば、（１）カードを使用するパターンが劇的に変化する場合、カードの潜在的な不正使用を発見することができ、また（２）顧客がより頻繁に又はあまりにも頻繁に特定の種類の取引に従事する場合、潜在的な耽溺又は乱用を特定することができる。監視するステップ３６４及び３６６は、１つの実施形態によれば、顧客の前の取引に基づいて取引の頻度及び／又は種類の範囲を確立して、将来の取引を確立された範囲と比較することによって達成することができる。別の実施形態によれば、不正防止用サブモジュール３５０が使用する範囲は、学問的又は制度上の調査などの結果として、地方自治体又は監督機関によって発行されるか、又は１人以上の参加者によって確立される。
【００７３】
図１５は、本発明の種々の実施形態に基づいて、強制支出動作を監視する工程を例示している。特に、ステップ５０２で開始すると、ＩＰＳＰモジュール３００は、金融取引に対する新しい要求を受信する。この新しい要求を受信することに応じて、ＩＰＳＰモジュール３００は、ステップ５０４として示されているように、特定の取引先３１、３２、３３と顧客との間の前に要求された金融取引に関連して、メモリ２４に記憶されている資金の総額を取り出す。ステップ５０６では、引き出された資金の額と新しい要求に関わる資金の額の合計が、取引先３１、３２、３３に対して使われる資金の予め決められた許容限度と比較される。この合計が予め決められた許容限度を超える場合は、ＩＰＳＰモジュール３００は、ステップ５０８に示されているように、該当する当事者（例えば、顧客、発行銀行、及び／又は取引先）に限度が超過されたことを通知する。本発明の別の実施形態では、このＩＰＳＰモジュール３００は、特定の期間（例えば、２４時間、３６時間、１週間、１月、１年）にメモリに記憶されている資金の総額を取り出すことができる。さらに、別の実施形態では、ＩＰＳＰモジュール３００は、特定の期間に顧客と取引先との間で行われた取引の回数を比較して、行われた取引の回数が所定の限度を超えると、顧客、発行銀行、及び／又は取引先に限度が超過されていることを通知する。
【００７４】
同様に、図１６は、本発明の種々の実施形態に基づいて、強制的なギャンブル動作を監視する方法を例示している。ステップ６０２で開始すると、ＩＰＳＰモジュール３００は、金融取引に対する新しい要求を受信する。この新しい要求には、資金の総額及び取引の種類が含まれる（例えば、取引先への資金の移動、取引先への賭け金の入金、取引先からの支払い要求）。次に、ステップ６０４では、ＩＰＳＰモジュール３００は、新しい要求の中の金融取引の種類に対して、メモリ２４に記憶されている資金の総額を取り出す。次に、ステップ６０６では、資金の総額と新しい要求の中の資金の額の合計が、新しい要求の中の金融取引の種類に関連して予め決められた許容限度と比較される。この合計が予め決められた許容限度を超える場合は、ＩＰＳＰモジュール３００は、ステップ６０８に示されているように、該当する当事者（例えば、顧客、発行銀行、及び／又は取引先）に限度が超過されたことを通知する。１つの実施形態では、この合計が予め決められた許容限度を超える場合、新しい要求は拒絶される。さらに、メモリから取り出された資金の総額は、特定の期間内に記憶された資金に対して制限され、また予め決められた許容限度は問合せされた期間に基づいて変化される。
【００７５】
前述した取引の種類を監視することに加えて、本発明の種々の実施形態によれば、不正防止用サブモジュール３５０は、払い戻し要求の取引を監視して、疑わしい取引を特定するようにさらに構成される。払い戻し要求の情報が当初の取引の情報と一致しない取引を識別することによって、又は特定の期間（例えば、１週間、１月、又は数ヶ月内）に特定の支払いカードに対して著しい数の払い戻し要求があることを確認することによって、疑わしい払い戻し要求の取引を特定することを受けて、この支払いカードの番号を禁止された支払いカードのリストに加えて、この支払いカードを用いる将来の購入取引を回避することができる。
【００７６】
上記のフィルタに加えて、本発明の種々の実施形態によれば、不正防止用サブモジュール３５０は、（１）各顧客は確実に１枚の支払いカードしか使用しないようにする、また（２）各顧客に対する特定の取引行為を特定の期間当たり特定の回数（例えば、１日当たり１回の支払い又は３６時間当たり３回の支払い）にして、支払いを制限するようにさらに構成される。さらに、１つの実施形態によれば、特定の期間（例えば、１日、１週間、１ヶ月当たり）の特定のサービス（例えば、インターネットのゲーム又は成人向けの娯楽）に対して、カード当たり又は顧客当たりが費やす金額に上限を設定することができる。１つの実施形態では、この上限は顧客の要求に応じて設定することができる。別の実施形態では、ＩＰＳＰシステム１０４は、特定の活動に使うことができる金額に対してデフォルト限界（default limit）（例えば、支払いカードに関連した２０％のクレジット限界）を取り入れることができる。この限界は、顧客の明白な要求がない場合は増加することはできない。１つの実施形態によれば、ＩＰＳＰシステム１０４又は取引先のシステム１０１、１０２、１０３は、支出限度を増加するための要求に答えて、資力以上に金を使うことの危険に関して、特に訓練された従業員からの電話又は顧客に対するイーメールなどにより顧客に材料を提示するように、また潜在的な不正使用が検出されたときは材料又は情報源（例えば、Gamblers Anonymousの電話番号、ウェブサイトのアドレス、又は他の材料）を示すように構成することができる。
【００７７】
本発明の種々の実施形態によれば、ＩＰＳＰシステム１０４は、不正防止用サブモジュール３５０からの結果を記憶する不正及び不正使用データベース（図示せず）をさらに備えている。１つの実施形態では、ＩＰＳＰモジュール３００は、取引を処理するとき（ステップ３０２）又は不正防止用サブモジュールを実行するとき（ステップ３０６）にデータベースにアクセスして、特定の支払いカード又は顧客に対する以前の不正チェックに基づいて、取引を拒絶すべきかどうかを決定する。
【００７８】
図７Ｂに示すように、不正防止用サブモジュール３５０は、本発明の１つの実施形態によれば、１つ以上の前述した不正検出フィルタを使用して、受信された取引情報を評価する。ステップ３７０で開始すると、この不正防止用サブモジュール３５０は、ＩＰＳＰモジュール３００から取引データを受け取る。次に、ステップ３７２において、不正防止用サブモジュール３５０は、取引データの評価に使用するために１つ以上の不正検出フィルタを決定する。例えば、１つの実施形態によれば、不正防止用サブモジュール３５０は、使用される取引先によって前もって選択された不正検出フィルタを使用する。別の実施形態によれば、使用される不正検出フィルタの種類は、取引の種類（例えば、許可要求、入金取消し要求、決済要求、又は支払い要求）又は取引の段階（例えば、取引情報が発行銀行にまだ送られていないかどうか、又はそれが発行銀行によってすでに許可されているかどうか）に依存する。さらに別の実施形態では、使用される不正検出フィルタの種類は、顧客に関連したＩＰアドレスの国に依存する。そして、別の実施形態では、どの不正検出フィルタを適用すべきかの選択は、ＩＰＳＰ及び／又は地域の監督機関によって決定される。最後に、ステップ３７４では、不正防止用サブシステム３５０は該当する不正検出フィルタを実行して、取引データを評価する。
【００７９】
不正防止用サブシステム３５０を実行することに加えて、ＩＰＳＰモジュール３００は、本発明の種々の実施形態によれば、不正であるか又は法的な規制を受ける金融取引を識別するようにさらに構成される。例えば、図１８は、不正な又は規制された金融取引を識別する典型的な工程を例示している。ステップ８０２で開始すると、ＩＰＳＰモジュール３００は、顧客の支払いカードから取引先３１、３２、３３に資金を移動するための要求を受け取る。資金を移動するための要求には、顧客の請求書送付先、及び顧客が要求を作成するために使用するコンピュータ装置に関連したＩＰアドレスの位置が含まれる。次に、ステップ８０４では、ＩＰＳＰモジュール３００は、顧客の請求書送付先、ＩＰアドレスの位置、及び取引先３１、３２、３３の位置を取引先３１、３２、３３への資金の移動が規制される位置のリストと比較する。これらの位置のいずれかが位置のリスト上の位置と一致する場合、ＩＰＳＰモジュール３００は、ステップ８０６に示されているように、１つ以上の監督機関がこれらの位置のいずれかで資金の移動を規制するかどうかを判断する。ＩＰＳＰモジュール３００が、１つ以上の監督機関が資金の移動を規制すると判断する場合、このＩＰＳＰモジュール３００は、ステップ８０８に示されているように、該当する当事者（例えば、顧客、取引先、及び／又は発行銀行）に資金の移動が支配される１つ以上の規制の種類を通知する。金融取引が支配される規制の種類には、移動の禁止（例えば、ギャンブルが違法な州又は管区内のギャンブル取引）又は移動の制限（例えば、賭け金の額を制限する州又は管区内のギャンブル取引）が含まれる。
【００８０】
ＡＳＰモジュール
図８は、本発明の種々の実施形態によるＡＳＰモジュール４００のブロック図を例示している。ＡＳＰモジュール４００は、１つの実施形態によれば、ＡＳＰシステム１０５上で動作するように構成されているが、ＩＰＳＰが、別の実施形態に基づいて、口座管理サービスを提供するためにＡＳＰと契約をしていない場合は、ＩＰＳＰのシステム１０４上で動作するように構成されることもできる。
【００８１】
ステップ４０２で開始すると、１つの実施形態によれば、ＡＳＰモジュール４００は、ＩＰＳＰシステム１０４及び承継銀行１０６から取引情報を得る。ＩＰＳＰシステム１０４から得た取引情報は、各取引に対して以下のデータフィールドが含まれる、すなわち、（１）取引先又は取引先の取引事業体（trading entity）（例えば、特定のウェブサイト）を識別するために承継銀行によって与えられた取引先識別（「ＭＩＤ」）番号、（２）取引の日付及び時刻、（３）顧客の名前、（４）支払いカード番号又は支払いカード番号の一部（例えば、最後の４桁）、（５）カード所有者のイーメールアドレス、（６）取引の有効期間、（７）使用されている支払いカードの種類（例えば、Visa、MasterCard、又はAmerican Express）、（８）支払い金額、（９）取引先が取引に割り当てた注文参照番号、（１０）取引が許可されたかどうかを示す、発行銀行が作成した独特なコードである許可コード、（１１）取引の処理ステータス（例えば、「１００」は完了した取引を示す）、（１２）ＩＰＳＰが処理要求を承継銀行に送る時刻である「処理時間」、（１３）カード所有者の街路番号、（１４）カード所有者の都市名、（１５）カード所有者の国名、（１６）カード所有者の郵便番号、（１７）親取引照会先（parent transaction reference）、すなわち、払い戻し要求の場合に払い戻される最初の取引に対する照会先、（１８）注文情報、これは取引先が希望する場合、取引に関するより多く情報を含むために使用できる、（１９）「サイト照会先」、これはＩＰＳＰの取引先に対する照会先である、（２０）取引の種類、これには許可された取引、払い戻し取引、及び取り消された取引（例えば、取り消された取引、又は発行銀行により取引先に金が移動される前で、処理要求がＩＰＳＰから承継銀行に送信される後に取引先の要求で金額が変更される取引）が含まれる、（２１）ＡＳＰシステム１０５の中で一意的に取引を識別する固有の参照番号（ＵＲＮ）、が含まれる。本発明の１つの実施形態によれば、この情報は、ＩＰＳＰから承継銀行に送られる処理要求の中にも含まれる。このことは、図６のステップ３１０に関連して前に説明されており、また図１０Ａのステップ１１０２及び１１０４に関連して後で説明される。承継銀行のシステム１０６から得られた取引情報は、例えば、取引先ごとの形で１つ以上のバッチで集められた、発行銀行から要求された資金の総額を含むことができる。
【００８２】
種々の実施形態によれば、取引情報を得るために、ＡＳＰモジュール４００は、取引情報が書き込まれている安全なウェブページ（例えば、各システム１０４、１０６によって維持されている）にアクセスし、その情報をＡＳＰシステム１０５にダウンロードし、別の種類の電子送信手段（例えば、イーメール又はファックスを介して）又は両者の組合せを介して取引情報を受信する。
【００８３】
種々の実施形態では、ステップ４０２で得られた取引情報は、ステップ４０４に示されているように、ＡＳＰシステム１０５に保存され、そしてＩＰＳＰシステム１０４から得られた情報は、ステップ４０６に示されているように、承継銀行のシステム１０６から得られた情報と比較される。図８に示された実施形態では、ステップ４０６はステップ４０４の後で生じるように示されているが、別の実施形態では、これらのステップは同時に又は逆に発生することもできる。
【００８４】
本発明の種々の実施形態によれば、比較するステップ４０６において、ＡＳＰモジュール４００は、ＩＰＳＰシステム１０４によって提供された取引情報が承継銀行のシステム１０６によって与えられた取引情報と一致しない取引を幾つか確認することがある。１つの実施形態では、幾つかの一致しない取引はフラグが立てられ、ＡＳＰモジュール４００が発生する除外報告書の中で取引先、ＩＰＳＰ、及び／又は承継銀行に報告される。このことは、ステップ４１０に関連して以下でより詳細に説明される。承継銀行のシステム１０６が各取引先に関連しまたＩＰＳＰ３６及び／又はＡＳＰ３５によって維持される口座に資金を直接移動するような別の実施形態（このことは、図１４に関連して以下に説明される）では、ＡＳＰモジュール４００は、ＩＰＳＰシステム１０４及び承継銀行のシステム１０６によって与えられた取引情報を各取引先の口座に移動された金額と比較するようにさらに構成される。
【００８５】
ＩＰＳＰシステム１０４及び承継銀行のシステム１０６によって与えられた取引情報を受け入れた後で、ＡＳＰモジュール４００は次に、決済工程の間に受け取った支払い金額を種々の参加者に割り当てる。このことは、図８でステップ４０８として示されている。この支払い金額には、例えば、取引先３１、３２、３３への支払い金額、ＩＰＳＰ３４、承継銀行３６、及びＡＳＰ３５に支払う手数料、及び各取引先３１、３２、３３に対して回転保存エスクロー勘定４１に預ける資金の割合が含まれる。例えば、種々の実施形態によれば、それぞれ異なる参加者は、取引先３１、３２、３３及び互いとの契約４３、４５、４７、４９の中のサービスに対する支払いとして、取引先３１、３２、３３が受け取った資金の一定の割合を要求することができる。例えば、承継銀行３６は、取引先３１、３２、３３が発行銀行３７、３８、３９から受け取った資金の３％を請求し、カード機構は自身のカードを用いて移動された資金の１％を請求し、ＩＰＳＰ３４はサービスに関連した支払いに対して５％を請求し、またＡＳＰ３５は会計管理サービスに対してＩＰＳＰ３４が受け取った金の３パーセントをＩＰＳＰ３４に請求することができる。別の実施例では、ＡＳＰ３５は、カードの検証、様々な参加者に対する手数料の支払い、及び受け取った入金取消しに対して取引先３１、３２、３３に請求可能な料金などの種々のサービスに対して、ＩＰＳＰ３４が受けた暫定的な必要を計算することもできる。
【００８６】
さらに、種々の実施形態によれば、金融取引システム１００は、回転保存エスクロー勘定４１に資金を供給するために使用される資金の割合を規定するプロトコルを確立することができる。例えば、システムプロトコルは、ＡＳＰモジュール４００が各取引先３１、３２、３３が受け取る資金の７．５％を各取引先３１、３２、３３に対する回転保存エスクロー勘定４１に割り当てるように要求する。別の実施例では、１つの実施形態によれば、回数保存口座に対して規定された割合は、特定の取引先３１、３２、３３が受け取った払い戻し要求の数に応じて自動的に増加又は減少する。さらに、ＡＳＰモジュール４００は、１つの実施形態によれば、予め決められた期間（例えば、６ヶ月、１年、又は３年）口座に残っている資金を監視及び確認して、これらの資金をこの期間の終わりに、取引先３１、３２、３３に再配分する。さらに、エスクロー勘定４１は、図１の実施形態では、ＡＳＰシステム３５の一部として示されている。しかしながら、別の実施形態では、このエスクロー勘定４１は存在する、すなわち銀行又は別の金融機関によって維持される。
【００８７】
次に、ステップ４１０では、ＡＳＰモジュール４００は、種々の実施形態によれば、各取引先に対して、一致報告書又は「通知書」を作成するように構成される。１つの実施形態では、この通知書は各取引先に、特定の期間（例えば、１日又は１週間）に取引先に対して処理された取引の一覧表、（必要な場合）一致ステップ４０６で作られた除外報告書、ステップ４０８で様々な参加者のそれぞれに割り当てられた支払いの一覧表、特定の期間内のエスクロー勘定の動作の一覧表、及び取引先３１、３２、３３に支払いが移される日付、を提供する。別の実施形態では、通知書の様々な部分が、別個の報告書の中に含まれる（例えば、除外報告書、支払い割当て報告書、及び取引一覧報告書）。そして、さらに別の実施形態では、ＡＳＰモジュール４００は、それぞれが指定した特定の様式に基づいて、ＩＰＳＰ３４及び各取引先３１、３２、３３に対して１つ以上の一覧報告書を作成するように構成される。
【００８８】
図８に示された実施形態では、ＡＳＰモジュール４００は、（１）承認を得るために各取引先３１、３２、３３に対する通知書をＩＰＳＰ３４に送る（このことは、ステップ４１２に示されている）、そして（２）ステップ４１４に示されているように、ＩＰＳＰ３４から通知書に対して承認を受け取ると、ステップ４１６に示されているように、通知書を取引先３１、３２、３３に送るようにさらに構成される。ＩＰＳＰ３４が、口座管理サービス（図示せず）を提供するようにＡＳＰ３５と契約していない別の実施形態では、ステップ４１２及び４１４は実行されない。
【００８９】
さらに、ＡＳＰモジュール４００は、ステップ４１８に示されているように、本発明の種々の実施形態によれば、支払いを準備して種々の参加者及びエスクロー勘定に送るように構成される。ステップ４１８は、例えば、参加者のそれぞれに物理的に支払い金を送る工程（例えば、小切手又は現金）、ＡＳＰシステム１０５に関連した口座から金を支払う義務がある様々な参加者のそれぞれに関連した口座に電子資金移動（ＥＦＴ）を行う要求を準備する工程、又はそれら両者の組合せを行う工程が含まれる。さらに、支払いステップ４１８が図８に示された実施形態ではステップ４１６の後に生ずるように示されているが、別の実施形態によるＡＳＰモジュール４００は、ステップ４１６と同時に又はその前に支払いステップ４１８を実行するように構成することができる。
【００９０】
本発明の別の実施形態では、ＡＳＰモジュール４００は、各取引先３１、３２、３３に支払い金を送る前に、関連する電子商取引（例えば、インターネットのギャンブル取引又は小売買入）にかかる地域又は地区の税金を抑えるようにさらに構成することができる。例えば、１つの実施形態では、ＡＳＰモジュール４００は、住居の所在地又は各顧客及び／又は取引先の取引する場所に基づいて該当する税金又は認可料金を適用して、資金を直接関連する税金又は認可当局に移動するように構成することができる。
【００９１】
特に、図１７は、金融取引で支払い義務がある税金に対して会計計算する典型的な工程を例示している。ステップ７０２で開始すると、１つ以上の税金管轄のそれぞれに対する該当する税金の種類及び対応する税率は、メモリ２４の中に記憶されている。次に、ステップ７０４において、顧客と取引先３１、３２、３３との間で行われた金融取引に関連した情報が受信される。金融取引に関連した情報を受信することに呼応して、ステップ７０６に示されているように、金融取引に関連した１つ以上の関連する税金管轄が特定される。次に、ステップ７０８において、特定された税金管轄に関連した１つ以上の税金の種類を決定するために、メモリが問合せを受ける。１つ以上の種類の税金が特定された税金管轄に関連している場合は、税金の種類に対して対応する税率が金融取引に対して適用されて、取引上支払い義務がある税金が決定される。このことは、ステップ７１０に示されている。さらに、取引に対して支払うべき税金が決定されると、ステップ７１２に示されているように、支払う税額は関連する税務当局に振り込まれる。種々の実施形態では、税金は、取引オリジネータ（transaction originator）（例えば、取引先）、顧客、及び／又は顧客が注文を発行するコンピュータ装置の所在地に基づいて課せられる。
【００９２】
種々の実施形態では、差し引かれる税額及び税務当局に支払われる額は、取引情報を用いて一時期システムに記憶される。このことは、幾つかの実施形態では、完全な監査の手掛かりになる。例えば、１つの実施形態では、払われるべき金額は、指定された銀行口座に保持され、定期的に（例えば、毎月、毎週、毎日、又はリアルタイムで）税務当局に支払われる。１つの実施形態では、この払われるべき金額は電子資金移動（ＥＦＴ）機能を介して税務当局に支払われる。
【００９３】
種々の実施形態によれば、この税金会計機能は、取引先、顧客、及び税務当局の負担を軽減し、また課税対象の取引に対して信頼できる会計システムを提供する。さらに、１つの実施形態では、ＡＳＰモジュール４００は、収める税金及び／又は税金預り金を集計する、税務当局に対する会計報告書を作成する。
【００９４】
さらに、種々の実施形態では、取引記録はＡＳＰモジュール４００を介して電子的に又は手作業で監査することができる。特に、各取引に関連した固有の参照番号（「ＵＲＮ」）が、取引がシステムを通って処理されるように追跡される。例えば、１つの実施形態では、複数の取引がバッチファイルにグループ化されて、決済するために承継銀行に送られる。ＡＳＰモジュール４００は、各個々の取引を独立して監査できるようにバッチファイルを識別する情報と一緒に、各取引に関連したＵＲＮをバッチファイルの中に記憶する。
【００９５】
Ｃ．代表的な処理フロー
許可要求の処理フロー
図９Ａは、本発明の種々の実施形態による許可要求を処理するフロー１０００を例示している。１つの実施形態では、許可要求の処理は、顧客が待機している間にオンラインで行われて、それは処理するのに通常２から１２秒かかる。この許可要求が発行銀行によって承認されると、取引先は顧客の支払いを受け入れ、また発行銀行は支払いカードに関連したクレジット限界又は差引残高を超えて要求された金額を阻止する。
【００９６】
本発明の種々の実施形態によれば、許可要求の工程１０００は、顧客の支払いカードから取引先の口座に金を振り込むための顧客からの要求を取引先３１、３２、３３が受け取ることによって、ステップ１００２で開始する。この要求には、例えば、振り込まれる金額、顧客の情報及び支払いカードの情報が含まれる（取引先は、前の取引で記録された顧客の情報及び支払いカードの情報を持たないと仮定する）。１つの実施形態では、顧客及び支払いカードの情報には、顧客の氏名及び住所、顧客のイーメールアドレス、及び支払いカードの番号、満了日、及び支払いカードに関連した他の識別情報が含まれる。１つの実施形態では、この要求は取引先のシステム１０１、１０２、１０３によって受信されて、それらのシステムで保存される。
【００９７】
次に、ステップ１００６で、本発明の種々の実施形態に基づいて、取引先３１、３２、３３は、顧客の要求の中で受け取った情報の体裁を検証する。１つの実施形態では、図５及びステップ２０４に示された取引先用モジュール２００に関連して前述されたように、この取引先用モジュール２００は、支払いカード番号の体裁は正しいかどうか、また全ての必要な欄が記入済みかどうかを検証する。
【００９８】
ステップ１００６で情報の体裁を検証した後、取引先３１、３２、３３は、取引情報をさらに処理するためにＩＰＳＰ３４に転送する。このことは、ステップ１０１０に示されている。ＩＰＳＰ３４は取引情報を受け取り、またＩＰＳＰシステム１０４に保存し、ステップ１０１２に示されているように、許可要求を処理するために承継銀行３６及び発行銀行３７、３８、３９が必要な情報を承継銀行３６に転送する。例えば、この情報は、本発明の種々の実施形態によれば、ＩＰＳＰモジュール３００によって承継銀行のシステム１０６に転送され、そして支払いカードの番号、支払い金額、及び顧客の請求書送付先を含んでいる。
【００９９】
次に、ステップ１０１４では、承継銀行のシステム１０６は、許可要求を受け取り、それを承継銀行のシステム１０６に保存する。次に、ステップ１０１６では、承継銀行のシステム１０６は、該当するカード発行会社及び発行銀行を識別し、許可要求を該当するカード発行会社のネットワーク（例えば、例えば、Visa、MasterCard、又はAmerican Expressのネットワーク）を介して発行銀行に経路指定する。許可要求を受け取ると、発行銀行のシステム１０７、１０８、１０９は、ステップ１０１８に示されているように、支払いカードが使用可能で有効であり、かつステップ１０２０に示されているように、十分な資金がこの支払いカードに対して利用可能であることを検証する。許可要求を承認すると、発行銀行のシステム１０７、１０８、１０９は、ステップ１０２２に示されているように、承認メッセージをカード発行会社のネットワークを介して承継銀行のシステム１０６に送り、そして承継銀行のシステム１０６はこの承認メッセージを受け取り、ステップ１０２４においてこの承認メッセージをＩＰＳＰシステム１０４に転送する。次に、ステップ１０２６では、ＩＰＳＰシステム１０４は、承認メッセージを受け取りまた保存し、そして許可要求を作成した取引先のシステム１０１、１０２、１０３にこの承認メッセージを転送する。
【０１００】
種々の実施形態によれば、図５に関連して前述された基本的な不正チェック及び身元／年令検証ステップ（ステップ２０４及び２０６）は、取引先からＩＰＳＰに許可要求の情報を転送するステップ１０１０と同時に、その前に、又はその後で取引先用モジュール２００によって実行される。さらに、本発明の種々の実施形態によれば、不正防止用サブシステム３５０を実行するステップは、図６のステップ３０６に示されており、ＩＰＳＰから承継銀行に許可要求の情報を転送するステップ１０１２と同時に、その前に、又はその後でＩＰＳＰモジュール３００によって実行される。
【０１０１】
図１３に示されている本発明の別の実施形態では、顧客情報は、取引先のシステム１０１ａ、１０２ａ、１０３ａ及びネットワーク１１５ａを通ってＩＰＳＰシステム１０４ａに送られるときに暗号化（例えば、２０４８ビットの可変暗号化）される。さらに、ＩＰＳＰモジュール３００ａは、不正防止用サブモジュール３５０ａの１つ以上の不正検出フィルタを使用し、これらの不正検出フィルタが潜在的に疑わしい行為を検出した場合、ＩＰＳＰモジュール３００ａは、承認のために許可要求を承継銀行のシステム１０６ａに送る前に、不正チェックの結果を取引先に送る。取引先が取引に対して承認を与えた後で、ＩＰＳＰモジュール３００ａは許可要求を承継銀行に転送し、承継銀行は次に、この要求を発行銀行に送る。承継銀行が許可メッセージを発行銀行から受け取った後で、承継銀行は取引情報を承継銀行のシステム１０６ａのメモリ領域（例えば、データベース）に保存し、そして許可メッセージをＩＰＳＰシステム１０４ａに送る。ＩＰＳＰモジュール３００ａは、許可メッセージを取引先に転送し、そしてこの取引に対して決済要求を作成する前に、取引情報に対して１つ以上の不正検出フィルタを実行する。
【０１０２】
決済処理のフロー
図１０Ａ及び１０Ｂは、本発明の種々の実施形態による決済要求を処理する代表的なフロー１１００を例示している。種々の実施形態による決済要求は、取引先に支払うために、発行銀行から承継銀行に金を振り込むために、承継銀行（又は承継銀行の代わりにＩＰＳＰ）が作成した要求である。本発明の種々の実施形態によれば、決済要求処理１１００は、ステップ１１０２において、ＩＰＳＰシステム１０４が各取引先３１、３２、３３に対して決済要求を作成し、この決済要求をバッチファイルで承継銀行３６に送ることで開始する。種々の実施形態では、各決済要求には、特定の期間（例えば、２４時間、４８時間、又は１週間）にＩＰＳＰ３４によって処理された取引に関するデータが含まれる。決済要求には、本発明の種々の実施形態によれば、許可された及び許可されない取引又は許可されたばかりの取引が含まれる。次に、本発明の種々の実施形態によれば、ステップ１１０４において、ＩＰＳＰシステム１０４は、決済要求をＩＰＳＰシステム１０４上に保存する。これらの決済要求は、ＩＰＳＰシステム１０４のセキュリティ保護された部分から決済要求をダウンロードすることによってＡＳＰシステム１０５に転送するか、又はＩＰＳＰ３４は決済要求の物理的なコピー又は電子コピーをＡＳＰ３５に送る（例えば、イーメール、ファックス、ＣＤ、ＤＶＤ、又はフロッピー（登録商標）ディスクによって）ことができる。本発明の種々の実施形態による決済要求の内容は、図８に関連して前述されている。
【０１０３】
ステップ１１０６に示されているように、承継銀行３６は、バッチファイルを受け取り、そして決済要求を該当する発行銀行３７、３８、３９に送信する。さらに、承継銀行３６は、ステップ１１０８に示されているように、各発行銀行３７、３８、３９に対する各決済要求の中に含まれた資金の額を集計する（例えば、資金の額を集約する）、ＡＳＰ３５に対する支払い報告書を作成及び保存する。ＡＳＰ３５に対して承継銀行３６が作成した支払い報告書の１つの実施形態は、図８に関連して前述されている。
【０１０４】
次に、ステップ１１１０では、発行銀行３７、３８、３９は、要求された資金を承継銀行３６に振り込む。次に、ステップ１１１２において、承継銀行３６は、受け取った資金をＩＰＳＰ３４に振り込む。ＩＰＳＰ３４（又はＡＳＰ３５）が資金を該当する参加者とエスクロー勘定に配送する前に、ＡＳＰシステム１０５は、ＩＰＳＰシステム１０４が作成した決済要求と承継銀行３６が作成した支払い報告書を得て、ステップ１１１４で得た情報を一致させる。ステップ１１１４で行われた一致させる動作の結果は、本発明の種々の実施形態によれば、ＡＳＰ３５によって一致報告書（又は「通知書」）の中で要約される。最後に、ステップ１１１６において、ＡＳＰ３５は、各参加者に対する支払い金及びエスクロー勘定に振り込む金額をまとめて、参加者とエスクロー勘定に支払い金を振り込む。
【０１０５】
１つの実施形態によれば、ＡＳＰモジュール４００は、ステップ１１１４及び１１１６を実行するように構成される。このことは、図８に関連して前に説明されている。例えば、ＡＳＰモジュール４００は、各取引先３１、３２、３３に定期的（例えば、毎日又は毎週）に送られる一致報告書の中でＩＰＳＰと承継銀行によって提供されるデータを一致させることにより生じた結果を集約する。この一致報告書は、取引先３１、３２、３３が特定の日付までに取引先の銀行口座に受け入れることを期待できる金額を集約する。さらに、一致報告書は、顧客がそれぞれの取引先の口座に入金する総額を含み、また下記の難点及び利点を示す、すなわち、（１）（支払いチェーンの中で全ての参加者に対する支払いをカバーする）手数料や使用料が少ないこと、（２）入金取消し及び払い戻しに対するセキュリティとして、回転保存エスクロー勘定の中で一定の期間（例えば、６ヶ月又は１年）保留された総額の割合に対応する「トラスト・ディダクト（trust deduct）」が少ないこと、（３）その上、一定の期間また通知書の日付の１日前に保留された「委託金（trust money）」があること、（４）前の取引に関連した通知書の日付に承継銀行によって伝えられた入金取消しが少ないこと、である。資金を該当する参加者と回転保存エスクロー勘定に振り込む前に、ＩＰＳＰ３４は、支払いが行われたことを示す日付を含む一致報告書を調査する。一致報告書に対するＩＰＳＰ３４の承認を受け取ると、ＡＳＰ３５は、この一致報告書を様々な取引先３１、３２、３３に転送すると共に、支払い金を該当する参加者とエスクロー勘定に振り込む。１つの実施形態では、支払い金の振込は、一致報告書が作成されかつ承認された後で行われる。別の実施形態では、支払い金の振込は、一致報告書が承認される前に行われる。
【０１０６】
図１４に示した別の実施形態によれば、資金は承継銀行によって、各取引先に関連した各企業体の口座（例えば、ＳＧ１、ＳＧ２、ＳＧ３、など）に直接支払われる。さらに、ＡＳＰモジュール４００ａは、各口座に受け入れられた金額を、それぞれＩＰＳＰ及び承継銀行から得られた決済要求及び支払い報告書と一致するようにさらに構成される。１つの実施形態では、種々の参加者又はエスクロー勘定に対して口座から支払われていない金額は、取引先に支払われる。
【０１０７】
入金取消し処理のフロー
入金取消し要求は、特別な費用を顧客の支払いカードの口座に返金するために、顧客に代わって発行銀行が始動する要求である。例えば、発行銀行は、顧客が主張する、顧客の支払いカード上の費用が顧客によって許可されなかったことを争っている顧客に応じて入金取消し要求を始動する。図１１は、本発明の種々の実施形態による入金取消し要求を処理する代表的なフロー１２００を例示している。
【０１０８】
ステップ１２０２で開始すると、発行銀行３７、３８、３９は、顧客から入金取消しに関する要求を受け取る。次に、ステップ１２０４で、発行銀行３７、３８、３９は、入金取消し要求を承継銀行３６に送る。承継銀行３６は、入金取消し要求を受け取り、ステップ１２０６でそれをＩＰＳＰ３４に送る。次に、ステップ１２０８において、ＩＰＳＰ３４は、入金取消し要求を最初の取引によるデータと比較する。入金取消し要求の中のデータが最初の取引によるデータと一致すると思われる場合は、ＩＰＳＰ３４はこの要求をステップ１２１０においてＡＳＰ３５に送信する。この比較及び送信するステップ１２０８及び１２１０は、前述されたように、本発明の種々の実施形態によれば、ＩＰＳＰモジュール３００によって実行される。次に、次に、ステップ１２１２において、本発明の種々の実施形態によれば、ＡＳＰ３５は入金取消しの金額を取引先のエスクロー勘定から承継銀行３６に転送し、この承継銀行３６は次に、入金取消し要求を始動する発行銀行３７、３８、３９に入金取消し金額を転送する。別の実施形態では、ＡＳＰ３５は、決済要求の中で取引先３１、３２、３３に支払うべき合計金額から入金取消し金額を差し引くことによって、発行銀行３７、３８、３９にそれを支払う。次に、ステップ１２１４で、ＡＳＰ３５は入金取消し要求を保存する。本発明の種々の実施形態では、ＡＳＰモジュール４００は、ステップ１２１２と１２１４を実行するように構成される。
【０１０９】
ステップ１２０８において、入金取消し要求のデータが最初の取引によるデータと一致していない場合は、本発明の種々の実施形態によれば、この入金取消し要求にはフラグが立てられる。さらに、特定の支払いカードに関連したフラグが立てられた入金取消し要求の数が特定の期間内で一定の数を超える場合（例えば、１週間又は１ヶ月内で２つの入金取消し要求）、ＩＰＳＰは、将来取引先が支払いを承認してはならない支払いカードのリスト（例えば、ＩＰＳＰ３４によって維持される不正及び悪用データベース）上に特定の支払いカード番号を含む。
【０１１０】
上記に加えて、種々の実施形態によれば、ＡＳＰ３５は、特定の期間（例えば、毎日又は毎週）内に承継銀行３６とＩＰＳＰ３４によって処理された入金取消し要求を、最初の取引からの取引データに一致させる。これらの要求を一致させるために、ＡＳＰ３５は、ステップ１２１６に示されているように、承継銀行３６が作成した入金取消し取引報告書とＩＰＳＰ３４が作成した入金取消し取引報告書とを得て、２つの報告書を最初の取引からのデータと比較する。１つの実施形態では、比較するステップ１２１６は、入金取消し報告書のデータをＡＳＰシステム１０５のメモリに記憶されている最初の取引からのデータとリンクすることによって実行される。１つの実施形態によれば、入金取消しデータ報告書は、次に続く情報の少なくとも一部を含んでおり、この情報は、（１）チャージ・バック（charged back）される最初の情報に対する参考資料、（２）ＭＩＤ番号、（３）入金取消し要求が作られた日付、（４）取引の「入金取消し」としての説明、（５）全部のカード番号、（６）承継銀行によって与えられた照合番号、（７）なぜ入金取消しがカード所有者によって開始されたかを示すカード発行会社が発行したコード番号、（８）なぜ入金取消しが開始されたかに関する説明、（９）入金取消し金額に対する通貨の種類、（１０）入金取消し金額、（１１）承継銀行から与えられたカード番号又はその一部（例えば、カード番号の最初の４桁）、（１２）最初の取引が「公表された」すなわち許可された日付、（１３）最初の取引が発生した日付、（１４）最初の取引の「種類」、（１５）最初の取引の通貨、（１６）最初の取引の金額、（１７）取引が決済された通貨、（１８）決済された金額、（１９）承継銀行によって提供された最初の「デフォルト」の通貨、（２０）承継銀行によって提供された最初の「デフォルト通貨」の金額、（２１）承継銀行が特定の日付の取引に関するそのデータをＩＰＳＰに開放したときの取引の一部の「バッチ」に対する参考資料である「最初のスリップ（original slip）」、（２２）承継銀行の「品目スリップ」、（２３）最初の取引の許可コード、（２４）承継銀行の「バッチ番号」、そして（２５）顧客の支払いカードの明細書に現れるときの取引先の名前である「取引先のＤＢＡ名」、である。図８に関連して前に説明したように、ＡＳＰモジュール４００は、本発明の種々の実施形態によれば、この一致ステップ１２１６を実行するように構成される。
【０１１１】
本発明の種々の実施形態によれば、報告書はＩＰＳＰシステム１０４及び承継銀行のシステム１０６にメールで送られる、またＡＳＰシステム１０５によってダウンロードされる、又は報告書は、例えばイーメール、ファックス、ＣＤ、ＤＶＤ、又はフロッピー（登録商標）ディスクを介して、物理的又は電子的に送られる。
【０１１２】
支払い処理のフロー
幾つかの電子商取引部門（例えば、ギャンブル）では、金を顧客に払い戻す必要がある。金を顧客に払うことは、特にインターネットのギャンブルに対して、マネーローンダリングを悪用する危険性に関する懸念が持ち上がる。本発明の種々の実施形態によれば、システム１００は、取引先に対して最初の支払いを行うために顧客が使用した支払いカードの口座に独占的に支払いを行うことにより、顧客と取引先との間に完全に透明な「閉ループ」を作り出すことによって、電子商取引に関連した幾つかの危険性に対処している。このため、１つの実施形態によれば、資金は同じ口座から発生しまた同じ口座に戻るため、全ての金の流れは追跡可能になる、これにより、電子商取引はマネーローンダリング計画には魅力的でなくなる。
【０１１３】
例えば、図１２は、顧客が支払い要求を提出したときに、顧客に対して支払いを処理しかつ支払いを送金する代表的なフロー１３００を例示している。ステップ１３０２で開始すると、取引先は支払いに関して顧客からの要求を受け取り、その要求をＩＰＳＰに転送する。次に、ステップ１３０４では、ＩＰＳＰは、顧客が政府又は地方自治体の許可リスト（例えば、米国が発行した「特別指定国家リスト」）に含まれていないことを検証する。さらに、１つの実施形態によれば、ＩＰＳＰは、顧客の国籍（例えば、顧客の請求書送付先又は顧客のコンピュータ装置のＩＰアドレスに基づく）が取引先が事業を行っている可能性がある禁止された国のリストに載っていないことを検証する。種々の実施形態によれば、顧客（又は顧客の国）がそのリストに載っている場合、システム１００は支払い要求を許可することはできないため、この要求は拒絶される。顧客が許可リストに含まれていない場合（又は、禁止された国と関連がない場合）、ＩＰＳＰ３４は支払い要求を取引先の銀行に送る。このことは、ステップ１３０６として示されている。要求を受け取り、そして支払い資金が取引先の口座にあることを受けて、取引先の銀行はこの資金をＩＰＳＰ３４に送金する。このことは、ステップ１３０８として示されている。ＩＰＳＰ３４が資金を受け取りそれらの記録をＩＰＳＰシステム１０４の中に保存した後で、ＩＰＳＰ３４は、ステップ１３１０に示されているように、その資金を承継銀行３６に振り込む。次に、ステップ１３１２では、承継銀行３６は資金を受け取ると、取引先のウェブ上で購入する（例えば、賭け金を入れる）ために使用された顧客の支払いカードに関連した発行銀行３７、３８、３９に、この資金を送金する。種々の実施形態によれば、ステップ１３１４では、発行銀行３７、３８、３９は、次に、取引先３１、３２、３３から受け取った金額を支払いカードに関連した口座に振り込むか、又はカード所有者としてリストされている顧客に小切手を送る。
【０１１４】
電子財布
本発明のさらに別の実施形態では（図示せず）、金融取引システム１００は、顧客がＩＰＳＰ３４から電子トークンを購入できるように構成される。この電子トークンはこの場合、合意した金額だけ参加している取引先３１、３２、３３に使用することができ、プリペイド形の「電子財布」口座が作られる。種々の実施形態によれば、金融取引システム１００の機能は、電子財布システムまで拡張できる。例えば、顧客からの要求を受け取り、資金を顧客の支払いカードに関連した口座から取引先の口座に振り込む取引先３１、３２、３３の代わりに、ＩＰＳＰ３４が要求を受け取って、資金を顧客の電子財布からＩＰＳＰの口座に振り込む。１つの実施形態によれば、ＩＰＳＰ３４は取引先用モジュール２００及びＩＰＳＰモジュール３００のステップを実行して、許可要求と発行銀行に対する決済要求を作成及び処理する。決済が行われると、ＩＰＳＰ３４は顧客の電子財布の口座に、振り込まれた資金の額を表す電子トークンの金額を振り込む。顧客はトークンを、購入するために参加している取引先３１、３２、３３に対して使用することができる。定期的に（例えば、毎日又は毎週）、ＩＰＳＰ３４は、各取引先のウェブサイトで使われたトークンの金額を表す資金を各取引先３１、３２、３３に振り込む。１つの実施形態では、ＡＳＰ３５は、電子財布の口座を管理して、ＩＰＳＰ３４からの支払いを関係する取引先３１、３２、３３に割り当てる。
【０１１５】
本発明の多くの変形例及び他の実施形態は、前述した説明及び関連した図面の中で示した教義の利点を有する本発明が属する技術分野に精通した者には思い浮かぶであろう。このため、本発明は開示された特定の実施形態に限定されるものではなく、また変形例及び他の実施形態は添付した特許請求の範囲の中に含まれるものとすることは理解されよう。本願の中で特別な用語が使用されるが、それらの用語は一般的であり説明のためのみに使用されるものであり、本発明の範囲を限定する目的で使用されるものではない。
【技術分野】
【０００１】
一般に、顧客が（インターネット上で又は別の方法で）取引先に対して支払カード（例えば、クレジットカード又はデビットカード）を使用することを希望する場合、この取引先は承継銀行に対して電子許可要求を送る。承継銀行はこの電子許可要求を、カード発行会社のネットワーク（card issuer network）（例えば、ビザ、マスタカード、アメリカンイクスプレス、又はプライベートカード発行会社のネットワーク）を介して発行銀行（すなわち、顧客に支払カード発行した銀行又は金融機関）に渡す。発行銀行は、顧客が利用可能な十分なクレジットを持っていること、支払いを滞納していないこと、及び提供される全ての情報（例えば、カード番号、カード検証値番号（card verification value number）、及びカード所有者の詳細）が正しいことを検証する。発行銀行は次に、支払いを許可する電子メッセージをカード発行会社のネットワークを介して承継銀行に送り、この承継銀行は電子メッセージを取引先に送る。取引先はこの許可メッセージを、発行銀行による将来の支払いの証拠として受け入れる。資金の実際の移動は、決済処理と呼ばれる後の段階で発生する。
【０００２】
インターネット又は他のネットワーク上で発生する支払カードによる取引は、カード所有者と取引先は取引が発生するときに通常一緒にいないため、対面支払い取引では必ずしも存在しない危険が伴う。さらに、ギャンブルや成人向け娯楽などの幾つかの電子商取引部門では、支払カードによる取引を信頼できるものにし、かつ不正行為や他の悪用を防止するために、システムに対する要求を更に強調する付加的な公共の関心が高まっている。
【発明の概要】
【課題を解決するための手段】
【０００３】
本発明の種々の実施形態により、（１）支払い取引をより確実に処理し、（２）不正取引、マネーローンダリング、及び未成年のギャンブルに対して取引先及び銀行を保護するのに役立ち、かつ（３）インターネットのゲーム、旅行、及び電子商品を顧客が購入することなど特別なリスクをもたらすことが分かる電子商取引の領域で他の不正行為を制限するのを支援する、電子商取引部門に対するより安全な金融取引が提供される。上記の目標を達成するために、金融取引システムの種々の実施形態により、（１）取引先、インターネット支払いサービスプロバイダ、承継銀行、及びカード機構（card scheme）に対する動作及び取引処理プロトコルが確立され、かつ（２）支払い及び金融取引をモニタし、確実に処理するための自動化システムが提供される。本願で説明された種々の実施形態を２つ以上組み合わせて、１つ以上のこれらの目標に適合するシステム又は方法を提供することができる。
【０００４】
本発明の種々の実施形態によれば、オンライン取引先との金融取引を処理するためのシステムが提供される。このシステムは、（１）資金を顧客の口座からオンライン取引先に移動する要求を受信し、（２）この資金を移動する要求を受信する動作に応答して、資金の少なくとも一部をオンライン取引先のエスクロー勘定に支払うように割り当て、かつ（３）資金の一部をオンライン取引先のエスクロー勘定に支払うように割り当てることに応答して、より短い所定の期間又は入金取消し又は払い戻し要求がシステムによって受信されるまで、割り当てられた資金の一部をエスクロー勘定に保管するように構成された支払いサービスプロバイダ用モジュールを備えている。さらに、１つの実施形態では、この要求は、ネットワークを介して支払いサービスプロバイダ用モジュールと通信する取引先のコンピュータ装置から受信される。
【０００５】
１つの実施形態では、この支払いサービスプロバイダ用モジュールは、各オンライン取引先に定期的に一致報告書（reconciliation report）を作成するようにさらに構成される。この一致報告書は、受信された振り込み要求及びエスクロー勘定に割り当てられた資金の部分を列挙している。別の種々の実施形態では、この支払いサービスプロバイダ用モジュールは、顧客の口座から取引先に前に振り込まれた資金に対する入金取消し要求又は返金要求を受信し、そして入金取消し要求又は返金要求を受信することに応答して、この入金取消し要求又は返金要求に対してエスクロー勘定に保管された資金を供給するようにさらに構成される。
【０００６】
さらに別の実施形態では、このシステムは、要求に対して１つ以上の不正検出フィルタを適用するように構成された不正防止用モジュールも備えている。この不正検出フィルタは、（１）顧客の口座に関連する第１の位置を要求をオンライン取引先に送るために使用された顧客のコンピュータ装置に関連する第２の位置と比較して、第１の位置が第２の位置の第１の所定の許容できる距離の外側にある場合、この要求は潜在的に不正であるとして印を付ける機能と、（２）顧客のイーメールアドレスに関連した第３の位置を第２の位置と比較して、この第３の位置が第２の位置の第２の所定の許容できる距離の外側にある場合、この要求は潜在的に不正であるとして印を付ける機能と、（３）顧客の口座に対する顧客の請求書送付先に関連する第４の位置を第２の位置と比較して、この第４の位置が第２の位置の第３の所定の許容できる距離の外側にある場合、この要求は潜在的に不正であるとして印を付ける機能と、（４）顧客の識別番号を金融取引を行うことを禁止された人物のリストと比較して、顧客の識別番号がリスト上の人物の１人と一致する場合、この要求は潜在的に不正であるとして印を付ける機能と、及び／又は（５）顧客の口座の識別番号を金融取引を行うことを禁止された口座のリストと比較して、この顧客の口座の識別番号がリストの口座の１つと一致する場合、この要求は潜在的に不正であるとして印を付ける機能と、を含むことができる。
【０００７】
本発明の種々の実施形態によれば、顧客から受信した払い戻し要求に対して資金を供給する方法が提供される。この方法には、（１）１人以上の顧客に関連した１つ以上の口座から取引先に支払われる資金の比率によって資金が供給されるエスクロー勘定を取引先（例えば、オンライン取引先）に対して開設するステップと、（２）特定の顧客に関連した口座から取引先に対して前に行われた支払いに対する払い戻し要求を受信するステップと、そして（３）エスクロー勘定に保管された資金を用いて、この払い戻し要求に資金を供給するステップと、が含まれる。１つの実施形態では、この払い戻し要求に対して資金を供給するステップは、議論せずに行われる。さらに、種々の実施形態によれば、この払い戻し要求は、入金取消し要求又は返金要求である。
【０００８】
その上、さらに別の実施形態では、この方法には、資金の一部が特定の期間（例えば、少なくとも６ヶ月）エスクロー勘定に保管されていることに呼応して、エスクロー勘定の資金の一部を取引先に振り込むステップも含まれる。別の実施形態では、この方法にはさらに、（１）特定の期間にわたって取引先が受け取る払い戻し要求の数が減少することを受けて、取引先がエスクロー勘定に支払う資金の比率を減少するステップと、（２）前記特定の期間にわたって取引先が受け取る払い戻し要求の数が増加することを受けて、取引先がエスクロー勘定に支払う資金の比率を増加するステップと、がさらに含まれる。さらに別の実施形態では、この方法には、払い戻し要求に対して潜在的に不正な払い戻し要求を識別するように構成された１つ以上の不正検出フィルタを利用するステップが含まれる。これらの不正検出フィルタは、本発明の１つの実施形態に基づいて、コンピュータが読取り可能な媒体上で実行される不正防止用モジュールによって動作される。
【０００９】
本発明の種々の実施形態により、（１）顧客に関連した口座から以前取引先に対して行われた支払いに対する払い戻し要求を受信するステップと、（２）取引先に関連した口座の中に保管された資金から、議論せずに顧客に対する払い戻し要求に資金を供給するステップとを有する、顧客に対する払い戻し要求に資金を供給する方法が提供される。この払い戻し要求は、種々の実施形態によれば、入金取消し要求又は返済要求とすることができる。さらに、１つの実施形態によれば、顧客に関連した口座を保持する金融機関からの払い戻し要求が受け取られて、払い戻し要求に対する資金が、顧客に関連した口座を保持する金融機関に対して支払われる。
【００１０】
本発明の種々の他の実施形態によれば、オンライン取引先に対して顧客から受信された潜在的に不正なオンライン金融取引を識別するための不正防止システムが提供される。この不正防止システムには、１人以上の顧客から受信された１つ以上の金融取引のそれぞれに対して、前述された１つ以上の不正検出フィルタを利用するように構成された不正防止用モジュールが含まれる。さらに、種々の実施形態では、この不正検出フィルタには、（１）１つ以上の続いて起こる金融取引に関連した情報を不正行為用データベースの中に記憶された金融取引と比較して、１つ以上の続いて起こる金融取引のそれぞれの顧客の口座、顧客の識別番号、又は顧客の請求書送付先が不正行為用データベースの中に記憶された金融取引のいずれかと一致する場合、潜在的に不正であるとして１つ以上の続いて起こる金融取引に印を付ける機能と、（２）第１の位置を第３の位置と比較して、この第１の位置が第３の位置の第１の所定の許容できる距離の外側にある場合、潜在的に不正であるとしてこの金融取引に印を付ける機能と、も含まれる。さらに、この第２の位置が国を含む実施形態では、不正検出フィルタは、第２の位置を取引先と金融取引を行うことが禁止されている国のリストと比較し、この第２の位置が国のリスト上にある場合は、金融取引を行うことが禁止される機能をさらに含む。
【００１１】
別の実施形態では、金融取引を行うことが禁止されている口座のリストは、盗難口座のリストである。さらに別の実施形態では、第１の位置は、顧客の口座を管理する金融機関に関連した位置である。そして、別の実施形態では、第１の位置は、顧客の口座に関連した請求書送付先である。種々の他の実施形態によれば、第１の位置、第２の位置、第３の位置、そして第４の位置は、国、地方、州、地域、市、又は１つ以上の郵便番号によって規定された郵便区域とすることができる。さらに、１つの実施形態では、人物のリスト及び／又は口座のリストは、政府当局によって発行される。
【００１２】
さらに、本発明の１つの実施形態では、不正検出フィルタが、取引先の住所に基づいて選択される。本発明の別の実施形態では、この不正検出フィルタは、第２の位置に基づいて選択される。そして、本発明のさらに別の実施形態では、この不正検出フィルタは、第１の位置に基づいて選択される。
【００１３】
別の実施形態では、システムは、顧客に対する払い戻し要求を受信するように構成された支払いサービスプロバイダ用モジュールをさらに備えて、不正防止用モジュールが払い戻しを要求する顧客のアイデンティティをオンライン取引先に関連した職員、管理者、又は所有者のリストと比較するようにさらに構成される。顧客が管理者、職員、又は所有者のリスト上にある場合は、不正防止用モジュールは、潜在的に不正であるとしてこの払い戻し要求に印を付ける。
【００１４】
本発明のさらに別の実施形態によれば、金融取引はギャンブル支払い要求であり、不正防止用モジュールは取引先から支払いを受け取るために顧客が指定した口座の識別番号を、取引先に賭け金を入れるために顧客が使用する口座の識別番号と比較するようにさらに構成される。支払いを受け取るために指定された口座の識別番号が、賭け金を取引先に入れるために使用された口座の識別番号と一致しない場合、この不正防止用モジュールは、潜在的に不正であるとしてこの払い戻し要求に印を付ける。さらに別の実施形態では、この不正防止用モジュールは、払い戻し要求の中で規定された金額が、払い戻しを受け取るために指定された口座に移動されないようにさらに構成される。別の実施形態では、払い戻し要求を受け取るために指定された口座が第１の支払いカードに関連し、取引先に賭け金を入れるために使用される口座が第２の支払いカードに関連し、そして不正防止用モジュールが、第１の支払いカードを第２の支払いカードと比較するようにさらに構成される。第１の支払いカードが第２の支払いカードと一致しない場合は、不正防止用モジュールは潜在的に不正であるとしてこの払い戻し要求に印を付ける。
【００１５】
本発明の種々の実施形態によれば、顧客の強制された支出動作を監視するシステムが提供される。このシステムはプロセッサ及びメモリを備えると共に、このプロセッサが（１）取引先と金融取引を行うために、顧客からの１つ以上の要求のそれぞれに関連した、資金の総額を含む情報をメモリの中に記憶し、（２）取引先と金融取引を行うために、資金の新しい金額を含む新しい要求を受信し、（３）この新しい要求を受信すると、メモリに記憶された資金の総額を修復し、（４）資金の総額及び新しい要求の中の資金の額の合計を所定の許容できる限度と比較し、そして（５）この合計が所定の許容できる限度を超えた場合、顧客、この顧客に関連した支払いソース、又は所定の許容できる限度が超過された取引先の１つ以上に通知する、ように構成される。特定の実施形態では、メモリの中に記憶された情報には、各要求が取引先によって受信されたデータが更に含まれ、かつプロセッサが特定の期間内にメモリの中に記憶された資金の総額と新しい要求の中の資金の額のとの合計を、所定の許容できる限度と比較するようにさらに構成される。
【００１６】
本発明の種々の他の実施形態によれば、顧客の強制されたギャンブル動作を監視する別のシステムが提供される。このシステムは前述されたシステムと似通っているが、プロセッサが、新しい要求の中の金融取引の種類に対してメモリの中に記憶された資金の総額を修復し、かつこの資金の総額と新しい要求の中の資金の額との合計を、新しい要求の中の金融取引の種類に関連した所定の許容できる限度と比較するようにさらに構成される。本発明の種々の実施形態では、取引の種類は、顧客に関連した口座から取引先に資金を移動する要求、又は前に取引先に移動した資金を用いて賭け金を入れる要求とすることができる。さらに、１つの実施形態では、要求及び新しい要求は、顧客に関連した１つ以上のコンピュータ装置からネットワークを介して取引先に関連したコンピュータ装置によって受信される。メモリの中に記憶された情報が、取引先が受信した要求の日付を含むような特定の実施形態では、プロセッサは、特定の期間内に顧客によって要求された資金の総額と新しい要求の中の資金の額のとの合計を、所定の許容できる限度と比較するようにさらに構成される。別の実施形態では、プロセッサは、この合計が所定の許容できる限度を超える場合、新しい要求が処理されないようにさらに構成される。
【００１７】
本発明の種々の実施形態によれば、顧客の強制された支出動作を監視するための第３のシステムが提供される。このシステムは前述された第１のシステムに類似しているが、要求に関連した情報には取引先が要求を受信した日付が含まれている。この第３のシステムの処理は、所定の期間内にメモリの中に記憶された取引の総数を修復し、取引の総数を所定の許容できる限度と比較し、そして取引の総数が所定の許容できる限度を超えた場合、顧客、この顧客に関連した支払いソース、又は限度が超過された取引先の１つ以上に通知する、ように更に構成される。
【００１８】
本発明の種々の実施形態では、オンライン取引先に対して行われた金融取引に対する税務会計システムが提供される。この税務会計システムはメモリとプロセッサを具備し、このメモリは１つ以上の税の種類及び１つ以上の税管轄（tax jurisdiction）のそれぞれに対する対応する税率を記憶するように構成される。プロセッサは、（１）オンライン取引先に対して行われた金融取引に関連した情報を顧客から受信し、（２）金融取引に関連した情報を受信すると、金融取引に関連した１つ以上の税管轄を識別し、（３）金融取引に関連した１つ以上の税管轄を識別すると、１つ以上の税の種類が１つ以上の税管轄に関係付けられているかどうかを決定するためにメモリに問合せを行い、（４）１つ以上の税の種類が１つ以上の税管轄に関係付けられていることが判断されると、支払い義務がある税額を決定するために、金融取引に関連した情報に対する１つ以上の税の種類のそれぞれに対して対応する税率を適用し、そして（５）支払い義務がある税額が決定されると、１つ以上の関連する税務当局に支払うべき税額を振り込む、ように構成される。種々の実施形態では、税管轄はオンライン取引先の住所、顧客の位置、及び／又は顧客が金融取引を行うために使用するコンピュータ装置の位置に関係付けられている。
【００１９】
さらに別の実施形態では、プロセッサが、金額を１つ以上の関連する税務当局に電子資金振替システムを介して振り込むようにさらに構成される。別の実施形態では、プロセッサが、支払い義務がある税額及び特定の期間にわたる金融取引情報を用いて、１つ以上の関連した税務当局に振り込まれた金額をメモリに記憶するようにさらに構成される。さらに別の実施形態では、プロセッサが、１つ以上の関連した税務当局のそれぞれに対して会計報告書を作成するように特に構成され、この会計報告書は関連した税務当局に支払い義務がある税額、関連した税務当局に振り込まれた税額、及び税金が関連した税務当局に支払われた金融取引に関連した情報の少なくとも一部を含んでいる。
【００２０】
本発明の種々の他の実施形態によれば、オンライン取引先に対して行われた金融取引を処理するためのシステムが提供される。このシステムは支払いサービスプロバイダ用モジュールを具備し、この支払いサービスプロバイダ用モジュールは、（１）顧客の所在地に関連した第１の位置と要求を発生したコンピュータ装置の第２の位置とを含む、顧客の口座からオンライン取引先に資金を移動する要求を受信し、（２）この要求を受信すると、第１の位置、第２の位置、及びオンライン取引先の住所を、オンライン取引先に対する資金の移動を規定する位置のリストと比較し、（３）第１の位置、第２の位置、及びオンライン取引先の住所が位置のリストの位置と一致する場合、１つ以上の監督機関が第１の位置、第２の位置、又はオンライン取引先の住所において、顧客の口座からオンライン取引先への資金の移動を規制するかどうかを決定し、そして、（４）１つ以上の監督機関が第１の位置、第２の位置、又はオンライン取引先の住所において、オンライン取引先への資金の移動を規制すると決定する場合、１人以上の顧客、取引先、又は金融取引に関連した顧客の口座に関連した銀行に対して、資金の移動が管理される１つ以上の規制の種類を通知する、ように構成される。規制の種類には、１つ以上の移動の禁止、移動の制限、又は移動への課税が含まれる。１つの実施形態では、第２の位置は要求を発生したコンピュータ装置に対して発行されたインターネットプロトコルに関連付けられる。
【００２１】
本発明の種々の実施形態によれば、オンライン取引先に対して行われた金融取引を処理するための第２のシステムが提供される。このシステムは支払いサービスプロバイダ用モジュールを具備し、この支払いサービスプロバイダ用モジュールは、（１）顧客の所在地に関連した第１の位置と要求を発生したコンピュータ装置の第２の位置とを含む、顧客の口座とオンライン取引先との間で金融取引を行うための要求（例えば、オンライン取引先に対してギャンブルの賭け金を入力する要求、資金をオンライン取引先に移動する要求、又はオンライン取引先に対して入力された１つ以上のギャンブルの賭け金のために生じた支払いに対する要求）を受信し、（２）この要求を受信すると、第１の位置、第２の位置、及びオンライン取引先の住所を、オンライン取引先に対して行われた金融取引を規定する位置のリストと比較し、（３）第１の位置、第２の位置、又は取引先の住所が位置のリストの位置と一致する場合、１つ以上の監督機関が第１の位置、第２の位置、又はオンライン取引先の住所において、オンライン取引先に対して行われた金融取引を規制するかどうかを決定し、そして、（４）１つ以上の監督機関が第１の位置、第２の位置、又は取引先の住所において、金融取引を規制すると決定する場合、１人以上の顧客、取引先、又は金融取引に関連した顧客の口座に関連した銀行に対して、金融取引が管理される規制の種類を通知するように構成される。
【００２２】
１つの実施形態では、支払いサービスプロバイダ用モジュールは、１つ以上の監督機関が第１の位置、第２の位置、又はオンライン取引先の住所において、オンライン取引先と行われる金融取引を規制すると決定されたことに対応して、金融取引が取引先と行われることを禁止するようにさらに構成される。さらに、さらに別の実施形態では、この支払いサービスプロバイダ用モジュールは、１つ以上の監督機関が第１の位置、第２の位置、又はオンライン取引先の住所において、オンライン取引先と行われる金融取引を規制することが確認されたことに対応して、１つ以上のオンライン取引先又は顧客の口座に関連した銀行に通知するようにさらに構成される。
【００２３】
本発明の様々な実施形態をこのようにして一般的な用語で説明してきたが、ここで添付の図面を参照する。これらの図面は、必ずしも縮尺通りには描かれていない。
【図面の簡単な説明】
【００２４】
【図１】本発明の種々の実施形態による金融取引処理システムの、ハイレベル・ブロック図である。
【図２】本発明の種々の実施形態による金融取引処理システムの中の様々な契約関係を例示する図である。
【図３Ａ】本発明の１つの実施形態によるコンピュータ装置の概略図である。
【図３Ｂ】本発明の別の実施形態によるコンピュータ装置の概略図である。
【図４】本発明の種々の実施形態による金融取引処理システムを例示する概略図である。
【図５】本発明の種々の実施形態による取引先用モジュールのブロック図である。
【図６】本発明の種々の実施形態によるＩＰＳＰ用モジュールのブロック図である。
【図７Ａ】本発明の種々の実施形態による不正防止用サブモジュールのブロック図である。
【図７Ｂ】本発明の種々の実施形態による不正防止用サブモジュールのフローチャートである。
【図８】本発明の種々の実施形態によるＡＳＰ用モジュールのブロック図である。
【図９Ａ】本発明の種々の実施形態による委任取引処理のフローチャートである。
【図９Ｂ】本発明の種々の実施形態による委任取引処理のフローチャートである。
【図１０Ａ】本発明の種々の実施形態による決済取引処理のフローチャートである。
【図１０Ｂ】本発明の種々の実施形態による決済取引処理のフローチャートである。
【図１１】本発明の種々の実施形態による入金取消し取引処理のフローチャートである。
【図１２】本発明の種々の実施形態による顧客支払い取引処理のフローチャートである。
【図１３】本発明の１つの実施形態による委任取引要求処理のフローチャートである。
【図１４】本発明の１つの実施形態による決済取引要求処理のフローチャートである。
【図１５】本発明の１つの実施形態による強制支出動作を監視する方法のフローチャートである。
【図１６】本発明の１つの実施形態による強制ギャンブル動作を監視する方法のフローチャートである。
【図１７】本発明の１つの実施形態に基づいて、金融取引上で支払い義務がある税金を決定する方法のフローチャートである。
【図１８】本発明の１つの実施形態に基づいて、非合法又は規制の対象になる金融取引を識別する方法のフローチャートである。
【発明を実施するための形態】
【００２５】
ここで添付した図面を参照して、本発明の種々の実施形態をより完全に説明する。これらの図面には、本発明の実施形態の全てではないが、幾つかが示されている。実際に、この発明は多くの異なった形態で具体化することができるが、本願に記載された実施形態に限定されると解釈してはならない。むしろ、この開示内容が適切な法的必要条件を満足するように、これらの実施形態が提供される。同じ参照番号は全体を通して同じ要素を指す。
【００２６】
概要 全体として、本発明の種々の実施形態により、（１）支払い取引をより確実に処理し、（２）不正取引、マネーローンダリング、及び未成年のギャンブルに対して取引先及び銀行を保護するのに役立ち、かつ（３）インターネットのゲーム、旅行、及び電子商品を顧客が購入することなど特別なリスクをもたらすことが分かる電子商取引の領域で他の不正行為を制限するのを支援する、電子商取引部門に対する改良された金融取引処理システムが提供される。上記の目標を達成するために、金融取引システムの種々の実施形態により、（１）取引先、インターネット支払いサービスプロバイダ、承継銀行、及びカード機構に対する動作及び取引処理プロトコルが確立され、かつ（２）支払い及び関連した金融取引を監視及び処理するための改良された自動化システムが提供される。
【００２７】
例えば、本発明の種々の実施形態では、回転保存エスクロー勘定（rolling reserve escrow account）が各取引先に対して設定され、承継銀行又は発行銀行に対して損失の危険を減少させる態様で資金が割り当てられる。例えば、１つの実施形態によれば、取引先が受信した払い戻し（例えば、入金取消し及び返金）要求を処理するために、十分な資金を確実に利用可能にすることによって、損失の危険が低減される。１つの実施形態によれば、取引先に支払われる資金の一定の割合が保存され、一定の期間（例えば、６ヶ月、１年、又は３年）エスクロー勘定に移動されて、資金がその期間に使用されない場合は、その資金は取引先に送り戻される。回転保存エスクロー勘定に資金供給される金は取引先の潜在的利益から取り出されるため、マネーローンダリング計画に対して取引先の機能を用いることは魅力的でないことになる。さらに、種々の実施形態によれば、取引先が入金取消し要求を議論できる立場が限定されるため、争うために許容できる立場は、承継銀行又は発行銀行に対する損失のリスク（例えば、不正フラグで印が付けられている取引）をほとんど増加しない。別の実施形態では、取引先はどのような立場でも、入金取消し要求を争うことは認められない。このため、種々の実施形態によれば、回転保存エスクロー勘定により払い戻し要求を処理するための資金源が確実にされ、顧客に対する損失のリスクが低減され、そして顧客がオンラインの金融取引に従事する可能性が増加される。さらに、払い戻し要求に対して取引先が資金供給すると、承継銀行及び発行銀行に対する損失の危険が減少され、また取引先に対するより好都合な取引条件が生じる（例えば、より低い取引料金又はより低い入金取消し料金）。
【００２８】
別の実施例のように、本発明の種々の実施形態では、金融取引システムの参加者は、互いに地域の監督機関に従うように要求する。例えば、１つの実施形態では、取引先がコンプライアンスから外れる場合、インターネットの支払いサービスプロバイダ（これは後で、より詳細に説明される）、承継銀行、及びカード機構は、その取引先と取引を行うことを拒絶するであろう。別の方法では、１つの実施形態では、規則を順守しない参加者に罰金を科すことにしている。さらに、顧客は、規則を順守しない取引先と取引を行うことを拒絶することもある。このプロトコルを確立することによって、この金融取引システムは、地域の監督機関に従う参加者に対して市場刺激策を提供するようにしている。
【００２９】
金融取引システムの参加者には、本発明の種々の実施形態によれば、オンラインの顧客、オンラインの取引先、インターネット支払いサービスプロバイダ（ＩＰＳＰ）、承継銀行、発行銀行、又はカード機構が含まれる。このＩＰＳＰは取引先と承継銀行との間で動作し、取引先に支払いに関連したサービスを提供するものであり、ネットワーク上の取引先と承継銀行との間のインターフェースである。さらに、ＩＰＳＰは、会計サービスプロバイダ（ＡＳＰ）と契約して、ＩＰＳＰが取引先に対して提供する支払いサービスに関連した会計管理サービスを提供する。
【００３０】
図１は、本発明の種々の実施形態に基づいて、どのように様々な参加者が互いに結び付けられるかに関するハイレベルの概略図を例示している。例えば、参加者は取引情報を電子的にネットワーク（例えば、インターネット、プライベート・ネットワーク、又はプライベートＬＡＮネットワーク）を介して交換することができる。特に、取引情報には、顧客の支払いカードに関連した口座から取引先の口座に金を移動するための、取引先からの許可要求、顧客の口座から取引先の口座に金を移動することを許可する発行銀行からの許可メッセージ、金を取引先の口座から顧客の口座に移動することを要求する発行銀行からの払い戻し（例えば、入金取消し又は返金）要求、及び特定の期間（例えば、２４時間、４８時間、又は１週間）の間に処理された全ての取引についての各取引先に対する決済要求が含まれる。
【００３１】
前述された実施形態は、オンライン取引先から商品及びサービスを購入するために、口座に関連した支払いカード（例えば、デビットカード、クレジットカード、プリペイドカード、又は近接カード（proximity card））を使用することを説明しているが、種々の他の実施形態では、購入するために他の種類の支払いモードも使用できる。例えば、別の支払いモードには、口座に関連した支払いトークン（payment token）（例えば、物理的又は電子的なトークン）を使用すること又は口座に関連した番号（例えば、口座番号及びその口座にアクセスするためのパスワード）を使用することが含まれる。別の支払いモードには、例えばアイリススキャン、指紋、及び音声認識など、口座に関連した生物測定データを使用することによって支払いを許可する動作が含まれる。支払いは、口座番号とワンタイム・パスワードの組合せによって許可されることもある。このワンタイム・パスワードはトークンによって又は電話、イーメール、又はショート・メッセージ・サービス（「ＳＭＳ」）を介して提供される。
【００３２】
簡単に前述されたように、種々の実施形態によるこの金融取引システムは、（１）参加者に対して動作及び処理プロトコルを、また（２）金融取引を高度のセキュリティを用いて処理するように適合された自動監視及び処理システム（例えば、コンピュータのソフトウェア及び／又はハードウェア）を提供する。これらのプロトコル及び自動システムは、電子商取引において危険を招く可能性がある不正な取引や他の悪用から顧客及び参加者を保護するように機能する。システムが実行するプロトコルの種々の実施例は、以下のＡ節で詳細に説明され、自動システムの種々の実施形態は下記のＢ節で説明される。金融取引システムを通して処理される様々な取引の代表的な流れは、Ｃ節でより詳細に説明される。
【００３３】
Ａ．代表的なプロトコル
この金融取引システムの種々の実施形態により、参加者に対する動作及び処理プロトコルが提供される。種々の実施形態によれば、これらのプロトコルは、組織犯罪や取引先との取引を用いるマネーローンダリング計画を阻止し、一般にオンライン金融取引に関連した不正で認められていない取引になる危険を減少させると共に、承継銀行及び発行銀行に対して損失が生じる危険を減少させ、そして政府又は地域の規制を順守する可能性が増加される目的を果たす。例えば、本発明の種々の実施形態によれば、参加者は地域の又は管轄の監督機関を順守することを実証できる必要があり、また特定の期間の間（例えば、２年、３年、又は５年）に処理された取引の検査可能な記録を保持する必要がある。さらに、プロトコルは各参加者が他の参加者と契約を締結する前に、地域の法的な要求事項の順守を実証することを要求し、またプロトコルは参加者が、他の参加者が地域の監督機関と良い状態にあることを定期的に検証することを要求する。取引先及びＩＰＳＰに対して確立される種々の例示的なプロトコルが、以下に説明される。
【００３４】
取引先
本発明の種々の実施形態によれば、取引先は会社の管理者、職員、及び受益株主（beneficial shareholder）の身元を全て開示し、またどのような変化もＩＰＳＰに報告することが要求される。このリストが提供されることを要求すること、またこのリストを組織犯罪に関連していると疑われた人及び事業体のリストと比較することは、組織犯罪の仲間がマネーローンダリング又は他の不法な目的のために取引先の事業を使用することを阻止するために有用である。
【００３５】
さらに、本発明の種々の実施形態によれば、取引先は、承継銀行、発行銀行、及び顧客に対して不正取引からの損失が生じる危険を減らすために役に立つ１つ以上の措置を取るように要求される。例えば、種々の実施形態によれば、取引先は、（１）全ての関連した法的な要求事項を順守することを実証すること、（２）何らかの契約上の義務が破られたときには罰金を支払うこと、（３）オンライン取引の間に提供された支払い情報及び顧客情報を検証するために、取引先のコンピュータ装置上でアドレス検証、年令検証、及び身元検証用ソフトウェアを使用すること、（４）受信された支払い及び顧客情報に対して初期不正チェックを実行し、またその後で無作為に又は定期的にチェックを実行すること、又は（５）ＩＰアドレスを用いてシステムにアクセスする顧客、又は取引が不正と考えられる管轄に関連した請求書送付先を提供する顧客に注意すること、が要求される。
【００３６】
さらに、種々の実施形態によれば、取引先は、取引先の事業に関連して不正使用が生じる危険を緩和する、すなわち不正使用がある場合、取引先と取引を行うことが明らかにされた社会的な影響を緩和するプロトコル（例えば、取引先がオンラインゲームの業者であるか又は成人向けの娯楽の提供者である場合は、強制的な支出）を実行するように要求される。例えば、取引先は、その事業の社会的な影響に関して忠告及び支援のリソース（例えば、ヘルプラインや有用な情報を与えるウェブサイト用の無料通話の電話番号、又はカウンセラーについての窓口案内）を提供するように要求される。さらに、１つの実施形態によれば、取引先は、顧客が顧客サービスを呼んで取引に関する問合せを行うために、顧客の支払いカードのステートメントに対して取引先の名前及び無料電話番号を提供するように要求される。本発明の種々の実施形態によれば、顧客サービスの代表者は、２４／７を利用できる。
【００３７】
ＩＰＳＰ
本発明の種々の実施形態によれば、ＩＰＳＰは、組織犯罪の集団などがマネーローンダリングをするために取引先の事業を用いることを阻止することに役立つために、また種々の参加者に対してオンライン金融取引に関連した危険を減らすために、１つ以上の下記の安全対策を実行するように要求される。すなわち、これらの安全対策は、（１）払い戻し要求を処理する各取引先に対して、前述された回転保存エスクロー勘定を設定すること、（２）不審な行動を特定するために取引を監視すること、（３）支払いカードベース当たりの取引の回数及び金額を監視すること、（４）追跡及び監査するために、別個の流れの中で各取引先（又はウェブサイト）に対する取引を継続すること、（５）特定の期間（例えば、１年、２年、又は５年）にわたって監査トライアル（audit trial）を作り取引情報を記憶するために、取引情報を定期的（例えば、２秒又は１０秒ごと）にセーブすること、（６）カード所有者の身元を確認すること、（７）ＩＰＳＰに対して会社の管理者及び受益株主を開示するように取引先に要求すること、（８）インターネットのギャンブル業者からカード所有者に対する賞金の支払いを制限すること、及び該当する許可リスト（sanction list）（例えば、米国における「特別指定国家リスト」）に対して受取人の名前を審査すること、（９）適切な地域の法律及び規制のもとで許可を受けるように、また金融及び法律上の良い状態を保つように取引先に要求すること、（１０）契約上の義務に違反していることが判明した業者を罰する（例えば、業者との契約を終了する又は業者に罰金を科することによって）こと、（１１）良く規制された管轄の中で動作する幾つかの層１の（Tier 1）承継銀行を用いて、それらの銀行に認定されること、（１２）セキュリティ保護されたカード所有者の情報を保持するために、取引先が方式、手順及び規格を実行することを要求すること（例えば、ビザ（VISA）の口座情報セキュリティ（「ＡＩＳ」）プログラムによって認定されること）、そして（１３）マネーローンダリングに関する金融活動作業部会（Financial Action Task Force on Money Laundering）の勧告（例えば、www.FATF-GAFI.org）を運用及び適用することである（例えば、付属書Ａに添付したInternational Monetary Fundによって公表された「Anti-Money Laundering/Combating Terrorist Financing Methodology (with FATF 40+9 incorporated)」を参照されたい）。さらに、種々の実施形態では、不正であることが判明した又は不正であると決定された、ＩＰＳＰによって処理された取引に関する情報を記憶するために、ＩＰＳＰは図１に示されている不正用データベース４２保持している。１つの実施形態によれば、ＩＰＳＰにより、参加者が取引を処理するときにこの不正用データベースを使用できるようになるため、発行銀行、承継銀行、取引先、及び顧客に対して損失が生じる危険を更に減らすことができる。ＩＰＳＰは自身の口座や不正用データベースを管理し、処理する取引を調停し、また取引先に対して一致報告書を発行することができるが、別の実施形態によれば、ＩＰＳＰは１つ以上のこれらのサービスを提供するために、ＡＳＰと契約することができる。
【００３８】
さらに、本発明の１つの実施形態による例示的なプロトコルは、ＩＰＳＰが各取引先に対して別個の企業体（例えば、ＳＧ１、ＳＧ２、ＳＧ３、など）を作り、これらの企業体がＩＰＳＰ及び／又はＡＳＰの指揮の下で、企業体に関連した特定の取引先に対して受信された資金を管理するように動作することを要求する。このことは、図１４に関連してより詳細に説明される。種々の実施形態によれば、この事業形態は、各取引先の動作を分離する。さらに、種々の実施形態によれば、この事業形態は、この事業形態により、金融取引システム及び顧客を保護するために保持されているエスクロー資金を確実に公正で客観的に制御する合法的な形態が提供される。
【００３９】
承継銀行
本発明の種々の実施形態によれば、例示的なプロトコルは、発行銀行及び顧客に対してオンライン取引に関連した危険を減少させるために、承継銀行が１つ以上の下記の安全対策を実行するように要求する。すなわち、これらの安全対策は、（１）顧客が確実に賞金又はクレジットを取引先から自身の支払いカードに受け取ることができるように、オンライン取引先のクレジット活動を監視すること（例えば、VISAが後援しているクレジット所有者資金移動（cardholder funds transfer）（ＣＦＴ）パイロット及びMasterCardが後援しているマネー・フロー・パイロット）、（２）全てのカード機構に対する規定（card scheme regulation）がＩＰＳＰと取引先に確実に伝達されること、（３）取引情報がカード機構及び発行銀行によって指示された正しいデータ要素を確実に有していること、そして（４）ＩＰＳＰが該当する規制体系を確実に順守することである。
【００４０】
参加者の間の協定
本発明の種々の実施形態によれば、１つ以上のシステムプロトコルが参加者間の協定に組み込まれて、確立されたプロトコルを確実に順守するようにされる。例えば、図２は、本発明の種々の実施形態に基づいて、参加者間の契約関係の概略図を例示している。特に、承継銀行３６、ＩＰＳＰ３４、及び各取引先３１、３２、３３は、三者間処理契約（three-way processing contract）４５に参加することができる。この三者間処理契約は、取引を処理する方法に関して各当事者の義務を示している。この協定４５は各当事者に、地域の監督機関と良好な関係を保つこと、職員、管理者、及び受益株主の更新されたリストを別の関係者に提供すること、取引情報に対して身元の検証及び不正行為の調査を行うこと、及び特定の期間（例えば、１年、３年、５年）にわたって取引情報を保存することを要求する。さらに、１つの実施形態によれば、協定４５は、取引先が払い戻し要求を議論することができる１つ以上の場所を備えることができる。別の実施形態によれば、協定４５は、不渡りのために取引先３１、３２、３３に対して請求できる料金を定めることができる。
【００４１】
さらに、承継銀行３６及び合え４は、信託契約４７に加入することができる。この信託契約４７は、ＩＰＳＰが各取引先のために精算を要求したとき（例えば、毎日又は毎週）、ＩＰＳＰが取引データ上で実行すべき特定の不正チェックを行う。
【００４２】
ＡＳＰ３５及び取引先３１、３２、３３は、エスクロー契約４９に加入することができる。このエスクロー契約４９は、どのようにＡＳＰが取引先のために回転保存エスクロー勘定を管理するかを示している（例えば、エスクロー勘定に対して取り出される資金の割合、その資金がエスクロー勘定に保管される期間、又は一致報告書の書式）。
【００４３】
さらに、ＡＳＰ３５及びＩＰＳＰ３４は、サービス契約４３に加入することができる。このサービス契約４３は、ＡＳＰがＩＰＳＰに提供した会計サービスに関連した各当事者の義務を示している（例えば、ＡＳＰとＩＰＳＰとの間で交換されたデータの書式及び接近可能性、ＡＳＰがＩＰＳＰ３４に対して又はＩＰＳＰ３４のために作成した概略報告の種類及び書式、１人以上の参加者に支払うことができる料金の計算、又は取引先に対して一致報告書を承認するための承認手順）。その他に、１つの実施形態では、ＡＳＰ３５は契約４３によって、ＩＰＳＰ３４又はＩＰＳＰ３４の代わりにＡＳＰ３５によって処理された取引に関して、取引先３１、３２、３３からの問合せに応答するように要求される。さらに、別の実施形態では、ＡＳＰ３５は、（ａ）入金取消し要求に関連した、ＩＰＳＰ３４の代わりにＡＳＰ３５によって処理された全ての取引データを識別するように、また（ｂ）この識別されたデータを取引先３１、３２、３３に転送して、入金取消し要求に関連して取引先３１、３２、３３が行うことを希望するさらに別の動作は、もしあれば、何であるかを確認するように要求される。
【００４４】
Ｂ．取引を監視及び処理するための自動システム
当業者によって明らかなように、本発明は、方法、取引処理システム、又はコンピュータプログラム製品として具体化される。従って、本発明は完全にハードウェアの実施形態、完全にソフトウェアの実施形態、又はソフトウェアとハードウェアの態様を組み合わせた実施形態の形をとることができる。さらに、本発明は、記憶媒体の中で具体化されたコンピュータが読取り可能な記憶媒体（例えば、コンピュータソフトウェア）上でコンピュータプログラム製品の形をとることができる。より具体的に説明すると、本発明は、ウェブで実行されるコンピュータソフトウェアの形をとることができる。ハードディスク、ＣＤ−ＲＯＭ、光記憶装置、又は磁気記憶装置を含む任意の適当なコンピュータが読取り可能な記憶媒体を使用することができる。
【００４５】
本発明の実施形態に基づいて、方法、装置（すなわち、システム）及びコンピュータプログラム製品のブロック図及びフローチャートを参照して、本発明は下記のように説明される。ブロック図及びフローチャートの各ブロック、及びブロック図及びフローチャートの中のブロックの組合せは、それぞれコンピュータプログラム命令が実行することができることは理解されよう。これらのコンピュータプログラム命令は、汎用コンピュータ、特殊目的のコンピュータ、又は他のプログラム可能なデータ処理装置にロードされて、コンピュータ又は他のプログラム可能なデータ処理装置上で実行されるこれらの命令が、フローチャートのブロックの中で指定された機能を実行するための手段を作り出すような装置を作る。
【００４６】
コンピュータ又は他のプログラム可能なデータ処理装置を特定の方法で機能させることができるこれらのコンピュータプログラムの命令を、コンピュータが読取り可能なメモリの中に記憶して、コンピュータが読取り可能なメモリの中に記憶された命令が、フローチャートのブロックの中で指定された機能を実行するコンピュータが読取り可能な命令を含む製品を作ることもできる。コンピュータプログラムの命令をコンピュータ又は他のプログラム可能なデータ処理装置にロードし、一連の動作ステップをコンピュータ又は他のプログラム可能な装置上で実行させて、コンピュータの実行による処理を行い、コンピュータ又は他のプログラム可能な装置上で実行される命令がフローチャートのブロックの中で指定された機能を実行するステップを提供することもできる。
【００４７】
従って、ブロック図及びフローチャートのブロックは、指定された機能を実行する手段の組合せ、指定された機能を実行するステップの組合せ及び指定された機能を実行するプログラム命令の手段に対応する。ブロック図及びフローチャートの各ブロック及びブロック図及びフローチャートの中のブロックの組み合わせは、指定された機能若しくはステップ、又は特殊目的のハードウェア及びコンピュータ命令の組み合わせを実行する特殊目的のハードウェアベースのシステムによって実行されることができることも理解されよう。
【００４８】
本願で説明される種々の実施形態では、「コンピュータ」又は「コンピュータ装置」という用語が参照される。そのようなコンピュータは、例えば、メインフレーム、ディスクトップ、ノートブック又はラップトップ、データ収集・記憶装置などの手持ち式装置（hand held device）とする、又は例えば無線電話などの他の装置の中に組み込まれた処理装置とすることができる。幾つかの具体例では、コンピュータは、ネットワークを介してデータ又はプロセッサにアクセスするために使用される「ダム」ターミナルとすることができる。図３Ａを参照すると、本発明の種々の実施形態の態様を実行するために使用できるコンピュータ装置の１つの実施形態が例示されている。図３Ａでは、定義されたステップを実行するために、マイクロプロセッサなどのプロセッサ１が、ソフトウェア命令を実行するために使用される。このプロセッサは電源装置１７から給電され、電源装置１７は必要な場合、他の構成要素にも電力を供給する。プロセッサ１は、一般に１６又は３２ビット幅（例えば、並列）のデータバス５を用いて通信する。このデータバス５は、主としてプロセッサとメモリとの間にデータやプログラム命令を運ぶために使用される。種々の実施形態では、メモリは、動作している間のみコンテンツを保持するＲＡＭ又は他の形態の主記憶装置２と考えられる。又はメモリは常にメモリのコンテンツを保持するＲＯＭ、ＥＰＲＯＭ、ＥＥＰＲＯＭ、フラッシュ、又は他の種類のメモリなどの不揮発性メモリ３とすることができる。メモリは、多量のデータを記憶するディスク記憶装置などの補助記憶装置４とすることもできる。幾つかの実施形態では、このディスク記憶装置は、専用バス（図示せず）の代わりにＩ／Ｏバス６を用いてプロセッサと通信することができる。補助記憶装置は、フロッピー（登録商標）ディスク、ハードディスク、コンパクトディスク、ＤＶＤ、又はコンピュータ技術に熟練している人には周知の他の任意の種類の大量記憶装置とすることができる。
【００４９】
プロセッサ１は、Ｉ／Ｏバス６を用いて様々な周辺機器又は外部装置とも通信する。種々の実施形態では、周辺Ｉ／Ｏコントローラ７が、種々の入力／出力装置を接続するために適当なＲＳ−２３２、ＲＳ４２２、ＤＩＮ、又は他のインターフェースなどの標準的なインターフェースを提供するために使用される。代表的な入力／出力装置には、ローカルプリンタ１８、モニタ８、キーボード９、及びマウス１０又は他の一般的なポインティング装置（例えば、ローラーボール、トラックパッド、ジョイステックなど）が含まれる。
【００５０】
プロセッサ１は、多くの場合、通信Ｉ／Ｏコントローラ１１を用いて外部通信ネットワークとも通信し、またＸ．２５、ＩＳＤＮ、ＤＳＬ、ケーブルモデムなどのデータ通信指向のプロトコル１２など種々のインターフェースを使用することができる。この通信コントローラ１１は、標準的な通信回線１３とインターフェースで接続しかつ通信するために、モデム（図示せず）を組み込むこともできる。最後に、この通信Ｉ／Ｏコントローラは、ＬＡＮを介して通信するために、イーサネット（登録商標）用インターフェースを組み込むことができる。これらのインターフェースのいずれかは、インターネット、イントラネット、ＬＡＮ、又は他のデータ通信機器などの広域ネットワークにアクセスするために使用することができる。
【００５１】
さらに、プロセッサ１は、無線インターフェース１６と通信することができる。この無線インターフェース１６は、例えばＩＥＥＥ ８０２．１１プロトコル、８０２．１５．４プロトコル、又はＣＤＭＡ２０００ １ｘ ＥＶ−ＤＯ、ＧＰＲＳ、Ｗ−ＣＤＭＡ、又は他のプロトコルなどの標準的な３Ｇ無線電気通信プロトコルの１つを用いて、他の装置と無線で通信するためにアンテナ１５と動作可能なように接続される。
【００５２】
使用できる処理システムの別の実施形態は、図３Ｂに示されている。この実施形態では、ローカルクライアント用コンピュータ２６ａ又はリモートクライアント用コンピュータ２６ｂのどちらかと通信するサーバ２０を含む分散型通信及び処理アーキテクチャが示されている。このサーバ２０は、主として、データベース２２（例えば、ＳＱＬデータベース）と通信するプロセッサ２１を備えている。このデータベース２２は、主記憶装置２４の形態だけではなく補助記憶装置の形態とみなすことができる。このプロセッサは、通常はＬＡＮ２５と接続するＩ／Ｏコントローラ２３を用いて、外部装置とも通信する。このＬＡＮは、ネットワークで結ばれたプリンタ２８及びローカルクライアント用コンピュータ２６ａに対する接続性を提供する。これらの装置は、必ずしも同じ部屋の中に配置する必要はないが、サーバと同じ施設の中に配置できる。リモート装置との通信は主として、ＬＡＮ２５から通信機器を介してインターネットなどのワイドエリアネットワーク２７にデータを方向付けることによって達成される。リモートクライアント用コンピュータ２６ｂはウェブブラウザを実行して、このリモートクライアント用コンピュータ２６ｂが、必要に応じて、データをワイドエリアネットワーク２７を通りＬＡＮ２５を介してサーバ２０に送信することによって、サーバとの相互作用ができるようにする。さらに、ウェブブラウザは、例えば、Java（登録商標） Script and Microsoft.netで開発されたユーザーインターフェースを備えることができる。
【００５３】
データネットワークの技術に優れた人は、多くの別の代わりの技術やアーキテクチャも実行可能であり、また本発明の種々の実施形態を実行するために使用できることを理解するであろう。図３Ａ及び図３Ｂで例示された実施形態は、様々な方法でまた本発明の範囲の中で修正することができる。
【００５４】
図４は、本発明の種々の実施形態に基づいて、各参加者と関連付けられ、また１つ以上のネットワーク１１５（例えば、プライベートネットワーク、プライベートＬＡＮネットワーク、又はインターネット）を介して互いに通信するコンピュータ装置１０１〜１０９を例示している。例えば、１つの実施形態によれば、ＩＰＳＰ３４は、ＩＰＳＰゲートウェイ４０を介して取引先３１、３２、３３及び承継銀行３６にアクセス可能であり、このＩＰＳＰゲートウェイ４０は、ＩＰＳＰネットワークを取引先３１、３２、３３及び承継銀行３６が利用しているネットワークに接続している。種々の実施形態によれば、ＩＰＳＰゲートウェイ４０は、ハードウェア、ソフトウェア、又はそれらの両者の組合せとして完全に実現することができる。１つの実施形態では、このＩＰＳＰゲートウェイ４０は、ＩＰＳＰネットワークへのアクセスを選択的に許可することによって、ＩＰＳＰ３４にまたＩＰＳＰ３４から送信された情報のセキュリティを確実にしている。例えば、ＩＰＳＰ３４と契約関係がない取引先３１、３２、３３及び承継銀行３６は、ＩＰＳＰゲートウェイ４０によってＩＰＳＰネットワークへのアクセスが拒絶される。
【００５５】
さらに、本発明の種々の実施形態によれば、承継銀行３６はカード機構用ネットワークを利用して、発行銀行３７、３８、３９と情報を交換することができる。カード機構用ネットワークの実施例には、ビザ、マスタカード、及びアメリカンイクスプレスのネットワークが含まれるが、これらに限定されることはない。
【００５６】
図３Ａ及び図３Ｂに関連して前に説明したように、種々の実施形態によれば、取引先３１、３２、３３、ＩＰＳＰ３４、承継銀行３６、及び発行銀行３７、３８、３９は、１つ以上のコンピュータ装置（例えば、１つ以上のサーバ、ＳＱＬサーバ、又はウェブサーバ）に関連付けられ、また１つ以上のこれらのコンピュータ装置は、金融取引を処理するために自動システムを備えることができる。例えば、システム１００は、取引先のシステム１０１、１０２、１０３上で動作するように構成された取引先用モジュール２００、ＩＰＳＰのシステム１０４上で動作するように構成されたＩＰＳＰ用モジュール、及びＡＳＰのシステム１０５上で動作するように構成されたＡＳＰ用モジュールを提供する。これらのモジュール２００、３００、４００は、１つの実施形態によれば、各参加者に対する処理機能を自動化する。これらのモジュールは、ハードウェア、ソフトウェア、又はそれらの両者の組合せとして完全に実現することができる。
【００５７】
さらに、１つの実施形態によれば、このＡＳＰ用モジュール４００は、ＩＰＳＰ３４がＡＳＰ３５と契約して口座関連のサービスを提供する場合は、ＡＳＰシステム１０５上で動作するように構成することができ、又は別の実施形態では、ＡＳＰ用モジュール４００は、ＩＰＳＰのシステム１０４上で動作するように構成することができる。これらのモジュールの種々の実施形態は、図５〜図８に関連して以下により詳細に説明される。
【００５８】
取引先用モジュール
図５は、本発明の種々の実施形態による取引先用モジュール２００のブロック図を例示している。種々の実施形態によれば、取引先用モジュール２００は、取引先のシステム１０１、１０２、１０３上で動作し、取引先が取引を処理するために実行する工程の少なくとも一部を自動化する。例えば、この取引先用モジュール２００は、ステップ２０２として示される許可要求を処理するように構成される。ステップ２０２では、取引先用モジュール２００は、顧客から支払い要求を受け取る。この支払い要求には、顧客の氏名、請求書送付先、イーメールアドレス、クレジットカード番号、ＣＶＶ２番号、支払い金額、又はカード発行会社名の幾つか又は全てが含まれている。次に、この取引先用モジュール２００は、クレジットカードの番号が有効な番号であるかどうか、また全ての欄が吸入されているかどうかを検証することなどにより、受信した支払い情報の書式を検証する。この取引先用モジュール２００は、顧客情報を３Ｄ秘密ソフトウェア・プラグイン（3-D secure software plug in）に関連して前に記憶した識別番号及びパスワードと比較するようにさらに構成される（例えば、Visaによる検証及びMasterCardによるSecureCode）。書式が正しい場合、取引先用モジュール２００は許可要求を発生し、それをさらに処理するためにＩＰＳＰシステム１０４に送る。
【００５９】
本発明の種々の実施形態によれば、この取引先用モジュール２００はまた、ステップ２０６で示されているように、受け取った取引要求に対して基本的な不正チェックを実行するように構成される。この基本的な不正チェック用ステップ２０６は、例えば、クレジットカード番号を盗まれたクレジットカード番号のリストと比較する動作、顧客によって与えられた請求書送付先が支払いカード用の請求書送付先と一致することを確認する動作、与えられた請求書送付先を顧客が最初に取引先に登録したときに提供した請求書送付先と比較する動作、又はカード発行会社名がそのカード用の銀行照合番号（ＢＩＮ）と一致することを検証する動作を含むことができる。さらに、不正チェック用ステップ２０６は、図５に示されているように、許可要求がＩＰＳＰに送られた後で（ステップ２０２）、又は許可要求を作成及び送信する前に実行される（図示せず）。１つの実施形態では、不正チェック用ステップ２０６は、許可要求が送信された後（ステップ２０２）であるが、発行銀行との合意の前に実行される。
【００６０】
潜在的な問題が不正チェック用ステップ２０６で発見されない場合は、取引先用モジュール２００は、ステップ２１０で示されているように、顧客の年令と身元を検証する。例えば、年令は、有権者登録の記録又は運転免許証の記録などのカード所有者に関する政府の記録を確認することによって、又は電子年令及び／又は身元確認サービス（例えば、ＵＫベースのＧＢグループが提供する「ＵＲＵ」サービス）とネットワーク接続を確立し、そして顧客の情報をこのサービスに与えることによって検証される。このサービスは、種々の実施形態によれば、顧客の情報を政府又は他の公文書と比較して、公共の身元と年令を検証する。１つの実施形態では、取引先用モジュール２００は、顧客が取引先に対して新しい口座を設立しているときに、年令・身元検証ステップ２１０を実行することができる。ステップ２１０の処理は、定期的に繰り返されるか、又は後で無作為に現在の顧客の身元及び年令を再検証する。さらに、図５に示されている実施形態では、年令・身元検証ステップ２１０は、不正チェック用ステップ２０６及び承認要求ステップ２０２の後で発生するように示されている。しかしながら、別の実施形態では、この年令・身元検証ステップ２１０は、承認要求ステップ２０２又は不正チェック用ステップ２０６の前に行うことができる。
【００６１】
顧客の年令及び身元が年令・身元検証ステップ２１０で検証されない場合、又は不正チェック用ステップ２０６が取引に関する潜在的な問題を発見した場合は、取引先用モジュール２００は、１つの実施形態によれば、ステップ２０８に示されているように、顧客に取引は拒絶されると知らせ、またＩＰＳＰに取引を拒絶すべきであると通知する。
【００６２】
さらに、種々の実施形態による取引先用モジュール２００は、特定の期間（例えば、セッション当たり、２４時間、又は１週間）取引先のウェブサイト上で使った金額を顧客に表示又は通知するように構成される。この情報により、顧客は取引先のウェブサイトに関連した強制的な行動を避けることができる。その上、取引先用モジュール２００は、取引先が維持している顧客に対する取引ログに顧客がアクセスできるように構成される。さらに、取引先用モジュール２００は、例えば、損失限界（例えば、ギャンブル取引）又はこの取引先のウェブサイトで使った時間及び／又は金額などに対して自主規制のガイドラインを構築するように構成される。
【００６３】
マネーローンダリングを防ぐために、この取引先用モジュール２００は、選択された金額（例えば、１５．０００ドル又は２０，０００ドル）を超える全ての取引を検査するために、マネーローンダリング防止用ソフトウェア（例えば、有効なデータを、付属書Ａとして添付された、International Monetary Fundが公表している「Anti-Money Laundering/Combating Terrorist Financing Methodology (with FATF 40+9 incorporated)」の中に記載されているパラメータと比較するソフトウェア）を実行するようにさらに構成することができる。ソフトウェアによる検査には、身元確認及び再確認、続いて検証された個人又は会社に対する確認がある。
【００６４】
ＩＰＳＰモジュール
図６は、本発明の種々の実施形態によるＩＰＳＰモジュール３００のフローチャートを例示している。１つの実施形態によれば、このＩＰＳＰモジュール３００は、ＩＰＳＰシステム１０４上で動作するように構成される。ステップ３０２で動作が開始すると、１つの実施形態によれば、ＩＰＳＰモジュール３００は、取引先のシステム１０１、１０２、１０３から受け取った許可要求を処理する。各許可要求には、特定の取引に対する支払い情報、及び顧客の氏名、顧客のイーメールアドレス、及び取引を開始するために顧客が使用するコンピュータ装置のＩＰアドレスなどの取引に関連する顧客情報が含まれる。本発明の種々の実施形態によれば、このＩＰＳＰモジュール３００は次に、許可要求を承継銀行のシステム１０６に送り、この承継銀行のシステム１０６はこの許可要求を該当する発行銀行のシステム１０７、１０８、１０９に転送する。図９Ａ及び図９Ｂに関連して以下により詳細に説明するが、種々の実施形態によれば、ＩＰＳＰモジュール３００は、発行銀行のシステム１０７、１０８、１０９から承継銀行のシステム１０６を介して、取引を許可する又は拒絶すると記載された許可メッセージを受け取り、その許可メッセージを取引先のシステム１０１、１０２、１０３に送る。
【００６５】
種々の実施形態によれば、ステップ３０４では、ＩＰＳＰモジュール３００は、自身が処理した取引情報（例えば、許可要求、入金取消し要求、払い戻し要求、及び決済要求）を保存する。この保存された取引情報は、会計監査の目的、顧客当たり、支払いカード当たり、又は取引先ベース当たりの取引の種類及び頻度を監視するため、及び決済要求を作成して、この決済要求に応じて受け取った資金の支払いを割り当てるために使用することができる。例えば、許可、入金取消し、及び払い戻し要求は、定期的に、例えば毎秒又は１０秒ごと、又はＩＰＳＰモジュール３００が受信しそして取引情報を処理するたびといった取引ベース当たりに保存することができる。これらの要求は、ある期間（例えば１日又は１週間又はそれ以上）保存することができる。さらに、種々の実施形態によれば、取引先が電子商取引に対応する１つ以上のウェブサイトを有する場合、これらの要求を取引先ベース当たり（又はＵＲＬ (ユニフォーム・リソース・ロケータ）（Uniform Resource Locator）当たり）で保存することができる。このＩＰＳＰモジュール３００は、各取引先に対する許可要求を定期的（例えば、毎日又は毎週）に各取引先に対する決済要求ファイルの中に集めて、この取引先に対する決済要求をバッチファイルの形で、決済するために承継銀行のシステム１０６に送る。このことは、ステップ３１０に関連して以下に説明される。このＩＰＳＰモジュール３００は、グループ化した取引情報を別個のファイルとして一定の期間（例えば、１年、２年、又は３年）保存することができる。
【００６６】
本発明の種々の実施形態では、ＩＰＳＰモジュール３００はまた、不正防止用サブシステム３５０を実行するように構成される。このことは、図６のステップ３０６として示され、また取引はシステム１００による決済を受ける必要があることを確認するために、図７Ａ及び図７Ｂに関してより詳細に以下に説明される。例えば、支払いカード番号が盗まれた支払いカード番号のリストに列挙されている、顧客のＩＰアドレスの国が支払いカードが発行された国と一致していない、又は顧客が国家制裁リスト（national sanctions list）（例えば、米国の「Specially Designated Nationals list」）に載っている場合、ＩＰＳＰモジュール３００は取引を決済するために提出しない。図６に示されている実施形態では、不正防止用サブシステム３５０の実行は、許可要求処理ステップ３０２及び取引情報保存ステップ３０４の後で生ずるように示されている。しかしながら、本発明の別の実施形態によれば、ステップ３０２において許可要求を承継銀行のシステム１０６に送る前に、又はステップ３０４において取引情報を保存する前に、ＩＰＳＰモジュール３００はステップ３０６を実行することができる。
【００６７】
本発明の種々の実施形態によれば、不正防止用サブモジュール３５０が、ステップ３０６において取引に対する潜在的な不正行為を検出した場合、ＩＰＳＰモジュール３００は、ステップ３０８に示されているように、該当する当事者に疑わしい不正行為を通知するように構成されている。この該当する当事者には、種々の実施形態によると、承継銀行３６（この銀行は、通知を発行銀行に送る）、発行銀行３７、３８、３９（直接接続されている）、取引先３１、３２、３３、及び／又は顧客が含まれる。さらに、ＩＰＳＰモジュール３００は、種々の実施形態によれば、ステップ３１２に示されているように、潜在的に不正な取引に関する情報を不正用データベース４２に記憶する。この不正用データベース４２は、後続する取引を分析するために、ＩＰＳＰモジュール３００に利用される。さらに、１つの実施形態では、不正用データベース４２は、カード発行会社ネットワーク及び／又は承継銀行にアクセスして、受信された取引を分析することができる。さらに、この不正用データベース４２は、１つ以上の下記の欄、すなわち、顧客の名前、住所、ＩＰアドレス、支払い情報（例えば、カード又は口座番号）、電話番号、及び前の不正行為を識別するコード又は説明を含むことができる。
【００６８】
ステップ３１０に示されているように、不正防止用サブモジュール３５０がステップ３０６において潜在的な不正行為を検出しない場合は、ＩＰＳＰモジュール３００は、種々の実施形態によれば、決済要求を作成して、それを承継銀行のシステム１０６又は発行銀行のシステム１０７、１０８、１０９に送信する。この決済要求は、特定の期間（例えば、１日又は１週間）の間にＩＰＳＰモジュール３００が受け取った許可、入金取消し、及び払い戻し要求に基づいている。決済要求には、１つの実施形態によれば、ＩＰＳＰモジュール３００及び取引先用モジュール２００により潜在的な不正行為として検出されなかった取引のみが含まれる。別の方法では、決済要求には、ＩＰＳＰモジュール３００又は取引先用モジュール２００により潜在的に不正であるとして検出された１つ以上の取引が含まれるが、それらの取引は潜在的に不正であるとして決済要求の中でマークされるか又はフラグが立てられる。
【００６９】
前述したように、ＩＰＳＰモジュール３００は、ステップ３０６で不正防止用サブモジュール３５０を実行する。本発明の種々の実施形態による例示的な不正防止用サブモジュール３５０が、図７Ａ及び図７Ｂに示されている。図７Ａに示されているように、この不正防止用サブモジュール３５０は、本願で「不正検出フィルタ」と呼ばれる種々のステップを実行して、潜在的に不正な取引行為を検出し、特定の不正検出フィルタの結果又は不正検出フィルタのグループの結果の組合せにより取引を阻止する又はその取引にフラグを立てるように構成される。ステップ３５２〜３６８は、本発明の種々の実施形態によれば、不正防止用サブモジュール３５０によって実行される幾つかの不正検出フィルタを示す。図７Ｂは、どの不正検出フィルタを取引情報に適用するかを決定するために、不正防止用サブモジュール３５０によって実行されるステップを例示している。
【００７０】
例えば、図７Ａのステップ３５２に示されているように、この不正防止用サブモジュール３５０は、支払いカードの情報を盗まれた支払いカードを識別するリストと比較することができる。さらに、ステップ３５４に示されているように、不正防止用サブモジュール３５０は、支払いカードを発行した金融機関に関連した位置を、顧客のコンピュータ装置に関連したＩＰアドレスに対応する位置と比較することができる。顧客のコンピュータ装置に関連したＩＰアドレスは、取引情報を取引先のシステム１０１、１０２、１０３が最初に受信したときに、取引先用モジュール２００によって（例えば、取引先用モジュール２００の中に組み込まれたＩＰアドレス検出用ソフトウェアを用いることによって）得ることができる。さらに、不正防止用サブモジュール３５０は、顧客のコンピュータ装置のＩＰアドレスに関連した位置を顧客の請求書送付先と比較して、顧客のコンピュータ装置の位置が請求書送付先の特定の半径内にある（例えば、５０マイル）ことを確認する。同様に、不正防止用サブモジュール３５０は、ステップ３５６に示されているように、支払いカードを発行した金融機関に関連した位置を、顧客が与えたイーメールアドレスに関連した位置と比較する、又はステップ３５７に示されているように、顧客のコンピュータ装置のＩＰアドレスの位置を、顧客が与えたイーメールアドレスに関連した位置と比較することができる。上記で比較された位置は、１つ以上の国、地方、州、地域、郡、市、又は１つ以上の郵便番号によって定義された郵便区域を含むことができる。
【００７１】
さらに、ステップ３５８に示されているように、不正防止用サブモジュール３５０は、支払いカードの銀行識別番号（ＢＩＮ）を疑わしいＢＩＮのリストと比較することができ、またステップ３６０では、この不正防止用サブモジュール３５０は、ウェブメールのイーメールアドレス（例えば、HOTMAIL 又は YAHOOのイーメールアドレス）を有する顧客が開始した取引を識別して、それにフラグを立てることができる。さらに、ステップ３６２に示されているように、不正防止用サブモジュール３５０は、顧客の情報を、政府の管轄内で取引先との金融取引に従事することを禁止されている人に対する政府編集のリストと比較することができる。顧客が、米国が発行した「Specially Designated Nationals list」のような司法権が発行した金融制裁を受ける人、グループ、及び事業体のリストで確認される場合、取引は拒絶される。同様に、ステップ３６８に示されているように、不正防止用サブモジュール３５０は、顧客のコンピュータ装置のＩＰアドレスに関連した国を、特定の管轄内で取引先と取引をすることを禁止されている国のリストと比較することができ、ＩＰアドレスの国がリスト上にある場合は、取引は拒絶される。さらに、ステップ３６７に示されているように、不正防止用サブモジュール３５０は、顧客の情報をオンライン取引先の職員、管理者、又は所有者のリストと比較することができ、顧客がこのリストに載っている場合は、取引は潜在的に不正であるとしてフラグが立てられるか又は拒絶される。
【００７２】
種々の実施形態によれば、不正防止用サブモジュール３５０は、ステップ３６４に示されているように、特定の期間（例えば、１月、１年）にわたって各顧客又は各カードに対する取引の回数を監視するようにさらに構成することができる。さらに、ステップ３６６に示されているように、不正防止用サブモジュール３５０は、特定の期間にわたって各顧客又はカードに対する取引の種類（例えば、ギャンブル取引、旅行の取引、成人向け娯楽の取引）を監視するように構成することができる。カード当たり又は顧客当たりのベースで取引の回数及び種類を監視することによって、不正防止用サブモジュール３５０は、本発明の種々の実施形態によれば、（１）カードを使用するパターンが劇的に変化する場合、カードの潜在的な不正使用を発見することができ、また（２）顧客がより頻繁に又はあまりにも頻繁に特定の種類の取引に従事する場合、潜在的な耽溺又は乱用を特定することができる。監視するステップ３６４及び３６６は、１つの実施形態によれば、顧客の前の取引に基づいて取引の頻度及び／又は種類の範囲を確立して、将来の取引を確立された範囲と比較することによって達成することができる。別の実施形態によれば、不正防止用サブモジュール３５０が使用する範囲は、学問的又は制度上の調査などの結果として、地方自治体又は監督機関によって発行されるか、又は１人以上の参加者によって確立される。
【００７３】
図１５は、本発明の種々の実施形態に基づいて、強制支出動作を監視する工程を例示している。特に、ステップ５０２で開始すると、ＩＰＳＰモジュール３００は、金融取引に対する新しい要求を受信する。この新しい要求を受信することに応じて、ＩＰＳＰモジュール３００は、ステップ５０４として示されているように、特定の取引先３１、３２、３３と顧客との間の前に要求された金融取引に関連して、メモリ２４に記憶されている資金の総額を取り出す。ステップ５０６では、引き出された資金の額と新しい要求に関わる資金の額の合計が、取引先３１、３２、３３に対して使われる資金の予め決められた許容限度と比較される。この合計が予め決められた許容限度を超える場合は、ＩＰＳＰモジュール３００は、ステップ５０８に示されているように、該当する当事者（例えば、顧客、発行銀行、及び／又は取引先）に限度が超過されたことを通知する。本発明の別の実施形態では、このＩＰＳＰモジュール３００は、特定の期間（例えば、２４時間、３６時間、１週間、１月、１年）にメモリに記憶されている資金の総額を取り出すことができる。さらに、別の実施形態では、ＩＰＳＰモジュール３００は、特定の期間に顧客と取引先との間で行われた取引の回数を比較して、行われた取引の回数が所定の限度を超えると、顧客、発行銀行、及び／又は取引先に限度が超過されていることを通知する。
【００７４】
同様に、図１６は、本発明の種々の実施形態に基づいて、強制的なギャンブル動作を監視する方法を例示している。ステップ６０２で開始すると、ＩＰＳＰモジュール３００は、金融取引に対する新しい要求を受信する。この新しい要求には、資金の総額及び取引の種類が含まれる（例えば、取引先への資金の移動、取引先への賭け金の入金、取引先からの支払い要求）。次に、ステップ６０４では、ＩＰＳＰモジュール３００は、新しい要求の中の金融取引の種類に対して、メモリ２４に記憶されている資金の総額を取り出す。次に、ステップ６０６では、資金の総額と新しい要求の中の資金の額の合計が、新しい要求の中の金融取引の種類に関連して予め決められた許容限度と比較される。この合計が予め決められた許容限度を超える場合は、ＩＰＳＰモジュール３００は、ステップ６０８に示されているように、該当する当事者（例えば、顧客、発行銀行、及び／又は取引先）に限度が超過されたことを通知する。１つの実施形態では、この合計が予め決められた許容限度を超える場合、新しい要求は拒絶される。さらに、メモリから取り出された資金の総額は、特定の期間内に記憶された資金に対して制限され、また予め決められた許容限度は問合せされた期間に基づいて変化される。
【００７５】
前述した取引の種類を監視することに加えて、本発明の種々の実施形態によれば、不正防止用サブモジュール３５０は、払い戻し要求の取引を監視して、疑わしい取引を特定するようにさらに構成される。払い戻し要求の情報が当初の取引の情報と一致しない取引を識別することによって、又は特定の期間（例えば、１週間、１月、又は数ヶ月内）に特定の支払いカードに対して著しい数の払い戻し要求があることを確認することによって、疑わしい払い戻し要求の取引を特定することを受けて、この支払いカードの番号を禁止された支払いカードのリストに加えて、この支払いカードを用いる将来の購入取引を回避することができる。
【００７６】
上記のフィルタに加えて、本発明の種々の実施形態によれば、不正防止用サブモジュール３５０は、（１）各顧客は確実に１枚の支払いカードしか使用しないようにする、また（２）各顧客に対する特定の取引行為を特定の期間当たり特定の回数（例えば、１日当たり１回の支払い又は３６時間当たり３回の支払い）にして、支払いを制限するようにさらに構成される。さらに、１つの実施形態によれば、特定の期間（例えば、１日、１週間、１ヶ月当たり）の特定のサービス（例えば、インターネットのゲーム又は成人向けの娯楽）に対して、カード当たり又は顧客当たりが費やす金額に上限を設定することができる。１つの実施形態では、この上限は顧客の要求に応じて設定することができる。別の実施形態では、ＩＰＳＰシステム１０４は、特定の活動に使うことができる金額に対してデフォルト限界（default limit）（例えば、支払いカードに関連した２０％のクレジット限界）を取り入れることができる。この限界は、顧客の明白な要求がない場合は増加することはできない。１つの実施形態によれば、ＩＰＳＰシステム１０４又は取引先のシステム１０１、１０２、１０３は、支出限度を増加するための要求に答えて、資力以上に金を使うことの危険に関して、特に訓練された従業員からの電話又は顧客に対するイーメールなどにより顧客に材料を提示するように、また潜在的な不正使用が検出されたときは材料又は情報源（例えば、Gamblers Anonymousの電話番号、ウェブサイトのアドレス、又は他の材料）を示すように構成することができる。
【００７７】
本発明の種々の実施形態によれば、ＩＰＳＰシステム１０４は、不正防止用サブモジュール３５０からの結果を記憶する不正及び不正使用データベース（図示せず）をさらに備えている。１つの実施形態では、ＩＰＳＰモジュール３００は、取引を処理するとき（ステップ３０２）又は不正防止用サブモジュールを実行するとき（ステップ３０６）にデータベースにアクセスして、特定の支払いカード又は顧客に対する以前の不正チェックに基づいて、取引を拒絶すべきかどうかを決定する。
【００７８】
図７Ｂに示すように、不正防止用サブモジュール３５０は、本発明の１つの実施形態によれば、１つ以上の前述した不正検出フィルタを使用して、受信された取引情報を評価する。ステップ３７０で開始すると、この不正防止用サブモジュール３５０は、ＩＰＳＰモジュール３００から取引データを受け取る。次に、ステップ３７２において、不正防止用サブモジュール３５０は、取引データの評価に使用するために１つ以上の不正検出フィルタを決定する。例えば、１つの実施形態によれば、不正防止用サブモジュール３５０は、使用される取引先によって前もって選択された不正検出フィルタを使用する。別の実施形態によれば、使用される不正検出フィルタの種類は、取引の種類（例えば、許可要求、入金取消し要求、決済要求、又は支払い要求）又は取引の段階（例えば、取引情報が発行銀行にまだ送られていないかどうか、又はそれが発行銀行によってすでに許可されているかどうか）に依存する。さらに別の実施形態では、使用される不正検出フィルタの種類は、顧客に関連したＩＰアドレスの国に依存する。そして、別の実施形態では、どの不正検出フィルタを適用すべきかの選択は、ＩＰＳＰ及び／又は地域の監督機関によって決定される。最後に、ステップ３７４では、不正防止用サブシステム３５０は該当する不正検出フィルタを実行して、取引データを評価する。
【００７９】
不正防止用サブシステム３５０を実行することに加えて、ＩＰＳＰモジュール３００は、本発明の種々の実施形態によれば、不正であるか又は法的な規制を受ける金融取引を識別するようにさらに構成される。例えば、図１８は、不正な又は規制された金融取引を識別する典型的な工程を例示している。ステップ８０２で開始すると、ＩＰＳＰモジュール３００は、顧客の支払いカードから取引先３１、３２、３３に資金を移動するための要求を受け取る。資金を移動するための要求には、顧客の請求書送付先、及び顧客が要求を作成するために使用するコンピュータ装置に関連したＩＰアドレスの位置が含まれる。次に、ステップ８０４では、ＩＰＳＰモジュール３００は、顧客の請求書送付先、ＩＰアドレスの位置、及び取引先３１、３２、３３の位置を取引先３１、３２、３３への資金の移動が規制される位置のリストと比較する。これらの位置のいずれかが位置のリスト上の位置と一致する場合、ＩＰＳＰモジュール３００は、ステップ８０６に示されているように、１つ以上の監督機関がこれらの位置のいずれかで資金の移動を規制するかどうかを判断する。ＩＰＳＰモジュール３００が、１つ以上の監督機関が資金の移動を規制すると判断する場合、このＩＰＳＰモジュール３００は、ステップ８０８に示されているように、該当する当事者（例えば、顧客、取引先、及び／又は発行銀行）に資金の移動が支配される１つ以上の規制の種類を通知する。金融取引が支配される規制の種類には、移動の禁止（例えば、ギャンブルが違法な州又は管区内のギャンブル取引）又は移動の制限（例えば、賭け金の額を制限する州又は管区内のギャンブル取引）が含まれる。
【００８０】
ＡＳＰモジュール
図８は、本発明の種々の実施形態によるＡＳＰモジュール４００のブロック図を例示している。ＡＳＰモジュール４００は、１つの実施形態によれば、ＡＳＰシステム１０５上で動作するように構成されているが、ＩＰＳＰが、別の実施形態に基づいて、口座管理サービスを提供するためにＡＳＰと契約をしていない場合は、ＩＰＳＰのシステム１０４上で動作するように構成されることもできる。
【００８１】
ステップ４０２で開始すると、１つの実施形態によれば、ＡＳＰモジュール４００は、ＩＰＳＰシステム１０４及び承継銀行１０６から取引情報を得る。ＩＰＳＰシステム１０４から得た取引情報は、各取引に対して以下のデータフィールドが含まれる、すなわち、（１）取引先又は取引先の取引事業体（trading entity）（例えば、特定のウェブサイト）を識別するために承継銀行によって与えられた取引先識別（「ＭＩＤ」）番号、（２）取引の日付及び時刻、（３）顧客の名前、（４）支払いカード番号又は支払いカード番号の一部（例えば、最後の４桁）、（５）カード所有者のイーメールアドレス、（６）取引の有効期間、（７）使用されている支払いカードの種類（例えば、Visa、MasterCard、又はAmerican Express）、（８）支払い金額、（９）取引先が取引に割り当てた注文参照番号、（１０）取引が許可されたかどうかを示す、発行銀行が作成した独特なコードである許可コード、（１１）取引の処理ステータス（例えば、「１００」は完了した取引を示す）、（１２）ＩＰＳＰが処理要求を承継銀行に送る時刻である「処理時間」、（１３）カード所有者の街路番号、（１４）カード所有者の都市名、（１５）カード所有者の国名、（１６）カード所有者の郵便番号、（１７）親取引照会先（parent transaction reference）、すなわち、払い戻し要求の場合に払い戻される最初の取引に対する照会先、（１８）注文情報、これは取引先が希望する場合、取引に関するより多く情報を含むために使用できる、（１９）「サイト照会先」、これはＩＰＳＰの取引先に対する照会先である、（２０）取引の種類、これには許可された取引、払い戻し取引、及び取り消された取引（例えば、取り消された取引、又は発行銀行により取引先に金が移動される前で、処理要求がＩＰＳＰから承継銀行に送信される後に取引先の要求で金額が変更される取引）が含まれる、（２１）ＡＳＰシステム１０５の中で一意的に取引を識別する固有の参照番号（ＵＲＮ）、が含まれる。本発明の１つの実施形態によれば、この情報は、ＩＰＳＰから承継銀行に送られる処理要求の中にも含まれる。このことは、図６のステップ３１０に関連して前に説明されており、また図１０Ａのステップ１１０２及び１１０４に関連して後で説明される。承継銀行のシステム１０６から得られた取引情報は、例えば、取引先ごとの形で１つ以上のバッチで集められた、発行銀行から要求された資金の総額を含むことができる。
【００８２】
種々の実施形態によれば、取引情報を得るために、ＡＳＰモジュール４００は、取引情報が書き込まれている安全なウェブページ（例えば、各システム１０４、１０６によって維持されている）にアクセスし、その情報をＡＳＰシステム１０５にダウンロードし、別の種類の電子送信手段（例えば、イーメール又はファックスを介して）又は両者の組合せを介して取引情報を受信する。
【００８３】
種々の実施形態では、ステップ４０２で得られた取引情報は、ステップ４０４に示されているように、ＡＳＰシステム１０５に保存され、そしてＩＰＳＰシステム１０４から得られた情報は、ステップ４０６に示されているように、承継銀行のシステム１０６から得られた情報と比較される。図８に示された実施形態では、ステップ４０６はステップ４０４の後で生じるように示されているが、別の実施形態では、これらのステップは同時に又は逆に発生することもできる。
【００８４】
本発明の種々の実施形態によれば、比較するステップ４０６において、ＡＳＰモジュール４００は、ＩＰＳＰシステム１０４によって提供された取引情報が承継銀行のシステム１０６によって与えられた取引情報と一致しない取引を幾つか確認することがある。１つの実施形態では、幾つかの一致しない取引はフラグが立てられ、ＡＳＰモジュール４００が発生する除外報告書の中で取引先、ＩＰＳＰ、及び／又は承継銀行に報告される。このことは、ステップ４１０に関連して以下でより詳細に説明される。承継銀行のシステム１０６が各取引先に関連しまたＩＰＳＰ３６及び／又はＡＳＰ３５によって維持される口座に資金を直接移動するような別の実施形態（このことは、図１４に関連して以下に説明される）では、ＡＳＰモジュール４００は、ＩＰＳＰシステム１０４及び承継銀行のシステム１０６によって与えられた取引情報を各取引先の口座に移動された金額と比較するようにさらに構成される。
【００８５】
ＩＰＳＰシステム１０４及び承継銀行のシステム１０６によって与えられた取引情報を受け入れた後で、ＡＳＰモジュール４００は次に、決済工程の間に受け取った支払い金額を種々の参加者に割り当てる。このことは、図８でステップ４０８として示されている。この支払い金額には、例えば、取引先３１、３２、３３への支払い金額、ＩＰＳＰ３４、承継銀行３６、及びＡＳＰ３５に支払う手数料、及び各取引先３１、３２、３３に対して回転保存エスクロー勘定４１に預ける資金の割合が含まれる。例えば、種々の実施形態によれば、それぞれ異なる参加者は、取引先３１、３２、３３及び互いとの契約４３、４５、４７、４９の中のサービスに対する支払いとして、取引先３１、３２、３３が受け取った資金の一定の割合を要求することができる。例えば、承継銀行３６は、取引先３１、３２、３３が発行銀行３７、３８、３９から受け取った資金の３％を請求し、カード機構は自身のカードを用いて移動された資金の１％を請求し、ＩＰＳＰ３４はサービスに関連した支払いに対して５％を請求し、またＡＳＰ３５は会計管理サービスに対してＩＰＳＰ３４が受け取った金の３パーセントをＩＰＳＰ３４に請求することができる。別の実施例では、ＡＳＰ３５は、カードの検証、様々な参加者に対する手数料の支払い、及び受け取った入金取消しに対して取引先３１、３２、３３に請求可能な料金などの種々のサービスに対して、ＩＰＳＰ３４が受けた暫定的な必要を計算することもできる。
【００８６】
さらに、種々の実施形態によれば、金融取引システム１００は、回転保存エスクロー勘定４１に資金を供給するために使用される資金の割合を規定するプロトコルを確立することができる。例えば、システムプロトコルは、ＡＳＰモジュール４００が各取引先３１、３２、３３が受け取る資金の７．５％を各取引先３１、３２、３３に対する回転保存エスクロー勘定４１に割り当てるように要求する。別の実施例では、１つの実施形態によれば、回数保存口座に対して規定された割合は、特定の取引先３１、３２、３３が受け取った払い戻し要求の数に応じて自動的に増加又は減少する。さらに、ＡＳＰモジュール４００は、１つの実施形態によれば、予め決められた期間（例えば、６ヶ月、１年、又は３年）口座に残っている資金を監視及び確認して、これらの資金をこの期間の終わりに、取引先３１、３２、３３に再配分する。さらに、エスクロー勘定４１は、図１の実施形態では、ＡＳＰシステム３５の一部として示されている。しかしながら、別の実施形態では、このエスクロー勘定４１は存在する、すなわち銀行又は別の金融機関によって維持される。
【００８７】
次に、ステップ４１０では、ＡＳＰモジュール４００は、種々の実施形態によれば、各取引先に対して、一致報告書又は「通知書」を作成するように構成される。１つの実施形態では、この通知書は各取引先に、特定の期間（例えば、１日又は１週間）に取引先に対して処理された取引の一覧表、（必要な場合）一致ステップ４０６で作られた除外報告書、ステップ４０８で様々な参加者のそれぞれに割り当てられた支払いの一覧表、特定の期間内のエスクロー勘定の動作の一覧表、及び取引先３１、３２、３３に支払いが移される日付、を提供する。別の実施形態では、通知書の様々な部分が、別個の報告書の中に含まれる（例えば、除外報告書、支払い割当て報告書、及び取引一覧報告書）。そして、さらに別の実施形態では、ＡＳＰモジュール４００は、それぞれが指定した特定の様式に基づいて、ＩＰＳＰ３４及び各取引先３１、３２、３３に対して１つ以上の一覧報告書を作成するように構成される。
【００８８】
図８に示された実施形態では、ＡＳＰモジュール４００は、（１）承認を得るために各取引先３１、３２、３３に対する通知書をＩＰＳＰ３４に送る（このことは、ステップ４１２に示されている）、そして（２）ステップ４１４に示されているように、ＩＰＳＰ３４から通知書に対して承認を受け取ると、ステップ４１６に示されているように、通知書を取引先３１、３２、３３に送るようにさらに構成される。ＩＰＳＰ３４が、口座管理サービス（図示せず）を提供するようにＡＳＰ３５と契約していない別の実施形態では、ステップ４１２及び４１４は実行されない。
【００８９】
さらに、ＡＳＰモジュール４００は、ステップ４１８に示されているように、本発明の種々の実施形態によれば、支払いを準備して種々の参加者及びエスクロー勘定に送るように構成される。ステップ４１８は、例えば、参加者のそれぞれに物理的に支払い金を送る工程（例えば、小切手又は現金）、ＡＳＰシステム１０５に関連した口座から金を支払う義務がある様々な参加者のそれぞれに関連した口座に電子資金移動（ＥＦＴ）を行う要求を準備する工程、又はそれら両者の組合せを行う工程が含まれる。さらに、支払いステップ４１８が図８に示された実施形態ではステップ４１６の後に生ずるように示されているが、別の実施形態によるＡＳＰモジュール４００は、ステップ４１６と同時に又はその前に支払いステップ４１８を実行するように構成することができる。
【００９０】
本発明の別の実施形態では、ＡＳＰモジュール４００は、各取引先３１、３２、３３に支払い金を送る前に、関連する電子商取引（例えば、インターネットのギャンブル取引又は小売買入）にかかる地域又は地区の税金を抑えるようにさらに構成することができる。例えば、１つの実施形態では、ＡＳＰモジュール４００は、住居の所在地又は各顧客及び／又は取引先の取引する場所に基づいて該当する税金又は認可料金を適用して、資金を直接関連する税金又は認可当局に移動するように構成することができる。
【００９１】
特に、図１７は、金融取引で支払い義務がある税金に対して会計計算する典型的な工程を例示している。ステップ７０２で開始すると、１つ以上の税金管轄のそれぞれに対する該当する税金の種類及び対応する税率は、メモリ２４の中に記憶されている。次に、ステップ７０４において、顧客と取引先３１、３２、３３との間で行われた金融取引に関連した情報が受信される。金融取引に関連した情報を受信することに呼応して、ステップ７０６に示されているように、金融取引に関連した１つ以上の関連する税金管轄が特定される。次に、ステップ７０８において、特定された税金管轄に関連した１つ以上の税金の種類を決定するために、メモリが問合せを受ける。１つ以上の種類の税金が特定された税金管轄に関連している場合は、税金の種類に対して対応する税率が金融取引に対して適用されて、取引上支払い義務がある税金が決定される。このことは、ステップ７１０に示されている。さらに、取引に対して支払うべき税金が決定されると、ステップ７１２に示されているように、支払う税額は関連する税務当局に振り込まれる。種々の実施形態では、税金は、取引オリジネータ（transaction originator）（例えば、取引先）、顧客、及び／又は顧客が注文を発行するコンピュータ装置の所在地に基づいて課せられる。
【００９２】
種々の実施形態では、差し引かれる税額及び税務当局に支払われる額は、取引情報を用いて一時期システムに記憶される。このことは、幾つかの実施形態では、完全な監査の手掛かりになる。例えば、１つの実施形態では、払われるべき金額は、指定された銀行口座に保持され、定期的に（例えば、毎月、毎週、毎日、又はリアルタイムで）税務当局に支払われる。１つの実施形態では、この払われるべき金額は電子資金移動（ＥＦＴ）機能を介して税務当局に支払われる。
【００９３】
種々の実施形態によれば、この税金会計機能は、取引先、顧客、及び税務当局の負担を軽減し、また課税対象の取引に対して信頼できる会計システムを提供する。さらに、１つの実施形態では、ＡＳＰモジュール４００は、収める税金及び／又は税金預り金を集計する、税務当局に対する会計報告書を作成する。
【００９４】
さらに、種々の実施形態では、取引記録はＡＳＰモジュール４００を介して電子的に又は手作業で監査することができる。特に、各取引に関連した固有の参照番号（「ＵＲＮ」）が、取引がシステムを通って処理されるように追跡される。例えば、１つの実施形態では、複数の取引がバッチファイルにグループ化されて、決済するために承継銀行に送られる。ＡＳＰモジュール４００は、各個々の取引を独立して監査できるようにバッチファイルを識別する情報と一緒に、各取引に関連したＵＲＮをバッチファイルの中に記憶する。
【００９５】
Ｃ．代表的な処理フロー
許可要求の処理フロー
図９Ａは、本発明の種々の実施形態による許可要求を処理するフロー１０００を例示している。１つの実施形態では、許可要求の処理は、顧客が待機している間にオンラインで行われて、それは処理するのに通常２から１２秒かかる。この許可要求が発行銀行によって承認されると、取引先は顧客の支払いを受け入れ、また発行銀行は支払いカードに関連したクレジット限界又は差引残高を超えて要求された金額を阻止する。
【００９６】
本発明の種々の実施形態によれば、許可要求の工程１０００は、顧客の支払いカードから取引先の口座に金を振り込むための顧客からの要求を取引先３１、３２、３３が受け取ることによって、ステップ１００２で開始する。この要求には、例えば、振り込まれる金額、顧客の情報及び支払いカードの情報が含まれる（取引先は、前の取引で記録された顧客の情報及び支払いカードの情報を持たないと仮定する）。１つの実施形態では、顧客及び支払いカードの情報には、顧客の氏名及び住所、顧客のイーメールアドレス、及び支払いカードの番号、満了日、及び支払いカードに関連した他の識別情報が含まれる。１つの実施形態では、この要求は取引先のシステム１０１、１０２、１０３によって受信されて、それらのシステムで保存される。
【００９７】
次に、ステップ１００６で、本発明の種々の実施形態に基づいて、取引先３１、３２、３３は、顧客の要求の中で受け取った情報の体裁を検証する。１つの実施形態では、図５及びステップ２０４に示された取引先用モジュール２００に関連して前述されたように、この取引先用モジュール２００は、支払いカード番号の体裁は正しいかどうか、また全ての必要な欄が記入済みかどうかを検証する。
【００９８】
ステップ１００６で情報の体裁を検証した後、取引先３１、３２、３３は、取引情報をさらに処理するためにＩＰＳＰ３４に転送する。このことは、ステップ１０１０に示されている。ＩＰＳＰ３４は取引情報を受け取り、またＩＰＳＰシステム１０４に保存し、ステップ１０１２に示されているように、許可要求を処理するために承継銀行３６及び発行銀行３７、３８、３９が必要な情報を承継銀行３６に転送する。例えば、この情報は、本発明の種々の実施形態によれば、ＩＰＳＰモジュール３００によって承継銀行のシステム１０６に転送され、そして支払いカードの番号、支払い金額、及び顧客の請求書送付先を含んでいる。
【００９９】
次に、ステップ１０１４では、承継銀行のシステム１０６は、許可要求を受け取り、それを承継銀行のシステム１０６に保存する。次に、ステップ１０１６では、承継銀行のシステム１０６は、該当するカード発行会社及び発行銀行を識別し、許可要求を該当するカード発行会社のネットワーク（例えば、例えば、Visa、MasterCard、又はAmerican Expressのネットワーク）を介して発行銀行に経路指定する。許可要求を受け取ると、発行銀行のシステム１０７、１０８、１０９は、ステップ１０１８に示されているように、支払いカードが使用可能で有効であり、かつステップ１０２０に示されているように、十分な資金がこの支払いカードに対して利用可能であることを検証する。許可要求を承認すると、発行銀行のシステム１０７、１０８、１０９は、ステップ１０２２に示されているように、承認メッセージをカード発行会社のネットワークを介して承継銀行のシステム１０６に送り、そして承継銀行のシステム１０６はこの承認メッセージを受け取り、ステップ１０２４においてこの承認メッセージをＩＰＳＰシステム１０４に転送する。次に、ステップ１０２６では、ＩＰＳＰシステム１０４は、承認メッセージを受け取りまた保存し、そして許可要求を作成した取引先のシステム１０１、１０２、１０３にこの承認メッセージを転送する。
【０１００】
種々の実施形態によれば、図５に関連して前述された基本的な不正チェック及び身元／年令検証ステップ（ステップ２０４及び２０６）は、取引先からＩＰＳＰに許可要求の情報を転送するステップ１０１０と同時に、その前に、又はその後で取引先用モジュール２００によって実行される。さらに、本発明の種々の実施形態によれば、不正防止用サブシステム３５０を実行するステップは、図６のステップ３０６に示されており、ＩＰＳＰから承継銀行に許可要求の情報を転送するステップ１０１２と同時に、その前に、又はその後でＩＰＳＰモジュール３００によって実行される。
【０１０１】
図１３に示されている本発明の別の実施形態では、顧客情報は、取引先のシステム１０１ａ、１０２ａ、１０３ａ及びネットワーク１１５ａを通ってＩＰＳＰシステム１０４ａに送られるときに暗号化（例えば、２０４８ビットの可変暗号化）される。さらに、ＩＰＳＰモジュール３００ａは、不正防止用サブモジュール３５０ａの１つ以上の不正検出フィルタを使用し、これらの不正検出フィルタが潜在的に疑わしい行為を検出した場合、ＩＰＳＰモジュール３００ａは、承認のために許可要求を承継銀行のシステム１０６ａに送る前に、不正チェックの結果を取引先に送る。取引先が取引に対して承認を与えた後で、ＩＰＳＰモジュール３００ａは許可要求を承継銀行に転送し、承継銀行は次に、この要求を発行銀行に送る。承継銀行が許可メッセージを発行銀行から受け取った後で、承継銀行は取引情報を承継銀行のシステム１０６ａのメモリ領域（例えば、データベース）に保存し、そして許可メッセージをＩＰＳＰシステム１０４ａに送る。ＩＰＳＰモジュール３００ａは、許可メッセージを取引先に転送し、そしてこの取引に対して決済要求を作成する前に、取引情報に対して１つ以上の不正検出フィルタを実行する。
【０１０２】
決済処理のフロー
図１０Ａ及び１０Ｂは、本発明の種々の実施形態による決済要求を処理する代表的なフロー１１００を例示している。種々の実施形態による決済要求は、取引先に支払うために、発行銀行から承継銀行に金を振り込むために、承継銀行（又は承継銀行の代わりにＩＰＳＰ）が作成した要求である。本発明の種々の実施形態によれば、決済要求処理１１００は、ステップ１１０２において、ＩＰＳＰシステム１０４が各取引先３１、３２、３３に対して決済要求を作成し、この決済要求をバッチファイルで承継銀行３６に送ることで開始する。種々の実施形態では、各決済要求には、特定の期間（例えば、２４時間、４８時間、又は１週間）にＩＰＳＰ３４によって処理された取引に関するデータが含まれる。決済要求には、本発明の種々の実施形態によれば、許可された及び許可されない取引又は許可されたばかりの取引が含まれる。次に、本発明の種々の実施形態によれば、ステップ１１０４において、ＩＰＳＰシステム１０４は、決済要求をＩＰＳＰシステム１０４上に保存する。これらの決済要求は、ＩＰＳＰシステム１０４のセキュリティ保護された部分から決済要求をダウンロードすることによってＡＳＰシステム１０５に転送するか、又はＩＰＳＰ３４は決済要求の物理的なコピー又は電子コピーをＡＳＰ３５に送る（例えば、イーメール、ファックス、ＣＤ、ＤＶＤ、又はフロッピー（登録商標）ディスクによって）ことができる。本発明の種々の実施形態による決済要求の内容は、図８に関連して前述されている。
【０１０３】
ステップ１１０６に示されているように、承継銀行３６は、バッチファイルを受け取り、そして決済要求を該当する発行銀行３７、３８、３９に送信する。さらに、承継銀行３６は、ステップ１１０８に示されているように、各発行銀行３７、３８、３９に対する各決済要求の中に含まれた資金の額を集計する（例えば、資金の額を集約する）、ＡＳＰ３５に対する支払い報告書を作成及び保存する。ＡＳＰ３５に対して承継銀行３６が作成した支払い報告書の１つの実施形態は、図８に関連して前述されている。
【０１０４】
次に、ステップ１１１０では、発行銀行３７、３８、３９は、要求された資金を承継銀行３６に振り込む。次に、ステップ１１１２において、承継銀行３６は、受け取った資金をＩＰＳＰ３４に振り込む。ＩＰＳＰ３４（又はＡＳＰ３５）が資金を該当する参加者とエスクロー勘定に配送する前に、ＡＳＰシステム１０５は、ＩＰＳＰシステム１０４が作成した決済要求と承継銀行３６が作成した支払い報告書を得て、ステップ１１１４で得た情報を一致させる。ステップ１１１４で行われた一致させる動作の結果は、本発明の種々の実施形態によれば、ＡＳＰ３５によって一致報告書（又は「通知書」）の中で要約される。最後に、ステップ１１１６において、ＡＳＰ３５は、各参加者に対する支払い金及びエスクロー勘定に振り込む金額をまとめて、参加者とエスクロー勘定に支払い金を振り込む。
【０１０５】
１つの実施形態によれば、ＡＳＰモジュール４００は、ステップ１１１４及び１１１６を実行するように構成される。このことは、図８に関連して前に説明されている。例えば、ＡＳＰモジュール４００は、各取引先３１、３２、３３に定期的（例えば、毎日又は毎週）に送られる一致報告書の中でＩＰＳＰと承継銀行によって提供されるデータを一致させることにより生じた結果を集約する。この一致報告書は、取引先３１、３２、３３が特定の日付までに取引先の銀行口座に受け入れることを期待できる金額を集約する。さらに、一致報告書は、顧客がそれぞれの取引先の口座に入金する総額を含み、また下記の難点及び利点を示す、すなわち、（１）（支払いチェーンの中で全ての参加者に対する支払いをカバーする）手数料や使用料が少ないこと、（２）入金取消し及び払い戻しに対するセキュリティとして、回転保存エスクロー勘定の中で一定の期間（例えば、６ヶ月又は１年）保留された総額の割合に対応する「トラスト・ディダクト（trust deduct）」が少ないこと、（３）その上、一定の期間また通知書の日付の１日前に保留された「委託金（trust money）」があること、（４）前の取引に関連した通知書の日付に承継銀行によって伝えられた入金取消しが少ないこと、である。資金を該当する参加者と回転保存エスクロー勘定に振り込む前に、ＩＰＳＰ３４は、支払いが行われたことを示す日付を含む一致報告書を調査する。一致報告書に対するＩＰＳＰ３４の承認を受け取ると、ＡＳＰ３５は、この一致報告書を様々な取引先３１、３２、３３に転送すると共に、支払い金を該当する参加者とエスクロー勘定に振り込む。１つの実施形態では、支払い金の振込は、一致報告書が作成されかつ承認された後で行われる。別の実施形態では、支払い金の振込は、一致報告書が承認される前に行われる。
【０１０６】
図１４に示した別の実施形態によれば、資金は承継銀行によって、各取引先に関連した各企業体の口座（例えば、ＳＧ１、ＳＧ２、ＳＧ３、など）に直接支払われる。さらに、ＡＳＰモジュール４００ａは、各口座に受け入れられた金額を、それぞれＩＰＳＰ及び承継銀行から得られた決済要求及び支払い報告書と一致するようにさらに構成される。１つの実施形態では、種々の参加者又はエスクロー勘定に対して口座から支払われていない金額は、取引先に支払われる。
【０１０７】
入金取消し処理のフロー
入金取消し要求は、特別な費用を顧客の支払いカードの口座に返金するために、顧客に代わって発行銀行が始動する要求である。例えば、発行銀行は、顧客が主張する、顧客の支払いカード上の費用が顧客によって許可されなかったことを争っている顧客に応じて入金取消し要求を始動する。図１１は、本発明の種々の実施形態による入金取消し要求を処理する代表的なフロー１２００を例示している。
【０１０８】
ステップ１２０２で開始すると、発行銀行３７、３８、３９は、顧客から入金取消しに関する要求を受け取る。次に、ステップ１２０４で、発行銀行３７、３８、３９は、入金取消し要求を承継銀行３６に送る。承継銀行３６は、入金取消し要求を受け取り、ステップ１２０６でそれをＩＰＳＰ３４に送る。次に、ステップ１２０８において、ＩＰＳＰ３４は、入金取消し要求を最初の取引によるデータと比較する。入金取消し要求の中のデータが最初の取引によるデータと一致すると思われる場合は、ＩＰＳＰ３４はこの要求をステップ１２１０においてＡＳＰ３５に送信する。この比較及び送信するステップ１２０８及び１２１０は、前述されたように、本発明の種々の実施形態によれば、ＩＰＳＰモジュール３００によって実行される。次に、次に、ステップ１２１２において、本発明の種々の実施形態によれば、ＡＳＰ３５は入金取消しの金額を取引先のエスクロー勘定から承継銀行３６に転送し、この承継銀行３６は次に、入金取消し要求を始動する発行銀行３７、３８、３９に入金取消し金額を転送する。別の実施形態では、ＡＳＰ３５は、決済要求の中で取引先３１、３２、３３に支払うべき合計金額から入金取消し金額を差し引くことによって、発行銀行３７、３８、３９にそれを支払う。次に、ステップ１２１４で、ＡＳＰ３５は入金取消し要求を保存する。本発明の種々の実施形態では、ＡＳＰモジュール４００は、ステップ１２１２と１２１４を実行するように構成される。
【０１０９】
ステップ１２０８において、入金取消し要求のデータが最初の取引によるデータと一致していない場合は、本発明の種々の実施形態によれば、この入金取消し要求にはフラグが立てられる。さらに、特定の支払いカードに関連したフラグが立てられた入金取消し要求の数が特定の期間内で一定の数を超える場合（例えば、１週間又は１ヶ月内で２つの入金取消し要求）、ＩＰＳＰは、将来取引先が支払いを承認してはならない支払いカードのリスト（例えば、ＩＰＳＰ３４によって維持される不正及び悪用データベース）上に特定の支払いカード番号を含む。
【０１１０】
上記に加えて、種々の実施形態によれば、ＡＳＰ３５は、特定の期間（例えば、毎日又は毎週）内に承継銀行３６とＩＰＳＰ３４によって処理された入金取消し要求を、最初の取引からの取引データに一致させる。これらの要求を一致させるために、ＡＳＰ３５は、ステップ１２１６に示されているように、承継銀行３６が作成した入金取消し取引報告書とＩＰＳＰ３４が作成した入金取消し取引報告書とを得て、２つの報告書を最初の取引からのデータと比較する。１つの実施形態では、比較するステップ１２１６は、入金取消し報告書のデータをＡＳＰシステム１０５のメモリに記憶されている最初の取引からのデータとリンクすることによって実行される。１つの実施形態によれば、入金取消しデータ報告書は、次に続く情報の少なくとも一部を含んでおり、この情報は、（１）チャージ・バック（charged back）される最初の情報に対する参考資料、（２）ＭＩＤ番号、（３）入金取消し要求が作られた日付、（４）取引の「入金取消し」としての説明、（５）全部のカード番号、（６）承継銀行によって与えられた照合番号、（７）なぜ入金取消しがカード所有者によって開始されたかを示すカード発行会社が発行したコード番号、（８）なぜ入金取消しが開始されたかに関する説明、（９）入金取消し金額に対する通貨の種類、（１０）入金取消し金額、（１１）承継銀行から与えられたカード番号又はその一部（例えば、カード番号の最初の４桁）、（１２）最初の取引が「公表された」すなわち許可された日付、（１３）最初の取引が発生した日付、（１４）最初の取引の「種類」、（１５）最初の取引の通貨、（１６）最初の取引の金額、（１７）取引が決済された通貨、（１８）決済された金額、（１９）承継銀行によって提供された最初の「デフォルト」の通貨、（２０）承継銀行によって提供された最初の「デフォルト通貨」の金額、（２１）承継銀行が特定の日付の取引に関するそのデータをＩＰＳＰに開放したときの取引の一部の「バッチ」に対する参考資料である「最初のスリップ（original slip）」、（２２）承継銀行の「品目スリップ」、（２３）最初の取引の許可コード、（２４）承継銀行の「バッチ番号」、そして（２５）顧客の支払いカードの明細書に現れるときの取引先の名前である「取引先のＤＢＡ名」、である。図８に関連して前に説明したように、ＡＳＰモジュール４００は、本発明の種々の実施形態によれば、この一致ステップ１２１６を実行するように構成される。
【０１１１】
本発明の種々の実施形態によれば、報告書はＩＰＳＰシステム１０４及び承継銀行のシステム１０６にメールで送られる、またＡＳＰシステム１０５によってダウンロードされる、又は報告書は、例えばイーメール、ファックス、ＣＤ、ＤＶＤ、又はフロッピー（登録商標）ディスクを介して、物理的又は電子的に送られる。
【０１１２】
支払い処理のフロー
幾つかの電子商取引部門（例えば、ギャンブル）では、金を顧客に払い戻す必要がある。金を顧客に払うことは、特にインターネットのギャンブルに対して、マネーローンダリングを悪用する危険性に関する懸念が持ち上がる。本発明の種々の実施形態によれば、システム１００は、取引先に対して最初の支払いを行うために顧客が使用した支払いカードの口座に独占的に支払いを行うことにより、顧客と取引先との間に完全に透明な「閉ループ」を作り出すことによって、電子商取引に関連した幾つかの危険性に対処している。このため、１つの実施形態によれば、資金は同じ口座から発生しまた同じ口座に戻るため、全ての金の流れは追跡可能になる、これにより、電子商取引はマネーローンダリング計画には魅力的でなくなる。
【０１１３】
例えば、図１２は、顧客が支払い要求を提出したときに、顧客に対して支払いを処理しかつ支払いを送金する代表的なフロー１３００を例示している。ステップ１３０２で開始すると、取引先は支払いに関して顧客からの要求を受け取り、その要求をＩＰＳＰに転送する。次に、ステップ１３０４では、ＩＰＳＰは、顧客が政府又は地方自治体の許可リスト（例えば、米国が発行した「特別指定国家リスト」）に含まれていないことを検証する。さらに、１つの実施形態によれば、ＩＰＳＰは、顧客の国籍（例えば、顧客の請求書送付先又は顧客のコンピュータ装置のＩＰアドレスに基づく）が取引先が事業を行っている可能性がある禁止された国のリストに載っていないことを検証する。種々の実施形態によれば、顧客（又は顧客の国）がそのリストに載っている場合、システム１００は支払い要求を許可することはできないため、この要求は拒絶される。顧客が許可リストに含まれていない場合（又は、禁止された国と関連がない場合）、ＩＰＳＰ３４は支払い要求を取引先の銀行に送る。このことは、ステップ１３０６として示されている。要求を受け取り、そして支払い資金が取引先の口座にあることを受けて、取引先の銀行はこの資金をＩＰＳＰ３４に送金する。このことは、ステップ１３０８として示されている。ＩＰＳＰ３４が資金を受け取りそれらの記録をＩＰＳＰシステム１０４の中に保存した後で、ＩＰＳＰ３４は、ステップ１３１０に示されているように、その資金を承継銀行３６に振り込む。次に、ステップ１３１２では、承継銀行３６は資金を受け取ると、取引先のウェブ上で購入する（例えば、賭け金を入れる）ために使用された顧客の支払いカードに関連した発行銀行３７、３８、３９に、この資金を送金する。種々の実施形態によれば、ステップ１３１４では、発行銀行３７、３８、３９は、次に、取引先３１、３２、３３から受け取った金額を支払いカードに関連した口座に振り込むか、又はカード所有者としてリストされている顧客に小切手を送る。
【０１１４】
電子財布
本発明のさらに別の実施形態では（図示せず）、金融取引システム１００は、顧客がＩＰＳＰ３４から電子トークンを購入できるように構成される。この電子トークンはこの場合、合意した金額だけ参加している取引先３１、３２、３３に使用することができ、プリペイド形の「電子財布」口座が作られる。種々の実施形態によれば、金融取引システム１００の機能は、電子財布システムまで拡張できる。例えば、顧客からの要求を受け取り、資金を顧客の支払いカードに関連した口座から取引先の口座に振り込む取引先３１、３２、３３の代わりに、ＩＰＳＰ３４が要求を受け取って、資金を顧客の電子財布からＩＰＳＰの口座に振り込む。１つの実施形態によれば、ＩＰＳＰ３４は取引先用モジュール２００及びＩＰＳＰモジュール３００のステップを実行して、許可要求と発行銀行に対する決済要求を作成及び処理する。決済が行われると、ＩＰＳＰ３４は顧客の電子財布の口座に、振り込まれた資金の額を表す電子トークンの金額を振り込む。顧客はトークンを、購入するために参加している取引先３１、３２、３３に対して使用することができる。定期的に（例えば、毎日又は毎週）、ＩＰＳＰ３４は、各取引先のウェブサイトで使われたトークンの金額を表す資金を各取引先３１、３２、３３に振り込む。１つの実施形態では、ＡＳＰ３５は、電子財布の口座を管理して、ＩＰＳＰ３４からの支払いを関係する取引先３１、３２、３３に割り当てる。
【０１１５】
本発明の多くの変形例及び他の実施形態は、前述した説明及び関連した図面の中で示した教義の利点を有する本発明が属する技術分野に精通した者には思い浮かぶであろう。このため、本発明は開示された特定の実施形態に限定されるものではなく、また変形例及び他の実施形態は添付した特許請求の範囲の中に含まれるものとすることは理解されよう。本願の中で特別な用語が使用されるが、それらの用語は一般的であり説明のためのみに使用されるものであり、本発明の範囲を限定する目的で使用されるものではない。
【特許請求の範囲】
【請求項１】
プロセッサとメモリとを備える疑わしい不正行為を監視するシステムであって、
前記プロセッサが、
資金を送金するための顧客からの１つ以上の要求のそれぞれに関連した情報と、前記要求を受信した日付とを前記メモリに記憶するステップと、
資金を送金するために新しい要求を受信するステップと、
前記新しい要求の受信に応じて、特定期間において前記メモリに記憶された取引の頻度を検索するステップと、
顧客の以前の取引先との取引に基づいた所定の範囲を前記メモリから検索するステップと、
前記取引の頻度と前記所定の範囲とを比較するステップと、
前記取引の頻度が前記所定の範囲よりも少ない又は多い場合、１人以上の顧客、前記顧客に関連した支払いソース、又は取引先に疑わしい不正行為が検出されたことを通知するステップと、
を含むシステム。
【請求項１】
プロセッサとメモリとを備える疑わしい不正行為を監視するシステムであって、
前記プロセッサが、
資金を送金するための顧客からの１つ以上の要求のそれぞれに関連した情報と、前記要求を受信した日付とを前記メモリに記憶するステップと、
資金を送金するために新しい要求を受信するステップと、
前記新しい要求の受信に応じて、特定期間において前記メモリに記憶された取引の頻度を検索するステップと、
顧客の以前の取引先との取引に基づいた所定の範囲を前記メモリから検索するステップと、
前記取引の頻度と前記所定の範囲とを比較するステップと、
前記取引の頻度が前記所定の範囲よりも少ない又は多い場合、１人以上の顧客、前記顧客に関連した支払いソース、又は取引先に疑わしい不正行為が検出されたことを通知するステップと、
を含むシステム。
【図１】
【図２】
【図３Ａ】
【図３Ｂ】
【図４】
【図５】
【図６】
【図７Ａ】
【図７Ｂ】
【図８】
【図９Ａ】
【図９Ｂ】
【図１０Ａ】
【図１０Ｂ】
【図１１】
【図１２】
【図１３】
【図１４】
【図１５】
【図１６】
【図１７】
【図１８】
【図２】
【図３Ａ】
【図３Ｂ】
【図４】
【図５】
【図６】
【図７Ａ】
【図７Ｂ】
【図８】
【図９Ａ】
【図９Ｂ】
【図１０Ａ】
【図１０Ｂ】
【図１１】
【図１２】
【図１３】
【図１４】
【図１５】
【図１６】
【図１７】
【図１８】
【公開番号】特開２０１２−１６８９７１（Ｐ２０１２−１６８９７１Ａ）
【公開日】平成２４年９月６日（２０１２．９．６）
【国際特許分類】
【出願番号】特願２０１２−９４０９６（Ｐ２０１２−９４０９６）
【出願日】平成２４年４月１７日（２０１２．４．１７）
【分割の表示】特願２００９−５０７１５４（Ｐ２００９−５０７１５４）の分割
【原出願日】平成１９年４月２５日（２００７．４．２５）
【出願人】（５０８３２０６１９）ユーシー・グループ・リミテッド (3)
【Ｆターム（参考）】
【公開日】平成２４年９月６日（２０１２．９．６）
【国際特許分類】
【出願日】平成２４年４月１７日（２０１２．４．１７）
【分割の表示】特願２００９−５０７１５４（Ｐ２００９−５０７１５４）の分割
【原出願日】平成１９年４月２５日（２００７．４．２５）
【出願人】（５０８３２０６１９）ユーシー・グループ・リミテッド (3)
【Ｆターム（参考）】
[ Back to top ]