Scheduling system and method for distributed and unreliable electric vehicle nodes for computational workloads

Abstract

Methods, computing systems, and techniques for scheduling computing tasks performed by untrusted devices are presented. For example, a task management system can receive vehicle data from a first electric vehicle, including the computing capabilities of the first electric vehicle and its availability calendar. Additionally, the system can generate a work package for the first electric vehicle based on its computing capabilities. The work package may include computing tasks that the first electric vehicle will complete. Furthermore, the system can determine one or more transmission parameters for communicating the work package to the first electric vehicle based on the availability calendar. Based on the transmission parameters, the system can then send a request for the first electric vehicle to perform the computing tasks in the work package.

Description

Technical Field

[0001] The present disclosure generally relates to using a distributed untrusted (low reliability) computing system as a node for general computing tasks. In particular, the present disclosure relates to predicting the availability of modern vehicles for executing computing tasks and allocating vehicles for executing computing tasks using a centralized management system.

Background Art

[0002] A work task management system for a distributed network of node agents is a system designed to manage tasks and allocate them to a network of node agents. A node agent refers to an individual computer or device that is part of a distributed network.

[0003] The work task management system can break down large-scale tasks or projects into smaller, more manageable subtasks and distribute them among the node agents in the network. The work task management system can also track the progress of each task and ensure that they are completed within the specified period.

[0004] Some examples of tasks that can be managed by a work task management system for a distributed network of node agents include data processing, scientific simulations, or complex computing tasks that require significant computing power.

[0005] To mitigate climate change, improved technologies related to work task management systems can reduce greenhouse gas emissions, reduce energy consumption, reduce the production of additional servers, and reduce the environmental impact associated with the mining of critical minerals.

Summary of the Invention

[0006] Aspects and advantages of the embodiments of this disclosure are partially described in the following description, or can be learned from the description, or can be learned through the implementation of the embodiments.

[0007] One exemplary aspect of this disclosure relates to a computerized implementation. The computerized implementation may include receiving vehicle data from a first electric vehicle, including the computing capacity of the first electric vehicle and an availability calendar for the first electric vehicle. The computing capacity of the first electric vehicle may be determined on the first electric vehicle based on a performance analysis of one or more computing resources installed on the first electric vehicle. The availability calendar for the first electric vehicle may be determined on the vehicle, and the availability calendar indicates the expected network connectivity of the first electric vehicle. The computerized implementation may include generating a work package for the first electric vehicle based on the computing capacity of the first electric vehicle. The work package may include computing tasks that the first electric vehicle will complete using at least a portion of the computing resources installed on the first electric vehicle. The computerized implementation may include determining one or more transmission parameters for communicating the work package to the first electric vehicle based on the availability calendar, the transmission parameters including a time for transmitting the work package to the first electric vehicle. The computer implementation method may include, based on transmission parameters, sending a request for the first electric vehicle to perform a computing task of a work package.

[0008] In one embodiment, the method may include generating an electronic reward for a user of a first electric vehicle based on the completion of a computing task and contribution to the reduction of greenhouse gas emissions.

[0009] In one embodiment, the requirements may include the location of the cryptographic signature and the work package.

[0010] In one embodiment, the work package may be stored in work package storage. Additionally, the work package storage may include computational instructions and data for performing computing tasks.

[0011] In one embodiment, the method may include receiving confirmation from a work verifier that a computing task has been performed. Additionally, the method may include generating a smart contract associated with the work package, the smart contract including a cryptographic signature and code indicating an indication by the first electric vehicle that the first electric vehicle has performed a computing task.

[0012] In one embodiment, the method may include sending a smart contract to a blockchain interface. The blockchain interface maintains the execution status of a computing task.

[0013] In one embodiment, the method may include determining that a computing task was not performed by the first electric vehicle within a predetermined time. Additionally, the method may include assigning a work package to be performed by the second electric vehicle based on the determination that the computing task was not performed by the first electric vehicle within a predetermined time.

[0014] In one embodiment, the method may include registering a first electric vehicle as a node agent in the agent inventory. The agent inventory may have a list of node agents. Additionally, each node agent in the list of node agents may include an associated availability calendar.

[0015] In one embodiment, the availability calendar can be determined by the first electric vehicle using one or more machine learning models based on the network connectivity vectors and computation mode availability calendar of the first electric vehicle. Additionally, the availability calendar may be further determined based on user-specific data processed only on the vehicle.

[0016] In one embodiment, the availability calendar may include multiple locations, and the network connection vector of the first electric vehicle may indicate the network connection of the first electric vehicle at each of the multiple locations.

[0017] In one embodiment, the network connectivity vector of the first electric vehicle may be determined by performing a network connectivity speed test with the first electric vehicle.

[0018] In one embodiment, a work package may specify at least one of the following: minimum computing resource requirements, completion date, and effort level required to execute the work package.

[0019] In one embodiment, the availability calendar may be a quantized calendar that predicts the current state and future operating state of the first electric vehicle.

[0020] In one embodiment, the operating state of the first electric vehicle may be off, downloading, or calculating.

[0021] In one embodiment, the computing task may be performed by the first electric vehicle only during the computing state.

[0022] In one embodiment, the first electric vehicle may be restricted from performing computing tasks while in a download state.

[0023] In one embodiment, the availability calendar may include a network availability calendar that determines when a vehicle is able to transmit data over the network.

[0024] In one embodiment, the availability calendar may include a compute mode availability calendar that determines specific times and durations during which a vehicle is available to perform computing tasks for a work package.

[0025] Another exemplary aspect of this disclosure relates to a computing system including a control circuit of a task management system. The control circuit may be configured to receive vehicle data having the computing capabilities of a first electric vehicle and an availability calendar for the first electric vehicle from a first electric vehicle. The computing capabilities of the first electric vehicle may be determined on the vehicle based on a performance analysis of one or more computing resources installed in the first electric vehicle. The availability calendar for the first electric vehicle may be determined on the vehicle and indicates the expected network connectivity of the first electric vehicle. The control circuit may be configured to generate a work package for the first electric vehicle based on the computing capabilities of the first electric vehicle. The work package may include computing tasks that the first electric vehicle will complete using at least a portion of the computing resources installed in the first electric vehicle. The control circuit may be configured to determine one or more transmission parameters for communicating the work package to the first electric vehicle based on the availability calendar, the transmission parameters including a time for transmitting the work package to the first electric vehicle. The control circuit may be configured to send a request for the first electric vehicle to perform a computing task of the work package based on the transmission parameters.

[0026] Yet another exemplary aspect of the present disclosure relates to one or more non - transitory computer - readable media storing instructions, which are executable by a control circuit to perform operations. The control circuit can receive vehicle data having the computing capabilities of a first electric vehicle and the availability calendar of the first electric vehicle from the first electric vehicle. The computing capabilities of the first electric vehicle can be determined on the first electric vehicle based on a performance analysis of one or more computing resources mounted on the first electric vehicle. The availability calendar of the first electric vehicle may be determined on the vehicle, and the availability calendar indicates the predicted network connectivity of the first electric vehicle. The control circuit may generate a work package for the first electric vehicle based on the computing capabilities of the first electric vehicle. The work package may include computing tasks that the first electric vehicle completes using at least a portion of the computing resources mounted on the first electric vehicle. The control circuit can determine one or more transmission parameters for communicating the work package to the first electric vehicle based on the availability calendar. The transmission parameters may include the time to transmit the work package to the first electric vehicle. The control circuit may transmit a request for the first electric vehicle to execute the computing tasks of the work package based on the transmission parameters.

[0027] These and other features, aspects, and advantages of the various embodiments of the present disclosure will be better understood with reference to the following description and the appended claims. The accompanying drawings, which are incorporated herein and constitute a part of this specification, illustrate exemplary embodiments of the specification and, together with the description, serve to explain the relevant principles.

Brief Description of the Drawings

[0028] A detailed description of embodiments directed to those skilled in the art is set forth in the specification with reference to the accompanying drawings. [Figure 1] A block diagram of an exemplary computing ecosystem according to an exemplary embodiment of the present invention is shown. [Figure 2]Shows a high-level diagram of an ecosystem example according to an embodiment of the present invention. [Figure 3] Shows a block diagram of the computing components of the CCMS and each node agent according to an exemplary embodiment of the present invention. [Figure 4] Shows a flowchart diagram of exemplary computational mode communication between a host system, a node agent, and a centralized computing management system according to an exemplary embodiment of the present specification. [Figure 5] Shows a block diagram of an exemplary centralized computing management system that interacts with multiple node agents and a blockchain interface according to an exemplary embodiment of the present specification. [Figure 6] Shows a flowchart diagram of a centralized computing management system that assigns tasks to node agents according to an exemplary embodiment of the present specification. [Figure 7] Shows a flowchart diagram of an exemplary method for a centralized computing management system to allocate computing tasks according to an exemplary embodiment of the present specification. [Figure 8] Shows a flowchart diagram of an exemplary method for a node agent to determine its availability and capabilities for executing a computing task according to an exemplary embodiment of the present specification. [Figure 9] Shows a block diagram of a computing system according to an exemplary embodiment of the present invention.

Mode for Carrying Out the Invention

[0029] Overview One aspect of this disclosure relates to a method and computing system for utilizing untrusted, distributed Internet of Things (IoT) devices as compute nodes for individual computing tasks. In some cases, IoT devices may have unpredictable availability of computing resources for performing computing tasks. The ecosystem described herein may include a plurality of IoT devices having distributed client applications, sometimes also referred to as node agents, and a centralized computing management system (CCMS).

[0030] Cloud computing enables centralized computing management of node agents, while the increasing number of IoT devices in the modern computing landscape can potentially be utilized as node agents to make computing capabilities available as part of edge computing infrastructure. According to some embodiments of the present invention, the technology described herein enables the use of modern vehicle battery-powered vehicles equipped with hardware capable of autonomous driving and continuous power supply as node agents to perform computing tasks for work packages.

[0031] Modern vehicles can be equipped with high-performance general-purpose computing hardware such as central processing units (CPUs) and graphics processing units (GPUs), as well as specialized hardware such as machine learning accelerators. However, in the past, traditional systems have not partially used modern vehicles as node agents because they were unreliable and unpredictable in terms of having the computing resources available to perform computing tasks assigned by the CCMS. For example, while a vehicle is being driven, its computing resources are used to handle tasks associated with driving the vehicle.

[0032] Recent research indicates that the utilization of computing resources in modern vehicles may be less than 10% of the day on average. For example, a vehicle may be driven for less than 3 hours a day on average. Therefore, if the availability of computing resources for non-driving purposes can be accurately predicted, the computing resources in a modern vehicle may be available for most of the day (e.g., when the vehicle is not being driven) to perform computing tasks assigned by the CCMS.

[0033] Additionally, a vehicle's internet connectivity may vary and, in some cases, may be unavailable. By using the machine learning techniques described herein, the system can accurately predict the vehicle's computing mode availability and network availability so that the vehicle can become a trusted node agent for performing computing tasks. For example, computing mode availability may include periods when the vehicle's computing resources are available for non-driving purposes, such as when a battery-powered electric vehicle is connected to a permanent power source for continuous charging (e.g., charging overnight). Network availability may include periods when the vehicle's internet connectivity is reliable so that the vehicle can download work packages to perform computing tasks for those work packages.

[0034] Machine learning models can be stored in the in-vehicle computing system. Additionally, with user permission, machine learning models can be trained using user-specific data to accurately predict both the vehicle's computing mode availability and network availability. Computing mode availability can indicate, based on user-specific data, when a particular user's vehicle may be available to perform computing tasks assigned by the CCMS. Network availability can indicate, based on user-specific data, when a particular user's vehicle may have a reliable wireless or wired network connection for downloading and uploading data (e.g., work packages). By maintaining and processing user-specific data using the in-vehicle computing system (rather than external systems), the system protects user privacy.

[0035] The availability of a compute mode can be determined by a machine learning model using the vehicle's onboard computing system, based on user-specific data. For example, the machine learning model can determine multiple time periods that have a high probability (e.g., 90% confidence level, 95% confidence level) of the vehicle not being driven, based on user-specific data. The predictive patterns of compute mode availability can be stored in a data structure, such as a compute mode availability calendar.

[0036] Additionally, network availability can be determined by a machine learning model using the vehicle's in-vehicle computing system, based on user-specific data. For example, the machine learning model can determine multiple time periods, based on user-specific data, that have a high probability (e.g., 90% confidence level, 95% confidence level) of the vehicle having a reliable network connection. Predicted patterns of network availability can be stored in a data structure, such as a network availability calendar.

[0037] Each vehicle can be registered with the CCMS and identified in the node inventory, which stores a list of registered node agents (e.g., vehicles). Vehicles can submit a compute mode availability calendar and a network availability calendar to the CCMS. The CCMS can then assign work packages to node agents in the node agent inventory based on the node agents' compute mode availability calendars and network availability calendars. As further described herein, the CCMS can send requests to the assigned node agents to perform computing tasks associated with the work packages.

[0038] Subsequently, the node agent can download the work package from the work package storage and execute the computing tasks associated with the work package. Once the node agent completes the computing tasks associated with the work package, it can notify the CCMS that the tasks have been completed. The CCMS can use a work package verifier to verify whether the work package has been successfully completed. In some cases, the node agent may receive a reward upon successful completion of the work package. The CCMS can generate the reward by initiating a smart contract using a blockchain interface. In other embodiments, the CCMS can interface with a non-blockchain interface that enables the generation of contracts related to rewards for executing computing tasks.

[0039] While some of the technologies described herein focus on utilizing modern vehicles as host systems, these technologies can be implemented by any IoT device acting as a host system. Node agents, which may be installed in the host system, may also be separate components within the system. IoT devices can be physical devices connected to a network that can communicate with other devices, collect data, exchange data, and perform various functions without requiring human intervention. These devices can range from simple sensors that measure temperature or humidity to more complex devices such as home automation systems, smart appliances, industrial machinery, and modern vehicles. IoT devices can exchange data with other devices or centralized systems (e.g., CCMS) for monitoring and control.

[0040] Illustrative aspects of this disclosure provide several technical effects and benefits. As an example, this disclosure facilitates improvements in computing technology by improving the reliability of IoT devices, such as modern vehicles, as node agents for performing computing tasks. By enabling computing resources that were previously unused (e.g., due to unreliability and unpredictability) to be used as node agents, the availability of computing resources for performing computing tasks is increased, which can result in faster processing times for performing large-scale tasks and projects.

