Source code ch.06: Pre-filing investigation & reverse engineering

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 6: Pre-filing investigation of software/internet/mobile products & services: Examining the product/service, without source code

6.1. Background and introduction to notice pleading, FRCP Rule 11, Local Patent Rules, and likely forthcoming legislation

  • 6.1.0 Conventional wisdom about software products & source code (the “Catch 22” or “chicken-and-egg” problem)
  • 6.1.1 Notice pleading and FRCP now-defunct Form 18 (Patent Infringement)
  • 6.1.2 FRCP Rule 11 in patent litigation; with a brief history of Rule 11; proposed changes to Rule 11 in HR 2655
  • 6.1.2B Fee awards for “exceptional” cases under 35 USC 285, for “objectively baseless” infringement contentions brought in bad faith (see article)
  • 6.1.3 Local Patent Rules and proposed legislation
  • 6.1.4 Application of Rule 11 and Local Patent Rule 3-1 to software/internet patent litigation
  • 6.1.5 Comparison to other instances where plaintiff’s burden is reduced, or presumptions are reversed
  • 6.1.6 Evidentiary doctrines of solely or “peculiarly” possessing information
  • 6.1.7 Selection of cases

6.1.1 Notice pleading and FRCP Form 18 (Patent Infringement)

  • 6.1.1.1 Iqbal, Twombly, and In re Bill of Lading
  • 6.1.1.2 General background on heightened pleading (PSLRA, Lerach, etc.; see Scott Dodson book on heightened pleading)
  • 6.1.1.3 Rule 84 forms (including Form 18) are removed in Judicial Conference Aug. 2013 proposed FRCP amendments

6.1.3 Local Patent Rules and proposed legislation

  • 6.1.3.1 Initial/preliminary Infringement Contentions
  • 6.1.3.2 Proposed legislation: HR 3309 heightened pleading requirements (but not in Leahy S. 1720?)
  • 6.1.3.3 Early element-by-element details of accused products
  • While pre-filing investigation (including “dead ends”) is protected work product (see Hricik, Patent Ethics: Litigation at 181), results will go into initial infringement contentions

6.1.4 Application of Rule 11 and Local Patent Rule 3-1 to software/internet patent litigation

  • 6.1.4.1 Post-discovery source code and “pinpoint” code citations
  • 6.1.4.2 Impact of post-discovery source code on pre-filing reverse engineering: “Catch 22”?
  • 6.1.4.3 Possible bases for the “Catch 22” view of software patent litigation
  • 6.1.4.4 Another basis for the “Catch 22” idea: Misreading of means-plus-function case (Network Caching v. Novell)
  • 6.1.4.5 Results of the “Catch 22” view of software patent litigation
  • 6.1.4.6 A software-specific “policy lever”?; but software patents are not confined to the “software industry”

6.1.5 Comparison to other instances where plaintiff’s burden is reduced, or presumptions are reversed

  • 6.1.5.1 Presumption for products by process under 35 USC 295
  • 6.1.5.2 Software as flour barrels: res ipsa loquitur for high tech?

6.1.6 Evidentiary doctrines of solely or “peculiarly” possessing information

  • Who generally knows more detailed facts about infringement, plaintiff or defendant?
  • Cases where D knows less than P about what D is doing: end-users, “mom and pops,” “covered customers”
  • Cases where P really knows almost nothing about what D is doing: see 6.1.5 above

6.1.7 Selection of Cases

  • 6.1.7.1 Northern District of California
  • 6.1.7.2 Eastern District of Texas
  • 6.1.7.3 Cases from Other Districts
  • 6.1.7.4 Cases from Court of Appeals for the Federal Circuit
  • 6.1.7.5 Summary of cases

6.2. General issues of policing/monitoring the market to detect software patent infringement

  • Demand letters
  • “Pre-filing discovery” (see Scott Dodson on “New Pleading”)
  • Searching for infringement (contrast freedom-to-operate searches)
  • “Infringement detection” using “Big Code” methods, e.g. old CodeClaim project  (article written in terms of finding non-patent prior art, but applicable to finding potential infringement)
  • Turning patent claims into “signatures” to locate potential candidates for closer inspection
  • Using patent citations as a source of “candidates” for further investigation (vendor D’s patents  X and Y cite our patent, and vendor D makes product Z, which it asserts is protected by patents X and Y, therefore Z is potentially worth closer inspection)
  • Law of private investigation in IP cases (“IP, PI”): straw purchases of tightly-controlled products, duty of candor, Model Rules 8.4(c), 4.1(a); NY bar IP exception
  • Fear and uncertainty over reverse engineering products under clickwrap license and DMCA

