订单处理方法、司机终端及服务端与流程

本申请涉及互联网技术领域，尤其涉及一种订单处理方法、司机终端及服务端。

背景技术

随着互联网以智能终端设备的发展，线上下单逐渐深入人们的生活，为人们提供便利，并成了人们生活中必不可少的部分。例如，在一种应用场景下，用户可在线预约或订购运输服务。之后，用户的订单会被推送至开启接单模式的货运司机进行抢单，抢到订单的司机可为用户上门提供货运或搬家等服务。

但是现有技术中，执行与运输服务相关的订单处理时，仍旧存在订单处理方法较为单一的缺陷。

技术实现要素：

本申请实施例提供一种订单处理方法、司机终端及服务端，用以更加灵活地处理订单。

本申请实施例提供一种订单处理方法，适用于第一司机的司机终端，包括：接收服务端针对第一订单发送的派单通知；获取所述第一司机将所述第一订单分配给与所述第一司机关联的第二司机的订单分配请求；向所述服务端发送所述订单分配请求，以使所述服务端将所述第一订单派单至所述第二司机。

进一步可选地，所述方法还包括：向所述服务端发送跟踪请求，以获取所述第二司机执行所述第一订单时的行为数据。

进一步可选地，跟踪所述第二司机执行所述第一订单时的行为，包括：获取所述第二司机执行所述第一订单时的起始时间；和/或，获取所述第二司机执行所述第一订单时的行驶轨迹；和/或，获取所述第二订单对应的用户对所述第一司机的评价。

进一步可选地，从关联的多个司机中，获取所述第一司机将所述第一订单分配给与所述第一司机关联的第二司机的订单分配请求，包括：获取所述第一订单的订单详情；展示所述第一订单的订单详情以及与所述第一司机关联的至少一个可分配的司机；获取所述第一司机从所述至少一个可分配的司机中选择的第二司机，以生成所述订单分配请求。

进一步可选地，所述方法还包括：接收所述第二司机发送的订单拒接请求或订单取消请求；获取所述第一司机从所述至少一个可分配的司机中选择的第三司机，以生成所述订单再分配请求；向所述服务端发送订单再分配请求，以使所述服务端将所述第一订单派单至所述第三司机。

本申请实施例还提供一种订单处理方法，适用于服务端，包括：向第一司机的司机终端发送针对第一订单的派单通知；接收所述第一司机的司机终端发送的将所述第一订单分配给第二司机的订单分配请求；将所述第一订单派单至所述第二司机。

进一步可选地，将所述第一订单派单至所述第二司机之后，还包括：在所述第二司机执行所述第一订单时，接收所述第二司机的司机终端上报的位置数据；根据所述位置数据，确定所述第二司机的行驶轨迹。

进一步可选地，所述方法还包括：根据所述第一订单的实际订单数据，确定所述第一订单对应的订单收益和/或订单服务质量；将所述第一订单对应的订单收益发放至所述第一司机；和/或，根据所述第一订单对应的服务质量更新所述第一司机的服务质量。

本申请实施例还提供一种司机终端，包括：通知接收模块，用于接收针对第一订单的派单通知；司机确定模块，用于从关联的多个司机中，确定第二司机作为执行所述第一订单的对象司机；分单模块，用于将所述第一订单分配给第二司机，以使所述第二司机执行所述第一订单。

本申请实施例还提供一种服务端，包括：通知发送模块，向第一司机的司机终端发送针对第一订单的派单通知；请求接收模块，用于接收所述第一司机发送的将所述第一订单分配给第二司机的分配请求；派单模块，用于将所述第一订单派单至所述第二司机。

本申请实施例中，第一司机的司机终端接收到针对第一订单的派单通知后，可根据第一司机的指示，将与第一司机关联的第二司机作为执行第一订单的对象司机，并请求服务端将第一订单分配给第二司机进行处理。在这样的实施方式中，司机终端和服务端可以同时加入到订单分配的过程中，使得订单处理过程更加灵活。

附图说明

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

图1是本申请一实施例提供的订单处理方法在第一司机的司机终端执行时的方法流程图；

