CN113409777A - 一种记录用户关注点的方法、车载主机及车辆 - Google Patents

Abstract

本发明的实施例提供一种记录用户关注点的方法、车载主机和车辆。本发明的方法在车载主机上执行，包括：检测车载主机采集的音频中是否包含预置的多个触发词中的一个；响应于检测到的所述多个触发词中的一个，判断所述多个触发词中的一个是否为第二触发词；若是第二触发词，则生成用于记录用户关注点的触发记录并不执行其他操作。本发明的方法在采集时可以无需网络连接，并在有网络连接的时候可将该触发记录发送至云端存储。本发明提供的车载主机可执行本发明提供的方法，本发明提供的车辆设置有本发明提供的车载主机。基于本发明的方式，能够以简单高效的方式实现离线记录用户关注点，为更精准描绘用户画像提供更为准确的数据。

Description

一种记录用户关注点的方法、车载主机及车辆

技术领域

本发明总体涉及大数据领域，并且更具体地，涉及一种大数据采集汇总处理的方法。

背景技术

在车联网中，为了更好的服务用户，通常需要给用户画像，从而能够更为精准的提供用户需要的对应内容。

传统的用户画像只能在车载主机注册用户时获得用户的注册信息，以及用户使用车载主机时的部分应用数据，这就导致用户画像的缺失不够精准的问题。

另一方面，很多时候需要用户主动输入数据，这就带来很多多余的操作，人机交互步骤过多，非常浪费时间。

因此，提供一种能够即精准，又减少用户介入的收集用户关注内容从而给用户画像的方法就显得尤为重要了。

发明内容

本发明的实施例提供了监听触发词，获取关注点数据的方法。基于本发明的方式，能够以简单高效的方式实现离线记录用户关注点，从而更精准描绘用户画像。

在本发明的第一方面中，提供了记录用户关注点的方法，在本地端执行，包括：检测本地采集的音频中是否包含预置的触发词；响应于检测到的所述触发词，判断所述触发词是否为第二触发词；若是第二触发词，生成一条触发记录并不启动语音交互。

在本发明的第二方面中，提供了一种车载主机，包括：至少一个处理单元；以及与至少一个处理单元耦合的存储器，存储器包含有存储于其中的指令，指令在被至少一个处理单元执行时，使得设备执行根据第一方面的方法的步骤。

在本发明的第三方面中，提供了一种车辆，搭载有根据第二方面实现的车载主机。

提供发明内容部分是为了以简化的形式来介绍本发明的概念，它们在下文的具体实施方式中将被进一步描述。发明内容部分无意标识本发明的关键特征或主要特征，也无意限制本发明的范围。

附图说明

通过结合附图对本发明示例性实施例进行更详细的描述，本发明的上述以及其它目的、特征和优势将变得更加明显，其中，在本发明示例性实施例中，相同的参考标号通常代表相同部件。

图1示出了能够实施本发明的一个实施例的场景的示意图；

图2示出了根据本发明的一个实施例的方法的流程图；

图3示出了根据本发明的一个实施例生成的多条触发记录的示意图；

图4示出了根据本发明的一个实施例的多个第二触发词属性关联不同应用的示意图；

图5示出了能够实施本发明的一个实施例的设备的示意性框图。

具体实施方式

下面将参考附图中示出的若干示例实施例来描述本发明的原理。虽然附图中显示了本发明的优选实施例，但应当理解，描述这些实施例仅是为了使本领域技术人员能够更好地理解进而实现本发明，而并非以任何方式限制本发明的范围。

在本文中使用的术语“包括”及其变形表示开放性包括，即“包括但不限于”。除非特别申明，术语“或”表示“和/或”。术语“基于”表示“至少部分地基于”。术语“一个示例实施例”和“一个实施例”表示“至少一个示例实施例”。术语“另一实施例”表示“至少一个另外的实施例”。术语“第一”、“第二”等等可以指代不同的或相同的对象。下文还可能包括其他明确的和隐含的定义。

如前所述，传统的用户画像所能得到的用户数据有着很大的局限性，为了获得精准的数据，很多厂商会进行针对性产品调研，这就导致了高昂的人力成本，并且需要用户深度参与，不利用大范围推广调研，这就不利于高效的且低成本的用户画像的需求。

