CN106469196A - 数据处理方法及其装置、投保方法及其投保系统 - Google Patents

Abstract

本发明公开了一种数据处理方法及其装置、投保方法及其投保系统。一种数据处理方法，包括：接收发送的查询请求，其中所述查询请求中包括类型信息和要素信息；根据所述类型信息调用相应的查询接口；通过所述查询接口调用相应的逻辑模块，所述逻辑模块根据所述要素信息获得相应的查询结果并返回。该数据处理方法通过调用相应的接口来复用核心系统中的保费计算逻辑，一方面能够保证保费试算和投保时的保费计算的一致性，另一方面能够降低众多的外围系统不必再导入保费因子，节约了开发资源。

Description

数据处理方法及其装置、投保方法及其投保系统

技术领域

本发明涉及计算机技术领域，具体而言，涉及一种数据处理方法及其装置、投保方法及其投保系统。

背景技术

现有技术中的保险核心系统只在系统内定义每个险种的保费计算方法，在录入保险计划时计算保费，不会为外围系统(例如电销、网站、电投、银保等渠道)提供保费试算服务。因此，在用户选择保险计划之后进行投保之前需要试算保险费时，需要各外围系统在各自的系统中分别具有保费试算的功能。例如电销渠道需要在系统中开发电销保费计算功能，网销渠道需要在系统中开发网销保费计算功能，电投渠道需要在系统中开发电投保费计算功能，银保渠道需要在系统中开发银保保费计算功能等。这种核心系统和外围系统保费计算功能的重复，导致了多套系统中都需要保存保费计算因子，造成了存储资源的浪费，浪费了开发资源。此外，还易导致在中间环节由于保费的误差而难以投保，例如不同系统计算中由于四舍五入的原因产生结果差异。

因此，需要一种新的数据处理方法及其装置、投保方法及其投保系统。

发明内容

有鉴于此，本发明提供一种数据处理方法及其装置、投保方法及其投保系统，能够提升保费试算的处理效率，并避免对系统资源的大幅占用。

本发明的其他特性和优点将通过下面的详细描述变得显然，或部分地通过本发明的实践而习得。

根据本公开的一个方面，提供一种数据处理方法，包括：接收查询请求，其中所述查询请求中包括类型信息和要素信息；根据所述类型信息调用相应的查询接口；通过所述查询接口调用相应的逻辑模块，所述逻辑模块根据所述要素信息获得相应的查询结果并返回。

在本公开的一种示例性实施例中，所述查询请求中的每一类型包括至少一个种类，每一种类包括多个要素。

在本公开的一种示例性实施例中，还包括：将每一种类以及每一种类对应的多个要素预先存储于一数据库中；从所述数据库中选择相应的种类配置成一类型，并根据所述配置生成所述类型的一配置信息表。

在本公开的一种示例性实施例中，还包括：判断所述配置信息表是否与一预设规则冲突。

在本公开的一种示例性实施例中，一个查询请求对应于一类型，所述类型中包括一第一种类和一第二种类，所述第一种类包括一第一要素信息，所述第二种类包括一第二要素信息。

在本公开的一种示例性实施例中，所述逻辑模块根据所述要素信息获得相应的查询结果并返回，包括：所述逻辑模块根据所述第一要素信息获得所述第一种类的一第一查询结果；所述逻辑模块根据所述第二要素信息获得所述第二种类的一第二查询结果；所述逻辑模块根据所述第一查询结果和所述第二查询结果获得所述类型的综合查询结果；所述逻辑模块将所述第一查询结果、所述第二查询结果和所述综合查询结果均返回。

根据本公开的一个方面，提供一种数据处理装置，包括：接收模块，用于接收查询请求，其中所述查询请求中包括类型信息和要素信息；调用模块，用于根据所述类型信息调用相应的查询接口；以及发送模块，用于通过所述查询接口调用相应的逻辑模块，所述逻辑模块根据所述要素信息获得相应的查询结果并返回。

在本公开的一种示例性实施例中，所述查询请求中的每一类型包括至少一个种类，每一种类包括多个要素。

在本公开的一种示例性实施例中，还包括：预置模块，用于将每一种类以及每一种类对应的多个要素预先存储于一数据库中；配置模块，用于从所述数据库中选择相应的种类配置成一类型，并根据所述配置生成所述类型的一配置信息表。

在本公开的一种示例性实施例中，还包括：第一判断模块，用于判断所述配置信息表是否与一预设规则冲突。

