订单回捞方法、回捞订单显示方法、服务端及司机终端与流程

文档序号:15935226发布日期:2018-11-14 02:17阅读:552来源:国知局

本申请涉及互联网技术领域,尤其涉及一种订单回捞方法、回捞订单显示方法、服务端及司机终端。

背景技术

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

但是,上述方法对用户下单和司机在线抢单的时间匹配度要求较高,不利于提高订单的转化率。



技术实现要素:

本申请实施例提供一种订单回捞方法、回捞订单显示方法、服务端及司机终端,用以延长回捞订单的存活周期,提高订单的转化率。

本申请实施例提供一种订单回捞方法,包括:根据未被接单的订单的当前订单状态,从所述未被接单的订单中确定符合回捞条件的订单作为回捞订单;将所述回捞订单添加至指定的回捞缓存空间;当所述回捞缓存空间中新增的回捞订单数量达到设定数量阈值时,将所述回捞缓存空间中新增的回捞订单分别推送至对应地理区域内的所有司机终端。

进一步可选地,所述当前订单状态包括:订单的下单时间或订单的推送次数,以及订单的接单状态。

进一步可选地,根据未被接单的订单的当前订单状态,从所述未被接单的订单中确定符合回捞条件的订单作为回捞订单,包括:若一未被接单的订单的请求状态为继续请求中,且下单时间距离当前时间的时间差大于设定阈值或订单推送次数大于设定次数,则确定所述未被接单的订单为回捞订单。

进一步可选地,所述方法还包括:当所述回捞订单为运输订单时,根据所述回捞订单的对应的运输距离和/或运输种类和/或运输时间,为所述回捞订单设置补贴;将所述回捞订单对应的补贴方式以及补贴金额推送至所述回捞订单对应地理区域内的所有司机终端。

进一步可选地,所述方法还包括:当接收到针对所述回捞订单的抢单请求时,根据发出所述抢单请求的司机终端的合法性以及历史行为,判断发出所述抢单请求的司机终端是否有接单权限;若有接单权限,则将所述回捞订单派发给所述司机终端,并从所述回捞缓存空间中删除所述回捞订单。

本申请实施例还提供一种回捞订单显示方法,包括:接收服务端推送的回捞订单;在消息通知界面上展示所述回捞订单;以及在所述回捞订单的关联区域展示抢单按钮和补贴标识;所述补贴标识指示所述回捞订单对应的补贴方式和补贴金额。

进一步可选地,所述方法还包括:响应于司机对所述抢单按钮的触发操作,向服务端发送抢单请求。

本申请实施例还提供一种用于订单回捞的服务端,包括:回捞订单确定模块,用于根据未被接单的订单的当前订单状态,从所述未被接单的订单中确定符合回捞条件的订单作为回捞订单;回捞订单存储模块,用于将所述回捞订单添加至指定的回捞缓存空间;回捞订单推送模块,用于当所述回捞缓存空间中新增的回捞订单数量达到设定数量阈值时,将所述回捞缓存空间中新增的回捞订单分别推送至对应地理区域内的司机终端。

进一步可选地,所述服务端还包括订单派发模块,用于:当接收到针对所述回捞订单的抢单请求时,根据发出所述抢单请求的司机终端的合法性以及历史行为,判断发出所述抢单请求的司机终端是否有接单权限;若有接单权限,则将所述回捞订单派发给所述司机终端,并从所述回捞缓存空间中删除所述回捞订单。

本申请实施例还提供一种司机终端,包括:接收模块,用于接收服务端推送的回捞订单;显示模块,用于在消息通知界面上展示所述回捞订单;以及在所述回捞订单的关联区域展示抢单按钮和补贴标识;所述补贴标识指示所述回捞订单对应的补贴方式和补贴金额。

本申请实施例中,从未被接单的订单中确定回捞订单,并将回捞订单推送至对应地理区域内的所有司机终端,进而可增加回捞订单在司机眼中出现时长,延长回捞订单的存活周期,有利于提高订单的转化率。

附图说明

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

图1为本申请一实施例提供的订单回捞方法的方法流程图;

图2为本申请另一实施例提供的订单回捞方法的方法流程图;

图3a为本申请一实施例提供的回捞显示方法的方法流程图;

图3b为本申请另一实施例提供的回捞显示方法的方法流程图;

图4a为本申请一实施例提供的用于订单回捞的服务端的结构示意图;