图2是本申请另一实施例提供的订单处理方法在第一司机的司机终端执行时的方法流程图；

图3是本申请一实施例提供的订单处理方法在服务端执行时的方法流程图；

图4是本申请另一实施例提供的订单处理方法在服务端行时的方法流程图；

图5a是本申请一实施例提供的第一司机的司机终端的结构示意图；

图5b是本申请另一实施例提供的第一司机的司机终端的结构示意图；

图6a是本申请一实施例提供的服务端的结构示意图；

图6b是本申请另一实施例提供的服务端的结构示意图。

具体实施方式

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

在本发明实施例中使用的术语是仅仅出于描述特定实施例的目的，而非旨在限制本发明。在本发明实施例和所附权利要求书中所使用的单数形式的“一种”、“所述”和“该”也旨在包括多数形式，除非上下文清楚地表示其他含义，“多种”一般包含至少两种，但是不排除包含至少一种的情况。

应当理解，本文中使用的术语“和/或”仅仅是一种描述关联对象的关联关系，表示可以存在三种关系，例如，a和/或b，可以表示：单独存在a，同时存在a和b，单独存在b这三种情况。另外，本文中字符“/”，一般表示前后关联对象是一种“或”的关系。

应当理解，尽管在本发明实施例中可能采用术语第一、第二、第三等来描述xxx，但这些xxx不应限于这些术语。这些术语仅用来将xxx彼此区分开。例如，在不脱离本发明实施例范围的情况下，第一xxx也可以被称为第二xxx，类似地，第二xxx也可以被称为第一xxx。

取决于语境，如在此所使用的词语“如果”、“若”可以被解释成为“在……时”或“当……时”或“响应于确定”或“响应于检测”。类似地，取决于语境，短语“如果确定”或“如果检测(陈述的条件或事件)”可以被解释成为“当确定时”或“响应于确定”或“当检测(陈述的条件或事件)时”或“响应于检测(陈述的条件或事件)”。

还需要说明的是，术语“包括”、“包含”或者其任何其他变体意在涵盖非排他性的包含，从而使得包括一系列要素的商品或者系统不仅包括那些要素，而且还包括没有明确列出的其他要素，或者是还包括为这种商品或者系统所固有的要素。在没有更多限制的情况下，由语句“包括一个……”限定的要素，并不排除在包括所述要素的商品或者系统中还存在另外的相同要素。

在一种应用场景中，部分能够提供运输服务的司机隶属于运输服务公司或者组织。在这种情况下，若采用现有技术提供的订单处理方法，每个司机都需注册线上接单的账号。但是这种订单处理方法较为单一，运输服务公司或者组织无法实现对司机的管理。

为解决上述缺陷，本申请实施例提供了一种订单处理方法，以下将结合附图，对本申请实施例提供的订单处理方法进行说明。

图1是本申请一实施例提供的订单处理方法在第一司机的司机终端端执行时的方法流程图，如图1所示，该方法包括：

步骤101、接收服务端针对第一订单发送的派单通知。

步骤102、获取第一司机将第一订单分配给与第一司机关联的第二司机的订单分配请求。

步骤103、向服务端发送订单分配请求，以使服务端将第一订单派单至第二司机。

一个典型的运输服务场景可包括三个部分：用户端、服务端以及司机终端。用户可以通过个人持有的用户端在线发起订单请求，服务端接收该订单请求，并可将订单请求推送至司机终端；司机通过个人持有的司机终端接收到服务端推送的订单之后，可根据实际情况决定接单与否；若司机接单，则可通过司机终端向服务端发送抢单请求，服务端可在应允司机终端的抢单请求时，将该订单派单至发起抢单的司机终端进行处理。

本实施例可以由第一司机的司机终端执行。第一司机关联有至少一个司机，且第一司机通过个人持有的司机终端与服务端进行通信，接收服务端发送的第一订单的派单通知，并将第一订单分配给与其关联的至少一个司机。第二司机是第一司机从与第一司机关联的至少一个司机中，选出的用于执行第一订单的司机。

