Source code ch.12: Preparation for source-code examination

Source Code & Software Patents: A Guide to Software & Internet Patent Litigation for Attorneys & Experts
by Andrew Schulman (
Detailed outline for forthcoming book

Chapter 12: Preparation for source-code examination

  • Preparation both by testifying expert and by non-testifying source-code examiner
  • Testifying expert should give directions/guidance to non-testifying source-code examiner

12.1 Knowing the questions, before looking for the answers

  • Some of the following may not apply to a particular source-code examination, if e.g. there are multiple source-code experts or examiners with different scopes of assignment
  • Source-code examination in patent litigation is not a holistic exercise to “understand how the code works”
  • Instead, the examiner will be looking for match/non-match of the source code with one or more asserted patent claims
  • This code/claim matching is also not holistic, but depends on alignment of elements/steps found in code with each and every limitation found in claim
  • If seeking to show non-match, then only need to show absence of one or more limitations
  • Thus, match is AND; non-match is OR
  • Except when trying to show that patentee’s or licensee’s source code “practices” the patent (see chapter 4), the code is unlikely to use the same terminology as the patent
  • Thus, match/non-match will be between one set of terms in source code with another set of terms in patent claims; see chapter 21
  • A key to an efficient source-code exam is to know what you’re looking for, before you get there
  • This means knowing as much as possible about what terminology (filenames, function/method names) the source code employs, before ever setting eyes on the source code
  • This is often possible, because of source-code fragments found in commercial products, and the increasing use of open source in commercial products; see chapter 6 on reverse engineering products and chapter 3 on open source
  • Legal questions to be answered by source code: see chapter 4 (how source code can help answer questions about infringement, non-infringement, equivalence, obviousness, practicing/working, non-infringing alternatives, damages, etc.)
  • Questions to be answered may be more specific than “is this claim limitation present? how about this one?”; e.g., does the claim require that both x and y be in same packet?; or can they be in separate packets but part of single message; etc.?
  • Some of these questions will only be clear after initial source-code review, and may involve legal questions about what the claim limitation means (claim construction) rather than factual questions about what the code does
  • Some questions relate to the source-code production itself: was the correct source code produced? is the source-code production complete? (see chapter 16)
  • Formulate a series of testable assertions (but it may be preferable to keep them loose), and consider how they will be tested using the source code

12.2 Understand the asserted claims: a potted guide to claim construction

  • The expert/examiner will be looking in source code for specific elements/steps to match claim limitations
  • This matching will likely occur before a Markman claim-construction hearing
  • The expert/examiner therefore needs to consider both broad and narrow readings of claim limitations
  • [Brief non-attorney’s potted guide to claim construction: independent vs. dependent claims; method/apparatus/system/medium claim types; parsing claims into limitations; clauses which are not limitations; preambles; wherein/whereby clauses; comprising/consisting; “means for”; claim differentiation; reading claims in light of specification; “own lexicographer”; etc.]
  • Make sure you know which claims are being asserted
  • Knowing why some claims were NOT asserted, to aid understanding of asserted claims
  • “That which infringes if after, anticipates if before”
  • Understanding subtle differences between claims which appear to say the same thing
  • Thinking through method vs. apparatus vs. system vs. medium claims
  • Thinking through making vs. using vs. selling/offering vs. importing infringement types

12.4 Knowing what to look for at the source-code exam, before the exam: source-code information embedded in commercial products, and open source used as basis for commercial products

  • Knowing which commercial products/versions/platforms/services are at issue: read the complaint, initial infringement and invalidity contentions, etc.; e.g., expert/examiner working for D should carefully study P’s initial infringement contentions
  • See product reverse engineering in chapter 6, including discussion of legal concerns over use of reverse engineering as a litigation tool
  • Software-based products surprisingly often include path/filenames of source-code files, enabling creation of source-code “maps” directly from the product
  • Using any public source code (e.g. open source, SDKs) before the source-code exam
  • Review any public non-source materials (technical manuals, etc.) before the source-code exam

12.5 Accessing the vendor’s non-public documents produced in discovery

  • In addition to public sources of information, expert/examiner needs produced internal documents e.g. specifications
  • Pros and cons of expert’s direct access to e.g. Concordance discovery database
  • See also chapter 29 on correlation of source code with non-source docs

12.6 Creating forms to guide note-taking at the source-code exam

  • Claims table with left-hand side filled in, room for notes in right-hand side (see chapters 7 and 26 on claims tables)
  • If product included extensive source-code information, checklists with source-code pathnames and filenames, function names, class names
  • Will want to discuss exam process in expert report (see chapter 28), so possibly prepare a checklist; be prepared to keep notes re: process itself, as well as specific findings
  • Pros and cons of the above preparation (con: if discoverable, makes an excellent subject for deposition)

12.7 When to go: the need for “diligence”

  • Cases establishing the need to review source code soon after its production
  • Scheduling, budget, estimating

12.8 What to bring and NOT bring to the source-code exam

  • Why it is important to bring the protective order (PO; see chapter 11) to the exam
  • Any discovery requests and responses which relate to this source-code production, for use in test for responsiveness and completeness; hopefully the expert/examiner will have helped draft the discovery request
  • Any interrogatory responses pointing to source code which is expected to be produced
  • Forms (see above) and notes from examination of the product
  • Carefully read the PO to determine whether a laptop or mobile device can be brought into the same room as the source code, whether a separate room will be provided at the source-code site, whether a laptop or tablet can be used for note-taking if it lacks a camera, etc.


Print Friendly, PDF & Email