(57)【特許請求の範囲】
【請求項１】
あるオンライン販売業者について顧客から受信した不正の可能性があるオンライン取引を識別する不正行為防止システムであって、
２以上の不正行為フィルタを用いて、顧客から受信したオンライン取引を評価するように構成される不正行為防止モジュールを実行するように構成されたプロセッサを備え、前記２以上の不正行為フィルタは、
（１）顧客のインターネットプロトコルアドレスにより識別される顧客の所在位置が不正行為頻発位置であるか否かを判定すること、
（２）顧客のインターネットプロトコルアドレスにより識別される顧客の所在位置について認められているクレジットカードの数、購入の規模、購入回数に対して制限があるか否かを判定すること、
（３）当該オンライン取引に使用されるクレジットカードを発行した銀行の位置により識別される地域と、顧客のインターネットプロトコルアドレスにより識別される顧客の位置との不一致を判定すること、
（４）顧客のインターネットプロトコルアドレスにより識別される地域と、顧客が提供する地域との不一致を判定すること、
（５）顧客の電話が登録されている場所として識別される地域と、顧客のインターネットプロトコルアドレスにより識別される顧客の位置との不一致を判定すること、
（６）顧客の演算装置に発行されるインターネットプロトコルアドレスが公知のゲートウェイ装置のインターネットプロトコルアドレスの一つ以上のリストのうちの一つにあるか否かを判断するために、前記顧客の演算装置に発行されるインターネットプロトコルアドレスと公知のゲートウェイ装置のインターネットプロトコルアドレスの一つ以上のリストとを比較して、演算装置に対して発行されるインターネットプロトコルアドレスが、公知のゲートウェイ装置のインターネットプロトコルアドレスの前記１つ以上のリストのうちの１つにあるか否かを判断し、前記顧客の演算装置に発行されるインターネットプロト
コルアドレスが、前記公知のゲートウェイ装置のインターネットプロトコルアドレスの前記一つ以上のリストにあると判断したことに応じて、ゲートウェイ装置に関連するエンティティ（組織）に対して、前記インターネットプロトコルアドレスと、当該取引が行われているウェブサイトと、時刻又は日付のうちの少なくとも一方を与えて、前記エンティティが、前記インターネットプロトコルアドレスと、前記ウェブサイトと、時刻又は日付のうちの少なくとも一方を用いて第２の位置を識別できるようにし、前記顧客の演算装置に関連する第２の位置を識別する情報を、ゲートウェイ装置に関連するエンティティから受
信し、前記情報が前記演算装置に関連する位置を識別しないことに応じて、当該要求を不適切である可能性がある要求として指定すること
のうちの２以上から選択され、
前記プロセッサは、前記不正行為フィルタのうちの１つ以上が適用されることに応じて、当該取引を不正の可能性がある取引として指定するように構成され、
前記プロセッサは、前記不正行為フィルタ（１）〜（６）のすべてが当該オンライン取引に適用されることに応じて、不正行為防止モジュールを実行して、当該取引を不正の可能性がある取引として指定するように構成されることを特徴とするシステム。
【請求項２】
前記プロセッサは、当該取引が不正の可能性がある取引として指定されたことに応じて、不正行為防止モジュールを実行して、当該取引に関連する情報を不正行為データベースに記憶するように構成されることを特徴とする請求項１に記載のシステム。
【請求項３】
前記２以上の不正行為フィルタは、販売業者の位置に基づいて選択されることを特徴とする請求項１に記載のシステム。
【請求項４】
前記２以上の不正行為フィルタは、顧客の位置に基づいて選択されることを特徴とする請求項１に記載のシステム。
【請求項５】
前記２以上の不正行為フィルタは、銀行の位置に基づいて選択されることを特徴とする請求項１に記載のシステム。
【請求項６】
あるオンライン販売業者について顧客から受信した不正の可能性があるオンライン取引を識別する、コンピュータによって実行される不正行為防止方法であって、
オンライン販売業者のための顧客から受信した一つ以上のオンライン取引に関するオンライン取引データを一つ以上のメモリストレージエリア内に受信及び格納するステップと、
２以上の不正行為フィルタを用いて、顧客から受信したオンライン取引データを一つ以上のコンピュータプロセッサを介して評価するステップであり、前記２以上の不正行為フィルタは、
（１）顧客のインターネットプロトコルアドレスにより識別される顧客の所在位置が不正行為頻発位置であるか否かを前記一つ以上のコンピュータプロセッサを介して判定すること、
（２）顧客のインターネットプロトコルアドレスにより識別される顧客の所在位置について認められているクレジットカードの数、購入の規模、購入回数に対して制限があるか否かを前記一つ以上のコンピュータプロセッサを介して判定すること、
（３）当該オンライン取引に使用されるクレジットカードを発行した銀行の位置により識別される地域と、顧客のインターネットプロトコルアドレスにより識別される顧客の位置との不一致を前記一つ以上のコンピュータプロセッサを介して判定すること、
（４）顧客のインターネットプロトコルアドレスにより識別される地域と、顧客が提供する地域との不一致を前記一つ以上のコンピュータプロセッサを介して判定すること、
（５）顧客の電話が登録されている場所として識別される地域と、顧客のインターネットプロトコルアドレスにより識別される顧客の位置との不一致を前記一つ以上のコンピュータプログラムを介して判定すること、
（６）顧客の演算装置に発行されるインターネットプロトコルアドレスが公知のゲートウェイ装置のインターネットプロトコルアドレスの一つ以上のリストのうちの一つにあるか否かを判断するために、前記一つ以上のコンピュータプロセッサを介して、前記顧客の演算装置に発行されるインターネットプロトコルアドレスと公知のゲートウェイ装置のインターネットプロトコルアドレスの一つ以上のリストとを比較し、前記顧客の演算装置に発行されるインターネットプロトコルアドレスが、前記公知のゲートウェイ装置のインターネットプロトコルアドレスの前記一つ以上のリストにあると判断したことに応じて、ゲートウェイ装置に関連するエンティティ（組織）に対して、前記インターネットプロトコルアドレスと、当該取引が行われているウェブサイトと、時刻又は日付のうちの少なくとも一方を与えて、前記エンティティが、前記インターネットプロトコルアドレスと、前記ウェブサイトと、時刻又は日付のうちの少なくとも一方を用いて第２の位置を識別できるようにし、前記顧客の演算装置に関連する第２の位置を識別する情報を、ゲートウェイ装置に関連するエンティティから受信し、前記情報が前記演算装置に関連する位置を識別しないことに応じて、当該要求を不適切である可能性がある要求として指定することのうちの２以上から選択され、
前記不正行為フィルタのうちの１つ以上が適用されることに応じて、当該取引を不正の可能性がある取引として前記一つ以上のコンピュータプロセッサを介して指定し、
前記不正行為フィルタ（１）〜（６）のすべてが当該オンライン取引に適用されることに応じて、前記一つ以上のコンピュータプロセッサを介して当該取引を不正の可能性がある取引として指定することを特徴とする方法。
【請求項７】
さらに、当該取引が不正の可能性がある取引として指定されたことに応じて、当該取引に関連する情報を不正行為データベースに記憶するために前記一つ以上のコンピュータプロセッサが構成されることを特徴とする請求項６に記載の方法。
【請求項８】
前記１以上の不正行為フィルタは、販売業者の位置に基づいて選択されることを特徴とする請求項６に記載の方法。
【請求項９】
前記１以上の不正行為フィルタは、顧客の位置に基づいて選択されることを特徴とする請求項６に記載の方法。
【請求項１０】
前記１以上の不正行為フィルタは、銀行の位置に基づいて選択されることを特徴とする請求項６に記載の方法。
【請求項１１】
あるオンライン販売業者について顧客から受信した不適切である可能性があるオンライン取引を識別する不正行為防止システムであって、
顧客とオンライン販売業者との間でオンライン取引を行うための要求を受信し、
顧客がオンライン取引を行うのに使用する演算装置に対して発行されるインターネットプロトコルアドレスを自動検知し、
インターネットプロトコルアドレスの検知に応じて、
公知のゲートウェイ装置のインターネットプロトコルアドレスのリストを１つ以上記憶する１以上のデータベースを検索し、
演算装置に対して発行されるインターネットプロトコルアドレスと、公知のゲートウェイ装置のインターネットプロトコルアドレスの前記１以上のリストを比較して、演算装置に対して発行されるインターネットプロトコルアドレスが、公知のゲートウェイ装置のインターネットプロトコルアドレスの前記１つ以上のリストのうちの１つにあるか否かを判断し、
演算装置に対して発行されるインターネットプロトコルアドレスが、公知のゲートウェイ装置のインターネットプロトコルアドレスの前記１つ以上のリストのうちの１つにあると判断したことに応じて、
ゲートウェイ装置に関連するエンティティ（組織）に対して、前記インターネットプロトコルアドレスと、当該取引が行われているウェブサイトと、時刻又は日付のうちの少なくとも一方を与えて、前記エンティティが、前記インターネットプロトコルアドレスと、前記ウェブサイトと、時刻又は日付のうちの少なくとも一方を用いて第２の位置を識別できるようにし、
顧客の演算装置に関連する第２の位置を識別する情報を、ゲートウェイ装置に関連するエンティティから受信し、
前記情報が前記演算装置に関連する位置を識別しないことに応じて、当該要求を不適切である可能性がある要求として指定し、
当該要求が不適切である可能性がある要求として指定されたことに応じて、当該オンライン取引に関連する情報を不適切取引データベースに記憶するように構成される
不正行為防止モジュールを実行するように構成されるプロセッサを備えることを特徴とするシステム。
【請求項１２】
前記プロセッサは、当該要求が不適切である可能性がある要求として指定されたことに応じて、不正行為防止モジュールを実行して、顧客とオンライン販売業者との間で行われることを否認するように構成されることを特徴とする請求項１１に記載のシステム。
【請求項１３】
あるオンライン販売業者について顧客から受信した不適切である可能性があるオンライン取引を識別する、コンピュータによって実行される不正行為防止方法であって、
顧客とオンライン販売業者との間でオンライン取引を行うための要求を一つ以上のメモリストレージエリア内に受信するステップと、
顧客がオンライン取引を行うのに使用する演算装置に対して発行されるインターネットプロトコルアドレスを一つ以上のコンピュータプロセッサを介して検知するステップと、
インターネットプロトコルアドレスの検知に応じて、
公知のゲートウェイ装置のインターネットプロトコルアドレスのリストを１つ以上記憶する１以上のデータベースを前記一つ以上のコンピュータプロセッサを介して検索するステップと、
演算装置に対して発行されるインターネットプロトコルアドレスが、公知のゲートウェイ装置のインターネットプロトコルアドレスの前記１つ以上のリストのうちの１つにあるか否かを判断するため、演算装置に対して発行されるインターネットプロトコルアドレスと、公知のゲートウェイ装置のインターネットプロトコルアドレスの前記１以上のリストを前記一つ以上のコンピュータプロセッサを介して比較するステップと、
演算装置に対して発行されるインターネットプロトコルアドレスが、公知のゲートウェイ装置のインターネットプロトコルアドレスの前記１つ以上のリストのうちの１つにあると判断したことに応じて、
ゲートウェイ装置に関連するエンティティ（組織）に対して、前記インターネットプロトコルアドレスと、当該取引が行われているウェブサイトと、時刻又は日付のうちの少なくとも一方を前記一つ以上のコンピュータプロセッサを介して与えるステップであり、前記エンティティが、前記インターネットプロトコルアドレスと、前記ウェブサイトと、時刻又は日付のうちの少なくとも一方を用いて第２の位置を識別できるようにし、
ユーザの演算装置に関連する第２の位置を識別する情報を、ゲートウェイ装置に関連するエンティティから前記一つ以上のコンピュータプロセッサを介して受信するステップと、
前記情報が前記演算装置に関連する位置を識別しないことに応じて、当該要求を不適切である可能性がある要求として指定するステップと、
当該要求が不適切である可能性がある要求として指定されたことに応じて、当該オンライン取引に関連する情報を不適切取引データベースに記憶するステップとを備えることを特徴とする方法。
【発明の詳細な説明】
【背景技術】
【０００１】
一般に、顧客が（インターネット上又は他の手段による）販売業者に対して支払いカード（例えば、クレジットカードやデビットカード）を使用したい場合、販売業者は提携銀行に電子許可要求を送る。提携銀行は、カード発行会社のネットワーク（例えば、ＶＩＳＡ、マスターカード、アメリカン・エキスプレス、又は、プライベート・カード発行会社のネットワーク）を介して、カード発行銀行（すなわち、顧客に支払いカードを発行した銀行や金融機関）に電子許可要求を渡す。カード発行銀行は、顧客が利用可能な預金を十分持っており、支払いの滞納がないこと、また、提供されたすべての情報（例えば、カード番号、カード検証値（ＣＶＶ）番号、）カード所有者の詳細）が正しいことを確認する。そして、カード発行銀行は、カード発行会社のネットワークを介して、支払いを許可する電子メッセージを提携銀行に送り、提携銀行はその電子メッセージを販売業者に送る。販売業者は、この後カード発行銀行が行う支払いの証拠として、この許可メッセージを受け取る。実際の資金移動は決済処理と呼ばれる後段で行われる。
【０００２】
インターネットや他のネットワークで行われる支払いカードによる取引は、通常、カード取引を行う際にカード所有者と販売業者が同じ場所にいないため、対面式の支払い取引では必ずしも発生しないような危険がある。また、ギャンブルや成人向け娯楽等、幾つかの電子商取引部門については、公益に対する懸念が新たに生じるので、支払いカードによる取引を安全なものにして、不正行為や他の悪用を防止するためのシステムの必要性がさらに注目されている。
【発明の概要】
【０００３】
本発明の種々の実施形態は、（１）支払い取引をより安全に処理し、（２）不正取引、マネーロンダリング、未成年のギャンブルから販売業者と銀行を保護するのに役立ち、（３）インターネット上のゲーム、旅行、消費者による電子商品購入等、特別なリスクを生じると考えられる電子商取引分野での他の悪用を制限するのに役立ち、（４）このような取引に関するプロセスや情報を統合して、データ記憶容量の低減、及び／又は、コンピュータ処理容量の低減を実現するのに役立つ、電子商取引部門のためのより安全な金融取引システムを提供する。上述の目的を達成するために、金融取引システムの種々の実施形態では、（１）販売業者、インターネット支払いサービスプロバイダ、提携銀行、カードスキームのための、業務及び取引処理プロトコルを設けるとともに、（２）支払い及び金融取引を監視し、安全に処理するための自動システムを提供する。本明細書に記載される種々の実施形態のうち２つ以上を組み合わせて、これらの目的の１つ以上を達成するシステム又は方法を提供してもよい。
【０００４】
本発明の種々の実施形態によれば、オンライン販売業者との取引を処理するシステムが提供される。このシステムは、通信インターフェースと、サービスプロバイダモジュールを実行するプロセッサとを備える。サービスプロバイダモジュールは、（１）ウェブサイトにて顧客とオンライン販売業者との間で取引を行うための要求であって、（ａ）顧客の住所に関連する第１の位置と、（ｂ）顧客に関連する演算装置に対して発行されるインターネットプロトコルアドレスとを含む要求を、ネットワーク上にある前記通信インターフェースを介して受信し、（２）この要求の受信に応じて、ネットワークを介して、既知のゲートウェイ装置のインターネットプロトコルアドレスを記憶する１以上のデータベースを検索し、当該インターネットプロトコルアドレスがいずれかのゲートウェイ装置に属しているか否かを判定し、（３）当該インターネットプロトコルアドレスがゲートウェイ装置に関連していないことに応じて、当該インターネットプロトコルアドレスに対応するとともに演算装置に関連する第２の位置を識別する情報を得るために、ネットワークを介して１以上のＩＰ地理的位置データベースを検索し、（４）当該インターネットプロトコルアドレスがゲートウェイ装置に関連していることに応じて、当該インターネットプロトコルアドレス、取引が行われているウェブサイト、取引の日時をゲートウェイ装置に与えることにより、演算装置に関連した第２の位置を識別する情報をゲートウェイ装置に要求し、（５）第２の位置を識別するための情報を受信したことに応じて、第１の位置と第２の位置を、メモリに記憶されたオンライン販売業者との取引を規制する位置リストと比較し、（６）第１の位置又は第２の位置が位置リストにある位置と一致することに応じて、１以上の規制当局が、第１の位置又は第２の位置にてオンライン販売業者との間で行われる取引を規制するか否かを判断し、（７）１以上の規制当局が第１の位置又は第２の位置における取引を規制すると判断したことに応じて、ネットワークを介して、顧客の演算装置のうちの１以上、又は、販売業者の１以上の演算装置に対して、当該取引が受ける規制の種類を通知するように構成される。一実施形態において、支払いサービスプロバイダモジュールは、さらに、１以上の規制当局が第１の位置又は第２の位置においてオンライン販売業者との間で行われる取引を規制すると判断したことに応じて、オンライン販売業者との間で当該取引が行われるのを防止するように構成される。
【０００５】
また、特定の実施形態において、規制の種類として、当該取引の禁止、当該取引の制限、又は、当該取引に対する課税がある。さらに、特定の実施形態において、ゲートウェイ装置は、インターネットサービスプロバイダのサーバ又はルータ、あるいは、携帯電話プロバイダのサーバ又はルータである。種々の実施形態において、当該取引は、オンライン販売業者に対して賭けを行う要求、オンライン販売業者に資金を移動する要求、又は、オンライン販売業者に対して行った１回以上の賭けの賞金払い戻しの要求である。さらに、種々の実施形態において、既知のゲートウェイ装置のインターネットプロトコルアドレスを記憶する前記１以上のデータベースには、インターネットサービスプロバイダのサーバ及びルータ、及び、携帯電話プロバイダのサーバ及びルータのアドレスが含まれる。
【０００６】
本発明の種々の実施形態によれば、ネットワークを介して第三者のウェブサイトにて第三者と取引を行うユーザの演算装置の位置に基づいて情報を提供するシステムが提供される。このシステムは、通信インターフェースと、妥当性確認モジュールを実行するプロセッサとを備える。妥当性確認モジュールは、（１）当該第三者のウェブサイト上の取引の承認要求であって、（ａ）ユーザの物理アドレスに関連する第１の位置と、（ｂ）演算装置に対して発行されるインターネットプロトコルアドレス、当該取引が行われているウェブサイト、当該取引の日時とを含む要求を、ネットワーク上にある前記通信インターフェースを介して受信し、（２）ネットワークを介して、既知のゲートウェイ装置のインターネットプロトコルアドレスを記憶する１以上のデータベースを検索して、当該インターネットプロトコルアドレスがいずれかのゲートウェイ装置に属しているか否かを判定し、（３）当該インターネットプロトコルアドレスがゲートウェイ装置に関連していないことに応じて、当該インターネットプロトコルアドレスに対応するとともに演算装置に関連する第２の位置を識別する情報を得るために、ネットワークを介して、１以上のＩＰ地理的位置データベースを検索し、（４）当該インターネットプロトコルアドレスがゲートウェイ装置に関連していることに応じて、当該インターネットプロトコルアドレス、取引が行われているウェブサイト、取引の日時をゲートウェイ装置に与えることにより、ユーザの演算装置に関連した第２の位置を識別する情報をゲートウェイ装置に要求し、（５）ネットワークを介して、顧客の演算装置のうちの１以上、又は、第三者の１以上の演算装置に対して、第２の位置を識別する情報を提供するように構成される。特定の実施形態において、プロセッサは、妥当性確認モジュールを実行して、インターネットプロトコルアドレスがゲートウェイ装置に関連していることに応じて当該取引を阻止する旨の通知を行うように構成される。
【０００７】
本発明の種々の実施形態によれば、あるオンライン販売業者について顧客から受信した不正の可能性があるオンライン取引を識別する不正行為防止システムが提供される。このシステムは、１以上の不正行為フィルタを用いて、顧客から受信したオンライン取引を評価するように構成される不正行為防止モジュールを実行するように構成されたプロセッサを備える。これら特定の実施形態において、前記１以上の不正行為フィルタは以下のうちの１以上から選択される。すなわち、（１）顧客の所在位置が不正行為頻発位置であるか否かを判定すること、（２）顧客の所在位置について認められているクレジットカードの数、購入の規模、購入回数に対して制限があるか否かを判定すること、（３）当該オンライン取引に使用されるクレジットカードを発行した銀行の位置により識別される地域と、顧客が提供した顧客の位置との不一致を判定すること、（４）当該オンライン取引に使用されるクレジットカードを発行した銀行の位置により識別される地域と、顧客のインターネットプロトコルアドレスにより得られる顧客の位置との不一致を判定すること、（５）顧客のインターネットプロトコルアドレスにより識別される地域と、顧客が提供する地域との不一致を判定すること、（６）顧客の電話が登録されている場所として識別される地域と、顧客の位置又は当該オンライン取引に使用されるクレジットカードを発行した銀行の位置との不一致を判定すること、（７）販売業者への登録の際に顧客が使用した情報のいずれかが、他の口座で他の時期に使用されたことがあるか否かを判定すること、あるいは、（８）そのクレジットカードが使用されたことがある複数の口座を判定すること、から選択される。さらに、プロセッサは、不正行為フィルタのうちの１つ以上が適用されることに応じて、不正行為防止モジュールを実行して、当該取引を不正の可能性がある取引として指定するように構成される。
【０００８】
特定の実施形態において、プロセッサは、不正行為フィルタのすべてが当該オンライン取引に適用されることに応じて、不正行為防止モジュールを実行して、当該取引を不正の可能性がある取引として指定するように構成される。また、特定の実施形態において、プロセッサは、当該取引が不正の可能性がある取引として指定されたことに応じて、不正行為防止モジュールを実行して、当該取引に関連する情報を不正行為データベースに記憶する。さらに、特定の実施形態において、前記１以上の不正行為フィルタは、販売業者の位置、顧客の位置、又は、銀行の位置に基づいて選択される。
【０００９】
本発明の種々の実施形態は、あるオンライン販売業者について顧客から受信した不適切である可能性があるオンライン取引を識別する不正行為防止システムを提供する。これら特定の実施形態において、このシステムは、（１）顧客とオンライン販売業者との間でオンライン取引を行うための要求を受信し、（２）顧客がオンライン取引を行うのに使用する演算装置に対して発行されるインターネットプロトコルアドレスを自動検知し、（３）インターネットプロトコルアドレスの検知に応じて、（ａ）公知のゲートウェイ装置のインターネットプロトコルアドレスのリストを１つ以上記憶する１以上のデータベースを検索し、（ｂ）ゲートウェイ装置に対して発行されるインターネットプロトコルアドレスと、公知のゲートウェイ装置のインターネットプロトコルアドレスの前記１以上のリストを比較して、演算装置に対して発行されるインターネットプロトコルアドレスが、公知のゲートウェイ装置のインターネットプロトコルアドレスの前記１つ以上のリストのうちの１つにあるか否かを判断し、（４）演算装置に対して発行されるインターネットプロトコルアドレスが、公知のゲートウェイ装置のインターネットプロトコルアドレスの前記１つ以上のリストのうちの１つにあると判断したことに応じて、当該要求を不適切である可能性がある要求として指定し、（５）当該要求が不適切である可能性がある要求として指定されたことに応じて、当該オンライン取引に関連する情報を不適切取引データベースに記憶するように構成される不正行為防止モジュールを実行するように構成されたプロセッサを備える。種々の実施形態において、プロセッサは、当該要求が不適切である可能性がある要求として指定されたことに応じて、不正行為防止モジュールを実行して、顧客とオンライン販売業者との間で行われることを否認するように構成される。
【００１０】
さらに、本発明の種々の実施形態は、顧客の強迫的ギャンブル行動を監視するシステムを提供する。このシステムは、顧客がオンライン販売業者と販売業者のウェブサイトにて取引を行うのに使用する演算装置から、ネットワークを介して要求を受信したことに応じて、以下のうちの１以上から選択される１以上の基準を用いて、当該要求を評価するように構成されるＩＰＳＰモジュールを実行するように構成されたプロセッサを備える。すなわち、（１）顧客が、販売業者と１以上の金融取引を行うために販売業者に対して入金する頻度を評価すること、（２）顧客の１回以上の入金の入金規模の不一致を判定すること、（３）販売業者との１以上の取引を行う要求を顧客から受信する頻度を評価すること、（４）一日のうちのどの時間に顧客から当該要求を受信するかを評価すること、（５）顧客から受信する要求の数が変化又は急増しているか否かを判定すること、又は、（６）顧客が冷却期間を要求したことがある、又は、取引の実行を禁止してもらうように要求したことがあることを、顧客に関する情報が示しているか否かを判定すること、から選択される。さらに、これら種々の実施形態において、ＩＰＳＰモジュールは、基準のうちの１つ以上が適用されることに応じて、顧客の演算装置のうちの１つ以上、顧客に対応する支払いソースに関連する１以上の演算装置、又は、オンライン販売業者に関連する１以上の演算装置に対して通知を行うように構成される。特定の実施形態において、プロセッサはさらに、基準のうちの１つ以上が適用されることに応じて、ＩＰＳＰモジュールを実行して、当該要求が処理されないようにする構成を有する。
【００１１】
特定の実施形態において、プロセッサは、不正行為フィルタのすべてが当該オンライン取引に適用されることに応じて、ＩＰＳＰモジュールを実行して、顧客の演算装置のうちの１つ以上、顧客に対応する支払いソースに関連する１以上の演算装置、又は、オンライン販売業者に関連する１以上の演算装置に対して通知を行うように構成される。また、特定の実施形態において、当該取引は、顧客に関連する口座から販売業者への資金移動、又は、販売業者に以前移動した資金を用いて賭けを行うことが含まれる。
【００１２】
さらに、特定の実施形態において、販売業者に対して顧客の入金が行われる頻度について閾値を設定し、プロセッサはさらに、ＩＰＳＰモジュールを実行して、（１）顧客の入金を受けたことに応じて、顧客の入金が行われる頻度と閾値を比較し、（２）当該頻度が閾値を超えたことに応じて、顧客の演算装置のうちの１つ以上、顧客に対応する支払いソースに関連する１以上の演算装置、又は、オンライン販売業者に関連する１以上の演算装置に対して通知を行うように構成される。一実施形態において、プロセッサはさらに、当該頻度が閾値を超えたことに応じて、ＩＰＳＰモジュールを実行して、当該要求を処理しないようにする構成を有する。
【００１３】
さらに、特定の実施形態において、販売業者に対して顧客の入金が行われる規模について閾値を設定し、プロセッサはさらに、ＩＰＳＰモジュールを実行して、（１）顧客の入金を受けたことに応じて、販売業者に対して行われた顧客の入金の規模と閾値を比較し、（２）当該規模が閾値を超えたことに応じて、顧客の演算装置のうちの１つ以上、顧客に対応する支払いソースに関連する１以上の演算装置、又は、オンライン販売業者に関連する１以上の演算装置に対して通知を行うように構成される。一実施形態において、プロセッサはさらに、該規模が閾値を超えたことに応じて、ＩＰＳＰモジュールを実行して、当当該要求を処理しないようにする構成を有する。
【００１４】
本発明の種々の実施形態を一般的に説明したが、以下、添付図面を参照する。図面は必ずしも一定の縮小率で記載してあるわけではない。
【図面の簡単な説明】
【００１５】
【図１】本発明の種々の実施形態による金融取引処理システムの高レベルブロック図である。
【図２】本発明の種々の実施形態による金融取引処理システムにおける種々の契約関係を示す図である。
【図３Ａ】本発明の一実施形態による演算装置の概略図である。
【図３Ｂ】本発明の他の実施形態による演算装置の概略図である。
【図４】本発明の種々の実施形態による金融取引処理システムを示す概略図である。
【図５】本発明の種々の実施形態による販売業者モジュールのブロック図である。
【図５Ａ】本発明の種々の実施形態によるＫＹＣサブモジュールのブロック図である。
【図６】本発明の種々の実施形態によるＩＰＳＰモジュールのブロック図である。
【図７Ａ】本発明の種々の実施形態による不正行為防止サブモジュールのブロック図である。
【図７Ｂ】本発明の種々の実施形態による不正行為防止サブモジュールのフローチャートである。
【図８】本発明の種々の実施形態によるＡＳＰモジュールのブロック図である。
【図９Ａ】本発明の種々の実施形態による許可取引処理のフローチャートである。
【図９Ｂ】本発明の種々の実施形態による許可取引処理のフローチャートである。
【図１０Ａ】本発明の種々の実施形態による決済取引処理のフローチャートである。
【図１０Ｂ】本発明の種々の実施形態による決済取引処理のフローチャートである。
【図１１】本発明の種々の実施形態によるチャージバック取引処理のフローチャートである。
【図１２】本発明の種々の実施形態による顧客支払い取引処理のフローチャートである。
【図１３】本発明の一実施形態による許可取引要求処理のフローチャートである。
【図１４】本発明の一実施形態による決済取引要求処理のフローチャートである。
【図１５】本発明の一実施形態による強迫的消費行動を監視する処理のフローチャートである。
【図１６】本発明の一実施形態による強迫的ギャンブル行動を監視するプロセスのフローチャートである。
【図１６Ａ】本発明の一実施形態による強迫的ギャンブル行動を監視する他のプロセスのフローチャートである。
【図１７】本発明の一実施形態による金融取引への課税を判断するプロセスのフローチャートである。
【図１８】本発明の一実施形態による違法な金融取引又は規制対象の金融取引を判定するプロセスのフローチャートである。
【発明を実施するための形態】
【００１６】
以下、添付図面を参照し、本発明の種々の実施形態についてより詳細に説明する。図面は、本発明の実施形態のすべてを示すものではなく、幾つかの実施形態を示す。本発明は、多数の異なる形態で実施することができ、以下に記載する実施形態に限定されるものではない。これらの実施形態は、本開示が適用可能な法的要件を満たすように記載されている。本明細書において同様の符号は同様の構成要素を示す。
【００１７】
概略
一般に、本発明の種々の実施形態は、電子商取引部門のための改良された金融取引システムを提供し、このシステムは、（１）支払い取引をより安全に処理し、（２）不正取引、マネーロンダリング、未成年のギャンブルから販売業者と銀行を保護するのに役立ち、（３）インターネット上のゲーム、旅行、消費者による電子商品購入等、特別なリスクを生じると考えられる電子商取引分野での他の悪用を制限するのに役立ち、（４）このような取引に関連したプロセスや情報を統合して、データ記憶容量の低減、及び／又は、コンピュータ処理容量の低減を実現するのに役立つ。「取引」という用語は、二者間での事業上の契約又はやりとりを意味するのに用いる。例えば、取引の例には、販売業者に対して顧客を登録すること、賭け金を賭けること、入金を行うこと、支払いを行うこと、及び／又は、取消を行うことが含まれる。上述の目的を達成するために、金融取引システムの種々の実施形態では、（１）販売業者、インターネット支払いサービスプロバイダ、提携銀行、カードスキームのための、業務及び取引処理プロトコルを設けるとともに、（２）支払い及び関連金融取引の監視と処理を行う改良型自動システムを提供する。
【００１８】
例えば、本発明の種々の実施形態において、各販売業者にローリングリザーブ・エスクロー口座を設置し、提携銀行又はカード発行銀行の損失の危険を低減するようにエスクロー口座に資金提供を行う。例えば、一実施形態によれば、販売業者が受け取ったペイバック要求（例えば、チャージバックや払い戻し要求）を処理するのに使用可能な十分な資金があることを確保することにより、この損失の危険を低減する。一実施形態によれば、販売業者に支払われた資金のうち、ある割合の資金が、一定期間（例えば、６カ月、１年、３年）エスクロー口座に留保及び移動させられ、その期間、その資金が使用されなければ、資金を販売業者に戻す。ローリングリザーブ・エスクロー口座に提供する資金は、販売業者の潜在的利益から取られるため、販売業者の事業をマネーロンダリングの手段として使うことは魅力がない。また、種々の実施形態によれば、販売業者がチャージバック要求に対して異議を唱えることが可能な根拠としては、許容可能な異議の根拠によって提携銀行又はカード発行銀行の損失の危険が著しく大きくならないように限定されている（例えば、不正行為フラグで示された取引）。他の実施形態において、販売業者は、どのような根拠でもチェックバック要求に異議を唱えることができない。このように、種々の実施形態によれば、ローリングリザーブ・エスクロー口座により、ペイバック要求の処理のための資金源が確保される。これにより、顧客の損失の危険が少なくなるとともに、顧客がオンライン金融取引に参加する可能性が高くなる。さらに、ペイバック要求の資金が販売業者により提供される場合、提携銀行やカード発行銀行の損失の危険が少なくなり、販売業者にとってより好ましい事業条件が得られる（例えば、取引レートの低下やチャージバック率の低下）。
【００１９】
他の例として、本発明の種々の実施形態において、この金融取引システムの参加者は、当該地域の規制当局に対するコンプライアンスを互いに求める。例えば、一実施形態において、販売業者がコンプライアンスを怠っている場合、インターネット支払いサービスプロバイダ（以下に詳細に説明する）、提携銀行、カードスキームは、その販売業者との事業を否認してもよい。また、一実施形態において、参加者はコンプライアンスを怠る参加者に対して罰金を科してもよい。さらに、顧客も、コンプライアンスを怠る販売業者との商取引を否認してもよい。このプロトコルを設けることにより、金融取引システムは、当該地域の規制当局に対するコンプライアンスを参加者に続けさせるような市場インセンティブを与えることが多い。
【００２０】
本発明の種々の実施形態によれば、この金融取引システムの参加者には、オンライン顧客、オンライン販売業者、インターネット支払いサービスプロバイダ（ＩＰＳＰ）、提携銀行、カード発行銀行、あるいは、カードスキームが含まれる。ＩＰＳＰは販売業者と提携銀行との間で業務を行い、販売業者に対して支払い関連サービスを提供し、ネットワークを介して販売業者と提携銀行との仲介役となる。また、ＩＰＳＰは、アカウンティングサービスプロバイダ（ＡＳＰ）と連絡を取り、ＩＰＳＰが販売業者に提供する支払いサービスに関連した会計管理サービスを提供させる。
【００２１】
図１は、本発明の種々の実施形態による、種々の参加者が互いにやりとりを行う様子を示す高レベルブロック図である。例えば、参加者はネットワーク（例えば、インターネット、プライベートネットワーク、プライベートＬＡＮネットワーク）を介して、取引情報を電子的に交換することができる。特に、取引情報には、顧客の支払いカードに関連する口座から販売業者の口座に資金を移動するための販売業者からの許可要求、顧客の口座から販売業者の口座への資金の移動を許可するカード発行銀行からの許可メッセージ、販売業者の口座から顧客の口座への資金移動を要求するカード発行銀行からのペイバック要求（例えば、チャージバック又は払い戻し要求）、特定期間（例えば、２４時間、４８時間、１週間）に処理されたすべての取引についての各販売業者に対する決済要求が含まれてもよい。
【００２２】
上述の実施形態では、オンライン販売業者から商品やサービスを購入するための口座に関連する支払いカード（例えば、デビットカード、クレジットカード、プリペイドカード、近接型ＩＣカード）を使用することを説明したが、他の種々の実施形態において、他の種類の支払い方式を用いて購入を行ってもよい。例えば、他の支払い方式として、ある口座に関連する支払いトークン（例えば、物理的トークン又は電子トークン）を使用したり、ある口座に関連する番号（例えば、口座番号や口座にアクセスするためのパスワード）を使用したりしてもよい。また、他の支払い方式として、ある口座に関連する虹彩スキャン、指紋、音声認識等の生体認証データを使用して、支払いを許可してもよい。また、口座番号と、トークン、電話、電子メール、ショートメッセージサービス（ＳＭＳ）により得られる１回限りのパスワードとを組み合わせて、支払いを許可してもよい。
【００２３】
上記で簡単に説明したが、種々の実施形態による金融取引システムは、（１）参加者のための業務及び処理プロトコルと、（２）高いセキュリティレベルで金融取引を処理するように構成された自動監視及び処理システム（例えば、コンピュータソフトウェア及び／又はハードウェア）を提供する。これらプロトコル及び自動システムは、電子商取引における不正取引や危険を生じる可能性のある他の悪用行為から顧客や参加者を保護するのに役立つ。このシステムにより実行されるプロトコルの種々の例について、以下のセクションＡで詳細に説明する。自動システムの種々の実施形態については、以下のセクションＢで説明する。この金融取引システムで処理される種々の取引の例示的な流れについては、セクションＣでより詳細に説明する。
【００２４】
Ａ．プロトコルの例
この金融取引システムの種々の実施形態では、参加者のための業務及び処理プロトコルを提供する。種々の実施形態によれば、プロトコルは、販売業者の事業を利用した組織犯罪やマネーロンダリングの手段を抑止し、オンライン金融取引に関連することが多い不正取引や無許可取引の危険を減らし、提携銀行やカード発行銀行の損失の危険を低減し、国又は地域の規制へのコンプライアンスが得られる可能性を高めるのに役立つ。例えば、本発明の種々の実施形態によれば、参加者は、当該地域又は管轄地域の規制当局に対するコンプライアンスを示すことができなければならず、かつ、特定期間（例えば、２年、３年、５年）に処理された取引の監査可能な記録を保持しなければならない。また、プロトコルにより、各参加者は、他の参加者との契約を行う前に当該地域の規制要件に対するコンプライアンスを示さなければならない、としてもよい。また、プロトコルにより、参加者は、当該地域の規制当局において他の参加者が高く評価されていることを定期的に確認しなければならない、としてもよい。販売業者及びＩＰＳＰに関して設けることできるプロトコルの種々の例を以下に説明する。
【００２５】
販売業者
本発明の種々の実施形態によれば、販売業者が、管理職、役員、受益株主の身元を十分に開示し、変更があればＩＰＳＰにその変更を報告しなければならない、としてもよい。このリストの提供を求め、このリストと、組織犯罪にかかわっていると考えられている人物や団体のリストを比較することで、組織犯罪グループが販売業者の事業をマネーロンダリングや他の違法目的に利用することを抑止するのに役立つ。
【００２６】
また、本発明の種々の実施形態によれば、販売業者が、不正取引による提携銀行、カード発行銀行、顧客への損失の危険を減らすような１以上の手段を取らなければならない、としてもよい。例えば、種々の実施形態によれば、販売業者が、（１）すべての関連規制要件に対するコンプライアンスを示し、（２）契約上の義務を怠った場合は罰金を支払い、（３）販売業者の演算装置上で住所確認、年齢確認、身元確認ソフトウェアを用いて、オンライン取引の際に得られた支払い情報及び顧客情報を確認し、（４）得られた支払い及び顧客情報に対して初期不正チェックを行い、その後はランダム又は定期的にチェックを行い、あるいは、（５）ＩＰアドレスを用いてシステムにアクセスしている顧客、又は、当該取引が違法とされる管轄地域に関連する請求先住所を提出する顧客に対して、通知を行わなければならないようにしてもよい。
【００２７】
さらに、種々の実施形態によれば、販売業者は、販売業者の事業に関連する悪用の危険があれば、その危険を少なくし、販売業者と事業を行うことにより社会的影響（例えば、販売業者がオンラインゲーム販売業者又は成人向け娯楽提供者である場合の強迫的消費行動）があると思われる場合、その影響を少なくするプロトコルを実施しなければならない、としてもよい。例えば、販売業者が、その事業の社会的影響に関する助言や相談の手段（例えば、電話相談のフリーダイヤル番号、役立つ情報を提供しているウェブサイト、カウンセラーの連絡先情報）を提供しなければならない、としてもよい。さらに、一実施形態によれば、顧客がカスタマーサービスに電話をして取引についての問い合わせることができるように、販売業者が、顧客の支払いカードの請求書に販売業者名とフリーダイヤル番号を記載しなければならない、としてもよい。本発明の種々の実施形態によれば、カスタマーサービスの代表連絡先は、１日２４時間、週７日いつでも連絡を取ることができるものとする。
【００２８】
ＩＰＳＰ
本発明の種々の実施形態によれば、ＩＰＳＰが、以下のセキュリティ機能のうちの１つ以上を実行して、組織犯罪グループ等が販売業者の事業をマネーロンダリングに利用するのを抑止し、オンライン金融取引に関連する種々の参加者への危険を低減しなければならない、としてもよい。すなわち、（１）ペイバック要求の処理の対象となる各販売業者に対して、上述のエスクロー口座等のローリングリザーブ・エスクロー口座を設置する、（２）取引を監視して、不審な活動を判別する、（３）支払いカード毎に取引の頻度と金額を監視する、（４）追跡及び監査を目的として、各販売業者（又はウェブサイト）の取引をそれぞれ個別のストリームとして保持する、（５）取引情報を定期的に（例えば、２秒毎、１０秒毎）に保存して監査証跡を作成し、特定期間（例えば、１年、２年、５年）取引情報を記憶する、（６）カード所有者の身元を確認する、（７）管理職や受益株主をＩＰＳＰに開示するように販売業者に求める、（８）インターネットギャンブル業者からカード所有者への賞金支払いを制限し、適用可能な制裁対象リスト（例えば、米国の「特別指定国民リスト」（Specially Designated Nationals list））を用いて受取人名のスクリーニングを行う、（９）販売業者のライセンス付与を、適用可能な地域の法律や規則に従って行い、財政面及び法的面での良好な評価を保つように求める、（１０）契約上の義務を怠ったとされる販売業者を罰する（例えば、販売業者との契約を停止する、あるいは、販売業者に罰金を科す）、（１１）規制が適正に行われている管轄地域で業務を行うティア１の提携銀行を利用し、それらの提携銀行から証明を受ける、（１２）カード所有者情報の安全を維持するためのポリシー、手続き、規格（例えば、ＶＩＳＡカードのアカウント情報セキュリティ（ＡＩＳ）プログラム）を実施するように販売業者に求める、（１３）マネーロンダリングに関する金融活動作業部会（Financial Action Task Force on Money Laundering）（例えば、www.FAFT-GAFL.org；例えば、国際通貨基金（ＩＭＦ）が公表した「マネーロンダリング防止／テロ資金調達対策法（FATF40+9を含む）」、付録Ａとして添付）の勧告の管理及び適用を行う、という機能である
。また、種々の実施形態において、ＩＰＳＰは、ＩＰＳＰが処理した取引で、不正であると思われる取引又は不正であると判断された取引についての情報を記憶するための、図１に示す不正行為データベース４２を維持する。一実施形態によれば、ＩＰＳＰにより、他の参加者は取引の処理の際に不正行為データベースを利用することができ、カード発行銀行、提携銀行、販売業者、顧客の損失の危険をさらに減らすことができる。ＩＰＳＰは、自身の会計処理及び不正行為データベースを管理し、処理する取引の照合確認を行って、販売業者に対する照合レポートを作成することができるが、他の実施形態によれば、ＩＰＳＰは、アカウンティングサービスプロバイダ（ＡＳＰ）と契約を結び、これらのサービスの１以上を提供してもよい。さらに、種々の実施形態において、ＩＰＳＰは、顧客についての情報を記憶するための顧客情報データベース５０を維持する。
【００２９】
また、本発明の一実施形態によるプロトコルの例として、ＩＰＳＰが各販売業者について個別の法人（例えば、ＳＧ１、ＳＧ２、ＳＧ３等）を作り、これらの法人がＩＰＳＰ及び／又はＡＳＰの指示のもとに運営を行い、当該法人に関連する特定の販売業者について受け取った資金を管理するようにしてもよい。これについては図１４を参照して詳細に説明する。種々の実施形態によれば、この企業構成により各販売業者の運営がそれぞれ個別化される。また、種々の実施形態によれば、この企業構成により、金融取引システムと顧客の保護のために保持しているエスクロー資金を、確実に公正かつ客観的に管理することができる法的構造が得られる。
【００３０】
提携銀行
本発明の種々の実施形態によれば、プロトコルの例として、提携銀行が以下のセキュリティ機能のうちの１つを実行して、カード発行銀行及び顧客に対するオンライン取引関連の危険を低減するようにしてもよい。すなわち、（１）オンライン販売業者のクレジット活動を監視して、顧客が販売業者から賞金やクレジットを自分の支払いカードで確実に受け取れるようにする（例えば、ＶＩＳＡカード主催のカード所有者資金移動（ＣＦＴ）プログラムや、マスターカード主催のマネーフロー・プログラム）、（２）すべてのカードスキームの規則がＩＰＳＰ及び販売業者に確実に伝わるようにする、（３）取引情報が確実に、カードスキーム及びカード発行銀行により規定されるような適正なデータ構成要素を含んでいるようにする、（４）適用可能な規制方式に対するＩＰＳＰのコンプライアンスを確保する、という機能である。
【００３１】
参加者間の契約
本発明の種々の実施形態によれば、１以上のシステムプロトコルを参加者間の契約に組み込んで、設けられたプロトコルに対するコンプライアンスを確保してもよい。例えば、図２は、本発明の種々の実施形態による参加者間の契約関係を示す概略図である。具体的には、提携銀行３６、ＩＰＳＰ３４、各販売業者３１、３２、３３が、取引の処理のしかたに関する各関係者の義務を示す三者間処理契約４５を結んでもよい。この契約４５では、各関係者は、当該地域規制当局からの良い評価を受け続け、役員、管理職、受益株主の最新リストを他の関係者に提供し、取引情報に対して何らかの身元確認及び不正行為チェックを行い、監査のために取引情報を所定期間（例えば、１年間、３年間、５年間）保存しなければならない。また、一実施形態によれば、契約４５には、販売業者がチャージバック要求に異議を唱えることができる１以上の根拠が含まれてもよい。他の実施形態によれば、契約４５は、チャージバックの際に販売業者３１、３２、３３に課すことできる料金を設定してもよい。
【００３２】
また、提携銀行３６とＩＰＳＰ３４は、ＩＰＳＰが取引データに対して行うべき特定の不正行為チェックと、ＩＰＳＰがいつ各販売業者に代わって決済を要求すべきか（例えば、毎日、毎週）を示す信託契約４７を結んでもよい。
【００３３】
ＡＳＰ３５と各販売業者３１、３２、３３は、ＡＳＰがどのように販売業者に代わってローリングリザーブ・エスクロー口座を管理するかを示すエスクロー契約４９を結んでもよい（例えば、エスクロー口座に取られる資金の割合、資金がエスクロー口座に保管される期間、照合レポートの形式）。
【００３４】
さらに、ＡＳＰ３５とＩＰＳＰ３４は、ＡＳＰがＩＰＳＰに提供するアカウンティングサービスに関して各関係者の義務を示すサービス契約４３を結んでもよい（例えば、ＡＳＰとＩＰＳＰの間で交換されるデータの形式及びアクセス性、ＩＰＳＰ３４のため又はＩＰＳＰ３４に代わってＡＳＰが作成する概要報告書の種類と形式、１以上の参加者に対して支払い可能な料金の計算、あるいは、販売業者についての照合レポートを承認するための承認手続き）。また、一実施形態において、契約４３により、ＩＰＳＰ３４が処理した取引又はＩＰＳＰ３４に代わってＡＳＰ３５が処理した取引についての販売業者３１、３２、３３からの問い合わせに対して、ＡＳＰ３５が応答しなければならない、としてもよい。さらに、他の実施形態において、ＡＳＰ３５は、（１）ＩＰＳＰ３４に代わってＡＳＰ３５が処理したチャージバック要求に関する取引データをすべて識別し、（２）識別したデータを販売業者３１、３２、３３に転送して、チャージバック要求に関して販売業者３１、３２、３３がさらに何らかの行動を望む場合、それを確かめなければならない、としてもよい。
【００３５】
（Ｂ．取引の自動監視及び処理システム）
当該分野の技術者ならばわかるであろうが、本発明は、方法、取引処理システム、又はコンピュータプログラム製品として実施することもできる。したがって、本発明は、全体がハードウェアによる実施形態、全体がソフトウェアによる実施形態、又は、ソフトウェアとハードウェアの側面を組み合わせた実施形態であってもよい。さらに、本発明は、コンピュータにより読み取り可能なプログラムインストラクション（例えば、コンピュータソフトウェア）を記憶媒体において組み込まれる、コンピュータにより読み取り可能な記憶媒体上のコンピュータプログラム製品であってもよい。より具体的には、本発明は、ウェブ上で実行されるコンピュータソフトウェアであってもよい。ハードディスク、ＣＤ−ＲＯＭ、光記憶装置、磁気記憶装置等、コンピュータにより読み取り可能な記憶媒体であれば、いずれの媒体も用いることができる。
【００３６】
以下、本発明の一実施形態による方法、装置（すなわち、システム）、コンピュータプログラム製品のブロック図及びフローチャートを参照して、本発明について説明する。なお、ブロック図及びフローチャートにおける各ブロックや、ブロック図及びフローチャートにおける各ブロックの組み合わせは、それぞれ、コンピュータプログラムインストラクションにより実行することができる。これらコンピュータプログラムインストラクションを、汎用コンピュータ、専用コンピュータ、又は、他のプログラミング可能なデータ処理装置に読み込んで、コンピュータ又は他のプログラミング可能なデータ処理装置上で実行するインストラクションによって、フローチャートの１又は複数のブロックにて特定される機能の実行手段を生成するような機器を構成してもよい。
【００３７】
これらコンピュータプログラムインストラクションをコンピュータにより読み取り可能なメモリに記憶して、コンピュータにより読み取り可能なメモリに記憶されたインストラクションによって、フローチャートの１又は複数のブロックにて特定される機能を実行するための、コンピュータにより読み取り可能なインストラクションを含む製品が得られるような特定の方法で、コンピュータ又は他のプログラミング可能なデータ処理装置を機能させるように指示を与えてもよい。コンピュータプログラムインストラクションをコンピュータ又は他のプログラミング可能なデータ処理装置に読み込んで、コンピュータ又は他のプログラミング可能な装置上で一連の動作ステップが行われるようにし、コンピュータ又は他のプログラミング可能な装置上で実行されるインストラクションによって、フローチャートの１又は複数のブロックにて特定される機能の実行ステップが得られるようなコンピュータ実行処理を生成してもよい。
【００３８】
したがって、ブロック図及びフローチャートにおけるブロックは、特定の機能を行う手段の組み合わせ、特定の機能を行うステップの組み合わせ、及び、特定の機能を行うプログラムインストラクション手段に対応している。なお、ブロック図及びフローチャートにおける各ブロック、及び、ブロック図及びフローチャートにおける複数ブロックの組み合わせは、特定の機能又はステップを行う専用ハードウェアによるコンピュータシステム、あるいは、専用ハードウェア及びコンピュータインストラクションの組み合わせにより実行することができる。
【００３９】
本明細書で説明する種々の実施形態において、「コンピュータ」又は「演算装置」という記載がある。このようなコンピュータは、例えば、メインフレーム、デスクトップ、ノートパソコン、又は、データ取得及び記憶装置等のハンドヘルド装置であってもよく、また、例えば、無線電話等の他の装置内に組み込まれる処理装置であってもよい。幾つかの例において、このコンピュータは、ネットワークを介してデータやプロセッサにアクセスするのに使用される「ダム端末（単能端末）」であってもよい。図３Ａを参照して、本発明の種々の実施形態の各側面を実施するのに用いることができる演算装置の一実施形態について説明する。図３Ａにおいて、マイクロプロセッサ等のプロセッサ１は、所定のステップを行うためのソフトウェアインストラクションを実行するのに使用される。プロセッサは電源１７から電力供給を受け、電源１７は必要に応じて他の構成要素にも電力を供給する。プロセッサ１は、一般に１６又は３２ビット幅（例えば、パラレル）のデータバス５を用いて通信を行う。データバス５は、一般にプロセッサとメモリの間でデータやプログラムインストラクションを伝達するのに使用される。種々の実施形態において、メモリは、ＲＡＭ、又は、動作中のみコンテンツを保持する他の形態のメモリである一次メモリ２とすることができるが、ＲＯＭ、ＥＰＲＯＭ、ＥＥＰＲＯＭ、フラッシュメモリ、あるいは、常時メモリコンテンツを保持する他のメモリ等、不揮発性メモリ３であってもよい。メモリは、大量のデータを記憶するディスク記憶装置等の二次メモリ４であってもよい。また、幾つかの実施形態において、ディスク記憶装置は、Ｉ／Ｏバス６又は専用バス（図示せず）を用いてプロセッサと通信を行ってもよい。二次メモリは、フロッピー（登録商標）ディスク、ハードディスク、コンパクトディスク、ＤＶＤ、あるいは、コンピュータ分野の技術者にとって既知の大容量記憶型の他のメモリであってもよい。
【００４０】
プロセッサ１は、Ｉ／Ｏバス６を用いて種々の周辺機器や外部装置と通信を行う。種々の実施形態において、周辺Ｉ／Ｏコントローラ７を用いて、種々の入出力装置に対するインターフェースとして適切なＲＳ−２３２、ＲＳ４２２、ＤＩＮ、ＵＳＢ、その他のインターフェース等、標準インターフェースを設ける。一般的な入出力装置は、ローカルプリンタ１８と、モニタ８と、キーボード９と、マウス１０又は他の一般的なポインティングデバイス（例えば、ローラボール、トラックパッド、ジョイスティック等）とを備える。
【００４１】
プロセッサ１は、一般に、通信Ｉ／Ｏコントローラ１１を用いて外部通信ネットワークと通信を行い、Ｘ．２５、ＩＳＤＮ、ＤＳＬ、ケーブルモデム等のデータ通信向きプロトコル１２等、種々のインターフェースを用いてもよい。通信コントローラ１１は、標準電話線１３とのインターフェース提供及び通信を行うためのモデム（図示せず）を組み込んでもよい。さらに、通信Ｉ／Ｏコントローラは、ＬＡＮを介した通信のためのイーサネット（登録商標）インターフェース１４を組み込んでもよい。これらのインターフェースはいずれも、インターネット、イントラネット、ＬＡＮ、その他のデータ通信設備等、広域ネットワークにアクセスするのに使用してもよい。
【００４２】
さらに、プロセッサ１は、例えば、ＩＥＥE８０２．１１プロトコル、８０２．１５．４プロトコル、あるいは、ＣＤＭＡ２０００１ｘＥＶ−ＤＯ、ＧＰＲＳ、Ｗ−ＣＤＭＡ等の標準３Ｇ無線通信プロトコル、その他のプロトコルのうちのいずれかを用いて、他の装置と無線通信を行うためのアンテナ１５に接続して動作する無線インターフェース１６と通信を行ってもよい。
【００４３】
使用できる処理システムの他の実施形態を図３Ｂに示す。この実施形態では、ローカルクライアントコンピュータ２６ａ又はリモートクライアントコンピュータ２６ｂのいずれか一方と通信を行うサーバ２０を備えた分散型通信及び処理構成を示す。サーバ２０は、一般に、二次メモリの一種として考えられるデータベース２２（例えば、ＳＱＬデータベース）及び一次メモリ２４と通信を行うプロセッサ２１を備える。プロセッサは、一般にＬＡＮ２５とのインターフェースとなるＩ／Ｏコントローラ２３を用いて、外部装置との通信も行う。ＬＡＮは、ネットワーク接続したプリンタ２８及びローカルクライアントコンピュータ２６ａとのローカル接続を行ってもよい。これらは、必ずしも同じ部屋の中でなくてもよいが、サーバと同じ設備内に配置されてもよい。リモート装置との通信は、一般に、データをＬＡＮ２５から通信設備を介してインターネット等の広域ネットワーク２７にルーティングすることにより達成される。リモートクライアントコンピュータ２６ｂはウェブブラウザを実行してもよく、ウェブブラウザにより、リモートクライアントコンピュータ２６ｂは、広域ネットワーク２７を介してＬＡＮ２５上及びサーバ２０へのデータ送信を行うことにより、必要に応じてサーバとインタラクションを行うことができる。また、ウェブブラウザは、例えば、JavaScriptやMicrosoft.netで開発されたユーザインターフェースを備えてもよい。
【００４４】
データネットワーキング分野の技術者であれば、多数の他の代替手段や構成が可能であり、それらを本発明の種々の実施形態に使用することができるとわかるであろう。図３Ａ及び図３Ｂに示す実施形態は、種々の変更が可能であり、本発明の範囲内とすることができる。
【００４５】
図４は、本発明の種々の実施形態による各参加者に関連し、１以上のネットワーク１１５（例えば、プライベートネットワーク、プライベートＬＡＮネットワーク、インターネット）を介して互いに通信を行う演算装置１０１〜１０９を示す。例えば、一実施形態によれば、ＩＰＳＰ３４は、ＩＰＳＰゲートウェイ４０を介して販売業者３１、３２、３３及び提携銀行３６からアクセス可能なＩＰＳＰネットワークを確立してもよく、ＩＰＳＰゲートウェイ４０は、販売業者３１、３２、３３及び提携銀行３６が利用するネットワークにこのＩＰＳＰネットワークを接続する。種々の実施形態によれば、ＩＰＳＰゲートウェイ４０は、完全にハードウェアとして、あるいは、完全にソフトウェアとして、あるいは、両者の組み合わせとして実現してもよい。一実施形態において、ＩＰＳＰゲートウェイ４０は、ＩＰＳＰネットワークへのアクセスを選択的に許可することにより、ＩＰＳＰ３４との情報の送受信のセキュリティを確保する。例えば、ＩＰＳＰ３４と契約関係がない販売業者３１、３２、３３又は提携銀行３６は、ＩＰＳＰゲートウェイ４０によりＩＰＳＰネットワークへのアクセスを拒否される場合がある。さらに、１以上の記憶装置が１以上のネットワーク１１５と通信を行ってもよい。これらの記憶装置は、サーバ、ハードディスク、光ディスク、磁気テープ、フラッシュメモリ等のうちの１種類以上の装置、又は、これらの組み合わせとしてもよい。また、種々の実施形態において、これらの記憶装置は１以上のデータベースを含んでもよい。例えば、ＩＰＳＰ３４及び／又は販売業者３１、３２、３３は、１以上の記憶装置にある１以上の第三者データベース１１６、１１７と通信を行ってもよい。さらに、１以上の第三者システム１１８が１以上のネットワーク１１５と通信を行ってもよい。
【００４６】
また、提携銀行３６は、カードスキームネットワークを利用して、本発明の種々の実施形態によるカード発行銀行３７、３８、３９と情報を交換することができる。カードスキームネットワークの例として、ＶＩＳＡカード、マスターカード、アメリカン・エキスプレスのネットワークがあるが、これらに限定されるものではない。
【００４７】
図３Ａ及び図３Ｂを参照して上述したように、種々の実施形態によれば、販売業者３１、３２、３３、ＩＰＳＰ３４、ＡＳＰ３５、提携銀行３６、カード発行銀行３７、３８、３９は、１以上の演算装置（例えば、１以上のサーバ、ＳＱＬサーバ、ウェブサーバ）と関連しており、これら演算装置のうちの１以上が金融取引の自動処理システムを備えていてもよい。例えば、システム１００は、販売業者のシステム１０１、１０２、１０３で動作するように構成された販売業者モジュール２００と、ＩＰＳＰのシステム１０４で動作するように構成されたＩＰＳＰモジュール３００と、ＡＳＰのシステム１０５で動作するように構成されたＡＳＰモジュール４００とを提供する。これらモジュール２００、３００、４００は、一実施形態によれば、各参加者の処理機能を自動化する。これらのモジュールは、完全にハードウェアとして、あるいは、完全にソフトウェアとして、あるいは、両者の組み合わせとして実現してもよい。
【００４８】
また、一実施形態によれば、ＩＰＳＰ３４がアカウンティング関連サービスを提供する契約をＡＳＰ３５と結ぶ場合、ＡＳＰモジュール４００をＡＳＰシステム１０５で動作するように構成してもよい。また、他の実施形態において、ＡＳＰモジュール４００をＩＰＳＰのシステム１０４で動作するように構成してもよい。これらモジュールの種々の実施形態について、図５〜図８を参照して以下に詳細に説明する。
【００４９】
販売業者モジュール
図５は、本発明の種々の実施形態による販売業者モジュール２００のブロック図である。種々の実施形態によれば、販売業者モジュール２００は、販売業者システム１０１、１０２、１０３にて動作し、取引を処理するために販売業者が行うステップのうちの少なくとも一部を自動化する。例えば、販売業者モジュール２００は、ステップ２０２として示す許可要求の処理を行うように構成される。ステップ２０２にて、販売業者モジュール２００は顧客から支払い情報を受け取る。支払い情報には、顧客のフルネームと、請求先住所、電子メールアドレス、クレジットカード番号、ＣＶＶ２番号、支払い額、カード発行会社名の一部又はすべてが含まれてもよい。そして、販売業者モジュール２００は、クレジットカード番号が有効な番号であるかどうか、また、すべての項目が完了しているかどうかを確認する等、受け取った支払い情報の形式を確認する。さらに、販売業者モジュール２００は、以前に記憶した３Ｄ安全ソフトウェアプラグイン・サービス（例えば、ＶＩＳＡ認証サービス（Verified by VISA）や、マスターカードのセキュアコード（SecureCode））に関連する識別情報とパスワードと顧客情報を比較する。形式が正しければ、販売業者モジュール２００は許可要求を発行し、さらなる処理を行うためにＩＰＳＰシステム１０４に許可要求を送る。
【００５０】
本発明の種々の実施形態によれば、販売業者モジュール２００は、ステップ２０６として示すように、受け取った取引要求に対して初期不正行為チェックを行うように構成される。初期不正行為チェックステップ２０６では、そのクレジットカード番号を、盗難クレジットカード番号リストと比較したり、顧客から提供された請求先住所が支払いカードの請求先住所と一致していることを確認したり、提供された請求先住所を、販売業者への最初の登録時に顧客から提供された請求先住所と比較したり、あるいは、カード発行会社名が、例えば、カードのバンキング識別番号（ＢＩＮ）と一致することを確認してもよい。また、不正行為チェックステップ２０６は、図５に示すように、許可要求をＩＰＳＰに送信した（ステップ２０２）後に行ってもよく、あるいは、許可要求の発行及び送信の前に行ってもよい（図示せず）。一実施形態において、不正行為チェックステップ２０６は、許可要求送信（ステップ２０２）後で、カード発行銀行における決済前に行う。
【００５１】
不正行為チェックステップ２０６にて潜在的な問題が検知されない場合、販売業者モジュール２００は、ステップ２１０として示す顧客の年齢及び身元確認を行う。例えば、有権者登録記録や運転免許証記録等、カード所有者についての行政上の記録を調べることにより、あるいは、電子的年齢及び／又は身元確認サービス（例えば、英国に拠点を置くＧＢグループが提供する「ＵＲＵ」サービス）とネットワーク接続を確立し、顧客の情報をこのサービスに提供することにより、年齢を確認してもよい。種々の実施形態によれば、このサービスは顧客の情報を行政上又は他の公的記録と比較して、顧客の身元及び年齢を確認する。一実施形態において、販売業者モジュール２００は、顧客が販売業者に対して新たな口座を設置するときに、年齢及び身元確認ステップ２１０を行ってもよい。
【００５２】
より具体的には、種々の実施形態の販売業者モジュール２００は、顧客熟知（ＫＹＣ（know-your-customer））サブモジュール５００により構成されてもよい。したがって、図５Ａは、本発明の種々の実施形態によるＫＹＣサブモジュール５００のブロック図である。例えば、顧客は、生年月日等、ある程度の個人情報を提供する。この個人情報は、販売業者モジュール２００が許可要求を受け取るとき、あるいは、その前の時点、例えば、顧客が販売業者に対して新たな口座を設置するときに収集してもよい。また、この情報をメモリに記憶してもよい。例えば、販売業者モジュール２００は、販売業者と通信を行うデータベース（例えば、図１に示す販売業者３  ３３と通信を行うデータベース５１）に、この情報を記憶してもよい。この場合、ステップ５１０にて、ＫＹＣサブモジュール５００は、この情報を受け取り（例えば、メモリに情報を問い合わせる）、顧客の個人情報を１以上の個人情報データベースと比較して、情報の妥当性を確保にする。この１以上の個人情報データベースは、販売業者モジュール２００からアクセス可能なシステム内の販売業者がまとめてもよく、商業上利用が可能な種々の第三者データベースを備えてもよい。例えば、これらデータベースは、ＫＹＣサブモジュール５００がネットワークを介して遠隔的にアクセスする行政のデータベースであってもよく、あるいは、販売業者システムのうちの１つ、例えば販売業者システム１００内に配置されるデータベースであってもよい。さらに、種々の実施形態において、販売業者モジュール２００は、情報をローカルデータベースに記憶する前に情報のスクラブ及び／又はフォーマット化を行い、情報がＫＹＣサブモジュール５００及び／又はこの情報を利用する他のモジュールにとってより有用となるようにしてもよい。
【００５３】
種々の実施形態において、顧客は、ある範囲で自己の個人情報を提供することができる。例えば、顧客は、フルネーム、生年月日、電話番号、電子メールアドレス、住所、社会保障番号、運転免許証番号、パスポート番号を含む情報を提供してもよい。ステップ５２０にて、ＫＹＣサブモジュール５００は、顧客の個人情報に基づいて、有権者登録記録や運転免許証記録等、種々の第三者システムに問い合わせを行い、これら第三者システムは、自システムのデータベース又は他のデータベースに問い合わせて、当該問い合わせで得られた情報のうちの１つ又は複数が、データベースにある情報に対応することを確認してもよい。したがって、種々の実施形態において、得られた一致の数、及び、問い合わせで得られた情報の敏感度（その情報が一般に知られていない度合い）によって、その情報を提供する者が実際にその人物である可能性が高くなる。したがって、ステップ５３０において、ＫＹＣサブモジュール５００は、問い合わせの情報の確認と、確認が必要な情報の敏感度に基づいて、顧客が本当にその人物であるかどうかを判断する。ＫＹＣサブモジュール５００は、顧客の身元が確認されていないと判断する場合、ステップ５４０として示すように、顧客の身元を否認する（例えば、ＫＹＣサブモジュール５００は、顧客の身元が確認されていないことを販売業者モジュール２００に通知する）。ＫＹＣサブモジュール５００は、顧客の身元が確認されたと判断する場合、顧客の身元が確認されたことを承認する（例えば、ＫＹＣサブモジュール５００は、顧客の身元が確認されたことを販売業者モジュール２００に通知する）。
【００５４】
さらに、種々の実施形態のＫＹＣサブモジュール５００は、得られた情報が正しいことを確かめ、販売業者モジュール２００が身元確認済みの顧客と取引していることがある程度の確実になると、ステップ５６０にて、顧客の個人情報に含まれる確認済みの生年月日に基づいて顧客の年齢を計算する。例えば、ＫＹＣサブモジュール５００は単に現在の日付から生年月日を減算するか、上述のような方法を用いる。その結果、種々の実施形態の販売業者モジュール２００は、顧客がある取引を販売業者と行うことについて、許可又は制限をすることができる。
【００５５】
図５に戻り、以降、ステップ２１０の処理を定期的又はランダムに繰り返して、既存の顧客の身元及び年齢を再確認してもよい。また、図５に示す実施形態では、年齢及び身元確認ステップ２１０は、不正行為チェックステップ２０６と許可要求２０２の後で行うものとして示す。しかし、他の実施形態において、年齢及び身元確認ステップ２１０は、許可要求ステップ２０２又は不正行為チェックステップ２０６の前に行うこともできる。
【００５６】
年齢及び身元確認ステップ２１０にて顧客の年齢及び身元が確認されない場合、あるいは、不正行為チェックステップ２０６で取引に潜在的な問題があることを検知した場合、一実施形態によれば、販売業者モジュール２００は、ステップ２０８として示すように、取引が否認されたことを顧客に通知し、取引を否認すべきであることをＩＰＳＰに通知することができる。
【００５７】
また、種々の実施形態による販売業者モジュール２００は、特定期間（例えば、セッション毎、２４時間、１週間）、販売業者のウェブサイトで費やした時間を顧客に表示するか、他の方法で通知するように構成される。この情報を得ることにより、販売業者のウェブサイトに関する顧客の強迫的行動を回避するための支援ができる。さらに、販売業者モジュール２００は、販売業者が維持する顧客用取引ログへの顧客のアクセスを許可するように構成されてもよい。また、販売業者モジュール２００は、例えば、損失に対する制限（例えば、ギャンブル取引）、あるいは、販売業者のウェブサイトで費やす時間及び／又は金額等、自主規制ガイドラインを実施するように構成されてもよい。
【００５８】
マネーロンダリングからの保護のため、販売業者モジュール２００は、マネーロンダリング防止ソフトウェア（例えば、付録Ａとして添付した、国際通貨基金（ＩＭＦ）が公表した「マネーロンダリング防止／テロ資金調達対策法（FATF40+9を含む）」に示されるパラメータと、利用可能なデータを比較するソフトウェア）を実行して、選択された金額（例えば、１５，０００ユーロ又は２０，０００ドル）を超える取引をすべて評価するように構成されてもよい。このソフトウェアによる評価では、身元確認及び再確認の後、確認済みの個人又は企業に対してチェックを行ってもよい。
【００５９】
ＩＰＳＰモジュール
図６は、本発明の種々の実施形態によるＩＰＳＰモジュール３００のフローチャートを示す。一実施形態によれば、ＩＰＳＰモジュール３００は、ＩＰＳＰシステム１０４にて動作するように構成される。一実施形態によれば、ステップ３０２において、ＩＰＳＰモジュール３００は販売業者システム１０１、１０２、１０３から受け取った許可要求を処理する。各許可要求は、特定の取引についての支払い情報と、顧客のフルネーム、顧客の電子メールアドレス、顧客が取引を開始するのに使用する演算装置のＩＰアドレス等、取引に関連する顧客情報とを含んでいてもよい。本発明の種々の実施形態によれば、ＩＰＳＰモジュール３００は、その後、許可要求を提携銀行システム１０６に送り、提携銀行システム１０６は、許可要求を適切なカード発行銀行システム１０７、１０８、１０９に送る。図９Ａ及び図９Ｂを参照して以下に詳細に説明するが、種々の実施形態によれば、ＩＰＳＰモジュール３００は、提携銀行システム１０６を通してカード発行銀行システム１０７、１０８、１０９から、取引を許可又は否認する許可メッセージを受け取る。ＩＰＳＰモジュール３００は、この許可メッセージを販売業者システム１０１、１０２、１０３に送る。
【００６０】
特定の実施形態において、販売業者システム１０１、１０２、１０３に加えて、あるいは、それらの代わりに、上述のようなＫＹＣサブモジュール５００をＩＰＳＰシステム１０４に含めてもよい。これら特定の実施形態において、販売業者システム１０１、１０２、１０３のうちのいずれかが、ＩＰＳＰモジュール３００に顧客の個人情報を送り、ＩＰＳＰモジュール３００は、ステップ３０３として示すようにＫＹＣサブモジュール５００を実行する。そして、ＫＹＣサブモジュール５００は、図１６Ａを参照して説明した上述のステップを実行する。したがって、これら特定の実施形態において、ＫＹＣサブモジュール５００は、多数の販売業者に対して顧客を確認するものである。さらに、これら特定の実施形態において、例えば、図１に示す顧客情報データベース５０等、販売業者システム１０１、１０２、１０３内のメモリに加えて、あるいは、それらの代わりに、ＩＰＳＰシステム１０４内にあるメモリに顧客の個人情報を記憶してもよい。
【００６１】
種々の実施形態によれば、ステップ３０４において、ＩＰＳＰモジュール３００は、ＩＰＳＰモジュール３００が処理した取引情報（例えば、許可要求、チャージバック要求、払い戻し要求、決済要求）を記憶する。記憶した取引情報は、監査目的に使用することができ、顧客毎、支払いカード毎、販売業者毎の取引の種類や頻度を監視し、決済要求を発行し、決済要求に応じて受け取った資金の支払い割り当てに使用してもよい。例えば、定期的に、例えば、毎秒又は１０秒毎、あるいは、ＩＰＳＰモジュール３００が取引情報を受信して処理する毎等、取引毎に、許可、チャージバック、払い戻しの各要求を記憶してもよい。これらの要求は所定期間（例えば、１日、１週間又はそれ以上）記憶してもよい。また、種々の実施形態によれば、これらの要求を販売業者毎に（あるいは、販売業者が電子商取引に対応するウェブサイトを２以上有している場合、ＵＲＬ毎に）記憶してもよい。ＩＰＳＰモジュール３００は、定期的に（例えば、毎日、毎週）各販売業者に対する許可要求をまとめて、各販売業者についての決済要求ファイルを作成し、販売業者に対する決済要求をバッチファイルとして提携銀行システム１０６に送り、決済を行ってもよい。これについては、ステップ３１０を参照して以下に説明する。ＩＰＳＰモジュール３００は、所定期間（例えば、１年、２年、３年）、まとめた取引情報を個別ファイルとして記憶してもよい。
【００６２】
また、種々の実施形態において、ＩＰＳＰモジュール３００は、図６のステップ３０６として示すとともに図７Ａ及び図７Ｂを参照して以下に詳細に説明する不正行為防止サブモジュール３５０を実行し、当該取引がシステム１００による決済の対象となることを確認するように構成される。例えば、支払いカード番号が盗難に遭った支払いカード番号のリストにある場合、あるいは、顧客のＩＰアドレスの国が、支払いカードが発行された国とは一致しない場合、あるいは、顧客が国別制裁対象リスト（例えば、米国の「特別指定国民リスト」（Specially Designated Nationals list））に載っている場合、ＩＰＳＰモジュール３００は、決済を行う取引として当該取引を提示しない。図６に示す実施形態において、不正行為防止サブモジュール３５０は、許可要求処理ステップ３０２及び取引情報記憶ステップ３０４の後に実行されるものとして記載される。しかし、本発明の他の実施形態によれば、ステップ３０２の提携銀行システム１０６への許可要求の送信前、又は、ステップ３０４の取引情報の記憶前に、ＩＰＳＰモジュール３００によりステップ３０６を行ってもよい。
【００６３】
本発明の種々の実施形態によれば、ステップ３０６にて不正行為防止サブモジュール３５０が、ある取引について不正行為の可能性があることを検知した場合、ＩＰＳＰモジュール３００は、ステップ３０８として示すように、不正行為の疑いがあることを適切な関係者に通知するように構成される。種々の実施形態による適切な関係者としては、提携銀行３６（カード発行銀行に通知を渡してもよい）、カード発行銀行３７、３８、３９（直接的）、販売業者３１、３２、３３、及び／又は、顧客が挙げられる。また、種々の実施形態によれば、ＩＰＳＰモジュール３００は、ステップ３１２として示すように、不正行為の可能性がある取引についての情報を不正行為データベース４２に記憶するように構成される。不正行為データベース４２は、ＩＰＳＰモジュール３００がその後の取引を分析するのに用いることができる。また、一実施形態において、不正行為データベース４２は、カード発行会社ネットワーク及び／又は提携銀行が、受信した取引を分析するためにアクセスできるようにしてもよい。さらに、不正行為データベース４２には、顧客名、住所、ＩＰアドレス、支払い情報（例えば、カード又は口座番号）、電話番号、以前の不正行為を識別するコード又は記載といった項目のうちの１以上を含まれていてもよい。
【００６４】
ステップ３１０に示すように、ステップ３０６にて不正行為防止サブモジュール３５０が不正行為の可能性があることを検知しない場合、種々の実施形態によれば、ＩＰＳＰモジュール３００は決済要求を発行して、提携銀行システム１０６又はカード発行銀行システム１０７、１０８、１０９に決済要求を送るように構成される。決済要求は、特定期間（例えば、１日、１週間）にＩＰＳＰモジュール３００が受け取った許可要求、チャージバック要求、払い戻し要求に基づいている。一実施形態によれば、決済要求には、ＩＰＳＰモジュール３００及び販売業者モジュール２００によって不正行為の可能性がある取引としては検知されなかった取引のみが含まれてもよい。また、決済要求には、ＩＰＳＰモジュール３００又は販売業者モジュール２００によって不正行為の可能性があるとして検知されたが、決済要求にて不正行為の可能性があるとしてマークやフラグが付された１以上の取引が含まれてもよい。
【００６５】
上述のように、ＩＰＳＰモジュール３００は、ステップ３０６にて不正行為防止サブモジュール３５０を実行する。本発明の種々の実施形態による不正行為防止サブモジュール３５０の一例を図７Ａ及び図７Ｂに示す。図７Ａに示すように、不正行為防止サブモジュール３５０は、ここで「不正行為フィルタ」と呼ばれる種々のステップを行い、不正行為の可能性がある取引活動を検知するが、特定の不正行為フィルタの結果、又は、不正行為フィルタ群の結果の組み合わせに応じて、取引を阻止したり、フラグを立てたりするように構成されてもよい。ステップ３５２〜３６８は、本発明の種々の実施形態による不正行為防止サブモジュール３５０が行う不正行為防止フィルタを示す。図７Ｂは、本発明の種々の実施形態により、どの不正行為フィルタを取引情報に適用するかを判断するために、不正行為防止サブモジュール３５０が実行するステップを示す。
【００６６】
例えば、図７Ａのステップ３５２に示すように、不正行為防止サブモジュール３５０は、支払いカード情報を、盗難に遭った支払いカードを識別するリストと比較してもよい。また、ステップ３５４に示すように、不正行為防止サブモジュール３５０は、支払いカードを発行した金融機関に関連する位置を、顧客の演算装置に対応するＩＰアドレスに関連する位置と比較してもよい。顧客の演算装置に対応するＩＰアドレスは、販売業者システム１０１、１０２、１０３が取引情報を最初に受信したときに、販売業者モジュール２００によって（例えば、販売業者モジュール２００に組み込まれたＩＰアドレス検知ソフトウェアを用いて）得ることができる。また、不正行為防止サブモジュール３５０は、顧客の演算装置のＩＰアドレスに関連する位置を、顧客の請求先住所と比較して、顧客の演算装置の位置が請求先住所から所定半径（例えば、５０マイル）内にあることを確保するように構成されてもよい。同様に、不正行為防止サブモジュール３５０は、ステップ３５６に示すように、支払いカードを発行した金融機関に関連する位置を、顧客が提供した電子メールアドレスに関連する位置と比較してもよく、また、ステップ３５７に示すように、顧客の演算装置のＩＰアドレスの位置を、顧客が提供した電子メールアドレスに関連する位置と比較してもよい。上述の比較する位置は、国、地域、州、地方、市、１以上の郵便番号（例えば、ジップコード）により定められる郵便地区のうちの１つ以上とすることができる。
【００６７】
また、ステップ３５８に示すように、不正行為防止サブモジュール３５０は、支払いカードのバンキング識別番号（ＢＩＮ）を、疑わしいＢＩＮのリストと比較してもよく、ステップ３６０にて、不正行為防止サブモジュール３５０は、ウェブメールの電子メールアドレス（例えば、ホットメールやヤフーの電子メールアドレス）を持つ顧客が開始した取引を識別し、それにフラグを立ててもよい。さらに、ステップ３６２に示すように、不正行為防止サブモジュール３５０は、国の管轄地域内の販売業者との金融取引にかかわることを禁止された人物について国がまとめた人物リストと顧客の情報を比較してもよい。顧客が、米国の「特別指定国民リスト」（Specially Designated Nationals list）等、管轄地域が発動する金融制裁の対象となる人物、団体、法人のリストにある場合、その取引を否認することができる。同様に、ステップ３６８に示すように、不正行為防止サブモジュール３５０は、顧客の演算装置のＩＰアドレスに関連する国を、特定の管轄地域の販売業者と事業を行うことを禁止された国のリストと比較し、ＩＰアドレスの国がリストにある場合、その取引を否認することができる。さらに、ステップ３６７に示すように、不正行為防止サブモジュール３５０は、顧客情報をオンライン販売業者の役員、管理職、又は所有者のリストと比較して、顧客がリストにある場合、その取引に不正行為防止の可能性があるとしてフラグを立てたり、否認したりすることができる。
【００６８】
種々の実施形態によれば、不正行為防止サブモジュール３５０はさらに、ステップ３６４に示すように、特定期間（例えば、１カ月、１年）、顧客毎又はカード毎に取引の頻度を監視するように構成されてもよい。また、ステップ３６６に示すように、不正行為防止サブモジュール３５０は、特定期間、顧客又はカード毎に取引の種類（例えば、ギャンブル取引、旅行取引、成人向け娯楽取引）を監視するように構成されてもよい。カード毎又は顧客毎に取引の頻度と種類を監視することにより、本発明の種々の実施形態による不正行為防止サブモジュール３５０は、（１）カードの使用パターンが大幅に変化した場合にカード不正使用の可能性があることを判別し、（２）顧客が特定種類の取引に以前より頻繁に又はあまりにも頻繁にかかわっている場合、嗜癖や乱用の可能性があることを判別することができる。一実施形態によれば、監視ステップ３６４及び３６６は、顧客の過去の取引に基づいて取引の頻度及び／又は種類の範囲を設定し、その後の取引を設定範囲と比較することにより達成することができる。他の実施形態によれば、不正行為防止サブモジュール３５０が用いる範囲は、当該地域の行政又は規制当局が公表してもよく、また、学術又は専門研究等の結果であってもよく、また、参加者のうちの一者以上が設定してもよい。
【００６９】
また、種々の実施形態の不正行為防止サブモジュール３５０は、特定の取引に関するＩＰアドレスのマスキング又は不正改変を検知するように構成されてもよい。例えば、顧客が、プロキシサーバやルータ等、何らかのファイアウォール又はゲートウェイ装置の背後で取引を行っている場合がある。すると、この取引に関するＩＰアドレスはファイアウォールやゲートウェイのものであり、顧客のコンピュータのＩＰアドレスは隠されているか、マスキングされている。一実施形態において、不正行為防止サブモジュール３５０は、公知のゲートウェイ装置（例えば、プロキシサーバ）のＩＰアドレスを記憶するデータベースを検索するフィルタを用い、取引に関するＩＰアドレスを公知のゲートウェイサーバ（例えば、プロキシサーバ）のリストと比較することにより、この状況に対処する。その結果、不正行為防止サブモジュール３５０は、顧客のＩＰアドレスがゲートウェイ装置（例えば、プロキシサーバ）のものであると判断した場合、不正行為の可能性があるとして、その取引にフラグを立てたり、その取引を否認したりすることができる。
【００７０】
さらに、種々の実施形態による不正行為防止サブモジュール３５０は、顧客の活動から疑わしいパターンを判別するように構成されてもよい。例えば、不正行為の１パターンとして、盗難情報又は盗難クレジットカードを使用しようとすることがある。こうした場合、不正行為防止サブモジュール３５０は、顧客がある口座を使用して取引を行う際に、この特定顧客口座に関する情報としてメモリに記憶される顧客情報と一致するはずだが一致しない情報が提供されているか検索するように構成されてもよい。
【００７１】
また、不正行為防止サブモジュール３５０は、（１）顧客の本拠地の位置を不正行為頻発位置として識別すること、（２）特定位置にて認められているクレジットカードの数、購入の規模、購入回数に対する制限を調査すること、（３）カード発行銀行により識別された位置と、顧客が提供した顧客の位置との不一致を調査すること、（４）カード発行銀行の位置と、顧客のＩＰアドレスにより提供される顧客の位置との不一致を調べること、（５）顧客のＩＰアドレスにより識別される位置と、顧客が提供する位置との不一致を調べること、（６）顧客の電話が登録されている場所として識別される位置と、上述のいずれかの位置との不一致を調べること、（７）販売業者に対する登録又は入金の際に顧客が使用した情報のいずれかが、他の時期に他の口座で使用されたことがあるか否かを判定して、不正行為の可能性がある関連口座を見つけること（例えば、名前と生年月日の一致、電話番号の一致、住所の一致）、（８）１つのクレジットカードが使用された複数の口座を判別すること、（９）所定期間に種々の口座で使用されることになっている、ある区分のクレジットカード群を識別すること（クレジットカード発行側によって得られる場合もあるが、例えば、ある銀行に対する回転率）、（１０）パスワードの一致を判別すること（例えば、不正行為者は目に見える情報をすべて変更するかもしれないが、パスワードの変更は考えないかもしれない）により、疑わしいパターンを識別してもよい。
【００７２】
例えば、特定の例において、不正行為防止サブモジュール３５０は、特定の取引について顧客が受け取ったクレジットカード番号（例えば、バンキング識別番号（ＢＩＮ））の最初の６ケタを識別する。これら特定の実施形態において、不正行為防止サブモジュール３５０は、ＢＩＮ番号を用いて、カードを発行した銀行とその銀行に対応する位置を識別する。例えば、不正行為防止サブモジュール３５０は、ＩＰＳＰシステム１０４内のメモリ（例えば、図１に示す情報データベース５２）、あるいは、ＩＰＳＰシステム１０４の外部のメモリ（例えば、図４に示す第三者データベース１１６、１１７）に記憶されたＢＩＮバイブル（例えば、既知のＢＩＮ番号のリストを有するメモリ）に問い合わせを行う。この問い合わせにより、クレジットカードを発行した銀行の銀行名及び／又は位置が返送される。これに対して、不正行為防止サブモジュール３５０は、顧客が自分の位置であるとして識別した位置を、取引に使用されるカードを発行した銀行の位置と比較する。これらの位置が同じではない場合、あるいは、これらの位置が所定の許容範囲内にない場合、不正行為防止サブモジュール３５０は、その取引を不正行為の可能性がある取引として判別する。例えば、顧客が自分の位置を米国であると識別し、クレジットカードがロシアにある銀行から発行された場合、不正行為防止サブモジュール３５０は、関連する取引を不正行為の可能性がある取引として判別する。
【００７３】
図１５は、本発明の種々の実施形態による強迫的消費行動の監視プロセスを示す。具体的には、ステップ５０２から開始し、ＩＰＳＰモジュール３００は新たな金融取引要求を受信する。この新たな要求の受信に応じて、ＩＰＳＰモジュール３００は、ステップ５０４として示すように、以前に要求があった特定の販売業者３１、３２、３３と顧客との間の金融取引に関連してメモリ２４に記憶された資金の総額を読み出す。ステップ５０６にて、読み出した資金の総額と新たな要求にある資金額との合計を、販売業者３１、３２、３３に払う資金に対する所定の許容限度と比較する。合計が所定の許容限度を超える場合、ＩＰＳＰモジュール３００は、ステップ５０８として示すように、適切な１又は複数の関係者（例えば、顧客、カード発行銀行、及び／又は販売業者）に、限度を超えていることを通知する。本発明の他の実施形態において、ＩＰＳＰモジュール３００は、特定期間（例えば、２４時間、３６時間、１週間、１カ月、１四半期、１年等）内にメモリに記憶された資金額を読み出してもよい。また、他の実施形態において、ＩＰＳＰモジュール３００は、特定期間に顧客と販売業者との間で行われた取引の数を比較するように構成され、行われた取引の数が所定の許容限度を超える場合には、ＩＰＳＰモジュール３００は、顧客、カード発行銀行、及び／又は販売業者に、限度を超えていることを通知する。
【００７４】
同様に、図１６は、本発明の種々の実施形態による強迫的ギャンブル行動の監視プロセスを示す。ステップ６０２から開始し、ＩＰＳＰモジュール３００は、新たな金融取引要求を受信する。この新たな要求には、資金額と、取引の種類（例えば、販売業者への資金移動、販売業者のもとでの賭け、販売業者へのペイアウト要求）が含まれてもよい。次に、ステップ６０４にて、ＩＰＳＰモジュール３００は、新たな要求における金融取引の種類についてメモリ２４に記憶された資金の総額を読み出す。そして、ステップ６０６にて、資金の総額と新たな要求の資金額との合計を、新たな要求における金融取引の種類に関する所定の許容限度と比較する。合計が所定の許容限度を超える場合、ＩＰＳＰモジュール３００は、ステップ６０８として示すように、適切な１又は複数の関係者（例えば、顧客、カード発行銀行、及び／又は販売業者）に、限度を超えていることを通知する。一実施形態において、合計が所定の許容限度を超える場合、その新たな要求を否認する。さらに、メモリから読み出した資金の総額を、特定期間内に記憶した資金に限定してもよく、問い合わせの期間に基づいて所定の許容限度を変えてもよい。
【００７５】
さらに、種々の実施形態のＩＰＳＰモジュール３００は、特定種類の取引の資金の総額が所定の許容限度を超えることに加えて、ある基準に基づいて強迫的ギャンブル行動を監視してもよい。例えば、ＩＰＳＰモジュール３００は、（１）顧客の入金頻度や、入金の規模にパターンがあるかどうか、例えば、顧客が賞金を取り戻そうとして入金の規模を大きくする等、（２）顧客がギャンブルを行う速さ、（３）顧客がギャンブルを行う時間帯、（４）顧客に関する情報が、顧客がギャンブル依存症のサポートセンターに連絡を取ったことがあることを示しているかどうか、（５）顧客のギャンブルパターンが変化又は急増したかどうか、（６）顧客に関する情報が、顧客が冷却期間を要求したことがある、あるいは、ギャンブルを禁止してもらうように要求したことがあることを示しているかどうか、を評価してもよい。
【００７６】
例えば、一実施形態において、ＩＰＳＰは、強迫的ギャンブルの問題を抱える人たちを支援する種々の組織との関係やネットワークコンピュータリンクの確立、及び／又は、このような組織（例えば、サポートセンサー）の設立を行ってもよい。こうした組織は、ＩＰＳＰモジュール３００に、これら種々の組織が使用するコンピュータシステムや記憶装置に記憶された情報へのアクセスを与えてもよい。例えば、ネットワーク１１５を介してＩＰＳＰシステム１０４及び／又はこれら組織が使用するコンピュータシステム１１８と通信を行う記憶装置（例えば、図４に示す第三者データベース１１６、１１７等、１以上のデータベース）に、情報を記憶してもよい。したがって、この特定の実施形態において、ＩＰＳＰモジュール３００は、顧客の身元に基づいて情報へのアクセス及び問い合わせを行うように構成される。そして、ＩＰＳＰモジュール３００は、その情報を評価して、顧客がこれら組織のいずれかに連絡を取ったことがあるかどうかを判断する。
【００７７】
例えば、一実施形態において、特定の顧客に関する情報が、コンピュータシステム１１８及び／又はコンピュータシステムに関連する記憶装置１１６、１１７に記憶されていることから、顧客がこのような組織に連絡を取ったことがあるということを示す指示情報を、コンピュータシステム１１８のうちの１以上がＩＰＳＰモジュール３００に返送する。他の実施形態において、当該１以上のコンピュータシステム１１８は、レーティング（例えば、１〜１０、又は、高中低）で表される指示情報を、ネットワーク１１５を介して、ＩＰＳＰシステム１０４にあるＩＰＳＰモジュール３００に送る。したがって、ＩＰＳＰモジュール３００は、この指示情報を受けて、レーティングを評価し、顧客が強迫的行動を示すかどうかを判断する。
【００７８】
また、特定の実施形態において、当該組織に関連するシステム１１８は、強迫的ギャンブルについての支援を求めて当該組織に連絡を取ったことがある新たな顧客に関する情報を、ネットワークを介してＩＰＳＰシステム１０４に転送してもよい。すると、ＩＰＳＰシステム１０４は、ＩＰＳＰシステム１０４内のメモリ（例えば、図１に示す顧客情報データベース５０）に、この情報を記憶する。したがって、これら特定の実施形態において、ＩＰＳＰモジュール３００は、幾つかの組織のシステムに記憶された情報を問い合わせる必要はなく、直接、ローカルメモリに情報を問い合わせればよい。これにより、これら組織に関連する幾つかの異なるシステム１１８に問い合わせなければならない場合と比較して、特定の実施形態では処理の高速化が得られる。
【００７９】
さらに、ＩＰＳＰシステム１０４は、種々の実施形態において、顧客が冷却期間を要求したことがある、あるいは、ギャンブルを禁止してもらうように要求したことがあることを示す情報を記憶してもよい。例えば、特定の実施形態において、ＩＰＳＰシステム１０４は、このような冷却期間又は禁止してもらうように要求するサービスを顧客に提供してもよい。例えば、顧客は、ＩＰＳＰシステム１０４に関連するウェブサイトを開き、システム１０４は、冷却期間又は禁止してもらうための顧客登録を促す１以上のウェブページを提供する。特定の実施形態において、顧客は、ＩＰＳＰシステム１０４上で直接、あるいは、販売業者システム１０１、１０２、１０３を介して、このサービスにアクセスすることができる。すなわち、特定の実施形態において、ＩＰＳＰシステム１０４は、販売業者のウェブサイト上で利用可能となる特定のウェブページを販売業者システム１０１、１０２、１０３に提供してもよい。
【００８０】
他の実施形態において、販売業者３１、３２、３３は、例えば、販売業者のウェブサイトを介して、冷却期間又は禁止してもらうように要求するサービスを顧客に提供してもよい。これら特定の実施形態において、販売業者システム１０１、１０２、１０３は、販売業者システム１０１、１０２、１０３にその情報を記憶する、及び／又は、要求に応じてＩＰＳＰシステム１０４に情報を送って記憶する。したがって、ＩＰＳＰモジュール３００は、ローカルに（例えば、図１に示すＩＰＳＰ３４に関連する顧客情報データベース５０に）情報を問い合わせることにより、及び／又は、個々の販売業者システム１０１、１０２、１０３（例えば、図１に示す販売業者３  ３３に関連する顧客情報データベース５１）に情報を問い合わせることにより、顧客の行動を監視する。
【００８１】
そこで、図１６Ａは、本発明の種々の実施形態による強迫的ギャンブル行動を監視する他のプロセスを示す。ステップ１６０２にて開始し、ＩＰＳＰモジュール３００は、新たな金融取引要求を受信する。これに対して、ＩＰＳＰモジュール３００は、ステップ１６０４として示すように、ＩＰＳＰシステム１０４内の記憶装置、販売業者システム１０１、１０２、１０３内の１以上の記憶装置、あるいは、ネットワーク１１５を介してＩＰＳＰシステム１０４と通信を行う１以上の記憶装置１１６、１１７のうちのいずれかに対して、強迫的ギャンブル行動の人たちを支援する種々の組織に連絡を取ったことがある個人を示す情報、及び／又は、冷却期間又は禁止してもらうように要求したことがある個人を示す情報を問い合わせる。この情報から、ＩＰＳＰモジュール３００は、ステップ１６０６として示すように、金融取引の要求を提出した顧客がそのような組織に連絡を取ったことがあるかどうか、冷却期間を要求したことがあるかどうか、及び／又は、ギャンブルを禁止してもらうように要求したことがあるかどうかを判断する。顧客がこれら組織のいずれか連絡を取ったことがある、冷却期間を要求したことがある、及び／又は、ギャンブルを禁止してもらうように要求したことがある場合、ＩＰＳＰモジュール３００は、ステップ１６０８として示すように、適切な１又は複数の関係者（例えば、顧客、カード発行銀行、及び／又は、販売業者）に連絡する。例えば、一実施形態において、ＩＰＳＰモジュール３００は、電子メール等の電子メッセージを適切な１又は複数の関係者に自動的に送る。特定の実施形態において、ＩＰＳＰモジュール３００はその要求を否認してもよい。
【００８２】
さらに、特定の実施形態において、ＩＰＳＰモジュール３００は、冷却期間の要求又はギャンブルを禁止してもらうための要求を、多数の販売業者に対して適用するように構成されてもよい。例えば、ＩＰＳＰモジュール３００が、顧客が販売業者との取引を要求しているという通知を、ネットワークを介して販売業者システム１０１、１０２、１０３のいずれかから受信する場合、ＩＰＳＰモジュール３００は、ＩＰＳＰシステム１０４内の記憶装置、販売業者システム１０１、１０２、１０３内の１以上の記憶装置、あるいは、ネットワークを介してＩＰＳＰシステム１０４と通信状態である１以上の記憶装置１０６、１０７のいずれかに対して、冷却期間及び／又はギャンブルを禁止してもらうように要求している個人に関する情報を問い合わせる。そして、取引を要求している顧客が販売業者システム１０１、１０２、１０３のいずれかについて冷却期間及び／又は禁止を要求していることを示す問い合わせ情報に基づいて、ネットワークを介して、顧客との取引発生を許可しないように販売業者システム１０１、１０２、１０３に指示を与える、及び／又は、顧客（及び／又は他の適切な関係者）に対して、顧客がそのような冷却期間又は禁止を要求していることを、販売業者システム１０１、１０２、１０３から通知させる。
【００８３】
種々の実施形態において、例えば、図１に示す情報データベース５２等のデータベースは、ネットワークを介して種々の販売業者システム１０１、１０２、１０３から受信した強迫的行動の可能性を示す信号を記録するように維持されてもよい。また、入金可能頻度や入金可能規模等、さらなる変数について閾値を設定して、データベースに記憶してもよい（上述の移動資金額に対する所定の許容限度等）。その結果、ＩＰＳＰモジュール３００がこれらの閾値に基づいて顧客の入金を監視し、適切な１又は複数の関係者に通知することにより、強迫的行動を関係者に知らせるのに役立つ。
【００８４】
さらなる実施形態において、ＩＰＳＰモジュール３００は、強迫的ギャンブラーの可能性がある人、あるいは、実際に強迫的ギャンブラーであるとして判別された参加者のデータベースを維持し、このデータベースにアクセスすることもできる。図１に示すような、ＩＰＳＰ３４及び／又は販売業者３３に関連する顧客情報データベース５０、５１、及び／又は、図４に示すような第三者データベース１１６、１１７を、この目的で利用してもよい。ＩＰＳＰモジュール３００はデータベースをチェックして、新たな顧客が、ギャンブル産業の販売業者として知られる販売業者との取引を行おうとする場合、必ず、顧客が強迫的ギャンブラーではないことを確実にする。ＩＰＳＰモジュール３００は、顧客がデータベースに含まれていると判断した場合、顧客がこの特定販売業者と取引を行うことを制限又は禁止する。
【００８５】
上述の種類の取引の監視のほかに、本発明の種々の実施形態によれば、不正行為防止サブモジュール３５０はさらに、ペイバック要求取引を監視し、不審な取引を識別するように構成されてもよい。ペイバック要求情報が本来の取引における情報と一致しないような取引を識別する、あるいは、特定期間（例えば、１週間、１カ月、数カ月以内）に特定の支払いカードに関して相当数のペイバック要求取引があったことを識別する等により、不審なペイバック要求取引を識別した場合に、支払いカード番号を、禁止支払いカードリストに追加し、その支払いカードを使った今後の購入取引を防止するようにしてもよい。
【００８６】
上述のフィルタに加え、本発明の種々の実施形態によれば、不正行為防止サブモジュール３５０はさらに、（１）各顧客が１枚の支払いカードのみを使用することを確実にし、（２）顧客毎に特定期間における特定活動に対する支払いを特定頻度に制限する（例えば、支払いを１日当たり１回、あるいは、３６時間毎に３回とする）ように構成されてもよい。さらに、一実施形態によれば、特定期間（例えば、日毎、週毎、月毎）における特定サービス（例えば、インターネットギャンブルや成人向け娯楽）について、カード毎又は顧客毎に使える金額の上限を設定してもよい。一実施形態において、顧客の要求に応じてこの上限を設定してもよい。他の実施形態において、ＩＰＳＰシステム１０４は、特定活動に使える金額についてデフォルトの限度額を導入してもよく（例えば、支払いカードに関連するクレジット限度の２０％）、この限度額は顧客の明確な要求がなければ増額することができない。一実施形態において、ＩＰＳＰシステム１０４又は販売業者システム１０１、１０２、１０３は、利用限度額の増額要求を受けて、特別訓練を受けた従業員から顧客への電話や電子メール等により、利用超過の危険に関する資料を顧客に提示し、乱用の可能性があることを検知した場合に資料や支援手段（例えば、ギャンブラーズ・アノニマス（ギャンブル依存症の人の自助グループ）の電話番号、ウェブサイトアドレス、その他の資料）を提示するように構成されてもよい。
【００８７】
本発明の種々の実施形態によれば、ＩＰＳＰシステム１０４はさらに、不正行為防止サブモジュール３５０からの結果を記憶する不正行為及び乱用データベース（図示せず）を備えてもよい。一実施形態において、ＩＰＳＰモジュール３００は、取引の処理時（ステップ３０２）や不正行為防止サブモジュール３５０の実行時（ステップ３０６）に、このデータベースにアクセスして、特定の支払いカード又は顧客に対する以前の不正行為チェックに基づいて取引を否認すべきかどうかを判断する。
【００８８】
図７Ｂに示すように、本発明の一実施形態によれば、不正行為防止サブモジュール３５０は、上述の不正行為フィルタのうちの１以上を使用して、受信した取引情報を評価してもよい。不正行為防止サブモジュール３５０は、ステップ３７０から開始し、ＩＰＳＰモジュール３００から取引データを受信する。次に、ステップ３７２にて、不正行為防止サブモジュール３５０は、取引データの評価に使用する１以上の不正行為フィルタを決定する。例えば、一実施形態において、不正行為防止サブモジュール３５０は、以前に販売業者が選択して使用した不正行為フィルタを使用する。他の実施形態において、使用する不正行為フィルタの種類は、取引の種類（例えば、許可要求、チャージバック要求、決済要求、支払い要求）によって異なる。さらに他の実施形態において、使用する不正行為フィルタの種類は、顧客に関連するＩＰアドレスの国によって異なる。そして、他の実施形態において、どの不正行為フィルタを用いるかの選択は、ＩＰＳＰ及び／又は当該地域規制当局によって決められる。そして、ステップ３７４にて、不正行為防止サブモジュール３５０は、適切な不正行為フィルタを実行して取引データを評価する。
【００８９】
本発明の種々の実施形態によれば、不正行為防止サブモジュール３５０の実行に加えて、ＩＰＳＰモジュール３００はさらに、違法又は規制対象となる金融取引を識別するように構成される。例えば、図１８は、違法又は規制対象の金融取引を識別するプロセスの一例を示す。ＩＰＳＰモジュール３００は、ステップ８０２から開始し、顧客の支払いカードから販売業者３１、３２、３３への資金移動の要求を受け取る。資金移動要求には、顧客の請求先住所と、顧客がこの要求を発行するのに使用した演算装置に関連するＩＰアドレスの位置が含まれる。
【００９０】
種々の実施形態において、不正行為防止サブモジュール３５０は、第三者のＩＰジオロケーション（地理的位置）サービスを利用して、ＩＰアドレスの位置を判断する。例えば、不正行為防止サブモジュール３５０は、第三者ＩＰジオロケーションサービスにより提供されるデータベースを検索して、あるＩＰアドレス又はＩＰアドレス群に対応する物理的位置を識別する。これらデータベースは、インターネットを介してアクセスするか、あるいは、種々の実施形態によるＩＰＳＰシステム１０４に直接接続することができる。
【００９１】
なお、幾つかの例において、顧客のコンピュータがゲートウェイ装置（ファイアウォール、プロキシサーバ、ルータ）を使用してもよい。ゲートウェイ装置は、個々のコンピュータ又はユーザの識別子をマスキングし、代わりにゲートウェイ装置の識別子を表示する（不正行為検出フィルタについて上述したのと同様）。例えば、顧客のコンピュータが、図１に示すゲートウェイ装置６０、６２を使用してもよい。これにより、不正行為防止サブモジュール３５０は、プロキシサーバ等、公知のゲートウェイ装置（例えば図４に示すように、ネットワーク１１５上の第三者データベース１１６、１１７）のＩＰアドレスを記憶するデータベースをさらに検索する。不正行為防止サブモジュール３５０が、そのＩＰアドレスを、あるゲートウェイ装置（例えば、プロキシサーバ）に属しているものとして識別し、ゲートウェイ装置（プロキシサーバ）の背後にいる顧客の位置を正確に判断又は予測できない場合、不正行為防止サブモジュール３５０は、そのＩＰアドレスを識別不可能としてフラグを立て、顧客によるＩＰＳＰシステム１０４の使用を制限する。
【００９２】
他の場合、ゲートウェイ装置は顧客の実際の識別子を把握していてもよい。したがって、種々の実施形態の不正行為防止サブモジュール３５０は、ネットワーク１１５を介して、顧客のコンピュータのＩＰアドレス等、顧客を識別するための、つまり、ゲートウェイ装置に接続した顧客の位置を識別するためのさらなる情報を、ゲートウェイ装置に要求するように構成される。
【００９３】
ＩＰアドレスを顧客の識別子として使用するのでは不十分な場合がある。そこで、不正行為防止サブモジュール３５０の種々の実施形態では他の固有識別子を利用する。例えば、顧客が携帯電話によりインターネットにアクセスしている場合、顧客は携帯電話のプロバイダにより制御されるゲートウェイ装置を通してやりとりする。この場合、不正行為防止サブモジュール３５０は、携帯電話会社に関連するゲートウェイ装置のＩＰアドレスを受信し、このＩＰアドレスと、金融取引に関連するウェブサイトと、取引の日時を携帯電話会社に提供する。種々の実施形態において、不正行為防止サブモジュール３５０は、インターネットを介して携帯電話会社のシステムにアクセスする等、種々のやり方でこの情報を提供することができる。
【００９４】
ＩＰアドレスとともにこの追加情報を提供した結果、携帯電話会社は特定サイトにアクセスしている携帯電話を識別することができ、基地局に基づいて顧客の位置を正確に特定し、ＩＰＳＰモジュール３００にその位置を提供することができる。したがって、この場合、不正行為防止サブモジュール３５０は、多数の変数の組み合わせを用いて、顧客の位置を識別する固有識別子を形成する。これら変数は、携帯電話会社のシステムのＩＰアドレス、金融取引に関連するウェブサイト、取引の日時である。
【００９５】
他の例において、顧客はＡＯＬ（アメリカ・オンライン）等、種々のインターネットプロバイダを通してインターネットにアクセスしていてもよい。携帯電話プロバイダの場合と同様、顧客はＡＯＬにより制御されたゲートウェイ装置を通してインターネットにアクセスしている。したがって、不正行為防止サブモジュール３５０は、顧客のコンピュータのＩＰアドレスではなく、ゲートウェイ装置のＩＰアドレスを受信する。これに対して、不正行為防止サブモジュール３５０は、ＩＰアドレス、金融取引に関連するウェブサイト、取引の日時をＡＯＬに提供し、ＡＯＬはこの情報を用いて顧客の位置を識別し、その位置をＩＰＳＰモジュール３００に提供する。他の実施形態では、他の多くの変数を１つ以上用いて、このような固有識別子、例えば、グローバルポジショニングシステム（ＧＰＳ）、高度観測時間差（Ｅ−ＯＴＤ）、タイミングアドバンス処理付きセルグローバル識別（ＣＧＩ−ＴＡ）、アップリンク到着時刻（ＴＯＡ）に関連する変数等を提供してもよい。
【００９６】
次に、ステップ８０４にて、ＩＰＳＰモジュール３００は、顧客の請求先住所、ＩＰアドレスの位置、販売業者３１、３２、３３の位置を、販売業者３１、３２、３３への資金移動規制位置リストと比較する。位置リストはＩＰＳＰ（例えば、図１に示す情報データベース５２）内にローカルに記憶してもよいし、１以上の第三者データベース（例えば、図４に示す第三者データベース１１６、１１７）にリモートで記憶してもよい。これら位置のいずれかが、位置リストにある位置と一致する場合、ＩＰＳＰモジュール３００は、ステップ８０６として示すように、１以上の規制当局がこれらの位置のいずれかにおける資金移動を規制しているかどうかを判断する。ＩＰＳＰモジュール３００は、１以上の規制当局が資金移動を規制していると判断する場合、ステップ８０８０として示すように、当該資金移動が受ける１以上の規制の種類について、適切な１又は複数の関係者（例えば、顧客、販売業者、及び／又はカード発行銀行）に通知する。金融取引が受ける規制の種類には、資金移動の禁止（例えば、ギャンブルが違法である州や地域でのギャンブル取引）や、資金移動の制限（例えば、賭金の額を制限している州や地域でのギャンブル取引）が含まれる。
【００９７】
さらに、種々の実施形態において、位置リストには、このような金融取引が違法又は規制対象となる位置だけでなく、このような取引の許可を選択的に除外する位置が含まれていてもよい。例えば、ある州ではこのような取引が厳密には違法ではないかもしれないが、州としては、このような取引の許可を除外することを選択する場合がある。したがって、ＩＰＳＰモジュール３００は、顧客の請求先住所、ＩＰアドレスの位置、販売業者３１、３２、３３の位置を、このような除外リストと比較して、３つの位置のいずれかがリストにある場合、取引を禁止する。除外リストには、特定種類の取引の除外を選択している業種等、他の実施形態における他の変数が含まれてもよい。
【００９８】
ＡＳＰモジュール
図８は、本発明の種々の実施形態によるＡＳＰモジュール４００のブロック図である。ＡＳＰモジュール４００は、一実施形態によるＡＳＰシステム１０５にて動作するように構成されてもよいが、ＩＰＳＰが他の実施形態による会計管理サービスを行う契約をＡＳＰと結んでいない場合、ＩＰＳＰシステム１０４にて動作するように構成されてもよい。
【００９９】
一実施形態によれば、ＡＳＰモジュール４００は、ステップ４０２にて開始し、ＩＰＳＰシステム１０４及び提携銀行システム１０６から取引情報を得る。ＩＰＳＰシステム１０４から得られた取引情報には、各取引について以下のデータ項目が含まれていてもよい。すなわち、（１）販売業者又は販売業者の営業組織（例えば、特定のウェブサイト）を識別するために提携銀行から付与される販売業者識別（ＭＩＤ）番号、（２）取引の日時、（３）顧客の名前、（４）支払いカード番号又は支払いカード番号の一部（例えば、最後の４ケタ）、（５）カード所有者の電子メールアドレス、（６）取引の通貨、（７）使用される支払いカードの種類（例えば、ＶＩＳＡ、マスターカード、アメリカン・エキスプレス）、（８）支払い額、（９）販売業者が取引に割り当てた注文照会番号、（１０）取引が許可されたかどうかを示し、カード発行銀行が発行する固有コードである許可コード、（１１）取引の決済状況（例えば、決済完了の取引については「１００」）、（１２）ＩＰＳＰが提携銀行に決済要求を送った時刻である「決済時刻」、（１３）カード所有者が居住する通りと番地、（１４）カード所有者の町、（１５）カード所有者の国、（１６）カード所有者の郵便番号、（１７）払い戻し要求があった場合に、払い戻される元の取引の照会記号となる元取引照会記号、（１８）販売業者が取引に関する情報をさらに含めたい場合に使用できる他の情報、（１９）販売業者に対するＩＰＳＰの照会記号である「サイト照会記号」、（２０）許可済み取引、払い戻し取引、取り消し済み取引（例えば、取消になった取引、あるいは、カード発行銀行から販売業者への送金前で、ＩＰＳＰから提携銀行への決済要求送信後に、販売業者の要求により金額が変更された取引）を含む取引の種類、（２１）ＡＳＰシステム１０５において取引を固有に識別する固有照会番号（ＵＲＮ）、というデータ項目である。本発明の一実施形態によれば、この情報は、ＩＰＳＰから提携銀行に送信される決済要求に含まれてもよい。これについては、先に図６のステップ３１０を参照して説明してあり、また、図１０Ａのステップ１１０２、１１０４を参照して以下に説明する。提携銀行システム１０６から得られる取引情報には、例えば、販売業者毎に１以上の集合としてまとめられた複数のカード発行銀行に要求される資金の総額が含まれてもよい。
【０１００】
種々の実施形態によれば、ＡＳＰモジュール４００は、取引情報を得るため、取引情報が掲示されている安全なウェブページ（例えば、各システム１０４、１０６により維持される）にアクセスして、ＡＳＰシステム１０５に情報をダウンロードしてもよいし、別の電子送信方式（例えば、電子メール又はファクス）により取引情報を受信してもよい。また、両者の組み合わせでもよい。
【０１０１】
種々の実施形態において、ステップ４０２にて得られた取引情報を、ステップ４０４として示すようにＡＳＰシステム１０５に記憶する。そして、ステップ４０６として示すように、ＩＰＳＰシステム１０４から得られた情報を、提携銀行システム１０６から得られた情報と比較する。図８に示す実施形態では、ステップ４０６はステップ４０４の後で行うことになっているが、他の実施形態においては、これらのステップを同時におこなってもよいし、順序を逆にしてもよい。
【０１０２】
本発明の種々の実施形態によれば、比較ステップ４０６にて、ＡＳＰモジュール４００は、ＩＰＳＰシステム１０４により提供された取引情報が提携銀行システム１０６により提供された取引情報と一致しない取引を識別する。一実施形態において、不一致の取引にはフラグを立て、ＡＳＰモジュール４００により作成される例外報告書にて、販売業者、ＩＰＳＰ、及び／又は提携銀行に報告する。これについては、ステップ４１０を参照して以下に詳細に説明する。他の実施形態において、図１４を参照して以下に説明するが、ＩＰＳＰ３６及び／又はＡＳＰ３５が維持する各販売業者の口座に、提携銀行システム１０６が直接資金移動を行う。この実施形態において、ＡＳＰモジュール４００はさらに、ＩＰＳＰシステム１０４及び提携銀行システム１０６により提供された取引情報を、各販売業者の口座に移動した金額と比較するように構成される。
【０１０３】
ＩＰＳＰシステム１０４及び提携銀行システム１０６により提供された取引情報の照合後、ＡＳＰモジュール４００は、図８にステップ４０８として示すように、種々の参加者に対して、決済処理中に受け取った支払い金額を割り当てることができる。支払い金額には、例えば、販売業者３１、３２、３３への支払い金額、ＩＰＳＰ３４、提携銀行３６、ＡＳＰ３５が受け取る手数料、及び、各販売業者３１、３２、３３のローリングリザーブ・エスクロー口座４１に入金する資金の割合が含まれてもよい。例えば、種々の実施形態によれば、種々の参加者は、販売業者３１、３２、３３との契約及び相互の契約４３、４５、４７、４９によるサービスに対する支払いとして、販売業者３１、３２、３３が受け取ったある資金のうち所定の割合を要求してもよい。例えば、提携銀行３６は、販売業者３１、３２、３３が受け取った資金の３％を請求し、カードスキームは、カード使用により移動した資金の１％を請求し、ＩＰＳＰ３４は、支払い関連サービスについて５％を請求し、ＡＳＰ３５は、会計管理サービスについてＩＰＳＰ３４が受け取った金額の３％をＩＰＳＰ３４に請求してもよい。他の例として、ＡＳＰ３５は、カード検証、種々の参加者への手数料支払い、受理したチャージバックについて販売業者３１、３２、３３に対して請求可能な料金等、種々のサービスについてＩＰＳＰ３４が負う一時費用を計算してもよい。
【０１０４】
また、種々の実施形態によれば、金融取引システム１００は、ローリングリザーブ・エスクロー口座４１に資金提供するのに使用される資金の割合を特定するプロトコルを設けてもよい。例えば、システムプロトコルにより、ＡＳＰモジュール４００は、各販売業者３１、３２、３３が受け取る資金の７．５％を、各販売業者３１、３２、３３のローリングリザーブ・エスクロー口座４１に割り当てなければならない、としてもよい。他の例として、一実施形態によれば、ローリングリザーブ口座の特定割合は、特定の販売業者３１、３２、３３について受けるペイバック要求の数に応じて自動的に増減させてもよい。また、一実施形態によれば、ＡＳＰモジュール４００は、所定期間（例えば、６カ月、１年、３年）口座に残っている資金の監視及び判別を行い、期間の終わりに販売業者３１、３２、３３にそれらの資金の再割り当てを行う。さらに、エスクロー口座４１は、図１の実施形態においてＡＳＰシステム３５の一部として示されている。しかし、他の実施形態において、エスクロー口座４１は銀行又は他の金融機関に存在するか、あるいは、銀行又は他の金融機関によって維持されてもよい。
【０１０５】
次に、ステップ４１０にて、種々の実施形態によれば、ＡＳＰモジュール４００は、販売業者毎に照合レポート又は「通知書」を発行するように構成される。一実施形態において、特定期間（例えば、１日又は１週間）に当該販売業者について処理した取引の概要、照合ステップ４０６で作成した例外報告書（必要な場合）、ステップ４０８で種々の参加者のそれぞれに割り当てた支払いの概要、特定期間のエスクロー口座における活動の概要、販売業者３１、３２、３３に支払いが送金される日付が、通知書によって各販売業者に与えられる。他の実施形態において、通知書のこれら各部分はそれぞれ別々の報告書に含まれる（例えば、例外報告書、支払い割り当て報告書、取引概要報告書）。そして、さらに他の実施形態において、ＡＳＰモジュール４００は、ＩＰＳＰ３４及び各販売業者３１、３２、３３への１以上の概要報告書を、それぞれ特定された形式により発行するように構成される。
【０１０６】
図８に示す実施形態において、ＡＳＰモジュール４００はさらに、（１）ステップ４１２として示すように、各販売業者３１、３２、３３への通知書の承認を受けるために通知書をＩＰＳＰ３４に送信し、（２）ステップ４１４として示すＩＰＳＰ３４から通知書の承認を受けると、ステップ４１６として示すように、販売業者３１、３２、３３に通知書を送信する。他の実施形態において、ＩＰＳＰ３４は会計管理サービス（図示せず）を提供する契約をＡＳＰ３５と結ばず、この場合、ステップ４１２、４１４は行わなくてもよい。
【０１０７】
また、ＡＳＰモジュール４００は、本発明の種々の実施形態によれば、ステップ４１８として示すように、種々の参加者及びエスクロー口座への支払いの準備及び送金を行うように構成されてもよい。ステップ４１８では、例えば、各参加者に物理的に支払いの送金を行う（例えば、小切手や現金）、又は、ＡＳＰシステム１０５に関連する口座から支払い先となる種々の参加者のそれぞれの口座への電子資金移動（ＥＦＴ）の要求を準備する、あるいは、これらの組み合わせであってもよい。さらに、図８に示す実施形態では、支払いステップ４１８はステップ４１６の後に行われることになっているが、他の実施形態によるＡＳＰモジュール４００は、ステップ４１６と同時又はステップ４１６の前に支払いステップ４１８を行うように構成されてもよい。
【０１０８】
本発明の他の実施形態によれば、ＡＳＰモジュール４００はさらに、各販売業者３１、３２、３３への支払い送金の前に、当該電子商取引（例えば、インターネットギャンブル取引や小売商品購入）に対する地方税を差し引くように構成されてもよい。例えば、一実施形態において、ＡＳＰモジュール４００は、各顧客及び／又は販売業者の居住地又は取引地に基づいて適用可能な税率又はライセンス料を適用し、その資金を適切な税当局又はライセンス許可当局に直接移動するように構成されてもよい。
【０１０９】
具体的には、図１７は、金融取引で課される税清算プロセスの一例を示す。ステップ７０２から開始し、１以上の税管轄地域のそれぞれについて、適切な税の種類と、対応する税率をメモリ２４に記憶する。次に、ステップ７０４にて、顧客と販売業者３１、３２、３３との間で行われる金融取引に関連する情報を受信する。この金融取引に関連する情報の受信に応じて、ステップ７０６として示すように、金融取引に関連する１以上の適切な税管轄地域を識別する。次に、ステップ７０８にて、識別された税管轄地域に関連する１以上の税の種類を判断するためにメモリに問い合わせる。１以上の税の種類が、識別した税管轄地域に関連している場合、ステップ７１０として示すように、この種類の税に対応する税率を当該金融取引に適用して、取引に課せられる税金を判断する。また、当該取引に課せられる税金を判断すると、ステップ７１２として示すように、支払うべき税額を適切な税当局に移動する。種々の実施形態において、取引発生側（例えば、販売業者）の位置、顧客、及び／又は、顧客が注文を行うときの演算装置の位置によって、課税を行ってもよい。
【０１１０】
種々の実施形態において、上述と同じシステム及びプロセスをライセンス料に適用することができる。例えば、運転免許証や漁獲許可証と同様に、個人がギャンブルを行うために取得しなければならないライセンスの行政手続き料の場合である。そこで、ステップ７０２から開始し、適切なライセンス料、及び、１以上のライセンス管轄区域のそれぞれについて対応するライセンスレートをメモリ２４に記憶する。次に、ステップ７０４にて、顧客と販売業者３１、３２、３３との間で行われる金融取引に関する情報を受信する。この金融取引に関する情報の受信に応じて、ステップ７０６として示すように、当該金融取引に関連する１以上の適切なライセンス管轄区域を識別する。次に、ステップ７０８にて、メモリに問い合わせを行い、関連する１以上のライセンスの種類を判断する。１以上のライセンスの種類が、識別されたライセンス管轄区域に関連している場合、ステップ７１０として示すように、その種類のライセンスに対応するライセンスレートを当該金融取引に適用して、当該取引にかかるライセンス料を判断する。また、取引にかかるライセンス料を判断すると、ステップ７１２として示すように、支払うべき料金を適切なライセンス当局に送金する。税金の場合と同様、種々の実施形態において、取引発生側（例えば、販売業者）の位置、顧客、及び／又は、顧客が注文を行うときの演算装置の位置によって、ライセンス料を課してもよい。
【０１１１】
種々の実施形態において、差し引かれた税金の額や税当局に支払われた額は、所定期間、取引情報とともにシステム内に記憶する。これにより、幾つかの実施形態において、完全な監査証跡が可能になる。例えば、一実施形態において、支払うべき額を指定銀行口座に保持し、定期的に（例えば、毎月、毎週、毎日、あるいは、リアルタイムで）税当局に支払う。一実施形態において、支払うべき額を電子資金移動（ＥＦＴ）により税当局に支払う。
【０１１２】
種々の実施形態によれば、この税清算機能により、販売業者、顧客、税当局の負担が減り、課税可能な取引について信頼できる清算システムが提供される。また、一実施形態において、ＡＳＰモジュール４００は、支払うべき税、及び／又は、徴収済みの税についてまとめた税当局への会計報告書を発行する。
【０１１３】
さらに、種々の実施形態において、ＡＳＰモジュール４００を介して、取引記録の監査を電子的又は手作業により行ってもよい。具体的には、システムを通して取引が処理される際に、各取引に関連する固有照会番号（ＵＲＮ）を追跡する。例えば、一実施形態において、複数の取引を１つのバッチファイルにまとめて、決済のために提携銀行に送る。ＡＳＰモジュール４００は、個々の取引を独立して監査できるように、バッチファイルにある各取引に関連するＵＲＮを、バッチファイルを識別する情報とともに記憶する。
【０１１４】
Ｃ．処理フローの例
許可処理フロー
図９Ａは、本発明の種々の実施形態による許可要求の処理フロー１０００を示す。一実施形態において、許可要求処理フローは、顧客が待っている間にオンラインで行われ、処理は一般に約２〜２０秒かかる。カード発行銀行が許可要求を受け付けると、販売業者は顧客の支払いを受け付け、カード発行銀行は、支払いカードに関するクレジット限度額又は残高から要求金額を遮断する。
【０１１５】
本発明の種々の実施形態によれば、許可要求プロセス１０００は、ステップ１００２から開始し、販売業者３１、３２、３３は、顧客の支払いカードから販売業者の口座への送金要求を顧客から受信する。この要求には、例えば、送金額、顧客の情報及び支払いカード情報が含まれてもよい（販売業者が、以前の取引で記憶した顧客の情報及び支払いカード情報を有していないことが前提）。一実施形態において、顧客及び支払いカード情報には、顧客のフルネームと住所、顧客の電子メールアドレス、支払いカード番号、有効期限、支払いカードに関する他の識別情報が含まれてもよい。一実施形態においては、販売業者のシステム１０１、１０２、１０３が、この要求を受信して、記憶してもよい。
【０１１６】
次に、本発明の種々の実施形態によれば、ステップ１００６にて、販売業者３１、３２、３３が、顧客からの要求において受信した情報のフォーマットを確認する。一実施形態において、図５及びステップ２０４に示す販売業者モジュール２００を参照して上述したように、販売業者モジュール２００は、支払いカード番号のフォーマットが正しいかどうか、及び、必要な項目がすべて完了しているかどうかを確認する。
【０１１７】
ステップ１００６の情報フォーマット確認後、販売業者３１、３２、３３は、ステップ１０１０として示すように、さらに処理を行うためにＩＰＳＰ３４に取引情報を転送する。ＩＰＳＰ３４は、ステップ１０１２として示すように、取引情報を受信してＩＰＳＰシステム１０４に記憶し、提携銀行３６及びカード発行銀行３７、３８、３９が許可要求の処理の際に必要とする情報を、提携銀行３６に転送する。例えば、本発明の種々の実施形態によれば、ＩＰＳＰモジュール３００が提携銀行システム１０６に情報を転送し、この情報には、支払いカード番号、支払い額、顧客の請求先住所が含まれていてもよい。
【０１１８】
次に、ステップ１０１４で、提携銀行システム１０６は許可要求を受信して、提携銀行システム１０６に記憶する。そして、ステップ１０１６にて、提携銀行システム１０６は、適切なカード発行会社及びカード発行銀行を識別し、適切なカード発行会社ネットワーク（例えば、ＶＩＳＡ、マスターカード、アメリカン・エキスプレスのネットワーク）を介して、カード発行銀行に許可要求を送る。許可要求を受信すると、カード発行銀行システム１０７、１０８、１０９は、ステップ１０１８として示すように、支払いカード番号が有効かつ正当であることを確認し、ステップ１０２０として示すように、支払いカードに利用可能な十分な資金があることを確認する。許可要求を承認すると、カード発行銀行システム１０７、１０８、１０９は、ステップ１０２２として示すように、カード発行会社ネットワークを介して提携銀行システム１０６に承認メッセージを送る。提携銀行システム１０６は、ステップ１０２４にて、承認メッセージを受信し、承認メッセージをＩＰＳＰシステム１０４         に送信する。そして、ステップ１０２６で、ＩＰＳＰシステム１０４は、承認メッセージを受信して記憶し、許可要求を発行した販売業者システム１０１、１０２、１０３にこの承認メッセージを送る。
【０１１９】
種々の実施形態によれば、許可要求情報を販売業者からＩＰＳＰに転送するステップＳ１０１０と同時に、あるいは、その前又は後に、図５を参照して上述した初期不正行為チェック及び身元／年齢確認ステップ（ステップ２０４及び２０６）を、販売業者モジュール２００により行ってもよい。また、本発明の種々の実施形態によれば、許可要求情報をＩＰＳＰから提携銀行に転送するステップ１０１２と同時に、あるいは、その前又は後に、図６にステップ３０６として示す不正行為防止サブモジュール３５０の実行ステップを、ＩＰＳＰモジュール３００により行ってもよい。
【０１２０】
本発明の他の実施形態を図１３に示すが、この実施形態において、顧客の情報を販売業者システム１０１ａ、１０２ａ、１０３ａに送るとき、またはネットワーク１１５ａを介してＩＰＳＰシステム１１４ａに送るとき、顧客情報を暗号化する（例えば、２０４８ビット変数暗号化による）。また、ＩＰＳＰモジュール３００ａは、不正行為防止サブモジュール３５０ａの不正行為フィルタのうちの１以上を実行して、不正行為フィルタが潜在的に不審な活動を検知した場合、提携銀行システム１０６ａに許可要求を送る前に、販売業者の承認を得るために不正行為チェックの結果を販売業者に送る。販売業者が取引の承認を与えた後、ＩＰＳＰモジュール３００ａは提携銀行に許可要求を送り、提携銀行はこの要求をカード発行銀行に送る。提携銀行は、カード発行銀行から許可メッセージを受信した後、提携銀行システム１０６ａのメモリ領域（例えば、データベース）に取引情報を記憶し、ＩＰＳＰシステム１０４ａに許可メッセージを送る。ＩＰＳＰモジュール３００ａは許可メッセージを販売業者に転送し、取引の決済要求発行前に取引情報に対して１以上の不正行為フィルタを実行してもよい。
【０１２１】
決済処理フロー
図１０Ａ及び図１０Ｂは、本発明の種々の実施形態による決済要求処理フローの一例１１００を示す。種々の実施形態によれば、決済要求とは、販売業者への支払いのためにカード発行銀行から提携銀行へ送金を行うように、提携銀行（又は提携銀行の代わりにＩＰＳＰ）が発行する要求である。本発明の種々の実施形態によれば、決済要求プロセス１１００は、ステップ１１０２から開始し、ＩＰＳＰシステム１０４が各販売業者３１、３２、３３についての決済要求を発行し、決済要求をバッチファイルとして提携銀行３６に送信する。種々の実施形態において、各決済要求には、特定期間（例えば、２４時間、４８時間、１週間）にＩＰＳＰ３４が取り扱った取引のデータが含まれる。本発明の種々の実施形態によれば、決済要求には、許可済み取引及び未許可取引、あるいは、許可済み取引のみが含まれてもよい。次に、本発明の種々の実施形態によれば、ステップ１１０４にて、ＩＰＳＰシステム１０４は、ＩＰＳＰシステム１０４に決済要求を記憶する。ＩＰＳＰシステム１０４の安全な部分からダウンロードすることにより、決済要求をＡＳＰシステム１０５に転送してもよい。また、ＩＰＳＰ３４が決済要求の物理的コピー又は電子コピーをＡＳＰ３５に送ってもよい（例えば、電子メール、ファクシミリ、ＣＤ、ＤＶＤ、フロッピー（登録商標）ディスクによる）。本発明の種々の実施形態による決済要求の内容については、先に図８を参照して説明した。
【０１２２】
ステップ１１０６に示すように、提携銀行３６はバッチファイルを受信し、適切なカード発行銀行３７、３８、３９に決済要求を送信する。また、提携銀行３６は、ステップ１１０８として示すように、各カード発行銀行３７、３８、３９に対する各決済要求に含まれる資金額（例えば、資金総額）をまとめたＡＳＰ３５への支払い報告書を発行し、記憶する。提携銀行３６がＡＳＰ３５に対して発行する支払い報告書の一実施形態については、先に図８を参照して説明した。
【０１２３】
そして、ステップ１１１０にて、カード発行銀行３７、３８、３９は要求された資金を提携銀行３６に移動させる。次に、ステップ１１１２にて、提携銀行３６は、受け取った資金をＩＰＳＰ３４に移動する。ＩＰＳＰ３４（又はＡＳＰ３５）が適切な参加者及びエスクロー口座に資金を分配する前に、ＡＰＳシステム１０５は、ステップ１１１４にて、ＩＰＳＰシステム１０４が発行した決済要求と、提携銀行３６が発行した支払い報告書を取得し、得られた情報を照合する。ステップ１１１４で行った照合の結果は、本発明の種々の実施形態のＡＳＰ３５が、照合レポート（又は「通知書」）としてまとめてもよい。そして、ステップ１１１６で、ＡＳＰ３５は、各参加者への支払いとエスクロー口座への送金額を整理して、参加者及びエスクロー口座に支払いの送金を行う。
【０１２４】
一実施形態によれば、ＡＳＰモジュール４００は、ステップ１１１４及び１１１６を行うように構成されてもよい。これについては図８を参照して上述した。例えば、ＡＳＰモジュール４００は、ＩＰＳＰ及び提携銀行が提供するデータの照合結果を、定期的に（例えば、毎日又は毎週）各販売業者３１、３２、３３に送られる照合レポートとしてまとめる。照合レポートは、販売業者３１、３２、３３が特定日までに販売業者の銀行口座にて受け取ることになっている金額の概要を示す。また、照合レポートには、顧客が各販売業者の口座に入金した総額が含まれており、このレポートは以下の差引額及び追加額を示す。すなわち、（１）手数料や料金（一連の支払いにおける全参加者への支払いを含む）の差引、（２）チャージバックや払い戻しに対する安全策としてのローリングリザーブ・エスクロー口座に所定期間（例えば、６カ月又は１年）留保してある総額のうちの、ある割合に対応する「トラスト・ディダクト」（信託差引額）の差引、（３）上記所定期間かつ通知書の日付の前日まで留保してあった「信託金」の追加、（４）以前の取引に関する通知書の日付において提携銀行から通知されたチャージバックの差引、といった差引額及び追加額である。適切な参加者及びローリングリザーブ・エスクロー口座への資金移動の前に、ＩＰＳＰ３４は、支払いが行われることになっている日付を含む照合レポートを再検討する。ＩＰＳＰ３４からの照合レポートの承認を受けて、ＡＳＰ３５は種々の販売業者３１、３２、３３に照合レポートを送信し、適切な参加者及びエスクロー口座に支払いの送金を行う。一実施形態において、照合レポートの発行及び承認後に資金移動を行ってもよい。他の実施形態においては、照合レポートの承認前に資金移動を行ってもよい。
【０１２５】
図１４に示す他の実施形態によれば、各販売業者に関連する各法人（例えば、ＳＧ１、ＳＧ２、ＳＧ３等）の口座に提携銀行が直接資金を入金する。また、ＡＳＰモジュール４００ａはさらに、各口座において受け取った金額と、ＩＰＳＰ及び提携銀行からそれぞれ得られた決済要求及び支払い報告書を照合するように構成される。一実施形態において、当該口座から種々の参加者又はエスクロー口座に支払われない金額は、販売業者に支払われる。
【０１２６】
チャージバック処理フロー
チャージバック要求とは、顧客の支払いカード口座に特定料金を払い戻すために、顧客に代わりカード発行銀行が発行する要求である。例えば、顧客が、自分は使用を許可していないと主張する支払いカードへの請求に異議を唱える場合、これに応じて、カード発行銀行がチャージバック要求を発行してもよい。図１１は、本発明の種々の実施形態によるチャージバック要求処理フローの一例１２００を示す。
【０１２７】
ステップ１２０２から開始し、カード発行銀行３７、３８、３９は顧客からチャージバック要求を受信する。そして、ステップ１２０４にて、カード発行銀行３７、３８、３９は、提携銀行３６にチャージバック要求を送信する。ステップ１２０６にて、提携銀行３６は、チャージバック要求を受信し、それをＩＰＳＰ３４に送信する。次に、ステップ１２０８にて、ＩＰＳＰ３４は、チャージバック要求を元の取引のデータと比較する。チャージバック要求におけるデータが元の取引のデータと一致すると思われる場合、ステップ１２１０にて、ＩＰＳＰ３４はその要求をＡＳＰ３５に送信する。比較及び送信ステップ１２０８及び１２１０は、上述のような本発明の種々の実施形態によるＩＰＳＰモジュール３００により行ってもよい。次に、ステップ１２１２にて、本発明の種々の実施形態によれば、ＡＳＰ３５はチャージバック金額を販売業者のエスクロー口座から提携銀行３６に転送し、提携銀行３６は、チャージバック要求を発行したカード発行銀行３７、３８、３９にチャージバック金額を転送する。他の実施形態において、ＡＳＰ３５は、資金不足、支払い不能、破産、及び／又は、販売業者の廃業等、販売業者がチャージバック金額を直接支払うことができない場合のみ、販売業者のエスクロー口座から提携銀行３６にチャージバック金額を転送する。他の実施形態において、ＡＳＰ３５は、決済要求において販売業者３１、３２、３３に支払わられるべき総額からチャージバック金額を差し引くことにより、カード発行銀行３７、３８、３９にチャージバック金額を支払う。そして、ステップ１２１４にて、ＡＳＰ３５はチャージバック要求を記憶する。本発明の種々の実施形態において、ＡＳＰモジュール４００はステップ１２１２及び１２１４を行うように構成される。
【０１２８】
ステップ１２０８にてチャージバック要求データが元の取引のデータと一致しない場合、本発明の種々の実施形態によれば、チャージバック要求にフラグを立ててもよい。また、特定の支払いカードに関してフラグが立てられたチャージバック要求の数が、所定期間に所定数（例えば、１週間又は１カ月間に２回のチャージバック要求）を超える場合、ＩＰＳＰは、今後、販売業者が支払いのために受け付けてはならない支払いカードのリストに、この特定の支払いカードを含めてもよい（例えば、ＩＰＳＰ３４が維持する不正行為及び乱用データベース）。
【０１２９】
上述に加えて、種々の実施形態によれば、ＡＳＰ３５は、特定期間に（例えば、毎日又は毎週）提携銀行３６及びＩＰＳＰ３４が処理するチャージバック要求を、元の取引の取引データと照合する。要求を照合するため、ＡＳＰ３５は、ステップ１２１６として示すように、提携銀行３６が発行するチャージバック取引報告書と、ＩＰＳＰ３４が発行するチャージバック取引報告書を取得し、これら２つの報告書を元の取引のデータと比較する。一実施形態において、比較ステップ１２１６は、チャージバック報告書のデータをＡＳＰシステム１０５のメモリに記憶された元の取引のデータとリンクさせることにより行う。一実施形態によれば、チャージバックデータ報告書には以下の情報のうち、少なくとも一部が含まれる。すなわち、（１）チャージバック対象となっている元の取引の照会記号、（２）ＭＩＤ番号、（３）チャージバック要求が発行された日付、（４）「チャージバック」としての取引の記載、（５）フルカード番号、（６）提携銀行が付与した照会記号、（７）カード所有者がチャージバックを開始した理由を示すコードであり、カード発行会社が発行するコード番号である「理由コード」、（８）チャージバック発生理由の記載、（９）チャージバック金額の通貨の種類、（１０）チャージバック金額、（１１）提携銀行が与えるカード番号又はその一部（例えば、カード番号の最初の４ケタ）、（１２）元の取引が「掲載された」又は許可された日付、（１３）元の取引が行われた日付、（１４）元の取引の「種類」、（１５）元の取引の通貨、（１６）元の取引金額、（１７）取引決済の通貨、（１８）決済額、（１９）提携銀行が与える元の「デフォルト」通貨、（２０）提携銀行が与える元の「デフォルト通貨」金額、（２１）提携銀行が特定日の取引に関するデータをＩＰＳＰに公開したときに、当該取引を含んでいた「取引バッチ」に対する照会記号である「オリジナル・スリップ」（元伝票）、（２２）提携銀行の「アイテム・スリップ」（項目伝票）、（２３）元の取引の許可コード、（２４）提携銀行の「バッチ番号」、（２５）顧客の支払いカード明細書に記載されている販売業者の名称である「販売業者ＤＢＡ名」、といった情報である。図８を参照して上述したように、本発明の種々の実施形態によれば、ＡＳＰモジュール４００は、この照合ステップ１２１６を行うように構成されてもよい。
【０１３０】
本発明の種々の実施形態によれば、ＩＰＳＰシステム１０４及び提携銀行システム１０６に各報告書を掲載し、ＡＳＰシステム１０５がダウンロードしてもよい。また、例えば、電子メール、ファクシミリ、ＣＤ、ＤＶＤ、フロッピー（登録商標）ディスク等により、物理的又は電子的に報告書を送ってもよい。
【０１３１】
支払い処理フロー
電子商取引部門の中には、顧客への払い戻しが必要な部門（例えば、ギャンブル）がある。顧客への支払いは、特にインターネットギャンブルの場合、マネーロンダリングへの悪用の危険が懸念される。本発明の種々の実施形態によれば、システム１００は、顧客が販売業者への元の支払いの際に利用した支払いカード口座のみに支払いを行い、顧客と販売業者との間に十分な透明性を有する「閉ループ」を構成することにより、電子商取引に関する危険に対処する。そこで、一実施形態によれば、資金は同じ口座から発生して同じ口座に戻り、全てのマネーフローが追跡可能となるので、電子商取引はマネーロンダリングの手段としては魅力のないものになる。
【０１３２】
例えば、図１２は、顧客による支払い要求提出時の顧客への支払い処理及び送信フローの例１３００を示す。ステップ１３０２から開始し、販売業者は顧客から支払い要求を受信し、その要求をＩＰＳＰに送信する。次に、ステップ１３０４にて、ＩＰＳＰは、顧客が国又は地域の当局制裁対象リスト（例えば、米国の「特別指定国民リスト」（Specially Designated Nationals list））に含まれていないことを確認する。また、一実施形態によれば、ＩＰＳＰは、販売業者が事業を行うかもしれない禁止国のリストに、顧客の国籍（例えば、顧客の請求先住所又は顧客の演算装置のＩＰアドレスに基づく）が含まれていないことを確認する。種々の実施形態によれば、顧客（又は顧客の国）がリストにある場合、システム１００は支払い要求を処理できず、要求は否認される。顧客が制裁対象リストに含まれていない場合（あるいは、禁止国に関係していない場合）、ステップ１３０６として示すように、ＩＰＳＰ３４は支払い要求を販売業者の銀行に送る。要求を受信し、支払い資金が販売業者の口座にあることを確認すると、ステップ１３０８として示すように、販売業者の銀行は資金をＩＰＳＰ３４に送る。ＩＰＳＰ３４は資金を受け取り、その記録をＩＰＳＰシステム１０４に記憶した後、ステップ１３１０に示すように提携銀行３６に資金を移動する。次に、ステップ１３１２にて、提携銀行３６は、資金を受け取ると、販売業者のウェブサイトでの購入（例えば、賭け）に使用された顧客の支払いカードに関連するカード発行銀行３７、３８、３９に資金を送る。種々の実施形態によれば、ステップ１３１４にて、カード発行銀行３７、３８、３９は、販売業者３１、３２、３３から受け取った金額分、支払いカードに関連する口座にクレジットを与えてもよいし、あるいは、カード所有者として名簿にある顧客に小切手を送ってもよい。
【０１３３】
Ｅウォレット（電子財布）
本発明のさらに他の実施形態において（図示せず）、金融取引システム１００は、顧客がＩＰＳＰ３４から電子トークンを購入できるようにし、プリペイド式の「Ｅウォレット」アカウントを作って、所定の値を参加販売業者３１、３２、３３に対して使用できるように構成されてもよい。種々の実施形態によれば、金融取引システム１００の特徴を、このＥウォレットシステムにも拡張可能である。例えば、販売業者３１、３２、３３が、顧客支払いカードに関連する口座から販売業者口座への資金移動の要求を顧客から受けるのではなく、ＩＰＳＰ３４が、顧客のＥウォレットアカウントからＩＰＳＰの口座への資金移動の要求を受け取る。一実施形態によれば、ＩＰＳＰ３４は、販売業者モジュール２００及びＩＰＳＰモジュール３００の各ステップを実行して、カード発行銀行に対する許可及び決済要求を発行し、処理する。決済が行われると、ＩＰＳＰ３４は、移動した資金の額を表す電子トークンの金額分、顧客のＥウォレットアカウントにクレジットを与える。顧客は参加販売業者３１、３２、３３に対してトークンを使用し、購入を行うことができる。ＩＰＳＰ３４は、定期的に（例えば、毎日又は毎週）各販売業者のウェブサイトで使ったトークンの金額に対応する資金を各販売業者３１、３２、３３に移動する。一実施形態において、ＡＳＰ３５はＥウォレットアカウントを管理し、ＩＰＳＰ３４から参加販売業者３１、３２、３３に支払いを割り当てる。
【０１３４】
種々の実施形態のＥウォレットシステムは、販売業者と顧客との取引の促進に加えて、顧客のプライバシー保護にも役立つ。例えば、顧客が、ある販売業者との取引のためにやりとりを行うとき、顧客はプリペイド式のＥウォレットアカウントを使用しているので、多くの販売業者は、顧客のＥウォレットアカウントに関する情報以外に顧客に関する情報をさらに求めることがない。その結果、販売業者は顧客の身元を直接知ることがない。販売業者は、顧客のＥウォレットアカウントを把握し、全ての取引を顧客のＥウォレットアカウントに対して直接行うだけである。
【０１３５】
また、他の種々の実施形態において、検証システムを用いて顧客の身元を保護することができる。例えば、一実施形態の金融取引システム１００は検証システムの拡張可能であり、検証システムが、顧客識別のためのトークン等、固有の個人識別子を販売業者に与える。したがって、顧客は検証システムで登録を行い、検証システムは、顧客が正当であるという、ある程度の保証を販売業者に与える。その結果、顧客の身元は保護され、販売業者は、顧客のトークン以外に顧客に関する情報をさらに求めることなく、顧客との取引に、ある程度の信用を持てる。
【０１３６】
上述の説明及び添付図面に示す教示を考慮すると、本発明が属する技術分野の技術者にとっては、本発明の多くの変形例や他の実施形態は明らかであろう。したがって、本発明は開示した具体的な実施形態に限定されず、変形例や他の実施形態も添付の請求の範囲の主旨に含まれるものとする。具体的な用語を用いて説明したが、これらは一般的かつ説明的な意味で使用したにすぎず、限定を目的とするものではない。
【図１】
0005663487.tif 000002
【図２】
0005663487.tif 000003
【図３Ａ】
0005663487.tif 000004
【図３Ｂ】
0005663487.tif 000005
【図４】
0005663487.tif 000006
【図５】
0005663487.tif 000007
【図５Ａ】
0005663487.tif 000008
【図６】
0005663487.tif 000009
【図７Ａ】
0005663487.tif 000010
【図７Ｂ】
0005663487.tif 000011
【図８】
0005663487.tif 000012
【図９Ａ】
0005663487.tif 000013
【図９Ｂ】
0005663487.tif 000014
【図１０Ａ】
0005663487.tif 000015
【図１０Ｂ】
0005663487.tif 000016
【図１１】
0005663487.tif 000017
【図１２】
0005663487.tif 000018
【図１３】
0005663487.tif 000019
【図１４】
0005663487.tif 000020
【図１５】
0005663487.tif 000021
【図１６】
0005663487.tif 000022
【図１６Ａ】
0005663487.tif 000023
【図１７】
0005663487.tif 000024
【図１８】
0005663487.tif 000025