用于安全信息验证和交换的系统和方法与流程

相关申请的交叉引用

本专利合作条约专利申请要求于2017年4月28日提交的标题为“systemandmethodforsecureinformationvalidationandexchange”的美国临时申请no.62/491,722的优先权，该美国临时申请的内容通过引用整体并入本文。

本文描述的实施例一般而言涉及用于安全地收集和验证来自实体的结构化和非结构化信息以促进该实体与第三方之间的有约束力的交易的系统和方法。

背景技术：

一方(诸如个人或公司)可以从保险提供者那里购买保险，以减轻某些财务损失的风险。通常，在保险提供者可以为申请人确定适当的承保限额和适当的保险费之前，保险提供者需要来自寻求保险的一方(“申请人”)的包含具体的机密信息的申请。

但是，所需信息的收集和组织对于申请人而言可能是耗时的或成本高昂的，从而降低了申请人将完成申请的机会。不完整的保险申请为保险提供者增加了成本并降低了风险分散并潜在地使申请人遭受无意的机密信息披露。

技术实现要素：

本文描述的实施例一般而言涉及包括多目的配置的控制器的系统，或者在功能上、结构上或物理地安全地将数据获取、验证和聚合操作与数据分发操作分开的系统。这些配置的结果是，申请人的隐私得到保护，申请完成时间可以减少，申请完成率可以提高，并且申请人可以能够审阅来自更大数量的保险提供者的更大数量的保险报价。

附图说明

现在将参考附图中示出的代表性实施例。应当理解的是，以下描述并非旨在将本公开限制到一个优选实施例。相反，本文提供的公开旨在覆盖可以包括在所描述的实施例的精神和范围内并由所附权利要求限定的替代物、修改和等同物。

图1描绘了诸如本文所述的系统的简化图。

图2a描绘了被配置为收集、验证和显示结构化和非结构化数据的电子设备。

图2b描绘了图2a的电子设备，具体地示出了其中电子设备提供促进有约束力的交易的选项的示例配置。

图3是诸如本文所述的用于交易结构化和非结构化数据的系统的简化流程图。

图4是诸如本文所述的用于交易结构化和非结构化数据的另一个系统的简化流程图。

图5是诸如本文所述的用于自动收集和验证结构化和非结构化数据的系统的简化流程图。

图6是用于自动结构化来自未知源的数据的系统的简化流程图。

图7是用于自动重构来自已知源的数据的系统的简化流程图。

图8是用于自动验证手动输入的数据的系统的简化流程图。

图9是描绘处理来自未知源的结构化或非结构化数据的方法的示例操作的流程图。

图10是描绘聚合和处理结构化数据的方法的示例操作的流程图。

图11是描绘最小化手动数据输入的方法的示例操作的流程图。

图12是描绘验证手动输入的数据的方法的示例操作的流程图。

图13是描绘确定是否可以从结构化数据源获取具体数据的方法的示例操作的流程图。

图14是描绘促进有约束力的交易的方法的示例操作的流程图。

在不同附图中使用相同或相似的附图标记表示相似、相关或相同的项目。另外，应当理解的是，各种特征和元件(以及它们的集合和分组)的(相对的或者绝对的)比例和尺寸以及其间存在的边界、分离和位置关系在附图中被提供，仅仅是为了促进对本文所述各种实施例的理解，并且因而可能不一定按比例呈现或示出，并且不意在指示所示实施例对不包括参考其描述的实施例的任何偏好或要求。

具体实施方式

本文描述的实施例涉及用于促进两方或更多方之间的有约束力的(binding)交易的系统和方法。特别地，本文描述的实施例涉及用于完成两方或更多方之间的有约束力的交易所必需的结构化、非结构化和手动输入的数据的高效且安全的聚合、验证、格式化和交换的系统和方法。由于本文所述的构造和配置，可以以更高效、私有和安全的方式完成有约束力的交易。

有约束力的交易的一个示例是保险申请人与保险提供者(此处一般称为“承保人(carrier)”)之间的保险交易。为了描述的简单，下面的实施例和示例引用房地产保险交易。但是，可以认识到的是，这仅仅是一个示例，并且本文描述的技术、示例、方法和系统可以等效地应用于其它交易(或交易类型)，包括但不限于：租客保险交易、汽车保险交易、健康保险交易、责任保险交易、旅行保险交易、公司或商业保险交易、个人物品保险交易、差额保险交易、人寿保险交易、电器保险交易、再保险交易、共同保险交易、止损保险交易等等。

为了完成房地产保险交易，申请人通过向承保人提交个人和机密信息来完成申请以从该承保人获得报价。如果申请人接受报价中列出的条款，那么交易可以完成。

但是，在许多情况下，申请人披露的信息范围过于广泛。例如，保险公司可以请求银行对账单以核实申请人的资产。除余额外，银行对账单还可以包括识别具体收款人、付款人和金额的交易记录。在另一个示例中，保险公司可以请求税表以核实税款的支付并核实申请人的应纳税工资总额。除了应纳税工资总额之外，税表还可以包括抵减额或项目、慈善捐赠、墨迹签名等。此类信息可能与保险公司无关，但仍在常规保险申请过程中被披露。

在其它常规情况中，要求申请人手动输入或以其它方式向保险公司提供大量信息以获得报价。在许多情况下，输入信息的过程非常耗时。因此，申请人可能在完成之前放弃申请过程。在这种情况下，保险提供者将失去分散风险的机会，并且可能失去(通过获取新的保单持有人)降低所有保单持有人的保费的机会。此外，在一些情况下，保险提供者可以保留使用或出售申请人在未完成的申请中披露的某些信息(例如，身份信息、联系信息、居住信息等)的权利达未知的时间段。此外，申请人手动输入信息的过程容易出错。因此，申请可能会延迟或报价在以后可能会撤销。

在还有其它常规情况下，为了从保险提供者处获取报价，可能要求申请人在同一申请的不同位置多次手动输入类似信息。在许多情况下，多次输入相同信息的重复过程可能会造成申请人在完成之前放弃申请过程或在整个申请中传播错误。如上所述，在这种情况下，保险提供者失去了分散风险的机会，并且申请人面临潜在的机密信息披露。

在还有其它常规情况下，申请人可以分阶段完成申请，从而周期性地保存未决的申请。在这种情况下，申请人可能面临一个或多个申请草稿中包含的信息的意外机密信息披露。

