一种保险订单生成方法及其相关设备与流程

1.本技术属于数据处理领域，尤其涉及一种保险订单生成方法及其相关设备。


背景技术：

2.保险中介(英文名：insurance intermediary)是指介于保险经营机构之间或保险经营机构与投保人之间，专门从事保险业务咨询与销售、风险管理与安排、价值衡量与评估、损失鉴定与理算等中介服务活动，并从中依法获取佣金或手续费的单位或个人。
3.保险中介因业务发展需要，会跟各保司对接各种类型和形态的保险产品，例如：人身险、个人财产险，团险等等，其中人身险按产品形态分又会有个人险、夫妻单、家庭单；个人财产险在被保标的上存在巨大差异，标的可能是房子、宠物等其它各类可能的财产；团险又与上述商品在投保人和被保人上存在不同，投保人可能是个人，也可能是企业，被保人数量一般会比较多。为了应对市场用户需求，保司会提供各类用户可选的附加险，同时保险中介也会创新组合包装多产品进行组合销售。同时上述各类型保险产品中，多被保人或者存在附加险的情况，均允许用户在不整单退保的前提下可以单被保人或者单附加险进行退保。保险中介为了用户体验，在个险投保过程一般都允许一次为多人投保等。同时保险中介的订单和保司的保单存在一定的差异，同时各家保司对一次投保的保单拆分粒度也不同，订单协议需同时兼顾上述差异带来的额外复杂性。
4.对于不同类型的保司及不同客户的保险需求，其生成的保险订单形式存在较大差别，对于保险中介后端的数据管理造成较大阻碍，导致一定的问题。


技术实现要素：

