CN113515698A - 网约车的个性化定制控制方法、系统、装置和存储介质 - Google Patents

Abstract

本发明公开了一种网约车的个性化定制控制方法、系统、计算机装置和存储介质，个性化定制控制方法包括从第一乘客终端获取用户数据，确定个性化定制控制参数，将个性化定制控制参数发送至司机终端，当司机终端确认个性化定制控制参数，根据个性化定制控制参数控制网约车的车上设备等步骤。本发明可以使得第一乘客能够在上车前对网约车上的附属功能进行提前的个性化定制，使得第一乘客能够尽快获得一个适合自己的网约车乘车氛围，具有良好的用户体验，由于第一乘客对网约车的附属功能的个性化定制可以在上车前完成，因此无需麻烦驾驶员进行设置，既提高第一乘客的自主性，也有助于安全行驶。本发明广泛应用于计算机技术领域。

Description

网约车的个性化定制控制方法、系统、装置和存储介质

技术领域

本发明涉及计算机技术领域，尤其是一种网约车的个性化定制控制方法、系统、计算机装置和存储介质。

背景技术

随着计算机技术等相关技术的发展，汽车除了基本交通功能之外，还能提供更丰富的车载娱乐功能、更精细化适应乘员需求的空调温控功能以及可调的汽车氛围营造等附属功能，从而使得乘员在享受到汽车快速交通方面的便利外，还能有更舒适的乘车体验甚至达到被款待的感觉。

汽车的附属功能主要由驾驶员控制，某些车型也将附属功能的控制交给驾驶员以外的乘员，但由于驾驶位以外的位置空间限制难以布置过多操控设备、驾驶员不能控制的因素过多将影响行车安全等原因，一般只是将调整部分区域的空调出风量或者出风方向等少部分功能交给乘员控制。无论是何种原因，驾驶员以外的乘员如果想调节汽车的附属功能，往往需要请求驾驶员进行操作，而汽车的附属功能越多，其组合的数量就越多，乘员进行个性化定制的选择就越多，操作起来的时间一般更长。对于私家车而言，其具有专属性，即乘员本身就是驾驶员，或者驾驶员是乘员的亲友等，乘员的操作请求容易获得满足。但是网约车具有公共化运营的特性，驾驶员与乘员之间存在隔阂感，乘员从主观或者客观上难以调节汽车的附属功能达到自己喜欢的程度，或者调节时需要较长的时间，既影响行车安全，又影响网约车运营效率。

发明内容

本发明的目的在于提供一种网约车的个性化定制控制方法、系统、计算机装置和存储介质，以解决上述网约车的附属功能难以个性化定制设置的技术问题。

一方面，本发明实施例包括一种网约车的个性化定制控制方法，包括：

从第一乘客终端获取用户数据；

根据所述用户数据，确定个性化定制控制参数；

将所述个性化定制控制参数发送至司机终端；

当检测到满足触发条件，根据所述个性化定制控制参数控制所述网约车的车上设备；所述触发条件包括：所述司机终端确认所述个性化定制控制参数。

进一步地，所述根据所述用户数据，确定个性化定制控制参数，包括：

对所述用户数据进行用户画像分析；

根据所述用户画像分析的结果，确定所述个性化定制控制参数。

进一步地，所述从第一乘客终端获取用户数据，包括：

从所述第一乘客终端获取第一叫车订单；

向所述司机终端推送所述第一叫车订单；

当所述第一叫车订单被所述司机终端查看，接收所述第一乘客终端上传所述用户数据。

进一步地，网约车的个性化定制控制方法还包括：

查找第二乘客终端；所述第二乘客终端发起第二叫车订单，且所述第二叫车订单与所述第一叫车订单被匹配到同一网约车驾驶任务中；

当所述第二乘客终端的上车时间早于所述第一叫车订单对应的上车时间，将所述个性化定制控制参数发送至第二乘客终端，所述触发条件还包括：所述第二乘客终端确认所述个性化定制控制参数。

进一步地，网约车的个性化定制控制方法还包括：

