The Freename name collision patent, in plain language

A patent on how colliding names are resolved was granted to Freename AG on August 26, 2025. The application window for ICANN’s new generic top-level domain round closed on August 12, 2026. Those two dates, read together, explain why the patent comes up whenever holders, applicants and their advisers discuss what happens when the same string exists in two naming systems. The patent is described in very different ways, and not every description matches the document.

This article reads the patent as a careful non-specialist would. It explains what the patent covers, describes the resolution method in plain terms, examines first registration as one of its weighted criteria, and identifies what the patent does not do. After reading it, you should be able to describe the patent accurately, resist over-reading it, and explain to clients or colleagues how it fits the questions that brand protection teams and general counsel are already asking about onchain names.

The article does not express any view on the patent’s validity, scope, or enforceability. Those questions are for your own counsel.

US 12,401,618 B1patent number, held by Freename AG

February 23, 2024filing date

August 26, 2025date of grant

Patent text on Google Patents; grant reported by Domain Name Wire.

What a patent is and what it protects

A patent is a time-limited right granted by a national authority to an inventor or to the party the invention was assigned to. The grant gives the holder the right, for a fixed period, to exclude others from making, using, selling, or importing what the claims describe, within the territory of the granting country. The protection is negative in character: the patent does not give the holder the right to do anything, it gives the holder the right to stop others from doing the specific things the claims define. What precisely the claims cover is a legal question that turns on their exact language, on the record of the examination, and, ultimately, on a court’s interpretation. Reading a patent as a general reader, which is all this article does, gives you an accurate picture of the method the inventor described. It cannot substitute for legal analysis of the claims.

Patents protect methods and systems, not facts or principles. A patent on a scoring method for resolving name collisions does not change what happened before the application was filed. It does not determine who created a name first, and it does not alter the rights that flow from trademark registration or, where the law recognizes it, from use. It sits alongside those legal regimes without superseding them. A holder reading this patent is reading a description of a technical method that one company says it invented. What follows from that is a separate and carefully bounded question.

The identifying facts

Four facts identify the document, and they are the only ones you need to cite it correctly. The patent is U.S. patent US 12,401,618 B1. It is held by Freename AG, the company behind the Freename registry. It was filed on February 23, 2024. It was granted on August 26, 2025.

Each of these facts carries a limit that is easy to lose in conversation. It is a United States patent, so it is a right under the law of one country. It is held by a company, so it is a private right and not a public rule. It has a filing date and a grant date, and neither of them is the date on which any particular name was registered. And it is a granted patent, which means an examiner allowed its claims. A grant is not a finding by a court about any dispute between two parties.

The problem the patent says it addresses

The problem the patent states is the name collision. A collision exists when the same string, the same characters in the same order, is present in more than one naming system. The patent names one case in particular: new ICANN TLDs colliding with established web3 namespaces.

It helps to see why this can happen at all. The DNS is a single hierarchy. ICANN coordinates the DNS root, the list of TLDs at the top of that hierarchy, and a string can be delegated there only once. Onchain naming systems sit outside that hierarchy. On Freename, for example, a TLD is recorded onchain as a token held in a wallet. Nothing in the DNS prevents a string from being created in an onchain registry, and nothing in an onchain registry prevents the same string from being applied for through ICANN. The two systems do not consult each other.

So two names can be identical strings yet exist in entirely different registries. One might be an onchain TLD. Another might be a TLD applied for through ICANN’s program, or an existing ICANN TLD. When a user or a system queries that string, something has to decide which record responds. Without a defined method, the result depends on whatever the querying software happens to do, and it can differ from one piece of software to the next.

That unpredictability is the gap the patent addresses. It does not claim to eliminate collisions. It describes a method for resolving them when they occur.

The method in plain language

The patent covers rules-based resolution of names that collide. In outline, the method has three parts: competing names are identified, each one is scored, and the result of the scoring decides which one resolves.

“Rules-based” is the important phrase. The decision is not left to chance, to a manual choice, or to a fixed default in favor of one naming system. It is produced by applying stated rules to each of the competing names. The same inputs, run through the same rules, give the same result.

