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 § 102
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 the appropriate paragraphs of 35 U.S.C. 102 that form the basis for the rejections under this section made in this Office action:
A person shall be entitled to a patent unless –
(a)(1) the claimed invention was patented, described in a printed publication, or in public use, on sale, or otherwise available to the public before the effective filing date of the claimed invention.
Claims 10, 16, 19-20 and 27 are rejected under 35 U.S.C. 102(a)(1) as being anticipated by Yang et al. (US 2014/0047409 A1).
As per claim 10 (Amended), Yang teaches the invention as claimed including, “An application development method, comprising:
displaying a page editing interface; and generating a page program according to an operation of a user on the page editing interface, wherein the operation comprises generating a page layout using materials and components, and configuring page information for the page layout;
configuring an application mid-end for the page program; and” Yang et al. teaches an application development tool that allows users to select and modify widgets (material and components), map API properties to widget attributes and create application user interfaces using the widgets. To modify the widgets and create applications, the application development tool edits the source code associated with the widget or application based on input received from the user via the application development tool interface (0022). Also see 0028. User can determine whether the selected widget should interact with the backend via entity APIs (mid-end) or if the widget selected at block 1 should interact with the backend platform via controller APIs (mid-end) (0032). If it is determined that a backend entity API is to be used, entity properties are mapped to widget attributes. API properties such as “id”, “name”, “percentage” of the selected backend entity are mapped to corresponding widget attributes. The application development tool maps the selected API property to the associated widget attributed by editing the source code of the widget using generated segments of code (0033-0036). Also see 0041-0042. A user can use the application development tool to generate a container having one or more widgets (0041). The application development tool allows a user to adjust a height, width, and page-level attributes (page information) associated with a container for deployment on various types of target platforms (0044).
“integrating the page program and the application mid-end to obtain an application
program.”
The application development tool may generate or select computer code to develop the application. Computer code may include program source code such as C or C++. The computer code may be used directly by the application development tool, such as by performing all or some of the steps necessary for creating a computer application. These steps may include interpreting, compiling, assembling, linking (integrating) and/or loading the computer code. The application development tool is used to design an application UI (page) having one or more widgets, map API properties to properties of the widgets, edit source code of the application and widgets, modify settings of the application and widgets, and the like (0027).
“wherein the application mid-end is configured to push page data, update page data, summarize page data, or any combination thereof; and
wherein configuring the application mid-end for the page program comprises:
determining page data to be pushed, page data to be updated, page data to be summarized, or any combination thereof in the page program.”
User can determine whether the selected widget should interact with the backend via entity APIs (mid-end) or if the widget selected at block 1 should interact with the backend platform via controller APIs (mid-end) (0032). If it is determined that a backend entity API is to be used, entity properties are mapped to widget attributes. API properties such as “id”, “name”, percentage” of the selected backend entity are mapped to corresponding widget attributes. The application development tool maps the selected API property to the associated widget attributed by editing the source code of the widget using progenerated segments of code (0033-0036). Also see 0026, 0036-0038 and figure 2. As can be seen in figure 1 data is sent from the platform database though a API (middleware) to a widget to be displayed.
As per claim 16, Yang et al. further teaches, “The method according to claim 10, wherein the page information comprises: page attribute information, page event information, page data information, page interaction information, page-to-page relationship information, or any combination thereof.”
A user can use the application development tool to generate a container having one or more widgets (0041). The application development tool allows a user to adjust a height, width, and page-level attributes associated with a container for deployment on various types of target platforms (0044).
As per claims 19-20 and 27, they contain similar limitations to claim 10 and 16 and are therefore rejected for similar reasons.
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 11-13, 21-24 are rejected under 35 U.S.C. 103 as being unpatentable over Yang et al. (US 2014/0047409 A1) as applied to claims 10 and 19-20 above, and further in view of Xie et al. (US 2018/02396621 A1).
As per claim 11, Yang et al. further teaches, The applicant development may generate or select computer code to develop application. Computer code may include program source code such as C or C++. The computer code may be used directly by the application development tool, such as by performing all or some of the steps necessary for creating a computer application. These steps may include interpreting, compiling, assembling, linking and/or loading the computer code” (0027).
However, Yang et al. does not explicitly appear to teach, “The method according to claim 10, wherein generating the page program according to the operation of the user on the page editing interface comprises:
editing interface into an intermediate component used to represent a page layout and/or page
information in the page layout, and generating a page program composed of the intermediate component.”
Xie et al. teaches, obtaining source code, compiling the source code to generate a plurality of intermediate files and linking the plurality of intermediate files to generate an object file (figures 2-4).
It would have been obvious to one of ordinary skill before the effective filing date to modify Yang et al. with Xie et al. Yang et al. teaches performing steps on the source code, including interpreting, compiling, assembling and linking which are well known steps in program/application generation. Xie et al. teaches a compiling step that generates a plurality of intermediate files which are then linked in order to generate the object file. Compiling source code into an intermediate representation in order to generate a program (object file/machine code )is well known to one of ordinary skill and would have been obvious to try. Performing these different compilation steps are nothing more than a design choice.
As per claim 12, Yang et al. and Xie et al. further teach, “The method according to claim 11, wherein the conversion module is developed based on a cross platform framework; and the intermediate component is configured to be parsed into actual executable code under the cross-platform framework.”
Yang et al. teaches, The applicant development may generate or select computer code to develop application. Computer code may include program source code such as C or C++. The computer code may be used directly by the application development tool, such as by performing all or some of the steps necessary for creating a computer application. These steps may include interpreting, compiling, assembling, linking and/or loading the computer code” (0027). The development tool allows deployment on various types of platforms (cross platform) (0044).
Xie et al. teaches, obtaining source code, compiling the source code to generate a plurality of intermediate files and linking the plurality of intermediate files to generate a object file (figures 2-4). Refer to claim 11 for motivation to combine.
As per claim 13, Yang et al. and Xie et al. further teach, “The method according to claim 12, wherein integrating the page program and the application mid-end to obtain the application program comprises:
parsing the intermediate component of the page program into the actual executable code
under the cross-platform framework to obtain an executable page program; and
integrating the executable page program and the application mid-end to obtain the
application program.”
Yang et al. teaches, the applicant development may generate or select computer code to develop application. Computer code may include program source code such as C or C++. The computer code may be used directly by the application development tool, such as by performing all or some of the steps necessary for creating a computer application. These steps may include interpreting, compiling, assembling, linking (integrating) and/or loading the computer code” (0027).
Xie et al. teaches, obtaining source code, compiling the source code to generate a plurality of intermediate files and linking (integrating)the plurality of intermediate files to generate a object file (figures 2-4). Refer to claim 11 for the motivation to combine.
As per claims 21-24, they contain similar limitations to claims 11-13 and are rejected for similar reasons.
Claims 14-15 and 25-26 are rejected under 35 U.S.C. 103 as being unpatentable over Yang et al. (US 2014/0047409 A1) as applied to claims 10 and 20 above, and further in view of Klask et al. (US 20110214078 A1).
As per claim 14, Yang et al. do not explicitly appear to teach, “The method according to claim 10, further comprising:
displaying a material editing interface; and
according to an operation of the user on the material editing interface, generating a new
edited material based on an existing material.
Klask et al. teaches, a widget builder for the user to create a customized widget (new edited material) from a template widget (material) or create a new template widget (material). Template widgets are used in the GUI builder to create widgets in a GUI (0052). Also see 0047, 0057 and 0063. Also see figures 5-6.
It would have been obvious to one of ordinary skill in the art before the effective filing date to modify Yang et al. with Klask et al. because both teach the use of widgets to generate a UI program. Klask et al. teaches a GUI that allows at user to generate and customize widgets that can then be used as templates to generate a UI. This known technique would improve Yang et al. allow it to create and customize more widgets for future use.
As per claim 15, Klask et al. further teaches, “The method according to claim 14, wherein according to the operation of the user on the material editing interface, generating the new edited material based on the existing material comprises:
according to the operation of the user on the material editing interface, by a basic material component pre-determined based on the cross-platform framework, converting a basic material component combination corresponding to the existing material into a basic material component combination corresponding to the new edited material; wherein the basic material component is configured to be parsed into a basic material under the cross-platform framework.
Klask et al. teaches, a widget builder for the user to create a customized widget (new edited material) from a template widget (basic material) or create a new template widget (material). Template widgets are used in the GUI builder to create widgets in a GUI (0052). Also see 0047, 0057 and 0063. Also see figures 5-6. Refer to claim 14 for the motivation to combine.
Yang et al. teaches an application development tool that allows users to select and modify widgets, map API properties to widget attributes an create application user interfaces using the widgets. To modify the widgets and create applications, the application development tool edits the source code associated with the widget or application based on input received from the suer via the application development tool interface (0022). The application development tool may generate or select computer code to develop application. Computer code may include program source code such as C or C++. The computer code may be used directly by the application development tool, such as by performing all or some of the steps necessary for creating a computer application. These steps may include interpreting, compiling, assembling, linking (integrating) and/or loading the computer code” (0027).
As per claims 25-26, they contain similar limitation to claims 14-15 and are therefore rejected for similar reasons.
Response to Arguments
Applicant's arguments filed 7/22/2026 have been fully considered but they are not persuasive.
Regarding 35 U.S.C 102 rejection:
Applicant argues:
“Claim 10 recites "displaying a page editing interface." While Yang discloses an application development tool interface for widget selection and preview. Specifically, Yang states that "the application development tool interface includes: a widget selection interface for displaying a representation of a plurality of widgets, a widget preview interface for displaying a preview of the first widget, and an application preview interface for displaying a preview of the application" (Yang, [0009]). Yang further states that "interface 300 may include widget selection interface 302 for displaying a list of one or more widgets from a local or remote database" (Yang, [0029]). Thus, Yang's interface is directed to selecting widgets, previewing widgets, and previewing an application. Yang does not disclose a "page editing interface," and does not disclose an interface specifically used for editing a page as required by claim 10. That is, Yang fails to teach the technical feature "displaying a page editing interface.
Claim 10 further recites "generating a page program according to an operation of a user on the page editing interface, wherein the operation comprises generating a page layout using materials and components, and configuring page information for the page layout." While Yang discloses selecting widgets from a widget library and mapping API properties to widget attributes. For example, Yang states that "[a]t block 1 of process 200, a widget may be selected from a widget library" (Yang, [0028]), and that "entity properties may be mapped to widget attributes" (Yang, [0033]). Yang also states that "an application UI may be generated by adding the widget to the UI" (Yang, [0041]). These disclosures concern widget selection, widget placement, and API-property-to-widget-attribute mapping. They do not disclose generating a page program according to an operation of a user on a page editing interface. They also do not disclose that the operation comprises generating a page layout using materials and components, and configuring page information for the page layout. At most, Yang discloses positioning widgets in an application UI; this is not the same as generating a page program based on a page layout and page information. Thus, Yang fails to disclose this technical feature.”
The examiner disagrees. Applicant's arguments fail to comply with 37 CFR 1.111(b) because they amount to a general allegation that the claims define a patentable invention without specifically pointing out how the language of the claims patentably distinguishes them from the references. Applicant argues that Yang interface is directed to selecting widgets, previewing widgets and previewing an applicant but does not disclose a “page editing interface” and the “displaying a page editing interface”. However, applicant never states what exactly a page editing interface is and how it differentiates from Yang. Just stating using widgets is not the same as a page program is not enough. As claimed the examiner interprets a page editing interface as a interface that allows a user to edit/design a page/user interface of a program. This includes the layout and components in the page. As stated in the rejection, Yang teaches a application development tool that allows a user to select and modify widgets, map API properties to widget attributes and create application user interface using the widgets (0022). Therefore, the user is using a page editor (application development tool) to create a page program (application user interface of widgets), which meets the claimed limitations. As stated in paragraph 0028 an application (page program) is developed using the application development tool. Yang further states a user can use the application development tool to generate a container (page program) having one or more widgets (materials and components) (0041) and that the application development tool allows a user to adjust a heigh, width, and page-level attributes (configure information for page layout) associated with a container for deployment. Under their broadest reasonable interpretation the claimed limitations are taught by Yang et al.
Applicant further argues: “Claim 10 further recites "configuring an application mid-end for the page program." While Yang discloses a backend system and APIs. For example, Yang states that "the application development tool 102 may communicate with the backend 104 using API 106" (Yang, [0023]). Yang also states that "application 108 ... may also access the backend system 104 using the API 106" (Yang, [0026]). A backend system accessed through APIs is not an "application mid-end" configured for a page program. Yang's disclosure is directed to querying backend APIs and mapping API properties to widget attributes, not to configuring an application mid-end for the page program. Therefore, Yang fails to disclose this technical feature.” Again this argument is nothing more that general allegations. Applicant argues that Yang does not teach “configuring an application mid-end for the page program”. The examiner disagrees. Paragraph 0147 of the applications specification states, “the application mid-end can be configured to implement communication functions in the generated application, for data communication with external parties.”. In their argument applicant reiterates the examiners rejection stating “Yang states that “the application development tool may communicate with the backend 104 using the API 106” (Yang [0023]). Yang also states that “application 108… may also access the backend system 104 using the API 106” (Yang, [0020]).”. Therefore, according the paragraph 0147 of the applications specification the API of Yang performs the same function of the claimed mid-end. Nothing in the claimed limitations further define what the mid-end for the page program is to differentiate it from an API in Yang, therefore Yang teaches the claimed limitation.
Applicant further argues:
“Claim 10 further recites "integrating the page program and the application mid-end to obtain an application program." While Yang states that "[b]y integrating the application development tool with the entity and controller APIs, the application development tool may query the platform for API definitions and map the API properties to a widget" (Yang, [0047]). This disclosure concerns integration between an application development tool and APIs for the purpose of querying API definitions and mapping API properties to widgets. It does not disclose integrating a page program and an application mid-end to obtain an application program. Yang's generated result is described as an application UI or exported source code files, not an application program obtained by integrating a page program with an application mid-end. So, Yang fails to teach this technical feature.”” Again this argument is nothing more that general allegations. All that is claimed is “integrating the page program and the application mid-end to obtain an application program”. In the previous rejection, the examiner states that Yang teaches, the application development tool to generate computer code for the application and that the computer code is used by the tool to perform all of the steps necessary for creating a computer application including interpreting, compiling, assembling, linking and/or loading the computer code. API properties are mapped to the properties of the widgets (0027). Therefore, Yang teaches the claimed limitations.
Applicant argues:
“Claim 10 further recites that "the application mid-end is configured to push page data, update page data, summarize page data, or any combination thereof." Yang does not disclose this feature. Yang states that application 108 may use API 106 to access backend functionality, which "may include reading and writing data to databases 103" (Yang, [0026]). Yang also states that "a button widget can have a 'click' action mapped to it that will call an entity API to update data or a dropdown menu widget can display data received from an entity API" (Yang, [0038]). These disclosures relate to generic database read/write operations, a widget action calling an entity API to update data, or a dropdown widget displaying data received from an entity API. Whereas in claim 10, the application mid-end can be configured to implement communication functions, such as pushing page data, updating page data, which is different from the function of the entity API. Yang does not disclose page data, does not disclose an application mid-end, and does not disclose that the application mid-end is configured to push page data, update page data, summarize page data, or any combination thereof.” Again this argument is nothing more that general allegations. The claimed limitations broadly claims “wherein the application mid-end is configured to push data, update page data, summarize page data, or any combination therefore;”. There is no specific limitation defining exactly what these types of data are. Yang teaches a user can determine whether the selected widget should interact with the backend via entity APIs (mid-end) or if the widget selected at block 1 should interact with the backend platform via controller APIs (mid-end) (0032). Yang further teaches, entity properties are mapped to widget attributes. API properties such as, “Id”, “name”, “percentage” of the selected backend entity are mapped to correspond widget attributes The application development tool maps the selected API property to the associated widget attribute by editing the source code of the widget using pre-generated segments of code (0033-0036). Further as can be seen in figure 1, data is sent (pushed) from the platform database though an API to a widget to be displayed. In the above arguments the examiner states and explains why the mid-end is analogous to the API of Yang et al, therefore Yang teaches the claimed limitations.
The applicant then continues to further argue the same arguments which boil down to Yang does not teach a “page program” or a “mid-end”. The applicant points to different parts of Yang et al. in their argument but then just states this is different from a page or mid-end with out any further definition or support from the specification or claim regarding what a “page” or “mid-end” are. Just because Yang does not use the same terminology, does not mean it does not teach the claimed limitations. For these reasons and the reasons above the current rejections stand.
Conclusion
Applicant's amendment necessitated the new ground(s) of rejection presented in this Office action. Accordingly, THIS ACTION IS MADE FINAL. See MPEP § 706.07(a). Applicant is reminded of the extension of time policy as set forth in 37 CFR 1.136(a).
A shortened statutory period for reply to this final action is set to expire THREE MONTHS from the mailing date of this action. In the event a first reply is filed within TWO MONTHS of the mailing date of this final action and the advisory action is not mailed until after the end of the THREE-MONTH shortened statutory period, then the shortened statutory period will expire on the date the advisory action is mailed, and any nonprovisional extension fee (37 CFR 1.17(a)) pursuant to 37 CFR 1.136(a) will be calculated from the mailing date of the advisory action. In no event, however, will the statutory period for reply expire later than SIX MONTHS from the mailing date of this final action.
Any inquiry concerning this communication or earlier communications from the examiner should be directed to MARK A GOORAY whose telephone number is (571)270-7805. The examiner can normally be reached Monday - Friday 10:00am - 6:00pm.
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, Lewis Bullock can be reached at 571-272-3759. The fax phone number for the organization where this application or proceeding is assigned is 571-273-8300.
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.
/MARK A GOORAY/ Examiner, Art Unit 2199
/LEWIS A BULLOCK JR/ Supervisory Patent Examiner, Art Unit 2199
Prosecution Insights