CN102739763B - 追踪方法 - Google Patents

Abstract

一种追踪方法，包括与车辆相关联的计算机系统(VACS)接收追踪请求。该方法也包括验证追踪请求并且通过和VACS通信的GPS确定车辆位置。该方法进一步包括对于至少一个推迟事件将车辆位置从VACS传输给关联了计算机系统的追踪请求(TRACS)。该方法另外包括取决于发生至少一个推迟事件向TRACS传输相当于推迟事件的数据。

Description

追踪方法

技术领域

本发明说明性实施例涉及一种计算机执行的追踪方法。

背景技术

无论是驾车穿越城镇会见朋友，还是驾车穿越乡村去会见亲戚，驾驶员通常想要向他们所要会见的那个人提供估计的到达时间。这有助于会见的那个人相应地计划他们的日程安排，这样他们能确保当旅客到达时他们是到场的。

不幸地，由于天气、道路修补、交通、绕道、未计划的停车等等，旅客经常被推迟，并且很多时候他们在估计到达时间附近可能没有到达任何地方。尽管手机的频率使打电话和更新估计的到达时间变得更加容易，驾驶员可能常常不想在每次推迟时这么做，或者他们的手机可能已经死机，或者可能有无数种他们无法或没有更新其到达时间的其它原因。

另外，可能发生紧急事件或其它原因使要会面的人们需要短暂地离开住宅。当然，除非他们合理地确定地知道不指望他们的客人在他们出去时到达，否则在这些情况下他们不会离开住宅，免得他们的客人在到达之后被困住等待他们回来。

很多车辆开始装备了GPS系统或其它导航系统，以便让车辆知道它的地理位置。另外，车辆甚至可以有允许车辆给当前位置拍照的车载摄像机。

发明内容

根据本发明示例性实施例的一种追踪方法，包括如下步骤：在车辆关联的计算机系统(VACS)处接收对于车辆的追踪请求；确定是否批准所述跟踪请求；当所述跟踪请求被批准时，通过与所述VACS通信的GPS确定所述车辆的位置；从所述VACS将所述车辆的位置传输给发送所述追踪请求计算机系统；监视所述车辆是否发生推迟事件；并且，当出现至少一个推迟事件时，向所述发送所述追踪请求的计算机系统传输对应于所述出现的推迟事件的数据。

在第一说明性实施例中，计算机执行的追踪方法包括接收车辆关联计算机系统(VACS，vehicle associated computing system)的追踪请求。该说明性方法也包括验证所述追踪请求和通过GPS和所述VACS通信确定车辆的位置。

该说明性方法进一步包括从VACS将车辆位置传输给追踪请求相关联的计算机系统(TRACS，tracking request associated computing system)。该说明性方法也包括监视车辆的至少一个推迟事件(delay-event)。该说明性方法附加地包括取决于至少一个推迟事件的出现向TRACS传输对应于推迟事件的数据。

在第二个说明性实施例中，计算机可执行的方法包括，由在TRACS处接收和车辆推迟事件相关联的数据，所述数据包括至少车辆的坐标。该说明性方法也包括使用TRACS确定位置类型(location-type)是否与车辆的坐标相关。

另外，说明性方法包括使用TRACS并且取决于确定来估算和位置类型有联系的推迟。说明性方法进一步包括至少部分基于估算的延迟调整估算的到达时间。说明性方法附加地包括将估计的到达时间从TRACS输送给请求方。

在第三个说明性实施例中，公开了一种计算机可读存储介质，其存储有当执行时导致VACS执行包括在VACS处接收追踪请求的方法的指令。所述说明性方法也包括验证追踪请求并且通过和VACS通信的GPS确定车辆位置。说明性方法进一步包括向TRACS传输车辆位置。

另外，说明性方法包括监视车辆的至少一个推迟事件并且，取决于至少一个推迟事件的出现，向TRACS传输对应于推迟事件的数据。

