CN1326081C - 便于开户的系统和方法 - Google Patents

Abstract

一种便于多个后端系统开户的系统。开户系统包括一个前端接口，它与客户交互以便收集诸如账户类型选择、计费信息和收取位置信息之类的客户信息。系统的后端接口预先核实客户信息，然后把客户信息路由到后端系统用于激活账户。后端接口还包括一个监视器和一个高速缓存，监视器确定后端系统的可用性，高速缓存在后端系统暂时不可用时存储开户请求和稍后要路由的客户信息。预先核实客户信息有利于在后端系统不可用时让后端接口实时地给客户分配账号。预先核实确保客户信息完全正确，以便允许后端系统稍后激活该账户。

Description

便于开户的系统和方法

技术领域

本发明涉及各种类型的开户流程的自动化，特别是涉及通过后端系统集合使用网络和计算机化的系统来采集和路由客户信息，以便促进账户的激活并提供其它相关服务。

背景技术

对于许多公司，都需要用不断增加的号码加速开立不同客户的账户。用于对这些账户进行开户的现有系统常常需要明显的人工干预，这种人工干预放慢了开户流程，并且例如当客户信息是通过电话告知的并且转写到数据库时出现了错误，人工干预还可能引入人为差错。另外，必须经常根据个人客户的需要定制每个账户，因此需要客户的多次决定，并且需要准确收集并路由和那些决定相关的大量信息。例如，为了开立不同的运输账户，运输或货运企业需要精确和快速地收集顾客信息。

从每天只有临时包裹的运输到多个包裹的运输，企业和个人的运输需求差异非常大。更多的发货人希望在运输包裹时能方便地为每个包裹支付运输费用。另外，运输服务提供商通过尽可能使顾客方便地发送包裹和尽可能方便地为运输付费而从中获益。通常，通过建立一个运输账户，客户可以通过该帐户要求不同的运输服务，并按照有规律的时间间隔，例如每月，付清该账户，这样可以简化运输。运输账户允许客户职员只需要通过装箱单上的账户号码来委托运输服务，从而在很大程度上节省了职员的时间和精力。

发送包裹的某些客户已经与运输服务提供商达成协定：运输服务提供商每天在预定时刻派服务员去取包裹。运输服务提供商通常为这样的服务收取一定费用。对于具有大量运输需求的客户而言，为收取包裹支付的费用通常是微不足道的。对于发送包裹没有时间规律的客户而言，他们可能觉得收取包裹的服务将导致成本增加，因此选择将包裹放在运输服务提供商指定的地点。不管怎样，一种更方便的对运输服务提供商和客户计费的方法是在运输服务提供商授予客户的赊购账户中积累费用。

客户要得到运输账户，必须向运输服务提供商提交一个开立帐户请求(“开户请求”)。如图18所示，现有的开户和向客户分配账号的方法是使用客户服务代表应答电话架构进行的。当潜在的客户希望成为账户所有人时，客户通过呼叫客户服务总线进行口头请求。客户的呼叫被转给负责新账户的客户服务代表。客户服务代表与客户通电话，询问一系列问题以便确定客户需要的账户类型。客户服务代表把信息记录到一个表单。然后将该表单手动馈送或重新键入几次到不同后端系统组中。账户库系统在客户服务代表选择并输入的有效日期分批地分配和激活账户。一旦已经开立了账户，客户服务代表手动记录新账号。客户服务代表然后通过把客户信息输入一个完全不同的供应系统来安排一个启动包(startup kit)。最后，服务代表进入服务分配系统来为账户预定账户服务，包括在客户位置处每天收取包裹的服务。

上述的开户流程需要集中的人力、消耗时间并且还有其他一些缺点。新账号经由启动包或客户服务代表的跟踪呼叫到客户需要二或三个工作日。如果客户表示急需账户，客户服务代表至多可以在几小时内打一个转送新账号的反馈电话。由于预定和非预定的维修或其它原因引起的停机，后端系统在多数时间都不能使用。在停机期间，不能分配账号，不能打开帐户，也不能提供其它服务。另外，客户服务代表可能忽略了完成一个或多个表单，导致开户流程的延迟甚至停滞。需要把数据重新输入到多个表单使得更容易出现转录错误。

从客户到服务代表的电话传达也有一些问题。没有办法将呼叫分类为“优先呼叫”，这样一个潜在的新客户可能要在电话中等待好几分钟。没有正确记录信息的客户服务代表可能会把错误输入到后端系统。在各个代表之间分配账户类型和有效日期也可能不同。另外，电话服务中心通常因为费用太高而无法每周7天每天24小时运转。

国际互联网的出现已经简化了包括运输工业在内的一些企业的账户申请。通过在一系列表单中填充不同的客户信息，可以在运输公司的环球信息网地址上申请账户。运输服务提供商然后处理表单，开立账户，并且给客户分配账号。申请账户和发布账号之间的延迟可能会激怒客户，并且可能导致损失那个客户的服务。一个运输服务提供商(联邦快递)通过响应互联网上提交的申请实时为每个不同类型的帐户提供一个账号来处理这个问题。

无论通过什么方式提交账户申请，用来产生账号并建立账户的系统有时由于一个或多个系统的停机而不能发布账号。通常当处理账户申请的系统之一正在维修或出现系统故障时会停机。在此停机期间，在现有电话申请系统或互联网申请系统中都不能提供账号。在此期间可能会失去对缓慢服务失望的客户。

让互联网接入系统采集和处理账户申请而不需要大量客户服务代表与客户联络并手动输入客户信息将是有利的。如果在不同账户处理系统的预定和非预定的停机期间可以实时给客户发布账号也将是有利的。

发明内容

本发明通过提供由一个或多个后端系统便于开户的系统来处理上面的需求并且实现其它的优点。开户简化系统包括与客户相互作用以便收集诸如账户类型选择、计费信息和收取位置信息之类的客户信息的前端接口。该开户简化系统还包括预先核实客户信息然后把客户信息路由到后端系统用于激活账户的后端接口。后端接口还包括监视系统(“监视器”)和高速缓存，监视器确定后端系统的可用性，高速缓存在后端系统暂时不可用时存储稍后要路由的开户请求和客户信息。有利地，预先核实客户信息让后端接口在后端系统不可用时实时地给客户发布账号。预先核实确保客户信息完全正确，以便允许后端系统稍后激活该账户。