当检测到满足所述触发条件，确定所述司机终端接受所述第一叫车订单；

当检测到不满足所述触发条件，确定所述司机终端拒绝所述第一叫车订单。

进一步地，网约车的个性化定制控制方法还包括：

当所述第一乘客终端的上车时间早于所述第二叫车订单对应的上车时间，将所述个性化定制控制参数发送至第二乘客终端；

当检测到所述第二乘客终端确认所述个性化定制控制参数，确定所述司机终端接受所述第二叫车订单；

当检测到所述第二乘客终端不确认所述个性化定制控制参数，确定所述司机终端拒绝所述第二叫车订单。

进一步地，网约车的个性化定制控制方法还包括：

查找第三乘客终端；所述第三乘客终端发起第三叫车订单，且所述第三叫车订单与所述第一叫车订单被匹配到不同网约车驾驶任务中；

将所述个性化定制控制参数发送至第三乘客终端；

当检测到所述第三乘客终端确认所述个性化定制控制参数，确定所述司机终端接受所述第三叫车订单；

当检测到所述第三乘客终端不确认所述个性化定制控制参数，确定所述司机终端拒绝所述第三叫车订单。

另一方面，本发明实施例还包括一种网约车的个性化定制控制系统，包括：

云服务器，用于从第一乘客终端获取用户数据，根据所述用户数据，确定个性化定制控制参数，将所述个性化定制控制参数发送至司机终端；

车载控制模块，用于当检测到满足触发条件，根据所述个性化定制控制参数控制所述网约车的车上设备；所述触发条件包括：所述司机终端确认所述个性化定制控制参数。

另一方面，本发明实施例还包括一种计算机装置，包括存储器和处理器，所述存储器用于存储至少一个程序，所述处理器用于加载所述至少一个程序以执行实施例中所述的网约车的个性化定制控制方法。

另一方面，本发明实施例还包括一种存储介质，其中存储有处理器可执行的程序，所述处理器可执行的程序在由处理器执行时用于执行实施例中所述的网约车的个性化定制控制方法。

本发明的有益效果是：实施例中的网约车的个性化定制控制方法，可以使得第一乘客能够在上车前对网约车上的附属功能进行提前的个性化定制，并且尊重网约车驾驶员的意愿，在网约车驾驶员接受第一乘客的个性化定制的情况下，才按照第一乘客的个性化定制对网约车上的附属功能进行控制，使得第一乘客能够尽快获得一个适合自己的网约车乘车氛围，具有良好的用户体验，由于第一乘客对网约车的附属功能的个性化定制可以在上车前完成，因此无需麻烦驾驶员进行设置，既提高第一乘客的自主性，也有助于安全行驶。

附图说明

图1为实施例中网约车的个性化定制控制方法的流程图；

图2和图3为执行网约车的个性化定制控制方法的硬件架构框图；

图4为实施例中考虑第二乘客终端(第二乘客已在车上，第一乘客未上车)的情况下，网约车的个性化定制控制方法的流程图；

图5为实施例中考虑第二乘客终端(第一乘客已在车上，第二乘客未上车)的情况下，网约车的个性化定制控制方法的流程图；

图6为实施例中考虑第三乘客终端(已完成或不接受第一乘客的叫车订单)的情况下，网约车的个性化定制控制方法的流程图。

具体实施方式

本实施例中，所提到的网约车可以是指由网约车服务提供商所有，并交由网约车服务提供商所雇用或者委托的网约车司机驾驶的汽车，也可以是指由车主自己所有，并且接入网约车服务提供商并接受网约车服务提供商安排驾驶任务的汽车，还可以是指接入网约车服务提供商并接受网约车服务提供商安排驾驶任务的传统出租车。

