Software Patent Drafting Strategy: The Four-Part Claim Suite, Alice Test, and AI-Assisted Generation
CNIPA.AI Team
Tech Blog
Software method patents (IPC class G06) are China's single largest category of invention patent applications, accounting for over 32% of filings. Yet software patent drafting presents unique challenges: how do you "translate" an algorithm or process into a technical solution meeting patent law requirements? How do you describe algorithmic details in the specification without falling into the "mental steps" examination trap? This article draws on Chapter 9 of Part II of the CNIPA Patent Examination Guidelines, the Alice/Mayo test framework, and real examination practice to provide directly applicable drafting strategies.
Patent Eligibility: The Threshold Rule for Avoiding Abstract Idea Exclusions
Before discussing the four-part claim suite structure, the most critical threshold for software patents must be understood: subject matter eligibility.
Chapter 9 of Part II of the CNIPA Patent Examination Guidelines provides that computer program-related inventions may be claimed as a method or as a product, but not as purely mental steps rules and methods, mathematical concepts, or mathematical rules.
The core requirement for avoiding eligibility risk: Claims must be evaluated as a whole. Algorithmic features (abstract information-processing logic) and technical features (specific computer processing steps, data formats, system components) must have a functional interrelationship. The algorithmic features and technical features cannot simply be split apart, with an examiner treating the technical features portion as prior art and denying patentability.
Practical eligibility test: The following claim types generally pass the eligibility examination:
- "A method for processing a specific type of physical data (image/signal/sensor data)" — the processing object is technical
- "A method for controlling a specific physical device (robot/sensor/industrial control system)" — the controlled object is technical
- "A method for solving a technical problem through specific technical means (neural network inference/specific encryption algorithm/specific data structure operations)" — the technical means are specific
The following claim types typically present eligibility risk:
- Pure business rules or mathematical algorithms with "executed on a computer" appended at the end of a step
- Pure descriptions of information content or data meaning, without any processing of signals or data
- Pure human-computer interaction design without specific information processing technology
The 2025 revision to the CNIPA Examination Guidelines added specification recording requirements for inventions involving AI model construction/training: the model's modules, layers, connections, training steps, and parameters must be recorded. This is an important new rule for AI/machine learning software patents.
The Complete Four-Part Claim Suite: Drafting Points for Each Component
First component: Method claims (primary scope of protection)
Method claims are the core of the four-part suite, generally providing the broadest protection scope and serving as the primary source of patent protection. Standard format:
A method for XXX, characterized in that it comprises the following steps:
S1: Acquiring/receiving XXX data;
S2: Processing the XXX data using YYY algorithm/model to obtain ZZZ;
wherein the YYY algorithm specifically comprises: ...[specific technical steps];
S3: Based on ZZZ, performing/outputting/generating WWW.
Drafting points: Use step numbering (S1/S2/S3); each step must clearly specify the input, processing logic, and output; key algorithm steps must be refined to the level of specific technical means rather than remaining at the functional description level; avoid vague adverbs such as "intelligently" or "automatically."
Second component: Apparatus claims (functional module mapping)
Apparatus claims mechanically map method steps to functional modules, with each module corresponding to one method step:
An apparatus for XXX, characterized in that it comprises:
an acquisition module, configured to acquire/receive XXX data;
a processing module, configured to process the XXX data using YYY algorithm to obtain ZZZ;
an execution module, configured to perform/output/generate WWW based on ZZZ.
Drafting points: Module names correspond to method steps (acquire → acquisition module; process → processing module); each module uses "configured to..." to describe its function; data flow between modules is implied in the functional descriptions ("XXX data acquired by the acquisition module").
Third component: Device claims (hardware architecture description)
Device claims protect the computer hardware architecture on which the software runs:
A computer device, characterized in that it comprises:
a memory, wherein the memory stores a computer program;
a processor, connected to the memory,
wherein when the processor executes the computer program, it implements:
S1: Acquiring/receiving XXX data;
S2: ...(repeat method steps)
Fourth component: Computer-readable storage medium claims (CRM claims)
Storage medium claims, called "computer-readable storage medium" (CRM) claims in China (and CRM claims in the US), are standard in Chinese software patents:
A computer-readable storage medium, characterized in that
a computer program is stored on the computer-readable storage medium,
and when the computer program is executed by a processor, it implements:
S1: ...(repeat method steps)
Storage medium claims incorporate the method steps by reference, avoiding repetitive drafting while independently protecting the physical medium storing the program.
Dependent Claim Expansion Strategy
Independent claims should cover the broadest protection scope; dependent claims progressively narrow this scope using "wherein," "specifically," or "further" limiting language, while also providing support for the independent claims (avoiding "claims lack specification support" rejections).
Typical expansion directions for software patent dependent claims:
| Expansion Direction | Example Phrasing | Purpose |
|---|---|---|
| Refine key algorithm steps | "wherein the YYY algorithm in step S2 specifically comprises..." | Implement specific technical means |
| Specify input data format | "wherein the XXX data is [specific format/type]" | Narrow claim scope; increase stability |
| Specify model parameters | "wherein the neural network model is [specific architecture]" | Protect specific embodiments |
| Add application scenarios | "wherein the method is applied to [specific scenario]" | Expand protection coverage |
| Add preferred embodiments | "wherein step S2 further comprises..." | Support specification embodiments |
Standard dependent claim count: Chinese software patents recommend 2–3 independent claims (covering method, apparatus, storage medium) plus 7–8 dependent claims, totaling 9–11 — staying within the most common 10-claim threshold for surcharges.
US Software Patents and the Alice Test: Comparison with the Chinese Approach
US software patents face eligibility challenges under 35 USC 101 combined with the Alice/Mayo two-step test. Understanding the Alice test is critical for US-China parallel prosecution of the same invention.
The Alice two-step test:
Step 1 (Alice Step 1): Do the claims direct to an "abstract concept" (including mathematical concepts, certain methods of organizing human activity, or mental processes)?
Step 2 (Alice Step 2A/B): If so, is there an "inventive concept" that transforms the claimed solution into something significantly more than the abstract concept itself? The 2019 USPTO revised guidelines further refined this into: Step 2A Prong 1 (whether the claim integrates the abstract concept into a practical application) and Step 2A Prong 2 (whether the claim provides substantive content beyond the abstract concept).
Drafting strategies to pass the Alice test:
| Strategy | Chinese (CNIPA) approach | US (USPTO) approach |
|---|---|---|
| Emphasize specific technical effects | "improves processing efficiency of XXX" | "improves the technical functioning of a computer" |
| Specify particular computer implementation | Describe specific processor/memory interactions | "a specific machine or manufacture" |
| Avoid broad functional claiming language | Avoid "apparatus for implementing arbitrary XXX" | Avoid "means for performing" |
| Reference specific data transformation | Describe specific data format conversions | "transformation of data" |
Core difference between China and the US: China's Article 25 "mental steps" exclusion standard and the Alice test's "abstract concept" exclusion standard are logically similar but operationally different. China focuses more on the "functional interrelationship" between algorithmic and technical features; the US focuses more on whether the claims as a whole provide an "inventive concept" beyond the abstract concept. For the same invention, Chinese and US independent claims typically need targeted adjustments — direct copying will not work optimally.
US software patents also have the CRM (Computer Readable Medium) claim form, which is US-specific. US CRM claims are logically equivalent to Chinese computer-readable storage medium claims, but specific drafting conventions differ.
Patent Drawing Strategy for Software Patents: Flowcharts and Mermaid
Patent drawings for software patents center on flowcharts. CNIPA format requirements for drawings: black-and-white line drawings; clear reference numerals (consistent with the specification); no textual explanations within drawings (only reference numerals and necessary technical terms).
Standard software patent drawing checklist (using a 10-claim patent as an example):
| Drawing Type | Content | Corresponding Claim | Required? |
|---|---|---|---|
| Method flowchart | Execution sequence of main method steps | Method independent claims | Mandatory |
| System architecture diagram | Overall system structure | Overall technical solution | Mandatory |
| Apparatus block diagram | Components of functional modules | Apparatus independent claims | Mandatory |
| Sub-process flowchart | Detailed flow for key steps | Dependent claims | Recommended |
| Data flow diagram | Data flow through the system | Data processing sub-steps | Recommended |
| Sequence diagram | Module interaction sequence | Multi-component interaction scenarios | Recommended (multi-component systems) |
| Model structure diagram | Neural network / AI model architecture | AI-related dependent claims | Mandatory (AI-type) |
Mermaid is an ideal tool for generating software patent drawings. Mermaid supports flowcharts, sequence diagrams, state diagrams, class diagrams, and other graph types — generating structured diagrams from text descriptions, suitable for use in AI-assisted generation workflows.
AI image generation (e.g., Stable Diffusion) is suitable for UI interface mockups, not structured flowcharts — structural accuracy (step sequence, conditional branches) matters more than visual appearance, making Mermaid the better choice.
AI-Assisted Software Patent Drafting: The Complete Workflow
CNIPA.AI's AI drafting capability is specifically optimized for the characteristics of software method patents, drawing on Chapter 9 of Part II of the CNIPA Examination Guidelines and real examination practice data:
Step 1: Technical element extraction — AI identifies core algorithm steps, input/output data types, key technical features, and potential eligibility risk points in the technical disclosure. For inventions involving AI/machine learning, AI specifically extracts model type, training data, and model architecture — information required by the 2025 updated examination guidelines.
Step 2: Subject matter eligibility pre-check — Before generating claims, AI checks whether the technical solution presents eligibility risk and recommends which technical features to add to establish a functional interrelationship between algorithmic and technical effects.
Step 3: Automated four-part claim suite generation — Automatically generates the four-component claim suite in Method → Apparatus → Device → Storage Medium order, ensuring technical features map one-to-one across components, and automatically expanding 3–5 dependent claims.
Step 4: Drawing planning and generation — Based on steps, modules, and data flows identified in the claims, plans the drawing list (mandatory types + recommended types), generates structured flowcharts using Mermaid for process diagrams, and uses AI image generation for UI-type drawings.
Step 5: Full specification generation — Covers all five major sections: Technical Field, Background Art (efficiency/accuracy insufficiency argument logic), Summary of the Invention (technical problem–solution–effects three-part structure), Brief Description of Drawings, and Detailed Description of Embodiments (with multiple embodiments).
| Task | Traditional Manual (hours) | AI-Assisted (minutes) | Savings |
|---|---|---|---|
| Technical element extraction and analysis | 1–2 hours | 5–10 minutes | ~90% |
| Four-part claim suite drafting | 2–4 hours | 10–15 minutes | ~92% |
| Dependent claim expansion | 1–2 hours | 5–10 minutes | ~90% |
| Drawing planning and preparation | 2–3 hours | 15–30 minutes | ~85% |
| Full specification drafting | 3–5 hours | 15–30 minutes | ~88% |
| Total | 9–16 hours | 50–95 minutes | ~88% |
AI-generated first drafts can serve directly as internal review versions (corporate applicants) or as attorney refinement drafts (patent agencies). The attorney's focus shifts from drafting to review: checking whether technical elements are accurately extracted, whether eligibility risks are identified, and whether claims scope aligns with corporate strategy.
Common Rejections in Software Patents and Response Strategies
The four most common rejection types in Chinese software patent examination and response strategies:
Eligibility rejection (PRC Patent Law Article 25(1)(ii)): Found to constitute mental steps rules and methods. Response: Amend the claims to add specific technical features (types of physical input signals, specific algorithm modules used, technical effects of the output); emphasize the functional interrelationship between algorithmic and technical features; through examination responses, explain the technical problem solved and the technical effect achieved.
Insufficient inventive step (PRC Patent Law Article 22(3)): Algorithm improvement found to be a conventional technical means in the field. Response: Provide performance comparison data in the specification (processing speed, accuracy, resource consumption) proving non-obvious technical effects; in examination responses, point out that the cited reference addresses a different technical problem or fails to disclose key technical features.
Insufficient specification disclosure (PRC Patent Law Article 26(3)): Algorithm description is too abstract; lacks specific implementation details. Response: Supplement the specification with pseudocode and detailed algorithm steps; for AI/machine learning, supplement with model layer structure, training data type, and parameters; these issues cannot be cured through examination responses after filing and must be avoided at the drafting stage.
Claims lack specification support (PRC Patent Law Article 26(4)): The functional generalization scope of the claims exceeds what the specification discloses. Response: At the drafting stage, prepare specific embodiments in the specification corresponding to each dependent claim; the generalization level of independent claims must be premised on sufficient supporting embodiments in the specification.
Mastering response strategies for these four rejection types, combined with AI-assisted first-draft generation, is the standard workflow for modern software patent practice.
Get Started with CNIPA.AI
Sign up now and experience AI-powered patent search and writing
Sign Up Free