阅读说明：本技术 车辆后背门的控制方法、服务器和车辆 (Control method of vehicle back door, server and vehicle ) 是由 王伟春 于 2019-04-01 设计创作，主要内容包括：本公开涉及一种车辆后背门的控制方法、服务器和车辆。应用于服务器的方法包括：接收终端发送的由用户触发生成的预约请求,所述预约请求包括预约时段；向与所述终端相关联的车辆转发所述预约请求,以使所述车辆在所述预约时段中,确定所述车辆的钥匙处于所述车辆周围的预定范围之内的情况下,控制打开所述车辆的后背门。这样,车辆后背门具有预约开启的功能,不需要用户腾出手或踢腿来开启后背门,极大地方便了用户,尤其是当用户提着重物时,更加体现出该功能的便利性。(The disclosure relates to a control method of a vehicle back door, a server and a vehicle. The method applied to the server comprises the following steps: receiving a reservation request which is sent by a terminal and is triggered and generated by a user, wherein the reservation request comprises a reservation time interval; and forwarding the reservation request to a vehicle associated with the terminal so that the vehicle controls to open a back door of the vehicle when the vehicle determines that a key of the vehicle is within a preset range around the vehicle in the reservation period. Like this, the vehicle back door has the function of reservation opening, does not need the user to vacate the hand or kick the leg and open back door, has greatly made things convenient for the user, especially when the user is carrying the heavy object, embodies the convenience of this function more.)

车辆后背门的控制方法、服务器和车辆

技术领域

本公开涉及车辆控制领域，具体地，涉及一种车辆后背门的控制方法、服务器和车辆。

背景技术

如今，车辆的使用越来越普及，并且，有越来越多的人选择使用私家车出行。车辆的后备箱中空间较大，可以存放较大件的行李和货物，这为人们的出行提供了很大的方便。例如，人们驾驶私家车去逛商场或去大型超市买东西，买的东西较多的话，就放到后备箱里。

通常，车辆后备箱的门，即后背门，可以通过触发设置在车内的微动开关或钥匙上的专用按键来开启。当人在车内时，就可以触发微动开关来开启后背门，当人在车外时，可以通过触发车钥匙上的按键来开启后背门。

在一些配置较高的车型中，在车辆后备箱的底部设置有感应设备，当人们手里拿着大件物品，不方面用手来触发开启后背门时，可以抬起一只脚伸到后备箱底部，当感应设备感应到这一踢腿动作时，就自动将后背门开启。这一方式极大地方便了人们的出行，即使双手都被占用，也能够开启后背门。但是，有时间当人们提着重物时，是很难作出这一踢腿动作的。

发明内容

本公开的目的是提供一种快捷、简单的车辆后背门的控制方法，并提供一种服务器和车辆。

为了实现上述目的，本公开提供一种车辆后背门的控制方法，所述方法包括：终端向服务器发送由用户触发生成的预约请求，所述预约请求包括预约时段；所述服务器向与所述终端相关联的车辆转发所述预约请求；所述车辆在所述预约时段中，确定所述车辆的钥匙处于所述车辆周围的预定范围之内的情况下，控制打开所述车辆的后背门。

可选地，所述终端向服务器发送由用户触发生成的预约请求的步骤之前，所述方法还包括：所述服务器在确定所述车辆已在预约位置驻车的情况下，向所述终端发送询问消息，所述询问消息用于询问是否生成所述预约请求。

可选地，所述终端向服务器发送由用户触发生成的预约请求的步骤之前，所述方法还包括：所述服务器周期性地向所述终端发送询问消息，所述询问消息用于询问是否生成所述预约请求。

可选地，所述服务器在确定所述车辆已在预约位置驻车的情况下，向所述终端发送询问消息的步骤之前，所述方法还包括：所述服务器获取所述车辆的历史停车位置；所述服务器将停车频次大于预定频次的历史停车位置确定为所述预约位置。

可选地，所述询问消息包括用于生成所述预约时段的推荐时段，所述服务器在确定所述车辆已在预约位置驻车的情况下，向所述终端发送询问消息的步骤之前，所述方法还包括：所述服务器获取与所述预约位置对应的历史停车时间；所述服务器根据所述历史停车时间确定所述推荐时段。

