跟踪和预测车载app的使用趋势的方法和设备

摘要

本发明涉及跟踪和预测车载app的使用趋势的方法和设备。公开了用于跟踪和预测车载资讯系统应用的使用趋势的方法和系统。应用使用数据被收集在许多道路车辆的资讯系统中。例如通过使用从车辆CAN总线或其他数据总线获得的数据，还提供车辆情景相关指示。表明车辆情景情况（例如交通和天气条件、后座乘客的存在性、行驶路途长度等）的情景相关指示被交叉引用到应用使用数据以便确定在哪些情况下可能使用哪些应用。来自许多车辆的应用使用数据和应用/情景相关数据被收集在中央服务器上并且被分析以便提供表明应用使用趋势的各种指标。应用使用趋势数据能够被车辆制造商使用以优化未来的资讯系统设计。

说明书

技术领域

本发明大体涉及用于跟踪车载资讯系统上的应用的使用并预测应用的未来使用的方法和设备，其中使用跟踪包括基于例如使用最近访问时间和频率的因素的应用的隐含用户等级，并且跟踪和趋势预测二者均包括车辆情况情景数据。

背景技术

信息/娱乐系统或者“资讯系统”已经在车辆中越来越流行，因为电子系统的功能性和性能已经突飞猛进，车辆中的因特网接入已经变得广泛可用，并且用户能力和期望有了相应增长。

现代车辆中的资讯系统不仅允许驾驶员或乘客与智能手机或移动装置交互作用，而且系统还提供其自身的内置资讯功能，包括例如存储和播放媒体文件、运行本地应用（“app”）、连接到因特网以获取文件和实时数据等等的特征。

随着车辆制造商大量地提供了更多的内置资讯系统，开发商通过使得更多的app可用于车辆资讯系统而做出响应。对于一些品牌的车辆制造商资讯系统，现在存在上千个app可用于下载和执行。随着app空间越来越大，车辆内的驾驶员或者乘客更加难以找到他们最感兴趣的app。这是特别属实的，因为驾驶员正关注于驾驶而不是关注于浏览app。

在智能手机等上的现有app使用跟踪器被局限成简单地跟踪app使用以为了节省电池寿命或最小化蜂窝数据传输的目的。类似地，现有app推荐引擎通常仅评估简单参数，例如app分类。能够做出更多工作来理解app使用趋势并且辅助车辆驾驶员和乘客寻找和执行他们本人可能喜欢的且/或在车辆驾驶环境的当前情景下对他们可能有用的app。

发明内容

根据本发明教导，公开了用于跟踪和预测车载资讯系统应用的使用趋势的方法和系统。应用使用数据被收集在许多道路车辆的资讯系统中。例如通过使用从车辆CAN总线或其他数据总线获得的数据，还提供车辆情景相关指示。表明车辆情景情况（例如交通和天气条件、后座乘客的存在性、行驶路途长度等）的情景相关指示被交叉引用到应用使用数据以便确定在哪些情况下可能使用哪些应用。来自许多车辆和驾驶员的应用使用数据和应用/情景相关数据被收集在中央服务器上并且被分析以便提供表明应用使用趋势的各种指标。应用使用趋势数据能够被车辆制造商使用以优化未来的资讯系统设计。

本发明还可包括下列方案。

1. 一种用于跟踪和预测车载资讯系统应用的使用趋势的方法，所述方法包括：

在车辆上机载的处理器中收集用于车载资讯系统应用的使用数据，所述处理器包括微处理器和存储器模块；

从所述使用数据计算所述应用的用户等级；

在所述处理器中从车辆控制器局域网总线（CAN总线）收集车辆操作数据；

从所述车辆操作数据来计算情景指示；

从所述使用数据、所述用户等级和所述情景指示来计算应用/情景相关性；

将所述使用数据、所述用户等级、和所述应用/情景相关性从所述车辆上传到中央服务器计算机以用于聚集；以及

在所述中央服务器计算机上从上传自许多道路车辆的所述使用数据、所述用户等级、和所述应用/情景相关性来计算整个用户群的应用使用趋势。

2. 根据方案1所述的方法，其中计算用户等级包括：计算隐含等级，基于用户浏览应用的最近访问时间、所述用户使用所述应用的最近访问时间、所述用户使用所述应用的频率、所述用户使用所述应用的持续时间以及所述应用的货币价值来计算所述隐含等级。

3. 根据方案2所述的方法，其中所述用户等级还包括由所述用户提供的明确等级。

4. 根据方案1所述的方法，其中所述车辆操作数据包括：车辆速度、变速器是否处于驻车档或行驶档、行驶路途中行驶的持续时间段和距离、导航和GPS数据、防抱死制动系统（ABS）使用数据、牵引控制系统数据、挡风玻璃雨刷是开还是关、驾驶员身份以及所述车辆中每个座位的占用状态。

