基于电子文件进行自动验证交易的系统与方法与流程

本申请要求了于2016年3月13日提交的目前在审理中的美国临时申请62/307,498的权益。本申请也是于2016年11月28日提交的目前在审理中的申请号为15/361,934的美国专利的部分延续申请。以上参考的申请内容通过引用并入本文。

本公开一般涉及验证电子文件中指示的交易，更具体地涉及基于电子文件内容验证交易。

背景技术：

客户可以通过网络实时向商家订购旅游和住宿等服务。这些订单可以立即被接收和处理。然而，订单的付款通常需要更多的时间来完成，特别是需要更多的时间来确保正在转移的资金的安全。因此，商家通常要求客户在下订单时提供实时的付款保证。例如，客户可以依照支付输入信用卡信息，并且商家可以在授权出售之前实时地验证信用卡信息。验证通常包括通过查询金融机构来确定所提供的信息是否有效(即，信用卡号码、有效日期、密码和/或客户名称是否跟已知信息相匹配)。

在收到这样的保证后，可以为客户生成一份订购单。订购单提供了该订单的证明，例如，购买价格、订购的货物和/或服务等。稍后，可能会生成订单的发票。订购单通常用来指示需要买哪些产品以及对价格的估计或报价，而发票通常用来指示实际提供了哪些产品以及产品的最终价格。通常，订单的发票所显示的购买价格与订购单所显示的购买价格不同。例如，如果一位住在酒店的客人最初订了3晚的住宿，但最后却住了四晚，那么订购单的总价格可能会与随后的发票上的总价格不同。发票的总价格与订购单的实际总价格不同的情况很难进行追踪，特别是在大型企业每天接受许多订单的情况下(例如，一家大型连锁酒店管理着某一国家的数百家或数千家酒店)。这些价格差异可能会导致企业的记录出现错误。

随着企业越来越多地依靠技术来管理与发票和订购单数据等业务有关的数据，用于适当地管理和验证数据的合适系统已成为成功的关键。特别是对于大型企业来说，企业每天使用的数据量可能是巨大的。因此，人工审查和验证这些数据是不现实的。然而，记录文件之间的差异可能给企业造成重大问题，例如，未能向税务局适当地报告收入。

通常，要回收(reclaim)在交易期间支付的增值税(vat)，必须将能指示与交易有关的信息的证据文件(如发票或收据)提交给适当的退税机构(例如，退还增值税的国家税务机构)。如果提交的文件中的信息与在收回请求中提交的信息不匹配，则拒绝该请求，也不批准退还。为此，组织机构的雇员通常以电子文件的形式手动选择和提交增值税回收所需的文件(例如，发票或收据的扫描图像文件)。手动选择会出现人为错误的可能性，例如，一名雇员在请求中提供了不正确的信息和(或)提交了错误文件(例如，另一笔交易的发票)。现有的自动验证交易解决方案在利用包含至少部分地非结构化的数据的电子文件时面临着挑战。

此外，许多企业还报销了代表公司和/或与雇员工作有关的各种费用。例如，一家公司可以报销其雇员在出差期间所使用的旅馆住宿费用。这类企业通常根据雇员提交的费用报告来确定报销。这些雇员提交的费用报告可能是错误的、具有欺骗性的或不准确的。这种不准确的费用报告可能导致公司报销错误或报税不准确。用于验证报销的典型解决方案需要对雇员提交的文件进行人工审查，这可能会进一步发生人为错误。其他解决方案可能允许自动验证，但通常要求雇员以具有特定结构或格式的形式来提交数据。

因此，提供一种能够克服现有技术缺陷的解决方案将是有利的。

技术实现要素：

本公开的几个示例性实施例的发明内容如下。本发明内容提供对这些实施例的基本理解以为读者提供方便，并且不完全限定本公开的范围。本发明内容不是对所有设想的实施例的广泛概述，其目的是既不确定所有实施例的关键或决定性的要素，也不描述任意方面或所有方面的范围。它的唯一目的是以简化的形式呈现一个或多个实施例的一些概念，作为之后提出的更详细描述的铺垫。为方便起见，在本文使用的术语“一些实施例”可以用于指代本公开的单个实施例或多个实施例。

这里公开的一些实施例包括用于基于电子文件进行验证交易的方法。所述方法包括：分析电子文件以确定交易的至少一个交易参数，其中电子文件包括至少部分地非结构化的数据；为交易创建模板，其中模板是包含所确定的至少一个交易参数的结构化数据集；根据所创建的模板确定至少一个数据源；从所确定的至少一个数据源中获取证明交易的数据；以及根据所获得的证明数据和创建的模板确定交易是否通过验证。

