Source Code book

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

The length of this book should not give the false impression that source-code examinations are unduly time-consuming, costly, burdensome, or complicated. In some ways, source-code exams are quite simple and straightforward. For example, the terminology in code sometimes closely matches that used in software patent claims. However, there are sufficient nuances and subtleties, and software is sufficiently important in contemporary litigation, to merit a lengthy book on source-code examination. The book also serves as an example of code examination generally, and illustrates the alignment of facts with legal categories.

Though focusing on patent litigation, much of the material is also applicable to examination of source code in non-patent cases, including software copyright and trade secrets; products liability; antitrust; and other legal areas in which source code is relevant.

This page and the linked pages for individual chapters provide a provisional detailed table of contents, not the book itself. If you are interested in reviewing particular portions of the forthcoming book, please send email.

For specific source-code examination services provided by SoftwareLitigationConsulting.com, see the FAQ and list of sample projects.

Table of contents

• This book covers the following topics: the nature of source code, and how this impacts its use as evidence, and in litigation generally; the steps involved before, during, and after a source-code examination; source-code discovery and protective orders (POs); source-code experts (testifying and consulting) and expert reports; alternatives when source code is unavailable (including pre-filing and pre-discovery); source-code problems (e.g. missing code or huge quantities); strategies for code reading and analysis (including comparison with patent claim limitations); and methods of source-code examination (including searching, close reading, tracing, comparing/diff-ing, and correlating).
• While it seems at first like a somewhat narrow topic, source-code examination in software patent litigation, apart from its intrinsic importance, also serves as an example of larger issues, including how technology generally can be analyzed/parsed for purposes of litigation or regulation.
• Increasing importance of software, and increasing need for software examination methods/skills/tools as a separate discipline from software development (“software reading” is not simply a subset of “software writing”)
• Forensic comparison/matching exemplified by taking software patent claim limitations, and “reading on” to software elements & steps
• Material is relevant to defendants as well as plaintiffs
• Source code is not the be-all and end-all of software patent litigation: how source code relates to, and differs from, the code in commercial products; how source code relates to reverse engineering
• The future of software patents, under Alice v. CLS Bank: focus on USPTO guidelines and post-Alice case law, rather than on Alice itself; note especially cases in which software patents were found subject-matter eligible under 101, including Cal. Inst. Tech. v. Hughes; CAFC case DDR Holdings v. Hotels.com (contrast with BuySafe v. Google; Planet Bingo v. VKGS); also see EDTX case with Bryson sitting by designation, Loyalty Conversion v. American Airlines; Enfish v. Microsoft; Bascom v. AT&T
• Role of source code in copyright and trade secrets cases, as well as in patent litigation

PART I: THE NATURE OF SOURCE CODE

Chapter 1: What’s so special (or not special) about source code?

• In many ways, source code files are just another type of document, like emails or memos
• Source code contains text, makes assertions, can reveal intent, etc.
• But source code is also a different type of document, because it is directly tied to commercial products (or in-house processes); see e-discovery article
• Is source code a sui generis type of evidence?; see Easterbrook vs. Lessig on “law of the horse”
• Source code (and software generally) is made up of the same raw materials (text) as patent claims
• Software as “operative words”
• Nature of software as both text and machine; both representation of, and instructions for, process/method
• Generic hardware is customized with specifics (“virtual machines”) which are spelled out in software
• Examples of source code in different programming languages
• Examples of source-code constructs (e.g. function call/declaration/definition, global/local variable, explicit/implicit function parameters, class/structure type/instance, function pointer, hook, event handler, subscriber, state machine, templates, etc.)
• Examples of user interface (UI) expressed in code/resources

Chapter 2: Source code and the “accused instrumentality” — how source code relates to commercial products

• Source code has a more direct relation to software product, than do schematics/blueprints/diagrams to non-software products
• Yet source code is generally not the accused instrumentality itself
• See chapter 22 on comparing source code to the accused instrumentality
• “Latent code” cases (Finjan, etc.); “dead code”; preprocessor #ifdef; build/make command
• How source code and products relate to standards (e.g., if the vendor states that the product implements 802.11g, possibly can avoid source-code examination for claim limitations relating to 802.11g)

