Decentralized Vehicle Software Update Propagation

Resolve Bottlenecks,
Find Innovative Solutions
Generate Solutions

Solution Overview

Problem

Current software update systems for vehicles are inefficient and insecure, relying on centralized networks and lacking comprehensive testing across a large number of transports, which can lead to inadequate validation and potential software issues.

Innovation Solution

A decentralized system using blockchain technology for software updates, where updates are validated and propagated through a network of vehicles, with multiple environments and proximity-based sharing, ensuring extensive testing and secure authentication.

Engineering Contradictions & Design Principles

VSEngineering Contradiction Analysis

1Reliability

If a centralized server distributes software updates to individual transport clients, then software updates can be delivered to transports, but the system becomes inefficient and insecure with extensive WAN usage

Engineering Contradiction:
ImprovesecurityVSAvoidefficiency
Core Design Contradiction:
ReliabilityVSProductivity

Solution Approach 1:

The patent segments the centralized update distribution into multiple decentralized update sources (other transports). Instead of all transports communicating with a single central server, updates are distributed peer-to-peer through the transport network, reducing WAN dependency and improving security while maintaining efficiency

Inventive Principle:
Principle #1Segmentation

Solution Approach 2:

The patent introduces blockchain technology as an intermediary layer that mediates between update sources and transport clients. The blockchain ledger verifies and tracks software update provenance, ensuring security and integrity without requiring extensive centralized server communication

Inventive Principle:
Principle #24Intermediary (Mediator)

2Reliability

If software updates are distributed through a centralized server, then updates can be propagated quickly, but the updates may not be adequately tested by a sufficiently large number of transports prior to distribution

Engineering Contradiction:
ImprovevalidationVSAvoidtesting time
Core Design Contradiction:
ReliabilityVSLoss of time

Solution Approach 1:

The patent implements preliminary testing by deploying software updates to a subset of transports before full distribution. The blockchain system tracks validation status, and updates are marked as tested once a sufficient number of transports successfully run them, ensuring adequate testing before widespread propagation

Inventive Principle:
Principle #10Preliminary action

Solution Approach 2:

The patent establishes a feedback mechanism where transports report validation results back to the network through the blockchain ledger. This feedback allows the system to track how many transports have successfully tested an update and makes this information visible to other transports, enabling informed update adoption decisions

Inventive Principle:
Principle #23Feedback

3Loss of information

If a centralized system collects and tracks software update information from millions of transports, then comprehensive tracking is achieved, but the system becomes complex and insecure

Engineering Contradiction:
Improvetracking completenessVSAvoidsystem complexity
Core Design Contradiction:
Loss of informationVSDevice complexity

Solution Approach 1:

The patent enables transports to self-verify software update information through the decentralized blockchain ledger. Each transport maintains its own record of update validation status, eliminating the need for a complex centralized tracking system while ensuring complete information availability across the network

Inventive Principle:
Principle #25Self-service

Data Source

PatentUS11868764B2Management of transport software updates
Publication Date: 2024.01.09 TOYOTA MOTOR NORTH AMERICA INC
  • US11868764B2 patent drawing
  • US11868764B2 patent drawing
  • US11868764B2 patent drawing

AI summary

An example operation may include one or more of sending, by a master transport, a first portion of a software update to a transport of a first subset of transports, sending, by a master transport, a second portion of the software update to a transport of a further subset of transports, when a first transport of the subset of the transports and a second transport of the further subset of the transports are in proximity, causing the first transport to send the first portion of the software update to the second transport, and causing the second transport to send the second portion of the software update to the first transport.