确定第一司机将第一订单分配给与第一司机关联的第二司机时，第一司机的司机终端向服务端发送订单分配请求。服务端接收到订单分配请求时，可根据订单分配请求的指示，将第一订单派单至第二司机。

本实施例中，第一司机的司机终端接收到针对第一订单的派单通知后，可根据第一司机的指示，将与第一司机关联的第二司机作为执行第一订单的对象司机，并请求服务端将第一订单分配给第二司机进行处理。在这样的实施方式中，司机终端和服务端可以同时加入到订单分配的过程中，使得订单处理过程更加灵活。

可选的，本申请实施例的技术方案可以应用于一个典型的实际应用场景中：多个司机组成一个车队，并选举出一个用于队长司机。例如，为提高搬家公司的管理效率以及综合服务质量，搬家公司内部可组成多个司机小分队，每个司机小分队可由小分队的队长司机管理队内的多个队员司机。在这种应用场景中，第一司机相当于车队中的队长司机的角色，第二司机相当于车队中接受队长管理的队员司机。在这种实施方式中，队长司机可通过个人持有的司机终端接收服务端发送的派单通知，并将相应的订单分配给队员司机，使得订单处理过程更加灵活。

以下部分将结合具体的实施例对本申请提供的订单处理方法进行具体说明。

图2是本申请另一实施例提供的订单处理方法在第一司机的司机终端执行时的方法流程图，如图2所示，该方法包括：

步骤201、接收服务端针对第一订单发送的派单通知。

步骤202、获取所述第一订单的订单详情。

步骤203、展示所述第一订单的订单详情以及与所述第一司机关联的至少一个可分配的司机。

步骤204、获取所述第一司机从所述至少一个可分配的司机中选择的第二司机，以生成所述订单分配请求。

步骤205、向所述服务端发送所述订单分配请求，以使所述服务端将所述第一订单派单至所述第二司机。

步骤206、向所述服务端发送跟踪请求，以获取所述第二司机执行所述第一订单时的行为数据。

步骤207、接收所述第二司机发送的订单拒接请求或订单取消请求。

步骤208、获取所述第一司机从所述至少一个可分配的司机中选择的第三司机，以生成订单再分配请求。

步骤209、向所述服务端发送订单再分配请求，以使所述服务端将所述第一订单派单至所述第三司机。

在步骤201中，可选的，第一订单，可以是服务端强指派给第一司机的订单。在这种情况下，第一司机无需通过其持有的司机终端向服务端发送抢单请求，服务端可在接收到用户的在线下单请求之后，直接将第一订单强指派给第一司机，并向第一司机持有的司机终端发送第一订单的派单通知。

可选的，第一订单可以是第一司机通过其持有的司机终端发起抢单操作并且抢单成功的订单。第一司机抢单成功后，服务端可向第一司机的司机终端发送第一订单的派单通知。

可选的，第一订单的的派单通知可指示第一司机对第一订单进行分配，并上报分配结果。

在步骤202中，可选的，第一订单的订单详情可包括：订单的始发地、目的地、需要运输的货物种类、运输出发时间、用户指定的车型、用户指定的车辆运力和/或是否需要司机提供人力搬运服务等。

在步骤203中，可选的，第一司机的司机终端在获取到第一订单的订单详情后，可展示一页面，该页面上展示第一订单的订单详情，以便于第一司机查看。

可选的，第一司机的司机终端展示第一订单的订单详情的同时，还可展示与第一司机关联的至少一个可分配的司机。例如，以司机名称列表展示至少一个可分配的司机，或者展示至少一个可分配的司机的头像。

可选的，展示所述至少一个可分配的司机时，可展示每一个司机的具体信息，例如，每一个司机的当前地理位置、车型、车辆运力和/或可接单时间等。进而，司机可将第订单的订单详情以及至少一个可分配的司机的具体信息作为分配订单时的参考数据，提高订单分配结果的合理性。

在步骤204中，可选的，第一司机的司机终端展示与第一司机关联的每一个司机的具体信息时，可同时展示与每一个司机关联的选择按钮。进而，第一司机可通过触发该第二司机对应的选择按钮选定第二司机作为执行第一订单的对象司机。