[0041] The technologies of this disclosure are related to transportation and help mitigate climate change in the environment. For example, the technologies described herein can determine customized computing instructions and timeframes for each of several electric vehicles and utilize each electric vehicle to complete computing tasks during times when it does not affect vehicle operation (e.g., while the vehicle is charging). This minimizes the energy use of computing, information, and communication technologies in electric vehicles (and other systems) while such equipment is operating (e.g., while driving). The technologies of this disclosure also help reduce greenhouse gas emissions. For example, the systems and methods of this disclosure promote the use of electric vehicles. As described herein, users of electric vehicles that utilize the vehicle as a computing node can be rewarded for completing tasks and for using the electric vehicle. The rewards can also reflect the vehicle's contribution to reducing greenhouse gas emissions based on its use, downtime calculations, etc. Such technologies can promote the adoption of electric vehicles, leading to an overall reduction in greenhouse gas emissions from automobiles or other types of transportation. Additionally, the technologies described herein reduce energy consumption for performing computing tasks by utilizing on-board computing systems within electric vehicles. On-board computing systems are more efficient at performing computing tasks and require less energy to perform them compared to legacy and older computing systems that consume more energy to perform computing tasks. By reducing energy consumption for performing these computing tasks, the technologies described herein reduce the amount of energy that needs to be generated by power plants, thereby reducing greenhouse gas emissions. Furthermore, by optimizing the use of electric vehicles (for example, by using computing resources when the vehicle is not being driven to process computing tasks), the global need to build additional servers to process computing tasks is reduced.By reducing the global need to build additional servers, this system can reduce the global demand for critical resources (e.g., rare earth elements, critical minerals) and mitigate the environmental impact of mining these critical resources. Furthermore, considering that the CCMS system utilizes hardware capabilities when determining which node agent to assign tasks to, the system enables more efficient task allocation (for example, vehicles with high-end GPUs and low-end CPUs can be assigned tasks better suited to GPU processing rather than tasks better suited to CPU processing). The system can also calculate per-watt calculations to reduce energy consumption by selecting the most energy-efficient option. For example, vehicles can provide the CCMS system with performance statistics including energy efficiency data, and the CCMS system can assign node agents based on that energy efficiency data.

[0042] The technology disclosed herein improves the reliability of IoT devices by leveraging the predicted computing power (and network connectivity) of various node agents to select node agents that are more likely to be able to complete (and available for) assigned tasks. This technology also enables the CCMS to transmit assigned computing tasks to selected node agents during periods of higher network speed and quality, avoiding costly computational latency. Thus, the computing technology described herein can avoid wasting computing resources on rework when selecting and assigning node agents due to incomplete task assignments.

[0043] Additionally, the technologies described herein protect user privacy by protecting user-specific data, which includes mechanisms to prevent centralized management systems from accessing user-specific data. For example, the technologies described herein include in-vehicle processing and removal of user-specific information to avoid transmission of user data to the CCMS. Thus, node agents (e.g., vehicles) can be used as secure agents while limiting expensive and computationally complex encryption software on the CCMS.

[0044] The technology of this disclosure can improve the efficiency of computing resources in a CCMS. For example, by calibrating the computing tasks assigned to a particular vehicle based on the expected on-board computing capacity of the vehicle, the CCMS can assign individual computing tasks that can be completed by a single vehicle. Thus, the CCMS can avoid using computationally expensive algorithms to divide computing tasks into subtasks and assign them to multiple different node agents for execution. Furthermore, the CCMS can avoid complex algorithms to aggregate completed subtasks to obtain a holistic computation result. This allows the CCMS to utilize its resources for its core responsibilities, such as improving node agent allocation and thorough verification.

[0045] Exemplary System The exemplary embodiments of this specification will now be described in more detail with reference to the drawings. It should be noted that the examples provided herein describing specific functions performed by a particular system are provided for illustrative purposes only and are not intended to limit the scope of such functions. For example, an action described as being performed by a preceding vehicle (or following vehicle) may be performed by another computing system (e.g., a cloud-based platform system), or vice versa.

[0046] Figure 1 shows an exemplary computing ecosystem 100 according to one embodiment of this specification. The ecosystem 100 may include a vehicle 105, a remote computing platform 110 (also referred to herein as the computing platform 110), and a user device 115 associated with a user 165. The user 165 may be the driver of the vehicle. In one embodiment, the user 165 may be a passenger in the vehicle. The vehicle 105, the computing platform 110, and the user device 115 may be configured to communicate with each other via one or more networks 125.

[0047] Systems / devices in ecosystem 100 may communicate using one or more application programming interfaces (APIs). This may include external APIs for communicating data from one system / device to another. External APIs may enable systems / devices to establish secure communication channels via secure access channels on network 125 through any number of methods, such as web-based forms, programmatic access via RESTful APIs, Simple Object Access Protocol (SOAP), Remote Procedure Calls (RPC), and scripting access.

[0048] The computing platform 110 may include a computing system located remotely from the vehicle 105. In one embodiment, the computing platform 110 may include a cloud-based server system. The computing platform 110 may include one or more backend services to support the vehicle 105. These services may include, for example, a centralized computing management system (CCMS) 112, teleassist services, navigation / routing services, and performance monitoring services. The computing platform 110 may host or otherwise include one or more APIs for communicating data with the vehicle's onboard computing system 130 or user device 115.

[0049] The computing platform 110 may include one or more computing devices. For example, the computing platform 110 may include a control circuit 185 and a non-temporary computer-readable medium 190 (e.g., memory). The control circuit 185 of the computing platform 110 may be configured to perform various operations and functions described herein. In one embodiment, the control circuit 185 may include one or more processors (e.g., microprocessors), one or more processing cores, a programmable logic circuit (PLC) or programmable logic / gate array (PLA / PGA), a field-programmable gate array (FPGA), an application-specific integrated circuit (ASIC), or any other control circuit. In one embodiment, the control circuit 185 may be programmed by one or more computer-readable or computer-executable instructions stored in the non-temporary computer-readable medium 190.

[0050] In one embodiment, the non-temporary computer-readable medium 190 may be a memory device, also called a data storage device, which may include an electronic storage device, a magnetic storage device, an optical storage device, an electromagnetic storage device, a semiconductor storage device, or any suitable combination thereof. The non-temporary computer-readable medium 190 can form, for example, a hard disk drive (HDD), a solid-state drive (SDD) or solid-state integrated memory, random access memory (RAM), read-only memory (ROM), erasable programmable read-only memory (EPROM or flash memory), static random access memory (SRAM), dynamic random access memory (DRAM), portable compact disc read-only memory (CD-ROM), digital multipurpose disc (DVD), or memory stick. In some cases, the non-temporary computer-readable medium 190 can store computer-executable instructions or computer-readable instructions, such as instructions for performing the operations and methods described herein.

[0051] The non-temporary computer-readable medium 190 can store information that can be accessed by the control circuit 185. For example, the non-temporary computer-readable medium 190 (e.g., one or more non-temporary computer-readable storage media, memory devices) can store data that can be acquired, received, accessed, written, manipulated, created, or stored. The data may include, for example, but is not limited to, data acquired from the in-vehicle computing system 130, such as vehicle data 118.

[0052] Vehicle data may include vehicle location data 120, vehicle route data 122, vehicle charging data 124, network availability calendar 126, computation mode availability calendar 128, and computing power data 129. The data may further include, but is not limited to, data received from other databases, such as work package data 131, map data 132, work package validation data 133, or charging station data 134. In one embodiment, the computing platform 110 may acquire data from one or more memory devices located away from the computing platform 110. Computing power data 129 may include data based on each host system or node agent that performs a self-assessment of its computing power by running standardized performance benchmarks on available hardware (e.g., GPU, CPU, ML accelerator).

[0053] In various embodiments, the terms “computer-readable instructions” and “computer-executable instructions” are used to describe software instructions or computer code configured to perform various tasks and operations. In various embodiments, where computer-readable or computer-executable instructions form a module, the term “module” broadly refers to a set of software instructions or code configured to cause the control circuit 185 to perform one or more functional tasks. Modules and computer-readable / executable instructions may be described as performing various operations or tasks when the control circuit or other hardware components are executing the module or computer-readable instructions.

[0054] The user device 115 may be a computing device owned by or otherwise accessible by the user 165, or may otherwise include it. For example, the user device 115 may be a telephone, laptop, tablet, wearable device (e.g., smartwatch, smart glasses, headphones), personal digital assistant, game system, personal desktop device, other handheld device, or other type of mobile or non-mobile user device, or may otherwise include them. As further described herein, the user device 115 may include one or more input components such as buttons, touchscreens, joysticks or other cursor controls, styluses, microphones, cameras or other imaging devices, motion sensors, the user device 115 may include one or more output components such as display devices (e.g., display screens), speakers, etc. In one embodiment, the user device 115 may include components such as a touchscreen, configured to perform input and output functions for receiving user input and presenting information for the user 165. The user device 115 may execute one or more instructions for running an instance of a software application and presenting the user interface associated therewith. The launch of the software application for each transportation platform may initiate a user network session with the computing platform 110.

[0055] Network 125 may be any type of network or combination of networks that enables communication between devices. In one embodiment, network 125 may include one or more of the following: a local area network, a wide area network, the Internet, a secure network, a cellular network, a mesh network, a peer-to-peer communication link, or any combination thereof, and may include any number of wired or wireless links. Communication over network 125 may be achieved via the network interface using, for example, any type of protocol, protection scheme, encoding, format, packaging, etc. Communication between the vehicle's onboard computing system 130 and the user device 115 may be facilitated by short-range or near-field communication technologies (e.g., Bluetooth® Low Energy Protocol, radio frequency signaling, NFC protocol).

[0056] Vehicle 105 may be a vehicle that can be operated by user 165. In one embodiment, vehicle 105 may be a car or another type of ground vehicle that is manually driven by user 165. For example, vehicle 105 may be a Mercedes-Benz® car or a van. In one embodiment, vehicle 105 may be an aircraft (e.g., a personal airplane) or a water vehicle (e.g., a boat). Vehicle 105 may include operator assistance functions such as cruise control and advanced driver assistance systems. In one embodiment, vehicle 105 may be a fully autonomous vehicle or a semi-autonomous vehicle.

[0057] Vehicle 105 may include a powertrain and one or more power sources. The powertrain may include motors, e-motors, transmissions, drive shafts, axles, differentials, e-components, gears, etc. The power sources may include one or more types of power sources. For example, vehicle 105 may be a fully electric vehicle (EV) that can use an electric battery to operate the vehicle 105's powertrain (e.g., for propulsion) and onboard functions of the vehicle. In one embodiment, vehicle 105 may include a hybrid power source, for example, a combination of flammable fuel and electricity.

[0058] For the sake of brevity, specific routines and conventional components of vehicle 105 (e.g., the engine) are not illustrated or described herein. Those skilled in the art will understand the operation of conventional vehicle components within vehicle 105.

[0059] Vehicle 105 may include an on-board computing system 130 mounted on vehicle 105. The on-board computing system 130 may be mounted on vehicle 102, in that it is located on or within vehicle 105. The on-board computing system 130 may include one or more computing devices that may include various computing hardware components. For example, the on-board computing system 130 may include a control circuit 135 and a non-temporary computer-readable medium 140 (e.g., memory). The control circuit 135 may be configured to perform various operations and functions for carrying out the technology described herein.

[0060] In one embodiment, the control circuit 135 may include one or more processors (e.g., microprocessors), one or more processing cores, a programmable logic circuit (PLC) or programmable logic / gate array (PLA / PGA), a field-programmable gate array (FPGA), an application-specific integrated circuit (ASIC), or any other control circuit. In one embodiment, the control circuit 135 or the in-vehicle computing system 130 may be part of, or form part of, a vehicle control unit (also referred to as a vehicle controller) embedded in or otherwise positioned in a vehicle 105 (e.g., a Mercedes-Benz® car or van). For example, the vehicle controller may be, or include, an infotainment system controller (e.g., an infotainment head unit), a telematics control unit (TCU), an electronic control unit (ECU), a central powertrain controller (CPC), a charge controller, a central external and internal controller (CEIC), a zone controller, or any other controller (the terms "or" and "and" may be used interchangeably herein).

[0061] In one embodiment, the control circuit 135 may be programmed by one or more computer-readable or computer-executable instructions stored in a non-temporary computer-readable medium 140.

[0062] In one embodiment, the non-temporary computer-readable medium 140 may be a memory device, also called a data storage device, which may include an electronic storage device, a magnetic storage device, an optical storage device, an electromagnetic storage device, a semiconductor storage device, or any suitable combination thereof. The non-temporary computer-readable medium 140 can form, for example, a hard disk drive (HDD), a solid-state drive (SDD) or solid-state integrated memory, random access memory (RAM), read-only memory (ROM), erasable programmable read-only memory (EPROM or flash memory), static random access memory (SRAM), dynamic random access memory (DRAM), portable compact disc read-only memory (CD-ROM), digital versatile disc (DVD), or memory stick. In some cases, the non-temporary computer-readable medium 140 can store computer-executable instructions or computer-readable instructions, such as instructions for performing the methods shown in Figures 7 and 8. Additionally or alternatively, similar such instructions may be stored on a computing platform 110 (e.g., non-temporary computer-readable medium 190) and provided via a network 125.

[0063] In one embodiment, the non-temporary computer-readable medium 140 may store vehicle data 118 describing the characteristics of the vehicle 105, such as manufacturer, model, year, serial number, software / firmware version, or characteristics of other vehicles. In one embodiment, the vehicle data 118 stored in the non-temporary computer-readable medium 140 may also include vehicle location data 120, vehicle route data 122, vehicle charge data 124, network availability calendar 126, computation availability calendar 128, and computing capacity data 129. For example, the vehicle data 118 may include at least some location data that maintains operator privacy by focusing on passive location data as opposed to active motion tracking. In one embodiment, the vehicle data 118 may include basic vehicle identifier information such as vehicle type, vehicle size, vehicle class, vehicle battery type, and corresponding range data, or other identification of functional information associated with one or more vehicles 105. As another example, the vehicle data 118 may include vehicle location data 120 indicating the location of a parked or operating vehicle 105. The in-vehicle computing system 130 may be configured to perform some or all of the operations for collecting or determining vehicle data 118. In yet another example, the vehicle data 118 may include a network availability calendar 126 determined on the vehicle 105. The network availability calendar 126 may indicate the expected network connectivity of the vehicle, as further described herein.

