CN108629696A - 一种基于用户的保险保障评估方法和系统 - Google Patents

Abstract

本发明涉及一种计算机实施的评估保险保障的方法，包括：使用一个或多个处理器根据经过更新的需求确定保障类型；使用一个或多个处理器根据更新需求的实际风险点确定所述保障类型的保额；以及使用一个或多个通信接口通过通信网络发送展示所述保障类型及其保额的指示。

Description

一种基于用户的保险保障评估方法和系统

技术领域

本发明涉及一种金融技术领域，特别地涉及一种基于用户的保险保障评估方法和系统。

背景技术

随着互联网技术的成熟，互联网保险得到了迅速的发展。对于互联网保险系统，去中介化使得其保险产品能够用较低的价格去拓展市场。因此，现有的互联网保险系统都是以产品为核心而设计的。但是，这样的互联网保险系统却没有得到用户的认可。2017年，针对互联网保险的投诉就上升了大约63％。传统的互联网保险系统已经没有发展空间。因此，本领域迫切需要一种从客户出发的互联网保险系统，从根本上解决存在的诸多问题。

发明内容

针对现有技术中存在的技术问题，本发明提出了一种计算机实施的评估保险保障的方法，包括：使用一个或多个处理器根据经过更新的需求确定保障类型；使用一个或多个处理器根据更新需求的实际风险点确定所述保障类型的保额；以及使用一个或多个通信接口通过通信网络发送展示所述保障类型及其保额的指示。

如上所述的方法，其中更新的需求为经过增加或移除一个或多个保险需求或者将保险需求转换成更低级别保险需求得到的需求。

如上所述的方法，其中更新需求的实际风险点为更新的需求对应的潜在风险点经过变量赋值后转换得到的风险点。

如上所述的方法，进一步包括使用一个或多个处理器调整所述保障类型的保额。

如上所述的方法，其中基于以下因素中的一者或多者调整保额：已经购买的保险保额、公司年金、公司或政府福利等中的一者或多者。

根据本发明的另一个方面，提出一种保险保障评估系统，包括：一个或多个通信接口；一个或多个存储器单元；一个或多个处理器，其执行存储在所述一个或多个存储器单元中的计算机可读指令，用以：根据经过更新的需求确定保障类型；根据更新需求的实际风险点确定所述保障类型的保额；以及使用一个或多个通信接口通过通信网络发送展示所述保障类型及其保额的指示。

如上所述的系统，其中更新的需求为经过增加或移除一个或多个保险需求或者将保险需求转换成更低级别保险需求得到的需求。

如上所述的系统，其中更新需求的实际风险点为更新的需求对应的潜在风险点经过变量赋值后转换得到的风险点。

如上所述的系统，进一步包括使用一个或多个处理器调整所述保障类型的保额。

如上所述的系统，其中基于以下因素中的一者或多者调整保额：已经购买的保险保额、公司年金、公司或政府福利等中的一者或多者。

附图说明

下面，将结合附图对本发明的优选实施方式进行进一步详细的说明，其中：

图1是现有的互联网保险系统的架构示意图；

图2是现有的互联网保险系统的用户产品关系图；

图3是根据本发明的一个实施例互联网保险系统结构的示意图；

图4是根据本发明的一个实施例互联网保险系统服务器的示意图；

图5是根据本发明的一个实施例互联网保险系统客户端设备的示意图；

图6是根据本发明一个实施例的互联网保险系统的示意图；

图7是根据本发明一个实施例的基于用户的保险模型的结构示意图；

图8是根据本发明一个实施例的基于用户的保险模型架构示意图；

图9是根据本发明一个实施例的用户界面系统的示意图；

图10是根据本发明一个实施例的用户交互方法的示意图；

图11A-11G是根据本发明一个实施例的用户使用实例的界面示意图；

图12是根据本发明一个实施例的保险需求评估方法的示意图；

图13是根据本发明一个实施例的保险风险评估方法的示意图；

图14是根据本发明一个实施例的保险保障评估方法的示意图；

图15是根据本发明一个实施例的保险产品推荐方法的示意图；

图16是根据本发明一个实施例的变量示意图。

具体实施方式

为使本发明实施例的目的、技术方案和优点更加清楚，下面将结合本发明实施例中的附图，对本发明实施例中的技术方案进行清楚、完整地描述，显然，所描述的实施例是本发明一部分实施例，而不是全部的实施例。基于本发明中的实施例，本领域普通技术人员在没有做出创造性劳动前提下所获得的所有其他实施例，都属于本发明保护的范围。

在以下的详细描述中，可以参看作为本申请一部分用来说明本申请的特定实施例的各个说明书附图。在附图中，相似的附图标记在不同图式中描述大体上类似的组件。本申请的各个特定实施例在以下进行了足够详细的描述，使得具备本领域相关知识和技术的普通技术人员能够实施本申请的技术方案。应当理解，还可以利用其它实施例或者对本申请的实施例进行结构、逻辑或者电性的改变。

图1是现有的互联网保险系统的架构示意图。如图所示，现有的互联网保险系统100从保险产品出发，针对于已有的保险产品1-保险产品4，根据产品的特点确定各个产品对应的适应人群。如下表1所示：

表1

保险产品	对应的适应人群
		产品1	适应人群1
产品2	适应人群2
		产品3	适应人群3
产品4	适应人群4

进一步地，根据适应人群的特点，确定归属与各个适应人群的需要满足的条件。如图所示，适应人群与各个条件之间的对应关系可以是一对多、多对一或者多对多。举例而言，如下表2所示

表2

保险产品	对应的适应人群	对应条件
			产品1	适应人群1	条件1、2、3
产品2	适应人群2	条件2、4、5
			产品3	适应人群3	条件1、3、6
产品4	适应人群4	条件4、5、6

图2是现有的互联网保险系统的用户产品关系图。对比图1不难发现图2的用户产品关系基本是图1系统构架的反向过程。如图所示，用户使用现有的互联网保险系统时，系统会请用户选择在保险类别中选择希望购买的保险产品的类别。这些类别包括但不限于：重疾保险、养老保险、子女教育金保险等。在图2的例子中，用户对分类2的保险类别感兴趣。用户选择了特定的类别后，现有的互联网保险系统会通过一系列的问答或者选择题，获取用户的信息，判断用户情况满足哪些条件后，根据这些条件判断用户的归属人群，并向用户推荐相应的保险产品。在图2的例子中，用户的情况满足条件1、2、4、5和6，归属人群为人群1和3。那么，现有的互联网保险系统将向用户推荐保险产品1和3。

