Software Litigation Consulting (Andrew Schulman) specializes in source code examination, software reverse engineering, pre-filing investigation of software/internet patent infringement, the preparation of claim charts (infringement, non-infringement, invalidity, and validity contentions), and research in software prior art. Services include:

• Source code examination (on-site or remote) for patent, copyright, and trade secrets litigation; programming languages: C/C++, Java, JavaScript, Objective-C, C#, PHP, Python, Win32/Win64 assembler, and other languages
• Pre-filing investigation: in-depth infringement-related inspection of software/internet products/services
• Software reverse engineering, including static (disassembly and decompilation) and dynamic (e.g. network packet sniffing) methods
• Mobile app software “teardown” (bill of materials, BOM) for Android and iOS (iPhone)
• Software component analysis (SCA) of object/binary code and/or source code (software teardown, BOM)
• Locating software/internet prior art (for anticipation, obviousness, on-sale, and public-use)
• Infringement, invalidity, non-infringement, and validity contentions: claim charts, including both initial “PICs” before source code is available, and post-discovery ICs with “pinpoint” source-code citations

Services in more detail:

• Source code examination (see FAQ; “Source code and e-discovery“; forthcoming book: Source Code Examination for Software & Internet Patent Litigation: A Guide for Attorneys and Experts)
• Using reverse engineering to investigate patent infringement and non-infringement (see article “Hiding in Plain Sight: Using Reverse Engineering to Uncover Software Patent Infringement”)
• Preparation of infringement, invalidity, non-infringement, and validity charts, correlating claim limitations on the one hand with elements/steps of software on the other (see 6-part introduction to software patent litigation, and draft of forthcoming book, Claim Charts for Patent Litigation)
• Locating and analyzing software prior art (see article “Open to Inspection: Using Reverse Engineering to Uncover Software Prior Art” (Part 1); Part 2
• Software reverse engineering (text extraction, class dump, code decompilation/disassembly, network packet monitoring, in-depth examination of web sites/services, etc.)
• Comparison/correlation of source code with products/services (for e.g. “latent code” issues; and creating source-code maps from binary/object code, as preparation for discovery)
• Open-source examination: comparison/correlation of open source with products/services (including vendor modifications to open source), and with proprietary source code
• Patent portfolio analysis (ranking of claims for valuation and prioritization; initial identification e.g. from patent citations of candidate licensees or potential infringers)
• Code comparisons using binary/object code (see “Finding Binary Clones with Opstrings & Function Digests”, parts 1, 2, and 3)
• Assistance with technical aspects of complaints, summary judgment motions and responses, interrogatory and discovery requests and responses, depositions, expert testimony and cross-examinations
• Comparison and correlation of internal documents from discovery (emails, etc.) with resulting technical practices (see e.g. “The Caldera v. Microsoft Dossier” here)
• See list of sample cases and projects.

Source code examination:

Source code conforms to rules dictated by programming languages, platforms (such as Android, Windows, or the Apple iOS and OSX operating systems), APIs (application programming interfaces), and other constraints (e.g. interoperability with other software and with devices). Source code examination needs to carefully use this structured format, as opposed to merely performing a keyword search, in part because there is typically too much code to read all of it, and much depends on the proper selection of areas requiring close reading. Whereas a simple keyword search might end up treating source code as a disconnected collection of code fragments, a true source-code examination will rely, for example, on:

• the relationship between caller and callee functions;
• child/parent class relationships;
• aliasing of names used for functions, parameters, variables, and data structures;
• actual operation of code (in contrast to relying entirely on the accuracy of names or comments in the code);
• awareness of implicit function calls (e.g. constructor/destructor), implied function parameters, and other implicit code invocations
• classes and modules; directory and filename path information; version control information; and other metadata
• careful attention to function pointers (including run-time replacement of callees/targets), vtables, operator/function overloading, hooks, on-event handlers/subscribers, run-time dynamic linking, and externally-generated events; and
• tracing data flow.

Also in contrast to a simple keyword search, a source-code examination will be alert to the possibility of code which is unused in the finished product; determining code usage or non-usage may require careful tracing (distinct from searching) through the source code, comparison of the source code with the binary/object code in the finished product, or even dynamic testing of the ‘live’ product.

The dependence of source code on external constraints means that the code can often be correlated with external information, such as API documentation, SDK (software development kit) sample code, header files, open source, and so on.

Other aspects of source-code examination services provided by Software Litigation Consulting include:

• Using custom-built code-examination tools, as well as industry-standard tools (see Projects)
• Testing completeness of source-code production
• Working with source code written in in-house/proprietary “little languages”
• Careful attention to protective order (PO) requirements, including restrictions on printing and note-taking
• Comparison of open source with vendor’s proprietary modifications
• In patent cases, searching and code reading in terms of claim construction (including alternative pre-Markman constructions), means-plus-function, and doctrine of equivalents (analysis of code for function, way, and result)
• In copyright cases, detection of non-literal copyright infringement or non-infringement, using e.g. tokenization tests, and structural comparisons
• Consulting source-code examiner assistance to testifying expert witness (initial selection of case-relevant source-code files; assistance with expert report; assistance with rebuttal of opponent’s expert report; assisting with and responding to Daubert challenges on basis for expert’s opinion)

Software reverse engineering:

Besides source-code examination, another focus of Software Litigation Consulting is examining the object/binary code embodied in actual products and services. This code is often more accessible than the source code, and often provides a different perspective from the source code.

Before source code becomes available during discovery, we can usually locate relevant elements embodied in, or steps carried out by, software/internet products and services. Software/internet products/services often contain the names of functions, structures, steps of processes, and so on — often even the full paths/locations and names of source-code files. Both static and dynamic software analysis (“reverse engineering”) are employed.

Not only is reverse engineering or its equivalent generally required for a reasonable pre-filing investigation under Rule 11 and Local Patent Rules, but working directly with the accused product/service provides direction and focus for discovery, including source-code examination.

Defendants as well as plaintiffs often benefit from direct inspection of the accused product/service, which provides crucial context to what is found in the source code. The role that code plays in the actual product/service may not be apparent from looking solely at the source code disclosed by the other side.

Since anticipatory prior art must by definition have been publicly accessible at the relevant time, looking at actual products/services can be more relevant than a prior-art search focused on proprietary, closed-held, source code.

Some of the questions attorneys may have about source-code examinations and about software reverse engineering (including “Why bother with anything other than the source code?”, “How can defendants benefit from reverse engineering the relevant software?”, “Is the kind of element-by-element information I need really available without the source code?”, and “Is it permissible to reverse engineering software, even for litigation purposes?”) are addressed in the FAQ.

For contact information, see About Us or send email.

Recent CV available here; a confidential list of past cases and clients is available under a non-disclosure agreement.

Sample source-code examination and reverse engineering cases and projects here.

LinkedIn profile here

Partial collection at academia.edu of drafts and (mostly older) articles

Andrew Schulman is a Senior IT Litigation Consultant with DisputeSoft and is working with GreyB. See Partners page.