[0064] As yet another example, vehicle data 118 may include a compute mode availability calendar 128 determined on vehicle 105. The compute mode availability calendar 128 may indicate a forecast period during which the vehicle is available to process computing tasks of a work package (e.g., non-driving computing tasks), as further described herein. As yet another example, vehicle data 118 may include compute capability data 129, which may include data associated with the compute capability of an on-board computing system 130. The compute capability data 129 may be determined on vehicle 105 based on a performance analysis of one or more computing resources installed in the vehicle. In one example, compute capability may indicate the overall computing resources of vehicle 105 (e.g., processing, memory, bandwidth). In some embodiments, compute capability may indicate the computing resources of vehicle 105 that may be available or could be utilized during a particular timeframe. This may include, for example, indicating that a certain percentage of vehicle 105's GPU or other processing resources are available within a particular timeframe.

[0065] The vehicle location data 120 stored in the non-temporary computer-readable medium 140 may be partially determined from sensor outputs associated with the sensor 150 and / or positioning system 155. For example, the vehicle location data 120 may indicate the coordinates, waypoints, semantic position, etc., of the vehicle 105. This type of information may be based on signals such as GPS signals. In some implementations, the vehicle location data 120 may include positioning data that includes the position of the vehicle 105 in the current environment within 6 degrees of freedom.

[0066] The vehicle data 118 may additionally or alternatively include vehicle route data 122 that describes multiple travel events associated with the vehicle 105. The vehicle route data 122 may indicate the origin and destination for each of the multiple travel events. A travel event may include a route from the origin to the destination. A travel event may be associated with a user 165 that enters a route request into the vehicle 105's navigation system.

[0067] In some cases, the vehicle route data 122 may provide one or more measures associated with travel events. In one embodiment, the vehicle route data may include the frequency or number of times that multiple travel events involve travel between their respective origins and respective destinations. The vehicle route data 122 stored in the non-temporary computer-readable medium 140 may be determined from the positioning system 155, similar to the vehicle location data 120. Furthermore, the vehicle route data 122 may also be obtained from one or more navigation systems installed in the vehicle 105. In one embodiment, the in-vehicle computing system 130 or computing platform 110 can process the vehicle location data 120 or other vehicle data 118 to determine the vehicle route data 122, which includes travel events and their associated origins and destinations.

[0068] Vehicle data 118 may additionally or alternatively include vehicle charging data 124. For example, vehicle charging data 124 may indicate charging events associated with one or more vehicles 105. Vehicle charging data 124 may include the current or future predicted charging state of vehicle 105. In some cases, vehicle charging data 124 can be correlated with vehicle location data 120. For example, vehicle charging data 124 may include the user's home location, which may be the vehicle's location at night. Vehicle charging data 124 may additionally or alternatively include vehicle range data related to the battery range of one or more vehicles 105.

[0069] The vehicle charging data 124 stored in the non-temporary computer-readable medium 140 may be predetermined or determined, at least in part, by communication between the in-vehicle computing system 130 and one or more batteries located within the vehicle 105. In this way, the in-vehicle computing system 130 can periodically monitor each electric battery to determine the total charge capacity, the current battery charge level, the estimated remaining time until recharging is required, or other real-time vehicle charging data parameters related to a particular vehicle 105. The vehicle charging data 124 may additionally or alternatively include data related to past or present charging activity. For example, the vehicle charging data may include a timestamp indicating when charging occurred, location data indicating where charging occurred, charge rate data indicating how quickly charging occurred, and a charging metric (for example, for determining frequency, ranking, or charging activity data) that cumulatively combines one or more of these aspects.

[0070] In one embodiment, the in-vehicle computing system 130 processes vehicle data 118, including vehicle location data 120, vehicle route data 122, vehicle charging data 124, network availability calendar 126, or computation mode availability calendar 128, to remove private information, but not limited to, active movement of vehicle 105 when not authorized by the vehicle operator. Personal information may include user-specific data, such as personally identifiable information. For example, user-specific data may include the vehicle's current location information, the vehicle's previous location information, route information from origin to destination, personal calendar information, work calendar information, travel information, and information that can enable user identification. The in-vehicle computing system 130 can directly and additionally process vehicle data 118, including vehicle location data 120, vehicle route data 122, vehicle charging data 124, network availability calendar 126, or calculation mode availability calendar 128, within the vehicle 105 to determine an availability calendar(s) to prevent any personal information (e.g., vehicle owner, vehicle operator, active location) from being transmitted from the vehicle 105 or used in any meaningful way, whether encrypted or otherwise. Thus, the vehicle 105 can protect the privacy of its occupants and those around them.

