Pseudonymous logging and instructions

Abstract

The present disclosure relates to managing data communications between individual vehicles and a network service. The network service may utilize the pseudonymous identifier to facilitate managing data communications between selected vehicles and a remote service. Illustratively, the pseudonymous identifier may correspond to an at least somewhat unique identifier generated by or configured on the vehicle. The pseudonymous generation / configuration is implemented such that the pseudonymous identifier is not associated by the network service with another identifier, such as a VIN, associated with the vehicle, vehicle owner, vehicle user, etc. For example, the network service may identify instructions to the vehicle associated with the pseudonymous identifier based on processing of vehicle data. The vehicle may identify one or more instructions by matching the pseudonymous identifier with the vehicle's pseudonymous identifier.

Description

[Technical field]

[0001] [CROSS REFERENCE TO RELATED APPLICATIONS] This application claims priority to U.S. Provisional Patent Application No. 63 / 262,864, entitled “PSEUDONYMOUS LOGGING AND DIRECTIVES,” filed October 21, 2021, which is hereby incorporated by reference in its entirety for all purposes. [Background technology]

[0002] Generally, computing devices and communication networks may be utilized to exchange data and / or information. In a typical application, content may be requested from one computing device to another computing device over the communication network. For example, a user of a personal computing device may utilize a browser application to request content pages (e.g., network pages, web pages, etc.) from a server computing device over a network (e.g., the Internet). In such an embodiment, the user computing device may be referred to as a client computing device and the server computing device may be referred to as a content provider. In another embodiment, information may be collected or generated at the user computing device and provided to the server computing device for further processing or analysis.

[0003] Generally, various vehicles, such as electric vehicles, internal combustion engine vehicles, hybrid vehicles, etc., can be configured to collect information about the vehicle. In certain scenarios, a service provider may want to access operating parameters, sensor values, or other information related to the vehicle, for example, to monitor or calculate vehicle performance characteristics. In other scenarios, a service provider may want to contact one or more vehicle users or owners to request that an action be taken. [Brief description of the drawings]

[0004] The present disclosure is described herein with reference to drawings of certain embodiments that are intended to illustrate, rather than limit, the disclosure. It is to be understood that the accompanying drawings, which are incorporated in and constitute a part of this specification, are for the purpose of illustrating the concepts disclosed herein and may not be to scale.

[0005] [Figure 1] FIG. 1 illustrates a block diagram of an example environment for providing vehicular communications with network services in accordance with one or more aspects of the present application.

[0006] [Diagram 2] FIG. 1 illustrates a block diagram of an exemplary environment corresponding to a vehicle, in accordance with one or more aspects of the present application.

[0007] [Figure 3A] 1 illustrates an exemplary architecture for implementing a management component according to aspects of the present application.

[0008] [Figure 3B] 1 illustrates an exemplary architecture for implementing vehicle data services in accordance with aspects of the present application.

[0009] [Figure 4] FIG. 1 is a block diagram of an exemplary environment for interaction between a network service and individual vehicles for generating pseudonyms (pseudonyms, anonymous names), according to one embodiment.

[0010] [Diagram 5] FIG. 1 is a block diagram of an example environment for interaction between a network service and an individual vehicle for transmission of vehicle data based on one or more pseudonymous identifiers, according to one embodiment.

[0011] [Figure 6]FIG. 1 is a block diagram of an exemplary environment for interaction between a network service and individual vehicles to send instructions to the vehicles, according to one embodiment.

[0012] [Figure 7] FIG. 1 is a block diagram of an exemplary environment for an alternative embodiment of interaction between a network service 120 and a computing device 130 for sending instructions to a vehicle.

[0013] [Figure 8] 1 is a flow chart illustrating a routine for vehicle pseudonym management according to one or more embodiments described herein.

[0014] [Figure 9] 1 is a flow chart illustrating a routine for vehicle data transmission according to one or more embodiments described herein.

[0015] [Figure 10] 1 is a flow chart illustrating a routine for processing a request for instructions to a vehicle according to one or more embodiments described herein.

[0016] [Figure 11] 1 is a flow chart illustrating a routine for processing a command request to a vehicle according to one or more embodiments described herein. DETAILED DESCRIPTION OF THE PREFERRED EMBODIMENTS

[0017] In general, one or more aspects of the present disclosure relate to configuration and management of data provided by or actions taken by vehicles. As an illustrative example, aspects of the present application correspond to managing data communications between individual vehicles and a network service. Illustratively, vehicle data may include, but is not limited to, vehicle driving information, vehicle parameters, sensor configuration information, sensor values, ambient information, and the like. In other illustrative examples, aspects of the present application correspond to managing actions or instructions taken by a select subset of vehicles based on communications generated by the network service.

[0018] In general, access to vehicle information has been largely limited to applications that associate vehicle data and vehicles with unique identities of individuals or vehicles. For example, several services can track vehicle ownership, vehicle performance data, vehicle maintenance information, etc. according to a unique identifier in the form of a Vehicle Identification Number (VIN) assigned to a vehicle at the time of manufacture. Traditionally, the VIN number of a vehicle is also associated with the individual information of the registered owner. Thus, in such implementations, a close association of the VIN number to the vehicle is required so that the service provider receiving the vehicle data associated with the VIN number can closely associate all received driving and performance data with an individual user. Thus, privacy cannot be protected by utilizing the VIN number for notification and processing of vehicle data, since the VIN number is known to both the service provider and the vehicle, and is further associated with the owner. Such systems / approaches may be vulnerable to operational or security violations.

[0019] To address at least some of the above inefficiencies, the network service may utilize pseudonymous identifiers to facilitate management of data communications between a particular vehicle and a remote service. Illustratively, the pseudonymous identifier may correspond to an at least somewhat unique identifier generated by or configured on the vehicle. The pseudonymous generation / configuration is implemented by the network service such that it is not associated with another identifier, such as a VIN, associated with the vehicle, vehicle owner, vehicle user, etc. In this regard, each pseudonymous identifier is a logical, generic identifier for an individual vehicle that may be transmitted and processed without association with vehicle identification or user identification information.

[0020] Vehicles may include network communication capabilities that may establish bidirectional communication with a network service. In one embodiment, each vehicle generates / configures a pseudonymous identifier(s), which is then registered with the network service. The vehicles may then collect and transmit vehicle data (e.g., performance metrics, driving conditions, sensor values, etc.) associated with the pseudonymous identifiers. In exchange, the network service may receive vehicle data for multiple vehicles without identifying a particular source of the vehicle data (e.g., a particular VIN or other identifier) ​​other than the pseudonymous identifiers. The network service may then utilize the collected vehicle data for diagnostic processes, usage processes, etc.

[0021] In certain embodiments, a user of a network service may wish to elicit some action to be taken by certain vehicles that meet selection criteria corresponding to collected vehicle data. For example, the network service may receive an action request that seeks to elicit service requests for vehicles that meet the selection criteria or the performance of diagnostic / corrective procedures. In another example, the network service may receive an action request that seeks to provide notifications to users / owners of vehicles that meet the selection criteria. Because the collected data that meets the selection criteria is associated only with pseudonymous identifiers, the network service is unable to directly send a communication to the target vehicles, such as via direct communication. Thus, the network service may issue instructions to the vehicles that correspond to a list of pseudonyms that are requested to perform some responsive action.

[0022] In some embodiments, the vehicle may be configured to periodically synchronize vehicle data with a computing device, such as a personal mobile device. In such embodiments, the vehicle and the computing device may be configured to establish two-way communication to transmit / receive vehicle data. The computing device may also include network communication capabilities capable of establishing two-way communication with a network service. In such embodiments, the computing device may be configured to collect and transmit vehicle data associated with the pseudonymous identifier. The computing device may also identify the pseudonymous identifier associated with the vehicle and receive one or more instructions from the network service.

[0023] In certain embodiments, the computing device may be configured to communicate with the network service as a secondary network. For example, if communication between the vehicle and the network service is disconnected or interrupted, the computing device may establish a secondary communication channel with the network service and continue to communicate with the network service. In such embodiments, the computing device may perform synchronization with the vehicle in real time or after the computing device establishes a means of communication with the network service. Thus, the computing device may be utilized to increase network durability or reliability between the vehicle and the network service.

[0024] In certain embodiments, both the vehicle and the computing device may provide a response to one or more instructions generated from the network service. In such embodiments, the vehicle or computing device that sends the first response signal to the network service has priority in communicating with the network service. For example, if the network service receives a response signal from the computing device before receiving a response signal from the vehicle, the network service may communicate with the computing device.

[0025] The individual vehicle is then configured to poll the list of instructions issued to the vehicle with the pseudonym to determine whether any of the listed pseudonyms match the individual vehicle's pseudonym. If the pseudonyms match, then the vehicle may trigger the implementation of a response action. For example, the vehicle may implement a requested diagnostic action or correct an anomaly. In another example, the vehicle may generate a further communication to the network service with the additional information or request further instructions from the vehicle. In the additional information or transmission, the network service may omit the pseudonym identifier such that a matching pseudonym identifier is not associated with the additional transmission. Illustratively, in one embodiment, the list of issued pseudonyms is large enough so that a response action that includes a VIN or other identifying information is not directly tied to an incoming response.

[0026] While various aspects are described according to exemplary embodiments and feature combinations, those skilled in the art will appreciate that the embodiments and feature combinations are exemplary in nature and should not be construed as limiting. More specifically, aspects of the present application may be applied to various types of vehicle data or vehicle processing. However, those skilled in the art will appreciate that aspects of the present application are not necessarily limited to application to any particular type of vehicle data, data communications, or exemplary interactions between vehicles, owners / users, and network services. Such interactions should not be construed as limiting.