5. 根据方案1所述的方法，其中所述情景指示包括：所述车辆是否正在行驶或驻车；在行驶之前、期间或之后是否使用应用；所述车辆是否在城市中或高速上行驶；交通和天气条件；以及所述车辆中乘客的存在性。

6. 根据方案1所述的方法，其中将所述使用数据、所述用户等级和所述应用/情景相关性从所述车辆上传到中央服务器计算机包括：通过使用远程信息处理服务将所述使用数据、所述用户等级和所述应用/情景相关性从所述车辆无线上传到所述中央服务器计算机。

7. 根据方案1所述的方法，其中计算应用使用趋势包括：将所述应用的人气值计算为所述应用的所述用户等级的统计学平均值。

8. 根据方案7所述的方法，其中计算应用使用趋势包括：将所述应用的时间加权的活跃度计算为针对一组过去时间间隔的应用的所述人气值的求和，且更近期的人气值具有更大权重。

9. 根据方案8所述的方法，其中计算应用使用趋势包括：计算包括是在该应用的所述时间加权的活跃度的斜率和所有应用的所述时间加权的活跃度的平均斜率之间的差的项的上升趋势值。

10. 根据方案1所述的方法，其中计算应用使用趋势包括：通过将用户群划分成多个组、计算该应用向每个所述组内的渗透性以及将多样性值计算为该应用向所有所述组内的渗透性的函数从而计算应用的多样性值。

11. 根据方案10所述的方法，其中用于计算所述多样性值的所述组包括人口统计学组和地理学组。

12. 一种用于跟踪和预测车载资讯系统应用的使用趋势的方法，所述方法包括：

在车辆上机载的处理器中收集用于车载资讯系统应用的使用数据，所述处理器包括微处理器和存储器模块；

从所述使用数据计算所述应用的用户等级，包括计算隐含等级，其中基于用户浏览应用的最近访问时间、所述用户使用所述应用的最近访问时间、所述用户使用所述应用的频率、所述用户使用所述应用的持续时间以及所述应用的货币价值来计算所述隐含等级；

在所述处理器中从车辆控制器局域网总线（CAN总线）收集车辆操作数据，其中所述车辆操作数据包括：车辆速度、变速器是否处于驻车档或行驶档、行驶路途中行驶的持续时间段和距离、导航和GPS数据、防抱死制动系统（ABS）使用数据、牵引控制系统数据、挡风玻璃雨刷是开还是关、以及所述车辆中每个座位的占用状态；

从所述车辆操作数据来计算情景指示，其中所述情景指示包括：所述车辆是否正在行驶或驻车；在行驶之前、期间或之后是否使用应用；所述车辆是否在城市中或高速上行驶；交通和天气条件；以及所述车辆中乘客的存在性；

从所述使用数据、所述用户等级和所述情景指示来计算应用/情景相关性；

将所述使用数据、所述用户等级和所述应用/情景相关性从所述车辆无线地上传到中央服务器计算机以用于聚集；以及

在所述中央服务器计算机上从上传自许多道路车辆的所述使用数据、所述用户等级和所述应用/情景相关性来计算整个用户群的应用使用趋势。

13. 根据方案12所述的方法，其中计算应用使用趋势包括：

将该应用的人气值计算为应用的所述用户等级的统计学平均值，并且将所述应用的时间加权的活跃度计算为针对一组过去时间间隔的应用的所述人气值的求和，且更近期的人气值具有更大权重；以及

通过将用户群划分成多个组、该应用向每个所述组内的渗透性以及将多样性值计算为该应用向所有所述组内的渗透性的函数从而计算应用的所述多样性值，其中用于计算所述多样性值的所述组包括人口统计学组和地理学组。

14. 一种用于跟踪和预测车载资讯系统应用的使用趋势的系统，所述系统包括：

车辆上机载的处理器，所述处理器包括微处理器和存储器模块，其中所述处理器被配置成具有用于跟踪资讯系统应用的使用的算法，包括：

　　应用使用收集模块，其被配置成收集车载资讯系统应用的使用数据并且从所述使用数据计算所述应用的用户等级，

　　车辆操作信息收集模块，其被配置成从车辆控制器局域网总线（CAN总线）收集车辆操作数据，

　　情景相关确认模块，其被配置成从所述车辆操作数据计算情景指示，以及

　　交叉引用模块，其被配置成从所述使用数据、所述用户等级和所述情景指示来计算应用/情景相关性，

其中所述处理器还被配置成将所述使用数据、所述用户等级和所述应用/情景相关性从所述车辆无线地上传，以用于聚集；以及

包括处理器、存储器模块和网络连接的中央服务器计算机，其中所述中央服务器计算机被配置成从上传自所述车辆和许多其他车辆的所述使用数据、所述用户等级和所述应用/情景相关性来计算整个用户群的应用使用趋势。

