Asking when a service innovation can be patented usually means asking the wrong question first. Getting a service innovation patented depends on finding the technical mechanism inside it.
A service cannot be patented. Neither can a business model, a workflow, or a way of organising people and transactions. Those are abstract ideas.
What can be patented is a specific technical mechanism used to deliver something — a method with defined steps producing a defined technical effect.
The gap between those two is where almost every application in this area fails, and closing it is a drafting and framing exercise rather than a legal argument.
The Alice two-step
| Step | Question |
|---|---|
| One | Is the claim directed to a judicial exception — an abstract idea? |
| Two | If so, do the elements amount to significantly more than the exception? |
Step one is where service claims usually fail. Methods of organising human activity, fundamental economic practices, and mental processes are all abstract ideas.
Step two rarely rescues them. Generic computer implementation does not supply an inventive concept, so reciting a processor, server, database or mobile device adds nothing.
The claim must recite how, not what. That single distinction predicts outcomes better than any other test. See what can be patented.
What counts as an abstract idea
| Category | Examples |
|---|---|
| Fundamental economic practices | Hedging, escrow, pricing, insurance, intermediated settlement |
| Methods of organising human activity | Scheduling, workflow, matching people, managing relationships |
| Mental processes | Observing, evaluating, judging, forming an opinion |
| Mathematical concepts | Formulas, calculations, relationships |
Most service innovations sit squarely in the second row. Matching supply with demand, routing requests to staff, sequencing tasks — all are ways of organising human activity.
Being new does not help at step one. Novelty is a §102 question; eligibility is a §101 question, and a genuinely novel way of organising human activity is still an abstract idea.
The characteristic failure
| Claim | Outcome |
|---|---|
| "A method of allocating advertising budget, comprising receiving campaign data, calculating an optimal allocation, and displaying the result" | Fails |
| Why | Fundamental economic practice, plus generic computing, reciting a result |
| Element | Analysis |
|---|---|
| Receiving data | Conventional |
| Calculating using a formula | Mathematical concept |
| Displaying on a device | Generic computing |
| Overall | Directed to an abstract idea, nothing significantly more |
Every step is something a computer does conventionally. Collecting, analysing and displaying information, without more, is the pattern courts have repeatedly held ineligible.
What survives
| Feature | Why it helps |
|---|---|
| A specific technical improvement | Improves how the machine operates |
| Solving a problem rooted in technology | Not a business problem dressed in code |
| A particular data structure or arrangement | Concrete, non-conventional |
| A specific processing technique with parameters | Recites how |
| Improved memory, bandwidth, latency, throughput | Measurable technical effect |
| Transforming a particular article | Traditional eligibility signal |
The test to apply to your own claim: if you deleted the business context, would anything technical remain?
A claim that only makes sense as a business improvement is directed to a business improvement. A claim that describes something a machine does differently, and why that is better technically, has somewhere to stand.
Reframing: finding the technical problem
Most service innovations contain a technical problem inside the business problem.
| Ask | Looking for |
|---|---|
| What does the system do that conventional systems cannot? | The technical delta |
| Why does the conventional approach fail technically? | Latency, memory, accuracy, scale |
| What specific mechanism solves that? | The claimable subject matter |
| What parameters, thresholds or structures are involved? | Specificity |
| Would a technical person recognise this as a technical fix? | The sanity check |
If none of those questions has an answer, the innovation is probably a business one and patent protection is unlikely.
If they do have answers, claim those answers rather than the service they enable.
Worked example: three framings
A company has built a scheduling service that reduces missed appointments.
Framing A — the service
A method of reducing missed appointments, comprising collecting appointment data, predicting non-attendance, and sending reminders accordingly.
| Step | Analysis |
|---|---|
| §101 step one | Method of organising human activity |
| §101 step two | Collecting, predicting, sending — all conventional |
| Outcome | Fails |
Framing B — the same thing, with a computer
...wherein the predicting is performed by a server executing a machine learning model, and the reminders are sent to a mobile device.
| Step | Analysis |
|---|---|
| §101 step one | Still a method of organising human activity |
| §101 step two | Generic computing — server, model, mobile device |
| Outcome | Still fails |
Framing C — the technical mechanism
A method of reducing prediction latency in an appointment scheduling system, comprising partitioning historical attendance records into fixed-size temporal buckets according to a cardinality threshold; maintaining a bounded accumulator per bucket such that memory consumption is independent of record count; and merging bucket results using a specified reconciliation step.
| Step | Analysis |
|---|---|
| §101 step one | Arguably a specific improvement in system operation |
| §101 step two | If reached: partitioning and bounded accumulator are a specific non-conventional arrangement |
| Outcome | Materially better prospects |
The underlying invention is identical in all three. What changed is what the claim is directed to.
Framing C is also narrower, which is the honest trade. It covers the mechanism rather than the business outcome, so a competitor achieving the same outcome differently is outside it.
Eligibility frequently turns on what the claim is directed to rather than what was invented. That is an uncomfortable feature of the current framework and a real one.
What the examiner sees first
| Signal | Read as |
|---|---|
| Background describes a market problem | Business method |
| Background describes a technical problem | Possible technical solution |
| Claims recite "determining" and "displaying" | Abstract |
| Claims recite structures and parameters | Specific |
| Specification measures improvements | Technical effect |
Framing is read before the claims are analysed, and it is cheap to get right at drafting and expensive to fix afterwards.
Europe reaches a similar place differently
| United States | European Patent Office | |
|---|---|---|
| Test | Alice two-step | Technical character |
| Business methods | Abstract idea | Excluded "as such" |
| Computer implementation | Does not save it | Non-technical features ignored for inventive step |
| What survives | Specific technical improvement | Further technical effect |
The routes differ and the outcomes largely converge. A claim that is a business method with a computer fails in both; a claim producing a genuine technical effect can succeed in both.
Which means one drafting approach serves both jurisdictions, and that approach is to claim the technical mechanism.
Continuations help here
| Use | Why |
|---|---|
| Different framing of the same disclosure | A second attempt at eligibility |
| Claims aimed at what competitors built | Written with hindsight |
| Narrower fallback | If the parent is rejected |
Eligibility outcomes vary, so keeping a continuation pending preserves a second route from the same specification — provided the technical detail was written in on day one.
Testing your own claim
Four questions to apply before drafting anything.
| Ask | Bad sign |
|---|---|
| Does the claim recite a result or a mechanism? | A result |
| Delete the business context — does anything technical remain? | Nothing does |
| Could a person do this on paper, given time? | Yes — mental process |
| Is the computer doing something differently, or just faster? | Just faster |
"Just faster" is the failure that catches people. Automating a task a human could do, at speed, is the paradigm abstract idea.
Something differently is what survives — a data structure, a processing technique, an arrangement that changes how the machine works rather than how quickly it does something conventional.
What to do if it is not patentable
| Route | Protects |
|---|---|
| Trade secret | An undetectable process, indefinitely |
| Trademark | The brand, indefinitely with renewal |
| Copyright | The specific code and content |
| Contracts | Customer and supplier relationships |
| Execution and network effects | The commercial position |
| Defensive publication | Stops others patenting it, cheaply |
Trade secret is the strongest alternative for service innovations, because a process running inside your own systems is frequently undetectable from outside.
Filing forecloses it permanently. Publication at eighteen months destroys secrecy whether or not a patent grants, which is the one IP decision that cannot be revisited. See can you patent something and make it free.
Drafting for eligibility
| Practice | Effect |
|---|---|
| Open with the technical problem | Frames the whole application |
| Describe why conventional approaches fail technically | Supports step two |
| Recite specific parameters and structures | Specificity survives |
| Include measured improvements | Memory, latency, throughput |
| Avoid result-based claim language | "So that revenue increases" is fatal |
| Avoid purely functional claiming | Invites §112 as well as §101 |
The specification does much of the work. A claim standing alone rarely demonstrates a technical improvement; the description explaining what was wrong before is what makes the improvement legible.
Write the technical problem first, in the background section. An application opening with a market opportunity signals a business method before the examiner reaches the claims.
The cost of getting it wrong
| Path | Cost |
|---|---|
| Assess eligibility first, reframe or stop | Hours |
| File, draw a §101 rejection, reframe | $12,000+ and 2 years |
| File, argue through several rounds, abandon | The full spend |
| Grant on narrow claims nobody would infringe | Full spend plus fees |
Software and business method applications draw the highest rejection rates and the most rounds, which is why assessing §101 before drafting is proportionate rather than cautious.
Most granted patents are abandoned before term anyway — only 41.4% of US utility patents reach it — and a narrow service patent nobody practises is a clear candidate. See the patent survival curve.
Service innovation patents: the checklist
- Accept that the service itself is not patentable. Look for the mechanism inside it.
- Assess §101 before drafting, not after the first rejection.
- Identify the technical problem, not the business problem.
- Ask what a machine does differently and why the conventional approach fails technically.
- Claim the mechanism, not the outcome. Recite how, never what is achieved.
- Do not rely on computer implementation. Generic hardware adds nothing at step two.
- Include specific parameters, structures and thresholds. Specificity is what survives.
- Test by deleting the business context. If nothing technical remains, stop.
- Consider trade secret seriously for undetectable processes, and remember filing forecloses it.
- Price the eligibility risk before committing. This is the field where applications most often consume budget without producing useful claims.