使用支付历史进行商业交易的方法和系统的制作方法

文档序号:6456909阅读:159来源:国知局
专利名称:使用支付历史进行商业交易的方法和系统的制作方法
使用支付历史进行商业交易的方法和系统
相关申请的交叉引用 不适用
背景技术
在典型的买方和卖方之间的商业交易中,买方会订立合同来从卖方购买货物。 合同会要求卖方在预定的送货日期将货物运送给买方,它也会要求买方在预定的合 同支付到期日支付货物的合同金额。
在某些情况下,卖方会愿意接受少于合同金额,以换取提前支付。例如,买 方会愿意接受低于合同的总价以换取提前支付。例如,买方可以与卖方订立用
$300,000向卖方购买1000台计算机监视器的合同。签约的支付到期日可以是12 月1日。然而,如果卖方可以在6月1日之前收到打折后的付款,卖家会愿意接受 计算机监视器10%的折扣或$270,000。
如果买方不愿意早于合同到期日支付货款,那么诸如买方银行等融资实体可 能愿意在合同到期日之前向卖方预付打折后的支付金额,以换取在合同到期日接收 全部合同金额的权利。例如,在上述示例中,买方银行可能愿意在6月1日向卖方 发送$270,000的打折后金额,以换取在12月1日收到$300,000合同金额的权利。 假设买方在合同到期日支付$300,000,那么买方银行将收到合同金额和打折后金额 之差(此处为$30,000)作为对商业交易融资的补偿。
买方银行有关是否在合同支付到期日之前向卖方预付打折后金额的判定是取 决于买方的信贷价值。例如,如果买方不是很有信贷价值的,那么买方银行会推断 买方可能不会按时和/或全额支付合同金额,因此向卖方发送预付打折后的款项是 非常有风险的。另一方面,如果买方银行判定买方有较好的信贷风险,那么买方银
行会判定得不到支付的风险较低且买方银行会因此向卖方发送预付款。
买方银行可以使用常规信用分数来判定是否向卖方预付资金。然而,常规信 用分数是一般性的,并且可能不能给予买方银行有关得不到买方支付的风险的足够 信息。例如, 一般的信用分数是通过查看买方对直接和间接开销(例如公用事业、 债务和其它付款)作出的所有支付的支付历史来制定的。如果买方具有延迟支付某些类型的帐单而非其它的历史,那么一般的常规信用分数可能不能充分地告知买方 银行有关买方银行的风险。
作为说明,买方可能100%的时间按时支付公用事业帐单(例如电)、95%的
时间按时支付原材料的帐单、而40%的时间按时支付办公室设备的帐单。买方的
一般信用分数会是高的,因为多数买方的帐单是按时支付的。如果买方银行基于买 方向卖方购买办公室设备的合同来考虑向卖方预付款,那么买方的一般信用分数可 能指示买方具有较好的信贷风险,即使当涉及办公室设备购买合同时买方具有较差 的信贷风险。
此外,实际上,信用信息是难以获得和/和可能不是当前的和及时的。如果买 方和卖方属于不同的管辖区域和/或国家时或者如果他们是新的并且还没有形成合
适的交易历史时尤其如此。在这种情况下,卖方或融资实体可能不能访问任何可信 赖的信用报告,更不用说精确的和允许它们作出有关特定商业交易的基于可靠信息 的判定的信用报告。
除了这个问题之外,就传统财务系统而言还有其它问题。有时候,货物和服 务的卖方可能希望收到筹资提议,但是没有使卖方能便利地找到可能愿意对它们的
商业交易融资的融资实体的便利平台。相反,诸如银行等融资实体可能希望向买方 和卖方融资,但是可能不知道如何联系乐意的买方和卖方。 本发明的各实施例解决了这些和其它问题。

发明内容
本发明的各实施例涉及可以利用由电子交易处理系统进行的多个商业交易的 支付历史的方法、系统和计算机可读介质。可以使用支付历史作出诸如融资判定和 运送判定等判定。
本发明的一个实施例涉及一种方法。该方法包括接收与由使用交易处理系 统进行商业交易的多个买方和卖方所进行的多个商业交易相关的交易数据,并且接 收来自实体的对有关接收到的交易数据的交易信息的请求。交易信息涉及买方和卖 方之间的商业交易,并且可包含包括风险评级的信息。交易信息被提供给实体,后 者然后可作出有关与买方和卖方进一步交互的判定。例如,实体可以是诸如银行等 融资实体,而银行在查看交易信息后可以判定是否代表买方向卖方预付资金。
本发明的另一实施例涉及计算机可读介质,包括用于接收与由使用交易处 理系统进行商业交易的多个买方和卖方所进行的多个商业交易相关的交易数据的代码;用于接收来自实体的对有关接收到的交易数据的交易信息的请求的代码,其中所述交易信息还涉及买方和卖方之间的商业交易;以及用于向实体提供交易信息的代码,其中所述实体然后作出与买方或卖方进一步交互的判定。
本发明的其它实施例涉及使用上述方法和计算机可读介质的服务器计算机以及系统。
以下更详细地描述了本发明的这些和其它实施例。附图简述