可选地，所述服务器在确定所述车辆已在预约位置驻车的情况下，向所述终端发送询问消息的步骤包括：所述服务器在确定所述车辆已在预约位置驻车，且与所述预约位置对应的历史消费金额满足预定条件的情况下，向所述终端发送所述询问消息。

本公开还提供一种车辆后背门的控制方法，应用于服务器。所述方法包括：接收终端发送的由用户触发生成的预约请求，所述预约请求包括预约时段；向与所述终端相关联的车辆转发所述预约请求，以使所述车辆在所述预约时段中，确定所述车辆的钥匙处于所述车辆周围的预定范围之内的情况下，控制打开所述车辆的后背门。

可选地，接收终端发送的由用户触发生成的预约请求的步骤之前，所述方法还包括：在确定所述车辆已在预约位置驻车的情况下，向所述终端发送询问消息，所述询问消息用于询问是否生成所述预约请求。

可选地，接收终端发送的由用户触发生成的预约请求的步骤之前，所述方法还包括：周期性地向所述终端发送询问消息，所述询问消息用于询问是否生成所述预约请求。

可选地，所述在确定所述车辆已在预约位置驻车的情况下，向所述终端发送询问消息的步骤之前，所述方法还包括：获取所述车辆的历史停车位置；将停车频次大于预定频次的历史停车位置确定为所述预约位置。

可选地，所述询问消息包括用于生成所述预约时段的推荐时段，所述在确定所述车辆已在预约位置驻车的情况下，向所述终端发送询问消息的步骤之前，所述方法还包括：获取与所述预约位置对应的历史停车时间；根据所述历史停车时间确定所述推荐时段。

可选地，所述在确定所述车辆已在预约位置驻车的情况下，向所述终端发送询问消息的步骤包括：在确定所述车辆已在预约位置驻车，且与所述预约位置对应的历史消费金额满足预定条件的情况下，向所述终端发送所述询问消息。

本公开还提供一种车辆后背门的控制方法，应用于车辆，所述方法包括：接收服务器转发的预约请求，所述预约请求由用户在与所述车辆相关联的终端上触发生成，并由所述终端发送给所述服务器，所述预约请求包括预约时段；在所述预约时段中，确定所述车辆的钥匙处于所述车辆周围的预定范围之内的情况下，控制打开所述车辆的后背门。

可选地，所述方法还包括：向所述服务器发送所述车辆的位置信息，以使所述服务器在确定所述车辆已在预约位置驻车的情况下，向所述终端发送询问消息，所述询问消息用于询问是否生成所述预约请求。

本公开还提供一种服务器，所述服务器被配置为执行如本公开提供的应用于服务器的方法所执行的步骤。

本公开还提供一种车辆，所述车辆被配置为执行如本公开提供的应用于车辆的方法所执行的步骤。

通过上述技术方案，用户能够通过终端预约车辆后背门的开启，在预约时段中，车辆在判断钥匙处于预定范围之内的情况下，认为用户在车辆附近，此时控制后备门打开。这样，车辆后背门具有预约开启的功能，不需要用户腾出手或踢腿来开启后背门，极大地方便了用户，尤其是当用户提着重物时，更加体现出该功能的便利性。

本公开的其他特征和优点将在随后的

具体实施方式

部分予以详细说明。

附图说明

附图是用来提供对本公开的进一步理解，并且构成说明书的一部分，与下面的具体实施方式一起用于解释本公开，但并不构成对本公开的限制。在附图中：

图1是一示例性实施例提供的车辆后背门的控制方法的情景图；

图2是一示例性实施例提供的车辆后背门的控制方法的流程图；

图3是另一示例性实施例提供的车辆后背门的控制方法的流程图；

图4是又一示例性实施例提供的车辆后背门的控制方法的流程图；

图5是一示例性实施例提供的车辆后背门的控制方法的信令图；

图6是又一示例性实施例提供的车辆后背门的控制方法的流程图；

