CN101044503A - 用于解决交易的系统和方法 - Google Patents

Abstract

本说明书描述了一种用于在线结算交易的系统和方法，其中在用户(诸如债务人)和服务器之间建立网络通信。本设计包括在服务器接收关于交易的信息；从所述服务器和所述用户之外的至少一个源查找与所述交易有关的可用信息；使用基于决策的引擎，处理来自所述可用信息的数据，该引擎包括代表位于所述服务器上的交易方建立的规则；以及基于由所述基于规则的引擎做出的至少一个决策，将交易结算提议集呈现给用户。在线时，用户/债务人可以接受提议集中的一个提议，或者可以更进一步加入到其它提议同意的协商中。

Description

用于解决交易的系统和方法

相关申请的交叉引用

【0001】本申请要求申请于2004年10月19日的名称为“债务结算计算机系统和方法(Debt Settlement Computer System and Method)”的美国临时专利申请60/620,131的权益。

【0002】本发明文档公开的一部分包含受到版权保护的素材。版权所有者不反对由专利文档或专利公开的任何人对其全部复制，并且以美国专利和商标局公开或发表的来自其专利文件或记录的文档中显示的形式，但对于其它任何方式保留所有的版权。

技术领域

【0003】本发明一般涉及用于处理和解决交易的系统和方法，并具体涉及使用计算机网络追回债务和/或管理与债务有关的信息的系统和方法。

景技术

【0004】某些类型的财务交易，特别是解决这种财务交易伴随着复杂，耗时的特点，并且常常采用昂贵的方法，该方法集中在收集信息并促进财务交易的解决。例如，债务解决一般需要调查债务人偿还债务的能力，债务可以被解决以达到令债权人满意的程度需要的期限，以及追回债务，这一般通过电话或以其它方式亲自联系债务人，促进债务的解决。当加入某些限制后，债务解决中的复杂性会增加，诸如收债人无力在他或她的工作场所留下适当的消息，关于谁可以获得信用报告的问题，和在什么情况下可以获得信用报告等。

【0005】另一种交易解决情况包括保险理赔领域。而且，解决保险索赔需要进行调查，或需要预测索赔人乐于接受的数额，承保人乐于提供的数额，和使承保人代表和索赔人解决交易的机制。一般，承保人代表和索赔人和/或索赔人的代表面对面或通过电话会谈以进行协商，并确定满意的数额，这基于许多因素，包括但不局限于损害的严重性，索赔人的财务状况，为结算提供资金的成本和其它相关因素。

【0006】关于债务结算，以前债务追回最有效的方法一直是通过债权人(或其代理机构)直接打电话给债务人。而债务人一般会感到被侵犯，有敌意，原因是债权人试图通过某些相对要胁的言辞策略强行追讨债务。

【0007】个体追款员一般是收取佣金的，即接受基于从债务人追回的数额的报酬。在佣金基础上的报酬与债权人的目标和债务人的偿还能力是对立的，原因是追款员希望偿还的数额最高，以提高她个人的佣金，然而债权人寻求的是未尝资产组合(protfolio)的总追回或回收最高。关于从个人债务人追回最高数额和最高总追回数额上的二分法，债权人通常能够通过以70％的结算条件(两千一百万美元)追回10亿美元资产组合的30％，而不采用以90％的结算条件(一千八百万美元)回收10亿美元资产组合的20％，来追回更多的债务。因此，使用过度积极的策略来追回一部分债务，会不利地影响债权人追回另一部分债务的能力，通过口头文字或其它途径可能限制债权人的总的全部追回数额。

【0008】一般通过追款员追回债务的成本包括薪水，佣金以及操作和设施成本(如，电，办公场所，家具，台式设备和维护，电话设备，运行和维护，行政支持人员和会计等)。不仅追回债务需要薪水和佣金，而且调查借方和其偿还能力也需要薪水和佣金。

【0009】债务追回一般是由实体完成的，实体并不提供资金(fund)，但是出一笔钱购买债务。这些实体的功能仅是为了追回债务的目的，同样，在操作时，这些实体也具有某些权利和限制。当这些实体中的一个寻求追回债务时，一个债务保持拖欠的时间越长，债务由于利息费和罚款也会增加。总的追回债务的可能性会随着时间减少。债务中的大部分会变成“脱离条例”，并在7年后变成在法律上是不可追回的。因此，联系债务人并处理账户必须在指定的时间限定内进行。更复杂的情况是在债务资产组合的购买，保持和销售程序中，债务买方和卖方可能不积极地购买。

【0010】一旦一个实体已经购买了债务，并发出了拖欠通知，则此实体或其代理机构会尝试联系债务人，一般是通过涉及记录的消息的昂贵的通往国外拨号器计划。在当今社会，联系信息的变化会给追回债务带来很大问题。当前的跳跃追踪信息提供者，诸如LexisNexis，Accurint，TransUnion，Experian和Equifax返回仅25％的提交账户的当前电话号码。因此，平均75％的跳跃追踪的债务人不能通过电话联系。必须首先拨目前的电话号码，目的是确定电话号码是否仍在使用，并且是否仍由原来的债务人使用。电话号码经常被重新分配，拨打改变的电话号码的成本很高，并且效率极其低。

【0011】一般而言，追款人一般可使用诉讼威胁、在债务人的信贷局或信用局(credit bureau)邮寄贬损性的信息，并且当与债务人打交道时，提供减少数额的结算作为主要工具。对于最佳总回报或追回款项，追回实践一般不是最优的。基于一般的先前经验，但需要进行一定量的调查，拇指规则(rules of thumb)用于结算数额，例如，确定是否向信用局报告拖欠状况会随时间变化对债务人和/或债务人偿还一定数额债务的能力有重要影响。追回程序的花费不允许将大数额的结算提议协调到个体债务人上。

【0012】在其它的交易解决情况下，包括但不局限于保险理赔，慈善抵押(charitable pledging)，政治目的的筹集资金和类似情况，需要的某些活动可能增加成本并且可能要求个人出现，诸如一个人打电话给另一个人，以及要求弄清偿还或被支付一定数额的能力或愿望等。这些要求可能是低效的，在某些情况下是困难又麻烦的或完全不可行的。

【0013】根据以上描述，如果有一个系统和方法与以前用于此类目的所使用的系统和方法相比，能改进交易解决或解决方案，诸如债务结算和追回程序，这将是很理想的。

发明内容

【0014】根据本设计的一个方面，提供了一种用于在线解决交易的系统和方法，其中在用户，诸如债务人和服务器之间建立网络通信。服务器接收关于交易的信息。也可以获得财务信息，宏观经济因素，历史数据和/或与交易有关的来自其它源的信息，诸如信用报告，并且获得的信息和/或与用户和/或交易相关的其它信息可以使用规则引擎被处理，该规则引擎是运行在服务器上的。由规则引擎使用的规则可以被预先定义，或代表交易的一方，诸如债权人，基于期望的交易解决策略被建立。包括至少一个结算提议的交易结算提议集，基于一个或多个由规则引擎做出的决策被呈现给用户。在线时，用户可以接受众多提议中的一个提议，或者可以更进一步加入到被认可的其它提议的协商中。

【0015】根据本设计的另一方面，呈现了一种用于结算交易的方法，该方法包括在用户和服务器之间建立网络通信，在服务器接收关于交易的信息，从服务器和用户外部的至少一个源查找与交易有关的可用信息，使用基于规则的引擎处理来自所述可用信息的数据，该引擎包括位于所述服务器上的代表交易一方建立的规则，并基于所述基于规则的引擎做出的至少一个决策，将交易结算提议集呈现给用户。

【0016】从以下的详细描述和相应附图中，本发明的这些优点和其它优点对本领域技术人员来说将变得明显。

附图的简要描述

【0017】为了更彻底地理解本公开，现在参考以下附图，其中相同的参考号在所有的图中指相同的项目：

【0018】图1图解说明了用于根据本发明的交易解决设计的一个实施例的计算机系统；

【0019】图2是根据本设计的一个实施例由图1的服务器执行的软件模块的逻辑表达；

【0020】图3A图解说明了根据本设计的一个实施例的用于债务追回的流程；

【0021】图3B是用于本设计的一种可选的流程；

【0022】图4图解说明了本设计的一个实施例的债务人交互端的结构示意，它是在微软平台上实现的；

【0023】图5是债权人系统结构的一个实施例；

【0024】图6示出了表示本设计的一个实施例的系统运行的可选实施例；

【0025】图7图解说明了支付合伙人服务器交易流程的实施例；

【0026】图8是使用模式(schema)将源数据映射到字典的一般概念的实施例；

【0027】图9图解说明了根据本设计的一般债权人/信贷代理的工作流程；

【0028】图10是根据本设计的一般债务人工作流程；

【0029】图11示出了互联网浏览器的屏幕照片，其具有特定于信用局的结算项目；

【0030】图12显示了用于特定债权人或信贷代理的一整套结算条款；

【0031】图13图解显示了结算字典，在该实施例中，它包括创建和编辑债务结算项目和转让标志，诸如XML标志的选项以匹配源数据；

【0032】图14表示用于报告的一般格式，特别用于报告债务资产组合的追回统计；

【0033】图15图解显示了一般的空白表格，它包括可以填写结算提议数据并为了发出结算提议目的呈现给债权人的字段；

【0034】图16示出了资产组合管理器，并图解说明了组织单元(OrgUnit)的概念；

【0035】图17示出了用于系统创建的资产组合的规则管理器；

【0036】图18图解说明了子资产组合的概念；

【0037】图19示出了字典管理器屏幕；

【0038】图20是选择的包括属性的字典的屏幕照片；

【0039】图21图解说明了可以被债务人/用户查看的屏幕照片；和

【0040】图22是使用包括规则的结算条款的一个可选的实施例，用来形成用于显示的实施例的给债务人的提议。

【0041】本说明书中列出的范例说明了具体的实施例，这种范例并不被解释为以任何方式对保护范围的限制。

具体实施方式

【0042】以下描述和附图图解说明了特定的实施例，足以使本领域技术人员能实践所描述的系统和方法。其它的实施例可以包括结构上，逻辑上，程序上的变化和其它变化。这些例子仅代表可能的变化。个别部件和功能一般是任选的，除非明确要求，运行的顺序也可以变动。一些实施例的部分和特征可以包括在另一些实施例中，或者替代另一些实施例中的那些部分和特征。

【0043】一般而言，本设计包括用来解决交易的系统和方法，包括但不局限于通过提供自动化的信息采集系统来解决债务，解决保险结算索赔，建立慈善捐献等，该信息采集系统采集关于交易一方的信息；基于由交易另一方建立的一套规则，分析采集的信息和/或在采集的信息上操作；并基于采集和分析的信息，将特定的提议呈现给个人。一般通过计算机网络，诸如通过互联网，一般通过加密的连接，提供提议和信息。然后，个人可以选择呈现的多个选项中的一项选择，或者可以拒绝选项，这里可以请求和/或输入特定的附加信息，并且将交易进一步向解决的方向推进。即使在使用当前的设计没有解决交易的情况下，接收到的信息对确定交易双方解决交易的能力和愿望都是有用的，并且接收到的信息指示解决交易的下一个逻辑步骤，诸如提起诉讼或不解决交易。因此，本设计使全部的交易解决程序自动进行，因此能够降低成本，节省时间，并降低与此相关的交易各方可接受的条款的复杂性。

【0044】鉴于已经提供了前面的系统，它使能够在线呈现提议以满足需要，诸如个人联系网站以获得汽车保险或抵押，那些类型的设计一般已经向用户提供了许多提议，而在呈现提议之前，不需要查找任何关于用户的信息。尽管那些类型的点可能要求用户输入，但例如在三个不同的贷方的三个提议被呈现给用户之前，不会发生外部调查或信息查找。本设计不仅查找与用户和/或交易有关的相关外部信息，而且本设计还解决了现有的关于交易的意见分歧。本设计考虑了关于现有交易处在不同位置的两方，诸如债务，保险结算，或其它两方类型的交易。