Chapter 3: Open source, other publicly-available source code, and software patent litigation

• Products are increasingly based in part on open source, with vendor modifications, additions, and deletions
• How to link open source to accused products
• Open source & patents (e.g., Microsoft accusations of patent infringement by open-source projects)
• Source code available as part of the product itself (e.g., obfuscated/minimized JavaScript, embedded SQL)
• “Quasi-source”: products which can be decompiled into a close-enough representation of the source code (e.g., products written in Java or C#)

Chapter 4: Using source code to answer patent litigation questions

• For copyright and trade secret issues, see FAQ
• Goal of the source-code exam: extraction, translation
• Answering who/what/when/where questions
• Proving & disproving literal infringement
• Interaction of apparatus/method/system/medium claims with make/use/sell/offer/import infringement
• “Means for” (means plus function) claims
• Using source code in Doctrine of Equivalents function/way/result analysis
• Contributory & induced infringement, including questions of “divided” or “split” infringement
• Proving & disproving invalidity: anticipation (proprietary source code itself won’t be prior art, but will be evidence of prior art in corresponding publicly-available product)
• Proving & disproving invalidity: obviousness (what are the boundaries of a single software “reference”?)
• Using source code to show on-sale, public-use (proprietary source code will be mere evidence of a public use, and does not itself constitute the public use)
• Enablement: Assertions of inadequate disclosure from failure to include source code in patent application (Aristocrat, etc.)
• Using source code to meet practicing/working requirements (for e.g. ITC domestic industry technical prong; to show practicing-entity status re: injunction under eBay v. MercExchange; ability to manufacture product for calculation of lost profits)
• Source code & remedies: see chapter 30
• Using source code to answer who/what/where/why/how/how much questions (e.g. where does this step occur?, who performs this step?, when was this code written?)

Chapter 5: Source code & patent litigation defendants

• While much of the book may appear oriented towards plaintiffs and their use of source code to prove infringement, almost everything here also applies to defendants
• Counterclaims
• Disproving infringement: 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, alternatively, to show its relative unimportance in the finished product)
• Proving absences
• Invalidity: source code can be used as evidence of anticipatory prior art in publicly-available product, but proprietary source code itself generally won’t be prior art (because prior art must have been publicly accessible at the relevant time); on-sale and public-use bars; obviousness; enablement
• Using source code to help turn plaintiff’s mountains (“they boosted our prized technology”) into molehills (e.g., “both sides do this small thing of minor importance”)
• Defendant examining own source code: using in-house developers and/or outside code examiners
• Defendant contradictory stances, e.g. D’s source code is “crown jewels” for purposes of protective order (see chapter 11), but is “oh, that old thing, we never use it anymore and it never had value for us” for purposes of damages (see chapter 30).
• Defendant’s often needs to discover and/or produce third-party code
• Defendants often operate under especially tight deadlines

PART II: BEFORE THE SOURCE CODE EXAMINATION

Chapter 6: Pre-filing investigation of software/internet/mobile products & services

• Lengthy chapter with analysis of cases from ND Cal., ED Tex., including non-software cases involving pre-filing reverse engineering of products
• Local Patent Rules (e.g. 3-1) requirement for element-by-element analysis of accused instrumentality; see Claim Charts book
• Requirement of reasonable pre-filing investigation under FRCP Rule 11
• Proposed legislation (e.g. Goodlatte “Innovation Act” HR 3309, reintroduced in 2015 as HR9) heightened pleading requirements
• “Reasonable pre-filing investigation” generally means “reverse engineering or its equivalent”
• Cases: Bender v. Maxim; Shared Memory v. Apple; CSR v. Freescale; Renesas v. Nanya; View Engineering v. Robotic Vision; AVG v. Electronic Arts; Vasudevan v. IBM; Connectel v. Cisco; Network Caching v. Novell
• Courts generally prefer primary sources (examining the accused product itself) to secondary sources (e.g. marketing literature, web site screen shots)
• Reverse engineering as a litigation tool (contrast reverse engineering as an issue in trade-secrets law)
• Examining apps and systems-level code based on Windows, Apple OSX, Apple iOS, and Android
• Examining web code (JavaScript, DOM inspector, etc.)
• Making deductions about server software behind firewall
• Acquiring device firmware
• Using packet monitoring to acquire code for web sites/services, for later static analysis
• Presence of readable text, including names of elements/steps, in software/internet products/services
• Using reverse engineering to locate names of elements & steps in accused instrumentality
• Static reverse engineering (text extraction, “strings”; class & header dump; disassembly; decompilation)
• Dynamic reverse engineering (logging; debugging; web DOM inspector; network monitoring / packet sniffing; file monitoring)

