CN105849760A

CN105849760A - 用于访问控制和系统整合的系统

Info

Publication number: CN105849760A
Application number: CN201480058275.9A
Authority: CN
Inventors: 罗德尼·肯尼斯·德鲁里; 马修·约翰·维克斯
Original assignee: Canon Inc
Current assignee: Canon Inc
Priority date: 2013-09-23
Filing date: 2014-09-23
Publication date: 2016-08-10
Anticipated expiration: 2034-09-23
Also published as: US10181162B2; US20150088707A1; WO2015042605A1; US20230385953A1; EP3050019A1; AU2023274173A1; EP3050019A4; US11030706B2; US20230325940A1; CA2925483A1; US20150379646A1; MY180325A; AU2014324112B2; AU2020223724B2; AU2021286434A1; SG11201602154YA; AU2020223724A1; CA2925483C; US20230325941A1; US11783433B2

Abstract

根据一种示例实施方式的自动提供使得交互客户能够建立账务软件系统与其金融机构之间的连接。这可以通过下述操作来实现：使得金融机构客户能够进行选择，以使来自其银行账户的它们的提要对于(例如，由客户的金融机构托管和操作的)金融互联网软件内的账务软件系统是可用的。当客户选择其想要与账务软件系统共享的银行账户时，它们被传递至账务软件系统，以将所选择的银行账户与他们已经在账务软件系统中设立的账户进行链接。

Description

用于访问控制和系统整合的系统

本申请要求于2013年9月23日提交的美国临时专利申请No.61/881,314的优先权，该美国临时专利申请的全部内容通过引用合并到本文中。

技术领域

本公开内容总体上涉及促进计算机系统之间的访问，并且更具体地涉及用于访问控制和系统整合的系统和方法。

背景技术

账务系统的用户通过将数据手动地输入至账务系统中来从他们的金融账户导入数据。替选地，用户可以从保持金融账户的金融机构下载数据，并且然后将其上传至账务系统中。

账务系统的用户通过与他们的金融账户进行交互或书写支票来支付账单。在完成支付之后，针对用户的账务数据被手动地更新，以表示支付了账单并且从中支取付款的账户余额减少了。

附图说明

通过附图的各个图中的非限制性示例的方式来示出一些实施方式。

图1是描绘根据一些实施方式的示例单账簿账务平台的框图。

图2是描绘根据一些实施方式的针对账务平台的示例账务应用框架的框图。

图3是描绘根据一些实施方式的针对账务平台的示例托管架构的框图。

图4是描绘根据一些实施方式的账务平台的示例数据中心系统的框图。

图5是描绘根据一些实施方式的用于访问账务平台的示例客户端设备的框图。

图6是描绘根据一些实施方式的用于账务平台的示例应用服务器的框图。

图7是描绘根据一些实施方式的用于与账务平台交互的示例银行服务器的框图。

图8是描绘根据一些实施方式的显示由银行的用户可访问的账户的示例用户接口的接口图。

图9是描绘根据一些实施方式的用于登录至账务平台中的示例用户接口的接口图。

图10是描绘根据一些实施方式的用于使得银行提要能够进入账务平台中的示例用户接口的接口图。

图11是描绘根据一些实施方式的用于使得银行提要能够进入账务平台中的示例用户接口的接口图。

图12是描绘根据一些实施方式的用于使得银行提要能够进入账务平台中的示例用户接口的接口图。

图13是描绘根据一些实施方式的用于通过账务平台提交批量支付的示例用户接口的接口图。

图14是描绘根据一些实施方式的用于通过账务平台提交批量支付的示例用户接口的接口图。

图15是描绘根据一些实施方式的用于通过账务平台提交批量支付的示例用户接口的接口图。

图16是描绘根据一些实施方式的用于通过账务平台提交批量支付的示例用户接口的接口图。

图17是描绘根据一些实施方式的用于银行平台与账务平台之间的交互的示例数据流的框图。

图18是根据一些实施方式的用于访问控制和系统整合的示例方法的流程图。

图19是根据一些实施方式的用于访问控制和系统整合的示例方法的流程图。

图20是根据一些实施方式的用于访问控制和系统整合的示例方法的流程图。

图21是根据一些实施方式的用于访问控制和系统整合的示例方法的流程图。

图22是根据一些实施方式的以计算机系统的示例形式的机器的框图，在该计算机系统内可以执行指令集合以使该机器执行本文中讨论的方法中的任一种或更多种。

具体实施方式

描述了用于促进不同的计算机系统之间的访问的示例系统和方法。在以下描述中，出于说明的目的，阐述了多个具体细节以提供对示例实施方式的透彻理解。然而，对于本领域技术人员将明显的是，可以在没有这些具体细节的情况下对本技术进行实践。

在本文中描述了在以下情景中的示例技术：向账务计算机系统提供对第三方金融计算机系统的访问。还将意识到的是，出于许多其它目的，所描述的技术可以被部署在其它环境中。

在本文中描述的一种示例实施方式使得能够访问第一计算机系统(例如，对使得可用于小企业客户的在线账务软件进行托管)和第二计算机系统(例如，对金融软件进行托管)，并且在第一计算机系统与第二计算机系统之间提供服务。

在线账务软件可以向小企业客户提供以下能力：通过访问安全的在线网站并且查看和更新他们的数据来在云内管理他们的账户。这样的客户还可以邀请可信顾问——例如，会计员、簿记员、他们的银行管理员和/或他们的企业伙伴——进入他们的账户。由于数据在云中且在一组可信个体之间共享，所以提供了单个账簿：可以由企业所有者及其会计员访问的一个单个的账户集合。因此，当会计员做出调整或者公布报告时，企业所有者可以访问该报告。当企业所有者核对他们的金融报表行并且创建账务交易时，会计员可以查看更新。会计员与企业所有者二者均具有对企业的健康的实时可视性。

为了使账务软件提供最新的金融报告，可能需要最新的金融数据。本申请描述了下述示例系统和方法，通过所述示例系统和方法保持企业的金融数据的金融机构可以为了他们的客户的利益而经由自动配置来与账务软件系统(例如，托管的在线账务软件解决方案)共享该金融数据。想要将交易性金融服务与由账务软件系统提供的企业平台更紧密地整合的金融机构可以得益于所描述的系统。示例实施方式可以寻求使账务软件与金融机构的服务更紧密地结合在一起，因为金融服务和账务服务是互补性活动。

图1是描绘示例单账簿账务系统100的框图。单账簿账务系统100可以向特定实体提供账务工具，以管理针对一个或更多个企业的账务。示例单账簿账务系统100可以包括实践工作室110和组织机构访问模块150，实践工作室110使得实体能够管理一个或更多个企业，组织机构访问模块150向企业提供用于针对该特定企业来管理账务数据的工具。实践工作室110可以包括实践配置文件管理模块112、实践员工管理模块114、在线培训模块116、实践管理模块118、伙伴资源模块120、报告包建立模块122以及工作文件模块124。实践工作室110、核心特征130和组织机构访问模块150保持通信(例如，经由函数调用、API或直接整合)。核心特征130可以包括账务和工资单模块132、社区模块134、账单/订购管理模块136、通知中心模块138、用户配置文件管理模块140以及分析模块142。实践工作室110和核心特征130可以由实体使用登录模块(未示出)来访问。

如图1中所示，基于目标用户将系统100的特征划分成三个区。实践工作室110的特征向会计员提供一套工具，以与他们的客户端进行交互并且管理他们的实践。核心特征130提供会计员和企业二者共用的核心功能和用户工具。组织机构访问模块150提供用于各个企业访问他们的数据的用户接口。

实践工作室110是针对会计员的中心登录。例如，具有多个客户端的会计员可以使用实践工作室110来登录并且得以访问针对客户端的账务数据、来自客户端的消息等，其中，多个客户端中的每个客户端是小企业。

实践配置文件管理模块112使得账务实践能够管理和查看其配置文件设置。例如，账务实践可以具有伙伴级别，该伙伴级别表示该账户实践与针对账务平台的提供者的关系的强度。该伙伴级别可以基于账务平台中与账务实践相关联的客户端的数目。例如，铜伙伴级别可以被分配给具有至少5个客户端的账务实践，银伙伴级别可以被分配给具有至少20个客户端的账务实践，并且金伙伴级别可以被分配给具有至少100个客户端的账务实践。替选地或附加地，账务实践可以具有由账务平台提供的一个或更多个证书。证书可以基于在线测试的完成来自动地提供，并且可以在预定周期(例如一年)已经过去之后届满。其它配置文件设置可以包括账务实践的名称、地址、电话号码、电子邮件地址等。

实践员工管理模块114向账务实践的管理者提供控制针对实践的员工的设置的能力。例如，一些员工可以具有对某些客户端的数据的只读访问，一些员工可以具有对某些客户端的读写访问，一些员工可能能够修改对其它员工的访问权限等。

在线培训模块116提供针对会计员及其员工的培训。在一些情况下，所提供的培训包括一个或更多个视频演示和一个或更多个在线测试。可以提供在培训完成时通过测试的通知。例如，员工可以接受培训课程，并且当成功完成时，监督员工的会计员可以接收成功完成的通知。

实践管理模块118提供针对会计员的服务。对由实践管理模块118提供的特征的访问可以被限制于与账务平台提供者具有预定伙伴级别的会计员。例如，对实践管理模块118的访问可以被限制于处于银级别或以上的会计员。由实践管理模块118提供的服务可以包括工作流工具、客户关系管理(CRM)工具、潜在客户生成工具、职业管理工具、发票生成工具等。

