Insights by Bernstein

How can I use confidential know-how as evidence in a dispute without making it public?

Marco Barulli — Tue, 10 Nov 2026 00:00:00 GMT

Updated: 2026-11-10

Identify which confidential details are needed to address the disputed facts, then agree with your lawyer how they can be examined under appropriate safeguards. Depending on the proceedings, these may include restricted access, confidential exhibits, redacted public copies and limits on use. Arrange protection before disclosure, while allowing the other party a fair opportunity to answer the evidence.

In an IP dispute, you may need to disclose confidential know-how so that your claim or defence can be examined. WIPO warns that inadequate protection against public disclosure during proceedings can reduce or destroy the commercial value of that know-how. See its guidance on protecting trade secrets.

This is a risk of losing trade-secret protection through disclosure. It does not mean that every confidential disclosure destroys protection. The practical question is who needs to examine the information, for what purpose and under which safeguards. The available measures depend on the jurisdiction and type of proceedings.

Identify the confidential detail needed to address the dispute

Separate the fact you need to establish from the documents containing the evidence. You might need to show which formula was disclosed to a manufacturer, how a particular process operated, or whether your earlier work contains the features now in dispute. Each question may require different information.

Mark the sensitive passages, tables, code or drawings and explain why public disclosure would matter. Avoid treating an entire project archive as equally confidential when only particular information needs protection. For help defining it, see how to identify the work or know-how at issue in an IP dispute.

For example, imagine that a manufacturer needs to establish which process parameters it supplied to a former partner. The relevant process sheet may contain both the disputed settings and unrelated production know-how. Identify the parts needed for the comparison and ask your adviser how the remaining information should be handled. The selection must still leave enough context for a fair examination.

Arrange safeguards before submitting the material

Discuss confidentiality before attaching sensitive files to correspondence, filing them with a court or giving them to an expert. A document marked “confidential” does not by itself determine who may see a court file or what may be discussed in a hearing.

WIPO’s guide to confidentiality during litigation describes measures such as protective orders and restricting access to named individuals. The applicable procedure determines how protection is requested and granted. Ask your lawyer what must be in place before disclosure and how to submit the confidential material while that request is being considered.

In EU trade-secret proceedings, Article 9 of the Trade Secrets Directive provides for restrictions on access to documents and hearings and for non-confidential versions of judgments. Protection can concern alleged trade secrets while their status is being decided. National procedures implement these safeguards; an NDA or a private sharing arrangement does not replace the necessary procedural steps.

Confidential know-how can also be relevant in other kinds of dispute. For proceedings before the Unified Patent Court, Article 58 of the UPC Agreement provides for restrictions on collection, use or access to evidence to protect confidential information. This is an example for that court, rather than a rule for every patent dispute.

Distinguish protection from the public from access by the other party

Keeping information out of the public record does not necessarily mean withholding it from your opponent. The other party needs a fair opportunity to understand and challenge the evidence. WIPO identifies this balance as a central issue in protecting secrets during litigation.

For EU proceedings covered by Article 9, a restricted group accessing documents or hearings must include at least one natural person from each party and their respective lawyers or representatives. Do not assume that access can always be limited to external lawyers or an independent expert.

Ask your adviser to define who may receive the material, what they may do with it, whether copies may be made and how reports or questions containing confidential detail will be handled. An expert report may help explain technical evidence, but it should not be treated as an automatic substitute for access that the proceedings require.

Keep confidential originals and disclosure copies connected

Preserve the complete original separately from any redacted or abbreviated version. Give each version a clear reference and record what was removed. Check that redaction does not leave sensitive text, comments, formulas or attachments accessible in the disclosure copy.

In the process-sheet example, an authorised reviewer might examine the complete parameter table while a public exhibit uses an approved redacted version. Both should identify the same underlying document. A reviewer should be able to explain which version they examined without inadvertently repeating the confidential values in a public report.

Where timestamped records are used, retain the exact files and proofs for the relevant versions. Redacting a file changes it, so keep the relationship between the original and the redacted copy explicit. A technical check can take place within the agreed confidential review process. Read more about what independent verification involves.

Follow protection through the rest of the proceedings

Track the material disclosed, recipients, applicable restrictions and subsequent exchanges. Include extracts reproduced in expert reports, witness statements, presentations and hearing materials. A confidential exhibit can reveal its contents through a later document if the same care is not carried through.

Review proposed public versions with your adviser and continue following the applicable restrictions after the dispute ends. Under Article 9, confidentiality obligations can continue after proceedings, subject to specified exceptions. Agree how retained copies, ongoing access and any return or deletion requirements interact with preservation obligations.

Sources

World Intellectual Property Organization. How to protect trade secrets?. Risk of losing trade-secret value or protection through public disclosure during proceedings.. Accessed 10 November 2026
World Intellectual Property Organization. WIPO Guide to Trade Secrets and Innovation — Part V: Trade secrets in litigation. Section 6: confidentiality during proceedings, protective orders and restricted access, balanced with defence rights and public access to justice.. Accessed 10 November 2026
European Parliament and Council of the European Union. Directive (EU) 2016/943 on trade secrets. Article 9: confidentiality of alleged trade secrets, restricted access, non-confidential judgments, fair-trial safeguards and duration of obligations. Applies to proceedings covered by the directive.. Accessed 10 November 2026
European Patent Office. Agreement on a Unified Patent Court — Article 58: Protection of confidential information. Example for proceedings before the UPC: restrictions on collection, use or access to evidence to protect confidential information.. Accessed 10 November 2026

How can I show independent development when accused of copying or misuse?

Marco Barulli — Tue, 10 Nov 2026 00:00:00 GMT

Updated: 2026-11-10

Connect the disputed features to records showing how your team developed them: drafts, experiments, decisions and the sources used. Establish when those features emerged, who contributed, and whether anyone had access to the other party’s material. Corroborate the history where possible and address gaps honestly. An early project start date or a timestamp alone does not establish independent development.

Someone alleges that your software, design or process draws on their work or confidential information. You believe your team developed it independently. The useful question is what your records can show about how you reached the disputed result.

A clear account connects particular features to the people, sources and decisions behind them. This answer focuses on copyright, unregistered designs and trade secrets. The legal significance of independent development, and who must prove which facts, depend on the right and jurisdiction. Your adviser should assess those questions against the actual allegation.

Start with the features you are accused of copying

Identify the code, design elements or information the other party says you took. If the allegation is broad or unclear, ask your adviser to seek enough detail for a meaningful response. See identifying the material at issue in an IP dispute.

Then locate those features in your own records. A project may have begun years before the dispute while the contested feature appeared only recently. An early proposal for the whole product will not necessarily explain the origin of that feature.

For each disputed item, identify its earliest documented appearance, the contributor involved and the records showing its subsequent development. Keep the relevant versions available for comparison.

Explain the path from the initial problem to the result

Use the records made during the work to explain how your team arrived at its solution. Drafts, laboratory notes, prototypes, issue discussions and design reviews can connect a finished feature to the decisions that produced it. Failed experiments and discarded approaches may help explain why the team chose a particular configuration.

WIPO’s trade-secret litigation guide identifies records of research and development progress as useful evidence when independent discovery is asserted. The point is to substantiate the route by which the information was obtained.

For example, imagine your company is accused of using a competitor’s confidential coating process after hiring one of its engineers. Trial records from before the engineer joined might show your team testing and selecting the disputed combination of temperatures and timings. Link those results to the version actually used in production. A general budget approval for coating research would establish much less about the origin of that combination.

Continue the account through later changes. Earlier independent work may explain the initial process without explaining a subsequent improvement. Identify what changed, who proposed it and the evidence of how that person reached the proposal.

Account for the sources your team used

Identify the public papers, standards, supplier specifications, licensed components and earlier internal work that informed the disputed features. Connect each source to the relevant decision or implementation, including when your team obtained or used it.

A source found after the allegation may show that information was publicly available. It does not establish that your team actually relied on that source during development. Distinguish those two propositions in your account.

Similarities may have a common origin. In a hypothetical software dispute, matching code or even a shared error could come from a library both teams used. Dependency records, licence files and earlier versions may help test that explanation. Identify the matching material precisely; the presence of one shared library does not explain every similarity in a program.

The US Ninth Circuit’s copyright instructions discuss independent creation and a prior common source as alternatives to copying. This is a US copyright example. A technical comparison should explain significant similarities and differences and their possible origins, while the legal assessment addresses which material is protected.

If your team studied or tested another product, describe that activity accurately. Keep acquisition records, test notes and resulting findings. The EU Trade Secrets Directive, Article 3, recognises independent creation and certain forms of reverse engineering as lawful acquisition, subject to its conditions, including the absence of a legally valid duty limiting that acquisition. Do not describe all work as independently invented if some of it came from such examination or from licensed material.

Address any access to the other party’s material

Review whether relevant team members encountered the claimant’s work or information through earlier employment, collaboration, demonstrations, shared files or public releases. Identify what they could access and when. Access does not itself establish use, but an explanation that ignores known contact leaves an important question unanswered.

Compare that timeline with the development of each disputed feature. Where decisions preceded the contact, identify the supporting records. Where they followed it, examine the sources and discussions behind them rather than assuming the earlier project start resolves the issue.

If you relied on separate teams or access restrictions, retain evidence of how those arrangements operated: team assignments, permissions, instructions and communications. A policy labelled “independent development” does not itself show that the people doing the work were separated from the information.

Also examine the permissions that applied. You may have been entitled to use material under a licence or collaboration agreement. That is a different explanation from independent development. Under Article 4 of the EU Trade Secrets Directive, lawful receipt does not necessarily permit later use or disclosure in breach of applicable duties.

Corroborate the chronology and make gaps visible

Connect internal records to dated exchanges with suppliers, external test reports, delivered prototypes or other records outside the immediate development team. Explain what each supports: an external test report may establish the performance of a sample without revealing the process used to make it.

Previously timestamped versions can support when particular files existed. They are most useful here when the files contain the disputed features or explain their development. Read more about what a digital timestamp establishes.

If you prepare a chronology now, label it as a later summary and link each statement to its source. Record recollections separately from contemporary documents. Preserve the underlying records, including material that complicates your account; do not rewrite earlier notes to make the history appear more complete.

Give your adviser a feature-by-feature account of the development, the supporting evidence, relevant exposure to the claimant’s material and unresolved gaps. This lets them test your explanation and identify where further investigation is needed.

Independent development is particularly relevant to the rights discussed here, but it is not a universal answer to an IP allegation. The European Commission’s design guidance distinguishes unregistered protection against copying from registered design protection. Do not assume that showing an independent origin resolves a registered-design or patent claim in the same way.

Sources

United States Court of Appeals for the Ninth Circuit. Model Civil Jury Instructions — 17.17 Copying: Access and Substantial Similarity. US copyright example: circumstantial evidence of copying, independent creation and prior common sources; commentary distinguishes copying from unlawful appropriation.. Accessed 10 November 2026
World Intellectual Property Organization. WIPO Guide to Trade Secrets and Innovation — Part V: Trade secrets in litigation. Sections 4.2 and 5.2: circumstantial evidence of misappropriation and evidence supporting independent discovery or reverse engineering.. Accessed 10 November 2026
European Parliament and Council of the European Union. Directive (EU) 2016/943 on trade secrets. Articles 3 and 4: lawful acquisition, including independent creation and qualifying reverse engineering, and unlawful acquisition, use or disclosure.. Accessed 10 November 2026
European Commission. Protection of designs. Overview of EU design protection, including unregistered protection against copying.. Accessed 10 November 2026

What evidence helps establish the financial harm caused by copying or misuse?

Marco Barulli — Tue, 10 Nov 2026 00:00:00 GMT

Updated: 2026-11-10

Keep records showing what changed financially, when it changed and why you link it to the alleged copying or misuse. Sales and cost data, customer correspondence, licensing records and development accounts can support the assessment. Compare actual results with a supported estimate of what would otherwise have happened, and distinguish documented figures from assumptions and other possible causes.

In an IP dispute, evidence that someone copied your work or misused confidential information does not itself establish the amount of financial harm. You need to explain the economic effect and connect it to the conduct concerned. The value of the asset, the amount spent developing it and the loss caused by misuse answer different questions.

The available financial remedies depend on the right, jurisdiction and circumstances. Start with your lawyer and, where appropriate, a financial expert to identify the assessment needed. The practical task is to assemble records that let them examine both the claimed loss and alternative explanations.

Identify the financial effect you are claiming

Describe the affected product, service, licence or opportunity and the relevant period. A broad statement that “the business lost value” gives an expert little to test. A claim that particular customers switched suppliers, or that you reduced prices on a defined product line, points to records that can be examined.

Useful starting points include:

Claimed effect	Records that may help assess it
Lost sales or customers	Orders, cancellations, customer correspondence, sales history and tender results
Lower prices or margins	Quotes, discounts, invoices, price changes and product-level cost records
Lost licensing income	Signed licences, royalty statements, negotiations and evidence of the use concerned
Costs of investigating and addressing the incident	Expert invoices, staff time records and descriptions of the work performed
A development advantage gained by the other party	Project accounts, trial history, development milestones and evidence of the work allegedly avoided

These are evidence categories, not a list of amounts automatically recoverable. Keep response costs and legal expenses separately identified so that your adviser can assess their treatment.

Connect the change to the alleged conduct

Build a timeline linking the relevant copying, disclosure or use to the financial events. Customer messages explaining a switch, a competing offer referring to the disputed features, or a cancellation shortly after a particular launch may help investigate the connection. Timing alone leaves other explanations open.

In a hypothetical dispute, a design studio says copied furniture caused a decline in orders. Its records also show delivery delays during the same period. The assessment needs to distinguish customers attracted by the competing design from those who left because the studio could not deliver. Keep correspondence and operational records supporting either explanation.

WIPO’s discussion of monetary remedies in trade-secret disputes emphasises the causal connection between the misconduct and the loss or benefit claimed. A fall in revenue across the whole business needs more explanation than a set of identified transactions connected to the dispute.

Support what would probably have happened otherwise

Assessing lost profits requires an estimate of the business you would have done without the alleged conduct. Give the expert historical sales, seasonality, repeat-order patterns, capacity constraints and forecasts prepared before the dispute. Explain changes in market demand, costs or competition that would have affected results anyway.

For example, suppose the studio claims it lost an order for 100 chairs priced at €200 each. The €20,000 order value is revenue, not automatically lost profit. The assessment must consider the costs of fulfilling the order, whether the studio could have supplied it, and any replacement business obtained. The appropriate calculation depends on the facts and applicable law.

Use the forecasts and budgets that actually existed at the relevant time. If you prepare a new estimate, label it as such and show how it was constructed. For a new product without a sales history, distinguish firm orders from enquiries, proposed contracts and management expectations.

Use timestamped records to establish the earlier commercial position

A forecast preserved and timestamped before the alleged misuse can help answer a specific challenge: was this expectation documented at the time, or constructed later to support the claim? The same applies to a pricing proposal, development budget or licensing offer. Link each record to the product or know-how concerned and explain how it contributes to the financial assessment.

For the furniture studio, a timestamped sales forecast and cost model from before the competing launch would give the expert a dated starting point for examining expected orders and margins. Customer correspondence and actual trading results would then help assess whether those expectations were realistic and why results differed.

Different records support different parts of the assessment. An earlier licensing offer documents the terms proposed at that stage; preserve the negotiation and any acceptance alongside it. Successive trial reports and project accounts can document the development history used to assess a claimed saving in research time or cost. In each case, the timestamp helps establish which version existed by a particular date, while the contents and supporting records explain its financial relevance.

If you only begin timestamping after the dispute arises, retain the earlier source records and distinguish their dates from the later timestamp. That later record provides a reference for the material assembled at that point. Read more about what a digital timestamp establishes.

Keep other measures separate from your own lost profits

Your loss may not be the only relevant financial measure. In the EU, Article 13 of the IP Enforcement Directive and Article 14 of the Trade Secrets Directive address factors including lost profits and unfair profits made by the infringer. They also provide for royalty-based lump sums in appropriate cases. National law and the facts determine which approach applies.

For a royalty-based assessment, keep licences and negotiations that can be meaningfully compared with the use at issue. Identify differences in territory, duration, exclusivity, permitted uses and any services included in the price. A fee for a broad commercial package may not be comparable to use of one design or one part of a process.

For trade secrets, development records may help assess a claimed benefit from avoiding research or reaching the market sooner. WIPO discusses development costs as a possible measure of unjust enrichment in particular circumstances. Your entire R&D budget is not automatically the other party’s saving: identify the work connected to the information used and the basis for estimating what was avoided.

Likewise, the other party’s total sales are not automatically profits attributable to your IP. Separate established figures from estimates, identify missing information and let your adviser assess how it might be obtained. Keep alternative calculations distinct and flag overlaps so the same effect is not counted twice.

Make the calculation traceable

Retain the underlying accounting exports, invoices, contracts and correspondence, together with the calculation files. Record the period, currency, product scope, data sources and assumptions. Explain allocations where a cost or revenue figure covers several products or activities.

Preserve and timestamp significant versions of the financial analysis together with the source extracts and assumptions used. This gives your adviser or expert an identifiable, dated package to review and lets later revisions be compared with it. Explain material changes, such as replacing an estimated cost with an invoice or correcting the affected sales period. Show where an estimate depends on uncertain facts and how different reasonable assumptions affect it. This helps an adviser or expert assess the strength of the claim and the information still needed, including during settlement discussions.

Financial records may themselves reveal confidential margins, prices or customer information. Agree the disclosure arrangements before circulating them; see how to use confidential know-how as evidence in a dispute without making it public.

Sources

World Intellectual Property Organization. WIPO Guide to Trade Secrets and Innovation — Part V: Trade secrets in litigation. Monetary remedies: causal connection, losses, unjust enrichment, development costs and avoiding duplicate compensation.. Accessed 10 November 2026
European Parliament and Council of the European Union. Directive 2004/48/EC on the enforcement of intellectual property rights. Article 13: damages, including economic consequences, unfair profits and, in appropriate cases, royalty-based alternatives.. Accessed 10 November 2026
European Parliament and Council of the European Union. Directive (EU) 2016/943 on trade secrets. Article 14: damages for unlawful acquisition, use or disclosure, relevant factors and royalty-based lump sums in appropriate cases.. Accessed 10 November 2026

What should change in how I handle evidence once an IP dispute becomes likely?

Marco Barulli — Tue, 10 Nov 2026 00:00:00 GMT

Updated: 2026-11-10

Move from routine recordkeeping to a coordinated preservation plan. Identify relevant records and the people and systems holding them, suspend deletion where needed, and agree how material will be collected and handled. Preserve evidence that may weaken your position as well as support it. Involve your lawyer and technical specialists early, before routine changes or an improvised investigation remove useful information.

During normal work, teams replace drafts, delete old messages, recycle devices and close former employees’ accounts. Once a dispute becomes likely, those same actions can remove information needed to understand what happened. This matters whether you intend to bring a claim or are responding to one.

Begin planning before a lawsuit is filed: records may disappear while the parties are still assessing their positions or discussing a resolution. The practical steps below help preserve material for later examination. Legal duties to retain or disclose it, the point at which those duties arise and the consequences of loss vary by jurisdiction. Ask your adviser which rules apply, including where the people and records are in different countries.

Agree what needs preserving and who will coordinate it

Identify the disputed work or information, relevant events and likely time period with your adviser. Then locate the people, systems and physical items that may hold evidence. For an IP dispute, these might include development repositories, shared workspaces, disclosure emails, access logs, laboratory notebooks, prototypes and retained product samples.

Assign someone to coordinate the practical work with legal advisers, IT and the relevant project team. Keep a record of the instructions, actions taken and unresolved gaps. The scope should follow the issues in the dispute and be reviewed as they become clearer.

For help defining the subject matter, see how to identify the work or know-how at issue in an IP dispute.

Interrupt routine deletion where it affects relevant records

Check automatic message deletion, log retention, backup rotation, account closure and device replacement. Tell the people responsible which records must be retained, and confirm that the necessary changes have actually been made. Include relevant service providers and others holding material on your behalf.

Retain relevant material even when it weakens your account. Your adviser needs the complete picture to assess the dispute, including conflicting versions and correspondence. Agree a targeted retention plan covering the relevant records and time periods, rather than stopping all deletion indefinitely. Whether particular material must later be disclosed, and whether legal privilege or other protections apply, are separate questions for your lawyer.

Consider a hypothetical dispute about a former collaborator’s use of a process. Your final process sheet survives, but messages explaining which version was shared expire after 30 days. A departing project manager’s laptop is also due to be reassigned. Copying the process sheet alone would leave both sources of context at risk. The immediate task is to coordinate preservation before those routine actions proceed.

Agree a collection method before investigating

Ask IT or a digital-forensics specialist how to preserve the relevant systems before staff start opening files, installing recovery tools or searching devices themselves. Prioritise information that changes quickly or may soon become unavailable. Decide what needs specialist acquisition and what can be collected through a documented export.

Include timestamping in the collection plan where useful. Once the files have been collected, timestamp the preserved set together with the collection report identifying its sources, the method used and the person responsible. This creates a dated reference for the material collected. Keep the collection time recorded separately from the time the timestamp was obtained.

Where there is an active leak, coordinate containment and preservation. Necessary security measures may change the system; record what was done and why. Avoid treating either evidence collection or continued exposure as something to leave unmanaged while the other is addressed.

NIST’s guidance on forensic collection emphasises planning, the volatility of data and documenting acquisition. It provides technical principles for specialists, rather than a universal procedure for collecting evidence in an IP case.

Retain usable originals and document handling

Keep original-format files, relevant metadata and the context needed to interpret them. An email export with its attachments and headers retains information that a pasted quotation may omit. A repository may contain relevant history beyond the latest source-code download.

Agree the preservation format with the person responsible for collection. A PDF or screenshot may be useful for reading, while leaving out information needed to examine the source record. If you create a redacted or annotated copy, retain the unaltered material and identify the copy clearly.

Store preserved material securely, limit access and use identified working copies for review. Record who collected each item, its source, the date, the method and subsequent handling or transfers. Specialists can document integrity checks as part of that process. This handling history is commonly called the chain of custody; NIST’s collection guidance explains the underlying practices.

Keep any timestamp certificates and verification data alongside the exact files they cover. These allow a reviewer to check whether a later copy matches the timestamped material. Read more about what a digital timestamp establishes and what independent verification means.

Keep new explanations, annotations and comparisons separate from the preserved records. If something is already missing or has changed, document the gap and tell your adviser so that possible recovery or alternative sources can be assessed.

Coordinate contact and disclosure with your adviser

Before sending a demand letter or asking the other side to return or delete material, discuss the evidence implications. In trade-secret disputes, WIPO warns that alerting the alleged wrongdoer may lead to concealment or destruction and affect possible preservation measures. See its guidance on collecting evidence for proceedings.

In the EU, Article 7 of the IP Enforcement Directive provides for court-ordered measures to preserve relevant evidence, potentially before proceedings on the merits and, in specified circumstances, without first hearing the other party. These measures require supporting evidence and are subject to safeguards. They are distinct from your own retention arrangements; the directive does not establish a general EU-wide duty to freeze records whenever a dispute seems possible. Your adviser can assess the available national procedure.

Collection also needs to respect applicable privacy, employment and access rules. Having access credentials does not by itself settle whether you may search a personal account or retrieve a former colleague’s files. Agree the lawful route and scope with your adviser.

Preserving material does not mean sending it all to the opposing party. Keep confidential information controlled while your lawyer assesses what must be disclosed, in what form and with which protections. For EU trade-secret proceedings, Article 9 of the Trade Secrets Directive provides for measures such as restricted access to documents and hearings and non-confidential versions of decisions, while protecting the parties’ right to a fair trial.

Review the preservation arrangements as the dispute develops, and obtain advice before resuming deletion of the affected records.

Sources

European Parliament and Council of the European Union. Directive 2004/48/EC on the enforcement of intellectual property rights. Article 7: court-ordered preservation of evidence, including before proceedings on the merits, subject to conditions and safeguards. Not a general EU-wide pre-litigation retention duty.. Accessed 10 November 2026
European Parliament and Council of the European Union. Directive (EU) 2016/943 on trade secrets. Article 9: protection of confidential information during trade-secret proceedings, including restricted access and non-confidential decisions.. Accessed 10 November 2026
National Institute of Standards and Technology. SP 800-86 — Guide to Integrating Forensic Techniques into Incident Response. Section 3.1: planning collection, prioritising data sources, documenting handling and preserving integrity. Technical guidance, not rules of admissibility.. Accessed 10 November 2026
World Intellectual Property Organization. WIPO Guide to Trade Secrets and Innovation — Part V: Trade secrets in litigation. Sections 2.4 and 4.3: timing of evidence collection, risks of alerting the other party and compliance with applicable law.. Accessed 10 November 2026

How do I identify exactly which parts of my work or know-how are at issue in an IP dispute?

Marco Barulli — Tue, 10 Nov 2026 00:00:00 GMT

Updated: 2026-11-10

Describe each disputed item precisely enough for someone unfamiliar with the project to locate it and understand what you claim has been copied or misused. Identify the relevant version, the features or information concerned, and the evidence supporting your account. Separate the material you claim is protected from public information and third-party contributions, and record what remains uncertain.

“They copied our software” or “they used our know-how” describes a concern, but leaves important questions unanswered. Which code or information? Which version? What do you say the other party did with it?

Start with a description that your lawyer, a technical expert and ultimately the other party can examine. The aim is to make the subject of the disagreement clear enough to test. The legal requirements depend on the right and country concerned; the examples below focus on copyright, unregistered designs and trade secrets.

Identify the material and the relevant version

Give each disputed item a short reference and locate it within the underlying records. For software, that might mean particular files and functions in a specified release. For a design, identify the drawings or photographs and the appearance they show. For know-how, specify the process, settings, formula or combination of information concerned.

Use the version relevant to the alleged events. If you shared release 2 with a contractor, do not silently substitute release 5 when describing what the contractor received. Explain subsequent changes separately.

A whole work or a combination of elements may be at issue. Precision does not require reducing everything to isolated fragments. It requires explaining whether you are relying on the whole, particular parts, their combination, or more than one of these.

Explain what you claim is protected

The same product can contain several kinds of material, with different grounds for protection. Separate them in your description so that each can be assessed on its own terms.

For copyright, identify the expression concerned: for example, particular source code, text, drawings or images. Explain which material you say has been reproduced. A shared business idea or similar functionality does not, by itself, identify copied expression. WIPO’s copyright guidance explains the distinction between expression and underlying ideas or methods.

For an unregistered design, identify the appearance concerned and the features or combination you rely on. Include views that let a reviewer see those features in context. In the EU case Karen Millen, the Court distinguished indicating what gives a design its individual character from having to prove individual character to benefit from the validity presumption. The defendant could still challenge validity. The practical lesson is to identify the claimed features clearly without assuming that every aspect of validity must always be proved afresh. See the Court’s explanatory summary; this is an EU design example, not a rule for all unregistered IP.

For trade secrets, identify the actual information claimed to be secret, rather than a broad category such as “manufacturing expertise”. Explain the boundaries of that information and why you say it qualified for protection at the relevant time. WIPO treats identifying the secret, establishing its protected status and proving misappropriation as separate tasks in its litigation guidance.

Distinguish your claim from the surrounding material

Mark public information, third-party material and elements you are not claiming as your own. Where you rely on a particular combination, explain the combination rather than implying that you own each ingredient separately.

Consider a hypothetical dispute about a coating process. “Our coating technology” is too broad to show what is contested. A more useful description might identify the sequence of operations and parameter ranges in a particular process sheet, while acknowledging that the equipment and a published base formulation are already known. Whether that combination qualifies for protection remains a separate assessment.

Also distinguish ownership from identification. Naming a code module precisely does not establish that your company owns its copyright. Link to the relevant contribution records, agreements or other basis for your entitlement; see evidence of authorship and ownership.

Connect each item to the allegation and its supporting evidence

Prepare a short working list for your adviser. For each item, record:

The material: its reference, version and exact location in the source records.
The claimed protection: what you say is protected and the basis for that position.
The alleged conduct: what you say the other party copied, obtained, disclosed or used, and when.
The evidence: the documents, samples or observations supporting each statement, including evidence pointing the other way.
The gaps: what you cannot yet establish or would need further evidence to assess.

In the coating example, a contractor’s receipt of the process sheet and a competitor’s later launch are two separate observations. They do not, without more, establish that the competitor used the specified process. If you have not seen its production records, state that limitation. Do not fill the gap by describing suspected use as a known fact.

Existing dated records can help identify which version was available at the relevant time. A timestamp does not determine which parts are legally protected or prove that the other party used them. See what a digital timestamp establishes.

Keep the description traceable and confidential

Date the working description and link it to the existing evidence. A summary prepared after a dispute begins can explain earlier records, but should not be presented as a document created at the time of the events. If your understanding changes, retain the earlier description and explain the correction.

Keep confidential detail in a controlled document for your advisers. Identifying a secret for legal assessment does not require publishing it. Before including it in correspondence or court filings, agree how it will be disclosed and protected. WIPO’s guidance on confidentiality in proceedings explains why this needs attention: the secret must be identified while the other party must be able to answer the claim.

If you are responding to an allegation, use the same structure to identify what is actually being claimed against you. Flag unclear items and ask your adviser to seek clarification before attempting a detailed comparison.

Sources

World Intellectual Property Organization. What can I protect with a copyright?. Copyright protects expression rather than underlying ideas, procedures or methods of operation.. Accessed 10 November 2026
World Intellectual Property Organization. WIPO Guide to Trade Secrets and Innovation — Part V: Trade secrets in litigation. Section 4.2: identifying the claimed secret, establishing protection and proving misappropriation are distinct tasks. Section 6: confidentiality during proceedings.. Accessed 10 November 2026
Court of Justice of the European Union. Karen Millen Fashions Ltd v Dunnes Stores, C-345/13 — Court press release. Official explanatory summary of the judgment of 19 June 2014: identifying the features giving an unregistered design individual character and the presumption of validity. The summary is not the binding judgment.. Accessed 10 November 2026

How can a company document its rights to work created by employees and contractors?

Marco Barulli — Mon, 09 Nov 2026 00:00:00 GMT

Updated: 2026-11-09

Document who created the work, which duties or contract covered it, and whether the company owns the rights or has permission to use it. Resolve missing transfers or unclear terms before relying on ownership. Preserve signed agreements alongside successive versions and delivery records, timestamping them as the work progresses to reinforce their chronology.

Link the work to the agreement that covers it

For each project, keep a short list of contributors and deliverables. Identify the person who wrote the code, prepared the drawings or developed the invention, the company they worked for, and the period of their involvement. Link each contribution to the relevant files and to the employment terms or contractor agreement in force at the time.

Use the company’s legal name, particularly where several companies in a group are involved. If one company employs the creator but another is intended to own or use the results, document the transfer or permission between them.

Record whether the company claims ownership or relies on a licence, and identify the contract clause or legal rule supporting that position. Mark unresolved points explicitly rather than treating every delivered file as company-owned.

For employees, preserve evidence of their duties

Keep the signed employment terms and amendments, the job description, project assignments and dated records of the work performed. These help establish whether the work fell within the employee’s duties and which terms applied when it was created.

Ownership rules differ by country and type of IP. Rights may belong to the employer under law, require a transfer from the employee, or remain with the employee in particular circumstances. Even within Europe, employee ownership rules are not fully harmonised, as the European IP Helpdesk explains.

For an invention, keep the employee’s written description of what they developed and the instructions defining their research or development task. Check whether local law requires notification to the employer, a claim to the invention, an assignment or compensation, and preserve evidence of any required steps.

For example, an engineer’s project brief and development notes can connect a new mechanism to their assigned duties. A job title or a clause saying “all IP belongs to the company” may not establish that connection or satisfy the required legal steps.

For contractors, document exactly what rights the company receives

Keep the signed contract and statement of work, including amendments. Check that they identify the deliverables and specify whether rights are transferred to the company or licensed for particular uses. Record any conditions, such as a transfer taking effect on payment, and retain evidence that those conditions were met.

Do not assume payment transfers ownership. WIPO’s guidance on expanding a team recommends making clear what the company owns and what the contractor keeps. If the company receives a licence, specify the permitted uses, duration and territory, including whether it can modify the work or allow customers to use it.