6.3. “Acquire the target”: Get and run the product

  • 6.3.0 Where & how to acquire products, for further inspection
  • 6.3.0.1 Standalone PC programs
  • 6.3.0.2 Mobile apps: acquiring IPA and APK files for inspection
  • 6.3.0.3 Simulator versions of mobile apps
  • 6.3.0.4 Setting up monitoring of web-based products/services
  • 6.3.0.5 Server side of web-based products
  • 6.3.0. 6 Open-source products, and products based on open source
  • 6.3.0.7 Debug versions and software development kits (SDKs)
  • 6.3.0.8 Older software
  • 6.3.0.9 Older web-based products
  • 6.3.0.10 Firmware (embedded software)
  • 6.3.0.11 “Look somewhere else”
  • 6.3.1 Products/services not reasonably accessible
  • 6.3.2 “Acquiring” a method or process
  • 6.3.3 Future and outdated products
  • 6.3.4 Expensive products
  • 6.3.5 Products with negotiated purchases (with a brief digression on pre-filing negotiations, C&D letters, “you might be interested” letters, and other pre-filing interaction between patent holder and to-be-accused infringer)
  • 6.3.5B Straw purchasers, using private investigators
  • 6.3.6 Too many products & “representative instrumentalities”
  • 6.3.7 Standards as proxies for products
  • 6.3.8 Relying on the inventor as a substitute for getting the product
  • 6.3.9 Relying solely on marketing materials instead of getting the product
  • 6.3.10 Getting the case off on the wrong foot by not inspecting the accused product
  • 6.3.11 Exhausting publicly accessible sources of information
  • 6.3.12 Inspecting the accused product is not merely to satisfy rules

6.4. Try to acquire source code pre-filing

  • 6.4.1 Open source
  • 6.4.2 Other publicly available source or quasi-source code

6.5. Reverse engineering the product or service

  • 6.5.1 Using reverse engineering as a litigation tool
  • 6.5.2 Reverse engineering “or its equivalent”: element-by-element analysis
  • 6.5.3 Is reverse engineering or its equivalent “required”? (Exhausting publicly-accessible sources of information; what is publicly accessible?; how much effort need be expended for something to no longer be publicly accessible?)
  • 6.5.4 Exception for reverse engineering when “impractical”
  • 6.5.4.1 Disproportionate expense
  • 6.5.4.2 Technical inaccessibility
  • 6.5.4.3 Impracticality of reverse engineering when source-specific information is required
  • 6.5.4.5. Impracticality from non-technical restrictions on reverse engineering: clickwrap; DMCA; Innovatio case re: Wireshark “interception”/recording to detect infringement; whether or not to “jailbreak” mobile devices
  • 6.5.5 Exception for reverse engineering when “unnecessary”
  • 6.5.5.1 Information available from indirect sources
  • 6.5.5.2 Representative instrumentalities
  • 6.5.6 Application to software of the pre-discovery reverse engineering requirement
  • 6.5.6.1 Application of reverse engineering pre-discovery requirement to software seen as somewhat unusual
  • 6.5.6.2 Application of reverse engineering pre-discovery requirement to software seen as inapplicable to software when source code will later become available
  • 6.5.7 What can be learned pre-discovery by reverse engineering software products & internet services?
  • 6.5.8 General points about static vs. dynamic reverse engineering: “Freudian vs. behavioralist”; dynamic RE only sees the particular tested configurations; danger of over-generalizing from dynamic RE
  • 6.5.9 Typically need an expert or technical consultant to do this work, but some attorneys have demonstrated ability e.g. to use Fiddler (example of Josh Rubin in Specht v. Netscape)

