Australia | Patenting AI And Machine Learning – Part 1: From Model To Method

Artificial intelligence (AI) and machine learning (ML) technologies are now embedded across a broad range of commercial and technical sectors, from healthcare, imaging and industrial control to financial services, cybersecurity, logistics and consumer platforms. As these technologies move from proof-of-concept into real-world deployment, they raise distinct patentability issues.

This two-part feature considers how AI and ML inventions can be protected in Australia.

• Part 1 | focuses on patentable subject matter and common pitfalls that can arise when AI and ML inventions are framed too broadly or too commercially.
• Part 2 | then considers how to shape patent specifications and claim strategy so that the technical implementation is properly captured.

For a broader discussion of IP Australia’s updated computer-implemented invention guidance following Aristocrat Technologies Australia Pty Ltd v Commissioner of Patents [2025] FCAFC 131, see our recent article that summarises the changes, practical implications and provides useful tips for Applicants.

AI patentability in Australia

In Australia, patent eligibility does not turn only on whether an AI or ML system is new, sophisticated or commercially valuable. The claimed invention must also be a “manner of manufacture” under the Patents Act 1990.

Australian law does not use the same “as such” exclusion found in UK and New Zealand-style formulations. However, computer-implemented inventions, software and algorithm-based inventions are not excluded merely because they involve software or conventional computer technology.

The more difficult question is whether the claimed invention, as a matter of substance, is more than an abstract idea, scheme, business method, or presentation of information implemented using ordinary computer tools.

The Full Federal Court’s decision in Aristocrat Technologies Australia Pty Ltd v Commissioner of Patents [2025] FCAFC 131 (Aristocrat ’25) is now an important reference point. The decision confirms that the assessment is one of characterisation. The claim is considered in light of the specification as a whole and the common general knowledge, and the inquiry is directed to substance rather than form¹.

Importantly, the claim should not be stripped back by disregarding known technical features where those features are fundamental to how the claimed combination operates².

For AI and ML inventions, this provides a useful but measured framework. The question is not simply whether the model is sophisticated, whether it processes data in a novel way, or whether it represents an “advance in computer technology.”

The more practical question is whether the claimed AI or ML implementation is merely an abstract idea manipulated on a computer, or an idea implemented using a computer to produce an artificial state of affairs and a useful result.

Below we outline practical strategies for preparing AI and ML patent applications that are better positioned to meet the Australian patentability threshold. In Part Two, we look beyond eligibility and consider how AI and ML inventions can be claimed strategically once the technical implementation has been identified. This includes identifying the centre of technical gravity, supporting multiple claim pathways, and building the technical disclosure needed for robust and commercially meaningful protection across multiple jurisdictions.

Where AI and ML inventions are more likely to be patenable

Not all uses of AI or machine learning will give rise to a patentable invention in Australia. These technologies are often commercially powerful, but the patentability inquiry focuses on the substance of the claimed invention as a whole.

In practical terms, AI and ML inventions are more likely to be patentable where the model is integrated into a specific computerised product, device, control process, communications environment or other practical system, and where the patent specification explains how that integration changes system behaviour or produces a practical technical result. The model should not appear as a black box that merely receives data and outputs a prediction, score, classification or recommendation.

For example, a convolutional neural network used in a medical imaging workflow to process imaging data, reduce artefacts, or support reconstruction of a clearer diagnostic image may present a stronger patentability case. The model is not merely generating information for its own sake. It is operating within a technical environment and affecting the quality or operation of a technical system.

By contrast, a model that uses historical purchasing behaviour to predict user preferences and personalise product recommendations in an e-commerce interface may face greater difficulty³.

While commercially valuable, that type of invention may still be characterised as a business method, marketing scheme, data-analysis exercise or decision-making logic implemented using standard computing tools, unless the claim and specification identify a more specific technical implementation or system-level result.

Although IP Australia’s updated patent examination manual guidance following Aristocrat ’25 is helpful in moving the analysis away from a rigid “advance in computer technology” requirement, it does not remove the underlying risk for AI implementations that are, in substance, directed to commercial decision-making or information presentation.

The distinction does not lie in whether the invention uses machine learning. The same model architecture may be used in one setting to improve operation of a device, control an industrial process, process sensor signals, or manage a constrained communications environment.

In another setting, it may be used only for customer segmentation or commercial decision-making. The patentability analysis will turn on the implemented context, the interaction between the claimed features, and the result produced by the claimed combination.