本文公开的一些实施例还包括非暂时性计算机可读介质，在所述可读介质上存储有用于使处理电路执行处理的指令，所述处理包括：分析电子文件以确定交易的至少一个交易参数，其中电子文件包括至少部分地非结构化的数据；为交易创建模板，其中所述模板是包含所确定的至少一个交易参数的结构化数据集；根据所创建的模板确定至少一个数据源；从所确定的至少一个数据源中获取证明交易的数据；以及根据所获得的证明数据和创建的模板确定交易是否通过验证。

本文公开的一些实施例还包括用于基于电子文件进行验证交易的系统。所述系统包括：处理电路；和记忆体(memory)，记忆体包含指令，当由处理电路执行指令时，系统配置为：分析电子文件以确定交易的至少一个交易参数，其中电子文件包括至少部分地非结构化的数据；为所述交易创建模板，其中模板是包含所确定的至少一个交易参数的结构化数据集；根据所创建的模板确定至少一个数据源；从所确定的至少一个数据源中获取证明交易的数据；以及根据所获得的证明数据和创建的模板确定交易是否通过验证。

附图说明

在说明书结尾处的权利要求中特别指出并明确提出了本文所公开的主题。以下与附图相结合的详细描述能够使所公开的实施例的前述目标和其他目标、特征和优点显而易见。

图1是用来描述所公开的多个实施例的网络图。

图2是根据实施例中的验证系统的示意图。

图3是根据实施例中的基于电子文件进行自动验证交易的方法的流程图。

图4是根据实施例中的基于电子文件创建数据集的方法的流程图。

具体实施方式

需要注意的是，本文公开的实施例仅是使用本文的创新方法得到的众多优势的示例。一般而言，在本申请的说明书中所作的声明不一定限制所提出的多个实施例中的任何一个。此外，一些陈述可能适用于某些创造性的特征，但不适用于其他的特征。一般来说，除非另有说明，否则单数的元素可以是复数的，反之亦然且不失一般性。在附图中，相似的数字在几个视图中表示相似的部分。

所公开的多个实施例包括用于基于电子文件进行自动验证交易的方法和系统。在实施例中，基于指示与交易相关的信息的电子文件来创建数据集。该交易可能是要求报销或退还增值税(vat)的交易。基于电子文件数据集创建交易属性的结构化数据集模板。基于该模板、至少一个存储交易证明数据的数据源，可以确定交易的一方或多方、或双方。检索交易证明数据。根据检索到(retrieved)的数据，确定该交易是否通过验证。

图1是用于描述所公开的多种实施例的示例网络图100。在示例网络图100中，交易验证器120、企业系统130和多个web源140-1到140-n(只是为了简单起见。在下文单独地称为web源140以及整体称为web源140)通过网络110通信连接。网络110可以是但不限于无线、蜂窝或有线网络、局域网(lan)、广域网(wan)、城域网(man)、因特网、万维网(www)、类似网络及其任意组合。

企业系统130与企业相关联，可以存储与企业或企业代表的采购有关的数据以及与企业本身有关的数据。企业系统130还可以存储与将要由企业验证的交易相关的数据。企业可以是但不限于：一种其雇员可以在国外购买须缴纳增值税的货物和服务的企业、一种为雇员报销各种费用的企业或两者都具备的企业。企业系统130可以是但不限于服务器、数据库、企业资源规划系统、客户关系管理系统或存储相关数据的任何其他系统。

企业系统130存储的数据可以包括但不限于电子文件(例如，发票的扫描图像文件、文本文件、电子表格文件)。每个电子文件可以显示例如发票、税收收据、采购号码记录、增值税收回请求、雇员费用报告等。包括在每个电子文件中的数据可以是结构化的、半结构化的、非结构化的或它们的组合。这些结构化或半结构化数据可采用不能被交易验证器120识别的格式，因此可被视为非结构化数据。

网络源140存储交易证明数据。这种数据可以包括但不限于，指示与交易有关的信息的数据(例如，指示价格、购买的产品、税收、买方、卖方等的数据)、与交易的至少一方有关的数据(例如，指示交易的一方的位置的数据)或两者都具备。交易证明数据可以是元数据或包括元数据，但不限于元数据。作为非限制性示例，用于验证交易的数据可以包括指示在交易发生时的用户位置的元数据。

web源140可以包括但不限于商家的服务器或设备、税局服务器、会计服务器、与企业相关的数据库等。作为非限制性示例，web源140-1可以是商家服务器，用于存储与商家进行交易的购买价格有关的数据。