图7是又一示例性实施例提供的车辆后背门的控制方法的流程图；

图8是根据一示例性实施例示出的一种电子设备的框图；

图9是根据一示例性实施例示出的一种电子设备的框图。

具体实施方式

以下结合附图对本公开的具体实施方式进行详细说明。应当理解的是，此处所描述的具体实施方式仅用于说明和解释本公开，并不用于限制本公开。

图1是一示例性实施例提供的车辆后背门的控制方法的情景图。如图1所示，终端10可以与服务器20通信连接，服务器20可以与车辆30通信连接。其中，通信方式可以包括4G、5G等多种通信方式。服务器例如可以为车联网服务器。终端10可以为电脑、手机、PAD、可穿戴设备等。图1中，终端10以智能手机为例示出。

图2是一示例性实施例提供的车辆后背门的控制方法的流程图。如图2所示，该方法可以包括以下步骤：

在步骤S11中，终端向服务器发送由用户触发生成的预约请求，预约请求包括预约时段。

在步骤S12中，服务器向与终端相关联的车辆转发预约请求。

在步骤S13中，车辆在预约时段中，确定车辆的钥匙处于车辆周围的预定范围之内的情况下，控制打开车辆的后背门。

在另一实施例中，终端向服务器发送由用户触发生成的预约请求的步骤(步骤S11)之前，该方法还包括：服务器在确定车辆已在预约位置驻车的情况下，向终端发送询问消息，询问消息用于询问是否生成预约请求。

在又一实施例中，终端向服务器发送由用户触发生成的预约请求的步骤(步骤S11)之前，该方法还包括：服务器周期性地向终端发送询问消息，询问消息用于询问是否生成预约请求。

在又一实施例中，服务器在确定车辆已在预约位置驻车的情况下，向终端发送询问消息的步骤之前，该方法还包括：服务器获取车辆的历史停车位置；服务器将停车频次大于预定频次的历史停车位置确定为预约位置。

在又一实施例中，询问消息包括用于生成预约时段的推荐时段，服务器在确定车辆已在预约位置驻车的情况下，向终端发送询问消息的步骤之前，该方法还包括：服务器获取与预约位置对应的历史停车时间；服务器根据历史停车时间确定推荐时段。

在又一实施例中，服务器在确定车辆已在预约位置驻车的情况下，向终端发送询问消息的步骤可以包括：服务器在确定车辆已在预约位置驻车，且与预约位置对应的历史消费金额满足预定条件的情况下，向终端发送询问消息。

上述各个实施例提供的方法是由服务器、车辆、终端三者之间互相通信来完成的，其中，各个步骤将在下文中分别针对服务器和车辆的方法中进行详细描述。

图3是一示例性实施例提供的车辆后背门的控制方法的流程图。该方法应用于服务器。如图3所示，所述方法可以包括以下步骤。

在步骤S21中，接收终端发送的由用户触发生成的预约请求，预约请求包括预约时段。

在步骤S22中，向与终端相关联的车辆转发预约请求，以使车辆在预约时段中，确定车辆的钥匙处于车辆周围的预定范围之内的情况下，控制打开车辆的后背门。

其中，终端中可以预先下载专用的APP，用户驻车之后，可以在终端中打开该APP，输入预约时段，发送预约请求。预约时段为一个时间段。例如，上午11：00-11:30。

APP中可以设置有多个选项(例如，多个备选的时段：10：00-10:30、10：30-11:00、11：00-11:30、……)，由用户来选择。服务器中可以存储有终端和车辆之间的关联关系。该关联关系可以是用户预先通过APP进行关联的。服务器在接收到终端发送的预约请求后，查询到与该终端关联的车辆，并向该车辆转发该预约请求。

车辆在接收到预约请求后，车载主机在预约时段指示的时间段开始时，唤醒车辆，并开始检测钥匙是否在车辆周边。如果是，可以认为用户已经回来，控制开启后背门，如果检测不到钥匙，可以认为用户还没有回来，则不开启后背门。其中，车辆可以配置有相关技术中的无钥匙进入系统，以及电动尾门系统。例如，车辆通过无钥匙进入系统中的无线射频识别技术来检测钥匙。预定范围可以是车辆通过其无钥匙进入系统所能够检测到钥匙的范围。