为了至少部分地解决上述问题以及其他潜在问题中的一个或者多个，本发明的实施例提出了一种记录用户关注点的方法，该方法能够通过监听触发词来实现，具体地，在本地端执行，包括：检测本地采集的音频中是否包含预置的触发词；响应于检测到的所述触发词，判断所述触发词是否为第二触发词；若是第二触发词，生成用于记录用户关注点的触发记录并不执行其他操作，也就是说，仅本地后台生成触发记录，本地前端用户是无感知的，因为并没有执行其他用户可感知的操作，具体来说，生成用于记录用户关注点的触发记录就是将检测到的具体的触发词记录下来，其中，该具体的触发词是第二触发词，在下文中，将用第二触发词来描述采集到的触发词是第二触发词的这种情况，本领域技术人员可以举一反三，这样的描述是为了减少拗口语音的晦涩，旨在说明本发明的关键点：响应于检测到的所述触发词，判断所述触发词是否为第二触发词；若是第二触发词，生成用于记录用户关注点的触发记录并不执行其他操作。以此方式，厂商只需要将事先需要调研的关键信息中的关键词整理并预置作为第二触发词，从而利用本地触发来记录用户语音中涉及厂商所需关键词的次数，得到用户关注点数据信息，在又一个实施例中，对于每一次基于第二触发词的本地触发都可以对应的将该具体第二触发词的触发次数累计计数加一，每一次基于第二触发词的响应仅执行上述的计数加一操作，而不执行语音响应，从而实现静默式的记录，不会影响用户的操作体验。

具体的，生成的一条触发记录可以本地存储。而在又一个实施例中，也可以是直接上传至云端。

本领域技术人员理解，由于车内环境背景噪音相对较低，语音交互的应用效果可以在此处得到最大程度地展现，因此车内通过语音触发，随后开始语音交互是普遍采用的人机交互方式。本发明即利用触发词监听的功能，尤其是利用无关云端的在本地端执行监听触发词功能，从而实现能够第一时间响应，快速完成收集工作，在此过程中，无需云端参与，执行效率能得到较大的保证。换一句话说，该第二触发词，是预设的用于记录被触发次数的关键词。

在一个优选例中，本地端在加载系统后，即获取麦克风权限，启动所述检测本地采集的音频中是否包含预置的触发词的步骤。这么做的目的是为了能够全程记录触发次数，从而得到更精准的数据信息。

在又一个实施例中，在执行本发明的过程中，还包括：响应于检测到的所述触发词，判断所述触发词是否为第一触发词；若是第一触发词，则启动语音交互。在本实施例中，该第一触发词为预设语音交互触发词。本领域技术人员理解，由于第一触发词承担了启动语音交互入口的作用，厂商存在较大的动力提高第一触发词的触发准确率，因此，在一些案例中，会在设置第一触发词时，往往会适当提高语音识别系统对第一触发词的敏感度。

因此，在一个优选例中，为了避免采集到的数据失真，应该避免第二触发词和第一触发词之间的存在发音近似问题。例如，所设置的第二触发词与第一触发词近音，导致语音识别系统将麦克风实际采集的语音内容识别为第一触发词，从而导致根据本发明的方法采集到的第二触发词的触发次数少于实际用户语音提及第二触发词的次数。这样的近音词可以举例包括：前鼻音和后鼻音，不同声调等情况，具体的比如第一触发词“你好擎感”，第二触发词“您好青港”，近音词的判断选择是现有技术，在此不予赘述。考虑到第一触发词的设置往往是和设备的品牌以及型号是绑定的，即特定的品牌或型号产品往往对应了特定的第一触发词，为了避免第二触发词和第一触发词之间的发音近似问题，需要锁定第一触发词而调整第二触发词。

进一步的，需要重新设置第一触发词甚至屏蔽第一触发词，本领域技术人员可以根据需要来决定，在此不与赘述。

在又一个实施例中，本发明的触发词还包含了第三触发词，该第三触发词可以是预置的多个对应不同操作指令的关键词短语，包括诸如：“打开车窗”，“熄火”，“打开空调”等等用于直接执行操作指令的语音口令，也即基于本发明的第三触发词，无需预先启动语音交互，而是直接基本本地预置的指令，在车载主机本地端直接基于采集到的第三触发词来响应执行操作，用户体验较快。

