CN109767017A - 车辆预约试驾信息处理方法、装置及电子设备 - Google Patents

Abstract

本申请实施例公开了车辆预约试驾信息处理方法、装置及电子设备，其中，所述方法包括：服务器保存多个实体店内可预约试驾车辆及其库存信息；接收第一客户端提交的预约试驾请求；确定待试驾的目标车辆信息、时间信息以及目标实体店，并生成预约试驾订单。通过本申请实施例，可以更好的满足用户的购车前的试驾需求，避免出现用户在到达实体店后出现的无车可试等情况的发生。

Description

车辆预约试驾信息处理方法、装置及电子设备

技术领域

本申请涉及车辆预约试驾信息处理技术领域，特别是涉及车辆预约试驾信息处理方法、装置及电子设备。

背景技术

汽车消费属于耐用品消费，不论在信息流、现金流、还是服务流层面，均需要依托线下渠道开展，尤其是在消费者试驾环节，在现阶段汽车消费者均需要通过专营店到店进行试驾。但是，经常会出现到店后发现无车可试，或者试驾不充分等情况。因此，如何为消费者购车提供更加确定性和便利性的服务，成为需要本领域技术人员解决的技术问题。

发明内容

本申请提供了车辆预约试驾信息处理方法、装置及电子设备，可以更好的满足用户的购车前的试驾需求，避免出现用户在到达实体店后出现的无车可试等情况的发生。

本申请提供了如下方案：

一种车辆预约试驾信息处理方法，包括：

服务器保存多个实体店内可预约试驾车辆及其库存信息；

接收第一客户端提交的预约试驾请求；

确定待试驾的目标车辆信息、时间信息以及目标实体店，并生成预约试驾订单。

一种车辆预约试驾信息处理方法，包括：

第一客户端提供可预约试驾车辆信息界面，所述界面中包括用于对车辆进行预约试驾的操作选项；其中，所述可预约试驾车辆位于实体店内；

通过所述操作选项接收到对目标车辆信息的操作后，确定预约的时间信息以及目标门店信息；

根据所述目标车辆信息、所述时间信息以及目标门店信息，向服务端提交预约试驾请求，以用于生成预约试驾订单。

一种车辆预约试驾信息处理方法，包括：

服务器对多个实体店内的可预约试驾车辆的位置信息以及钥匙位置信息进行保存；

根据第二客户端提交的信息确定到达目标实体店指定终端设备前的用户信息，并确定关联的预约试驾订单信息；

将所述预约试驾订单信息提供给所述第二客户端，以用于通过所述终端设备进行展示并提供用于发起提车试驾操作的操作选项；

通过所述操作选项接收到操作请求后，根据所述预约试驾订单中的目标车辆信息以及所述保存的信息确定目标车辆位置信息以及目标钥匙位置信息，并返回给所述第二客户端，以用于分别控制所述目标车辆以及所述目标钥匙的自动取出。

一种车辆预约试驾信息处理方法，包括：

第二客户端获取到达目标实体店指定终端设备前的用户的信息，并确定关联的预约试驾订单信息；

通过所述终端设备进行所述预约试驾订单信息展示，其中包括用于发起提车试驾操作的操作选项；

通过所述操作选项接收到操作请求后，提交到服务器，并接收服务器返回的所述订单关联的目标车辆在所述目标实体店中的位置信息以及目标钥匙的位置信息；其中，所述服务器用于对所述实体店内的车辆位置信息以及钥匙位置信息进行保存；

根据所述目标车辆位置信息生成第一位置指令，根据所述目标钥匙位置信息生成第二位置指令，以用于分别控制所述目标车辆以及所述目标钥匙的自动取出。

一种车辆预约试驾信息处理装置，应用于服务器，包括：

信息保存单元，用于保存多个实体店内可预约试驾车辆及其库存信息；

请求接收单元，用于接收第一客户端提交的预约试驾请求；

订单生成单元，用于确定待试驾的目标车辆信息、时间信息以及目标实体店，并生成预约试驾订单。

一种车辆预约试驾信息处理装置，应用于第一客户端，包括：

界面提供单元，用于提供可预约试驾车辆信息界面，所述界面中包括用于对车辆进行预约试驾的操作选项；其中，所述可预约试驾车辆位于实体店内；

信息确定单元，用于通过所述操作选项接收到对目标车辆信息的操作后，确定预约的时间信息以及目标门店信息；

信息提交单元，用于根据所述目标车辆信息、所述时间信息以及目标门店信息，向服务端提交预约试驾请求，以用于生成预约试驾订单。

一种车辆预约试驾信息处理装置，应用于服务器，包括：

信息保存单元，用于对多个实体店内的可预约试驾车辆的位置信息以及钥匙位置信息进行保存；

订单确定单元，用于根据第二客户端提交的信息确定到达目标实体店指定终端设备前的用户信息，并确定关联的预约试驾订单信息；

订单信息提供单元，用于将所述预约试驾订单信息提供给所述第二客户端，以用于通过所述终端设备进行展示并提供用于发起提车试驾操作的操作选项；

位置信息确定单元，用于通过所述操作选项接收到操作请求后，根据所述预约试驾订单中的目标车辆信息以及所述保存的信息确定目标车辆位置信息以及目标钥匙位置信息，并返回给所述第二客户端，以用于分别控制所述目标车辆以及所述目标钥匙的自动取出。

一种车辆预约试驾信息处理装置，应用于第二客户端，包括：

订单信息确定单元，用于获取到达目标实体店指定终端设备前的用户的信息，并确定关联的预约试驾订单信息；

订单展示单元，用于通过所述终端设备进行所述预约试驾订单信息展示，其中包括用于发起提车试驾操作的操作选项；

请求提交单元，用于通过所述操作选项接收到操作请求后，提交到服务器，并接收服务器返回的所述订单关联的目标车辆在所述目标实体店中的位置信息以及目标钥匙的位置信息；其中，所述服务器用于对所述实体店内的车辆位置信息以及钥匙位置信息进行保存；

指令生成单元，用于根据所述目标车辆位置信息生成第一位置指令，根据所述目标钥匙位置信息生成第二位置指令，以用于分别控制所述目标车辆以及所述目标钥匙的自动取出。

一种电子设备，包括：

一个或多个处理器；以及

与所述一个或多个处理器关联的存储器，所述存储器用于存储程序指令,所述程序指令在被所述一个或多个处理器读取执行时，执行如下操作：

提供可预约试驾车辆信息界面，所述界面中包括用于对车辆进行预约试驾的操作选项；其中，所述可预约试驾车辆位于实体店内；

通过所述操作选项接收到对目标车辆信息的操作后，确定预约的时间信息以及目标门店信息以及目标门店信息；

根据所述目标车辆信息、所述时间信息以及目标门店信息，向服务端提交预约试驾请求，以用于生成预约试驾订单。

一种电子设备，包括：

一个或多个处理器；以及

与所述一个或多个处理器关联的存储器，所述存储器用于存储程序指令,所述程序指令在被所述一个或多个处理器读取执行时，执行如下操作：

获取到达目标实体店指定终端设备前的用户的信息，并确定关联的预约试驾订单信息；

通过所述终端设备进行所述预约试驾订单信息展示，其中包括用于发起提车试驾操作的操作选项；

通过所述操作选项接收到操作请求后，提交到服务器，并接收服务器返回的所述订单关联的目标车辆在所述目标实体店中的位置信息以及目标钥匙的位置信息；其中，所述服务器用于对所述实体店内的车辆位置信息以及钥匙位置信息进行保存；

根据所述目标车辆位置信息生成第一位置指令，根据所述目标钥匙位置信息生成第二位置指令，以用于分别控制所述目标车辆以及所述目标钥匙的自动取出。

根据本申请提供的具体实施例，本申请公开了以下技术效果：

通过本申请实施例，可以通过在线下部署提供试驾服务的实体店，并提供线上预约的服务系统，使得用户可以实现在线上进行试驾的预约，并按照预订的时间到指定的实体店进行试驾。因此，可以更好的满足用户的购车前的试驾需求，避免出现用户在到达实体店后出现的无车可试等情况的发生。

另外，本申请实施例还可以为用户提供深度试驾的服务，也即，可以将车辆开走，不限制具体的试驾场所，并且，还可以进行长时间的充分试驾，例如，可以是三天，等等，因此，可以更好的帮助用户进行购买决策。

再者，本申请实施例还通过一些方式实现了对用户购车意向的判断，只有在用户具有较高购车意向的情况下，才为其生成具体的预约试驾订单，或者，还可以根据购车意向的强弱，提供不同级别的车辆供其试驾，从而避免为一些别有用心的用户提供可乘之机。

当然，实施本申请的任一产品并不一定需要同时达到以上所述的所有优点。

附图说明

为了更清楚地说明本申请实施例或现有技术中的技术方案，下面将对实施例中所需要使用的附图作简单地介绍，显而易见地，下面描述中的附图仅仅是本申请的一些实施例，对于本领域普通技术人员来讲，在不付出创造性劳动的前提下，还可以根据这些附图获得其他的附图。

图1是本申请实施例提供的系统架构的示意图；

图2是本申请实施例提供的第一方法的流程图；

图3-1至3-3是本申请实施例提供的第一客户端界面示意图；

图4是本申请实施例提供的第二方法的流程图；

图5是本申请实施例提供的第三方法的流程图；

图6-1至6-8是本申请实施例提供的第二客户端界面示意图；

图6-9是本申请实施例提供的购车订单界面示意图；

图7是本申请实施例提供的第四方法的流程图；

图8是本申请实施例提供的第一装置的示意图；

图9是本申请实施例提供的第二装置的示意图；

图10是本申请实施例提供的第三装置的示意图；

图11是本申请实施例提供的第四装置的示意图；

图12是本申请实施例提供的电子设备的示意图。

具体实施方式

