Mobile applications fall into class 9. The reason is simple: the user downloads a copy of the application to their device, so what exists is a product. Class 9 covers downloadable software.
But most applications have two layers, and the second falls into a different class:
- Class 9 — the application file the user downloads
- Class 42 — the server, cloud service or subscription dashboard behind the app
For a purely front-end app, class 9 suffices. If a service runs behind it and that is where the revenue comes from, class 42 is needed too.
Class Map by Application Type
| Application type | Core class | Often added |
|---|---|---|
| Utility app working offline | 9 | — |
| Subscription service app (SaaS client) | 9 + 42 | 35 (if there are sales) |
| Game | 9 | 41 (online game service), 35 (in-game sales) |
| E-commerce / shopping app | 9 + 35 | 42 |
| Social network / messaging | 9 + 38 | 42, 45 |
| Education app | 9 + 41 | 42 |
| Health / fitness tracking | 9 + 44 | 42 |
| Finance / payment app | 9 + 36 | 42 |
| Food ordering / reservations | 9 + 43 or 35 | 42 |
| Maps, navigation, transport | 9 + 39 | 42 |
Class 9 or Class 42? A Practical Test
Ask this: does the user download anything?
- If yes → class 9 is needed.
- If access is only through a browser → class 42 suffices and class 9 is unnecessary.
- If there is both an app and a web dashboard → both make sense.
Taking an unnecessary class has a price: classes not put to genuine use within five years of registration are open to a revocation request (Article 26). Taking class 9 for a purely web-based product creates that risk.
The full framework of the 9/42 distinction: Which Class Does Software Fall Into?
Risks Specific to the App Economy
1. Store complaint mechanisms
This is the most concrete risk for app developers. The App Store and Google Play can remove applications following trademark infringement notices.
The critical point: having published first does not protect you. If you have not registered your name and someone else does, they may use the complaint route to have your app removed. A user base built over years can be lost that way.
2. Descriptive names
App names frequently state the function outright: "Invoice Tracker", "Calorie Counter", "Quick Note". Such names may be refused as descriptive, and even where they are registered they are weak — competitors may freely use similar names.
Additions such as "App", "Mobile", "Go", "Pro" and "Plus" add no distinctiveness and are stripped out in the similarity assessment.
3. App name versus company name
In the app economy market value nearly always sits in the app name, not the company's. If the budget is limited, give priority to the name the user searches for, downloads and recommends.
4. Icon and interface
An app icon may be registered as a figurative mark if it is distinctive. The interface design is, as a rule, the subject of design registration. The differences: Trademark, Patent, Design or Utility Model?
Registration Before Investment
In investor discussions the IP portfolio is a standard diligence item. An unregistered product name is recorded as a risk in the due diligence process.
The app name should also be considered alongside the domain; owning a domain confers no trademark right: Does Owning a Domain Give Trademark Rights?
The International Dimension
Applications are borderless by nature, but trademark protection is territorial. A Turkish registration has no effect in other countries. If your target markets are defined, a multi-country filing through the Madrid Protocol may be worth considering: International Registration and the Madrid Protocol.
Before You File
Classes 9 and 42 attract heavy filing in Türkiye. Checking your app name in your chosen classes shows both refusal risk and store-complaint risk in advance.
Let Us Define Your Scope
Share your application architecture and revenue model, and our trademark registration team will set the 9/42 balance and identify any additional classes needed.