A Conversation About Software and Patents: On the Record with Bob Zeidman

Bob Zeidman is know to our readers as an occasional guest contributor. He is also the president and founder of Zeidman Consulting, a contract research and development firm in Silicon Valley that provides engineering consulting to law firm. He is also the president and founder of Software Analysis and Forensic Engineering Corporation, the leading provider of software intellectual property analysis tools. In short, Zeidman is a software expert in every sense of the word “expert”, he holds numerous patents and he is prolific author. He has written four engineering texts—The Software IP Detective’s Handbook, Verilog Designer’s Library, Introduction to Verilog, Designing with FPGAs and CPLDs, and Just Enough Electronics to Impress Your Friends and Colleagues—in addition to numerous articles and papers. He has also written three award-winning screenplays and three award-winning novels including his latest, Good Intentions, a political satire about a future dystopia.

On August 12, 2014, I had the opportunity to speak with Zeidman on the record. As the dust begins to settle from the Supreme Court’s Alice v. CLS Bank decision I thought it might be interesting to talk about the issues with a computer expert who regularly works with patent attorneys and technology clients, and who has been advising both attorneys and clients how to handle the Alice decision from a technical standpoint. In our three part interview we discuss the decision and various ways attorneys might be able to move forward to provide disclosure sufficient to satisfy even the Alice standard.

Without further ado, what follows is part 1 of my interview with Bob Zeidman.

QUINN: Okay, Bob, thanks a lot for taking the time to chat with me today. I really appreciate you getting on the line to talk about these issues. There is a lot going on this summer with respect to software and I thought who better to ask some of these questions to then you. I know you’re a software expert, so I thought it might be good to get perspective from someone who understands the technology on a deep level. So I thought we could begin with the Supreme Court’s decision in Alice v. CLS Bank. Lawyers can read a decision and understand it to some extent I suppose, but there’s not a lot of “there” there. Unfortunately, the Supreme Court left a lot of things unanswered. But one of the critical questions is how do you construct a description of software now so that it can be patent eligible?

ZEIDMAN: Thanks, Gene. First of all thanks for having me and I really appreciate the honor of being in such a prestigious blog site as yours which I read regularly. You know, I read over the Alice v. CLS Bank court ruling and found it to be pretty interesting. Previously I’d read a lot of commentary on it but I hadn’t specifically focused on the ruling itself. I do have comments, some high level comments and low level comments, so I don’t know which you’d prefer me to get into first.

QUINN: Well, let’s start from a high level view of what your thoughts are and then we can get into the nitty-gritty from there?

ZEIDMAN: Sure. Well, first of all about the ruling itself, I was surprised at how relatively short it was and to me it didn’t clarify much. I’m familiar with the cases that it references and still I found it confusing. I think software is something that is very, very new in technology and I’m starting to believe that patent law just really doesn’t understand software. I won’t say that lawyers don’t understand software, I think they do. But when I look at this ruling it is very specific about specific things. 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. I think it’s still very inventive–I don’t want to be misunderstood. But for example now days you can draw a diagram, there are programs that will allow you to draw a diagram and software tools will turn that diagram into a working functional invention. The user doesn’t have to quite understand how the electrons are going through the circuitry or how the processor is writing things to a buffer. The programmer has to understand very high level concepts and that will be translated into something that is an innovative, novel, and in my opinion patentable invention.

[JV-3]

QUINN: That is what is being called computer assisted innovation, correct?

ZEIDMAN: Yes, there have been a number of terms since I’ve been in the industry. Computer aided engineering, computer aided something or other. But if you look at even programming languages in the early days if you go back to the, well, if you go back to the 1950s, let’s say, people had to actually move plugs around there was something physical they had to do. And then after that with assemblers they had to write at a very low level and say what was the processor doing at a very low level, nearly each cycle of a clock that’s running the processor. They’d say well first add this number to that number; it was very detailed.

Then you got to high level languages like Basic and C where you could write at a high level and not worry about which processor you’re using. And this is an issue because the courts don’t like generic processors, but the problem is that all software tools these days are designed to run on a generic processor so that you can use any processor that you want. The tools are getting more sophisticated. The programmer can write a very interesting, unique algorithm and not worry about the specific processor it’s running on. You can even create a program by drawing diagrams where you can say I want this kind of function connected to this kind of function and it’s something nobody thought of before. This program will have the computer do something unique whether it’s control of process or do a calculation or display something on your screen. But the programmer doesn’t need to know which processor is in the computer, how the processor works, the speed of the processor, how the electrons are going through circuits, things like that.

QUINN: Yes.

