Source code ch.07: Initial infringement contentions

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 7: Pleadings and initial infringement contentions in software patent litigation

7.0 Background on notice pleading, Rule, Local Patent Rules, and forthcoming legislation: see chapter 6

7.1 PICs are “nit picky” and not-very preliminary

  • Movement away from “PIC” terminology e.g. in ND Cal.; now initial version of infringement contentions
  • PICs unfortunately are often done by an attorney, with little or no expert input, using superficial “pattern matching” of claim language to vaguely similar wording at other side’s web site, or in user interface of its product (e.g., PIC which mapped raster-based patent claim to bitmap-based product feature; especially sad when the product did also have a raster-based feature)
  • Application to defendants as well as plaintiffs: “kneejerk counterclaim” cases
  • For non-initial infringement contentions (ICs), see chapter 26

7.2 Basics of claim charts: infringement is not “holistic”

  • Patents are not “concepts,” and patent infringement is not conceptual (“they took our idea”)
  • Patent claims delimit territory; showing infringement requires showing that this territory was encroached; such encroachment occurs in a specific location, or set of locations, in a product, service, system, or medium; and the job of the PIC is to make a best effort, based on available information, to point to where the accused “instrumentality” (device, method, system, or medium) does this (though really the job of PIC is notice of what P reasonably believes it can prove, rather than proof itself)
  • This is done by breaking a patent claim into “limitations” (elements or parts of an apparatus/device, or steps of a method), and pointing to where each such limitation is embodied or carried out by the accused instrumentality
  • Incidentally, going through such an exercise makes clear that software patents (and even business method patents) are typically far more tangible/concrete than one would think from public discussions
  • Even though showing patent infringement is not a holistic exercise, but rather a detailed mapping of each claim limitation to a specific location/step in an accused product, at same time there is — towards the end, not the beginning, of the process — room for overall comparisons (including, though rarely, some product-to-product comparisons; see xxx) and a need for overall assessment (“okay, we found every limitation of the claim matches up to a component of the product — but do all the components fit together together to make up a single thing, or is it just a parts list or laundry list?; do the components fit together in the way required by the patent claim?)

7.3 Claim chart left-hand side and right-hand side

  • 7.3.1 Left Hand Side: Parsing claims into limitations
  • 7.3.2 Right Hand-Side: Plugging in the other side’s proper nouns [elements, steps, structures, functions, features, algorithm, processes, components, modules; in part because patentee can be “own lexicographer,” there may be literal infringement employing different names]

7.4 Level of detail needed for initial/preliminary infringement contentions

  • 7.4.1 Avoiding conclusory or “mimicking” contentions: tie/weave/link P’s limitations to D’s elements/steps [mimicking: P often uses its own claim language to point to corresponding elements in D’s product, rather than using D’s own naming, to defer committing to a specific mapping between a P limitation and a D element/step]
  • 7.4.2 Showing, without having to prove: provide reasons for believing what you would later find in the source code
  • 7.4.3 Pinpointing: Identifying location (via name) where elements/steps are found in accused product/service
  • 7.4.4 Explaining how/why element/step matches limitations
  • 7.4.5.1 The Wizard of Oz rule: “because, because, because, because, because”
  • 7.4.5.2 Adapting function/way/result from DoE as a way to avoid being conclusory about literal infringement
  • 7.4.5 Interaction of claim type (apparatus, method, system, medium, signal) with infringement type (make, use, sell, offer, import)
  • 7.4.6 Examples from cases of charts with sufficient and insufficient detail [Theranos; Connectel; CSR; AVG]

7.5 Omitting and repeating information

  • 7.5.1 “Information and belief” often used as unthinking talisman
  • 7.5.2 Hedging: “see”, “for instance”, and other ways of not actually saying anything
  • 7.5.3 Assumptions
  • 7.5.4.1 Inferring presence of element x from element y
  • 7.5.4.2 Inventor’s fallacy: implicitly inferring presence of element x from result/output y
  • 7.5.4.3 Be explicit, or give some authority for the assumption
  • 7.5.4 Standards: inferring operation from part names [e.g. “sqrt”; when can named part’s lower-level implementation can be treated as black box, vs. when need to drill down]
  • 7.5.5 Filling in simple limitations from secondary sources [e.g. network, CPU]
  • 7.5.6 Negative limitations
  • 7.5.7 Some “limitations” may actually be mere preconditions [-ed vs. -ing]
  • 7.5.8 Omitting function/purpose when structure/implementation can be shown [including preambles; but see means+function 112/6; reverse of inventor fallacy]
  • 7.5.9 Show when necessary information is really in the other side’s exclusive possession (i.e., demonstrate “exhaustion” as discussed in chapter 6)

7.6 Reducing repetitiveness in claim charts: Limitation Charts

  • 7.6.1 The problem of repetitive charts [fear cross-reference with “see,” but courts see through huge charts]
  • 7.6.2 Extracting common limitations: “parts is parts”?
  • 7.6.3 Claims as parts lists [also note Word merge templates to generate repetitive claim charts; possibility of un-merge]
  • 7.6.4 Problems with parts-list charts: see “laundry list,” “bag of parts” cases

7.7 Reducing repetitiveness with representative instrumentalities

  • 7.7.1 Need to show how/why the instrumentality is representative of others

7.8 Small but important words

  • 7.8.1 Importance of connectives: the claim is not a “laundry list” nor mere “bag of parts”
  • 7.8.2 Importance of small non-technical words, and subtle differences between claims with same parts
  • 7.8.3 Difference between e.g. “programmed” and “programmable”

7.9 Special cases

  • 7.9.1 Showing means-plus-function 35 USC 112(6) infringement, under WMS Gaming
  • 7.9.2 Showing infringement by doctrine of equivalents [don’t merely recite function, way, result; parse out each separate attribute]
  • 7.9.3 Showing inducement and contributory infringement [who carries out process; inducement/contribution elements]

7.10 Infringement charts as admission ticket to patent litigation (not just a hoop to jump through)

  • 7.10.1 PICs as material relevant to reasonable pre-filing investigation under Rule 11; PICs should embody that one has exhausted publicly available information, and engaged in “reverse engineering or its equivalent” to learn patent-relevant details of the accused product (see chapter 6)
  • 7.10.2 PICs as prerequisite to mandatory disclosure and discovery under Local Patent Rules (and under proposed patent-reform legislation, e.g. Goodlatte)
  • 7.10.3 PICs as slightly-flexible early cementing of theories of infringement and invalidity
  • 7.10.4 Get expert involved earlier in case than you would otherwise prefer
  • 7.10.5 Process of building PICs to locate case “hot spots,” and to guide targeted discovery requests
  • 7.10.6 Process of building PICs to determine preferred claim construction for later Markman hearing
  • 7.10.7 Process of building PICs to locate “sweet spot” (often-narrow channel) between infringement & likely prior art
  • 7.10.8 Claim charts shown in licensing demands/negotiations may create a basis for a declaratory judgment (DJ) action; see case xxx

7.11 Application to other patent litigation charts

  • 7.12.1 Don’t confuse with claim construction charts for Markman
  • 7.12.2 Applicability to invalidity charts: anticipation, obviousness, public use, on sale [but note source code has a different role in invalidity, since prior art must have been public at the relevant time]
  • 7.12.3 Applicability to practicing/working charts [e.g. for ITC domestic industry technical prong; lost profits]

7.12 Supplementing and amending ICs, post-discovery

  • “Pinpoint” source-code line numbers post-discovery: should then be a matter of filling in gaps, not an initial fishing expedition
  • Non-preliminary claim charts: see chapter 26

 

Print Friendly, PDF & Email