如上已经初步对本发明的主要内容作了说明，为了能更好的解释本发明的精妙之处，下面将结合图1-图5对本发明的多个不同实施例进行详细描述。

首先参照图1，图1示出了能够实施本发明的一个实施例的场景100的示意图。车辆110内部场景100包括车载主机112、云端140以及用户130和190，用户日常说话中包括第一触发词120和第二触发词180。

在图1中，车载主机112可以接收来自云端140的信息，也可将本地信息数据上传至云端140。这种信息例如可以是与第二触发词180相关的信息。在图1中，可以是用户130和190之间有对话，也可以是用户130或190单独说话，虽然图1中的场景100尤其适合发生于汽车座舱内，但不应理解为语音来源仅限于车内用户130和190，考虑到车内作为封闭环境，拥有背景噪音较低的优势，本发明所应用的场景能够获得更为优质的收音效果。但同时，车外语音来源(未示出)中带有第一触发词120和第二触发词180亦可被麦克风(未标示)收录，例如和用户130通过电话沟通的车外用户的语音内容通过话筒传递到车内，本领域技术人员理解，对于无声纹识别的语音识别系统而言，来自用户130的语音和来自话筒的语音是等效的。

如图所示，车载主机112通过网络连接到云端140，云端140不应该被视为一个或多个具体的设备，而是可以理解为位于远端提供后台计算能力的服务器和/服务器群组，亦可以是运行于某一台物理服务器中逻辑容器的程序，此时，车载主机112可以从云端140获取第二触发词，本领域技术人理解，车载主机112还可以被配置为从其他终端(未示出)：如手机、PAD等设备直接通过近场通信获取信息：如第二触发词180。在一些实施例中，车辆110中还可以包括用于采集与车辆110相关的状态信号的传感器组(未示出)。

第一触发词120被配置为语音交互触发词，本领域技术人员理解，第一触发词120与第二触发词180为非近音词，由于第一触发词120的设置是现有技术，且本发明的方法在监听到第一触发词120后所执行的流程也是现有技术，因此，关于第一触发词120的设置和监听后的执行流程在此不予赘述。

以下结合参考图1和图2来阐述本发明的主要方法流程。其中，图2示出了根据本发明的一个实施例的方法200的流程图。方法200由图1中的车载主机112来执行，以下对方法200的描述不应被理解为对本发明所做出的的限制，方法200还可以包括未示出的其他附加动作和/或可以省略所示出的动作。在本实施例中，生成一条记录具体采用的是在一个关注点数据表中进行记录具体内容。

在一个实施例中，首先执行步骤201，本地监听触发词，本领域技术人员理解，监听不仅仅是针对本发明所述的触发词，而是监听所有音频输入内容，根据本地预置的触发词规则，来匹配对应的音频输入内容，在一个实施例中，触发词的监听不涉及语义理解，不需网络后台分析系统参与，只要本地执行即可实现。而本步骤中所说的本地监听，就是利用现有技术中离线监听本地唤醒词的技术，无需将音频内容上传到云端处理，直接本地比对即可实现。

随后分别根据监听到的内容，执行以下不同的步骤，其中，若监听到第一触发词120，则执行步骤202，启动语音交互；若监听到第二触发词，即判断所述多个触发词中的一个是否为第二触发词；若是第二触发词，则则执行步骤203，生成用于记录用户关注点的触发记录并不执行其他操作。具体而言，在监听到第一触发词120并执行步骤202启动语音交互，以及之后的语音交互过程，是现有技术所广泛实施的，不是本发明的重点，所以在此不予赘述。但是图2作为简要示意图并未显示出步骤202后的逻辑关系，即在步骤202后，在本发明执行语音交互的过程中，还会继续执行步骤201，监听触发词，从而实现本发明的采集功能不会因为语音交互过程而中断。本领域技术人员理解，这能最大化的保证本发明所采集数据的准确性。