下面将结合本申请实施例中的附图，对本申请实施例中的技术方案进行清楚、完整地描述，显然，所描述的实施例仅仅是本申请一部分实施例，而不是全部的实施例。基于本申请中的实施例，本领域普通技术人员所获得的所有其他实施例，都属于本申请保护的范围。

在本申请实施例中，提供了可以实现线上预约、线下提车试驾的处理系统，具体的，如图1所示，在硬件层面上可以包括部署在线下的实体店系统，例如，可以按照城市区划部署多个不同的实体店，同一个城市区划内还可以部署多个实体店，等等。实体店内具有车库系统，可以停放多种可供试驾的车辆，车库系统可以通过自动化控制系统实现自动提车等功能；另外，实体店内还可以具有自动化钥匙管理系统，实现对车辆钥匙的自动化管理，以及为进入实体店的用户提供的公用终端设备，用于基于线上生成的预约试驾订单进行线下的取车试驾操作，并作为云端的服务器与车库系统、钥匙关联系统之间的桥梁，可以将服务器发送的指令，转发给车库系统以及钥匙关联系统。

在软件层面上，首先可以部署用于对各实体店内的车辆信息、钥匙信息等进行统一管理的服务器系统，各实体店具体提供哪些车型的试驾服务，具体车辆在车库内的停放位置信息、对应钥匙在钥匙柜内的存放位置信息，各车辆的库存信息，等等，都可以通过服务器进行保存。另外，服务器还可以为消费者用户、买家用户等第一用户提供线上预约试驾服务。具体的，还可以为第一用户提供第一客户端，该第一客户端运行在用户的手机等私有终端设备中。具体实现时，该第一客户端可以是以独立的应用程序的形式出现，或者，还可以是将相应的功能集成在其他的应用程序中，例如，可以在“手机淘宝”客户端中提供上述第一客户端的功能，等等。其中，所述第一客户端具体可以为用户提供用户界面，通过这种用户界面用户可以对各实体店内可选的车辆信息进行浏览、搜索等操作，并对选中车辆选择在线预约试驾，服务器便可以生成对应的预约试驾订单。之后，第一用户便可以在预约的时间内到对应的实体店进行提车试驾，在提车的过程中，还可以通过实体店中的公用终端设备中的第二客户端、所述自动化车库系统、自动化钥匙管理系统等，为用户实现自助式的提车试驾体验。在试驾结束后，第一用户还可以进行还车，或者，还可以对车辆进行购买操作，等等。具体实现时，本申请实施例在线上预约阶段、线下提车试驾阶段以及试驾结束后的阶段，分别可以提供相应的解决方案，下面从多个角度分别对不同阶段进行详细介绍。

实施例一

首先，该实施例一对线上预约阶段，服务器端的具体实现进行详细介绍。

参见图2，该实施例一首先提供了一种车辆预约试驾信息处理方法，该方法具体可以包括：

S201：服务器保存多个实体店内可预约试驾车辆及其库存信息；

具体的，关于各个实体店内具体可预约试驾车辆的信息，以及初始的库存信息，可以是由实体店的工作人员等，通过登录到服务器的管理界面等方式，提交到服务器进行保存。而在第一用户开始进行预约操作后，则可以由服务器对具体的库存信息进行更新。例如，当第一用户对某车辆完成了预约试驾时，可以对该车辆对应的库存进行扣减，接收到实体店工作人员提交的车辆归还信息时，可以将对应车辆的库存进行增加，等等。另外，服务器还可以对车辆在具体实体店内的位置信息、钥匙的位置信息等进行保存。

例如，关于具体车辆的信息，服务端具体保存的信息可以如表1所示：

表1

关于钥匙的位置信息可以通过如下表2的方式进行保存：

表2

当然，在具体实现时，还可以通过其他形式对具体的信息进行保存，这里不应看作是对本申请保护范围的限制。

S202：接收第一客户端提交的预约试驾请求；

具体实现时，第一用户可以通过多种方式发起预约试驾。例如，在一种方式下，第一用户可以通过第一客户端的用户界面，对可预约试驾的车辆信息进行浏览，此时，服务器可以接收第一客户端提交的浏览请求，并向所述第一客户端提供可预约试驾车辆信息列表。之后，第一用户可以从车辆信息列表中选择自己所需试驾的车辆，并且，如图3-1所示，可以在界面中提供“免费预约试驾”等操作选项，通过点击该操作选项即可提交具体的预约试驾请求。在这种方式下，所述服务器还可以保存有所述实体店的地理位置信息，此时，在向所述第一客户端提供可预约试驾车辆信息列表时，可以首先根据所述第一客户端关联第一用户所在的地理位置信息，以及各实体店的地理位置信息，提供可选实体店的信息，在目标实体店被选中后，再提供所述目标实体店内的可预约试驾车辆信息列表。

或者，在另一种方式下，在用户知晓所需试驾车辆的品牌、型号等信息的情况下，还可以通过搜索的方式查找所需试驾的车辆信息。此时，服务器可以接收所述第一客户端提交的搜索请求，然后，根据所述保存的实体店中可预约试驾的车辆信息提供搜索结果，并提供用于提交预约试驾请求的操作选项，以用于通过所述操作选项针对选中的搜索结果提交预约试驾请求。其中，在可选的实施方式中，还可以首先根据所述第一客户端关联第一用户所在的地理位置信息，确定与所述地理位置信息相关的至少一个目标实体店，然后，根据所述目标实体店中可预约试驾的车辆信息提供搜索结果。其中，如果搜索结果是，所述目标实体店中存在符合用户搜索条件的车辆，则可以将该车辆的信息进行展示，并提供“预约试驾”等操作选项，用户可以通过点击该操作选项的方式发起相应的预约试驾请求。

另外，在实际应用中，可能存在以下情况：用户在马路上、停车场等看到一辆车，感觉比较感兴趣，具有购买的意愿，并且希望在购买之前先进行试驾，。此时，如果用户根据车辆的外观能够知晓具体的车辆品牌、型号等信息，则可以直接通过搜索等方式，通过所述第一客户端进行搜索，以确定系统中是否能够提供关于该车辆的试驾服务。而如果用户无法明确知晓车辆的品牌、型号等信息，则为了使得客户仍然能够实现对该车辆的试驾，本申请实施例还可以提供通过图像识别的方式确定车辆品牌、型号等标识的功能。具体实现时，第一客户端中还可以提供用于采集车辆图像信息的操作选项，该选项被操作后，可以启动手机等终端设备上的摄像头等图像摄取装置，这样，用户可以将其摄像头对准所需试驾的车辆进行拍摄，这样，服务器可以接收所述第一客户端提交的车辆图像信息，然后通过对所述车辆图像信息进行识别，确定对应的品牌及车型等信息，并确定所述实体店内是否存在对应的可预约试驾的车辆，如果存在，便可以提供该车辆的信息，并提供用于提交预约试驾请求的操作选项。

S203：确定待试驾的目标车辆信息、时间信息以及目标实体店，并生成预约试驾订单。

在确定出待试驾的目标车辆信息时，还可以确定试驾的时间信息、实体店信息等，具体的，关于时间信息，可以由第一用户进行设置，或者，为了便于管理，如图3-2所示，还可以预先对每天的可预约时段等进行配置，由第一用户选择具体的日期以及时间段，等等。

关于目标实体店的确定，则可以是根据用户所在的地理位置信息进行匹配，例如，对于上海的用户，可以默认为到上海的实体店进行提车试驾，北京的用户则默认为到北京的实体店进行提车试驾；如果同一城市内存在多家实体店，则可以根据用户与各实体店之间的距离信息，将距离用户最近的实体店确定为目标实体店，或者，由第一用户选择具体的目标实体店，等等。

在确定出上述信息后，可以生成具体的预约试驾订单，这样，后续第一用户就可以到具体的目标实体店进行提车试驾。

其中，在具体实现时，本申请实施例在线上预约阶段还可以就一些细节进行相应的处理，以使得整个方案更加完善。例如，由于本申请实施例可以为用户提供免费的试驾服务，并且在一种试驾服务中，用户可以进行深度试驾，也即，可以驾车驶离实体店，对具体试驾的路线、场所等无固定的限制，并且，可以进行为期三天甚至更长时间的免费试驾，这种服务主要是提供给具有购车意向的用户，使其能在购车之前，获得充分的试驾体验。但是，这可能会使得一些别有用心的用户借着试驾的名义，进行免费“租车”，将试驾体验店当作免费租车行。为了避免该现象的发生，本申请实施例中，在具体接收到第一用户的预约试驾请求时，生成预约试驾订单之前，还可以对用户的购车意向值进行确定，只有在购车意向值比较高时，才为其生成预约试驾订单，否则拒绝生成，或者，根据购车意向值的高低，可以提供不同档次的车辆供其试驾，等等。也就是说，服务器可以对所述第一客户端关联的第一用户购车意向值的高低进行判断，以用于确定是否为所述第一用户生成预约试驾订单，或者该第一用户对应的可预约试驾的目标车辆。

具体的，可以通过多种方式对第一用户的购车意向值进行确定，例如，其中一种方式下，可以要求第一用户在进行预约试驾前缴纳一定数目的资源作为意向金(这里称为“意向资源”)，当然，意向金的数目可以是远高于对应时间在租车行租车时所需缴纳的费用，例如，可以是数万元等等，这样，如果第一用户愿意缴纳这部分意向金，则可以证明用户的购车意向比较明确，是确实为了购买才来试驾的，而如果不愿意缴纳，则证明用户的购车意向可能比较不明确，因此，可以拒绝为其生成预约试驾订单。

其中，具体缴纳意向资源的操作可以是由第一用户预先进行的，例如，只要第一用户开通在线预约试驾服务，就可以先缴纳意向资源，其中，为了避免占用用户的实体账户中的资源造成占用，还可以通过对用户关联的信用账户中的资源进行冻结等方式来进行意向资源的缴纳。例如，“蚂蚁花呗”等系统为某第一用户提供了5万元的信用额度，供用户先消费后付款，因此，本申请实施例中，用户在缴纳意向资源时，系统可以优先从这种信用账户中冻结一部分资源，后续如果用户在试驾结束后，将车辆归还，则可以将这部分资源解冻，如果用户最终选择了购买该车辆，则还可以将这部分意向资源作为车辆的首付款，或者抵用一部分车款，等等。当然，在具体实现时，还可以为用户提供可选的意向资源数量，用户在缴纳意向资源时，可以根据自己的实际需求，选择具体的数量进行缴纳，例如，可以缴纳3万、5万等等。