【0045】本设计将两方引领到一起，并使一方具有使用基于规则引擎中的一套规则形成提议集以解决交易的能力。因此，本设计使用在基于规则的引擎中从外部获得的关于交易和/或用户的信息，自动化交易的解决，该引擎具有部分基于一方希望的协商规则提供的规则。

【0046】实施本系统和方法的各种实施例的单元将在下文进行描述，在一些情况下是结构级别上的描述，在另一些情况下是逻辑级别上的描述。使用熟知的结构可以配置许多单元。本说明书中的功能性和程序采用的描述方式使本领域普通技术人员能够实施结构内的功能性和程序。

【0047】下文描述的处理过程可以由单一平台实现，或通过分布式处理计算平台实现。此外，此类处理过程和功能性可以以特定用途的硬件形式来实现，或者以由通用处理器或网络处理器运行的软件或固件的形式实现。在这种处理过程中处理的数据或做为这种处理结果产生的数据可以被存储在任何本领域内传统类型的存储器中。作为例子，这种数据可以存储在临时存储器中，诸如存储在给定计算机系统或子系统的RAM中。此外，或者可选地，这种数据可以存储在长期的存储设备中，诸如磁盘，可重写光盘等。为本说明书的公开目的考虑，计算机可读介质可以包括任何形式的数据存储机制，包括现有的存储技术，以及这种结构和这种数据的硬件或电路表示。

【0048】本系统和方法的技术可以使用各种技术被实现。例如，本说明书描述的方法可以用运行在可编程微处理器上的软件实现，或者用微处理器或其它专门设计的专用集成电路，可编程逻辑器件，或它们的各种结合的硬件来实现。特别地，本说明书描述的方法可以通过一系列计算机可执行的指令来实现，这些指令驻存在诸如载波，磁盘驱动器或其它计算机可读介质的存储介质内。

【0049】而且，尽管本说明书主要关于用于解决债务结算情况中的交易的示例性的系统和方法进行了描述，但本说明书的发明和公开并不受其限制。如注意到的，本设计可用于各种情况下，进一步包括但不局限于保险理赔，慈善捐献等。

【0050】本说明书中使用的术语“实体”指个人，公司，合伙企业或其它类型的法人实体。下文将描述的系统和方法的一个特定的实施例有时也被称作“智能债务结算系统”或“IDS系统”，或甚至简称为“IDS”。

【0051】系统可以被在线操作，或通过互联网，如用于债权人或它们的代理人(例如，包括债务托收公司，债务托收机构和法人代表)的基于网络的平台，以使债务人在一天中的任何时间进行账户结算。债务人可以登录或连接到该系统，并在家里或办公室私下处理账户，不会造成给追款部门或追款机构打电话并与追款员交谈的不方便情况。该系统可以使债权人能够使用他自己的决策标准在线创建债务结算条款，因此有助于债务人和债权人/欠款托收机构更加快速地在线达成互惠的解决方案，而不需要牵涉到代理机构的追款员。

【0052】当债务人加入到在线会话时，系统会询问特定的信用信息，包括但不局限于信用报告。基于如此确定的信用信息和债权人预先定义的追款原则，债权人/欠款托收机构可以基于债务人的偿还能力，确定债务人可用的结算提议。在更少对抗的环境下，债务人可以选择最希望的结算提议。使用在线付帐技术，系统可被用于处理支付，并且系统可以用当前的信息(诸如实际的债务结算)更新信用局。系统可以给所有请求该交易的合适的交易方发出通知书。系统可以给债权人提供信息，以使债权人可以查看并实时在线管理资产组合结算参数。

【0053】使用公开的标准，系统一般可被实现。例如，系统可以被构建在Microsoft Visual Studio.NET和SQL Server 2000内，可以是全部服从于XML的。系统可以在安全的数据中心上运行，并且系统能成为网络服务，以向其战略企业合伙人提供技术基础。

【0054】系统的最终用户可能包括可以访问互联网的拖欠消费者债务人。为了大概定义使用系统和/或与系统相关的实体，这些当事人方可以包括“债权人”，即将钱贷给诸如个人的其它实体的实体，并且这些“债务人”欠了债权人的钱。实体可以包括银行，信贷协会和其它信用机构，但也可以包括向实体提供金钱，货物和/或服务的其它人，诸如律师，医生等。“主要债权人”是具有内部追款资质或能力的债权人。在这种情况下，“债务人”是那些具有承担来自债权人的债务的实体。个人，合伙企业，公司，政府实体和实际上是任何人或商业机构都可以成为债务人。“欠款托收机构”代表主要债权人一般以回收费用的百分比追款。“收款贴现者(collection discounter)”一般购买债务，并在内部或机构内追回该债务。收款贴现者独立于债权人或主要债权人，而欠款托收机构一般是债权人或主要债权人的代理人。

【0055】系统的逻辑概括图示于图1。在图1中，计算机系统100包括一般用于交易解决的服务器102。服务器102可以通过通信网络110与债务人设备106通信，债务人设备例如个人计算机或PDA。债权人服务器104，由债权人或代表债权人操作(如，操作债务人设备106的债务人的债权人)可通过通信网络108连接到服务器102。采集软件120，其可以是债权人使用的现有软件，运行于债权人服务器104上。信用局服务器116通过通信网络107与服务器102通信。支付合伙人服务器114通过通信网络109与服务器102通信。

【0056】通信网络107，108，109和110可以是如互联网或局域网或广域网。应用程序可以运行在债务人设备106上，并提供由债务人访问服务器102的通道，应用程序诸如互联网浏览器或其它应用程序，其向债务人提供图形界面或其它用户界面。服务器102上的债务人账户可以被激活或被访问，如使用债务人提供的登录信息激活或访问。

【0057】服务器102可以执行软件112，这将在下文详细描述。关于债务人的信息，如由债权人操作的债权人服务器104保存的与债务相关的信息，可以存储在账户/交易数据库118上，它可以由服务器102访问。注意服务器可以从内部源或外部源获得其它信息，以方便交易，并使下文关于软件112描述的规则能应用到接收的数据中，以向用户呈现提议集。被查找的信息的例子包括以一些方式与用户或交易相关的信息，诸如宏观经济数据，财务信息，交易信息，个人信息或其它相关数据。例如，当用户/债务人居住在遭受自然灾害的地区，如果债务交易中的债权人希望延长一段时间结算债务，则系统会获得债务人居住的地区的状况信息。这种信息查找可基于呈现的规则进行或独立于呈现的规则进行。这种信息可以从，诸如账户/交易数据库118，从债权人服务器104，或从图2中未示出的一些远程源中获得，这些远程源诸如公众可访问的天气服务器或财务数据服务器。

【0058】软件112可以与采集软件120交互，以使与债务人相关的数据在服务器102和债权人服务器104之间是同步的，诸如以实时方式或安全批处理方式。

【0059】一般而言，示于图1的系统运行以使债务人和债权人或债权人代表/代理人一起处理交易，一般通过基于由债权人建立的规则向债务人提供一定数量的选项，其中由债权人提供的信息可以被分析并被处理，以建立债务人可用的选项。服务器102可以保存或访问某些信息，但也可以功能性地运行以保存信息，收集信息，并处理操作债务人设备106的债务人，债权人服务器104，信用局服务器116和支付服务器114之间联系。

【0060】图2图解说明了可以由服务器102执行的软件模块的逻辑配置，服务器102是软件112的一部分。如，这些逻辑模块中的一些或全部可以分布在多个服务器上。债务人界面222可以使用债务人设备106向债务人提供界面，并将此类债务人提供的信息提供给决策引擎206。信用局模块202可以从信用报告所获得目前访问服务器102的债务人的信用报告。

【0061】信用报告一般以具有大量信息的形式表现为实体调查信用报告或个人请求信用报告，信息包括但不局限于诸如信用卡发行者，汽车或房屋贷款债权人的账户实体；信用报告还可以包括诸如已经支付或未支付，评价，破产，或其它相关信息。在一些情况下，信用等级或信用评分被计算，并提供。一般该报告包括个人或实体的名称，及其它识别特征，诸如地址，电话号码，出生日期，出生地，社会保障号，或其它个人信息。对具有大量活动的个人或实体，这类信用报告可以包括数百甚至数千项的个人信息。

【0062】信用报告以特定于其发行者的格式发布。如，信用报告局A可以提供脚本或其它数据格式，诸如一连串记录，包括(按顺序)名字，姓，中间名，当前街道住址，当前城市，当前州，当前邮政编码，当前电话号码，破产，破产日期，破产审理法庭，账户名字等。信用报告所B可以提供不同的脚本或其它数据格式，这些格式包括名字，中间名，姓，当前区号，当前电话号码，当前街道号，当前街道，当前单元号，当前州，当前邮政编码，信用评分，账户名字，账户状态，账户按月支付情况等。尽管可能包括相同的一般信息，但格式和顺序可能完全不同，并可能会呈现不同的实体。对每个发行者而言，该结果是不同的信用报告。

【0063】系统100在信用局模块202处获得由信用局服务器107提供的一定格式的信用报告。一般信用局识别信息是与信用报告一起提供的，诸如信用报告由信用报告局A提供。可选地，可命令信用局模块202从信用局A上获得个体X的信用报告，并且信用局模块202可以联系信用局服务器116，以获得信用报告。这里，信用局模块202会知道被联系的信用局服务器，即，公司A的信用局服务器，并且如果信用局服务器没有在信用报告中出现的话，能够将该信息发送到分析器模块204。

【0064】简单地说，信用局模块202接收通常来自决策引擎206的请求，以获得来自信用局A的信用报告。然后，信用局模块202从信用局服务器116上获得用于信用局A的信用报告，并且可以在接收的报告中完成一些级别的功能，诸如将报告转换成可以被分析器模块204使用的格式，或定位某些受限制的信息。一般而言，信用局以一致的方式或格式生成信息和报告，并且来自一个所的报告会遵守预定的格式。如果这种格式改变了，诸如增加了新的字段或数据，通过在信用局模块202内或分析器模块204内改变期望的参数，来容纳该信息。

【0065】当由信用局模块202实现某些功能，而由分析器模块204实现其它功能时，将信用局模块202与分析器模块204结合可以实现一定的功能性。然而，一般而言，分析器模块获得以信用报告形式接收的信息，并将该信息分析成对系统有用的信息，抛弃任何无用信息。提取的信息依情形而定，但也可以事先知道或了解，诸如保留个人的名字和姓，但抛弃当前的街道住址。信息分析的结果可以是期望格式的信息集，其可运行于系统中的其它模块之上。

【0066】系统可以基于为特定债权人或信贷机构生成的规则分析信息。例如，如果特定的债权人仅希望基于个人的信用评分，破产历史，和所有账户的当前银行存款余额提供交易，则信用局模块202和分析器模块204仅提供那些信息。这样，系统基于提供的报告并结合由债权人/信贷机构或可任选地由维持软件102的一方建立的规则，分析信息。用于个体债权人的规则可形成模式216和/或字典214的一部分，并因此通过决策引擎206或不依赖决策引擎(未示出)为分析器模块可用。

【0067】举例来说，信用局A可以以特定格式提供电子形式的信用报告。信用局模块202可接收已知来自于信用局A的信用报告。信用报告可能已经由债权人或信贷机构P查询的结果生成。因此，信用局模块202和分析器模块204可能知道来自信用局A的信用报告正为了债权人或信贷机构P的利益被分析。有了这些信息，分析器可以基于为债权人或信用机构P建立的规则，从信用报告获得仅需要的那些信息。基于为债权人或信贷机构P建立的规则，实现该规则仅需要的输入可以是破产次数和破产日期，至少两个账户上超过60天的拖欠支付，所有已知银行账户可用的钱的数额，和信用评分。基于规则需要的输入，分析器再从信用局A的报告提取需要的信息。