通过上述技术方案，用户能够通过终端预约车辆后背门的开启，在预约时段中，车辆在判断钥匙处于预定范围之内的情况下，认为用户在车辆附近，此时控制后备门打开。这样，车辆后背门具有预约开启的功能，不需要用户腾出手或踢腿来开启后背门，极大地方便了用户，尤其是当用户提着重物时，更加体现出该功能的便利性。

在另一实施例中，在图3的基础上，接收终端发送的由用户触发生成的预约请求的步骤(步骤S21)之前，该方法还可以包括以下步骤：

在确定车辆已在预约位置驻车的情况下，向终端发送询问消息。该询问消息用于询问是否生成预约请求。

其中，车辆中可以设置有GPS定位装置，车辆可以周期性地将自己的位置通过车载T-box发送给服务器。服务器具有计时的功能，可以根据车辆在同一位置的时长来判断车辆是否已驻车，例如，如果车辆在同一位置超过预定时长，就可以认为已驻车。或者，也可以由车辆将已驻车的消息发送给服务器。例如，发动机熄火时，车辆发送已驻车的消息。服务器中可以预先存储有一个或多个预定的预约位置。当车辆的位置在预约位置驻车时，服务器可以向终端的APP推送询问消息。预约位置可以是商场、超市等的停车场位置。因为人们在这些购物消费场所驻车后，很可能购买了较多东西回来，此时非常需要利用上述的预约开启功能。

该实施例中，服务器可以在车辆处于预约位置驻车时开启预约功能。用户可以在终端收到推送的询问消息时，应用该功能。询问消息例如可以为：“是否需要开通预约后背门开启功能？”并附上“是”和“否”的按键。

当车辆在预约位置之外的其他位置驻车的话，服务器可以不开启该功能。这样，通过合理地设置预约位置，使得服务器的资源得到较为合理的利用，避免服务器数据处理量过大造成瘫痪。

在又一实施例中，在图3的基础上，接收终端发送的由用户触发生成的预约请求的步骤(步骤S21)之前，该方法还可以包括以下步骤：

周期性地向终端发送询问消息，该询问消息用于询问是否生成预约请求。

其中，发送询问消息的周期可以预先设置，例如，服务器每小时发送一次询问消息。该实施例中，相比上一实施例，服务器不需要确定车辆的位置以及驻车情况，从而减小了服务器的工作量，加快了服务器的运行速度。

在又一实施例中，在上一实施例的基础上，在确定车辆已在预约位置驻车的情况下，向终端发送询问消息的步骤之前，该方法还包括以下步骤：获取车辆的历史停车位置；将停车频次大于预定频次的历史停车位置确定为预约位置。

在上一实施例中，预约位置可以是服务器统一设置的适用于全部车辆的位置。在该实施例中，每个车辆对应的预约位置可以是根据该车辆自身的历史数据来确定的。不同的车辆的预约位置可以是不同的。

具体地，当历史停车位置的停车频次大于预定频次(例如，每周一次)时，可以将该历史停车位置确定为与该车辆对应的预约位置。

与各个车辆对应的预约位置，也可以是在服务器已存储的多个位置中所选择的位置。即，服务器已存储的多个位置中，停车频次大于预定频次的历史停车位置确定为该车辆的预约位置。该预定的多个位置可以是商场、超市等购物消费场所的停车场。这样，人们进行购物的可能性较大，很可能需要用到该预约功能。

该实施例中，不同车辆的预约位置根据用户的习惯自动生成，这样，预约开启后背门的功能具有一定的针对性，需求性更高。

在又一实施例中，询问消息可以包括用于生成预约时段的推荐时段。在确定车辆已在预约位置驻车的情况下，向终端发送询问消息的步骤之前，该方法还可以包括以下步骤：获取与预约位置对应的历史停车时间；根据历史停车时间确定推荐时段。

