In my view there are two major flaws in the analysis that leads the PC to this recommendation. Firstly, it conflates business methods and software into a common category, using the abbreviation ‘BM&S’ throughout its discussion. Secondly, it is clear that the PC has very little idea about the vast scope of activity and technological advancement that takes place under the general banner of software development.
As has been the case in many previous attempts to ‘reform’ the law in relation to patenting of computer-implemented inventions (including the farcical process that delayed introduction of the New Zealand Patents Act 2013 for years) the PC primarily views software through the lens of its own rather limited experience of mass market consumer software and online services, along with the rather narrow perspective provided by disproportionately vocal free and open source software (FOSS) advocates.
There is, however, so much more to software than this, and the PC’s draft recommendation of a blanket exclusion is, simply, a terrible and deeply flawed idea!
The ‘Relationship’ Between Business Methods and SoftwareThe PC defines a business method as ‘a way of operating “any aspect of an economic enterprise”, and encompass[es] a broad range of ideas and activities.’ It defines software as ‘a set of instructions that allow computing devices to function.’ It further states that ‘with the rise of the digital economy, many business methods are implemented by software, making it difficult to separate the two.’ On this basis, the PC creates and analyses its single category of ‘BM&S’ patents.
With all due respect to the PC’s efforts to get its collective heads around complex issues in both technology and patent law, this is a gross simplification that has virtually no basis in reality. You will not see the term ‘BM&S’ used on this blog, except within quotation marks. It is an invented and substantially non-existent category of subject matter, the primary effect of which is to ensure that the baby gets thrown out with the bathwater.
The PC may be right to say that ‘many business methods are implemented by software.’ At the very least, many business processes are supported by software, even if it is just through the use of common business productivity tools such as spreadsheets, databases, word processors, and project management applications.
However, it is equally self-evident that the majority of processes employed within business across Australia, and around the world, whether or not supported by software, are not the subject of patents, or indeed of any form of IP protection other than, perhaps, trade secrecy.
It is also apparent that the vast majority of software is not directed to implementing business methods. The software that controls a car’s engine, a washing machine, a dishwasher, the Wi-Fi implementation in a mobile phone, the complex systems of an Airbus A380, a wireless router, the digital video decoders in a television, a set-top box, or a Blu-ray player, the switching equipment in the telecommunications networks, life support systems, X-ray machines, gene sequencers, systems on the International Space Station, satellites, warships, military drones and guided weapons, public transport signalling systems, traffic management systems, security systems, laboratory test and measurement apparatus… I could go on, but none of this software implements a business method! All of it, in fact, either enables entirely new functionality, or replaces prior electronic and/or mechanical systems with a cheaper, more efficient and/or more powerful digital alternative.
To be fair, the PC recognises the role of what it calls ‘embedded’ software, but pays only lip service to this category, as if it is some sort of minor exception to a general rule that software (as subsumed within the ‘BM&S’ category) is not deserving of patent protection.
However, there are also numerous software applications that run on desktop computers, and other common computing devices, that are highly technical in nature, and do not implement anything vaguely resembling a ‘business method’. For example, software that assists in the design, simulation, construction and/or manufacturing of infrastructure (e.g. buildings and bridges), integrated circuits, electronic systems, mechanical devices, communications networks, aerospace systems and so forth (i.e. computer aided design and manufacturing, or ‘CAD/CAM’, software) is highly technical in nature, and is based upon principles of physics and engineering, not business.
Furthermore, within the realm of computer systems as technical artefacts in their own right, there is software that manages huge databases, performs highly complex information processing, that performs data compression, coding, decoding, and other forms of manipulation, and which is based on advanced principles developed in the fields of mathematics, information theory, and computer systems engineering, sometimes at significant expense and considerable commercial risk.
The fact is that the vast majority of important code in the world – code that requires large investments in research, development, coding and testing – is not to be found in smartphone apps or on e-commerce sites. This code, whether embedded in products and systems, or used for their design and operations, is mission-critical, mostly proprietary, and carries with it huge liability in case of faults or failures.
To sum up: most business processes are not critically dependent upon software, and most software does not implement any business process. The PC’s ‘BM&S’ is a confected category which, if it exists at all, encompasses only a small (though, admittedly, disproportionately troublesome) subset of potentially patentable subject matter.
The Open Source FallacyOne thing you can be sure of, whenever there is a review of patentable subject matter, is that someone will play the ‘FOSS card’. This essentially consists of asserting that the existence of successful FOSS projects – such as the Linux operating system – and the increasing embrace of open source practices by commercial software developers, such as Google, Microsoft, IBM and Apple, is somehow evidence that the ‘software industry’ (assuming such a monolithic entity actually exists) would continue to invest and to innovate in the absence of patent protection, and even that proprietary models of software development are becoming obsolete in view of the wider benefits of open source development.
The draft report states (with citations omitted):
In the case of software developments, many owners do not protect their content at all. Indeed, rather than seek protection some developers share their code and encourage third parties to copy and contribute to the development of their software. This approach, referred to as open source, has been adopted by companies including Google, IBM, RedHat and Sony.
Open source approaches offer a number of benefits for both software developers and innovating firms. Developers derive a gain from making software, as it allows them to learn new skills from collaborators. Firms gain as open source approaches are typically more agile and adaptable and can be built to accommodate follow on innovations without the need for proprietary products, allowing for fast and dynamic improvements.
So, did the PC prepare its report using LibreOffice (version 5 being the latest and greatest agile and dynamic improvement) running on Ubuntu Linux for desktop?
Of course not. The metadata in the DOCX and PDF versions of the report available for download indicate that it was prepared using Microsoft Word on Windows, and that Adobe’s proprietary Acrobat PDFMaker 10.0 was used to create the PDF document.
I want to be very clear here – I am not in any way an opponent of FOSS. Proprietary and open source models are complementary to one another, and these days much software development lies somewhere along a continuum involving a mix of open source and proprietary technologies. Each has its place. I have a mix of commercial, free and open source software on the laptop I am using to write this blog post. The notices in much of the ‘proprietary’ software reveals that it contains a number of open source components.
While Microsoft obviously has its detractors, it has for decades now been delivering consumer- and business-grade software that has immeasurably enhanced the productivity of people throughout the world. With Windows NT and Windows 95, Microsoft brought full 32-bit multi-user, multi-processing operating systems to the masses by the mid-1990s, when Linux was still too unstable to be of any use to anybody but those working on its development. The same can said for many other proprietary applications that continue to deliver the levels of usability and stability demanded by businesses, and most consumers, where the FOSS alternatives still require technical expertise, self-support skills and patience that most users do not possess. I would count among these Adobe Photoshop, Microsoft Office, and all of Apple’s proprietary software.
Microsoft spent over US$11 billion on research and development in 2015, and was granted 1956 US patents. IBM invested US$5.2 billion, and received 7355 US patents. Google’s R&D spend was US$9.8 billion, with a haul of 2835 US patents. Apple spent US$6 billion, and was granted 1938 US patents. (R&D figures are from statistica.com, and patent numbers from IFI CLAIMS.) These companies, among others, are conducting quality research and development of new technologies and, accordingly, their patents are not, for the most part, directed to business methods or other non-technical matter.
Conversely, their size, depth of market penetration, and ability to subsume innovations developed by smaller companies and individuals (whether open source or otherwise) is, in the absence of patent protection for those innovations, essentially unrestricted. What is a small business, providing a successful add-in for a Microsoft product, supposed to do if and when Microsoft decides to deliver the same functionality to all of its customers worldwide as part of a routine automated update? Without effective IP protection there is nothing it can do.
The Myth of Rapid Development CyclesAnother claim about patent protection for software that is often made, including in the draft PC report, is that patents are unnecessary and largely worthless due to the rapid development cycle of software. As the PC report puts it (again, omitting citations):
The short innovation cycles means [sic] that innovators have significant first–mover advantages. Innovators can recoup some of their R&D investments simply from being the first mover. Trade secrets can slow down the competition, thereby extending first mover advantages. In some cases — perhaps many cases — the exclusivity period provided by the first mover advantage is enough to motivate R&D in BM&S, rendering patent protection moot. Indeed, the fast moving nature of BM&S development means that the commercial lifespan of a software program or feature is usually less than the time it takes to finalise a patent application — which in Australia can take up to five years.
The report also notes that ‘there were six full versions of the android [sic] operating software between September 2008 and October 2015’ and quotes one author as saying ‘the frequency of software release had been increasing since the early 2000s, and 10 years later, several companies were releasing new software multiple times per day’.
The problem with this analysis is that most of these software updates consist primarily of minor changes, bug fixes and plugs for security holes – many of which would not need fixing if the software had not been rushed out in the first place. Developing genuinely new and improved features, incorporating them into the product, and properly testing the entire application to ensure not only that the new features are stable and work as expected, but also that they do not break any existing functionality of the product, is not trivial, and does not happen on the short time scales suggested.
As for the supposed mismatch between patent terms, examination time, and commercial lifespan of software products, there are a numbers of answers to this. It is, for example, now apparent that some of the innovative (at the time) features introduced into early versions of software developed by companies such a IBM, Microsoft, Apple, Adobe and others, have a lifespan that is already measured in decades rather than months or years.
More importantly, however, for small businesses and start-ups, the fact is that the commercial success and longevity of a truly innovative development might not be known until some time after release of the corresponding product or feature. Any patent application should, of course, be filed prior to public launch or disclosure of the invention. However, the decision as to whether it will be worth pursuing the application in view of the commercial success of the invention can be deferred.
I agree completely that it is often not worth pursuing patent protection for incremental and/or short-lived software products and features (indeed, I have said as much right here on this blog). But this is not, in itself, a reason to exclude software from patentability entirely.
Conclusion – How Do You Solve a ‘Problem’ Like Software?Setting aside, for now, the flaws in the PC’s analysis, there is no question that the patent-eligibility of software has been under attack for some time, and that something needs to be done to address the real issues that exist.
As matters now stand in Australia (and in the US, though that is a separate matter) the position on computer-implemented inventions is highly uncertain, and almost unworkable. As I have recently discussed, the Patent Office’s examination guidelines arising from the Research Affiliates and RPL Central cases are resulting in subjective and inconsistent decision-making and, unless the High Court agrees to hear RPL Central’s appeal, there is little prospect of any improvement or clarification in the foreseeable future.
Furthermore, from what I have seen recently coming out of the New Zealand Patent Office, that country’s attempt to ‘bolt on’ a software exclusion to the ‘manner of manufacture’ eligibility test, as the PC is essentially recommending, is creating problems of its own.
These days, I much prefer dealing with the European and UK Patent Offices. While the laws across Europe expressly exclude business methods and computer programs, ‘as such’, from patentability, a consistent approach to this exclusion that does not prevent patenting of computer-implemented solutions to genuinely technical problems results in predictable outcomes.
Maybe it is time we dumped the ‘manner of manufacture’ test altogether, and followed the Europeans’ lead?