在上述预先缴纳了意向资源，再进行车辆的选择以及提交预约试驾请求的情况下，服务器在接收所述第一客户端提交的对可预约试驾的车辆信息进行浏览的请求，并向用户提供可选的车辆信息时，还可以根据所述第一客户端关联第一用户已缴纳意向资源的数量，以及各车辆对应的资源信息，为该第一用户确定可选的车辆信息，并提供给所述第一客户端供所述第一用户进行选择。也就是说，不同车辆对应的所需资源数量有所不同，而在用户缴纳了不同数量的意向金的情况下，其能够试驾的车辆也可以是不同的。例如，如果是缴纳3万元意向金的用户，可以试驾中等级别的车辆，如果是缴纳了更多的意向金的用户，则能够试驾的车辆的范围更大，不仅可以包括中等级别的车辆，还可以包括高等级别的车辆，等等。

或者，如前文所述，如果用户是因为刚好在马路上或者停车场看到了一辆车，需要通过本申请实施例中的系统进行在线预约试驾，并且，预先并没有缴纳意向金，则服务器在根据第一用户提交的车辆图像等信息，确定所述待试驾的目标车辆后，还可以首先根据所述目标车辆对应的资源信息，确定需缴纳的意向资源的数量，如果所述第一客户端关联第一用户已缴纳对应数量的意向资源，则触发进入生成所述预约试驾订单的步骤。例如，如果用户当前看到的是一辆50万元左右的车，则需要缴纳5万元的意向金，并提示用户进行缴纳，如果用户进行了缴纳，则证明该用户确实对该车辆具有购买意向，否则，即可拒绝为该用户生成预约试驾订单，等等。

其中，关于具体意向资源的数量与可试驾车辆之间的对应关系，可以是预先在服务器端进行配置并保存，服务器根据这种对应关系进行判断或者确定操作即可。

另一种对用户的购车意向进行判断的方式可以是根据用户的信用等级信息进行判断，例如，用户的“芝麻信用”分数，等等，由于一般情况下，这种信用分能够从一定程度上体现出用户在日常生活中的信用，因此，也可以作为对用户购车意向的判断依据。当然，还可以将用户对意向资源的缴纳情况以及所述信用等级相结合，综合判断用户的购车意向的强弱。此外，还可以根据用户的信用等级，对用户需要缴纳的意向资源的数量进行调整。例如，如果用户需要试驾高级别的车辆，且其信用等级比价高，则可以要求其缴纳相对较低的意向资源，反之，则需要缴纳价高的意向资源，等等。

此外，还可以对同一个第一用户在预置时间段内(例如，最近一年内)的预约试驾次数信息进行统计，如果超过了某阈值(例如，三次)，则可以拒绝再为其生成预约试驾订单。通过这种方式，也可以从一定程度上避免一些用户以试驾的名义多次进行“免费租车”。

除了从购车意向上对用户的预约试驾资格进行控制，在一些可选的实施方式中，还可以对用户的驾车资格进行验证，具体的，在确定了目标车辆、试驾时间等信息后，服务器还可以提供用于输入驾驶员信息的界面，例如，如图3-3所示，可以要求用户输入驾驶员的姓名、联系方式、身份证号等信息。在用户输入具体的驾驶员信息后，还可以通过预置的查询系统对所述驾驶员信息进行验证。具体的验证过程，可以包括对信息的真实性进行验证，另外，还可以包括对违法等情况进行验证，例如，如果发现某驾驶员在一段时间内多次被处罚，则也可以拒绝为其生成预约试驾订单，等等。

再者，在线下的实体店中，为了提高提车试驾过程中的科技感，可以通过对人脸识别等方式，为用户提供一些更便捷的提车方式，例如，第一用户在完成线上的预约试驾后，到线下的实体店进行提车时，实体店内可以部署有摄像头等设备，用户进入实体店后，便可以通过人脸识别的方式，识别出用户的姓名等信息，并通过LED等显示屏显示出对该用户的欢迎信息；后续第一用户在通过实体店中的终端设备进行操作时，也可以通过对用户的人脸识别等方式，识别出该用户关联的具体的订单，并在终端设备的显示屏上进行显示，进而用户直接通过点击“立即提车”等按钮进入提车环节即可，期间不需要用户输入自己的账户名称、订单编号等信息。

为了达到上述目的，服务器在生成具体的预约订单时，还可以首先采集所述第一客户端关联第一用户的生物体征信息，其中可以包括人脸图像信息、指纹信息、声纹信息、虹膜信息等等，然后，可以对采集到的生物体征信息与预先保存的所述第一用户关联的生物体征信息进行比对，确定是否为所述第一用户本人操作。在确定出是所述第一用户本人操作时，可以将所述采集到的生物体征信息与所述预约试驾订单信息进行绑定，当然，由于预约试驾订单中还会包括有第一用户的姓名等信息，因此，在与上述订单信息进行绑定后，同时可以将用户的生物体征信息与用户的姓名等信息进行绑定。这样，后续到线下的实体店中进行提车试驾时，就可以达到上述通过识别用户的生物体征信息提供相应的欢迎界面、订单信息等目的。

另外需要说明的是，在本申请实施例中，可以向用户提供多种不同类型的试驾方式，例如，除了前述提到的“深度试驾”之外，还可以提供“集中试驾”的试驾方式，以满足不同用户的多种不同的个性化需求。其中，所谓的深度试驾，就是指，在用户具有相对较明确的购买意向，并且已经确定了想要购买的对象，则可以对该购买对象对应的车辆进行深度试驾，在深度试驾的过程中，用户可以将车辆开走，离开实体店，可以去自己喜欢或者方便的道路上进行试驾，并且，可以试驾的时间可以比较长，例如，三天，等等。这样，通过这种深度试驾的方式，可以使得用户在实际的驾车环境中，获得对试驾车辆比较全面的试驾体验，可以更好的帮助用户进行购车决策。而集中试驾是指，在用户具有购车意向，但是尚未明确具体所需购买的车辆，需要在多个不同的车辆之间进行比较时，则可以选择进行“集中试驾”，在这种方式下，用户可以一次性选择多辆车进行试驾，在预约试驾订单中，可以包括多个待试驾的车辆。对于这种情况，可以为用户提供专门的试驾场所，例如，赛车场等等，用户可以在该试驾场所内，对所需的多个车辆进行试驾，由于是在同一固定场所内对多个车进行试驾，因此，也可以称为集中试驾。其中，集中试驾的试驾时间通常都是在试驾当天即结束，当然，也可以仅选择一辆车，在固定场所内进行试驾，等等。

需要说明的是，对于上述深度试驾的试驾类型，虽然对具体的试驾场所不进行限制，但是，在实际应用中，还可以规定第一用户在一定的可试驾地理区域范围内进行试驾，例如，北京市的用户不能将车辆驶离北京市，等等。也即，对于深度试驾类型的订单，服务器还可以确定可试驾的地理区域范围信息，并添加到所述预约试驾订单中。具体实现时，可以通过多种方式确定所述可试驾地理区域范围信息。例如，在一种方式下，可以是根据所述目标实体店所在的地理位置信息，确定可试驾的地理区域范围信息。具体的，该地理区域范围可以是由目标实体店进行确定或者也可以由服务器为实体店进行配置，等等。或者，还可以根据所述第一客户端关联第一用户相关的地理位置信息，确定可试驾的地理区域范围信息。其中，所谓与第一用户相关的地理位置信息，具体可以包括第一用户的家庭住址所在的地理位置，工作单位所在的地理位置，或者，还可以为第一用户提供电子地图界面，由第一用户在界面中圈选出自己所需的地理区域范围，等等。另外，在具体实现时，无论具体通过何种方式确定可试驾的地理区域范围，服务器都可以对区域范围内的具体路段进行判断，将一些事故多发路段排除在外，这样，可以降低在试驾过程中车辆受损或者人员受伤的几率。其中，服务器可以预先从相关的数据库中获得事故多发路段的相关数据，以此为依据进行上述判断操作。

总之，在可以提供多种不同试驾类型的情况下，服务器在生成预约试驾订单时，还可以确定出第一用户所需的试驾类型信息，并添加到所述预约试驾订单中。其中，所述试驾类型包括集中试驾以及深度试驾，所述集中试驾为：在指定的试驾场所内对预约的至少一个车辆进行试驾，所述深度试驾为：在指定时间段内对预约的车辆进行无固定试驾场所限制的试驾。

总之，通过本申请实施例提供的上述方案，可以实现在线的预约试驾，为后续的现象提车试驾提供基础。

实施例二

该实施例二是与实施例一相对应的，从第一客户端的角度，提供了一种车辆预约试驾信息处理方法，参见图4，该方法具体可以包括：

S401：第一客户端提供可预约试驾车辆信息界面，所述界面中包括用于对车辆进行预约试驾的操作选项；其中，所述可预约试驾车辆位于实体店内；

S402：通过所述操作选项接收到对目标车辆信息的操作后，确定预约的时间信息以及目标门店信息；

S403：根据所述目标车辆信息、所述时间信息以及目标门店信息，向服务端提交预约试驾请求，以用于生成预约试驾订单。

其中，具体在提供可预约试驾车辆信息界面时，可以提供实体店内可预约试驾车辆的列表信息界面，以用于从所述列表中进行目标车辆的选择。

或者，在另一种情况下，还可以是根据接收到的搜索关键词，从所述实体店关联的可预约试驾车辆信息中，搜索出符合搜索条件的可预约试驾车辆，并在所述界面中进行提供。

