为特定用户确定电话号码优先级列表的制作方法

本公开总体涉及为特定用户确定电话号码优先级列表。

背景技术：

车辆通常配备有车载通信平台(例如，远程信息处理单元和/或信息娱乐单位)或能实现免提通话、车辆跟踪、导航指令传输以及其它类似功能的其它车载控制器。为实现免提通话，车载通信平台可以无线地连接到配对的移动通信设备。传到移动通信设备的来电呼叫可以通过车辆的音频系统接收，使驾驶员在无需接合移动通信设备的实例中能够接听电话呼叫。在一些实例中，驾驶员也可访问存储在移动通信设备上(例如，在车载显示器上)的电话簿。

技术实现要素：

在为特定用户确定电话号码优先级列表的方法的一个实施例中，响应于辨识车辆中的特定用户，车载呼叫日志应用程序将自动启动。一经启动应用程序，则为用户自动下载历史呼叫简档。历史呼叫简档包括个人车辆呼叫记录。对应于当用户在车内时所安排的去话呼叫的每个实例，使用车辆呼叫记录更新历史呼叫简档。当用户在车内时对应的预定时间增量内选中某一电话号码用于去话呼叫的概率是动态确定的。概率取决于从个体车辆呼叫记录中检索到的位置数据点。动态生成按概率排序的电话号码列表。当所述用户在车内时，使最近生成的按所述概率排序的电话号码列表显示在车辆显示器上。

附图说明

本公开实施例的特征将通过参考下面的详细描述和附图变得显而易见，其中，类似的附图标记对应于类似(虽然也许不完全相同)的部件。为简便起见，具有之前描述的功能的附图标记或特征可以或可以不结合出现它们的其它附图进行描述。

图1是用于为特定用户确定电话号码优先级列表的系统的一个实施例的示意图；和

图2是显示显示最近生成的按动态确定的概率排序的电话号码列表的车载显示器的示意图。

具体实施方式

本文所公开的系统和方法的实施例利用特定用户的历史呼叫简档来动态预测电话号码列表，当特定用户在任何车辆中时在预定时间增量内有可能选择这些电话号码进行去话呼叫。所述历史呼叫简档包括个人车辆呼叫记录，其中每个呼叫记录包括与当特定用户在车内时由他/她呼出的去话呼叫相关联的数据。在去话呼叫期间，车载呼叫日志应用程序收集诸如呼叫期间的车辆位置数据点、呼叫的时间数据点以及去话呼叫的被叫电话号码等数据。这些数据存储在历史呼叫简档中。在随后的车辆行程中，识别到特定用户在车内则下载其用户简档至车辆中。在此段行程中(并且当用户在车内时)，所述用户进行去话呼叫时，更新历史呼叫简档。同样在此段行程中，为用户提供与最近生成的预测电话号码列表，在所述用户在车内的特定时间这些电话号码是用于去话呼叫的可能候选号码。预测电话号码列表可能响应于用户的请求而生成，或可能当用户在车内时定期更新。

为特定用户提供更新的预测电话号码(这些电话号码是用于去话呼叫的可能候选号码)列表，使用户能够在无需滚动电话簿的实例中在车载显示器上选择去话电话号码。

如将在以下公开的实施例部分中所说明的，已经发现，将车辆位置数据列入车辆呼叫记录中，提高了所作出的预测的准确率，从而改善提供个性化车载服务的技术过程。历史数据可描绘特定用户从特定车辆位置呼叫特定电话号码的模式。这样，在确定电话号码被选中的概率时列入位置数据，增加了所得结果的准确率。

现在参照图1，其描绘了用于为特定用户确定电话号码优先级列表的系统10的一个实施例。系统10包括与特定用户相关联的一辆或多辆车辆12、12′、服务器14(其可能是为车辆12、12′提供后端服务的中心16的一部分)以及载波/通信系统18。

电话呼叫和/或消息(例如，下载的简档等)可传输到车辆12、12′的通信部件和使用载波/通信系统18的中心16，从通信部件和中心16传输，和/或在两者之间传输。各部件之间的一些通信链路在图1中显示为闪电符号和箭头。

