Under the Defend Trade Secrets Act (“DTSA”), information qualifies as a “trade secret” if (1) the owner has taken “reasonable measures” to keep it secret, and (2) the information derives independent value from the fact that it is not generally known and not readily ascertainable. See 18 U.S.C. § 1839(3); Life Spine, Inc. v. Aegis Spine, Inc., 8 F.4th 531, 540 (7th Cir. 2021). 

A common issue in trade secret litigation is whether the alleged trade secrets are described with enough specificity to support a DTSA claim. In the Fourth Circuit, for example, trade secrets must be identified with “sufficient particularity” by the plaintiff at the pleading stage, so that “a defendant [can] delineate that which he is accused of misappropriating.” Sysco Mach. Corp. v. DCS USA Corp., 143 F.4th 222, 228 (4th Cir. 2025) (“Neither the defendant nor the court should be forced into a fishing expedition to find evidence of a valid trade secret in the pleadings.”). 

More recently, in connection with customer service software for businesses, the Seventh Circuit in NEXT Payment Solutions, Inc. v. CLEAResult Consulting, Inc., No. 24-1377, __ F.4th __ (7th Cir. Jan. 13, 2026) reiterated its requirement for “a high level of specificity when a plaintiff makes a claim for misappropriation of a trade secret,” citing REXA, Inc. v. Chester, 42 F.4th 652, 663 (7th Cir. 2022). 

At the least, a plaintiff must present enough specifics for the fact finder to distinguish between information that is generally known and information that is not readily ascertainable and thus qualifies as a statutory secret. See IDX Sys. Corp. v. Epic Sys. Corp., 285 F.3d 581, 584 (7th Cir. 2002) (“[A] plaintiff must do more than just identify a kind of technology and then invite the court to hunt through the details in search of items meeting the statutory definition.” (citing Composite Marine Propellers, Inc v. Van Der Woude, 962 F.2d 1263, 1266 (7th Cir. 1992))).
      * * *
But NEXT's descriptions [of its software modules] face a fundamental problem: NEXT only ever tells us the end result of what its software does, not how it does it. See, e.g., Silvaco Data Sys. v. Intel Corp., 184 Cal. App. 4th 210, 221–22 (Cal. App. Ct. 2010) (the “finished (compiled) product” of what a software program does is not a trade secret because it is “evident to anyone running the finished program”), disapproved of on other grounds by Kwikset Corp. v. Superior Ct., 51 Cal. 4th 310, 337 (Cal. 2011). NEXT does not identify any specific algorithms, source code, or methodologies underlying the FAST Tool's functionality. Instead, NEXT defines its modules in vague and generic language that describes the software's function. This lack of detail makes it impossible to distinguish between the aspects of the FAST Tool that are generally known and ascertainable, and those which NEXT contends are secret and derive value from being kept as such. See IDX Sys., 285 F.3d at 583–84 (software developer's tender of a “a 43-page description of the methods and processes underlying and the inter-relationships among various features making up IDX's software package” left it “mysterious” what it contended were trade secrets, because it did not separate its purported secrets from the “other information that goes into any software package”).

The Court found that the plaintiff's “description uses generic functional verbiage that simply describes the process in circular terms. . . . But how the software achieves that process is left unspecified.” 

     None of the above descriptions articulate a concrete secret that derives economic value from being generally unknown and not readily ascertainable. It is not a trade secret for a software program to manage appointment inventory, schedule appointments, collect and display data, send notifications, or fill out PDFs. Anybody using the FAST Tool application and seeing these features, either on the public-facing or internal web application, would be able to ascertain that the software was acting to perform these tasks. IDX Sys., 285 F.3d at 584 (“things that any user or passer-by sees at a glance,” such as the appearance of a data-entry screen in a billing software program, are “exceedingly hard to call trade secrets”). The fact that NEXT describes what its software does in generic terms that any user can discern means that it has failed to identify any information that might qualify for protection. Id.; see also BondPro Corp. v. Siemens Power Generation, Inc., 463 F.3d 702, 710 (7th Cir. 2006) (“[A] process described in general terms … will usually be widely known and thus not worth incurring costs to try to conceal and so not a trade secret.”).
     Put another way, NEXT does exactly what we have said a trade secret plaintiff cannot do: it points to broad areas of software technology and asks us to sort out what aspects of that technology may or may not meet the statutory requirements for protection. But the onus is on NEXT to identify concrete secrets. See REXA, 42 F.4th at 663; IDX Sys., 285 F.3d at 584 (citing Composite Marine, 962 F.2d at 1266).

While source code, rules, and algorithms can constitute trade secrets, they must be described with more than generic descriptions of what the software does in a manner that anybody using it could ascertain. See Syntel Sterling Best Shores Mauritius Ltd. v. TriZetto Grp., Inc., 68 F.4th 792 (2d Cir. 2023) (plaintiff described its software trade secrets with sufficient specificity where it provided documentation identifying the underlying source code and architecture behind the claimed software trade secrets). Broad descriptions with jargon-laden terminology describing what the software does would not suffice. “Describing the software functions without disclosing the underlying methods is like saying someone stole your top secret apple pie recipe, but never identifying the secret recipe itself.” NEXT Payment Sols., Inc. v. CLEAResult Consulting, Inc., No. 1:17-cv-08829, 2020 WL 2836778, at *15 (N.D. Ill. May 31, 2020). While new and valuable software “might have distinctive characteristics resulting from that design—such as improved performance—[but] they cannot constitute trade secrets because they are not secret but are evident to anyone running the finished program”. See Silvaco, 184 Cal. App. 4th at 222. 

Thus, the Court affirmed summary judgment of no trade secret misappropriation because the plaintiff failed to come forward with evidence from which a jury could conclude that its software modules could qualify as trade secrets.