在一个实施例中，开户简化系统(“开户系统”)包括从客户查询接口中接收客户信息并核实该客户信息的客户信息核实器。开户系统还包括消息发送或路由系统，它可用来制定消息的格式、向每一后端系统发送消息和从每一后端系统接收消息。响应于客户信息的核实，消息发送系统可以制定开户请求的格式并将它发送给后端系统的账户库系统。如果后端系统不可用，则开户系统还包括高速缓存，用于存储直到后端系统可用为止的消息。有利地，消息储存在高速缓存中允许即使当后端系统由于预定或非预定停机时间而不可用时也可由客户提交开户请求。

账户可以是通过运输服务提供商发送包裹的运输账户或者是其它类型的消费者或企业账户。不同类型的运输账户包括临时运输账户和周期性(通常是每天)运输账户。一方面，在账户库系统已经产生临时运输账号时客户就可以使用该账户。另一方面，每天运输账户直到经过预先确定的延迟才可由客户使用，在预先确定的延迟期间，预定周期性的收取访问。该延迟还可以在后端系统之一不可用时使用，此时不能完成账户请求。开户系统可以包括一个监视器，它通过检查每一后端系统的预定停机时间或者使用查询或确定后端系统响应性的“ping”逻辑来确定后端系统是否可用。

一方面，监视器可以通过信息发送系统向一个或多个后端系统发送查询消息。查询消息可以是发送给后端系统的一个简单查询。后端系统回复失败可能表明后端系统不可用，或者后端系统可以发送一个指示它不可用的回复。这则消息还可以包含制定格式后的消息，这些消息到达后端系统的一些子系统，允许监视器确定后端系统是否完全可用或者部分可用。例如，监视器可以发送由消息发送系统制定格式后的查询消息，并把这则查询消息发送给账户库系统。这则查询消息包含制定格式后的信息，这些信息到达账户库系统的账号数据库，容许账户库系统或监视系统确定账号数据库是否可用。当数据库具有比预定义账号最小数目更少的账号时另一查询发出警告。这则查询消息还可以包括警告信息，它向后端系统及其子系统指示这则查询消息是一个测试而不是一个需要完整处理和响应的典型消息。这则警告信息有利地防止后端系统向开户系统发送假信息。

在另一方面中，客户信息包括运输和计费地址信息。账户库系统包括在开户之前核实运输和计费地址信息的地址核实器。客户信息核实器预先核实同一运输和计费地址信息，允许开户请求储存在高速缓存中用于随后执行，而没有被账户库系统地址核实器拒绝的危险。当客户仍然在申请时实时执行预先核实，允许客户纠正任何不正确的地方。优选地，核实器预先核实城市、州和邮编等等，更优选地，核实器执行一个附加的街道级核实。

本发明对于各种后端系统都适用，但是一个或多个后端系统的具体结构并不是本发明的一部分。后端系统通常是单独的系统，在参与开户请求之前它需要消息发送系统来定制消息和语言习惯的格式。除了账户库系统之外，后端系统可以包括向客户发送供应的供应系统。例如，如果开户系统正在开立运输账户，供应可以包括一个包含便于客户使用运输账户的各种指令和内容的供应包。后端系统还可以包括用于把服务分配给客户的服务系统。例如，在每天运输账户的情况下，服务系统可以包括调度系统和服务分配系统。调度系统可以完成客户的服务调度核实。服务调度核实确保在适当的时间向客户提供运输服务。服务分配系统然后派遣运输服务职员到客户位置每天收取包裹。

在另一方面中，本发明包括一种通过互联网开立客户运输账户的系统和方法，该系统和方法获得客户信息，基于客户信息推荐一种运输账户类型，然后预先核实所选择的客户信息，以允许立即向客户分配地面运输、空中运输和国际装货单都可用的账号。

前端接口被用来通过互联网与客户通信，以便获得并核实客户信息，并且被用来向客户实时分配运输账号而不需要客户服务代表参与。后端接口被用来向一个或多个单独的后端系统发送开户消息，以便开立与账号相应的账户。后端接口通过前端接口与客户通信，并且，如果后端系统可用则建立运输账户，或者，如果后端系统不可用则把开户消息存储在高速缓存中稍后传送。

在另一实施例中，本发明包括一个图形用户界面，用于通过互联网与客户通信并且用于与一个或多个后端系统通信以便与运输服务提供商建立运输账户。图形用户界面包括记录客户提交的客户信息的客户信息查询。客户信息最好包括关于客户计划未来地面发货需求的地面运输需求信息和关于客户计划未来空运需求的空中运输需求信息。图形用户界面的账户推荐接口基于客户提交的地面运输需求信息和空中运输需求信息向客户推荐一种账户类型。账户推荐接口还包括账户选择字段，允许客户选择客户所需的不同于推荐的账户类型的账户类型。账户推荐接口把开户请求传送给后端系统以便开立客户选定的账户类型。图形用户界面还包括账号接口，它相应于地面和空运订单布局重新建立的运输账户来向客户传送账号。账号接口可以用来向客户实时传送账号并且向客户传送一个延迟，在使用该账户可以放置装货单之前必须经过该延迟。延迟是以接收并执行开户请求的后端系统的可用性为基础的。

一方面，账户推荐接口计算地面运输需求和空中运输需求的费用，以便确定一个最节约成本的账户推荐给客户。可替代地，发货的最节约成本的账户可以是每日收取账户或者临时收取账户，在每日收取账户中，运输服务提供商每天都到客户运输位置；在临时收取账户中，运输服务提供商并不每天都到客户运输位置。如果运输量非常低以至于一个临时账户不实际时，开户系统还可以推荐一种信用卡运输账户。

本发明还可以由电话服务中心使用。电话服务中心的服务员通过电话接受来自客户的开户请求并提交该开户请求。在这种情况下，服务人员把客户传送的信息输入开户系统中并获取客户账号。