相对的，在执行步骤201中，如果监听到的是第二触发词180，则执行步骤203，静默式记录到本地创建的关注点数据表中。由于第二触发词180所设置的目的不是用作启动语音交互的口令，而第一触发词120也往往会有单独的记录存储次数需求，因此需要将不同的触发词进行隔离，所以，为了避免用户使用过程中的混淆，需要限制用户修改第一触发词120的权限。优选地，第一触发词120的设置权限仅由预设实现，在又一个实施例中，第一触发词120的设置可以通过后续更细迭代来修改。进一步地，在一个优选实施例中，第二触发词180可以由用户自行添加，利用用户需要分析车内环境词频，可以自由添加其所需要的第二触发词180，本领域技术人员可以根据需要来确定第二触发词180的用词可选池以避免用户设定的第二触发词180和第一触发词120相冲突。通过将第二触发词180和第一触发词120严格区分设置，本发明只需要利用本地监听模块即可保证本发明优势之一——及时性。

在执行本发明的过程中，为了能够最大化的采集到车内所能采集的数据，本发明的方法可以在车载主机112加载系统时，即获取麦克风权限，启动监听。考虑到车载主机112的供电能耗在车辆110中占比很小，因此，开机启动监听是易于接受的，由于当下处理单元性能的提升，后台运行监听并不会影响车载主机112的运行顺畅度。当然，在另一个实施例中，监听模块也可以是根据响应用户的指令或其他设备的指令而启动。

在一个优选实施例中，第一触发词120为厂商预设的语音交互触发词，例如现有技术中常见的“HEY,SIRI”，“小度小度”，“你好擎感”，“小爱同学”诸如此类等等，值得注意的是第一触发词120的设定应该避免生活常见词组，同时考虑到为了避免频繁错误触发以及用户的真实触发需求，语音触发词的词组长度应当适中，大量的调研及用户反馈显示，两至四个短音词组是适合的。

进一步地，第二触发词180为预设用户关注点关键词，具体而言，就是第二触发词180的作用是用于假定预测用户关注点，通过预设多个不同的第二触发词180关键词内容，来实现对不同关注点关键词的采集。

在一个具体实施例中，在执行步骤203后，还包括可以根据网络连通的情况以将关注点数据表及时上传到云端140以供调用，通常可以开放API接口给第三方分析平台获取数据从而实现信息的分析功能。在又一个实施例中，是直接将生成的记录发送至云端，本地仅缓存，无本地存储，更加高效。通过本发明所采集的数据，无疑更为真实有效，并且针对性更高。

以下再结合图3和图4，来举例说明第二触发词180的设置与采集。具体地，图3示出了根据本发明的实施例生成的多条记录的示意图，更为具体的，本领域技术人员可以用表单的形式来记录，表单至少包括监听项，记录监听到第二触发词的内容；时间项，记录监听到第二触发词的时间；位置项，记录实时GPS位置；车辆规范数据项，记录实时车辆规范数据。图3中的示例中所截取的是将“医生”，“肿瘤”，“医院”，“预约”，“手术”，“康复”等词组设置为第二触发词180的记录的片段，参见该表中，位置信息没有获取成功，可能是所处位置为地下等无信息位置，由此可见本发明可在无信息区域记录采集信息，而每个关键词所监听到的时间都根据指定格式做了记录，2020年1月2日上午10点03分至07分这段时间内总计采集到7次第二触发词180内容，并且图3的实施例中，记录了车载主机112的型号为ACV-9，用户信息为未登录状态，导航目的地的XX医院，结合图2和图3可知，监听项的内容是厂商预设的，而时间项，位置项，车辆规范数据项的内容均为车载主机112根据程序执行自动生成的信息。而且，图3实施例中的第二触发词180均为双字词组，可见不同于第一触发词120，由于针对第二触发词180仅执行静默式的记录，完全可以采用较短的词条长度，不用担心类似第一触发词120因为过短易触发而引起的频繁触发，因第二触发词180的词条长度过短所导致的存在可能过度监听的可能性在一定程度上可以接受的。

图3中的示例是一个优选实施例，在不同实施情况下，生成用于记录用户关注点的触发记录并不启动语音交互的步骤包括如下步骤其中之一也可：记录内容，用于指示检测到的第二触发词的内容；记录时间，用于指示检测到的第二触发词的时间；记录位置，用于指示检测到第二触发词时的GPS位置；或记录车辆规范数据，用于指示检测到第二触发词时的车辆规范数据；所述车辆规范数据中至少包括如下中至少一项：车载主机型号，用户账户信息，导航应用数据，娱乐应用数据，行车状态数据，车身传感器数据。具体执行哪一个或几个记录步骤可以根据实际需求调整。

