车载硬件和软件的增强的可用性和功能的制作方法

说明性实施例总体上涉及用于增强车载硬件和软件的可用性和功能的方法和设备。

背景技术：

车辆包括越来越强大的计算系统。驱动着车载信息娱乐系统、远程信息处理系统以及一套车载软件模块和电子控制单元(ecu)，车载计算机具有强大且经常未被使用的处理能力。车辆传感器也在车辆行驶时提供关于车辆和周围环境的大量数据，而同样，在许多情况下，这些数据以及提供和收集这些数据的传感器经常未被使用。

技术实现要素：

在第一说明性示例中，移动装置包括处理器，所述处理器被配置成结合在所述移动装置上执行的应用程序来请求使用车辆资源。所述处理器还被配置成接收使用所述车辆资源的费用的通知。所述处理器还被配置成向包括所请求的资源的车辆发送支付所述费用的协议，并且响应于所发送的协议而从所述车辆资源接收数据。

在第二说明性示例中，车辆包括被配置成从远程源接收使用车辆资源的请求的处理器。所述处理器还被配置成基于资源的状态来确定车辆是否能够满足请求。所述处理器还被配置成响应于确定车辆能够满足所述请求而向远程源发送使用资源的费用，并且响应于从所述远程源接收到支付费用的协议而根据结合费用限定的使用期限来提供对资源的使用。

在第三说明性示例中，一种车辆包括被配置成确定可供远程源使用的一个或多个车辆资源的处理器。所述处理器还被配置成广播所确定的一个或多个资源的可用性。所述处理器还被配置成从远程源接收使用至少一个车辆资源的请求，并且响应于确定所述至少一个资源当前未被车辆使用并且可供远程源使用，提供对所述至少一个资源的使用以换取来自远程源的支付协议。

附图说明

图1示出了说明性数据共享系统；

图2示出了用于移动装置的非车载处理的说明性示例；

图3示出了请求满足过程的说明性示例；

图4示出了用于向远程实体提供数据的替代过程；以及

图5示出了说明性按需请求处理过程。

具体实施方式

根据需要，本文公开了详细的实施例；然而，应理解，所公开的实施例仅是说明性的，并且可以以各种和替代的形式并入。附图不一定按比例绘制；一些特征可能被放大或最小化以示出特定部件的细节。因此，本文公开的具体结构细节和功能细节不应被解释为是限制性的，而是仅解释为教导本领域技术人员以各种方式采用所要求保护的主题的代表性基础。

随着车辆的自主性越来越高，车载计算和传感器套件的能力将呈指数级增长，但是在许多情况下，车辆没有利用许多车载传感器并且没有使用很多车载计算能力。说明性实施例允许连接到车辆计算机的移动装置在车辆计算机上非车载地进行处理，以既加快移动装置的处理速度又节省移动装置电池寿命。此外，移动装置用户以及甚至应用程序开发人员可以请求和使用车辆传感器数据来改进应用程序的功能和/或改进所需数据的质量和数量。

通过允许乘客使用车载处理和数据，以及通过允许车辆所有者或乘坐者将数据出售给请求应用程序，可以实现新的收入模式和新的更快地处理并改进移动电池寿命的模式，而无需向现有车辆系统添加任何重要硬件。

图1示出了可与说明性实施例结合使用的说明性数据共享系统。在该示例中，示出了说明性车辆101，其包括至少一个车载处理器103。车辆101可以是手动驾驶车辆或自主车辆。尽管自主车辆通常将具有更大的计算能力和传感器功能，但是它们对这些系统的使用需求也更大，但是任何一种类型的车辆都适合于说明性实施例，因为手动驾驶车辆和自主车辆都可能有共享计算和共享传感器数据的机会。

车辆101具有提供蜂窝连接功能的远程信息处理控制单元(tcu)105。该单元105允许车辆101与云130中的远程系统对话，所述远程系统在该示例中包括数据服务应用程序131以及一个或多个应用程序服务器133、135。数据服务应用程序131可以由原始设备制造商(oem)进行管理，并且可以向车辆通知未决数据请求或将数据出售给请求实体的机会。例如，天气或导航应用程序提供商可能想要关于特定地点的天气状况或道路/交通状况的本地化数据。应用程序服务器133、135可以从数据服务131服务器请求该信息，所述服务器可以识别具有适当的传感器和与数据请求相对应的位置的车辆。数据服务131服务器然后可以联系那些车辆101以确定车辆是否可以以及将获得并出售所请求的数据。