再或者，还可以首先提供用于进行图像采集的操作选项，接收到图像采集请求后，获得车辆图像采集结果，然后，将所述车辆图像采集结果提交到服务器，以用于通过对所述车辆图像信息进行识别，确定对应的品牌及车型信息，并确定所述实体店内是否存在对应的可预约试驾的车辆，若存在，则返回该车辆的信息；在所述界面中提供该车辆的信息。

关于该实施例二中其他的具体实现，可以参见前述实施例一中的介绍，这里不再赘述。

实施例三

该实施例三主要是从线下的提车试驾阶段，对本申请实施例的具体方案进行介绍。也即，用户通过第一客户端以及服务器完成线上的预约试驾，并生成相应的订单后，可以按照预约的时间，到目标实体店进行提车试驾。具体的，在本申请实施例中，可以在目标实体店中提供一终端设备，该终端设备中可以包括第二客户端，另外，还可以带有摄像头等用于采集用户生物体征信息的设备，通过该终端设备，可以完成对用户到底目标实体店的确认，进而，用户可以通过该终端设备发出具体的取车指令。终端设备则可以根据从服务器接收到的相关车辆的位置信息、钥匙信息等，生成相应的控制指令，控制对应的车辆以及钥匙自动取出，从而实现自助式的提车试驾。

下面对具体的实现方案进行介绍。

首先，参见图5，该实施例三首先从服务器的角度，提供了一种车辆预约试驾信息处理方法，该方法具体可以包括：

S501：服务器对至少一个实体店内的可预约试驾车辆的位置信息以及钥匙位置信息进行保存；

具体实现时，如前文所述，在具体实体店中可以包括车库系统以及钥匙管理系统，其中，车库系统中可以包括多个车位以及第一控制器，所述车位用于停放具体的车辆，为了节省空间，可以采用立体车位的形式；第一控制器用于接收实体店内的所述公用终端设备发送的位置指令，对对应位置处的车辆进行出库处理。其中，可以通过自动化控制设备，实现对车辆的自动出库。

钥匙管理系统中可以对应一钥匙存放容器，该钥匙存放设备可以存在多个钥匙位，可以预先由工作人员将车辆的钥匙存放入具体的钥匙位；另外，还可以存在第二控制器，该第二控制器也可以用于接收公用终端设备发送的位置指令，将对应位置处的钥匙提供给用户。其中，钥匙存放设备也可以通过自动化设备实现钥匙的自动取出。例如，钥匙存放设备可以是采用具有多个储存钥匙空间，且每个储存钥匙空间为抽屉结构，或者仓门的结构，通过电子锁或密码锁等实现打开或关闭。当电子锁或密码锁接收到锁定或解锁控制信号时，可实现储存钥匙空间的锁定或解锁，等等。

具体实现时，关于各个实体店中具体车辆所在位置的信息，以及钥匙所在位置的信息都可以预先保存到服务器中，由服务器统一控制目标车辆以及目标钥匙的取出。当然，实体店内的公用终端设备可以作为服务器与车库系统、钥匙管理系统之间的桥梁，进行信息或者指令的中转。

S502：根据第二客户端提交的信息确定到达目标实体店指定终端设备前的用户信息，并确定关联的预约试驾订单信息；

用户到达目标实体店后，可以来到所述公用终端设备前，此时，第二客户端可以通过该公用终端设备的摄像头等装置感应到用户的到来，并且，可以采集用户的生物体征等信息，提交到服务器。由于服务器在生成预约试驾订单时，可以采集用户的生物体征信息，并与预约试驾订单信息进行绑定，因此，服务器在接收到第二客户端提交的用户生物体征信息后，就可以确定出对应的预约试驾订单。当然，在实际应用中，用户也可以通过第二客户端提交自己的账户信息等，使得服务器能够通过账户信息确定出对应的预约试驾订单信息，等等。

S503：将所述预约试驾订单信息提供给所述第二客户端，以用于通过所述终端设备进行展示，并提供用于发起提车试驾操作的操作选项；

在确定出预约试驾订单后，可以将订单信息提供给第二客户端，这样，第二客户端可以通过所述终端设备进行展示，用户可以从该终端设备中查看到该预约试驾订单的信息。当然，具体实现时，提供给第二终端展示的订单信息，可以是服务器保存的订单详情信息中的一部分，例如，可以仅包括具体的试驾车辆的信息。另外，还可以在该界面中提供用于发起提车试驾操作的操作选项，例如，如图6-1所示，可以显示出具体的车辆的品牌、型号、预约的时间等信息，另外，可以提供“车辆已为您准备好”的提示信息，以及“立即提车”按钮，用户可以通过点击该按钮，发起提车试驾请求。也就是说，用户进入到实体店之后，可以通过实体店内的终端设备进行“签到”，并触发具体的提车试驾操作，之后，就可以根据该设备提供的引导信息等，进行钥匙以及车辆的提取。当然，在具体实现时，上述通过公用终端设备进行“签到”的过程中，为了提高准确度，避免误识别，还可以通过第二客户端向用户提供用于登录的图形码，并提示用户使用其手机等私有终端设备中的第一客户端，对该图形码进行扫描，从而使得服务器获得对应的用户登录账户信息，进而，在确定用户生物体征信息对应的预约试驾订单时，还可以使用用户登录的账户信息进行验证。

S504：通过所述操作选项接收到操作请求后，根据所述预约试驾订单中的目标车辆信息以及所述保存的信息确定目标车辆位置信息以及目标钥匙位置信息，并返回给所述第二客户端，以用于分别控制所述目标车辆以及所述目标钥匙的自动取出。

在接收到“立即试驾”的请求后，服务器就可以根据所述预约试驾订单中的目标车辆信息以及所述保存的信息，确定出目标车辆的位置信息以及目标钥匙的位置信息，并返回给第二客户端。第二客户端在收到上述位置信息后，可以根据所述目标车辆位置信息生成第一位置指令，根据所述目标钥匙位置信息生成第二位置指令，进而，可以将第一位置指令提供给车库系统的第一控制器，由第一控制器控制目标车辆的自动取出；将第二位置指令提供给钥匙管理系统的第二控制器，由第二控制器控制目标钥匙的取出。相应的，第二客户端可以在终端设备的显示屏中，给出相应的提示信息。其中，由于钥匙柜通常可以放置在距离所述终端设备比较近的地方，因此，如图6-2所示，可以直接在终端设备的屏幕上显示出“请取走您的钥匙”，而目标车辆具体是位于车库中，因此，可以在终端设备的显示屏中对目标车辆所在车库的具体位置等信息进行提示，例如，图6-2所示的“请前往2号车架领取爱车”，等等。

在用户离开终端设备前往车库取车后，第二客户端可以自动将与该用户相关的信息在所述公用终端设备中进行注销，也即，不需要用户手动执行退出系统等操作。具体的，如图6-3所示，还可以提供相应的提示信息，如：“您的信息将在3秒钟后注销”，等等。

在实际应用中，由于车库所在的位置则通常与所述公用终端设备所在的位置之间有一定的距离，并且车库内可能通过多个车辆存放设备(车架等)进行车辆的存放。在这种情况下，由于用户所选择的车辆位于其中某个车辆存放设备内，因此，为了便于用户快速找到自己所需的车辆，还可以分别在公用终端设备与各个车辆存放设备之间部署“指示灯带”，即，可以在公用终端设备通往各个车辆存放设备的道路上部署多个指示灯，在默认状态下，这些指示灯处于关闭状态。每条指示灯带可以通过一个控制器进行控制整条灯带上各指示灯的开关。公用终端设备在接收到服务端下发的位置信息后，则可以确定出目标车辆所在的车辆存放设备，并指示对应车辆存放设备的控制器，将对应指示灯带上的各个指示灯进行开启。这样，用户可以沿着这种指示灯带快速找到自己所选择的车辆所在的车辆存放设备。

对于服务器而言，在用户点击“立即试驾”，并完成车辆的领取后，可以将该用户关联的所述预约试驾订单的状态修改为试驾中状态，相应的，用户也可以通过其手机等私有终端设备上的第一客户端查看到具体订单信息状态的变化。

其中，对于是深度试驾的情况，由于并不会对具体的试驾场所进行限制，用户可以将车辆开走，但是，在具体实现时，为了降低风险，如前文所述，可以对允许试驾的地理区域范围进行限制，例如，北京实体店的用户在试驾过程中不能离开北京市的范围，等等。为了进行控制，可以在所述目标车辆中配备有定位装置，服务器可以在所述预约试驾订单中还记录有可试驾的地理区域范围信息。这样，对于处于试驾中状态的订单，如果其试驾类型是深度试驾，则服务器还可以对所述目标车辆的位置进行跟踪，并在所述目标车辆即将超出所述可试驾的地理区域范围时，通过第一客户端提供提示信息。

在结束试驾后，用户可以将车辆归还到实体店中，实体店的工作人员等，可以登录到服务器中，将车辆归还信息提交到服务器，这样服务器就可以根据该车辆对应的订单信息，将订单状态切换为已结束状态。另外，接收到将所述目标车辆归还的信息后，还可以更新对应实体店内对应车辆的库存信息。

其中，在具体实现时，可以是将车辆归还至提车时的实体店，或者，在同一个城市部署有多家实体店的情况下，也可以实现跨实体店的还车。也即，假设用户在A实体店进行提车试驾，但是可以将车辆归还至B实体店，等等。另外，为了进一步节省用户的时间，还可以为用户提供上门取车服务，例如，在用户试驾结束后，可以通过第一客户端提供的操作选项，发起上门取车请求，并提供自己的地址等信息，这样，服务器可以分配相应的服务人员，到指定的地址将对应的车辆开回。

