CN100409206C

CN100409206C - 交互式发票接口

Info

Publication number: CN100409206C
Application number: CNB018225705A
Authority: CN
Inventors: R·A·尼利; S·布莱特; J·B·法仑; B·科恩; J·C·拉瑟
Original assignee: BCE Emergis Technologies Inc
Current assignee: Emergis Technologies Inc
Priority date: 2000-12-19
Filing date: 2001-12-18
Publication date: 2008-08-06
Anticipated expiration: 2021-12-18
Also published as: WO2002063515A3; EP1368767A2; US20020077977A1; WO2002063515A2; CN1537291A; US7702579B2

Abstract

本发明涉及一种自动化电子开发票和付款联合系统，以供客户远程核实来自至少两个开发票人的账单信息。在较佳实施例中，该系统包括三个主要组成部分：一个整合发票接口、一个供访问整合发票接口的远端客户接口以及一个付款引擎。在该较佳实施例中，所述整合发票接口为每一开发票人提供了至少一个访问点；为至少一个客户设置每一开发票人的访问点；验证每一客户；并直接自每一开发票人自动请求所述客户账户信息。另外，在该较佳实施例中，付款引擎将客户付款指令直接自客户发至每一开发票人。

Description

交互式发票接口

发明背景

(1)发明领域

本发明总体而言涉及自动化票据系统，更具体而言，其涉及供客户远程核实来自至少两个开发票人的账单信息的一种自动化电子开发票与付款联合系统。

(2)先前技术说明

开发票和收款历来是一个高度人力密集和纸张密集的过程。一般而言，该过程涉及一开发票人，通常为一企业，其编制一份详细列明已提供的货物和服务及其相应费用的发票。该发票邮寄给一客户，客户将核实发票的正确性并向开发票人返回某一形式的付款凭证同时附有一纸质支票。开发票人随后将该纸质支票提交至其银行，以通过例如自动清算所(ACH)网络获得付款。其它类似的付款系统包括书写信用卡号、背书及预先授权以汇票的方式自某一账户中按月提取不超过预定限额的款项，例如，通过一支票账户定期支付公用事业费。

随着互联网的出现，开发票人表现出其对由来已久的开具纸质账单和付款过程进行自动化的愿望。较为流行的一种方法是电子账单付款服务。在该方法中，客户收到一张以纸质形式提示的发票，由另外一家通常带有一银行标记的付款服务机构将款项转付给开发票人。该客户持其纸质账单，登录至一基于互联网的服务机构，该服务机构接收付款指令，进而进行电子付款，或在更多情况下，代表客户寄出一张纸质汇票。

该服务机构，尽管在某种意义上对客户是很方便的，但是可能出错，因为收到的付款时常会因数据不正常而致不能准确过账。此外，客户必须仍然以与先前方式基本相同的方式处理账单，并且实际上必须尽早给出付款指令，因为执行付款过程可能需要3-5天的时间。Checkfree是此种类型服务的最大提供商。

大多数行业观察员已经注意到，一更可靠和更高效的开发票处理模式是客户收到一份电子版发票，同时可在同一交易网络内进行电子付款或对各系列项提出异议。在这一方面，人们已熟知多种不同的方法。

一种方法是美国专利第6,044,362号以及同在申请中的美国专利申请案第09/535,334号所述的直接发票提示和付款。该发明在客户和开发票人之间建立了一条直接用于电子发票提示和付款的链接。该技术受到大多数开发票人的喜爱，因为它提供了最强的标记功能、灵活性、支持操作方面的清晰度和最低的成本，并允许开发票人维系当前的银行关系。然而，该方法的一个缺点是客户必须访问多个账户，每个账户均有不同的密码和登录要求。

另一方法是完整账单提示，开发票人通过该方法将其原始账单数据发送给一个中央服务系统，由其将这些数据整合为一个账单列表，并显示给参与该服务的公司的客户。这些公司以“推模式(Push Model)”向该整合服务机构发送数据。这种方法也被称为“完整整合”，因为需要创建一大型数据库，由其将来自许多开账单人的数据合并入一中央服务系统中。该电子系统在下列专利中均有描述：颁予Kight等人的美国专利第5,383,113号；颁予Landry的美国专利第5,649,117和5,956,700号；颁予Anderson等人的美国专利第5,283,829号；颁予Lawlor等人的美国专利第5,220,501号；颁予Hilt等人的美国专利第5,465,206号，且其披露的内容全文均以引用的方式并入本文中。

在这些电子开发票和付款联合系统中，第三方的万维网站点在客户登录访问账单时将成为中央访问点。通常，第三方整合服务机构可有偿允许一不同的机构在开发票人的客户可能访问的网页上打上标记。例如，公司A可能将其原始账单数据发送至一个第三方整合服务机构，当公司A的客户访问其发票时，该网页即由一银行或一互联网门户打上标记。尽管呈示给客户的发票仍然带有公司A的公司标志，但整体服务、登记注册、标志广告以及服务关系的标记将由该第三方整合服务机构及其被许可人控制。

此种类型的服务机构可同时对开发票人和客户提供某些便利。对于开发票人而言，这一方法易于采纳以实施引导，因为服务是外包的，而开发票人开始该过程时仅需提供原始账单文件。而且，对于客户而言，登记注册和密码管理受到简化，且账单核实操作也可更加高效，因为客户访问一个万维网站点即可浏览多项发票。尽管这些系统看起来精简了整个过程，但事实上可能大大增加了该过程的复杂性以及一笔数目不低的费用：

·首先，存在多家整合服务机构，且客户在某些情况下具有各自不同的偏好。但是，许多开发票人感到其受市场所迫而采用多家整合服务机构，以将其账单发至尽可能多的地方，从而增加客户的方便程度。由于原始账单数据和其它参考信息必须送达或推至不同的服务机构，因而必须进行大量的经营投资。具体而言，数据格式经常是不同的，因而开发票人的内部支持团队必须理解每一服务机构的细微差别。此外，不同的银行接口和付款惯例也使支持多个整合服务机构变得复杂化。因此，进行电子提示和付款所带来的成本节约潜势经常会丧失于这种复杂性之中。

·第二，整合服务提供商对每份发票收取的服务费用通常十分高昂，因而使成本节约潜势再一次丧失。

·第三，打标记通常不再由开发票人控制，而由第三方整合服务机构或自该第三方整合服务机构购得再标记权的任何其他人控制。

·第四，开发票人经常会放松关于哪些方可提示该开发票人的发票的控制。事实上，一个被开发票人视为有竞争力的公司可能会凭借其与第三方整合服务机构的业务关系而使一将开发票人的账单包括在内的账单整合服务更加简便。例如，客户可在一个已由一家也提供在线按揭再融资服务的竞争银行打上标记的第三方站点上核实一私人融资公司的按揭账单。以该银行的名义呈示的标志广告可能会使该私人融资公司失去访问该第三方站点的客户。

·第五，发送至第三方的数据具有时间敏感性。开发票人对客户数据的后续修改不能在已经呈示的电子发票中得到反映或更新。该电子账单整合服务系统可能很快与开发票人的数据脱节，从而导致客户疑惑，并进而导致费用高昂的客户支持。

·第六，在该环境下难于进行客户关怀，因为各种关系可能会因排除故障和支持而变得模糊不清。改变格式或开账单人均可能导致问题的出现，因而在问题起因和补救方面常会发生混淆。

·第七，不存在一种可操作的方法来“合并整合机构”。也就是说，不可能有任何一家第三方整合服务机构能够获得一特定个体服务客户的所有开发票人的数据。由于市场的竞争本质，几乎可以肯定地说，一个体需要登录至一个以上的第三方站点来核实其全部发票，因为没有任何一个第三方整合服务机构能够囊括一特定个体服务客户的全部开发票人。

关于电子账单提示和付款的另一技术是“部分整合”。在这种模式下，仅有摘要数据被发送或推至中央整合服务机构。当客户登录查看账单列表和付款选项时，其可以选择一导航选项，在由处于中央位置的第三方服务机构管理和控制的交易过程中，由该导航选项将客户链接至开发票人的详细信息。尽管该方法在重要的客户操作方面为开发票人提供了更多的控制权，但其仍存在明显的不足：

·首先，中央服务系统大大限制了开发票人的处理和使用选项。例如，向服务系统登记或注册均始于该中央服务系统，而开发票人并非始终能完全获知在注册时提供的信息。要求在整合服务机构注册在许多方面即意味着将客户的“所有权”转移至第三方整合服务机构而不是开发票人。

·第二，付款业务关系取决于上述模式的中央服务系统而不是开发票人。付款需经第三方整合服务机构进行。

·第三，付款争议在第三方整合服务机构处解决，这对开发票人来说是一个困难的沟通、客户关怀和调解过程。

·第四，开发票人失去标记机会，且无法控制第三方整合服务机构会允许谁来重新标记该服务机构。该服务机构中数据的整合性质使之难于创造一种环境使发票摘要不显示于可能为竞争者做广告的再标记门户上。

·第五，当前使用的部分整合法不允许客户直接登录至开账单人处查看发票详细信息，客户必须始终从整合服务机构开始登录。