在一个实施例中，载波/通信系统18是双向射频(RF)通信系统。载波/通信系统18可包括一个或多个蜂窝塔20或卫星(未示出)。应当理解的是，载波/通信系统18还可包括一个或多个基站和/或移动交换中心(Msc)22(例如，2G/3G网络)、一个或多个演进节点基站(eNodeB)和演进分组核心网(EPC)24(用于4G(LTE)网络)、和/或一个或多个陆地网络26。载波/通信系统18可以是蜂窝无线电环境或卫星无线电环境的一部分，其中可包括各种无线网络供应商(其包括移动网络运营商，未示出)，采用相同或各种无线电接入技术。虽然已经提供了几个实施例，但应当理解的是，无线载波/通信系统18的体系结构可以是GSM(全球移动通信系统)、CDMA2000、UMTS(通用移动通信系统)、LTE(长期演进技术)或一些其它可用的体系结构。

互联网连接也可用于传输消息、数据等。通过车辆的互联网连接(例如，当车辆12、12′配备有4G长期演进连接、长期演进连接或其它合适的互联网连接时)或通过移动设备的蜂窝和互联网连接(当车辆12、12′中有移动设备并且移动设备与车辆12、12′无线通信时)，利用载波/通信系统18可传输消息、数据等。

车辆12、12′可以是与特定用户相关联的小汽车、摩托车、载重汽车或休闲车(RV)。当特定用户在进入车辆12、12′时可以被识别或辨识时，所述车辆12、12′则被认为与特定用户相关联。在一些实施例中，车辆12、12′包括一些可以辨识特定用户的识别系统。在一个实施例中，可以通过其移动设备识别特定用户。当特定用户进入任何一辆车辆12、12′时，其移动设备可(经由任何短距离无线技术)无线连接到车辆12、12′的车辆通信平台(VCP)28。VCP 28可具有存储在其存储器44中的移动设备标识符(例如，电话号码、序列号等)，并且其可检索联接到存储器44中的所述移动设备标识符的用户。当VCP 28识别到多个移动设备时，VCP 28可提示车内乘员以辨识所标识的乘员中哪位是驾驶员。例如，语音提示或显示提示可表明通过其移动设备已经识别到哪些潜在驾驶员，并且要求车内乘员选择将驾驶这段行程的潜在驾驶员中的一个。可替代地，VCP 28可使用来自外围设备(例如，照相机、指纹垫、视网膜扫描仪或其它生物识别设备等)的数据，以辨识谁在驾驶座上。

在其它实施例中，车辆12、12′使用可以辨识特定用户的车外识别系统。例如，VCP 28可替代地将所识别的移动设备的移动设备标识符传输给服务器14，其使用信息来辨识特定用户。当识别到多个移动设备标识符时，VCP 28还可以将来自指示哪位是驾驶员的外围设备(例如，照相机、指纹垫、视网膜扫描仪或其它生物识别设备等)的数据传输到服务器14。在本实施例中，特定用户的身份随后由服务器14确定，并且从服务器14传输到VCP 28，从而车辆12、12′知道特定用户是谁。

特定用户可以是车辆12、12′的拥有者，或特定用户可以是车辆12、12′的授权用户，或特定用户可以之前与车辆(例如，车队车辆、出租车辆或借用车辆等)没有关联，只要车辆12、12′具有辨识使用服务器14的特定用户的能力即可。

车辆12、12′都配备有合适的硬件和计算机可读指令/代码，使其能够在载波/通信系统18上(例如，与服务器14)通信(例如，传输和/或接收语音和数据通信)。在一些实例中，车辆12、12′也能够利用短距离无线通信链路进行通信。尽管将对车辆12的部件进行更详细地描述，但是应当理解的是，其它车辆12′每辆都可以配备有相同或相似部件。

如图1所示，车辆12包括如前所述的车辆通信/通讯平台(VCP)28。在一个实施例中，VCP 28是车载车辆专用通信和娱乐设备。在另一个实施例(未示出)中，VCP 28是车载车辆专用通信设备(例如，远程信息处理单元)，并且车辆12包括分立式车载车辆专用娱乐设备(例如，信息娱乐单元)。不管是集成到单个单元(例如，VCP 28)还是被包括作为分立单元，车载车辆专用通信和娱乐设备包括能够运行计算机可读指令/代码的硬件部件，其包含在非瞬时性的有形计算机可读介质上。