图4b为本申请另一实施例提供的用于订单回捞的服务端的结构示意图;

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

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

具体实施方式

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

在现有技术中,用户通过运输服务预约平台提供的客户端在线下单后,该客户端可将用户的订单发送至运输服务预约平台提供的服务端,并由服务端向开启接单模式的司机终端主动推送订单。这种情况下,只有处于接单模式的司机能够接收到被推送的订单,而其他处于非接单模式的司机无法接收到推送订单。进而,被推送的部分订单可能会遇到没有司机接单造成的推送时间超长或推送轮次过多的情况,导致订单转化率低。

为解决上述缺陷,本申请实施例提供了一种订单回捞方法,其核心在于,从未被接单的订单中确定回捞订单,并将回捞订单推送至对应地理区域内的司机终端,以延长回捞订单的存活周期,增加回捞订单在司机眼中出现时长,并最终实现订单转化率的提升。以下将结合附图,详细说明本申请实施例各实施例提供的技术方案。

图1为本申请一实施例提供的订单回捞方法的方法流程图。如图1所示,该方法包括:

步骤101、根据未被接单的订单的当前订单状态,从所述未被接单的订单中确定符合回捞条件的订单作为回捞订单。

步骤102、将所述回捞订单添加至指定的回捞缓存空间。

步骤103、当所述回捞缓存空间中新增的回捞订单数量达到设定数量阈值时,将所述回捞缓存空间中新增的回捞订单分别推送至对应地理区域内的所有司机终端。

在步骤101中,未被接单的订单,指的是服务端向开启接单模式的司机推送的订单中,没有被司机抢单订单的或抢单后又被司机方取消的订单。回捞订单,指的是未被接单的订单中生存周期结束,又重新捞取回来,并继续延长生存周期的订单。

在步骤102中,回捞缓存空间,用于暂时存放回捞订单,统计新增的回捞订单的数量,并标记存放于此的订单为生存周期需要延长的订单。当一回捞订单被取消或被接单时,则从回捞缓存空间里删除该回捞订单。

在步骤103中,回捞缓存空间中新增的回捞订单,指的是:自上一次将回捞缓存空间中的回捞订单推送至对应地理区域内的所有司机终端之后,新添加至回捞缓存空间中的回捞订单,这部分新增的回捞订单是未被重新推送过的。

对应地理区域内的所有司机终端,指的是与回捞订单有地理关联的区域内的所有司机终端,包括处于抢单模式的司机终端以及非抢单模式的司机终端。在这种方式下,处于非抢单模式的司机终端也能够接收到回捞订单的推送,进而可增大回捞订单被接单的概率,提升订单的转化率。

本实施例中,从未被接单的订单中确定回捞订单,并将回捞订单推送至对应地理区域内的所有司机终端,进而可增加回捞订单在司机眼中出现时长,延长回捞订单的存活周期,有利于提高订单的转化率。

上述实施例对订单回捞方法进行了简单介绍,以下部分将结合附图2,对本申请实施例提供的订单回捞方法的具体实现过程进行详细说明。如图2所示,该方法包括:

步骤201、根据未被接单的订单的下单时间或订单的推送次数,以及订单的接单状态,从所述未被接单的订单中确定符合回捞条件的订单作为回捞订单。

步骤202、将所述回捞订单添加至指定的回捞缓存空间。

步骤203、当所述回捞缓存空间中新增的回捞订单数量达到设定数量阈值时,将所述回捞缓存空间中新增的回捞订单分别推送至对应地理区域内的所有司机终端。

步骤204、当接收到针对所述回捞订单的抢单请求时,根据发出所述抢单请求的司机终端的合法性以及历史行为,判断发出所述抢单请求的司机终端是否有接单权限。

步骤205、在确定所述司机终端有接单权限时,将所述回捞订单派发给所述司机终端,并从所述回捞缓存空间中删除所述回捞订单。

在本实施例中,运输服务预约平台提供的服务端接收到客户端发送的订单请求之后,可根据订单请求,向处于抢单模式的司机终端推送订单。其间,针对同一订单可能会经历多轮次的推送。例如,一个订单在第一轮次的推送中,没有被接单,则进入第二轮次的推送,若第二次的推送中,仍然没有被接单,则可能会进入第三轮次的推送。通常,不同的推送轮次对应不同的地理范围,每一次推送对应的地理范围相比于前一次有所增大,以使更多处于抢单模式的司机终端接到订单推送,增加订单转化率。