网约车服务提供商使用云服务器运营网约车平台。网约车的车主或者驾驶员使用自己的手机、平板电脑等终端或者网约车上的车载设备运行司机侧APP，需要乘坐网约车的乘客使用自己的手机、平板电脑等终端运行乘客侧APP。乘客侧APP和司机侧APP均接入网约车平台，乘客侧APP根据乘客的个人信息、出发地和目的地、预计上车时间、希望乘坐的网约车的车型、是否接受拼车等信息生成叫车订单，并将叫车订单上传到网约车平台，由网约车平台根据叫车订单中的信息以及运营规则选择合适的网约车，将叫车订单分配到该网约车驾驶员的司机侧APP供驾驶员查看，驾驶员可以通过司机侧APP主动选择或者强制选择接受该叫车订单。

本实施例中，所提到的第一乘客终端是指由第一乘客所使用的手机、平板电脑等终端，第二乘客终端是指由第二乘客所使用的手机、平板电脑或者网约车上的车载触摸屏等终端，第三乘客终端是指由第三乘客所使用的手机、平板电脑等终端，司机终端是指由网约车驾驶员所使用的手机、平板电脑或者网约车上的车载触摸屏等终端。由于在同一时间下，终端一般仅供一个乘客使用，第二乘客终端专供第二乘客使用而不会供第一乘客使用，司机终端专供司机使用而不会供第二乘客使用，因此本实施例中可以不区分乘客以及相应的乘客终端、不区分司机以及相应的司机终端。

本实施例中，第一乘客是指刚发出或者正在准备发出叫车订单的乘客，并且第一乘客所发出的叫车订单为第一叫车订单，网约车平台根据第一叫车订单分配到了合适的网约车，第一乘客尚未登上该网约车。

本实施例中，第二乘客是指刚发出或者正在准备发出叫车订单的乘客，并且第二乘客所发出的叫车订单为第二叫车订单，并且第二叫车订单与第一叫车订单的出发地、目的地相同或者相近，例如第一叫车订单的出发地为A地点，目的地为E地点，第一叫车订单的行驶路线为A→B→C→D→E，而“第二叫车订单的出发地为A地点、目的地为D地点”、“第二叫车订单的出发地为C地点、目的地为D地点”、“第二叫车订单的出发地为B地点、目的地为F地点(从B地点到F地点的路线为B→C→D→E→F)”、“第二叫车订单的出发地为G地点(G地点与B地点很接近)、目的地为H地点(H地点与E地点很接近)”等情况下，网约车平台通过“拼单”机制，根据第二叫车订单为第二乘客分配到了合适的网约车，即第一乘客被分配到的那辆网约车，并且网约车执行相同的驾驶任务，该驾驶任务要求网约车走一条路线实现对第一乘客和第二乘客的运输。即通过“拼单”机制，如果第一叫车订单以及第二叫车订单均被网约车司机接单，那么第一乘客与第二乘客至少在部分路段同时在车上成为同车乘客。而且，第一叫车订单对应的上车时间可能迟于也可能早于第二叫车订单对应的上车时间，当第一叫车订单对应的上车时间迟于第二叫车订单对应的上车时间，并且第二叫车订单被网约车平台和司机终端接受，那么在第一乘客发出第一叫车订单时，第二乘客已在乘坐该网约车；当第一叫车订单对应的上车时间早于第二叫车订单对应的上车时间，并且第一叫车订单被网约车平台和司机终端接受，那么在第二乘客发出第二叫车订单时，第一乘客已在乘坐该网约车。

本实施例中，第三乘客是指在完成对第一乘客、第二乘客的运输(或者拒绝对他们的运输)之后，发出或者正在准备发出叫车订单的乘客，并且第三乘客所发出的叫车订单为第三叫车订单，即司机终端接收到第三叫车订单时，对第一乘客、第二乘客的驾驶任务已结束(或者因不满足条件而未发起)，“拼单”机制不会把第三叫车订单与第一叫车订单、第二叫车订单分配到相同的驾驶任务中，即第三乘客不会与第一乘客成为同车乘客。

参照图1，本实施例中的网约车的个性化定制控制方法包括以下步骤：

S1.从第一乘客终端获取用户数据；

S2.根据用户数据，确定个性化定制控制参数；