当然，在试驾结束后，除了可能会将车辆归还，还有一种可能是，用户需要购买对应的车辆，对于这种情况，本申请实施例也提供了相应的解决方案，也即，在用户将车辆归还至具体的实体店后，仍然可以通过所述公用终端设备执行具体的购车流程。具体的，用户同样可以进入到终端设备的感应区，使得终端设备能够采集到用户的生物体征信息，并由第二客户端提交至服务器。服务器在接收到用户信息后，通过匹配判断，确定出该用户关联的预约试驾订单信息处于试驾结束状态，则就可以认为该用户可能是需要对相关的车辆进行购买操作。因此，服务器就可以向所述第二客户端提供与所述预约试驾订单中的目标车辆关联的可售车辆信息。其中，所述可售车辆信息可以是具体销售对应车辆的网络店铺等提供的相关信息，由于同一款车可能会在多家店铺中都存在，因此，可以提供关于同一车辆的多条信息，用户可以从中进行对比选择。例如，展示结果可以如图6-4所示，每条信息中可以包括具体车辆的品牌、型号等信息，以及具体的价格信息、付款方式信息。用户可以通过左右滑动公用终端设备显示屏的方式切换查看其他的条目。

然后，在用户选定其中一个条目后，服务器可以接收通过所述第二客户端提交的车辆选择结果以及购买指令信息，此时，可以向所述第二客户端提供第一图形码，以用于通过第一客户端扫描所述第一图形码的方式进行登录，如图6-5所示，其中还可以显示有“请用户手机淘宝扫码登录”等提示信息。也就是说，如果用户需要购车，则需要用到用户的账户信息，此时，可以首先要求用户进行登录，而由于公用终端设备是公用的设备，因此，为了保证用户信息的安全性，可以通过其私有终端设备扫码的方式进行登录。之后，服务器可以根据所述登录的用户账户信息、所述车辆选择结果以及对应的可选购车方案信息，生成承接页面，并将所述承接页面信息返回给所述第二客户端，以用于对所述可选购车方案信息进行展示。如图6-6所示，其中可以包括三种购车方案供用户选择。其中，具体的购车方案也可以是根据用户的具体情况而定制的，例如，可以根据用户的支付习惯等信息，为用户定制可选的购车方案，如果用户喜欢低首付，则提供首付比例比较低的购车方案，如果用户喜欢全款支付，则可以提供全款支付的购车方案，等等。

在接收到所述第二客户端提交的购车方案选择结果后，如果具体的购车方案涉及到信用支付，则服务器还可以根据所述第一用户的信用记录信息进行评估，并向所述第二客户端返回评估结果。如果评估通过，则还可以提供用于支付的操作选项，如图6-7中所示的“快去支付吧”，等等。通过所述用于支付的操作选项接收到操作请求后，生成用于跳转到支付界面的链接，并根据所述链接生成第二图形码，并提供给第二客户端进行展示，如图6-8所示，还可以提供提示信息，如“请使用手机淘宝扫码登录”，等等。这样，用户就可以通过其私有终端设备中的第一客户端扫描所述第二图形码的方式，跳转到支付界面，如图6-9所示，其为在用户手机等私有终端设备中的展示结果。也即，具体的支付操作可以在用户的私有终端设备上完成，从而保障用户敏感信息的安全性。需要说明的是，可以由所购买车辆所属的店铺指定的提车实体店，例如，在图6-9的订单中指定的具体的提车实体店的地址等信息。也就是说，本申请实施例中所述的实体店通常可以是仅用于提供试驾服务的实体店，而如果需要购买时，则从具体的4S店等进行提车，以确保用户所提的车辆是新车，而不是被反复试驾过的车辆。当然，在实际应用中，本申请实施例的实体店中也可以提供存放区，也即，用户购车之后的提车实体店，与其试驾时的实体店也可能是同一个，具体可以根据实际情况而定。

总之，通过本申请实施例，可以通过在线下部署提供试驾服务的实体店，并提供线上预约的服务系统，使得用户可以实现在线上进行试驾的预约，并按照预订的时间到指定的实体店进行试驾。因此，可以更好的满足用户的购车前的试驾需求，避免出现用户在到达实体店后出现的无车可试等情况的发生。

另外，本申请实施例还可以为用户提供深度试驾的服务，也即，可以将车辆开走，不限制具体的试驾场所，并且，还可以进行长时间的充分试驾，例如，可以是三天，等等，因此，可以更好的帮助用户进行购买决策。

再者，本申请实施例还通过一些方式实现了对用户购车意向的判断，只有在用户具有较高购车意向的情况下，才为其生成具体的预约试驾订单，或者，还可以根据购车意向的强弱，提供不同级别的车辆供其试驾，从而避免为一些别有用心的用户提供可乘之机。

实施例四

该实施例四是与实施例三相对应的，从第二客户端的角度提供了一种车辆预约试驾信息处理方法，其中，所述第二客户端具体可以是指，在具体实体店中部署的供进入实体店的用户所公用的终端设备中的客户端，具体实现时，该第二客户端可以是以应用程序的形式安装在所述公用终端设备中，或者，也可以是固化在所述公用终端设备中，等等。具体的，参见图7，该方法具体可以包括：

S701：第二客户端获取到达目标实体店指定终端设备前的用户的信息，并确定关联的预约试驾订单信息；

具体实现时，第二客户端获得用户信息后可以提交到服务器，由服务器确定关联的预约试驾订单信息，并返回给第二客户端。当然，在实际应用中，还可以由服务器预先将预约试驾订单信息提供给第二客户端，第二客户端可以在获得用户信息后，直接根据本地保存的信息，确定出关联的预约试驾订单信息。其中，第二客户端获得的用户信息具体可以是采集到的用户生物体征信息等，例如，用户的人脸图像数据，等等。

S702：通过所述终端设备进行所述预约试驾订单信息展示，其中包括用于发起提车试驾操作的操作选项；

S703：通过所述操作选项接收到操作请求后，提交到服务器，并接收服务器返回的所述订单关联的目标车辆在所述目标实体店中的位置信息以及目标钥匙的位置信息；其中，所述服务器用于对实体店内的车辆位置信息以及钥匙位置信息进行保存；

S704：根据所述目标车辆位置信息生成第一位置指令，根据所述目标钥匙位置信息生成第二位置指令，以用于分别控制所述目标车辆以及所述目标钥匙的自动取出。

关于该实施例四中的未详述部分可以参见前述实施例三中的记载，这里不再赘述。

与实施例一相对应，本申请实施例还提供了一种车辆预约试驾信息处理装置，参见图8，该装置应用于服务器，包括：

信息保存单元801，用于保存多个实体店内可预约试驾车辆及其库存信息；

请求接收单元802，用于接收第一客户端提交的预约试驾请求；

订单生成单元803，用于确定待试驾的目标车辆信息、时间信息以及目标实体店，并生成预约试驾订单。

具体实现时，该装置还可以包括：

目标车辆信息接收单元，用于所述接收第一客户端提交的预约试驾请求之前，接收所述第一客户端提交的目标车辆信息；

确定单元，用于确定所述实体店内是否存在对应的可预约试驾的车辆；

第一车辆信息提供单元，用于如果存在，则提供该车辆的信息，并提供用于提交预约试驾请求的操作选项。

其中，所述目标车辆信息接收单元具体可以用于：

接收所述第一客户端提交的车辆图像信息，通过对所述车辆图像信息进行识别，确定目标车辆信息对应的品牌及车型信息。

另一种实现方式下，所述装置还可以包括：

浏览请求接收单元，用于所述接收第一客户端提交的预约试驾请求之前，接收第一客户端提交的浏览请求；

可选实体店信息提供单元，用于根据所述第一客户端关联第一用户所在的地理位置信息，提供可选的实体店信息；

第二车辆信息提供单元，用于在目标实体店被选中后，提供该目标实体店内可预约试驾车辆的信息，以及各自对应的用于提交预约试驾请求的操作选项。

再者，该装置还可以包括：

搜索请求接收单元，用于所述接收第一客户端提交的预约试驾请求之前，接收第一客户端提交的搜索请求；

搜索单元，用于根据所述第一客户端关联第一用户所在的地理位置信息，确定目标实体店，并判断所述目标实体店中是否存在满足搜索条件的可预约车辆；

第三车辆信息提供单元，用于如果存在，则提供可预约车辆信息，以及对应的用于提交预约试驾请求的操作选项。

另外，在具体实现时，该装置还可以包括：

购车意向值确定单元，用于所述生成预约试驾订单之前，确定所述第一客户端关联的第一用户购车的意向值；

订单生成与否确定单元，用于根据该意向值，确定是否为所述第一用户生成预约试驾订单。

或者，还可以包括：

可预约车辆确定单元，用于根据所述意向值，为该第一用户提供可选的可预约试驾的车辆。

具体实现时，所述购车意向值确定单元具体可以用于：

根据所述第一客户端关联的第一用户缴纳的意向资源的数量，确定所述第一用户的购车意值。

此时，该装置还可以包括：

意向资源数量确定单元，用于确定所述待试驾的目标车辆后，根据所述目标车辆对应的资源信息，确定需缴纳的意向资源的数量。

或者，该装置还可以包括：

浏览请求接收单元，用于在接收第一客户端提交的预约试驾请求之前，接收所述第一客户端提交的对可预约试驾的车辆信息进行浏览的请求；

可选车辆信息提供单元，用于根据所述第一客户端关联第一用户已缴纳意向资源的数量，以及各车辆对应的资源信息，为该第一用户确定可选的车辆信息，并提供给所述第一客户端供所述第一用户进行选择。

另一种方式下，所述购车意向值确定单元具体可以用于：

根据所述第一客户端关联的第一用户的信用等级信息，确定所述第一用户的购车意值。

在实际应用中，该装置还可以包括：

预约试驾次数确定单元，用于所述生成预约试驾订单之前，确定所述第一客户端关联第一用户在预置时间段内的预约试驾次数；

触发单元，用于如果所述预约试驾次数未达到预置阈值，则触发所述生成预约试驾订单的步骤。

另外还可以包括：

信息录入界面提供单元，用于提供用于输入驾驶员信息的界面；

验证单元，用于接收到驾驶员信息后，通过预置的查询系统对所述驾驶员信息进行验证。