另一方面，开户系统的前端接口包括模块化的、可升级的结构，该结构包括相互作用来显示一系列网页以便从客户获取客户信息的好几个组件。前端接口被分解成为页面对象和处理机对象，页面对象包含有关如何显示页面的信息，处理机对象包含处理那个页面所需的逻辑。

本发明的开户系统具有优于现有技术的一些优点。从客户观点看，因为可通过互联网访问开户系统，所以开户系统很方便并且易于使用。同时，在可以使用帐户之前，开户系统以最小延迟时间或者没有延迟时间就立即提供账号。开户系统有利地自动请求对于客户的包括启动包在内的供应材料以及与账户相关的客户服务。在运输账户的情况下，向客户提供可用于地面和空中发货的单个账号。该账号对于某些类型的账户发货可立即有效，并且如果不能立即可用，则客户知道该账户何时可用于发货。另外，使用该账户不需要信用卡。

开户系统对于账户提供商也具有优点。开户系统避免了专门输入数据以及协调后端系统使用的职员开支。在客户把他们自己的数据输入到图形用户界面时避免了数据输入差错。在电话中心的情况下，开户系统协调后端系统的使用，将开户中的差错和延迟减到最少。即使当后端系统关闭时也仍然可以许可账号，减少了在后端系统可用性的预定或非预定中断期间丧失客户。上面列出的该开户系统的优点能吸引乐意使用传统系统之外的附加客户，从而增加账户预订数目。

附图说明

因此已经以常规术语说明了本发明，现在将参考附图，附图不一定是按比例绘制的，在这些附图中：

图1是本发明一个实施例的开户系统的示意图，示出了开户系统、客户计算机和多个后端系统之间的关系；

图2是图1的开户系统与多个后端系统相互作用的框图；

图3是图2的开户系统的前端接口的框图；

图4是图2的开户系统的后端接口的框图；

图5是图2的开户系统的开户监视器的框图；

图6是图5的开户系统监视器的另一框图；

图7A和7B是由本发明另一实施例的计算机程序产品执行的开户方法的流程图；

图8是本发明另一实施例的图形用户界面首页的截屏图；

图9是图形用户界面的运输需求页面的截屏图；

图10是图形用户界面的联系页面的截屏图；

图11是图形用户界面的信用卡运输页面的截屏图；

图12是图形用户界面的账户类型页面的截屏图；

图13是图形用户界面的服务费页面的截屏图；

图14是图形用户界面的收取信息页面的截屏图；

图15是图形用户界面的计费信息页面的截屏图；

图16是图形用户界面的账号信息页面的截屏图；

图17是本发明的图形用户界面的账号提供页面的截屏图；和

图18是现有技术的开户系统的示意图。

具体实施方式

下面将参考附图更完整地描述本发明，附图中示出了本发明的优选实施例。然而，本发明可以通过多种不同形式来体现，而不受在此处提出的实施例的限制；相反，提供这些实施例以使本公开全面和完整，并且对于本领域技术人员来说完全覆盖了本发明的范围。相同的数字在全文中指代相同的成分。

促进开户的系统的一个实施例或者本发明的“开户系统”10如图1至图6所示。如图2所示，开户系统10包括前端接口11和后端接口13，客户15或服务中心16可通过诸如公共互联网、专用内部网或局域网之类的网络12访问前端接口11，后端接口13通过路由系统40发送消息来和多个后端系统14通信。

如图1所示，开户系统10的前端接口11收集经由客户计算机20从客户15通过网络12发送的客户信息。开户系统10的前端接口11基于客户信息推荐账户类型并且请求来自客户的账户参数。开户系统通过后端接口13把账户参数传送到后端系统14的账户库系统17(“ARS”)。如果账户库系统可用，则它核实客户信息的有效性，实时(例如，4-90秒，或者更优选地是4-30秒)产生一个账号并激活对应于该账号的账户。

如果账户库系统不可用，则开户系统10预先核实客户信息的有效性并实时产生一个账号，使用前端接口11把账号传送给客户15并存储用于在稍后转发给后端系统14的开户请求(和其它消息)。按照这种方式，即使一个、一些或所有的后端系统14不可用或变成不可用时，客户15也可接收账号。并且，开户系统10预先核实客户信息确保当账户库系统接收到保存和转发的消息时账户库系统17将发现客户信息有效。

或者，开户系统10可以与能够完成一系列功能的其它类型的后端系统14通信。例如，后端系统还可以包括供应系统18(“SS”)，供应系统18从开户系统中接收客户信息和账号并且把诸如启动包之类的供应发送给客户15。启动包包含新开户要使用的指令和内容。另一方面，后端系统14还包括一个服务分配系统19(“SDS”)，用于在从开户系统接收到账号和客户信息之后给客户15提供服务。启动包的一个示例是用于启动运输账户的工具，包括包装、详细列出运输指示的标签、价格表。服务系统19提供的服务示例可以是调度使用运输账户来发送包裹的每日包裹收取。服务系统19通过包裹中心信息系统79或PCIS与包裹中心通信，以便设置计划时间。账户库系统17把客户信息和账号信息传送给称为SFA或LINK的销售人员自动化软件80，这个自动化软件80是管理销售渠道的运输服务提供商的账户执行程序所使用的一个销售人员自动化软件包。

参见图2，开户系统的前端接口11位于一个网层，因为它包括产生显示在客户计算机20上的多个网页的Java账户servlet 21。如图3和图4所示，账户servlet运行在服务器22或多个服务器上，并且通过用于安全目的的防火墙41与后端接口13分离。通常如图8至图17的网页截屏图所示，按照这种方式，开户系统10通过图形用户界面与客户15交互，以便从客户获得客户信息并且把开户信息转送给客户。servlet 21不限于运行在服务器22上，它还可以运行于其它类型的硬件、固件或两者组合上。通常，servlet 21是包含在源互联网站点(未示出)内的许多应用中的一种，它与客户15交互，完成除了开户之外的其它任务，例如广告或销售之类。