The rules take the form of weighted criteria. A criterion is a characteristic of a name that the method looks at. A weight is the importance given to that characteristic relative to the others. A criterion with a heavy weight moves the result a great deal, and a criterion with a light weight moves it a little. The patent lists several weighted criteria. This article names only one of them, first registration, because it is the one that holders and applicants ask about and because a paraphrase of the full list would drift toward restating the claims.

Two consequences follow from the structure itself, without any reading of the claims. The first is that no single criterion decides the outcome alone, unless the weights are set so that it does. The second is that the method is a property of the software that applies it. It is designed to sit inside software that handles queries for names. It is not a central directory that all traffic passes through. Its reach therefore depends on which software applies it.

First registration as one of the weighted criteria

Among the criteria the patent lists is first registration, meaning the earliest date of creation of a name. It is one criterion among several, and it carries a weight within the scoring.

In plain terms: when two names collide, the method can take into account which one was created first. As the criterion is described, the earlier date counts in a name’s favor.

This matters because it gives precedence in time a defined role in software that applies the method. It does not mean that the first-registered name always wins. The scoring uses several criteria, so a name created earlier may be outweighed by a later name that does better on the others. First registration is an input, not a guarantee.

For TLD holders, the practical implication is narrow but real. The date on which a TLD was created is a piece of data that this method treats as meaningful. On Freename, the registry record is public and anyone can check it on a block explorer, so the date of creation of a TLD is not a matter of anyone’s recollection. It is the kind of date a first-registration criterion looks at.

What first registration is not

The phrase invites three confusions, and each of them leads to an inaccurate description of the patent.

It is not the patent’s own filing date. February 23, 2024 is the date the patent application was filed. It says nothing about when any name was created, and a name is not “covered” or “not covered” according to whether it was created before or after that date.

It is not a trademark concept. Trademark systems have their own rules about who has the earlier right, and those rules vary by country. A date of creation in a naming registry is a technical fact about a record. It is not a date of first use of a mark and it is not a trademark filing date.

It is not a statement about entitlement. A criterion in a scoring method tells software which record to return. It does not say that the party behind the earlier record ought to have the name, in law or otherwise.

What this means inside software that applies the method

The patent describes a method. Software that uses the method, such as a resolver built into a wallet or a browser extension, has to implement it. When such software receives a query for a string that exists in more than one naming system, it scores the competing names and returns the one the scoring favors.

For a holder of an onchain TLD whose string is also applied for through ICANN, this means the following: software that applies this method does not simply defer to the ICANN namespace. It compares the names against the criteria and resolves according to the result. If the onchain TLD was created earlier and does well on the other criteria, it is the one that resolves in that software.

For an applicant in the ICANN round whose applied-for string matches an existing onchain TLD, the inverse applies. That software does not automatically prefer the ICANN string. A string applied for in the 2026 round that collides with an onchain TLD created before it would, under this method, need to do better than the earlier registration on the other weighted criteria in order to resolve there.

The important caveat is that all of this is conditional on the software. A patent gives its holder the right to exclude others from the method. It is not evidence that any given piece of software applies the method, and it is not a guarantee that the market will adopt it. Software that does not apply it behaves as it did before. An ordinary browser resolves names through the DNS, and onchain names resolve outside the DNS root, so that browser does not open an onchain name at all without added support. Support for onchain names exists in some wallets and through browser extensions, it is partial, and it changes. You can review what works on onchain TLDs, with sources, and form your own view of how far that support reaches.

One further distinction keeps the reasoning clean. “Which name resolves in this software” and “which name is the real one” are different questions. The method answers the first, for the software that applies it. Nothing in a resolution method answers the second, and for a string that exists in two naming systems the second question may have no single answer.

What the patent does not do

This section needs the most careful reading, because the patent is sometimes described in terms that exceed what it does.

A few of these deserve elaboration.

The patent does not decide ownership. An onchain TLD is held by whoever holds the token that represents it in the registry. Rights in a trademark come from registration with a trademark authority or, in some jurisdictions, from established use. A scoring method applied in resolution software is a technical tie-breaker. It is not a legal determination of rights. A dispute about rights in a string, whether it is framed as trademark infringement, bad faith or breach of contract, is resolved through the legal mechanisms that govern those claims, not through this patent.