在还有其它常规情况下，申请人可能期望在选择来自特定承保人的特定策略之前比较来自多个承保人的报价。在许多情况下，申请人必须手动输入或以其它方式向每个个体承保人提供大量信息，以便从该承保人获得报价。如上所述，对于多个承保人在多个位置多次输入信息的过程是耗时的并且容易出错。因此，申请人可能会在完成之前放弃申请过程，或者可能仅寻求来自少量保险提供者的报价；申请人可能无法了解不同承保人提供的更优惠的保险单或保费。

在还有其它常规情况下，申请人可以向保险经纪人提供信息，而保险经纪人进而将该方的信息提交给与保险经纪人有转介关系的各个保险公司。照此，申请人仅接收来自与保险经纪人具有已有的、建立的关系的保险提供者的报价。例如，在一些情况下，保险经纪人可以具有在线业务或门户。承保人可以许可访问门户。通过门户提交申请的申请人不会接收来自没有许可访问门户的承保人的报价。与上述其它常规情况一样，在这种情况下，申请人不知道或不能够知道来自其它承保人的可能更有利的保险单。

在还有其它常规情况下，保险经纪人分发(并货币化)来自申请人的财务信息，并且仅在申请人通常不会阅读或理解的隐私政策中提供向第三方披露的通知。在这种情况下，申请人面临意料之外的机密信息披露。

因而，本文描述的实施例涉及用于完成保险申请并安全地分发该申请所需的格式化、非结构化和手动输入的数据的安全且高效的聚合、验证、格式化和交换的系统和方法，而无需不必要的信息或过度披露给任何数量的保险承保人。

更具体而言，本文所述的系统包括多目的配置的控制器，或者在功能上、结构上或物理地安全地将数据获取、验证和聚合操作与数据分发操作分开的系统。这些配置的结果是，申请人的隐私得到保护，申请完成时间可以减少，申请完成率可以提高，并且申请人可以能够审阅来自更大数量的保险提供者的更大数量的保险报价。

下面参考图1-图14讨论这些和其它实施例。但是，本领域技术人员将容易认识到的是，本文关于这些附图给出的详细描述仅用于解释，并且不应当被解释为限制性的。

例如，图1描绘了本文描述的实施例的简化系统图。由用户设备102经由直接或网络连接来访问所示出的系统(识别为系统100)。

用户设备102可以是任何合适的设备，诸如但不限于：蜂窝电话、膝上型计算机、平板计算机、台式计算机等。通常，用户设备102由申请人操作，但这不是必需的。例如，在其它实施例中，用户设备102可以是由申请人的代理或代表操作的设备。在另外的示例中，多于一个用户设备(或代理设备)可以与系统100相关联。

系统100还包括自动数据聚合控制器104和数据分发控制器106，自动数据聚合控制器104和数据分发控制器106彼此(和/或与未示出的其它系统或控制器)安全地通信，以仅收集和交换完成申请所必需的信息，这些信息可以被分发到一个或多个保险承保人(被识别为承保人108)。

在一个实施例中，收集、验证和分发与申请相关联的信息的过程可以在用户设备102向自动数据聚合控制器104发送描述操作用户设备102的申请人期望完成的交易类型(例如，房地产保险、个人财产保险、车辆保险等)的信号或通信之后开始。

在一些实施例中，一旦确定了特定的申请类型，自动数据聚合控制器104就可以将请求类型转发到数据分发控制器106。数据分发控制器106可以访问包括承保人108的承保人数据库(未示出)，该承保人可以能够基于从自动数据聚合控制器104接收的请求类型向申请人提供报价。例如，承保人数据库可以包括与不同市场相关联的不同保险承保人或与不同类型的保险相关联的承保人。本领域技术人员可以认识到的是，这样的数据库可以是第一方数据库或第三方数据库；承保人数据库可以以任何数量的合适的方式实现。

一旦确定了潜在承保人的集合，系统100就可以操作以收集和验证信息以完成与这些承保人相关联的一个或多个申请。在其它实施例中，该潜在承保人的集合可以在随后的时间被更新和/或改变。在还有其它实施例中，此时不能确定潜在承保人的集合。

自动数据聚合控制器104被配置为以任意数量的合适方式接收和/或收集数字数据形式的信息。例如，在许多实施例中，自动数据聚合控制器104被配置为从各种本地或远程信息源(例如，第一方数据库、第三方数据库、直接数据输入等)收集、验证和组织与申请人相关(或直接由申请人提供)的信息。来自申请人的信息可以包括任何合适的信息，诸如但不限于：身份信息、税收信息、不动产或个人财产信息、收入信息、储蓄信息、债务信息、家庭信息、房地产信息、就业信息等。

表示来自申请人(或与申请人相关联)的具体信息的具体数字数据可以由自动数据聚合控制器104从各种源和/或以各种形式或格式接收或产生，包括但不限于：手动输入的数据(例如，由申请人和/或申请人的代理提供的数据，诸如姓名数据)、检索到的数据(例如，响应于查询的来自第一方或第三方数据库的结构化数据，诸如地址数据)、提取的数据(例如，从文档中提取的值，诸如从税收文档中提取的税收数据)、推断的数据(例如，基于数据的存在或不存在而确定的值，诸如基于税收信息的就业状况)和/或计算的数据(例如，基于其它数据计算的数据，诸如根据出生日期信息的年龄)。

一旦被收集为数字数据，自动数据聚合控制器104就可以通过执行合适的数据验证操作来验证数据。在一些示例中，数据验证操作可以包括但不限于：拼写验证、语法验证、格式验证、数值范围验证、被禁字符检查、数据清理操作等。在许多情况下，自动数据聚合控制器104执行的数据验证技术和操作可以因申请和/或因申请人而异。一般而言且广泛地，已经由自动数据聚合控制器104验证和/或清理的数据在本文中被称为“规格化的数据”。

数据分发控制器106被配置为将由自动数据聚合控制器104收集的数据和信息打包并安全地分发给承保人108、一个或多个评级组织或其它实体。数据分发控制器106可以被配置为以行业标准格式(例如，住宅贷款数据格式1003)和/或特定于承保人的格式来提交信息。在一些情况下，数据分发控制器106可以在提交申请时在适当情况下匿名化申请人的身份，但这可能不是必需的。

数据分发控制器106还被配置为将特定申请的需求或申请的集合的组合需求传达给自动数据聚合控制器104。特别地，在许多实施例中，数据分发控制器106被配置为向自动数据聚合控制器104指示关于特定承保人(或承保人的集合)的特定申请(或多个申请)所需的数据的类型和/或格式。

