CN106708476B - 一种单机应用指令处理方法及装置 - Google Patents

Abstract

本申请公开了一种单机应用指令处理方法及装置，方法包括：接收终端上的单机应用发送的携带有终端标识及用户请求对象的状态值的指令；查询预置的发送渠道推荐规则，确定与指令匹配的目标发送渠道；利用目标发送渠道将指令作为一条订单信息发往与目标发送渠道对应的第三方服务器，并向单机应用发送通知，以使单机应用向用户发放所请求的对象。本申请支持指令的多渠道发送，并且各个发送渠道均规定了所发送指令的相关信息，以短信发送渠道为例，可以设定携带某些终端标识的指令不允许发送，如已知的某些刷单终端的标识，还可以设定携带的用户请求对象的状态值超过预设值的指令不允许发送等，通过这种设置，防止了用户使用短信持续刷单的问题。

Description

一种单机应用指令处理方法及装置

技术领域

本申请涉及数据处理技术领域，更具体地说，涉及一种单机应用指令处理方法及装置。

背景技术

随着智能终端的发展，越来越多的厂商进入应用研发领域。应用可以分为联网应用和单机应用，二者的区别在于单机应用不需要终端联网，即可供用户使用。常见的单机应用如单机小游戏等。

在单机应用的场景中，用户若要得到应用提供的某些对象，则需要利用与单机应用集成的应用处理程序包，以短信形式向第三方服务器发送对象获取指令，由第三方服务器根据指令，从用户的账户余额中扣除相应金额，并同应用供应商进行收入分成。同时，应用处理程序在检测到短信发送成功后，即通知单机应用下发用户指定的对象。这里，第三方服务器一般为电信运营商。以用户购买应用提供的道具为例，假设应用提供的道具价值一元，则用户点击购买后，由应用处理程序包向电信运营商发送短信，并在短信发送成功后通知应用下发道具。电信运营商收到短信后从用户账户余额中扣除部分金额，扣除的部分金额由电信运营商和应用供应商共享。

但是，发明人研究发现，现有技术仅仅支持单机应用指令的短信发送渠道，且现有的短信发送方式存在缺陷：由于应用处理程序包是以短信是否成功发送作为通知单机应用下发对象的条件，当用户的账户余额不足但是短信套餐充足的情况下，用户可以不断的通过发送短信来进行刷单，损害单机应用供应商的利益。

发明内容

有鉴于此，本申请提供了一种单机应用指令处理方法及装置，用于解决现有技术仅支持单机应用指令的短信发送方式，且容易被用户刷单，损害单机应用提供商利益的问题。

为了实现上述目的，现提出的方案如下：

一种单机应用指令处理方法，包括：

接收终端上的单机应用发送的携带有终端标识及用户请求对象的状态值的指令；

查询预置的发送渠道推荐规则，确定与所述指令匹配的目标发送渠道，所述发送渠道推荐规则规定了不同类型的发送渠道对指令携带的终端标识及用户请求对象的状态值的要求；

利用所述目标发送渠道，将所述指令作为一条订单信息发往与该目标发送渠道对应的第三方服务器，以供所述第三方服务器操作所述订单信息；

向所述单机应用发送通知信息，以使所述单机应用向所述用户发放所请求的对象。

一种单机应用指令处理装置，包括：

指令接收单元，用于接收终端上的单机应用发送的携带有终端标识及用户请求对象的状态值的指令；

发送渠道匹配单元，用于查询预置的发送渠道推荐规则，确定与所述指令匹配的目标发送渠道，所述发送渠道推荐规则规定了不同类型的发送渠道对指令携带的终端标识及用户请求对象的状态值的要求；

订单信息发送单元，用于利用所述目标发送渠道，将所述指令作为一条订单信息发往与该目标发送渠道对应的第三方服务器，以供所述第三方服务器操作所述订单信息；

应用通知单元，用于向所述单机应用发送通知信息，以使所述单机应用向所述用户发放所请求的对象。