一个开发票系统应允许开发票人保持其与客户的直接关系，而且同时提供简化访问多个站点的便利性。此外，客户应能轻而易举地查看发票摘要数据列表，并能在勿需开账单人放弃过程控制的前提下链接至开发票人的站点。另外，还需要一种简单的方法，以使开发票人“写一次”即可发布至多个不同的访问站点。这些过程可允许开发票人发布摘要数据，以便加入账单列表，然后允许二级提示点通过开发票人站点检索数据(拉模式(Push Model))。开发票人应具有使整合服务机构动态检索其摘要数据的装置，而不是采用当前的“推”整合技术，以确保数据的最新状态。

实现以上所述需要使用能够保留开账单人的标记、客户关怀关系、财务伙伴的选择以及开发票人的市场营销机会的整合技术。这些系统不应要求有价值内容的提供者-在本案中指提供账单摘要或全部电子账单数据的开发票人-必须向第三方支付费用才能获取这些内容-但该方向其他方完全出售的情况除外。该系统应允许通过多个直接站点进行索引，这为客户提供了方便且未放弃开发票人的重要操作和控制方面的考虑。开发票人还应能够选择呈示账单和付款摘要、采购订单以及货运单据等的站点。数据应以多种技术提供，以便于检索及加入其它账单列表。较佳实施例包括提供可通过客户浏览器检索的图形图像以及传送至次级提示伙伴的XML信息串。

因此，人们需要一种简便而直接的自动化电子开发票和付款系统和方法，其应直接涉及开发票人和客户，且同时应允许客户通过一个门户或银行站点访问开发票人的万维网站点，并核实其所有账单摘要，然后访问开发票人网址。这些系统可允许向客户提供当前的真实数据，且同时向开发票人提供及时的付款。此外，由于不需要第三方付款引擎，因而开发票人每次交易均可获得更低廉的成本，并能够控制统一资源定位器(URL)或门户的“标记”，而不需显示第三方服务提供商的标志广告。

发明概述

本发明旨在提供一种自动化电子开发票和付款联合系统，以供客户远程核实来自至少两个开发票人的账单信息。在较佳实施例中，系统包括三个主要组成部分：一个整合发票接口、一个供访问整合发票接口的远程客户接口以及一个付款引擎。

在较佳实施例中，整合发票接口为每一开发票人提供了至少一个访问点；为至少一个客户设置每一开发票人的访问点；验证每一客户；并直接向每一开发票人自动请求账户信息。

此外，在较佳实施例中，付款引擎自客户直接向每一开发票人发送客户付款指令。该较佳付款引擎阐述于2000年3月28日颁布的共同拥有的美国专利第6,044,362号以及同在申请中的美国专利申请案第09/535,334号，现为美国专利第______号，颁布于____年____月____日，其全文以引用的方式并入本文中。

付款引擎包括：发票提示电子装置，其适用于向客户呈示客户账单数据供其核实并针对自动化账单请求发至客户的付款指令；及一个远端电子客户授权接口，其适用于：(i)接收客户账单数据供客户核实以及来自发票提示电子装置的付款指令请求；(ii)提供发送至客户的客户账单数据和付款指令请求；(iii)接收客户针对付款指令请求发出的客户付款指令；以及(iv)直接向每一开发票人传送来自客户的客户付款指令，该付款指令至少包括一个发票账户号码和一个相关的客户付款账户。

如上所述，在较佳实施例中，客户数据通过安装于每一开发票人万维网站点的一个装置取自开发票人的站点。该装置读取开发票人的数据，将其封装并完成客户向门户提出的请求。

因此，本发明的一个方面是提供一自动化电子开发票和付款联合系统，以供客户远程核实来自至少两个开发票人的客户账户信息。该系统包括：一整合发票接口，其中发票接口包括：(i)针对每一开发票人的至少一个访问点；(ii)为至少一个客户设置每一开发票人的访问点的装置；以及(iii)用以验证每一客户的装置；以及一个用以访问整合发票接口的远端客户接口。

本发明的另一个方面是为一供客户远程核实来自至少两个开发票人的客户账户信息的自动化电子开发票及付款系统提供一个整合发票接口。该系统包括：针对每一开发票人的至少一个访问点；为至少一个客户设置每一开发票人的访问点的装置；用以验证每一客户的装置；以及直接自每一开发票人自动请求所述客户账户信息的装置。

本发明的另外一个方面是提供一自动化电子开发票和付款联合系统，以供客户远程核实来自至少两个开发票人的客户信息。该系统包括：一个整合发票接口，其中发票接口包括：(i)针对每一开发票人的至少一个访问点；(ii)为至少一个客户设置每一开发票人的访问点的装置；(iii)用以验证每一客户的装置；以及(iv)直接自每一开发票人自动请求所述客户账户信息的装置；一个供访问整合发票接口的远端客户接口；以及一个付款引擎，其可将客户付款指令直接自客户发至每一开发票人，该付款引擎包括：发票提示电子装置，其适用于向客户呈示客户账单数据供客户核实，并针对自动化账单请求发至客户的付款指令；以及一个远端电子客户授权接口，其适用于：(i)接收供客户核实的客户账单数据和来自发票提示电子装置的付款指令请求；(ii)提供发送至客户的客户账单数据和付款指令请求；(iii)接收客户针对付款指令请求发出的客户付款指令；以及(iv)直接向每一开发票人传送来自客户的客户付款指令，该付款指令至少包括一个发票账户号码和一个相关的客户付款账户。

所属技术领域的技术人员在结合图式阅读下文关于较佳实施例的描述之后将会了解本发明以上所述及其它方面。

附图简要说明

图1是依据本发明提供电子发票摘要并付款的一种方法的总体示意图；

图2是依据本发明进行电子开发票并付款的“部分门户”模式的功能说明；

图3是依据本发明构建的一种“部分门户”电子开发票和付款系统的示意图；

图4是依据本发明在一电子开发票和付款门户上进行登记过程的详细功能说明；

图5是依据本发明在一电子开发票和付款门户上进行开发票/提示过程的详细功能说明；

图6是依据本发明进行的电子开发票和付款方法的摘要服务器/付款过程的详细功能说明；

图7是依据本发明构建的“部分门户”电子开发票和付款系统的一适当数据模型实例；

图8是依据本发明构建的一“完整门户”电子开发票和付款系统的功能说明；

图9是依据本发明构建的一自动化电子开发票和付款联合系统的登记部分的示意图；

图10是依据本发明构建的一自动化电子开发票和付款联合系统的动态显示部分的示意图；

图11是一基于现有技术的开发票付款引擎系统的示意图；

图12是依据本发明进行的电子开发票和付款的一种较佳付款引擎方法的示意图；

图13A和113B是依据本发明构建的一种较佳付款引擎电子开发票和付款系统的示意图。

较佳实施例详细说明

在下文说明中，同样的参考编号在各图中代表同样的或相应的部分。同样，在下文说明中，诸如“向前”、“向后”、“左”、“右”、“向上”、“向下”以及诸如此类的词语均为表达方便而使用，不可解释为限制性词语。

图1所示为依据本发明构建的一动态整合模型(通称为210)的总体示意图。其基本组件是客户互联网接口212、摘要代理门户214以及至少两个开发票人216。在该较佳实施例中，本发明还包括一付款引擎220，其为客户互联网接口212和开发票人216之间的接口。在该较佳实施例中所述的此种付款引擎详细阐释于2000年3月28日颁布的美国专利第6,044,362号，其全文再一次以引用的方式并入本文中。

首先让我们来看总体动态整合模型210。每一开发票人216和摘要代理214首先建立一初始协议222。该协议至少将包括用于访问的URL、摘要代理名称以及用于验证的其它要素。此外，一开发票人和一门户还可达成协议将一万维网页用于客户登记。在该登记页面上，开发票人将会指定用于客户验证所需的要素，如用户名、密码、账号和个人识别代码。这些要素随后将由摘要代理和开发票人在检索数据或为验证至开发票人站点的转移时使用。在摘要代理和开账单人登记完成后，客户212可首先在摘要代理门户214上登记注册，然后转移至开发票人站点216进行登记。

在另一实施例中，客户可以首先向开发票人登记并输入相关客户信息。在开发票人处的登记完成后，客户可以指定其希望将其账单显示于数个门户。因此，虽然客户登记的较佳实施例始于门户并将登记转移至开发票人，但是登记还可始于开发票人，且该开发票人可以提供与之建有协议的门户清单，客户可从该清单中选择希望显示其账单的那些门户。

尽管在图1中将客户登记视为两个单独的行为224和225，但可以授权摘要代理门户214作为客户代理完成在客户212和开发票人216之间建立登记。验证信息还可在门户上生成和储存，且随后还可储存于开发票人站点。当客户开始请求摘要信息时，摘要代理在收到请求后首先对客户进行验证。然后该请求将被发送至开发票人，开发票人验证并确认该客户请求确系关于其当前持有的一个账户，且存在一可由其返回门户的有效账户密码对。

同样，在摘要代理和开发票人之间进行登记的过程中，开发票人还可为客户指定相关的URL，供其查看详细的发票信息。这样，当客户选择从摘要代理处查看详细信息时，其可被传送到开发票人已提供的一个站点，然后根据开发票人已指定的URL将客户引至该特定开发票人站点。

