Today's Date: September 17, 2014 Search | Home | Contact | Services | Patent Attorney | Patent Search | Provisional Patent Application | Patent Application | Software Patent | Confidentiality Agreements

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


Written by Gene Quinn
President & Founder of IPWatchdog, Inc.
Patent Attorney, Reg. No. 44,294
Zies, Widerman & Malek
Blog | Twitter | Facebook | LinkedIn
Posted: August 22, 2014 @ 10:22 am
Tell A Friend!


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 HandbookVerilog Designer’s LibraryIntroduction to VerilogDesigning 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.





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

- - - - - - - - - -

For information on this and related topics please see these archives:

Tags: , , , , , , , , , , ,
Posted in: Bob Zeidman, Gene Quinn, Guest Contributors, Interviews & Conversations, IP News, IPWatchdog.com Articles, Patents, Software, Technology & Innovation

About the Author

is a Patent Attorney and the founder of the popular blog IPWatchdog.com, which has for three of the last four years (i.e., 2010, 2012 and 2103) been recognized as the top intellectual property blog by the American Bar Association. He is also a principal lecturer in the PLI Patent Bar Review Course. As an electrical engineer with a computer engineering focus his specialty is electronic and computer devices, Internet applications, software and business methods.

 

12 comments
Leave a comment »

  1. Is it really my invention if I hire 10 people, and what I say to them is, go create a device that records the exact dimensions of an object in 3D space. Or is it the invention of the people that actually came up with the solution and created the device in the lab? I realize a lot of people assign their invention to the employer, that’s not what I’m asking.

    If I hire 10 people to create something I thought up in my head as a thought experiment, and I don’t require them to assign me the invention as part of an employment contract, who’s invention is it? My understanding is it would be those 10 people’s invention, and they could patent it.

    Now, if I think up something as a thought experiment in my head and I say ‘Gee, it would be nice if my computer did X’, and 10 people have written a tool that I can draw a picture of something, and the computer then writes a program based on that, is it that I’ve invented something, or has the computer invented it, or has the people who wrote the program invented it? The problem I see is, things are becoming so abstracted, and the tools so powerful, that if Mr. Quinn and Mr. Zeidman have their way, then in 100 years the guy who just thinks up ‘Oh, I would like a program that fills out my taxes for me’ and tells the computer to do it, then he’ll have a patent on ‘filling out my taxes’.

    A lot of the problems that people have with software patents is that they don’t patent a way to do X, they patent the concept of doing X. And the more abstract you allow that to get via the use of computer aided drafting and computer aided programming, then the more the patent system breaks down. The patent system is not supposed to be about locking people out of the market. It’s supposed to be about fostering invention and encouraging disclosure, so that people figure out multiple ways of doing something. The person who figures out the most efficient method will make the most of his patents.

    Software patents however, usually, broadly cover ways of doing X without specificity. The more abstract you make them (that is, the less specificity on exactly how you are doing X) the more you are locking up the idea of doing X, rather than the specific way of doing X. It would be like getting a patent on the idea of runflat tires or recycled tires, rather than the patent on this new type of tire that can go 200 miles with a hole in it, and it’s made of recycled paper rather than rubber, and here’s how the recycled paper is made into something we can make a tire out of.

  2. Even though the courts are maddeningly incapable of distinguishing novelty from non-obviousness from subject matter eligibility from enablement, they do seem to be able to make the right bottom-line decision in most cases, albeit based on flawed reasoning. Of course that results in bad precedents and bad case law, but since they routinely ignore or reinterpret past decisions anyway, maybe that is not as big a problem as it might be. I think it mostly comes down to the strength/quality of the underlying invention. Good patents will generally withstand judicial review, and marginal ones won’t, even if the reasoning of the court is completely muddled.

  3. Good comment from Ron Hilton. I agree.

    Trouble is, what was thought to be a good invention very often turns out not to be, following objective accurate assessment of the state of the art. It then becomes a matter of salvaging what is still patentable, after the carnage.

    For that, you need subject matter you can claim, and (as Ron points out) a supporting description good enough to convince the court that what is NOW claimed is distinguished, by a genuine inventive step, from the totality of the prior art .

    Draft poorly, and salvage is beyond the capabilities of your prosecuting attorney. Draft your patent application competently though, and you can still have exclusive rights commensurate with the real contribution you have brought to the art.

    I think drafting competence is still deeply undervalued. I think incompetent drafting has ben tolerated till now, but not for much longer.

  4. “but maybe the code needs to be included in the patent and referred to in the claims.” imagine that. it is no wonder to me why there are so many difficulties around software in patents. it’s because this simple statement appears a novelty to some people. the code (i.e. “algorithm”) must be described and claimed in the patent because that’s what the inventor MADE. absent an algorithm, the inventor has not disclosed the invention. the only algorithm that needs to be disclosed is the one that supports the claims. if you withhold it because it’s a trade secret, then it can’t be claimed.

  5. Gene – not sure who you’re responding to in #4 other than Bob Ziedman in your original interview, but I’ll oblige you and play devil’s advocate. If it takes a significant amount of actual code to disclose the invention, then the resulting patent claims are likely to be so long and involved as to be fairly worthless from an IP standpoint (not much more protection than a copyright).

  6. An algorithm is not code.

  7. like any mechanical patent application where more details need to be included in the claims to get around prior art, algorithm claims will require as much detail as necessary to be allowable. one must understand that the first thing a programmer thinks about when presented with a software design challenge is — an algorithm. one cannot code if one doesn’t first have an algorithm in mind. secondly, one can have a good algorithm in mind which might take weeks and hundreds of lines of code to complete. one can describe an algorithm in a few sentences and the code which performs that algorithm may occupy many pages. nonetheless, defining the algorithm describes what the programmer-inventor made.

  8. are the cafc decisions in Aristocrat, or Net Moneyin (or even WMS Gaming from 1999) that far afield from Alice?:

    “Although Aristocrat argued that the structure corresponding to the recited functions was a standard microprocessor-based gaming machine with “appropriate programming,” the court noted that the specification contained no “guidance to determine the meaning of ‘standard microprocessor’ or ‘appropriate programming.’” The court ruled that “[m]erely stating that a standard microprocessor is the structure without more is not sufficient.” In particular, the court noted that the specification did not create any specific structure or new machine because “it does not set forth any specific algorithm” for performing the recited function.”

  9. Honestly, one of the things that always infuriates me about (what I consider) to be ‘bad patents’ in software is the lack of actually defining anything that actually tells me what is invented. It’s just a paragraph description of the concept, not the specific solution being patented. Put in the specific algorithm (as stated above, an algorithm is not the code, for those non programmers, the algorithm is the recipe, the steps to take, with specificity, where as the code is more akin to the dish being prepared). Most software patents that end up being termed bad (I won’t comment on just how many those are considering the host’s feelings) are written to cover as much as possible without disclosing any sort of algorithm, just the basic concept of the ‘invention’.

    Nobody would allow a patent on brakes that said ’cause friction to slow the car down’ but things that vague ‘on a computer’ are just fine, up until recently.

  10. Unfortunately “algorithm” has become a forbidden word in patent prosecution, because it is viewed as being too abstract and akin to pure math. IMHO, it ought to be sufficient to add the limitation that the algorithm is a computer-implemented process, or better yet, just call it what it is: software! But the “software=math” zealots have poisoned that simple solution. I typically do a fairly detailed “method” flowchart that is the equivalent of an algorithm, making it clear that it is intended to run on a computer, but avoid using the evil terms “algorithm” or “software” in the description.

  11. Ron,

    I must ask (and I hope you realize this is tongue in cheek): are you one of those “@^%#&$” scriviners that the Supreme Court is seemingly always upset about?

  12. Guilty as charged :)

Leave Comment