其中，推荐时段可以是多个备选的时段，用户可以从推荐时段中选出一个时段作为预约时段。车辆在预约位置驻车、启动的状态可以通过车载T-box发送给服务器，或者，服务器通过车辆位置来判断车辆是否在预约位置驻车、启动。服务器可以统计车辆在预约位置的历史停车时间。历史停车时间在一定程度上体现了用户的习惯。

根据历史停车时间确定推荐时段的具体方式可以是：在本车驻车时间的基础上，加上历史停车时间的平均值，得到预计的用户返回时间，然后，在多个预定的时间段中，将上述预计的用户返回时间所在的时段确定为其中一个推荐时段。还可以将该推荐时段邻近的几个时段也作为推荐时段。在询问消息中可以附带有推荐时段。用户确认该询问消息后，可以将该询问消息中用户确认的推荐时段确定为预约时段。该推荐时段是根据该用户自身习惯(历史停车时间)确定的时段，因此，该推荐时段具有一定的针对性，更符合用户的需求。

举例来说，服务器确定车辆停在预约位置的历史停车时间的平均值为70分钟，当前驻车时间为10：00，则预计的用户返回时间为11:10。预先确定的预定的时间段为每半小时一个时间段(例如，10：00-10:30、10：30-11:00、11：00-11:30、……)，则可以确定一个推荐时段为11：00-11:30，也可以确定三个推荐时段：10：30-11:00、11：00-11:30、11：30-12:00。询问消息中可以包括一个或三个推荐时段。例如，用户收到的推送消息为：“是否需要预约11：00-11:30的后背门开启功能？”并附上“是”和“否”的按键。如果用户点击“是”，则该11：00-11:30的推荐时段成为预约时段。如果用户点击“否”，还可以弹出其他推荐时段。

该实施例中，服务器通过用户自身的历史停车时间，向终端推送询问消息，从而使预约时段更加精准，符合每个用户的具体需求。

在又一实施例中，在确定车辆已在预约位置驻车的情况下，向终端发送询问消息的步骤可以包括：在确定车辆已在预约位置驻车，且与预约位置对应的历史消费金额满足预定条件的情况下，向终端发送询问消息。

其中，与预约位置对应的历史消费金额，可以通过终端中的付款记录(例如，通过支付宝、微信等支付的记录)来确定。终端可以将消费金额发送至服务器，由服务器判断消费金额是否满足预定条件(例如，消费金额是否大于500元人民币)。也可以由终端来判断消费金额是否满足预定条件，并在判定消费金额满足预定条件时，将判断结果发送至服务器。

该实施例中，车主需要同意将消费习惯记录到大数据的云服务系统。由于消费金额在一定程度上体现了用户返回车辆时手提的物品的大小、重量等。可以认为消费金额越多，用户返回车辆时手提的物品越多。这样，当车辆在预约位置驻车，且用户的历史消费金额满足预定条件(例如，大于预定的金额阈值)的情况下，服务器再向终端发送询问消息。此时，能够避免不必要的功能开启，减少了服务器的数据处理量，保障了真正有需求的用户的正常使用。

图4是又一示例性实施例提供的车辆后背门的控制方法的流程图。该实施例应用于车辆。如图4所示，该方法可以包括以下步骤：

在步骤S31中，接收服务器转发的预约请求，预约请求由用户在与车辆相关联的终端上触发生成，并由终端发送给服务器，预约请求包括预约时段。

在步骤S32中，在预约时段中，确定车辆的钥匙处于车辆周围的预定范围之内的情况下，控制打开车辆的后背门。

该实施例与图3的实施例相对应，其中，终端中可以预先下载专用的APP，用户驻车之后，可以在终端中打开该APP，输入预约时段，发送预约请求。预约时段为一个时间段。例如，上午11：00-11:30。

APP中可以设置有多个选项(例如，多个备选的时段：10：00-10:30、10：30-11:00、11：00-11:30、……)，由用户来选择。服务器中可以存储有终端和车辆之间的关联关系。该关联关系可以是用户预先通过APP进行关联的。服务器在接收到终端发送的预约请求后，查询到与该终端关联的车辆，并向该车辆转发该预约请求。

