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 office action is in response to applicant’s RCE filed on 04/28/2026.
Claims 1-20 are pending and examined.
Response to Arguments
Per 103 rejection, applicant’s arguments filed on 04/10/2026 have been fully considered
but are moot in light of new grounds of rejection with a new reference (Chaganti) applied for the new limitations.
Applicant also argued (page 8 of the remark) the cited prior art do not teach the limitation of “dynamically synchronizing the reference architecture with the code repository”. The examiner respectfully disagrees, see the updated 103 rejection below.
The examiner is available for a phone interview with applicant.
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, 3-8, 10-11, 13-16 and 18-20 are rejected under 35 U.S.C. 103 as being unpatentable Lindvall et al. (US PGPUB 2009/0276757) hereinafter Lindvall, in view of Kodosky et al. (US PGPUB 2003/0184595) hereinafter Kodosky, in view of Charisius et al. (US PGPUB 2002/0108101) hereinafter Charisius, in view of Chaganti (US PGPUB 2017/0068931).
Per claim 1, Lindvall discloses a method comprising: obtaining information based on an action performed relating to a portion of code of an application stored, the portion of code dynamically aligned with at least one component of a reference architecture relating to the application, wherein a correlation exists between the portion of code and the reference architecture (paragraphs [0015][0016][0041][0042]; build an abstract model of the code and planned architectures of a software system, the abstract model of the code architecture documents the dependencies between the conceptual components identified and selected by the users; the abstract models of the code and planned architectures are displayed to enable comparison of the code and planned architectures; a mapping between the abstract model and the file system model is maintained to provide explicit linkages between elements in the abstract model and their corresponding elements in the software system's source code (i.e. correlating between the portion of code and the reference architecture)); automatically navigating to a specified location based on the information, the specified location being one of a selected area in the code and a selected area in the reference architecture (paragraphs [0015][0016][0041][0042]; the explicit linkage is used to navigate between abstract views of the code architecture from the highest-level elements to the source code details, (i.e. the a user can use the linkage information to navigate between a particular location in the code architecture to the corresponding location in the source code)).
Lindvall does not explicitly state the source code is stored in a code repository. However, this is a common practice in the field of the art, as evidenced in Kodosky (paragraph [0442]; storing program assets in a database). Kodosky also suggests automatically navigating to a specified location based on the information, the specified location being one of a selected area in the code repository and a selected area in the reference architecture (paragraph [0025]; a user can interact with a program icon in the application diagram (reference architecture), and the corresponding source code is displayed). Therefore, it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to combine Lindvall and Kodosky to store source code in a code repository for easy access and code management/maintenance.
Lindvall does not explicitly teach dynamically synchronizing the reference architecture with the code repository based on a change to the code repository, the dynamically synchronizing the reference architecture with the code repository including automatically modifying the reference architecture to reflect the change and to indicate how the change relates to one or more selected components of the reference architecture. However, Charisius suggests the above (paragraphs [0019][0057][0058][0088][0089][0096], a software development tool that creates a graphical representation (reference architecture) of source code, the software development tool also reflects (synchronizes) any modifications to the source code on the graphical representation; the graphical and textual views are synchronized so that a modification in one view is automatically reflected in the other view; QA module provides an error message if the modification does not conform a set of rules; the graphical representation includes a Unified Modeling diagram, which displays components and their relationships; the change in source code can be an addition to the source code). Thus, it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to combine Lindvall, Kodosky and Charisius to dynamically synchronize a change in source code in a repository to a graphical view (reference architecture) of a component diagram corresponding to the source code; as the graphical view can help a user to easily identify a complex system to visualize structural and behavioral patterns (Charisius, paragraph [0016]).
Lindvall discloses obtaining a reference architecture relating to the application (paragraphs [0015][0016][0041][0042]; build an abstract model of the code and planned architectures of a software system, the abstract model of the code architecture documents the dependencies between the conceptual components identified and selected by the users), Lindvall does not explicitly teach the reference architecture including one or more documents that describe one or more components of the reference architecture, the one or more documents providing one or more recommended structures and an integration of one or more information technology products to be used to form a solution to a selected project in a selected industry. However, Chaganti suggests the above (paragraph [0014], associating reference architecture documents and other technical documents with associated components, allowing a customer to see relevant recommendations as they build a specific hardware configuration, after which they can use the recommendation to generate a complete Bill-Of-Material for the solution, for further customizing the hardware to suit their needs, the desired level of recommendations can be shown on a product selection screen). Thus, it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to combine Lindvall, Kodosky, Charisius and Chaganti to associate reference architecture documents with components of a system and to allow a customer to see relevant recommendations as they build a specific hardware configuration as a solution to a project; as these reference architecture documents provide important and useful information for system integration in an IT project.
Per claim 3, Kodosky further suggests “wherein the information comprises an indication of a user selected component of the reference architecture, and wherein the specified location is the selected area in the code repository” (paragraph [0025]; a user can interact with a program icon (selected component) in the application diagram (reference architecture), and the corresponding source code is displayed).
Per claim 4, Kodosky further suggests “wherein the user selected component is at a selected granular level of functionality of a plurality of granular levels of functionality within the reference architecture” (paragraphs [0025][0201]; a user can interact with a program icon (selected component) in the application diagram (reference architecture), and the corresponding source code is displayed; the user can select different options to display the configuration diagram with different views or different levels of granularity).
Per claim 5, Lindvall further suggests “wherein the information comprises an indication of a user selected code portion of the code repository, and wherein the specified location is the selected area in the reference architecture” (paragraphs [0101]0041][0042]; the explicit linkage is used to navigate between abstract views of the code architecture from the highest-level elements to the source code details, (i.e. the a user can use the linkage information to navigate between a particular location in the code architecture to the corresponding location in the source code)).
Per claim 6, Lindvall further suggests “dynamically aligning the portion of code with the at least one component of the reference architecture relating to the application, wherein the dynamically aligning provides the correlation between the portion of code of the code repository and the reference architecture” (paragraphs [0042][0146][0147][0148]; the explicit linkage is used to navigate between abstract views of the code architecture from the highest-level elements to the source code details; after code changes have been implemented, steps are repeated to verify that the updated actual architecture complies with the planned code architecture, prior to verifying that the planned and updated actual architectures are aligned, steps are repeated to identify the updated planned and actual architectures, an additional comparison may be necessary in order to make sure that the changes have been implemented correctly and that no new deviations).
Per claim 7, Lindvall further suggests “analyzing one or more code components of the portion of code to provide code analysis; analyzing chosen one or more components of the reference architecture to provide reference architecture analysis; using the code analysis and the reference architecture analysis to correlate the portion of code with the at least one component of the reference architecture” (paragraphs [0015][0016][0041][0042]; build an abstract model of the code and planned architectures of a software system, the abstract model of the code architecture documents the dependencies between the conceptual components identified and selected by the users; the abstract models of the code and planned architectures are displayed to enable comparison of the code and planned architectures; a mapping between the abstract model and the file system model is maintained to provide explicit linkages between elements in the abstract model and their corresponding elements in the software system's source code (i.e. correlating between the portion of code and the reference architecture)).
Per claim 8, Lindvall further suggests “wherein the analyzing the one or more code components comprises analyzing one or more tags and functionality of, at least, the one or more code components” (paragraphs [0015][0016][0041][0042]; build an abstract model of the code and planned architectures of a software system, the abstract model is derived from a concrete file system model, wherein the file system model is constructed by the methods, computer program products, and systems, the file system model describes the dependencies between the software system's components, such as method invocations, function calls (functionality), variable access (tag), and other dependencies between the files and directories that contain the software system's source code.).
Per claim 10, Charisius further suggests “wherein the change to the code repository is an addition of new code and wherein the automatically modifying the reference architecture includes modifying the reference architecture to include an indication of the new code and how it relates to the one or more selected components of the reference architecture” (paragraphs [0019][0057][0058][0088][0089][0096], a software development tool that creates a graphical representation of source code, the software development tool also reflects (synchronizes) any modifications to the source code on the graphical representation; the graphical representation includes a Unified Modeling diagram, which displays components and their relationships; the change in source code can be an addition to the source code; the added component/file is displayed in the Unified modeling diagram).
Claims 11, 13-15 recite similar limitations as claims 1, 3, 5-6. Therefore, claims 11, 13-15 are rejected under similar rationales as claims 1, 3, 5-6.
Claims 16, 18-20 recite similar limitations as claims 1, 3, 5-6. Therefore, claims 16, 18-20 are rejected under similar rationales as claims 1, 3, 5-6.
Claims 2, 12 and 17 are rejected under 35 U.S.C. 103 as being unpatentable over Lindvall, in view of Kodosky, in view of Charisius, in view of Chaganti, in view of Reshef et al. (US PGPUB 2002/0120919) hereinafter Reshef.
Per claim 2, Lindvall does not explicitly teach “wherein the information comprises an indication that the portion of code generated a status log based on execution of the application, and wherein the specified location is the selected area in the reference architecture”. However, Reshef suggests the above (claim 1; generating a program execution report from a program execution, then generating a visual representation of the hierarchical program structure and a visual representation of the position within the hierarchical program structure corresponding to the stage of program execution indicated by the received report). Therefore, it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to combine Lindvall, Kodosky, Charisius, Chaganti and Reshef to generate a program execution report and displaying a specific location in a hierarchical program structure corresponding to the stage of program execution indicated by the received report, this would help a user to diagnosis and debug the program.
Claims 12 and 17 recite similar limitations as claim 2. Therefore, claims 12 and 17 are rejected under similar rationales as claim 2.
Claims 9 is rejected under 35 U.S.C. 103 as being unpatentable over Lindvall, in view of Kodosky, in view of Charisius, in view of Chaganti, in view of Ashek et al. (US PGPUB 2021/0089767) hereinafter Ashek.
Per claim 9, Lindvall does not explicitly teach “the analyzing the chosen one or more components of the reference architecture includes performing image analysis and textual analysis of, at least, the one or more components of the reference architecture”. However, Ashek suggests the above (abstract paragraphs [0004][0024][0025]; extracting and analyzing information from an architecture diagram; an extraction component is configured to extract attributes (e.g., text annotations) from the nodes and edges; an identification component classifies regions of the drawing into node types using image segmentation). Therefore, it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to combine Lindvall, Kodosky, Charisius, Chaganti and Ashek to analyze the reference architecture diagram using image analysis and text analysis, in order to extract useful information from the reference architecture diagram, in order to perform an architecture verification process.
Conclusion
Any inquiry concerning this communication or earlier communications from the examiner should be directed to HANG PAN whose telephone number is (571)270-7667. The examiner can normally be reached 9 AM to 5 PM.
Examiner interviews are available via telephone, in-person, and video conferencing using a USPTO supplied web-based collaboration tool. To schedule an interview, applicant is encouraged to use the USPTO Automated Interview Request (AIR) at http://www.uspto.gov/interviewpractice.
If attempts to reach the examiner by telephone are unsuccessful, the examiner’s supervisor, Chat Do can be reached at 571-272-3721. The fax phone number for the organization where this application or proceeding is assigned is 571-273-8300.
Information regarding the status of published or unpublished applications may be obtained from Patent Center. Unpublished application information in Patent Center is available to registered users. To file and manage patent submissions in Patent Center, visit: https://patentcenter.uspto.gov. Visit https://www.uspto.gov/patents/apply/patent-center for more information about Patent Center and https://www.uspto.gov/patents/docx for information about filing in DOCX format. For additional questions, contact the Electronic Business Center (EBC) at 866-217-9197 (toll-free). If you would like assistance from a USPTO Customer Service Representative, call 800-786-9199 (IN USA OR CANADA) or 571-272-1000.
/HANG PAN/Primary Examiner, Art Unit 2193
Prosecution Insights