生物体征信息采集单元，用于采集所述第一客户端关联第一用户的生物体征信息；

比对单元，用于对采集到的生物体征信息与预先保存的所述第一用户关联的生物体征信息进行比对，确定是否为所述第一用户本人操作。

绑定单元，用于在确定出是所述第一用户本人操作时，将所述采集到的生物体征信息与所述预约试驾订单信息进行绑定。

另外，所述生成预约试驾订单时，该装置还可以包括：

试驾类型确定单元，用于确定试驾类型信息，并添加到所述预约试驾订单中。

其中，所述试驾类型包括集中试驾以及深度试驾，所述集中试驾为在指定的试驾场所内对预约的至少一个车辆进行试驾，所述深度试驾为在指定时间段内对预约的车辆进行无固定试驾场所限制的试驾。

其中，如果所选定的试驾类型为深度试驾，则所述装置还可以包括：

地理区域范围确定单元，用于确定可试驾的地理区域范围信息，并添加到所述预约试驾订单中。

其中，所述地理区域范围确定单元具体可以用于：

根据所述目标实体店所在的地理位置信息，确定可试驾的地理区域范围信息。

或者，所述地理区域范围确定单元具体可以用于：

根据所述第一客户端关联第一用户相关的地理位置信息，确定可试驾的地理区域范围信息。

另外，其中，所述地理区域范围确定单元还可以用于：

将事故多发路段排除在所述可试驾地理区域范围之外。

与实施例二相对应，本申请实施例还提供了一种车辆预约试驾信息处理装置，参见图9，该装置应用于第一客户端，包括：

界面提供单元901，用于提供可预约试驾车辆信息界面，所述界面中包括用于对车辆进行预约试驾的操作选项；其中，所述可预约试驾车辆位于实体店内；

信息确定单元902，用于通过所述操作选项接收到对目标车辆信息的操作后，确定预约的时间信息以及目标门店信息；

信息提交单元903，用于根据所述目标车辆信息、所述时间信息以及目标门店信息，向服务端提交预约试驾请求，以用于生成预约试驾订单。

其中，所述界面提供单元具体可以用于：

提供实体店内可预约试驾车辆的列表信息界面，以用于从所述列表中进行目标车辆的选择。

或者，所述界面提供单元也可以用于：

根据接收到的搜索关键词，从所述实体店关联的可预约试驾车辆信息中，搜索出符合搜索条件的可预约试驾车辆，并在所述界面中进行提供。

再者，所述界面提供单元还可以用于：

提供用于进行图像采集的操作选项；

接收到图像采集请求后，获得车辆图像采集结果；

将所述车辆图像采集结果提交到服务器，以用于通过对所述车辆图像信息进行识别，确定对应的品牌及车型信息，并确定所述实体店内是否存在对应的可预约试驾的车辆，若存在，则返回该车辆的信息；

在所述界面中提供该车辆的信息。

与实施例三相对应，本申请实施例还提供了一种车辆预约试驾信息处理装置，参见图10，该装置应用于服务器，包括：

信息保存单元1001，用于对多个实体店内的可预约试驾车辆的位置信息以及钥匙位置信息进行保存；

订单确定单元1002，用于根据第二客户端提交的信息确定到达目标实体店指定终端设备前的用户信息，并确定关联的预约试驾订单信息；

订单信息提供单元1003，用于将所述预约试驾订单信息提供给所述第二客户端，以用于通过所述终端设备进行展示并提供用于发起提车试驾操作的操作选项；

位置信息确定单元1004，用于通过所述操作选项接收到操作请求后，根据所述预约试驾订单中的目标车辆信息以及所述保存的信息确定目标车辆位置信息以及目标钥匙位置信息，并返回给所述第二客户端，以用于分别控制所述目标车辆以及所述目标钥匙的自动取出。

具体实现时，该装置还可以包括：

订单状态修改单元，用于将所述预约试驾订单的状态修改为试驾中状态。

具体实现时，所述目标车辆中还可以配备有定位装置，所述预约试驾订单中还记录有可试驾的地理区域范围信息；所述装置还可以包括：

跟踪单元，用于对所述目标车辆的位置进行跟踪；

提示单元，用于在所述目标车辆即将超出所述地理区域范围时，通过第一客户端提供提示信息。

另外，该装置还可以包括：

库存信息更新单元，用于接收到将所述目标车辆归还的信息后，更新对应实体店内对应车辆的库存信息。

可售车辆信息提供单元，用于如果再次根据第二客户端提交的信息确定出到达目标实体店指定终端设备前的用户信息，且该用户信息关联的预约试驾订单信息处于试驾结束状态，则向所述第二客户端提供与所述预约试驾订单中的目标车辆关联的可售车辆信息。

购买指令接收单元，用于接收通过所述第二客户端提交的车辆选择结果以及购买指令信息；

第一图形码提供单元，用于向所述第二客户端提供第一图形码，以用于通过第一客户端扫描所述第一图形码的方式进行登录；

承接页面生成单元，用于根据所述登录的用户账户信息、所述车辆选择结果以及对应的可选购车方案信息，生成承接页面；

承接页面提供单元，用于将所述承接页面信息返回给所述第二客户端，以用于对所述可选购车方案信息进行展示。

评估单元，用于接收到所述第二客户端提交的购车方案选择结果后，根据所述第一用户的信用记录信息进行评估，并向所述第二客户端返回评估结果。

支付操作选项提供单元，用于如果评估通过，则提供用于支付的操作选项；

第二图形码生成单元，用于通过所述用于支付的操作选项接收到操作请求后，生成用于跳转到支付界面的链接，并根据所述链接生成第二图形码，以用于通过第一客户端扫描所述第二图形码的方式，跳转到支付界面。

与实施例四相对应，本申请实施例还提供了一种车辆预约试驾信息处理装置，参见图11，该装置应用于第二客户端，包括：

订单信息确定单元1101，用于获取到达目标实体店指定终端设备前的用户的信息，并确定关联的预约试驾订单信息；

订单展示单元1102，用于通过所述终端设备进行所述预约试驾订单信息展示，其中包括用于发起提车试驾操作的操作选项；

请求提交单元1103，用于通过所述操作选项接收到操作请求后，提交到服务器，并接收服务器返回的所述订单关联的目标车辆在所述目标实体店中的位置信息以及目标钥匙的位置信息；其中，所述服务器用于对所述实体店内的车辆位置信息以及钥匙位置信息进行保存；

指令生成单元1104，用于根据所述目标车辆位置信息生成第一位置指令，根据所述目标钥匙位置信息生成第二位置指令，以用于分别控制所述目标车辆以及所述目标钥匙的自动取出。

另外，与实施例二对应，本申请实施例还提供了一种电子设备，包括：

一个或多个处理器；以及

与所述一个或多个处理器关联的存储器，所述存储器用于存储程序指令,所述程序指令在被所述一个或多个处理器读取执行时，执行如下操作：

提供可预约试驾车辆信息界面，所述界面中包括用于对车辆进行预约试驾的操作选项；其中，所述可预约试驾车辆位于实体店内；

通过所述操作选项接收到对目标车辆信息的操作后，确定预约的时间信息以及目标门店信息以及目标门店信息；

根据所述目标车辆信息、所述时间信息以及目标门店信息，向服务端提交预约试驾请求，以用于生成预约试驾订单。

与实施例四对应，本申请实施例还提供了一种电子设备，包括：

一个或多个处理器；以及

与所述一个或多个处理器关联的存储器，所述存储器用于存储程序指令,所述程序指令在被所述一个或多个处理器读取执行时，执行如下操作：

获取到达目标实体店指定终端设备前的用户的信息，并确定关联的预约试驾订单信息；

通过所述终端设备进行所述预约试驾订单信息展示，其中包括用于发起提车试驾操作的操作选项；

通过所述操作选项接收到操作请求后，提交到服务器，并接收服务器返回的所述订单关联的目标车辆在所述目标实体店中的位置信息以及目标钥匙的位置信息；其中，所述服务器用于对所述实体店内的车辆位置信息以及钥匙位置信息进行保存；

根据所述目标车辆位置信息生成第一位置指令，根据所述目标钥匙位置信息生成第二位置指令，以用于分别控制所述目标车辆以及所述目标钥匙的自动取出。

其中，图12示例性的展示出了电子设备的架构，例如，设备1200可以是移动电话，计算机，数字广播终端，消息收发设备，游戏控制台，平板设备，医疗设备，健身设备，个人数字助理，飞行器等。

参照图12，设备1200可以包括以下一个或多个组件：处理组件1202，存储器1204，电源组件1206，多媒体组件1208，音频组件1210，输入/输出(I/O)的接口1212，传感器组件1214，以及通信组件1216。

处理组件1202通常控制设备1200的整体操作，诸如与显示，电话呼叫，数据通信，相机操作和记录操作相关联的操作。处理元件1202可以包括一个或多个处理器1220来执行指令，以完成本公开技术方案提供的视频播放方法中的当满足预设条件时，生成流量压缩请求，并发送给服务器，其中所述流量压缩请求中记录有用于触发服务器获取目标关注区域的信息，所述流量压缩请求用于请求服务器优先保证目标关注区域内视频内容的码率；根据服务器返回的码流文件播放所述码流文件对应的视频内容，其中所述码流文件为服务器根据所述流量压缩请求对所述目标关注区域之外的视频内容进行码率压缩处理得到的视频文件的全部或部分步骤。此外，处理组件1202可以包括一个或多个模块，便于处理组件1202和其他组件之间的交互。例如，处理部件1202可以包括多媒体模块，以方便多媒体组件1208和处理组件1202之间的交互。

存储器1204被配置为存储各种类型的数据以支持在设备1200的操作。这些数据的示例包括用于在设备1200上操作的任何应用程序或方法的指令，联系人数据，电话簿数据，消息，图片，视频等。存储器1204可以由任何类型的易失性或非易失性存储设备或者它们的组合实现，如静态随机存取存储器(SRAM)，电可擦除可编程只读存储器(EEPROM)，可擦除可编程只读存储器(EPROM)，可编程只读存储器(PROM)，只读存储器(ROM)，磁存储器，快闪存储器，磁盘或光盘。