从上述的技术方案可以看出，本申请实施例提供的单机应用指令处理方法，接收终端上的单机应用发送的携带有终端标识及用户请求对象的状态值的指令，然后查询预置的发送渠道推荐规则，确定与所述指令匹配的目标发送渠道，这里发送渠道推荐规则规定了不同类型的发送渠道对指令携带的终端标识及用户请求对象的状态值的要求，也即可以根据指令选择指令所匹配的目标发送渠道，进而利用所述目标发送渠道，将所述指令作为一条订单信息发往与该目标发送渠道对应的第三方服务器，并向单机应用发送通知信息，以使单机应用向用户发放所请求的对象。本申请支持指令的多种发送渠道，并且各个发送渠道均规定了所发送指令的相关信息，以短信发送渠道为例，可以设定携带某些终端标识的指令不允许发送，如已知的某些刷单终端的标识，还可以设定携带的用户请求对象的状态值超过预设值的指令不允许发送等，通过这种设置，防止了用户使用短信持续刷单的问题，保护了单机应用提供商的利益。

附图说明

为了更清楚地说明本申请实施例或现有技术中的技术方案，下面将对实施例或现有技术描述中所需要使用的附图作简单地介绍，显而易见地，下面描述中的附图仅仅是本申请的实施例，对于本领域普通技术人员来讲，在不付出创造性劳动的前提下，还可以根据提供的附图获得其他的附图。

图1为本申请实施例公开的一种单机应用指令处理方法流程图；

图2为本申请实施例公开的另一种单机应用指令处理方法流程图；

图3为本申请实施例公开的又一种单机应用指令处理方法流程图；

图4为本申请实施例公开的一种确定目标发送渠道的方法流程图；

图5为本申请实施例公开的又一种单机应用指令处理方法流程图；

图6为本申请实施例公开的一种单机应用指令处理装置结构示意图；

图7为本申请实施例公开的一种终端硬件结构示意图。

具体实施方式

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

本申请实施例提供的单机应用指令处理方法，应用于应用处理程序包，该应用处理程序包可以和单机应用相互集成，共同安装在终端上。这里，终端一般为手机，除此之外还可以是其它支持短信功能的终端。接下来，我们从应用处理程序包侧对本申请方案进行介绍，参见图1，图1为本申请实施例公开的一种单机应用指令处理方法流程图。

如图1所示，该方法包括：

步骤S100、接收终端上的单机应用发送的携带有终端标识及用户请求对象的状态值的指令；

用户对终端上的单机应用进行操作，请求获取应用提供的某个对象。而在应用中，各个对象均具有对应的状态值，状态值可以看作对象在应用中的某种属性，举例如，游戏应用中提供的各种道具即可看作对象，而道具的价值即可以道具的状态值。

本申请的应用处理程序包接收应用发送的指令，进而根据指令执行后续动作。

步骤S110、查询预置的发送渠道推荐规则，确定与所述指令匹配的目标发送渠道；

其中，所述发送渠道推荐规则规定了不同类型的发送渠道对指令携带的终端标识及用户请求对象的状态值的要求。

本实施例中，应用处理程序包支持多种类型的发送渠道，举例如短信发送渠道、网络发送渠道等。发送渠道具体用于执行下述步骤S120的动作。对于各个类型的发送渠道，均规定了对指令携带的终端标识及用户请求对象的状态值的要求。举例如，短信发送渠道所发送的指令中用户请求对象的状态值不能超过额定阈值，或者在限定时间内，携带同一终端标识的各个指令中的用户请求对象的状态值的和值不能够超过额定阈值等等。

由于不同的发送渠道对所发送的指令提出了不同要求，本实施例中应用处理程序包可以根据指令的具体内容，选择匹配的发送渠道，例如对涉嫌刷单的指令，可以选择指令要求比较严格的发送渠道，举例如，若发现游戏单机应用中同一终端在一定时间范围内发送的道具获取指令次数超过阈值，因此认定该终端可能存在刷单的嫌疑，为了保证游戏单机应用提供商的利益，可以选择网络发送渠道，将指令发送给对应的网银服务器，由网银服务器实时扣费。由于网络发送渠道相对短信发送渠道而言，指令发送失败的概率较低，更加可靠，能够避免用户在账户余额不足而短信套餐充足的情况下进行刷单的情。

步骤S120、利用所述目标发送渠道，将所述指令作为一条订单信息发往与该目标发送渠道对应的第三方服务器；

对于各个发送渠道，其均对应设置有第三方服务器，举例如，短信发送渠道对应的为电信运营商服务器，网络发送渠道对应的为网银服务器等。本实施例中可以选择创建订单信息，该订单信息业携带有终端标识及用户请求对象的状态值，同时订单信息还标识有订单号。通过向第三方服务器发送订单信息，可以供第三方服务器操作订单信息。

步骤S130、向所述单机应用发送通知信息，以使所述单机应用向所述用户发放所请求的对象。