在本公开的一种示例性实施例中，一个查询请求对应于一类型，所述类型中包括一第一种类和一第二种类，所述第一种类包括一第一要素信息，所述第二种类包括一第二要素信息。

在本公开的一种示例性实施例中，所述发送模块包括：第一结果获取单元，用于所述逻辑模块根据所述第一要素信息获得所述第一种类的一第一查询结果；第二结果获取单元，用于所述逻辑模块根据所述第二要素信息获得所述第二种类的一第二查询结果；综合结果获取单元，用于所述逻辑模块根据所述第一查询结果和所述第二查询结果获得所述类型的综合查询结果；发送单元，用于所述逻辑模块将所述第一查询结果、所述第二查询结果和所述综合查询结果均返回。

根据本公开的一个方面，提供一种投保方法，包括：发送一查询请求，其中所述查询请求中包括类型信息和要素信息；接收根据所述类型信息和所述要素信息返回的查询结果；根据所述查询结果发送一投保请求。

根据本公开的一个方面，提供一种投保系统，包括：查询接口，用于响应于接收到的查询请求调用相应的逻辑模块，其中所述查询请求中包括类型信息和要素信息；逻辑模块，用于根据所述查询请求中的所述要素信息获得相应的查询结果；通信模块，用于返回所述查询结果并接收投保请求，其中所述投保请求基于所述查询结果发出。

在本公开的一种示例性实施例中，还包括：存储模块，用于存储所述查询结果。

根据本发明示例实施方式提供的数据处理方法及其装置、投保方法及其核心系统，通过复用核心系统的保费计算逻辑提供保费试算通用服务，能够满足各险种保费计算要素的输入，将保费试算结果返回前端系统，便于前端系统展示给客户。

另一方面，根据本发明的一些示例实施方式，保费试算方法在核心系统中可以根据保险计划的不同而灵活定义和配置，极大的减少了开发量。

应当理解的是，以上的一般描述和后文的细节描述仅是示例性的，并不能限制本发明。

附图说明

通过参照附图详细描述其示例实施例，本发明的上述和其它目标、特征及优点将变得更加显而易见。

图1是根据一示例性实施方式示出的一种数据处理方法的流程图。

图2是图1所述数据处理方法基于的一种示例性系统架构图。

图3是基于图2所示的系统架构图的另一种数据处理方法的流程图。

图4是根据一示例性实施方式示出的数据处理装置的框图。

图5是根据一示例性实施方式示出的投保方法的流程图。

图6是根据一示例性实施方式示出的投保系统的框图。

具体实施方式

现在将参考附图更全面地描述示例实施方式。然而，示例实施方式能够以多种形式实施，且不应被理解为限于在此阐述的范例；相反，提供这些实施方式使得本发明将更加全面和完整，并将示例实施方式的构思全面地传达给本领域的技术人员。附图仅为本发明的示意性图解，并非一定是按比例绘制。图中相同的附图标记表示相同或类似的部分，因而将省略对它们的重复描述。

此外，所描述的特征、结构或特性可以以任何合适的方式结合在一个或更多实施方式中。在下面的描述中，提供许多具体细节从而给出对本发明的实施方式的充分理解。然而，本领域技术人员将意识到，可以实践本发明的技术方案而省略所述特定细节中的一个或更多，或者可以采用其它的方法、组元、装置、步骤等。在其它情况下，不详细示出或描述公知结构、方法、装置、实现或者操作以避免喧宾夺主而使得本发明的各方面变得模糊。

图1是根据一示例性实施方式示出的一种数据处理方法的流程图。

如图1所示，在步骤S110中，接收查询请求，其中所述查询请求中包括类型信息和要素信息。

在示例性实施例中，所述查询请求中的每一类型包括至少一个种类，每一种类包括多个要素。

在示例性实施例中，一个查询请求对应于一类型，所述类型中包括一第一种类和一第二种类，所述第一种类包括一第一要素信息，所述第二种类包括一第二要素信息。

例如，针对保险行业，所述查询请求可以是保费试算请求。其中所述保费试算请求中包括保险产品即类型信息，通常一个保险产品对应一个保费试算请求。一个保险产品中通常可以设置多个保险险种(例如，健康险、意外险、寿险、养老保险等)。每个险种可以提取出多个保费试算因子即该险种的要素信息。例如一个保费试算请求对应一个保险计划，该保险计划中包括第一保险险种和第二保险险种，所述第一保险险种包括多个第一保费试算因子即所述第一要素信息，所述第二保险险种包括多个第二保费试算因子即所述第二要素信息。