附图说明

图1显示了车辆计算机系统的说明性示例；

图2显示了追踪请求方法的说明性示例；

图3显示了批准方法的一个示例；

图4显示了车辆监视方法的说明性示例；

图5显示了用于处理车辆紧急事件的方法的说明性示例；并且

图6显示了目的地时间调整估算方法的说明性示例。

具体实施方式

根据需要，本说明书中公开了本发明具体的实施例；但是，应理解公开的实施例仅为本发明的示例，其可以通过多种替代形式实施。附图无需按比例绘制；一些特征可被放大或缩小以显示特定部件的细节。所以，此处所公开的具体结构和功能细节不应解释为限定，而仅为教导本领域技术人员以多种形式实施本发明的代表性基础。

图1说明了用于车辆31的车辆载计算机系统(VCS)1的示例拓朴框图。这种基于车辆的计算机系统1的示例为由福特汽车公司制造的SYNC系统。设有基于车辆的计算机系统的车辆可包含位于车辆中的可视前端界面4。用户还可通过例如触摸屏与该界面(如果有的话)交互。在另一说明性的实施例中，通过按压按扭、口头对话和语音合成进行交互。

在图1中所示的说明性实施例1中，处理器3控制车载计算机系统的运行的至少一部分。设在车辆中的处理器允许指令和循环的车载处理。此外，处理器连接至非持久存储器5和持久存储器7。在这个说明性实施例中，非持久存储器为随机存取存储器(RAM)并且持久存储器为硬盘驱动器(HDD)或快闪存储器。

处理器还设有多个不同的输入，允许用户与处理器交互。在此说明性实施例中，设有麦克风29、辅助输入25(用于输入33)、USB输入23、GPS输入24和蓝牙输入15。还设有输入选择器51以允许用户在多种输入之间切换。在麦克风和辅助连接器的输入传递至处理器之前通过转换器27将其从模拟信号转换为数字信号。尽管未显示，与VCS通信的多个车辆组件和辅助组件可使用车辆网络(例如但不限于CAN总线)以向VCS(或其组件)传递数据或从其接收数据。

对系统的输出可包括但不限于视觉显示器4和扬声器13或立体声系统输出。扬声器连接至放大器11并通过数字-模拟转换器9从处理器3接收其信号。还可分别沿19、21处所示的双向数据流输出至远程蓝牙设备(例如PND54)或USB设备(例如车辆导航设备60)。

在一个说明性实施例中，系统1使用蓝牙收发器15与用户的移动设备53(例如蜂窝电话、智能电话、PDA等)通信17。移动设备可随后用于通过例如与蜂窝塔57的通信55来与车辆31外部的网络61通信59。在一些实施例中，蜂窝塔可为WiFi接入点。

信号14代表了移动设备和蓝牙收发器之间的示例性通信。

可通过按钮52或类似输入指示移动设备53和蓝牙收发器15的配对，这样，指示CPU车载蓝牙收发器将与移动设备中的蓝牙收发器配对。

可利用例如与移动设备53相关联的数据计划(data-plan)、声载数据(dataover voice)或双音多频(DTMF)音调在CPU3和网络61之间传递数据。可替代地，可能需要包括具有天线18的车载调制解调器63以便通过语音频带(voice band)在CPU 3和网络61之间传递16数据。随后，移动设备53能够通过例如与蜂窝塔57的通信55以与车辆31之外的网络61通信59。在一些实施例中，调制解调器63可与蜂窝塔建立通信20以与网络61通信。如非限制性示例，调制解调器63可为USB蜂窝调制解调器并且通信20可为蜂窝通信。

在一个说明性实施例中，处理器可设有包括API的操作系统以与调制解调器应用软件通信。调制解调器应用软件可访问蓝牙收发器上嵌入模块或固件以完成与远程蓝牙收发器(例如在移动设备中发现的)的无线通信。