既单独又通过与中心16(例如，其可以是由车载信息娱乐单元服务提供商拥有和运营的设施)通信，VCP 28都可提供多种服务。这些服务的几个实施例包括但不限于：结合位置检测模块30提供的分路段显示路线和其它导航相关服务；连同遍及车辆12的各种传感器接口模块和传感器提供的气囊展开通知和其它紧急或路边辅助相关服务；以及与信息娱乐有关的服务，其中音乐、网页、影视、电视节目、视频游戏和/或其它内容经由车辆总线系统34和音频总线(未示出)由VCP 28下载。所列服务绝不是VCP 28所有可能性的穷举性列举，而仅仅是VCP 28能够提供的一些服务的例证。

车辆总线系统32可利用多种网络协议，如控制器局域网(CAN)、面向媒体的系统传输(MOST)、本地互联网(LIN)、以太网、TCP/IP及其它适当的连接，例如符合已知ISO、SAE和IEEE标准和规格的那些连接，仅举几例。车辆总线系统32使车辆12能够从VCP 28向设备和系统的各种单元(例如，显示器48和扬声器50)发送信号(例如，实时总线消息等)。车辆总线系统32还能使车辆12在VCP 28处从设备和系统的各个单元(例如，车辆传感器(未示出))接收信号。由车辆总线32接收到的信号的一个实施例包括由服务器14接收到的历史呼叫简档。由车辆总线32传输的信号的一个实施例包括由显示器48显示的最近生成的电话号码列表。

如上所指出的，VCP 28可用于车辆通信。一些车辆通信(例如，在车辆12与中心16处的服务器14之间)利用无线电或卫星传输与载波/通信系统18建立语音信道，使得语音和数据传输均可经过语音信道发送和接收。在一些实例中，车辆通信可通过VCP 28经由通信模块34而实现，所述通信模块包括用于语音通信的蜂窝芯片组/部件36和用于数据传输的数据传输系统38。

VCP 28的蜂窝芯片组/部件36可以是模拟、数字、双模、双频、多模和/或多频带无线收发器。蜂窝芯片组-部件36使用在当前市场上用于蜂窝系统的标准模拟和/或数字频段中的一个或多个规定频率。可以使用任何合适的协议，包括数字传输技术，诸如TDMA(时分多址)、CDMA(码分多址)、W-CDMA(宽带CDMA)、FDMA(频分多址)、OFDMA(正交频分多址)等。

在一个实施例中，数据传输系统38可包括分组构建器，将其编程以决定将要发送何种分组(例如，带宽、要包含的数据等)并实际构建分组数据消息。在另一个实施例中，数据传输系统38可包括无线调制解调器，其应用某种类型的编码或调制来转换数字数据，使得其能够通过合并在蜂窝芯片组/部件36中的声码器或语音编解码器进行通信。应当理解的是，提供可接受数据速率和比特误差的任何合适的编码或调制技术都可以与本文所公开的实施例一起使用。虽然已提供了实施例，但应当理解的是，可以使用任何合适的数据传输系统38。

还可以将VCP 28配置用于短距离无线通信技术，诸如及其各种类型、专用短距离通信(DSRC)或WI-FI^TM及其各种类型。

位置检测单元30可包括GPS接收机、无线电三角测量系统、航位推算定位系统和/或其组合。具体地，GPS接收器响应于从GPS卫星星座(未示出)接收的GPS广播信号提供准确时间以及车辆12的纬度和经度坐标。位置检测单元30还可以包括，例如，Glonass(即，全球导航卫星系统)、Sbas(即，基于卫星的增强系统)或D-GPS(差分式全球定位系统)。位置检测芯片组/部件30可以是或可以不是车载导航单元的一部分。

VCP 28还可包括实时时钟(RTC)40。实时时钟(RTC)40提供准确的日期和时间信息给可能需要和/或请求日期和时间信息的VCP 28硬件和软件部件。在一个实施例中，RTC 40可为从车辆12呼出的任何去话呼叫提供时间和/或日期信息。

VCP 28还包括电子处理设备42，其可操作地耦合到一种或多种类型的电子存储器44。在一个实施例中，电子处理设备42是微处理器。在其它实施例中，电子处理设备42可以是微控制器、控制器和/或主机处理器。在另一个实施例中，电子处理设备42可以是专用集成电路(ASIC)。VCP 28的电子存储器44可以是加密存储器，其被配置为存储i)将由处理器42执行的呼叫日志应用程序46、ii)与车辆12的各种系统相关联的数据(即，车辆数据、VIN等)等等。电子存储器44可以是非瞬时性的有形计算机可读介质(例如，RAM)。