在发送完毕订单信息后可以向单机应用发送通知信息，通知其向用户发放请求对象。

本申请实施例提供的单机应用指令处理方法，接收终端上的单机应用发送的携带有终端标识及用户请求对象的状态值的指令，然后查询预置的发送渠道推荐规则，确定与所述指令匹配的目标发送渠道，这里发送渠道推荐规则规定了不同类型的发送渠道对指令携带的终端标识及用户请求对象的状态值的要求，也即可以根据指令选择指令所匹配的目标发送渠道，进而利用所述目标发送渠道，将所述指令作为一条订单信息发往与该目标发送渠道对应的第三方服务器，并向单机应用发送通知信息，以使单机应用向用户发放所请求的对象。本申请支持指令的多种发送渠道，并且各个发送渠道均规定了所发送指令的相关信息，以短信发送渠道为例，可以设定携带某些终端标识的指令不允许发送，如已知的某些刷单终端的标识，还可以设定携带的用户请求对象的状态值超过预设值的指令不允许发送等，通过这种设置，防止了用户持续刷单的问题，保护了单机应用提供商的利益。

可选的，上述步骤S130的过程可以是在确定目标发送渠道发送订单信息成功后执行。而若确定目标发送渠道发送订单信息失败时，可以选择其它发送渠道，重新向对应的第三方服务器发送订单信息，直至确定发送成功后再执行步骤S130。

本实施例以单机应用为单机游戏为例，对本申请方案进行介绍。

用户在单机游戏环境中选择购买某个游戏道具，该游戏道具价值1圆人民币。则当用户点击购买后，单机游戏向本申请的应用处理程序包发送指令，指令中携带有终端标识及用户购买的游戏道具的价值。应用处理程序包接收指令后，查询预置的各类发送渠道的推荐规则，确定终端标识及游戏道具价值均满足短信发送渠道的要求，因此选择短信发送渠道作为目标发送渠道。进一步，将指令作为一条订单信息发往目标发送渠道对应的电信运营商服务器，由电信运营商服务器实施扣费操作。应用处理程序包同时向单机游戏发送通知信息，通知单机游戏向用户发放游戏道具。

在本申请另一个实施例中，假设发送渠道包括短信发送渠道和网络发送渠道。为了便于理解下文，首先对短信发送渠道和网络发送渠道进行介绍。短信发送渠道即通过向电信运营商发送短信的形式发送指令。短信发送渠道比较简捷，但是，若用户账户余额不足而短信套餐充足，则可以通过短信渠道的形式不断的刷单，损害应用提供商的利益。而网络发送渠道，其需要用户提供网银账号等信息，用户操作比较复杂，但是，网络发送渠道不存在用户刷单的可能，能够保护应用提供商的利益。

参见图2，图2为本申请实施例公开的另一种单机应用指令处理方法流程图。

如图2所示，该方法包括：

步骤S200、接收终端上的单机应用发送的携带有终端标识及用户请求对象的状态值的指令；

用户对终端上的单机应用进行操作，请求获取应用提供的某个对象。而在应用中，各个对象均具有对应的状态值，状态值可以看作对象在应用中的某种属性，举例如，游戏应用中提供的各种道具即可看作对象，而道具的价值即可以道具的状态值。

步骤S210、判断指令携带的所述终端标识是否在本地预置的黑名单中，若是，则执行步骤S220，若否，则执行步骤S230；

步骤S220、将所述网络发送渠道确定为与所述指令匹配的目标发送渠道；

步骤S230、判断当前时间之前的预置历史时间段内，携带有同一终端标识的指令中，用户请求对象的状态值的和值是否超过阈值，若是，则执行步骤S220，若否，则执行步骤S240；

步骤S240、将所述短信发送渠道确定为与所述指令匹配的目标发送渠道；

步骤S250、利用所述目标发送渠道，将所述指令作为一条订单信息发往与该目标发送渠道对应的第三方服务器；

对于各个发送渠道，其均对应设置有第三方服务器，如短信发送渠道对应的为电信运营商服务器，网络发送渠道对应的为网银服务器。本实施例中可以选择创建订单信息，该订单信息业携带有终端标识及用户请求对象的状态值，同时订单信息还标识有订单号。通过向第三方服务器发送订单信息，可以供第三方服务器操作订单信息。

步骤S260、向所述单机应用发送通知信息，以使所述单机应用向所述用户发放所请求的对象。