ZEIDMAN: By the way, I see this— I think some other people have written about this, too, but it occurs to me that the same thing may be happening in mechanical engineering with respect to mechanical patents with the advent of 3-D printers.

QUINN: Right.

ZEIDMAN: You no longer have to choose a gear and know the ratio, they can just say here is the thing that I want, go make it.

QUINN: Yes. And there’s also been some discussion about this with respect to pharmaceuticals as well. Because if you know what the lead compound is that you need to start investigating then the compound or resulting pharmaceutical almost invents itself, which is a bit of an exaggeration but not terribly so because the real inventive step is figuring out among all the possible candidates where to begin to investigate and why. And what’s happening is in that space, like in so many other spaces, computers and the software are getting better and better in allowing for a time where you could envision that it could be completely computer assisted to get to that lead compound in which case pharmaceuticals might no longer be patent eligible.

ZEIDMAN: I agree. I think it’s possible that—maybe we haven’t reached that point yet—but it’s possible that in the near future we’ll need to really redefine what is an invention. The courts seem to be saying if it’s a computer aided invention, it’s not patentable. I don’t like that and I hope that’s not the way we go, but maybe we should start thinking along those terms whether it’s software or pharmaceutical drugs or 3-D printed mechanics.

QUINN: Yes. I think that is a problem. And I think particularly in this case where they start distinguishing the Diamond v. Diehr where there was a computer program process for curing rubber was computerized. The industry always believed that case was the Supreme Court’s rethinking of the prohibition against software being patent eligible. But now they seem to be saying that the process in Diehr was patentable in spite of the fact that it was a computer implemented process because it resulted in a tangible product. And maybe there’s no way around this when you have judges that are in their 70s and 80s making these decisions. These are not people that grew up on a computer, they did not grow up on the Internet, and they don’t even use e-mail.

ZEIDMAN: Right. The Supreme Court’s comments in Alice v. CLS Bank regarding Diamond v. Diehr surprised me because it seems that they’re saying that Diamond v. Diehr had nothing to do with the computer or the program, it had to do with an improvement over an existing process. But my understanding is the program itself that controlled the mechanism was inventive. And they seem to be saying here, no, it’s not the program itself, rather it’s this improvement over a previous process that makes it inventive.

QUINN: I think you’re right. And I think that’s scary because then it almost means that in order for you to have a significant hope on getting a patent on your computer implemented process it needs to improve a previous process that the court would recognize as something that could be patented. The Court seems to want a real world parallel. But we are seeing a fundamental shift in innovation. Software and computers are able to do things that heretofore we really haven’t ever been able to do and there isn’t a real world tangible parallel.

ZEIDMAN: Right. Right.

QUINN: So what does that mean for patent eligibility? When I was reading Alice I was struck by the way they interpreted Diamond v. Diehr in the same way that a lot of the people who would prefer not to have any software patents, or any patents at all, read it. That was not the way the industry had ever read Diehr, and this reading is worrisome.

ZEIDMAN: I read it the same way. And I think it is a problem. But then in my mind they say a bunch of contradictory things. One of which strikes me in particular is how they repeat over and over again that something shouldn’t be patentable because of the draftsmen’s art. And they say that you can’t just add the words “use a computer to do this.”

QUINN: Yes.

ZEIDMAN: And yet I think they’ve opened the door for making software patents exactly dependant on the draftsmen’s art because as you and I have seen over the years, every time there’s a court ruling it just means that you have to word the patent claims differently. None of the software patents have changed, they’re just worded the claims differently.

QUINN: Well, that’s right. And I think what we will see is a move towards the way that software was patented in the mid-to-late 1970s, because it was in the beginning of the 1970s that the Supreme Court said that software was not patentable with the Gottschalk v. Benson decision. After that you didn’t claim it as software, but rather you claimed it as a machine that provides the desired functionality.

ZEIDMAN: Right.

QUINN: And I think to some extent with a lot of these claims, by which I mean those in patent applications that are in and patents that have already been issued, are in trouble. I think people might want to be thinking about giving up the method claims or disclaiming the method claims. Then let’s have the discussion about whether a machine is not patent eligible any more simply because it incorporates a computer implemented process. Because that’s what a system is – a system is a machine. Unfortunately the patentee in the Alice case wound up arguing that the system claims rise and fall with the methods claims, which I think strategically was a mistake. The systems claims incorporated the real world tangible things you can touch. And maybe it wouldn’t have made a difference, particularly if they took the approach used by the Patent Trial and Appeals Board that literally seems mandated by the Supreme Court decision in Mayo v. Prometheus, but it would have been a much harder case because then the downstream ramifications would have been a lot more clear, I think.