伙伴资源模块120提供关于第三方伙伴的信息。例如，第三方可以提供与系统100交互的工具，以提供超过系统100单独的功能的有用功能。用户可以访问伙伴资源模块120来学习可用的第三方工具。例如，至第三方网站的链接、文档、视频和搜索工具均可以被提供。

报告包建立模块122提供工具，以使得会计员能够创建并且生成标准化的报告集合。例如，损益表和季度报告二者均可以被添加至包。然后，会计员能够容易地生成针对任一所选客户端的两种报告或者生成针对每个客户端的报告。

工作文件模块124向会计员提供交互性地创建金融报告的工具。例如，会计员可以将针对客户端的已知数据输入工作文件中，并且然后将具有客户端所需的数据的指示的该工作文件发送至该客户端。在客户端将丢失数据输入工作文件之后，会计员可以完成该报告。

核心特征130包括由会计员和组织机构二者使用的模块。账务和工资单模块132向组织机构提供通用账簿。通用账簿可以整合有组织机构的工资单，以绕开在每个支付期间将工资单数据输入通用账簿的独立步骤。账务和工资单模块132访问针对每个客户端企业的银行数据。银行数据可以通过银行提要或者通过用户创建的文档或会计员创建的文档来导入。账务和工资单模块132还可以经由应用编程接口(API)与第三方工具进行通信。

社区模块134提供论坛，用户可以通过该论坛进行通信。例如，有问题的用户可以在论坛中发布话题，并且随后接收来自另一用户的有帮助的响应。取自用户配置文件(例如，经由用户配置文件管理模块140所管理的用户配置文件)的信息可以与用户的论坛发帖一起出现。例如，用户名称、用户的图像以及作为会计员或组织机构的成员的用户的身份均可以被示出。

账单/订购管理模块136使得用户能够使用系统100对每个组织机构的一个或更多个账单账户进行配置。系统100可以周期性地收取访问的订购费用(例如，月度订购或年度订购)。订购费用可以根据一个或更多个账单账户来自动地扣除。

通知中心模块138向用户提供通知。例如，用户可以相互发送呈现为通知的消息。通知还可以由系统100(例如，通过账务和工资单模块132)基于事件来创建。例如，可以由用户经由账务和工资单模块132来设置针对特定银行账户的最低账户余额。当针对该银行账户的余额降至最低账户余额以下时，可以由系统100生成通知以告知用户。

用户配置文件管理模块140使得用户能够基于权限设置来管理用户的组织机构的配置文件以及其它的配置文件。例如，会计员可以具有管理会计员的客户端的配置文件的权限。配置文件可以包括面向公众的信息，例如企业名称和地址。

登录模块(例如，经由用户名称和口令)对登录进系统100中的用户的身份进行验证。基于用户的身份，呈现包括用户可以访问的组织机构的列表的用户接口。对于大多数小企业客户端，列表将由单个组织机构组成。

分析模块142对来自不同组织机构的数据进行分析和关联。例如，可以根据组织机构集合来生成针对特定关键绩效指标的基准，并且将其与针对另一组织机构的关键绩效指标进行比较。从比较产生的结果可以被呈现给组织机构的代表、组织机构的会计员、组织机构的审计员或其它的关注方。

组织机构访问模块150访问针对单个组织机构的核心特征130。组织机构访问模块150在由登录模块进行用户验证之后呈现以下用户接口，其具有针对单个组织机构的选项，而不具有仅由实践工作室110使用的另外的特征。

图2是描绘针对账务平台的示例账务应用框架200的框图。账务应用框架200可以是能够启用“软件即服务”(SaaS)产品的端到端web开发框架。账务应用框架200可以包括超文本标记语言(HTML)和/或JavaScript层210、ASP.Net模型视图控制器(MVC)220、可扩展样式表语言转换(XSLT)230、结构240、服务250、对象相关模型260和数据库270。

HTML和/或JavaScript层210提供客户端侧功能，例如UI生成、对用户输入的接收以及与服务器的通信。客户端侧代码可以由ASP.NETMVC 220或XSLT 230动态地创建。替选地，可以使用另一服务器侧工具来静态地或动态地创建客户端侧代码。

ASP.Net MVC 220或XSLT 230提供服务器侧功能，例如，数据处理、web页面生成以及与客户端的通信。还可以使用其它服务器侧技术与数据库270进行交互，并且创建针对用户的体验。

结构240提供中转机构，数据通过该中转机构被处理并且被呈现给用户。例如，ASP.Net MVC 220或XSLT 230可以访问结构240，以确定数据的期望格式。基于结构240，生成用于数据的呈现的客户端侧代码。所生成的客户端侧代码和用于呈现的数据被发送至客户端，然后客户端呈现该数据。

服务250提供可重用工具，该可重用工具可以由ASP.Net MVC 220、XSLT 230和结构240使用，以访问存储在数据库270中的数据。例如，可以使得通过对存储在数据库270中的原始数据进行操作的计算所生成的综合数据由服务250可访问。

对象关系模型260提供可由软件使用以对存储在数据库270中的数据进行操纵的数据结构。例如，数据库270可以通过将多个行(其中，每一行具有共同的值)存储在表格中来表示多对一关系。相比之下，软件可能偏好访问作为数组的数据，其中，数组是与共同值对应的对象的成员。因此，对象相关模型260可以当软件访问多个行时将多个行转换成数组，并且当数据被存储时执行逆转换。

图3是描绘用于账务平台的示例托管架构300的框图。该平台可以使用一个或更多个荚310来实现。每个荚310包括特定于该荚310的应用服务器虚拟机(VM)320(其被示出为图3中的应用服务器虚拟机320A-320C)以及在荚310之间共享的应用服务器虚拟机320(例如，内部服务VM 330和应用编程接口VM 340)。应用服务器虚拟机320A-320C经由web接口或API与客户端和第三方应用进行通信。由应用管理程序350来监视应用服务器虚拟机320A-320C。在一些示例实施方式中，应用服务器虚拟机320A-320C以及API VM 340是公众可访问的，而内部服务VM 330不能由托管架构300外部的机器访问。应用服务器VM 320A-320C可以经由应用或web接口提供用户端服务。内部服务VM 330可以向应用服务器VM 320A-320C提供后端工具，向应用管理程序350提供监视工具或者提供其它内部服务。API VM 340可以将编程接口提供给第三方。第三方可以使用编程接口来构建依赖于由荚310提供的特征的另外的工具。

内部防火墙360确保在数据库管理程序370与公众可访问的虚拟机320-340之间仅允许被许可的通信。数据库管理程序370监视基本的结构化查询语言(SQL)服务器380A和380B。基本SQL服务器380A和380B访问所共享的存储层450A或450B(在图4中所示)，以读取和写入由应用服务器虚拟机320-340生成或使用的数据。冗余SQL服务器390A和390B分别向基本SQL服务器380A和380B提供备用功能。

可以使用Windows 2008R2、Windows 2012或另外的操作系统来实现虚拟机320-340。可以使用冗余的备用件来构造支持虚拟机320-340的应用和支持服务器。可以跨多个荚310来共享支持服务器。应用管理程序350、内部防火墙360和数据库管理程序370可以在数据中心内扩展多个荚310。在一些示例实施方式中，每个基本SQL服务器380和冗余SQL服务器390被配置成支持30,000-45,000个组织机构。因此，在每个荚310使用两个这样的服务器对的实施方式中，荚容量是60,000-90,000个组织机构。冗余SQL服务器390可以利用SQL2012的“永远在线”回弹特性。

图4是描绘通过网络与其它系统进行交互的账务平台的示例数据中心系统400的框图。初级数据中心410针对客户请求进行服务，并且被复制到次级数据中心420。可以使次级数据中心420在线，以在初级数据中心410故障的情况下针对客户请求进行服务。初级数据中心410通过网络455与银行服务器460、第三方服务器470、客户端设备480以及客户端设备490进行通信。银行服务器460提供银行数据(例如，经由银行应用465)。第三方服务器470正在运行第三方应用475。客户端设备480和490分别使用web客户端485和编程客户端495与初级数据中心410进行交互。

在每个数据中心410和420内，示出了多个荚，例如图3的荚310。初级数据中心410被示出为包含荚440A-440D。次级数据中心420被示出为包含荚440E-440H。运行在初级数据中心410的荚上的应用被复制到次级数据中心420的荚。例如，与VMWare站点恢复管理器(SRM)结合的EMC复制(由EMC公司提供)可以被用于应用层复制。数据库层对初级数据中心410的存储装置450A与次级数据中心420的存储装置450B之间的复制进行处理。数据库复制提供数据库一致性以及确保所有数据库270在相同时间点处的能力。

数据中心410和420分别使用负载平衡器430A和430B，以对每个数据中心内的荚上的负载进行平衡。可以使用相同的硬件来创建数据中心410和420，以确保次级数据中心420的性能与初级数据中心410的性能相同。可以使用一个或更多个EMC VNX存储局域网来实现存储装置450。

银行服务器460与初级数据中心410交互，以向客户端的银行账户提供银行记录。例如，客户端可以向初级数据中心410提供账户凭据，该初级数据中心410使用该账户凭据来得以访问客户端的账户信息。银行服务器460可以向初级数据中心410提供银行记录，以随后通过客户端使用客户端设备480或490来进行复制。

