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 Request for Continued Examination filed on February 25, 2026 and Amendment filed on January 29, 2026. Claims 1 and 4 are amended. Claims 13 and 14 are new. Claims 1-14 are pending in the case. Claims 1 and 4 are the independent claims.
This action is non-final.
Continued Examination Under 37 CFR 1.114
A request for continued examination under 37 CFR 1.114, including the fee set forth in 37 CFR 1.17(e), was filed in this application after final rejection. Since this application is eligible for continued examination under 37 CFR 1.114, and the fee set forth in 37 CFR 1.17(e) has been timely paid, the finality of the previous Office action has been withdrawn pursuant to 37 CFR 1.114. Applicant's submission filed on January 29, 2026 has been entered.
Applicant’s Response
In the Amendment filed January 29, 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 nothing in Doney discloses or suggests “registering the extended component to a component palette of the user interface platform development tool, 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,” as recited in the amended independent claims, and that Doney and Iborra fail to teach or suggest these features of the amended independent claims. This argument is persuasive. Therefore, the rejections are withdrawn.
Applicant additionally argues that “the class creation and inheritance of Doney is not directed to a component….a person of skill in the art would not construe class as described by Doney as corresponding to a component as recited by claim. The Applicant’s originally filed specification, at page 8, lines 16-19 states that ‘[c]omponents are basic files that make up a screen of a business system and can be used to develop Pages, Project UDCs, MSA UDCs, and TTCs. All screens in the business system can be composed of structured component to support efficient operation that can be reused anywhere.’ Doney is therefore directed towards the logic behind smart contracts while claim 1 is directed towards visual components.” It is not clear whether Applicant’s argument is that the quoted portions of the specification provide an explicit definition for the term “component,” or not. To the extent that Applicant does not intend to explicitly require the term component to be interpreted according to the quoted portions of the specification, Examiner notes that the claims as actually recited do not appear to explicitly require that the recited components be “basic files that make up a screen of a business system….” as argued by Applicant. Although the claims are interpreted in light of the specification, limitations from the specification are not read into the claims. See In re Van Geuns, 988 F.2d 1181, 26 USPQ2d 1057 (Fed. Cir. 1993). In this instance, one or ordinary skill in the art would understand the term “component,” used in the context of software development and including the capability to inherit functions from other components, as recited in the claims, as generally including classes, objects, and related concepts which are common to object-oriented software development regardless of whether the software object in question provides user interface functions, smart contract functions, or other functions. Alternatively, to the extent that Applicant’s arguments do intend to explicitly require/define the term component to be interpreted according to the quoted portions of the specification, Applicant’s argument is moot in view of the new grounds of rejection provided below.
New grounds of rejection are 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, 7, 10, 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).
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).
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).
With respect to claims 3 and 6, Doney in view of Iborra, further in view of Atarashi 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 claims 7 and 10, Doney in view of Iborra, further in view of Atarashi teaches all of the limitations of claims 1 and 4 as previously discussed, and Doney further teaches wherein the extended component inherits all of the properties, the events, and the APIs of the selected basic component without change (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; paragraph 0158, creation of child class through inheritance; child object created through inheritance acquires all properties and behaviors of the parent object from which it is derived; paragraph 0159, indicating that 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. 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).
With respect to claim 13, Doney in view of Iborra, further in view of Atarashi 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, 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 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 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, and Atarashi 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) 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 Kawabe et al. (US 20100217839 A1).
With respect to claims 2 and 5, Doney in view of Iborra, further in view of Atarashi 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, 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), 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 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, and Iborra in front of him to have modified the teachings of Doney (directed to creating and managing user configurable objects and functions) 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, 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) 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 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, and Iborra in front of him to have modified the teachings of Doney (directed to creating and managing user configurable objects and functions) 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, 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), 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.
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