User authentication direct data stream for vehicle data

Abstract

One or more aspects of this disclosure relate to the configuration and management of data communications associated with a vehicle. Illustratively, aspects of this application relate to the management of data communications for obtaining data generated or collected by a vehicle (e.g., "vehicle data"), which may include, but are not limited to, logs of information previously collected or generated by sensors and processing components, current vehicle data, or third-party data collected by the vehicle. In another exemplary example, aspects of this application relate to the management of data communications for providing a vehicle with configuration data or executable code, such as for a diagnostic application or repair application.

Description

Technical Field

[0001] [Cross - Reference to Related Applications] This application claims priority to U.S. Provisional Patent Application No. 63 / 497,687, entitled "USER AUTHORIZED DIRECT DATA STREAMING FOR VEHICLE DATA," filed on April 21, 2023, and U.S. Provisional Patent Application No. 63 / 498,240, entitled "USER AUTHORIZED DIRECT DATA STREAMING FOR VEHICLE DATA," filed on April 25, 2023. Each of the above applications is hereby incorporated by reference in its entirety into this specification.

Background Art

[0002] Generally speaking, computer devices and communication networks can be used to exchange data and / or information. In a general application, a computer device can request content from another computer device via a communication network. For example, a user on a personal computer device can use a browser application to request a content page (such as a network page, a web page, etc.) from a server computer device via a communication network (such as the Internet). In this example, the user computer device can be called a client computer device, and the server computer device can be called a content provider. In another embodiment, the user computer device can collect or generate information and provide the collected information to the server computer device for further processing or analysis.

[0003] Generally speaking, various vehicles, such as electric vehicles, internal combustion engine vehicles, and hybrid vehicles, can be equipped with various sensors and components to facilitate operation. In certain scenarios, the vehicle owner or vehicle user may designate a third party to whom at least some of the data generated or collected by the vehicle will be provided. Typically, vehicle information is first provided to a content provider, and then subsequently provided to third parties by the content provider. [Overview of the project]

[0004] Several embodiments of systems, methods, and non-temporary computer storage media are described. Exemplary operations include causing a processor or computer to respond to connection information from a third-party network, wherein the connection information includes a public fleet key, the received public fleet key is used to authorize the vehicle to receive the public fleet key from a mobile device paired with the vehicle; analyzing a vehicle transmission configuration to be transmitted to the vehicle, wherein the vehicle transmission configuration includes instructions for the type of vehicle data to be streamed to the third-party network, information describing how the vehicle connects to the third-party network, and a specific certification authority authorized to verify the third-party network, and the vehicle transmission configuration is signed based on a secret fleet key associated with the third-party network; and transmitting the vehicle transmission configuration to the vehicle, wherein the vehicle is configured to identify one or more network locations from which vehicle data is streamed based on the vehicle transmission configuration, the vehicle to verify the network locations using the specific certification authority, and the vehicle to transmit the type of vehicle data to the third-party network.

[0005] The operation may include one or more operations that cause a processor or computer to provide a third-party network with a public schema that identifies the types of available vehicle data, and the vehicle transmission configuration represents a subset of the types of available vehicle data. The vehicle stores a fleet public key based on receiving the fleet public key from a mobile device, and the vehicle uses the fleet public key to verify the vehicle transmission configuration. The mobile device is either communicating wirelessly with the vehicle over the network or locally wirelessly with the vehicle. A specific type of vehicle data is assigned an alias, and the vehicle associates a specific type of vehicle data with an alias. The vehicle generates event data corresponding to the alias, and the vehicle associates the event data with a specific type of vehicle data. Transmission takes place over an encrypted communication link between the third-party network and the vehicle.

[0006] The following describes systems, methods, and non-temporary computer storage media according to several embodiments. Exemplary operations may include receiving a fleet public key associated with a third-party network via a mobile device paired with a vehicle, the vehicle being configured to generate event data associated with various types of vehicle data, the event data being generated based on the use of sensors or on the operation of the vehicle by a user, and analyzing a vehicle transmission configuration received from a management network associated with the vehicle, the vehicle transmission configuration including instructions for a particular type of vehicle data to be streamed to the third-party network, information describing how the vehicle connects to the third-party network, and a specific certification authority authorized to verify the third-party network, the vehicle transmission configuration being signed based on a secret fleet key associated with the third-party network, and a processor verifying the vehicle transmission configuration based on the fleet public key, and transmitting a particular type of vehicle data to the third-party network, the vehicle identifying one or more network locations to stream a particular type of vehicle data based on the vehicle transmission configuration, and the vehicle verifying the network locations using a specific certification authority. [Brief explanation of the drawing]

[0007] This disclosure is described herein with reference to drawings of specific embodiments, which are intended to illustrate but not limit the disclosure. The accompanying drawings incorporated herein and forming part of this disclosure are for illustrative purposes only and may not be to scale.

[0008] [Figure 1] This is a block diagram of an exemplary environment for providing vehicle data communication access according to one or more aspects of the technology of the present disclosure.

[0009] [Figure 2]This is a block diagram of a vehicle-compatible environment according to one or more aspects of the technology of this disclosure.

[0010] [Figure 3A] This is a block diagram of an exemplary architecture for implementing the processing components on the vehicle described herein.

[0011] [Figure 3B] This is a block diagram of an exemplary architecture for implementing the third-party network described herein.

[0012] [Figure 4A] This block diagram illustrates an example of interaction between a vehicle, a third-party network, and a management network.

[0013] [Figure 4B] This block diagram shows another example of interaction between a vehicle, a third-party network, a pair of mobile devices, and a management network.

[0014] [Figure 5] This is an exemplary process flowchart for a vehicle authentication routine that initiates data streaming to a third-party network.

[0015] [Figure 6] This is an exemplary process flowchart for a third-party authentication routine that initiates streaming data associated with a vehicle.

[0016] [Figure 7] This is an exemplary process flowchart for an exemplary routine of registering a vehicle to a fleet. [Modes for carrying out the invention]

[0017] Generally speaking, one or more aspects of this disclosure relate to the configuration and management of data communications associated with a vehicle. Illustratively, aspects of this application relate to the management of data communications for obtaining data generated or collected by a vehicle (e.g., "vehicle data"). Illustrative data may include current vehicle information (e.g., information collected or generated by sensors and processing components), vehicle information logs, and third-party data collected by the vehicle. In another exemplary example, aspects of this application relate to the management of data communications for providing a vehicle with configuration data or executable code, such as diagnostic or repair applications.

[0018] According to exemplary embodiments, one or more aspects of this application relate to the management and accessibility of vehicle data communications provided to authenticated and authorized third parties. Exemplarily, a network service provider facilitates interaction between vehicle owners / users and third parties accessing their respective vehicle data. The network service provider can facilitate initial authentication for access to vehicle data, provide access to vehicle data to authenticated and authorized users, and manage the revocation of vehicle data access rights.