通过本发明生成的记录，将一段时间内所有的监听记录导出即可得到各个不同的第二触发词180的触发频度，例如，图3中的所展示的4分钟不到时间内，“手术”这一第二触发词180被触发2词，其他6项第二触发词180各被触发1次。本领域技术人员理解，图3仅作为示例为公众描绘了部分记录的例子，在实际案例中，更大量的数据记录结果可以找到部分第二触发词180更多的触发次数。图3的实施例中所展示的辆规范数据包括车载主机112型号，用户账户信息，导航应用数据这三项数据信息。通常，有了用户账户信息数据，可以更好的针对具体用户进行分析画像，从而脱离具体车载主机112，而是与用户身份所绑定，使得后续根据用户画像而进行的信息推送可以依托用户账户信息本身而不是特定局限于的某一台车载主机。在一个优选例中，可以包括用户账户信息，车载主机112型号，车载主机112的唯一激活认证码，从而实现更准确的身份确认。

以下再结合图4，来说明第二触发词180的不同设置所带来的不同影响。在一个实施例中，第二触发词180选取与车内场景100具有较高相关度的关键词，例如，“加油”，“吃饭”，“医院”，“电影”等词语车内场景100强相关，这些关键词的属性分类包括兴趣点，车主消费，出行服务。在预设第二触发词180时，管理人员可同时选择确定第二触发词180的关键词内容的对应关键词属性，而可选的关键词属性与车载主机内的应用程序之间都设置有对应的应用映射关系，本领域技术人员理解，在设置类似车内场景100强相关关键词为第二触发词180时，可以适当减少记录项，例如记录中的车辆规范数据项仅包含车身传感器数据，不包含导航应用数据，娱乐应用数据，行车状态数据等，以压缩类似实质上的冗余数据。图4所示的实施例示例性的举例了一种单一的映射关系，根据实际的数据采集准确度的需求，本领域技术人员可以采用一对多或者多对多的属性-应用关系，在此不予赘述。

在另一个实施例中，如果本地端存储资源丰富，也可以同时记录导航应用数据，娱乐应用数据，行车状态数据等，以作为信息二次确认，形成相互印证，保证数据的准确度。本领域技术人员可以根据实际需要采取不同的方案。

当然，在很多时候，第二触发词180往往是与车内场景100完全无关的内容，例如“做公益”，“捐献”，“血型”，“大脑”等等诸如此类，在这种情况下，如果能够将更多的车辆规范数据项一并记录，则可以更好的从广度上完善数据的互补性，利用第二触发词180的内容和对应的多项车辆规范数据项来描绘出关键词被触发时的场景。在一个具体实施例中，车辆规范数据项可以包括多个车身传感器数据，例如座椅状态，门窗状态，温度气压数据等，本领域技术人员理解，本发明所例举的车载主机型号，用户账户信息，导航应用数据，娱乐应用数据，行车状态数据，车身传感器数据仅是用作示例参考，根据具体的实际需求，可以将其他不同的车辆规范数据一并记录，在此不一一举例。

在又一个优选地中，本发明车载主机112还执行更换第二触发词180的步骤，具体的，在与云端140通信的过程中，从云端获取新关键词内容以对本地的第二触发词进行迭代更新。通常，根据每次记录用户关注点的需求，在本地可以设置数十个，数百个乃至更多的第二关键词180，当收集需求发生变更时，就可以在后台管理系统(本发明中未示出)上传需要的至少一个第二触发词180至云端，在车载主机112访问云端140或云端140主动下发数据给车载主机112时，可以将云端140的至少一个第二触发词180传输到车载主机112，用以进行车载主机112本地的第二触发词180的替换或增量更新。

继续参照图5，图5示出了能够实施本发明的实施例的设备500的示意性框图。例如，如图1所示的车载主机112可以由设备500来实施。如图所示，设备500包括中央处理单元(CPU)501，其可以根据存储在只读存储器(ROM)502中的计算机程序指令或者从存储单元508加载到随机访问存储器(RAM)503中的计算机程序指令，来执行各种适当的动作和处理。在RAM 503中，还可存储设备500操作所需的各种程序和数据。CPU 501、ROM 502以及RAM503通过总线504彼此相连。输入/输出(I/O)接口505也连接至总线504。

