By michael li
One app can contain several graphical user interface (GUI) designs, not one continuous sequence. Before a China GUI design patent application is prepared, screenshots from A/B experiments, different user roles and changing account content should be separated and assessed rather than arranged into a story the proposed interface does not actually tell.
The problem is not the number of screenshots alone. It is whether the views consistently express the design intended for protection, including the relationship between interfaces and any claimed changes.
A developer may deliver a folder containing the customer checkout, an alternative checkout layout, a merchant dashboard and a confirmation screen. Each image may belong to the same app, but that commercial connection does not establish that all images are states of one design.
China’s design-patent framework generally limits an application to one design, subject to specified exceptions such as similar designs of the same product. The December 2025 GUI application guide further distinguishes successive interfaces with a clear relationship from parallel interfaces serving different functions.
IPcrossark’s China design patent application guide addresses general image and filing preparation. For GUIs, an additional question comes first: which screenshots belong together, and why?
The following example is hypothetical, not an IPcrossark client matter. Assume a shopping app’s development handover contains these six screenshots:
| Screenshot | Context supplied by the developer | Question for the filing review |
|---|---|---|
| A1: Basket screen | Customer account, experiment version A | What interface design is intended for protection? |
| A2: Payment-options screen | Reached from A1 by selecting checkout | Is it part of a coherent successive interface design? |
| A3: Confirmation screen | Reached after completing the proposed checkout route | How does it relate to the function and design shown in A1 and A2? |
| B1: Alternative basket | Experiment version B, shown to another test group | Is it an alternative design rather than the next state of version A? |
| M1: Merchant dashboard | A different account role with different permissions | Does it represent a separate function or another design needing assessment? |
| A4: Basket with different product photographs | Version A with different account content | Is the difference variable content or part of the interface design? |
Simply numbering these images 1–6 would not establish a continuous change process. In particular, the alternative basket and merchant dashboard should not be presented as later frames merely because their files were exported after the confirmation screen.
This does not mean that every alternative requires a separate application. The representative should assess the intended designs, interface relationships and any applicable similar-design filing route before the applicant decides how to proceed.
For a proposed sequence, a useful preparation record identifies the starting interface, the relevant user interaction and the resulting interface. The context should also identify the experiment version, user role and device presentation where those facts affect the appearance.
A walkthrough or internal screen recording can help explain the intended relationship. It is a recommended communication aid, not a universal filing attachment or proof that patent protection requires a publicly released, fully implemented app.
A coherent proposed design can be considered before implementation. The important point is to describe the intended design honestly and consistently, rather than infer a sequence from a mixture of unrelated captures.
The review should distinguish three different situations:
For a dynamic GUI, the examination guidance requires the views to determine the complete change process uniquely, with change-state views named in order. Selecting attractive screenshots without understanding that process can leave the filing inconsistent with the intended design.
The December 2025 guide illustrates a network-meeting GUI using modified Tencent Meeting screens. The three views show “Meeting,” “Contacts” and “My” interfaces.
The guide treats them as parallel interfaces serving different functions, with movement possible between the screens rather than a clear, unique direction of change. It says they cannot be treated as one design; whether they can be filed together as similar designs depends on the relevant requirements.
This is an official guide illustration, not a court judgment or a reported decision about an A/B experiment. Its relevance is that navigability within one app does not settle the application structure.
The hypothetical checkout folder raises a related preparation question. Before asking an illustrator to produce change-state views, the applicant should explain whether the images show one intended design, different functions, alternative experiments or merely different content.
A photograph, account balance or recommendation may change while the surrounding interface remains the same. Conversely, an experiment may alter the arrangement, controls or other visual features that matter to the proposed design.
The GUI guide distinguishes content displayed within an interface from the interface design itself. It also cautions that externally supplied or changing material is not automatically excluded content; its role in the design still needs assessment.
The recommended preparation approach is to preserve the original captures and identify the areas believed to be variable. The representative can then determine the appropriate presentation in filing views and reference views.
Blanking out every difference can remove a feature intended for protection. Leaving all example content untouched can also obscure what the application is meant to cover, so neither approach should be applied mechanically.
Where a partial design patent is sought for an interface region, IPcrossark’s explanation of Chinese partial-design boundaries and views provides related background. The GUI-specific review must still confirm the eligible subject matter, protected portion, product indication and description.
A CNIPA case analysis published on 29 May 2019 examined a series of invalidation matters concerning computers with GUIs, including decisions numbered 35196 and 35197. Among the issues was whether software available before filing had disclosed the interface design.
The analysis described forum download links and software that ordinary users could install through conventional steps, despite registration or installation codes. The evidence did not establish that trial users owed a confidentiality duty, and the panel did not accept the asserted internal-testing and unauthorised-disclosure grace-period argument.
The practical lesson is limited but important: a “test version” label or an access code does not, alone, establish confidentiality. Access conditions and the actual disclosure history need examination before the filing strategy relies on secrecy.
These were historical invalidation matters, not cases about assembling A/B screenshots. Their former whole-product presentation framework should not be copied into current partial-design advice, and this article does not infer final invalidation outcomes beyond the findings reported in the analysis.
The business should request enough context to distinguish design alternatives from sequence states. Useful handover information may include the relevant build or prototype, experiment label, account role, intended interaction and explanation of any content-only changes.
Ownership and confidentiality are separate questions from whether the views express one design. A well-organised screenshot folder does not itself establish the applicant’s rights or show that development and testing remained confidential.
For China-related development engagements, CNLITIX’s guide to contract and transaction risks offers related reading on deliverables, technical specifications, change orders, confidentiality and ownership of newly created work. That contract discussion complements, rather than replaces, the design-patent filing review.
The proposed handover record is an applicant-preparation suggestion, not a compulsory CNIPA form. Its purpose is to give the representative reliable instructions before application views are finalised.
Possibly, but the app name and screenshot count do not determine the answer. The interfaces’ functions, logical relationship and intended protection must be assessed under the applicable filing requirements.
No; the appropriate treatment depends on the actual designs and whether relevant grouping requirements are satisfied. The key warning is not to relabel alternative experiments as consecutive animation frames without a supporting design relationship.
There is no blanket rule based solely on the account labels. Different roles should trigger a review of the interfaces’ functions and relationship, not an automatic conclusion either way.
A publicly released or fully implemented app is not a general prerequisite described by these GUI view requirements. The applicant must nevertheless provide views and descriptions that clearly express the intended design.
Not automatically; access control and confidentiality obligations are different questions. The actual recipients, access arrangements, restrictions and evidence should be assessed rather than inferred from a login screen.
IPcrossark’s patent services include Chinese design patent filing, with related search and examination-response support. This article connects that service with a practical preparation issue: deciding what interface design the proposed application should express.
An initial enquiry can identify the product, the intended GUI feature and whether the supplied images include alternative versions or different account roles. Confidential prototypes, user information and technical material should be shared only through agreed arrangements.
Contact IPcrossark to discuss the proposed Chinese design application and required information. GUI-specific assessment, drawing work and particular deliverables should be confirmed in the engagement scope rather than assumed from this article.
This article is a preparation framework, not a determination that a particular GUI is eligible or patentable. Official materials were checked on 30 October 2026, and the fictional app example is separate from the official illustration and historical invalidation analysis.
Fields marked * are required. We usually reply within one business day.
We will reply by email within one business day. This window will close automatically.