在其他示例中，应用程序服务器133可以直接与车辆101通信，这是因为其被许可这样做，或者因为其正在支持驻留在车辆上的应用程序119。当应用程序服务器133通信以支持车载应用程序119时，服务器133可以通过车载应用程序119请求数据。当没有对应的车载应用程序119时，服务器133可以直接从车辆101请求数据。

在该示例中，车辆还包括wi-fi收发器107和蓝牙收发器109，它们可用于与车辆中的移动装置120通信。除了提供通信服务外，例如，wi-fi收发器还可以向请求应用程序提供由收发器在车辆行驶时识别的公共热点列表。因此，例如，如果应用程序开发人员想要在某个地点包括关于可用公共热点的数据，则一个或多个车辆101可以检测那些网络并将关于其存在的信息提供给开发人员。

车辆101还包括人机接口(hmi)111，所述hmi111通常是触敏显示器。该接口可以用于批准数据请求以及控制和设置可以共享什么数据、何时可以共享数据、数据费用、任何必要的匿名性等的设置。车辆101还包括多个车载传感器113。这些可以包括但不限于位置(gps、glonass)、内部/外部相机、行驶数据(方向、行驶距离、速度等)、惯性传感器、磁力计、污染传感器、通过悬架进行的道路质量感测、外部声音等。自主车辆还可以包括高质量的激光雷达、雷达或其他被设计成在车辆101行驶时精确地绘制其周围的物理环境的地图的传感器。

大部分或全部传感器113具有实际的车辆方面用途，但是除非有特定原因发生而要求车辆101从给定传感器113获取数据，否则它们通常也未被使用。因此，甚至在车辆101也需要数据的情况下，这些传感器113也可被用来向许多感兴趣方提供可共享/可出售的数据。传感器113可以具有原生轮询速率(它们收集/报告数据的频率)，并且也可能会被指示以与给定请求相对应的速率进行轮询。除非轮询对原本需要的计算资源带来了不必要的压力，否则在车辆101行驶时，车辆101可以轻松地收集和共享来自这些传感器113的数据。

车辆101还可以包括导航计算机115。该计算机可以比移动装置120的计算机更强大，或者可以访问对移动装置120的原生导航功能有用的更高质量的位置信号或其他导航数据。此外，全部被导航系统115所跟踪或可跟踪的路线数据、路线推荐、兴趣点和一般旅行习惯可能是应用程序开发人员感兴趣的。因此，应用程序服务器133、135可能够从车辆101计算系统的导航系统115请求导航数据。

车辆101还包括各种车载系统117，诸如制动系统、悬架系统、暖通空调(hvac)、娱乐系统、诊断系统等。这些系统117中的一些或全部具有并且可以报告各种车载移动装置120和应用程序开发人员都感兴趣的数据。例如，车载用户可以利用某些车辆101系统数据来复制象征当前车辆101状况的游戏环境。移动应用程序开发人员可能想了解组件磨损数据、娱乐选择、hvac设置以及各种其他信息，这些信息可以帮助开发人员创建能够基于对从其收集数据的人们的习惯的观察来向其他用户提出建议的应用程序。

许多先前的车辆101系统117由电子控制单元(ecu)118支持，所述ecu118通常也能够获得并提供数据的特定实例。这些ecu118还可以具有与其相关联的计算能力，当ecu118原本没有用于其主要预期目的时，可以在分布式计算模型中使用这些计算能力来改进移动装置120的处理。

车辆101还可以包括一个或多个车载应用程序119。这些应用程序119可以支持或改进车载功能，以及提供非车载地向应用程序服务器133、135出售数据或与之共享数据的机会。可以通过共享数据的协议来免费使用一些应用程序119，并且在其他情况下，车辆101的所有者或乘坐者可能够响应于来自应用程序服务器133、135的一个或多个请求而基于共享数据来生成利润或费用抵消(例如，针对乘坐)。