例如,第一轮次的推送,可将订单推送至以订单始发地为中心的5公里半径对应的地理范围内的所有处于抢单模式的司机终端。第二轮次的推送,可将订单推送至以订单始发地为中心的10公里半径对应的地理范围内的所有处于抢单模式的司机终端。相应的,后续每一次推送对应的地理范围可比前一次适当增加,增加幅度可视城市大小而定,不再赘述。

用户通过客户端发起的订单的生存周期有如下的结束方式,一种是用户主动取消订单,订单的请求状态变为结束状态,则订单生存周期结束;另一种是,用户未取消订单,订单的请求状态为继续请求中,但是在经历多轮次或特定时长的推送后仍然无人接单,则订单的生存周期随着最后一轮推送的结束而结束或随着推送时长上限的到达而结束。

基于上述记载,在步骤201中,从未被接单的订单中确定符合回捞条件的订单作为回捞订单时,可设定回捞条件为:该订单的请求状态为继续请求中,且下单时间距离当前时间的时间差大于设定阈值或订单推送次数大于设定次数。

例如,未被接单的订单的请求状态为继续请求中,且下单时间距离当前时间的时间差大于设定阈值,则可视为订单的生存周期已结束。再例如,未被接单的订单的请求状态为继续请求中,且推送次数已经大于设定次数时,则可视为订单的生存周期已结束。可选的,在实际中,设定阈值,可以为2分钟或5分钟,设定次数可以为3个轮次或5个轮次。本步骤中,可将生存周期结束的订单作为回捞订单,以通过回捞的方式延长这些订单的生存周期。

在步骤202中,可选的,回捞缓存空间中的每一回捞订单可分别对应一个地理区域标识,该地理区域标识可根据回捞订单包含的始发地信息确定。例如,某一回捞缓存空间中,不同的回捞订单对应的地理区域标识可以为地理区域a、地理区域b或地理区域c等等,以便于在后续的步骤中,根据新增的回捞订单对应的地理区域标识,将新增的回捞订单分别推送至对应的地理区域内所有的司机终端。

在另一种可选的实施方式中,不同的回捞缓存空间可分别对应不同的地理区域标识,同一个回捞缓存空间中的回捞订单对应相同的地理区域。例如,第一、第二以及第三回捞缓存空间可分别对应地理区域x、地理区域y以及地理区域z。其中,第一回捞缓存空间中的回捞订单对应的地理区域均为x,第二回捞缓存空间中的回捞订单对应的地理区域均为y,第三回捞缓存空间中的回捞订单对应的地理区域均为z。可选的,在实际应用中,可建立不同城市对应的回捞缓存空间,并将属于同一城市的回捞订单添加至该城市对应的回捞缓存空间中,以提升后台订单数据的管理效率。

在步骤203中,回捞订单对应的地理区域,可以是回捞订单包含的始发地所属的城市、县或区等。将回捞缓存空间中新增的回捞订单分别推送至对应地理区域内的所有司机终端,有如下可行的方式:

在一种可行的实施方式中,设定数量阈值=1。也就是说,回捞缓存空间中,每新增一个回捞订单,则启动一次推送,将该新增的回捞订单推送至该新增的回捞订单对应的地理区域内的所有司机终端。这种方式的实时性较高,用户体验良好。

另一种可选的方式为,设定数量阈值=n,n>1。在这种实施方式下,回捞缓存空间中,每积累n个回捞订单,则启动一次推送,将新增的n的回捞订单分别推送至对应的地理区域内的所有司机终端。其中,n为经验值,例如,在订单密度较大的城市,n可取10,在订单密度较小的城市,n可取5。这种方式的优势在于,推送频率低,降低了对服务端产生的压力。

基于步骤202中针对回捞订单与地理区域标识的记载,将回捞缓存空间中新增的回捞订单分别推送至对应地理区域内的所有司机终端,可由如下不同方式实现:其一,针对同一回捞缓存空间中的每一个回捞订单分别对应一个地理区域标识的情况,服务端可逐一读取该回捞缓存空间中的新增回捞订单对应的地理区域标识,并将其推送至该地理区域标识指示的地理区域内的所有司机终端。