[0071] To remove personal information, the in-vehicle computing system 130 may utilize one or more data scrubbing or data cleansing techniques. These techniques may be applied to identify, remove, delete, or normalize specific data. The in-vehicle computing system may utilize encryption techniques and other methods to securely store user-specific data or other personal information on the vehicle 105, provided that permission for such storage / data collection is given by the relevant user. The process used to scrub any private information may include the use of algorithms and software configured to identify certain types of information to be removed from the data (e.g., the driver's name), delete such information from the data, and prepare it for transmission. In this way, the data analyzed and created on the computing system 130 may be anonymized locally (e.g., on the vehicle 105) before being transmitted to any system outside the vehicle 105 (e.g., computing platform 110, CCMS 112).

[0072] An in-vehicle computing system 130 (e.g., a control circuit 135) may be configured to communicate with other components of the vehicle 105 via a communication channel. The communication channel may include one or more data buses (e.g., a Controller Area Network (CAN)), an in-vehicle diagnostic connector (e.g., OBD-II), or a combination of wired or wireless links. The in-vehicle systems can transmit or receive data, messages, signals, etc., between each other via the communication channel.

[0073] In one embodiment, the communication channel may include direct connections such as those provided via a dedicated wired communication interface, such as an RS-232 interface or a Universal Serial Bus (USB) interface, or via a local computer bus, such as a Peripheral Component Interconnection (PCI) bus. In one embodiment, the communication channel may be provided via a network. The network may be any type or form of network, such as a personal area network (PAN), local area network (LAN), e.g., an intranet, metropolitan area network (MAN), wide area network (WAN), or the internet. The network may utilize different technologies and protocol layers or stacks, including, for example, the Ethernet protocol, Internet Protocol Suite (TCP / IP), ATM (Asynchronous Transfer Mode) technology, SONET (Synchronous Optical Networking) protocol, or SDH (Synchronous Digital Hierarchy) protocol.

[0074] In one embodiment, the systems / devices of the vehicle 105 may communicate via an intermediate storage device, or more generally, an intermediate non-temporary computer-readable medium. For example, a non-temporary computer-readable medium 140, which may be outside the in-vehicle computing system 130, can function as an external buffer or repository for storing information. In such an example, the in-vehicle computing system 130 may retrieve or otherwise receive information from the non-temporary computer-readable medium 140.

[0075] The vehicle 105 may include one or more human-machine interfaces (HMIs) 145. The human-machine interfaces 145 may include display devices as described herein. The display devices (e.g., touchscreens) may be visible to users of the vehicle 105 located in the front of the vehicle 105 (e.g., the driver's seat, the passenger seat) (e.g., user 165, a second user 175). Additionally or alternatively, a display device (e.g., a rear unit) may be visible to users located in the rear of the vehicle 105 (e.g., the rear passenger seats).

[0076] Vehicle 105 may include one or more sensors 150. Sensors 150 may be configured to acquire sensor data. This may include sensor data associated with the surrounding environment of vehicle 105, sensor data associated with the interior of vehicle 105, or sensor data associated with a specific vehicle function. Sensor data may indicate conditions observed inside, outside, or in the surrounding environment of the vehicle. For example, sensor data may acquire image data, internal / external temperature data, weather data, data indicating the location of a user / object inside vehicle 105, weight data, motion / gesture data, audio data, or other types of data. Sensors 150 may include one or more of the following: cameras (e.g., visible spectrum cameras, infrared cameras), motion sensors, audio sensors (e.g., microphones), weight sensors (e.g., vehicle seats), temperature sensors, humidity sensors, light detection and ranging (LIDAR) systems, radio wave detection and ranging (RADAR) systems, or other types of sensors. Vehicle 105 may also include other sensors configured to acquire data associated with vehicle 105. For example, the vehicle 105 may include an inertial measurement unit, a wheel odometry device, or other sensors. The vehicle data 118 may include data derived from the sensor 150.

[0077] Vehicle 105 may include a positioning system 155. The positioning system 155 may be configured to generate position data (also called location data) indicating the location of vehicle 105. For example, the positioning system 155 may determine the position based on an IP address using one or more inertial sensors (e.g., inertial measurement units), satellite positioning systems, or by using proximity to a network access point or other network component (e.g., a cellular tower, a Wi-Fi access point), or other appropriate techniques. The positioning system 155 may determine the current location of vehicle 105. The position may be expressed as a set of coordinates (e.g., latitude, longitude), an address, or a semantic location (e.g., "workplace"). Vehicle data 118 may include data derived from the positioning system 155.

[0078] In one embodiment, the positioning system 155 may be configured to locate the vehicle 105 within its environment. For example, the vehicle 105 may have access to map data (e.g., map data 132) that provides detailed information about the environment surrounding the vehicle 105. The map data may provide information about the identification and location of different roads, road divisions, buildings, or other items, the location and direction of lanes (e.g., the location and direction of parking lanes, turning lanes, bicycle lanes, or other lanes within a particular road), traffic control data (e.g., the location, timing, or instructions of signs (e.g., stop signs, yield signs), traffic lights (e.g., stop lights), or other traffic signals or control devices / markings (e.g., pedestrian crossings)), or any other data. Based on the map data, the positioning system 155 may locate the vehicle 105 within its environment (e.g., across multiple axes). For example, the positioning system 155 processes sensor data (e.g., LIDAR data, camera data, etc.) and matches it with a map of the surrounding environment to obtain an understanding of the vehicle's position within that environment. The determined position of the vehicle 105 can be used by various systems of the in-vehicle computing system 130 or provided to the computing platform 110.

[0079] The vehicle 105 may include a communication system 160 configured to enable the vehicle 105 (and its on-board computing system 130) to communicate with other computing devices. The on-board computing system 130 can use the communication system 160 to communicate with a computing platform 110 or one or more other remote computing devices via a network 125 (for example, via one or more radio signal connections). In one embodiment, the communication system 160 may enable communication between one or more systems mounted on the vehicle 105.

[0080] In one embodiment, the communication system 160 may be configured to enable the vehicle 105 to communicate with or otherwise receive data from the user device 115. The communication system 160 may utilize a variety of communication technologies, such as Bluetooth® Low Energy Protocol, radio frequency signaling, or other short-range or near-field communication technologies. The communication system 160 may include any suitable components for interfacing with one or more networks, such as a transmitter, receiver, port, controller, antenna, or other suitable components that may help facilitate communication.

[0081] Vehicle 105 may include multiple vehicle functions 165A to C that require the computing resources of vehicle 105. The computing mode availability calendar 128 can predict when the vehicle is not running multiple vehicle functions 165A to C so that the vehicle's computing resources are available to perform computing tasks requested by CCMS 112.

[0082] Vehicle functions 165A to 165C may be functions configured to be performed by the vehicle 105 based on detected inputs. Vehicle functions 165A to 165C may include one or more of the following: (i) vehicle comfort functions, (ii) vehicle staging functions, (iii) vehicle environment functions, (vi) vehicle navigation functions, (v) driving style functions, (v) vehicle parking functions, or (vi) vehicle entertainment functions. Vehicle navigation functions can control the vehicle's systems to provide a route to a specific destination. For example, vehicle 105 may include an onboard navigation system that provides user 165 with a route to travel to a destination. The navigation system may utilize map data and GPS-based signals to provide guidance to user 165 via a display device inside vehicle 105. Vehicle parking functions can control parking-related features of the vehicle. In one embodiment, vehicle parking functions may include a parking camera function that controls a side camera, a rear camera, or a 360-degree camera to assist user 165 when parking vehicle 105. Additionally or alternatively, the vehicle parking function may include a parking assist function to help maneuver the vehicle 105 into a parking area. The vehicle entertainment function may control one or more entertainment-related features of the vehicle 105. For example, the vehicle entertainment function may include a music function for controlling the radio or another source of audio or visual media. The vehicle entertainment function may control sound parameters (e.g., volume, bass, treble, speaker distribution) or select a radio station or media content type / source.

[0083] Each vehicle function may include controllers 170A to 170C associated with that particular vehicle function 165A to 165C. Controllers 170A to 170C for a particular vehicle function may include control circuits configured to operate the associated vehicle functions 165A to 165C. For example, a controller may include circuits configured to turn on a seat heating function, turn off a seat heating function, set a specific temperature or temperature level, etc.

[0084] The technology of this disclosure enables a vehicle 105 to predict when the resources of its in-vehicle computing system 130 may be available to perform computing tasks other than those necessary to operate the vehicle. Furthermore, the technology of this disclosure enables the vehicle to predict when it will connect to one or more networks 125 so that it can receive instructions from, for example, CCMS 112 to perform assigned computing tasks. As will be further described below, this allows the vehicle 105 to act as a node agent for CCMS 112 to enhance the reliability of the vehicle in completing assigned computing tasks while protecting user-specific data.

[0085] Figure 2 shows a high-level diagram of a computation ecosystem example 200 according to one embodiment of the present invention. The ecosystem 200 may include a first node agent 210, a second node agent 220, and a CCMS 112. The first node agent 210, the second node agent 220, and the CCMS 112 may be configured to communicate with each other via one or more networks 125.

[0086] In one example, as shown in Figure 2, the first node agent 210 may be a vehicle, and the second node agent 220 may be a vehicle. The representations of node agents 210 and 220 are not intended to be limiting, as other IoT devices may be used as node agents within the technology of this disclosure.

[0087] The first node agent 210 can transmit vehicle data (e.g., vehicle data 118) to the CCMS 112 via one or more networks 125. Additionally, the second node agent 220 can transmit vehicle data (e.g., vehicle data 118) to the CCMS 112 via one or more networks 125. The CCMS 112 can receive vehicle data from multiple node agents (e.g., the first node agent 210, the second node agent 220).

[0088] As further described herein with reference to Figures 4 and 5, the vehicle data 118 may include the computing power of each node agent and the availability calendar of each node agent. For example, the computing power of the first node agent 210 (e.g., computing power data 129) may be determined on a host system (e.g., a vehicle) (e.g., using an in-vehicle computing system 130) based on a performance analysis of one or more computing resources installed on the host system. The computing power may indicate the type of computing hardware included in the first node agent 210, the performance of the computing hardware (e.g., processing speed, latency), or other information regarding the computing resources of the first node agent 210.

[0089] The availability calendar may include a network availability calendar 126 and a compute-mode availability calendar 128 for the first node agent 210, which may be determined on a host system (e.g., a vehicle). As further described herein, the availability calendar can indicate the expected network connectivity of the host system, as well as when (and for how long) the computing power of the first node agent 210 may be available to perform computing tasks. For example, the availability calendar may include a network availability calendar 126 that determines when the vehicle can transmit data over the network. Furthermore, the availability calendar may include a compute-mode availability calendar 128 that determines the specific time and duration for which the vehicle is available to perform computing tasks on a workload task payload (e.g., taking its computing power into consideration).

[0090] In response to receiving vehicle data 118 from the first node agent 210, which enables the first node agent 210 to register with the CCMS 112, the CCMS 112 can generate a work package for the first node agent 210 based on the computing capabilities of the first node agent 210. The work package can be stored as work package data 131, as described in Figure 1. The work package may include computing tasks that the first node agent 210 (e.g., the first vehicle, the first electric vehicle) completes using at least some of the computing resources installed in the host system or the first node agent 210.

[0091] As further described herein with reference to Figures 5 and 6, a work package can represent a computing task specifically selected for the first node agent 210 (e.g., data deduplication, image data processing, mapping updates, model training, data reconstruction, etc.). The work package can represent computational instructions for executing the computing task using computing resources expected to be available on the first node agent 210. For example, as further described herein, a work package can be generated based on an availability calendar and the computing capabilities of the first node agent to help improve reliability, such as ensuring that the first node agent 210 becomes available and can complete the assigned computing task with a certain degree of precision within an expected timeframe. In one embodiment, the work package may include instructions for sending data related to completed tasks (e.g., notification instructions, upload instructions, etc.).

[0092] In some cases, instead of generating a work package, CCMS112 can generate a request to perform the computing tasks of a work package. For example, CCMS112 can generate a request that has the location of the work package (e.g., a reference or link to a computing storage resource that can access / search for the work package). CCMS112 can then send the request to a first node agent 210. The first node agent 210 can then download the work package based on the location received from the request.

[0093] Furthermore, the CCMS112 can determine one or more transmission parameters for transmitting (communicating) a work package to the first node agent 210 based on an availability calendar (e.g., a network availability calendar 126). The transmission parameters may include the time to transmit the work package to the first vehicle (e.g., the first electric vehicle). For example, the time to transmit may be when the first node agent 210 is in download mode (e.g., the vehicle has internet connectivity and is using limited computing resources).

[0094] Subsequently, based on the transmission parameters, CCMS112 can send a request for the first node agent 210 to perform the computing task of the work package.

[0095] Additionally, CCMS112 can generate a second work package based on the computing power of the second node agent 220 and assign it to the second node agent 220. For example, the computing power of the second node agent 220 may be lower than that of the first node agent 210, and therefore CCMS can assign a second work package that is easier to execute than the first work package.

[0096] Figure 3 shows a block diagram 300 of the computing components of the CCMS and each node agent according to an exemplary embodiment of this specification. The block diagram 300 includes a CCMS 310, a blockchain interface 320, a work package storage 330, a work package verifier 340, a first host system 350, and a second host system 360. The CCMS 310 may include a node agent inventory 315. The first host system 350 (e.g., a first vehicle, a first electric vehicle) may include a first node agent 355 (e.g., an in-vehicle computing system 130). The second host system 360 (e.g., a second vehicle, a second electric vehicle) may include a second node agent 365. In some embodiments, the CCMS 310 may include hardware, software, or functionality similar to that of the CCMS 112. In some embodiments, the first host system 350 may include hardware, software, or functionality similar to that of the vehicle 105. In some embodiments, the first node agent 355 may include hardware, software, or functions similar to those of the in-vehicle computing system 130.

[0097] The first and second node agents 350 and 360 can collect context information 356 and 366, respectively. Context information 356 and 366 may include data related to learning the usage and connectivity patterns of each node agent. For example, the first node agent 350 may acquire data indicating the charging behavior of the first node agent 350 (e.g., as vehicle charging data 124). The first node agent 350 may also acquire data indicating network behavior related to the first node 350. For example, the first node agent 350 may examine network connectivity status via speed tests (e.g., to the CCMS 310) to help determine when and where the first node agent 350 connects to the CCMS 310. In one embodiment, the first node agent 350 can determine the quality of the network connection (e.g., signal strength).

[0098] The first node agent 350 can also acquire data indicating the type, usage, and performance of the computing resources (e.g., those installed in a vehicle) of the first node agent 350. This may include maintaining data structures indicating computing hardware (e.g., CPU, GPU), their manufacturer / model, lifespan, etc. This may also include maintaining statistics across activations of different agent modes. Each node agent can periodically perform a self-assessment of its computing capabilities by running standardized performance benchmarks on available hardware (e.g., GPU, CPU, ML accelerator), which may be stored as computing capability data (e.g., computing capability data 129).

[0099] According to some embodiments, the first node agent 355 of the first host system 350 (e.g., an IoT device, a vehicle) can have multiple states, such as download mode, compute mode, or off mode. In some cases, the first host system 350 can have multiple node agents.

[0100] During download mode, the first host system 350 or the first node agent 355 can perform download mode tasks (e.g., download data) using internet connectivity and limited computing resources (e.g., less than 10%). Additionally, download mode can be terminated and resumed without issue by the first host system 350 or the first node agent 355. By requiring limited computing resources, download mode can operate even when the first host system 350 is being used for its primary purpose, such as when a vehicle is being driven and requires computing resources for driving.

[0101] A compute node may require the use of a larger share (e.g., more than 50%) of the computing resources of the first node agent 355 to perform compute mode tasks (e.g., compute tasks for work packages). In some cases, compute mode may be intended to run when the first host system 350 or the first node agent 355 determines that the primary function of the system is not required (e.g., when a vehicle is actively charging). In compute mode, the first node agent 355 can isolate the general computing environment from the rest of the first host system 350 through virtualization. Additionally, the first node agent 355 can enable access to the hardware of the first host system 350 (e.g., GPUs, CPUs, ML accelerators) to perform tasks. Furthermore, the first node agent 355 can be controlled and scheduled by the first host system 350.

[0102] Off mode can occur when the vehicle is not connected to a network. Additionally, off mode can occur when the vehicle is completely stopped. Furthermore, off mode can occur when the vehicle's battery level falls below a predetermined threshold.

[0103] In some cases, context information 356, 366 may include user-specific data. The first host system 350 can provide the first node agent 355 with access to the host system's user-specific data (e.g., context data, vehicle data 118). User-specific data may include data that is relevant to learning the usage patterns of the first host system 350. This may include information such as the user's specific location history, charging location, charging date, charging time, or other information.

[0104] The first node agent 355 may include, use, or otherwise leverage a machine learning (ML) model 357. The machine learning model 357 may include a neural network (e.g., a deep neural network), or other types of machine learning models, including nonlinear and / or linear models. The neural network may include a feedforward neural network, a recurrent neural network (e.g., a long-term memory recurrent neural network), a convolutional neural network, or other forms of neural networks. Some exemplary machine learning models may leverage attentional mechanisms, such as self-attention. For example, some exemplary machine learning models may include a multi-head self-attention model (e.g., a transformer model).

[0105] In some cases, the ML model 357 can be configured to determine the availability and probability of different modes of the first host system 350. For example, the first node agent 355 can input context information 356 into the ML model 357 to determine the probability or availability of each mode over different periods in the future. The first node agent 355 can use the ML model 357 to determine the availability and probability of different modes from historical data and generate a quantization calendar by accessing the context information 356 provided from the first host system 350 (including, for example, vehicle data 118), investigating the network connectivity status via speed tests to the CCMS 310, and maintaining statistics on the activation of different modes. The quantization calendar can predict the state of the first node agent 355 (e.g., off, download, or compute mode) and the network status at a specific point in the future, as will be further illustrated with reference to Figure 4.

[0106] ML model 357 can be trained using training context data. Training context data may include contextual information such as network availability data, billing data, and location data. The training context data may include labeled training data. The training context information can be supplied to ML model 357, processed by ML model 357, and compared to ground truth. This can be done on the first node agent 355 or on a remote computing system, as further described herein. Training of ML model 357 may include various training or learning techniques, such as backpropagation of errors. For example, a loss function can be backpropagated through the model(s) to update one or more parameters of the model(s) (e.g., based on the gradient of the loss function).

[0107] In some cases, network status may be used by the CCMS 310 to determine one or more transmission parameters based on the availability calendar of the first node agent 355. Based on the transmission parameters, the CCMS 310 can send a request to the first host system 350 to perform a task. The transmission parameters may indicate the time (e.g., weekday, time of day, etc.) or vehicle location at which the CCMS 310 can request the first node agent 355 to complete the computing task. In some cases, the transmission parameters may indicate the mode of the first node agent 355. In some cases, the transmission parameters may include a future scheduled time for the first node agent 355 to send a request to complete the computing task.

[0108] To protect user-specific data (e.g., personally identifiable information (PII), contextual data, private data), in one embodiment, the learning process for training the ML model 257 can be executed only on the first node agent 355 to prevent user-specific data from being transmitted from the first host system 350. The techniques described herein allow the first host system 350 to provide user-specific data to the first node agent 355 to improve the accuracy of probability and availability determinations without the privacy implications of a centralized method (e.g., without transmitting user-specific data to the computing platform 110 or CCMS 310). In some cases, the first node agent 355 only shares the availability calendar and performance benchmarks with the CCMS 310. Additionally, the first node agent 355 only shares the predictive availability calendar and performance benchmarks with the CCMS 310. Additionally, each node agent can periodically self-assess its computing power by running standardized performance benchmarks on available hardware (e.g., GPUs, CPUs, ML accelerators), which can be stored as computing power data (e.g., computing power data 129).

[0109] The node agent inventory 315 may include a data structure that shows one or more node agents registered with the CCMS 310. The data structure of the node agent inventory 315 may include lists, tables, etc. According to some embodiments, a node agent (first node agent 355, second node agent 360) can register itself with the CCMS 310 by sending its computing power (e.g., previously evaluated benchmark results of the node agent) and the node agent's predictability calendar to the CCMS 310. Once a node agent is registered, the CCMS 310 can store the node agent data in the node agent inventory 315. After a node agent is registered, it may be selected for task assignment. In one embodiment, a node agent can await a task assignment from the CCMS 310 (e.g., a request to perform tasks in a work package).

[0110] The work package storage 330 may be a system containing a self-contained finite set of computational instructions that have all the data and computational instructions necessary to complete a computing task. The computing task may also include metadata that describes the computing task and its requirements in more detail, such as the required hardware, an optional completion date, and the effort required for the task. The work package verifier 340 can verify whether the computing task has been successfully completed by the node agent 350. This result can then be used to create a smart contract, ensuring the authenticity of the source and the integrity of the data. Interfaces such as the blockchain interface 320 can communicate with a shared, immutable record of smart contracts, similar to but not limited to the blockchain 510.

[0111] The work package verifier 340 can verify that a work package has been completed by a node agent. For example, the work package verifier 340 can send a verification message to the CCMS 310 indicating that the first node agent 355 has successfully executed the computing task of the assigned work package.

[0112] The blockchain interface 320 may be an interface for communicating with the CCMS 310 to generate smart contracts associated with rewards for performing computing tasks. In other embodiments, the CCMS 320 may interface with a non-blockchain interface that enables the generation of contracts associated with rewards for performing computing tasks.

[0113] In one embodiment, a reward can be provided to a node agent for performing a computing task. The CCMS 310 can interact with a work package verifier 340 that can verify that the computing task has been successfully executed. The CCMS 310 can then interact with a blockchain interface 330 to generate a smart contract for the node agent. The smart contract can be associated with a reward for the node agent. For example, the reward could be a monetary compensation for successfully performing the computing task. In another example, the reward could be an additional benefit received from the vehicle manufacturer (e.g., free / discounted vehicle charging).

[0114] Agent application Figure 4 shows a flowchart 400 of exemplary compute-mode communication between a first host system 350, a first node agent 355, and a CCMS 310 according to an exemplary embodiment of the present invention. Figure 4 includes a plurality of operations 410, 420, 430, and 440, each of which may include suboperations or steps (shown in Figure 4) that can be performed by the host system 350.

[0115] In operation 410, the host system 350 can determine an availability calendar (e.g., a calculated mode availability calendar 128). In some cases, the first node agent 355 can collect data (e.g., vehicle data 118) to generate the availability calendar. For example, the first node agent 355 can acquire (and store) context information 356 which may include vehicle data 118, relevant time (e.g., weekday, daytime), and relevant location (e.g., latitude / longitude coordinates, address). The first node agent 355 can also perform connectivity tests with a network (e.g., a communication channel to CCMS 310 has been established). Connectivity tests may include network speed tests to determine whether the first node agent 335 can connect / transmit data over the network, or to indicate the quality of the connection. Information collected by the first node agent can be stored in the memory of the first node agent 355 (e.g., as vehicle data 118).

[0116] The first node agent 355 can use the collected data to determine an availability calendar. For example, the first node agent 355 can process the collected data (e.g., vehicle data 118) to predict when and where the first node agent 355 will connect to the network associated with the CCMS 310. The first node agent 355 can use such data to determine which (and which parts) of the node agent's computing resources (e.g., processor, memory, power, bandwidth) will be available during a particular timeframe. The first node agent 355 can also determine how long such resources will be available to complete computing tasks. The first node agent 355 can also predict the time, location, and duration of the first node agent 355 being in a particular mode (e.g., download mode, compute mode, off mode). For example, vehicle data 118 can be input into the ML model 357 to generate an availability calendar. The availability calendar may include a compute mode availability calendar 128 and a network availability calendar 126. The computation mode availability calendar 128 and the network availability calendar 126 may be combined into a single data structure or separated into different data structures.

[0117] As described herein, the availability calendar is a quantization calendar that predicts the current state and future state of the first node agent 355, or may otherwise include it. Table 1 below provides an example quantization calendar.

[0118] [Table 1]

[0119] In some cases, the first node agent 355 can evaluate the network availability calendar. For example, in a future timeframe identified in the availability calendar (e.g., 00:30am to 00:45am on day +1), the first node agent 355 can acquire data to determine whether the computed availability forecast (e.g., 50%) and network forecast (e.g., status: 1% connected, speed: 10% faster than 5Mbit / s) included in the availability calendar are similar to the actual state of the first node agent 355 (e.g., within a 5% range). If so, the first node agent 355 can retain the availability calendar. Otherwise, the first node agent 355 can revise the availability calendar or improve its forecast by collecting updated data associated with the first node agent 355.

[0120] In operation 420, if the vehicle data (e.g., vehicle data 118) is updated (e.g., the number of updated data points exceeds a predetermined threshold), the host system 350 can recalculate the availability calendar. For example, if the threshold number of data points for vehicle data 118 (e.g., 10) changes, the first node agent 355 can retrain the ML model 357 based on the updated vehicle data 118. In some cases, additional layers may be added to the ML model 357.

[0121] The first node agent 355 can periodically (e.g., hourly, daily, weekly) input updated vehicle data into the ML model 357 to generate an updated availability calendar. If the updated availability calendar differs from a previously sent availability calendar, the updated availability calendar is sent to the CCMS 310. Furthermore, when a threshold for change in the probability associated with the availability calendar is reached, the availability calendar can be uploaded to the CCMS 310 again. For example, when the machine learning model determines that there is a 95% confidence that a vehicle is available for computation mode during a first period, the computation mode availability calendar is updated to include the first period. The updated computation mode availability calendar can then be submitted to the CCMS 310. Furthermore, the ML model 357 may have self-learning or self-supervised techniques based on vehicle data 118, charging patterns, and network vectors (e.g., network state, network connectivity prediction, network speed prediction). The network vectors may include data associated with network state, connectivity prediction, and / or speed prediction. As described above, private data (e.g., user-specific data, vehicle-specific data, PII) can be processed in the first node agent 355 to protect user privacy.

[0122] In operation 430, when the first node agent 355 is in calculation mode, the first node agent 355 can communicate with the CCMS 310. For example, the first node agent 355 can use one or more network test diagnostic tools to test (or retest) the network connectivity between the first node agent 355 and the CCMS 310 to test the speed, quality, etc., of the connection between the first node agent 355 and the CCMS 310. The first node agent 355 can retain updated connectivity test data. In some cases, the first node agent 355 can obtain updated context information (e.g., vehicle data 118). As further described herein, during calculation mode, the first node agent 355 can perform tasks related to requests received from the CCMS 310.

[0123] In operation 440, the first host system 350 may shut down the compute mode by sending a shutdown notification to the first node agent. For example, if the first host system 350 is being used by a user to drive to a certain location, the first host system 350 may shut down the compute mode so that its computing resources are used for driving purposes. In some cases, the first node agent 355 may evaluate (or re-evaluate) the availability calendar using techniques similar to those already described herein.

[0124] Centralized Computing Management System (CCMS) Figure 5 shows a block diagram of an exemplary centralized computing management system ecosystem 500 according to an exemplary embodiment of this specification. Figure 5 also shows an exemplary data flow between systems in ecosystem 500.

[0125] The ecosystem 500 may include several subsystems, such as the CCMS 310, work package storage 330, work package verifier 340, and block interface 320. As shown in Figure 3, the CCMS 310 may include a node agent inventory 315. The node agent inventory 315 (not shown in Figure 5) can store node agent data associated with each registered node agent. Each node agent 350 can register with the CCMS 310 to consider work package assignments.

[0126] Node agents communicate with the node agent inventory to upload their predictability calendars and network calendars (e.g., network vectors).

[0127] CCMS310 can initiate the assignment of work packages (e.g., workloads) to one or more node agents registered with CCMS310 (e.g., the first node agent 355). As described above, the first node agent 355 can send its computing power and availability calendar to CCMS310. The network connectivity (e.g., network vector) of the first node agent 355 can be evaluated by CCMS310 when the first node agent 355 connects to CCMS310. In some cases, task assignment may be performed once CCMS310 has registered one or more agents in its node agent inventory.

[0128] Based on its capabilities, CCMS310 can prepare work packages (e.g., workloads) and assign them to node agent 355. Work packages can be obtained based on the availability calendar and computing power of the first node agent 355. For example, the computing power of the first node agent 355 may include multiple GPUs. The availability calendar may indicate, for example, that at a future point in time (e.g., when the first node agent 355 is in compute mode), 99% of the GPUs will be available to complete a computing task for 2.5 hours, and that the first node agent 355 will be available to receive (and send) communications to CCMS310 over the network. CCMS310 can identify computing tasks (e.g., automated data labeling) that can be completed by the first node agent 355 within this timeframe using these computing resources. CCMS can generate a work package that shows the compute instructions to complete this computing task. CCMS310 can assign the work package to the first node agent 355. The process of assigning work packages (e.g., workloads) is further explained in Figures 6 and 7.

[0129] In response to the first node agent 355 receiving work package data (e.g., work package data 131) from CCMS 310, the first node agent 355 can download the work package from the work package storage 330. The work package data may include a cryptographic signature and the location of the work package. Once the work package is downloaded, the first node agent 355 can process one or more tasks associated with the work package.

[0130] The first node agent 355 may upload the processing results to the work package storage 330. The first node agent 355 can notify the CCMS 310 of task completion. For example, the first node agent 355 can send a notification to the CCMS 310 at the present time or at a later time (for example, when the first node agent 355 is not present at the present time but has network connectivity).

[0131] In one embodiment, CCMS310 can coordinate (e.g., request) the creation of a smart contract that can be cryptographically signed to guarantee the authenticity of the origin and the integrity of the data. CCMS310 can send the request to the blockchain interface 320 to establish the smart contract. Additionally, the blockchain interface 320 can maintain an inventory of smart contracts and tasks performed by different node agents.

[0132] Smart contracts can be cryptographically signed using blockchain 510. By cryptographically signing using blockchain 510, a digital signature is created using an encryption algorithm and then recorded on blockchain node 520. This process guarantees the authenticity and integrity of the signed data. Once created using an encryption algorithm, the digital signature generates a unique code that can only be created by the owner of the private key associated with the signature (e.g., CCMS310, blockchain interface 320). This ensures that the signature can only be created by an authorized entity (e.g., CCMS310, blockchain interface 320) and cannot be forged. By combining the digital signature with blockchain 510, the signature can be recorded on blockchain node 520 in a tamper-proof manner.

[0133] After the smart contract is established, the blockchain interface 320 can send the information associated with the smart contract back to the CCMS 310. To verify the work that has been performed, the CCMS 310 can request verification from the work package verifier 340. For example, the work package verifier 340 can send work package verification data 133 to the CCMS 310. The work package verifier 340 may download the work package and results from the work package storage 330 and determine whether the processing was successful or not. The work package verifier 340 can determine whether the computing task was successfully executed based on the completion notification received when the computing task is finished. Additionally, if the computing task is not executed within a predetermined time, the work package verifier 340 indicates that the computing task was not successfully executed. The result of the verification request can be forwarded to the CCMS 310. The CCMS can notify the blockchain interface 510 of the updated information of the smart contract. If the validation request fails, CCMS310 assumes that the work package (e.g., workload) has not been processed satisfactorily and reassigns it to another agent (e.g., a second node agent 360).

[0134] Figure 6 shows a flowchart 600 of a CCMS that assigns tasks to node agents according to an exemplary embodiment of this specification.

[0135] In operation 610, the CCMS 310 can assign a work package to the first node agent 355. Each work package may be finite and self-contained. Additionally, the CCMS 310 can ensure that the tasks are of an appropriate size to guarantee that the agent can complete the task within a given computation mode time limit. Thus, the CCMS 310 can baseline tasks so that only tasks that are feasible (in terms of time and processing power) can be assigned to node agents.

[0136] As described herein, work packages can be generated based on an availability calendar and the computing power of the first node agent 355. For example, computing power may indicate that the first node agent 355 includes multiple CPUs (e.g., mounted in a vehicle). The availability calendar may indicate that the first node agent 355 will be in compute mode for a length of 5 hours during a particular future period, when 95% of its CPUs are available to process computing tasks. The CCMS 310 can select computing tasks (e.g., image processing) for the first node agent 355 that can be completed based on these computing powers and their availability. The CCMS 310 can generate work packages (e.g., along with the associated computing instructions) that represent the computing tasks. Based on the availability calendar, the CCMS 310 can determine transmission parameters indicating when the first node agent 355 should send a request to complete the work package and send the request accordingly.

[0137] The first node agent 355 can retrieve work packages from the work package storage 330. Once the work packages are downloaded by the first node agent 355, the tasks in the work packages can be executed while the first node agent 355 is in compute mode.

[0138] The CCMS310 can access the node agent inventory 315 to obtain a list of registered node agents. The node agent inventory 315 may have multiple lists for the CCMS310 to select from. For example, the node agent inventory 315 may have a first list associated with high-performance node agents and a second list associated with low-performance node agents. Furthermore, each computing task may be labeled as a high-priority task, a medium-priority task, and a low-priority task. Based on the labels associated with the computing tasks and the different characteristics of the node agents (e.g., high performance, high reliability, good network connectivity), the CCMS310 can assign computing tasks to registered node agents.

[0139] For example, CCMS310 can assign high-priority tasks first, medium-priority tasks second, and low-priority tasks last. Priority can indicate the urgency to which CCMS310 wants the computing task to be completed. Additionally, CCMS can assign a first task requiring high processing power to a first node with high processing power, and a second task requiring low processing power to a second node with either high or low processing power.

[0140] In some cases, assignment does not require an active node agent, but CCMS310 can utilize the currently connected node agent to avoid latency in assigning work packages. The determination of which node agent is currently connected can be made based on the availability calendar.

[0141] CCMS can assign different levels of task priority to each node agent (for example, to a node that is currently connected, has a good track record, and has a faster processing speed). This allows CCMS310 to determine which node agents are trustworthy and increase the likelihood of assigning tasks to node agents with a positive record of completing computing tasks. In some cases, node agents may be assigned different task priorities based on the trustworthiness of each node agent. For example, a first node with a high trustworthiness score may be assigned high-priority tasks, while a second node with a low trustworthiness score may be assigned low-priority tasks.

[0142] In one embodiment, the CCMS310 can rebalance tasks that have already been assigned. For example, the CCMS310 may have already assigned a first computing task to a first node agent 355 and a second computing task to a second node agent 365. The CCMS310 may determine that a third computing task has a higher priority than the first and second tasks. The CCMS310 may determine that the third computing task requires a substantial amount of computing resources that can only be available on the second node agent within a desired timeframe for completion. The CCMS310 may determine that the second task can be completed by the computing resources of the first node agent, and that the first computing task can be completed by the computing resources of the third node agent. Therefore, the CCMS310 can rebalance the computing tasks by reassigning the first computing task to the third node agent, reassigning the second computing task to the first node agent, and reassigning the third computing task to the second node agent. This can enable the first, second, and third computing tasks to be completed in a reliable, timely, and efficient manner.

[0143] Exemplary Method The following flowcharts include operations that can be performed by computing systems. Operations described in the examples herein as being performed by a particular computing system are not intended to be limiting and may be performed by other computing systems. For example, operations described as being performed on a vehicle may be performed by a computing system located remotely from the vehicle, or vice versa.

[0144] Figure 7 is a flowchart illustrating a method 700 in which the CCMS sends a request to a node agent to perform a computing task. In one embodiment, method 700 can be performed by a CCMS such as CCMS112, CCMS310, the control circuit 915 in Figure 9, or other suitable control circuit. One or more parts of method 700 may be implemented as algorithms on hardware components of the devices described herein. For example, steps of method 700 may be implemented as actions / instructions that can be executed by computing hardware.

[0145] Figure 7 shows steps performed in a specific order for illustrative and explanatory purposes, but the methods of this disclosure are not limited to the order or sequence shown. Various steps of Method 700 may be omitted, rearranged, combined, or adapted in various ways without departing from the scope of this disclosure.

[0146] Method 700 includes, but is not limited to, an electric vehicle acting as a node agent, for illustrative purposes only. It should be understood that other vehicles or IoT devices may be used in place of the electric vehicle within Method 700, as described herein.

[0147] In one embodiment, Method 700 may begin with step 710 in which a computing system (e.g., CCMS112, CCMS310) receives vehicle data from a first electric vehicle (e.g., vehicle 105, first node agent 210, first host system 350), including the computing capacity of the first electric vehicle and the availability calendar of the first electric vehicle, or may otherwise include such data. The computing capacity of the first electric vehicle (e.g., computing capacity data 129) may be determined on the vehicle based on a performance analysis of one or more computing resources installed on the first electric vehicle. Additionally, the availability calendar of the first electric vehicle (e.g., network availability calendar 126, compute mode availability calendar 128) may be determined on the vehicle, and the availability calendar may indicate the predicted network connectivity of the first electric vehicle.

[0148] According to some embodiments, some electric vehicles (e.g., the first electric vehicle) may operate solely on batteries, while others may be hybrid models equipped with both electric motors and internal combustion engines. In some cases, the electric vehicle (e.g., the first electric vehicle) may be a battery electric vehicle (BEV), a plug-in hybrid electric vehicle (PHEV), a hybrid electric vehicle (HEV), or a fuel cell electric vehicle (FCEV). A BEV operates solely on electricity and is recharged from an external power source. A BEV is propelled by one or more electric motors powered by a rechargeable battery pack. A PHEV uses a battery to power electric motors and can be recharged from an external power source. Additionally, a PHEV incorporates an internal combustion engine that can recharge the battery or directly power the wheels to enable a longer driving range. A HEV is powered by a combination of an internal combustion engine and electric motors powered from a battery pack for greater efficiency. The battery in an HEV cannot be recharged from an external power source. FCEVs use a highly efficient electrochemical process to convert hydrogen into electricity, which then powers an electric motor.

[0149] As an exemplary example, vehicle 105 can determine an availability calendar based on user-specific data. The availability calendar may include a network availability calendar 126 and a compute mode availability calendar 128. Then, as part of registration as a node agent, vehicle 105 can send vehicle data 118, including the availability calendar and compute capacity data 129, to CCMS 112.

[0150] In some cases, the first electric vehicle may be an electric vehicle. The system may generate electronic rewards for the user of the first electric vehicle based on the completion of computing tasks and contributions to the reduction of greenhouse gas emissions. For example, the reward may be renewable energy credits generated by a smart contract. Renewable energy credits (RECs) may be certificates corresponding to the environmental attributes of energy generated from renewable resources or energy consumption reduced using a modern, more efficient in-vehicle computing system. Renewable energy credits can track progress and compliance with government renewable portfolio standards intended to support a cleaner power generation mix.

[0151] In some cases, rewards may be based on the first node agent's contribution to reducing greenhouse gas emissions / mitigating climate change. For example, the first node agent could be an electric vehicle. Rewards may be monetary or other credit benefits. Rewards can be increased based on the total number of computing tasks completed by the electric vehicle, the electric vehicle's lifespan, etc., with higher rewards for more computing tasks completed or for the electric vehicle being used by the user (e.g., more charging credits). Additionally or alternatively, rewards may be based on a user's recent transition from a combustion engine vehicle to an electric vehicle, for example, a user may have recently acquired an electric vehicle after owning a combustion engine vehicle. Rewards for the first computing tasks completed by this electric vehicle may be higher to encourage the use of electric vehicles.

[0152] CCMS310 can provide data indicating rewards (e.g., prizes) for the user profile of the first node agent. This could include, for example, depositing monetary rewards as credits to an account associated with the user's database. In some cases, this could involve using a specific banking API to send data indicating the rewards so that they are reflected in the user's bank account.

[0153] In some cases, the system may register a first electric vehicle as a node agent in the agent inventory. The agent inventory may have a list of node agents. Additionally, each node agent in the list of node agents may include an associated availability calendar.

[0154] In some cases, the availability calendar can be determined by the first electric vehicle using one or more machine learning models based on the network connectivity vector of the first electric vehicle or the computational availability of the first electric vehicle. Additionally, the availability calendar can include multiple locations, and the network connectivity vector of the first electric vehicle can indicate the network connectivity of the first electric vehicle at each of the multiple locations. Furthermore, the network connectivity vector of the first electric vehicle can be determined by performing a network connectivity speed test with the first electric vehicle.

[0155] In one embodiment, method 700 may begin with step 720, in which a computing system generates a work package for the first electric vehicle based on the computing capabilities of the first electric vehicle, or may otherwise include such a work package (e.g., work package data 131) may include computing tasks that the first electric vehicle completes using at least some of the computing resources installed in the first electric vehicle.

[0156] Continuing with the illustrative example, the CCMS 112 can generate a work package so that the in-vehicle computing system 130 can complete a computing task (e.g., performing a non-driving computing task) when the vehicle 105 is in a computing mode (e.g., charging). The computing mode may be identified in the computing mode availability calendar 129. For example, the vehicle 105 can be expected to be in computing mode on weekday nights when the vehicle is charging at the user's home.

[0157] In some cases, a work package can indicate at least one of the following: minimum computing resource requirements, completion date, and the effort level required to perform the workload tasks.

[0158] In one embodiment, method 700 may begin with step 730 in which a computing system determines one or more transmission parameters for communicating a work package to a first electric vehicle based on an availability calendar, or otherwise include the transmission parameters. The transmission parameters may include the time to transmit the work package to the first electric vehicle. For example, the availability calendar may include a network availability calendar (network availability calendar 126) that determines when a vehicle is able to transmit data over the network. The transmission parameters may be determined based on the network availability calendar 126.

[0159] Continuing with the illustrative example, CCMS112 can determine, based on the network availability calendar 129, that the time to send the work package to the vehicle 105 is during the user's commute. Therefore, the transmission parameters can include a timeframe related to the user's morning commute (e.g., from 8 AM to 8:30 AM).

[0160] In some cases, the availability calendar received by 710 may be a quantized calendar that predicts the current state and operating state of the first electric vehicle over a future period. For example, the operating state of the first electric vehicle may be off, downloading, or computing. Based on the predicted download state of the node agent 355, the CCMS 310 can determine the transmission parameters.

[0161] In some cases, the availability calendar may be further determined based on user-specific data processed only on the vehicle using an in-vehicle computing system (e.g., in-vehicle computing system 130). For example, the in-vehicle computing system may utilize data sources containing personally identifiable information (PII), but such information is removed during the generation of the availability calendar. This allows the in-vehicle computing system to transmit the availability calendar while still protecting user-specific data within its secure computing resources installed in the vehicle.

[0162] In one embodiment, method 700 may begin with step 740, in which a computing system transmits a request for a first electric vehicle to perform a computing task of a work package based on transmission parameters, or may otherwise include the same. In some cases, the request may include a cryptographic signature and the location of the work package. Additionally, the work package may be stored in work package storage. Furthermore, the work package storage may contain computation instructions and data for performing the computing task.

[0163] Continuing with the illustrative example, CCMS112 can send a request to vehicle 105 during the user's morning commute. The request may include work package data 131, which includes the location of the assigned work package in work package storage 330.

[0164] In some cases, the availability calendar received by 710 may include a compute-mode availability calendar (e.g., compute-mode availability calendar 128) that determines the specific time and duration for which the vehicle is available to perform computing tasks on a workload task payload.

[0165] In some cases, computing tasks can be performed by the first electric vehicle only during the computing state. Furthermore, the first electric vehicle can be restricted from performing computing tasks during the download state.

[0166] In some cases, the system can receive confirmation from a work verifier that a work package or computing task has been executed. Additionally, the system can generate a smart contract associated with the work package. The smart contract may include a cryptographic signature and code indicating an indication by the first electric vehicle that the first electric vehicle will perform the computing task. Furthermore, the system can send the smart contract to a blockchain interface. The blockchain interface can maintain the execution status of the computing task (e.g., task assigned, task running, task completed, task reassigned).

[0167] In some cases, the system may determine that a computing task was not performed by the first electric vehicle within a predetermined time. Additionally, based on the determination that the computing task was not performed by the first electric vehicle within a predetermined time, the system may assign a work package to be performed by the second vehicle.

[0168] Figure 8 shows a flowchart illustrating Method 800 for an IoT device to send an availability calendar to the CCMS for registration as a node agent. In one embodiment, Method 800 can be performed by an IoT device such as a vehicle 105, a first node agent 210, a first host system 350, the control circuit 915 in Figure 9, or other suitable control circuit. One or more parts of Method 800 may be implemented as algorithms on the hardware components of the devices described herein. For example, the steps of Method 1200 may be implemented as actions / instructions that can be executed by computing hardware.

[0169] Figure 8 shows steps performed in a specific order for illustrative and explanatory purposes, but the methods of this disclosure are not limited to the order or arrangement shown. Various steps of Method 800 may be omitted, rearranged, combined, or adapted in various ways without departing from the scope of this disclosure.

[0170] Method 800 includes, but is not limited to, a vehicle acting as a node agent, for illustrative purposes only. It should be understood that, as described herein, electric vehicles or other IoT devices may be used in place of a vehicle within Method 800.

[0171] In one embodiment, Method 800 may begin in step 810, or otherwise include, a computing system (e.g., Vehicle 105, First Node Agent 210, Node Agent 355) using an on-board computing system (e.g., On-board computing system 13) of the First Vehicle (e.g., Vehicle 105, Electric Vehicle) to determine the computing capability of the First Vehicle based on a performance analysis of one or more computing resources installed in the First Vehicle. The computing capability may be based on previously evaluated benchmark results of the Node Agents, On-board computing system, or Vehicle.

[0172] In one embodiment, method 800 may begin with a step 820 in which a computing system determines a network availability calendar for a first vehicle using an in-vehicle computing system, or otherwise include the method. The network availability calendar may indicate the predicted network connectivity of the first vehicle. The network availability calendar may predict when a node agent will have good network connectivity as a particular period in the future. In some cases, as described herein, the vehicle data 118 may be generated using one or more machine learning models (e.g., machine learning model 357).

[0173] In one embodiment, Method 800 may begin with step 830, in which a computing system determines a compute mode availability calendar for a first vehicle using an in-vehicle computing system, or otherwise include the same. The compute mode availability calendar may indicate future forecast periods during which the first vehicle is available to perform computing tasks of a work package. The compute mode availability calendar may indicate times and periods during which the first vehicle may be available to perform a given task, even in the absence of network connectivity. The compute mode calendar may indicate when (e.g., days, hours) the first vehicle is expected to be in compute mode, download mode, or off mode. For example, the compute mode availability calendar can accurately predict when a vehicle will be parked and charged based on vehicle data 118. The compute mode calendar may indicate the types of available computing resources (e.g., CPU, GPU) installed in the first vehicle. The compute mode calendar may indicate which portions of the computing resources are available to perform computing tasks (e.g., 50%, 99%). As described herein, the first vehicle can generate a computation mode calendar by leveraging one or more machine learning models.

[0174] In one embodiment, method 800 may begin with step 810, in which the computing system transmits vehicle data (e.g., vehicle data 118) to the CCMS (e.g., CCMS 310), or may otherwise include the vehicle data, which may include the computing capabilities of the first vehicle, the network availability calendar of the first vehicle, and / or the compute mode availability of the first vehicle. In one embodiment, by transmitting the information described in operation 840, the vehicle 105 may register itself with the CCMS 310 as a node agent 355.

[0175] In one embodiment, method 800 may begin in step 850 in which the computing system receives a request from the CCMS having a work package for a first vehicle, or otherwise include such a request. The work package may represent a computing task that the first vehicle completes using at least a portion of the computing resources installed in the first vehicle. The request received in 850 may be similar to a request sent by the CCMS 310 in operation 740.

[0176] In some cases, the first vehicle may download the work package when the vehicle is in download mode operation as indicated by the network availability calendar. The network availability calendar 126 is generated by the first vehicle in step 820. Additionally, the first vehicle may perform (e.g., execute, process) the computing task(s) of the work package while in compute mode. The compute mode can be determined (e.g., predicted) by the first vehicle when the compute mode availability calendar 128 is generated in step 830.

[0177] In some cases, the first vehicle (e.g., vehicle 105) can send a notification to the CCMS 112 after the computing task(s) have been executed. The notification may indicate that the computing task has been completed. The CCMS 112 can then receive work package verification data 133 from the work package verifier 340 to determine whether the computing task has been successfully completed.

[0178] Exemplary computing system Figure 9 shows a block diagram of an exemplary in-vehicle computing system 900 according to one embodiment of the present invention. The system 900 includes an in-vehicle computing system 905 (e.g., a computing system mounted in a vehicle), a server computing system 1005 (e.g., a remote computing system, a cloud computing platform), and a training computing system 1105, all of which are communicably coupled via one or more networks 955.

[0179] The in-vehicle computing system 905 may include one or more computing devices 910 or circuits. For example, the in-vehicle computing system 905 may include a control circuit 915 and a non-temporary computer-readable medium 920, also referred to herein as memory. In one embodiment, the control circuit 915 may include one or more processing cores, programmable logic circuits (PLCs) or programmable logic / gate arrays (PLAs / PGAs), field-programmable gate arrays (FPGAs), application-specific integrated circuits (ASICs), or any other control circuits. In some implementations, the control circuit 915 may be part of, or form part of, a vehicle control unit (also referred to as a vehicle controller) that is embedded in or otherwise positioned in a vehicle (e.g., a Mercedes-Benz® car or van). For example, the vehicle controller may be an infotainment system controller (e.g., an infotainment head unit), a telematics control unit (TCU), an electronic control unit (ECU), a central powertrain controller (CPC), a charge controller, a central external and internal controller (CEIC), a zone controller, or any other controller, or may include these. In one embodiment, the control circuit 915 may be programmed by one or more computer-readable or computer-executable instructions stored in a non-temporary computer-readable medium 920. In some cases, the in-vehicle computing system 905 may be an in-vehicle computing system 130, a first node agent 210, a second node agent 220, a first node agent 355, or a second node agent 365.

[0180] In one embodiment, the non-temporary computer-readable medium 920 may be a memory device, also called a data storage device, which may include an electronic storage device, a magnetic storage device, an optical storage device, an electromagnetic storage device, a semiconductor storage device, or any suitable combination thereof. The non-temporary computer-readable medium 920 can form, for example, a hard disk drive (HDD), a solid-state drive (SDD) or solid-state integrated memory, random access memory (RAM), read-only memory (ROM), erasable programmable read-only memory (EPROM or flash memory), static random access memory (SRAM), dynamic random access memory (DRAM), portable compact disc read-only memory (CD-ROM), digital multipurpose disc (DVD), or memory stick.

[0181] Non-temporary computer-readable medium 920 can store information that can be accessed by the control circuit 915. For example, non-temporary computer-readable medium 920 (e.g., a memory device) can store data 925 that can be acquired, received, accessed, written, manipulated, created, or stored. The data 925 may include, for example, any of the data or information described herein. In one embodiment, the in-vehicle computing system 905 can acquire data from one or more remotely located memories.

[0182] The non-temporary computer-readable medium 920 may also store computer-readable instructions 930 that can be executed by the control circuit 915. Instructions 930 may be software written in any suitable programming language, or they may be implemented in hardware. Instructions may include computer-readable instructions, computer-executable instructions, and so on. As described herein, in various embodiments, the terms “computer-readable instructions” and “computer-executable instructions” are used to describe software instructions or computer code configured to perform various tasks and operations. In various embodiments, where computer-readable or computer-executable instructions form a module, the term “module” broadly refers to a set of software instructions or code configured to cause the control circuit 915 to perform one or more functional tasks. Modules and computer-readable / executable instructions may be described as performing various operations or tasks when the control circuit 915 or other hardware components are executing the module or computer-readable instructions.

[0183] Instruction 930 may be executed in a separate logical or virtual thread on the control circuit 915. For example, non-temporary computer-readable medium 920 may store instructions 930 that, when executed by the control circuit 915, cause the control circuit 915 to perform any of the operations, methods, or processes described herein. In some cases, non-temporary computer-readable medium 920 may store computer-executable instructions or computer-readable instructions, such as instructions for performing at least a portion of the methods(s) shown in Figures 7-8.

[0184] In one embodiment, the in-vehicle computing system 905 may store or include one or more machine learning models 935. In one embodiment, one or more machine learning models 935 may be received from the server computing system 1005 via the network 955, stored in the in-vehicle computing system 905 (e.g., a non-temporary computer-readable medium 920), and then used by the control circuit 915, or otherwise implemented. In one embodiment, the in-vehicle computing system 905 may implement multiple parallel instances of a single model.

[0185] Additionally or alternatively, one or more machine learning models 935 may be contained within, or otherwise stored and implemented by, a server computing system 1005 that communicates with the in-vehicle computing system 905 according to a client-server relationship. For example, a machine learning model 935 may be implemented by the server computing system 1005 as part of a web service. Thus, one or more models 935 may be stored and implemented in the in-vehicle computing system 905, or one or more models 935 may be stored and implemented in the server computing system 1005.

[0186] One or more Model 935s may be trained to perform the functions and operations described herein to determine availability calendars, for example, a network availability calendar 126 and / or a calculation mode availability calendar 128, based on vehicle data 118, work package data 131, map data 132, work package verification data 133, and / or charging station data 134. Additionally, one or more Model 935s may be trained with user-specific data associated with the vehicle 105, which can only be processed using the vehicle's onboard computing system 130 to protect data privacy.

[0187] The in-vehicle computing system 905 may include a communication interface 940. The communication interface 940 may be used to communicate with one or more other systems. The communication interface 940 may include any circuits, components, software, etc., for communicating over one or more networks (e.g., network 955). In one embodiment, the communication interface 940 may include, for example, one or more communication controllers, receivers, transceivers, transmitters, ports, conductors, software, or hardware for communicating data / information.

[0188] The in-vehicle computing system 905 may also include one or more user input components 945 that receive user input. For example, a user input component 945 may be a touch-sensitive component (e.g., a touch-sensitive display screen or touchpad) that is sensitive to the touch of a user input object (e.g., a finger or stylus). The touch-sensitive component may function to implement a virtual keyboard. Other exemplary user input components include a microphone, a conventional keyboard, a cursor device, a joystick, or other devices to which the user may provide user input. As an example, an input component 945 may be, or may include, an infotainment system in a vehicle.

[0189] The in-vehicle computing system 905 may include one or more output components 950. The output components 950 may include hardware or software for generating content audibly or visually. For example, the output component 950 may have one or more speakers, earpieces, headsets, handsets, etc. The output component 950 may have a display device that has hardware for displaying a user interface or messages to the user. For example, the output component 950 may include a display screen, CRT, LCD, plasma screen, touchscreen, TV, projector, tablet, or other suitable display component. For example, the output component 950 may be, or include, an in-vehicle infotainment system.

[0190] The server computing system 1005 may include one or more computing devices 1010. In one embodiment, the server computing system 1005 may include one or more server computing devices, or be otherwise implemented therein. In cases where the server computing system 1005 includes multiple server computing devices, such server computing devices may operate according to a sequential computing architecture, a parallel computing architecture, or any combination thereof. In some cases, the server computing system 1005 may be a computing platform 110, CCMS 112, or CCMS 310.

[0191] The server computing system 1005 may include a control circuit 1015 and a non-temporary computer-readable medium 1020, also referred to herein as memory 1020. In one embodiment, the control circuit 1015 may include one or more processors (e.g., microprocessors), one or more processing cores, a programmable logic circuit (PLC) or programmable logic / gate array (PLA / PGA), a field-programmable gate array (FPGA), an application-specific integrated circuit (ASIC), or any other control circuit. In one embodiment, the control circuit 1015 may be programmed by one or more computer-readable or computer-executable instructions stored in the non-temporary computer-readable medium 1020.

[0192] In one embodiment, the non-temporary computer-readable medium 1020 may be a memory device, also called a data storage device, which may include an electronic storage device, a magnetic storage device, an optical storage device, an electromagnetic storage device, a semiconductor storage device, or any suitable combination thereof. The non-temporary computer-readable medium can form, for example, a hard disk drive (HDD), a solid-state drive (SDD) or solid-state integrated memory, random access memory (RAM), read-only memory (ROM), erasable programmable read-only memory (EPROM or flash memory), static random access memory (SRAM), dynamic random access memory (DRAM), portable compact disc read-only memory (CD-ROM), digital multipurpose disc (DVD), or memory stick.

[0193] Non-temporary computer-readable medium 1020 can store information that can be accessed by the control circuit 1015. For example, non-temporary computer-readable medium 1020 (e.g., a memory device) can store data 1025 that can be acquired, received, accessed, written, manipulated, created, or stored. The data 1025 may include, for example, any of the data or information described herein. In one embodiment, the server computing system 1005 can acquire data from one or more remotely located memories from the server computing system 1005.

[0194] The non-temporary computer-readable medium 1020 may also store computer-readable instructions 1030 that can be executed by the control circuit 1015. Instructions 1030 may be software written in any suitable programming language, or they may be implemented in hardware. Instructions may include computer-readable instructions, computer-executable instructions, and so on. As described herein, in various embodiments, the terms “computer-readable instructions” and “computer-executable instructions” are used to describe software instructions or computer code configured to perform various tasks and operations. In various embodiments, where computer-readable or computer-executable instructions form a module, the term “module” broadly refers to a set of software instructions or code configured to cause the control circuit 1015 to perform one or more functional tasks. Modules and computer-readable / executable instructions may be described as performing various operations or tasks when the control circuit 1015 or other hardware components are executing the module or computer-readable instructions.

[0195] Instruction 1030 may be executed in a separate logical or virtual thread on the control circuit 1015. For example, non-temporary computer-readable medium 1020 may store instruction 1030, which, when executed by the control circuit 1015, causes the control circuit 1015 to perform any of the operations, methods, or processes described herein. In some cases, non-temporary computer-readable medium 1020 may store computer-executable instructions or computer-readable instructions, such as instructions for performing at least a portion of the methods(s) shown in Figures 7-8.

[0196] The server computing system 1005 may store or otherwise include one or more machine learning models 1035. The machine learning models 1035 may include, or be identical to, the model 935 stored in the in-vehicle computing system 905. In one embodiment, the machine learning models 1035 may include an unsupervised learning model (e.g., for generating data clusters). In one embodiment, the machine learning models 1035 may include other types of machine learning models, including neural networks (e.g., deep neural networks) or nonlinear or linear models. The neural networks may include feedforward neural networks, recurrent neural networks (e.g., long-term memory recurrent neural networks), convolutional neural networks, or other forms of neural networks. Some exemplary machine learning models may leverage attentional mechanisms such as self-attention. For example, some exemplary machine learning models may include multi-head self-attentional models (e.g., transformer models).

[0197] In some cases, one or more Model 1035s may be trained to perform the functions and operations described herein to determine which node agent to assign a computing task to, based on the node agent's network availability calendar 126 and / or compute mode availability calendar 128. Additionally, the decision on which node agent to assign a computing task may be further based on non-user specific vehicle data 118, work package data 131, map data 132, work package validation data 133, and / or charging station data 134.

[0198] The server computing system 1005 may include a communication interface 1040. The communication interface 1040 may be used to communicate with one or more other systems. The communication interface 1040 may include any circuits, components, software, etc., for communicating over one or more networks (e.g., network 955). In one embodiment, the communication interface 1040 may include, for example, one or more communication controllers, receivers, transceivers, transmitters, ports, conductors, software, or hardware for communicating data / information.

[0199] The in-vehicle computing system 905 or the server computing system 1005 can train models 935 and 1035 through interaction with a training computing system 1105 which is communicatively coupled via a network 955. The training computing system 1105 may be separate from the server computing system 1005 or may be part of the server computing system 1005.

[0200] The training computing system 1105 may include one or more computing devices 1110. In one embodiment, the training computing system 1105 may include one or more server computing devices, or be otherwise implemented thereby. In cases where the training computing system 1105 includes multiple server computing devices, such server computing devices may operate according to a sequential computing architecture, a parallel computing architecture, or any combination thereof.

[0201] The training computing system 1105 may include a control circuit 1115 and a non-temporary computer-readable medium 1120, also referred to herein as memory 1120. In one embodiment, the control circuit 1115 may include one or more processors (e.g., microprocessors), one or more processing cores, a programmable logic circuit (PLC) or programmable logic / gate array (PLA / PGA), a field-programmable gate array (FPGA), an application-specific integrated circuit (ASIC), or any other control circuit. In one embodiment, the control circuit 1115 may be programmed by one or more computer-readable or computer-executable instructions stored in the non-temporary computer-readable medium 1120.

[0202] In one embodiment, the non-temporary computer-readable medium 1120 may be a memory device, also called a data storage device, which may include an electronic storage device, a magnetic storage device, an optical storage device, an electromagnetic storage device, a semiconductor storage device, or any suitable combination thereof. The non-temporary computer-readable medium can form, for example, a hard disk drive (HDD), a solid-state drive (SDD) or solid-state integrated memory, random access memory (RAM), read-only memory (ROM), erasable programmable read-only memory (EPROM or flash memory), static random access memory (SRAM), dynamic random access memory (DRAM), portable compact disc read-only memory (CD-ROM), digital multipurpose disc (DVD), or memory stick.

[0203] Non-temporary computer-readable medium 1120 can store information that can be accessed by the control circuit 1115. For example, non-temporary computer-readable medium 1120 (e.g., a memory device) can store data 1125 that can be acquired, received, accessed, written, manipulated, created, or stored. The data 1125 may include any of the data or information described herein, such as data relating to a simulated environment. In one embodiment, the training computing system 1105 can acquire data from one or more memories located remotely from the training computing system 1105.

[0204] The non-temporary computer-readable medium 1120 may also store computer-readable instructions 1130 that can be executed by the control circuit 1115. Instructions 1130 may be software written in any suitable programming language, or they may be implemented in hardware. Instructions may include computer-readable instructions, computer-executable instructions, and so on. As described herein, in various embodiments, the terms “computer-readable instructions” and “computer-executable instructions” are used to describe software instructions or computer code configured to perform various tasks and operations. In various embodiments, where computer-readable or computer-executable instructions form a module, the term “module” broadly refers to a set of software instructions or code configured to cause the control circuit 1115 to perform one or more functional tasks. Modules and computer-readable / executable instructions may be described as performing various operations or tasks when the control circuit 1115 or other hardware components execute the module or computer-readable instructions.

[0205] Instruction 1130 may be executed in a separate logical or virtual thread on the control circuit 1115. For example, non-temporary computer-readable medium 1120 may store instruction 1130 that, when executed by the control circuit 1115, causes the control circuit 1115 to perform any of the operations, methods, or processes described herein. In some cases, non-temporary computer-readable medium 1120 may store computer-executable instructions or computer-readable instructions, such as instructions for performing at least a portion of the methods(s) shown in Figures 7-8.

[0206] The training computing system 1105 may include a model trainer 1135 that trains machine learning models 935, 1035 stored in the in-vehicle computing system 905 or the server computing system 1005 using various training or learning techniques. For example, models 935, 1035 (e.g., machine learning models for vehicle availability) may be trained using simulated environment techniques, such as training models 935, 1035 using a simulated representation of a road created from existing sensor data or motion data (e.g., predicting vehicle connectivity and computability in a simulated environment).

[0207] In some implementations, the model trainer can train models 935 and 1035 in an unsupervised manner.

[0208] The computing system may modify the parameters of models 935, 1035 based on the loss function, thereby allowing the model to be effectively trained for a specific application in an unsupervised manner, without the need for labeled data.

[0209] The model trainer 1135 can utilize training techniques such as backward propagation of errors. For example, a loss function can be backpropagated through the model to update one or more parameters of the model (e.g., based on the gradient of the loss function). Various loss functions can be used, such as mean squared error, likelihood loss, cross-entropy loss, hinge loss, or various other loss functions. The parameters can be iteratively updated over several training iterations using gradient descent.

[0210] In one embodiment, performing error backpropagation may include performing truncated backpropagation through time. The model trainer 1135 can perform several generalization techniques (e.g., weight decay, dropout, etc.) to improve the generalization ability of the trained model. In particular, the model trainer 1135 can train machine learning models 935, 1035 based on the training data set 1140.

[0211] The training data 1140 may include unlabeled training data for unsupervised training. The training data 1140 may include datasets such as vehicle characteristics, model, class, type, and exemplary driving routes. The model trainer 1135 can train models 935, 1035 to determine the network availability calendar 126 and / or the computed mode availability calendar 128.

[0212] The model trainer 1135 may include computer logic used to provide a desired function. The model trainer 1135 may be implemented in hardware, firmware, or software that controls a general-purpose processor. For example, in one embodiment, the model trainer 1135 may include a program file stored in a storage device, loaded into memory, and executed by one or more processors. In other implementations, the model trainer 1135 may include one or more sets of computer executable instructions stored in a tangible computer-readable storage medium such as RAM, a hard disk, or an optical or magnetic medium.

[0213] The training computing system 1105 may include a communication interface 1145. The communication interface 1145 may be used to communicate with one or more other systems. The communication interface 1145 may include any circuits, components, software, etc., for communicating over one or more networks (e.g., network 955). In one embodiment, the communication interface 1145 may include, for example, one or more communication controllers, receivers, transceivers, transmitters, ports, conductors, software, or hardware for communicating data / information.

[0214] Network 955 can be any type of communication network, such as a local area network (e.g., an intranet), a wide area network (e.g., the Internet), or any combination thereof, and may include any number of wired or wireless links. Generally, communication over Network 955 can be carried out over any type of wired or wireless connection using a wide variety of communication protocols (e.g., TCP / IP, HTTP, SMTP, FTP), encoding or formatting (e.g., HTML, XML), or protection schemes (e.g., VPN, Secure HTTP, SSL).

[0215] The machine learning models described herein may have various types of input data or combinations thereof that represent data available to other systems installed in the vehicle. The input data may include, for example, latent coded data (e.g., latent spatial representation of the input), statistical data (e.g., data calculated or derived from some other data source), sensor data (e.g., raw or processed data captured by the vehicle's sensors), or other types of data.

[0216] Figure 9 shows one exemplary computing system that may be used to implement the present disclosure. Other computing systems may be used in a similar manner. For example, in one embodiment, the in-vehicle computing system 905 may include a model trainer 1135 and training data 1140. In such an implementation, the model 935 may be trained locally on the in-vehicle computing system 905 and used. In some such implementations, the in-vehicle computing system 905 may implement the model trainer 1135 to personalize the model 935 based on user-specific data.

[0217] Further consideration of various embodiments Embodiment 1 relates to a computer implementation method. The method may include receiving vehicle data from a first vehicle (e.g., an electric vehicle), including the computing capacity of the first vehicle and an availability calendar for the first vehicle. The computing capacity of the first vehicle can be determined on the first vehicle based on a performance analysis of one or more computing resources installed on the first vehicle. The availability calendar for the first vehicle can be determined on the vehicle, and the availability calendar indicates the expected network connectivity of the first vehicle. The method may include generating a work package for the first vehicle based on the computing capacity of the first vehicle. The work package may include computing tasks that the first vehicle will complete using at least a portion of the computing resources installed on the first vehicle. The method may include determining one or more transmission parameters for communicating the work package to the first vehicle based on the availability calendar. The transmission parameters may include the time to send the work package to the first vehicle. The method may include sending a request for the first vehicle to perform the computing tasks of the work package based on the transmission parameters.

[0218] Embodiment 2 includes a computer implementation of Embodiment 1. In this embodiment, the request may include the location of the cryptographic signature and the work package.

[0219] Embodiment 3 includes a computer implementation of Embodiment 2. In this embodiment, a work package can be stored in a work package storage. The work package storage may contain computational instructions and data for executing computing tasks.

[0220] Embodiment 4 includes a computer implementation method of Embodiment 2. In this embodiment, the method may further include receiving confirmation from a work verifier that a computing task has been performed, and generating a smart contract associated with the work package, wherein the smart contract includes a cryptographic signature and a code indicating an indication by the first vehicle that the first vehicle has performed a computing task.

[0221] Embodiment 5 includes a computer implementation method of Embodiment 4. In this embodiment, the method may further include sending a smart contract to a blockchain interface. The blockchain interface can maintain the execution status of computing tasks.

[0222] Embodiment 6 includes a computer implementation method of Embodiment 1. In this embodiment, the method may further include determining that a computing task was not performed by the first vehicle within a predetermined time, and, based on the determination that the computing task was not performed by the first vehicle within a predetermined time, assigning a work package to be performed by the second vehicle.

[0223] Embodiment 7 includes a computer implementation method of Embodiment 1. In this embodiment, the method may further include registering a first vehicle as a node agent in the agent inventory, the agent inventory having a list of node agents. Each node agent in the list of node agents may include an associated availability calendar.

[0224] Embodiment 8 includes a computer implementation of Embodiment 1. In this embodiment, the availability calendar can be determined by the first vehicle using one or more machine learning models based on the network connectivity vectors and computation mode availability calendar of the first vehicle.

[0225] Embodiment 9 includes a computerized implementation of Embodiment 8. In this embodiment, the availability calendar may include a plurality of locations, and the network connectivity vector of the first vehicle indicates the network connectivity of the first vehicle at each of the plurality of locations.

[0226] Embodiment 10 includes a computer implementation method of Embodiment 9. In this embodiment, the network connectivity vector of the first vehicle can be determined by performing a network connectivity speed test with the first vehicle.

[0227] Embodiment 11 includes a computer implementation of Embodiment 1. In this embodiment, the work package indicates at least one of the following: minimum computing resource requirements, completion date, and effort level required to perform the work package.

[0228] Embodiment 12 includes a computerized implementation of Embodiment 1. In this embodiment, the availability calendar is a quantized calendar that predicts the current state and operating state of the first vehicle over a future period.

[0229] Embodiment 13 includes a computer implementation method of Embodiment 12. In this embodiment, the operating state of the first vehicle may be off, downloading, or calculating.

[0230] Embodiment 14 includes a computer implementation of Embodiment 13. In this embodiment, the computing task is performed by the first vehicle only during the computing state.

[0231] Embodiment 15 includes a computer implementation of Embodiment 13. In this embodiment, the first vehicle is restricted from performing computing tasks while in a download state.

[0232] Embodiment 16 includes a computer implementation of Embodiment 1. In this embodiment, the availability calendar may include a network availability calendar that determines when a vehicle can transmit data over the network.

[0233] Embodiment 17 includes a computer implementation of Embodiment 1. In this embodiment, the availability calendar may include a compute mode availability calendar that determines specific times and durations during which a vehicle is available to perform computing tasks for a work package.

[0234] Embodiment 18 includes a computer implementation of Embodiment 1. In this embodiment, the availability calendar may be further determined based on user-specific data processed only on the vehicle.

[0235] Embodiment 19 relates to a computing system. The computing system may include a control circuit of a task management system. The control circuit may be configured to receive vehicle data from a first vehicle, including the computing capacity of the first vehicle and an availability calendar for the first vehicle. The computing capacity of the first vehicle can be determined on the vehicle based on a performance analysis of one or more computing resources installed in the first vehicle. The availability calendar for the first vehicle can be determined on the vehicle, and the availability calendar indicates the expected network connectivity of the first vehicle. The control circuit may be configured to generate a work package for the first vehicle based on the computing capacity of the first vehicle. The work package may include computing tasks that the first vehicle will complete using at least a portion of the computing resources installed in the first vehicle. The control circuit may be configured to determine one or more transmission parameters for communicating the work package to the first vehicle based on the availability calendar. The transmission parameters may include a time to send the work package to the first vehicle. Based on the transmission parameters, the control circuit may be configured to send a request for the first vehicle to perform the computing tasks of the work package.

[0236] Embodiment 20 relates to one or more non-temporary computer-readable media for storing instructions that can be executed by a control circuit to perform an operation. The control circuit can receive vehicle data from a first vehicle, including the computing capacity of the first vehicle and an availability calendar for the first vehicle. The computing capacity of the first vehicle can be determined on the vehicle based on a performance analysis of one or more computing resources installed in the first vehicle. The availability calendar for the first vehicle can be determined on the vehicle, and the availability calendar indicates the expected network connectivity of the first vehicle. The control circuit may be configured to generate a work package for the first vehicle based on the computing capacity of the first vehicle. The work package may include computing tasks that the first vehicle will complete using at least some of the computing resources installed in the first vehicle. The control circuit may be configured to determine one or more transmit parameters for communicating the work package to the first vehicle based on the availability calendar. The transmit parameters may include a time to transmit the work package to the first vehicle. Based on the transmit parameters, the control circuit may be configured to send a request for the first vehicle to perform the computing tasks of the work package.

[0237] Additional disclosures As used herein, adjectives and their possessive forms are intended to be interchangeable unless it is evident from the context or explicitly indicated otherwise. For example, “vehicle components” may be interchangeable with “vehicle components” where appropriate. Similarly, words, phrases, and other disclosures herein are intended to encompass obvious variations and synonyms, even if such variations and synonyms are not explicitly listed.

[0238] The technologies discussed herein refer to servers, databases, software applications, and other computer-based systems, as well as the actions performed and the information transmitted to and from such systems. The inherent flexibility of computer-based systems allows for a wide variety of possible configurations, combinations, and divisions of tasks and functions between their components. For example, the processes described herein may be performed using a single device or component, or multiple devices or components operating in combination. Databases and applications may run on a single system or be distributed across multiple systems. Distributed components may operate sequentially or in parallel.

[0239] While the subject matter has been described in detail with respect to various specific exemplary embodiments, each example is provided for illustrative purposes only and not as a limitation of the disclosure. Those skilled in the art, having achieved the foregoing understanding, can readily generate modifications, variations, and equivalents of such embodiments. Therefore, the disclosure does not exclude such modifications, variations, or additions to the subject matter, as will be readily apparent to those skilled in the art. For example, features illustrated or described as part of one embodiment may be used in conjunction with another embodiment to result in yet another embodiment. Thus, the disclosure is intended to encompass such modifications, variations, and equivalents.

[0240] The aspects of this disclosure are described in relation to exemplary embodiments. Numerous other implementations, modifications, or variations within the scope and spirit of the appended claims can be recalled by those skilled in the art from the examination of this disclosure. Any and all features in the following claims can be combined or reconfigured in any possible way. Thus, the scope of this disclosure is illustrative and not limiting, and this disclosure does not exclude such modifications, variations, or additional inclusions to the subject matter, as will be readily apparent to those skilled in the art. Furthermore, terms are used herein with lists of exemplary elements joined by conjunctions such as “and,” “or,” and “but.” It should be understood that such conjunctions are provided for illustrative purposes only. The terms “and / or” and “or” may be used interchangeably herein. For example, a list joined by a particular conjunction such as “or” may refer to “at least one” or “any combination” of the exemplary elements enumerated therein, and “or” shall be understood as “or” unless otherwise indicated. Also, terms such as “based on” should be understood as “at least partially based on.”

[0241] Those skilled in the art will understand, by using the disclosures provided herein, that any element of the claims, actions, or processes discussed herein may be adapted, rearranged, expanded, omitted, combined, or modified in various ways without departing from the scope of this disclosure. Sometimes, elements are enumerated in the specification or claims using letter references for illustrative purposes and are not intended to be limiting. Where used, letter references do not imply a particular order of actions or the importance of any particular element listed. For example, (a), (b), (c), ..., (i), (ii), (iii), ..., etc., may be used to indicate actions or different elements within a list. Such identifiers are provided for the convenience of the reader and do not indicate a particular order, importance, or priority of steps, actions, or elements. For example, an action indicated by a list identifier such as (a), (i) may be performed before, after, or concurrently with another action indicated by a list identifier such as (b), (ii).

Claims

1. A computer implementation method, Receiving vehicle data from a first electric vehicle, including the computing capabilities of the first electric vehicle and the availability calendar of the first electric vehicle, The computing capability of the first electric vehicle is determined on the first electric vehicle based on a performance analysis of one or more computing resources installed on the first electric vehicle. The availability calendar for the first electric vehicle is determined on the vehicle, and the availability calendar indicates the expected network connectivity of the first electric vehicle. Based on the computing capabilities of the first electric vehicle, a work package for the first electric vehicle is generated, wherein the work package includes computing tasks that the first electric vehicle completes using at least a portion of the computing resources installed in the first electric vehicle. Based on the availability calendar, determine one or more transmission parameters for transmitting the work package to the first electric vehicle, wherein the transmission parameters include the time for transmitting the work package to the first electric vehicle. Based on the transmission parameters, the first electric vehicle transmits a request to perform the computing task of the work package, A computer implementation method, including

2. The first electric vehicle is an electric vehicle, and the method is Based on the completion of the computing task and the contribution to the reduction of greenhouse gas emissions, an electronic reward is generated for the user of the first electric vehicle. The computer implementation method according to claim 1, further comprising:

3. The computer implementation method according to claim 1, wherein the requirement includes a cryptographic signature and the location of the work package.

4. The computer implementation method according to claim 3, wherein the work package is stored in a work package storage, and the work package storage has computational instructions and data for executing the computing task.

5. Confirmation that the aforementioned computing task has been executed is received from the work verifier, To generate a smart contract associated with the work package, wherein the smart contract includes the cryptographic signature and code indicating an indication by the first electric vehicle that the first electric vehicle performed the computing task. The computer implementation method according to claim 3, further comprising:

6. The process further includes sending the smart contract to a blockchain interface, the blockchain interface maintaining the execution status of the computing task. The computer implementation method according to claim 5.

7. Determining that the computing task was not performed by the first electric vehicle within a predetermined time, Based on the determination that the computing task was not performed by the first electric vehicle within the predetermined time, the work package to be performed by the second electric vehicle is assigned. The computer implementation method according to claim 1, further comprising:

8. The process further includes registering the first electric vehicle as a node agent in the agent inventory, the agent inventory having a list of node agents, and each node agent in the list of node agents having an associated availability calendar. The computer implementation method according to claim 1.

9. The availability calendar is determined by the first electric vehicle using one or more machine learning models based on the network connection vector and computation mode availability calendar of the first electric vehicle. The availability calendar is further determined based on user-specific data processed only on the vehicle. The computer implementation method according to claim 1.

10. The computer implementation method according to claim 9, wherein the availability calendar includes a plurality of locations, and the network connection vector of the first electric vehicle indicates the network connection of the first electric vehicle at each of the plurality of locations.

11. The computer implementation method according to claim 10, wherein the network connection vector of the first electric vehicle is determined by performing a network connectivity speed test with the first electric vehicle.

12. The computer implementation method according to claim 1, wherein the work package indicates at least one of the minimum computing resource requirements, the completion date, and the effort level required to perform the work package.

13. The computer implementation method according to claim 1, wherein the availability calendar is a quantization calendar that predicts the current state and future operating state of the first electric vehicle.

14. The computer implementation method according to claim 13, wherein the operating state of the first electric vehicle is one of the off state, download state, or calculation state.

15. The computer implementation method according to claim 14, wherein the computing task is performed by the first electric vehicle only during the computing state.

16. The computer implementation method according to claim 14, wherein the first electric vehicle is restricted from performing the computing task during the download state.

17. The computer implementation method according to claim 1, wherein the availability calendar includes a network availability calendar that determines when the vehicle can transmit data over the network.

18. The computer implementation method according to claim 1, wherein the availability calendar includes a compute mode availability calendar that determines specific times and durations during which the vehicle is available to perform the computing tasks of the work package.

19. A computing system, The control circuit of the task management system is provided, and the control circuit receives vehicle data from a first electric vehicle, including the computing capabilities of the first electric vehicle and the availability calendar of the first electric vehicle. The computing capability of the first electric vehicle is determined on the vehicle based on a performance analysis of one or more computing resources installed on the first electric vehicle. The availability calendar for the first electric vehicle is determined on the vehicle, and the availability calendar indicates the expected network connectivity of the first electric vehicle. Based on the computing capabilities of the first electric vehicle, a work package for the first electric vehicle is generated, wherein the work package includes computing tasks that the first electric vehicle completes using at least a portion of the computing resources installed in the first electric vehicle. Based on the availability calendar, determine one or more transmission parameters for transmitting the work package to the first electric vehicle, wherein the transmission parameters include the time for transmitting the work package to the first electric vehicle. Based on the transmission parameters, the first electric vehicle transmits a request to perform the computing task of the work package, A computing system configured to perform the following tasks.

20. One or more non-temporary computer-readable media for storing instructions, wherein the instructions are controlled by a control circuit. Receiving vehicle data from a first electric vehicle, including the computing capabilities of the first electric vehicle and the availability calendar of the first electric vehicle, The computing capability of the first electric vehicle is determined on the first electric vehicle based on a performance analysis of one or more computing resources installed on the first electric vehicle. The availability calendar for the first electric vehicle is determined on the vehicle, and the availability calendar indicates the expected network connectivity of the first electric vehicle. Based on the computing capabilities of the first electric vehicle, a work package for the first electric vehicle is generated, wherein the work package includes computing tasks that the first electric vehicle completes using at least a portion of the computing resources installed in the first electric vehicle. Based on the availability calendar, determine one or more transmission parameters for transmitting the work package to the first electric vehicle, wherein the transmission parameters include the time for transmitting the work package to the first electric vehicle. Based on the transmission parameters, the first electric vehicle transmits a request to perform the computing task of the work package, One or more non-temporary computer-readable media capable of executing this.

Images