S3.将个性化定制控制参数发送至司机终端；

S4.当检测到满足触发条件，根据个性化定制控制参数控制网约车的车上设备；其中，触发条件包括：司机终端确认个性化定制控制参数。

本实施例中，执行步骤S1-S4所涉及到的硬件结构如图2和图3所示，其主要包括第一乘客终端、云服务器、车载控制模块和司机终端等部分。其中，云服务器和车载控制模块组成网约车的个性化定制控制系统，可以用于执行本实施例中的网约车的个性化定制控制方法，具体地，可以由云服务器来执行网约车的个性化定制控制方法中的步骤S1-S3，由车载控制模块来执行网约车的个性化定制控制方法中的步骤S4。

其中，第一乘客终端包括网络模块002，第一乘客终端可以运行打车软件001，第一乘客终端可以通过网络模块002和打车软件001，向云服务器发送用户数据。云服务器201具有用户画像分析功能，云服务器201可以直接根据第一乘客终端的指令，通过查表或者解析内容等方式确定个性化定制控制参数，云服务器201也可以在获得第一乘客终端授权的情况下，从第一乘客终端读取历史出行记录、搜索记录、购物记录和通话记录等用户数据，通过大数据分析以及用户画像分析等功能确定个性化定制控制参数。司机终端包括网络模块602，司机终端可以运行打车软件601，司机终端可以通过网络模块602和打车软件601，接收云服务器发送的个性化定制控制参数。

汽车包括汽车网关101、触摸屏131、多媒体控制模块130、扬声器133、CAN总线、空调控制模块120、空调压缩机121、天窗控制模块112、车身控制模块110以及车窗控制模块111等硬件。汽车网关101可以接收云服务器发送的个性化定制控制参数，通过CAN总线将个性化定制控制参数发送到多媒体控制模块130、空调控制模块120、车身控制模块110、车窗控制模块111、天窗控制模块112等车载控制模块，这些控制模块根据个性化定制控制参数分别控制所播放的音乐曲目、电影、音量大小，空调目标温度、出风量，座椅倾斜度和加热温度，车窗和天窗开合度等附属功能参数。汽车上还可以设置氛围灯以及氛围灯控制模块，氛围灯控制模块可以根据个性化定制控制参数控制氛围灯的颜色、亮度和变化组合等。汽车上还可以设置可控的空气清新系统，能够调节车内的气味类型等。由于每个人的喜好和心情不同，对音乐曲目、电影、音量大小、空调目标温度、出风量、座椅倾斜度、加热温度、车窗和天窗开合度、氛围灯的颜色、亮度和变化组合、车内的气味类型等附属功能的具体参数要求不同，因此对上述参数的控制属于个性化定制。

本实施例中，步骤S1，也就是从第一乘客终端获取用户数据这一步骤，包括以下步骤：

S101.从第一乘客终端获取第一叫车订单；

S102.向司机终端推送第一叫车订单；

S103.当第一叫车订单被司机终端查看，接收第一乘客终端上传用户数据。

其中，步骤S103中，驾驶员可以通过司机终端仅查看第一叫车订单的用户资料、出发地和目的地等信息，但暂不接受第一叫车订单。

本实施例中，步骤S2，也就是根据用户数据，确定个性化定制控制参数这一步骤，包括以下步骤：

S201.对用户数据进行用户画像分析；

S202.根据用户画像分析的结果，确定个性化定制控制参数。

步骤S201-S202中，云服务器可以从第一乘客终端读取历史出行记录、搜索记录、购物记录和通话记录等用户数据，通过大数据分析以及用户画像分析等功能对用户数据进行分类，从而为第一乘客分类加上“城市白领”、“喜欢古典音乐的大学生”、“需要安静的环境休息”等标签，根据标签查找相应的个性化定制控制参数。

步骤S3中，云服务器将个性化定制控制参数发送至司机终端，在经过第一乘客终端授权的情况下，驾驶员可以通过司机终端查看个性化定制控制参数。驾驶员可以操作司机终端，确认或不确认个性化定制控制参数。

