Prosecution Insights
Last updated: October 25, 2026
Application No. 18/748,965

GRAPHIC DESIGN CODE GENERATION PLUGIN SYSTEM

Non-Final OA §103
Filed
Jun 20, 2024
Priority
Jun 20, 2023 — provisional 63/522,049
Examiner
NOOR, TUBBA
Art Unit
4100
Tech Center
4100
Assignee
Figma Inc.
OA Round
1 (Non-Final)
Grant Probability
Favorable
1-2
OA Rounds

Examiner Intelligence

Grants only 0% of cases
0%
Career Allowance Rate
0 granted / 0 resolved
-60.0% vs TC avg
Minimal +0% lift
Without
With
+0.0%
Interview Lift
resolved cases with interview
Typical timeline
Avg Prosecution
4 currently pending
Career history
7
Total Applications
across all art units
This examiner has no resolved cases yet (career too new); statute-level performance unavailable. The Grant Probability card shows Tech Center averages instead.

Office Action

§103
Notice of Pre-AIA or AIA Status The present application, filed on or after March 16, 2013, is being examined under the first inventor to file provisions of the AIA . DETAILED ACTION This office action is in response to the application filed on 06/20/2024. Claims 1-20 are pending in this application. Claims 1, 13, and 20 are independent claims. Priority Applicant’s claim for the benefit of a prior-filed application under 35 U.S.C. 119(e) or under 35 U.S.C. 120, 121, 365(c), or 386(c) is acknowledged. The present application claims priority to U.S. Provisional Application No. 63/522,049 filed on June 20, 2023. The earlier filing date of June 20th, 2023 is granted. Drawings The drawings are objected to because Figures 1 and 2 are blurry and fail to clearly disclose the subject matter. Corrected drawing sheets in compliance with 37 CFR 1.121(d) are required in reply to the Office action to avoid abandonment of the application. Any amended replacement drawing sheet should include all of the figures appearing on the immediate prior version of the sheet, even if only one figure is being amended. The figure or figure number of an amended drawing should not be labeled as “amended.” If a drawing figure is to be canceled, the appropriate figure must be removed from the replacement sheet, and where necessary, the remaining figures must be renumbered and appropriate changes made to the brief description of the several views of the drawings for consistency. Additional replacement sheets may be necessary to show the renumbering of the remaining figures. Each drawing sheet submitted after the filing date of an application must be labeled in the top margin as either “Replacement Sheet” or “New Sheet” pursuant to 37 CFR 1.121(d). If the changes are not accepted by the examiner, the applicant will be notified and informed of any required corrective action in the next Office action. The objection to the drawings will not be held in abeyance. Claim Objections Claim 1 is objected to because of the following informality: Claim 1 recites “to render at last a portion”. Examiner suggests amending to “to render at least a portion”. Appropriate correction is required. Claim Rejections - 35 USC § 103 In the event the determination of the status of the application as subject to AIA 35 U.S.C. 102 and 103 (or as subject to pre-AIA 35 U.S.C. 102 and 103) is incorrect, any correction of the statutory basis (i.e., changing from AIA to pre-AIA ) for the rejection will not be considered a new ground of rejection if the prior art relied upon, and the rationale supporting the rejection, would be the same under either status. The following is a quotation of 35 U.S.C. 103 which forms the basis for all obviousness rejections set forth in this Office action: A patent for a claimed invention may not be obtained, notwithstanding that the claimed invention is not identically disclosed as set forth in section 102, if the differences between the claimed invention and the prior art are such that the claimed invention as a whole would have been obvious before the effective filing date of the claimed invention to a person having ordinary skill in the art to which the claimed invention pertains. Patentability shall not be negated by the manner in which the invention was made. Claims 1-5, 7-10, 13-17, 19, and 20 are rejected under 35 U.S.C. 103 as being unpatentable over Tingpeng (WO2020140932A1) in view of Xianghui (CN108572821A) and in further view of Kirmse (US20230103087A1). Regarding claim 1, Tingpeng teaches: A computer system comprising: a memory resource storing instructions; ([0016-0017] “A first memory and a first processor, wherein... The first memory is used to store programs.”) Tingpeng teaches an electronic device that includes a memory utilized for storing programs. one or more processors using the instructions stored in the memory resource to perform operations including: [0018] “The first processor, coupled to the first memory, is configured to execute the program stored in the first memory for”) Tingpeng further teaches that at least one processor is connected to the memory and processes the information that is stored in the memory which then executes the program instructions to perform the necessary operations. providing a design interface to render at last a portion of a graphic design; ([0013] “The user interface is displayed so that the user can input the image data to be processed.” [0045] “Determine the interface element information of the image file to be processed.” [0126] “The image file to be processed can be a design draft or a design drawing.”) Tingpeng teaches an interface where a user can input an image to be processed. providing a code interface to render a code representation for at least a portion of the graphic design wherein providing the code interface includes [0042] “To improve development efficiency and shorten the development cycle, this application provides a method for automatically generating interface code based on an image file to be processed.” [0045-0047] “Determine the interface element information of the image file to be processed. Based on the interface element information, determine the layout information of the interface. Generate interface code based on the layout information.” [0048] “These design software programs typically provide users with an application programming interface (API) (i.e., a plugin)” [0131] “Then, the interface code in the language selected by the user can be generated.”) Tingpeng teaches a system that provides a code interface that generates a code representation of an image file. This is done by determining elements of the image that is inputted and generating code based on that information which corresponds to rendering a code representation of a graphic as taught by the applicant. Tingpeng does not disclose: (1) executing one or more plugins to generate the code representation (2) the one or more plugins including at least a first plugin that is selectable by a user (3) to configure the generation of the code representation in accordance with one or more preferences However, Xianghui teaches: (1) executing one or more plugins to generate the code representation ([0038] “Step 106: The plugin generates user interface code for terminal operation based on the received code generation instructions, preset code templates and interface description file templates, and user interface under the drawing platform. The code generation instructions include code template identifiers.”) Xianghui teaches a plugin to generate code. Additionally, Xianghui teaches: (3) to configure the generation of the code representation in accordance with one or more preferences. ([0028] “In other embodiments, users can input page component selection instructions on an open API-based drawing platform, and the drawing platform can then display the page components corresponding to the page component selection instructions.” [0030] “Specifically, users can input ordinary component selection commands on the plugin”) Xianghui teaches a system where users provide a selection of instructions through an open API-based drawing platform, and a plugin that generates user interface code based on the code generation instructions provided by the user along with the selected templates. Tingpeng and Xianghui do not disclose: (2) the one or more plugins including at least a first plugin that is selectable by a user However, Kirmse teaches: (2) the one or more plugins including at least a first plugin that is selectable by a user ([0221] “providing an indication of the at least one plugin to the first user; receiving, from the first user, a selection of a first plugin from the at least one plugin”) Kirmse teaches a first plugin selected by a user. Therefore, it would have been obvious to a person having ordinary skill in the art before the effective filing date of the claimed invention to modify the teachings of Tingpeng to incorporate Xianghui’s plugin-based code generation with Kirmse’s user selected first plugin which would provide a more flexible and configurable approach to generating interface code based on user selections. Regarding claim 13, it is a method claim having similar limitations cited in the rejection of claim 1. Therefore, claim 13 is also rejected under the same rationale as cited in the rejection of claim 1 above. Regarding claim 20, it is a non-transitory computer-readable medium having similar limitations cited in the rejection of claim 1. Therefore, claim 20 is also rejected under the same rationale as cited in the rejection of claim 1 above. Regarding claim 2, Tingpeng teaches: wherein the first plugin supports a plurality of programming languages for the code representation. ([0049] “These design software programs typically provide users with an application programming interface (API) (i.e., a plugin)” [0053] “It can generate interface code corresponding to various code languages according to actual needs.” [0131] “The code language types include, but are not limited to: HTML (HyperText Markup Language), Vue, and Rax.”) Tingpeng teaches a system where a plugin generates interface code in various coding languages such as HTML and more which corresponds to supporting a plurality of programming languages. Regarding claim 14, it is a method claim having similar limitations cited in the rejection of claim 2. Therefore, claim 14 is also rejected under the same rationale as cited in the rejection of claim 2 above. Regarding claim 3, Tingpeng teaches: wherein the one or more preferences include a selection of a first programming language from the plurality of programming languages. ([0053] “It can generate interface code corresponding to various code languages according to actual needs.” [0129-0131] “Furthermore, the above method may also include: Display at least one control corresponding to a code language type on the operation interface for the user to select. The code language types include, but are not limited to: HTML (HyperText Markup Language), Vue, and Rax. Then, the interface code in the language selected by the user can be generated.”) Tingpeng teaches that a user can select a programming language from a variety of programming languages. Regarding claim 15, it is a method claim having similar limitations cited in the rejection of claim 3. Therefore, claim 13 is also rejected under the same rationale as cited in the rejection of claim 3 above. Regarding claim 4, Tingpeng teaches: wherein the first plugin converts an internal representation of at least some of the graphic design into the first programming language, the first program language being different from the internal representation. ([0049] “During the export process, the plugin iterates through all layers of the image file to be processed and performs type parsing and data extraction on all layers.” [0053] “In step 103 above, the layout information of the interface is converted into code to obtain the interface code.”) Tingpeng teaches parsing the image file and extracts layout information from the image layers. The extracted layout information is an internal representation of at least some of the graphic design because it represents the design information used by the plugin to generate code. Tingpeng further teaches converting the extracted layout information into interface code. Since the generated code is a programming language representation distinct from the extracted layout information, Tingpeng teaches converting an internal representation into a first programming language. Regarding claim 16, it is a method claim having similar limitations cited in the rejection of claim 4. Therefore, claim 16 is also rejected under the same rationale as cited in the rejection of claim 4 above. Regarding claim 5, Tingpeng teaches: wherein the first plugin retrieves data from one or more external repositories and integrates the data into the code representation. ([0049] “These design software programs typically provide users with an application programming interface (API) (i.e., a plugin), through which interface element information related to the design draft can be exported and cached in a cache space, such as the clipboard. During the export process, the plugin iterates through all layers of the image file to be processed and performs type parsing and data extraction on all layers.” [0051] “In step 102 above, UI element information can be exported from the cache space, layout recognition can be performed, and layout information can be obtained.” [0083-0086] “Furthermore, the step 103 above, "generating interface code based on the layout information," can be implemented using the following steps: Based on the layout information, match the corresponding code layout information from the code library. Based on the attribute information of each interface element in the layout information, match the attribute information of each node in the code layout information at the code level from the code library. Add the attribute information of each node at the code level to the code layout information to obtain the interface code.”) Tingpeng teaches retrieving code layout and attribute information from a code library which corresponds to the claimed external repository. Additionally, Tingpeng adds the retrieved information to generate the interface code and thereby integrating the retrieved data into the code representation. Regarding claim 17, it is a method claim having similar limitations cited in the rejection of claim 5. Therefore, claim 17 is also rejected under the same rationale as cited in the rejection of claim 5 above. Regarding claim 7, Tingpeng teaches: wherein executing the one or more plugins includes causing the code interface to identify an asset ([0050] “The interface element information may include: the attribute information of each interface element. The attribute information may include at least one of the following: name, type, coordinates, width and height, drawing order, fill content, and fill content style. The types of interface elements may include, but are not limited to: text, image, shape, input, and textArea.”) Applicant spec states [0040] “Further, the code interface 132 can include a separate segment to identify assets used in the graphic design, such as design elements that are part of a library associated with a library of an account associated with the user.” [0051] “In some aspects, the developer plugin 142 can call node.isAsset, which is an API that returns whether a given node is an asset. As used herein, an asset is a design element that is either an icon or a raster image.” Further defining an asset as a design element that is either an icon or a raster image. Tingpeng teaches identifying the interface elements which correspond to the claimed asset. Tingpeng does not disclose: as part of the code representation However, Xianghui teaches: as part of the code representation ([0041] “In practice, the color, font, text color and size of each component can also be set through the drawing platform. When the plugin traverses the components, it will also obtain the aforementioned attribute information and generate it into the code (or description file).”) Xianghui teaches generating the identified component information into code which corresponds to identifying the asset as part of the code representation. Therefore, it would have been obvious to a person having ordinary skill in the art before the effective filing date of the claimed invention to combine the teachings of Tingpeng and Xianghui so that executing the plugin causes the code interface to identify the corresponding asset. Doing so would enable a more complete code representation of the graphical design. Regarding claim 19, it is a method claim having similar limitations cited in the rejection of claim 7. Therefore, claim 19 is also rejected under the same rationale as cited in the rejection of claim 7 above. Regarding claim 8, Tingpeng teaches: wherein executing the one or more plugins includes inferring a layout rule amongst one or more layers of the graphic design. ([0074] “To better reflect the scenario of manually writing code in actual development and improve the actual usability and maintainability of the interface code, a flex layout property (i.e., the flex layout property) can be added to the layout information.” [0077] “Spacing rules for various scalability layout attributes can be pre-defined based on the specific application.” [0098] “The layer attribute information of each layer after the prediction rule processing is used as the attribute information of each interface element in the interface element information.” [0175] “In the technical solution provided in this application embodiment, interface element information is first exported from the image file to be processed, the layout information of the interface is determined based on the interface element information, and then the interface code is automatically generated based on the layout information.”) Tingpeng describes processing information from layers of a graphic design to determine the layout information. Tingpeng explains that layout information is determined based on the interface element information and that the layer attribute information after rule processing is used as the interface element information. Regarding claim 9, Tingpeng teaches: wherein the layout rule ([0077] “Spacing rules for various scalability layout attributes can be pre-defined based on the specific application.”) Tingpeng teaches spacing rules and layout attributes which correspond to a layout rule. Tingpeng does not disclose: specifies a spatial relationship amongst multiple layers of the graphic design However, Xianghui teaches: specifies a spatial relationship amongst multiple layers of the graphic design. ([0051] “The layout setting unit is used to receive layout setting instructions and adjust the position of ordinary components on page components according to the layout setting instructions. The layout setting instructions include relative layout information.”) Xianghui teaches relative layout information and adjusting the position of components which corresponds to specifying the spatial relationships between various elements/layers. Therefore, it would have been obvious to a person having ordinary skill in the art before the effective filing date of the claimed invention to apply Xianghui’s relative layout information to Tingpeng’s layout rules to define the spatial relationship among the layers and components which would result in the graphic design layout to be represented in generated interface code. Regarding claim 10, Tingpeng does not disclose: wherein the layout rule specifies a spacing between multiple layers of the graphic design. However, Xianghui teaches: wherein the layout rule specifies a spacing between multiple layers of the graphic design. ([0033] “The plugin adjusts the position of ordinary components according to the layout settings instructions, thus ensuring correct display effects on various screen resolutions and in both landscape and portrait orientations when implementing the user interface.” “In practical applications, this process is equivalent to UI designers marking the position and spacing of ordinary components on page components.” [0040] “Based on the relative layout information, it generates the constraint description into the interface description file to make each component and its relative position accurately presented, thereby generating the Java code file and interface description file of the user interface under Android.”) Xianghui teaches layout rules that define the relative spacing and positioning of UI components. A person of ordinary skill in the art would have understood that specifying relative positions and spacing between components/layers constitutes specifying spacing between multiple layers of the graphic design. Under the broadest reasonable interpretation, the term “spacing” reasonably encompasses ordinary layout spacing or relative spacing between elements. Claims 6 and 18 are rejected under 35 U.S.C. 103 as being unpatentable over Tingpeng (WO2020140932A1) in view of Xianghui (CN108572821A) in view of Kirmse (US20230103087A1) and in further view of Glaser et al (US20120042210A1). Regarding claim 6, Tingpeng teaches: wherein the graphic design is structured to define a plurality of layers, wherein each layer of the plurality of layers corresponds to one of an object, a group of objects, or a type of object; ([0048] “In the above 101, the image file to be processed can be a design draft or a design drawing. A design draft refers to the original file created by a UI designer using design software. This original file usually contains multiple layers.” [0096] “Export the layer attribute information of each layer from the image file to be processed.” [0099] “The layer attribute information includes name, type, coordinates, width and height, drawing order, fill content, and fill content style.”) Tingpeng discloses a graphic design including a plurality of layers. In view of the applicant’s spec which equates design elements with layers [0039] “The associations can map individual code elements of the code representation 145 to corresponding design elements (or layers) of the graphic design”, each disclosed layer reasonably corresponds to a design object/design element under the broadest reasonable interpretation of the claim. Tingpeng does not disclose: wherein executing the one or more plugins is performed in response to the user selecting a layer of the plurality of layers using one of the design interface or the code interface. However, Glaser teaches: wherein executing the one or more plugins is performed in response to the user selecting a layer of the plurality of layers using one of the design interface or the code interface. ([0040] “Particular embodiments provide the capability of testing different layers of an application/product in a single test framework.” “receiving, by a user interface, a selection of tests for execution from the plurality of tests, where the selected tests are configured to test a plurality of layers of a product” [0041] “ In addition, various layers of a product can be tested, such as graphical user interface (GUI), web service, API, database, and network test layers.” [0056] “ For example, various tests 406 can represent different product lines and/or product layers.” “These pluggable components may act together as building blocks that provide test coverage for different layers (e.g., GUI, API, web service, database, network, etc.) of the product.” [0065] “A selection of tests can be received for execution according to the user configurations, where the selected tests can test a plurality of layers of a product.”) Glaser teaches user selection of tests that represent different product layers for execution and further teaches pluggable components that provide test coverage for those layers. Under the broadest reasonable interpretation, selecting tests representing product layers corresponds to selecting a layer, thereby teaching the execution of one or more plugins in response to the user selection. Therefore, it would have been obvious to a person having ordinary skill in the art before the effective filing date of the claimed invention to combine the teachings of Glaser with the previous teachings of Tingpeng to provide users with greater control and flexibility by allowing plugins to be executed for selected layers of a graphic design, thereby improving the processing efficiency. Regarding claim 18, it is a method claim having similar limitations cited in the rejection of claim 6. Therefore, claim 18 is also rejected under the same rationale as cited in the rejection of claim 6 above. Claim 11 is rejected under 35 U.S.C. 103 as being unpatentable over Tingpeng (WO2020140932A1) in view of Xianghui (CN108572821A) in view of Kirmse (US20230103087A1) and in further view of Fu (CN114968407B). Regarding claim 11, Tingpeng does not disclose: wherein the first plugin is a third-party plugin However, Fu teaches: wherein the first plugin is a third-party plugin ([0040] “The first plugin can be a third-party plugin.”) Fu teaches a system where the first plugin can be a third-party plugin. Therefore, it would have been obvious to a person having ordinary skill in the art before the effective filing date of the claimed invention to combine the teachings of Fu with the previous teachings of Tingpeng to achieve a flexible and extensible system that allows outside parties to integrate alternative algorithms to generate code based on a graphic design. Claim 12 is rejected under 35 U.S.C. 103 as being unpatentable over Tingpeng (WO2020140932A1) in view of Xianghui (CN108572821A) in view of Kirmse (US20230103087A1) and in further view of Parker et al (US8094583B2). Regarding claim 12, Tingpeng does not disclose: wherein the first plugin has read-only access to the graphic design. However, Parker teaches: wherein the first plugin has read-only access to the graphic design. ([0020] “The extended information repositories are adapted to present information to a plug-in as read-only information”) Parker teaches a method in which information retrieved from repositories is presented to a plugin as read-only information. Therefore, it would have been obvious to a person having ordinary skill in the art before the effective filing date of the claimed invention to modify the previously taught plugin to access the graphic design as taught by Parker to achieve a system that presents information retrieved from repositories to plugins as read-only information. Making this modification would preserve the integrity of the original graphic design while still allowing the plugin to analyze the design and generate the corresponding output. Conclusion The prior art made of record and not relied upon is considered pertinent to applicant's disclosure. (US12099818B2) Plugin-oriented functional programming system configured with software components: Teaches a computing system for plugin-oriented functional programming. Any inquiry concerning this communication or earlier communications from the examiner should be directed to Tubba Noor whose telephone number is 571-270-0803. The examiner can normally be reached on Monday-Friday from 8:00 AM to 5:00 PM. If attempts to reach the examiner by telephone are unsuccessful, the examiner’s supervisor, Chat Do, can be reached at telephone number 571-272-3721. The fax phone number for the organization where this application or proceeding is assigned is 571-273-8300. Examiner interviews are available via telephone, in-person, and video conferencing using a USPTO supplied web-based collaboration tool. To schedule an interview, applicant is encouraged to use the USPTO Automated Interview Request (AIR) Form at https://www.uspto.gov/patents/uspto-automated- interview-request-air-form. Information regarding the status of published or unpublished applications may be obtained from Patent Center. Unpublished application information in Patent Center is available to registered users. To file and manage patent submissions in Patent Center, visit: https://patentcenter.uspto.gov. Visit https://www.uspto.gov/patents/apply/patent-center for more information about Patent Center and https://www.uspto.gov/patents/docx for information about filing in DOCX format. For additional questions, contact the Electronic Business Center (EBC) at 866-217-9197 (toll-free). If you would like assistance from a USPTO Customer Service Representative, call 800-786-9199 (IN USA OR CANADA) or 571-272-1000. /TUBBA NOOR/Examiner, Art Unit 2193 /Chat C Do/Supervisory Patent Examiner, Art Unit 2193
Read full office action

Prosecution Timeline

Jun 20, 2024
Application Filed
Aug 10, 2026
Non-Final Rejection mailed — §103 (current)

Strategy Recommendation AI-generated — please review before filing

Get a prosecution strategy drawn from examiner precedents, rejection analysis, and claim mapping.
Typically takes 5-10 seconds — AI-generated, attorney review required before filing

Prosecution Projections

1-2
Expected OA Rounds
Grant Probability
Low
PTA Risk
Based on 0 resolved cases by this examiner. Grant probability derived from career allowance rate.

Sign in with your work email

Enter your email to receive a magic link. No password needed.

Personal email addresses (Gmail, Yahoo, etc.) are not accepted.

Free tier: 3 strategy analyses per month