在实施例中，交易验证器120被配置为基于利用电子文件的机器视觉进行识别的交易参数来创建模板，其中电子文件指示与交易相关的信息。在另一实施例中，交易验证器120可以配置为从例如企业系统130种检索电子文件。基于所创建的模板，交易验证器120被配置为检索该交易的证明数据。

在实施例中，该交易验证器120被配置为基于包括至少部分地非结构化的数据(例如，非结构化数据、半结构化数据或具有未知结构的结构化数据)的电子文件创建数据集。为此，交易验证器120可进一步配置为利用光学字符识别(ocr)或其他图像处理来确定电子文件中的数据。因此，交易验证器120可以包括识别处理器或通信连接到识别处理器(例如，图2中的识别处理器235)

在实施例中，交易验证器120被配置为分析所创建的数据集以识别该电子文件中所指示的与交易相关的交易参数。在实施例中，交易验证器120被配置为基于所创建的数据集创建模板。每个模板都是一个结构化数据集，包括用于交易的已识别的交易参数。

在实施例中，交易验证器120被配置为验证电子文件中所指示的交易。在另一实施例中，交易验证器120被配置为给电子文件创建模板，并基于所创建的模板获取该交易的证明数据。证明数据可以是元数据，也可以是包括元数据。在另一实施例中，交易验证器120被配置为确定至少一个数据源并从中获取证明数据。该至少一个数据源可以包括但不限于web源140、企业系统130或两者都具备。在另一实施例中，交易验证器120被配置为从确定的至少一个数据源检索证明数据。

基于证明数据和创建的模板，交易验证器120被配置为确定电子文件中所指示的交易是否通过验证。为此，在另一实施例中，交易验证器120被配置为将所创建的模板数据与所获得的证明数据进行比较。在另一实施例中，进一步基于模板的结构进行比较。作为非限制性示例，模板的“位置”字段中的数据可以与指示跟买方关联的用户设备(未示出)位置的元数据进行比较。在另一实施例中，基于该比较，交易验证器120被配置为确定所比较的数据的匹配程度是否超过预定阈值，如果超过，则确定该交易通过验证。

在实施例中，当确定交易未通过验证时，可以确定验证失败的原因。验证交易失败的潜在原因可能包括与模板数据和证明数据之间的差异相关的情况或假设。潜在原因可以基于一个或多个因果关系规则来确定。在实施例中，因果关系规则可以包括与价格差异的特定值或其倍数相关联的潜在原因。在另一实施例中，因果关系规则还可以基于该差异是正的(例如，发票中的价格高于证明数据所指示的价格)还是负的(例如，发票中的价格低于证明数据所指示的价格)。

作为用于确定失败原因的非限制性示例，因果关系规则可以包括雇员费用报告，该报告指示与买方的用户设备位置不同的交易位置。因此，无法验证的原因被确定为“不正确的雇员位置”。例如，一份雇员费用报告显示，9月9日下午5：00，一名雇员“约翰·史密斯”在希腊购买了一张飞机票，但与约翰·史密斯的公司智能手机相关联的元数据表明，该智能手机在9月9日下午5：00在英国。

在另一实施例中，可以生成指示交易是否通过验证的通知，并将其发送到例如企业系统130处。在另一实施例中，当确定交易没有通过验证时，该通知可进一步指示已确定的失败原因。

应当注意的是，上面针对图1中的企业系统130的描述的实施例仅是为了简单起见而进行描述的，并不限于所公开的实施例。在不偏离本公开的范围的情况下，多个企业系统能被平等地利用。

图2是根据实施例中所使用的交易验证器120的示例框图。交易验证器120包括耦合到记忆体215的处理电路210、存储器220、光学字符识别(ocr)处理器230和网络接口240。在另一实施例中，交易验证器120的部件可以通过总线250进行通信连接。

处理电路210可以作为一个或多个硬件逻辑部件和电路来实现。例如，可以使用的硬件逻辑部件的说明性类型包括但不限于现场可编程门阵列(fpga)、专用集成电路(asic)、专用标准产品(assp)、片上系统(soc)、通用微处理器、微控制器、数字信号处理器(dsp)等，或者可以执行计算或其他信息处理的任何其他硬件逻辑部件。

记忆体215可以是易失性的(例如，ram等)、非易失性的(例如rom、快闪记忆体等)或其组合。在一种配置中，用于实现本文公开的一个或多个实施例的计算机可读指令可以存储在存储器220中。

