Software Patents: The Engineer vs. Designer Perspective

On March 25, 2013, I spoke on the record with Eric Gould Bear (left) about all things software, from designing software, to drafting patent applications to litigating. Bear is a successful inventor with over 100 patents and patent applications to his name and a testifying expert witness. He has worked with numerous Fortune 500 companies and has a unique perspective of expert, creator and fan of those who innovate in the software space.

In Part I of our interview, titled Designing Into the Path of Disruptive Technology, we discussed the journey from ideas to designs that establish a technology platform. In Part II, titled Software Patents: Drafting for Litigation and a Global Economy, we discussed (among other things) the unfortunate reality that the top technology innovators simply won’t listen to licensing overtures unless they are first sued. In the final segment, Part III, which appears below, we conclude our discussion of litigation, discuss working with patent examiners and then end with a discussion relating to the reality that an engineering mentality is very different from an experience design mentality, at least relative to development of software.

Without further ado, here is the final installment of my interview with Eric Gould Bear.

[Interviews]

BEAR: That raises another interesting issue in the patent space about how claims will be interpreted in court. Are they going to be read from the perspective of a user experience, or are they going to be read from the perspective of an engineer? I’ve run across this issue in depositions and in Markman hearings – where you’ve got an expert on one side who’s looking at the user experience of an invention. And on the other side, you’ve got an expert who is looking at the raw engineering variables.

Take, for example, a segment of video. One person may be talking about the segment as defined by how the user sees it. If you were watching a show from the beginning and then you hit pause, we can talk about the first segment of video spanning from the beginning until the pause point. And then, say they’re listening from the pause point to the end. We can say it has two experiential segments of video. But an engineer might look at the word “segment” and say, “It has to do with how it’s encoded on disk, and it doesn’t matter what the user does on the front end.” If it’s not clear in the specification what level of analysis to apply, then you’ve got chaos when it comes to interpretation of a user experience patent. There’s a good chance one party is going to bring engineers – or at least an engineering mindset – to the table.

QUINN: Right. Right. And that’s why I think with these things that you want to describe them in both ways. You want to describe it from the user’s perspective and you want to describe it from the engineering perspective. Then I also think – and I encourage people to look at this – from the computer’s perspective because, you know, what role does the computer play? You almost have to conceptualize the computer – as a person or human that is involved with taking these instructions and doing these various tasks. So you have these three different perspectives. You have the computer on the input and output side, then the person who the output is intended for, and the person who is doing the inputting into the computer to get the computer to do what you want it to do.

BEAR: That’s a really great way of thinking about it. And it seems to me that if you were to take that perspective, then you could preemptively avoid divided infringement. Write your claims so that the one party, if they’re not taking a particular action, is able to be responding to another party who took that action or getting the output from another party who took that action – parties being, in this case, machines or systems.

QUINN: I think that’s exactly right. You’re describing the invention from another perspective probably because you want to have each little slice of what could eventually be done – because under the law we have today, the likelihood that one party is doing all of the system is pretty low. You have to describe it from the overarching system view, I think, so people can understand, you know, from A to Z what is going on here. You want the patent to, at the end of the day, be a document that has multiple purposes. One person might be interested in licensing it or may be not deeply involved with technology, but are business people who can understand what it does and why it’s important. Another group may wind up being the judge and jury; and in almost all cases they’ll have zero scientific background. There are a number of district court judges that are getting heavily involved in doing patent cases which I think is good, but still they’re not scientists.

BEAR: Right.

QUINN: That’s another kind of a lay audience. So you have the big overall perspective, but then if you don’t dissect it into the variant pieces and parts of the input, the output and all the stuff that goes on to match the inputs with the outputs and all the calculations and machinations that make it worthwhile, then you’re allowing divided infringement to potentially be an issue. And I don’t think we’ve seen the last on the divided infringement cases. To be honest, I’ll be a little bit surprised if at some point the Supreme Court doesn’t weigh in on it. So we’re in this uneasy timeframe right now where I don’t think we really know what the ultimate end is going to be on divided infringement.

