Abstract Ideas and ‘Software Patents’ – Two Sides to the Story

I recently wrote about the decision of the Federal Court of Australia in Repipe Pty Ltd v Commissioner of Patents [2019] FCA 1956, in which two innovation patents owned by RePipe were found to be invalid, and thus liable to be revoked, on the ground that neither was for a patent-eligible ‘manner of manufacture’ under Australian law.  In that article, I noted that even when software innovators, like RePipe, make substantial investments and incur significant business risks in devising, developing, and bringing an invention to market, they may find themselves unable to access the same protection under the Australian patent system that is available to innovators in other fields of technology.  I observed that while some relatively trivial, low-social-impact, and low-risk innovations, such as a ‘packing box for shuffled playing cards’, enjoy uncontroversial patent protection, RePipe’s sophisticated, high-impact, high-risk, development of a networked system for improving workplace health and safety, is denied protection on the basis that it is a ‘mere scheme’ implemented using ‘standard’ or ‘generic’ hardware and software.

I questioned the policy basis for this distinction, in view of the classical economic rationale for having a patent system, viz., to provide an incentive for individuals and businesses to engage in the risky process of invention, development, and marketing of new products and services.  Which is all very well when this process of commercialisation actually takes place, and there is a genuine investment to be protected.  But that is not always the case.  Sometimes, the only ‘investment’ is in the preparation and filing of a patent application.  And where the claimed invention is software-implemented, a suspicion may arise that the real ‘work’ of innovation, which would justify the grant of exclusive patent rights under the classical rationale, can be avoided. 

I believe it is this suspicion that has caused courts and patent offices – along with legislators, in those jurisdictions that have chosen to impose statutory restrictions on patenting of ‘computer programs’ – so much angst.  This has led, in turn, to confusion and inconsistency in decision-making, such that the patent system can appear capricious, unpredictable, and discriminatory when applied to software innovations. This is bad for innovative businesses that can add confusion and uncertainty around the availability of patent protection, for themselves and their competitors, to all of the other risks and unknowns that they already face in developing and commercialising new products and services.

The patent system is supposed to be ‘technology neutral’, and capable of adapting to new developments and the emergence of new technologies.  However, it plainly is not.  The primary legal tests for determining what is, and is not, deserving of patent protection – novelty, inventive step, and the provision of a sufficient disclosure of the invention – are proving inadequate to deal fairly and consistently with computer-implemented innovations.  As a result, the blunt instrument of subject matter eligibility has become the tool of choice for striking down claims that are deemed to be unworthy of protection.

A Hypothetical ‘Invention’

To clarify my point, consider this hypothetical situation.  Imagine that when driving home from the shops today, I suddenly had an idea for an online platform for connecting inventors with patent attorneys (elevator pitch: ‘it’s like Tinder, only for connecting clients with attorneys’).  This would be great for inventors, who otherwise might have trouble finding a suitable attorney, and great for attorneys, who might be able to gain new business with a lower cost of client acquisition. 

We will suppose, for the purposes of this hypothetical, that my sudden flash of inspiration included a couple of features that are specific to requirements in the market for patent attorney services – maybe to do with ensuring confidentiality of information shared via the online platform, and/or addressing potential conflicts of interest – such that my idea includes functional aspects that we will assume are novel and inventive.

So, hypothetically, I now have an idea for a new and inventive computer-implemented system.  I think we can all agree, however, that my flash of inspiration in the car does not qualify for patent protection.  It is, at this point, just an idea.  As we all know, a mere idea has never been sufficient to support a patent claim.  The idea must be embodied in concrete form, either in reality (e.g. by the development of a prototype), or ‘constructively’ (e.g. by the provision of written instructions).  This concrete form must be disclosed in a patent specification in a manner that is sufficient to enable a person skilled in the relevant art (in this case, an appropriately qualified and experienced software developer, or team of developers) to put the invention into effect without exercising any further inventive ingenuity.

Describing the ‘Invention’

Fortunately for me, I am a patent attorney with experience working in a software development environment.  Indeed, not only have I developed software myself, I worked for two years in software specification, writing functional requirements documents for developers to turn into working code.  I know that an implementation of my idea would require hundreds of thousands of lines of code to be written, tested, and debugged over a period of many months.  I do not know exactly what those lines of code will look like, but I do know that with an adequate requirements specification the work of developing them will be routine. 

I also know what the hardware and software architecture of the system will look like.  There will be a server (probably cloud-based) with a database containing details of attorneys and clients registered with the system.  There will be remote applications, running on computers, smartphones, and other devices operated by the attorneys and clients.  The remote applications will communicate with the server to share and update information.  The server will correlate attorney and client data to select potential matches, and send these out to the remote applications.  The remote applications will present user interfaces to the attorneys and clients, enabling them to enter details, view prospective matches, and make selections.

Clearly it is possible to implement all of this in software.  Given enough time and effort, pretty much anything (within reason) that can be imagined, can be implemented in software!  And, because I am a patent attorney with experience in software development, I sit down to start drafting a patent specification for my idea as soon as I get home.  Within a day, it is done, and ends up looking much like the specifications at issue in the recent Encompass and Repipe cases.  It describes, in some detail, all of the major functionality, along with the technical environment – i.e. the hardware and software architecture – in which that functionality is to be implemented.  It is, without question, a sufficient description for a software developer (or team) to sit down and put my idea into effect – albeit over a period of months – using their existing knowledge, skills, and standard resources, without making any further inventive contribution.

The Question at the Heart of the ‘Software Patent’ Controversy