前端接口收集来自客户的信息，基于客户信息推荐账户类型并且经过防火墙将数据提交给后端接口13用于另外的处理。如图3所示，这些前端接口功能由一组客户(或用户)数据处理系统和一组账户数据处理系统执行。用户数据处理系统包括用户验证查询系统23、HTTP请求解析系统42、HTTP响应构成系统43和数据核实系统26。

用户验证查询系统23与源互联网站点的用户登录和验证系统24，又称为互联网会员服务(IMS)，以及客户配置文件系统25通信。验证系统24控制源互联网站点的注册和其他相关访问权利。如图2所示，客户配置文件系统(CPS)25存储源互联网站点得到和使用的和客户有关的信息。在提交开户请求之前通过验证系统24要求客户登录到互联网站点上。在登录期间提供的任何相关客户信息储存在CPS 25中，并用于预置前端接口11的网页。还可以通过安全套接层(SSL)进行开户系统10和客户之间的通信，安全套接层是一个安全的Web浏览器，它能够保护客户通过互联网发送的敏感个人信息。

在成功开立一个新的账户之后，开户系统10可通过发送新发布的账号来更新用户登录和验证系统24。接着，用户登录和验证系统更新客户配置文件系统25，存储该账号用于将来与其它配置文件信息一起使用。源互联网站点和它的其它系统可以和访问和使用其他配置文件信息一起访问和使用该账号。例如，当与客户交互时，其它系统可以用账号预置各种信息字段，从而不需要在每次应用中再输入该账号。

HTTP请求解析系统42把所有客户提交的信息和应用具体信息解析成为一个可用的内部数据表示。反过来，HTTP响应构成系统43把商务规则应用到内部数据上，以便产生各个互联网浏览器可识别的HTML页面。数据核实系统26使用商务规则来检查在网页字段上提交的客户信息的有效性，并且拒绝接受客户提交的错误数据，例如在各个字段中使用不正确字符等等。

账户数据处理系统包括账号请求系统44、账户请求产生系统45和账户响应解析系统46。账号请求系统使用远程方法调用(RMI)呼叫后端接口13，并且从储存在受保护的服务环29中的可用账号库或表33中获得下一个可用账号。账户请求产生系统45还使用RMI来把客户信息发送给后端接口用于进一步处理，并将其传送到后端系统14。账户响应解析系统46从后端接口13复查已完成的消息，并向后端接口13更新已完成的消息。虽然优选使用RMI，但是在本领域中也公知用于发送消息的若干其它方法并且可以使用这些方法。

另一方面，前端接口11包括模块化的、可升级的结构，该结构包括相互作用来呈现一系列网页以便从客户获取客户信息的好几个组件。开户前端接口被分解成为页面对象和处理机对象，页面对象包含有关如何显示页面的信息，处理机对象包含处理那个页面所需的逻辑。最好使用XML文件来描述网页。XML文件规定包括在每个页面上的输入对象。输入对象包括用于收集并显示信息的输入字段。在一个示例中，输入页面收集用于发送包裹的收取信息和诸如位置信息、联系信息和地址信息之类的输入对象。具有地址信息的输入对象可以包含诸如城市、州、邮编和街道号之类的输入字段。

开户系统10的每个输入页面具有针对页面处理机的指针，它是在产生输入页面时由页面库通过示例说明的。页面处理机包含服务逻辑和功能，用于使用一种核实方法或设置方法来处理来自页面的输入。如果一个页面处理机已经具有新页面所需功能，那么可以再次使用现有的处理机并不必对它进行重写。页面处理机的核实器核实输入字段中的输入并对于无效信息报告错误。简单地通过XML文件的创建或修改，输入页面和页面处理机允许先前存在网页的修改和新页面的创建。按照这种方式，网页可适合在具有不同商务规则的多个国家使用。有利的一点是前端接口11很容易更新和维护。更改商业逻辑组件不影响前端接口的所有组件，并且更新接口不需要重新启动服务器22。

如图4所示，开户系统10的后端接口13从被保护的服务环29中得到账号。被保护的服务环29包括一个预先分配的账号表33，后端接口13可以从表33中给客户分配账号。数据库中预先分配的账号范围是唯一的，因为账户库系统将不分配预先分配范围中的号码，从而确保账户库系统17不会分配重复的号码。预先分配账号表33每周7天每天24小时存在于被保护的服务环29中。最好从账户库系统17中获得账号的分类，用于开户系统10在周期性的基础上，例如每年两次，进行存储和分配。

如图3和图4所示，后端接口13位于通过防火墙41与前端接口11交互的应用层上。后端接口准备传送给后端系统14的帐户信息，并且当后端系统之一不可用时执行存储和转发(高速缓存)功能。后端接口包括账户请求处理机28，用于通过接收来自servlet 21中的RMI消息并将这些消息发送给其他系统来处理账户请求。

账户请求处理机28包括消息处理机30、高速缓存监视器31和web消息路由器47。消息处理机30接收来自账户请求处理机28的请求，并且对后端系统14制定适当的主机消息的格式。需要重申的是，消息处理机30为适当的后端系统14翻译那些请求。翻译使得单独的后端系统可以读取那些消息，那些单独的后端系统可能是独立开发，并因此具有彼此不同并且和开户系统不同的消息格式和使用习惯。

如图1所示，消息处理机30把消息传递给作为路由系统40的一部分的web消息路由器47。web消息路由器47接收从消息处理机30发送的消息并把这些消息发送到路由系统40的其他部分，然后等候来自路由系统其他部分的消息响应。路由系统的剩余部分包括客户消息服务器(CMS)39、客户自动化管理系统(CAMS)35和在线客户接入系统(OCAS)34。路由系统40在开户系统10和后端系统14之间路由消息。虽然优选实施例中使用了几个路由系统，但是这些路由系统可以集成在一个处理开户系统10和后端系统14之间的所有消息的单独路由系统中。另外，路由系统40可以整个地或者部分地集成到开户系统10中。

