一种业务数据处理方法、装置及电子设备与流程

1.本技术涉及处理技术，更具体的说，是涉及一种业务数据处理方法、装置及电子设备。


背景技术：

2.呼叫中心承担着售前和售后咨询以及服务的业务，其能够帮助解决用户疑问和业务问题，有利于维系客户和开拓市场。
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.图1为本技术实施例公开的一种业务数据处理方法的流程图；
38.图2为本技术实施例公开的一个确定预估业务需求数据的流程图；
39.图3为本技术实施例公开的另一种业务数据处理方法的流程图；
40.图4为本技术实施例公开的确定当前业务路径的业务需求数据的流程图；
41.图5为本技术实施例公开的一个业务数据处理流程示意图；
42.图6为本技术实施例公开的一种业务数据处理装置的结构示意图。
具体实施方式
43.下面将结合本技术实施例中的附图，对本技术实施例中的技术方案进行清楚、完整地描述，显然，所描述的实施例仅仅是本技术一部分实施例，而不是全部的实施例。基于本技术中的实施例，本领域普通技术人员在没有做出创造性劳动前提下所获得的所有其他实施例，都属于本技术保护的范围。
44.图1为本技术实施例公开的一种业务数据处理方法的流程图，参见图1所示，业务数据处理方法可以包括：
45.步骤101：获得当前业务路径的信息数据，所述信息数据包括任务队列数量和任务属性参数。
46.业务处理系统中可以包含多个业务路径，但这些业务路径的数量也是有限的。面对大量的用户业务请求，需要将这些用户业务请求合理的分配给数量有限的业务路径，使得用户需求能够被及时有效的解决。在一个实际的应用场景中，业务处理系统可以是人工服务系统，多个业务路径对应多个人工坐席，也可以理解为客服人员，这些人工坐席可以通过电话语音方式、即时通信方式等实现与客户的交互，解决客户的业务问题。
47.在业务处理系统正常运行的过程中，其可以周期性的获得各业务路径的信息数据，以便于后续实时确定各个业务路径的工作量，从而为后续进入业务处理系统的用户业务请求的分配提供参考依据。其中，获得各业务路径的信息数据的周期可以根据实际应用场景中业务路径数量与用户业务请求量合理确定。
48.需要说明的是，任务队列数量和任务属性参数仅为当前业务路径的信息数据的一种实现，实际情况中，任何可以辅助确定当前业务路径的工作量的数据都可以包含在所述信息数据中。当然，当前业务路径的信息数据除了包括可以辅助确定当前业务路径的工作量的数据外，也可以包含一些当前业务路径的相关信息，如业务路径编号、业务路径的一些配置数据等，本技术对此并不做固定限制。
49.步骤102：基于所述任务队列数量和所述任务属性参数确定当前业务路径的业务需求数据。
50.其中，任务队列数量可以表征已经接入当前业务路径的任务数量，任务属性参数可以表征正在服务的任务的工作复杂度。其中，工作复杂度可以基于任务涉及主题以及具体的任务问题来综合确定。例如，对于问题“手机怎么连接wifi”，该问题比较简单，人工坐席可以直接口述回答或编辑文字回答“打开手机设置——选择无线局域网wlan——搜索可用wlan——选择想要连接的网络——输入密码，完成连接”，甚至一些实现中，人工坐席可以直接调用预置的解答模板中的回答模板，直接发送给客户；对于这类比较简单的问题，其工作复杂度就比较低；而对于“手机黑屏是什么原因”的问题，其可能存在很多原因，例如可
能是系统问题，也可能是主板的问题或显示屏的问题，这种问题就需要人工坐席询问客户一些问题，并基于客户的回答逐步锁定手机黑屏的具体原因，从而这类问题需要人工坐席与客户有较多次的沟通交互，其工作复杂度就比较高。
51.确定了当前业务路径的任务队列数量和任务属性参数，依据预设策略就可以得到当前业务路径的业务需求数据，所述业务需求数据对应当前业务路径的工作量，表征当前业务路径需要做多少工作才能够满足当前接入的所有任务的业务需求。
52.步骤103：基于所述业务需求数据和分配策略确定是否将用户业务请求接入当前业务路径。
53.每个业务路径均会有服务上限数据，该服务上限数据可以但不限定为包括最多服务任务数量、最大工作量、最大等待时间中的至少一种；一些实现中，服务上限数据可用于配置分配策略，例如，分配策略可以是在当前业务路径已经接入的任务数量达到最多服务任务数量时，若当前业务路径的工作量没有超出最大工作量，则可以接入新的用户业务请求。
54.若当前业务处理系统接入一个新的用户业务请求，可随机选择一个或基于任务数量均衡的策略选择一个当前业务路径，并基于当前业务路径的业务需求数据和所述分配策略确定是否将用户业务请求接入当前业务路径。
55.为了更好的理解本技术实现，现给出一个例子：1、假设a和b两个坐席同时服务用户业务请求上限都为5个，当前服务中用户业务请求都为4个，但a坐席4个用户业务请求均为简用户业务请求，b坐席4个用户业务请求中有3个复杂用户业务请求，1个简单用户业务请求，此时新进入一个服务请求，普通方案会随机分配给a坐席或者b坐席，采用本方案会分配给a坐席，从而使该服务请求得到更快的响应和解决；可见本技术方案能够缩短用户等待时长，提高用户体验。另一个例子：一般实现中各坐席同时服务用户业务请求上限均为固定值，假设为5个，a和b两个坐席当前服务中用户业务请求都为5个，但a坐席5个用户业务请求均为简单用户业务请求，b坐席5个用户业务请求中有4个复杂用户业务请求，1个简单用户业务请求，此时新进入一个服务请求，当前方案会认为a坐席和b坐席均已达到服务上限，无法满足该服务请求，采用本方案会分配给a坐席，从而使用相同资源解决了更多的问题；可见本技术方案能够结合用户业务请求复杂度动态调整服务上限数据，业务路径能效利用率能够有效提升。
56.本实施例所述业务数据处理方法在为业务请求分配业务路径时，首先确定能够表征业务路径工作量大小的业务需求数据，而业务路径的工作量综合考虑了业务路径的任务数量和任务难易程度，更具实际指导意义；然后再根据业务需求数据确定当前业务路径的工作是否已达到饱和，进而确定是否接入用户业务请求，该实现相对于仅以业务路径的任务队列数量作为用户业务请求接入依据的方案来说更加客观均衡，有利于最大化业务处理效率，提升用户体验。
57.一个实现中，所述基于所述业务需求数据和分配策略确定是否将用户业务请求接入当前业务路径，可以包括：基于用户业务请求的业务请求内容确定所述用户业务请求的预估业务需求数据；基于所述业务需求数据、所述预估业务需求数据以及所述分配策略确定是否将所述用户业务请求接入当前业务路径。
58.用户业务请求在接入业务处理系统时，可能已经包含了业务问题，这样，可以基于
用户业务请求中的业务问题来进行预测，得到解决该用户业务请求所需的预估业务需求数据，进而后续在判断是否可以将该用户业务请求接入当前业务路径时，也将所述预估业务需求数据作为一项参考内容。
59.例如，用户业务请求中携带问题“**设备如何实现投屏”，则系统经过自然语言处理相关技术，可以确定该用户业务请求需要解决的是投屏指导问题，基于历史解决该类问题的相关信息，如解决问题时长、坐席与客户交互次数等，可以预测出所述预估业务需求数据。
60.图2为本技术实施例公开的一个确定预估业务需求数据的流程图，参见图2所示，所述基于用户业务请求的业务请求内容确定所述用户业务请求的预估业务需求数据，可以包括：
61.步骤201：在业务请求内容中包含第一信息的情况下，基于所述第一信息确定所述用户业务请求的预估业务需求数据。
62.其中的第一信息可以但不限制为包括问题主题和问题类型，如前述“**设备如何实现投屏”的问题，其问题主题为“投屏技术”，问题类型为“指导型问题”。再如，对于问题“手机连接不上wifi”，其问题主题为网络连接，问题类型为“故障型问题”。不同问题主题和/或问题类型的问题，其处理难度是不同的，系统中可以针对不同的问题主题以及问题类型预先设定处理复杂度等级，而后依据用户业务请求的业务请求内容的第一信息情况，预测到该用户业务请求的预估业务需求数据。
63.步骤202：在业务请求内容中不包含第一信息的情况下，确定所述用户业务请求的预估业务需求数据为第一数据。
64.业务请求内容中不包含第一信息，即业务请求内容中并没有明确的业务问题，而由于用户业务请求还没有接入确定的业务路径，也无法了解或预估该用户业务请求的业务需求数据。对于这种情况，通常可以为这类用户业务请求设定一个固定的数值作为其预估业务需求数据。
65.例如，业务请求内容中包含“你好，在吗？”的内容，这个问题仅仅是打招呼式的语言，不涉及任何业务问题，因此基于业务请求内容，并不能够通过相应计算得到用户业务请求的预估业务需求数据，只能以一个合理的设定值，也即所述第一数据，作为该用户业务请求的预估业务需求数据。
66.一个实现中，所述分配策略包括从业务需求余量大于预估业务需求数据的业务路径中随机选择一个确定为接入用户业务请求的业务路径，则业务数据处理方法还可以包括：基于当前业务路径的业务需求上限和所述业务需求数据确定得到业务需求余量。
67.由于包含多个业务路径，因此在为用户业务请求分配业务路径时，就需要依据一定的原则，本实现中，可以依据业务需求余量来协助确定用户业务请求所能够分配的业务路径。每个业务路径都可以有自身的业务需求上限，当确定了新接入业务处理系统的用户业务请求的预估业务需求数据后，可以考量哪些业务路径的业务需求余量能够满足该用户业务请求的处理。可以理解的，用户业务请求的预估业务需求数据小于业务路径的业务需求余量的情况下，该业务路径具备接入该用户业务请求的能力。
68.一个例子中，如业务路径a的业务需求上限为10，当前已经接入的任务的业务需求数据为7.5，若用户业务请求b的预估业务需求数据为2，则7.5+2小于10，业务路径a可以接
入用户业务请求b；若用户业务请求b的预估业务需求数据为3，则7.5+3大于10，业务路径a不可以接入用户业务请求b。
69.图3为本技术实施例公开的另一种业务数据处理方法的流程图，参见图3所示，另一个实现中，业务数据处理方法可以包括：
70.步骤301：获得当前业务路径的信息数据，所述信息数据包括任务队列数量和任务属性参数。
71.步骤302：基于所述任务队列数量和所述任务属性参数确定当前业务路径的业务需求数据。
72.步骤303：基于所述业务需求数据和分配策略确定将用户业务请求接入当前业务路径。
73.步骤304：基于各个业务路径的工作复杂度将所述用户业务请求进行业务路径的重新分配，所述工作复杂度的判断依据包括所述任务队列数量和所述任务属性参数。
74.在用户业务请求已经接入当前业务路径后，还可以周期性的实时确定各个业务路径的工作复杂度，所述工作复杂度为能够反应当前业务路径工作繁忙程度或工作量的参数，其也可以基于所述任务队列数量和所述任务属性参数，经过设定的计算模型确定。
75.例如，在用户业务请求已经接入当前业务路径后，确定业务路径c的工作复杂度最小，则可以将所述用户业务请求重新分配给业务路径c，以使得所述用户业务请求能够被及时处理。
76.当然，实际应用中，若用户业务请求在当前业务路径已经开始交互处理，为了保障服务的连续性，也可以不对所述用户业务请求进行重新分配。若业务路径c的工作复杂度比当前业务路径的工作复杂度低，且差值超过第一阈值，则可以确定将所述用户业务请求接入业务路径能够大大加快所述用户业务请求的处理时间，则可以直接将所述用户业务请求重新分配给业务路径c。
77.本实施例中，在当前业务路径已经接入用户业务请求的情况下，还可以实时的对所有的业务路径的工作复杂度进行评估，若确定存在其他工作复杂度相对于当前业务路径更低的业务路径，可以将用户业务请求重新分配给工作复杂度更小的业务路径，以使得所述用户业务请求被更快的处理，减少用户的等待时间。
78.另一个实现中在将所述用户业务请求接入当前业务路径后，还可以包括：基于各个业务路径的等待时长将所述用户业务数据请求进行业务路径的重新分配。
79.其中，等待时长也是能够反应业务路径工作繁忙程度的一个指标，其确定依据也可以基于所述任务队列数量和所述任务属性参数。
80.本实现和前述基于业务路径工作复杂度进行用户业务请求重分配的实现类似，为两个可以并列实现的技术方案。其中，业务路径的工作复杂度和等待时长都能够反应业务路径的工作量，不过两个参数表征的具体意义和具体确定方法存在差异，但无论依据什么参数对用户业务请求进行重分配，整体的原则都是能够更快的处理所述用户业务请求，减少用户的等待时间，提升用户的被服务体验。
81.当然，对用户业务请求进行重分配所依据的参数也不限于上述工作复杂度和/或等待时长，实现中还可以依据其他参数来实现，只要其依据的原则是能够更快的处理用户业务请求，都应属于本技术方案的保护范围。
82.图4为本技术实施例公开的确定当前业务路径的业务需求数据的流程图，参见图4所示，一个实现中，所述基于所述任务队列数量和所述任务属性参数确定当前业务路径的业务需求数据，可以包括：
83.步骤401：确定当前业务路径中每一个任务的任务复杂度。
84.每一个用户业务请求对应一个处理任务，每个任务都具有其任务复杂度，可以结合前述不同问题所涉及的问题主题和问题属性不同的内容理解，不同任务的任务复杂度也不相同，因此处理不同任务所需的工作量也不相同。
85.步骤402：基于每一个任务的任务复杂度确定该任务的子需求数据。
86.每个业务路径包含多个任务，每个任务都有其任务复杂度，基于任务复杂度可以确定处理该任务的子需求数据，也即处理每个任务所需的工作量。
87.步骤403：将所有任务的子需求数据汇总为业务需求数据。
88.把当前业务路径中包含的所有任务的子需求数据求总和，就能够得到当前业务路径的业务需求数据。
89.前述实施例中，所述获得当前业务路径的信息数据，可以包括：采用人工智能算法确定当前业务路径下每一个任务的任务属性参数。
90.已经接入当前业务路径的任务，其对应用户可能已经与人工坐席进行了一些会话交互，基于该交互内容，系统可通过人工智能算法处理确定得到每个任务对应的任务属性参数，该任务属性参数可以但不限制为包括任务类型、任务主题等。
91.在一个具体的实现中，业务处理系统的处理过程可参见图5，图5为本技术实施例公开的一个业务数据处理流程示意图，结合图5所示，业务处理系统的处理流程可以包括：
92.1、系统收集呼叫中心各坐席当前正在处理的用户业务请求；
93.2、系统自动分析交互内容，通过机器学习模型自动评估各用户业务请求复杂度；
94.3、系统通过同时服务用户业务请求量及用户业务请求复杂度综合评估业务路径当前忙碌程；
95.4、新用户接入呼叫中心，提出服务请求；
96.5、系统自动分析交互内容，通过机器学习模型自动评估该用户业务请求复杂度；
97.6、系统判断该业务路径是否可应答该请求；
98.7、如可应答，接入用户服务请求，否则重复1、2、3步骤直到匹配到业务路径。
99.本技术所述业务数据处理方法，通过客户与人工坐席的对话内容，可以自动对用户业务请求进行复杂度评估，根据每个人工坐席当前处理的各个用户业务请求的复杂度综合评估对应坐席(业务路径)的忙碌程度，进而判断将新进入排队的用户业务请求分配给哪个坐席，从而极大提升呼叫中心坐席(业务处理系统)的效能利用率。
100.对于前述的各方法实施例，为了简单描述，故将其都表述为一系列的动作组合，但是本领域技术人员应该知悉，本技术并不受所描述的动作顺序的限制，因为依据本技术，某些步骤可以采用其他顺序或者同时进行。其次，本领域技术人员也应该知悉，说明书中所描述的实施例均属于优选实施例，所涉及的动作和模块并不一定是本技术所必须的。
101.上述本技术公开的实施例中详细描述了方法，对于本技术的方法可采用多种形式的装置实现，因此本技术还公开了一种装置，下面给出具体的实施例进行详细说明。
102.图6为本技术实施例公开的一种业务数据处理装置的结构示意图，参见图6所示，
业务数据处理装置60可以包括：
103.数据获得模块601，用于获得当前业务路径的信息数据，所述信息数据包括任务队列数量和任务属性参数。
104.需求确定模块602，用于基于所述任务队列数量和所述任务属性参数确定当前业务路径的业务需求数据。
105.接入确定模块603，用于基于所述业务需求数据和分配策略确定是否将用户业务请求接入当前业务路径。
106.本实施例所述业务数据处理装置在为业务请求分配业务路径时，首先确定能够表征业务路径工作量大小的业务需求数据，而业务路径的工作量综合考虑了业务路径的任务数量和任务难易程度，更具实际指导意义；然后再根据业务需求数据确定当前业务路径的工作是否已达到饱和，进而确定是否接入用户业务请求，该实现相对于仅以业务路径的任务队列数量作为用户业务请求接入依据的方案来说更加客观均衡，有利于最大化业务处理效率，提升用户体验。
107.一个实现中，所述接入确定模块可包括：需求预估模块，用于基于用户业务请求的业务请求内容确定所述用户业务请求的预估业务需求数据；接入确定子模块，用于基于所述业务需求数据、所述预估业务需求数据以及所述分配策略确定是否将所述用户业务请求接入当前业务路径。
108.一个实现中，所述需求预估模块具体可用于：在业务请求内容中包含第一信息的情况下，基于所述第一信息确定所述用户业务请求的预估业务需求数据；在业务请求内容中不包含第一信息的情况下，确定所述用户业务请求的预估业务需求数据为第一数据。
109.一个实现中，所述分配策略包括从业务需求余量大于预估业务需求数据的业务路径中随机选择一个确定为接入用户业务请求的业务路径，则所述业务数据处理装置还包括：余量确定模块，用于基于当前业务路径的业务需求上限和所述业务需求数据确定得到业务需求余量。
110.一个实现中，业务数据处理装置还包括请求重分配模块，用于在将所述用户业务请求接入当前业务路径后，基于各个业务路径的工作复杂度将所述用户业务请求进行业务路径的重新分配，所述工作复杂度的判断依据包括所述任务队列数量和所述任务属性参数。
111.一个实现中，所述请求重分配模块用于：在将所述用户业务请求接入当前业务路径后，基于各个业务路径的等待时长将所述用户业务数据请求进行业务路径的重新分配。
112.一个实现中，所述需求确定模块具体用于：确定当前业务路径中每一个任务的任务复杂度；基于每一个任务的任务复杂度确定该任务的子需求数据；将所有任务的子需求数据汇总为业务需求数据。
113.一个实现中，所述数据获得模块具体用于：采用人工智能算法确定当前业务路径下每一个任务的任务属性参数。
114.上述实施例中的所述的任意一种业务数据处理装置包括处理器和存储器，上述实施例中的数据获得模块、需求确定模块、接入确定模块、请求重分配模、余量确定模块、需求预估模块、接入确定子模块等均作为程序模块存储在存储器中，由处理器执行存储在所述存储器中的上述程序模块来实现相应的功能。
115.处理器中包含内核，由内核去存储器中调取相应的程序模块。内核可以设置一个或多个，通过调整内核参数来实现回访数据的处理。
116.存储器可能包括计算机可读介质中的非永久性存储器，随机存取存储器(ram)和/或非易失性内存等形式，如只读存储器(rom)或闪存(flash ram)，存储器包括至少一个存储芯片。
117.本技术实施例提供了一种存储介质，其上存储有程序，该程序被处理器执行时实现上述实施例中所述的业务数据处理方法。
118.本技术实施例提供了一种处理器，所述处理器用于运行程序，其中，所述程序运行时执行上述实施例中所述的业务数据处理方法。
119.进一步，本实施例提供了一种电子设备，包括处理器以及存储器。其中存储器用于存储所述处理器的可执行指令，所述处理器配置为经由执行所述可执行指令来执行上述实施例中所述的业务数据处理方法。其中，所述可执行指令包括：获得当前业务路径的信息数据，所述信息数据包括任务队列数量和任务属性参数；基于所述任务队列数量和所述任务属性参数确定当前业务路径的业务需求数据；基于所述业务需求数据和分配策略确定是否将用户业务请求接入当前业务路径。
120.本说明书中各个实施例采用递进的方式描述，每个实施例重点说明的都是与其他实施例的不同之处，各个实施例之间相同相似部分互相参见即可。对于实施例公开的装置而言，由于其与实施例公开的方法相对应，所以描述的比较简单，相关之处参见方法部分说明即可。
121.还需要说明的是，在本文中，诸如第一和第二等之类的关系术语仅仅用来将一个实体或者操作与另一个实体或操作区分开来，而不一定要求或者暗示这些实体或操作之间存在任何这种实际的关系或者顺序。而且，术语“包括”、“包含”或者其任何其他变体意在涵盖非排他性的包含，从而使得包括一系列要素的过程、方法、物品或者设备不仅包括那些要素，而且还包括没有明确列出的其他要素，或者是还包括为这种过程、方法、物品或者设备所固有的要素。在没有更多限制的情况下，由语句“包括一个
……”
限定的要素，并不排除在包括所述要素的过程、方法、物品或者设备中还存在另外的相同要素。
122.结合本文中所公开的实施例描述的方法或算法的步骤可以直接用硬件、处理器执行的软件模块，或者二者的结合来实施。软件模块可以置于随机存储器(ram)、内存、只读存储器(rom)、电可编程rom、电可擦除可编程rom、寄存器、硬盘、可移动磁盘、cd
‑
rom、或技术领域内所公知的任意其它形式的存储介质中。
123.对所公开的实施例的上述说明，使本领域专业技术人员能够实现或使用本技术。对这些实施例的多种修改对本领域的专业技术人员来说将是显而易见的，本文中所定义的一般原理可以在不脱离本技术的精神或范围的情况下，在其它实施例中实现。因此，本技术将不会被限制于本文所示的这些实施例，而是要符合与本文所公开的原理和新颖特点相一致的最宽的范围。