15. 根据方案14所述的系统，其中所述用户等级包括隐含等级，其中基于用户浏览应用的最近访问时间、所述用户使用所述应用的最近访问时间、所述用户使用所述应用的频率、所述用户使用所述应用的持续时间以及所述应用的货币价值来计算所述隐含等级。

16. 根据方案14所述的系统，其中所述车辆操作数据包括：车辆速度、变速器是否处于驻车档或行驶档、行驶路途中行驶的持续时间段和距离、导航和GPS数据、防抱死制动系统（ABS）使用数据、牵引控制系统数据、挡风玻璃雨刷是开还是关、驾驶员身份以及所述车辆中每个座位的占用状态。

17. 根据方案14所述的系统，其中所述情景指示包括：所述车辆是否正在行驶或驻车；在行驶之前、期间或之后是否使用应用；所述车辆是否在城市中或高速上行驶；交通和天气条件；以及所述车辆中乘客的存在性。

18. 根据方案14所述的系统，其中所述应用使用趋势包括被计算为应用的所述用户等级的统计学平均值的所述应用的人气值。

19. 根据方案18所述的系统，其中所述应用使用趋势包括被计算为针对一组过去时间间隔的所述应用的所述人气值的求和的所述应用的时间加权的活跃度，且更近期的人气值具有更大权重。

20. 根据方案14所述的系统，其中所述应用使用趋势包括通过将用户群划分成多个组、计算该应用向每个所述组内的渗透性以及将多样性值计算为该应用向所有所述组内的渗透性的函数从而计算得到的应用的多样性值，其中用于计算所述多样性值的所述组包括人口统计学组和地理学组。

从下述描述和所附权利要求结合附图将显而易见到本发明的附加特征。

附图说明

图1是包括资讯系统的车辆的示意图，该资讯系统被构造成跟踪车载app使用、预测使用趋势并且向用户做出推荐；

图2是能够被用于跟踪车载app使用并预测app使用趋势的架构的框图；

图3是代表被用于跟踪车载app使用并预测app使用趋势的图2架构的一种实施例的系统的框图；

图4是用于跟踪并预测车载app的使用趋势的方法的流程图；

图5是用于向用户做出资讯系统app的推荐的系统的框图；

图6A是包含出自一组用户的一组app的已知等级信息的二分图的视图；

图6B是示出如何能够从现有用户app等级数据推断出一些未知关系的二分图的视图；以及

图7是用于向用户做出资讯系统app的推荐的方法的流程图。

具体实施方式

涉及跟踪和预测车载app的使用趋势的方法和设备的本发明实施例的下述讨论实质上仅是示例性的并且不以任何方式试图限制本发明或其应用或使用。

现代车辆中的资讯系统不仅允许驾驶员或乘客接入智能手机或移动装置，而且系统还提供其自身的内置资讯功能，包括例如存储和播放媒体文件、运行本地应用（“app”）、访问因特网以获取文件和实时数据等等的特征。现在，多个车辆制造商现在提供资讯系统，并且app开发商已经通过针对这些资讯系统放出数千个app来进行响应。

在可用app的数量有些势不可挡的情况下，消费者将逐渐转向推荐引擎或其他信息源来寻找相关和有用的移动应用，而不是在数千可用的移动app中进行挑选。资讯系统用户能够获益于他们本人可能感兴趣的或者处于他们当前车辆驾驶情景中的app的精确且及时的推荐。类似地，车辆制造商能够获益于表明app使用趋势的数据，因为这个数据能够有用于优化未来资讯系统的硬件和操作系统。

图1是包括资讯系统102的车辆100的示意图，该资讯系统102被构造成跟踪车载app使用、预测使用趋势并且向用户104做出推荐。资讯系统102至少包括处理器106和显示器108。资讯系统102还包括用于提供车辆100内的声音输出的至少一个扬声器110和用于从用户104接收声音输入的至少一个扩音器112。

处理器106被示于图1并且在此被描述为单个元件，但是，这样的图释是为了便于描述并且应该意识到，由这个元件执行的功能可以被结合在一个或更多个装置内，例如，被实现在软件、硬件和/或专用集成电路中。处理器106可以是专用或通用数字计算机，其包括微处理器或中央处理单元、包括非易失存储器（包括只读存储器和电可编程只读存储器）的存储介质、随机存取存储器、高速时钟、模数和数模电路以及输入/输出电路和装置以及适当的信号调制和缓冲电路。处理器106具有在下文中讨论的方法中被描述的一组处理算法，包括存储在非易失存储器中且被执行以提供相应功能的常驻程序指令和校准值。算法可以在预设的基于时间的循环回路期间被执行，或者算法可以响应于事件的发生被执行。

显示器108可以共享于车辆导航系统、气候控制界面或者在车辆100内的其他目的。显示器108通常是触摸屏设计，其中在屏幕上能够显示选项并且通过用户104触摸显示器108的屏幕来做出选择。