用户使用现有的互联网保险系统容易出现“得非所愿、愿非所得”的情况。这是现有的互联网保险系统投诉率居高不下的重要原因。以产品为核心的架构决定了所有的筛选条件都是围绕着产品进行的。例如，某个用户的家庭年收入>100万，根据筛选条件，现有的互联网保险系统会向用户推荐最高保额的重疾保险。但是，这个客户有计划移民海外，而在海外当地已有的社会保障已经能够涵盖出现重疾的大部分费用。这个用户的真正需求是补充重疾保险，而不必购买最高保额的保险产品。但是以产品为核心的系统并不会反映出这样的需求，出现“愿非所得”的情况就在所难免。再比如，某个用户希望投保子女教育金保险。如果按照现有的互联网保险系统，用户会被推荐购买一款子女教育金保险产品。但是，作为家庭支柱的用户本身却尚未购买任何保险。一旦用户自身的健康出现问题，那么子女的教育金仍然无法得到保障。在这种情况下，出于保障子女教育的考虑，用户的最大风险在于自身的风险而非子女教育金本身。如果用户仅购买了子女教育金保险产品而未购买自身的重疾保险产品，那么用户的风险并未真正得到解决。因此，出现“愿非所得”的情况可能性就很高了。现有的互联网保险系统虽然实现了去中介化，却失去了以用户为核心的保险理念，被投诉也就是理所当然的情况了。

针对现有互联网保险系统的问题，本发明提出了一种以基于客户的互联网保险系统，其与传统的以产品为核心的互联网保险系统有着本质的区别。以下详细介绍本发明的互联网保险系统。

图3图示说明了互联网系统300，其包括一个或多个在通信网络上的客户端设备302、应用服务器304、网页服务器306、服务器负载平衡器308、云负载平衡器310。应用服务器304、网页服务器306、服务器负载平衡器308、云负载平衡器310通信地耦合到一个或多个数据库312。

通信网络能够是覆盖行政区、国家、大陆或其组合的任意多级网络。通信网络的示例能够包括：蜂窝网络，诸如3G网络、4G网络、长期演进(LTE)网络；声波通信网络；卫星网络；广域网，诸如因特网；或它们的组合。应用服务器304、网页服务器306、服务器负载平衡器308、云负载平衡器310能够通过连接314被通信地耦合到通信网络。连接314能够是有线连接、无线连接或它们的组合。

互联网保险系统或其中的一部分能够包括由计算云(诸如，阿里云、腾讯云、百度云、Windows Azure云、亚马逊弹性计算云(Amazon EC2)、Google App Engine或它们的组合)作为主机管理(host)的网页和/或移动应用。例如，停车管理系统300能够包括在一个或多个应用服务器304、网页服务器306或它们的组合作为主机管理的虚拟机器上运行的网页和/或移动应用。在一种变型中，计算云能够包括一个或多个应用服务器304、网页服务器306、数据库312、服务器负载平衡器308、云负载平衡器310、其中的部分或它们的组合。

云负载平衡器310能够在多个网页服务器306之间提供流量负载平衡和分配客户请求。网页服务器306能够包括HTTP服务器或者依赖计算云来处理HTTP请求。网页服务器306还能够由计算云实例化和管理。

服务器负载平衡器308能够平衡网页服务器306和一个或多个应用服务器304之间的互动。应用服务器304能够处理应用逻辑并且与数据库312互动以存储数据和应用状态。网页服务器306、应用服务器304或它们的组合能够包括机架式服务器、集群服务器、刀片服务器、主机、专用台式电脑或笔记本电脑，或它们的组合。

数据库312能够是一个或多个SQL数据库。应用服务器304能够与管理SQL数据库的一个或多个SQL服务器交互。应用数据和应用状态能够被存储在云管理的SQL数据库中。在另一些变型中，数据库312能够是面向文档型数据库，包括诸如数据库的NoSQL数据库。

客户端设备302能够包括便携式计算设备，诸如智能手机、平板电脑、笔记本电脑、智能手表、个人娱乐设备或它们的组合。在另一些变型中，客户端设备302还能够包括台式计算机。

图4图示说明互联网保险系统300的服务器400能够具有一个或多个处理器402、存储器404和通信接口406。处理器402能够通过高速总线408被耦合到存储器404和通信接口406。服务器400能够表示图3中的网页服务器112、应用服务器110或它们的组合中的任意一种。

处理器402能够包括一个或多个中央处理单元(CPU)、图形处理单元(GPU)、专用集成电路(ASIC)、现场可编程门阵列(FPGA)或它们的组合。处理器402能够执行存储在存储器404中的软件或计算机可读指令以执行本文描述的方法或操作。处理器402能够以若干不同的方式来实施。例如，处理器402能够包括一个或多个嵌入式处理器、处理器核心、微型处理器、逻辑电路、硬件有限状态机(FSM)、数字信号处理器(DSP)或它们的组合。例如，处理器402能够是64位处理器。

存储器404能够存储软件、数据、日志或它们的组合。存储器204能够是内部存储器。替代地，存储器404能够是外部存储器，诸如驻留在存储节点、云服务器或存储服务器上的存储器。存储器404能够是易失性存储器或非易失性存储器。例如，存储器404能够是诸如非易失性随机存取存储器(NVRAM)、闪存、磁盘存储器的非易失性存储器，或者是诸如静态随机存取存储器(SRAM)的易失性存储器。存储器404能够是用于服务器400的主存储单元。

通信接口406能够包括一个或多个有线或无线通信接口。例如，通信接口406能够是服务器400的网络接口卡。通信接口406能够是无线调制解调器或有线调制解调器。在一种变型中，通信接口406能够是WiFi调制解调器。在另一些变型中，通信接口406能够是3G调制解调器、4G调制解调器、LTE调制解调器、蓝牙组件、射频接收器、天线或它们的组合。服务器400能够使用通信接口406连接到通信网络或者与通信网络通信地耦合。服务器400能够使用通信接口406传输或者接收包或消息。

图5图示说明互联网保险系统300的客户端设备500能够具有客户端处理器512、客户端存储器514、客户端通信单元516、以及显示器518。客户端处理器512能够通过高速总线520被耦合到客户端存储器514、和客户端通信单元216。

客户端处理器512能够包括一个或多个CPU、GPU、ASIC、FPGA或它们的组合。客户端处理器512能够执行存储在客户端存储器514中的软件以执行本文描述的方法。客户端处理器512能够以若干不同的方式来实施。例如，客户端处理器512能够是嵌入式处理器、处理器核心、微型处理器、逻辑电路、硬件FSM、DSP或它们的组合。作为一个具体的示例，客户端处理器512能够是32位处理器，诸如处理器。

客户端存储器514能够存储软件、数据、日志或它们的组合。在一种变型中，客户端存储器514能够是内部存储器。在另一种变型中，客户端存储器514能够是外部存储单元。客户端存储器514能够是易失性存储器或非易失性存储器。例如，客户端存储器514能够是诸如NVRAM、闪存、磁盘存储器的非易失性存储器，或者是诸如SRAM的易失性存储器。客户端存储器514能够是用于客户端设备500的主存储单元。

