10 July 2016

An Audience with the Productivity Commission on the Patenting of Computer-Implemented Inventions

HearingOn Friday 24 June 2016 I attended a public hearing in Melbourne, conducted by the Productivity Commission in relation to its draft report in its review of ‘Intellectual Property Arrangements’.  I had made a written submission on the draft report, and the purpose of the Commission’s public hearings was to ‘provide participants with the opportunity to elaborate on their submissions, respond to submissions of others, and to discuss issues with Commissioners.’

The focus of my written submission, and the topic of my discussion with the Commissioners, was the chapter of the draft report dealing with ‘Business Methods and Software.’  The single draft recommendation to arise out of that chapter is that ‘the Australian Government should amend section 18 of the Patents Act 1990 (Cth) to explicitly exclude business methods and software from being patentable subject matter.’  I disagree strongly with that recommendation!

My full written submission is available from the Productivity Commission’s web pages relating to the IP review.  (A copy can be downloaded directly – PDF, 120kB.)  Full transcripts of the hearings, which were conducted in Brisbane, Sydney, Canberra and Melbourne, are also now available.

The following is an edited transcript of my appearance.  The Commissioners are Mr Jonathan Coppel (‘JC’) and Ms Karen Chester (‘KC’).  I have cut the length of the transcript by about half, and added some headings to flag the particular topics being discussed.  Other than that I have employed the usual conventions of ellipsis (...) to mark where text has been deleted, and square brackets to indicate paraphrasing.  Comments replacing longer passages are in square brackets and italics.  I have also corrected punctuation, mistranscriptions and typographical errors without providing specific indications (the convention, of course, would be to leave them in place and pepper the text with [sic], which is ugly and distracting).

The Relationship Between ‘Business Methods’ and ‘Software’

JC: Maybe I could begin by mentioning that we have had a number of other participants in previous days commenting on the Business Methods and software chapter of the draft report. One of the [points] that they have made is that it's better to think about business methods and software as two distinct forms of intellectual property. Listening to your opening remarks you seem to suggest the opposite, that a business method is sort of embodied in software and that the areas of intellectual property need to be looked at together. I was wondering if you could comment on the - - -
 
MS: I am sorry if I have given that impression. My opening comment was that your draft report had, in fact, brought them together into a single category. My belief and my written submission is that no such single category actually in fact exists. So the first thing you have to do is separate your thinking from this idea that there can be a ‘BM&S’, a ‘business methods and software’ category.
 
… I am not sure it is as simple as saying that business methods is one kind of IP and software is another kind of IP, because it certainly is true that software supports business processes and that software can support business processes in a variety of different ways.
 
I am not sure that trying to separate them in terms of, ‘Well, here is one sort of IP and here is another sort of IP’ is possible, but you do need to separate it as the Full Federal Court has effectively done in its three most recent cases in this area: the Grant decision, the Research Affiliates decision and the RPL Central decision. They have said quite clearly: a technological innovation is patentable; a business innovation is not.
 
So what they are looking at there is, where is the innovation?
 
[Here I presented an example of a particular (unnamed) multinational client, with customers, employees and an R&D presence in Australia.]
 
So there are huge amounts of technological innovation and technological R&D; there ae methodologies that they are developing that have wider application in large-scale transaction processing systems and database systems. Massive investments in that, and yet, a lot of it is regarded – from the perspective of patentability in what we are seeing from the examination processes not just in Australia but in the US as well – a lot of it is regarded as ‘business methods’.
 
Now, the issue here is that, yes, it is a business method; people don't invest huge amounts of money in these kinds of developments unless it's going to support their business and their customer's businesses. But in actual fact the investment and the research and development, and the deployment is in the technological platform that underpins that. And so it is important to focus on [the question]: ‘where is the innovation?’
 
[Have they just come up with a business innovation in which] the implementation is neither here nor there, or have they in fact created a technological innovation that has enabled that new service which otherwise wouldn't have been possible? So the distinction between what is a business innovation and what is a technological innovation is important. The distinction between what is a business method and what is software as distinct forms of IP, I think it not important in that context.

The Commercial Lifespan of Software

JC: You have given a number of examples. Do you have any sense as to the life of these - the commercial life of these examples? Software is typically associated with something that is pretty fast-moving. There are always new developments. If you could give us a sense as to the life of these innovations.
 
MS: Okay. The software that I worked on in the computer-aided design area, which – I was there from 2000 to 2002 … the product itself still exists. I noticed, when I looked recently, that they are still promoting one of the features that I was instrumental in developing while I was there, as one of the key features of the product that distinguishes it from their competitors’ products…
 