资讯系统102还包括输入/输出端口114，其可以优选地是通用串行总线（USB）端口。端口114能够被用于通过使用适配器线缆（未示出）将移动装置和智能手机（例如智能手机116）连接到资讯系统102。当经由端口114被连接到资讯系统102时，智能手机116能够被充电、能够使得音乐或者视频流向资讯系统102以及实现其他功能。替代性地，智能手机116能够通过使用蓝牙、Wi-Fi、近程通信（NFC）或者任意其他的短程无线通信协议与资讯系统102无线通信。

车辆100（具体地，资讯系统102）能够与蜂窝服务118和因特网120无线通信。车辆因特网接入可以经由蜂窝服务118被实现，或者其可以经由一些其他形式的无线通信绕过蜂窝服务118而到达因特网120，其中所述无线通信例如是使用专用短程通信（DSRC）或者外部Wi-Fi的车辆至基础设施通信。蜂窝服务118还可以被用于实现远程信息处理服务，其提供例如导航和礼宾服务的便利设施，并且蜂窝服务118还可以被用于下文讨论的app使用跟踪、预测和推荐服务。

图2是能够被用于跟踪车载app使用并预测app使用趋势的架构140的框图。在架构140中，虚线矩形内的模块被机载在车辆100上。车载app使用收集模块142收集关于资讯系统102中的app使用的数据。被app使用收集模块142收集的信息包括与app商店的用户交互，例如浏览app商店内的app、（免费）下载app、购买app（被存储以备未来使用的成本价值）以及在下载或购买后app的后续使用。app使用收集模块142还记录对每个app的每次使用，以便使用数据的最近访问时间以及每个app的使用频率和每个app的每次使用的持续时间总是可用的。

通过使用上述数据，app使用收集模块142能够如下来量化用户104对每个app的隐含等级r：

  (1)

其中V_R1是定义浏览app的最近访问时间的值，V_R2是定义使用app的最近访问时间的值，V_F是定义使用app的频率的值，V_D是定义使用app的持续时间的值，并且V_M是定义app的货币价值（或支付的量）的值。w变量是用于等式中的相应值V的加权值，并且被内在关联以致。

交叉引用模块144从app使用收集模块142接收app使用数据和app等级数据。通过使用app使用和等级数据以及下述的其他数据，交叉引用模块144执行对app使用趋势的本地（在车辆100上机载）数据分析，如下文进一步讨论的。

CAN总线信息收集模块146从车辆CAN总线（控制器局域网总线）或者任意其他可用的车辆数据总线收集关于车辆操作的所有方面的数据。被CAN总线信息收集模块146收集的数据可以包括车辆速度、变速器是否驻车档或行驶档、行驶路途中行驶的持续时间段和距离、导航和GPS数据、防抱死制动系统（ABS）使用数据，牵引控制系统数据、挡风玻璃雨刷开或关、车辆中每个座位的占用状态以及其他参数。如果驾驶员身份信息是可用的，则CAN总线信息收集模块146还可以记录驾驶员的身份。

情景相关确认模块148从CAN总线信息收集模块146接收原始车辆操作数据、处理该数据并且向交叉引用模块144提供车辆操作情景指示。在此的想法是在不同的车辆情景情形下，不同app可以具有不同程度的受欢迎度。因此，在具体车辆情景情形下的app使用模式比仅有app使用数据是更有意义的信息。由情景相关确认模块148提供的操作情景指示可以例如表明在具体时间，车辆100正行驶还是驻车、正在相对长的行驶路途中、正在某种道路类型（高速、街道、砾石路等）上、在某种道路条件（大或小摩擦）下以及交通条件（灯、正常或拥挤）、后座上是否有儿童、当前车辆位置是被频繁地还是不频繁地查看以及驾驶员是否正在使用导航辅助。驾驶员身份也可以被包括以作为情景指示。情景相关确认模块148可以通过使用来自CAN总线信息收集模块146的原始数据（包括这里未列出的其他情景）来得到许多不同类型的情景参考。

由情景相关确认模块148得到的情景参考能够被交叉引用模块144使用来确定app使用和车辆操作情景之间的关系。例如，在行驶路程可以被导航系统数据检测到并且可以以声音/语音识别模式使用邮件app的情况下，可以从数据得知只要在不熟悉地点行驶时驾驶员喜欢使用特定的导航app或者在行驶去工作的路上时驾驶员会希望检查她的每日邮件。交叉引用模块144能够使用任意适当的统计或数字技术来确认app使用数据和车辆情景参考数据之间的相关性。

