IBM · Filed Nov 25, 2024 · Published May 28, 2026 · verified — real USPTO data

Red Hat Patents a System That Toggles OS Features Based on Energy Use

Red Hat wants Linux to know when it's running low on power — and automatically shut off OS components that aren't worth the energy cost right now.

Red Hat Patent: Energy-Aware OS Component Toggling — figure from US 2026/0147401 A1
FIG. 1A — rendered from the official USPTO publication PDF.
Publication number US 2026/0147401 A1
Applicant Red Hat, Inc.
Filing date Nov 25, 2024
Publication date May 28, 2026
Inventors Leigh Griffin, Leonardo Rossetti
CPC classification 713/323
Grant likelihood Medium
Examiner MURSHID, AFRINA (Art Unit 2176)
Status Docketed New Case - Ready for Examination (Jan 3, 2025)
Document 20 claims

What Red Hat's energy-aware OS switching actually does

Imagine your laptop is running on a nearly dead battery, but the operating system keeps a bunch of background services humming along as if nothing's changed. Red Hat's patent is about fixing exactly that, not just for laptops, but for servers, edge devices, and any Linux-based system where energy availability fluctuates.

The idea is to give the OS a kind of energy budget dashboard. It builds two maps: one that tracks what each OS component costs to run (based on its code and call patterns), and another that tracks what's actually running and how much power is available right now. When those two pictures line up unfavorably, the system can automatically deactivate components that aren't pulling their weight.

For you as a user or a sysadmin, this could mean a server that gracefully sheds non-essential OS features during a power constraint — without you having to manually tune anything.

How the two maps drive activate/deactivate decisions

The patent describes a two-map architecture for making real-time energy decisions at the OS level.

Map one is built by analyzing source code to produce a function call tree (a graph showing which functions call which other functions during execution) for each OS component, combined with historical or measured energy usage data for the host device. This gives the system a cost model: here's roughly how much power this component consumes when it runs.

Map two is a live snapshot — it captures what applications are currently active, what component loads are running, and crucially, what energy is actually available on the host right now. Think of it as the "current state" view versus map one's "unit cost" view.

A processing device then compares the two maps against available energy and decides whether to activate or deactivate specific OS components. The decision logic sits at the intersection of: what does this component cost, what else is competing for power, and how much power do we have left?

This is essentially a policy engine for OS-level power management, operating at a finer granularity than typical CPU frequency scaling or suspend states.

What this means for Linux servers and edge devices

Most power management in operating systems today works at the hardware layer — throttling CPU speed, spinning down disks, cutting display brightness. Red Hat's approach goes a level higher, making the OS itself a participant in energy budgeting by toggling its own components. For edge computing deployments, IoT devices, or data centers running on renewable energy with variable availability, that's a meaningful distinction.

Red Hat owns RHEL and contributes heavily to the Linux kernel, so a patent in this space isn't theoretical. If this approach made it into production tooling, it would give operators a new lever for managing workloads under power constraints — something increasingly relevant as energy costs and sustainability reporting become real pressures for enterprise IT.

Editorial take

This is quiet, unglamorous infrastructure work — the kind Red Hat actually ships. The two-map model is a thoughtful way to separate static cost modeling from dynamic runtime state, and the problem it solves (OS-level energy granularity) is real and underserved. It won't generate headlines, but it's exactly the kind of systems-level thinking that ends up in RHEL a few years later.

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.