其二,针对不同的回捞缓存空间分别对应不同的地理区域标识,同一个回捞缓存空间中的回捞订单对应相同的地理区域的情况,服务端可直接根据回捞缓存空间的地理区域标识,将该回捞缓存空间中新增的所有回捞订单推送至该地理区域标识指示的地理区域内的所有司机终端。承接上述例子,服务端可将第一回捞缓存空间中新增的回捞订单均推送至x区域内的所有司机终端,将第二回捞缓存空间中新增的回捞订单均推送至y区域内的所有司机终端,相应的,将第三回捞缓存空间中新增的回捞订单均被推送至z区域内的所有司机终端。这种实施方式下,回捞订单的推送效率更高。

将回捞缓存空间中新增的回捞订单分别推送至对应地理区域内的所有司机终端之后,司机终端会展示回捞订单,司机可根据实际情况通过个人的司机终端进行抢单。司机终端接收到司机的抢单操作后,可向服务端发送抢单请求。

在步骤204中,服务端接收到司机终端发送的抢单请求之后,可进一步判断发出所述抢单请求的司机终端是否有接单权限,以确保订单能够以较高的质量完成。可选的,服务端可首先判断发出抢单请求的司机终端的合法性,具体可表现为:判断该司机终端是否完成注册、审核资料上传以及是否缴纳保证金等。可选的,在确定该司机终端的具有合法性之后,可进一步根据司机终端的历史行为,例如遭遇投诉情况、被惩罚情况、恶意取消订单等情况,判断司机是否表现良好,满足接单条件。

本实施例中,根据未被接单的订单的下单时间或订单的推送次数从未被接单的订单中确定回捞订单,可实现回捞订单的精准选取。基于此,将回捞订单推送至对应地理区域内的所有司机终端,并在接到抢单请求时对发出抢单请求的司机终端的接单权限进行判断,可在提升订单转化率的同时,确保回捞订单具有较高的完成质量。

在上述实施例中,服务端在选取回捞订单之后,还可为回捞订单设置相应的补贴,以激励司机接单,进而提高回捞订单的接单率。在步骤203中,服务端除了向司机终端推送回捞缓存空间中的回捞订单之外,还可向司机终端推送回捞订单对应的补贴方式以及补贴金额。其中,补贴方式可包括:发放红包、优惠券或奖励金等方式。补贴金额可根据订单的实际情况进行设置,例如,当回捞订单为运输订单时,可根据回捞订单的对应的运输距离和/或运输种类和/或运输时间,为回捞订单设置补贴金额。若运输距离较远,或花费的运输时间较长,则可设置较大的补贴金额。再例如,运输生鲜类对时效性要求较高的货物时,可设置较大的补贴金额,以增加司机的积极性。

上述实施例记载了运输服务预约平台提供的服务端进行订单回捞的方法,以下部分将结合附图对运输服务预约平台提供的司机终端显示回捞订单的方法进行说明。图3a为本申请一实施例提供的回捞显示方法的方法流程图。如图3a所示,该方法包括:

步骤301、接收服务端推送的回捞订单。

步骤302、在消息通知界面上展示所述回捞订单;以及在所述回捞订单的关联区域展示抢单按钮和补贴标识;所述补贴标识指示所述回捞订单对应的补贴方式和补贴金额。

在本实施例中,消息通知界面,可以是司机终端提供的信息展示频道的一个页面,也可以是司机终端的系统通知栏。回捞订单的关联区域,是消息通知页面上的一个区域,可位于回捞订单展示区的周围,例如,可以在回捞订单展示区的右边或者下边或其他位置等。

在回捞订单的关联区域,可展示抢单按钮,司机可触发抢单按钮执行抢单操作,无需再跳转至抢单页面进行抢单,十分便捷。除此之外,在回捞订单的关联区域,可展示补贴标识,例如红包、优惠券或奖励金的图片标识或者字符标识等,补贴标识上还可显示补贴金额,以激励司机主动接单。待有司机接单并且订单完成后结算时,将相应的补贴发放给司机。可选的,当司机终端接收到多个回捞订单时,多个回捞订单在司机终端可根据订单起始地点与司机之间的距离进行降序排列,或按照补贴金额的多少进行降序排列,以便于司机进行选择。

进一步可选地,如图3b所示,本申请实施例提供的回捞订单显示方法还包括:步骤303、响应于司机对所述抢单按钮的触发操作,向服务端发送抢单请求。进而,服务端可在接受到抢单请求后,对司机端是否具有接单权限进行验证,并在验证通过后,将订单派发给该司机终端。