Where ownership is transferred, check the formalities for the relevant rights and countries, such as required signatures or registration of the transfer. The European IP Helpdesk’s assignment guidance explains why one contract format cannot be assumed sufficient everywhere.

If an agency or contractor uses other people to produce the work, ask for copies of the relevant assignments or licences, or written confirmation identifying the contributions covered and the rights it obtained. Check that those rights allow the transfer or licence promised to your company.

Separate new work from material brought into the project

Ask contributors to identify existing code, templates, images, designs or methods they include. Keep a list of those items, their owners and the permissions covering the company’s intended use. Preserve the applicable licence terms and any restrictions on modification, distribution or sublicensing.

For example, a developer may create a new application using a library they already owned and third-party open-source components. The company’s documents should distinguish rights in the new code from permission to use the existing components. Paying for the application does not explain those different rights. For confidential know-how, WIPO’s guidance on collaborative innovation similarly distinguishes what each party brings from what they develop together, and recommends agreeing how both may be used.

Keep the documents with the delivered versions

At each handover, preserve the delivered files, contributor names, acceptance messages and the agreements covering that delivery. Where payment triggers a rights transfer, link the payment record too. Keep signed originals and, for electronically signed documents, the accompanying signature-validation records.

Preserving and timestamping successive deliveries and agreements builds a dated history of what the company received and which terms were documented at each stage. Different timestamping methods can support this history; see what a digital timestamp establishes. A timestamp supports when a document existed, but cannot supply a missing signature or transfer rights that the agreement does not grant.

Before a contributor leaves, check for missing signatures, unidentified third-party material and deliverables absent from the contract. Arrange any necessary clarification, licence or assignment with the appropriate parties, using the actual signing date. Keep unresolved gaps visible for legal review, and store the completed records where the company can retrieve them after the person leaves.

Sources

World Intellectual Property Organization. IP for Business Moments: Grow. Expanding the team: employee agreements, contractor ownership and rights retained by contributors.. Accessed 9 November 2026
European Commission, European IP Helpdesk. Europe — Frequently Asked Questions. Employee ownership rules vary nationally; assignment requirements depend on the jurisdiction and right.. Accessed 9 November 2026
World Intellectual Property Organization. WIPO Guide to Trade Secrets and Innovation. Part VI: distinguishing existing material from new collaborative results and agreeing access and use.. Accessed 9 November 2026

What evidence should I collect to document the commercial use of a trademark?

Marco Barulli — Mon, 09 Nov 2026 00:00:00 GMT

Updated: 2026-11-09

Keep examples showing how customers encountered the trademark, together with records of the goods sold or services supplied, dates, markets and sales volumes. Link packaging, labels, photographs and advertising to invoices, orders or delivery records. Preserve and timestamp these materials regularly to reinforce the dated history of use, rather than reconstructing it when evidence is requested.

Show the mark as customers encountered it

Keep examples showing how you use the trademark to market or supply particular goods or services. For goods, these might be photographs of products, labels, packaging or shop displays. For services, keep brochures, advertisements, signage or customer documents that show the mark and identify the service offered or supplied.

Preserve the full context: a close-up of a logo alone may not identify the product, service or seller. Keep the wording and design actually used, including earlier versions when branding changes. Separate proposed packaging and campaign mock-ups from material that reached customers.

The USPTO’s specimen guidance illustrates this distinction for US filings: specimens must show actual use, and acceptable examples differ between goods and services. A document useful in your wider evidence file may not qualify as a filing specimen on its own.

Connect the mark to sales and services

Preserve invoices, orders, delivery records and records of services performed. Keep product codes and descriptions that let someone match a transaction to the branded item. If an invoice names only a company or product code, retain a catalogue or product list explaining which mark appeared on the goods sold.

For example, a coffee producer could keep photographs of its branded bags, the product list linking each bag to a stock code, invoices using those codes, and delivery records identifying the destinations. The photographs show the branding; the other documents help establish which products were sold, when and where.

Record quantities or sales values as well as individual transactions. Keep the invoices, orders or accounting records supporting each sales summary, and separate figures by mark, product or service and market where possible. Company-wide turnover may say little about use of a particular trademark. EUIPO’s guidance on commercial documents explains how invoices can help show the timing, frequency and geographical extent of sales.

Keep the dates, markets and businesses clear

For each group of records, note the period covered, the countries or regions concerned, the goods or services, and the business making the sales. Distinguish a campaign’s publication date from the date you saved a copy. Keep advertising placement records or distribution reports alongside the advertisement itself.

Where a distributor, franchisee or licensee uses the mark, identify that business and retain the relevant authorisation, sales reports and any records of quality control. The conditions under which another business’s use counts for the owner vary. For example, Canadian guidance on evidence of use addresses both licensed use and the owner’s control over the goods or services.

Preserve a dated sequence as business continues

Collect records at regular intervals and when products, packaging, services or markets change. Include the earliest available sales evidence and later examples showing continued activity. A practical routine might combine quarterly collections with extra records for launches and major campaigns; this is a record-keeping suggestion, not a legal minimum.

Timestamp the collected files as you preserve them, keeping the originals, certificates and verification data together. For timestamping methods and their limits, see what a digital timestamp establishes.

For the coffee producer, successive timestamped collections could preserve each packaging version alongside the corresponding sales and delivery records. This makes later changes traceable. A timestamp supports when the files existed; the photographs and transaction records provide the evidence of commercial activity. Timestamping an old invoice today does not independently establish that its stated transaction date is correct.

Select evidence for the relevant requirement

Organise the collection by trademark, goods or services, market and period so you can retrieve the relevant records. Keep confidential originals securely; prepare redacted copies separately when disclosure is necessary.

Before submitting evidence, check the country, procedure, period and goods or services it must cover. Applying for registration, keeping a registration in force and defending it against a challenge for non-use may require different documents or declarations. WIPO’s overview explains that protection and application requirements vary between countries. A well-maintained collection gives you material to select from; its legal sufficiency depends on the particular requirement.

Sources

World Intellectual Property Organization. How to Protect a Trademark?. Trademark protection and application requirements differ between countries; some offices require evidence of use.. Accessed 9 November 2026
European Union Intellectual Property Office. Trade mark guidelines: Invoices and other commercial documents. Invoices as evidence of sales, dates, frequency and geographical extent, considered with other records.. Accessed 9 November 2026
United States Patent and Trademark Office. Specimens. US-specific examples of actual trademark use for goods and services, and limits on acceptable specimens.. Accessed 9 November 2026
Canadian Intellectual Property Office. Guide to preparing an affidavit or a statutory declaration in section 45 proceedings. Canadian examples connecting the mark, goods or services, transactions, relevant dates and licensed use.. Accessed 9 November 2026

What evidence can help establish authorship and ownership beyond showing that a file existed?

Marco Barulli — Mon, 09 Nov 2026 00:00:00 GMT

Updated: 2026-11-09

Preserve and timestamp drafts, correspondence and agreements as the work develops. Record who created or changed each significant part, and keep the contracts explaining who holds the rights. Together, the successive versions, contributors’ messages and signed agreements help show how the work was created, who contributed and how ownership was established or transferred.

Build a dated record of how the work developed

A finished file rarely shows who made particular changes or why. Earlier versions and the messages discussing them can help explain those decisions.

Keep sketches, working drafts, source files, laboratory notes, version histories and test results. Link each version to the emails, meeting notes or feedback explaining what changed and why.

A verifiable digital timestamp helps establish that a particular version of a file existed by a given time. Methods include Bitcoin anchoring and timestamps issued by a trusted authority. Their time precision, verification procedures and legal effects differ; see what a digital timestamp establishes.

Timestamp these records as the project progresses. The timestamps support when each version existed; the drafts, messages and agreements help explain who created it and who holds the rights. A timestamp does not verify whether statements inside a document are true.

Suppose a company commissions an illustration from a freelancer. They preserve and timestamp the initial sketches, revised drafts, emails requesting and explaining changes, the signed agreement transferring rights and the final illustration as each becomes available. The emails identify the versions being discussed, and the agreement identifies the commissioned work.

The sequence is useful because the drafts show the changes, the emails connect them to the freelancer, and the agreement documents the transfer of rights. Timestamps support when each of these records existed. Timestamping the whole collection only at the end would establish its existence by that later date, rather than establish the earlier dates of individual drafts or exchanges.

Preserve original files and messages where possible. Export the version history with its dates, usernames and change descriptions, rather than keeping only a screenshot of the latest entry.

Keep the exact certified files, their certificates and the data needed for verification alongside the supporting records.

Connect contributions to identifiable people

For each significant part of the work, record the contributor’s name, what they created or changed, and the files or correspondence that support that description. For example, distinguish the person who drew the initial illustration from the person who revised its colours or prepared the final print files.

A username in a version history or an author name in a file’s properties can help identify a contributor, but may need explanation. Several people may use the same login, and someone may upload a colleague’s work. Where that happens, add a note identifying who actually did the work and link it to supporting material, such as the email in which they supplied the draft.

At a project milestone, send each contributor the description of their work and the relevant file references. Ask them to confirm or correct it—for example: “We recorded that you created the initial sketches and revised the colours in version 3. Is that accurate, and is anything missing?” Keep their replies and record any disagreements. If someone describes their contribution months later, distinguish that recollection from emails, drafts or notes created during the project.

Explain the basis for ownership

The person who created the work and the person or organisation that owns the rights may differ. An employer may own rights under the applicable law, or a creator may transfer them by agreement.

Keep employment terms, commissioning and collaboration agreements, and signed assignments transferring rights. If rights have changed hands more than once, retain the documents for each transfer. Check that they identify the work, the rights transferred and the parties involved.

Invoices and delivery emails help document payment and receipt of the work, but do not necessarily show that rights were transferred. For example, the UK Intellectual Property Office explains that commissioning a copyright work does not, by itself, make the customer its owner. The customer may have permission to use it without owning the copyright. This is a UK copyright example; the rules vary by right and country. For the employment terms, contractor agreements and licences a company should retain, see documenting company rights in employee and contractor work.

Make the evidence easy to follow

Prepare a short summary naming the work and its contributors, listing key dates, and identifying the contracts or legal basis for ownership. Link each statement to the relevant draft, message or agreement. Flag missing contracts and disagreements about who did particular work.

Someone unfamiliar with the project should be able to follow how the work developed and why ownership is claimed. Whether the evidence establishes those rights depends on the type of IP and the applicable law.

Sources

UK Intellectual Property Office. Ownership of copyright works. UK-specific guidance on creators, employment, commissioned works and the distinction between permission and ownership.. Accessed 9 November 2026

What evidence helps a lender or valuer assess an unregistered IP asset?

Marco Barulli — Mon, 09 Nov 2026 00:00:00 GMT

Updated: 2026-11-09

Provide a defined asset and version, development records including any timestamped evidence, documents supporting the company’s rights, and records connecting the asset to revenue or cost savings. Explain the conditions supporting its legal protection and what another operator would need to use it. These records support valuation and lending decisions; they do not themselves establish financial value or make the asset acceptable as collateral.

Separate the asset, the rights and the recovery question

For unregistered software, designs and confidential know-how, there may be no public IP register identifying the asset and its owner. The company must provide records that let someone outside the business examine what exists, what protection and rights it relies on, and how the asset produces a commercial benefit.

The opening chapters of Financing Unregistered Innovation distinguish three issues: whether the asset qualifies for legal protection, whether the company holds rights it can offer as security, and what a creditor could recover after default. Development records help establish what was created and when. Agreements and other legal records support the company’s rights, while technical documentation and access arrangements help assess whether another operator could use the asset.

Consider a manufacturer whose confidential calibration method reduces rejected products. A valuer needs to assess the benefit attributable to that method. If a lender is considering it as collateral, it also needs to understand what could be recovered or transferred if the borrower could no longer repay. The method’s value inside a functioning factory may differ substantially from its value to a buyer without the original team or equipment.

Identify what exists and what supports its protection

Provide the exact version being assessed, with a description of its boundaries and the records explaining its development. For the calibration method, that might mean operating instructions, parameter tables, test procedures and dated trial results. Link important milestones to contributor records and any matching timestamp certificates. See how to identify the exact asset under review.

The evidence of protection depends on the asset:

Confidential know-how: identify the information treated as secret and the measures used to control access and disclosure. Explain why its confidentiality contributes to its commercial benefit.
Software: identify the relevant code and contributors, distinguishing original development from third-party components and the permissions governing them.
Unregistered designs: identify the design and the creation or disclosure events relevant to the particular protection claimed, including their dates and locations. Have the applicable conditions and remaining term assessed.

Timestamped records help make the chronology and integrity of particular files checkable. They do not establish that all legal conditions for protection are satisfied. For example, a certificate for a process description does not demonstrate that everyone receiving it was subject to confidentiality obligations.

If earlier records are incomplete, identify which dates and events the available evidence supports. See building evidence now for work developed in the past.

Show which rights the borrowing company actually holds

Connect the asset to founder and contributor assignments, employment records, collaboration agreements and incoming licences. Identify the legal entity holding the rights, any joint owners, rights already granted to others and restrictions relevant to continued use or transfer.

For the calibration method, the company may hold the rights to use and license its confidential parameter tables but rely on supplier software to run them. The supplier licence and any required consent matter to the assessment even though the software is excluded from the company’s own know-how asset.

Where security is proposed, provide existing financing documents and relevant records of earlier security interests for legal review. The advisers must assess whether and how a lender can take security over the asset, where its claim ranks against other creditors and what it could do if the borrower defaults. An asset inventory or digital certificate does not perform those legal steps.

Connect commercial claims to underlying records

Show how the defined asset is used and provide the records behind the claimed benefit. A useful evidence package connects the technical material to operations and then to financial results.

Claim being assessed	Evidence that helps examine it
The calibration method reduces rejects	Production and quality records identifying the process version, test conditions, inputs and comparison period
Lower rejection rates save money	Scrap, rework and operating-cost records reconciled to the claimed saving, including implementation costs
Software generates recurring income	Customer contracts, invoices, receipts and renewal records linked to the relevant product or service
Designs generate licensing income	Signed licences, royalty statements, payments and the design versions covered

In the manufacturing example, fewer rejects after introducing the method are relevant, but other changes may explain part of the improvement. Record equipment upgrades, input changes and operator training during the same period. Let the valuer distinguish the contribution of the know-how from the contribution of other assets and people.

Similarly, total revenue from a software business is not automatically revenue attributable to one codebase. Customer relationships, support services, brands and other technology may contribute. Explain the allocation used and identify assumptions that still need testing.

Distinguish recorded results from valuation assumptions

Provide historical records separately from forecasts. If the method is still at pilot stage, describe the trials and the assumptions needed to extend them to commercial production. Do not present expected savings as savings already achieved.

Development expenditure can explain the resources invested and inform a cost-based assessment, but it is not automatically the asset’s value. Forecast income, comparable transactions and replacement costs serve different valuation approaches. The UK Intellectual Property Office’s valuation guidance explains their limitations, including uncertainty about future benefits and the difficulty of finding comparable transactions.

Agree the valuation purpose, date and scope with the valuer. A valuation for continued use in the business may involve different assumptions from a sale following default. WIPO’s guidance highlights economic benefits and, for collateral financing, continued validity and marketability. A valuation figure is an input to a credit decision, not a commitment to lend that amount.

Document what another operator would need

For the calibration method, could a qualified operator reproduce the process from the preserved instructions, or does it depend on choices only the founder understands? Provide evidence of handovers, training or reproduction trials where available, identifying what was tested and by whom.

For software, include build and deployment instructions, dependencies, maintenance requirements and the permissions needed to continue operation. For encrypted material, document who controls access and the agreed process for authorised access if the borrower cannot cooperate. Keep credentials and keys outside the general review package.

Identify obstacles such as non-transferable licences, specialist equipment, missing documentation or dependence on particular people. Technical access, legal permission to use the asset and the existence of a willing buyer are separate questions. Preserving files alone does not resolve them.

The paper also distinguishes lending against a specific asset from financing based on royalties, customer payments owed to the business or the wider business itself. The evidence should match the proposed route: records of dependable contracted income may matter more in one case, while transferable technical material and a credible recovery plan matter more in another.

Preserve the basis of the assessment

Keep a dated package identifying the asset version, supporting records, assumptions and unresolved issues supplied for review. Certify that package where appropriate and retain the exact files and verification material. Record later changes to the asset, its licences or its commercial performance so an earlier assessment is not silently applied to a different situation.

Use staged confidential review where the supporting material contains sensitive know-how. The lender or valuer should be able to identify what was examined directly, what relied on an expert report and what remains unverified.

Sources

Marco Barulli and Paul Reboh. Financing Unregistered Innovation: A Comparative Study of IP-Backed Finance for Trade Secrets, Designs, and Software. Version 1.0, November 2026, Part I, chapters 1–3: legal protection, entitlement and encumbrance, operational recovery, and different financing routes. Working paper published by Bernstein.. Accessed 9 November 2026
World Intellectual Property Organization. Valuing Intellectual Property Assets. Identifiable assets, economic benefits, valuation approaches and marketability for financing.. Accessed 9 November 2026
UK Intellectual Property Office. Valuing your intellectual property. Cost, market and income approaches; limits of historical expenditure and assumptions about future benefits.. Accessed 9 November 2026

What evidence should I preserve to support prior-use rights if someone else later patents the technology?

Marco Barulli — Mon, 09 Nov 2026 00:00:00 GMT

Updated: 2026-11-09

Preserve the technical versions your business used, together with records showing what it did, where, when and through which legal entity. Keep evidence of development, actual operations and concrete preparations, clearly distinguishing each stage. Timestamp successive collections as events occur to reinforce their chronology. Whether these facts support prior-use rights depends on the country and the patent concerned.

Record the technology and what the business actually did

Prior-use rights may allow a business to continue certain activities despite a later patent. The qualifying facts differ between countries, including whether the law recognises actual use, preparations or prior possession of the invention. WIPO’s comparative study explains these differences and the importance of preserving evidence when the activity occurs.

Keep enough technical detail to identify the version involved: drawings, specifications, source code, formulations, machine settings or operating instructions. Link each version to records showing how it was used, such as production logs, batch sheets, installation records, test reports or customer deliveries. A drawing shows a design; it does not alone show that a machine was built or operated.

For example, a manufacturer using a particular mixing method could preserve the operating instructions, equipment settings and batch records identifying the dates, site and operator. Sales or delivery records for the resulting products add commercial context. Together, these documents connect the technical method to identifiable operations.

Distinguish development, preparation and actual use

Keep the stages separate. Laboratory experiments, an approved investment, an equipment order, commissioning and routine production describe different activities. Record what had actually happened at each date, including cancellations or unfinished work.

Where implementation was being prepared, preserve purchase orders, supplier correspondence, site plans, tooling specifications and installation schedules. These help explain the commitment made and how close the business was to using the technology.

The legal threshold needs checking locally. For example, UK law can recognise effective and serious preparations made in good faith before the relevant priority date. The US prior-commercial-use defence generally requires qualifying commercial use at least one year before the earlier of the effective filing date or a public disclosure qualifying for the statutory grace-period exception. Merely showing that work predates the patent’s grant is therefore insufficient.

Identify the business, location and origin of the work

Name the legal entity carrying out the activity and the facility and country where it occurred. If contractors or group companies were involved, retain their instructions, agreements and records of the work performed. Do not assume that activity by one company or in one country automatically establishes rights for another.

Preserve records explaining how the technology was obtained: development notes, earlier designs, contributor correspondence and any relevant licences. These can help address questions about independent development and good faith.

Also record later changes to the technology, production sites and business ownership, and any interruption in use. Their effect on the right depends on local law; retaining them allows an adviser to assess continuity and the scope of the activity that may be protected.

Preserve and timestamp the records as events occur

Build successive collections around meaningful events: a completed trial, equipment commissioning, the start of production or a technical revision. Keep the original production logs, test reports and correspondence. For each, record where it came from—for example, the factory’s production system, the testing laboratory or the equipment supplier. Retain supplier and customer documents alongside internal notes where they corroborate the same events.

Timestamp each collection promptly and retain its exact files, certificates and verification data. Bitcoin anchoring and authority-issued timestamps can support this chronology; see what a digital timestamp establishes. A timestamp dates the preserved material, but does not independently establish that an operation described in it took place.

In the mixing-method example, timestamped collections from trials, commissioning and production help preserve the sequence of technical and operational records. Timestamping only the final operating manual would not establish when the trial or commissioning records existed. Keep confidential material under access controls; collecting this evidence does not require publishing the technology.

Use the records when a later patent becomes relevant

These steps build the evidence an adviser will need. Deciding whether it supports continued operation requires comparing the recorded activity with the patent and the local conditions for prior-use protection. See what freedom to operate means and how prior use affects it for that assessment, including the limits on changed or expanded operations.

Sources

World Intellectual Property Organization. Draft reference document on the exception regarding prior use. SCP/32/3, Annex: comparative treatment of qualifying activities, territory, scope and evidence. A 2020 survey, not a statement of current law in every country.. 6 May 2020. Accessed 9 November 2026
UK Intellectual Property Office. Manual of Patent Practice: Section 64 — Right to continue use begun before priority date. UK example: good-faith acts or effective and serious preparations before the relevant priority date; limits on the protected activity.. Accessed 9 November 2026
United States Government Publishing Office. 35 U.S.C. § 273 — Defense to infringement based on prior commercial use. US requirements for qualifying commercial use, timing, good faith, evidence and the scope of the defence; 2024 Code edition.. Accessed 9 November 2026

How can I let a potential investor, buyer or licensee examine confidential know-how while limiting disclosure?

Marco Barulli — Mon, 09 Nov 2026 00:00:00 GMT

Updated: 2026-11-09

Agree what the reviewer needs to assess, then disclose the least sensitive material that can answer that question reliably. Use staged access, defined confidentiality terms and, where appropriate, an independent expert. Preserve and timestamp each disclosure package, linking it to the recipients, terms and access records. Make clear what the reviewer has verified and what still requires access to the underlying know-how.

Start with the decision the reviewer needs to make

A potential investor may need confidence that a process works and that the company controls the relevant know-how. A prospective licensee may also need to establish whether it can reproduce the result with its own equipment. Those questions require different levels of access.

Ask the reviewer to identify the uncertainty they need to resolve before requesting a complete technical folder. Record the question, the proposed evidence and any further examination that may be necessary. This turns disclosure into a sequence of specific assessments.

WIPO’s trade-secret guidance recognises that a licensee may need access to confidential information to assess its utility or value. Confidentiality measures must allow a meaningful examination while controlling how that information is used.

Reveal evidence in stages

Consider a fictional manufacturer licensing a confidential calibration method. The method improves production consistency, but its parameter tables and operating sequence would let a competitor reproduce it. A possible review sequence is:

Question under review	Initial evidence	Detail reserved for further review
Does the method produce the claimed result?	Test report describing conditions, measurements and limitations	Exact settings and full operating instructions
Are the results repeatable?	A witnessed trial under agreed conditions	Instructions needed to reproduce the trial independently
Does the company hold the rights needed to license the know-how?	Asset description, contribution records and relevant agreements	Technical annexes identifying sensitive contributions
Can the licensee use the method on its own line?	Compatibility assessment by an agreed technical reviewer	Detailed parameters, training and implementation material

Agree what triggers the next stage, such as completion of an initial technical assessment and agreement on the recipients and terms for deeper review. An investor examining an early opportunity may not need the same access as a buyer completing an acquisition.

A demonstration supports what happened under the conditions shown. It does not necessarily establish that the method will work at another scale, with other inputs or without the original operator. Record those limits so the next stage addresses the remaining question.

Use an independent reviewer where direct disclosure is too sensitive

The parties may agree that a suitably qualified expert examines the detailed know-how and reports on specified questions. For the calibration method, the expert could inspect the settings, witness trials and assess compatibility without passing the full parameter tables to the commercial team.

Agree who appoints the expert and check their qualifications and any conflicts of interest. Define which material they can access, the tests they will perform, their confidentiality obligations and what their report may disclose. The receiving party must accept the scope and limitations of the report if it is to serve the intended review.

Identify the exact technical package examined and preserve the report with that reference. “The technology was independently reviewed” is too vague if the expert saw only selected results or an earlier version. Expert review can reduce direct disclosure, but it cannot answer questions excluded from its scope.

Define the terms and people before granting access

Specify the permitted purpose, such as evaluating a licence for the identified method. Identify the receiving organisation and the employees or advisers allowed to examine the material, including how further disclosure is authorised. Address copying, testing, retention and use of the information as appropriate to the review.

The UK Intellectual Property Office’s NDA guidance recommends defining the permitted purpose precisely and considering disclosures to employees and professional advisers. Check the applicable agreement before granting access. If a potential investor will not accept confidentiality terms at the introductory stage, use material suitable for that exchange and leave the sensitive technical examination for a separately agreed process.

For the detailed mechanics, see how to identify information covered by an NDA. An NDA does not determine which files a person needs to see; that decision still comes from the review scope.

Preserve the package before disclosing it

Prepare a separate package for each stage, containing only the material intended for those recipients. Check that redacted files do not expose hidden text, comments, spreadsheet formulas or attachments. Preserve the original material separately, with a record of how the disclosure copy relates to it.

Timestamp the exact package before release and retain the matching files and verification data. This gives the disclosure a verifiable content reference that can also appear in an annex or review report. It does not require revealing the underlying know-how publicly. See what a digital timestamp establishes.

For the calibration example, certify the initial test report as its own package. If a technical expert later receives the settings and operating instructions, preserve and certify that separate package too. A certificate for the complete internal project does not, by itself, identify which subset the investor received.

Timestamping supports the dated existence and integrity of the package. It does not demonstrate that the process works, that the company owns the know-how or that the recipient kept it confidential. Those questions rely on the technical assessment, rights documents and handling records.

Record the examination as well as the file exchange

Keep the package reference, recipients, applicable terms and available delivery or access records together. For a demonstration or technical call, record who attended, what was shown and what additional detail was explained. A follow-up answer revealing a parameter or process step is another disclosure even if no new file was uploaded.

Ask the reviewer to distinguish in their report between material examined directly, conclusions based on summaries, and matters left unverified. This prevents a limited review from being presented later as a complete technical assessment. See how to document recipients and accepted terms.

When the review ends, close access and follow the agreed retention, return or deletion arrangements. Preserve the disclosure history and any confirmations received. Access restrictions can control future retrieval, but cannot erase downloaded copies or knowledge already acquired. Decide how much to disclose with that practical limit in mind.

Sources

World Intellectual Property Organization. Frequently Asked Questions: Trade Secrets. Confidentiality measures and the difficulty of assessing know-how for licensing without access to the information.. Accessed 9 November 2026
UK Intellectual Property Office. Non-disclosure agreements. Sections 2, 4 and 5: permitted purpose, recipients, signatories and records of disclosures. UK guidance; legal effects depend on the agreement and applicable law.. Accessed 9 November 2026

What is freedom to operate, and how does prior use affect it?

Marco Barulli — Mon, 09 Nov 2026 00:00:00 GMT

Updated: 2026-11-09

If your business already uses technology that someone else later patents, a freedom-to-operate assessment asks whether you can continue without infringing their rights. Qualifying prior use may allow you to continue despite that patent. The assessment must establish which activities and countries this protection covers, and whether other patents or planned changes create further obstacles.

Can we keep using technology we already developed?

Suppose your business has used a confidential mixing method for several years. You then discover that another company holds a patent that appears to cover it. Your immediate question is whether you can continue production. That is a freedom-to-operate question: does someone else’s patent restrict what your business wants to do?

Your earlier use matters because it may support a right to continue despite that patent. To assess this, a patent adviser needs to establish both whether the patent covers your method and whether your earlier activity meets the local conditions for prior-use protection.

For the practical steps to document earlier use, see what evidence to preserve for prior-use rights. Here, the question is how those records help establish whether your business can continue operating despite a particular patent.

First check whether the patent covers your operation

Give the adviser the technical description of the method you use, the countries where production and sales take place, and the patent you have identified. The review compares your method with the patent’s claims—the numbered statements defining its protection—and checks whether the patent is in force in the relevant countries. A similar title or drawing does not establish that your activity falls within its scope.

The Swiss Federal Institute of Intellectual Property describes this focus on claims, scope and legal status. If the patent does not cover your activity, or is not in force where it matters, you may not need a prior-use defence against it. A wider FTO review also considers other potentially relevant patents and published applications.

Establish what your earlier use allows you to continue

If the patent presents an obstacle, the next question is whether your business qualifies for prior-use protection. The relevant dates, territory, activities and person entitled to rely on the right depend on national law. Some systems recognise certain preparations as well as actual use; others apply different conditions. WIPO’s comparative study explains these differences.

In the mixing-method example, qualifying prior use could allow the manufacturer to continue its existing operation without the patent owner’s permission.

The conclusion must identify the activity protected. For example, the US prior-commercial-use provision expressly limits the defence rather than granting a general licence under every patent claim. The defence also does not, by itself, invalidate the patent.

Use the records to assess whether the conditions are met

The adviser needs to connect each legal requirement to specific evidence. Technical files identify the method used; production or testing records show the activity; dates, locations and company details establish when, where and by whom it was carried out. Distinguishing experiments, preparations and commercial operations helps determine what had happened by the legally relevant date.

In the mixing-method example, the adviser would compare the dated operating instructions with the method covered by the patent, then check the batch records for evidence that the business used that method at the relevant site and time. Timestamps can support when those documents existed. The batch records and other supporting documents must still establish the operation itself. If the batch records do not identify the method used or the production date, flag that gap before relying on the defence.

Check new plans against the limits of the right

Continuing the existing mixing method and launching a changed operation are different questions. If you introduce a new mixer component covered by another patent, your earlier use of the method does not automatically address that patent. Moving production to another country or changing the method also requires checking whether the protection still applies.

Keep the adviser’s conclusion with the technical version, countries and activities reviewed. Record which prior-use right supports continued operation and which proposed changes still need assessment. Where protection is insufficient, options may include a licence, a design change or a challenge to the patent. WIPO’s FTO overview discusses these approaches.

Sources

World Intellectual Property Organization. IP and Business: Launching a New Product: freedom to operate. Scope of FTO analysis, territorial and time limits of patents, and options for addressing patent obstacles.. 30 September 2005. Accessed 9 November 2026
Swiss Federal Institute of Intellectual Property. Freedom-to-operate search. Search and analysis focused on patent claims, scope of protection and legal status.. Accessed 9 November 2026
World Intellectual Property Organization. Draft reference document on the exception regarding prior use. SCP/32/3: comparative overview of prior-use rights and their limits; a 2020 survey, not current legal guidance for every country.. 6 May 2020. Accessed 9 November 2026
United States Government Publishing Office. 35 U.S.C. § 273 — Defense to infringement based on prior commercial use. US example: qualifying prior commercial use, a limited defence rather than a general licence, and no invalidation solely through that defence; 2024 Code edition.. Accessed 9 November 2026

Can I build useful IP evidence now for work developed in the past?

Marco Barulli — Mon, 09 Nov 2026 00:00:00 GMT

Updated: 2026-11-09

Yes. Earlier deliveries, correspondence, development records and records held by other parties can support a history assembled today. Connect each claim to the material that supports it and distinguish original records from later recollections. Timestamping the assembled package creates a verifiable record from now onward; it does not backdate the work or resolve missing ownership agreements.

An incomplete history can still contain useful evidence

Consider a fictional startup preparing for investment. Its founders say they developed a prototype two years ago, before the company was incorporated. They have the current design, some old drawings and an email exchange with a manufacturer, but no timestamp certificate from that period.

Those records may still support an earlier history. Examine which parts of the account they substantiate: what was sent to the manufacturer, which features were present, who contributed and how the work reached the company. These are separate questions, and the evidence may answer some more clearly than others.

This is particularly relevant to unregistered software, designs and know-how. A patent application or registration already provides an official record for its own contents and procedural dates; reconstructing development history is not a substitute for reviewing that record.

Connect an earlier event to identifiable material

A useful historical record connects a date or event to particular content. In the prototype example, an original email with an attached drawing may support that the drawing was sent at that stage. A reply discussing a feature can add context. A copy retained by the manufacturer may provide corroboration beyond the founder’s own files.