乘坐者移动装置120可以通过移动装置120的收发器(包括wi-fi收发器125和蓝牙收发器127)与车辆101通信。移动装置120还包括处理器121，并且能够通过蜂窝收发器123进行蜂窝通信。通过蜂窝收发器123，移动装置120可以与云130通信，并且可以直接与应用程序服务器133、135通信，应用程序服务器133、135可以支持安装在移动装置120上的应用程序129或者可以通过移动装置120从车辆101请求数据。

例如，移动装置120可以无线地或通过有线usb连接连接到车辆101。当车辆101具有移动装置120感兴趣的可用处理能力或传感器数据时(例如，如车辆101所通告或移动装置120所请求的)，移动装置120可以将用于处理的数据发送给车辆处理器103、ecu118或其他可用的分布式计算资源。在其他示例中，移动装置120可以从车辆101以某些轮询速率请求某些数据类型，并且车辆101可以通过以通过直接连接或者经由数据的无线广播返回的所请求的轮询速率提供移动装置120可以订阅的数据来进行响应。

通过使用此类系统，移动装置120可以例如通过使用结合有惯性传感器和磁力计的车辆gps来改进地图绘制。这样既可以节省移动装置的电池寿命，又潜在地提供更准确的信息。移动装置还可以利用例如hvac和信息娱乐设置等来增强移动应用程序的体验。

通过允许移动装置120使用处理资源，以及通过允许车辆所有者向移动装置120和云服务器133、135出售数据，车辆所有者或甚至乘坐者可以使用已经存在于车辆101基础设施中的技术来生成新的收入流。

可以例如通过应用程序编程接口(api)来实现数据传送，类似于编程接口如何被实例化以订阅已经在移动装置120上的车载传感器数据，移动应用程序129可以通过所述api创建到车辆101的数据链路以获得输入数据(通过usb或wifi传送)。车辆101可以在每个传感器的基础上按应用程序内确定的轮询速率来广播对所请求的数据的更新。

api的实施可取决于各个开发人员，但是可以提供可从车辆101获得的一套数据输入。应用程序129可以向车辆101轮询具有功能、轮询速率和许可的策略表。将创建白名单(例如，在云130上更新的)，以使应用程序129能够获得可用信息的一般类型，但是各个车辆101可以确定是否以及何时将或能够共享给定数据类型。

图2示出了可由例如移动装置处理器121执行的用于移动装置的非车载处理的说明性示例。在该示例中，移动装置120在201处确定执行应用程序129需要特定处理功能或数据集。该非车载功能可被构建到移动装置120操作系统中(以重新定向某些数据请求)，或者其可被构建到应用程序129中，应用程序129被构建为利用与提供此类功能的车辆101的交互。如果在203处处理或数据不需要或不受益于非车载，则装置120在205处将仅使用原生处理/传感器来满足装置120的需求。在一些情况下，例如，当电池电量低时，移动装置120可尝试尽可能多地进行非车载处理以保留电池寿命。在其他情况下，当应用程序129(经由与当前车辆101有关的白名单)识别某种类型的改进的数据可以通过与车辆101进行通信而获得时，移动装置120可以仅在存在大量处理需求或非车载数据请求的情况下才尝试非车载处理。

如果装置120确定非车载可能是有用的，则装置120可以在207处请求服务。该服务对应于可从车辆101获得的功能(处理/数据提供)，所述功能由与车辆101相关联的白名单或车辆101对可用处理/数据提供的广播所识别。如果在209处所请求的服务可用，则装置120还在211处请求许可。某些功能可能需要oem批准的应用程序，因此，即使某个数据集可用，装置120或应用程序129也可能不被批准访问该数据。处理或数据的可用性通常将取决于车辆101当前正在使用处理能力和/或数据来做什么，以及驾驶员/乘客/所有者是否已批准所请求的数据类型的共享处理或共享。

