The hardest part of an app or platform patent is moving the invention into claim language. Mobile apps and SaaS platforms are mostly algorithms and data flows — they're inherently functional ("performs an action") rather than structural ("comprises element A and element B"). KIPO and the USPTO both allow functional claims, but their rules for definiteness differ enough that the same invention can clear one office and stall in the other if drafted with only one in mind.
Why app claims are hard
Mechanical inventions translate cleanly into structural claims ("a device comprising A coupled to B"). Apps are "code that does X." That makes the natural form of an app claim functional ("a system performing the steps of …"), and KIPO's computer-related invention guidelines require that information processing be concretely realized using hardware to qualify as an invention. Pure functional language fails — function plus the structure that performs it is what passes.
Functional vs. structural — two styles
Functional claims describe outcomes ("configured to do X," "performing Y"). Scope is broader but a thin spec invites definiteness rejections. Structural claims name concrete components ("a first module, a second module, a communication unit, a storage unit"). Scope narrows but stability rises.
| Aspect | Functional | Structural |
|---|---|---|
| Form | "a system configured to perform X" | "a system comprising module 1, module 2" |
| Scope | Broader | Narrower |
| Definiteness risk | Higher ("mere function") | Lower |
| Inventive step | Needs detailed algorithms in spec | Component differences are easier to argue |
| US §112(f) treatment | Often means-plus-function | Standard structural claim |
| KIPO definiteness | Skilled artisan must be able to envision a concrete artifact | Judged by named components |
KIPO — definiteness for functional claims
Per the KIPO computer-related invention guidelines, definiteness for functional claims turns on whether "a person skilled in the art, with the technical common sense at filing, can envision a concrete artifact having the recited function from the matter described in the claim." In other words, even if the claim ends in "performs X," the spec must describe how the system performs X — algorithms and data structures — so the artisan can build it.
US §112(f) — means-plus-function
35 U.S.C. §112(f) explicitly governs functional claims in the US. "Means for …" or equivalent nonce words ("~ module", "~ unit") are interpreted as means-plus-function: the spec must describe the structure that performs the function. For software inventions, that "structure" isn't generic computer hardware — it's the algorithm itself.
If a US claim says "a module configured to detect anomalies," the spec must lay out the algorithm: "the anomaly-detection algorithm comprises the steps of (1) … (2) … (3) …." Missing or vague algorithms invite §112(b) indefiniteness invalidation.
Four claim shapes for app patents
- System claim: "A system comprising at least one processor and memory, the processor configured to perform …"
- Method claim with HW actor: "A method, performed by at least one processor, comprising: (1) receive …, (2) process …, (3) output …"
- Program / medium claim: "A non-transitory computer-readable medium storing a program that causes a computer to perform …"
- UI / interaction claim: "A user interface configured to display screen X in response to a first input, and to process data Y in response to a second input"
Five spec-drafting tips to dodge rejections
- Walk the algorithm step-by-step in the spec: "Step 1: …, Step 2: …" — satisfies both KIPO definiteness and US §112(f)
- Specify input and output data structures: "a JSON object containing fields A, B, C" — narrows scope cleanly
- Quantify technical effects: "response time reduced by 50ms," "memory savings of 30%" — supports inventive step (Korea) and §101 practical application (US)
- Provide multiple embodiments: cloud, on-device, hybrid — broader coverage and harder to design around
- Separate domain claims: split medical, financial, etc. into distinct independent claims so a domain-specific rejection doesn't kill the rest
Frequently asked questions
Does broad functional claiming mean higher invalidation risk?
Yes. Broader scope shrinks the gap to prior art, which makes invalidation easier. The standard answer is a claim pyramid: a functional independent claim plus structural dependent claims. Even if the independent claim falls, narrower dependents survive — layered defense.
Are "module"-style terms safe in Korea?
KIPO has no nonce-word rule like US §112(f), so "a module" alone won't trigger an indefiniteness rejection — but the spec still has to describe what the module does and how. If you also target the US, prefer concrete components like "processor, memory, ~ unit" so a single spec works for both jurisdictions.
Is the UI itself patentable?
The visual appearance of a UI is protected by design registration (screen design), not patent. The interaction logic — "detect gesture X and trigger screen change Y" — is patentable as a claim. To cover both visual differentiation and interaction logic, file a design + a patent in parallel.
File app / platform patents with iphere
Specifications and claims drafted to clear both KIPO definiteness and US §112(f) — claim pyramids, algorithm walk-throughs, multi-embodiment coverage.