在本文中，从数据分发控制器106发送到自动数据聚合控制器104的信息一般被称为聚合/验证方案(或更简单地，“方案”)。方案可以包括任何数量的合适的字段、格式、值表示或编码，并且应该认识到的是，分发方案所依据的具体内容、格式或机制可以随实施例而不同。诸如本文所述的方案通常不包括任何个人识别信息，但这可能不是必需的。

在典型的实施例中，方案作为结构化数据跨安全网络连接(例如，经由安全套接字层分发的javascript对象符号或可扩展标记语言格式的文件)从数据分发控制器106发送到自动数据聚合控制器104，但是可能并非所有实施例都要求这样做。在许多情况下，除了由自动数据聚合控制器104用来以特定方式验证或重新格式化具体数据的验证定义或功能(本文中一般称为“验证定义”)之外，方案还包括关于特定申请的要求的信息(例如，格式、类型、最大长度等)。

例如，如果数据分发控制器106确定与承保人108中的特定承保人相关联的特定申请仅需要姓名信息，那么数据分发控制器106可以将包括只需要姓名信息的指示的方案传达给自动数据聚合控制器104。该方案还可以包括与申请所需的姓名信息相关联的验证定义。

在这个示例中，验证定义可以包括但不限于与以下各项相关联的定义：大写、编码、格式、间距、字符计数等。响应于接收到方案，自动数据聚合控制器104获得(例如，经由手动输入或另一种方法)并验证(例如，根据验证定义)申请人姓名的数字化表示(例如，作为字符串、数据对象、加密的字符串、无类型对象或任何其它合适的数字化表示)。

此后，自动数据聚合控制器104将规格化的姓名数据传达给数据分发控制器106。作为响应，数据分发控制器106将规格化的姓名数据插入到申请的适当字段中，并且经由安全信道将申请转发到相关联的承保人。

作为本文所述的拓扑的结果，数据分发控制器106未从申请人接收任何不必要的信息或任何格式不正确的信息。类似地，承保人也不从申请人接收任何不必要的信息、任何部分完成的申请草稿或任何格式不正确的信息。以这种方式，保护申请人的数据隐私不受第三方侵害。

在另外的示例中，自动数据聚合控制器104可以被配置为确定收集特定申请所需的信息的高效方式。例如，自动数据聚合控制器104可以与文档内容数据库(未示出)相关联或者可以与文档内容数据库通信，该文档内容数据库存储关于通常包含在各种文档(诸如驾驶执照、银行对账单、税表、房地产文档、护照文档、社交媒体网站、电子邮件数据库等)中的数据的信息。自动数据聚合控制器104可以用来自从数据分发控制器106接收的方案的信息查询文档内容数据库，并且数据库可以返回包含(一个或多个)申请所需的全部或基本全部信息的优化的或最小化的文档类型集合。以这种方式，减轻了申请人不必要的数据输入。

例如，在一个实施例中，数据分发控制器106可以确定特定申请仅需要名字、姓氏和地址。响应于该确定，数据分发控制器106将适当的方案分发到自动数据聚合控制器104。自动数据聚合控制器104查询文档内容数据库，该文档内容数据库确定名字、姓氏和地址信息是申请人的驾驶执照的全部内容。

在一个实施例中，自动数据聚合控制器104可以向用户设备102发送信号，该信号使用户设备102在显示器上呈现用户界面，该用户界面请求申请人检索驾驶执照并将来自该执照的信息输入到在用户界面内呈现的字段中。

在其它实施例中，自动数据聚合控制器104可以请求申请人的驾驶执照的照片。从该照片中，自动数据聚合控制器104可以仅提取名字、姓氏和地址信息。更具体而言，在这个示例中，自动数据聚合控制器104可以忽略和/或丢弃驾驶执照的照片内的其它信息，诸如但不限于：器官捐献状态、证件发行日期或到期日期、证件号、申请人的签名、申请人的相片、申请人的中间名或名字的首字母等。

此后，自动数据聚合控制器104验证从驾驶执照中检索到的名字、姓氏和地址数据，并将规格化的名字数据、规格化的姓氏数据和规格化的地址数据传达给数据分发控制器106。作为响应，数据分发控制器106将规格化的数据插入到(一个或多个)申请的适当字段中，并将完成的(一个或多个)申请转发到相关联的(一个或多个)承保人。以这种方式，数据分发控制器106不从申请人接收任何不必要的信息或任何格式不正确的信息。类似地，承保人也不从申请人接收任何不必要的信息、任何部分完成的申请草稿或任何格式不正确的信息。以这种方式，保护申请人的数据隐私不受第三方侵害。

可以认识到的是，由于限制了由自动数据聚合控制器104收集(并随后发送给数据分发控制器106)的信息，因此减少了申请人不必要的信息披露，并保护了隐私。

自动数据聚合控制器104和数据分发控制器106的具体实施方式可以随实施例而变。在许多情况下，自动数据聚合控制器104和数据分发控制器106被实现为跨一个或多个安全通信信道彼此通信的虚拟和/或物理服务器或服务器集群(或在该虚拟和/或物理服务器或服务器集群上作为存储在非易失性存储器中的计算机指令集实现)。在其它情况下，自动数据聚合控制器104或数据分发控制器106的一个或多个部分可以用可分发到申请人的电子设备(诸如用户设备102)的软件来实现。

一般而言，出于解释的目的，并且为了促进理解诸如本文所述的系统的各种配置，给出了图1中描绘的前述实施例及其各种替代方案及其变体。但是，对于本领域技术人员将显而易见的是，为了实践特定描述的实施例或其等同物，可能不需要本文给出的具体细节中的一些具体细节。

例如，可以理解的是，一般而言并且广泛地，本文所述的实施例将保险申请处理系统的数据收集和验证功能与同一系统的数据分发功能分开和/或隔离。特别地，自动数据聚合控制器与数据分发控制器分开操作。功能分离的结果是，通过防止过度披露和分发不完整的申请来保护申请人的隐私。在另外的实施例中，本文所述的划分的功能还减少了完成多个保险申请所需的时间。特别地，数据分发控制器向自动数据聚合控制器提供了包含内容和验证信息两者的方案。自动数据聚合控制器使用该方案来确定需要什么信息、应当如何格式化表示该信息的数据以及应当访问或请求哪些文档、问题或数据库以便获得该数据。以这种方式，无需来自申请人的大量输入就可以聚合和格式化特定申请所需的所有信息。