在本文所公开的实施例中，响应于在车辆12或12′内识别到的特定用户，可自动启动呼叫日志应用程序46。当用户在车辆12内时，呼叫日志应用程序46收集与从车辆12、12′呼出的去话呼叫相关的数据，以便为特定用户建立历史呼叫简档。当用户在车辆12或12′内时，呼叫日志应用程序46还使用历史呼叫简档为特定用户确定电话号码优先级列表。车辆12、12′每辆的呼叫日志应用程序46与服务器14通信，从而接收当时当前在车辆12、12′内识别的用户的特定信息，并且也可基于特定用户调整其输出。

一经启动，可将呼叫日志应用程序46编程为监测来自车辆12或12′的去话呼叫活动(即，使用VCP 28呼出的呼叫)。当特定用户在车辆12或12′内时，呼叫日志应用程序每秒对去话呼叫活动进行监测。用户从VCP 28呼出去话呼叫时，呼叫日志应用程序46识别出呼叫正在呼出，并收集与特定去话呼叫相关联的数据。

对于每个去话呼叫，呼叫日志应用程序46收集至少一部分去话呼叫期间车辆12或12′的位置(即，车辆位置数据点)、去话呼叫的时间/日期(即，时间/日期数据点)以及去话呼叫的被叫电话号码(即，什么号码正在/已经被呼叫)。

可以在呼叫日志应用程序46处从位置检测单元30中接收车辆位置数据点。车辆位置数据点可包括车辆12、12′的纬度数据点、车辆12、12′的经度数据点、车辆12、12′的高程数据点或其组合。位置检测单元30可包括用于计算位置数据点的容许误差值。可以在一次去话呼叫期间接收/收集若干次车辆位置数据点。可能希望的是在一次去话呼叫期间接收/收集多个车辆位置数据点，因为当呼叫正在进行时车辆12、12′可能在移动中。在一个实施例中，可由位置检测单元30接收持续时间为5秒至30秒的去话呼叫中每秒车辆位置数据点。在此实施例中，呼叫日志应用程序46为一次去话呼叫接收5个车辆位置数据点(例如，如果每秒接收一个位置数据点，持续5秒钟)到90个车辆位置数据点(例如，如果每秒接收三个位置数据点，持续30秒钟)。为一次去话呼叫收集多个位置数据点有助于提高随后由呼叫日志应用程序46所做预测的准确率。应当理解的是，车辆位置数据点可以在去话呼叫的5秒到30秒的任意时长内进行收集(例如，在第1秒到第5秒处、第5秒到第35秒处等)。如果数据收集完成之前结束(例如，在30秒之前)呼叫，将利用收集到的任一数据。

日期/时间数据点可从实时时钟(RTC)40处接收。日期/时间数据点可包括呼出去话呼叫的日历日和/或呼出去话呼叫的当天的某个时间。当天的所述某个时间可以是小时(例如，1-24)、或小时和分钟、或小时、分钟和秒钟。如果若干车辆位置数据点得以收集，相应地，也可收集日期/时间数据点。

可以收集数据，直到持续时间结束和/或直到去话呼叫完成，以先发生者为准。

收集一次去话呼叫的数据以后，呼叫日志应用程序46为此次去话呼叫生成车辆呼叫记录。车辆呼叫记录包括数据点(即，位置和时间/日期数据点)和被叫电话号码。车辆呼叫记录还辨识特定用户。这使得服务器14能够更新特定用户的历史呼叫简档。以下将更详细地描述服务器14。

应当理解的是，呼叫日志应用程序46将为由特定用户在车辆12、12′内时所呼出的每次去话呼叫收集数据并生成车辆呼叫记录。在一段行程中(即，从上车到下车)，可呼出任意数量的去话呼叫并生成任意数量的相应车辆呼叫记录。

呼叫日志应用程序46将车辆呼叫记录传输到服务器14以便将其存储在特定用户的历史呼叫简档中。呼叫日志应用程序46利用VCP的通信模块34来传输车辆呼叫记录。在车辆数据上传事件期间，通信模块34将车辆呼叫记录作为分组数据传输到服务器14。车辆呼叫记录生成后，可立即对其进行传输，或者一次驾驶事件期间的所有车辆呼叫记录可在事件结束时(其由车辆发动机被关闭动力、被关闭等发信号指示)一并进行传输。