设备500中的多个部件连接至I/O接口505，包括：输入单元506，例如麦克风等；输出单元507，例如各种类型的显示器、扬声器等；存储单元508，例如硬盘等；以及通信单元509，例如网卡、调制解调器、无线通信收发机等。通信单元509允许设备500通过诸如因特网的计算机网络和/或各种电信网络与其他设备交换信息/数据。

上文所描述的各个过程和处理，例如方法200可由处理单元501执行。例如，在一些实施例中，方法200可被实现为计算机软件程序，其被有形地包含于机器可读介质，例如存储单元508。在一些实施例中，计算机程序的部分或者全部可以经由ROM 502和/或通信单元509而被载入和/或安装到设备500上。当计算机程序被加载到RAM 503并由CPU 501执行时，可以执行上文描述的方法200的一个或多个动作。

本发明可以是方法、装置、系统和/或计算机程序产品。计算机程序产品可以包括计算机可读存储介质，其上载有用于执行本发明的各个方面的计算机可读程序指令。

计算机可读存储介质可以是可以保持和存储由指令执行设备使用的指令的有形设备。计算机可读存储介质例如可以是――但不限于――电存储设备、磁存储设备、光存储设备、电磁存储设备、半导体存储设备或者上述的任意合适的组合。计算机可读存储介质的更具体的例子(非穷举的列表)包括：便携式计算机盘、硬盘、随机存取存储器(RAM)、只读存储器(ROM)、可擦式可编程只读存储器(EPROM或闪存)、静态随机存取存储器(SRAM)、便携式压缩盘只读存储器(CD-ROM)、数字多功能盘(DVD)、记忆棒、软盘、机械编码设备、例如其上存储有指令的打孔卡或凹槽内凸起结构、以及上述的任意合适的组合。这里所使用的计算机可读存储介质不被解释为瞬时信号本身，诸如无线电波或者其他自由传播的电磁波、通过波导或其他传输媒介传播的电磁波(例如，通过光纤电缆的光脉冲)、或者通过电线传输的电信号。

这里所描述的计算机可读程序指令可以从计算机可读存储介质下载到各个计算/处理设备，或者通过网络、例如因特网、局域网、广域网和/或无线网下载到外部计算机或外部存储设备。网络可以包括铜传输电缆、光纤传输、无线传输、路由器、防火墙、交换机、网关计算机和/或边缘服务器。每个计算/处理设备中的网络适配卡或者网络接口从网络接收计算机可读程序指令，并转发该计算机可读程序指令，以供存储在各个计算/处理设备中的计算机可读存储介质中。

用于执行本发明操作的计算机程序指令可以是汇编指令、指令集架构(ISA)指令、机器指令、机器相关指令、微代码、固件指令、状态设置数据、或者以一种或多种编程语言的任意组合编写的源代码或目标代码，所述编程语言包括面向对象的编程语言—诸如Smalltalk、C++等，以及常规的过程式编程语言—诸如“C”语言或类似的编程语言。计算机可读程序指令可以完全地在用户计算机上执行、部分地在用户计算机上执行、作为一个独立的软件包执行、部分在用户计算机上部分在远程计算机上执行、或者完全在远程计算机或服务器上执行。在涉及远程计算机的情形中，远程计算机可以通过任意种类的网络—包括局域网(LAN)或广域网(WAN)—连接到用户计算机，或者，可以连接到外部计算机(例如利用因特网服务提供商来通过因特网连接)。在一些实施例中，通过利用计算机可读程序指令的状态信息来个性化定制电子电路，例如可编程逻辑电路、现场可编程门阵列(FPGA)或可编程逻辑阵列(PLA)，该电子电路可以执行计算机可读程序指令，从而实现本发明的各个方面。

这里参照根据本发明实施例的方法、装置(系统)和计算机程序产品的流程图和/或框图描述了本发明的各个方面。应当理解，流程图和/或框图的每个方框以及流程图和/或框图中各方框的组合，都可以由计算机可读程序指令实现。

这些计算机可读程序指令可以提供给通用计算机、专用计算机或其它可编程数据处理装置的处理单元，从而生产出一种机器，使得这些指令在通过计算机或其它可编程数据处理装置的处理单元执行时，产生了实现流程图和/或框图中的一个或多个方框中规定的功能/动作的装置。也可以把这些计算机可读程序指令存储在计算机可读存储介质中，这些指令使得计算机、可编程数据处理装置和/或其他设备以特定方式工作，从而，存储有指令的计算机可读介质则包括一个制造品，其包括实现流程图和/或框图中的一个或多个方框中规定的功能/动作的各个方面的指令。

