Source Code & Software Patents: A Guide to Software & Internet Patent Litigation for Attorneys & Experts
by Andrew Schulman (http://www.SoftwareLitigationConsulting.com)
Detailed outline for forthcoming book
Chapter 5: Source code & patent litigation defendants
- While this book may appear largely focused on plaintiffs and their use of source code to prove infringement, almost everything here also applies to defendants, and their goals of disproving infringement and proving invalidity.
- P v. D terminology: the term “plaintiff” or P is often used as a convenience to denote the patent holder asserting infringement, but in declaratory judgment cases, the accused infringer will be the plaintiff (P), and patent holder the defendant (D). Further, D may assert its own patent-infringement counterclaims against P.
- References in the book to “pre-filing investigation” should be read more broadly to refer to any “pre-discovery investigation,” as this type of investigation includes those quickly done by D, after P’s filing of the case, but before discovery has begun.
5.1 Counterclaims
- Time pressure on D to quickly file counterclaim, sometimes without adequate investigation: “kneejerk counterclaims”
- Rule 11, Local Patent Rules on prefiling investigation and initial infringement contentions apply equally to D counterclaims as to P’s earlier accusations
5.2 Disproving infringement, and/or diminishing its unimportance
- Disproving infringement: rebut P’s specific assertions of infringement
- Contrast proving non-infringement (showing absence of infringement) to disproving infringement
- Usually D has no burden to prove non-infringement, except perhaps if D seeks declaratory judgment of non-infringement, or if D asserts affirmative defense of non-infringement
- Similarity of non-infringement to showing availability of non-infringing alternatives, design-around?
- Situations in which some burden on P is shifted to D, e.g. 35 USC 295 (product by process), and “Catch 22”: see chapter 6
- Understanding the relationship between source code and the accused instrumentality (see chapters 2 and 22) is especially important for defendants seeking to disprove infringement (or perhaps to show its relative unimportance in the finished product)
- Showing source code doesn’t match claim
- Source code matches claim, but source code not built into product: see chapters 2 and 22
- Source code matches some accused products, but not all: see chapters 7 and 26 on “representative instrumentalities”
- Source code is reflected in accused product, but is never used: see chapter 2 on “latent code” cases, “dead code”
- Source code is used in product, but hardly ever: see chapter 30 on damages
- Source code is used in product, but D asserts it has little (or even negative) value: see chapter 30 on damages
- “Turning (apparent) mountains into molehills”; see the old lawyer joke about goats and cabbages
- Interaction of code interpretation (fact) with claim construction (law)
- Often the parties agree on what the code does, but disagree on what claim requires
- What is role of source-code examination, when the parties disagree on claim construction rather than code interpretation?
- Source-code examination findings will often drive parties’ respective claim-construction positions
- D should not pass up opportunities to dispute P’s code interpretation: e.g. static code shows “loop,” but dynamic examination shows only executed once, which arguably not a loop
- Don’t assume that function names or comments accurately describe what code does; check implementation at lower levels; D may have to disagree with characterizations made by its own source code, or with P’s naive or simplistic interpretation of these characterizations
- Doctrine of equivalents: showing code’s function, code’s way, and code’s result are insufficiently similar to limitation
- Means plus function: showing that code does not match specific means disclosed in specification
5.3 Providing invalidity: anticipation, obviousness, on sale, public use, inadequate disclosure
- “That which infringes if after, anticipates if before”
- Thus, P’s overbroad infringement contentions may be a gift to D: if P reads its claims as broad enough to read on D, then P may be estopped from denying that prior art (matching what D does) anticipates the claim
- However, infringement and invalidity are not perfect mirror images:
- Showing invalidity is an uphill battle; because patents are presumed valid, invalidity must be shown with “clear and convincing evidence”
- P does not have the burden of proving validity of a granted patent (e.g., i4i v. Microsoft)
- Prior art usually found in earlier patents, published patent applications, or in “printed publications”
- “Printed publication” is a term of art, which likely includes software itself, not merely printed descriptions of software
- Software as NPL (non-patent literature)
- Source code can be used to show that a product/service was anticipatory prior art
- However, the proprietary source code itself generally won’t be prior art, because prior art by definition must have been publicly accessible at the relevant time to the PHOSITA (person having ordinary skill in the art), and must have been capable of “teaching” the PHOSITA
- Using reverse engineering to uncover prior art software: see New Matter article
- Using source code to show obviousness; the scope of a single software “reference,” and combining references; see combining source code with non-source documents in chapter 29; open source as evidence of PHOSITA level of skill, or perhaps revealing T/S/M to combine references?
- Does a software product — albeit comprised of many components, documentation, sample files, etc. — constitute a single reference, to be analyzed for anticipation, rather than multiple references to be analyzed for obviousness?; see Enfish case
- On-sale or public-use may be easier to show with source code, because on-sale or public-use technology need not have been capable of teaching the PHOSITA at the relevant time; “non-informing public use”
- Inadequate disclosure defenses: enablement, written description; software patent almost never requires source code for adequate disclosure: see Aristocrat, WMS Gaming in chapter xxx; also see PTO on “self-documenting source code”
- How much source code must be written, to constitute “undue experimentation”?
- BOX: Academic dispute on whether source-code disclosure would solve perceived “software patent problem”; calls for “open patents”
- Using software developers identified in source code, to show patent missing one or more inventor names
- Using dates in source code, to show laches, but D’s use of invention must have been “open and notorious”; proprietary source code is not open and notorious (but may be evidence of); how open and notorious are software internals, given widespread availability of reverse-engineering tools?; how much is a patent holder expected to police the market for infringement?
- Using dates in source code to show prior use (prior-user rights defense expanded in AIA)
- Unenforceability
- Standards committee participation by patent owner
5.4 Defendant examining its own source code
- More generally, either party’s relation to its own source code
- Parties sometimes spend less time in litigation with their own code, than with the opponent’s
- Accessing client’s own source code is typically simpler than accessing the other side’s (see chapter 11 on protective orders)
- However, D should usually examine its own code with as much care as (and probably in the same manner as) P will examine D’s code
- Benefits of taking the “outsider’s” view of one’s own source code
- Benefits of reverse engineering one’s own product/service, even when the source code is readily available; e.g., outsiders, lacking source code, often find security vulnerabilities in software, unknown to the vendor (which did have source code)
- Defendants sometimes assume they know everything there is to know about their own code; after all, “it’s ours and we wrote it”
- But sometimes D’s code (upon which P will focus) is something D acquired, and hasn’t carefully inspected; or the engineers who wrote the code have left the company; or the engineers have long ago moved on to other projects [this of course does not affect infringement itself (or even willfulness?), but may impact D’s discovery obligations?]
- D’s loss of, or overwriting of, its source code: see chapter 10 on missing code and spoliation
- Usually, D does know far more about its own technology than P does
- D sometimes required to explain source code, provide (or even create anew) narrative or “roadmap,” to P: see chapter 9 on discovery
- In fact, sometimes P’s ignorance of D’s technology, compared to D’s inside knowledge (and possession of proprietary source code), is used as a basis for some burden shifting: see chapter 6 on the source code “Catch 22”
5.5 D examining P’s source code
- Using P’s source code to show anticipation, on sale, public use: see above
- Using P’s source code to show that P not practicing or “working” its invention: US does not have working requirement, but working/practicing is needed for technical prong of ITC domestic industry; and may be needed to show eligibility for injunctive relief; lost profits
- ITC domestic industry technical prong may be proved or disproved with source code, including that of licensee of otherwise-non-practicing entity (NPE); these may be unwilling licensees following earlier litigation
- Injunctive relief & working requirement: see eBay v. MercExchange
- Lost profits & working requirement; did patent holder have ability to practice invention? [D’s own source code, with error checking, handling of boundary conditions, etc. may show what it takes in real world to practice the invention?]
- D will also often need to examine P’s source code (even in the case of so-called “trolls” or non-practicing entities; NPE will have bought patent from somewhere, and along with it often source code, or access to the inventors who generally will still have source code (but: i4i); or NPE may have licensees
5.6 D’s need for third-party source code
- Third-party source code may be intermingled in D’s source code repository: see third-party discovery intervention in chapter 9
- Open source, for comparison with D’s modifications, additions, deletions (especially when P has based initial infringement contentions on open source; see chapter 3)
- Third-party prior-art source code: see FRCP 45 subpoenas in chapter 9 on discovery
BOX: Somewhat inconsistent patent defendant litigation stances involving source code
- D’s resistance to discovery of source code “crown jewels” may later contradict position, after a finding of infringement, that the source code in question is old, outdated, no longer used, of little or negative value, and so on
- D may assert P’s failure to conduct reasonable pre-filing investigation, by noting P’s failure to reverse engineer D’s product or service, when that product or service clickwrap carries “no reverse engineering” language: see chapter 6
- D may denigrate infringing portion of product/service, in seeming contradiction to earlier “it’s worth millions of dollars” praise (in marketing literature, source code comments, or internal emails) for arguably same technology