步骤S4中，可以将触发条件设定为“司机终端确认个性化定制控制参数”。当检测到满足触发条件，也就是“司机终端确认个性化定制控制参数”，那么网约车上的多媒体控制模块、空调控制模块、天窗控制模块和车窗控制模块等控制模块，根据个性化定制控制参数控制网约车的扬声器、空调、天窗和车窗等设备，从而形成相应的组合，营造相应的个性化氛围。

由于步骤S1-S4可以在第一乘客上车前进行，而执行完步骤S1-S4之后，网约车一般经过一定时间才行驶到接第一乘客上车的地点，网约车上受个性化定制控制参数控制的设备可以在这段时间内完成预备工作，例如空调、座椅加热系统等设备在这段时间内制冷或制热至个性化定制控制参数所确定的目标温度，如果多媒体控制模块本地没有存储个性化定制控制参数所指定的音乐曲目或者电影，那么多媒体控制模块可以在这段时间内联网下载，从而使得第一乘客上车时可以立即享受到其个性化定制的氛围。

通过执行步骤S1-S4，可以使得第一乘客能够在上车前对网约车上的附属功能进行提前的个性化定制，并且尊重网约车驾驶员的意愿，在网约车驾驶员接受第一乘客的个性化定制的情况下，才按照第一乘客的个性化定制对网约车上的附属功能进行控制，使得第一乘客能够尽快获得一个适合自己的网约车乘车氛围，具有良好的用户体验。由于第一乘客对网约车的附属功能的个性化定制可以在上车前完成，司机终端确认或不确认个性化定制控制参数的过程容易通过计算机自动实现(例如驾驶员可以将司机终端设置为无论个性化定制控制参数的内容如何，一律确认个性化定制控制参数，或者将司机终端设置为只接受在某些范围内的个性化定制控制参数)，因此无需麻烦驾驶员进行设置，既提高第一乘客的自主性，也有助于安全行驶。

本实施例中，在执行步骤S1-S4的基础上，还可以执行以下步骤：

P1.查找第二乘客终端；其中，第二乘客终端发起第二叫车订单，且第二叫车订单与第一叫车订单被匹配到同一网约车驾驶任务中；

P2.当第二乘客终端的上车时间早于第一叫车订单对应的上车时间，将个性化定制控制参数发送至第二乘客终端，其中，触发条件还包括：第二乘客终端确认个性化定制控制参数。

步骤P2中，由于第二乘客终端发送的第二叫车订单与第一叫车订单属于同一网约车的同一驾驶任务，即第二乘客可能是第一乘客的同车乘客，而第二乘客终端的上车时间早于第一叫车订单对应的上车时间，因此在执行步骤S1-S4和P1-P2时，第二乘客已在网约车上。由于个性化定制控制参数是根据第一乘客终端的用户数据生成的，因此个性化定制控制参数是根据第一乘客的意愿进行控制，由于第一乘客的意愿不一定符合驾驶员的意愿，也不一定符合第二乘客的意愿，因此可以将个性化定制控制参数分别发送至司机终端和第二乘客终端，分别供驾驶员和第二乘客进行确认或不确认。在执行步骤S1-S4的基础上执行步骤P1-P2的原理如图4所示，触发条件变成了“司机终端确认个性化定制控制参数，且第二乘客终端确认个性化定制控制参数”，即只有司机终端和第二乘客终端均确认个性化定制控制参数时，才属于满足触发条件。当满足触发条件，表明驾驶员和第二乘客均接受第一乘客的定制，司机终端接受第一叫车订单，并且根据个性化定制控制参数控制网约车的车上设备；当不满足触发条件，表明驾驶员和第二乘客至少一个不接受第一乘客的定制，司机终端可以拒绝第一叫车订单，不再根据个性化定制控制参数控制网约车的车上设备。无论司机终端接受还是拒绝第一叫车订单，司机终端都可以将接受还是拒绝的结果发送至云服务器，由云服务器通知第一乘客终端。

