网约车监管方法、装置、服务器和存储介质与流程

1.本技术实施例涉及数据处理技术领域，尤其涉及一种网约车监管方法、装置、服务器和存储介质。


背景技术：

2.随着互联网技术的发展，依托互联网预约出租汽车的经营服务，即网约车业务应运而生，相比传统的出租汽车预约方式，由于网约车不仅提供运输服务，还有具有服务评价、行驶导航、全程跟踪和后台支付等功能，因此，逐渐成为大众的主要出行方式之一。
3.然而，由于当前存在较多网约车平台，同一个司机可以同时服务于多家网约车平台，乘客下单时，也可以同时对比多家网约车平台提供的订单价格等，如选择价格较低的网约车平台进行下单，这使得网约车平台面临着极大的竞争压力。因此，为加强对网约车平台的管理和提高网约车平台的服务质量，对网约车的跨平台接单行为进行有效的监管成为现有技术中亟需解决的技术问题。


技术实现要素：

4.本技术实施例提供一种网约车监管方法、装置、服务器和存储介质，可以及时掌握网约车的跨平台接单行为，有利于加强对网约车和网约车平台的管理。
5.第一方面，本技术实施例提供一种网约车监管方法，包括：
6.获取目标用户在使用本平台进行下单预估时产生的路径规划信息，所述路径规划信息包括起点、终点、预计出发时间、至少一条规划线路和所述至少一条规划线路对应的预计到达时间；
7.根据本平台签约车辆的反馈信息和所述路径规划信息，确定符合接单条件的候选车辆，所述反馈信息包括定位信息和订单情况；
8.根据所述候选车辆在预设时间段内反馈的定位信息，确定与所述路径规划信息相符的目标车辆；
9.根据所述目标车辆反馈的订单情况，确定所述目标车辆是否存在跨平台接单行为。
10.可选地，所述根据本平台签约车辆的反馈信息和所述路径规划信息，确定符合接单条件的候选车辆，包括：
11.根据所述定位信息，确定所述预计出发时间在所述起点附近的相关车辆；
12.根据所述订单情况，从所述相关车辆中筛选出在预计出发时间没有服务订单的候选车辆。
13.可选地，所述根据所述候选车辆在预设时间段内反馈的定位信息，确定与所述路径规划信息相符的目标车辆，包括：
14.根据所述候选车辆在所述预设时间段内反馈的定位信息，生成所述候选车辆的定位轨迹；
15.将所述预计出发时间在所述起点存在停留和/或下线操作，且，所述定位轨迹与所述目标用户的规划线路重合的候选车辆，确定为所述目标车辆。
16.可选地，所述根据所述目标车辆反馈的订单情况，确定所述目标车辆是否存在跨平台接单行为，包括：
17.根据所述目标车辆反馈的订单情况，确定所述目标车辆在所述预设时间段内是否存在服务订单；
18.若不存在，则确定所述目标车辆存在跨平台接单行为。
19.可选地，所述确定所述目标车辆存在跨平台接单行为之前，所述方法还包括：
20.向所述目标车辆发送载客情况确认请求；
21.接收所述目标车辆反馈的载客情况确认响应；
22.相应地，所述确定所述目标车辆存在跨平台接单行为，包括：
23.若根据所述载客情况确认响应确认所述目标车辆上搭载有乘客，则确定所述目标车辆存在跨平台接单行为。
24.可选地，所述确定所述目标车辆存在跨平台接单行为之前，所述方法还包括：
25.获取目标用户信息，所述目标用户信息包括用户身份信息和用户账号信息；
26.确定本平台是否存在与所述路径规划信息相符的目标订单；
27.若存在，则确认所述目标订单对应的用户身份信息与所述目标用户信息中的用户身份信息是否一致；
28.相应地，所述确定所述目标车辆存在跨平台接单行为，包括：
29.若不一致，则确定所述目标车辆存在跨平台接单行为。
30.可选地，所述确定所述目标车辆存在跨平台接单行为之后，所述方法还包括：
31.获取目标用户信息和目标车辆信息；
32.将所述路径规划信息、所述目标用户信息和所述目标车辆信息存储到数据库中。
33.第二方面，本技术实施例提供一种网约车监管装置，包括：
34.获取模块，用于获取目标用户在使用本平台进行下单预估时产生的路径规划信息，所述路径规划信息包括起点、终点、预计出发时间、至少一条规划线路和所述至少一条规划线路对应的预计到达时间；
35.处理模块，用于根据本平台签约车辆的反馈信息和所述路径规划信息，确定符合接单条件的候选车辆，所述反馈信息包括定位信息和订单情况；根据所述候选车辆在预设时间段内反馈的定位信息，确定与所述路径规划信息相符的目标车辆；根据所述目标车辆反馈的订单情况，确定所述目标车辆是否存在跨平台接单行为。
36.第三方面，本技术实施例提供一种服务器，包括存储器、处理器及存储在存储器上并可在处理器上运行的计算机程序，所述处理器执行所述程序时实现如上述第一方面所述的网约车监管方法。
37.第四方面，本技术实施例提供一种计算机可读存储介质，其上存储有计算机程序，该程序被处理器执行时实现如上述第一方面所述的网约车监管方法。
38.本技术实施例提供的网约车监管方法、装置、服务器和存储介质，通过获取目标用户在使用本平台进行下单预估时产生的路径规划信息，根据本平台签约车辆的反馈信息和路径规划信息，确定符合接单条件的候选车辆，根据候选车辆在预设时间段内反馈的定位
信息，确定与路径规划信息相符的目标车辆，根据目标车辆反馈的订单情况，确定目标车辆是否存在跨平台接单行为，可以及时掌握网约车的跨平台接单行为，从而有利于加强对网约车和网约车平台的管理，提高了网约车平台的服务质量。
附图说明
39.图1为本技术实施例提供的一种应用场景示意图；
40.图2为本技术实施例一提供的网约车监管方法的流程示意图；
41.图3为本技术实施例一提供的确定候选车辆的逻辑示意图；
42.图4为本技术实施例二提供的网约车监管方法的流程示意图；
43.图5为本技术实施例三提供的网约车监管装置的结构示意图；
44.图6为本技术实施例四提供的一种服务器的结构示意图。
具体实施方式
45.下面结合附图和实施例对本技术作进一步的详细说明。可以理解的是，此处所描述的具体实施例仅仅用于解释本技术，而非对本技术的限定。另外还需要说明的是，为了便于描述，附图中仅示出了与本技术相关的部分而非全部结构。
46.示例性地，图1为本技术实施例提供的一种应用场景示意图，如图1所示，本技术实施例所提供的网约车监管方法涉及服务器(网约车应用后台)、网约车(对应司机)和用户设备(对应乘客)，在网约车业务中，乘客通过其用户设备上安装的网约车乘客端app进行网约车查找和呼叫，服务器根据乘客在网约车乘客端app中输入的起点、终点、出发时间等为乘客进行路线规划，生成订单，并将订单推送给乘客起点附近的网约车，网约车司机通过网约车司机端app查看订单，并根据情况进行接单。
47.然而，在实际网约车业务中存在这样一种情况，如乘客甲通过本平台的网约车乘客端app进行了下单预估，却最终没有在本平台下单，那么，该乘客是否在其他平台进行了下单？以及本平台签约的网约车是否通过其他平台服务了该笔订单？现有技术中没有很好的解决方案，即现有技术中无法很好地对本平台的网约车的跨平台接单行为及造成的订单流失情况进行监管，在此基础上对网约车及平台的管理存在盲目性。
48.本技术技术方案的主要思路：基于现有技术中存在的技术问题，本技术实施例提供一种对网约车平台所签约的网约车的跨平台接单行为进行监管的技术方案，记录乘客进行下单预估时的规划路径(实际乘客未下单)，根据各网约车在一段时间(与规划路径相关)内反馈的数据，如定位数据、订单数据、上下线数据等，判断各网约车的运行轨迹与乘客规划路径相符，若相符，则相应的网约车通过其他平台服务了该笔订单，即该网约车存在跨平台接单行为，本平台流失了该笔订单。通过对本平台的流失订单情况，如数量、发生时间、发生路段、金额等进行分析，有利于进一步加强对网约车及网约车平台的管理，提高网约车平台服务质量。
49.实施例一
50.图2为本技术实施例一提供的网约车监管方法的流程示意图，本实施例的方法可以由本技术实施例所提供的网约车监管装置执行，该装置可以由软件和/或硬件的方式来实现，并可集成于如图1所示的服务器中。如图2所示，本实施例的网约车监管方法，包括：
51.s101、获取目标用户在使用本平台进行下单预估时产生的路径规划信息。
52.其中，目标用户是指使用本平台进行了下单预估，但没有进行下单的乘客的账户。路径规划信息，包括目标用户在网约车乘客端app输入的信息和服务器(网约车后台)根据目标用户输入的信息得到的规划信息，其中目标用户输入的信息包括起点、终点、预计出发时间等，服务器生成的规划信息包括至少一条规划线路(即由所述起点到所述终点的线路)和至少一条规划线路对应的预计到达时间、预估金额等。
53.可以理解的是，服务器可以根据路网地图和道路实时交通，生成规划信息，假设目标用户输入的起点为a，终点为b，当在a与b之间选择不同的途经点进行路线规划时，就可以生成不同的规划线路，并根据预计出发时间，计算得到不同的预计到达时间。
54.本实施例中，可以事先设置确定目标用户的规则，如当当前时间超过预计出发时，用户仍未完成下单时，则将该用户确定为目标用户，或者，当用户进行下单预估一段时间后，仍未完成下单时，则将用户确定为目标用户。
55.本实施例中，当用户在本平台进行下单预估时，服务器将生成路径规划信息，将路径规划信息与用户标识(如账号)进行对应存储，如存储到特定的数据库中，并对各用户的下单情况进行监控，当确定某用户为目标用户时，从数据库中获取该用户的路径规划信息。
56.s102、根据本平台签约车辆的反馈信息和路径规划信息，确定符合接单条件的候选车辆。
57.其中，反馈信息包括定位信息和订单情况，车辆反馈的定位信息是指车辆的经纬度信息，车辆反馈的订单情况包括车辆有无接单以及接单的时间、单号等信息。定位信息和订单情况，可以由预先设置的反馈规则由车辆主动上报给服务器，如车辆可以按照预设周期进行定位信息的反馈，如每隔1min向服务器反馈一次定位信息，可以在接到新的订单时进行接单情况的反馈。
58.需要说明的是，本实施例中，用户的路径规划信息和车辆的反馈信息的获取及使用等，均是在经过乘客或司机授权的前提下进行的。
59.在一种可能的实施方式中，本实施例中，根据各签约车辆反馈的定位信息，确定预计出发时间在起点附近的相关车辆，根据订单情况，从相关车辆中筛选出在预计出发时间没有服务订单的候选车辆。
60.其中，起点附近是指以起点为中心，以预设距离为半径的一定区域范围，预设距离可以事先设定，如2km。
61.本实施方式中，在确定相关车辆时，不仅需要考虑各签约车辆的位置，即是否在起点附近，还需要考虑各签约车辆在起点附近的时间，即是包括预计出发时间或是否在预计出发时间范围内。在确定候选车辆时，需要筛选出的相关车辆在预计出发时间是否为空闲状态，即有无服务的订单。
62.为便于区分和描述，本实施例中，将根据定位信息筛选出的车辆(初次筛选)，叫做相关车辆；将根据订单情况，进一步筛选出的车辆(二次筛选)，叫做候选车辆。示例性地，图3为本技术实施例一提供的确定候选车辆的逻辑示意图，由图3不难看出，通过上述方式逐渐缩小车辆的筛选范围，从而有助于最终确定出可能存在跨平台接单行为的车辆。
63.s103、根据候选车辆在预设时间段内反馈的定位信息，确定与路径规划信息相符的目标车辆。
64.本实施例中，在通过s102筛选出候选车辆后，进一步地，通过从候选车辆中筛选出与目标用户的路径规划信息相符的车辆，即目标车辆。
65.其中，预设时间段，可以是根据路径规划信息中的预计出发时间和各条规划线路对应的预计到达时间确定的一个时间段。例如，预计出发时间为8：10，规划线路s1的预计到达时间为9：02，规划线路s2的预计到达时间为9：00，规划线路s3的预计到达时间为9：10。
66.在一种可能的实施方式中，可以通过选取预计出发时间或预计出发时间附近的一个时间，作为预设时间段的开始时间，同时选取任意一条规划线路对应的预计到达时间或预计到达时间附近的一个时间作为预设时间段的结束时间，如预设时间段可以为8：10
‑
9：00、8：05
‑
9：00、8：10
‑
9：02等等，从而可以在车辆到达终点附近时筛选出目标车辆，筛选出的目标车辆准确率较高。
67.在另一种可能的实施方式中，可以以预计出发时间与任意一条规划线路对应的预计到达时间作为基准时间段，选取基准时间段的前一部分，如2/3或1/2等，作为预设时间段，如选取基准时间段为8：10
‑
9：10，则可以为预设时间段为8：10
‑
8：50(基准时间段的前2/3)或8：10
‑
8：40(基准时间段的前1/2)，从而可以达到实时筛选目标车辆的目的。
68.上述两种可能的实施方式仅作为确定预设时间段的两种举例，可以理解的是，根据实际情况和应用场景需求，在确定目标车辆时，可以定义不同的预设时间段，此处不做限制。
69.可选地，本实施例中，可以先根据各候选车辆在预设时间段内反馈的定位信息，生成各候选车辆的定位轨迹。定位轨迹由各候选车辆在预设时间段内上报的定位信息构成，用于描述各候选车辆的运动轨迹，每个定位信息可以表示为一个点(定位点)，通过将同一候选车辆的各个点顺次连接起来，得到该候选车辆的定位轨迹。
70.进一步地，通过对各候选车辆的定位轨迹与目标用户的路径规划信息进行比对和分析，确定目标车辆。具体地：
71.(1)确定预计出发时间各候选车辆在起点是否存在停留
72.本实施例中，根据定位轨迹各定位点的分布情况，确定各候选车辆是否存在停留以及停留的时间和位置。例如，根据各候选车辆定位轨迹中的定位点是否存在重合，确定各候选车辆是否存在停留，即停车，则某候选车辆的定位轨迹上的定位点不重合，则说明该候选车辆一直处于行驶状态；若某候选车辆的定位轨迹上有至少两个定位点发生重合，则说明该候选车辆在该重合定位点所在的位置发生停留。
73.由于定位信息及定位信息的上报频率已知，因此，根据重合的定位点的位置(如第几个定位点)、个数等，就可以确定对应候选车辆的发生停留的位置、起始时间、结束时间和停留时长等。
74.需要说明的是，本实施例中，只要某候选车辆的停留位置与路径规划信息中的起点、停留起始时间与路径规划信息中的预计出发时间大致重合，如可以预先设置时间重合范围(如预计出发时间前后3分钟内)和位置重合范围(如起点附近500m以内)，当由定位轨迹确定的停留位置满足位置重合范围，且，停留时间满足时间重合范围时，即可认定预计出发时间该候选车辆在起点存在停留。
75.(2)确定预计出发时间各候选车辆在起点是否存在下线操作
76.在实际操作过程中，若候选车辆的司机要通过其他平台进行接单，则必然要进行
登录平台的切换，此时，就会存在上下线操作行为，因此，通过确定各候选车辆在预计出发时间是否存在下线操作行为，也可以达到对目标车辆进行定位的目的。
77.示例性地，通过对本平台各签约车辆的上下线时间进行记录，如形成各签约车辆的上下线日志，那么，根据预设时间段对各候选车辆的上下日志进行筛选，就可以确定各候选车辆在预设时间段内是否存在上下线操作行为。
78.(3)确定各候选车辆的定位轨迹与目标用户的规划线路是否存在重合
79.本实施例中，当路径规划信息中存在多条规划线路时，需要将每一个候选车辆的定位轨迹与多条规划路径分别进行对比，只要某候选车辆的定位轨迹与路径规划信息中的一条规划线路存在重合，则认为该候选车辆的定位轨迹与目标用户的规划线路重合。
80.本实施例中，可以根据实际情况对选用上述(1)
‑
(3)相应的数据分析方法，生成不同的策略，从候选车辆中筛选出目标车辆。
81.可选地，本实施例中，可以通过采用上述(1)和(3)中的方法对各候选车辆对应的数据分别进行分析，并将预计出发时间在起点存在停留，且，定位轨迹与目标用户的规划线路重合的候选车辆，确定为目标车辆。
82.可选地，本实施例中，可以通过采用上述(2)和(3)中的方法对各候选车辆对应的数据分别进行分析，将预计出发时间在起点存在下线操作，且，定位轨迹与目标用户的规划线路重合的候选车辆，确定为目标车辆。
83.可选地，本实施例中，可以通过采用上述(1)
‑
(3)中的方法对各候选车辆对应的数据分别进行分析，将预计出发时间在起点存在停留，且，预计出发时间在起点存在下线操作，且，定位轨迹与目标用户的规划线路重合的候选车辆，确定为目标车辆。
84.s104、根据目标车辆反馈的订单情况，确定目标车辆是否存在跨平台接单行为。
85.由于不同用户之间的出行路线存在重合的可能性，因此，本实施例中，在根据s103筛选出目标车辆后，本步骤中，还需要进一步结合目标车辆反馈的订单情况，才能最终确定目标车辆是否存在跨平台接单行为。
86.可以理解的是，本平台的签约车辆在每次通过本平台进行接单时，都会将相应的订单信息和接单时间等反馈给平台。因此，在确定出目标车辆后，服务器可以根据目标车辆的标识，如车牌号或对应司机的账号，从相应的数据库中获取目标车辆反馈的接单记录，即订单情况。
87.相应地，本步骤中，根据目标车辆的向本平台反馈的订单情况，确定目标车辆在预设时间段是否存在服务订单，即是否有接单行为，若存在，在确定目标车辆通过本平台服务了其他用户，该其他用户的出行路线与目标用户的出行路线重合。若不存在，则说明该目标车辆存在跨平台接单行为。
88.可选地，在s104之后，当确定目标车辆存在跨平台接单行为，则本实施例中，还可以进一步获取目标用户信息和目标车辆信息，并将路径规划信息、目标用户信息和目标车辆信息存储到数据库中，以便于后续做进一步的数据分析，如分析平台的订单流失数量、原因等，从而制定出更加具有针对性的网约车及网约车平台管理策略。
89.其中，目标用户信息可以包括目标用户的账户名、身份信息等，目标车辆信息可以包括目标车辆的基本信息(如车牌号、车型、平台签约时长等)和目标车辆的对应的司机相关信息(如账户名等)。
90.若上述s101
‑
s104是实时进行的，如预设时间段为基准时间段的前一部分，则本实施例中，为排除目标车辆在空载情况下与目标用户出行路线重合的情况，在确定目标车辆在预设时间段不存在本平台的服务订单之后，进一步，还可以向目标车辆发送载客情况确认请求，以确认目标车辆上是否搭载有乘客，若是，则进一步了证实目标车辆存在跨平台接单行为，否则，证实目标车辆没有跨平台接单行为。
91.本实施例中，为排除同一用户使用不同账号下单的情况，在确定目标车辆在预设时间段不存在本平台的服务订单之后，进一步地，还可以对本平台中订单进行筛选，确定本平台中是否存在与路径规划信息相符的订单，即目标订单。需要说明的是，这里“相符”不仅指规划线路的相符，还包括起点、终点、预计出发时间及预计到达时间的相符。
92.若存在，确认目标订单对应的用户身份信息与目标用户信息中用户身份信息是否一致，若一致，说明目标用户使用了其他账号进行了下单，目标车辆不存在跨平台接单行为；若不一致，说明目标用户没有本平台下单，目标车辆存在跨平台接单行为。
93.本实施例中，通过获取目标用户在使用本平台进行下单预估时产生的路径规划信息，根据本平台签约车辆的反馈信息和路径规划信息，确定符合接单条件的候选车辆，根据候选车辆在预设时间段内反馈的定位信息，确定与路径规划信息相符的目标车辆，根据目标车辆反馈的订单情况，确定目标车辆是否存在跨平台接单行为，可以及时掌握网约车的跨平台接单行为，从而有利于加强对网约车和网约车平台的管理，提高了网约车平台的服务质量。
94.实施例二
95.下面通过一个具体的实施例对本技术的技术方案做进一步说明，示例性地，图4为本技术实施例二提供的网约车监管方法的流程示意图，本实施例的方法可以由本技术实施例所提供的网约车监管装置执行，该装置可以由软件和/或硬件的方式来实现，并可集成于如图1所示的服务器中。如图4所示，本实施例中的网约车监管方法，包括：
96.s201、获取车辆的实时定位信息，并存储到数据库中。
97.本步骤中，司机登录网约车司机端app后，可以由司机实时上报网约车的定位信息(即经纬度信息)，也可以由服务器通过地理信息系统(geographic information system，gis)实时获取网约车的定位信息，并存储至数据库如hbase数据库中。
98.s202、获取乘客进行下单预估时产生的路径规划信息，并存储到数据库中。
99.乘客打开且登录网约车乘客端app后，在乘客授权定位服务的情况下，服务器通过gis系统实时获取乘客定位信息及乘客进行下单预估时产生的路径规划信息，并存储至数据库如hbase数据库中。
100.路径规划信息中包括起点和终点、起点和终点对应的多条规划路径，以及多条规划路径对应的预估金额等。
101.s203、从数据库获取路径规划信息。
102.s204、从数据库获取路径规划信息中起点一定范围内车辆的定位信息。
103.其中，一定范围内的车辆包括正在执行的订单的终点，在路径规划信息中起点一定阈值范围内(例如半径3公里)车辆。
104.s205、从数据库中获取相同时段内实际行驶轨迹与乘客起点和终点及规划路径相符(乘客之前用app尝试下单的规划路径，这个规划路径有可能是一条或多条，车辆实际轨
迹与其中的任一规划路径相符即可)的车辆的定位信息。
105.s206、根据车辆的定位信息，确定车辆在乘客规划路径的起点和终点范围内是否存在定位上报停留(这里指系统判断车辆非等待红绿灯的停留，与通常乘客上车、下车的停留耗费时间区间一致)，和/或，确认车辆司机在乘客规划路径轨迹内是否存在上下线操作(预估的起始时间和到达时间)。
106.若是，执行s207，否则，结束流程。
107.s207、确认车辆在乘客规划路径轨迹内是否没有平台服务订单。
108.若是，执行s208，否则，结束流程。
109.s208、向车辆发送载客情况确认消息，以确认车上是否有乘客。
110.其中，载客情况确认消息可以为push消息。可选地，在向车辆发送载客情况确认消息的同时，还可以同步连接车内视频，以通过视频确认车上是否有乘客。
111.若是，执行s209，否则，结束流程。
112.s209、相同时段内，平台是否没有与乘客身份信息相符的订单。
113.本步骤用以排除乘客使用其他账号下单的情况。若是，执行s210，否则，结束流程。
114.s210、确认司机与乘客均通过其他平台服务完成订单，并记录路径规划信息、乘客信息和车辆信息。
115.本实施例中，通过上述方法对网约车进行监管，一方面，由于不需要依赖第三方平台，有利于节约了网约车的监管成本，另一方面，由于不需要依赖事后收集数据判定网约车服务其他平台订单行为，即监测都可实时进行，满足了对网约车进行实际监管的需求，从而及时发现网约车的跨平台接单行为，最后，通过对存在跨平台接单行为的相关数据进行存储，能够满足事后进一步进行数据分析的需求，有利于加强对网约车及网约车平台的管理。
116.实施例三
117.图5为本技术实施例三提供的网约车监管装置的结构示意图，如图5所示，本实施例中网约车监管装置10包括：
118.获取模块11和处理模块12。
119.获取模块11，用于获取目标用户在使用本平台进行下单预估时产生的路径规划信息，所述路径规划信息包括起点、终点、预计出发时间、至少一条规划线路和所述至少一条规划线路对应的预计到达时间；
120.处理模块12，用于根据本平台签约车辆的反馈信息和所述路径规划信息，确定符合接单条件的候选车辆，所述反馈信息包括定位信息和订单情况；根据所述候选车辆在预设时间段内反馈的定位信息，确定与所述路径规划信息相符的目标车辆；根据所述目标车辆反馈的订单情况，确定所述目标车辆是否存在跨平台接单行为。
121.可选地，处理模块12具体用于：
122.根据所述定位信息，确定所述预计出发时间在所述起点附近的相关车辆；
123.根据所述订单情况，从所述相关车辆中筛选出在预计出发时间没有服务订单的候选车辆。
124.可选地，处理模块12具体用于：
125.根据所述候选车辆在所述预设时间段内反馈的定位信息，生成所述候选车辆的定位轨迹；
126.将所述预计出发时间在所述起点存在停留，且，所述定位轨迹与所述目标用户的规划线路重合的候选车辆，确定为所述目标车辆。
127.可选地，处理模块12具体用于：
128.根据所述目标车辆反馈的订单情况，确定所述目标车辆在所述预设时间段内是否存在服务订单；
129.若不存在，则确定所述目标车辆存在跨平台接单行为。
130.可选地，处理模块12还用于：
131.向所述目标车辆发送载客情况确认请求；
132.接收所述目标车辆反馈的载客情况确认响应；
133.相应地，处理模块12具体用于：
134.若根据所述载客情况确认响应确认所述目标车辆上搭载有乘客，则确定所述目标车辆存在跨平台接单行为。
135.可选地，获取模块11还用于：
136.获取目标用户信息，所述目标用户信息包括用户身份信息和用户账号信息；
137.相应地，处理模块12还用于：
138.确定本平台是否存在与所述路径规划信息相符的目标订单；
139.若存在，则确认所述目标订单对应的用户身份信息与所述目标用户信息中的用户身份信息是否一致；
140.相应地，处理模块12具体用于：
141.若不一致，则确定所述目标车辆存在跨平台接单行为。
142.可选地，获取模块11还用于：
143.获取目标用户信息和目标车辆信息；
144.处理模块12还用于：
145.将所述路径规划信息、所述目标用户信息和所述目标车辆信息存储到数据库中。
146.本实施例所提供的网约车监管装置可执行上述方法实施例所提供的网约车监管方法，具备执行方法相应的功能模块和有益效果。本实施例的实现原理和技术效果与上述方法实施例类似，此处不再一一赘述。
147.实施例四
148.图6为本技术实施例四提供的一种服务器的结构示意图，如图6所示，该服务器20包括存储器21、处理器22及存储在存储器上并可在处理器上运行的计算机程序；服务器20处理器22的数量可以是一个或多个，图6中以一个处理器22为例；服务器20中的处理器22、存储器21可以通过总线或其他方式连接，图6中以通过总线连接为例。
149.存储器21作为一种计算机可读存储介质，可用于存储软件程序、计算机可执行程序以及模块，如本技术实施例中的获取模块11和处理模块12对应的程序指令/模块。处理器22通过运行存储在存储器21中的软件程序、指令以及模块，从而执行服务器的各种功能应用以及数据处理，即实现上述的网约车监管方法。
150.存储器21可主要包括存储程序区和存储数据区，其中，存储程序区可存储操作系统、至少一个功能所需的应用程序；存储数据区可存储根据终端的使用所创建的数据等。此外，存储器21可以包括高速随机存取存储器，还可以包括非易失性存储器，例如至少一个磁
盘存储器件、闪存器件、或其他非易失性固态存储器件。在一些实例中，存储器21可进一步包括相对于处理器22远程设置的存储器，这些远程存储器可以通过网格连接至服务器。上述网格的实例包括但不限于互联网、企业内部网、局域网、移动通信网及其组合。
151.实施例五
152.本技术实施例五还提供一种计算机可读存储介质，其上存储有计算机程序，所述计算机程序在由计算机处理器执行时用于执行一种网约车监管方法，该方法包括：
153.获取目标用户在使用本平台进行下单预估时产生的路径规划信息，所述路径规划信息包括起点、终点、预计出发时间、至少一条规划线路和所述至少一条规划线路对应的预计到达时间；
154.根据本平台签约车辆的反馈信息和所述路径规划信息，确定符合接单条件的候选车辆，所述反馈信息包括定位信息和订单情况；
155.根据所述候选车辆在预设时间段内反馈的定位信息，确定与所述路径规划信息相符的目标车辆；
156.根据所述目标车辆反馈的订单情况，确定所述目标车辆是否存在跨平台接单行为。
157.当然，本技术实施例所提供的一种包计算机可读存储介质，其计算机程序不限于如上所述的方法操作，还可以执行本技术任意实施例所提供的网约车监管方法中的相关操作。
158.通过以上关于实施方式的描述，所属领域的技术人员可以清楚地了解到，本技术可借助软件及必需的通用硬件来实现，当然也可以通过硬件实现，但很多情况下前者是更佳的实施方式。基于这样的理解，本技术的技术方案本质上或者说对现有技术做出贡献的部分可以以软件产品的形式体现出来，该计算机软件产品可以存储在计算机可读存储介质中，如计算机的软盘、只读存储器(read
‑
only memory，rom)、随机存取存储器(random access memory，ram)、闪存(flash)、硬盘或光盘等，包括若干指令用以使得一台计算机设备(可以是个人计算机，服务器，或者网格设备等)执行本技术各个实施例所述的方法。
159.值得注意的是，上述网约车监管装置的实施例中，所包括的各个单元和模块只是按照功能逻辑进行划分的，但并不局限于上述的划分，只要能够实现相应的功能即可；另外，各功能单元的具体名称也只是为了便于相互区分，并不用于限制本技术的保护范围。
160.注意，上述仅为本技术的较佳实施例及所运用技术原理。本领域技术人员会理解，本技术不限于这里所述的特定实施例，对本领域技术人员来说能够进行各种明显的变化、重新调整和替代而不会脱离本技术的保护范围。因此，虽然通过以上实施例对本技术进行了较为详细的说明，但是本技术不仅仅限于以上实施例，在不脱离本技术构思的情况下，还可以包括更多其他等效实施例，而本技术的范围由所附的权利要求范围决定。