消息处理机30在一组消息创建和发送规则中操作，以便确定是否应该立即把消息发送到后端系统14或者发送到包含账户消息高速缓存87、账号库33和监视器状态文件54的数据库36。例如，消息创建和发送规则包含来自类库32的主机有效时间、预定停机时间和超时参数。类库包含用于后端系统14的消息格式制定规则48、用于后端系统的停机时间表38、消息注册函数、数据库连接函数、脉动(heart beat)类49、配置数据类50和注册器类55。脉动类49定义在规定时间间隔检查数据库36的一个函数，以寻找需要重发的高速缓存消息。配置数据类50包含开户系统10的各种配置，例如消息发送超时时间间隔、消息再试的最大数目、数据库连接参数、脉动时间间隔、数据库主机名、服务器地址、后端系统主机、RMI端口号码和配置信息、注册文件名称和系统默认值。注册器类55被用来把应用消息写入日志文件。

高速缓存监视器31检查数据库36中高速缓存的消息的状态。成功发送的消息可从数据库中删除并写入成功日志文件51中。超过每个配置数据类50的最大再试数量的消息可从数据库36删除并写入失败日志文件52中。高速缓存监视器31运行一个上载线程53，它处理仍然“在进行中”的那些消息，也就是那些既没失败也没有成功发送的消息。

后端接口13在把客户信息提交给后端系统14之前通过把信息提交给核实系统27来预先核实客户地址信息。预先核实客户信息确保高速缓存的消息稍后不会被包括在后端系统14中的核实系统所拒绝。在客户15已经退出该系统不能再改正客户信息时，消息被拒绝尤其会成为问题。优选地，后端接口执行的预先核实至少与后端系统14执行的核实一样严格。在图示的实施例中，后端接口13使用XML地址核实器作为核实系统27的一部分来预先核实客户的地址信息，例如街道名称、市、州和邮编组合。与核实系统27的通信经由可扩展标记语言(XML)来执行。或者，还可以用核实系统27核实其它类型的信息，例如确保客户15信用价的信用报告数据。

如图5和图6所示，后端接口13也可以与开户应用监视器37交互，或者可以包括开户应用监视器37。开户监视器37被用来监视开户系统和外部系统。一般来说，监视器37指示系统之一存在通信问题或非计划的断电的时间。例如，开户监视器37监视地址核实器27、开户请求处理机28和servlet21的有效性。开户监视器37还核实通过路由系统40与后端系统14的通信以及与用户登录和验证系统24的通信。另外，对高速缓存监视器31还进行监视，以便查看它是否正在运行，对有关数据库36的高速缓存大小进行监视，以便保证高速缓存中储存消息的空间。通过被保护的服务环29可用的有效账号范围由一个账号范围监视器90验证未使用数目。

监视器状态信息保持在储存在监视器中或数据库层36中存储的组件状态文件54中。当被监视的系统(或组件)之一关闭时，那么对应于系统或组件的状态列出在状态字段中。开户监视器37可以作为一个独立的监视器，也可以连接到Webmon应用63，Webmon应用63是监视例如跟踪以及互联网运输应用的一些其它应用的“状态板”或操纵台。系统故障引起告警，该告警执行一个应用CGI脚本，查找来自Webmon应用63的响应，该响应识别并隔离出现问题的组件、系统或子系统。

状态文件54还包括一个源组件名称字段，它消除了对单个故障的重复通知。例如，当一个系统关闭时，将随着关闭而列出同一系统的各部分，并且只发送一个故障通知。这允许对系统和子系统进行诊断和修复操作，例如重新启动系统。更新字段列出文件最后一次更新时的时间标记。唤醒间隔字段以毫秒为单位列出一个脉动线程的休眠时间。计划类型字段列出停机时间是计划的、非计划的还是脉动的。开始停机时间字段列出断电的起始时间。结束停机时间字段列出断电结束时间。消息字段列出在系统中发生的任何具体错误。

在监视过程中，开户监视器37将查阅类库32的停机时间表38，以便确定由于维护或其他原因的预定停机时间是否使任何后端系统14不可用。如图6所示，监视器37通过消息发送系统向一个或多个后端系统14发送查询消息(有时称为“ping”逻辑)。查询消息可以是发送给后端系统的一个简单查询。后端系统回复失败可能表明后端系统不可用，或者后端系统可以发送一个指示它不可用的回复。这则消息还可以包含为了到达后端系统14的一些子系统而制定格式后的消息，从而允许监视器确定后端系统是否完全可用或者部分可用。例如，可以由监视器发送由消息发送系统制定格式后的消息，并将这则消息发送到账户库系统17。查询消息包含制定格式后的信息，以便请求将要在账户库系统中得到验证的地址，从而允许账户库系统17或监视系统37确定账户库系统是否可用。这则查询消息还可以是警告信息，警告信息向后端系统及其子系统指示这则查询消息是一个测试，并不是一个需要完整处理和响应的典型消息。这则警告信息有利于防止后端系统14向开户系统发送假信息。

对于临时账户和每日账户，开户系统10响应后端系统14的故障或不可用是不同的。对于临时账户，账户库系统17不可用的通知触发开户系统10的客户通知，通知估计将来账号可用的时间，通常是在若干小时内。在预定停机的情况下，开户系统10列出从停机时间表38获取的停机时间。在非预定停机的情况下，开户系统列出一个预先确定的停机时间。对于每日账户，服务分配系统19核实客户和收取职员之间的每日收取时间的要求导致几天的延迟，因此不计算停机时间。基于调度计划开始日期经由向分配系统19提交的消息联系客户。当后端系统14可用时，把信息提交给后端系统，后端系统对应于分配的账号激活账户。作为选择，后端系统还可以确定并核实收取账户的收取时间表，并且分配一个启动包利用新开户的账户和账号来促进运输。

如图7A和图7B所示，在另一实施例中，本发明包括一种开户方法。如图7A所示，在步骤100，客户15登录到例如UPS.com之类的运输网站上，并且在步骤101被引入到承运方或运输服务提供商的开立运输账户的选项。在步骤102，对具体的客户运输需求进行查询，包括预期发货的数量和时间。而且，在步骤103询问客户是否要运输诸如危险的、高价值或易碎货物之类的特殊货物。如果希望运输特殊货物，则客户15被引入一个具有更好设置以处理专门的运输需求的替换服务系统，例如运输公司在1-800-PICK-UPS的在线座席。

