April 22, 2012
Software patents have taken a beating in the last two years.
Software patents survived In re Bilski and RCT v. Microsoft (which was the first post-Bilski Federal Circuit case on software patents, decided in December 2010): Software patents are not going away absent a change to the statute. But case law in the last two years has made it harder and harder to enforce software patents, get injunctions or sustain damages for them on appeal. Further, the slow pace of patent litigation, can leave many high-tech devices or inventions obsolete before there is a final result (the Hynix v. Rambus litigation has been continuing for over 12 years). Finally, patent litigation in the U.S. is more uncertain than ever given a badly fractured Federal Circuit.
RCT v. Microsoft was a case where there was an immediate connection between the software and the printer it controlled; the invention was described in detail. On the other hand, look at just some of cases that have been tamping back software patents before and since, such as Blackboard v. Desire2Lean, where claims were found indefinite; Trading Technologies v. eSpeed, where claims were found to be much narrower than asserted; and most recently, Ergo Licensing v. Carefusion 303 and Noah v. Intuit, where the Federal Circuit invalidated claims for failure to disclose sufficient algorithms to provide structure for means plus function limitations. There are of course other cases, but this is tough sledding. What does this mean to you?
It means you cannot put software patents that might be important to your business through a low cost provider pipeline and count on quantity to offset quality issues. Many companies play the “patents by the pound” ploy — get all you can, as cheaply as you can, and scare people with a big thicket of patents. I have never been a fan of this approach, but it certainly should not be applied to key technology — and definitely not to technology that is now hard to write valid claims over. If you have a software invention worth pursuing, you need to spend the time and money to have the patent done by a top notch provider with full cooperation from the inventors. The written description needs to be extremely thorough — with enough of an algorithm disclosed that the patent truly enables, teaches, and discloses an invention that can be implemented by one of skill in the art.
But writing a good patent is only one piece of the puzzle. You also need to look at software as part of your business and plan for problems just as you would with other parts of your business. Businesses and individuals spend a lot of money planning on problems: That is why we have a worldwide insurance, and reinsurance industry. That is why we have fire-hydrants in front of our homes. Stuff happens.
If you are selling products or services that include software, and are confronted with a claim of infringement of a software patent, the trend by courts to narrowly read software patents, creates not just defensive opportunities, but design around opportunities. You should have on staff (or as a resource) someone who has the capability to design around narrowly construed software algorithms with new algorithms. A software patch does not require re-tooling of a factory. If sued for software patent infringement, ask yourself, should we just redesign now to avoid the lawsuit or have a new product design (or component design) ready as soon as possible. The new case law makes this approach more feasible than it was in the past due to the constriction of the scope of software patents.
The take away from these points: 1) If you have a software invention important to your business put the patent in the hands of an experienced, successful, patent attorney who can write software patents that satisfy the written description requirement but still protect your IP space. A balance must be struck between protection of your IP and getting such narrow protection you have no real protection. You will get your money’s worth, one way or another.… 2) Hire the best software designers you can get, not only will this help your business, but when confronted with a software patent, it will enhance your capacity to design around it under current law. Heck, a lot of software features never get used, not many people are aware of them, even lawyers for the companies who sell the products often don’t know they exist: If it is not worth the fight, don’t fight. Remember this is about money, it is not an engineering contest or an ego battle — it is only about MONEY$$$.
BUT – there is a fly in the ointment – Industry standards in telecom and other network areas often adopt very specific software protocols for the “handshakes” or interoperability connections between equipment or signals. This becomes a problem because infringement may not be contestable: The main issue may be validity no matter how narrow the patent is if it covers a standard.
Yet, this is where the third piece of the puzzle comes in: Damages. The first order of business in defending a suit on a standard is to move to dismiss injunctive relief: The proponent of the standard offered the proposal to the group with the full expectation it would be implemented by the industry — where does the injunction come in under today’s law? The only issue is $$$. Recently we have seen cases between medical device makers where no injunction was awarded, and those guys always wanted and enforced injunctions. Injunctions and exclusion orders based on industry standards for interoperability should not be permitted: These are money cases from the get go. In fact, Nokia recognized this when it sued on its standards-related patents for a royalty and did not ask for an injunction.
The next thing is to put damages in perspective: Of course, the standard is essential to the operation of the device; but one buys a lamp because of the design and how it projects light, not because it comes with a standard electrical connector (plug) that fits in a standard wall socket. Interoperability interfaces are typically chosen from among several options within a shade or two of difference of each other, or developed quickly by a group, or participant, out of need for an interface (more so than the details of the interface) — which does not allow for an argument on high damages. This is especially true in light of Lucent in 2009, Resqnet.com in 2010, and Uniloc in 2011. Further, the antitrust authorities continue to keep at least one eye on abuse of the standards process, as shown in In re N-Data. The crux of the matter is if your product uses the standard, defend on validity, estoppel, damages, and wipe out the exclusion order or injunction. And yes, ask the FTC and the standards group and the EC to investigate…
The bottom line is an effective software patent enforcement strategy requires more planning and more attention from both technical and legal people in the company. The increased attention and expense needs to be integrated at the “C-Level” with the company’s business goals (in part, because of higher costs and higher risks of failure). Recall, however, patents cannot stop the better product from winning in the market: Polaroid beat Kodak in the 1980s on the instamatic camera, got an injunction, yet disappeared not long after. Kodak itself now is in bankruptcy as technology has leap-frogged to the next generation. Add to this the slow pace of patent litigation (especially in the US), its unpredictability (can you say “panel dependent”?), and the dilution of remedies — and a thoughtful business person will see the real battle ground is the marketplace not the courtroom…