The strength of that connection depends on the records’ authenticity, completeness and provenance. Preserve the original message and attachment where available, and record who supplied them. A screenshot showing an email date but omitting the attachment gives the reviewer less to examine.

Compare what different records actually support:

Record recovered	What it may help establish	What still needs connecting
Manufacturer’s email and attached drawing	A particular design was exchanged at that stage	Which features carried through to the current design
Prototype invoice and delivery record	A prototype was ordered or delivered	The specification or version used to make it
Repository history and release archive	Development steps and the contents of a release	The reliability of the dates and identities recorded
Earlier timestamp certificate with matching files	The dated existence and integrity of those files	Their contributors, ownership and relationship to the present asset

Several records can support one another, but check whether they come from independent sources. Three documents repeating the same unsupported date do not provide three independent confirmations. For software, see whether Git commits are enough to document development.

Separate the earlier version from what exists today

Suppose the manufacturer’s copy shows the prototype’s housing, but the current design includes a mechanism added later. The earlier exchange may support the housing’s history. It does not establish that the later mechanism already existed.

Preserve both versions and describe the differences. Where the link is uncertain, say so: “This drawing documents the housing used in the first prototype; we have not located a dated record of the mechanism before the later release.” That is more informative than assigning the earliest date found to the entire current product.

The same applies to know-how. An old test report may document a result without recording the process that produced it. Identify what the report contains and what still depends on an explanation from the people involved. For practical ways to define the material, see how to identify the exact asset under review.

Use recollections to explain the records, with their limits visible

Ask contributors to explain their own role, the sequence of work and the records they recognise. Date their account when it is prepared. Have them distinguish what they remember directly from what they infer from documents, and identify any uncertainty.

For example, a founder may recognise a drawing as the version used in an early demonstration but be unable to recall its exact date. Their account can connect the drawing to that event; a calendar entry, attendee’s correspondence or demonstration photographs may help establish when it happened.

A signature helps attribute an account to its author; the statements still need to be assessed against the available records. Preserve differing accounts and investigate material disagreements rather than editing them into an artificially consistent history.

Timestamp the evidence you can assemble now

Once the historical material and explanatory account are organised, preserve and timestamp that package. This establishes a dated record of the files available at the new certification point and allows someone to check later whether the presented files match it. It is useful even when the events described are much older: future reviewers can examine the same preserved material, and later additions can be distinguished from this starting point.

The earlier dates remain supported by the historical records and their context. If the package contains a drawing described as being from two years ago, today’s timestamp does not independently establish that earlier date. If you recover an earlier certificate, keep it with its matching files and verify it separately.

Preserve the certified package unchanged, using working copies for annotations. Add newly recovered evidence as a further dated version. Different timestamping methods, including blockchain anchoring, can support this process; see what a digital timestamp establishes and what to preserve alongside a certificate.

Establish the company’s rights separately

Evidence that a founder developed the prototype before incorporation does not, by itself, show that the company now owns the relevant rights. The history needs to connect to the agreements or legal rules through which the company acquired them. WIPO’s guidance for investors and buyers distinguishes identifying the IP used by a business from demonstrating ownership or permission to use it.

If a transfer is missing, address it with the relevant parties and adviser. A new assignment may cover earlier work, but it should record the actual signing date and satisfy the applicable requirements. See how companies document rights to employee and contractor work.

For confidential know-how, distinguish the development history from the history of confidentiality measures too. Introducing access controls today does not establish who could access the material in the past.

In this example, the completed review might support different conclusions with different levels of confidence: an early drawing is corroborated by the manufacturer’s records, the later mechanism is documented only from a subsequent release, and the transfer to the company was completed during preparation for investment. Keeping those distinctions visible makes the evidence useful to a reviewer without claiming a completeness the records cannot support.

Sources

World Intellectual Property Organization. Accelerate by Working with Investors and Buyers. Evidence of ownership, restrictions on use and transferability of key agreements.. Accessed 9 November 2026

How can I identify the exact software, designs or know-how being reviewed in due diligence?

Marco Barulli — Mon, 09 Nov 2026 00:00:00 GMT

Updated: 2026-11-09

Define what is included, give the asset and version clear references, and preserve a fixed set of files. Use an index to connect those files to the specific records supporting their development, ownership and use. For timestamped material, identify exactly which files each certificate covers. Keep later changes separate so reviewers can tell which version they examined.

Start with a specific asset, not a project folder

For registered rights, an application or registration number gives reviewers an official starting point. Unregistered software, designs and know-how need a description that identifies the material being examined. The broader evidence checklist is covered in what to organise before IP due diligence; this answer focuses on defining one asset and its supporting record.

Consider a fictional manufacturer preparing its production-line calibration method for a potential licensee. The method combines operating instructions, parameter tables and a test procedure. The folder called “Line A development” also contains abandoned experiments, supplier manuals and working drafts. Sharing that folder would leave the reviewer to decide which material constitutes the method.

Instead, prepare a short asset description. Give it a reference that stays the same as it develops, such as CAL-01, and explain its purpose, boundaries and dependencies:

Included: the sequence for calibrating line A, the settings for the specified materials and the procedure for checking the result.
Excluded: earlier experimental settings, the machine supplier’s manual and the control software supplied with the machine.
Dependencies: the machine model and software version needed to apply the method, with separate references to the relevant supplier documentation and permissions.

Excluding a supplier’s manual from the asset does not make it irrelevant. It makes clear that the company is presenting its calibration method, while identifying the external material needed to use it.

List the files that define this version

Give the package a version, such as CAL-01 version 2.0, and preserve a fixed copy. Its file list might look like this:

Material	Version included	Role in the asset
Calibration instructions	Revision 3	Defines the operating sequence
Parameter tables	Revision 7	Specifies settings for the listed materials
Acceptance test procedure	Revision 2	Defines how the calibration is checked

Add the exact filenames and storage references to the actual list. The package version identifies the combination being reviewed; individual files can have different revision numbers.

Check whether the documents are sufficient to explain the method. If an operator selects settings using experience that has never been recorded, identify that gap and arrange for it to be documented. Do not describe the package as containing the complete method while essential steps remain unexplained.

For software, the equivalent package might contain a preserved source-code release, build instructions and a dependency list. For a design, it might contain the editable drawings, specifications and reference images for one version. In each case, identify what belongs to the version under review.

Connect each point to the evidence supporting it

Keep the material defining the asset distinct from the records explaining its history and the company’s rights. Both belong in the review, but they serve different purposes.

For CAL-01, an evidence index could contain entries like these:

Point to examine	Supporting record	Connection to check
How the settings were developed	Trial report and contributor notes	Identifies the trials that led to revision 7 of the parameter tables
The company’s rights in a contractor’s contribution	Signed agreement, delivery schedule and acceptance message	Identifies the delivered tables and the provisions covering rights in them
How the method was kept confidential	Access records and disclosure records with the applicable NDAs	Identifies who could access which material and under what terms
Which version existed at a recorded time	Timestamp certificate and matching files	Identifies the instructions, tables or package covered by that certificate

In the actual index, use precise document references and point to the relevant clause, page, delivery or file. “Contractor agreements” is not enough if several contractors worked on different versions. Mark uncertainty where a delivery schedule fails to identify the material clearly.

This lets a reviewer check whether the ownership documents cover the identified material, as recommended in the Hong Kong Intellectual Property Department’s due diligence guidance.

Preserve and timestamp the package prepared for review

Once the CAL-01 package is ready, set aside the exact files being submitted for review, including the description and file list. Prepare readable copies where needed. For the parameter tables, retain the source spreadsheet if its formulas or structure matter, and include an export showing the values and how to read them. Check that the export accurately represents the selected version before certifying it.

Timestamp this fixed package to create a dated record of the material assembled for review. The certification process uses cryptographic fingerprints to connect the certificate to the exact digital files. During verification, the fingerprints are recalculated from the supplied files and checked against the certified record. See what a digital timestamp establishes.

Preserve the certified files unchanged and use separate copies for editing or annotation. Certification covers the file’s exact bytes, not just its visible contents: saving a spreadsheet again can change the file even when its displayed values look the same. Exports need the same care. If you certify an archive, retain that exact archive; recreating it from the same documents can produce different bytes.

Keep earlier timestamped development records alongside this review package, with their scope clearly identified. A certificate covering revision 7 of the parameter tables supports that version’s dated existence. It does not give the same date to instructions added later. Equally, timestamping the assembled package now records the combination available now; it does not establish the earlier history described in its trial reports.

Retain the certificates and verification data, link them from the evidence index and check that verification succeeds before handing over the package. Record separately which version the reviewer received: a timestamp establishes a dated record of material, not its delivery. See what to preserve alongside a timestamp certificate.

Keep the description useful without disclosing the secret

The general inventory can identify CAL-01, its purpose and the categories of material included. Keep the detailed settings and instructions in restricted storage, with access appropriate to the review. Check that filenames and index descriptions do not themselves reveal sensitive parameters.

The restricted description should identify the information or combination the company treats as secret. WIPO notes that a secret combination can include elements that are individually public. For CAL-01, the relevant know-how might lie in how the sequence and settings work together. Calling every file “confidential” would not explain that relationship or demonstrate the measures taken to protect it.

Record changes without replacing what was reviewed

If the team changes the settings during due diligence, preserve CAL-01 version 2.0 and create version 2.1. Record which files changed, why, and which supporting records apply to the update. Tell the reviewer which version is current and retain a record of the version they received.

Before handing over the package, ask a colleague unfamiliar with the method to follow the references. They should be able to identify the included files, distinguish supplier material, locate the agreement covering a contribution and find the files matching a certificate. Any broken connection is a concrete item to resolve before the review proceeds.

Sources

Hong Kong Intellectual Property Department. IP Due Diligence. Examining documents supporting ownership and rights relevant to a transaction.. Accessed 9 November 2026
World Intellectual Property Organization. Frequently Asked Questions: Trade Secrets. Identifying confidential information, including combinations of elements, and measures to preserve secrecy.. Accessed 9 November 2026

How can a licence or transfer agreement identify the exact files, designs or know-how it covers?

Marco Barulli — Mon, 09 Nov 2026 00:00:00 GMT

Updated: 2026-11-09

Define the material in a schedule that forms part of the agreement, identifying its scope, version and any exclusions. For digital material, preserve and timestamp the agreed package and reference its certificate and file list in that schedule. State separately which rights are licensed or transferred, how delivery is confirmed and whether later versions are included. Certification helps verify the identified files; the agreement determines the rights granted.

Make the agreement point to a defined version

A phrase such as “the designs supplied to the licensee” leaves room for disagreement if the parties exchanged several versions during negotiations. A shared folder can change after signing. Identify the material through a schedule or annex that the agreement expressly incorporates, with a description and version reference the parties can check.

For example, a furniture designer licenses a chair design to a manufacturer. They have exchanged concept sketches, production drawings and several revisions of a cutting template. The agreement should identify which drawings and template constitute the licensed package, and whether the earlier concepts are included.

Prepare the package using the approach described in how to identify the exact material under review. Then make the clauses granting rights refer expressly to that defined package.

Combine a readable description with a certified reference

The schedule should explain what the material is, while the certificate provides a way to verify the exact digital version. For the chair design, the schedule could identify:

The design name and package reference, such as “Chair C — production package version 3”.
A file list identifying the production drawings, cutting template and assembly instructions, with their individual revisions.
The certificate reference for that preserved package and the information needed to locate and verify it.
Exclusions, such as rejected concepts, the designer’s reusable component library and supplier-owned drawings.

These are elements to include in the schedule, not a complete model clause. Have the agreement specify how the schedule defines the material covered and how any inconsistency between the description, file list and referenced package is resolved.

Finalise and timestamp the package before fixing its reference in the agreement. Check that both parties are referring to the same package. A certificate number alone does not explain the subject matter or make inaccessible files usable; preserve the underlying material and agree how authorised parties can retrieve it.

For confidential know-how, the contract can identify a restricted technical package without reproducing the secret instructions in its main text. The parties still need an agreed means of identifying and accessing that package. The reference remains useful only if authorised parties can identify and retrieve the material it points to.

Distinguish the material from the rights granted

Identifying a drawing does not determine whether the recipient may manufacture from it, modify it, sublicense it or use it in another territory. The agreement must specify those permissions or the rights being transferred, together with relevant limits and conditions. The European IP Helpdesk’s guidance on assignments and licences explains the distinction between transferring ownership and granting permission to use IP.

In the chair example, possession of the editable design files and a licence to manufacture the chair are separate matters. Identify both the files to be delivered and the rights granted in relation to them. Likewise, access to confidential process instructions does not by itself settle the permitted uses or confidentiality obligations.

For registered rights, list the relevant application or registration numbers and jurisdictions in the appropriate schedule. Certified drawings may help identify the technical deliverables, but they do not replace identification of the patent, trademark or registered design rights included in the transaction.

Check third-party and jointly owned material separately. A precise file list cannot supply rights the grantor does not hold. The Hong Kong Intellectual Property Department highlights the risk that the actual ownership position does not match the licence or assignment the parties intend.

Make delivery and acceptance refer to the same package

Use the agreed package reference in the delivery message or receipt. Retain the delivered files, the signed agreement and schedule, and the certificates and verification data. The recipient should be able to check that the files received match the version identified in the contract.

Distinguish receipt from any contractual acceptance procedure. A download record may support that files were accessed; it does not necessarily show that the recipient accepted their technical adequacy or that a condition triggering a rights transfer was satisfied. If acceptance, payment or another event matters, retain the evidence of that event separately.

For know-how, identify any training, demonstrations or practical assistance required in addition to the documents. A certified manual cannot establish that undocumented operating knowledge was successfully communicated. Record those activities against the agreement’s requirements.

Decide what happens when the material changes

If the designer later revises the cutting template, the new file should not silently replace the one identified at signing. Preserve the original package and give the update its own version and certificate reference.

The agreement should state whether updates are excluded, supplied under a defined update obligation, or included only through a further agreement. Where later versions can be added, define who can approve them and how their inclusion is recorded. Certifying an update does not automatically bring it within the rights granted by the agreement.

Apply the same care to improvements created by the recipient. Their inclusion and the parties’ rights in them need express treatment in the agreement rather than an assumption that everything placed in the project folder belongs to the original package.

Keep the contractual reference usable after signing

Retain a fixed copy of each agreed package and its supporting verification material, rather than relying solely on a live storage link. If storage changes, preserve the original references and record the new location. See what to preserve alongside a timestamp certificate.

A later reviewer should be able to start with the signed agreement, locate the incorporated schedule, retrieve the identified material and check it against the certificate. They can then examine the terms governing that material without first having to reconstruct which files the parties meant.

Sources

Hong Kong Intellectual Property Department. IP Due Diligence. Checking that ownership and existing rights are consistent with the proposed licence or assignment.. Accessed 9 November 2026
European Commission, European IP Helpdesk. Europe — Frequently Asked Questions. IP assignment and licensing: distinguishing transfers from permission to use, and applicable formalities.. Accessed 9 November 2026

What IP evidence should a company organise before due diligence by an investor, buyer or potential licensee?

Marco Barulli — Mon, 09 Nov 2026 00:00:00 GMT

Updated: 2026-11-09

Start with an inventory distinguishing registered rights from unregistered assets. For registered rights, assemble official records of scope, status and ownership, together with relevant agreements. For unregistered software, designs and know-how, identify the material and preserve development records, including timestamped evidence where available. For both, document ownership or permitted use, restrictions and unresolved gaps.

Start with the assets relevant to the transaction

Prepare an inventory of the IP supporting the products, services or technology under review. A potential licensee examining one manufacturing process may need a narrower set of records than a buyer acquiring the whole company.

Give each asset a clear name or reference. Describe what it consists of, where it is used, which legal entity owns it or holds permission to use it, and where the supporting evidence can be found. Include registered rights and applications alongside unregistered work. WIPO’s IP audit guidance provides a useful starting point for identifying assets, their business use and the rights of other parties.

Avoid entries such as “our technology” or “all company know-how” without further identification. For a production process, identify the relevant specifications, operating instructions, test results and versions. See how to identify the exact material under review for a worked example.

Distinguish registered rights from unregistered assets

The evidence needed depends on how the asset is protected. A registration or application gives reviewers an official reference from which to begin. For unregistered assets, the company needs to identify the material under review and assemble the records explaining its development and protection.

One product can involve both. A patented manufacturing process may depend on confidential operating parameters and software that are not fully described in the patent. List those associated assets separately and explain how they fit together, so that examining the patent does not leave important parts of the technology unexamined.

For registered rights, start with the official record

For patents, registered trademarks and registered designs, provide application or registration numbers, the relevant countries, the recorded owner and current status. Include the documents defining the protection, renewal or maintenance records, relevant deadlines and any pending challenges. Distinguish applications from granted or registered rights.

Connect these records to assignments, licences and other agreements affecting ownership or use. Where ownership has changed, keep the transfer documents and evidence of any required recordal. A register entry is a starting point for examining the company’s rights; the underlying agreements and any discrepancies still need review.

For a patent, the central questions concern its claims, legal status, ownership and the rights available for the transaction. The Hong Kong Intellectual Property Department’s due diligence guidance also identifies assessment of claim scope and potential freedom-to-operate obstacles. Timestamped development files are usually peripheral to this review, although they may matter if a specific issue about entitlement or development history arises.

For unregistered assets, identify the material and document its history

For software, unregistered designs and confidential know-how, identify the files, versions or documented information that make up the asset. Preserve source code, drawings, specifications, laboratory notes or operating instructions, together with records of contributors and significant development milestones. Explain which protection the company relies on for each asset, such as copyright, unregistered design rights or trade-secret protection; the requirements differ by right and jurisdiction.

Timestamped records can help reviewers check whether a particular version existed by a particular time and whether the supplied files match the dated record. Link any timestamped milestones or deliveries to the asset in the inventory. Different methods, including blockchain anchoring, can support this evidence; see what a digital timestamp establishes.

Connect the company’s rights to the supporting agreements

For both registered rights and unregistered assets, link the relevant work to founder assignments, employment records, contractor agreements, collaboration agreements, acquisitions and licences, as applicable. Include signed amendments and evidence that any conditions affecting the rights were met.

Identify the company by its legal name. If a founder developed the technology before incorporation, or another company in the group employed the contributors, preserve the documents explaining how the relevant rights reached the company under review.

Ownership and permission to use an asset should be distinguishable in the inventory. WIPO’s guidance for businesses working with investors and buyers emphasises both evidence of ownership and whether key licences can continue following an acquisition.

Show obligations and restrictions affecting the assets

Keep incoming and outgoing licences, customer commitments, research agreements and other arrangements that affect what the company can do with the IP. Identify relevant limits on territory, duration, exclusivity, sublicensing or transfer, and any consent required for the proposed transaction.

For software, include an inventory of third-party components and the applicable licence terms. For jointly developed technology, include the agreements governing each party’s use of the results. Record any security interests, ownership claims or disputes affecting the assets.

The purpose is to let reviewers compare the rights the company holds with the rights the transaction requires. The Hong Kong Intellectual Property Department’s due diligence guidance explains why examining ownership documents and rights already granted is central to that assessment.

Include evidence of confidentiality and business use

For confidential know-how, assemble records showing how the information was identified and handled: confidentiality agreements, access permissions, disclosure records and relevant procedures. Connect those records to the particular information concerned.

Keep evidence showing where the asset is used in the business, such as product releases, manufacturing records, customer agreements or licensing activity. Explain the connection: a customer contract may relate to a product containing several assets, rather than demonstrate the value of one particular invention or design.

Separate the inventory and introductory descriptions from sensitive technical material, and organise access around the agreed scope of review. See how to allow examination while limiting disclosure.

Preserve a history that reviewers can check

Keep original files and signed documents alongside the index used for due diligence. Record where each item came from, which asset and version it concerns, and whether it was created at the time of the events or reconstructed later.

For timestamped records, preserve the exact matching files, certificates and verification data so reviewers can check them. See what to preserve alongside a timestamp certificate.

If you are assembling the records now, distinguish earlier evidence from documents prepared for this review. See how to build useful evidence for work developed in the past.

Keep a short list of missing documents, inconsistent names, unclear contributions and unresolved rights. Assign someone to investigate each point and distinguish completed corrections from matters still awaiting agreement or legal assessment.

A reviewer should be able to move from an asset in the inventory to the records supporting it, understand what those records establish, and see where further investigation is needed.

Sources

World Intellectual Property Organization. Uncovering IP Risks and Potential: IP Audit. Asset inventory, ownership, third-party rights and business use.
World Intellectual Property Organization. Accelerate by Working with Investors and Buyers. Evidence of ownership and transferability of key licences.
Hong Kong Intellectual Property Department. IP Due Diligence. Ownership documents and rights relevant to the proposed transaction.

What records help demonstrate that a company treated particular information as a trade secret?

Marco Barulli — Mon, 09 Nov 2026 00:00:00 GMT

Updated: 2026-11-09

Identify the information the company kept secret and preserve records showing how it restricted access, informed recipients of confidentiality duties and controlled disclosures. Keep signed agreements, permission changes, access logs and training records linked to the relevant files. Timestamp successive collections to reinforce when those records existed and document how the protection measures changed over time.

Identify the information being protected

Describe the particular formula, process settings, source code, dataset or commercial information the company wants to keep secret. Give it an internal reference, identify the relevant versions and storage locations, and name the person responsible for managing access. Avoid descriptions so broad that nobody can tell which information they cover.

Record why secrecy matters commercially: for example, a combination of process settings reduces waste, or disclosure of a pricing model would let competitors predict the company’s bids. Distinguish the confidential details from information already published or routinely shared without restrictions. Keep the description itself under appropriate access controls.

Once you have identified the information, connect it to the measures used to protect it. For example, a confidential formula should be linked to the laboratory’s access permissions, staff confidentiality agreements and records of any external disclosures. These show how the company put its decision to keep the formula secret into practice.

Keep evidence of access restrictions in practice

Preserve records showing who was authorised to access the information, why they needed it, and when access was granted, changed or removed. Useful records include permission lists, approval requests, system logs and, where relevant, visitor or restricted-area entry records.

Keep the system exports and enough detail to interpret them: which folder or files they cover, the period recorded and who the usernames identify. A screenshot of today’s permissions does not explain who could open the folder six months ago. Record gaps in logging rather than treating the absence of an entry as proof that nobody accessed the information.

WIPO’s protection guidance includes physical and technical access restrictions and periodic reviews of who needs the information. Preserve the review decisions too, such as removing a former project member’s access.

Link confidentiality duties to the people and files concerned

Retain signed employment clauses, contractor agreements and NDAs, including the versions and dates that applied. Connect them to the people receiving the information and the project or material covered.

For each external disclosure, record the recipient, purpose, exact files or versions shared, applicable terms and sharing date. Keep the signed terms or acceptance messages, together with any delivery or access records. An NDA alone does not identify what was subsequently disclosed; the file list and correspondence supply that connection.

Keep the confidentiality instructions employees received, together with dated training materials and attendance or acknowledgements. Concrete instructions might specify which project folders are restricted, who can approve external sharing and where confidential files may be stored. The USPTO’s trade secret toolkit gives examples of contractual and operational protection measures in the US context; it does not prescribe a universal checklist.

Record how the company responded to changes and problems

When someone changes role or leaves, retain the access-removal record, equipment-return checklist and any requested confirmation about returning or deleting confidential copies. A deletion confirmation documents what the person stated; it does not independently verify every device or copy.

If information was sent to the wrong recipient or exposed through an open link, preserve the incident details, the investigation and the steps taken to contain it. Keep dates and unresolved questions. Do not rewrite the history to suggest that controls were always effective.

WIPO’s management guide treats monitoring, responses to leaks and employee departures as parts of ongoing protection. Keep records of access reviews, leak investigations and departure checks alongside the original policies.

Preserve a dated history of the measures

For example, a manufacturer protecting a coating formula could retain the formula version, a note explaining its commercial value, the approved laboratory users, their confidentiality terms and access logs. When a testing partner receives selected results, add the NDA, the files disclosed and the access-expiry record.

Preserve and timestamp these collections as the formula, recipients or controls change. Successive collections help document which versions and protection records existed at each stage. For timestamping methods and their limits, see what a digital timestamp establishes.

Keep the original files, certificates and verification data. Timestamping supports when those records existed, but does not authenticate every statement or demonstrate that information remained secret. The agreements, system records and documented actions provide the evidence of how the company handled it. Protect this evidence collection as carefully as the confidential information it describes.

Sources

World Intellectual Property Organization. Frequently Asked Questions: Trade Secrets. Secrecy, commercial value because of secrecy, and reasonable steps to preserve secrecy; national legal frameworks vary.. Accessed 9 November 2026
World Intellectual Property Organization. How to Protect Trade Secrets?. Confidentiality markings, access restrictions, agreements, reviews and employee training.. Accessed 9 November 2026
World Intellectual Property Organization. WIPO Guide to Trade Secrets and Innovation. Part IV: identifying valuable confidential information, implementing protection measures, monitoring and employee departures.. Accessed 9 November 2026
United States Patent and Trademark Office. Trade Secret Intellectual Property Toolkit. Protecting a trade secret: practical examples of reasonable measures in the US context, assessed case by case.. Accessed 9 November 2026

The question that stalls indie game deals: “Who owns what?”

Marco Barulli — Fri, 06 Nov 2026 00:00:00 GMT

Updated: 2026-11-06

How video game studios protect their IP and prove ownership of code, art, and music. A practical guide to due diligence from prototype to publishing deal.

Imagine a small indie studio about to sign its first publishing deal. The playable demo runs smoothly, the visual style looks sharp, and the publisher wants to move forward. Then comes the due diligence request that stalls everything: show us that you own or control the rights to everything in the game.

The founders wrote most of the code. A freelance artist designed the characters. The soundtrack mixes original tracks with stock audio. Several environment props came from an online marketplace. An early collaborator left six months ago, and the agreement covering their work sits buried somewhere in an old email thread.

The team can demo the game in ten minutes. Proving who made what, and under which terms, can take weeks.

IP questions come up throughout production. A competitor might copy a character, a contractor might dispute how their work is used, or a confidential prototype might leak online. Preparing for these moments means keeping a clear, dated record of the work, the contracts attached to it, and every version shared outside the team.

What, exactly, are you protecting?

A video game is not a single piece of intellectual property; it combines several kinds. Code, art, dialogue, and music usually fall under copyright. Game titles and logos involve trademark rules. Proprietary tools and game-balancing formulas may count as trade secrets, while certain novel technical systems might qualify for a patent. As WIPO’s overview of video games and IP points out, these rights and requirements vary depending on the country and the asset.

For a studio, the best place to start is with the files themselves: 3D models, animation clips, dialogue scripts, audio tracks, and source code for core mechanics. Each asset has an author, a creation date, and terms that dictate how the studio can use it.

The difference between an idea and its expression is just as important. The U.S. Copyright Office notes that copyright protects original creative expression, never raw concepts, systems, or game mechanics. Pitching “a cooperative survival game on a derelict space station” gives no exclusive right to that setup. The actual code, art, audio, and written words may qualify for protection. A verified timestamp can establish that specific work existed by a recorded time; it cannot turn a generic game idea into exclusive property.

Connect assets to the people and agreements behind them

Consider the freelance character artist. The studio has the finished model and a paid invoice. But does the contract grant full ownership, or only a license? Does it allow sequels, merchandising, or engine ports? Was the character built from scratch, or adapted from an existing base model?

A folder named after a contributor shows where the file came from, but it leaves the legal relationship unproven.

In Mastering the Game (p. 248), WIPO discusses the importance of agreements covering ownership when hiring contractors. The rights acquired depend on the applicable law and contract. A payment receipt or invoice is not a substitute for a signed contract.

A practical studio archive keeps the legal paperwork right next to the delivery. For commissioned work, store the signed contract, assignment of rights, acceptance emails, and source files together. For marketplace assets, save the specific license terms and purchase receipts. For departing team members, retain the agreements establishing which rights the studio holds in their contributions. A digital certificate can prove the date and integrity of these files, but it will not fix missing permissions or vague contracts.

Preserve the development history before you need it

If a distinctive creature from your demo turns up in another game, the finished model is only part of your evidence. Early concept sketches, discarded drafts, 3D sculpt iterations, and commit logs tell a much stronger story of how your design took shape.

The same trail protects you if another company accuses your studio of copying. Showing your internal work step by step can support an account of independent creation and clarify which third-party assets you used under license. The real value comes from records made during day-to-day work, rather than evidence scrambled together after a dispute begins.

There is no need to change your daily workflow. Keep using your regular version control and project tools. Alongside that stream, save dated snapshot packages at key milestones - such as the first playable build, approved character sets, investor pitch builds, and release candidates.

When preparing a package for a publisher, include the build, key source files, a design document, and a short summary of third-party libraries and licenses. Package what a reviewer will actually need; copying an entire project directory without context creates clutter instead of clarity.

Keep the exact files behind the evidence

A digital timestamp or certificate is only helpful if the studio can produce the exact file that matches it.

Game production makes this tricky. An artist re-exports a model with new settings, an audio track gets re-rendered, textures are recompressed, or the project moves to an updated engine version. The game may look identical on screen, but the file’s underlying bytes have changed. Its digital fingerprint (hash) will no longer match the version recorded months earlier.

To avoid this trap, keep the exact files sent to partners in safe, read-only storage alongside your everyday repositories. Active code repositories show ongoing work, but the preserved milestone packages provide the static baseline needed if ownership is ever challenged. Regular backups, secure key storage, and checks that files can still be opened help keep your evidence usable without relying on a single laptop or drive.

Record what leaves the studio

Different pitches require different levels of access. A publisher pitch might only need a short video and a pitch deck. Technical due diligence might expose source code and engine tools, while a co-development partner might need raw art assets.

Treat each disclosure as its own package. Note exactly which build was sent, who received it, what organization they represent, and which non-disclosure agreement (NDA) covers the exchange. If confidential material leaks later, this log can help investigate the disclosure history. Preserve the signed NDA or recorded acceptance of terms alongside it.

Keep in mind that technical tools have limits. Email verification establishes control of the designated email address; it does not establish the person’s identity or authority to sign an agreement for their employer. Once someone downloads a build, access logs cannot stop them from copying it to another drive. Signed contracts and technical tracking must work together.

Start with your next milestone

Getting organized does not require pausing production to audit years of old files. Start with the next milestone. Assemble the exact build, design notes, and key art ready for your next submission. Match those assets with their contractor agreements and marketplace licenses, timestamp the package before sharing it, and log who receives it. Repeating this simple routine at each major milestone turns due diligence from a panic into a quick, routine review.

How Bernstein supports this process

Managing evidence, version histories, and confidential disclosures by hand takes time that small teams rarely have. The Bernstein platform supports this process alongside the tools a studio already uses:

Certification with independent time evidence: Bernstein fingerprints your files and encrypts them in your browser before upload. Only the fingerprints are anchored on the Bitcoin blockchain. Qualified EU timestamps and timestamps from a Chinese authority are also available, depending on the plan. These separate certificates provide independently verifiable evidence of existence and integrity at the recorded times, as explained in How Bernstein works.
Encrypted, versioned storage: To prevent the file-mismatch problem, Bernstein pairs time-stamping with zero-knowledge encrypted storage. Files are encrypted client-side before upload, preserving the exact bit-for-bit originals needed to verify certificates years down the line. Studios can export certificates and verification materials for independent validation. They must retain the corresponding original files and the keys needed to access any encrypted copies.
Secure sharing for pitches and milestones: When sending confidential builds, design documents, or pitch decks to publishers and external partners, Bernstein Secure Sharing links access directly to a certified version. It verifies control of the designated recipient email address, can require acceptance of your NDA before unlocking files, and logs download events.
Complementary to legal advice: Bernstein provides the technical evidence trail - records of existence, integrity, and disclosure. It does not replace contracts or legal advice, but gives your lawyers and publishers verifiable records to assess alongside the agreements and other evidence supporting ownership.

Sources

David Greenspan, S. Gregory Boyd and Jas Purewal. Video Games and IP: A Global Perspective. 30 April 2014
U.S. Copyright Office. What Does Copyright Protect?. Accessed 6 November 2026
World Intellectual Property Organization. Mastering the Game. Discussion of employees and independent contractors, p. 248.