在另一实施例中，移动设备53包括用于语音带或宽带数据通信的调制解调器。在声载数据的实施例中，当正在传输数据期间移动设备的主人对设备说话时，可执行已知为频分复用的技术。在其它时间，当主人没有使用该设备时，数据传输能够使用整个带宽(在一个示例中为300Hz至3.4kHz)。

如果用户具有与移动设备相关联的数据计划，该数据计划可允许宽带传输且系统可使用更宽的带宽(加速数据传输)。在又一实施例中，移动设备53被安装至车辆31的蜂窝通信设备(未显示)所代替。在又一实施例中，移动设备53可以是能够通过例如(而非限定)802.11网络(例如WiFi)或WiMax网络通信的无线局域网(LAN)设备。

在一个实施例中，输入数据可经由声载数据或数据计划穿过移动设备、穿过车载蓝牙收发器、并进入车辆内部处理器3。例如，在某些临时数据的情况下，数据可存储在HDD或其它存储介质7上直至不再需要的时候。

其它可与车辆交互的来源包括具有例如USB连接56和/或天线58的个人导航设备54，或者具有USB 62或其它连接的车辆导航设备60、车载GPS设备24、或者与网络61连接的远程导航系统(未显示)。

此外，CPU可与多个其它辅助设备65通信。这些设备可通过无线连接67或有线连接69相连。同样地或可替代地，CPU可使用例如WiFi 71收发器连接至基于车辆的无线路由器73。这可允许CPU在本地路由器73范围内连接至远程网络。辅助设备65可包括但不限于个人媒体播放器、无线健康设备、移动计算机等。

使用与配对的无线设备自动建立的连接，车辆计算机系统能够备份、追踪、更新以及甚至校正无线设备数据。在出现多于一个配对的设备的情况下，至少主(或更高级别)设备会在任意给定的情况下被管理。当仅出现一个设备时，除非停用配对，对该设备将自动地发生数据管理，而无需驾驶员干预。

另外，这种系统能够利用基于互联网的工具以更新、删除以及校正存储的数据。在这种情况下，在驾驶进行时能够在后台检查例如个人完整电子邮件列表和/或电话列表。通过使用社交网站，并且假定在这些网站上粘贴的信息是准确的，车辆计算机系统能够自动地在后台主动管理无线数据。

为了更好协调客人的到达和主人(或驾驶员会见的人等等)的在场，实时追踪行驶车辆的当前位置的方法可能是有用的。如果主人能看见车辆在道路上何处，主人然后能更好地知道车辆实际上将会何时到达目的地。虽然主人是用作一个示例，车辆也可能行驶到会面的地方，比如交易场所或饭店，并且已经到场的那方可能想知道例如估算的到达时间以便于他们能推迟会议、安排请求桌椅等等。

由于为了更新而重复地给旅行的一方打电话可能是不方便并且甚至可能是危险的，并且由于行驶的一方可能对他们正在旅行通过的地方不熟悉，所以不能提供精确的位置信息，通过使用车辆的GPS坐标作为已知的地图、位置、距离和估计的车辆到达时间的参考可能是已知的。

在第一说明性实施例中，如图2所示，车辆追踪系统(例如，但不限于，来自车辆的远程服务器)接收车辆追踪请求。附加地或可选择地，查询的一方能够例如直接从智能手机向车辆发送请求(例如，如果智能手机具有绘图功能)。其它接收和传输请求和请求的数据的方法也是可能的，这些示例仅仅提供了几个典型场景。

在这个说明性实施例中，远程服务器接收所述请求201，并且联系车辆203。所述联系可能是通过与车辆通信的无线装置建立的连接，它可能是永久与车辆通信的装置，它可能通过无线网线连接等等。

一旦已经联系车辆，远程服务器给车辆发出用于验证意图的请求204。由于隐私原因，大多数(即使不是全部)驾驶员可能不想简单地被任何一方追踪，所以在这个说明性实施例中，车辆验证所述请求。

