IPOS Raises the Drafting Bar for AI and Data Patent Claims
IPOS has used its supplemental AI patent guidance to make one point much harder to ignore: for AI and data-heavy inventions, the fight is often no longer about whether software-related subject matter can be patented in the abstract. It is about whether the claim and the specification show a real technical contribution tied to a specific problem, rather than a mathematical model dressed up with industry language.
That is why the latest clarification matters. The practical pressure is now falling on the parts of an application that many teams still treat too loosely: training-data processing, dataset improvement, post-training model adjustment, and the disclosure needed to show why those steps produce a technical result. If the claim reads like a generic algorithm, or like ordinary hardware merely running a model, the old “mathematical method” risk has not gone away. IPOS is effectively asking applicants to make the chain visible: what the model does, what inputs and outputs matter, what technical setting is being addressed, and what result follows from that design.
The real issue is not AI eligibility in general, but whether the claim is genuinely technical
Many AI patent drafts still begin with a familiar formula: identify a neural network, say it can be used for classification, control, prediction or optimisation, and assume that the application problem will do the rest. IPOS is signalling that this drafting style is increasingly fragile. The examiner is asked to construe the claim, identify its actual contribution, and then ask whether that contribution sits only within excluded subject matter such as a mathematical method, a business method or the presentation of information. That sequence matters. It means applicants do not get credit merely for putting AI terminology into the claim.
The weak point in many filings is functional language that remains too broad to show a specific technical problem. Saying that a model is used “to control a system” or “to manage risk” may sound practical, but it can still be read at a level too generic to escape abstraction. The stronger applications will be the ones that make the problem narrow enough to be technical, and make the claim steps visibly causally linked to solving it. That requires more than a field label. It requires a readable relationship between the claimed processing and the technical task being performed.
Training-data work is becoming central, but datasets cannot be claimed as mere information
One of the most useful parts of the IPOS guidance is that it does not treat training-data work as peripheral. It expressly recognises that protection may be sought where dataset features are claimed as part of a training method, or where the invention lies in generating or improving a dataset directed to a specific problem. That matters for generative AI, industrial modelling, medical prediction and identity-verification systems, where the inventive step often lies as much in data preparation, augmentation, filtering or synthesis as in the model architecture itself.
But IPOS also draws a clean boundary. A dataset characterised only by its informational content, or by how it is delivered, is still vulnerable to being treated as a mere presentation of information. That distinction is commercially important. Applicants cannot expect the phrase “training data” to do legal work by itself. They need to show how the dataset features function inside the technical process, how they shape training or inference, and why they help solve the identified problem. In practice, this pushes engineering detail forward. Data provenance, selection logic, labelling structure, augmentation design and use constraints can no longer be treated as background texture if they are doing the real patent work.
Fine-tuning and post-training adjustment claims need more than a promise of better accuracy
The guidance examples also suggest where post-training model claims will face pressure. In commercial language, applicants may talk about fine-tuning, adaptation, pruning, extension or optimisation. In patent language, those labels are not enough. If a claim simply says that a trained network is extended, reduced, reweighted or otherwise adjusted without anchoring that step to a concrete technical problem, the actual contribution may still be seen as no more than an algorithmic change in the abstract. “Improved model performance” is not a patent position if it floats free from a technical setting.
The safer route is to draft those model-adjustment steps back into a system-level context. Is the adjustment allowing a computational task to be executed more effectively on a processor with specific constraints? Is it improving prediction quality for a defined manufacturing parameter? Is it enabling earlier detection of a concrete medical event? Is it dealing with scarcity or imbalance in fraud-detection samples? Those are the kinds of links that make the claim read like a technical solution rather than a generic optimisation script. This is especially important for generative AI applications, where “fine-tuning” is often described as a broad capability. IPOS is effectively forcing applicants to explain why that adjustment mattered, what was technically changed, and what measurable system-level consequence followed.
The disclosure burden is moving earlier, and evidence planning has to move with it
IPOS states that where the claimed subject matter depends on particular characteristics of the training dataset, those characteristics must be disclosed unless they are readily apparent or can be determined without undue burden. That single point has large practical consequences. In many AI filings, vulnerability will now surface not only at inventive step but also at support and sufficiency. A specification that describes the model in broad outline while saying little about dataset features, selection criteria, training conditions or verification methodology may find itself exposed on several fronts at once.
That changes internal filing workflow. A common sequence has been for the R&D team to provide a model diagram and for the patent draft to layer in the application story later. For stronger AI filings, the better sequence is usually the reverse: define the technical problem first, map the dataset characteristics and processing steps that matter, identify evaluation metrics and baseline comparisons, and then decide what belongs in the independent claim and what must remain in the examples to support it. For applicants trying to reduce the risk of a mathematical-method objection, more concrete performance metrics, comparative experiments and system-level effect data are starting to look less like optional polish and more like the material that keeps the application standing.
The deeper significance of the IPOS update is not that Singapore has suddenly become hostile to AI patents. It is that it is leaving less room for hopeful drafting. Training-data handling, model adjustment and algorithm deployment all need to be written with more precision than before. The applicants that can clearly connect a specific technical problem to the claimed AI processing, the relevant dataset features and the resulting technical effect are the ones most likely to come through examination with fewer surprises.
