技术领域
[0001] 本申请实施例涉及数据处理技术领域，尤其涉及一种数据处理方法、装置、服务器设备和芯片系统。
相关背景技术
[0002] 目前，电子设备在向用户提供服务的过程中，可以与云端的服务器进行交互，实现向用户推送营销活动的功能。
[0003] 示例性的，在服务器中可以配置有任务，该任务与活动相关。用户在电子设备上输入与活动相关的操作(如参加活动、在活动中领取奖励等)的情况下，服务器可以根据任务中配置的判断逻辑，对电子设备进行对应的响应。例如，根据用户当前参与活动的次数、与当前活动对应的指定动作(如购买行为)的参与信息等，确定是否满足任务中的判断逻辑，进而生成对应的响应信息发送给电子设备。由此电子设备就可以根据响应信息进行对应的界面显示，如奖励领取、活动参与失败等。
[0004] 在服务器中可以配置大量的任务，以便支持丰富的营销活动。现有的任务配置和处理机制中，存在任务配置复杂、处理效率低下的问题。
具体实施方式
[0055] 以下，术语“第一”、“第二”仅用于描述目的，而不能理解为指示或暗示相对重要性或者隐含指明所指示的技术特征的数量。由此，限定有“第一”、“第二”的特征可以明示或者隐含地包括一个或者更多个该特征。在本实施例的描述中，除非另有说明，“多个”的含义是两个或两个以上。
[0056] 目前，电子设备向用户提供的服务类型越来越丰富。在一些实现中，电子设备可以通过与云端服务器进行交互，向用户提供业务服务。云端服务器也可简称为云端。
[0057] 示例性的，参考图1，为一种通信场景示意图。电子设备可以与云端进行通信连接。在云端中可以配置有一个或多个服务器，不同服务器都可以用于支持不同的业务服务，或者多个服务器共同配合以便支持更加复杂的业务服务。
[0058] 在一些实现中，该配置在云端的服务器可以包括运营服务器。
[0059] 在运营服务器中可以配置有一个或多个活动。这样，在用户使用电子设备过程中，可以通过电子设备参加活动。在达成活动对应配置的条件时，则云端可以向电子设备推送对应的奖励信息。
[0060] 作为一种示例，参考图2，为一种电子设备显示活动的界面示例。
[0061] 在如图2的示例中，该活动可以对应包括在名称为“每日任务”的活动集合中。在该活动集合中，可以包括多个已配置的活动。
[0062] 例如，该已配置的活动可以包括基于用户对指定主题的购买行为的活动1、基于用户对已有主题资源试用行为的活动2、基于用户对指定专区(如aa专区)的浏览行为的活动3。
[0063] 这样，在电子设备的界面21上，就可以分别显示各个活动对应的信息。
[0064] 以活动1为例进行说明。在界面21上可以显示有该活动1的图像201、活动名称202、对应的积分信息203，以及标示当前活动状态的按钮204等。
[0065] 例如，活动名称202可以包括“购买资源”。在本示例中，活动名称202中还可以包括对该活动的相关解释，比如“限定主题”的文字提示信息。
[0066] 在该如图2的示例中，积分信息203可以包括“+5”的提示信息。这样，用户就可以知晓当前活动达成条件之后，可以被配置有5个积分的奖励。
[0067] 此外，在该如图2的示例中，按钮204也可以包括文字提示信息。例如，该文字提示信息可以是根据当前用户行为是否达到配置在活动1中的相关条件对应显示的。本示例中，该文字提示信息可以对应于当前活动状态为“去完成”、“领取奖励”，或者“已完成”。
[0068] 以配置在活动1中的相关条件包括：购买资源的次数达到2次为例。
[0069] 这样，在用户购买指定资源的次数未达到2次的情况下，则在按钮204中的文字提示信息可以显示为“去完成”。在用户购买指定资源的次数已经达到2次，但是未领取对应奖励的情况下，则在按钮204中的文字提示信息可以显示为“领取奖励”。在用户购买指定资源的次数已经达到2次，已经领取对应奖励的情况下，则在按钮204中的文字提示信息可以显示为“已完成”。
[0070] 在一些实现中，用户可以对按钮204进一步输入指示。对应的，电子设备可以与运营服务器进行交互，进行与当前操作对应的响应。
[0071] 示例性的，以当前活动状态为“去完成”为例。如图3所示，在用户点击按钮204的情况下，则电子设备可以从运营服务器获取对该点击操作的响应界面并显示。例如，电子设备可以从运营服务器获取该对按钮204的点击操作的响应界面。该响应界面可以对应于：跳转显示该活动指定的购买界面。这样，电子设备就可以显示界面22所示的限定主题的选购界面。
[0072] 以当前活动状态为“领取奖励”为例。如图4所示，在用户点击按钮204的情况下，则电子设备可以从云端(如运营服务器)获取对该点击操作的响应。例如，电子设备可以从运营服务器获取该对按钮204的点击操作的响应。该响应可以对应于：获取当前活动的奖励信息。这样，电子设备就可以从运营服务器获取奖励信息并展示给用户。
[0073] 上述图2到图4仅提供了一种活动的示例。在云端中还可以配置有其他活动，由此使得用户可以获取更加丰富的使用体验。
[0074] 结合图2到图4的示例，电子设备在界面向用户展示活动界面，以及对用户输入操作进行响应时，都需要与云端进行交互。而云端为了支持各个不同的活动，需要分别为各个活动进行配置维护。在完成活动配置后，云端在接收到来自电子设备的用户的操作相关信息时，还需要针对各个活动配置的逻辑，进行对应的逻辑处理以便获取该操作响应的响应并发送给电子设备。一般的，各个活动的维护处理逻辑都是相对独立的。
[0075] 这样，就需要在云端中分别为不同的活动分别进行配置，这也就会造成较大的人力和资源开销。即使活动内容相近，也需要分别进行开发配置，进一步奖励活动配置过程中的效率。在用户输入操作后，针对该操作的活动处理逻辑的独立执行，也会造成云端的算力浪费。
[0076] 为了应对上述问题，本申请实施例提供的技术方案，可以应用于云端中的服务器中。该方案能够为不同的活动提供统一的配置和处理框架。从而实现对不同活动的统一管理和维护。由此使得在需要大量活动配置时，能够获取更加高效的配置和处理效果。基于该处理框架，还能够更加高效地执行对用户输入操作的响应，避免云端的算力浪费。
[0077] 在本申请实施例中，针对相近或类似的活动配置，可以复用已配置的插件实现各自功能。而在需要使用新的配置时，只需要对应开发该新增功能的插件，结合已有其他功能插件，就可以通过本申请实施例提供的方案实现，高效完成新活动的配置和处理。
[0078] 需要说明的是，在本申请实施例中，一个活动可以对应于一个任务。每个任务都可以用于向一个或多个应用提供一项活动服务能力。例如，在云端中配置签到任务的情况下，则该签到任务可以为其他多个应用程序同时提供签到的活动服务能力。
[0079] 在一个任务中，可以对应配置有一个或多个流程。
[0080] 不同流程用于提供该任务的不同部分功能。例如，以图2中的活动1为例。
[0081] 在本申请实施例中，该活动1可以对应包括有多个流程。比如，在电子设备请求显示界面21时，通过该活动1对应任务1中的流程1，实现向电子设备反馈活动1的图像201、活动名称202、积分信息203等界面内容的功能。
[0082] 又如，在电子设备请求显示界面21时，通过该活动1对应任务1中的流程2，根据当前用户行为，确定并向电子设备反馈按钮204以及按钮204中的文字提示信息。
[0083] 又如，在活动状态为“领取奖励”情况下，电子设备接收到用户对按钮204的点击操作时，通过该活动1对应任务1中的流程3，对当前活动状态的判断以及向电子设备推送正确的奖励信息等。
[0084] 本申请实施例提供的方案可以通过配置的数据处理装置中的各个功能模块实现。
[0085] 在一些实施例中，该数据处理装置可以配置在一个服务器(如运营服务器)中。在另一些实施例中，该数据处理装置中的不同功能模块也可配置在不同的服务器中，由此提升海量数据配置、处理和维护过程中的效率。
[0086] 以下说明中，以该数据处理装置配置在一个服务器中为例。
[0087] 参考图5，为本申请实施例提供的一种数据处理装置的组成示意图。
[0088] 如图5所示，该数据处理装置可以包括：配置模块、数据库、条件过滤模块、可配置插件组、规则模块、条件模块、动作模块等。其中，规则模块也可称为规则引擎，条件模块也可称为条件引擎，动作模块也可称为动作引擎。
[0089] 在该如图5所示的数据处理装置中，配置模块可以与可配置插件组、数据库配合，实现新任务和流程的配置。数据库、条件过滤模块、可配置插件组、规则模块、条件模块、动作模块可以互相配合，实现对已配置任务和流程的相关处理。
[0090] 以下分别进行说明。
[0091] 在一些实现中，如图6所示，数据处理装置的配置模块可以耦接有配置设备。该配置设备可以包括显示屏、输入设备等组件。这样，开发人员(如提出活动方案的开发人员)可以通过输入设备以及显示屏，向配置模块输入新的任务和流程的配置。该提出活动方案的开发人员可以为营销人员。
[0092] 在本申请实施例中，数据处理装置的配置模块可以通过配置设备向开发人员提供基于可视化图像界面(UI)的配置方式。在一些实施例中，配置模块可以通过应用程序或网页页面的形式，展示该UI配置界面。例如，配置模块可以在网页页面(如HTML)上嵌入任务配置中心模块，以便于在该网页上展示配置中心模块中的各个配置按钮。配置模块可以在接收到对各个配置按钮的点击、拖动等操作时，根据该配置按钮的功能，以及对应的操作信息，生成任务配置信息。如此重复就可以完成任务配置的实现。
[0093] 这样，即使营销人员不具备软件方面的专业知识，也可以通过该UI的配置方式，快速便捷地实现任务和流程的配置。
[0094] 作为一种示例，参考图7，该可视化图像界面的配置方式可以包括任务信息的配置，以及流程信息的配置。
[0095] 如界面71所示，为任务信息的配置示例。该任务信息也可称为任务基本信息。如界面71所示，在该任务信息配置界面中，可以提供任务名称的配置项以及任务编码的配置项。任务编码也可称为活动编码，或activityCode。
[0096] 可以理解的是，不同任务的任务编码可以不同。一般的，不同任务的任务名称也不同。也可以存在一些任务具有相同的任务名称。
[0097] 在一些实现中，在完成任务名称(如任务T1)的配置后，任务编码可以是由开发人员在该界面71上主动配置的(如配置为T1xxxxxx)。
[0098] 在另一些实现中，在完成任务名称(如任务T1)的配置后，配置模块可以自动生成该任务对应的任务编码，以保证各个任务编码的差异性。例如，配置模块可以在开发人员输入任务名称为“任务T1”后，自动将任务编码填充为“T1xxxxxx”。
[0099] 在完成任务信息的配置后，可以进入具体流程信息的配置。示例性的，在完成界面71上的任务信息配置后，开发人员可以点击界面71上的按钮701，进入流程配置的界面72。
[0100] 在本申请中，每个任务都可以配置有至少一个流程。也就是说，在一些实现中，一个任务可以配置有一个流程；在另一些实现中，一个任务可以配置有多个流程。
[0101] 如界面72所示，在该流程配置的界面72中，可以配置流程基本信息以及具体的流程配置。
[0102] 在本申请实施例中，流程基本信息可以包括以下中的至少一项：流程编码，流程名称，是否需要登录等。例如，流程编码可以配置为“Syyyyyyy”，流程名称可以配置为“流程1”，是否需要登录可以配置为“需要登录”或者“不需登录”。流程编码也可称为ProcessCode。
[0103] 其中，是否需要登录的基本信息可以用于标示当前流程是否需要用户的登录信息才可触发。例如，在是否需要登录的基本信息配置为“需要登录”的情况下，则表示该流程需要用户的登录信息才可进行后续处理判断。如果当前用户尚未登录(例如处于游客状态)，则该流程直接返回失败结果。又如，在是否需要登录的基本信息配置为“不需登录”的情况下，则表示该流程不需要用户的登录信息。那么对应的，无论当前用户是否已经登录，都可以执行该流程的后续判断处理。
[0104] 在本申请实施例中，流程配置可以包括以下三个维度中的至少一个维度的配置项：规则配置、条件配置，以及动作配置。在如图7的示例中，以流程配置包括规则配置1、条件配置1，以及动作配置1为例。
[0105] 其中，规则配置可以用于管理和限制当前流程的可执行次数。条件配置可以用于指示当前流程的其他判断条件。动作配置可以用于指示在满足规则配置以及条件配置的情况下，对应执行的响应。
[0106] 需要说明的是，在本申请实施例中，数据处理装置中可以预先配置有各个维度下的至少一个可用插件。不同插件可以对应于一项集成功能。这样，对于任一个维度的配置，也就可以通过选取该维度提供的插件实现。在一些实现中，各个维度的配置还可以包括其他与已配置插件对应的逻辑配置。
[0107] 作为一种示例，该各个维度的至少一个插件可以存储在数据处理装置的可配置插件组中。
[0108] 参考图8，为一种可配置插件组的示例。如图8所示，该可配置插件组中可以包括规则插件组、条件插件组，以及动作插件组。
[0109] 其中，规则插件组可以包括流程参与次数账户查询插件、公共资格插件、积分插件等插件。由此，在界面72中需要进行规则配置时，只需要选取上述规则插件组中的至少一个已有插件，就可以完成该规则配置。
[0110] 条件插件组可以包括业务查询插件、变量解析插件、响应解析插件等插件。由此，在界面72中需要进行条件配置时，只需要选取上述条件插件组中的至少一个已有插件，就可以完成该条件配置。
[0111] 动作插件组可以包括领取奖励插件、订阅设置插件、数据返回插件等插件。由此，在界面72中需要进行动作配置时，只需要选取上述动作插件组中的至少一个已有插件，就可以完成该动作配置。
[0112] 在本申请的另一些实施例中，与已配置插件对应的逻辑配置可以包括：针对插件返回结果的逻辑判断。例如，条件配置中调用的插件用于返回购买资源数量时，可以配置针对该购买资源数量对应的逻辑判断。比如，购买资源数量！＝‑1时，条件通过(或称为条件判断成功)。由此表示在购买资源数量不等于‑1时，则基于该插件的条件配置通过。可以理解的是，在该示例中，由于条件配置为恒等式，因此该条件配置始终通过。该条件配置的配置可以用于获取购买资源数量，以便于其他模块(如动作配置)中使用。
[0113] 在本申请的另一些实施例中，与已配置插件对应的逻辑配置还可以包括其他逻辑配置。该具体内容将在后续详述。
[0114] 继续参考图7。在完成该规则配置1、条件配置1，以及动作配置1的流程配置后，该界面72中还提供额外的新增按钮702。该按钮702提供了增加新的规则配置、条件配置和/或动作配置的入口。在开发人员需要在当前流程增加新的配置时，可以点击该按钮702，实现其他配置的新增。
[0115] 在完成所有流程配置之后，开发人员可以点击界面上的按钮703，指示保存当前已配置的任务以及流程。
[0116] 这样，如图9所示，数据处理装置的配置模块就可以从配置设备获取在界面71以及界面72上接收到的操作流，由此解析获取该操作流对应配置的任务信息以及流程信息。其中，任务信息可以包括任务名称、任务编码等，流程信息可以包括流程编码、流程名称、规则配置、条件配置、动作配置等。配置模块可以将该任务信息和流程信息发送到数据库中进行存储。
[0117] 可以理解的是，在本申请实施例中，上述基于插件的任务配置实现中，由于各个插件对应于独立的功能模块，并不与任意任务或流程绑定。因此各个插件可以被不同任务和/或流程的配置复用。由此能够在提高任务和流程配置效率的同时，减小对该配置过程的维护成本。此外，由于该插件组合的配置机制，使得该配置过程能够适配到各个不同活动任务的同时，能够提升各个任务和流程配置的规范性。
[0118] 在本申请中，如图9所示，配置模块可以将该任务信息和流程信息存储在数据库中。
[0119] 作为一种示例，同一个流程中的不同维度的信息可以存储在数据库的不同位置。例如，在数据库中可以配置有规则库、条件库以及动作库。不同的库可以用于存储不同维度的配置。
[0120] 配置模块可以将已配置的流程的规则配置，以及该流程和所属任务的编码(如流程编码和任务编码)存储在规则库中。由此，数据处理模块在后续需要使用该规则配置时，就可以通过流程编码以及任务编码，从规则库中获取该规则配置。
[0121] 类似的，配置模块可以将已配置的流程的条件配置，以及流程编码和任务编码存储在条件库中。配置模块可以将已配置的流程的动作配置，以及流程编码和任务编码存储在动作库中。
[0122] 由此，完成配置的各个任务和流程配置都可以存储在数据处理装置的数据库中。
[0123] 作为一种示例，以已完成配置的任务包括签到任务、抽奖任务、下载任务、购买任务等为例。
[0124] 参考图10，在数据处理装置的数据库中就可以分别存储各个任务对应的规则、条件，以及动作配置。
[0125] 例如，签到任务的签到配置可以包括：规则库中的签到规则，条件库中的签到条件，动作库中的签到动作等。
[0126] 在该签到任务中配置有多个流程的情况下，则该签到规则具体可以包括该多个流程分别对应的规则以及流程编码。该签到条件具体可以包括该多个流程分别对应的条件以及流程编码。该签到动作具体可以包括该多个流程分别对应的动作以及流程编码。
[0127] 由此，通过上述图6到图10的示例，就可以完成本申请实施例中，基于规则、条件、动作划分的流程和任务配置。其中，各个维度(如规则、条件或动作)的配置都可以基于插件实现的。
[0128] 结合图5中的说明，在数据库中已经配置存储有任务的情况下，数据处理装置的数据库、条件过滤模块、可配置插件组、规则模块、条件模块、动作模块可以互相配合，实现对已配置任务的相关处理。
[0129] 其中，相关处理可以包括根据来自前端设备(如电子设备或应用服务器)的请求信息，通过各个模块进行逻辑判断和处理，在满足条件的情况下，向前端设备反馈对应流程配置的动作配置。
[0130] 示例性的，参考图11，在一些实施例中，用户在电子设备上输入操作之后，电子设备可以生成操作信息，并将操作信息传输给应用服务器。对应的，应用服务器可以根据接收到的操作信息，生成请求信息，并将请求信息传输给部署在云端(如云端的运营服务器)中的数据处理装置，以便于数据处理装置根据该请求信息，触发预配置任务和任务中流程的判断逻辑。
[0131] 在申请实施例中，该请求信息可以包括用户输入操作相对应的任务编码和流程编码。在一些实施例中，该请求信息还可以包括用户当的登录信息等。其中，在该请求信息中包括用户的登录信息时，该请求信息的发送可以是在用户允许的前提下执行的。在该示例中，应用服务器就可以作为前端设备。
[0132] 对应的，数据处理装置可以根据请求信息，触发对应流程的判断逻辑。具体将在后续详述。
[0133] 需要说明的是，在如图11的示例中，还提供了另一种获取请求信息的方式。例如，电子设备可以直接根据用户的操作，生成请求信息。电子设备可以将请求信息直接传输给数据处理装置。这样，该电子设备就可以作为数据处理装置的前端设备。
[0134] 在本申请的一些实施例中，数据处理装置接收到请求信息之后，可以将请求信息传输给条件过滤模块进行前置判断。
[0135] 本申请实施例中，条件过滤模块可以配置为根据活动状态、活动时间、用户登录态、国家限制、风控校验等基本的活动参与要求判断此次活动请求是否满足参与条件。
[0136] 作为一种可能的实现，参考图12。在本申请中，条件过滤模块可以配置有至少一项过滤功能。比如，该至少一项过滤功能可以包括活动时间过滤、活动状态过滤、登录状态过滤等。
[0137] 其中，活动时间过滤的功能可以对应于：根据当前接收到请求信息携带的任务编码，确定该任务编码对应的任务配置。根据当前时间是否在该任务配置对应的时间段内，执行活动时间过滤。例如，在当前时间在任务配置对应的时间段内时，则活动时间过滤通过。
[0138] 活动状态过滤的功能可以对应于：根据当前接收到请求信息携带的任务编码，确定该任务编码对应的任务配置。根据该任务配置指示的活动状态是否为激活状态，执行活动状态过滤。例如，在任务配置指示的活动状态是为激活状态时，则活动状态过滤通过。
[0139] 登录状态过滤的功能可以对应于：根据当前接收到请求信息携带的任务编码和流程编码，确定需要触发的流程配置。根据该流程配置中的“是否需要登录”的配置，以及请求信息中携带的指示用户登录情况的内容，执行登录状态过滤。例如，该流程配置中的“是否需要登录”配置为“需要登录”，请求信息携带有用户的登录信息，则该登录状态过滤通过；反之，请求信息未携带有用户的登录信息，或者请求信息携带当前用户未登录的指示信息，则该登录状态过滤不通过(失败)。又如，该流程配置中的“是否需要登录”配置为“不需要登录”，则请求信息无论是否携带有用户的登录信息，则该登录状态过滤通过。
[0140] 在本申请的另一些实施例中，条件过滤模块还可以用于判断当前用户的用户账户是否为新开户。在条件过滤模块中可以为新开户或非新开户配置有不同的应对策略。由此，使得条件过滤模块实现对用户账户的管理功能。在一些实现中，该判断逻辑可以集成在登录状态过滤的功能中。
[0141] 在不同实现中，条件过滤模块可以根据当前任务配置的指示，执行各个过滤功能的一个或多个。在所有执行的过滤功能均通过时，则该请求信息可以被传输给其他模块进行后续执行。
[0142] 示例性的，该请求消息可以被传输给规则模块以及其他模块，进行后续判断。
[0143] 作为一种示例，参考图13，请求信息被传输给规则模块后，规则模块可以根据请求信息中携带的任务编码和流程编码，从规则库中获取需要触发的流程的规则配置。
[0144] 规则模块可以执行规则配置中指示的需要调用的插件，执行规则判断。例如，规则模块可以执行规则判断，根据对应流程配置的规则插件组，进一步判断请求信息是否满足参与条件。规则模块还可以根据插件配置，在符合参与条件的情况下，进行活动账户变更、荣耀积分扣减等资格扣减操作。
[0145] 在本申请的一些实施例中，规则模块可以配置有维护用户账户的能力。
[0146] 其中，用户账户可以与用户的登录信息相对应。在数据处理装置接收到不同的登录信息后，可以根据各个登录信息对应的用户账户进行对应的维护和处理。
[0147] 在一些实现中，用户账户可以配置有可参与活动的可用剩余次数。在另一些实现中，用户账户可以配置有用户积分。
[0148] 由此，规则模块可以根据配置的规则配置中调用的插件，修改/控制各个用户账户的可用剩余次数/积分。
[0149] 在规则模块判断通过的情况下，请求信息可以被传输给条件模块，以便于条件模块进行条件判断。
[0150] 示例性的，条件模块可以根据请求信息中携带的任务编码和流程编码，从条件库中获取需要触发的流程的条件配置。
[0151] 在本申请实施例中，条件配置中调用的插件可以包括需要从其他设备/模块获取相关信息的插件。这样，条件模块可以配置为根据对应条件配置的插件组，借助API执行器调用相应业务方接口，并根据响应结果进行对应的逻辑判断，进而确定当前的请求信息是否满足具体的参与场景。
[0152] 在条件模块判断通过的情况下，条件模块可以触发动作模块进行后续处理。
[0153] 示例性的，条件模块可以将请求信息可以被传输给动作模块，以便于动作模块按照已配置的动作配置对前端设备进行响应。
[0154] 在本申请的一些实施例中，动作模块可以根据请求信息中携带的任务编码和流程编码，从动作库中获取需要触发的流程的动作配置。动作模块可以配置为根据对应流程的动作插件组，执行最终的活动表现形式。例如发奖、展示数据、订阅/取消订阅签到提醒、领取任务等。动作模块还可以通过执行该配置的活动表现形式，实现向前端设备的响应。例如，动作模块根据动作配置，向前端设备发送响应信息。
[0155] 上述结合图11到图13对本申请实施例中，数据处理模块根据已配置的任务和流程，在接收到请求信息后的处理逻辑进行了简要说明。以下结合表1到表3，提供一种具体的已配置任务和流程的示例，对接收到请求信息后的处理逻辑进行举例说明。
[0156] 其中，表1到表3可以分别对应于一个流程。如表1对应流程1，表2对应流程2，表3对应流程3。该流程1到流程3可以配置在同一个任务中。例如，该流程1到流程3可以配置在任务1中，该任务1可以与图2所示的活动1相对应。
[0157] 请参考表1，为活动1中的一个流程(如流程1)的配置示例。通过该流程1，数据处理装置就可以在电子设备需要在界面21上显示活动1的图像201、活动名称202等信息时，响应于来自前端设备的请求信息，向前端设备发送对应的信息。
[0158] 作为一种示例，电子设备可以在用户输入显示界面21的操作1(如进入活动界面的操作等)后，向应用服务器发送对应的操作信息1。对应的，应用服务器作为前端设备，可以根据操作信息1生成请求信息1发送给云端的数据处理装置。该示例中，该请求信息1可以携带流程1的流程编码(如init)。
[0159] 表1
[0160]
[0161] 以数据处理装置接收到的请求信息1携带的流程编码包括init为例。
[0162] 结合图11到图13中的说明，条件过滤模块可以根据流程编码为init，获取流程1的流程基本信息。该流程1的流程基本信息中，是否需要登录配置为“无需登录”。这样，条件过滤模块可以执行登录状态过滤，并获得通过的执行结果。在本示例中，以条件过滤模块中仅配置有登录状态过滤为例。
[0163] 由此，条件过滤模块可以将该请求信息1发送给规则模块。
[0164] 规则模块可以根据该请求信息1，获取流程1的规则配置。如表1所示，该流程1的规则配置可以为空。这样，规则模块可以获取执行通过的结果。规则模块可以将该请求信息1发送给条件模块。
[0165] 条件模块可以根据该请求信息1，获取流程1的条件配置。如表1所示，该流程1的条件配置可以为空。这样，条件模块可以获取执行通过的结果。条件模块可以将该请求信息1发送给动作模块。
[0166] 动作模块可以根据该请求信息1，获取流程1的动作配置。如表1所示，流程1的动作配置可以包括：调用返回数据到前端设备插件，向前端设备返回key‑value的数据表。该数据表中，可以包括：“task1Pic‑https//…icon”的对应关系，“task1Name‑购买资源”的对应关系，“task1Target‑5”的对应关系，“task1Desc‑限定主题”的对应关系。
[0167] 这样，动作模块就可以将该表1中的key‑value的数据表携带在响应信息1中，发送给前端设备。由此，前端设备就可以基于该响应信息1，控制电子设备显示界面21上的图像201、活动名称202、积分信息203等信息。
[0168] 本示例中，该活动1还可以配置有其他流程。
[0169] 请参考表2，为活动1中的又一个流程(如流程2)的配置示例。通过该流程2，数据处理装置就可以确定并向前端设备返回按钮204中的文字提示信息。
[0170] 在一些实施例中，请求信息1也可以携带该流程2的流程编码(如taskStatus)。这样，数据处理装置可以根据接收到的该请求信息1，触发流程1以及流程2的处理。
[0171] 表2
[0172]
[0173] 如表2所示，该流程2的名称可以配置为“任务状态信息流程”，流程编码可以配置为“taskStatus”，该流程2的执行需要用户的登录信息。
[0174] 此外，如表2所示，该流程2中的规则配置可以配置为空。这样，在执行该流程2时，不需要进行规则判断，直接继续执行后续的条件配置。
[0175] 在该表2的示例中，该流程2的条件配置可以通过调用流程参与次数账户查询插件实现。具体的，通过调用流程参与次数账户查询插件，可以获取流程编码为getReward的流程参与次数账户情况，并在流程参与次数上限！＝‑1时，该条件1通过。
[0176] 在条件1通过的情况下，可以继续配置为进行条件2的判断。例如，通过调用流程参与次数账户查询插件，可以查询用户指定时间段的购买资源数量。在该过程中，输入到该插件的入参可以包括：开始时间{TODAYSTARTTIME}，结束时间{TODAYENDTIME}。由此获取该时间段内的购买资源数量作为返回值。该条件2可以配置为购买资源数量！＝‑1时，该条件2通过。
[0177] 由此，通过该流程2的条件配置的执行，就可以获取流程参与次数上限以及购买资源数量。
[0178] 基于该流程2的条件配置，由于条件1和条件2均为恒等式，因此在完成条件配置的执行后，可以触发动作配置的执行。
[0179] 示例性的，基于该表2所示的动作配置，数据处理装置可以向前端设备反馈包括“loadTimes‑条件2购买资源数量”的对应关系，以及“completed‑条件1流程参与次数上限”的对应关系。该对应关系也可以是由key‑value的形式传递给前端设备的。
[0180] 在一些实施例中，数据处理模块向前端设备传递该表2中配置的key‑value时，还可以携带有该key‑value的解析方式。例如，loadTimes<5时，对应在按钮204中的文字提示信息显示为“去完成”。loadTimes>5且completed<1时，对应在按钮204中的文字提示信息显示为“领取奖励”。completed>1时，对应在按钮204中的文字提示信息显示为“已完成”。
[0181] 在另一些实施例中，上述对key‑value的解析方式也可以是与前端设备预先协商并存储在前端设备中的。这样，前端设备就可以在接收到该表2中配置的key‑value后，根据其中携带的上述两个对应关系确定需要控制电子设备显示的文字提示信息的内容。
[0182] 在本示例中，该活动1还可以配置有流程3。该流程3可以用于识别当前用户是否具有奖励信息的领取资格，并在有领取资格时，向用户(如用户的电子设备)配发相应的奖励信息。
[0183] 示例性的，在界面21上的按钮204中的文字提示信息显示为“领取奖励”的情况下，用户输入操作2(如对该按钮204的点击操作)后，电子设备可以生成操作信息2。操作信息2可以包括指示点击“领取奖励”的信息。电子设备可以将该操作信息2发送给应用服务器。对应的，应用服务器可以根据该操作信息2生成请求信息2。在请求信息2中可以携带流程3的流程编码(如getReward)。由此，数据处理装置可以根据该请求信息2，触发执行流程3。
[0184] 作为一种示例，该流程3的流程配置如下表3所示。
[0185] 表3
[0186]
[0187] 如表3所示，该流程3的名称可以配置为“领取奖励流程”，流程编码可以配置为“getReward”，该流程3的执行需要用户的登录信息。
[0188] 如表3所示，该流程3中的规则配置可以配置为：调用流程参与次数账户查询插件。本示例中，该规则配置还可以包括：条件满足时，赠送1次流程参与机会，每次执行后，扣除1次机会。其中，条件可以为预配置的条件。规则模块可以根据请求信息2携带的信息(如用户的登录信息等)，确定是否满足该预配置的条件。
[0189] 例如，该与配置的条件可以包括：当前登录信息指示的用户账户是新建账户。那么对应的，规则模块可以根据当前登录信息是否为新建账户，触发对应的配置：赠送1次流程参与机会，每次执行后，扣除1次机会。
[0190] 在本示例中，规则模块可以在当前流程参与机会大于0的情况下，确定执行通过，并将请求信息2传输给条件模块进行后续处理。
[0191] 条件模块可以根据请求信息2携带的流程编码，获取该流程3对应的条件配置。
[0192] 如表3所示，该条件配置可以包括：查询用户指定时间段的购买资源数量。对应的，条件模块可以将开始时间{TODAYSTARTTIME}，结束时间{TODAYENDTIME}作为接口参数，输入到调用的流程参与次数账户查询插件中，由此确定该时间段内的购买资源数量。
[0193] 进一步的，条件模块可以根据该购买资源数量，是否大于或等于5，确定当前条件判断是否通过。本示例中，以条件配置通过为例。
[0194] 由此，条件模块就可以将请求信息2传输给动作模块。
[0195] 动作模块可以根据请求信息2获取流程3的动作配置。如表3所示，该流程3的动作配置可以包括：调用领取奖励插件。该动作配置还可以包括：礼包单编码：FQWF12D13141、礼包组编码：group1、礼包编码：task1、领取数量：1。这样，动作模块就可以生成响应信息2，该响应信息2中可以包括礼包单编码：FQWF12D13141、礼包组编码：group1、礼包编码：task1、领取数量：1等内容。动作模块可以将该响应信息2传输给前端设备，由此实现对请求信息2的响应。
[0196] 可以理解的是，前端设备(如应用服务器)在接收到该响应信息2之后，可以根据响应信息2中携带的奖励信息(如礼包单编码：FQWF12D13141、礼包组编码：group1、礼包编码：task1、领取数量：1)，向当前用户(如操作信息2对应的电子设备)推送该对应的奖励信息。
[0197] 由此，通过上述表1到表3的任务和流程配置示例，以及基于该流程配置的处理机制说明，本领域技术人员应当能够理解本申请中，数据处理装置根据已配置的任务和流程配置，以及请求信息，通过规则、条件以及动作等模块的配合处理，实现对应任务和流程的处理以及响应。
[0198] 与上述示例相对应的，在数据库中存储有其他任务和/或流程的配置时，数据处理装置也可以通过类似的处理机制，快速实现对前端设备的响应。可以理解的是，基于该模块化的处理机制，使得数据处理装置可以实现对不同场景不同类型的任务/流程的响应。由此避免为不同任务分别配置处理逻辑情况下，在执行各个任务时的额外开销。
[0199] 上述示例中，提供了本申请实施例提供的一种数据处理方法的实现示例。
[0200] 在本申请的另一些实施例中，数据处理装置中的各个模块还可以结合用户的账户的资格配置，实现更加准确的任务处理和响应。
[0201] 作为一种示例，请参考图14，为本申请实施例提供的又一种数据处理方法的模块间交互的流程示意图。
[0202] 如图14所示，该方法可以包括：
[0203] S1401、条件过滤模块根据接收到的请求信息，进行条件过滤处理。
[0204] 示例性的，该请求信息可以为前述示例中的请求信息1、请求信息2等。在本示例中，该请求信息可以包括用户的登录信息、流程编码，以及任务编码等信息。
[0205] 该步骤的执行可以参考前述图12中的示例，具体不再赘述。
[0206] 如图14所示，在过滤成功的情况下，则执行S1402。
[0207] 反之，在过滤失败的情况下，则生成失败信息1。该失败信息1可以包括指示过滤失败的原因值。条件过滤模块还可以根据该失败信息1，生成失败响应。在该失败响应中可以携带失败信息1，对应表示失败原因是过滤失败。
[0208] 在本申请中，数据处理装置可以在生成失败响应之后，将该失败响应发送给前端设备。
[0209] S1402、条件过滤模块向规则模块发送请求信息。
[0210] S1403、规则模块检测用户账户状态。
[0211] 在本示例中，规则模块可以维护不同用户的登录信息对应的用户账户。
[0212] 该用户账户可以配置有可参加活动的剩余次数(或称为可用剩余次数)，以及与用户的登录信息相对应的积分信息。
[0213] 示例性的，规则模块可以根据接收到的请求信息中携带的用户的登录信息，确定该用户对应的用户账户。
[0214] 规则模块还可以检测该用户账户的可参加活动的剩余次数是否为0，以便进行后续不同的判断逻辑。
[0215] 例如，在该用户账户的剩余次数是0时，则对应没有剩余资格。那么规则模块可以生成失败信息2。该失败信息2中可以包括指示剩余次数为0的失败原因值。规则模块可以将该失败信息2发送给条件过滤模块。对应的，条件过滤模块可以根据接收到失败信息2，生成失败响应。在该失败响应中可以携带失败信息2，对应表示失败原因是剩余次数为0。
[0216] 又如，在该用户账户的剩余次数大于0时，则对应有剩余资格。那么规则模块可以执行以下S1404。
[0217] S1404、规则模块执行对当前账户的剩余次数‑1的处理。
[0218] 由此，规则模块通过该S1404的处理，将当前账户中的可用剩余次数进行对应的扣除，保证规则模块维护的用户账户中可用剩余次数的准确性。
[0219] S1405、规则模块判断次数是否扣除成功。
[0220] 在扣除成功的情况下，则执行以下S1406。对应的，在扣除失败的情况下，则规则模块生成失败信息3，该失败信息3可以携带指示可用剩余次数扣除失败对应的原因值。进一步的，条件过滤模块可以根据该失败信息3，生成失败响应。在该失败响应中可以包括失败信息3指示的原因值。
[0221] S1406、规则模块执行对当前账户的积分扣除的处理。
[0222] 由此，规则模块通过该S1406的处理，将当前账户中的积分进行对应的扣除，保证规则模块维护的用户账户中积分的准确性。
[0223] S1407、规则模块判断积分是否扣除成功。
[0224] 在积分扣除成功的情况下，表示针对当前请求信息的规则判断通过。对应的，规则模块可以执行以下S1408。
[0225] 对应的，在积分扣除失败的情况下，则规则模块生成失败信息4，该失败信息4可以携带指示积分扣除失败对应的原因值。进一步的，条件过滤模块可以根据该失败信息4，生成失败响应。在该失败响应中可以包括失败信息4指示的原因值。
[0226] 需要说明的是，在本申请实施例中，在可用剩余次数或者积分扣除失败的情况下，规则模块可以按照上述示例生成对应的失败信息以及失败响应。规则模块还可以将该生成的失败响应传输给前端模块，完成对接收到请求信息的响应。此外，规则模块还可以在可用剩余次数或者积分扣除失败的情况下，对已经扣除的可用剩余次数或积分进行回滚处理。
[0227] 示例性的，以可用剩余次数扣除成功，积分扣除失败为例。这样，规则模块可以针对已经扣除成功的可用剩余次数进行回滚处理。例如，规则模块可以对当前账户的可用剩余次数执行+1的处理。由此使得在当前请求信息无法成功参与当前活动的情况下，保证当前账户的可用剩余次数的准确性。
[0228] 在本申请实施例中，在规则模块通过上述S1403‑S1407的执行，获得规则模块判断通过的结果后，数据处理装置还可以根据当前账户(即请求信息中携带的登录信息指示的在规则模块中维护的用户账户)的状态信息，选择性执行后续的条件判断。
[0229] 示例性的，该当前账户的状态信息可以包括：新开户，非新开户。对于新开户的当前账户，数据处理装置可以配置为：跳过条件判断，直接进行后续动作配置。这样，可以有效增加新开户的用户粘性。对应的，对于非新开户的状态信息，数据处理装置可以配置为：根据预设的规则，确定是否触发执行条件判断。例如，该预设的规则可以配置为：针对所有非新开户，均触发执行条件判断。
[0230] 在该如图14的示例中，该对当前账户的状态信息的判断机制可以由条件过滤模块执行。示例性的，该过程可以包括：
[0231] S1408、条件过滤模块判断是否新开户。
[0232] 示例性的，规则模块可以在执行S1407，并且确定积分扣除成功后，向条件过滤模块发送相关信息，以便指示条件过滤模块当前账户的规则判断通过。
[0233] 在一些实施例中，规则模块可以向条件过滤模块发送请求信息。对应的，条件过滤模块可以根据接收到请求信息，确定当前账户的规则判断通过。
[0234] 在另一些实施例中，规则模块可以向条件过滤模块发送指示规则判断通过的信息。对应的，条件过滤模块可以根据接收到该信息，确定当前账户的规则判断通过。
[0235] 由此，在条件过滤模块确定当前账户的规则判断通过的情况下，可以触发该S1408的执行。
[0236] 在本示例中，在当前账户为新开户的情况下，直接执行动作配置。例如，跳转执行S1411。
[0237] 对应的，在当前账户为非开户的情况下，则执行S1409。
[0238] S1409、条件过滤模块判断是否需要再次执行条件判断。
[0239] 示例性的，在条件过滤模块中可以配置有预设的规则，该预设的规则可以指示是否对非新开户进行条件判断。
[0240] 这样，条件过滤模块可以根据该预设的规则，确定针对当前账户是否需要再次执行条件判断。
[0241] 在需要再次针对当前账户执行条件判断的情况下，则条件过滤模块可以向动作模块发送请求信息，以及再次执行标识，以便于动作模块执行S1410。
[0242] 在不需要再次针对当前账户执行条件判断的情况下，则条件过滤模块可以向动作模块发送请求信息，以便于动作模块根据请求信息，针对当前账户执行动作配置，如执行S1411。
[0243] S1410、条件模块根据请求信息和再次执行标识，执行条件判断。
[0244] 示例性的，条件模块可以根据接收到的再次执行标识，执行对应的条件判断。
[0245] 在本申请实施例中，条件模块可以配置为针对不同的标识，触发不同的条件判断策略。
[0246] 例如，该不同的标识为该S1410中对应的再次执行标识的情况下，则该条件判断策略可以包括：只要任一个条件判断通过，则此次条件模块的条件判断通过。这样，在该流程对应配置的条件配置中包括多个条件判断时，只需要有任一个条件判断成功，则该条件模块对应的条件判断通过。
[0247] 在本申请的另一些实施例中，该不同的标识也可以为：开户标识。该开户标识对应于请求信息中携带的登录信息，在规则模块中尚未开户。这样，通过该条件判断，就可以识别是否对当前用户进行开户。
[0248] 针对该标识为开户标识的情况下，该条件判断策略可以包括：在满足所有条件判断的情况下，则对应条件判断通过。反之，若存在至少一个条件判断失败的情况下，针对当前账户的条件判断失败。
[0249] 在本示例中，如S1409中的说明，以条件模块接收到再次执行标识为例。
[0250] 这样，条件模块就可以根据接收到的请求信息中携带的任务编码和流程编码，从条件库中获取对应的条件配置。
[0251] 条件模块可以执行条件配置中的每个条件判断，在所有条件判断均通过的情况下，则针对该条件配置的条件判断成功。对应的，条件模块可以向动作模块发送请求信息，以便于动作模块执行S1411。
[0252] 反之，在条件配置中，存在至少一个条件判断失败，则针对该条件配置的条件判断失败。对应的，条件模块可以生成失败信息5，该失败信息5可以携带指示条件判断失败的原因值。条件模块可以将该失败信息5发送给条件过滤模块，以便于条件过滤模块根据该失败信息5，生成失败响应。在该失败响应中可以包括失败信息5指示的原因值。
[0253] S1411、动作模块根据请求信息，执行动作配置。
[0254] 示例性的，动作模块可以根据请求信息中携带的任务编码和流程编码，从动作库中获取对应的动作配置。
[0255] 在一些实施例中，动作模块还可以从条件模块中获取动作配置所需的数据信息。例如，动作模块可以从条件模块获取购买资源数量等信息。
[0256] 由此，动作模块可以根据动作配置，生成响应信息，进而将该响应信息发送给前端设备。由此完成对前端设备发出请求信息的响应。
[0257] 在如图14的S1403以及后续示例中，提供了当前用户已经存在的情况下，有可用剩余次数/没有可用剩余次数的处理机制。
[0258] 在另一些实施例中，在规则模块执行S1403时，请求信息中指示的登录信息在规则模块中尚未开户。这样，参考图15，本申请实施例还提供该场景下的对应处理机制。
[0259] 如图15所示，在如图14的基础上，在执行S1401‑S1403后，规则模块可以检查用户账户状态。由此触发S1501，如确定账户状态为未开户。这样，规则模块以及条件模块可以通过后续S1502‑S1505，实现对该未开户情况下的应对逻辑。
[0260] 可以理解的是，在如图15的示例中，若S1403中检查用户账户状态的结果为已开户，并且没有可用剩余次数/有可用剩余次数，则可以按照如图14中的S1404‑S1411执行对前端设备的响应。
[0261] 如图15所示，在该未开户场景下，该方案还可以包括：
[0262] S1502、规则模块向条件模块发送开户标识以及请求信息。
[0263] 其中，开户标识表示当前用户尚未开户。这样，条件模块可以根据请求信息以及开户标识，执行S1503，由此确定是否可以为当前用户开户。
[0264] S1503、条件模块根据开户标识和请求信息，执行条件判断。
[0265] 示例性的，结合S1410中的说明，在本示例中，条件模块可以根据开户标识，确定采用如下条件判断策略：在满足所有条件判断的情况下，则对应条件判断通过。反之，若存在至少一个条件判断失败的情况下，针对当前账户的条件判断失败。
[0266] 作为一种示例，条件模块可以根据请求信息携带的任务编码和流程编码，从条件库中获取对应的条件配置。
[0267] 条件模块可以在所有的条件判断均通过的情况下，确定当前条件配置的判断通过。
[0268] 对应的，可以执行以下S1504。
[0269] S1504、条件模块向规则模块发送开户指示。
[0270] 在本申请中，条件模块可以在确定当前用户的条件配置的判断通过时，表示当前用户可以开户，则执行该S1504，指示规则模块进行开户。
[0271] S1505、规则模块根据接收到的开户指示，对当前用户进行开户处理。
[0272] 由此，规则模块就可以对该请求信息中的登录信息，建立对应的用户账户。
[0273] 在本申请中，规则模块可以执行该S1505后，重新执行S1403。例如，规则模块可以根据新开户的用户账户进行检查用户账户状态的处理。由此触发S1404‑S1411中的处理机制。
[0274] 可以理解的是，在该如图15的示例中，由于该用户账户为新开账户，因此在所有规则判断均通过的情况下，执行S1408时，判断结果可以为新开户。由此跳转执行S1411，直接为当前用户配置响应的奖励信息。
[0275] 由此，就可以通过数据处理装置，实现对请求信息的准确和快速响应。可以理解的是，该如图14以及图15的方案实现，可以配合前述示例中的基于插件的配置过程，对不同场景下复杂的活动进行有效支持。
[0276] 需要说明的，本申请实施例中涉及的用户的电子设备可以包括手机、可折叠电子设备、平板电脑、桌面型计算机、膝上型计算机、手持计算机、笔记本电脑、超级移动个人计算机(ultra‑mobile personal computer，UMPC)、上网本、蜂窝电话、个人数字助理(personal digital assistant，PDA)、增强现实(augmented reality，AR)设备、虚拟现实(virtual reality，VR)设备、人工智能(artificial intelligence,AI)设备、可穿戴式设备、车载设备、智能家居设备、或智慧城市设备中的至少一种。本申请实施例对该电子设备的具体类型不作特殊限制。
[0277] 可以理解的是，本申请实施例提供的相关设备为了实现上述功能，其包含了执行各个功能相应的硬件结构和/或软件模块。本领域技术人员应该很容易意识到，结合本文中所公开的实施例描述的各示例的单元及算法步骤，本申请实施例能够以硬件或硬件和计算机软件的结合形式来实现。某个功能究竟以硬件还是计算机软件驱动硬件的方式来执行，取决于技术方案的特定应用和设计约束条件。专业技术人员可以对每个特定的应用来使用不同方法来实现所描述的功能，但是这种实现不应认为超出本申请实施例的范围。
[0278] 本申请实施例可以根据上述方法示例对上述相关设备进行功能模块的划分，例如，可以对应各个功能划分各个功能模块，也可以将两个或两个以上的功能集成在一个处理模块中。上述集成的模块既可以采用硬件的形式实现，也可以采用软件功能模块的形式实现。需要说明的是，本申请实施例中对模块的划分是示意性的，仅仅为一种逻辑功能划分，实际实现时可以有另外的划分方式。
[0279] 上述主要从各个功能模块的角度对本申请实施例提供的方案进行了介绍。本领域技术人员应该很容易意识到，结合本文中所公开的实施例描述的各示例的单元及算法步骤，本申请能够以硬件或硬件和计算机软件的结合形式来实现。某个功能究竟以硬件还是计算机软件驱动硬件的方式来执行，取决于技术方案的特定应用和设计约束条件。专业技术人员可以对每个特定的应用来使用不同方法来实现所描述的功能，但是这种实现不应认为超出本申请的范围。
[0280] 上述集成的模块既可以采用硬件的形式实现，也可以采用软件功能模块的形式实现。需要说明的是，本申请实施例中对模块的划分是示意性的，仅仅为一种逻辑功能划分，实际实现时可以有另外的划分方式。
[0281] 示例性的，图16示出了的一种服务器设备1600的组成示意图。如图16所示，该服务器设备1600可以包括：处理器1601和存储器1602。该存储器1602用于存储计算机执行指令。示例性的，在一些实施例中，当该服务器设备1601执行该存储器1602存储的指令时，可以使得该服务器设备1600执行上述实施例中任一种所示的方法。例如，该服务器设备1600可以包括上述实施例中提供的数据处理装置。在一些实现中，该服务设备1600可以为运营服务器。
[0282] 需要说明的是，上述方法实施例涉及的各步骤的所有相关内容均可以援引到对应功能模块的功能描述，在此不再赘述。
[0283] 图17示出了的一种芯片系统1700的组成示意图。该芯片系统1700可以包括：处理器1701和通信接口1702，用于支持相关设备实现上述实施例中所涉及的功能。在一种可能的设计中，芯片系统还包括存储器，用于保存相关设备(如上述服务器设备或者数据处理装置)必要的程序指令和数据。该芯片系统，可以由芯片构成，也可以包含芯片和其他分立器件。需要说明的是，在本申请的一些实现方式中，该通信接口1702也可称为接口电路。
[0284] 需要说明的是，上述方法实施例涉及的各步骤的所有相关内容均可以援引到对应功能模块的功能描述，在此不再赘述。
[0285] 在上述实施例中的功能或动作或操作或步骤等，可以全部或部分地通过软件、硬件、固件或者其任意组合来实现。当使用软件程序实现时，可以全部或部分地以计算机程序产品的形式来实现。该计算机程序产品包括一个或多个计算机指令。在计算机上加载和执行计算机程序指令时，全部或部分地产生按照本申请实施例所述的流程或功能。所述计算机可以是通用计算机、专用计算机、计算机网络、或者其他可编程装置。所述计算机指令可以存储在计算机可读存储介质中，或者从一个计算机可读存储介质向另一个计算机可读存储介质传输，例如，所述计算机指令可以从一个网站站点、计算机、服务器或者数据中心通过有线(例如同轴电缆、光纤、数字用户线(digital subscriber line，DSL))或无线(例如红外、无线、微波等)方式向另一个网站站点、计算机、服务器或数据中心进行传输。所述计算机可读存储介质可以是计算机能够存取的任何可用介质或者是包括一个或多个可以用介质集成的服务器、数据中心等数据存储设备。所述可用介质可以是磁性介质(例如，软盘、硬盘、磁带)，光介质(例如，DVD)、或者半导体介质(例如固态硬盘(solid state disk，SSD))等。
[0286] 尽管结合具体特征及其实施例对本申请进行了描述，显而易见的，在不脱离本申请的精神和范围的情况下，可对其进行各种修改和组合。相应地，本说明书和附图仅仅是所附权利要求所界定的本申请的示例性说明，且视为已覆盖本申请范围内的任意和所有修改、变化、组合或等同物。显然，本领域的技术人员可以对本申请进行各种改动和变型而不脱离本申请的精神和范围。这样，倘若本申请的这些修改和变型属于本申请权利要求及其等同技术的范围之内，则本申请也意图包括这些改动和变型在内。