图1(a)示出了根据本发明一实施例的系统的框图。也示出了支付历史应收款打折过程流。
图l(b)示出了根据本发明一实施例的计算机装置的一些组件的框图。图l(c)示出了根据本发明一实施例的支付历史应收款打折过程流中的各步骤的流程图。
图2(a)示出了系统的框图。也示出了支付历史应付款打折过程流。图2(b)示出了根据本发明一实施例的支付历史应付款打折过程流中的各步骤的流程图。
图3(a)示出了系统的框图。也示出了支付历史分发过程流。
图3(b)示出了根据本发明一实施例的支付历史分发过程流中的各步骤的流程图。
图4(a)示出了系统的框图。也示出了第三方融资过程流。
图4(b)示出了根据本发明一实施例的第三方融资过程流中的各步骤的流程图。图5(a)示出了系统的框图。也示出了支付历史供应链过程流。
图5(b)示出了根据本发明一实施例的支付历史供应链过程流中的各步骤的流程图。
图6(a)示出了系统的框图。也示出了支付历史匹配过程流。
图6(b)示出了根据本发明一实施例的支付历史匹配过程流中的各步骤的流程图。
详细描述本发明的一个实施例涉及一种方法。该方法包括接收与由使用交易处理系统进行商业交易的多个买方和卖方所进行的多个商业交易相关的交易数据。由买方进行的商业交易可以是随着时间的流逝可能涉及多个不同卖方的交易。由卖方进行的商业交易也可以随着时间的流逝涉及多个不同的买方。随着时间的流逝,买方和卖方的交易档案可以由交易处理系统收集并且被存储在历史数据库中。有关买方和卖方如何和何时进行商业交易的特定历史可以被存储在历史数据库中。
在交易处理系统接收到交易数据之后(或之前),从诸如融资银行等实体接收到对有关接收到的交易数据的交易信息的请求。发送给实体的交易信息可以包括原始交易数据或经处理的交易数据。可响应于来自实体的对交易信息的特定请求,将交易信息发送给请求实体。或者,可以响应于实体先前的请求,将交易信息推向实体。
交易信息可以包括从所接收到的交易数据获取的任何合适类型的信息。例如,交易信息可以包括原始交易数据和/或经操纵的交易数据。例如,由交易处理系统接收到的交易数据可以是针对特定买方的,并且可以由交易处理系统操纵(分析、计算等)以形成特定买方的风险评级。风险评级可以指示买方是否可能在特定的到期日支付特定类型的产品。
请求实体(例如买方银行)之后可接收交易信息,并且之后能判定是否或如何进一步与买方和/或卖方交互。例如,交易信息可以包括使用接收到的交易数据判定的风险评级。如果买方具有较低的风险评级,那么买方银行可能决定提早向卖方支付商业交易的打折后的金额,以换取在稍后的日期接收到买方对商业交易的全额付款的权利。如果买方具有较高的风险评级,那么买方银行会判定得不到买方支付的风险太高,并由此会不参与买方进行的商业交易。
以下详细描述了本发明的特定实施例的多个示例,而本发明的实施例不限于此。例如,描述了多个系统和方法。根据本发明的各实施例的系统可以包括所具体描述的更多或更少的组件。例如,尽管所描述的系统包括买方和卖方,但是根据本发明的实施例的其它系统可不包括买方和/或卖方。此外,以下所描述的特定方法可以包括比具体描述的更多或更少步骤的方法。
图l(a)示出了根据本发明的一个实施例的系统。图l(a)中所示的系统可在支付历史应收款打折过程中使用。在典型的支付历史应收款过程中,融资实体可向卖方预付款,以换取在合同支付到期日从买方接收支付的权利。
图l(a)所示的系统包括与买方银行112相关联的买方110,以及与卖方银行122相关联的卖方120。买方IIO可以在买方银行112有帐户,而卖方120可以在卖方银行122有帐户。
买方110、买方银行112、卖方120以及卖方银行122可以与交易处理系统130和支付处理系统140联系。支付处理系统140进而可以与交易处理系统130有效通信。在图l(a)和其它附图中,为清楚说明起见,示出了一个买方、 一个卖方、 一个买方银行和一个卖方银行。然而,在本发明的各实施例中,许多买方、买方银行、卖方和卖方银行可以与交易处理系统130和支付处理系统140(直接或间接)交互。此外,本发明的实施例也不限于仅包括单个交易处理系统和/或单个支付处理系统的系统。
买方110和卖方120可以是具有合适特性的实体。例如,买方110和卖方120可以包括公司、组织、个人等。买方IOO和卖方120可以是使用交易处理系统130和/或支付处理系统140进行商业交易的数百个或甚至数千个买方和卖方的两方。这种商业交易可以涉及货物和/或服务的销售。
在一些情况下,买方银行112可以被称为"发行机构",而在一些情况下卖方银行122可以被称为"收单方"。虽然在图l(a)中示出了买方银行112和卖方银行122,应该理解可以使用数百个甚至数千个银行或其它类型融资实体来代替买方银行112和卖方银行122,或者除了买方银行112和卖方银行122外可以有数百个甚至数千个银行或其它类型融资实体。例如,在本发明的其它实施例中,诸如公司、非营利性组织、政府或协会可以向卖方预付款以及从买方收集应收款。
交易处理系统130可以包括能够处理多个买方和卖方之间的商业交易的任何合适类型的系统。在优选实施例中,交易处理系统包括各种功能的原始件,包括具有支付条款和条件的供方帐单的数据库、帐单预处理器、支付管理器模块、交易费条款和条件数据库、发行机构定价引擎、授权和清算接口以及支付结果处理模块。有关示例性交易处理系统的其它特定细节可以在2001年10月29日提交的美国专禾U申请No. 10/020,466以及WO 03/038553中找到,两者都是通过整体引用包含于此,以实现所有目的。
支付处理系统140可包括能够处理电子支付的任何合适的系统。在优选实施例中,支付处理系统140可适于处理由一般消费者进行的典型的借记卡或信用卡交易。支付处理系统140也可适于执行结算和清算过程。示例性支付处理系统可以包括VisaNetTM。
交易处理系统130可包括服务器计算机130(a),该服务器计算机130(a)可以包括计算机可读介质或CRM 130(a)-l。服务器计算机130(a)可被有效耦合到历史数据库130(b)。历史数据库130(b)可以存储来自多个商业交易的数据。数据可以包括先前的交易信息、先前的支付信息以及诸如风险评级等输出数据。如此处所使用的,"服务器计算机"可以具体化为可以为一个或多个客户计算机或其它计算机装置的请求提供服务的一个或多个计算装置。通常,服务器计算机或主机计算机是功能强大的计算机或用作单个计算机的计算机群。例如,服务器计算机130(a)可以是大型计算机、小型机或小型机群。在另一示例中,服务器计算机130(a)可以包括一个或多个数据库服务器和一个或多个Web服务器。服务器计算机130(a)可以为一个或多个客户机计算机的请求提供服务。
任何合适的通信介质可用于使图l(a)中所示的各种实体和组件能彼此通信,包括通信线路、信道和无线电接口的任何适当的组合。根据一个实施例,通信介质可以包括例如因特网、内联网、公共开关电话网络(PSTN)、或者无线电话或无线电网络。根据一个实施例,服务器计算机130(a)和各种计算机装置(例如计算机装置110(a))可以使用基于TCP/IP的协议通过通信介质通信。
买方IIO、卖方120、买方银行112、以及卖方银行122各自可以具有至少一个计算机装置llO(a)、 120(a)、 112(a)、 122(a)。这些计算机装置110(a)、 120(a)、112(a)、 122(a)使得买方110、卖方120、买方银行112、以及卖方银行122能够与交易处理系统130和支付处理系统140进行电子通信。
计算机装置110(a)、 120(a)、 112(a)、 122(a)中的任何一个,或者甚至是诸如服务器计算机130(a)等的交易处理系统130和支付处理系统140中的组件可以使用任何合适数目的子系统。图l(b)中示出了这种子系统或组件的示例。图l(b)所示的子系统经由系统总线775互连。示出了诸如打印机774、键盘778、固定磁盘779、耦合到显示适配器782的监视器776等其它子系统。可以用诸如串行端口 777等本领域中公知的多种装置将耦合到I/O控制器771的外围设备和输入/输出(I/0)设备链接到计算机系统。例如,串行端口 777或外部接口 781可用于将计算机装置连接到诸如因特网等广域网、鼠标输入设备或扫描仪。经由系统总线的互连使得中央处理器773能够与各个子系统通信并控制来自系统存储器772或固定磁盘779的指令的执行以及子系统之间的信息换取。系统存储器772和/或固定磁盘779可以具体化为计算机可读介质。
根据本发明的各实施例的方法的任何部分的结果可以在图l(b)所示的任一输出设备上输出,并且可以由运作输出设备的实体使用。例如,买方银行可以具有打印机或监视器,以使买方银行能在作出关于在与卖方的商业交易中是否代表买方向卖方预付资金的判定时查看买方的风险评级。
可以参考图l(a)和图l(c)来描述支付历史应收款打折方法。首,买方110和卖方120向交易处理系统130登记(步骤70)。此外,将或已经与买方110和卖方120交互的其它买方和卖方(未示出)也可以向交易处理系统130登记。
如图l(a)中的附图标记1所示,在买方110和卖方120向交易处理系统130注册后,买方110、卖方120以及各个其它买方和卖方(未示出)使用交易处理系统130进行商业交易(步骤72)。由于它们使用交易处理系统130进行商业交易,买方110和卖方120构建支付和交易历史。使用交易处理系统130的各个买方和卖方的支付和交易历史由服务器计算机130(a)存储在历史数据库130(b)中。可以任选地为买方110和卖方120构建交易档案,且这些交易档案可以被存储在历史数据库130(b)中。
在某个时间(例如买方110和卖方120形成交易历史之后),买方110和卖方120使用交易处理系统130进入特定的商业交易。例如,卖方120可以与买方IIO形成合同,以向买方110提供1000台计算机监视器。买方110可同意在12月1日为1000台计算机监视器支付$300,000。包括合同金额以及任一个或多个支付到期日的合同条款和条件被存储在交易处理系统130中。
如图l(a)中的附图标记2所示,告知买方银行112有关买方110和卖方120之间的商业交易。买方银行112接着从交易处理系统130获取与买方110相关的交易信息(步骤74)。如上所述,买方银行112可以简单地请求交易信息(例如经由电子邮件),而交易信息可由交易处理系统130发送给买方银行112。或者,交易信息可以被推送到买方银行112,而无需对交易信息初始的或直接的上述请求。
买方银行112获取的交易信息可以包括任何合适类型的信息。在本发明的各实施例中,交易信息可以包括与买方110或卖方120相关的过往交易信息、与买方110和卖方120之间的当前交易相关的当前交易信息,以及能够帮助买方银行112作出決定的经处理信息。例如,交易信息可包括有关买方或卖方的信息、支付信息以及诸如风险评级等输出数据。
交易处理系统130能够跟踪对诸如银行等实体有用的信息以帮助评级风险。例如,交易信息可以包括以下各应付款和/或应收款信息;平均交易规模或特定交易规模;平均未付的应付款和/或应收款;当前未付的应付款或应收款;平均支付时间;平均和当前持仓净额(AP/AR);发货国/抵达国;贷款份额(tranche);根据商品/服务分层的平均支付时间选择;时效报告(aging reporting);以及未付的帐户应付款和帐户应收款的加权平均值。交易信息也可以包括诸如逾期付款、短期付款、由于资金不足的拒绝付款以及来自银行融资的拖欠等支付信息。最后,交易信息也可以包括经计算或经判定的输出,包括个人统计数据以及基于实体的交易
历史对加权评级的计算。如果需要,也可以根据交易频率(例如30天、60天、90
天或终身)来跟踪信息。
在本发明的各实施例中,诸如银行等实体可以使用交易处理系统130或者登陆并搜索,或者接收文件。银行可以向交易处理系统请求信息或可以提供其自身的加权模型。如果买方的风险评级高于预定的风险评级,那么也可能更新实体的接受概况文件以便自动地提供融资(例如,银行的概况文件可能表示"如果买方的风险评级分数高于X就提供融资"或者"如果符合这些特定的参数就提供融资")。如上所述,银行可使用这个和其它信息来作出信用判定并标识资产融资/担保的源。
接收到的交易信息也可以具体地应用于与买方110和卖方120之间的当前交易或者与之有关。例如,买方IIO可能已经展示出当支付与一种类型的购买(例如电)有关时按时支付而另一种类型(例如法律服务)则不按时支付的模式。在另一示例中,买方110可能具有相对于较小的帐单而言更经常地按时且全额支付较大的帐单。这些购买模式中的任一个可以由交易处理系统130识别并且可以被存储在历史数据库130(b)中。在一些实施例中,服务器计算机130(a)可以使用上述信息中的任一个来创建用于量化买方对一特定交易按时且全额支付的风险的风险评级。风险评级可以用数字或字母级别的形式,使得最终用户可以容易地区分好的风险与坏的风险。
在买方银行112获取了交易信息后,买方银行112接着作出有关是否就商业交易向卖方120提供预付款的判定。如图1(a)中的附图标记3所示,如果风险对于买方银行112是可接受的,那么买方银行112向卖方120作出融资提议(步骤76)。例如,如果卖方120期望在12月1日为1000台计算机监视器的运送收到$300,000,那么买方银行112可能提议提前(例如6月1日)向卖方120支付$270,000,以换取12月1日从买方110接收全额$300,000的权利。
如图1(a)中的附图标记4所示,在向卖方120作出预付款的提议后,卖方120可以接受买方银行112预付款的提议(步骤78)。
在卖方120接受预付款的提议后,交易处理系统130随后锁定交易。即,之后不能修改买方110、卖方120以及买方银行112之间交易的条款。
在议定的预付款日期,买方银行112于是将资金预付给卖方120 (步骤82)。可以使用支付处理系统140和交易处理系统130来预付资金。图l(a)中的附图标记5示出了可以发生在交易处理系统130和支付处理系统140之间用于发起资金转帐的消息传递。在一个实施例中,支付处理系统140可以执行授权过程(步骤84)。如图l(a)中的附图标记5示出的,支付处理系统140可以将请求对资金转帐授权的授权请求消息发送给买方银行112。如果批准了,那么买方银行112接着可以发回批准预付款的授权响应消息。
如图1(a)中的附图标记7和8所示,在买方银行112准予预付款之后,执行结算和清算过程(步骤86)。接着将资金发送给卖方银行112。如图l(a)中的附图标记9所示,接着向卖方的帐户贷记。
在信用卡交易中使用授权和清算过程。作为背景,在信用卡交易的情况下,电子支付可以被分成两个部分授权过程以及结算和清算过程。当消费者在销售点购买货物或服务时,授权过程实质上是实时进行的(例如在几秒之内,诸如少于10秒),而结算和清算过程稍后进行。在授权过程中,支付处理系统检査消费者信用贷款的最高限额或消费者帐户中的资金,并将该信息中继回商家以便通知商家和消费者关于消费者是否具有足够的信用或资金来进行所期望的交易。在结算和清算过程中,支付处理系统合并不同受让方和发行机构的各个交易,并且在它们之间清算帐户。在结算和清算过程中,能够转帐实际的资金。通常该过程在从消费者购
买的日期后两或三天内完成。接着,随后在消费者帐户的定期报表中为该购买向消费者开帐单。
再次参考图l(a),如附图标记IO所示,在合同支付日期,买方110向买方银行112发送合同金额的付款,而非卖方120或卖方银行122。例如,在先前所描述的示例中,买方110可以在12月1日将用于由卖方提供的IOOO台计算机监视器向买方银行112发送$300,000,而非卖方120或卖方银行122。假设买方银行112、卖方120和买方IIO之间的交易按计算进行,那么买方银行112由于预付款给卖方120将净赚$30,000。
在完成交易之后,更新历史数据库130(b)(步骤88)。例如,如果买方110按时(即在合同到期日)支付合同金额,那么将在历史数据库130(b)中更新买方的交易历史以反映之。如果买方IIO没有及时支付,那么也将在历史数据库130(b)中更新交易历史以反映之。可以记录在历史数据库130(b)中的买方的交易行为的特征可以包括买方是否按时或全额支付;相对于其它类型的产品,买方是否以提前的方式对一些类型的产品付款;买方需要多久来支付帐单等。可以参考图2(a)和2(b)来描述支付历史应付款打折过程。图2(a)示出了根据本发明的一实施例的系统的框图,且类似于图1 (a)的框图。在该示例中,买方银行112在合同支付到期日向卖方120付款,而买方110在合同支付到期日之后向买方银行112付款。
首先,买方IIO和卖方112向交易处理系统130登记(步骤170)。接着,如上所述以及如图2(a)的附图标记11所示,买方110和卖方120使用交易处理系统130进行各种商业交易(步骤172)。
在某个时间点,买方110和卖方120使用交易处理系统130进入特定的商业交易。如图2(a)的附图标记12所示,接着将该交易通知买方银行112,而买方银行112从交易处理系统130获取与买方110相关的交易信息(步骤174)。
如图2(a)的附图标记13所示,买方银行112接着向买方IIO作出延迟付款的提议(步骤176)。如果该提议对买方110是可接受的,那么买方110接着接受来自买方银行112提议,如附图标记14所示(步骤178)。作为例示,在买方110和卖方120之间购买计算机监视器的合同中,买方110有义务在6月1日向卖方120支付$300,000。买方银行112可以提议在6月1日向卖方120支付合同金额$300,000,但是直到ll月1日要求买方110支付。作为该贷款的交换,会向买方110收费。费用可以是固定的费用或者可以是交易金额的百分比。
买方银行112接着向交易处理系统130预付资金(步骤180)。在此之前或之后,买方IIO指示与买方银行112通信的交易处理系统130以在合同支付到期日发放付款(步骤182)。
如图2(b)和图2(a)中的附图标记15、 16和17所示,支付处理系统140执行授权过程(步骤184),并且还执行结算和清算过程(步骤186)(如上所述)。如图2(a)中的附图标记18所示,在卖方银行122接收到资金后,在合同支付到期日向卖方120在卖方银行122处的银行帐户贷记。
如图2(a)中的附图标记19所示,接着在合同支付时间之后的时间向买方110的银行帐户借记(步骤188)。
在完成商业交易之后,在历史数据库130(b)中更新买方110和卖方120的交易历史(步骤190)。
可以参考图3(a)和图3(b)描述支付历史分发过程。图3(a)示出了根据本发明的—实施例的系统的框图,其类似于图l(a)中的框图。在该示例中,卖方银行122 (而非买方银行112)在合同支付到期日之前将资金预付给卖方120。在先前的实施例中,买方110和卖方120向交易处理系统130登记(步骤270)。 接着,如先前所述和图3(a)中的附图标记21所示,买方IIO和卖方120使用交易 处理系统130进行各种商业交易(步骤272)。
在某个时间点上,在特定的商业交易中涉及买方110和卖方120。如图3(a) 中的附图标记22所示,接着将交易通知给卖方银行122,而卖方银行122从交易 处理系统130获取与买方110相关的交易信息(步骤274)。
如附图标记23所示,卖方银行122接着向卖方120作出预付款的提议(步骤 276),而卖方120接受来自卖方银行122的提议(步骤278)。卖方银行122接 着在合同支付到期日之前的日期向卖方120预付资金(步骤280)。
在某个时间点上,买方IIO接着在到期时(即合同支付到期日)发放付款(步 骤282)。如上所述,如附图标记25、 26和27所示,支付处理系统140接着执行 授权、结算和清算过程(步骤284和286)。
在完成商业交易之后,在历史数据库130(b)中更新买方和卖方的交易历史(步 骤288)。
可以参考图4(a)和4(b)描述第三方融资和打折过程。图4(a)示出了根据本发明 的一实施例的系统的框图,其类似于图l(a)的框图,其不同之处还示出了第三方融 资银行160。第三方融资银行160也包括至少一个计算机装置160 (a)。该示例示 出了第三方融资实体(例如与买方110或卖方120无特别关联的实体)可以向买方 110或卖方120融资,而不是买方银行112或卖方银行122。
如上所述,买方110和卖方120向交易处理系统130登记(步骤470)。接着, 如上所述和如图4(a)中的附图标记41所示,买方110和卖方120使用交易处理系 统130进行各种交易(步骤472)。
在某个时间点,买方110和卖方120进入特定的商业交易。如图4(a)的附图标 记42所示,接着将交易通知给第三方银行160,而第三方银行160从交易处理系 统130获取与买方110相关的交易信息(步骤474)。
如图4(a)的附图标记43所示,第三方银行160接着以类似于上述的方式向卖 方120作出预先借记或向买方IIO作出推迟借记的提议(步骤476)。买方110或 卖方120接着接受来自第三方银行160的提议(步骤478)。接着,第三方银行160 根据是向卖方120作出预先借记提议还是向买方IIO作出推迟借记的提议,在支付 条款之前或支付条款之时向卖方120预付资金(步骤480)。
买方428接着在到期时发放付款(步骤482),而第三方银行160可以适当地向买方银行112或卖方银行122发送资金(步骤484)。
在完成商业交易之后,在历史数据库130(b)中更新买方和卖方的交易历史(步 骤288)。
可以参考图5(a)和5(b)描述支付历史提供过程。图5(a)示出了根据本发明一实 施例的系统的框图,其具有图l(a)中也示出的组件。然而,在图5(a)中,未示出买 方银行、卖方银行和支付处理系统。在该示例中,卖方120将支付历史信息用于基 于买方前的交易历史判定是否将货物运送给买方110。
如上所述,买方110和卖方120向交易处理系统130登记(步骤570)。接着, 如上所述和如图5(a)中的附图标记51所示,买方110和卖方120使用交易处理系 统130进行各种交易(步骤572)。如图5(a)的附图标记52所示,接着将交易通 知给卖方银行120,而卖方银行120从交易处理系统130获取与买方110相关的交 易信息(步骤574)。
如附图标记53所示,卖方120接着使用交易信息来判定是否运送货物(步骤 576)。例如,如果在接收到交易信息之后,卖方120相信卖方120可能不会按时 和/或全额得到付款,那么卖方120然后会判定不将货物运送各买方110。另一方面, 如果交易信息指示买方110具有较好的风险,那么卖方120会将货物运送给买方 110。
在完成买方110和卖方120之间的商业交易之后,在历史数据库130(b)中更 新买方和卖方的交易历史(步骤578)。
可以参考图6(a)和6(b)描述支付历史匹配过程。图6(a)示出了根据本发明一实 施例的系统的框图,其具有也在图l(a)中示出的组件。在图6(a)中,示出一般银行 114与交易处理系统130通信。 一般的银行114具有至少一台计算机装置114(a)。 一般银行114可以是买方银行、卖方银行或某些其它的实体。
同样,在该示例中,有两个买方/卖方(B-S)实体117、 119,其各自具有一 计算机装置117(a)、 119(a)。B-S实体117、 119用作货物和服务的买方和卖方两者。 B-S实体的一个示例可以是向零售商店销售计算机的计算机制造商,但也购买部件 用以构建计算机。在该示例中,在接收支付历史信息之后,可使应付款和应收款相 匹配。该匹配服务可被提供给银行,并且可标识将来帐户的应收款以便保证帐户应 付款(资产融资/担保等)。
首先,B-S实体117、 119向交易处理系统130登记(步骤670)。接着,如 上所述以及图6(a)中的附图标记61所示,B-S实体117、119使用交易处理系统130进行各种交易(步骤672)。如图6(a)中的附图标记62所示,银行114获取与B-S 实体117、 119相关的交易信息。
银行114查询交易数据以使实体117、119之间将来的应付款和应收款相匹配, 并接着标识不同的B-S实体117、 119之间将来的应付款和应收款(步骤674、676)。 在银行114判定特定B-S实体具有可以与较好的应付款(即可能被支付的应付款) 相匹配的较好的应收款(即可能被支付的应收款)之后,可以匹配B-S实体117、 119的支付历史。
在银行114标识可以相匹配的将来的应付款和应收款之后,银行114接着锁 定将来的应收款,并使它们与应付款相匹配(步骤678)。在到期日,银行114计 算交易的净余额并移动任何剩余的资金(步骤680)。最后,如在前的实施例中, 可以在历史数据库130(b)中更新任一 B-S实体117、 119的交易历史。
本发明的各实施例具有许多优点。在本发明的各实施例中,交易处理系统向
诸如卖方和银行(和其它金融机构)等实体提供有关特定买方或卖方的详细的交易
信息,从而可以作出后续的融资和交易判定。交易信息可以包括与买方和卖方的交
易历史相关的原始或经处理的交易数据。从交易处理系统获取的交易信息是及时
的、精确的且对于这种实体可访问的。同样,诸如公司等买方和卖方可以使用来自
交易处理系统的信息来作出交易判定和/或寻求来自银行或其它金融实体的融资和
/或打折。同样地,由于在本发明的各实施例中使用的交易处理系统监视由多个买
方和卖方进行的商业交易,本发明的各实施例也可以用于提供对应收款的某些欺诈
控制,因为进行商业交易的各方都是已知的。最后,诸如银行等商业实体还可以在
市场环境中对非消费者的打折/融资判定作出投标。
本发明的各实施例还有许多其它的优点。例如,在本发明的各实施例中,买 方或卖方可以在交易处理系统中不断地请求融资提议,并且可以使任一银行与交易
处理系统通信以提供融资提议。
最后,也应该注意,对于公司而言,本发明的各实施例可用于标准检查 (benchmarking)帐户应付款和帐户应收款功能的匿名池(blind peer pool)。公 司可以基于行业、商品、公司规模等来查看该池。
此处所使用的术语和表达是用作描述的术语而非限制,而且并不旨在使用这 种术语和表达来排除所示和所描述的特征的等价物或其部分,应该认识到各种修改 都可能在所要求保护的发明的范围内的。此外,本发明的任一实施例的任一个或多 个特征可以与本发明的任何其它实施例的任何一个或多个特征结合,而不背离本发明的范围。
应该理解,上述的本发明可以用模块化或集成的方式使用计算机软件的控制
逻辑的形式来实现。基于此处所提供的揭示和示教,本领域的一般技术人员会知道
和理解使用硬件以及硬件和软件的组件来实现本发明的其它方式和/或方法。
在本申请中所描述的任一软件组件或功能可以被实现为由处理器使用诸如
Java、 C十+或Perl等任何合适的计算机语言用例如常规或面向对象的技术执行的软 件代码。软件代码可以在计算机可读介质上被存储为一系列指令或命令,所述计算 机可读介质诸如随机存取存储器(RAM)、只读存储器(ROM)、诸如硬盘或软 盘等磁介质或诸如CD-ROM等光介质。这种计算机可读介质中的任一个可以驻留 在单个计算装置之上或之中,并且可以出现在系统或网络内的不同的计算装置之上
或之中。
以上描述是说明性的而非限制性的。通过阅读本说明书,本发明的许多变体 将对本领域的技术人员变得显而易见。由此,本发明的范围不应该参考以上描述来 确定,而是应该参考未决的权利要求以及它们全范围或等价物来确定。此外,来自 任一实施例的一个或多个特征可用与任一其它实施例的一个或多个特征结合,而不 背离本发明的范围。
书面称述"一"、"一个"或"该"旨在意为"一个或多个",除非明确地 指示相反。
上述所有专利、专利申请、出版物以及描述通过整体引用包含于此,以实现 所有目的。没有任一个被视为现有技术。
权利要求
1.一种方法,包括接收与由使用交易处理系统进行商业交易的多个买方和卖方所进行的多个商业交易相关的交易数据;接收来自实体的对有关接收到的交易数据的交易信息的请求,其中所述交易信息也涉及买方和卖方之间的商业交易;以及向实体提供所述交易信息,其中所述实体然后作出有关进一步与所述买方或所述卖方交互的决定。
2. 如权利要求l所述的方法,其特征在于,所述交易信息包括风险信息,其 中所述风险信息包括对所述买方或所述卖方的风险评级。
3. 如权利要求l所述的方法,其特征在于,所述实体包括买方银行。
4. 如权利要求1所述的方法,其特征在于,所述实体包括卖方银行。
5. 如权利要求l所述的方法,其特征在于,还包括在提供所述交易信息之后, 接收由所述实体预付的资金。
6. 如权利要求l所述的方法,其特征在于,支付到期日与所述商业交易相关 联,且所述方法还包括接收由所述实体预付的资金,并且接着在所述支付到期日之 前的预付款日将所述资金转给所述卖方。
7. 如权利要求l所述的方法,其特征在于,支付到期日与所述商业交易相关 联,且所述方法还包括接收由所述实体预付的资金,并且然后在所述支付到期日之前的预付款曰将 所述资金转给所述卖方;在所述交易到期日向所述买方的帐户借记。
8. 如权利要求l所述的方法,其特征在于,还包括 在进行所述商业交易之后,更新支付历史数据库。
9. 如权利要求l所述的方法,其特征在于,所述实体是所述卖方,其中所述 交易信息包括风险信息,且其中所述风险信息帮助所述卖方判定是否运送与所述商 业交易相关联的货物。
10. 如权利要求1所述的方法,其特征在于,所述交易信息包括与所述买方 或所述卖方相关联的将来的应收款信息以及将来的应付款信息,其中在将所述交易信息提供给所述实体之后,所述实体使应付款和应收款相匹配。
11. 一种计算机可读介质,包括用于接收与由使用交易处理系统进行商业交易的多个买方和卖方所进行的多 个商业交易相关的交易数据的代码;用于接收来自实体的对有关接收到的交易数据的交易信息的请求的代码,其 中所述交易信息也涉及买方和卖方之间的商业交易;以及用于向实体提供所述交易信息的代码,其中所述实体然后作出有关进一步与 所述买方或所述卖方交互的决定。
12. 如权利要求ll所述的计算机可读介质,其特征在于,所述交易信息包括 风险信息,其中所述风险信息包括对所述买方或所述卖方的风险评级。
13. 如权利要求ll所述的计算机可读介质,其特征在于,所述实体包括买方 银行。
14. 如权利要求ll所述的计算机可读介质,其特征在于,所述实体包括卖方银行。
15. 如权利要求ll所述的计算机可读介质,其特征在于,还包括在提供所述 交易信息之后接收由所述实体预付的资金。
16. 如权利要求ll所述的计算机可读介质,其特征在于,支付到期日与所述 商业交易相关联,且其中所述方法还包括接收由所述实体预付的资金,并且然后在 所述支付到期日之前的预付款日将所述资金转给所述卖方。
17. 如权利要求ll所述的计算机可读介质,其特征在于,支付到期日与所述商业交易相关联,且其中所述计算机可读介质还包括用于接收由所述实体预付的资金,并且然后在所述支付到期日之前的预付款曰将所述资金转给所述卖方的代码;用于在所述交易到期日向所述买方的帐户借记的代码。
18. 如权利要求ll所述的计算机可读介质,其特征在于,还包括 用于在进行所述商业交易之后,更新支付历史数据库的代码。
19. 如权利要求ll所述的计算机可读介质,其特征在于,所述实体是所述卖 方,其中所述交易信息包括风险信息,且其中所述风险信息帮助所述卖方判定是否 运送与所述商业交易相关联的货物。
20. 如权利要求ll所述的计算机可读介质,其特征在于,所述交易信息包括与所述买方或所述卖方相关联的将来的应收款信息以及将来的应付款信息,其中在将所述交易信息提供给所述实体之后,所述实体使应付款和应收款相匹配。
21. —种服务器计算机,包括如权利要求ll所述的计算机可读介质。
22. —种系统,包括包括如权利要求21所述的服务器计算机的交易处理系统;以及 有效耦合到所述交易处理系统的支付处理系统。
23. 如权利要求22所述的系统,其特征在于,还包括有效耦合到所述支付处 理系统的买方银行和卖方银行。
全文摘要
揭示了一种方法。该方法包括接收与由使用交易处理系统进行商业交易的多个买方和卖方所进行的多个商业交易相关的交易数据,接着接收来自实体的对有关接收到的交易数据的交易信息的请求,其中该交易信息也涉及买方和卖方之间的商业交易。该方法还包括向实体提供交易信息,其中该实体然后作出有关进一步与买方或卖方交互的决定。
文档编号G06F17/00GK101578595SQ200780049055
公开日2009年11月11日 申请日期2007年10月24日 优先权日2006年11月17日
发明者C·斯沃克哈姆, F·马斯林, M·贝尔斯基, W·里德 申请人:维萨国际服务协会
网友询问留言 已有0条留言
  • 还没有人留言评论。精彩留言会获得点赞!
1