在具体操作中，客户212向摘要代理门户214发送一个请求226，要求显示所有未结账单。摘要代理门户214作出响应向每一开发票人站点216发送一请求，要求沿线路230向选定客户212的摘要代理门户214提供账单摘要信息。然后，摘要代理门户214经由线路232向客户212提供完整账单摘要。如该较佳实施例所述，当具备一付款引擎220时，客户212可以沿线路234查看详细的开发票人信息，并还可沿线路236修改付款安排，如共同拥有的美国专利第6,044,362号所详述。此时，客户实际上可授权付款，开发票人将发出请求，要求直接从客户银行收取款项而无需经由一第三方整合服务机构。

本发明的实际操作也可参照图2从功能角度来理解。如图所示，摘要代理门户214与开发票人之间建立初始协议，其中包括允许开发票人访问该门户站点，以及登录开发票人站点以供客户最终访问。开发票人此时也可在站点之间建立访问安全体系，并规定何种信息可置于摘要代理门户214上供客户查看。

此外，摘要代理门户214允许客户212登记，并选择拟显示的开发票人，并将对一特定客户的登记控制权转移至开发票人。门户站点接受开发票人生成的唯一用户名和密码，并储存每一客户账户的这些唯一用户名和密码。在该较佳实施例中，每一客户212的这些数据对均保存在摘要代理门户上，且客户212在每次登录进入摘要代理门户214时无需重新输入。摘要代理门户站点214也允许客户在摘要代理门户万维网页上配置其优选门户显示。

允许客户配置其优选门户显示之处将作为一“门户配置器”，客户实际上可以根据某些事件规定用户界面显示变化。一个实例是，如果账单将要迟付或过期，则可改变该账单在门户站点的显示颜色，其用以向客户指示即将发生账单迟付或过期状况，或者客户可以规定一特定数额，如果账单摘要内某一账单超出该规定数额，就会被突出显示，此类性质的事项均可根据客户优选确定。

摘要代理门户214从开发票人站点216获取账单摘要信息并加以显示。该门户直接向开发票人站点发送客户请求，且在发送该请求的过程中首先向开票人站点传送验证信息，例如一加密的姓名/密码对或一安全令牌，然后接收来自开发票人或开发票人站点上摘要服务器的摘要数据。此时，如果使用一付款引擎，如共同拥有的美国专利第6,044,362号所述，则客户212也可直接到达开发票人216执行付款交易。

除上述功能外，摘要代理门户214也允许客户在屏幕上指示其已核实发票或下载付款摘要数据信息。此外，摘要代理门户可处理并显示传输错误信息，客户可随后对其进行更正。摘要代理门户214也可用于显示标志广告，以使摘要代理门户的拥有者产生额外收入。最后，摘要代理门户也允许客户在其不再希望使用摘要代理门户或不再与某一特定的先前登记的开发票人维持账户的情况下退出其与一或多个开发票人的联系。

开发票人站点216向摘要代理门户214提供免费赠送功能。开发票人站点216与摘要代理门户214建立一项协议，包括允许一门户管理员直接访问一开发票人站点以登录一门户，并设置该门户站点的访问密码。开发票人站点216也登记各客户并提供付款银行务和客户信息。该过程可由客户手动执行，也可通过Mircrosoft Wallet程序或能够与客户工作站交换该信息的类似程序获取信息。另外，开发票人站点将客户的验证信息例如用户名/密码对返回摘要代理。该验证将产生一用于客户账户访问的安全ID，以仅向有效客户提供数据。

除单一门户模式外，开发票人站点也可允许一客户选择通过多个门户进入。例如，一客户可能希望具有进入多个门户(如AOL或YAHOO！)的选项。

开发票人站点216完成数据摘要请求并处理来自摘要代理门户214的出错信息。它向门户传送包含有摘要数据的图形或XML信息，并同时传送用于详细核实数据的开发票人链接。该过程使用在登记过程中建立的URL来实现这些请求。最后，开发票人站点216允许经由例如在开发票人站点216显示的弹出式窗口或使用帧返回摘要代理门户214。

在该较佳实施例中，该“部分”门户模式在门户处不储存任何客户信息，既不储存付款信息，也不储存详细的发票信息。客户总是被送至开发票人站点来查看详细的发票信息或执行付款。首先，开发票人登记进入一门户银行服务器或一提示服务系统。开发票人首先出示验证参数，以与提示服务系统及开发票人之间进行通信。与此同时，开发票人建立URL和摘要服务器ID，以使摘要代理门户214与开发票人站点216建立联系。开发票人也可同时根据其账单开具周期确定其对门户的更新频率。最后，开发票人也可允许在门户上提供与开发票人有关的标志广告管理信息。

如图4所示，其对登记过程进行了更详细的描述。在登记过程中，摘要代理门户214，例如YAHOO！、AOL或Home Banking Site，允许客户输入客户信息和一用户名/密码对登记进入门户。另外，客户还可以添加电子邮件信息，以允许门户站点在收到一新账单摘要时通知客户212。客户也可输入一般银行信息、包括付款安排在内的付款源以及客户希望显示的开发票人。同时客户可以配置由开发票人显示的信息，例如页面显示，包括范围、消息和容错。最后，客户可以允许同时在其它门户上公布相关信息。

客户登记成功之后，该客户也可同时在摘要代理站点或开发票人站点216上输入与开发票人相关的登记信息。倘使客户在开发票人站点216上登记，则这些信息可从该门户传递至开发票人，其包括客户信息、电子邮件信息、付款源信息以及付款安排。这些信息日后如有变更，则可以通过开发票人站点216予以修改。当最终登记在开发票人站点之后，该站点会将客户信息，如ID号和个人识别号，返回至摘要代理门户214。客户212也可根据其从列表中选择的其它开发票人处进行登记。

摘要代理门户214将该客户置入该门户的未决队列中，并通过电子邮件向客户发送确认信息。客户收到并打开该电子邮件时返回的确认会从门户站点和开发票人站点将该客户激活，从而使该客户核实其摘要账单。

门户收集的付款信息可随后公布于其它开发票人站点。本文所用的“公布于开发票人站点”意指这些信息被送至开发票人，从而使开发票人此时获得付款信息。

本发明的发票提示过程可通过参照图5获得最佳理解。首先，在开发票人站点216开发票，且将详细发票存入详细发票服务器。摘要信息从详细发票服务器拷贝至摘要服务器，这些摘要资料包括，例如，发票金额、付款安排以及付款状态。然后通过开发票人的每一摘要服务器检索摘要数据，包括发票金额、付款安排和付款状态。客户212使用DYNAMIC INBOX(动态收件箱)查看摘要代理处的账单信息。

当客户准备核实每一发票的详细信息时，其将被链接至该详细发票，在转至开发票人站点216时，验证资料也被发送出去。对于“部分”门户模式，摘要代理门户不保存这些详细记录。相反，如果使用“完整”门户模式，则可以通过摘要代理门户修改向开发票人站点216进行的付款安排，并将修改状况传递至详细发票服务器上的开发票人。

如图6所示，客户212一旦被转移至开发票人站点216后即可通过一个付款处理引擎220付款并更新其账户，其将详细阐述于下文中的图12、113A和113B(包括其中的编号分别代表的含义)。

现在来看图7，图中所示为本发明的较佳数据模式概览。在该较佳实施例中，摘要代理门户214包括详细的客户信息以及默认的客户付款源信息，其还包括保持门户/开发票人联系所需的默认客户付款安排和开发票人信息。这些信息可包括开发票人的显示以及账单摘要信息。门户标志信息、标志规格以及客户概况也可储存于摘要门户代理214中。

开发票人站点216存有免费的客户信息以及客户的用户名/密码对。开发票人站点216进一步包括客户联系信息和付款源信息、付款安排和规则、会记信息和历史记录。此外，其还包括摘要信息，例如服务器标识符、开发票人密码、门户参数验证信息以及一般性门户信息。最后，开发票人站点216可包括开发票人标志信息和开发票人标志规格。

本发明的另一实施例是完整门户模式。部分门户模式和完整门户模式的差别是，在完整门户模式中，付款资料储存于门户站点，然后依次公布于开发票人。图8所示为一完整门户模式的动态整合功能模式。该实施例不同于结合图2和下列关键参数所给出和讨论的实施例模式，付款信息储存于门户处，且详细的发票资料也可储存于该门户处。

图9所示为依据本发明构建的一自动化电子开发票和付款联合系统的登记部分的示意图。远端计算机400访问门户管理万维网服务器来登记开发票人。网络405通过互联网、内部局域网或拨号访问万维网服务器。开发票人登记应用程序540允许客户输入关于各开发票人的信息。

页面显示410允许客户输入关于开发票人的信息，包括URL、图形、验证字段以及图标。应用程序将这些信息存入数据库430。

门户万维网服务器420主持登记应用程序。数据库430储存开发票人登记信息。该数据库也用于检索关于有效开发票人列表的信息，客户登记进入该服务系统后即可从其中做出选择。远端计算机440访问门户管理万维网服务器来登记客户。

