The Lodsys patent
May 21, 2011 at 11:39 PM by Dr. Drang
It’s been just over a week since we started hearing about Lodsys’s claims of patent rights over in-app purchases made in iOS apps. In that time, there’s been a lot of outrage, namecalling, and misinformation swirling around the Apple-centric corner of the internet. I’ve been hoping a lawyer, or better yet, an IP lawyer, in the community would speak up and set a few things straight. Since that hasn’t happened, I’ll do my best in this post and hope that those better informed will come along and correct my mistakes.
Update 5/22/11
This afternoon I got a mildly annoyed email from Patrick Igoe. He is a patent attorney and has written a few posts at applepatent.com with exactly the sort of analysis I was looking for, as well as a couple with more general discussion of Lodsys. You should go there and read what he has to say.
Let’s start with my bona fides. First off, I’m not a attorney so I probably shouldn’t be using Latinate terms like bona fides. But I have worked as an engineering consultant to patent attorneys in patent infringement litigation,1 and the attorneys I’ve worked with have explained certain features, quirks, and conventions of patent law to me. That’s what I want to pass along in this post, starting with some generalities and then moving into specifics about the Lodsys patent itself.
Patents are presumed valid
Whenever there’s outrage about any software patent, the first thing you hear is that it’s clearly invalid because it’s obvious and there’s prior art. In litigation, though, patents are presumed valid. The thinking is that the inventor had to go through a prolonged vetting process with the patent office, and it’s neither right nor a good use of the court’s time to force the inventor to go through that process again. The burden of proof is on the defendant who wants to challenge a patent’s validity, and most defendants don’t want to take on that burden. The more common strategy is to argue that the patent doesn’t apply to their product.
Patent interpretation
When deciding whether a product infringes on a patent, the court has to interpret not only the law, but also the patent itself. Many years ago, a patent attorney I was working for explained to me the usual approach to patent interpretation this way:
Narrowly written patents are interpreted broadly; broadly written patents are interpreted narrowly.
At first blush, this has a certain “down the rabbit hole” feel to it, but it makes sense if you think about it carefully.
Say you’re an inventor, and your patent is quite modest in its claims. Courts will tend to give you the benefit of the doubt in close calls because your patent has left a lot of room for others to work in. Conversely, if your patent claims a huge swath of the metaphorical invention space, courts will look very critically at any arguments that go beyond a strict reading of the patent language.
Remember, the purpose of patents is to encourage innovation. The time-limited monopoly that a patent grants is there to reward inventors but not shut off development by others. This philosophy of interpreting patents is a way of striking that balance.
The patent itself
The patent that Lodsys says applies to in-app purchases is 7,222,078, Methods and systems for gathering information from units of a commodity across a network. If you’re going to criticize Lodsys as a patent troll, you really should read the patent itself and see what it claims.
Now, I can’t blame people for not wanting to read the patent. Even the most lucid and succinct patents are unbelievable dull, combining the worst of engineering and legal writing. And 7,222,078 is far from lucid and succinct. It is, in fact, an 89-page abomination that makes the patents I’ve had to deal with look like an E.B. White essay. A long chunk in the middle looks like the worst PowerPoint presentation you’ve ever endured.
Figures like this go on for 40 pages. Think I’m kidding? Exaggerating for effect? See for yourself.
This next one’s my favorite. I keep thinking it should have Get Your War On word balloons.
There’s so much of this crap that I’m tempted to say it’s as much a business methods patent as it is a software patent.
It’s time now for a confession. Despite my belief that one shouldn’t criticize a patent before reading it, I just couldn’t read the whole thing. Not without being paid to do so, anyway. I mean, look at this:
Once developed and integrated into a product, an automated Customer-Based Product Design Module (CB-PD Module) adds new and fundamentally different opportunities to obtain continuous Customer information in potentially faster, cheaper and more systematic ways than expensive and occasional product, market and human factors research studies. Since management decisions must inevitably be made about all aspects of products and services, Customers can and should participate in these selections. The CB-PD Module produces usage-based information on several levels: There are product design decisions, such as which product features should be added or improved to add the most value to that product. There are product management decisions, such as learning why specific products are preferred by Customers. There are Vendor management decisions, such as using Customer views of different product categories to help allocate corporate resources so that the business can jump faster and farther toward its revenue and profit objectives. There are business performance decisions, such as providing a continuous flow of current Customer-Based Product Design Reports (CB-PDR) into the Vendor’s internal data networks so many areas of the organization can develop iterative improvements in their operations, performance and results.
That’s one of the better paragraphs.
But I did make my way through most of it, and I read every word of the claims section. Here’s what I found:
The patent is all about improving products through networked and automated customer/vendor interaction. The interaction takes several forms including
- Monitoring how customers use the product.
- Online questionnaires for customer ratings of features.
- Online customer support.
- Placing orders.
It is, of course, only the last of these four that’s applicable to in-app purchases.
- The product improvement anticipated in the patent is pretty clearly of a traditional sort, in which customer feedback leads to changes in the next design iteration. This strikes me as quite a bit different from the in-app purchase system, in which the developer has already designed several modules for the product, and the customer buys those modules as desired. In-app purchasing is, unquestionably, a means of product improvement, but the improvements are pre-built, not based on any in-app features for customer interaction.
- In the patent, it is the customer and the “vendor” that interact. My understanding of the in-app purchasing process is that customers interact with Apple, not the app developer. Shouldn’t the patent, then—if it’s applicable at all—apply only to Apple? We know from Lodsys itself that Apple has licensed this patent.
Update 5/22/11
Again, go to applepatent.com to see Patrick Igoe’s discussion. He, too, thinks the claim of infringement is weak, but instead of talking in generalities and making bitchy insults like I do, he does a real analysis of the claims section of the patent. Had I read his stuff earlier, I probably wouldn’t have bothered writing this post.
I might still have posted those idiotic figures, though.
Update 5/22/11 (later in the evening)
Blogging patent attorneys aren’t as scarce as I thought. Here’s another one with a critical analysis of the Lodsys claims.
Are these guys right? I dunno, do I look like Learned Hand? I can say, though, that their arguments address issues and follow lines of logic familiar to me from my experience with patent litigation.
And even if they are right that doesn’t mean taking the matter to court is the right decision for developers. Costs and benefits.
Appropriate developer response
Let me start by saying I don’t really know what the appropriate developer response is, but I suspect that asking for advice from Apple is a wise move. We should learn shortly how Apple plans to play this.
In the meantime, lots of people with no stake in the outcome have been saying stupid things. Fight! is the most common response, an easy thing to say when you don’t have to pay the lawyers fees. Roll over was Marco Arment’s response on his Build & Analyze podcast. His argument is that the 0.575% licensing fee is too little to be worth fighting over, especially when the fight would certainly cost more.
I would say that both of these are wrong. A principled stand is great in theory, but businesses have to weigh costs and benefits. But Marco’s wrong, too. You can’t “just pay it and get on with life” because it isn’t well defined. How long will the payments last? How will the base of the 0.575% be determined? How long will that rate be applicable? This last question was answered in this tweet from James Thomson:
Only just spotted that Lodsys reserves “the right to change its royalty rates at any time” in the small print of my claim letter…
The answer, in a nutshell, is “As long as we (Lodsys) say it is.” You cannot make a business decision with such an open-ended liability in front of you.
Marco’s mistake is to treat the Lodsys demand letter as if it were a bill. It’s not. It is, like every matter involving lawyers, an offer to negotiate. Whether the developers choose to negotiate individually (which seems stupid to me), as a group, or as a group under Apple’s wing (which is contingent on Apple’s response), they’ll have to do some negotiating at some time. And that will, unfortunately, cost them.
The software patent problem
I don’t mean to pick on Marco Arment, but he said some other things in that podcast that betray a lack of understanding of the patent system. As I think these misunderstandings are common, I want to address them here.
Patents only help the big guys. While it’s certainly true that big companies have an advantage in patent litigation because they have more money to burn, that advantage isn’t unique to patent litigation. Big companies have that same advantage in every aspect of business, but we don’t say it’s not fair that they get to buy ads on TV or get volume deals from vendors. It’s just a fact of life.
The patent system, as costly as it may be, does level the playing field when an individual or small company develops a useful invention. In one of the patent cases I consulted on, the plaintiff was a small manufacturer with a unique and very useful product that was copied by a much larger manufacturer. Without patent protection—and litigation to enforce that protection—the larger company’s market reach would have allowed it to dominate the sales of a product it didn’t develop and didn’t pay for the development of.
- Patents last too long. Patents currently last 20 years. This is, obviously, several lifetimes in the software business, and it’s natural for programmers to think that it’s too long. But in more traditional fields, 20 years isn’t long at all. Pharmaceutical companies, for example, complain that a 20-year term is too short because they often have to go through years of testing and certification after a drug is patented before they’re allowed to bring it to market. It is, I think, legitimate to argue that software patents should have a shorter term, but—contrary to what many programmers think—software isn’t everything.
Patents should be abolished entirely. Had Marco just said that software patents should be abolished, I wouldn’t have listed it here. Software patents weren’t allowed until fairly recently,2 and I’m sympathetic to the idea that they never should have been allowed (although I don’t think there’s much value in fighting that battle anymore). But to argue that all patents should be abolished is just silly. A provision for patent law is in the U.S. Constitution. Article I, Section 8 says Congress shall have the the power
To promote the Progress of Science and useful Arts, by securing for limited Times to Authors and Inventors the exclusive Right to their respective Writings and Discoveries;
U.S. patent law dates back to the very beginning of the republic and was based on earlier English patent law. We have centuries of experience with it and centuries of very smart people using it and refining it. It’s likely that the coffeemaking paraphernalia Marco loves so much wouldn’t be around if its inventors couldn’t use patents to discourage others from stealing their inventions.
Finally
As I said at the top, I’m not an expert in patent law, but I think I have more experience with it than most people who are commenting on it. I welcome any and all corrections and additions from people who really do know the subject.
-
These were suits involving traditional physical devices, not software. It’s possible that some aspects of patent law are different for software. ↩
-
Dennis Ritchie, the creator of C and co-creator of Unix has a story about getting a software patent before they were officially allowed. The claims section of the patent was written to allow both a hardware and software interpretation, but the preferred embodiment section described the invention as a physical system only. This got the patent approved even though Bell Labs intended to implement the invention in software only. Because it’s the claims that matter most (especially if the patent is narrow), the Labs could enforce the patent on software. ↩