车辆在接收到预约请求后，车载主机在预约时段指示的时间段开始时，唤醒车辆，并开始检测钥匙是否在车辆周边。如果是，可以认为用户已经回来，控制开启后背门，如果检测不到钥匙，可以认为用户还没有回来，则不开启后背门。其中，车辆可以配置有相关技术中的无钥匙进入系统，以及电动尾门系统。例如，车辆通过无钥匙进入系统中的无线射频识别技术来检测钥匙。预定范围可以是车辆通过其无钥匙进入系统所能够检测到钥匙的范围。

通过上述技术方案，用户能够通过终端预约车辆后背门的开启，在预约时段中，车辆在判断钥匙处于预定范围之内的情况下，认为用户在车辆附近，此时控制后备门打开。这样，车辆后背门具有预约开启的功能，不需要用户腾出手或踢腿来开启后背门，极大地方便了用户，尤其是当用户提着重物时，更加体现出该功能的便利性。

在又一实施例中，该方法还包括：向服务器发送车辆的位置信息，以使服务器在确定车辆已在预约位置驻车的情况下，向终端发送询问消息，询问消息用于询问是否生成预约请求。

其中，车辆中可以设置有GPS定位装置，车辆可以周期性地将自己的位置通过车载T-box发送给服务器。服务器具有计时的功能，可以根据车辆在同一位置的时长来判断车辆是否已驻车，例如，如果车辆在同一位置超过预定时长，就可以认为已驻车。或者，也可以由车辆将已驻车的消息发送给服务器。例如，发动机熄火时，车辆发送已驻车的消息。服务器中可以预先存储有一个或多个预定的预约位置。当车辆的位置在预约位置驻车时，服务器可以向终端的APP推送询问消息。预约位置可以是商场、超市等的停车场位置。因为人们在这些购物消费场所驻车后，很可能购买了较多东西回来，此时非常需要利用上述的预约开启功能。

当车辆在预约位置之外的其他位置驻车的话，服务器可以不开启该功能。这样，通过合理地设置预约位置，使得服务器的资源得到较为合理的利用，避免服务器数据处理量过大造成瘫痪。

在又一实施例中，服务器可以周期性地向终端发送询问消息，该询问消息用于询问是否生成预约请求。

其中，发送询问消息的周期可以预先设置，例如，服务器每小时发送一次询问消息。该实施例中，相比上一实施例，服务器不需要确定车辆的位置以及驻车情况，从而减小了服务器的工作量，加快了服务器的运行速度。

在又一实施例中，车辆可以将自身的停车位置发送至服务器，服务器获取到车辆的历史停车位置后，可以将停车频次大于预定频次的历史停车位置确定为预约位置。

在该实施例中，每个车辆对应的预约位置可以是根据该车辆自身的历史数据来确定的。不同的车辆的预约位置可以是不同的。不同车辆的预约位置根据用户的习惯自动生成，这样，预约开启后背门的功能具有一定的针对性，需求性更高。

在又一实施例中，询问消息可以包括用于生成所述预约时段的推荐时段。车辆可以将预约位置驻车、启动的状态通过车载T-box发送给服务器，或者，车辆将自身位置发送给服务器，服务器通过车辆位置来判断车辆是否在预约位置驻车、启动。服务器可以统计车辆在预约位置的历史停车时间。历史停车时间在一定程度上体现了用户的习惯。

服务器获取到与预约位置对应的历史停车时间后，可以根据历史停车时间确定推荐时段。在询问消息中可以带有推荐时段。该推荐时段是根据该用户自身习惯确定的时间，因此，该推荐时段具有一定的针对性，更符合用户的需求。

该实施例中，服务器通过用户自身的历史停车时间，向终端推送询问消息，从而使预约时段更加精准，符合每个用户的具体需求。

在又一实施例中，服务器可以在确定车辆已在预约位置驻车，且与预约位置对应的历史消费金额满足预定条件的情况下，向终端发送询问消息。