本领域技术人员将认识到的是，任何数量的合适数据库和/或自动数据聚合控制器或模块可以与自动数据聚合控制器相关联。例如，诸如本文所述的自动数据聚合控制器可以爬(crawl)各种公共和/或专有数据库，以便收集关于申请的信息，而无需申请人的大量输入。例如，在一个实施例中，申请人经由网页访问自动数据聚合控制器。在这个示例中，网页和/或自动数据聚合控制器可以与社交媒体持久存在插件对接，该插件包含基本身份信息，诸如姓名和电子邮件地址。在申请人的许可下，自动数据聚合控制器可以根据姓名和电子邮件地址访问选民数据库和/或另一个公共数据库，以确定地址、出生日期和家庭状况。利用地址信息并在申请人的许可下，自动数据聚合控制器可以访问房地产数据库来确定所有权信息，诸如财产的法律描述和财产的销售历史。利用出生日期信息和先前获得的姓名信息并且在申请人的允许下，自动数据聚合控制器可以查询多个公共数据库，以获得就业信息、车辆所有权信息等。本领域技术人员将认识到的是，自动数据聚合控制器可以以这种方式继续聚合信息，直到无法获得附加的有用或所需信息为止。此后，自动数据聚合控制器可以请求来自申请人的附加信息(例如，对特定问题的答案、非公开信息等)，此后，聚合过程可以再次开始。

一旦根据方案中的验证定义收集并验证了所需的信息，自动数据聚合控制器就将重新格式化的数据分发到数据分发控制器。此后，数据分发控制器打包数据并将数据分发到一个或多个承保人。

在承保人接收到由数据分发控制器分发的(一个或多个)申请之后，承保人可以将报价传送回数据分发控制器，数据分发控制器又可以将报价直接(或经由自动数据聚合控制器)传达给申请人。申请人可以审阅返回的各种报价，并可以选择报价。一旦选择，交易就可以完成。

因而，可以认识到的是，本文描述的通用系统(其中收集、自动聚合和验证操作在功能上与分发功能分开)可以以任何数量的合适方式来实现。在一些实施例中，自动数据聚合控制器和数据分发控制器被实现为在分离的服务器上操作的分离的服务。在其它情况下，自动数据聚合控制器和数据分发控制器可以是在同一应用包内操作的分离的软件模块。在一些情况下，自动数据聚合控制器和/或数据分发控制器的一个或多个部分在申请人或申请人的代理拥有和/或操作的设备上进行操作。

例如，图2a-图2b描绘了包括电子设备的实施例，该电子设备被配置为访问诸如本文所述的自动数据聚合控制器和/或数据分发控制器，或者以其他方式与诸如本文所述的自动数据聚合控制器和/或数据分发控制器一起操作。但是，将认识到的是，所描绘的示例不是详尽的；参考图2a-图2b描述的各种实施例可以以任何数量的合适的或特定于实现的方式被修改或组合。

具体而言，图2a描绘了电子设备200。电子设备200可以是任何合适的电子设备，例如但不限于：蜂窝电话、平板计算机、膝上型计算机、台式计算机、可连接互联网的设备、可连接内联网的设备等。在一个示例中，电子设备200是无线连接到远程服务器或服务器组的便携式电子设备，但是这可能不是必需的。电子设备200可以包括以下当中的一个或多个：处理器、暂态存储器、非暂态存储器、显示器、用户输入系统、无线或有线通信模块等。在许多情况下，电子设备200被配置为将可由处理器执行的程序指令存储在非暂态存储器中。在一些实施例中，诸如本文所述的系统的一个或多个部分可以全部或部分地实现为存储在电子设备200内或电子设备200可访问的非暂态存储器中的可执行指令。

在所示的实施例中，电子设备200包括壳体202，壳体202包围并容纳显示器204，该显示器204可操作地或通信地耦合到诸如上述的处理器(未示出)。在许多情况下，显示器204可操作地耦合到用户输入系统(诸如触摸输入系统)，以便从电子设备200的用户接收输入。

显示器204可以被配置为呈现与系统(诸如自动数据聚合控制器，诸如本文所述)相关联的图形用户界面204a。与本文所述的其它实施例一样，数据聚合系统可以被配置为全部或部分地在电子设备200上操作。在其它情况下，电子设备200经由安全通信网络与数据聚合系统通信。在其它情况下，数据聚合系统的部分在电子设备200上操作，而其它部分远程操作。

与本文所述的其它实施例一样，数据聚合系统与数据分发系统通信。更特别地，数据聚合系统被配置为从数据分发系统接收通知自动数据聚合控制器的功能和操作的方案。此外，该方案可以包括通知图形用户界面204a要为操作电子设备200的申请人显示哪些字段、图像或指令的信息。

在一个实施例中，图形用户界面204a可以被配置为请求来自申请人的输入(例如，手动输入的数据、照片数据、视频数据、音频数据、生物特征数据、登录数据或信息、文档信息)。例如，图形用户界面204a可以呈现可选择的选项，诸如可选择的选项206。在一些情况下，可以一次选择可选择的选项206中的多于一个可选择的选项。在其它情况下，可选择的选项206中的每个可选择的选项是互斥的。任何时候都只能选择一个选项。图形用户界面204a还可以呈现文本输入字段，诸如输入字段208。输入字段208可以被配置为接收字母数字输入、手绘输入、仅数字输入、仅符号输入等。

图形用户界面204a还可以呈现供用户上传文件的部件，诸如上传字段210。上传字段210可以被配置为通过拖放、经由用户操作的文件选择对话框或通过任何其它合适的方法来接收文件。在一些情况下，上传字段210可以被配置为接收远程文件的网址。上传字段210可以被配置为接收具体或任意格式的文件。图形用户界面204a还可以提供一个或多个输入按钮，诸如提交按钮212。

可以认识到的是，图形用户界面204a可以被配置为以任何数量的合适方式来接收来自用户的输入；在图中识别出的具体示例被理解为是非限制性的。例如，在其它实施例中，图形用户界面204a可以包括但不限于：物理或虚拟输入、照片或视频输入、麦克风输入、生物特征输入、触觉或机械输入等。

在许多实施例中，图形用户界面204a被用于从申请人收集用于保险的信息。更具体而言，操作电子设备200的申请人执行软件申请(或访问web申请的地址)，该软件申请进而呈现图形用户界面204a。如上所述，本申请为申请人提供了对自动数据聚合控制器(未示出)的访问。本申请最初向申请人呈现一系列可选择的选项，诸如可选择的选项206，每个可选择的选项与自动数据聚合控制器支持的特定保险申请类型相关联。例如，在一个实施例中，可选择的选项206中的第一可选择的选项可以与汽车保险相关联，可选择的选项206中的第二可选择的选项可以与房主的保险相关联，并且可选择的选项206中的第三可选择的选项可以与租客的保险相关联。在其它情况下，可以向申请人呈现其它可选择的选项。