What is Bitcoin anchoring, and how does it work?

Marco Barulli — Thu, 05 Nov 2026 00:00:00 GMT

Updated: 2026-11-05

Bitcoin anchoring connects a cryptographic fingerprint of your files to a transaction recorded on the Bitcoin blockchain. It provides evidence that the corresponding data existed by the time the transaction was included in a block, without publishing the files themselves. Verification requires both the blockchain record and the proof explaining how the files are connected to it.

How does a file become connected to Bitcoin?

The starting point is a cryptographic hash: a fingerprint calculated from the file on your computer. An anchoring protocol defines how that fingerprint becomes part of a Bitcoin transaction.

The connection need not be a readable copy of the hash inside the transaction. A protocol may combine several fingerprints into a single value, or use a fingerprint to derive a cryptographic key or Bitcoin address. In each case, it must be possible to reproduce the steps connecting the original files to the recorded transaction.

The transaction is submitted to the Bitcoin network. Once a miner includes it in a block accepted by the network, it becomes part of Bitcoin’s public transaction history. Merely submitting a transaction is not the same as having it confirmed in a block.

Why use Bitcoin’s public record?

Bitcoin provides a public record that can be checked independently of the service that arranged the anchor and is exceptionally resistant to alteration once well confirmed. For someone preserving evidence of their work, this means a complete proof can remain verifiable even if the original provider closes or stops offering verification.

That independence comes from the way the record is maintained. Bitcoin’s transaction history is stored and independently checked by many thousands of computers, called nodes, distributed around the world. It does not depend on any single provider or location remaining available.

Its resistance to alteration comes from the links between blocks and the computational work securing them. Each block is cryptographically linked to the previous one. Changing an older transaction would require rebuilding the affected chain and overcoming the network’s accumulated proof of work. Each additional block adds a confirmation and increases the work needed. For a transaction buried sufficiently deep in Bitcoin’s blockchain, rewriting that history is computationally infeasible in practice under current network conditions.

What does the date establish?

With a valid connection from the files to a confirmed transaction, the anchor supports the conclusion that the corresponding data existed by the time of the block’s inclusion. It does not tell you when the work first began or when the file was originally created.

Bitcoin targets an average interval of about ten minutes between blocks, although individual intervals can be shorter or longer. This gives a sense of the record’s time granularity, rather than a guarantee of ten-minute timestamp accuracy.

The block’s displayed date and time also need care. Bitcoin block times are supplied by miners and checked against protocol limits; they are not precise readings from a trusted civil-time clock. An anchor should therefore not be described as proving existence at an exact second. The distinction matters when comparing Bitcoin anchoring with timestamps issued by a timestamp authority.

For the broader distinction between evidence of existence and claims about authorship or ownership, see what a digital timestamp establishes.

Are the files published on the blockchain?

No. In Bitcoin anchoring, the transaction records the file’s cryptographic fingerprint or a value derived from it, such as a combined hash or a Bitcoin address. It does not contain the original document, design or source code.

The public record provides the cryptographic link used to verify the anchor, not a readable or recoverable copy of the work. Anchoring therefore does not publish the file’s contents, and the blockchain cannot be used to reconstruct a missing or altered file. You must preserve the original files alongside the proof connecting them to the transaction.

What do you need to verify an anchor later?

Bitcoin defines how transactions and blocks are validated, but there is no single universally adopted protocol for connecting files to those transactions. Keep the evidence required by the particular anchoring method:

The exact files covered by the record, including any manifest or accompanying file used to calculate the fingerprint.
The complete connecting proof, such as the sequence of hashes, a Merkle path, or the public keys and address-derivation details required by the protocol.
The transaction reference and protocol documentation, including the version used.

A transaction ID locates a blockchain record. On its own, it does not explain which files that record covers. The reviewer must calculate the fingerprints, reproduce the connection and check the transaction’s inclusion in the blockchain. See independent verification for the difference between checking that evidence and relying on a provider’s confirmation.

Sources

Satoshi Nakamoto. Bitcoin: A Peer-to-Peer Electronic Cash System. Sections 3–5 and 11: timestamping, proof of work, the network and resistance to rewriting confirmed history. 2008. Accessed 5 November 2026
Bitcoin Developer Documentation. Block Chain — Developer Guide. Transaction inclusion, linked blocks, proof of work and consensus. Accessed 5 November 2026
Bitcoin Developer Documentation. Block Chain — Reference. Block headers and the validation constraints on miner-supplied block times. Accessed 5 November 2026
BTC Nodes. Reachable Bitcoin Nodes. Network snapshot reporting approximately 19,000 reachable nodes, distributed across countries; reachable nodes are not a count of every node. Accessed 5 November 2026

How does client-side encryption protect confidential files?

Marco Barulli — Thu, 05 Nov 2026 00:00:00 GMT

Updated: 2026-11-05

Client-side encryption encrypts a file on your device before it is uploaded. The server receives encrypted data rather than readable contents. If the provider cannot obtain the decryption keys, it cannot read the stored files. This helps protect confidential work while using online storage, but its effectiveness depends on key management, the software performing the encryption and the security of your device.

What happens before the file reaches the server?

“Client-side” means that the operation happens on your computer or other device. The software uses an encryption key to turn the readable file into encrypted data, often called ciphertext. That encrypted version is uploaded. To read it again, authorised software needs the corresponding decryption key.

For example, a company might store an unpublished manufacturing process with an online service. With correctly implemented client-side encryption and keys unavailable to the provider, access to the stored encrypted file alone would not reveal the process.

Can the encryption happen directly in the browser?

Yes. A web application can encrypt files locally using the browser’s built-in cryptographic capabilities, without requiring a separate desktop application or plugin. The browser is running on your device: using a website does not mean that every operation happens on its server.

The W3C’s Web Cryptography API defines interfaces for encryption and decryption, key generation, hashing and digital signatures. For example, an application can use AES-GCM to encrypt a file and detect alterations to the encrypted data. The application passes the file data to the browser’s cryptographic implementation, then uploads the encrypted result.

These capabilities provide the building blocks; the application decides how to use them and what to send to the server. Using Web Crypto does not by itself guarantee that readable files or keys never leave the device. That depends on the application’s code, key handling and security design.

The W3C Security Interest Group’s Cryptography usage in Web Standards provides complementary guidance on choosing algorithms and using them correctly. It is currently a draft guidance document, rather than the specification defining the browser API.

How is client-side encryption different from a secure connection or encrypted storage?

A service may protect the connection used to upload a file, encrypt the file once it reaches its servers, or encrypt it on your device before upload. These are three distinct protections, and a service can use all three together. To understand what each protects, consider where encryption happens and who can access the readable contents:

Encryption in transit, such as HTTPS, protects data as it travels between your device and the server. The server can still receive and process readable contents when that connection ends.
Server-side encryption at rest protects the stored data. If the provider’s systems control the keys, they can decrypt it when needed to deliver the service.
Client-side encryption protects the contents before upload. With keys kept outside the provider’s control, the contents remain unreadable to its servers even after the upload finishes.

The protections can be combined. The important distinction is not simply whether a service says “encrypted”, but where encryption happens and who can decrypt the result.

Why does control of the keys matter?

Encrypting a file locally provides little protection from the storage provider if the provider also receives an accessible copy of the key. Ask who can obtain or use the decryption keys: you, a recipient, an organisation administrator, a separate key service, or the storage provider itself.

Exclusive control also means taking responsibility for the keys. If only you can decrypt the files, you must keep the keys and recovery material secure and available when needed. Letting a provider or administrator recover access for you can be convenient, but if they can decrypt the files without your involvement, your control is no longer exclusive. The tradeoff is between the convenience of delegated recovery and the responsibility that comes with keeping access entirely under your control.

Recovery arrangements matter too. A service may let you reset your login password without being able to recover your encrypted files. Check how recovery works before relying on the service, and preserve the recovery material securely. Losing every usable key and recovery route can make the files inaccessible even if the encrypted copies are safely stored.

What does client-side encryption leave exposed?

The protection applies to the data that is actually encrypted. Depending on the implementation, filenames, file sizes, account details or access records may remain visible. A confidential project name can reveal information even when the document contents are unreadable.

It also does not protect a readable file from malware already running on your device, or prevent an authorised recipient from copying what they can open. The encryption software itself must be trustworthy. Device security, recipient selection and access controls remain part of protecting the work.

Sources

World Wide Web Consortium (W3C). Web Cryptography API. W3C Recommendation; sections 2.3, 6 and 14: cloud storage, security considerations and browser cryptographic operations. 26 January 2017. Accessed 5 November 2026
W3C Security Interest Group. Cryptography usage in Web Standards. Group Note Draft (work in progress): guidance on algorithm selection, key management and authenticated encryption. 29 January 2026. Accessed 5 November 2026
Canadian Centre for Cyber Security. Guidance on Cloud Service Cryptography. ITSP.50.106, sections 2.2 and 3.3: encryption in transit and at rest, and control of cloud encryption keys. 20 May 2020. Accessed 5 November 2026
Elaine Barker, National Institute of Standards and Technology. Recommendation for Key Management: Part 1 – General. NIST SP 800-57 Part 1 Rev. 5; protection of keying material and Appendix B on key recovery. May 2020. Accessed 5 November 2026
Andrew Paverd et al.. OmniShare: Securely Accessing Encrypted Cloud Storage from Multiple Authorized Devices. Academic research on client-side encryption, key distribution and access from authorised devices; arXiv:1511.02119v3. 29 December 2016. Accessed 5 November 2026

What evidence should an architect preserve before submitting a proposal to a competition?

Marco Barulli — Thu, 05 Nov 2026 00:00:00 GMT

Updated: 2026-11-05

Keep a record of how your design developed, the exact files submitted and the uses permitted by the competition terms. Timestamp important design stages and the final submission package, and retain the organiser’s receipt. Together, these records help you show what your studio created, what the organiser received and what it was allowed to do with the proposal.

Preserve the choices that make the design yours

If an unsuccessful proposal later appears in another practice’s project, the final presentation may not tell the whole story. Earlier sketches, plans and models can show how your studio developed the disputed features before submitting them.

Keep the stages that explain significant choices: the first study of a façade, alternative layouts or the revisions that resolved a circulation problem. Retain editable drawings and models alongside readable exports. Identify the people responsible for the work and keep the agreements covering consultants’ drawings, visualisations and other contributions.

Record what submitting allows the organiser to do

Save the brief, competition rules and intellectual property terms, including amendments and written clarifications. Permission to assess a proposal, exhibit its images and develop it into a building are different things. Establish what is allowed for unsuccessful entries and what would require a separate agreement with your studio.

RIBA identifies copyright protection and clear post-competition commitments as principles of its managed competitions. Use those questions when reviewing the terms of your own competition, and preserve the answers you receive before entering.

Keep the exact package you submit

A last-minute export can leave the uploaded boards different from the files in your studio’s “final” folder. Set aside the actual submission: boards, reports, forms, supporting files and any archive uploaded to the portal. Connect it to the competition and entry reference.

For an anonymous competition, keep the connection between the entry code and your studio in your private records. Follow the organiser’s rules about names and identifying information in submitted files.

Timestamp the design history and submission

Digital timestamps can provide independently verifiable evidence that specific drawings and models existed by a given time. Create them at important design stages and for the final package before submission. Keep the matching files and certificates so that the dated record can be checked later.

For example, if a distinctive façade treatment later appears in another proposal, an earlier timestamped study can support your account of when that design was already present in your work. The development files and contribution records help explain how it came about.

The submission timestamp and the organiser’s receipt serve complementary purposes: one identifies the dated package you preserved; the other records its delivery. Keep both connected to the same entry.

Preserve the submission confirmation

Save the portal receipt, entry number, file list and recorded submission time. Where possible, download the accepted package and compare it with your preserved copy. If you replace a file before the deadline, retain the confirmation identifying the replacement. Keep correspondence about upload problems or agreed exceptions.

These records can matter even without a copying dispute, for example if there is disagreement over whether a required board was included or a revised proposal arrived in time.

Keep a separate record of any public reveal

If the organiser exhibits your entry, or you publish it in a portfolio, keep a copy of what became public, where and when. Check the competition’s confidentiality and publicity rules first. A private submission to a jury and a public exhibition are different events in the design’s history.

If the proposal includes a potentially patentable technical innovation, such as a new façade assembly system, consult your patent adviser before publishing its details. Public disclosure before filing can affect novelty under Article 54 of the European Patent Convention.

Before You Submit: How to Protect Your Architectural Work examines the concern behind these precautions: a studio shares a proposal to win work, then finds its design being used without the commission it expected. It explains why the design history, submission records and permitted uses need to be considered together.

Sources

Royal Institute of British Architects. Why enter a RIBA Competition. Best-practice principles for RIBA-managed competitions, including briefs, copyright and promotional uses. Not a statement of every competition’s terms.. Accessed 5 November 2026
European Patent Office. European Patent Convention, Article 54 — Novelty. Article 54(2): information made available to the public before filing forms part of the state of the art.. Accessed 5 November 2026

What evidence should I preserve before sharing a pitch deck, prototype or technical document?

Marco Barulli — Thu, 05 Nov 2026 00:00:00 GMT

Updated: 2026-11-05

Keep the exact version you intend to disclose, supporting records of its development, and the terms governing the exchange. Identify the recipient and purpose before sharing; afterwards, retain the delivery or access records. If you timestamp the material, preserve the matching files and verification data. A dated copy helps establish what existed, but does not itself establish receipt, ownership or confidentiality.

Preserve the version that will actually leave your hands

Set aside a copy of the final sharing package before sending it. Include the deck, attachments, technical drawings and any supporting document the recipient will receive. Give the package a reference that also appears in your covering message.

Keep editable source files separately from the exported presentation. Both can matter: the export shows what you disclosed, while the source and earlier revisions help explain how it developed. If you remove confidential slides for an introductory meeting, preserve that shorter deck as its own version rather than assuming the full deck records the disclosure.

For a physical prototype, keep photographs, identifying marks, relevant drawings and a description of its condition and capabilities. Record what the recipient may handle or inspect. A photograph documents a view of the object; it cannot establish every feature of the prototype or what a live demonstration revealed.

Keep enough history to explain the work

Retain the earlier records that explain important choices: a sketch, test result, design revision or contribution note. Connect them to the people involved and the agreements relevant to their work. You do not need to send this whole history to the recipient.

A timestamp can support the chronology of a preserved file. As RFC 3161 explains, the underlying assertion concerns data existing before a particular time. It does not establish who created that data or whether its statements are correct.

Keep certified originals separate from everyday working copies. The article Your certificate is immutable. Your files are not. explains why preserving the exact bytes matters even when two documents look identical.

Decide the terms before disclosing the detail

Record the intended recipient, their organisation and the purpose of the exchange. Keep the applicable NDA or other terms, including the version agreed and the record of agreement. Check whether the recipient can involve colleagues or advisers and whether oral disclosures need written confirmation.

The UK Intellectual Property Office’s NDA guidance recommends defining the permitted purpose and keeping a record of disclosures. The particular agreement and applicable law determine the obligations.

If an investor will not sign an NDA, decide what you can show without one. A limited introductory deck may be enough to start a discussion. Timestamping a detailed deck does not make disclosing its contents confidential. For the wider tension between demonstrating value and revealing know-how, see IP-backed finance and the disclosure paradox.

Where the material includes a potentially patentable invention, resolve the filing and disclosure sequence first. Under Article 54 of the European Patent Convention, public disclosure before filing can affect novelty. A private timestamp does not reserve a patent filing date.

Complete the record after the exchange

Save the sent message, attachments, portal receipt or available access records. For a meeting, note who attended, which version you presented and what additional information you explained or demonstrated. Distinguish notes made immediately afterwards from later recollections.

Record a revised deck, follow-up answer or additional demonstration as a further disclosure. Your record should let someone reconstruct this particular exchange, rather than merely show that a project folder existed.

Sources

UK Intellectual Property Office. Non-disclosure agreements. Sections 2, 4 and 5: defining the permitted purpose, checking signatories and recording disclosures. UK guidance; contract effects depend on applicable law.. Accessed 5 November 2026
C. Adams, P. Cain, D. Pinkas and R. Zuccherato. Internet X.509 Public Key Infrastructure Time-Stamp Protocol. RFC 3161, introduction and section 2: evidence of data existence and verification against a hash.. Accessed 5 November 2026
European Patent Office. European Patent Convention, Article 54 — Novelty. Article 54(2): information made available to the public before filing forms part of the state of the art.. Accessed 5 November 2026

When drafting an NDA, how can I clearly identify the confidential information I want it to cover?

Marco Barulli — Thu, 05 Nov 2026 00:00:00 GMT

Updated: 2026-11-05

Preserve the collection you intend to disclose and use a digital timestamp certificate to give it a verifiable reference. Identify that certificate in the NDA or an annex, and state which certified material the confidentiality obligations cover. This defines a concrete perimeter without reproducing the sensitive contents in the contract. Provide separately for later versions, oral disclosures and the permitted use of the information.

When preparing an NDA for a potential partner, start with the information they will need and the purpose for which they may use it. For example, you might disclose drawings and test results so a manufacturer can assess whether it can produce a component. Describe that purpose and identify the material to which the confidentiality and permitted-use obligations will apply.

Decide how the agreement will identify that information: through a defined collection, specified categories, confidential markings, or a combination. If your discussions will also reveal information through meetings or demonstrations, provide for those disclosures too. The UK Intellectual Property Office’s guidance discusses these choices and the importance of defining the permitted purpose.

The aim is to make it possible for both parties to identify the information concerned, including later if its scope is disputed. A broad phrase such as “our technical know-how” may describe a category, but does little on its own to establish what you actually disclosed.

Prepare the collection the NDA will cover

Gather the drawings, reports, source code, datasets or other files you intend to disclose. Give the collection a name and revision reference, and preserve its exact contents. A dedicated collection is easier to identify than a mixed project archive containing unrelated work.

Identify the collection in the agreement or an attached schedule. Keep a readable file list so both parties can understand what the reference includes.

Use a digital certificate to establish the perimeter

An effective and convenient way to identify that collection of confidential information is to use a digital timestamp certificate, giving the NDA a fixed, verifiable reference. It connects the files’ cryptographic fingerprints to dated evidence, allowing someone with the files and verification data to check that they match the certified record. Here, “certificate” means evidence tied to the contents of the files, not simply a signed statement listing their names.

Certify the collection before disclosure, then identify the certificate in the NDA’s definition of confidential information or attach it as an annex. Make the contractual connection explicit: state that the obligations apply to the information contained in the certified collection, subject to the agreement’s exclusions.

For example, you could certify “Pump evaluation package, revision 2”, comprising drawings, test results and assembly notes. The NDA would identify that package by its certificate reference and state that the information it contains is covered for the agreed evaluation purpose. If a particular drawing is questioned later, the preserved file can be checked against the certificate to establish whether it belongs to that exact collection.

The benefit goes beyond dating the work. The certificate gives both parties a common reference for the perimeter of the information covered, even when the collection contains hundreds of files or technical content that would be difficult to describe precisely in a contract. A new file cannot be silently substituted while still matching the original certified record.

Keep the exact files, certificate and verification data together, and retain the records showing which certified package was supplied to the recipient. The certificate identifies the material; it does not, on its own, establish that it was delivered or that the recipient accepted the NDA.

Keep technical details out of the contract itself

You do not need to reproduce formulas, source code or detailed drawings in the NDA merely to identify them. The agreement can refer to a preserved collection while its contents remain in controlled storage. This is useful when the contract will circulate among people who need to review its terms but do not need the underlying know-how.

WIPO’s guidance on collaborative innovation discusses identifying background know-how through titles or reference numbers while controlling access to the information itself.

Make sure the reference can be followed when necessary: an authorised reviewer should be able to retrieve the material and check that it matches the collection identified in the agreement.

Plan for information you will disclose later

A collaboration rarely stops at the first package. When drafting the NDA, decide how it will cover revised drawings, additional results and information explained in meetings. Agree a workable process for identifying these additions, including any marking or written-confirmation requirements.

For example, the agreement might expressly cover later certified versions of the same collection when the new certificate and corresponding material are supplied to the recipient. Alternatively, it might require an agreed update to its schedule. Define the process in advance, including how additions are identified and notified. Preserve earlier disclosed versions too: removing information from a later package should not leave its continuing treatment unclear.

The article on employee NDAs and confidential knowledge illustrates how references can remain connected to an evolving body of information, from onboarding through project work to departure.

Preserve the agreement and the actual disclosures together

Once the terms are agreed, keep the executed NDA, its schedules and amendments with the referenced collections. For each exchange, retain the covering message, the version supplied and available delivery or access records. Preserve earlier packages even when newer versions replace them.

Together, these records connect what you intended the NDA to cover with what you actually shared. Precise identification supports that connection; it does not remove the agreement’s exclusions, make every item a trade secret or establish that a breach occurred.

Sources

UK Intellectual Property Office. Non-disclosure agreements. Sections 2, 4 and 5: defining the permitted purpose, checking signatories and recording disclosures. UK guidance; contract effects depend on applicable law.. Accessed 5 November 2026
World Intellectual Property Organization. WIPO Guide to Trade Secrets and Innovation — Part VI. Sections 2.2–2.5 and 3: background information, collaborative results and academic partners.. Accessed 5 November 2026
C. Adams, P. Cain, D. Pinkas and R. Zuccherato. Internet X.509 Public Key Infrastructure Time-Stamp Protocol. RFC 3161, introduction and sections 2.1–2.2: timestamping a hash and checking the corresponding data imprint.. Accessed 5 November 2026

Can one timestamp cover several files?

Marco Barulli — Thu, 05 Nov 2026 00:00:00 GMT

Updated: 2026-11-05

Yes. Several files can be represented by one combined cryptographic fingerprint, which is then timestamped. Each file is connected to that fingerprint through a reproducible calculation. The timestamp provides evidence that the covered versions existed by the recorded time; it does not mean they were all created together. To verify the record later, keep the files and the evidence needed to reproduce their connection to the timestamp.

How can one fingerprint represent several files?

A timestamp binds a cryptographic fingerprint to a time. The data represented by that fingerprint can be a single file or a collection. There are several ways to construct it:

An archive: put the files into a ZIP or another archive and timestamp the archive’s fingerprint. Verification starts with that exact archive, so preserve it rather than relying on recreating it later.
A list of file fingerprints: calculate each file’s hash, then combine the hashes using a defined order and format and hash the result. A manifest can also record filenames and other context, provided the manifest itself is covered by the timestamp.
A hash tree, often called a Merkle tree: combine file fingerprints in successive layers until one final fingerprint remains. That final value represents the collection, while a supporting proof can connect an individual file to it.

The method must be documented so an independent reviewer can repeat the calculation. Simply listing filenames on a certificate does not cryptographically connect their contents to the timestamp.

What does the shared date tell you?

It provides a common point by which the covered versions existed. For example, a design drawing, a prototype photograph and a test report can be included in one dated record of a development milestone, even if they were produced on different days.

The shared timestamp does not establish the order in which those files were created or prove that they belong to the same development process. Preserve the descriptions, revision references and other context that explain their relationship. If the sequence matters, create dated records at successive milestones rather than relying only on a final collection.

That depends on the method and the proof you retain. A Merkle-tree proof can provide the intermediate hashes needed to connect one file to the timestamped value without disclosing the other files. RFC 4998 describes this approach for evidence records.

With other methods, verification may require the original archive, the complete manifest or the other file fingerprints. Check the actual verification procedure before assuming you can disclose only one file. A certificate covering a collection does not automatically provide a separate, self-contained proof for each item.

What happens when you add or change a file?

The existing timestamp continues to cover the original set of file versions. It does not extend to a later addition or an edited version merely because the file sits in the same project or folder.

Create a new timestamp for the updated collection and retain the earlier version with its proof. This produces a sequence of dated records while preserving the ability to verify each milestone on its own.

What should you keep with the timestamp?

Keep the exact files or archive that were covered, the timestamp proof, and the instructions and supporting data needed to reproduce the combined fingerprint. Depending on the method, this may include a manifest, the ordering rules or an individual file’s Merkle proof.

Test the exported evidence before relying on it. A missing file or a missing step in the connecting proof can prevent verification even when the timestamp itself remains valid. See which files and context to keep alongside a timestamp certificate for the broader evidence package.

Sources

Tobias Gondrom, Ralf Brandner and Ulrich Pordesch. RFC 4998: Evidence Record Syntax (ERS). Sections 4.2 and 4.3: hash trees, reduced hash trees and verification of data covered by an archive timestamp. August 2007. Accessed 5 November 2026
C. Adams, P. Cain, D. Pinkas and R. Zuccherato. RFC 3161: Internet X.509 Public Key Infrastructure Time-Stamp Protocol. Timestamping a message imprint rather than the underlying data; updated by RFC 5816. August 2001. Accessed 5 November 2026

How does an EU qualified electronic timestamp differ from a blockchain timestamp?

Marco Barulli — Thu, 05 Nov 2026 00:00:00 GMT

Updated: 2026-11-05

A qualified electronic timestamp is issued through a qualified trust service under the EU’s eIDAS rules, using an accurate time source linked to Coordinated Universal Time (UTC). It benefits from a legal presumption of accurate date and time and integrity of the linked data. A blockchain timestamp connects a file’s fingerprint to a blockchain record, with verification based on the anchoring protocol and the blockchain’s rules. Depending on its design, the anchoring protocol can also link that record to a user-controlled cryptographic key. The two approaches can complement each other.

What does “qualified” mean?

This answer focuses on the EU’s eIDAS framework. Other jurisdictions have their own rules for timestamping services and evidence, with different requirements and legal effects; the EU’s qualified status should not be assumed to apply elsewhere.

“Qualified” is a defined status under EU law, not a general description of technical quality. A qualified electronic timestamp must meet the eIDAS requirements, including binding the data to an accurate UTC-linked time and being signed or sealed by a qualified trust service provider, or protected by an equivalent method.

The provider and the particular timestamping service must be listed as qualified in an EU national trusted list. A provider offering one qualified service does not automatically make all its products qualified. The European Commission’s trusted-list guidance explains how to check this status.

Similarly, using the standard RFC 3161 timestamp format does not by itself make a timestamp qualified. The format describes how the cryptographic evidence is structured; qualification also depends on the service’s regulatory status and operation.

Where does the time come from?

With a qualified timestamp, the authority binds the file’s fingerprint to a time from an accurate source linked to UTC. The authority signs the resulting evidence, so a reviewer can check who issued it and whether the signed information has been altered.

With a blockchain timestamp, the fingerprint is connected to a transaction or other record according to an anchoring protocol. The meaning and precision of its time depend on the blockchain used. In Bitcoin, blocks arrive about ten minutes apart on average, and their times are supplied by miners subject to protocol limits. This is different from an authority’s UTC-linked clock; it should not be presented as equivalent precision.

For the mechanics of connecting files to that public record, see Bitcoin anchoring.

What difference does qualification make legally?

Under Article 41 of eIDAS, a qualified timestamp benefits from a presumption that its date and time are accurate and that the linked data has integrity. A qualified timestamp issued in one EU Member State is recognised as qualified throughout the EU.

A non-qualified electronic timestamp cannot be denied legal effect or admissibility solely because it is electronic or lacks qualified status. Blockchain anchoring alone does not confer the qualified timestamp’s specific presumptions. Its evidential weight still needs to be assessed in context.

A growing body of case law and legislation supports the use of blockchain records as evidence across different jurisdictions. The working paper Blockchain Evidence in Court: A Cross-Jurisdictional Study of Admissibility and Weight, by Bernstein’s co-founders Marco Barulli and Paul Reboh, surveys developments in more than thirty jurisdictions. It distinguishes acceptance of a record as evidence from the weight a court gives it: the applicable rules, the reliability of the proof and the surrounding evidence still matter.

Neither approach automatically establishes authorship, ownership or an IP right. Those are separate questions from whether particular data existed at a given time.

Can the record also link the files to a particular person?

Yes, if the protocol includes that link. An anchoring protocol can bind the file’s fingerprint to a user’s public key. A signature made with the corresponding private key demonstrates control of that key. If the user signs the anchoring record before it is timestamped, the dated evidence also covers that signature.

This adds a connection between the work and the key holder to the evidence of existence. When the key is reliably linked to a person or organisation, that connection can support an authorship or ownership claim alongside development records, agreements and other evidence. It is a feature of the particular protocol, rather than something every blockchain timestamp provides.

For example, OpenTimestamps provides proof that data existed before a certain time, but its timestamp proof does not itself identify the requester or bind the record to an owner’s public key. That attribution must be supplied separately, for example by timestamping a digitally signed document. OpenTimestamps alone therefore does not provide the user-key link described above.

The distinction is between control of the key and possession of the file: signing a fingerprint alone does not prove that the signer had the underlying file at that time, or has retained it continuously since. Nor does it establish that the signer created the work or owns its rights.

A qualified timestamp on a file’s fingerprint alone does not identify the person presenting the file either. It can, however, cover a document already signed by that person. Linking the work to a user and establishing its date are complementary functions that can be combined with either timestamping approach.

Can both be verified independently?

Yes, provided the necessary evidence is available. Independence means being able to check the proof outside the platform that supplied it; it does not mean that both methods rely on the same sources of trust.

For an authority-issued timestamp, the reviewer checks the file’s fingerprint against the timestamp token, verifies the authority’s digital signature and certificate chain, and examines the relevant certificate-status information. Where qualified status matters, the reviewer also checks the service’s status at issuance using trusted-list information. The check relies on the authority’s certified identity and its timekeeping obligations, but need not rely on a “Valid” badge on its website.

For a blockchain timestamp, the reviewer reproduces the connection from the file’s fingerprint to the blockchain record and verifies that record against the chain. This relies on the anchoring protocol, the blockchain’s consensus rules and the blockchain data used for verification.

In either case, keep the complete evidence needed for independent verification, rather than only a screenshot or a link to an online certificate.

Why use both for the same files?

The two records address different needs. A qualified timestamp supplies an authority-attested time with a defined EU legal status. A public-blockchain anchor supplies a separately verifiable record secured by the blockchain’s network.

Their relative evidential weight can also change across jurisdictions. Outside the EU, a qualified timestamp does not automatically carry the presumptions it enjoys under eIDAS. Depending on local rules and the evidence presented, a court could give a well-supported, independently verified Bitcoin anchor greater weight than an EU qualified timestamp. Neither method is universally stronger in court; retaining both provides different grounds on which to establish the dated record.

Sources

European Parliament and Council. Regulation (EU) No 910/2014 — eIDAS. Articles 41 and 42: legal effects and requirements for electronic timestamps. 23 July 2014. Accessed 5 November 2026
European Commission. Questions & Answers on Trust Services under the European Digital Identity Regulation. Electronic timestamps: the 2024 revision leaves the existing timestamp provisions unchanged. Accessed 5 November 2026
European Commission. List of qualified trust service providers in the EU. Qualification of providers and individual services through national trusted lists. Accessed 5 November 2026
C. Adams, P. Cain, D. Pinkas and R. Zuccherato. RFC 3161: Internet X.509 Public Key Infrastructure Time-Stamp Protocol. Timestamp tokens, message imprints, authority signatures and verification; updated by RFC 5816. August 2001. Accessed 5 November 2026
Bitcoin Developer Documentation. Block Chain — Reference. Block headers, transaction commitments and miner-supplied time. Accessed 5 November 2026
Marco Barulli and Paul Reboh. Blockchain Evidence in Court: A Cross-Jurisdictional Study of Admissibility and Weight. Working paper, version 3; comparative survey of more than thirty jurisdictions; authors are Bernstein’s co-founders. 1 October 2026. Accessed 5 November 2026
OpenTimestamps. OpenTimestamps — How it Works. Proof of prior existence and public calendar services that require no registration. Accessed 5 November 2026

How can I document who received confidential material and which terms they accepted?

Marco Barulli — Thu, 05 Nov 2026 00:00:00 GMT

Updated: 2026-11-05

Keep a disclosure record linking the exact material to the intended recipient, the applicable terms and the evidence of acceptance. Preserve the terms as they appeared at the time, alongside signatures, acknowledgements or recorded acceptance events. Retain delivery and access records separately: an invitation, a download and acceptance describe different events, and none alone establishes the recipient’s identity, authority or subsequent conduct.