在一个说明性实施例中，验证是每个查询方每次行程的一次性方法。所以，在这个系统中，例如一旦已经在行程期间首次验证了一方，不再需要验证该方来追踪车辆行程的剩下部分。所述验证可存储在服务器上，或者所述验证可存储在车辆这边(vehicle-side)，并且可自动验证行程期间随后的每个请求。

在另外一个说明性实施例中，车辆所有者给追踪方提供车辆识别代码。这可以是永久的代码，或者它可以是每个行程改变的代码。在这个实施例中，当与请求一起传递代码时，车辆将会确认追踪请求的效力。可能希望所述代码至少是用户可定义的，因为不可改变的代码可能被先前给予代码的人所使用，但是现在，不管出于什么原因，驾驶员不希望那个人使用该代码。该代码可以简单地是例如密码，或者它可以是车辆计算机系统或用户生成的数字、字母、数字字母组合等代码。

在进一步的说明性实施例中，查询方可识别为“一直批准(alwaysapproved)”。例如，如果父母想追踪孩子的车辆，父母能够建立系统，使得车辆乘客不能拒绝父母请求。

这些只是可怎么处理验证的少数说明性示例，虽然其它用于识别的已知的和适用的方法也被认为是可用于说明性实施例且在于本发明范围内。进一步参考图3中所示的示例讨论批准。

在远程服务器请求验证之后，系统检查以确认是否批准验证205。如果请求被拒绝，方法退出206。否则，方法然后可接收车辆的GPS坐标207。虽然在这个示例中使用GPS坐标，那只是常见定位系统的一个示例，并且可执行任何适当的确定车辆的位置的方法。除了GPS坐标，在这个说明性实施例中，也接收路径数据209。

在这个实施例中，车辆装备了导航系统，并且接收编程在导航系统中的至目的地的路径数据。换句话说，接收用于当前编程的目的地的数据。但是，这个目的地可能和查询方的位置不对应。例如但非限定，如果驾驶员开始了四小时行程中的一个小时，但是已经重新编程了导航系统以寻找当地加油站，查询方可能接收对应于估算的驾驶员到达当地加油站的时间的信息。

由于这不可能是寻求的到达时间，也可随查询一起提供目的地查询，这样远程服务器(查询电话等等)一旦收到车辆的当前GPS位置便可然后计算输入目的地的估算到达时间。

有可能有这样的情形，例如，查询方从它自己的装备了GPS系统的装置(例如但不限于智能手机)输入查询。在这种情况下手机本身可实际上传输查询装置的位置作为“目标位置”(end location)，从而不需要在查询中包含最终目的地。

一旦知道了正确的目的地，通过说明书中描述的任何示例性方法，或者通过其它适当的方法，查询服务器(手机等)能够然后计算估算的到达时间并且显示例如车辆的当前位置211。虽然未示出，计算的到达时间可考虑比如但不限于天气状况、交通状况、已知的绕道、截止目前行程的车辆平均速度等要素。通过包含像这样的要素，能获得非常精确的(除任何其它中断之外)的对到达时间的估算。

图3显示了批准方法(approval process)的一个示例。在这个说明性实施例中，车辆计算机系统(或例如与车辆计算机系统配对的、包含设计的用于执行所述一个或多个说明性实施例的应用程序的智能手机或其它装置)接收用于追踪车辆的请求301。

在这个实施例中，驾驶员能预先批准(pre-approving)请求和/或系统“记住”已经在以前批准的用于追踪当前行程的相关方。如果请求不是预先批准的303，在这个实施例中，车辆计算机系统通知乘客请求在等待批准305。这可能是口头的、视觉的或其它适当的通知。相似地，乘客能通过口头输入(比如但不限于“批准”或“拒绝”)或包括但不限于指定同意或拒绝的按钮按压、触摸屏按压等的物理输入对通知作出回答。