其中各个险种的保费试算因子可以包括公司名称、缴费频率、险种代码、死亡等级、保额、总保费、基础保费、加费、投保人和/被保险人年龄、投保人和/被保险人性别、缴费期、风险期间、当前日期、被保险人是否吸烟、被保险人意外死亡率、加费原因等，还可以包括年金、加费预留等试算因子。

虽然上述实施例以保险行业的保费试算为例进行说明，但本发明不以此为限。且虽然本发明上述实施例仅例举了一个保险计划包括两种保险险种，但实际上一个保险计划中包括的保险险种数量并不受限制，可以只包括一个，也可以包括多个。

在示例性实施例中，还包括：将每一种类以及每一种类对应的多个要素预先存储于一数据库中；从所述数据库中选择相应的种类配置成一类型，并根据所述配置生成所述类型的一配置信息表。

还是以上述保费试算为例进行说明，可预先在所述数据库中存储各个保险险种及各个险种对应的保费试算因子，相当于为用户提供了一个险种池子(pool)。各个保险计划可以根据需求从该险种池子中自主选择相应的险种。例如选择一个险种配置为该保险计划的主险种，选择另一个或者多个险种配置为该保险计划的附加险，并根据这些配置将其存储到该保险计划的所述配置信息表中。用户进行相应保险计划的保费试算请求时，将该配置信息表相应的发送给系统。

在一些实施例中，还可以包括：设置各个险种计划中包括的保险险种的预设个数。例如，可以设置一个险种计划中最多不超过20个保险险种。当然，具体的预设个数可以根据系统需求自主设置，本发明不以此为限。

在示例性实施例中，还包括：判断所述配置信息表是否与一预设规则冲突。

其中所述预设规则可为投保规则。根据所述投保规则来判断一个保险计划中的险种配置是否符合要求。例如，针对一个成人被保险人，其对应的保险计划中就不可能包括专门针对孩童的保险险种等。

在步骤S120中，根据所述类型信息调用相应的查询接口。

其中，所述查询接口可为保费试算接口。可在系统中预先根据保险公司推出的各个保险计划设置相应的查询接口，各个查询接口对应不同的保费试算逻辑，各个保费试算逻辑分别针对各个保险计划中的保险险种及该各个保险险种中包含的保费试算因子进行配置。

在步骤S130中，通过所述查询接口调用相应的逻辑模块，所述逻辑模块根据所述要素信息获得相应的查询结果并返回。

在一些实施例中，所述逻辑模块中还考虑了该保险计划的折扣因素。

在示例性实施例中，所述逻辑模块根据所述要素信息获得相应的查询结果并返回，包括：所述逻辑模块根据所述第一要素信息获得所述第一种类的一第一查询结果；所述逻辑模块根据所述第二要素信息获得所述第二种类的一第二查询结果；所述逻辑模块根据所述第一查询结果和所述第二查询结果获得所述类型的综合查询结果；所述逻辑模块将所述第一查询结果、所述第二查询结果和所述综合查询结果均返回。

以上述一个保险计划包括两个保险险种为例进行说明。所述查询结果可以包括第一保险险种的险种代码、该第一保险险种的保额、该第一保险险种的保费、该第一保险险种的基础保费以及该第一保险险种的基础加费等，还可以包括第二保险险种的险种代码、该第二保险险种的保额、该第二保险险种的保费、该第二保险险种的基础保费以及该第二保险险种的基础加费等，还可以包括该保险计划的查询结果返回状态(成功或者失败)、保单总保额、保单总保费、保单总基础保费以及保单总加费等。

在另一些实施例中，所述查询结果也可以仅返回该保险计划的查询结果返回状态、保单总保额、保单总保费、保单总基础保费以及保单总加费等。需要说明的是，虽然上述以一个保险计划包括两个保险险种为例进行举例说明，但如果一个保险计划包括两个以上的保险险种，不仅返回整个保险计划的保费试算合计结果，还可以分别针对各个保险险种返回各个险种的保费试算明细结果。

这样，只需要调用一次保费试算接口，即可返回整个保险计划下每个险种各自的保费以及保险计划的合计保费，避免了多次调用，提高了调用、查询的效率。

