Key Takeaways:
- The patent-versus-trade-secret choice turns on detectability. Patent what is observable in products, publications, or standards, and consider trade secret for contributions hidden in non-observable model internals. The two can be layered.
- Subject-matter eligibility under 35 U.S.C. § 101 depends on framing the invention as a concrete technical improvement or practical application, not a desired result or business outcome.
- Recite specific technical features (model architecture, processing steps, data handling, and special-purpose hardware) as an ordered combination of input, processing, and output limitations.
- Draft for enforcement. Keep each independent claim performable by a single actor and tied to observable activity, and separate training claims from inference claims.
- Support the claims with a specification that defines AI/ML terms, describes the model at multiple levels with objective performance results, and avoids “black box” disclosure. Build fallback positions into dependent claims.
Artificial intelligence (AI) generally refers to computer systems that perform tasks ordinarily requiring human-like perception, reasoning, prediction, classification, language understanding, planning, or decision-making. Modern AI typically involves machine-learning (ML) models trained on data rather than hand-coded rules, including neural networks (such as convolutional and recurrent networks) and transformer-based models like many large language models. Commercial systems often add software “wrappers” around the underlying model, including prompt logic, retrieval tools, guardrails, and user interfaces. Although AI/ML inventions can raise unique issues because of their complexity and nontransparency, the patentability analysis rests on the same framework applied to software inventions. That framework includes subject-matter eligibility, novelty, non-obviousness, written description, and enablement. The considerations below, many familiar from software practice, apply with equal force to AI/ML.
Patent or Trade Secret? Weighing Disclosure Against Detectability
When choosing between patent and trade secret protection, detectability is a key consideration. A patent is only as valuable as the ability to detect infringement. Many AI/ML inventions reside in software, and often in model parameters that are not readily discernible. This makes infringement hard to observe and the patent harder to enforce. Where the innovation is observable at inference or likely to surface through products, publications, marketing, reverse engineering, or a technical standard, a patent is the stronger choice. Where the contribution lives entirely in the hidden internals of a SaaS-delivered model that cannot practically be reverse-engineered, a trade secret may better preserve value.
Each regime has inherent limits. A patent excludes others (including independent developers and lawful reverse engineers) but requires an enabling public disclosure under 35 U.S.C. § 112 that forecloses trade-secret protection for whatever is disclosed. Protections lasts for only about twenty years from filing. A trade secret can endure indefinitely and requires no disclosure, but guards only against misappropriation. No recourse is offered against independent development or lawful reverse engineering, and its value can vanish once the secret is exposed. Timing also matters. A party’s own secret commercial use can eventually bar a later patent, so the decision cannot be deferred indefinitely.
The choice is not strictly binary. A single system can support a layered strategy with observable, claimable features (e.g., model architectures, system interfaces, and inference-time behavior), while maintaining genuinely concealed assets (e.g., curated training datasets, labeling and preprocessing pipelines, fine-tuning procedures, and specific weights or hyperparameters) as trade secrets.
Strategies for Patent Claim Drafting
As with computer-implemented inventions generally, AI/ML claims can be vulnerable under 35 U.S.C. § 101 to characterization as unpatentable abstract ideas. That risk can be reduced by avoiding broad functional language that merely recites a desired result and instead tying the claimed technology to a technical improvement or other practical application.
1. Avoid language characterizing the model, or its use, as an abstract idea. Refrain from reciting steps that sound like mental processes (e.g., predict, observe, evaluate), explicit mathematical formulas, and terms directed to business or legal subject matter (e.g., contracts, advertising, sales). Such language invites scrutiny under § 101. Claims reciting known or conventional models for business or other non-technical outcomes are especially vulnerable and may also fail to distinguish over prior art.
Contact Us Today:
2. Integrate the model into “a practical application.” A practical application is a specific implementation that may (i) produce a technical improvement to AI/ML technology, (ii) solve a technical problem using AI/ML technology, or (iii) produce a technical improvement to other existing technology using AI/ML technology. Framing claims around how an existing technology (or the model itself) is technologically improved may position the invention as a technological advance satisfying § 101. Examples include
- improving model accuracy,
- reducing model size, parameters, or layers,
- reducing training data,
- improving training or inference speed, or
- optimizing hardware use.
Where the invention lies in the use of the model, structure the claims around a stated technical problem, the solution using the model, and a concrete technical action resulting from the model’s output (e.g., controlling a medical device, guiding a surgical robot, operating an autonomous vehicle). Claims are weaker when they merely collect information, apply a model, and display a recommendation.
3. Do not claim the desired outcome alone. Claims must particularly point out and distinctly claim the invention under 35 U.S.C. § 112. Definiteness problems arise from broad functional language and vague “black box” terms. A claim reciting “an AI module configured to predict an outcome,” for instance, invites questions about which components or steps perform the recited function. A claim should instead specify the technical features that solve the technical problem or produce the improvement, such as
- architectural components (e.g., neural networks, transformer-based models),
- steps tied to those components (e.g., encoding/decoding, embedding, convolution), and
- special-purpose hardware (e.g., GPUs, TPUs) outside a generic computing environment.
These features are best claimed as an ordered combination of concrete input, processing, and output limitations, rather than disconnected generic elements. For a training invention, the claims may specify how data is selected, labeled, filtered, transformed, augmented, or weighted, and the components that do so. For runtime operation, they may specify the input data received, any preprocessing or feature extraction, the AI processing performed, and the technical output or action produced. Such limitations define the invention with greater specificity and reduce the risk that it reads as an abstract idea, a black box, or a functional result.
4. Draft with enforceability and divided infringement in mind. Even an eligible, well-supported claim has limited value if infringement cannot be detected or attributed to one actor. The AI value chain is often distributed. One party assembles data and trains the model, another hosts or deploys it, and an end user supplies inputs and obtains outputs. A method claim whose steps span these parties can be hard to enforce under divided-infringement rules. Where possible, each independent claim should be written so that a single actor performs all steps, with such steps being directed to activity observable or inferable from the accused product or service. Separating training claims from inference claims, and aligning each with the party that performs it, keeps the patent both enforceable and detectable.
5. Build fallback positions into dependent claims. Dependent claims should recite narrower implementations (e.g., specific model types, training parameters, preprocessing techniques, hardware configurations, thresholds, feedback loops, confidence scoring, validation steps, or technical outputs) to preserve scope during prosecution and supply alternatives if broader claims face eligibility, prior-art, written-description, or enablement challenges under 35 U.S.C. § 112.
Strategies for Drafting the Specification
Like other computer-implemented inventions, a strong AI/ML specification is built around the technical contribution, not the business value of the output. It must support eligibility under 35 U.S.C. § 101 and satisfy the disclosure requirements of 35 U.S.C. § 112 by describing the invention concretely enough to read as a technical improvement rather than an abstract idea.
1. Define AI/ML terms technically. Because claim terms are read in light of the specification, define the technical features recited in the claims, particularly terms and steps lacking a recognized meaning in the field. Provide technical definitions for words such as predict, identify, observe, evaluate, and encode that differentiate them from mental processes.
2. Avoid describing the model as a “black box.” A thin disclosure can create eligibility, written-description, and enablement problems. The invention may look like an abstract idea implemented with generic tools, and the specification may fail to show possession or to enable a skilled person to make and use it without undue experimentation. Instead, describe model structure, inputs, outputs, training and inference processes, data preparation, and performance metrics with enough specificity to support the claims’ breadth, ideally at multiple levels (e.g., high-level structures, intermediate architectures and algorithmic steps, and detailed features as needed). Describe the data pipeline (e.g., what data is collected, how it is used to train the model, and how the trained model processes new data), and include objective results where possible (e.g., accuracy, precision, recall, latency, memory use, robustness), which support eligibility, enablement, and non-obviousness alike.
3. Frame the invention as a technical improvement to a technical problem. Describe how the improvement is achieved and why the approach performs better, rather than claiming a desired result such as “a more accurate model.” Identifying the technical challenge, any unexpected development problems, and the inadequacy of conventional approaches can support both eligibility and prior-art distinctions. Although the USPTO does not require an applicant to recite the improvement in a conclusory statement, the specification must provide enough detail for a person of ordinary skill in the art to recognize it. Bare assertions of improvement are weaker than, if not insufficient compared to, an explanation of how the system achieves it.
Conclusion
Protecting AI/ML innovations calls for the same disciplined analysis as other software inventions, with attention to a few recurring pressure points. The threshold question is detectability. Where infringement would be observable in a product, publication, or standard, a patent is generally preferable. Where the contribution resides only in non-observable internals, a trade secret may serve better. Where patenting is chosen, eligibility under 35 U.S.C. § 101 turns on framing the invention as a concrete technical improvement or practical application, supported by claims reciting specific technical features (e.g., architecture, processing steps, data handling, and hardware). The specification must then supply enough technical detail to support those claims under 35 U.S.C. § 112 and avoid the appearance of a “black box.” The claims should also be drafted for real-world enforcement, performable and observable by a single actor, with dependent claims preserving fallback scope.
For in-house counsel and technology leaders, the practical takeaway is to engage patent counsel early, while the architecture and development record are still taking shape, so that the technical narrative, the disclosure, and the claims can be aligned before filing. Approached in this way, an AI/ML patent strategy is far more likely to yield enforceable, defensible protection commensurate with the organization’s investment in the underlying technology.