[0027] 1 illustrates a block diagram of an example environment of a system 100 in which a number of vehicles communicate with a network service via a network connection. The system 100 includes a network that connects a set of vehicles 110, a network service 120, and a computing device 130. Each component may represent a software module that is implemented or executed by one or more external computing devices. These external computing devices may be separate, stand-alone external computing devices. Thus, each component of the network service 120 should be considered a logical representation of a service and does not require a specific implementation in one or more external computing devices.

[0028] As shown in FIG. 1, a network 150 can connect the devices and modules of the system. Any number of devices can be connected by the network. In an embodiment, the vehicle 110, the network service 120, and the computing device 130 can communicate or exchange data (e.g., one or more communication channels are established) over the network 150. In an embodiment, the network service 120 provides a network-based service to the vehicle 110 and the computing device 130 over the network 150. The network service 120 implements a network-based service, which is a large shared pool of network-accessible computing resources (such as computing, storage, or network resources, applications, or services). The network service 120 can be virtualized or bare metal. The network service 120 can provide on-demand network access to a shared pool of configurable computing resources that can be programmatically provisioned and released in response to user commands. These resources can be dynamically provisioned and reconfigured to meet changing loads. In this way, the concept of "cloud computing" or "network-based computing" can be thought of as both applications delivered as services over a network, and the network service hardware and software that provides those services.

[0029] In an embodiment, network 150 may be a secure network, such as a local area network, that securely communicates with network service 120 over the Internet. Network 150 may include any wired network, wireless network, or combination thereof. For example, network 150 may be a personal area network, a local area network, a wide area network, a wireless broadcast network (e.g., for radio or television), a cable network, a satellite network, a cellular network, or combination thereof. As a further example, network 150 may be a publicly accessible network of linked networks that may be operated by a variety of different parties, such as the Internet. In an embodiment, network 150 may be a private or semi-private network, such as a corporate or university intranet. Network 150 may include one or more wireless networks, such as, for example, a Global System for Mobile Communications (GSM) network, a Code Division Multiple Access (CDMA) network, a Long Term Evolution (LTE) network, a fifth generation wireless communication (5G), or any other type of wireless network. Network 150 may use protocols and components for communicating over the Internet or any of the other aforementioned types of networks. For example, protocols used by network 150 include Hypertext Transfer Protocol (HTTP), HTTP Secure, Message Queue Telemetry Transport (MQTT), Constrained Application Protocol (CoAP), etc. Protocols and components for communicating over the Internet or any of the other aforementioned types of communication networks are well known to those skilled in the art and therefore will not be described in further detail herein.

[0030] In some embodiments, each of the vehicles 110 is connected to the computing device 130 and the network 160. In such embodiments, the network 160 may include any combination of wired and / or wireless networks, such as, for example, one or more direct communication channels, local area networks, wide area networks, personal area networks, and / or the Internet. In some embodiments, communication between the vehicles 110 and the computing device 130 may be performed via a short-range communication protocol, such as Bluetooth, Bluetooth Low Energy (BLE), and / or Near Field Communications (NFC). In some embodiments, the network 160 may be utilized as a backup network for the network 150. For example, if communication between the vehicles 110 and the network service 120 is disconnected or interrupted, the network between the computing device 130 and the network service 120 may be utilized to perform communication. In some embodiments, the network 160 may be utilized to periodically synchronize vehicle data. In certain embodiments, each computing device 130 may establish the network 160 with multiple vehicles 110.

[0031] In some embodiments, networks 150, 160 may include some or all of the same communication protocols, services, hardware, etc. Thus, although the description herein may describe communications between vehicle 110 and computing device 140 over network 160, as well as communications between vehicle 110, network service 120, third party service provider 130, and computing device 140 over network 150, the communications of devices and / or network-based services are not limited to such. The various communication protocols described herein are merely examples, and the application is not limited thereto.

[0032] In an embodiment, computing device 130 (e.g., also referred to as a user device) can be any computing device, such as a desktop, laptop or tablet computer, a personal computer, a tablet computer, a wearable computer, a server, a personal digital assistant (PDA), a hybrid PDA / cell phone, a cell phone, a smart phone, a set-top box, a voice command device, a digital media player, etc. As described herein, applications (e.g., browsers, standalone applications, etc.) can be executed by computing device 130 that allow a user to access an interactive user interface, view images, analysis results, aggregated data, etc. In various embodiments, a user of computing device 130 can interact with the vehicle and / or network services through various devices. Such interaction can typically be achieved through an interactive graphical user interface or through voice commands, but can alternatively be achieved through command line and / or other means.

[0033] Illustratively, the network service 120 may include a vehicle data service 122 that may provide functionality to respond to data received from the vehicle 110 and / or the computing device 130 as applied to aspects of the present application. In an embodiment, vehicle data with a pseudonymous identifier(s) associated with a particular vehicle is periodically transmitted from the vehicle to the vehicle data service 122. In such an embodiment, the vehicle data service 122 may process the vehicle data received from the vehicle and provide instructions. For example, the vehicle data service 122 may receive vehicle data from a plurality of vehicles 110, where each vehicle is associated with a pseudonymous identifier. The vehicle data service 122 then processes the vehicle data with the pseudonymous identifier for each instruction and writes an instruction. The network service 120 may further include a vehicle data storage 124 configured to store the processed data and / or the vehicle data received from the plurality of data. The network service is represented in a simplified logical form and is not indicative of all of the physical software and hardware components that may be implemented to realize functionality related to the network-based service.

[0034] Each vehicle 110 may include communications capabilities, such as hardware and software, that facilitate interaction via one of a number of communications media and protocols. More specifically, the vehicle includes a number of sensors, components, and data storage for acquiring, generating, and maintaining vehicle data, including driving data. In some embodiments, the information provided by each component may include processed information, where sensor information is processed by a controller, logic unit, processor, or the like to generate additional information. For example, a vision system may utilize input from one or more camera sensors to provide an output (e.g., process raw camera image data and generate an output corresponding to the processing of the raw camera image information). The camera sensor may be a sensor component associated with a vision system to determine vehicle driving conditions, ambient conditions, or other information. In other embodiments, the camera sensor may be separate from sensor components, such as non-camera sensor components, and a vehicle may include multiple camera sensors. In yet another example, additional information acquired from or associated with a positioning system, a calendar system, or a time-based system may be utilized by the control component.

[0035] FIG. 2 illustrates, for illustrative purposes, an environment corresponding to a vehicle 110 according to one or more aspects of the present application. Illustratively, each vehicle includes a management component 210 operable to implement one or more aspects of the present application described herein. In one aspect, the management component 210 can generate or configure a pseudonymous identifier(s) to be utilized to identify the vehicle to network services. The pseudonymous identifier can correspond to any one of a variety of unique or semi-unique identifiers. The pseudonymous identifier can be based on an attribute of the vehicle, such as a representation of a particular hardware or software component. In another embodiment, the pseudonymous identifier can be selected from a list of available pseudonymous identifiers, such as a random selection. The pseudonymous identifier(s) can be generated or configured at the time of manufacture, release from the manufacturer, etc. For simplicity, one or more vehicles are generally represented as a single component, but includes some of the functionality described and illustrated in other vehicles.

[0036] The environment of the vehicle 110 may include sensors 212 that may provide input for operation of the vehicle or for gathering information, as described herein. The collection of sensors 212 may include one or more sensors or sensor-based systems that may be included in the vehicle or may be accessible by the vehicle while it is being operated. The sensors 212 may be integrated into the vehicle. Alternatively, the sensors 212 may be provided by an interface associated with the vehicle, such as a physical connection, a wireless connection, or a combination thereof.

[0037] In one aspect, the sensor constellation 212 can include a vision system that provides inputs such as object detection, attributes of detected objects (e.g., location, speed, acceleration), and the presence of surrounding conditions (e.g., snow, rain, ice, fog, smoke, etc.). For example, each vehicle 110 includes a sensor constellation 212 (including cameras, driving sensors, etc.), a management component 210, and data storage 214. In this example, the sensor constellation 212 can provide vehicle driving parameters to the management component 210 in real time or near real time. The management component 210 can provide data related to control of the vehicle, such as steering direction, acceleration, braking, etc. The data storage 214 can store information about the current vehicle driving environment. In some embodiments, the vehicle 110 can rely on such a vision system for defined vehicle driving functions without the assistance of or in place of other conventional detection systems.

[0038] In yet another aspect, the sensor 212 can include one or more positioning systems that can obtain reference information from external sources that allows various levels of accuracy in determining the vehicle's positioning information. For example, the positioning system can include various hardware and software components for processing information from sources such as GPS, Wireless Local Area Network (WLAN) access points, Bluetooth, and Radio-Frequency Identification (RFID). In some embodiments, the positioning system can obtain information from multiple sources in combination. Illustratively, the positioning system can obtain information from various input sources to determine the vehicle's positioning information, particularly the altitude at the current location. In other embodiments, the positioning system can determine driving parameters related to the journey, such as heading, speed, and acceleration. The positioning system can be configured as part of the vehicle for multiple purposes, including automated driving applications, augmented driving, or user-assisted navigation. Illustratively, the positioning system can include processing components and data that aid in identifying various vehicle parameters or processing information.

