Application Details
Last published on: 7 October 2026 at 15:37 UTC
Application Responses
Section: Applying Entity Information
This question set collects information regarding the legal entity that would enter into a Registry Agreement with ICANN upon successful completion of all relevant application processes. The information collected is intended to be used for background screening.
Provide the full legal name of the applying entity as it appears on the official registration documents. Do not use abbreviations.
Internet DotTrademark Organisation Limited
Provide the long form (no acronyms) of the legal entity form/business structure of the applying entity as it appears on the official registration documents. If the original script of the legal entity form/business structure is not English, ONLY provide its official English translation. No additional information should be provided as this will be used for the automatic population of the Registry Agreement.
Private Limited Company/Body Corporate
The jurisdiction indicates the location in which the business of the applying entity is registered for legal and financial purposes. This is either 1) a country name, or a 2) state/territory name, depending on where the applying entity is registered. No additional information should be provided as this will be used for the automatic population of the Base Registry Agreement. Examples include "Delaware", "Germany", etc.
Hong Kong, China
Provide the website URL of the applying entity, if available.
https://www.trademarkdomain.com/
1. Choose Yes or No. 2. Use the definition of Affiliate from the Base Registry Agreement (see https://www.icann.org/en/registry-agreements/base-agreement).
true
1. Specify if the applying entity is an existing registry operator, ICANN accredited registrar, and/or an Affiliate of a registry operator and/or registrar. 2. If the applying entity is an Affiliate, provide the details of such Affiliate relationship, including the name of the affiliated registry operator and/or registrar. 3. If the applying entity is an ICANN accredited registrar, specify the registrar ID number.
The applying entity is an existing registry operator for the TLDs .xn--czr694b and .xn--imr513n. The applying entity (Internet DotTrademark Organisation Limited, Hong-Kong SAR) and ShangYu Global Technology Co., Ltd. are entities subject to the same ultimate controlling party. Both entities are ultimately controlled by the same natural-person controller through an intermediate Cayman Islands holding company. ShangYu Global Technology Co., Ltd. (IANA ID 3813) is an ICANN-accredited registrar. Jiang Yu Liang Cai Technology Company Limited, a wholly-owned subsidiary of ShangYu Global Technology Co., Ltd., acts as the registry operator for the delegated gTLD .xn--otu796d. There is no direct shareholding between the Hong Kong-based applicant entity and either the accredited registrar or its registry operator subsidiary. Ultimate control is exercised via the top-level Cayman Islands holding platform.
Choose Yes or No.
false
86
Provide the primary business phone number without including the country code.
13521738308
Provide the primary business email address of the applying entity.
sunxuejie@tdnnic.org
Enter the street address (no PO Box).
Rm 1502, Building 7, No. 9 Shouti South Road, Haidian District
Enter the city, village, municipality, etc.
Beijing
Enter the state, province, department, territory, prefecture, oblast, etc., if applicable.
Beijing
1. Enter the postal code, if applicable. 2. If a postal code does not exist, type “Not Applicable”.
100037
CN
If applicable, provide the full legal name as it appears on the official registration documents of the Direct Parent Company of the applying entity. Do not use abbreviations.
DotTrademark Holding Limited
Provide the long form (no acronyms) of the legal entity form/business structure of the Direct Parent Company as it appears on the official registration documents. If the original script of the legal entity form/business structure is not English, ONLY provide its official English translation.
Business Company Limited by Shares/Body Corporate
The jurisdiction indicates the location in which the business of the Direct Parent Company is registered for legal and financial purposes. This is either 1) a country name, or a 2) state/territory name, depending on where the Direct Parent Company is registered. Examples include "Delaware", "Germany", etc.
British Virgin Islands
If applicable, provide the full legal name as it appears on the official registration documents of the Ultimate Parent Company of the applying entity. Do not use abbreviations. "Ultimate Parent Company" means, with respect to an Applicant (and, if applicable, a Direct Parent Company), the top-level entity that directly or indirectly possesses the power to direct the management and policies of such Applicant (and, if applicable, a Direct Parent Company) through the ownership of voting securities, as a general partner, as a managing member, by contract, or otherwise. An Ultimate Parent Company is not controlled by any other entity. If there are no intermediary entities between the Applicant and the Ultimate Parent Company, the Ultimate Parent Company would be the same entity as the Direct Parent Company.
DotTrademark Holding Group
Provide the long form (no acronyms) of the legal entity form/business structure of the Ultimate Parent Company as it appears on the official registration documents. If the original script of the legal entity form/business structure is not English, ONLY provide its official English translation.
Exempted Company Limited by Shares/Body Corporate
The jurisdiction indicates the location in which the business of the Ultimate Parent Company is registered for legal and financial purposes. This is either 1) a country name, or a 2) state/territory name, depending on where the Direct Parent Company is registered. Examples include "Delaware", "Germany", etc.
Cayman Islands
Section: Applying Entity Background and Organization
This question set collects information related to the individuals who will have access to TAMS, manage the application, and receive inquiries.
Xiongwei Huang
Xiongwei Huang, Yangyi Wu
DotTrademark Holding Limited
Xiongwei Huang
Xiongwei Huang
Section: Self-Certification
Provide a single document for Self-Certification question Q2.2-1. The document must include only the SC2.2-1.1, SC2.2-1.2, or SC2.2-1.3 statements. Do not modify any of the Self-Certification statements.
1. Provide a single document for Self-Certification question Q2.2-1. 2. The document must include only the SC2.2-1.1 through SC2.2-1.3 statements. 3. Do not modify any of the Self-Certification statements. 4. If the applying entity cannot Self-Certify the SC2.2-1.1 through SC2.2-1.3 statements, provide a document that explains why the applying entity cannot Self-Certify the SC2.2-1.1 through SC2.2-1.3 statements.
Section: Operational/Planning
The document for Q2.3.1 must be a PDF. The document for Q2.3-2 must be an Excel (.xlsx) file.
The document for Q2.3-1 must be a PDF.
Section: Security Policy and Planning
Provide a single document for Self-Certification question AGB Q220, Q5.1-1. The document must include only the SC5.1-1.1 through SC5.1-1.3 statements. Do not modify any of the Self-Certification statements. If the applicant cannot Self-Certify SC5.1-1.1 through SC5.1-1.3 statements, provide a document that explains why the entity cannot Self-Certify the SC5.1-1.1 through SC5.1-1.3 statements.
1. Provide a single document for Self-Certification question Q5.1-1. 2. The document must include only the SC5.1-1.1 through SC5.1-1.3 statements. 3. Do not modify any of the Self-Certification statements. 4. If the applying entity cannot Self-Certify the SC5.1-1.1 through SC5.1-1.3 statements, provide a document that explains why the applying entity cannot Self-Certify the SC5.1-1.1 through SC5.1.1-3 statements.
Section: DNS Abuse
Provide a single document for Self-Certification question AGB Q221, Q5.2-1. The document must include only the SC5.2-1.1 through SC5.2-1.7 statements. Do not modify any of the Self-Certification statements. If the applicant cannot Self-Certify the SC5.2-1.1 through SC5.2-1.7 statements, provide a document that explains why the applying entity cannot Self-Certify the SC5.2-1.1 through SC5.2-1.7 statements.
1. Provide a single document for Self-Certification question Q5.2-1. 2. The document must include only the SC5.2-1.1 through SC5.2-1.7 statements. 3. Do not modify any of the Self-Certification statements. 4. If the applying entity cannot Self-Certify the SC5.2-1.1 through SC5.2-1.7 statements, provide a document that explains why the applying entity cannot Self-Certify the SC5.2-1.1 through SC5.2-1.7 statements.
Section: Primary String
This question set collects basic information regarding the string that is being applied for (for example, a-label, meaning, script). If the applying entity opts to designate a replacement string, it must answer the same set of questions for the replacement string from the AGB Question Set 5 on.
xn--czr694b
商标
U+5546 U+6807
Provide the meaning, or restatement of the string in English, that is, a description of the literal meaning of the string in the opinion of the applying entity. If there is no literal meaning in English (for example, a brand name or a proper noun without a translation) simply state "No English Translation"
Trademark
If an IDN, provide the script of the string (both in English and as referenced by the RZ-LGR/ISO 15924)
Chinese (Han)
Provide a representation of the string according to the International Phonetic Alphabet.
/ʂɑŋ˥˥ pjɑʊ˥˥/
Confirm the statement using a checkbox.
true
1. Describe the mission and purpose of the applied-for gTLD, including the intended registrants and users, and the related activities that have been or will be carried out to achieve this purpose. 1a. If applying for a variant of an existing gTLD, please also describe the mission and purpose of the existing gTLD, including the intended registrants and users, and the related activities that have been or will be carried out to achieve this purpose. 2. Explain how this purpose is sustainable over time.
The mission of the applied‑for Traditional‑Chinese .商標 gTLD is to supply professional registry services for global trademark holders, delivering localized intellectual‑property domain‑name protection for traditional‑Chinese‑using communities worldwide. 1a. Information for the existing simplified‑Chinese .商标 gTLD As its registry operator, we have maintained stable, compliant operation for 12 years, with mature capabilities in IDN‑policy compliance, technical maintenance, anti‑cybersquatting and registry governance. Its intended registrants cover domestic and overseas enterprises, trademark owners and IP agencies, while end‑users are global online brand‑information visitors. Ranking top‑10 among active IDN gTLDs, it satisfies brand‑owners’ demands for online brand layout and trademark defence. We have carried out daily system maintenance, sunrise‑period registration services, anti‑abuse governance and IP‑industry outreach in long‑term operation. Target users and plans for .商標 Simplified and Traditional Chinese characters are two mainstream written forms. Traditional‑Chinese script is widely‑used in Hong Kong, Macao, Taiwan and overseas‑Chinese communities. Target registrants are local brands, overseas‑Chinese‑run enterprises and global trademark agencies needing traditional‑Chinese brand‑domain assets, and end‑users are traditional‑Chinese‑speaking internet users. Complementary to .商标, this gTLD completes the Chinese‑character domain‑name ecosystem. After approval, we will launch regional market promotion, trademark‑owner sunrise registration, cross‑script coordinated management and ongoing ICANN‑compliant maintenance, to reduce trademark‑related domain‑name disputes and boost international‑IP‑right cooperation. 2. Long‑term sustainability Huge‑sized traditional‑Chinese‑using groups sustain steady market demand. Our 12‑year operational experience and shared technical system for two Chinese‑character TLDs guarantee stable‑cost, mature‑standard operation. Dual simplified‑traditional domain‑name resources meet brands’ full‑region asset layout needs and maintain commercial vitality. We will keep updating ICANN‑IDN compliance rules and anti‑abuse mechanisms for long‑term standardized governance.
Section: Variant String(s)
This question set collects basic information regarding any variants of the primary string (AGB Question Set 5) that are being applied for. Loop over multiple variant strings if the string has multiple variant strings.
xn--czro89b
商標
U+5546 U+6A19
Provide the script of the variant string (both in English and as referenced by the RZ-LGR/ISO 15924)
Chinese (Han)
Select an option.
Existing TLD
Provide the meaning or intended meaning (for non-dictionary words) of each of the applied-for variant string(s), including sources. If there is no literal meaning in English (for example, a brand name or a proper noun without a translation) simply state "no English Translation/Meaning".
Trademark
Provide at least three bona-fide examples to support the explanation. (for example, evidence of trademark use by showing real world use cases).
The primary string 商标 (Simplified Chinese) and variant string 商標 (Traditional Chinese) are semantically identical, conceptually equivalent, and universally interchangeable within all global Chinese-speaking communities. The two strings solely differ in orthographic writing form, both exclusively representing the single legal and commercial meaning of “trademark”, with no distinction in definition, function, or public perception. Three bona-fide real-world examples proving equivalence: 1. Cross-jurisdictional official IP regulatory usage Chinese Mainland official IP administrations uniformly adopt the Simplified form 商标 in laws, certificates and administrative documents, while Hong Kong, Macao, Taiwan and overseas Chinese regulatory authorities standardly use the Traditional form 商標. All regional IP institutions recognize the two terms as identical and interchangeable in trademark administration and legal affairs. 2. Global enterprise trademark publicity and brand practice Leading Chinese and multinational enterprises use 商标 for Mainland market announcements and 商標 for Hong Kong, Taiwan and overseas Chinese market statements. The two variants are applied in identical trademark protection declarations, brand disclaimer statements and IP publicity scenarios, serving exactly the same commercial purpose. 3. Judicial and legal recognition in trademark dispute cases Courts and judicial authorities across Greater China consistently treat 商标 and 商標 as equivalent legal concepts in trademark infringement litigation. Judicial rulings confirm that Simplified and Traditional versions of the term carry identical legal meaning, with no substantive difference in trademark identification and right protection.
1. Applying entities shall explain why one label is insufficient and two or more labels are necessary to satisfy regional, linguistic, or cultural drivers. 2. Identify the user communities served by primary and for each of the variant TLDs. 3. How are these user community needs reflected by differences or similarities in the design of the IDN tables offered for the primary and the each variant TLD.
1. Why a single label is insufficient; why two labels are necessary The Chinese language employs two standard, culturally and regionally distinct writing systems: Simplified Chinese (used in Mainland China) and Traditional Chinese (used in Hong Kong SAR, Macao SAR, Taiwan region of China, and most overseas Chinese communities globally). These are not mere stylistic variants but official, legally recognized scripts with long-standing usage conventions in business, law, government, and brand identity. A single label (either 商标 or 商標) cannot adequately serve all Chinese speaking communities: • Users in Traditional Chinese regions and overseas communities strongly prefer and rely on 商標 for legal certainty, cultural familiarity, and brand consistency. • Using only Simplified 商标 would create linguistic, cultural, and practical barriers for trademark owners operating in Traditional Chinese markets. • Two labels are necessary to fully respect linguistic diversity, ensure regional inclusivity, and avoid disadvantaging large, distinct user groups that rely on Traditional Chinese for commercial and IP activities. 2. User communities served by primary and variant TLDs • Primary string: 商标 (Simplified Chinese) Serves: • Enterprises, brand owners, and IP users in Mainland China • Organizations using Simplified Chinese for domestic business and trademark protection • Variant string: 商標 (Traditional Chinese) Serves: • Trademark owners and businesses in Hong Kong SAR, Macao SAR, Taiwan region of China • Overseas Chinese communities across Southeast Asia, North America, Europe, and other regions using Traditional Chinese • Multinational brands targeting Traditional Chinese speaking markets • Legal and IP professionals specializing in cross-border Chinese trademark practice 3. How user needs are reflected in IDN table design The primary and variant TLDs share identical core purpose, registry policy, and registration rules (trademark focused, IP protection oriented). Their IDN tables are designed to: • Support equivalent semantic function while respecting script specific encoding and character conventions; • Maintain consistent eligibility, security, and rights protection mechanisms across both labels; • Differ only in the Simplified vs. Traditional character set to match the linguistic expectations of their respective user communities; • Ensure users in each region can register, use, and trust their preferred script without compromising policy consistency or security. This design ensures both TLDs serve the same global trademark protection mission while accommodating legitimate regional and linguistic user needs.
Provide steps and descriptions that adequately demonstrate all defined criteria are met. See Section 7.6 Variant String Evaluation and Section 3.1.9.2.1 Application Submission of New Primary IDN and its Variant Strings. Notes: Commitments made by an applicant to minimize the noted operational and management complexities will form the basis of contractual requirements to be included in the applicable Registry Agreement.
Steps to Minimize Operational & Management Complexities for Variant gTLDs 商标 / 商標 The applicant commits to implement the following binding measures to eliminate operational complexity for registrars, resellers, and registrants across the primary gTLD 商标 (Simplified) and variant gTLD 商標 (Traditional). These commitments will be formalized in the Registry Agreement per ICANN Section 7.6 and Section 3.1.9.2.1. 1. Unified Registry Platform & Shared Technical Infrastructure • Deploy a single, integrated registry system for both 商标 and 商標 with identical back-end architecture, EPP commands, DNSSEC, and registration data specs. • No separate systems or custom integrations; registrars use one set of technical interfaces to support both TLDs, eliminating dual-platform overhead. 2. Identical Policies, Eligibility & Registration Rules • Maintain fully aligned registration policies, eligibility criteria, TMCH checks, abuse mitigation, and dispute processes across both TLDs. • Registrants face identical terms; registrars avoid conflicting rule sets or divergent compliance burdens. 3. Synchronized Pricing, Promotions & Lifecycle Management • Align registration, renewal, transfer, and restore fees and timelines. • Use synchronized billing cycles and status codes to prevent operational drift and registrar reporting complexity. 4. Unified Registrar & Reseller Support Framework • Provide a single helpdesk, documentation portal, and training program covering both TLDs. • Publish one consolidated registrar manual and API guide to reduce training, integration, and query costs. 5. Consistent IDN Table Design & Script Alignment • Design IDN tables to be structurally parallel, differing only in Simplified vs. Traditional character sets while preserving identical logic, permitted characters, and variant handling. • Ensure uniform parsing, validation, and confusability controls to avoid user or system confusion. 6. Centralized Reporting, Data & Compliance Outputs • Generate consolidated monthly/quarterly reports, registry statistics, and compliance data in a single format. • Simplify ICANN reporting, audit, and reseller reconciliation through unified datasets. 7. Coordinated Brand, Abuse & Rights Protection Services • Operate a single trademark protection engine, abuse monitoring system, and takedown workflow for both TLDs. • Ensure consistent rights protection standards without duplicative processes for rights holders. 8. Binding Long-Term Operational Commitment • The applicant formally commits that the above unified model will be maintained for the full term of the Registry Agreement to ensure long-term stability and minimal complexity. • No divergent policies, systems, or fees will be introduced that would create disparity between the primary and variant TLDs. ________________________________________ Summary of Compliance with ICANN Criteria These measures directly address ICANN’s requirements to limit complexity by: • Using shared infrastructure to avoid redundant systems; • Applying uniform rules to eliminate registrar/registrant confusion; • Aligning IDN table design to reflect linguistic differences without operational divergence; • Establishing binding contractual commitments to sustain the simplified model long-term. This framework ensures stable, low-complexity operation that benefits all users while upholding DNS security, stability, and compliance with ICANN variant string rules.
Confirm the statement using the checkbox.
true
Section: Safeguard Identification
This question set collects information related to determining whether certain Safeguard Public Interest Commitments (Safeguard PICs) are required for the applied-for gTLD string. See Section 7.8.2.3 Safeguard PICs. Answers to these questions will inform assessment by ICANN on whether and which Safeguard PICs must be incorporated in the applicable Registry Agreement (RA) if the string proceeds to delegation. The answers themselves will not automatically make such a determination.
1. When answering the questions, apply criteria by considering the meaning of the requested TLD string in the following contexts: a. Literally as described in the application b. Literally in any other language in which the string is a recognized word or phrase. c. Informally in any language or regional variant, where alternative meanings exist. 2. If the proverbial “reasonable person” who understands the relevant context believes that the question should be answered ‘yes’, then the answer is yes.
Yes
1. When answering the questions, apply criteria by considering the meaning of the requested TLD string in the following contexts: a. Literally as described in the application b. Literally in any other language in which the string is a recognized word or phrase. c. Informally in any language or regional variant, where alternative meanings exist. 2. If the proverbial “reasonable person” who understands the relevant context believes that the question should be answered ‘yes’, then the answer is yes.
Yes
1. When answering the questions, apply criteria by considering the meaning of the requested TLD string in the following contexts: a. Literally as described in the application b. Literally in any other language in which the string is a recognized word or phrase. c. Informally in any language or regional variant, where alternative meanings exist. 2. If the proverbial “reasonable person” who understands the relevant context believes that the question should be answered ‘yes’, then the answer is yes.
No
1. When answering the questions, apply criteria by considering the meaning of the requested TLD string in the following contexts: a. Literally as described in the application b. Literally in any other language in which the string is a recognized word or phrase. c. Informally in any language or regional variant, where alternative meanings exist. 2. If the proverbial “reasonable person” who understands the relevant context believes that the question should be answered ‘yes’, then the answer is yes.
No
1. When answering the questions, apply criteria by considering the meaning of the requested TLD string in the following contexts: a. Literally as described in the application b. Literally in any other language in which the string is a recognized word or phrase. c. Informally in any language or regional variant, where alternative meanings exist. I-2. If the proverbial “reasonable person” who understands the relevant context believes that the question should be answered ‘yes’, then the answer is yes.
No
1. When answering the questions, apply criteria by considering the meaning of the requested TLD string in the following contexts: a. Literally as described in the application b. Literally in any other language in which the string is a recognized word or phrase. c. Informally in any language or regional variant, where alternative meanings exist. I-2. If the proverbial “reasonable person” who understands the relevant context believes that the question should be answered ‘yes’, then the answer is yes.
No
Select Yes or No. Notes: 1. ICANN will evaluate whether an applied-for gTLD string requires one or more Safeguard Public Interest Commitments (Safeguard PICs) to be included in the Base RA). 2. In addition to the Mandatory Public Interest Commitments (PICs) that must be included in each Base RA, a subset of Base RAs must include Safeguard PICs based on ICANN’s Safeguard Assessment. See Section 7.8.2.3 Safeguard PICs. 3. Applying entities for TLDs that are not found to require Safeguard PICs can elect to add them to the applicable Base RAs voluntarily to, for example, further their business objectives, help address issues or concerns that are raised or could be raised with respect to their applications, or avoid the need for the evaluation and implementation of customized Registry Voluntary Commitment (RVC). See Section 7.8.3 Registry Voluntary Commitments (RVCs).
No
Section: Registry Voluntary Commitments (RVCs)
This question set collects information related to any Registry Voluntary Commitments (RVCs) that the applying entity is submitting. The decision to submit an RVC is typically voluntary, except for those recognized by ICANN to resolve an objection or to address GAC Consensus Advice. See Section 7.8.3 Registry Voluntary Commitments for more information.
1. Select Yes or No. 2. In addition to Safeguard Public Interest Commitments (PICs), an applying entity will be permitted to propose one or more Registry Voluntary Commitments (RVCs) to provide additional safeguards with regard to the registry operator’s operation of an applied-for gTLD string. See Section 7.8.3 Registry Voluntary Commitments (RVCs). 3. RVCs are separate from Community Registration Policies. See Section 7.8.3 Registry Voluntary Commitments (RVCs) and Section 7.8.4 Community Registration Policies for more information. If you are applying for a Community gTLD, please submit the Community Registration Policies by answering Questions 150-155. However, if you propose to include additional Registry Voluntary Commitments in the RA beyond the Community Registration Policies, you may answer "yes" and proceed to answer the following questions. 4. You are encouraged to consider whether there are other means, separate from including commitment(s) in the Base RA, that could be used to further your business objectives or help resolve any anticipated or actual issue(s) raised regarding the applied-for gTLD string or application. See Section 7.8.3 Registry Voluntary Commitments (RVCs). Notes: If you select “yes” to this question, you are required to pay the conditional Registry Commitments Evaluation fee, and commitments that are approved by ICANN will be included in Specification 11 of the applicable Base RA as specific voluntary public interest commitments as contractual obligations.
No
Section: Brand & Code of Conduct Exemptions
This question set collects information related to whether the applied-for gTLD string is a .Brand (see Section 7.3) or if the applying entity is seeking a Code of Conduct exemption (see Section 7.4).
Select Yes or No
No
This serves as an indication of intent to apply for an exemption to Specification 9 and that the applying entity is NOT requesting to be designated a .Brand TLD, pursuant to Specification 13.
No
Section: Additional Information and Supporting Materials
This question set collects any additional information that the applying entity would like to provide, including any supporting materials.
Section: Bona Fide Intent and Prohibited Communications
This question set contains attestations related to the applying entity’s acknowledgment of bona fide intent and prohibited communications.
Confirm the statement using the checkbox.
true
Confirm the statement using the checkbox.
true