来自交叉引用模块144的app使用数据和app/情景相关数据被提供至基于云的聚集和趋势跟踪模块150。聚集和趋势跟踪模块150驻留在例如能够从道路上的许多车辆收集数据和/或传播数据至道路上的许多车辆的因特网服务器的装置上。例如，特定车辆制造商可以使用其远程信息处理服务（例如OnStar?）来上传来自成千上万的道路车辆的app使用数据和app/情景相关数据。替代性地，聚集和趋势跟踪模块150可以被构造成当车辆具有无线因特网接入时收集来自车辆上机载的交叉引用模块144的数据。不管车辆如何将它们的数据通信到服务器，聚集和趋势跟踪模块150聚集许多用户和车辆的app使用数据，并且分析被聚集的数据来产生整个用户群的app使用趋势。

如本领域一个技术人员理解的，本公开中提到因特网服务器或中央服务器计算机意味着一台计算机或计算机群，其至少包括微处理器或者中央处理单元、存储器和网络连接。服务器计算机可以被配置成具有用于分析app使用和等级数据、跟踪使用趋势、向用户推荐app等的算法。

聚集和趋势跟踪模块150能够基于来自许多用户和车辆的app使用数据来计算各种指标。能够被计算的一个指标是app i的人气，这能够通过在收集的数据所来自的整个用户群上使用如平均值和标准偏差的统计学从（来自等式1的）等级r计算得到。

能够被计算的另一个指标是app i的时间加权的活跃度。时间加权的活跃度指标的目的是用作对用户之间app活跃度水平的指示，其中对更近期的使用给予更大的加权。以如下方式在一个过去时间窗口（例如过去的一个月或过去的一年）上计算时间加权的活跃度：

             (2)

其中在从过去时间（-n）直到当前时间（0）的时间t上求和，是人气，并且a是常数。应该注意到的是，因为t在等式2中总是负的，所以对于过去更遥远的时间，因数a^t非常小（比1小得多），并且针对接近当前时间的时间，因数a^t更接近等于1，因此提供了如前所述的时间加权。

能够被计算的另一个指标是app i的人口统计或地理多样性。多样性指标的目的是用作对app的用户的多样性的指示，该多样性包括人口统计和地理多样性以及可能的其他类型。通过首先将用户群划分成多个组G并且通过使用如下等式来计算app对每个组G的渗透性P来计算app的多样性：

                (3)

其中是对app i的组G的渗透性，n是组G中app i的用户数量，并且N是所有组中全部用户的数量。作为示例，组G可以代表基于年龄或种族划分的人口统计组，其中可以存在大约8-10个不同的组。组G还可以代表基于全球区域、美国区域或一些其他地理学分区的地理学组。一旦组被定义并且其被每个app的渗透性被计算，则如下计算多样性指标：

            (4)

其中对所有组G计算求和，并且在等式3中定义渗透值P。

能够被计算的另一个指标是app i的向上趋势指示。向上指标的目的是用作对用户中app的活跃水平的向上或向下趋势的指示，并且其相对于所有app的趋势被计算以便考虑到所有app使用趋势。通过首先计算每个app的活跃度在过去时间段上的（斜率）或趋势来确定app的上升趋势。被定义成（活跃度）指标相对于时间的斜率，并且能够通过使用线性回归或另一合适的统计技术被计算。之后如下在一个过去时间窗口（例如过去的一个月或过去的一年）上计算上升趋势指标：

    (5)

其中是在该时间段上app i的人气H的均值，是恰在上文描述的斜率指标，是在该时间段上的所有app的平均（均值）斜率，并且t是该时间段。

能够通过在计算中包括app/情景相关数据来进一步精炼上述任意指标。例如，可以针对具有后座乘客的情况计算人气。除了上述那些之外也能够想到可以由聚集和趋势跟踪模块150基于来自许多用户和车辆的app使用、等级和情景数据来计算的其他指标。

由聚集和趋势跟踪模块150计算的整个用户群的app使用趋势能够被用于多种目的。通过理解处理和存储器需求、如何基于app使用模式能够改进资讯系统操作系统和人机界面等等，车辆制造商能够使用app使用趋势数据来优化未来资讯系统设计。app使用趋势数据也能够被给予或出售给app开发商以便帮助开发商更好地理解他们的app和同类型其他app的使用。app使用趋势数据也能够被用于向用户做出关于下载、购买或使用某些app的推荐。趋势数据还可以被用于给应用中的广告标价。

图3是代表被用于跟踪车载app使用并预测app使用趋势的架构140的一种实施例的系统160的框图。在系统160中，app使用收集模块142、交叉引用模块144、CAN总线信息收集模块146和情景相关确认模块148被一起组合在于资讯系统102上运行的数据收集app 162中。替代性地，模块142-148均可以是独立app或者可以以一些其他方式组合。在任意情况下，这些数据收集和分析模块作为资讯系统102上的一个或更多个app运行。app 162（或者多个app）将由车辆制造商开发并且在资讯系统102上始终以后台模式运行。

