IBM · Filed Jan 9, 2025 · Published Jul 9, 2026 · verified — real USPTO data

IBM Patents a System That Skips Broken Layers When Rebuilding Crashed Software Programs

When a software update breaks a cloud application, figuring out exactly which piece is corrupted, and which other pieces depend on it, is a genuinely painful process. IBM is patenting a way to automate that detective work.

IBM Patent: Auto-Recovery for Broken Container Image Layers — figure from US 2026/0195211 A1
Figure from the official USPTO publication.
See all 11 drawings from this filing ↓
Publication number US 2026/0195211 A1
Applicant INTERNATIONAL BUSINESS MACHINES CORPORATION
Filing date Jan 9, 2025
Publication date Jul 9, 2026
Inventors Xiao Ling Chen, Heng Wang, Zhan Peng Huo, Yu Zui You
CPC classification 717/173
Grant likelihood Medium
Examiner CENTRAL, DOCKET (Art Unit OPAP)
Status Docketed New Case - Ready for Examination (Feb 25, 2025)
Document 20 claims

What IBM's container layer recovery actually does

Think of a cloud application like a stack of building blocks, where each block sits on top of others. Modern apps are often shipped as "containers" made up of these stacked layers. If one layer gets a bad software update, anything built on top of it can also break, even if those upper layers look perfectly fine on their own.

IBM's patent describes a system that watches for these bad updates and automatically labels the broken layer in a central storage location (called an image repository). It also traces which other layers are built on top of the broken one, whether directly or through a chain of dependencies, and labels those too.

When it's time to restore the application, the system knows to skip all those flagged layers and pull only the clean ones. Instead of an engineer manually hunting down every affected piece, the recovery process happens with the bad parts already identified and excluded.

How the repository flags and skips bad dependencies

The patent covers a method for recovering software containers when one of their component image layers receives a faulty patch (a software update that introduces an error).

The core steps are:

  • The system identifies a specific image layer as containing a patch in error.
  • It marks that layer at the image repository (the central store where container layers are kept and distributed), so every system talking to that repository knows the layer is problematic.
  • It then traces the dependency graph (a map of which layers rely on which other layers), identifying layers with either a direct dependency (immediately built on the broken layer) or an indirect dependency (built on something that is itself built on the broken layer, one or more steps removed).
  • Those dependent layers are also flagged at the repository.
  • When container recovery begins, the system pulls only the clean, unflagged layers from the repository, skipping the broken layer and all its dependents entirely.

The distinction between direct and indirect dependencies is the most technically interesting part. A broken layer doesn't just affect what's immediately on top of it; it can corrupt a whole chain of layers downstream. The patent explicitly handles both cases.

What this means for cloud app reliability and downtime

Container-based software, the kind that powers most modern cloud services, is notoriously tricky to repair when an update goes wrong. Today, engineering teams often have to manually trace which parts of an application are affected by a bad patch before they can safely restore service. That takes time, and time is downtime.

By moving the dependency tracking and flagging to the image repository itself rather than leaving it to individual teams, IBM's approach means the knowledge of what's broken is shared automatically across any system that uses that repository. For companies running dozens or hundreds of containerized applications, that could mean the difference between a five-minute automated recovery and a multi-hour incident.

Editorial take

This is practical, unglamorous infrastructure work, but it addresses a real pain point in how cloud software gets repaired after bad updates. IBM has deep roots in enterprise software reliability, and a patent like this fits squarely into their cloud and hybrid-infrastructure business. It's not a headline-grabber, but the kind of thing that earns its keep in production environments.

The drawings

11 drawing sheets from US 2026/0195211 A1 · click any drawing to enlarge

Patent filing page

Which company should we read for you?

We track 17 companies here. Pro is the same weekly breakdown for any company you choose, delivered privately. Type a name and we'll scope it and send you a quote.

Get one Big Tech patent every Sunday

Plain English, intelligent commentary, no hype. Free.

Source. Full patent text and figures from the official USPTO publication PDF.

Editorial commentary on a publicly published patent application. Not legal advice.