Repipe confirms that where the overall functionality of a computer-implemented invention relates only to excluded subject matter, such as an abstract idea or a business scheme, then the fact that the functionality is embodied via software in a technical system is, in itself, insufficient to confer patent-eligibility. There must, additionally, be some patentable ingenuity (whatever that might mean) in the implementation itself. Of course, the relevant implementation details would necessarily be reflected in the claims, and the scope of protection available is therefore correspondingly limited. This applies regardless of the cost and business risk involved in devising, developing, and bringing the invention to market.
As a result, many software innovators seem to be second-class citizens under the Australian patent system when compared with those working in other fields of technology. It is difficult to discern any coherent policy basis for this distinction. The classical economic rationale for having a patent system is to provide an incentive for the risky process of invention, development, and marketing of new products and services. Once an invention has proven to be commercially successful, competitors can enter the now-established market at considerably reduced risk, even if their production costs are the same as those of the innovator. Why, then, should patent protection be considered justified for, say, a ‘packing box for shuffled playing cards’, but not for RePipe’s invention of a sophisticated networked system for improving workplace health and safety? I know which one of these involved the larger investment and business risk in development, and I know which one offers the greater social benefit … and it is not the one that is entitled to patent protection in Australia!
Background on an Innovative Australian Enterprise
RePipe is a plumbing business based in Western Australia. It is a business that is clearly concerned about the health and safety of its employees, partners and clients, stating on its website that ‘at RePipe, risk management takes priority to [sic] all other objectives, including profit.’ It has embodied its risk management expertise in a software system called rerisk®, which it hopes will ‘change the world’. Access to the rerisk® system is not limited to RePipe – the system is available as a service to other businesses that want to improve their workplace health and safety (WHS) processes. It comprises a server-based backend, and an app that can be installed on portable devices (i.e. smartphones or tablets) carried by workers on site. In use, information and documentation pertinent to WHS compliance processes for particular jobs carried out by workers at specific locations are downloaded to the portable devices. Among a range of other useful features, the system: provides prompts and checklists to ensure that workers comply with relevant procedures; generates alerts when problems or risks are identified; and enables information provided by the workers to be uploaded back to the server and/or communicated to other workers on site. rerisk® was one of three finalists in the WorkSafe Western Australia 2019 ‘Work health and safety invention of the year’ (199 employees or less category).I do not include the above information in order to spruik rerisk®, about which I know nothing beyond the information available at the various linked sites. I include it to make the point that the technology that is sought to be protected by the RePipe patents is not merely an idea that has never actually been implemented in reality. It is a sophisticated software platform and service that has been developed and deployed to a high commercial standard, that has received recognition for its innovation and utility, and that is providing real benefits to RePipe and other businesses, along with their employees. Anybody who has ever been involved in the development of commercial software – i.e. software that must work effectively and reliably in the hands of a range of end users – knows just how much investment in technology, time, and money is required to bring such systems to market.
RePipe’s Adventures in Patentland
You might think, therefore, that when a business has made such an investment in developing a new and innovative system that does something as important and useful as improving health and safety of workers in potentially hazardous working environments, it would be possible to protect that investment via the patent system. Patents are, after all, supposed to exist in order to provide an incentive to invest in the economically risky enterprise of innovation, to support the development and dissemination of new and useful products and services.That is, presumably, exactly what RePipe thought when it embarked upon a patenting strategy for the rerisk® invention, beginning with an Australian provisional application in March 2015. It went on, a year later, to file an international application under the Patent Cooperation Treaty (PCT), claiming priority from the provisional application. It has since used the PCT application as the basis for filings in Australia, the US, Canada, South Korea, Japan, and the European Patent Office (EPO). Additionally, in Australia, RePipe filed two innovation patents, nos. 2017100560 and 2017100943.
Unfortunately for RePipe, first IP Australia, and now a single judge of the Federal Court of Australia, have disagreed. While there has been no finding that the inventions claimed in either of the two innovation patents lack novelty or an innovative step, in a decision issued on 28 June 2018 (Repipe Pty Ltd [2018] APO 42) a delegate of the Commissioner of Patents found that neither patent was for a ‘manner of manufacture’, i.e. that the claimed computer-implemented inventions did not comprise patent-eligible subject matter. RePipe appealed the decision, which has now been upheld in the Federal Court.
The court’s approach to assessing patent-eligibility in Repipe deftly navigates the not-entirely-coherent reasoning of the various relevant higher authorities by which a single judge is bound – most notably National Research Development Corporation v Commissioner of Patents [1959] HCA 67 (NRDC); CCOM Pty Ltd v Jiejing Pty Ltd [1994] FCA 1168; 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 Limited [2015] FCAFC 177; D’Arcy v Myriad Genetics Inc [2015] HCA 35; and Encompass Corporation Pty Ltd v InfoTrack Pty Ltd [2019] FCAFC 161.
Software is not Excluded from Patenting
Firstly, the court is clear that software is not subject to any special exclusion from patent-eligibility, i.e. that in appropriate circumstances an invention implemented via the instrumentality of a computer program may be patented (at [33]):A mere scheme or plan is not patentable. However, an improvement in computer technology, including one that implements a method used in the conduct of business, is patentable. The business criterion for patentable subject matter is an artificially created state of affairs that has economic significance or utility, although this may not be sufficient in all circumstances. No special rules or exclusions apply to claims for functions performed by software.
Patent-Eligibility Does not Depend Upon Prior Art… Or Does It?
Secondly – and in contrast to the current examination practice of IP Australia, on which the five-judge panel in Encompass declined to comment – the court has reiterated that assessment of ‘manner of manufacture’ does not involve considerations of prior art or common general knowledge in the field, i.e. the ‘ball point pen principle’ articulated in CCOM still stands (at [35]):Consideration of whether there is an improvement in this context, or of matters of invention or ingenuity, directs attention to the subject-matter of the invention as a matter of substance. It does not import into the manner of manufacture ground, considerations of novelty or of the inventive or innovative step …. The approach is not to compare the claim against the common general knowledge in the field of computer technology or against prior art in that field.
So far, so good. It is here, however, where difficulties presented by more recent Full Court decisions start to become apparent. In trying to follow RPL Central and Research Affiliates, in which a distinction is supposedly drawn between patent-eligible and ineligible computer-implemented inventions, the court provides this summary (at [38]):
An invention will be patentable where ‘part of the invention is the application and operation of the method in a physical device’: RPL (at [101], citing Research Affiliates (at [104])). It will also be patentable where the invention involves the creation of an artificial state of affairs where the computer is integral to the invention or where the invention involves the use of a computer in a way that is itself claimed to be inventive, so that the invention lies in the computerisation or where there is some ingenuity in the way in which computer is utilised: RPL (at [104]).
It remains difficult to see how the state of the art (i.e. prior art and common general knowledge in the field) is not brought into the analysis when the court is required to consider what constitutes the ‘invention’ or ‘ingenuity’ in the claimed subject matter.
Does Encompass Resolve the Conundrum?
In an effort to make sense of these principles drawn from Research Affiliates and RPL Central, the court turned, at [40]-[47], to the recent Encompass decision noting that the five-judge panel had there explained (at [91]):In each case, the Full Court was seeking to describe the conceptual distinction between a manner of manufacture and an unpatentable abstraction. In each case, the Full Court was explaining that a claimed method that is unpatentable does not change its legal character merely because the method is implemented by the instrumentality of a computer.
While this does not appear unreasonable on its face, there is an inherent difficulty with its use of the word ‘merely’. It leaves unanswered the precise questions raised by the Full Court’s approach in Research Affiliates and RPL Central, namely: what, exactly, are the required characteristics of computer implementation sufficient to transcend ‘mere-ness’ and thereby to change the legal character of an unpatentable abstraction, and how, precisely, are these to be evaluated if not by reference to the state of the art in ordinary computer utilisation?
Bringing Out the Experts!
Notwithstanding the supposed irrelevance of the state of the art to the issue of patent-eligibility, both RePipe and the Commissioner of Patents called on expert witnesses. RePipe’s witness is described, at [48], as ‘an expert in computer systems’ who gave evidence as to (among other things) ‘his understanding of the operation and programming of computers and the difference between general-purpose and specific purpose computers and computer implementation as at the priority date’ and ‘what is needed to implement the inventions in the Patents and whether programming a computer to implement the inventions is technical in nature.’ The Commissioner’s expert is described, at [49], as ‘a tenured academic with expertise in developing and implementing databases’ (although it is not clear what relevance or additional authority his tenured status might confer in this context).Usefully, however, the expert testimony provided the court with an overview of a typical software development process, from the preparation of a functional requirements specification through to the production of working code (see [85]-[87]). RePipe submitted that its claimed inventions are broader than any specific code that might be produced to implement them: ‘[t]hey are the whole system or method, including the architecture of the computer system required to carry out the steps in the claims and the functionality required of every component in the system’ (at [86]). Furthermore, the court appears to have accepted, at [88], that limiting the patents to a particular implementation, e.g. by including code in the claims, would have rendered the patents useless, since it would be a simple matter for a competitor to ‘avoid infringement by producing the same functionality, but with slightly different code.’
RePipe sought to distinguish its patent claims from those in RPL Central by pointing out that its ‘inventions are not, and could not be, carried out on generic computers with generic software. The Patents prescribe specific functional requirements and computer code must be written to meet those requirements’ (at [91]). It further (and more convincingly) sought to distinguish Research Affiliates by noting that, other than reciting ‘a computer-implemented method’, the claims there focused on ‘non-technological aspects of the invention’, which the Full Court found were the work of an analyst, rather than the computer (at [92]).
Technical Content versus Meaningful Technical Content?
None of this was sufficient to save RePipe’s claims. The court found, at [93]-[94]:I am not persuaded the Patents in this case are readily distinguishable. No specific application software has been claimed or even identified in any claim of the Patents. No computing programming logic or code is disclosed anywhere in the Patents. The substance of both inventions is a mere scheme that can be implemented using some unidentified software application to cause a server computer and smartphone to perform the steps identified in the claim. To implement the scheme, a reader must use his/her own skill and knowledge to write an appropriate software application. No such application is disclosed in the Patents.
…The language used by patent attorneys when drafting and amending claims cannot convert what is, in substance, an unpatentable business method or scheme into a patentable invention by merely asserting that the invention is in the field of computer technology or by using words in the claim or specification that refer to computer technology …. As a matter of substance, there is no meaningful technical content in the description in the body of the claims or specification.
The court further concluded, at [100], that ‘[i]t may well be that specific software needs to be designed to achieve the “invention”, but even so, that is not the substance of the claimed inventions.’
The point here – arguably – is that if there is no ingenuity (i.e. eligible subject matter) in the method disclosed, or in the architecture of the system disclosed as a platform for implementation, then the necessary ingenuity must reside in some aspect of the implementation itself. Yet the specification does not disclose that the skilled person is required to do anything beyond applying ordinary skill in the art of software development to convert this high-level functional description into a working implementation. It is not enough, on this view, to argue that software development is a technical activity, involving technical considerations, when the specification itself makes no claim – indeed disclaims – that the process of software development involves any further inventive ingenuity in this case.
I am not saying that this is necessarily a ‘correct’ approach, or that it is how the law ‘should be’. For one thing, it does not resolve the inconsistency between, on the one hand, accepting that considerations of novelty or inventive step do not enter into the assessment of ‘manner of manufacture’ and, on the other, that a determination that the system architecture disclosed ‘is nothing more than a standard (generic) server, network and a smartphone or similar, for example, a tablet’ (at [99]) is nonetheless relevant to the conclusion that the claimed invention in not patentable. In an effort to do so, the courth here relies (at [94]) on drawing a distinction between ‘meaningful technical content’ that contributes to the ‘substance’ of the invention and – one presumes, although it is not spelled out – superficial or generic technical content that does not. As unsatisfactory as this may seem, it is perhaps the only plausibly consistent approach that the court could have taken, considering the binding precedent of Research Affiliates, RPL Central, and Encompass.
More Technical Detail is not Necessarily the Answer
In reading the judgment, it might be tempting to conclude that RePipe has been the author of its own misfortune, in failing to provide additional technical implementation detail in its patent specifications. The court seems to make much of the fact that no specific software application or program code for carrying out the inventions is disclosed in the specifications, or made the subject of any patent claims. Indeed, it noted, at [100], that ‘[t]he specifications admit that the claimed inventions may be implemented using any software application, that uses any technical means, that causes a generic server and smartphone to perform the claimed steps’ (emphasis in original).As a practical matter, however, RePipe would have been unlikely to gain anything by including such additional technical detail. Any software developer (including both sides’ experts in this case) would agree that the specifications provide sufficient instruction, in the form of functional requirements, to enable a competent development team to build the software without exercising any further inventive ingenuity. In fact, if this were not the case, then the patents would have been invalid on the additional ground of failing to satisfy the requirement of section 40(2)(a) of the Patents Act 1990 that the specifications must ‘disclose the invention in a manner which is clear enough and complete enough for the invention to be performed by a person skilled in the relevant art’. This is, of course, precisely why the specifications ‘admit’ that any suitable software and technology may be used to implement the inventions – this is not so much an admission, as an assertion that the disclosure is sufficient to satisfy section 40, and equivalent requirements in other jurisdictions.
As I have already noted, reciting specific code in the claims would have so limited the scope of the patents as to render them worthless in practice. In any event, protection is already provided for specific computer program code under the law of copyright. Patents are intended to provide a different, though often complementary, form of protection for functionality, rather than a specific expression of that functionality (see Data Access v Powerflex Services [1999] HCA 49, at [20], per Gleeson CJ, McHugh, Gummow and Hayne JJ).
Conclusion – Limited Protection for Software-Based Innovation
So where does that leave innovative software developers such as RePipe? Unfortunately, like Research Affiliates, RPL Central, Encompass, and many others before them, it probably leaves them without access to the same scope of protection under the Australian patent system as innovators in other fields of technology.The courts seem to be telling us that there are essentially two ways in which a computer-implemented invention may qualify for patent protection. The first is for the overall functionality to fall within a field of patent-eligible subject matter. This may be so when that functionality is technical in nature, for example because it is related to improving some technical system.
However, inventions like RePipe’s, where the functionality relates only to excluded subject matter such as an abstract idea or a business scheme, do not qualify for the same broad protection under the current approach. In such cases, protection will only be available where there is some patentable ingenuity in one or more aspects of the computer implementation itself, and will then generally be limited to those patentable elements of the implementation.
0 comments:
Post a Comment