一组用户app 164也在资讯系统102上运行。用户app 164是由用户104下载并/或购买的多个app，并且可以被任意开发商开发。用户app 164是提供用户所需的特征和功能的app，类似于智能手机116上的那些app。即，用户app 164能够被用于例如娱乐、天气、新闻、运动、导航、游戏等等事情。这是使用趋势跟踪所涉及的用户app 164。

网关app 166也在资讯系统102上运行。网关app 166也由车辆制造商开发并且在资讯系统102上始终以后台模式运行。网关app 166用作在资讯系统102与驻留在基于云的服务器上的聚集和趋势跟踪模块150之间的双向通信接口。网关app 166的主要功能是将app使用数据和app/情景相关数据从交叉引用模块144发送到聚集和趋势跟踪模块150。

app框架168驻留在资讯系统102上并且用作所有驻留app的基础。具体地，app框架168允许用户app 164的下载和使用数据由数据收集app 162的app使用收集模块142收集。app框架168还允许来自交叉引用模块144的app使用数据和app/情景相关数据由网关app 166取用，该网关app 166将其发送至聚集和趋势跟踪模块150。

图4是用于跟踪并预测车载app的使用趋势的方法的流程图180。在框182处，多个用户app的使用数据被收集，如在app使用收集模块142的描述中所讨论的。在框184处，通过使用等式1，针对每个用户app计算隐含用户等级。在框186处，从车辆CAN总线收集车辆操作数据。如上文关于CAN总线信息收集模块146所讨论的，从CAN总线收集的数据包括能够被用于确定行驶环境情景的任意车辆操作参数。在框188处，由来自CAN总线的操作数据计算车辆操作情景指示。如上文所讨论的，情景指示指定了任意给定时间所经历的行驶情形的类型，例如在拥堵的交通中短程单独驶向工作或者在雨天带着孩子的长途越野路途等等。

在框190处，app使用和等级数据以及情景指示数据被用于计算app/情景相关性，该相关性表明针对车辆100中的用户104当app使用趋势关联于车辆情景时的app使用趋势。如上文具体讨论的，流程图框182-190的步骤在车辆100上机载的资讯系统102内被执行。在框192处，app使用和等级数据以及app/情景相关性被提供给服务器计算机以用于对于许多车辆的聚集。如上文讨论的，服务器计算机可以是基于因特网的服务器或者远程信息处理服务服务器。在框194处，从app使用数据和app/情景相关性来计算整个用户人口群体的app使用趋势。app使用趋势包括能够被计算的各种指标，包括app人气、时间加权的活跃度、多样性和上升趋势。app使用趋势能够被车辆制造商、app开发商等等来使用。

如上文讨论的，随着资讯系统app市场变得更加流行，车辆内的驾驶员或者乘客更加难以找到他们可能最感兴趣的app。在可用app的数量（成千上万）有些势不可挡的情况下，消费者将逐渐转向推荐引擎或其他信息源来找到相关和有用的移动应用，而不是在移动app市场上手动挑选。如上文具体描述的从许多车辆收集到的app使用和等级数据也能够被用作向各个用户做出app推荐的基础。

通过使用例如用app分类进行拣选来向用户推荐其他app的技术，或者通过使用社区网络朋友圈来推荐，现有app推荐工具仅提供初级能力。但是，通过使用来自资讯系统app的数千或数万用户的app等级数据，能够识别出相似性，这会允许向各个用户做出准确的app推荐。具体地，这里公开的推荐系统收集了出自许多不同用户的许多不同app的等级，并且之后使用相似性引擎通过确定用户的应用相似性和应用的用户相似性来做出准确的app推荐。这些技术在下文中被讨论。

图5是用于向用户做出资讯系统app的推荐的系统200的框图。包括下述多个模块的系统200能够被实践成在服务器计算机上运行的一个或多个算法，该服务器计算机能够从许多车辆资讯系统无线上传数据，如先前所讨论的。一组用户202使用向系统200提供数据的车辆中的资讯系统。对于完全展开的系统而言，该组用户202在数量上可以是数百万的。一组app 204驻留在向系统200提供数据的车辆中的资讯系统上。并非该组app 204中的每个app均驻留在每个资讯系统上，也并非每个app均被该组用户202中的每个用户使用。对于完全展开的系统而言，该组app在数量上可以是数万或更多。

等级模块206包括明确用户等级模块208和隐含用户等级模块210。app的用户等级能够是明确的或隐含的。能够通过允许用户直接给具体app分级（例如1星至5星）来收集明确的等级数据。明确用户等级模块208收集app的所有这样的可用明确用户等级。

隐含等级数据能够如上文等式（1）中所示被定义，并被如下修改成考虑到来自多个用户的等级:

 (6)