如果在211处装置120或应用程序129被批准访问所请求的资源，则装置120可以在213处发送数据以进行处理，或者在213处订阅与所请求的数据相对应的传感器数据的广播。在许多情况下，可能存在与使用车辆101资源相关联的费用，并且装置120还可以在215处处理对所请求的数据或处理的支付。然后，装置120以周期性的轮询间隔(指定应用程序129/装置120或指定车辆101)接收数据，并且一旦请求完成并得到满足，装置120就可以在217处取消订阅数据广播。

装置120可能需要订阅某个数据集以便接收所请求的数据，并且当装置120订阅时，车辆101可以跟踪向装置120提供了多少个数据实例。如果装置120正在按实例请求进行支付，这是有用的，但是在其他模型中，装置120可以为数据订阅支付固定费率，然后装置120可以确定使用了多少个数据点。订阅数据可以允许装置120接收用于解密广播数据的密钥，或者，在更简单的模型中，只要一个装置120订阅了某种数据类型，车辆101就可以简单地通过可用的通信信道广播该类型的数据，直到没有装置120订阅为止。后一种模型将允许第二装置在广播期间有效地免费获得数据，但是其也将避免其他安全协议交换，并且可能更易于实施。

图3示出了可由例如车辆101处理器103执行的请求满足过程的说明性示例。在该示例中，车辆101从装置120接收处理或数据请求。而且，在该示例中，即使在装置所有者没有使用该应用程序129的情况下，车辆101也可以从在装置120上执行的应用程序129接收请求。某些应用程序129可以被设计成在可用时利用车辆101的数据，因此即使装置120所有者不明确需要该数据，也可以从车辆101请求某些数据。在这种情况下，与装置120所有者不同，应用程序129开发人员可能会为所请求的数据付费，并且在乘车共享情况下，装置120所有者可能实际上是在向应用程序129提供商出售数据以抵消乘坐费用。

例如，增强的导航应用程序129可以使用车辆数据来改进用户体验。这可以包括当前乘客并不特别感兴趣的各种数据(交通、路况、天气等)，但是前往当前乘客当前所在位置的其他人对这些数据可能感兴趣。同时，乘客可有权将给定打车服务的数据出售给任何请求实体。因此，乘客可以选择将本地传感器数据出售给驻留在乘客带入车辆101中的那个装置120上的应用程序129。这将鼓励经常出行的人出于数据提供的目的将许多应用程序129加载到他们的电话120上，即使那些人出于其他原因很少或永远不会使用那些应用程序129。

在另一个示例中，车辆101可以从数据服务131服务器或应用服务器133、135接收请求。这些基于云的实体可能够识别具有现场提供所需数据期望的特征(型号、速度、类型、位置等)的特定车辆101，并且基于云的实体可以直接从已识别的车辆101请求数据。驾驶员或乘客可以再次确定是否应将数据出售给服务器，以及是否满足请求可能取决于数据的可用性和共享条款。

在车辆101在301处接收到请求之后，车辆101可以在303处确定所请求的处理或数据是否可用。在处理的情况下，车辆101可以确定车辆101本身是否需要附加的处理功能，并且在数据的情况下，车辆101可以确定车辆101是否具有共享所请求的数据的功能和能力。所述功能可以取决于所安装的传感器以及这些传感器当前用来做什么，并且所述能力可以取决于与数据共享有关的设置以及为了换取获得和提供所请求的数据车辆101所经历的任何功率消耗(即，低功率状态车辆101可忽略所有请求，以便保留用于驾驶目的的车载功率)。

如果所请求的处理或数据当前不可用，但是将来可能可用，则车辆101可以在305处将请求排队，并且可以在服务可用时通知装置120或其他请求实体。如果在305处所请求的服务当前是可用的并且在307处基于共享或许可设置而未被允许，则车辆101可以在309处拒绝请求。

否则，车辆101可以在311处向请求实体提供订阅访问，从而允许所述实体订阅数据共享请求中的某种类型的数据，或者可以在分布式计算请求的情况下简单地满足处理请求。如果装置120或其他实体要订阅数据，则车辆101可以在313处添加装置120或实体，并且可以与装置120或实体共享任何必要的解密或信道识别参数，以允许装置120或实体获得所请求的结果。然后，在315处，车辆101可以以周期性的轮询间隔向装置120或其他实体广播数据(或通过直接通信信道直接发送数据)。