客户登记应用程序450允许客户选择其希望显示于其动态收件箱中的开发票人。该应用程序450首先从数据库430中读取数据，以确定可向客户显示的有效开发票人列表并检索开发票人信息以完成登记过程(例如使客户通过以在开发票人处完成登记的URL)。然后，该应用程序450向客户显示这些有效开发票人的列表。当客户选定开发票人后，应用程序450显示客户必须填写的栏目(如用户名、密码、账户)列表。这些栏目是针对开发票人的，且也通过数据库430检索。当填写完这些栏目之后，该客户即被传递至开发票人登记应用程序540。开发票人验证信息也随之转移。该开发票人登记应用程序负责生成验证信息，以供在动态收件箱中访问。该验证信息随后传回客户登记应用程序450，并随后储存于客户及验证信息数据库480。

客户桌面付款信息显示于460中。客户可能已经输入付款账户信息(例如支票账户信息、信用卡信息)并储存于其个人计算机的本地数据库中。客户也可能已经通过诸如Microsoft Wallet之类的应用程序输入信息。这些信息随后可按XML、OFX/IFX或其它数据发布标准传递至开发票人登记应用程序540。

门户万维网服务器470主持客户登记应用程序。数据库480储存客户登记和验证信息。

远端计算机500访问开发票人管理万维网服务器来登记门户。门户登记应用程序510允许客户输入关于各门户的信息。页面显示允许客户输入关于门户的信息，包括识别符和URL。然后，应用程序510将信息储存于数据库530中。开发票人处的万维网服务器520主持门户登记应用程序。数据库530储存门户登记信息。该数据库也由门户验证应用程序580用于验证确认：在客户登记过程中转移控制权的门户是一已在开发票人处登记的门户。

开发票人登记应用程序540接受来自门户客户登记页面450的请求，并调用门户验证应用程序560来核实发出该请求的门户。应用程序540也生成该客户的验证信息，并将这些验证信息返回至门户客户登记应用程序450。应用程序540也将该验证信息储存于一数据库600中，以供将来通过动态收件箱进行验证。应用程序540也通过向客户验证应用程序580提供在门户上输入的栏目和数值来验证该客户为该开发票人的一EBPP客户。

验证数据生成程序550用于创建安全信息、对该安全信息进行加密并将该数据储存于动态整合验证数据库600中。该数据库通过开发票人登记应用程序540调用，并传回所生成的验证信息。

门户验证应用程序560从门户登记数据库530读取信息，以确定有效门户的列表及其适用的识别信息。该应用程序560通过开发票人登记应用程序540调用，并由540向其传送应请求收到的门户识别信息。该应用程序获得该门户识别信息、与该数据库核对并验证其是否存在以及该识别信息是否正确。

开发票人处的万维网服务器570主持开发票人登记应用程序。客户验证应用程序580通过开发票人的EBPP数据库590读取有效客户列表及账户。该程序通过核实确保此为一EBPP上的客户，且该账户是该客户的有效账户，且该客户已经输入用以访问该账户的正确验证信息。

EBPP数据库590管理该服务系统上的客户、账户列表以及供客户访问具体账户的验证信息。

客户验证数据库600用于储存由验证数据生成程序550生成的客户安全和验证数据，其用于当客户希望通过动态收件箱显示账单之时。

众所周知，登记可从开发票人站点开始，且该开发票人将显示用于客户登记的可能门户列表。控制权随后传递至该门户以完成登记过程。此外，桌面付款信息460可以采用多种标准(XML、OFX/IFX)传递至开发票人。用以向开发票人传递该信息的方法不应对本专利构成限制。

图10所示为依据本发明构建的一自动化电子开发票及付款联合系统的动态显示部分的示意图。远端计算机440访问门户显示万维网服务器以登记开发票人。网络710通过互联网、内部局域网或拨号上网来访问万维网服务器。门户的万维网服务器720主持动态收件箱应用程序。

门户页面生成器应用程序730创建用以向客户显示门户信息的页面。该应用程序构建并输出万维网html格式文件，以显示于万维网服务器上。该程序也接受客户关于通过页面和站点显示及导航的请求。该应用程序调用账单摘要页面生成器740为客户创建页面的动态收件箱部分。门户应用程序730将客户登录门户站点所获得的客户信息传送至账单摘要页面生成器740。

账单摘要页面生成器应用程序740用以在门户页面上构建客户账单摘要。该页面生成器在收到请求后首先通过客户验证应用程序745验证一客户是一个有效客户，然后为该客户创建动态收件箱。该程序也检索已储存的客户安全令牌，以通过一安全链接以加密格式将其传递至开发票人数据服务器765。然后，该开发票人数据服务器765对照其客户验证数据库600确认该客户的验证信息。账单摘要页面生成器也通过客户验证应用程序745检索该客户选择在其动态收件箱中显示的开发票人列表。然后，账单摘要页面生成器调用开发票人验证应用程序750来验证该客户选定的开发票人，并也检索用于在动态收件箱中建立开发票人链接的开发票人URL信息。

账单摘要页面生成器通过一客户安全链接向开发票人数据服务器765传递一系列请求，包括验证用的安全令牌、开发票人、账户以及所请求数据的类型。在对客户和开发票人进行验证之后，开发票人数据服务器765随后通过一个安全链接将所请求的数据返回账单摘要页面生成器。

开发票人验证应用程序750通过对照开发票人验证数据库430进行检查来确认自账单摘要页面生成器发送的开发票人确为有效的开发票人。该程序也通过开发票人验证数据库430检索其它开发票人信息，包括URL。

客户优选应用程序760允许客户通过门户配置万维网网页的显示。客户能够选择其希望在其页面上显示的内容以及显示方式。客户也可根据特定数值选择显示变化，以此配置账单在本应用程序的动态收件箱中的显示格式。例如，客户可以配置该应用程序，以在到期日已经超过当前日的情况下将发票行的颜色变为红色。该应用程序将储存客户优选设置，并在客户显示页面时对其进行检索。

数据库770用于储存客户优选页面。该数据库用于储存客户的优选，且在显示页面时，客户优选应用程序760将对该数据库的数据进行检索，以确定客户的优选。

开发票人数据服务器765负责验证发自账单摘要页面生成器740的请求，并向其返回合适的数据或出错信息。

门户验证应用程序772是开发票人数据服务器765的一部分，它首先通过检查门户登记数据库530来验证发出请求的门户确为一有效门户。账户验证应用程序775是开发票人数据服务器765的一部分，它通过对照客户验证数据库600检查安全令牌来验证客户的账户和身份确实有效。该应用程序对安全令牌进行解密，并将该经解密的令牌与储存在数据库中的客户令牌进行对比。

请求转换应用程序780是开发票人数据服务器765的一部分，它将客户请求传递至合适的服务器以检索必要的数据。XML服务器790检索与该账户相关的客户账单数据信息，并将其封装为XML格式数据包返回开发票人数据服务器765。它通过开发票人摘要服务器应用程序820来检索该信息，而应用程序820在收到请求时或以批处理方式通过开发票人系统检索该信息。

图形服务器800检索与该账户相关的客户账单数据信息，并将其封装为图形格式(GIF或其它图形格式)的数据包返回开发票人数据服务器765。它通过开发票人摘要服务器应用程序820来检索该信息，而应用程序820在收到请求时或以批处理方式通过开发票人系统检索该信息。

一般或特定格式服务器810检索与该账户相关的客户账单数据信息，并将其封装为特定格式。该格式可以是IFX、OFX、EDI或其它特定格式，这些服务器将处理待传递回开发票人数据服务器765的该信息包。它通过开发票人摘要服务器应用程序820来检索该信息，而应用程序820在收到请求时或以批处理方式通过开发票人系统检索该信息。

开发票人摘要服务器应用程序820接收来自格式服务器的请求，并通过开发票人摘要数据库830检索该开发票人的信息。开发票人摘要数据库由开发票人在收到请求时或通过批处理方式装入。作为替代方案，开发票人摘要服务器也可以直接自开发票人系统通过某些接口或特定的数据库储存程序检索信息。

数据库830储存开发票人摘要信息，其由开发票人系统在收到来自开发票人摘要服务器应用程序的请求时提供或通过开发票人系统定期更新。

现在来看图11，其为纸质发票付款以及通过第三方服务提供商进行自动化发票付款的当前过程。

对于纸质发票过程，开发票人10开具一纸质发票12，该发票将通过邮件发送至客户20。在验证该发票正确以后，客户20开具一张纸质支票22，并将该纸质支票返回至开发票人10。然后，开发票人10贷记客户20的账户，并将支票22连同其它业务收据提交给开发票人银行30。开发票人银行30随后通过众所周知的ACH网络与客户银行40联系，要求自客户的支票账户划转资金并将其存入开发票人的支票账户。该交互过程采用了一种由32、42所表示的传统的众所周知的过程。

如上所述，在开发票人10自客户20收到支票22之前已经过了一段时间。如果支票由直接由客户20送至开发票人银行30，则该过程可以在一定程度上加快。该锁箱(lock box)过程产生于对发票上邮箱地址的使用，其可将支票22直接送至开发票人银行30，即使发票12上的地址可能显示开发票人10的名称。在这一经改良的过程中，开发票人银行30在收到支票22后仍将在款项记入开发票人账户之前通过ACH网络32、42履行有关程序。

为使该过程自动化，第三方服务提供商54加入进来。在本过程中，开发票人10向服务提供商54传送电子数据流14，包括纸质发票通常所包含的全部信息。然后，服务提供商54和客户20之间进行电子通信，以通知客户20知悉未付费用，并在某些情况下允许客户批准通过其账户付款。然后，服务提供商54将付款授权52发送给客户银行40。与此同时，服务提供商54也可将一信息56传送至开发票人10，通知其知悉付款授权52。

