IP Library Granted Patent US 11,294,662
Granted Patent B2
US 11,294,662 · App. 16/597,796 · Granted Apr 5, 2022

Management of transport software updates

Inventors: Louis Brugman (Frisco, TX); Devang H. Parekh (Dallas, TX); Wilson-Boon Siang Khoo (Allen, TX)
Assignee: TOYOTA MOTOR NORTH AMERICA, INC.
G06F8/658G06F8/656G06F21/57H04L9/0643H04L2209/38
View Patent ↗
Loading inventors, assignments & file history…
Monitor This Case
Get email alerts when status or documents change.
Order Certified Copies
Most orders are placed with the USPTO same day — all within 24 business hours.
Order via The Patent Place →
Pre-filled with this patent's details
Quick Facts
Patent No.
US 11,294,662
App. No.
16/597,796
Granted
Apr 5, 2022
Kind
B2
Abstract

An example operation may include one or more of receiving a software update at a transport, performing a first validation of the software update in a first environment, wherein the first environment includes a least amount of potential interactions, and performing a further validation of the software update when the first validation is successful, in a further environment, wherein the further environment includes an amount of potential interactions greater than the first environment.

Claims (31)

1. A method, comprising:

dividing a software update by a first transport into a first portion and a second portion;

sending the first portion, by the first transport, to a second transport, wherein the first portion is sent to the second transport based on one or more characteristics of the second transport;

sending the second portion, by the first transport, to a third transport based on one or more characteristics of the third transport being different from the one or more characteristics of the second transport;

instructing the third transport, by the first transport, to send the second portion of the software update to the second transport when the second transport and the third transport are in proximity to one another; and

executing the software update, by the second transport, intermittently with a previous software update, wherein the executing of the software update is performed when the second transport is operated in a minimal traffic environment, and wherein the executing of the previous software version is performed when the second transport is not being operated in the minimal traffic environment.

2. The method of claim 1 , comprising reverting to the previous software version when a failure of one or more software validations occurs.

3. The method of claim 2 , comprising receiving the one or more software validations from another transport.

4. The method of claim 1 , comprising invoking the software update based on an analysis of one or more driving environments.

5. The method of claim 1 , comprising executing a smart contract to record at least one data block reflecting a validated software update on a ledger of the blockchain.

6. A system, comprising:

a processor of a first transport;

a memory on which are stored machine readable instructions that when executed by the processor, cause the processor to:

divide a software update by the first transport into a first portion and a second portion;

send the first portion by the first transport to a second transport, wherein the first portion is sent to the second transport based on one or more characteristics of the second transport;

send the second portion to a third transport based on one or more characteristics of the third transport being different from the one or more characteristics of the second transport;

instruct the third transport, by the first transport, to send the second portion of the software update to the second transport when the second transport and the third transport are in proximity to one another; and

execute the software update, by the second transport, intermittently with a previous software version, wherein the execution of the software update is performed when the second transport is operated in a minimal traffic environment, and wherein the execution of the previous software version is performed when the second transport is not being operated in the minimal traffic environment.

7. The system of claim 6 , wherein the instructions further cause the processor to revert to the previous software version when a failure of one or more software validations occurs.

8. The system of claim 6 , wherein the instructions further cause the processor to receive the one or more software validations from another transport.

9. The system of claim 6 , wherein the instructions further cause the processor to invoke the software update based on an analysis of one or more driving environments.

10. The system of claim 6 , wherein the instructions further cause the processor to execute a smart contract to record at least one data block that reflects validated software update on a ledger of the blockchain.

11. A non-transitory computer readable medium comprising instructions, that when read by a processor, cause the processor to:

dividing a software update by a first transport into a first portion and a second portion;

sending the first portion, by the first transport, to a second transport, wherein the first portion is sent to the second transport based on one or more characteristics of the second transport;

sending the second portion, by the first transport, to a third transport based on one or more characteristics of the third transport being different from the one or more characteristics of the second transport;

instructing the third transport, by the first transport, to send the second portion of the software update to the second transport when the second transport and the third transport are in proximity to one another; and

executing the software update, by the second transport, intermittently with a previous software update, wherein the executing of the software update is performed when the second transport is operated in a minimal traffic environment, and wherein the executing of the previous software version is performed when the second transport is not being operated in the minimal traffic environment.

12. The non-transitory computer readable medium of claim 11 , further comprising instructions, that when read by a processor, cause the processor to revert to the previous software version when a failure of one or more software validations occurs.

13. The non-transitory computer readable medium of claim 11 , further comprising instructions, that when read by a processor, cause the processor to receive the one or more software validations from another transport.

14. The non-transitory computer readable medium of claim 11 , further comprising instructions, that when read by a processor, cause the processor to execute a smart contract to execute a smart contract to record at least one data block reflecting a validated software update on a ledger of the blockchain.

Assignments (1)
ASSIGNMENT OF ASSIGNOR'S INTEREST Recorded Oct 9, 2019
From: BRUGMAN, LOUIS; PAREKH, DEVANG H.; KHOO, WILSON-BOON SIANG
To: TOYOTA MOTOR NORTH AMERICA, INC.
Reel/Frame 050671/0983 →
Continuity (1)
Related Publication 20210109746A1 · Apr 15, 2021
Cited By (1)
US 12,430,420