在步骤205中，可选的，第一司机的司机终端可响应于第一司机针对第二司机对应的选择按钮的触发，将订单分配请求发送至服务端。服务端接收到订单分配请求之后，可将第一订单派单给第二司机。在步骤206中，可选的，跟踪请求可以是第一司机主动通过其司机终端发起的。例如，在第一司机的司机终端的订单页面上，可展示由第一司机分配的订单的订单编号。第一司机可通过触发每一订单的订单编号进入订单详情页。响应于第一司机进入订单详情页的操作，第一司机的司机终端可向服务端发送跟踪请求，请求获取第二司机执行所述第一订单时的行为数据。获取到行为数据后，可在订单详情页展示行为数据。

可选的，跟踪请求也可以是第一司机的司机终端自动向服务端发起的。在这种实施方式中，第一司机的司机终端可按照设定的周期向服务端发送跟踪请求，并将服务端返回的行为数据保存至本地。当第一司机进入订单详情页时，第一司机的司机终端可从本地读取行为数据，以快速展示第二司机执行所述第一订单时的行为。

可选的，获取所述第二司机执行所述第一订单时的行为数据，可包括：获取所述第二司机执行所述第一订单时的起始时间；和/或，获取所述第二司机执行所述第一订单时的行驶轨迹；和/或，获取所述第二订单对应的用户对所述第一司机的评价。

应当理解，本步骤的目的在于：向第一司机提供监管与之关联的其他司机的渠道。第一司机通过第二司机执行第一订单时的行为数据对第二司机的作业过程进行监管时，有利于提升第二司机的服务质量以及用户的体验。

可选的，在本步骤中，第一司机的司机终端还可根据由其分配的订单的当前状态，展示订单的状态标签。例如，在正在进行中的订单的订单编号处添加“待结算”标签，在已完成的订单的订单编号处添加“已结算”标签。进而，便于第一司机对订单进行管理。

步骤207中，在一种可能的应用场景中，第一司机将第一订单分配给第二司机之后，由于第二司机的主观原因或者客观原因导致第二司机无法完成第一订单。在这种情况下，第二司机可以向第一司机发送订单拒绝请求或订单取消请求。可选的，第一司机的司机终端在接收到第二司机发送的订单拒绝请求或订单取消请求时，可再次展示与所述第一司机关联的至少一个可分配的司机，并可在展示之前将第二司机从所述至少一个可分配的司机中删除，以在有限的展示页面上展示尽可能多的可分配的司机，提升订单的转化率。

在步骤208中，可选的，第一司机的司机终端再次展示所述至少一个可分配的司机的司机的信息时，可同时展示与每一个司机关联的选择按钮。第一司机可通过触发该第三司机对应的选择按钮选定第三司机作为执行第一订单的对象司机。第一司机的司机终端在接到第一司机从展示的至少一个可分配的司机中选择符合接单条件的第三司机时，可生成订单再分配请求。

在步骤209中，可选的，第一司机的司机终端可响应于第一司机针对第三司机对应的选择按钮的触发，将订单再分配请求发送至服务端。其中，订单再分配请求。服务端接收到订单再分配请求之后，可将第一订单派单给第三司机。

需要说明的是，当第一司机的司机终端端接收到第三司机发送的订单拒绝请求或订单取消请求时，可将第三司机从所述至少一个可分配的司机中删除之后再次展示与所述至少一个可分配的司机，并从剩余的可分配的司机中选取可执行第一订单的对象司机。应当理解，每当有司机无法服从订单分配时，第一司机及其司机终端均可采用上述方式进行订单再分配，此处不赘述。

本实施例中，第一司机的司机终端接收到针对第一订单的派单通知后，可根据第一司机的指示，将与第一司机关联的第二司机作为执行第一订单的对象司机，并请求服务端将第一订单分配给第二司机进行处理。在这样的实施方式中，司机终端和服务端可以同时加入到订单分配的过程中，使得订单处理过程更加灵活。除此之外，在第二司机无法完成第一订单时，第一司机可通过其司机终端将第一订单流转给第三司机，有利于提升订单转化率以及第一司机的接单积极性。