In this hypothetical scenario, then, the three main pillars of patentability have been satisfied.  I have provided: (1) a sufficient description of a system including functional features; that are (2) novel; and (3) inventive.  If my invention was a mechanical device, I would expect that this would be enough to secure a patent.  But my invention is not a mechanical device, it is a computer-implemented system.  It requires the use only of readily available hardware, arranged in a well-known architecture.  Certainly, it also requires the development of hundreds of thousands of lines of code to turn that ‘generic’ hardware into the specific system that I have envisaged.  But is that enough?

Just a few paragraphs back, we agreed that my idea was not, by itself, enough to support a patent.  Since then, all I have done is to describe that same idea, and place it into the context of an otherwise entirely conventional hardware and software environment that I plucked from my store of knowledge and experience without any further substantive design effort.  Does this now make it, as if by magic, ‘more than’ the original unpatentable idea?  I do not ask this as a rhetorical question.  It is, in my view, the question at the very heart of the entire controversy around patenting of computer-implemented inventions.

And it is not at all a hypothetical question.  In my career as a patent attorney, there have been numerous occasions on which I have drafted just such a patent specification for a client that came to me with only the original idea for a computer-implemented innovation.  In some cases, they did not have the skills or knowledge to implement their ideas even if they had wanted to do so – indeed, they may have wanted to get some protection in place precisely so that they could start talking about their idea with software developers or prospective business partners.  These are common scenarios.  Businesses want whatever protection may be available to be in place before they start incurring costs and accumulating risk.

The Answer – According to the Federal Court of Australia

Turning back to the question at hand, the five-judge panel in Encompass Corporation Pty Ltd v InfoTrack Pty Ltd [2019] FCAFC 161, at [101], provided its very clear answer.  Presented with the proposition that the method claimed by Encompass was ‘a high-level description of a computer program’ (which it absolutely was, in the sense discussed above), the court disagreed, stating that ‘[i]f approached from this point of view, the method is really an idea for a computer program, it being left (as we have said) to the user to carry out that idea in an electronic processing device’ (emphasis added).

Did it matter that the Encompass invention had actually been implemented commercially?  No, not at all.  The patent system does not concern itself with whether or not the inventor has made a working model, prototype, or commercial embodiment of the invention.  All that matters is whether the specification sufficiently describes how to do so.  And, for many software-implemented inventions, a high-level description of the corresponding functional requirements is, indeed, sufficient for this purpose.

Would it have made a difference if Encompass had provided additional technical detail, or even sample code?  No, I do not believe so.  As I have already noted, in this kind of case – where no further inventive ingenuity is required in order to implement the system – such detail is not required to satisfy the primary requirements for patentability.  And even if additional detail had been provided, this could only conceivably have been of assistance if such technical details had also been incorporated into the claims, since superfluous description, by itself, surely cannot mystically confer patent-eligibility upon an otherwise ineligible claim.  But, as I noted in my earlier article discussing the Repipe case, reciting additional detail in the claims would have the effect of limiting the scope of any patent such that it could be easily avoided simply by choosing an alternative implementation approach.  Software is like that, you see!

Conclusion – Confusion and Conflict, but no Simple Solution

So, where does all this leave us?

Firstly, it has become apparent that the three primary pillars on which the patent system rests for established technologies – novelty, inventive step, and sufficiency of description – are incapable of distinguishing between patent-worthy and un-patent-worthy software-implemented inventions.  This leaves only the blunt instrument of subject matter eligibility as a tool to weed out the ‘undesirable’ claims.

Secondly, it follows that some computer-implemented inventions are patent-eligible, while others are not … if we can only work out how to tell the difference!

Thirdly, the distinction between eligible and ineligible inventions rests upon determining whether, or not, what is being claimed comprises ineligible subject matter (e.g. an abstract idea, or a mere scheme) implemented generally via the instrumentality of ‘conventional’ or ‘generic’ computer hardware and software systems.

Fourthly, we know – because the courts keep telling us so – that prior art and common general knowledge in the field of computer technology do not enter into the analysis.

Fifthly, we are therefore left to work out for ourselves how we are to identify whether or not the computer hardware and software systems involved in the implementation of a claimed invention are ‘conventional’ or ‘generic’.  There are some very long-standing system architectures that we might all agree fall into these categories, however it seems to me that we would be relying on common general knowledge in doing so (and it is worth keeping in mind that, for example, even the common ‘client-server model’ of a centralised system executing software that provides services to one or more remote applications was itself novel and inventive, perhaps some time back in the 1960s).  But there are, equally, architectures, algorithms, techniques, and configurations that are known, and can be found in the prior art, but that most practitioners would not regard as ‘conventional’.  Which raises the question: where do we draw the line?

Given this last point in particular, it is hardly surprising that different minds might reach different conclusions as to whether or not a claimed invention is patent-eligible in any given case.  Nor is it surprising that, in such a case, the arguments for and against eligibility might seem strained and infected with subjective evaluations.  The end result is decisions – including those of the higher courts, to which we all look for guidance – that routinely appear incoherent and inconsistent with one another.

From a policy perspective, it ‘feels’ like there might be some value in providing protection for inventors and businesses that actually go on to invest in developing and commercialising their computer-implemented inventions, while denying similar protection to those who merely file the kind of patent applications I have been discussing here.  But the patent system is incapable of making such a distinction.  Furthermore, why should we single-out software-based inventions for special treatment?  There are, doubtless, many inventions in other fields that can similarly be reduced from an initial idea to a practical implementation, on paper, with relatively little time and effort, and yet are not presently subject to additional eligibility constraints.

One certain thing is that there is no simple solution to the ‘problem’ of patenting computer-implemented inventions.  Or, if there is, it has somehow eluded legislators, patent administrators, judges, and numerous other intelligent people, not only in Australia but also in the US and other jurisdictions that have been grappling with the issue for decades already.

Tags: Computer programs, Patentable subject matter