图4示出了用于向远程实体提供数据的替代过程，所述过程可由例如车辆101处理器103执行。在该示例中，车辆101在401处从远程实体接收远程请求。该远程实体可以是数据服务服务器131、远程应用程序服务器133、135，或甚至是通过在车辆101内的移动装置120上执行的应用程序129发送请求的远程服务器133、135。

再者，如果在403处数据不可用，则车辆101在405处向请求实体通知当前不可用。由于远程实体经常需要有关特定车辆位置或地点的数据，因此所述实体在将来的某个时间点可能对数据不感兴趣。在这种情况下，车辆101在407处确定数据请求是否为现场请求，该现场请求是与车辆位置或其他临时参数相关的一次性请求。如果在407处不可用数据对应于现场请求，则车辆101在409处拒绝所述请求，因为所述请求所基于的车辆101的状态很可能在数据变得可用于共享时发生改变。

如果所述请求是持续性请求(例如，应用程序服务器133、135想要收集由车辆wi-fi收发器107沿着路线识别的所有无线网络的标识)，则车辆101可以在411处处理付费和数据交换协议过程。这通常将涉及指定满足条件、价格和支付价格的协议以及从请求实体接收到支付格式。

一旦在411处完成了支付和协议握手和协商，则车辆101在413处确定所述请求是否是现场请求。如果所述请求是一次性现场请求，则车辆101在415处获得所请求的数据，并且在417处向请求实体发送所述数据。

另一方面，如果所述请求是需要按间隔进行持续报告的订阅类型请求，则车辆101在419处设置报告间隔。该间隔可以由请求实体指定，或者对于给定的传感器或车辆101可以是固定的。在其他示例中，驾驶员或所有者可以指定给定传感器的轮询/报告间隔。车辆101还可以在419处设置报告的持续时间，例如包括在x时间内、在n英里内或直到旅程结束一直报告。在许多情况下，请求实体将基于报告的数据总量进行支付，因此，所述实体将有动机指定准确的报告持续时间。

一旦在421处在指定的持续时间内完成了报告，车辆101就可以以在411处商定的方式处理所述请求的支付。

图5示出了说明性按需请求处理过程。该过程可由车辆101处理器103或结合移动装置120处理器121工作的车辆101处理器执行。在一些情况下，车辆驾驶员或所有者可能够批准请求，而在其他情况下，乘客可有权批准请求。谁有权批准请求(以及谁从支付中受益)通常是由协议决定(例如，共乘公司u允许乘坐者出售数据以支付乘车费用)或由出售什么样的数据决定(例如，关于乘客的人口统计和乘客目的地可以在乘客的控制下，而制动器磨损数据可以在驾驶员的控制下)的问题。

车辆101在501处接收请求，并且基于诸如先前参数的预定义参数来确定谁适合批准所述请求。然后，在503处，如果适当的实体批准所述请求，则车辆101在507处处理所述请求的计费。因此，例如，如果接收到针对目的地和乘客人口统计的请求，则车辆101可以确定乘客应批准所述请求，并且将所述请求发送给乘客移动装置120以供批准。在这种情况下，满足请求的价值可以抵消乘车费用或存入乘客帐户。

另一方面，如果接收到制动器磨损请求，则车辆101可以确定驾驶员适合批准所述请求并且将所述请求发送到hmi111以进行驾驶员交互和批准。在该情况下，满足请求的价值可以计到驾驶员帐户。当在503处接收到批准时，车辆101然后在509处根据在507处商定的付费向实体发送数据。如果在503处没有接收到批准，则车辆101可以在505处简单地拒绝所述请求。

取决于示例的变型，用于执行说明性实施例等的编程指令可以由适当的处理器执行，所述处理器包括但不限于车辆处理器、云处理和/或移动装置处理器。非暂时性存储介质(诸如但不限于硬盘驱动器、固态驱动器和其他用于存储编程指令的存储介质)可以存储指令，从而允许处理器访问该存储介质以执行指令以执行说明性实施例等。