客户端通信单元516能够是有线或无线通信接口。例如，客户端通信单元516能够是客户端设备的网络接口卡。客户端通信单元516能够是无线调制解调器或有线调制解调器。在一种变型中，客户端通信单元516能够是WiFi调制解调器。在另一些变型中，客户端通信单元516能够是3G调制解调器、4G调制解调器、LTE调制解调器、蓝牙组件、射频接收器、天线或它们的组合。客户端设备能够使用客户端通信单元516连接到通信网络或者与通信网络通信地耦合。客户端设备500能够使用客户端通信单元516传输或者接收包或消息。

显示器518能够是诸如液晶显示器(LCD)的触摸屏显示器、薄膜晶体管(TFT)显示器、有机发光二极管(OLED)显示器或者有源矩阵有机发光二极管(AMOLED)显示器。在某些变型中，显示器518能够是视网膜显示器、触觉触摸屏或它们的组合。例如，当客户端设备500是智能手机时，显示器518能够是智能手机的触摸屏显示器。

客户端设备500通过显示器518展示的图形用户界面(GUI)与用户交互。GUI能够向用户展示内容，用户能够根据展示的内容将用户输入应用到GUI上的按钮、文本框、或链接。响应于将用户输入应用到按钮、文本框、或链接，客户端设备500根据处理器执行的软件或者经过与服务器400通信后向用户展示新的内容。

客户端设备500还可以包括输入装置，例如键盘、触摸屏等。如本领域技术人员所了解的，客户端设备500还可以包括其他功能的装置，以满足客户的需要。

图6是根据本发明一个实施例的互联网保险系统的示意图。如图所示，互联网保险系统600包括客户端601和服务器端602。在一些实施例中，客户端601可以运行在客户端设备500上；服务器端602可以运行在服务器400上。

在一些实施例中，客户端601包括但不限于运行于IOS系统、Android系统、Window系统或者其他系统的APP、网页(Web)端、微信客户端或微信小程序、嵌入其他第三方应用程序的独立或非独立的程序等。客户端601向用户提供图形交互界面(GUI)，从用户获得信息，并向用户展示内容和结果。

在一些实施例中，如图所示，服务器端602包括应用接口604、计算核心606、用户库608和产品库610。应用接口604用于与客户端601通信。例如，应用接口604从客户端601获得用户信息。用户信息被转发到用户库608。用户库608针对每一个用户都建立相应的文档，以存储用户信息并提供用户信息到计算核心606。

在一些实施例中，用户库608包括多个子库。这些子库的例子包括用户资料库612，其用来保存用户的基本资料，例如用户的性别、年龄、家庭结构、收入等确定信息中的一者或多者。另一个子库的实例是用户偏好库614，其用来保存用户的偏好，例如用户的风险便好：激进型还是保守型、用户的产品偏好：重疾险还是意外险、用户的公司偏好：新华保险还是太平洋保险、等等中的一者或多者。基于用户的偏好有利于了解用户的性格、金融知识、风险意识等模糊信息。这些子库还可以包括用户需求库616，其用来存储用户的需求。用户的需求包括用户自己表达的需求以及在此之前经评估的用户用户需求。由于用户的需求是最为重要的因素之一，因此用户需求库616对于本发明的系统而言一定程度上成为了历史数据库。还有一个子库的实例是用户保单库618，其存储与有关的用户保单。这些保单既包括用户购买的保单，也包括以用户或其家庭成员为受益人的保单。用户的已有保单有利于评估用户尚欠缺的保险保障。本领域技术人员应当理解，用户资料库612以外的其他子库对于本发明的互联网保险系统而言都是可选的。用户库608可以包括一个或多个如上的或其他的子库，从而有利于计算核心606更为准确地了解用户需求、评估用户风险、确定用户的保障以及推荐适合用户的产品。

在一些实施例中，用户库608还通过其他信息获取渠道607获得用户信息。这些渠道可能是互联网保险系统的其他子系统，也可以是合作的第三方公司，例如银行、保险公司、第三方社交平台、第三方企业平台、第三方信用平台等。这些渠道可能获得的用户信息更为多样。仅举例如下：用户订单/保单、用户操作、用户访问记录、用户消费记录、用户投资理财记录等。

在一些实施例中，产品库610包括产品信息库622。产品信息库622包括保险产品的信息以及互联网保险系统为保险产品添加的属性。保险产品信息包括保险产品名称、保险公司名称、保险产品类型、保险产品保额、保险产品缴费、保险产品的拒保、拒赔条件等信息、保险产品的详细保障责任(例如重疾险的保障疾病范围、疾病种类及对应保障额度、以及精算使用的发病率统计数据等)中的一者或多者。互联网保险系统添加的属性可以包括保障属性，例如重疾保障、医疗保障、身故保障等中的一者或多者。添加的属性还可以包括保障产品类型，其为保障属性下的子属性。例如，重疾保障属性下可以包括定期重疾类型和终身重疾类型。添加的属性还可以包括保险产品的优先级。保险产品的优先级可以根据多种因素确定，其包括但不限于，第三方评级机构的评级、保险公司的推荐度、保险产品的销售量、用户的反馈等中的一者或多者。根据本发明的另一个实施例，产品库610可以额外包括产品评分库624，其存储保险产品的优先级信息。

互联网保险系统600可以包括保险产品平台626，其存储一个或多个来自于同一或不同保险公司的保险产品。互联网平台系统600也可以不包括保险产品平台626，而是与其他的保险产品汇聚平台或者一家或多家保险公司合作，获得保险产品。

在一些实施例中，计算核心606与用户库608和产品库610通信，根据预定的或基于人工智能的规则和算法，执行了解用户需求、评估用户风险、确定用户保障、以及推荐保险产品等功能中的一者或多者。计算核心606与应用接口604通信，通过应用接口604指示客户端602从客户获得信息和/或展示计算结果。

在一些实施例中，计算核心606包括人工规则引擎632、数据智能引擎634、以及智能测算服务636。人工规则引擎632存储人工预定的规则，例如需求与潜在风险点之间的对应关系、风险点与变量池中变量的对应关系等中的一者或多者。人工规则引擎632根据存储的人工预定规则，执行相应的功能，例如激活或者关闭相应的风险点或者变量。数据智能引擎634实现数据的检索、存取、添加、删除等功能。数据智能引擎634利用历史数据以及针对历史数据的分析结果，提高数据检索、存取、添加和删除的准确度，加快处理速度。智能测算服务636根据用户库608和/或产品库610的信息，针对用户需求、用户风险、用户保障、以及适合的保险产品执行计算、关联、筛选、推送等功能中的一者或多者。