Make one record for each disclosure

Give each exchange a reference and connect it to the material shared. Record the recipient’s name, organisation, role and contact address, together with the purpose, date, channel and exact file or collection revision.

Record separately what was offered and what the evidence shows happened. An email sent with an attachment, an invitation to a file portal and a logged download are different records. If several people need access, keep their individual records rather than treating one person’s activity as evidence for the whole group.

WIPO’s trade-secret management guidance treats contractual restrictions and access controls as complementary measures when information goes outside an organisation. A practical disclosure record connects those measures to a particular exchange.

Preserve the terms the recipient actually saw

Keep a fixed copy of the relevant NDA, confidentiality notice or sharing terms. Link it to the package and to the acceptance record. Saving only a webpage address is insufficient if the wording at that address can later change.

For a signed agreement, retain the executed document and any associated signature records. For acceptance through a portal, retain the terms version, the account or address involved, the event time and the recorded action. Also keep the invitation or covering message explaining why the recipient was asked to accept.

For example, if a technical adviser accepts terms before downloading revision 3, preserve that sequence. Do not later attach revision 4 or a rewritten set of terms to the same event and imply those were what the adviser accepted.

Check who is acting for the recipient organisation

A company email address helps connect an exchange to an organisation, but does not automatically establish authority to bind it. The UK Intellectual Property Office’s NDA guidance advises checking that the person signing has the necessary authority.

Where this matters, keep the relevant role confirmation or correspondence. An email verification code records access to a mailbox; it is not, by itself, a full identity check. Shared mailboxes and forwarded messages can make individual attribution less certain. Describe the evidence at the level it supports.

Explain what each event means

An invitation shows that access was offered. A delivery record may support receipt by a system. A view or download event records activity attributed to an account or session. Acceptance records an action relating to particular terms. These do not necessarily establish that the person read every document, understood the terms or complied with them afterwards.

If no access confirmation is available, say so. A subsequent reply discussing a drawing may be useful corroboration; silence is not confirmation of receipt or agreement. Retain the original messages and available logs, not only a summary you typed later.

Keep later access changes traceable

Record further recipients, new disclosures, revised terms and the ending of access. Withdrawal of online access does not retrieve files already downloaded or information already learned. Handle return, deletion and any permitted retention under the relevant agreement, preserving acknowledgements without presenting them as proof that every copy has disappeared.

Keep the record in controlled storage with the files and agreements it describes. Limit personal data to what is needed and set retention arrangements appropriate to the relationship. The employee NDA article illustrates why the connection between material, terms and recipients needs to survive personnel changes.

Use digital services to record the exchange

Digital services can help record what you shared, with whom and when. Registered email services, such as REM services in Europe and IncaMail in Switzerland, provide receipts documenting delivery events. Controlled file-sharing services can also record access to a specific version and require acceptance of confidentiality terms before opening it. Keep these records alongside the exact files and terms involved.

But recording a disclosure must not compromise the secret itself. Exposing confidential material to unintended recipients or unnecessary intermediaries can put its secrecy and trade-secret protection at risk. For sharing trade-secret material, our recommendation is to use only end-to-end encrypted services, so the contents are readable by the intended parties rather than the service provider. A delivery receipt or a “certified email” label does not itself guarantee that protection: check how the particular service handles encryption and access.

Share only what the recipient needs, under the agreed terms. Encryption protects the exchange; the recipient’s handling of the information still matters afterwards.

Sources

UK Intellectual Property Office. Non-disclosure agreements. Sections 2, 4 and 5: defining the permitted purpose, checking signatories and recording disclosures. UK guidance; contract effects depend on applicable law.. Accessed 5 November 2026
World Intellectual Property Organization. WIPO Guide to Trade Secrets and Innovation — Part IV. Sections 2.3 and 3.2–3.3: confidentiality measures and sharing information with external parties.. Accessed 5 November 2026
ETSI. Registered Electronic Mail (REM) Services — Framework and architecture. EN 319 532-1: REM services and evidence of the message delivery process.. Accessed 5 November 2026
Swiss Post. Electronic registered mail with IncaMail. Registered dispatch, signed receipts and acceptance, refusal or expiry status.. Accessed 5 November 2026

What records should I keep when sharing designs or specifications with a manufacturer?

Marco Barulli — Thu, 05 Nov 2026 00:00:00 GMT

Updated: 2026-11-05

Keep the exact drawings, specifications and samples supplied, the terms governing their use, and records of delivery and acknowledgement. Preserve each revision, the manufacturer’s proposed changes and your approvals separately. Identify any subcontractors allowed to receive the material. Distinguish your original design from the supplier’s contributions, and keep the agreements addressing those contributions, tooling and production permissions.

Separate quotation, sampling and production

A supplier may need different information at each stage. Record what each package is for: estimating cost, making a prototype, testing a process or producing an agreed order. Do not rely on a file named “final” to explain which stage it authorises.

For each package, preserve the exact drawings, CAD exports, patterns, tolerances, bills of materials and specifications you provide. Include referenced attachments and identify their revisions. Keep the covering message, the recipient details and any acknowledgement connecting that supplier to that package.

For physical samples, assign an identifier and retain photographs, measurements and dispatch or handover records. If a sample changes, record the change and its relationship to the relevant drawing. A photograph of a sample is useful context, but is not a substitute for records of dimensions, materials or functional tests.

Connect the package to its permitted use

Keep the NDA and the relevant quotation, development or manufacturing agreement. Record the purpose for which the supplier can use the material and the conditions for involving another factory, subcontractor or consultant.

WIPO’s guidance on external sharing specifically includes manufacturing and outsourced work. Its general recommendation is to combine appropriate agreements with practical measures to protect confidential information.

Preserve written clarifications about matters such as sample quantities, production approval, use of tooling and return or retention of materials. An NDA is not necessarily the document that settles all these issues. If the commercial terms leave an important point open, record the unresolved question before proceeding.

Keep supplier changes and your approvals distinct

Manufacturing often changes a design. A supplier may adjust a seam, alter a mould or propose a different tolerance. Keep the proposal, its author, the reason, the files affected and the decision made.

Suppose a supplier recommends a larger internal radius to avoid cracking. Preserve the original drawing, the supplier’s marked-up proposal, your response and the revised drawing released for production. This makes it possible to distinguish a supplier suggestion from an approved change and from an unauthorised deviation.

Do not treat approval of a technical change as an automatic transfer of rights in it. Keep the contractual provisions and contribution records needed to assess who may use the improvement. WIPO’s collaboration guidance distinguishes pre-existing information from results created during joint work.

Preserve the version history through production

When a revision replaces an earlier package, identify the replacement explicitly and retain the earlier one. Ask the supplier to acknowledge which revision it will use. Connect sample approvals, inspection reports and production orders to that reference rather than to a changing shared folder.

Save evidence of agreed onward disclosures and the records received from subcontractors. At the end of the relationship, document access changes and the agreed handling of drawings, samples, tooling and retained copies. Keep records you are entitled or required to retain; do not assume a termination means everything can immediately be destroyed.

Use digital timestamps at key manufacturing stages

A digital timestamp gives you independently verifiable evidence that particular files existed by a given time. Before sending a design to a manufacturer, timestamp the exact drawings and specifications you intend to share. This establishes a dated reference for the design before the supplier begins working on it, without requiring you to make it public.

Create further timestamped records at meaningful stages: a supplier’s proposed modification, an approved sample or the package released for production. In the example above, the original drawing and the revised drawing with the larger internal radius would each have their own dated record. Keep the supplier’s proposal and your approval connected to the relevant versions.

Retain the exact files and their certificates alongside the messages, acknowledgements and agreements. Together, they help explain which design existed at each stage, which version the manufacturer received and what you authorised. For the underlying mechanism, see What does a digital timestamp establish?.

These records can matter long after production. From first sketch to final collection tells how timestamped design files helped a fashion house win a dispute over copied garments. The evidence was useful because it had been preserved before the dispute arose.

Sources

World Intellectual Property Organization. WIPO Guide to Trade Secrets and Innovation — Part IV. Sections 2.3 and 3.2–3.3: confidentiality measures and sharing information with external parties.. Accessed 5 November 2026
UK Intellectual Property Office. Non-disclosure agreements. Sections 2, 4 and 5: defining the permitted purpose, checking signatories and recording disclosures. UK guidance; contract effects depend on applicable law.. Accessed 5 November 2026
World Intellectual Property Organization. WIPO Guide to Trade Secrets and Innovation — Part VI. Sections 2.2–2.5 and 3: background information, collaborative results and academic partners.. Accessed 5 November 2026

What is the difference between source code escrow and timestamping?

Marco Barulli — Thu, 05 Nov 2026 00:00:00 GMT

Updated: 2026-11-05

Source code escrow arranges for code and supporting materials to be held by an independent agent and released to a customer under agreed conditions, such as the supplier ceasing support. Timestamping provides verifiable evidence that a particular version of the code existed by a recorded time. Escrow addresses future access and continuity; timestamping addresses dated evidence. One does not replace the other, and a project may benefit from both.

What does source code escrow provide?

Escrow gives a software customer an agreed route to obtain source code if specified events occur. The supplier deposits the code and supporting materials with an independent agent. The agreement identifies the beneficiary, the release conditions and the procedure for requesting and disputing release.

Possible triggers include insolvency, discontinuation of maintenance or failure to meet agreed support obligations. The actual contract determines which events count and what happens next; release is not automatic whenever the customer is dissatisfied.

Receiving source code also does not automatically transfer copyright. The relevant agreements must define what the customer may do with the released materials, such as maintaining the application internally or appointing another developer.

What does timestamping provide instead?

Timestamping connects a cryptographic fingerprint of the code to a recorded time. It can provide evidence that the corresponding version existed by that time without publishing the code or giving a customer access to it.

That evidence can help identify a development milestone or distinguish one version from another. It does not establish by itself who wrote the code, who owns it or whether it works. Nor does a timestamp contain a recoverable copy of the source code: you must preserve the files to verify them later.

These benefits are not limited to the author. A supplier, customer or escrow agent can use dated evidence to identify a particular package of materials.

Why is depositing the code not enough for continuity?

A deposit is useful only if it contains what someone needs to take over the software. Source files may be insufficient without build instructions, compatible tools, dependencies, configuration and technical documentation. For a hosted application, restoring service may also require operational data and access to infrastructure.

Verification should therefore match the intended recovery task. Checking that a deposit contains readable files is different from demonstrating that another team can build and run the application in an independent environment. Escrow services offer different levels of testing; the agreement should specify the level required and how often deposits and checks are updated.

Timestamp verification answers a different question: whether the files match the dated proof. A successful cryptographic check does not establish that the deposited software can be rebuilt or operated.

Can timestamping and escrow be used together?

Yes. Timestamping the exact deposit package creates a dated reference for the materials, while escrow provides custody and the contractual release mechanism.

Keep the deposit receipt or acknowledgement linking that package to the escrow agent. A timestamp alone does not prove that the agent received or accepted it. When a new version is deposited, preserve its own proof and receipt so the history of deposits remains clear.

Which do you need?

Start with the problem you need to solve:

You need evidence of a particular software version at a particular time: timestamping can support that record, alongside the files and development context.
You need access to a supplier’s code if support ends: an escrow arrangement can address that contingency, with appropriate release rights and recovery testing.
You need both continuity and a verifiable history of deposited versions: combine the two, making sure each deposit is clearly linked to its dated evidence.

A backup, a timestamp and an escrow agreement perform different jobs. Keeping a copy preserves the material; timestamping adds dated evidence; escrow governs another party’s access under agreed conditions.

Sources

Escode. Negotiating a Software Escrow Agreement: Key Terms and Release Conditions. Primary provider guidance on deposits, release events, permitted use and verification. Accessed 5 November 2026
NCC Group / Escode. Escrow and Verification for Software or Cloud Applications. G-Cloud 14 service definition, published on the UK Digital Marketplace; distinguishes deposit review from build and recovery verification. 2024. Accessed 5 November 2026
Silver Spring Networks. Fast-Start Smart Grid Project Master Agreement — source code escrow agreement. Publicly filed contract, Exhibit 10.15; an example of deposit-update obligations and contractual release provisions, not a universal rule. Accessed 5 November 2026
C. Adams, P. Cain, D. Pinkas and R. Zuccherato. RFC 3161: Internet X.509 Public Key Infrastructure Time-Stamp Protocol. Evidence of prior existence through a timestamped message imprint; updated by RFC 5816. August 2001. Accessed 5 November 2026

How can a university distinguish its existing know-how from work developed during a joint research project?

Marco Barulli — Thu, 05 Nov 2026 00:00:00 GMT

Updated: 2026-11-05

Before the collaboration starts, identify the know-how the university brings and preserve the research records supporting it. Connect this starting record to the collaboration agreement, then document new results and contributions as the work develops. Dated, verifiable versions help distinguish earlier knowledge from later developments; the agreement defines the partners’ rights to use each.

Identify what the university brings to the project

A research partnership may build on years of work already carried out in a university laboratory. Once researchers begin exchanging methods, data and ideas, it becomes harder to separate that earlier knowledge from what the collaboration produces. Make the distinction while the starting point is still clear.

Prepare an inventory of the relevant methods, software, datasets, experimental procedures and materials the university brings. Ask the other partners to do the same. Use descriptions that lead to identifiable records: a particular calibration procedure and its validation data, for example, rather than “the laboratory’s expertise”.

WIPO’s guidance on collaborative innovation distinguishes this background information from results generated during the collaboration. Align the inventory with the agreement’s definitions, including how it treats work developed independently outside the project.

Connect the inventory to evidence and agreed access

For each item, identify the supporting notebooks, reports, code or data, the partner providing it and the person responsible for maintaining it. Record confidentiality restrictions, third-party rights and the agreed uses during and after the project.

Some university records may contain a former sponsor’s information or material licensed for a limited purpose. Have the technology transfer or contracts team resolve those restrictions before promising access to a new partner.

Attach the agreed inventory to the collaboration agreement or give it an explicit reference there. The schedule can identify a confidential method without reproducing the technical detail in paperwork that circulates more widely. Preserve the version the partners agreed and any subsequent changes.

Create a dated reference before the collaboration starts

A digital timestamp can give the supporting files an independently verifiable date while their contents remain private. Certify the collection documenting the university’s relevant know-how before sharing it, then connect that certificate to the background inventory.

This gives you a concrete reference if a partner later questions whether a method existed before the joint project. The preserved files show the method as documented at that point; the certificate supports its prior existence. The agreement records what the partners accepted as background and how it may be used.

Keep the original research records as well as the inventory. Timestamping a list of methods is less informative than preserving the procedures, data and notes that explain them. If work has already begun, retain earlier evidence and clearly identify any account reconstructed afterwards.

For more on identifying confidential collections in agreements, see how to define the information an NDA will cover.

Record what the collaboration adds

As results emerge, retain the experiments, data, software revisions and technical notes behind them. Record who contributed and which earlier methods or materials the result builds on. Create further dated records at meaningful research milestones.

Suppose the university contributes a calibration method and an industrial partner supplies a sensor design. Together, the researchers develop a new correction algorithm. Preserve the original method, the supplied design and the experiments leading to the algorithm, with notes explaining each team’s contributions. This makes the relationship between the starting material and the new result visible.

Ask contributors to check the account while the work is fresh. Keep corrections and unresolved points. These factual records help the technology transfer team assess inventorship and ownership under the relevant law and agreements.

Agree how results may be used and published

At project milestones, review new results against the starting inventory. Identify improvements to existing methods, newly developed work and any classification that needs agreement. Record the decisions about ownership, access and commercial use, including any background rights needed to exploit a result.

The Lambert Toolkit offers examples of how universities and businesses can allocate these rights. Its models are starting points for negotiation under English law; choose and adapt terms for the particular partnership.

Coordinate papers, theses, conference presentations and patent filings through the agreed review process. Keep the version approved for disclosure and the authorisations, so that publication does not inadvertently expose a partner’s confidential method or research awaiting a patent filing.

Leave an institutional record when the project ends

Keep the starting inventory, agreed updates, result records and rights decisions together with their supporting files and certificates. Assign responsibility for them within the institution, so they remain available when a researcher leaves or a later licensing opportunity arises. Record continuing confidentiality, access and retention obligations.

The university should be able to explain both what it brought to the collaboration and what emerged from it, without rebuilding that history from former researchers’ inboxes.

Sources

World Intellectual Property Organization. WIPO Guide to Trade Secrets and Innovation — Part VI. Sections 2.2–2.5 and 3: background information, collaborative results and academic partners.. Accessed 5 November 2026
UK Intellectual Property Office. University and business collaboration agreements: Lambert Toolkit. Model agreements offer different allocations of rights. Starting points for negotiation under English law, not universal ownership rules.. Accessed 5 November 2026

When Institutions Play Startup: The Cautionary Tale and Demise of WIPO PROOF

Marco Barulli — Wed, 04 Nov 2026 00:00:00 GMT

Updated: 2026-11-04

A post-mortem on why a UN agency’s commercial timestamping service collapsed after 20 months, and what it teaches the IP ecosystem about digital evidence.

Migrating from WIPO PROOF?

To ensure your legacy evidence remains permanent and fully protected ahead of the January 2027 sunset, Bernstein is offering an exclusive transition discount and dedicated migration support for former WIPO clients. We’ll help you securely organize your original files and existing tokens into zero-knowledge Bernstein projects. Contact the Bernstein team today.

On May 27, 2020, the World Intellectual Property Organization (WIPO), a specialized agency of the United Nations, stepped outside its traditional multilateral boundaries to launch WIPO PROOF, a commercial digital timestamping service pitched as an impartial “digital notary” for the data economy. Designed to produce cryptographic proof of existence for unregistered intellectual assets—trade secrets, raw data sets, algorithms, and design drafts—the service was billed as an essential digital bridge for global innovation.

Twenty months later, the experiment was over. On January 31, 2022, token generation was halted, and the service was formally decommissioned on February 1, 2022.

The demise of WIPO PROOF is a classic study in institutional mission creep: what happens when an intergovernmental body attempts to operate as a commercial software vendor in a mature, competitive technology market. The service faltered on economic miscalculations, technological commoditization, and legal ambiguities. Ultimately, its closure paved the way for a welcome, disciplined return to core multilateral governance under WIPO’s updated leadership.

The Genesis of an Institutional Mismatch

WIPO PROOF was championed in the twilight of former Director General Francis Gurry’s tenure. The concept appeared visionary on paper: as economic activity shifted from tangible industrial assets to ephemeral digital bits, traditional formal intellectual property registrations (patents, trademarks, industrial designs) felt too slow and expensive for rapid, iterative digital works. WIPO sought to position itself directly in the creative workflow, issuing trusted cryptographic fingerprints that could serve as international evidence of anteriority.

Yet this ambition contained a structural flaw. WIPO’s foundational mandate under its establishing convention is normative and administrative: harmonizing national IP legislation, administering international treaty frameworks like the Patent Cooperation Treaty (PCT) and Madrid System, and providing technical assistance and education. Operating a direct-to-consumer digital utility required an entirely different operational DNA—continuous user acquisition, dynamic software iteration, customer onboarding, API platform engineering, and hyper-competitive pricing. By stepping into the arena of commercial software, an intergovernmental body crossed the line from market facilitator to private-market competitor.

The Commercial Reality: 3,000 Tokens and a Broken Pricing Model

The market’s verdict on WIPO PROOF was swift and unforgiving. During initial feasibility assessments, planners built models anticipating robust enterprise adoption, eyeing volume targets of up to 100,000 tokens annually.

The actual figures disclosed during the 32nd session of WIPO’s Program and Budget Committee told a starkly different story: during its entire first year, WIPO PROOF sold just over 3,000 tokens worldwide. While users registered from 117 countries, adoption was paper-thin.

Metric	WIPO PROOF	Market reality or alternatives
Projected annual sales volume	Baseline: up to 100,000 tokens annually.	Actual sales: just over 3,000 tokens in the first year.
Retail pricing	CHF 20 per single token.	Tens of vendors charging from a few cents to a few euros.
Enterprise bundle pricing	CHF 13 per token when purchasing a bundle of 1,000 tokens.	SaaS flat-rate subscriptions or APIs charging fractions of a cent.
Infrastructure	A centralized RFC 3161 PKI Time Stamping Authority.	Private Qualified Trust Service Providers and decentralized public blockchains.
Statutory legal weight	A standard electronic timestamp, without the eIDAS qualified presumption.	Qualified electronic timestamps carrying a legal presumption across the 27 EU member states.

The primary driver of this commercial failure was an unworkable pricing strategy. WIPO set the price of a single token at 20 Swiss Francs (CHF), offering marginal volume discounts that scaled to CHF 13 per token only if an enterprise committed to purchasing a 1,000-token bundle. This pricing betrayed a fundamental misunderstanding of digital development workflows:

For individual creators and developers, paying CHF 20 each time a software build, CAD revision, or manuscript chapter was updated introduced unsustainable financial and procedural friction.
For R&D enterprises and data science teams, generating thousands of training datasets or iterative code commits per week made a per-token manual fee an operational non-starter.

In the context of WIPO’s broader balance sheet, the product was an irrelevant distraction. WIPO operates on a biennial budget exceeding 790 million Swiss Francs, with more than 95% of its income generated reliably through statutory filing fees from the PCT, Madrid, and Hague systems. WIPO PROOF produced virtually no revenue while consuming ongoing engineering oversight, governance debate, and security compliance costs.

Technical Commoditization and Legal Ambiguities

WIPO PROOF was frequently mischaracterized as a blockchain solution, but it was nothing of the sort. The service relied on standard Public Key Infrastructure (PKI) conforming to the decades-old IETF RFC 3161 protocol. The user’s browser calculated a SHA-256 hash locally, transmitted that hash to WIPO’s servers, and WIPO appended an atomic timestamp signed by its institutional private key to output a .tsr token file.

By offering standard RFC 3161 timestamping, WIPO was attempting to charge a premium for a utility that had long since become a commoditized feature of developer toolchains, operating systems, and commercial document management suites.

Crucially, the service was trapped in an awkward legal position:

Lacking Qualified Legal Presumption: While WIPO attained ISO/IEC 27001 and aligned its procedures with ETSI EN 319 421/422 trust standards, its tokens did not carry the statutory presumption of temporal accuracy and data integrity enjoyed by Qualified Trust Service Providers (QTSPs) under European Union’s eIDAS Regulation. European enterprises needing court-tested certainty could obtain qualified timestamps from domestic QTSPs for a fraction of the cost.
The “Proof of Creation” Mirage: Marketing an electronic timestamp under an intellectual property banner risked confusing unsophisticated creators. Cryptographic timestamps prove possession and integrity of an exact sequence of bytes at a specific date; they do not prove authorship, originality, or ownership. Anyone who illicitly accessed an unreleased codebase or secret design could hash it and receive a genuine WIPO token.
No Substantive Procedural Rights: Unlike formal statutory copyright registration (such as Section 411(a) in the United States) or national administrative envelopes (such as France’s INPI e-Soleau or the Benelux i-DEPOT), a WIPO PROOF token conferred no statutory presumptions, no statutory damages eligibility, and no priority filing date. It was merely private electronic evidence—yet branded with the seal of a UN agency.

The Leadership Course Correction: A Return to Multilateral Focus

The quiet shutdown of WIPO PROOF was not an accident; it was an intentional policy correction. When Daren Tang took office as Director General in late 2020, his administration initiated a comprehensive strategic review during the preparation of WIPO’s Medium-Term Strategic Plan (MTSP) 2022–2026.

Tang articulated a clear, principled vision for the organization’s boundaries. Speaking candidly before intellectual property bodies, including the Chartered Institute of Patent Attorneys (CIPA) Congress, Tang stated directly that WIPO should not be offering services that compete with the private sector.

The new leadership recognized that when an international organization uses its institutional standing and public budget to sell commercial software, it distorts private markets, antagonizes specialized technology providers, and compromises its core identity as an impartial normative body.

At the Program and Budget Committee session in July 2021, the Secretariat reported that market conditions had accelerated rapidly, rendering the continuation of the pilot unviable. Member States ratified the recommendation to end the program during the October 2021 General Assemblies.

Tang’s administration redirected WIPO’s resources where they can deliver authentic, systemic value: administering and modernizing the core international treaty frameworks (PCT, Madrid, Hague), expanding global IP education, training academies, and youth initiatives, and supporting small- and medium-sized enterprises (SMEs) and developing economies in unlocking the value of their intangible assets.

The leadership deserves credit for recognizing an overreach, executing a graceful wind-down, and refocusing WIPO on its essential statutory and educational role.

Lessons for the IP Ecosystem: Where Proof Truly Belongs

WIPO committed to supporting legacy token holders with verification tools through January 31, 2027. Because the service utilized open RFC 3161 standards, existing tokens remain verifiable offline via standard OpenSSL cryptographic utilities using WIPO’s exported public CA certificates. Yet the broader lesson of the WIPO PROOF experiment is unmistakable: institutional centralization is the wrong paradigm for long-term digital proof.

When proof of existence relies on a centralized institutional service, the longevity of that evidence remains vulnerable to changes in administrative policy, budget reallocations, or executive leadership. The moment WIPO discontinued token generation in 2022, private, standards-based timestamping was reaffirmed as the only durable foundation.

For creators, inventors, and enterprises managing valuable trade secrets and code, evidence of creation should never depend on whether an administrative vendor remains in business. Instead, lasting IP defensibility is achieved by anchoring cryptographic commitments to public and reliable blockchains such as Bitcoin, alongside electronic timestamps issued by qualified trust service providers that carry statutory legal value. By pairing immutable, decentralized public ledgers with qualified timestamps, proof of anteriority and integrity becomes permanently verifiable, independent of any operating company, government portal, or intergovernmental organization.

WIPO’s foray into commercial timestamping proved that while digital evidence is vital, building and sustaining that evidence layer belongs in the competitive, standards-driven private market.

Securing Your Legacy Assets Ahead of January 2027

For organizations, inventors, and creative teams holding legacy WIPO PROOF tokens, an important operational date is approaching: January 31, 2027, marks the conclusion of WIPO’s five-year transitional commitment to provide hosted token validation and verification services.

Compounding this transition is a fundamental design reality of the service: WIPO never stored your actual certified data. Files were hashed locally inside the browser and never uploaded to WIPO’s servers. As a result, WIPO held only the .tsr token files, leaving the physical custody and preservation of original source files, design documents, and trade secret datasets entirely to the user. If an original file is lost, altered, or separated from its token, the cryptographic match is broken and the evidentiary chain collapses.

The impending January deadline serves as a timely reminder to audit your archives, consolidate your original assets alongside their tokens, and bring them into an active, resilient environment.

A Permanent Home for Your Evidence:

Bernstein offers the natural destination for this transition:

Centralized Project Workflows: Import your historical files, legacy WIPO tokens, and accompanying documentation directly into structured Bernstein projects, preserving complete evidentiary context across the entire lifecycle of your IP.
Multi-Jurisdictional Legal Defensibility: Besides permanent Bitcoin blockchain anchoring, Bernstein generates at once EU eIDAS qualified electronic timestamps and official Chinese trusted timestamps, providing cryptographic records backed by qualified legal presumptions of temporal accuracy and data integrity across their respective territories.
Decentralized Permanence: Anchor ongoing project iterations to the Bitcoin blockchain, ensuring your proofs of anteriority remain mathematically verifiable forever, completely independent of any institutional website or corporate lifecycle.
Zero-Knowledge Storage: Unlike WIPO’s token-only model that left custody entirely on your shoulders, Bernstein solves the critical vulnerability of asset preservation by securely maintaining your underlying digital files alongside their certificates in an encrypted, versioned vault. Built on a zero-knowledge architecture, all files are encrypted locally in your browser before upload, ensuring your trade secrets, source code, and design files remain accessible exclusively to you.

Sources

WIPO News. WIPO Introduces New Business Service That Provides Evidence of an Intellectual Asset's Existence. May 27, 2020
WIPO Magazine. Introducing WIPO PROOF: an interview with Francis Gurry. June 30, 2020
WIPO News. Discontinuation of the WIPO Proof Token Generation Service. October, 2021
ManagingIP. WIPO Proof to end in 2022 after poor demand. September, 2021
WIPO Magazine. Digital date-and-time-stamping: the evidentiary value and practical significance of WIPO PROOF. January 17, 2021
IP Leaders. WIPO PROOF : Intellectual Property's mark in going digital. May 14, 2021
WIPO. Program of Work and Budget for 2022/23
WIPO. Program and Budget Committee 2021. July 2021
RFC Editor. RFC 3161: Internet X.509 Public Key Infrastructure Time-Stamp Protocol. August 2001

How can I document the contributions of employees, freelancers and research partners?

Marco Barulli — Wed, 04 Nov 2026 00:00:00 GMT

Updated: 2026-11-04

Record who contributed, what they created or changed, when they did it, and which files or other records support that account. Keep the relevant agreements alongside the work, distinguish existing material from new contributions, and ask contributors to check the description while events are fresh. These records help explain involvement; ownership also depends on the applicable law and agreements.

Describe the work each person actually did

A project team list shows who was involved, but rarely explains their contributions. Record the particular work: who proposed a solution, produced a drawing, wrote a software component, designed an experiment or interpreted its results.

For each substantial contribution, keep:

The person’s name, organisation and role at the time.
A description of what they created, changed or decided.
The dates or period of the work, identifying any estimates.
References to the relevant files and versions.
Supporting messages, meeting notes, laboratory records or task discussions.

For example, a prototype record might distinguish the employee who proposed a new mechanism, the freelancer who prepared its detailed drawings and the research partner who tested it. Link each description to the material that supports it. If several people developed something together, describe their interaction and any uncertainty about individual contributions.

Separate existing material from new work

At the start of a collaboration, identify the designs, code, data or methods each participant brings. As work proceeds, record what was added or changed and which earlier material it builds on. Include the source and relevant permissions for third-party material.

For confidential know-how, WIPO’s guidance on collaborative innovation distinguishes information brought into a project from results developed during it, and explains why their treatment should be addressed in the collaboration agreement.

Keep the agreements connected to the contributions

Retain the signed documents that apply to the work and identify the relevant project, period or deliverables. Depending on the relationship, these may include employment terms, a freelancer’s commission, a research agreement, a licence or an assignment of rights. Preserve amendments as well as the original agreement.

Do not infer ownership simply from payment, a job title or a name on a file. For example, the UK Intellectual Property Office’s copyright guidance distinguishes work made in the course of employment from commissioned work and recommends keeping records of creators and contracts. That is a UK copyright example, not a rule for every country or IP right.

The contribution record supplies facts for an ownership review. It does not itself transfer rights or settle who legally qualifies as an author or inventor.

Check the account with the people involved

At a milestone or handover, ask contributors to review the description of their work and the supporting references. Keep their replies, record corrections and mark unresolved points explicitly. Silence should not be recorded as confirmation.

Date later corrections and preserve the earlier account so changes remain traceable. If you reconstruct events after the project, distinguish recollections from records made at the time.

Preserve the record and its supporting files

Keep the contribution notes with the exact file versions they describe, in storage the responsible organisation can maintain after a contributor leaves. Restrict access to confidential material and retain only the personal information needed to explain the work.

An independently verifiable timestamp can strengthen the chronology of the preserved material. RFC 3161 describes evidence of data existence: timestamping a note that names a contributor does not establish that the attribution is true. The underlying work, correspondence and contributor confirmations give that statement its support.

Sources

World Intellectual Property Organization. WIPO Guide to Trade Secrets and Innovation. Part VI, sections 2.2–2.4: distinguishing existing information from collaborative results and agreeing how those results are managed.. Accessed 4 November 2026
UK Intellectual Property Office. Ownership of copyright works. UK-specific guidance on employee and commissioned works, including records of creators and relevant contracts.. Accessed 4 November 2026
C. Adams, P. Cain, D. Pinkas and R. Zuccherato. Internet X.509 Public Key Infrastructure Time-Stamp Protocol. RFC 3161, introduction and section 2: timestamps provide evidence of data existence.. August 2001. Accessed 4 November 2026

What files and supporting information should I preserve alongside a timestamp certificate?

Marco Barulli — Wed, 04 Nov 2026 00:00:00 GMT

Updated: 2026-11-04