[0039] In yet another aspect, the sensor constellation 212 can include one or more navigation systems for identifying navigation-related information. Illustratively, the navigation system can obtain positioning information from a positioning system and identify characteristics or information about the identified location, such as altitude, road grade, etc. The navigation system can also determine a recommended lane position or a predetermined lane position on a multi-lane road based on a direction provided or predicted to a vehicle user. Similar to a positioning system, a navigation system can be configured as part of a vehicle for multiple purposes, including automated driving applications, augmented driving, or user-assisted navigation.

[0040] The local resources further include one or more management components 210(s) that may operate on each vehicle 110 or on a computing device 130 (e.g., a mobile computing device) accessible from the vehicle. Illustratively, the management components 210(s) may access input from various sensors 212, process the input data, and store the processed data. For purposes of this application, the management components 210(s) will be described with respect to one or more functions related to the illustrative aspects. For example, the management components 210 may generate or configure a pseudonymous identifier by associating it with vehicle data generated from the multiple sensors 212. The management components 210 may communicate with the computing devices 130 and the network service 120 via communication means 216.

[0041] The environment may further include various additional sensor components or sensing systems operable to provide various operating parameter related information for use according to one or more operating conditions. Additionally, the environment may include one or more control components for processing the output, such as transmitting data via a communication output, generating data in a memory, or transmitting an output to another processing component.

[0042] 3A, an exemplary architecture for implementing the management component 210 on the vehicle 110 is described. The management component 210 may be part of a component / system that may generate or configure the pseudonymous identifier(s) and provide functionality related to processing and managing vehicle data for further use by the network service. The management component 210 may be further configured to identify instructions generated from the network service and perform one or more corrective actions based on the instructions.

[0043] The architecture of Figure 3A is exemplary in nature and should not be construed as requiring a particular hardware or software configuration for the managing component 210. The overall architecture of the managing component 210 shown in Figure 3A includes an arrangement of computer hardware and software components that can be used to implement aspects of the present disclosure. As shown, the managing component 210 includes a processing unit 302, a network interface 308, a computer-readable medium 306, and an input / output device interface 304, all of which can communicate with each other via a communication bus. The components of the managing component 210 can be physical hardware components that can include one or more circuits and software models.

[0044] Network interface 308 may provide connectivity to one or more networks or computing systems, such as networks 150, 160 of FIG. 1. Thus, processing unit 302 may receive information and instructions from other computing systems or services over a network. Processing unit 302 may also communicate with memory 310 and may also provide output information via an input / output device interface. In some embodiments, management component 210 may include more (or fewer) components than those shown in FIG. 3A.

[0045] The memory 310 may include computer program instructions that are executed by the processing unit 302 to implement one or more embodiments. The memory 310 typically includes RAM, ROM, or other persistent or non-transitory memory. The memory 310 may store an operating system 314 that provides computer program instructions used by the processing unit 302 in the overall management and operation of the management component 210. Additionally, the memory 310 may include computer program instructions and other information for implementing aspects of the present disclosure.

[0046] The memory 310 can include a pseudonymous identifier(s) management component 316. The pseudonymous identifier(s) management component 316 can be configured to generate or configure the pseudonymous identifier(s) by associating with vehicle data. Each pseudonymous identifier is a logical, generic identifier of an individual vehicle that can be transmitted and processed without association with vehicle or user identification information. The pseudonymous identifier can correspond to any one of a variety of unique or semi-unique identifiers. The pseudonymous identifier can be based on an attribute of the vehicle, such as a representation of a particular hardware or software component. In another embodiment, the pseudonymous identifier can be selected from a list of available pseudonymous identifiers, such as a random selection. The pseudonymous identifier(s) can be generated or configured at the time of manufacture, release from the manufacturer, etc. The pseudonymous identifier can be associated with a cryptographic or other security mechanism to prevent modification or corruption of the pseudonymous identifier by a user or an external service.

[0047] In one embodiment, the management of pseudonymous identifier(s) component 316 processes the vehicle data by adding a pseudonymous identifier corresponding to the vehicle. For example, the management of pseudonymous identifier(s) component 316 can add a pseudonymous identifier for each segment of vehicle data or group of vehicle data. In one embodiment, the pseudonymous identifier(s) are automatically added to the vehicle data when the vehicle data is transmitted from the vehicle to the network service. In one embodiment, the management of pseudonymous identifier(s) component 316 can generate new pseudonymous identifier(s) associated with the vehicle. For example, a manufacturer, manager, or owner of the vehicle can request that the pseudonymous identifier(s) be replaced with new identifier(s). For example, if information of the existing pseudonymous identifier(s) is made public, the vehicle owner can request that the pseudonymous identifier(s) be reset. In this example, the management of pseudonymous identifier(s) component 316 can generate a new identifier or receive a new identifier from the vehicle manufacturer (e.g., an authorized service facility, technician, or manager of the vehicle manufacturer). In such an embodiment, the management of pseudonymous identifier(s) component 316 may continue to keep track of the previous pseudonymous identifier by associating the identifier with the new pseudonymous identifier.

[0048] In one embodiment, the manage pseudonymous identifier(s) component 316 can identify any work (e.g., service work) performed on a vehicle by the vehicle's VIN number. For example, if the brake fluid is changed on a vehicle and a record of the brake fluid is stored with the vehicle's VIN number, the manage pseudonymous identifier(s) component 316 can associate the brake fluid history with the vehicle's pseudonymous identifier(s). In this example, the manage pseudonymous identifier(s) component 316 can identify work on a vehicle based on searching public records of the vehicle's VIN. In one embodiment, the manage pseudonymous identifier(s) component 316 can associate the pseudonymous identifier(s) with one or more service requests, service history, or service parts for the vehicle. For example, if a new part is ordered for a vehicle, the manage pseudonymous identifier(s) component 316 can associate the new part with the vehicle's pseudonymous identifier(s). The type or number of work or services on a vehicle is not limited by this disclosure.

[0049] The memory 310 may further include a vehicle data management component 318. In an embodiment, the vehicle data management component 318 may collect vehicle data. The vehicle data may include, but is not limited to, vehicle performance metrics, driving conditions, sensor values, location information, and the like. As described in FIG. 2, the vehicle includes multiple sensors, components, and data storage to acquire, generate, and maintain vehicle data, such as driving data. The collection and processing of vehicle data may be based on programmed configuration data, based on manual input by a user, or in response to a request from a network service.

[0050] The memory 310 may further include an instruction identification component 320. The instruction identification component 320 may be configured to identify one or more instructions sent from a network service. The instructions may include instructions that the vehicle needs to execute in response, such as a diagnostic, repair, or update process. In one embodiment, the instruction identification component 320 may collect and process published / posted vehicle instructions. In one embodiment, the instruction identification component 320 may identify an instruction corresponding to a vehicle by attempting to match a specific pseudonymous identifier of the vehicle with any of the pseudonymous identifiers associated with the vehicle instructions. If the instruction identification component 320 does not match the specific pseudonymous identifier of the vehicle, the instruction for the vehicle may be ignored.

[0051] The memory 310 may further include an instruction processing component 322. The instruction processing component 322 may process published / posted vehicle instructions associated with the vehicle pseudonym identifier. In some embodiments, the processing of the vehicle instructions may elicit a number of actions on the vehicle in response thereto. In one aspect, the instruction may include instructions to be performed by the vehicle in response thereto, such as a diagnostic, repair, or update process. One or more actions may be considered mandatory or optional. In another aspect, the vehicle instruction may include a request to elicit an action by the vehicle owner / user, such as generating a notification to schedule a service call. Additionally, the vehicle may send confirmation, status, or notification communications upon request or when preconfigured. In some embodiments, the instruction processing component 322 processes the instruction to classify the instruction based on priority (e.g., mandatory, optional, emergency), the type of action requested, and the like. The instruction processing component 322 may further provide one or more instructions or recommendations to the vehicle owner or driver based on the result of the processing of the instruction.

[0052] 3B, an example architecture for implementing the vehicle data service 122 on the network service 120 is described. The vehicle data service 122 may be part of a component / system that may provide functionality related to the vehicle 110 and / or the computing device 130. The vehicle data service 122 may be configured to periodically receive vehicle data and, based on processing of the vehicle data, send instructions to the vehicle. Based on the results of processing the vehicle data, the vehicle data service 122 may be configured to write instructions to the vehicle with a list of pseudonym identifiers.

[0053] The architecture of Figure 3B is exemplary in nature and should not be construed as requiring a particular hardware or software configuration for the vehicle data service 122. The overall architecture of the vehicle data service 122 shown in Figure 3B includes an arrangement of computer hardware and software components that may be used to implement aspects of the present disclosure. As shown, the vehicle data service 122 includes a processing unit 342, a network interface 348, a computer readable media drive 346, and an input / output device interface 344, all of which may communicate with each other via a communication bus. Each component of the vehicle data service 122 may be a physical hardware component that may include one or more circuits and software models.

[0054] Network interface 348 may provide connectivity to one or more networks or computing systems, such as networks 150, 160 of FIGURE 1. Thus, computing device 140 may receive information and instructions over a network from other computing systems or services. Vehicle data service 122 may communicate with memory 350 and may also provide output information via an input / output device interface. In some embodiments, vehicle data service 122 may include more (or less) components than those shown in FIGURE 3B.

[0055] The memory 350 may include computer program instructions that are executed by the processing unit 342 to implement one or more embodiments. The memory 350 typically includes RAM, ROM, or other persistent or non-transitory memory. The memory 350 may store an operating system 352 that provides computer program instructions used by the processing unit 342 in the overall management and operation of the vehicle data service 122.