【0068】可选地，可以开发一致的规则集，其中检索信息可以是不依赖于债权人或信贷机构的整套信息或通用信息集。例如，分析器通常可以检索信用评分，所有银行账户可用的资金，识别信息，拖欠支付的总次数，破产次数和日期，和个人可用的总信用额度。尽管该信息可以位于信用局A，B，C等的信用报告的不同位置，但此类型的信息一般在标准的信用报告中都有，并且可以从一个所的信用报告中提取出来。

【0069】请注意，尽管在此处和整个文档中提供了特定的例子，但这些例子只是说明性的，并不对本系统和方法的功能性进行限制。其它的例子和实施方式也是可行的，本说明书不应该由所显示的例子限制。

【0070】分析器模块204的结果是被分析的一套信息，该信息是从用于特定实体的特定信用报告中分析的，结果可能仅包括与特定债权人或信贷机构有关的那些信息。

【0071】换言之，分析器模块204可以分析来自信用报告的信息，以由决策引擎206处理和做出决策。更具体地说，分析器模块204可以提取并计算用户或债权人/信贷机构定义的信用报告项目和往来账户数据，然后将计算的所和账户数据提交到决策引擎206，以用于做出决策的处理。

【0072】决策引擎206基于从个人信用报告接收的信息，可以为债务人估算、计算并生成多个结算提议，接收的信息包括诸如，债务人还债的能力，债务人银行和信用卡的账户历史。例如，可以通过使用决策引擎206访问账户/交易数据库118，确定账户历史。账户/交易数据库118可以包含关于特定债务人的信息，这些信息可以不通过图1所示的那些模块获得，或从提供的诸如信用局服务器116，支付合伙人服务器114的模块获得，或通过债务人设备106从债务人处获得。信息可以包括但不一定局限于先前从信用局或其它诸如支付历史，信用评分，破产情况，拖欠支付等以及识别信息中得到的关于特定债务人的信息。此后，在输出口某些信息是不可用的，存储在债务账户数据库中的有关债务人的任何信息可用于适当的地方。而且，如果债务人登录到该系统，选择或拒绝选择呈现的特定选项，则该信息会被债务人保存在适当的地方，至少保存债务人访问次数和访问URL。债务人界面222也可能会通过访问账户/交易数据库118，协助将此历史数据提供给决策引擎206。

【0073】债务人界面222有两种功能：向债务人直接提供界面，诸如通过在线会话过程，并可能在适当的地方访问债务人账户数据库。通过以某些方式通知债务人，一般的会话将被提示，诸如预先录制电话信息，信件，或诸如电子邮件或文本消息等的电子联系方式。然后，债务人可以访问已经建立的网站，该网站一般由服务器102的所有者/操作员控制和/或操作。用户可以使用标准，一般是安全的互联网协议登录到站点上，诸如由用户/债务人登录到网站，基本上通过债务人界面222将债务人和系统100联接。一连串的身份验证问题可以呈现给债务人，确定用户身份包括，但不局限于提供社会保障号，回答全部仅由正确用户/债务人可能知道的问题，诸如“你的生日是什么时候”，“你在哪个支行开设美国银行账户”以及“1994年你破产时，代理你的律师的姓是什么？”用户需要回答一连串的问题，以确定身份。此外，当初次联系时，诸如当债务人接收信件，电子邮件，文本信息，或电话信息时，会向用户/债务人提供一个代码，并且除了回答其它相关身份验证问题外，可以询问用户/债务人来提供该代码。一旦债务人界面222将用户识别为满意等级，这里的满意是视信贷机构或控制或维持服务器102的实体的情形和期望来确定的。在极端情况下，可能还需要再安全一些。还可以使用其它的身份验证方法，包括但不局限于声音识别硬件和软件，指纹识别等，以减少错误身份验证的可能性。

【0074】一旦用户已经被核对或验证，则债务人已经登录到系统的事实会被注意，并可能被保存在诸如账户/交易数据库118中。用户/债务人可以确定他或她正在询问的债务，这一般是通过从包含一个或多个要结算的债务的菜单中选择的。这里，会发生两种情况中的一种。如果信用报告可用，并且已经被分析器模块204分析，则决策引擎会将债务识别为与债务人相关，并且获得适用的债权人规则和决策标准，并计算一系列提议以呈现给用户/债务人，诸如将一系列选则在屏幕上呈现给债务人。如果信用报告还没有被接收到并没被分析，则用户可能被告知等待一段合理的时间，诸如几分钟。否则，如果信用报告还没有被获得，并在合理的时间段内没有被分析，则用户可能被告知在一指定时间段后或以后再返回。例如，消息可能被传送给债务人/用户：正在准备至少一个结算提议，并且债务人/用户应该在美国东部时区下午4点之后重新登录。可以把会话代码或密码提供给用户，以使她不需要再次经历身份验证过程的询问。

【0075】一旦对用户/债务人进行了身份验证，或用户/债务人已经通过债务人界面再次连接到系统，如果决策引擎206具有可用的分析过的信用报告信息，则决策引擎206可以获得模式，规则，适合于债权人/信贷机构的字典，或其它寻求解决债务交易的实体。决策引擎206依靠字典214和模式216将一系列选项或决策呈现给用户/债务人。在此背景下，模式是适用于情形的结构化的规则框架。举例来说，模式可以与债权人/信贷机构X相关联，并且可以包括诸如下面所述的规则：

【0076】“在任何一次，仅向任何债务人提供最多三个选项”。

【0077】“如果在过去的十年中，用户/债务人已经破产超过一次，则可用的唯一的提议是支付100％到90％之间的债务”。

【0078】“产生的提议仅在初次登录时可用，如果债务人/用户退出登录或由于任何原因失去联系，则对随后登录产生的可用的提议将是支付100％到90％之间的债务”。

【0079】“如果债务人/用户具有超过650的信用评分，则初次会给债务人/用户提供三种选项，包括(1)立即结算100％未偿债务的提议，(2)12个月内，以8％的年利息每月分期付款筹措100％的债务资金的提议，和(3)24个月内，以10％的年利息每月分期付款筹措100％的债务资金的提议”。债务人/用户被呈现给一份声明，同意基于以下选项处理债务：(1)实质上不会影响他/她的信用评分，但选项(2)和(3)会引起给所有适当的信用局报告延迟付款的报告。如果债务人没有接受选项(1)，(2)和(3)中的任何一项，则给用户/债务人提供第二组选项，该第二组选项包括一个选项：立即结算90％的债务，并带有必须立即结算但会对所有适当的信用局报告为“不足(deficient)”的声明。

【0080】“如果债务人/用户具有超过675的信用评分，并且在所有账户中此债务与可用现金的比率小于5％，所有账户中所有其它未偿债务与可用现金的比率小于25％，则向债务人用户提供四种提议：(1)结算90％的未偿债务的提议，不用向信用局报告；(2)以每年10％的利率支付12次结算85％的债务的提议，向信用局报告拖欠报告；(3)以每年12.5％的利率支付24次结算80％的债务的提议，向信用局报告拖欠报告；和(4)立即偿还50％的债务的提议，且剩下的50％在12个月内以年利率5％偿还，不向信用局报告。

【0081】从上文所述可以理解到，可以产生这些规则和模式以实际上包括任意一套规则和条件，并且这些规划和模式可以非常复杂。模式模块216中的那组规则和模式可以由债权人/信贷机构提供，或者由控制服务器102的实体提供，或由其两者一起提供。例如，债权人B期望有一套模式在特定的条件下应用，这包括以每年一定百分比的利率利用筹措资金条款(financing term)。维持服务器的实体可以自动增加要分配给该维持服务器的实体的0.25％百分比。可选地，维持服务器的实体可以规定：由于特定权限下的某些规定，任何情况下，特定权限中的债务人都不会被提供包括超过25％的筹措资金百分率的结算提议。某些债权人可以仅为结算提议提供一般的指导原则，并且维持服务器102的实体可以实施这些指导原则，并建立规则和模式。

【0082】例如，债权人可以仅表明给每个债务人/用户确切提供三个提议的愿望，包括100％未偿债务的提议，两个基于债务人/用户的信用评分，以低利率高信用评分的资金提议。维持服务器102的实体获得此信息，并建立实施债权人期望的规则和模式，并可以实施基于债务人/用户信用评分的利率方案，对具有最大利息率需求的权限进行特定限制。例如，如果债务人/用户的信用评分低于500，两个提议的筹措资金或还款利率可能都是25％，不过条款或条件不同；如果信用评分大于500但小于650，则提供以12个月10％的利率和24个月12％的利率的还款提议；如果信用评分大于650但小于750，则提供以12个月6％的利率和24个月8％的利率的还款提议；并且如果超过750，则提供以12个月或24个月的5％的利率的还款提议。

【0083】如果需要，可以向信用局提供报告，并且利率和条件可以周期性地改变，因此需要使用的模式或数据改变，以应用这些规则。例如，如果模式包含使用优惠放款利率的规则以确定资金项，则优惠贷款利率可以实施在此系统中，诸如字典214，并且优惠贷款利率可以周期性地改变最低贷款利率，或者决策引擎可以通过设备的某些类型的界面获得恒定不变的优惠贷款利率，该设备提供周期更新的优惠贷款利率。

【0084】决策引擎206因此典型地是基于规则的引擎，其使用以前定义的规则，例如，通过服务器102的管理员或与服务器102具有商业或其它关系的另一个实体定义的。因此，引擎206使用的规则也可以包括由债权人决策标准212中的债权人定义的信息，并且决策引擎206可以是相互作用的，意思是决策引擎206之外的个人通过债务人界面222可以提供可用于呈现提议的信息。

【0085】因此，决策引擎的全部功能性通过债务人界面222与债务人交互，并且一旦债务人被验证身份，则可以获得经过分析的用户信用信息，及从账户/交易数据库118中获得关于债务人的任何信息。基于拥有的特定债务，决策引擎使用字典214，模式216，和债权人决策标准212为债务人准备一套提议，该组提议包括至少一个提议。然后，这些提议通过债务人界面222被传送给用户，债务人可以选择一个用于交易解决。

【0086】因此，决策引擎206产生那组提议的规则可以包括，如，很多各种各样的数学，逻辑，或其它使用与债务人相关的数据作为运算对象的功能。数据可能包括由债权人提供的债务人信息，诸如，债务规模，债务产生的日期，和最后一次支付的日期。为这些功能和其它规则所用的其它信息可以包括从债务人的信用报告获得的数据，诸如，债务人的当前信用评分。

【0087】字典214一般表示在信用报告，模式和债权人决策标准之内使用的术语翻译机。如，一个信用报告可以使用术语“姓”，而另一个信用报告可以称该字段为“姓氏”，实质上表示相同的事物。字典能将来自信用报告或债权人模式内接收的术语转换成可以被决策引擎206识别的术语。另一个例子就是包含字段“上一次拖欠支付”的信用报告，被决策引擎用作“上一次拖欠日期”，并作为“上一次未交支付，”“最近一次未履行的债务，”等包含在其它的信用报告中。除了将一套术语转换成另一套，转换和其它翻译参数可以被包括在字典214中，诸如当利率是用月利率提供时，可以转换成年利率。翻译和字典词条可以被提供以在信用报告，模式内的规则和由决策引擎206采用的内部变量之间转换。一般而言，决策引擎可以从债权人决策标准212和/或模式216中获得规则和模式，从分析模块204和信用局模块202中获得信用报告，并将它们转换成由决策引擎206可用的格式。

