- within Insolvency/Bankruptcy/Re-Structuring topic(s)
The U.S. Court of Appeals for the Seventh Circuit, which hears federal appeals from Illinois, Wisconsin, and Indiana, recently issued a decision clarifying the level of specificity required to claim trade secret protection for software under federal law. In NEXT Payment Solutions, Inc. v. CLEAResult Consulting, Inc., the court explained a plaintiff cannot get to a jury just by describing software features in broad, everyday terms. To bring a viable trade secret claim under the federal Defend Trade Secrets Act, ("DTSA"), 18 U.S.C. §§ 1836 et seq., the party must be able to clearly explain what the "secret" is, not merely point to the system's visible functions or the results it produces.
According to the complaint, in 2014, CLEAResult Consulting Inc. ("CLEAResult") hired Next Payment Solutions, Inc. ("NEXT") to build a custom scheduling application called the FAST Tool. As alleged, the application included a publicly-visible interface that customers used to schedule appointments and an internal interface that CLEAResult staff used to manage appointments and customer information. Like most software, it also had behind-the-scenes elements such as rules, algorithms, and source code that were not shared with the customer.
NEXT alleged that, in 2017, CLEAResult acquired another company with its own scheduling platform called DSMTracker and CLEAResult decided to switch to that platform. Before switching, CLEAResult's developers reviewed FAST Tool's internal interface to compare features and identify ways the DSMTracker could meet CLEAResult's needs or be improved. According to the complaint, after the transition, CLEAResult used that process to copy the FAST Tool's capabilities.
NEXT sued, claiming trade secret theft under the DTSA and also unjust enrichment under Illinois law. The district court granted summary judgment on the DTSA claim in favor of CLEAResult, finding NEXT failed to identify a trade secret. NEXT appealed, but the Seventh Circuit affirmed.
The elements of a trade secret claim require the plaintiff to show: "(1) their information was a trade secret; (2) it was misappropriated; and (3) it was used in the defendant's business." The Court's ruling turned on the first requirement–i.e., did NEXT actually identify a protectable "trade secret"?
Under the DTSA, information can qualify as a trade secret if the owner took reasonable measures to maintain its confidentiality and the information derives independent economic value from not being generally known or readily ascertainable by others. Courts also require the plaintiff to describe the alleged secret with enough detail that a judge or jury can distinguish between trade secret information and ordinary, well-known ideas or common software features.
NEXT tried to meet that requirement by listing dozens of "modules" in the FAST Tool, with names like "Online Self Scheduling" and "Email & Text Messaging," and describing how each functioned. However, NEXT also acknowledged there was no evidence CLEAResult accessed the FAST Tool's source code or the underlying "engine" that made it run.
The Seventh Circuit agreed NEXT's descriptions were too vague because they only explained the software's outputs, not the hidden know-how behind them. For example, the Court found describing a module as "manag[ing] appointment inventory," "show[ing] real-time availability," or "send[ing] automated notifications based on triggers" only describes typical scheduling-system behavior. It does not identify the confidential methods by which the software provides those functionalities, such as specific algorithms, unique system architecture, specialized rules, or other behind-the-scenes design choices.
That distinction mattered because a trade secret must be not readily ascertainable. In other words, if someone can learn the trade secret "at a glance" simply by using the product or looking at the user-facing screens, that information is usually not "secret" for purposes of the DTSA.
The Seventh Circuit also rejected the argument that placing the information on a non-public, internal system satisfies the secrecy requirement. The Court found that, even if the general public cannot access the tool, customers and users who do have access can still observe what the software does. If the trade secret is based on visible functionality rather than internal processes or methods, limiting access to certain users does not automatically turn those features into trade secrets.
NEXT Payment Solutions helps explain the complexity in calling software a trade secret. To protect the secret, a company must clearly articulate what the protected secret is. Listing features and describing what the software accomplishes is not enough, especially when those features are visible to ordinary users. Typically, courts want to see identification of the non-obvious "how," not just the visible "what." Simply keeping a system behind a login or limiting it to internal use does not automatically make what users can see and understand into a trade secret.
The content of this article is intended to provide a general guide to the subject matter. Specialist advice should be sought about your specific circumstances.