[0056] The memory 350 can include an instruction identification component 354. The instruction identification component 354 can receive a request to issue a pseudonymous vehicle instruction. Illustratively, the vehicle instruction corresponds to one or more actions and associated parameters to be elicited upon receipt by the instruction identification component 354. In one aspect, the instruction can include instructions to be executed by the vehicle in response thereto, such as a diagnostic, repair, or update process. The one or more actions can be considered mandatory or optional. In another aspect, the vehicle instruction can include a request to elicit an action by the vehicle owner / user, such as generating a notification to schedule a service call.

[0057] In one embodiment, the instruction identification component 354 processes instruction requests to the vehicle. In one aspect, the instruction identification component 354 can verify that the request for vehicle data is authorized, such as through an authentication or authorization mechanism. In another aspect, the received request may not explicitly identify the pseudonymous identifier of interest, but indicates selection criteria (e.g., all vehicles with more than 100,000 miles on the clock). Thus, the instruction identification component 354 can query stored vehicle data to identify appropriate pseudonymous identifiers that are relevant to the selection criteria. In yet another aspect, if the selection criteria results in a set of pseudonymous identifiers that does not meet a size threshold, the network service can reject the request, request different criteria, or include different pseudonymous identifiers in the set. As previously discussed, having a set of one or more pseudonymous identifiers that exceed a threshold can mitigate potential network service. Thus, an individual or third party can repeatedly match a VIN or other identifying information to a particular pseudonymous identifier.

[0058] Memory 350 may further include an instruction writing component 356. The instruction writing component 356 may write a vehicle instruction request that identifies a set of pseudonymous identifiers that are requested to be incorporated into the instruction request. In some embodiments, the instruction writing component 356 need not actively send the vehicle instruction request to each vehicle. Alternatively, the instruction writing component 356 need not include a processing mechanism that specifically identifies a contact mechanism (e.g., a network address) for each pseudonymous identifier. Rather, each vehicle individually contacts the network service for the published list of pseudonymous identifiers and vehicle instructions.

[0059] In one embodiment, the instruction writing component 356 writes instructions to the vehicle with the list of pseudonymous identifiers. Illustratively, each vehicle need not be configured to send requests at the same time. The sending of requests can be randomized or performed over a range of times (e.g., during a day) so that the sending of requests can be distributed to reduce the network processing resource requirements of the network service. In one embodiment, the instruction writing component 356 can provide a set of published / written instructions to the vehicle and associated pseudonymous identifiers. This can include identifying the complete list of pseudonymous identifiers or a subset of the pseudonymous identifiers that has been sorted / filtered in some way. This approach requires that the vehicle can match the pseudonymous identifier against the list of pseudonymous identifiers. In another embodiment, the vehicle can send the pseudonymous identifier(s) of interest, and the instruction writing component 356 can then determine whether a match occurs. The network service can then respond with a notification or confirmation result. In this embodiment, the amount of data sent between the network service and the vehicle can be minimized. Additionally, aspects of this embodiment may reduce the impact on the vehicle's processing resources of processing the list to identify potential matches.

[0060] The memory 350 may further include a network request component 358. The network request component 358 may collect network performance information, such as network bandwidth. Alternatively, the network performance information may be collected according to a predefined rule for accessing vehicle data, such as a predefined two-way data communication protocol. In some embodiments, the network request component 358 may determine when to initiate communication with a vehicle. This may be when to request vehicle data from the vehicle. In some embodiments, the network request component 358 may monitor the network performance information to determine when to initiate a request for vehicle data, which vehicle data to request, and the like. For example, the network request component 358 may use the collected network performance information to determine when a vehicle data request can be initiated. In another embodiment, the network request component 358 may use the network performance information to select or filter among various requested information, such as selecting information with a higher priority when the quality of the (relative) network conditions is low. In a further embodiment, the network request component 358 may perform data transmissions at different times or intervals in scenarios where the quality of the network conditions is deemed to be more variable or deteriorating. By way of example, and without limitation, network performance information may include available bandwidth, delay measurements, transmission error rates, and the like.

[0061] In one embodiment, in response to detecting a decrease in network performance, the network request component 358 may configure a secondary network communication path with the computing device 130. For example, the vehicle and the network service may initially communicate over the network 150. In this example, if the network request component 358 detects that the vehicle 110 has a lost or interrupted network connection, the network request component 358 may automatically connect the vehicle 110 to the computing device 130 associated with the vehicle 110.

[0062] In one embodiment, the network request component 358 can determine an initial communication path between the vehicle and a network service or between the computing device and a network service. For example, the network request component 358 can establish an initial communication path with one of the computing device and the vehicle based on a criterion. The criterion can be based on the timing of responses received by the network request component 358. For example, if the network request component 358 receives a response from the vehicle before a response from the computing device, the network request component 358 can establish an initial communication path between the vehicle and the network service. The criterion can be based on monitoring of network performance. For example, the network request component 358 can compare the network performance of the network connections with the vehicle and the computing device.

[0063] 4, a description of an exemplary interaction between a network service and individual vehicles to generate pseudonyms is provided. Although a series of interactions is shown, the application is not limited to a particular number of vehicles interacting with the network service. Rather, in some embodiments, the number of interactions between individual vehicles and the network service is relatively large, including thousands or more individual vehicles.

[0064] In (1), the vehicles 110 may generate or configure (e.g., by management component 210) pseudonymous identifier(s) that will be utilized to identify each vehicle 110 to network services 120. As discussed above, the pseudonymous identifier may correspond to any one of a variety of unique or semi-unique identifiers. The pseudonymous identifier may be based on an attribute of the vehicle 110, such as a representation of a particular hardware or software component. In another embodiment, the pseudonymous identifier may be selected from a list of available pseudonymous identifiers, such as a random selection. The pseudonymous identifier(s) may be generated or configured at the time of manufacture, release from the manufacturer, etc.

[0065] At (2), the vehicle 110 may store the pseudonymous identifier in local memory for use in communications. The pseudonymous identifier may be associated with a cryptographic or other security mechanism to prevent modification or corruption of the pseudonymous identifier by a user or an external service.

[0066] At (3), pseudonym registration information may be transmitted from each vehicle 110 to a network service 120 (such as vehicle data service 122). This process illustrates the first instantiation of transmitting pseudonym identifiers between vehicles 110 and network service 120. Although these transmissions are shown as being transmitted in parallel, one of the vehicles 110 may be triggered to register with network service 120 at various times or in response to triggering criteria, such as delivery of the vehicle to a new owner. In an embodiment, the timing of the pseudonym transmission may be based on a seed value, such as a randomly generated number. As such, the transmission of the pseudonym is not tightly coupled to the timing of delivery of the vehicle or generation of the pseudonym.

[0067] At (4), the registration data with the pseudonymous identifier is processed by network service 120. Illustratively, network service 120 may instantiate one or more records, data stores, etc. based solely on the transmitted pseudonymous identifier and without further association with other identifying information related to the vehicle, such as a VIN or user identifier.

[0068] 5, an exemplary interaction between network service 120 and individual ones of vehicles 110 to effect the transmission of vehicle data based on one or more pseudonymous identifiers is described. As noted above, while a series of interactions is illustrated, the application is not limited to a particular number of vehicles 110 interacting with the network service. Rather, in some embodiments, the number of interactions between individual vehicles 110 and network service 120 is relatively large, including thousands or more individual vehicles.

[0069] At (1), vehicle data may be collected (e.g., by management component 210) in vehicle 110. As described above, the vehicle includes a number of sensors, components, and data storage for acquiring, generating, and maintaining vehicle data, including driving data. The collection and processing of vehicle data may be based on programmed configuration data, based on manual input by a user, or in response to a request from a network service (not shown).

[0070] At (2), vehicle 110 may associate vehicle data with a previously stored pseudonymous identifier maintained in local memory. The pseudonymous identifier and vehicle data may be associated with a cryptographic or other security mechanism to prevent modification or corruption of the pseudonymous identifier by a user or an external service.

[0071] In (3), one or more vehicles 110 may synchronize vehicle data with computing device 130. In some embodiments, this synchronization may be performed periodically or in real-time. In some embodiments, a portion of the data may be synchronized with computing device 130. In such embodiments, this portion of data may be defined or specified by a user, a vehicle manufacturer, a vehicle manager, etc. For example, computing device 130 may obtain only synchronized vehicle data related to engine oil management data. In this example, computing device 130 may transmit the engine oil management data directly to network service 120 by associating the data with a pseudonymous vehicle identifier. In some embodiments, process (3) may be an optional process.

[0072] At (4), vehicle data with the generated pseudonymous identifier may be transmitted from each vehicle to the network service. Although shown as a single transmission, the collection and transmission of vehicle data with associated pseudonymous identifiers may correspond to multiple transmissions. Such transmissions may be scheduled for each vehicle or for groups of vehicles. Additionally, while the transmissions are shown as being transmitted in parallel, the vehicles may be triggered to transmit vehicle data to the network service at various times or in response to trigger criteria, such as an error, a particular sensor value, a threshold of accumulated vehicle data, a change in a vehicle data value, etc. At (4), the network service processes the vehicle data with the pseudonymous identifier. Illustratively, the network service may utilize an instantiated record, data store, etc., associated with the previously transmitted pseudonymous identifier without further association with other identifying information associated with the vehicle, such as a VIN or user identifier. Thus, the network service may receive detailed information about the vehicle, including performance or operating parameters, illustratively without having the information necessary to identify the particular vehicle or vehicle owner that provided (or is associated with) the transmitted vehicle data.

