Last week, the U.S. Court of Appeals for the Seventh Circuit issued a significant decision in Next Payment Solutions, Inc. v. CLEAResult Consulting, Inc., a case that offers important lessons for executives overseeing technology development, data governance, vendor relationships, and intellectual‑property strategy.
The case centers on allegations of trade‑secret theft. While the court ultimately affirmed judgment for CLEAResult Consulting, Inc. (CLEAResult), the defendant, the opinion highlights critical strategic issues for any company that builds, buys, licenses, or relies on proprietary software systems.
Factual Background: What Happened
CLEAResult, an energy‑efficiency services provider, hired Next Payment Solutions (NEXT) in 2014 to build a customized appointment‑scheduling tool called the FAST Tool. This software included both customer‑facing and internal functionality, supported by proprietary rules, algorithms, and source code accessible only to NEXT.
In 2017, CLEAResult acquired another company that used a competing scheduling platform, the DSMTracker. CLEAResult initiated an internal effort, Project Renaissance, to refine the DSMTracker. To do this, CLEAResult staff reviewed the internal‑facing screens and functions of the FAST Tool so the new system could match its capabilities. However:
- CLEAResult never accessed FAST Tool source code, algorithms, or processing engine, and
- NEXT conceded there was no evidence CLEAResult accessed those deeper technical components of the FAST Tool, such as the underlying processing engine or rules software.
After transitioning its customers to the DSMTracker, CLEAResult terminated its relationship with NEXT. NEXT sued, alleging misappropriation of Trade Secrets under the Defend Trade Secrets Act (DTSA). NEXT claimed CLEAResult reverse‑engineered or otherwise took confidential know‑how from the FAST Tool.
During litigation, the district court repeatedly required NEXT to identify the actual trade secrets allegedly stolen. NEXT provided spreadsheets listing 34 software modules, five combinations of modules and features and functional descriptions of the modules such as “manages the inventory of appointments,” “presents real‑time availability,” or “create[s] open appointment slots, to update appointment availability. However, NEXT did not describe any underlying code, algorithms, or methodologies.
The Court’s Holdings
NEXT Failed to Identify Trade Secrets with the Required Specificity
The Seventh Circuit affirmed summary judgment against NEXT because NEXT described only what the software did—not how it did it. Identifying features such as “appointment scheduling,” “inventory management,” or “sending notifications” describes visible functionality, not protectable secrets. The court emphasized:
- Trade‑secret plaintiffs must identify concrete secrets, not broad technology areas.
- Functionality obvious to any user generally cannot qualify as a trade secret.
- Without explaining source code, algorithms, architecture, or non‑obvious implementation, a plaintiff cannot meet the DTSA’s specificity requirement.
The court analogized NEXT’s argument to claiming “someone stole your top‑secret recipe but never identifying the recipe itself.” NEXT’s descriptions consisted of generic functional outcomes, not the secret ingredients.
Key Takeaways for C‑Suite Leaders
This decision provides valuable guidance for CEOs, CTOs, CIOs, and GCs who manage technology assets, intellectual property risk, and vendor relationships.
If You Want Trade‑Secret Protection, You Must Define the Secret Precisely
Courts require specific, technical articulation of what is secret, not generic descriptions of software features.
Implication for leaders:
- Ensure your teams document algorithms, architecture, data models, and unique processes, not just high‑level functionality.
- Maintain internal policies that map functionality to underlying proprietary implementation.
- If you plan to litigate, assume you will need to identify the “secret sauce” with technical clarity.
Visible Software Functionality Is Not a Trade Secret
Any feature that a user can see or deduce from normal use is not “secret.” The court emphasized that appointment scheduling screens, customer‑data views, or automated notifications are not protectable if any user can observe them.
Implication for leaders:
- Protect the back‑end implementation, not the front‑end features.
- Understand that competitors may lawfully replicate observable functionality unless protected by contract or patent.
Contracts and Access Controls Are Critical
Because observed functionality wasn’t secret, the remaining protection for NEXT would have been contractual, yet nothing in the case created contractual liability here.
Implication for leaders:
- Use robust NDAs, license agreements, and access‑limit provisions.
- Clearly prohibit reverse engineering and define what constitutes proprietary information.
- Ensure your vendor and partner contracts state exactly what cannot be replicated.
Software Builders Should Preserve Evidence of Novelty
If your competitive advantage lies in technology, you must document what is non‑obvious and non‑public.
Implication for leaders:
- Implement an IP‑governance program that catalogs technical innovations.
- Consider using inventions logs, source‑code escrow, or architecture whitepapers.
- Without documentation, courts may find you have “no protectable secrets.”
Final Thoughts
The Seventh Circuit’s decision in Next Payment Solutions v. CLEAResult is a reminder that:
- Trade‑secret law protects implementation, not functionality.
- Businesses must articulate their proprietary technology with specificity.
- Courts expect disciplined IP management, rigorous documentation, and strategic consistency throughout litigation.
For C‑level executives, the case underscores the importance of building a corporate culture that treats proprietary technology as an asset requiring governance, documentation, and legal foresight, not just innovation.
