Prosecution Insights
Last updated: July 17, 2026
Application No. 18/782,091

SYSTEM AND METHOD PROVIDING SPECIALIZED SIZE UNITS IN RESPONSIVE EDITING

Non-Final OA §103
Filed
Jul 24, 2024
Priority
Jul 24, 2023 — provisional 63/515,142 +1 more
Examiner
NGUYEN, CAO H
Art Unit
Tech Center
Assignee
Wix.com Ltd.
OA Round
1 (Non-Final)
91%
Grant Probability
Favorable
1-2
OA Rounds
7m
Est. Remaining
98%
With Interview

Examiner Intelligence

Grants 91% — above average
91%
Career Allowance Rate
1042 granted / 1147 resolved
+30.8% vs TC avg
Moderate +8% lift
Without
With
+7.5%
Interview Lift
resolved cases with interview
Typical timeline
2y 6m
Avg Prosecution
15 currently pending
Career history
1159
Total Applications
across all art units

Statute-Specific Performance

§101
1.5%
-38.5% vs TC avg
§103
68.8%
+28.8% vs TC avg
§102
14.5%
-25.5% vs TC avg
§112
0.6%
-39.4% vs TC avg
Black line = Tech Center average estimate • Based on career data from 1147 resolved cases

Office Action

§103
DETAILED ACTION 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 . 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. The factual inquiries for establishing a background for determining obviousness under 35 U.S.C. 103 are summarized as follows: 1. Determining the scope and contents of the prior art. 2. Ascertaining the differences between the prior art and the claims at issue. 3. Resolving the level of ordinary skill in the pertinent art. 4. Considering objective evidence present in the application indicating obviousness or nonobviousness. This application currently names joint inventors. In considering patentability of the claims the examiner presumes that the subject matter of the various claims was commonly owned as of the effective filing date of the claimed invention(s) absent any evidence to the contrary. Applicant is advised of the obligation under 37 CFR 1.56 to point out the inventor and effective filing dates of each claim that was not commonly owned as of the effective filing date of the later invention in order for the examiner to consider the applicability of 35 U.S.C. 102(b)(2)(C) for any potential 35 U.S.C. 102(a)(2) prior art against the later invention. Claim(s) 1-20 is/are rejected under 35 U.S.C. 103 as being unpatentable over Fialkow et al. (US Patent Application Publication No. 2020/0372206) in view of Abrahami (US Patent Application Publication No. 2013/0219263). Regarding claims 1 and 17, Fialkow discloses a website building system (WBS), the system comprising [see para. 0003; Website building systems (WBS) are used by both novices and professionals to create interactive websites. Existing WBSs are based on a visual editing model and most WBSs typically provide multiple templates, with a template possibly including a complete sample website, a website section]: an editor to enable a designer of said WBS to create and edit a website on a first sized viewport [see para. 0022; the user's first experience when creating a site using a WBS visual editor may typically be that the user chooses a template (e.g. according to style or industry type/sub-type), possibly a blank template and then edits the template in the visual editor including the editing of content, logic, layout and attributes; which corresponds to WBS editor for visual creation and editing on pages], said website having at least one component having at least one property with a display pixel value for a measurement of said first sized viewport represented as a designer intent responsive pixel (DIRP) [see para. 0096; 0115; A layout may incorporate fluid components whose size and attributes may be affected by their parents (e.g. by parent changes or viewport width changes) or by additional triggers. The effects could be automatically determined by the system also be specified or edited by the user (e.g. the component width is a given percentage or function of the parent component width) and responsive editing module allow a user to define width value breakpoints and matching breakpoint ranges for displays associated with different viewports (such as 320-750 pixels for a smartphone screen, 750-1000 pixels for a tablet screen and 1000 pixels and higher for a desktop screen etc.); which corresponds to pixel based properties in original layout], said editor to save a representation of said website according to an original layout of said website [see para. 0005, 0011, 0023; Under the site generation model, the WBS generates an initial site for the user, based on a selected template, possibly modified by filling-in common elements of information, and possibly allowing follow-up editing of the generated site. This filling-in is required as various pieces of information (such as the business name or a description of the management team) are included in multiple locations in the template's pages. Thus, the user may have to change the business name (for example) in multiple places throughout the template; which corresponds to save a representation of website]; however, Fialkow fails to explicitly teach a scaling pixel handler to render said representation onto a second sized viewport and to display said at least one component proportionally as scaled version of said DIRP according to a measurement of said second sized viewport; and wherein said rendered representation maintains said original layout. Abrahami discloses a scaling pixel handler to render said representation onto a second sized viewport and to display said at least one component proportionally as scaled version of said DIRP according to a measurement of said second sized viewport [see para. 0209-0211; Using a pixel value which is adjusted relative to the size of display device displaying the application, so if (for example), an application is scaled down 20% due to a display screen having a lower resolution, the threshold values are also scaled down by 20%. Using a pixel value which is adjusted relative to the sizes of the two components being anchored--so if one of the components is enlarged, the required anchor distance would grow proportionally. The dynamic layout basic parameter value may be specified using the minimal, maximal or average size of the components involved; which corresponds to dynamic scaling and resizing for viewport changes]; and wherein said rendered representation maintains said original layout [see para. 0148; A copy of the information may also be stored locally on client in cases where end-user is allowed to modify certain aspects of the application (such as the size and position of certain components). There multiple versions of the stored dynamic layout information for the same stored application. This information may include anchor information, anchor creation history and the original position and size for each component affected by the dynamic layout as well as any designer or end-user set parameters; which corresponds to anchor maintain original layout relationship]. It would have been obvious to one of an ordinary skill in the art, having the teachings of Fialkow and Abrahami before the affective filing date of the claimed invention to modify, a website building system of Fialkow to include integrating dynamic layout and dynamic content, as taught by Abrahami. One would have been motivated to make such a combination in order to provide a scaling pixel handler for improved cross device while preserving original layout intent and a cascading style sheet generator to map the features of the updated fluid responsive design layout design into a smart CSS for the current viewport. Regarding claims 2 and 10, Fialkow discloses wherein said at least one component comprises at least one of: page, a section, a mini-page, a regular container, a single-page container, a multi-page container and a gallery container [see para. 0007, 0008; The WBS may also support hierarchical arrangements of components using atomic components (text, image, shape, video etc.) as well as various types of container components which contain other components (e.g. regular containers, single-page containers, multi-page containers, gallery containers etc.). The sub-pages contained inside a container component are referred to as mini-pages, and each of which may contain multiple components. Some container components may display just one of the mini-pages at a time, while others may display multiple mini-pages simultaneously]. Regarding claims 3 and 11, Fialkow discloses wherein said editor comprises: a visual editor to enable said editing using a stage and panels; and a document converter to save said representation using a data representation language [see para. 0217, 0313 and figure 11A; The Add Panel may include atomic components, containers, design elements (such as layouters and repeaters) as well as pre-fabricated sections. The Add Panel may also include WBS services and verticals, such as blog, store and bookings; Component grouper convert a site description (e.g. in data description languages such as XML or JSON) to a hierarchical set of group definitions]. Regarding claims 4 and 12, Fialkow discloses wherein said scaling pixel handler comprises: a document renderer to convert said representation to CSS properties for said display according to said original layout; and a machine learning (ML)/artificial intelligence (AI) engine to provide recommendations and overrides for said document renderer [see para. 0105, 0232; Responsive editor enable a user to create and edit responsive websites (including specifying ranges for breakpoints) and may use functionality from rule engine and ML/AI engine. CSS generator generate smart CSS's as a result of an editing change and mesh applier used to transform nonresponsive websites into responsive ones having grids that are responsive target display changes. ML/AI engine analyze the absolute (WYSIWYG) layout definitions during editing and saving (or other site operations), and detect user intent]. Regarding claims 5 and 13, Fialkow discloses wherein said document renderer comprises a designer intent responsive pixel (DIRP) calculator to scale said DIRPs according to said measurement of said second sized viewport [see para. 0096; 0115; A layout incorporate fluid components whose size and attributes may be affected by their parents (e.g. by parent changes or viewport width changes) or by additional triggers. The effects could be automatically determined by the system also be specified or edited by the user (e.g. the component width is a given percentage or function of the parent component width) and responsive editing module allow a user to define width value breakpoints and matching breakpoint ranges for displays associated with different viewports (such as 320-750 pixels for a smartphone screen, 750-1000 pixels for a tablet screen and 1000 pixels and higher for a desktop screen etc.); which corresponds to pixel based properties in original layout]. Regarding claims 6 and 14, Fialkow discloses wherein said measurement is width or height [see para. 0114; the affecting variables may be not a single parameter (or a combination thereof), but rather a function of multiple parameters. For example, system allow defining different layouts based on the aspect ratio of the display (which is a function of the display width and height)]. Regarding claims 7 and 15, Fialkow discloses, wherein said at least one property is at least one of: font size, corner radius, border width and box shadow [see para. 0130; hus, a site may detect when a user is viewing it from a distance (thus viewing the site on an “effectively smaller” screen) and adapt the site to that distant viewing, possibly changing site layout and using a larger font size. The site then change as the user approaches the screen. The user's distance e measured (for example) by any sensor available to the system, or analysis of video camera output available to the system. This also work with multiple viewing users (e.g. in a public setting) by optimizing for the distance that best represents the multiple viewers (e.g. average distance)]. Regarding claims 8 and 16, Fialkow discloses wherein said original layout comprises a typography of said website [see para. 0130, 0131; a site detect when a user is viewing it from a distance (thus viewing the site on an “effectively smaller” screen) and adapt the site to that distant viewing, possibly changing site layout and using a larger font size. The site then change as the user approaches the screen. The user's distance may be measured (for example) by any sensor available to the system, or analysis of video camera output available to the system. This may also work with multiple viewing users (e.g. in a public setting) by optimizing for the distance that best represents the multiple viewers (e.g. average distance)]. Regarding claim 9, Fialkow discloses a method for a website building system (WBS), the method comprising [see para. 0003; Website building systems (WBS) are used by both novices and professionals to create interactive websites. Existing WBSs are based on a visual editing model and most WBSs typically provide multiple templates, with a template possibly including a complete sample website, a website section]: enabling a designer of said WBS to create and edit a website on a first sized viewport [see para. 0022; the user's first experience when creating a site using a WBS visual editor may typically be that the user chooses a template (e.g. according to style or industry type/sub-type), possibly a blank template and then edits the template in the visual editor including the editing of content, logic, layout and attributes; which corresponds to WBS editor for visual creation and editing on pages], said website having at least one component having at least one property with a display pixel value for a measurement of said first sized viewport represented as a designer intent responsive pixel (DIRP) [see para. 0096; 0115; A layout may incorporate fluid components whose size and attributes may be affected by their parents (e.g. by parent changes or viewport width changes) or by additional triggers. The effects could be automatically determined by the system also be specified or edited by the user (e.g. the component width is a given percentage or function of the parent component width) and responsive editing module allow a user to define width value breakpoints and matching breakpoint ranges for displays associated with different viewports (such as 320-750 pixels for a smartphone screen, 750-1000 pixels for a tablet screen and 1000 pixels and higher for a desktop screen etc.); which corresponds to pixel based properties in original layout], said editor to save a representation of said website according to an original layout of said website [see para. 0005, 0011, 0023; Under the site generation model, the WBS generates an initial site for the user, based on a selected template, possibly modified by filling-in common elements of information, and possibly allowing follow-up editing of the generated site. This filling-in is required as various pieces of information (such as the business name or a description of the management team) are included in multiple locations in the template's pages. Thus, the user may have to change the business name (for example) in multiple places throughout the template; which corresponds to save a representation of website]; however, Fialkow fails to explicitly teach saving a representation of said website according to an original layout of said website; rendering said representation onto a second sized viewport; displaying said at least one component proportionally as scaled version of said DIRP according to a measurement of said second sized viewport; and wherein said rendered representation maintains said original layout. Abrahami discloses saving a representation of said website according to an original layout of said website; rendering said representation onto a second sized viewport; displaying said at least one component proportionally as scaled version of said DIRP according to a measurement of said second sized viewport; and wherein said rendered representation maintains said original layout [see para. 0209-0211; Using a pixel value which is adjusted relative to the size of display device displaying the application, so if (for example), an application is scaled down 20% due to a display screen having a lower resolution, the threshold values are also scaled down by 20%. Using a pixel value which is adjusted relative to the sizes of the two components being anchored--so if one of the components is enlarged, the required anchor distance would grow proportionally. The dynamic layout basic parameter value may be specified using the minimal, maximal or average size of the components involved; which corresponds to dynamic scaling and resizing for viewport changes]; and wherein said rendered representation maintains said original layout [see para. 0148; A copy of the information may also be stored locally on client in cases where end-user is allowed to modify certain aspects of the application (such as the size and position of certain components). There multiple versions of the stored dynamic layout information for the same stored application. This information may include anchor information, anchor creation history and the original position and size for each component affected by the dynamic layout as well as any designer or end-user set parameters; which corresponds to anchor maintain original layout relationship]. It would have been obvious to one of an ordinary skill in the art, having the teachings of Fialkow and Abrahami before the affective filing date of the claimed invention to modify, a website building system of Fialkow to include integrating dynamic layout and dynamic content, as taught by Abrahami. One would have been motivated to make such a combination in order to provide a scaling pixel handler for improved cross device while preserving original layout intent and a cascading style sheet generator to map the features of the updated fluid responsive design layout design into a smart CSS for the current viewport. Regarding claim 18, Abrahami discloses wherein the scaling pixel handler is further configured to: receive a user input specifying a custom viewport size; and dynamically update said rendered CSS based on said custom viewport size [see para. 0209-0211; Using a pixel value which is adjusted relative to the size of display device displaying the application, so if (for example), an application is scaled down 20% due to a display screen having a lower resolution, the threshold values are also scaled down by 20%. Using a pixel value which is adjusted relative to the sizes of the two components being anchored--so if one of the components is enlarged, the required anchor distance would grow proportionally. The dynamic layout basic parameter value may be specified using the minimal, maximal or average size of the components involved; which corresponds to dynamic scaling and resizing for viewport changes]. Regarding claim 19, Fialkow discloses wherein dynamically updating the rendered CSS comprises recalculating said conversion of DIRPs to CSS units based on a ratio between the custom viewport size and said reference viewport size [see para. 0096; 0115; A layout may incorporate fluid components whose size and attributes may be affected by their parents (e.g. by parent changes or viewport width changes) or by additional triggers. The effects could be automatically determined by the system also be specified or edited by the user (e.g. the component width is a given percentage or function of the parent component width) and responsive editing module allow a user to define width value breakpoints and matching breakpoint ranges for displays associated with different viewports (such as 320-750 pixels for a smartphone screen, 750-1000 pixels for a tablet screen and 1000 pixels and higher for a desktop screen etc.); which corresponds to pixel based properties in original layout]. Regarding claim 20, Abrahami discloses, wherein the scaling pixel handler is further configured to maintain a consistent typography scale across different viewport sizes by applying a scaling factor to font sizes defined using DIRPs [see para. 0209-0211; Using a pixel value which is adjusted relative to the size of display device displaying the application, so if (for example), an application is scaled down 20% due to a display screen having a lower resolution, the threshold values are also scaled down by 20%. Using a pixel value which is adjusted relative to the sizes of the two components being anchored--so if one of the components is enlarged, the required anchor distance would grow proportionally. The dynamic layout basic parameter value may be specified using the minimal, maximal or average size of the components involved; which corresponds to dynamic scaling and resizing for viewport changes]. Conclusion The prior art made of record and not relied upon is considered pertinent to applicant's disclosure (See PTO-892). Blumenfeld et al. (2020/0151226) discloses the system has database storing website components, together with definitions and instances of WCAs. The WCAs are single packaged entities which is accessed as a set of customizable elements. A WCA application (app) builder (360) is configured to enable a developer to build and edit a first version WCA. An in-site editor (330) is configured to provide specific editing capabilities for a user to edit a definition or an instance of the first version WCA. A WCA handler (370) is configured to receive a modification to the first version WCA from the user and update to the first version WCA from the developer. A reference to specific paragraphs, columns, pages, or figures in a cited prior art reference is not limited to preferred embodiments or any specific examples. It is well settled that a prior art reference, in its entirety, must be considered for all that it expressly teaches and fairly suggests to one having ordinary skill in the art. Stated differently, a prior art disclosure reading on a limitation of Applicant's claim cannot be ignored on the ground that other embodiments disclosed were instead cited. Therefore, the Examiner's citation to a specific portion of a single prior art reference is not intended to exclusively dictate, but rather, to demonstrate an exemplary disclosure commensurate with the specific limitations being addressed. In re Heck, 699 F.2d 1331, 1332-33,216 USPQ 1038, 1039 (Fed. Cir. 1983) (quoting In re Lemelson, 397 F.2d 1006,1009, 158 USPQ 275, 277 (CCPA 1968)). In re: Upsher-Smith Labs. v. Pamlab, LLC, 412 F.3d 1319, 1323, 75 USPQ2d 1213, 1215 (Fed. Cir. 2005); In re Fritch, 972 F.2d 1260, 1264, 23 USPQ2d 1780, 1782 (Fed. Cir. 1992); Merck & Co. v. Biocraft Labs., Inc., 874 F.2d 804, 807, 10 USPQ2d 1843, 1846 (Fed. Cir. 1989); In re Fracalossi, 681 F.2d 792,794 n.1,215 USPQ 569, 570 n.1 (CCPA 1982); In re Lamberti, 545 F.2d 747, 750, 192 USPQ 278, 280 (CCPA 1976); In re Bozek, 416 F.2d 1385, 1390, 163 USPQ 545, 549 (CCPA 1969). Any inquiry concerning this communication or earlier communications from the examiner should be directed to CAO H NGUYEN whose telephone number is (571)272-4053. The examiner can normally be reached on Mon-Fri 9am-5pm. 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) at http://www.uspto.gov/interviewpractice. If attempts to reach the examiner by telephone are unsuccessful, the examiner’s supervisor, Kieu Vu can be reached on 571-272-4057. The fax phone number for the organization where this application or proceeding is assigned is 571-273-8300. Information regarding the status of an application may be obtained from the Patent Application Information Retrieval (PAIR) system. Status information for published applications may be obtained from either Private PAIR or Public PAIR. Status information for unpublished applications is available through Private PAIR only. For more information about the PAIR system, see http://pair-direct.uspto.gov. Should you have questions on access to the Private PAIR system, contact the Electronic Business Center (EBC) at 866-217-9197 (toll-free). If you would like assistance from a USPTO Customer Service Representative or access to the automated information system, call 800-786-9199 (IN USA OR CANADA) or 571-272-1000. /CAO H NGUYEN/Primary Examiner, Art Unit 2171
Read full office action