[0019] In some embodiments, the processed information having sensor information processed by a controller, logic unit, processor, etc. and additional information generated can include the information provided by the components. For example, a vision system may use inputs from one or more camera sensors and provide an output corresponding to the identification of environmental conditions regarding the vehicle. In this example, the vision system may optionally identify an object disposed proximate to the vehicle along with a signal indicating the movement of the object. In some embodiments, additional sensor (e.g., ultrasonic, radar, etc.) information may be acquired. In some embodiments, the control component can use additional information obtained or associated from a positioning system, a calendar system, or a time-based system. In yet another example, the historical information can be incorporated or used as a separate information source by the control component to process at least a portion of a set of information sources such as the detected vehicle speed, external temperature measurement, and the operating state of the windshield wiper, vision system (e.g., camera input), location identification system (e.g., GPS system), timing information, the operating state of the radar component, etc.

[0020] As described above, conventional techniques for managing data communication between a vehicle and a third party require that vehicle data be first transmitted to a centralized server, such as a content provider, where the vehicle data is stored. After the vehicle data is stored in the centralized server, the centralized server determines to which third party the vehicle data is to be transmitted. For example, in a conventional technique, vehicle data may be collected by the vehicle and provided to a content provider such as an automobile manufacturer or another centralized server. The content provider may then provide the vehicle data to one or more third parties.

[0021] Conventional approaches to vehicle data management may require a content provider to allocate resources such as computing and labor resources to maintain the data flow between a vehicle and a third party and store a large amount of vehicle data. Additionally, the content provider may be required to allocate resources to separate or isolate vehicle data for each third party, filter vehicle data based on third party preferences, and control when vehicle data is collected and sent to a third party. These requirements may also introduce additional latency between when vehicle data is collected and when a third party receives the data. Further, vehicle owners / users may have little or no control over which vehicle data is collected and which third parties the vehicle data is sent to.

[0022] To address at least some of the inefficiencies described above, a management network can facilitate a direct and secure data connection between a vehicle and a third party for streaming vehicle data to the third party. The management network can provide a service for initializing and maintaining authentication information used to create a direct data connection between the vehicle and the third party. While any direct secure data connection can be used for streaming data between the vehicle and the third party, for illustrative purposes, a mutually authenticated encrypted data stream such as mutual transport layer security (“mTLS”) is described. However, those skilled in the art will understand that one or more aspects of the present application are not limited to the use of the mTLS protocol and that variants or alternatives of mutually authenticated communication protocols may be implemented.

[0023] As described herein, mutually authenticated encrypted data streams, such as mTLS, may require each party to establish a communication channel for data streaming and authenticate the other party's identity. Exemplarily, according to an mTLS-based mutual authentication technique, two (or more) computer devices encrypt and decrypt data using unique computer instructions called public and private keys. When a public key is used to encrypt a portion of the data, only the private key associated with the public key may be used to decrypt that portion of the data. Exemplarily, mTLS may use a computer data file called a certificate to authenticate the identity of the parties. For authentication purposes, a certificate may contain authentication information, such as a public key, a statement of the entity that issued the certificate, called a Certificate Authority, the certificate's expiration date, and other information used for authentication. Exemplarily, mTLS may require each party to present a certificate to the other before authentication can begin, before data transfer can commence. In more detail, in some embodiments, the information contained in, or having in, a certificate may also include additional information used for the exchange of streaming data between the two computer devices.

[0024] Exemplary, the management network can provide services to facilitate the configuration of direct and secure communication channels, such as an mTLS-based connection between a vehicle and a third-party destination. However, according to aspects of the present application, the management network is configured not to participate in secure communication channels or to receive data exchanged between the vehicle and the third-party destination. In some embodiments, the management network may function as a certificate authority and issue certificates for the vehicle and third parties used in establishing and configuring mutually authenticated communication channels, i.e., mTLS connections. In some embodiments, the management network may control the expiration dates of the certificates. In other embodiments, the issuance and expiration dates of the certificates may be determined by another party, such as the vehicle owner, a third party, or another entity.

[0025] For example, by configuring a directly mutually authenticated communication channel such as an mTLS connection, a third party may directly receive vehicle data from a vehicle without requiring the data to be received, processed, transmitted, or stored by a management system (or any specific computer device associated with a management system). This allows one or more third parties to directly obtain vehicle data, such as one or more of the following: GPS data, speed data, fuel or battery status data, navigation data, and autonomous driving information (e.g., activation of autonomous driving functions, termination of autonomous driving, specific objects or signals determined by autonomous driving functions).

[0026] Data communication also enables third parties to diagnose vehicle performance, identify potential problems, and facilitate pre-ordering of parts. It also allows third parties to have the vehicle execute executable code or configurations that facilitate diagnosis, repair, updates, upgrades, etc. The configuration of the types of data transmitted to third-party destinations can be pre-configured in the vehicle as part of the provisioning of mutual authentication certificates, or transmitted by a management service.

[0027] Exemplary, a vehicle owner may control one or more attributes of a data communication channel, including the duration of access, the type of access, and vehicle data restrictions. Specifically, according to embodiments of this application, once a mutually authenticated communication channel is established between the vehicle and one or more third-party destinations, user controls may be further implemented to control aspects of the streaming data content, including but not limited to the initiation of streaming data, the continuation of streaming data, and the termination of streaming data. In some embodiments, the user controls may be further configured to require some form of physical proximity to a selected vehicle, such as by limiting the control to an in-vehicle interface, a short-range wireless communication network, or a verified mobile application (e.g., a scanned barcode). As used herein, streaming data refers to information provided by the vehicle to a third party, and the information is pushed by the vehicle (e.g., as a stream). In some embodiments, the information may be requested (e.g., pulled) by the third party from the vehicle.

[0028] While various embodiments are described according to exemplary combinations of embodiments and features, those skilled in the art will understand that these examples and feature combinations are illustrative in nature and should not be construed as limiting. More specifically, embodiments of this application may be applicable to various types of vehicle data or vehicle processes. Furthermore, while embodiments of this application may describe embodiments relating to a single vehicle, this application may be applicable to multiple vehicles, such as a fleet of vehicles. However, those skilled in the art will understand that embodiments of this application are not necessarily limited to any particular type of vehicle data, data communication, or exemplary interaction between a third party, a customer, and a management network.

[0029] Exemplary block diagram Figure 1 is a block diagram of an exemplary system 100 for providing vehicle data communication access according to one or more aspects of the technology of the present disclosure. System 100 may include a network 150, which connects a set of vehicles 110 (e.g., a fleet of vehicles), a management network 120, and one or more third-party networks 130. Components may correspond to software modules implemented or run by one or more external computer devices, which may be separate standalone external computer devices. Thus, the components of the management network 120 should be considered logical representations of services and do not require a specific implementation form on one or more external computer devices.

[0030] The third-party network 130 can be any server or computer device, such as a desktop, laptop, personal computer, tablet computer, wearable computer, server, personal digital assistant (PDA), hybrid PDA / mobile phone, mobile phone, smartphone, set-top box, voice command device, or digital media player, as shown in Figure 1. The third-party network 130 may also be one or more computer devices connected together within a local area network ("LAN"), over a wide area network ("WAN"), or by any technology used to connect or tether computer devices together. The third-party network 130 may run applications (e.g., browsers, standalone applications) that enable users to access user interfaces for interaction and view images, analyses, aggregated data, etc. As an exemplary embodiment, the third-party network 130 corresponds to one or more computer devices used to acquire and analyze vehicle data. As described later, the third-party network 130 may request access to vehicle data as described herein.