其中，与预约位置对应的历史消费金额，可以通过终端中的付款记录(例如，通过支付宝、微信等支付的记录)来确定。终端可以将消费金额发送至服务器，由服务器判断消费金额是否满足预定条件(例如，消费金额是否大于500元人民币)。也可以由终端来判断消费金额是否满足预定条件，并在判定消费金额满足预定条件时，将判断结果发送至服务器。

该实施例中，车主需要同意将消费习惯记录到大数据的云服务系统(可以通过APP进行设置)。由于消费金额在一定程度上体现了用户返回车辆时手提的物品的大小、重量等。可以认为消费金额越多，用户返回车辆时手提的物品越多。这样，当车辆在预约位置驻车，且用户的历史消费金额满足预定条件(例如，大于预定的金额阈值)的情况下，服务器再向终端发送询问消息。此时，能够避免不必要的功能开启，减少了服务器的数据处理量，保障了真正有需求的用户的正常使用。

上述各个实施例的技术特征，在不矛盾的情况下，可以互相结合，此处不再一一详细描述。图5是一示例性实施例提供的车辆后背门的控制方法的信令图。图5的实施例中，结合了上述多个实施例的特征。

图6是又一示例性实施例提供的车辆后背门的控制方法的流程图。在图6的实施例中，以下步骤被实施。

1、服务器可以定时向用户手机APP发送推送消息，询问是否需要定时预约尾门开启功能。服务器推送的时机也可以不是定时，而是依据环境监测确定推送时机，例如通过定位系统，服务器定位至车辆停在预约位置，则开启推送；

2、用户点击手机APP中的“确认”按键，则手机APP出现定时界面，用户可以早该定时界面中选择预约时段；

3、T-Box系统的服务器将该预约时段发送给车载主机；

4、到达预约时段后，车载主机唤醒车辆，车辆检测钥匙是否在周边，如果是，开启尾门；如果否，不开启尾门。

图7是又一示例性实施例提供的车辆后背门的控制方法的流程图。在图7的实施例中，以下步骤被实施。

1、车辆、车主手机APP均同意大数据服务，后台服务器可以通过大数据收集、统计车主的使用习惯。例如，经过预设时间段的数据统计，得知车主每次去xx商场的购物时间基本都在1小时左右，且使用手机购物支付的金额基本都在500元左右，则认为购物东西较多，需要自动开启尾门；

2、车辆停在xx商场后，车辆自动开启定时尾门开启功能，当车主1小时左右(也可以是时间范围，例如40-80分钟)，车辆唤醒，检测钥匙是否在周边，如果是，开启尾门；如果否，不开启尾门。

上述步骤2的替换方案：步骤1之后，当检测到车辆又一次停在xx商场，则服务器向用户手机APP发送推送消息，询问是否需要定时预约尾门开启功能；用户点击“确认”，则手机APP出现定时界面，并主动推送由大数据统计出的时间作为预约时段；T-Box系统的服务器将该预约时段发送给车载主机；到达预约时段后，车载主机唤醒车辆，车辆检测钥匙是否在周边，如果是，开启尾门；如果否，不开启尾门。

本公开提供一种服务器，该服务器被配置为执行上述应用于服务器的方法中的步骤。

本公开提供一种车辆，该车辆被配置为执行上述应用于车辆的方法中的步骤。

图8是根据一示例性实施例示出的一种电子设备800的框图。例如，电子设备800可以被提供为设置在车辆中。如图8所示，该电子设备800可以包括：处理器801，存储器802。该电子设备800还可以包括多媒体组件803，输入/输出(I/O)接口804，以及通信组件805中的一者或多者。