也可以把计算机可读程序指令加载到计算机、其它可编程数据处理装置、或其它设备上，使得在计算机、其它可编程数据处理装置或其它设备上执行一系列操作步骤，以产生计算机实现的过程，从而使得在计算机、其它可编程数据处理装置、或其它设备上执行的指令实现流程图和/或框图中的一个或多个方框中规定的功能/动作。

附图中的流程图和框图显示了根据本发明的多个实施例的系统、方法和计算机程序产品的可能实现的体系架构、功能和操作。在这点上，流程图或框图中的每个方框可以代表一个模块、程序段或指令的一部分，所述模块、程序段或指令的一部分包含一个或多个用于实现规定的逻辑功能的可执行指令。在有些作为替换的实现中，方框中所标注的功能也可以以不同于附图中所标注的顺序发生。例如，两个连续的方框实际上可以基本并行地执行，它们有时也可以按相反的顺序执行，这依所涉及的功能而定。也要注意的是，框图和/或流程图中的每个方框、以及框图和/或流程图中的方框的组合，可以用执行规定的功能或动作的专用的基于硬件的系统来实现，或者可以用专用硬件与计算机指令的组合来实现。

以上已经描述了本发明的各实施例，上述说明是示例性的，并非穷尽性的，并且也不限于所披露的各实施例。在不偏离所说明的各实施例的范围和精神的情况下，对于本技术领域的普通技术人员来说许多修改和变更都是显而易见的。本文中所用术语的选择，旨在最好地解释各实施例的原理、实际应用或对市场中技术的改进，或者使本技术领域的其它普通技术人员能理解本文披露的各实施例。

Claims (10)

1.一种记录用户关注点的方法，其特征在于，在车载主机上执行，包括：

确定车载主机采集的音频中是否包含预置的多个触发词中的一个；

响应于检测到的所述多个触发词中的一个，判断所述多个触发词中的一个是否为第二触发词；

若是第二触发词，则生成用于记录用户关注点，所述第二关键词为关于预设用户关注点的关键词。

2.根据权利要求1所述的方法，其特征在于，在加载所述车载主机系统后，即获取麦克风权限，执行所述检测车载主机采集的音频中是否包含预置的多个触发词中的一个的步骤。

3.根据权利要求1或2所述的方法，其特征在于，还包括：

响应于检测到的所述多个触发词中的一个，判断所述多个触发词中的一个是否为第一触发词；

若是第一触发词，则启动语音交互，所述第一唤醒词为预设语音交互唤醒词。

4.根据权利要求3所述的方法，其特征在于，所述第二唤醒词与所述第一唤醒词为非近音词。

5.根据权利要求1或2所述的方法，其特征在于，还包括：

若网络连通，则将所述触发记录发送至云端存储。

6.根据权利要求5所述的方法，其特征在于，所述生成用于记录用户关注点的触发记录并不启动语音交互的步骤中还包括至少如下步骤之一：

记录所检测到的第二触发词的内容；

记录检测到第二触发词时的时间；

记录检测到第二触发词时的GPS位置；或

记录检测到第二触发词时的车辆规范数据；所述车辆规范数据中至少包括如下中至少一项：

车载主机型号，用户账户信息，导航应用数据，娱乐应用数据，行车状态数据，车身传感器数据。

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

响应于检测到的所述多个触发词中的一个，判断所述多个触发词中的一个是否为第三触发词；

若是第三触发词，则响应执行对应的操作指令。

8.根据权利要求1所述的方法，其特征在于，还包括，从云端获取新关键词内容以对本地的由至少一个第二触发词构建的第二触发词词库迭代更新。

9.一种车载主机，包括：

至少一个处理单元；以及

与所述至少一个处理单元耦合的存储器，所述存储器包含有存储于其中的指令，所述指令在被所述至少一个处理单元执行时，使得所述设备执行根据权利要求1至8中任一项所述的方法的步骤。

10.一种车辆，其特征在于，搭载有权利要求9所述的车载主机。

Images