其后任何时间，特定用户进入车辆12、12′或能够识别他/她并配备有呼叫日志应用程序46的另一辆车，对应的呼叫日志应用程序46为当特定用户在车辆12、12′内时所呼出的去话呼叫的每个实施例收集数据，并生成相应的车辆呼叫记录。这样，用户的历史呼叫简档得以定期更新，不管他/她正在使用何种车辆12、12′。更新历史呼叫简档的功能可与由呼叫日志应用程序46执行的其他功能(例如，在后台)同时执行。

呼叫日志应用程序46还能使用特定用户的历史呼叫简档为特定用户生成电话号码优先级列表。

当辨识到用户在车辆12、12′内(如前文所述)并且作为响应呼叫日志应用程序46启动时，将特定用户的历史呼叫简档自动下载到呼叫日志应用程序46中。VCP 28辨识特定用户后，服务器14可响应于来自VCP 28的请求自动下载所述历史呼叫简档。该请求可包括特定用户的身份。服务器14辨识特定用户后，服务器14可将历史呼叫简档连同特定用户的身份传输到呼叫日志应用程序46。

在一个实施例中，呼叫日志应用程序46(例如，通过在用户界面52处的用户输入)从用户接收对优先级列表的请求。在另一个实施例中，当用户在车辆12、12′内时，呼叫日志应用程序46可定期更新优先级列表(例如，以预定时间间隔)。

为了为特定用户生成电话号码优先级列表，呼叫日志应用程序46动态确定当特定用户在车辆12、12′内时在预定时间增量内选择某一特定电话号码进行去话呼叫的概率。概率取决于历史呼叫简档中来自车辆呼叫记录的所有数据。在本文所公开的实施例中可增加概率和与概率成正比的准确率，因为考虑到的数据包括在先的去话呼叫呼出时车辆12、12′的位置以及这些去话呼叫呼出的日期/时间。如上所述，任一条车辆呼叫记录的位置数据可包括多达90个位置数据点(即，为时长30秒的呼叫收集的3种不同类型的位置数据)。

呼叫日志应用程序46在预定时间帧内(例如，当前日期之前的2周、3个月等)从呼叫记录数据中检索数据。预定时间帧是窗口期，在此期间，认为历史呼叫数据适用于为用户行为建模。如果用户经常呼出去话呼叫相同的号码，窗口期可能短于用户很少呼出去话呼叫的情况。呼叫日志应用程序46可能会根据特定用户的历史呼叫简档自动更新窗口期。此外，认为此窗口期之外的所有数据是过时的并且不会被呼叫日志应用程序46检索以供使用。呼叫日志应用程序46还可标记任何过时的车辆呼叫记录，并且服务器14可丢弃来自特定用户的历史呼叫简档的这些特定记录。

通常，呼叫日志应用程序46在要求的时间或当用户在车内时根据预定时间表将概率与候选呼叫联系人(其由特定用户的历史呼叫简档所确定)相关联。

更具体地，呼叫日志应用程序46利用检索到的数据作为训练数据用于训练机器学习算法并用于构建预测模型。预测模型是针对给定数据的机器学习算法的产物。机器学习算法不使用任何前瞻性数据来建立预测模型并进行预测。在一个实施例中，机器学习算法是C4.5或J48(即，C4.5算法的开放源码的Java实现)，两者中的每一个均从训练数据中构建决策树。其它合适的机器学习算法包括随机森林、Hoeffding树、改良等等。使用决策树、机器学习算法以及从其中构建的预测模型，可以对未知实例进行分类(即，预测当用户在车辆12、12′内时在给定时间选中电话号码用于去话呼叫的概率)。预测模型的输出是预测分类器。在本文所公开的实施例中，预测分类器是当特定用户在车辆12、12′内时在特定实例中可能被呼叫的预测电话号码的优先级列表。

在一个实施例中，为从历史呼叫简档分析出的数据中的每个电话号码生成概率。预定数量(例如，1至5或1至10)的可能电话号码，可包括在列表中。这样，列表中的每个电话号码与选中特定号码用于去话呼叫的概率相关联。电话号码按概率排序，概率最大的号码在列表顶部。列表还可包括每个预测电话号码的误差分布。