其中，处理器801用于控制该电子设备800的整体操作，以完成上述的车辆后背门的控制方法中的全部或部分步骤。存储器802用于存储各种类型的数据以支持在该电子设备800的操作，这些数据例如可以包括用于在该电子设备800上操作的任何应用程序或方法的指令，以及应用程序相关的数据，例如联系人数据、收发的消息、图片、音频、视频等等。该存储器802可以由任何类型的易失性或非易失性存储设备或者它们的组合实现，例如静态随机存取存储器(Static Random Access Memory，简称SRAM)，电可擦除可编程只读存储器(Electrically Erasable Programmable Read-Only Memory，简称EEPROM)，可擦除可编程只读存储器(Erasable Programmable Read-Only Memory，简称EPROM)，可编程只读存储器(Programmable Read-Only Memory，简称PROM)，只读存储器(Read-Only Memory，简称ROM)，磁存储器，快闪存储器，磁盘或光盘。多媒体组件803可以包括屏幕和音频组件。其中屏幕例如可以是触摸屏，音频组件用于输出和/或输入音频信号。例如，音频组件可以包括一个麦克风，麦克风用于接收外部音频信号。所接收的音频信号可以被进一步存储在存储器802或通过通信组件805发送。音频组件还包括至少一个扬声器，用于输出音频信号。I/O接口804为处理器801和其他接口模块之间提供接口，上述其他接口模块可以是键盘，鼠标，按钮等。这些按钮可以是虚拟按钮或者实体按钮。通信组件805用于该电子设备800与其他设备之间进行有线或无线通信。无线通信，例如Wi-Fi，蓝牙，近场通信(Near FieldCommunication，简称NFC)，2G、3G、4G、NB-IOT、eMTC、或其他5G等等，或它们中的一种或几种的组合，在此不做限定。因此相应的该通信组件805可以包括：Wi-Fi模块，蓝牙模块，NFC模块等等。

在一示例性实施例中，电子设备800可以被一个或多个应用专用集成电路(Application Specific Integrated Circuit，简称ASIC)、数字信号处理器(DigitalSignal Processor，简称DSP)、数字信号处理设备(Digital Signal Processing Device，简称DSPD)、可编程逻辑器件(Programmable Logic Device，简称PLD)、现场可编程门阵列(Field Programmable Gate Array，简称FPGA)、控制器、微控制器、微处理器或其他电子元件实现，用于执行上述的车辆后背门的控制方法。

在另一示例性实施例中，还提供了一种包括程序指令的计算机可读存储介质，该程序指令被处理器执行时实现上述的车辆后背门的控制方法的步骤。例如，该计算机可读存储介质可以为上述包括程序指令的存储器802，上述程序指令可由电子设备800的处理器801执行以完成上述的车辆后背门的控制方法。

图9是根据一示例性实施例示出的一种电子设备900的框图。例如，电子设备900可以被提供为一服务器。参照图9，电子设备900包括处理器922，其数量可以为一个或多个，以及存储器932，用于存储可由处理器922执行的计算机程序。存储器932中存储的计算机程序可以包括一个或一个以上的每一个对应于一组指令的模块。此外，处理器922可以被配置为执行该计算机程序，以执行上述的车辆后背门的控制方法。

另外，电子设备900还可以包括电源组件926和通信组件950，该电源组件926可以被配置为执行电子设备900的电源管理，该通信组件950可以被配置为实现电子设备900的通信，例如，有线或无线通信。此外，该电子设备900还可以包括输入/输出(I/O)接口958。电子设备900可以操作基于存储在存储器932的操作系统，例如Windows ServerTM，Mac OSXTM，UnixTM,LinuxTM等等。

在另一示例性实施例中，还提供了一种包括程序指令的计算机可读存储介质，该程序指令被处理器执行时实现上述的车辆后背门的控制方法的步骤。例如，该计算机可读存储介质可以为上述包括程序指令的存储器932，上述程序指令可由电子设备900的处理器922执行以完成上述的车辆后背门的控制方法。

以上结合附图详细描述了本公开的优选实施方式，但是，本公开并不限于上述实施方式中的具体细节，在本公开的技术构思范围内，可以对本公开的技术方案进行多种简单变型，这些简单变型均属于本公开的保护范围。

另外需要说明的是，在上述具体实施方式中所描述的各个具体技术特征，在不矛盾的情况下，可以通过任何合适的方式进行组合。为了避免不必要的重复，本公开对各种可能的组合方式不再另行说明。

此外，本公开的各种不同的实施方式之间也可以进行任意组合，只要其不违背本公开的思想，其同样应当视为本公开所公开的内容。