Keep the exact files that were certified, the original certificate and its supporting verification data, and a short note identifying the project, version, contributors and reason for certification. Retain relevant agreements and correspondence too. Protect the certified files from changes, maintain backups and test verification. A certificate cannot reconstruct missing files or restore altered ones to their certified state.

Preserve the exact certified version

Keep the files in the form they had when certified. A cryptographic fingerprint depends on the file’s contents, as explained by NIST. A document that looks identical after being opened and saved may contain different bytes and no longer match its certificate.

For examples of how everyday software can alter files without an explicit save, see Your certificate is immutable. Your files are not..

Work on copies when making changes. Keep useful exports or converted formats as additional copies, clearly distinguished from the certified originals. If you certified a ZIP archive, preserve that exact archive: rebuilding a ZIP from the same documents can produce a different file.

Check what the certificate covers. If it refers to a package of files or a manifest listing their fingerprints, retain that structure and the information connecting each file to the certificate. A filename alone is not a reliable identifier of a version.

Keep the verification material, not just a picture of the certificate

Download the original certificate and any accompanying proof files or validation package. A screenshot or printout may show the date and a reference number while omitting the digital data needed to verify them. A PDF may contain useful verification data, so retain the original PDF rather than a scan of it.

The material required depends on the timestamping method. For an RFC 3161 timestamp, verification involves the timestamp token, the file’s fingerprint, the authority’s signature and relevant certificate information. Section 2.2 of RFC 3161 describes those checks. Keep the provider’s export and verification instructions, and check whether further validation material is needed for long-term preservation.

Test the exported package while you still have access to the service. Record when the check was performed, the tool used and its result. This helps the next person repeat the process, although a past successful check does not replace verification of the files presented later.

Explain what the certified material represents

A short note should let someone unfamiliar with the project understand the record. Include:

The project and the version or milestone covered.
What the files contain and why this version was certified.
Who contributed and who prepared the record.
The dates of the work, distinguished from the certification date.
Where the files, certificates and supporting records are stored.

Retain relevant briefs, contracts, contribution confirmations, test results and correspondence. For example, if the certified drawing was sent to a manufacturer, keep the message identifying the delivered version and the terms governing that disclosure. The certificate supports the dated existence of the drawing; those other records help explain its use and significance.

Make the records recoverable

Maintain backups in a separate location and periodically check that you can retrieve the files and verify them. If storage is encrypted, keep recovery information securely under the control of someone responsible for the records. Do not put decryption secrets into a package you routinely share.

Assign responsibility for keeping the records accessible when a contributor leaves or a service account closes. When moving to new storage, check the copied files against their recorded fingerprints. Keep the original certified version even if you also create a newer format for reading it.

A certificate cannot reconstruct a missing file, restore an altered file to its certified version or unlock one whose key is lost. Preserving the files and the means to access them is part of preserving the evidence.

Sources

C. Adams, P. Cain, D. Pinkas and R. Zuccherato. Internet X.509 Public Key Infrastructure Time-Stamp Protocol. RFC 3161, section 2.2: checking the data imprint, signature and timestamp authority's certificate information.. August 2001. Accessed 4 November 2026
National Institute of Standards and Technology. Cryptographic hash function. A file fingerprint depends on its contents; cryptographic hashes support comparison of exact digital data.. Accessed 4 November 2026

Are Git commits enough to document when software was developed?

Marco Barulli — Wed, 04 Nov 2026 00:00:00 GMT

Updated: 2026-11-04

Git commits are useful evidence of how software evolved, but their dates are supplied by users. Hosting the repository on GitHub does not change that. The service can add separate records of pushes and collaboration that help corroborate a timeline. Preserve both, and consider independent timestamps for important versions whose existence by a particular date may need to be demonstrated.

Git records the development, but its dates are supplied by users

A Git repository can show successive versions of code, the changes between them and the explanations recorded in commit messages. A commit’s identifier links to a particular project tree, its parent commits and its metadata, as described in Git’s object model. This makes Git valuable for tracing development.

However, author and committer names and dates can be supplied by the person creating the commit. Git also supports replacing commits through operations such as amend and rebase. Rewriting a commit produces a different identifier; it does not silently alter the original commit under the same identifier. The Git documentation explains these controls.

A signed commit can help connect a commit to a signing key, but the signature alone does not independently establish when the work existed or who wrote every line. Preserve review discussions, task records and release correspondence when they help explain the code’s history.

Does hosting the repository on GitHub make a difference?

The same Git commit has the same identifier and embedded dates in a local repository and in a copy hosted on GitHub. Uploading it does not turn those dates into independently verified creation dates.

What a hosting service can add is a separate record of activity. GitHub’s activity view associates pushes, merges and branch changes with commits and authenticated users. Preserved service records can therefore help corroborate that particular code was present on the service at a particular time. Pull-request discussions and reviews can also help explain contributions and decisions.

For example, a commit may carry a January date but first be pushed to GitHub in March. A record of that March push can support its existence then; it does not independently verify the January date. Nor does the account that pushed the code necessarily identify its author or owner.

Keep useful service records separately from your repository backup. A Git clone does not include the host’s activity logs or review discussions. Retention also varies: GitHub’s Events API returns a limited recent timeline, not a permanent archive of every event.

Public or private matters separately

A hosted repository can be private. Keeping code on GitHub is not automatically the same as publishing it, just as keeping it locally is not by itself a confidentiality policy. Consider who has access, what they may do with the code and the agreements governing their involvement.

Making a repository public lets others access and copy the disclosed code. Changing it back to private does not undo that disclosure: GitHub confirms that existing public forks remain public. If the code contains confidential know-how or a potentially patentable invention, assess disclosure before publishing. WIPO explains that disclosure before filing can destroy patent novelty, subject to the applicable law and any grace period.

You do not need to make a repository public to create a dated record of it. Keep the decision about disclosure separate from the decision about preserving evidence.

Add a dated reference at meaningful milestones

If you need to support that a particular version existed by a particular date, an independent timestamp adds evidence beyond the dates supplied within your working tools. RFC 3161 describes this evidence-of-existence function. It does not establish the date the work first began or validate the authorship claims in the files.

At a release, delivery or important development milestone:

Preserve the source snapshot and record its full commit identifier.
Retain the repository history needed to examine that version, along with relevant reviews, tests and release notes.
Check that the package includes any separately stored material needed to understand the work; a commit identifier alone is not a backup of the code.
Timestamp the package and retain the exact certified bytes, certificate and verification information.

For example, certifying a release archive today can support that the archived code existed by today. It does not independently verify a commit date from six months earlier. The earlier chronology still needs its own supporting records.

Sources

Git project. git-commit documentation. Commit information, --date, --amend and --gpg-sign: configurable metadata, replacement commits and signing.. Accessed 4 November 2026
Scott Chacon and Ben Straub. Pro Git: Git Objects. Commit objects: links to the project tree, parent commits and author/committer metadata.. Accessed 4 November 2026
GitHub. Using the activity view to see changes to a repository. Pushes, merges and branch changes associated with commits and authenticated users.. Accessed 4 November 2026
GitHub. REST API endpoints for events. Event timestamps and the limited retention of the Events API timeline.. Accessed 4 November 2026
GitHub. Setting repository visibility. Public access and the persistence of public forks after a repository becomes private.. Accessed 4 November 2026
World Intellectual Property Organization. How to Protect Inventions through Patents. Public disclosure before filing can destroy novelty; grace periods depend on applicable law.. Accessed 4 November 2026
C. Adams, P. Cain, D. Pinkas and R. Zuccherato. Internet X.509 Public Key Infrastructure Time-Stamp Protocol. RFC 3161, introduction and section 2: evidence of data existence at a particular time.. August 2001. Accessed 4 November 2026

How can I create independently verifiable evidence of confidential work without making it public?

Marco Barulli — Wed, 04 Nov 2026 00:00:00 GMT

Updated: 2026-11-04

Use a service that timestamps a cryptographic fingerprint of your files without publishing their contents. Keep the exact files privately, together with the certificate and verification data. Later, an authorised reviewer can check that the files match the dated record. Independent verification means the evidence can be checked without relying solely on the original service; it does not require public access to your work.

Timestamp a fingerprint while keeping the work private

A cryptographic hash is a digital fingerprint calculated from a file’s contents. It lets someone check whether a file matches a previously recorded fingerprint. A secure hash function is designed to make reconstructing the contents from the fingerprint computationally infeasible, as described by NIST.

A timestamp service can work with that fingerprint instead of the file. For example, RFC 3161 specifies that a timestamp authority processes a hash representation of the data. The resulting token can later be checked against the file without the authority having received its contents.

The hash alone does not establish a date. It needs a verifiable link to the timestamp or other dated record.

Check what leaves your device

Calculating a file’s hash is a straightforward operation that can be performed locally on your computer. There is no need to upload the file to calculate its fingerprint. For timestamping, that fingerprint can be sent to the provider while the file stays on your device.

Check that this is how the service actually works: is the hash calculated locally, or is the file uploaded and hashed on the provider’s server? If the service also stores your files, check whether they are encrypted before upload and who can obtain the decryption keys. The important question is what reaches the server: only a fingerprint, encrypted files, or readable contents.

Also check whether filenames, descriptions or other metadata become visible. A confidential project title can reveal information even when its files remain unreadable.

Keep enough material to verify the record independently

Preserve the exact certified files, their certificates, the supporting verification data and instructions for checking them. If the files are encrypted, retain a secure way to recover the keys as well. A certificate cannot reconstruct a missing file, restore an altered file to its certified version or unlock one whose key is lost.

Test the verification process while the material is available. A reviewer should be able to establish both that the file matches the recorded fingerprint and that the dated evidence is valid. For an RFC 3161 token, this includes checking the timestamp authority’s signature and the relevant certificate information, as set out in section 2.2 of the standard.

Ask whether the checks can be performed with exported material and independent tools, rather than only through your account on the original provider’s website.

Decide who may examine the files later

Independent verification does not mean anyone can read the work. To check that a particular document matches its certificate, a reviewer needs access to that document, whether through a controlled review or a private copy. They do not need you to publish it for everyone.

For example, you could timestamp an unpublished process description now, keep it confidential, and later provide the exact file and verification material to an authorised expert. The expert could check the dated record without making the description public.

Plan that access separately: identify the recipient, the permitted purpose and any confidentiality terms. WIPO’s trade-secret management guidance describes access controls and contractual measures as parts of protecting confidential information. Timestamping supplements those measures; it does not establish ownership or prove that the information has remained secret.

Sources

National Institute of Standards and Technology. Cryptographic hash function. Definitions of a file fingerprint and the one-way and collision-resistance properties of cryptographic hashes.. Accessed 4 November 2026
C. Adams, P. Cain, D. Pinkas and R. Zuccherato. Internet X.509 Public Key Infrastructure Time-Stamp Protocol. RFC 3161, sections 2.1 and 2.2: timestamping a hash and validating the returned token.. August 2001. Accessed 4 November 2026
World Intellectual Property Organization. WIPO Guide to Trade Secrets and Innovation. Part IV, section 2.3: operational and contractual measures for protecting confidential information.. Accessed 4 November 2026

What does a digital timestamp establish?

Marco Barulli — Wed, 04 Nov 2026 00:00:00 GMT

Updated: 2026-11-04

A verifiable digital timestamp provides evidence that a particular version of a file existed no later than the time established by the timestamp. It connects the file’s cryptographic fingerprint to a dated record that can be checked later. It does not, on its own, establish when the work was first created, who created it or who owns it.

What does the date mean?

Suppose you finish a design on Monday and timestamp it on Thursday. The timestamp supports the conclusion that this version existed by Thursday. It does not establish Monday as its creation date.

The same applies to an older file: timestamping it today creates evidence from today. It does not retrospectively certify a date written inside the document.

How is the file connected to the date?

A cryptographic hash identifies the file’s exact contents. A timestamp connects that fingerprint to evidence of time. For example, under RFC 3161, a timestamp authority signs a record containing the hash and a time value. The authority can process the fingerprint without receiving the file itself.

Verification checks both the file and the timestamp. For a timestamp issued by an authority under RFC 3161, this means checking:

The file’s fingerprint: recalculate its hash and compare it with the hash recorded in the timestamp, using the specified algorithm.
The authority’s digital signature: verify that the timestamp was signed with the key corresponding to the authority’s signing certificate, and that the signed information—including the hash and time—has not been altered.
The signing certificate and its trust chain: check that the certificate was authorised for timestamp signing and chains back to a trusted certification authority. Its validity period and relevant revocation information must also be assessed; a mathematically correct signature alone does not establish that the signing key was trustworthy.
The time information and service policy: check the recorded time, any stated accuracy, and the rules under which the authority issued the timestamp. The signature authenticates the authority’s statement of time; confidence in that time also depends on the authority’s clock and operating procedures.

These checks are normally performed by verification software using the timestamp and supporting certificates and validation data. A matching file hash is only one part of the process.

Does it establish authorship or ownership?

The timestamp dates the material submitted. It does not determine whether the person submitting it created it, had permission to use it or holds the relevant rights. Nor does it check whether statements inside the file are true.

For example, a timestamped project note may say that a contractor assigned their rights to a company. The timestamp shows that the note existed by a date; it does not replace the assignment agreement. Preserve the records that support the statements you may later need to substantiate.

What should I keep for later verification?

Keep the exact timestamped file, its certificate or proof file, and any supporting verification data needed to check it independently. The provider’s complete export may bundle these together. A certificate cannot reconstruct a missing file or restore an altered one to its certified version.

There is no single certificate file format. Common forms you may encounter include:

PDF: a readable certificate or report. Some PDFs also contain embedded timestamps, signatures or proof attachments; others are only a summary. Preserve the original digital PDF and its attachments, not a printout or scan.
RFC 3161 response or token: a machine-readable file, often named .tsr or .tst. It contains the signed timestamp information used by verification software. File extensions vary between providers.
Blockchain proof file: for example, an OpenTimestamps .ots file. It contains the information needed to connect a file’s fingerprint to a blockchain record. Other services use their own proof formats.

Depending on the format, the proof file may need supporting verification data to be checked independently. For an authority-issued timestamp, this can include the authority’s signing certificate, intermediate certificates linking it to a trusted root, and dated certificate-status records showing whether certificates had been revoked. These may already be embedded in the export or supplied separately. For a blockchain timestamp, it means the proof connecting the file’s hash to the blockchain entry, rather than just a transaction number or screenshot.

You should not normally need to assemble these technical components yourself. Export the complete verification package, keep the provider’s instructions, and check that it includes what is needed for independent verification and long-term preservation. The filename extension alone does not tell you whether the package is complete.

When the work changes, preserve and timestamp the new version separately. This produces a sequence of dated records rather than asking one timestamp to describe the whole history of a project.

Sources

C. Adams, P. Cain, D. Pinkas and R. Zuccherato. Internet X.509 Public Key Infrastructure Time-Stamp Protocol. RFC 3161; introduction and sections 2.1 and 2.2: evidence of existence, timestamping hashes and verification. August 2001. Accessed 4 November 2026
National Institute of Standards and Technology. Cryptographic hash function. File fingerprints and the security properties used to identify matching data. Accessed 4 November 2026
OpenSSL Project. openssl-ts. Timestamp responses, tokens and certificate files used for verification. Accessed 4 November 2026
OpenTimestamps. OpenTimestamps. Detached .ots proof files and blockchain timestamp verification. Accessed 4 November 2026
Adobe. Add verification information to digital signatures. Signing certificates, revocation information and timestamps for long-term validation. Accessed 4 November 2026

What does independent verification mean?

Marco Barulli — Wed, 04 Nov 2026 00:00:00 GMT

Updated: 2026-11-04

Independent verification means anyone with the necessary files and proof data can check that those files match the dated evidence, without relying on the original provider to vouch for the result.

Instead of trusting a green “Valid” badge on a vendor’s portal, an independent reviewer uses the files, the exported cryptographic proof, and standalone verification tools to reproduce the math directly. A provider’s confirmation is convenient, but independence requires that the proof stands on its own outside their platform.

What Makes a Check Independent?

Imagine handing an auditor a design file and its timestamp evidence. If they must log into your provider’s website and accept its confirmation of the record, the check isn’t independent—it simply takes the provider’s word for it. Even using a secondary verification site isn’t necessarily independent, as it may just query the original vendor’s API behind the scenes.

The practical test of independence is simple: Can an outside party verify the result using the files and proof data you supply, together with independently available trust or blockchain data, without an account, an active API, or permission from the original platform?

What Does the Reviewer Check?

Verification follows the cryptographic links between the file and its dated evidence:

The File Fingerprint (Hash): The reviewer calculates the cryptographic hash of your file on their own machine to confirm it matches the input recorded in the exported proof.
The Cryptographic Evidence: The reviewer checks the proof using the method that produced it.
- For Authority-Issued Timestamps (RFC 3161): The reviewer inspects the timestamp authority’s digital signature, validates its certificate chain, and checks relevant revocation information. Standard tools like OpenSSL can perform these checks offline when the necessary certificates, trusted roots and certificate-status data are already available locally.
- For Blockchain Timestamps: Because no single universal standard exists for anchoring data to a blockchain, verification follows the specific anchoring protocol used. The reviewer checks how the file hash was processed (for example, combined with other hashes in a Merkle tree or used to derive a cryptographic key or blockchain address), traces it to the on-chain record, and verifies that the transaction was confirmed in a block. A raw transaction ID alone proves nothing about which file was anchored without this connective proof.

If any part of the proof must still be retrieved from the provider’s private servers, verification still depends on their availability. The complete cryptographic proof and the applicable protocol specifications must be preserved together.

Does “Independent” Mean Trust-Free?

No. Independent verification removes reliance on the vendor for checking the evidence, not the need for foundational trust. It shifts trust from a commercial vendor’s confirmation to cryptographic algorithms, verification software, and the infrastructure used to establish time:

With Authority Timestamps: You trust the cryptographic algorithms, the certificate chain leading to an accepted trust root, and the authority’s timekeeping and operating procedures.
With Blockchain Proofs: You rely on the underlying blockchain’s consensus rules and security assumptions. Querying an online block explorer is convenient, but running your own validating node lets you check blockchain data instead of relying solely on a third-party server’s response.
Long-Term Durability: Algorithms can weaken over time, and software evolves. An independent proof needs periodic assessment against current cryptographic standards and may require additional preservation measures to remain verifiable. Technical verification alone does not determine its legal weight.

Does the Reviewer Need Access to Confidential Files?

To confirm that a specific file matches the proof, the reviewer must calculate its hash directly from that file. However, this can be done locally in a secure, controlled environment. Independent verification does not inherently require uploading confidential files to a public server or web service.

If you share only the hash, the reviewer can check the dated proof associated with that fingerprint, but they cannot verify that it belongs to your confidential document without checking the document itself.

How to Prepare for an Independent Audit

To ensure your records can be checked without the original provider’s help:

Archive the complete evidence package: Store the exact, unaltered files alongside the complete proof bundle (receipts, signatures, Merkle paths, or manifests).
Retain protocol documentation: For blockchain proofs, keep a copy of the specific anchoring specification and version used.
Run a rehearsal: Test the verification workflow using standalone tools. If testing on a disconnected machine, first obtain the necessary certificate-status or blockchain data. Document the software versions, commands, and outputs.

Catching a missing receipt or ambiguous protocol step during a dry run is far easier than resolving it under the pressure of a legal dispute or investor audit.

Sources

OpenSSL Project. openssl-ts. Verification of RFC 3161 timestamp responses using files, timestamp tokens and certificate chains. Accessed 4 November 2026
OpenTimestamps. OpenTimestamps. Open timestamp proof format, independent verification and available client implementations. Accessed 4 November 2026
C. Adams, P. Cain, D. Pinkas and R. Zuccherato. Internet X.509 Public Key Infrastructure Time-Stamp Protocol. RFC 3161, sections 2.1 and 2.2: timestamp authority requirements and verification. August 2001. Accessed 4 November 2026

What is a cryptographic hash?

Marco Barulli — Wed, 04 Nov 2026 00:00:00 GMT

Updated: 2026-11-04

A cryptographic hash is a fixed-length value calculated from digital data, such as a file. It acts as a fingerprint of the file’s exact contents: changing even one byte produces a different hash with overwhelming probability. Comparing hashes helps establish whether two files contain exactly the same data.

How does it work?

A hash function processes a file and produces a value, usually displayed as a string of letters and numbers. The same file processed with the same hash function always produces the same result. Calculating a hash is a straightforward operation that can be performed locally on your computer; there is no need to upload the file.

For example, you could calculate the hash of a design file before sending it to a collaborator. If you later use the same hash function to calculate the hash of the returned file and obtain the same value, that is strong evidence that its contents have not changed. If the values differ, the files differ—even if the change is not immediately visible.

Changes to information stored inside the file, such as embedded metadata, can also change its hash. Renaming a file ordinarily does not, because its filename is separate from its contents.

What is SHA-256, and how long is its hash?

SHA stands for Secure Hash Algorithm. SHA-256 is a widely used member of the SHA-2 family, standardised by NIST. SHA-2 and SHA-3 are both current families of cryptographic hash algorithms; the older SHA-1 is being phased out. NIST’s overview describes these standards.

The “256” refers to the length of the result: 256 bits, or 32 bytes, usually displayed as 64 hexadecimal characters using the digits 0–9 and letters a–f. A short text file and a large design archive both produce a SHA-256 hash of exactly that length. The hash’s length depends on the algorithm, not on how much information the file contains.

A longer hash provides more possible values: SHA-256 has 2²⁵⁶ possible results. Two different files can theoretically have the same hash, which is called a collision, but finding such a pair is computationally infeasible with a secure algorithm such as SHA-256. This is why a matching hash is strong evidence of identical contents, rather than a mathematical guarantee that every possible file has a unique fingerprint.

How much difference can one character make?

These sentences differ only in their final punctuation: a full stop versus an exclamation mark.

Sentence A	Sentence B
This design is original.	This design is original!
SHA-256 `fff9b3e35c519283` `58c4430038b00f47` `fe26f3f9f4cfd557` `c05341573d85a959`	SHA-256 `068c0525b996503d` `75220f6f9fb3db9d` `d2195b5313ac1641` `1076d608297f78c8`

Each hash contains 64 hexadecimal characters, split across four lines here for readability. The hashes were calculated from the exact sentences shown, encoded as UTF-8, including the final punctuation and with no trailing space or line break.

Changing just the punctuation produces a very different hash. The same principle applies to files: changing a single byte—even in metadata that is not visible when you open the document—changes the hash with overwhelming probability. Similar-looking hashes do not indicate similar files.

What does a hash tell you about a file?

A hash helps identify an exact digital version and detect changes. On its own, it does not establish when the file existed, who created it or who owns the rights to its contents.

To establish a dated record, the hash needs to be connected to reliable evidence of time, such as a digital timestamp. To connect the file to a person or development process, additional records are needed.

Does a hash reveal the file’s contents?

A cryptographic hash is not an encrypted copy of the file, and it cannot be decrypted to recover the original.

A timestamp provider can receive the hash rather than the file itself. Check what actually reaches its server: only a fingerprint, an encrypted file, or readable contents. If the service also stores the file, check whether encryption happens before upload and who can access the decryption keys.

Why does this matter for intellectual property?

A hash lets a certificate or timestamp refer precisely to a particular design, document, source-code archive or other digital file. The file itself does not need to be included in the timestamp record.

Keep the exact certified file alongside its certificate. Later verification depends on recalculating its hash and checking that it matches the certified value. A hash cannot reconstruct a missing file or restore an altered file to its certified version.

Sources

National Institute of Standards and Technology. Hash Functions. SHA-2 and SHA-3 families, fixed-length outputs and security properties. Accessed 4 November 2026
National Institute of Standards and Technology. Secure Hash Standard (SHS). FIPS 180-4; hash algorithms and message digests. August 2015
C. Adams, P. Cain, D. Pinkas and R. Zuccherato. Internet X.509 Public Key Infrastructure Time-Stamp Protocol. RFC 3161; introduction and sections 2.1, 2.2 and 2.4.1. August 2001

At which stages of a project should I create a dated record of my work?

Marco Barulli — Wed, 04 Nov 2026 00:00:00 GMT

Updated: 2026-11-04

Create a dated record when you first have something concrete to preserve, when the work changes significantly, and before sharing a version with someone outside the project. Capture handovers and the final state when work ends or pauses. Keep routine working history between these milestones, and add independently verifiable timestamps where the timing of a particular version matters.

Start before the work looks finished

An early sketch, technical note, design brief or experimental plan can establish a useful starting point. Preserve it while its context is fresh: what were you trying to achieve, who was involved, and what material did you already have?

If a collaboration is beginning, record what each participant brings to it. This helps distinguish existing work from later contributions, although the record alone does not determine ownership.

Capture changes that explain the development

Create a new record when a change would matter to someone trying to understand how the project evolved. Examples include:

A design revision that changes how a product works or looks.
An experiment that supports a new approach or explains why another was abandoned.
A working prototype or software release.
A contribution that changes the direction of the work.

Preserve the relevant version with a short explanation of what changed and why. Keep earlier versions so the development remains traceable.

Before sending drawings to a manufacturer, giving a research partner access to results or delivering work to a client, preserve the exact version involved. Afterwards, retain the correspondence or delivery record showing what was sent, to whom and under which terms. A timestamp on a file does not itself show that someone received it.

When a contributor leaves, or a project pauses or ends, capture the current state and any unfinished work. This is also a useful moment to check that someone remains responsible for the files and can retrieve them.

For confidential material, keep the records under appropriate access controls. WIPO’s guidance on document management measures recommends simple procedures for handling and tracing such documents.

Choose a rhythm that fits the work

Continue keeping ordinary working records between milestones. In a fast-moving project, useful changes may happen every day; in another, several weeks may pass between them. A regular review can help catch gaps, but important changes and disclosures should trigger a record when they happen.

Where timing matters, add an independently verifiable timestamp to the relevant files. As explained in RFC 3161, a timestamp provides evidence that particular data existed at a particular time. Retain the exact files and the certificate together.

If the project is already underway, start now

Preserve the existing material and write an accurate account of its history, linking to earlier emails, drafts or other supporting records. Distinguish the dates of those activities from the date you prepared the account.

A timestamp obtained today cannot establish that the same file existed six months ago. Earlier records may help support that chronology; today’s timestamp provides a dated reference for the material you preserve now.

Sources

C. Adams, P. Cain, D. Pinkas and R. Zuccherato. Internet X.509 Public Key Infrastructure Time-Stamp Protocol. RFC 3161, introduction and section 2: timestamps provide evidence of existence at a particular time.. August 2001. Accessed 4 November 2026
World Intellectual Property Organization. WIPO Guide to Trade Secrets and Innovation. Part IV, section 2.3, Document management measures: simple procedures for handling and tracing confidential records.. Accessed 4 November 2026

Is your IP ready to be financed? A checklist built on the EUIPO's five priorities

Marco Barulli — Tue, 03 Nov 2026 00:00:00 GMT

Updated: 2026-11-03

The EUIPO's five priorities for IP-backed finance, read as a to-do list for IP owners and their counsel. What to put in place now so your IP qualifies when the instruments arrive.

This is the fourth and final article in our series on IP-backed finance from the innovator’s perspective: a practical guide on how companies and their IP advisers can prepare their assets for financing.

We began this series with a foundational policy document: the EUIPO’s April 2026 report on IP-backed finance, which estimates an annual addressable market of EUR 70-150 billion for European companies leveraging their intellectual property for growth. Over our last three posts, we examined the primary obstacles it identifies: the disclosure paradox, the vicious circle of missing data, and the mixed record of blockchain as a tool for IP-backed markets.

Now, we turn to practical steps. The report establishes five priorities for building a functional IP-backed finance system in Europe. While no one can predict exactly when guarantee schemes, valuation standards, or a central pledge register will be finalized, every priority demands specific readiness from IP owners. Fortunately, most of that groundwork can and should begin today.

Priority 1: Make IP visible

What the report proposes: A voluntary disclosure framework built upon the IP Scan (the subsidized IP check-up for EU SMEs detailed in part 1). This framework would cover registered rights and other relevant intangibles, ensuring IP-rich firms are transparent and easily evaluated by lenders and investors.

What it will ask of you: A structured, comprehensive inventory of your intellectual property, including crucial assets that sit outside formal registries.

What to do now:

If you are an EU-based SME, apply for an IP Scan immediately. It is heavily subsidized and serves as the report’s proposed entry point for the future disclosure framework.
Audit your registered rights to ensure they are in order: confirm renewals are paid, assignments and licenses are formally recorded, and ownership resides in the correct corporate entity.
Catalog the unregistered assets that drive real commercial value (source code, know-how, data sets, designs, and internal processes) and designate clear ownership for each.
For critical unregistered assets, establish a verifiable record of their existence and timeline without exposing their actual content. This is Bernstein’s core utility: by creating a cryptographic fingerprint of your files anchored to Bitcoin, eIDAS-qualified timestamps, and a China TSA, you generate a provable inventory you can safely present to financial counterparties.

Priority 2: Assign credible value to IP

What the report proposes: A European valuation architecture aligned with International Valuation Standards, modular valuation models to reduce costs for SMEs, and digital tools that generate indicative estimates pending professional validation.

What it will ask of you: Verifiable data a valuer can trust. Valuations demand documented proof of identity: when the asset was developed, how it evolved, its cost base, and its commercial application.

What to do now:

Maintain development records continuously, rather than scrambling to compile them when a valuation is commissioned. Immutable, date-stamped revisions of key work demonstrate an asset’s evolution and substantiate both cost- and income-based analyses.
Track the specific development costs of key assets. Under IAS 38 (the accounting standard for intangible assets), development costs can only be capitalized as an asset rather than treated as an expense under strict circumstances, requiring hard evidence that all conditions were met.
Document the direct commercial impact of each asset. Detail which products or services rely on it, the revenue it supports, the costs it reduces, or the advantages it helps maintain. Maintain clear evidentiary links that distinguish the asset’s specific contribution from the broader business operations.
When providing a valuer access to trade secrets, use controlled sharing environments that maintain strict access logs.

Priority 3: Leverage IP value into lending

What the report proposes: Initial risk-sharing through public guarantees for IP-backed loans, dedicated public lending against IP collateral, and the exploration of IP insurance products.

What it will ask of you: The precise documentation a lender’s counsel requires before taking security over an asset: clear definitions, undisputed ownership, proven integrity, and a complete access history.

What to do now:

Secure your chain of title. Verify that all founders, employees, and contractors have executed written IP assignments to the company, and check the execution dates against the development history.
Understand how IP pledges function in your specific jurisdiction. The report explicitly notes that rules are not harmonized across Member States, making this a critical question for your national legal counsel.
Ensure the integrity of your key assets can be audited by a third party independently. Bernstein certificates, for example, can be mathematically verified by external parties without relying on Bernstein itself.

Priority 4: Build the evidence base

What the report proposes: Common data requirements, interconnected registries, a robust dataset of real transaction outcomes, and a central register of IP pledges.

What it will ask of you: Clear transaction records and documentation of every agreement involving your IP.

What to do now:

Maintain a central, up-to-date register of all licenses, options, pledges, and disclosures, complete with executed attachments.
Implement controlled sharing for all sensitive material. Every disclosure to a partner, investor, or acquirer must leave a cryptographic, date-stamped audit trail detailing exactly who received access, under what terms, and when.
Keep your evidence portable. Periodically export your certificates, files, and cryptographic keys to self-hosted storage. Your evidentiary record should never be locked into a single vendor’s ecosystem.

Priority 5: Reinforce coordination

What the report proposes: Cross-border coordination of standards, valuation expertise, digital tools, and training. Notably, the proposed training programs target founders and management teams directly to prevent the early-stage IP errors that most frequently impede fundraising and prepare firms for investor IP due diligence.

What it will ask of you: To have anticipated and mitigated these early-stage errors long before a term sheet arrives.

What to do now: Treat IP due diligence readiness as a continuous operational discipline, not a reactive project.

The one element you cannot retrofit

While most of this checklist can be executed on demand, one critical element cannot be backdated: a timestamp.

