用户身份验证方法和装置与流程

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.图1为本技术实施例提供的一种汽车自动个性化配置的流程示意图；
35.图2为本技术实施例提供的一种座椅验证系统的示意图；
36.图3为本技术实施例提供的一种用户身份验证方法的流程示意图；
37.图4为本技术实施例提供的一种用户身份验证方法的流程示意图；
38.图5为本技术实施例提供的一种用户身份验证方法的流程示意图；
39.图6为本技术实施例提供的一种用户身份验证方法的流程示意图；
40.图7为本技术实施例提供的一种用户身份验证方法的流程示意图；
41.图8为本技术实施例提供的一种用户身份验证装置的结构示意图；
42.图9为本技术实施例提供的另一种用户身份验证装置的结构示意图；
43.图10为本技术实施例提供的一种芯片的结构示意图；
44.图11为本技术实施例提供的一种车辆的结构示意图。
具体实施方式
45.为了便于清楚描述本技术实施例的技术方案，在本技术的实施例中，采用了“第一”、“第二”等字样对功能和作用基本相同的相同项或相似项进行区分。例如，第一阈值和第二阈值仅仅是为了区分不同的阈值，并不对其先后顺序进行限定。本领域技术人员可以理解“第一”、“第二”等字样并不对数量和执行次序进行限定，并且“第一”、“第二”等字样也并不限定一定不同。
46.需要说明的是，本技术实施例中，“示例性的”或者“例如”等词用于表示作例子、例证或说明。本技术中被描述为“示例性的”或者“例如”的任何实施例或设计方案不应被解释
为比其他实施例或设计方案更优选或更具优势。确切而言，使用“示例性的”或者“例如”等词旨在以具体方式呈现相关概念。
47.本技术实施例中，“至少一个”是指一个或者多个，“多个”是指两个或两个以上。“和/或”，描述关联对象的关联关系，表示可以存在三种关系，例如，a和/或b，可以表示：单独存在a，同时存在a和b，单独存在b的情况，其中a，b可以是单数或者复数。字符“/”一般表示前后关联对象是一种“或”的关系。“以下至少一项(个)”或其类似表达，是指的这些项中的任意组合，包括单项(个)或复数项(个)的任意组合。例如，a，b，或c中的至少一项(个)，可以表示：a，b，c，a-b，a-c，b-c，或a-b-c，其中a，b，c可以是单个，也可以是多个。
48.随着社会的发展，越来越多的汽车进入家庭，受到家庭经济水平或者汽车购买指标的限制，一辆车可能被多人使用，在使用汽车的过程中，用户可以根据自己的生理特征和偏好，通过操作完成对汽车的个性化配置。
49.例如，汽车的个性化配置可以包括座椅、后视镜、方向盘、空调、娱乐系统、安全气囊或辅助驾驶功能等的个性化配置；其中，对座椅的个性化配置可以理解为调整座椅的高度位置或靠背位置等，对后视镜的个性化配置可以理解为调整后视镜的位置或角度等。
50.可能的情况中，用户可能依次执行以下过程：调整座椅的高度、打开空调、打开娱乐系统及调整后视镜位置，完成对汽车的个性化配置，但是，用户对汽车进行个性化配置的过程耗时费力，而且也会影响用户对汽车的使用体验，因此，一种可能的实现方式中，可以采用自动化的方式完成对汽车的个性化配置。
51.示例性的，图1为本技术实施例提供的一种汽车自动个性化配置的流程示意图，如图1所示，汽车自动个性化配置包括四个步骤：创建用户资料(profile)、用户登录、读取用户资料以及个性化配置。
52.其中，创建用户资料的可能实现为：用户在首次使用汽车时，可以通过手动输入的方式录入用户资料，用户资料中记录了用户的生理特征和配置参数。或者，当用户对汽车进行个性化配置时，汽车可以自动记录配置参数，并将该配置参数记录在用户资料里。
53.其中，用户登录的可能实现为：用户再次使用汽车时，用户打开了汽车座舱，此时，汽车接收了用户的登录操作。
54.其中，读取用户资料的可能实现为：汽车接收了用户的登录操作，汽车可以从该用户对应的用户资料里读取配置参数。
55.其中，个性化配置的可能实现为：汽车从用户资料里读取了配置参数，汽车可以根据该配置参数进行个性化配置。
56.用户可以基于图1所示的汽车自动个性化配置流程，完成对汽车的个性化配置，从而节省对汽车的个性化配置的时间，提高用户体验。
57.需要说明的是，在图1所示的汽车自动个性化配置流程中，用户登录后，需要在登录验证为通过的情况下，才可以读取用户资料中的配置参数。因而，登录验证的方式包括以下可能的实现方式：
58.方式一，可以采用车钥匙的方式进行验证。例如，用户可以通过点击车钥匙上的开启按钮，打开汽车座舱，从而判定登录验证为通过。
59.方式二，可以采用手机的方式进行验证。例如，在手机已安装汽车应用程序(application，app)的情况下，用户通过点击该汽车app中的选项，例如，开启座舱选项，打
开汽车座舱，从而判定登录验证为通过。
60.方式三，可以采用用户密码的方式进行验证。例如，用户可以通过在车载显示屏上输入用户密码，在用户密码正确的情况下，从而判定登录验证为通过。
61.但是，上述方式一至方式三中可能存在误用或者盗用的情况。
62.其中，误用的场景可以为：若实际用户误拿了车钥匙或手机，并用该车钥匙或手机打开汽车座舱，汽车对比之前使用该车钥匙或该手机打开座舱的用户记录，判定登录验证为通过，事实上，实际用户与登录的用户资料里的用户不一致，并且由于实际用户与用户资料里的用户的生理特征和偏好不同，当使用用户资料里的配置参数对汽车进行个性化配置时，既影响舒适性，又可能使得实际用户对汽车的不熟练操作而带来安全风险。
63.其中，盗用的场景可以为：有人盗用了用户的车钥匙或手机，或者，有人知晓了该用户密码，这样，该人可以通过登录的账号，了解用户资料里的用户经常输入的地点，再结合汽车驾驶路线，可能会得到用户资料里的用户的家庭地址或公司地址，从而带来隐私泄露风险。
64.针对误用或者盗用的情况，还可以采用方式四进行验证，具体的，可以采用面部识别的方式进行验证。例如，通过实时地检测用户的面部，在面部与用户资料里的面部一致时，从而读取用户资料里的配置参数。由于面部识别有较强的唯一性，因而可以有效地避免实际用户与用户资料里的用户不一致的情况的发生。
65.但是，采用面部识别的验证方式，需要在汽车座舱内安装摄像头，该摄像头具备面部识别的软件能力，验证成本相对较高。
66.基于此，本技术实施例提供一种用户身份验证方法，应用于智能驾驶领域，方法包括：利用设置于车辆座椅的压力传感器获取用户特征信息；根据用户特征信息验证用户的身份。在本技术实施例的方法中，压力传感器是车辆座椅中普遍具备的，因而基于压力传感器获取的用户特征信息对用户的身份进行验证时，既可以节省验证成本，又可以避免验证时压力传感器盗用或者误用情况的发生，从而有效地避免安全风险和隐私泄露风险。
67.示例性的，图2为本技术实施例提供的一种座椅验证系统的示意图，如图2所示，在图1所示的汽车自动个性化配置的基础上，增加了如图2所示的座椅验证系统，座椅验证系统包括：座椅传感器、预处理模块、验证模块以及配置模块；其中，预处理模块以及验证模块可以部署在座椅控制器上，配置模块可以部署在车身控制器上或其它域控制器上。
68.可能的方式中，座椅传感器和预处理模块之间的接口可以称为接口1(interface1，if1)，预处理模块和验证模块之间的接口可以称为接口2(interface2，if2)，验证模块和配置模块之间的接口可以称为接口3(interface1，if3)。
69.可能的方式中，座椅传感器，用于检测用户对座椅的压力，从而得到传感器检测信号。例如，在座椅传感器包括压力传感器时，压力传感器感受压力信号，并将压力信号转换成电信号，从而得到传感器检测信号；其中，压力传感器可以包括电阻式压力传感器、电感式压力传感器或电容式压力传感器等。进而，座椅传感器可以通过if1向预处理模块发送传感器检测信号。
70.可能的方式中，预处理模块，用于对传感器检测信号进行预处理，从而得到座椅信息。例如，当有力作用于电容式压力传感器，电极之间的电容会发生改变，这样，预处理模块可以根据电容的变化确定座椅信息，该座椅信息用于反映用户特征信息，该座椅信息可以
包括压力值等。进而，预处理模块可以通过if2向验证模块发送座椅信息。
71.可能的方式中，验证模块，用于对座椅信息和用户资料里的用户信息进行验证，从而得到验证结果，进而，验证模块可以通过if3向配置模块发送验证结果。
72.可能的方式中，配置模块，用于根据验证结果进行配置处理。例如，在验证结果为通过的情况下，配置模块可以根据用户资料里的配置参数对汽车进行个性化配置；在验证结果为不通过的情况下，配置模块可以不对汽车进行个性化配置，或者，配置模块可以根据默认的配置参数对汽车进行个性化配置；因此，配置模块基于验证结果对汽车进行配置，既可以节省用户对汽车的配置时间，又可以提高用户对汽车的使用体验。
73.下面以具体的实施例对本技术实施例的技术方案以及本技术实施例的技术方案如何解决上述技术问题进行详细说明。下面这几个具体的实施例可以独立实现，也可以相互结合，对于相同或相似的概念或过程可能在某些实施例中不再赘述。
74.示例性的，图3为本技术实施例提供的一种用户身份验证方法的流程示意图，如图3所示，可以包括以下步骤：
75.s301：利用设置于车辆座椅的压力传感器获取用户特征信息。
76.本技术实施例中，压力传感器可以设置于车辆座椅中，还可以设置于车辆座椅表面，为了便于描述，后续以车辆座椅中的压力传感器为例进行说明。
77.本技术实施例中，压力传感器的数量可以为一个或者多个，在压力传感器的数量不同时，所获取的用户特征信息也不同。
78.在车辆座椅中的压力传感器为一个的情况下，用户特征信息可以反映用户对座椅的挤压效果，因而，用户特征信息可以包括压力等。可以理解，用户特征信息的具体内容也可以根据实际应用场景设定。
79.适应的，利用设置于车辆座椅的压力传感器获取用户特征信息，一种可能的实现方式为：在用户特征信息反映用户对座椅的挤压效果的情况下，利用设置于车辆座椅的压力传感器获取压力。
80.示例性的，当用户坐在座椅上，座椅中的压力传感器感受用户对座椅的挤压效果，不同的挤压效果对应不同的压力信号，压力传感器将压力信号转换成电信号，进而，根据该电信号可以获取压力；利用设置于车辆座椅的压力传感器获取压力的实现方式，也可以根据实际应用场景设定。
81.在车辆座椅中的压力传感器为多个的情况下，用户特征信息为用于描述用户的坐姿轮廓的信息，其中，多个压力传感器可以均匀地分布在座椅的不同位置，或者，多个压力传感器可以不均匀地分布在座椅的不同位置；其中，多个压力传感器均匀地分布在座椅的不同位置，可以理解为，任意相邻的两个传感器之间的距离相等，距离的具体值可以根据实际应用场景设定；可以理解，多个压力传感器分布在座椅上的具体位置，可以根据实际应用场景设定。
82.适应的，利用设置于车辆座椅的压力传感器获取用户特征信息的一种可能的实现方式为：在用户特征信息为用于描述用户的坐姿轮廓的信息的情况下，利用设置于车辆座椅的压力传感器获取座椅上的用户的坐姿形状。
83.示例性的，由于多个压力传感器分布在座椅的受力表面，当用户坐在座椅上，座椅中的压力传感器感受到用户对座椅的挤压效果，不同的挤压效果对应不同的压力信号，不
同的压力信号通过转换可以得到不同方位上的电信号，这样，基于多个压力传感器可以得到多个方位的电信号，因而，通过电信号的能量以及电信号所对应的方位，从而得到座椅上的用户的坐姿形状。可以理解，利用设置于车辆座椅的压力传感器获取座椅上的用户的坐姿形状的实现方式，也可以根据实际应用场景设定，本技术实施例不作具体限定。
84.s302：根据用户特征信息验证用户的身份。
85.本技术实施例中，在车辆座椅中的压力传感器为一个的情况下，用户特征信息可以包括压力等，因而，根据压力验证用户的身份，可以包括以下可能的实现方式：
86.一种可能的实现方式中，在车辆座椅中的压力传感器获取的压力位于第一区间内时，验证用户的身份为通过。例如，用户通过车钥匙或手机的方式打开座舱，用户坐在座椅上，座椅中的压力传感器基于用户对座椅的挤压效果，可以得到挤压效果所对应的压力，在车辆判定压力位于第一区间内时，从而验证用户的身份为通过。
87.例如，压力为200牛顿(n)，第一区间为[180n，220n]，由于200n位于[180n，220n]内，因此，验证用户的身份为通过；可以理解，第一区间的具体范围，也可以根据实际应用场景设定。
[0088]
再一种可能的实现方式中，在车辆座椅中的压力传感器获取的压力不位于第一区间内时，验证用户的身份为未通过。例如，用户通过车钥匙或手机的方式打开座舱，用户坐在座椅上，座椅中的压力传感器基于用户对座椅的挤压效果，可以得到挤压效果所对应的压力，在车辆判定压力不位于第一区间内时，从而验证用户的身份为未通过。
[0089]
例如，压力为160n，第一区间为[180n，220n]，由于160n不位于[180n，220n]内，因此，验证用户的身份为未通过；可以理解，第一区间的具体范围，也可以根据实际应用场景设定。
[0090]
需要说明的是，当车辆座椅中的压力传感器获取的压力为第一区间的最大值或最小值时，验证用户的身份为通过。
[0091]
本技术实施例中，在车辆座椅中的压力传感器为多个的情况下，用户特征信息为用于描述用户的坐姿轮廓的信息，用户的坐姿轮廓的信息可以体现在座椅上的用户的坐姿形状，因而，可以根据座椅上的用户的坐姿形状与预设坐姿形状验证用户的身份，其中，预设坐姿形状可以是用户手动存储在车辆中的，也可以是采用其他方式存储在车辆中的，本技术实施例不作限定；因此，根据座椅上的用户的坐姿形状与预设坐姿形状验证用户的身份，包括以下可能的实现方式：
[0092]
一种可能的实现方式中，在座椅上的用户的坐姿形状对应的二维图像，与预设坐姿形状对应的二维图像之间的相似度大于或等于设定的阈值的情况下，验证用户的身份为通过。
[0093]
例如，用户通过车钥匙或手机的方式打开座舱，用户坐在座椅上，座椅中的多个压力传感器基于用户对座椅的不同方位上的挤压效果，可以得到不同方位上的压力值，因此，根据不同的方位以及不同方位上的压力，可以得到二维图像，该二维图像可以表示座椅上的用户的坐姿形状，这样，车辆在判定用户的坐姿形状对应的二维图像，与预设坐姿形状对应的二维图像之间的相似度大于或等于设定的阈值的情况下，从而验证用户的身份为通过。
[0094]
例如，若预设的坐姿形状对应的二维图像，与多个传感器获取的用户的坐姿形状
对应的二维图像之间的相似度为95％，设定的阈值为90％，由于95％》90％，因此，验证用户的身份为通过。
[0095]
再一种可能的实现方式中，在用户的坐姿形状对应的二维图像，与预设坐姿形状对应的二维图像之间的相似度小于设定的阈值的情况下，验证用户的身份为未通过。例如，用户通过车钥匙或手机的方式打开座舱，用户坐在座椅上，座椅中的多个压力传感器基于用户对座椅的不同方位上的挤压效果，可以得到不同方位上的压力，因此，根据不同的方位以及不同方位上的压力，可以得到二维图像，该二维图像可以表示座椅上的用户的坐姿形状，这样，车辆在判定座椅上的用户的坐姿形状对应的二维图像，与预设坐姿形状对应的二维图像之间的相似度小于设定的阈值的情况下，从而验证用户的身份为未通过。
[0096]
例如，若预设的坐姿形状对应的二维图像，与多个传感器获取的用户的坐姿形状对应的二维图像之间的相似度为80％，设定的阈值为90％，由于80％《90％，因此，验证用户的身份为未通过。
[0097]
可以理解的是，结合图2，本技术实施例的s301可以由图2所示的座椅传感器和预处理模块来执行，s302可以由图2所示的验证模块来执行。
[0098]
综上所述，在本技术实施例中，利用设置于车辆座椅的压力传感器获取用户特征信息，进一步地，根据用户特征信息验证用户的身份，由于压力传感器是车辆座椅中普遍具备的，因而基于压力传感器获取的用户特征信息对用户的身份进行验证时，既可以节省验证成本，又可以避免盗用或误用情况的发生，从而有效地避免安全风险和隐私泄露风险。
[0099]
在图3对应的实施例的基础上，示例性的，图4为本技术实施例提供的一种用户身份验证方法的流程示意图，可以包括以下步骤：
[0100]
s401：利用设置于车辆座椅的压力传感器获取用户特征信息。
[0101]
本技术实施例中，在车辆座椅中的压力传感器为一个的情况下，用户特征信息可以包括压力值或体重值等；可以理解，用户特征信息的具体内容也可以根据实际应用场景设定。
[0102]
适应地，利用设置于车辆座椅的压力传感器获取用户特征信息，包括以下可能的实现方式：
[0103]
一种可能的实现方式中，在用户特征信息包括压力值时，利用设置于车辆座椅的压力传感器获取压力值。
[0104]
示例性的，当用户坐在座椅上，座椅中的压力传感器感受到压力信号，压力传感器将压力信号进行转换后，可以得到压力信号对应的电压，基于电压和压力值的对应关系，从而得到用户对座椅的压力值。例如，电压和压力值之间的对应关系可以通过以下公式来表示，公式为：压力值＝第一系数*电压的乘积+第二系数。
[0105]
可以理解，第一系数的具体值、第二系数的具体值以及电压和压力值之间具体的对应关系，可以根据实际应用场景设定，本技术实施例不作具体限定；利用设置于车辆座椅的压力传感器获取压力值的实现方式，也可以根据实际应用场景设定。
[0106]
另一种可能的实现方式中，在用户特征信息包括体重值时，利用设置于车辆座椅的压力传感器获取体重值。
[0107]
示例性的，压力传感器可以基于压力值得到体重值，压力传感器得到压力值的实现方式可以参考上述步骤的描述，在此不赘述；当压力传感器得到压力值后，基于压力值与
体重值之间的对应关系，可以得到用户的体重值。例如，在压力值为200n时，体重值为54千克。可以理解，压力值与体重值之间具体的对应关系可以根据实际应用场景设定，本技术不作具体限定；利用设置于车辆座椅的压力传感器获取体重值的实现方式，也可以根据实际应用场景设定。
[0108]
本技术实施例中，在车辆座椅中的压力传感器为多个的情况下，基于s302的描述，用户特征信息可以包括用户在座椅上的受力面积，可以理解，用户特征信息的具体内容也可以根据实际应用场景设定。
[0109]
适应地，利用设置于车辆座椅的压力传感器获取用户在座椅上的受力面积，可能的实现方式为：由于多个压力传感器分布在座椅的受力表面，当用户坐在座椅上，座椅中的多个压力传感器基于用户对座椅的不同方位上的挤压效果，可以得到不同方位上的压力值，因此，根据不同的方位以及不同方位上的压力值，可以得到二维图像，进而，根据该二维图像可以得到用户在座椅上的受力面积。可以理解，利用设置于车辆座椅的压力传感器获取用户在座椅上的受力面积的实现方式，也可以根据实际应用场景设定。
[0110]
需要说明的是，在座椅中的压力传感器为多个时，所获取的用户特征信息也可以包括压力值或体重值等，一个压力传感器获取的压力值或体重值的实现方式可以参考前述步骤的描述，在此不再赘述；这样，所获取的压力值或体重值可以为多个压力传感器所获取的压力值或体重值进行函数运算后得到的，该函数可以包括平均函数、最大值函数、中位值函数或加权求和函数等；可以理解，函数的具体内容也可以根据适应应用场景设定。
[0111]
s402：根据用户特征信息验证用户的身份。
[0112]
本技术实施例中，在用户特征信息包括压力值或体重值的情况下，可以根据压力值或体重值，以及预先获取的用户的体重相关信息，验证用户的身份。其中，预先获取的用户的体重相关信息可以是用户手动输入并存储在车辆中的信息，也可以是根据实际应用场景，通过其他方式存储在车辆中的信息，本技术实施例不作限定。
[0113]
适应地，在用户特征信息包括压力值的情况下，根据压力值以及预先获取的用户的体重相关信息，验证用户的身份，可以包括以下可能的实现方式：
[0114]
一种可能的实现方式中，在压力值与预先获取的用户的体重相关信息的差值小于或等于第一阈值的情况下，验证用户的身份为通过。其中，预先获取的用户的体重相关信息包括压力值等。
[0115]
示例性的，用户通过车钥匙或手机的方式打开座舱，车辆可以对比之前使用该车钥匙或手机打开座舱的用户记录，确定用户并预先获取车辆中存储的用户对座椅的压力值，在车辆判定预先获取的用户对座椅的压力值与压力传感器获得的压力值之间的差值小于或等于第一阈值的情况下，例如，预先获取的用户对座椅的压力值与压力传感器获得的压力值之间的差值为40n，第一阈值为55n，由于40《55，从而验证用户的身份为通过。可以理解，第一阈值的具体值，可以根据实际应用场景设定。
[0116]
又一种可能的实现方式中，在压力值没有对应预先获取的用户的体重相关信息的情况下，验证用户的身份为通过。其中，预先获取的用户的体重相关信息没有包括压力值。
[0117]
示例性的，由于预先获取的用户的体重相关信息没有包括压力值，因而压力传感器获取的压力值无法与预先获取的用户的体重相关信息进行比较，因此，验证用户的身份为通过。
[0118]
再一种可能的实现方式中，在压力值与预先获取的用户的体重相关信息的差值大于第一阈值的情况下，验证用户的身份为未通过。其中，预先获取的用户的体重相关信息包括压力值等。
[0119]
示例性的，用户通过车钥匙或手机的方式打开座舱，车辆可以对比之前使用该车钥匙或手机打开座舱的用户记录，确定用户并预先获取车辆中存储的用户对座椅的压力值，在车辆判定预先获取的用户对座椅的压力值与压力传感器获得的压力值之间的差值大于第一阈值的情况下，例如，预先获取的用户对座椅的压力值与压力传感器获得的压力值之间的差值为55n，第一阈值为50n，由于55》50，从而验证用户的身份为未通过。可以理解，第一阈值的具体值，可以根据实际应用场景设定，本技术实施例不作具体限定。
[0120]
适应地，在用户特征信息包括体重值的情况下，根据体重值以及预先获取的用户的体重相关信息验证用户的身份的实现方式，与根据压力值以及预先获取的用户的体重相关信息验证用户的身份的实现方式类似，在此不再赘述。可以理解，根据体重值验证用户的身份的实现方式，也可以根据实际应用场景设定。
[0121]
本技术实施例中，在用户特征信息包括用户在座椅上的受力面积的情况下，可以根据用户在座椅上的受力面积以及预先获取的用户的坐姿轮廓信息，验证用户的身份。其中，预先获取的用户的坐姿轮廓信息可以是用户手动输入并存储在车辆中的信息，也可以是采用其他方式存储在车辆中的信息。
[0122]
适应地，根据用户在座椅上的受力面积以及预先获取的用户的坐姿轮廓信息，验证用户的身份，可以包括以下可能的实现方式：
[0123]
一种可能的实现方式中，在用户在座椅上的受力面积与预先获取的用户的坐姿轮廓信息的差异小于或等于第二阈值的情况下，验证用户的身份为通过。其中，预先获取的用户的坐姿轮廓信息包括受力面积等。
[0124]
示例性的，用户通过车钥匙或手机的方式打开座舱，车辆可以对比之前使用该车钥匙或手机打开座舱的用户记录，确定用户并预先获取车辆中存储的该用户在座椅上的受力面积；当用户坐在座椅上，座椅中的多个压力传感器可以得到用户在座椅上的受力面积，车辆在判定预先获取的用户在座椅上的受力面积与多个压力传感器获得的用户在座椅上的受力面积之间的差值小于或等于第二阈值的情况下，例如，预先获取的用户在座椅上的受力面积与压力传感器获得的用户在座椅上的受力面积之间的差值为200平方厘米(cm2)，第二阈值为300cm2，由于200《300，从而验证用户的身份为通过。可以理解，第二阈值的具体值，也可以根据实际应用场景设定。
[0125]
一种可能的实现方式中，在用户在座椅上的受力面积没有对应预先获取的用户的坐姿轮廓信息的情况下，验证用户的身份为通过。其中，预先获取的用户的坐姿轮廓信息没有包括受力面积。
[0126]
示例性的，由于预先获取的用户的坐姿轮廓信息没有包括用户在座椅上的受力面积，因而压力传感器获取的用户在座椅上的受力面积无法与预先获取的用户的坐姿轮廓信息进行比较，因此，验证用户的身份为通过。
[0127]
再一种可能的实现方式中，在用户在座椅上的受力面积与预先获取的用户的坐姿轮廓信息的差异大于第二阈值的情况下，验证用户的身份为未通过。其中，预先获取的用户的坐姿轮廓信息包括用户在座椅上的受力面积等。
[0128]
示例性的，用户通过车钥匙或手机的方式打开座舱，车辆可以对比之前使用该车钥匙或手机打开座舱的用户记录，确定用户并预先获取车辆中存储的该用户在座椅上的受力面积，车辆在判定预先获取的用户在座椅上的受力面积与压力传感器获得的用户在座椅上的受力面积之间的差值大于第二阈值的情况下，例如，预先获取的用户在座椅上的受力面积与压力传感器获得的用户在座椅上的受力面积之间的差值为350cm2，第二阈值为300cm2，由于350》300，从而验证用户的身份为未通过。可以理解，第二阈值的具体值，也可以根据实际应用场景设定。
[0129]
s403：在用户的身份通过验证的情况下，根据车辆中预先设置的用户的配置参数，对车辆进行配置。
[0130]
本技术实施例中，车辆中预先设置的用户的配置参数可以是车辆默认的配置参数，也可以是用户通过手动输入而设置的配置参数，可以理解，车辆中预先设置的用户的配置参数的具体内容，本技术实施例不作限定。
[0131]
示例性的，若车辆中预先设置的用户的配置参数包括座椅的配置参数、后视镜的配置参数或空调的配置参数等，则通过升高座椅、调整后视镜为水平视线或者打开空调等，完成对车辆的配置。
[0132]
可以理解的是，结合图2，本技术实施例的s401可以由图2所示的座椅传感器和预处理模块来执行，s402可以由图2所示的验证模块来执行，s403可以由图2所示的配置模块来执行。
[0133]
需要说明的是，本技术实施例的s403是可选步骤，本技术实施例各步骤之间的先后顺序也可以根据实际应用场景进行调整，本技术实施例对此不作具体限定。
[0134]
综上所述，在本技术实施例中，利用设置于车辆座椅的压力传感器获取用户特征信息，进一步地，根据用户特征信息验证用户的身份，由于压力传感器是车辆座椅中普遍具备的，因而基于压力传感器获取的用户特征信息对用户的身份进行验证，既可以节省验证成本，又可以在用户的身份通过验证的情况下，根据车辆中预先设置的用户的配置参数，对车辆进行配置，预先设置的用户的配置参数符合用户对汽车配置的偏好，这样，可以减少盗用或误用情况的发生，有效地避免安全风险和隐私泄露风险，提高用户对汽车的使用体验。
[0135]
在图3所示的实施例的基础上，示例性的，图5为本技术实施例提供的一种用户身份验证方法的流程示意图，可以包括以下步骤：
[0136]
s501：接收用户的登录操作。
[0137]
本技术实施例中，用户打开车辆座舱，可以理解为，接收了用户的登录操作。具体的，接收用户的登录操作的实现方式包括：
[0138]
一种实现方式中，用户通过车钥匙打开车辆座舱。例如，用户可以通过点击车钥匙上的开启按钮，打开汽车座舱。
[0139]
又一种实现方式中，用户通过手机打开车辆座舱。例如，在手机已安装汽车app的情况下，用户点击汽车app中的选项，例如，开启座舱选项，从而打开汽车座舱。
[0140]
s502：读取用户对应的配置参数。
[0141]
本技术实施例中，用户对应的配置参数可以是用户首次使用车辆时手动录入的配置参数，也可以是用户上次配置车辆时，车辆自动记录的配置参数，本技术实施例不作限定。可以理解，用户对应的配置参数的具体内容，可以根据实际应用场景设定。
[0142]
示例性的，若车辆云端存储了用户对应的配置参数，则在车辆接收了用户的登录操作后，车辆可以从云端读取用户对应的配置参数。可以理解，车辆可以从云端读取用户对应的配置参数的具体实现方式，本技术实施例不作限定。
[0143]
s503：根据用户对应的配置参数对车辆进行配置。
[0144]
示例性的，若配置参数包括空调相关的参数，则配置模块可以通过对空调的温度进行降低或升高，从而实现对车辆的配置。可以理解，用户对应的配置参数的具体内容，也可以根据实际应用场景设定；根据用户对应的配置参数对车辆进行配置的具体实现方式，本技术实施例不作限定。
[0145]
s504：利用设置在车辆座椅中的压力传感器获取用户特征信息。
[0146]
s505：根据用户特征信息验证用户的身份。
[0147]
s506：在用户的身份通过验证的情况下，维持用户对应的配置参数对车辆进行的配置。
[0148]
示例性的，若车辆的当前配置为升高了座椅的高低，在用户的身份未通过验证的情况下，继续维持升高后的座椅高度，至于用户后续是否通过手动操作对车辆进行其他配置，本技术实施例不作限定。
[0149]
s507：在用户的身份未通过验证的情况下，取消用户对应的配置参数对车辆进行的配置。
[0150]
示例性的，若配置模块根据用户对应的配置参数，打开了娱乐系统，那么，在用户的身份未通过验证的情况下，则配置模块关闭娱乐系统。
[0151]
s508：在用户的身份未通过验证的情况下，取消用户对应的配置参数中安全相关的参数对车辆进行的配置。
[0152]
本技术实施例中，安全相关的参数包括座椅相关的配置参数、安全气囊相关的配置参数和/或安全带相关的配置参数；可以理解，安全相关的参数的具体内容，也可以根据实际应用场景设定。
[0153]
一种示例，在用户的身份未通过验证的情况下，取消用户对应的配置参数中座椅相关的配置参数对车辆的配置。例如，配置模块根据用户对应的配置参数，升高了座椅的高度，基于压力传感器获取的用户特征信息进行用户的身份的验证时，在用户的身份未通过验证的情况下，配置模块降低座椅的高度，使得降低后的座椅的高度与配置模块对座椅进行配置前的高度一样。
[0154]
又一种示例，在用户的身份未通过验证的情况下，取消用户对应的配置参数中安全气囊相关的配置参数对车辆的配置。例如，配置模块可以根据安全气囊相关的配置参数，对安全气囊的冲击力进行降低或增加，基于压力传感器获取的用户特征信息进行用户的身份的验证时，在用户的身份未通过验证的情况下，配置模块取消对安全气囊的冲击力的降低或增加，使得取消后的安全气囊的配置与配置模块对安全气囊配置前一样。
[0155]
再一种示例，在用户的身份未通过验证的情况下，取消用户对应的配置参数中安全带相关的配置参数。例如，配置模块根据安全带相关的配置参数，对安全带进行收紧或放松，基于压力传感器获取的用户特征信息进行用户的身份的验证时，在用户的身份未通过验证的情况下，配置模块取消对安全带的收紧或放松，使得取消后的安全带的配置与配置模块对安全带配置前一样。
[0156]
需要说明的是，在用户的身份未通过验证的情况下，可以选择上述所描述的三种示例中的至少一种示例来取消对车辆的配置，本技术实施例对此不作具体限定。
[0157]
本技术实施例中，s504和s505的内容可以参考s401和s402的内容适应描述，与图4所示的实施例不同的是，本技术实施例是在用户的身份未通过验证的情况下，对车辆进行异常处理。
[0158]
可以理解的是，结合图2，本技术实施例的s504可以由图2所示的座椅传感器和预处理模块来执行，s505可以由图2所示的验证模块来执行，s506-s508可以由图2所示的配置模块来执行。
[0159]
需要说明的是，本技术实施例的s501-s503是可选步骤，可以根据实际应用场景设置可选步骤的一个或多个，本技术实施例各步骤之间的先后顺序也可以根据实际应用场景进行调整，本技术实施例对此不作具体限定。
[0160]
综上所述，在本技术实施例中，车辆在接收用户的登录后，可以提前对车辆进行配置，从而减少用户等待配置的时间，这样，在根据压力传感器获取的用户特征信息对用户的身份进行验证时，通过不同的验证结果，选择取消不同的车辆配置，既可以保证用户的安全风险和隐私泄露风险，又可以提高用户的使用体验。
[0161]
在图3所示的实施例的基础上，图6为本技术实施例提供的一种用户身份验证方法的流程示意图，可以包括以下步骤：
[0162]
s601：利用压力传感器在车辆中录入用户特征信息。
[0163]
本技术实施例中，用户特征信息可以包括压力值、体重值或用户的坐姿轮廓信息中的至少一个等，因而，利用压力传感器在车辆中录入用户特征信息的实现方式，与压力传感器获取用户特征信息的实现方式类似，在此不再赘述。可以理解，用户特征信息的具体内容，也可以根据实际应用情况设定。
[0164]
s602：利用设置于车辆座椅的压力传感器获取用户特征信息。
[0165]
s603：根据用户特征信息验证用户的身份。
[0166]
本技术实施例中，s602和s603可以参考s401和s402的内容适应描述，与图4所示的实施例的不同在于，本技术实施例中，用户特征信息是压力传感器获取的。
[0167]
需要说明的是，s601所描述的内容，也可以在s603所描述的内容之后执行。例如，验证模块利用压力传感器获取的用户特征信息进行身份验证时，发现用户特征信息没有对应预先获取的用户的特性信息，这样，在验证后，验证模块可以通知座椅传感器录入用户特征信息并存储在车辆中；或者，在验证后，车辆可以在车载显示屏上发送录入请求，若用户确认录入后，座椅传感器可以录入用户特征信息并存储在车辆中，方便下次使用。
[0168]
需要说明的是，s601所描述的内容，也可以与s603所描述的内容同时执行。例如，验证模块发现用户特征信息没有对应预先获取的用户的特性信息，验证模块可以在验证的同时，通知座椅传感器录入用户特征信息并存储在车辆中，方便下次使用。
[0169]
可以理解的是，结合图2，本技术实施例的s602可以由图2所示的座椅传感器和预处理模块来执行，s603可以由图2所示的验证模块来执行。
[0170]
综上所述，在本技术实施例中，利用压力传感器在车辆中录入用户特征信息以及利用设置于车辆座椅的压力传感器获取用户特征信息，进一步地，根据用户特征信息验证用户的身份时，可以直接将压力传感器获取的用户特征信息与压力传感器录入的用户特征
信息进行比较，可以节省录入成本以及验证成本，又可以避免盗用或误用情况的发生，从而有效地避免安全风险和隐私泄露风险。
[0171]
在图3所示的实施例的基础上，图7为本技术实施例提供的一种用户身份验证方法的流程示意图，可以包括以下步骤：
[0172]
s701：利用设置于车辆座椅的压力传感器获取用户特征信息。
[0173]
s702：根据用户特征信息验证用户的身份。
[0174]
s703：在用户的身份未通过验证的情况下，对车辆进行异常处理。
[0175]
本技术实施例中，在用户的身份未通过验证的情况下，对车辆进行异常处理，可以包括以下可能的实现方式：
[0176]
一种可能的实现方式中，在用户的身份未通过验证的情况下，将车辆的配置恢复为默认配置。例如，若车辆的默认配置为打开娱乐系统或打开空调等，因而，在用户的身份未通过验证时，将车辆配置为打开娱乐系统或打开娱乐系统等。可以理解，车辆的默认配置的具体内容，也可以根据实际应用场景设定。
[0177]
又一种可能的实现方式中，在用户的身份未通过验证的情况下，维持车辆的当前配置，包括以下几种示例：
[0178]
一种示例，若车辆的当前配置与用户打开车辆座舱后的配置一致，在用户的身份未通过验证的情况下，配置模块不对车辆进行任何操作，至于用户后续是否通过手动操作对车辆进行配置，本技术实施例不作限定。
[0179]
又一种示例，若车辆的当前配置是用户通过手动操作执行的，在用户的身份未通过验证的情况下，维持用户通过手动操作对车辆的配置，至于用户后续是否通过手动操作对车辆进行其他配置，本技术实施例不作限定。
[0180]
再一种可能的实现方式中，在用户的身份未通过验证的情况下，根据用户的配置参数中的部分参数，对车辆进行配置；其中，部分参数为用户的配置参数中除安全相关的参数外的其他参数，安全相关的参数包括座椅相关的配置参数、安全气囊相关的配置参数和/或安全带相关的配置参数。可以理解，安全相关的参数的具体内容，也可以根据实际应用场景设定。
[0181]
示例性的，根据用户的配置参数中的部分参数为娱乐系统相关的配置参数，对车辆进行配置。例如，配置模块可以根据娱乐系统相关的配置参数，对当前的娱乐系统的音量进行升高或者降低，从而实现对娱乐系统的个性化配置，由于配置后的娱乐系统的音量符合用户的偏好，因此可以提高用户对汽车的使用体验。可以理解，用户的配置参数中的部分参数的具体内容，也可以根据实际应用场景设定。
[0182]
本技术实施例中，s701和s702的内容可以参考s401和s402的内容适应描述，与图4所示的实施例不同的是，本技术实施例是在用户的身份未通过验证的情况下，对车辆进行异常处理。
[0183]
可以理解的是，结合图2，本技术实施例的s701可以由图2所示的座椅传感器和预处理模块来执行，s702可以由图2所示的验证模块来执行。
[0184]
需要说明的是，本技术实施例的s603是可选步骤，本技术实施例各步骤之间的先后顺序也可以根据实际应用场景进行调整，本技术实施例对此不作具体限定。
[0185]
综上所述，在本技术实施例中，利用设置于车辆座椅的压力传感器获取用户特征
信息，进一步地，根据用户特征信息验证用户的身份，由于压力传感器是车辆座椅中普遍具备的，基于压力传感器获取的用户特征信息对用户的身份进行验证，既可以节省验证成本，又可以减少盗用或误用情况的发生，避免安全风险和隐私泄露风险，同时，又可以在用户的身份未通过验证的情况下，通过不同的配置选择对车辆进行配置，从而提高用户对汽车的使用体验。
[0186]
上面结合图3-图7，对本技术实施例的方法进行了说明，下面对本技术实施例提供的执行上述方法的用户身份验证装置进行描述。本领域技术人员可以理解，方法和装置可以相互结合和引用，本技术实施例提供的一种用户身份验证装置可以执行上述用户身份验证方法。
[0187]
下面以采用对应各个功能划分各个功能模块为例进行说明：
[0188]
示例性的，如图8为本技术实施例提供的一种用户身份验证装置的结构示意图，如图8所示，该装置包括处理器800、存储器801和收发机802。
[0189]
处理器800负责管理总线架构和通常的处理，存储器801可以存储处理器800在执行操作时所使用的数据，收发机802用于在处理器800的控制下接收和发送数据与存储器801进行数据通信。
[0190]
总线架构可以包括任意数量的互联的总线和桥，具体由处理器800代表的一个或多个处理器和存储器801代表的存储器的各种电路链接在一起。总线架构还可以将诸如外围设备、稳压器和功率管理电路等之类的各种其他电路链接在一起，这些都是本领域所公知的，因此，本文不再对其进行进一步描述。总线接口提供接口。处理器800负责管理总线架构和通常的处理，存储器801可以存储处理器800在执行操作时所使用的数据。
[0191]
本技术实施例揭示的流程，可以应用于处理器800中，或者由处理器800实现。在实现过程中，用户身份验证的流程的各步骤可以通过处理器800中的硬件的集成逻辑电路或者软件形式的指令完成。处理器800可以是通用处理器、数字信号处理器、专用集成电路、现场可编程门阵列或者其他可编程逻辑器件、分立门或者晶体管逻辑器件、分立硬件组件，可以实现或者执行本技术实施例中的公开的各方法、步骤及逻辑框图。通用处理器可以是微处理器或者任何常规的处理器等。结合本技术实施例所公开的方法的步骤可以直接体现为硬件处理器执行完成，或者用处理器中的硬件及软件模块组合执行完成。软件模块可以位于随机存储器，闪存、只读存储器，可编程只读存储器或者电可擦写可编程存储器、寄存器等本领域成熟的存储介质中。该存储介质位于存储器801，处理器800读取存储器801中的信息，结合其硬件完成信号处理流程的步骤。
[0192]
本技术实施例一种可选的方式，处理器800用于读取存储器801中的程序并以执行如图3所示的s301和s302中的方法流程。
[0193]
示例性的，图9为本技术实施例提供另一种用户身份验证装置的结构示意图，该装置包括：包括收发模块900和处理模块901。
[0194]
收发模块900，用于支持处理模块901获取与用户身份验证相关的多个信息。
[0195]
处理模块901，用于利用设置于车辆座椅的压力传感器获取用户特征信息；处理模块901，还用于根据用户特征信息验证用户的身份。
[0196]
一种可能的实现方式中，处理模块901，还用于：在用户的身份通过验证的情况下，根据车辆中预先设置的用户的配置参数，对车辆进行配置。
[0197]
一种可能的实现方式中，处理模块901，还用于：接收用户的登录操作；读取用户对应的配置参数；根据用户对应的配置参数对车辆进行配置。
[0198]
一种可能的实现方式中，处理模块901，还用于：在用户的身份通过验证的情况下，维持用户对应的配置参数对车辆进行的配置；或者，在用户的身份未通过验证的情况下，取消用户对应的配置参数对车辆进行的配置；或者，在用户的身份未通过验证的情况下，取消用户对应的配置参数中安全相关的参数对车辆进行的配置；其中，安全相关的参数包括座椅相关的配置参数、安全气囊相关的配置参数和/或安全带相关的配置参数。
[0199]
一种可能的实现方式中，用户特征信息包括压力值或体重值；处理模块901，具体用于：在用户特征信息与预先获取的用户的体重相关信息的差值小于或等于第一阈值的情况下，验证用户的身份为通过；或者，在用户特征信息没有对应预先获取的用户的体重相关信息的情况下，验证用户的身份为通过；或者，在用户特征信息与预先获取的用户的体重相关信息的差值大于第一阈值的情况下，验证用户的身份为未通过。
[0200]
一种可能的实现方式中，压力传感器的数量为多个，用户特征信息为用于描述用户的坐姿轮廓的信息；处理模块901，具体用于：在用户特征信息与预先获取的用户的坐姿轮廓信息的差异小于或等于第二阈值的情况下，验证用户的身份为通过；或者，在用户特征信息没有对应预先获取的用户的坐姿轮廓信息的情况下，验证用户的身份为通过；或者，在用户特征信息与预先获取的用户的坐姿轮廓信息的差异大于第二阈值的情况下，验证用户的身份为未通过。
[0201]
一种可能的实现方式中，处理模块901，还用于：利用压力传感器在车辆中录入用户特征信息。
[0202]
一种可能的实现方式中，处理模块901，还用于：在用户的身份未通过验证的情况下，对车辆进行异常处理。
[0203]
一种可能的实现方式中，处理模块901，具体用于：将车辆的配置恢复为默认配置；或者，维持车辆的当前配置；或者，根据用户的配置参数中的部分参数，对车辆进行配置；其中，部分参数为用户的配置参数中除安全相关的参数外的其他参数，安全相关的参数包括座椅相关的配置参数、安全气囊相关的配置参数和/或安全带相关的配置参数。
[0204]
示例性的，图10为本技术实施例提供的一种芯片的结构示意图。芯片100包括一个或两个以上(包括两个)处理器1010和通信接口1030。
[0205]
在一些实施方式中，存储器1040存储了如下的元素：可执行模块或者数据结构，或者他们的子集，或者他们的扩展集。
[0206]
本技术实施例中，存储器1040可以包括只读存储器和随机存取存储器，并向处理器1010提供指令和数据。存储器1040的一部分还可以包括非易失性随机存取存储器(non-volatile random access memory，nvram)。
[0207]
本技术实施例中，存储器1040、通信接口1030以及存储器1040通过总线系统1020耦合在一起。其中，总线系统1020除包括数据总线之外，还可以包括电源总线、控制总线和状态信号总线等。为了便于描述，在图10中将各种总线都标为总线系统1020。
[0208]
上述本技术实施例描述的方法可以应用于处理器1010中，或者由处理器1010实现。处理器1010可能是一种集成电路芯片，具有信号的处理能力。在实现过程中，上述方法的各步骤可以通过处理器1010中的硬件的集成逻辑电路或者软件形式的指令完成。上述的
处理器1010可以是通用处理器(例如，微处理器或常规处理器)、数字信号处理器(digital signal processing，dsp)、专用集成电路(application specific integrated circuit，asic)、现成可编程门阵列(field-programmable gate array，fpga)或者其他可编程逻辑器件、分立门、晶体管逻辑器件或分立硬件组件，处理器1010可以实现或者执行本发明实施例中的公开的各方法、步骤及逻辑框图。
[0209]
结合本技术实施例所公开的方法的步骤可以直接体现为硬件译码处理器执行完成，或者用译码处理器中的硬件及软件模块组合执行完成。其中，软件模块可以位于随机存储器、只读存储器、可编程只读存储器或带电可擦写可编程存储器(electrically erasable programmable read only memory，eeprom)等本领域成熟的存储介质中。该存储介质位于存储器1040，处理器1010读取存储器1040中的信息，结合其硬件完成上述方法的步骤。
[0210]
示例性的，图11为本技术实施例提供的一种车辆1100的结构示意图，该车辆包括压力传感器1101，至少一个存储器1102，至少一个收发器1103以及至少一个处理器1104。
[0211]
压力传感器1101，用于获取用户特征信息。
[0212]
存储器1102，用于存储一个或多个程序以及数据信息；其中，一个或多个程序包括指令。
[0213]
收发器1103，用于与车辆中的通讯设备进行数据传输，以及用于与云端进行数据传输。
[0214]
处理器1104，用于利用设置于车辆座椅的压力传感器获取用户特征信息；处理模块901，还用于根据用户特征信息验证用户的身份。
[0215]
在一些可能的实施方式中，本技术实施例提供的用户身份验证的方法的各个方面还可以实现为一种程序产品的形式，其包括程序代码，当程序代码在计算机设备上运行时，程序代码用于使计算机设备执行本说明书中描述的根据本技术各种示例性实施方式的用户身份验证方法中的步骤。
[0216]
程序产品可以采用一个或多个可读介质的任意组合；其中，可读介质可以是可读信号介质或者可读存储介质，可读存储介质包括但不限于：电、磁、光、电磁、红外线、或半导体的系统、装置或器件，或者任意以上的组合。可读存储介质的更具体的例子(非穷举的列表)包括：具有一个或多个导线的电连接、便携式盘、硬盘、随机存取存储器(random access memory，ram)、只读存储器(read-only memory，rom)、可擦除可编程只读存储器(erasable programmable read-only memory，eprom)、光纤、紧凑型光盘只读储存器(compact disc read-only memory，cd-rom)、光存储器件、磁存储器件、或者上述的任意合适的组合。
[0217]
根据本技术的实施方式的用于用户身份验证的程序产品，其可以采用cd-rom，并可以包括程序代码，并可以在服务器设备上运行。然而，本技术的程序产品不限于此，在本文件中，可读存储介质可以是任何包含或存储程序的有形介质，该程序可以被通信传输、装置或者器件使用或者与其结合使用。
[0218]
可读信号介质可以包括在基带中或者作为载波一部分传播的数据信号，其中承载了可读程序代码。这种传播的数据信号可以采用多种形式，包括但不限于：电磁信号、光信号或上述的任意合适的组合。可读信号介质还可以是可读存储介质以外的任何可读介质，该可读介质可以发送、传播或者传输用于由周期网络动作系统、装置或者器件使用或者与
其结合使用的程序。
[0219]
可读介质上包含的程序代码可以用任何适当的介质传输，包括但不限于：无线、有线或光缆等，或者上述的任意合适的组合。
[0220]
可以以一种或多种程序设计语言的任意组合来编写用于执行本技术操作的程序代码，程序设计语言包括面向对象的程序设计语言，例如，java或c++等，还包括常规的过程式程序设计语言，例如，c语言或类似的程序设计语言。程序代码可以完全地在用户计算设备上执行、部分地在用户设备上执行、作为一个独立的软件包执行、部分在用户计算设备上部分在远程计算设备上执行、或者完全在远程计算设备或服务器上执行。在涉及远程计算设备的情形中，远程计算设备可以通过任意种类的网络连接到用户计算设备，或者，可以连接到外部计算设备；其中，网络可以包括局域网(local area network，lan)或广域网(wide area network，wan)等。
[0221]
本技术实施例针对用户身份验证的方法还提供一种计算设备可读存储介质，即断电后内容不丢失。该存储介质中存储软件程序，包括程序代码，当程序代码在计算设备上运行时，该软件程序在被一个或多个处理器读取并执行时可实现本技术实施例上面任何一种用户身份验证的方案。
[0222]
本技术实施例还提供一种电子设备，在采用对应各个功能划分各个功能模块的情况下，该电子设备包括：处理模块，用于支持用户身份验证装置执行上述实施例中的步骤，例如，可以执行s301和s302的操作，或者本技术实施例所描述的技术的其他过程。
[0223]
其中，上述方法实施例涉及的各步骤的所有相关内容均可以援引到对应功能模块的功能描述，在此不再赘述。
[0224]
当然，用户身份验证装置包括但不限于上述所列举的单元模块。并且，上述功能单元的具体所能够实现的功能也包括但不限于上述实例所述的方法步骤对应的功能，电子设备的其他单元的详细描述可以参考其所对应方法步骤的详细描述，本技术实施例在此不予赘述。
[0225]
在采用集成的单元的情况下，上述实施例中所涉及的电子设备可以包括：处理模块、存储模块和通信模块。其中，存储模块，用于保存电子设备的程序代码和数据，通信模块用于支持电子设备与其他网络实体的通信，以实现电子设备的通话或数据交互等功能。
[0226]
其中，处理模块用于对电子设备的动作进行控制管理。例如，处理模块可以是处理器或控制器，通信模块可以是收发器或通信接口等，存储模块可以是存储器。
[0227]
进一步的，该电子设备还可以包括输入模块和显示模块。例如，显示模块可以是屏幕或显示器，输入模块可以是触摸屏，语音输入装置，或指纹传感器等。
[0228]
以上可以参照示出的方法、装置(系统)和/或计算机程序产品的框图和/或流程图描述本技术。应理解，可以通过计算机程序指令来实现框图和/或流程图示图的一个块以及框图和/或流程图示图的块的组合，可以将这些计算机程序指令提供给通用计算机、专用计算机的处理器和/或其它可编程数据处理装置，以产生机器，使得经由计算机处理器和/或其它可编程数据处理装置执行的指令可以创建用于实现框图和/或流程图块中所指定的功能/动作的方法。
[0229]
相应地，还可以用硬件和/或软件(包括固件、驻留软件或微码等)来实施本技术。更进一步地，本技术可以采取计算机可使用或计算机可读存储介质上的计算机程序产品的
形式，其具有在介质中实现的计算机可使用或计算机可读程序代码，以由指令执行系统来使用或结合指令执行系统而使用。在本技术上下文中，计算机可使用或计算机可读介质可以是任意介质，其可以包含、存储、通信、传输或传送程序等，以由指令执行系统、装置或设备使用，或结合指令执行系统、装置或设备使用。
[0230]
本技术结合多个流程图详细描述了多个实施例，但应理解，这些流程图及其相应的实施例的相关描述仅为便于理解而示例，不应对本技术构成任何限定。
[0231]
本技术描述的多个实施例之间可以任意组合或步骤之间相互交叉执行，各个实施例的执行顺序和各个实施例的步骤之间的执行顺序均不是固定不变的，也不限于图中所示，各个实施例的执行顺序和各个实施例的各个步骤的交叉执行顺序应以其功能和内在逻辑确定。
[0232]
尽管结合具体特征及其实施例对本技术进行了描述，显而易见的，在不脱离本技术的精神和范围的情况下，可对其进行各种修改和组合。相应地，本说明书和附图仅仅是所附权利要求所界定的本技术的示例性说明，且视为已覆盖本技术范围内的任意和所有修改、变化、组合或等同物。显然，本领域的技术人员可以对本技术进行各种改动和变型而不脱离本技术的范围。这样，倘若本技术的这些修改和变型属于本技术权利要求及其等同技术的范围之内，则本技术也意图包括这些改动和变型在内。