CN108009841A - 网约车服务请求处理方法、装置和服务器 - Google Patents
网约车服务请求处理方法、装置和服务器 Download PDFInfo
- Publication number
- CN108009841A CN108009841A CN201710195830.8A CN201710195830A CN108009841A CN 108009841 A CN108009841 A CN 108009841A CN 201710195830 A CN201710195830 A CN 201710195830A CN 108009841 A CN108009841 A CN 108009841A
- Authority
- CN
- China
- Prior art keywords
- order
- queue
- estimated price
- starting point
- user terminal
- Prior art date
- Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
- Pending
Links
Classifications
-
- G—PHYSICS
- G06—COMPUTING OR CALCULATING; COUNTING
- G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
- G06Q30/00—Commerce
- G06Q30/06—Buying, selling or leasing transactions
- G06Q30/0601—Electronic shopping [e-shopping]
- G06Q30/0633—Managing shopping lists, e.g. compiling or processing purchase lists
- G06Q30/0635—Managing shopping lists, e.g. compiling or processing purchase lists replenishment orders; recurring orders
-
- G—PHYSICS
- G06—COMPUTING OR CALCULATING; COUNTING
- G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
- G06Q10/00—Administration; Management
- G06Q10/06—Resources, workflows, human or project management; Enterprise or organisation planning; Enterprise or organisation modelling
- G06Q10/063—Operations research, analysis or management
- G06Q10/0631—Resource planning, allocation, distributing or scheduling for enterprises or organisations
-
- G—PHYSICS
- G06—COMPUTING OR CALCULATING; COUNTING
- G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
- G06Q30/00—Commerce
- G06Q30/02—Marketing; Price estimation or determination; Fundraising
- G06Q30/0283—Price estimation or determination
-
- G—PHYSICS
- G06—COMPUTING OR CALCULATING; COUNTING
- G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
- G06Q2240/00—Transportation facility access, e.g. fares, tolls or parking
Landscapes
- Business, Economics & Management (AREA)
- Engineering & Computer Science (AREA)
- Human Resources & Organizations (AREA)
- Strategic Management (AREA)
- Economics (AREA)
- Development Economics (AREA)
- Entrepreneurship & Innovation (AREA)
- General Physics & Mathematics (AREA)
- Marketing (AREA)
- Theoretical Computer Science (AREA)
- Physics & Mathematics (AREA)
- General Business, Economics & Management (AREA)
- Finance (AREA)
- Accounting & Taxation (AREA)
- Game Theory and Decision Science (AREA)
- Educational Administration (AREA)
- Tourism & Hospitality (AREA)
- Quality & Reliability (AREA)
- Operations Research (AREA)
- Management, Administration, Business Operations System, And Electronic Commerce (AREA)
- Traffic Control Systems (AREA)
Abstract
本发明提出了一种网约车服务请求处理方法、装置和服务器，其中，网约车服务请求处理方法包括：从一个用户终端接收至少包括一个起点和一个终点的网约车服务请求，生成包括根据起点和终点计算的第一预估价格的订单并发送至用户终端；从用户终端接收到确认订单指令后，将订单加入到第一队列中排队等待分配服务车辆；若满足预定条件，要求用户终端确认是否根据高于第一预估价格的第二预估价格执行订单；若用户终端确认根据第二预估价格执行订单，则将订单加入到第二队列中排队等待分配服务车辆，否则保持订单在第一队列中排队等待分配服务车辆。通过本发明的技术方案，可以在最大程度上满足用户的出行需求。
Description
技术领域
本发明涉及网约车技术领域，具体而言，涉及基于网约车服务请求处理方法、网约车服务请求处理装置和服务器。
背景技术
网约车给用户的出行带来了极大的便捷，但是，在上下班高峰期供给与需求极度不平衡情况下，出现了先发单的用户比后发单的用户先被响应订单，加价的订单也无法保证真的被应答，而不加价的用户无法发单的问题。而出行是没有伪需求的，现有的技术方案无法满足用户的出行需求。
因此，如何最大程度上满足用户的出行需求成为亟待解决的技术问题。
发明内容
本发明正是基于上述问题，提出了一种新的技术方案，可以解决现有技术方案无法满足用户的出行需求的技术问题。
有鉴于此，本发明的第一方面提出了一种网约车服务请求处理方法，包括：从一个用户终端接收至少包括一个起点和一个终点的网约车服务请求，生成包括根据所述起点和所述终点计算的第一预估价格的订单并发送至所述用户终端；从所述用户终端接收到确认订单指令后，将所述订单加入到第一队列中排队等待分配服务车辆，所述第一队列按照收到确认订单指令的时间先后顺序排列；若满足预定条件，要求所述用户终端确认是否根据高于所述第一预估价格的第二预估价格执行所述订单；若所述用户终端确认根据所述第二预估价格执行所述订单，则将所述订单加入到第二队列中排队等待分配服务车辆，否则保持所述订单在所述第一队列中排队等待分配服务车辆，其中，为所述第二队列分配的车辆数与所述第二队列中待执行订单数的比值大于为所述第一队列分配的车辆数与所述第一队列中待执行订单数的比值。
在该技术方案中，在将订单加入到第一队列中排队等待分配服务车辆之后，用户可以根据自己的实际出行需求选择是否高于第一预估价格的第二预估价格执行订单。若用户此时比较着急用车，则可以选择高于第一预估价格的第二预估价格执行订单，这样将订单加入到第二队列中排队，由于为第二队列分配的车辆数与第二队列中待执行订单数的比值大于为第一队列分配的车辆数与第一队列中待执行订单数的比值，即为第二队列分配的车辆资源优于为第一队列分配的车辆资源，从而可以为着急用车的订单快速派车。若用户此时不着急用车，则可以选择保持第一预估价格执行订单，订单也就继续在第一队列中排队。因此，通过加价执行订单的方式不仅能够提升优先排队的门槛，抑制需求，提升司机的接单意愿，还避免排队过长，保证约车订单能够被快速应答，从而满足了用户在不同情况下的出行需求。
在上述技术方案中，优选地，所述预定条件包括：所述起点所在的区域内排队等待分配服务车辆的订单数比可用车辆数多设定阈值和/或当前时间在预设时间范围内。
在该技术方案中，当订单的起点所在的区域内排队等待分配服务车辆的订单数比可用车辆数多设定阈值时，说明该区域内出现了供需失衡，则要求用户终端确认是否根据高于第一预估价格的第二预估价格执行订单。或者当前时间在预设时间范围内，例如，预设时间范围为：早上7:00-早上9:30和下午5:30-下午8:00，说明在上下班高峰期内，则要求用户终端确认是否根据高于第一预估价格的第二预估价格执行订单。在以上两种情况下，都可以通过加价执行订单的方式满足不同用户的出行需求。
在上述任一技术方案中，优选地，所述设定阈值为：固定的数值或者由所述区域的大小确定。
在上述任一技术方案中，优选地，所述区域为：地图上所述起点所在的格子、地图上所述起点所在的格子及与其相邻的所有格子、以所述起点为圆心且以预定数值为半径的圆或者按经度和纬度划分的区域。
在上述任一技术方案中，优选地，所述第二预估价格与所述第一预估价格之间的差额为：固定金额、根据所述订单的行程信息计算得到的金额或者从所述用户终端接收到的金额。
在该技术方案中，用户每次加价的金额(即第二预估价格比第一预估价格高的差额)可以是固定的，还可以是根据订单的行程信息计算得到的，还可以是用户自己输入的。其中，行程信息包括但不限于：订单的起点、终点、路程总长。例如，起点或者终点越偏僻，第二预估价格比第一预估价格高的差额就越高，或者路程越长，第二预估价格比第一预估价格高的差额就越高。
本发明的第二方面提出了一种网约车服务请求处理装置，包括：处理单元，用于从一个用户终端接收至少包括一个起点和一个终点的网约车服务请求，生成包括根据所述起点和所述终点计算的第一预估价格的订单并发送至所述用户终端；第一排队单元，用于从所述用户终端接收到确认订单指令后，将所述订单加入到第一队列中排队等待分配服务车辆，所述第一队列按照收到确认订单指令的时间先后顺序排列；确认单元，用于若满足预定条件，要求所述用户终端确认是否根据高于所述第一预估价格的第二预估价格执行所述订单；第二排队单元，用于若所述用户终端确认根据所述第二预估价格执行所述订单，则将所述订单加入到第二队列中排队等待分配服务车辆，否则保持所述订单在所述第一队列中排队等待分配服务车辆，其中，为所述第二队列分配的车辆数与所述第二队列中待执行订单数的比值大于为所述第一队列分配的车辆数与所述第一队列中待执行订单数的比值。
在该技术方案中，在将订单加入到第一队列中排队等待分配服务车辆之后，用户可以根据自己的实际出行需求选择是否高于第一预估价格的第二预估价格执行订单。若用户此时比较着急用车，则可以选择高于第一预估价格的第二预估价格执行订单，这样将订单加入到第二队列中排队，由于为第二队列分配的车辆数与第二队列中待执行订单数的比值大于为第一队列分配的车辆数与第一队列中待执行订单数的比值，即为第二队列分配的车辆资源优于为第一队列分配的车辆资源，从而可以为着急用车的订单快速派车。若用户此时不着急用车，则可以选择保持第一预估价格执行订单，订单也就继续在第一队列中排队。因此，通过加价执行订单的方式不仅能够提升优先排队的门槛，抑制需求，提升司机的接单意愿，还避免排队过长，保证约车订单能够被快速应答，从而满足了用户在不同情况下的出行需求。
在上述技术方案中，优选地，所述预定条件包括：所述起点所在的区域内排队等待分配服务车辆的订单数比可用车辆数多设定阈值和/或当前时间在预设时间范围内。
在该技术方案中，当订单的起点所在的区域内排队等待分配服务车辆的订单数比可用车辆数多设定阈值时，说明该区域内出现了供需失衡，则要求用户终端确认是否根据高于第一预估价格的第二预估价格执行订单。或者当前时间在预设时间范围内，例如，预设时间范围为：早上7:00-早上9:30和下午5:30-下午8:00，说明在上下班高峰期内，则要求用户终端确认是否根据高于第一预估价格的第二预估价格执行订单。在以上两种情况下，都可以通过加价执行订单的方式满足不同用户的出行需求。
在上述任一技术方案中，优选地，所述设定阈值为：固定的数值或者由所述区域的大小确定。
在上述任一技术方案中，优选地，所述区域为：地图上所述起点所在的格子、地图上所述起点所在的格子及与其相邻的所有格子、以所述起点为圆心且以预定数值为半径的圆或者按经度和纬度划分的区域。
在上述任一技术方案中，优选地，所述第二预估价格与所述第一预估价格之间的差额为：固定金额、根据所述订单的行程信息计算得到的金额或者从所述用户终端接收到的金额。
在该技术方案中，用户每次加价的金额(即第二预估价格比第一预估价格高的差额)可以是固定的，还可以是根据订单的行程信息计算得到的，还可以是用户自己输入的。其中，行程信息包括但不限于：订单的起点、终点、路程总长。例如，起点或者终点越偏僻，第二预估价格比第一预估价格高的差额就越高，或者路程越长，第二预估价格比第一预估价格高的差额就越高。
本发明的第三方面提出了一种服务器，包括上述第二方面的技术方案中任一项所述的网约车服务请求处理装置，因此，该服务器具有和上述第二方面的技术方案中任一项所述的网约车服务请求处理装置相同的技术效果，在此不再赘述。
本发明的第四方面提出了一种网约车服务请求处理方法，包括：从一个用户终端接收至少包括一个起点和一个终点的网约车服务请求，生成包括根据所述起点和所述终点计算的第一预估价格的订单；若满足预定条件，要求所述用户终端确认是否根据高于所述第一预估价格的第二预估价格执行所述订单；若所述用户终端确认根据所述第一预估价格执行所述订单，则将所述订单加入到第一队列中排队等待分配服务车辆，若所述用户终端确认根据所述第二预估价格执行所述订单，则将所述订单加入到第二队列中排队等待分配服务车辆，其中，为所述第二队列分配的车辆数与所述第二队列中待执行订单数的比值大于为所述第一队列分配的车辆数与所述第一队列中待执行订单数的比值。
在该技术方案中，在接收到来自用户终端的网约车服务请求后，若满足预定条件，则要求用户终端确认是否根据高于第一预估价格的第二预估价格执行订单。若用户此时不着急用车，则可以选择第一预估价格执行订单，订单在第一队列中排队。若用户此时比较着急用车，则可以选择高于第一预估价格的第二预估价格执行订单，这样将订单加入到第二队列中排队，由于为第二队列分配的车辆数与第二队列中待执行订单数的比值大于为第一队列分配的车辆数与第一队列中待执行订单数的比值，即为第二队列分配的车辆资源优于为第一队列分配的车辆资源，从而可以为着急用车的订单快速派车。因此，通过加价执行订单的方式不仅能够提升优先排队的门槛，抑制需求，提升司机的接单意愿，还避免排队过长，保证约车订单能够被快速应答，从而满足了用户在不同情况下的出行需求。
在上述技术方案中，优选地，所述预定条件包括：所述起点所在的区域内排队等待分配服务车辆的订单数比可用车辆数多设定阈值和/或当前时间在预设时间范围内。
在该技术方案中，当订单的起点所在的区域内排队等待分配服务车辆的订单数比可用车辆数多设定阈值时，说明该区域内出现了供需失衡，则要求用户终端确认是否根据高于第一预估价格的第二预估价格执行订单。或者当前时间在预设时间范围内，例如，预设时间范围为：早上7:00-早上9:30和下午5:30-下午8:00，说明在上下班高峰期内，则要求用户终端确认是否根据高于第一预估价格的第二预估价格执行订单。在以上两种情况下，都可以通过加价执行订单的方式满足不同用户的出行需求。
在上述任一技术方案中，优选地，所述设定阈值为：固定的数值或者由所述区域的大小确定。
在上述任一技术方案中，优选地，所述区域为：地图上所述起点所在的格子、地图上所述起点所在的格子及与其相邻的所有格子、以所述起点为圆心且以预定数值为半径的圆或者按经度和纬度划分的区域。
在上述任一技术方案中，优选地，所述第二预估价格与所述第一预估价格之间的差额为：固定金额、根据所述订单的行程信息计算得到的金额或者从所述用户终端接收到的金额。
在该技术方案中，用户每次加价的金额(即第二预估价格比第一预估价格高的差额)可以是固定的，还可以是根据订单的行程信息计算得到的，还可以是用户自己输入的。其中，行程信息包括但不限于：订单的起点、终点、路程总长。例如，起点或者终点越偏僻，第二预估价格比第一预估价格高的差额就越高，或者路程越长，第二预估价格比第一预估价格高的差额就越高。
本发明的第五方面提出了一种网约车服务请求处理装置，包括：处理单元，用于从一个用户终端接收至少包括一个起点和一个终点的网约车服务请求，生成包括根据所述起点和所述终点计算的第一预估价格的订单；确认单元，用于若满足预定条件，要求所述用户终端确认是否根据高于所述第一预估价格的第二预估价格执行所述订单；排队单元，用于若所述用户终端确认根据所述第一预估价格执行所述订单，则将所述订单加入到第一队列中排队等待分配服务车辆，若所述用户终端确认根据所述第二预估价格执行所述订单，则将所述订单加入到第二队列中排队等待分配服务车辆，其中，为所述第二队列分配的车辆数与所述第二队列中待执行订单数的比值大于为所述第一队列分配的车辆数与所述第一队列中待执行订单数的比值。
在该技术方案中，在接收到来自用户终端的网约车服务请求后，若满足预定条件，则要求用户终端确认是否根据高于第一预估价格的第二预估价格执行订单。若用户此时不着急用车，则可以选择第一预估价格执行订单，订单在第一队列中排队。若用户此时比较着急用车，则可以选择高于第一预估价格的第二预估价格执行订单，这样将订单加入到第二队列中排队，由于为第二队列分配的车辆数与第二队列中待执行订单数的比值大于为第一队列分配的车辆数与第一队列中待执行订单数的比值，即为第二队列分配的车辆资源优于为第一队列分配的车辆资源，从而可以为着急用车的订单快速派车。因此，通过加价执行订单的方式不仅能够提升优先排队的门槛，抑制需求，提升司机的接单意愿，还避免排队过长，保证约车订单能够被快速应答，从而满足了用户在不同情况下的出行需求。
在上述技术方案中，优选地，所述预定条件包括：所述起点所在的区域内排队等待分配服务车辆的订单数比可用车辆数多设定阈值和/或当前时间在预设时间范围内。
在该技术方案中，当订单的起点所在的区域内排队等待分配服务车辆的订单数比可用车辆数多设定阈值时，说明该区域内出现了供需失衡，则要求用户终端确认是否根据高于第一预估价格的第二预估价格执行订单。或者当前时间在预设时间范围内，例如，预设时间范围为：早上7:00-早上9:30和下午5:30-下午8:00，说明在上下班高峰期内，则要求用户终端确认是否根据高于第一预估价格的第二预估价格执行订单。在以上两种情况下，都可以通过加价执行订单的方式满足不同用户的出行需求。
在上述任一技术方案中，优选地，所述设定阈值为：固定的数值或者由所述区域的大小确定。
在上述任一技术方案中，优选地，所述区域为：地图上所述起点所在的格子、地图上所述起点所在的格子及与其相邻的所有格子、以所述起点为圆心且以预定数值为半径的圆或者按经度和纬度划分的区域。
在上述任一技术方案中，优选地，所述第二预估价格与所述第一预估价格之间的差额为：固定金额、根据所述订单的行程信息计算得到的金额或者从所述用户终端接收到的金额。
在该技术方案中，用户每次加价的金额(即第二预估价格比第一预估价格高的差额)可以是固定的，还可以是根据订单的行程信息计算得到的，还可以是用户自己输入的。其中，行程信息包括但不限于：订单的起点、终点、路程总长。例如，起点或者终点越偏僻，第二预估价格比第一预估价格高的差额就越高，或者路程越长，第二预估价格比第一预估价格高的差额就越高。
本发明的第六方面提出了一种服务器，包括上述第五方面的技术方案中任一项所述的网约车服务请求处理装置，因此，该服务器具有和上述第五方面的技术方案中任一项所述的网约车服务请求处理装置相同的技术效果，在此不再赘述。
通过本发明的技术方案，可以在最大程度上满足用户的出行需求。
附图说明
图1示出了根据本发明的第一个实施例的网约车服务请求处理方法的流程示意图；
图2示出了根据本发明的第一个实施例的网约车服务请求处理装置的结构示意图；
图3示出了根据本发明的第一个实施例的服务器的结构示意图；
图4A至图4D示出了根据本发明的第一个实施例的终端界面的示意图；
图5示出了根据本发明的第二个实施例的网约车服务请求处理方法的流程示意图；
图6示出了根据本发明的第二个实施例的网约车服务请求处理装置的结构示意图；
图7示出了根据本发明的第二个实施例的服务器的结构示意图；
图8A至图8H示出了根据本发明的第二个实施例的终端界面的示意图。
具体实施方式
为了可以更清楚地理解本发明的上述目的、特征和优点，下面结合附图和具体实施方式对本发明进行进一步的详细描述。需要说明的是，在不冲突的情况下，本申请的实施例及实施例中的特征可以相互组合。
在下面的描述中阐述了很多具体细节以便于充分理解本发明，但是，本发明还可以采用其他不同于在此描述的其他方式来实施，因此，本发明的保护范围并不受下面公开的具体实施例的限制。
图1示出了根据本发明的第一个实施例的网约车服务请求处理方法的流程示意图。
如图1所示，根据本发明的第一个实施例的网约车服务请求处理方法，包括：
步骤102，从一个用户终端接收至少包括一个起点和一个终点的网约车服务请求，生成包括根据起点和终点计算的第一预估价格的订单并发送至用户终端。
步骤104，从用户终端接收到确认订单指令后，将订单加入到第一队列中排队等待分配服务车辆，第一队列按照收到确认订单指令的时间先后顺序排列。
步骤106，若满足预定条件，要求用户终端确认是否根据高于第一预估价格的第二预估价格执行订单。
优选地，预定条件包括：起点所在的区域内排队等待分配服务车辆的订单数比可用车辆数多设定阈值和/或当前时间在预设时间范围内。
当订单的起点所在的区域内排队等待分配服务车辆的订单数比可用车辆数多设定阈值时，说明该区域内出现了供需失衡，则要求用户终端确认是否根据高于第一预估价格的第二预估价格执行订单。或者当前时间在预设时间范围内，例如，预设时间范围为：早上7:00-早上9:30和下午5:30-下午8:00，说明在上下班高峰期内，则要求用户终端确认是否根据高于第一预估价格的第二预估价格执行订单。
优选地，设定阈值为：固定的数值或者由区域的大小确定。
例如，设定阈值为根据经验得到的固定的数值。或者设定阈值随着区域面积的增大而增大。
优选地，区域为：地图上起点所在的格子、地图上起点所在的格子及与其相邻的所有格子、以起点为圆心且以预定数值为半径的圆或者按经度和纬度划分的区域。
由于地图被划分为很多六边形的格子，在用户的起点所在的格子内，排队等待分配服务车辆的订单数比可用车辆数多设定阈值，说明该格子内出现了严重的供需失衡，则要求用户终端确认是否根据高于第一预估价格的第二预估价格执行订单。
步骤108，若用户终端确认根据第二预估价格执行订单，则将订单加入到第二队列中排队等待分配服务车辆，否则保持订单在第一队列中排队等待分配服务车辆，其中，为第二队列分配的车辆数与第二队列中待执行订单数的比值大于为第一队列分配的车辆数与第一队列中待执行订单数的比值。
在该技术方案中，在将订单加入到第一队列中排队等待分配服务车辆之后，用户可以根据自己的实际出行需求选择是否高于第一预估价格的第二预估价格执行订单。若用户此时比较着急用车，则可以选择高于第一预估价格的第二预估价格执行订单，这样将订单加入到第二队列中排队，由于为第二队列分配的车辆数与第二队列中待执行订单数的比值大于为第一队列分配的车辆数与第一队列中待执行订单数的比值，即为第二队列分配的车辆资源优于为第一队列分配的车辆资源，从而可以为着急用车的订单快速派车。若用户此时不着急用车，则可以选择保持第一预估价格执行订单，订单也就继续在第一队列中排队。因此，通过加价执行订单的方式不仅能够提升优先排队的门槛，抑制需求，提升司机的接单意愿，还避免排队过长，保证约车订单能够被快速应答，从而满足了用户在不同情况下的出行需求。
优选地，第二预估价格与第一预估价格之间的差额为：固定金额、根据订单的行程信息计算得到的金额或者从用户终端接收到的金额。
用户每次加价的金额(即第二预估价格比第一预估价格高的差额)可以是固定的，还可以是根据订单的行程信息计算得到的，还可以是用户自己输入的。其中，行程信息包括但不限于：订单的起点、终点、路程总长。例如，起点或者终点越偏僻，第二预估价格比第一预估价格高的差额就越高，或者路程越长，第二预估价格比第一预估价格高的差额就越高。
图2示出了根据本发明的第一个实施例的网约车服务请求处理装置的结构示意图。
如图2所示，根据本发明的第一个实施例的网约车服务请求处理装置200，包括：处理单元202、第一排队单元204、确认单元206和第二排队单元208。
处理单元202，用于从一个用户终端接收至少包括一个起点和一个终点的网约车服务请求，生成包括根据起点和终点计算的第一预估价格的订单并发送至用户终端。
第一排队单元204，用于从用户终端接收到确认订单指令后，将订单加入到第一队列中排队等待分配服务车辆，第一队列按照收到确认订单指令的时间先后顺序排列。
确认单元206，用于若满足预定条件，要求用户终端确认是否根据高于第一预估价格的第二预估价格执行订单。
优选地，预定条件包括：起点所在的区域内排队等待分配服务车辆的订单数比可用车辆数多设定阈值和/或当前时间在预设时间范围内。
当订单的起点所在的区域内排队等待分配服务车辆的订单数比可用车辆数多设定阈值时，说明该区域内出现了供需失衡，则要求用户终端确认是否根据高于第一预估价格的第二预估价格执行订单。或者当前时间在预设时间范围内，例如，预设时间范围为：早上7:00-早上9:30和下午5:30-下午8:00，说明在上下班高峰期内，则要求用户终端确认是否根据高于第一预估价格的第二预估价格执行订单。在以上两种情况下，都可以通过加价执行订单的方式满足不同用户的出行需求。
优选地，设定阈值为：固定的数值或者由区域的大小确定。
优选地，区域为：地图上起点所在的格子、地图上起点所在的格子及与其相邻的所有格子、以用户为圆心且以预定数值为半径的圆或者按经度和纬度划分的区域。
第二排队单元208，用于若用户终端确认根据第二预估价格执行订单，则将订单加入到第二队列中排队等待分配服务车辆，否则保持订单在第一队列中排队等待分配服务车辆，其中，为第二队列分配的车辆数与第二队列中待执行订单数的比值大于为第一队列分配的车辆数与第一队列中待执行订单数的比值。
在该技术方案中，在将订单加入到第一队列中排队等待分配服务车辆之后，用户可以根据自己的实际出行需求选择是否高于第一预估价格的第二预估价格执行订单。若用户此时比较着急用车，则可以选择高于第一预估价格的第二预估价格执行订单，这样将订单加入到第二队列中排队，由于为第二队列分配的车辆数与第二队列中待执行订单数的比值大于为第一队列分配的车辆数与第一队列中待执行订单数的比值，即为第二队列分配的车辆资源优于为第一队列分配的车辆资源，从而可以为着急用车的订单快速派车。若用户此时不着急用车，则可以选择保持第一预估价格执行订单，订单也就继续在第一队列中排队。因此，通过加价执行订单的方式不仅能够提升优先排队的门槛，抑制需求，提升司机的接单意愿，还避免排队过长，保证约车订单能够被快速应答，从而满足了用户在不同情况下的出行需求。
优选地，第二预估价格与第一预估价格之间的差额为：固定金额、根据订单的行程信息计算得到的金额或者从用户终端接收到的金额。
用户每次加价的金额(即第二预估价格比第一预估价格高的差额)可以是固定的，还可以是根据订单的行程信息计算得到的，还可以是用户自己输入的。其中，行程信息包括但不限于：订单的起点、终点、路程总长。例如，起点或者终点越偏僻，第二预估价格比第一预估价格高的差额就越高，或者路程越长，第二预估价格比第一预估价格高的差额就越高。
图3示出了根据本发明的第一个实施例的服务器的结构示意图。
如图3所示，根据本发明的第一个实施例的服务器300，包括上述第二方面的技术方案中任一项的网约车服务请求处理装置200，因此，该服务器300具有和上述第二方面的技术方案中任一项的网约车服务请求处理装置200相同的技术效果，在此不再赘述。
下面通过图4A至图4D进一步地说明上述技术方案。在该实施例中，呼叫的车辆为快车，当然，呼叫的车辆包括但不限于快车，还可以为其他类型的车辆，例如，专车、出租车和顺风车等。
用户终端接收用户输入的起点“兴华胡同”和终点“北海北门”，并将包括该起点和终点的网约车服务请求发送给服务器，服务器根据该网约车服务请求生成包括根据起点和终点计算的第一预估价格的订单并发送至用户终端。如图4A所示，在用户终端上显示第一预估加价，该第一预估价格包括拼车价格和不拼车价格。当用户终端接收用户输入的拼车指令或者不拼车指令，并接收到呼叫快车指令(即确认订单指令)后，服务器将该订单加入到第一队列中排队等待分配服务车辆。
服务器将该订单加入到第一队列中排队等待分配服务车辆之后，确定起点所在区域内排队等待分配服务车辆的订单数比可用车辆数是否多设定阈值，若是，则要求用户终端确认是否根据高于第一预估价格的第二预估价格执行订单。如图4B所示，在用户终端上显示“加12元，优先叫车”。优选地，用户终端上还可以显示订单排队等待分配服务车辆的状态提示信息。其中，状态提示信息包括但不限于以下之一或多种的组合：在该订单之前排队的人数、预估等待时间、排队等待分配服务车辆的订单总数、当前可用车辆的数量。例如，提示信息为图4B中的“您前面还有100人在等待应答，大约需等10分钟”，用户根据该提示信息来选择是否“优先叫车”。若用户选择“优先叫车”，则将订单加入到第二队列中排队，若用户未选择“优先叫车”，则保持订单在第一队列中排队。
当用户终端上接收到“加12元，优先叫车”的指令时，显示正在为乘客优先派车的信息，例如，如图4C所示，在用户终端的上侧显示“正在为您优先派车，请稍等”的信息。或者，当用户终端上接收到“加12元，优先叫车”的指令时，显示当前排队订单数较多的信息，例如，如图4D所示，在用户终端的上侧显示“当前加价人数较多，车辆较少，请耐心等待”的信息。
图5示出了根据本发明的第二个实施例的网约车服务请求处理方法的流程示意图。
如图5所示，根据本发明的第二个实施例的网约车服务请求处理方法，包括：
步骤502，从一个用户终端接收至少包括一个起点和一个终点的网约车服务请求，生成包括根据起点和终点计算的第一预估价格的订单。
步骤504，若满足预定条件，要求用户终端确认是否根据高于第一预估价格的第二预估价格执行订单。
优选地，预定条件包括：起点所在的区域内排队等待分配服务车辆的订单数比可用车辆数多设定阈值和/或当前时间在预设时间范围内。
当订单的起点所在的区域内排队等待分配服务车辆的订单数比可用车辆数多设定阈值时，说明该区域内出现了供需失衡，则要求用户终端确认是否根据高于第一预估价格的第二预估价格执行订单。或者当前时间在预设时间范围内，例如，预设时间范围为：早上7:00-早上9:30和下午5:30-下午8:00，说明在上下班高峰期内，则要求用户终端确认是否根据高于第一预估价格的第二预估价格执行订单。在以上两种情况下，都可以通过加价执行订单的方式满足不同用户的出行需求。
优选地，设定阈值为：固定的数值或者由区域的大小确定。
例如，设定阈值为根据经验得到的固定的数值。或者设定阈值随着区域面积的增大而增大。
优选地，区域为：地图上起点所在的格子、地图上起点所在的格子及与其相邻的所有格子、以起点为圆心且以预定数值为半径的圆或者按经度和纬度划分的区域。
由于地图被划分为很多六边形的格子，在用户的起点所在的格子内，排队等待分配服务车辆的订单数比可用车辆数多设定阈值，说明该格子内出现了严重的供需失衡，则要求用户终端确认是否根据高于第一预估价格的第二预估价格执行订单。
步骤506，若用户终端确认根据第一预估价格执行订单，则将订单加入到第一队列中排队等待分配服务车辆，若用户终端确认根据第二预估价格执行订单，则将订单加入到第二队列中排队等待分配服务车辆，其中，为第二队列分配的车辆数与第二队列中待执行订单数的比值大于为第一队列分配的车辆数与第一队列中待执行订单数的比值。
在该技术方案中，在接收到来自用户终端的网约车服务请求后，若满足预定条件，则要求用户终端确认是否根据高于第一预估价格的第二预估价格执行订单。若用户此时不着急用车，则可以选择第一预估价格执行订单，订单在第一队列中排队。若用户此时比较着急用车，则可以选择高于第一预估价格的第二预估价格执行订单，这样将订单加入到第二队列中排队，由于为第二队列分配的车辆数与第二队列中待执行订单数的比值大于为第一队列分配的车辆数与第一队列中待执行订单数的比值，即为第二队列分配的车辆资源优于为第一队列分配的车辆资源，从而可以为着急用车的订单快速派车。因此，通过加价执行订单的方式不仅能够提升优先排队的门槛，抑制需求，提升司机的接单意愿，还避免排队过长，保证约车订单能够被快速应答，从而满足了用户在不同情况下的出行需求。
优选地，第二预估价格与第一预估价格之间的差额为：固定金额、根据订单的行程信息计算得到的金额或者从用户终端接收到的金额。
用户每次加价的金额(即第二预估价格比第一预估价格高的差额)可以是固定的，还可以是根据订单的行程信息计算得到的，还可以是用户自己输入的。其中，行程信息包括但不限于：订单的起点、终点、路程总长。例如，起点或者终点越偏僻，第二预估价格比第一预估价格高的差额就越高，或者路程越长，第二预估价格比第一预估价格高的差额就越高。
图6示出了根据本发明的第二个实施例的网约车服务请求处理装置的结构示意图。
如图6所示，根据本发明的第二个实施例的网约车服务请求处理装置600，包括：处理单元602、确认单元604和排队单元606。
处理单元602，用于从一个用户终端接收至少包括一个起点和一个终点的网约车服务请求，生成包括根据起点和终点计算的第一预估价格的订单。
确认单元604，用于若满足预定条件，要求用户终端确认是否根据高于第一预估价格的第二预估价格执行订单。
优选地，预定条件包括：起点所在的区域内排队等待分配服务车辆的订单数比可用车辆数多设定阈值和/或当前时间在预设时间范围内。
当订单的起点所在的区域内排队等待分配服务车辆的订单数比可用车辆数多设定阈值时，说明该区域内出现了供需失衡，则要求用户终端确认是否根据高于第一预估价格的第二预估价格执行订单。或者当前时间在预设时间范围内，例如，预设时间范围为：早上7:00-早上9:30和下午5:30-下午8:00，说明在上下班高峰期内，则要求用户终端确认是否根据高于第一预估价格的第二预估价格执行订单。在以上两种情况下，都可以通过加价执行订单的方式满足不同用户的出行需求。
优选地，设定阈值为：固定的数值或者由区域的大小确定。
优选地，区域为：地图上起点所在的格子、地图上起点所在的格子及与其相邻的所有格子、以起点为圆心且以预定数值为半径的圆或者按经度和纬度划分的区域。
排队单元606，用于若用户终端确认根据第一预估价格执行订单，则将订单加入到第一队列中排队等待分配服务车辆，若用户终端确认根据第二预估价格执行订单，则将订单加入到第二队列中排队等待分配服务车辆，其中，为第二队列分配的车辆数与第二队列中待执行订单数的比值大于为第一队列分配的车辆数与第一队列中待执行订单数的比值。
在该技术方案中，在接收到来自用户终端的网约车服务请求后，若满足预定条件，则要求用户终端确认是否根据高于第一预估价格的第二预估价格执行订单。若用户此时不着急用车，则可以选择第一预估价格执行订单，订单在第一队列中排队。若用户此时比较着急用车，则可以选择高于第一预估价格的第二预估价格执行订单，这样将订单加入到第二队列中排队，由于为第二队列分配的车辆数与第二队列中待执行订单数的比值大于为第一队列分配的车辆数与第一队列中待执行订单数的比值，即为第二队列分配的车辆资源优于为第一队列分配的车辆资源，从而可以为着急用车的订单快速派车。因此，通过加价执行订单的方式不仅能够提升优先排队的门槛，抑制需求，提升司机的接单意愿，还避免排队过长，保证约车订单能够被快速应答，从而满足了用户在不同情况下的出行需求。
优选地，第二预估价格与第一预估价格之间的差额为：固定金额、根据订单的行程信息计算得到的金额或者从用户终端接收到的金额。
用户每次加价的金额(即第二预估价格比第一预估价格高的差额)可以是固定的，还可以是根据订单的行程信息计算得到的，还可以是用户自己输入的。其中，行程信息包括但不限于：订单的起点、终点、路程总长。例如，起点或者终点越偏僻，第二预估价格比第一预估价格高的差额就越高，或者路程越长，第二预估价格比第一预估价格高的差额就越高。
图7示出了根据本发明的第二个实施例的服务器的结构示意图。
如图7所示，根据本发明的第二个实施例的服务器700，包括上述第五方面的技术方案中任一项的网约车服务请求处理装置600，因此，该服务器700具有和上述第五方面的技术方案中任一项的网约车服务请求处理装置600相同的技术效果，在此不再赘述。
下面通过图8A至图8H进一步地说明上述技术方案。在该实施例中，呼叫的车辆为快车，当然，呼叫的车辆包括但不限于快车，还可以为其他类型的车辆，例如，专车、出租车和顺风车等。
用户终端接收用户输入的起点“兴华胡同”和终点“北海北门”，并向服务器发送包括该起点和终端的网约车服务请求。服务器根据该网约车服务请求生成包括根据起点和终点计算的第一预估价格的订单，并确定该起点所在区域内排队等待分配服务车辆的订单数比可用车辆数是否多设定阈值，若是，则要求用户终端确认是否根据高于第一预估价格的第二预估价格执行订单。如图8A所示，用户终端上显示“高峰期提醒”以及“+12元加速叫车”、“不加价排队叫车”这两个选项，并显示“+12元加速叫车”和“不加价排队叫车”分别对应的预估等待时间。
当用户在图8A的界面上选择“+12元加速叫车”时，进入到如图8B所示的呼叫快车的界面，在该界面上，用户可以选择拼车或者不拼车。
当用户在图8B的界面上选择不拼车的选项，并发出呼叫快车的信号时，用户终端进入到如图8C所示的界面，提示用户是否确认加价，并显示加价的金额和加价后的总额。
如图8D所示，当用户选择确认加价时，显示“正在为您加速派车，请稍等”的信息。
当用户在图8A的界面上选择“不加价排队叫车”时，进入到如图8E所示的呼叫快车的界面，在该界面上，用户可以选择拼车或者不拼车。
当用户在图8E界面上选择不拼车时，服务器要求用户终端确认是否根据高于第一预估价格的第二预估价格执行订单。如图8F所示，在用户终端上显示“+12元加速叫车(约等3分钟)”的选项。优选地，用户终端上还可以显示订单排队等待分配服务车辆的状态提示信息。其中，状态提示信息包括但不限于以下之一或多种的组合：在该订单之前排队的人数、预估等待时间、排队等待分配服务车辆的订单总数、当前可用车辆的数量。例如，提示信息为图8F中的“当前人数较多，大约需等10分钟，您可以选择加价以提高应答速度”，以帮助用户根据该提示信息来选择是否“优先叫车”。
当用户在图8F的界面上选择“+12元加速叫车”之后，显示正在为用户加速派车的信息，例如，如图8G所示，在用户终端的上侧显示“正在为您加速派车，请稍等”的信息。或者，当用户在图8F的界面上选择“+12元加速叫车”之后，如图8H所示，在用户终端的上侧显示“当前加价人数较多，车辆较少，请耐心等待”的信息。
以上结合附图详细说明了本发明的技术方案，通过本发明的技术方案，可以在最大程度上满足用户的出行需求。
在本发明中，术语“第一”、“第二”仅用于描述的目的，而不能理解为指示或暗示相对重要性；术语“多个”表示两个或两个以上。对于本领域的普通技术人员而言，可以根据具体情况理解上述术语在本发明中的具体含义。
以上所述仅为本发明的优选实施例而已，并不用于限制本发明，对于本领域的技术人员来说，本发明可以有各种更改和变化。凡在本发明的精神和原则之内，所作的任何修改、等同替换、改进等，均应包含在本发明的保护范围之内。
Claims (22)
1.一种网约车服务请求处理方法，其特征在于，包括：
从一个用户终端接收至少包括一个起点和一个终点的网约车服务请求，生成包括根据所述起点和所述终点计算的第一预估价格的订单并发送至所述用户终端；
从所述用户终端接收到确认订单指令后，将所述订单加入到第一队列中排队等待分配服务车辆，所述第一队列按照收到确认订单指令的时间先后顺序排列；
若满足预定条件，要求所述用户终端确认是否根据高于所述第一预估价格的第二预估价格执行所述订单；
若所述用户终端确认根据所述第二预估价格执行所述订单，则将所述订单加入到第二队列中排队等待分配服务车辆，否则保持所述订单在所述第一队列中排队等待分配服务车辆，其中，为所述第二队列分配的车辆数与所述第二队列中待执行订单数的比值大于为所述第一队列分配的车辆数与所述第一队列中待执行订单数的比值。
2.根据权利要求1所述的网约车服务请求处理方法，其特征在于，
所述预定条件包括：所述起点所在的区域内排队等待分配服务车辆的订单数比可用车辆数多设定阈值和/或当前时间在预设时间范围内。
3.根据权利要求2所述的网约车服务请求处理方法，其特征在于，
所述设定阈值为：固定的数值或者由所述区域的大小确定。
4.根据权利要求2所述的网约车服务请求处理方法，其特征在于，
所述区域为：地图上所述起点所在的格子、地图上所述起点所在的格子及与其相邻的所有格子、以所述起点为圆心且以预定数值为半径的圆或者按经度和纬度划分的区域。
5.根据权利要求1至4中任一项所述的网约车服务请求处理方法，其特征在于，
所述第二预估价格与所述第一预估价格之间的差额为：固定金额、根据所述订单的行程信息计算得到的金额或者从所述用户终端接收到的金额。
6.一种网约车服务请求处理装置，其特征在于，包括：
处理单元，用于从一个用户终端接收至少包括一个起点和一个终点的网约车服务请求，生成包括根据所述起点和所述终点计算的第一预估价格的订单并发送至所述用户终端；
第一排队单元，用于从所述用户终端接收到确认订单指令后，将所述订单加入到第一队列中排队等待分配服务车辆，所述第一队列按照收到确认订单指令的时间先后顺序排列；
确认单元，用于若满足预定条件，要求所述用户终端确认是否根据高于所述第一预估价格的第二预估价格执行所述订单；
第二排队单元，用于若所述用户终端确认根据所述第二预估价格执行所述订单，则将所述订单加入到第二队列中排队等待分配服务车辆，否则保持所述订单在所述第一队列中排队等待分配服务车辆，其中，为所述第二队列分配的车辆数与所述第二队列中待执行订单数的比值大于为所述第一队列分配的车辆数与所述第一队列中待执行订单数的比值。
7.根据权利要求6所述的网约车服务请求处理装置，其特征在于，
所述预定条件包括：所述起点所在的区域内排队等待分配服务车辆的订单数比可用车辆数多设定阈值和/或当前时间在预设时间范围内。
8.根据权利要求7所述的网约车服务请求处理装置，其特征在于，
所述设定阈值为：固定的数值或者由所述区域的大小确定。
9.根据权利要求7所述的网约车服务请求处理装置，其特征在于，
所述区域为：地图上所述起点所在的格子、地图上所述起点所在的格子及与其相邻的所有格子、以所述起点为圆心且以预定数值为半径的圆或者按经度和纬度划分的区域。
10.根据权利要求6至9中任一项所述的网约车服务请求处理装置，其特征在于，
所述第二预估价格与所述第一预估价格之间的差额为：固定金额、根据所述订单的行程信息计算得到的金额或者从所述用户终端接收到的金额。
11.一种服务器，其特征在于，包括：如权利要求6至10中任一项所述的网约车服务请求处理装置。
12.一种网约车服务请求处理方法，其特征在于，包括：
从一个用户终端接收至少包括一个起点和一个终点的网约车服务请求，生成包括根据所述起点和所述终点计算的第一预估价格的订单；
若满足预定条件，要求所述用户终端确认是否根据高于所述第一预估价格的第二预估价格执行所述订单；
若所述用户终端确认根据所述第一预估价格执行所述订单，则将所述订单加入到第一队列中排队等待分配服务车辆，若所述用户终端确认根据所述第二预估价格执行所述订单，则将所述订单加入到第二队列中排队等待分配服务车辆，其中，为所述第二队列分配的车辆数与所述第二队列中待执行订单数的比值大于为所述第一队列分配的车辆数与所述第一队列中待执行订单数的比值。
13.根据权利要求12所述的网约车服务请求处理方法，其特征在于，
所述预定条件包括：所述起点所在的区域内排队等待分配服务车辆的订单数比可用车辆数多设定阈值和/或当前时间在预设时间范围内。
14.根据权利要求13所述的网约车服务请求处理方法，其特征在于，
所述设定阈值为：固定的数值或者由所述区域的大小确定。
15.根据权利要求13所述的网约车服务请求处理方法，其特征在于，
所述区域为：地图上所述起点所在的格子、地图上所述起点所在的格子及与其相邻的所有格子、以所述起点为圆心且以预定数值为半径的圆或者按经度和纬度划分的区域。
16.根据权利要求12至15中任一项所述的网约车服务请求处理方法，其特征在于，
所述第二预估价格与所述第一预估价格之间的差额为：固定金额、根据所述订单的行程信息计算得到的金额或者从所述用户终端接收到的金额。
17.一种网约车服务请求处理装置，其特征在于，包括：
处理单元，用于从一个用户终端接收至少包括一个起点和一个终点的网约车服务请求，生成包括根据所述起点和所述终点计算的第一预估价格的订单；
确认单元，用于若满足预定条件，要求所述用户终端确认是否根据高于所述第一预估价格的第二预估价格执行所述订单；
排队单元，用于若所述用户终端确认根据所述第一预估价格执行所述订单，则将所述订单加入到第一队列中排队等待分配服务车辆，若所述用户终端确认根据所述第二预估价格执行所述订单，则将所述订单加入到第二队列中排队等待分配服务车辆，其中，为所述第二队列分配的车辆数与所述第二队列中待执行订单数的比值大于为所述第一队列分配的车辆数与所述第一队列中待执行订单数的比值。
18.根据权利要求17所述的网约车服务请求处理装置，其特征在于，
所述预定条件包括：所述起点所在的区域内排队等待分配服务车辆的订单数比可用车辆数多设定阈值和/或当前时间在预设时间范围内。
19.根据权利要求18所述的网约车服务请求处理装置，其特征在于，
所述设定阈值为：固定的数值或者由所述区域的大小确定。
20.根据权利要求18所述的网约车服务请求处理装置，其特征在于，
所述区域为：地图上所述起点所在的格子、地图上所述起点所在的格子及与其相邻的所有格子、以所述起点为圆心且以预定数值为半径的圆或者按经度和纬度划分的区域。
21.根据权利要求17至20中任一项所述的网约车服务请求处理装置，其特征在于，
所述第二预估价格与所述第一预估价格之间的差额为：固定金额、根据所述订单的行程信息计算得到的金额或者从所述用户终端接收到的金额。
22.一种服务器，其特征在于，包括：如权利要求17至21中任一项所述的网约车服务请求处理装置。
Priority Applications (7)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| CN201710195830.8A CN108009841A (zh) | 2017-03-29 | 2017-03-29 | 网约车服务请求处理方法、装置和服务器 |
| CN201780035203.6A CN109313776A (zh) | 2017-03-29 | 2017-11-14 | 用于按需服务分配车辆的系统和方法 |
| JP2019548912A JP6867504B2 (ja) | 2017-03-29 | 2017-11-14 | オンデマンドサービスのための乗り物を割り当てるシステム及び方法 |
| EP17904135.5A EP3577620A4 (en) | 2017-03-29 | 2017-11-14 | SYSTEMS AND METHODS FOR ALLOCATING VEHICLES TO ON-DEMAND SERVICES |
| PCT/CN2017/110885 WO2018176849A1 (en) | 2017-03-29 | 2017-11-14 | Systems and methods for allocating vehicles for on-demand services |
| AU2017406770A AU2017406770A1 (en) | 2017-03-29 | 2017-11-14 | Systems and methods for allocating vehicles for on-demand services |
| US15/838,194 US20180285792A1 (en) | 2017-03-29 | 2017-12-11 | Method and system for providing transportation service |
Applications Claiming Priority (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| CN201710195830.8A CN108009841A (zh) | 2017-03-29 | 2017-03-29 | 网约车服务请求处理方法、装置和服务器 |
Publications (1)
| Publication Number | Publication Date |
|---|---|
| CN108009841A true CN108009841A (zh) | 2018-05-08 |
Family
ID=62048722
Family Applications (1)
| Application Number | Title | Priority Date | Filing Date |
|---|---|---|---|
| CN201710195830.8A Pending CN108009841A (zh) | 2017-03-29 | 2017-03-29 | 网约车服务请求处理方法、装置和服务器 |
Country Status (2)
| Country | Link |
|---|---|
| US (1) | US20180285792A1 (zh) |
| CN (1) | CN108009841A (zh) |
Cited By (16)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| CN108985477A (zh) * | 2018-06-29 | 2018-12-11 | 北京嘀嘀无限科技发展有限公司 | 业务处理方法、装置及存储介质 |
| CN109377023A (zh) * | 2018-09-28 | 2019-02-22 | 北京三快在线科技有限公司 | 订单的分配方法、装置及电子设备 |
| CN110175869A (zh) * | 2019-05-08 | 2019-08-27 | 北京三快在线科技有限公司 | 车辆分配方法及装置、电子设备和计算机可读存储介质 |
| CN110766505A (zh) * | 2018-11-09 | 2020-02-07 | 北京嘀嘀无限科技发展有限公司 | 识别紧急订单请求的系统和方法 |
| CN110782301A (zh) * | 2019-02-25 | 2020-02-11 | 北京嘀嘀无限科技发展有限公司 | 一种拼单方法、装置、电子设备及计算机可读存储介质 |
| CN110956346A (zh) * | 2018-09-26 | 2020-04-03 | 北京嘀嘀无限科技发展有限公司 | 一种订单处理方法及装置 |
| CN111144603A (zh) * | 2018-11-02 | 2020-05-12 | 北京嘀嘀无限科技发展有限公司 | 一种服务信息推送方法、装置、电子设备和存储介质 |
| CN111277618A (zh) * | 2018-12-05 | 2020-06-12 | 北京嘀嘀无限科技发展有限公司 | 一种信息推送方法、装置、电子设备及存储介质 |
| CN111339230A (zh) * | 2020-02-24 | 2020-06-26 | 腾讯科技（深圳）有限公司 | 一种车辆信息显示方法、装置、电子设备和存储介质 |
| CN111526170A (zh) * | 2019-02-01 | 2020-08-11 | 北京嘀嘀无限科技发展有限公司 | 推送方法、显示方法、装置、服务器、终端和存储介质 |
| CN111861081A (zh) * | 2019-12-23 | 2020-10-30 | 北京嘀嘀无限科技发展有限公司 | 一种订单分配方法、装置、电子设备及存储介质 |
| CN111861200A (zh) * | 2020-07-17 | 2020-10-30 | 北京嘀嘀无限科技发展有限公司 | 一种服务订单分配方法、装置、电子设备及可读存储介质 |
| CN112559144A (zh) * | 2020-12-09 | 2021-03-26 | 海南大学 | 面向数据与信息权益交换的智能共享装置调度方法 |
| CN113657810A (zh) * | 2021-09-01 | 2021-11-16 | 首约科技(北京)有限公司 | 一种提升完单率和司机满意度的派单方法 |
| CN113902150A (zh) * | 2021-09-07 | 2022-01-07 | 首约科技(北京)有限公司 | 一种即时单派单的乘客排队策略方法 |
| CN119273038A (zh) * | 2024-09-11 | 2025-01-07 | 北京行云在线软件开发有限公司 | 一种多渠道报价订单升舱调度方法、装置、计算机设备及可读存储介 |
Families Citing this family (3)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| US11842304B2 (en) * | 2019-11-14 | 2023-12-12 | Toyota Motor North America, Inc. | Accessible ride hailing and transit platform |
| US20220164910A1 (en) * | 2020-11-20 | 2022-05-26 | Lyft, Inc. | Prioritized transportation requests for a dynamic transportation matching system |
| JP7643411B2 (ja) * | 2022-08-09 | 2025-03-11 | トヨタ自動車株式会社 | 荷物配送管理システム、荷物配送管理方法、及び車両 |
Citations (5)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| CN102655335A (zh) * | 2012-02-24 | 2012-09-05 | 东北大学秦皇岛分校 | 基于队列管理的小区电动汽车充电管理系统及方法 |
| CN104021667A (zh) * | 2014-06-25 | 2014-09-03 | 哈尔滨工业大学 | 整合预约服务与实时打车的出租车合乘调度系统及调度方法 |
| CN104183118A (zh) * | 2014-08-19 | 2014-12-03 | 北京嘀嘀无限科技发展有限公司 | 基于拍卖模式获得乘客最优接驾司机的派单系统 |
| CN105761482A (zh) * | 2016-05-10 | 2016-07-13 | 北京交通大学 | 基于公平性的出租车实时预约方法及系统 |
| CN106355921A (zh) * | 2016-11-10 | 2017-01-25 | 安徽云看信息技术有限公司 | 一种基于路程时间的打车方法 |
Family Cites Families (4)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| US10002198B2 (en) * | 2009-10-28 | 2018-06-19 | Verizon Patent And Licensing Inc. | Mobile taxi dispatch system |
| CA2932917A1 (en) * | 2013-12-11 | 2015-06-18 | Uber Technologies, Inc. | Intelligent queuing for user selection in providing on-demand services |
| US10664707B2 (en) * | 2014-10-06 | 2020-05-26 | Marc R. Hannah | Managed access system for traffic flow optimization |
| GB201503080D0 (en) * | 2015-02-24 | 2015-04-08 | Addison Lee Ltd | Resource management |
-
2017
- 2017-03-29 CN CN201710195830.8A patent/CN108009841A/zh active Pending
- 2017-12-11 US US15/838,194 patent/US20180285792A1/en not_active Abandoned
Patent Citations (5)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| CN102655335A (zh) * | 2012-02-24 | 2012-09-05 | 东北大学秦皇岛分校 | 基于队列管理的小区电动汽车充电管理系统及方法 |
| CN104021667A (zh) * | 2014-06-25 | 2014-09-03 | 哈尔滨工业大学 | 整合预约服务与实时打车的出租车合乘调度系统及调度方法 |
| CN104183118A (zh) * | 2014-08-19 | 2014-12-03 | 北京嘀嘀无限科技发展有限公司 | 基于拍卖模式获得乘客最优接驾司机的派单系统 |
| CN105761482A (zh) * | 2016-05-10 | 2016-07-13 | 北京交通大学 | 基于公平性的出租车实时预约方法及系统 |
| CN106355921A (zh) * | 2016-11-10 | 2017-01-25 | 安徽云看信息技术有限公司 | 一种基于路程时间的打车方法 |
Non-Patent Citations (2)
| Title |
|---|
| 朱国玮: "《市场营销案例集》", 30 November 2014, 上海：上海人民出版社 * |
| 重庆晨报上游新闻（重庆）: "滴滴司机：加价收益最多只能拿到20元多出的归平台", 《HTTP://NEWS.163.COM/17/0124/10/CBHPRCKU00018AOR.HTML》 * |
Cited By (20)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| CN108985477A (zh) * | 2018-06-29 | 2018-12-11 | 北京嘀嘀无限科技发展有限公司 | 业务处理方法、装置及存储介质 |
| CN110956346A (zh) * | 2018-09-26 | 2020-04-03 | 北京嘀嘀无限科技发展有限公司 | 一种订单处理方法及装置 |
| CN109377023A (zh) * | 2018-09-28 | 2019-02-22 | 北京三快在线科技有限公司 | 订单的分配方法、装置及电子设备 |
| CN111144603A (zh) * | 2018-11-02 | 2020-05-12 | 北京嘀嘀无限科技发展有限公司 | 一种服务信息推送方法、装置、电子设备和存储介质 |
| CN110766505A (zh) * | 2018-11-09 | 2020-02-07 | 北京嘀嘀无限科技发展有限公司 | 识别紧急订单请求的系统和方法 |
| CN111277618A (zh) * | 2018-12-05 | 2020-06-12 | 北京嘀嘀无限科技发展有限公司 | 一种信息推送方法、装置、电子设备及存储介质 |
| CN111277618B (zh) * | 2018-12-05 | 2023-06-16 | 北京嘀嘀无限科技发展有限公司 | 一种信息推送方法、装置、电子设备及存储介质 |
| CN111526170B (zh) * | 2019-02-01 | 2022-10-04 | 北京嘀嘀无限科技发展有限公司 | 推送方法、显示方法、装置、服务器、终端和存储介质 |
| CN111526170A (zh) * | 2019-02-01 | 2020-08-11 | 北京嘀嘀无限科技发展有限公司 | 推送方法、显示方法、装置、服务器、终端和存储介质 |
| CN110782301A (zh) * | 2019-02-25 | 2020-02-11 | 北京嘀嘀无限科技发展有限公司 | 一种拼单方法、装置、电子设备及计算机可读存储介质 |
| CN110175869A (zh) * | 2019-05-08 | 2019-08-27 | 北京三快在线科技有限公司 | 车辆分配方法及装置、电子设备和计算机可读存储介质 |
| CN111861081A (zh) * | 2019-12-23 | 2020-10-30 | 北京嘀嘀无限科技发展有限公司 | 一种订单分配方法、装置、电子设备及存储介质 |
| CN111339230B (zh) * | 2020-02-24 | 2021-11-02 | 腾讯科技（深圳）有限公司 | 一种车辆信息显示方法、装置、电子设备和存储介质 |
| CN111339230A (zh) * | 2020-02-24 | 2020-06-26 | 腾讯科技（深圳）有限公司 | 一种车辆信息显示方法、装置、电子设备和存储介质 |
| CN111861200A (zh) * | 2020-07-17 | 2020-10-30 | 北京嘀嘀无限科技发展有限公司 | 一种服务订单分配方法、装置、电子设备及可读存储介质 |
| CN111861200B (zh) * | 2020-07-17 | 2024-06-25 | 北京嘀嘀无限科技发展有限公司 | 一种服务订单分配方法、装置、电子设备及可读存储介质 |
| CN112559144A (zh) * | 2020-12-09 | 2021-03-26 | 海南大学 | 面向数据与信息权益交换的智能共享装置调度方法 |
| CN113657810A (zh) * | 2021-09-01 | 2021-11-16 | 首约科技(北京)有限公司 | 一种提升完单率和司机满意度的派单方法 |
| CN113902150A (zh) * | 2021-09-07 | 2022-01-07 | 首约科技(北京)有限公司 | 一种即时单派单的乘客排队策略方法 |
| CN119273038A (zh) * | 2024-09-11 | 2025-01-07 | 北京行云在线软件开发有限公司 | 一种多渠道报价订单升舱调度方法、装置、计算机设备及可读存储介 |
Also Published As
| Publication number | Publication date |
|---|---|
| US20180285792A1 (en) | 2018-10-04 |
Similar Documents
| Publication | Publication Date | Title |
|---|---|---|
| CN108009841A (zh) | 网约车服务请求处理方法、装置和服务器 | |
| CN109716367B (zh) | 用于预定运输服务的方法和系统 | |
| CN104021667B (zh) | 整合预约服务与实时打车的出租车合乘调度系统及调度方法 | |
| CN108009651A (zh) | 订单处理方法、装置、终端设备和计算机可读存储介质 | |
| US20130024249A1 (en) | Public transport optimization | |
| WO2016008391A1 (zh) | 在网络租车系统中为他人订车的方法和系统 | |
| CN102682599A (zh) | 一种基于lbs出租车预约系统与方法 | |
| CN110390544A (zh) | 司机奖励的下发方法及装置 | |
| CN106373382B (zh) | 一种用于车辆调度的方法与设备 | |
| CN105160711A (zh) | 一种动态调价方法及装置 | |
| CN106022540A (zh) | 订单处理方法及装置 | |
| KR20180136760A (ko) | 복수의 배차 요청이 가능한 콜택시 서비스를 제공하는 방법, 서버 및 단말 | |
| CN106097702A (zh) | 智能交通调度方法和系统 | |
| CN110070751A (zh) | 车位共享发布管理系统、车位共享自动推送装置及方法 | |
| CN110175869A (zh) | 车辆分配方法及装置、电子设备和计算机可读存储介质 | |
| CN111598646A (zh) | 一种带预定功能的电动出租车充电导航方法 | |
| CN103116980A (zh) | 一种基于云的出租车资源调度的方法 | |
| CN113240477A (zh) | 订单派发方法、订单派发装置和可读存储介质 | |
| CN109102160A (zh) | 出租车排队调度方法、装置及计算机可读存储介质 | |
| KR102250657B1 (ko) | 콜 서비스 예약 시스템 및 방법 | |
| CN112329965B (zh) | 乘车服务调度方法、装置、电子设备及存储介质 | |
| CN113902150A (zh) | 一种即时单派单的乘客排队策略方法 | |
| CN103956044A (zh) | 基于移动互联网的出租车智能电召系统及方法 | |
| CN109840986A (zh) | 油号信息的显示方法、装置及车载无线终端 | |
| CN111626801A (zh) | 一种订单派发方法、装置、电子设备和计算机存储介质 |
Legal Events
| Date | Code | Title | Description |
|---|---|---|---|
| PB01 | Publication | ||
| PB01 | Publication | ||
| SE01 | Entry into force of request for substantive examination | ||
| SE01 | Entry into force of request for substantive examination | ||
| RJ01 | Rejection of invention patent application after publication |
Application publication date: 20180508 |
|
| RJ01 | Rejection of invention patent application after publication |