Analytical Software Patch Management
US-2016103671-A1 · Apr 14, 2016 · US
US9710253B2 · US · B2
| Field | Value |
|---|---|
| Publication number | US-9710253-B2 |
| Application number | US-201514742566-A |
| Country | US |
| Kind code | B2 |
| Filing date | Jun 17, 2015 |
| Priority date | Apr 16, 2015 |
| Publication date | Jul 18, 2017 |
| Grant date | Jul 18, 2017 |
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.
Queued software patches are analyzed before one patch is chosen as the next patch to be integrated into a working build. The chosen patch might not be next in chronological order of arrival at the queue. Instead, an illustrative build server applies a number of priority factors to every patch awaiting integration in the patch queue, specifically by analyzing one or more relevant attributes of the patch. The patch that receives the highest priority score in the course of the evaluation is then extracted for integration. After the patch has been integrated, the build server (e.g., using an illustrative patch queue manager module) circles back and again evaluates all the patches in the current queue, which may have queued new patches that were submitted while the previous patch was being integrated. Relative to a default chronological order, a given patch may receive a boost in priority or, conversely, may have its priority reduced.
Opening claim text (preview).
What is claimed is: 1. A computer-implemented method for managing software patch submissions for integration into a working build, the method comprising executing on a first computing device the steps of: receiving, by the first computing device, a plurality of software patches from one or more second computing devices, wherein each software patch comprises one or more executable software files and is submitted for integration into a first set of executable software files that collectively defines a working build; queueing, by the first computing device, the plurality of submitted software patches into a queue; assigning, by the first computing device, to each software patch in the queue, a respective priority score based on at least one of: (a) a geographical location where the respective software patch was submitted to the queue for integration into the working build, (b) a time of day at a geographical location where the respective software patch was submitted to the queue for integration into the working build, (c) an indication that the respective software patch fixes a problem of an earlier software patch that failed integration into the working build, (d) an indication that the respective software patch previously had its priority score lowered due to a failed dependency on an antecedent software patch and which dependency is currently satisfied, (e) an indication that the respective software patch was successfully tested with one or more customers before being submitted to the queue for integration into the working build, (f) whether the respective software patch was submitted to the queue after a predefined deadline, and (g) whether the respective software patch was submitted by a user who has at least one other software patch assigned to a failed-patch pool; selecting, by the first computing device, a first software patch from the queue as a next software patch to be integrated into the working build, wherein the first software patch has a highest priority score among the software patches in the queue, and wherein another software patch arrived at the queue before the first software patch; integrating the first software patch into the working build, resulting in an updated working build that comprises a functionality of the first software patch; and wherein the respective priority score of a given software patch is lowered when the given software patch was submitted by a user who has at least one other software patch assigned to the failed-patch pool. 2. A computer-implemented method for managing software patch submissions for integration into a working build, the method comprising executing on a first computing device the steps of: receiving, by the first computing device, a plurality of software patches from one or more second computing devices, wherein each software patch comprises one or more executable software files and is submitted for integration into a first set of executable software files that collectively defines a working build; queueing, by the first computing device, the plurality of submitted software patches into a queue; assigning, by the first computing device, to each software patch in the queue, a respective priority score based on at least one of: (a) a geographical location where the respective software patch was submitted to the queue for integration into the working build, (b) a time of day at a geographical location where the respective software patch was submitted to the queue for integration into the working build, (c) an indication that the respective software patch fixes a problem of an earlier software patch that failed integration into the working build, (d) an indication that the respective software patch previously had its priority score lowered due to a failed dependency on an antecedent software patch and which dependency is currently satisfied, (e) an indication that the respective software patch was successfully tested with one or more customers before being submitted to the queue for integration into the working build, (f) whether the respective software patch was submitted to the queue after a predefined deadline, and (g) whether the respective software patch was submitted by a user who has at least one other software patch assigned to a failed-patch pool; selecting, by the first computing device, a first software patch from the queue as a next software patch to be integrated into the working build, wherein the first software patch has a highest priority score among the software patches in the queue, and wherein another software patch arrived at the queue before the first software patch; integrating the first software patch into the working build, resulting in an updated working build that comprises a functionality of the first software patch; and wherein the respective priority score of a given software patch is raised when a first geographical location where the given software patch was submitted is below a predefined geographical difference relative to a second geographical location where the working build is integrated, and the respective priority score of the given software patch is lowered when the first geographical location where the given software patch was submitted is more than the predefined geographical difference relative to the second geographical location where the working build is integrated. 3. A computer-implemented method for managing software patch submissions for integration into a working build, the method comprising executing on a first computing device the steps of: receiving, by the first computing device, a plurality of software patches from one or more second computing devices, wherein each software patch comprises one or more executable software files and is submitted for integration into a first set of executable software files that collectively defines a working build; queueing, by the first computing device, the plurality of submitted software patches into a queue; assigning, by the first computing device, to each software patch in the queue, a respective priority score based on at least one of: (a) a geographical location where the respective software patch was submitted to the queue for integration into the working build, (b) a time of day at a geographical location where the respective software patch was submitted to the queue for integration into the working build, (c) an indication that the respective software patch fixes a problem of an earlier software patch that failed integration into the working build, (d) an indication that the respective software patch previously had its priority score lowered due to a failed dependency on an antecedent software patch and which dependency is currently satisfied, (e) an indication that the respective software patch was successfully tested with one or more customers before being submitted to the queue for integration into the working build, (f) whether the respective software patch was submitted to the queue after a predefined deadline, and (g) whether the respective software patch was submitted by a user who has at least one other software patch assigned to a failed-patch pool; selecting, by the first computing device, a first software patch from the queue as a next software patch to be integrated into the working build, wherein the first software patch has a highest priority score among the software patches in the queue, and wherein another software patch arrived at the queue before the first software patch; integrating the first software patch into the working build, resulting in an updated working build that comprises a functionality of the first software patch; and wherein the respective priority score of a given software patch is raised when a first time of day at a first geographical location where the given software patch was submitted is below a predefined ti
Updates (security arrangements therefor G06F21/57) · CPC title
Related publications grouped by family.
Answers are generated from the same data shown on this page.