如果请求未被批准307，系统拒绝请求并且返回拒绝309。如果请求被批准307(或如果请求被预先批准303)，系统然后检查以确认监视是否启动311。关于图4和图5更为详细地讨论了监视车辆。

如果监视启动311，接收系统设置监视状态313并且然后回复请求批准和当前车辆数据315。如果没有必要设置监视状态，那么接收系统可简单地回复同意和当前车辆数据315。

图4显示了关于监视车辆的状态的说明性实施例。在这个说明性实施例中，查询方已经请求车辆信息，并且已经批准该请求，导致设置车辆的监视状态。监视车辆可能是有用的，例如，如果所述查询方发送初始查询以确定估算到达时间，但是然后直到存在可能增加估计到达时间的事件并不希望再和车辆联系。另外或可选择地，查询方可能希望接收随着距离间隔或时间间隔的定期更新，从而允许追踪车辆而无需重复地发送对信息的请求。

在这个说明性实施例中，接收请求的系统已经将车辆的监视状态设置为“启动”并随后开始对各种推迟事件和/或行驶的时间/距离间隔来跟踪车辆的状态。

例如，如果发生路外停车(off-road)事件403(在那里车辆的GPS坐标不再对应于已知的道路)，在车辆计算或导航系统变为失效(例如由于事故或动力下降事件)的情况下所述系统可准备传输位置数据405。如果没有出现路外停车事件，或者一旦在车辆动力下降的事件中已经准备了传输，系统然后检查以确认车辆PRNDL是否处于停车状态407。这里，PRNDL(P-Park(停车挡)、R-Reverse(倒车挡)、N-Neutral(空挡)、D-Drive(驱动挡)、L-Low(低速挡))表示自动换挡车辆的档位。

如果PRNDL没有处于停车状态，然后车辆可简单地短暂地将已知的道路作为便道(比如穿过停车场)，或者车辆可简单地行驶在未知的道路上并且所以不需要更新“事件”，因为旅行时间不可能受到较大影响。

如果PRNDL是处于停车状态407，那么系统可发送当前位置更新和/或来自一个或多个车辆的外部摄像机的快照409。由于车辆处于停车状态，例如假如加汽油使旅程可能会推迟5-10分钟、假如停车吃饭使旅程可能会推迟20-40分钟等等。关于图6进一步讨论了预测推迟的时间段，但是在这个说明性实施例中，即使没有预计推迟的预测算法，查询方也可基于来自车辆摄像机的照片(大概显示了车辆的当前位置)猜测可能的推迟。

在这个说明性实施例中，一旦发送了所述数据则还设置标志，以便于符合另一个条件时在同次停车的相关方法中较晚的点不再次发送所述数据。可在适当的时间清除标志，例如，但不限于当车辆PRNDL不再处于停车状态，或者当车辆行驶时等等。所以如果系统探测到车辆处于停车状态但设置了标志415，它将会“知道”已经为这次停车发送了相关数据，并且能继续处理。如果没有设置标志415，那么系统可发送相关数据409，设置标志411，并且继续处理。

如果车辆没有处于停车状态，在这个说明性实施例中，系统然后检查以确认车辆动力是否是接通的413。如果发送/监视系统是车辆计算机系统，则在车辆动力丢失的事件中它可能将会失去电能，所以在那个例子中所述方法可自然地结束。但是，系统可能在备用电源上保持受限动力以处理紧急事件状态(比如如果车辆没有处于停车状态但是电源被切断时可能会发生的)或者在所述系统失去所有电能之前处理总结进程(wrap-up processes)。在另外一个示例中，监视系统可设于无线装置上(例如以应用程序的形式)并且所以仍然有电源即使车辆没有。