Chapter 7: Pleadings and initial infringement contentions in software patent litigation

• Level of specificity required for preliminary or initial infringement contentions (PICs) under Local Patent Rules (e.g. 3-1)
• Possibly forthcoming heightened pleading requirements under e.g. HR 3309 (Goodlatte “Innovation Act”, reintroduced as HR 9)
• PIC is not all that preliminary; move away from PIC terminology e.g. in ND Cal.; initial ICs
• Aligning claim limitations with elements or steps uncovered in reverse engineering
• See chapter 26: Claim charts; and see Claim charts book

Chapter 8: Expert witnesses & non-testifying consultants in software patent litigation

• Need for early expert involvement, so as not to later provide expert/examiner with a fait accompli (which has been jokingly defined as “French for ‘the train has left the station'”)
• Coordination between non-testifying source-code examiner and testifying expert
• Involving expert/examiner in framing discovery requests
• Reliability of source-code examination methodology, under Daubert and Kumho Tire
• Potential impact of protective order (PO) on expert/examiner’s source-code examination methodology
• What is the relevant field of expertise?; broad vs. narrow
• Types of technical experts: generalist vs. specialist; computer science vs. software engineering; industry vs. academic; “hired gun” vs. “mad scientist”
• Expert’s ability to represent or describe the PHOSITA (person having ordinary skill in the art) in a broad vs. narrow “art”
• FRCP and FRE requirements re: opinion, factual basis, principles, and methods
• Software engineering methodology (software inspection) as non-litigation basis for software examination in patent litigation

Chapter 9: Source code discovery

• Many different issues; can be handled as who/what/when/where/why/how:
  • Who gets access to code?; whose source code?; third-party code; whose burden to explain code
  • What/which source code: specific versions requested and produced; arguably ancillary materials (test scripts, code generator input, make/build files); tools to be installed on source-code computer
  • When: schedule of source-code production, need for diligence inspecting
  • Where: production at law firm, escrow facility, development site
  • Why is the source code being requested?: relevance to specific legal questions; knowing beforehand what one expects to find
  • How: format in which source code produced; “native” format; source-code control repository
  • How much: problems of code quantity, costs, missing source code; produce all vs. partial
• Mandatory source-code disclosure under Local Patent Rules, following (sufficiently detailed?) initial/preliminary infringement contentions
• FRCP 34
• Source-code production is usually a “review,” not quite a normal doc production, and not quite an in situ inspection
• How source code differs from other documents in discovery; see article
• Relation of source-code discovery to e-discovery, ESI
• Applying Zubulake cost/benefit factors to source-code discovery
• Framing source-code discovery requests with specificity, based on pre-filing reverse engineering
• Know what you’re asking for: specific products, version numbers, platforms, components; avoiding vague “they need to give us their codes” requests
• Responding to source-code discovery requests
• Source code produced under FRCP 33(d) in response to interrogatory
• Third party source-code discovery under FRCP 45 subpoena
• Possession, custody & control of source code
• Intermingled third-party source code (cases with third-party intervenors)
• Get input files used with code generators, templates, etc., as well as generated output
• Inaccessibility, undue cost & burden, proportionality to case need
• Form & manner of production: as kept (native) vs. categorized by request; usable/searchable format
• Explanatory burden: is producing party required to explain or “roadmap” its source code, in addition to producing it?

Chapter 10: Incomplete source-code productions, spoliation and missing source code

• Reasons why some source code is typically “missing,” even while other source code has been over-produced (“dumping”)
• How examiner can determine whether the source-code production is incomplete: see chapter 16 (testing completeness)
• That some source-code files are missing does not necessarily make the source-code production “incomplete”
• Source code spoliation cases (including changing date/timestamps)
• Source code “redaction” cases (including removal of source-code comments)
• Cases: Adams v. Dell/Winbold; VocalSpace v. Lorenso; i4i v. Microsoft; Keithley v. Homestore.com Juniper Networks v. Toshiba; Rosenthal Collins v. Trading Tech.; Big Baboon v. Dell; 3Com v. D-Link (Realtek); Fleming v. Escort; GE v. SonoSite; Fresenius Med. v. Baxter; Clear One v. Chiang; SCO v. IBM

Chapter 11: Source code protective orders

• Source code usually receives a blanket/umbrella PO rather than one crafted to specific trade secrets (TS) or confidential info
• See article: “Source Code Protective Orders, from the perspective of a source-code examiner,” covering:
  • Typical source-code PO restrictions and their impact on the source-code examination itself;
  • Contradiction between “blanket” source-code PO restrictions and FRCP 26(c)(1) need to show “good cause” (particularized need for protection);
  • Legitimate reasons for restrictive POs;
  • Illegitimate reasons for restrictive POs
• See Andy Johnson-Laird article on “overly protective order”
• Case law on source-code protective orders
• Fallacy that all source code is inherently trade secret or highly confidential
• Attorneys frequently underestimate impact of agreed-upon PO restrictions on the source-code examination
• For example, in a copyright case requiring comparison between P’s and D’s source code, P and D will have agreed on a PO in which the two different source-code trees are on separate computers, and cannot be copied; how to do a quasi-comparison under such circumstances?
• See chapter 15 (source-code exam environment) on how PO can dramatically affect source-code exam
• Cases: Bergstrom v. Glacier Bay; Dynetix v. Synopsys; Kelora Sys. v. Target; BIAX v. Brother Int’l; BIAX v. Nvidia; Function Media v. Google; Ameranth v. Pizza Hut; HTI IP v. Webtech; Mediostream v. Microsoft; Apple v. Samsung; GE v. Sonosite; eBay v. Kelora; MVS v. Bingo Bean; Dynamic Microprocessor v. EKD; EPL Holdings v. Apple; Unwired Planet v. Apple

Chapter 12: Preparation for source-code examination

• Because expert/examiner will be looking in source code for specific elements/steps to match claim limitations, chapter includes a brief non-attorney’s potted guide to claim construction
• Using reverse engineering to prepare for the source-code exam (how to know what you’re looking for, before the examination, at the level of class, function, folder, and file names)
• Software-based products surprisingly often include path/filenames of source-code files, enabling creation of source-code “maps” directly from the product
• Creating forms for note-taking use during source-code exam
• Know what the narrow technical questions are, before the exam

PART III: THE SOURCE CODE EXAMINATION

Chapter 13: Purposes of, and general approach to, source-code examination

• Not a holistic exercise to understand the code, but rather a focused search for specific elements & steps to match patent claim limitations, or determine no such match
• Bottom-up vs. top-down approach
• Searching vs. tracing approach
• The source-code exam will generally yield one or more Bates-stamped print-outs of files extracted from a large source-code tree; the expert/examiner selects files to be printed, the producing party reviews them, and then produces to the requesting party
• Neither a doc production, nor an in-situ inspection; source-code exam more like “quick peek” doc review

Chapter 14: Scheduling: “diligence,” timing of source-code exam, and amendment/supplementation

• Courts have sanctioned parties for lack of “diligence” in examining produced source code (after you fought so hard to get it, remember to use it)
• If the source-code exam occurs before Markman claim construction, the examiner may need to take a flexible (both broad & narrow) approach to code/claim matching
• Often repeat source-code visits will be required
• Narrow timeframes, especially in ITC practice
• Supplementing discovery requests & responses
• Supplementing expert reports, responses & rebuttal reports
• Amending/supplementing infringement contentions & responses
• Cases: Diagnostic Sys. v. Symantec; Advanced Software v. Fiserv; Big Baboon v. Dell; Whitserv v. Computer Packages; Symantec v. McAfee; Apple/AT&T antitrust litigation; Digital Reg TX v. Adobe; Symantec v. Veeam; MetLife v. Bancorp; Apple v. Samsung; MIT v. Abacus; Garmin v. TomTom; REC v. Bamboo; AVG v. Electronic Arts

Chapter 15: The source-code examination environment

• This is where the agreed-upon protective order (PO; see chapter 11) has its biggest impact
• It is crucial that the examiner carefully read and understand the PO restrictions, before starting the source-code examination
• The source-code machine is generally disconnected from internet, so tools must be provided by producing party
• Tools commonly available as part of Windows and Apple OSX operating systems (e.g., findstr, grep, awk)
• Ability to create ad hoc tools using scripting available on Windows (VBScript) and Apple OSX (awk)
• Tools commonly provided as part of POs (Understand source-code browser; PowerGrep; dtSearch; WinMerge; etc.)
• Viewing source code in the context of version control (CVS, Perforce, etc.) vs. viewing at the OS file level
• Getting the “lay of the land”: source-code organization; producing directory listings
• Impact on the examiner of the location, time, form & manner of source-code production
• Likely contents of the source-code production: what to expect
• Examining own client’s code vs. other side’s code
• Adhering to PO even for own side’s source code, e.g. to help maintain reasonable security precaution (RSP) element of trade-secret status

Chapter 16: Testing completeness & responsiveness of source-code productions

• Source-code productions are often both over-complete (“dumping”) and under-complete (missing source code, which is not necessarily spoliation; see chapter 10)
• External test for source-code completeness: is everything that is known from reverse engineering commercial product (e.g. as part of pre-filing investigation), also visible in the produced source code?
• Internal test for source-code completeness: if need be, could the produced source be recompiled?
• Sometimes “missing” files or code are actually present; e.g. examiner assumes that all JavaScript files must have .js file extension, and overlooks *.coffee (CoffeeScript) or *.hbs (Handlebars) files; or some source code is buried inside tar or zip archive files
• Ensuring the correct version of source code has been produced, matching the accused/anticipatory instrumentality: see chapter 22

Chapter 17: Indexing source code

• In a large source-code production, searches will be too slow unless the code is first indexed (or cached e.g. in PowerGrep)
• Indexing also creates information in its own right, e.g. counts of how often a function is referenced can help provide a general “map” of the source code, and help show the role played by specific functions
• Tools such as Understand provide indexing; Lucene; dtSearch
• Deciding which subsets to index of a huge production (triage)

Chapter 18: Searching source code for patent-claim-relevant elements and steps

• This is a surprisingly lengthy chapter on what might at first seem a simple subject (“you just go in the code and look for the limitations from the patent claims”)
• How to select search terms, including synonyms and exemplary embodiments, from claim limitations
• Aliases
• Using claim differentiation, the patent specification, and claim construction, to derive search terms
• How the terminology of source code relates to the terminology of software/internet patent claims
• “Searching by counting”
• Looking for negatives (trying to show non-infringement; or trying to meet “without” limitations which call for the absence of an element/step)

Chapter 19: Tracing through code, data flow, and the internet

• Tracing functions up (who calls this function?) and down (who does this function call?; knowing this can be important in determining whether the function’s name is an accurate description of the function’s operation)
• Using OS-provided logging to assist source-code tracing
• Web Developer breakpoints, including DOM event breakpoints
• Data flow, data structures, global variables, “data reverse engineering”
• Tracing flow of internet packets (see network packet monitoring in chapter 6 discussion of software reverse engineering)

Chapter 20: “Close reading” of source code

• This chapter should be read in conjunction with Code Reading by Diomidis Spinellis
• Is there more than one way to read a given piece of source code, or is expert disagreement merely a sign that one of the experts is wrong?; is source code ever “ambiguous”?
• How do different interpretations of source code (fact) relate to different interpretations of terms in claim construction (law)?
• Using function/data names and comments, without assuming that the names/comments are correct
• Verifying that a function does what its name/comment indicates it does
• Examining data structures and classes
• Particular examples of code “gotchas”; why code examination is not merely a matter of searching, reading, or comparison of tokens, but requires understanding what the tokens represent as code, and understanding of what occurs implicitly within a line of code:
  • Function pointers and vtables; state machines
  • Hooks, on-event handlers/subscribers, run-time dynamic linking
  • Function and operator overloading
  • Implicit function invocation (e.g. C++ constructors/destructors), implicit parameters
• Mini-languages, embedded languages (e.g. SQL), input to code generators
• Child/parent class relationships
• Forward/backward caller, callee tracing
• Explain what above (function pointer, hooks, etc.) have in common: need to understand what strings/tokens represent as code; how/when/where invocations occur
• Potentially short-circuiting analysis of source code which implements and/or uses a standard

Chapter 21: “Reading on”: comparing source code to claim limitations

• Mapping of claim limitations to code elements/steps must be consistent (if A maps to X in one claim, it’s likely a mistake if B maps to X in another claim)
• Code should “face in the same direction” as the allegedly corresponding claim (e.g., server-based vs. client-based claims)
• Applying both broad & narrow claim constructions, when examining code prior to a Markman ruling (also using claim construction from other cases)
• Taking a critical look at provisional matches of code to claims
• Don’t assume that names used in code are accurate; often must look at actual operation, apart from naming
• Don’t assume that matching terms mean the same thing, or conversely that a different term is not a “hit”
• Don’t assume that comments are correct, but be prepared to use comments to simplify explanation of code
• Also brief discussion of source-code comparisons in non-patent cases, especially copyright and trade secret, generally comparing two different source-code trees, in contrast to patent litigation comparison of one source-code tree with patent claims

Chapter 22: Comparing source code to the commercial product at issue

• Is the source code in itself ever the accused instrumentality?; usually it is “mere evidence” of the internal design & operation of the commercial product/service at issue
• Having found relevant source code, ensure the source code is expressed in the accused products, and plays a sufficiently important role; see chapter 2 (e.g., “latent code”)
• Comparing source code produced in discovery, with facts learned pre-discovery from reverse engineering
• How to test that source code matches the product, including specific versions/platforms
• Dealing with “dead code”, #ifdefs, and other conditional compilation
• Can “dead code” ever infringe, e.g. as “scaffolding” or infringe apparatus claim by “making” (contrast “using” method claim)
• Did the producing party produce the correct source code for the accused product? (see also missing code in chapter 16)
• Product testing & instrumentation often make more compelling-looking exhibits than does source code
• Infringing code may belong to a small arguably-separable component, rather than to the entire accused product (see also chapter 5 on defendants, and chapter 30 on damages)

Chapter 23: Handling source-code quantity and versions

• The “quantity case” (many products x many patents/claims)
• Prioritizing, triage, schedule, budget
• Version “diffs”
• When are older versions important?: laches/SOL; priority; prior-user defense; non-infringing alternatives
• When are unreleased/forthcoming versions important?: injunction; non-infringing alternatives
• Mapping evolution of relevant functions/data over multiple product versions
• Writing small scripts, using OS tools already available on the source-code machine, to analyze large amounts of source code
• Working with version control systems

Chapter 24: Extracting relevant source code: note taking & printing

• Purpose of the source-code exam is to select relevant files from large source production; have selected source-code files (or portions of files) printed and Bates stamped
• Note-taking limits under protective order
• Potential discoverability of expert’s source-code notes
• Printing output from expert/examiner’s scripts, command lines (diff files, “dir” output, etc.)
• Printing limits under protective order; negotiating changes to printing limits
• Printing under PO is generally NOT for later analysis; analysis is generally restricted to the protected source-code room; why?
• “Why are you printing so much?”: elements/steps scattered across many files; need to print lower-level code to confirm what relevant code does; need to print higher-level code to show how relevant code is used within product as a whole

PART IV: AFTER THE SOURCE-CODE EXAMINATION

Chapter 25: Authentication & admissibility of source code

• Some auto-authentication from party’s production in response to discovery request for source code to a given product/version
• Authenticating date/timestamps of source code files
• Weight of comments, function names
• Authentication of expert/examiner’s script/command line output on protected source-code computer
• Comparison of source code with object/binary code in finished product

Chapter 26: Claim charts

• See chapter 7 on initial/preliminary infringement contentions; this chapter covers post-discovery claim charts, with “pinpoint” citations to source code; and see Claim Charts book
• Showing “location”: where each element or step resides in the accused instrumentality or anticipatory prior art
• “Where” (location) can often be shown using the other side’s function/class/file/variable names, as found in their code
• Cases requiring showing of “how” as well as “where” the limitation resides in the product
• Cases on “super pinpoint” citations (requests to “only” show code “necessary” to limitation), e.g. Vasudevan v. IBM
• Cases on merely exemplary infringement contentions (where right column of claim chart is simply a list of bullet points, or “e.g. items”): is D at some point in litigation entitled to know complete extent of what P regards as infringing a particular claim, and by implication to know what P sees as not infringing?
• Avoiding “mimicking,” i.e. simply repeating claim language to describe alleged corresponding elements/steps in the accused instrumentality, rather than using the other side’s specific names for elements/steps
• Examples of acceptable & unacceptable claim charts
• Claims tables for “the quantity case” (large number of products x multiple versions x multiple patents/claims)
• Representative instrumentalities
• Repetitive “cut and paste” tables
• Avoiding the “bag of parts” or “laundry list” problem: tying the elements/steps together
• Handling means-plus-function (“means for”) claim limitations
• Handling infringement under the Doctrine of Equivalents: parsing out function/way/result
• Showing absences (negative limitations)
• Making an actual statement in the claim chart: avoiding “see”, “for instance” and other conclusory or loose formulations

Chapter 27: Expert reports and affidavits

• Contents required under FRCP 26, and important non-required contents
• Using source code in expert reports & affidavits, under protective order restrictions against “copying” code
• Attempted “backdooring” of party contentions through expert reports & affidavits
• Relationship between expert reports and party contentions
• Balance between flexibility and commitment, especially pre-Markman
• See chapter 8 on the role of technical expert witnesses in software patent litigation

Chapter 28: Source code & depositions, interrogatories, trial, demonstrative exhibits

• Bringing source code to deposition, under protective order
• Use of source code to depose or cross-examine software developer
• Have deponent software developer draw diagrams of the source code, and/or of relevant product functionality, algorithm
• Checklist of questions which can be asked about a source-code examination
• Demonstrative exhibits based on source code
• Often, non-source evidence is more compelling-looking demonstrative exhibits; e.g. jurors may better comprehend the idea of testing/instrumentation (dynamic examination of product) than the idea of source code (static examination of something which is not-quite the accused product)
• Correlating the source code (product internals) to the visible product/service (its user interface)
• Multiple independent sources for each claim limitation (e.g. show use of network in marketing literature, in source code, and by “live” testing with network monitor)

Chapter 29: Correlating source code with non-source documents

• Searching in non-source discovery production (e.g. emails, specs) for function/data/module names learned from the source-code exam
• Public searching (e.g. in error logs posted by users, or in open source) for function/data/module names found in source code
• See also chapter 22 on correlating source code (static analysis) with reverse-engineered info from product (dynamic analysis)

Chapter 30: Source code & remedies: damages, lost profits, and injunctions

• Economists’ use of technical expert/examiner’s findings
• Economists’ own source code, including e.g., SPSS, SAS, Excel models; see case xxx in which economics expert hid methodology in uncommented source code
• Using source code to help show importance or unimportance of infringing technology in product as a whole (though typically role of infringing technology within overall product is shown more by consumer demand than by technology supply)
• Using source code to show ability to practice invention, for lost profits
• Using source code to show practicing/working invention, for ITC domestic industry technical prong, and status as practicing entity for injunctive relief under eBay v. MercExchange
• Non-source docs (e.g. emails) explaining the value of the code, and/or explaining the problems it causes; docs explaining why an approach was taken or not taken: see chapter 29 on correlating source code with non-source documents
• The lines-of-code fallacy, and other source-code metrics
• Which product is the correct baseline for damages calculations?; it may be a small separable component or it may be an entire larger (more expensive) product
• Entire market value rule
• The “date picker” problem (see Lucent v. Gateway)
• Non-infringing alternatives and design-around

PART V: CONCLUSION

Chapter 31: Source-code examination, beyond software patents

• Applying lessons learned from patent law to other areas of law in which software is at issue
• Source code in copyright and trade secret cases
• Source code in non-IP law (contracts; products liability; criminal law/procedure; administrative law)