第三方服务器470可以与初级数据中心410和客户端设备480或490交互，以向客户端设备480或490的用户提供另外的特征。例如，用户可以对第三方服务器470进行授权，以对存储在初级数据中心410中的用户数据进行访问。第三方服务器470的第三方应用475可以使用用户数据来生成报告、提供宏或以其它方式提高用户访问或操纵用户数据的能力。第三方应用475可以使用API经由网络455与初级数据中心410进行通信。第三方应用475可以使用web或编程接口与客户端设备480或490进行通信。

图5是示出根据一些示例实施方式的适用于访问控制和系统整合的客户端设备480或490的部件的框图500。客户端设备480或490被示出为包括被配置成彼此进行通信(例如，经由总线、共享存储器或开关)的通信模块510、显示模块520、输入模块530以及支付模块540。

通信模块510可以与初级数据中心410、银行服务器460、第三方服务器470、网络455或其任何适当组合进行通信。可以经由显示模块520来呈现(例如，在显示设备上显示)经由通信模块510接收的信息。可以选择信息或者可以由客户端设备480或490的用户输入搜索查询。

由显示模块520呈现用户接口。由输入模块530检测来自用户的输入。可以由通信模块510将由输入模块530从用户接收的命令传送至初级数据中心410或银行服务器460。通信模块510可以从初级数据中心410或银行服务器460接收响应，该响应包括以任何组合形式的银行记录的集合、企业记录的集合、各个银行记录与各个企业记录之间的指示那些记录之间的协调的关联以及其它数据。

支付模块540可以生成对初级数据中心410的请求，以支付账单或批量账单。该请求可以通过网络455经由通信模块510被传送至初级数据中心410。

图6是示出根据一些示例实施方式的适用于访问控制和系统整合的应用服务器VM320A的部件的框图600。应用服务器VM 320A被示出为包括被配置成彼此通信(例如经由总线、共享存储器或开关)的通信模块610、密码模块620、提要模块630、支付模块640和存储模块650。

通信模块610可以与客户端设备480或490、银行服务器460、第三方服务器470、网络455或其任何适当组合进行通信。经由通信模块610接收的信息可以经由存储模块650进行存储，或者由其它模块620-640进一步处理。

密码模块620可以在由通信模块610进行传输之前对通信进行加密，在由通信模块610进行接收之后对通信进行解密，对由存储模块650存储的数据进行加密或解密或者以其它方式执行密码功能。

提要模块630可以对从银行服务器(例如，银行服务器460)接收的银行提要进行处理。例如，提要数据可以包括关于提供银行的特定账户上的交易的信息。使用数据库，账务应用的用户的相应簿记账户可以被标识并且被更新，以反映包括在提要中的交易。

支付模块640可以对经由通信模块610从用户接收的支付请求进行处理。例如，可以使用数据库对与对其作出支付请求的簿记账户对应的银行账户进行识别。该请求可以被发送至银行服务器460，以完成所请求的交易。簿记数据还可以被更新以反映存储模块640中的交易，从而经由通信模块610将该簿记数据传送至用户。

存储模块650向应用服务器VM 320提供数据存储访问。例如，该存储装置可以由闪速存储器、硬盘驱动器、网络存储器或另外的存储介质来提供，并且经由存储模块650来与该存储装置对接。

图7是示出根据一些示例实施方式的适用于访问控制和系统整合的银行服务器460的部件的框图700。银行服务器460被示出为包括被配置成彼此通信(例如，经由总线、共享存储器或开关)的通信模块710、密码模块720、提要模块730、支付模块740以及存储模块750。

通信模块710可以与客户端设备480或490、应用服务器VM 320、第三方服务器470、网络455或其任何适当组合进行通信。经由通信模块710所接收的信息可以经由存储模块750进行存储或者由密码模块720、提要模块730或支付模块740进一步处理。

密码模块720可以在由通信模块710进行传输之前对通信进行加密，在由通信模块710进行接收之后对通信进行解密，对由存储模块750存储的数据进行加密或解密或者以其它方式执行密码功能。

提要模块730可以生成针对账务服务器(例如，应用服务器VM 320)的银行提要。例如，提要数据可以包括关于由账户持有者所授权并且由账务应用所请求的特定账户上的交易的信息。

支付模块740可以对经由通信模块710从账务应用接收的支付请求进行处理。例如，所接收的通信可以由密码模块720进行解密，并且然后由支付模块740进行验证和处理，以完成所请求的交易(例如，通过使用存储模块750来更新合适的记录，使用通信模块710与其它金融机构进行通信，或者所述二者)。

存储模块750提供针对银行服务器460的数据存储访问。例如，存储装置可以由闪速存储器、硬盘驱动器、网络存储器或另外的存储介质来提供，并且经由存储模块750来与该存储装置对接。

图8是描绘根据一些实施方式的显示由银行的用户可访问的账户的示例用户接口(UI)800的接口图。UI 800包括具有关于不同账户的信息的数据的各个行855A-855E，并且可以被统称为行855。类似地，行855中的单独一行可以被称为行855。可以由客户端设备480或490的显示模块520向访问银行服务器460的用户显示UI 800。

元素810示出了提供用户接口的银行的名称。元素810-835包括菜单栏，可操作该菜单栏以用于查看用户的各个账户或由银行提供的特征。例如，标记为“外汇交易”的元素835可以被操作用于向用户示出由银行提供的各种外汇交易服务。

元素840是搜索工具。元素840可以被操作用于搜索银行网站、搜索用户的账户和交易或上述二者。

元素845是向用户示出关于当前屏幕的信息的文本框。在该情况下，元素845指示用户可以创建针对示例账务应用Xero的银行提要。

元素850包含标题，该标题是针对在该标题以下所示出的行855A-855E中的数据的列。表格中的每一行855包括账户号码和两个复选框。复选框可被操作用于选择和取消选择将针对账户的提要发送至账务服务的选项(在中间列中示出)，以及使得能够通过账务服务在账户上支取账单支付的选项(在最右边的列中示出)。例如，行855C示出了20-2054-0864243-10的账户号码并且已经选中了两个复选框，其指示提要应当被提供至账务服务并且将允许在该账户上的账单支付。相比之下，行855E仅选中了第一框，其指示虽然将提供银行提要，但是不允许账单支付。

元素860可被操作用于接受使用行855A-855E中的复选框所选择的提要设置。如图8中所示，元素860可被操作用于使针对所有的五个所显示的账户来发送提要，并且允许在所述账户中的两个账户上的账单支付。

图9是描绘根据一些实施方式的用于登录进账务平台中的示例用户接口900的接口图。可以由客户端设备480或490的显示模块520向访问应用服务器VM 320的用户显示UI900。元素910向用户显示提示、标题或应用标识符。类似地，分别读取“电子邮件”和“口令”的元素920和940提示用户在文本域930和950中输入相应信息。标记为“登录”的元素960可被操作用于向账务平台提交被输入至文本域930和950中的电子邮件和口令信息。如果所输入的信息为正确，则账务平台使得用户能够访问与用户相关联的账户的信息(例如，由于用户具有访问数据的合适的安全权限)。

图10是描绘根据一些实施方式的用于使银行提要进入账务平台的示例用户接口1000的接口图。行1060A-1060E是具有关于不同账户的信息的数据的各个行，并且可以被统称为行1060。类似地，行1060中的单独一行可以被称为行1060。可以由客户端设备480或490的显示模块520向访问应用服务器VM 320的用户显示UI 1000。

元素1010指示账务平台的名称，并且可被操作用于返回至主页或针对账务应用的主屏幕。标记为“退出”的元素1020可被操作用于使用户退出账务平台。元素1030和1040向用户提供关于当前屏幕的信息。

元素1050指示在表格中的行1060中的每行中所示的数据的类型。因此，行1060中的每行示出了金融机构处的账户的账户号码、持有该账户的组织机构、与该金融账户对应的账务应用的簿记账户、是否在该账户上启用账单支付以及该账户的当前状态。在图10中，账单支付被启用或被禁用，并且每个账户的状态是被连接或未被分配。另外的状态选项在各种实施方式中可以是可用的。行1060A-1060C示出了代替针对行1060的组织机构和簿记账户二者的名称的下拉式菜单。该下拉式菜单可被操作用于分别选择对用户为可用的组织机构和账户。例如，如果用户是若干个企业的会计员，则组织机构下拉式菜单可以被预先填充有该用户是会计员的企业。

标记有“连接”的元素1070可被操作用于连接用户已经选择了合适的信息的任何账户。例如，如果用户正在选择针对未分配的账户的组织机构和簿记账户二者，则激活元素1070使未分配的账户成为已分配或已连接。标记为“取消”的元素1080可被操作用于取消任何做出的改变。

图11是描绘根据一些实施方式的用于使银行提要进入账务平台的示例用户接口1100的接口图。相对于图10以上描述了元素1010-1050、行1060C-1060E、元素1070以及元素1080。可以在用户已经选择了针对UI1000中的行1060A和1060B的组织机构和簿记账务之后示出图11的UI。

行1160A和1160B示出了已经通过填充相应下拉式菜单的选择区而选择了组织机构和簿记账户。因此，行1160A和1160B的状态列现在示出“就绪”，其指示元素1070的操作将使得做出连接账户的尝试。

图12是描绘根据一些实施方式的用于使银行提要进入账务平台的示例用户接口1200的接口图。可以在用户启用UI 1100中的元素1070以使得一个或更多个银行账户被连接至账务平台之后示出UI 1200。相对于图10以上描述了元素1010-1050、行1060C-1060E以及元素1070。