Prosecution Timeline

Jul 24, 2024
Application Filed
Jun 25, 2026
Non-Final Rejection mailed — §103
Jul 08, 2026
Interview Requested

Precedent Cases

Applications granted by this same examiner with similar technology

Patent 12675541
Multimodal Web Navigation
2y 4m to grant Granted Jul 07, 2026
Patent 12669921
CONTENT COLLECTION INDICATORS WITHIN A GROUP MESSAGING SYSTEM
2y 4m to grant Granted Jun 30, 2026
Patent 12664354
SYSTEM AND GRAPHICAL USER INTERFACE FOR DOCUMENT EDITING AND PUBLICATION CONTROL
2y 5m to grant Granted Jun 23, 2026
Patent 12657042
SYSTEMS AND METHODS FOR IMPROVED GRAPHICAL USER INTERFACES BASED ON CONTEXTUAL INFORMATION
2y 7m to grant Granted Jun 16, 2026
Patent 12656933
INPUT METHOD, DEVICE, AND STORAGE MEDIUM
2y 6m to grant Granted Jun 16, 2026
Study what changed to get past this examiner. Based on 5 most recent grants.

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
91%
Grant Probability
98%
With Interview (+7.5%)
2y 6m (~7m remaining)
Median Time to Grant
Low
PTA Risk
Based on 1147 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