在许多示例中，在显示可选择的选项206的同时，其它输入元素可以被隐藏，其它输入元素诸如但不限于：输入字段208、上传字段210和提交按钮212。

一旦申请人做出选择，自动数据聚合控制器就可以将该选择传达给数据分发控制器(未显示)。基于选择和/或其它信息(例如，申请人的位置、时间或日期、申请人的年龄等)，数据分发控制器可以将方案传达给自动数据聚合控制器。

此后，自动数据聚合控制器可以解析该方案，并基于该方案使图形用户界面204a改变以便从申请人请求信息。例如，如果来自数据分发控制器的方案指示申请仅需要来自申请人的身份信息，那么可以将图形用户界面204a修改为仅示出与收集或显示身份信息相关的字段或输入，诸如输入字段208。

一旦经由图形用户界面204a从申请人收集了信息和/或由自动数据聚合控制器自动收集了信息，自动数据聚合控制器就可以验证根据相关联的方案内的一个或多个验证定义而聚合的信息。此后，如相对于本文描述的其它实施例所指出的，自动数据聚合控制器可以将适当格式化的数据传达给数据分发控制器(未示出)。此后，数据分发控制器以合适的行业标准或特定于承保人的格式组装申请，并将申请分发到承保人的集合，承保人的集合进而可以选择将报价返回给申请人，报价可以作为报价的集合214显示在图形用户界面204a(例如，参见图2b)上。此后，申请人可以从报价的集合214中选择报价，并购买216来自相应的承保人的保险单。

一般而言，出于解释的目的，并且为了促进理解诸如本文所述的系统的各种配置，给出了图2a-图2b中描绘的前述实施例及其各种替代方案及其变体。但是，对于本领域的技术人员将显而易见的是，为了实践特定描述的实施例或其等同物，可能不需要这里给出的具体细节中的一些具体细节。

例如，可以认识到的是，所描绘的用户设备和图形用户界面可以采用任何数量的合适形式，并且可以随实施例而变。例如，在一些情况下，如上所述，用户设备可以是膝上型计算机。在其它情况下，申请人的代理可以代表用户访问自动数据聚合控制器。在这些情况下，代理可以接收与申请人不同的用户界面。类似地，由数据分发控制器递送给自动数据聚合控制器的方案对于代理而言可以不同于申请人。例如，与代理相关联的方案可以使图形用户界面呈现被配置为接受行业标准数据文件的上传的字段，而与申请人相关联的方案可以使图形用户界面呈现被配置为接受用户提供的文档的字段。照此，更一般而言，可以认识到的是，当由行业专业人士(例如，代理)访问时，诸如本文所述的系统可以与当申请人直接访问该系统时不同地配置。

其它实施例可以以不同的方式实现。例如，在一些情况下，自动数据聚合控制器和数据分发控制器可以由一般称为系统协调器的分离的系统进行协调。

图3描绘了诸如本文所述的系统协调器的简化系统图。系统协调器可以被配置为控制、执行和/或协调诸如本文所述的自动数据聚合控制器或数据分发控制器的一个或多个功能。系统协调器可以被实现为可配置为执行诸如本文所述的功能和操作(及其替代物)的服务器、一组服务器或任何其它合适的系统。可以认识到的是，为了简化图示和描述，从图3中省略了由系统协调器实现和/或监督的自动数据聚合控制器和数据分发控制器的部分。

更具体而言，诸如本文所述的系统协调器300包括请求发起器302、请求处理器304和承保人接口306。模块、部件或子系统中的每一个可以以任何合适的特定于实现的方式来配置。在一些情况下，系统协调器300的子系统可以被实现为物理上分离的部件，但是并非所有实施例都要求这样做。

诸如本文所述的系统协调器300的请求发起器302可以被配置为从用户设备、代理设备或从诸如本文所述的自动数据聚合控制器接收请求。请求通常是发起新保险申请的请求，但这可以随实施例而变。请求可以是任何合适的请求，包括但不限于：文本或数据消息、电话呼叫、电子邮件、应用编程接口访问等。

例如，在一个实施例中，请求发起器302包括网络接口，用于安全地从一个或多个设备(诸如用户设备或代理设备)发送和接收指令或请求。指令或请求可以包括账户凭证或其它私人或机密信息。

请求发起器302可以确定对请求或指令的适当响应。例如，如果用户设备或代理设备将可以由系统处理的请求发送到请求发起器302，那么请求发起器302可以将指令发送到请求处理器304。

诸如本文所述的系统协调器300的请求处理器304可以被配置为协调诸如本文所述的自动数据聚合控制器和数据分发控制器之间的信息交换(例如，参见图1)。在一些情况下，请求处理器304可以被配置为自动数据聚合控制器和数据分发控制器之间的中介，而在其它情况下，请求处理器304可以仅促进自动数据聚合控制器和数据分发控制器之间的安全信息交易。一旦申请完成(例如，自动数据聚合控制器已收集、验证并格式化所有必需的信息)，请求处理器304就可以将申请转发到承保人接口306(例如，由承保人或经纪人管理的贷款发起软件)。

诸如本文所述的系统协调器300的承保人接口306可以被配置为选择申请并将申请分发到特定的承保人。在一些情况下，承保人接口306可以被配置为与某些承保人的定制申请编程接口对接，但这可能不是必需的。例如，在一些实施例中，承保人接口306可以以行业标准格式向所选择的承保人的集合提供申请。

一般而言，出于解释的目的，并且为了促进对系统协调器的各种配置的理解，给出了图3中描绘的前述实施例及其各种替代方案及其变体。但是，对于本领域技术人员将显而易见的是，为了实践特定描述的实施例或其等同物，可能不需要本文给出的具体细节中的一些具体细节。

一般而言并且广泛地，图4-图8描绘了诸如本文所述的系统的各个部分、子系统和/或具体实现。

图4是诸如本文所述的另一个系统的简化流程图。系统400实现诸如本文所述的自动数据聚合控制器和数据分发控制器的功能。

系统400包括请求发起器402，该请求发起器402接收对数据聚合操作的申请人或代理请求。请求发起器402与请求处理器404通信。请求处理器404进而可通信地耦合到一个或多个外部数据库(识别为可访问的数据库406)和一个或多个承保人接口(识别为承保人接口408)。

系统400的请求处理器404包括数据聚合器410。数据聚合器410可通信地耦合到数据规格化控制器412和分发控制器414。

