An EPO software patent application should do more than place a business or mathematical concept on a computer. It should identify the technical problem, disclose the architecture and processing relationships that produce the technical effect, and build claim and disclosure fallbacks that remain useful under the EPO’s two-hurdle and COMVIK analysis.
European software practice is best understood as a connected drafting problem. A computer-implemented invention may clear the first patentability hurdle because the claim uses technical means, but inventive step still turns on the features that contribute to technical character. The draft therefore needs enough technical detail to show what the software does to a computer, network, device, data-processing pipeline or other technical system, and enough fallback disclosure to support later amendments without adding subject matter.
A claim involving a computer or other technical means is generally not excluded as a computer program “as such,” but that does not mean the software contribution will support inventive step. The specification should identify the technical effect and the features that produce it.
Broad result-oriented language can become fragile if the description does not explain the technical architecture, processing sequence, data relationship or implementation that creates the asserted effect. Draft the broad concept together with narrower technical fallbacks.
The EPO applies a two-hurdle approach to computer-implemented inventions. At the first hurdle, a claim using technical means such as a computer is normally an “invention” within Article 52(1), even if it also contains non-technical features. At the second hurdle, inventive step is assessed by asking which features contribute to technical character. Under the COMVIK approach, non-technical features can be part of the claim, but they support inventive step only to the extent that they contribute to a technical effect serving a technical purpose.
Drafting should therefore make the technical contribution visible in the application itself. The stronger question is not merely “is this software?” but “what technical problem is solved, by what technical features, and with what technical effect?”
Programs for computers are excluded under Article 52(2)(c) and (3) only when claimed as such. A program can have technical character when, running on a computer, it produces a further technical effect beyond the ordinary physical interactions between software and hardware. Typical examples include controlling a technical process, improving the internal functioning of a computer, or changing the operation of interfaces or technical resources.
For drafting, this means that phrases such as “implemented by software” or “executed by a processor” are not enough by themselves. The specification should explain the relevant computer behavior, resource interaction, device control, data structure, communications effect, security improvement, latency reduction, memory management, or other technical consequence that the software actually produces.
| Weak drafting direction | Stronger EPO drafting direction |
|---|---|
| Use software to automate a task | Explain the technical process, computer operation or device interaction changed by the software. |
| Improve efficiency with an algorithm | Identify the computing constraint and measurable technical effect such as latency, bandwidth, processor load or memory use. |
| Organize information more effectively | Show whether the data structure or format has a technical function in a technical system. |
| Apply business rules using a server | Separate the non-technical business requirement from any technical implementation that actually solves a technical problem. |
The COMVIK approach can be used before filing as a stress test. Ask which claimed features would still matter if the business, administrative or mathematical requirement were handed to the skilled person as part of the problem. The application should then explain why the remaining implementation choices solve a technical problem in a non-obvious way.
This is especially important for SaaS, fintech, marketplaces, recommendation systems, enterprise workflows and other inventions where commercially important logic may be non-technical. The draft should not manufacture a technical effect. It should identify any real technical implementation contribution and document it with enough specificity to support the intended claim scope.
The EPO Guidelines state that claims directed to computer-implemented inventions should define all features essential for the technical effect of the process carried out by the program. The specification should therefore make clear which architecture, data flow, device interaction, processing sequence or control relationship is essential and which features are merely optional.
A useful claim family may include a computer-implemented method, a system or apparatus, and, where appropriate, program or storage-medium formulations consistent with EPO practice. Claim categories should reflect the actual invention rather than being generated mechanically.
European applications for cloud and distributed inventions should explain the technical topology in enough detail to understand where processing, storage, communication, authentication and control occur. If some method steps are performed by different devices, servers or clients, the claims and description should make those relationships coherent.
The EPO Guidelines expressly distinguish computer-implemented inventions carried out by generic data-processing means, inventions using specific data-processing or technical devices, and inventions implemented in distributed computing environments. A good specification should support the claim form that actually matches the deployment architecture.
Map the claimed features to the technical problem, technical effect, architecture and fallback disclosure before filing or before entering the European phase.
The application must disclose the invention clearly and completely enough for the skilled person to carry it out. Source code is not automatically required. What matters is whether the technical teaching provides enough information to implement the claimed invention without undue burden across the intended scope.
For technically complex software, useful disclosure can include architecture diagrams, sequence diagrams, processing stages, data structures, protocol interactions, state transitions, pseudocode or narrative algorithms. The amount of detail should match the complexity and breadth of the claimed technical contribution.
Claims must be clear, concise and supported by the description. A broad software claim should therefore have a defensible basis in the disclosed technical teaching. Terms such as “engine,” “module,” “platform,” “optimizer” or “controller” should not hide uncertainty about the actual functionality when that functionality is central to the invention.
Build dependent claims around technically meaningful fallback positions: data-processing steps, resource relationships, protocol details, system topology, device constraints, error handling, security mechanisms, timing relationships and measurable technical effects.
Later EPO amendments cannot add subject matter extending beyond the application as filed. Software specifications should therefore disclose combinations and alternatives deliberately. A feature buried only in one narrow embodiment may be difficult to extract later if the application does not clearly support its use in a broader combination.
A practical drafting structure is: broad technical concept → alternative architectures → optional features → narrower implementation combinations → specific examples. The point is not to create artificial boilerplate, but to make the disclosed technical relationships and fallback positions explicit before the filing date.
The EPO recognizes that a data structure or format can contribute to technical character where it has an intended technical use and produces a technical effect when used for that purpose. This can matter for storage formats, control data, packet structures, metadata, indexes and other software inventions where the way information is structured changes operation of the technical system.
The draft should therefore distinguish information whose meaning is only cognitive or administrative from functional data that actually controls or changes a technical process or device.
Computer-implemented simulation, design and modelling inventions are examined using the same general CII principles. The mere fact that the simulated system is technical does not automatically establish a technical effect. The specification should identify how the claimed simulation or model contributes to a technical solution, for example through a technical use, implementation or downstream technical process.
| Drafting risk | Why it matters | Better first-filing response |
|---|---|---|
| Generic computer implementation | May clear the first hurdle but add little to inventive step | Describe the specific technical effect and implementing features |
| Business requirement dominates the claim | Non-technical features may be given to the skilled person as constraints | Identify the non-obvious technical implementation |
| Essential effect not reflected in claims | Can trigger clarity/support issues and weaken inventive-step analysis | Claim the features causally responsible for the technical effect |
| Thin architecture disclosure | Limits sufficiency and amendment options | Disclose processing relationships, alternatives and technical fallbacks |
| Feature isolated in one embodiment | Later extraction can create added-matter risk | State broader and narrower combinations expressly |
| Data merely has semantic meaning | May not contribute to technical character | Explain any technical function of the data structure or format |
The specification should distinguish the technical contribution from the prior art instead of describing every software feature as equally important. Explain why the architecture, processing relationship or control mechanism matters technically. If several implementations can achieve the effect, disclose them. If only a specific implementation works, avoid unsupported generalization.
This improves the basis for later problem-solution analysis and can make it easier to formulate narrower claims when prior art is identified during search or examination.
Many applicants reach the EPO through the PCT. The first filing should therefore be capable of supporting both international search and later European prosecution. A technically rich PCT specification can preserve fallback positions for the EPO while remaining usable for the US and other national phases.
Useful lifecycle links include PCT filing, international filing strategy, PCT Written Opinion response, and EPO search opinion and examination response.
The drafting stage should anticipate the issues likely to arise during European search and examination. If the EPO questions technical character or inventive step, a well-structured specification can provide evidence of the technical problem, effect and implementation. If prior art requires narrowing, explicit fallback positions and clear amendment basis can materially improve the available response options.
Review technical effect, COMVIK positioning, claim categories, sufficiency, Article 123(2) support and PCT/EPO sequencing before the drafting strategy is fixed.
Use this page together with the broader Software Patent Drafting hub, the EPO Patent Drafting guide, PCT filing, and EPO examination response to connect first-draft decisions with later international and European prosecution.
Return to the technology-level software drafting hub for broader international drafting strategy.
Review the broader European drafting framework, including support, sufficiency and amendment-basis planning.
US software drafting is strongest when the specification connects the architecture, data flow and processing sequence to a supported technological improvement and preserves narrower positions for later USPTO prosecution.
Discuss the software invention, architecture, claim categories, §101 positioning, §112 support and international filing objectives before filing.