通过执行步骤P1-P2，可以向未上车的第一乘客提前告知已上车的同车乘客即第二乘客的选择，根据在车上的驾驶员以及第二乘客的意愿来确定是否接收第一乘客的叫车订单，避免因第一乘客、第二乘客和驾驶员对网约车个性化定制配置的要求冲突而产生不快，避免出现不良用户体验。

本实施例中，在执行步骤S1-S4的基础上，还可以执行以下步骤：

P3.当第一乘客终端的上车时间早于第二叫车订单对应的上车时间，将个性化定制控制参数发送至第二乘客终端；

P4.当检测到第二乘客终端确认个性化定制控制参数，确定司机终端接受第二叫车订单；

P5.当检测到第二乘客终端不确认个性化定制控制参数，确定司机终端拒绝第二叫车订单。

步骤P3中，由于第二乘客终端发送的第二叫车订单与第一叫车订单属于同一网约车的同一驾驶任务，即第二乘客可能是第一乘客的同车乘客，而第二乘客终端的上车时间迟第一叫车订单对应的上车时间，因此在执行步骤S1-S4和P3-P5时，驾驶员已接受第一叫车订单，第一乘客可能已在网约车上也可能未在网约车上，而第二乘客希望约到网约车，第二乘客发出的第二叫车订单尚未被驾驶员接受。由于个性化定制控制参数是根据第一乘客终端的用户数据生成的，因此个性化定制控制参数是根据第一乘客的意愿进行控制，由于第一乘客的意愿不一定符合第二乘客的意愿，因此可以将个性化定制控制参数发送至第二乘客终端，供第二乘客进行确认或不确认。在执行步骤S1-S4的基础上执行步骤P3-P5的原理如图5所示，由于步骤S1-S4已执行完毕，网约车的车上设备已被按照个性化定制控制参数进行配置，如果第二乘客确认个性化定制控制参数，表明第二乘客接受第一乘客的意愿，那么司机终端接收第二叫车订单，如果第二乘客不确认个性化定制控制参数，表明第二乘客不接受第一乘客的意愿，那么司机终端拒绝第二叫车订单。无论司机终端接受还是拒绝第二叫车订单，司机终端都可以将接受还是拒绝的结果发送至云服务器，由云服务器通知第二乘客终端。

通过执行步骤P3-P5，可以向未上车的第二乘客提前告知已上车的同车乘客即第一乘客的选择，根据第二乘客的意愿来确定是否接收第二乘客的叫车订单，避免第二乘客上车后因不习惯第一乘客的个性化定制配置而产生不快，避免出现不良用户体验。

本实施例中，在执行步骤S1-S4的基础上，还可以执行以下步骤：

P6.查找第三乘客终端；第三乘客终端发起第三叫车订单，且第三叫车订单与第一叫车订单被匹配到不同网约车驾驶任务中；

P7.将个性化定制控制参数发送至第三乘客终端；

P8.当检测到第三乘客终端确认个性化定制控制参数，确定司机终端接受第三叫车订单；

P9.当检测到第三乘客终端不确认个性化定制控制参数，确定司机终端拒绝第三叫车订单。

步骤P6中，由于第三乘客终端发送的第三叫车订单与第一叫车订单不属于同一驾驶任务，即第三乘客不会是第一乘客的同车乘客。虽然第三乘客不会与第一乘客同时乘坐网约车，但是由于车上的空调、座椅加热、空气清新等系统具有迟滞性，例如第一乘客下车后，短时间内车厢内的气温以及座椅都会维持在第一乘客所选择的温度，车内的空气也会维持在第一乘客所选择的气味，第三乘客不一定接受第一乘客的个性化定制配置。通过执行步骤P6-P9，可以向未上车的第三乘客提前告知前一乘客即第一乘客的选择，根据第三乘客的意愿来确定是否接收第三乘客的叫车订单，避免第三乘客上车后因不习惯第一乘客的个性化定制配置而产生不快，避免出现不良用户体验。

