改进关连的机动车的用户体验的制作方法

改进关连的机动车的用户体验的制作方法
【专利摘要】提供了用于在车辆中发起至少一个处理的方法、装置和计算机程序产品。所述装置确定车辆的近似位置。另外，所述装置基于所确定的近似位置来确定在此期间所述车辆的一个或多个注册司机接近所述车辆的最短时间段。此外，所述装置基于所确定的时间段来确定是否要在所述车辆中发起至少一个处理。
【专利说明】改进关连的机动车的用户体验

【技术领域】
[0001]概括地说，本公开内容涉及自动控制系统，具体地说，本公开内容涉及车辆控制系统。

【背景技术】
[0002]车辆已经包含了诸如报警系统、车载调制解调器、音乐娱乐系统、导航系统等更多的电子系统。由于这些电子系统的需求，用于为这些电子系统供电的电池已经变得紧张。除了功率需求，这些电子系统具有针对更新和维护的时间需求。存在对改进关连的机动车关于更新、维护和供电的用户体验的需求。


【发明内容】

[0003]在本公开内容的一个方面，提供了一种方法、计算机程序产品和一种装置。所述装置确定车辆的近似位置。另外，所述装置基于所确定的近似位置来确定在此期间所述车辆的注册司机接近所述车辆的最短时间段。此外，所述装置基于所确定的时间段来确定是否要在所述车辆中发起至少一个处理。

【专利附图】

【附图说明】
[0004]图1示出了注册司机到达车辆的行进时间。
[0005]图2示出了正在接收位置信息的车辆。
[0006]图3示出了用于确定位置信息的时序。
[0007]图4示出了不同类型的处理。
[0008]图5示出了基于可用电池电量来确定是否要发起至少一个处理。
[0009]图6示出了用于确定是否要发起至少一个处理的信息。
[0010]图7是一个示例性实施例的流程图。
[0011]图8是另一个示例性实施例的流程图。
[0012]图9是向车辆注册司机的流程图。
[0013]图10是示出了在一个示例性装置中的不同模块/单元/组件之间的数据流的概念数据流图。
[0014]图11是示出了另一个示例性装置中的不同模块/单元/组件之间的数据流的概念数据流图。
[0015]图12是示出了针对采用处理系统的装置的硬件实施方式的一个例子的示图。
[0016]图13是示出了针对采用处理系统的另一装置的硬件实施方式的另一例子的示图。