本实施例中，在应用处理程序包本地预置有黑名单，黑名单中记录了存在刷单嫌疑的终端标识。若接收的一个指令中携带的终端标识恰好在黑名单中，则代表该指令有可能是刷单指令，因此为了避免用户刷单，可以选择网络发送渠道，从而保证应用提供商的利益。

进一步，若接收的一个指令中携带的终端标识不在黑名单中，则进一步执行步骤S230的判断逻辑。在步骤S230中，限制了同一终端在预置时间段内所请求的对象状态值的和值的上限，也即若同一终端在一定时间段内多次发送对象请求，且请求的对象状态值的和值超过阈值，则认为该用户也存在刷单的可能，因此选择网络发送渠道。

当然，上述实施例仅仅示例了两种判断逻辑，除此之外还可以存在其它的多种判断逻辑，例如限定同一终端在预置时间段内发送对象请求的次数不能够超过一定值，否则认为该终端存在刷单可能，进而可以选择网络发送渠道作为目标发送渠道。

进一步地，参见图3，图3为本申请实施例公开的又一种单机应用指令处理方法流程图。

如图3所示，该方法包括：

步骤S300、接收终端上的单机应用发送的携带有终端标识及用户请求对象的状态值的指令；

用户对终端上的单机应用进行操作，请求获取应用提供的某个对象。而在应用中，各个对象均具有对应的状态值，状态值可以看作对象在应用中的某种属性，举例如，游戏应用中提供的各种道具即可看作对象，而道具的价值即可以道具的状态值。

步骤S310、判断指令携带的所述终端标识是否在本地预置的黑名单中，若是，则执行步骤S320，若否，则执行步骤S330；

步骤S320、将所述网络发送渠道确定为与所述指令匹配的目标发送渠道；

步骤S330、判断当前时间之前的预置历史时间段内，携带有同一终端标识的指令中，用户请求对象的状态值的和值是否超过阈值，若是，则执行步骤S320，若否，则执行步骤S340；

步骤S340、将所述短信发送渠道确定为与所述指令匹配的目标发送渠道；

步骤S350、利用所述目标发送渠道，将所述指令作为一条订单信息发往与该目标发送渠道对应的第三方服务器；

步骤S360、在检测到终端处于断网状态时，将所述订单信息缓存在本地；

步骤S370、在检测到终端处于联网状态时，将所述订单信息及本地缓存的历史订单信息上传至后台，并且利用后台记录的黑名单对本地的黑名单进行更新；

其中，后台记录的黑名单为后台通过对本地上传的订单信息及第三方服务器操作后并上传的订单信息进行核对所得到的黑名单，其中所述订单信息标识有订单号。

步骤S380、向所述单机应用发送通知信息，以使所述单机应用向所述用户发放所请求的对象。

需要说明的是，在断网状态下，终端向第三方服务器发送订单信息时，一般为短信发送方式。相比于上一实施例可知，本实施例中若终端处于断网状态，则在向第三方服务器发送订单信息后，进一步将订单信息缓存在本地。对于缓存在本地的订单信息，当检测到终端联网后，进一步上传至后台。

当然，上述步骤S370的执行顺序并非限定于图3的情况，其可以在图3中的任意位置执行。

为了便于理解后台创建黑名单的过程，本实施对后台的运行规则进行简单介绍：

后台接收的信息分为两类，一类是第三方服务器操作后并上传的订单信息；另一类是应用处理程序包上传的订单信息。可以理解的是，若订单信息为用户刷单产生的订单信息，则该订单信息无法被第三方服务器操作，也即凡是第三方服务器操作后上传给后台的订单信息均为合法的订单信息。而应用处理程序包上传的订单信息包含了合法订单信息和用户刷单产生的非法订单信息，因此后台通过比对订单号，若发现处理程序包上传的某条订单信息不存在于第三方服务器上传的订单信息中，则代表该条订单信息为非法订单信息，从而将该条订单信息携带的终端标识添加到黑名单中。

进一步地，对于短信发送渠道，其可以分为移动短信发送渠道、联通短信发送渠道和电信短信发送渠道，且该三个短信发送渠道各自包含若干个子渠道。则参见图4，上述实施例中的步骤S240、将所述短信发送渠道确定为与所述指令匹配的目标发送渠道的过程，可以包括：

步骤S400、根据终端的电信运营商标识，从所述移动短信发送渠道、所述联通短信发送渠道和所述电信短信发送渠道中选择电信运营商标识一致的渠道；

