(58)【調査した分野】(Int.Cl.,DB名)
前記プロセッサは、当該取引が不正の可能性がある取引として指定されたことに応じて、不正行為防止モジュールを実行して、当該取引に関連する情報を不正行為データベースに記憶するように構成されることを特徴とする請求項1に記載のシステム。
さらに、当該取引が不正の可能性がある取引として指定されたことに応じて、当該取引に関連する情報を不正行為データベースに記憶するために前記一つ以上のコンピュータプロセッサが構成されることを特徴とする請求項6に記載の方法。
前記プロセッサは、当該要求が不適切である可能性がある要求として指定されたことに応じて、不正行為防止モジュールを実行して、顧客とオンライン販売業者との間で行われることを否認するように構成されることを特徴とする請求項11に記載のシステム。
【発明を実施するための形態】
【0016】
以下、添付図面を参照し、本発明の種々の実施形態についてより詳細に説明する。図面は、本発明の実施形態のすべてを示すものではなく、幾つかの実施形態を示す。本発明は、多数の異なる形態で実施することができ、以下に記載する実施形態に限定されるものではない。これらの実施形態は、本開示が適用可能な法的要件を満たすように記載されている。本明細書において同様の符号は同様の構成要素を示す。
【0017】
概略
一般に、本発明の種々の実施形態は、電子商取引部門のための改良された金融取引システムを提供し、このシステムは、(1)支払い取引をより安全に処理し、(2)不正取引、マネーロンダリング、未成年のギャンブルから販売業者と銀行を保護するのに役立ち、(3)インターネット上のゲーム、旅行、消費者による電子商品購入等、特別なリスクを生じると考えられる電子商取引分野での他の悪用を制限するのに役立ち、(4)このような取引に関連したプロセスや情報を統合して、データ記憶容量の低減、及び/又は、コンピュータ処理容量の低減を実現するのに役立つ。「取引」という用語は、二者間での事業上の契約又はやりとりを意味するのに用いる。例えば、取引の例には、販売業者に対して顧客を登録すること、賭け金を賭けること、入金を行うこと、支払いを行うこと、及び/又は、取消を行うことが含まれる。上述の目的を達成するために、金融取引システムの種々の実施形態では、(1)販売業者、インターネット支払いサービスプロバイダ、提携銀行、カードスキームのための、業務及び取引処理プロトコルを設けるとともに、(2)支払い及び関連金融取引の監視と処理を行う改良型自動システムを提供する。
【0018】
例えば、本発明の種々の実施形態において、各販売業者にローリングリザーブ・エスクロー口座を設置し、提携銀行又はカード発行銀行の損失の危険を低減するようにエスクロー口座に資金提供を行う。例えば、一実施形態によれば、販売業者が受け取ったペイバック要求(例えば、チャージバックや払い戻し要求)を処理するのに使用可能な十分な資金があることを確保することにより、この損失の危険を低減する。一実施形態によれば、販売業者に支払われた資金のうち、ある割合の資金が、一定期間(例えば、6カ月、1年、3年)エスクロー口座に留保及び移動させられ、その期間、その資金が使用されなければ、資金を販売業者に戻す。ローリングリザーブ・エスクロー口座に提供する資金は、販売業者の潜在的利益から取られるため、販売業者の事業をマネーロンダリングの手段として使うことは魅力がない。また、種々の実施形態によれば、販売業者がチャージバック要求に対して異議を唱えることが可能な根拠としては、許容可能な異議の根拠によって提携銀行又はカード発行銀行の損失の危険が著しく大きくならないように限定されている(例えば、不正行為フラグで示された取引)。他の実施形態において、販売業者は、どのような根拠でもチェックバック要求に異議を唱えることができない。このように、種々の実施形態によれば、ローリングリザーブ・エスクロー口座により、ペイバック要求の処理のための資金源が確保される。これにより、顧客の損失の危険が少なくなるとともに、顧客がオンライン金融取引に参加する可能性が高くなる。さらに、ペイバック要求の資金が販売業者により提供される場合、提携銀行やカード発行銀行の損失の危険が少なくなり、販売業者にとってより好ましい事業条件が得られる(例えば、取引レートの低下やチャージバック率の低下)。
【0019】
他の例として、本発明の種々の実施形態において、この金融取引システムの参加者は、当該地域の規制当局に対するコンプライアンスを互いに求める。例えば、一実施形態において、販売業者がコンプライアンスを怠っている場合、インターネット支払いサービスプロバイダ(以下に詳細に説明する)、提携銀行、カードスキームは、その販売業者との事業を否認してもよい。また、一実施形態において、参加者はコンプライアンスを怠る参加者に対して罰金を科してもよい。さらに、顧客も、コンプライアンスを怠る販売業者との商取引を否認してもよい。このプロトコルを設けることにより、金融取引システムは、当該地域の規制当局に対するコンプライアンスを参加者に続けさせるような市場インセンティブを与えることが多い。
【0020】
本発明の種々の実施形態によれば、この金融取引システムの参加者には、オンライン顧客、オンライン販売業者、インターネット支払いサービスプロバイダ(IPSP)、提携銀行、カード発行銀行、あるいは、カードスキームが含まれる。IPSPは販売業者と提携銀行との間で業務を行い、販売業者に対して支払い関連サービスを提供し、ネットワークを介して販売業者と提携銀行との仲介役となる。また、IPSPは、アカウンティングサービスプロバイダ(ASP)と連絡を取り、IPSPが販売業者に提供する支払いサービスに関連した会計管理サービスを提供させる。
【0021】
図1は、本発明の種々の実施形態による、種々の参加者が互いにやりとりを行う様子を示す高レベルブロック図である。例えば、参加者はネットワーク(例えば、インターネット、プライベートネットワーク、プライベートLANネットワーク)を介して、取引情報を電子的に交換することができる。特に、取引情報には、顧客の支払いカードに関連する口座から販売業者の口座に資金を移動するための販売業者からの許可要求、顧客の口座から販売業者の口座への資金の移動を許可するカード発行銀行からの許可メッセージ、販売業者の口座から顧客の口座への資金移動を要求するカード発行銀行からのペイバック要求(例えば、チャージバック又は払い戻し要求)、特定期間(例えば、24時間、48時間、1週間)に処理されたすべての取引についての各販売業者に対する決済要求が含まれてもよい。
【0022】
上述の実施形態では、オンライン販売業者から商品やサービスを購入するための口座に関連する支払いカード(例えば、デビットカード、クレジットカード、プリペイドカード、近接型ICカード)を使用することを説明したが、他の種々の実施形態において、他の種類の支払い方式を用いて購入を行ってもよい。例えば、他の支払い方式として、ある口座に関連する支払いトークン(例えば、物理的トークン又は電子トークン)を使用したり、ある口座に関連する番号(例えば、口座番号や口座にアクセスするためのパスワード)を使用したりしてもよい。また、他の支払い方式として、ある口座に関連する虹彩スキャン、指紋、音声認識等の生体認証データを使用して、支払いを許可してもよい。また、口座番号と、トークン、電話、電子メール、ショートメッセージサービス(SMS)により得られる1回限りのパスワードとを組み合わせて、支払いを許可してもよい。
【0023】
上記で簡単に説明したが、種々の実施形態による金融取引システムは、(1)参加者のための業務及び処理プロトコルと、(2)高いセキュリティレベルで金融取引を処理するように構成された自動監視及び処理システム(例えば、コンピュータソフトウェア及び/又はハードウェア)を提供する。これらプロトコル及び自動システムは、電子商取引における不正取引や危険を生じる可能性のある他の悪用行為から顧客や参加者を保護するのに役立つ。このシステムにより実行されるプロトコルの種々の例について、以下のセクションAで詳細に説明する。自動システムの種々の実施形態については、以下のセクションBで説明する。この金融取引システムで処理される種々の取引の例示的な流れについては、セクションCでより詳細に説明する。
【0024】
A.プロトコルの例
この金融取引システムの種々の実施形態では、参加者のための業務及び処理プロトコルを提供する。種々の実施形態によれば、プロトコルは、販売業者の事業を利用した組織犯罪やマネーロンダリングの手段を抑止し、オンライン金融取引に関連することが多い不正取引や無許可取引の危険を減らし、提携銀行やカード発行銀行の損失の危険を低減し、国又は地域の規制へのコンプライアンスが得られる可能性を高めるのに役立つ。例えば、本発明の種々の実施形態によれば、参加者は、当該地域又は管轄地域の規制当局に対するコンプライアンスを示すことができなければならず、かつ、特定期間(例えば、2年、3年、5年)に処理された取引の監査可能な記録を保持しなければならない。また、プロトコルにより、各参加者は、他の参加者との契約を行う前に当該地域の規制要件に対するコンプライアンスを示さなければならない、としてもよい。また、プロトコルにより、参加者は、当該地域の規制当局において他の参加者が高く評価されていることを定期的に確認しなければならない、としてもよい。販売業者及びIPSPに関して設けることできるプロトコルの種々の例を以下に説明する。
【0025】
販売業者
本発明の種々の実施形態によれば、販売業者が、管理職、役員、受益株主の身元を十分に開示し、変更があればIPSPにその変更を報告しなければならない、としてもよい。このリストの提供を求め、このリストと、組織犯罪にかかわっていると考えられている人物や団体のリストを比較することで、組織犯罪グループが販売業者の事業をマネーロンダリングや他の違法目的に利用することを抑止するのに役立つ。
【0026】
また、本発明の種々の実施形態によれば、販売業者が、不正取引による提携銀行、カード発行銀行、顧客への損失の危険を減らすような1以上の手段を取らなければならない、としてもよい。例えば、種々の実施形態によれば、販売業者が、(1)すべての関連規制要件に対するコンプライアンスを示し、(2)契約上の義務を怠った場合は罰金を支払い、(3)販売業者の演算装置上で住所確認、年齢確認、身元確認ソフトウェアを用いて、オンライン取引の際に得られた支払い情報及び顧客情報を確認し、(4)得られた支払い及び顧客情報に対して初期不正チェックを行い、その後はランダム又は定期的にチェックを行い、あるいは、(5)IPアドレスを用いてシステムにアクセスしている顧客、又は、当該取引が違法とされる管轄地域に関連する請求先住所を提出する顧客に対して、通知を行わなければならないようにしてもよい。
【0027】
さらに、種々の実施形態によれば、販売業者は、販売業者の事業に関連する悪用の危険があれば、その危険を少なくし、販売業者と事業を行うことにより社会的影響(例えば、販売業者がオンラインゲーム販売業者又は成人向け娯楽提供者である場合の強迫的消費行動)があると思われる場合、その影響を少なくするプロトコルを実施しなければならない、としてもよい。例えば、販売業者が、その事業の社会的影響に関する助言や相談の手段(例えば、電話相談のフリーダイヤル番号、役立つ情報を提供しているウェブサイト、カウンセラーの連絡先情報)を提供しなければならない、としてもよい。さらに、一実施形態によれば、顧客がカスタマーサービスに電話をして取引についての問い合わせることができるように、販売業者が、顧客の支払いカードの請求書に販売業者名とフリーダイヤル番号を記載しなければならない、としてもよい。本発明の種々の実施形態によれば、カスタマーサービスの代表連絡先は、1日24時間、週7日いつでも連絡を取ることができるものとする。
【0028】
IPSP
本発明の種々の実施形態によれば、IPSPが、以下のセキュリティ機能のうちの1つ以上を実行して、組織犯罪グループ等が販売業者の事業をマネーロンダリングに利用するのを抑止し、オンライン金融取引に関連する種々の参加者への危険を低減しなければならない、としてもよい。すなわち、(1)ペイバック要求の処理の対象となる各販売業者に対して、上述のエスクロー口座等のローリングリザーブ・エスクロー口座を設置する、(2)取引を監視して、不審な活動を判別する、(3)支払いカード毎に取引の頻度と金額を監視する、(4)追跡及び監査を目的として、各販売業者(又はウェブサイト)の取引をそれぞれ個別のストリームとして保持する、(5)取引情報を定期的に(例えば、2秒毎、10秒毎)に保存して監査証跡を作成し、特定期間(例えば、1年、2年、5年)取引情報を記憶する、(6)カード所有者の身元を確認する、(7)管理職や受益株主をIPSPに開示するように販売業者に求める、(8)インターネットギャンブル業者からカード所有者への賞金支払いを制限し、適用可能な制裁対象リスト(例えば、米国の「特別指定国民リスト」(Specially Designated Nationals list))を用いて受取人名のスクリーニングを行う、(9)販売業者のライセンス付与を、適用可能な地域の法律や規則に従って行い、財政面及び法的面での良好な評価を保つように求める、(10)契約上の義務を怠ったとされる販売業者を罰する(例えば、販売業者との契約を停止する、あるいは、販売業者に罰金を科す)、(11)規制が適正に行われている管轄地域で業務を行うティア1の提携銀行を利用し、それらの提携銀行から証明を受ける、(12)カード所有者情報の安全を維持するためのポリシー、手続き、規格(例えば、VISAカードのアカウント情報セキュリティ(AIS)プログラム)を実施するように販売業者に求める、(13)マネーロンダリングに関する金融活動作業部会(Financial Action Task Force on Money Laundering)(例えば、www.FAFT-GAFL.org;例えば、国際通貨基金(IMF)が公表した「マネーロンダリング防止/テロ資金調達対策法(FATF40+9を含む)」、付録Aとして添付)の勧告の管理及び適用を行う、という機能である
。また、種々の実施形態において、IPSPは、IPSPが処理した取引で、不正であると思われる取引又は不正であると判断された取引についての情報を記憶するための、
図1に示す不正行為データベース42を維持する。一実施形態によれば、IPSPにより、他の参加者は取引の処理の際に不正行為データベースを利用することができ、カード発行銀行、提携銀行、販売業者、顧客の損失の危険をさらに減らすことができる。IPSPは、自身の会計処理及び不正行為データベースを管理し、処理する取引の照合確認を行って、販売業者に対する照合レポートを作成することができるが、他の実施形態によれば、IPSPは、アカウンティングサービスプロバイダ(ASP)と契約を結び、これらのサービスの1以上を提供してもよい。さらに、種々の実施形態において、IPSPは、顧客についての情報を記憶するための顧客情報データベース50を維持する。
【0029】
また、本発明の一実施形態によるプロトコルの例として、IPSPが各販売業者について個別の法人(例えば、SG1、SG2、SG3等)を作り、これらの法人がIPSP及び/又はASPの指示のもとに運営を行い、当該法人に関連する特定の販売業者について受け取った資金を管理するようにしてもよい。これについては
図14を参照して詳細に説明する。種々の実施形態によれば、この企業構成により各販売業者の運営がそれぞれ個別化される。また、種々の実施形態によれば、この企業構成により、金融取引システムと顧客の保護のために保持しているエスクロー資金を、確実に公正かつ客観的に管理することができる法的構造が得られる。
【0030】
提携銀行
本発明の種々の実施形態によれば、プロトコルの例として、提携銀行が以下のセキュリティ機能のうちの1つを実行して、カード発行銀行及び顧客に対するオンライン取引関連の危険を低減するようにしてもよい。すなわち、(1)オンライン販売業者のクレジット活動を監視して、顧客が販売業者から賞金やクレジットを自分の支払いカードで確実に受け取れるようにする(例えば、VISAカード主催のカード所有者資金移動(CFT)プログラムや、マスターカード主催のマネーフロー・プログラム)、(2)すべてのカードスキームの規則がIPSP及び販売業者に確実に伝わるようにする、(3)取引情報が確実に、カードスキーム及びカード発行銀行により規定されるような適正なデータ構成要素を含んでいるようにする、(4)適用可能な規制方式に対するIPSPのコンプライアンスを確保する、という機能である。
【0031】
参加者間の契約
本発明の種々の実施形態によれば、1以上のシステムプロトコルを参加者間の契約に組み込んで、設けられたプロトコルに対するコンプライアンスを確保してもよい。例えば、
図2は、本発明の種々の実施形態による参加者間の契約関係を示す概略図である。具体的には、提携銀行36、IPSP34、各販売業者31、32、33が、取引の処理のしかたに関する各関係者の義務を示す三者間処理契約45を結んでもよい。この契約45では、各関係者は、当該地域規制当局からの良い評価を受け続け、役員、管理職、受益株主の最新リストを他の関係者に提供し、取引情報に対して何らかの身元確認及び不正行為チェックを行い、監査のために取引情報を所定期間(例えば、1年間、3年間、5年間)保存しなければならない。また、一実施形態によれば、契約45には、販売業者がチャージバック要求に異議を唱えることができる1以上の根拠が含まれてもよい。他の実施形態によれば、契約45は、チャージバックの際に販売業者31、32、33に課すことできる料金を設定してもよい。
【0032】
また、提携銀行36とIPSP34は、IPSPが取引データに対して行うべき特定の不正行為チェックと、IPSPがいつ各販売業者に代わって決済を要求すべきか(例えば、毎日、毎週)を示す信託契約47を結んでもよい。
【0033】
ASP35と各販売業者31、32、33は、ASPがどのように販売業者に代わってローリングリザーブ・エスクロー口座を管理するかを示すエスクロー契約49を結んでもよい(例えば、エスクロー口座に取られる資金の割合、資金がエスクロー口座に保管される期間、照合レポートの形式)。
【0034】
さらに、ASP35とIPSP34は、ASPがIPSPに提供するアカウンティングサービスに関して各関係者の義務を示すサービス契約43を結んでもよい(例えば、ASPとIPSPの間で交換されるデータの形式及びアクセス性、IPSP34のため又はIPSP34に代わってASPが作成する概要報告書の種類と形式、1以上の参加者に対して支払い可能な料金の計算、あるいは、販売業者についての照合レポートを承認するための承認手続き)。また、一実施形態において、契約43により、IPSP34が処理した取引又はIPSP34に代わってASP35が処理した取引についての販売業者31、32、33からの問い合わせに対して、ASP35が応答しなければならない、としてもよい。さらに、他の実施形態において、ASP35は、(1)IPSP34に代わってASP35が処理したチャージバック要求に関する取引データをすべて識別し、(2)識別したデータを販売業者31、32、33に転送して、チャージバック要求に関して販売業者31、32、33がさらに何らかの行動を望む場合、それを確かめなければならない、としてもよい。
【0035】
(B.取引の自動監視及び処理システム)
当該分野の技術者ならばわかるであろうが、本発明は、方法、取引処理システム、又はコンピュータプログラム製品として実施することもできる。したがって、本発明は、全体がハードウェアによる実施形態、全体がソフトウェアによる実施形態、又は、ソフトウェアとハードウェアの側面を組み合わせた実施形態であってもよい。さらに、本発明は、コンピュータにより読み取り可能なプログラムインストラクション(例えば、コンピュータソフトウェア)を記憶媒体において組み込まれる、コンピュータにより読み取り可能な記憶媒体上のコンピュータプログラム製品であってもよい。より具体的には、本発明は、ウェブ上で実行されるコンピュータソフトウェアであってもよい。ハードディスク、CD−ROM、光記憶装置、磁気記憶装置等、コンピュータにより読み取り可能な記憶媒体であれば、いずれの媒体も用いることができる。
【0036】
以下、本発明の一実施形態による方法、装置(すなわち、システム)、コンピュータプログラム製品のブロック図及びフローチャートを参照して、本発明について説明する。なお、ブロック図及びフローチャートにおける各ブロックや、ブロック図及びフローチャートにおける各ブロックの組み合わせは、それぞれ、コンピュータプログラムインストラクションにより実行することができる。これらコンピュータプログラムインストラクションを、汎用コンピュータ、専用コンピュータ、又は、他のプログラミング可能なデータ処理装置に読み込んで、コンピュータ又は他のプログラミング可能なデータ処理装置上で実行するインストラクションによって、フローチャートの1又は複数のブロックにて特定される機能の実行手段を生成するような機器を構成してもよい。
【0037】
これらコンピュータプログラムインストラクションをコンピュータにより読み取り可能なメモリに記憶して、コンピュータにより読み取り可能なメモリに記憶されたインストラクションによって、フローチャートの1又は複数のブロックにて特定される機能を実行するための、コンピュータにより読み取り可能なインストラクションを含む製品が得られるような特定の方法で、コンピュータ又は他のプログラミング可能なデータ処理装置を機能させるように指示を与えてもよい。コンピュータプログラムインストラクションをコンピュータ又は他のプログラミング可能なデータ処理装置に読み込んで、コンピュータ又は他のプログラミング可能な装置上で一連の動作ステップが行われるようにし、コンピュータ又は他のプログラミング可能な装置上で実行されるインストラクションによって、フローチャートの1又は複数のブロックにて特定される機能の実行ステップが得られるようなコンピュータ実行処理を生成してもよい。
【0038】
したがって、ブロック図及びフローチャートにおけるブロックは、特定の機能を行う手段の組み合わせ、特定の機能を行うステップの組み合わせ、及び、特定の機能を行うプログラムインストラクション手段に対応している。なお、ブロック図及びフローチャートにおける各ブロック、及び、ブロック図及びフローチャートにおける複数ブロックの組み合わせは、特定の機能又はステップを行う専用ハードウェアによるコンピュータシステム、あるいは、専用ハードウェア及びコンピュータインストラクションの組み合わせにより実行することができる。
【0039】
本明細書で説明する種々の実施形態において、「コンピュータ」又は「演算装置」という記載がある。このようなコンピュータは、例えば、メインフレーム、デスクトップ、ノートパソコン、又は、データ取得及び記憶装置等のハンドヘルド装置であってもよく、また、例えば、無線電話等の他の装置内に組み込まれる処理装置であってもよい。幾つかの例において、このコンピュータは、ネットワークを介してデータやプロセッサにアクセスするのに使用される「ダム端末(単能端末)」であってもよい。
図3Aを参照して、本発明の種々の実施形態の各側面を実施するのに用いることができる演算装置の一実施形態について説明する。
図3Aにおいて、マイクロプロセッサ等のプロセッサ1は、所定のステップを行うためのソフトウェアインストラクションを実行するのに使用される。プロセッサは電源17から電力供給を受け、電源17は必要に応じて他の構成要素にも電力を供給する。プロセッサ1は、一般に16又は32ビット幅(例えば、パラレル)のデータバス5を用いて通信を行う。データバス5は、一般にプロセッサとメモリの間でデータやプログラムインストラクションを伝達するのに使用される。種々の実施形態において、メモリは、RAM、又は、動作中のみコンテンツを保持する他の形態のメモリである一次メモリ2とすることができるが、ROM、EPROM、EEPROM、フラッシュメモリ、あるいは、常時メモリコンテンツを保持する他のメモリ等、不揮発性メモリ3であってもよい。メモリは、大量のデータを記憶するディスク記憶装置等の二次メモリ4であってもよい。また、幾つかの実施形態において、ディスク記憶装置は、I/Oバス6又は専用バス(図示せず)を用いてプロセッサと通信を行ってもよい。二次メモリは、フロッピー(登録商標)ディスク、ハードディスク、コンパクトディスク、DVD、あるいは、コンピュータ分野の技術者にとって既知の大容量記憶型の他のメモリであってもよい。
【0040】
プロセッサ1は、I/Oバス6を用いて種々の周辺機器や外部装置と通信を行う。種々の実施形態において、周辺I/Oコントローラ7を用いて、種々の入出力装置に対するインターフェースとして適切なRS−232、RS422、DIN、USB、その他のインターフェース等、標準インターフェースを設ける。一般的な入出力装置は、ローカルプリンタ18と、モニタ8と、キーボード9と、マウス10又は他の一般的なポインティングデバイス(例えば、ローラボール、トラックパッド、ジョイスティック等)とを備える。
【0041】
プロセッサ1は、一般に、通信I/Oコントローラ11を用いて外部通信ネットワークと通信を行い、X.25、ISDN、DSL、ケーブルモデム等のデータ通信向きプロトコル12等、種々のインターフェースを用いてもよい。通信コントローラ11は、標準電話線13とのインターフェース提供及び通信を行うためのモデム(図示せず)を組み込んでもよい。さらに、通信I/Oコントローラは、LANを介した通信のためのイーサネット(登録商標)インターフェース14を組み込んでもよい。これらのインターフェースはいずれも、インターネット、イントラネット、LAN、その他のデータ通信設備等、広域ネットワークにアクセスするのに使用してもよい。
【0042】
さらに、プロセッサ1は、例えば、IEEE802.11プロトコル、802.15.4プロトコル、あるいは、CDMA20001xEV−DO、GPRS、W−CDMA等の標準3G無線通信プロトコル、その他のプロトコルのうちのいずれかを用いて、他の装置と無線通信を行うためのアンテナ15に接続して動作する無線インターフェース16と通信を行ってもよい。
【0043】
使用できる処理システムの他の実施形態を
図3Bに示す。この実施形態では、ローカルクライアントコンピュータ26a又はリモートクライアントコンピュータ26bのいずれか一方と通信を行うサーバ20を備えた分散型通信及び処理構成を示す。サーバ20は、一般に、二次メモリの一種として考えられるデータベース22(例えば、SQLデータベース)及び一次メモリ24と通信を行うプロセッサ21を備える。プロセッサは、一般にLAN25とのインターフェースとなるI/Oコントローラ23を用いて、外部装置との通信も行う。LANは、ネットワーク接続したプリンタ28及びローカルクライアントコンピュータ26aとのローカル接続を行ってもよい。これらは、必ずしも同じ部屋の中でなくてもよいが、サーバと同じ設備内に配置されてもよい。リモート装置との通信は、一般に、データをLAN25から通信設備を介してインターネット等の広域ネットワーク27にルーティングすることにより達成される。リモートクライアントコンピュータ26bはウェブブラウザを実行してもよく、ウェブブラウザにより、リモートクライアントコンピュータ26bは、広域ネットワーク27を介してLAN25上及びサーバ20へのデータ送信を行うことにより、必要に応じてサーバとインタラクションを行うことができる。また、ウェブブラウザは、例えば、JavaScriptやMicrosoft.netで開発されたユーザインターフェースを備えてもよい。
【0044】
データネットワーキング分野の技術者であれば、多数の他の代替手段や構成が可能であり、それらを本発明の種々の実施形態に使用することができるとわかるであろう。
図3A及び
図3Bに示す実施形態は、種々の変更が可能であり、本発明の範囲内とすることができる。
【0045】
図4は、本発明の種々の実施形態による各参加者に関連し、1以上のネットワーク115(例えば、プライベートネットワーク、プライベートLANネットワーク、インターネット)を介して互いに通信を行う演算装置101〜109を示す。例えば、一実施形態によれば、IPSP34は、IPSPゲートウェイ40を介して販売業者31、32、33及び提携銀行36からアクセス可能なIPSPネットワークを確立してもよく、IPSPゲートウェイ40は、販売業者31、32、33及び提携銀行36が利用するネットワークにこのIPSPネットワークを接続する。種々の実施形態によれば、IPSPゲートウェイ40は、完全にハードウェアとして、あるいは、完全にソフトウェアとして、あるいは、両者の組み合わせとして実現してもよい。一実施形態において、IPSPゲートウェイ40は、IPSPネットワークへのアクセスを選択的に許可することにより、IPSP34との情報の送受信のセキュリティを確保する。例えば、IPSP34と契約関係がない販売業者31、32、33又は提携銀行36は、IPSPゲートウェイ40によりIPSPネットワークへのアクセスを拒否される場合がある。さらに、1以上の記憶装置が1以上のネットワーク115と通信を行ってもよい。これらの記憶装置は、サーバ、ハードディスク、光ディスク、磁気テープ、フラッシュメモリ等のうちの1種類以上の装置、又は、これらの組み合わせとしてもよい。また、種々の実施形態において、これらの記憶装置は1以上のデータベースを含んでもよい。例えば、IPSP34及び/又は販売業者31、32、33は、1以上の記憶装置にある1以上の第三者データベース116、117と通信を行ってもよい。さらに、1以上の第三者システム118が1以上のネットワーク115と通信を行ってもよい。
【0046】
また、提携銀行36は、カードスキームネットワークを利用して、本発明の種々の実施形態によるカード発行銀行37、38、39と情報を交換することができる。カードスキームネットワークの例として、VISAカード、マスターカード、アメリカン・エキスプレスのネットワークがあるが、これらに限定されるものではない。
【0047】
図3A及び
図3Bを参照して上述したように、種々の実施形態によれば、販売業者31、32、33、IPSP34、ASP35、提携銀行36、カード発行銀行37、38、39は、1以上の演算装置(例えば、1以上のサーバ、SQLサーバ、ウェブサーバ)と関連しており、これら演算装置のうちの1以上が金融取引の自動処理システムを備えていてもよい。例えば、システム100は、販売業者のシステム101、102、103で動作するように構成された販売業者モジュール200と、IPSPのシステム104で動作するように構成されたIPSPモジュール300と、ASPのシステム105で動作するように構成されたASPモジュール400とを提供する。これらモジュール200、300、400は、一実施形態によれば、各参加者の処理機能を自動化する。これらのモジュールは、完全にハードウェアとして、あるいは、完全にソフトウェアとして、あるいは、両者の組み合わせとして実現してもよい。
【0048】
また、一実施形態によれば、IPSP34がアカウンティング関連サービスを提供する契約をASP35と結ぶ場合、ASPモジュール400をASPシステム105で動作するように構成してもよい。また、他の実施形態において、ASPモジュール400をIPSPのシステム104で動作するように構成してもよい。これらモジュールの種々の実施形態について、
図5〜
図8を参照して以下に詳細に説明する。
【0049】
販売業者モジュール
図5は、本発明の種々の実施形態による販売業者モジュール200のブロック図である。種々の実施形態によれば、販売業者モジュール200は、販売業者システム101、102、103にて動作し、取引を処理するために販売業者が行うステップのうちの少なくとも一部を自動化する。例えば、販売業者モジュール200は、ステップ202として示す許可要求の処理を行うように構成される。ステップ202にて、販売業者モジュール200は顧客から支払い情報を受け取る。支払い情報には、顧客のフルネームと、請求先住所、電子メールアドレス、クレジットカード番号、CVV2番号、支払い額、カード発行会社名の一部又はすべてが含まれてもよい。そして、販売業者モジュール200は、クレジットカード番号が有効な番号であるかどうか、また、すべての項目が完了しているかどうかを確認する等、受け取った支払い情報の形式を確認する。さらに、販売業者モジュール200は、以前に記憶した3D安全ソフトウェアプラグイン・サービス(例えば、VISA認証サービス(Verified by VISA)や、マスターカードのセキュアコード(SecureCode))に関連する識別情報とパスワードと顧客情報を比較する。形式が正しければ、販売業者モジュール200は許可要求を発行し、さらなる処理を行うためにIPSPシステム104に許可要求を送る。
【0050】
本発明の種々の実施形態によれば、販売業者モジュール200は、ステップ206として示すように、受け取った取引要求に対して初期不正行為チェックを行うように構成される。初期不正行為チェックステップ206では、そのクレジットカード番号を、盗難クレジットカード番号リストと比較したり、顧客から提供された請求先住所が支払いカードの請求先住所と一致していることを確認したり、提供された請求先住所を、販売業者への最初の登録時に顧客から提供された請求先住所と比較したり、あるいは、カード発行会社名が、例えば、カードのバンキング識別番号(BIN)と一致することを確認してもよい。また、不正行為チェックステップ206は、
図5に示すように、許可要求をIPSPに送信した(ステップ202)後に行ってもよく、あるいは、許可要求の発行及び送信の前に行ってもよい(図示せず)。一実施形態において、不正行為チェックステップ206は、許可要求送信(ステップ202)後で、カード発行銀行における決済前に行う。
【0051】
不正行為チェックステップ206にて潜在的な問題が検知されない場合、販売業者モジュール200は、ステップ210として示す顧客の年齢及び身元確認を行う。例えば、有権者登録記録や運転免許証記録等、カード所有者についての行政上の記録を調べることにより、あるいは、電子的年齢及び/又は身元確認サービス(例えば、英国に拠点を置くGBグループが提供する「URU」サービス)とネットワーク接続を確立し、顧客の情報をこのサービスに提供することにより、年齢を確認してもよい。種々の実施形態によれば、このサービスは顧客の情報を行政上又は他の公的記録と比較して、顧客の身元及び年齢を確認する。一実施形態において、販売業者モジュール200は、顧客が販売業者に対して新たな口座を設置するときに、年齢及び身元確認ステップ210を行ってもよい。
【0052】
より具体的には、種々の実施形態の販売業者モジュール200は、顧客熟知(KYC(know-your-customer))サブモジュール500により構成されてもよい。したがって、
図5Aは、本発明の種々の実施形態によるKYCサブモジュール500のブロック図である。例えば、顧客は、生年月日等、ある程度の個人情報を提供する。この個人情報は、販売業者モジュール200が許可要求を受け取るとき、あるいは、その前の時点、例えば、顧客が販売業者に対して新たな口座を設置するときに収集してもよい。また、この情報をメモリに記憶してもよい。例えば、販売業者モジュール200は、販売業者と通信を行うデータベース(例えば、
図1に示す販売業者3 33と通信を行うデータベース51)に、この情報を記憶してもよい。この場合、ステップ510にて、KYCサブモジュール500は、この情報を受け取り(例えば、メモリに情報を問い合わせる)、顧客の個人情報を1以上の個人情報データベースと比較して、情報の妥当性を確保にする。この1以上の個人情報データベースは、販売業者モジュール200からアクセス可能なシステム内の販売業者がまとめてもよく、商業上利用が可能な種々の第三者データベースを備えてもよい。例えば、これらデータベースは、KYCサブモジュール500がネットワークを介して遠隔的にアクセスする行政のデータベースであってもよく、あるいは、販売業者システムのうちの1つ、例えば販売業者システム100内に配置されるデータベースであってもよい。さらに、種々の実施形態において、販売業者モジュール200は、情報をローカルデータベースに記憶する前に情報のスクラブ及び/又はフォーマット化を行い、情報がKYCサブモジュール500及び/又はこの情報を利用する他のモジュールにとってより有用となるようにしてもよい。
【0053】
種々の実施形態において、顧客は、ある範囲で自己の個人情報を提供することができる。例えば、顧客は、フルネーム、生年月日、電話番号、電子メールアドレス、住所、社会保障番号、運転免許証番号、パスポート番号を含む情報を提供してもよい。ステップ520にて、KYCサブモジュール500は、顧客の個人情報に基づいて、有権者登録記録や運転免許証記録等、種々の第三者システムに問い合わせを行い、これら第三者システムは、自システムのデータベース又は他のデータベースに問い合わせて、当該問い合わせで得られた情報のうちの1つ又は複数が、データベースにある情報に対応することを確認してもよい。したがって、種々の実施形態において、得られた一致の数、及び、問い合わせで得られた情報の敏感度(その情報が一般に知られていない度合い)によって、その情報を提供する者が実際にその人物である可能性が高くなる。したがって、ステップ530において、KYCサブモジュール500は、問い合わせの情報の確認と、確認が必要な情報の敏感度に基づいて、顧客が本当にその人物であるかどうかを判断する。KYCサブモジュール500は、顧客の身元が確認されていないと判断する場合、ステップ540として示すように、顧客の身元を否認する(例えば、KYCサブモジュール500は、顧客の身元が確認されていないことを販売業者モジュール200に通知する)。KYCサブモジュール500は、顧客の身元が確認されたと判断する場合、顧客の身元が確認されたことを承認する(例えば、KYCサブモジュール500は、顧客の身元が確認されたことを販売業者モジュール200に通知する)。
【0054】
さらに、種々の実施形態のKYCサブモジュール500は、得られた情報が正しいことを確かめ、販売業者モジュール200が身元確認済みの顧客と取引していることがある程度の確実になると、ステップ560にて、顧客の個人情報に含まれる確認済みの生年月日に基づいて顧客の年齢を計算する。例えば、KYCサブモジュール500は単に現在の日付から生年月日を減算するか、上述のような方法を用いる。その結果、種々の実施形態の販売業者モジュール200は、顧客がある取引を販売業者と行うことについて、許可又は制限をすることができる。
【0055】
図5に戻り、以降、ステップ210の処理を定期的又はランダムに繰り返して、既存の顧客の身元及び年齢を再確認してもよい。また、
図5に示す実施形態では、年齢及び身元確認ステップ210は、不正行為チェックステップ206と許可要求202の後で行うものとして示す。しかし、他の実施形態において、年齢及び身元確認ステップ210は、許可要求ステップ202又は不正行為チェックステップ206の前に行うこともできる。
【0056】
年齢及び身元確認ステップ210にて顧客の年齢及び身元が確認されない場合、あるいは、不正行為チェックステップ206で取引に潜在的な問題があることを検知した場合、一実施形態によれば、販売業者モジュール200は、ステップ208として示すように、取引が否認されたことを顧客に通知し、取引を否認すべきであることをIPSPに通知することができる。
【0057】
また、種々の実施形態による販売業者モジュール200は、特定期間(例えば、セッション毎、24時間、1週間)、販売業者のウェブサイトで費やした時間を顧客に表示するか、他の方法で通知するように構成される。この情報を得ることにより、販売業者のウェブサイトに関する顧客の強迫的行動を回避するための支援ができる。さらに、販売業者モジュール200は、販売業者が維持する顧客用取引ログへの顧客のアクセスを許可するように構成されてもよい。また、販売業者モジュール200は、例えば、損失に対する制限(例えば、ギャンブル取引)、あるいは、販売業者のウェブサイトで費やす時間及び/又は金額等、自主規制ガイドラインを実施するように構成されてもよい。
【0058】
マネーロンダリングからの保護のため、販売業者モジュール200は、マネーロンダリング防止ソフトウェア(例えば、付録Aとして添付した、国際通貨基金(IMF)が公表した「マネーロンダリング防止/テロ資金調達対策法(FATF40+9を含む)」に示されるパラメータと、利用可能なデータを比較するソフトウェア)を実行して、選択された金額(例えば、15,000ユーロ又は20,000ドル)を超える取引をすべて評価するように構成されてもよい。このソフトウェアによる評価では、身元確認及び再確認の後、確認済みの個人又は企業に対してチェックを行ってもよい。
【0059】
IPSPモジュール
図6は、本発明の種々の実施形態によるIPSPモジュール300のフローチャートを示す。一実施形態によれば、IPSPモジュール300は、IPSPシステム104にて動作するように構成される。一実施形態によれば、ステップ302において、IPSPモジュール300は販売業者システム101、102、103から受け取った許可要求を処理する。各許可要求は、特定の取引についての支払い情報と、顧客のフルネーム、顧客の電子メールアドレス、顧客が取引を開始するのに使用する演算装置のIPアドレス等、取引に関連する顧客情報とを含んでいてもよい。本発明の種々の実施形態によれば、IPSPモジュール300は、その後、許可要求を提携銀行システム106に送り、提携銀行システム106は、許可要求を適切なカード発行銀行システム107、108、109に送る。
図9A及び
図9Bを参照して以下に詳細に説明するが、種々の実施形態によれば、IPSPモジュール300は、提携銀行システム106を通してカード発行銀行システム107、108、109から、取引を許可又は否認する許可メッセージを受け取る。IPSPモジュール300は、この許可メッセージを販売業者システム101、102、103に送る。
【0060】
特定の実施形態において、販売業者システム101、102、103に加えて、あるいは、それらの代わりに、上述のようなKYCサブモジュール500をIPSPシステム104に含めてもよい。これら特定の実施形態において、販売業者システム101、102、103のうちのいずれかが、IPSPモジュール300に顧客の個人情報を送り、IPSPモジュール300は、ステップ303として示すようにKYCサブモジュール500を実行する。そして、KYCサブモジュール500は、
図16Aを参照して説明した上述のステップを実行する。したがって、これら特定の実施形態において、KYCサブモジュール500は、多数の販売業者に対して顧客を確認するものである。さらに、これら特定の実施形態において、例えば、
図1に示す顧客情報データベース50等、販売業者システム101、102、103内のメモリに加えて、あるいは、それらの代わりに、IPSPシステム104内にあるメモリに顧客の個人情報を記憶してもよい。
【0061】
種々の実施形態によれば、ステップ304において、IPSPモジュール300は、IPSPモジュール300が処理した取引情報(例えば、許可要求、チャージバック要求、払い戻し要求、決済要求)を記憶する。記憶した取引情報は、監査目的に使用することができ、顧客毎、支払いカード毎、販売業者毎の取引の種類や頻度を監視し、決済要求を発行し、決済要求に応じて受け取った資金の支払い割り当てに使用してもよい。例えば、定期的に、例えば、毎秒又は10秒毎、あるいは、IPSPモジュール300が取引情報を受信して処理する毎等、取引毎に、許可、チャージバック、払い戻しの各要求を記憶してもよい。これらの要求は所定期間(例えば、1日、1週間又はそれ以上)記憶してもよい。また、種々の実施形態によれば、これらの要求を販売業者毎に(あるいは、販売業者が電子商取引に対応するウェブサイトを2以上有している場合、URL毎に)記憶してもよい。IPSPモジュール300は、定期的に(例えば、毎日、毎週)各販売業者に対する許可要求をまとめて、各販売業者についての決済要求ファイルを作成し、販売業者に対する決済要求をバッチファイルとして提携銀行システム106に送り、決済を行ってもよい。これについては、ステップ310を参照して以下に説明する。IPSPモジュール300は、所定期間(例えば、1年、2年、3年)、まとめた取引情報を個別ファイルとして記憶してもよい。
【0062】
また、種々の実施形態において、IPSPモジュール300は、
図6のステップ306として示すとともに
図7A及び
図7Bを参照して以下に詳細に説明する不正行為防止サブモジュール350を実行し、当該取引がシステム100による決済の対象となることを確認するように構成される。例えば、支払いカード番号が盗難に遭った支払いカード番号のリストにある場合、あるいは、顧客のIPアドレスの国が、支払いカードが発行された国とは一致しない場合、あるいは、顧客が国別制裁対象リスト(例えば、米国の「特別指定国民リスト」(Specially Designated Nationals list))に載っている場合、IPSPモジュール300は、決済を行う取引として当該取引を提示しない。
図6に示す実施形態において、不正行為防止サブモジュール350は、許可要求処理ステップ302及び取引情報記憶ステップ304の後に実行されるものとして記載される。しかし、本発明の他の実施形態によれば、ステップ302の提携銀行システム106への許可要求の送信前、又は、ステップ304の取引情報の記憶前に、IPSPモジュール300によりステップ306を行ってもよい。
【0063】
本発明の種々の実施形態によれば、ステップ306にて不正行為防止サブモジュール350が、ある取引について不正行為の可能性があることを検知した場合、IPSPモジュール300は、ステップ308として示すように、不正行為の疑いがあることを適切な関係者に通知するように構成される。種々の実施形態による適切な関係者としては、提携銀行36(カード発行銀行に通知を渡してもよい)、カード発行銀行37、38、39(直接的)、販売業者31、32、33、及び/又は、顧客が挙げられる。また、種々の実施形態によれば、IPSPモジュール300は、ステップ312として示すように、不正行為の可能性がある取引についての情報を不正行為データベース42に記憶するように構成される。不正行為データベース42は、IPSPモジュール300がその後の取引を分析するのに用いることができる。また、一実施形態において、不正行為データベース42は、カード発行会社ネットワーク及び/又は提携銀行が、受信した取引を分析するためにアクセスできるようにしてもよい。さらに、不正行為データベース42には、顧客名、住所、IPアドレス、支払い情報(例えば、カード又は口座番号)、電話番号、以前の不正行為を識別するコード又は記載といった項目のうちの1以上を含まれていてもよい。
【0064】
ステップ310に示すように、ステップ306にて不正行為防止サブモジュール350が不正行為の可能性があることを検知しない場合、種々の実施形態によれば、IPSPモジュール300は決済要求を発行して、提携銀行システム106又はカード発行銀行システム107、108、109に決済要求を送るように構成される。決済要求は、特定期間(例えば、1日、1週間)にIPSPモジュール300が受け取った許可要求、チャージバック要求、払い戻し要求に基づいている。一実施形態によれば、決済要求には、IPSPモジュール300及び販売業者モジュール200によって不正行為の可能性がある取引としては検知されなかった取引のみが含まれてもよい。また、決済要求には、IPSPモジュール300又は販売業者モジュール200によって不正行為の可能性があるとして検知されたが、決済要求にて不正行為の可能性があるとしてマークやフラグが付された1以上の取引が含まれてもよい。
【0065】
上述のように、IPSPモジュール300は、ステップ306にて不正行為防止サブモジュール350を実行する。本発明の種々の実施形態による不正行為防止サブモジュール350の一例を
図7A及び
図7Bに示す。
図7Aに示すように、不正行為防止サブモジュール350は、ここで「不正行為フィルタ」と呼ばれる種々のステップを行い、不正行為の可能性がある取引活動を検知するが、特定の不正行為フィルタの結果、又は、不正行為フィルタ群の結果の組み合わせに応じて、取引を阻止したり、フラグを立てたりするように構成されてもよい。ステップ352〜368は、本発明の種々の実施形態による不正行為防止サブモジュール350が行う不正行為防止フィルタを示す。
図7Bは、本発明の種々の実施形態により、どの不正行為フィルタを取引情報に適用するかを判断するために、不正行為防止サブモジュール350が実行するステップを示す。
【0066】
例えば、
図7Aのステップ352に示すように、不正行為防止サブモジュール350は、支払いカード情報を、盗難に遭った支払いカードを識別するリストと比較してもよい。また、ステップ354に示すように、不正行為防止サブモジュール350は、支払いカードを発行した金融機関に関連する位置を、顧客の演算装置に対応するIPアドレスに関連する位置と比較してもよい。顧客の演算装置に対応するIPアドレスは、販売業者システム101、102、103が取引情報を最初に受信したときに、販売業者モジュール200によって(例えば、販売業者モジュール200に組み込まれたIPアドレス検知ソフトウェアを用いて)得ることができる。また、不正行為防止サブモジュール350は、顧客の演算装置のIPアドレスに関連する位置を、顧客の請求先住所と比較して、顧客の演算装置の位置が請求先住所から所定半径(例えば、50マイル)内にあることを確保するように構成されてもよい。同様に、不正行為防止サブモジュール350は、ステップ356に示すように、支払いカードを発行した金融機関に関連する位置を、顧客が提供した電子メールアドレスに関連する位置と比較してもよく、また、ステップ357に示すように、顧客の演算装置のIPアドレスの位置を、顧客が提供した電子メールアドレスに関連する位置と比較してもよい。上述の比較する位置は、国、地域、州、地方、市、1以上の郵便番号(例えば、ジップコード)により定められる郵便地区のうちの1つ以上とすることができる。
【0067】
また、ステップ358に示すように、不正行為防止サブモジュール350は、支払いカードのバンキング識別番号(BIN)を、疑わしいBINのリストと比較してもよく、ステップ360にて、不正行為防止サブモジュール350は、ウェブメールの電子メールアドレス(例えば、ホットメールやヤフーの電子メールアドレス)を持つ顧客が開始した取引を識別し、それにフラグを立ててもよい。さらに、ステップ362に示すように、不正行為防止サブモジュール350は、国の管轄地域内の販売業者との金融取引にかかわることを禁止された人物について国がまとめた人物リストと顧客の情報を比較してもよい。顧客が、米国の「特別指定国民リスト」(Specially Designated Nationals list)等、管轄地域が発動する金融制裁の対象となる人物、団体、法人のリストにある場合、その取引を否認することができる。同様に、ステップ368に示すように、不正行為防止サブモジュール350は、顧客の演算装置のIPアドレスに関連する国を、特定の管轄地域の販売業者と事業を行うことを禁止された国のリストと比較し、IPアドレスの国がリストにある場合、その取引を否認することができる。さらに、ステップ367に示すように、不正行為防止サブモジュール350は、顧客情報をオンライン販売業者の役員、管理職、又は所有者のリストと比較して、顧客がリストにある場合、その取引に不正行為防止の可能性があるとしてフラグを立てたり、否認したりすることができる。
【0068】
種々の実施形態によれば、不正行為防止サブモジュール350はさらに、ステップ364に示すように、特定期間(例えば、1カ月、1年)、顧客毎又はカード毎に取引の頻度を監視するように構成されてもよい。また、ステップ366に示すように、不正行為防止サブモジュール350は、特定期間、顧客又はカード毎に取引の種類(例えば、ギャンブル取引、旅行取引、成人向け娯楽取引)を監視するように構成されてもよい。カード毎又は顧客毎に取引の頻度と種類を監視することにより、本発明の種々の実施形態による不正行為防止サブモジュール350は、(1)カードの使用パターンが大幅に変化した場合にカード不正使用の可能性があることを判別し、(2)顧客が特定種類の取引に以前より頻繁に又はあまりにも頻繁にかかわっている場合、嗜癖や乱用の可能性があることを判別することができる。一実施形態によれば、監視ステップ364及び366は、顧客の過去の取引に基づいて取引の頻度及び/又は種類の範囲を設定し、その後の取引を設定範囲と比較することにより達成することができる。他の実施形態によれば、不正行為防止サブモジュール350が用いる範囲は、当該地域の行政又は規制当局が公表してもよく、また、学術又は専門研究等の結果であってもよく、また、参加者のうちの一者以上が設定してもよい。
【0069】
また、種々の実施形態の不正行為防止サブモジュール350は、特定の取引に関するIPアドレスのマスキング又は不正改変を検知するように構成されてもよい。例えば、顧客が、プロキシサーバやルータ等、何らかのファイアウォール又はゲートウェイ装置の背後で取引を行っている場合がある。すると、この取引に関するIPアドレスはファイアウォールやゲートウェイのものであり、顧客のコンピュータのIPアドレスは隠されているか、マスキングされている。一実施形態において、不正行為防止サブモジュール350は、公知のゲートウェイ装置(例えば、プロキシサーバ)のIPアドレスを記憶するデータベースを検索するフィルタを用い、取引に関するIPアドレスを公知のゲートウェイサーバ(例えば、プロキシサーバ)のリストと比較することにより、この状況に対処する。その結果、不正行為防止サブモジュール350は、顧客のIPアドレスがゲートウェイ装置(例えば、プロキシサーバ)のものであると判断した場合、不正行為の可能性があるとして、その取引にフラグを立てたり、その取引を否認したりすることができる。
【0070】
さらに、種々の実施形態による不正行為防止サブモジュール350は、顧客の活動から疑わしいパターンを判別するように構成されてもよい。例えば、不正行為の1パターンとして、盗難情報又は盗難クレジットカードを使用しようとすることがある。こうした場合、不正行為防止サブモジュール350は、顧客がある口座を使用して取引を行う際に、この特定顧客口座に関する情報としてメモリに記憶される顧客情報と一致するはずだが一致しない情報が提供されているか検索するように構成されてもよい。
【0071】
また、不正行為防止サブモジュール350は、(1)顧客の本拠地の位置を不正行為頻発位置として識別すること、(2)特定位置にて認められているクレジットカードの数、購入の規模、購入回数に対する制限を調査すること、(3)カード発行銀行により識別された位置と、顧客が提供した顧客の位置との不一致を調査すること、(4)カード発行銀行の位置と、顧客のIPアドレスにより提供される顧客の位置との不一致を調べること、(5)顧客のIPアドレスにより識別される位置と、顧客が提供する位置との不一致を調べること、(6)顧客の電話が登録されている場所として識別される位置と、上述のいずれかの位置との不一致を調べること、(7)販売業者に対する登録又は入金の際に顧客が使用した情報のいずれかが、他の時期に他の口座で使用されたことがあるか否かを判定して、不正行為の可能性がある関連口座を見つけること(例えば、名前と生年月日の一致、電話番号の一致、住所の一致)、(8)1つのクレジットカードが使用された複数の口座を判別すること、(9)所定期間に種々の口座で使用されることになっている、ある区分のクレジットカード群を識別すること(クレジットカード発行側によって得られる場合もあるが、例えば、ある銀行に対する回転率)、(10)パスワードの一致を判別すること(例えば、不正行為者は目に見える情報をすべて変更するかもしれないが、パスワードの変更は考えないかもしれない)により、疑わしいパターンを識別してもよい。
【0072】
例えば、特定の例において、不正行為防止サブモジュール350は、特定の取引について顧客が受け取ったクレジットカード番号(例えば、バンキング識別番号(BIN))の最初の6ケタを識別する。これら特定の実施形態において、不正行為防止サブモジュール350は、BIN番号を用いて、カードを発行した銀行とその銀行に対応する位置を識別する。例えば、不正行為防止サブモジュール350は、IPSPシステム104内のメモリ(例えば、
図1に示す情報データベース52)、あるいは、IPSPシステム104の外部のメモリ(例えば、
図4に示す第三者データベース116、117)に記憶されたBINバイブル(例えば、既知のBIN番号のリストを有するメモリ)に問い合わせを行う。この問い合わせにより、クレジットカードを発行した銀行の銀行名及び/又は位置が返送される。これに対して、不正行為防止サブモジュール350は、顧客が自分の位置であるとして識別した位置を、取引に使用されるカードを発行した銀行の位置と比較する。これらの位置が同じではない場合、あるいは、これらの位置が所定の許容範囲内にない場合、不正行為防止サブモジュール350は、その取引を不正行為の可能性がある取引として判別する。例えば、顧客が自分の位置を米国であると識別し、クレジットカードがロシアにある銀行から発行された場合、不正行為防止サブモジュール350は、関連する取引を不正行為の可能性がある取引として判別する。
【0073】
図15は、本発明の種々の実施形態による強迫的消費行動の監視プロセスを示す。具体的には、ステップ502から開始し、IPSPモジュール300は新たな金融取引要求を受信する。この新たな要求の受信に応じて、IPSPモジュール300は、ステップ504として示すように、以前に要求があった特定の販売業者31、32、33と顧客との間の金融取引に関連してメモリ24に記憶された資金の総額を読み出す。ステップ506にて、読み出した資金の総額と新たな要求にある資金額との合計を、販売業者31、32、33に払う資金に対する所定の許容限度と比較する。合計が所定の許容限度を超える場合、IPSPモジュール300は、ステップ508として示すように、適切な1又は複数の関係者(例えば、顧客、カード発行銀行、及び/又は販売業者)に、限度を超えていることを通知する。本発明の他の実施形態において、IPSPモジュール300は、特定期間(例えば、24時間、36時間、1週間、1カ月、1四半期、1年等)内にメモリに記憶された資金額を読み出してもよい。また、他の実施形態において、IPSPモジュール300は、特定期間に顧客と販売業者との間で行われた取引の数を比較するように構成され、行われた取引の数が所定の許容限度を超える場合には、IPSPモジュール300は、顧客、カード発行銀行、及び/又は販売業者に、限度を超えていることを通知する。
【0074】
同様に、
図16は、本発明の種々の実施形態による強迫的ギャンブル行動の監視プロセスを示す。ステップ602から開始し、IPSPモジュール300は、新たな金融取引要求を受信する。この新たな要求には、資金額と、取引の種類(例えば、販売業者への資金移動、販売業者のもとでの賭け、販売業者へのペイアウト要求)が含まれてもよい。次に、ステップ604にて、IPSPモジュール300は、新たな要求における金融取引の種類についてメモリ24に記憶された資金の総額を読み出す。そして、ステップ606にて、資金の総額と新たな要求の資金額との合計を、新たな要求における金融取引の種類に関する所定の許容限度と比較する。合計が所定の許容限度を超える場合、IPSPモジュール300は、ステップ608として示すように、適切な1又は複数の関係者(例えば、顧客、カード発行銀行、及び/又は販売業者)に、限度を超えていることを通知する。一実施形態において、合計が所定の許容限度を超える場合、その新たな要求を否認する。さらに、メモリから読み出した資金の総額を、特定期間内に記憶した資金に限定してもよく、問い合わせの期間に基づいて所定の許容限度を変えてもよい。
【0075】
さらに、種々の実施形態のIPSPモジュール300は、特定種類の取引の資金の総額が所定の許容限度を超えることに加えて、ある基準に基づいて強迫的ギャンブル行動を監視してもよい。例えば、IPSPモジュール300は、(1)顧客の入金頻度や、入金の規模にパターンがあるかどうか、例えば、顧客が賞金を取り戻そうとして入金の規模を大きくする等、(2)顧客がギャンブルを行う速さ、(3)顧客がギャンブルを行う時間帯、(4)顧客に関する情報が、顧客がギャンブル依存症のサポートセンターに連絡を取ったことがあることを示しているかどうか、(5)顧客のギャンブルパターンが変化又は急増したかどうか、(6)顧客に関する情報が、顧客が冷却期間を要求したことがある、あるいは、ギャンブルを禁止してもらうように要求したことがあることを示しているかどうか、を評価してもよい。
【0076】
例えば、一実施形態において、IPSPは、強迫的ギャンブルの問題を抱える人たちを支援する種々の組織との関係やネットワークコンピュータリンクの確立、及び/又は、このような組織(例えば、サポートセンサー)の設立を行ってもよい。こうした組織は、IPSPモジュール300に、これら種々の組織が使用するコンピュータシステムや記憶装置に記憶された情報へのアクセスを与えてもよい。例えば、ネットワーク115を介してIPSPシステム104及び/又はこれら組織が使用するコンピュータシステム118と通信を行う記憶装置(例えば、
図4に示す第三者データベース116、117等、1以上のデータベース)に、情報を記憶してもよい。したがって、この特定の実施形態において、IPSPモジュール300は、顧客の身元に基づいて情報へのアクセス及び問い合わせを行うように構成される。そして、IPSPモジュール300は、その情報を評価して、顧客がこれら組織のいずれかに連絡を取ったことがあるかどうかを判断する。
【0077】
例えば、一実施形態において、特定の顧客に関する情報が、コンピュータシステム118及び/又はコンピュータシステムに関連する記憶装置116、117に記憶されていることから、顧客がこのような組織に連絡を取ったことがあるということを示す指示情報を、コンピュータシステム118のうちの1以上がIPSPモジュール300に返送する。他の実施形態において、当該1以上のコンピュータシステム118は、レーティング(例えば、1〜10、又は、高中低)で表される指示情報を、ネットワーク115を介して、IPSPシステム104にあるIPSPモジュール300に送る。したがって、IPSPモジュール300は、この指示情報を受けて、レーティングを評価し、顧客が強迫的行動を示すかどうかを判断する。
【0078】
また、特定の実施形態において、当該組織に関連するシステム118は、強迫的ギャンブルについての支援を求めて当該組織に連絡を取ったことがある新たな顧客に関する情報を、ネットワークを介してIPSPシステム104に転送してもよい。すると、IPSPシステム104は、IPSPシステム104内のメモリ(例えば、
図1に示す顧客情報データベース50)に、この情報を記憶する。したがって、これら特定の実施形態において、IPSPモジュール300は、幾つかの組織のシステムに記憶された情報を問い合わせる必要はなく、直接、ローカルメモリに情報を問い合わせればよい。これにより、これら組織に関連する幾つかの異なるシステム118に問い合わせなければならない場合と比較して、特定の実施形態では処理の高速化が得られる。
【0079】
さらに、IPSPシステム104は、種々の実施形態において、顧客が冷却期間を要求したことがある、あるいは、ギャンブルを禁止してもらうように要求したことがあることを示す情報を記憶してもよい。例えば、特定の実施形態において、IPSPシステム104は、このような冷却期間又は禁止してもらうように要求するサービスを顧客に提供してもよい。例えば、顧客は、IPSPシステム104に関連するウェブサイトを開き、システム104は、冷却期間又は禁止してもらうための顧客登録を促す1以上のウェブページを提供する。特定の実施形態において、顧客は、IPSPシステム104上で直接、あるいは、販売業者システム101、102、103を介して、このサービスにアクセスすることができる。すなわち、特定の実施形態において、IPSPシステム104は、販売業者のウェブサイト上で利用可能となる特定のウェブページを販売業者システム101、102、103に提供してもよい。
【0080】
他の実施形態において、販売業者31、32、33は、例えば、販売業者のウェブサイトを介して、冷却期間又は禁止してもらうように要求するサービスを顧客に提供してもよい。これら特定の実施形態において、販売業者システム101、102、103は、販売業者システム101、102、103にその情報を記憶する、及び/又は、要求に応じてIPSPシステム104に情報を送って記憶する。したがって、IPSPモジュール300は、ローカルに(例えば、
図1に示すIPSP34に関連する顧客情報データベース50に)情報を問い合わせることにより、及び/又は、個々の販売業者システム101、102、103(例えば、
図1に示す販売業者3 33に関連する顧客情報データベース51)に情報を問い合わせることにより、顧客の行動を監視する。
【0081】
そこで、
図16Aは、本発明の種々の実施形態による強迫的ギャンブル行動を監視する他のプロセスを示す。ステップ1602にて開始し、IPSPモジュール300は、新たな金融取引要求を受信する。これに対して、IPSPモジュール300は、ステップ1604として示すように、IPSPシステム
104内の記憶装置、販売業者システム101、102、103内の1以上の記憶装置、あるいは、ネットワーク115を介してIPSPシステム
104と通信を行う1以上の記憶装置116、117のうちのいずれかに対して、強迫的ギャンブル行動の人たちを支援する種々の組織に連絡を取ったことがある個人を示す情報、及び/又は、冷却期間又は禁止してもらうように要求したことがある個人を示す情報を問い合わせる。この情報から、IPSPモジュール300は、ステップ1606として示すように、金融取引の要求を提出した顧客がそのような組織に連絡を取ったことがあるかどうか、冷却期間を要求したことがあるかどうか、及び/又は、ギャンブルを禁止してもらうように要求したことがあるかどうかを判断する。顧客がこれら組織のいずれか連絡を取ったことがある、冷却期間を要求したことがある、及び/又は、ギャンブルを禁止してもらうように要求したことがある場合、IPSPモジュール300は、ステップ1608として示すように、適切な1又は複数の関係者(例えば、顧客、カード発行銀行、及び/又は、販売業者)に連絡する。例えば、一実施形態において、IPSPモジュール300は、電子メール等の電子メッセージを適切な1又は複数の関係者に自動的に送る。特定の実施形態において、IPSPモジュール300はその要求を否認してもよい。
【0082】
さらに、特定の実施形態において、IPSPモジュール300は、冷却期間の要求又はギャンブルを禁止してもらうための要求を、多数の販売業者に対して適用するように構成されてもよい。例えば、IPSPモジュール300が、顧客が販売業者との取引を要求しているという通知を、ネットワークを介して販売業者システム101、102、103のいずれかから受信する場合、IPSPモジュール300は、IPSPシステム
104内の記憶装置、販売業者システム101、102、103内の1以上の記憶装置、あるいは、ネットワークを介してIPSPシステム
104と通信状態である1以上の記憶装置106、107のいずれかに対して、冷却期間及び/又はギャンブルを禁止してもらうように要求している個人に関する情報を問い合わせる。そして、取引を要求している顧客が販売業者システム101、102、103のいずれかについて冷却期間及び/又は禁止を要求していることを示す問い合わせ情報に基づいて、ネットワークを介して、顧客との取引発生を許可しないように販売業者システム101、102、103に指示を与える、及び/又は、顧客(及び/又は他の適切な関係者)に対して、顧客がそのような冷却期間又は禁止を要求していることを、販売業者システム101、102、103から通知させる。
【0083】
種々の実施形態において、例えば、
図1に示す情報データベース52等のデータベースは、ネットワークを介して種々の販売業者システム101、102、103から受信した強迫的行動の可能性を示す信号を記録するように維持されてもよい。また、入金可能頻度や入金可能規模等、さらなる変数について閾値を設定して、データベースに記憶してもよい(上述の移動資金額に対する所定の許容限度等)。その結果、IPSPモジュール300がこれらの閾値に基づいて顧客の入金を監視し、適切な1又は複数の関係者に通知することにより、強迫的行動を関係者に知らせるのに役立つ。
【0084】
さらなる実施形態において、IPSPモジュール300は、強迫的ギャンブラーの可能性がある人、あるいは、実際に強迫的ギャンブラーであるとして判別された参加者のデータベースを維持し、このデータベースにアクセスすることもできる。
図1に示すような、IPSP34及び/又は販売業者33に関連する顧客情報データベース50、51、及び/又は、
図4に示すような第三者データベース116、117を、この目的で利用してもよい。IPSPモジュール300はデータベースをチェックして、新たな顧客が、ギャンブル産業の販売業者として知られる販売業者との取引を行おうとする場合、必ず、顧客が強迫的ギャンブラーではないことを確実にする。IPSPモジュール300は、顧客がデータベースに含まれていると判断した場合、顧客がこの特定販売業者と取引を行うことを制限又は禁止する。
【0085】
上述の種類の取引の監視のほかに、本発明の種々の実施形態によれば、不正行為防止サブモジュール350はさらに、ペイバック要求取引を監視し、不審な取引を識別するように構成されてもよい。ペイバック要求情報が本来の取引における情報と一致しないような取引を識別する、あるいは、特定期間(例えば、1週間、1カ月、数カ月以内)に特定の支払いカードに関して相当数のペイバック要求取引があったことを識別する等により、不審なペイバック要求取引を識別した場合に、支払いカード番号を、禁止支払いカードリストに追加し、その支払いカードを使った今後の購入取引を防止するようにしてもよい。
【0086】
上述のフィルタに加え、本発明の種々の実施形態によれば、不正行為防止サブモジュール350はさらに、(1)各顧客が1枚の支払いカードのみを使用することを確実にし、(2)顧客毎に特定期間における特定活動に対する支払いを特定頻度に制限する(例えば、支払いを1日当たり1回、あるいは、36時間毎に3回とする)ように構成されてもよい。さらに、一実施形態によれば、特定期間(例えば、日毎、週毎、月毎)における特定サービス(例えば、インターネットギャンブルや成人向け娯楽)について、カード毎又は顧客毎に使える金額の上限を設定してもよい。一実施形態において、顧客の要求に応じてこの上限を設定してもよい。他の実施形態において、IPSPシステム104は、特定活動に使える金額についてデフォルトの限度額を導入してもよく(例えば、支払いカードに関連するクレジット限度の20%)、この限度額は顧客の明確な要求がなければ増額することができない。一実施形態において、IPSPシステム104又は販売業者システム101、102、103は、利用限度額の増額要求を受けて、特別訓練を受けた従業員から顧客への電話や電子メール等により、利用超過の危険に関する資料を顧客に提示し、乱用の可能性があることを検知した場合に資料や支援手段(例えば、ギャンブラーズ・アノニマス(ギャンブル依存症の人の自助グループ)の電話番号、ウェブサイトアドレス、その他の資料)を提示するように構成されてもよい。
【0087】
本発明の種々の実施形態によれば、IPSPシステム104はさらに、不正行為防止サブモジュール350からの結果を記憶する不正行為及び乱用データベース(図示せず)を備えてもよい。一実施形態において、IPSPモジュール300は、取引の処理時(ステップ302)や不正行為防止サブモジュール350の実行時(ステップ306)に、このデータベースにアクセスして、特定の支払いカード又は顧客に対する以前の不正行為チェックに基づいて取引を否認すべきかどうかを判断する。
【0088】
図7Bに示すように、本発明の一実施形態によれば、不正行為防止サブモジュール350は、上述の不正行為フィルタのうちの1以上を使用して、受信した取引情報を評価してもよい。不正行為防止サブモジュール350は、ステップ370から開始し、IPSPモジュール300から取引データを受信する。次に、ステップ372にて、不正行為防止サブモジュール350は、取引データの評価に使用する1以上の不正行為フィルタを決定する。例えば、一実施形態において、不正行為防止サブモジュール350は、以前に販売業者が選択して使用した不正行為フィルタを使用する。他の実施形態において、使用する不正行為フィルタの種類は、取引の種類(例えば、許可要求、チャージバック要求、決済要求、支払い要求)によって異なる。さらに他の実施形態において、使用する不正行為フィルタの種類は、顧客に関連するIPアドレスの国によって異なる。そして、他の実施形態において、どの不正行為フィルタを用いるかの選択は、IPSP及び/又は当該地域規制当局によって決められる。そして、ステップ374にて、不正行為防止サブモジュール350は、適切な不正行為フィルタを実行して取引データを評価する。
【0089】
本発明の種々の実施形態によれば、不正行為防止サブモジュール350の実行に加えて、IPSPモジュール300はさらに、違法又は規制対象となる金融取引を識別するように構成される。例えば、
図18は、違法又は規制対象の金融取引を識別するプロセスの一例を示す。IPSPモジュール300は、ステップ802から開始し、顧客の支払いカードから販売業者31、32、33への資金移動の要求を受け取る。資金移動要求には、顧客の請求先住所と、顧客がこの要求を発行するのに使用した演算装置に関連するIPアドレスの位置が含まれる。
【0090】
種々の実施形態において、不正行為防止サブモジュール350は、第三者のIPジオロケーション(地理的位置)サービスを利用して、IPアドレスの位置を判断する。例えば、不正行為防止サブモジュール350は、第三者IPジオロケーションサービスにより提供されるデータベースを検索して、あるIPアドレス又はIPアドレス群に対応する物理的位置を識別する。これらデータベースは、インターネットを介してアクセスするか、あるいは、種々の実施形態によるIPSPシステム104に直接接続することができる。
【0091】
なお、幾つかの例において、顧客のコンピュータがゲートウェイ装置(ファイアウォール、プロキシサーバ、ルータ)を使用してもよい。ゲートウェイ装置は、個々のコンピュータ又はユーザの識別子をマスキングし、代わりにゲートウェイ装置の識別子を表示する(不正行為検出フィルタについて上述したのと同様)。例えば、顧客のコンピュータが、
図1に示すゲートウェイ装置60、62を使用してもよい。これにより、不正行為防止サブモジュール350は、プロキシサーバ等、公知のゲートウェイ装置(例えば
図4に示すように、ネットワーク115上の第三者データベース116、117)のIPアドレスを記憶するデータベースをさらに検索する。不正行為防止サブモジュール350が、そのIPアドレスを、あるゲートウェイ装置(例えば、プロキシサーバ)に属しているものとして識別し、ゲートウェイ装置(プロキシサーバ)の背後にいる顧客の位置を正確に判断又は予測できない場合、不正行為防止サブモジュール350は、そのIPアドレスを識別不可能としてフラグを立て、顧客によるIPSPシステム104の使用を制限する。
【0092】
他の場合、ゲートウェイ装置は顧客の実際の識別子を把握していてもよい。したがって、種々の実施形態の不正行為防止サブモジュール350は、ネットワーク115を介して、顧客のコンピュータのIPアドレス等、顧客を識別するための、つまり、ゲートウェイ装置に接続した顧客の位置を識別するためのさらなる情報を、ゲートウェイ装置に要求するように構成される。
【0093】
IPアドレスを顧客の識別子として使用するのでは不十分な場合がある。そこで、不正行為防止サブモジュール350の種々の実施形態では他の固有識別子を利用する。例えば、顧客が携帯電話によりインターネットにアクセスしている場合、顧客は携帯電話のプロバイダにより制御されるゲートウェイ装置を通してやりとりする。この場合、不正行為防止サブモジュール350は、携帯電話会社に関連するゲートウェイ装置のIPアドレスを受信し、このIPアドレスと、金融取引に関連するウェブサイトと、取引の日時を携帯電話会社に提供する。種々の実施形態において、不正行為防止サブモジュール350は、インターネットを介して携帯電話会社のシステムにアクセスする等、種々のやり方でこの情報を提供することができる。
【0094】
IPアドレスとともにこの追加情報を提供した結果、携帯電話会社は特定サイトにアクセスしている携帯電話を識別することができ、基地局に基づいて顧客の位置を正確に特定し、IPSPモジュール300にその位置を提供することができる。したがって、この場合、不正行為防止サブモジュール350は、多数の変数の組み合わせを用いて、顧客の位置を識別する固有識別子を形成する。これら変数は、携帯電話会社のシステムのIPアドレス、金融取引に関連するウェブサイト、取引の日時である。
【0095】
他の例において、顧客はAOL(アメリカ・オンライン)等、種々のインターネットプロバイダを通してインターネットにアクセスしていてもよい。携帯電話プロバイダの場合と同様、顧客はAOLにより制御されたゲートウェイ装置を通してインターネットにアクセスしている。したがって、不正行為防止サブモジュール350は、顧客のコンピュータのIPアドレスではなく、ゲートウェイ装置のIPアドレスを受信する。これに対して、不正行為防止サブモジュール350は、IPアドレス、金融取引に関連するウェブサイト、取引の日時をAOLに提供し、AOLはこの情報を用いて顧客の位置を識別し、その位置をIPSPモジュール300に提供する。他の実施形態では、他の多くの変数を1つ以上用いて、このような固有識別子、例えば、グローバルポジショニングシステム(GPS)、高度観測時間差(E−OTD)、タイミングアドバンス処理付きセルグローバル識別(CGI−TA)、アップリンク到着時刻(TOA)に関連する変数等を提供してもよい。
【0096】
次に、ステップ804にて、IPSPモジュール300は、顧客の請求先住所、IPアドレスの位置、販売業者31、32、33の位置を、販売業者31、32、33への資金移動規制位置リストと比較する。位置リストはIPSP(例えば、
図1に示す情報データベース52)内にローカルに記憶してもよいし、1以上の第三者データベース(例えば、
図4に示す第三者データベース116、117)にリモートで記憶してもよい。これら位置のいずれかが、位置リストにある位置と一致する場合、IPSPモジュール300は、ステップ806として示すように、1以上の規制当局がこれらの位置のいずれかにおける資金移動を規制しているかどうかを判断する。IPSPモジュール300は、1以上の規制当局が資金移動を規制していると判断する場合、ステップ8080として示すように、当該資金移動が受ける1以上の規制の種類について、適切な1又は複数の関係者(例えば、顧客、販売業者、及び/又はカード発行銀行)に通知する。金融取引が受ける規制の種類には、資金移動の禁止(例えば、ギャンブルが違法である州や地域でのギャンブル取引)や、資金移動の制限(例えば、賭金の額を制限している州や地域でのギャンブル取引)が含まれる。
【0097】
さらに、種々の実施形態において、位置リストには、このような金融取引が違法又は規制対象となる位置だけでなく、このような取引の許可を選択的に除外する位置が含まれていてもよい。例えば、ある州ではこのような取引が厳密には違法ではないかもしれないが、州としては、このような取引の許可を除外することを選択する場合がある。したがって、IPSPモジュール300は、顧客の請求先住所、IPアドレスの位置、販売業者31、32、33の位置を、このような除外リストと比較して、3つの位置のいずれかがリストにある場合、取引を禁止する。除外リストには、特定種類の取引の除外を選択している業種等、他の実施形態における他の変数が含まれてもよい。
【0098】
ASPモジュール
図8は、本発明の種々の実施形態によるASPモジュール400のブロック図である。ASPモジュール400は、一実施形態によるASPシステム105にて動作するように構成されてもよいが、IPSPが他の実施形態による会計管理サービスを行う契約をASPと結んでいない場合、IPSPシステム104にて動作するように構成されてもよい。
【0099】
一実施形態によれば、ASPモジュール400は、ステップ402にて開始し、IPSPシステム104及び提携銀行システム106から取引情報を得る。IPSPシステム104から得られた取引情報には、各取引について以下のデータ項目が含まれていてもよい。すなわち、(1)販売業者又は販売業者の営業組織(例えば、特定のウェブサイト)を識別するために提携銀行から付与される販売業者識別(MID)番号、(2)取引の日時、(3)顧客の名前、(4)支払いカード番号又は支払いカード番号の一部(例えば、最後の4ケタ)、(5)カード所有者の電子メールアドレス、(6)取引の通貨、(7)使用される支払いカードの種類(例えば、VISA、マスターカード、アメリカン・エキスプレス)、(8)支払い額、(9)販売業者が取引に割り当てた注文照会番号、(10)取引が許可されたかどうかを示し、カード発行銀行が発行する固有コードである許可コード、(11)取引の決済状況(例えば、決済完了の取引については「100」)、(12)IPSPが提携銀行に決済要求を送った時刻である「決済時刻」、(13)カード所有者が居住する通りと番地、(14)カード所有者の町、(15)カード所有者の国、(16)カード所有者の郵便番号、(17)払い戻し要求があった場合に、払い戻される元の取引の照会記号となる元取引照会記号、(18)販売業者が取引に関する情報をさらに含めたい場合に使用できる他の情報、(
19)販売業者に対するIPSPの照会記号である「サイト照会記号」、(
20)許可済み取引、払い戻し取引、取り消し済み取引(例えば、取消になった取引、あるいは、カード発行銀行から販売業者への送金前で、IPSPから提携銀行への決済要求送信後に、販売業者の要求により金額が変更された取引)を含む取引の種類、(
21)ASPシステム105において取引を固有に識別する固有照会番号(URN)、というデータ項目である。本発明の一実施形態によれば、この情報は、IPSPから提携銀行に送信される決済要求に含まれてもよい。これについては、先に
図6のステップ310を参照して説明してあり、また、
図10Aのステップ1102、1104を参照して以下に説明する。提携銀行システム106から得られる取引情報には、例えば、販売業者毎に1以上の集合としてまとめられた複数のカード発行銀行に要求される資金の総額が含まれてもよい。
【0100】
種々の実施形態によれば、ASPモジュール400は、取引情報を得るため、取引情報が掲示されている安全なウェブページ(例えば、各システム104、106により維持される)にアクセスして、ASPシステム105に情報をダウンロードしてもよいし、別の電子送信方式(例えば、電子メール又はファクス)により取引情報を受信してもよい。また、両者の組み合わせでもよい。
【0101】
種々の実施形態において、ステップ402にて得られた取引情報を、ステップ404として示すようにASPシステム105に記憶する。そして、ステップ406として示すように、IPSPシステム104から得られた情報を、提携銀行システム106から得られた情報と比較する。
図8に示す実施形態では、ステップ406はステップ404の後で行うことになっているが、他の実施形態においては、これらのステップを同時におこなってもよいし、順序を逆にしてもよい。
【0102】
本発明の種々の実施形態によれば、比較ステップ406にて、ASPモジュール400は、IPSPシステム104により提供された取引情報が提携銀行システム106により提供された取引情報と一致しない取引を識別する。一実施形態において、不一致の取引にはフラグを立て、ASPモジュール400により作成される例外報告書にて、販売業者、IPSP、及び/又は提携銀行に報告する。これについては、ステップ410を参照して以下に詳細に説明する。他の実施形態において、
図14を参照して以下に説明するが、IPSP36及び/又はASP35が維持する各販売業者の口座に、提携銀行システム106が直接資金移動を行う。この実施形態において、ASPモジュール400はさらに、IPSPシステム104及び提携銀行システム106により提供された取引情報を、各販売業者の口座に移動した金額と比較するように構成される。
【0103】
IPSPシステム104及び提携銀行
システム106により提供された取引情報の照合後、ASPモジュール400は、
図8にステップ408として示すように、種々の参加者に対して、決済処理中に受け取った支払い金額を割り当てることができる。支払い金額には、例えば、販売業者31、32、33への支払い金額、IPSP34、提携銀行36、ASP35が受け取る手数料、及び、各販売業者31、32、33のローリングリザーブ・エスクロー口座41に入金する資金の割合が含まれてもよい。例えば、種々の実施形態によれば、種々の参加者は、販売業者31、32、33との契約及び相互の契約43、45、47、49によるサービスに対する支払いとして、販売業者31、32、33が受け取ったある資金のうち所定の割合を要求してもよい。例えば、提携銀行36は、販売業者31、32、33が受け取った資金の3%を請求し、カードスキームは、カード使用により移動した資金の1%を請求し、IPSP34は、支払い関連サービスについて5%を請求し、ASP35は、会計管理サービスについてIPSP34が受け取った金額の3%をIPSP34に請求してもよい。他の例として、ASP35は、カード検証、種々の参加者への手数料支払い、受理したチャージバックについて販売業者31、32、33に対して請求可能な料金等、種々のサービスについてIPSP34が負う一時費用を計算してもよい。
【0104】
また、種々の実施形態によれば、金融取引システム100は、ローリングリザーブ・エスクロー口座41に資金提供するのに使用される資金の割合を特定するプロトコルを設けてもよい。例えば、システムプロトコルにより、ASPモジュール400は、各販売業者31、32、33が受け取る資金の7.5%を、各販売業者31、32、33のローリングリザーブ・エスクロー口座41に割り当てなければならない、としてもよい。他の例として、一実施形態によれば、ローリングリザーブ口座の特定割合は、特定の販売業者31、32、33について受けるペイバック要求の数に応じて自動的に増減させてもよい。また、一実施形態によれば、ASPモジュール400は、所定期間(例えば、6カ月、1年、3年)口座に残っている資金の監視及び判別を行い、期間の終わりに販売業者31、32、33にそれらの資金の再割り当てを行う。さらに、エスクロー口座41は、
図1の実施形態においてASPシステム35の一部として示されている。しかし、他の実施形態において、エスクロー口座41は銀行又は他の金融機関に存在するか、あるいは、銀行又は他の金融機関によって維持されてもよい。
【0105】
次に、ステップ410にて、種々の実施形態によれば、ASPモジュール400は、販売業者毎に照合レポート又は「通知書」を発行するように構成される。一実施形態において、特定期間(例えば、1日又は1週間)に当該販売業者について処理した取引の概要、照合ステップ406で作成した例外報告書(必要な場合)、ステップ408で種々の参加者のそれぞれに割り当てた支払いの概要、特定期間のエスクロー口座における活動の概要、販売業者31、32、33に支払いが送金される日付が、通知書によって各販売業者に与えられる。他の実施形態において、通知書のこれら各部分はそれぞれ別々の報告書に含まれる(例えば、例外報告書、支払い割り当て報告書、取引概要報告書)。そして、さらに他の実施形態において、ASPモジュール400は、IPSP34及び各販売業者31、32、33への1以上の概要報告書を、それぞれ特定された形式により発行するように構成される。
【0106】
図8に示す実施形態において、ASPモジュール400はさらに、(1)ステップ412として示すように、各販売業者31、32、33への通知書の承認を受けるために通知書をIPSP34に送信し、(2)ステップ414として示すIPSP34から通知書の承認を受けると、ステップ416として示すように、販売業者31、32、33に通知書を送信する。他の実施形態において、IPSP34は会計管理サービス(図示せず)を提供する契約をASP35と結ばず、この場合、ステップ412、414は行わなくてもよい。
【0107】
また、ASPモジュール400は、本発明の種々の実施形態によれば、ステップ418として示すように、種々の参加者及びエスクロー口座への支払いの準備及び送金を行うように構成されてもよい。ステップ418では、例えば、各参加者に物理的に支払いの送金を行う(例えば、小切手や現金)、又は、ASPシステム105に関連する口座から支払い先となる種々の参加者のそれぞれの口座への電子資金移動(EFT)の要求を準備する、あるいは、これらの組み合わせであってもよい。さらに、
図8に示す実施形態では、支払いステップ418はステップ416の後に行われることになっているが、他の実施形態によるASPモジュール400は、ステップ416と同時又はステップ416の前に支払いステップ418を行うように構成されてもよい。
【0108】
本発明の他の実施形態によれば、ASPモジュール400はさらに、各販売業者31、32、33への支払い送金の前に、当該電子商取引(例えば、インターネットギャンブル取引や小売商品購入)に対する地方税を差し引くように構成されてもよい。例えば、一実施形態において、ASPモジュール400は、各顧客及び/又は販売業者の居住地又は取引地に基づいて適用可能な税率又はライセンス料を適用し、その資金を適切な税当局又はライセンス許可当局に直接移動するように構成されてもよい。
【0109】
具体的には、
図17は、金融取引で課される税清算プロセスの一例を示す。ステップ702から開始し、1以上の税管轄地域のそれぞれについて、適切な税の種類と、対応する税率をメモリ24に記憶する。次に、ステップ704にて、顧客と販売業者31、32、33との間で行われる金融取引に関連する情報を受信する。この金融取引に関連する情報の受信に応じて、ステップ706として示すように、金融取引に関連する1以上の適切な税管轄地域を識別する。次に、ステップ708にて、識別された税管轄地域に関連する1以上の税の種類を判断するためにメモリに問い合わせる。1以上の税の種類が、識別した税管轄地域に関連している場合、ステップ710として示すように、この種類の税に対応する税率を当該金融取引に適用して、取引に課せられる税金を判断する。また、当該取引に課せられる税金を判断すると、ステップ712として示すように、支払うべき税額を適切な税当局に移動する。種々の実施形態において、取引発生側(例えば、販売業者)の位置、顧客、及び/又は、顧客が注文を行うときの演算装置の位置によって、課税を行ってもよい。
【0110】
種々の実施形態において、上述と同じシステム及びプロセスをライセンス料に適用することができる。例えば、運転免許証や漁獲許可証と同様に、個人がギャンブルを行うために取得しなければならないライセンスの行政手続き料の場合である。そこで、ステップ702から開始し、適切なライセンス料、及び、1以上のライセンス管轄区域のそれぞれについて対応するライセンスレートをメモリ24に記憶する。次に、ステップ704にて、顧客と販売業者31、32、33との間で行われる金融取引に関する情報を受信する。この金融取引に関する情報の受信に応じて、ステップ706として示すように、当該金融取引に関連する1以上の適切なライセンス管轄区域を識別する。次に、ステップ708にて、メモリに問い合わせを行い、関連する1以上のライセンスの種類を判断する。1以上のライセンスの種類が、識別されたライセンス管轄区域に関連している場合、ステップ710として示すように、その種類のライセンスに対応するライセンスレートを当該金融取引に適用して、当該取引にかかるライセンス料を判断する。また、取引にかかるライセンス料を判断すると、ステップ712として示すように、支払うべき料金を適切なライセンス当局に送金する。税金の場合と同様、種々の実施形態において、取引発生側(例えば、販売業者)の位置、顧客、及び/又は、顧客が注文を行うときの演算装置の位置によって、ライセンス料を課してもよい。
【0111】
種々の実施形態において、差し引かれた税金の額や税当局に支払われた額は、所定期間、取引情報とともにシステム内に記憶する。これにより、幾つかの実施形態において、完全な監査証跡が可能になる。例えば、一実施形態において、支払うべき額を指定銀行口座に保持し、定期的に(例えば、毎月、毎週、毎日、あるいは、リアルタイムで)税当局に支払う。一実施形態において、支払うべき額を電子資金移動(EFT)により税当局に支払う。
【0112】
種々の実施形態によれば、この税清算機能により、販売業者、顧客、税当局の負担が減り、課税可能な取引について信頼できる清算システムが提供される。また、一実施形態において、ASPモジュール400は、支払うべき税、及び/又は、徴収済みの税についてまとめた税当局への会計報告書を発行する。
【0113】
さらに、種々の実施形態において、ASPモジュール400を介して、取引記録の監査を電子的又は手作業により行ってもよい。具体的には、システムを通して取引が処理される際に、各取引に関連する固有照会番号(URN)を追跡する。例えば、一実施形態において、複数の取引を1つのバッチファイルにまとめて、決済のために提携銀行に送る。ASPモジュール400は、個々の取引を独立して監査できるように、バッチファイルにある各取引に関連するURNを、バッチファイルを識別する情報とともに記憶する。
【0114】
C.処理フローの例
許可処理フロー
図9Aは、本発明の種々の実施形態による許可要求の処理フロー1000を示す。一実施形態において、許可要求処理フローは、顧客が待っている間にオンラインで行われ、処理は一般に約2〜20秒かかる。カード発行銀行が許可要求を受け付けると、販売業者は顧客の支払いを受け付け、カード発行銀行は、支払いカードに関するクレジット限度額又は残高から要求金額を遮断する。
【0115】
本発明の種々の実施形態によれば、許可要求プロセス1000は、ステップ1002から開始し、販売業者31、32、33は、顧客の支払いカードから販売業者の口座への送金要求を顧客から受信する。この要求には、例えば、送金額、顧客の情報及び支払いカード情報が含まれてもよい(販売業者が、以前の取引で記憶した顧客の情報及び支払いカード情報を有していないことが前提)。一実施形態において、顧客及び支払いカード情報には、顧客のフルネームと住所、顧客の電子メールアドレス、支払いカード番号、有効期限、支払いカードに関する他の識別情報が含まれてもよい。一実施形態においては、販売業者のシステム101、102、103が、この要求を受信して、記憶してもよい。
【0116】
次に、本発明の種々の実施形態によれば、ステップ1006にて、販売業者31、32、33が、顧客からの要求において受信した情報のフォーマットを確認する。一実施形態において、
図5及びステップ204に示す販売業者モジュール200を参照して上述したように、販売業者モジュール200は、支払いカード番号のフォーマットが正しいかどうか、及び、必要な項目がすべて完了しているかどうかを確認する。
【0117】
ステップ1006の情報フォーマット確認後、販売業者31、32、33は、ステップ1010として示すように、さらに処理を行うためにIPSP34に取引情報を転送する。IPSP34は、ステップ1012として示すように、取引情報を受信してIPSPシステム104に記憶し、提携銀行36及びカード発行銀行37、38、39が許可要求の処理の際に必要とする情報を、提携銀行36に転送する。例えば、本発明の種々の実施形態によれば、IPSPモジュール300が提携銀行システム106に情報を転送し、この情報には、支払いカード番号、支払い額、顧客の請求先住所が含まれていてもよい。
【0118】
次に、ステップ1014で、提携銀行システム106は許可要求を受信して、提携銀行システム106に記憶する。そして、ステップ1016にて、提携銀行システム106は、適切なカード発行会社及びカード発行銀行を識別し、適切なカード発行会社ネットワーク(例えば、VISA、マスターカード、アメリカン・エキスプレスのネットワーク)を介して、カード発行銀行に許可要求を送る。許可要求を受信すると、カード発行銀行システム107、108、109は、ステップ1018として示すように、支払いカード番号が有効かつ正当であることを確認し、ステップ1020として示すように、支払いカードに利用可能な十分な資金があることを確認する。許可要求を承認すると、カード発行銀行システム107、108、109は、ステップ1022として示すように、カード発行会社ネットワークを介して提携銀行システム106に承認メッセージを送る。提携銀行システム106は、ステップ1024にて、承認メッセージを受信し、承認メッセージをIPSPシステム104 に送信する。そして、ステップ1026で、IPSPシステム104は、承認メッセージを受信して記憶し、許可要求を発行した販売業者システム101、102、103にこの承認メッセージを送る。
【0119】
種々の実施形態によれば、許可要求情報を販売業者からIPSPに転送するステップS1010と同時に、あるいは、その前又は後に、
図5を参照して上述した初期不正行為チェック及び身元/年齢確認ステップ(ステップ204及び206)を、販売業者モジュール200により行ってもよい。また、本発明の種々の実施形態によれば、許可要求情報をIPSPから提携銀行に転送するステップ1012と同時に、あるいは、その前又は後に、
図6にステップ306として示す不正行為防止サブモジュール350の実行ステップを、IPSPモジュール300により行ってもよい。
【0120】
本発明の他の実施形態を
図13に示すが、この実施形態において、顧客の情報を販売業者システム101a、102a、103aに送るとき、またはネットワーク115aを介してIPSPシステム114aに送るとき、顧客情報を暗号化する(例えば、2048ビット変数暗号化による)。また、IPSPモジュール300aは、不正行為防止サブモジュール350aの不正行為フィルタのうちの1以上を実行して、不正行為フィルタが潜在的に不審な活動を検知した場合、提携銀行システム106aに許可要求を送る前に、販売業者の承認を得るために不正行為チェックの結果を販売業者に送る。販売業者が取引の承認を与えた後、IPSPモジュール300aは提携銀行に許可要求を送り、提携銀行はこの要求をカード発行銀行に送る。提携銀行は、カード発行銀行から許可メッセージを受信した後、提携銀行システム106aのメモリ領域(例えば、データベース)に取引情報を記憶し、IPSPシステム104aに許可メッセージを送る。IPSPモジュール300aは許可メッセージを販売業者に転送し、取引の決済要求発行前に取引情報に対して1以上の不正行為フィルタを実行してもよい。
【0121】
決済処理フロー
図10A及び
図10Bは、本発明の種々の実施形態による決済要求処理フローの一例1100を示す。種々の実施形態によれば、決済要求とは、販売業者への支払いのためにカード発行銀行から提携銀行へ送金を行うように、提携銀行(又は提携銀行の代わりにIPSP)が発行する要求である。本発明の種々の実施形態によれば、決済要求プロセス1100は、ステップ1102から開始し、IPSPシステム104が各販売業者31、32、33についての決済要求を発行し、決済要求をバッチファイルとして提携銀行36に送信する。種々の実施形態において、各決済要求には、特定期間(例えば、24時間、48時間、1週間)にIPSP34が取り扱った取引のデータが含まれる。本発明の種々の実施形態によれば、決済要求には、許可済み取引及び未許可取引、あるいは、許可済み取引のみが含まれてもよい。次に、本発明の種々の実施形態によれば、ステップ1104にて、IPSPシステム104は、IPSPシステム104に決済要求を記憶する。IPSPシステム104の安全な部分からダウンロードすることにより、決済要求をASPシステム105に転送してもよい。また、IPSP34が決済要求の物理的コピー又は電子コピーをASP35に送ってもよい(例えば、電子メール、ファクシミリ、CD、DVD、フロッピー(登録商標)ディスクによる)。本発明の種々の実施形態による決済要求の内容については、先に
図8を参照して説明した。
【0122】
ステップ1106に示すように、提携銀行36はバッチファイルを受信し、適切なカード発行銀行37、38、39に決済要求を送信する。また、提携銀行36は、ステップ1108として示すように、各カード発行銀行37、38、39に対する各決済要求に含まれる資金額(例えば、資金総額)をまとめたASP35への支払い報告書を発行し、記憶する。提携銀行36がASP35に対して発行する支払い報告書の一実施形態については、先に
図8を参照して説明した。
【0123】
そして、ステップ1110にて、カード発行銀行37、38、39は要求された資金を提携銀行36に移動させる。次に、ステップ1112にて、提携銀行36は、受け取った資金をIPSP34に移動する。IPSP34(又はASP35)が適切な参加者及びエスクロー口座に資金を分配する前に、APSシステム105は、ステップ1114にて、IPSPシステム104が発行した決済要求と、提携銀行36が発行した支払い報告書を取得し、得られた情報を照合する。ステップ1114で行った照合の結果は、本発明の種々の実施形態のASP35が、照合レポート(又は「通知書」)としてまとめてもよい。そして、ステップ1116で、ASP35は、各参加者への支払いとエスクロー口座への送金額を整理して、参加者及びエスクロー口座に支払いの送金を行う。
【0124】
一実施形態によれば、ASPモジュール400は、ステップ1114及び1116を行うように構成されてもよい。これについては
図8を参照して上述した。例えば、ASPモジュール400は、IPSP及び提携銀行が提供するデータの照合結果を、定期的に(例えば、毎日又は毎週)各販売業者31、32、33に送られる照合レポートとしてまとめる。照合レポートは、販売業者31、32、33が特定日までに販売業者の銀行口座にて受け取ることになっている金額の概要を示す。また、照合レポートには、顧客が各販売業者の口座に入金した総額が含まれており、このレポートは以下の差引額及び追加額を示す。すなわち、(1)手数料や料金(一連の支払いにおける全参加者への支払いを含む)の差引、(2)チャージバックや払い戻しに対する安全策としてのローリングリザーブ・エスクロー口座に所定期間(例えば、6カ月又は1年)留保してある総額のうちの、ある割合に対応する「トラスト・ディダクト」(信託差引額)の差引、(3)上記所定期間かつ通知書の日付の前日まで留保してあった「信託金」の追加、(4)以前の取引に関する通知書の日付において提携銀行から通知されたチャージバックの差引、といった差引額及び追加額である。適切な参加者及びローリングリザーブ・エスクロー口座への資金移動の前に、IPSP34は、支払いが行われることになっている日付を含む照合レポートを再検討する。IPSP34からの照合レポートの承認を受けて、ASP35は種々の販売業者31、32、33に照合レポートを送信し、適切な参加者及びエスクロー口座に支払いの送金を行う。一実施形態において、照合レポートの発行及び承認後に資金移動を行ってもよい。他の実施形態においては、照合レポートの承認前に資金移動を行ってもよい。
【0125】
図14に示す他の実施形態によれば、各販売業者に関連する各法人(例えば、SG1、SG2、SG3等)の口座に提携銀行が直接資金を入金する。また、ASPモジュール400aはさらに、各口座において受け取った金額と、IPSP及び提携銀行からそれぞれ得られた決済要求及び支払い報告書を照合するように構成される。一実施形態において、当該口座から種々の参加者又はエスクロー口座に支払われない金額は、販売業者に支払われる。
【0126】
チャージバック処理フロー
チャージバック要求とは、顧客の支払いカード口座に特定料金を払い戻すために、顧客に代わりカード発行銀行が発行する要求である。例えば、顧客が、自分は使用を許可していないと主張する支払いカードへの請求に異議を唱える場合、これに応じて、カード発行銀行がチャージバック要求を発行してもよい。
図11は、本発明の種々の実施形態によるチャージバック要求処理フローの一例1200を示す。
【0127】
ステップ1202から開始し、カード発行銀行37、38、39は顧客からチャージバック要求を受信する。そして、ステップ1204にて、カード発行銀行37、38、39は、提携銀行36にチャージバック要求を送信する。ステップ1206にて、提携銀行36は、チャージバック要求を受信し、それをIPSP34に送信する。次に、ステップ1208にて、IPSP34は、チャージバック要求を元の取引のデータと比較する。チャージバック要求におけるデータが元の取引のデータと一致すると思われる場合、ステップ1210にて、IPSP34はその要求をASP35に送信する。比較及び送信ステップ1208及び1210は、上述のような本発明の種々の実施形態によるIPSPモジュール300により行ってもよい。次に、ステップ1212にて、本発明の種々の実施形態によれば、ASP35はチャージバック金額を販売業者のエスクロー口座から提携銀行36に転送し、提携銀行36は、チャージバック要求を発行したカード発行銀行37、38、39にチャージバック金額を転送する。他の実施形態において、ASP35は、資金不足、支払い不能、破産、及び/又は、販売業者の廃業等、販売業者がチャージバック金額を直接支払うことができない場合のみ、販売業者のエスクロー口座から提携銀行36にチャージバック金額を転送する。他の実施形態において、ASP35は、決済要求において販売業者31、32、33に支払わられるべき総額からチャージバック金額を差し引くことにより、カード発行銀行37、38、39にチャージバック金額を支払う。そして、ステップ1214にて、ASP35はチャージバック要求を記憶する。本発明の種々の実施形態において、ASPモジュール400はステップ1212及び1214を行うように構成される。
【0128】
ステップ1208にてチャージバック要求データが元の取引のデータと一致しない場合、本発明の種々の実施形態によれば、チャージバック要求にフラグを立ててもよい。また、特定の支払いカードに関してフラグが立てられたチャージバック要求の数が、所定期間に所定数(例えば、1週間又は1カ月間に2回のチャージバック要求)を超える場合、IPSPは、今後、販売業者が支払いのために受け付けてはならない支払いカードのリストに、この特定の支払いカードを含めてもよい(例えば、IPSP34が維持する不正行為及び乱用データベース)。
【0129】
上述に加えて、種々の実施形態によれば、ASP35は、特定期間に(例えば、毎日又は毎週)提携銀行36及びIPSP34が処理するチャージバック要求を、元の取引の取引データと照合する。要求を照合するため、ASP35は、ステップ1216として示すように、提携銀行36が発行するチャージバック取引報告書と、IPSP34が発行するチャージバック取引報告書を取得し、これら2つの報告書を元の取引のデータと比較する。一実施形態において、比較ステップ1216は、チャージバック報告書のデータをASPシステム105のメモリに記憶された元の取引のデータとリンクさせることにより行う。一実施形態によれば、チャージバックデータ報告書には以下の情報のうち、少なくとも一部が含まれる。すなわち、(1)チャージバック対象となっている元の取引の照会記号、(2)MID番号、(3)チャージバック要求が発行された日付、(4)「チャージバック」としての取引の記載、(5)フルカード番号、(6)提携銀行が付与した照会記号、(7)カード所有者がチャージバックを開始した理由を示すコードであり、カード発行会社が発行するコード番号である「理由コード」、(8)チャージバック発生理由の記載、(9)チャージバック金額の通貨の種類、(10)チャージバック金額、(11)提携銀行が与えるカード番号又はその一部(例えば、カード番号の最初の4ケタ)、(12)元の取引が「掲載された」又は許可された日付、(13)元の取引が行われた日付、(14)元の取引の「種類」、(15)元の取引の通貨、(16)元の取引金額、(17)取引決済の通貨、(18)決済額、(19)提携銀行が与える元の「デフォルト」通貨、(20)提携銀行が与える元の「デフォルト通貨」金額、(21)提携銀行が特定日の取引に関するデータをIPSPに公開したときに、当該取引を含んでいた「取引バッチ」に対する照会記号である「オリジナル・スリップ」(元伝票)、(22)提携銀行の「アイテム・スリップ」(項目伝票)、(23)元の取引の許可コード、(24)提携銀行の「バッチ番号」、(25)顧客の支払いカード明細書に記載されている販売業者の名称である「販売業者DBA名」、といった情報である。
図8を参照して上述したように、本発明の種々の実施形態によれば、ASPモジュール400は、この照合ステップ1216を行うように構成されてもよい。
【0130】
本発明の種々の実施形態によれば、IPSPシステム104及び提携銀行システム106に各報告書を掲載し、ASPシステム105がダウンロードしてもよい。また、例えば、電子メール、ファクシミリ、CD、DVD、フロッピー(登録商標)ディスク等により、物理的又は電子的に報告書を送ってもよい。
【0131】
支払い処理フロー
電子商取引部門の中には、顧客への払い戻しが必要な部門(例えば、ギャンブル)がある。顧客への支払いは、特にインターネットギャンブルの場合、マネーロンダリングへの悪用の危険が懸念される。本発明の種々の実施形態によれば、システム100は、顧客が販売業者への元の支払いの際に利用した支払いカード口座のみに支払いを行い、顧客と販売業者との間に十分な透明性を有する「閉ループ」を構成することにより、電子商取引に関する危険に対処する。そこで、一実施形態によれば、資金は同じ口座から発生して同じ口座に戻り、全てのマネーフローが追跡可能となるので、電子商取引はマネーロンダリングの手段としては魅力のないものになる。
【0132】
例えば、
図12は、顧客による支払い要求提出時の顧客への支払い処理及び送信フローの例1300を示す。ステップ1302から開始し、販売業者は顧客から支払い要求を受信し、その要求をIPSPに送信する。次に、ステップ1304にて、IPSPは、顧客が国又は地域の当局制裁対象リスト(例えば、米国の「特別指定国民リスト」(Specially Designated Nationals list))に含まれていないことを確認する。また、一実施形態によれば、IPSPは、販売業者が事業を行うかもしれない禁止国のリストに、顧客の国籍(例えば、顧客の請求先住所又は顧客の演算装置のIPアドレスに基づく)が含まれていないことを確認する。種々の実施形態によれば、顧客(又は顧客の国)がリストにある場合、システム100は支払い要求を処理できず、要求は否認される。顧客が制裁対象リストに含まれていない場合(あるいは、禁止国に関係していない場合)、ステップ1306として示すように、IPSP34は支払い要求を販売業者の銀行に送る。要求を受信し、支払い資金が販売業者の口座にあることを確認すると、ステップ1308として示すように、販売業者の銀行は資金をIPSP34に送る。IPSP34は資金を受け取り、その記録をIPSPシステム104に記憶した後、ステップ1310に示すように提携銀行36に資金を移動する。次に、ステップ1312にて、提携銀行36は、資金を受け取ると、販売業者のウェブサイトでの購入(例えば、賭け)に使用された顧客の支払いカードに関連するカード発行銀行37、38、39に資金を送る。種々の実施形態によれば、ステップ1314にて、カード発行銀行37、38、39は、販売業者31、32、33から受け取った金額分、支払いカードに関連する口座にクレジットを与えてもよいし、あるいは、カード所有者として名簿にある顧客に小切手を送ってもよい。
【0133】
Eウォレット(電子財布)
本発明のさらに他の実施形態において(図示せず)、金融取引システム100は、顧客がIPSP34から電子トークンを購入できるようにし、プリペイド式の「Eウォレット」アカウントを作って、所定の値を参加販売業者31、32、33に対して使用できるように構成されてもよい。種々の実施形態によれば、金融取引システム100の特徴を、このEウォレットシステムにも拡張可能である。例えば、販売業者31、32、33が、顧客支払いカードに関連する口座から販売業者口座への資金移動の要求を顧客から受けるのではなく、IPSP34が、顧客のEウォレットアカウントからIPSPの口座への資金移動の要求を受け取る。一実施形態によれば、IPSP34は、販売業者モジュール200及びIPSPモジュール300の各ステップを実行して、カード発行銀行に対する許可及び決済要求を発行し、処理する。決済が行われると、IPSP34は、移動した資金の額を表す電子トークンの金額分、顧客のEウォレットアカウントにクレジットを与える。顧客は参加販売業者31、32、33に対してトークンを使用し、購入を行うことができる。IPSP34は、定期的に(例えば、毎日又は毎週)各販売業者のウェブサイトで使ったトークンの金額に対応する資金を各販売業者31、32、33に移動する。一実施形態において、ASP35はEウォレットアカウントを管理し、IPSP34から参加販売業者31、32、33に支払いを割り当てる。
【0134】
種々の実施形態のEウォレットシステムは、販売業者と顧客との取引の促進に加えて、顧客のプライバシー保護にも役立つ。例えば、顧客が、ある販売業者との取引のためにやりとりを行うとき、顧客はプリペイド式のEウォレットアカウントを使用しているので、多くの販売業者は、顧客のEウォレットアカウントに関する情報以外に顧客に関する情報をさらに求めることがない。その結果、販売業者は顧客の身元を直接知ることがない。販売業者は、顧客のEウォレットアカウントを把握し、全ての取引を顧客のEウォレットアカウントに対して直接行うだけである。
【0135】
また、他の種々の実施形態において、検証システムを用いて顧客の身元を保護することができる。例えば、一実施形態の金融取引システム100は検証システムの拡張可能であり、検証システムが、顧客識別のためのトークン等、固有の個人識別子を販売業者に与える。したがって、顧客は検証システムで登録を行い、検証システムは、顧客が正当であるという、ある程度の保証を販売業者に与える。その結果、顧客の身元は保護され、販売業者は、顧客のトークン以外に顧客に関する情報をさらに求めることなく、顧客との取引に、ある程度の信用を持てる。
【0136】
上述の説明及び添付図面に示す教示を考慮すると、本発明が属する技術分野の技術者にとっては、本発明の多くの変形例や他の実施形態は明らかであろう。したがって、本発明は開示した具体的な実施形態に限定されず、変形例や他の実施形態も添付の請求の範囲の主旨に含まれるものとする。具体的な用語を用いて説明したが、これらは一般的かつ説明的な意味で使用したにすぎず、限定を目的とするものではない。