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 .
This action is responsive to the Amendment filed on May 12, 2026. Claims 1 and 4 are amended. Claims 7 and 10 are cancelled. Claims 1-6, 8, 9, and 11-14 are pending in the case. Claims 1 and 4 are the independent claims.
This action is final.
Applicant’s Response
In the Amendment filed May 12, 2026, Applicant amended the claims and provided arguments in response to the rejection of the claims under 35 USC 103 in the previous office action.
Response to Argument/Amendment
Applicant’s amendment to the claims in response to the rejection of the claims under 35 USC 103 in the previous office action are acknowledged, and Applicant’s associated arguments have been fully considered. Applicant argues that “Atarashi completely fails to teach or suggest an object-oriented extension mechanism that dynamically inherits functions (such as events and APIs) to add new business logic to an existing component….Doney focuses on backend smart contract logic, providing no motivation to combine its teachings with a frontend UI component palette as in amended claim 1….Doney and Iborra are silent to the features of amended claim 1. Nothing in the cited portions of Atarashi…in any combination with Doney[]…and/or Iborra[]…discloses or suggests ‘wherein the registered extended component is configured to be selectable from the component palette and arrangeable on a design screen of the user interface platform development tool for visual software development, and wherein the extended component inherits all of properties, events, and application programming interfaces (APIs) of the selected basic component without change, and is limited to inheriting from only the single selected basic component to which the additional function is added’ as recited by amended claim 1….”
However, as cited in the previous office action, Atarashi is cited as teaching:
wherein the registered extended component is configured to be selectable from the component palette and arrangeable on a design screen of the user interface platform development tool for visual software development (e.g. paragraph 0048, Fig. 2, displaying layout editor 20 on screen of HMI development support apparatus, including registry component palette 47; paragraph 0049, user laying out components displayed on primitive component palette 46 and registry component palette 47 in layout edition window 45, so as to create a concerned display screen image; paragraph 0055, acquiring component XMLs corresponding to project, interpreting them, and registering them on the registry component palette; components displayed on the registry component palette are limited to those used for the selected project from all components registered on the component management table; paragraphs 0078-0081, describing Fig. 14-17, component registry window and process allowing edited component to be added in a component registry process; user clicking register component of layout menu 611 so as to register the image-edited component; user inputting component name for edited component and adds primitive components constituting the concerned component by the add button; receiving user’s input of registry “yes” button 625, generating component XML corresponding to added primitive components, adding it on the component management table, adding image layers on image management table and update times corresponding to added primitive components, and changing layout XML based on registry components, updating layout management table and update time; paragraph 0085, Fig. 19, confirming component has been updated in update confirmation window 72b; paragraph 0088-0089, receiving user’s input of pressed updated layout button 721, updating displays of layout management window 83 and registry component palette 87 as shown in Fig. 21)
Moreover, with respect to similar limitations previously recited in cancelled claims 7 and 10, Doney is cited as teaching:
wherein the extended component inherits all of properties, events, and application programming interfaces (APIs) of the selected basic component without change, and is limited to inheriting from only the single selected basic component to which the additional function is added (e.g. paragraph 0068, digital asset templates defined from logic blocks that declare supported interfaces, properties, functions, events, dependencies, triggers, and requisite data in/outputs; paragraph 0073, class template expressed as data structure specifying behaviors for the class including permissions, interfaces, functions, properties, events, errors, dependencies, etc.; paragraph 0087, class templates stored in class registry defined by behaviors, properties, functions, etc. of objects associated within the class; triggers, functions, etc., of class configuration; paragraphs 0158-0159, creation of child class through inheritance; child class adding new logic/overriding parent's behavior; child object created through inheritance acquires all properties and behaviors of the parent object from which it is derived; the child class inherits from the parent class, and may optionally further extend the behavior of the parent by adding additional properties/logic and/or overriding parent behavior by specifying new mapping of functions or properties; initially checking for extensions/overrides and then defaulting to parent class template; i.e. where additional functionality is added to a single inherited behavior of the parent, the child class will inherit only one basic component to which the additional function is added (along with other basic components, which are inherited without modification, such that they are not basic components to which the additional function is added); in at least some embodiments, where no extension/override is defined, the child class inherits all of the permissions, interfaces, functions, properties, events, errors, dependencies, etc. of the parent class without change; moreover, in some embodiments, the extension/overriding appears to be described as being implemented by adding entirely new properties/logic, etc., such that the original permissions, functions, etc., are first inherited without change, and then additional properties and behaviors are added after this inheritance has occurred).
Regarding Applicant’s argument that Atarashi fails to teach or suggest and object-oriented extension mechanism that dynamically inherits functions to add new business logic to an existing component, Examiner notes that it is not necessary for Atarashi to teach these concepts because Doney was already cited as teaching the relevant claim limitations in the previous office action, i.e.:
generating (i.e. by the page generation computing unit) a page for an extended component by a development tool for software development (e.g. paragraph 0064, low-code development platform; paragraph 0087, enabling users to create and extend classes without needing to generate new code, by inheriting behaviors from other class templates; paragraph 0137, Fig. 4b, illustrating GUI for class creation operable to create individual items/objects; GUI 280 for class creation includes selectable logic fields, select parent class button 286, etc.; paragraph 0158, deriving new class from existing class such as super class or base class; paragraph 0159, child class extending behavior of parent; i.e. development platform generating a GUI screen/page for creating a child class which inherits information from a parent class, and thereby extends the parent class/component);
receiving (i.e. by the component extension computing unit) by user input on a work screen of the development tool a selection button for a single selection of one of basic components (e.g. paragraph 0137, Fig. 4b, selection of parent class button 286 operable to cause the item to inherit class behaviors of the parent class selected by the parent class button 286; paragraph 0159, class inheriting from another upon reference of the parent class template during class creation; i.e. receiving a user selection of a base/super class upon which the current child class is to be based);
receiving (i.e. by the component extension computing unit) information of an additional function (e.g. paragraph 0087, users defining behaviors, etc.; paragraph 0137, Fig. 4b, selectable logic fields 284; paragraph 0142, inheriting logic/attribute from another class but overriding, such as implementing differently certain functions or properties; paragraph 0159, child class adding additional properties and new logic to the child class; child class overriding parent’s behavior by specifying new mapping of functions or properties; i.e. a user providing additional logic/behavior/functionality for the child class/component, and/or overriding/altering existing functionality);
generating (i.e. by the component extension computing unit) an extended component that inherits all functions of a selected basic component and to which the additional function is granted based on the information of the additional function entered (e.g. paragraph 0087, users defining behaviors, etc.; paragraph 0137, creating individual item/object via GUI; item inheriting behaviors of selected parent class; paragraph 0158, inheritance is mechanism of basing object/class upon another object/class, retaining similar implementation; child object created through inheritance acquires all properties and behaviors of the parent object from which it is derived; paragraphs 0158-0159, creation of child class through inheritance; child class adding new logic/overriding parent’s behavior; i.e. generating/creating the child class/component which inherits the functions of the parent, and which also includes new/additional functions/behaviors)
Therefore, the combination of Doney and Atarashi does appear to teach the limitations disputed in Applicant’s arguments. With respect to Applicant’s argument that there is no motivation to combine the cited references, Examiner notes that Atarashi was cited as providing explicit motivation, noting benefits which could be realized by utilizing its teachings, including significantly enhancing operational performance of HMI development tools, reducing implementation time in HMI development, and reducing HMI implementation cost as described in Atarashi (paragraph 0093). There does not appear to be anything in the teachings of Doney or Atarashi which would amount to any teaching away from their combination. Moreover, although Doney may be particularly concerned with backend components and Atarashi may be concerned with frontend components (as is apparently argued by Applicant), Examiner notes that both of these references are both more generally concerned with software development, including defining objects/components for use in software (as cited with regard to Doney; Examiner notes that at least Fig. 7 of Atarashi also indicates use of inheritance structures between user-defined components), and are therefore both analogous to the claimed invention because they are both from the same field of endeavor, or are at least both reasonably pertinent, as discussed in MPEP 2141.01(a).
In addition, Applicant’s arguments are moot in view of the new grounds of rejection provided below.
Claim Rejections – 35 USC § 103
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 set forth in Graham v. John Deere Co., 383 U.S. 1, 148 USPQ 459 (1966), that are applied 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 under pre-AIA 35 U.S.C. 103(a), the examiner presumes that the subject matter of the various claims was commonly owned at the time any inventions covered therein were made absent any evidence to the contrary. Applicant is advised of the obligation under 37 CFR 1.56 to point out the inventor and invention dates of each claim that was not commonly owned at the time a later invention was made in order for the examiner to consider the applicability of pre-AIA 35 U.S.C. 103(c) and potential pre-AIA 35 U.S.C. 102€, (f) or (g) prior art under pre-AIA 35 U.S.C. 103(a).
Claims 1, 3, 4, 6, 13, and 14 are rejected under 35 U.S.C. 103 as being unpatentable over Doney (US 20230359604 A1) in view of Iborra et al. (US 7555742 B2), further in view of Atarashi et al. (US 20080040677 A1), further in view of Lung et al. (US 6751793 B1).
With respect to claims 1 and 4, Doney teaches an extended component generation device in a user interface platform development system, comprising a page generation computing unit, a component extension computing unit, and a registration computing unit, each configured to perform a respective method step; and a non-transitory computer-readable medium storing computer executable instructions for performing an extended component generation method when executed by a computer (e.g. paragraph 0224, invention embodied as computer system; paragraph 0227, computing devices of computer system; paragraph 0228, computing devices including processor, system memory, storage devices, etc.; paragraph 0229, processors processing instructions for execution; paragraph 0233, computer readable media/instructions; paragraph 0249, described functions accomplished via processors executing instructions stored in tangible computer readable memories), the method comprising:
generating (i.e. by the page generation computing unit) a page for an extended component by a development tool for software development (e.g. paragraph 0064, low-code development platform; paragraph 0087, enabling users to create and extend classes without needing to generate new code, by inheriting behaviors from other class templates; paragraph 0137, Fig. 4b, illustrating GUI for class creation operable to create individual items/objects; GUI 280 for class creation includes selectable logic fields, select parent class button 286, etc.; paragraph 0158, deriving new class from existing class such as super class or base class; paragraph 0159, child class extending behavior of parent; i.e. development platform generating a GUI screen/page for creating a child class which inherits information from a parent class, and thereby extends the parent class/component);
receiving (i.e. by the component extension computing unit) by user input on a work screen of the development tool a selection button for a single selection of one of basic components (e.g. paragraph 0137, Fig. 4b, selection of parent class button 286 operable to cause the item to inherit class behaviors of the parent class selected by the parent class button 286; paragraph 0159, class inheriting from another upon reference of the parent class template during class creation; i.e. receiving a user selection of a base/super class upon which the current child class is to be based);
receiving (i.e. by the component extension computing unit) information of an additional function (e.g. paragraph 0087, users defining behaviors, etc.; paragraph 0137, Fig. 4b, selectable logic fields 284; paragraph 0142, inheriting logic/attribute from another class but overriding, such as implementing differently certain functions or properties; paragraph 0159, child class adding additional properties and new logic to the child class; child class overriding parent’s behavior by specifying new mapping of functions or properties; i.e. a user providing additional logic/behavior/functionality for the child class/component, and/or overriding/altering existing functionality);
generating (i.e. by the component extension computing unit) an extended component that inherits all functions of a selected basic component and to which the additional function is granted based on the information of the additional function entered (e.g. paragraph 0087, users defining behaviors, etc.; paragraph 0137, creating individual item/object via GUI; item inheriting behaviors of selected parent class; paragraph 0158, inheritance is mechanism of basing object/class upon another object/class, retaining similar implementation; child object created through inheritance acquires all properties and behaviors of the parent object from which it is derived; paragraphs 0158-0159, creation of child class through inheritance; child class adding new logic/overriding parent’s behavior; i.e. generating/creating the child class/component which inherits the functions of the parent, and which also includes new/additional functions/behaviors); and
registering (i.e. by the registration computing unit) the extended component with the development tool (e.g. paragraph 0087, class registry records all user defined classes; paragraph 0142, inheritance data stored in item registry and class registry; i.e. adding the child class (as defined by the user) to a corresponding registry); and
wherein the extended component inherits all of properties, events, and application programming interfaces (APIs) of the selected basic component without change, and is limited to inheriting from only the single selected basic component to which the additional function is added (e.g. paragraph 0068, digital asset templates defined from logic blocks that declare supported interfaces, properties, functions, events, dependencies, triggers, and requisite data in/outputs; paragraph 0073, class template expressed as data structure specifying behaviors for the class including permissions, interfaces, functions, properties, events, errors, dependencies, etc.; paragraph 0087, class templates stored in class registry defined by behaviors, properties, functions, etc. of objects associated within the class; triggers, functions, etc., of class configuration; paragraphs 0158-0159, creation of child class through inheritance; child class adding new logic/overriding parent's behavior; child object created through inheritance acquires all properties and behaviors of the parent object from which it is derived; the child class inherits from the parent class, and may optionally further extend the behavior of the parent by adding additional properties/logic and/or overriding parent behavior by specifying new mapping of functions or properties; initially checking for extensions/overrides and then defaulting to parent class template; i.e. where additional functionality is added to a single inherited behavior of the parent, the child class will inherit only one basic component to which the additional function is added (along with other basic components, which are inherited without modification, such that they are not basic components to which the additional function is added); in at least some embodiments, where no extension/override is defined, the child class inherits all of the permissions, interfaces, functions, properties, events, errors, dependencies, etc. of the parent class without change; moreover, in some embodiments, the extension/overriding appears to be described as being implemented by adding entirely new properties/logic, etc., such that the original permissions, functions, etc., are first inherited without change, and then additional properties and behaviors are added after this inheritance has occurred).
Doney does not explicitly disclose that the development tool is a user interface platform development tool, that the information of the additional function is received on a popup window of the user interface platform development tool, or that the extended component is based on the information of the additional function entered through the popup window.
However, Iborra teaches that the development tool is a user interface platform development tool, that the information of the additional function is received on a popup window of the user interface platform development tool, and that the extended component is based on the information of the additional function entered through the popup window (e.g. col. 6 lines 35-42, object in the form of attributes and services which perform whatever function the service is designed to do; services defined for object carry out processing appropriate to the existence and meaning of the object; col. 8 line 23-40, specifying patterns for user interface of software application, generating software application based on formal specification, the generated software application including instructions for handling the user interface in accordance with patterns specified in presentation model; col. 25 lines 8-21, maintaining information on relationships between classes, including inheritance relationships; storing names of parent class and child class, whether specialization is temporary or permanent, formula as specialization condition, events to activate/deactivate child role, etc.; col. 20 lines 47-52, presentation model is set of predefined concepts used to describe user interface requisites; col. 27 lines 30-39, for each class, there are set of constant, variable, or derived attributes, including a set of services; for complex class such as one defined using inheritance, object model provides particular characteristics specified for the corresponding complex class; col. 35 lines 5-17, Figs. 9A-C, providing dialog boxes for class creation, definition, setting of relationships between classes, etc.; inheritance relationships created using dialog box similar to Fig. 9A; i.e. the extended class/component, such as a child class/subclass which inherits properties such as services/functions from a parent class (therefore extending the parent), may be defined by a user via a dialog box/popup window of a user interface platform development tool, including by the user setting the attributes, such as functions/services, specializations, etc. via the dialog box/popup window).
Accordingly, it would have been obvious to one of ordinary skill in the art before the effective filing date of the invention having the teachings of Doney and Iborra in front of him to have modified the teachings of Doney (directed to creating and managing user configurable objects and functions), to incorporate the teachings of Iborra (directed to an automatic software production system) to include the capability to implement the system (i.e. of Doney) as a user interface platform development tool, in which the user may enter the information of the additional function via a popup window/dialog box of the user interface platform development tool, such that the extended component (such as a child class/subclass) is based on the information of the additional function entered through the popup window/dialog box (as taught by Iborra). One of ordinary skill would have been motivated to perform such a modification in order to automatically generate a complete, robust software application based on validated formal specification including user interface code and error handling code as described in Iborra (abstract).
Doney and Iborra do not explicitly disclose registering the extended component to a component palette, wherein the registered extended component is configured to be selectable from the component palette and arrangeable on a design screen of the user interface platform development tool for visual software development. However, assuming arguendo that Doney does not explicitly disclose components which are visual components which make up a display screen, Atarashi teaches components which are visual components which make up a display screen, and further teaches registering the extended component to a component palette, wherein the registered extended component is configured to be selectable from the component palette and arrangeable on a design screen of the user interface platform development tool for visual software development (e.g. paragraph 0048, Fig. 2, displaying layout editor 20 on screen of HMI development support apparatus, including registry component palette 47; paragraph 0049, user laying out components displayed on primitive component palette 46 and registry component palette 47 in layout edition window 45, so as to create a concerned display screen image; paragraph 0055, acquiring component XMLs corresponding to project, interpreting them, and registering them on the registry component palette; components displayed on the registry component palette are limited to those used for the selected project from all components registered on the component management table; paragraphs 0078-0081, describing Fig. 14-17, component registry window and process allowing edited component to be added in a component registry process; user clicking register component of layout menu 611 so as to register the image-edited component; user inputting component name for edited component and adds primitive components constituting the concerned component by the add button; receiving user’s input of registry “yes” button 625, generating component XML corresponding to added primitive components, adding it on the component management table, adding image layers on image management table and update times corresponding to added primitive components, and changing layout XML based on registry components, updating layout management table and update time; paragraph 0085, Fig. 19, confirming component has been updated in update confirmation window 72b; paragraph 0088-0089, receiving user’s input of pressed updated layout button 721, updating displays of layout management window 83 and registry component palette 87 as shown in Fig. 21).
Accordingly, it would have been obvious to one of ordinary skill in the art before the effective filing date of the invention having the teachings of Doney, Iborra, and Atarashi in front of him to have modified the teachings of Doney (directed to creating and managing user configurable objects and functions) and Iborra (directed to an automatic software production system), to incorporate the teachings of Atarashi (directed to HMI development support) to include the capability to implement the components (i.e. objects/classes of Doney) as including visual components which make up a display screen, where the registration of the visual components includes registration to a component palette from which the components are selectable and arrangeable on design screens of the user interface platform development tool. One of ordinary skill would have been motivated to perform such a modification in order to significantly enhance operational performance of HMI development tools, reduce implementation time in HMI development, and reduce HMI implementation cost as described in Atarashi (paragraph 0093).
Assuming arguendo that Doney, Iborra, and Atarashi do not explicitly disclose wherein the extended component inherits all of properties, events, and application programming interfaces (APIs) of the selected basic component without change, and is limited to inheriting from only the single selected basic component to which the additional function is added, Lung teaches wherein the extended component inherits all of properties, events, and application programming interfaces (APIs) of the selected basic component without change, and is limited to inheriting from only the single selected basic component to which the additional function is added (e.g. col. 7 lines 24-50, describing Figs. 1 and 2, in object oriented languages, class used to implement abstract data type containing all functions and data appropriate for the type; a member is used to represent a property or an operation of a class; data member is a value stored directly with class object; objects of derived classes composed by concatenating the members of the base classes and members of the derived class itself; single inheritance refers to a class which is derived from one and only one base class; i.e. as shown in Figs. 1 and 2, all members (e.g. properties, events, interfaces, etc.) of a base class are inherited by a derived class (without change, as shown), and in an single inheritance implementation the derived class is limited to inheriting from only a single base class, though the derived class itself may add additional/new members/functions; therefore, class manager 130 single inherits from only class employee 120, including all of its members while also adding additional members, and class director 140 single inherits from only class manager 130, including all of its members while also adding additional members (i.e. inheriting original members, including properties, functions, etc. of the base class without change while adding new members, including at least one additional function which is specific to the derived class)).
Accordingly, it would have been obvious to one of ordinary skill in the art before the effective filing date of the invention having the teachings of Doney, Iborra, Atarashi, and Lung in front of him to have modified the teachings of Doney (directed to creating and managing user configurable objects and functions), Atarashi (directed to HMI development support), and Iborra (directed to an automatic software production system), to incorporate the teachings of Lung (directed to hierarchical structures in programming languages, i.e. such as inheritance structures for use in software development) to include the capability to implement the components (i.e. objects/classes of Doney) using single inheritance, such that each derived object/class is limited to inheriting from only a single base/parent class, including inheriting the members of those classes (i.e. properties, events, functions, behavior, interfaces, etc., as taught by Doney and Lung) unchanged. One of ordinary skill would have been motivated to perform such a modification in order to allow for the growth of hierarchical structures with new base classes while preserving release-to-release binary compatibility as described in Lung (col. 1 lines 11-16).
With respect to claims 3 and 6, Doney in view of Iborra, further in view of Atarashi, further in view of Lung teaches all of the limitations of claims 1 and 4 as previously discussed, and Doney further teaches wherein the basic component is a component belonging to at least one type of Forms, Grid, Container, Navigation, Chart, Frame, HTML5, and others (e.g. paragraph 0068, digital asset templates defined from logic blocks that declare supported interfaces, properties, functions, events, dependencies, triggers, and requisite data in/outputs; paragraph 0073, class template expressed as data structure specifying behaviors for the class including permissions, interfaces, functions, properties, events, errors, dependencies, etc.; paragraph 0087, class templates stored in class registry defined by behaviors, properties, functions, etc. of objects associated within the class; triggers, functions, etc., of class configuration; Examiner notes that this claim is interpreted to include a wide variety of different types component, based on the recitation of “and others” within the listing of possible component types).
With respect to claim 13, Doney in view of Iborra, further in view of Atarashi, further in view of Lung teaches all of the limitations of claim 1 as previously discussed, and Doney further teaches wherein the additional function extends functions of a component (e.g. paragraph 0087, users defining behaviors, etc.; paragraph 0137, Fig. 4b, selectable logic fields 284; paragraph 0142, inheriting logic/attribute from another class but overriding, such as implementing differently certain functions or properties; paragraph 0159, child class adding additional properties and new logic to the child class; child class overriding parent’s behavior by specifying new mapping of functions or properties; i.e. a user providing additional logic/behavior/functionality for the child class/component, and/or overriding/altering existing functionality).
Atarashi further teaches that the component is tailored to characteristics of a project and included in a visual interface of a system (e.g. paragraph 0049, user laying out components displayed in primitive component palette and registry component palette so as to crate display screen image, such as for in-car navigation system; paragraph 0052-0055, Figs. 2-4, user selecting project in menu bar 41, project menu 411 displayed, user inputting read project, acquiring appropriate project ID and name tag of project XML corresponding to the project ID, acquiring component XMLs corresponding to the project ID of selected project, interpreting them and registering them on the registry component palette; components displayed on the registry component palette are limited to those used for the selected project; paragraph 0075, graphically editing display frame; user may modify image data of registry components and add new image data thereto; paragraph 0077, registering image-edited component; paragraph 0080, user inputting component name for image-edited component and adding primitive components constituting the concerned component; paragraph 0081, registering the component; i.e. the component is a visual component which is used in the design of a graphical user interface of a system, and may be associated with a corresponding project and edited by the user such that it is tailored to characteristics of the project).
Accordingly, it would have been obvious to one of ordinary skill in the art before the effective filing date of the invention having the teachings of Doney, Iborra, Lung, and Atarashi in front of him to have modified the teachings of Doney (directed to creating and managing user configurable objects and functions), Lung (directed to hierarchical structures in programming languages, i.e. such as inheritance structures for use in software development), and Iborra (directed to an automatic software production system), to incorporate the teachings of Atarashi (directed to HMI development support) to include the capability to implement the components (i.e. objects/classes of Doney) as including visual components which make up a display screen, where the components may be further edited by the user and associated with a particular project, such that the component is tailored to characteristics of the project an included in a visual interface of a system. One of ordinary skill would have been motivated to perform such a modification in order to significantly enhance operational performance of HMI development tools, reduce implementation time in HMI development, and reduce HMI implementation cost as described in Atarashi (paragraph 0093).
With respect to claim 14, Doney in view of Iborra, further in view of Atarashi, further in view of Lung teaches all of the limitations of claim 1 as previously discussed, and Doney, Iborra, and Atarashi each further teach wherein a structure of the extended component is generated without manual coding or automatically through popup window input (e.g. Doney paragraph 0064, low-code development platform; paragraph 0087, enabling users to create and extend classes without needing to generate new code; Iborra col. 7 line 46-col. 8 line 4, capturing system requirements graphically (through GUI) converting models so created into formal specification; providing translator to automatically generate complete, robust software application/application code based on validated formal specification, freeing the developer from having to manually produce source code; Atarashi paragraph 0081, user inputting to register the component, and image editor/component registry unit generates component XML corresponding to the added primitive components of the image-edited component and adds it on the component management table as shown in Fig. 16).
Accordingly, it would have been obvious to one of ordinary skill in the art before the effective filing date of the invention having the teachings of Doney, Iborra, Lung, and Atarashi in front of him to have modified the teachings of Doney (directed to creating and managing user configurable objects and functions) and Lung (directed to hierarchical structures in programming languages, i.e. such as inheritance structures for use in software development) to incorporate the teachings of Iborra (directed to an automatic software production system) and Atarashi (directed to HMI development support) to include the capability to generate the structure of the extended component without manual coding. One of ordinary skill would have been motivated to perform such a modification in order to automatically generate a complete, robust software application based on validated formal specification including user interface code and error handling code as described in Iborra (abstract), and in order to significantly enhance operational performance of HMI development tools, reduce implementation time in HMI development, and reduce HMI implementation cost as described in Atarashi (paragraph 0093).
Claims 2, 5, 8, 9, 11, and 12 are rejected under 35 U.S.C. 103 as being unpatentable over Doney in view of Iborra, further in view of Atarashi, further in view of Lung, further in view of Kawabe et al. (US 20100217839 A1).
With respect to claims 2 and 5, Doney in view of Iborra, further in view of Atarashi, further in view of Lung teaches all of the limitations of claims 1 and 4 as previously discussed. Doney does not explicitly disclose wherein the page for the extended component is a page having a design tab and a source tab. However, Kawabe teaches wherein the page for the extended component is a page having a design tab and a source tab (e.g. paragraph 0093, Fig. 5, development tool for software developer, window with tools; component list 203 for operating program by pasting on window in design and code creation window 205; design and code creation window 205 (source file editor) for designing program and develop source code; paragraph 0104, Fig. 6, showing screen shots of design and code creation window 205; tabs 2051, 2052, and 2053 each showing tab displaying source code of each file; paragraph 0217, Fig. 6, software developer arranging component of component list 203 on tab 2050 of design and code creation window; i.e. the design and creation window 205 within the software developer GUI can include at least a tab for designing and arranging components, and a tab for displaying/editing source code).
Accordingly, it would have been obvious to one of ordinary skill in the art before the effective filing date of the invention having the teachings of Doney, Iborra, Atarashi, Lung, and Kawabe in front of him to have modified the teachings of Doney (directed to creating and managing user configurable objects and functions), Atarashi (directed to HMI development support), Lung (directed to hierarchical structures in programming languages, i.e. such as inheritance structures for use in software development), and Iborra (directed to an automatic software production system), to incorporate the teachings of Kawabe (directed to a develop system and method) to include, within the page/UI screen for the extended component, a design tab and a source tab. One of ordinary skill would have been motivated to perform such a modification in order to reduce human-induced cost in software development as described in Kawabe (paragraph 0036).
With respect to claims 8 and 11, Doney in view of Iborra, further in view of Atarashi, further in view of Lung, further in view of Kawabe teaches all of the limitations of claims 2 and 5 as previously discussed, and Iborra further teaches a design screen showing properties of the extended component and showing a user-defined component (e.g. col. 25 lines 8-21, maintaining information on relationships between classes, including inheritance relationships; storing names of parent class and child class, whether specialization is temporary or permanent, formula as specialization condition, events to activate/deactivate child role, etc.; col. 27 lines 30-39, for each class, there are set of constant, variable, or derived attributes, including a set of services; for complex class such as one defined using inheritance, object model provides particular characteristics specified for the corresponding complex class; col. 35 lines 13-17, Fig. 9C showing dialog box to modify properties of aggregation relationship between classes; inheritance and aggregation relationships created using dialog box similar to Fig. 9A; col. 36 lines 58-61, Fig. 10, showing dialog to create relationships between classes which graphically shows the relationships and all the properties of those relationships; col. 38 lines 30-47, Figs. 11A-B, dialog boxes used to define attributes for class and their properties, and formulas for derivation of values of attributes of classes; col. 39 lines 1-2, Fig. 12, dialog to define services of class with their arguments; i.e. various design screens are provided for displaying properties, attributes, services/functions, etc. of a class, including a child class/subclass which inherits and potentially extends a parent class, where these classes and subclasses are defined by the user, via the interface).
Accordingly, it would have been obvious to one of ordinary skill in the art before the effective filing date of the invention having the teachings of Doney, Atarashi, Lung, and Iborra in front of him to have modified the teachings of Doney (directed to creating and managing user configurable objects and functions), Lung (directed to hierarchical structures in programming languages, i.e. such as inheritance structures for use in software development), and Atarashi (directed to HMI development support), to incorporate the teachings of Iborra (directed to an automatic software production system) to include the capability to provide a design screen showing properties of extended components (such as a class which is extended by a child class/subclass) and further showing user-defined components (as taught by Iborra). One of ordinary skill would have been motivated to perform such a modification in order to automatically generate a complete, robust software application based on validated formal specification including user interface code and error handling code as described in Iborra (abstract).
Kawabe further teaches that the design tab activates a design tab screen and that the design screen can be a design tab screen (e.g. paragraph 0093, Fig. 5, development tool for software developer, window with tools; component list 203 for operating program by pasting on window in design and code creation window 205; design and code creation window 205 (source file editor) for designing program and develop source code; paragraph 0217, Fig. 6, software developer arranging component of component list 203 on tab 2050 of design and code creation window; i.e. the design and creation window 205 within the software developer GUI can include at least a tab for designing and arranging components).
Accordingly, it would have been obvious to one of ordinary skill in the art before the effective filing date of the invention having the teachings of Doney, Iborra, Atarashi, Lung, and Kawabe in front of him to have modified the teachings of Doney (directed to creating and managing user configurable objects and functions), Atarashi (directed to HMI development support), Lung (directed to hierarchical structures in programming languages, i.e. such as inheritance structures for use in software development), and Iborra (directed to an automatic software production system), to incorporate the teachings of Kawabe (directed to a develop system and method) to include, within the page/UI screen for the extended component, a design tab for displaying screens for designing components. One of ordinary skill would have been motivated to perform such a modification in order to reduce human-induced cost in software development as described in Kawabe (paragraph 0036).
With respect to claims 9 and 12, Doney in view of Iborra, further in view of Atarashi, further in view of Lung, further in view of Kawabe teaches all of the limitations of claims 2 and 5 as previously discussed, and Iborra further teaches wherein the design screen comprises an area where the selected basic component is displayed and modifiable (e.g. col. 25 lines 8-21, maintaining information on relationships between classes, including inheritance relationships; storing names of parent class and child class, whether specialization is temporary or permanent, formula as specialization condition, events to activate/deactivate child role, etc.; col. 27 lines 30-39, for each class, there are set of constant, variable, or derived attributes, including a set of services; for complex class such as one defined using inheritance, object model provides particular characteristics specified for the corresponding complex class; col. 35 lines 13-17, Fig. 9C showing dialog box to modify properties of aggregation relationship between classes; inheritance and aggregation relationships created using dialog box similar to Fig. 9A; col. 36 lines 58-61, Fig. 10, showing dialog to create relationships between classes which graphically shows the relationships and all the properties of those relationships; col. 38 lines 30-47, Figs. 11A-B, dialog boxes used to define attributes for class and their properties, and formulas for derivation of values of attributes of classes; col. 39 lines 1-2, Fig. 12, dialog to define services of class with their arguments; i.e. various design screens are provided for displaying information about classes, including parent classes and child classes/subclasses, and for editing/modifying the classes, such that the design screens include at least one area where a selected basic component, such as a parent class, is displayed and modifiable).
Accordingly, it would have been obvious to one of ordinary skill in the art before the effective filing date of the invention having the teachings of Doney, Atarashi, Lung, and Iborra in front of him to have modified the teachings of Doney (directed to creating and managing user configurable objects and functions), Lung (directed to hierarchical structures in programming languages, i.e. such as inheritance structures for use in software development), and Atarashi (directed to HMI development support), to incorporate the teachings of Iborra (directed to an automatic software production system) to include the capability to provide a design screen showing properties of extended components (such as a class which is extended by a child class/subclass) and further showing user-defined components (as taught by Iborra). One of ordinary skill would have been motivated to perform such a modification in order to automatically generate a complete, robust software application based on validated formal specification including user interface code and error handling code as described in Iborra (abstract).
Kawabe further teaches that the design screen can be a design tab screen (e.g. paragraph 0093, Fig. 5, development tool for software developer, window with tools; component list 203 for operating program by pasting on window in design and code creation window 205; design and code creation window 205 (source file editor) for designing program and develop source code; paragraph 0217, Fig. 6, software developer arranging component of component list 203 on tab 2050 of design and code creation window; i.e. the design and creation window 205 within the software developer GUI can include at least a tab for designing and arranging components).
Accordingly, it would have been obvious to one of ordinary skill in the art before the effective filing date of the invention having the teachings of Doney, Iborra, Atarashi, Lung, and Kawabe in front of him to have modified the teachings of Doney (directed to creating and managing user configurable objects and functions), Atarashi (directed to HMI development support), Lung (directed to hierarchical structures in programming languages, i.e. such as inheritance structures for use in software development), and Iborra (directed to an automatic software production system), to incorporate the teachings of Kawabe (directed to a develop system and method) to include, within the page/UI screen for the extended component, a design tab for displaying screens for designing components. One of ordinary skill would have been motivated to perform such a modification in order to reduce human-induced cost in software development as described in Kawabe (paragraph 0036).
It is noted that any citation to specific pages, columns, lines, or figures in the prior art references and any interpretation of the references should not be considered to be limiting in any way. “The use of patents as references is not limited to what the patentees describe as their own inventions or to the problems with which they are concerned. They are part of the literature of the art, relevant for all they contain,” 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 (GCPA 1968)). Further, a reference may be relied upon for all that it would have reasonably suggested to one having ordinary skill the art, including nonpreferred embodiments. Merck & Co, v. Biocraft Laboratories, 874 F.2d 804, 10 USPQ2d 1843 (Fed. Cir.), cert, denied, 493 U.S. 975 (1989). See also Upsher-Smith Labs. v. Pamlab, LLC, 412 F,3d 1319, 1323, 75 USPQ2d 1213, 1215 (Fed. Cir, 2005): Celeritas Technologies Ltd. v. Rockwell International Corp., 150 F.3d 1354, 1361, 47 USPQ2d 1516, 1522-23 (Fed. Cir. 1998).
Conclusion
The prior art made of record and not relied upon is considered pertinent to applicant’s disclosure.
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 JEREMY L STANLEY whose telephone number is (469)295-9105. The examiner can normally be reached on Monday-Friday from 9:00 AM to 5:00 PM CST.
If attempts to reach the examiner by telephone are unsuccessful, the examiner’s supervisor, Abdullah Al Kawsar, can be reached at telephone number (571) 270-3169. 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 Patent Center and the Private Patent Application Information Retrieval (PAIR) system. Status information for published applications may be obtained from Patent Center or Private PAIR. Status information for unpublished applications is available through Patent Center and Private PAIR for authorized users only. Should you have questions about access to the Private PAIR system, contact the Electronic Business Center (EBC) at 866-217-9197 (toll-free).
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.
/JEREMY L STANLEY/
Primary Examiner, Art Unit 2127
Prosecution Insights