本发明实施例涉及互联网技术领域中的网约车技术领域，尤其涉及一种交通工具预定方法和装置。
背景技术：
终端叫车是指终端利用叫车软件向车主发送叫车请求的一种打车方式。
在实际应用过程中，当可用车资源较少时，用户通过终端叫车可能不会及时叫到车辆，且在一定时间后，如果还是没有叫到车辆，一般情况下用户会再次通过终端发起叫车，如此反复，导致用户会频繁地触发终端叫车，直至叫到车辆为止。
然而，终端频繁地向服务器发送叫车请求，会长时间占用大量的网络资源，造成网络资源消耗较大。
技术实现要素：
有鉴于此，本发明实施例提供一种交通工具预定方法和装置，以解决现有终端叫车方法中，终端频繁地向服务器发送叫车请求，会长时间占用大量的网络资源，造成网络资源消耗较大的问题。技术方案如下：
基于本发明实施例的一方面，本发明实施例提供一种交通工具预定方法，包括：
发送用于预定交通工具的预定请求，所述预定请求中携带用于预定交通工具的代价值；
判断在满足预设条件下是否接收到预定成功响应；
如果在满足预设条件下没有接收到所述预定成功响应，增加所述代价值，得到增加后的代价值；
发送携带所述增加后的代价值的预定请求。
进一步的，所述代价值为预定方需要支付的代价值，或者，接受预定方将要得到的代价值。
进一步的，所述代价值包括金额、积分、信誉度值中的一个或多个。
进一步的，增加所述代价值，包括：
按照预设规则增加预设数值的代价值。
进一步的，在增加所述代价值前，所述方法还包括：
判断本次预定交通工具累积增加的代价值的和是否达到第一预设代价值上限；
当未达到时，执行所述增加所述代价值的步骤。
进一步的，在增加所述代价值之后，在发送携带所述增加后的代价值的预定请求之前，所述方法还包括：
判断本次预定交通工具累积增加的代价值的和是否达到第二预设代价值上限；
当未达到时，执行所述发送携带所述增加后的代价值的预定请求的步骤。
进一步的，所述判断在满足预设条件下是否接收到预定成功响应，包括：
判断在发送所述预定请求后的预设时间内是否接收到预定成功响应；或，
判断在所述预定请求对应的被预定方通知数量达到预设数量时，是否接收到预定成功响应；或，
判断在发送所述预定请求后的预设时间内，且所述预定请求对应的被预定方通知数量达到预设数量时，是否接收到预定成功响应。
基于本发明实施例的另一方面，本发明实施例提供一种交通工具预定装置，包括：
发送单元，用于发送用于预定交通工具的预定请求，所述预定请求中携带用于预定交通工具的代价值；
第一判断单元，用于判断在满足预设条件下是否接收到预定成功响应；
调整单元，用于在所述第一判断单元判断在满足预设条件下没有接收到所述预定成功响应时，增加所述代价值，得到增加后的代价值；
所述发送单元还用于，发送携带所述增加后的代价值的预定请求。
进一步的，所述代价值为预定方需要支付的代价值，或者，接受预定方将要得到的代价值。
进一步的，所述代价值包括金额、积分、信誉度值中的一个或多个。
进一步的，所述调整单元具体用于，按照预设规则增加预设数值的代价值。
进一步的，所述装置还包括：
第二判断单元，用于判断本次预定交通工具累积增加的代价值的和是否达到第一预设代价值上限；
所述调整单元具体用于，当所述第二判断单元判断本次预定交通工具累积增加的代价值的和未达到第一预设代价值上限时，增加所述代价值。
进一步的，所述装置还包括：
第三判断单元，用于判断本次预定交通工具累积增加的代价值的和是否达到第二预设代价值上限；
所述发送单元具体用于，当所述第三判断单元判断本次预定交通工具累积增加的代价值的和未达到第二预设代价值上限时，发送携带所述增加后的代价值的预定请求。
进一步的，所述第一判断单元具体用于，判断在发送所述预定请求后的预设时间内是否接收到预定成功响应；或，
判断在所述预定请求对应的被预定方通知数量达到预设数量时，是否接收到预定成功响应；或，
判断在发送所述预定请求后的预设时间内，且所述预定请求对应的被预定方通知数量达到预设数量时，是否接收到预定成功响应。
本发明实施例提供的交通工具预定方法中，发送用于预定交通工具的预定请求，所述预定请求中携带用于预定交通工具的代价值，判断在满足预设条件下是否接收到预定成功响应；如果在满足预设条件下没有接收到所述预定成功响应，增加所述代价值，得到增加后的代价值，并发送携带所述增加后的代价值的预定请求。本发明实施例在满足预设条件却没有接收到预定成功响应的情况下，通过自动增加代价值，提高了交通工具的预定成功率，能够在一定程度上减少服务请求的发送个数，减少了网络资源的占用率，提高了网络资源的利用率。
附图说明
为了更清楚地说明本发明实施例或现有技术中的技术方案，下面将对实施例或现有技术描述中所需要使用的附图作简单地介绍，显而易见地，下面描述中的附图仅仅是本发明实施例的实施例，对于本领域普通技术人员来讲，在不付出创造性劳动的前提下，还可以根据提供的附图获得其他的附图。
图1为本发明实施例提供的一种交通工具预定方法的流程图；
图2为本发明实施例提供的一种交通工具预定方法的另一种流程图；
图3为本发明实施例提供的一种交通工具预定装置的结构示意图；
图4为本发明实施例提供的一种交通工具预定装置的另一种结构示意图；
图5为本发明实施例提供的一种交通工具预定装置的再一种结构示意图。
具体实施方式
下面将结合本发明实施例中的附图，对本发明实施例中的技术方案进行清楚、完整地描述，显然，所描述的实施例仅仅是本发明实施例一部分实施例，而不是全部的实施例。基于本发明实施例中的实施例，本领域普通技术人员在没有做出创造性劳动前提下所获得的所有其他实施例，都属于本发明实施例保护的范围。
请参阅图1，其示出了本发明实施例提供的一种交通工具预定方法的流程图，该方法应用于预定方，所述预定方可具体为智能手机、掌上电脑等能够发起预定请求的终端，所述方法具体包括：
步骤101，发送用于预定交通工具的预定请求，所述预定请求中携带用于预定交通工具的代价值。
本发明实施例步骤101可以是终端向服务器发送预定请求，也可以是终端向终端发送预定请求，为了便于描述，本发明实施例以终端向服务器发送预定请求的应用场景为例进行说明，当然本发明实施例对于方案的具体应用场景不做限定。
本发明实施例中，预定请求中携带有用于预定交通工具的代价值，该代价值可以为预定方需要支付的代价值，或者，接受预定方将要得到的代价值，具体例如，代价值为预定方需要支付的金额、积分值、信誉度值中的一个或多个，或代价值为接受预定方将要得到的金额、积分值、信誉度值中的一个或多个。本发明实施例中，接受预定方可以具体为私家车、出租车等。
步骤102，判断在满足预设条件下是否接收到预定成功响应。如果接收到，执行步骤103，如果没有接收到，执行步骤104。
其中，预定成功响应表示的是接受预定方依据预定请求确认交通工具预定成功。当预定方在满足预设条件下接收到预定成功响应，表示预定方发起的预定请求被成功响应，交通工具预定成功。而如果预定方在满足预设条件下没有接收到预定成功响应，则表示当前没有接受预定方接受预定请求，交通工具预定失败。
具体在本发明实施例中，步骤102可以采用如下方式实现：
方案一：判断在发送所述预定请求后的预设时间内是否接收到预定成功响应。
具体在本实施例中，例如预设时间为2分钟，当终端向服务器发送预定请求后开始计时，如果在2分钟内接收到服务器返回的预定成功响应，表明当前有接受预定方接受了预定请求，交通工具预定过程结束。而如果在2分钟内并没有接收到服务器返回的预定成功响应，则执行步骤104。
本实施例中的预设时间还可以为1分钟、3分钟、5分钟等，其根据用户需求灵活设置。
方案二：判断在所述预定请求对应的被预定方通知数量达到预设数量时，是否接收到预定成功响应。
具体在本实施例中，以被预定方具体为出租车为例，当服务器接收到终端发送的预定请求后，会以广播的方式将预定请求发送到各出租车。当服务器通知出租车的通知数量达到预设数量，例如预设数量为100时，判断是否有出租车接受该预定请求。如果有出租车接受该预定请求，便向预定方返回预定成功响应。此外，本实施例还可以为，每当服务器成功将预定请求发送至一辆出租车后，会把该成功发送的消息告知终端，由此终端根据服务器返回的成功发送的消息可以获知当前有多少辆出租车已成功接收到自己的预定请求。仍以预设数量为100为例，当终端判断服务器返回的车辆的通知数量等于100时，表明当前已有100辆出租车成功接收到预定请求，此时如还没有接收到服务器返回的预定成功响应，则继续执行步骤104。而如果在服务器返回的车辆的通知数量小于100时就接收到服务器返回的预定成功响应，则交通工具预定过程结束。
本实施例中的预设数量还可以为30、50、80、120等，其根据用户需求灵活设置。
方案三：判断在发送所述预定请求后的预设时间内，且所述预定请求对应的被预定方通知数量达到预设数量时，是否接收到预定成功响应。
方案三同时考虑了预设时间和被预定方通知数量两个条件，当在终端发送预定请求后的预设时间内，且所述预定请求对应的被预定方通知数量达到预设数量时，仍没有接收到预定成功响应，表示在满足预设条件下没有接收到预定成功响应，此时执行步骤104。
步骤103，确定交通工具预定成功。
步骤104，增加所述代价值，得到增加后的代价值。
其中，增加代价值可以具体采用如下方式实现：按照预设规则增加预设数值的代价值。
具体地，当代价值为金额时，在所述金额的基础上，按照第一预设规则增加预设金额；
当代价值为积分时，在所述积分的基础上，按照第二预设规则增加预设积分数；
当代价值为信誉度值时，在所述信誉度值的基础上，按照第三预设规则增加预设信誉度值。
在本发明实施例中，如果在满足预设条件下终端没有接收到服务器返回的预定成功响应，则增加预定请求中携带的用于预定交通工具的代价值。其中，第一预设规则、第二预设规则、第三预设规则可根据用户的实际需求由用户灵活设置。以金额为例，按照第一预设规则增加预设金额可以包括：依次增加的预设金额分别为5元、7元、10元、20元等，或，按照基准值的百分比，如2％、3％、5％、10％等递增的方式增加预设金额。
步骤105，发送携带所述增加后的代价值的预定请求。
为了实现对本发明实施例更清楚地说明，现以预定出租车、代价值具体为金额为例进行说明，如图2所示，包括：
步骤201，终端发送用于预定出租车的预定请求，所述预定请求中携带用于预定出租车的基准金额。
在本发明实施例实际应用过程中，用户利用终端预定出租车时，首先需要在终端上输入起始地和目的地，进而终端根据用户输入的起始地和目的地，输出从所述起始地到所述目的地的基准金额。通常该基准金额是叫车服务公司提供的基准预测价格。在实施例中，假设基准金额为30元。
用户在查看终端输出的基准金额后，确认进行叫车，便触发终端上的“确认叫车”按钮，此时终端便接收到用户输入的确认叫车指令，并基于该确认叫车指令，将携带有所述基准金额的预定请求发送至服务器。其中，终端上的“确认叫车”按钮可以是一物理按钮，也可以是虚拟按键。
步骤202，终端判断在满足预设条件下是否接收到服务器返回的预定成功响应。如果接收到，执行步骤203，如果没有接收到，执行步骤204。
步骤203，确定出租车预定成功，叫车过程结束。
步骤204，在所述基准金额的基础上，按照第一预设规则增加预设金额，得到增加后的金额。
其中第一预设规则具体为每次增加5元。
步骤205，发送携带所述增加后的金额的预定请求。
终端将携带增加预设金额5元后的金额的预定请求发送至服务器，进而返回步骤202。
本实施例中，在终端向服务器发送包括基准金额30元的预定请求后，终端开始计时。在2分钟内有出租车接单，服务器将向终端返回预定成功响应，此时出租车预定成功，叫车过程结束。而如果在2分钟内没有出租车接单，则终端在基准金额30元的基础上自动增加5元，得到加价后的金额35元，并将携带有35元的预定请求重新发送至服务器。
在将携带有35元的预定请求重新发送至服务器后，终端再次重新开始计时。在2分钟内有出租车接单，服务器向终端返回预定成功响应，此时叫车成功，叫车过程结束。而如果在2分钟内仍没有出租车接单，则终端在用户当前的出价价格35元的基础上再自动增加5元，得到加价后的金额40元，并将携带有40元的预定请求再次重新发送至服务器。
以此类推，每当终端完成一次自动加价，并将携带有加价后金额的预定请求重新发送至服务器后，终端再次重新开始计时。在预设时间2分钟内有出租车接单，则结束叫车过程，在预设时间2分钟内没有出租车接单，则在用户当前的出价价格的基础上再自动增加预设金额，并将携带有增加预设金额后的金额的预定请求再次重新发送至服务器，如此反复，直至有出租车接单，终端接收到服务器返回的预定成功响应，结束叫车过程，同时也结束加价过程。
因此应用本发明实施例提供的交通工具预定方法，终端发送用于预定交通工具的预定请求，所述预定请求中携带用于预定交通工具的代价值，判断在满足预设条件下是否接收到预定成功响应；如果在满足预设条件下没有接收到所述预定成功响应，增加所述代价值，得到增加后的代价值，并发送携带所述增加后的代价值的预定请求。本发明实施例在满足预设条件却没有接收到预定成功响应的情况下，通过自动增加代价值，提高了交通工具的预定成功率，能够在一定程度上减少服务请求的发送个数，减少了网络资源的占用率，提高了网络资源的利用率。此外，本发明实施例实现了终端的自动加价功能，无需用户手动加价，简化了用户操作，智能化高。
在上述实施例的基础上，申请人进一步发现，如果终端发送的预定请求长时间没有被响应的话，终端会一直反复执行增加代价值的操作，最终导致增加后的代价值过大，超出用户的实际支付意愿。
由此，本发明实施例进一步提出，在执行步骤104之前还可以包括：
步骤105，判断本次预定交通工具累积增加的代价值的和是否达到第一预设代价值上限。如果大于，执行步骤106，如果不大于，再执行步骤104。
步骤106，停止增加代价值的操作。
或，在执行步骤104之后，执行步骤105之前，还可以包括：
步骤107，判断本次预定交通工具累积增加的代价值的和是否达到第二预设代价值上限。如果大于，执行步骤108，如果不大于，再执行步骤104。
步骤108，停止增加代价值的操作。
其中，第一预设代价值上限和第二预设代价值上限可由用户灵活设置，例如具体为20元、40元、50元等。
仍以前述每次增加5元为例继续说明，例如第一预设代价值上限为22元，,当前终端第4次增加金额后，其累积增加的金额等于20元。当终端执行第5次加价时，首先判断本次预定出租车累积增加的金额的和，即此时在增加5元后的累加增加的金额25元是否达到第一预设代价值上限22元。显然，本次在增加5元后的累加增加的金额25元已大于第一预设代价值上限22元，此时终端的第5次加价操作被停止。同时，整个叫车过程也可随其停止。当然本发明实施例也可选择就以第4次加价后的金额20元继续向服务器定时或不定时发送。
或，仍以前述每次增加5元为例继续说明，例如第二预设代价值上限为23元，当前终端第5次增加金额后，其累积增加的金额等于25元。当终端发送携带有增加后的金额25元的预定请求之前，首先判断本次预定出租车累积增加的金额的和25元是否达到第二预设代价值上限23元。显然，本次在增加5元后的累加增加的金额25元已大于第二预设代价值上限23元，此时终端的第5次加价操作被取消。同时，整个叫车过程也可随其停止。当然本发明实施例也可选择就以第4次加价后的金额20元继续向服务器定时或不定时发送。
本发明实施例中的终端可以预先设置自动加价模式，当终端开启自动加价模式后，才可实现上述实施例，因此本发明实施例还可以在步骤101之前包括：
步骤100，开启终端的自动加价模式。
当用户点击终端上对应开启自动加价模式的按钮或链接后，终端便开启自动加价模式。
基于前文本发明实施例提供的一种交通工具预定方法，本发明实施例还提供一种交通工具预定装置，如图3所示，包括：
发送单元100，用于发送用于预定交通工具的预定请求，所述预定请求中携带用于预定交通工具的代价值；
第一判断单元200，用于判断在满足预设条件下是否接收到预定成功响应；
调整单元300，用于在所述第一判断单元200判断在满足预设条件下没有接收到所述预定成功响应时，增加所述代价值，得到增加后的代价值；
所述发送单元100还用于，发送携带所述增加后的代价值的预定请求。
本发明实施例中，代价值为预定方需要支付的代价值，或者，接受预定方将要得到的代价值。所述代价值包括金额、积分、信誉度值中的一个或多个。
优选的，本发明实施例中的调整单元300具体用于，按照预设规则增加预设数值的代价值。
作为本发明实施例的一个实施例，本发明实施例提供的交通工具预定装置还可以包括，如图4所示：
第二判断单元400，用于判断本次预定交通工具累积增加的代价值的和是否达到第一预设代价值上限；
此时所述调整单元300具体用于，当所述第二判断单元400判断本次预定交通工具累积增加的代价值的和未达到第一预设代价值上限时，增加所述代价值。
作为本发明实施例的另一个实施例，本发明实施例提供的交通工具预定装置还可以包括，如图5所示：
第三判断单元500，用于判断本次预定交通工具累积增加的代价值的和是否达到第二预设代价值上限；
此时所述发送单元100具体用于，当所述第三判断单元500判断本次预定交通工具累积增加的代价值的和未达到第二预设代价值上限时，发送携带所述增加后的代价值的预定请求。
在本发明实施例中，所述第一判断单元200具体用于，判断在发送所述预定请求后的预设时间内是否接收到预定成功响应；或，
判断在所述预定请求对应的被预定方通知数量达到预设数量时，是否接收到预定成功响应；或，
判断在发送所述预定请求后的预设时间内，且所述预定请求对应的被预定方通知数量达到预设数量时，是否接收到预定成功响应。
需要说明的是，本说明书中的各个实施例均采用递进的方式描述，每个实施例重点说明的都是与其他实施例的不同之处，各个实施例之间相同相似的部分互相参见即可。对于装置类实施例而言，由于其与方法实施例基本相似，所以描述的比较简单，相关之处参见方法实施例的部分说明即可。
最后，还需要说明的是，在本文中，诸如第一和第二等之类的关系术语仅仅用来将一个实体或者操作与另一个实体或操作区分开来，而不一定要求或者暗示这些实体或操作之间存在任何这种实际的关系或者顺序。而且，术语“包括”、“包含”或者其任何其他变体意在涵盖非排他性的包含，从而使得包括一系列要素的过程、方法、物品或者设备不仅包括那些要素，而且还包括没有明确列出的其他要素，或者是还包括为这种过程、方法、物品或者设备所固有的要素。在没有更多限制的情况下，由语句“包括一个……”限定的要素，并不排除在包括所述要素的过程、方法、物品或者设备中还存在另外的相同要素。
以上对本发明实施例所提供的一种交通工具预定方法和装置进行了详细介绍，本文中应用了具体个例对本发明实施例的原理及实施方式进行了阐述，以上实施例的说明只是用于帮助理解本发明实施例的方法及其核心思想；同时，对于本领域的一般技术人员，依据本发明实施例的思想，在具体实施方式及应用范围上均会有改变之处，综上所述，本说明书内容不应理解为对本发明实施例的限制。