如果不希望运输特殊货物，则用预期发货的数量和时间来计算计划发货的年费用。在步骤105，把年费与最小数量或边缘数量进行比较，例如每年运输费用是否计划低于1,000美元。如果低于边缘总值，在步骤106将客户引入推荐的信用卡计费服务，这是一种能降低成本的记帐方法。如果客户15选择忽略该建议，或者如果计划的发货年费超过最小总值，在步骤107推荐一个临时账户或者一个每日收取账户。具体地说，如果费用低于阈值，例如每年3,900美元，则建议使用临时账户，或者，如果计划费用超出阈值，则建议使用每日收取账户。在此使用的选定的边缘和阈值是示范性的，并且可以根据一些因素而调整，这些因素例如是价格通货膨胀、运输费用的变化或者希望支持不同开户类型等等。

客户15要么接受所推荐的账号类型，要么选择拒绝账户建议并选择另一账号类型。无论选择什么账号类型，都在步骤109收集有关客户收取位置的信息，并且在步骤110记录客户计费信息。如图7B所示，在步骤111核对、总结和显示计费信息、运输类型选择以及任何其它相关信息，以供客户15复查和校正。在复查之后，在步骤112例如通过确保计费住址有正确的邮编来预先核实客户信息，这里的预先核实最好比在激活一个账户之前由后端系统14执行的核实更严格。如果对客户信息的核实不成功，则在步骤111再次请求客户复查和更正信息，然后在步骤112再次尝试预先核实。如果对客户信息的核实成功，在步骤113给客户15分配并显示一个账号。

在步骤114，检查账户库系统17的有效性，如果不可用，在步骤115开户系统10给客户分配一个账号并通知客户可以使用该账号之前的延迟。从使用停机时间表38计划该延迟，或者如果是非预定的，则报告该延迟为一个预先确定的时间量，例如八天，这个时间量最好是保守估计值。如果已分配客户信息和账号，在步骤116当账户库系统17变成可用时存储和转发客户信息和账号。当账户库系统可用时，除非开户系统10已经分配了一个账号，否则在步骤117账户库系统给客户分配一个账号。如果账户是每日收取账户，在步骤118预定收取服务，并且通知客户15在账户可用之前计划的延迟，这里的延迟最好是直到第一个收取日的时间值。一旦已经分配账号，在步骤119，账户库系统17激活与该账号相应的账户并且给客户分配一个启动包。如上所述，然后在步骤120使用账号更新在客户配置文件系统25上存储账号的用户登录和验证系统24。使用客户配置文件信息和账号预置各种其他互联网运输应用，例如提供订单以及发送包裹订单系统。

在另一实施例中，本发明包括多个图形用户界面面板，这些面板最好是互联网网页形式，它们由前端接口11的servlet 21通过网络12发布并且显示在客户计算机20上。这里使用的术语“图形用户面板”是指任何计算机产生的图形图像或图像集合，例如计算机屏幕上的一个窗口、一个输入和输出字段的集合、整个网页或好几个网页的一部分。网页允许客户15与后端系统14通信以便与运输服务提供商建立一个运输账户。如图8至图17所示，开户系统分别包括首页64、运输需求页面65、联系页面68、账户类型页面69、服务费页面70、信用卡运输页面71、收取位置信息页面72、计费信息页面73、账号信息页面74和账号提供页面75。

利用开户系统10可以开立不同类型的运输账户，包括每日收取账户(又称为常规账户)，其中，没有特殊收取请求以及不论是否有包裹要发送时服务提供商在每个工作日都要去客户15处收取包裹。另一种类型的运输账户是临时账户(又称为按需账户或非常规账户)，其中，客户通过使用自助选项负责把包裹放入发货人的传送系统，例如在指定位置处放下包裹。对于临时账户服务提供商并不每天去收取。前端接口11根据客户15的计划运输需求和计划的账户每年运输收入计算来推荐客户使用每日收取账户还是临时账户。如果客户要求，本发明的开户系统10还可以开立其它类型的运输账户，例如进口账户。

如图8所示，首页64简要描述了开立运输账户必须完成的步骤。首页包括启动按钮66，客户15可以选择启动按钮66来继续开立运输账户的流程。如图9所示，运输需求网页65收集基本的运输信息，并且包括运输类型和频率字段67。客户通过指出他所希望每周(或每月)运送的地面、空中和国际包裹或信件的数量来填写多个运输类型和频率字段。前端接口11利用一个全年收入额方程计算出客户一年的估计运输费用，该方程基于每天、每周或其它时间预订的运输服务的数量和类型来计划每年的运输费用。运输需求页面65还包括运输异常事件选择77，用于让客户指示危险物和昂贵、易碎货物的运输，或者客户将作为经授权的运输出口。如果客户指示一个例外，客户将会被导向到联系页面68。如图10所示，联系页面包括联系信息(例如免费的电话号码)，该联络信息允许顾客联络运输服务提供商以便提供更客户化的账户来满足他们的运输需要。

如果没有指明运输异常情况，将使用全年收入额计算的结果在账户类型页面69上建议一个节约成本的账户类型。通过把所建议的账户设置为默认选择，账户类型页面将列出所建议的账户：每日收取账户或者临时收取账户。如果所计划的一年运输费用大于每年的选定总值，那么推荐每日收取账户。如果运输费用总量超出最小值但低于每年的选定总值，那么推荐临时账户。如图11所示，对于运输费用低于每年最小总值的，通过把客户引导到信用卡运输页面71来推荐使用信用卡支付每一包裹的费用，从而建议一种更能节约成本的替代选项。

如图12所示，在账户类型页面69上提供有和每日收取和临时运输账户的附加信息有关的信息，以帮助客户选择。如图13所示，如果客户选择每日收取账户，则客户被引导到服务费页面70，它按照客户每周运输开支比例列出每日收取服务的周服务费。虽然推荐了具体的账户类型，但是客户仍然可以选择去选定一个非推荐类型的账户。