图7是根据本发明一个实施例的基于用户的保险模型的结构示意图。如本领域技术人员所理解的，基于用户的保险模型可以运行在计算核心606上。保险模型的核心是需求、风险、保障以及产品之间的关联关系。基于用户的保险模型既包括人工规则设定的部分，也包括数据的检索、存取、添加和删除等互动操作，以及关联关系的创设、更新和移除。基于用户的保险模型的相应部分可以运行在计算核心606的人工规则引擎632、数据智能引擎634以及智能测算服务636上。

参考图7，基于用户的保险模型700包括三个基本部分：需求702、风险704、和保障706。需求702代表用户的保险需求。用户的保险需求包括一级需求，其包括但不限于重疾、医疗报销、房贷或生活支出、财富传承、资产保值、养老储备和子女教育费用等。每个一级需求还可以包括一个或多个从属于该一级需求的二级需求，或者更为细致的三级需求，以此类推。

风险704代表用户的保险风险。保险风险与保险需求相对应。一个保险需求对应一个或多个保险风险。不同的保险需求对应的多个保险风险中有重合的可能。例如，养老储备和子女教育费用的需求都可能对应家庭支柱身故的保险风险。在一些实施例中，将不同保险需求的保险风险进行区分。换言之，不同的保险需求将对应不同的保险风险，排除重复的可能。在上面的例子中，将养老储备和子女教育费用的需求对应的家庭支柱身故的保险风险区分为家庭支柱身故无法支付养老费用的保险风险和家庭支柱身故无法支付子女教育费用的保险风险。区分不同的需求对应的风险有利于系统的简化。

在很多现有的保险模型中，需求与风险的区分并不明显。这通常意味着有什么样的需求就等同于有什么样的风险，或者面对什么样的风险就有什么样的需求。这是现有的以产品为核心的保险模型经常犯的错误之一。对于本发明的基于用户的保险模型而言，需求与风险之间的区别是显而易见的。对于用户而言，一项需求对应的风险点可能是跨类型的，甚至角色都可能发生变化。以上面的子女教育费用为例，其对应的风险点包括家庭支柱的重疾和意外的保险风险，而家庭支柱可能并不是用户自己。基于用户的含义就在于以用户及用户家庭出发，充分发挥保险的保障作用。只有这样贴紧用户才可能在去中介化互联网保险的情况下仍能得到用户的认可。

在一些实施例中，保险风险704包括潜在风险和实际风险。实际风险是潜在风险的子集。保险需求与潜在风险的对应关系是经设定后不变的(当然，修改保险模型时也可以人为修改)。然而，保险需求与实际风险的对应关系可能根据用户和/或用户家庭的情况而有所不同。例如，养老储备的需求对应退休后收入锐减的潜在风险。当时，如果用户所在的企业已经购买了相当数量的年金，其数额足以补偿退休后的工资收入，那么收入锐减的潜在风险就不成为实际风险。

保障706是用户所需的保险保障。保险保障即为一定数额的保障额度。保障额度包括一种或多种保障类型的组合。在一些实施例中，保障类型与保险产品的类型相对应，包括例如重疾保障、医疗保障、寿险保障、养老保障、两全保障等。在一些实施例中，保险保障包括个人保障以及家庭保障。个人保障和家庭保障之下再包括如上所述的保障类型。

保障类型与保险产品相对应有利于客户依据保障方案去选择合适的保险产品。然而，本领域技术人员应当理解，这并不是保险保障的唯一表示方式。例如，可以通过针对风险的处理方式更为直观地表示保险保障。例如，重大疾病一次性足额给付金、意外和疾病身故的赔付金、退休或约定可领取的养老金等。

在一些实施例中，各类保险保障具有各自的优先级。在一些实施例中，各类保险保障的优先级是固定的，例如重疾保障的优先级高于养老保障。在另一些实施例中，各类保险保障的优先级根据用户和/或用户家庭情况的不同而有所变化。例如，对于无社保的用户，医疗保障的优先级大于养老保障。在另一些实施例中，用户已经购买的保险保额也是影响各个保险保障优先级的重要因素。当然，在一些实施例中，各类保险保障的优先级综合考虑以上一种或多种因素来确定。

参考图7，基于用户的保险模型700中，根据用户输入的初始条件，可以估计用户的需求702。基于估计的需求702，根据需求702与风险704之间的对应关系，可以得到风险704。接下来，通过以例如问卷的形式与用户互动。响应于用户输入的用户以及用户家庭的信息，根据预定的规则和算法，更新需求702和风险704。在需求702和风险704确定以后，根据需求类型和对应的风险得出建议的用户保障706。与图1相比较，在本发明的基于用户的保险模型中，无论是用户需求、用户风险、还是用户保障都是以用户和用户家庭为核心的，将保险的理念和保障与用户的实际情况相结合而提出适合于用户和用户家庭的保障方案。

根据本发明的一个实施例，基于用户的保险模型700可以包括保险产品708。基于用户保障706，根据保险产品推荐规则，可以向用户推荐保险产品并提供在线或离线的购买服务。应当注意的是，保险产品708对于本发明的保险模型700不是必需的部分。用户完全可以使用本发明的保险模型700来评估需求、风险和保障而不必关注任何保险产品。当然，在了解了用户的保险保障706之后，用户可以选择自行购买相应的保险产品。

参考图7的例子，估计的需求702为需求1和需求2。需求1和需求2对应的风险704分别为(风险1和风险2)以及(风险3和风险4)。与用户进行互动后，发现风险1和风险2并不是实际风险，那么需求1最终被移除了。需求2的风险3和风险4为实际风险，那么需求2得到了保留，并且建议了保障方案，即保障1。在针对风险4进行评估是，风险5是相关风险，也被加入到评估范围之内。同样地，风险5对应需求3(未示出)以及需求3对应的另一风险，即风险6也被加入。需求3的风险5和风险6为实际风险，需求3得到了保留，并且建议了保障方案，即保障2。进一步地，针对保障1和保障2分别推荐了保险产品1和保险产品2。

以上仅仅是通过一个具体实例说明了本发明的基于用户的保险模型，即保险需求发生了增减。也可能出现其他的更新情况，例如保险需求未发生变化，而风险点减少；或者保险需求细化为更为详细的需求，相应地风险点出现变化等。

图8是根据本发明一个实施例的基于用户的保险模型架构示意图。图8代表了一种图7的基于用户的保险模型的实现方式。当然，其他架构实现本发明的基于用户的保险模型也是本领域技术人员根据现有的技术知识能够实现的，其仍在本发明的范围之中。

参考图8，基于用户的保险模型800包括三个层次。最外层是用户界面820，其代表了与用户的交流和互动。用户界面820的设计关注到用户体验，直接影响用户对产品的喜爱度和使用频度。中间层是需求802、风险804和保障806以及保险产品808(可选)，其代表了用户通过用户界面820可见的全部或部分内容。用户通过中间层了解自己和/或家庭的保险需求、保险风险、保险保障和推荐的保险产品中的一者或多者。最内层是变量810。变量810代表了用户输入的关于自身和家庭信息以及其他对于评估用户和/或其家庭的保险需求、保险风险、保险保障和推荐的保险产品有帮助的信息。变量810整体而言对用户是不可见的，但是其能够影响需求802、风险804和保障806中的一者或者多者。