步骤S410、根据本地预置的子渠道优先级，从所述电信运营商标识一致的渠道下的子渠道中选择优先级最高的子渠道，将其确定为与所述指令匹配的目标发送渠道。

当单机应用为单机游戏时，移动短信发送渠道下设置有移动和游戏基地发送渠道、移动MM游戏基地发送渠道等，联通短信发送渠道下设置有联通沃商店发送渠道等、电信短信发送渠道下设置有电信爱游戏发送渠道等。其中，各个子渠道均设置有选择优先级。

基于上一实施例，在本申请的又一实施例中，进一步增加单机应用处理程序包对本地子渠道优先级进行更新的过程，详细参见图5。

如图5所示，该方法包括：

步骤S500、接收终端上的单机应用发送的携带有终端标识及用户请求对象的状态值的指令；

步骤S510、判断指令携带的所述终端标识是否在本地预置的黑名单中，若是，则执行步骤S520，若否，则执行步骤S530；

步骤S520、将所述网络发送渠道确定为与所述指令匹配的目标发送渠道；

步骤S530、判断当前时间之前的预置历史时间段内，携带有同一终端标识的指令中，用户请求对象的状态值的和值是否超过阈值，若是，则执行步骤S520，若否，则执行步骤S540；

步骤S540、将所述短信发送渠道确定为与所述指令匹配的目标发送渠道；

步骤S550、利用所述目标发送渠道，将所述指令作为一条订单信息发往与该目标发送渠道对应的第三方服务器；

步骤S560、在检测到终端处于断网状态时，将所述订单信息缓存在本地；

步骤S570、在检测到终端处于联网状态时，将所述订单信息及本地缓存的历史订单信息上传至后台，并且利用后台记录的黑名单对本地的黑名单进行更新；

步骤S580、在检测到终端处于联网状态时，向后台发送子渠道优先级更新请求，所述更新请求中携带有终端标识；

步骤S590、接收后台反馈的子渠道优先级排序，并对本地的子渠道优先级进行更新；

其中后台反馈的子渠道优先级排序为后台利用终端标识确定终端所在省份，进而查询该省份各个子渠道的关停状态，确定该省份各个子渠道的优先级排序。

步骤S600、向所述单机应用发送通知信息，以使所述单机应用向所述用户发放所请求的对象。

当然，上述步骤S580、S590的执行顺序并非限定于图5的情况，其可以在图3中的任意位置执行。

本实施例中，后台通过对各个省份的子渠道的关停状态进行统计，进而确定各个省份的子渠道优先级排序，并将子渠道优先级排序信息发给单机应用处理程序包，以供其对本地子渠道优先级进行更新。

下面对本申请实施例提供的单机应用指令处理装置进行描述，下文描述的单机应用指令处理装置与上文描述的单机应用指令处理方法可相互对应参照。

参见图6，图6为本申请实施例公开的一种单机应用指令处理装置结构示意图。

如图6所示，该装置包括：

指令接收单元61，用于接收终端上的单机应用发送的携带有终端标识及用户请求对象的状态值的指令；

发送渠道匹配单元62，用于查询预置的发送渠道推荐规则，确定与所述指令匹配的目标发送渠道，所述发送渠道推荐规则规定了不同类型的发送渠道对指令携带的终端标识及用户请求对象的状态值的要求；

订单信息发送单元63，用于利用所述目标发送渠道，将所述指令作为一条订单信息发往与该目标发送渠道对应的第三方服务器，以供所述第三方服务器操作所述订单信息；

应用通知单元64，用于向所述单机应用发送通知信息，以使所述单机应用向所述用户发放所请求的对象。

可选的，所述发送渠道可以包括短信发送渠道和网络发送渠道，则所述发送渠道匹配单元可以包括：

第一判断单元，用于判断指令携带的所述终端标识是否在本地预置的黑名单中；

第一发送渠道确定单元，用于在所述第一判断单元判断为是时，将所述网络发送渠道确定为与所述指令匹配的目标发送渠道；

第二判断单元，用于在所述第一判断单元判断为否时，判断当前时间之前的预置历史时间段内，携带有同一终端标识的指令中，用户请求对象的状态值的和值是否超过阈值；

第二发送渠道确定单元，用于在所述第二判断单元判断为是时，将所述网络发送渠道确定为与所述指令匹配的目标发送渠道；

