The Two Offices Are Not Asking the Same Threshold Question
For software, algorithm, and AI inventions, the first mistake is to assume that a positive result in one jurisdiction predicts a positive result in another. China and the United States both require a patentable technical contribution, but they reach that issue through different legal structures.
China's current Patent Examination Guidelines, as amended effective January 1, 2026, require the examiner to analyze the claimed solution as a whole rather than mechanically separating technical features from algorithmic or business-rule features. For inventions involving AI, big data, algorithms, or business rules, the examination asks how the claimed features work together, what technical problem is solved, what technical means are used, and what technical effect is obtained.
The U.S. system starts from a different architecture. A claim must fall within a statutory category under 35 U.S.C. §101 and then survive the judicial-exception framework reflected in current USPTO guidance. For a software claim, an examiner may ask whether the claim is directed to an abstract idea and, if so, whether the claim integrates that idea into a practical application or otherwise contains significantly more. Novelty and non-obviousness do not answer that eligibility question by themselves.
A Chinese “technical solution” conclusion and a U.S. §101 conclusion are not interchangeable legal findings. A U.S. filing should be reviewed under the U.S. framework using the disclosure that actually exists in the Chinese/PCT priority record.
China's 2026 Rules Make the Technical Interaction More Explicit
The 2026 CNIPA amendments are particularly relevant to cross-border drafting because they make the treatment of AI and algorithmic features more concrete. The Guidelines state that features should be considered as an integrated whole. In inventive-step analysis, algorithmic or business-rule features that functionally support or interact with technical features can contribute to the assessment rather than being discarded merely because they are non-technical in isolation.
The same amendments also sharpen disclosure expectations for AI-related applications. If the invention concerns building or training an AI model, the specification generally needs to describe the necessary model modules, layers or connections, and the concrete training steps and parameters needed to implement the solution. If the invention applies a model or algorithm in a specific field, the specification generally needs to explain how it is combined with that field or scenario and how inputs and outputs are configured so the technical relationship can be implemented.
That is useful preparation for a U.S. filing, but it does not eliminate the need for adaptation. A description can be sufficient for one jurisdiction's technical-solution inquiry and still leave the U.S. claim too abstract, too result-oriented, or too disconnected from the disclosed implementation.
In the United States, the Claimed Improvement Must Be Visible in the Claim
U.S. eligibility practice places heavy pressure on how the claim expresses the asserted technological improvement. It is often not enough for the specification to say that the invention improves efficiency, accuracy, security, resource use, or user experience. The claim should identify the technological mechanism that produces the improvement with enough specificity that the improvement is part of the claimed solution rather than a marketing conclusion.
This is where a literal translation can fail even when every English sentence is accurate. A Chinese claim may state a sequence such as “obtaining data, processing the data according to a model, and outputting a result.” If the U.S. record does not explain what changes in the computer, network, sensor system, storage architecture, industrial process, or other technical environment—and if the claim does not capture that relationship—the examiner may see only generic information processing.
The adaptation exercise therefore asks: What is the technical bottleneck? Which claimed operation changes the way the system functions? What technical data is being processed and why? Is the improvement tied to a particular architecture, signal path, control loop, memory operation, model implementation, or industrial process? Most importantly, is that explanation already supported by the priority disclosure?
§112 Can Become the Second U.S. Problem
Even if §101 is manageable, software claims can encounter written-description, enablement, or definiteness problems under §112. Broad functional language is particularly vulnerable when the specification provides only a desired result and little implementation detail. The risk is not that functional claiming is automatically improper. The risk is that later prosecution may require a narrower technical relationship that the original filing never actually described.
For China-originated applications, this can appear in several ways: a model is named but its role in the system is not explained; a “module” performs a result without an underlying process; a parameter is claimed broadly although only one value is disclosed; or the specification describes a business objective more clearly than the technical mechanism used to achieve it.
Once the U.S. case has been filed, new matter cannot simply be inserted into the original disclosure. That is why the highest-value adaptation work happens before the U.S. filing date, while the team can still distinguish supported clarification from genuinely new technical content and make an informed priority decision.
Claim Architecture Also Needs to Travel Across the Border
Different systems produce different drafting habits. A Chinese claim set may put significant detail into the independent claim because that structure fits the expected examination path. A U.S. strategy may benefit from a different ladder of claim scope, with meaningful dependent-claim fallbacks and terminology that supports continuation practice. The goal is not to make a claim “American” stylistically. It is to make the claim set usable under U.S. examination without inventing new disclosure.
The same point applies to terminology. Software translations often rotate among “module,” “unit,” “component,” “device,” “platform,” and “system.” A linguistically fluent translation can make that variation sound elegant; a patent record may make it look like six different structures. For a U.S. filing, one concept should generally have one stable principal term unless a technical distinction is intended.
A Better China-to-U.S. Software Workflow
- Identify the technical improvement before translating the claims, not after the first §101 rejection.
- Map that improvement to the Chinese/PCT disclosure and figures so the U.S. position rests on existing support.
- Review the claim under the current U.S. §101 framework separately from novelty and obviousness.
- Check whether the specification provides implementation detail sufficient for likely §112 pressure points.
- Rebuild the claim hierarchy where necessary instead of preserving Chinese claim structure mechanically.
- Normalize terminology and antecedent relationships across claims, description, and drawings.
- Separate supported clarification from genuinely new technical matter and analyze priority consequences before adding it.
Takeaway
The practical lesson is not that software patents “work in China but fail in America.” Both systems can protect software-related inventions, and both can reject them. The lesson is that a favorable Chinese drafting or examination posture is not a substitute for a U.S.-specific legal and technical review.
For a China-originated software or AI application, translation answers only one question: did the English preserve the Chinese text? Adaptation answers the harder question: does the existing technical record support a useful U.S. claim strategy under §101, §112, and the prosecution choices that may follow? That is why the most important U.S. work often begins before the translation is finalized.