Twelve patent applications assigned to Microsoft Technology Licensing, LLC were published on July 16, 2026. Seven of them touch artificial intelligence or machine learning. Read the titles in isolation and they scatter — protein chemistry, feed ranking, audience prediction. Read three of them together and a theme surfaces that is worth an analyst's attention: the cost of running a model, as distinct from the cost of building one.

The clearest of the three is US20260203368A1, titled "METHODS FOR LOOKUP TABLE-BASED MIXED-PRECISION MATRIX MULTIPLICATION." It is a published application — kind code A1, meaning a pending filing, not an issued grant — classified under CPC G06F 17/16 and G06F 1/03, and it names four inventors: Mao Yang, Shijie Cao, Ting Cao, and Lingxiao Ma. The record contains 20 claims, with independent claims at 1 (a method), 10 (a computing system), and 18 (a computing system with a bit-serial lookup-table unit).

The problem it addresses is narrow and expensive. When a large language model is squeezed onto a phone or a laptop, its weights are quantized down to very low precision while its activations stay higher. Multiplying those two together is mixed-precision matrix multiplication, and general-purpose CPUs have no native instruction for it. The conventional workaround is to expand the low-bit weights back up to a precision the hardware understands and then multiply normally — paying, in effect, for precision that was deliberately discarded. Per the abstract, the application instead decomposes "an n-bit weight matrix into a series of n one-bit matrices," generates "a lookup table of partial matrix multiplication results" from permutations of activation groups against those one-bit matrices, and then uses "g-bit groups of the input weight matrix as indices" to retrieve precomputed partials and aggregate them. Multiplication becomes lookup plus addition.

The inventive weight, according to the description, is not the lookup idea itself — the filing is explicit that lookup-table approaches were tried before, including on GPUs, where the description states practical kernel performance came out worse than dequantization-based kernels because of storage and access-speed constraints. What the application pursues is keeping the table in the fastest memory available. Dependent claim 2 puts the lookup table "in a register of a central processing unit." The description names existing SIMD shuffle instructions — TBL on ARM, PSHUF on x86 — as the retrieval mechanism. Independent claim 18 goes further and claims a CPU containing "at least one LUT unit with bit-serial circuit architecture" comprising N×M multiplexing units, which is claimed subject matter rather than described silicon.

This allows for the deployment of LLMs on edge devices using widely available CPUs and without relying on GPUs and without compromising computational efficiency.— METHODS FOR LOOKUP TABLE-BASED MIXED-PRECISION MATRIX MULTIPLICATION, US20260203368A1

That sentence is the application's own framing, and it is worth reading for what it does not say. It is scoped to edge deployment on commodity CPUs. It is not a statement about datacenter accelerators, and the record's GPU discussion is a technical postmortem on why earlier lookup kernels underperformed — not a market position. The filing contains no performance figures of any kind: no speedup, no latency, no tokens per second, no memory or power number. The quantitative content is structural. A FIG. 4 worked example groups four activations into a 16-entry table. A FIG. 3 comparison counts 144 eight-bit registers for the lookup method against 104 for llama.cpp — and that is a cost the description then works to mitigate, not a result to celebrate. The record does reference T-MAC and llama.cpp by name, noting a possible conflict between the llama.cpp threadpool and the TVM threadpool when integrating T-MAC. That is implementation discussion inside a specification, not evidence of a shipped integration.

Three levers, one problem

The reason this filing reads differently in company with its siblings is that two other Microsoft applications published the same day arrive at inference cost from different directions. US20260203643A1, "Inference Acceleration of a Model using an In-Place Mixture-of-Experts," describes converting an already-trained model into a mixture-of-experts in place — identifying subnetworks, adding a router that scores on hidden state and subnetwork saliency, and fine-tuning — rather than training an MoE from scratch. US20260203652A1, "Knowledge Distillation using Hybrid Loss Function for Different Sample Types," describes training a small student model from a large teacher using a contrastive loss that combines forward KL divergence on teacher samples with reverse KL on student samples. It shares four inventors with the in-place MoE application.

Line them up and they are three levers on the same lever arm: compute less per operation (lookup tables), activate less of the network per token (in-place MoE), or ship a smaller network altogether (distillation). None of the three requires new accelerator hardware to be useful — the lookup method targets CPUs already in the field, the MoE conversion targets a model that already exists, and distillation targets what gets deployed. That is the reading worth flagging. It is an observation about what published on one Thursday, framed from titles, abstracts, and claim text, and it is emphatically not a Microsoft statement of strategy. A filing is evidence that work happened, not evidence of a roadmap, and claims routinely narrow before anything issues.

What the rest of the day looks like

The remaining AI-adjacent publications lean toward serving and ranking rather than model efficiency. US20260203604A1, "ASYNCHRONOUS SERVING ARCHITECTURE FOR CUSTOMIZED CONTENT ITEMS," describes serving a cached item immediately while a generative-AI item is produced asynchronously and dropped into a slot that has not rendered yet — hiding generation latency rather than reducing it, which is a different answer to a related question. US20260203530A1 describes building a linked-entity database from search logs and injecting entity context into a prompt data structure. Further out, US20260204338A1 splits polypeptide sequences into overlapping three-amino-acid fragments to make quantum-mechanical protein property calculation tractable, with CPC coverage including G06N 10/80. The non-AI half of the day is infrastructure plumbing — a snoop filter with a disaggregated vector table, digital PLL calibration, die-to-die receiver sampling control, and US20260203099A1, which monitors local resource consumption and hands a running application off to a cloud machine. That last one sits in interesting company with the lookup-table filing: one application is about making a workload run where it already is, the other about moving it when it cannot. Both are pending. Neither is a product. What they are is a record of where engineering hours went — and on July 16, a disproportionate share of Microsoft's went toward making inference cheaper without buying anything new to run it on.