【具体实施方式】
[0017]以下结合附图所阐述的详细描述旨在作为对本发明的各种配置的描述，而不旨在表示可以实践本文中所描述的概念的唯一配置。所述详细描述包括出于提供对各种概念的透彻理解目的的特定细节。然而，对于本领域技术人员来说将显而易见的是，可以在不具有这些特定细节的情况下实践这些概念。在一些实例中，以框图形式示出公知的结构和组件，以避免模糊这些概念。
[0018]现将参照各种装置和方法来呈现控制系统的若干方面。这些装置和方法将在下面的详细描述中描述并通过各种框、模块、组件、电路、步骤、处理、算法等(统称为“要素”)在附图中示出。可以使用电子硬件、计算机软件或它们的任意组合来实现这些要素。这些要素是实现为硬件还是软件取决于具体应用和对整个系统施加的设计约束。
[0019]举例而言，可以利用包括一个或多个处理器的“处理系统”来实现要素，或要素的任何部分，或要素的任意组合。处理器的例子包括被配置为执行贯穿本公开内容所描述的各种功能的微处理器、微控制器、数字信号处理器(DSP)、现场可编程门阵列(FPGA)、可编程逻辑设备(PLD)、状态机、门逻辑、分立硬件电路和其它适当硬件。所述处理系统中的一个或多个处理器可以执行软件。无论被称为软件、固件、中间件、微代码、硬件描述语言还是其它，软件应当被广义地解释为意味着指令、指令集、代码、代码段、程序代码、程序、子程序、软件模块、应用、软件应用、软件包、例程、子例程、对象、可执行程序、执行的线程、过程、函数等。
[0020]因此，在一个或多个示例性实施例中，所描述的功能可以在硬件、软件、固件或其任意组合中实现。如果在软件中实现，则功能可以作为一个或多个指令或代码存储在计算机可读介质上或被编码为计算机可读介质上的一个或多个指令或代码。计算机可读介质包括计算机存储介质。存储介质可以是可以由计算机存取的任何可用介质。通过示例而非限制的方式，这种计算机可读介质可以包括RAM、ROM、EEPROM、CD-ROM或其它光盘存储器、电子盘存储器、磁盘存储器或其它磁存储设备，或可以用于携带或存储具有指令或数据结构形式的期望的程序代码并可以由计算机存取的任何其它介质。如本申请中所使用的，磁盘和光盘包括压缩光盘(CD)、激光光盘、光盘、数字多功能光盘(DVD)、软盘和蓝光盘，其中，磁盘通常磁性地复制数据，而光盘则用激光来光学地复制数据。上述的组合也应当包括在计算机可读介质的保护范围之内。
[0021]图1示出了注册司机到达车辆的行进时间。车辆110可以确定所述车辆110的近似位置。接下来，车辆110确定车辆110的注册司机130在此期间接近所述车辆110的最短时间段。车辆110可以使用所述最短时间段来确定是否要发起至少一个处理180。在图1中示出的例子中，车辆I1可以与注册作为车辆110的拥有者的注册司机130相关联。如图所示，注册司机130位于远离车辆110的远端位置170，比如岛屿。为了注册司机130到达车辆110，注册司机130可以使用任意数量的行进模式，包括通过水路、航空和陆路来行进。例如，注册司机130可以通过公共交通、步行、骑自行车或其它交通方法来行进。行进时间可以包括多个行进路线，比如通过航空140行进的路线152和通过陆路120行进的路线154，或通过水路142行进的路线158和通过陆路120行进的路线154。各种行进模式可能具有不同的行进时间和固有的行进延迟。在图1中示出的例子中，注册司机130可以通过航空140或水路142行进以到达车辆110。对于通过航空140的行进，注册司机130可能需要到机场的额外的行进方式和延迟(例如路线150)以登上飞机。对于通过水路142的行进，注册司机130可能需要到渡口的另一路线156以便登上远洋船舶。通过航空140行进的固有行进延迟可能包括在机场、屏蔽检查、海关检查等处的延迟。天气也造成了固有延迟。通过海路142行进的固有延迟可能包括在渡口处的延迟和天气延迟。在图1中，通过航空140行进可能需要7个小时，加上针对天气延迟144的4个小时，总的航空行进为11个小时,而通过海路142行进可能需要10个小时，加上天气延迟146的3个小时，总的海路行进为13个小时。即使通过航空140的行进具有较长的固有延迟，但是总的航空行进时间比总的海路行进时间要短。第二段行程包括通过陆路120行进的路线154以便注册司机130到达陆地120。通过陆路120的行进也可能包括固有延迟，比如交通延迟148。交通延迟148可能包括I个小时的交通拥堵。所述行进时间可能受到一天之中的时间的影响。在白天时，有更多行进模式可用，但是某些类型的延迟可能更普遍。例如，高峰时间期间的交通延迟在白天期间是普遍的，而较低的限速在夜间期间可能是普遍的。行进时间可能以其它方式受到一天之中的时间的影响，包括注册司机的行进可用性。例如，注册司机130可能在夜间期间睡觉而无法行进。
[0022]在图1中示出的例子中，注册司机130在此期间接近车辆110的最短时间段可以是通过路线150、152和154的20个小时。所述车辆可以使用所确定的最短时间段来确定是否要发起至少一个处理180，使得在注册司机130到达车辆110之前完成所述至少一个处理180。例如，车辆可能具有需要9个小时的软件更新处理、需要12个小时的数据同步处理，以及需要21个小时的系统自检。在一个方面中，所述车辆可以确定这三个处理可以并行(例如，同时)执行。所述车辆可以确定要发起软件更新处理和数据同步处理，因为这两个处理可以同时地执行并且将在注册司机130到达车辆110之前完成。车辆110可以确定不执行系统自检，即使是在并行执行所述处理的情况下，因为系统自检将无法在注册司机130到达车辆110之前完成。在另一个方面中，车辆110可以确定这三个处理必须串行执行(例如，一个接一个)。因此，车辆110可以确定仅要发起软件更新处理或数据同步处理中的一个并且确定不执行系统自检，因为系统自检将无法在注册司机130到达车辆之前完成。
[0023]图2示出了接收位置信息的车辆。车辆110可以确定其近似位置和注册司机130的位置，以便用于确定是否要发起至少一个处理180。在图2的例子中，车辆110可以接收针对其自身位置和针对注册司机130的位置的位置信息216。例如，车辆110可以使用来自GPS卫星240的全球定位系统(GPS)位置信息216来确定其自身的位置。注册司机130可以使用移动设备220来确定位置信息210。可以例如通过GPS卫星240来提供位置信息210。其它确定位置的方法是可能的。举例而言，移动设备220可以通过基于陆地的接入点来接收位置信息，并且通过与附近的接入点的接近度或通过多个接入点的三角定位来确定位置。在移动设备220已经确定了其位置信息之后，移动设备220可以向接入点230发送所述位置信息212。在另一个实施例中，移动设备220可以向接入点230发送不包括位置信息的信号，并且所述接入点230确定移动设备220的近似位置。接入点230可以向车辆110发送注册司机130的位置信息214。车辆110可以基于所接收的注册司机130的位置信息和车辆自身的位置信息来确定在此期间注册司机130接近车辆110的最短时间段。可以基于位置信息来确定最短时间段，例如如图1中所描述的。
[0024]在一个配置中，车辆110可以通过从注册司机130接收到的信号218来确定注册司机130是否接近车辆110。例如，车辆110可以监听(overhear)信号(例如，在上行链路上向服务基站发送的信号、蓝牙信号、WiFi信号)或接收到从注册司机130所携带的移动设备220发送的专用信号(即，专门向车辆110发送的信号)。基于接收到的信号类型，车辆110可以确定注册司机130距离车辆110的潜在范围。车辆110可以通过其它方式(比如视觉检测)来确定注册司机130的接近度。例如，耦合到车辆110的摄像头可以捕获注册司机130的图像，并且车辆110可以通过面部识别来确定注册司机130正在接近。所述摄像头不是必须耦合到车辆110。例如，车辆可以监控由具有已知位置的摄像头捕获到并上载到互联网的图像。如果车辆110确定注册司机130在那些图像中的任何图像中，则车辆110能够基于所述摄像头的已知位置来确定注册司机130到车辆110的接近度。
[0025]图3示出了用于确定位置信息的时序。注册司机的位置信息可以用于确定所述注册司机在此期间接近所述车辆的近似位置的最短时间。位置信息在时间线上示出(用时间t进行标记)。在车辆从注册司机接收位置信息或请求位置信息时,时间310、312、314、316、318、320、322、324可以包括相等的时间间隔或可以包括不相等的时间间隔。所述时间间隔可以是预先确定的间隔或基于触发器。例如，在时间310、312处，注册司机可能正在驾驶车辆，并且在时间314处，将车辆停在家。在时间316处，注册司机可能离开车辆到另一个位置。在时间318处，注册司机可能前往参加工作上调度的会议，而在时间320处，前往商务旅行。在时间322处，注册司机可能返回工作并开始返回车辆。所述注册司机可能在时间324到达车辆。在车辆已经停止(314)之后，车辆可以请求注册司机的位置。车辆还可以以预定的间隔确定其自身的位置。在接收到注册司机的位置(在时间316处的司机位置I)之后，车辆可以确定在此期间注册司机接近所述车辆的最短时间段。车辆可以在接收到注册司机的后续位置(分别是时间318、320、322、324处的司机位置2、3、4、5)之后更新所确定的最短时间段。车辆可以确定在时间316、318、320处，所述注册司机分别大概有4、6和30小时的距离。车辆可以确定系统自检处理需要21个小时。在时间316、318处，车辆可以确定不发起系统自检处理，因为所述处理无法在注册司机回到车辆110之前完成。但是，在时间320处，车辆可以确定要发起系统自检处理，因为所述处理可以在注册司机回到车辆110之iu完成。
[0026]图4示出了不同类型的处理。当确定是否要发起至少一个处理时，可以将所确定的最短时间段与完成至少一个处理的时间段进行比较。例如，在第一处理类型中(本文中称为“用户临近(user-approach) ”处理401)，所述时间段可以是用于完成所述至少一个处理的阈值时间段。也就是说，当确定是否要发起所述至少一个处理时，可以将所确定的最短时间段与用于完成所述至少一个处理的阈值时间段进行比较。用户临近处理可以是在注册司机到达车辆之前很短时间发起的处理。所述用户临近处理可以为了注册司机的舒适而被发起并且可以基于注册司机的偏好。例如，注册司机可能期望车厢冷却至六十度或加热到八十度。再举一个例子，注册司机可能希望在所述注册司机到达车辆之前车窗降到一半。又举一个例子，注册司机可能希望在所述注册司机到达车辆之前一分钟时车内灯光打开/关闭、门开锁，并且引擎/发动机启动。用户临近处理可以包括可以在所述注册司机到达车辆之前很短时间发起的其它处理，比如加热或冷却车辆电池。可以基于发起所述至少一个处理所需的必要时间量来确定阈值时间段。所述阈值时间段可以基于优选时间。例如，如果注册司机希望在他/她到达车辆之前60秒时车窗降下来，则所述阈值时间段可以是60秒。在另一个例子中，车辆可以确定满足偏好所必须的阈值时间段。例如，如果当前内部温度是100度，则为了将车厢冷却至六十度，车辆可以确定所述阈值时间段为15分钟。如果所述车辆确定注册司机还有60分钟的距离，则车辆可以休眠或等待45分钟。在45分钟之后，车辆可以基于注册司机的更新的位置来重新计算注册司机到达车辆的最短时间段。例如，车辆可以确定最短时间段为10分钟，并且发起冷却将车厢冷却至68度。
[0027]第二处理类型(本文中称为“选择的”处理402)可以包括在从一组处理中选择一个处理的情况下的处理。例如，车辆可以基于可用时间量(即，最短时间段)来执行系统更新405。当较少时间可用时，车辆可以执行增量的或紧急的系统更新。当较多时间可用时，车辆可以执行完全更新。对于选择的处理402，车辆可以基于最短时间段来确定要发起所述组中的哪一个处理。举另一个例子，车辆可以基于可用时间量(最短时间段)对车辆电池407充电并选择一个电池充电速度。当较多时间可用时，该车辆可以发起较慢的但是更完全的电池充电(例如，需要6个小时)。当较少时间可用时，车辆可以发起较快的电池充电(例如，需要4个小时)。在这个例子中，如果车辆确定最短时间段是7个小时，则车辆可以选择发起需要6个小时的较慢的电池充电。
[0028]第三处理类型(本文中称为“混杂”处理403)可以包括未包括在用户临近处理和选择的处理中的所有其它处理。混杂处理可以包括例如固件更新、GPS更新、软件补丁、安全更新、碎片整理、下载数据、上载数据、执行系统检测、车辆安保等。关于车辆安保，如果注册司机不在车辆附近，则车辆可以保护所述车辆不被进入或驾驶，即使潜在司机(比如注册司机之一的家庭成员)有钥匙。所述车辆安保处理可以通过输入密码而手动重写。所述车辆可以基于最短时间段来确定要发起的至少一个处理。一些处理可以并行执行，一些可以串行执行。所列出的GPS更新可以与其它处理并行(例如，同时)执行，因为GPS功能可以是独立的功能。所列出的其它处理可以串行执行。举个例子，车辆可以确定最短时间段为2个小时。车辆可以确定要发起GPS更新(2个小时)、软件补丁(I个小时)和下载数据(2个小时)。即使总的处理时间是4个小时也可以发起所述三个处理，因为它们可以并行执行，具有的有效壁钟时间为2个小时。
[0029]一些处理可能基于司机的接近度而不能被发起。这些处理可以被称为非接近处理。非接近处理可以根据调度表来发起，或者在任何时间发起，因为它们被确定为不会降低用户体验，或者它们最近没有运行并且即使它们降低用户体验也必须运行。
[0030]包括用户选择的处理的非接近处理应当根据调度表来运行，而不考虑注册司机的接近度。例如，参照图4，混杂处理固件更新和碎片整理被调度(schedule)，并因此它们可以根据调度表来发起而无需受到关于注册司机的接近度的约束。
[0031]另外，非接近处理包括注册司机确定可以在任何时间发起、不考虑注册司机的接近度的处理。例如，注册司机可以确定可以在任何时间执行对包含电影和音乐的磁盘的碎片整理，并且仅可以在注册司机距离至少3个小时距离时执行对包含操作系统的磁盘的碎片整理。这样，操作系统磁盘碎片整理处理将不是非接近处理，而电影/音乐磁盘碎片整理处理将是非接近处理。
[0032]此外，非接近处理包括已经一段时间没有运行过、但即使它们降低用户体验也必须运行的处理。例如，如果安全更新处理没有运行是由于注册司机太接近而使得所述处理无法发起，则安全更新处理可以成为非接近处理。一旦安全更新处理是非接近处理，则所述处理可以不受涉及注册司机的接近度的约束来发起。
[0033]这些处理可以包括对它们应该何时运行的调度表。所述调度表可以是所述处理应该运行的具体时间、运行所述处理的频率和/或触发所述处理的特定事件。例如，固件更新可以每周发起一次，而碎片整理处理可以每天发起一次。也可以指定特定时间和/或日期。处理可以由具体事件触发。例如，碎片整理处理可以在删除大的文件后发起或通过磁盘上存储的数据减少到特定阈值来发起。
[0034]图5示出了基于可用电池电量来确定是否要发起至少一个处理。车辆可以有一个或多个电源，比如主车辆电池、辅助电池、用于为电动机供电的电池包等等。这些电源中的任何一个或全部可以用于为至少一个处理供电。电池500显示了 70 %可用的电池电量502。组I包括处理A、B、C、D，并且可能使用少于所述可用电量的电量来完成。车辆可以确定要发起组I中的处理。组2包括处理E、F、G并且可能使用所有或几乎所有剩余可用电量来完成。在这种情况下，如果系统确定车辆具有足够的电池寿命对所述车辆供电，则所述车辆可以确定要发起所述处理。替代地，所述车辆可以确定不发起所述处理，因为所有或几乎所有可用电池电量将耗尽。所述车辆可以确定足够用于启动车辆的引擎或发动机的电池电量来确定是否要发起处理。组3包括处理H、1、J、K并且可能使用多于可用电池电量502的电量来完成。在这种情况下，系统可以确定不发起组3的处理。对要发起处理的确定可以基于行进的最短时间或可用电池电量中的任意一项或两项。
[0035]如果车辆连接到电源，诸如包括家用电源插座或充电站的外部电源，则如果使用所连接的电源，所述车辆可以不需要考虑可用电池电量502。在这种情况下，由于电池500将被再充满或电源可以是连接的电源，所以可以发起组3处理。
[0036]在一些情况中，不考虑没有足够的电量来启动车辆或没有足够电量来完成处理，而发起组2和组3处理。例如如果车辆停在车库，但是没有插入到车库中的充电站，则车辆可以发起组2和组3处理，因为充电站在附近。车辆将不能完成组3处理。然而，注册司机可以将车辆插入充电站以允许完成组3处理。同样，车辆可能在完成组2处理之后无法启动。但是，注册司机可以将车辆插入充电站以允许电池在组2处理期间或完成之后充电。
[0037]图6示出了用于确定是否要发起至少一个处理的信息。用于确定是否要发起至少一个处理的信息可以包括处理时间和处理类型。信息可以包括针对注册司机的行进历史606。所述行进历史可以用于计算注册司机到达车辆的行进时间。该车辆可以使用平均的历史行进时间或最长的历史行进时间。例如，在图1中，车辆可以接收注册司机在机场处的位置。车辆可以查询行进历史中的行进时间以确定距离机场的平均时间是8个小时15分钟，并且最长行进时间是10个小时。车辆可以使用平均或最长行进时间中的一个来确定是否要发起至少一个处理。信息还可以包括注册司机的调度表608。注册司机的调度表608可以用于计算所述注册司机到达车辆的行进时间。例如，在7月2日，车辆可以查询注册司机的调度表并确定注册司机有在机场的午饭约会。车辆可以使用这个位置来确定行进时间以及确定是否要发起至少一个处理。再举一个例子，在7月10日，车辆可以确定注册司机在10小时的距离以外的船上休假。车辆可以确定要发起在少于10个小时的时间内完成的至少一个处理。在7月15日，车辆可以确定注册司机在欧洲旅行并且在20小时的距离以夕卜。车辆可以确定要发起少于20小时的至少一个处理。
[0038]图7是示例性实施例的流程图。所述方法可以由车辆执行。在701处开始后，车辆确定所述车辆的近似位置。在步骤702处，车辆接收注册司机的位置。注册司机的位置是假设所述注册司机要携带的所述注册司机的移动设备的位置。在步骤703处，车辆确定针对注册司机的可用行进模式。车辆可以根据从注册司机接收到的信息或者根据存储在车辆系统中的信息(比如关于图6所讨论的信息)来确定可用模式。在步骤704处，车辆将所确定的车辆的近似位置与接收到的注册司机的位置进行比较。在步骤705处，车辆估计注册司机从接收到的注册司机的位置到达车辆附近的行进速度。在步骤706处，车辆估计注册司机从接收到的注册司机的位置到达车辆附近的行进延迟。在步骤703、705、706中，车辆可以使用来自注册司机的信息或存储的信息。车辆还可以在做出估计时接入在线网络或源。行进延迟可以基于针对交通模式的固有延迟、历史、调度表和/或其它可用的历史源或实时源。例如，车辆可以在确定行进延迟时存取实时交通信息、航班延迟和天气状况。在步骤707处，车辆确定车辆的注册司机在此期间接近所述车辆的最短时间段。在步骤708处，车辆确定是否存在是非接近处理的用户临近处理(其为需要在司机到达车辆之前、小于阈值时间段内发起的处理)要发起。例如，用户临近处理可以包括加热或冷却车厢、调谐广播或播放音乐、打开或关闭门控灯、调整座椅或后视镜等等。如果存在这种用户临近处理要发起，则处理继续到步骤709。在步骤709处，车辆确定最短时间段是否小于阈值时间段。如果最短时间段小于阈值时间段，则在步骤710处，车辆基于注册司机偏好来确定是否要发起至少一个处理。在步骤711处，在确定要发起至少一个处理后，车辆发起至少一个处理。例如，注册司机可能返回车辆并且可能小于10分钟以外的距离的阈值。在这种情况下，车辆可以加热车厢或将广播调谐到注册司机的偏好。返回步骤709，如果最短时间段不小于阈值时间段(即，注册司机不小于阈值时间段的距离)，则所述方法可以进入等待或休眠状态。
[0039]继续到步骤712，车辆确定是否存在不是非接近处理的、选择的处理(其为包括从一组处理中进行选择的处理)要发起。例如，车辆可以从多个电池充电速度中进行选择。当较多时间可用时，车辆可以发起较慢但更完全的电池充电。当较少时间可用时，车辆可以发起较快的电池充电。当较多时间可用时，车辆可以执行更彻底和完整的系统更新、数据同步、数据备份等。当较少时间可用时，车辆可以执行增量或紧急系统更新。在步骤713处，车辆确定用于完成所述处理的组中的每一个处理的处理时间段。例如，慢速电池充电可以在10个小时内完成，而快速充电在4个小时内完成。在步骤714处，车辆基于最短时间段和针对每个处理的处理时间来确定是否要发起处理的组中的至少一个处理。在步骤715处，车辆在休眠时间段内进入休眠模式。休眠时间段可以基于最短时间段和处理时间段之差。在步骤716处，在休眠时间段到期后车辆醒来。在步骤717处，车辆在确定要发起处理的组中的至少一个处理后发起所述至少一个处理。步骤717被示出为在步骤715和716之后，但是步骤717可以在步骤715之前，使得车辆在进入休眠模式之前发起所述至少一个处理。
[0040]继续到步骤718，车辆确定是否存在不是非接近处理的混杂处理要发起。混杂处理是除了用户临近处理和选择的处理之外的所有处理。混杂处理可以包括软件更新、地图下载等等。在步骤719处，车辆确定用于完成至少一个其它处理的处理时间段。在步骤720处，车辆基于最短时间段和处理时间段来确定是否要发起至少一个其它处理。在步骤721处，车辆在休眠时间段内进入休眠模式。在步骤722处，在休眠时间段到期后车辆醒来。在步骤723处，车辆基于确定要发起至少一个其它处理来发起所述至少一个其它处理。
[0041 ] 在步骤708、712和718处开始的处理组可以串行或并行执行。在一个方面中，所述方法可以执行从708到711的步骤，然后执行从712到717的步骤，然后执行从718到723的步骤。在另一个方面中，所述方法可以同时执行所有三个处理组。
[0042]如上所讨论的，注册司机的位置是假设所述注册司机要携带的所述注册司机的移动设备的位置。如果注册司机启动了车辆而没有携带移动设备(即，移动设备没有接近车辆)，则车辆可以记录注册司机没有携带移动设备以及记录时间。然后，车辆可以确定具体的注册司机将不会携带移动设备的频率和可能的时间。基于注册司机将不会携带移动设备的频率和可能的时间，车辆可以确定是否实现图7的方法。例如，如果车辆确定注册司机每天下午I点在没有移动设备的情况下发动车辆，则车辆可以每天在下午I点之前的数个小时暂停图7的方法以利于定期维护的默认模式。
[0043]图8是另一个示例性实施例的流程图。所述方法可以由服务器(比如接入点)执行。在801处开始，服务器接收车辆的近似位置。在步骤802处，服务器接收注册司机的位置。注册司机的位置是假设所述注册司机要携带的所述注册司机的移动设备的位置。在步骤803处，服务器确定注册司机的可用行进模式。服务器可以根据从注册司机接收的信息或根据服务器处存储的信息(比如关于图6所讨论的信息)来确定可用模式。在步骤804处，服务器将接收到的车辆的近似位置与接收到的注册司机的位置进行比较。在步骤805处，服务器估计注册司机从接收到的所述注册司机的位置到达车辆附近的行进速度。在步骤806处，服务器估计注册司机从接收到的所述注册司机的位置到达车辆附近的行进延迟。在步骤803、805、806中，服务器可以使用来自注册司机的信息或存储的信息。服务器还可以在做出估计时接入在线网络或源。行进延迟可以基于交通模式的固有延迟、历史、调度表和/或其它可用的历史源或实时源。例如，服务器可以在确定行进延迟时访问实时交通信息、航班延迟和天气状况。在步骤807处，服务器确定车辆的注册司机在此期间接近车辆的最短时间段。在步骤808处，服务器确定是否存在是非接近处理的、用户临近处理(其为需要在司机到达车辆之前在小于阈值时间段内发起的处理)要发起。例如，用户临近处理可以包括加热或冷却车厢、调谐广播或播放音乐音轨、打开或关闭门控灯、调整座椅或后视镜等等。如果存在这种用户临近处理要发起，则处理继续到步骤809。在步骤809处，月艮务器确定最短时间段是否小于阈值时间段。如果最短时间段小于阈值时间段，则在步骤810处，服务器基于注册司机偏好来确定是否要发起至少一个处理。在步骤811处，在确定要发起至少一个处理后服务器请求车辆发起所述至少一个处理。例如，服务器可以通过与车辆的无线通信来发送请求。在步骤815处，服务器请求车辆在休眠时间段内进入休眠模式。在步骤816处，在休眠时间段到期后，服务器请求车辆醒来。在步骤817处，在确定要发起处理的组中的至少一个处理后，服务器请求车辆发起所述至少一个处理。例如，注册司机可能返回车辆并且可能小于10分钟的阈值的距离。在这种情况下，服务器可以请求车辆加热车厢或将广播电台调谐到注册司机的偏好。返回步骤809，如果最短时间段不小于阈值时间段(即，该注册司机不小于阈值时间段的距离)，则所述方法可以进入等待或休眠状态。
[0044]继续到步骤812，服务器确定是否存在不是非接近处理的、选择的处理(其为包括从处理的组中进行选择的处理)要发起。例如，服务器可以从多个电池充电速度中进行选择。当较多时间可用时，服务器可以请求车辆发起较慢但更完全的电池充电。当较少时间可用时，服务器可以请求车辆发起较快的电池充电。当较多时间可用时，服务器可以请求车辆执行更彻底和完全的系统更新、数据同步、数据备份等。当较少时间可用时，服务器可以请求车辆执行增量或紧急系统更新。在步骤813处，服务器确定用于完成处理的组中的每一个处理的处理时间段。例如，慢速电池充电可以在10个小时内完成，而快速充电在4个小时内完成。在步骤814处，车辆基于最短时间段和针对每个处理的处理时间来确定是否要发起处理的组中的至少一个处理。在步骤815处，服务器请求车辆在休眠时间段内进入休眠模式。所述休眠时间段可以基于最短时间段和处理时间段之差。在步骤816处，在休眠时间段到期后服务器请求车辆醒来。在步骤817处，在确定要发起处理的组中的至少一个处理后服务器请求车辆发起所述至少一个处理。步骤817被示出为在步骤815和816之后，但是步骤817可以在步骤815之前，使得车辆在进入休眠模式之前发起所述至少一个处理。
[0045]继续到步骤818，服务器确定是否存在不是非接近处理的、混杂处理要发起。混杂处理是除了用户临近处理和选择的处理之外的所有处理。混杂处理可以包括软件更新、地图下载等等。在步骤819处，服务器确定用于完成至少一个其它处理的处理时间段。在步骤820处，服务器基于最短时间段和处理时间段来确定是否要发起至少一个其它处理。
[0046]在步骤821处，服务器请求车辆在休眠时间段内进入休眠模式。在步骤822处，在休眠时间段到期后服务器请求车辆醒来。在步骤823处，基于确定要发起至少一个其它处理，服务器请求车辆发起所述至少一个其它处理。本领域的技术人员将认识到，服务器可以请求车辆发起至少一个处理，并且所述车辆可以确定其自身何时进入休眠模式。
[0047]在步骤808、812和818处开始的处理组可以串行执行或并行执行。在一个方面中，所述方法可以执行从808到811的步骤，然后执行从812到817的步骤，然后执行从818到823的步骤。在另一个方面中，所述方法可以同时执行所有三个处理组。
[0048]如上所讨论的，注册司机的位置是假设所述注册司机要携带的所述注册司机的移动设备的位置。如果注册司机启动车辆，而没有携带所述移动设备(即，移动设备没有接近车辆)，则服务器可以记录所述注册司机没有携带移动设备以及时间。然后，服务器可以确定具体的注册司机将不携带移动设备的频率和可能的时间。基于注册司机将不携带移动设备的频率和可能的时间，服务器可以确定是否实现图8的方法。例如，如果服务器确定注册司机每天下午I点在没有移动设备的情况下发动车辆，则服务器可以每天在下午I点之前的数个小时暂停图8的方法以利于定期维护的默认模式。
[0049]图9是向车辆注册司机的流程图。处理通过接收用于注册的司机信息在902处开始。所述处理可以无线地、通过互联网或在车辆或服务器的控制台处执行。司机信息可以包括资料信息、密码、令牌密钥等等。在所述处理接收到司机信息之后，所述处理在步骤904处将司机注册为车辆的拥有者。接下来在步骤906处，所述处理接收例如偏好、调度表等注册用户数据。用户数据可以定期地向服务器发送，或者车辆或服务器可以发送针对用户数据的请求。一旦司机向车辆进行了注册，则所述车辆可以接收用于所述车辆确定注册司机的位置的位置信息。车辆还可以基于从注册司机接收到的用户数据来确定最短时间段。
[0050]车辆和服务器是分开讨论的，并且车辆和服务器可能是在远程位置处的分开的实体。车辆和服务器可以相距很远或靠近在一起。
[0051]图10是示出了一个示例性装置中不同模块/单元/组件之间的数据流的概念性数据流图。所述装置可以是车辆中包含的装置。装置1001可以包括被配置为接收或确定注册司机和车辆的位置的位置确定模块1002。装置1001还可以包括被配置为基于确定的注册司机的位置和车辆的位置来确定行进时间的行进时间确定模块1004。行进时间确定模块1004还可以被配置为基于其它条件(比如调度表、一天中的时间、历史等)来确定行进时间。装置1001还可以包括被配置为确定要完成处理所花费的时间长度的处理时间确定模块1006。处理时间确定模块1006可以被配置为确定任何数量的处理或处理的组。一些处理可能不具有处理时间，或者具有不明显的处理时间。其它类型的处理是可能的。处理时间确定模块1006可以根据历史信息、处理的本质或系统的能力(硬驱动速度、网络速度等)来确定处理时间。装置1001还可以包括被配置为确定是否要发起至少一个处理的处理发起确定模块1008。例如，处理发起确定模块1008可以被配置为将行进时间与处理时间进行比较。处理发起确定模块1008可以被配置为基于司机的位置来确定要发起至少一个处理。处理发起确定模块1008可以被配置为基于很多因素来确定要发起至少一个处理。例如，所述确定可以基于来自车辆和注册司机中的任何一个或两个上的接近传感器的信息。装置1001还可以包括处理发起模块1010。处理发起模块1010可以被配置为在处理发起确定模块1008确定要发起至少一个处理后发起所述至少一个处理。处理发起模块1010可以被配置为以任意多种方式与车辆系统交互。例如，处理发起模块1010可以耦合到电子控制单元(ECU)，或者处理发起模块1010可以直接连接到车辆系统。车辆系统可以包括任何电子系统或机械系统。
[0052]所述装置可以包括执行图7、9的上述流程图中的算法的每个步骤的额外模块。这样，图7、9的上述流程图中的每个步骤可以由模块来执行，并且所述装置可以包括那些模块中的一个或多个模块。所述模块可以是被具体配置为执行所声明的处理/算法的一个或多个硬件组件、由被配置为执行所声明的处理/算法的处理器实现、存储在用于由处理器实现的计算机可读介质中，或它们的一些组合。
[0053]图11是示出了另一个示例性装置中的不同模块/单元/组件之间的数据流的概念性数据流图。装置1101可以是服务器中包含的装置。装置1101可以包括被配置为接收司机注册信息并且对司机进行注册的司机注册模块1112。一旦司机向系统进行注册，则服务器可以接收司机位置信息或请求司机位置信息。装置1101可以包括用于请求车辆发起至少一个处理的处理发起请求模块1110。处理发起请求模块1110可以耦合到无线设备或发射机以向车辆发送请求以使所述车辆发起至少一个处理。装置1101可以包括被配置为接收或确定注册司机的位置和车辆的位置的位置确定模块1102。装置1101还可以包括被配置为基于确定的注册司机的位置和车辆的位置来确定行进时间的行进时间确定模块1104。行进时间确定模块1104还可以被配置为基于其它条件(比如调度表、一天中的时间、历史等)来确定行进时间。装置1101还可以包括被配置为确定要完成处理所花费的时间长度的处理时间确定模块1106。处理时间确定模块1106可以被配置为确定任何数量的处理或处理的组。一些处理可能不具有处理时间，或者具有不明显的处理时间。其它类型的处理是可能的。处理时间确定模块1106可以根据历史信息、处理的本质或系统的能力(硬驱动速度、网络速度等)来确定处理时间。装置1101还可以包括被配置为确定是否要发起至少一个处理的处理发起确定模块1108。例如，处理发起确定模块1108可以被配置为将行进时间与处理时间进行比较。处理发起确定模块1108可以被配置为基于司机的位置来确定要发起至少一个处理。处理发起确定模块1108可以被配置为基于很多因素来确定要发起至少一个处理。例如，所述确定可以基于来自车辆和注册司机中的任何一个或两个上的接近传感器的信息。
[0054]所述装置可以包括执行图8、9的上述流图中的算法的每个步骤的额外模块。这样，图8、9的上述流图中的每个步骤可以由模块来执行，并且所述装置可以包括那些模块中的一个或多个模块。所述模块可以是被具体配置为执行所声明的处理/算法的一个或多个硬件组件、由被配置为执行所声明的处理/算法的处理器实现、存储在用于由处理器实现的计算机可读介质中，或它们的一些组合。
[0055]图12是示出了针对采用处理系统的装置的硬件实现的一个例子的示图1200。所述处理系统可以是车辆的处理系统。处理系统1201可以利用总线结构(一般由总线1250代表)来实现。总线1250可以包括任何数量的互连总线和桥接器，这取决于处理系统1201的特定应用和整体设计约束。总线1250将包括一个或多个处理器和/或硬件模块的各个电路链接在一起，所述一个或多个处理器和/或硬件模块由处理器1212、模块1202、1204、1206、1208和1210以及计算机可读介质1214代表。总线1250还可以链接各个其它电路，比如定时源、外围设备、稳压器和功率管理电路，它们在本领域内是公知的，并且因此将不再进一步描述。处理系统1201可以链接到车辆系统。处理系统1201可以耦合到收发机1230。收发机1230耦合到一个或多个天线1240。收发机1230可以提供用于在传输介质上与各个其它装置通信的单元。处理系统1201可以包括耦合到计算机可读介质1214的处理器1212。处理器1212负责通用处理，所述通用处理包括对存储在计算机可读介质1214上的软件的执行。当所述软件由处理器1212执行时，使得处理系统1201执行上面针对任何具体装置所描述的各个功能。计算机可读介质1214还可以用于存储处理器1212正在执行软件时所操作的数据。处理系统1201还包括模块1202、1204、1206、1208和1210。这些模块可以是运行在处理器1212中、驻留/存储在计算机可读介质1214中的软件模块，耦合到处理器的一个或多个硬件模块，或它们的一些组合。处理系统1201可以是车辆系统的组件。
[0056]在一种配置中，装置1001、1299可以包括:用于确定车辆的近似位置的单元；用于基于所确定的近似位置来确定在此期间车辆的注册司机接近所述车辆的最短时间段的单元；以及用于基于所确定的时间段来确定是否要在所述车辆中发起至少一个处理的单元。装置1001、1299还可以包括:用于接收车辆的注册司机的位置的单元；以及用于将所确定的车辆的近似位置与接收到的注册司机的位置进行比较的单元。装置1001、1299还可以包括:用于估计注册司机从接收到的注册司机的位置到达车辆附近的行进速度的单元；以及用于估计注册司机从接收到的注册司机的位置到达车辆附近的行进延迟的单元。装置1001、1299还可以包括:用于确定完成所述至少一个处理的处理时间段的单元。装置1001、1299还可以包括:用于在近似等于所确定的最短时间段减去处理时间段的休眠时间段内进入休眠模式的单元；以及用于在休眠时间段到期后醒来以便发起至少一个处理使得所述至少一个处理在所确定的最短时间段到期之前完成的单元。装置1001、1299还可以包括:在用于驱动车辆的引擎或发动机中的至少一个开启时定期地确定车辆位置的单元；用于基于所确定的时间段来确定电池充电速度的单元；以及用于确定车辆的电池中的剩余电量的单元。装置1001、1299还可以包括:用于当车辆处于电池充电站的阈值距离内时，不考虑电池中的剩余电量而确定要发起至少一个处理的单元。装置1001、1299还可以包括:用于在阈值时间段内还没有发起至少一个处理时，不考虑所确定的时间段而确定要发起至少一个处理的单元。装置1001、1299还可以包括:用于在确定要发起至少一个处理后在车辆中发起至少一个处理的单元。上述单元可以是装置1001、1299的上述模块中的一个或多个模块和/或被配置为执行上述单元所列举的功能的装置的处理系统。
[0057]图13是示出了针对采用处理系统的装置的硬件实现的另一个例子的示图1300。所述处理系统可以是服务器的处理系统。处理系统1301可以利用总线结构(一般由总线1350代表)来实现。总线1350可以包括任何数量的互连总线和桥接器，这取决于处理系统1301的特定应用和整体设计约束。总线1350将包括一个或多个处理器和/或硬件模块的各个电路链接在一起，所述一个或多个处理器和/或硬件模块由处理器1312、模块1302、1304、1306、1308和1310以及计算机可读介质1314代表。总线1350还可以链接各个其它电路，比如定时源、外围设备、稳压器和功率管理电路，它们在本领域内是公知的，并且因此将不再进一步描述。处理系统1301可以链接到车辆系统。处理系统1301可以耦合到收发机1330。收发机1330耦合到一个或多个天线1340。收发机1330可以提供用于通过传输介质与各个其它装置通信的单元。处理系统1301可以包括耦合到计算机可读介质1314的处理器1312。处理器1312负责通用处理，所述通用处理包括对存储在计算机可读介质1314上的软件的执行。当所述软件由处理器1312执行时，使得处理系统1301执行上面针对任何具体装置所描述的各个功能。计算机可读介质1314还可以用于存储处理器1312正在执行软件时所操作的数据。处理系统1301还包括模块1302、1304、1306、1308和1310。所述模块可以是运行在处理器1312中、驻留/存储在计算机可读介质1314中的软件模块，耦合到处理器的一个或多个硬件模块，或它们的一些组合。处理系统1301可以是服务器系统的组件。
[0058]在一个配置中，装置1101、1399可以包括:用于确定车辆的近似位置的单元；用于基于所确定的近似位置来确定在此期间车辆的注册司机接近所述车辆的最短时间段的单元；以及用于基于所确定的时间段来确定是否要在车辆中发起至少一个处理的单元。装置1101,1399还可以包括:用于接收车辆的注册司机的位置的单元；以及用于将所确定的车辆的近似位置与接收到的注册司机的位置进行比较的单元。装置1101、1399还可以包括:用于估计注册司机从接收到的注册司机的位置到达车辆附近的行进速度的单元；以及用于估计注册司机从接收到的注册司机的位置到达车辆附近的行进延迟的单元。装置1101、1399还可以包括:用于确定完成所述至少一个处理的处理时间段的单元。装置1101、1399还可以包括:用于在近似等于所确定的最短时间段减去处理时间段的休眠时间段内进入休眠模式的单元；以及用于在休眠时间段到期后醒来以便发起至少一个处理使得所述至少一个处理在所确定的最短时间段到期之前完成的单元。装置1101、1399还可以包括:在用于驱动车辆的引擎或发动机中的至少一个开启时定期地确定车辆位置的单元；用于基于所确定的时间段来确定电池充电速度的单元；以及用于确定车辆的电池中的剩余电量的单元。装置1101、1399还可以包括:用于在车辆处于电池充电站的阈值距离内时，不考虑电池中的剩余电量而确定要发起至少一个处理的单元。装置1101、1399还可以包括:用于在阈值时间段内还没有发起至少一个处理时，不考虑所确定的时间段而确定要发起至少一个处理的单元。装置1101、1399还可以包括:用于在确定要发起至少一个处理后，在车辆中发起至少一个处理的单元。上述单元可以是装置1101、1399的上述模块中的一个或多个和/或被配置为执行上述单元所列举功能的装置的处理系统。所述装置还可以包括:用于请求车辆在近似等于所确定的最短时间段减去处理时间段的休眠时间段内进入休眠模式的单元；用于在休眠时间段到期后请求车辆醒来以便发起至少一个处理使得所述至少一个处理在所确定的最短时间段到期之前完成的单元；以及用于在确定要发起至少一个处理后，请求车辆发起至少一个处理的单元。所述装置还可以包括用于对车辆的司机进行注册的单元。
[0059]应该理解的是，所公开的处理中步骤的特定顺序或层次是对示例性方法的举例说明。基于设计偏好，应该理解的是可以重新排列所述处理中步骤的特定顺序或层次。此外，一些步骤可以被组合或省略。所附方法要求以示例顺序呈现了各个步骤的单元，但并不意味着要受限于所呈现的特定顺序或层次。
[0060]提供了上述描述，以使得本领域任意技术人员能够实践本文中所描述的各个方面。对于本领域技术人员来说，对这些方面的各种修改将是显而易见的，并且本文中所定义的一般原理也可以适用于其它的方面。因此，权利要求并不旨在受限于本文中所示出的方面，而是要符合与权利要求文字相一致的全部范围，其中，除非具体说明，否则以单数形式提到的元件并不旨在意味着“一个且只有一个”，而是“一个或多个”。除非另外具体说明，否则术语“一些”指的是一个或多个。通过引用方式将对于本领域普通技术人员来说公知的或稍后将会公知的、贯穿本公开内容所描述的各个方面的元件的所有结构和功能等同物明确地并入本文，并且旨在包含于权利要求中。另外，本文中所公开的内容不旨在奉献给公众，无论这一公开内容是否在权利要求中被明确地列举。权利要求元素不是要被解释作为功能单元，除非使用短语“用于…的单元”明确地列举了所述元素。
【权利要求】
1.一种用于在车辆中发起至少一个处理的方法，包括: 确定所述车辆的近似位置； 基于所确定的近似位置来确定在此期间所述车辆的注册司机接近所述车辆的最短时间段；以及 基于所确定的时间段来确定是否要在所述车辆中发起所述至少一个处理。
2.根据权利要求1所述的方法，还包括接收所述车辆的所述注册司机的位置，其中，确定所述最短时间段包括将所确定的所述车辆的近似位置与所接收的所述注册司机的位置进行比较。
3.根据权利要求2所述的方法，其中，所述车辆的所述注册司机是向服务器注册的司机，并且所述注册司机的所述位置是从所述服务器接收的。
4.根据权利要求2所述的方法，还包括对所述车辆的司机进行注册，其中，所述注册司机的所述位置是从与所述注册司机一起的无线设备接收的。
5.根据权利要求2所述的方法，其中，所述注册司机的所述位置是以预定的时间间隔接收的。
6.根据权利要求2所述的方法，其中，所述注册司机的第一位置是在确定了所述车辆的上一次近似位置之后的预定时间段后接收的。
7.根据权利要求2所述的方法，还包括估计所述注册司机从所接收的所述注册司机的位置到达所述车辆附近的行进速度，其中，还基于所估计的所述注册司机的行进速度来确定所述最短时间段。
8.根据权利要求7所述的方法，其中，所述注册司机的所述行进速度是基于以下各项中的至少一个来估计的:(i)可用行进模式；(ii)通过陆路、水路还是航空行进；(iii)交通情况；(iv)与所述可用行进模式相关联的固有延迟；或(V)所述注册司机的先前行进速度历史。
9.根据权利要求2所述的方法，还包括估计所述注册司机从所接收的所述注册司机的位置到达所述车辆附近的行进延迟，其中，还基于所述注册司机的所估计的行进延迟来确定所述最短时间段。
10.根据权利要求9所述的方法，其中，所述注册司机的所述行进延迟是基于以下各项中的至少一个来估计的:(i) 一天中的时间，(?)所述注册司机的调度表或(iii)所述注册司机的先前行进延迟历史。
11.根据权利要求1所述的方法，还包括确定用于完成所述至少一个处理的处理时间段。
12.根据权利要求11所述的方法，还包括: 在近似等于所确定的最短时间段减去所述处理时间段的休眠时间段内进入休眠模式；以及 在所述休眠时间段到期后醒来以便发起所述至少一个处理，使得所述至少一个处理在所确定的最短时间段到期之前完成。
13.根据权利要求11所述的方法，还包括: 请求所述车辆在近似等于所确定的最短时间段减去所述处理时间段的休眠时间段内进入休眠模式；以及 请求所述车辆在所述休眠时间段到期后醒来以便发起所述至少一个处理，使得所述至少一个处理在所确定的最短时间段到期之前完成。
14.根据权利要求1所述的方法，其中，所述至少一个处理包括以下各项中的至少一个:加热所述车辆的弓I擎或发动机中的至少一个、加热所述车辆的电池、加热或冷却所述车辆内部、对所述车辆的所述电池充电、锁住所述车辆的门或隔间、关闭所述车辆的灯、下载数据、上载数据、在所述车辆中进行存储碎片整理、同步数据或执行系统检测。
15.根据权利要求1所述的方法，其中，所述至少一个处理包括基于所述注册司机的用户偏好来加热或冷却所述车辆的内部以及选择加热或冷却配置文件。
16.根据权利要求1所述的方法，其中，所述车辆的所述近似位置是在用于驱动所述车辆的引擎或发动机中的至少一个关闭后确定的所述车辆的停止位置。
17.根据权利要求1所述的方法，还包括在用于驱动所述车辆的引擎或发动机中的至少一个开启时定期地确定所述车辆的位置，其中，所述车辆的所述近似位置是在所述车辆的所述引擎和所述发动机中的至少一个关闭之前立即确定的所述车辆的所述位置。
18.根据权利要求1所述的方法，其中，所述至少一个处理包括对所述车辆的电池充电，并且所述方法还包括基于所确定的时间段来确定所述电池的充电速度。
19.根据权利要求1所述的方法，还包括确定所述车辆的电池中的剩余电量，其中，确定是否要发起所述至少一个处理还基于所确定的所述电池中的剩余电量。
20.根据权利要求19所述的方法，其中，确定是否要发起所述至少一个处理还基于所述车辆是否在电池充电站的阈值距离内。
21.根据权利要求20所述的方法，还包括当所述车辆在电池充电站的阈值距离内时，不考虑所述电池中的剩余电量而确定要发起所述至少一个处理。
22.根据权利要求1所述的方法，还包括在确定要发起所述至少一个处理后，在所述车辆内发起所述至少一个处理。
23.根据权利要求1所述的方法，还包括在确定要发起所述至少一个处理后，请求所述车辆发起所述至少一个处理。
24.根据权利要求1所述的方法，其中，确定所述近似位置包括从所述车辆接收所述近似位置。
25.根据权利要求1所述的方法，其中，确定是否要在所述车辆内发起所述至少一个处理还基于所述至少一个处理是否已经在阈值时间段内发起，并且所述方法还包括当所述至少一个处理还没有在所述阈值时间段内发起时不考虑所确定的时间段而确定要发起所述至少一个处理。
26.一种用于在车辆中发起至少一个处理的装置，包括: 用于确定所述车辆的近似位置的单元； 用于基于所确定的近似位置来确定在此期间所述车辆的注册司机接近所述车辆的最短时间段的单元；以及 用于基于所确定的时间段来确定是否要在所述车辆中发起所述至少一个处理的单元。
27.根据权利要求26所述的装置，还包括用于接收所述车辆的所述注册司机的位置的单元，其中，用于确定所述最短时间段的所述单元还被配置为将所确定的所述车辆的近似位置与所接收的所述注册司机的位置进行比较。
28.根据权利要求27所述的装置，其中，所述车辆的所述注册司机是向服务器注册的司机，并且所述注册司机的所述位置是从所述服务器接收的。
29.根据权利要求27所述的装置，还包括用于对所述车辆的司机进行注册的单元，其中，所述注册司机的所述位置是从与所述注册司机一起的无线设备接收的。
30.根据权利要求27所述的装置，其中，所述注册司机的所述位置是以预定的时间间隔接收的。
31.根据权利要求27所述的装置，其中，所述注册司机的第一位置是在确定了所述车辆的上一次近似位置之后的预定时间段后接收的。
32.根据权利要求27所述的装置，还包括用于估计所述注册司机从所接收的所述注册司机的位置到达所述车辆附近的行进速度的单元，其中，所述最短时间段是还基于所估计的所述注册司机的行进速度而确定的。
33.根据权利要求32所述的装置，其中，所述注册司机的所述行进速度是基于以下各项中的至少一个来估计的:(i)可用行进模式；(ii)通过陆路、水路还是航空行进；(iii)交通情况；(iv)与所述可用行进模式相关联的固有延迟；或(V)所述注册司机的先前行进速度历史。
34.根据权利要求27所述的装置，还包括用于估计所述注册司机从所接收的所述注册司机的位置到达所述车辆附近的行进延迟的单元，其中，所述最短时间段是还基于所述注册司机的所估计的行进延迟而确定的。
35.根据权利要求34所述的装置，其中，所述注册司机的所述行进延迟是基于以下各项中的至少一个来估计的:(i) 一天中的时间，(?)所述注册司机的调度表或(iii)所述注册司机的先前行进延迟历史。
36.根据权利要求26所述的装置，还包括用于确定用于完成所述至少一个处理的处理时间段的单元。
37.根据权利要求36所述的装置，还包括: 用于在近似等于所确定的最短时间段减去所述处理时间段的休眠时间段内进入休眠模式的单元；以及 用于在所述休眠时间段到期后醒来以便发起所述至少一个处理，使得所述至少一个处理在所确定的最短时间段到期之前完成的单元。
38.根据权利要求36所述的装置，还包括: 用于请求所述车辆在近似等于所确定的最短时间段减去所述处理时间段的休眠时间段内进入休眠模式的单元；以及 用于请求所述车辆在所述休眠时间段到期后醒来以便发起所述至少一个处理，使得所述至少一个处理在所确定的最短时间段到期之前完成的单元。
39.根据权利要26所述的装置，其中，所述至少一个处理包括以下各项中的至少一个:加热所述车辆的引擎或发动机中的至少一个、加热所述车辆的电池、加热或冷却所述车辆内部、对所述车辆的所述电池充电、锁住所述车辆的门或隔间、关闭所述车辆的灯、下载数据、上载数据、在所述车辆中进行存储碎片整理、同步数据或执行系统检测。
40.根据权利要求26所述的装置，其中，所述至少一个处理包括基于所述注册司机的用户偏好来加热或冷却所述车辆的内部以及选择加热或冷却配置文件。
41.根据权利要求26所述的装置，其中，所述车辆的所述近似位置是在用于驱动所述车辆的引擎或发动机中的至少一个关闭后确定的所述车辆的停止位置。
42.根据权利要求26所述的装置，其中，用于确定所述车辆的所述位置的所述单元还被配置为在用于驱动所述车辆的引擎或发动机中的至少一个开启时定期地确定所述车辆的位置，其中，所述车辆的所述近似位置是在所述车辆的所述引擎和所述发动机中的至少一个关闭之前立即确定的所述车辆的位置。
43.根据权利要求26所述的装置，其中，所述至少一个处理包括对所述车辆的电池充电，并且所述方法还包括基于所确定的时间段来确定所述电池的充电速度。
44.根据权利要求26所述的装置，还包括用于确定所述车辆的电池中的剩余电量的单元，其中，用于确定是否要发起所述至少一个处理的所述单元还基于所确定的所述电池中的剩余电量来做出所述确定。
45.根据权利要求44所述的装置，其中，用于确定是否要发起所述至少一个处理的单元还基于所述车辆是否在电池充电站的阈值距离内来做出所述确定。
46.根据权利要求45所述的装置，还包括用于当所述车辆在电池充电站的阈值距离内时，不考虑所述电池中的剩余电量而确定要发起所述至少一个处理的单元。
47.根据权利要求26所述的装置，还包括用于在确定要发起所述至少一个处理后，在所述车辆内发起所述至少一个处理的单元。
48.根据权利要求26所述的装置，还包括用于在确定要发起所述至少一个处理后，请求所述车辆发起所述至少一个处理的单元。
49.根据权利要求26所述的装置，其中，用于确定所述近似位置的所述单元还被配置为从所述车辆接收所述近似位置。
50.根据权利要求26所述的装置，其中，用于确定是否要在所述车辆内发起所述至少一个处理的所述单元还基于所述至少一个处理是否已经在阈值时间段内发起来做出所述确定，并且所述装置还包括用于当所述至少一个处理还没有在所述阈值时间段内发起时不考虑所确定的时间段而确定要发起所述至少一个处理的单元。
51.一种用于在车辆中发起至少一个处理的装置，包括: 一种处理系统，被配置为: 确定所述车辆的近似位置； 基于所确定的近似位置来确定在此期间所述车辆的注册司机接近所述车辆的最短时间段；以及 基于所确定的时间段来确定是否要在所述车辆中发起所述至少一个处理。
52.根据权利要求51所述的装置，其中，所述处理系统还被配置为接收所述车辆的所述注册司机的位置，其中，确定所述最短时间段包括将所确定的所述车辆的近似位置与所接收的所述注册司机的位置进行比较。
53.根据权利要求52所述的装置，其中，所述车辆的所述注册司机是向服务器注册的司机，并且所述注册司机的所述位置是从所述服务器接收的。
54.根据权利要求52所述的装置，其中，所述处理系统还被配置为对所述车辆的司机进行注册，其中，所述注册司机的所述位置是从与所述注册司机一起的无线设备接收的。
55.根据权利要求52所述的装置，其中，所述注册司机的所述位置是以预定的时间间隔接收的。
56.根据权利要求52所述的装置，其中，所述注册司机的第一位置是在确定了所述车辆的上一次近似位置之后的预定时间段后接收的。
57.根据权利要求52所述的装置，其中，所述处理系统还被配置为估计所述注册司机从所接收的所述注册司机的位置到达所述车辆附近的行进速度，其中，所述最短时间段是还基于所估计的所述注册司机的行进速度而确定的。
58.根据权利要求57所述的装置，其中，所述注册司机的所述行进速度是基于以下各项中的至少一个来估计的:(i)可用行进模式；(ii)通过陆路、水路还是航空行进；(iii)交通情况；(iv)与所述可用行进模式相关联的固有延迟；或(V)所述注册司机的先前行进速度历史。
59.根据权利要求52所述的装置，其中，所述处理系统还被配置为估计所述注册司机从所接收的所述注册司机的位置到达所述车辆附近的行进延迟，其中，所述最短时间段是还基于所述注册司机的所估计的行进延迟而确定的。
60.根据权利要求59所述的装置，其中，所述注册司机的所述行进延迟是基于以下各项中的至少一个来估计的:(i) 一天中的时间，(?)所述注册司机的调度表或(iii)所述注册司机的先前行进延迟历史。
61.根据权利要求51所述的装置，其中，所述处理系统还被配置为确定用于完成所述至少一个处理的处理时间段。
62.根据权利要求61所述的装置，其中，所述处理系统还被配置为: 在近似等于所确定的最短时间段减去所述处理时间段的休眠时间段内进入休眠模式；以及 在所述休眠时间段到期后醒来以便发起所述至少一个处理，使得所述至少一个处理在所确定的最短时间段到期之前完成。
63.根据权利要求61所述的装置，其中，所述处理系统还被配置为: 请求所述车辆在近似等于所确定的最短时间段减去所述处理时间段的休眠时间段内进入休眠模式；以及 请求所述车辆在所述休眠时间段到期后醒来以便发起所述至少一个处理，使得所述至少一个处理在所确定的最短时间段到期之前完成。
64.根据权利要求51所述的装置，其中，所述至少一个处理包括以下各项中的至少一个:加热所述车辆的弓I擎或发动机中的至少一个、加热所述车辆的电池、加热或冷却所述车辆内部、对所述车辆的所述电池充电、锁住所述车辆的门或隔间、关闭所述车辆的灯、下载数据、上载数据、在所述车辆中进行存储碎片整理、同步数据或执行系统检测。
65.根据权利要求51所述的装置，其中，所述至少一个处理包括基于所述注册司机的用户偏好来加热或冷却所述车辆的内部以及选择加热或冷却配置文件。
66.根据权利要求51所述的装置，其中，所述车辆的所述近似位置是在用于驱动所述车辆的引擎或发动机中的至少一个关闭后确定的所述车辆的停止位置。
67.根据权利要求51所述的装置，其中，所述处理系统还被配置为在用于驱动所述车辆的引擎或发动机中的至少一个开启时定期地确定所述车辆的位置，其中，所述车辆的所述近似位置是在所述车辆的所述引擎和所述发动机中的至少一个关闭之前立即确定的所述车辆的所述位置。
68.根据权利要求51所述的装置，其中，所述至少一个处理包括对所述车辆的电池充电，并且所述方法还包括基于所确定的时间段来确定所述电池的充电速度。
69.根据权利要求51所述的装置，其中，所述处理系统还被配置为确定所述车辆的电池中的剩余电量，其中，所述处理系统被配置为基于所确定的所述电池中的剩余电量来确定是否要发起所述至少一个处理。
70.根据权利要求69所述的装置，其中，所述处理系统被配置为基于所述车辆是否在电池充电站的阈值距离内来确定是否要发起所述至少一个处理。
71.根据权利要求70所述的装置，其中，所述处理系统被配置为当所述车辆在电池充电站的阈值距离内时，不考虑所述电池中的剩余电量而确定要发起所述至少一个处理。
72.根据权利要求51所述的装置，其中，所述处理系统还被配置为在确定要发起所述至少一个处理后，在所述车辆内发起所述至少一个处理。
73.根据权利要求51所述的装置，其中，所述处理系统还被配置为在确定要发起所述至少一个处理后，请求所述车辆发起所述至少一个处理。
74.根据权利要求51所述的装置，其中，所述处理系统被配置为通过从所述车辆接收所述近似位置来确定所述近似位置。
75.根据权利要求51所述的装置，其中，所述处理系统被配置为还基于所述至少一个处理是否已经在阈值时间段内发起来确定是否要在所述车辆内发起所述至少一个处理，并且所述处理系统还被配置为当所述至少一个处理还没有在所述阈值时间段内发起时不考虑所确定的时间段而确定要发起所述至少一个处理。
76.一种用于在车辆中发起至少一个处理的计算机程序产品，包括: 计算机可读介质，其包括用于进行以下行为的代码: 确定所述车辆的近似位置； 基于所确定的近似位置来确定在此期间所述车辆的注册司机接近所述车辆的最短时间段；以及 基于所确定的时间段来确定是否要在所述车辆中发起所述至少一个处理。
【文档编号】G01S19/51GK104204851SQ201380014827
【公开日】2014年12月10日 申请日期:2013年3月18日 优先权日:2012年3月19日
【发明者】B·福鲁坦普尔, J·D·贝克利, S·巴拉苏布拉马尼亚姆, M·伦施勒 申请人:高通股份有限公司