本实施方式提供的数据处理方法，通过调用系统提供的统一的查询接口，能够快速获得查询结果，保证了保费试算和最终投保时保费结果的一致性，同时众多的外围系统不必再导入繁杂的试算因子，不必再开发保费试算功能，节约了开发资源，节省了存储资源。

应清楚地理解，本发明描述了如何形成和使用特定示例，但本发明的原理不限于这些示例的任何细节。相反，基于本发明公开的内容的教导，这些原理能够应用于许多其它实施方式。

图2是图1所述数据处理方法基于的一种示例性系统架构图。

如图2所示，该系统架构包括：各个投保渠道210、前端系统(front_end)220、保费试算通用服务230以及核心系统240。

其中电销渠道可以直接和核心系统240、保费试算通用服务230直接双向通信。网站、电投和银保通等渠道通过前端系统220和核心系统240、保费试算通用服务230双向通信。保费试算通用服务230连接核心系统240和各个外围系统。

其中各个投保渠道210可以包括电销、网站、电投、银保通等。

其中核心系统240可以包括保费试算接口和投保单录入接口。其中所述投保单录入接口包含保费计算逻辑模块。

在示例性实施例中，所述保费试算通用服务230由所述核心系统230提供，且所述保费试算通用服务230能够通过所述保费试算接口的调用，复用所述保费计算逻辑模块作为所述保费试算通用服务230的保费试算逻辑模块。

图3是基于图2所示的系统架构图的另一种数据处理方法的流程图。

如图3所示，在步骤S310中，通过各种投保渠道210接入前端系统220。

例如，保险代理人通过电话、网站、微信、银行等渠道接入前端系统220。

在步骤S320中，前端系统220录入相应保险计划的各种保费试算因子。

其中，该保险计划中可以包括多个保险险种，各个保险险种分别具有其对应的保费试算因子，前端系统录入该保险计划中每个保险险种的保费试算因子，例如投保险种代码、缴费频率、职业等级、保额、年龄、性别、缴费期、保障期等信息。

在步骤S330中，前端系统调用保费试算通用服务。

前端系统220将录入的信息组织报文后，调用保费试算通用服务230。

在步骤S340中，保费试算通用服务230调用核心系统240保费试算接口。

保费试算通用服务230满足各类型险种的保费试算的要求，预先将各类型险种的保费试算因子都提取出来并送入所述保费试算接口，满足保费试算的初始要求。这样的设计，接口格式单一、调用简单。

在步骤S350中，保费试算接口调用核心系统240内部保费计算逻辑模块获得保费试算结果。

所述保费试算结果可以包括该保险计划的各个保险险种的保费试算明细结果和该保险计划的保费合计结果。

在步骤S360中，保费试算接口将该保费试算结果返回给保费试算通用服务230。

在步骤S370中，保费试算通用服务230将该保费试算结果以报文形式发送返回前端系统220。

在步骤S380中，前端系统220对该保费试算结果进行页面展示。

在示例性实施例中，还可以包括：根据来自任意的前端系统220的连接，获取该前端系统220的终端种类信息；根据该终端种类信息，以相应的方式向所述前端系统发送该保费试算结果。这样可以根据前端系统220的终端类型的不同，以便于该前端系统显示的方式向该前端系统发送该保费试算结果。

本实施方式提供的数据处理方法，通过巧妙的复用核心系统既有的保费计算逻辑，实现投保之前的保费试算和投保时的保费计算的统一。此外，通过提取各险种通用的保费试算因子，在通用接口中充分考虑了各险种的特点，实现了调用入口的统一，且核心系统中的保费试算逻辑可根据保险计划的不同而灵活定义、按需配置。

需要注意的是，上述附图仅是根据本发明示例性实施方式的方法所包括的处理的示意性说明，而不是限制目的。易于理解，上述附图所示的处理并不表明或限制这些处理的时间顺序。另外，也易于理解，这些处理可以是例如在多个模块中同步或异步执行的。

下述为本发明装置实施例，可以用于执行本发明方法实施例。对于本发明装置实施例中未披露的细节，请参照本发明方法实施例。

图4是根据一示例性实施方式示出的数据处理装置的框图。

如图4所示，该数据处理装置400包括：接收模块410、调用模块420以及发送模块430。

其中接收模块410用于接收查询请求，其中所述查询请求中包括类型信息和要素信息。

调用模块420用于根据所述类型信息调用相应的查询接口。

发送模块430用于通过所述查询接口调用相应的逻辑模块，所述逻辑模块根据所述要素信息获得相应的查询结果并返回。