如果客户从账户类型页面69选择每日账户，则显示收取位置信息页面72，否则对于临时账户显示计费信息页面。如图14所示，收取位置页面包括多个收取位置字段78，对于开立每日收取账户而言必须完成这些字段。为了方便顾客，可以使用已经提交给源互联网站点的用户登录和验证系统24的信息或者在客户配置文件系统(CPS)25上找到的信息来预置计费和收取位置字段。客户可以改写预置字段。优选地，收取位置字段请求与收取点、收取起始日期、每日截止时间、公司名称、联系名称和称号、包括街道地址、城市、州和邮政编码在内的地址、电子邮件地址和本地电话号码有关的客户信息。如图15所示，把客户导向计费信息页面73。对于所有账户类型都必须完成计费信息页面，计费信息页面包括多个计费信息字段76。优选地，计费信息字段请求与公司名称、联系名称和头衔、地址、电子邮件地址和公司电话号码有关的客户信息。或者，当选择临时账户时，收取位置信息页面72还可以用来收集收取信息。

如图16所示，在账号信息页面74上向客户显示客户信息的概要。如果需要，在提交信息之前账号信息页面允许客户编辑客户信息。一旦提交，如上所述，使用地址核实器27检查客户数据的有效性并且向后端系统14提交开户请求。如果后端系统和其它必要的系统可用，那么通过发布账号来实时填充账户请求。如果一个系统或一些系统不可用，则把账户请求消息高速缓存在数据库36上，用于高速缓存监视器31监视并稍后转发。如图17所示，不管怎样，在账号提供(“谢谢您页面”)页面75上和该账户有效的日期和/或时间一起发布该账号。有利的是账号可以用于诸如地面、空中或国际运输之类的所有传送类型。具体地说，每日收取和临时账户允许客户运送地面、空中和国际发货。在大多数情况下，临时类型运输账户数目可以立即使用。

另一方面，可以通过电话服务中心16访问开户系统10。电话服务中心的服务人员通过电话接受来自客户15的开户请求并提交该开户请求。在这种情况下，服务人员把客户传送的信息输入开户系统10中并实时获取客户账号。

开户系统10具有优于现有技术的一些优点。从客户观点看，因为可通过互联网访问开户系统，所以开户系统很方便并且易于使用。而且，开户系统可以立即实时提供账号。开户系统有利地自动对客户请求包括启动包在内的提供材料以及与账户相关的客户服务。在运输账户的情况下，给客户提供可用于地面和空中发货的单个账号。该账号对于某些类型的账户发货可立即有效，并且如果不能立即可用，客户也知道该账户何时可用于发货。

对于帐户提供商而言，开户系统10也具有一些优点。开户系统避免了专门输入数据以及协调后端系统14使用的职员开支。由于客户把他们自己的数据输入到图形用户界面，因此避免了数据输入差错。在电话服务中心16的情况下，开户系统协调后端系统14的使用，将开户中的差错和延迟减到最少。即使在后端系统关闭时也仍然可以许可账号，从而减少了在后端系统有效性的预定或非预定中断期间失去客户。上面列出的该开户系统的优点能吸引愿意使用传统系统之外的附加客户，从而能增加账户预订数目。

图1至图17是根据本发明的方法、系统和程序产品的框图、流程图和控制流程图示。应该理解，可以通过计算机程序指令来实现框图、流程图和控制流程图示的每一模块或步骤，以及框图、流程图和控制流程图示中模块的组合。这些计算机程序指令可以载入到计算机或其它可编程设备上以便产生一个机器，从而在计算机或其它可编程设备上执行的指令创建用于执行框图、流程图或控制流程模块或步骤中规定功能的装置。这些计算机程序指令也可以储存在计算机可读存储器中，计算机可读存储器能够使计算机或其它可编程设备以特定的方式工作，这样储存在计算机可读存储器中的指令产生包括实现在框图、流程图或控制流程模块或步骤中规定的功能的指令装置的产品。计算机程序指令也可以装载到计算机或其它可编程装置上，以便产生将要在计算机或其它可编程装置上执行的一系列操作步骤，以产生由计算机执行的处理，从而在计算机或其它可编程设备上执行的指令提供用于实现框图、流程图或控制流程模块或步骤中规定工作的步骤。

因此，框图、流程图或控制流程图示的模块或步骤支持用于执行规定功能的装置组合、用于执行规定功能的步骤组合以及用于执行规定功能的程序指令装置。还应该理解，通过专用基于硬件的计算机系统可以实现框图、流程图或控制流程图示的每一模块或步骤以及框图、流程图或控制流程图示中的模块或步骤的组合，专用基于硬件的计算机系统执行专用硬件和计算机指令的规定功能或步骤或者它们的组合。

对本领域技术人员来说很容易想到本发明的许多修改和其它实施例，对他们而言本发明包含了前述说明书和相关附图中表示的示范作用。因此，应该理解本发明不局限于所公开的特定实施例，而应该认为修改和其它实施例包含在附加权利要求的范围之内。虽然本文使用了具体的术语，但是它们只是一般性的描述，并不用于限制本发明。

Claims (38)

1.一种便于客户用来开立账户的系统，所述开户系统包括：

客户查询系统，用于提示客户提交客户信息和开户请求，所述查询系统进一步用于记录提交的客户信息和开户请求；

预先核实系统，用于从客户查询系统接收客户信息，并核实客户信息是否完全正确以便允许激活账户；

账号发布系统，用于响应于客户信息的核实分配并发布用来识别账户的账号；和

高速缓存系统，它能够在账户激活系统不可用时接收并存储开户请求、账号和经核实的客户信息，并且还能够在账户激活系统可用时向账户激活系统发送开户请求、账号和经核实的客户信息。

2.如权利要求1所述的开户系统，其中账号发布系统包括一个唯一的从中分配并发布账号的账号库。

3.如权利要求1所述的开户系统，进一步包括账户推荐系统，用于基于账户使用信息提出一个账户类型建议，其中客户查询系统还用于向客户提示该账户使用信息以及记录客户提交的账户使用信息。

4.如权利要求3所述的开户系统，其中账户类型建议是对客户而言最节约成本的账户类型。