以上实施例，从第一司机的司机终端的角度描述了本申请提供的订单处理方法的实施过程，以下将从服务端的角度继续对本申请的技术方案进行说明。

图3是本申请一实施例提供的订单处理方法在服务端执行时的方法流程图，如图3所示，该方法包括：

步骤301、向第一司机的司机终端发送针对第一订单的派单通知。

步骤302、接收所述第一司机的司机终端发送的将所述第一订单分配给第二司机的订单分配请求。

步骤303、将所述第一订单派单至所述第二司机。

在本实施例中，第一司机是服务端选定的用于处理第一订单的对象司机。服务端将针对第一订单的派单通知发送给第一司机的司机终端后，第一司机可通过其司机终端进行订单分配，并在确定订单分配结果之后，向服务端发送订单分配请求。具体的订单分配方法可参考前述实施例的记载，此处不赘述。服务端接收到订单分配请求之后，可根据订单分配请求的指示，将第一订单派单至第二司机。在这样的实施方式中，司机终端和服务端可以同时加入到订单分配的过程中，使得订单处理过程更加灵活。

图4是本申请另一实施例提供的订单处理方法在服务端执行时的方法流程图，如图4所示，该方法包括：

步骤401、向第一司机的司机终端发送针对第一订单的派单通知。

步骤402、接收所述第一司机的司机终端发送的将所述第一订单分配给第二司机的订单分配请求。

步骤403、将所述第一订单派单至所述第二司机。

步骤404、在所述第二司机执行所述第一订单时，接收所述第二司机的司机终端上报的位置数据，以根据所述位置数据，确定所述第二司机的行驶轨迹。

步骤405、在所述第一订单结束时，根据所述第一订单的实际订单数据，确定所述第一订单对应的订单收益和/或订单服务质量。

步骤406、将所述第一订单对应的订单收益发放至所述第一司机；和/或，根据所述第一订单对应的服务质量更新所述第一司机的服务质量。

在步骤401中，可选的，服务端在接收到用户通过个人持有的客户端发送的第一订单处理请求之后，可将第一订单推送至符合接单要求的司机终端，以使符合接单要求的司机通过个人的司机终端发起抢单请求。服务端接收到抢单请求之后，从发起抢单请求的司机中选取第一司机作为处理第一订单的对象司机，并向第一司机的司机终端发送针对第一订单的派单通知。

可选的，服务端也可以在接收到用户通过个人持有的客户端发送的第一订单处理请求之后，将第一订单强指派给第一司机进行处理，并向第一司机的司机终端发送针对第一订单的派单通知。

在步骤402以及403中，服务端可接收第一司机的司机终端发送的将第一订单分配给第二司机的订单分配请求，并将第一订单派单至第二司机由第二司机完成。

需要说明的是，在实际中，当第一司机和与之关联的多个司机表现为一个车队中的队长司机和接受队长司机管理的多个队员司机时，在处理订单之前，可在线上以车队为单位注册运输服务账号。注册运输服务时，队长司机需要提供注册所需的认证资料并交纳相应的保证金。在一种实施方式中，队长司机可邀请队员司机加入车队，并可在创建车队之后向服务端请求关联队员司机。响应于队长司机的邀请，队员司机可注册运输服务账号，并可在未缴纳保证金的情况下，接受并执行队长司分配的订单。基于这种队长司机和队员司机均注册账号的实施方式，可执行步骤404。

在步骤404中，可选的，在第二司机执行第一订单的过程中，第二司机的司机终端可按照设定的周期向服务端上报位置数据。服务端接收到位置数据后，可绘制第二司机的行驶轨迹。进而，当第一司机的司机终端向服务端发送跟踪请求时，服务端可将第二司机的行驶轨迹反馈至第一司机的司机终端，有利于第一司机对第二司机的作业过程进行监管，提升第二司机的服务质量。