[0073] In one embodiment, if the network connection between vehicle 110 and network service 120 is lost or interrupted, the computing device 130 can transmit synchronized vehicle data to network service 120. For example, computing device 130 and vehicle 110 can periodically synchronize vehicle data by utilizing network 160, such as a short-range data communications network. In this example, vehicle data can be transmitted from computing device 130 to network service 120 if vehicle 110 cannot connect to network 150.

[0074] 6, an exemplary interaction between network service 120 and individual ones of vehicles 110 to transmit instructions to the vehicles by one or more pseudonymous identifiers is described. As noted above, while a series of interactions is shown, the application is not limited to a particular number of vehicles 110 interacting with network service 120. Rather, in some embodiments, the number of interactions between individual vehicles 110 and network service 120 is relatively large, including thousands or more individual vehicles.

[0075] In (1), the network service 120 may process (or may receive a request to process) the pseudonymously stored vehicle data. In one embodiment, the network service 120 may analyze the collected performance data to identify one or more actions to be taken by the vehicle 110 associated with the pseudonymous identifier. For example, the network service 120 may perform a diagnostic process to identify potential hardware or software errors / faults indicated by the collected vehicle data. In another example, the network service 120 may utilize processing techniques to facilitate grouping or organizing a set of vehicles 110 based on vehicle data such as driving parameters, vehicle attributes, driving areas, usage characteristics, etc. In some embodiments, the processing of the stored vehicle data may be omitted or may be performed as a separate process and is not required herein.

[0076] At (2), a pseudonymous request for issuance of vehicle instructions is received at the network service 120. Illustratively, the vehicle instructions correspond to one or more actions and associated parameters that are to be elicited upon receipt at the vehicle. In one aspect, the instructions may include instructions to be executed by the vehicle in response thereto, such as a diagnostic, repair, or update process. The one or more actions may be deemed mandatory or optional. In another aspect, the vehicle instructions may include a request to elicit an action by the vehicle owner / user, such as generating a notification to schedule a service call.

[0077] In yet another aspect, the vehicle instructions may include requests / commands to transmit additional or supplemental vehicle data to network service 120 or a third party. For example, the vehicle instructions may include transmitting a particular vehicle identification (e.g., VIN) and particular driving parameters that may be utilized for subsequent action by network service 120. In such a response communication, the pseudonymous identifier may be omitted such that network service 120 does not associate the supplementally provided vehicle identifier with the pseudonymous identifier.

[0078] In a variation of the above, the vehicle instructions may include a list of specific vehicles that network service 120 is interested in tracking as a subset of the pseudonymous identifiers. Thus, the vehicle instructions may request that the pseudonymous identifiers be returned in response to a matching VIN. In this regard, if the subset of pseudonymous identifiers is large enough, the service provider may not be able to definitively associate a particular VIN with a pseudonymous identifier.

[0079] At (3), the network service 120 processes the request for vehicle instructions. In one aspect, the network service 120 can verify that the request for vehicle data is authorized, such as through an authentication or authorization mechanism. In another aspect, the received request may not explicitly identify the pseudonymous identifier of interest, but may indicate selection criteria (e.g., all vehicles with more than 100,000 miles on the odometer). Thus, the network service 120 can query stored vehicle data to identify suitable pseudonymous identifiers that are relevant to the selection criteria. If the selection criteria results in a set of pseudonymous identifiers that does not meet the size threshold, the network service 120 can reject the request, request additional criteria, or include additional pseudonymous identifiers in the set. As previously discussed, having one or more sets of pseudonymous identifiers that exceed the threshold can mitigate potential network service 120. Thus, an individual or third party can repeatedly match a VIN or other identifying information to a particular pseudonymous identifier.

[0080] At (4), network service 120 can populate a vehicle instruction request that identifies the set of pseudonymous identifiers that are requested to be incorporated into the instruction request. In this embodiment, network service 120 need not actively send vehicle instruction requests to each vehicle, or include a processing mechanism that specifically identifies a contact mechanism (e.g., a network address) for each pseudonymous identifier. Rather, each vehicle individually contacts network service 120 with the published list of pseudonymous identifiers and vehicle instructions.

[0081] At (5), written vehicle instructions are requested from each vehicle 110 along with the list of pseudonymous identifiers. Illustratively, each vehicle need not be configured to send requests at the same time. The sending of requests can be randomized or performed over a range of times (e.g., during a day) so that the sending of requests can be distributed to reduce network processing resource requirements by the network service 120. At (6), the network service 120 can respond to each request individually. In one embodiment, the network service 120 can provide the published / written vehicle instructions and the associated set of pseudonymous identifiers. This can include identifying the complete list of pseudonymous identifiers or a subset of the pseudonymous identifiers that has been sorted / filtered in some way. This approach requires that the vehicle 110 can match the pseudonymous identifier against the list of pseudonymous identifiers. In another embodiment, the vehicle can send the pseudonymous identifier(s) of interest, and the network service 120 can then determine whether a match occurs. The network service 120 can then respond with a notification or confirmation result. This embodiment can minimize the amount of data transmitted between network service 120 and the vehicle and can also reduce the impact on the vehicle's processing resources to process the list to identify potential matches.

[0082] In (7), the vehicle 110 may collect and process (e.g., by the management component 210) the set of published / posted vehicle instructions and associated pseudonymous identifiers. As described above, the vehicle processes the set of published / posted vehicle instructions and associated pseudonymous identifiers by attempting to match the vehicle's particular pseudonymous identifier with any of the pseudonymous identifiers associated with the vehicle instructions. If the vehicle does not match the vehicle's particular pseudonymous identifier, the vehicle instruction may be ignored. Alternatively, as shown in FIG. 6, the vehicle instruction may be initiated or processed by the vehicle for a subset of vehicles that match the pseudonymous identifier. As described above, initiating the vehicle instruction may elicit some responsive action by the vehicle. In one aspect, the instruction may include instructions to be executed by the vehicle in response thereto, such as a diagnostic, repair, or update process. One or more actions may be considered mandatory or optional. In another aspect, the vehicle instruction may include a request to elicit an action by the vehicle owner / user, such as generating a notification to schedule a service call. Additionally, the vehicle may send confirmation, status, or notification communications on demand or when preconfigured.

[0083] At (8), vehicle 110 may initiate vehicle instructions. In some embodiments, vehicle 110 processes the instructions to categorize the instructions based on priority (e.g., required, optional, emergency), type of action required, etc. Vehicle 110 may further provide one or more instructions or recommendations to the vehicle owner or driver based on the results of processing the instructions.

[0084] 7, an alternative embodiment of an exemplary interaction between network service 120 and computing device 130 for sending instructions to vehicles with one or more pseudonymous identifiers is described. As discussed above, while a series of interactions is shown, the application is not limited to a particular number of vehicles 110 and computing devices 130 interacting with network service 120. Rather, in some embodiments, the number of interactions between individual vehicles 110 and network service 120 is relatively large, involving thousands or more individual vehicles. Processes (1) through (4) described in FIG. 6 may be used in FIG. 7.

[0085] In (5), the computing device 130 may request the posted vehicle instructions with the list of pseudonymous identifiers. Illustratively, the computing device 130 need not be configured to send the requests simultaneously. The requests may be randomized or may be performed over a range of times (e.g., during a day) so that the requests can be distributed to reduce the network processing resource requirements of the network service 120. In (6), the network service 120 may respond to each request individually. In one embodiment, the network service 120 may provide the published / posted vehicle instructions and the associated set of pseudonymous identifiers. This may include identifying the complete list of pseudonymous identifiers or a subset of the pseudonymous identifiers that may have been sorted / filtered in some way. This approach requires that the vehicle 110 may match the pseudonymous identifier against the list of pseudonymous identifiers. In another embodiment, the computing device 130 may send the pseudonymous identifier(s) of interest, and the network service 120 may then determine whether a match occurs. The network service 120 may then respond with a notification or confirmation. In this embodiment, the amount of data transmitted between network service 120 and computing device 130 may be minimized, and the impact on the processing resources of computing device 130 to process the list to identify potential matches may also be reduced.

[0086] In (7), the computing device 130 may collect and process a set of published / posted vehicle instructions and associated pseudonymous identifiers. As described above, the computing device 130 processes the set of published / posted vehicle instructions and associated pseudonymous identifiers by attempting to match the vehicle's particular pseudonymous identifier with any of the pseudonymous identifiers associated with the vehicle instructions. If the computing device 130 does not match the vehicle's particular pseudonymous identifier, the vehicle instruction may be ignored. Alternatively, as shown in FIG. 7, for a subset of vehicles that match the pseudonymous identifier, the computing device 130 may initiate or process the vehicle instruction. As described above, initiating the vehicle instruction may elicit some responsive action by the computing device 130. In one aspect, the instruction may include instructions to be executed by the computing device 130 in response thereto, such as a diagnostic, repair, or update process. One or more of the actions may be considered mandatory or optional. In another aspect, the vehicle instruction may include a request to elicit an action by the vehicle owner / user, such as generating a notification to schedule a service call. Additionally, the vehicle may send confirmation, status, or notification communications on demand or when preconfigured.

[0087] At (8), computing device 130 may initiate instructions to the vehicle. In one embodiment, computing device 130 processes the instructions to categorize the instructions based on priority (e.g., required, optional, emergency), type of action required, etc. Computing device 130 may further provide one or more instructions or recommendations to the owner or driver of the vehicle based on the results of processing the instructions.