5.本技术实施例第一方面提供了一种保险订单生成方法，包括：
6.获取用户单次购买行为所包括的购买信息，所述购买信息属于第一位阶信息；
7.基于所述单次购买行为的信息确定逻辑订单信息，所述逻辑订单信息属于第二位阶信息；
8.拆解所述逻辑订单信息，得到第三位阶信息，所述第三位阶信息包括被保人为目标对象的独立订单；
9.将所述第一位阶信息、第二位阶信息和第三位阶信息作为保险订单信息关联存储，所述第三位阶信息属于所述第二位阶信息，所述第二位阶信息属于所述第一位阶信息。
10.基于本技术实施例第一方面所提供的保险订单生成方法，可选的，所述第一位阶信息内包括对所述购买行为的付款设置和发票信息。
11.基于本技术实施例第一方面所提供的保险订单生成方法，可选的，所述第二位阶信息包括对所述逻辑订单信息的付款设置和发票信息。
12.基于本技术实施例第一方面所提供的保险订单生成方法，可选的，所述第三位阶信息包括所述独立报单对应的保险产品存储协议。
13.基于本技术实施例第一方面所提供的保险订单生成方法，可选的，所述第三位阶
信息包括支付设置、保全设置、退保设置、续保设置、续期设置、理赔设置、退费设置和回访设置中的任意一种或多种。
14.基于本技术实施例第一方面所提供的保险订单生成方法，可选的，所述方法还包括：
15.接收用户发送的修改设置；
16.依据所述修改设置调整所述第三位阶信息；
17.基于本技术实施例第一方面所提供的保险订单生成方法，可选的，所述独立订单具有附加险信息。
18.基于本技术实施例第一方面所提供的保险订单生成方法，可选的，所述方法还包括：
19.接收保司的交互请求；
20.依据保司请求使用所述第三位阶信息与所述保司进行交互。
21.本技术实施例第二方面提供了一种保险订单生成设备，包括：
22.获取单元，用于获取用户单次购买行为所包括的购买信息，所述购买信息属于第一位阶信息；
23.确定单元，用于基于所述单次购买行为的信息确定逻辑订单信息，所述逻辑订单信息属于第二位阶信息；
24.拆解单元，用于拆解所述逻辑订单信息，得到第三位阶信息，所述第三位阶信息包括被保人为目标对象的独立订单；
25.存储单元，用于将所述第一位阶信息、第二位阶信息和第三位阶信息作为保险订单信息关联存储，所述第三位阶信息属于所述第二位阶信息，所述第二位阶信息属于所述第一位阶信息。
26.基于本技术实施例第二方面所提供的保险订单生成设备，可选的，所述第一位阶信息内包括对所述购买行为的付款设置和发票信息。
27.基于本技术实施例第二方面所提供的保险订单生成设备，可选的，所述第二位阶信息包括对所述逻辑订单信息的付款设置和发票信息。
28.基于本技术实施例第二方面所提供的保险订单生成设备，可选的，所述第三位阶信息包括所述独立报单对应的保险产品存储协议。
29.基于本技术实施例第二方面所提供的保险订单生成设备，可选的，所述第三位阶信息包括支付设置、保全设置、退保设置、续保设置、续期设置、理赔设置、退费设置和回访设置中的任意一种或多种。
30.基于本技术实施例第二方面所提供的保险订单生成设备，可选的，所述设备还包括：
31.修改单元，用于接收用户发送的修改设置；
32.依据所述修改设置调整所述第三位阶信息；
33.基于本技术实施例第二方面所提供的保险订单生成设备，可选的，所述独立订单具有附加险信息。
34.基于本技术实施例第二方面所提供的保险订单生成设备，可选的，所述设备还包括：
35.修改单元，用于接收保司的交互请求；
36.依据保司请求使用所述第三位阶信息与所述保司进行交互。
37.本技术实施例第三方面提供了一种保险订单生成设备，包括：
38.中央处理器，存储器，输入输出接口，有线或无线网络接口以及电源；
39.所述存储器为短暂存储存储器或持久存储存储器；
40.所述中央处理器配置为与所述存储器通信，在所述设备上执行所述存储器中的指令操作以执行本技术实施例第一方面中任意一项所述的方法。
41.本技术实施例第四方面提供了一种计算机可读存储介质，包括指令，当所述指令在计算机上运行时，使得计算机执行如本技术实施例第一方面中任意一项所述的方法。
42.本技术实施例第五方面提供了一种包含指令的计算机程序产品，当其在计算机上运行时，使得计算机执行如本技术实施例第一方面中任意一项所述的方法。
43.从以上技术方案可以看出，本技术实施例具有以下优点：本技术提供了一种保险订单生成方法，包括：获取用户单次购买行为所包括的购买信息，所述购买信息属于第一位阶信息；基于所述单次购买行为的信息确定逻辑订单信息，所述逻辑订单信息属于第二位阶信息；拆解所述逻辑订单信息，得到第三位阶信息，所述第三位阶信息包括被保人为目标对象的独立订单；将所述第一位阶信息、第二位阶信息和第三位阶信息作为保险订单信息关联存储，所述第三位阶信息属于所述第二位阶信息，所述第二位阶信息属于所述第一位阶信息。基于上述方法可知，本技术所提供的保险订单生成方法基于购买行为、逻辑订单和被保人为目标对象的独立报单的三个层次存储相应的保险订单信息，通过这一存储方式使得各种类型的保险产品及服务均可基于该结构进行数据的存储，并且可通过独立订单的方式获得保单粒度的数据，便于与保单粒度与保司进行交互，提高了数据的通用性。
附图说明
44.为了更清楚地说明本技术实施例或现有技术中的技术方案，下面将对实施例或现有技术描述中所需要使用的附图作简单地介绍，显而易见地，下面描述中的附图仅仅是本技术的实施例，对于本领域普通技术人员来讲，在不付出创造性劳动的前提下，还可以根据提供的附图获得其他的附图。可以理解的是，本部分所提供的附图仅用于更好地理解本方案，不构成对本技术的限定。
45.图1为本技术所提供的保险订单生成方法实施例的一个流程示意图。
46.图2为本技术所提供的保险订单生成方法实施例的另一个流程示意图。
47.图3为本技术所提供的保险订单信息结构的一个示意图。
48.图4为本技术所提供的第三位阶信息与保司间交互过程的一个流程示意图。
49.图5为本技术所提供的保险订单生成设备实施例的一个结构示意图。
50.图6为本技术所提供的保险订单生成设备实施例的另一个结构示意图。
具体实施方式
51.为了使本技术领域的人员更好地理解本技术方案，下面对本技术实施例中的技术方案进行清楚、完整地描述，显然，所描述的实施例仅仅是本技术一部分的实施例，而不是全部的实施例。基于本技术中的实施例，本领域普通技术人员在没有做出创造性劳动前提
下所获得的所有其他实施例，都应当属于本技术保护的范围。同时，为了描述清楚和简明，以下的描述中省略了对公知的功能和结构的描述。
52.本技术的说明书和权利要求书及上述附图中的术语“第一”、“第二”、“第三”、“第四”等(如果存在)是用于区别类似的对象，而不必用于描述特定的顺序或先后次序。应该理解这样使用的数据在适当情况下可以互换，以便这里描述的实施例能够以除了在这里图示或描述的内容以外的顺序实施。此外，术语“包括”和“具有”以及他们的任何变形，意图在于覆盖不排他的包含，例如，包含了一系列步骤或单元的过程、方法、产品或设备不必限于清楚地列出的那些步骤或单元，而是可包括没有清楚地列出的或对于这些过程、方法、产品或设备固有的其它步骤或单元。
53.保险中介(英文名：insurance intermediary)是指介于保险经营机构之间或保险经营机构与投保人之间，专门从事保险业务咨询与销售、风险管理与安排、价值衡量与评估、损失鉴定与理算等中介服务活动，并从中依法获取佣金或手续费的单位或个人。
54.保险中介因业务发展需要，会跟各保司对接各种类型和形态的保险产品，例如：人身险、个人财产险，团险等等，其中人身险按产品形态分又会有个人险、夫妻单、家庭单；个人财产险在被保标的上存在巨大差异，标的可能是房子、宠物等其它各类可能的财产；团险又与上述商品在投保人和被保人上存在不同，投保人可能是个人，也可能是企业，被保人数量一般会比较多。为了应对市场用户需求，保司会提供各类用户可选的附加险，同时保险中介也会创新组合包装多产品进行组合销售。同时上述各类型保险产品中，多被保人或者存在附加险的情况，均允许用户在不整单退保的前提下可以单被保人或者单附加险进行退保。保险中介为了用户体验，在个险投保过程一般都允许一次为多人投保等。同时保险中介的订单和保司的保单存在一定的差异，同时各家保司对一次投保的保单拆分粒度也不同，订单协议需同时兼顾上述差异带来的额外复杂性。
55.对于不同类型的保司及不同客户的保险需求，其生成的保险订单形式存在较大差别，对于保险中介后端的数据管理造成较大阻碍，导致一定的问题。
56.因成本和维护的便捷性考虑，保险中介一般也不会考虑为每种类型的保险产品或者保险形态单独设计不同的订单协议，如果各类型均单独设计不同订单协议，这对依赖订单的上下游业务或系统会是一种灾难，所以需要一种通用的、适用于保险中介的订单存储方式以满足上述各类保险产品，这是一个挑战。针对上述各种复杂保险产品或形态场景，本发明提出了一种通用的、高扩展的订单协议以及该订单协议的生成方法和存储方式，以满足上述各类保险产品和形态对订单的需求，统一了各业务或系统对订单的依赖标准。
57.请参阅图1，本技术所提供的保险订单生成方法的一个实施例包括：步骤101-步骤105。
58.101、获取用户单次购买行为所包括的购买信息。
59.获取用户单次购买行为所包括的购买信息，所述购买信息属于第一位阶信息。其中购买信息即为用户单次购买过程所产生的所有信息，一般可以购买行为发生的时间作为不同购买行为的区分，在实际用户购买保险产品的过程中往往会基于保险中介的推荐购买多份产品，这些产品可能分别对应不同的保险协议，需要不同的被保人信息，但其又属于用户在同一次购买行为中所产生的信息，因此将本次购买行为作为第一位阶信息，以便于在后续数据维护和处理过程中对该类型的信息进行处理，对于第一位阶信息，应当记录本次
购买行为相关联的整体性信息，如本次购买过程的交易双方详细信息，即客户的详细信息与收款方的详细信息，以及为本次购买记录生产相应的id设置等信息，此外还可包括本次购买行为的付款设置以表示本次购买行为是否完成了付款，具体此处不做限定。
60.102、基于所述单次购买行为的信息确定逻辑订单信息。
61.具体的，基于所述单次购买行为的信息确定逻辑订单信息，所述逻辑订单信息属于第二位阶信息。在客户的单次购买行为过程中可能包括一个或多个逻辑订单，对于逻辑订单的定性由工作人员预先设置，一个逻辑订单中可包括一张保单也可包括多张保单，同时逻辑订单的定性也应参照保司的定义而设置，如对于团体保险或夫妻险，对于这一类产品某些保司可能出具多张保单，而某些保司则出具一张保单。对于多张保单的情况而言各张保单关联较为紧密，因此可设置此情况下的多张保单属于一张逻辑订单，具体的逻辑订单形式及包含保单的数量可依据实际情况而定，此处不做限定。在一次购买行为中可能包括一张或多张逻辑订单，具体此处不做限定，每张逻辑订单应作为一条独立的第二位阶信息存储，此外该逻辑订单信息对应的第二位阶信息中还应具有与该逻辑订单相关联的付款设置以表示本次购买行为是否完成了付款，具体此处不做限定。
62.103、拆解所述逻辑订单信息，得到第三位阶信息。
63.具体的，拆解所述逻辑订单信息，得到第三位阶信息，所述第三位阶信息包括被保人为目标对象的独立订单。对于各张逻辑订单以被保人为目标对象进行拆分，得到被保人为目标对象的独立订单，并将每个被保人为目标对象的独立订单作为一条独立的第三位阶信息进行存储，举例而言，如对于一张包含夫妻险的逻辑订单，则会拆解为被保人为丈夫的独立订单和被保人为妻子的独立订单，并得到包含相应独立订单的第三位阶信息。值得注意的是，对于拆分得到的独立订单由于保司的划分情况不同可能具有相同的保单号，也可能具有不同的保单号，具体依据实际情况而定，此处不做限定。此外由于独立订单为用于存储保单的最底层信息，应当具有与保险产品相关联的所有必须信息，如保险产品的存储协议，其中应当包括投保人、被保人、受益人、发票、基本信息和银行卡等信息，具体的信息种类可依据实际情况而定，此处不做限定。
64.104、将所述第一位阶信息、第二位阶信息和第三位阶信息作为保险订单信息关联存储
65.将所述第一位阶信息、第二位阶信息和第三位阶信息作为保险订单信息关联存储，所述第三位阶信息属于所述第二位阶信息，所述第二位阶信息属于所述第一位阶信息。通过从属关系的形式，使得保险订单相关的信息可以更加规范准确的被存储，支持不同形态的保险产品对订单的协议需求业务人员使用。
66.从以上技术方案可以看出，本技术实施例具有以下优点：本技术提供了一种保险订单生成方法，包括：获取用户单次购买行为所包括的购买信息，所述购买信息属于第一位阶信息；基于所述单次购买行为的信息确定逻辑订单信息，所述逻辑订单信息属于第二位阶信息；拆解所述逻辑订单信息，得到第三位阶信息，所述第三位阶信息包括被保人为目标对象的独立订单；将所述第一位阶信息、第二位阶信息和第三位阶信息作为保险订单信息关联存储，所述第三位阶信息属于所述第二位阶信息，所述第二位阶信息属于所述第一位阶信息。基于上述方法可知，本技术所提供的保险订单生成方法基于购买行为、逻辑订单和被保人为目标对象的独立报单的三个层次存储相应的保险订单信息，通过这一存储方式使
得各种类型的保险产品及服务均可基于该结构进行数据的存储，并且可通过独立订单的方式获得保单粒度的数据，便于与保单粒度与保司进行交互，提高了数据的通用性。
67.为便于在实际订单处理过程中使用本方法，本技术还提供了一种可选择实施的更为详细的实施例，请参阅图2，本技术的一个实施例包括：步骤201-步骤208。
68.201、获取用户单次购买行为所包括的购买信息。
69.获取用户单次购买行为所包括的购买信息，所述购买信息属于第一位阶信息，所述第一位阶信息内包括对所述购买行为的付款设置和发票信息。本步骤与前述图1对应实施例中步骤101类似，具体可参照前述内容，此处不做赘述。
70.202、基于所述单次购买行为的信息确定逻辑订单信息。
71.具体的，基于所述单次购买行为的信息确定逻辑订单信息，所述逻辑订单信息属于第二位阶信息，所述第二位阶信息包括对所述逻辑订单信息的付款设置和发票信息。本步骤与前述图1对应实施例中步骤201类似，具体可参照前述内容，此处不做赘述。
72.203、拆解所述逻辑订单信息，得到第三位阶信息。
73.具体的，拆解所述逻辑订单信息，得到第三位阶信息，所述第三位阶信息包括被保人为目标对象的独立订单。所述第三位阶信息包括所述独立报单对应的保险产品存储协议。所述第三位阶信息包括支付设置、保全设置、退保设置、续保设置、续期设置、理赔设置、退费设置和回访设置中的任意一种或多种。即第三位阶信息包括了独立报单的多种类细节信息，以便支持中介及客户进行修改，具体的第三位阶信息所包括的内容可依据实际情况进行调整，此处不做限定。第三位阶信息包括被保人为目标对象的独立订单，独立订单挂载保险标的，例如个人险标的为被保人自身，财产险为财产标的，例如宠物，一个独立订单依据产品形态可挂载多个标的。附加险挂载在独立订单粒度，一个独立订单可依据投保方案挂载多个标的。独立订单上在中介侧支持保单粒度的所有操作。
74.此外，需要说明的是，对于保险产品内用户所额外选择的附加险内容同样挂载在第三位阶信息内，对于一个独立订单而言，可能存在任意数量的附加险，具体的附加险数量可依据实际情况而定，此处不做限定。将附加险信息挂在第三位阶信息上更便于与保司交互和进行数据的管理。
75.204、将所述第一位阶信息、第二位阶信息和第三位阶信息作为保险订单信息关联存储。
76.将所述第一位阶信息、第二位阶信息和第三位阶信息作为保险订单信息关联存储，所述第三位阶信息属于所述第二位阶信息，所述第二位阶信息属于所述第一位阶信息。通过从属关系的形式，使得保险订单相关的信息可以更加规范准确的被存储，支持不同形态的保险产品对订单的协议需求业务人员使用。
77.205、接收用户发送的修改设置。
78.具体的，接收用户发送的修改设置，用户可基于相应界面对第三位阶层面的信息进行修改调整，具体的，可参照图3，图3中所展示的大单即为第一位阶信息，逻辑单即为第二位阶信息，小单即为第三位阶信息，在大单范围内用户可以执行开发票及付款等操作进而使用和调整第一位阶信息，在逻辑单范围内用户可以执行开发票及针对某一特定逻辑订单的付款行为，进而使用和调整第二位阶信息，在小单范围内由于记载有被保人为单一独立的目标对象的独立报单因此可以修改可调整保单相关联的大部分信息，如图所示，可包
括：支付、修改投保人、修改被保人、更改受益人、申请发票(纸质电子)、保全、申请纸质保单、解除合同、修改续期银行卡、修改基本信息、犹豫期退保、生效前退保、犹豫期外退保、续保、回访续期、理赔、评论、电子保单下载(用户侧)、退费和开发票等操作，同时也支持对于第三位阶信息下各个附加险的相应操作，如单独退保或加保等过程，具体操作方式及可执行的操作种类可依据实际情况而定，此处不做限定。
79.206、依据所述修改设置调整所述第三位阶信息。
80.具体的，依据所述修改设置调整所述第三位阶信息。即依据用户的操作修改第三位阶信息并进行存储，同时对于某些信息的修改还会触发与保司的交互过程，如修改投保人、修改被保人何更改受益人等操作，具体此处不做限定。
81.207、接收保司的交互请求。
82.具体的，存储数据的保险中介服务器接收保司的交互请求，可以理解的是，在实际实施过程中也可由中介服务器主动向保司发送交互请求进而执行交互过程，具体可依据实际情况而定，此处不做限定。
83.208、依据保司请求使用所述第三位阶信息与所述保司进行交互。
84.具体的，依据保司请求使用所述第三位阶信息与所述保司进行交互。进而保证保司所存储信息与保险中介存储的信息一致，具体的交互过程可参照图4，包括退费、退保、生效和失效等多个层面的交互，在交互过程中使用第三位阶信息更加准确简洁，便于数据的管理过程。
85.从以上技术方案可以看出，本技术实施例具有以下优点：本技术提供了一种保险订单生成方法，包括：获取用户单次购买行为所包括的购买信息，所述购买信息属于第一位阶信息；基于所述单次购买行为的信息确定逻辑订单信息，所述逻辑订单信息属于第二位阶信息；拆解所述逻辑订单信息，得到第三位阶信息，所述第三位阶信息包括被保人为目标对象的独立订单；将所述第一位阶信息、第二位阶信息和第三位阶信息作为保险订单信息关联存储，所述第三位阶信息属于所述第二位阶信息，所述第二位阶信息属于所述第一位阶信息。基于上述方法可知，本技术所提供的保险订单生成方法基于购买行为、逻辑订单和被保人为目标对象的独立报单的三个层次存储相应的保险订单信息，通过这一存储方式使得各种类型的保险产品及服务均可基于该结构进行数据的存储，并且可通过独立订单的方式获得保单粒度的数据，便于与保单粒度与保司进行交互，提高了数据的通用性。
86.上述内容对本技术所提供的保险订单生成方法进行了描述，为支持上述实施例的实施，本技术还提供了一种保险订单生成设备，请参阅图5，本技术的一个实施例包括：
87.获取单元501，用于获取用户单次购买行为所包括的购买信息，所述购买信息属于第一位阶信息；
88.确定单元502，用于基于所述单次购买行为的信息确定逻辑订单信息，所述逻辑订单信息属于第二位阶信息；
89.拆解单元503，用于拆解所述逻辑订单信息，得到第三位阶信息，所述第三位阶信息包括被保人为目标对象的独立订单；
90.存储单元504，用于将所述第一位阶信息、第二位阶信息和第三位阶信息作为保险订单信息关联存储，所述第三位阶信息属于所述第二位阶信息，所述第二位阶信息属于所述第一位阶信息。
91.可选的，所述第一位阶信息内包括对所述购买行为的付款设置和发票信息。
92.可选的，所述第二位阶信息包括对所述逻辑订单信息的付款设置和发票信息。
93.可选的，所述第三位阶信息包括所述独立报单对应的保险产品存储协议。
94.可选的，所述第三位阶信息包括支付设置、保全设置、退保设置、续保设置、续期设置、理赔设置、退费设置和回访设置中的任意一种或多种。
95.可选的，所述设备还包括：
96.修改单元，用于接收用户发送的修改设置；
97.依据所述修改设置调整所述第三位阶信息；
98.可选的，所述独立订单具有附加险信息。
99.可选的，所述设备还包括：
100.修改单元，用于接收保司的交互请求；
101.依据保司请求使用所述第三位阶信息与所述保司进行交互。
102.本实施例中，保险订单生成设备中各单元所执行的流程与前述图1所对应的实施例中描述的方法流程类似，此处不再赘述。
103.图6是本技术实施例提供的一种保险订单生成设备服务器的结构示意图，该服务器600可以包括一个或一个以上中央处理器(central processing units，cpu)601和存储器605，该存储器605中存储有一个或一个以上的应用程序或数据。
104.本实施例中，中央处理器601中的具体功能模块划分可以与前述图5中所描述的各单元的功能模块划分方式类似，此处不再赘述。
105.其中，存储器605可以是易失性存储或持久存储。存储在存储器605的程序可以包括一个或一个以上模块，每个模块可以包括对服务器中的一系列指令操作。更进一步地，中央处理器601可以设置为与存储器605通信，在服务器600上执行存储器605中的一系列指令操作。
106.服务器600还可以包括一个或一个以上电源602，一个或一个以上有线或无线网络接口603，一个或一个以上输入输出接口604，和/或，一个或一个以上操作系统，例如windows servertm，mac os xtm，unixtm,linuxtm，freebsdtm等。
107.该中央处理器601可以执行前述图1或图2所示实施例中所执行的操作，具体此处不再赘述。
108.本技术实施例还提供了一种计算机存储介质，该计算机存储介质用于储存为上述保险订单生成方法所用的计算机软件指令，其包括用于执行为保险订单生成方法所设计的程序。
109.该保险订单生成方法可以如前述图1中所描述的保险订单生成方法。
110.本技术实施例还提供了一种计算机程序产品，该计算机程序产品包括计算机软件指令，该计算机软件指令可通过处理器进行加载来实现上述图1图2中任意一项的保险订单生成方法的流程。
111.在本技术所提供的几个实施例中，应该理解到，所揭露的系统，装置和方法，可以通过其它的方式实现。例如，以上所描述的装置实施例仅仅是示意性的，例如，电路的等效变换，单元的划分，仅仅为一种逻辑功能划分，实际实现时可以有另外的划分方式，例如多个单元或组件可以结合或者可以集成到另一个系统，或一些特征可以忽略，或不执行。另一
点，所显示或讨论的相互之间的耦合或直接耦合或通信连接可以是通过一些接口，装置或单元的间接耦合或通信连接，可以是电性，机械或其它的形式。
112.所述作为分离部件说明的单元可以是或者也可以不是物理上分开的，作为单元显示的部件可以是或者也可以不是物理单元，即可以位于一个地方，或者也可以分布到多个单元上。可以根据实际的需要选择其中的部分或者全部单元来实现本实施例方案的目的。
113.另外，在本技术各个实施例中的各功能单元可以集成在一个处理单元中，也可以是各个单元单独物理存在，也可以两个或两个以上单元集成在一个单元中。上述集成的单元既可以采用硬件的形式实现，也可以采用软件功能单元的形式实现。
114.以上所述仅为本发明的较佳实施例而已，并不用以限制本发明，凡在本发明的精神和原则之内所作的任何修改、等同替换或改进等，均应包含在本发明的保护范围之内。