The patent does not bind ICANN. ICANN decides which strings are delegated in the DNS root under its own policies, its own application rules and its own procedures for objections and for competing applications. A patent held by a private company describes a method that software may apply. It is not a court ruling, and it places no obligation on ICANN to take the method into account.

The patent does not replace trademark law. Whatever protection a brand has in a string comes from its trademark rights, not from any scoring method, and that is as true for a trademark TLD as for any other use of the mark. If a brand holds registered rights in a string and the same string exists as an onchain TLD, the trademark owner’s position is assessed under the trademark law of the countries concerned. The UDRP, the dispute policy that registrants of domain names in ICANN’s generic TLDs accept through their registration agreements, covers those domain names. It was not written for onchain names, and the patent does not extend it to them. The patent adds nothing to that analysis and takes nothing away from it.

The patent is also territorial. It is a right under U.S. law. Whether corresponding rights exist elsewhere is a factual question this article does not address, and you should not assume an answer in either direction.

Why the timing matters

Two dates belong to the patent itself: the filing on February 23, 2024 and the grant on August 26, 2025. The application window of the ICANN round, the first in more than a decade, closed on August 12, 2026. The order of those dates is the reason the patent draws attention.

The grant came almost a year before the window closed. A public, granted patent naming collisions between new ICANN TLDs and established web3 namespaces as a problem therefore existed while applications could still be filed. An applicant who looked could find it. That is a statement about what was public, not about what any applicant knew or should have done.

The order of the dates supports one modest conclusion: the collision question was not raised after the fact. It was stated, in a public document, before the list of applied-for strings was fixed.

It does not support two others. It does not show that ICANN’s process takes the patent into account. ICANN has its own procedures for applications that compete for the same string and for objections from third parties, and those procedures run on ICANN’s rules. Whether and how a private patent on resolution scoring touches them is uncertain, and it is a matter for each applicant’s own counsel. Nor does the order of the dates give earlier onchain names a legal priority over later applications. The priority that the method assigns exists inside the scoring, in the software that applies it.

The timing also bears on the side-by-side comparison between an ICANN dotBrand and an onchain TLD. An ICANN TLD resolves everywhere the DNS does, which is nearly everywhere, and on that measure the DNS is simply better. The patent does not change that. What it does is describe a method under which, in software that applies it, resolution of a contested string can go to the onchain name, and it does so in a document that is part of the public patent record.

How holders and applicants can reasonably read it

Neither holders nor applicants should read more into this patent than it says. Here is a grounded account of what each group can take from it.

For onchain TLD holders

If you hold a TLD on the Freename registry, the patent tells you that the company behind the registry holds a patent on a collision method in which the date of creation of a name is one weighted input. That is a fact about a published method. It is not, on its own, a statement about how any particular wallet, browser or extension behaves.

It is not a guarantee that your name resolves in preference to an ICANN TLD. Support for onchain names is partial. Software that uses a different way of resolving names, or that does not handle collisions at all, does not apply this method.

What is reasonable: if you hold an onchain TLD whose string has also been applied for through ICANN, both the patent and the legal frameworks around names are relevant to your position. Understanding both clearly is more useful than leaning on either one. In a conversation with a buyer or an adviser, the accurate sentence is short: the TLD has a public date of creation, and a published method exists in which that date counts. The inaccurate sentences are the ones that turn this into a right against the applicant. If you want a structured view of where your TLD stands before such a conversation, the TLD Readiness Score on this site is one place to start.

For ICANN applicants

If you have applied for a string that matches an existing onchain TLD, the patent is part of the environment you operate in. It does not block your application. ICANN’s process runs on its own rules. It does mean that, even if your string is delegated, software built on this method will not automatically prefer your TLD over an earlier onchain registration.

The practical question is not whether the patent is valid or enforceable against you, which requires legal advice. It is whether the audience you care about reaches names through the DNS or through software that resolves onchain names. For most uses the answer is the DNS, and the collision changes little. If your plans depend on wallets or similar software, the collision becomes a planning question as well as a legal one.