数据聚合器410与诸如本文所述的自动数据聚合控制器相关联。因而，数据聚合器410可以被配置为以任何合适的方式从申请人或代理收集信息，这些方式包括但不限于：文档上传和读取、远程文档链接、手动数据输入、照相或扫描文档上传、数字签名等。数据聚合器410还可通信地耦合到可访问的数据库406，可访问的数据库406可以包括车辆数据库416、财务数据库418、财产数据库420或任何其它合适的数据库422。本领域技术人员将认识到的是，数据聚合器410可以包括和/或可访问任何数量的合适的数据库，无论是本地的还是远程的或者第一方或第三方的。

与本文所述的其它实施例一样，数据聚合器410可以被配置为以任何数量的合适方式以数字数据的形式从申请人或申请人的代理接收和/或收集信息。例如，在许多实施例中，数据聚合器410被配置为从各种本地或远程信息源(例如，可访问的数据库406)收集、验证和组织与申请人相关(或由申请人直接提供)的信息。来自申请人的信息可以包括任何适当的信息，诸如但不限于：身份信息、税收信息、不动产或个人财产信息、收入信息、储蓄信息、债务信息、家庭信息、房地产信息、就业信息等。

表示来自申请人(或与申请人相关联)的具体信息的具体数字数据可以由数据聚合器410从各种来源和/或以各种形式或格式来接收或产生，包括但不限于：手动输入的数据、检索到的数据、提取的数据、推断的数据和/或计算的数据。

一旦被收集为数字数据，数据聚合器410就可以将原始收集的数据传递给数据规格化控制器412。数据规格化控制器412被配置为通过执行合适的数据验证操作以验证数据来生成规格化的数据。在一些示例中，数据验证操作可以包括但不限于：拼写验证、语法验证、格式验证、数值范围验证、被禁字符检查、数据清理操作等等。在许多情况下，数据规格化控制器412执行的数据验证技术和操作可以随申请和/或随申请人而变。

此后，将规格化的数据传递给分发控制器414，分发控制器414进而被配置为将规格化的数据插入到特定于承保人的或与承保人无关的格式中，该格式可经由承保人接口408分发到一个或多个承保人。这样的承保人可以包括承保人424、426、428。以这种方式，与本文所述的其它实施例一样，在分发之前，申请人或代理或请求发起器提供的信息被过滤、验证和格式化。以这种方式，保护申请人的隐私不被保险公司和第三方数据库管理员损害。

在其它实施例中，可以以另一种方式配置诸如本文所述的系统。例如，图5描绘了诸如本文所述的用于自动收集和验证结构化和非结构化数据的系统的简化流程图。与本文所述的其它实施例一样，系统500实现诸如本文所述的自动数据聚合控制器和/或数据分发控制器的一个或多个部件或功能。

系统500包括请求发起器502，该请求发起器502接收申请人或代理的请求以开始数据聚合操作。在所示的实施例中，请求发起器502可以被配置为在桌面计算设备上操作，但是并非所有实施例都要求这样做。

与本文描述的其它实施例一样，请求发起器502与请求处理器504通信，该请求处理器504进而与一个或多个外部数据库506通信。这个实施例中的请求处理器504包括输入控制器508、数据规格化控制器510、数据聚合器512和数据处理器514。数据处理器514又可以耦合到一个或多个可访问的数据库506。本领域技术人员将认识到的是，数据聚合器512可以包括和/或可访问任何数量的合适的数据库，无论是本地的还是远程的或者第一方或第三方的。

与本文所述的其它实施例一样，系统500的请求处理器504实现诸如本文所述的自动数据聚合控制器的某些功能。更特别地，请求处理器504的输入控制器508可以被配置为与请求发起器502通信以从申请人或代理接收输入。在其它情况下，输入控制器508可以被配置为生成或处理可以被分发到请求发起器或数据规格化控制器510的一个或多个方案和/或验证定义。

与本文所述的其它实施例一样，数据聚合器512是与诸如本文所述的自动数据聚合控制器相关联的物理或软件部件。因而，数据聚合器512可以被配置为以任何合适的方式从申请人或代理收集信息，包括但不限于：文档上传和读取、远程文档链接、手动数据输入、照相或扫描文档上传、数字签名、文档或信息旁白(narration)等。

数据聚合器512还经由数据处理器514可通信地耦合到可访问的数据库506。以这种方式，数据处理器514用作第三方数据库与自动数据聚合控制器的部分之间的中介。

与本文所述的其它实施例一样，数据聚合器512可以被配置为以任何数量的合适方式以数字数据的形式从申请人或申请人的代理接收和/或收集信息。例如，在许多实施例中，数据聚合器512被配置为从各种本地或远程信息源(例如，可访问的数据库506)收集、验证和组织与申请人相关(或由申请人直接提供)的信息。来自申请人的信息可以包括任何适当的信息，诸如但不限于：身份信息、税收信息、不动产或个人财产信息、收入信息、储蓄信息、债务信息、家庭信息、房地产信息、就业信息等。

如上所述，表示来自申请人(或与申请人相关联)的特定信息的特定数字数据可以由数据聚合器512从各种来源和/或以各种形式或格式接收或产生，包括但不限于：手动输入的数据、检索到的数据、提取的数据、推断的数据和/或计算的数据。

一旦被收集为数字数据，数据聚合器512就可以将原始收集的数据传递给数据规格化控制器510。数据规格化控制器510被配置为通过执行适当的数据验证操作来验证数据以生成规格化数据。在一些示例中，数据验证操作可以包括但不限于：拼写验证、语法验证、格式验证、数值范围验证、被禁字符检查、数据清理操作等。在许多情况下，数据规格化控制器510执行的数据验证技术和操作可以随申请和/或随申请人而变。

此后，规格化的数据被传递回输入控制器508，输入控制器508又可以将该数据呈现给请求发起器502，以进行申请人或代理的验证或核实。

在其它实施例中，可以以另一种方式配置诸如本文所述的系统。例如，图6是用于自动结构化来自未知源的数据的系统的简化流程图。

与本文所述的其它实施例一样，系统600实现诸如本文所述的自动数据聚合控制器和/或数据分发控制器的一个或多个部件或功能。特别地，系统600是诸如本文所述的自动数据聚合控制器的一部分，其被配置为从未知源或质量中提取信息结构化文档或非结构化文档。在一些示例中，结构化或非结构化文档可以是税收文档，未知源可以是：税收文档的扫描、税收文档的照片、带有文本层的便携式文档格式的税收文档、没有文本层的便携式文档格式的税收文档等。在另一个示例中，结构化文档可以是行业标准格式，诸如住宅贷款数据格式1003。