ZEIDMAN: Yes, I noticed the court was not happy with the plaintiff’s arguments at all and pretty much dismissed them time and time again in the decision. I see a lot of places in the ruling where it basically–how should I put it–belittled the plaintiff or criticized them, I guess, for making arguments that they said were irrelevant.

QUINN: I’m not sure that the arguments that were made were the best arguments, but I don’t think they were irrelevant. I think there were probably other better arguments to be made but at the end of the day I don’t know that this would have mattered given the decision that we got. It almost seems like they had made up their mind, which is the real story. I mean one of the things that I’ve kicked around with some folks is my growing concern that if a judge can understand what it is you’re trying to patent then it’s going to be patent ineligible and/or obvious. I think the judges look at this and they say, oh, there’s no invention there because it makes sense to them. They don’t think anything about how the invention comes into being. I almost think that in these patent applications that deal with computer implemented processes you may need to layer on heavy technological description in a way that you may only have previously put into a design document written for those who understand the architecture, technology and how to write code. This is problematic because your average judge who is not a science or computer major, they might be a history major or English major, so it will be better if they can’t understand it because maybe then they might be more inclined to acknowledge the processes as innovative.

ZEIDMAN: You know, I think you’re absolutely right. I thought of the same thing but not in those terms. I’ve been thinking about it and advising some companies. I read the Alice patents and what I thought was, well, when the claims say to save some number for future use, I thought well any programmer knows “save” means save it in memory. Or when the claims state to “store” information for later retrieval this means store in a database. And I think one of ordinary skill in the art would understand that from the simple wording in the CLS patent claims. But the judges saw that anybody could understand the claims and therefore they’re not patentable. So I’ve been advising clients and colleagues to put in specifically “store in a database” or “save in a buffer” because then it makes it something technical. I don’t think it really changes the claims but it makes it something where a judge can look at it and say, oh, yeah, that’s technical, that’s patentable.

QUINN: And I think a lot of the drawings don’t do anybody any favors in a lot of these software patent applications. When a lot of them are just a flowchart with one box leading to another box leading to another box all in a line, you look at this and think there has to be more. You know? I mean that’s not software, that’s not how you write it out when you’re sketching it, you know, there should really be flowcharts and a line is in my mind not a flow chart. It is as if computer logic isn’t taught any more. In college we had to take a computer logic class to get our electrical engineering degree, and our assignments were flowcharts, and I can tell you none of them were what you typically see in a patent application, they had substance and conveyed meaning.

ZEIDMAN: Yeah.

QUINN: And every one of those boxes in that simplistic flowchart, or line chart really, could be a series of complex flowcharts and I think that’s the way we probably have to go. But I’m getting worked up. Let’s take a step back. What tips and tricks other than the one that you just gave us do you think maybe we need to be considering when we’re writing these patent applications to make it more concrete so they can really be seen in a way that allows others to appreciate it as an innovation?

ZEIDMAN: Well, I’m not sure but another thing that’s crossed my mind that I think some companies will not be happy with, but maybe the code needs to be included in the patent and referred to in the claims. I think if a judge sees, or a patent examiner sees code maybe they’d be more inclined to say, okay, this is a series of complex steps performed by a computer. But without that it seems more like an abstract idea.

QUINN: Well, that’s interesting that you say it. I hadn’t really thought about it in that way. I’ve started talking about whether code, or some code, might be better off to put into an application for disclosure purposes. And also to some extent in order to make sure there’s a “there” there, to show we’re not theorizing about this, this is not something like in the early business method patents where we had no idea how we were gonna pull it off. I think maybe that is a good suggestion because that would seem to suggest that there really is something that’s built. There is a prototype. This is not just ephemeral or a thought project – it’s real.

ZEIDMAN: Right. One of the reasons there’s an explosion in software patents is that it’s really easy to create a software patent without having written the code. And I’m not saying that’s a bad thing. But I do know, I have seen patents where there have been code snippets that don’t work. And I think that’s one thing to be careful of. Because I believe that can invalidate your patent forbeing non-enabling.

QUINN: Yes.

ZEIDMAN: And I think there’s going to be a gray area there if companies do put code snippets in they probably don’t want to include their entire code because not only could that be huge, but that could give away trade secrets about other inventions that they don’t want to patent. On the other hand, once you include snippets without including all of the code, there could be stuff that actually doesn’t work because you haven’t initialized variables or put in some key line of code such that without that specific line of code the invention doesn’t work.

QUINN: Right. So that’s fraught with risk, too.

ZEIDMAN: Yes.

Click to continue reading