第三发送渠道确定单元，用于在所述第二判断单元判断为否时，将所述短信发送渠道确定为与所述指令匹配的目标发送渠道。

可选的，本申请的单机应用指令处理装置还可以包括：

订单信息缓存单元，用于在检测到终端处于断网状态时，将所述订单信息缓存在本地；

订单信息上传单元，用于在检测到终端处于联网状态时，将所述订单信息及本地缓存的历史订单信息上传至后台；

黑名单更新单元，用于在检测到终端处于联网状态时，利用后台记录的黑名单对本地的黑名单进行更新，其中，后台记录的黑名单为后台通过对本地上传的订单信息及第三方服务器操作后并上传的订单信息进行核对所得到的黑名单，其中所述订单信息标识有订单号。

可选的，所述短信发送渠道包括移动短信发送渠道、联通短信发送渠道和电信短信发送渠道，且该三个短信发送渠道各自包含若干个子渠道，则所述第三发送渠道确定单元可以包括：

运营商确定单元，用于根据终端的电信运营商标识，从所述移动短信发送渠道、所述联通短信发送渠道和所述电信短信发送渠道中选择电信运营商标识一致的渠道；

子渠道确定单元，用于根据本地预置的子渠道优先级，从所述电信运营商标识一致的渠道下的子渠道中选择优先级最高的子渠道，将其确定为与所述指令匹配的目标发送渠道。

可选的，本申请的单机应用指令处理装置还可以包括：

更新请求发送单元，用于在检测到终端处于联网状态时，向后台发送子渠道优先级更新请求，所述更新请求中携带有终端标识；

优先级更新单元，用于接收后台反馈的子渠道优先级排序，并对本地的子渠道优先级进行更新，其中后台反馈的子渠道优先级排序为后台利用终端标识确定终端所在省份，进而查询该省份各个子渠道的关停状态，确定该省份各个子渠道的优先级排序。

本申请实施例提供的单机应用指令处理装置，接收终端上的单机应用发送的携带有终端标识及用户请求对象的状态值的指令，然后查询预置的发送渠道推荐规则，确定与所述指令匹配的目标发送渠道，这里发送渠道推荐规则规定了不同类型的发送渠道对指令携带的终端标识及用户请求对象的状态值的要求，也即可以根据指令选择指令所匹配的目标发送渠道，进而利用所述目标发送渠道，将所述指令作为一条订单信息发往与该目标发送渠道对应的第三方服务器，并向单机应用发送通知信息，以使单机应用向用户发放所请求的对象。本申请支持指令的多种发送渠道，并且各个发送渠道均规定了所发送指令的相关信息，以短信发送渠道为例，可以设定携带某些终端标识的指令不允许发送，如已知的某些刷单终端的标识，还可以设定携带的用户请求对象的状态值超过预设值的指令不允许发送等，通过这种设置，防止了用户持续刷单的问题，保护了单机应用提供商的利益。

本申请实施例还提供一种终端，该终端可以包括上述所述的单机应用指令处理装置，对于单机应用指令处理装置的描述可参照上文对应部分描述，此处不再赘述。

下面对本申请实施例提供的终端的硬件结构进行描述，下文描述中涉及单机应用指令处理的部分可参照上文对应部分描述。图7为本申请实施例提供的终端的硬件结构示意图，参照图7，该终端可以包括：

处理器1，通信接口2，存储器3，通信总线4，和显示屏5；

其中处理器1、通信接口2、存储器3和显示屏5通过通信总线4完成相互间的通信；

可选的，通信接口2可以为通信模块的接口，如GSM模块的接口；

处理器1，用于执行程序；

存储器3，用于存放程序；

程序可以包括程序代码，所述程序代码包括处理器的操作指令。

处理器1可能是一个中央处理器CPU，或者是特定集成电路ASIC(ApplicationSpecific Integrated Circuit)，或者是被配置成实施本申请实施例的一个或多个集成电路。

存储器3可能包含高速RAM存储器，也可能还包括非易失性存储器(non-volatilememory)，例如至少一个磁盘存储器。

其中，程序可具体用于：

接收终端上的单机应用发送的携带有终端标识及用户请求对象的状态值的指令；

查询预置的发送渠道推荐规则，确定与所述指令匹配的目标发送渠道，所述发送渠道推荐规则规定了不同类型的发送渠道对指令携带的终端标识及用户请求对象的状态值的要求；

利用所述目标发送渠道，将所述指令作为一条订单信息发往与该目标发送渠道对应的第三方服务器，以供所述第三方服务器操作所述订单信息；