其中是由用户U_m针对app A_n给出的等级，V_R1是定义浏览app的最近访问时间的值，V_R2是定义使用app的最近访问时间的值，V_F是定义使用app的频率的值，V_D是定义使用app的持续时间的值，并且V_M是定义app的货币价值（或支付的量）的值。w变量是用于等式中的相应值V的加权值，并且被内在关联以致。隐含用户等级模块210收集如等式（6）中所定义的app的隐含用户等级。

等级模块206以任意合适的方式组合app的明确和隐含用户等级，以便提供尽可能多的用户的针对尽可能多的app的等级。例如，等级模块206可以使用加权的平均值来提供聚集的用户/app等级数据，其中加权的平均值向明确等级给出的权重比向隐含等级给出的权重更大。替代性地，等级模块206可以针对已经由用户给出明确等级的任意用户-应用对而放弃隐含等级的计算。

在任意情况下，聚集的用户/app等级数据被提供给过滤模块212，其能够在进一步处理之前针对相关性过滤用户和app二者。例如，用户可以被过滤成仅包括来自特定车辆类型的资讯系统用户，或者基于用户属性被过滤。类似地，app可以通过位置感知、新鲜度或者app在应用名单中的属性（例如使用哪个应用API）被过滤。

被过滤的用户/app等级数据被提供给推荐模块214。推荐模块214包括用户驱动的共识模块216和app驱动的共识模块218，如下文讨论的。用户驱动的共识模块216和app驱动的共识模块218向推荐合成器220提供用户/app相关数据。推荐合成器220使用来自用户驱动的共识模块216和app驱动的共识模块218的用户/app相关数据以及可选的外部输入222来向用户做出具体app推荐。外部输入222可以包括任意基于云或“网络空间”的输入，例如来自因特网搜索引擎、移动装置操作系统的制造者、因特网购物服务等的app推荐。

现在将讨论用户驱动的共识模块216和app驱动的共识致模块218如何从被过滤的用户/app等级数据来确定用户/app相关数据，从而识别具体用户可能感兴趣的app。这个确定经由相似性测量的计算被做出并且能够通过二分图被可视化。

图6A是包含出自一组用户302的一组app 304的已知等级信息的二分图300的视图。如上所讨论的，用户302和app 304已经优选地被过滤。即，通过使用来自过滤模块212的被过滤的用户/app等级数据来构造二分图300。图300为了清晰仅示出有限数量的用户302和app 304。在二分图300中用户302的数量不需要等同于app 304的数量，并且根据如何执行过滤，可以存在比app更多的用户，或者可以存在比用户更多的app。

出自用户的app的每个已知等级（无论是隐含的、明确的或是二者组合）在二分图300上被显示为关系线306。例如，第一（最左）用户已经将第一app分级为4，第一用户已经将第二app分级为3，第二用户已经将第四app分级为3等等，并且最后用户已经将最后的app分级为1。在图300中仅示出少量等级数字，以便避免使得图像杂乱，但是每条关系线306基于如上所讨论的app的隐含或明确用户等级实际上均具有与其相关的等级数。为了简明示出了整数等级值，但是关系线306上的等级不需要是整数值。

在观察图300时，显而易见到缺失了许多关系线306；即某些用户对于某些app的关系或等级是未知的，这非常可能表明所讨论的该用户没有看到或使用所讨论的该app。例如，第一用户不具有针对第四app的等级，第二用户不具有针对第二app的等级，等等。

图6B是示出如何能够从现有用户app等级数据推断出一些未知关系的二分图310的视图。在图310中，在图300中缺失的一些关系线306以使用标注以问号的加粗虚线填充。虽然这些未知关系不存在等级数据，但是相似性引擎技术可以被用于推断出等级。如果在不存在关系时推断出关系，则这个关系可以被推荐合成器220用作在推断出的等级很高的情况下向用户推荐app的基础。

用户驱动的共识模块216能够以下述方式计算出自用户的app的被推断等级。首先，如下述计算在目标用户和其他用户之间的相似性测量：

 (7)

其中Sim（U_i，U_j）是目标用户U_i和另一用户U_j之间的相似性，针对是已经被用户U_i和U_j二者分级的一组app A中的元素的每个app a_l进行求和，r（U_i，a_l）是由用户U_i针对app a_l给出的等级（且类似地针对用户U_j），并且是由用户i或者j给所有app的平均等级。通过使用等式（7），通过比较他们给共同app的等级来确定用户间的相似性。

之后，从相似性测量中识别出目标用户的数量K个最近近邻。K个最近近邻旨在是与目标用户志趣相投的用户，并且因此可能对目标用户没有等级的具体app具有类似态度。

最后，通过聚集k个最近近邻用户的共识来计算目标用户对具体app的推断等级，如下：

  (8)

其中是出自目标用户U_h的app a_l的推断等级，是出自目标用户U_h的所有app的平均等级，针对K个最近近邻中的每个用户k进行求和，且等级（r和）和相似性Sim（U_h，U_k）被如上定义。