[0088] At (9), the computing device 130 may synchronize vehicle data, such as updated vehicle data based on processing the instructions, with the vehicle 110.

[0089] In an alternative embodiment, both the vehicle 110 and the computing device 130 may respond to instructions posted by the network service 120. In this embodiment, the network service 120 may establish an initial communication path between the vehicle and the network service based on a criterion. The criterion may be based on the timing of responses received by the network service 120 (e.g., the network request component 358). For example, if the network request component 358 receives a response from the vehicle before a response from the computing device, the network request component 358 may establish an initial communication path between the vehicle and the network service. The criterion may be based on monitoring of network performance. For example, the network request component 358 may compare the network performance of the network connections with the vehicle and the computing device.

[0090] 8, a vehicle pseudonym management routine 800 will be described, which is illustratively implemented by management component 210 implemented in one of vehicles 110. The process illustrated in FIG. 8 is illustrative in nature and should not be construed as limiting.

[0091] At block 802, the vehicle 110 may generate or configure (e.g., by management component 210) a pseudonymous identifier that will be utilized by network services 120 to identify the individual vehicle of the vehicle 110. As discussed above, the pseudonymous identifier may correspond to any one of a variety of unique or semi-unique identifiers. The pseudonymous identifier may be based on an attribute of the particular vehicle 110, such as a representation of a particular hardware or software component. In another embodiment, the pseudonymous identifier may be selected from a list of available pseudonymous identifiers, such as a random selection. The pseudonymous identifier(s) may be generated or configured at the time of manufacture, release from the manufacturer, etc.

[0092] At block 804, the vehicle 110 may store the pseudonymous identifier in local memory for use in communications. The pseudonymous identifier may be associated with a cryptographic or other security mechanism to prevent modification or corruption of the pseudonymous identifier by a user or an external service.

[0093] At block 806, the generated pseudonym registration information may be transmitted from each vehicle 110 to a network service 120 (such as vehicle data service 122). This process illustrates a first instantiation of transmitting pseudonym identifiers between the vehicles 110 and the network service 120. Although these transmissions are shown as being transmitted in parallel, one of the vehicles 110 may be triggered to register with the network service 120 at various times or in response to a triggering criterion, such as delivery of the vehicle to a new owner. In an embodiment, the timing of the pseudonym transmission may be based on a seed value, such as a randomly generated number. As such, the transmission of the pseudonym is not tightly related to the timing of delivery of the vehicle or the generation of the pseudonym. The routine 800 may end at block 806.

[0094] 9, a vehicle data transmission routine 900 will be described. The routine 900 is illustratively implemented by a management component 210 implemented in one of the vehicles 110. The process illustrated in FIG. 9 is illustrative in nature and should not be construed as limiting.

[0095] At block 902, vehicle data may be collected in the vehicle 110 (e.g., by the management component 210). As described above, the vehicle includes a number of sensors, components, and data storage for acquiring, generating, and maintaining vehicle data, including driving data. The collection and processing of vehicle data may be based on programmed configuration data, based on manual input by a user, or in response to a request from a network service (not shown).

[0096] At block 904, vehicle data may be associated with the previously stored pseudonymous identifier maintained in local memory in vehicle 110. The pseudonymous identifier and vehicle data may be associated with an encryption or other security mechanism to prevent modification or corruption of the pseudonymous identifier by a user or an external service.

[0097] In some embodiments, vehicle data may be synchronized with the computing device 130 by one or more of the vehicles 110. In some embodiments, this synchronization may be performed periodically or in real time. In some embodiments, a portion of the data may be synchronized with the computing device 130. In such embodiments, this portion of the data may be defined or specified by a user, a vehicle manufacturer, a vehicle manager, etc. For example, the computing device 130 may obtain only synchronized vehicle data related to engine oil management data. In this example, the computing device 130 may transmit the engine oil management data directly to the network service 120 by associating the data with a pseudonymous vehicle identifier. In some embodiments, process (3) may be an optional process.

[0098] At block 904, vehicle data with the generated pseudonym identifier may be transmitted from each vehicle to the network service. Although shown as a single transmission, the collection and transmission of vehicle data with associated pseudonym identifiers may correspond to multiple transmissions. Such transmissions may be scheduled for individual vehicles or for groups of vehicles. Additionally, while the transmissions are shown as being transmitted in parallel, vehicles may be triggered to transmit vehicle data to the network service at various times or in response to trigger criteria such as an error, a particular sensor value, a threshold of accumulated vehicle data, a change in a vehicle data value, etc.

[0099] In one embodiment, if a network connection between one of the vehicles 110 and the network service 120 is lost or interrupted, the computing device 130 may transmit the synchronized vehicle data to the network service 120. For example, the computing device 130 and one of the vehicles 110 may periodically synchronize the vehicle data by utilizing a network 160, such as a short-range data communications network. In this example, the vehicle data may be transmitted from the computing device 130 to the network service 120 if the vehicle is unable to connect to the network 150. The routine 900 may end at block 906.

[0100] 10, a routine 1000 for processing vehicle instruction requests is described. The routine 1000 is illustratively implemented by a management component 210 implemented in one of the vehicles 110. The process illustrated in FIG 10 is exemplary in nature and should not be construed as limiting.

[0101] At block 1002, written vehicle instructions accompanied by a list of pseudonym identifiers are requested from each vehicle 110. Illustratively, each vehicle need not be configured to send requests at the same time. The sending of requests can be randomized or performed over a range of times (e.g., within a day) so that the sending of requests can be distributed to reduce network processing resource requirements by network service 120.

[0102] At block 1004, the vehicle 110 may receive (e.g., by the management component 210) a set of published / posted vehicle instructions and associated pseudonymous identifiers. At block 1006, the vehicle 110 processes the published / posted set of vehicle instructions and associated pseudonymous identifiers by attempting to match the vehicle's particular pseudonymous identifier with any of the pseudonymous identifiers, including those associated with the vehicle instructions. If the vehicle does not match the vehicle's particular pseudonymous identifier, the routine 1000 may end at block 1010 and the vehicle instructions may be ignored. If the vehicle matches the vehicle's particular pseudonymous identifier, the routine continues to block 1008. In some embodiments, a subset of the vehicles that match the pseudonymous identifier may initiate or process a vehicle instruction by the vehicle. In such an embodiment, initiating a vehicle instruction may elicit some responsive action by the vehicle. In one aspect, the instruction may include instructions to be executed by the vehicle in response thereto, such as a diagnostic, repair, or update process. One or more actions may be considered mandatory or optional. In another aspect, the instructions to the vehicle may include a request to elicit an action by the vehicle owner / user, such as generating a notification to schedule a service call. Additionally, the vehicle may also send confirmation, status, or notification communications upon request or when preconfigured.

[0103] At block 1008, vehicle 110 may initiate vehicle instructions. In one embodiment, processing of the instructions by vehicle 110 may categorize the instructions based on priority (e.g., required, optional, emergency), type of action required, etc. Vehicle 110 may further provide one or more instructions or recommendations to the vehicle owner or driver based on the results of processing the instructions.

[0104] 11, a routine 1100 for processing vehicle instruction requests will be described. Routine 1100 is illustratively performed by vehicle data service 122 implemented in network service 120. The process illustrated in FIG. 10 is exemplary in nature and should not be construed as limiting.

[0105] At block 1102, a pseudonymous request for issuance of vehicle instructions is received at the network service 120. Illustratively, the vehicle instructions correspond to one or more actions and associated parameters to be elicited upon receipt at the vehicle. In one aspect, the instructions may include instructions to be executed by the vehicle in response thereto, such as a diagnostic, repair, or update process. The one or more actions may be considered mandatory or optional. In another aspect, the vehicle instructions may include a request to elicit an action by the vehicle owner / user, such as generating a notification to schedule a service call.

[0106] In yet another aspect, the vehicle instructions may include requests / commands to transmit additional or supplemental vehicle data to network service 120 or a third party. For example, the vehicle instructions may include transmitting a particular vehicle identification (e.g., VIN) and particular driving parameters that may be utilized for subsequent action by network service 120. In such a response communication, the pseudonymous identifier may be omitted such that network service 120 does not associate the supplementally provided vehicle identifier with the pseudonymous identifier.

[0107] In a variation of the above, the vehicle instructions may include a list of specific vehicles that network service 120 is interested in tracking as a subset of the pseudonymous identifiers. Thus, the vehicle instructions may request that the pseudonymous identifiers be returned in response to a matching VIN. In this regard, if the subset of pseudonymous identifiers is large enough, the service provider may not be able to definitively associate a particular VIN with a pseudonymous identifier.

[0108] In some embodiments, the network service 120 may process (or receive requests to process) the pseudonymously stored vehicle data. In one embodiment, the network service 120 may analyze the collected performance data to identify one or more actions to be taken by the vehicle 110 associated with the pseudonymous identifier. For example, the network service 120 may perform a diagnostic process to identify potential hardware or software errors / faults indicated by the collected vehicle data. In another example, the network service 120 may utilize processing techniques to facilitate grouping or organizing a set of vehicles 110 based on vehicle data such as driving parameters, vehicle attributes, driving areas, usage characteristics, etc. In some embodiments, the processing of the stored vehicle data may be omitted or may be performed as a separate process and is not required herein.