5.如权利要求1所述的开户系统，进一步包括监视系统，用于确定账户激活系统不可用的时间，并且能够与高速缓存系统通信。

6.一种通过向后端系统提交开户请求便于客户开户的系统，所述开户系统包括：

客户查询接口，具有用于收集客户信息的客户信息字段和用于记录开户请求的账户请求字段；

预先核实系统，用于接收客户信息并核实客户信息是否完全正确以允许激活账户；

路由系统，它能够响应于客户信息的核实制定开户请求和客户信息的格式，并且将开户请求和客户信息发送到后端系统；

监视系统，用于确定后端系统不可用的时间；和

高速缓存系统，它能够在后端系统不可用时接收并存储开户请求和客户信息，以便在后端系统可用时通过路由系统向后端系统重新提交开户请求和客户信息。

7.如权利要求6所述的开户系统，进一步包括账号发布系统，用于响应于客户信息的核实分配和发布用来识别账户的账号。

8.如权利要求7所述的开户系统，其中账号发布系统进一步用于在后端系统不可用时分配并发布账号。

9.如权利要求8所述的开户系统，其中账号发布系统包括一个唯一的从中分配并发布账号的账号库。

10.如权利要求9所述的开户系统，其中账号库能够从后端系统中定期接收附加唯一账号的列表。

11.如权利要求6所述的开户系统，其中监视系统进一步用于通过路由系统向后端系统发送查询消息，并且基于后端系统对查询消息的响应确定后端系统的可用性。

12.如权利要求11所述的开户系统，其中查询消息包含具有制定的格式以便到达后端系统的一些子系统的信息，以便确定子系统的可用性。

13.如权利要求12所述的开户系统，其中子系统之一是后端系统的账户库系统。

14.如权利要求6所述的开户系统，其中监视系统用于查阅列出后端系统预计划不可用的停机时间表。

15.一种通过后端系统便于开立客户运输账户的系统，所述开户系统包括：

前端接口，包括能够在客户计算机上产生多个图形用户界面面板的servlet，所述图形用户界面面板包括：

账户类型选择面板，用于记录客户选定的运输账户类型；

客户信息面板，用于记录客户提交的有关客户的信息；和

账号提供面板，用于向客户报告与客户运输账户相关的账号；和后端接口，包括：

预先核实系统，用于核实客户信息是否完全正确，以便允许后端系统激活该运输账户；

账号发布系统，用于响应于客户信息的核实从唯一账号库中分配账号并且把账号发送给账号提供面板；和

路由系统，它能够制定账户类型选择、账号和客户信息的格式，并且把它们发送给后端系统，从而允许后端系统激活与账户类型选择和账号相应的运输账户；并且

所述后端系统包括：高速缓存系统，该高速缓存系统能够在后端系统不可用时接收并存储账户类型选择、账号和客户信息用于在稍后后端系统可用时发送给后端系统。

16.如权利要求15所述的开户系统，其中图形用户界面面板进一步包括运输需求面板和账户推荐面板，运输需求面板用于记录客户输入的有关预期运输类型和频率的信息，而账户推荐面板用于基于运输需求信息推荐账户类型。

17.如权利要求16所述的开户系统，其中有关预期运输类型和频率的信息包括地面、空中和国际运输需求。

18.如权利要求15所述的开户系统，其中后端系统进一步包括监视系统，该监视系统用于确定后端系统不可用的时间。

19.如权利要求15所述的开户系统，其中账号可用于地面运输和空中运输。

20.如权利要求15所述的开户系统，其中账号可用于地面、空中和国际运输。

21.如权利要求15所述的开户系统，其中运输账户类型包括临时账户和周期收取帐户中的一个。

22.如权利要求21所述的开户系统，其中当账户类型选择是周期收取账户时，路由系统进一步用于把账号和客户信息路由到服务分配系统。

23.如权利要求21所述的开户系统，其中路由系统进一步用于把账号和客户信息路由给供应系统以提供一个启动包。

24.一种通过后端系统便于客户开户的方法，所述开户方法包括：

记录有关客户的信息；

记录开户请求；

预先核实客户信息以确保客户信息完全正确，以便允许后端系统激活该账户；

监视后端系统以便确定后端系统的可用性；

当后端系统不可用时发布与该账户相关的唯一账号；和

当后端系统可用时把开户请求、客户信息和账号路由到后端系统，以便允许后端系统激活与账户类型选择和账号相应的运输账户。

25.如权利要求24所述的开户方法，进一步包括：在把客户信息和账号路由到后端系统之前，在后端系统不可用时高速缓存账号和顾客信息。

26.如权利要求24所述的开户方法，其中监视包括向后端系统发送查询消息，并基于对该查询消息的响应来确定后端系统的可用性。

27.如权利要求24所述的开户方法，其中发布账号包括从唯一账号库中发布账号。

28.如权利要求27所述的开户方法，进一步包括监视唯一账号库的使用。

29.如权利要求28所述的开户方法，进一步包括在账号库使用完后通过从后端系统获取附加唯一账号来补充唯一账号库。

30.如权利要求24所述的开户方法，其中监视包括查阅列出预计划的后端系统不可用的停机时间表。

31.如权利要求24所述的开户方法，其中记录开户请求包括记录开立运输账户的请求。

32.如权利要求31所述的开户方法，进一步包括记录客户的运输需求信息，并且在记录开户请求之前基于运输需求信息推荐一个运输账号类型。

33.如权利要求32所述的开户方法，其中记录运输需求信息包括记录运输类型和频率。

34.如权利要求33所述的开户方法，其中记录运输需求信息包括记录地面和空中运输需求。

35.如权利要求33所述的开户方法，其中记录运输需求信息包括记录地面、空中和国际运输需求。

36.如权利要求33所述的开户方法，其中推荐运输账号类型包括推荐临时账户和周期收取账户中的一个。

37.如权利要求36所述的开户方法，其中路由开户请求进一步包括路由用于建立服务分配系统的收取时间表的请求。

38.如权利要求36所述的开户方法，其中路由开户请求进一步包括由供应系统路由向客户发送启动包的请求。

Images