与其它实施例一样，系统600包括请求发起器602，该请求发起器602接收申请人或代理的请求以开始数据聚合操作。在所示的实施例中，请求发起器602可以被配置为在桌面计算设备上操作，但是并非所有实施例都要求这样做。在这个示例中，请求发起器602被配置为向数据处理器606传输或以其它方式发送一个或多个结构化文档604。

这个实施例中的数据处理器606包括网络接口608、存储器610和处理器612。网络接口608可通信地耦合到请求发起器602，并且可以被配置为将从请求发起器602接收的信息或数据(包括一个或多个结构化文档604)传达给处理器612。

数据处理器606可通信地耦合到文档处理管道(pipeline)，该文档处理管道包括栅格化器614、图像预处理器616、数据提取器618、数据验证器620和表格填充器622。

在这个示例中，文档处理管道被配置为规格化根据结构化文档的处理和数据提取，而不管文档的源或文档交付格式的质量如何。例如，这个实施例的文档处理管道可以被配置为处理但不限于：栅格化文档、向量文档、图像文档、视频文档等。

系统600的文档处理管道的栅格化器614被配置为栅格化(例如，数字化)从请求发起器602接收的结构化文档，包括一个或多个结构化文档604。如本文所使用的，短语“结构化文档”一般是指已知以特定格式或在特定位置包含或记载具体信息的文档或形式。结构化文件可以是收据、税表、损益表(incomestatement)、银行对账单、驾驶执照、护照等。如本文中所使用的，短语“非结构化文档”一般是指可以在任意位置或格式中包括不同数据的文档。

系统600的文档处理管道的图像预处理器616可以从栅格化器614接收结构化文档的数字化和/或栅格化版本。图像预处理器616可以对栅格化的文档执行任何数量的适当文档处理操作，包括但不限于：去歪斜、阈值化、二值化、旋转、噪声过滤等。在一些情况下，图像预处理器616可以对每个文档执行相同的图像处理操作，而在其它情况下，可以将不同的操作或操作次序应用于不同的检测到的或已知的文档类型、文档格式或文档源。

系统600的文档处理管道的数据提取器618可以从图像预处理器616接收预处理的栅格化文档，并且可以执行光学字符识别操作以从栅格化文档中提取文本信息。数据提取器618还可以被配置为从文本信息中提取某些信息。例如，数据提取器618可以包括被配置为匹配字符的某些模式的一个或多个正则表达式引擎。

系统600的文档处理管道的数据验证器620可以接收数据提取器618的输出，并且可以根据(例如，来自方案的)验证定义验证该数据。

系统600的文档处理管道的表单填充器622可以从数据验证器620接收经验证的数据，并且进而可以填充在请求发起器602上显示的一个或多个表单字段。

在其它实施例中，可以以另一种方式配置诸如本文所述的系统。例如，图7是用于自动处理结构化数据的系统的简化流程图。

与本文所述的其它实施例一样，系统700实现诸如本文所述的自动数据聚合控制器和/或数据分发控制器的一个或多个部件或功能。特别地，系统700是诸如本文所述的自动数据聚合控制器的一部分，其被配置为以已知格式提取信息结构化文档。在一些示例中，结构化文档可以是税务文档，未知源可以是：对象模型、纯文本文档、标记文档、教练(instructor)标准格式等。

与其它实施例一样，系统700包括请求发起器702，该请求发起器702接收申请人或代理的请求以开始数据聚合操作。在所示的实施例中，请求发起器702可以被配置为在桌面计算设备上操作，但是并非所有实施例都要求这样做。在这个示例中，请求发起器702被配置为向数据处理器706传输或以其它方式发送一个或多个结构化文档704。

与本文所述的其它实施例一样，这个实施例中的数据处理器706包括网络接口708、存储器710和处理器712。网络接口708可通信地耦合到请求发起器702，并且可以被配置为将从请求发起器702接收的信息或数据(包括一个或多个结构化文档704)传达给处理器712。

数据处理器706可通信地耦合到文档处理管道，该文档处理管道包括数据提取器714、数据验证器716和表格填充器718。

系统700的文档处理管道的数据提取器714可以从请求发起器702接收一个或多个结构化文档，包括一个或多个结构化文档704。数据提取器714被配置为从包含在结构化文档中的文本信息中提取信息。例如，数据提取器714可以包括被配置为匹配字符的某些模式的一个或多个正则表达式引擎。在另一个示例中，数据提取器714被配置为基于一个或多个文档标签或格式标题来处理结构化文档。

系统700的文档处理管道的数据验证器716可以接收数据提取器714的输出，并且可以根据(例如，来自方案的)验证定义验证该数据。

系统700的文档处理管道的表单填充器718可以从数据验证器716接收经验证的数据，并且进而可以填充在请求发起器702上显示的一个或多个表单字段。

还有另外的实施例可以以不同的方式实现。例如，图8是用于自动验证手动输入的数据的系统的简化流程图。

与本文所述的其它实施例一样，系统800实现诸如本文所述的自动数据聚合控制器和/或数据分发控制器的一个或多个部件或功能。特别地，系统800是诸如本文所述的自动数据聚合控制器的一部分，其被配置为从手动输入的数据中提取信息。

与其它实施例一样，系统800包括请求发起器802，该请求发起器802接收申请人或代理的请求以开始数据聚合操作。在所示的实施例中，请求发起器802可以被配置为在桌面计算设备上操作，但是并非所有实施例都要求这样做。在这个示例中，请求发起器802被配置为向数据处理器804传输或以其它方式手动发送输入数据，该数据处理器又可以耦合到一个或多个可访问的数据库(第一方或第三方)。可访问的数据库被识别为数据库806。

与本文所述的其它实施例一样，这个实施例中的数据处理器804包括网络接口808、存储器810和处理器812。网络接口808可通信地耦合到请求发起器802，并且可以被配置为将从请求发起器802接收的信息或数据传达给处理器812。

数据处理器804可通信地耦合到数据处理管道，该数据处理管道包括数据验证器814和表格填充器816。与本文所述的其它实施例一样，系统800的数据处理管道的数据验证器814可以接收数据验证器814的输出，并且可以根据(例如，来自方案的)验证定义验证该数据。在这个实施例中，数据验证器814还可以被配置为与数据库806对接以便验证手动输入的数据。

系统800的数据处理管道的表单填充器816可以从数据验证器814接收经验证的数据，并且进而可以填充在请求发起方802上显示的一个或多个表单字段。

一般而言，出于解释的目的，并且为了促进理解诸如本文所述的自动数据聚合系统的各种配置，给出了在图3-图8中描绘的前述实施例及其各种替代方案及其变体。但是，对于本领域技术人员将显而易见的是，为了实践特定描述的实施例或其等同物，可能不需要本文呈现的具体细节中的一些具体细节。

