The part of NVIDIA (NVDA) that gets discussed is the silicon — the accelerator, the transistor count, the memory bandwidth. The part that determines whether that silicon earns its keep is less visible: the software that decides what the GPU does next, in what order, and whether it ever sits idle waiting on a dependency. In the week ending 11 May 2026, NVIDIA had a run of patents issue that sits squarely on that second layer. A granted claim is enforceable coverage, not an aspiration, so this cluster is a map of positions NVIDIA has locked in around the execution and orchestration of work on its hardware — the layer between a developer's program and the chip actually running it.

The center of the cluster is the execution graph — the structure CUDA uses to represent a sequence of GPU operations and their dependencies, so the whole batch can be launched with low overhead rather than one call at a time. US12619868B2 covers combining independent operations in such a graph; its abstract states the mechanism plainly:

In at least one embodiment, a processor causes two or more operations in a graph to be combined based, at least in part, on another combination of two or more independent operations.— Techniques for combining independent operations in a graph structure, US12619868B2

Fusing operations and cutting per-call overhead is a direct lever on utilization: a GPU that spends fewer cycles on launch and scheduling overhead spends more on compute. That is the unit economics of an accelerator a customer is paying for by the hour.

A cluster around keeping the accelerator busy

The rest of the set rounds out the same orchestration theme from adjacent angles. US12619480B2 covers an application programming interface that adds nodes to a software graph while storing an indication of whether a node ran, based on a dependency type the API specifies — a way of expressing event dependencies between pieces of work. US12619477B2 covers an API that causes graph code to wait on a semaphore used by another API, the synchronization primitive that lets independently scheduled streams of work coordinate without stalling the whole device. And US12619464B2 covers program-flow monitoring and control of an event-triggered system, where operational units are organized into a flow and a manager exchanges communications with nodes to track when each event completes. Read together, these are claims on the plumbing of dependency-aware scheduling — how a complex workload gets decomposed into nodes, sequenced, synchronized, and watched.

There is a coherent commercial logic to why NVIDIA, specifically, would amass coverage at this layer. Its competitive position rests not only on the accelerator but on CUDA — the software stack developers target — and the orchestration primitives are where that stack turns raw silicon into throughput. Two more grants extend the footprint into the data pipeline and the model layer: US12619878B2 covers a master-transform architecture that combines a sequence of data transforms into master transforms run on parallel processing units to prepare data for training, and US12620139B1 covers neural-network-based image segmentation. The pipeline grant matters because feeding the accelerator is itself a bottleneck — a GPU starved of prepared data is as idle as one stalled on a dependency.

It is worth being precise about what "orchestration" buys, because the business significance is downstream of a technical fact. A modern AI workload is not one monolithic kernel; it is thousands of small operations with dependencies between them, and the time the hardware spends launching, sequencing, and synchronizing those operations is time it is not computing. Each of the four central grants attacks a different part of that overhead: US12619868B2 reduces the number of operations by combining them, US12619480B2 records and reasons about which operations depend on which, US12619477B2 coordinates separately scheduled work through a semaphore rather than forcing a full-device stall, and US12619464B2 tracks the flow so a manager knows when each unit has finished. The common thread is that none of them touches the math the GPU performs; they govern the scaffolding around it. For an installed base of accelerators, that scaffolding is the difference between a chip that is nominally fast and a chip that is actually utilized — and utilization, not peak throughput, is what a buyer renting compute pays against.

The facilities layer, and the limits

The same week also produced grants on the physical side of running accelerators at scale. US12621964B2 covers interchangeable, coolant-calibrated in-rack coolant distribution units, and US12621963B2 covers server air cross-transfer blanking for datacenter cooling. These sit alongside the orchestration grants as coverage on the facilities that house dense GPU racks — the cooling that determines how many accelerators fit in a rack and how hard they can run. For a vendor whose customers are building out GPU data centers, coverage on rack-level thermal management is coverage on the same buildout its silicon revenue depends on.

The limits are the standard ones for a grant cluster. Enforceable coverage is not a deployed feature or a disclosed revenue line — these patents describe methods and systems, and the records do not state how widely NVIDIA uses each one or what it earns from them. Execution-graph scheduling, synchronization primitives, and liquid cooling are also actively worked across the industry, so coverage on a particular technique does not foreclose alternatives. And single-week patent counts swing with examiner timing, so the cluster is best read as a snapshot of a sustained investment rather than a sudden shift. What the week shows as fact is specific and consistent: in the same seven days, NVIDIA had grants issue across execution-graph operation combining, API-level dependency and semaphore control, program-flow monitoring, training-data transformation, and rack cooling — a coordinated footprint on the orchestration and facilities layers that sit above and around the accelerator, which is where a chip becomes utilized capacity.