On August 12, 2014, I spoke with computer expert Bob Zeidman (pictured left) on the record for an in-depth interview that published on IPWatchdog.com. The interview lasted approximately 1 hour and 15 minutes and was over 11,000 words in length. I think it was an excellent and intriguing discussion about the reality of software, both from a coding and market perspective. We also spoke at length about the Supreme Court’s decisions in Alice v. CLS Bank, Bilski v. Kappos, and Diamond v. Diehr. We also discussed what type of disclosure might be enough to satisfy both the Patent Office and the Supreme Court, which is increasingly becoming the arbiter of all things patent-eligible.
While a lengthy conversation like this would be of interest to those who work in the area, there were a number of intriguing points raised during our interview that I hope all patent practitioners would be interested in. For that reason, I offer here highlights of the interview. For the complete interview, please see A Conversation about Software and Patents.
On software turning the abstract into something functional and useful:
ZEIDMAN: I think a lot of the rulings about software patentability are very specific and I think it’s creating problems because software is evolving very rapidly. Modern software tools allow people to turn fairly abstract ideas into reality. That’s the beauty of software. You can start describing things in such a high level and yet output what I consider an innovative invention. And so how do we separate abstract ideas that are unpatentable from an actual software implementation is going to be really difficult. And I don’t think this ruling helps. I think maybe it muddies it a bit.
QUINN: Can you give me an idea of what you’re talking about with respect to making the abstract ideas a reality where previously that may not have really been possible?
ZEIDMAN: I think if you look at inventions before software, an inventor had to create something physical. That meant the inventor had to describe every aspect of the invention that wasn’t well understood. Obviously, there were things that are well understood, like mechanical principles and physical principles and electrical principles, but patent examiners and the courts understood that there was something physical there and so it was easy to say ‘is this a gear, what are its ratios, how does it connect to this other gear here.’ Whereas nowadays, with software, an inventor will start taking things that sound very abstract and write them down. And then another piece of software—a compiler or now there’s even more advanced software tools—that will take that description that sounds very abstract and turn it into code that will run on a computer that consists of just electrons doing some work. The point is that the description of it sounds very abstract.
On computer programmers thinking programming is something everyone can do:
ZEIDMAN: You know, there was a really eye-opening experience for me when I debated a Berkeley professor a few years ago at the Computer History Museum about software patents. Should software be patentable? And I thought I had come up with this great idea that was going to basically get the audience to come over to my side in the first five, ten minutes of the debate. What I did is I asked how many in the audience–there were about 300 people including Steve Wozniak, by the way–and I asked how many people have written software? I think every hand in the audience went up. And then I said okay now put your hand down if you think that pretty much anybody could write software. And you know almost every hand in the audience went down.
QUINN: Wow.
ZEIDMAN: What I expected– I thought these people must respect that what they do requires at least a four-year education plus experience. All of us have complained about programmers who don’t know what they’re doing. All of us had assignments where we couldn’t figure it out–it took us a long time–and we were really proud when we figured it out. But somehow I think they’ve been brainwashed to think that what they do is just not that big a deal.
On the practical difficulty of using open source code:
QUINN: And one of the other problems that I find a lot of times is if you’re trying to get somebody to work on something that’s open source, that they didn’t create and they’re not familiar with, it’s problematic because they’d almost be better off starting from scratch and doing it their way so that they know how everything’s happening and they know where all the problems are from a debugging standpoint.
ZEIDMAN: Absolutely. My own experience was that we have a tool CodeDiff that finds differences in lines of code between the source code of two different programs. My original thought was that I’d go get an open source diff program; these things have been around for years. But I need to report some metrics about the differences—percentages of differences for example. So I thought, ‘well I’ll just get some open source code program that finds text differences and determine where in the code it’s finding out the differences, and I’ll put in some variables that keep track of that, that just keep count, and then I’ll put in code to print out some statistics.’ Now I’ve been programming for a long time, and I can’t remember any code that I couldn’t figure out. And for a living, I reverse engineer code and testify in court. Yet I could not reverse engineer this code. Every time I touched it to make some kind of change to test it, the whole thing broke. And I finally had to write the code completely from scratch because this open source code was such a kludge, such a mess, that it was impossible for me to figure out.
Tags: Bob Zeidman, computer programmer, computer software patents, first action interview, Open Source, patent, patents, software patent, software patents
You share in the PLI Practice Center community, so we just ask that you keep things civil. Leave out the personal attacks. Do not use profanity, ethnic or racial slurs, or take shots at anyone's sexual orientation or religion. If you can't be nice, we reserve the right to remove your material and ban users who violate our Terms of Service.