Accordingly, the patentability threshold does not hinge on whether the AI model is new or sophisticated in isolation. What matters is whether the invention, when considered as a whole, is properly characterised as a patentable implementation rather than an abstract idea or scheme carried out on ordinary computer infrastructure.

This might involve improving operation of a device, controlling an industrial process, or delivering a measurable improvement in system performance. The key is to explain how the claimed invention produces that practical outcome, rather than merely replicating human judgment or implementing known rules at scale.

Where AI and ML patent applications go wrong – and how to get it right

Even where an AI or ML invention is technically strong, a poorly prepared patent specification can undermine its prospects in Australia. Many applications encounter objections not because the underlying technology lacks value, but because the specification fails to show how the claimed AI implementation operates within a real system, how the relevant features work together, and what practical result is produced.

The following are common drafting issues and practical ways to avoid them.

1. Overgeneralising the technical problem

A common mistake is to describe the invention as “improving accuracy” or “enhancing performance” or “optimising decisions” without identifying what is being improved, how the improvement occurs, or in what implemented context.

These kinds of statements often read as aspirational rather than grounded in engineering detail.

For example, a claim that a model “improves fraud detection” may be vulnerable if it does not explain the relevant data inputs, processing steps, security protocol, system architecture, or operational response.

By contrast, a patent specification that describes how a recurrent neural network processes time-stamped transaction data to trigger a real-time risk flag within a secure authorisation protocol provides a clearer practical setting for the invention.

The aim is not simply to identify a desirable outcome, but to explain how the claimed system operates to produce that outcome.

2. Relying on “buzzwords” instead of substance

Terms such as “deep learning engine,” “AI module,” or “trained model” and “neural network” may sound technically sophisticated, but without technical context, they add little if the patent specification does not explain their structure function and role in the claimed system.

A generic statement that “a deep learning model classifies sensor data” may be too abstract.

A stronger disclosure may explain that a convolutional neural network having defined processing layers is trained on labelled ECG waveform data to identify arrhythmic events in real time, and that the output is used to initiate automated triage within a clinical monitoring system.

The more the patent specification explains how the AI component is configured and how it interacts with other system components, the easier it is to characterise the invention as a practical application of the technology rather than a generic algorithmic result.

3. Omitting the role of data

For many AI systems, data is not a passive input. The way data is selected, cleaned, labelled, transformed, compressed, synchronised or combined may be central to how the invention works.

In weaker patent specifications, these steps are sometimes treated as background detail, even though they may be critical to how the invention works. For example, describing a system as “trained on historical customer data” says little about the invention. By contrast, explaining that the system filters outliers from transaction logs, aligns timestamps, and labels entries using a semi-supervised process to identify anomalous patterns may provide a more concrete basis for protection.

Where data preparation or feature generation contributes to the practical operation of the system, those details should be described and, where appropriate, claimed.

4. Mixing technical and non-technical effects

AI and ML inventions often produce both technical and commercial benefits. A common drafting problem is to emphasise only the commercial effect.

For example, a system that identifies high-value customers using ML may be described as “optimising engagement” or “increasing conversions.” Those outcomes may be commercially valuable, but they do not necessarily assist the patentability analysis. The stronger patent story may lie elsewhere, such as reduced memory usage, lower latency, more efficient server-side segmentation, improved data synchronisation, or a particular way of configuring a distributed processing environment.

This does not mean that commercial context is irrelevant. It may explain why the invention matters. But the patent specification should also identify the implemented mechanism and the practical result produced by the claimed combination.

5. Describing the result but not the mechanism to achieve it

It is not enough to describe what the system achieves. The patent specification should explain how it achieves it.

This is particularly important where the claims refer to outcomes such as classification, scoring, detection, prediction or recommendation. A claim that “the model outputs a fraud score” may be vulnerable if the underlying model, input features, training process, deployment architecture or system response is not explained.

By contrast, a patent specification that describes a fraud score generated using a gradient boosting algorithm trained on multi-channel metadata, and then used to initiate a secondary authentication loop within a secure gateway, provides a stronger basis for characterising the invention as an implemented security process, rather than a disembodied scoring exercise.

6. Ignoring the computing context and technical integration

For AI and ML inventions, patentability may depend not only on what the model does, but on how and where it is implemented. The computing environment may be central to the invention.