[0031] Network 150 connects the third-party network 130 and the management network 120 of the vehicle 110, as shown in Figure 1. Network 150 can connect any number of devices through a network service provider or other connection method. In some embodiments, the network service provider refers to a large shared pool of network-accessible computing resources (such as compute, storage, or networking resources, applications, or services) that implement network-based services and may be virtualized or bare metal. The network service provider can provide on-demand network access to a shared pool of configurable computing resources that can be programmatically provisioned and released in response to customer commands. These resources can be dynamically provisioned and reconfigured to adjust to variable loads. Thus, the concept of “cloud computing” or “network-based computing” can be thought of as both applications delivered as a service over a network and the hardware and software of the network service provider that provides those services.

[0032] Network 150 may include any combination of wired and / or wireless networks, such as one or more direct communication channels, a local area network, a wide area network, a personal area network, and / or the Internet. In some embodiments, communication between the vehicle 110 and the third-party network 130 may be carried out via short-range communication protocols such as Bluetooth, Bluetooth low energy ("BLE"), and / or near-field communication ("NFC"). Communication between the vehicle 110, the third-party network 130, and the management network 120 may be carried out via Network 150, such as via one or more secure networks, such as a local area network that securely communicates with the management network 120 via the Internet. The various communication protocols described herein are merely examples, and this application is not limited thereto.

[0033] Illustratively, a set of vehicles 110 corresponds to one or more vehicles configured with data storage devices for storing data generated from electrical components within the vehicles 110. The data may include any processed data related to vehicle operation, such as log data generated from sensors installed in the vehicle, engine oil data, coolant temperature, mileage, oxygen, and knocking information from various sensors. The data may also include diagnostic data, automated driving (e.g., autonomous driving) related data, etc. The data may also include driver or passenger interactions with user interfaces within the vehicle (e.g., interaction with specific controls, activation of specific applications) or with specific vehicle controls within the vehicle (e.g., windows, power seats, automatic doors or trunk, air conditioning control devices, music control devices, etc.). In one embodiment, the data may be received from an external device. Illustratively, vehicle 110 may include computer devices that are integrated into the vehicle or are considered to form part of the vehicle. In other embodiments, the customer may also have additional computer devices, such as mobile devices, which are considered to be associated with the vehicle, including mobile devices connected to or located near the vehicle. For the purposes of this disclosure, customer computer devices are generally construed in accordance with each of these embodiments and their variations.

[0034] Exemplary, the management network 120 may include a certificate management service 116 that can provide the functionality to respond to third-party authentication as applicable to the aspects of this application. The management network 120 may include one or more data stores that store data associated with the vehicle 110 and the third-party network 130. The certificate management service 116 and data store 114 in Figure 1 are essentially logical and can be implemented in the management network 120 in a variety of ways.

[0035] For illustrative purposes, Figure 2 is a block diagram of an environment corresponding to a vehicle 110 according to one or more embodiments of the technology of the present disclosure. The environment includes a set of local sensor inputs, or a set of information, which may provide inputs for the operation of the vehicle, as described herein. The set of local sensors may include one or more sensors or sensor-based systems that are included in the vehicle or accessible by the vehicle during operation. The local sensors or sensor systems may be integrated into the vehicle. Alternatively, the local sensors or sensor systems may be provided by an interface associated with the vehicle, such as a physical connection, a wireless connection, or a combination thereof.

[0036] In one embodiment, the local sensor can form part of a vision system that provides input to the vehicle, such as object detection, attributes of the detected object (e.g., position, velocity, acceleration), and the presence of environmental conditions (e.g., snow, rain, ice, fog, smoke, etc.). In some embodiments, the vehicle 110 can rely on such a vision system for defined vehicle operation functions without assistance from, or in place of, other conventional detection systems.

[0037] In yet another embodiment, the local sensor may include one or more positioning systems that can obtain reference information from external sources, enabling varying levels of accuracy in determining the vehicle's positioning information. For example, the positioning system may include various hardware and software components for processing information from sources such as GPS, wireless local area network (WLAN) access point information, Bluetooth information, and radio frequency identification (RFID) sources. In some embodiments, the positioning system may obtain a combination of information from multiple sources. Exemplarily, the positioning system may obtain information from various input sources to determine the vehicle's positioning information, specifically its altitude at its current location. In other embodiments, the positioning system may also determine driving-related operating parameters such as direction of travel, speed, and acceleration. The positioning system may be configured as part of a vehicle for multiple purposes, including autonomous driving applications, driver enhancement, or user-assisted navigation. Exemplarily, the positioning system may include processing components and data that facilitate the identification of various vehicle parameters or processing information.

[0038] In yet another embodiment, the local sensor may include one or more navigation systems for identifying navigation-related information. exemplified, the navigation system may acquire positioning information from the positioning system and identify characteristics or information relating to the identified location, such as altitude and road gradient. The navigation system may also identify proposed or intended lane positions on multi-lane roads based on directions provided to or expected by the vehicle user. Similar to positioning systems, the navigation system may be configured as part of a vehicle for multiple purposes, including autonomous driving applications, driver augmentation, or user-assistance navigation. The navigation system may be combined with or integrated with the positioning system. exemplified, the positioning system may include processing components and data that facilitate the identification of various vehicle parameters or processing information.

[0039] The local resource further includes one or more processing components 112 that may be hosted on the vehicle or a computer device accessible by the vehicle (e.g., a mobile computer device). The processing components 112 may, exemplary, access inputs from various local sensors or sensor systems, process the input data, and store the processed data. For the purposes of this application, the processing components 112 will be described in relation to one or more functions relating to exemplary embodiments. For example, a processing component 112 in a vehicle 110 may collect and transmit a dataset in response to a request from an authorized technician.

[0040] The environment may further include various additional sensor components or sensing systems that are operable to provide information about various operating parameters for use according to one or more operating states. The environment may further include one or more control components for processing the output, such as transmitting data through communication outputs, generating data in memory, or transmitting outputs to other processing components.

[0041] Referring here to Figure 3A, an exemplary architecture for implementing a processing component on the vehicle 110 is described. The processing component 112 may be part of a component / system that can provide functions associated with processing and storing vehicle data, and providing access to the stored data for the technician by receiving authorized information for the technician.

[0042] The architecture in Figure 3A is illustrative in nature and should not be interpreted as requiring a specific hardware or software configuration for the processing component. The general architecture of the vehicle / customer device processing component 112 shown in Figure 3A includes configurations of computer hardware and software components that may be used to implement aspects of this disclosure. As shown, the processing component includes a processing unit 302, a network interface 308, a computer-readable media drive 306, and an input / output device interface 304, all of which may communicate with each other via a communication bus. Components of the processing component may be physical hardware components that may include one or more circuit and software models.

[0043] The network interface 308 may provide connectivity to one or more networks or computer systems, such as network 150 in Figure 1 (e.g., wireless or wired connections such as cellular, Wi-Fi, or Bluetooth). Thus, the processing unit 302 may receive information and commands from other computer systems or services via the network. The processing unit 302 may also communicate with memory 310 and further provide output information via input / output device interfaces. In some embodiments, the processing components 112 may include more (or fewer) components than those shown in Figure 3A.