在本文讨论的说明性实施例中的每一个中，都示出了可由计算系统执行的过程的示例性、非限制性示例。关于每个过程，执行所述过程的计算系统可以为了执行所述过程的有限目的而变为被配置为专用处理器以执行所述过程。并非所有过程都需要完整地执行，而是被理解为可以被执行以实现本发明的要素的过程类型的示例。可以根据需要在示例性过程中添加或移除另外的步骤。

关于在附图中描述的示出说明性过程流的说明性实施例，应注意，为了执行这些附图示出的示例性方法中的一些或全部，可以暂时启用通用处理器作为专用处理器。当执行提供指令以执行方法中的一些或全部步骤的代码时，处理器可暂时重新用作专用处理器，直到所述方法完成为止。在另一示例中，在适当的程度上，根据预先配置的处理器起作用的固件可致使处理器充当为执行所述方法或其一些合理变型而提供的专用处理器。

虽然上文描述了示例性实施例，但并不意指这些实施例描述本发明的所有可能的形式。相反，说明书中使用的词语是描述性的词语，而不是限制性的词语，并且应理解，在不脱离本发明的精神和范围的情况下，可以进行各种改变。另外，各种实施的实施例的特征可以以逻辑方式组合，以产生本文描述的实施例的情境上合适的变型。

根据本发明，提供了一种移动装置，其具有：存储应用程序的存储器；以及处理器，其被配置成结合在移动装置上执行应用程序来请求使用车辆的车辆资源；接收使用车辆资源的费用的通知；向车辆发送支付费用的协议；并且响应于发送的协议而从车辆资源接收数据。

根据一个实施例，所述请求由移动装置的用户以输入请求的形式明确地发起。

根据一个实施例，响应于检测到与车辆的可用连接以及对由应用程序限定的车辆资源的使用，所述请求由应用程序被动地发起。

根据一个实施例，响应于与车辆相关联的白名单将车辆资源识别为可供使用以及对由应用程序限定的车辆资源的使用，所述请求由应用程序被动地发起。

根据一个实施例，响应于车辆对可用资源的广播将车辆资源识别为可供使用以及对由应用程序限定的车辆资源的使用，所述请求由应用程序被动地发起。

根据一个实施例，对车辆资源的使用包括对车辆计算循环的使用。

根据一个实施例，对车辆资源的使用包括对车辆传感器的使用。

根据一个实施例，对车辆资源的使用包括对由车辆收集的数据的使用。

根据本发明，提供了一种车辆，其具有：无线收发器；以及处理器，其被配置成经由所述无线收发器从远程源接收对车辆资源的使用的请求；基于资源的状态确定车辆是否能够满足请求；响应于确定车辆能够满足该请求而向远程源发送使用资源的费用；并且响应于从远程源接收到支付费用的协议而根据结合费用限定的使用期限来提供对资源的使用。

根据一个实施例，远程源包括车辆内的移动装置。

根据一个实施例，远程源包括与车辆通信的远程服务器。

根据一个实施例，对车辆资源的使用包括对车辆传感器的使用。

根据一个实施例，对车辆资源的使用包括对车辆计算循环的使用。

根据一个实施例，对车辆资源的使用包括对由车辆收集的数据的使用。

根据一个实施例，处理器还被配置成在发送费用之前将请求呈现给车辆乘员以供批准，并且其中所述发送费用取决于来自乘员的批准输入。

根据本发明，提供了一种车辆，其具有：无线收发器；以及处理器，所述处理器被配置成经由无线收发器确定可供远程源使用的一个或多个车辆资源；广播所确定的一个或多个资源的可用性；从远程源接收使用至少一个车辆资源的请求；并且响应于确定所述至少一个资源当前未被车辆使用并且可供远程源使用，提供对所述至少一个资源的使用以换取来自远程源的支付协议。

根据一个实施例，广播包括使用每个资源的费用。

根据一个实施例，广播包括针对收集数据的一个或多个资源中的资源的报告循环。

根据一个实施例，所述处理器被配置成响应于确定车辆当前正在使用至少一个资源，将请求排队直到至少一个资源未被车辆使用为止。

根据一个实施例，所述处理器被配置成响应于来自与车辆进行无线通信的移动装置的请求可用车辆资源列表的请求，广播所确定的一个或多个资源的可用性。