【0088】模式216可被用来输入源数据，例如，从债权人服务器104提供给服务器102。例如，可以使用模式编辑器编辑模式，这为本领域技术人员所熟知，其可以运行在服务器102上，并使用系统100可由债权人访问。这种编辑器可以可选地与系统分立运行，并且可以给系统100提供经编辑的模式。源数据，即用于模式的源数据，诸如规则，标准和其它信息一般起源于计算机系统或由债权人维持的服务器，诸如债权人服务器104。源数据通常具有特别不相同的数据结构，该数据结构取决于债权人系统提供的数据，因此在被存储为模式之前，服务器接收的数据可被转换。

【0089】使用客户指定的模式，可以产生字典或增强它，其中字典被用来将信息从一种形式转化或翻译成另一种形式。模式可以被分析，并且取决于模式中采用的术语，专有名词，格式和各个方面，在字典中可以提供特定的翻译或转换。这种分析一般是离线人为进行的，但在一些有限的情况下，可以自动进行。通过模式216处理源数据，以建立一个或多个不同的规则字典(如，一个或多个字典214)。ETL(扩展，传送，并加载)处理可以作为此输入的一部分在这些源数据文件上进行。可以选择一个或多个源数据文件以由特定的模式处理。源数据文件(可以是多个文件)和模式的选择可以产生不同的字典214，其中每个字典具有不同的规则和字段类型。

【0090】字典214可以包括各个定义(如上文提到的)，这些定义包括，例如提供变量和指导原则，其中指导原则可以作为字典214，模式216，或债权人决策标准212或服务器102上的其它合适的位置的一部分。指导原则可以被定义为债务人的档案必须满足的要求，以产生特定的提议或特定的一套提议。提议变量可以是例如基于预定的数学功能用来产生提议的功能。例如，一特定的提议可能要求债务人居住在一特定的州，并且提议可以基于数学方程产生，例如数学方程可以使用债务的大小和上一次支付后的天数。提议变量可以包括对基本默认值的调整，其中这种调整是由规则控制的。例如，当提议变量设定一个值，(如，“到期(天数)＝25”)，如果对应于债务人的数据满足所定义的条件，则诸如“如果应计的利息＞＝1000，则值(到期(天数)＝37)”的规则可以用于对初始值25进行调整。这些规则可以放在字典214内，但更一般地作为债权人决策标准212或模式216的一部分被包含，并且可以位于服务器102内的其它位置。

【0091】图8图解显示了使用模式216将源数据映射到字典214的一般概念的一个实施例。每个模式216被定义为与不同的源产生的数据相符，诸如金融机构或其它债权人或信贷机构。模式输入源数据并将源数据转换成一个或多个选择的字典214。可以使用模式图产生映射。源数据的字段一般不同于字典214中期望的最后字段。例如，源数据可以包括诸如4位“优惠放款利率”的字段，而服务器102使用5位称作“优惠利率”的字段运行。该模式可以将优惠放款利率映射成优惠利率，并将一个0加到提供的值中。

【0092】源数据可以映射到超过一个字典，两个或多个源数据文件可以被映射成公用字典。使用模式图中的公式，某些条特定的源数据可以是计算值或导出值，其能放置到一个或多个字典214中的许多不同的字段中。

【0093】服务器可以可选地创建第二字典作为单独的字典，或作为第一字典的副本，其中第二字典可以被编辑以具有不同于第一字典的规则。此外，上文讨论的映射过程可被用来从字典中输出数据，例如通过创建一种模式以将字典数据转换成输出数据文件。

【0094】结算提议因债务人不同而变化。如，结算提议可以将不同结构的财务条款提供给债务人。提议可以包括打折的一次付清立即支付，和以规定的利息率筹措资金的月支付数额。

【0095】债权人决策标准212表示可以在产生结算提议时由决策引擎206使用的信息(如，存储在可以被服务器102访问的内存中)。标准212可以是先前由一个或多个债权人提供的信息，每个债权人使用自己的债权人服务器104独立访问服务器102。标准212可以存储为生成提议时，决策引擎206遵循的一套规则。

【0096】由决策引擎206使用的各种规则也可以通过对规则和获得的相应追款结果进行分析来优化。可以为了某一特定的债权人，某一批债务人，或为其它特定的情况，来优化规则。

【0097】举例来说，如果债权人/信贷机构或控制或操作服务器102的实体希望优化，优化过程可以考虑到回收率。如果一组债务的回收率接近100％，则给剩余债务人产生的提议可以以某些方式改变，诸如减少筹措资金利率，或提供90％的结算提议，而不是100％的结算提议。相反地，如果回收率接近0％，或在期望值以下，则可以提供较高的筹措资金利率或无能力提供资金，或提供仅100％的结算提议，而不是90％的结算提议。也可以提供对规则的其它优化。

【0098】回收管理器208是本设计任选的一方面，其中债权人可以具有特定的可以被追款员或主管人审查并同意的债务人提议，例如由债权人指定的提议。作为前面所述交易解决程序的一部分，债权人可以登录到服务器102上，以查看诸如由债务人呈现的一列可选的提议。债权人可以同意，不同意，或以其它方式发起对一具体债务人的行动。

【0099】应该认识到尽管图2所示的软件的逻辑表示图说明了各个块，模块和部件，但各部件之间的划分线并不严格和快速，而且可以由各种部件实现特定的功能性，包括单一部件或部件组合，而且本说明书描述的功能性也不是一套严格和快速的要求。例如，决策引擎206可以仅将这些规则和模式应用到来自分析器模块204的经分析的信用报告，回收管理器208可以产生并通过债务人界面222将提议呈现给用户/债务人。

【0100】支付处理器210，也是任选部件，可以执行追款或回收程序的一些或全部的支付处理和会计功能。如前面指出的，用户/债务人可以选择结算提议，其包括在一段时期内提供资金的支付条件，或其它类型的结构化的结算。支付处理器210可以使用户/债务人采用多种支付形式，这可以提高债务人还债的能力。如，支付处理器210可以分期或周期地使一定数额充值到信用卡，ATM卡或银行账户上。支付处理器210还可以管理支付的分配和/或任何一方(例如，与债务人的原始债务交易和/或由服务器102处理的结算交易有关的任何一方)的信用。支付分配可以基于诸如存储在服务器102上的资产组合分配规则，并可以由支付处理器210访问。例如，对由信用卡支付的一个组中的任何债务，如果信用卡发行者接收交易的4％，剩余的96％给操作服务器102的实体分2％，给债权人/信贷机构分98％，则支付处理器分别给信用卡发行者，操作服务器102的实体，和债权人/信贷机构分配4％，1.92％和94.08％。这样，支付处理器210的功能性就是将以任何形式接收的支付分开，并对按照一套预定的规则接收的支付进行分配。为了完成该功能性，支付处理器210可以与支付合伙人服务器114交互，其中支付合伙人服务器表示诸如在银行、信用卡发行者、或其它实体中操作的服务器，并可以用来处理由债务人/用户选择的交易，以及按照一套建立的规则立即将完成的支付在合适的几个交易方中划分。规则可以位于模式216中，或位于系统的其它合适的一方，包括但不局限于回收管理器208或支付处理器210。

【0101】本系统具有在服务器102内结合并通过软件112，在支付合伙人，债权人，信贷机构等内以称作OrgUnit的单元形式，或组织内的单元形式建立分支的能力。诸如信贷机构的组织，可以分成多个部门或单元，诸如收款，资金，会计等，甚至可以在那些部门或单元内分成子单元。本发明的系统能建立那些OrgUnit，并使规则可以由单个OrgUnit使用，或一起用于所有的OrgUnit。支付可以进行或分配到组织中的单个OrgUnit内。

【0102】资产组合分配规则一般是总分类帐(G/L)账户分配规则。每个OrgUnit可以具有2个或多个账户表(一般是基于现金的信托表和基于利息(accrual-basis)的业务表)。当OrgUnit通过支付处理器210接收在线支付时，为每个账户表定义的分配规则一般说明了支付是如何并以何种顺序应用到费用和本息余额。此外，相同的分配规则也可以说明“分开(split)”交易，例如借方应收款和利息业务表中的贷款收入(crediting revenue)。账户分配定义了所有流入和流出系统100的金钱。而且，在资产组合管理器220内，会计学规则可以绑定到资产组合周转事件(Portfolio Lifecycle Events)，诸如全部支付，或保证支付，因此，将特定债务池或债务同盟(pool of debts)绑定到系统100内管理该债务的特定合同安排。因此，资产组合管理器220可以接收与解决的交易相关的信息，一旦支付已经由支付处理器210处理，说明那些给每个组织单元(OrgUnit)的每美元的分配量收到并被支付了。也可以采用特定的会计学规则，以适当地在OrgUnit之间分配分配量。

【0103】报告引擎218收集关于债务、债务人的行动、产生的提议、接受的提议、完成的支付、以后要完成的支付的信息，和其它在系统内计算并由系统提供的相关信息，而且报告引擎能以期望的报告形式编制信息，诸如以电子数据表或其它文档形式编制信息。例如，债权人/信贷机构能应要求或周期性地接收结算的一债务池的数额的报告，结算条件包括接收到的支付，它们被接收的形式，特定日期要接收的未来支付。结果是由报告引擎218生成一般可配置的报告集，该报告集是为债权人，信贷机构，控制服务器102的那个实体或几个实体，及任何由系统100解决的交易中其它具有利息的适当实体的利益生成的。

【0104】因此，报告引擎218可以给一些或所有经过身份验证的各交易方生成并任选地发送周期性报告(如，每日，每周或每月)。例如，报告引擎218可以与支付处理器210通信，以获得债务状况信息，并且再如可与回收管理器208通信以访问债权人预定义的管理信息报告的规则。

【0105】资产组合管理器220可以向其它实体提供债务余额管理，债务资产组合的转移和/或销售。此情况下的债务余额管理还是由规则指导的，诸如通过特定的OrgUnit向政府实体支付税金，由OrgUnit向其它实体支付或向预先安排数量的OrgUnit支付，诸如租金，费用，应付款，或其它实体内的交易，以及通过在系统100上维护的规则规定的其它相关支付。

【0106】因此，资产组合管理器220的功能可以以包括来自债权人决策标准212的信息的规则为基础。再举一个例子，资产组合管理器220可以基于预定的一套标准(如，由债权人建立的)，将债务分组为用于销售的子资产组合。在这种方式下，如果资产组合符合预定标准，则它们可以在实体或OrgUnit之间销售或转换。这种安排可以包括提供规则的信贷机构A，如果在整个资产组合中到期金额在一百万美元和五百万美元之间，且所有借款人的平均信用评分超过625，而且没有超过120天的拖欠债务，则信贷机构A提供的此规则将很乐于从债权人(不是另一个信贷机构)接纳债务资产组合。信贷机构A可以指定一种规则，能通过为所欠的每美元债务支付债权人20美分来购买这种债务资产组合。因此，使用资产组合管理器220，这些规则可用来管理资产组合。

【0107】一般的流程示于图3A中，一种可选的处理流程示于图3B中。从图3A中可见，点301表明债权人或信贷机构可以用服务器102同步所有债务和债务人信息的往来账户数据。点302表明债权人或信贷机构可以基于已经建立的规则和对这种交易的认可，在实体之间或在OrgUnit之间管理，分割，分配，并转移债务资产组合。