电源组件1206为设备1200的各种组件提供电力。电源组件1206可以包括电源管理系统，一个或多个电源，及其他与为设备1200生成、管理和分配电力相关联的组件。

多媒体组件1208包括在设备1200和用户之间的提供一个输出接口的屏幕。在一些实施例中，屏幕可以包括液晶显示器(LCD)和触摸面板(TP)。如果屏幕包括触摸面板，屏幕可以被实现为触摸屏，以接收来自用户的输入信号。触摸面板包括一个或多个触摸传感器以感测触摸、滑动和触摸面板上的手势。触摸传感器可以不仅感测触摸或滑动动作的边界，而且还检测与触摸或滑动操作相关的持续时间和压力。在一些实施例中，多媒体组件1208包括一个前置摄像头和/或后置摄像头。当设备1200处于操作模式，如拍摄模式或视频模式时，前置摄像头和/或后置摄像头可以接收外部的多媒体数据。每个前置摄像头和后置摄像头可以是一个固定的光学透镜系统或具有焦距和光学变焦能力。

音频组件1210被配置为输出和/或输入音频信号。例如，音频组件1210包括一个麦克风(MIC)，当设备1200处于操作模式，如呼叫模式、记录模式和语音识别模式时，麦克风被配置为接收外部音频信号。所接收的音频信号可以被进一步存储在存储器1204或经由通信组件1216发送。在一些实施例中，音频组件1210还包括一个扬声器，用于输出音频信号。

I/O接口1212为处理组件1202和外围接口模块之间提供接口，上述外围接口模块可以是键盘，点击轮，按钮等。这些按钮可包括但不限于：主页按钮、音量按钮、启动按钮和锁定按钮。

传感器组件1214包括一个或多个传感器，用于为设备1200提供各个方面的状态评估。例如，传感器组件1214可以检测到设备1200的打开/关闭状态，组件的相对定位，例如所述组件为设备1200的显示器和小键盘，传感器组件1214还可以检测设备1200或设备1200一个组件的位置改变，用户与设备1200接触的存在或不存在，设备1200方位或加速/减速和设备1200的温度变化。传感器组件1214可以包括接近传感器，被配置用来在没有任何的物理接触时检测附近物体的存在。传感器组件1214还可以包括光传感器，如CMOS或CCD图像传感器，用于在成像应用中使用。在一些实施例中，该传感器组件1214还可以包括加速度传感器，陀螺仪传感器，磁传感器，压力传感器或温度传感器。

通信组件1216被配置为便于设备1200和其他设备之间有线或无线方式的通信。设备1200可以接入基于通信标准的无线网络，如WiFi，2G或3G，或它们的组合。在一个示例性实施例中，通信部件1216经由广播信道接收来自外部广播管理系统的广播信号或广播相关信息。在一个示例性实施例中，所述通信部件1216还包括近场通信(NFC)模块，以促进短程通信。例如，在NFC模块可基于射频识别(RFID)技术，红外数据协会(IrDA)技术，超宽带(UWB)技术，蓝牙(BT)技术和其他技术来实现。

在示例性实施例中，设备1200可以被一个或多个应用专用集成电路(ASIC)、数字信号处理器(DSP)、数字信号处理设备(DSPD)、可编程逻辑器件(PLD)、现场可编程门阵列(FPGA)、控制器、微控制器、微处理器或其他电子元件实现，用于执行上述方法。

在示例性实施例中，还提供了一种包括指令的非临时性计算机可读存储介质，例如包括指令的存储器1204，上述指令可由设备1200的处理器1220执行以完成本公开技术方案提供的视频播放方法中的当满足预设条件时，生成流量压缩请求，并发送给服务器，其中所述流量压缩请求中记录有用于触发服务器获取目标关注区域的信息，所述流量压缩请求用于请求服务器优先保证目标关注区域内视频内容的码率；根据服务器返回的码流文件播放所述码流文件对应的视频内容，其中所述码流文件为服务器根据所述流量压缩请求对所述目标关注区域之外的视频内容进行码率压缩处理得到的视频文件。例如，所述非临时性计算机可读存储介质可以是ROM、随机存取存储器(RAM)、CD-ROM、磁带、软盘和光数据存储设备等。

本说明书中的各个实施例均采用递进的方式描述，各个实施例之间相同相似的部分互相参见即可，每个实施例重点说明的都是与其他实施例的不同之处。尤其，对于系统或系统实施例而言，由于其基本相似于方法实施例，所以描述得比较简单，相关之处参见方法实施例的部分说明即可。以上所描述的系统及系统实施例仅仅是示意性的，其中所述作为分离部件说明的单元可以是或者也可以不是物理上分开的，作为单元显示的部件可以是或者也可以不是物理单元，即可以位于一个地方，或者也可以分布到多个网络单元上。可以根据实际的需要选择其中的部分或者全部模块来实现本实施例方案的目的。本领域普通技术人员在不付出创造性劳动的情况下，即可以理解并实施。

以上对本申请所提供的车辆预约试驾信息处理方法、装置及电子设备，进行了详细介绍，本文中应用了具体个例对本申请的原理及实施方式进行了阐述，以上实施例的说明只是用于帮助理解本申请的方法及其核心思想；同时，对于本领域的一般技术人员，依据本申请的思想，在具体实施方式及应用范围上均会有改变之处。综上所述，本说明书内容不应理解为对本申请的限制。

Claims (40)

1.一种车辆预约试驾信息处理方法，其特征在于，包括：

服务器保存多个实体店内可预约试驾车辆及其库存信息；

接收第一客户端提交的预约试驾请求；

确定待试驾的目标车辆信息、时间信息以及目标实体店，并生成预约试驾订单。

2.根据权利要求1所述的方法，其特征在于，所述接收第一客户端提交的预约试驾请求之前还包括：

接收所述第一客户端提交的目标车辆信息；

确定所述实体店内是否存在对应的可预约试驾的车辆；

如果存在，则提供该车辆的信息，并提供用于提交预约试驾请求的操作选项。

3.根据权利要求2所述的方法，其特征在于，所述接收所述第一客户端提交的目标车辆信息，包括：

接收所述第一客户端提交的车辆图像信息；

通过对所述车辆图像信息进行识别，确定目标车辆信息对应的品牌及车型信息。

4.根据权利要求1所述的方法，其特征在于，所述接收第一客户端提交的预约试驾请求之前还包括：

接收第一客户端提交的浏览请求；

根据所述第一客户端关联第一用户所在的地理位置信息，提供可选的实体店信息；

在目标实体店被选中后，提供该目标实体店内可预约试驾车辆的信息，以及各自对应的用于提交预约试驾请求的操作选项。

5.根据权利要求1所述的方法，其特征在于，所述接收第一客户端提交的预约试驾请求之前还包括：

接收第一客户端提交的搜索请求；

根据所述第一客户端关联第一用户所在的地理位置信息，确定目标实体店，并判断所述目标实体店中是否存在满足搜索条件的可预约车辆；

如果存在，则提供可预约车辆信息，以及对应的用于提交预约试驾请求的操作选项。

6.根据权利要求1所述的方法，其特征在于，所述生成预约试驾订单之前还包括：

确定所述第一客户端关联的第一用户购车的意向值；

根据该意向值，确定是否为所述第一用户生成预约试驾订单。

7.根据权利要求6所述的方法，其特征在于，还包括：

根据所述意向值，为该第一用户提供可选的可预约试驾的车辆。

8.根据权利要求6所述的方法，其特征在于，所述确定所述第一客户端关联的第一用户购车的意向值，包括：

根据所述第一客户端关联的第一用户缴纳的意向资源的数量，确定所述第一用户的购车意值。

9.根据权利要求8所述的方法，其特征在于，还包括：

确定所述待试驾的目标车辆后，根据所述目标车辆对应的资源信息，确定需缴纳的意向资源的数量。

10.根据权利要求8所述的方法，其特征在于，还包括：

在接收第一客户端提交的预约试驾请求之前，接收所述第一客户端提交的对可预约试驾的车辆信息进行浏览的请求；

根据所述第一客户端关联第一用户已缴纳意向资源的数量，以及各车辆对应的资源信息，为该第一用户确定可选的车辆信息，并提供给所述第一客户端供所述第一用户进行选择。

11.根据权利要求6所述的方法，其特征在于，所述确定所述第一客户端关联的第一用户购车的意向值，包括：

根据所述第一客户端关联的第一用户的信用等级信息，确定所述第一用户的购车意值。

12.根据权利要求1所述的方法，其特征在于，所述生成预约试驾订单之前还包括：

确定所述第一客户端关联第一用户在预置时间段内的预约试驾次数；

如果所述预约试驾次数未达到预置阈值，则触发所述生成预约试驾订单的步骤。

13.根据权利要求1所述的方法，其特征在于，所述生成预约试驾订单之前还包括：

提供用于输入驾驶员信息的界面；

接收到驾驶员信息后，通过预置的查询系统对所述驾驶员信息进行验证。

14.根据权利要求1所述的方法，其特征在于，所述生成预约试驾订单之前还包括：

采集所述第一客户端关联第一用户的生物体征信息；

对采集到的生物体征信息与预先保存的所述第一用户关联的生物体征信息进行比对，确定是否为所述第一用户本人操作。

15.根据权利要求14所述的方法，其特征在于，还包括：

在确定出是所述第一用户本人操作时，将所述采集到的生物体征信息与所述预约试驾订单信息进行绑定。

16.根据权利要求1所述的方法，其特征在于，所述生成预约试驾订单时还包括：

确定试驾类型信息，并添加到所述预约试驾订单中。

17.根据权利要求16所述的方法，其特征在于，所述试驾类型包括集中试驾以及深度试驾，所述集中试驾为在指定的试驾场所内对预约的至少一个车辆进行试驾，所述深度试驾为在指定时间段内对预约的车辆进行无固定试驾场所限制的试驾。

