Software (and business method) patents are important for many reasons. Venture capitalists often require patents for funding. They are offensive and defensive tools against competitors. They promote a perception of a company’s innovativeness. They can add value to a company’s balance sheet. There is potential for licensing or selling since patents are transferrable IP assets.
The problem of course is how to obtain software patents in the US and in Australia in view of the US Supreme Court’s subject matter eligibility decision under 35 USC §101, and in Australia, in view of the Full Federal Court’s manner of manufacture decisions under the Patents Act 1990 (Cth), s 18(1)(a). Following Alice, Research Affıliates LLC v Commissioner of Patents4 (RA) and Commissioner of Patents v RPL Central Pty Ltd5 (RPL), the patentability of software and business method inventions has become a substantial hurdle to overcome in patent prosecution. That is, while there is not a bar against software and business method patents in either the US or in Australia, intangible inventions are highly scrutinised in the US and Australian patent offices.
While the subject matter tests in Australia and in the US are quite different from one another, a practitioner will write one patent application for both jurisdictions. In the US, examiners consider a claim as a whole. In Australia, a harder test to overcome is whether there is an inventive contribution set out in the claim. Accordingly, an acceptance or rejection in the US and Australia may be for different reasons. When writing, consider passing muster in each jurisdiction individually. Below are combined tips for writing for both jurisdictions.
While these court decisions are known outside of the patent business, the ramifications are not well understood, so managing client expectations is difficult. The patent attorney’s job is to help the inventors find or develop patentable subject matter in a seemingly abstract (unpatentable) invention. Sometimes the task is not possible.
The reason why software and business method claims are currently under such scrutiny should be understood. The Alice holding was that “[a] claim that recites an abstract idea must include ‘additional features’ to ensure that the [claim] is more than a drafting effort designed to monopolize the [abstract idea].” Thus, the Alice holding mitigated risk of pre-emption of an abstract idea. According to the Alice court’s rationale, granting a limited monopoly on an abstract idea is dangerous because an abstract idea represents a building block of human ingenuity. Tying up building blocks with patents might impede progress rather than foster it, thus contravening the policy behind the patent system, which is to promote development of the technical arts. That is, claiming an otherwise abstract idea in a limiting way (something more), does not pre-empt the abstract idea. The case law before Alice provided the same result.
The United States Patent and Trademark Office (USPTO) has issued guidelines to its examiners on how to determine whether a software invention is subject matter eligible, including a two-part test. The first part asks whether the claimed invention is abstract. If it is abstract (or a scheme), then the second part asks if there is “something more” (an additional feature) which provides an inventive contribution. That means part of the subject matter question involves determining whether there is an inventive concept. The courts in both RA and RPL were looking for something more as well.
USPTO has published a flow chart.6 This flow chart ends with something more — including, for example, transforming physical material, or data representing physical phenomena, into a different state or thing, to achieve a practical application to be patentable. USPTO has also published examples of subject matter eligible claims.7
There has been a bit of a reprieve just recently. In Amdocs (Israel) Ltd v Openet Telecom Inc8 (Amdocs), the Federal Circuit said that although the hardware involved was limited generic computer components, “the claim’s enhancing limitation necessarily requires that these generic components operate in an unconventional manner to achieve an improvement in computer functionality”. RA and RPL also considered whether those claims provided an improvement in computer functionality.
Furthermore, on 2 November 2016, the USPTO issued a memo to examiners in light of the Federal Circuit’s McRO Inc v Bandai Namco Games America Inc9 (McRO), (see below), that instructed examiners to not overgeneralize the claim or simplify it into its “gist” or core principles, when identifying a concept as a judicial exception (an abstract idea). The new memo also acknowledges that while the Federal Circuit agreed that each claim element was found in the prior art in Bascom Global Internet Services Inc v AT&T Mobility LLC10 (Bascom) (see below), it held that the ordered combination of the claimed elements was not in the prior art. The memo in turn instructs examiners to consider the ordered combination of elements when considering whether a claim amounts to significantly more than an alleged abstract idea. Thus, now the USPTO accepts combinations of steps that together cause a transformation of some type.
This is an evolving space, so more USPTO guidelines are always expected. At IP Australia, thin guidelines are provided at the Manual of Practice and Procedure (MPP) 184.108.40.206 and 220.127.116.11. At IP Australia, examiners typically base their objections in view of their own interpretation of the language of RA and RPL.
If I find that the invention is patentable, the answer that I give usually does not correspond with the expectations of the inventors. The answer may not be obvious at first, especially when speaking with inventors as they do not think in terms of getting over these hurdles. Finding an angle by which to frame the software invention oftentimes requires that a patent attorney drill down into questions with the inventors and creativity. To avoid an abstract finding, write the application to emphasise that the invention is a technical solution to a technical problem.
A software invention may solve a software problem such as:
Also a software invention may solve any kind of technical problem such as:
Below are the five examples where the US Federal Circuit found patentable subject matter:
These and many other subject matter eligibility cases of the Patent and Trademark Appeals Board and lower US Federal Courts where patents were allowed or validated are discussed at IP Spotlight.13
Because it is a subjective call, examiners are inclined to find a claimed software invention abstract. Therefore, it is best if the invention is not perceived as abstract in the first place. Claims in which a computer is merely a tool will result in an abstract finding. Instead, pre-emptively focus on the technical solution to avoid an abstract finding. Still an examiner may find the invention abstract. Further prosecuting the claims to argue there is something more, an inventive contribution, can be difficult. Be honest with yourself about the prospects for success.
Apply the transformation test. Does something change? Does the input arrive in one form and then something happens to it, causing it to change into a new structure? Does the claimed invention result in a physical effect? Software inventions that generate a physical change in the physical world are less likely to be viewed as abstract. The physical effect should be directly caused by the claimed invention. Delivering generated data for use by another system will probably not satisfy this test. It is tricky to find an inventive concept in data manipulation. Sorting or distributing the data without something more will not overcome the hurdle. Are you just moving content or data from one place to another without changing the data or creating new data? Watch out for this. Suffice to say, if a computer carries out programming steps where the computer is simply a tool, those steps will be found a scheme in Australia and abstract in the US.
Ask whether a new data type is created in the process as per the transformation test? Is there an association between two types of data that creates a new data file or type, even temporary data that causes something to happen? Even still, find other features that can be added to the claims to create a combination of elements.
Consider if the claimed invention could be carried out by hand. Consider whether a computer is really necessary to carry out the invention? That is, remove the computer from the method to see if the computer is required. At least one court found that claims had been carried out by Middle Eastern merchants around the time of Christ.
Likewise, draft claims so they do not read on mental steps. If you can carry out the invention in your head, it could be found lacking subject matter eligibility. Look for a software invention that does not read on mental steps.
Does the invention improve computing functionality? In Enfish, the Federal Circuit found the self-referential table for a computer database not abstract because the problem solved was a software-based problem and the invention improved computer functionality. The computer was not merely a tool.
If you list objects, list only technical objects of the invention in the description. Do not list business or human manipulation objects as an examiner will use these against you. Examiners are looking for these objects to argue that the motivation is not a technical one.
Claim the way it works, not the result. But also use means-plus-function claims in addition to your method and system claims. In Enfish, the US Federal Circuit found means-plus-function claims cleared the hurdle because the description was adequate. Either way, write a complete description of how the means carry out the function, with as many figures and equivalents as possible. Technical details of the description should be specific, not loosely defined. For example, refer to “display output driven by the processor”, rather than just “displayed”. If your inventors have not yet implemented their invention and there are technical problems foreseen, explore those and write about potential solutions in detail. Be wary of a leap in logic or missing steps. Also, do not admit off-the-shelf solutions for technical problems.
Take the method beyond the computer and involve a system architecture by adding one or more physical layers to the process. Are remote devices receiving and/or transmitting signals in the process? Is a remote server involved in the process? In Bascom, the Federal Circuit found an inventive concept (something more) was in the non-conventional and non-generic arrangement of known, conventional pieces including the remote ISP server filters.
Involve the user interface. If there is a new way of driving the display of something that requires a new processor-level method, that may overcome the hurdle. Is there a new type of data or a data transformation?
Make your preamble long, identifying the field to which the invention relates so that the claims do not pre-empt all fields to which the solution could be applied. Long preambles make the claims look narrower. Pre-emption was why Alice was decided as it was. If your solution applies to different fields, write more applications to those fields.
Keep tabs on the progress of implementation, looking for technical problems that have surfaced during development. File top-up provisional applications to describe further solutions. Also, expedited examination can early on determine whether the application will overcome the hurdle.
The art of writing software patent applications to clear the subject matter eligibility hurdle has taken interesting turns. It has been found that there are some examination groups in the USPTO that simply do not grant patents.14 Write the title of the invention to avoid these groups when the group assignments are made at the USPTO. Telling also are the reasons for allowances in examining groups related to your technology (according to an International Patent Classification (IPC)).
Look to allowed and validated cases for inspiration. Rejected or invalidated cases, especially in the US lower courts are fraught with the application of inconsistent standards. The 2 November 2016 USPTO memo in fact instructs examiners to avoid relying on lower court decisions. Accordingly, time is better spent on reviewing allowed and validated cases.
Have you claimed some kind of transformation? Does the claimed invention change or create something? Does the software invention extend beyond one computer to another physical layer? Have you claimed how it works? Have you described in detail how the invention works? Does the invention improve the functioning of a computer? If so, you will have a better chance of overcoming the subject matter eligibility hurdle.