【0108】债权人可以向债务人提供刺激以结算债务。例如使用印刷邮寄，电话或电子邮件，可以向债务人提供这种刺激。如指出的，债务人为债权人或其受让人或代理机构所知，而且债权人/受让人/代理机构一般有债务人的某些形式的联系信息。尽管人们可能再次更改了或提供了不正确的联系信息，但点303表明债权人/受让人/代理机构试图以建议的方式联系债务人。一般可以向债务人提供网站或代码，某些债务人可能会对这种引诱做出反应。可选地，债务人可以联系债权人/受让人/代理机构，表明有意解决债务，这时，可以向债务人提供联系或登录到服务器102上的信息。因此，可以采用各种与债务人建立联系的方式，最终结果是给债务人提供用于联系服务器102的联系信息。

【0109】例如，一旦债务人登录到服务器102为主机的网站，并对他或她自己进行了身份验证，则软件112可以请求债务人的信用报告，债务人是使用信用局模块202在点304上确定的。因为信用报告一般仅从授权实体获得特定的许可，当被来自信用局服务器116的信用局模块202请求时，信用报告请求可以被信用局认为是与债务人的债权人(或与债权人的欠款托收机构)有关的请求。在这种方式下，可以获得信用报告，并且来自信用报告的数据可以被分析模块204分析，并被决策引擎206使用，如上面对点305的描述。

【0110】在点306上，结算提议可以在例如网页上提供给债务人。决策引擎206可以如上所述，根据来自信用报告的经分析的信息和由债权人或信贷机构建立的规则来计算提议。给债务人的一套提议的例子示于图6。每个提议都有对应的到期日，债务人使用的图标或按钮，以能够选择接受特定的提议。

【0111】在点307上，服务器102产生的网页上也可以呈现诸如图标或按钮，由债务人点击来表明使用服务器102与债权人协商其它条件的愿望。这种协商的条款可以由债权人或信贷机构和/或控制服务器的实体指定。例如，债权人可能不希望有提供协商的能力。信贷机构A可以向用户/债务人提供一次协商尝试，而信贷机构B提供了三次协商机会。

【0112】协商使用户能根据他或她的期望设置条件，并因此使债务人可使用各种合适的字段，诸如以具有数据输入字段的HTML网页的形式，至于数据指诸如用户/债务人现在愿意支付的数额，用户/债务人愿意在接下来的12个月，24个月每月支付的数额等，期望的利息率，期望偿还的期限等。提供的期限应该是一致的。举例来说，用户可能乐于在数月内支付一定的数额，并且可能希望做出完成该目标的安排。如果最初产生的两个提议是12个月内每月支付500美元，24个月内每月支付275美元，则债务人可能认为这些提议很困难或不可行，但可能乐于在数月内每月支付150美元。然后，用户可以输入他乐于支付的数额，并请求或指定支付的期限。可选地，如果一个最初的提议是结算立即支付的未付余额的20％的债务，并在3年中以8％的年利率偿还剩余80％的资金，则该信息可以被输入。

【0113】来自系统100，具体是服务器102的响应取决于建立的用于协商的规则。如果这些规则被建立以接受现在支付20％，在三年中以每年8％的年利率支付80％的提议，则服务器指示交易已被解决，并且交易向前进行到请求信息，诸如通过信用卡或银行账户获得20％。在大多数情况下，用户/债务人不允许返回到最初的那个提议或那几个提议，而且一旦用户/债务人请求进一步协商，则会失去呈现的连续的机会。

【0114】如果规则被建立以运行在由用户/债务人呈现的协商提议上，则决策引擎会借助图2中的各模块评估协商提议，以确定响应。例如，如果接受了现在支付20％，三年内以8％利率支付80％，则决策引擎206会获得规则和/或模式，该规则或模式表示债权人已经指定了“第一轮协商”，立即支付低于50％的提议是不可接受的。但如果接受了立即支付小于50％的提议，则决策引擎和其它模块将提供50％的立即支付，另50％在12或24个月期限内以10％的利率偿还。这些还价是针对用户进行的。

【0115】用户/债务人可以选择一种选项，并解决该交易或可选地，服务器102可以表明基于提供的规则，由用户/债务人提出的提议对债权人/信贷机构是可接受的。在这点上，如点308所示，用户/债务人可以使用选择的支付形式进行支付，还可以对任何意见一致的支付，和以后支付的支付形式制定计划。

【0116】可以理解到，在某个点上，解决方案是不可行的；用户/债务人和债权人/信贷机构规则可能不能解决交易。在那点上，呈现给用户/债务人一份指示，说明还没有达成任何解决方案，用户/债务人可以通过电话联系信贷机构以进一步讨论解决方案。无论如何，此点上的交互式的在线会话包括可以被保存并用于进一步协商的数据，或基于交易能被成功解决的可能性做出决策。如果位置之间的距离太远，则信贷机构可能决定提起诉讼，而不再做进一步的讨论，而另一个机构可能乐于折中，并通过电话或通过使用具有不同规则的系统进一步协商。用于以后的提议的一套规则和模式可能是可用的，以使用户/债务人能够登录并进一步寻求解决交易的方法。

【0117】可选地，如果提供了协商，则可以以可编辑的形式向用户呈现提议，而且用户可以编辑呈现的提议以尝试解决该交易。

【0118】如果用户/债务人选择协商或提供不同的结算条款，则用户/债务人可以可选地被放置到收款员队列中，诸如聊天室或其它在线设备/工具，其中该队列可以被可以访问服务器102的债权人或信贷机构监控。可以通知用户/债务人，他的提议已经放置到队列中，并且当债权人对产生的提议的已经做出决策时，也会通知债务人(如，通过聊天，文本消息，或电子邮件)。

【0119】如果已经解决了该交易，则点309表明系统可以通过第三方信托账户合伙人处理该交易。第三方信托账户合伙人是向国外建立的实体，并代表债权人维护交易，以使操作或控制服务器102的实体不需要直接牵涉到资金处理中。某些法律可能会禁止实体维护债权人、银行等的信托中的资金，因此可以利用第三方信托账户合伙人，但这是任选的。进一步讲，如果操作或控制服务器的实体是银行或者允许的其它资金持有人，则可能不需要或不要求有合伙人。在点310，系统可以根据上述讨论的分配原则分配资金，诸如通过使用参照支付处理器210讨论的支付处理。在点311，会计分录可以被邮寄，并在点312产生报告。

【0120】图3B图解说明了用于整个系统的可选的一般流程图。点351为每个适当的债权人/信贷机构建立规则，并且是由OrgUnit建立的。点352将债务资产组合装载到系统100中。在点353，向用户通知解决未偿债务的机会。在点354，用户/债务人登录到系统100，并在点355进行身份验证，在点356选择债务。在点357，服务器102使用信用局模块202查找以获得用户的信用报告，并任选地从账户/交易数据库118中查找关于债务人的信息。取决于获得信用报告需要的时间量，服务器102可以指示用户/债务人在一特定的时间之后返回，并在此时间之前查找信用报告，分析数据，或者是服务器102可以获得信用报告，并使用分析器模块204分析该数据。一旦该数据已经被分析，并且用户/债务人也在场，则点358使决策引擎206任选地基于分析的信息获得用于所选择的债务的合适规则，并且如果任何现有的模式和字典与前面的分离，则点358还可以获得模式和字典术语以及债权人决策标准。基于模式，规则，分析的信用信息和其它来自系统100的各部分的可用合适信息，在点359，决策引擎准备包括至少一个提议的一套提议。在点360，系统将该提议呈现给用户/债务人。在点361，用户或者选择一个提议，或者如果提供协商，则可以选择协商。如果可采用协商，并选择了协商，则在点362用户/债务人能够将她的提议输入。在点363，决策一般是由决策引擎206，但也可能通过债权人/信贷机构代表或其它实体评估的，则还价或者可被接受，或者可产生进一步的提议。在该点上，系统通过以下步骤循环：基于规则产生的提议，评估协商的可用性，并且如果可用，则允许用户/债务人进行还价。如在点364所示的最终结果是解决或陷入僵局4。如果解决方案产生，则在点365，会产生支付处理，并在点366应要求产生报告。可以理解到，也可以产生本说明书讨论的其它方面，诸如基于资产组合活动，修改规则，尽管这在图3B中未示出。

【0121】图4图解说明了在Microsoft平台上实现的本设计的相互作用端的债务人的结构化表示。债务人系统400使用面向对象编程和SQL(结构化查询语言)数据库操作以完成上文描述的功能性。一般而言，对象被创建或接收，并且如果需要，可周期性地操作，以为了应用模式和规则，并向用户/债务人呈现提议，而获得数据。该结构被分解成各种用网络服务器互联的等级，网络服务器能通过互联网从外部世界进行访问。

【0122】从图4可见，网络服务器401包括ASP.NET网络应用程序402，其用来使所有适当的债务人功能性与互联网进行接口连接，诸如允许债务人联系服务器102，并为了身份验证目的与服务器进行交互等。ASP.NET网络应用程序一般为本领域技术人员所熟知。债务人界面222的许多功能是由网络服务器401实现的。对象代理服务器403被提供，以与网络服务器401，和系统中的其它等级进行数据往来，从而完成上文描述的功能性。超出网络服务器401以外的债务人系统部件包括对象等级服务器410，数据等级服务器420，和所等级服务器430。对象等级通过网络服务器401创建并接收/翻译与债务人/用户接口的对象。

【0123】对象等级410包括对象服务411和决策引擎412。对象服务411接收对象，并能询问数据等级或需要时将对象转化，以将此对象提供给决策引擎412。决策引擎206的许多功能性可以通过决策引擎412实现，包括将规则和模式组合，并将规则和模式应用到经过分析的信用报告信息，以产生向用户/债务人做出的那组提议，如果有，还能产生以后的协商。如所示，对象等级410既与数据等级420连接，又与所等级430连接，以实现必需的功能性。决策引擎412可以从数据等级420查找规则和其它的信息，对象服务411也能从数据等级420查找规则和其它的信息。数据等级420包括SQL服务器421，一般是可以访问所有规则、模式、字典和以上所注示的其它数据的SQL服务器，这些数据被存储以用来创建提议，管理债务资产组合等。对象等级410还与所等级430连接，所等级430一般包括支付服务模块431，其用来从成功的交易解决方案中建立支付结果。

【0124】支付服务模块431排队并处理支付交易，并基于支付方法(如，ACH、CC等)，还基于在信托合伙人OrgUnit和债务人/信贷机构OrgUnit之间建立的任何联系或安排将它们发送到适当的第三方支付处理器入口。债权人/信贷机构OrgUnit A可以安排以通过一个第三方支付处理器处理信用卡支付交易，而通过另一个第三方支付处理器处理ACH支付。系统可以使债权人/信贷机构动态地通过给债权人/信贷机构OrgUnit显示可用的信托合伙人OrgUnit和他们各自的信托和支付处理服务提供选择支付合伙人。债权人/信贷机构能选择信托合伙人，并应用于特定的支付服务。信托合伙人然后可以同意或拒绝该应用。支付服务应用可以由询问数据补充。诸如折扣率，交易费用，起动成本等的同意和合同变量可以根据为同意或合同建立的规则应用决策引擎206，并可能产生支付服务合同。一旦建立起了这些合同，则向用户呈现债务解决的支付方法，这取决于债权人/信贷机构OrgUnit已经建立的有效支付服务合同。

【0125】所服务器430进一步包括所网络服务模块432，当需要时，其用来从信用局获得数据，诸如信用报告，并且当合适时，可以提供债务人/用户的信用报告。所网络服务模块432与分析器服务模块433连接。所网络服务模块432实现大多数关于逻辑信贷机构模块202描述的功能性，而分析器服务模块433实现与本设计的逻辑表示中的分析器模块204相关的大多数功能性。ABS队列处理器434对信用报告的请求进行排列，并将它们分配给适当的用户/债务人。因此，在图4中示出的大多数功能性实现了图2中示出的由决策引擎206、分析器模块204、信用局模块202、债权人决策标准212、债务人界面222、字典214和模式216实现的逻辑功能。