在一些实施例中，变量810中的一些变量与保险风险相对应。换言之，保险风险对应一个或多个变量。例如，罹患终身疾病的风险对应用户的年龄、个人年收入、家庭年收入、有无社保等多个变量。根据这些变量的内容和取值情况，就可以了解罹患终身疾病的风险对于用户是否是实际风险以及风险的严重程度。在一些实施例中，变量810中的一些变量是用户的信息，包括但不限于：性别、年龄、家庭结构、个人年收入、家庭年收入等。在一些实施例中，变量810包括用户的偏好，例如用户是否在意医疗环境和服务、用户是否在意养老的环境和服务等。在一些实施例中，变量810可以是用户的购买意愿或者倾向，比如用户是否关注高端医疗、是否关注养老、是否关注子女教育等。在一些实施例中，变量810可以是用户或家庭的未来变化，例如用户是否有移民的意愿、用户是否有单独生活的意愿等。

在本发明的一些实施例中，变量可以由用户在客户设备的GUI上直接输入；也可以由用户在GUI用户界面系统中的问卷系统中选择或输入。除了在于用户直接的交互中获得变量的内容以外，也可以通过其他渠道或者与第三方公司合作获得关于用户和/或用户家庭的这些信息。

如图8所示，变量810与需求802、风险804和保障806中的一者或多者相关联。举例而言，变量810包括一个或多个初始条件，其包括但不限于：性别、年龄、家庭结构、是否拥有房产等变量中的一个或多个。根据作为初始条件的变量，根据预定的规则或算法，可以估计用户的需求802。当然，也可以不依据作为初始条件的变量而人工规定一些通常的需求作为估计的用户需求。在一些实施例中，结合初始条件的变量和人工规定的需求来估计用户的需求。这样所估计的需求可能更为准确。

进一步地，需求802发生变化时，变量810也可以发生相应的变化。这些变化包括激活一个或多个变量810；关闭一个或多个变量810；或者二者的结合。当一个变量被激活后，确定变量是否已经被赋值。如果变量未被赋值，则将该变量加入到与用户交互的GUI界面中，从用户获得该变量的信息并完成赋值。再或者，当变量810发生变化时，根据预定的规则和算法，需求802发生相应的变化。这些变化包括：增加新的需求；减少已有的需求；将一级需求细化为二级需求；或者以上三者的结合。本领域技术人员应当理解，变量810的变化可能是一个动态的过程，因此需求802的变化也可能是一个相应的动态过程。

在一些实施例中，需求802与变量810的互动是通过风险804实现的。举例而言，需求802对应一个或多个风险点804。当某个需求出现时，与其所对应的一个或多个潜在风险804相关联的一个或多个变量810被激活。当变量810经过赋值后，潜在风险可能并未转换为实际风险。如果某个需求对应的风险点都不成为实际风险，那么这一需求可以删除。如前所介绍的，某个需求对应的风险点可能是跨类别的。因此，当跨类别的风险点在变量赋值后从潜在风险变成实际风险，那么实际风险对应的需求也当然被增加。接下来，更多的变量被激活，从而新的需求及其风险点得到评估。因此，变量与风险之间的互动更为直接。在一些实施例中，变量与风险是相互对应的。在变量赋值后，根据预定的规则和算法，可以评估风险的大小，从而确定某个风险点是否成为实际风险，以及风险的优先级。

在一些实施例中，如前所述，当需求802和风险804确定以后(例如所有相关的变量已经被赋值)，就可以来评估保障806。在确定某一类的保障806时，预定的配置规则和算法以及有关的变量都会被使用。因此，保障806也与变量810相关。考虑到变量810与需求802和风险804之间的互动关系，那么保障806与变量810之间的关联就更为紧密了。

根据本发明的一个实施例，基于用户的保险模型800还可以包括保险产品808。如前所述，推荐保险产品以及提供相应的购买保险产品的通路并不是基于用户的保险模型800的必需部分。与基于产品的保险模型不同，本发明基于用户的模型本质上与保险产品无关。

在一些实施例中，根据保障方案能够确定保险产品类型。在保险产品类型确定后，根据预定的规则和算法，检索保险产品并对保险产品进行排序。根据排序的结果向用户推荐保险产品。在一些实施例中，保险产品的推荐规则和算法仅与保障方案有关。

图9是根据本发明一个实施例的用户界面系统的示意图。用户界面系统900可以包括在服务器端也可以包括在客户端。举例而言，对于APP应用而言，为了增加交互的流畅性，用户界面系统900包括在客户端。根据来自服务端的指令和数据向用户展示相应的界面和内容。对于Web访问方式而言，客户端并不包括任何界面。Web浏览器从服务器端下载相应的界面和内容并向用户展示。用户界面系统是直接与客户交互的部分，很大程度上决定了用户的体验。

参考图9，在一些实施例中，用户界面系统900包括：初始界面902、需求界面904、问卷系统906、风险界面908、保障方案界面910、投保方案界面912、以及投保界面914。

在一些实施例中，初始界面902包括一个或多个界面。在针对用户进行需求分析之前，用户通过初始界面902输入初始条件。初始界面902包括但不限于：性别界面、家庭结构界面、年龄界面或生日界面等中的一者或多者。对于界面系统900，初始界面902是可选的，但也是推荐的。利用初始条件，需求分析可以更为准确，更有针对性。在不包括或展示初始界面902的情况下，也可以考虑已经从之前的交互或者第三方公司已经获得相关的信息。或者，选择所有用户都从相同的需求分析开始。在一些实施例中，初始界面902包括登录界面、注册界面、找回密码界面、用户信息界面等中的一者或多者。

需求界面904包括图形化整合需求分析界面、用户需求分析界面、家庭成员分析界面、家庭整体分析界面、需求调整界面中的一者或多者。需求界面中的各个界面可以是分立的多个界面也可以是连续的分屏或不分屏界面。

图形化整合需求分析界面以图形化的方式将所有家庭成员和/或所有种类的需求呈现给用户。本领域技术人员应当理解，图形化的手段更为直观和清楚，是推荐采用的方式。以非图形化展示也同样在本发明的范围之中。在一些实施例中，整合需求分析界面包括各个保险需求的文字和/或图形化说明。在一些实例中，文字和/或图形化说明以可变的方式展示。例如，当用户输入应用到某个保险需求上时，展示该保险需求的文字和/或图形化说明。

