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 28: Using source code at depositions, in interrogatories, and at trial (including demonstrative exhibits)
28.1 Deposing the source-code developer
- We won’t cover general deposition issues here, just depositions as they relate to source code
- Get names of potential deponents from source code comments and from version control (see “Who wrote this code?” in chapter 4; code may contain initials or email addresses rather than names)
- Bringing source code print-outs to deposition, under protective order (see chapter 11 on PO restrictions)
- Security precautions for using source code at dep, e.g. take dep at source-code location or where secure laptop has been transported by bonded carrer (Nomadix v. HP; see useful article by Andrew P. MacArthur)
- Deponent’s likely preference for electronic access to source code (rather than print-outs)
- Deponent may say, “I could answer that if I had source code in front of me,” and PO may appear to preclude that
- Conversely, if source code is available at dep, deponent may use it to “snow” attorney
- Direct deponent to particular place (function name, class definition, etc.) in a given file, or risk long delay while deponent slowly peruses entire file
- Avoid questions which invite deponent’s reading entire source file (“does it say anywhere in here that…?”)
- Limited use of source code, given 7-hour time limit
- Helpful to have technical consultant with attorney at dep, but careful that consultant does not take attorney into the weeds
- Generally preferable to have non-testifying consultant assist at dep, rather than testifying expert (ABA, Litigators on Experts at 181-2)
- 30(b)(6) deponent without source-code access should call coworkers at break, to get source-code answers
- Deposition as replacement for access to third-party source code: sometimes, 3P may provide engineer for deposition, rather than providing source code (Realtime Data v. MetroPCS)
- Depositions from former employees: if engineer has left company, may need dep; but caution: former employee post-employment continuing duties of non-disclosure
- In rare instance of “discovery about discovery” (see chapter 9), may need deposition from “custodian” of source code
- Showing deponent source code print out, and asking questions
- Attorney’s own expert and technical consultant are a good source for questions
- [List of sample questions here, e.g.: “what’s this function do?”, “which file contains the implementation of x?”, “who calls this function?”, “is this function name accurate?”, “is this module/file used in the product?”, etc.]
- The power of just asking : programmers say “Use the Source, Luke” (UTSL), but they also say “Just Ask” (this may also be basis for an expert’s reliance on deposition testimony; see chapter 8 on bases for expert opinion)
- Important to ask about presence and absence of each claim limitation
- But important to ask questions of engineers in the right way, using terms they can agree with
- Avoid using your own side’s claim terminology; it is easier for deponent to answer “no” (and for opposing attorney to object “calls for a legal conclusion”) if the question explicitly uses language of claim limitations (see also “mimicking” in chapters 7 and 26 on claims tables)
- Attorney should try to use deponent’s own terms: terminology from the source code, and/or learned from examination of product (see chapter 6)
- In addition to using the appropriate nouns, think carefully about verbs
- E.g., if attorney asks deponent whether X does Y, deponent will with complete comfort say no, if X does Z, and Z in turn schedules a later call to Y; thus, instead of asking “does X do Y?”, ask: “does X either directly or indirectly result in the execution of Y?”
- Attorneys often think that an “uncooperative” engineer deponent has been “coached” (woodshed), and probably has been, but real reason for not answering yes, to a question attorney thinks deserves a yes, is that engineer is naturally being literal minded, and that attorney asked a question for which “no” was the literally correct answer
- Have deponent draw a diagram of how the relevant source code works: get top-level diagram as engineer would do for less-technical managers, but using names of functions and files; this does not violate rule against requiring creation of new documents in discovery [cite case]
- Get explicit reference from deponent to particular source-code functions or files, as alignment afterwards of testimony with source code may otherwise be difficult
- Using dep to get quasi-authentication/acknowledgment of your source-code examiner’s own output printed from protected source-code machine: e.g., dir, diff, grep listings (see chapter 24)
- Vasudevan v. MicroStrategy: ordering deponent to testify on the source code produced [check]
- Big Baboon v. Dell: P request 30(b)(6) dep of D programmer to help understand how code works, but didn’t ask for 30(b)(6) until almost 4 months after had source code access [or after did source-code exam?]
- Committing the deponent to provide additional documents noted during the deposition
28.2 Deposing the source-code expert/examiner
- Checklist of questions which can be asked about a source-code examination; see chapters 20 and 21 (same questions that source-code examiner should ask self during examination about code/claim matches, are questions that could be asked at deposition)
- Scope of assignment: “What were you asked to look at?; what were you NOT ASKED to look at?; what were you ASKED NOT to look at?; so you were told not to think about X, and you didn’t?; isn’t X something you would consider in your non-litigation work?”; “what haven’t you done (yet) in the source code, that you would have liked to do?”
- Questions regarding notes taken during source-code examination (even when notes themselves not discoverable); why expert/examiner first though X but later concluded Y; why noted presence of X but didn’t follow up; see chapter 24
- “What is the smallest change in this code which would change your opinion?; e.g., what would take it from literal infringement to equivalence?”; then probe separate components of equivalence (function, way, and result are three different things; see chapter 4)
- Ask about relation of testifying expert with non-testifying consultant/examiner
- Deposition of non-testifying examiner is unlikely (work product), but non-testifying expert works under direction of testifying expert, and testifying expert is possibly relying on non-testifying expert at least to select/extract particular files from larger set of produced source code (see expert role in chapter 8)
- “What has non-testifying consultant/examiner done, which you, the testifying expert, are relying upon?”
- Methodology for drawing conclusions of presence/absence of claim limitation, from presence/absence of particular source code; i.e., what is expert’s methodology for matching code to claims?
- See chapter 8 for questions probing into frequent expert assertions that “I just let the speak for itself”; showing that the expert has opinions with underlying assumptions and underlying selection of facts
- Locking-in and narrowing source-code examiner’s interpretation of code, identification of relevant files
- Limiting scope of further source-code or product examination
- Questions regarding any source code created by examiner for automating source-code inspection or for product testing; using any ambiguities in examiner’s code to highlight possibility of differing interpretations of source code at issue in case
28.3 Remember to use the results of the deposition
- Sometimes attorneys struggle to acquire evidence, or to have it admitted, and then forget to use it
- Someone has to go through dep transcripts, and pull out everything regarding each claim limitation
- Sometimes deposition testimony can be used as a substitute for source code, in supplying one or more claim limitations; see also properly using comments in source code (chapter 20) and using non-source documents (chapter 29) to supply claim limitations, especially those which are common to software patents generally (CPU, network, memory, etc.)
- Sometimes difficult to correlate dep testimony with particular pieces of code, so try to get explicit cite from deponent
- Supplementing discovery requests after deposition: see Fresenius Med. v Baxter (knew from deposition that source code production was incomplete) [also note this in ch.16 re: testing completeness]
- Using dep testimony to provide additional evidence for expert/examiner’s conclusions from source-code examination
- If an issue is made of expert’s reasonable reliance on deposition testimony in drawing conclusions, note that “just ask” is standard non-litigation practice for software developers
- But experts should avoid trying to take on the fact-finder’s job e.g. by asssessing credibility of deposition testimony; instead, note consistencies or inconsistencies with other evidence, especially the source code
28.4 Interrogatories prior to the source-code examination
- [This and 28.6 below don’t belong here chronologically, but it otherwise makes sense to discuss them here; could put in chapter 9 on discovery, but that chapter focuses on document production, rather than other forms of discovery, and is already overly-long]
- Patent Local Rule e.g. 3-1 is intended to take place of series of interrogatories that parties would otherwise likely propound; see chapter 7 on initial claim charts
- Coupling interrogatories with source-code production requests
- Limited to 25 interrogatories, so don’t waste; contrast requests for admission; some of the following rogs should thus perhaps be deferred until after initial source-code examination (see 28.5 below)
- Some rogs may also be unnecessary if proper pre-filing investigation has been done (see chapter 6); instead use request for admission (see 28.6 below)
- Rogs to ask which source-code files are used to build accused product
- Rogs to ask for names of software developers, and relevant dates of code (which may not be present in source code itself; see chapter 15 on likely state of source-code production); see LaserDynamics v. Asus
- See also chapter 9 on requests for production of non-source documents related to relevant source code, e.g. “any emails, specifications, bug reports, testing results, internal wiki pages, etc. related to the following source-code filenames and functions”
- Rogs to ask which source-code files are primarily responsible (higher level) for a visible feature of the product (contrast asking which code carries out a particular claim limitation)
- Rogs to ask which lower-level functionality (libraries, frameworks, etc.) are used by the primarily-responsible source code
- By requesting list of filenames, function names, class names, network protocol names, etc.that do X, get other side’s characterization of the relevant code
- Other side will of course deny that it even does X, but even with boilerplate responses, other side will often more-or-less helpfully state, in so many words, that “without in any way accepting we do X, we do something like it (or the closest we come to it, which is a mile away) is in filename A, functions B and C.” [Expert/examiner will of course use this during source-code examination; see chapter 12]
- FRCP 33(d): rog calling for narrative response, can instead be answered with business records (here, source code)
- If interrogatory responses arrive after source-code exam, supplemental source-code exam may need to be scheduled (see chapter 14)
28.5 Interrogatories based on results of the source-code examination
- Supplemental interrogatories after initial source-code examination
- Using produced source code to add specificity to interrogatories
- Rog to ID developers of source code, where not known from source code (do this AFTER get source, since may be clear from source code itself, and won’t spend a rog)
- Each party should have its own expert capable of interpreting the source code, and generating narrative (see chapter 8 on expert’s role)
- But the producing party presumably has greater knowledge of its own code than does the requesting party
- Thus, a party is still often entitled to a narrative description, “roadmap,” or “teaching documents,” even after it has the other side’s source code: see LaserDynamics v. Asus; Leader Tech. v. Facebook; see chapter 6 generally on whose burden it is to explain what code does, whose burden to provide greater specificity (BigBand v. Imagine)
28.6 Requests for admission
- “Admission” as in acknowledgement, not stipulation to evidence admissibility (except, admit that doc is authentic; see chapter 25)
- No limit on number of requests for admission (contrast 25 rogs)
- Effect of denial, if later proven
- 30 days to admit, deny, or object; after 30 days, deemed admitted
- E.g., admit that product X includes & uses claim limitation Y, at least for more generic Y (network, CPU, etc.); to be useful, admitted inclusion or use of Y must be in same context as disputed limitations (see “no bag of parts” in chapter 26)
- E.g., admit that prior art X discloses claim limitation Y
- E.g., admit that not pursuing a particular theory, e.g. equivalence, on-sale bar
- Contrast admit/deny presence of claim limitation here with deposition (“calls for a legal conclusion”)
- After source-code exam, narrowing issues with requests for admission that a specified piece of source code performs a particular task or brings about a particular result, e.g. “11. Admit or deny that function DoXandYandZ in file f.c performs the operations X, Y, and Z. 12. Admit or deny that the comment immediately preceding the function accurately describes the purpose of DoXandYandZ as “Prepare a gimlet object for transmission over network”
28.7 Using source code at trial: direct and cross examination
- Step through limitations with own expert, regarding each ask if present or not present, how expert knows
- How do you know?; see chapter 8 on expert methodology
- Often better in trial testimony to refer to more understandable bases than source code, e.g., expert did “live” testing of product, followed by a brief “And did you see this in the source code?”
- Want to avoid too much source code in direct; use other more visible forms of evidence
- Keep it simple, but be ready with complex (gory details) if challenged
- Better to use source code in cross examination than in direct examination?
- Explaining code’s structure vs. explaining its function/purpose
- Temptation to provide all evidence for presence/absence of claim limitation, but remember that showing too many citations tends to suggest case is weak and needs all this corroboration; keep some in back pocket, to use if challenged
28.7B Expert’s trial testimony
- Oral vs. written direct testimony
- Avoiding partisanship, advocacy
- Demeanor is fact-finder’s “touchstone” (proxy) for reliability
- Anticipate likely questions, quibbles, challenges; pros & cons of responding ahead of time vs. keep in back pocket
- Including background needed by fact-finder: supply major premise for syllogisms, e.g. an X is always/usually/rarely/never a Y; the code implements X; therefore, match/not-match to claim limitation Y (see chapter 8 on expert role, including having some non-ipse dixit basis for the major premise, e.g. articles from CiteSeer)
- Avoiding characterizing code or claim limitations with “patent profanity”, e.g. “very important feature”, “key feature”, etc. (see chapter 28 on expert reports)
28.8 Source code and demonstrative exhibits
- 28.8.1 Non-source demonstratives are preferable to source code
- 28.8.2 Showing source code snippets in demonstrative exhibits
- 28.8.3 Analogies
- 28.8.4 Claims chart as demonstrative exhibits
- 28.8.5 Diagrams
- 28.8.6 Videos and “live” demonstrations
- 28.8.7 The law of demonstrative exhibits
- 28.8.8 Critiquing the other side’s demonstrative exhibits
28.8.1 Non-source demonstratives are generally preferable to source code
- Often, non-source evidence is more compelling-looking demonstrative exhibits
- 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)
- General problem of explaining results: forest/trees
28.8.2 Showing source code snippets in demonstrative exhibits
- Remember, if derived from source code under PO, exhibit likely also under PO (see chapter 11 on “tainting” of materials based on protected source code)
- Preferable to have as many claim limitations on same page (within one function, or file), rather than scattered: show use/call in 1 place, leave showing scattered implementation if asked; if can show on one page, then not mere parts list (see chapters 7 and 26 on claims tables)
- Turning piece of source code into “smoking gun” diagram?
- Use of source-code comments in demonstrative exhibits
- Correlate source-code snippet with statements more readily understandable than the source code itself: non-source doc (e.g. email, change log) or deposition testimony, explaining reason for code (“we did it this way because…”) or for change to code
- What is smallest snippet of source code that can be pointed to, in a way that fact finder will see (readily understand) with minimal explanation?
- Rule of completeness (FRE 106)
28.8.3 Analogies
- Analogies and the importance of non-expertise: Need non-tech people to help with analogies;
- Someone familiar with tech may not be as good, because don’t feel need to explain e.g. what web page is
- But careful about analogies, which can often be turned against you
- Especially beware of spur-of-the-moment ad hoc analogies
- Some analogies for aspects of source code which work, don’t work, for D and P; using other side’s analogy
- Don’t trivialize
28.8.4 Claims chart as demonstrative exhibits
- Simplified claims tables: fitting the output from chapter 26 onto one posterboard
- Demonstrative exhibit with checklist of limitations:
- Generally, D in an infringement action would prefer more limitations and P would prefer fewer, because every limitation is another thing which P must separately prove in order to show infringement. In defending patent validity, P will naturally prefer more limitations and D fewer, as each limitation is another thing which D must separately prove to show anticipation. These countervailing constraints should confine the parties to reasonable parsing of the claim.
- On the other hand, if P is confident that it can show that D meets every sub-limitation, then it may prefer to thinly slice its claim, as this would result in a more powerful demonstrative exhibit for trial (or settlement negotiations): showing that infringing the claim requires 13 different things and that D includes every one of those things (“a baker’s dozen, ladies and gentlemen of the jury”) is more powerful than showing that D only does 4 different things.
28.8.5 Diagrams
- Companies that specialize in demonstrative exhibits, e.g. TheFocalPoint.com
- Using the other side’s diagrams from internal documents, e.g. vendor’s internal flowcharts (see chapter 29 on using non-source documents)
- Possibly show alignment of code with any patent drawings, but don’t want to suggest that drawings rather than claims constitute the patented invention
- Diagrams auto-generated by tools such as Understand: call sequences
- Using GraphViz
- Call tree
- Network ladder diagram for client/server
- Higher-level “cloud” diagram (components, not sub-components), with gradual exposure of detail
- Timeline
28.8.6 Videos and “live” demonstrations
- See chapter 22 on matching source code to product, correlating internals (source code) to externals (GUI)
- Live demos risky, but also problems with videotaping (e.g., US v. Microsoft video not all done in one take)
- Movie of web site and browser “Web Developer” window, showing GUI and code at same time
- Videos of dynamic reverse engineering of product (packet sniffer, etc.; see chapter 6)
- Using old contemporaneous video demos
28.8.7 The law of demonstrative exhibits
- Must be accurate representation of what purports to depict
- Merely illustrates witness testimony
- Can’t unfairly depict (range, scale), but emphasis allowed
- Does exhibit illustrate facts (less foundation necessary) or compile/explain facts (more foundation)?
- Possibly summary of voluminous material (FRE 1006); see authentication/admissibility in chapter 25
- Use law of demonstrative exhibits as basis for critiques (see below)
28.8.8 Critiquing the other side’s demonstrative exhibits & analogies
- Exaggerated proportions: e.g., patented invention only one small part of accused instrumentality, but P’s exhibits suggest larger role
28.8.9 Miscellaneous points about trial testimony and demonstrative exhibits
- “Show and tell”: showing is preferable to telling; this is not only story-telling 101, but also reflects patent law’s emphasis on structure (what something is, or what it does) rather than purpose
- Want to point to something which others (fact finder, other side) will SEE as doing or embodying a given claim or limitation, rather than something which requires explanation in order to tie it to the claim or limitation
- In other words, want match, non-match (of code with claim) to be apparent, with as little expert explanation as possible
- But risk that as statements made clearer, other side’s refutation becomes easier; need only find one exception
- Also, readily-apparent matches (e.g., claim calls for “X” and code contains function named “X”) are subject to challenge as facile comparison based only on name; expert must be prepared to show that name “X” accurately reflects that function really is doing X, as its name/comments state, and that this X is the same as X in the patent claim
- Thus, initially SHOW x, but be ready with ability to TELL why, if challenged?; this matches FRE allowing opinion before basis
- Alluding to, even if not showing, multiple independent sources for each claim limitation (e.g. point to use of network in marketing literature, in source code, and by “live” testing with network monitor)