还有另外的实施例引用诸如本文所述的操作自动数据聚合控制器、数据分发控制器和/或系统协调器的方法。

图9是描绘处理来自未知源的结构化或非结构化数据的方法的示例操作的流程图。可以通过任何合适的电子设备、服务器设备或其组合(无论是虚拟的还是物理的)来全部或部分地实现和/或执行所描述的方法。在许多实施例中，该方法与诸如本文所述的自动数据聚合控制器、数据分发控制器或系统协调器(或其组合)相关联。

方法900在操作902处开始，在操作902中接收非结构化文档。接下来，在操作904处，可以对非结构化文档进行栅格化。不管非结构化文档中是否存在文本层，都可以对文档进行栅格化。接下来在操作906处，可以识别栅格化的文档中的文本(例如，光学字符识别操作)。接下来，在操作908处，可以从识别自栅格化的文档的文本中识别和/或提取数据。最后，在操作910处，可以将提取的数据传递到诸如本文所述的数据聚合器。

图10是描绘聚合和处理结构化数据的方法的示例操作的流程图。可以通过任何合适的电子设备、服务器设备或其组合(无论是虚拟的还是物理的)来全部或部分地实现和/或执行所描述的方法。在许多实施例中，该方法与诸如本文所述的自动数据聚合控制器、数据分发控制器或系统协调器(或其组合)相关联。

方法1000在操作1002处开始，在操作1002中接收结构化文档。在操作1004处，从结构化文档中提取数据，该数据可以是行业标准或以其它方式指定的格式。在一个实施例中，结构化文档可以包括文档树或字节流，其可以通知某些数据的位置。在其它情况下，可以以另一种方式(例如，正则表达式)提取数据。在操作1006处，可以将提取的数据传递到诸如本文所述的数据聚合器。

图11是描绘最小化手动数据输入的方法的示例操作的流程图。可以通过任何合适的电子设备、服务器设备或其组合(无论是虚拟的还是物理的)来全部或部分地实现和/或执行所描述的方法。在许多实施例中，该方法与诸如本文所述的自动数据聚合控制器、数据分发控制器或系统协调器(或其组合)相关联。

方法1100在操作1102处开始，在操作1102中接收用户输入。用户可以是申请人、申请人的代理、与申请人进行业务往来的公司(例如银行)的员工或任何其他合适的且授权的人。在操作1104处，可以基于在操作1102处接收的信息来确定显示方案，该显示方案可以包括验证定义。最终在操作1106处，可以基于显示方案来更新用户设备的显示。

图12是描绘验证手动输入的数据的方法的示例操作的流程图。可以通过任何合适的电子设备、服务器设备或其组合(无论是虚拟的还是物理的)来全部或部分地实现和/或执行所描述的方法。在许多实施例中，该方法与诸如本文所述的自动数据聚合控制器、数据分发控制器或系统协调器(或其组合)相关联。

方法1200在操作1202处开始，在操作1202中接收用户输入。与其它实施例一样，用户可以是申请人、申请人的代理、与申请人进行业务往来的公司(例如，银行)的员工或任何其他合适的且授权的人。在操作1204处，可以基于在操作1202处接收的信息来确定验证定义，该验证定义可以包括在从诸如本文所述的数据分发控制器接收的方案中。最终在操作1206处，可以根据在1204处接收的验证定义来验证用户在操作1202处提供的信息或输入。

图13是描绘确定是否可以从结构化数据源获取具体数据的方法的示例操作的流程图。可以通过任何合适的电子设备、服务器设备或其组合(无论是虚拟的还是物理的)来全部或部分地实现和/或执行所描述的方法。在许多实施例中，该方法与诸如本文所述的自动数据聚合控制器、数据分发控制器或系统协调器(或其组合)相关联。

方法1300在操作1302处开始，在操作1302中确定具体形式所需的具体数据。在一些情况下，数据可以与若干承保人相关联，每个承保人与特定位置和/或特定保险类型相关联。具体数据可以是所有承保人所需的数据，包括公共数据和仅单个承保人特有地需要的数据。数据可以包括：姓名数据、地址数据、对某些问题的答案、财务数据、收入数据、债务数据、财产所有权数据等。

接下来，在操作1304处，该方法可以确定数据是否可从第三方数据库获得。例如，姓名数据和地址数据可以从第三方数据库(例如，税收信息数据库)获得，而对某些问题的答案可能无法经由第三方或第一方数据库获得。

接下来，在操作1306处，被确定为可从一个或多个第三方数据库获得的数据可以从那些数据库获得。一旦从那些数据库中检索到数据，就可以根据验证定义来验证数据。在一些情况下，数据可以被用于预填充或自动填充表单(例如，申请)。在一些情况下，访问单个数据库以获得具体信息，而在其它情况下，可以使用冗余的访问。

图14是描绘促进有约束力的交易的方法的示例操作的流程图。可以通过任何合适的电子设备、服务器设备或其组合(无论是虚拟的还是物理的)来全部或部分地实现和/或执行所描述的方法。在许多实施例中，该方法与诸如本文所述的自动数据聚合控制器、数据分发控制器或系统协调器(或其组合)相关联。

方法1400在操作1402处开始，在操作1402中选择特定承保人的保险单。此后，在操作1404处，可以通过根据报价的条款约束申请人和承保人来完成保险交易。

一般而言，出于解释的目的，并且为了促进理解诸如本文所述的用于操作自动数据聚合系统的各种方法，给出了图9-图14中描绘的前述实施例及其各种替代方案及其变体。但是，对于本领域技术人员将显而易见的是，为了实践特定描述的实施例或其等同物，可能不需要本文给出的具体细节中的一些具体细节。

可以认识到的是，虽然以上公开了许多实施例，但是关于本文描述的方法和技术给出的操作和步骤仅仅是示例性的，因而并不详尽。还可以认识到的是，对于特定实施例，可能需要或期望替代的步骤次序或更少或附加的操作。

虽然上面的公开内容是依据各种示例性实施例和实现来描述的，但是应当理解的是，在一个或多个单独的实施例中描述的各种特征、方面和功能就其适用性而言不限于描述它们所利用的特定实施例，而是代替地可单独地或以各种组合应用到本发明的一些实施例中的一个或多个实施例，不管这种实施例是否被描述以及这些特征是否作为所述实施例的一部分被给出。因此，本发明的广度和范围不应当受上述示例性实施例中的任何实施例的限制而是代替地由本文给出的权利要求定义。