[0044] Memory 310 may include computer program instructions that the processing unit 302 executes to implement one or more embodiments. Memory 310 generally includes RAM, ROM, or other persistent or non-temporary memory. Memory 310 may store an operating system 312 that provides computer program instructions used by the processing unit 302 in the general management and operation of the processing component 112. Memory 310 may further include computer program instructions and other information for implementing aspects of the present disclosure. For example, in one embodiment, memory 310 includes an authentication component 314. In some embodiments, the authentication component 314 requests authentication information, such as a third-party certificate or other authentication information, from a certificate management service 116 or from a third-party network 130. In these embodiments, the authentication component 314 may receive authentication information via the network 150.

[0045] In some embodiments, the third party has authentication credentials, such as a certificate, provided to the third-party network 130 by a certificate management service 116 that authenticates the third party's data streaming access to the vehicle 110. In these embodiments, the authentication component 314 may receive a transmission configuration from the certificate management service 116 that includes authentication credentials, such as public key information associated with the third party. In these embodiments, the third party may provide the authentication component 314 with a certificate or other semi-persistent information via the network 150 by utilizing the third-party network 130.

[0046] After receiving the third-party certificate, the authentication component 314 may verify or confirm the third-party certificate. After verifying the third-party certificate, the authentication component 314 may present the vehicle or fleet certificate to the third-party network 130. After presenting the vehicle or fleet certificate, the authentication component 314 may receive confirmation of approval or other instructions from the third-party network 130 and provide the authorized third-party information to the interface component 316.

[0047] The memory 310 further includes an interface component 316. The interface component 316 can provide various interfaces to enable authorized third-party access to vehicle data, executable code, or vehicle configuration to facilitate diagnosis or repair. In some embodiments, access to vehicle data or data communications is configured as a set of common interfaces that do not require custom computer devices or hardware for third parties. In some embodiments, the interfaces can correspond to vehicle network information that provides access to sensor, component, and data values ​​and states collected by the vehicle's sensors and components. In some embodiments, sensors can include hardware and software components that can acquire, generate, or process various operational or environmental information sources configured within the vehicle for various purposes. In some embodiments, sensors can provide raw collected data to control components and other controls for various functions. For example, information provided to control components by sensors, controller components, or other processing units can be associated with vehicle operation, such as detected vehicle speed, external temperature measurements, and windshield wiper operating status, vision systems (e.g., camera inputs), positioning systems (e.g., GPS systems), timing information, and component operating status.

[0048] Referring here to Figure 3B, an exemplary architecture for implementing the third-party network 130 is described. As previously mentioned, the third-party network 130 may be part of a component or system that can provide third-party-associated functions to present third-party authentication information and facilitate access to vehicle data.

[0049] The architecture in Figure 3B is illustrative in nature and should not be interpreted as requiring a specific hardware or software configuration for the third-party network 130. The general architecture of the third-party network 130 shown in Figure 3B includes configurations of computer hardware and software components that may be used to implement aspects of this disclosure. As shown, the third-party network 130 includes a processing unit 322, a network interface 328, a computer-readable media drive 326, and an input / output device interface 324, all of which can communicate with each other via a communication bus. Components of the third-party network 130 may also include physical hardware components that may include one or more circuit and software models.

[0050] The network interface 328 may provide connectivity to one or more networks or computer systems, such as network 150 in Figure 1. Thus, the third-party network 130 may receive information and commands from other computer systems or services via the network. The third-party network 130 may also communicate with memory 330 and further provide output information via the input / output device interface 324. In some embodiments, the third-party network 130 may include more (or fewer) components than those shown in Figure 3B.

[0051] The memory 330 may contain computer program instructions that the processing unit 322 executes to implement one or more embodiments. The memory 330 generally includes RAM, ROM, or other persistent or non-temporary memory. The memory 330 may store an operating system 332 that provides computer program instructions used by the processing unit 322 in the general management and operation of the third-party network 130.

[0052] The memory 330 may further include interface software 334. In some embodiments, the interface software 334 provides various interfaces that can be provided to third parties. For example, the interface software 334 may compile and present vehicle data received from one or more vehicles 110. In some embodiments, the interface software 334 facilitates interaction between a third-party network 130 and the management network 120. For example, a third party may use the interface software 334 to interact with the management network 120 for purposes such as setting up an account, creating a fleet identification, registering and receiving certificates, setting up a streaming configuration, renewing expired certificates, and initiating vehicle fleet registration. In some embodiments, the interface may be provided as an application programming interface ("API") or may respond to a network endpoint.

[0053] Memory 330 may further include authentication software 336 for managing the authentication process of third parties. In some embodiments, a third party may have a certificate provided by the certificate management service 116 and then be able to receive a vehicle or fleet certificate. In these embodiments, the authentication software 336 may use the certificate and the vehicle or fleet certificate to establish a direct data stream for one or more vehicles 110. In one example, the third party does not have access to connect to the vehicle until the third party receives a certificate from the management network 120. In some embodiments, to request a certificate, the third party sends an .

[0054] In some embodiments, a third party does not have access to a particular vehicle until that vehicle is added to the fleet associated with the third party. For example, a third party may request that the vehicle be added to the fleet associated with the third party. In another example, a vehicle owner or user may request that the vehicle be added to the fleet associated with the third party. The transmission of certificate requests, or requests to add a vehicle to the fleet, can be facilitated through interface software 334, such as an API or other interface. In some embodiments, the interface software 334 interacts with an API associated with the certificate management service 116.

[0055] In some embodiments, the authentication software 336 may interact with one or more vehicles 110 to facilitate mutual authentication. In these embodiments, the authentication software may interact with the vehicles 110 to present third-party identification information and certificates indicating authentication for receiving vehicle data from the vehicles 110. The authentication software 336 may further interact with the vehicles 110 to receive and verify vehicle or fleet certificates indicating vehicle identification information and complete mutual authentication. Once mutual authentication is complete, the authentication software 336 enables the interface software 334 to stream data with the vehicles 110.

[0056] Exemplary block diagram - interaction Figures 4A and 4B illustrate a technology in which, in some embodiments, three parties may permit streaming data from a vehicle to a third-party network. For example, the third-party network described in Figures 4A and 4B represents, in some embodiments, a third party that has a need or desire to stream data from the vehicle. In this example, the third party may not represent the vehicle owner. For example, the third party may be an entity that rents temporary access to the vehicle, a rideshare entity, and so on. As will be discussed later, the third-party network may directly obtain streaming data from the vehicle through interactions with the vehicle, with a management network, and optionally with mobile devices authorized to access or provide information to the vehicle.

[0057] Figure 4A is a block diagram illustrating an example of interaction between a vehicle, a third party, and a management network. The overall high-level flow shows that (1) the third party constitutes a stream profile. The stream profile may include one or more identifiers used when selecting a particular vehicle or vehicle type. For example, the third party may use various vehicle types as part of a fleet they control or operate on. The stream profile may further include user or user type or other information, generally referred to as fleet identification. The stream profile may further include the configuration of the vehicle data to be collected, processed, and transmitted. For example, a particular type of vehicle data may be identified for collection (e.g., speed data, autonomous driving data, etc., as described herein). In some embodiments, the data may correspond to a particular event, so that the streaming data is event-based streaming. As an example, whenever a particular event occurs (e.g., on the vehicle), the vehicle may stream data based on the event. The stream profile may further include certificate information or other information used to configure or maintain authentication information used to stream data to the third-party network. The stream profile may further identify one or more network locations from which the vehicle streams data.