[0109] At block 1104, the network service 120 processes the request for vehicle instructions. In one aspect, the network service 120 can verify that the request for vehicle data is authorized, such as through an authentication or authorization mechanism. In another aspect, the received request may not explicitly identify the pseudonymous identifier of interest, but may indicate selection criteria (e.g., all vehicles with more than 100,000 miles on the odometer). Thus, the network service 120 can query stored vehicle data to identify suitable pseudonymous identifiers that are relevant to the selection criteria. In yet another aspect, if the selection criteria results in a set of pseudonymous identifiers that does not exceed a size threshold, the network service 120 can reject the request, request additional criteria, or include additional pseudonymous identifiers in the set. As previously discussed, having one or more sets of pseudonymous identifiers that exceed a threshold can mitigate potential network service 120. Thus, an individual or third party can repeatedly match a VIN or other identifying information to a particular pseudonymous identifier.

[0110] At block 1106, network service 120 may respond to each request individually. In one embodiment, network service 120 may provide published / posted instructions to the vehicle and a set of associated pseudonymous identifiers. This may include identifying the complete list of pseudonymous identifiers or some sorted / filtered subset of the pseudonymous identifiers. This approach requires that the vehicle be able to match the pseudonymous identifier against the list of pseudonymous identifiers.

[0111] At block 1108, network service 120 may receive a specific response to the posted pseudonym indication request. In one embodiment, the vehicle may transmit the pseudonym identifier(s) of interest, and network service 120 may then determine whether a match occurs. In one embodiment, network service 120 may then respond with a notification or confirmation. This embodiment may minimize the amount of data transmitted between network service 120 and the vehicle, and may also reduce the impact on the vehicle's processing resources to process the list to identify potential matches.

[0112] At block 1110, network service 120 may process the particular response received to writing the vehicle instruction request that identifies the set of pseudonymous identifiers that were requested to incorporate the instruction request. In this embodiment, network service 120 need not actively send vehicle instruction requests to each vehicle. Alternatively, network service 120 need not include a processing mechanism that specifically identifies a contact mechanism (e.g., a network address) for each pseudonymous identifier. Rather, each vehicle individually contacts network service 120 for the published list of pseudonymous identifiers and vehicle instructions. Routine 1100 may end at block 1112.

[0113] Various embodiments of the present disclosure may be systems, methods, and / or computer program products at any feasible level of technical detail integration. The computer program product may include computer-readable storage medium(s) having computer-readable program instructions for causing a processor to perform aspects of the present disclosure.

[0114] For example, software instructions may perform functions described herein when executed by one or more hardware processors and / or any other suitable computing devices and / or may perform functions described herein in response to the software instructions being executed. The software instructions and / or other executable code may be read from a computer-readable storage medium(s).

[0115] A computer readable storage medium may be a tangible device capable of holding and storing data and / or instructions used by an instruction execution device. A computer readable storage medium may be, for example, but is not limited to, an electronic storage device (including any volatile and / or non-volatile electronic storage device), a magnetic storage device, an optical storage device, an electromagnetic storage device, a semiconductor storage device, or any suitable combination thereof. Although not exhaustive, more specific examples of computer readable storage media include portable computer floppy disks, hard disks, solid state drives, random access memory (RAM), read only memory (ROM), erasable programmable read only memory (EPROM or flash memory), static random access memory (SRAM), portable compact disk read only memory (CD-ROM), digital versatile disk (DVD), memory stick, floppy disk, or mechanically encoded devices such as punch cards or ridges in grooves structures with instructions recorded thereon, and any suitable combination of the above. A computer-readable storage medium as used herein should not be construed as a transitory signal per se, such as radio waves or other freely propagating electromagnetic waves, electromagnetic waves propagating through a waveguide or other transmission medium (e.g., light pulses passing through a fiber optic cable), or electrical signals transmitted over wires.

[0116] The computer-readable program instructions described herein can be downloaded from a computer-readable storage medium to each computing / processing device, or can be downloaded to an external computer or storage device via a network, such as the Internet, a local area network, a wide area network, and / or a wireless network. The network can include copper transmission cables, optical transmission fiber, wireless transmission, routers, firewalls, switches, gateway computers, and / or edge servers. A network adapter card or network interface in each computing / processing device receives the computer-readable program instructions from the network and transfers the computer-readable program instructions for storage in a computer-readable storage medium in the respective computing / processing device.

[0117] Computer readable program instructions (e.g., also referred to as "code," "instructions," "modules," "applications," "software applications," etc.) for carrying out the operations of the present disclosure can be either source code or object code written in any combination of one or more programming languages, including assembler instructions, Instruction-Set-Architecture (ISA) instructions, machine instructions, machine-dependent instructions, microcode, firmware instructions, state setting data, configuration data for an integrated circuit, or procedural programming languages, such as object-oriented programming languages ​​such as Java, C++, and the like, and procedural programming languages, such as the "C" programming language or similar programming languages. The computer readable program instructions can be invoked from other instructions or from themselves, and / or can be invoked in response to detected actions or interrupts. The computer readable program instructions configured to be executed on a computing device can be provided on a computer readable storage medium and / or provided as a digital download that can be further stored on the computer readable storage medium (the digital download can be initially stored in a compressed or installable format that requires installation, decompression, or decryption before execution). Such computer readable program instructions may be stored partially or completely on a memory device (e.g., a computer readable storage medium) of the executing computing device for execution on the computing device. The computer readable program instructions may be executed entirely on the user's computer (e.g., the executing computing device), partially on the user's computer, partially on the user's computer, partially on a remote computer, or as a standalone software package entirely on a remote computer or server.In the latter scenario, the remote computer may be connected to the user's computer over any type of network, including a local area network (LAN) or wide area network (WAN), or may be connected to an external computer (e.g., over the Internet using an Internet Service Provider). In an embodiment, computer readable program instructions may be executed by electronic circuitry, including, for example, programmable logic circuitry, a field programmable gate array (FPGA), or a programmable logic array (PLA), using state information of the computer readable program instructions to personalize the electronic circuitry to perform aspects of the disclosure.

[0118] Aspects of the present disclosure are described herein with reference to flowchart illustrations and / or block diagrams of methods, apparatus (systems), and computer program products according to embodiments of the present disclosure. It will be understood that each block of the flowchart illustrations and / or block diagrams, and combinations of blocks in the flowchart illustrations and / or block diagrams, can be implemented by computer readable program instructions.

[0119] These computer-readable program instructions can be provided to a processor of a general purpose computer, special purpose computer, or other programmable data processing apparatus to produce an apparatus, where the instructions, executed by the processor of the computer or other programmable data processing apparatus, provide means for performing the functions / operations specified in one or more blocks of the flowcharts and / or block diagrams. These computer-readable program instructions can also be stored on a computer-readable storage medium that can direct a computer, programmable data processing apparatus, and / or other device to function in a particular manner. As a result, the computer-readable storage medium storing instructions will comprise an article of manufacture including instructions that perform aspects of the functions / operations specified in one or more blocks of the flowchart(s) and / or block diagram(s).

[0120] Computer-readable program instructions may also be loaded onto a computer, other programmable apparatus, or other device to cause the computer, other programmable apparatus, or other device to execute a series of operational steps to produce a computer-implemented procedure, such that the instructions executed on the computer, other programmable apparatus, or other device perform the functions / operations specified in one or more blocks of the flowcharts and / or block diagrams. For example, the instructions may initially be carried on a magnetic disk or solid state drive of a remote computer. The remote computer may load the instructions and / or modules into its own dynamic memory and transmit the instructions using a modem over a telephone, cable, or optical line. A modem local to the server computing system may receive the data over the telephone / cable / optical line and, using a converter device containing appropriate circuitry, place the data on a bus. The bus may carry the data to a memory, from which the instructions may be retrieved and executed by a processor. The instructions received by the memory may be stored on a storage device (e.g., a solid state drive) as appropriate, either before or after execution by the computer processor.

[0121] The flowcharts and block diagrams in the figures illustrate the architecture, functionality, and operation of possible implementations of systems, methods, and computer program products according to various embodiments of the present disclosure. In this regard, each block in the flowchart or block diagram may represent a module, segment, or part of instructions, including one or more executable instructions for implementing a specified logical function(s). In some alternative implementations, the functions described in each block may be performed in a different order than the order described in the figures. For example, two blocks shown in succession may in fact be executed substantially simultaneously, or the blocks may sometimes be executed in the reverse order, depending on the functionality involved. Furthermore, in some implementations, certain blocks may be omitted. Additionally, the methods and processes described herein are not limited to any particular sequence, and the associated blocks or states may be executed in other sequences as appropriate.

[0122] It should also be noted that each block of the block diagrams and / or flowchart illustrations, and combinations of blocks in the block diagrams and / or flowchart illustrations, may be implemented by a dedicated hardware-based system performing the specified functions or operations or executing a combination of dedicated hardware and computer instructions. For example, any of the processes, methods, algorithms, elements, blocks, applications, or other functions (or portions of functions) described in the preceding sections may be embodied in electronic hardware, such as application-specific processors such as Application-Specific Integrated Circuits (ASICs), programmable processors such as Field Programmable Gate Arrays (FPGAs), application-specific circuits, and / or may be fully or partially automated (any of which may involve custom hardwired logic, logic circuits, ASICs, FPGAs, etc., combined with custom programming / execution of software instructions to realize the techniques).