行1260A和1260B通过指示图11中的行1160A和1160B的状态为已连接来示出与这两行中所示的账户连接的尝试已成功。另外地，行1260A示出了已经启用账单支付。

元素1270向用户告知来自新构建的提要的信息应当在24小时内出现。在一些实施方式中，立即检索初始提要。

图13是描绘根据一些实施方式的用于通过账务平台来提交批量支付的示例用户接口1300的接口图。行1380A-1380D可以统称为行1380。类似地，行1380中的单独一行可以称为行1380。可以由客户端设备480或490的显示模块520来向访问应用服务器VM 320的用户显示UI 1300。

元素1300对示出了批量支付屏幕的组织机构进行识别。元素1315可被操作用于退出账务平台。元素1320和1325示出了关于当前所显示的屏幕的信息。具体地，它们示出了用户正在与账务平台中的账户进行交互，并且利用那些账户来支付账单。

元素1330可被操作用于将新的账单添加至账务系统中。例如，点击元素1330、在触摸屏上触摸或以其它方式与元素1330进行交互可以使得UI窗口出现提示用户输入针对新的账单的数据。

元素1335可被操作用于将新的贷记单添加至账务系统中。例如，点击元素1335、在触摸屏上触摸或以其它方式与元素1335进行交互可以使得UI窗口出现提示用户输入针对新的贷记单的数据。

元素1340可被操作用于将一个或更多个记录导入账务系统中。例如，点击元素1340、在触摸屏上触摸或以其它方式与元素1340进行交互可以使得UI窗口出现提示用户输入包含要导入的记录的文件的文件名称。

元素1345示出了各种预定义搜索选项。每个搜索选项可被操作用于(例如，作为超级链接)使包含行1380的下面的表格更新，以仅示出符合所选择的搜索选项的账单。所示出的搜索选项是：“所有”，其与示出针对在元素1310中所示的组织机构的所有账单的搜索对应；“草稿”，其与示出未完成账单的搜索对应；“等待许可”，其与示出已经完成但尚未由组织机构的合适成员(例如，CFO)许可的账单的搜索对应；“等待支付”，其与示出准备要支付的账单的搜索对应；“已支付”，其与示出已经支付的账单的搜索对应；以及“重复”，其与示出周期性反复出现的账单的搜索对应。附加地，在元素1345中示出的搜索选项中的一个或更多个搜索选项可以指示与该搜索选项对应的结果的数目。例如，标记为“等待支付”的搜索选项指示11个搜索结果是可用的。

元素1350可被操作用于打印当前所显示的账单的报告。元素1355可被操作用于生成账单集合的批量支付。元素1360可被操作用于安排支付以用于未来执行。元素1365将账单的总数目及其总量连同计价币种一起显示。元素1370可被操作用于通过指定标准来搜索账单。元素1350、1355、1360和1370中的每个可以使相应UI被呈现，以收集来自用户的输入供执行元素的功能时使用。

元素1375是示出包含在行1380中的每一行中的数据的首行。因此，行1380中的每行示出了下述内容中的一个或更多个：针对账单的参考标识符；发送了账单的实体的名称；生成了账单的日期或接收到账单的日期；账单到期的日期；账单被安排支付的计划日期；已经支付的账单的量；以及仍未完成的账单的量。在各种实施方式中，可以示出更多、更少或不同的列。

图14是描绘根据一些实施方式的用于通过账务平台来提交批量支付的示例用户接口1400的接口图。以上相对于图13描述了元素1310-1375和行1380A-1380D。可以在用户已经与UI 1300的标记为“批量支付”的元素1355进行交互之后示出UI 1400。

元素1410是响应于元素1355的操作而呈现的弹出式窗口。呈现了弹出式窗口中的三个选项。支票支付选项可被操作用于创建和打印支票，批量支付选项可被操作用于创建可以被上传至用户的银行的具有支付信息的文件，并且取消选项可被操作用于关闭弹出式窗口并且取消批量支付。

图15是描绘根据一些实施方式的用于通过账务平台来提交批量支付的示例用户接口1500的接口图。以上相对于图13描述了元素1310-1320。行1570A-1570C可以统称为行1570。类似地，行1570A-1570C中的单独一行可以称为行1565。可以在从图14的元素1410中选择生成支票或支付文件的选项中的一个之后示出图15的UI 1500。

元素1510结合元素1320向用户告知正在查看的当前屏幕。在该情况下，用户正在创建新的批量支付，以利用用户的账户中的一个或更多个账户针对购买进行支付。

元素1515和1525是分别与选择器1520和1530对应的表头。选择器1520可被操作用于选择将对批量进行支付的支付日期。例如，选择器1520可以使用日历选择器、文本输入域或另外的方法来实现。选择器1530可被操作用于选择将对批量进行支付的银行账户。例如，选择器1530可以使用预填充有账务平台已知的银行账户的下拉式列表来实现。

元素1535、1545和1555分别对应于文本输入域1540、1550和1560。文本输入域1540、1550和1560可被操作用于针对批量中的每个支付来输入详情(域1540)、代码值(域1550)和参考值(域1560)。在各种实施方式中，详情、代码和参考值可以被预先填充、从下拉式列表中选择或以其它方式来选择。详情、代码和参考值可以具有对组织机构、金融机构、收款人或另一方的意义。

元素1565包含针对由行1570所填充的表格的表头。行1570中的每一行包括下述内容中的一个或更多个：收款人的名称；针对账单的参考；账单的到期日期；将作出针对账单的支付的银行账户；应付总额；以及支付量。行1570中的每行还包括可被操作用于从批量中去除行、在UI 1500中被示出为包含“x”的框的元素。元素1575向用户告知在批量中被支付的总量。

元素1580可被操作用于使用所选的选项来做出支付。例如，可以创建由所示的三个账单组成的批量。元素1585可被操作用于取消批量支付。例如，与元素1585的交互可以使用户返回至UI 1300。

图16是描绘根据一些实施方式的用于通过账务平台来提交批量支付的示例用户接口1600的接口图。以上相对于图13描述了元素1310-1375以及行1380A-1380D。可以在使用图15的UI 1500提交了批量之后示出图16的UI 1600。元素1610示出了确认消息，其指示已经提交了批量支付。

图17是描绘根据一些实施方式的用于在银行平台与账务平台之间的交互的示例数据流的框图1700。

用户(未示出)与网上银行UI 1710进行交互，以选择一个或更多个账户来与账务服务提供者共享。网上银行UI 1710将用户重定向至账务服务UI 1720。账务服务UI 1720对用户进行认证，并且将用户的簿记账户与网上银行服务处的银行账户进行链接。账务服务UI 1720还与账务服务后台1740进行通信，以存储账户链接数据。账务服务后台1740使用私有银行API 1730与银行进行通信。由私有银行API 1730提供的特征包括更新针对银行账户的注册、进行从所注册的银行账户支取的第三方支付以及其它服务。银行文件交付1750基于经由私有银行API 1730对账户的注册、经由批量文件交付将针对所注册的账户的银行记录提要提供给账务服务文件邮箱1760。账务服务文件邮箱1760将所接收的批量文件提供给账务服务后台1740，账务服务后台1740对批量进行处理，以生成针对与所接收的提要文件中的报告交易对应的簿记账户的记录。下面更详细地讨论示例过程的另外的细节。

金融服务的概述

根据一个示例，提供了用于自动地构建至银行账户的链接以及提供多个互补性服务的方法和系统。示例方法和系统可以包括三个部分，这三个部分称为：

●经由网上银行自动地提供账户。

●由账务软件系统经由私有应用编程接口(API)调用银行提供的服务。●经由安全传输来传送文件数据(例如，账户提要服务)

根据一个示例实施方式的自动提供使得交互客户能够建立账务软件系统与金融机构之间的连接。这可以通过以下来实现：使得金融机构客户能够选择，以使得来自他们的银行账户的他们的提要可用于金融因特网软件内的(例如，由客户的金融机构托管和操作的)账务软件系统。当客户选择他们想要与账务软件系统共享的银行账户时，它们被传递至账务软件系统，以将所选择的银行账户与他们已经在账务软件系统中建立的账户进行链接。

当这些账户被连接时，账务软件系统将经由私有API向金融机构注册提要，并且请求要包括在周期性数据提要(例如，夜间提要)中的数据。

如果所连接的账户支持上述服务，并且客户已经请求了该服务，则客户还可以将支付指令从账务软件系统传递回到金融机构的网上银行软件以用于授权。由网上银行软件提供的各种服务可以与账务软件系统连接。

自动提供

根据示例实施方式的自动提供可以包括多个功能，其中的两个功能是：

●启用/禁用金融机构账户上的服务，以与账务软件系统一起使用。

●针对账务软件系统中的账户来管理(例如，映射)金融机构账户。

启用是用户在网上银行软件内标识他们想要与账务软件系统共享的他们的银行账户的处理。所有账户可以默认被禁用。可以要求在线服务的已认证用户明确地启用要与账务软件系统一起使用的账户，并且可选地选择他们想要使用的任何另外的服务。例如，可以使用UI 800来启用账户。

当账户被启用时，与该账户有关的报表数据被标记为等待对账务软件系统的批量检索，其随后将由“UpdateRegistration”服务进行确认，进一步的细节将在下面提供。

当金融机构账户被启用时，该金融机构账户然后可以被连接。针对账务软件系统帐户的服务未被完全启用，直到金融机构账户被连接并且提要注册被确认为止。