[0058] In some embodiments, configuring a stream profile allows a third party to receive specific vehicle information, such as the vehicle's specific public and private keys, vehicle-specific certificates, and specific identifiers of other vehicles. In some embodiments, some or all of the vehicle's specific information is stored in specific secure hardware of the vehicle, such as memory 310 in Figure 3A. In some embodiments, a third party may configure an initial stream profile. In other embodiments, a third party may update or reconfigure an existing stream profile. In some embodiments, a third party may update an expired configuration. In each of the above and other embodiments, the information required to configure the stream profile may be adapted to the embodiment.

[0059] In (2), the stream configuration is signed with a fleet secret key. In some embodiments, the stream configuration is signed by a computer device associated with the management network using a fleet secret key (e.g., a fleet-scope secret key). The fleet secret key may be maintained by the management network. In other embodiments, the stream configuration is signed by a third party, a vehicle owner, or another person or entity that possesses a fleet secret key. In such embodiments, one or more fleet secret keys may be delegated or entrusted to individual third parties. In some embodiments, the fleet secret key is a secret key specific to one or more vehicles configured within the fleet. In some embodiments, the requirement that the stream configuration is signed with a fleet secret key ensures that the stream configuration can only be set or modified by a person or entity that has the authentication to do so. In some embodiments, specific vehicle information is not transmitted to third parties until the stream configuration is signed with a fleet secret key.

[0060] (3) The management network sets up a vehicle transmission configuration for transmission to a specific vehicle or fleet. The vehicle transmission configuration may include third-party certificate information. The vehicle transmission configuration may also include certificate authority information. The vehicle transmission configuration may also include fleet certificates. The vehicle transmission configuration may also include the fleet's public and private keys. The vehicle transmission configuration may also include data streaming instructions configured to control which vehicle data is streamed and at what frequency, and any other information necessary to facilitate a direct and secure stream between a specific vehicle or fleet and between the vehicle and a third party.

[0061] In some embodiments, the vehicle transmission configuration may include an initial setup. In this embodiment, the created vehicle transmission configuration triggers a user verification sequence. In some embodiments, the user verification sequence may require the vehicle owner or user to be physically present in or near the vehicle. For example, the vehicle may require verification using a key entry, verification on a local vehicle console, verification using a short-range communication protocol such as Bluetooth low energy ("BLE"), Near Field Communication (NFC), or other similar verification techniques. In other embodiments, such as the embodiment in Figure 4B, the user verification sequence may use a telephone or other user terminal paired with a particular vehicle while in physical proximity. Alternatively, as will be discussed later, user verification may be initiated as part of, or in combination with, the transmission of data after the establishment of a mutually authenticated communication channel.

[0062] In (4), the vehicle (e.g., a processor included in the vehicle) verifies the transmission configuration and extracts third-party certificate information. In some embodiments, the vehicle verifies the transmission configuration by partially verifying the configuration signature using a known fleet certificate authority. For example, the vehicle may verify that the configuration signature is from a management network or another known certificate authority.

[0063] In some embodiments, the vehicle verifies the transmission configuration by partially verifying that the fleet certificate primary public key included in the transmission configuration (e.g., used to sign the transmission configuration) matches a fleet public key stored in the vehicle's secure hardware. For example, the vehicle may verify that the fleet certificate primary public key matches a fleet public key stored in memory 310. The vehicle owner may control the existence or use of the fleet public key stored in the vehicle's secure hardware. For example, the owner may hide the existence of the fleet public key, invalidate the fleet public key, or remove the fleet public key. In this example, the existence or use of the fleet public key may be controlled by using a user verification sequence as described above.

[0064] In some embodiments, the vehicle verifies the transmission configuration by partially verifying the configuration signature using the fleet certificate public signing key. In some embodiments, extracting third-party certificate information involves partially extracting a third-party authority certificate from the transmission configuration. As described herein, the third-party authority certificate may identify a certification authority authorized by the vehicle to verify the server or network location providing the streaming data.

[0065] In (5), the vehicle and the third party establish a mutually authenticated connection. For example, in some embodiments, the vehicle initiates the establishment of a mutually authenticated connection by first connecting to the third-party network. The vehicle may connect to the third-party network using any of the functions described with respect to network 150. In some embodiments, the connection to the third-party network may be a passive instruction that the vehicle is available to stream data. In some embodiments, the connection to the third-party network may be an active request to stream data to the network.

[0066] In some embodiments, third-party networks maintain mutually authenticated connections by presenting third-party certificates. In some embodiments, the third-party certificate is a certificate used for mTLS encrypted data communication or other mutual authentication techniques. In some embodiments, the third-party certificate is arbitrary authentication information used to initialize a direct, secure data stream. In some embodiments, the Certificate Authority granting the third-party certificate is the management network. In some embodiments, the third-party network acted as the Certificate Authority. In some embodiments, the Certificate Authority was a party not shown.

[0067] In some embodiments, vehicles maintain mutually authenticated connections by verifying third-party certificates. In some embodiments, vehicles verify third-party certificates by using third-party authority certificates extracted from the transmission configuration. In some embodiments, vehicles verify third-party certificates by comparing the public key in the third-party certificate with the public key configured in the vehicle transmission configuration.

[0068] In some embodiments, the vehicle verifies the third-party certificate by partially verifying that the certificate authority that issued the third-party certificate matches the certificate authority of the fleet certificate. In some embodiments, the vehicle verifies the third-party certificate by partially verifying that the third-party certificate has not expired. In some embodiments, the vehicle verifies the third-party certificate by having the parties verify that the third-party certificate is identical to the fleet certificate. In some embodiments, the vehicle verifies the third-party certificate by partially using a unique device certificate and device key stored in the vehicle's secure hardware.

[0069] In some embodiments, vehicles maintain mutually authenticated connections by presenting unique device certificates. In some embodiments, the unique device certificate is a specific certificate of the vehicle. In some embodiments, the unique device certificate is a certificate used for mTLS encrypted data communication or other mutual authentication techniques. In some embodiments, the unique device certificate is arbitrary authentication information used to initialize a direct, secure data stream. In some embodiments, the certificate authority granting the unique device certificate is a management network. In some embodiments, a third-party network acted as the certificate authority. In some embodiments, the certificate authority was a party not shown. In some embodiments, the unique device certificate is identical to a third-party certificate. In some embodiments, the unique device certificate is different from a third-party certificate. In some embodiments, the unique device certificate is stored in the vehicle's secure hardware. In some embodiments, the unique device certificate is created and authenticated before receiving the vehicle transmission configuration.