【0126】图5图解显示了债权人系统结构500，其也包括服务器等级501，对象等级510，数据等级520，和所等级530。债权人系统结构可以与任何债权人分开维护，除了运行在交易解决程序的债权人一端，本质上维护债权人数据，并实现交易中与债权人相关的功能性。此外，采用OOP和SQL的Microsoft平台示于此实施例中。债权人端使债权人、信贷机构或其它具有债务的实体提供信息，并使能够与系统100的债务人端连接，更易于交易的解决。债权人结构500实现债权人需要的各种功能，诸如收集债权人和债务人数据，准备用于提供提议的数据，并通知交易解决和交易状态的债权人，在某些情况下，还准备需要的报告。

【0127】如同图4中的债务人结构，债权人结构包括ASP.NET网络应用程序502，和服务器等级501中的对象代理服务器503。此外，服务器等级501包括FTP部件和数据接收器。诸如银行的债权人可以维护包括数据、规则或其它有用于实现讨论的交易解决程序的其它适当的信息的FTP站点。为了维护一定级别的一致性，FTP站点文件夹504维护至少一个列表，并且在某些情况下，维护在交易解决程序中使用的数据的整个文件。这些文件夹的出现能易于获得由系统100使用的规则、模式、账户、债务等。在服务器等级501中提供债权人数据接收器505，以将接收到的数据写入债权人的FTP站点文件夹。可选地，债权人数据接收器可以将数据包通过电子邮件或安全网络服务直接传输到系统100的其它部件。FTP站点文件夹504和债权人数据接收器505能直接有利地与债权人来往联接，并从债权人代理512接收数据，并将数据传输到债权人代理512。

【0128】对象等级510包括债权人对象服务511和债权人代理512。数据对象由此等级接收并传输。债权人对象代理服务器503可以接收并传输对象以进行处理或者处理之后，用在系统结构的债务人端。债权人代理512创建并加密去往债权人的数据输出，将加密的文件传输到运行在服务器等级501上的债权人数据接收器505。此外，数据等级服务器520维护数据库，使用SQL服务器521数据交互发生在此等级520上。数据当然与债权人相关，并且使用此SQL服务器521，债权人相关数据被检索并传输。所等级服务器530包括代理人自动化服务531，其执行预定事件，诸如开始日，关闭日，月末和其它处理和账户需求。代理人自动化服务531与外部支付处理器和其它适当的设备通信，以监控激活的交易状态，批下载报告，并实现其它与债权人相关的功能。交易状态可以在SQL服务器521中被更新，产生变动记录和当前状态。所等级服务器530可以使用MSMQ(微软消息队列)通知书与对象等级服务器510通信，以准备并输出数据包。代理人自动化服务在债权人端实现的功能不如在债权人所等级服务器430上实现的功能广，并且仅自动化预定事件，以评估状态并准备与报告相关的信息。

【0129】图6图解所示了系统运行的一个可选的实施例，或决策流程，特别是包括系统100的许多逻辑软件部件。从图6看出，信用局601表示获得信用报告来源的信用局，一般表示系统100可能联系的所有信用局。运行是通过围成圆圈的数字顺序进行的，决策流程运行一般是由所服务器602指导的。第一过程就是登录并获得会话标记，以对会话进行确认，其中会话是在所服务器602上的。此信息通过所服务器602和决策引擎建造档案模块603。过程2获得提取列表，或被提供的一列数据，而点3获得报告列表，或由服务器602报告的一列数据。提取列表和报告列表一般是信贷机构专用的，并且这些决策一般是关于信用局模块202和上面的债权人决策标准212进行描述的。例如，信用局A的提取列表包括存储为规则的信息和/或包括信用评分、债务人姓、债务人名字、最近破产领域、超过两个月拖欠的支付数目、所有账户手头的总现金等的模式。报告列表可以是要报告给信用局的信息，诸如交易成功、解决的债务、支付安排等。

【0130】决策流程一般从点4开始，邮寄请求，该请求一般是来自特定信用局的信贷报告请求，这可能基于提取列表或者可能基于报告列表。在点5，所服务器602从RDBMS(有关系的数据库管理系统)604获得所登录。点6将请求插入到所服务器队列，这取决于用于现有的队列信息和与队列中的附加请求项有关的数据的RDBMS 604。一旦所服务器602具有队列信息，它就通过MSMQ或其它适当的传输机构向所服务器队列605发送请求。所服务器队列605可以以期望的顺序执行，并且最终做出的请求会产生从信用局601中获得的信用报告。一旦所服务器队列605已经获得了信用报告，点8表明该数据被传输到分析器606，以从接收的信用报告中分析相关数据。块607表示分析器执行逻辑。一旦已经开始分析，则在点9报告-通知指示被从分析器606提供给所服务器602。有了经分析的信息后，在点10所服务器602传输请求以得到决策引擎构建档案模块603的结构。决策引擎构建档案模块603基于经分析的信用局信息或信用报告，提取列表，报告列表和有关系的数据库项603建立债务人的档案。在点11，如果某些信用信息已经变成可用时，在RDBMS 604中输入附加信息，决策引擎构建档案模块603可以更新特定的债务人档案。

【0131】与决策引擎构建档案模块603结合的决策引擎确定模块608一般形成了图2中的决策引擎206。基于出现的情况，决策引擎确定模块608可以产生由债权人/借贷机构同意的一套标准或提议细节。决策模块609实际上接收此信息，并将接收到的信息提供/转化成特定提议，并以决策结果的形式提供决策，一般以MSMQ但也可能以其它的消息格式。

【0132】尽管图6所示为两个单独的模块(决策引擎确定模块608和决策模块609)，但参考图2，决策引擎206包含确定功能。因此，图6所示的两个模块608和609可以合并成一个单独的决策模块。注意图6图解说明了决策引擎206内的各种子功能，包括构建档案(BuildProfile)，其与实时外部数据源模块和前面提到的决定模块通信，其将规则应用于编制的档案，结果生成提议。

【0133】来自决策模块609的MSMQ决策结果消息被提供以填写请求提议模块610，其中填写请求提议模块610是提议数据库，其保存以前提出的提议，并将一套提议排队以传输到用户/债务人。用户/债务人通过消费者ASPX信用评分页面装载模块611接收该组提议，页面装载模块611载有传输给用户/债务人的页面。在消费者ASPX页面装载模块611，系统接收任何响应，它可以将MSMQ中接收到的响应或其它适当的消息格式传输到填写请求提议模块610。在该点上，当用户/债务人已经对该页面上提供的提议或一套提议或其它选择做出动作，则接收到的决策可以从填写请求提议模块610传输到决策模块609，以及到决策引擎确定模块608。结果是根据建立的规则做出适当行动(进行协商，考虑解决的交易，中止的协商/会话，等)，包括进一步将同意的该组提议进行传输的可能性。注意RDBMS 604可以通过来自填写请求命令模块610的处理结果更新，即同意和交易解决结果，协商/会话中止结果等。

【0134】图7图解显示了如使用支付合伙人服务器114实现的支付合伙人交易流程700。第三方支付合伙人向债权人/委托人提供了诸如ACH(自动化票据交换所)处理，资金清算和支付服务。第三方支付合伙人代表委托人，诸如银行，授信主体和欠款托收机构接收资金，并代表委托人保存和/或清算资金。例如，系统100通过互联网提交所有电子形式的交易，可以将资金存放到第三方支付合伙人的信托账户。委托人-债权人能使用该系统，通过指定规则和模式与第三方支付合伙人连接，根据规则和模式，第三方支付合伙人的期限，条件和费用是处理资金。例如，如果在传输到账户J之前，资金会保存3天，或保存直到从债权人处接收到了同意信息，则第三方支付合伙人根据提供的规则保存并作用于资金。再一次，维持服务器102的实体可以实施这些规则，该实体与债权人、信贷机构或诸如一些政府规定、，高利贷需求、和其它适当数据的支付合伙人分离。

【0135】第三方支付合伙人一般能够处理借记卡，现金信用卡(MasterMoney card)，ACH，EFT，并且能代表受委托人和/或其顾客指示的委托人-债权人发起交易，能代表委托人在一段固定的时间内，诸如30天保存从客户的顾客接受的资金，还能根据客户的电子指令，基于保存在系统中并由委托人或代表委托人建立的电子分配规则将资金分配给委托人账户。

【0136】贯穿图7，用户/债务人使用他或她的用户界面设备106，以在点1提供诸如以EFT或信用卡信息形式的支付。服务器102接收此支付输入并将交易向前发送到点2的支付合伙人服务器114。在点3，支付合伙人服务器发出来自适当的债务载体，诸如常用或活期账户(checking account)，储蓄账户(save account)，信用卡发行者等，或账户701的请求进行身份验证的身份验证请求。点4是身份验证响应，要么确认该次交易，要么否认该次交易。如果否认该次交易，则支付合伙人服务器可以将此信息传输到服务器102，其可根据预定的规则在支付被拒绝的情况下做出行动，诸如通过将提议改变为仅可以随时间进行的支付，拒绝产生任何下一步的提议，并中止会话，或其它期望的动作。不管是否同意该交易，点5表明交易结果通过服务器102被提供给用户/债务人。如果同意该交易，则在点6，请求支付合伙人服务器114将结算请求提供给废弃账户(bin account)提供者或商人账户提供者，并且由提供者702指示进行存钱。在点8，有关任何一方的任何费用被分配，其中有关的一方703是与解决的交易有关的一方，包括但不局限于维持服务器102的实体。点9表明由服务器102可请求进行某些支出，以在周期性基础上，诸如每星期或每月，支付合伙人114。点10表明根据建立的规则，钱被存入到委托人账户704或债权人账户705。

【0137】提议并不局限于简单的财务条款。以上讨论的每个提议或每组提议也可以包括非财务条款，诸如免费产品或服务的提议，或如某些其它类型的便利或权利。非财务提议的提供是由一个或多个由决策引擎206考虑的规则控制的。例如，如果提供免费产品以解决未偿债务的95％的交易，则可以送给拥有1000美元的用户/债务人包括下面这样一个提议的一套提议：即以950美元加上免费形式的信用报告解决该交易，并且此数据可以呈现给用户/债务人以便选择。

【0138】作为以上呈现的可用于系统100的一种选择，用户/债务人与服务器102的交互可以基本实时地同时在线地用服务器102大大提高他的信用评分。例如，用户/债务人可以使用系统100进行债务支付。如图7所示，该支付被接收并被作用，因此，服务器102具有目前可用并传送的批准的资金。从图1可知，服务器102可以向债权人服务器104和/或信用局服务器116报告支付的清偿情况。一旦接收到了已经清偿一项债务的报告，则信用局服务器116会考虑那个债务的支付情况，并基于用户/债务人的当前评分重新计算信用评分。信用评分的计算考虑了各种因素，不同的信用局可以用相同的数据计算不同的信用评分，但一般来说，未偿债务的清偿是可能增加用户/债务人的信用评分的正面因素。如果能够计算并且已经计算信用评分，则信用局服务器可以将更新的信用评分传送回服务器102，以通过债务人设备106传送并显示给用户。可选地，服务器102一般可以知道债务的支付是如何影响信用评分，而且服务器102可以基于满意的债务数额和满意条件(立即支付，长期支付等)计算用户/债务人的临时或暂时信用评分。例如，如果基于具有几个拖欠债务，五年以前有过一次破产经历的整个信用历史，则债务人的信用评分是612，未偿2000美元债务的清偿可能会提高信用评分。例如，如果债务人总的未偿债务在20,000到30,000美元之间，信用评分在610到620之间，支付未偿债务一般会将信用评分提高四个点，服务器102或信用局服务器116可以指示用户的信用评分可能或者将提高至616。