A cryptographic timestamp inherently records the exact moment it is generated. Any service claiming to backdate a timestamp is fundamentally worthless. If a lender in 2029 asks whether a vital piece of know-how existed in 2026, a timestamp created in 2026 can help establish that the corresponding files existed at that time. Comparing those files with the timestamped record can also help verify their integrity. Ownership requires separate supporting evidence, such as contracts and assignments, and other contemporaneous records may also help establish the asset’s history.

The policy timeline for European IP-backed finance remains uncertain. It depends on the Savings and Investment Union, guarantee budgets, and banking standards. Your timestamped record, however, begins when you create the timestamp, not automatically when you create the asset.

Closing the series

The EUIPO report makes a compelling case for expanding IP-backed finance in Europe. The capital is mobilizing, and IP-rich firms are driving the continent’s growth. Whether an individual company can capitalize on this shift will depend less on the timing of reforms and more on whether its IP can be cleanly verified, understood, and audited by external capital providers.

This principle has anchored our entire series. Disclose the proof, not the secret. Supply the foundational evidence that only the asset owner can generate. Use blockchain where it provides mathematical certainty as a digital notary, not as a speculative token. And establish your evidentiary record today, because a timestamp created tomorrow cannot establish that the files existed today.

Bernstein has been building these verifiable records for innovators since 2016. Bernstein does not value IP, it simply ensures that when the market is ready to do so, your evidence is available for independent verification.

To see the platform in action, visit bernstein.io.

This checklist is general guidance and not legal advice; consult counsel on the law of your jurisdiction. Bernstein provides evidence and does not replace patents, trademarks or contracts.

Sources

European Union Intellectual Property Office. IP-backed Finance. Executive Summary, p. 5; sections 2.2.2–2.2.3, pp. 39–42; sections 4.1–4.5, pp. 103–109. April 2026
European Union Intellectual Property Office. IP Scan / IP Scan Enforcement voucher 2026. SME Fund 2026, Voucher 1. Accessed 3 November 2026

EU Qualified Ledgers: A Legal Privilege No Technology Earned

Marco Barulli — Thu, 29 Oct 2026 00:00:00 GMT

Updated: 2026-10-29

The EU grants qualified ledgers a legal presumption their technology does not earn. It helps in EU courts, adds little elsewhere, and is no substitute for proof anyone can verify.

The 2024 revision of eIDAS created a new class of evidence: qualified electronic ledgers. The implementing rules published in December 2025 set out what these systems must do (Regulation 2024/1183, Implementing Regulation 2025/2531). A record entered on a certified ledger now carries a statutory presumption of integrity and chronological order in all 27 member states.

In any EU court, even in a dispute between companies from different member states, that presumption moves the burden of proof onto whoever challenges the record. So it is fair to ask what technical breakthrough earned it.

There isn’t one.

The framework does not require decentralization, fault tolerance across independent parties, or open verification. It is perfectly comfortable with a closed system run by a single company. Read past the regulatory vocabulary and the required controls are signatures, hash chains and a protected signing key: the same toolkit engineers have bolted onto ordinary databases for decades.

The EU has not raised the technical bar. It has stamped the existing one and attached a legal privilege to the stamp. For IP owners and the lawyers who defend them, mistaking that stamp for stronger evidence is a costly error. It trades proof that anyone can verify for a label that only works where the label is recognized, and only if the vendor is still around to back it.

A Ledger in Name Only

“Qualified electronic ledger” sounds like distributed, tamper-proof infrastructure. The annex to Implementing Regulation 2025/2531 describes something much plainer:

advanced electronic signatures or seals based on qualified certificates, to show where data came from;
hash lists or hash trees (SHA-256 or stronger) to fix the order of records;
signature-based integrity checks, so that any later change is detectable;
certified hardware (Common Criteria EAL 4 or FIPS 140-3 Level 3) to hold the signing keys.

Nothing on that list needs a blockchain. Distributed ledgers are allowed, with some extra ISO requirements, but they are an option, not a condition. An append-only PostgreSQL table with signed entries, a Merkle root and a hardware security module (HSM, the tamper-resistant device banks use to guard their signing keys) clears the same functional bar.

	Certified “qualified ledger”	Equivalent system, uncertified
Technology	Database + PKI + hash chain	Database + PKI + hash chain (or stronger)
Legal weight in the EU	Statutory presumption (eIDAS Art. 45k)	Must prove its integrity from scratch

Ledger vendors will object that their systems are distributed, pointing to the number of nodes they run. But ten servers under one company’s control are still one company. Whoever holds the root keys, the hosting contracts and the admin console can go bankrupt, be coerced or make a mistake, and all ten nodes go down with them.

The result is a legal hierarchy that ignores engineering. An audited database labelled “qualified” gets the presumption; an identical or better system without the label starts from zero. The law trusts the vendor’s paperwork more than the mathematics of the evidence.

An Audit Is Not a Guarantee

Defenders point to the supervision regime. Qualified trust service providers are audited at least every two years and must keep a termination plan that preserves access to records if they shut down (Implementing Regulation 2025/2530, Article 3).

A termination plan is an intention, not a proof. It works only if, at the moment the provider collapses, there is still money, a willing successor and staff who follow the plan. Insolvency, distressed sales and restructuring are exactly the moments when none of that is certain.

An audit report says a provider passed a checklist on the day of the audit. It cannot bring back an archive that has gone offline, or rebuild a chain of custody halfway through a trial. Suing a bankrupt trust provider will not rescue a claim that has lost its proof.

Evidence Must Outlast the Vendor

Intellectual property can stay valuable, and contested, for decades. Take a company that keeps a process secret instead of patenting it. If a competitor later patents the same idea, the company can keep using its process only by proving it got there first, and that proof must hold for as long as the rival’s patent can be enforced: up to twenty years.

Software companies rarely last that long. Products are discontinued, APIs deprecated, startups acquired or wound down. Meanwhile the disputes that matter (a former supplier reusing your drawings, a new patent covering a process you have run for years) often surface ten or fifteen years after the work was created.

At that point you must prove that the work existed, that it has not changed, and that it was yours. A ledger entry cannot do that on its own if checking it requires the vendor’s closed API, a licence for discontinued software, or an escrow archive nobody has opened in a decade. When the provider goes, the evidence goes with it.

Every IP lawyer should therefore apply one test:

If the ledger vendor disappeared tomorrow, could an independent expert export the raw proofs and verify them in court using only open-source tools and public standards?

If the answer is no, you do not own your evidence. You rent it.

The Presumption Stops at the Border

IP is international. An invention developed in Munich is patented in the US, manufactured in Shenzhen and licensed in Tokyo. Infringers do not pick their jurisdiction to suit Brussels.

The presumption in Article 45k binds EU courts. A US federal judge, a Singapore arbitral panel or the High Court in London owes it nothing. Outside the EU:

admissibility follows local procedure and expert-evidence rules, such as Daubert challenges in the US, where the opposing party asks the judge to exclude expert testimony whose method cannot be independently tested;
an EU certificate does not replace a technical account of how the record was produced and checked;
an expert who has to concede that verification depends on a vendor’s undisclosed, closed-source code invites exclusion, or at best a heavy discount.

Compare an open standard such as RFC 3161 for timestamps. The format and the verification procedure are public, and any competent expert anywhere can check a token with free tools, without a licence and without the issuer’s help. Evidence built that way travels. Evidence that relies on an EU certificate for its weight is strong in EU courts, but everywhere else it has to prove itself from scratch.

Use the Badge, Don’t Build on It

None of this makes qualified ledgers useless. Inside the EU, a statutory presumption is a real procedural advantage, as long as the record stays verifiable for the life of the asset and does not depend on the vendor’s survival. Outside the EU, it adds very little.

So IP owners do not have to choose between local recognition and global verifiability. They should layer the two. Anchor evidence first in open, global infrastructure that anyone can check without asking permission, such as RFC 3161 timestamps or the Bitcoin blockchain. Then, where a dispute is likely to be fought, add the proof that local courts recognize: a qualified ledger in the EU, an accredited timestamping authority in China, a government-accredited timestamp in Japan.

When you decide how your company records its core assets:

Anchor globally first. Use open standards and public infrastructure that any expert, in any jurisdiction, can verify with free tools.
Add local recognition where you may litigate. Treat nationally recognized proofs as a layer on top, not as the foundation.
Keep the data and the proofs. A proof only certifies a hash; without the exact original file, it proves nothing. Keep the certified data, byte for byte, together with self-contained proof packages (raw signatures, hashes and certificate chains), all in your own custody.
Verify without the vendor. Make sure your own team can check any historical record with open-source tools, with the vendor’s platform switched off.

A statutory presumption can win you the argument in one jurisdiction. Proof that anyone can check lets you make the argument anywhere.

Sources

European Parliament and Council of the European Union. Regulation (EU) 2024/1183. Amendments to eIDAS introducing electronic ledgers; Article 45k cited in the article. 2024
European Commission. Implementing Regulation (EU) 2025/2531. Requirements for qualified electronic ledgers; annex. 2025
European Commission. Implementing Regulation (EU) 2025/2530. Article 3: termination plans. 2025
C. Adams, P. Cain, D. Pinkas and R. Zuccherato. Internet X.509 Public Key Infrastructure Time-Stamp Protocol (TSP). RFC 3161. August 2001

How should I document the development of an idea, design or invention?

Marco Barulli — Thu, 29 Oct 2026 00:00:00 GMT

Updated: 2026-10-29

Build a dated record as the work develops. Preserve meaningful versions, record who contributed and explain what changed. Add independently verifiable timestamps at important milestones, and retain the exact files they certify. Together, these records should let someone unfamiliar with the project understand what existed, when it existed and how it evolved.

Start with the work itself

Preserve the materials that explain your development process: sketches, drafts, design files, source code, experimental results, photographs of prototypes and technical notes. Include unsuccessful approaches when they help explain how you reached a solution.

Keep original working files alongside useful exports. A finished PDF or photograph may show the result, while the underlying files and earlier versions explain how you got there.

Give each meaningful version some context

For each milestone, record the date, contributors, changes and supporting files. A short note is often enough: what problem were you addressing, what did you try, and what did you learn?

For example, a prototype revision could include the updated drawing, photographs, test results and a note explaining why the dimensions changed. Keep relevant correspondence and agreements alongside the project when they help establish contributions, instructions or ownership arrangements.

Make the chronology independently verifiable

A date written in a document records what you say happened. A trusted digital timestamp provides additional evidence that a particular version already existed at a given time. Timestamping meaningful milestones can therefore strengthen the chronology of your development record. See RFC 3161, introduction and section 2.

Choose milestones that matter to the project: a significant design change, an experimental result, a software release or the version about to be shared with a partner. If you document earlier work retrospectively, distinguish the date of the original activity from the date you created the record.

Preserve the evidence so it remains usable

Retain the exact certified files, their certificates and the information needed for verification. Work on copies when making further changes, and maintain backups. A certificate cannot reconstruct a missing original, and an altered file may no longer match its certificate. See Your certificate is immutable. Your files are not..

Keep confidential records under appropriate access controls. Use a clear folder structure, identify sensitive material and make responsibility for maintaining the records explicit. WIPO recommends document-management measures that make confidential information identifiable and traceable, while remaining simple enough for people to follow.

Sources

C. Adams, P. Cain, D. Pinkas and R. Zuccherato. Internet X.509 Public Key Infrastructure Time-Stamp Protocol. RFC 3161; introduction and section 2. August 2001
Bernstein. Your certificate is immutable. Your files are not.. Preserve the version you certified. 16 October 2026
World Intellectual Property Organization. WIPO Guide to Trade Secrets and Innovation. Part IV: Trade secret management; Document management measures. Accessed 29 October 2026

Before You Submit: How to Protect Your Architectural Work

Marco Barulli — Wed, 28 Oct 2026 00:00:00 GMT

Updated: 2026-10-28

Before submitting to a tender or competition, preserve evidence of your design, clarify permitted uses and plan any public disclosure to support protection.

Preserve the story of your design before it leaves the studio, and why it matters when a tender goes wrong.

The boards are ready. The model is checked. After weeks of testing layouts and working through revisions, your studio is about to submit its proposal.

You know another practice might win, that is the nature of competitions. What worries you is a different scenario: your proposal is rejected, but a few months later, a distinctly familiar concept appears in the winning project. Or the client asks for “a few more schematic drawings,” only to hand your hard work to a cheaper execution firm.

If this happens, could you prove exactly what your studio created, what you shared, and what the client was allowed to do with it?

These questions are much easier to answer if you prepare while the project is still on your desk. A few deliberate habits can give you a clear, independently verifiable record.

Preserve how the design became yours

A final presentation shows the polished result. But the sketches, study models, and revisions show how your team arrived there.

You don’t need to archive every mouse click, but you should preserve the meaningful milestones. Keep the early study that captures the first appearance of a façade treatment. Save the series of plans showing how you resolved an awkward circulation space. Document consultant contributions and make sure you have agreements on how their work can be used.

Proving ownership is much easier when you can show the actual choices you made. Saying “we proposed a light-filled atrium” holds little weight; showing timestamped CAD files of its specific proportions and spatial relationships changes the conversation.

How Bernstein helps:

Bernstein certifies your project revisions and retains your files in encrypted storage. By combining Bitcoin anchoring with officially recognized EU (eIDAS) and Chinese timestamps, Bernstein gives each revision independent proof that matching files existed by the certified date and haven’t been altered since. This multi-standard timestamping ensures your evidence carries immediate weight and meets local legal standards in European, Chinese, and international contexts, all while your drawings remain strictly private.

Be clear about what submitting allows

Before entering a tender, read the intellectual property clauses as carefully as the design brief. Watch out for predatory “rights grab” clauses. Permission for a jury to assess a proposal is very different from permission to build it.

Look for answers to four practical questions:

Does the studio retain copyright of the submission?
What can the organizer do with unselected entries?
Can the organizer adapt your work or pass it to another practice?
What permissions remain if the project is cancelled?

The Royal Institute of British Architects (RIBA) highlights protecting entrants’ copyright as an essential mark of a well-run competition, while recognizing that organizers usually only need limited rights to promote or exhibit entries. If the wording gives the organizer too much freedom, seek clarification before submitting. Whenever possible, agree in writing that developing your proposal requires a separate contract. (Note: A tiny copyright symbol on your title block will not override the competition’s signed terms).

Keep the exact package that leaves the studio

The night before a deadline is chaotic. A board is re-exported, a render is tweaked, and suddenly the package uploaded to the portal differs slightly from the one in your server’s “Final” folder.

Preserve and certify the exact files submitted, and keep the portal upload receipt or delivery confirmation alongside them. If a dispute ever arises about what was handed over, having certified copies of the identical file bundle eliminates any debate about subsequent tampering or missing pages.

How Bernstein helps:

Certify the full submission bundle - You can certify the complete package that leaves the studio, not just drawings and 3D models, but technical specifications, administrative forms, and qualification documents. This creates an independently verifiable snapshot of the entire submission on that date.
Control delivery with Secure Sharing - When tenders do not require a closed procurement portal, Bernstein’s Secure Sharing allows you to distribute files directly. It tracks who opened your drawings and logs their explicit acceptance of your sharing terms before granting access, creating a record of access through the sharing link and the terms accepted by recipients.

Choose the public reveal deliberately

A strong proposal deserves a public life, even if it doesn’t win. Publishing your work in a portfolio or exhibition brings recognition, and it can also trigger legal protection.

In the European Union, a design that is new and unique can qualify for 3 years of unregistered design protection from the moment it is first disclosed to the EU public. No registration is required. This covers copying the appearance of whole buildings or distinct architectural components.

A quick warning: Check the competition’s confidentiality rules before posting on social media. A private submission to a jury does not count as a public reveal, but once you publish it on your website or in a public exhibition, the three-year protection clock starts ticking.

Connect publication to the work behind it

If you want to protect your work, your public reveal shouldn’t exist in a vacuum. It should be linked directly to your private design process.

How Bernstein helps:

This is the idea behind Bernstein’s planned Defensive Publishing feature. When you decide to reveal a design, you select a version from your project’s private, certified record. The publication becomes the next step in that documented history. It connects your early private sketches to your final public renders, creating a verifiable trail anchored to the Bitcoin blockchain, connecting the published design to its development history and helping document the disclosure on which unregistered design protection depends.

(Note: If your design includes a genuine technical innovation, like a novel façade assembly system, publishing it might prevent you from patenting it later. Decide if you want to file for a patent before sharing the technical details.)

Conclusions

Your studio has to show its work to win work. But before your next submission leaves the office, make sure you have preserved the design’s development, locked down the exact submission package, and understood the terms of sharing.

By making these simple steps a studio habit, you will be in a much stronger position to stand behind your work, control its narrative, and take action if someone uses it without your permission.

Sources

Bernstein. Platform features. Certification process and Secure Sharing tools
Bernstein. Defensive Publishing. Planned feature
Royal Institute of British Architects. Guidance for competition entrants
European Union Intellectual Property Office. FAQ on design protection basics
European Union Intellectual Property Office. Invalidity decision ICD 000001014. Architectural designs
European Union Intellectual Property Office. FAQ on unregistered Community designs. Proving prior disclosure
European Patent Office. Guidelines for Examination. 2026 edition, G-IV, 2: technical disclosure and prior art

Blockchain in IP finance: the lesson of patent NFTs

Marco Barulli — Tue, 27 Oct 2026 00:00:00 GMT

Updated: 2026-10-27

Patent NFTs promised a liquid market for intellectual property. The collapse of IPwe shows why the true value of distributed ledgers lies in durable evidence, not tradable tokens.

An enterprise often spends years quietly engineering proprietary technology before ever approaching a lender. When funding talks finally begin, the dialogue turns quickly from technological promise to documented reality. The innovator must substantiate what it owns, demonstrate how the technology evolved, and prove why its records deserve confidence. In IP-backed lending, the quality of those internal records directly shapes credit terms and underwriting decisions.

In the first two articles of this series, we examined the disclosure paradox and the evidence gap in IP finance. Distributed ledgers enter this discussion because they allow corporate records to be verified independently and objectively. Yet much of the public debate has bypassed this foundational evidentiary role, focusing instead on a far more speculative ambition: turning intellectual property into tradeable tokens.

The EUIPO’s IP-backed Finance report examines that ambition through the rise and fall of IPwe. Its trajectory provides an instructive case study in where distributed ledgers deliver tangible value for an IP owner today.

What happened to the patent NFTs?

IPwe set out to transform intellectual property management by representing patents as non-fungible tokens, or NFTs. Each patent NFT aimed to consolidate key legal and technical data into a single digital record, with the goal of accelerating due diligence and executing licensing transactions through smart contracts.

The concept addressed a genuine market friction. Patent intelligence is fragmented across regional registries, proprietary databases, and internal enterprise archives. Evaluating an unfamiliar portfolio demands substantial diligence, high legal costs, and significant administrative time. Consolidating that information into a standardized digital record promised a shared baseline for owners, prospective buyers, and financing partners alike.

Commercial reality proved far less forgiving. As the EUIPO report recounts, IPwe failed to gain sufficient market traction and entered bankruptcy in 2024. Crucially, the EUIPO report distinguishes between commercial friction and technological failure. It attributes the collapse to weak market demand and unresolved uncertainty regarding the securities-law status of patent NFTs, rather than an inherent defect in distributed ledgers.

That distinction carries an essential lesson. Minting a token is a straightforward technical procedure. Building a functioning, liquid secondary market requires willing buyers, tested transaction structures, clear regulatory boundaries, and a compelling reason for conservative market participants to abandon established legal mechanisms. IPwe showed the immense distance between a working technical proof of concept and a self-sustaining commercial marketplace.

For an innovator preparing intellectual property for financing, the immediate priority lies elsewhere. Before an intangible asset can ever be traded, the company must first build durable, verifiable evidence of what it owns and controls.

A useful record before a tradable asset

Consider an industrial manufacturer developing a proprietary production method. The commercial value of that know-how resides in engineering drawings, laboratory test results, chemical formulations, and iterative operational manuals. Taken together, these materials define the proprietary asset and demonstrate operational control over the trade secret.

Certifying those materials as research progresses produces an objective, tamper-proof audit trail. A cryptographic fingerprint uniquely identifies each source file, and anchoring that fingerprint to Bitcoin establishes a permanent, publicly verifiable reference point. Throughout this process, the underlying trade secrets remain private.

This workflow directly supports claims of ownership and chain of title. The business can connect certified technical milestones to employment agreements, assignment records, and internal project logs, assembling a coherent and verifiable evidentiary package. When a lender, appraiser, or investor examines the portfolio, they work from updated, tamper-proof documentation rather than a hurried retrospective narrative assembled under deadline pressure.

The commercial advantage takes effect immediately. It does not require a novel token exchange to achieve market liquidity, nor does it depend on patent NFTs gaining regulatory approval as financial instruments. Instead, it strengthens the company’s negotiating position inside the conventional financing and licensing transactions it already conducts.

The choice of blockchain matters

The architectural design supporting an IP record determines whether that evidence will remain legally defensible across decades.

IPwe’s platform operated on a hybrid architecture. According to the Hyperledger Foundation’s February 2023 announcement, cited by the EUIPO, the system paired the public Casper blockchain with a private, permissioned Hyperledger Fabric network. This hybrid structure sought to link enterprise data held on a closed consortium ledger with tokenized assets represented on a public chain.

Private, permissioned networks serve specific operational needs when a known group of corporate partners must coordinate workflows and control access to shared information. For an IP owner seeking evidence that remains defensible over the long term, however, private ledgers introduce severe counterparty risks. A permissioned network depends entirely on the consortium members continuing to fund, operate, and maintain the infrastructure. If those members dissolve the partnership, change strategic priorities, or face insolvency, the network and its validation mechanisms can disappear.

The public layer provided similarly fragile assurance. Casper remains operational, but its live explorer showed just 71 active validators on 26 October 2026. Such concentration introduces direct evidentiary risks: following a July 2024 exploit, validators coordinated to halt the network for several days and replace two historical blocks, as Casper’s own incident report documents. When preserving records across decades, the label “public” is not enough on its own. If a small group of operators can pause the ledger and alter recorded history, the network loses the neutral immutability required for durable legal proof.

This vulnerability becomes critical when dealing with assets that possess a long commercial lifespan. A proprietary production process may remain in active use long after its original creators have departed. A patent portfolio might be licensed, assigned, or pledged as collateral fifteen years after its initial filing. The legal evidence must travel with the asset through corporate reorganizations, portfolio sales, and successive rounds of financing.

Bitcoin provides the durability required for that continuity. Its ledger is maintained by a global, decentralized network that has mostly operated without interruption since 2009. Anyone can verify an anchor on Bitcoin independently, without requesting permission from a consortium or relying on the survival of the vendor that registered the initial timestamp. Its decentralization, operational longevity, and open verifiability make Bitcoin an exceptionally dependable foundation for permanent IP records.

Why Bernstein builds on Bitcoin

Bernstein anchors the cryptographic fingerprints of certified IP assets directly to Bitcoin. The public reference point exists on an open ledger, completely outside Bernstein’s internal systems.

Confidentiality is protected at the source. Files are encrypted locally on the owner’s device before any data is transmitted. As a result, sensitive proprietary materials are never disclosed to Bernstein, and trade secrets are never broadcast to a public blockchain.

To ensure broad evidential weight across legal jurisdictions, Bernstein pairs this Bitcoin anchor with certified electronic timestamps from recognized authorities, including EU qualified and China trusted timestamps. Innovators can export their complete cryptographic certificates alongside the original files and the independent verification protocols. With this package secured, the company retains self-contained proof that any court, lender, or auditor can verify independently, even if Bernstein ceased operations tomorrow.

For the manufacturer in our example, every key engineering milestone becomes a certified revision. When debt financing or private equity investment is on the table, the company and its IP counsel can present a clean, chronological dossier of the asset. They can share access with authorized reviewers under appropriate non-disclosure terms, using the certified timestamps as an unalterable, shared baseline throughout due diligence.

Selecting the right underlying infrastructure is practical risk management. An evidence system delivers genuine commercial value only when its legal validity outlives the commercial relationship with the service provider that created it.

Evidence that future markets will also need

The EUIPO report remains optimistic about the future role of distributed ledgers in IP finance. In its analysis of securitisation, the report highlights how distributed ledgers could record ownership histories, track licensing assignments, and support the administration of cash flows within structured finance vehicles.

That EUIPO’s vision aligns directly with the preparatory work companies can undertake today. Whatever form a future financial transaction takes, both lenders and rating agencies will still demand a clear, verifiable picture of the underlying asset. A thoroughly documented development history, clean proof of chain of title, and clearly identified version histories give any transaction a stronger legal and financial footing.

For business owners and IP counsel, the strategic path forward is straightforward and practical. It begins with identifying a core proprietary asset and gathering the materials that establish legal ownership and control, from technical schematics to contributor agreements and assignments. Once that baseline dossier is certified, the team simply maintains the record as the technology evolves, storing the exported cryptographic certificates alongside the original source files.

Over time, this disciplined approach creates an asset that cannot be fabricated retrospectively: an unimpeachable, contemporaneous record built in lockstep with the invention itself. When an investor, commercial partner, or bank asks what the company owns, the verifiable proof is already waiting.

The fourth and final article in this series will translate these principles into a practical readiness checklist, giving innovators and their advisers a step-by-step framework to prepare intangible assets for capital markets.

Explore how Bernstein helps you build a certified, independently verifiable record of your IP.

Sources

European Union Intellectual Property Office. IP-backed Finance. Section 3.1.6, printed pages 68-69, on patent NFTs and IPwe’s bankruptcy; section 3.1.11, printed page 81, on distributed ledgers and IP securitisation. April 2026
Hyperledger Foundation. IPwe Launches Revolutionary Platform and Deployment of 25 Million Patent NFTs on Hybrid Casper Blockchain and Hyperledger Fabric Network. 2 February 2023
Casper Association. Casper Blockchain Security Update: Preliminary Incident Report
Casper Association. Casper Security Incident Has Been Resolved; Network is Fully Operational
Casper live explorer. Active-validator snapshot cited as of 26 October 2026

From first sketch to final collection: building evidence of your designs

Marco Barulli — Wed, 21 Oct 2026 00:00:00 GMT

Updated: 2026-10-21

What a French fashion dispute can teach designers about timestamping, confidential sharing and preserving their work.

When French fashion house AZ Factory took clothing wholesaler Valeria Moda to court over counterfeit garments, it introduced an unconventional piece of evidence: blockchain timestamps proving its design files predated the infringing copies.

The dispute centered on two signature creations, Love from Alber and Hearts from Alber. Valeria Moda challenged both the infringement claims and AZ Factory’s underlying copyright ownership. AZ Factory faced a dual burden: proving its chain of title and establishing an incontrovertible timeline of creation.

On 20 March 2025, the Marseille Judicial Court ruled in AZ Factory’s favor. Central to the decision were two blockchain timestamps registered on 5 May and 15 September 2021. An independent bailiff’s report from 19 October 2022 corroborated these records. In France, a bailiff (commissaire de justice) is an authorized legal officer whose formal observations carry significant evidentiary weight in court; here, the report documented the formal verification of the timestamp records. Alongside evidence of public release under AZ Factory’s name, the court accepted the timestamps as legitimate proof of prior existence. (Read the full EUIPO case summary).

For creators across fashion, jewelry, and furniture design, the takeaway is clear: the strongest defense against infringement is built while the work is taking shape, long before a dispute surfaces. Contemporaneously certifying and preserving your designs as they evolve establishes a verifiable, objective record of what you created and precisely when.

What the timestamp contributed

Digital files are inherently fragile evidence. Operating system metadata—such as file names and local “Date Modified” stamps—carries little weight in court. Files are routinely renamed, moved, duplicated, and re-exported, altering local timestamps in the process. When an infringement dispute arises years later, local file metadata rarely withstands legal scrutiny.

A blockchain timestamp anchors the file to an immutable reference point outside your personal computer.

The process begins with a cryptographic hash, a unique digital fingerprint calculated mathematically from the file’s contents. If a single pixel, curve, or character changes, the hash changes completely. Anchoring this fingerprint into a public ledger like Bitcoin provides tamper-resistant proof that the exact matching file existed on or before that entry was recorded. Beyond verifying existence and integrity, this mechanism also establishes proof of possession: by demonstrating control over the private key used to sign the Bitcoin transaction containing that fingerprint, the owner can provably show they held the file at the time of registration.

Crucially, only the fingerprint is written to the blockchain; the design file itself remains entirely private. This distinction is vital when handling unreleased collections, sensitive client proposals, or proprietary prototypes. You can establish incontrovertible proof of prior existence without exposing commercial assets on a public ledger.

However, you must keep the exact source file. A blockchain certificate cannot reconstruct a misplaced sketch, nor can it validate an export altered after the timestamp was generated. (In this post, we break down three common ways you might inadvertently sabotage your own digital certificates. )

Show how the design evolved

A solitary timestamp answers a narrow question: Did this specific file exist by this date?

In copyright disputes, however, an organic creative trail tells a far more compelling story. A persuasive narrative rarely starts with a polished final export; it begins months earlier with the first rough sketch, pattern experiments, revised color palettes, factory sample revisions, and technical production packs.

By certifying these milestones throughout development and maintaining them within a version-controlled project, you build an unbroken chronology of creation. Each certificate benchmarks a specific iteration. Together with the stored source files, these records allow a judge, adversary, or examiner to trace how a concept matured into a finished design.

This developmental history reinforces your final claim. It proves that distinctive aesthetic features were not copied at the last minute, but evolved organically across revisions. An infringer claiming independent creation will struggle to counter a dated, chronological trail of iterative work. Crucially, this record cannot be retrofitted: certifying a batch of legacy drafts today only proves they exist today, not when they were originally drawn.

Chronological proof must also connect directly to the individuals involved. Always store design briefs, contributor agreements, sign-offs, and delivery emails alongside your certified files. Anyone can timestamp an arbitrary digital file; timestamping someone else’s work does not grant ownership. Regular timestamping does not create copyright—it supplies the verifiable evidentiary foundation needed to enforce it.

Three situations where this matters

Certification and secure storage serve distinct, complementary roles. Certification delivers a legally defensible, verifiable date; storage preserves the exact source files required to substantiate it. Encrypted, versioned storage ensures your confidential iterations remain protected without being overwritten as designs evolve.

Before production begins, you often need to share technical drawings, patterns, or renders with external manufacturers for quoting. The risk of leaks or unauthorized copying is high. Even with a signed non-disclosure agreement (NDA), parties frequently dispute which specific files were covered.

Before sharing, certify the collection and securely store that exact version. Reference the certificate’s unique identifier directly in the NDA or its annex. This binds both parties to an unambiguous, tamper-proof inventory of disclosed files without embedding large, proprietary designs into the contract text itself. Keep an audit trail of what was sent and to whom.

When design revisions occur, update the certified references accordingly. The agreement defines the legal obligations; the certificate and stored files establish the exact subject matter. See our guide on the NDA and contracts use case.

2. Managing fragmented studio workflows

Modern creative workflows are rarely linear. An illustrator sends a draft by email, a colleague adjusts the color scheme, and a freelance CAD specialist delivers the production files. If team members depart or a client questions a design’s provenance months down the road, reconstructing its history across scattered inboxes and shared drives is nearly impossible.

Consolidating versions into a centralized project and certifying them upon arrival preserves the creative chain of custody. Storing contributor identities, copyright assignments, and sign-offs alongside the timestamped files allows you to instantly trace every contribution and defend your intellectual property.

3. Defending against lookalike launches

A competitor debuts a product unmistakably derived from yours. You scramble to assemble evidence, only to find your working directory contains only the latest production export—dated weeks after the competitor’s launch—while earlier working sketches were overwritten or discarded.

If you have systematically certified and stored iterative milestones, you can readily retrieve earlier drafts and their corresponding timestamps. Demonstrating that signature motifs existed in your studio months before the competitor’s release shifts legal leverage decisively in your favor. A timestamp secured today cannot rescue an overwritten file from last year, making proactive archiving essential.

Build the evidence as you work

Bernstein unifies certification, storage, and secure sharing into a single creative workflow. Encrypted, version-controlled storage safeguards your proprietary files as concepts evolve, while Secure Sharing lets you govern access, log recipient consent, and maintain an immutable audit trail. Certificates integrate directly into contractual agreements to identify protected IP unambiguously.

