DETAILED ACTION
Status of Claims
This action is in reply to the communication filed on 10/20/2025.
Claims 1, 4-6, 8, 11-13, 15, and 18-20 have been amended.
Claims 1-20 are currently pending and have been examined.
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 .
Response to Arguments
Applicant's amendments and arguments filed 10/20/2025 with respect to the rejections under 35 USC § 101 have overcome the issues identified in the prior Office Action; the rejections under 35 USC § 101 have accordingly been withdrawn.
Applicant’s arguments filed 10/20/2025 with respect to the rejections under 35 USC § 102/103 have been considered but are moot in view of the new grounds of rejection.
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.
Claims 1-4, 8-11, and 15-18 are rejected under 35 U.S.C. 103 as being unpatentable over Ranganathan et al. (US 2012/0233590 A1) in view of Unterdechler et al. (“Identifying repeating patterns in IEC 61499 systems using Feature-Based embeddings”, 09/06/2022).
Claims 1, 8, and 15:
Ranganathan discloses the limitations as shown in the following rejections:
A computer-implemented method for managing application architectures, the method comprising: receiving, by a processor, application data associated with an application architecture (flow pattern), wherein the application architecture includes at least one application (application/program flow) in an application domain (deployment/sharing context/environment), wherein the at least one application (existing application flow) has a first set of application portions (components/sub-flows) (¶0022, 0031-0034, 0044).
analyzing the application data (attributes) to determine functions (signatures) of the first set of application portions (¶0048, 0057) disclosing analyzing flow attributes to determine signatures of the subflows/components then stored in the run-time flow information repository.
updating the application domain to include a new application (new application flow) having a second set of application portions, wherein the updating comprises…determining [a functional match between] an application portion (component/sub-flow) from the first set of application portions and an application portion from the second set of application portions (see ¶0024, 0046-0047, 0058-0062) limitation discussed further in view of Unterdechler. Exemplary quotation:
“input flow analyzer…analyzes any newly received input flow F (for instance, from an analytic composer), identifies all components annotated with @share and computes the signature of all such components (¶0058)...identifying one or more sub-flows of the flow that match one or more existing sub-flows that are already running in one or more separate flows by querying a run-time flow information repository...a sub-flow matches an existing sub-flow when the sub-flow performs one or more same functions and has one or more same inputs and one or more same outputs (that is, the same signature)” (¶0060-0061).
deploying the updated application domain, wherein the updated application domain does not include the application portion (that matched an already deployed component) from the second set of application portions, and wherein the deploying comprises reusing the application portion from the first set of application portions to deploy the new application (see ¶0064-0065, 0024, 0027)
“The techniques depicted in FIG. 7 also include reusing the deployed code for the flow in an existing environment. Reusing the deployed code for the flow in an existing environment can include receiving a command to deploy a new flow based program, identifying reusable components of the new flow based program that are already deployed in the existing environment, wherein the existing environment includes the deployed code for the flow and deployed code for additional flows, and generating a new flow component for any part of the new flow that is not already deployed in the existing environment.” (¶0064)
[claim 8, 15] A system for managing application architectures, the system comprising: a memory; and a processor in communication with the memory, the processor being configured/ computer readable storage medium having program instructions embodied therewith, the program instructions executable by a processor to cause the processors to perform operations/a function (see ¶0067-0071; FIG. 8).
As indicated above, Ranganathan discloses identifying sub-flows of the new flow that match/perform the same functions as existing sub-flows, but does not specifically disclose the matching includes identifying, based on a comparison of the determined functions and the predicted functions, levels of commonality for the first and second sets of application portions; and determining that a level of commonality for an application portion from the first set of application portions and an application portion from the second set of application portions exceeds a threshold level.
Unterdechler, however, discloses analogous method to identify functionally similar components/ subapplications to facilitate component reuse including a detailed machine-learning driven method for clustering subapplications into similarity groups disclosing predicting, based on application data extracted from the new application, functions of the second set of application portions; identifying, based on a comparison of the determined functions and the predicted functions (e.g. Function Blocks and Function Block types thereof), levels of commonality (similarity value) for the first and second sets of application portions; and determining that a level of commonality for an application portion from the first set of application portions and an application portion from the second set of application portions exceeds a threshold level (in same similarity group); (see at least pg. 2, col. 1, para. 2-3; pg. 4, col. 1, para. 2 and Fig. 3; pg. 5, col. 2, para. 1; pg. 6, col. 2, para. 1-3). “methods vary in, i.e., the procedures used for measuring the similarity and the parameterization (i.e. thresholds, amount of clusters). As a result, we expect a list of similarity groups, where each group includes similar components” (pg. 4, col. 1, para. 2). See pg. 3-5, § III for detailed description of similarity analysis process.
It would have been obvious to a person of ordinary skill in the art prior to the filing date of the invention to modify Ranganathan to employ Unterdechler’s AI based technique of identifying similar components to increase the speed and accuracy of the identification procedure and increasing opportunities for component reuse (Unterdechler pg. 1, Abstract; pg. 2, col. 1, para. 2-3; pg. 7, col. 1).
Claims 2, 9, and 16:
The combination of Ranganathan/Unterdechler discloses the limitations as shown in the rejections above. Unterdechler further discloses generating an application optimization plan associated with the application architecture, wherein the application optimization plan includes one or more recommendations (“information to improve development practices”, which components to reuse and how to reuse) (see at least pg. 1, Abstract and § I, para. 4-5; pg. 2, col. 1, para. 3; pg. 6, § VI-A, para. 2-4; pg. 6-7, § VI-B, para. 1).
Claims 3, 10, and 17:
The combination of Ranganathan/Unterdechler discloses the limitations as shown in the rejections above. Unterdechler does not specifically disclose having implemented automated operations to exploit the reuse and refactoring opportunities identified from the similarity analysis results, and does not specifically disclose automatically deploying the application optimization plan to the application architecture.
However, it is well established that automating a manual activity, which accomplishes the same result, is insufficient to distinguish over the prior art (see MPEP § 2144.04(III) (citing In re Venner, 262 F.2d 91, 95 (CCPA 1958)), and it would have been obvious to a person of ordinary skill in the art prior to the filing date of the invention to modify Ranganathan/Unterdechler to automatically carry out the identified component reuse and refactoring operations because “[t]he automation of such operations into existing IDEs (e.g., 4diac IDE) can help to improve the system quality and highly reduce the project specific efforts” (pg. 7, § V).
Claims 4, 11, and 18:
The combination of Ranganathan/Unterdechler the limitations as shown in the rejections above. Unterdechler further discloses identifying a new application architecture (new project), wherein the new application architecture includes one or more new application portions; identifying levels of commonality between the first set of application portions (core/common components) and the one or more new application portions; and determining whether a level of commonality from the levels of commonality of the first set of application portions and the one or more new application portions exceeds the threshold level (similar enough to existing core/common components to be implemented by reuse) (see at least pg. 1; pg. 7, col. 1).
“A typical development lifecycle of a CPPS includes the analysis of reusable components to create a common workspace that can be used from project to project. This practice is depicted in Figure 1. Based on their domain knowledge and experience, companies identify a set of common artifacts that are developed and maintained centrally on a Core Platform. This platform includes Libraries for specific components and functionalities, Templates for pre-created project structures, and Solutions for well-known machines and plants.
When a new project arrives, its requirements are analyzed to decide which components from the Core Platform to reuse.” (pg. 1, Abstract, § I, para. 4-5).
Claims 5, 12, and 19 are rejected under 35 U.S.C. 103 as being unpatentable over Ranganathan in view of Unterdechler in view of in view of Singh et al. (US 2020/0301702 A1).
Claims 5, 12, and 19:
The combination of Ranganathan/Unterdechler discloses the limitations as shown in the rejections above. Unterdechler further discloses analyzing one or more reference architectural documents (e.g. project design requirements, project hierarchy) associated with the application architecture to identify the application data (pg. 1, § I, para. 4-5; pg. 3, § III, para. 2; pg. 5, Fig. 4) and discloses removing the application portion (separate identical subapplications/FBs) from the second set of application portions and reusing a single FB instead (pg. 6, § VI-A, para. 2-4). Ranganathan/Unterdechler does not specifically disclose automatically updating the one or more reference architectural documents.
Singh however discloses an analogous software code management implementation including automatically updating (e.g. merging) the one or more reference architectural documents (specification documents) associated with code files that reuse a common code element (application portion) in at least ¶0004, 0019, 0036-0037:
“merging specification elements such as resources and definitions for re-used computer software code for an API into a single specification document for the API and to combine existing complete API specification documents that may reference each other into a single specification document. Multiple specification documents that include resources and definitions may be merged into a single document that presents uniform documentation for APIs that share common software code elements without being forced to individually update each document for a new API that includes the shared elements.”
It would have been obvious to a person of ordinary skill in the art prior to the filing date of the invention to modify Ranganathan/Unterdechler to automatically update documentation as taught by Singh to reduce development effort and because it “improves API documentation by ensuring that common API code elements are documented consistently across all APIs that share the code elements” (¶0037).
Claims 6, 7, 13, 14, and 20 are rejected under 35 U.S.C. 103 as being unpatentable over Ranganathan in view of Unterdechler in view of Farnsworth et al. (US 2014/0005856 A1).
Claims 6, 7, 13, 14, and 20:
The combination of Ranganathan/Unterdechler discloses the limitations as shown in the rejections above. Ranganathan/Unterdechler does not specifically disclose generating one or more simulations using the application data, wherein the one or more simulations are representations of the application architecture…identifying one or more missing application portions from the one or more simulations of the application architecture.
Farnsworth, however, discloses (¶0007, 0034) an analogous development environment for control applications that supports a simulation based functional validation procedures that “involve modeling flow and/or using simulations to predict faults or gaps that might lead to invalid or incomplete verification or development of a product, service, or system” (¶0035). The validation including generating one or more simulations (simulation/model) using the application data (requirements and specifications), wherein the one or more simulations are representations of the application architecture (application functional hierarchy) and identifying one or more missing application portions (gaps/violated functional requirement) from the one or more simulations of the application architecture (see at least ¶0035, 0046-0048, 0056, 0068-0070, 0076).
It would have been obvious to a person of ordinary skill in the art prior to the filing date of the invention to modify Ranganathan/Unterdechler to employ Farnsworth’s simulation driven validation method because it “allows designers to validate control specifications early in the design cycle. This improves control specification quality and reduces overall development time” (¶0036-0037, 0041).
Conclusion
The prior art made of record and not relied upon is considered pertinent to applicant’s disclosure:
The following references are directed to deployment systems capable of reusing already deployed components: US 11811681 B1; US 20200065225 A1; US 20090007097 A1; US 20080295109 A1; “Cafe A Generic Configurable Customizable Composite Cloud Application Framework”
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 of a general nature or relating to the status of this application or concerning this communication or earlier communications from the Examiner should be directed to Paul Mills whose telephone number is 571-270-5482. The Examiner can normally be reached on Monday-Friday 11:00am-8:00pm. If attempts to reach the examiner by telephone are unsuccessful, the Examiner’s supervisor, April Blair can be reached at 571-270-1014.
Examiner interviews are available via telephone, in-person, and video conferencing using a USPTO supplied web-based collaboration tool. To schedule an interview, applicant is encouraged to use the USPTO Automated Interview Request (AIR) at http://www.uspto.gov/interviewpractice.
Information regarding the status of published or unpublished applications may be obtained from Patent Center. Unpublished application information in Patent Center is available to registered users. To file and manage patent submissions in Patent Center, visit: https://patentcenter.uspto.gov. Visit https://www.uspto.gov/patents/apply/patent-center for more information about Patent Center and https://www.uspto.gov/patents/docx for information about filing in DOCX format. For additional questions, contact the Electronic Business Center (EBC) at 866-217-9197 (toll-free). If you would like assistance from a USPTO Customer Service Representative, call 800-786-9199 (IN USA OR CANADA) or 571-272-1000.
/P. M./
Paul Mills
02/04/2026
/APRIL Y BLAIR/Supervisory Patent Examiner, Art Unit 2196