呼叫日志应用程序46可动态确定在预定时间增量内某一特定电话号码被选中用于去话呼叫的概率。这样，在预定时间增量结束时，呼叫日志应用程序46从历史呼叫简档(如果用户已经从车辆12、12′中呼出了去话呼叫，其可进行最新更新)中检索数据，并且运行预测模型以便为下一个预定时间增量更新预测电话号码的优先级列表。对于特定用户在车辆12、12′内的每个预定时间增量，重复此过程。在一个实施例中，预定时间增量是特定用户在车辆12、12′内的每分钟。在本实施例中，预测电话号码的优先级列表将每分钟进行更新。在另一个实施例中，预定时间增量是特定用户在车辆12、12′内的每7秒。

并不是定期更新优先级列表或在定期更新之间的某一时间点上，当接收到来自车辆乘员的请求时，呼叫日志应用程序46可动态确定某一特定电话号码被选中用于去话呼叫的概率。

呼叫日志应用程序46命令显示器48显示概率最大的电话号码。通常，显示1至10个电话号码，并且所显示的电话号码至少具有10％的概率在预定时间增量内被选中用于去话呼叫。每个电话号码的概率独立于其他每个电话号码的概率。显示器48可以描绘电话号码、与特定号码相关联的任何名称以及选中号码可能用于去话呼叫的预测时间。图2示出了一个实施例，其中，在下午4：30，日托(DC)的电话号码最有可能被选中进行去话呼叫，其次是泰国餐馆(TR)的电话号码以及J的办公室(JO)电话号码，并且在下午5：00，家庭(H)电话号码最有可能被选中进行去话呼叫。这些号码在给定时间和在车辆当时当前位置处被选中用于去话呼叫的概率最高，其中所述概率基于特定用户的历史呼叫数据。

在一些实施例中，由于当用户在车辆12、12′内时每一时间增量更新优先级列表，显示器48可不断变化。然而，如果优先级列表从一个时间增量到下一个时间增量不发生变化，显示器48将保持先前显示的电话号码列表，但也可以更新可能选择号码的预测时间。在其它实施例中，响应于用户请求更新优先级列表，从而当接收和处理请求时将更新优先级列表。

在一个实施例中，显示器48是全彩色触摸屏显示器。显示器48的其它实施例包括VFD(真空荧光显示器)、LED(发光二极管)显示器、LCD(液晶二极管)显示器和/或其类似物。在一个实施例中，扬声器50是如1图所示的用户界面52的扬声器。在其它实施例中，扬声器50可以是独立扬声器或车辆扬声器(未示出)。

显示器48可以是用户界面52的一部分。用户界面52可操作地连接到车辆总线系统32。用户界面52允许特定用户向车辆12输入信息和命令(例如，呼叫日志应用程序46)并从车辆12接收信息(例如，从呼叫日志应用程序46接收优先级列表)。用户界面52可以是任何命令驱动的用户界面或菜单驱动界面。在一个实施例中，用户界面52是图形用户界面(GUI)。在另一个实施例中，用户界面48是人机界面(HMI)。如图1所示，除显示器48之外，用户界面48还可包括扬声器50。用户界面52还可以包括麦克风(未示出)。

用户界面52可协助VCP 28提供各种服务。这些服务的一个实施例包括允许特定用户从显示的最近生成的电话号码列表中选择呼叫的用户界面52。作为实施例，特定用户可点击他/她想在用户界面52拨打的显示的电话号码或与其相关联的名称。电话号码随后被传输到VCP 28蜂窝芯片组/部件36，从而开始拨打用户选中的电话号码。

系统10还包括前文提到的服务器14。如图1所示，服务器14可以位于为车辆12、12′提供后端服务的中心16处。服务器14可以是参与服务呼叫日志应用程序46的专用服务器。例如，服务器14通过存储最新的历史呼叫简档并将历史呼叫简档提供给特定用户当时当前所处的车辆12、12′来协助为特定用户确定电话号码优先级列表。

当接收到车辆呼叫记录，服务器14将呼叫记录与特定用户的简档进行匹配，并用呼叫记录更新特定用户的历史呼叫简档。还将服务器14编程以删除任何过时的呼叫记录(即，不再对机器学习算法和预测模型有用的过时记录)。

当接收到请求，将服务器14编程以通过辨识特定用户(通过在请求中所接收到的移动设备标识符)并检索特定用户的历史呼叫简档或通过检索在请求中所标识的特定用户的历史呼叫简档对所述请求作出响应。

