Software prior art is the evidence that proves you built something before someone else filed for a patent on it — and most developers have no independently verifiable record of when their code was written.
Software development moves fast. A developer writes an algorithm, builds a feature, architects a system. The code works, the product ships, the team starts the next sprint. At some point — months or years later — someone decides the underlying method is worth patenting. Or worse, a competitor files a patent on a method the developer built first.
In both cases, the question that determines the outcome is: can you independently prove when that code was written?
The United States moved to a first-inventor-to-file system under the America Invents Act (AIA) in 2013. Priority goes to the first person to file a patent application, not the first person to invent. The practical consequence for developers is that having built something first does not matter unless you can prove you built it first — and proving it requires evidence that meets a specific standard.
In Europe, the position is stricter. The European Patent Convention operates an absolute novelty requirement: any public disclosure of the invention before the filing date — a conference talk, a published paper, a public code repository, a demo at a trade show — destroys the right to patent it in any EPC member state. There is no grace period. The developer who presented their algorithm at a meetup before filing has disclosed it publicly and lost their European patent rights permanently.
The USPTO received over 600,000 utility, plant, and reissue applications in FY 2024, according to its Congressional Budget Submission.
The rejection data confirms why prior art evidence matters. A study published in the Yale Journal of Law and Technology (2015) by Carley, Hegde, and Marco, analysing 2.15 million utility patent applications filed between 1996 and 2005, found that only 11.4 per cent of applications received first-action allowance — meaning 88.6 per cent were rejected on the first examination. USPTO prosecution research confirms the pattern holds broadly: an obviousness rejection under Section 103 is the most common ground, with a lack-of-novelty rejection under Section 102 close behind.
For software developers, the prior art question cuts both ways. If you are filing a patent, you need to prove your invention is novel. If someone else files a patent on a method you built first, you need prior art evidence to challenge or invalidate their claim. In both directions, the question is the same: what existed, in what form, and when?
Software developers are, by the nature of their work, better documented than most creators. Git commits carry timestamps. Version control systems record every change. CI/CD pipelines log builds with dates. Code review platforms track who approved what and when. README files, changelogs, and release notes provide a written narrative of the development timeline.
This documentation is valuable. It is not, however, independently verifiable evidence of the kind a patent examiner, an opposition proceeding, or a court requires.
Git timestamps are generated by the committing machine and can be altered using commands available to any developer. A forced push, an interactive rebase, or a squash merge can rewrite commit history. The timestamps reflect the clock of the machine that made the commit, not an independent time source. In an adversarial proceeding, opposing counsel will challenge git history on exactly these grounds — and the challenge is technically accurate.
CI/CD build logs are maintained on the vendor's infrastructure across continuous integration platforms. The logs are attested by the vendor, not by an independent third party. If the vendor is acquired, changes its retention policy, or suffers a data loss, the logs may become unavailable. Even when available, they are records maintained by a platform the developer uses, not records produced by a party with no stake in the outcome.
Code review platforms record approvals, but the approval is tied to a specific platform account, not to an independently anchored identity or timestamp. The record exists within the platform's own ecosystem and depends on the platform's own attestation of its integrity.
None of this means these records are useless. They are corroborative evidence — supporting material that strengthens a claim when presented alongside stronger evidence. What they are not is primary evidence of the kind that carries independent weight in a patent proceeding. The distinction matters because patent disputes are decided on evidence, not on the parties' assertions about what they built and when. The AIPLA Report of the Economic Survey 2023 shows that median patent litigation costs through trial reach $3.625 million per patent when more than $25 million is at risk. At those stakes, the quality of the prior art evidence determines the outcome.
When prior art is used to challenge a patent — either in a USPTO inter partes review, an EPO opposition, or a court proceeding — the evidence must meet a specific standard.
The evidence must establish that the prior art existed before the patent's priority date. It must establish the specific content of the prior art — not just that code existed, but what the code did, what method it implemented, and what technical problem it solved. And it must be in a form that the examining body can verify independently of the party producing the evidence.
Published prior art — academic papers, granted patents, publicly archived software — meets this standard because publication creates an independent record with an independently verifiable date. Unpublished prior art — internal code, private repositories, unreleased features, proprietary algorithms — does not have an independent date unless one has been created.
The Finnegan analysis of prior art evidence at the PTAB notes that all evidence in inter partes review proceedings must satisfy the US Federal Rules of Evidence, and that establishing the date of prior art is a prerequisite for its use. The PTAB has accepted computer-generated timestamps as evidence of date — but the weight given to that timestamp depends on the independence and reliability of the system that generated the record.
In 2023, 1,203 federal trade secret cases were filed in the United States according to the Lex Machina 2024 Trade Secret Litigation Report — and in each of those cases the claimant's ability to establish what existed and when was the foundational evidential question.
For a developer whose prior art is in a private repository, the question is not whether the code exists. It is whether they can produce an independently verifiable record of what the code contained and when it existed in that form — a record that was not generated by their own systems and cannot be challenged as self-produced.
The gap between what developers have and what patent proceedings require is closed by making a record at the point of creation — not after a dispute arises.
When code is deposited, the file is hashed using SHA-256, the hash is timestamped by an accredited Trust Service Provider under RFC 3161, and the timestamped hash is anchored to the Bitcoin blockchain via OpenTimestamps. This is a single automated process — each step depends on the output of the preceding one. The result is a portable certificate recording the file name, the cryptographic fingerprint, the timestamp, and the blockchain anchor.
A free RFC 3161 timestamp from an unaccredited TSA produces a technically valid record but carries no legal presumption — the developer would have to argue for its accuracy in a proceeding. With optional eIDAS Article 41 qualification from an accredited QTSP, the timestamp carries a legal presumption of accuracy across all 27 EU member states — the court assumes accuracy unless the opposing party proves otherwise. Under UK law the certificate is treated as strong electronic evidence. Under US Federal Rule of Evidence 901, the documented, reproducible process provides a basis for admissibility.
For software prior art specifically, the practical workflow maps to how developers already work. A developer deposits a snapshot of a codebase, a specific module, a design document, or an architecture specification at a milestone — feature complete, pre-release, pre-publication, pre-filing. Each deposit produces its own certificate. Each certificate is independently verifiable without reference to the platform that generated the record. The developer's git history, commit messages, and CI logs remain valuable as corroborative evidence — but the certificate provides the independently anchored primary record that a patent examiner or tribunal requires.
The infrastructure extends beyond single deposits. Every version of every file is independently recorded, so a developer can establish not just that a method existed but how it evolved — an early sketch of an algorithm, a working prototype, a production-ready implementation, each independently dated. The result is not a single timestamp of a single file but a complete, independently anchored development history.
For a technology company whose core IP is in proprietary algorithms and software architecture, this infrastructure means every milestone in the development process is recorded at the time it happens — not reconstructed from platform logs after a dispute. The eIDAS 2.0 regulation (EU 2024/1183), which entered into force in 2024, strengthens QTSP supervision and extends the framework to new trust services including electronic archiving. The evidential infrastructure available to developers today is broader and more legally grounded than at any previous point.
The practical consequence is specific to how software IP disputes unfold.
A developer who built a feature in 2024 and deposited a snapshot at the time has a certificate that proves the code existed in that form on that date. If a competitor files a patent on the same method in 2025, the certificate establishes the foundational element of any prior art challenge — that the code existed in that specific form before the patent's priority date — independently dated, independently verifiable, and without the developer having to argue for the reliability of their own git history.
A CTO preparing a patent portfolio has a documented record of each invention's development timeline. The deposit history establishes priority dates for each component, provides evidence for the prior art search that precedes filing, and supports the invention disclosure that patent counsel requires. For applications filed under the EPC's absolute novelty requirement, the deposit record establishes what existed before any public disclosure — the critical question for European filings.
A patent attorney advising a client on whether to file has an independently anchored record of the client's development history to assess. Prior art assessment is clearer when the client can produce certificates showing what they built and when, rather than asking the attorney to rely on git logs the opposing party will challenge.
The EUIPO's 2023 Trade Secrets Litigation Trends report found that success rates for trade secret claims across the EU stand at approximately 27 per cent — reflecting in part the difficulty claimants face in proving what existed and when without an independent record made at the time. Software prior art disputes present the same evidential challenge. The code exists. The question is whether the developer can prove it existed in a specific form before the date that matters. A certificate made at the time answers that question. A git log produced after the dispute does not carry the same weight.
The gap between writing code and proving you wrote it is not a gap that better version control closes. Git history is a development tool, not an evidential infrastructure. The record that a patent examiner, an opposition tribunal, or a court requires is one that was made at the time, by a party with no stake in the outcome, in a form that can be verified independently. For developers building patentable methods, the time to make that record is at the point of creation — not at the point of dispute.
This post provides general information about the role of cryptographic evidence in software prior art disputes. It is not legal advice. For advice on a specific matter, consult a qualified lawyer or patent attorney in your jurisdiction.
Related Reading
Proving "Prior Art" at the PTAB — Finnegan
eIDAS Qualified Timestamps vs Free Timestamps: What the Difference Means for Evidence
The Evidence Your IP Insurance Policy Assumes You Already Have
James Snell is the founder of Provlyn, a platform providing cryptographic prior proof of IP ownership. provlyn.com