需要说明的是，当第二司机(队员司机)未注册运输服务账号时，第一司机(队长司机)可通过其他联系方式(例如电话联系)对第二司机(队员司机)的订单处理过程进行监管，不赘述。

在步骤405中，可选的，当用户在其客户端上操作结束订单和/或第二司机在其客户端上操作结束订单时，可认为第一订单执行结束。此时，可根据所述第一订单的实际订单数据，确定所述第一订单对应的订单收益和/或订单服务质量。

其中，第一订单的实际订单数据可包括：第一订单的实际花费时间、实际运输距离、是否有高速费/过桥费等、所采用的车辆的车型和/或所采用的车辆的运力等。根据上述信息，可计算完成第一订单后，司机可获取的订单收益。订单服务质量，可包括用户在结束订单后给第二司机服务进行打分的评价分数和/或评价标签等。

在步骤406中，可选的，确定第一订单的订单收益之后，将该订单收益发放至第一司机，以便于第一司机对第二司机的收益情况进行管理。

可选的，确定第一订单对应的服务质量后，可结合第一司机的历史服务质量重新计算第一司机的服务质量。通过采用这种方式，可加强第一司机对与之关联的其他司机服务质量的监管。

在一种可能的情况下，若第二司机执行第一订单的行为遭到用户投诉进而服务端需要对其进行惩罚时，服务端可将惩罚措施下发至第一司机的司机终端，例如扣除第一司机缴纳的保证金，以警示第一司机提升对与之关联的其他司机的监管力度。

以上描述了订单处理方法的可选实施方式，实际中，该订单处理方法可通过第一司机的司机终端以及服务端之间的交互实现。

如图5a所示，第一司机的司机终端包括：

通知接收模块501，用于接收服务端针对第一订单发送的派单通知；司机确定模块502，用于获取所述第一司机将所述第一订单分配给与所述第一司机关联的第二司机的订单分配请求；分单模块503，向所述服务端发送所述订单分配请求，以使所述服务端将所述第一订单派单至所述第二司机。

进一步可选地，如图5b所示，第一司机的司机终端还包括：行为跟踪模块504，用于：向所述服务端发送跟踪请求，以获取所述第二司机执行所述第一订单时的行为数据。

进一步可选地，行为跟踪模块504具体用于：获取所述第二司机执行所述第一订单时的起始时间；和/或，获取所述第二司机执行所述第一订单时的行驶轨迹；和/或，获取所述第二订单对应的用户对所述第一司机的评价。

进一步可选地，司机确定模块502具体用于：获取所述第一订单的订单详情；展示所述第一订单的订单详情以及与所述第一司机关联的至少一个可分配的司机；获取所述第一司机从所述至少一个可分配的司机中选择的第二司机，以生成所述订单分配请求。

进一步可选地，司机确定模块502还用于：接收所述第二司机发送的订单拒接请求或订单取消请求；获取所述第一司机从所述至少一个可分配的司机中选择的第三司机，以生成订单再分配请求；向所述服务端发送订单再分配请求，以使所述服务端将所述第一订单派单至所述第三司机。

上述第一司机的司机终端可执行图1以及图2对应实施例所提供的订单处理方法，具备执行方法相应的功能模块和有益效果。未在本实施例中详尽描述的技术细节，可参见本申请实施例所提供的方法，不再赘述。

如图6a所示，服务端包括：

通知发送模块601，向第一司机的司机终端发送针对第一订单的派单通知；请求接收模块602，用于接收所述第一司机的司机终端发送的将所述第一订单分配给第二司机的订单分配请求；派单模块603，用于将所述第一订单派单至所述第二司机。

进一步可选地，派单模块603具体用于：将所述第一订单派单至所述第二司机之后，在所述第二司机执行所述第一订单时，接收所述第二司机的司机终端上报的位置数据；根据所述位置数据，确定所述第二司机的行驶轨迹。

进一步可选地，如图6b所示，服务端还包括：订单结算模块604，用于根据所述第一订单的实际订单数据，确定所述第一订单对应的订单收益和/或订单服务质量；将所述第一订单对应的订单收益发放至所述第一司机；和/或，根据所述第一订单对应的服务质量更新所述第一司机的服务质量。

