Insights by Bernstein: Learn

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

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

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

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

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

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)