在示例性实施例中，所述查询请求中的每一类型包括至少一个种类，每一种类包括多个要素。

在示例性实施例中，数据处理装置400还包括：预置模块，用于将每一种类以及每一种类对应的多个要素预先存储于一数据库中；配置模块，用于从所述数据库中选择相应的种类配置成一类型，并根据所述配置生成所述类型的一配置信息表。

在示例性实施例中，数据处理装置400还包括：第一判断模块，用于判断所述配置信息表是否与一预设规则冲突。

在示例性实施例中，一个查询请求对应于一类型，所述类型中包括一第一种类和一第二种类，所述第一种类包括一第一要素信息，所述第二种类包括一第二要素信息。

在示例性实施例中，所述发送模块440包括：第一结果获取单元，用于所述逻辑模块根据所述第一要素信息获得所述第一种类的一第一查询结果；第二结果获取单元，用于所述逻辑模块根据所述第二要素信息获得所述第二种类的一第二查询结果；综合结果获取单元，用于所述逻辑模块根据所述第一查询结果和所述第二查询结果获得所述类型的综合查询结果；发送单元，用于所述逻辑模块将所述第一查询结果、所述第二查询结果和所述综合查询结果均返回。

需要注意的是，上述附图中所示的框图是功能实体，不一定必须与物理或逻辑上独立的实体相对应。可以采用软件形式来实现这些功能实体，或在一个或多个硬件模块或集成电路中实现这些功能实体，或在不同网络和/或处理器装置和/或微控制器装置中实现这些功能实体。

图5是根据一示例性实施方式示出的投保方法的流程图。

如图5所示，在步骤S510中，发送一查询请求，其中所述查询请求中包括类型信息和要素信息。

在步骤S520中，接收根据所述类型信息和所述要素信息返回的查询结果。

在示例性实施例中，用户通过一终端设备(例如手机、台式机、平板电脑或者笔记本电脑等)登录保险公司的网站，选择一个保险计划，根据该保险计划输入相应的险种的保费试算因子，然后向保险公司的前端系统发送查询请求。前端系统通过调用核心系统中的通用保费试算服务，根据该保险计划及用户输入的各个保费试算因子，返回相应的保费试算结果。具体的可参见上述的数据处理方法及数据处理装置。

在步骤S530中，根据所述查询结果发送一投保请求。

在示例性实施例中，当所述终端设备接收到该核心系统返回的所述查询结果时，可在所述终端设备的显示屏幕上的适当位置显示一个虚拟按键(当然，也可以预先设置一个实体按键替代该虚拟按键等同的功能)，该虚拟按键显示“一键投保”。用户可以选择点击该一键投保按键向前端系统发出所述投保请求。如果前端系统审核该投保请求符合投保要求，则可以将该投保请求发送至该核心系统，使该投保请求在该核心系统中生成保单。

本实施方式提供的投保方法，可具有保费试算后的一键投保功能，直接将试算保费转为投保的保费金额，而无需在投保时再次计算。

本发明实施例中的其他内容参考上述实施例，在此不再赘述。

图6是根据一示例性实施方式示出的投保系统的框图。

如图6所示，该投保系统600包括：查询接口610，用于响应于接收到的查询请求调用相应的逻辑模块，其中所述查询请求中包括类型信息和要素信息；逻辑模块620，用于根据所述查询请求中的所述要素信息获得相应的查询结果；通信模块630，用于返回所述查询结果并接收投保请求，其中所述投保请求基于所述查询结果发出。

在示例性实施例中，还包括：存储模块640，用于存储所述查询结果。

本发明实施方式提供的投保系统，直接将投保之前的试算保费转为投保的保费金额，而无需再次计算。在一些实施例中，当接收到投保请求时，可先判断该投保请求是否在近期通过调用通用保费试算服务估算过保费，如果之前估算过便可直接将估算的保费直接带入核心系统中，同时关闭核心系统中的投保保费计算功能，不再重复计算。

通过以上的实施方式的描述，本领域的技术人员易于理解，这里描述的示例实施方式可以通过软件实现，也可以通过软件结合必要的硬件的方式来实现。因此，根据本发明实施方式的技术方案可以以软件产品的形式体现出来，该软件产品可以存储在一个非易失性存储介质(可以是CD-ROM，U盘，移动硬盘等)中或网络上，包括若干指令以使得一台计算设备(可以是个人计算机、服务器、移动终端、或者网络设备等)执行根据本发明实施方式的方法。