可以通过编写执行本实施例中的网约车的个性化定制控制方法的计算机程序，将该计算机程序写入至计算机装置或者存储介质中，当计算机程序被读取出来运行时，执行本实施例中的网约车的个性化定制控制方法。

需要说明的是，如无特殊说明，当某一特征被称为“固定”、“连接”在另一个特征，它可以直接固定、连接在另一个特征上，也可以间接地固定、连接在另一个特征上。此外，本公开中所使用的上、下、左、右等描述仅仅是相对于附图中本公开各组成部分的相互位置关系来说的。在本公开中所使用的单数形式的“一种”、“所述”和“该”也旨在包括多数形式，除非上下文清楚地表示其他含义。此外，除非另有定义，本实施例所使用的所有的技术和科学术语与本技术领域的技术人员通常理解的含义相同。本实施例说明书中所使用的术语只是为了描述具体的实施例，而不是为了限制本发明。本实施例所使用的术语“和/或”包括一个或多个相关的所列项目的任意的组合。

应当理解，尽管在本公开可能采用术语第一、第二、第三等来描述各种元件，但这些元件不应限于这些术语。这些术语仅用来将同一类型的元件彼此区分开。例如，在不脱离本公开范围的情况下，第一元件也可以被称为第二元件，类似地，第二元件也可以被称为第一元件。本实施例所提供的任何以及所有实例或示例性语言(“例如”、“如”等)的使用仅意图更好地说明本发明的实施例，并且除非另外要求，否则不会对本发明的范围施加限制。

应当认识到，本发明的实施例可以由计算机硬件、硬件和软件的组合、或者通过存储在非暂时性计算机可读存储器中的计算机指令来实现或实施。所述方法可以使用标准编程技术-包括配置有计算机程序的非暂时性计算机可读存储介质在计算机程序中实现，其中如此配置的存储介质使得计算机以特定和预定义的方式操作——根据在具体实施例中描述的方法和附图。每个程序可以以高级过程或面向对象的编程语言来实现以与计算机系统通信。然而，若需要，该程序可以以汇编或机器语言实现。在任何情况下，该语言可以是编译或解释的语言。此外，为此目的该程序能够在编程的专用集成电路上运行。

此外，可按任何合适的顺序来执行本实施例描述的过程的操作，除非本实施例另外指示或以其他方式明显地与上下文矛盾。本实施例描述的过程(或变型和/或其组合)可在配置有可执行指令的一个或多个计算机系统的控制下执行，并且可作为共同地在一个或多个处理器上执行的代码(例如，可执行指令、一个或多个计算机程序或一个或多个应用)、由硬件或其组合来实现。所述计算机程序包括可由一个或多个处理器执行的多个指令。

进一步，所述方法可以在可操作地连接至合适的任何类型的计算平台中实现，包括但不限于个人电脑、迷你计算机、主框架、工作站、网络或分布式计算环境、单独的或集成的计算机平台、或者与带电粒子工具或其它成像装置通信等等。本发明的各方面可以以存储在非暂时性存储介质或设备上的机器可读代码来实现，无论是可移动的还是集成至计算平台，如硬盘、光学读取和/或写入存储介质、RAM、ROM等，使得其可由可编程计算机读取，当存储介质或设备由计算机读取时可用于配置和操作计算机以执行在此所描述的过程。此外，机器可读代码，或其部分可以通过有线或无线网络传输。当此类媒体包括结合微处理器或其他数据处理器实现上文所述步骤的指令或程序时，本实施例所述的发明包括这些和其他不同类型的非暂时性计算机可读存储介质。当根据本发明所述的方法和技术编程时，本发明还包括计算机本身。

计算机程序能够应用于输入数据以执行本实施例所述的功能，从而转换输入数据以生成存储至非易失性存储器的输出数据。输出信息还可以应用于一个或多个输出设备如显示器。在本发明优选的实施例中，转换的数据表示物理和有形的对象，包括显示器上产生的物理和有形对象的特定视觉描绘。