[0070] In some embodiments, the third-party network maintains mutually authenticated connections by verifying unique device certificates. In some embodiments, the third party verifies the unique device certificate by partially comparing the public key in the unique device certificate with the public key received from the management network. In some embodiments, the third party verifies the unique device certificate by partially verifying that the Certificate Authority that issued the unique device certificate matches the Certificate Authority of the management network. In some embodiments, the third party verifies the unique device certificate by partially verifying that the Certificate Authority that issued the unique device certificate is the same Certificate Authority that signed the configuration using the fleet private key. In some embodiments, the third party verifies the unique device certificate by partially verifying that the Certificate Authority that issued the unique device certificate matches the Certificate Authority of the third-party certificate. In some embodiments, the third party verifies the unique device certificate by partially verifying that the unique device certificate has not expired. In some embodiments, the third party verifies the fleet certificate by verifying that the unique device certificate is identical to the third-party certificate at the parties' discretion.

[0071] In some embodiments, the third-party network maintains a mutually authenticated connection by granting streaming access to the vehicle. In some embodiments, the streaming access is unidirectional, and only the vehicle can transmit data to or modify data on the third-party network. In some embodiments, the streaming access is bidirectional, and the third-party network can transmit data to or modify data on the vehicle.

[0072] In (6), vehicle data is streamed to a third-party network. Vehicle data may be configured by a vehicle transmission configuration. For example, the vehicle transmission configuration may configure which vehicle data to transmit and how often the vehicle data is transmitted. In some embodiments, the third-party network may stream data to the vehicle. For example, the third-party network may configure vehicle settings, update vehicle software, display messages on the vehicle dashboard, etc. In some embodiments, the ability of the third-party network to stream data to the vehicle is established in the stream profile. In some embodiments, vehicle data is streamed using a public key and a private key, such as in an mTLS encrypted transmission control protocol ("TCP") connection. In some embodiments, the public key and private key of the third party are the same as the public key and private key of the fleet. In some embodiments, the public key and private key of the third party are different from the public key and private key of the fleet.

[0073] As described above, in some embodiments, the transmission of vehicle data may be conditional on a user verification sequence. In some embodiments, the user verification sequence may require the vehicle owner or user to be physically present with or in close proximity to the vehicle. For example, the vehicle may require verification using key input, verification on a local vehicle console, verification using a short-range communication protocol such as Bluetooth low energy ("BLE"), Near Field Communication (NFC), or other similar verification techniques. In other embodiments, the user verification sequence may use a telephone or other user terminal paired with a particular vehicle while in physical proximity.

[0074] Figure 4B is a block diagram illustrating another example of interaction between a vehicle, a third party, and a management network. Figure 4B is similar to that of Figure 4A, and the explanation for Figure 4B is applicable to Figure 4A, except that Figure 4B illustrates the use of a mobile device paired with the vehicle (paired mobile devices). Pairing a mobile device can mean that the mobile device is trusted by the vehicle, without being limited by the examples. For example, a user account associated with the vehicle may similarly be associated with an application running on the mobile device. As another example, the mobile device may have a known MAC address for the vehicle. As yet another example, the mobile device may be pre-paired with the vehicle via Bluetooth. As yet another example, the mobile device may provide the vehicle with its public key. The mobile device may communicate wirelessly with the vehicle via a network (e.g., the internet). The mobile device may also communicate locally wirelessly with the vehicle (e.g., via Bluetooth).

[0075] (1) The third-party network registers the fleet key with the management network. (2) The third-party network provides a request to register the fleet key with a mobile device. For example, the mobile device may be running an application associated with the third-party network (e.g., responding to communication with the third-party network). The application may be further associated with a vehicle, or access to the vehicle may be based on the presence of the mobile device.

[0076] A mobile device may register a fleet key (e.g., the public key described above) with a vehicle (e.g., via a wireless connection). The mobile device may also provide a request to the management network to authorize a vehicle to receive the fleet key. In some embodiments, the management network may decide whether or not to allow registration with the vehicle based on the fleet key received in step (1). For example, the management network may compare the fleet key in step (1) with a fleet key already registered with the vehicle. In another example, the management network may determine that the mobile device is associated with a vehicle (e.g., via pairing, via the same user account). In some embodiments, the management network may optionally block registration based on its determination that registration should not occur (e.g., by providing information to the vehicle via a wireless connection, e.g., using a system or management-level function).

[0077] In (3), the third-party network signs the transmission configuration using the fleet key. For example, the third-party network may sign the configuration using the private key associated with the fleet. Further explanation of the configuration is included in (3) of Figure 4A above. In (4), the third-party network sets up the transmission configuration via the management network as described above. For example, the transmission configuration is provided to the management network and then provided to the vehicles. In (5), the vehicles verify the transmission configuration based on the paired fleet key. For example, the signed transmission configuration can be verified (e.g., verified that it was legitimately provided from the third-party network) based on the public key registered in step (2).

[0078] In (6), a mutually authenticated connection is established between the third-party network and the vehicle. The transmission configuration may include information describing where (e.g., a server, network location) the vehicle will connect to in order to provide the streaming data. The transmission configuration may further include information identifying a Certificate Authority, in some embodiments a single Certificate Authority, which is used to verify the server or network location associated with the third-party network. The transmission configuration may further specify how to establish a secure connection (e.g., mTLS). In (7), the vehicle streams the data to the third-party network.

[0079] As described above with respect to Figures 4A to 4B, a third party may select specific data from individual vehicles or generally from a fleet of vehicles that prefer to be streamed. For example, the streaming data may be provided to a backend accessible to the third party (e.g., a network location). In some embodiments, the user interface may be accessible to the third party (e.g., a user associated with the third party) and may include selectable options associated with specific vehicle data to be streamed. The user may then provide user input for selecting specific selectable options, and these selections may form part of the vehicle transmission configuration described herein.

[0080] The vehicle may run software that controls the vehicle's operation. For example, as described above, the vehicle may run software that enables autonomous driving functions, air conditioning control, etc. The software may be updated over time, for example, via over-the-air (OTA) updates. The vehicle's software may aggregate various types of data, some of which may be selected for transmission as streaming data by a third-party network. In some embodiments, the selectable options described above may be automatically entered based on the software running on the vehicle. For example, the various selectable options may correspond to various types of data (e.g., various types of events). In some embodiments, the selectable options may also be accessible to third parties and obtained from a schema containing options available for selection by third parties. As can be understood, certain types of data may be confidential or experimental so that access to them should be restricted.

[0081] For example, vehicle software may generate statistics or monitor events associated with new autonomous driving features. It may be detrimental for a third party to access or become aware of data associated with new autonomous driving features before the full release of the new features.

[0082] In some embodiments, aliasing may be used to restrict access to secret or experimental features. For example, a vehicle, or a fleet of vehicles, may receive an OTA update that adds a new feature (e.g., a new signal or streaming feature such as a new event). A third party may be restricted from seeing this new feature when selecting data to stream. The new feature may be associated with an internal name, such as experimental feature A. The feature may be considered ready for full deployment later. Server-side restrictions, such as third-party restrictions, may be removed. Thus, a third party can select a new feature to form part of the streaming data described herein. The selection may be associated with a specific name (e.g., "autonomous driving feature A"), for example, in a schema or user interface used by the third party. Once selected, the vehicle may use aliasing to associate the name—experimental feature A—with the specific name—autonomous driving feature A. Thus, when streaming a vehicle, information or events from experimental feature A may be provided to a third party as streaming data (e.g., via an interface), or the streaming data may be provided as data for autonomous driving feature A.