如果车辆电源是切断的413-是，系统首先检查以确定传输是否是准备好的417。在这个例子中，传输可能已经是准备好的以响应步骤403中路外停车事件的探测。如果传输已经是准备好的，系统发送位置数据/快照/任何其它相关数据。快照可在发送数据的时间里拍摄，或者一旦探测到路外停车状态就拍摄它们(或者在之间或者之前适合用于特定实施方案的任何点)。一旦发送了数据(或者没有发送)，系统检查以确认旅程是否已终止419(例如车辆到达目的地)。

如果旅程终止419，停止监视421，因为车辆已经大概到达了查询方的位置。有可能是在车辆导航系统中编程的目的地和查询方的位置不同的情况，所以在比如这个例子中，可由查询方指示旅程“终止”点而非车辆导航计算机中的当前目的地。

在这个说明性实施例中，如果旅程没有终止，监视系统检查以确认时间/距离间隔是否已经过去423。这可能是预先定义的间隔，或者所述间隔可通过查询方定义(例如但不限于每15分钟、每10英里等等)。如果间隔已经过去，那么相关的车辆数据(位置、快照等等)发送到查询方425，并且然后所述系统返回以监视事件数据(event data)。

图5显示了用于处理紧急状态的系统的说明性实施例。如果监视系统具备探测紧急事件的能力，那么在检查任何其它状态之前，系统可检查以确认紧急事件是否已经出现501。在随时出现紧急事件的情况下，监视方法默认具有该流程。在这个说明性实施例中，在探测到紧急事件501之后，监视系统首先执行任何与存在的紧急程序一致的程序503(比如但不限于通知紧急应答员、ICE联系人等等)。一旦完成这些程序，系统将发送紧急事件更新给查询方505。

在一些例子中，查询方可能是唯一定位旅行方的那个人。例如，如果查询方住在已知的道路之外，并且在不能传送给紧急应答员(由于道路名称是不知道的)的位置存在事故，发送这个更新给查询方可以允许那方然后联系紧急应答员并且通知他们车辆的估计位置。如果图片是使用一个或多个车辆摄像机拍摄和传输的，也有可能存在查询方能使用的当地的地标以识别车辆的位置并且给紧急应答员提供协助以找到车辆援助乘客。

图6显示了用于预测与车辆沿路径的停车相关联的推迟。在这个说明性实施例中，给车辆发送请求以获得位置信息的系统接收回复的所述信息和/或一个或多个来自车辆摄像机的快照601(视频也是可能的)。一旦已经收到数据，查询系统显示所述快照(例如如果查询系统是智能手机或其它能显示的装置)603，或者将快照中继给查询方用于显示603。

基于与已知的商业位置相关联的GPS数据，系统然后尝试确定位置类型是否是已知的605。例如，如果车辆停在对应于加油站的位置，则系统可假设驾驶员正在获取燃料(车辆的燃料状态也能用于帮助这个确定，因为驾驶员不可能在油箱装满时为了燃料而停下来)。

或者，如果所述位置状态相当于饭店，则驾驶员可能是为了食物停下来(但是，之前的数据，仅在几分钟之前在饭店停车可再次用来“确定”停车的目的)。

如果位置类型是不知道的，或者例如假如位置有双重目的(比如加油站/餐馆)，系统可向查询方询问与可能停车的原因相关的信息607。例如，如果位置是完全不知道的，查询方能够使用一个或多个从车辆摄像机发送的快照或视频识别位置类型。

或者，基于车辆停在停车场的哪一部分(从摄像机拍摄知道的)，用户能够确定车辆停下来是为了汽油还是食物。

如果用户不能识别停车的性质(607-否)，默认的推迟可用于调整到达时间(例如但不限于，10分钟)609。如果用户能识别位置类型611，那么可使用对应于位置类型的推迟612。

可替代地或附加地，查询用户可简单地输入估算的推迟时间613，该估算的推迟时间随后可用于调整估计的到达时间。如果没有接收到输入，可再次使用默认的推迟615。