以上所述，只是本发明的较佳实施例而已，本发明并不局限于上述实施方式，只要其以相同的手段达到本发明的技术效果，凡在本发明的精神和原则之内，所做的任何修改、等同替换、改进等，均应包含在本发明保护的范围之内。在本发明的保护范围内其技术方案和/或实施方式可以有各种不同的修改和变化。

Claims (10)

1.一种网约车的个性化定制控制方法，其特征在于，包括：

从第一乘客终端获取用户数据；

根据所述用户数据，确定个性化定制控制参数；

将所述个性化定制控制参数发送至司机终端；

当检测到满足触发条件，根据所述个性化定制控制参数控制所述网约车的车上设备；所述触发条件包括：所述司机终端确认所述个性化定制控制参数。

2.根据权利要求1所述的网约车的个性化定制控制方法，其特征在于，所述根据所述用户数据，确定个性化定制控制参数，包括：

对所述用户数据进行用户画像分析；

根据所述用户画像分析的结果，确定所述个性化定制控制参数。

3.根据权利要求1所述的网约车的个性化定制控制方法，其特征在于，所述从第一乘客终端获取用户数据，包括：

从所述第一乘客终端获取第一叫车订单；

向所述司机终端推送所述第一叫车订单；

当所述第一叫车订单被所述司机终端查看，接收所述第一乘客终端上传所述用户数据。

4.根据权利要求3所述的网约车的个性化定制控制方法，其特征在于，还包括：

查找第二乘客终端；所述第二乘客终端发起第二叫车订单，且所述第二叫车订单与所述第一叫车订单被匹配到同一网约车驾驶任务中；

当所述第二乘客终端的上车时间早于所述第一叫车订单对应的上车时间，将所述个性化定制控制参数发送至第二乘客终端，所述触发条件还包括：所述第二乘客终端确认所述个性化定制控制参数。

5.根据权利要求4所述的网约车的个性化定制控制方法，其特征在于，还包括：

当检测到满足所述触发条件，确定所述司机终端接受所述第一叫车订单；

当检测到不满足所述触发条件，确定所述司机终端拒绝所述第一叫车订单。

6.根据权利要求5所述的网约车的个性化定制控制方法，其特征在于，还包括：

当所述第一乘客终端的上车时间早于所述第二叫车订单对应的上车时间，将所述个性化定制控制参数发送至第二乘客终端；

当检测到所述第二乘客终端确认所述个性化定制控制参数，确定所述司机终端接受所述第二叫车订单；

当检测到所述第二乘客终端不确认所述个性化定制控制参数，确定所述司机终端拒绝所述第二叫车订单。

7.根据权利要求3-6任一项所述的网约车的个性化定制控制方法，其特征在于，还包括：

查找第三乘客终端；所述第三乘客终端发起第三叫车订单，且所述第三叫车订单与所述第一叫车订单被匹配到不同网约车驾驶任务中；

将所述个性化定制控制参数发送至第三乘客终端；

当检测到所述第三乘客终端确认所述个性化定制控制参数，确定所述司机终端接受所述第三叫车订单；

当检测到所述第三乘客终端不确认所述个性化定制控制参数，确定所述司机终端拒绝所述第三叫车订单。

8.一种网约车的个性化定制控制系统，其特征在于，包括：

云服务器，用于从第一乘客终端获取用户数据，根据所述用户数据，确定个性化定制控制参数，将所述个性化定制控制参数发送至司机终端；

车载控制模块，用于当检测到满足触发条件，根据所述个性化定制控制参数控制所述网约车的车上设备；所述触发条件包括：所述司机终端确认所述个性化定制控制参数。

9.一种计算机装置，其特征在于，包括存储器和处理器，所述存储器用于存储至少一个程序，所述处理器用于加载所述至少一个程序以执行权利要求1-7任一项所述的网约车的个性化定制控制方法。

10.一种存储介质，其中存储有处理器可执行的程序，其特征在于，所述处理器可执行的程序在由处理器执行时用于执行权利要求1-7任一项所述的网约车的个性化定制控制方法。

Images