… the basic simulation platform that [the software] uses is originally an open source platform, a thing called Ptolemy created by the University of California at Berkeley. The work that we did was to say, ‘Well, there was no point in reinventing the wheel in that sense,’ and we were strong supporters of open source in a variety of ways. The new intellectual property that we created was in the specific models for the various devices and systems … that our particular product was designed to simulate, and in the new user interface features that we provided to make it much easier for our target users to access that.
 
So that kind of product has a long lifetime.
 
[Here I gave the example of IBM’s widely-used Transaction Processing Facility (TPF) platform – without actually naming it – which was initially developed in the 1960’s, had its first full commercial release in 1979, and has not had a new release since December 2005.]
 
This kind of software that does really important stuff and has to be really, really stable, people try to get it right and then leave it alone. There is a lot of software out there with long lifetimes. Again, we are far too accustomed these days to our smartphone apps updating every second day and annoying us with those notifications. We are far too accustomed to Microsoft and its … product-release cycles. That represents only a very small part of the sorts of industries that we are talking about that use software and programmable hardware as fundamental building blocks in everything they do.

The Limitations of Trade Secrecy

JC: There are multiple ways in which to protect the investment in research and development and in a number of industries, they don't use intellectual property laws at all. They rely on secrecy, which has a downside that it may never enter into the public domain. I am just wondering whether software is one of those areas where the ability to keep the innovation away from potential competitors is an option? How easy would it be to copy software, if it's kept secret, for instance.
 
MS: Well, setting aside straight copying which, of course, is covered by copyright, one of the issues with software is that there are a variety of ways in which you inevitably expose your innovation to the market and to your competitors when you release software products. One of them is that people can see the functionality on the face of the software. …
 
Reverse engineering is another and despite various technological measures to prevent that, pretty much anything that is done in software or in any form of programmable hardware is subject to reverse engineering, and the copyright protections that are supposed to prevent people from doing that for a variety of reasons really are not going to be effective in an industrial context. So that's the second - - -
 

JC: Why is that?
 
MS: Well, simply because there is no way to know. You can have a law that says it is illegal to … break the technological protection measures that have been put in place to try and prevent it, but you cannot know what somebody does in the privacy of their own research facilities. You cannot know that they are doing that in Australia as opposed to in India where no such law exists.
 
So in practice, you really cannot prevent the reverse engineering of software.
 
In relation to … the systems that I worked on in the simulation area, our customers were … highly qualified engineers who design telecommunications devices, networks or optical fibre systems. They didn't just want to know that our software worked because we said it did, they wanted to know how it worked.
 
So we actually published descriptions of our algorithms and the underlying theory in the documentation for that software. We had no choice, because if those researchers and designers didn't know that they could trust those models and how they worked, and what the difference was between one model and another, then they were not going to be confident using that software. So that's another example of where there's a problem.
 

The Limitations of Copyright Protection


KC: Mark, I just want to explore a little bit more the views that you espoused before around the ineffectiveness of copyright when it comes to coding, just to make sure that I kind of understand it. So you are saying that copyright is clearly a form of protection for coding, but it is more difficult to enforce those rights, because it is more difficult to detect when it is being breached. Is that what you're suggesting?
 
MS: I'll give you an example. I mean, suppose we take something like the CSIRO's Wi-Fi invention which, when it was first invented, really needed to be [implemented in] hardware. … [You can now do in software] everything that is required to implement what was invented at CSIRO.
 
If I do that and then I release that code, and somebody reverse engineers that – or perhaps I provide the source code and open source it, … and I say, ‘Look, there's a licence term here. You can do what you want with it for non-commercial purposes, but if you want commercial use then we require you to take a licence.’ Now, if I have only got copyright, what happens is that the code itself reveals the algorithm. It reveals the actual steps, general steps that you have to take. If someone takes that code and they just copy it and they just reuse it well then they have infringed copyright.
 
If somebody takes the code and they read it and by reading it they deduce the algorithm and they write down the steps of the algorithm in plain English or as a specification and then they hand that to another programmer who hasn't seen the code and say, ‘Look, we've got an interesting algorithm here. Could you write code to implement this?’ Now, that person hasn't seen the code, they haven't copied it. They haven't been given anything other than the underlying algorithm and been told, ‘Go away and independently implement this.’
 
That independent implementation almost certainly does not infringe copyright. … [What] you are seeking to protect with a patent in that case is the actual technology which you have developed which is then represented by a series of steps and an algorithm which can then be implemented in hardware or software in order to bring that into a product.
 
