Software Patch LKG Cache for Binary Selection

Resolve Bottlenecks,
Find Innovative Solutions
Generate Solutions

Solution Overview

Problem

Existing software patch systems are inefficient due to lengthy release times, quality risks, and unnecessary testing and download costs, as they include unnecessary binary changes and require thorough testing of all binaries in a patch, even if only a few are new.

Innovation Solution

Implementing a last known good (LKG) method that uses file caches for previously tested binaries, prioritizing the GDR cache over the SP cache, and synchronizing dependency databases to selectively include only necessary binaries in patches, reducing testing and deployment time and costs.

Engineering Contradictions & Design Principles

VSEngineering Contradiction Analysis

1Reliability

If all binaries are included in the patch package, then completeness of the patch is improved, but the patch size and download cost increase

Engineering Contradiction:
Improvecompleteness of the patchVSAvoidpatch size
Core Design Contradiction:
ReliabilityVSQuantity of substance

Solution Approach 1:

The patent extracts only the necessary binaries from the complete set of binaries. By comparing the dependency information with the binaries available in the LKG cache, the system identifies and includes only those binaries that are actually needed for the fix, excluding redundant ones from the patch package.

Inventive Principle:
Principle #2Taking out (Extraction)

Solution Approach 2:

The patent segments the patch package into two parts: binaries that need to be updated (new or modified) and binaries that can remain at their last known good version. This segmentation allows the system to include only the necessary updated binaries in the patch while excluding binaries that don't need changes.

Inventive Principle:
Principle #1Segmentation

2Reliability

If all binaries are tested before release, then quality assurance is improved, but the testing time increases

Engineering Contradiction:
Improvequality assuranceVSAvoidtesting time
Core Design Contradiction:
ReliabilityVSLoss of time

Solution Approach 1:

The patent extracts only the binaries that actually need testing from the complete set of binaries in the patch. By using dependency information to identify which binaries are new or modified, the system tests only those specific binaries rather than all binaries in the package, significantly reducing testing time while maintaining quality assurance.

Inventive Principle:
Principle #2Taking out (Extraction)

3Adaptability or versatility

If dependent binaries are included in the patch, then functionality is improved, but unnecessary changes and testing requirements increase

Engineering Contradiction:
ImprovefunctionalityVSAvoidtesting time
Core Design Contradiction:
Adaptability or versatilityVSLoss of time

Solution Approach 1:

The patent extracts only the necessary dependent binaries from the complete set of dependent binaries. By comparing dependency requirements with the LKG cache contents, the system identifies which dependent binaries are already in a good state and can be excluded from the patch, including only those that actually need to be updated.

Inventive Principle:
Principle #2Taking out (Extraction)

Data Source

PatentUS7689972B2System and method for producing software patches
Publication Date: 2010.03.30 MICROSOFT TECHNOLOGY LICENSING LLC
  • US7689972B2 patent drawing
  • US7689972B2 patent drawing
  • US7689972B2 patent drawing

AI summary

A system and method for last known good (LKG) for patches. A file cache is created to store binaries which have shipped as part of a previous wide public release—security fixes (GDRs) and service packs. There are two levels of cache, including an SP cache which keeps all of the files which were shipped as part of the service pack, and a GDR cache which keeps all of the files shipped in the GDRs. Customers do not need to download all of the binaries contained in a package when they already have the version of the dependent binaries on their system when they get the new patch. Customers only need to test the binaries which have changed, rather than everything in the new package, which speeds up the deployment of critical patches.