【0139】图9图解说明了根据如图1和图2公开的实施例的一般债权人/信贷机构的工作流程。点901用服务器102建立债权人/信贷机构账户，并建立用于债权人的一整套总体默认值。点902配置用于债权人/信贷机构的结算条款，诸如口头地将结算条款提供给能将结算条件翻译成服务器的适当条款的实体，适当条款诸如APX，手稿，或其它适当的结算条款。点903上载债务资产组合，一般通过通信媒介108从债权人服务器104上载到服务器102。资产组合包括所有的债务，并包括识别与这些债务相关的信息，可能还包括但不局限于债务人姓名，账户号，债务数额，发生日期等。在点904，债务人地址可以被从债权人服务器104上载到服务器102。在点905，可以提供任选的资产组合等级，以使用建立的等级系统评定该资产组合。例如，可以用字母等级(A，B，C，D等)对资产组合进行评估，其中，通过一些主观测量，A是最佳的资产组合。也可以采用编号等级(例如，1是高风险，2是中风险，3是低风险)或其它等级。在产生提议集时，这些等级可用在某些以后的规则中。例如，高风险资产组合可被批准为每年12％的最小筹措资金利率，而最低风险资产组合可批准为8％的最小筹措资金利率。这些等级也可以按期望进行变化。点906表明与债务人进行通信，诸如通过邮件、电子邮件、文本消息、记录的电话消息，或其它方式进行通信，因此发起与债务人的联系，并且使用当前的系统100开始进行交易解决。注意，债务人的地址可以周期性地进行更新，资产组合可以再评定，而且可通过债权人/信贷机构，维持服务器102的实体或其它适当的和/或授权的实体发送信件。

【0140】图10图解显示了一般的债务人工作流程。在点1001，债务人接收信件或其它提供服务器的网站的通信，可能确定特定的债务人或债权人，也可能提供已知的关键词或密码或代码，使能用在服务器102的网站上。在点1002，债务人可以使用他的关键字，密码，或适当的代码登录到网站上。在某些情况和权限下，个人或实体可能需要同意诸如债权人，信贷机构，或维持服务器102的实体获得他的信用报告。在这种情况下，用户可以同意信用报告，即指示获得实体被授权，以获得代表他自己的信用报告，这作为一种选择显示在点1003。当用户不允许别人获得自己的信用报告时，或没有可用的信用报告时，可以建立规则，其中例如，没有产生提议或可选地仅有有限的提议(诸如未偿债务的100％)可以出现。这些规则是通过债权人/信贷机构或控制服务器102的实体建立的。一段时间以后，此时间的长短视情况而定，在点1004，用户/债务人可能接受并查看提议。在点1005，用户/债务人可以选择最佳提议，并在点1006还债。对用户来说，可用的选择就是通过购买它或其它可用的选择查看他的/她的信用报告，并且在点1007，在某些情况下，如果提供的话，可以查看她的或她的信用评分。

【0141】为了提供当实体访问系统时可能遇到/使用的屏幕类型的一般感觉，屏幕照片的一般集合示于图11-22。这些屏幕照片代表了本设计的一般说明，但也可显示可选的图，信息或布局，因此本说明书显示的屏幕照片并不旨在进行限制。

【0142】图11显示了一种具有针对信用局的结算项目的互联网浏览器。一般来说，所映射功能在该屏幕上显示，即，信用局模块202是如何从信用局116获得信用报告的。所映射屏幕1101表明所的名字，报告类型，提取列表，并在所项目的右侧提供了列表，该所项目是从检索到的报告中提取出来的(负的贸易数目，贸易数，高信用等)。此屏幕上的操作员能从屏幕左侧可用的字段中选择，选择他或她希望从信用局模块中包括的字段，并可能使用信用局模块202和分析器模块204进行分析。而且，模式表示了共享的词汇，并允许机器执行这些规则。用于债权人的模式可以包括从信用报告中提取期望的信息的规则。

【0143】图12显示了用于特定债权人或信贷机构的一整套结算条款。屏幕1201包括实体名字(债权人/信贷机构)，还包括不同等级的规则，诸如87％的结算和90％的结算。提议变量包括两种情况下30天或25天到期期限，指导原则包括各规则，其中，如果债权人当前的债务余额大于或等于500.00美元，则30天内偿还数额为97％。如果应记利息大于或等于1000.00美元。如果注销数额(charge off amount)大于或等于5000.00美元，则提供的值为80％。提议和指导原则1202可被修改，条款可增加，移除，或改动，这取决于债权人/信贷机构或其它实体的期望。可以提供有效的日期和到期日期。注意给字典增加条款的一种选择被提供在屏幕1201上。

【0144】图13图解显示了结算字典1301，在本实施例中，它包括选择1302，以创建并编辑债务结算项目和转让标签，诸如XML标签以与源数据匹配。在此图中的各种债务结算项目，在特定的债权人和字典“债务”的情况下，包括输入账户状态(entry Account Status)，应记利息，年龄等，表示字典术语的每一项可以与信用报告记录或其它数据库记录匹配。点1302包括项目或标签，例如以XML格式、它的类型，点1303说明项目“年龄”可以使用公式，诸如“当前日期”减去“债务日期”来创建。

【0145】图14表示报告的一般格式，特别是用于报告债务资产组合的收款统计格式。在此图中，在点1401，可提供日期和时间，资产组合中的账户数目，总的债务数额，已经解决的账户数目，结算的账户的百分比，结算的债务的数额，结算的所有债务的百分比，解决数额，结算的总债务的百分比，结算的结算债务的百分比，总追款，交易解决数额的百分比。报告可以以各种格式提供。

【0146】图15图解显示了一般的空白表格，该空白表格包括可以填写结算提议数据并为了实现发布结算提议的目的，呈现给债权人的字段。输入可以包括账户编号，状态，名字，原始债权人，本金余额(principalbalance)，当前余额(current balance)，可用结算集，从债务人接收到的建议和还价提议。如果债权人期望具有向债务人动态地产生结算提议的能力，图15的屏幕照片则可以呈现给债权人。在该图中，呈现了四个可编辑的字段和两个计算过的字段。其面前具有图15的屏幕的债权人/信贷机构可能知道债务的细节，及目前协商的状态，并且可以输入预付定金，期限，利息率，和到期日期，它们可以被服务器102接收，并通过债务人设备106呈现给用户/债务人。“计算”选择使用特定的期限和输入的利息率计算月利率和总的偿还债务，而“提交给债务人”允许债权人/信贷机构通过服务器102将提议发送给债权人。注意，如果提议违背了用于债权人/信贷机构的任何规则，诸如用于呈现的情况的利息率太低，服务器102会向债权人/信贷机构发送警告。此外，对应于该规则集的提议超过了所有其它规则，其中一种规则可能是由通过显示在图15中的界面由活的人提交的提议。

【0147】图16图解显示了资产组合管理器，并示出了组织单元(OrgUnit)的概念。在图16中，测试专家(Test Master)是测试区域(Test Region)的资产组合，测试区域是是第一性能的子OrgUnit。测试专家包括各种结算字典和资产组合，测试专家的右边是OrgUnit，资产组合名字，账户号，分配总额，调整总额，结算数目，结算的分配额，和收到的支付。这使用户能创建新的资产组合或修改已经存在原资产组合。如指出的，子OrgUnit可以继承母OrgUnit的财产。图17示出了用于已经创建的资产组合的规则管理器，如果需要，规则可以加入到资产组合中。例如，对于OrgUnit测试区域，资产组合名字测试专家，规则可被创建以结算债务或转移债务，诸如当资产组合不能支付每年少于8％的利息率时，以及资产组合可以以每美元加上50美分卖给一个实体。

【0148】图18图解说明了“子资产组合”的概念，其中可以加入附加的资产组合。在该图中，FPGroup 2，FPGroup 22和FPGroup 3是测试专家的子资产组合。子资产组合可以继承母资产组合的属性和规则，并且可以具有不同的或附加的规则。子资产组合使分类和度量能够被测量以用于资产组合的子部分，并且能描绘出一幅用于资产组合的债务结算状态的良好图画。图19示出了字典管理器屏幕，其中可以为资产组合引入字典。在这种情况下，30，60和90天字典是可用的，这里时间段表示资产组合中债务的拖欠时间。这些日期可以表示拖欠的最大值，最小值，平均值或其它时间段。例如，对于超过30天的旧债务，可应用30天字典，这种字典可以有90天字典不包括的某些选择和规则。引入和目标字典的概念示于图19中，图中，引入字典可以从另一个OrgUnit引入，诸如从远程位置引入。目标字典可以表示可应用于特定的债务资产组合并且可以仅应用于那个债务资产组合的可能字典。

【0149】图20示出了选择的字典，本说明书中为引入字典和其属性，即它可以由七个账户分享，并可以设置为专用于该资产组合。如果字典被设置为专用，则该字典的各方面可以被改变，并且不应用于其它的六个账户。

【0150】图21图解显示了可以为债务人/用户查看的屏幕照片2101。这里显示了个人的姓名，如债权人，参考号，购买日期，原则，联系信息(具有更新此信息的选项)和特别地用于结算的两个选择。在该图中，应付余额是1153.85美元，交易解决方案提议集包括现在支付84.62美元的提议，到期日期是4/21/04，或现在支付230.77美元，12个月每月支付81.15美元，利息率为10％。提议集中的第二提议到期日期是4/6/04。用户要么接受提议集中的提议，或可以选择一个选择以提交她自己考虑的提议。此外，使用户能够提交提议的提议取决于为债权人、信贷机构、债务人和要处理的交易建立的规则。

【0151】结算条款的第二屏幕照片示于图22。图22呈现了提议变量和指导原则、每个不同的规则集。提议仅是90％结算2201中的一个。此例子中的要求是如果采用用户/债务人，则在点2202，值被设置等于10，预付定金等于90，90％的结算。指导原则设定追款的天数小于30，意思是90％的债务必须在30天之内收回。注意90％的提议在7天内到期。也提供了有效日期和取消日期。此形式可以呈现给债权人或维护服务器的实体，如果需要，可以输入条款和/更改条款。

可选的交易解决情况

【0152】尽管前面大致关于特定的债务结算情况对解决交易进行了讨论，但本发明并不是那样被限制的。特别是，可以使用本系统，包括规则，模式，字典，模块，服务器和部件以解决其它类型的交易。

【0153】例如，可以应用本系统和一般方法以寻求和获得慈善捐款。在这种情况下，获得信用报告可以是实用的或不实用的，但可以获得关于使用不同源的捐献者的一般信息。与前面的系统一样，可以给某些捐献者提供网站地址，可以提供数字指示器，诸如捐献者号码。此类捐献者可以具有向许多机构捐献一定数额的历史，因此可以具有可用的档案情况。