在收到付款授权52后，客户银行40通过传统渠道将款项付至开发票人银行30。

非银行服务提供商54也可得到授权访问ACH网络，以代表客户20通过PPD客户银行40来办理汇票业务。在此种情况下，服务提供商54可以自客户收取款项并存入服务提供商的支票账户，然后再将这些款项转付给开发票人10。

从图11的复杂性可知，常规纸质发票过程和第三方服务提供商过程二者均不方便且费时费力。

图12所示为一种依据本发明构建的电子开发票和付款的方法。该方法始于向客户20呈示一发票的电子提示50。应了解，本文所用术语“提示”一词并不包括通常与商业票据相关的专业定义，即向一提款人出具的一可议付票据。相反，该术语意指通过电子装置提供一至少含有与一纸质发票通常所含客户账单数据相同的“发票”。此种电子提示可以通过使用一互联网站点、一银行自动柜员机或通过使用一个独立的公用电话亭进行。

在一较佳实施例中，发票也可包括，除通常的账单数据之外，一付款指令请求。该请求向客户提供一机会选择支付该发票款项的银行账户，或向客户提供通过借记卡、信用卡、自动柜员机、储值卡或其它资金来源进行付款的选项。

发票可包括诸如客户名称、地址、账户号码和电子邮件地址之类的账单资料。发票可进一步包括一纸质发票通常所包括的账单数据，以注明该发票所涵盖的期间、该发票所涉及的具体货物/服务的详细状况、应付总额以及付款到期日期。

除典型发票信息外，电子发票提示也可包括与信贷条件的变更及类似情况相关的客户通知。开发票人10也可包括销售和促销资料，借以向客户20通报新产品或关于现有产品的销售情况。

在电子发票提示50之后，客户向开发票人10提供一项电子授权52，准许从客户账户付款。这一步骤可以省去开具和邮寄纸质支票所需的时间和费用。这样，开发票人10即有可能在短至一天的时间内从客户银行账户支取款项，这与接收纸质支票22所需的时间相比大为缩短。

包含于上述电子授权中的信息可包括发票账号以及一相关的客户付款账户。在一较佳实施例中，这两项信息与授权同时提交。当发出预先安排的指令时，不需要每次均重新提交该信息。

在提供付款授权之前，客户20可获得变更付款指令的数个选项，以创建经过修改的付款指令52a。这些修改可以是不作任何修改即接受电子发票提示中所载的全部付款条件。另外，客户20可获得下列选项中的任一组合：

1)客户可因非特定原因或某具体原因，如对发票所载的某个系列项发生争议，而支付少于到期发票金额的款项；

2)客户可选择支付多于到期发票金额的款项；

3)客户可选择实施特殊付款，例如针对一项贷款偿付额外本金；

4)客户可选择变更通过电子转账付款的日期，但前提是该日期尚未过期；

客户可以变更付款资金来源，即从一个主要支票账户变更为一个预授权的信用卡。

进行上述任何变更均要求客户得到开发票人的授权。

上述方法可通过图13A所示的自动化票据系统加以实施，该系统可供客户对来自一开发票人的自动化账单进行远程核实，其包括：(a)发票提示电子装置60，用于为请求与自动化账单相关的付款指令而提交客户账单资料；以及(b)一个电子客户授权接口84。

该客户接口接收来自开发票人提示电子装置的客户账单数据和付款指令请求，并将这些资料提供给客户。该接口也可响应付款指令请求接收客户付款指令，并将这些指令从客户传送给开发票人。

该发票提示电子装置60也可进一步包括一控制系统62以及第一个通信电子装置64。这些构件通常安装于一个由开发票人控制的设施内。

在一客户设施处，系统包括一个远程授权终端80，其具有第二个电子通信装置82，该装置用于与第一个电子通信装置64进行通信。控制系统62对电子发票50的生成进行协调，该电子发票至少包括传统纸质发票中通常所包括的所有账单信息并附有付款指令请求。该控制系统随后将监控该信息自第一个电子通信装置64提交至第二个电子通信装置82以供客户核实整个过程。

远程授权终端80适用于向一客户提供账单数据，并传送该客户对账单数据的合适反应。这些反应将指示无任何改变地全部接受账单数据以实施自动化付款，或者如上所述对账单数据进行修改。客户接口84可进一步适用于将这些信息传送至发票提示电子装置60。

该系统的构件可以采用多种方法进行配置。例如，客户可访问站点可以驻留于开发票人提供的用于接收账单数据和来自客户的付款指令的一个互联网万维网站点。该站点可通过客户电子授权接口84访问。在本例中，客户授权接口84将包括一个互联网浏览器以访问客户可访问站点。

该电子客户授权接口的其它替代性装置包括自动柜员机(ATM)、远端公用电话亭、个人计算机、交互式电视装置或电话机。

倘使采用电话机，则电子客户授权接口84可包括一台众所周知的按键式电话机或基于屏幕的电话机。

在另一实施例中，电子客户授权接口84是一台数字计算机，其通过电子邮件向客户提供账单数据和付款指令请求，并通过电子邮件回复将客户付款指令52转发至发票提示电子装置60。电子客户授权接口84也可包括一用于显示账单数据和付款指令请求的显示装置以及一用于接收客户付款指令的客户启动输入装置。

除可视显示外，电子客户授权接口也可进一步包括音频电子装置85和一扬声器86，以向客户呈示账单数据和付款指令请求。在该实施例中，用于接收客户付款指令的此种客户启动输入装置也可为客户语音输入装置。

电子客户授权接口84也可适用于允许客户轮询(poll)发票提示电子装置60，以接收账单数据和付款指令请求。

本发明的自动化票据系统包括一开发票人向一客户提交账单数据供客户远程核实、这些数据的接受或修改以及将这些数据传送至开发票人。可提交给客户的账单信息50可包括下列各项的任一组合：

·付款到期日

·到期应付金额

·账单期间提供的货物/服务详细情况

·滞纳金

·账户信息

·客户信息，包括客户名称、客户地址及客户账户识别符(账户识别符可包括一客户号码及/或一账户号码)

·发票识别符，如发票号码

·系列项争议

·多项发票付款

发票提示电子装置60可包括一储存装置，以储存与客户账单有关的发票信息以及与客户相关的金融机构的账户信息。也就是说，客户可有权从多个账户中选择一具体账户，从其中提取款项支付发票金额。

储存装置和发票提示电子装置60也可包括与预授权付款指令相关的信息，以通过该指令从账户信息中所列的一个账户自动支付账单信息中所列的账单金额。如果使用了预授权付款指令，则来自发票提示电子装置60的付款指令请求50可询问客户是接受经修改的还是未修改的这些指令。为完成此种修改，客户授权接口84可进一步包括一个编辑器，以供修改预授权付款指令。

本发明的总体操作可参照图13B得到更好的理解。开发票人的客户可以通过任何远程安装的计算装置101访问系统，并通过一个公共或私人网络102与开发票人系统通信。一万维网服务器或某种类型的通信处理器103对客户与允许客户开始配置过程的应用系统之间的在线通信实施管理。系统以电子方式向客户呈示数据输入表格，该表格应通过一配置应用程序104完成，该程序也可根据包含于Legacy系统中的开发票人记录来验证客户输入的数据是否有效。在确定客户和财务账户记录是否准确之后，开发票人将激活客户进行电子发票提示和汇款过程。

可向客户发送电子邮件信息或传统信函，其含有允许客户访问系统的信息，如账户号码及/或密码。

在该客户的下一开发票周期中可以获得合适的数据，例如Legacy打印数据以及Legacy自动付款106。Legacy打印数据是指通常被发送至打印机以通过纸张打印客户发票的数据。Legacy自动付款数据是指通常由开发票人创建的使开发票人按照与客户之间的预授权安排启动付款的记录。付款记录包括那些经格式化用于通过支票账户或储蓄账户进行自动资金转移(ACH格式数据)以及通过信用卡、借记卡或储值卡进行借记交易的记录。拟向ATM网络传输的文件也包括在内。

在获取产品数据的过程中，Legacy数据通过一应用程序107分类、分析和压缩，并保持合适的控制数据以报告操作状况。应用程序108将数据装入关系数据库109以供按月处理。在该较佳实施例中，可以使用两台单独的计算机对具有敏感性的诸如账户号码和授权代码之类的财务数据提供额外的安全。作为进一步安全措施，开发票人可选择使用位于开发票人防火墙安全装置之后且通过一安全网络111连接至万维网服务器主机112的计算机110对产品进行配置。

发票提示数据和关于财务安排的数据集合可以通过即时数据传输，例如通过数据库109内一个加密的远程储存程序或者分批传输，予以提示。

在需要以电子方式呈示的数据已经准确地装入万维网服务器数据库113之后，应用程序114将向客户发送电子邮件信息宣布月度发票已经具备并提供某些数据摘要。由于电子邮件账户数据可能无效或无法获得服务，因而，应用程序114可用于生成通过美国邮政服务、传真或其它方式发送的数据。前端处理器115中含有以开发票人希望的方式呈示发票和默认付款安排116所必需的模板。万维网服务器103主持一客户可借以访问其发票的交互式交易网络。客户可选择修改预定的付款安排。例如，客户可以更改付款金额、付款日期、将付款资金来源从一个人支票账户更改为开发票人批准的另一来源，例如，信用卡。这些安排114储存于万维网服务器数据库113内。

