Memory device with secure boot updates and self recovery
US-2024406008-A1 · Dec 5, 2024 · US
US2021397429A1 · US · A1
| Field | Value |
|---|---|
| Publication number | US-2021397429-A1 |
| Application number | US-202016906433-A |
| Country | US |
| Kind code | A1 |
| Filing date | Jun 19, 2020 |
| Priority date | Jun 19, 2020 |
| Publication date | Dec 23, 2021 |
| Grant date | — |
A practical reading order for non-experts. Skip the full description unless you need deep technical detail.
What the patent document calls the invention.
A short plain-language summary of the technical disclosure.
Who owns or filed the patent and who is credited as inventor.
Filing, priority, publication, and grant dates set the timeline.
The legal scope of protection — read this for what is actually claimed.
Technology tags used to group this patent with similar filings.
Prior art links and similar publications in this corpus.
Official abstract text for this publication.
Methods, systems, and devices supporting live updates for stateful software components are described. A computing system may implement live updating for patching stateful software components. A device may execute a first set of requests at a first version of a software component deployed to a container, where the software component may be a stateful component associated with an in-memory state managed by the container. The device may receive a software patch that includes a second version of the software component from a user device, deploy the second version of the software component to the container, and route a second set of requests to the second version of the software component. The device may update the in-memory state of the software component based on the first version of the software component and the second version of the software component to maintain accurate state information across versions during the patching process.
Opening claim text (preview).
1 . A method for managing software updates, comprising: executing a first set of requests at a first version of a software component deployed to a container, wherein the software component comprises a stateful component, and wherein executing the first set of requests changes an in-memory state of the software component managed by the container based at least in part on the software component comprising the stateful component; receiving, from a user device, a software patch comprising a second version of the software component; deploying the second version of the software component to the container based at least in part on the software patch and concurrent with executing at least a first portion of the first set of requests at the first version of the software component; routing a second set of requests to the second version of the software component based at least in part on the deploying; and updating, at the container, the in-memory state of the software component based at least in part on the first version of the software component and the second version of the software component. 2 . The method of claim 1 , further comprising: completing execution of the first set of requests at the first version of the software component; and deleting the first version of the software component from the container based at least in part on completing the execution of the first set of requests. 3 . The method of claim 1 , further comprising: executing the second set of requests at the second version of the software component based at least in part on the routing. 4 . The method of claim 3 , wherein the software component is associated with a software application, the method further comprising: running the software application, wherein executing the first set of requests at the first version of the software component and executing the second set of requests at the second version of the software component are based at least in part on running the software application. 5 . The method of claim 4 , further comprising: performing a patching operation based at least in part on receiving the software patch, wherein the patching operation comprises deploying the second version of the software component to the container and deleting the first version of the software component from the container; and maintaining a connection for running the software application, a data flow for running the software application, or both throughout the patching operation. 6 . The method of claim 5 , further comprising: communicating with a plurality of user devices operated by a plurality of users based at least in part on running the software application, wherein the patching operation is performed transparent to the plurality of users. 7 . The method of claim 3 , wherein at least a second portion of the first set of requests is executed at the first version of the software component concurrent to at least a portion of the second set of requests being executed at the second version of the software component. 8 . The method of claim 1 , wherein deploying the second version of the software component comprises: replicating the in-memory state of the software component from the first version of the software component to the second version of the software component. 9 . The method of claim 1 , wherein updating the in-memory state of the software component further comprises: implementing a protocol to manage the in-memory state of the software component. 10 . The method of claim 9 , wherein updating the in-memory state of the software component further comprises: receiving, at the container, first execution information for the first version of the software component and second execution information for the second version of the software component; aggregating the first execution information and the second execution information according to the protocol; and updating the in-memory state of the software component based at least in part on the aggregating. 11 . The method of claim 1 , further comprising: managing, at the container, a set of resources for the software component, the set of resources comprising the in-memory state of the software component. 12 . The method of claim 11 , wherein the first version of the software component and the second version of the software component access the set of resources from the container to execute the first set of requests and the second set of requests. 13 . The method of claim 1 , further comprising: intercepting, at a mediator associated with a plurality of software components, a request indicating the software component; and routing the request to the container comprising the software component based at least in part on the request indicating the software component. 14 . The method of claim 13 , further comprising: maintaining, at the mediator, a plurality of connections with the plurality of software components via a plurality of application programming interfaces. 15 . The method of claim 1 , wherein the second set of requests is routed to the second version of the software component via an application programming interface. 16 . An apparatus for managing software updates, comprising: a processor; memory coupled with the processor; and instructions stored in the memory and executable by the processor to cause the apparatus to: execute a first set of requests at a first version of a software component deployed to a container, wherein the software component comprises a stateful component, and wherein executing the first set of requests changes an in-memory state of the software component managed by the container based at least in part on the software component comprising the stateful component; receive, from a user device, a software patch comprising a second version of the software component; deploy the second version of the software component to the container based at least in part on the software patch and concurrent with executing at least a first portion of the first set of requests at the first version of the software component; route a second set of requests to the second version of the software component based at least in part on the deploying; and update, at the container, the in-memory state of the software component based at least in part on the first version of the software component and the second version of the software component. 17 . The apparatus of claim 16 , wherein the instructions are further executable by the processor to cause the apparatus to: complete execution of the first set of requests at the first version of the software component; and delete the first version of the software component from the container based at least in part on completing the execution of the first set of requests. 18 . A non-transitory computer-readable medium storing code for managing software updates, the code comprising instructions executable by a processor to: execute a first set of requests at a first version of a software component deployed to a container, wherein the software component comprises a stateful component, and wherein executing the first set of requests changes an in-memory state of the software component managed by the container based at least in part on the software component comprising the stateful component; receive, from a user device, a software patch comprising a second version of the software component; deploy the second version of the software component to the container based at least in part on the software patch and concurrent with executing at least a first p
Version control (security arrangements therefor G06F21/57); Configuration management · CPC title
Updates (security arrangements therefor G06F21/57) · CPC title
involving the movement of software or configuration parameters (network booting or remote initial program loading [RIPL] G06F9/4416) · CPC title
Installation · CPC title
Related publications grouped by family.
Answers are generated from the same data shown on this page.