【0154】一般来说，捐献者可以使用债务人设备106登录到由慈善机构或慈善团体维护的网站，并且可以登录到服务器102。服务器可以仅依赖账户/交易数据库118以获得用户/捐献者的信息。可选地，如果可以从外部源获得用户/捐献者的外部信息，诸如信用局，包含个人信息的数据库，或互联网资源，可以采用此类资源以扩大个人的档案情况。用户/捐献者可能被请求回应一些问题，诸如收入水平，当前家庭住址，或当前办公地址和位置。然后如以上所述，规则可以被服务器应用以产生提议集，这里提议可以包括一次性礼物或支付选项，可能包括具有每个提议的免费提议。例如，如果对捐献人一无所知，而且捐献人没有提供明显的实质性信息以回应提出的问题，诸如拒绝说明收入水平，则可提供默认的加入等级，诸如25美元，50美元，100美元，250美元或500美元的选项，或一年中每个月支付25美元或50美元。然而，如果已知某些信息，则可以向个人发送不同的提议。例如，如果个人年收入超过150,000美元，并且已知在过年的一年中已经向当前的慈善机构捐款超过1000美元，在过去的一年中向其它慈善机构捐款超过1000美元，则这可以引发一种规则。例如，如果用户/捐献人在过年的一年中已经捐款超过500美元但少于2000美元，并且声明的年收入超过100,000美元，则服务器102将向用户/捐献者发送立即捐献500美元，1000美元，2000美元和5000美元的选项，并分别在年度慈善机构公布中将他或她的名字称为铜级、银级、黄金级和铂金级捐献者。用户可以选择这些选项中的一个、或可以给用户提供一种可选的选项，即用户/捐献者可以输入附加信息。例如，如果用户/捐献者希望额外捐献1500美元，则她可以输入该数目，或者可以输入12个月每月捐献150美元的期望数目。后续的规则可以起作用，但一般而言，捐献的数目可以被接受或交易得到解决。支付可以如前面声明的那样进行，其中在前面的描述中，慈善机构是站在债权人的立场的。注意图2所示的实施例中的某些模块可以是不必要的，或者可以具有不同的功能性。如果没有联系信用局，但联系了账户数据库118和其它慈善相关的机构，则信用局模块202和分析器模块204查找从相关数据源请求的信息，并可以分析所获得的信息。而且，此例中的资产组合管理器220可以是慈善捐款管理器，它能根据预定的规则，使捐献被分配给合适的领受者。

【0155】一个可选的例子是保险索赔中的结算。在本发明的系统100中，用户可以是有索赔或有索赔权利的个人，或者实体，或合适的代理，本说明书称作索赔人。用户/索赔人可以登录到服务器102，例如，服务器可以连接到信用局服务器116和账户/交易数据库118或其它的外部数据库或数据源。在此情况下，账户数据库可以包括以前向用户/索赔人提供的结算提议，关于从合法资源获得的关于索赔人的财务信息，伤害/事故的严重程度，或其它相关信息。基于可用的信息以及在账户/交易数据库118中一般可用的任何为类似索赔支付的索赔历史，服务器可以根据由承保人或保险公司建立的规则准备一套保险结算提议。例如，如果伤害是年纪为58，没有直系家属的个人由于车祸引起的死亡，则现在可向索赔人提供500,000美元,或20年中每年支付30,000美元，或30年中每年支付25,000美元。根据承保人提出的规则，索赔人可以被授权以接受结算或可以提供可选的条款。处理支付(ETF，信用卡支付等)的本发明设计的各方面一般是不要求的，但一旦根据提供的规则和获得的协议，解决了交易，则此支付可被授权，并由第三方支付或由合适的债权人支付。关于解决情况的信息，诸如此索赔已经被解决的事实，和索赔和报告的资产，都可以在适当的时候生成。

【0156】使用本发明的设计，可以实现解决交易的其它例子。

【0157】通过前面的描述，已经对用于交易解决的改进的系统和方法进行了描述。改进的系统和方法可以基本上或完全基于互联网，以使用户能访问结算服务器以解决交易，诸如从提供互联网浏览能力的平台上管理债务。

【0158】前面对特定实施例的描述充分揭示了本公开的一般特性，通过应用现有知识，其它人可以容易地修改/或改写用于各种应用的本系统和方法，而不偏离本发明的一般概念。因此，这种改写和修改在所公开的实施例的等同例的意思和范围内。本说明书中使用的措词或术语是为了描述目的，而非用于限制目的。

Claims (41)

1.一种用于结算交易的方法，包括：

在用户和服务器之间建立网络通信；

在服务器上接收关于所述交易的信息；

从所述服务器和所述用户之外的至少一个源查找与所述交易有关的可用信息；

使用基于规则的引擎，处理来自所述可用信息的数据，该引擎包括代表位于所述服务器上的所述交易的一方建立的规则；和

基于所述基于规则的引擎做出的至少一个决策，将交易结算提议集呈现给所述用户。

2.根据权利要求1所述的方法，其中所述用户包括债务人，所述交易包括所述债务人欠的债务。

3.根据权利要求2所述的方法，其中所述可用信息包括与所述债务人相关的信用报告。

4.根据权利要求3所述的方法，其中所述基于规则的引擎中的规则是由对所述债务有权利的信用实体建立的。

5.根据权利要求1所述的方法，其中所述基于规则的引擎依赖至少一个字典，该字典用来将接收到的信息转换成为所述服务器使用的信息。

6.根据权利要求1所述的方法，其中所述交易结算提议集包括至少一个提议，该提议是根据在所述交易中有利益的信用实体建立的规则形成的。

7.根据权利要求1所述的方法，进一步包括使所述用户能够制作不同于所述交易结算提议集中提供的任何提议的提议。

8.根据权利要求1所述的方法，其中处理来自可用财务信息的数据包括分析可用信息，以仅获得产生所述交易结算提议集需要的那个信息。

9.根据权利要求8所述的方法，其中所述交易结算提议集包括对所述用户的刺激，以通过与所述服务器通信来结算所述债务。

10.根据权利要求1所述的方法，其中所述规则引擎包括考虑所述用户足以解决所述交易的能力的规则。

11.根据权利要求7所述的方法，进一步包括提供可选的结算提议集，其不同于所述交易结算提议集中的任何提议。

12.根据权利要求11所述的方法，进一步包括基于预定的结算规则批准所述可选的结算。

13.根据权利要求1所述的方法，进一步包括将至少一个支付选项呈现给所述用户，该选项与所述交易结算提议集中的至少一个提议有关。

14.根据权利要求13所述的方法，其中所述支付选项包括有折扣的立即支付选项和/或固定货币数额的分期支付。

15.一种结算用户和财务交易一方之间的财务交易的方法，包括：

在用户和服务器之间建立网络通信；

从与所述服务器和所述用户分离的源查找与所述交易有关的可用信息，并且当关于所述交易的信息可用时，接收所述服务器上的所述可用信息；

使用代表所述交易的所述方建立的规则，处理所述服务器上有关所述交易的可用数据；和

基于根据代表所述财务交易的所述方建立的所述规则做出的至少一个决策，将交易结算提议集呈现给所述用户。

16.根据权利要求15所述的方法，其中所述用户包括债务人，所述交易包括所述债务人欠的债务。

17.根据权利要求16所述的方法，其中所述可用信息包括与所述债务人相关的信用报告。

18根据权利要求15所述的方法，进一步包括使所述用户能制作不同于所述交易结算提议集中提供的任何提议的提议。

19.根据权利要求15所述的方法，其中处理来自所述可用信息的数据包括分析所述可用信息，以仅获得产生所述交易结算提议集需要的那个信息。

20.一种结算债务人和债权人之间的财务交易的方法，包括：

在所述债务人和服务器之间建立网络通信；

为所述用户查找信用报告，并且当所述信用报告可用时，在所述服务器接收所述信用报告；

使用由所述债权人建立的规则，处理所述服务器上的所述信用报告；和

基于根据所述债权人建立的所述规则做出的至少一个决策，将交易结算提议集呈现给所述债务人。

21.一种用于结算交易的系统，包括：

服务器，其被配置成接收来自用户的通信，所述服务器进一步被配置以从所述服务器和用户外部的至少一个源查找与所述交易有关的可用信息，所述服务器包括：

基于规则的引擎，该引擎包括代表所述交易的一方建立的规则，所述基于规则的引擎被配置以基于由所述基于规则的引擎做出的至少一个决策，处理来自所述可用信息的数据，并将交易结算提议集呈现给所述用户。

22.根据权利要求21所述的系统，其中所述服务器进一步包括分析模块，其被配置以接收所述可用信息，并基于代表所述交易的所述一方建立的所述规则分析信息。

23.根据权利要求21所述的系统，其中所述服务器进一步包括资产组合管理模块，其被配置以管理资产组合，所述资产组合包括基于由多个用户采取的行动和与所述资产组合相关的方面的多个交易。

24.根据权利要求21所述的系统，其中所述用户包括债务人，和所述交易包括所述债务人欠的债务。

25.根据权利要求24所述的系统，其中所述可用信息包括与所述债务人相关的信用报告。

26.根据权利要求25所述的系统，其中所述基于规则的引擎中的规则是由对所述债务有权利的信用实体建立的。

27.根据权利要求21所述的系统，其中所述基于规则的引擎依赖至少一个字典，该字典用来将接收到的信息转换成为所述服务器使用的信息。

28.根据权利要求21所述的系统，其中所述交易结算提议集包括根据所述规则形成的至少一个提议。

29.根据权利要求28所述的系统，其中所述服务器进一步被配置以使所述用户能够制作不同于所述交易结算提议集中提供的任何提议的提议。

30.根据权利要求21所述的系统，其中所述服务器进一步被配置以提供所述交易结算提议集，所述交易结算提议集包括对所述用户的刺激，以通过与所述服务器通信来解决所述交易。

31.根据权利要求21所述的系统，其中所述规则引擎包括考虑所述用户足以解决所述交易的能力的规则。

32.根据权利要求29所述的方法，进一步包括提供一种可选的结算提议集，其不同于所述交易结算提议集中的任何提议。

33.根据权利要求21所述的方法，其中所述服务器进一步包括支付处理模块，其被配置以将至少一个支付选项呈现给所述用户，该支付选项与所述交易结算提议集中的至少一个提议相关。

34.一种用于结算用户和财务交易的一方之间的财务交易的系统，包括：

服务器，其被配置以从与所述服务器和所述用户分离的源中查找关于所述交易的可用信息，并且当关于所述交易的信息可用时，在所述服务器接收所述可用的信息，其中所述服务器包括：

规则引擎，其被配置以使用代表所述财务交易的所述方建立的规则，处理关于所述交易的可用数据；和

其中所述服务器被配置以：基于根据代表所述财务交易的所述方建立的规则，由所述规则引擎做出的至少一个决策，将交易结算提议集呈现给所述用户。

35.根据权利要求34所述的系统，其中所述服务器进一步包括分析模块，该分析模块被配置以接收所述可用信息，并基于代表所述交易的所述方建立的所述规则分析信息。

36.根据权利要求35所述的系统，其中所述服务器进一步包括资产组合管理模块，其被配置以管理资产组合，资产组合包括基于由多个用户采取的行动和与所述资产组合相关的方面的多个交易。

37.根据权利要求34所述的系统，其中所述用户包括债务人，并且所述交易包括所述债务人欠的债务。

38.根据权利要求37所述的方法，其中所述可用信息包括与所述债务人相关的信用报告。

39.根据权利要求38所述的方法，进一步包括使所述用户能做出不同于所述交易结算提议集中提供的任何提议的提议。

40.一种用于结算债务人和债权人之间的交易的系统，包括：

服务器，其被配置以与所述债务人建立联系，并从债务人接收信息，并且进一步被配置以为所述用户查找信用报告，所述服务器包括：

被配置以接收数据的基于规则的引擎，所述数据包括获得的任何信用报告的至少一部分和与所述交易相关的任何其它信息，所述基于规则的引擎被配置以使用由所述债权人建立的规则处理所述数据；

其中所述服务器进一步被配置以基于根据由所述债权人建立的所述规则做出的至少一个决策，将交易结算提议集呈现给所述债务人。

41.一种用于收集与交易相关的信息的系统，目的是编纂用于结算交易的至少一个提议的一个提议集，包括：

被配置以查找信息的服务器，所述服务器被配置以从一组信息中查找至少一个信息，该组信息包括：

与关于用户的个人数据有关的信息；

与关于用户账户的账户数据有关的信息；

与宏观经济数据有关的信息；和

与所述交易相关的信息；

其中所述服务器从与所述服务器和所述用户分离的一个源中查找所有信息。

Images