6.6 Static reverse engineering: examining the product files

  • 6.6.1 BOX: Know the baseline (ideally, this would be done with “Big Code”; old CodeClaim project; GitHub; searching JavaScript code)
  • 6.6.2 Locate the executable files, including e.g. mobile app IPA and APK files
  • 6.6.2B BOX: Staying away from “jailbreaking”
  • 6.6.3 Possibly expand or decompress the files
  • 6.6.3B De-obfuscation, see e.g. Android APK deobfuscation (http://apk-deguard.com/); JavaScript deobuscation, JSNice (http://www.srl.inf.ethz.ch/jsnice)
  • 6.6.4 (Usually) ignoring boilerplate standard files (see NSRL)
  • 6.6.5 Acquire any available “debug” versions of the product files
  • 6.6.6 Full-text search of product binary/object code files
  • 6.6.6.1 “Strings” (see article)
  • 6.6.6.2 Using a text-search utility (grep, findstr)
  • 6.6.6.3 What are promising-looking strings in pre-filing patent-infringement investigation?
  • 6.6.6.4 Avoiding “tunnel vision” in pre-filing text search
  • 6.6.6.5 What if there are zero “hits”?
  • 6.6.6.6 [!] What if the files are compressed or encrypted?
  • 6.6.7 Structured inspection of product binary/object code files (“dump” utilities)
  • 6.6.7.1 Get a utility such as dumppe, otool, elfdump
  • 6.6.7.2 Generate text for each code file
  • 6.6.7.3 Look for API names
  • 6.6.7.4 Look for claim terms and “synonyms”
  • 6.6.8 Function/method names inside product code files
  • 6.6.8.1 DeMangling/undecorating C++ names
  • 6.6.8.2 Objective-C code (products based on Apple OSX/iOS)
  • 6.6.8.3 Look for API groups
  • 6.6.8.4 Look for callback functions
  • 6.6.8.5 Create a product map
  • 6.6.9 Source code-related paths and filenames inside product code files
  • 6.6.9.1 Source and object filenames
  • 6.6.9.2 Object pathnames
  • 6.6.9.3 Locating third-party library path/filenames
  • 6.6.10. Source-code fragments inside product code files
  • 6.6.10.1 Assertions
  • 6.6.10.2 Logging strings
  • 6.6.10.3 Embedded code such as SQL, JavaScript
  • 6.6.11 Other text inside product code files
  • 6.6.11.1 Error messages
  • 6.6.11.2 Resources: menus, dialog box options, etc.
  • 6.6.12 Using text gathered from product code files, in preparation for filing and initial infringement contentions
  • 6.6.13 Quasi-source: Is some of the source code publicly accessible?
  • 6.6.13.1 JavaScript code
  • 6.6.13.2 Decompilation
  • 6.6.13.2.1 Java
  • 6.6.13.2.2 Flash ActionScript
  • 6.6.13.2.3 Microsoft .NET
  • 6.6.13.3 Disassembly (usually a last resort in pre-filing investigation)
  • 6.6.13.4 Open source
  • 6.6.13.5 Sample code (SDKs, etc.)

6.7 Dynamic reverse engineering: run the product, with instrumentation

  • 6.7.0 A warning about dynamic RE (and testing generally, as opposed to static examination): it will only tell you what happened in the particular tested configurations, cannot show what “always” happens, and shouldn’t be used to draw negative conclusions (e.g. “this never happens”)
  • 6.7.0b Unless if dynamic RE based on all configurations, e.g. sampling of vendor’s back-end log files
  • 6.7.1 Triggers
  • 6.7.2 Displayed text
  • 6.7.3 Using & avoiding browser features
  • 6.7.3.1 “View Source” can be misleading
  • 6.7.3.2 URL in address bar can be misleading
  • 6.7.3.3 Browser “Developer Tools”
  • 6.7.8 Network monitoring & capture (“packet sniffing”)
  • 6.7.8.1 Capturing network activity with Fiddler & Wireshark
  • 6.7.8.2 AJAX
  • 6.7.8.3 HTTPS (secure HTTP) traffic
  • 6.7.8.4 Decompressed (GZIP) traffic
  • 6.7.8.5 Network traffic not seen by Fiddler
  • 6.7.8.6 Wireshark
  • 6.7.8.7 Auto-response
  • 6.7.8.8 Searching network captures
  • 6.7.8.9 Keep & date the capture files
  • 6.7.8.10 Mobile devices, proxy servers, and Fiddler proxy
  • 6.7.8.11 Bluetooth, BLE, Zigbee, etc. monitoring with Android developer option and Wireshark btsnoop import, and/or with TI dongle/packet sniffer
  • 6.7.9 Non-network monitoring
  • 6.7.9.1 Running the program under OS-activity monitors, e.g. using Android adb logcat
  • 6.7.9.2 Application diagnostic output and logging
  • 6.7.9.3 Logging for mobile devices, without “jailbreaking”
  • 6.7.9.4 Setting the logging level, e.g. OSX write profile; iOS mobileconfig files
  • 6.7.9.5 API-level logging
  • 6.7.9.6 Debuggers
  • 6.7.9.7 Running mobile apps on desktop simulator
  • 6.7.9.8 (Gently) poke at the server; feeding inputs, collecting outputs
  • 6.7.9.9 Repeat
  • 6.7.10 Using dynamic RE results: the focus on tools above puts the cart before the horse, because the point is to use monitoring/sniffing tools not to generate data, but to help answer specific questions
  • 6.7.10.1 Know the baseline: what does “normal” look like?
  • 6.7.10.2 Do log before & after some event of interest, then diff (with normalization of e.g. timestamps) to identify changes associated with the event
  • 6.7.10.3 Sorting and counting data bytes in log files to identify patterns
  • 6.7.10.4 Writing ad hoc scripts e.g. in Awk to plow through voluminous log files
  • 6.7.10.5 Feeding input to generate implicit model; see “Stealing Machine Learning Models via Prediction APIs” here; article

6.8   Has someone else already examined the app?

6.9 Concluding points on pre-discovery investigation

 

Print Friendly, PDF & Email