上述服务端可执行图2以及图3对应实施例所提供的订单处理方法，具备执行方法相应的功能模块和有益效果。未在本实施例中详尽描述的技术细节，可参见本申请实施例所提供的方法，不再赘述。

本领域内的技术人员应明白，本申请的实施例可提供为方法、系统、或计算机程序产品。因此，本申请可采用完全硬件实施例、完全软件实施例、或结合软件和硬件方面的实施例的形式。而且，本申请可采用在一个或多个其中包含有计算机可用程序代码的计算机可用存储介质(包括但不限于磁盘存储器、cd-rom、光学存储器等)上实施的计算机程序产品的形式。

本申请是参照根据本申请实施例的方法、设备(系统)、和计算机程序产品的流程图和/或方框图来描述的。应理解可由计算机程序指令实现流程图和/或方框图中的每一流程和/或方框、以及流程图和/或方框图中的流程和/或方框的结合。可提供这些计算机程序指令到通用计算机、专用计算机、嵌入式处理机或其他可编程数据处理设备的处理器以产生一个机器，使得通过计算机或其他可编程数据处理设备的处理器执行的指令产生用于实现在流程图一个流程或多个流程和/或方框图一个方框或多个方框中指定的功能的装置。

这些计算机程序指令也可存储在能引导计算机或其他可编程数据处理设备以特定方式工作的计算机可读存储器中，使得存储在该计算机可读存储器中的指令产生包括指令装置的制造品，该指令装置实现在流程图一个流程或多个流程和/或方框图一个方框或多个方框中指定的功能。

这些计算机程序指令也可装载到计算机或其他可编程数据处理设备上，使得在计算机或其他可编程设备上执行一系列操作步骤以产生计算机实现的处理，从而在计算机或其他可编程设备上执行的指令提供用于实现在流程图一个流程或多个流程和/或方框图一个方框或多个方框中指定的功能的步骤。

在一个典型的配置中，计算设备包括一个或多个处理器(cpu)、输入/输出接口、网络接口和内存。

内存可能包括计算机可读介质中的非永久性存储器，随机存取存储器(ram)和/或非易失性内存等形式，如只读存储器(rom)或闪存(flashram)。内存是计算机可读介质的示例。

计算机可读介质包括永久性和非永久性、可移动和非可移动媒体可以由任何方法或技术来实现信息存储。信息可以是计算机可读指令、数据结构、程序的模块或其他数据。计算机的存储介质的例子包括，但不限于相变内存(pram)、静态随机存取存储器(sram)、动态随机存取存储器(dram)、其他类型的随机存取存储器(ram)、只读存储器(rom)、电可擦除可编程只读存储器(eeprom)、快闪记忆体或其他内存技术、只读光盘只读存储器(cd-rom)、数字多功能光盘(dvd)或其他光学存储、磁盒式磁带，磁带磁磁盘存储或其他磁性存储设备或任何其他非传输介质，可用于存储可以被计算设备访问的信息。按照本文中的界定，计算机可读介质不包括暂存电脑可读媒体(transitorymedia)，如调制的数据信号和载波。

还需要说明的是，术语“包括”、“包含”或者其任何其他变体意在涵盖非排他性的包含，从而使得包括一系列要素的过程、方法、商品或者设备不仅包括那些要素，而且还包括没有明确列出的其他要素，或者是还包括为这种过程、方法、商品或者设备所固有的要素。在没有更多限制的情况下，由语句“包括一个……”限定的要素，并不排除在包括所述要素的过程、方法、商品或者设备中还存在另外的相同要素。

最后应说明的是：以上实施例仅用以说明本发明的技术方案，而非对其限制；尽管参照前述实施例对本发明进行了详细的说明，本领域的普通技术人员应当理解：其依然可以对前述各实施例所记载的技术方案进行修改，或者对其中部分技术特征进行等同替换；而这些修改或者替换，并不使相应技术方案的本质脱离本发明各实施例技术方案的精神和范围。