已认证网上银行用户可以选择连接一个或更多个已启用账户。由此，用户被重定向至账务软件系统，该账户软件系统将请求用户向账务软件系统进行认证(例如，通过使用UI 900)。在认证之后，用户可以被请求选择他们想要将账务软件系统的哪个簿记账户与他们的金融机构的银行账户连接(例如，如图17中所示)。

当具有提要服务的银行账户连接至账务软件系统账户时，账务软件系统将调用“UpdateRegistration”服务。服务对账户进行注册，从而使得针对该账户的最新数据能够按计划被检索并且经由提要被加载至账务软件系统账户。账务软件系统对来自金融机构的提要数据进行处理，以创建单账簿账务系统中的相应条目。

当提供第三方支付服务的银行账户连接至账务软件系统帐户时，可以使用第三方支付服务将批量支付直接提交至银行，以用于来自该账户的许可。

根据一个示例实施方式的账户启用是用于针对金融机构账户来分配可用账务软件系统服务的方法。所有账户可以默认被禁用。

单个方法UpdateASServices可以采用所请求的账务系统(AS)服务和账户的映射，并且针对所有用户的账户来更新活跃的AS服务。该方法(UpdateASServices)更新针对用户的金融机构账户的集合所启用的AS服务。例如，在金融系统服务器上执行UpdateASServices可以使针对用户账户中的每个的数据传输至请求AS。数据可以是增量的(例如，仅反映自上次数据传输之后的改变)或完整的。启用可以发生在金融机构的服务平台内。已认证在线服务用户可以改变他们的金融机构账户的启用状态。

用户被呈现有在他们的在线服务中可用的账户的列表。每个账户具有用户可以针对每个账户而启用的可用服务的列表。取决于哪个账户能够支持提要或批量支付，定期存款可以不具有可用的服务，信用卡可以具有可用的账户提要服务，并且当前账户可以具有可用的账户提要服务和第三方支付服务。

在对针对账户的服务做出改变时，被请求以针对账户和服务而启用的账户与服务的映射被发布至服务器。如果存在在数据可以被共享之前可以被约定的条款和条件，则可以在改变被提交之前获得这样的约定。

还在当将账户连接至账务软件系统账户时，启用创建或分配用于所有服务的针对账户的唯一标识符(例如，AccountID)。AccountID被保证是唯一的并且是持续的，并且针对给定账户始终是相同的(例如，即使其被断开连接并且被重新连接)。AccountID可以被包括在交易的提要中，并且在支付批量文件的格式中可以被允许作为主关键字。AccountID可以为金融机构中已经在使用的标识符(包括账户号码)，但是出于安全考虑不推荐使用信用卡号码或敏感信息作为AccountID。

可以由金融机构认证的用户通过访问所呈现的账户来执行启用。已启用的AS服务的新映射可以针对用户的账户列表来保存，该新的映射是分配新的AS服务并且禁用已经被去除的AS服务。

除非服务在账户的可用AS服务内被列出，否则不针对账户来启用那些服务。如果账户已经添加有的账户提要服务作为更新的一部分，则其被标记为等待包括在夜间批量文件中。如果账户已经去除了账户提要服务作为更新的一部分，则其从批量文件中被去除。如果这是首次启用账户，则分配或生成唯一的AccountID。

账户连接和断开连接被移交至账务软件系统来完成。例如，可以经由通过用户从在线金融软件内所触发的HTTPS POST来完成向账务软件系统的传递。

在实施方式中，在线金融客户点击提交并且对表单发布进行拦截，AJAX请求检索加密表单中的以上信息，并且将其插入表单的变量中，然后该表单被发布。为了完成连接或断开连接，用户利用有效用户账户向账务软件系统进行认证。

接下来描述以下格式，根据示例实施方式，当对账户提要进行初始化或管理时，经由用户的浏览器从金融机构传递至账务软件系统的数据的格式。

所传递的数据可以从金融机构被发送至账务软件系统。数据可以经由用户的web浏览器客户端作为包含在JavaScript对象表示法(JSON)数据结构中加密的、签名二进制大对象(BLOB)而被传递。

金融机构对包含关于用户已经选择连接至账务软件系统的银行账户的信息的数据的BLOB(例如，下面更为详细地讨论的AccountMapMessage)进行组装。该BLOB将包含唯一标识符、账户号码、余额以及其它敏感信息，并且因此该BLOB可以被加密，以使得内部的数据对传递该BLOB的客户端浏览器是不透明的。

可以通过首先对该数据进行加密并且然后生成针对该加密数据的消息认证码(MAC)来传递AccountMapMessage数据。这可以称为“加密然后MAC”。例如，随机地生成对称密钥，并且将其用于对AccountMapMessage数据进行加密。发送数据的金融机构具有账务软件系统的RSA公钥，金融机构使用RSA公钥对对称密钥进行加密。接收数据的账务软件系统使用其RSA私钥来对对称密钥进行解密，并且转而使用对称密钥对消息进行解密。

金融机构具有RSA私钥，金融机构使用RSA私钥对发送至账务软件系统的消息进行签名。账务软件系统使用金融机构的RSA公钥来验证签名是有效的。在示例实施方式中，可以使用各种密码算法，例如用于对称加密的高级加密标准(AES)、用于非对称加密的RSA算法(以Ron Rivest、Adi Shamir和Leonard Adleman命名)以及用于签名的安全哈希算法(SHA)RSA-SHA2。

针对在系统中生成和使用的密钥，可以指定最小密钥尺寸。例如，AES或SHA密钥可以为至少256位，并且RSA密钥可以为至少2048位。密码系统可以使用随机数和初始化向量值。随机数是针对特定消息使用一次并且然后被丢弃的值。随机数生成算法可以确保随机数在利用相同时间戳发送的消息中是唯一的，在来自相同方的消息中是唯一的，或者使用另一个标准来选择随机数。在一个示例实施方式中，生成随机的随机数并且将其与先前使用的值进行比较。如果随机数是可接受的，则使用该随机数。如果随机数不是可接受的，则生成新的随机的随机数并且重复该处理。

初始化向量是密码系统的输入。通常，随机地生成初始化向量。在一些示例实施方式中，使用随机数作为初始化向量生成算法的输入来生成初始化向量。

可以从密码安全随机数发生器生成随机数和初始化向量。这确保了对称加密将是强壮的，并且防止针对消息中的加密数据字节的暴力攻击。当由金融机构执行随机数和初始化向量的生成时，账务软件系统可以请求对所使用的方法的确认，以确认生成处理是足够随机的。