There are two separate things there. There is the expression of the work as there always is in copyright, that's the actual code, but there's the underlying idea of the work in this case, is perhaps the algorithm. Without the ability to protect what you have actually invented there, which is a new algorithm independent of how it is implemented, you have no way via just copyright to effectively protect that.
 
KC: So if we were to draw a parallel with, say, code versus say a book or a story, breaching copyright doesn't require a pure replication of the book itself. You can sort of still lift key ideas or, say, music as well and that can still be seen as a breach of copyright. What is it about the algorithm that sort of separates it from the coding? It is a function of the coding, so it is part of the embedded innovation. I am just trying to work out why the copyright then isn't effective.
 
MS: Well, again, using the Wi-Fi example, the primary claim in the patent that protected that innovation contains about three steps. … So that is the level at which you can describe that algorithm.
 
The code to implement that … would be many, many thousands of lines long. If I copy those thousands of lines or any part of those thousands of lines then I am potentially infringing that copyright. If I deduce the underlying algorithm and get it back to those three steps, that's the underlying idea. It's a technical idea. It isn't an aspect of what copyright protects in the code. The code is a particular expression of that idea.
 
… I think the fact that code is protected by copyright is as much as anything else a historical accident. … At some point, it was decided, ‘Well, there needs to be protection for software,’ and it was decided, ‘Well, let's pretend that’ – it is a legal fiction, I think, it takes no account of the actual process of technology – it says, ‘Let's pretend that code is a literary work and throw it in with literary works in the copyright law,’ which is now, effectively, the global approach, so I don't think it can be changed now.
 
Code is not a literary work. It is not the same sort of an expression of an idea that a literary work is an expression of an idea. I think, with the benefit of hindsight, a little bit more effort in devising a sui generis form of protection for software code might in fact have been a much better idea.

The Limitations of ‘First Mover Advantage’

[Here, Ms Chester moved the discussion on to the perception that software innovations have a short commercial life, and that ‘first mover advantage’ might therefore limit the value of, and need for, IP protections.]
 
KC: So is there a - sort of like a statistical evidence-base that we can look at to get a better handle on whether or not there is a misconception of most software being a very short commercial life, which is I guess what we have been drawing on in our report?
 
MS: I think the notion that software has a short commercial life - it's complex even in the case of the kinds of software that we look at all the time, in the sense that some features of software have a short life, [but] some features last for many, many years. Not very long ago, I wanted to retrieve the electronic of my PhD thesis which I wrote on Microsoft Word 2.0 in 1995. I was able to load that into the current version of Microsoft Word. The formatting was a bit off, but a couple of hours work and I was able to undo that and I was then able to save it back out in PDF which hopefully is a much more stable format.
 
… [A]lthough the application itself may be updated regularly, there may be underlying features are quite important that were quite innovative when they were developed that require real technical effort to bring into effect… [S]oftware products may evolve, but the core features … – the platform on which they were originally developed – may remain quite stable underneath the surface.
 
So the fact that we as consumers see software being updated regularly doesn't necessarily mean that all of the technology and research and development, and innovation that's gone into developing that software is becoming obsolete at the same rate. So that's one factor. You could ask Microsoft how much of the early 1990s Windows NT code-base is still is in Windows 10. I daresay it's not zero. So they might actually be able to tell you something like that, if they were minded to.
 
The other thing I would say about patent protection for software that does have a short lifespan – and we see many examples of smartphone apps for example that are fads and come and go, and things where there may be an opportunity that arises and then fades away – the patent system isn't well‑suited for that anyway. I don't generally encourage people who ring up and say, ‘Look, I've got this great idea for an app and I want to know how I get a patent for it’ - I don't necessarily encourage those people to pursue patent protection.
 

 
I think there is a serious problem with a misalignment between the way some people use the system and what is an appropriate use of that system. It doesn't mean saying, "We shouldn't let software be patented", what it means is making sure that people are better educated about the IP rights that are available to them and what's most effective in their business.

Conclusion – A Positive Experience

Overall, I found the public hearing process to be a positive experience.  The Commissioners were thoughtful and receptive, and I enjoyed speaking with them.

I am looking forward to seeing what impact the consultation process has on the Commission’s final report, which is due to Government in August, and should be published before the end of the year.

0 comments:

Post a Comment


Copyright © 2014
Creative Commons License
The Patentology Blog by Dr Mark A Summerfield is licensed under a Creative Commons Attribution-NonCommercial-ShareAlike 3.0 Australia License.