Software Patent Law | Patents4Software.com

For decades, more than three to be more precise (e.g. see http://www.dei.unipd.it/~pettarin/fsfs2/fsfs2.xhtml), the anti-software patent zealots have been declaring the uselessness of patents on machine-implemented processes, or predicting the end of the software industry as we know it.  First, the battle cry was “software patents are useless because software technology evolves too fast for patents to be of use.” But that criticism was soon proved to be false, as a great number of pioneering inventions lasted longer or nearly as long as the 20 year patent term.   When the viability of patent protection for programmed computers became evident, the mantra became “software patents will destroy software innovation.”  That mantra obviously proved wrong again!   Interestingly, some of the most intensive patenting efforts have been undertaken in the mobile computing/smart phone market, where patent protection is now being aggressively used by various innovative companies to fend off unfair copying by imitators or outright intellectual property thieves.  Again, far from destroying the smart phone market, the smart phone market continues to grow rapidly, in no small part due to the ability of innovative companies to obtain a fair return on investment in the ground-breaking R&D that has helped fuel that market’s growth.

So one is left to wonder, why do certain elements of the software industry continue to insist that patents on programmed devices such as smart phones, tablet computers or personal computers in general should not be entitled to patent protection simply because they operate in accordance with a sequence of computer instructions instead of being hard-wired?

Recently, it occurred to me that there is indeed a difference, but it is not a difference in the nature of software vs. other technologies, a differentiation that does not stand up to unbiased scrutiny, particularly now that virtually all electronic devices are in large part programmable on one level or another, but rather in the nature of the relationship of inventor to manufacturer.  More particularly, in most industries inventors are largely separated or insulated from the management of intellectual property rights – i.e., the typical inventor is told what he or she is permitted to copy or imitate, follows those rules, and generally needs to worry no further concerning the risk of his or her company being sued for misappropriation of another party’s IP.

On the other hand, computer programmers see themselves in a different way:  almost all of them see themselves as actual or at least potential manufacturing entities (even if only as a hobby), exposed directly to the responsibilities and risks of a complex system for protecting innovation from being unfairly copied.  However, the risk and complexity of the patent system is a cost of doing business beyond the means of the typical programmer.  The barrier of the patent system thus becomes personal to a great many software developers, who see it as an infringement on their personal rights, as opposed to a business challenge or opportunity.  Again, these business challenges rarely are taken personally by inventors in other disciplines — they almost universally work for the entities that manufacture products and manage the attendant IP rights.

While in the main it is rare for a mom and pop software manufacturer to face ruinous patent threats, as I have pointed out in a prior posting, perhaps the answer to the perpetual software patent debate lies not in trying to reduce intellectual property protection in an age where intellectual property forms a larger and larger part of our nation’s wealth (not to mention playing right into the hands of unscrupulous competitors in copycat countries that are licking their chops at the possibility to clone iPhones, iPads and more), but rather in addressing what is probably the real cause of most software patent consternation by volume – programmers who take patent infringement risk personally.  For example, Section 35 U.S.C. 287 (c) of the US patent law provides a limited exemption to surgeons who may infringe a US patent in the course of treating a patient.  Perhaps a similarly styled exemption could relieve micro-entity software programmers or companies from liability for producing infringing computer programs until they are given fair notice detailing the basis for infringement, and a reasonable period of time to design around the patent or challenge it in a reexamination proceeding.  Of course there would be many loopholes to consider that may make this approach difficult to enact, but I think perhaps this proposal may get the hopelessly deadlocked software patent debate off dead-center and create a win-win situation for all parties.

A special thanks to Daniel Parrish for the following post:

Last week, an Eastern District of Texas judge granted in part Apple’s motion to intervene in Lodsys’s patent infringement suit against eleven application-developing entities.  Lodsys filed the suit in late May 2011 (amended July 2011) and Apple filed its motion to intervene only nine days later.  After ten months, the court granted Apple permissive intervention: “Apple is permitted to intervene in this suit, but such intervention is limited to the issues of patent exhaustion and licensing.”

The summary in the public record states:

“SEALED MEMORANDUM OPINION and ORDER – Apple has satisfied each of the four requirements for intervention as a matter of right under Rule 24(a)(2). The Court finds that permissive intervention is also appropriate under Rule 24(b). To avoid any potential prejudice to Lodsys rights under the License Agreement such intervention shall be and is hereby limited to the issues of license and patent exhaustion. Apples Motion to Intervene is GRANTED-IN-PART to the extent and as specified herein. Motions terminated: [4] MOTION to Intervene filed by Apple, Inc.. Signed by Judge Rodney Gilstrap on 4/12/12. (ehs, ) Modified on 4/12/2012 (ch, ).”

Apple’s interest in this suit extends beyond gratuitous defense of its application (app) developers.  Apple has an economic interest, having already paid licensing fees to Lodsys for rights to the disputed patents.  Apple asserts that the licensed rights cover developers who create apps which are sold and distributed from Apple’s App Store.  The developer typically retains 70% of the app’s revenue, while Apple takes 30% for payment processing, hosting services, and content management.  Apple contends that its rights extend to developers, giving them the freedom to create applications using Apple’s licensed technology without worrying about claims of patent infringement.  Thus, a judgment in favor of Lodsys would give them “two bites at the ‘Apple’” by generating licensing revenue from Apple and infringement damages from Apple’s app developers.

This is the essence of patent exhaustion theory, upon which Judge Rodney allowed Apple to intervene in this suit.  Patent exhaustion means that an initial sale of a patented invention severs the patent owner’s rights to that item.  More complex issues arise with respect to licensing.  A typical example is an upstream supplier licensing a patent such that downstream firms do not have to.  This is efficient from both cost and administrative perspectives, but much depends on the language of the license itself.  Here, Apple is the “upstream supplier” and the developers are the “downstream firms” that Apple claims to cover.

Apple hopes to succeed in this litigation, as much of its success can be attributed to the “There’s An App For That” culture it fosters.  In February 2008, Apple released a software developer’s kit (SDK), opening its iOS operating system for third party app development.  Recent figures from Apple illustrate how successful this strategy has been.  To date, over 25 billion apps have been downloaded, from the currently available 650,000 apps by 150,000 active developers.  This enables Apple to distribute not only apps that nearly every user downloads (e.g. Facebook, Skype, etc.) but also apps that are narrowly tailored to few users (e.g. app for users of the Hennepin County Library).  It does so by lowering some of the technical barriers to entry, namely by allowing developers to “copy and paste” certain software objects from Apple into the app itself.  For example, if an iPhone app requires a user to type on a keyboard, the app developer is not required to write the code for a keyboard.  Rather, the developer can simply “paste” Apple’s keyboard-object into the app.  This not only simplifies app development, but increases uniformity across app interfaces.

This is the essence of the Lodsys dispute.  Some of these software objects are supposedly patented by Lodsys and licensed to Apple, for example the “App Store” button in the Labyrinth app illustrated in Apples motion to intervene.  Lodsys contends that only Apple (and not third-party developers) is covered by the license.  Apple disagrees, asserting that its licensed rights protect third-party developers from suits like this one.

Although the outcome of this dispute likely depends on the exact terms of the licensing agreement, some industry watchers believe that a Lodsys triumph this would be a major blow to app developers.  Albeit a distinct possibility, Apple would most likely renegotiate its licensing agreement with Lodsys.  App developers and Apple have a symbiotic relationship wherein each depends on the other for mutual financial gain.  Apple is in a much stronger position to negotiate licensing agreements than an individual developer.  If Apple allowed Lodsys (or other similarly situated companies) to obtain judgments against developers, this could limit the very innovation that contributed to Apple’s success.  Apple is too smart to kill the goose laying the golden eggs and will most likely continue to defend its app developers.

Yesterday, news broke that Microsoft purchased 800 AOL patents and pending applications for $1.056 billion and also obtained a non-exclusive license to the remaining AOL patents.  This amounts to $1.2 million per patent, which is a new high point among recent patent sales.  The Motorola and Nortel sales amounted to $700,00 to $750,000 per patent.

This move by Microsoft occurred about a month after AOL hired Evercore Partners to help it find a suitable buyer for its patent portfolio.  It is interesting that the initial valuation for the patents, made in February by activist investor, Starboard Value LP, was $1 billion.

Several patent analytics companies have publicly opined on the value of the AOL patent portfolio. M-Cam’s review of the AOL patent portfolio concluded that 71% of AOL’s US patents have “potential commercial impairment.” http://www.m-cam.com/sites/www.m-cam.com/files/20120329%20-%20AOL_0.pdf . M-Cam put a valuation of $290 million on the AOL patent portfolio.  M-Cam determined that 76% of the AOL patent portfolio will be in effect for at least another ten years.  Four of the patents were reissued.  Twenty percent of the AOL patents were originally issued to other entities, in particular, Netscape Communications.

The M-Cam report identified that the technology space surrounding the AOL US patents is dominated by patents owned by IBM, Microsoft, AT&T, Sony, Sun Microsystems, and Cisco, respectively.  These companies have substantial numbers of patents that have pre-1991 patent intersections to AOL patents.  The term “patent intersections” relates to technology and citation relationships identified by M-Cam analytics.  M-Cam ranked Google as number eleven on this list. Google has no patents with early patent intersections in this area but has over 11,000 patents with AOL intersections that are post- 1991.  M-Cam concluded that companies with pre-1991 patent intersections “could have leverage over AOL” as they hold patents with similar claims that predate AOL.  M-Cam concluded that companies such as Google, Yahoo!, Digimarc and JP Morgan Chase could be licensing targets because of the high incidence of citation to AOL patents.   .

A second analytics group, MDB Capital Group, an investment bank in Santa Monica, CA, put a value as great as $1 billion on the patent portfolio in an article published by Bloomberg on March 24:  http://www.bloomberg.com/news/2012-03-23/aol-said-to-hire-evercore-to-find-buyer-for-800-patent-portfolio.html . A co-founder of MDB opined, “More than likely the buyer on this would be someone like Google or Microsoft (MSFT),”

The approach of these two companies shows the importance of context in patent valuation.  MDB started its analysis by considering likely buyers and what the patent portfolio would mean to them, as well as the “heat” of the market.  M-Cam, on the other hand, looked at the details of patents within the AOL portfolio and made its determination based upon the quality of patents within the portfolio.  Both approaches have merit.  The MDB approach is based upon business factors such as expectations regarding markets, and, “heat”, that is, a knowledge of desires to covet by particular company managements.  The M-Cam approach provides an objective analysis of a patent portfolio once the game is played, a particular company wins, and the “heat” cools.

With this move, Microsoft has increased its arsenal of basic internet infrastructure patents and may be in a better position to compete with Google.  Time will tell whether the AOL patents purchased are worth the price.

This post contributed by Janal Kalis.

Overview

The Court of Appeals for the Federal Circuit will focus on the legal standard for joint infringement in the forthcoming McKesson and Akami opinions.  Because of software’s inexorable transition from computer-readable media to network and internet distribution, these opinions significantly affect joint infringement for software inventions.

McKesson Technologies Inc. v. Epic Systems Corp., (Fed. Cir. 2011) focuses on two questions, as ordained by the en banc order:

1. If separate entities each perform separate steps of a method claim, under what circumstances, if any, would either entity or any third party be liable for inducing infringement or for contributory infringement?

2. Does the nature of the relationship between the relevant actors—e.g., service provider/user; doctor/patient—affect the question of direct or indirect infringement liability?

Akamai Technologies, Inc. v. Limelight Networks, Inc., (Fed. Cir. 2011) paraphrased McKesson’s questions in its single en banc order question:

1. If separate entities each perform separate steps of a method claim, under what circumstances would that claim be directly infringed and to what extent would each of the parties be liable?

Akami

At issue in Akamai is Akamai’s Patent No. 6108703 (“’703”), which uses the term “tagging” to describe prepending a URL, as suggested by Limelight’s brief: “www.provider.com/…/story.gif” may become “ghost1467.com/www.provider.com/…/story.gif”.  Limelight infringes every step but one of ‘703 by hosting the content and providing an alternate server name to its customers; the customers perform the final step by prepending the server name onto the URL.

Arguing for Akamai, Mr. Dunner’s oral argument proposed three tests:

“One test is direction or control, not ‘and control,’ ‘or control.’  The second test is concert of action.  The third test is knowingly combining steps with another.  So there are three separate tests, and in each case, there has to be knowledge of what is happening.”

Arguing for Limelight, Mr. Panner cited § 271’s sharp distinction between § 271(a)’s establishment of patent infringement as a strict liability tort, and that knowledge of infringement is required for indirect infringement under § 271(b) or § 271(c).

Judge Newman was clearly uncomfortable with this strict reading of § 271 to Limelight’s admitted desire for the customer to perform the final step.  Judge Lourie also indicated discomfort with this outcome.  However, this is exactly the arm’s length transaction contemplated by Judge Rader in BMC: “This court acknowledges that the standard requiring control or direction for a finding of joint infringement may in some circumstances allow parties to enter into arms-length agreements to avoid infringement.”  (498 F.3d at 1381.)  Indeed, that Limelight intended the result and that this portion of Limelight’s website seems to have no substantial noninfringing use (to borrow language from § 271(c)) seems to imply some degree of inequity.

McKesson

At issue in McKesson is McKesson Patent No. 6,757,898 (“‘898”), which covers a method of communication between a patient and a healthcare provider.  Defendant Epic’s software “MyChart” infringes every step of the method claim except for the first step: “initiating a communication by one of the plurality of users to the provider for information . . . .”

Mr. Joseffer restated the BMC “direction-or-control” test McKesson advanced in its brief.  He was immediately peppered with questions about his assertion that McKesson can prevail under either § 271 (a) or (b) (where § 271 (b) inducement generally requires direct infringement under § 271 (a)), but he clarified that the direction-or-control test broadens legal attribution to cover either (a) or (b).

Judge Dyk inquired about whether this method patent could be enforceable if it had been written entirely from the perspective of the doctor.  Mr. Joseffer replied that such a patent could be circumvented if the doctor asked someone in IT to perform at least one step, and explained that requiring a claim construction solution would expand multi-step method claims to an unworkable number of party subcombinations, and that no such construction could be expected to anticipate every possible scenario.

Arguing for Epic, Mr. Moore held to the Supreme Court’s decision in Aro (previously cited against Mr. Joseffer by Judge Moore), which requires performing all steps of a method patent to satisfy § 271 (a) infringement.  Mr. Moore went on to explain that § 271 (b) and (c) were created to encompass negligent or intentional acts by secondary or tertiary parties, and that statutory construction interprets their separation to preclude multiple party inducement under (a).

Judge Moore asked, “Then why would you ever file for inducement if, in your theory, the direct infringer would be the same person as the inducer because he is, in the common-law sense, making them act as his agent.  271 (b) would be superfluous in your statutory interpretation because it would be entirely encapsulated under 271 (a).”  Subsequent questioning, alas, did not clear up this apparent contradiction before the end of Mr. Moore’s time.

Conclusion

The Federal Circuit did not seem eager to adopt Akamai’s knowledge test, nor did they seem satisfied by McKesson’s argument that all patents must have a remedy.  The Judges may not find explicit support in § 271 or previous method patent cases, but seem to be open to expanding the direction-or-control test to avoid circumvention of method patents.  Though the oral arguments provided some insight the concerns of Judges Linn, Prost, Moore, Dyk, Bryson, and Newman, we are left to extrapolate the proclivities of the quieter Judges Lourie, O’Malley, Reyna, and silent Chief Judge Rader.

The outcome will have a significant effect on authoring method claims, especially as applied to software patents.  As such, we eagerly anticipate the decision, expected later this spring.