现在将参考附图更加充分地描述本发明的各种实施例，其中示出 本发明的某些但是不是全部实施例。实际上，本发明可以以许多不同 的形式被实施并且不应该被解释为限制于这里阐述的实施例。而是提 供这些实施例使得所公开的内容将满足适用的法律要求。通篇中相同 的附图标记是指相似的元件。
21简要概述
通常，本发明的各种实施例提供了一种用于电子商业部门的改进
的金融交易处理系统，其（1)更加安全地处理支付交易，（2)有助
于使商家和银行免受欺骗交易、洗钱和未成年人赌博，以及（3)有
助于在被看作构成特殊风险的电子商业区域限制其它滥用，诸如因特
网赌博、旅游和顾客购买电子商品。为了达到上述目标，金融交易系
统的各种实施例（1)为商家、因特网支付服务提供商、收单银行和
卡组织建立了操作和交易处理协议，以及（2)提供用于监视并且处
理支付和相关金融交易的改进了的自动化系统。
例如，在本发明的各种实施例中，为每个商家建立并且以减少收
单银行或者发行银行损失的风险的方式资助循环储备委托账户。例如，根据一个实施例，通过确保有足够的资金可用于处理由商家接收
的退还请求（例如退款和偿还），损失的风险被减小了。根据一个实施例，支付给商家的某百分率的资金被储备并在某个段时间（例如6个月、l年或者3年）被转账到委托账户，如果在时间段中没有使用该资金，资金被转账回商家。因为资助循环储备委托账户的钱出自商家的潜在利润，使用商家的营业用于洗钱方案可能不太引人注意。此外，根据各种实施例，商家可以争论退款请求的场合被限制为使得可
接受的用于争论的场合基本上不增加收单银行或发行银行（例如使用欺骗标志进行标记的交易）的风险。在另一个实施例中，商家可能不被允许在任何场合争论退款。因此，根据各种实施例，循环储备委托账户确保用于处理退款请求的资金的来源，其减少了顾客的损失的风险并可以增加顾客在在线金融交易中将使用担保的可能性。此外，当退还请求被商家资助时，收单银行和发行银行的损失的风险被减小了并可能导致对于商家更有利的营业期（例如更低的交易率或更低的退款率）。
作为另一个例子，在本发明的各种实施例中，金融交易系统的参与者要求彼此遵守本地管理机构。例如，在一个实施例中，如果商家没有遵守，因特网提供商（下面将更加详细地讨论）、收单银行和卡
22组织可以拒绝与商家交易。作为替代，在一个实施例中，参与者可以罚款不遵守的参与者。此外，顾客还可以拒绝与不遵守的商家交易。通过建立这种协议，金融交易系统试图为保持遵守本地管理机构的参与者提供一种市场激励。
根据本发明的各种实施例，金融交易系统的参与者可以包括在线
顾客、在线商家、因特网支付服务提供商（IPSP)、收单银行、发行银行或者卡组织。IPSP在网络上在商家和收单银行之间运作以把与
支付相关的服务提供给商家和商家与收单银行之间的界面。此外，
IPSP可以与记帐服务提供商（ASP)签订合同以提供与IPSP提供给商家的支付服务相关的记帐管理服务。
图1根据本发明的各种实施例示出了各个参与者怎样与彼此接口的高级示意图。例如，参与者可以在网络（例如因特网、私有网络或者私有LAN网络）上电子地交换交易信息。特别地，交易信息可以包括来自商家的把钱从与顾客支付卡相关联的账户转账到商家的账户的授权请求、来自发行银行的授权钱从顾客的账户转账到商家的账户的授权消息、来自发行银行的请求钱从商家的账户转账到顾客的账户的退还（例如退款或偿还）请求，以及每个商家在特定时间段（例如，24小时、48小时或一周）期间处理的所有交易的结算请求。
尽管以上讨论的实施例描述了使用与账户相关联的支付卡（例如借记卡、信用卡、预付卡或感应卡）从在线商家购买商品和服务，应该理解在各种其它实施例中，其它类型的支付模式可以被用于进行购买。例如，替换的支付模式可以包括使用与账户相关联的支付代币（例如物理的或电子的代币）或使用与账户相关联的号码（例如用于访问账户的账户号和口令）。其它支付模式可以包括通过使用与账户相关联的生物测定数据授权支付，诸如例如虹膜扫描、指紋和声音识别。支付还可以通过账户号和可以由代币或者经由电话、电子邮件或短消息服务（"SMS")提供的一次性口令的组合被授权。
如以上简单讨论的，根据各种实施例的金融交易系统提供了 （1)针对参与者的操作和处理协议和（2)适配于处理具有高级别安全的金融交易的自动化监视和处理系统（例如计算机软件和/或硬件）。这些协议和自动化系统用于保护顾客和参与者免于欺骗交易和可能在
电子商业交易中创造风险的其它滥用。以下在部分A中详细描述由系统实施的协议的各种例子，以及以下在部分B中描述自动化系统的各种实施例。在部分C中详细描述通过金融交易系统处理的各种交易的示例性流程。
A.示例性协i义
金融交易系统的各种实施例为参与者提供了操作和处理协议。根据各种实施例，阻止有组织的犯罪和使用商家的营业进行洗钱计划的协议服务，减少了通常与在线金融交易相关联的欺骗和未授权交易的风险并减少了收单银行和发行银行的损失的风险，并增加了遵守政府或本地管理规章的或然率。例如，根据本发明的各种实施例，参与者应该能够表明遵守本地或司法管理机构并应该保持在特定时间段（例如，2年、3年或5年）内处理的交易的可审计记录。此外，协议可以要求每个参与者在进入与其它参与者签订合同之前表明遵守本地
管理要求，以及协议可以要求参与者周期地验证其它参与者保持与本地管理机构好的声誉。以下描述可以为商家和IPSP建立的各种示例性协议。赵
根据本发明的各种实施例，商家可以被要求完全地公开公司主管、职员和受益股东的身份并把任何变化报告到IPSP。要求提供这个列表并把该列表与被怀疑参与有组织的犯罪的人和实体的列表比较，可以帮助阻止有組织的犯罪链使用商家的营业用于洗钱或其它非法目的。
此外，根据本发明的各种实施例，商家可以被要求采取有助于减少来自欺骗交易的收单银行、发行银行和顾客的损失的风险的一个或多个步骤。例如，根据各种实施例，商家可以被要求（1)表明遵守所有相关管理要求，（2)任何契约责任被破坏时支付惩罚付费，（3)使用地址验证、年龄验证和在商家的计算装置上的身份验证软件，来
24验证在在线交易期间提供的支付信息和顾客信息，（4)对所接收的支付和顾客信息执行初始欺骗检验并之后执行随机或周期检验，或(5 )把通知提供给正在使用IP地址访问系统的顾客或者提供与其中交易被视为非法的权限相关联的账单地址的顾客。
而且，根据各种实施例，商家可以被要求执行减轻与商家的营业相关联的滥用（如果有）的风险或者与商家进行的交易的可见的社会影响（例如强制花费，如果商家是在线赌博商家或成人娱乐提供商）的协议。例如，商家可以被要求提供关于它的营业的社会影响的建议和帮助资源（例如免费的帮助热线电话号码、提供有帮助的信息的网站或顾问的联系信息）。此外，根据一个实施例，商家可以被要求在顾客的支付卡清单上提供商家的姓名和免费电话号码，使顾客可以呼叫顾客服务和查询交易。根据本发明的各种实施例，顾客服务代表应该是24/7可用的。
根据本发明的各种实施例，IPSP可以被要求实施一个或多个以下的安全特征以帮助阻止有组织的犯罪链或来自使用商家营业用于洗钱目的其它犯罪，并为各种参与者减少与在线金融交易相关联的风险：（1)为每个商家建立将处理来自它的退还请求的循环储蓄委托账户，诸如以上讨论的委托账户，（2)监视交易，以识别可疑的活动，（3)以每张支付卡为基础监视交易的频率和数值，（4)为跟踪和审计的目的，把每个商家（或网站）的交易保持在分开的流中，（5)周期地（例如每2秒或每10秒）保存交易信息以创建审计审问以及在特定时间段（例如1年、2年或5年）存储交易信息，（6)验证卡持有者的身份，（7)要求商家公开公司主管和受益股东给IPSP, (8)限制从因特网赌博商家到卡持有者的奖金的支付并从可适用的制裁列表（例如U.S."特别指定国家列表，，）筛选收款人的姓名，（9 )要求商家在可适用本地法律和规章下被许可并保持好的金融和法律声誉，（10)惩罚被发现破坏契约责任的商家（例如，通过终止与商家的合同或罚款商家），（11)在良好管理的司法中使用几个Tierl收单银行并由它们保证，（12)要求商家实施目的在于保持卡持有者信 息安全的政策、步骤和标准（例如，由VISA的账户信息安全（"AIS") 项目保证），和（13 )操作和应用Financial Action Task Force on Money Laundering的4,荐（例如，www,FATF-GAFLorg )(例如，参见附 录A中的"Anti-Money Laundering/Combating Terrorist Financing Methodology(yith FATF 40+9 incorporated)"(由 International Monetary Fund发行））。此外，在各种实施例中，IPSP保持欺骗 数据库42，如在图l中所示的，用于存储关于由IPSP处理的呈现为 或被确定为欺骗的交易的信息。根据一个实施例，当处理交易时IPSP 允许其它参与者利用欺骗数据库，进一步减少了发行银行、收单银行、
商家和顾客的损失的风险。尽管IPSP可以管理它自己的记帐和欺骗 数据库、协调它处理的交易，并为商家生成协调报告，但根据另一个 实施例，IPSP可以与ASP签订合同以提供这些服务中的一个或多个 服务。
此外，根据本发明的一个实施例的示例性协议可以要求IPSP为 每个商家创建分开的公司实体（例如，SG1、 SG2、 SG3等），以及 这些公司实体在IPSP和/或ASP的指导下操作，以管理为与公司实体 相关联的特定商家接收的资金，这将参考图14更详细地讨论。根椐 各种实施例，该公司结构把每个商家的操作分离。此外，根据各种实 施例，该公司结构提供确保公平和客观地管理委托资金的合法结构， 委托资金是为了保护金融交易系统和顾客。
根据本发明的各种实施例，示例性协议可以要求收单银行实施一 个或多个以下的安全特征以减少与在线交易相关联的发行银行和顾 客的风险：（1)监视在线商家的信用活动以确保顾客能够从商家接 收奖金或点数到他们的支付卡上（例如，由VISA赞助的卡持有者资 金转账（CFT)导引，，和由MasterCard赞助的Money Flow导引）， (2 )确保所有卡组织规章被传送到IPSP和商家，（3 )确保交易信 息具有正确的数据单元，如由卡组织和发行银行规定的，和（4)确保IPSP遵守可适用的管理计划。
^与者之河的为定
根据本发明的各种实施例，一个或多个系统协议可以被并入参与
者之间的约定以确保遵守建立的协议。例如，图2根据本发明的各种 实施例示出参与者之间的契约关系的示意图。特别地，收单银行36、 IPSP 34和每个商家31、 32、 33可以进入三方处理合同45，其阐述 了关于交易怎样被处理的每方的责任。该约定45可以要求每方保持 与本地管理机构的良好声誉，提供主管、职员和受益股东的更新列表 给其它方，执行某种身份验证和对交易信息的欺骗检验，并在特定时 间段（例如，l年、3年、5年）为了审计目的存储交易信息。此外， 根据一个实施例，约定45可以包括一个或多个其中商家可以争论退 款请求的场合。根据另一个实施例，约定45可以建立商家31、 32、 33针对退款应担负的费用。
此外，收单4艮行36和IPSP 34可以进入信任约定47，其阐述IPSP 应该对交易数据实施的特定欺骗检验和以每个商家的名义，IPSP何 时应该请求结算（例如，每天或每周）。
ASP 35和每个商家31、 32、 33可以进入委托约定49，其阐述 商家ASP将怎样以商家的名义管理循环储蓄委托账户（例如资金被拿 出用于委托账户的百分比，资金被存储在委托账户中的时间长度或者 协调报告的格式）。
此外，ASP35和IPSP34可以进入服务约定43，其阐述关于由 ASP提供给IPSP的记帐服务的每方的责任（例如，在ASP和IPSP 之间交换的数据的格式和可访问性，为IPSP 34或以IPSP34的名义 由ASP生成的摘要报告的类型和格式，可支付给一个或多个参与者的 费用的计算，或者为商家审批协调报告的审批步骤）。此外，在一个 实施例中，ASP35可以由约定43要求，以响应于来自商家31、 32、 33的关于由IPSP 34或由ASP 35为了 IPSP 34处理的交易的查询。 此外，在另一个实施例中，ASP 34可以被要求（a)识别由ASP 35 以IPSP 34的名义处理的所有交易数据和（b)把识别的数据转发到商家31、 32、 33以确定如果有，关于退款请求商家31、 32、 33希望 采取什么进一步的行动。
B.用于监视和处理交易的自动化系统
本领域的技术人员将理解，本发明可以作为一种方法、 一种交易
处理系统或一种计算机程序产品被实施。因此，本发明可以采取完全
硬件实施例、完全软件实施例或软件和硬件方面结合的实施例的形
式。此外，本发明可以采取在计算机可读存储介质上具有在存储介质
中实施的计算机可读程序指令（例如计算机软件）的计算机程序产品
的形式。更特别地，本发明可以采取网站实现的计算机软件的形式。
任何合适的计算机可读存储介质可以被利用，包括硬盘、CD-ROM、
光学存储介质或磁存储介质。
以下将参考根据本发明的实施例的方法、设备（即系统）和计算
机程序产品的框图和流程图描述本发明。应该理解，框图和流程图的
每个方块，以及在框图和流程图中的方块的组合，可以分别由计算机
程序指令实施。这些计算机程序指令可以被下载到通用计算机、专用
计算机或者其它可编程数据处理设备上以产生一种机器，使得在计算
机上或其它可编程数据处理设备上执行的指令创建一种用于实施在
流程图框中指定的功能的装置。
这些计算机程序指令还可以被存储在能够指导计算机或其它可
编程数据处理设备以一种特定的方式运行的计算机可读存储器中，使
得存储在计算机可读存储器中的指令产生一种包括用于实现在流程
图或框中指定的功能的计算机可读指令的产品。计算机程序指令还可
以被下载到计算上或其它可编程数据处理设备上以使在计算机上或
其它可编程设备上执行的一 系列操作步骤生成计算机实现过程，使得
在计算机上或其它可编程设备上执行的指令为实现在流程图框中指
定的功能。
因此，框图和流程图的方块支持用于执行指定功能的装置的组 合、用于执行指定功能的步骤的组合和用于执行指定功能的程序指令 装置。还应该理解，框图和流程图的每个方块，和在框图和流程图中
28的方块的组合可以通过执行指定功能或步骤的基于硬件的专用计算 机系统或者专用硬件和计算机指令的组合被实现。
在这里描述的各种实施例中，"计算机，，或"计算装置"可以被提 及。这种计算才几可以是，例如大型机、台式才几、笔记本电脑或膝上型 电脑、诸如数据获取和存储装置的手持装置，或者它可以是配备在另 一个设备中的处理装置，诸如例如无线电话。在某些例子中，计算机
可以是用于在网络上访问数据或处理器的"哑"终端。转到图3A，计 算装置的一个实施例被示出，其可以被用于实现本发明的各种实施 例。在图3A中，处理器1，诸如微处理器，被用于执行实现规定步 骤的软件指令。处理器从当需要时也为其它部件提供能量的电源17 接收能量。处理器1使用通常是16或32比特宽（例如，并行的）的 数据总线5通信。数据总线5被使用来转送数据和程序指令，典型地 在处理器和存储器之间。在各种实施例中，存储器可以被认为是仅在 运行期间保留内容的RAM或其它形式的主存储器2，或者它可以是 非易失性存储器3，诸如ROM、 EPROM、 EEPROM、 FLASH或其 它类型的在所有时间都保留存储内容的存储器。存储器还可以是辅助 存储器4，诸如存储大量数据的磁盘存储器。在某些实施例中，磁盘 存储器可以使用I/O总线6,代替地或专用总线（未示出）与处理器 通信。辅助存储器可以是软盘、硬盘、光盘、DVD或者计算机领域的 技术人员已知的任何其它类型的大容量存储器类型。
处理器1还使用I/O总线6与各种外围或外部装置通信。在各种 实施例中，外围I/O控制器7被用于提供标准接口，诸如RS-232、 RS422、 DIN、 USB或合适与各种输入/输出装置接口的其它接口。典 型的输入/输出装置包括本地打印机18、监视器8、键盘9和鼠标10 或其它典型的指向装置（例如、轨迹球、触摸板、操纵杆等）。
处理器1通常还使用通信I/O控制器11与外部通信网络通信， 并可以使用各种接口 ，诸如数据通信有关的协议12，诸如X.25、ISDN、 DSL、线缆调制解调器等。通信控制器11还可以并入用于与标准电 话线13接口和通信的调制解调器（未示出）。最终，通信I/0控制
29器可以并入用于LAN上通信的以太网接口 14。这些接口中的任何一 个可以^f皮用于访问广域网，诸如因特网、内联网、LAN或其它数据通 信设施。
此外，处理器1可以与可操作地连接到天线15用于通过使用例 如IEEE 802.11协议、802.15.4协议或标准3G无线通信协议诸如 CDMA2000 lxEV-DO、 GPRS、 W-CMDA或其它协议与另 一个装置 进行无线通信的无线接口 16通信。
在图3B中示出可以使用的处理系统的替代实施例。在该实施例 中，示出了包括与本地客户计算机26a或远程客户计算机26b通信的 服务器20的分布通信和处理体系结构。服务器20通常包括与数据库 22 (例如SQL数据库）通信的处理器21，其可以被看作辅助存储器 以及主存储器24的一种形式。处理器还使用通常与LAN 25接口的 I/O控制器23与外部装置通信。LAN可以提供与网络打印机28和本 地客户计算机26a的本地连接。这些可以被置于与服务器相同的设施 中，尽管不一定在同一个房间中。与远程装置的通信典型地通过通信 i殳施把来自LAN25的数据路由至广域网27、诸如因特网而完成。远 程客户计算机26b可以执行网络浏览器，如有需要，通过广域网27 在LAN 25上把数据发送到服务器20,而允许远程客户26b与服务器 交互。此外，网络浏览器可以包括例如以Java Scrip和Microsoft.net 开发的用户接口。
数据网络的技术人员将意识到许多其它替代和体系结构是可能 的，并且可以被用于实施本发明的各种实施例。在图3A和3B中所示 的实施例可以以不同的方式被修改并且在本发明的范围之内。
图4示出根据本发明的各种实施例的、与每个参与者相关联的、 并且与经由一个或多个网络115(例如私有网络、私有LAN网络或因 特网）互相通信的计算装置101-109。例如，根据一个实施例，IPSP 34可以建立可由商家31、 32、 33和收单银行36通过把IPSP网络连 接到由商家31、 32、 33和收单4艮行利用的网络的IPSP网关40访问 的IPSP网络。根据各种实施例，IPSP网关40可以完全作为硬件、完全作为软件或作为两者的组合被实施。在一个实施例中，IPSP网 关40通过选择性地允许访问IPSP网络确保被发送到IPSP网关40 的和从其发送的信息的安全。例如，与IPSP34没有契约关系的商家 31、 32、 33或收单银行36可以被拒绝通过IPSP网关40访问IPSP网络。
此外，根据本发明的各种实施例，收单银行36可以利用卡组织 网络以与收单银行37、 38、 39交换信息。卡组织网络的例子包括但 不限于VISA、 MasterCard和American Express网络。
如上参考图3A和3B讨论的，根据各种实施例，商家31、 32、 33、 IPSP 34、 ASP 35、收单银行36和发行银行37、 38、 39可以与 一个或多个计算装置（例如， 一个或多个服务器、SQL服务器或网络 浏览器）相关联，并且这些计算装置中的一个或多个可以包括用于处 理金融交易的自动化系统。例如，系统IOO提供了被配置为在商家的 系统IOI、 102、 103上运行的商家模块200，；帔配置为在IPSP的系统 104上运行的IPSP模块300，和被配置为在ASP的系统105上运行 的ASP才莫块400。根据一个实施例，这些模块200、 300、 400使每个 参与者的处理功能自动化。这些模块可以完全作为硬件、完全作为软 件或作为两者的组合被实施。
此外，根据本发明，如果IPSP 34与ASP 35签订合同提供记帐 相关的服务，ASP模块400可以被配置为在ASP系统105上运行， 或者，在另一个实施例中，ASP模块400可以被配置为在IPSP的系 统104上运行。以下参考图5-8更加详细描述这些模块的各种实施 例。
艰家淑
图5示出根据本发明的各种实施例的商家模块200的框图。根据 各种实施例，商家模块200在商家系统101、 102、 103上运行，并且 使商家执行的处理交易的步骤的至少一部分自动化。例如，商家模块 200被配置为处理授权请求，这被示为步骤202。在步骤202，商家模 块200从顾客接收支付信息，其可以包括商家的全名和账单地址、电子邮件地址、信用卡号、CVV2号、支付数量或卡发行商名称中的某 些或全部。然后商家模块200验证接收的支付信息的格式，诸如验证 信用卡号是否是有效的号码以及是否所有的字段都已经被完成。商家 模块200还可以被配置为比较顾客信息和之前存储的与3-D安全软 件插件（例如，Visa的Verify和MasterCard的SecureCode )相关 联的标识和口令。如果格式是正确的，商家模块200生成并且发送授 权请求到IPSP系统104，用于进一步的处理。
根据本发明的各种实施例，商家模块200还被配置为在接收的交 易请求上执行初步欺骗检验，如步骤206所示。初步欺骗检验步骤206 可以包括例如比较信用卡号和被窃的信用卡号的列表，验证由顾客提 供的账单地址与支付卡的账单地址匹配，比较提供的账单地址和当顾 客初始商家向商家登记时提供的账单地址，或者验证卡发行商的名称 与卡的银行识别号（BIN)匹配。此外，欺骗检验步骤206可以在授 权请求被发送到IPSP (步骤202)后，如在图5中所示，或者在生成 和发送授权请求之前（未示出）被执行。在一个实施例中，欺骗检验 步骤206在授权请求已经被发送（步骤202 )之后但是在与发行银行 结算之前被执行。
如果在欺骗检验步骤206中没有检测出潜在问题，商家模块200 验证顾客的年龄和身份，如步骤210所示。例如，年龄可以通过检验 卡持有者的政府记录被验证，诸如投票人登记记录或驾驶证记录，或 者通过建立与电子年龄和/或身份验证服务（例如，由基于UK的GB Group提供的"URU，，服务）的网络连接和提供顾客的信息给该服务而 被验证。根据各种实施例，所述服务比较顾客的信息和政府或者其它 公共记录，以验证顾客的身份和年龄。在一个实施例中，当顾客建立 与商家的新账户时商家模块200可以执行年龄和身份验证步骤210。 步骤210的过程可以被周期地或随机地重复进行，之后重新验证现有 顾客的身份和年龄。此外，在图5中所示的实施例中，年龄和身份验 证步骤210被示出为在欺骗检验步骤206和授权请求步骤202之后发 生。然而，在其它实施例中，年龄和身份验证步骤210可以在授权请求步骤202或欺骗检验步骤206之前发生。
根据一个实施例，如果顾客的年龄和身份没有在年龄和身份验证 步骤210中验证或者如果欺骗检验步骤206检测到交易的潜在问题， 商家模块200可以通知顾客交易被拒绝，和通知IPSP交易应该被拒 绝，如步骤208所示。
此外，根据各种实施例，商家模块200被配置为显示或者相反通 知顾客特定时间段（例如，每次会话、24小时或一周）期间花在商家 的网站上的时间数量。拥有这种信息可以帮助顾客避免关于商家的网 站的强制行为。此外，商家模块200可以被配置为允许顾客访问由商 家保存的顾客的交易日志。此外，商家模块200可以被配置为实现自 身动调节方针，诸如例如损失的极限（例如赌博交易），或者在商家 的网站上花的时间和/或钱。
为了避免洗钱，商家模块200还可以被配置为执行反洗钱软件 (例如把可获得的数据与在由International Monetary Fund发行的 "Anti-Money Laundering/Combating Terrorist Financing Methodology (with FATF 40+9 incorporated)"中阐述的参数比较的软 件），作为附录A附上，以评估在选择的数量中（例如15000英镑或 20000美元）的任何交易。软件的评估可以包括身份验证和重新验证， 跟着是对验证的个人或公司的检验。
mr户模块
图6示出根据本发明的各种实施例的IPSP模块300的流程图。 根据一个实施例，IPSP模块300被配置为在IPSP系统104上运行。 从步骤302开始，根据一个实施例，IPSP模块300处理从商家系统 101、 102、 103接收的授权请求。每个授权请求可以包括特定交易的 支付信息和与交易相关联的顾客信息，诸如顾客的全名、顾客的电子 邮件地址和由顾客使用以发起交易的计算装置的IP地址。根据本发 明的各种实施例，然后IPSP模块300把授权请求发送到收单银行系 统106，收单银行系统把授权请求发送到合适的发行银行系统107、 108、 109。如以下参考图9A和9B更详细地讨论的，根据各种实施例，
33IPSP模块300从发行银行系统107、 108、 109经由收单银行系统106 接收授权消息，授权或拒绝交易，并且IPSP模块300把授权消息发 送到商家系统IOI、 102、 103。
根据各种实施例，在步骤304， IPSP模块300存储由IPSP模块 300处理的交易信息（例如授权请求、退款请求、偿还请求和结算请 求）。存储的交易信息可以被用于审计目的，基于每个顾客、每个支 付卡或每个商家监视交易的类型和频率，以及生成结算请求并响应于 结算请求，分配接收的资金的支付。例如，授权、退款和偿还请求可 以被周期地存储，诸如例如每秒或每十秒，或者基于每次交易，诸如 每当IPSP模块300接收和处理交易信息时。这些请求可以被存储特 定时间段（例如一天或一周或更长）。此外，根据各种实施例，请求 可以基于每个商家被存储（或如果商家具有多于一个网站支持电子商 业交易，则基于每个URL (统一资源定位器））。IPSP模块300周 期地（例如每天或每周）把每个商家的授权请求集合成每个商家的结 算请求文件，并把商家的结算请求在批处理文件中发送到收单银行系 统106用于结算，下面将参考步骤310对其进行讨论。IPSP模块300 可以把集合的交易信息作为分开的文件存储一定的时间段（例如，一 年、两年或三年）。
在本发明的各种实施例中，IPSP模块300还被配置为执行欺骗 阻止子模块350，其在图6中作为步骤306被示出并以下参考图7A 和7B更详细地讨论，用来验证交易应该由系统IOO进行结算。例如， 如果支付卡号被在偷窃的支付卡号的列表上列出，顾客的IP地址的 国家与支付卡发行的国家不匹配，或者顾客在国家制裁列表上（例如， 美国的"Specially Designated Nationals list") ， IPSP才莫块300将不显 示结算的交易。在图6中所示的实施例中，欺骗阻止子模块350的执 行被示出，其在授权请求处理步骤302和交易信息存储步骤304之后 发生。然而，根据本发明的其它实施例，步骤306可以在步骤302中 的发送授权请求到收单银行系统106之前或者在步骤304中的存储交 易信息之前由IPSP模块300执行。
34根据本发明的各种实施例，如果欺骗阻止子模块350在步骤306 中检测到交易的潜在的欺骗的活动，IPSP模块300被配置为把被怀 疑的欺骗活动通知合适方，这在步骤308中被示出。根据各种实施例 的合适方可以包括收单银行36 (其可以把通知传递到发行银行）、发 行银行37、 38、 39 (直接地）、商家31、 32、 33和/或顾客。此外， 根据各种实施例，IPSP模块300被配置为在欺骗数据库42中存储关 于潜在的欺骗交易的信息，如步骤312所示。欺骗数据库42可以由 IPSP模块300利用来分析随后的交易。此外，在一个实施例中，欺 骗数据库42可以被卡发行商网络和/或收单银行访问以分析接收的交 易。此外，欺骗数据库42可以包括一个或多个以下字段：顾客姓名、 地址、IP地址、支付信息（例如卡或账户号）、电话号码和识别之前 欺骗活动的代码或描述。
如在步骤310中所示，根据本发明的各种实施例，如果欺骗阻止 子模块350在步骤306中没有检测到任何潜在的欺骗活动，IPSP模 块300被配置为生成和发送结算请求到收单银行系统106或发行银行 系统107、 108、 109。结算请求是基于在特定时间段（例如一天或一 周）中由IPSP模块300接收的授权、退款和偿还请求。根据一个实 施例，结算请求可以仅包括那些没有被IPSP模块300和商家模块200 作为潜在的欺骗被检测出的交易。作为替代，结算请求可以包括已经 被IPSP模块300或商家模块200作为潜在的欺骗检测出的、但是在 结算请求中标记或标志为潜在的欺骗的一个或多个交易。
如上所述，IPSP模块300在步骤306中执行欺骗阻止子模块350。 根据本发明的各种实施例，示例性欺骗阻止子模块350在图7A和7B 中被示出。如在图7A和7B中所示，欺骗阻止子模块350执行各种步 骤，这里被称为"欺骗过滤"，以检测潜在的欺骗交易活动，并可以被 配置为根据特定欺骗过滤器的结果或来自欺骗过滤器组的结构的组 合，阻挡或标志交易。根据本发明的各种实施例，步骤352-368示 出可以由欺骗阻止子模块350执行的几个欺骗过滤器。图7B示出根 据本发明的各种实施例的由欺骗阻止子模块350执行的确定对交易信
35息应用哪个欺骗过滤器的步骤。
例如，如在图7A中的步骤352中所示，欺骗阻止子模块350可以比较支付卡信息和标识被窃支付卡的列表。此外，如在步骤354中所示，欺骗阻止字模块350可以比较与发行支付卡的金融机构相关联的位置和与和顾客的计算装置相关联的IP地址相关联的位置。当交
易信息由商家系统IOI、 102、 103初始接收时，与顾客的计算装置相关联的IP地址可以由商家模块200获得（例如通过使用被集成到商家模块200中的IP地址检测软件）。此外，欺骗阻止子模块350可以被配为比较与顾客的计算装置的IP地址相关联的位置和顾客的账单地址以确保顾客的计算装置的位置在账单地址的特定范围之内（例如50英里）。相似地，欺骗阻止子模块350可以比较与发行支付卡的金融机构相关联的位置和与顾客提供的电子邮件地址相关联的位置，如在步骤356中所示，或者比较顾客的计算装置的IP地址的位置和与顾客提供的电子邮件地址相关联的位置，如在步骤357中所示。以上比较的位置可以包括国家、区域、州、地区、县、城市或者由一个或多个邮政编码限制的邮政区域中的一个或多个。
此外，如在步骤358中所示，欺骗阻止子模块350可以比较支付卡的银行识别号（BIN)和可疑的BIN的列表，以及在步骤360中，欺骗阻止子模块350可以识别和标志由具有网络邮件电子邮件地址(例如，HOTMAIL或YAHOO电子邮件地址）的顾客发起的交易。此外，如在步骤362中所示，欺骗阻止子模块350可以比较顾客的信息和政府编译的在政府的权限中被禁止与商家进行金融交易的个人的列表。如果顾客被识别为在受到由权限公布的金融制裁的个人、集团和实体的列表上，诸如由U.S.发行的"Specially Designate Nationalslist",则交易可以被拒绝。相似地，如在步骤368中所示，欺骗阻止子模块350可以比较与顾客的计算装置的IP地址相关联的国家和在特定权限中被禁止与商家进行交易的国家的列表，并且如果IP地址的国家在所述列表上，则交易可以被拒绝。此外，如在步骤367中所示，欺骗阻止子模块350可以比较顾客的信息和在线商家的职员、主管或业主商家的列表，并且如果顾客在列表上，则交易可以被标志为潜在的欺骗或被拒绝。
根据各种实施例，欺骗阻止子模块350还可以被配置为监视在特定时间段期间（例如一个月、 一年）每个顾客或每张卡的交易的频率，如在步骤364中所示。此外，如在步骤366中所示，欺骗阻止子模块350可以被配置为监视在特定时间段期间为顾客或卡的交易的类型(例如，赌博交易、旅游交易、成人娱乐交易）。根据本发明的各种实施例，通过基于每卡或每顾客监视交易的频率和类型，欺骗阻止子模块350可以（1)如果卡的使用显著地改变，则识别它的潜在欺骗的使用和（2)如果顾客更加频繁地或太频繁地参与特定类型地交易，则识别潜在的嗜好或滥用。根据一个实施例，监视步骤364和366可以通过基于顾客之前的交易建立交易的频率和类型范围和比较将来的交易与所建立的范围而被完成。根据其它实施例，欺骗阻止子模块350使用的范围可以由本地政府或管理机构公开，可以从学术的或学院的研究等等得出，或者可以由一个或多个参与者建立。
图15示出根据本发明的各种实施例的监视强制花费行为的过程。具体地，从步骤502开始，由IPSP模块300接收金融交易的新请求。响应于接收到新请求，IPSP模块300提取已经存储在存储器24中的、与之前请求的在特定商家31、 32、 33和顾客之间的金融交易相关联的资金总额，如步骤504所示。在步骤506，提取的资金总额的总数量和在新请求中的资金的数量与预定的可接受的花在商家31、 32、 33上的资金的极限相比较。如果总数量超过预定的可接受的极限，IPSP模块300通知合适方（例如顾客、发行银行和/或商家）已经超出极限，如在步骤508中所示。在本发明的替代实施例中，IPSP模块300被配置为用于比较在特定时间段期间在顾客和商家之间进行的交易的数量，并且如果进行的交易的数量超出预定的可接受的极限，那么IPSP模块300通知顾客、发行银行和/或商家：极限已被超出。
相似地，图16示出根据本发明的各种实施例的监视强制赌博行为的过程。从步骤602开始，金融交易的新请求由IPSP模块300接收。新请求可以包括资金的数量和交易的类型（例如，把资金转账到商家，与商家打赌，请求从商家支出）。接下来，在步骤604， IPSP模块300为在新请求中的金融交易类型提取被存储在存储器24中的资金总额。然后，在步骤606，资金总额的总数量和在新请求中的资金数量与预定的可接受的、与在新请求中的金融交易类型相关联的极限。如果总数量超出预定可接受的极限，IPSP模块300通知合适方(例如，顾客、发行银行和/或商家）：已经超出极限，这在步骤608中被示出。在一个实施中，如果总数量超出预定的可接受的极限，则拒绝新请求。此外，从存储器提取的资金总额可以被限制于在特定时间段内存储的那些资金，并且预定的可接受的极限可以基于查询的时间段被改变。
除了以上提到的监视交易的类型，根据本发明的各种实施例，欺骗阻止子模块350还可以被配置为监视退还请求交易和识别可疑的交易。响应于识别可疑的退还请求交易，诸如通过识别其中退还请求信息与在原先交易中的信息不一致的交易或者通过识别特定时间段期间（例如，在一周、 一个月或者几个月中）特定支付卡的很大数量的退还请求交易，支付卡号可以被添加到禁止的支付卡的列表，因此阻止使用该支付卡的未来购买交易。
除了以上的过滤器，根据本发明的各种实施例，欺骗阻止子模块350还可以被配置为（1)确保每个顾客仅使用一个支付卡和（2)把在特定时间期间每个顾客的某种活动的支付限制为特定的频率（例如，每天一次支付或每36小时三次支付）。此外，根据一个实施例，可以设置在特定时间段期间（例如，每天、每周或每月）在特定服务(例如，因特网赌博或成人娱乐）上每卡或每顾客可以花费的数量的最高限度。在一个实施例中，最高限度可以按照顾客的要求设置。在另一个实施例中，IPSP系统104可以对可以花费在某种活动上的数量引进默认的极限（例如，与支付卡相关联的信用卡的极限的20% )，如果没有顾客的明确的请求这不能增加。根据一个实施，IPSP系统104或商家系统101、 102、 103可以被配置为响应于接收增加花费极限的请求，把关于过度花费的风险的材料呈现给顾客，诸如经由来自专门培训的雇员的电话或到顾客的电子邮件，并且当潜在的滥用被检测到时呈现材料或资源（例如，赌博者匿名电话号码、网站地址或其它材料）。
根据本发明的各种实施例，IPSP系统104还包括存储来自欺骗阻止模块350的结果的欺骗和滥用数据库（未示出）。在一个实施例中，当处理交易（步骤302)时或当执行欺骗阻止子模块（步骤306)根据之前的特定支付卡或顾客的欺骗检验，以确定交易是否应该被拒绝时，IPSP模块300访问数据库。
如在图7B中所示，根据本发明的一个实施例，欺骗阻止子模块350可以使用以上描述的欺骗过滤器中的一个或多个以评估接收的交易信息。从步骤370开始，欺骗阻止子模块350从IPSP模块300接收交易数据。接下来，在步骤372中，欺骗阻止子模块350确定该一个或多个过滤器在评估交易数据中使用。例如，根据一个实施例，欺骗阻止子模块350使用之前由商家选择使用的欺骗过滤器。根据另一个实施例，使用的欺骗过滤器的类型依赖于交易的类型（例如，授权请求、退款请求、结算请求或支付请求）或者交易的哪一个阶段（例如交易信息是否还没有被发送到发行银行或者它是否已经被发行银行授权）。在另一个实施例中，使用的欺骗过滤器的类型依赖于与顾客相关联的IP地址的国家。并且在另一个实施例中，选择应该应用哪一个欺骗过滤器由IPSP和/或本地管理机构决定。最后，在步骤374中，欺骗阻止子模块350执行合适的欺骗过滤器以评估交易数据。
根据本发明的各种实施例，除了执行欺骗阻止子模块350以外，IPSP模块300还被配置为用于识别非法的或受管理限制的金融交易。例如，图18示出识别非法或被限制的金融交易的示例性过程。从步骤802开始，IPSP模块300从顾客的支付卡接收把资金转账到商家31、 32、 33的请求。转账资金的请求包括顾客的账单地址和与由顾客使用以生成请求的计算装置相关联的IP地址的位置。接下来，在步
39骤804中，IPSP模块300把顾客的账单地址、IP地址的位置和商家31、 32、 33的位置与管理到商家31、 32、 33的资金转账的位置的列表比较。如果这些位置中的任何一个与位置列表上的位置匹配，则IPSP模块300确定一个或多个管理机构是否管理在这些位置中的任何一个中的资金转账，如在步骤806中所示。如果IPSP模块300确定一个或多个管理机构管理资金的转账，则IPSP模块300通知合适方（例如，顾客、商家和/或发行银行）资金的转账承受的一种或多种类型的规章，如在步骤808中所示。金融交易可能承受的规章的类型包括禁止转账（例如，在赌博是非法的州或地区中的赌博交易）或限制转账（例如，在限制打赌的资金数量州或地区中的赌博交易）。
图8示出根据本发明的各种实施例的ASP模块400的框图。尽管根据一个实施例，ASP模块400可以被配置为在ASP系统105上运行，但根据另 一个实施例，如果IPSP没有与ASP签订合同提供记帐管理服务，它还可以被配置为在IPSP系统104上运行。
从步骤402开始，根据一个实施例，ASP模块400从IPSP系统104和收单银行系统106获得交易信息。从IPSP系统104获得的交易信息针对每个交易可以包括以下数据字段：（1)商家识别（"MID")号，其由收单银行授予，以标识商家或商家的交易实体（例如，特定网站）；（2)交易的日期和时间；（3)顾客的姓名：（4)支付卡号或支付卡号的一部分（例如，最后四位数字）；（5)卡持有者的电子邮件地址；（6)交易的货币；（7)使用的支付卡的类型（例如，Visa、 MasterCard或American Express) ; (8)支付数量； (9)商家分配给交易的定单参考号；（IO)授权代码，其是由发行银行生成的唯一代码，表明交易是否被授权；（11)交易的结算状态（例如，"100"代表完成的交易）；（12)"结算时间"，其是IPSP把结算请求发送到收单银行的时间；（13)卡持有者的街道和街道号；（14)卡持有者的城镇；（15)卡持有者的国家；（16)卡持有者的邮政编码；(17)起源交易参考，其在偿还请求的情况下成为被偿还的原先的交
40易的参考；（18)定单信息，商家如果他们愿意，可以使用它以包括更多关于交易的信息；（18)"地点参考"，其是商家的IPSP参考；(19)交易的类型，其可以包括授权的交易、退款交易和取消的交易(例如，被取消的交易，或在钱由发行银行转账到商家之前并且在结算请求从IPSP被发送到收单银行之后应商家的请求数量改变的交易）；和（20)唯一参考号（URN)，其唯一地识别在ASP系统105中的交易。根据本发明的一个实施例，该信息还可以被包括在从IPSP被发送到收单银行的结算请求中，以上参考图6中的步骤310对此进行了讨论，以下将参考图10A中的步骤1102和1104对其进行讨论。从收单银行系统106获得的交易信息可以包括从收单银行请求的资金总额，例如，每个商家在一批或多批中聚集的资金总额。
根据各种实施例，为了获取交易信息，ASP模块400可以访问其上张贴交易信息的安全网页（例如，由每个系统104、 106保存的）并且把信息下栽到ASP系统105中，通过另一类型的电子交易(例如，经由电子邮件或传真)或两者的组合接收交易信息。
在各种实施例中，在步骤402中获得的交易信息被存储在ASP系统105上，如在步骤404中所示，并且从IPSP系统104获得的信息与从收单银行系统106获得的信息相比较，如在步骤406中所示。在图8中所示的实施例中，步骤406被显示为在步骤404之后发生，但是在其它实施例中，这两个步骤可以同时发生或以相反的次序发生。
根据本发明的各种实施例，在比较步骤406中，ASP模块400识别由IPSP系统104提供的交易信息与由收单银行系统106提供的信息不匹配的任何交易。在一个实施例中，任何非匹配交易被标志并且在由ASP模块400生成的例外报告中被报告给商家、IPSP和/或收单银行，以下将参考步骤410更详细地对其进行讨论。在另一个实施例中，其中收单银行系统106把资金直接地转账到与每个商家相关联的、并且由IPSP36和/或ASP35保存的账户，以下将参考图14对其进行讨论，ASP模块400还被配置为把由IPSP系统104和收单银行系统106提供的交易信息与被转账到每个商家账户的数量相比较。
在协调由IPSP系统104和收单银行106提供的交易信息之后， 然后ASP模块400可以把在结算过程期间接收的支付数量分配给各种 参与者，这在图8中的步骤408中被示出。支付数量可以包括，例如， 支付给商家31、 32、 33的数量、欠IPSP34、收单银行和ASP 35的 佣金，和为每个商家31、 32、 33存储在循环储蓄委托账户41中的资 金的百分比。例如，根据各种实施例，各种参与者可以要求把由商家 31、 32、 33接收的资金的某个百分比作为他们与商家31、 32、 33的 合同43、 45、 47、 49中服务的支付。例如，收单银行36可以从收单 银行37、 38、 39收费由商家31、 32、 33接收的资金的3%，卡組织 可以收费使用他们的卡转账的资金的1%， IPSP 34可以收费与支付 相关的服务的5%,以及ASP35可以为它的记帐管理服务向IPSP34 收费由IPSP34接收的钱的3%。如另一个例子，ASP35还可以计算 由IPSP34招致的各种服务的临时花费，诸如卡验证、给各种参与者 的佣金支付和针对接收的退款可由商家31、 32、 33收费的任何费用。 此外，根据各种实施例，金融交易系统IOO可以建立指定被用于 资助循环储蓄委托账户41的资金的百分比的协议。例如，系统协议 可以要求ASP模块400把要由每个商家31、 32、 33接收的资金的7.5 %分配给每个商家31、 32、 33的循环储蓄委托账户。在另一个例子 中，根据一个实施例，针对循环储蓄账户的指定的百分比可以被自动 地增加或减少，依赖于为特定商家31、 32、 33接收的退款请求的数 量。此外，根据一个实施例，ASP模块400监视并识别特定时间段（例 如，六个月、 一年或三年）保留在账户中的资金，并且在时间段的末 尾重新把那些资金分配给商家31、 32、 33。此外，委托账户41在图 1的实施例中作为ASP系统35的一部分被示出。然而，在其它实施 例中，委托账户41可以处在或由银行或其它金融机构保持。
接下来，在步骤410中，根据各种实施例，ASP模块400被配 置为为每个商家生成协调报告、或"建议通知书"。在一个实施例中， 建议通知书提供给每个商家在特定时间段期间（例如， 一天或一周）
42为商家处理的交易的摘要、在协调步骤406中创建的例外报告（如果 需要）、分配给在步骤408中的各种参与者中的每个的支付的摘要、 在特定时间段期间在委托账户中的活动的摘要和支付被转账到商家 31、 32、 33的日期。在另一个实施例中，建议通知书的各个部分被包 括在分开的报告中（例如，例外报告、支付分配报告和交易摘要报告）。 以及，在另一个实施例中，ASP模块400被配置为根据由每个指定的 特定的格式为IPSP 34和每个商家31、 32、 33生成一个或多个摘要 报告。
在图8中所示的实施例中，ASP模块400还被配置为（l)为每 个商家31、 32、 33把建议通知书发送到IPSP 34用于审批，这被示 为步骤412，和（2) —旦从IPSP34接收到建议通知书的批准，这被 示为步骤414，把建议通知发送到商家31、 32、 33，这被示为步骤416。 在其中IPSP34没有与ASP签订提供记帐管理服务（未示出）的合同 的另一个实施例中，步骤412和414可能不执行。
此外，根据本发明的各种实施例，ASP模块400被配置为准备 和把支付发送到各种参与者和委托账户，如在步骤418中所示。步骤 418可以包括，例如，物理地把支付（例如，支票或现金）发送到每 个参与者，准备请求从与ASP系统105相关联的账户到与欠钱的各种 参与者相关联的账户的电子资金转账（EFT)，或者两者的结合。此 外，尽管支付步骤418被示为在图8中所示的实施例中的步骤416之 后发生，根据其它实施例，ASP模块400可以被配置为与步骤416同 时或在其之前执行支付步骤418。
在本发明的其它实施例中，ASP模块400还可以被配置为在发 送支付到每个商家31、 32、 33之前扣留相关电子商业交易（例如， 因特网赌博交易或零售购买）的本地或地区税。例如，在一个实施例 中，ASP模块400可以被配置为基于居住地或每个顾客和/或商家的 交易的地点应用使用的税或发证率，以及把资金直接地转账到相关税 或发证纟几构。
特别地，图17示出在金融交易上所欠的任何税的示例性记帐过程。从步骤702开始， 一种或多种税收管辖权的税的合适类型和对应 的税率被存储在存储器24中。接下来，在步骤704,与在顾客和商家 31、 32、 33之间进行的金融交易相关联的信息被接收。响应于接收与 金融交易相关联的信息，识别出与金融交易相关联的一种或多种相关 税收管辖权，如步骤706所示。接下来，在步骤708,查询存储器以 确定与识别的税收管辖权相关联的一种或多种类型的税。如果一种或 多种类型的税与识别的税收管辖权相关联，那么税的类型对应的税率 被应用到金融交易以确定交易欠的税，这作为步骤710示出。此外， 一旦确定交易欠的税，欠税的数量转账到相关税务机构，如步骤712 所示。在各种实施例中，可以基于交易发起者（例如，商家）、顾客 的位置和/或顾客从其下定单的计算装置的位置征税。
在各种实施例中，扣留的税的数量和支付给税务机构的数量被存 储在一段时间段内具有交易信息的系统中，在某些实施例中，其允许 审计跟踪。例如，在一个实施例中，应付款的数量被保存在指定的银 行账户中，并被周期地（例如，每月、每周、每天或即时）支付给税 务机构。在一个实施例中，应付款的数量经由电子资金转账（EFT) 被支付给税务机构。
根据各种实施例，该税务记帐功能减轻了商家、顾客和税务机构
的负担，并提供了有税交易的可信的记帐系统。此外，在一个实施例 中，ASP模块400生成总结到期应纳税款和/或已征的税的、用于税 务机构的记帐报告。
此外，在各种实施例中，交易记录可以被电子地或人工地通过 ASP模块400进行审计。特别地，当交易通过系统被处理时，与每个 交易相关联的唯一参考号（"URN")被跟踪。例如，在一个实施例中， 多个交易可以被分组成批处理文件并被发送到收单银行进行结算。 ASP模块400在批处理文件中存储与每个交易相关联的URN以及识 别批处理文件的信息，使得每个单独的交易可以独立地被审计。
C.示例性处理流程
授城理絲
44图9A示出根据本发明的各种实施例的处理授权请求的流程图 100。在一个实施例中，授权请求的处理当顾客等待时在线发生，并 且它通常花费两到二十秒进行处理。如果授权请求被发行银行接受， 商家接受顾客的支付，并发行银行阻挡请求的数量超过与支付卡相关 联的信用极限或余额。
根据本发明的各种实施例，授权请求处理1000在步骤1002通过 商家31、 32、 33从顾客接收从顾客的支付卡到商家的账户的转账的 请求开始。该请求可以包括，例如，转账的数量和顾客的信息和支付 卡信息（假设商家不具有从之前的交易存储顾客的信息和支付卡信 息）。在一个实施例中，顾客和支付卡信息可以包括顾客的全名和地 址、顾客的电子邮件地址和支付卡号、有效日期和与支付卡相关联的 任何其它识别信息。在一个实施例中，请求可以由商家的系统101、 102、 103接收，并被存储在其上。
接下来，在步骤1006中，根据本发明的各种实施例，商家31、 32、 33验证在顾客的请求中接收的信息的格式。在一个实施例中，如 以上对于在图5和步骤204中所示的商家模块200讨论的，商家模块 200验证支付卡号的格式是否是正确的，以及是否所有要求的字段都 已经完成。
在步骤1006中验证完信息的格式之后，商家31、 32、 33把交易 信息转移到IPSP 34进行进一步处理，这被示为步骤1010。 IPSP 34 接收并在IPSP系统104上存储交易信息，并且把收单银行36和发行 银行37、 38、 39需要的信息转移到收单银行36以处理授权请求，如 步骤1012所示。例如，根据本发明的各种实施例，该信息可以由IPSP 模块300转移到收单银行系统106,并且可以包括支付卡号、支付数 量和顾客的账单地址。
接下来，在步骤1014中，收单银行系统106接收并在收单银行 系统106上存储授权请求。然后，在步骤1016中，收单银行系统106 识别合适的卡发行商和发行银行，并把授权请求经由合适的卡发行商 网络（例如，Visa、 MasterCard或American Express网络）路由到发行银行。 一旦接收到授权请求，发行银行系统107、 108、 109验证 支付卡是可操作的和有效的，这被示为步骤1018，以及有足够的资金 用于支付卡，这被示为步骤1020。 一旦批准授权请求，发行银行系统 107、 108、 109通过卡发行商网络把批准消息发送到收单银行系统106, 示为步骤1022，而收单银行系统106接收批准消息并在步骤1024中 把批准消息发送到IPSP系统104。然后，在步骤1026中，IPSP系统 104接收并存储批准消息并把批准消息发送到发起授权请求的商家系 统101、 102、 103。
根据各种实施例，以上参考图5讨论的初级欺骗检验和身份/年 龄验证步骤（步骤204和206 )可以由商家模块200与把授权请求信 息从商家转移到IPSP的步骤1010同步、在其之前和在其之后执行。 此外，根据本发明的各种实施例，执行欺骗阻止子模块350的步骤， 这在图6中被示为步骤306，可以由IPSP模块300与把授权请求信息 从IPSP转移到收单银行的步骤1020同步、在其之前和在其之后执行。
在本发明的另一个实施例中，在图13中示出，当被发送到商家 系统101a、 102a、 103a和经由网络115a #1发送到到IPSP系统104a 时，顾客的信息被加密（例如，具有2048比特可变加密）。此外，IPSP 模块300a执行欺骗阻止子模块350a的一个或多个欺骗过滤器，并且 如果欺骗过滤器检测到潜在可疑活动，IPSP模块300a在发送授权请 求到收单银行之前把欺骗检验的结果发送到商家用于审批，然后收单 银行把请求发送到发行银行。在收单银行从发行银行接收授权消息之 后，收单银行在收单银行系统106a (例如，数据库）的存储区域中存 储交易信息并把授权消息发送到IPSP系统104a。 IPSP模块300a把 授权消息转发到商家，并可以在生成对于交易的结算请求之前在交易 信息上执行一个或多个欺骗过滤器。
潜#^埋谅程
图IOA和10B示出根据本发明的各种实施例的处理结算请求的 示例性流程图1100。根据各种实施例，结算请求是由收单银行（或代 表收单银行的IPSP)生成的把钱从发行银行转账到收单银行用于支付给商家的请求。根据本发明的各种实施例，结算请求过程1100在步骤1102开始，其中IPSP系统104为每个商家31、 32、 33生成结算请求并且把结算请求在批处理文件中发送到收单银行36。在各种实施例中，每个结算请求包含在特定时间段期间（例如，24小时、48小时或一周）由IPSP34处理的交易的数据。根据本发明的各种实施例，结算请求可以包括授权的和未授权的交易或仅包括授权交易。接下来，根据本发明的各种实施例，在步骤1104中，IPSP系统104把结算请求存储在IPSP系统104上。结算请求可以通过从IPSP系统104的安全部分下载结算请求而被转移到ASP系统105,或者IPSP 34可以发送结算请求的物理拷贝或电子拷贝到ASP35(例如，经由电子邮件、传真、CD、 DVD或软盘）。根据本发明的各种实施例的结算请求的内容是以上参考图8进行讨论的。
如在步骤1106中所示，收单银行36接收批处理文件并把结算请求发送到合适的发行银行37、 38、 39。此外，收单4艮行36生成并存储用来总结被包括在每个发行银行37、 38、 39的每个结算请求中的资金数量（例如集合的资金数量）的用于ASP 35的支付报告，这作为步骤1108示出。由收单银行36为ASP 35生成的支付报告的一个实施例是以上参考图8进行讨论的。
然后，在步骤1110中，发行银行37、 38、 39把请求的资金转账到收单银行36。接下来，在步骤1112中，收单银行把接收的资金转账到IPSP 34。在IPSP 34 (或ASP 35 )把资金分发到合适的参与者和委托账户之前，ASP系统105获取由IPSP系统104生成的结算请求和由收单银行36生成的支付报告，并在步骤1114中协调获取的信息。根据本发明的各种实施例，步骤1114中执行的协调的结果可以在协调报告（或"建议通知书，，）中由ASP35总结。最后，在步骤1116中，ASP35组织每个参与者的支付和用于转账到委托账户的数量，并把支付转账到参与者和委托账户。
根据一个实施例，ASP模块400被配置为执行步骤1114和1116，这是在以上参考图8进行讨论的。例如，ASP模块400总结来自协调
47数据的结果，该数据由IPSP和收单银行在周期地（例如，每天或每周）被发送到每个商家31、 32、 33的协调报告中提供的。协调报告总结商家31、 32、 33可能希望在商家的银行账户中在特定的日期前接收的数量。此外，协调报告包括顾客放置在他们各自的商家账户中的总额，并且示出以下减免和增加：（l)减去佣金和费用（覆盖在支付链中的给所有参与者的支付）；（2)减去对应于特定时间段期间（例如，六个月或一年）在循环储蓄委托账户中作为保障退款和偿还安全而保留的总额的百分比的"信任减免，，；（3)增加在某个时间段期间和建议通知的日期的前一天保留的"信任钱"；（4)减去任何
由收单银行在关于之前交易的建议通知书的当天发送的任何退款。在把资金转账到合适的参与者和循环存储委托账户之前，IPSP 34回顾包括其上支付被表明为已支付的日期的协调报告。 一旦接收IPSP 34针对协调报告的批准，ASP 35把协调报告发送到各种商家31、 32、33,并且把支付转账到合适的参与者和委托账户。在一个实施例中，资金的转账可以在委托报告被生成并批准之后发生。在另一个实施例中，资金的转账可以在协调报告的批准之前发生。
根据在图14中所示的替代实施例，资金直接地由收单银行存入与每个商家（例如，SG1、 SG2、 SG3等）相关联的每个公司实体的账户中。此外，ASP模块400a还被配置为用于协调接收到每个具有结算请求的账户的数量和从IPSP和收单银行分别获得的支付报告。在一个实施例中，没有从账户支付给各种参与者或委托账户的任何数量净皮支付给商家
退款请求是由发行银行代表顾客发起的请求偿还特定费用到顾客的支付账户的请求。例如，发行银行可以响应顾客争辩在顾客的支付卡上的费用：顾客声称没有被顾客授权，而发起退款请求。图11示出根据本发明的各种实施例的处理退款请求的示例性流程图1200。
在步骤1202开始，发行银行37、 38、 39接收来自顾客的退款请求。然后，在步骤1204，发行银行37、 38、 39把退款请求发送到收
48单银行。在步骤1206中，收单银行36接收退款请求并且把它发送到IPSP34。接下来，在步骤1208， IPSP34比较退款请求和来自原始交易的数据。如果退款请求中的数据显示与来自原始交易的数据匹配，在步骤1210中，IPSP 34把请求发送到ASP 35。根据如上所述的本发明的各种实施例，比较和发送步骤1208和1210可以由IPSP模块300执行。接下来，在步骤1212中，根据本发明的各种实施例，ASP35把退款数量从商家的委托账户转发到收单银行36,然后收单银行把退款数量转发到发起退款请求的发行银行37、 38、 39。在替代实施例中，ASP 35在结算请求中通过把它从应该支付给商家31、 32、 33的总额中扣除而把退款数量支付给发行银行37、 38、 39。然后，在步骤1214， ASP35存储退款请求。在本发明的各种实施例中，ASP模块400被配置为执行步骤1212和1214。
根据本发明的一个实施例，如果在步骤1208中退款请求数据与来自原始交易的数据不匹配，则退款请求可以被标志。此外，如果标志的与特定支付卡相关联的退款请求的数量在特定时间段内（例如，一周或一个月内两次退款请求）超出某个数量，则IPSP可以把特定的支付卡号包括在商家在将来不应该接受支付的支付卡的列表上（例如，在由IPSP34保存的欺骗和滥用数据库中）。
除了上述的以外，根据各种实施例，ASP 35协调由收单银行36和IPSP34在特定时间段期间（例如，每天或每周）处理的退款请求与来自原始交易的交易数据。为了协调请求，ASP35获取由收单银行36生成的退款交易报告和由IPSP34生成的退款交易报告，并且把这两个报告和来自原始交易的数据比较，如步骤1216所示。在一个实施例中比较步骤1216通过链接在退款报告中的数据和来自已经被存储在ASP系统105的存储器中的原始交易的数据而被执行。根据一个实施例，退款数据报告包含以下信息的至少一部分：（l)参考被退款的原始交易；（2)MID号；（3 )提出退款请求的日期；（4)作为"退款"的交易的描迷；（5)完全的卡号；（6)由收单银行担保的参考号；（7)"原因代码"，由卡发行银行发出的、表明卡持有者发起退款的原因的代码号；（8)发起退款的原因的描述；（9)退款数 量的货币类型；（10)退款数量；（11)收单银行提供的卡号或部分 卡号（例如，卡号的头四位数字）；（12)原始交易被"张贴"或被授 权的日期；（13)原始交易发生的日期；（14)原始交易的"类型，，；
(15)原始交易的货币；（16)原始交易的数量；（17)交易结算的 货币；（18)结算的数量；（19)收单银行提供的原始的"默认"货币；
(20)收单银行提供的原始"默认货币，，数量；（21)"原始单"，是"批 处理"交易的参考，交易是当收单银行把它的关于特定日期的交易释 放给IPSP时的一部分；（22 )收单银行的"项目单"；（23 )原始交 易的授权代码；（24)收单银行的"批处理号"；和（25)"商家DBA 名称"，其是商家显示在顾客的支付卡声明上的名称。如以上参考图8 描述的，根据本发明的各种实施例，ASP模块400可以被配置为执行 协调步骤1216。
根据本发明的各种实施例，报告可以被张贴到IPSP系统104和 收单银行系统106上，并且由ASP系统105下栽，或者报告可以物理 地或电子地经由例如电子邮件、传真、CD、 DVD或软盘被发送。
i:^义理處在
在某些电子商业部门（例如，赌博），钱可能需要退还给顾客。 支付给钱可能引起洗钱滥用的风险的担忧，特别是对于因特网赌博。 根据本发明的各种实施例，系统IOO通过专门地给由顾客使用以进行 给商家的原始支付的支付卡账户支付，在顾客和商家之间创建完全透 明的"封闭环"，而解决了某些与电子商业交易相关联的风险。因此， 根据一个实施例，资金起源于并流回相同账户，并且所有的资金流动 是可跟踪的，这使电子商业对于洗钱计划没有吸引。
例如，图12示出当顾客提交支付请求时处理和发送支付给顾客 的示例性流程1300。从步骤1302开始，商家从顾客接收支付的请求， 并把请求发送到IPSP。接下来，在步骤1304中，IPSP验证顾客没有 被包括在政府或本地机构制裁列表（例如，由U.S.公开的"Specially Designated Nationals Ust，，）上。此外，根据一个实施例，IPSP验译顾客的国籍（例如，基于顾客的账单地址或顾客计算装置的IP地址） 不是在其中商家可以进行交易的被禁止的国家的列表上。根据各种实 施例，如果顾客（或顾客的国家）在列表上，支付请求不能够由系统
100处理，并且请求被拒绝。如果顾客没有被包括在制裁列表上（或 没有与被禁止国家相关联），IPSP34把支付请求发送到商家的银行， 这被示为步骤1306。响应于接收请求和验证支付资金在商家的账户 中，商家银行把资金发送到IPSP34,这被示为步骤1308。在IPSP34 已经接收资金并在IPSP系统104中存储它们的记录之后，IPSP 34 把资金转账到收单银行36，如在步骤1310中所示。接下来，在步骤 1312中， 一旦接收资金，收单银行36把资金发送到与顾客的、用于 在商家的网站上进行购买（例如，下赌注）的支付卡相关联的发行银 行37、 38、 39。根据各种实施例，在步骤1314中，然后针对从商家
31、 32、 33接收的数量，发行银行37、 38、 39可以相信与支付卡相 关联的账户，或者发行银行37、 38、 39可以发送支票给被列为卡持 有者的顾客。
在子钱逸
在本发明的另一个实施例中（未示出），金融交易系统100被配 置为允许顾客从IPSP34购买电子代币，然后这可以被用于与参加商 家31、 32、 33商定价格，创建预付的"电子钱包"账户。根据各种实 施例，金融交易系统100的特征可延伸到电子钱包系统。例如，IPSP 34接收把资金从顾客的电子钱包账户转账到IPSP的账户的请求，而 不是商家31、 32、 33从顾客接收把资金从与顾客的支付卡相关联的 账户转账到商家的账户的请求。根据一个实施例，IPSP 34执行商家 模块200和IPSP模块300生成并处理与发行银行的授权和结算请求 的步骤。 一旦结算，IPSP 34把代表转账的资金的数量的电子代币的 数量存入顾客的电子钱包账户。顾客可以使用代币和同参与商家31 、
32、 33进行购买。周期地（例如，每天或每周），IPSP34把代表在 每个商家的网站花费的代币的数量的资金转账到每个商家31、32、33。 在一个实施例中，ASP 35管理电子钱包账户并且把支付从IPSP 34分配给参与商家31、 32、 33。
在得到上述的描述和相关联的附图中呈现的指导的好处后，本发 明的许多修改和其它实施例将出现在本发明属于的技术领域的技术 人员的脑海中。因此，应该理解本发明不限于公开的特定实施例，以 及修改和其它实施例打算被包括在附加的权利要求的范围内。尽管这 里使用了特定的词语，但它们仅在一般的和说明的意义上被使用，而 不是为了限制的目的。