向所述单机应用发送通知信息，以使所述单机应用向所述用户发放所请求的对象。

最后，还需要说明的是，在本文中，诸如第一和第二等之类的关系术语仅仅用来将一个实体或者操作与另一个实体或操作区分开来，而不一定要求或者暗示这些实体或操作之间存在任何这种实际的关系或者顺序。而且，术语“包括”、“包含”或者其任何其他变体意在涵盖非排他性的包含，从而使得包括一系列要素的过程、方法、物品或者设备不仅包括那些要素，而且还包括没有明确列出的其他要素，或者是还包括为这种过程、方法、物品或者设备所固有的要素。在没有更多限制的情况下，由语句“包括一个……”限定的要素，并不排除在包括所述要素的过程、方法、物品或者设备中还存在另外的相同要素。

本说明书中各个实施例采用递进的方式描述，每个实施例重点说明的都是与其他实施例的不同之处，各个实施例之间相同相似部分互相参见即可。

对所公开的实施例的上述说明，使本领域专业技术人员能够实现或使用本申请。对这些实施例的多种修改对本领域的专业技术人员来说将是显而易见的，本文中所定义的一般原理可以在不脱离本申请的精神或范围的情况下，在其它实施例中实现。因此，本申请将不会被限制于本文所示的这些实施例，而是要符合与本文所公开的原理和新颖特点相一致的最宽的范围。

Claims (11)

1.一种单机应用指令处理方法，其特征在于，包括：

接收终端上的单机应用发送的携带有终端标识及用户请求对象的状态值的指令；

查询预置的发送渠道推荐规则，确定与所述指令匹配的目标发送渠道，所述发送渠道推荐规则规定了不同类型的发送渠道对指令携带的终端标识及用户请求对象的状态值的要求；所述发送渠道包括短信发送渠道和网络发送渠道，所述查询预置的发送渠道推荐规则，确定与所述指令匹配的目标发送渠道包括：若所述终端在预置时间段内发送所述指令的次数超过次数阈值，或；在限定时间段内，携带同一终端标识的各个指令中的用户请求对象的状态值的和值超过额定阈值；或；若指令中携带预设终端标识；则将所述网络发送渠道确定为与所述指令匹配的目标发送渠道，以避免用户在用户账户余额不足而短信套餐充足的条件下通过所述短信发送渠道进行刷单；

利用所述目标发送渠道，将所述指令作为一条订单信息发往与该目标发送渠道对应的第三方服务器，以供所述第三方服务器操作所述订单信息；

向所述单机应用发送通知信息，以使所述单机应用向所述用户发放所请求的对象。

2.根据权利要求1所述的方法，其特征在于，所述发送渠道包括短信发送渠道和网络发送渠道，所述查询预置的发送渠道推荐规则，确定与所述指令匹配的目标发送渠道，包括：

判断指令携带的所述终端标识是否在本地预置的黑名单中；

若是，则将所述网络发送渠道确定为与所述指令匹配的目标发送渠道；

若否，则判断当前时间之前的预置历史时间段内，携带有同一终端标识的指令中，用户请求对象的状态值的和值是否超过阈值；

若是，则将所述网络发送渠道确定为与所述指令匹配的目标发送渠道；

若否，则将所述短信发送渠道确定为与所述指令匹配的目标发送渠道。

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

在检测到终端处于断网状态时，将所述订单信息缓存在本地；

在检测到终端处于联网状态时，将所述订单信息及本地缓存的历史订单信息上传至后台，并且利用后台记录的黑名单对本地的黑名单进行更新，其中，后台记录的黑名单为后台通过对本地上传的订单信息及第三方服务器操作后并上传的订单信息进行核对所得到的黑名单，其中所述订单信息标识有订单号。

4.根据权利要求2所述的方法，其特征在于，所述短信发送渠道包括移动短信发送渠道、联通短信发送渠道和电信短信发送渠道，且该三个短信发送渠道各自包含若干个子渠道，所述将所述短信发送渠道确定为与所述指令匹配的目标发送渠道，包括：

根据终端的电信运营商标识，从所述移动短信发送渠道、所述联通短信发送渠道和所述电信短信发送渠道中选择电信运营商标识一致的渠道；

根据本地预置的子渠道优先级，从所述电信运营商标识一致的渠道下的子渠道中选择优先级最高的子渠道，将其确定为与所述指令匹配的目标发送渠道。

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