用户需求分析界面、家庭成员分析界面、和家庭整体分析界面类似。以用户需求分析界面为例，在该界面中，列出一个或多个针对该用户的保险需求。进一步地，针对某个保险需求，可以选择列出针对该保险需求的详细说明。再进一步，可以选择列出该保险需求所对应的潜在风险。如果用户认可该保险需求，可以点击用户需求分析界面上针对该保险需求的按钮或链接，从而进入后续问卷系统，针对该保险需求进行更为详细的分析。如果用户认为该保险需求可能需要调整，用户可以点击需求调整的按钮或链接，进入需求调整界面，对需求进行调整。用户本领域技术人员应当理解，这仅仅是用户需求分析界面的一种展示方式。家庭成员分析界面和家庭整体分析界面的形式类似，其展示的内容为各个家庭成员的保险需求分析以及将整个家庭作为整体的保险需求分析。在一些实施例中，家庭成员分析界面和家庭整体分析界面是可选的。

问卷系统906包括一个或多个界面。用户在问卷系统中回答问题，从而输入用户和/或其家庭有关的信息。如前所了解的，使用问卷系统906是针对变量赋值的过程。在问卷系统906中，展示哪些问题以及以什么样的顺序来展示问题再或者如何根据用户之前的回答调整问题和/或顺序是本发明的基于用户的保险模型所决定的。但是，在不考虑内容的情况下，就问卷系统906的实现而言，现有技术中已有的问卷系统都可以应用于本发明的用户界面系统900中而向用户展示基于用户的保险模型的这些问题。

风险界面908包括一个或多个界面。风险界面908向用户展示经过详细分析后的保险风险。在一些实施例中，包括保险风险的经更新的需求界面可以用来向用户同时展示需求以及需求对应的风险。因此，风险界面908是可选的。或者，同时展示需求和风险的界面也可以被认为是风险界面。

以同时展示需求和风险的界面为例，界面908展示一个或多个经过更新后的保险需求。与需求分析界面904相比，界面908可能会包括更多的需求、更少的需求、或者更为细化的需求。例如，对于资产较多的家庭，养老储备需求并不存在；但是之前需求分析界面904可能不存在的资产传承需求可能会增加。进一步地，医疗需求可能会细化为海外高端医疗。

界面908包括针对每个需求的实际保险风险。需求的增加、减少和细化引起对应风险点的变化。如前所述，实际风险是潜在风险的子集。因此，针对各个保险需求而言，向用户显示的风险点可能不变或者减少。在界面908中需求和风险的变化反映出基于本发明的基于用户的保险模型针对用户情况的评估结果。

保障方案界面910用来显示保险保障。具体而言，针对各个保障类型，在保障界面910展示分别建议的保额。在一些实施例中，在保证界面910可以同时向用户展示已经购买的保险产品的保额、和/或，建议的保额与已经购买的保险产品的保额之间的差额。在一些实施例中，在保证界面910展示不同保障类型的优先级。展示优先级的方式包括但不限于：展示的顺序、展示的字体或图形的大小或颜色、额外添加的标签、或者提示框。在一些实施例中，保障界面910可以包括保障建议。例如，建议用户优先考虑哪个或哪些个保障类型或者更为具体的保障配置建议。

在一些实施例中，保障界面910包括针对各个保障类型的保障说明。例如，当用户点击某个保障类型时，展开折叠的页面或者进入新的页面，并且在展开的页面或者新的页面中向用户展示针对该保障类型的保障说明。保障说明可以包括主题词或语句，方便用户更快地了解保障的含义。

在一些实施例中，在保障界面910中，允许用户调整保障额度。用户可以在保障额度调整界面中输入希望的保障额度。针对用户输入的保障额度，保障界面可以提供相应的反馈和建议，供用户参考。

在一些实施例中，在包含了保险产品推荐的情况下，整合了保障方案和推荐产品的投保方案界面912可以作为保障界面910的替换方案。或者，投保界面912即为保障界面的基础上增加了推荐产品的相关内容。例如，在各个保障分类下，包括了一个或多个推荐保险产品以及这些保险产品的详细信息，包括但不限于：保险产品名称、公司、保额、保障年限、缴费年限、投保费用等中的一者或多者。

在用户点击了某个保险产品后，向用户展示投保界面914。投保界面914提示用户输入被投保人、投保人、受益人、生效时间等购买保险的必要信息。在某些实施例中，投保界面914还包括支付界面。用户可以通过支付界面完成支付，购买保险产品。

图10是根据本发明一个实施例的用户交互方法的示意图。图11A-11G是根据本发明一个实施例的用户使用实例的界面示意图。参考图10和图11A-11G，通过用户使用本发明的用户界面系统进行交互的一个实例，进一步说明本发明的技术方案。

在步骤1010，用户使用初始界面，输入初始条件；其中初始见面的实例如图11A所示。用户根据初始界面中包括的选项或问题，输入用户或家庭的信息。

在步骤1020，向用户展示需求分析界面，其中需求分析界面的实例如图11B所示。在图形化整合需求分析界面，用户可以看到家庭的需求图谱。根据需求图谱，用户可以直观地了解到家庭所需的保险的类型以及最迫切的保险需求是哪些。在个人、孩子以及教育费用提前准备项目下，用户可以看到这些保险需求的描述以及这些保险需求对应的一个或多个潜在风险。

在步骤1030，响应于用户认可保险需求，调用问卷系统，向用户展示一个或多个问题。问卷系统的界面的实例如图11C所示。如图所示，如果用户点击为您的某个需求进行详细分析或者点击确定需求，表示用户认可了这一保险需求。在问卷系统中，向用户展示该需求下对应的问题，从用户收集相关的信息。

在步骤1040，响应于问卷系统结束，向用户展示保留更新的需求和风险的界面，如图11D所示。问卷系统结束后，用户认可的需求分析都已经进行了详细的分析。如前所述，需求可能增加、减少或者细化。需求所对应的风险点转化为之前显示的风险点的子集。这些更新是应用本发明的基于用户的保险模型得到的分析结果。如前所述，可以向用户展示经过更新的需求界面，或者包括了更新的需求和风险的风险界面，或者其他包括了相关内容的界面。对比图11B和图11D，图形化的整合需求图谱虽然形状大致相同，但是形状发生了变化。这意味着保险风险发生变化。以显示的本人医疗费用补偿和报销需求为例，对应的风险点减少了。在一些实施例中，这一步骤是可选的，问卷系统结束后可以直接转入保障方案界面。

在步骤1050，响应于用户认可更新的需求和风险，向用户展示保障方案界面。保障方案界面的实例如图11E所示。例如，用户点击确认需求/风险或者下一步的按钮，表示用户认可了更新的需求和风险。接下来，向用户展示保障方案的界面。在保障方案界面，向用户展示一个或多个保障类型以及保障类型下分别建议的保额。

在步骤1060，向用户展示一个或多个推荐的保险产品。推荐的保险产品的实例如图11F所示。在各个保障类型下，可以向用户展示推荐的产品。如前所述，推荐保险产品是可选的步骤。