在另一实施例中，记忆体215被配置为存储软件。软件应被广义地解释为任何类型的指令，无论是软件、固件、中间件、微码、硬件描述语言还是其他。指令可以包括代码(例如，是源代码格式、二进制代码格式、可执行代码格式或任何其他合适的代码格式)。当由处理电路210执行这些指令时，这些指令使处理电路210执行本文所描述的多种处理。具体来说，当指令被执行时，这些指令使处理电路210基于如本文所述电子文件执行自动验证交易。

存储器220可以是磁存储器、光存储器等，并且可以实现作为例如快闪记忆体或其他记忆体、cd-rom、数字多用途磁盘(dvd)或可用于存储所需信息的任何其他介质。

ocr处理器230可以包括但不限于被配置为识别非结构化数据集中的模式、特征或两者的特征识别处理器和/或模式识别处理器(rp)235。具体来说，在实施例中，ocr处理器230被配置为至少识别非结构化数据中的字符。识别的字符可用于创建包括验证交易所需的数据的数据集。

网络接口240允许交易验证器120与企业系统130、web源140或其组合进行通信，用于例如收集元数据、检索数据、获取电子文件、存储数据等。

应当理解，本文描述的实施例不限于图2中所示的特定架构。另外，可以在不偏离所公开实施例的范围的情况下同样地使用其他架构。

图3是根据实施例中的基于电子文件进行自动验证交易的方法的示例流程图300。在实施例中，该方法可由交易验证器(例如，交易验证器120)执行。

在s310处，基于包括与交易相关的信息的电子文件来创建数据集。电子文件可以包括但不限于非结构化数据、半结构化数据、具有未预料的或未公布的结构或两者都具备的结构化数据。在实施例中，s310还可以包括使用光学字符识别(ocr)来分析电子文件以确定电子文件中的数据、识别数据中的关键字段、识别数据中的值或其组合。下面针对图4进一步描述基于电子文件来创建数据集。

在s320上，对数据集进行分析。在实施例中，分析数据集可以包括但不限于确定交易参数，交易参数是例如但不限于至少一个实体标识(例如，消费企业标识、商家企业标识，或两者)、与交易有关的信息(例如，但不限于：日期、时间、价格、出售的商品或服务的类型等)或这两者。在另一实施例中，分析数据集还可以包括基于数据集识别交易。

在s330处，基于数据集创建模板。模板可以是但不限于包括多个字段的数据结构。这些字段可以包括所识别的交易参数。字段可以是预定义的。

从电子文件创建模板，由于所创建的模板的结构化性质，使得处理速度更快。例如，相对于缺乏这种结构的数据集，在结构化数据集上执行查询和处理操作的执行效率会更高。此外，将来自电子文件的信息组织成结构化数据集，可以显著地减少用于保存电子文件中包含的信息所需的存储量。电子文件通常是图像，相比包含相同信息的数据集需要更多存储空间。例如，表示来自100000个图像电子文件的数据的数据集可以作为数据记录保存在文本文件中。这样的一个文本文件的大小将大大小于100000幅图像的大小。

在s340处，确定来自至少一个数据源的交易证明数据。这样的数据源可以包括(但不限于)一个或多个web源、企业系统或者两者都具备。在另一实施例中，s340还包括基于模板确定数据源。例如，如果模板包括指示购买人名称的字段“买方”，则可以确定至少一个存储元数据的数据源，元数据与例如跟潜在购买者相关联的用户设备相关。

在s350处，从所确定的至少一个数据源获取该交易的证明数据。在实施例中，可以基于创建的模板获取数据。作为非限制性的示例，如果模板包括指示交易位置的“位置”字段、指示交易时间的“时间”字段和指示进行交易处理的雇员的“买方”字段，则可以获得指示在交易发生时与雇员关联的用户设备的位置的元数据。作为另一非限制性的示例，如果模板包括指示交易价格的“价格”字段和指示交易标识的“交易id”字段，则可以从商家数据库中检索到指示交易价格的元数据。

在s360处，根据模板和所获得的证明数据，确定交易是否通过验证，如果是，则继续执行s380；否则，继续执行s370。在实施例中，s360可以包括将模板中的数据与获得的证明数据进行比较。在另一实施例中，可以进一步基于预定阈值进行验证。例如，如果所比较的数据的匹配程度超过预定阈值，则该交易通过验证。

在另一实施例中，该比较可以是基于模板的结构。在另一实施例中，可以将模板的每个字段中的数据与从至少一个数据源处获得的相应数据进行比较。例如，字段“位置”、“买方”和“价格”中的数据可以分别与从所确定的至少一个数据源处获得的相应位置、雇员和价格数据进行比较。