[0123] Any of the above-mentioned processors and / or devices incorporating any of the above-mentioned processors may be referred to herein as, for example, a "computer," a "computing device," a "computing device," a "hardware computing device," a "hardware processor," a "processing unit," and the like. The computing devices of the above embodiments may typically (although not necessarily) be controlled and / or coordinated by operating system software, such as Mac OS, iOS, Android, Chrome OS, Windows OS (e.g., Windows XP, Windows Vista, Windows 7, Windows 8, Windows 10, Windows Server, etc.), Windows CE, Unix, Linux, SunOS, Solaris, Blackberry OS, VxWorks, or other suitable operating systems. In other embodiments, the computing devices may be controlled by their own operating system. A conventional operating system controls and schedules computer processes for execution, performs memory management, provides file systems, networking, I / O services, and provides user interface functionality, such as a graphical user interface (GUI), among others.

[0124] As described above, in various embodiments, certain functionality may be accessed by a user via a web-based viewer (such as a web browser) or other suitable software program. In such implementations, the user interface may be generated by a server computing system and sent to the user's web browser (e.g., executed on the user's computing system). Alternatively, data necessary to generate the user interface (e.g., user interface data) may be provided by the server computing system to the browser to generate the user interface (e.g., the user interface data may be executed by a browser accessing a web service and configured to render the user interface based on the user interface data). The user may then interact with the user interface via the web browser. The user interface of certain implementations may be accessed via one or more dedicated software applications. In certain embodiments, one or more of the computing devices and / or systems of the present disclosure may include a mobile computing device, and the user interface may be accessed via such a mobile computing device (e.g., a smartphone and / or tablet).

[0125] It should be understood that many variations and modifications can be made to the above-described embodiments, and that the elements are among the other acceptable examples. All such modifications and variations are intended to be included within the scope of the present disclosure. The above description details certain embodiments. However, no matter how detailed the above content is, it will be understood that the systems and methods can be implemented in many ways. Also, as mentioned above, the use of a particular term when describing a particular feature or aspect of the systems and methods should not be interpreted as meaning that the term is redefined herein to be limited to include the particular characteristic of the feature or aspect of the systems and methods to which the term relates.

[0126] In particular, conditional terms such as "can," "could," "might," or "may," unless otherwise specified or understood otherwise within the context in which they are used, are intended to generally convey that certain features, elements, and / or steps are included in certain embodiments, but that other embodiments may not include them. Thus, such conditional terms are generally not intended to imply that the features, elements, and / or steps are in any way required for one or more embodiments, or that logic for determining whether those features, elements, and / or steps should be included or performed in any particular embodiment, with or without user input or prompting, is necessarily included in one or more embodiments.

[0127] Conjunction terms in phrases such as "at least one of X, Y, and Z," or "at least one of X, Y, or Z," should be understood in the context in which they are commonly used to convey that an item, term, etc. can be either X, Y, or Z, or any combination thereof, unless otherwise noted. For example, the term "or" is used in an inclusive (rather than exclusive) sense, e.g., when used to connect a number of elements, the term "or" may mean one, some, or all of the elements in the list. Thus, such conjunctive terms are not generally intended to imply that at least one of X, at least one of Y, and at least one of Z, respectively, must be present in a particular embodiment.

[0128] The term "a" as used herein should be given an inclusive interpretation, not an exclusive interpretation. For example, unless otherwise specified, the term "a" should not be understood to mean "exactly one" or "only one." Instead, the term "a" means "one or more" or "at least one," regardless of whether it is used in the claims or elsewhere in the specification, and regardless of the use of quantifiers such as "at least one," "one or more," or "plurality" in the claims or elsewhere in the specification.

[0129] The term "comprising" as used herein should be given an inclusive rather than an exclusive interpretation. For example, a general purpose computer including one or more processors should not be interpreted as excluding other computer components, and may include components such as memory, input / output devices, and / or network interfaces, among others.

[0130] While the above detailed description has shown, described and pointed out novel features as applied to various embodiments, it will be understood that various omissions, substitutions and changes may be made in the form and details of the illustrated devices or processes without departing from the spirit of the disclosure. As will be recognized, certain features may be used or practiced separately from other features, and therefore certain embodiments of the invention described herein may be embodied in a form that does not provide all of the features and benefits described herein. The scope of the particular inventions disclosed herein is indicated by the appended claims, rather than the foregoing description. All changes that come within the spirit and range of equivalence of the claims are intended to be embraced within their scope.

Claims

1. 1. A system for managing vehicle data using a pseudonymous identifier associated with a vehicle, comprising: and one or more external computing devices associated with a processor and a memory for executing computer-executable instructions to implement a management component, the management component performing a pseudonym configuration that associates each of the pseudonym identifiers with an individual vehicle, the configuration of the pseudonym identifiers comprising: Identifying a pseudonymous identifier; storing the identified pseudonymous identifier; and and transmitting the identified pseudonymous identifier; A network service receives a vehicle data transmission, the vehicle data transmission comprising: Collecting vehicle data; Associating the vehicle data with the identified pseudonymous identifier; and transmitting the vehicle data along with the identified pseudonymous identifier to the network service; and requesting an instruction to the vehicle from the network service, and requesting the instruction to the vehicle. sending instructions to a network service to write to the vehicle; receiving the written vehicle instructions; identifying at least one instruction associated with the vehicle; and initiating the identified instruction.

2. The system of claim 1 , wherein the vehicle instructions include instructions to be executed by the vehicle in response to identifying the vehicle instructions associated with the vehicle, such as a diagnostic, repair, or update process.

3. The system of claim 1 , wherein the pseudonymous identifier is one of a variety of unique or semi-unique identifiers associated with the individual vehicles.

4. The system of claim 1 , wherein the individual vehicles include a number of sensors, components, and data storage for acquiring, generating, and maintaining the vehicle data.

5. The system of claim 1 , wherein the management component is further configured to synchronize the vehicle data with a computing device, the computing device configured to wirelessly communicate the vehicle data.

6. The system of claim 5 , wherein the computing device is configured to transmit the vehicle data to the network service.

7. The system of claim 1 , wherein the posted vehicle instructions disclose a set of vehicle instructions and associated pseudonymous identifiers.

8. The network service, receiving a request for issuance of an instruction to the vehicle using the pseudonymous identifier; processing the request for vehicle instructions by identifying a suitable pseudonymous identifier associated with a selection criterion, where the selection criterion is associated with a threshold value of a vehicle attribute, and where the vehicle instructions associated with the suitable pseudonymous identifier are written vehicle instructions; The system of claim 1 , configured to provide the written vehicle instructions to the management component.

9. 1. A system for managing vehicle data using a pseudonymous identifier associated with a vehicle, comprising: Identifying a pseudonymous identifier associated with the vehicle; transmitting the vehicle data along with the identified pseudonymous identifier to a network service; receiving, from a network service, instructions for the posted vehicle; identifying at least one instruction associated with the vehicle; and initiating the identified instruction.

10. 10. The system of claim 9, wherein the vehicle instructions include instructions to be executed by the vehicle in response to identifying the vehicle instructions associated with the vehicle, such as a diagnostic, repair, or update process.

11. The system of claim 9 , wherein the pseudonymous identifier is one of various unique or semi-unique identifiers associated with each of the vehicles.

12. The system of claim 1 , further comprising synchronizing the vehicle data with a computing device, the computing device configured to communicate the vehicle data.

13. The system of claim 12 , wherein the computing device is configured to transmit the vehicle data to the network service.

14. The system of claim 9 , wherein the posted vehicle instructions disclose a set of vehicle instructions and associated pseudonymous identifiers.

15. The network service, receiving a request for issuance of an instruction to the vehicle using the pseudonymous identifier; processing the request for vehicle instructions by identifying a suitable pseudonymous identifier associated with a selection criterion, where the selection criterion is associated with a threshold value of a vehicle attribute, and where the vehicle instructions associated with the suitable pseudonymous identifier are written vehicle instructions; The system of claim 9 , configured to provide the written vehicle instructions to the vehicle.

16. 1. A computer-implemented method for managing vehicle data using a pseudonymous identifier associated with a vehicle, comprising: Identifying a pseudonymous identifier associated with each vehicle; storing the identified pseudonymous identifier; transmitting the identified pseudonymous identifier to a network service; Associating the vehicle data with the identified pseudonymous identifier; and transmitting the vehicle data with the identified pseudonymous identifier to a network service; Sending instructions to a network service to write to the vehicle; receiving the written vehicle instructions; identifying at least one instruction associated with the vehicle; and initiating the identified instruction.

17. 20. The computer-implemented method of claim 16, wherein the vehicle instructions include instructions to be executed by the vehicle in response to identifying the vehicle instructions associated with the vehicle, such as a diagnostic, repair, or update process.

18. 20. The computer-implemented method of claim 16, wherein the pseudonymous identifier is one of a variety of unique or semi-unique identifiers associated with the individual vehicle.

19. 20. The computer-implemented method of claim 16, wherein the individual vehicles are further configured to synchronize the vehicle data with a computing device, the computing device configured to wirelessly communicate the vehicle data.

20. 20. The computer-implemented method of claim 19, wherein the computing device is configured to transmit the vehicle data to the network service.

21. The network service, receiving a request for issuance of an instruction to the vehicle using the pseudonymous identifier; processing the request for vehicle instructions by identifying a suitable pseudonymous identifier associated with a selection criterion, where the selection criterion is associated with a threshold value of a vehicle attribute, and where the vehicle instructions associated with the suitable pseudonymous identifier are written vehicle instructions; 20. The computer-implemented method of claim 16 configured to provide the written vehicle instructions to the individual vehicles.

Images