Can You Patent a Service or Business Model? What You Can Protect Is the Technical Mechanism Behind It

In my 20 years of practice, clients have often brought me a new service idea and asked, "Can we patent this?" A new delivery model, a new way of sharing rental equipment, a new booking system. My answer is usually the same: the model is not the point. The point is what you specifically did, technically, to make the model work.

This article explains, primarily through the lens of Chinese invention patent examination, what is worth filing in a service innovation, where applications typically get rejected, and how to organise your material. The underlying logic carries over to Europe and the US.

Can a service or business model innovation be patented at all?

Start with the legal framework. Article 2(2) of the Chinese Patent Law defines an invention as a new technical solution relating to a product, a process or an improvement thereof. Article 25 excludes "rules and methods for mental activities", which is where pure pricing rules, marketing strategies and business models fall.

That does not mean anything commercial is excluded. Part II, Chapter 9 of China's Patent Examination Guidelines sets out specific rules for applications containing algorithmic features or business rule and method features. The core principle is to consider the claim as a whole, looking at the relationship between its technical and business features and asking whether together they use technical means to solve a technical problem and achieve a technical effect. Using a computer is not, by itself, enough.

Other major systems draw a comparable line. In Europe, features that do not contribute to technical character are generally disregarded when assessing inventive step under the EPO's COMVIK approach. In the US, the Supreme Court's Alice decision asks whether a claim directed to an abstract idea adds "significantly more". The vocabulary differs; the practical lesson is the same.

So under Chinese invention patent practice, what is worth filing in a service or business model innovation is the concrete technical implementation that supports it.

Whether a service innovation can be patented depends not on how novel the business model is, but on whether the technical changes made to deliver it are specific and solve a technical problem. You protect the mechanism, not the idea.

Where do patentable technical solutions hide in a service innovation?

The three directions below are partly modelled on published examination examples and partly illustrative mining directions. The following are illustrative examples, not real client cases.

Batch notification in a logistics service. "When a parcel arrives, notify several people at once" is a business idea. But if delivering it required coordinated changes to the data architecture and communication between the server, the logistics terminal and the user terminals, there is a technical solution to discuss.

Automatic return in shared equipment. "Borrow anywhere, return anywhere, settle automatically" is a service model. What can be mined is how the device combines lock status, location and sensor signals to recognise a genuine return and avoid false judgements. What you protect is the recognition and control mechanism, not the return-anywhere model.

Concurrency handling in online booking. "Book, cancel, waitlist" is a business process. But if, to cope with large numbers of requests arriving simultaneously, you designed specific resource locking, conflict handling and state synchronisation mechanisms, that may form a technical filing point.

The common thread: the business idea is only the entry point. What goes into the claims is the concrete arrangement of data, communication, recognition or control built to realise it.

What are the most common reasons business method applications get rejected?

In my experience, there are three recurring traps:

1. The substance is only a business rule. The core is a pricing, discount, ranking or allocation rule. Adding words like "server" or "AI" to the claims still does not solve any technical problem, and the application fails as non-patentable subject matter.

2. It is technical, but not inventive. The solution has technical features, but it simply uses conventional technology to implement a business requirement: the business rule is new, but the implementation is something any practitioner would do routinely. It clears the subject-matter hurdle and fails on inventive step.

3. It says "smart matching" or "automatic optimisation" without explaining how. The description lists benefits but never says how the matching works, what the optimisation is based on, or what the steps are. In China, that leads to insufficient disclosure (Article 26, paragraph 3) or claims not supported by the description (Article 26, paragraph 4). Europe and the US have equivalent sufficiency and support requirements.

Three traps sink most business method filings: only a business rule, a conventional technical implementation, or effects without process. Adding "server" or "AI" to the claims fixes none of them.

How should you organise the application material?

My advice is to reorganise the material from "business goal" into "technical problem, concrete mechanism, technical effect".

Take a booking system as an illustrative example. If the disclosure says "improve booking success", that is a business goal; an examiner cannot see the technical problem. Reframed as a technical problem, it becomes: "concurrent requests cause the same equipment time slot to be booked twice." Then describe the mechanism you actually use:

• what lock or occupancy marker reserves a slot;
• when the state check is performed;
• what the conflict-resolution rules and steps are when requests collide;
• how recovery works when something fails midway, such as an interrupted payment or a network timeout.

Finally, explain the technical effect of that mechanism: no double occupancy and a consistent state.

Organised this way, the examiner is no longer looking at a business idea but at a solution with a defined technical problem, specific technical means, and a corresponding technical effect.

What lines should never be crossed when preparing the application?

I make two points clear to every client:

First, the mechanisms must really exist. Never invent them for the filing. If your system does not actually have a dedicated conflict-handling mechanism, you cannot describe one just to make the application look more technical. A patent application must be grounded in genuine inventive work.

Second, once filed, amendments cannot go beyond what the original description and claims disclosed (Article 33 of the Chinese Patent Law; Europe and the US have equivalent rules against adding new matter). The technical mechanism has to be in the application on day one. Remembering implementation details only when an office action arrives is usually too late.

Pure business rules cannot be turned into a patentable technical solution through wording. Rather than polishing the language, go back to the engineering and ask what technical problem you actually solved to deliver the service.

This is not legal advice; consult a qualified patent attorney for your situation.

The bottom line

The difficulty with service innovation patents is not making a business idea sound technical. It is finding the real technical contribution behind it. If you have not yet worked out which technical problems your service model raises and what mechanisms solve them, the tool below can help you lay out the technical problem and its contradictions first.