在检测到终端处于联网状态时，向后台发送子渠道优先级更新请求，所述更新请求中携带有终端标识；

接收后台反馈的子渠道优先级排序，并对本地的子渠道优先级进行更新，其中后台反馈的子渠道优先级排序为后台利用终端标识确定终端所在省份，进而查询该省份各个子渠道的关停状态，确定该省份各个子渠道的优先级排序。

6.一种单机应用指令处理装置，其特征在于，包括：

指令接收单元，用于接收终端上的单机应用发送的携带有终端标识及用户请求对象的状态值的指令；

发送渠道匹配单元，用于查询预置的发送渠道推荐规则，确定与所述指令匹配的目标发送渠道，所述发送渠道推荐规则规定了不同类型的发送渠道对指令携带的终端标识及用户请求对象的状态值的要求；所述发送渠道包括短信发送渠道和网络发送渠道，所述查询预置的发送渠道推荐规则，确定与所述指令匹配的目标发送渠道包括：若所述终端在预置时间段内发送所述指令的次数超过次数阈值，或；在限定时间段内，携带同一终端标识的各个指令中的用户请求对象的状态值的和值超过额定阈值；或；若指令中携带预设终端标识；则将所述网络发送渠道确定为与所述指令匹配的目标发送渠道，以避免用户在用户账户余额不足而短信套餐充足的条件下通过所述短信发送渠道进行刷单；

订单信息发送单元，用于利用所述目标发送渠道，将所述指令作为一条订单信息发往与该目标发送渠道对应的第三方服务器，以供所述第三方服务器操作所述订单信息；

应用通知单元，用于向所述单机应用发送通知信息，以使所述单机应用向所述用户发放所请求的对象。

7.根据权利要求6所述的装置，其特征在于，所述发送渠道包括短信发送渠道和网络发送渠道，所述发送渠道匹配单元包括：

第一判断单元，用于判断指令携带的所述终端标识是否在本地预置的黑名单中；

第一发送渠道确定单元，用于在所述第一判断单元判断为是时，将所述网络发送渠道确定为与所述指令匹配的目标发送渠道；

第二判断单元，用于在所述第一判断单元判断为否时，判断当前时间之前的预置历史时间段内，携带有同一终端标识的指令中，用户请求对象的状态值的和值是否超过阈值；

第二发送渠道确定单元，用于在所述第二判断单元判断为是时，将所述网络发送渠道确定为与所述指令匹配的目标发送渠道；

第三发送渠道确定单元，用于在所述第二判断单元判断为否时，将所述短信发送渠道确定为与所述指令匹配的目标发送渠道。

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

订单信息缓存单元，用于在检测到终端处于断网状态时，将所述订单信息缓存在本地；

订单信息上传单元，用于在检测到终端处于联网状态时，将所述订单信息及本地缓存的历史订单信息上传至后台；

黑名单更新单元，用于在检测到终端处于联网状态时，利用后台记录的黑名单对本地的黑名单进行更新，其中，后台记录的黑名单为后台通过对本地上传的订单信息及第三方服务器操作后并上传的订单信息进行核对所得到的黑名单，其中所述订单信息标识有订单号。

9.根据权利要求7所述的装置，其特征在于，所述短信发送渠道包括移动短信发送渠道、联通短信发送渠道和电信短信发送渠道，且该三个短信发送渠道各自包含若干个子渠道，所述第三发送渠道确定单元包括：

运营商确定单元，用于根据终端的电信运营商标识，从所述移动短信发送渠道、所述联通短信发送渠道和所述电信短信发送渠道中选择电信运营商标识一致的渠道；

子渠道确定单元，用于根据本地预置的子渠道优先级，从所述电信运营商标识一致的渠道下的子渠道中选择优先级最高的子渠道，将其确定为与所述指令匹配的目标发送渠道。

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

更新请求发送单元，用于在检测到终端处于联网状态时，向后台发送子渠道优先级更新请求，所述更新请求中携带有终端标识；

优先级更新单元，用于接收后台反馈的子渠道优先级排序，并对本地的子渠道优先级进行更新，其中后台反馈的子渠道优先级排序为后台利用终端标识确定终端所在省份，进而查询该省份各个子渠道的关停状态，确定该省份各个子渠道的优先级排序。

11.一种存储介质，其特征在于，所述存储介质中存储有程序代码，所述程序代码被执行时实现如权利要求1至5任一项所述的单机应用指令处理方法。

Images