Trade secret misappropriation elements in software disputes refer to the specific legal requirements a plaintiff must satisfy to establish that protectable information was wrongfully acquired, disclosed, or used. In software cases, meeting each of those elements demands rigorous technical analysis.
Software-related trade secret cases are among some of the most aggressively litigated disputes in the technology law space. Like many technology related disputes, they are complicated and involve significant effort to identify, contextualize, and establish facts material to the outcome of the matter.
Whether the claim involves stolen source code, misappropriated algorithms, or an engineer who departed with proprietary system designs, the consequences of lost competitive advantages, revenue exposures, and reputational harm can escalate quickly.
Unlike other intellectual property frameworks, like patents or copyrights, trade secrets are neither acquired nor represented by a physical tangible item, such as a registered patent certificate disclosing an invention or discovery, or a copyright registration certificate reflecting the scope of one’s creative work. Instead, trade secrets, by definition, are secret.
The secretive nature often presents unique and challenging evidentiary considerations.
· How does one identify specifically the scope of the trade secret?
· How does one prove the claimed secret(s) were improperly acquired, disclosed, or used?
· How does one prove that the claimed secret derives independent economic value?
· How does one prove the claimed secret is not generally known or readily ascertainable in the industry?
Taken all together, this becomes a complex question of, how does one establish all of this, especially where the claim concerns something that, by its very definition, is a secret?
Unlike patents and copyrights, software trade secrets are often a black box; they’re embedded in code architecture, program logic, data structures, and many other elements within the software. Their existence, and indeed their value, may not be obvious even to technically sophisticated users or observers.
Thus, establishing what qualifies, what was taken, and whether it was taken improperly, requires methodical and thorough technical analysis. For a broader look at how software trade secrets are identified and protected throughout litigation, see our related discussion of protecting trade secrets in IT litigation.
This article examines each element and explains how technical expert analysis becomes indispensable to the matter.
Why Software Trade Secret Cases Are Uniquely Complex
There are a few factors that contribute to the complexity of software trade secret misappropriation matters:
· Software trade secrets rarely exist in a single unitary form; they’re often distributed across code bases, documents, version control histories, configuration files, and employee communications; identifying them necessitates considering a wide variety of information
· Establishing or defeating claims of misappropriation is technically difficult due to idiosyncrasies in the industry; the same underlying technology may be independently developed by two competing companies with their fingers on the pulse of the industry
· Digital evidence is both voluminous and perishable; code repositories, access records, email metadata, and device forensics necessitate careful, often immediate, preservation
· Cases routinely involve interpersonal dynamics not always present in other types of cases, including departing employees, competitive hires, NDA disputes; layering employment law complexity among the already complex subject matter increases the challenge
The Elements of Trade Secret Misappropriation: An Overview
Both state and federal courts apply a similar legal structure when considering trade secret misappropriation matters. A plaintiff must establish (1) the existence of a protectable trade secret; (2) reasonable measures to maintain its secrecy; and (3) acquiring the trade secret through improper means.
The legal standard varies modestly by jurisdiction, but the underlying evidentiary demands are largely consistent, whether in federal or state court. In the section below, we discuss each of these elements and how expert analysis helps develop support for establishing each one.
Element 1: Existence of a Protectable Trade Secret
The term “trade secret” is generally defined as information that has independent economic value from not being generally known or readily ascertainable, and that the owner has taken reasonable measures to keep that information secret. To establish the existence of a trade secret, it is often necessary to establish each component of this complex definition, entailing a thorough and detailed analysis of technical information and documentation by a technical expert.
Trade Secret Identification and Scope
Before litigation, a trade secret misappropriation expert witness can help counsel identify specifically what qualifies for trade secret protection, if not already known. This analytical work includes working collaboratively with the developers to understand the software, identify areas to probe and investigate, and carrying out the investigation.
It also involves applying various source code analysis techniques, review and evaluation of technical documentation, including design and development artifacts and communications, and industry research to fully understand what may be claimed versus what likely meets the definition.
Further, technical experts can provide preliminary evaluation of the information to determine whether any components are sourced from publicly available libraries, open-source components, or are reflective of industry-standard approaches. This helps narrow trade secret designations early in an effort to ward off procedural challenges.
Discovery Support
Trade secret matters, much like other types of matters in software disputes, often generate enormous technical discovery demands inclusive of source code productions, version control logs, access records, device forensics, employee communications, and numerous other categories of information.
Moreover, what a party is claiming as a trade secret is not always clear cut or apparent without considering much of the context as provided via these categories of information. A software expert can help counsel understand which pieces of the puzzle to consider, what to request in discovery, what to preserve, and help identify which artifacts are most probative of the remaining elements of the trade secret misappropriation claims.
Element 2: Reasonable Measures to Maintain Secrecy
One of the key points of evaluation considers whether the party claiming trade secret has exercised reasonable means or efforts to protect and maintain the secrecy of the claimed trade secret information. Without establishing sufficient proof, it may be inferred that the claimant failed to treat the information as a trade secret.
In practice, this may be reflected among a variety of technical and written materials, such as confidentiality agreements, access logs and commit histories, employee onboarding and offboarding procedures, data handling and retention policies, document and artifact labelling policies, and numerous others.
Technical experts can evaluate this data, from both an industry practice and technical perspective, to determine whether the security posture matches the claimed sensitivity of information, or whether the practices match the policy representations as provided through internal documentation. The technical evidence may establish material facts that support inappropriate access, disclosure, or use, in violation of existing policies.
Document and Artifact Analysis
Given the enormous technical discovery demands, the ability to quickly sift through source code productions, version control logs, access records, device forensics, employee communications, company policy documentation, and numerous other categories of information can enable counsel to more quickly understand what is material versus what is superfluous.
Throughout the discovery process, experts can help narrow the search for material documentation and technical artifacts to establish or refute claimed security postures and practices. Technical experts with experience in investigating software-based trade secret misappropriation claims can help counsel understand which artifacts are most probative, not just in regard to efforts to maintain secrecy, but concerning acquisition or use of the trade secrets.
Damages Support
Remedies in trade secret cases can range from injunctive relief to monetary damages. Monetary damages may include calculations of unjust enrichment or reasonable royalties. A technical expert can help support or bolster the economic value of misappropriated information and identify relevant periods of competitive advantage a defendant gained in their wrongdoing.
For example, if a trade secret claimant has historical records reflecting the research and technical development efforts of their trade secrets, a software trade secret expert can analyze this information to allow a damages expert to prepare an estimated value of avoided costs by a wrongdoer. Similarly, a technical expert can help determine at what point in time the claimant reasonably possessed the trade secret and began extracting economic value from it to support a variety of damages calculation theories, including reasonable royalties or damages.
Element 3: Misappropriation — Improper Acquisition, Disclosure, or Use
One of the most technically demanding elements to establish or contest in a software trade secret misappropriation case is showing improper acquisition or disclosure of the trade secret, and use of the trade secret by a defendant. Misappropriation requires showing a defendant acquired the trade secret through improper means, or without authorization, or inappropriately disclosed the information to a third party.
Source Code and Metadata Analysis
A technical expert can evaluate forensic artifacts and source code repository activity across key points in time, such as the activity just prior to and immediately after an employee departure, to trace the origins of portions of the source code. This information can support or refute claims that an alleged wrongdoer has independently arrived at the same solution or whether the claimed information was in the public domain or otherwise readily ascertainable.
Expert Report and Testimony
As is the case with other types of matters we’ve discussed on our blog, being prepared to submit a technically rigorous, court-ready report, and being prepared to testify clearly at deposition and/or trial and to defend that report is paramount to the outcome of the case. While a software trade secret expert certainly provides meaningful value through assisting with preliminary evaluation, discovery support, and supporting damages experts, such an expert is uniquely qualified to review and analyze technical information, reach conclusions and findings, and communicate those findings in a way that is understandable and defensible.
Reflection: Differences Between Trade Secret Analysis Compared to Copyright and Patent Analyses
Expert analysis in different contexts requires different analytical techniques driving toward the same general objectives: identify technical facts that are material to the disposition of the case, and provide in-depth analysis of how those technical facts drive a historical and accurate narrative. The goal in software trade secret misappropriation analysis is much the same, and benefits from many of the same analytical methods discussed recently, though with its own unique considerations.
Consider source code analysis for copyright infringement matters. This type of analysis entails both a direct literal comparison of code sets, as well as application of the “Abstraction-Filtration-Comparison” test to detect non-literal similarities. Though the ultimate factual questions may be different, the AFC test can be a useful analog for developing the facts in the trade secret misappropriation context as well, as trade secrets within computer software can take on numerous forms beyond the literal source code.
For example, consider the following hypothetical: Company A is alleging Company B misappropriated Company A’s trade secrets present in its proprietary customer relationship management (“CRM”) system, which is composed of a large volume of historical data from Company A’s entire business history, and reflects unique information Company A learned about each of its clients through decades of business relationships. This CRM system can detect early warning signs of client relationship deterioration through a combination of its historical data, proprietary algorithms, and customized automated trigger mechanisms that flag issues against Company A’s defined business risks.
Foreseeably, any specific component of this CRM system may be eligible for trade secret protection, but merely looking at the source code, or comparing it to Company B’s may not, on its own, establish any actual trade secrets, or prove or refute any wrongdoing. To answer those questions, a software expert may need to deconstruct the program borrowing from the AFC methodology, to analyze the software at different levels of abstraction, and begin investigating:
(a) Whether any particular component is not generally known or readily ascertainable;
(b) Whether allegedly proprietary algorithms and methods are truly proprietary, or are common industry practice;
(c) Whether any specific component of this provides an independent economic value to Company A; and
(d) Whether, or to what extent, Company A has used reasonable techniques to protect parts of their CRM from disclosure.
By comparison, an expert evaluating the same CRM system in a copyright infringement investigation may only be asking:
(a) Whether the underlying source code is protectable expression;
(b) Whether Company B had the requisite access and ability to copy Company A’s source code; or
(c) Whether or to what extent actionable similarities between the two company’s CRM systems are qualitatively or quantitatively significant.
In this hypothetical, a software expert who has worked on copyright matters has the benefit of experience to identify methodological approaches used in one context that may be helpful in a different context where the factual questions that must be answered are different. For instance, a software expert who has performed an AFC test in a copyright matter, may apply the ‘abstraction’ step of the AFC analysis to identify and analyze the data structures and algorithms of the CRM system, and assess whether it’s proprietary, whether repository metadata reflect restricted access to show it was subject to reasonable means to maintain secrecy, or, when evaluating an alleged wrongdoer’s system, whether the data structures and algorithms were acquired, disclosed, or used it improperly in their system.
Consider the same hypothetical as above, but Company A’s CRM system is the preferred embodiment of its registered patent, and Company B’s system is being investigated for patent infringement. An expert may be looking at Company A’s patent and/or its CRM system, alongside Company B’s CRM system and be asking the questions:
(a) For any of the proprietary features or functions of the CRM system, what was the state of the art at the time Company B allegedly developed and implemented it?
(b) Does Company B’s implementation practice every single limitation identified in the patent?
(c) How does Company B’s implementation differ from the patent claims?
The state of the art at the time speaks to the elements of what was generally known or readily ascertainable at the time of development of a potential trade secret. Whether all elements of an alleged trade secret have been implemented or if there are differences in implementation speaks to the question of whether a potentially misappropriated trade secret was ever used. A software expert who has worked on patent matters has added benefit of experience to apply methodological approaches used in other contexts (e.g., preparing claim charts and tracing functionality) that may help answer questions as to whether Company B has committed any wrongdoing or has independently developed its own solution, or whether the claimed trade secret was readily known or generally ascertainable in the industry at the time.
Conclusion
Trade secret misappropriation cases involving software are technically demanding matters in commercial litigation. Each element of the claim necessitates technical analysis that goes beyond what document review and legal argument alone can often support. Engaging a qualified software expert early, even before filing, can shape discovery strategy, sharpen the claims, and strengthen the evidentiary foundation from the outset. Attorneys evaluating software trade secret disputes are encouraged to contact DisputeSoft for a confidential case assessment. With over 23 years of experience analyzing complex software and IT systems, DisputeSoft’s experts bring the technical depth, forensic capability, and testifying experience to support counsel throughout the process.
FAQs: Trade Secret Misappropriation Elements in Software Disputes
What are the three elements of a trade secret misappropriation claim?
Courts generally require a plaintiff to establish three elements: (1) the existence of a protectable trade secret, (2) that the owner took reasonable measures to maintain its secrecy, and (3) that the information was acquired, disclosed, or used through improper means. In software disputes, satisfying each element typically requires the kind of technical analysis discussed throughout this article — from source code review to forensic investigation of access and use.
Why are trade secrets in computer software challenging to identify?
For two reasons really: (1) the complexity of the technology, given the context of the legal definition, means potentially any part of the system could be a claimed trade secret provided it meets the other requirements of the definition; and (2) the scope of what is claimed and what actually does qualify is not always immediately apparent even to a highly sophisticated analyst. Meeting the requirements that trade secrets be identified with a particular degree of specificity in a court setting necessitates gaining a full and thorough understanding of how the definition is met, which may entail numerous evaluative and analytical methods be applied to be certain.
What is considered a reasonable measure to protect a software trade secret?
Examples include, but fundamentally are not limited to, non-disclosure agreements, consistent labelling or tagging of such information, restricted access and use across members of the company, internal policies and procedures around communication of sensitive information. It’s key to remember “reasonable” to one small company may not be considered “reasonable” to a larger, much more sophisticated company.
How does a software trade secret expert’s analytical approach differ in this context from copyright analysis and patent analysis?
The technical skillset and the analytical methods used in patent infringement and copyright infringement matters serve as useful analogs that have been tested in some of the most technically complex cases, historically. The primary differences are not so much in the analytical approaches, but the relevant factual questions that need to be answered. A skilled expert can leverage the analytical methods and approaches from these various disciplines and rely on their experience and knowledge to know what to look for and evaluate based on the questions presented for analysis.
