要在不熟悉地点行驶 时驾驶员喜欢使用特定的导航app或者在行驶去工作的路上时驾驶员会希望检查她的每 日邮件。交叉引用模块144能够使用任意适当的统计或数字技术来确认app使用数据和车 辆情景参考数据之间的相关性。
[0044] 来自交叉引用模块144的app使用数据和app/情景相关数据被提供至基于云的 聚集和趋势跟踪模块150。聚集和趋势跟踪模块150驻留在例如能够从道路上的许多车辆 收集数据和/或传播数据至道路上的许多车辆的因特网服务器的装置上。例如，特定车辆 制造商可以使用其远程信息处理服务(例如OnStar?)来上传来自成千上万的道路车辆的 app使用数据和app/情景相关数据。替代性地，聚集和趋势跟踪模块150可以被构造成当 车辆具有无线因特网接入时收集来自车辆上机载的交叉引用模块144的数据。不管车辆如 何将它们的数据通信到服务器，聚集和趋势跟踪模块150聚集许多用户和车辆的app使用 数据，并且分析被聚集的数据来产生整个用户群的app使用趋势。
[0045] 如本领域一个技术人员理解的，本公开中提到因特网服务器或中央服务器计算机 意味着一台计算机或计算机群，其至少包括微处理器或者中央处理单元、存储器和网络连 接。服务器计算机可以被配置成具有用于分析app使用和等级数据、跟踪使用趋势、向用户 推荐app等的算法。
[0046] 聚集和趋势跟踪模块150能够基于来自许多用户和车辆的app使用数据来计算各 种指标。能够被计算的一个指标是app i的人气这能够通过在收集的数据所 来自的整个用户群上使用如平均值和标准偏差的统计学从(来自等式1的）等级r计算得 到。
[0047] 能够被计算的另一个指标是app i的时间加权的活跃度⑴。时间 加权的活跃度指标的目的是用作对用户之间app活跃度水平的指示，其中对更近期的使用 给予更大的加权。以如下方式在一个过去时间窗口（例如过去的一个月或过去的一年)上计 算时间加权的活跃度：
其中在从过去时间（_n)直到当前时间（0)的时间t上求和，是人气，并且 a是常数。应该注意到的是，因为t在等式2中总是负的，所以对于过去更遥远的时间，因数 Bt非常小（比1小得多），并且针对接近当前时间的时间，因数at更接近等于1，因此提供了 如前所述的时间加权。
[0048] 能够被计算的另一个指标是app i的人口统计或地理多样性。 多样性指标的目的是用作对app的用户的多样性的指示，该多样性包括人口统计和地理多 样性以及可能的其他类型。通过首先将用户群划分成多个组G并且通过使用如下等式来计 算app对每个组G的渗透性P来计算app的多样性：
其中P(G)appw是对app i的组G的渗透性，η是组G中app i的用户数量，并且N 是所有组中全部用户的数量。作为示例，组G可以代表基于年龄或种族划分的人口统计组， 其中可以存在大约8-10个不同的组。组G还可以代表基于全球区域、美国区域或一些其他 地理学分区的地理学组。一旦组被定义并且其被每个app的渗透性被计算，则如下计算多 样性指标：
其中对所有组G计算求和，并且在等式3中定义渗透值P。
[0049] 能够被计算的另一个指标是app i的向上趋势指示i/ptrend^jppy丨。向上指标 的目的是用作对用户中app的活跃水平的向上或向下趋势的指示，并且其相对于所有app 的趋势被计算以便考虑到所有app使用趋势。通过首先计算每个app的活跃度在过去时间 段上的Stope (斜率)或趋势来确定app的上升趋势。Stope被定义成Jciirrty (活跃度） 指标相对于时间的斜率，并且能够通过使用线性回归或另一合适的统计技术被计算。之后 如下在一个过去时间窗口（例如过去的一个月或过去的一年）上计算上升趋势指标：
其中丨)是在该时间段上app i的人气H的均值，Slopejpp⑴是恰在上文 描述的斜率指标，是在该时间段上的所有app的平均(均值）斜率，并且t是该时间 段。
[0050] 能够通过在计算中包括app/情景相关数据来进一步精炼上述任意指标。例如，可 以针对具有后座乘客的情况计算人气。除了上述那些之外也能够想到可以由聚集和趋势跟 踪模块150基于来自许多用户和车辆的app使用、等级和情景数据来计算的其他指标。
[0051] 由聚集和趋势跟踪模块150计算的整个用户群的app使用趋势能够被用于多种目 的。通过理解处理和存储器需求、如何基于app使用模式能够改进资讯系统操作系统和人 机界面等等，车辆制造商能够使用app使用趋势数据来优化未来资讯系统设计。app使用趋 势数据也能够被给予或出售给app开发商以便帮助开发商更好地理解他们的app和同类型 其他app的使用。app使用趋势数据也能够被用于向用户做出关于下载、购买或使用某些 app的推荐。趋势数据还可以被用于给应用中的广告标价。
[0052] 图3是代表被用于跟踪车载app使用并预测app使用趋势的架构140的一种实施 例的系统160的框图。在系统160中，app使用收集模块142、交叉引用模块144、CAN总线 信息收集模块146和情景相关确认模块148被一起组合在于资讯系统102上运行的数据 收集app 162中。替代性地，模块142-148均可以是独立app或者可以以一些其他方式组 合。在任意情况下，这些数据收集和分析模块作为资讯系统102上的一个或更多个app运 行。app 162 (或者多个app)将由车辆制造商开发并且在资讯系统102上始终以后台模式 运行。
[0053] -组用户app 164也在资讯系统102上运行。用户app 164是由用户104下载并 /或购买的多个app，并且可以被任意开发商开发。用户app 164是提供用户所需的特征和 功能的app，类似于智能手机116上的那些app。即，用户app 164能够被用于例如娱乐、天 气、新闻、运动、导航、游戏等等事情。这是使用趋势跟踪所涉及的用户app 164。
[0054] 网关app 166也在资讯系统102上运行。网关app 166也由车辆制造商开发并且 在资讯系统102上始终以后台模式运行。网关app 166用作在资讯系统102与驻留在基于 云的服务器上的聚集和趋势跟踪模块150之间的双向通信接口。网关app 166的主要功能 是将app使用数据和app/情景相关数据从交叉引用模块144发送到聚集和趋势跟踪模块 150〇
[0055] app框架168驻留在资讯系统102上并且用作所有驻留app的基础。具体地，app 框架168允许用户app 164的下载和使用数据由数据收集app 162的app使用收集模块 142收集。app框架168还允许来自交叉引用模块144的app使用数据和app/情景相关数 据由网关app 166取用，该网关app 166将其发送至聚集和趋势跟踪模块150。
[0056] 图4是用于跟踪并预测车载app的使用趋势的方法的流程图180。在框182处，多 个用户app的使用数据被收集，如在app使用收集模块142的描述中所讨论的。在框184 处，通过使用等式1，针对每个用户app计算隐含用户等级。在框186处，从车辆CAN总线收 集车辆操作数据。如上文关于CAN总线信息收集模块146所讨论的，从CAN总线收集的数 据包括能够被用于确定行驶环境情景的任意车辆操作参数。在框188处，由来自CAN总线 的操作数据计算车辆操作情景指示。如上文所讨论的，情景指示指定了任意给定时间所经 历的行驶情形的类型，例如在拥堵的交通中短程单独驶向工作或者在雨天带着孩子的长途 越野路途等等。
[0057] 在框190处，app使用和等级数据以及情景指示数据被用于计算app/情景相关性， 该相关性表明针对车辆100中的用户104当app使用趋势关联于车辆情景时的app使用趋 势。如上文具体讨论的，流程图框182-190的步骤在车辆100上机载的资讯系统102内被 执行。在框192处，app使用和等级数据以及app/情景相关性被提供给服务器计算机以用 于对于许多车辆的聚集。如上文讨论的，服务器计算机可以是基于因特网的服务器或者远 程信息处理服务服务器。在框194处，从app使用数据和app/情景相关性来计算整个用户 人口群体的app使用趋势。app使用趋势包括能够被计算的各种指标，包括app人气、时间 加权的活跃度、多样性和上升趋势。app使用趋势能够被车辆制造商、app开发商等等来使 用。
[0058] 如上文讨论的，随着资讯系统app市场变得更加流行，车辆内的驾驶员或者乘客 更加难以找到他们可能最感兴趣的app。在可用app的数量(成千上万)有些势不可挡的情 况下，消费者将逐渐转向推荐引擎或其他信息源来找到相关和有用的移动应用，而不是在 移动app市场上手动挑选。如上文具体描述的从许多车辆收集到的app使用和等级数据也 能够被用作向各个用户做出app推荐的基础。
[0059] 通过使用例如用app分类进行拣选来向用户推荐其他app的技术，或者通过使用 社区网络朋友圈来推荐，现有app推荐工具仅提供初级能力。但是，