[0083] Example flowchart Figure 5 is an exemplary process flowchart for a vehicle authentication routine that initiates data streaming to a third-party network. This process may be performed, for example, by a vehicle (e.g., vehicle 110). Those skilled in the art will understand that the routine may be implemented by one or more computer devices that implement appropriate hardware and software executable code and modules to provide the identified functions.

[0084] Starting in block 502, the vehicle receives the vehicle transmission configuration. The vehicle transmission configuration may include some or all of the elements described in (3) of Figure 4A. In block 504, the vehicle extracts the fleet certificate from the vehicle transmission configuration. The fleet certificate may include a fleet verification public key, such as a fleet public key or a third-party public key, as shown in Figure 4A. In block 506, the vehicle verifies the fleet certification authority. In block 508, the vehicle verifies the fleet certificate public key. In block 510, the vehicle verifies the transmission configuration signature. In block 512, the vehicle extracts the third-party authority certificate. In block 514, the vehicle establishes a mutually authenticated connection with the third party. The routine in Figure 5 may include some or all of the elements described in Figures 4A to 4B.

[0085] Figure 6 is an exemplary process flowchart for a third-party authentication routine that initiates streaming data associated with a vehicle. This process may be performed, for example, by a third party (e.g., Third Party 130). Those skilled in the art will understand that the routine may be implemented by one or more computer devices that implement appropriate hardware and software executable code and modules to provide the identified functionality.

[0086] In block 602, the third party receives a vehicle connection. Block 602 may include some or all of the elements described in Figure 4A (5). In block 604, the third party presents a certificate to the vehicle. Block 604 may include some or all of the elements described in Figure 4A (5). In block 606, the third party receives a device certificate from the vehicle. Block 606 may include some or all of the elements described in Figure 4A (5). In block 608, the third party verifies the device certificate. Block 608 may include some or all of the elements described in Figure 4A (5). In block 610, the third party grants streaming access to the vehicle. Block 610 may include some or all of the elements described in Figure 4A (5) and (6).

[0087] Figure 7 is an exemplary process flowchart for an exemplary routine for registering a vehicle to a fleet. This process may be performed, for example, by a vehicle (e.g., vehicle 110). As described herein, a fleet may be one or more vehicles associated with a single streaming profile. A streaming profile may include some or all of the elements described in Figure 4A(1). Those skilled in the art will understand that the routine may be implemented by one or more computer devices that implement appropriate hardware and software executable code and modules to provide the identified functionality.

[0088] Starting in block 702, the vehicle receives a request to join the fleet. Such a request may be generated in a streaming profile configuration as described in (1) of Figure 4A. In block 704, the vehicle enters a registered state. In some embodiments, the registered state includes displaying or sending a message to the vehicle owner requesting the vehicle to join the fleet. In some embodiments, the message is displayed on the vehicle's console. In some embodiments, the message is displayed on an application or user terminal associated with the vehicle owner. In some embodiments, the message is transmitted to the vehicle owner via text transmission, SMS message, email, etc.

[0089] In block 706, the vehicle receives a registration confirmation. The registration confirmation may include some or all of the elements described in (3) of Figure 4A. In block 708, the vehicle transmits a registration confirmation. In some embodiments, the registration confirmation is data indicating that the vehicle has been added to the fleet. In some embodiments, the registration confirmation includes a message to the vehicle owner using one or more of the techniques described in block 704. In some embodiments, the registration confirmation includes data transmitted to a management network, such as management network 120. In some embodiments, the registration confirmation includes data transmitted to a third party, such as third-party network 130.

[0090] Other Embodiments All processes described herein are embodied in software code modules executed by a computer system comprising one or more computers or processors, and can be fully automated by the software code modules. The code modules may be stored in any type of non-temporary computer-readable medium or other computer storage device. Some or all of the methods may be embodied in dedicated computer hardware.

[0091] Many other variations beyond those described herein will become apparent from this disclosure. For example, depending on the embodiment, any particular operation, event, or function of any of the algorithms described herein may be performed in a different order, and may be added, merged, or excluded entirely (for example, not all described operations or events are necessary for the implementation of the algorithm). Furthermore, in certain embodiments, operations or events may be performed not sequentially, but simultaneously, for example, through multithreading, interrupt handling, or through multiple processors or processor cores, or on other parallel architectures. Moreover, various tasks or processes may be performed by various machines and / or computer systems that can work together.

[0092] Various exemplary logic blocks, modules, and engines described in relation to the embodiments disclosed herein may be implemented or implemented by machines such as processing units or processors, digital signal processors (DSPs), application-specific integrated circuits (ASICs), field-programmable gate arrays (FPGAs) or other programmable logic devices, discrete gates or transistor logic, discrete hardware components, or any combination thereof, designed to perform the functions described herein. The processor may be a microprocessor, but in alternative examples, the processor may be a controller, microcontroller, or state machine, or a combination thereof. The processor may include electrical circuits configured to process computer executable instructions. In another embodiment, the processor includes an FPGA or other programmable device that performs logical operations without processing computer executable instructions. The processor may also be implemented as a combination of computer devices, for example, a combination of a DSP and a microprocessor, multiple microprocessors, one or more microprocessors combined with a DSP core, or any other such configuration. Although this specification primarily describes digital technologies, the processor may primarily include analog components. For example, some or all of the signal processing algorithms described herein may be implemented in analog circuits or mixed analog and digital circuits. The computer environment may include any type of computer system, including, but not limited to, a microprocessor, a mainframe computer, a digital signal processor, a portable computer device, a device controller, or a computer system based on an in-device computing engine.

[0093] In particular, "can" and "could" Conditional language such as "might" or "may," unless otherwise specified, is generally understood to be used in contexts where it is commonly used to convey that a particular embodiment includes certain features, elements, and / or steps, but other embodiments do not. Accordingly, such conditional language is generally not intended to mean that features, elements, and / or steps are required in any way in one or more embodiments, or that one or more embodiments necessarily include logic for determining whether these features, elements, and / or steps are included in any particular embodiment or should be implemented in any particular embodiment, with or without user input or prompting.

[0094] Disjunctive language, such as the phrase "at least one of X, Y, or Z," is generally understood in its context to indicate that an item, term, etc., can be any one of X, Y, or Z, or any combination thereof (e.g., X, Y, and / or Z), unless otherwise specified. Therefore, such disjunctive language is not, and should not be intended to, mean that a particular embodiment requires at least one of X, at least one of Y, or at least one of Z, respectively, to exist.

[0095] Any process description, element, or block in the flowcharts described herein and / or shown in the accompanying drawings should be understood as potentially representing a module, segment, or portion of code containing one or more executable instructions for implementing a particular logical function or element in the process. As will be understood by those skilled in the art, depending on the function included, alternative implementations are included within the scope of the embodiments described herein, in which elements or functions may be deleted or executed in the illustrated or described order, including substantially simultaneously or in reverse order.