如包括等式（7）和等式（8）的上面三段所述，在用户先前没有可用等级的情况下，用户驱动的共识模块216能够基于用户相似性计算出自所述用户的app的推断等级。来自用户驱动的共识模块216的推断等级能够被推荐合成器220使用以在推断等级值很高的情况下向用户做出app的具体推荐。

app驱动的共识模块218能够以类似于上述的方式计算出自用户的app的被推断等级，只不过是在app相似性方面而不是在用户相似性方面。首先，如下来计算在目标app和其他app之间的相似性测量：

 (9)

其中Sim（a_i，a_j）是目标app a_i和另一app a_j之间的相似性，针对是已经给app a_i和a_j二者分级的一组用户U中的元素的每个用户u_m进行求和，r（u_m，a_i）是由用户u_m针对app a_i给出的等级（且类似地针对app a_j），并且是由用户u_m给所有app的平均等级。使用等式（9），通过比较app出自共同用户的等级来确定所述app之间的相似性。

之后，从相似性测量中识别出目标app的数量K个最近近邻。K个最近近邻旨在是与目标app具有类似属性的app，并且因此可能对没有对目标app分级的具体用户具有类似吸引力。

最后，通过聚集K个最近近邻app的共识来计算出自具体用户的目标app的推断等级，如下：

  (10)

其中是出自用户U_h的目标app a_l的推断等级，是出自所有用户的目标app a_l的平均等级，针对K个最近近邻中的每个app k进行求和，并且等级（r和）和相似性Sim（a_l，a_k）被如上定义。

如包括等式（9）和等式（10）的上面三段所述，在先前没有可用等级的情况下，app驱动的共识模块218能够基于app相似性计算出自用户的app的推断等级。来自app驱动的共识模块218的推断等级能够被推荐合成器220使用以在推断等级值很高的情况下向用户做出app的具体推荐。

来自用户驱动的共识模块216和app驱动的共识模块218的输出以及可选的外部输入222被推荐合成器220使用来向用户做出具体app推荐。推荐合成器220能够以任意适当方式（例如简单平均、加权平均或其他信息融合算子）结合来自用户驱动的共识模块216、app驱动的共识模块218的输入和可选的外部输入222。

图7是用于向用户做出资讯系统app的推荐的方法的流程图320。在框322处，收集来自车载资讯系统的许多用户的许多app的app等级数据。数据可以从车辆资讯系统被无线传输到中央服务器。数据可以包括出自用户的app的明确等级以及隐含等级二者，其中基于例如浏览app的最近访问时间、使用app的最近访问时间、使用app的频率、使用app的持续时间和app的货币价值的因素来计算所述隐含等级。app的明确和隐含用户等级可以在进一步处理之前被结合。

在框324处，针对相关性过滤用户/app等级数据。可以基于用户属性来过滤用户并且可以基于app属性来过滤app，以便提供与手头推荐最相关联的一组用户、app和等级。在框326处，在没有可用等级时，被过滤的用户/app等级数据被用于通过使用用户驱动的共识计算来针对用户/app关系计算推断等级。如上文讨论的，当先前没有可用等级时，用户驱动的共识计算基于共同app的等级的用户相似性来计算出自用户的app的推断等级。在框328处，在没有可用等级时，被过滤的用户/app等级数据被用于通过使用app驱动的共识计算来针对用户/app关系计算推断等级。如上文讨论的，当先前没有可用等级时，app驱动的共识计算基于出自共同用户的等级的app相似性来计算出自用户的app的推断等级。

在框330处，来自用户驱动的共识计算和app驱动的共识计算的推断等级被用于合成针对具体用户的具体app推荐。app推荐合成还可以包括外部输入，例如来自因特网搜索引擎、移动装置操作系统的制造者、因特网购物服务等的app推荐。可以以任意合适的方式（例如简单平均或者加权平均）来组合推断等级和外部输入。在框332处，通过从中央服务器向用户车辆内的资讯系统下载，针对app考虑的合成推荐被提供给适当的用户。

基于真实用户/app关系数据（例如，与简单的app分类不同）做出的app推荐更可能被车载资讯系统的用户很好地接受。这种高品质推荐服务导致顾客针对资讯系统本身和整个车辆的满意度增加。

通过使用上述技术，能够分析包括隐含用户等级和情景相关性的资讯系统app使用数据来检测使用趋势。检测到的使用趋势能够有助于指导车辆制造商和app开发商进行未来的研发，并且基于从整个用户群收集的app使用数据能够向用户做出有帮助的推荐。

前文讨论仅公开并描述了本发明的示例性实施例。本领域的技术人员从这样的讨论且从附图和权利要求中将容易地认识到，能够在不背离如所附权利要求所限定的本发明的精神和范围的前提下做出各种修改、改进和变型。