Should you ever need to demonstrate ownership or provenance, every file and its corresponding cryptographic proof are instantly accessible. Using Bernstein’s validator, you, your legal counsel, or opposing parties can independently verify file authenticity without complex technical workflows.

For an in-depth legal analysis of the admissibility of cryptographic proof across international courts, read our open-access study: Blockchain Evidence in Court: A Cross-Jurisdictional Study of Admissibility and Weight.

Sources

European Union Intellectual Property Office. The Court of Marseille recognised blockchain timestamping as legitimate evidence of copyright ownership. Case summary: Tribunal judiciaire de Marseille, First Civil Chamber, RG 23/00046, judgment of 20 March 2025. Accessed 27 October 2026
Marco Barulli and Paul Reboh. Blockchain Evidence in Court: A Cross-Jurisdictional Study of Admissibility and Weight. Working paper, v3, website edition. October 2026

No data, no deals: the evidence gap in IP finance

Marco Barulli — Tue, 20 Oct 2026 00:00:00 GMT

Updated: 2026-10-20

Why do lenders hesitate to accept IP as collateral? The EUIPO describes a vicious circle of missing data. Learn what lenders actually need to see, and how your company can break the cycle by providing verifiable evidence.

In IP-backed finance and the disclosure paradox, we looked at a difficulty facing companies seeking finance against their intellectual property: how to give others enough information to assess an asset while preserving its confidentiality.

This time, we cross to the other side of the table. Suppose the company is ready to share that information. Why do lenders still hesitate?

The EUIPO’s 2026 report on IP-backed finance describes a vicious circle. Too few transactions produce too little data. Without reliable data, lenders remain cautious. And cautious lenders make fewer deals.

Breaking that circle requires coordinated work across the financial system. But part of the answer begins much closer to home, with the company’s records and the advisers who understand its assets.

The vicious circle

A bank considering a loan against machinery has something concrete to work with. There are established markets, comparable sales and experience of recovering value when borrowers default.

For IP, those reference points are harder to find. A patent portfolio, a proprietary process and a body of software may each be valuable, but assessing what could be recovered from them is a different exercise. Their usefulness may depend on particular people, complementary technology or a business that knows how to put them to work.

The report describes the resulting caution: lenders apply substantial discounts to estimated values or leave IP out of their recovery calculations altogether.

That caution is difficult to overcome without experience. Lenders need evidence of how IP-backed loans perform, what happens when borrowers default and how much can ultimately be recovered. Yet each institution has little incentive to build that experience alone.

What the report proposes

The EUIPO proposes public guarantees to share lending risk, better data on repayments and recoveries, and a central register of IP pledges to help lenders assess competing claims.

These measures would give lenders more confidence and better reference points. They require coordination and time. Meanwhile, companies can prepare the information every transaction will need: a clear, verifiable account of the assets being offered.

What a lender needs to know about one asset

Consider a company offering proprietary software or a manufacturing process as part of a financing proposal. Before a lender and its advisers can assess it, they need a clear account of what the company holds.

Four questions provide a useful starting point.

What exactly is it?
A registered right has an entry in a public register. A body of source code, a dataset or a confidential process needs another way to establish its boundaries. Which files, versions and supporting materials make up the asset? A description such as “our production software” leaves considerable room for uncertainty.

Who owns it, and since when?
The history may involve founders, employees, contractors and acquired businesses. Assignment agreements and development records help explain how their contributions became part of the company’s assets. A clear chain of title makes that history easier to examine.

Which version is being assessed?
Software changes, datasets grow and processes improve. The parties need to know which version they reviewed and how later developments relate to it. Keeping a dated history allows them to return to the same reference point.

How has confidential material been shared?
For trade secrets and know-how, the conditions of disclosure matter. Who received access, to which material, and under what agreement? A documented sharing history helps advisers understand how confidentiality has been managed.

The answers also help reveal dependencies. A process may require specialist knowledge to operate; software may rely on components licensed from others. Identifying those connections early gives everyone a more useful picture of the asset.

How Bernstein helps build those answers

Much of the information comes from the company’s daily work: development files, contracts, technical documentation and records of disclosure. Bernstein gives those materials a certified history that the company can present and a lender’s advisers can check.

Its role is concrete in each of the four questions.

Identify the exact asset.
Bernstein creates a cryptographic fingerprint of the files in a certified revision. Counsel can reference that revision in an asset description or supporting agreement, giving the parties a precise set of materials to refer to. Files are encrypted before leaving the owner’s device, so even sensitive code, formulations and process documentation can be included without exposing their contents to Bernstein.

Document its history and support the ownership review.
Bernstein anchors fingerprints to the Bitcoin blockchain and trusted timestamp authorities, including EU qualified timestamps. Certifying development records alongside assignments and other agreements gives counsel dated evidence to examine when reconstructing who contributed what and how the company acquired its rights.

Preserve the version under review.
Bernstein keeps immutable, dated revisions together with the encrypted original files. If the software develops during a financing discussion, the version initially reviewed remains available. The lender’s advisers can check that a file matches its certificate and distinguish it from subsequent revisions.

Control and record disclosure.
When a valuer or lender needs access, Bernstein’s secure sharing provides time-limited links, one-time passwords, contract acceptance before access and verifiable access logs. The company can share the relevant material and retain a record of access through that channel.

Together, these capabilities turn a collection of working files into a verifiable record of the asset’s development and disclosure.

For example, a software company preparing for financing could certify a release together with its technical documentation, preserve the relevant contributor agreements, and give a valuer controlled access to that revision. If development continues during the review, everyone can still identify the version on which the assessment was based.

The evidence also remains usable beyond the immediate transaction. Certificates can be verified independently of Bernstein, and owners can export them with the original files and the materials needed for later verification. Preserving that package allows future reviewers to examine the same evidence.

A role for IP counsel

IP counsel brings two kinds of knowledge to a financing discussion: the technical understanding needed to assess the innovation, and familiarity with the client’s assets and how they were developed.

Together, these help counsel explain what a lender is being asked to assess: which assets underpin a product or process, how they relate to one another, and which agreements and records support the company’s rights. For software, trade secrets and know-how, that context can be particularly valuable because much of it will never appear in a public register.

An adviser who knows the client’s development history can also spot what is missing. A contractor’s contribution may need a clearer assignment. An important process may be poorly documented. The version offered for review may differ from the one described in an earlier agreement. Addressing these questions before the financing discussion makes the subsequent review easier.

Bernstein gives counsel a practical way to preserve and substantiate that work. Counsel determines what belongs in the evidence file, connects the technical materials with their legal history, and decides what a reviewer needs to see. Bernstein certifies the selected records, preserves their versions and supports controlled disclosure.

This makes the adviser’s knowledge easier to share with lenders and valuation specialists. They receive a coherent account of the assets, supported by evidence they can examine directly.

Breaking the circle from the inside

The wider market needs more transactions, better data and institutions willing to share risk. Companies and their advisers can contribute by making the assets behind each proposed transaction easier to understand.

That work can begin well before a loan application: identify the assets, preserve their development history, connect them to the relevant agreements and keep track of disclosure. Bernstein makes certification, preservation and controlled sharing part of that ongoing process.

For IP counsel, it is a natural extension of knowing the client and protecting its innovation. When a financing opportunity arises, the company has a documented history ready for review, rather than a reconstruction to begin.

The next article looks more closely at blockchain’s role in IP finance, from the ambitions surrounding tokenised patents to its practical use in creating verifiable records.

Explore how Bernstein helps you build a certified, independently verifiable record of your IP.

Sources

European Union Intellectual Property Office. IP-backed Finance. Executive Summary; sections 2.1.2, 3.1.2 and 3.1.7; Priorities 3 and 4. April 2026

Financing Unregistered Innovation: A Comparative Study of IP-Backed Finance for Trade Secrets, Designs, and Software

Marco Barulli — Mon, 19 Oct 2026 00:00:00 GMT

Updated: 2026-11-06

Trade secrets, proprietary codebases, and unregistered designs represent the dominant share of modern enterprise value, yet they remain largely excluded from secured debt markets due to the absence of public title registries and the resulting information asymmetry between borrowers and lenders. This comparative study examines how uncertificated intellectual assets can support debt financing across the United States, European Union, China, and Japan, with comparative insights from the United Kingdom and Singapore. We advance a central thesis: verifiable digital evidence serves as the structural private surrogate for public registration, bridging the evidentiary gap required to prove legal existence, satisfy statutory secrecy standards, verify unbroken chains of title, and monitor dynamic collateral pools without forfeiting confidentiality. By deploying multi-layered evidence architectures—anchoring cryptographic hashes into public blockchains for decentralized, vendor-independent permanence, while triangulating those records with regional statutory trust frameworks such as eIDAS 2.0 qualified electronic ledgers in Europe and state-recognized timestamps in China—innovators can establish verifiable proof of prior possession and sequential integrity. Furthermore, pairing verifiable evidence of existence with client-side encrypted payload storage can support post-default recovery, helping document statutory "reasonable secrecy" measures and preserve usable technical assets for transfer to a creditor or liquidator, subject to applicable rights and access arrangements. While the substantive mechanisms for encumbrance vary—from Article 9 general intangibles in the United States and specialized software exploitation pledges in France to fiduciary security assignments (Sicherungsabtretung) in Germany and comprehensive enterprise-value charges in Japan—every financing route ultimately hinges on the creditor's ability to verify, monitor, and liquidate asset value. Incorporating key statutory developments—including eIDAS 2.0 (Regulation (EU) 2024/1183), the European Union Design Reform Package (Regulation (EU) 2024/2822 and Directive (EU) 2024/2823), China’s revised Anti-Unfair Competition Law, the UK Property (Digital Assets etc) Act 2025, and Basel Framework CRE22 capital constraints—this paper demonstrates how digital evidence transforms uncertificated innovation from an unprovable "black box" into bankable collateral. We translate this comparative framework into three commercial financing models and an operational evidence dossier for innovators and credit underwriters.

Paper status

working paper

Version

v1.0

Sources

Your certificate is immutable. Your files are not.

Marco Barulli — Fri, 16 Oct 2026 00:00:00 GMT

Updated: 2026-10-16

How everyday tools can change certified files without an explicit save, and why preserving the exact original matters.

You care about your intellectual property, so you take the proper precautions: you obtain digital timestamps from qualified trust authorities to legally establish that your work existed at a specific point in time.

You store the certificates securely. You keep the files intact. You never intentionally edit or alter them.

Then, when the stakes are high (e.g. defending your copyright or proving prior use in a trademark dispute) you run the verification. It fails.

How does cryptographic proof collapse without any conscious mistake? The answer is subtle: everyday desktop tools routinely alter files in the background without prompting you and without you ever clicking “Save.”

Here are three common scenarios that silently break your chain of custody:

1. Reviewing a PDF in macOS Preview

You open a document, a technical drawing or a schematic. A page is sideways, so you rotate it 90 degrees to read it, then close the window. Because Preview autosaves continuously in the background, closing the window commits that change directly to disk. You never pressed Save, but the underlying file has been rewritten—and the certified hash is permanently broken. (Apple documentation)

2. Rotating a photo in Windows File Explorer

You browse photos of a prototype in Windows. One photo appears sideways, so you click “Rotate right.” The image still shows the exact same invention, but Windows writes that orientation metadata directly into the file structure. Even a “lossless” rotation alters binary data. To human eyes, the image is unchanged; to a cryptographic verification algorithm, it is an entirely different file. (Microsoft documentation)

3. Playing an audio track in iTunes

You import a demo or interview recording into your library to listen to it. If features like Sound Check are enabled, the player can write volume-normalization tags directly into the file’s ID3 metadata. The recorded audio has not changed by a single millisecond, but the container has. The digital fingerprint no longer matches. (ID3 documentation)

Three routine actions: reviewing a document, organizing photos, playing a recording. Three everyday ways to inadvertently sever the link between a certificate and its source file.

A certificate cannot reconstruct the original

A digital certificate anchors a strict cryptographic hash. Change a single bit, even invisible metadata buried in a file header, and the fingerprint mismatch is absolute.

This is true whether your proof is anchored on Bitcoin or issued by a qualified timestamping authority. Neither system can resurrect a lost or modified original; they only attest to the exact sequence of bytes registered at that moment. Overwrite every unaltered copy, and the certificate becomes functionally worthless.

Preserve the version you certified

Your active work shouldn’t have to live under glass. You need to review blueprints, organize design assets, and listen to recordings without accidentally compromising your legal proof.

That is why Bernstein couples cryptographic certification with encrypted, versioned storage. Certified versions remain frozen and verifiable as your project develops, while client-side encryption ensures your proprietary assets remain strictly confidential. See: Bernstein features.

An immutable certificate is only as strong as the file it preserves.

Sources

Apple. Save files in Preview on Mac. Preview User Guide. Accessed 27 October 2026
Microsoft. JpegBitmapEncoder.Rotation Property. System.Windows.Media.Imaging; .NET API documentation. Accessed 27 October 2026
ID3.org. iTunes Normalization settings. COMM: iTunes normalization settings and the iTunNORM tag. Last edited 25 November 2013. Accessed 27 October 2026

Confidential know-how: financing, NDAs and evidence

Marco Barulli — Thu, 15 Oct 2026 00:00:00 GMT

Updated: 2026-10-13

Recent Bernstein articles, our updated research paper, and two things worth your attention elsewhere.

Hello,

I’d like to use this newsletter to share useful reading on IP and innovation every two weeks, with a few observations of my own. This first issue brings together a question that runs through our recent work: how do you make confidential knowledge identifiable and verifiable while keeping control of who can see it?

From Bernstein

Making know-how visible to a lender

The EUIPO’s report on IP-backed finance raises a difficult question for companies whose value lies in confidential know-how. A lender needs enough information to assess an asset. The company needs to protect the information that makes it valuable.

Our new article explores how a dated, verifiable inventory can support that conversation before detailed disclosure. My takeaway: prepare the evidence before the financing discussion starts. It won’t establish a valuation or replace due diligence, but it gives both sides something more concrete to work with.

👉 Read the article on IP-backed finance

Giving an employee NDA a precise reference

An NDA can refer broadly to confidential information. Years later, identifying the files and versions covered by it may be much harder.

This article follows a hypothetical employee from onboarding to departure, showing how agreements can refer to certified collections without reproducing technical secrets in the paperwork. I find the historical revisions particularly useful: an abandoned design may still be confidential, even if it no longer appears in the current project folder.

👉 Read the article on employee NDAs

Our updated research on blockchain evidence in court

Paul and I have published the October edition of our cross-jurisdictional study. It separates four questions: whether a record can be admitted, whether it is intact, when it existed, and how it connects to a person or organisation.

The distinction matters in practice. A timestamp can support evidence of existence and integrity; authorship and ownership require additional evidence. The paper is open access, with a plain-language introduction on our website.

👉 Explore the research and download the paper

Elsewhere in IP and innovation

WIPO: getting science into practical use

The 2026 Global Innovation Index looks at how scientific breakthroughs become businesses that can scale. For me, it raises a practical question: what must a research team have in place before a commercial partner can assess its work?

Explore WIPO’s report

EPO: Europe’s technology transfer challenge

The EPO will discuss how to turn research and patents into market success. I’d listen for what helps a promising project become a collaboration that both sides can actually execute.

October 22, 13:00-14:30 CEST. Programme and livestream

If one of these topics touches a problem you’re working on, reply and let me know. It will help me choose what to cover next.

Best, Marco

IP-backed finance and the disclosure paradox

Marco Barulli — Tue, 13 Oct 2026 00:00:00 GMT

Updated: 2026-10-13

The EUIPO's 2026 report puts 'make IP visible' first on the road to IP-backed finance. For trade secrets and know-how, visibility is the risk. How to disclose the proof without disclosing the secret.

In April 2026 the EUIPO published a foundational report on IP-backed finance: how European companies could use their intellectual property to raise credit and capital, and why today they mostly cannot. It is a long document, 131 pages, written for policymakers and financial institutions. It deserves a wider readership than that.

The figures in the report show why every IP-rich company should pay attention. It estimates the EU’s SME credit gap at up to EUR 365 billion a year, and the share attributable to IP-rich firms at EUR 70-150 billion a year. With the right infrastructure for disclosure, valuation and risk-sharing, it expects IP-backed instruments could mobilise EUR 30-120 billion a year in new financing. IP-intensive industries already generate around 48% of EU GDP. The timing matters too: the Savings and Investment Union is being designed now, and the report’s central argument is that freed capital “flows to where it can be assessed, priced and deployed with confidence.” If IP cannot be assessed, the capital will go elsewhere.

The report maps 18 possible actions across three pillars and orders the most actionable into five priorities: make IP visible, assign it a credible value, leverage that value into lending, build the evidence base, and reinforce coordination. Most of these are jobs for regulators, banks and IP offices, and some will take years.

But every one of them also asks something of the companies that own the IP and of the lawyers who advise them. That side of the story is what this series is about. Over four posts we will read the report from the innovator’s chair:

The disclosure paradox (this post): why the first priority collides with the nature of the asset.
The vicious circle: what a lender actually needs to know about an IP asset, and which part of that you control.
Blockchain in IP finance: what the report gets right about tokenisation, and what it leaves out.
Readiness: a practical checklist for being financeable when the instruments arrive.

Priority 1 runs into a wall

The report’s first priority is to make IP visible. “Before IP can be used for financing, it must be visible, structured and understandable by financial actors.” The starting point is low. Citing earlier EUIPO survey data, the report notes that only 13% of IP right owners have ever tried to obtain financing through their IP assets, and a large majority have never had a professional valuation.

Part of the reason is accounting. IAS 38, the international accounting standard for intangible assets, lets a company show the IP it develops itself as an asset only in narrow cases. Most of that work is booked as an expense, so it never appears on the balance sheet, however valuable it is. The report proposes a voluntary disclosure framework to fill that gap. Its starting point would be the IP Scan, an IP check-up already available to small businesses through the SME Fund, the EUIPO’s grant scheme for EU-based SMEs: an expert designated by the national IP office reviews the company’s business and its IP, and recommends a strategy, with most of the cost reimbursed. The report would turn it into a financing-oriented disclosure tool covering “both registered IP rights and other relevant intangibles.”

The other reason matters most for IP counsel. The report describes innovation finance as a market with severe information asymmetry: investors cannot tell good projects from weak ones, so they price everything as average. Telling them more does not work well, because “innovative ideas can be imitated” and “companies hesitate to share details due to competitive risks, weakening the credibility of their signals.” Elsewhere it notes that disclosure about intangibles “may undermine the firm’s competitive position” and that fear of spillovers to competitors keeps firms quiet.

In other words, the first step towards IP-backed finance asks innovators to do the one thing their IP strategy tells them not to do.

Why it bites hardest on unregistered IP

For registered rights the tension is mild. A granted patent is already public, and the register is the evidence. A lender can look it up.

The problem is everything that is not registered, which in many technology companies is most of the value: source code, process know-how, formulations, training data and models, design files, lab records. Here, secrecy is not a preference. Under the EU Trade Secrets Directive (2016/943), information is protected as a trade secret only if it has been subject to reasonable steps to keep it secret. Each disclosure to a lender, a valuer or an investor is a small erosion of the very thing that makes the asset valuable and protectable.

NDAs help, but an NDA governs how the other side behaves with your information; it does not record what that information was, or when you had it. And a lender asked to accept “we have valuable know-how, trust us” will do what the report says lenders do today: apply a heavy haircut, or leave the asset out altogether.

So the innovator is stuck between two bad options. Disclose, and weaken the asset. Stay quiet, and the asset does not count.

Separate the proof from the content

There is a third option, resting on a simple piece of cryptography. A fingerprint (hash) of a file identifies that exact file. Anyone holding the file can recompute it and check it matches; nobody holding only the fingerprint can work back to the file.

Fix that fingerprint in time with an independent, verifiable timestamp, and you have a sealed envelope with a postmark nobody can forge. It proves that a specific piece of work existed on a specific date and has not changed since, while revealing nothing about its content. Whoever you later allow to open it can check for themselves that it is what you certified.

For IP-backed finance this changes the disclosure step. A company can show a lender a structured inventory of its unregistered assets, each with a certified date and an integrity proof, without handing over a line of the underlying work. When a valuer or the lender’s counsel needs to go deeper, the material can be opened to them alone, with a record of who saw what.

How Bernstein does it

This is what Bernstein has done since 2016. It is an Innovation Evidence Platform: it produces proof of existence, ownership and integrity for digital assets without exposing their content.

Files are encrypted in your browser before they leave your device. Only the fingerprint is used for certification. Bernstein cannot read your content, which is why the evidence can cover your most sensitive material.
The fingerprint is anchored to the Bitcoin blockchain, to EU qualified timestamps under eIDAS, and to a China timestamp authority. For European counsel, the eIDAS anchor carries a legal presumption: under Article 41(2) of the eIDAS Regulation, a qualified electronic timestamp enjoys a presumption of the accuracy of its date and time and of the integrity of the data it is bound to.
Every certification produces a certificate anyone can verify independently, without Bernstein. A lender does not have to trust us, or you.
The certified files themselves are kept, encrypted and versioned. A fingerprint is only useful if you can still produce the exact file it was made from, byte for byte. Over years or decades that is harder than it sounds: files get migrated between systems and re-saved, and some software silently rewrites a PDF’s metadata just by opening it. Change a single byte and the file no longer matches its proof. Bernstein stores the originals exactly as certified, so they are still there, unaltered, when the proof has to be checked.
Revisions are immutable and dated, so the record shows how the work developed, not only that it existed.
Sharing is controlled and logged: time-limited links, one-time passwords, contract acceptance before access, and hash-chained access logs. The same record that supports a valuation also documents the reasonable steps you took to keep the information secret.

What Bernstein does not do is value your IP or decide whether a bank will lend against it. Those remain the work of valuers, lenders and the policy changes the report describes. What it does is remove the reason to stay invisible: you can make an asset legible to a financial counterparty without giving it away.

Disclose the proof, not the secret

The EUIPO is right that IP must become visible before it can be financed. For unregistered IP, the practical way to get there is not more disclosure of content but better disclosure of evidence: what exists, since when, held by whom, and unchanged. That is information a lender can use and a competitor cannot.

In Part 2, we move to the lender’s side of the table. Even when IP is visible, the report finds that banks still discount it heavily, because of a vicious circle in which no transactions means no data, and no data means no transactions. We look at what a lender actually needs to know about a single IP asset, and which part of that answer only the owner can supply.

If you want to see how a certified, verifiable record works in practice, you can find out more at bernstein.io.

Bernstein provides evidence, not legal advice, and does not replace patents, trademarks or contracts.

Sources

European Union Intellectual Property Office. IP-backed Finance. Executive Summary; section 2.1.1 (information asymmetry); section 2.2.2 (identification of intangibles, IAS 38); section 4.1 (Priority 1: make IP visible). April 2026
European Union Intellectual Property Office. IP Scan. SME Fund 2026: IP Scan vouchers

Bitcoin anchoring, explained

Paul Reboh — Sat, 10 Oct 2026 00:00:00 GMT

Updated: 2026-10-10

Reviewer: Marco Barulli

Anchoring writes a hash of your file into a Bitcoin transaction. Because the ledger is public and append-only, anyone can later check that the hash existed no later than that block, without asking you or any provider. The file itself is never on the chain; only its fingerprint is.

Applies to

International

Assumptions

a general, non-technical reader

Why a public ledger

A private database can be edited by its owner. The Bitcoin ledger cannot be rewritten by any single party, which is what makes the anchor independent of the certifying service.

What verification looks like

Recompute the hash of the file, find the transaction referenced in the certificate, and check the hash is there. No account, no API key, no phone call.

Sources

Bitcoin whitepaper, section 3

RFC 3161 and eIDAS qualified timestamps, explained

Paul Reboh — Sat, 10 Oct 2026 00:00:00 GMT

Updated: 2026-10-10

Reviewer: Marco Barulli

RFC 3161 is the technical protocol: a client sends a hash to a timestamp authority, which returns a signed token binding the hash to a time. eIDAS is the legal layer: when the authority is qualified under eIDAS, Article 41 gives the token a presumption of accuracy across the EU.

Applies to

International

Assumptions

a general, non-technical reader

The protocol

The authority never sees the file, only its hash. The returned token is a small signed structure anyone can validate against the authority’s public certificate.

The legal layer

Qualification under eIDAS requires audited time sources and processes. In exchange, the law presumes the date and time accurate and the data intact, shifting the burden to whoever challenges it.

Sources

Make employee NDAs more robust with a verifiable record of confidential knowledge

Marco Barulli — Thu, 08 Oct 2026 00:00:00 GMT

Updated: 2026-10-08

Connect employee NDAs to a verifiable record of confidential knowledge, from onboarding through project development to departure, without reproducing sensitive content in employment paperwork.

When an employee joins a company, they need access to knowledge that makes their work possible. When they leave, confidentiality obligations need to remain connected to the information they received and helped develop.

An NDA establishes obligations. Bernstein helps give those obligations an identifiable reference: preserved project files, certified versions, and sharing under expressly accepted conditions.

This connection matters at three moments: onboarding, project development and departure.

Consider Alex, a hypothetical employee joining Acme to work on a technical project.

Onboarding: certify the knowledge that already exists

Before giving Alex access, Acme collects the confidential project materials relevant to their role. These might include source code, technical specifications, experimental results or a documented manufacturing process.

The company uploads and certifies a baseline revision in Bernstein before Alex joins the project.

Files are encrypted client-side before transmission. Their cryptographic fingerprints are anchored to the Bitcoin blockchain and timestamp authorities, creating independently verifiable evidence of the certified content’s existence and integrity at a particular time. The confidential content itself is not published on the blockchain.

Acme now has a preserved reference for the project knowledge that predates Alex’s involvement. If Alex later claims that particular material originated with them during their employment, the company can produce the earlier files and their corresponding certificate. The baseline supports that factual distinction; employment agreements and contribution records establish the surrounding rights.

Refer to confidential collections without reproducing them

The same certified revision can serve as a reference in Alex’s confidentiality agreement.

Acme prepares a collection of the materials it intends to cover. The agreement identifies that collection by its project name and Bernstein certificate ID, and defines the confidentiality and permitted-use obligations attached to it.

The technical content remains in the encrypted repository. There is no need to reproduce formulas, source code or experimental details in the employment paperwork merely to identify the collection.

This is useful when the protected knowledge spans hundreds of files or contains information that should not circulate with ordinary contracts. Those contracts may later pass through legal reviews, audits or due diligence. A certificate reference allows them to point to a fixed collection without carrying its sensitive contents.

Where the intended scope is the entire certified collection, the agreement can say so expressly, subject to its exclusions, such as information already public or independently developed. A dedicated collection makes this simpler than referring to a mixed project archive and trying to describe confidential subsets in the agreement.

Where detailed verification is needed, the underlying materials can be made available to authorized reviewers through controlled sharing. The certificate provides the reference against which those files can be checked.

Acme then shares the certified collection with Alex through Bernstein.

Sharing can require recipient verification and in-app acceptance of confidentiality terms before access. Those terms can define the permitted purpose, restrictions on further disclosure, and responsibilities for handling the information.

Acme keeps the certified collection, the applicable terms and the record of Alex’s acceptance connected in its documentation.

Each element serves a distinct purpose:

The certified revision fixes the content of the collection and provides verifiable evidence of when it existed.
The confidentiality terms define the obligations attached to that collection.
Alex’s acceptance documents their agreement to those conditions.

The resulting arrangement is more concrete than a standalone NDA referring broadly to company information. Alex is given access to an identifiable body of knowledge under explicit conditions, and Acme preserves the version to which those conditions refer.

During employment: keep the record current

A project changes as people work on it. The onboarding baseline should therefore become the first entry in an ongoing record.

Acme establishes a certification routine around meaningful updates: design changes, development milestones, new experimental results or other significant additions. Bernstein’s immutable revisions preserve successive states of the documented content.

This history helps distinguish the knowledge that existed before Alex joined from developments made during their employment.

The company can use these certified references in project acknowledgements, updated confidentiality schedules or agreements concerning new work. When needed, contribution records can be preserved alongside the technical materials.

When additional material is shared, its certified reference can be connected to the confidentiality terms governing that disclosure.

The benefit is continuity. The company’s agreements and its documented knowledge remain connected as the project evolves.

Departure: refer to an identifiable body of confidential information

When Alex leaves, Acme prepares a current certified revision and a confidentiality schedule for the departure documentation.

The schedule identifies the project and the Bernstein certificate IDs corresponding to the covered collections. The departure agreement or acknowledgement refers expressly to that schedule when restating continuing confidentiality and permitted-use obligations.

This provides a fixed reference for the documented project knowledge at departure. If the scope is later disputed, the company can retrieve the preserved files and verify that they match the referenced certification.

Relevant earlier revisions should also be included. Alex may have received an abandoned design, an earlier formulation or a historical analysis that no longer appears in the latest project files. The revision history allows the company to account for that information without relying solely on the project’s final state.

As at onboarding, these references avoid reproducing sensitive technical details in the departure paperwork. The detailed content stays securely preserved, while the agreement identifies the collections to which the continuing obligations apply.

The departure record reinforces the obligations established during employment and makes their subject matter more specific.

Keep the evidence confidential and available

Preserving evidence should not require unnecessary disclosure of the information being protected.

Bernstein combines client-side encryption, immutable revisions and sharing with recipient verification and acceptance of terms. Acme can preserve its confidential project materials and make them available to Alex under defined conditions.

This separation is central to the workflow: agreements refer to identifiable certified collections, detailed content remains protected, and the originals are preserved for verification when required.

Certification fixes the reference. The confidentiality agreement defines the obligations. Neither requires the company to expose its technical knowledge in paperwork that may circulate more widely.

Give confidentiality obligations a concrete reference

With Bernstein, Acme can connect Alex’s employment to a documented sequence:

Certify the project baseline before onboarding.
Share the relevant collection under expressly accepted conditions.
Preserve certified revisions as the project develops.
Reference the relevant certified collections in departure documentation.

The result is a clearer connection between the company’s knowledge, the information made available to the employee, and the obligations attached to it.

That is how Bernstein can make employee NDAs more robust: by giving confidentiality agreements a precise, verifiable reference while keeping the underlying knowledge securely preserved.

Hashes and what they prove

Paul Reboh — Thu, 08 Oct 2026 00:00:00 GMT

Updated: 2026-10-08

Reviewer: Marco Barulli

A hash is a fixed-length fingerprint of a file. The same file always gives the same hash; any change, however small, gives a different one. A hash proves identity between two copies of a file. Combined with a timestamp, it proves that this exact file existed at that time. Alone, it proves nothing about time.

Applies to

International

Assumptions

a general, non-technical reader

One-way by design

You cannot reconstruct the file from the hash, which is why a hash can be published or anchored without disclosing anything.

The pairing that matters

Hash plus timestamp is the atomic unit of digital evidence: identity plus date. Everything else in this library is commentary on that pair.

Sources

NIST, Secure Hash Standard (FIPS 180-4)

Blockchain Evidence in Court: A Cross-Jurisdictional Study of Admissibility and Weight

Marco Barulli — Thu, 01 Oct 2026 00:00:00 GMT

Updated: 2026-10-01

Courts across the common-law and civil-law worlds no longer ask whether a blockchain-anchored record is admissible, but how much weight it deserves. This paper surveys the admissibility and probative value of blockchain records and electronic timestamps in more than thirty jurisdictions, drawing on primary law, case law and literature in more than a dozen languages. It sets out the four questions every court asks (admissibility, integrity, time and attribution), the three procedural traditions that shape the answer, and the international instruments that make electronic records admissible, including UNCITRAL's model laws, eIDAS and Implementing Regulation (EU) 2025/2531 on qualified electronic ledgers. It analyses the leading decisions and rules, among them China's Online Litigation Rules, the Tribunal judiciaire de Marseille's 2025 anteriority ruling, OLG Jena on screenshots, the Sterlingov Daubert rulings affirmed by the D.C. Circuit in 2026, and the Supreme Court of India's 2026 order on the hash-value certificate. The paper distinguishes what a ledger proves (existence, integrity and time under the control of a key) from what it does not (authorship, identity and authenticity before anchoring), and compares public, consortium and private ledgers. It concludes with eight technology-neutral design criteria for digital evidence that holds across forums.

Paper status

working paper