For applicants whose string is a brand name, a related question is whether the same string already exists as an onchain TLD. The Namespace Exposure Score gives a first view of how exposed a brand is onchain, and it is better consulted before anyone assumes the field is clear.

How to describe the patent in a memo

Most errors about this patent are errors of wording, and a short test catches them. A sentence about the patent is safe when its subject is the method and its verb is “describes” or “covers”. It becomes unsafe when its subject is a party and its verb is “owns”, “wins” or “must”.

“The patent covers a method that scores colliding names, and first registration is one weighted criterion” is accurate. “Under the patent, the first registrant owns the name” is not, because the patent does not address ownership. “The patent means ICANN must recognize earlier onchain names” is not, because the patent does not bind ICANN. “The patent protects onchain holders” is too loose to be right or wrong, and it should be replaced with a sentence that says what the method does and where it applies.

The broader setting of the patent

The tension between the DNS and onchain naming systems is structural. The DNS is a single hierarchy coordinated by ICANN, in which each string exists once. Onchain naming systems are separate from that hierarchy and from each other. That separation is part of what makes onchain names useful for certain purposes, such as names that resolve in wallets, payments to a name, or websites published on an onchain TLD. It also means that the same string can exist in more than one place without any authority to decide between the records.

The patent proposes one answer to that problem. Whether it is the answer that software makers adopt is an open question, and this article does not predict it. What is not open is that the patent exists, that it is public, and that it describes a method in which first registration is a weighted input.

For operators who run a market TLD as a namespace, issuing names such as name.yoursector to members of a sector, the patent is relevant reading for a practical reason. People who take a name under a TLD will ask what happens if the same string is delegated in the DNS. An operator’s documentation is better when it answers that question accurately: resolution depends on the software, a published method exists for deciding collisions, and no method makes an onchain name resolve everywhere.

For advisers, the patent is a useful test of how a file is described. A valuation, a negotiation position or a risk memo that relies on the patent should say which of its statements come from the patent, which come from the behavior of specific software, and which are legal conclusions that counsel has reached. Mixing the three is how over-reading starts.

What to do with this reading

The patent is public. You can read its text on Google Patents, and the grant itself was covered by Domain Name Wire. This article has deliberately not reproduced claim language, because a paraphrase of a claim can be mistaken for the claim. If your situation turns on the claims, read them in the original, and read them with counsel.

For most readers the concrete next step is a check of facts, in this order. Establish whether the string you care about exists in more than one naming system. For an onchain TLD, look at the public registry record and note its date of creation. Then identify the software through which your audience reaches names, because that decides whether a resolution method matters to you at all. Only then decide whether the patent belongs in your analysis, and describe it in the terms set out above.

Where that check raises a concrete question, such as whether to acquire the onchain TLD that matches a brand string, or how to characterize the collision in an agreement, Hush Partners handles such files for holders and for organizations. The contact form is the starting point, and every exchange is covered by a standard mutual NDA.

Questions people ask

Does the patent give Freename the right to resolve any name it chooses?

No. The patent gives Freename AG the rights of a patent holder over the method the claims describe. It gives Freename no authority over names held in other registries, and none over resolution in the DNS. What a user’s software resolves depends on the resolver that software uses and on how it is configured.

Does the patent count in ICANN’s own procedures?

ICANN’s procedures for objections and for competing applications run on ICANN’s rules, and the patent is not one of them. Whether the patent could matter in separate legal proceedings is a question for counsel in the jurisdiction concerned. This article offers no view on it.

Is first registration the same thing as priority in an ICANN application?

No. First registration, in the patent, is the earliest date of creation of a name, used as an input to a score. Any ordering among ICANN applications is set by ICANN’s rules. These are separate frameworks that do not share a concept of priority, and a date in one has no automatic meaning in the other.

If a string was created onchain after an ICANN application was filed, does the method still apply?

The method concerns names that collide, whichever came first. An onchain name created later would not have the benefit of the first-registration criterion. The outcome would then depend on the other criteria and on their weights, in the software that applies the method.

Where can I check whether an onchain TLD already exists for a brand string?

The Trademark Name Check on this site is a free check for a given brand string. If any term in this article needs a reference point, the glossary defines the terms used across the site.