本实施例中,司机终端在接收到服务端推送的回捞订单后,展示回捞订单,以延长回捞订单在司机眼中出现的时长,有利于提升运输服务平台的订单转化率。除此之外,在回捞订单的关联区域展示接收到的回捞订单对应的补贴方式以及补贴金额,有利于提高司机接单的积极性。

需要说明的是,上述实施例所提供方法的各步骤的执行主体均可以是同一设备,或者,该方法也由不同设备作为执行主体。比如,步骤201至步骤203的执行主体可以为设备a;又比如,步骤201和202的执行主体可以为设备a,步骤203的执行主体可以为设备b;等等。

另外,在上述实施例及附图中的描述的一些流程中,包含了按照特定顺序出现的多个操作,但是应该清楚了解,这些操作可以不按照其在本文中出现的顺序来执行或并行执行,操作的序号如101、102等,仅仅是用于区分开各个不同的操作,序号本身不代表任何的执行顺序。另外,这些流程可以包括更多或更少的操作,并且这些操作可以按顺序执行或并行执行。需要说明的是,本文中的“第一”、“第二”等描述,是用于区分不同的消息、设备、模块等,不代表先后顺序,也不限定“第一”和“第二”是不同的类型。

图4a为本申请一实施例提供的用于订单回捞的服务端的结构示意图。如图4a所述,该服务端包括:回捞订单确定模块401、回捞订单存储模块402以及回捞订单推送模块403。

其中,回捞订单确定模块401,用于根据未被接单的订单的当前订单状态,从所述未被接单的订单中确定符合回捞条件的订单作为回捞订单;回捞订单存储模块402,用于将所述回捞订单添加至指定的回捞缓存空间;回捞订单推送模块403,用于当所述回捞缓存空间中新增的回捞订单数量达到设定数量阈值时,将所述回捞缓存空间中新增的回捞订单分别推送至对应地理区域内的所有司机终端。

进一步可选地,所述当前订单状态包括:订单的下单时间或订单的推送次数,以及订单的接单状态。

进一步可选地,回捞订单确定模块401具体用于:若一未被接单的订单的请求状态为继续请求中,且下单时间距离当前时间的时间差大于设定阈值或订单推送次数大于设定次数,则确定所述未被接单的订单为回捞订单。

进一步可选地,回捞订单推送模块403具体用于:当所述回捞订单为运输订单时,根据所述回捞订单的对应的运输距离和/或运输种类和/或运输时间,为所述回捞订单设置补贴;将所述回捞订单对应的补贴方式以及补贴金额推送至所述回捞订单对应地理区域内的所有司机终端。

进一步可选地,如图4b所示,本申请实施例所提供的服务端还包括订单派发模块404,用于:当接收到针对所述回捞订单的抢单请求时,根据发出所述抢单请求的司机终端的合法性以及历史行为,判断发出所述抢单请求的司机终端是否有接单权限;若有接单权限,则将所述回捞订单派发给所述司机终端,并从所述回捞缓存空间中删除所述回捞订单。上述订单回捞服务端可执行图1以及图2对应的实施例所提供的订单回捞方法,具备执行方法相应的功能模块和有益效果。未在本实施例中详尽描述的技术细节,可参见本申请实施例所提供的方法,不再赘述。

图5a为本申请一实施例提供的司机终端的结构示意图。如图5a所示,该终端包括:接收模块501以及显示模块502。

其中,接收模块501,用于接收服务端推送的回捞订单;显示模块502,用于在消息通知界面上展示所述回捞订单;以及在所述回捞订单的关联区域展示抢单按钮和补贴标识;所述补贴标识指示所述回捞订单对应的补贴方式和补贴金额。

进一步可选地,如图5b所示,该司机终端还包括:抢单模块503,用于响应于司机对所述抢单按钮的触发操作,向服务端发送抢单请求。

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

其中,应当理解,本申请实施例提供的司机终端与服务端之间可以是无线或有线网络连接。在本实施例中,若司机终端或服务端通过移动网络通信连接,该移动网络的网络制式可以为2g(gsm)、2.5g(gprs)、3g(wcdma、td-scdma、cdma2000、utms)、4g(lte)、4g+(lte+)、wimax等中的任意一种。

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

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

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

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

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

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

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

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

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

当前第1页1 2 
网友询问留言 已有0条留言
  • 还没有人留言评论。精彩留言会获得点赞!
1