BEAR: Well, it seems to me you have the benefit of the inducement ruling changes.

QUINN: It’s interesting to hear you say you’ve got to think of what people are going to be doing in five to ten years. And with your claims written in a way that could capture those technologies that right now may seem fanciful like they’ll never happen, but they’re really trying only ten to fifteen years away max. One of the things that I try and do is think about where are the courts heading with the way that they’re interpreting these things – because by the time you file it, the patent issue may maybe four or five years down the road. I mean, you can get it much quicker if you want to accelerate. You can get it within six months or a year, but that comes with an extra fee. I think that fee is very worthwhile because it cuts down the time you have to wait, and expediting probably cuts down the amount of expense in getting the patent. But by the time you get the patent you’re usually years down the road. And by the time you get to the point where a judge is ultimately going to decide what the claims mean, if there’s infringement going on you’re even more years down the road. So in five to eight years from now, what are the courts going to expect to see in these kinds of applications. It’s frustrating from a drafting perspective, because once they announce these rules they extend retroactively saying this is the way it always should have been.

BEAR: I’ll tell you a funny story. There’s a family of patents that I first filed in 1992. I called the first prototype a “Relativity Controller” because it could perform non-salience de-emphasis based on a user’s unique point of view. The newest batch of those patents just issued in the last month or so, and we were working with the same examiner from 1992 through the end of 2012.

QUINN: Wow!

BEAR: And we got to know each other because we would spend time going back and forth to the patent office and sitting down together. It was great. I learned so much from this man about how he saw things. We thought we drafted the claims in a way that was airtight. And his interpretations could have easily been taken as misinterpretation. But he was spot on with finding holes in our language. It was frustrating, but always helped us perfect the patents. Once, he was caught in the middle of the computer readable medium issue, you know, with it being potentially interpreted as including propagated signals.

QUINN: Oh, my goodness!

BEAR: So he had us amend the claims – I can’t remember the language exactly – qualifying “computer readable medium” with “that isn’t a propagated signal or a carrier wave.” In fact, the language I wanted to use – and this is why I don’t prosecute without patent counsel – would have simply said, “a statutory computer readable medium wherein da, da, da.”

QUINN: Yeah.

BEAR: The rulings keep changing, so they make us dance all over the place. What I’ve done in my most recent applications is put it into the lexicon. I defined “computer readable medium” and “computer readable media” as interchangeably meaning storage that can be accessed by a computer that explicitly does not include any propagated signal, any carrier wave or any other non-statutory subject matter. I just put it in writing to get ahead of future foolishness.

QUINN: Don’t get me going on the propagated signals. I mean, I can’t believe that case came out. I find it embarrassing that the Federal Circuit treats propagated signals as non-existent. They actually really do exist.

BEAR: You were commenting on projecting where the courts are going to be in the future. Who knows what’s going to happen?

QUINN: Who knows?

BEAR: There’s always going be goofy stuff like that.

QUINN: The one thing that I think that it’s safe to say though is – whatever you think the requirements are today in terms of the amount of detail you need to include – far more detail will be expected by the time the patent becomes litigated.

BEAR: Yeah.

QUINN: So gone are the days – and they’ve been gone for a while – that you could get cheap software patent that was at all relevant. And I think now there’s probably a whole lot of software patents that you could probably wind up getting today issued that by the time they would become infringed or litigated or reviewed will not stand the test because they just don’t explain enough. They assume too much or they don’t define enough. I’ll give you where I’m going with this. There’s a real aversion it seems in a lot of corners – for designers and inventors in this space – to actually take the time to put together flow charts, for example.