It can be important to describe whether the model runs on embedded hardware, mobile devices, edge networks, cloud infrastructure, distributed systems, sensors, control systems or communications layers. It may also be important to explain the constraints under which the model operates, including limited processing power, memory, bandwidth, latency, energy, privacy or security requirements.

These are not always mere deployment details. In many cases, they explain why the implementation is practically significant. If those implementation constraints are not described, the model may appear to be a generic software tool, even where the actual deployment required real technical insight.

For example, a model that predicts equipment faults may be unconvincing if it is described only in functional terms. The same model may present a stronger case if it is deployed on solar-powered field sensors, processes real-time soil and pressure data, and triggers automated irrigation adjustments over a low-bandwidth network. That context helps show that the invention is not simply an abstract prediction, but a practical system operating under real technical constraints.

7. Collapsing training and deployment into a single step

AI systems often involve distinct phases: training, where the model learns from historical data, and inference, where the trained model is deployed operationally.

Where a patent specification blurs these phases, it becomes harder to identify the inventive contribution and support patentability.

Is the contribution in the training pipeline? The data preparation process? The model architecture? The inference process? The deployment environment? The interaction between the model and another technical system?

For example, a claim to “a machine learning system for detecting fraudulent transactions” may be too general if it does not distinguish between training and operational use. A more effective disclosure may describe:

1. training a federated learning model across encrypted transaction logs maintained by multiple institutions, and
2. deploying the trained model within each institution’s monitoring system so that locally held transaction data contributes to peer-informed anomaly detection while remaining within each institution’s secure environment.

That type of disclosure identifies both the training context and the deployment context, and may better support claims directed to different aspects of the invention.

What has changed after Aristocrat ’25?

The Aristocrat ’25 decision, together with IP Australia’s stakeholder feedback response and updated Manual guidance, is helpful for applicants because it moves the analysis away from an overly rigid requirement that a computer-implemented invention must involve an advance in computer technology before it can be patentable⁴.

The decision confirms that conventional computer implementation is not automatically fatal⁵. It is too narrow to say that implementing an idea using conventional computer technology can never be a manner of manufacture. Known technical features may still matter if they are part of the combination that gives the invention its practical effect⁶.

That is particularly relevant for AI and ML inventions. Many valuable AI implementations use known model types, known hardware, known cloud services, known sensors, known processors or known communications networks. The fact that individual components are known should not end the inquiry. The question is how the claimed features work together, and whether the claimed implementation produces the required practical result.

However, the Aristocrat ’25 decision and the updated patent examination manual guidance should not be overstated. They do not make business analytics, recommendation engines, risk scoring, financial modelling or information presentation patentable merely because they use AI.

The Full Federal Court reaffirmed that earlier cases rejecting business, marketing, logistics, risk-management and information-processing schemes were correctly decided where the computer was merely used to manipulate an abstract idea.

For AI and ML applicants, the practical message is therefore balanced: do not rely on the sophistication of the model alone, but do not assume that conventional computer components are irrelevant. The patent specification should explain the implemented system as a whole, including the interaction between the model, data, computing environment and resulting practical operation.

In Part 2

In Part 2, we look beyond eligibility and consider how AI and ML inventions can be claimed strategically, once the technical implementation has been identified.

This includes identifying the centre of technical gravity, supporting multiple claim pathways, and building the evidence needed for robust and commercially meaningful protection.

Footnotes

1 Aristocrat Technologies Australia Pty Ltd v Commissioner of Patents [2025] FCAFC 131 at [2025] FCAFC 131 at [126]

2 See by analogy Aristocrat [2025] FCAFC 131 at [127]

3 See Aristocrat [2025] FCAFC 131 at [132], discussing Grant v Commissioner of Patents [2006] FCAFC 120; Research Affiliates LLC v Commissioner of Patents [2014] FCAFC 150; Commissioner of Patents v RPL Central Pty Ltd [2015] FCAFC 177; Encompass Corporation Pty Ltd v Infotrack Pty Ltd [2019] FCAFC 161; Commissioner of Patents v Rokt Pte Ltd [2020] FCAFC 86; Repipe Pty Ltd v Commissioner of Patents [2021] FCAFC 223; and Dei Gratia Pty Ltd v Commissioner of Patents [2024] FCA 1145.

4 See Aristocrat [2025] FCAFC 131 at [136]

5 See Aristocrat [2025] FCAFC 131 at [132]

6 See Aristocrat [2025] FCAFC 131 at [127]