以上具体地示出和描述了本发明的示例性实施方式。应可理解的是，本发明不限于这里描述的详细结构、设置方式或实现方法；相反，本发明意图涵盖包含在所附权利要求的精神和范围内的各种修改和等效设置。

Claims (15)

1.一种数据处理方法，其特征在于，包括：

接收查询请求，其中所述查询请求中包括类型信息和要素信息；

根据所述类型信息调用相应的查询接口；

通过所述查询接口调用相应的逻辑模块，所述逻辑模块根据所述要素信息获得相应的查询结果并返回。

2.根据权利要求1所述的数据处理方法，其特征在于，所述查询请求中的每一类型包括至少一个种类，每一种类包括多个要素。

3.根据权利要求2所述的数据处理方法，其特征在于，还包括：

将每一种类以及每一种类对应的多个要素预先存储于一数据库中；

从所述数据库中选择相应的种类配置成一类型，并根据所述配置生成所述类型的一配置信息表。

4.根据权利要求3所述的数据处理方法，其特征在于，还包括：

判断所述配置信息表是否与一预设规则冲突。

5.根据权利要求2所述的数据处理方法，其特征在于，一个查询请求对应于一类型，所述类型中包括一第一种类和一第二种类，所述第一种类包括一第一要素信息，所述第二种类包括一第二要素信息。

6.根据权利要求5所述的数据处理方法，其特征在于，所述逻辑模块根据所述要素信息获得相应的查询结果并返回，包括：

所述逻辑模块根据所述第一要素信息获得所述第一种类的一第一查询结果；

所述逻辑模块根据所述第二要素信息获得所述第二种类的一第二查询结果；

所述逻辑模块根据所述第一查询结果和所述第二查询结果获得所述类型的综合查询结果；

所述逻辑模块将所述第一查询结果、所述第二查询结果和所述综合查询结果均返回。

7.一种数据处理装置，其特征在于，包括：

接收模块，用于接收查询请求，其中所述查询请求中包括类型信息和要素信息；

调用模块，用于根据所述类型信息调用相应的查询接口；以及

发送模块，用于通过所述查询接口调用相应的逻辑模块，所述逻辑模块根据所述要素信息获得相应的查询结果并返回。

8.根据权利要求7所述的数据处理装置，其特征在于，所述查询请求中的每一类型包括至少一个种类，每一种类包括多个要素。

9.根据权利要求8所述的数据处理装置，其特征在于，还包括：

预置模块，用于将每一种类以及每一种类对应的多个要素预先存储于一数据库中；

配置模块，用于从所述数据库中选择相应的种类配置成一类型，并根据所述配置生成所述类型的一配置信息表。

10.根据权利要求9所述的数据处理装置，其特征在于，还包括：

第一判断模块，用于判断所述配置信息表是否与一预设规则冲突。

11.根据权利要求8所述的数据处理装置，其特征在于，一个查询请求对应于一类型，所述类型中包括一第一种类和一第二种类，所述第一种类包括一第一要素信息，所述第二种类包括一第二要素信息。

12.根据权利要求11所述的数据处理装置，其特征在于，所述发送模块包括：

第一结果获取单元，用于所述逻辑模块根据所述第一要素信息获得所述第一种类的一第一查询结果；

第二结果获取单元，用于所述逻辑模块根据所述第二要素信息获得所述第二种类的一第二查询结果；

综合结果获取单元，用于所述逻辑模块根据所述第一查询结果和所述第二查询结果获得所述类型的综合查询结果；

发送单元，用于所述逻辑模块将所述第一查询结果、所述第二查询结果和所述综合查询结果均返回。

13.一种投保方法，其特征在于，包括：

发送一查询请求，其中所述查询请求中包括类型信息和要素信息；

接收根据所述类型信息和所述要素信息返回的查询结果；

根据所述查询结果发送一投保请求。

14.一种投保系统，其特征在于，包括：

查询接口，用于响应于接收到的查询请求调用相应的逻辑模块，其中所述查询请求中包括类型信息和要素信息；

逻辑模块，用于根据所述查询请求中的所述要素信息获得相应的查询结果；

通信模块，用于返回所述查询结果并接收投保请求，其中所述投保请求基于所述查询结果发出。

15.根据权利要求14所述的投保系统，其特征在于，还包括：

存储模块，用于存储所述查询结果。