在该较佳实施例中，客户也可使用连接至网络102和一台PBX电话处理交换机118的电话机117与语音应答装置119之间传递数据。客户可以通过按键输入或语音识别调入关于其发票的听觉信息并发出信号指示其对先前存在的安排的更改。这些更改由前端处理器115加以处理，并记录于数据库中，与基于远程计算机的输入相似。

在开发票人向银行或金融交易处理机构发送付款数据的每一天，应用程序120均受到执行以识别万维网服务器数据库113中排定付款计划的客户。来自万维网服务器的数据被传送至第二台计算机110进行处理，并与最初储存于关系数据库109的含有预授权付款安排的数据合并。记录将根据客户的指令受到修改，或者对于客户请求变更付款源的情形，这些记录可能会被删除并重新创建。然后，对数据进行格式化以重新与开发票人的Legacy系统121接口，例如，模拟用于开发票人的锁箱处理的普通文件格式。

数据122被传送至开发票人银行或办理金融交易的一个第三方机构。当一个处理批次内的客户数据因资金不足或账户数据不正确而被退回时，应用程序123会加以记录，以保持正确的客户付款历史记录。

该产品的安全措施允许采用专门以开发票人为中心的方式传送电子发票提示和付款安排。尽管该较佳实施例涵盖开发票人可能选择将万维网服务器主持或万维网服务器及汇付处理外包给代表开发票人的一个外部公司，但仍将以使客户在正常情况下不会觉察到开发票人实际上并未直接操作该产品的方式向客户提供服务。

在阅读上述说明之后，所属技术领域的技术人员还可对该产品作出某些修改或改良。图3以实例的方式示出了始于开发票人的登记过程，其中在创建令牌时，需提供一名称/密码对以及客户初始记录的验证信息。但本发明的登记过程也可始于摘要代理或门户。而且，本文所用的“开发票人”一词也可包括一“应付账户”站点，该站点首先自一个以上的子发票开票人检索其信息并将其合并于一发票中。例如，一本地电话公司可将来自其自己、一单独的长途电话公司和一互联网DSL服务机构的子发票合并在一起。应了解，为了简明和可靠起见，所有此种修改和改良已自本文中删除，但其仍合理地属于下述权利要求的范围。

Claims

1. 一种自动化电子开发票和付款联合系统，以供客户远程核实来自至少两个开发票人或来自代表所述开发票人的实体的客户账户信息，所述系统包括：

(a)一整合发票接口，其中所述发票接口包括：(i)针对每一开发票人或针对代表所述开发票人的实体的至少一个访问点；(ii)为至少一个客户设置每一开发票人或代表所述开发票人的实体的所述访问点的装置；以及(iii)用以验证每一所述客户的装置；

(b)一用以访问所述整合发票接口的远端客户接口；以及

(c)一用以将发票付款指令从所述客户电子地传输到每一开发票人或代表所述开发票人的实体的付款引擎，所述付款引擎包括：发票提示电子装置，其适用于向客户呈示电子发票，以便供客户核实，所述电子发票由所述开发票人或以代表所述开发票人的方式从客户账单数据创建，保存在服务器上并且只能由所述开发票人或以代表所述开发票人的方式取出，而且，该发票提示电子装置适用于针对自动化账单请求发至所述客户的付款指令；及一个远端电子客户授权接口，其适用于：(i)接收电子发票供客户核实以及来自所述发票提示电子装置的付款指令请求；(ii)提供发送至客户的电子发票和付款指令请求；(iii)接收客户针对付款指令请求发出的客户付款指令；以及(iv)向每一开发票人或代表所述开发票人的实体传送来自客户的客户付款指令。

2. 如权利要求1所述的系统，其中所述付款来源为一清算所。

3. 如权利要求2所述的系统，其中所述清算所为一信使。

4. 如权利要求2所述的系统，其中所述清算所为一付款网络。

5. 如权利要求1所述的系统，其中所述付款指令包括传送日期。

6. 如权利要求1所述的系统，其中所述付款指令包括自客户相关金融机构提取的金额。

7. 如权利要求1所述的系统，其中所述付款指令包括与客户相关的账户信息，其中款项自该客户处提取。

8. 如权利要求1所述的系统，其中所述付款指令包括与每一开发票人或每一代表所述开发票人的实体相关的账户信息，其中款项自该客户或所述实体处提取。

9. 如权利要求1所述的系统，其中所述账单数据包括开发票人账单信息。

10. 如权利要求9所述的系统，其中所述账单信息包括一到期日期。

11. 如权利要求9所述的系统，其中所述账单信息包括一到期应付金额。

12. 如权利要求9所述的系统，其中所述账单信息包括在一账单期间内所供货物或服务的清单。

13. 如权利要求9所述的系统，其中所述账单信息包括一迟付费用。

14. 如权利要求9所述的系统，其中所述账单信息包括一账户信息。

15. 如权利要求1所述的系统，其中所述账单数据包括客户信息。

16. 如权利要求15所述的系统，其中所述客户信息包括客户名称。

17. 如权利要求15所述的系统，其中所述客户信息包括客户地址。

18. 如权利要求15所述的系统，其中所述客户信息包括所述客户的账户信息。

19. 如权利要求1所述的系统，其中所述账单数据包括一客户账户标识符。

20. 如权利要求1所述的系统，其中所述账单数据包括一发票标识符。

21. 如权利要求1所述的系统，其中所述发票提示电子装置进一步包括与客户账单有关的发票信息以及与所述客户有关的金融机构账户信息，其中款项将自所述客户处提取。

22. 如权利要求21所述的系统，其中所述发票提示电子装置进一步包括一预授权付款指令，以通过该指令从所述账户信息中所列的一个账户自动支付所述账单信息中所列的账单金额。

23. 如权利要求22所述的系统，其中来自所述发票提示电子装置的付款指令请求将询问客户对于所提示的账单数据是否需要预授权付款指令。

24. 如权利要求22所述的系统，其中来自所述发票提示电子装置的付款指令请求将询问客户所提示账单数据的预授权付款指令是否需要修改。

25. 如权利要求22所述的系统，其中所述客户授权接口包括一用于修改所述预授权付款指令的编辑器。

26. 如权利要求21所述的系统，其中所述账户信息包括来自多个金融机构的账户信息，且所述付款指令请求将询问客户选择自其中提取款项以支付一相关客户账单的金融机构。

27. 如权利要求26所述的系统，其中所述发票提示电子装置包括一预授权默认值，其用于确定自其中提取款项以支付所述相关客户账单的金融机构。

28. 如权利要求27所述的系统，其中所述电子客户授权接口适用于接收一客户输入以接受预授权默认值。

29. 如权利要求27所述的系统，其中所述电子客户授权接口适用于接收一客户输入以修改预授权默认值。

30. 如权利要求1所述的系统，其中所述付款指令请求包括账单信息，其选自由到期金额、付款时间及用于提取款项的账户组成的群。

31. 如权利要求30所述的系统，其中所述客户授权接口适用于修改账单信息，以更改一个或多个由到期金额、付款时间及用于提取款项的账户组成的群。

32. 如权利要求1所述的系统，其中所述账单数据包括所述客户的通知。

33. 如权利要求1所述的系统，其中所述账单数据包括针对所述客户的广告信息。

34. 如权利要求1所述的系统，其中所述账单数据包括控制信息。

35. 如权利要求1所述的系统，其中所述付款指令包括一提取款项日期。

36. 如权利要求1所述的系统，其中所述付款指令包括一发票金额。

37. 如权利要求1所述的系统，其中每一开发票人或每一代表所述开发票人的实体均将提供一客户可访问站点，以接收所述账单数据及所述付款指令请求，所述站点可通过所述电子客户授权接口访问。

38. 如权利要求37所述的系统，其中所述客户可访问站点为一互联网站点且所述电子客户授权接口包括一用于访问所述客户可访问站点的浏览器。

39. 如权利要求37所述的系统，其中所述电子客户授权接口为一自动柜员机。

40. 如权利要求37所述的系统，其中所述电子客户授权接口为一远端公用电话亭。

41. 如权利要求37所述的系统，其中所述电子客户授权接口为一个人计算机。

42. 如权利要求37所述的系统，其中所述电子客户授权接口为一交互式电视装置。

43. 如权利要求37所述的系统，其中所述电子客户授权接口为一电话机。

44. 如权利要求37所述的系统，其中所述电子客户授权接口为一计算机，所述账单数据及所述付款指令请求通过向客户发送电子邮件予以提示且所述客户付款指令通过一客户电子邮件提供。

45. 如权利要求37所述的系统，其中所述电子客户授权接口包括一用于显示所述账单数据和所述付款指令请求的显示装置以及一用于接收客户付款指令的客户启动输入装置。

46. 如权利要求37所述的系统，其中所述电子客户授权接口包括音频电子装置和一扬声器以呈示所述账单数据和所述付款指令请求，以及一用于接收客户付款指令的客户启动输入装置。