一旦确定了推迟，因为系统具有与已知的停车位置类型关联的推迟606或者因为查询用户已经协助估算了推迟，因此方法能相应地调整估算的到达时间617并且显示新的估算的到达时间619。

只要旅程没有恢复621-否，系统检查以确认是否已经超过估算的推迟时间623。如果超过估算的推迟时间，并且旅程没有恢复，系统可调整估计的推迟时间624并且调整估计的到达时间617。

在这个说明性实施例中，作为一个非限制的示例，拖延的推迟基于位置的类型(或者原来的推迟的期间)调整。例如，非限制地，如果停车是为了食物，则系统每次可增加5分钟，但是如果停车是为了燃料，则仅仅每次1分钟。相似地，如果原来的停车是30分钟，时间可以5分钟的间隔而增加，但是如果原来的停车计划用10分钟，时间可仅以1分钟间隔而增加。

一旦旅程已经恢复，则用于停车的实际推迟是知道的，并且能知道实际的调整的估计到达时间625并且显示(或中继用于显示)所述实际的调整的估计到达时间627。

这个预测系统在比如燃料停车站之类的短的推迟可能不会改变主人的行为，但是如果知道旅客停车，例如是为了进餐，那么主人可确定在客人到达之前他们大概有额外的半小时，所以他们能进行快速的任务，否则将没有时间进行直至计划的时间。如果旅客比期望的晚恢复行程，更新的时间能发送给主人并且他们能再次相应地调整他们的行为。

由于上文描述了典型的实施例，并非意味着这些实施例说明并描述了本发明的所有可能形式。在一定程度上，说明书中使用的词语为描述性词语而非限定，并且应理解可做各种改变而不脱离本发明的实质和范围。另外，可联合各种执行实施例的特征以形成本发明进一步的实施例。

Claims (11)

1.一种计算机执行的方法，包括：

在车辆关联的计算机系统VACS处接收追踪请求；

验证所述追踪请求，以确定是否批准所述追踪请求；

当所述追踪请求被批准时，确定车辆位置；

从所述VACS将所述车辆位置传输给追踪请求相关联的计算机系统TRACS；

监视车辆的推迟事件；并且

当出现推迟事件时，向所述TRACS发送对应于所述推迟事件的数据，

其中，验证追踪请求的步骤包括：

通知车辆乘客所述追踪请求；以及，

接收来自于车辆乘客的响应于所述请求的批准。

2.根据权利要求1所述的方法，其中，接收追踪请求的步骤还包括：

确定所述追踪请求先前已经被批准；并且

当确定所述请求先前已经被批准时，使用所述VACS自动批准所述请求。

3.根据权利要求1所述的方法，其中，所述VACS是车辆计算机系统。

4.根据权利要求1所述的方法，其中，所述VACS包含在与车辆计算机系统通信的无线装置中。

5.根据权利要求1所述的方法，其中，所述推迟事件包括车辆PRNDL改变为停车状态，

其中，所述车辆PRNDL表示车辆的档位的状态。

6.根据权利要求5所述的方法，其中，所述数据包括当出现所述推迟事件时所述车辆的GPS坐标。

7.根据权利要求5所述的方法，其中，所述数据包括当出现所述推迟事件时对应于所述车辆的GPS坐标的已知位置的识别。

8.根据权利要求5所述的方法，其特征在于，所述数据包括从与所述VACS通信的车辆摄像系统拍摄的至少一个照片。

9.根据权利要求5所述的方法，其中，所述数据包括至少一个视频片段传输，通过与所述VACS通信的车辆摄像系统获取所述视频片段。

10.根据权利要求5所述的方法，其中，所述推迟事件包括通过与所述VACS通信的一个或多个车辆传感器探测到车辆事故。

11.根据权利要求1所述的方法，其中，验证的步骤包括：

在所述VACS处接收验证代码；并且

使用所述VACS核实所述验证代码。