服务器14是计算机硬件系统(例如，中央处理单元54)和计算机可读指令，其能够接收和存储车辆呼叫记录，并且其能够响应从呼叫日志应用程序46中接收到的请求。中央处理单元54可以是控制器、主处理机或ASIC。中央处理单元54能够执行存储在中央服务器14的电子存储器56上的呼叫日志应用程序的计算机可读指令。

服务器14可接收车辆呼叫记录和/或来自车辆12、12′的请求，和/或通过载波/通信系统18传输数据(例如，特定用户的历史呼叫简档)。更具体地，服务器14还包括与VCP 28选择性通信的服务器通信收发器58。服务器通信收发器58可以是能够发送和/或接收载波/通信系统18上的数据通信的任何适当的数据传输系统。例如，服务器通信收发器58能够接收车辆呼叫记录和来自呼叫日志应用程序46(以及VCP 28)的请求，并且能够将特定用户的历史呼叫日志(单独或与特定用户的身份组合)传输回呼叫日志应用程序46。

除服务器14之外，中心16还可包括其他部件，如附加计算设备60、交换机62、顾问(未示出)、数据库64以及网络连接或总线68。

中央计算设备60，其往往结合电信设备(未示出)一起使用，通常配备有合适的硬件和软件和/或使计算设备硬件60能够完成各种中心功能的程序。可将计算设备60编程以执行中心16的一些任务/操作。电信与计算设备60可包括服务器网络(包括服务器14)，网络耦合到任何信息处理的本地存储的及远程的数据库(例如，数据库64)。

中心16还可包括交换机62。交换机62可以是专用小交换机(PBX)。交换机62路由输入信号，使得语音传输通常可发送到现场顾问或自动响应系统，并且数据传输得以传递给调制解调器或其它设备(例如，通信模块)以进行解调及进一步信号处理。调制解调器可包括编码器，并且其可连接到诸如服务器14和数据库64的各种设备。

中心16还包括现场和/或自动顾问(未示出)。每个顾问可与工作站相关联，工作站包括电信与计算机设备60。

可将中心16处的数据库64设计为存储车辆记录、订户/用户简档记录(包括历史呼叫简档)或任何其他相关订户和/或车辆信息和/或移动设备信息。在一个实施例中，可将数据库64配置为存储用户简档，其可包含订户/用户14的个人信息(例如，用户姓名、车库/家庭住址、帐单地址、家庭电话号码、便携式电话号码/移动拔号号码等)、他/她的历史呼叫简档等等。服务器14可利用数据库中的信息来确定呼叫日志应用程序46正试图辨识哪位特定用户和/或哪一历史呼叫简档与所辨识的特定用户相关联。

应当理解的是，数据库64可允许中心16充当从车辆12、12′中收集到的数据的存储库。在一些实例中，另一设施可充当收集到的数据的存储库(例如，与服务器14或顾问可访问其数据库的中心16相关联的客户关系管理系统(未示出))。

如图1所示，各个呼叫中心部件经由网络连接或总线68彼此耦合，这可类似于前文所述的车辆总线32。

应当理解的是，中心16可以是任何中央或远程设施，有人或无人、移动或固定，期望向其上或从其中交换语音和数据通信。这样，现场顾问可以是实际位于中心16处或者可以当通过中心16进行通信时位于远离中心16处。

也可将如图1所示的中心16虚拟化并且配置在云计算机内，也就是说，在基于因特网的计算环境中。例如，计算机设备60可以作为云平台服务或PaaS(平台即服务)进行访问，其利用云计算基础设施而不是在中心16处的主存计算机设备60。也可将数据库64和服务器14虚拟化为云资源。被称为IaaS(基础设施即服务)的云基础设施通常利用平台虚拟化环境作为一种服务，其可包括诸如计算设备60、数据库64、服务器14以及其它计算机设备的部件。在一个实施例中，本文所公开的确定特定用户的身份和/或检索历史呼叫简档可经由SaaS(软件即服务)在“云”端执行。

为了进一步说明本公开内容，特提供如下实施例。应当理解的是，这些实施例仅用于说明的目的，并不应当解释为对本公开范围的限制。

实施例

实施例1-4说明了：当利用7个属性(包括各种位置数据点)时以及当利用不到7个属性的不同组合时预测准确率的差异。这些实施例说明了：当利用位置数据点属性时，预测准确率显著提高，更具体地，当7个属性(GPS纬度、GPS经度、高程、月、日、时、去话呼叫的号码)被用作预测的训练数据时。

实施例1