47. 如权利要求37所述的系统，其中所述电子客户授权接口适用于允许一客户轮询所述发票提示电子装置，以接收所述账单数据和所述付款指令请求。

48. 如权利要求1所述的系统，其中所述电子客户授权接口包括一访问程序及一服务器连接。

49. 如权利要求48所述的系统，其中所述访问程序为一互联网服务器。

50. 如权利要求48所述的系统，其中所述服务器连接为一互联网服务器连接。

51. 如权利要求50所述的系统，其中所述互联网服务器连接为一互联网拨号连接。

52. 一种用于一自动化电子开发票和付款联合系统的整合发票接口，以供客户远程核实来自至少两个开发票人或代表所述开发票人的实体的客户信息，所述整合发票接口包括：

(a)针对每一开发票人或代表所述开发票人的实体的至少一个访问点；

(b)为至少一个客户设置每一开发票人或代表所述开发票人的实体的所述访问点的装置；

(c)用以验证每一所述客户的装置；

(d)自每一开发票人或代表所述开发票人的实体自动请求所述客户账户信息的装置；以及

(e)用以将发票付款指令从所述客户电子地传输到每一开发票人或代表所述开发票人的实体的装置，其中所述整合发票接口适用于传送电子发票，所述电子发票由所述开发票人或以代表所述开发票人的方式从客户账单数据创建，保存在服务器上并且只能由所述开发票人或以代表所述开发票人的方式取出。

53. 如权利要求52所述的整合发票接口，其中所述至一开发票人或代表所述开发票人的实体的至少一个访问点为开发票人的统一资源定位器。

54. 如权利要求52所述的整合发票接口，其中所述至一开发票人的至少一个访问点进一步包括多个至每一开发票人的访问点。

55. 如权利要求52所述的整合发票接口，其中所述每一开发票人的所述每一访问点为一门户站点上的统一资源定位器。

56. 如权利要求52所述的整合发票接口，其中用于设置每一开发票人或代表所述开发票人的实体的访问点的装置包括开发票人的统一资源定位器自开发票人的万维网站点的转移。

57. 如权利要求56所述的整合发票接口，其中用于设置每一开发票人或代表所述开发票人的实体的访问点的装置进一步包括一访问点集合，其用于提供可访问门户及开发票人或代表所述开发票人的实体的目录。

58. 如权利要求57所述的整合发票接口，其中所述访问点集合包括一开发票人统一资源定位器、门户统一资源定位器及付款引擎统一资源定位器中的至少之一。

59. 如权利要求52所述的整合发票接口，其中用于设置每一开发票人或代表所述开发票人的实体的访问点的所述装置进一步包括用于安排客户付款的装置。

60. 如权利要求59所述的整合发票接口，其中用于安排所述客户付款的所述装置位于门户端。

61. 如权利要求59所述的整合发票接口，其中用于安排所述客户付款的所述装置为一位于开发票人端的数据输入点。

62. 如权利要求59所述的整合发票接口，其中用于安排所述客户付款的所述装置位于所述开发票人的付款引擎处。

63. 如权利要求52所述的整合发票接口，其中验证装置储存于一门户上。

64. 如权利要求63所述的整合发票接口，其中储存于一门户上的所述验证装置为一名称/密码对。

65. 如权利要求63所述的整合发票接口，其中储存于一门户上的所述验证装置进一步包括开发票人验证信息。

66. 如权利要求65所述的整合发票接口，其中所述开发票人验证信息为一名称/密码对。

67. 如权利要求52所述的整合发票接口，其中所述验证装置为开发票人验证信息。

68. 如权利要求67所述的整合发票接口，其中所述开发票人验证信息储存于开发票人站点上。

69. 如权利要求68所述的整合发票接口，其中储存于开发票人站点上的所述开发票人验证信息为一名称/密码对。

70. 如权利要求52所述的整合发票接口，其中用于自动请求客户账户信息的所述装置为一至开发票人万维网站点的统一资源定位器请求。

71. 如权利要求52所述的整合发票接口，其中所述客户账户信息包括开发票人内容。

72. 如权利要求71所述的整合发票接口，其中所述内容包括至少下述之一：当前账单“摘要”、账单/付款历史“摘要”、开发票人通知/消息“摘要”、票据或详细信息。

73. 如权利要求52所述的整合发票接口，其中所述客户账户信息包括采购订单。

74. 如权利要求52所述的整合发票接口，其中所述客户账户信息包括货运单据。

75. 如权利要求52所述的整合发票接口，其中所述客户账户信息的数据格式至少为下述之一；XML、EDI、图形、文本以及IFX/OFX。

76. 一种自动化电子开发票和付款联合系统，以供客户远程核实来自至少两个开发票人或代表所述开发票人的实体的客户账户信息，所述系统包括：

(a)一整合发票接口，其中所述发票接口包括：(i)针对每一开发票人或代表所述开发票人的实体的至少一个访问点；(ii)为至少一个客户设置每一开发票人或代表所述开发票人的实体的所述访问点的装置；以及(iii)用以验证每一所述客户的装置；以及(iv)用于自每一开发票人或代表所述开发票人的实体自动请求所述客户账户信息的装置；

(b)一个用以访问所述整合发票接口的远端客户接口；

(c)一个付款引擎，其中所述客户付款指令自客户发至每一开发票人或代表所述开发票人的实体，所述付款引擎包括：发票提示电子装置，其适用于向所述客户呈示电子发票，以便供客户核实，所述电子发票由所述开发票人或以代表所述开发票人的方式从客户账单数据创建，保存在服务器上并且只能由所述开发票人或以代表所述开发票人的方式取出，而且，该发票提示电子装置适用于针对自动化账单请求发至所述客户的付款指令；以及一个远端电子客户授权接口，其适用于：(i)接收供客户核实的所述电子发票和来自所述发票提示电子装置的付款指令请求；(ii)提供发送至所述客户的电子发票和付款指令请求；(iii)接收所述客户针对所述付款指令请求发出的客户付款指令；以及(iv)向每一开发票人或代表所述开发票人的实体传送来自客户的客户付款指令。

77. 如权利要求76所述的系统，其中所述付款源为一清算所。

78. 如权利要求77所述的系统，其中所述清算所为一信使。

79. 如权利要求77所述的系统，其中所述清算所为一付款网络。

80. 如权利要求76所述的系统，其中所述付款指令包括传送日期。

81. 如权利要求76所述的系统，其中所述付款指令包括待自客户相关金融机构提取的金额。

82. 如权利要求76所述的系统，其中所述付款指令包括与客户相关的账户信息，其中款项将自所述账户中提取。

83. 如权利要求76所述的系统，其中所述付款指令包括与每一开发票人或代表所述开发票人的实体相关的账户信息，其中款项将存入所述账户。

84. 如权利要求76所述的系统，其中所述账单数据包括开发票人账单信息。

85. 如权利要求84所述的系统，其中所述账单信息包括一到期日期。

86. 如权利要求84所述的系统，其中所述账单信息包括一到期应付金额。

87. 如权利要求84所述的系统，其中所述账单信息包括一在账单期间提供的货物及服务清单。

88. 如权利要求84所述的系统，其中所述账单信息包括一迟付费用。

89. 如权利要求84所述的系统，其中所述账单信息包括账户信息。

90. 如权利要求76所述的系统，其中所述账单数据包括客户信息。

91. 如权利要求90所述的系统，其中所述客户信息包括客户名称。

92. 如权利要求90所述的系统，其中所述客户信息包括客户地址。

93. 如权利要求90所述的系统，其中所述客户信息包括所述客户的账户信息。

94. 如权利要求76所述的系统，其中所述账单数据包括一客户账户标识。

95. 如权利要求76所述的系统，其中所述账单数据包括一发票标识符。

96. 如权利要求76所述的系统，其中所述发票提示电子装置进一步包括与客户账单有关的发票信息及与所述客户有关的金融机构账户信息，其中款项将自所述客户处提取。

97. 如权利要求96所述的系统，其中所述发票提示电子装置进一步包括一预授权付款指令，以通过该指令从所述账户信息中所列的一个账户自动支付所述账单信息中所列的账单金额。

98. 如权利要求97所述的系统，其中来自所述发票提示电子装置的付款指令请求将询问客户对于所提示的账单数据是否需要预授权付款指令。

99. 如权利要求97所述的系统，其中来自所述发票提示电子装置的付款指令请求将询问客户所提示账单数据的预授权付款指令是否需要修改。

100. 如权利要求97所述的系统，其中所述客户授权接口包括一用于修改所述预授权付款指令的编辑器。

101. 如权利要求96所述的系统，其中所述账户信息包括来自多个金融机构的账户信息，且所述付款指令请求将询问客户选择自其中提取款项以支付一相关客户账单的金融机构。

102. 如权利要求101所述的系统，其中所述发票提示电子装置包括一预授权默认值，其用于确定自其中提取款项以支付所述相关客户账单的金融机构。

103. 如权利要求102所述的系统，其中所述电子客户授权接口适用于接收一客户输入以接受预授权默认值。

104. 如权利要求102所述的系统，其中所述电子客户授权接口适用于接收一客户输入以修改预授权默认值。

105. 如权利要求76所述的系统，其中所述付款指令请求包括账单信息，其选自由到期金额、付款时间及用于提取款项的账户组成的群。