18.根据权利要求17所述的方法，其特征在于，如果所选定的试驾类型为深度试驾，则所述方法还包括：

确定可试驾的地理区域范围信息，并添加到所述预约试驾订单中。

19.根据权利要求18所述的方法，其特征在于，所述确定可试驾的地理区域范围信息，包括：

根据所述目标实体店所在的地理位置信息，确定可试驾的地理区域范围信息。

20.根据权利要求18所述的方法，其特征在于，所述确定可试驾的地理区域范围信息，包括：

根据所述第一客户端关联第一用户相关的地理位置信息，确定可试驾的地理区域范围信息。

21.根据权利要求18所述的方法，其特征在于，还包括：

将事故多发路段排除在所述可试驾地理区域范围之外。

22.一种车辆预约试驾信息处理方法，其特征在于，包括：

第一客户端提供可预约试驾车辆信息界面，所述界面中包括用于对车辆进行预约试驾的操作选项；其中，所述可预约试驾车辆位于实体店内；

通过所述操作选项接收到对目标车辆信息的操作后，确定预约的时间信息以及目标门店信息以及目标门店信息；

根据所述目标车辆信息、所述时间信息以及目标门店信息，向服务端提交预约试驾请求，以用于生成预约试驾订单。

23.根据权利要求22所述的方法，其特征在于，所述提供可预约试驾车辆信息界面，包括：

提供实体店内可预约试驾车辆的列表信息界面，以用于从所述列表中进行目标车辆的选择。

24.根据权利要求22所述的方法，其特征在于，所述提供可预约试驾车辆信息界面，包括：

根据接收到的搜索关键词，从所述实体店关联的可预约试驾车辆信息中，搜索出符合搜索条件的可预约试驾车辆，并在所述界面中进行提供。

25.根据权利要求22所述的方法，其特征在于，所述提供可预约试驾车辆信息界面，包括：

提供用于进行图像采集的操作选项；

接收到图像采集请求后，获得车辆图像采集结果；

将所述车辆图像采集结果提交到服务器，以用于通过对所述车辆图像信息进行识别，确定对应的品牌及车型信息，并确定所述实体店内是否存在对应的可预约试驾的车辆，若存在，则返回该车辆的信息；

在所述界面中提供该车辆的信息。

26.一种车辆预约试驾信息处理方法，其特征在于，包括：

服务器对多个实体店内的可预约试驾车辆的位置信息以及钥匙位置信息进行保存；

根据第二客户端提交的信息确定到达目标实体店指定终端设备前的用户信息，并确定关联的预约试驾订单信息；

将所述预约试驾订单信息提供给所述第二客户端，以用于通过所述终端设备进行展示并提供用于发起提车试驾操作的操作选项；

通过所述操作选项接收到操作请求后，根据所述预约试驾订单中的目标车辆信息以及所述保存的信息确定目标车辆位置信息以及目标钥匙位置信息，并返回给所述第二客户端，以用于分别控制所述目标车辆以及所述目标钥匙的自动取出。

27.根据权利要求26所述的方法，其特征在于，还包括：

将所述预约试驾订单的状态修改为试驾中状态。

28.根据权利要求26所述的方法，其特征在于，所述目标车辆中配备有定位装置，所述预约试驾订单中还记录有可试驾的地理区域范围信息；所述方法还包括：

对所述目标车辆的位置进行跟踪；

在所述目标车辆即将超出所述地理区域范围时，通过第一客户端提供提示信息。

29.根据权利要求26所述的方法，其特征在于，还包括：

接收到将所述目标车辆归还的信息后，更新对应实体店内对应车辆的库存信息。

30.根据权利要求26所述的方法，其特征在于，还包括：

如果再次根据第二客户端提交的信息确定出到达目标实体店指定终端设备前的用户信息，且该用户信息关联的预约试驾订单信息处于试驾结束状态，则向所述第二客户端提供与所述预约试驾订单中的目标车辆关联的可售车辆信息。

31.根据权利要求30所述的方法，其特征在于，还包括：

接收通过所述第二客户端提交的车辆选择结果以及购买指令信息；

向所述第二客户端提供第一图形码，以用于通过第一客户端扫描所述第一图形码的方式进行登录；

根据所述登录的用户账户信息、所述车辆选择结果以及对应的可选购车方案信息，生成承接页面；

将所述承接页面信息返回给所述第二客户端，以用于对所述可选购车方案信息进行展示。

32.根据权利要求31所述的方法，其特征在于，还包括：

接收到所述第二客户端提交的购车方案选择结果后，根据所述第一用户的信用记录信息进行评估，并向所述第二客户端返回评估结果。

33.根据权利要求32所述的方法，其特征在于，还包括：

如果评估通过，则提供用于支付的操作选项；

通过所述用于支付的操作选项接收到操作请求后，生成用于跳转到支付界面的链接，并根据所述链接生成第二图形码，以用于通过第一客户端扫描所述第二图形码的方式，跳转到支付界面。

34.一种车辆预约试驾信息处理方法，其特征在于，包括：

第二客户端获取到达目标实体店指定终端设备前的用户的信息，并确定关联的预约试驾订单信息；

通过所述终端设备进行所述预约试驾订单信息展示，其中包括用于发起提车试驾操作的操作选项；

通过所述操作选项接收到操作请求后，提交到服务器，并接收服务器返回的所述订单关联的目标车辆在所述目标实体店中的位置信息以及目标钥匙的位置信息；其中，所述服务器用于对所述实体店内的车辆位置信息以及钥匙位置信息进行保存；

根据所述目标车辆位置信息生成第一位置指令，根据所述目标钥匙位置信息生成第二位置指令，以用于分别控制所述目标车辆以及所述目标钥匙的自动取出。

35.一种车辆预约试驾信息处理装置，其特征在于，应用于服务器，包括：

信息保存单元，用于保存多个实体店内可预约试驾车辆及其库存信息；

请求接收单元，用于接收第一客户端提交的预约试驾请求；

订单生成单元，用于确定待试驾的目标车辆信息、时间信息以及目标实体店，并生成预约试驾订单。

36.一种车辆预约试驾信息处理装置，其特征在于，应用于第一客户端，包括：

界面提供单元，用于提供可预约试驾车辆信息界面，所述界面中包括用于对车辆进行预约试驾的操作选项；其中，所述可预约试驾车辆位于实体店内；

信息确定单元，用于通过所述操作选项接收到对目标车辆信息的操作后，确定预约的时间信息以及目标门店信息；

信息提交单元，用于根据所述目标车辆信息、所述时间信息以及目标门店信息，向服务端提交预约试驾请求，以用于生成预约试驾订单。

37.一种车辆预约试驾信息处理装置，其特征在于，应用于服务器，包括：

信息保存单元，用于对多个实体店内的可预约试驾车辆的位置信息以及钥匙位置信息进行保存；

订单确定单元，用于根据第二客户端提交的信息确定到达目标实体店指定终端设备前的用户信息，并确定关联的预约试驾订单信息；

订单信息提供单元，用于将所述预约试驾订单信息提供给所述第二客户端，以用于通过所述终端设备进行展示并提供用于发起提车试驾操作的操作选项；

位置信息确定单元，用于通过所述操作选项接收到操作请求后，根据所述预约试驾订单中的目标车辆信息以及所述保存的信息确定目标车辆位置信息以及目标钥匙位置信息，并返回给所述第二客户端，以用于分别控制所述目标车辆以及所述目标钥匙的自动取出。

38.一种车辆预约试驾信息处理装置，其特征在于，应用于第二客户端，包括：

订单信息确定单元，用于获取到达目标实体店指定终端设备前的用户的信息，并确定关联的预约试驾订单信息；

订单展示单元，用于通过所述终端设备进行所述预约试驾订单信息展示，其中包括用于发起提车试驾操作的操作选项；

请求提交单元，用于通过所述操作选项接收到操作请求后，提交到服务器，并接收服务器返回的所述订单关联的目标车辆在所述目标实体店中的位置信息以及目标钥匙的位置信息；其中，所述服务器用于对所述实体店内的车辆位置信息以及钥匙位置信息进行保存；

指令生成单元，用于根据所述目标车辆位置信息生成第一位置指令，根据所述目标钥匙位置信息生成第二位置指令，以用于分别控制所述目标车辆以及所述目标钥匙的自动取出。

39.一种电子设备，其特征在于，包括：

一个或多个处理器；以及

与所述一个或多个处理器关联的存储器，所述存储器用于存储程序指令,所述程序指令在被所述一个或多个处理器读取执行时，执行如下操作：

提供可预约试驾车辆信息界面，所述界面中包括用于对车辆进行预约试驾的操作选项；其中，所述可预约试驾车辆位于实体店内；

通过所述操作选项接收到对目标车辆信息的操作后，确定预约的时间信息以及目标门店信息以及目标门店信息；

根据所述目标车辆信息、所述时间信息以及目标门店信息，向服务端提交预约试驾请求，以用于生成预约试驾订单。

40.一种电子设备，其特征在于，包括：

一个或多个处理器；以及

与所述一个或多个处理器关联的存储器，所述存储器用于存储程序指令,所述程序指令在被所述一个或多个处理器读取执行时，执行如下操作：

获取到达目标实体店指定终端设备前的用户的信息，并确定关联的预约试驾订单信息；

通过所述终端设备进行所述预约试驾订单信息展示，其中包括用于发起提车试驾操作的操作选项；

通过所述操作选项接收到操作请求后，提交到服务器，并接收服务器返回的所述订单关联的目标车辆在所述目标实体店中的位置信息以及目标钥匙的位置信息；其中，所述服务器用于对所述实体店内的车辆位置信息以及钥匙位置信息进行保存；

根据所述目标车辆位置信息生成第一位置指令，根据所述目标钥匙位置信息生成第二位置指令，以用于分别控制所述目标车辆以及所述目标钥匙的自动取出。