Patentability of computer-implemented inventions – a high-level take
The ambiguities around patentability of computer-implemented inventions (CIIs) are never more pronounced than when an invention crosses an attorney’s desk that’s clearly a clever and viable solution to a real-world problem but is largely a matter of programming.
Inventions of this kind tend to be at the fringes of what’s considered patent-eligible in most jurisdictions currently. However, there are some key principles of (relatively) general application which, if argued well, can give such inventions the best possible chance of getting across the line. This article is intended as a high-level summary of these principles.
Patent-eligibility of CIIs.
Most countries don’t allow patent protection for inventions that relate to “software as such” (or equivalent terminology). However, over time case law has put a gloss on this, and CIIs, even ones that are software-centric, can now be patent-eligible if they meet certain criteria. These vary by country but generally include:
- The degree to which the invention provides a “technical solution to a technical problem” – or to what extent a “technical effect” or “technical character” is present in the invention.
- Is the computer(s) merely functioning in its ordinary manner (to crunch numbers or for processing speed), or does the inventive concept involve the computer functioning in a new way, doing something it didn’t / couldn’t do before. This is also sometimes construed as whether the invention relates to an innovative computer architecture.
- Is the computer integral to the inventive concept, as opposed to being merely incidental to it? A corollary of this is whether the inventive concept has a “manual analogy”, i.e. whether the computer is just automating an already-known process or one that has or could have a low-tech equivalent; or whether in contrast the process is only possible by virtue of the computer(s).
- The level of abstraction at which the invention is framed – does it relate to a high-level idea / scheme, or is it a specific solution such as a concrete set of well-defined steps?
The author’s “boots-on-the-ground” impression is that there seems to be a glacial but discernible evolution towards a more CII-tolerant attitude in many Patent Offices, likely due to an increasing amount of case law that clarifies and qualifies what was in the past quite a “crude” and “harsh” prohibition. With luck, this trend will continue and things will shift more in favour of deserving CIIs in the coming years.
Canada and New Zealand are examples of jurisdictions that assess CIIs through a somewhat different lens – Canada in view of its post-Choueifaty[1] shift away from the "technological solution to a technological problem" rubric in favour of the question of whether the claims define matter that has a “physical existence or manifests a discernible physical effect or change"[2]; and New Zealand due to its rejection of the “technical effect” consideration altogether when it comes to CII patentability.
A few cases, by way of example
Here are a few cases, as an example of how the above CII principles pan out in practice. (Of course there are hundreds of others that could be pointed to – these are just an exemplary few).
- CosmoKey[3], a recent US Federal Circuit decision having claims to an improved authentication method whereby the authentication function was only turned on for a specific transaction, then turned off again; and also imposed a time interval between switching on and obtaining the user’s input. The Court found the invention patent-eligible on the basis that “the claims and specification thus recite a specific improvement to authentication that increases security, prevents unauthorized access by a third party, is easily implemented, and can advantageously be carried out with mobile devices of low complexity.”
- Jagwood[4], an Australian Hearing Office decision from 2020. A short-form URL was placed in a payment reference field as a “key” that linked to a document warehouse to allow a payment and its full financial document (e.g. a PDF) to be coupled together, rather than being sent separately. It was argued that this was a new “architecture” due to the new (joint instead of separate) path taken by both items of information; and that the use of the short-form URL also amounted to the computer functioning in an unconventional manner. Technical effect carried the day, along with other principles including computerisation being integral to the inventive concept; ingenuity in the way computers are utilised; and, to an extent, the computers operating in a manner foreign to their ordinary usage.
- Facebook[5] is another Australian Hearing Office case exemplifying something similar. The invention dealt with overcoming the “sandboxing limitation” whereby providers of mobile apps are unable to access user download data. The solution involved providing a “shared memory location” on the mobile device from which that data could be retrieved and relayed back to the app provider. This was held to be a “technical improvement” (with the underlying problem likewise being a “technical limitation”). Again, in this invention there was arguably an innovative “architecture” in the sense of a unique “path” taken by the data.
Mooting the arguments / counter-arguments:
With “good” CII inventions, the same governing principles can be construed / applied in different ways.
During prosecution, Patent Offices might reason along the lines that:
- The invention is purely a matter of programming;
- The computer(s) is functioning in its ordinary manner, to process data; there is no new architecture or capability. The ingenuity lies in the “scheme”, being the underlying protocol.
- Any hardware components involved are just doing their ordinary thing.
But in response, the following can often be helpful:
- The invention comprises a specific improvement offering a significant, real-world, practical advantage i.e. a technical effect.
- The claimed invention is not at a high level of abstraction but rather involves a specific set of well-defined steps.
- “Computer architecture” is something of a philosophical question, and the innovative protocol of the invention, though alleged to be a “scheme” by the Patent Office, can be in fact often be construed as a modification in the “computer architecture”, in the sense of the computer doing something new, something more / other than it had traditionally done in the relevant technical space, to achieve an enhanced effect. Refer the altered “flow path” in some of the above examples: on some level this was a “conceptual” matter, but in practice it came down to clever computer architecture.
- As a subsidiary argument, it can also help to point to communication between different “nodes” (user’s device, data repository, 3rd party nodes, etc), which to an extent is also a matter of “computer architecture”, depending on the facts of the case.
- There isn’t a satisfactory “manual analogy”. The invention is not mere automation of a process humans could do, just more slowly – the improved functionality has computerisation integral to it.
- The presence and role of any hardware components (even if functioning generically) should also be emphasised, to generally lend the invention a more “tangible” flavour and move away from the perception of it being a “computer program as such”.
Tactical considerations
At the outset, it’s always a good idea to ask yourself if the client appears to have “glossed over” an aspect of the invention which may in fact provide patent-eligibility. Clients may naturally be most excited about the programming aspects of their invention. But if, for instance, the invention provides a functional advantage and it’s not apparent if this is purely a case of programming or involves some underlying change in the computer architecture, it’s worth quizzing the client about how this advantage comes about. Is the computer(s) really just doing its ordinary thing, or is it functioning in a manner that can be said to be unconventional?
The “deterrent” value of a patent application is not to be underestimated. For inventions where relying on trade secrets isn’t an option due to the concept being easily replicable by third parties (via independent programming), first-to-market advantage will become important. A patent application dovetails with this. It can be maintained for up to 30-31 months without patent-eligibility issues even coming into the equation. This can complement the client’s efforts to establish themselves in the market, in that competitors may tend to be dissuaded from putting out their own version of the concept for fear of liability if and when the patent is granted.
A commercial decision can then be made by the client as to whether the application has done its job or whether it’s worthwhile pursuing it further – at which point the above-noted patent-eligibility issues will eventually need to be thrashed out with national Patent Offices.
“Riding the wave” of patent-eligibility jurisprudence by keeping an application alive for as long as possible is also something to consider, in jurisdictions where it appears CII principles are set to take a turn for the better in the foreseeable future.
Endnotes:
[1] Yves Choueifaty v Attorney General of Canada, 2020 FC 837
[2] https://www.ic.gc.ca/eic/site/cipointernet-internetopic.nsf/eng/wr04860.html
[3] CosmoKey Solutions, GMBH & Co. KG. v. Duo Security, LLC (Fed. Cir, Oct. 3, 2021)
[4] Jagwood Pty Ltd [2020] APO 38
[5] Facebook, Inc. [2020] APO 19
Author: Anna Klepacki
//piperpat.com/news/article/patentability-of-computer-implemented-inventions-a-high-level-take