根据十折交叉验证利用所有7个属性执行以下预测准确率结果，所述十折交叉验证如下列混淆矩阵1所示。

十折交叉验证：数据随机分为10份，其中类表示为与完整数据集和在其余十分之九所训练的学习方案大致相同的比例。学习过程针对不同的训练集总共执行10次。

混淆矩阵：在多类预测中，测试集的结果可显示为每类的行和列。每个矩阵元素显示测试例的数目，其中，实际的类是行，而预测的类是列。优良结果对应于主对角线下方的较大数字以及较小的(理想为零)非对角元素。

混淆矩阵1

如在混淆矩阵1中所说明的，当使用7个属性时，正确分类实例2353例(99.619％)，错误分类实例9例(0.381％)。

实施例2

根据十折交叉验证利用4个属性(GPS纬度、GPS经度、小时、去话呼叫号码)执行以下预测准确率结果，所述十折交叉验证如下列混淆矩阵2所示。

混淆矩阵2

如在混淆矩阵2中所说明的，当仅使用4个属性时，正确分类实例2283例(96.6554％)，错误分类实例79例(3.3446％)。

实施例3

根据十折交叉验证利用4个属性(月、日、小时、去话呼叫号码)执行以下预测准确率结果，所述十折交叉验证如下列混淆矩阵3所示。

混淆矩阵3

如在混淆矩阵3中所说明的，当使用4个非位置数据点属性时，正确分类实例1684例(71.2955％)，错误分类实例678例(28.7045％)。通过比较实施例2和实施例3的结果，很显然，位置数据点(在实施例2中使用，而在实施例3中没有使用)显著提高了预测的准确率。

实施例4

根据十折交叉验证利用4个属性(GPS纬度、GPS经度、高程、去话呼叫号码)执行以下预测准确率结果，所述十折交叉验证如下列混淆矩阵4所示。

混淆矩阵4

如在混淆矩阵4中所说明的，当使用3个位置数据点属性时，正确分类实例2254例(95.4276％)，错误分类实例108例(4.5724％)。

通过比较实施例1-4的结果，很显然，时刻和位置数据点属性的组合(实施例1和实施例2)得到用于获得精确预测的最佳组合。

实施例5

在此实施例中，生成了两个混淆矩阵。混淆矩阵图5是数据测试集的交叉验证结果，在数据测试集中，为每一次呼叫收集一个数据点。混淆矩阵图6是数据测试集的交叉验证结果，在数据测试集中，为每一次呼叫收集5至30个位置数据点。对于混淆矩阵5，150多个呼叫的预测准确率为33.1％。优良结果对应于主对角线下方的数字。对于混淆矩阵6，仅少数几个呼叫的预测准确率为99.69％。

应当理解的是，如本文所用的术语“通信”应当解释为包括所有形式的通信，包括直接和间接通信。间接通信可包括两个部件与位于其间的附加部件的通信。

进一步地，术语“连接/被连接/联接”和/或其类似形式在本文中被广泛定义为涵盖多种不同的连接设置方式和组装技术。这些设置方式和技术包括但不限于：(1)一个部件与另一部件之间(两者之间没有中介部件)的直接通信；以及(2)一个部件与另一部件(两者之间有一个或多个部件)的通信，只要所述一个部件“连接到”另一部件便是以某种方式与其它部件进行可操作地通信(即使其间存在一个或多个附加部件)。

整个说明书中提及的“一个实施例”、“另一个实施例”、“实施例”等是指与实施例有关所描述的特定元素(例如，特征、结构和/或特性)被包括在本文所描述的至少一个实施例中，并且可存在或可不存在于其他实施例中。此外，应当理解的是，除非上下文另有明确说明，针对任何实施例所描述的元素可以在各个实施例中以任何适当的方式进行结合。

应当理解的是，本文所提供的范围包括所述范围以及所述范围内的任何值或子范围。例如，5秒至30秒的范围应当解释为包括明确表述的界限5秒至30秒以及单独的值(例如，6秒、15秒、23秒等)和子范围(例如，约8秒至约25秒、约10秒至约40秒等)。

在描述和要求保护本文所公开的实施例时，除非上下文另有明确说明，单数形式“一个”、“一种”以及“所述”也包括复数个的指代物。

虽然已经对一些实施例进行了详细描述，但应当理解的是，可对所公开的实施例进行修改。因此，以上描述应当被认为是非限制性的。