在步骤1070，响应于用户选择一个保险产品，向用户展示投保界面。投保界面的实例如图11G所示。用户在投保界面输入相关信息，可以购买或预定该保险产品。进一步地，还可以向用户展示支付页面，用户完成支付，可以实现该保险产品的购买。

以上通过了一个具体的实例，说明了在客户端装置的显示器上，与用户交互以及展示相关界面的情况。

以下通过评估保险需求、保险风险、和保险保障以及推荐保险产品的方法进一步说明本发明的基于用户的保险模型。

图12是根据本发明一个实施例的保险需求评估方法的示意图。如图所示，评估方法1200包括如下步骤：

在步骤1210，根据用户输入的初始条件，估计用户和/或用户家庭的保险需求。步骤1210是可选的。即使不考虑用户输入的初始条件，也可以根据用户或者家庭最可能的保险需求作为估计的保险需求。当然，基于用户输入的初始条件对最可能的保险需求进行调整后得出的估计的保险需求更符合用户的希望。如前所述，保险需求可以分为多级。在一些实施例中，估计的保险需求是第一级保险需求。或者，在一些实施例中，估计的保险需求包括第一级和第二级保险需求。

在步骤1220，根据用户输入，修改估计的用户和/或用户家庭的保险需求。步骤1220是可选的。如果用户对于估计的保险需求认可，则可以确认估计的保险需求。如果用户认为估计的保险需求需要修改，则应用用户输入以修改估计的保险需求。

在步骤1230，响应于用户确认估计的用户和/或用户家庭的保险需求，调用问卷系统，根据用户对一个或多个问卷系统中问题的回答，为相应的一个或多个变量赋值。用户确认了估计的保险需求后，通过问卷系统向用户展示一个或多个保险问题。在一些实施例中，如前所述，保险问题与风险相对应。当保险需求确定后，保险需求对应的风险相关的一个或多个保险问题将被加入问卷系统中，并且通过客户端向用户展示。进一步地，用户回答这些保险问题的用户输入可以用来向这些保险问题对应的变量赋值。

在一些实施例中，响应于一个或多个变量的赋值，问卷系统增加或减少一个或多个保险问题或者调整一个或多个问题的顺序。问卷系统中各个保险问题是相互关联的。用户对于一个保险问题的不同回答代表不同的保险问题路径。随着用户路径的确定，其他的用户路径中的问题将被移除，问卷系统中的保险问题将会减少。或者，不同路径中同一保险问题的顺序可能不同，问卷系统中的保险问题的顺序将会调整。进一步地，保险需求或风险的增加会导致新的保险问题被加入到问卷系统中，问卷系统中的保险问题将会增加。

在步骤1240，响应于一个或多个变量的赋值，更新用户和/或用户家庭的保险需求。具体而言，响应于变量赋值，第一级别的需求可以被细化为一个或多个第二级别需求；其中第二级别需求的级别小于第一级别需求。或者，响应于一个保险需求对应的所有风险经变量赋值均未成为实际风险，可以移除该保险需求。

在一些实施例中，一个风险可能对应两个保险需求。如果该风险经过变量赋值成为实际风险，那么该风险对应的另一保险需求也将被认为用户确认的需求。换言之，该另一需求应当加入到用户的保险需求中。相应地，在问卷系统中，加入该另一需求对应的保险问题。

在一些实施例中，响应于用户回答了问卷系统中所有的问题，将最终经过更新的用户需求作为用户保险需求评估的结果。如果用户未能回答完问卷系统中所有问题而中途停止，则将当前的经更新的用户需求作为保险需求评估的结果。因此，无论用户是否回答了所有的保险问题，本实施例的方法都能够提供考虑了已有用户输入的经评估的用户保险需求。

图13是根据本发明一个实施例的保险风险评估方法的示意图。如图所示，评估方法1300包括如下步骤：

在步骤1310，根据估计的需求激活需求对应的一个或多个潜在风险点。在一些实施例中，可以向用户展示一个或多个潜在风险点作为估计的需求对应的风险。

在步骤1320，调用问卷系统，根据用户对问卷系统中问题的回答为一个或多个变量赋值。其中，问卷系统中的问题与一个或多个潜在风险点相对应。

在步骤1330，响应于一个或多个变量的赋值，将潜在风险点转换为实际风险点或者将潜在风险点移除。根据预定的规则和算法，根据一个或多个变量的赋值评估潜在风险点的风险是否符合特定的条件。如果符合特定的条件则将潜在风险点转换为实际风险点；如果不符合特定条件则将潜在风险点移除。

在步骤1340，响应于一个或多个变量的赋值，增加或移除问卷系统中的一个或多个问题或者调整一个或多个问题的顺序。如前所述，问卷系统中各个问题可以是相互关联的。根据一个或多个变量的赋值，可以改变问卷系统中的一个或多个问题。

在步骤1350，响应于一个风险点从潜在风险点转换为实际风险点，将该风险点归属的需求的其他风险点对应的问题加入到问卷系统。如前所述，在一些实施例中，一个风险可能对应两个保险需求。如果该风险经过变量赋值成为实际风险，那么该风险对应的另一保险需求也将被认为用户确认的需求。换言之，该另一需求应当加入到用户的保险需求中；该另一需求对应的风险点也被激活。相应地，在问卷系统中，加入该另一需求对应的风险点相关的保险问题。

在步骤1360，响应于用户回答了问卷系统中所有的问题，展示实际风险点。或者在步骤1370，如果用户未能回答完问卷系统中所有问题而中途停止，则展示当前的实际风险点。

图14是根据本发明一个实施例的保险保障评估方法的示意图。如图所示，评估方法1400包括如下步骤：

在步骤1410，根据经过更新的需求确定保障类型。

在步骤1420，根据更新需求的实际风险点确定保障类型的保额。

在步骤1430，对保额进行调整。根据以下因素对保额进行调整，包括但不限于：已经购买的保险保额、公司年金、国家福利、(请补充)等中的一者或多者。

图15是根据本发明一个实施例的保险产品推荐方法的示意图。如图所示，评估方法1500包括如下步骤：

在步骤1510，根据保障类型，检索保险产品。在一些实施例中，保险产品包括保障类型的标签。这样可以方便保险产品的检索。

在步骤1520，根据过滤算法，过滤检索的保险产品。在一些实施例中，推荐算法包括将评分低于阈值的保险产品移除；或者将用户评价中差评比例高于阈值的保险产品移除。本领域技术人员应当理解，以上仅仅是过滤算法的实例。其他的检索过滤算法也可以应用于本发明而实现检索结果的过滤。在一些实施例中，经过推荐算法过滤后保留的保险产品数量低于10个、5个、4个、3个或2个。

在步骤1530，根据保额保费匹配算法，对经过滤的保险产品排序。保额匹配算法为选择保额最接近的方案并以此对经过滤的保险产品进行排序。在一些实施例中，各个保险产品包括优先推荐顺序的排序，其中保额匹配算法为根据排序选择保额最接近的方案作为推荐的保险产品。