I struggle to get clients to do that, and it’s like, “How are you going to have any hope of putting this thing together if you don’t do flow charts?” I’m an electrical engineer, and we were taught that early on when I was doing coding. If you don’t have a flow chart to go back and look at, what’s your reference point? How are you going to know? We used to do flow charts upon flow charts upon flow charts. That’s the way I think and that’s the way I initially attack designing something. You just drill down deeper and deeper in terms of the flow charts until you’ve got the makings of something that really can turn rather easily into a design document. And if you do, you have something that relatively easily turns into a patent application.

BEAR: Exactly.

QUINN: And there’s a lot of work involved.

BEAR: No doubt.

QUINN: But, you know, there has to be a systematic approach to these things and I think one of the main pitfalls is not approaching these kinds of projects like an engineer. The engineering mentality is very different from the computer science mentality, for example. An engineer approaches a project as a system that has a lot of pieces and parts that need to work together, and which need to be accounted for and tracked. Computer scientists see the world in code and typically jump right in and start coding without giving lot of thought to the system dynamics. Computer scientists also tend to document what they are doing within the code itself, making it impossible to easily figure out the broader context of what is going on. Writing a patent application when the only documentation is buried in hundreds of thousands or millions of lines of code is practically impossible. Understanding the overall architecture down to the specific subroutines is critical, and I just don’t know how you do that without proper documentation and to me that means flowcharts.

BEAR: What’s important about that is to show change over time and how things work over time. I’ve personally illustrated many of my own figures and flow charts. As a designer, I just like to be hands on, managing the quality of the work and making sure it communicates exactly what we need it to say. And, I’m the same in preparing for court. I like to create demonstratives and be the one giving tutorials to the court – because live presentations are often the best way to communicate how something works.

Another visualization technique that’s really effective is storyboarding. Storyboards can show the change in a system over time. If this is the position of the device and this is what you see on screen at time T1, then at time T2, this is the position of the device and this is what you see on screen. And then at time T3, this is the position of the device and this is what you see on screen. Describing actions with pictures removes ambiguity about the user experience and establishes some defense of how the system is claimed to operate.

QUINN: I totally agree. You know, it will be interesting to see where this evolution goes and there are still people who would rather not have these things be patentable. I just don’t get that. To pretend that it’s the hardware that’s unique seems to be extraordinarily naïve. It’s not the hardware, it’s the software and –

BEAR: It’s the user experience. It’s how it all comes together.

QUINN: Right. And to think of things as not being innovations is mind blowing.

BEAR: You wrote a great op ed piece the other day on Mark Cuban. Gave me a private smile.

QUINN: Thank you. I’m glad you liked that. In no place more so than the software area, I get really frustrated when people talk interchangeably about innovation and new product. And not “new” meaning “different,” but just another version. If you are blocked by a patent and you throw up your hands, “I can’t do this,” then what you’re doing is not innovation. You’re just being blocked from copying what other people have done. But innovation is about building something new – and for reasons I don’t necessarily understand – many in the news media really don’t seem to understand that. They talk about patents blocking innovation. And they just don’t block innovation. They – if they do anything – block copycats from merely copying without paying a royalty.

BEAR: To be fair, it’s often a mix. If it’s part old stuff, even reconstituted in a way that does something newly magical, you’re still going to have to license the preexisting parts that go into it. The trick is getting the economics to work for everyone involved. Your question earlier about open source – I don’t have a good answer to that. But I am a fan of the possibility of what open source can do for the economy; and it’s a question of the mindset of the people in the business. Can they get comfortable enough with interdependence?

QUINN: That’s an interesting point – and so true isn’t it?

BEAR: We, in the United States, hold this media generated ideal of what it means to be in power. And power is confused with independence. But power, in my mind, involves acknowledging and embracing interdependence – because there’s nothing to lose that really matters. With synergy, there’s only gain.

QUINN: On that note, we should probably wrap this up. This has been a good conversation. Thanks for taking time to chat with me. I really enjoyed it.

BEAR: Absolutely. I appreciate the opportunity to share my thoughts with your audience.