[go: up one dir, main page]

CN106327311B - 订单处理方法、装置及系统 - Google Patents

订单处理方法、装置及系统 Download PDF

Info

Publication number
CN106327311B
CN106327311B CN201610825189.7A CN201610825189A CN106327311B CN 106327311 B CN106327311 B CN 106327311B CN 201610825189 A CN201610825189 A CN 201610825189A CN 106327311 B CN106327311 B CN 106327311B
Authority
CN
China
Prior art keywords
order
order request
addresses
destination addresses
destination
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.)
Active
Application number
CN201610825189.7A
Other languages
English (en)
Other versions
CN106327311A (zh
Inventor
赵君杰
任俊媛
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
BOE Technology Group Co Ltd
Original Assignee
BOE Technology Group Co Ltd
Priority date (The priority date 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 date listed.)
Filing date
Publication date
Application filed by BOE Technology Group Co Ltd filed Critical BOE Technology Group Co Ltd
Priority to CN201610825189.7A priority Critical patent/CN106327311B/zh
Publication of CN106327311A publication Critical patent/CN106327311A/zh
Priority to US15/680,562 priority patent/US20180075568A1/en
Application granted granted Critical
Publication of CN106327311B publication Critical patent/CN106327311B/zh
Active legal-status Critical Current
Anticipated expiration legal-status Critical

Links

Images

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
    • G06Q50/00—Information and communication technology [ICT] specially adapted for implementation of business processes of specific business sectors, e.g. utilities or tourism
    • G06Q50/40—Business processes related to the transportation industry
    • 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
    • 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
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L67/00—Network arrangements or protocols for supporting network services or applications
    • H04L67/01—Protocols
    • H04L67/12—Protocols specially adapted for proprietary or special-purpose networking environments, e.g. medical networks, sensor networks, networks in vehicles or remote metering networks

Landscapes

  • Business, Economics & Management (AREA)
  • Accounting & Taxation (AREA)
  • Finance (AREA)
  • Engineering & Computer Science (AREA)
  • General Business, Economics & Management (AREA)
  • Theoretical Computer Science (AREA)
  • Strategic Management (AREA)
  • Physics & Mathematics (AREA)
  • Economics (AREA)
  • General Physics & Mathematics (AREA)
  • Marketing (AREA)
  • Development Economics (AREA)
  • Tourism & Hospitality (AREA)
  • Health & Medical Sciences (AREA)
  • General Health & Medical Sciences (AREA)
  • Human Resources & Organizations (AREA)
  • Primary Health Care (AREA)
  • Traffic Control Systems (AREA)
  • Operations Research (AREA)

Abstract

本发明公开了一种订单处理方法、装置及系统，属于信息技术领域。所述方法包括：接收第一订单请求，所述第一订单请求包括下单信息，所述下单信息至少包括：n个目的地址，n≥2且所述n为整数；根据所述n个目的地址，对所述第一订单请求进行处理，得到第二订单请求；将所述第二订单请求发送至车载终端。本发明解决了目前的订单处理方法，预定的车辆可靠性较低的问题，实现了提高预定的车辆可靠性，用于预定车辆。

Description

订单处理方法、装置及系统
技术领域
本发明涉及信息技术领域，特别涉及一种订单处理方法、装置及系统。
背景技术
随着互联网及移动设备的迅速发展，特别是智能手机和智能移动导航系统的普及，给人们的出行带来了极大的便利。随着城市的发展，打车需求已经是人们的普遍需求。互联网和打车行业的有机结合，使由打车客户端与打车服务器所组成的打车平台应运而生。基于打车平台的订单处理方法提高了打车效率，使人们出行更加快捷。
现有技术中有一种订单处理方法，通过该方法，用户通过自身携带的终端(即用户终端)中的打车客户端打车，具体的，用户终端将订单请求通过打车客户端发送至用于预定车辆的打车服务器，该订单请求包括下单信息，该下单信息包括用户输入的起始地址、目的地址及用户信息(包括用户姓名和用户电话号码)，打车服务器再将该订单请求发送至一定范围内的多个车辆的终端(即车载终端)，多个车载终端接收订单请求后，打车服务器从多个车载终端中确定一个车载终端为用户服务，或者，打车服务器直接将订单请求发送至一个车载终端，使该车载终端为用户服务。
上述方法仅适用于下单信息中包括一个目的地址的情况，无法适用于多个目的地址的情况，所以目前的订单处理方法，预定的车辆可靠性较低。
发明内容
为了解决现有技术预定的车辆可靠性较低的问题，本发明提供了一种订单处理方法、装置及系统。所述技术方案如下：
第一方面，提供了一种订单处理方法，包括：
接收第一订单请求，所述第一订单请求包括下单信息，所述下单信息至少包括：n个目的地址，n≥2且所述n为整数；
根据所述n个目的地址，对所述第一订单请求进行处理，得到第二订单请求；
将所述第二订单请求发送至车载终端。
另一方面，提供一种订单处理方法，包括：
获取第一订单请求，所述第一订单请求包括下单信息，所述下单信息至少包括：n个目的地址，n≥2且所述n为整数；
将所述第一订单请求发送至打车服务器，以使所述打车服务器根据所述n个目的地址对所述第一订单请求进行处理，得到第二订单请求，并将所述第二订单请求发送至车载终端。
还提供一种订单处理装置，所述装置包括：
第一接收模块，用于接收第一订单请求，所述第一订单请求包括下单信息，所述下单信息至少包括：n个目的地址，n≥2且所述n为整数；
处理模块，用于根据所述n个目的地址，对所述第一订单请求进行处理，得到第二订单请求；
第一发送模块，用于将所述第二订单请求发送至车载终端。
一种订单处理装置，所述装置包括：
获取模块，用于获取第一订单请求，所述第一订单请求包括下单信息，所述下单信息至少包括：n个目的地址，n≥2且所述n为整数；
第一发送模块，用于将所述第一订单请求发送至打车服务器，以使所述打车服务器根据所述n个目的地址对所述第一订单请求进行处理，得到第二订单请求，并将所述第二订单请求发送至车载终端。
一种订单处理系统，包括：打车服务器、用户终端和车载终端；
所述打车服务器用于：接收第一订单请求，所述第一订单请求包括下单信息，所述下单信息至少包括：n个目的地址，n≥2且所述n为整数；根据所述n个目的地址，对所述第一订单请求进行处理，得到第二订单请求；将所述第二订单请求发送至所述车载终端；
所述用户终端用于：获取第一订单请求，所述第一订单请求包括下单信息，所述下单信息至少包括：n个目的地址，n≥2且所述n为整数；将所述第一订单请求发送至打车服务器，以使所述打车服务器根据所述n个目的地址对所述第一订单请求进行处理，得到第二订单请求，并将所述第二订单请求发送至所述车载终端。
本发明提供的技术方案带来的有益效果是：
本发明提供的订单处理方法、装置及系统，该方法中，打车服务器能够接收用户终端发送的第一订单请求，并对该第一订单请求进行处理，得到第二订单请求，再将第二订单请求发送至车载终端，其中，第一订单请求包括下单信息，该下单信息包括多个目的地址，相较于现有技术，该方法适用于下单信息包括多个目的地址的情况，该方法使得用户在输入多个目的地址时也能成功预订车辆，提高了预定的车辆可靠性。
附图说明
为了更清楚地说明本发明实施例中的技术方案，下面将对实施例描述中所需要使用的附图作简单地介绍，显而易见地，下面描述中的附图仅仅是本发明的一些实施例，对于本领域普通技术人员来讲，在不付出创造性劳动的前提下，还可以根据这些附图获得其他的附图。
图1是本发明实施例提供的各个实施例所涉及的实施环境的示意图；
图2是本发明实施例提供的一种订单处理方法流程图；
图3是本发明实施例提供的另一种订单处理方法流程图；
图4是本发明实施例提供的又一种订单处理方法流程图；
图5-1是本发明实施例提供的再一种订单处理方法流程图；
图5-2是本发明实施例提供的一种用户终端获取第一订单请求流程图；
图5-3是本发明实施例提供的一种下单页面的示意图；
图5_4是本发明实施例提供的一种路线图的示意图；
图5-5是本发明实施例提供的一种打车服务器发送子订单请求流程图；
图5-6是本发明实施例提供的一种打车服务器分别与车载终端Z1和Z2交互的示意图；
图6-1是本发明实施例提供的再一种订单处理方法流程图；
图6-2是本发明实施例提供的又一种路线图的示意图；
图7-1是本发明实施例提供的再一种订单处理方法流程图；
图7-2是本发明实施例提供的一种订单处理方法流程图
图8-1是本发明实施例提供的一种订单处理装置的框图；
图8-2是本发明实施例提供的一种处理模块的框图；
图8-3是本发明实施例提供的一种第一发送模块的框图；
图8-4是本发明实施例提供的一种订单处理装置的框图；
图9-1是本发明实施例提供的再一种订单处理装置的框图；
图9-2是本发明实施例提供的一种订单处理装置的框图；
图9-3是本发明实施例提供的一种订单处理装置的框图；
图10-1是本发明实施例提供的一种订单处理装置的框图；
图10-2是本发明实施例提供的一种订单处理装置的框图。
具体实施方式
为使本发明的目的、技术方案和优点更加清楚，下面将结合附图对本发明实施方式作进一步地详细描述。
图1示出了本发明各个实施例所涉及的实施环境的示意图，该实施环境可以包括打车服务器100、用户终端200和多个车载终端300。
打车服务器100可以是一台服务器，或者由若干台服务器组成的服务器集群，或者是一个云计算服务中心。打车服务器100分别与用户终端200和车载终端300通过无线网络建立连接。
用户终端200可以为可穿戴设备、手机、平板电脑、计算机等等。
车载终端300可以为可穿戴设备、手机、平板电脑、计算机等等，本实施环境不对车载终端300的数量作出限制。
打车服务器100在接收到用户终端200发送的第一订单请求后，能够根据第一订单请求包括的下单信息中的多个目的地址，对第一订单请求进行处理，得到第二订单请求，并将第二订单请求发送至车载终端300。
图2是根据一示例性实施例示出的一种订单处理方法的流程图，本实施例以该订单处理方法应用于图1所示实施环境中的打车服务器100来举例说明。该订单处理方法可以包括如下几个步骤：
步骤201、接收第一订单请求，该第一订单请求包括下单信息，下单信息至少包括：n个目的地址，n≥2且n为整数。
步骤202、根据n个目的地址，对第一订单请求进行处理，得到第二订单请求。
步骤203、将第二订单请求发送至车载终端。
综上所述，本发明实施例提供的订单处理方法，该方法中，打车服务器能够接收用户终端发送的第一订单请求，并对该第一订单请求进行处理，得到第二订单请求，再将第二订单请求发送至车载终端，其中，第一订单请求包括下单信息，该下单信息包括多个目的地址，相较于现有技术，该方法适用于下单信息包括多个目的地址的情况，该方法使得用户在输入多个目的地址时也能成功预订车辆，提高了预定的车辆可靠性。
进一步的，一方面，步骤202可以包括：根据下单信息判断是否需要拆分第一订单请求；当需要拆分第一订单请求时，根据下单信息将第一订单请求拆分为m个子订单请求，2≤m≤n且m为整数；将m个子订单请求作为第二订单请求。相应的，步骤203可以包括：将m个子订单请求分别发送至至少m个不同的车载终端。
另一方面，下单信息还包括第一地址类型标识和起始地址，第一地址类型标识用于指示n个目的地址为n个串行的目的地址，步骤202可以包括：判断起始地址与n个目的地址组成的n+1个地址是否满足第二预设条件；当n+1个地址满足第二预设条件时，调整n个串行的目的地址的顺序，得到第二订单请求。其中，第二预设条件为：S1＞S3；或者，T1＞T3；或者，S1＞S3且T1＞T3；S1为n+1个地址中任意相邻两个地址的行驶距离之和，S3为顺序调整后的n+1个地址中任意相邻两个地址的行驶距离之和，T1为n+1个地址中任意相邻两个地址的行驶时间之和，T3为顺序调整后的n+1个地址中任意相邻两个地址的行驶时间之和。
综上所述，本发明实施例提供的订单处理方法，该方法中，打车服务器能够接收用户终端发送的第一订单请求，并对该第一订单请求进行处理，得到第二订单请求，再将第二订单请求发送至车载终端，其中，第一订单请求包括下单信息，该下单信息包括多个目的地址，相较于现有技术，该方法适用于下单信息包括多个目的地址的情况，该方法使得用户在输入多个目的地址时也能成功预订车辆，提高了预定的车辆可靠性。
图3是根据一示例性实施例示出的一种订单处理方法的流程图，本实施例以该订单处理方法应用于图1所示实施环境中的用户终端200来举例说明。该订单处理方法可以包括如下几个步骤：
步骤301、获取第一订单请求，该第一订单请求包括下单信息，下单信息至少包括：n个目的地址，n≥2且n为整数。
步骤302、将第一订单请求发送至打车服务器，以使打车服务器根据n个目的地址对第一订单请求进行处理，得到第二订单请求，并将第二订单请求发送至车载终端。
综上所述，本发明实施例提供的订单处理方法，该方法中，用户终端能够将第一订单请求发送至打车服务器，使得打车服务器根据第一订单请求包括的下单信息中的多个目的地址，对第一订单请求进行处理，得到第二订单请求，并将第二订单请求发送至车载终端，相较于现有技术，该方法适用于下单信息包括多个目的地址的情况，该方法使得用户在输入多个目的地址时也能成功预订车辆，提高了预定的车辆可靠性。
图4是根据一示例性实施例示出的一种订单处理方法的流程图，本实施例以该订单处理方法应用于图1所示实施环境中的车载终端300来举例说明。该订单处理方法可以包括如下几个步骤：
步骤401、接收打车服务器发送的第二订单请求，该第二订单请求是打车服务器根据n个目的地址，对第一订单请求进行处理后得到的，该第一订单请求包括下单信息，下单信息至少包括：n个目的地址，n≥2且n为整数。
综上所述，本发明实施例提供的订单处理方法，该方法中，车载终端能够接收打车服务器发送的第二订单请求，该第二订单请求是打车服务器根据第一订单请求包括的下单信息中的多个目的地址，对第一订单请求进行处理后得到的，相较于现有技术，该方法适用于下单信息包括多个目的地址的情况，该方法使得用户在输入多个目的地址时也能成功预订车辆，提高了预定的车辆可靠性。
图5-1是根据一示例性实施例示出的一种订单处理方法的流程图，本实施例以该订单处理方法应用于图1所示实施环境来举例说明。该订单处理方法可以包括如下几个步骤：
步骤501、用户终端获取第一订单请求。
第一订单请求包括下单信息，下单信息至少包括：n个目的地址，n≥2且n为整数。具体的，如图5-2所示，步骤501可以包括：
步骤5011、用户终端接收用户的输入信息。
输入信息包括n个目的地址。示例的，输入方式可以是语音输入方式，文字输入方式和图形输入方式中的任一种。假设用户YH当前所处的地址为A0(即起始地址)，用户YH想先去目的地址A1，再去目的地址A2，那么示例的，如图5-3所示，用户终端的下单页面可以显示有两个可选项：“串行”和“并行”，用户YH可以通过用户终端的下单页面输入两个目的地址：A1和A2，然后选择“串行”选项。为了便于用户了解什么是串行的目的地址和并行的目的地址，两个选项可以分别设置一个链接，当用户点击选项链接的标识时，用户可以获得串行的目的地址或并行的目的地址的解释。
此外，用户终端的下单页面也可以显示两个表格，一个表格用于输入多个串行的目的地址，该表格可以如表1所示。另一个表格用于输入多个并行的目的地址，该表格可以如表2所示。当用户YH在表1中输入两个目的地址：A1和A2，用户终端则可以确定A1和A2这两个目的地址为用户期望依次到达的两个串行的目的地址。当用户YH在表2中输入两个目的地址：A1和A2，用户终端则可以确定A1和A2这两个目的地址为用户期望到达的两个并行的目的地址。
表1
目的地址
A1
A2
表2
目的地址 A1 A2
另外，用户YH还可以在用户终端的下单页面上绘制一个路线图，如图5-4所示，用户终端根据路线图中的端点名称，数量以及线段上的指示箭头，可以确定A1和A2这两个目的地址为用户期望依次到达的两个串行的目的地址。
步骤5012、用户终端根据输入信息生成第一订单请求。
以步骤5011中的目的地址A1和A2为例，用户终端根据输入信息生成第一订单请求，该第一订单请求包括下单信息，下单信息包括两个目的地址：A1和A2。进一步的，当用户选择了“串行”选项，或者在表1中输入了两个目的地址，那么下单信息可以包括第一地址类型标识，该第一地址类型标识用于指示A1和A2这两个目的地址为用户期望依次到达的两个串行的目的地址。此外，下单信息还包括起始地址和用户信息，该用户信息包括目标用户的通讯号码，示例的，该目标用户可以为用户YH。可选的，目标用户的通讯号码为目标用户的电话号码。需要补充说明的是，目标用户的通讯号码可以直接采用目标用户的电话号码来表示，也可以采用电话号码中的一部分来表示，还可以采用任一能够唯一指示电话号码的号码标识来表示，本发明实施例对此不做限定。另外，用户信息还可以包括目标用户的标识，可选的，该目标用户的标识为目标用户的姓名，也可以为目标用户姓氏，还可以为目标用户的名。
步骤502、用户终端将第一订单请求发送至打车服务器。
下单信息还包括用户在第一目的地址的停留时间，第一目的地址为n个目的地址中除最后一个目的地址之外的任一目的地址。打车服务器接收到用户终端发送的第一订单请求后，由于下单信息包括第一地址类型标识，该第一地址类型标识用于指示n个目的地址为用户期望依次到达的n个串行的目的地址，所以打车服务器能够根据第一地址类型标识确定n个目的地址为n个串行的目的地址。示例的，地址类型标识可以采用数字来表示，如第一地址类型标识用1来表示，第二地址类型标识用0来表示。第二地址类型标识用于指示n个目的地址为n个并行的目的地址。
以用户YH为例，用户终端向打车服务器发送的第一订单请求的下单信息可以包括：起始地址A0，两个目的地址A1和A2，用户YH的姓名，用户YH的电话号码，以及用户YH在A1的停留时间T′(A1A2)。下单信息还包括第一地址类型标识：1。
步骤503、打车服务器判断起始地址与n个目的地址组成的n+1个地址是否满足第二预设条件。
该第二预设条件为：S1＞S3；或者，T1＞T3；或者，S1＞S3且T1＞T3；其中，S1为n+1个地址中任意相邻两个地址的行驶距离之和，S3为顺序调整后的n+1个地址中任意相邻两个地址的行驶距离之和，T1为n+1个地址中任意相邻两个地址的行驶时间之和，T3为顺序调整后的n+1个地址中任意相邻两个地址的行驶时间之和。可选的，当打车服务器判断起始地址与n个目的地址组成的n+1个地址满足第二预设条件时，执行步骤504；当打车服务器判断n+1个地址不满足第二预设条件时，执行步骤505。
对于起始地址A0，两个目的地址A1和A2来说，调整了目的地址的顺序后，用户YH是先去目的地址A2，再去目的地址A1，将A0和A1之间的行驶距离记为S(A0A1)，将A1和A2之间的行驶距离记为S(A1A2)，将A0和A2之间的行驶距离记为S(A0A2)，将A2和A1之间的行驶距离记为S(A2A1)，将A0和A1之间的行驶时间记为T(A0A1)，将A1和A2之间的行驶时间记为T(A1A2)，将A0和A2之间的行驶时间记为T(A0A2)，将A2和A1之间的行驶时间记为T(A2A1)，那么存在：S1＝S(A0A1)+S(A1A2)，S3＝S(A0A2)+S(A2A1)，T1＝T(A0A1)+T(A1A2)，T3＝T(A0A2)+T(A2A1)，那么S(A0A1)+S(A1A2)＞S(A0A2)+S(A2A1)时，或者，T(A0A1)+T(A1A2)＞T(A0A2)+T(A2A1)时，或者，S(A0A1)+S(A1A2)＞S(A0A2)+S(A2A1)且T(A0A1)+T(A1A2)＞T(A0A2)+T(A2A1)时，打车服务器则可以判断A0，A1和A2满足第二预设条件。
其中，行驶时间
Figure BDA0001114450070000091
S为行驶距离，v为平均速度，λ为道路拥堵率，道路拥堵率用于指示当前道路的拥堵程度，如当前道路的拥堵程度特别高，那么λ可以等于1.5；当前道路的拥堵程度一般高，那么λ可以等于1.2；当前道路不拥堵，那么λ可以等于1。λ的大小可以根据实际应用来设置，本发明实施例对此不做限定。示例的，
Figure BDA0001114450070000092
需要说明的是，当下单信息包括用户在第一目的地址的停留时间时，为了提高计算结果的准确性，计算行驶时间时应该将停留时间考虑进去，比如，已知用户YH在目的地址A1的停留时间T′(A1A2)，那么A1和A2之间的行驶时间
Figure BDA0001114450070000093
步骤504、当n+1个地址满足第二预设条件时，打车服务器调整n个串行的目的地址的顺序。
当起始地址与n个目的地址n+1个地址满足第二预设条件时，打车服务器便可以调整n个串行的目的地址的顺序。以用户YH为例，调整之前两个目的地址的顺序为A1→A2，调整之后两个目的地址的顺序为A2→A1。调整了n个串行的目的地址的顺序之后，执行步骤505。该方法通过第二预设条件，调整多个串行目的地址的顺序，可以降低预定车辆的费用。
步骤505、打车服务器判断第一目的地址是否满足第一预设条件。
其中，第一预设条件为：t1＞a*t2；t1为用户在第一目的地址的停留时间，t2为第一目的地址到第二目的地址的行驶时间，第二目的地址为第一目的地址下一个相邻的目的地址，a大于0且小于1。示例的，a可以等于1/3。以用户YH为例，第一种情况，假设三个地址不满足第二预设条件，打车服务器没有调整两个目的地址的顺序，两个目的地址的顺序仍然为A1→A2，那么打车服务器可以判断目的地址A1是否满足第一预设条件，第一预设条件中的t1＝T′(A1A2)，t2＝T(A1A2)，打车服务器判断t1＞a*t2是否成立，如果成立，则执行步骤506，确定需要拆分第一订单请求，如果不成立，则确定不需要拆分第一订单请求；第二种情况，假设三个地址满足第二预设条件，打车服务器将两个目的地址的顺序调整为了A2→A1，那么打车服务器可以判断目的地址A2是否满足第一预设条件，此时，第一预设条件中的t1＝T′(A2A1)，t2＝T(A2A1)，打车服务器再判断t1＞a*t2是否成立，如果成立，则执行步骤506，确定需要拆分第一订单请求，如果不成立，则确定不需要拆分第一订单请求。
步骤506、当第一目的地址满足第一预设条件时，打车服务器确定需要拆分第一订单请求。
当第一目的地址满足第一预设条件时，打车服务器确定需要拆分第一订单请求。然后执行步骤507，对第一订单请求进行拆分。
步骤507、当需要拆分第一订单请求时，打车服务器根据下单信息将第一订单请求拆分为m个子订单请求。
2≤m≤n且m为整数。打车服务器根据下单信息将第一订单请求拆分为m个子订单请求，再将m个子订单请求作为第二订单请求。具体的，步骤507可以包括：以第一目的地址为分界点，将第一订单请求拆分为第一子订单请求和第二子订单请求，第一子订单请求中的终点为第一目的地址，第二子订单请求的起点为第一目的地址。以步骤505中的第一种情况为例，打车服务器以目的地址A1为分界点，将第一订单请求拆分为两个子订单请求，其中一个子订单请求中的起点为A0，终点为A1，另一个子订单请求中的起点为A1，终点为A2；以步骤505中的第二种情况为例，打车服务器以目的地址A2为分界点，将第一订单请求拆分为两个子订单请求，其中一个子订单请求中的起点为A0，终点为A2，另一个子订单请求中的起点为A2，终点为A1。另外，每个子订单请求还可以包括用户YH的姓名和用户YH的电话号码等。
步骤508、打车服务器向用户终端发送拆分请求。
拆分请求包括m个子订单请求、子订单请求的个数或拆分提示信息，即该拆分请求可以包括拆分好的m个子订单请求，也可以包括子订单请求的个数m，还可以包括拆分提示信息，本发明实施例对该拆分提示信息的具体形式不做限定。打车服务器将订单请求拆分为m个子订单请求后，可以向用户终端发送拆分请求，以便于用户确定是否需要采用本次拆分方案。
步骤509、用户终端向打车服务器发送确认拆分的响应。
如果用户确定需要采用本次拆分方案，用户终端接收确定指令，并向打车服务器发送确认拆分的响应。
步骤510、打车服务器将m个子订单请求分别发送至至少m个不同的车载终端。
具体的，如图5-5所示，步骤510可以包括：
步骤5101、打车服务器将第一子订单请求发送至至少一个第一车载终端。
步骤5102、在确定用户达到第一目的地址且经过预设时间段后，打车服务器将第二子订单请求发送至至少一个第二车载终端。
该预设时间段小于或等于t1。以步骤505中的第一种情况为例，打车服务器先将拆分得到的起点为A0的子订单请求发送至至少一个车载终端，将拆分得到的起点为A1的子订单请求发送至至少一个车载终端，关于打车服务器如何确定出两个车载终端为用户服务的具体过程可以参考现有技术，在此不再赘述。假设打车服务器直接将起点为A0的子订单请求发送至车载终端Z1，那么在用户达到目的地址A1且经过预设时间段后，再将起点为A1的子订单请求直接发送至车载终端Z2。该预设时间段小于或等于用户YH在A1的停留时间T′(A1A2)。图5-6示出了打车服务器分别与车载终端Z1和Z2交互的示意图。需要说明的是，图5-6中未示出步骤510之前的步骤，步骤510之前的步骤可以参考图5-1中的步骤501至509。
步骤511、车载终端向打车服务器发送子订单请求响应。
以步骤505中的第一种情况为例，打车服务器将起点为A0的子订单请求发送至车载终端Z1后，车载终端Z1向打车服务器发送子订单请求响应，该子订单请求响应包括车载终端Z1对应的车辆信息和驾驶员信息。其中，车辆信息可以包括车辆的颜色，型号以及车牌号等，驾驶员信息可以包括驾驶员的姓名和电话号码。同样的，打车服务器将起点为A1的子订单请求发送至车载终端Z2后，车载终端Z2向打车服务器发送子订单请求响应，该子订单请求响应包括车载终端Z2对应的车辆信息和驾驶员信息。
步骤512、打车服务器从至少m个子订单请求响应中选择m个子订单请求响应。
以步骤505中的第一种情况为例，如果打车服务器将两个子订单请求分别发送至一个车载终端，那么打车服务器可以直接将每一个车载终端发送的子订单请求响应发送至用户终端。如果打车服务器将两个子订单请求发送至三个车载终端，三个车载终端中的每个车载终端向打车服务器发送子订单请求响应，打车服务器需要从三个子订单请求响应中选择出两个子订单请求响应，再将这两个子订单请求响应发送至用户终端。
步骤513、打车服务器将m个子订单请求响应发送至用户终端。
以步骤505中的第一种情况为例，打车服务器将车载终端Z1发送的子订单请求响应发送至用户终端，该子订单请求响应包括车载终端Z1对应的车辆信息和驾驶员信息；打车服务器将车载终端Z2发送的子订单请求响应发送至用户终端，该子订单请求响应包括车载终端Z2对应的车辆信息和驾驶员信息。打车服务器每次都是在接收到车载终端发送子订单请求响应后就将该子订单请求响应发送至用户终端的。
本发明实施例提供的订单处理方法适用于单用户去多个串行的目的地址的场景，也适用于多用户去多个串行的目的地址的场景，该方法能够在用户输入多个串行的目的地址的情况下，调整目的地址的顺序，并对第一订单请求进行拆分以完成车辆预定过程，解决了现有技术中单用户或多用户去多个串行的目的地址时，必须用户临时给驾驶员指路，或者依靠驾驶员的经验确定行驶路线的问题，降低了预定车辆的费用，提高了预定的车辆可靠性，提高了用户打车体验。
本发明实施例提供的订单处理方法，该方法中，打车服务器能够根据用户终端发送的第一订单请求中的下单信息，判断是否需要拆分第一订单请求，下单信息包括多个目的地址，当确认需要拆分该第一订单请求时，再根据下单信息将第一订单请求拆分为多个子订单请求，并将该多个子订单请求发送至多个车载终端，相较于现有技术，当用户想去多个串行的目的地址时，该方法能够在确认需要拆分订单请求时，将第一订单请求拆分为多个子订单请求，这样一来，无需用户针对每个目的地址都临时给驾驶员指路，或依靠驾驶员的经验确定行驶路线，提高了预定的车辆可靠性，提高了用户打车体验。
综上所述，本发明实施例提供的订单处理方法，该方法中，打车服务器能够接收用户终端发送的第一订单请求，并对该第一订单请求进行处理，得到第二订单请求，再将第二订单请求发送至车载终端，其中，第一订单请求包括下单信息，该下单信息包括多个目的地址，相较于现有技术，该方法适用于下单信息包括多个目的地址的情况，该方法使得用户在输入多个目的地址时也能成功预订车辆，提高了预定的车辆可靠性，提高了用户打车体验，降低了预定车辆的费用。
图6-1是根据一示例性实施例示出的一种订单处理方法的流程图，本实施例以该订单处理方法应用于图1所示实施环境来举例说明。该订单处理方法可以包括如下几个步骤：
步骤601、用户终端获取第一订单请求。
第一订单请求包括下单信息，下单信息至少包括：n个目的地址，n≥2且n为整数。具体的，用户终端接收用户的输入信息，用户终端根据输入信息生成第一订单请求。输入信息包括n个目的地址。假设用户YH和用户HX当前所处的地址为A0(即起始地址)，用户YH想去目的地址A1，用户HX想去目的地址A2，用户YH为下单者，用户YH可以通过图5-3所示的下单页面输入两个目的地址：A1和A2，然后选择“并行”选项。或者，用户YH在表2中输入两个目的地址：A1和A2。或者，用户YH在下单页面上绘制一个路线图，如图6-2所示，用户终端根据该路线图中的端点名称，数量以及线段上的指示箭头，可以确定A1和A2这两个目的地址为用户期望到达的n个并行的目的地址。下单信息可以包括起始地址和第二地址类型标识，该第二地址类型标识用于指示n个目的地址为n个并行的目的地址。此外，下单信息还包括用户信息，用户信息可以包括用户的通讯号码和用户的标识。
步骤602、用户终端将第一订单请求发送至打车服务器。
打车服务器接收到用户终端发送的第一订单请求后，由于下单信息包括第二地址类型标识，该第二地址类型标识用于指示n个目的地址为用户期望到达的n个并行的目的地址，所以打车服务器能够根据第二地址类型标识确定n个目的地址为n个并行的目的地址。以用户YH和用户HX为例，用户终端向打车服务器发送的第一订单请求的下单信息可以包括起始地址A0，两个目的地址A1和A2，用户YH的姓名，以及用户YH的电话号码。
步骤603、打车服务器判断起始地址与n个目的地址组成的n+1个地址是否满足第三预设条件。
该第三预设条件为：S1＞S2；或者，T1＞T2；或者，S1＞S2且T1＞T2；其中，S1为n+1个地址中任意相邻两个地址的行驶距离之和，S2为起始地址与n个目的地址中每个目的地址的行驶距离之和，T1为n+1个地址中任意相邻两个地址的行驶时间之和，T2为起始地址与n个目的地址中每个目的地址的行驶时间之和。
可选的，当打车服务器判断起始地址与n个目的地址组成的n+1个地址满足第三预设条件时，执行步骤604，确定需要拆分第一订单请求；当打车服务器判断起始地址与n个目的地址组成的n+1个地址不满足第三预设条件时，则确定不拆分第一订单请求。以用户YH和用户HX为例，对于起始地址A0，两个目的地址A1和A2来说，将A0和A1之间的行驶距离记为S(A0A1)，将A1和A2之间的行驶距离记为S(A1A2)，将A0和A2之间的行驶距离记为S(A0A2)，将A0和A1之间的行驶时间记为T(A0A1)，将A1和A2之间的行驶时间记为T(A1A2)，将A0和A2之间的行驶时间记为T(A0A2)，那么存在：S1＝S(A0A1)+S(A1A2)，S2＝S(A0A1)+S(A0A2)，T1＝T(A0A1)+T(A1A2)，T2＝T(A0A1)+T(A0A2)，那么当S(A0A1)+S(A1A2)＞S(A0A1)+S(A0A2)时，或者，T(A0A1)+T(A1A2)＞T(A0Al)+T(A0A2)时，或者，S(A0A1)+S(AiA2)＞S(A0A1)+S(A0A2)且T(A0Al)+T(A1A2)＞T(A0A1)+T(A0A2)时，打车服务器则可以判断A0，A1和A2满足第三预设条件。
其中，行驶时间的计算公式可以参考步骤503中的
Figure BDA0001114450070000141
进行说明，在此不再赘述。
步骤604、当n+1个地址满足第三预设条件时，打车服务器确定需要拆分第一订单请求。
当n+1个地址满足第三预设条件时，打车服务器确定需要拆分第一订单请求，然后执行步骤605，对第一订单请求进行拆分。
步骤605、当需要拆分第一订单请求时，打车服务器根据下单信息将第一订单请求拆分为m个子订单请求。
打车服务器根据下单信息将第一订单请求拆分为m个子订单请求，再将m个子订单请求作为第二订单请求。具体的，步骤605可以包括：根据下单信息将第一订单请求拆分为m个子订单请求，m等于n，每个子订单请求中的起点为起始地址，终点为n个目的地址中的一个目的地址。
进一步的，一方面，下单信息还包括用户信息，该用户信息包括目标用户的通讯号码；每个子订单请求包括起始地址、n个目的地址和目标用户的通讯号码。可选的，用户信息还包括目标用户的标识，每个子订单请求还包括目标用户的标识。
另一方面，下单信息还包括用户信息，该用户信息包括n个用户的通讯号码，以及地址号码对应关系。该地址号码对应关系用于记录目的地址与用户的通讯号码的对应关系，n个用户包括目标用户；每个子订单请求包括起始地址、n个目的地址中的一个目的地址，以及与n个目的地址中的一个目的地址对应的用户的通讯号码。可选的，用户信息还包括目标用户的标识，每个子订单请求还包括目标用户的标识。需要说明的是，每个子订单请求可以包括目的地址，也可以不包括目的地址，当不包括目的地址时，用户可以告诉驾驶员要去的地方是哪里，本发明实施例对此不做限定。
以用户YH和用户HX为例，打车服务器确定需要拆分第一订单请求后，根据下单信息将第一订单请求拆分为两个子订单请求，其中一个子订单请求中的起点为A0，终点为A1，该子订单请求用于为用户YH服务，另一个子订单请求中的起点为A0，终端为A2，该子订单请求用于为用户HX服务。另外，每个子订单请求还包括用户YH的姓名和用户YH的电话号码。上述过程中，由于每个子订单请求中均包括用户YH的电话号码，所以如果为用户YH服务的车辆先到达A0，为用户HX服务的车辆后达到A0，用户YH会先离开A0，用户HX会后离开A0，这样会给用户HX打车带来不便，为了避免这种现象发生，一方面，下单信息还包括用户信息，该用户信息可以包括用户YH的姓名和用户YH的电话号码，一个子订单请求可以包括起始地址A0、两个目的地址A1和A2、用户YH的姓名和用户YH的电话号码，另一个子订单请求可以包括起始地址A0、两个目的地址A1和A2、用户YH的姓名和用户YH的电话号码。由于每个子订单请求均包括A1和A2，所以无论哪辆车辆都可以为用户HX服务，这样一来，如果两辆车辆没有同时达到A0，那么用户YH可以在用户HX离开A0后再离开A0；另一方面，下单信息还包括用户信息，该用户信息可以包括用户YH的姓名、用户YH的电话号码、用户HX的电话号码，以及地址号码对应关系，该地址号码对应关系可以如表3所示，表3中的150xxxxxxxx为用户YH的电话号码，138yyyyyyyy为用户HX的电话号码。打车服务器根据下单信息拆分的一个子订单请求可以包括起始地址A0、目的地址A1、用户YH的姓名和用户YH的电话号码，另一个子订单请求可以包括起始地址A0、目的地址A2、用户YH的姓名和用户HX的电话号码。这样一来，为用户YH服务的车载终端能够获取用户YH的电话号码，为用户HX服务的车载终端能够获取用户HX的电话号码，所以用户YH无需等用户HX离开A0后再离开A0，提高了用户打车体验。
表3
目的地址 用户的通讯号码
A1 150xxxxxxxx
A2 138yyyyyyyy
步骤606、打车服务器向用户终端发送拆分请求。
拆分请求包括m个子订单请求、子订单请求的个数或拆分提示信息。打车服务器将订单请求拆分为m个子订单请求后，可以向用户终端发送拆分请求，以便于用户确定是否需要采用本次拆分方案。
步骤607、用户终端向打车服务器发送确认拆分的响应。
如果用户确定需要采用本次拆分方案，用户终端接收确定指令，并向打车服务器发送确认拆分的响应。
步骤608、打车服务器将m个子订单请求分别发送至至少m个不同的车载终端。
以用户YH和用户HX为例，打车服务器可以将一个子订单请求发送至至少一个车载终端，将另一个子订单请求发送至至少一个车载终端，关于打车服务器如何确定出两个车载终端为用户服务的具体过程可以参考现有技术。
步骤609、车载终端向打车服务器发送子订单请求响应。
该子订单请求响应包括车载终端对应的车辆信息和驾驶员信息。以用户YH和用户HX为例，假设打车服务器直接将一个子订单请求发送至车载终端Z1，将另一个子订单请求发送至车载终端Z2，那么在打车服务器将子订单请求发送至车载终端Z1后，车载终端Z1会向发车服务器发送子订单请求响应，该子订单请求响应包括车载终端Z1对应的车辆信息和驾驶员信息，在打车服务器将子订单请求发送至车载终端Z2后，车载终端Z2会向发车服务器发送子订单请求响应，该子订单请求响应包括车载终端Z2对应的车辆信息和驾驶员信息。打车服务器分别与车载终端Z1和Z2的交互过程可以参考图5-6。
需要补充说明的是，当打车服务器拆分的每个子订单请求包括起始地址、n个目的地址和目标用户的通讯号码时，车载终端需要从n个目的地址中选择一个目的地址作为该子订单请求中的终点。相应的，在车载终端向打车服务器发送子订单请求响应之后，该方法还包括：车载终端显示n个目的地址；车载终端接收用于指示从n个目的地址中选择一个目的地址作为终点的选择指令；车载终端根据选择指令从n个目的地址中选择一个目的地址作为终点。示例的，以用户YH和用户YH为例，假设打车服务器拆分的一个子订单请求可以包括起始地址A0、两个目的地址A1和A2、用户YH的姓名和用户YH的电话号码，另一个子订单请求可以包括起始地址A0、两个目的地址A1和A2、用户YH的姓名和用户YH的电话号码，那么车载终端需要根据用户指示，从两个目的地址A1和A2选择出一个目的地址作为终点，以便于为用户YH或用户YH服务。
步骤610、打车服务器从至少m个子订单请求响应中选择m个子订单请求响应。
以步骤609中的车载终端Z1和车载终端Z2为例，打车服务器在接收到两个车载终端分别发送的子订单请求响应后，直接将两个子订单请求响应发送至用户终端。如果打车服务器接收到多于三个子订单请求响应，需要从三个子订单请求响应中选择出两个子订单请求响应，再将这两个子订单请求响应发送至用户终端。
步骤611、打车服务器将m个子订单请求响应发送至用户终端。
以步骤609中的车载终端Z1和车载终端Z2为例，打车服务器将车载终端Z1发送的子订单请求响应发送至用户终端，该子订单请求响应包括车载终端Z1对应的车辆信息和驾驶员信息；打车服务器将车载终端Z2发送的子订单请求响应发送至用户终端，该子订单请求响应包括车载终端Z2对应的车辆信息和驾驶员信息。打车服务器每次都是在接收到车载终端发送子订单请求响应后就将该子订单请求响应发送至用户终端的。
本发明实施例提供的订单处理方法适用于多用户去多个并行的目的地址的场景，该方法能够在用户输入多个并行的目的地址的情况下，对第一订单请求进行拆分以完成车辆预定过程，解决了现有技术中无法同时满足多个用户的打车需求的问题，该方法无需用户临时给驾驶员指路，或者依靠驾驶员的经验确定行驶路线，提高了预定的车辆可靠性，提高了用户打车体验。
本发明实施例提供的订单处理方法，该方法中，打车服务器能够根据用户终端发送的第一订单请求中的下单信息，判断是否需要拆分第一订单请求，下单信息包括多个目的地址，当确认需要拆分该第一订单请求时，再根据下单信息将第一订单请求拆分为多个子订单请求，并将该多个子订单请求发送至多个车载终端，相较于现有技术，当多个用户想去多个并行的目的地址时，该方法能够在确认需要拆分第一订单请求时，将第一订单请求拆分为多个子订单请求，这样一来，无需用户针对每个目的地址都临时给驾驶员指路，或依靠驾驶员的经验确定行驶路线，提高了预定的车辆可靠性，提高了用户打车体验。
综上所述，本发明实施例提供的订单处理方法，该方法中，打车服务器能够接收用户终端发送的第一订单请求，并对该第一订单请求进行处理，得到第二订单请求，再将第二订单请求发送至车载终端，其中，第一订单请求包括下单信息，该下单信息包括多个目的地址，相较于现有技术，该方法适用于下单信息包括多个目的地址的情况，该方法使得用户在输入多个目的地址时也能成功预订车辆，提高了预定的车辆可靠性，提高了用户打车体验。
图7-1是根据一示例性实施例示出的一种订单处理方法的流程图，本实施例以该订单处理方法应用于图1所示实施环境来举例说明。该订单处理方法可以包括如下几个步骤：
步骤701、用户终端接收用户的输入信息。
输入信息包括n个目的地址。n≥2且n为整数。用户终端可以将包括n个目的地址的第一订单请求发送至打车服务器，由打车服务器采用多种拆分方式对第一订单请求进行拆分，得到多个拆分方案，最后由用户选择出一种满足用户需求的拆分方案。
假设用户YH当前所处的地址为A0(即起始地址)，用户YH想先去目的地址A1，再去目的地址A2，如图5-3所示，用户YH通过用户终端的下单页面输入两个目的地址：A1和A2，但用户未选择“串行”选项。或者，用户终端的下单页面并未有串行”和“并行”两个可选项，也未显示表1和表2所示的表格，在这种情况下，用户终端可以将两个目的地址发送至打车服务器，由打车服务器给用户推荐出多种拆分方案供用户YH选择。
步骤702、用户终端根据输入信息生成第一订单请求。
第一订单请求包括下单信息，该下单信息至少包括：n个目的地址。以用户YH输入两个目的地址：A1和A2为例，下单信息可以包括：起始地址A0，两个目的地址A1和A2，用户YH的姓名，以及用户YH的电话号码。
步骤703、用户终端将第一订单请求发送至打车服务器。
用户终端将生成的第一订单请求发送至打车服务器，以便于打车服务器判断是否需要拆分第一订单请求。
步骤704、打车服务器根据下单信息判断是否需要拆分第一订单请求。
一方面，打车服务器可以将下单信息包括的n个目的地址作为n个串行的目的地址，那么打车服务器根据下单信息判断是否需要拆分第一订单请求的过程可以参考步骤505和步骤506。此外，打车服务器也可以判断是否需要调整n个串行的目的地址的顺序，具体可以参考步骤503和步骤504；另一方面，打车服务器可以将下单信息包括的n个目的地址作为n个并行的目的地址，那么打车服务器根据下单信息判断是否需要拆分第一订单请求的过程可以参考步骤603和步骤604，在此不再赘述。
步骤705、当需要拆分第一订单请求时，打车服务器采用至少两种拆分方式，根据下单信息对第一订单请求进行拆分得到至少两组拆分请求。
每组拆分请求包括：m个待选子订单请求。至少两种拆分方式包括串行拆分方式和并行拆分方式，2≤m≤n且m为整数。以用户YH输入两个目的地址：A1和A2为例，打车服务器采用两种拆分方式，根据下单信息对第一订单请求进行拆分。当打车服务器将n个目的地址作为n个串行的目的地址时，打车服务器可以采用步骤506所述的拆分方式对第一订单请求进行拆分，得到一组拆分请求，该拆分请求包括两个待选子订单请求，其中一个待选子订单请求可以包括：起始地址A0，目的地址A1，用户YH的姓名，以及用户YH的电话号码，另一个待选子订单请求可以包括：目的地址A1(即该待选子订单请求中的起点)，目的地址A2，用户YH的姓名，以及用户YH的电话号码。
当打车服务器将n个目的地址作为n个并行的目的地址时，打车服务器可以采用步骤605所述的拆分方式对第一订单请求进行拆分，得到一组拆分请求，该拆分请求包括两个待选子订单请求，其中，一个子订单请求可以包括起始地址A0，两个目的地址A1和A2，用户YH的姓名和用户YH的电话号码，另一个子订单请求可以包括起始地址A0，两个目的地址A1和A2，用户YH的姓名和用户YH的电话号码。
步骤706、打车服务器向用户终端发送拆分请求。
该拆分请求包括对应于不同拆分方式的至少两组拆分请求。打车服务器得到至少两组拆分请求后，将该至少两组拆分请求发送至用户终端，以便于用户终端从该至少两组拆分请求中确认一组拆分请求。
步骤707、用户终端向打车服务器发送确认拆分的响应。
该响应包括用户终端在至少两组拆分请求中确认的一组目标拆分请求。
以步骤705中的两组拆分请求为例，假设用户终端在该两组拆分请求中确认的一组目标拆分请求为打车服务器将n个目的地址作为n个串行的目的地址时，对第一订单请求进行拆分得到的一组拆分请求，那么用户终端向打车服务器发送确认拆分的响应，该响应包括用户终端在两组拆分请求中确认的一组目标拆分请求。
步骤708、打车服务器将目标拆分请求中的m个待选子订单请求确定为m个子订单请求。
打车服务器接收到用户终端发送的确认拆分的响应后，将该响应中包括的目标拆分请求中的m个待选子订单请求确定为m个子订单请求，并将该m个子订单请求作为第二订单请求。
步骤709、打车服务器将m个子订单请求分别发送至至少m个不同的车载终端。
该步骤可以参考步骤510或步骤608，在此不再赘述。
步骤710、车载终端向打车服务器发送子订单请求响应。
子订单请求响应包括车载终端对应的车辆信息和驾驶员信息。该步骤可以参考步骤511或步骤609，在此不再赘述。
步骤711、打车服务器从至少m个子订单请求响应中选择m个子订单请求响应。
该步骤可以参考步骤512或步骤610，在此不再赘述。
步骤712、打车服务器将m个子订单请求响应发送至用户终端。
该步骤可以参考步骤513或步骤611，在此不再赘述。
本发明实施例提供的订单处理方法适用于多用户去多个目的地址的场景，该方法能够根据用户输入的多个目的地址为用户推荐出多个拆分方案，使得用户能够从多个拆分方案中选择一种拆分方案来完成车辆预定过程，极大满足了用户的打车需求，提高了用户打车体验。该方法通过对用户输入的多个目的地址进行分析，当多个目的地址满足预设条件时，将第一订单请求拆分为多个子订单请求，降低了预定车辆的费用，提高了用户的出行效率，且路径规划较为优化。
本发明实施例提供的订单处理方法，该方法中，打车服务器能够根据用户终端发送的第一订单请求中的下单信息，判断是否需要拆分第一订单请求，下单信息包括多个目的地址，当确认需要拆分该第一订单请求时，再根据下单信息将第一订单请求拆分为多个子订单请求，并将该多个子订单请求发送至多个车载终端，相较于现有技术，当用户想去多个目的地址时，该方法能够在确认需要拆分第一订单请求时，将第一订单请求拆分为多个子订单请求，并给用户推荐出多种拆分方案供用户选择，这样一来，无需用户针对每个目的地址都临时给驾驶员指路，或依靠驾驶员的经验确定行驶路线，提高了预定的车辆可靠性，提高了用户打车体验。
综上所述，本发明实施例提供的订单处理方法，该方法中，打车服务器能够接收用户终端发送的第一订单请求，并对该第一订单请求进行处理，得到第二订单请求，再将第二订单请求发送至车载终端，其中，第一订单请求包括下单信息，该下单信息包括多个目的地址，相较于现有技术，该方法适用于下单信息包括多个目的地址的情况，该方法使得用户在输入多个目的地址时也能成功预订车辆，提高了预定的车辆可靠性，提高了用户打车体验，降低了预定车辆的费用。
图7-2是根据一示例性实施例示出的一种订单处理方法的流程图，本实施例以该订单处理方法应用于图1所示实施环境来举例说明。该订单处理方法可以包括如下几个步骤：
步骤801、用户终端获取第一订单请求。
第一订单请求包括下单信息，下单信息至少包括：n个目的地址，n≥2且n为整数。下单信息还包括第一地址类型标识和起始地址。该第一地址类型标识用于指示n个目的地址为n个串行的目的地址。
步骤801的具体过程可以参考步骤501。
步骤802、用户终端将第一订单请求发送至打车服务器。
打车服务器接收到用户终端发送的第一订单请求后，由于下单信息包括第一地址类型标识，该第一地址类型标识用于指示n个目的地址为用户期望依次到达的n个串行的目的地址，所以打车服务器能够根据第一地址类型标识确定n个目的地址为n个串行的目的地址。
步骤803、打车服务器判断起始地址与n个目的地址组成的n+1个地址是否满足第二预设条件。
该第二预设条件为：S1＞S3；或者，T1＞T3；或者，S1＞S3且T1＞T3；其中，S1为n+1个地址中任意相邻两个地址的行驶距离之和，S3为顺序调整后的n+1个地址中任意相邻两个地址的行驶距离之和，T1为n+1个地址中任意相邻两个地址的行驶时间之和，T3为顺序调整后的n+1个地址中任意相邻两个地址的行驶时间之和。步骤803的具体过程可以参考步骤503。
步骤804、当n+1个地址满足第二预设条件时，打车服务器调整n个串行的目的地址的顺序，得到第二订单请求。
步骤804可以参考步骤504。第二订单请求中的多个目的地址的顺序与第一订单请求包括的下单信息中的多个目的地址的顺序不同。该方法通过第二预设条件，调整多个串行目的地址的顺序，可以降低预定车辆的费用。
步骤805、打车服务器将第二订单请求发送至车载终端。
在打车服务器将第二订单请求发送至车载终端之前，打车服务器可以向用户终端发送调整请求，以便于用户确定是否采用本次调整方案。如果用户确定需要采用本次调整方案，用户终端接收确定指令，并向打车服务器发送确认调整的响应。打车服务器将第二订单请求发送至车载终端之后，车载终端将车载终端对应的车辆信息和驾驶员信息发送至打车服务器，以使打车服务器将对应的车辆信息和驾驶员信息发送至用户终端，完成整个车辆预定过程。打车服务器将第二订单请求发送至一个车载终端，也可以将第二订单请求发送至多个车载终端，当打车服务器将第二订单请求发送至多个车载终端时，需要打车服务器从多个车载终端中选择一个车载终端为用户服务，该选择过程可以参考现有技术。
本发明实施例提供的订单处理方法适用于单用户或多个用户去多个串行的目的地址的场景，该方法能够在用户输入多个串行的目的地址的情况下，对多个目的地址的顺序进行调整，完成车辆预定过程，降低了预定车辆的费用，提高了用户的出行效率，路径规划较为优化。
综上所述，本发明实施例提供的订单处理方法，该方法中，打车服务器能够接收用户终端发送的第一订单请求，并对该第一订单请求进行处理，得到第二订单请求，再将第二订单请求发送至车载终端，其中，第一订单请求包括下单信息，该下单信息包括多个目的地址，相较于现有技术，该方法适用于下单信息包括多个目的地址的情况，该方法使得用户在输入多个目的地址时也能成功预订车辆，提高了预定的车辆可靠性，提高了用户打车体验，降低了预定车辆的费用。
需要说明的是，本发明实施例提供的订单处理方法步骤的先后顺序可以进行适当调整，步骤也可以根据情况进行相应增减，任何熟悉本技术领域的技术人员在本发明揭露的技术范围内，可轻易想到变化的方法，都应涵盖在本发明的保护范围之内，因此不再赘述。
下述为本发明装置实施例，可以用于执行本发明方法实施例。对于本发明装置实施例中未披露的细节，请参照本发明方法实施例。
图8-1是根据一示例性实施例示出的一种订单处理装置的框图，该订单处理装置可以通过软件、硬件或者两者的结合实现成为打车服务器的部分或者全部。该订单处理装置可以包括：
第一接收模块810，用于接收第一订单请求，第一订单请求包括下单信息，下单信息至少包括：n个目的地址，n≥2且n为整数。
处理模块820，用于根据n个目的地址，对第一订单请求进行处理，得到第二订单请求。
第一发送模块830，用于将第二订单请求发送至车载终端。
综上所述，本发明实施例提供的订单处理装置，该装置能够接收用户终端发送的第一订单请求，并对该第一订单请求进行处理，得到第二订单请求，再将第二订单请求发送至车载终端，其中，第一订单请求包括下单信息，该下单信息包括多个目的地址，相较于现有技术，该装置适用于下单信息包括多个目的地址的情况，该装置使得用户在输入多个目的地址时也能成功预订车辆，提高了预定的车辆可靠性。
具体的，如图8-2所示，处理模块820，包括：第一判断子模块8201，用于根据下单信息判断是否需要拆分第一订单请求。拆分子模块8202，用于在需要拆分第一订单请求时，根据下单信息将第一订单请求拆分为m个子订单请求，2≤m≤n且m为整数。处理子模块8203，用于将m个子订单请求作为第二订单请求。相应的，如图8-3所示，第一发送模块830包括：第一发送子模块8301，用于将m个子订单请求分别发送至至少m个不同的车载终端。
进一步的，如图8-4所示，该装置还包括：第二发送模块840，用于向用户终端发送拆分请求，拆分请求包括m个子订单请求、子订单请求的个数或拆分提示信息。第二接收模块850，用于接收用户终端发送的确认拆分的响应。
可选的，下单信息还包括第一地址类型标识，第一地址类型标识用于指示n个目的地址为n个串行的目的地址，下单信息还包括用户在第一目的地址的停留时间，第一目的地址为n个目的地址中除最后一个目的地址之外的任一目的地址，第一判断子模块8201，用于：判断第一目的地址是否满足第一预设条件；在第一目的地址满足第一预设条件时，确定需要拆分第一订单请求。
拆分子模块8202，用于：以第一目的地址为分界点，将第一订单请求拆分为第一子订单请求和第二子订单请求，第一子订单请求中的终点为第一目的地址，第二子订单请求的起点为第一目的地址；其中，第一预设条件为：t1＞a*t2；t1为用户在第一目的地址的停留时间，t2为第一目的地址到第二目的地址的行驶时间，第二目的地址为第一目的地址下一个相邻的目的地址，a大于0且小于1。
具体的，第一发送子模块8301，用于：将第一子订单请求发送至至少一个第一车载终端；在确定用户达到第一目的地址且经过预设时间段后，将第二子订单请求发送至至少一个第二车载终端，预设时间段小于或等于t1。
进一步的，如图8-2所示，下单信息还包括起始地址，处理模块820还包括：第二判断子模块8204，用于判断起始地址与n个目的地址组成的n+1个地址是否满足第二预设条件。调整子模块8205，用于在n+1个地址满足第二预设条件时，调整n个串行的目的地址的顺序。其中，第二预设条件为：S1＞S3；或者，T1＞T3；或者，S1＞S3且T1＞T3；S1为n+1个地址中任意相邻两个地址的行驶距离之和，S3为顺序调整后的n+1个地址中任意相邻两个地址的行驶距离之和，T1为n+1个地址中任意相邻两个地址的行驶时间之和，T3为顺序调整后的n+1个地址中任意相邻两个地址的行驶时间之和。
可选的，下单信息还包括起始地址和第二地址类型标识，第二地址类型标识用于指示n个目的地址为n个并行的目的地址，第一判断子模块8201，用于：判断起始地址与n个目的地址组成的n+1个地址是否满足第三预设条件；在n+1个地址满足第三预设条件时，确定需要拆分第一订单请求。拆分子模块8202，用于：根据下单信息将第一订单请求拆分为m个子订单请求，m等于n，每个子订单请求中的起点为起始地址，终点为n个目的地址中的一个目的地址。其中，第三预设条件为：S1＞S2；或者，T1＞T2；或者，S1＞S2且T1＞T2；S1为n+1个地址中任意相邻两个地址的行驶距离之和，S2为起始地址与n个目的地址中每个目的地址的行驶距离之和，T1为n+1个地址中任意相邻两个地址的行驶时间之和，T2为起始地址与n个目的地址中每个目的地址的行驶时间之和。
一方面，下单信息还包括用户信息，用户信息包括目标用户的通讯号码，每个子订单请求包括起始地址、n个目的地址和目标用户的通讯号码。可选的，用户信息还包括目标用户的标识，每个子订单请求还包括目标用户的标识。目标用户的通讯号码可以采用目标用户的电话号码来直接表示，也可以采用电话号码中的一部分来表示，还可以采用任一能够唯一指示电话号码的号码标识来表示，本发明实施例对此不做限定。示例的，目标用户的标识为目标用户的姓名。另一方面，下单信息还包括用户信息，用户信息包括n个用户的通讯号码，以及地址号码对应关系，地址号码对应关系用于记录目的地址与用户的通讯号码的对应关系，n个用户包括目标用户，每个子订单请求包括起始地址、n个目的地址中的一个目的地址，以及与n个目的地址中的一个目的地址对应的用户的通讯号码。可选的，用户信息还包括目标用户的标识，每个子订单请求还包括目标用户的标识。
可选的，拆分子模块8202，用于：采用至少两种拆分方式，根据下单信息对第一订单请求进行拆分得到至少两组拆分请求，每组拆分请求包括：m个待选子订单请求，至少两种拆分方式包括串行拆分方式和并行拆分方式；向用户终端发送拆分请求，拆分请求包括对应于不同拆分方式的至少两组拆分请求；接收用户终端发送的确认拆分的响应，响应包括用户终端在至少两组拆分请求中确认的一组目标拆分请求；将目标拆分请求中的m个待选子订单请求确定为m个子订单请求。
进一步的，如图8-4所示，该装置还包括：第三接收模块860，用于接收至少m个不同的车载终端分别发送的子订单请求响应，子订单请求响应包括车载终端对应的车辆信息和驾驶员信息；选择模块870，用于从至少m个子订单请求响应中选择m个子订单请求响应；第三发送模块880，用于将m个子订单请求响应发送至用户终端。图8-4中其他标记含义可以参考图8-1进行说明。
可选的，下单信息还包括第一地址类型标识和起始地址，第一地址类型标识用于指示n个目的地址为n个串行的目的地址，处理模块820，用于：判断起始地址与n个目的地址组成的n+1个地址是否满足第二预设条件；当n+1个地址满足第二预设条件时，调整n个串行的目的地址的顺序，得到第二订单请求；其中，第二预设条件为：S1＞S3；或者，T1＞T3；或者，S1＞S3且T1＞T3；S1为n+1个地址中任意相邻两个地址的行驶距离之和，S3为顺序调整后的n+1个地址中任意相邻两个地址的行驶距离之和，T1为n+1个地址中任意相邻两个地址的行驶时间之和，T3为顺序调整后的n+1个地址中任意相邻两个地址的行驶时间之和。
本发明实施例提供的订单处理装置，该装置能够根据用户终端发送的第一订单请求中的下单信息，判断是否需要拆分第一订单请求，下单信息包括多个目的地址，当确认需要拆分该第一订单请求时，再根据下单信息将第一订单请求拆分为多个子订单请求，并将该多个子订单请求发送至多个车载终端，该装置还可以不拆分第一订单请求，根据预设条件调整多个目的地址的顺序，降低预定车辆的费用。相较于现有技术，当用户想去多个目的地址时，该装置能够在确认需要拆分第一订单请求时，将第一订单请求拆分为多个子订单请求，这样一来，无需用户针对每个目的地址都临时给驾驶员指路，或依靠驾驶员的经验确定行驶路线，提高了预定的车辆可靠性，提高了用户打车体验。
综上所述，本发明实施例提供的订单处理装置，该装置能够接收用户终端发送的第一订单请求，并对该第一订单请求进行处理，得到第二订单请求，再将第二订单请求发送至车载终端，其中，第一订单请求包括下单信息，该下单信息包括多个目的地址，相较于现有技术，该装置适用于下单信息包括多个目的地址的情况，该装置使得用户在输入多个目的地址时也能成功预订车辆，提高了预定的车辆可靠性，提高了用户打车体验，降低了预定车辆的费用。
图9-1是根据一示例性实施例示出的一种订单处理装置的框图，该订单处理装置可以通过软件、硬件或者两者的结合实现成为用户终端的部分或者全部。该订单处理装置可以包括：
获取模块910，用于获取第一订单请求，第一订单请求包括下单信息，下单信息至少包括：n个目的地址，n≥2且n为整数。
第一发送模块920，用于将第一订单请求发送至打车服务器，以使打车服务器根据n个目的地址对第一订单请求进行处理，得到第二订单请求，并将第二订单请求发送至车载终端。
综上所述，本发明实施例提供的订单处理装置，该装置能够将第一订单请求发送至打车服务器，使得打车服务器根据第一订单请求包括的下单信息中的多个目的地址，对第一订单请求进行处理，得到第二订单请求，并将第二订单请求发送至车载终端，相较于现有技术，该装置适用于下单信息包括多个目的地址的情况，该装置使得用户在输入多个目的地址时也能成功预订车辆，提高了预定的车辆可靠性。
进一步的，第二订单请求为m个子订单请求，2≤m≤n且m为整数，如图9-2所示，该装置还包括：第一接收模块930，用于接收打车服务器发送的拆分请求，拆分请求包括m个子订单请求、子订单请求的个数或拆分提示信息；第二发送模块940，用于向打车服务器发送确认拆分的响应。
可选的，下单信息还包括第一地址类型标识，第一地址类型标识用于指示n个目的地址为n个串行的目的地址，下单信息还包括用户在第一目的地址的停留时间，第一目的地址为n个目的地址中除最后一个目的地址之外的任一目的地址。
可选的，下单信息还包括起始地址和第二地址类型标识，第二地址类型标识用于指示n个目的地址为n个并行的目的地址。
可选的，下单信息还包括用户信息，用户信息包括目标用户的通讯号码，每个子订单请求包括起始地址、n个目的地址和目标用户的通讯号码。可选的，用户信息还包括目标用户的标识，每个子订单请求还包括目标用户的标识。
可选的，下单信息还包括用户信息，用户信息包括n个用户的通讯号码，以及地址号码对应关系，地址号码对应关系用于记录目的地址与用户的通讯号码的对应关系，n个用户包括目标用户，每个子订单请求包括起始地址、n个目的地址中的一个目的地址，以及与n个目的地址中的一个目的地址对应的用户的通讯号码。可选的，用户信息还包括目标用户的标识，每个子订单请求还包括目标用户的标识。
进一步的，如图9-3所示，该装置还包括：第二接收模块950，用于接收打车服务器发送的拆分请求，拆分请求包括对应于不同拆分方式的至少两组拆分请求，至少两组拆分请求是打车服务器采用至少两种拆分方式，对第一订单请求进行拆分后得到的，每组拆分请求包括：m个待选子订单请求，至少两种拆分方式包括串行拆分方式和并行拆分方式；第三发送模块960，用于向打车服务器发送确认拆分的响应，以使打车服务器将目标拆分请求中的m个待选子订单请求确定为m个子订单请求，响应包括用户终端在至少两组拆分请求中确认的一组目标拆分请求。
如图9-2所示，该装置还包括：第三接收模块970，用于接收打车服务器针对每个子订单请求发送的子订单请求响应，子订单请求响应是车载终端发送给打车服务器的，子订单请求响应包括车载终端对应的车辆信息和驾驶员信息。
具体的，获取模块910，用于：接收用户的输入信息，输入信息包括n个目的地址；根据输入信息生成第一订单请求。
综上所述，本发明实施例提供的订单处理装置，该装置能够将第一订单请求发送至打车服务器，使得打车服务器根据第一订单请求包括的下单信息中的多个目的地址，对第一订单请求进行处理，得到第二订单请求，并将第二订单请求发送至车载终端，相较于现有技术，该装置适用于下单信息包括多个目的地址的情况，该装置使得用户在输入多个目的地址时也能成功预订车辆，提高了预定的车辆可靠性，提高了用户打车体验，降低了预定车辆的费用。
图10-1是根据一示例性实施例示出的一种订单处理装置的框图，该订单处理装置可以通过软件、硬件或者两者的结合实现成为车载终端的部分或者全部。该订单处理装置可以包括：第一接收模块1010，用于接收打车服务器发送的第二订单请求，第二订单请求是打车服务器根据n个目的地址，对第一订单请求进行处理后得到的，第一订单请求包括下单信息，下单信息至少包括：n个目的地址，n≥2且n为整数。
综上所述，本发明实施例提供的订单处理装置，该装置能够接收打车服务器发送的第二订单请求，该第二订单请求是打车服务器根据第一订单请求包括的下单信息中的多个目的地址，对第一订单请求进行处理后得到的，相较于现有技术，该装置适用于下单信息包括多个目的地址的情况，该装置使得用户在输入多个目的地址时也能成功预订车辆，提高了预定的车辆可靠性。
可选的，第二订单请求为m个子订单请求，2≤m≤n且m为整数，如图10-2所示，该装置还包括：发送模块1020，用于向打车服务器发送子订单请求响应，以使打车服务器将子订单请求响应发送至用户终端，子订单请求响应包括车载终端的车辆信息和驾驶员信息。
进一步的，下单信息还包括起始地址、用户信息和第二地址类型标识，第二地址类型标识用于指示n个目的地址为n个并行的目的地址，用户信息包括目标用户的通讯号码，每个子订单请求包括起始地址、n个目的地址和目标用户的通讯号码，如图10-2所示，该装置还包括：显示模块1030，用于显示n个目的地址；第二接收模块1040，用于接收用于指示从n个目的地址中选择一个目的地址作为终点的选择指令；选择模块1050，用于根据选择指令从n个目的地址中选择一个目的地址作为终点。可选的，用户信息还包括目标用户的标识，每个子订单请求还包括目标用户的标识。图10-2中的其他标记含义可以参考图10-1。
综上所述，本发明实施例提供的订单处理装置，该装置能够接收打车服务器发送的第二订单请求，该第二订单请求是打车服务器根据第一订单请求包括的下单信息中的多个目的地址，对第一订单请求进行处理后得到的，相较于现有技术，该装置适用于下单信息包括多个目的地址的情况，该装置使得用户在输入多个目的地址时也能成功预订车辆，提高了预定的车辆可靠性，提高了用户打车体验，降低了预定车辆的费用。
本发明实施例还提供了一种订单处理系统，该系统包括：打车服务器、用户终端和车载终端。
打车服务器用于：接收第一订单请求，第一订单请求包括下单信息，下单信息至少包括：n个目的地址，n≥2且n为整数；根据n个目的地址，对第一订单请求进行处理，得到第二订单请求；将第二订单请求发送至车载终端。
用户终端用于：获取第一订单请求，第一订单请求包括下单信息，下单信息至少包括：n个目的地址，n≥2且n为整数；将第一订单请求发送至打车服务器，以使打车服务器根据n个目的地址对第一订单请求进行处理，得到第二订单请求，并将第二订单请求发送至车载终端。
打车服务器包括图8-1或图8-4所示的订单处理装置；用户终端包括图9-1、图9-2或图9-3所示的订单处理装置；车载终端包括图10-1或图10-2所示的订单处理装置。
综上所述，本发明实施例提供的订单处理系统，该系统中，打车服务器能够接收用户终端发送的第一订单请求，并对该第一订单请求进行处理，得到第二订单请求，再将第二订单请求发送至车载终端，其中，第一订单请求包括下单信息，该下单信息包括多个目的地址，相较于现有技术，该系统适用于下单信息包括多个目的地址的情况，该系统使得用户在输入多个目的地址时也能成功预订车辆，提高了预定的车辆可靠性，提高了用户打车体验，降低了预定车辆的费用。
所属领域的技术人员可以清楚地了解到，为描述的方便和简洁，上述描述的系统，装置和模块的具体工作过程，可以参考前述方法实施例中的对应过程，在此不再赘述。
本领域普通技术人员可以理解实现上述实施例的全部或部分步骤可以通过硬件来完成，也可以通过程序来指令相关的硬件完成，所述的程序可以存储于一种计算机可读存储介质中，上述提到的存储介质可以是只读存储器，磁盘或光盘等。
以上所述仅为本发明的较佳实施例，并不用以限制本发明，凡在本发明的精神和原则之内，所作的任何修改、等同替换、改进等，均应包含在本发明的保护范围之内。

Claims (15)

1.一种订单处理方法，其特征在于，所述方法包括：
接收第一订单请求，所述第一订单请求包括下单信息，所述下单信息至少包括：n个目的地址，n≥2且所述n为整数；
根据所述n个目的地址，对所述第一订单请求进行处理，得到第二订单请求，其中，根据所述n个目的地址，对所述第一订单请求进行处理包括：当所述n个目的地址为n个串行的目的地址时，根据所述下单信息对所述第一订单请求进行拆分，或者，调整所述n个目的地址顺序，当所述n个目的地址为n个并行的目的地址时，根据所述下单信息对所述第一订单请求进行拆分；
将所述第二订单请求发送至车载终端。
2.根据权利要求1所述的方法，其特征在于，所述根据所述n个目的地址，对所述第一订单请求进行处理，得到第二订单请求，包括：
根据所述下单信息判断是否需要拆分所述第一订单请求；当需要拆分所述第一订单请求时，根据所述下单信息将所述第一订单请求拆分为m个子订单请求，2≤m≤n且所述m为整数；
将所述m个子订单请求作为所述第二订单请求；
所述将所述第二订单请求发送至车载终端，包括：
将所述m个子订单请求分别发送至至少m个不同的车载终端。
3.根据权利要求2所述的方法，其特征在于，在所述将所述m个子订单请求分别发送至至少m个不同的车载终端之前，所述方法还包括：
向用户终端发送拆分请求，所述拆分请求包括所述m个子订单请求、子订单请求的个数或拆分提示信息；
接收所述用户终端发送的确认拆分的响应。
4.根据权利要求2或3所述的方法，其特征在于，所述下单信息还包括第一地址类型标识，所述第一地址类型标识用于指示所述n个目的地址为n个串行的目的地址，所述下单信息还包括用户在第一目的地址的停留时间，所述第一目的地址为所述n个目的地址中除最后一个目的地址之外的任一目的地址；
所述根据所述下单信息判断是否需要拆分所述第一订单请求，包括：
判断所述第一目的地址是否满足第一预设条件；
当所述第一目的地址满足所述第一预设条件时，确定需要拆分所述第一订单请求；
所述根据所述下单信息将所述第一订单请求拆分为m个子订单请求，包括：
以所述第一目的地址为分界点，将所述第一订单请求拆分为第一子订单请求和第二子订单请求，所述第一子订单请求中的终点为所述第一目的地址，所述第二子订单请求的起点为所述第一目的地址；
其中，所述第一预设条件为：
t1>a*t2；
所述t1为所述用户在所述第一目的地址的停留时间，所述t2为所述第一目的地址到第二目的地址的行驶时间，所述第二目的地址为所述第一目的地址下一个相邻的目的地址，所述a大于0且小于1。
5.根据权利要求4所述的方法，其特征在于，所述将所述m个子订单请求分别发送至至少m个不同的车载终端，包括：
将所述第一子订单请求发送至至少一个第一车载终端；
在确定所述用户达到所述第一目的地址且经过预设时间段后，将所述第二子订单请求发送至至少一个第二车载终端，所述预设时间段小于或等于所述t1。
6.根据权利要求5所述的方法，其特征在于，所述下单信息还包括起始地址，在所述根据所述下单信息判断是否需要拆分所述第一订单请求之前，所述方法还包括：
判断所述起始地址与所述n个目的地址组成的n+1个地址是否满足第二预设条件；
当所述n+1个地址满足所述第二预设条件时，调整所述n个串行的目的地址的顺序；
其中，所述第二预设条件为：
S1>S3；
或者，T1>T3；
或者，S1>S3且T1>T3；
所述S1为所述n+1个地址中任意相邻两个地址的行驶距离之和，所述S3为顺序调整后的n+1个地址中任意相邻两个地址的行驶距离之和，所述T1为所述n+1个地址中任意相邻两个地址的行驶时间之和，所述T3为顺序调整后的n+1个地址中任意相邻两个地址的行驶时间之和。
7.根据权利要求2或3所述的方法，其特征在于，所述下单信息还包括起始地址和第二地址类型标识，所述第二地址类型标识用于指示所述n个目的地址为n个并行的目的地址，
所述根据所述下单信息判断是否需要拆分所述第一订单请求，包括：
判断所述起始地址与所述n个目的地址组成的n+1个地址是否满足第三预设条件；
当所述n+1个地址满足所述第三预设条件时，确定需要拆分所述第一订单请求；
所述根据所述下单信息将所述第一订单请求拆分为m个子订单请求，包括：
根据所述下单信息将所述第一订单请求拆分为所述m个子订单请求，所述m等于所述n，每个所述子订单请求中的起点为所述起始地址，终点为所述n个目的地址中的一个目的地址；
其中，所述第三预设条件为：
S1>S2；
或者，T1>T2；
或者，S1>S2且T1>T2；
所述S1为所述n+1个地址中任意相邻两个地址的行驶距离之和，所述S2为所述起始地址与所述n个目的地址中每个目的地址的行驶距离之和，所述T1为所述n+1个地址中任意相邻两个地址的行驶时间之和，所述T2为所述起始地址与所述n个目的地址中每个目的地址的行驶时间之和。
8.根据权利要求7所述的方法，其特征在于，
所述下单信息还包括用户信息，所述用户信息包括目标用户的通讯号码，每个所述子订单请求包括所述起始地址、所述n个目的地址和所述目标用户的通讯号码；
所述下单信息还包括用户信息，所述用户信息包括n个用户的通讯号码，以及地址号码对应关系，所述地址号码对应关系用于记录目的地址与用户的通讯号码的对应关系，所述n个用户包括目标用户，每个所述子订单请求包括所述起始地址，所述n个目的地址中的一个目的地址，以及与所述n个目的地址中的一个目的地址对应的用户的通讯号码。
9.根据权利要求2所述的方法，其特征在于，所述根据所述下单信息将所述第一订单请求拆分为m个子订单请求，包括：
采用至少两种拆分方式，根据所述下单信息对所述第一订单请求进行拆分得到至少两组拆分请求，每组所述拆分请求包括：m个待选子订单请求，所述至少两种拆分方式包括串行拆分方式和并行拆分方式；
向用户终端发送拆分请求，所述拆分请求包括对应于不同拆分方式的所述至少两组拆分请求；
接收所述用户终端发送的确认拆分的响应，所述响应包括所述用户终端在所述至少两组拆分请求中确认的一组目标拆分请求；
将所述目标拆分请求中的m个待选子订单请求确定为所述m个子订单请求。
10.根据权利要求2所述的方法，其特征在于，在所述将所述m个子订单请求分别发送至至少m个不同的车载终端之后，所述方法还包括：
接收所述至少m个不同的车载终端分别发送的子订单请求响应，所述子订单请求响应包括车载终端对应的车辆信息和驾驶员信息；
从所述至少m个子订单请求响应中选择m个子订单请求响应；
将所述m个子订单请求响应发送至用户终端。
11.根据权利要求1所述的方法，其特征在于，所述下单信息还包括第一地址类型标识和起始地址，所述第一地址类型标识用于指示所述n个目的地址为n个串行的目的地址，
所述根据所述n个目的地址，对所述第一订单请求进行处理，得到第二订单请求，包括：
判断所述起始地址与所述n个目的地址组成的n+1个地址是否满足第二预设条件；
当所述n+1个地址满足所述第二预设条件时，调整所述n个串行的目的地址的顺序，得到所述第二订单请求；
其中，所述第二预设条件为：
S1>S3；
或者，T1>T3；
或者，S1>S3且T1>T3；
所述S1为所述n+1个地址中任意相邻两个地址的行驶距离之和，所述S3为顺序调整后的n+1个地址中任意相邻两个地址的行驶距离之和，所述T1为所述n+1个地址中任意相邻两个地址的行驶时间之和，所述T3为顺序调整后的n+1个地址中任意相邻两个地址的行驶时间之和。
12.一种订单处理方法，其特征在于，所述方法包括：
获取第一订单请求，所述第一订单请求包括下单信息，所述下单信息至少包括：n个目的地址，n≥2且所述n为整数；
将所述第一订单请求发送至打车服务器，以使所述打车服务器根据所述n个目的地址对所述第一订单请求进行处理，得到第二订单请求，并将所述第二订单请求发送至车载终端，其中，根据所述n个目的地址对所述第一订单请求进行处理包括：当所述n个目的地址为n个串行的目的地址时，根据所述下单信息对所述第一订单请求进行拆分，或者，调整所述n个目的地址顺序，当所述n个目的地址为n个并行的目的地址时，根据所述下单信息对所述第一订单请求进行拆分。
13.一种订单处理装置，其特征在于，所述装置包括：
第一接收模块，用于接收第一订单请求，所述第一订单请求包括下单信息，所述下单信息至少包括：n个目的地址，n≥2且所述n为整数；
处理模块，用于根据所述n个目的地址，对所述第一订单请求进行处理，得到第二订单请求，其中，根据所述n个目的地址，对所述第一订单请求进行处理包括：当所述n个目的地址为n个串行的目的地址时，根据所述下单信息对所述第一订单请求进行拆分，或者，调整所述n个目的地址顺序，当所述n个目的地址为n个并行的目的地址时，根据所述下单信息对所述第一订单请求进行拆分；
第一发送模块，用于将所述第二订单请求发送至车载终端。
14.一种订单处理装置，其特征在于，所述装置包括：
获取模块，用于获取第一订单请求，所述第一订单请求包括下单信息，所述下单信息至少包括：n个目的地址，n≥2且所述n为整数；
第一发送模块，用于将所述第一订单请求发送至打车服务器，以使所述打车服务器根据所述n个目的地址对所述第一订单请求进行处理，得到第二订单请求，并将所述第二订单请求发送至车载终端，其中，根据所述n个目的地址对所述第一订单请求进行处理包括：当所述n个目的地址为n个串行的目的地址时，根据所述下单信息对所述第一订单请求进行拆分，或者，调整所述n个目的地址顺序，当所述n个目的地址为n个并行的目的地址时，根据所述下单信息对所述第一订单请求进行拆分。
15.一种订单处理系统，其特征在于，包括：打车服务器、用户终端和车载终端；
所述打车服务器用于：接收第一订单请求，所述第一订单请求包括下单信息，所述下单信息至少包括：n个目的地址，n≥2且所述n为整数；根据所述n个目的地址，对所述第一订单请求进行处理，得到第二订单请求；将所述第二订单请求发送至所述车载终端；
所述用户终端用于：获取第一订单请求，所述第一订单请求包括下单信息，所述下单信息至少包括：n个目的地址，n≥2且所述n为整数；将所述第一订单请求发送至打车服务器，以使所述打车服务器根据所述n个目的地址对所述第一订单请求进行处理，得到第二订单请求，并将所述第二订单请求发送至所述车载终端；
其中，根据所述n个目的地址对所述第一订单请求进行处理包括：当所述n个目的地址为n个串行的目的地址时，根据所述下单信息对所述第一订单请求进行拆分，或者，调整所述n个目的地址顺序，当所述n个目的地址为n个并行的目的地址时，根据所述下单信息对所述第一订单请求进行拆分。
CN201610825189.7A 2016-09-14 2016-09-14 订单处理方法、装置及系统 Active CN106327311B (zh)

Priority Applications (2)

Application Number Priority Date Filing Date Title
CN201610825189.7A CN106327311B (zh) 2016-09-14 2016-09-14 订单处理方法、装置及系统
US15/680,562 US20180075568A1 (en) 2016-09-14 2017-08-18 Order processing method, apparatus and system

Applications Claiming Priority (1)

Application Number Priority Date Filing Date Title
CN201610825189.7A CN106327311B (zh) 2016-09-14 2016-09-14 订单处理方法、装置及系统

Publications (2)

Publication Number Publication Date
CN106327311A CN106327311A (zh) 2017-01-11
CN106327311B true CN106327311B (zh) 2022-02-15

Family

ID=57787944

Family Applications (1)

Application Number Title Priority Date Filing Date
CN201610825189.7A Active CN106327311B (zh) 2016-09-14 2016-09-14 订单处理方法、装置及系统

Country Status (2)

Country Link
US (1) US20180075568A1 (zh)
CN (1) CN106327311B (zh)

Families Citing this family (8)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
KR101725343B1 (ko) * 2015-03-12 2017-04-26 네이버 주식회사 콜택시 서비스 제공 방법 및 이를 제공하는 콜택시 서비스 서버
CN107784548B (zh) * 2017-02-17 2020-09-29 平安科技（深圳）有限公司 订单处理方法和装置
US20190026671A1 (en) * 2017-07-20 2019-01-24 DTA International FZCO Device, System, and Method for Optimizing Taxi Dispatch Requests
CN111612286B (zh) * 2019-02-25 2023-09-29 北京嘀嘀无限科技发展有限公司 一种订单分配方法、装置、电子设备及存储介质
CN112556707A (zh) * 2019-09-25 2021-03-26 北京京东振世信息技术有限公司 路径规划方法和装置
CN112116112B (zh) * 2020-08-11 2022-05-03 北京嘀嘀无限科技发展有限公司 信息交互方法、装置、存储介质和电子设备
CN112116419A (zh) * 2020-09-01 2020-12-22 汉海信息技术(上海)有限公司 网约车下单方法、装置、电子设备及存储介质
CN113965617A (zh) * 2021-08-26 2022-01-21 天地融科技股份有限公司 一种基于物联网打车的方法、装置及系统

Family Cites Families (11)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US8510315B2 (en) * 2010-12-06 2013-08-13 Microsoft Corporation Prioritizing travel itineraries
CN103680124A (zh) * 2012-09-03 2014-03-26 国民技术股份有限公司 一种出租车叫车系统及方法
CN103971507B (zh) * 2013-01-30 2017-06-13 国民技术股份有限公司 一种召车方法、召车平台及系统
US9599481B2 (en) * 2014-05-06 2017-03-21 Elwha Llc System and methods for identifying one or more transportation vehicle units with or without package delivery obligation for transporting one or more end users
CN104821069A (zh) * 2015-05-25 2015-08-05 重庆蓝岸通讯技术有限公司 一种基于用户手机终端的地铁到站提醒方法
US20160379167A1 (en) * 2015-06-25 2016-12-29 Amazon Technologies, Inc. Dynamic resource allocation and scheduling
CN105234087B (zh) * 2015-10-12 2018-04-17 杨彦明 一种快递自动分拣方法及系统
US10846633B2 (en) * 2015-12-29 2020-11-24 Lyft, Inc. System for selecting drivers for transportation requests with specified time durations
US9792575B2 (en) * 2016-03-11 2017-10-17 Route4Me, Inc. Complex dynamic route sequencing for multi-vehicle fleets using traffic and real-world constraints
CN105930920A (zh) * 2016-04-11 2016-09-07 深圳市联文智能技术有限公司 物流配送管理方法和物流配送管理装置
US20170364968A1 (en) * 2016-06-16 2017-12-21 Conduent Business Services, Llc Method and system for cost sharing in a pooled vehicle

Also Published As

Publication number Publication date
US20180075568A1 (en) 2018-03-15
CN106327311A (zh) 2017-01-11

Similar Documents

Publication Publication Date Title
CN106327311B (zh) 订单处理方法、装置及系统
US12125335B2 (en) Facilitating direct rendezvous for a network service
US12373753B2 (en) Vehicle dispatch system, vehicle dispatch method, server, user terminal, and storage medium
TWI696977B (zh) 用於提供運輸服務的方法和系統
US10425490B2 (en) Service information and configuration user interface
US11810217B2 (en) Method and system for trip invitation
CN107945503B (zh) 顺风车的拼车方法和系统
CN102607568A (zh) 可由与车辆相关的计算系统执行的计算机实施方法
CN110068347A (zh) 用于结合充电需求的路线计划的方法和设备
CN103424121A (zh) 基于云服务器的车载导航方法及系统
CN105407127A (zh) 一种用于乘用工具资源免费共享的方法、装置以及系统
CN102155952A (zh) 车载终端、车辆导航系统及车辆导航方法
CN111383073A (zh) 一种多用户共乘方法及其系统
CN116665479A (zh) 车位推荐方法、装置、电子设备及存储介质
US20200175446A1 (en) System and method for managing taxi dispatch, and program for controlling taxi dispatch requests
TWI674510B (zh) 用於推薦搭乘地點的系統和方法
CN110288417A (zh) 信息处理设备和存储用于汽车共享服务的程序的存储介质
CN108023919A (zh) 一种上车位置推荐方法及装置、服务器
CN111539796B (zh) 一种订单处理方法、装置及存储介质
JP6333341B2 (ja) 情報処理装置、探索領域設定方法及びプログラム
US11407430B2 (en) Information processing device and information processing method
CN104655143A (zh) 利用车载信息系统服务器端的运行路径提供装置及方法
CN110706065A (zh) 订单处理方法及装置、信息显示方法及装置和电子设备
CN117808653B (zh) 基于车联网的数据分析方法、终端设备以及存储介质
US20240070793A1 (en) Order reception system, order reception method, and storage medium

Legal Events

Date Code Title Description
PB01 Publication
PB01 Publication
C10 Entry into substantive examination
SE01 Entry into force of request for substantive examination
GR01 Patent grant
GR01 Patent grant