106. 如权利要求105所述的系统，其中所述客户授权接口适用于修改账单信息，以更改一个或多个由到期金额、付款时间及用于提取款项的账户组成的群。

107. 如权利要求76所述的系统，其中所述账单数据包括所述客户的通知。

108. 如权利要求76所述的系统，其中所述账单数据包括针对所述客户的广告信息。

109. 如权利要求76所述的系统，其中所述账单数据包括控制信息。

110. 如权利要求76所述的系统，其中所述付款指令包括一提取款项日期。

111. 如权利要求76所述的系统，其中所述付款指令包括一发票金额。

112. 如权利要求76所述的系统，其中每一开发票人或代表所述开发票人的实体均将提供一客户可访问站点，以接收所述账单数据及所述付款指令请求，所述站点可通过所述电子客户授权接口访问。

113. 如权利要求112所述的系统，其中所述客户可访问站点为一互联网站点且所述电子客户授权接口包括一用于访问所述客户可访问站点的浏览器。

114. 如权利要求112所述的系统，其中所述电子客户授权接口为一自动柜员机。

115. 如权利要求112所述的系统，其中所述电子客户授权接口为一远端公用电话亭。

116. 如权利要求112所述的系统，其中所述电子客户授权接口为一个人计算机。

117. 如权利要求112所述的系统，其中所述电子客户授权接口为一交互式电视装置。

118. 如权利要求112所述的系统，其中所述电子客户授权接口为一电话机。

119. 如权利要求112所述的系统，其中所述电子客户授权接口为一计算机，所述账单数据及所述付款指令请求通过向客户发送电子邮件予以提示且所述客户付款指令通过一客户电子邮件提供。

120. 如权利要求112所述的系统，其中所述电子客户授权接口包括一用于显示所述账单数据和所述付款指令请求的显示装置以及一用于接收客户付款指令的客户启动输入装置。

121. 如权利要求112所述的系统，其中所述电子客户授权接口包括音频电子装置和一扬声器以呈示所述账单数据和所述付款指令请求，以及一用于接收客户付款指令的客户启动输入装置。

122. 如权利要求112所述的系统，其中所述电子客户授权接口适用于允许一客户轮询所述发票提示电子装置，以接收所述账单数据和所述付款指令请求。

123. 如权利要求76所述的系统，其中所述电子客户授权接口包括一访问程序及一服务器连接。

124. 如权利要求123所述的系统，其中所述访问程序为一互联网服务器。

125. 如权利要求123所述的系统，其中所述服务器连接为一互联网服务器连接。

126. 如权利要求125所述的系统，其中所述互联网服务器连接为一互联网拨号连接。

127. 如权利要求76所述的系统，其中所述至一个开发票人的至少一个访问点为开发票人的统一资源定位器。

128. 如权利要求76所述的系统，其中所述至一个开发票人或代表所述开发票人的实体的至少一个访问点进一步包括多个至每一开发票人的访问点。

129. 如权利要求76所述的系统，其中所述每一开发票人的所述每一访问点为一门户站点上的统一资源定位器。

130. 如权利要求76所述的系统，其中用于设置每一开发票人或代表所述开发票人的实体的访问点的装置包括开发票人的统一资源定位器自开发票人的万维网站点的转移。

131. 如权利要求130所述的系统，其中用于设置每一开发票人或代表所述开发票人的实体的访问点的装置进一步包括一访问点集合，其用于提供可访问门户及开发票人或代表所述开发票人的实体的目录。

132. 如权利要求131所述的系统，其中所述所述访问点集合包括一开发票人统一资源定位器、门户统一资源定位器及付款引擎统一资源定位器中的至少之一。

133. 如权利要求76所述的系统，其中用于设置每一开发票人或代表所述开发票人的实体的访问点的所述装置进一步包括用于安排客户付款的装置。

134. 如权利要求133所述的系统，其中用于安排所述客户付款的所述装置位于门户端。

135. 如权利要求133所述的系统，其中用于安排所述客户付款的所述装置为一位于开发票人端的数据输入点。

136. 如权利要求133所述的系统，其中用于安排所述客户付款的所述装置位于所述开发票人的付款引擎处。

137. 如权利要求76所述的系统，其中验证装置储存于一门户上。

138. 如权利要求137所述的系统，其中储存于一门户上的所述验证装置为一名称/密码对。

139. 如权利要求137所述的系统，其中储存于一门户上的所述验证装置进一步包括开发票人验证信息。

140. 如权利要求139所述的系统，其中所述开发票人验证信息为一名称/密码对。

141. 如权利要求76所述的系统，其中所述验证装置为开发票人验证信息。

142. 如权利要求141所述的系统，其中所述开发票人验证信息储存于开发票人站点上。

143. 如权利要求142所述的系统，其中储存于开发票人站点上的所述开发票人验证信息为一名称/密码对。

144. 如权利要求76所述的系统，其中用于自动请求客户账户信息的所述装置为一至开发票人万维网站点的统一资源定位器请求。

145. 如权利要求76所述的系统，其中所述客户账户信息包括开发票人内容。

146. 如权利要求145所述的系统，其中所述内容包括至少下述之一：当前账单“摘要”、账单/付款历史“摘要”、开发票人通知/消息“摘要”、票据或详细信息。

147. 如权利要求76所述的系统，其中所述客户账户信息包括采购订单。

148. 如权利要求76所述的系统，其中所述客户账户信息包括货运单据。

149. 如权利要求76所述的系统，其中所述客户账户信息的数据格式至少为下述之一；XML、EDI、图形、文本以及IFX/OFX。

150. 一种用于自动化电子开发票和付款联合的方法，以供客户远程核实来自至少两个开发票人或代表所述开发票人的实体的客户账户信息，所述方法包括下述步骤：

(a)提供一整合发票接口，其中所述发票接口包括：(i)针对每一开发票人或代表所述开发票人的实体的至少一个访问点；(ii)为至少一个客户设置每一开发票人或代表所述开发票人的实体的所述访问点的装置；以及(iii)用以验证每一所述客户的装置；

(b)通过一远端客户接口访问所述整合发票接口；以及

(c)使用付款引擎将发票付款指令从所述客户电子地传输到每一开发票人或代表所述开发票人的实体，所述付款引擎包括：发票提示电子装置，其适用于向客户呈示电子发票，以便供客户核实，所述电子发票由所述开发票人或以代表所述开发票人的方式从客户账单数据创建，保存在服务器上并且只能由所述开发票人或以代表所述开发票人的方式取出，而且，该发票提示电子装置适用于针对自动化账单请求发至所述客户的付款指令；及一个远端电子客户授权接口，其适用于：(i)接收电子发票供客户核实以及来自所述发票提示电子装置的付款指令请求；(ii)提供发送至客户的电子发票和付款指令请求；(iii)接收客户针对付款指令请求发出的客户付款指令；以及(iv)向每一开发票人或代表所述开发票人的实体传送来自客户的客户付款指令。

151. 一种用于自动化电子开发票和付款联合的方法，以供客户利用一整合发票接口远程核实来自至少两个开发票人或代表所述开发票人的实体的客户账户信息，所述方法包括下述步骤：

(a)针对每一开发票人或代表所述开发票人的实体提供至少一个访问点；

(b)为至少一个客户设置每一开发票人或代表所述开发票人的实体的所述访问点；

(c)验证每一所述客户；

(d)自每一开发票人或代表所述开发票人的实体自动请求所述客户的账户信息；以及

(e)将发票付款指令从所述客户电子地传输到每一开发票人或代表所述开发票人的实体，其中所述整合发票接口适用于传送电子发票，所述电子发票由所述开发票人或以代表所述开发票人的方式从客户账单数据创建，保存在服务器上并且只能由所述开发票人或以代表所述开发票人的方式取出。

152. 一种用于自动化电子开发票和付款联合的方法，以供客户远程核实来自至少两个开发票人或代表所述开发票人的实体的客户账户信息，所述方法包括下述步骤：

(a)提供一整合发票接口，其中所述发票接口包括：(i)针对每一开发票人或代表所述开发票人的实体的至少一个访问点；(ii)为至少一个客户设置每一开发票人或代表所述开发票人的实体的所述访问点的手段；以及(iii)用以验证每一所述客户的手段；以及(iv)用于自每一开发票人或代表所述开发票人的实体自动请求所述客户账户信息的手段；

(b)通过一远端客户接口访问所述整合发票接口；以及

(c)使用付款引擎将所述客户付款指令自客户发至每一开发票人或代表所述开发票人的实体，所述付款引擎包括：发票提示电子装置，其适用于向所述客户呈示电子发票，以便供客户核实，所述电子发票由所述开发票人或以代表所述开发票人的方式从客户账单数据创建，保存在服务器上并且只能由所述开发票人或以代表所述开发票人的方式取出，而且，该发票提示电子装置适用于针对自动化账单请求发至所述客户的付款指令；以及一个远端电子客户授权接口，其适用于：(i)接收供客户核实的所述电子发票和来自所述发票提示电子装置的付款指令请求；(ii)提供发送至所述客户的电子发票和付款指令请求；(iii)接收所述客户针对所述付款指令请求发出的客户付款指令；以及(iv)向每一开发票人或代表所述开发票人的实体传送来自所述客户的客户付款指令。