例如：当某一用户需求配置定期重疾时，首先去定期重疾的标签下的所有产品，然后根据排序去选择产品。例如排序1的产品最高保额只有50万(10,20,30,50)，排序2的产品最高保额80万(有20,50,80万三个档位)。针对不同的保额，可以按照如下规则排序：

A：当需要配置30万的方案时，出现的产品为；推荐排序1的产品即可

B：当需要配置80万的方案时，出现的产品为：排序1的产品50万，排序2的产品10万。

C：当需要配置60万的方案时，出现的产品为：排序1的产品50万，排序2的产品20万。即，选择保额最接近的方案。

在步骤1540，向用户展示推荐结果。

图16是根据本发明一个实施例的变量属性的示意图。本发明的基于用户的保险模型中包括了多个变量。这些变量可以分为三种变量：第一变量，个人信息变量，例如性别、年龄、年收入等；第二变量，家庭信息变量，例如家庭年收入、家庭费用支出、子女教育支出等；以及第三变量，即衍生变量，其是基于第一变量和/或第二变量按照预定的规则或算法得出的变量，例如保障完成度，其计算公式为：保额/保费。

如图所示，变量可以包括一个或多个不同的属性。在一些实施例中，变量根据其赋值属性可以包括数值变量、布尔变量、文本变量、时间变量等等。

在一些实施例中，一些变量包括风险属性，其为变量对应的风险点。进一步地，变量还可以包括需求属性，其为风险点归属的需求。如前所述，一些需求可以包括跨类别的风险点。跨类别的风险点可能同时归属与两个或两个以上的需求。相应地，跨类别的风险点对应变量的需求属性可以包括两个需求。如前所述，需求可以分为多级。也就是说，一个需求还可以包括下级的子需求。同样地，需求属性也包括多级。

在一些实施例中，一些变量包括问题属性，其为对应问卷系统中的问题。例如，变量“房产状态”，赋值为“是”或“否”，其对应的问题为问卷系统中的8号问题，即“家庭是否购买了房产？”，答案为选项“是”或“否”。

进一步地，问题属性还包括优先级。优先级决定了其对应的问题在问卷系统中的顺序。换言之，问卷系统根据问题属性中的优先级决定在问卷系统中该问题展示给客户的顺序。由于某些问题是关联的，优先级也决定了这些问题的关联关系。这些问题按照先后顺序而具有顺次排列的优先级。举例而言，问题6、7、8是关联问题，顺序是问题6、7、8。问题6、7、8对应的优先级是连续正整数51、52和53。当优先级调整时，问题6、7、8对应的优先级同时加减，从而保证这些问题之间的顺序是不变的。在另外一些实施例中，变量的问题属性并不包括优先级，而问卷系统中的各个问题包括优先级。通过对问卷系统中各个问题的优先级进行调整能够达到相同的效果。

在一些实施例中，一些变量包括状态属性，其为“激活”或者“非激活”状态。当变量的状态属性为“激活”状态，则其问题属性中对应的问题将被加入到问卷系统中。当变量的状态属性为“非激活”状态，则其问题属性中对应的问题将被从问卷系统中移除。本发明的基于用户的保险模型可以响应于一个或多个变量的赋值而更改另外一个或多个变量的状态属性，从而将另外一个或多个变量对应的问题加入问卷系统或者从问卷系统中移除。或者，响应于一个或多个变量的赋值而改变另外一个或多个变量的问题属性的优先级，从而改变另外一个或多个变量对应的问题的展示顺序。

在一些实施例中，变量池中的变量根据需求属性被分为多个组。响应于一个需求被用户确认，变量池中该需求对应的组中的变量都被调入问卷系统中。需求被用户确认包括用户通过输入确认一个或多个需求。或者，一个需求属性包括多个需求的变量经赋值后，本发明的基于用户的保险模型根据预定的规则和算法，确定该变量所对应的风险超过了预定值，那么该变量所对应的风险将成为实际风险。相应地，该变量的需求属性中其他需求被认为也被用户确认。其他需求对应的变量将被激活并加入到问卷系统之中。

本领域技术人员应当理解，以上的描述中详细地介绍了本发明的基于用户的保险模型的架构、方法、交互、以及实现。根据上述描述，具有相关的保险知识和保险销售经验的本领域相关人员完全可以想出各种各样的保险需求、保险风险、保险保障、以及与其相关的保险变量，并能够根据这些保险变量设计出相应的问卷问题，从而在本发明的基于用户的保险模型基础上开发出各自的互联网保险系统。这些保险系统及其相关架构、方法、交互、以及实现都在本发明的范围之中。

上述实施例仅供说明本发明之用，而并非是对本发明的限制，有关技术领域的普通技术人员，在不脱离本发明范围的情况下，还可以做出各种变化和变型，因此，所有等同的技术方案也应属于本发明公开的范畴。

Claims (10)

1.一种计算机实施的评估保险保障的方法，包括：

使用一个或多个处理器根据经过更新的需求确定保障类型；

使用一个或多个处理器根据更新需求的实际风险点确定所述保障类型的保额；以及

使用一个或多个通信接口通过通信网络发送展示所述保障类型及其保额的指示。

2.根据权利要求1所述的方法，其中更新的需求为经过增加或移除一个或多个保险需求或者将保险需求转换成更低级别保险需求得到的需求。

3.根据权利要求1所述的方法，其中更新需求的实际风险点为更新的需求对应的潜在风险点经过变量赋值后转换得到的风险点。

4.根据权利要求1所述的方法，进一步包括使用一个或多个处理器调整所述保障类型的保额。

5.根据权利要求4所述的方法，其中基于以下因素中的一者或多者调整保额：已经购买的保险保额、公司年金、公司或政府福利等中的一者或多者。

6.一种互联网保险系统，包括：

一个或多个通信接口；

一个或多个存储器单元；

一个或多个处理器，其执行存储在所述一个或多个存储器单元中的计算机可读指令，用以：

根据经过更新的需求确定保障类型；

根据更新需求的实际风险点确定所述保障类型的保额；以及

使用一个或多个通信接口通过通信网络发送展示所述保障类型及其保额的指示。

7.根据权利要求6所述的系统，其中更新的需求为经过增加或移除一个或多个保险需求或者将保险需求转换成更低级别保险需求得到的需求。

8.根据权利要求6所述的系统，其中更新需求的实际风险点为更新的需求对应的潜在风险点经过变量赋值后转换得到的风险点。

9.根据权利要求6所述的系统，进一步包括使用一个或多个处理器调整所述保障类型的保额。

10.根据权利要求9所述的系统，其中基于以下因素中的一者或多者调整保额：已经购买的保险保额、公司年金、公司或政府福利等中的一者或多者。