例如，多个默认随机数发生器并非是在密码学上安全的。作为替代，可以选择密码安全算法(例如，在C#中，应当使用System.Security.Cryptography.RandomNumberGenerator类，而不使用System.Random类)。

可以由金融机构使用以实现所讨论的密码特征的示例数据结构包括：

可以由账务软件使用以实现所讨论的密码特征的示例数据结构包括：

金融机构可以使用以下示例算法对消息进行封装，以由账务软件系统接收。在下面的伪代码中，对包含敏感数据的JSON AccountMapMessage进行加密和签名，然后将所产生的MessageContainer作为JSON数据结构经由用户的浏览器发送至账务软件系统。

PlainTextDataString＝ Base64Encode(AccountMapMessage)

IVBytes＝ GenerateRandomIV()

EncryptedIV＝ RSAEncrypt(IVBytes,X_PubKey)

RandomKeyBytes＝ GenerateRandomKey()

EncryptedRandomKey＝ RSAEncrypt(RandomKeyBytes,X_PubKey)

EncryptedDataBytes＝ AESEncrypt(PlainTextDataString,

RandomKeyBytes,IVBytes)

SignatureBytes＝ CalculateSHA2Signature(

EncryptedIV+EncryptedRandomKey+

EncryptedDataBytes,

FI_PrivKey)

MessageContainer.PC＝ "PROVIDER/BANKXYZ"

MessageContainer.EIV＝ Base64Encode(EncryptedIV)

MessageContainer.ERK＝ Base64Encode(EncryptedRandomKey)

MessageContainer.Data＝ Base64Encode(EncryptedDataBytes)

MessageContainer.S＝ Base64Encode(SignatureBytes)

MessageContainer.SM＝ "RSA-SHA2"

可以如下来执行在由账务软件系统接收消息时对消息进行验证和解封装。当从金融机构接收消息时，账务软件系统可以对消息进行解密和解封装以确保其来自金融机构，并且尚未被篡改。可以使用示出为伪代码的以下算法来对MessageContainer进行解封装并且接收AccountMapMessage。

EncryptedIV＝ Base64Decode(MessageContainer.EIV)

EncryptedRandomKey＝ Base64Decode(MessageContainer.ERK)

EncryptedDataBytes＝ Base64Decode(MessageContainer.Data)

SignatureBytes＝ Base64Decode(MessageContainer.S)

(Check MessageContainer.SM＝＝"RSA-SHA2")

VerifySignatureBytes＝ CalculateSHA2Signature(

EncryptedIV+EncryptedRandomKey+

EncryptedDataBytes,

FI_PubKey)

(Check VerifySignatureBytes＝＝SignatureBytes)

IVBytes＝ RSADecrypt(EncryptedIV,X_PrivKey)

RandomKeyBytes＝ RSADecrypt(EncryptedRandomKey,

X_PrivKey)

PlainTextDataString＝ AESDecrypt(EncryptedDataBytes,

RandomKeyBytes,IVBytes)

AccountMapMessage＝ Base64Decode(PlainTextDataString)

账务软件系统然后可以对AccountMapMessage的内部进行验证，以检查其是否具有完整性。验证消息的来源可以通过验证CheckAccountMapMessage.ProviderID与MessageContainer.PC匹配来执行。验证消息是当前的可以通过验证TimeStampUTC在有效消息的容限内并且消息尚未过期来执行。验证消息并非重放尝试可以通过验证配对(TimeStampUTC，Nonce)尚未用于该提供者来执行。可以执行对消息内容的其它验证。

如果所有这些验证和解封装操作已成功，则向用户示出使他们能够继续在账务软件系统内的启用处理的屏幕。

可以实现上述消息加密和封装，以使消息能够通过不可信通信机构(例如，经由用户的浏览器通过互联网)从金融机构传递至账务软件系统。

加密和签名可以提供如下保证：消息由金融机构合法生成，在传送中未被篡改或查看，并且无法被重放。金融机构还可以确保仅账务软件系统能够对数据进行解密。下面更详细地讨论各种安全威胁。

电子欺骗：由于使用在账务软件系统与金融机构之间共享的公钥/私钥对，所以除金融机构之外的任何人不可能生成有效消息。

否认：金融机构使用它们的私钥对数据进行签名，该私钥保持保密并且仅由它们持有。当账务软件系统接收消息并且使用金融机构的公钥来检查签名时，它们可以确保金融机构原始生成了消息。

篡改：签名检查还防止在传送中的篡改。如果IV、密钥或数据被修改，则签名检查将失败。

信息公开：AccountMapMessage可以包含一些敏感信息，例如银行账户余额或账户号码。这使用一次性使用的加密密钥来进行加密。该加密密钥在消息中被发送，而使用账务软件系统的公钥对其进行非对称地加密，仅账务软件系统可以对其进行解密。

重放：通过时间戳和随机值来防止重放攻击，其使得账务软件系统能够保证其将仅接收和处理给定的消息一次。如果具有相同的时间戳和随机数的消息到达，则账务软件系统将拒绝该消息。

中间人攻击：攻击者可以在合法用户能够获取所生成的JSON之前从金融机构截获所生成的JSON，并且将其转发至账户软件系统。这通在用户浏览器中使用的防止客户端侧上的MiTM的SSL/TLS连接并且使用针对消息时间戳的短的届满时间来缓解。由于用户在消息生成与向账务软件系统的即时POST之间不需要执行任何动作，所以届满时间可以被保持较短。

拒绝服务攻击：该协议不提供针对拒绝服务攻击的保护，攻击者能够向账务软件系统端点发送大的畸形的或大量的消息并且招致高成本的签名检查或解密处理处理发生。这将通过使用账务软件系统的标准暴力检测机制来缓解。

特权提升：从金融机构传递至账务软件系统的消息不会将特权从一个环境传达至另一环境。用户仍需要独立地向金融机构的站点和账务软件系统二者进行认证。

由金融机构提供的数据可以指示针对用户的每个金融账户的账户类型。例如，可以使用下面的C#类来实现账户类型指示器。类似地，可以使用下面的JSON示例来指示账户是当前账户。

由金融机构提供的数据可以指示针对用户的每个金融账户提供的一个或更多个服务。例如，可以使用下面的C#类来实现服务类型指示器。类似地，可以使用下面的JSON示例来指示账户提要服务和第三方支付服务二者均可用于该账户。

存储在AS系统处的数据可以反映关于金融机构处的金融账户的信息，该信息包括针对该金融账户可用的服务。下面是可以用在C#类中以存储这样的账户特定数据的数据类型和对值的描述的表格。

另外的示例数据类型是AccountMapMessage，其包含指示要从金融机构被发送至账务软件系统的已启用账户的完整消息。

另一个示例数据类型是MessageContainer，其包含从金融机构经由用户的浏览器被发送至账务软件系统的消息。每个Byte[]在当呈现为JSON时被发送为Base64编码字符串。

(Base64编码值被省略)

当已经将用户从金融机构重定向至账务软件系统并且传递了合适的消息时，账务软件系统可以将每个AccountID与用户的账务软件系统账户相关联。如果账户被连接，则活跃AS服务被提供至该账户。

用户可以对已经连接的账户进行管理。在该情况下，他们可以被示出连接的状态并且能够在他们期望时将账户断开连接。如果账户被断开连接，则从该账户中去除活跃AS服务。

在实施方式中，在使得用户能够管理账户之前，对以下前提条件中的一个或更多个进行验证。

●向账务软件系统认证用户。

●对ProviderCode进行识别。

●可以用账务软件系统的私钥对随机密钥进行解密。

●可以用随机密钥对请求数据进行解密。

●用金融机构的公钥对签名进行验证。

●ProviderID是有效提供者。

●随机数之前尚未被使用。

●数据能够被解析并且所有所需要素被包括。

●具有活跃服务的至少一个AccountServiceMap被包括在ActiveAccountServiceMaps的列表中。

●时间戳在有效超时时段内。

私有金融API

为了使账务软件系统与金融机构共享服务，金融机构将多个服务暴露给账务软件系统。这些使得账务软件系统当由客户指示时能够执行针对金融机构的动作。还可以支持另外的服务。

金融机构可以实现接受JSON POST请求并且对其进行响应的小的web服务。下面是针对期望请求和响应的规范。

访问金融服务端点可以由VPN进行保密，并且仅可以由账务软件系统使用。针对服务的完整URL对于提供金融机构是唯一的，但是端点针对所有参与的金融机构可以是相同的。下面用每个服务来给出示例端点。

对于第三方支付，当金融机构账户已经被启用并且与第三方支付服务连接时，针对该账户的批量支付可以被提交至金融机构。如果账户具有针对该账户的第三方支付服务，则当账务软件系统用户创建批量支付作为他们对可支付的账户的管理的一部分时，他们具有将该批量直接提交给金融机构以进行授权和完成的选项。

表述性状态转移(REST)架构可以支持客户端与服务器之间的REST型接口。REST型接口可以是无状态的(例如，在请求之间客户端上下文可以不被存储在服务器上)。REST型接口可以是可缓存的(例如，来自服务器的响应可以指示它们是否是可缓存的)。客户端可以对可缓存响应进行缓存，从而减少了网络流量和延迟。REST型接口可以是分层的(例如，客户端可以连接至中间服务器而不是终端服务器)。REST型接口可以对在每个请求中涉及的资源进行识别，以便使得客户端能够修改其拥有的资源。此外，在无状态REST型接口中，每个REST消息可以是自包含的，并且包括足够的用于描述如何处理该消息的信息。一些客户端可以跟踪它们自身的状态，并且仅通过超媒体(例如，超级链接)来做出状态转移。

第三方支付请求可以是发布JSON消息并且期望JSON响应的REST型HTTP请求。下面提供了示例JSON请求和响应的格式。

第三方支付请求，即从用户的账户向第三方做出支付或批量支付的请求。由AS向金融机构做出该请求。

端点：/第三方支付

批量中的每一项描述单个交易。批量项的示例要素：

第三方支付请求的示例要素：

第三方支付响应，金融机构向第三方支付请求提供响应。

响应返回HTTP状态以报告请求的成功。如果存在服务器错误，则消息将包括JSON包，该JSON包包含错误消息的非空数组。批量应当被完全地处理，从而返回200状态，或者完全不被处理，从而返回500错误以及相关错误消息。

错误消息类型的示例要素：

更新注册请求，即在金融机构处的针对已经注册的账户的更新注册数据的请求。该请求由账务软件系统向金融机构做出。更新针对金融账户的注册数据可以包括：向银行注册针对账户的提要；将金融账户与相应账务软件系统账户断开连接；或者以其它方式改变账户的注册。

账户软件系统可以实现周期性工作，以在更新断开连接的账户的状态以示出它们已经被取消注册之前标识断开连接的账户并且验证它们满足某些标准(例如，它们已经断开连接的时段等)。请求可以被批量地提交。

端点：/更新注册

在批量请求中的每个项指示要更新的单个账户。用于更新单个账户的请求的示例要素：

更新注册请求的示例要素：

更新注册响应，即金融机构提供对更新注册请求的响应。另外地，当接收到注册请求或取消注册请求时，金融机构可以添加账户或从用在被提供至账务软件系统的提要中的账户的列表中去除账户。

更新注册请求可以被完全地处理，从而返回200状态；或者完全不被处理，从而返回500错误以及针对不能被注册或取消注册的账户的相关错误消息。

来自金融机构的错误响应的示例要素：

其它数据类型

下面的表格包含用在各种实施方式中的在账务服务和金融机构中的任一者或二者处的另外的数据类型。

下面的表格包含用在各种实施方式的在金融机构处的另外的数据。

下面的表格包含用在各种实施方式中的在账务系统处的另外的数据。

文件交付(账户提要服务)

报表数据的批量供应

金融机构可以批量地向账务软件系统提交数据。在实施方式中，金融系统在将针对账户的数据添加至该批量之前验证每个账户已经被启用、被注册和被确认。

金融机构可以通过安全文件传递协议(SFTP)经由周期性(例如，夜间)批量文件来发布针对所有活跃的且已确认的账户的最新交易。批量包含针对被标记为已启用的所有账户或其子集的报表数据。批量文件可以由AccountID作为关键字。如果账务软件系统遇到不识别的AccountID(例如，已启用但未连接的)，则数据被忽略。否则，数据被加载至与该AccountID相关联的账务软件系统账户中。账务软件系统对来自金融机构的提要数据进行处理，以在单账簿账务系统中创建相应条目。

图18是根据一些实施方式的针对访问控制和系统整合的示例方法1800的流程图。通过示例的方式，方法1800被描述为通过图5-7的系统和模块来实现。

应用服务器VM 320的通信模块610在操作1810中接收由用户经由金融系统提供的授权，以链接一个或更多个金融账户。例如，银行服务器460可以将web页面传送至客户端设备480或490，例如图8中所示的示例UI 800。使用UI，用户可以选择一个或更多个账户来与账务平台共享。在接收用户的选择之后，银行服务器460将授权发送至账务服务器。

在操作1820中，账务平台检索针对金融账户的金融数据。例如，银行服务器460可以使用提要模块730来生成包括针对金融账户的交易的文件，并且将该文件传递至应用服务器VM 320。应用服务器VM 320可以经由存储模块660将用于随后处理的提要数据存储在数据库或文件系统中。应用服务器VM 320的提要模块630然后可以从存储装置中检索针对金融账户的金融数据。在其它实施方式中，账务平台直接从金融机构中检索金融数据。

在操作1830中，提要模块630基于金融数据来生成针对簿记账户的数据。例如，金融数据中的交易可以示出在某日向实体的支付，并且可以生成针对簿记账户的相应交易。

图19是根据一些实施方式的用于访问控制和系统整合的示例方法1900的流程图。通过示例的方式，方法1900被描述为通过图5-7的系统和模块来实现。以上相对于图18描述了操作1810-1830。

账务平台在操作1910中对金融系统内的金融账户的金融数据的提要进行注册。例如，账务平台可以经由通信模块610使用利用密码模块620所处理的安全加密消息来发送数据被请求的金融账户的标识符。作为响应，银行服务器460可以验证用户拥有已经被提供了授权来与账务平台共享账户数据的金融账户。在确认授权之后，银行服务器接受注册，并且布置成将提要数据周期性地发送至账务平台。

账务平台从金融系统周期性地接收提要形式的金融账户数据(操作1920)，并且当接收到新的数据时生成针对相应簿记账户的另外的簿记数据(操作1930)。

图20是根据一些实施方式的用于访问控制和系统整合的示例方法2000的流程图。仅通过示例的方式，该方法被描述为通过图5-7的系统和模块来实现。以上相对于图18描述了操作1820和1830。

在操作2010中，应用服务器VM 320接收由用户经由金融系统提供的加密的授权以链接金融账户。例如，客户端设备480或490可以与银行服务器460建立连接，以对与账务平台共享账户数据进行授权。作为响应，银行服务器460可以对送往账务平台的消息进行加密，以向账务平台告知该账务平台已经被授权以接收针对金融账户的账户数据。应用服务器VM320可以使用密码模块620对消息进行解密，并且对源进行验证。

账务系统对用户进行授权(操作2020)。例如，UI 900可以由连接至初级数据中心410的web服务器的客户端设备480的显示模块520来呈现。用户授权可以包括用户名称和口令、生物数据或者以其它方式将用户标识为与被授权对金融账户数据进行链接的用户是相同。

账务系统接收与要同金融账户链接的用户相关联的簿记账户的标识(操作2030)。例如，UI 1000可以被呈现以使得用户能够选择簿记账户来与金融账户相关联。

图21是根据一些实施方式的用于访问控制和系统整合的示例方法2100的流程图。仅通过示例的方式，方法2100被描述为通过图5-7的系统和模块来实现。以上相对于图18描述了操作1810和1820。

账务服务提供者在操作2110中验证金融系统支持针对所链接的金融账户的第三方支付服务。这使得账务平台的用户能够经由金融系统向第三方提交单独支付或批量支付。

在操作2120中，由应用服务器VM 320将在金融账户上支取的批量支付提交给银行服务器460。例如，用户可以使用图13-16中所示的UI来选择账单集合以批量支付，并且应用服务器VM 320可以生成批量支付文件并且将批量支付文件自动地发送至银行服务器460。

银行服务器460对批量的支付进行处理，并且确定是否所有支付均已被成功处理。如果是，则银行服务器460向账务平台发送确认，账务平台接收(操作2130)该确认。如果任何支付未被成功处理，则所有交易被回滚，并且向账务平台提供错误消息。在该情况下，通过账务平台将错误消息示出给用户。

如果交易已成功完成，则更新与金融账户对应的簿记账户的数据(操作2140)，以示出交易完成。例如，可以在簿记账户中创建新的记录以示出该支付，可以将簿记账户的当前余额更新以反映交易，账单可以被标记为已支付等。

在本文中某些实施方式被描述为包括逻辑或多个部件、模块或机构。模块可以构成软件模块(例如，包含在机器可读介质上或包含在传输信号中的代码)或硬件模块。硬件模块是能够执行某些操作的有形单元，并且硬件模块可以以特定方式被配置或布置。在示例实施方式中，一个或更多个计算机系统(例如，单机的、客户端或服务器计算机系统)或计算机系统的一个或更多个硬件模块(例如，处理器或处理器群)可以由软件(例如，应用或应用部)配置为操作以执行如本文中所描述的某些操作的硬件模块。

在各种实施方式中，硬件模块可以被机械地或电子地实现。例如，硬件模块可以包括被永久配置成执行某些操作的专用电路或逻辑(例如，作为专用处理器，例如现场可编程门阵列(FPGA)或专用集成电路(ASIC))。硬件模块还可以包括由软件临时地配置成执行某些操作的可编程逻辑或电路(例如，如包含在通用处理器或其它可编程处理器内)。将意识到的是，可以通过成本和时间考虑来推动在专用的永久配置的电路中或在临时配置的电路(例如，由软件进行配置)中机械地实现硬件模块的决策。

因此，术语“硬件模块”应当被理解为包括有形实体，该有形实体是被物理构造、永久配置(例如，硬连线)或临时配置(例如，被编程)来以特定方式进行操作和/或执行本文中描述的某些操作的实体。考虑其中硬件模块被临时配置(例如，被编程)的实施方式，硬件模块中的每一个无需在任一时刻处均被配置或实例化。例如，在硬件模块包括使用软件进行配置的通用处理器的情况下，通用处理器可以在不同时间处被配置为各自不同的硬件模块。软件因此可以对处理器进行配置，以例如在一个时刻处构成特定硬件模块，并且在不同的时刻处构成不同的硬件模块。

硬件模块可以向其它硬件模块提供信息并且接收来自其它硬件模块的信息。因此，所描述的硬件模块可以被视为通信上耦接的。在同时存在多个这样的硬件模块的情况下，可以通过连接硬件模块的信号传输(例如，通过合适的电路和总线)来实现通信。在其中多个硬件模块在不同时间处被配置或实例化的实施方式中，可以例如通过将信息存储在多个硬件模块可以访问的存储器结构中并且在该存储器结构中检索信息来实现在这样的硬件模块之间的通信。例如，一个硬件模块可以执行操作，并且将该操作的输出存储在通信上耦接的存储器设备中。另外的硬件模块然后可以在随后的时间处访问存储器设备，以检索和处理所存储的输出。硬件模块还可以发起与输入或输出设备的通信，并且可以对资源进行操作(例如，信息的收集)。

在本文中描述的示例方法的各种操作可以至少部分地由临时地配置(例如，由软件)或永久地配置以执行相关操作的一个或更多个处理器来执行。不论是临时地被配置还是永久地被配置，这样的处理器可以构成操作以执行一个或更多个操作或功能的处理器实现的模块。在本文中所称的模块在一些示例实施方式中可以包括处理器实现的模块。

类似地，本文中描述的方法可以至少部分地是处理器实现的。例如，方法的操作中的至少一些操作可以由一个或更多个处理器或处理器实现的模块来执行。操作中的某些操作的执行可以被分布在一个或更多个处理器之中，所述一个或更多个处理器不仅可以驻留在单个机器内而且可以被部署成跨多个机器。在一些示例实施方式中，一个或更多个处理器可以位于单个位置中(例如，在家庭环境、办公室环境内或作为服务器形式)，而在其它实施方式中，处理器可以被分布成跨多个位置。

一个或更多个处理器还可以操作以支持在“云计算”环境中执行相关操作或者操作为“软件即服务”(SaaS)。例如，操作中的至少一些操作可以由计算机群(作为包括处理器的机器的示例)来执行，这些操作是经由网络(例如，因特网)以及经由一个或更多个合适接口(例如，应用程序接口)可访问的。

示例实施方式可以以数字电子电路或以计算机硬件、固件、软件或以它们的组合来实现。示例实施方式可以使用下述的计算机程序产品来实现，所述计算机程序产品例如为具体包含在信息载体中——例如在用于由诸如可编程处理器、计算机或多个计算机的数据处理装置执行或控制上述数据处理装置的操作的计算机可读介质中——的计算机程序。

计算机程序可以以包括编译语言或解释语言的任何形式的编程语言来编写，并且计算机程序可以被部署成包括作为单机程序或作为模块、子例程或适于用在计算机环境中的其它单元的任何形式。计算机程序可以被部署成在一个计算机上执行或者在多个计算机上执行，所述多个计算机处于一个站处或者被分布成跨多个站并且通过通信网络进行互联。

在示例实施方式中，可以由一个或更多个可编程处理器来执行操作，所述一个或更多个可编程处理器执行计算机程序，以通过对导入数据进行操作并且生成输出来执行功能。方法操作还可以由专用逻辑电路(例如，FPGA或ASIC)来执行，并且示例实施方式的装置可以被实现为专用逻辑电路(例如，FPGA或ASIC)。

计算系统可以包括客户端和服务器。客户端和服务器一般彼此远离并且通常通过通信网络来交互。客户端和服务器的关系凭借运行在相应计算机上并且彼此具有客户端服务器关系的计算机程序来产生。在部署可编程计算系统的实施方式中，将意识到的是，硬件和软件架构二者均值得考虑。具体地，将意识到的是，是以永久配置的硬件(例如，ASIC)还是以临时配置的硬件(例如，软件和可编程处理器的组合)亦或以永久配置的硬件和临时配置的硬件的组合来实现某些功能的选择可以是设计选择。下面阐述了可以部署在各种示例实施方式中的硬件(例如，机器)和软件架构。

图22示出了以计算机系统2200的示例形式的机器的框图，在计算机系统2200内指令2224可以被执行用于使机器执行本文中讨论的方法中的任一种或更多种方法。在替选实施方式中，机器操作为单机设备或者可以连接(或联网)至其它机器。在联网部署中，机器可以以服务器-客户端网络环境中的服务器或客户端机器的身份来操作，或者机器可以操作为对等(或分布式)网络环境中的对等机。机器可以为个人计算机(PC)、平板计算机、机顶盒(STB)、个人数字助理(PDA)、蜂窝电话、web应用、网络路由器、交换机或桥接器，或者能够执行(顺序地或以其它方式)指定要由该机器采取的动作的指令的任何机器。另外，虽然仅示出了单个机器，但是术语“机器”也应当被采用以包括单独地或联合地执行指令集合(或多个集合)以执行本文中讨论的方法中的任一种或更多种方法的机器的任何组合。

示例计算机系统2200包括经由总线2208彼此通信的处理器2202(例如，中央处理单元(CPU)、图形处理单元(GPU)或上述二者)、主存储器2204以及静态存储器2206。计算机系统2200还可以包括视频显示设备2210(例如，液晶显示器(LCD)或阴极射线管(CRT))。计算机系统2200还包括字母数字输入设备2212(例如，键盘)、用户接口(UI)导航设备2214(例如，鼠标或触敏显示器)、盘驱动单元2216、信号生成设备2218(例如，扬声器)和网络接口设备2220。

盘驱动单元2216包括机器可读介质2222，在该机器可读介质2222上存储有实施本文中描述的方法或功能中的任一种或更多种或由所述方法或功能利用的数据结构和指令2224(例如，软件)中的一个或更多个集合。指令2224在其由计算机系统2200执行期间还可以完全地或至少部分地驻留在主存储器2204内、静态存储器2206内和/或处理器2202内，主存储器2204和处理器2202还构成机器可读介质。

虽然在示例实施方式中将机器可读介质2222示出为单个介质，但是术语“机器可读介质”可以包括存储一个或更多个指令2224或数据结构的单个介质或多个介质(例如，集中式数据库或分布式数据库和/或相关缓存和服务器)。术语“机器可读介质”还应当被采用以包括下述的任何有形介质：所述有形介质能够存储、编码或携载用于由机器执行的并且使机器执行本技术的方法中的任一种或更多种方法的指令(例如，指令2224)，或者能够存储、编码或携载由这样的指令利用或与这样的指令相关联的数据结构。术语“机器可读介质”因此应当被采用以包括但不限于固态存储器以及光学和磁性介质。机器可读介质的具体示例包括非易失性存储器，非易失性存储器以示例的方式包括：半导体存储器设备，例如可擦除可编程只读存储器(EPROM)、电可擦除可编程只读存储器(EEPROM)和闪速存储器设备；磁盘，例如内部硬盘和可移动磁盘；磁光盘；以及DC-ROM和DVD-ROM盘。

指令2224还可以使用传输介质通过通信网络2226来发送或接收。指令2224可以使用网络接口设备2220和多个公知传送协议(例如，HTTP)中的任一协议来发送。通信网络的示例包括局域网(“LAN”)、广域网(“WAN”)、因特网、移动电话网、简易老式电话(POTS)网和无线数据网络(例如，WiFi和WiMAX网络)。术语“传输介质”应当被采用以包括下述的任何无形介质：所述无形介质能够存储、编码或携载用于由机器执行的指令，并且包括数字或模拟通信信号或促进这样的软件的通信的其它无形介质。

虽然已经参考具体示例实施方式描述了本发明主题，但是明显的是，可以在不背离本技术的更广泛范围的情况下对这些实施方式做出各种修改和改变。因此，说明书和附图要被视为示出性意义而不是限制性意义。形成本文的一部分的附图以图示的方式并且非限制性地示出其中可以对本主题进行实践的具体实施方式。足够详细地描述了所示的实施方式，以使得本领域技术人员能够对本文中公开的教示进行实践。可以利用上述实施方式并且从其得到其它实施方式，使得可以在不背离本公开内容的范围情况下做出结构和逻辑替换和改变。因而该详细描述不以限制性意义而被采用，并且各种实施方式的范围仅通过所附权利要求与称为这样的权利要求的等同方案的完全范围一起来限定。

本发明主题的这样的实施方式在本文中可以仅出于便利而被单独地和/或共同地称为术语“发明”，而不意在在实际上公开了多于一个发明或发明概念的情况下将本申请的范围主动地限制为任何单个发明或发明概念。因此虽然已经在本文中示出和描述了具体实施方式，但是应当意识到的是，被计算以实现相同目的的任何布置可以针对所示出的具体实施方式而被替换。本公开内容意在涵盖各种实施方式的任何以及全部调整或变型。以上实施方式以及未在本文中具体描述的其它实施方式的组合在阅读以上描述时对于本领域技术人员将是明显的。

Claims

1.一种方法，包括：

在包括具有存储器和至少一个处理器的机器的账务系统处接收由用户在金融系统处提供的授权，以将由所述账务系统保持的簿记账户与由所述金融系统保持的金融账户链接；

响应于对所述授权的接收，经由所述账务系统来检索与所述金融账户有关的金融账户数据；以及

使用所述金融账户数据来生成与所述簿记账户有关的账务数据。

2.根据权利要求1所述的方法，进一步包括：通过所述账务系统并且使用所述授权来经由应用编程接口(API)向所述金融系统注册提要。

3.根据权利要求2所述的方法，进一步包括：

响应于对所述提要的注册，从所述金融系统周期性地接收与所述金融账户有关的另外的金融账户数据；以及

使用所述另外的金融账户数据来生成与所述簿记账户有关的另外的账务数据。

4.根据权利要求1所述的方法，进一步包括：基于所述授权将来自所述账务系统的支付指令提供给所述金融系统。

5.根据权利要求1所述的方法，其中：

所述授权对用户进行识别；并且所述方法进一步包括：

在所述账务系统处对所述用户进行授权；以及

在检索所述金融账户数据之前从已授权的用户接收要链接的所述簿记账户的指示。

6.根据权利要求1至5中任一项所述的方法，进一步包括：

通过所述账务系统并且使用所述授权来验证所述金融系统支持针对所述金融账户的第三方支付服务。

7.根据权利要求6所述的方法，进一步包括：

将在所述金融账户上支取的批量支付提交给金融机构处的所述第三方支付服务。

8.根据权利要求7所述的方法，进一步包括：

从所述金融机构接收指示所述批量支付中的所有交易已经成功完成的确认。

9.根据权利要求8所述的方法，进一步包括：

响应于从所述金融机构接收到所述确认，更新与所述簿记账户有关的账务数据，以示出所述交易完成。

10.一种账务系统，包括：

存储器，以及

处理器，其耦接至所述存储器并且被配置成：

接收由用户在金融系统处提供的授权，以将由所述账务系统保持的簿记账户与由所述金融系统保持的金融账户链接；

响应于对所述授权的接收，检索与所述金融账户有关的金融账户数据；以及

11.根据权利要求10所述的账务系统，其中，所述处理器进一步被配置成使用所述授权经由API来向所述金融系统注册提要。

12.根据权利要求11所述的账务系统，其中，所述处理器进一步被配置成：

13.根据权利要求10所述的账务系统，其中，所述处理器进一步被配置成基于所述授权将支付指令提供给所述金融系统。

14.根据权利要求11所述的账务系统，其中：

所述授权对所述用户进行识别；并且进一步包括：

在所述账务系统处对所述用户进行授权；并且所述处理器进一步被配置成：

15.根据权利要求10至14中任一项所述的账务系统，其中，所述处理器进一步被配置成：

使用所述授权来验证所述金融系统支持针对所述金融账户的第三方支付服务。

16.根据权利要求15所述的账务系统，其中，所述处理器进一步被配置成：

将在所述账户上支取的批量支付提交给金融机构处的所述第三方支付服务。

17.根据权利要求16所述的账务系统，其中，所述处理器进一步被配置成：

18.一种非暂态机器可读存储介质，其上存储有指令，当由一个或更多个处理器执行所述指令时，所述指令使所述一个或更多个处理器执行包括下述步骤的操作：

接收由用户在金融系统处提供的授权，以将由账务系统保持的簿记账户与由所述金融系统保持的金融账户链接；

19.根据权利要求18所述的非暂态机器可读存储介质，其中，所述操作进一步包括：

通过所述账务系统并且使用所述授权来经由API向所述金融系统注册提要。

20.根据权利要求18至19中任一项所述的非暂态机器可读存储介质，其中，所述操作进一步包括：