在可选的s370处，当确定交易没有通过验证时，确定至少一个验证失败的原因。在实施例中，可以基于至少一个因果关系规则来确定验证失败的至少一个原因。这些原因可以包括但不限于：不正确的位置、不正确的价格等等。

在可选的s380处，可以生成通知。该通知可以指示交易是否通过验证。在另一实施例中，当交易没有通过验证时，通知可以包括所确定的至少一个原因。

图4是s310的示例流程图，描述了根据实施例中基于电子文件创建数据集的方法。

在s410处，获取该电子文件。获取电子文件可包括但不限于接收电子文件(例如，接收扫描图像)或检索电子文件(例如，从消费企业系统、商业企业系统或数据库中检索电子文件)。

在s420上，对该电子文件进行了分析。分析可以包括但不限于使用光学字符识别(ocr)来确定电子文件中的字符。

在s430上，根据分析确定电子文件中的关键字段和值。关键字段可以包括但不限于商家的姓名和地址、日期、货币、出售的商品或服务、交易标识、发票号码等。一份电子文件可能包含不必要的细节，而这些细节不会被认为是关键值。例如，商家的商标可能是不需要的，因此，它不是一个关键值。在实施例中，可以预定义一个关键字段列表，并提取与这些关键字段匹配的数据块。然后，进行清洁处理(cleaningprocess)以确保信息准确地显示。例如，如果ocr将产生一个“1211212005”的数据，则清洁处理将此数据转换为12/12/2005的数据。另一个例子是，如果名称表示为“mo$den”，则将更改为“mosden”。清洁处理可以是使用外部信息资源(例如字典、日历、企业数据库等)来执行。

在另一实施例中，检查提取的数据块是否完整。例如，如果识别到商家名称但缺少商家地址，则商家地址的关键字段是不完整的。执行尝试令缺失的关键字段值完整。这种尝试可以包括查询外部系统和数据库、与之前分析过的发票相关性或查询以上因素的组合。外部系统和数据库可以包括业务目录、通用产品代码(upc)数据库、包裹派送及跟踪系统等。在实施例中，s430得到预定义关键字段及其各自的值的完整集合。

在s440处，生成结构化数据集。生成的数据集包括已识别的关键字段和值。

本文公开的多个实施例能够以硬件、固件、软件或其中的任何组合来实现。此外，优选地将软件实现为具体呈现在程序存储单元或计算机可读介质上的应用程序，程序存储单元或计算机可读介质由部分或某些设备和/或设备组合组成的。应用程序可以上传到包括任何适当架构的机器上，并由该机器执行。优选地，该机器在计算机平台上实现，计算机平台具有诸如一个或多个中央处理单元(“cpu”)、记忆体和输入/输出接口等硬件。计算机平台还可以包括操作系统和微指令代码。本文中描述的各种处理和功能可以是微指令代码的一部分或应用程序的一部分或者是它们的任意组合，不管这种计算机或处理器是否有被清楚地示出，这些微指令代码或应用程序都可以由cpu执行。此外，多种其他外部单元可以连接到计算机平台，例如附加的数据存储单元和打印单元。此外，非临时计算机可读介质是除了临时传播信号之外的任何计算机可读介质。

应当理解的是，对于本文使用“第一”、“第二”等指定的元素，一般不限制这些元素的数量或顺序。相反，本文通常使用的这些指定是作为区分两个或多个元素或一个元素的多个例子。因此，对第一和第二元素的引用并不意味着仅可以使用两个元素，或者第一元素必须以某种方式位于第二元素之前。另外，除非另有说明，一组元素包括一个或多个元素。

如本文所使用的，短语“至少一个”后加上一个项目列表，意味着可以单独使用该项目列表中的任何一个，或者可以使用其中两个或两个以上所列项目的任意组合。例如，如果一个系统被描述为包括“a、b和c中的至少一个”，系统可以包括单独一个a；单独一个b；单独一个c；a和b组合；b和c组合；a和c组合；或a、b和c组合。

在本文引用的所有示例和条件表达都是出于讲解的目的，以帮助读者理解所公开的实施例的原则和发明人所传递的概念，以进一步发展该技术，并且应被理解为不限于这些具体引用的示例和条件。此外，本文中所有关于公开实施例的原则、方面和体现的陈述以及其中具体的示例，旨在包含这些陈述中的结构等效物和功能等效物。此外，这类等效物包括目前已知的等效物以及未来开发的等效物，即无论结构如何，能执行相同功能的任意元素。