[0096] Unless otherwise specified, articles such as "a" or "an" should generally be interpreted as including one or more of the listed items. Therefore, phrases such as "devices configured to..." are intended to include one or more of the enumerated devices. Such one or more enumerated devices may also be collectively configured to perform the stated enumeration. For example, "processors configured to perform enumerations A, B, and C" could include a first processor configured to perform enumeration A, working in conjunction with a second processor configured to perform enumerations B and C.

[0097] It should be emphasized that many variations and modifications can be made to the embodiments described above, and that elements thereof are understood to be found in other acceptable examples. All such modifications and variations are intended to be included herein within the scope of this disclosure.

Claims

1. A system for providing vehicle data access, the system comprising one or more processors and a non-temporary computer storage medium for storing instructions, wherein when an instruction is executed by the one or more processors, the one or more processors, Responding to connection information from a third-party network, wherein the connection information includes a public fleet key, and the received public fleet key is used to authorize the vehicle to receive the public fleet key from a mobile device paired with the vehicle. Analyzing a vehicle transmission configuration transmitted to the vehicle, wherein the vehicle transmission configuration includes instructions for the type of vehicle data to be streamed to the third-party network, information describing how the vehicle connects to the third-party network, and a specific certification authority authorized to verify the third-party network, and the vehicle transmission configuration is signed based on a secret fleet key associated with the third-party network. A system that transmits the vehicle transmission configuration to the vehicle, wherein the vehicle is configured to identify one or more network locations to stream the vehicle data based on the vehicle transmission configuration, verify the network locations using the specific certification authority, and transmit the type of vehicle data to the third-party network.

2. The instruction further causes one or more processors to To provide the third-party network with a public schema that identifies the types of available vehicle data, The system according to claim 1, wherein the vehicle transmission configuration represents a subset of the types of available vehicle data.

3. The system according to claim 1, wherein the vehicle stores the fleet public key based on its receipt of the fleet public key from the mobile device, and the vehicle uses the fleet public key to verify the vehicle transmission configuration.

4. The system according to claim 3, wherein the mobile device communicates wirelessly with the vehicle via a network, or the mobile device communicates locally with the vehicle.

5. The system according to claim 1, wherein a specific type of vehicle data is assigned an alias, and the vehicle associates the specific type of vehicle data with the alias.

6. The system according to claim 5, wherein the vehicle generates event data corresponding to the alias, and the vehicle associates the event data with the type of the specific vehicle data.

7. The system according to claim 1, wherein the transmission is performed via an encrypted communication link between the third-party network and the vehicle.

8. A method implemented by a system of one or more processors, A step of responding to connection information from a third-party network, wherein the connection information includes a public fleet key, and the received public fleet key is used to authorize the vehicle to receive the public fleet key from a mobile device paired with the vehicle. A step of analyzing a vehicle transmission configuration to be transmitted to the vehicle, wherein the vehicle transmission configuration includes instructions for the type of vehicle data to be streamed to the third-party network, information describing how the vehicle connects to the third-party network, and a specific certification authority authorized to verify the third-party network, and the vehicle transmission configuration is signed based on a secret fleet key associated with the third-party network. A step of transmitting the vehicle transmission configuration to the vehicle, wherein the vehicle is configured to identify one or more network locations to stream the vehicle data based on the vehicle transmission configuration, to verify the network locations using the specific certification authority, and to transmit the type of vehicle data to the third-party network. Methods that include...

9. The further step includes providing the third-party network with a public schema that identifies the types of available vehicle data, The method according to claim 8, wherein the vehicle transmission configuration represents a subset of the types of available vehicle data.

10. The method according to claim 8, wherein the vehicle stores the fleet public key based on its receipt of the fleet public key from the mobile device, and the vehicle uses the fleet public key to verify the vehicle transmission configuration.

11. The method according to claim 10, wherein the mobile device communicates wirelessly with the vehicle via a network, or the mobile device communicates locally with the vehicle.

12. The method according to claim 8, wherein a specific type of vehicle data is assigned an alias, and the vehicle associates the specific type of vehicle data with the alias.

13. The method according to claim 12, wherein the vehicle generates event data corresponding to the alias, and the vehicle associates the event data with the type of the specific vehicle data.

14. The method according to claim 8, wherein the transmission is performed via an encrypted communication link between the third-party network and the vehicle.

15. A non-temporary computer storage medium for storing instructions, wherein when the instructions are executed by the systems of one or more computers, the one or more computers, Responding to connection information from a third-party network, wherein the connection information includes a public fleet key, and the received public fleet key is used to authorize the vehicle to receive the public fleet key from a mobile device paired with the vehicle. Analyzing a vehicle transmission configuration transmitted to the vehicle, wherein the vehicle transmission configuration includes instructions for the type of vehicle data to be streamed to the third-party network, information describing how the vehicle connects to the third-party network, and a specific certification authority authorized to verify the third-party network, and the vehicle transmission configuration is signed based on a secret fleet key associated with the third-party network. Transmitting the vehicle transmission configuration to the vehicle, wherein the vehicle is configured to identify one or more network locations to stream the vehicle data based on the vehicle transmission configuration, verify the network locations using the specific certification authority, and transmit the type of vehicle data to the third-party network. A non-temporary computer storage medium that enables the execution of [the specified action].

16. The instruction further causes one or more computers to: To provide the third-party network with a public schema that identifies the types of available vehicle data, The computer storage medium according to claim 15, wherein the vehicle transmission configuration represents a subset of the types of available vehicle data.

17. The computer storage medium according to claim 15, wherein the vehicle stores the fleet public key based on its receipt of the fleet public key from the mobile device, and the vehicle uses the fleet public key to verify the vehicle transmission configuration.

18. The computer storage medium according to claim 17, wherein the mobile device communicates wirelessly with the vehicle via a network, or the mobile device communicates locally with the vehicle.

19. The computer storage medium according to claim 15, wherein a specific type of vehicle data is assigned an alias, and the vehicle associates the specific type of vehicle data with the alias.

20. The computer storage medium according to claim 19, wherein the vehicle generates event data corresponding to the alias, and the vehicle associates the event data with the type of the specific vehicle data.

21. The computer storage medium according to claim 15, wherein transmission is performed via an encrypted communication link between the third-party network and the vehicle.

22. The computer storage medium according to claim 15, wherein the third-party network is configured to verify the vehicle based on a vehicle certification authority.

23. A method implemented by a processor included in the vehicle, The steps include receiving a fleet public key associated with a third-party network via a mobile device paired with the vehicle, wherein the vehicle is configured to generate event data associated with various types of vehicle data, and the event data is generated based on the use of sensors or on the operation of the vehicle by a user; A step of analyzing a vehicle transmission configuration received from a management network associated with the vehicle, wherein the vehicle transmission configuration includes instructions for a specific type of vehicle data to be streamed to the third-party network, information describing how the vehicle connects to the third-party network, and a specific certification authority authorized to verify the third-party network. The vehicle transmission configuration is signed based on a secret fleet key associated with the third-party network, and the processor verifies the vehicle transmission configuration based on the fleet public key. A step of transmitting the aforementioned specific type of vehicle data to the third-party network, wherein the vehicle identifies one or more network locations to stream the aforementioned type of vehicle data based on the vehicle transmission configuration, and the vehicle verifies the network locations using the aforementioned specific certification authority. Methods that include...

Images