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 the amendment filed 10/30/2025.
Claim 1 has been amended.
Claims 1-12 remain pending and have been considered below.
Response to Arguments
Applicant’s arguments with respect to claim 1-12 have been considered but are moot because the new ground of rejection does not rely on any reference applied in the prior rejection of record for any teaching or matter specifically challenged in the argument.
Claim Rejections - 35 USC § 102
The following is a quotation of the appropriate paragraphs of 35 U.S.C. 102 that form the basis for the rejections under this section made in this Office action:
A person shall be entitled to a patent unless –
(a)(1) the claimed invention was patented, described in a printed publication, or in public use, on sale, or otherwise available to the public before the effective filing date of the claimed invention.
Claims 1-4 and 12 are rejected under 35 U.S.C. 102(a)(1) as being anticipated by U.S. Pub. No. 20210064347 to Junior.
Per claim 1, Junior teaches a computer-implemented method for mapping source code to computation resource, the method comprising the steps of:
using one or more processors to query cloud-provider metadata or management APIs to determine computation resources of a cloud provider used by an application (see at least paragraph [0154] “FIG. 6 illustrates exemplary function usage data 600 extracted from cloud native APIs stored by the multi-cloud biller 120 of FIG. 1, according to some embodiments. It is noted that a system administrator can optionally create multiple subscriptions for one Cloud Type, although it is not necessary. Using this extracted information 600, the database 125 can provide the system administrator with consolidated data showing how much the proposed system owes to each Cloud. In one or more embodiments, the multi-cloud biller 120 uses the exemplary internal billing information of FIG. 6 and queries the multi-cloud orchestrator 160 about what application contains which functions, so that monthly developer bills can be provided to developers by (i) consolidating the costs per application (cost of its functions during the month), and (ii) applying administrations fees”);
identifying, by the one or more processors, executable artifacts that are deployed on the computation resources (see at least paragraph [0155] “…the multi-cloud biller 120 can query the multi-cloud orchestrator 160 to discover that Application A was composed of functions Func1 and FuncA on 20.02.02, and it can consolidate the cost of this application…”).
matching, by the one or more processors, executable artifacts to source-code and configuration content to provide artifact to code or configuration matches (see at least paragraph [0221] “…obtains a first source code for at least one function of a plurality of functions of an application during step 1210. As described herein, the at least one function is hosted in a first cloud having a first cloud environment of a plurality of distinct cloud environments…”).
Per claim 2, Junior further teaches:
wherein the step of identifying executable artifacts includes identifying contained artifacts that are embedded in the executable artifacts (see at least paragraph [0257] “…querying a structural state of the application to obtain one or more of an identifier of one or more of the functions of the application, an identifier of one of the distinct cloud environments hosting one or more of the functions of the application, and an identifier of a version of one or more of the functions of the application…”).
Per claim 3, Junior further teaches:
obtaining content of all or parts of physical or virtual storage devices used by the computation resources and metadata about the computation resources (see at least FIG.6).
Per claim 4, Junior further teaches:
monitoring build processes of the source-code that generate the executable artifacts (see at least paragraph [0208] “…every time a change on a function source code is committed to the master repository, it will send a push notification to the multi-cloud CI/CD 130 via HTTP and the system will reflect the change in the deployed application (e.g., update the function in the correct public cloud immediately)…”).
Per claim 12, Zhang further teaches
recording the artifact to code or configuration matches in a database (see at least col.14, lines 22-24 “…The disclosed system generates configuration files for different clouds and function types, deploys the functions…”); and
allowing intervention by a manual operator to update or override the artifact to code or configuration matches recorded in the database (see at least paragraph [0223] “…updates the function via CI/CD and/or migrates functions among clouds according to pre-established optimization criteria (e.g., price or network utilization)…”).
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 5-11 are rejected under 35 U.S.C. 103 as being unpatentable over U.S. Pub. No. 20210064347 to Junior in view of U.S. Patent No. 11537400 to Zhang.
Per claim 5, Junior does not explicitly teach
wherein the step of matching executable artifacts includes generating candidate matches and assigning a confidence score to each of the candidate matches, the confidence score indicates a likelihood of being an actual match.
Zhang teaches an analogous art relates to mapping source code to binary code, comprises:
generating candidate matches and assigning a confidence score to each of the candidate matches (see at least col.11, lines 65-67 – col.12, lines 1-6 “…identification of source code associated with binary executable files based on a weighted matching of hash signatures derived from the binary executable files and source code according to some embodiments. As shown, the analysis involves a comparison of one or more repositories 308A-308N (e.g., candidate repositories identified by the processes described in FIG. 3) and executable binary file(s) 302 associated with a software application…”), the confidence score indicates a likelihood of being an actual match (see at least col.11, lines 30-45 “…a weighted matching algorithm 412 is then used to identify a repository most likely to correspond to the executable binary file(s) 302 based on a comparison of the hash values of the hash map 410 and each of the hash maps 408A-408N. For example, the weighted matching algorithm 412 may more heavily weight the hash value matches corresponding to method names over hash value matches corresponding to package names, or more heavily weight matching class names over matching file names, etc. In some embodiments, the process may select a best matching repository as an identified match 414, e.g., based on a repository or repositories that include a greatest number or percentage of matching hash values…”).
It would have been obvious for a person of an ordinary skilled in the art as of the effective filing date of the claimed invention to modify the teaching of Junior to incorporate the teaching of Zhang to generate candidates that matching the executable code. One would have been motivated find matching candidates for executable code in order to save time from generating the source code.
Per claim 6, Zhang further teaches
employing an optimization algorithm that selects a matching that maximizes the overall or total confidence score, while not including contradicting matches (see at least col.11, lines 30-45 “…a weighted matching algorithm 412 is then used to identify a repository most likely to correspond to the executable binary file(s) 302 based on a comparison of the hash values of the hash map 410 and each of the hash maps 408A-408N. For example, the weighted matching algorithm 412 may more heavily weight the hash value matches corresponding to method names over hash value matches corresponding to package names, or more heavily weight matching class names over matching file names, etc. In some embodiments, the process may select a best matching repository as an identified match 414, e.g., based on a repository or repositories that include a greatest number or percentage of matching hash values…”).
Per claim 7, Zhang further teaches
wherein the candidate matches are generated using a Name-based Matching of Artifact To Code mechanism wherein names of artifacts are compared against exact or approximate names of modules and repositories, and exact or approximate names of generated artifacts as they are expressed in build and project files within the modules and repositories (see at least col.11, lines 30-45 “…a weighted matching algorithm 412 is then used to identify a repository most likely to correspond to the executable binary file(s) 302 based on a comparison of the hash values of the hash map 410 and each of the hash maps 408A-408N. For example, the weighted matching algorithm 412 may more heavily weight the hash value matches corresponding to method names over hash value matches corresponding to package names, or more heavily weight matching class names over matching file names, etc. In some embodiments, the process may select a best matching repository as an identified match 414, e.g., based on a repository or repositories that include a greatest number or percentage of matching hash values…”).
Per claim 8, Zhang further teaches
wherein the candidate matches are generated using an Artifact Metadata-based Matching To Code mechanism wherein artifact metadata is obtained from at least one source of the group of sources including: an executable header, an executable version information resource; an executable-embedded manifest; a manifest file alongside an executable artifact; and artifacts managed in an artifact repository; and wherein the artifact metadata is used to match to repositories based on predefined rules (see at least col.11, lines 39-45 “…modernization agent 130 filters out for analysis any repositories managed by the version control system 142 that are associated with applications developed in the .NET language or that use a framework that is incompatible with a framework identified by the decomposed application data 306. In some embodiments, the modernization agent 130 further filters repositories based on a comparison of filenames in the repository and filenames identified in the decomposition of the binary executable file(s) 302…”).
Per claim 9, Zhang further teaches
wherein the candidate matches are generated using a Dependency Fingerprint-based Matching To Code mechanism, wherein a respective fingerprint is created including dependencies of each artifact of the executable artifacts and comparing the fingerprint to declared dependencies declared for modules in the source-code (see at least col.13, lines 33-50 “…once the source code for an application is identified and obtained by the modernization service 102 or modernization agent 130, the source code can be analyzed to obtain data useful to various modernization recommendation processes. The analysis results may include various application attributes such as, for example, an application type, a programming language used to develop the application, integrations with other systems, architecture type (e.g., monolithic, 3-tier, microservice-based, etc.), application dependencies (e.g., on third party software and libraries, other libraries and files, execution environments), application relationships (e.g., network connections, inter-process communications (IPC), remote procedure calls (RPC)), data flow and network throughput, and the like…”).
Per claim 10, Zhang further teaches
wherein the candidate matches are generated using a Symbol-based Matching of Artifact To Code mechanism wherein at least one of: class names, exported functions, and internal symbols present in executable artifacts, are compared to a list of symbols devised from the source-code (see at least col.12, lines 46-67 “In some embodiments, another process discovered binary executable files or other runtime artifacts to candidate source code repositories involves extracting symbol tables or assembly binary code from the binary executable files and comparing information contained therein to a filtered set of repositories as described above. For example, applications implemented using some programming languages may not be associated with an intermediate language that can be easily decomposed by a decomposition tool as described above…”).
Per claim 11, Zhang further teaches
wherein the step of matching executable artifacts includes generating candidate matches using a Build Process Tracking for Matching Artifact to Code mechanism wherein the build process in a continuous integration and continuous delivery/continuous deployment (CI/CD) system is monitored to identify potential names of the executable artifacts (see at least col.3, lines 20-35 “…In some embodiments, the automation server 146 broadly represents any type of server, service, application, or other tool that helps automate various software development processes such as, for example, building, testing, and deploying software applications. An automation server 146, for example, may automate such processes in an effort to facilitate a continuous integration and continuous delivery approach to software development and deployment…”).
Conclusion
Applicant's amendment necessitated the new ground(s) of rejection presented in this Office action. Accordingly, THIS ACTION IS MADE FINAL. See MPEP § 706.07(a). Applicant is reminded of the extension of time policy as set forth in 37 CFR 1.136(a).
A shortened statutory period for reply to this final action is set to expire THREE MONTHS from the mailing date of this action. In the event a first reply is filed within TWO MONTHS of the mailing date of this final action and the advisory action is not mailed until after the end of the THREE-MONTH shortened statutory period, then the shortened statutory period will expire on the date the advisory action is mailed, and any nonprovisional extension fee (37 CFR 1.17(a)) pursuant to 37 CFR 1.136(a) will be calculated from the mailing date of the advisory action. In no event, however, will the statutory period for reply expire later than SIX MONTHS from the mailing date of this final action.
Any inquiry concerning this communication or earlier communications from the examiner should be directed to PHILLIP H NGUYEN whose telephone number is (571)270-1070. The examiner can normally be reached Monday-Friday 9:00AM-5:00PM.
Examiner interviews are available via telephone, in-person, and video conferencing using a USPTO supplied web-based collaboration tool. To schedule an interview, applicant is encouraged to use the USPTO Automated Interview Request (AIR) at http://www.uspto.gov/interviewpractice.
If attempts to reach the examiner by telephone are unsuccessful, the examiner’s supervisor, Wei Zhen can be reached at (571) 272-3708. 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.
/PHILLIP H NGUYEN/Primary Examiner, Art Unit 2191