Prosecution Insights
Last updated: October 02, 2026
Application No. 18/677,516

AUTOMATED SOFTWARE PACKAGE RELEASE MANAGEMENT

Non-Final OA §101§102§103§112
Filed
May 29, 2024
Examiner
RIVERA, ANIBAL
Art Unit
2192
Tech Center
2100 — Computer Architecture & Software
Assignee
Microsoft Technology Licensing, LLC
OA Round
1 (Non-Final)
91%
Grant Probability
Favorable
1-2
OA Rounds
0m
Est. Remaining
99%
With Interview

Examiner Intelligence

Grants 91% — above average
91%
Career Allowance Rate
692 granted / 761 resolved
+35.9% vs TC avg
Moderate +12% lift
Without
With
+11.9%
Interview Lift
resolved cases with interview
Typical timeline
2y 3m
Avg Prosecution
40 currently pending
Career history
792
Total Applications
across all art units

Statute-Specific Performance

§101
14.4%
-25.6% vs TC avg
§103
44.6%
+4.6% vs TC avg
§102
25.1%
-14.9% vs TC avg
§112
8.6%
-31.4% vs TC avg
Black line = Tech Center average estimate • Based on career data from 761 resolved cases

Office Action

§101 §102 §103 §112
CTNF 18/677,516 CTNF 87882 DETAILED ACTION This action is responsive to application filed on May 29, 2024. Claims 1-20 are pending and are presented to examination. 07-03-aia AIA 15-10-aia The present application, filed on or after March 16, 2013, is being examined under the first inventor to file provisions of the AIA. 07-06 AIA 15-10-15 In the event the determination of the status of the application as subject to AIA 35 U.S.C. 102 and 103 (or as subject to pre-AIA 35 U.S.C. 102 and 103) is incorrect, any correction of the statutory basis for the rejection will not be considered a new ground of rejection if the prior art relied upon, and the rationale supporting the rejection, would be the same under either status. Examiner Notes Examiner cites particular columns, paragraphs, figures and line numbers in the references as applied to the claims below for the convenience of the applicant. Although the specified citations are representative of the teachings in the art and are applied to the specific limitations within the individual claim, other passages and figures may apply as well. It is respectfully requested that, in preparing responses, the applicant fully consider the references in their entirety as potentially teaching all or part of the claimed invention, as well as the context of the passage as taught by the prior art or disclosed by the examiner. Drawings The drawings filed on May 29, 2024 are acceptable for examination purposes. Information Disclosure Statement As required by M.P.E.P. 609, the applicant’s submission of the Information Disclosure Statement dated May 29, 2024 is acknowledged by the examiner and the cited references have been considered in the examination of the claims now pending. Claim Objections 07-29-01 AIA Claim 15 is objected to because of the following informalities: Claim 15 recites “ wherein each of the plurality of software packages is developed in a software package development process associated with [[the]] a software release manage (SRM) SRM ; and wherein the association comprises hooks in the software package development process causing automated reporting of the information indicative of change of components in each of the plurality of software packages to [[the]] a data manager. ” . Appropriate correction is required. 07-30-03-h AIA Claim Interpretation 07-30-03 AIA The following is a quotation of 35 U.S.C. 112(f): (f) Element in Claim for a Combination. – An element in a claim for a combination may be expressed as a means or step for performing a specified function without the recital of structure, material, or acts in support thereof, and such claim shall be construed to cover the corresponding structure, material, or acts described in the specification and equivalents thereof. The following is a quotation of pre-AIA 35 U.S.C. 112, sixth paragraph: An element in a claim for a combination may be expressed as a means or step for performing a specified function without the recital of structure, material, or acts in support thereof, and such claim shall be construed to cover the corresponding structure, material, or acts described in the specification and equivalents thereof. 07-30-05 The claims in this application are given their broadest reasonable interpretation using the plain meaning of the claim language in light of the specification as it would be understood by one of ordinary skill in the art. The broadest reasonable interpretation of a claim element (also commonly referred to as a claim limitation) is limited by the description in the specification when 35 U.S.C. 112(f) or pre-AIA 35 U.S.C. 112, sixth paragraph, is invoked. As explained in MPEP § 2181, subsection I, claim limitations that meet the following three-prong test will be interpreted under 35 U.S.C. 112(f) or pre-AIA 35 U.S.C. 112, sixth paragraph: (A) the claim limitation uses the term “means” or “step” or a term used as a substitute for “means” that is a generic placeholder (also called a nonce term or a non-structural term having no specific structural meaning) for performing the claimed function; (B) the term “means” or “step” or the generic placeholder is modified by functional language, typically, but not always linked by the transition word “for” (e.g., “means for”) or another linking word or phrase, such as “configured to” or “so that”; and (C) the term “means” or “step” or the generic placeholder is not modified by sufficient structure, material, or acts for performing the claimed function. Use of the word “means” (or “step”) in a claim with functional language creates a rebuttable presumption that the claim limitation is to be treated in accordance with 35 U.S.C. 112(f) or pre-AIA 35 U.S.C. 112, sixth paragraph. The presumption that the claim limitation is interpreted under 35 U.S.C. 112(f) or pre-AIA 35 U.S.C. 112, sixth paragraph, is rebutted when the claim limitation recites sufficient structure, material, or acts to entirely perform the recited function. Absence of the word “means” (or “step”) in a claim creates a rebuttable presumption that the claim limitation is not to be treated in accordance with 35 U.S.C. 112(f) or pre-AIA 35 U.S.C. 112, sixth paragraph. The presumption that the claim limitation is not interpreted under 35 U.S.C. 112(f) or pre-AIA 35 U.S.C. 112, sixth paragraph, is rebutted when the claim limitation recites function without reciting sufficient structure, material or acts to entirely perform the recited function. Claim limitations in this application that use the word “means” (or “step”) are being interpreted under 35 U.S.C. 112(f) or pre-AIA 35 U.S.C. 112, sixth paragraph, except as otherwise indicated in an Office action. Conversely, claim limitations in this application that do not use the word “means” (or “step”) are not being interpreted under 35 U.S.C. 112(f) or pre-AIA 35 U.S.C. 112, sixth paragraph, except as otherwise indicated in an Office action. This application includes one or more claim limitations that do not use the word “means,” but are nonetheless being interpreted under 35 U.S.C. 112(f) or pre-AIA 35 U.S.C. 112, sixth paragraph, because the claim limitation(s) uses a generic placeholder that is coupled with functional language without reciting sufficient structure to perform the recited function and the generic placeholder is not preceded by a structural modifier. Such claim limitation(s) is/are: “ a data manager configured to automatically obtain and store information indicative of change, testing, and release of a software package; ”, “ a releaser configured to automatically generate the information indicative of the release of the software package for each release of the software package; ” and “ a dashboard manager configured to provide a user interface for an authorized user to access the stored information indicative of change, testing, and release of the software package. ” in claim 1 , “ a notifier configured to automatically notify configured recipients about the information indicative of change, testing, or release of the software package in response to a configured notification trigger. ” in claim 2 , “ wherein the releaser comprises an approval manager configured to automatically manage the release of the software package comprising managing an approval process to obtain approval of the software package from the configured recipients. ” in claim 5 , “ wherein the releaser comprises a compliance checker configured to automatically determine whether components in the software package comply with configured release criteria. ” in claim 6 , “ wherein the releaser comprises a change log generator configured to automatically maintain a history of changes to components in the software package. ” in claim 7 , “ wherein the dashboard manager comprises a package comparer configured to automatically determine differences between components in different released or pre-released software packages or in different releases of the same software package. ” in claim 8 and “ wherein the releaser comprises a package deployer configured to automatically deploy the released software package to configured destinations. ” in claim 10 . Because this/these claim limitation(s) is/are being interpreted under 35 U.S.C. 112(f) or pre-AIA 35 U.S.C. 112, sixth paragraph, it/they is/are being interpreted to cover the corresponding structure described in the specification as performing the claimed function, and equivalents thereof. If applicant does not intend to have this/these limitation(s) interpreted under 35 U.S.C. 112(f) or pre-AIA 35 U.S.C. 112, sixth paragraph, applicant may: (1) amend the claim limitation(s) to avoid it/them being interpreted under 35 U.S.C. 112(f) or pre-AIA 35 U.S.C. 112, sixth paragraph (e.g., by reciting sufficient structure to perform the claimed function); or (2) present a sufficient showing that the claim limitation(s) recite(s) sufficient structure to perform the claimed function so as to avoid it/them being interpreted under 35 U.S.C. 112(f) or pre-AIA 35 U.S.C. 112, sixth paragraph. Claim Rejections - 35 USC § 112 07-30-02 AIA The following is a quotation of 35 U.S.C. 112(b): (b) CONCLUSION.—The specification shall conclude with one or more claims particularly pointing out and distinctly claiming the subject matter which the inventor or a joint inventor regards as the invention. The following is a quotation of 35 U.S.C. 112 (pre-AIA), second paragraph: The specification shall conclude with one or more claims particularly pointing out and distinctly claiming the subject matter which the applicant regards as his invention. 07-34-01 Claims 1-11 and 16 are rejected under 35 U.S.C. 112(b) or 35 U.S.C. 112 (pre-AIA), second paragraph, as being indefinite for failing to particularly point out and distinctly claim the subject matter which the inventor or a joint inventor (or for applications subject to pre-AIA 35 U.S.C. 112, the applicant), regards as the invention. Claim 1 limitations, “ a data manager configured to automatically obtain and store information indicative of change, testing, and release of a software package; ”, “ a releaser configured to automatically generate the information indicative of the release of the software package for each release of the software package; ” and “ a dashboard manager configured to provide a user interface for an authorized user to access the stored information indicative of change, testing, and release of the software package. ” invoke 35 U.S.C. 112(f) or pre-AIA 35 U.S.C. 112, sixth paragraph. Claim 2 limitation, “ a notifier configured to automatically notify configured recipients about the information indicative of change, testing, or release of the software package in response to a configured notification trigger. ” invokes 35 U.S.C. 112(f) or pre-AIA 35 U.S.C. 112, sixth paragraph. Claim 5 limitation, “ wherein the releaser comprises an approval manager configured to automatically manage the release of the software package comprising managing an approval process to obtain approval of the software package from the configured recipients. ” invokes 35 U.S.C. 112(f) or pre-AIA 35 U.S.C. 112, sixth paragraph. Claim 6 limitation, “ wherein the releaser comprises a compliance checker configured to automatically determine whether components in the software package comply with configured release criteria. ” invokes 35 U.S.C. 112(f) or pre-AIA 35 U.S.C. 112, sixth paragraph. Claim 7 limitation, “ wherein the releaser comprises a change log generator configured to automatically maintain a history of changes to components in the software package. ” invokes 35 U.S.C. 112(f) or pre-AIA 35 U.S.C. 112, sixth paragraph. Claim 8 limitation, “ wherein the dashboard manager comprises a package comparer configured to automatically determine differences between components in different released or pre-released software packages or in different releases of the same software package. ” invokes 35 U.S.C. 112(f) or pre-AIA 35 U.S.C. 112, sixth paragraph. Claim 10 limitation, “ wherein the releaser comprises a package deployer configured to automatically deploy the released software package to configured destinations. ” invokes 35 U.S.C. 112(f) or pre-AIA 35 U.S.C. 112, sixth paragraph. However, the written description fails to disclose the corresponding structure, material, or acts for performing the entire claimed function and to clearly link the structure, material, or acts to the function. In view of Figure 1 of instant application including corresponding component: SRM Server 104 (appears to equate to management server for providing different functionalities. However, it does not disclose corresponding hardware structure that provide claims functionalities, especially, the disclosure does not provide clear structural support for performing claims steps such as to store, generate, provider etc.; it is further to note that Figure 1, and paragraph [0039] of the instant application disclose that the SRM 104 may be “ SRM server 104 comprises one or more computing devices, servers, services, local processes, remote machines, web services, etc. SRM server 104 may be any type of stationary or mobile computing device. In an example, SRM server 104 may comprise a server located on an organization’s premises and/or coupled to an organization’s local network, a remotely located (e.g., third party) server, a cloud-based server (e.g., one or more servers in a distributed manner), or any other device or service that may host, manage, and/or provide resource(s) for automated software package release management. SRM server 104 may be implemented as a plurality of programs executed by one or more computing devices. SRM server 104 is not limited to a physical machine, but may include other types of machines or nodes, such as a virtual machine , that are executed in physical machines. ” It is unclear whether the SRM 104 is hardware or software as claimed and how is used to carry on the functions of the above limitations. Therefore, the claim is indefinite and is rejected under 35 U.S.C. 112(b) or pre-AIA 35 U.S.C. 112, second paragraph. 07-34-23 Applicant may: (a) Amend the claim so that the claim limitation will no longer be interpreted as a limitation under 35 U.S.C. 112(f) or pre-AIA 35 U.S.C. 112, sixth paragraph; (b) Amend the written description of the specification such that it expressly recites what structure, material, or acts perform the entire claimed function, without introducing any new matter (35 U.S.C. 132(a)); or (c) Amend the written description of the specification such that it clearly links the structure, material, or acts disclosed therein to the function recited in the claim, without introducing any new matter (35 U.S.C. 132(a)). If applicant is of the opinion that the written description of the specification already implicitly or inherently discloses the corresponding structure, material, or acts and clearly links them to the function so that one of ordinary skill in the art would recognize what structure, material, or acts perform the claimed function, applicant should clarify the record by either: (a) Amending the written description of the specification such that it expressly recites the corresponding structure, material, or acts for performing the claimed function and clearly links or associates the structure, material, or acts to the claimed function, without introducing any new matter (35 U.S.C. 132(a)); or (b) Stating on the record what the corresponding structure, material, or acts, which are implicitly or inherently set forth in the written description of the specification, perform the claimed function. For more information, see 37 CFR 1.75(d) and MPEP §§ 608.01(o) and 2181. Dependent claims 3-4, 9 and 11 do not overcome the deficiency of the base claim and, therefore, are rejected for the same reasons as the base claim. Claim 5 (and similar for claim 16) recites “ wherein the releaser comprises an approval manager configured to automatically manage the release of the software package comprising managing an approval process to obtain approval of the software package from the configured recipients. ” There is insufficient antecedent basis for this limitation in the claim. Claim Rejections - 35 USC § 101 07-04-01 AIA 07-04 35 U.S.C. 101 reads as follows: Whoever invents or discovers any new and useful process, machine, manufacture, or composition of matter, or any new and useful improvement thereof, may obtain a patent therefor, subject to the conditions and requirements of this title. Claims 1-20 are rejected under 35 U.S.C. 101 because the claimed invention recites a judicial exception, is directed to that judicial exception, an abstract idea, as it has not been integrated into practical application and the claims further do not recite significantly more than the judicial exception. Examiner has evaluated the claims under the framework provided in the 2019 Patent Eligibility Guidance published in the Federal Register 01/07/2019 and has provided such analysis below. Step 1: Claims 1-11 are directed to systems and fall within the statutory category of machines and Claims 12-20 are directed to methods and fall within the statutory category of processes. Therefore, “Are the claims to a process, machine, manufacture or composition of matter?” Yes. In order to evaluate the Step 2A inquiry “Is the claim directed to a law of nature, a natural phenomenon or an abstract idea?” we must determine, at Step 2A Prong 1, whether the claim recites a law of nature, a natural phenomenon or an abstract idea and further whether the claim recites additional elements that integrate the judicial exception into a practical application. Step 2A Prong 1: Claims 1 and 12 as drafted, recite a process that, under its broadest reasonable interpretation, covers steps that could reasonably be performed in the mind, including with the aid of pen and paper, but for the recitation of generic computer components. That is, the limitations: a) “ a data manager configured to automatically obtain and store information indicative of change, testing, and release of a software package; – Mental processes (see MPEP 2106.04(a)(2), III), this limitation can be reasonable performed by a human mind, wherein a person can manage data in paper providing data about changes in a software package. b) “ a releaser configured to automatically generate the information indicative of the release of the software package for each release of the software package; ” – Mental processes (see MPEP 2106.04(a)(2), III), this limitation can be reasonable performed by a human mind, wherein a person is create/generate data for a software release. That is, nothing in the claim elements precludes the step from practically being performed in the mind or with a pen and paper, (i.e., “ obtain ” and, “ generate ”) can be performed in the human mind though observation, evaluation, judgment, opinion with the aid of pen and paper. Thus, these limitations fall within the “Mental Processes” grouping of abstract ideas. Therefore, Yes , claims 1 and 12 recite judicial exceptions. The claims have been identified to recite judicial exceptions, Step 2A Prong 2 will evaluate whether the claims are directed to the judicial exception. Step 2A Prong 2: This judicial exception is not integrated into a practical application. The claims recite the following additional elements: “ a data manager ”, “ a software release manager ”, “ a releaser ” and “ a dashboard manager ”. The additional elements are merely instructions to implement an abstract idea on a computer, or merely using a generic computer or computer components as a tool to perform the abstract idea (see MPEP 2106.05(f)). Accordingly, the additional elements recited in the claims do not integrate the abstract idea into a practical application because it does not impose any meaningful limits on practicing the abstract idea, thus failing to integrate the abstract idea into a practical application. There are additional elements in the claim such as: a) “ provide a user interface for an authorized user to access the stored information indicative of change, testing, and release of the software package.” . However as drafted, this element is considered mere instruction to apply an exemption using a computer (see MPEP 2106.05(f). b) “ store information indicative of change, testing, and release of a software package; ”. However as drafted, this element is considered mere instruction to apply an exemption using a computer (see MPEP 2106.05(f)(2). Therefore, “Do the claims recite additional elements that integrate the judicial exception into a practical application? No , these additional elements do not integrate the abstract idea into a practical application and they do not impose any meaningful limits on practicing the abstract idea. The claim is directed to an abstract idea. After having evaluating the inquires set forth in Steps 2A Prong 1 and 2, it has been concluded that claims 1 and 12 not only recites a judicial exception but that the claim is directed to the judicial exception as the judicial exception has not been integrated into practical application. Step 2B: As discussed above with respect to integration of the abstract idea into a practical application, the additional elements: “ a data manager ”, “ a software release manager ”, “ a releaser ” and “ a dashboard manager ” are generic computer components used as tools to perform the abstract idea. Accordingly, the additional elements recited in the claims cannot provide an inventive concept. In addition, after further evaluation the claim as a whole doesn’t improve any function of a computer or to any other technology or technical field. Thus, the claims are not patent eligible. The additional element “ obtain and store information indicative of change, testing, and release of a software package; ” is also considered a well-understood, routine, conventional activity (see MPEP 2106.05(d),II,iv “storing information”). Therefore, “Do the claims recite additional elements that amount to significantly more than the judicial exception? No , these additional elements, alone or in combination, do not amount to significantly more than the judicial exception. Having concluded analysis within the provided framework, Claims 1 and 12 do not recite patent eligible subject matter under 35 U.S.C. § 101 . As to claims 2-11 and 13-20 , the features of these claims do not add any additional elements integrating the abstract idea into a practical application or amounting to significantly more at least because these claims add no additional elements beyond those already addressed above with respect to claim and otherwise only further describe the abstract idea itself, specifically encompasses mere instructions to apply the exception. Therefore, Claims 1-20 do not recite patent eligible subject matter under 35 U.S.C. § 101. Claim Rejections - 35 USC § 102 07-07-aia AIA 07-07 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 – 07-08-aia AIA (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. 07-15 AIA Claim s 1-7 and 10-18 are rejected under 35 U.S.C. 102( a)(1 ) as being anticipated by Hawrylo et al. (US Pub. No. 2019/0129701 – hereinafter Hawrylo) . With respect to claim 1, Hawrylo teaches a software release manager (SRM) implemented in a computing device, the SRM comprising: a data manager configured to automatically obtain and store information indicative of change, testing, and release of a software package (See paragraph [0005], “ Conventional software release and deployment models rely on a variety of software tools that provide release information (e.g., information pertaining to code development, various testing, etc.), revision tracking, status, various reports and messages, which software components are involved or affected by a particular release, which artifacts are needed or affected by a specific release, which features are newly introduced or revised, whether a revised feature is still compatible with the remaining portion of the software application, approval status, etc. ”. See paragraphs [0021], [0081], “ a release activity or first information pertaining to the release and one or more version identifiers or one or more common identifiers pertaining to the release activity or the first information may be identified. Moreover, a set of artifacts or code modules that has been branched into a boxset may be identified based in part or in whole upon the one or more version identifiers or the one or more common identifiers; and identifiers or synonyms of the set of artifacts or code modules may also be identified from a database that is managed by a release resource module and maintains detailed information of the release. ”. See paragraph [0130], “ In these embodiments, pertinent information may be identified at 202B for a software application or a portion thereof. Such pertinent information may include, any information pertaining to the software application or a portion thereof. For example, an artifact, a code module or segment, a release activity, references (e.g., pointers, link structures, symbolic links, uniform resource locators, uniform resource identifiers, etc.) to contents therein or information therefor (e.g., specification, release notes, test results, etc.), database scripts, schemas, global and local configurations and properties, documentation, platform specific objects (e.g., objects such as class files and resources for a Java-based integration framework such as Apache Mule, a Web server environment, etc.), or any tangible byproducts produced during the development of the software application, etc., regardless of whether such pertinent information is releasable, non-releasable, deployable, or non-deployable. ”. See paragraphs [0099], [0104], [0113], [0198], [0203], [0206], “ As described above with reference to FIG. 3A, the pertinent information may be identified with various modules described herein such as one or more of the modules described in FIGS. 1A-1C and 2A-2T. Moreover, some examples of such pertinent information may include references (e.g., pointers, link structures, symbolic links, uniform resource locators, uniform resource identifiers, etc.) to contents therein or information therefor (e.g., specification, release notes, test results, etc.), database scripts, schemas, global and local configurations and properties, documentation, platform specific objects (e.g., objects such as class files and resources for a Java-based integration framework such as Apache Mule, a Web server environment, etc.), or any tangible byproducts produced during the development of the software application, etc., regardless of whether such pertinent information is releasable, non-releasable, deployable, or non-deployable. ”. Furthermore, see figures 5A-5U (and related text). Examiner notes: stored information about a release (e.g., release activities, i.e., artifact, feature, components, code segment, specification, test, etc.). a releaser configured to automatically generate the information indicative of the release of the software package for each release of the software package (See paragraphs [0017], [0032], [0060]-[0062], [0068], [0083], [0102], [0127]-[0128], [0202] and figures 1, 4A (and related text), “ a method for automating the release and deployment of a software application delivery model at least by tracking and moving the software application along the pipeline for the continuous release and deployment of the software application delivery model. In these embodiments, these techniques identify a release and pertinent information thereof for a software application delivery model and determine dependencies among at least some of the pertinent information. ”. Examiner notes: automating the release and deployment of a software application delivery model at least by tracking and moving the software application along the pipeline for the continuous release and deployment of the software application delivery model) and a dashboard manager configured to provide a user interface for an authorized user to access the stored information indicative of change, testing, and release of the software package (See figures 5A-5U (and related text) and paragraphs [0223], [0227], [0254], dashboard manager used by an authorized user). With respect to claim 2, Hawrylo teaches the SRM further comprising: a notifier configured to automatically notify configured recipients about the information indicative of change, testing, or release of the software package in response to a configured notification trigger (See paragraphs [0060], [0063]-[0066], [0082], [0102], [0153], [202], ” Moreover, the integrated platform may intelligently determine the dependency and perform intelligent decision making among various stages of the eventual software release and programmatically generate and transmit messages, e-mails, or any suitable forms of notifications together with other pertinent information to relevant parties. ”). With respect to claim 3, Hawrylo teaches wherein the information indicative of change, testing, and release of the software package is indicative of change, testing, and release of components in the software package (See paragraph [0005], “ Conventional software release and deployment models rely on a variety of software tools that provide release information (e.g., information pertaining to code development, various testing, etc.), revision tracking, status, various reports and messages, which software components are involved or affected by a particular release, which artifacts are needed or affected by a specific release, which features are newly introduced or revised, whether a revised feature is still compatible with the remaining portion of the software application, approval status, etc. ”. See paragraphs [0021], [0081], “ a release activity or first information pertaining to the release and one or more version identifiers or one or more common identifiers pertaining to the release activity or the first information may be identified. Moreover, a set of artifacts or code modules that has been branched into a boxset may be identified based in part or in whole upon the one or more version identifiers or the one or more common identifiers; and identifiers or synonyms of the set of artifacts or code modules may also be identified from a database that is managed by a release resource module and maintains detailed information of the release. ”. See paragraph [0130], “ In these embodiments, pertinent information may be identified at 202B for a software application or a portion thereof. Such pertinent information may include, any information pertaining to the software application or a portion thereof. For example, an artifact, a code module or segment, a release activity, references (e.g., pointers, link structures, symbolic links, uniform resource locators, uniform resource identifiers, etc.) to contents therein or information therefor (e.g., specification, release notes, test results, etc.), database scripts, schemas, global and local configurations and properties, documentation, platform specific objects (e.g., objects such as class files and resources for a Java-based integration framework such as Apache Mule, a Web server environment, etc.), or any tangible byproducts produced during the development of the software application, etc., regardless of whether such pertinent information is releasable, non-releasable, deployable, or non-deployable. ”. See paragraphs [0099], [0104], [0113], [0198], [0203], [0206], “ As described above with reference to FIG. 3A, the pertinent information may be identified with various modules described herein such as one or more of the modules described in FIGS. 1A-1C and 2A-2T. Moreover, some examples of such pertinent information may include references (e.g., pointers, link structures, symbolic links, uniform resource locators, uniform resource identifiers, etc.) to contents therein or information therefor (e.g., specification, release notes, test results, etc.), database scripts, schemas, global and local configurations and properties, documentation, platform specific objects (e.g., objects such as class files and resources for a Java-based integration framework such as Apache Mule, a Web server environment, etc.), or any tangible byproducts produced during the development of the software application, etc., regardless of whether such pertinent information is releasable, non-releasable, deployable, or non-deployable. ”. Furthermore, see figures 5A-5U (and related text). Examiner notes: stored information about a release (e.g., release activities, i.e., artifact, feature, components, code segment, specification, test, etc.). With respect to claim 4, Hawrylo teaches wherein the software package is developed in a software package development process associated with the SRM (See paragraph [0071], “ a development tenant (DEV) 100A1 that performs the build verification test for a software application delivery model. The plurality of tenants 100A may also include the continuous development tenant (CDEV) 100A2 that performs the continuing build verification test for a software application delivery model; a quality assurance tenant 100A3 (QA) that performs functions such as the build acceptance test, component automation, etc. to ensure that the software application delivery model meets the defined quality level; a performance tenant 100A4 that (PERF) performs component performance test, etc. to ensure that components perform as designed or intended. ” and wherein the association comprises hooks in the software package development process causing automated reporting of the information indicative of change of components in the software package to the data manager (See at least figure 2T (and related text), development modules 206 and paragraphs [0223]-[0224], “ The identification of each branch is also subject to the control and management of the branch management module 204M so that possible conflicts may be eliminated, and versioning of any aspects of the software application may be under control. These identifications of branches may be stored in a branching repository (not shown) that is also accessible by the release management module 202M and the one or more code development modules 206M for integration with the branch management module 204M as well as the deployment modules (e.g., the continuous deployment dashboard 212M, the enterprise continuous deployment module 214M, etc.) The branch management module 204M may track some or all deployable or non-deployable artifacts and function in tandem with the release management module 202M to fill or augment the boxset (e.g., 250M) to include everything (e.g., artifacts) to support a deployment. ”. See paragraph [0228]-[0230], [0271], “ The enterprise continuous deployment module 214M includes a module that enables developers to integrate various pieces of artifacts into a shared repository (e.g., the deployment repository 210M or the code repository 208M). The enterprise continuous deployment module 214M verifies each check-in of pieces of artifacts by an automated build, execution of individual component tests, and/or code coverage thresholds allowing multiple teams or members to detect problems with the software application early. ”). With respect to claim 5, Hawrylo teaches wherein the releaser comprises an approval manager configured to automatically manage the release of the software package comprising managing an approval process to obtain approval of the software package from the configured recipients (See figure 5N (and related text) and paragraph [0291], “ FIG. 5N illustrates an example user interface for the screen of the release resource center module 500N. In addition to the information illustrated in FIGS. 5L-5M, this example illustrated in FIG. 5N shows that the release resource center module may automatically, autonomously, or programmatically populate the screen with additional information including, for example, approver information 502N. This additional approver information 502N may include a list of approvers of various release activities initiated by a logged-in tenant, the respective states 504N for each listed item, the respective approvers 506N, the respective tenants 508N who opened the release activities, the respective due dates of the release activities 510N, the respective short descriptions 512N, the respective configuration item(s) 514N, and the respective date and time information 516N for the listed release activities. ”). With respect to claim 6, Hawrylo teaches wherein the releaser comprises a compliance checker configured to automatically determine whether components in the software package comply with configured release criteria (See paragraph [0193], “ On the other hand, if the transformed data model determines at 220E that the pertinent information may now be deterministically classified into one or more classes with sufficiently high confidence level, the one or more classes may be determined by the transformed data model. In some embodiments, the transformed data model applies a plurality of hierarchical checks to a series of terms, patterns, and/or relations of the pertinent information. These one or more classes may be optionally ranked at 222E into one or more ranked classes based in part or in whole upon, for example, their respective confidence levels, scores from compliance with or violation of the plurality of hierarchical checks, etc. ”). With respect to claim 7, Hawrylo teaches wherein the releaser comprises a change log generator configured to automatically maintain a history of changes to components in the software package (See paragraph [0276], “ Some examples of project information that may be generated or retrieved by the information generation and retrieval module 206T may include, for example, change log information, cross referenced sources, dependency lists, or any other desired or required information. ”). With respect to claim 10, Hawrylo teaches wherein the releaser comprises a package deployer configured to automatically deploy the released software package to configured destinations (See paragraph [0248], “ One or more target platforms or environments for the deployment of the release of the software application may be identified at 206O. For example, a Java-based integration framework, a Web server environment, a development environment, a quality check environment, a manufacturing environment, and/or one or more testing environments may be identified at 206O. These one or more target platforms or environments may be referenced in generating platform- or environment-specific boxsets from the boxset generated at 204O. ”). With respect to claim 11, Hawrylo teaches wherein the data manager is configured to automatically obtain and store information indicative of change, testing, and release of each of a plurality of software packages (See paragraph [0005], “ Conventional software release and deployment models rely on a variety of software tools that provide release information (e.g., information pertaining to code development, various testing, etc.), revision tracking, status, various reports and messages, which software components are involved or affected by a particular release, which artifacts are needed or affected by a specific release, which features are newly introduced or revised, whether a revised feature is still compatible with the remaining portion of the software application, approval status, etc. ”. See paragraphs [0021], [0081], “ a release activity or first information pertaining to the release and one or more version identifiers or one or more common identifiers pertaining to the release activity or the first information may be identified. Moreover, a set of artifacts or code modules that has been branched into a boxset may be identified based in part or in whole upon the one or more version identifiers or the one or more common identifiers; and identifiers or synonyms of the set of artifacts or code modules may also be identified from a database that is managed by a release resource module and maintains detailed information of the release. ”. See paragraph [0130], “ In these embodiments, pertinent information may be identified at 202B for a software application or a portion thereof. Such pertinent information may include, any information pertaining to the software application or a portion thereof. For example, an artifact, a code module or segment, a release activity, references (e.g., pointers, link structures, symbolic links, uniform resource locators, uniform resource identifiers, etc.) to contents therein or information therefor (e.g., specification, release notes, test results, etc.), database scripts, schemas, global and local configurations and properties, documentation, platform specific objects (e.g., objects such as class files and resources for a Java-based integration framework such as Apache Mule, a Web server environment, etc.), or any tangible byproducts produced during the development of the software application, etc., regardless of whether such pertinent information is releasable, non-releasable, deployable, or non-deployable. ”. See paragraphs [0099], [0104], [0113], [0198], [0203], [0206], “ As described above with reference to FIG. 3A, the pertinent information may be identified with various modules described herein such as one or more of the modules described in FIGS. 1A-1C and 2A-2T. Moreover, some examples of such pertinent information may include references (e.g., pointers, link structures, symbolic links, uniform resource locators, uniform resource identifiers, etc.) to contents therein or information therefor (e.g., specification, release notes, test results, etc.), database scripts, schemas, global and local configurations and properties, documentation, platform specific objects (e.g., objects such as class files and resources for a Java-based integration framework such as Apache Mule, a Web server environment, etc.), or any tangible byproducts produced during the development of the software application, etc., regardless of whether such pertinent information is releasable, non-releasable, deployable, or non-deployable. ”. Furthermore, see figures 5A-5U (and related text). Examiner notes: stored information about a release (e.g., release activities, i.e., artifact, feature, components, code segment, specification, test, etc.). wherein the releaser is configured to automatically generate the information indicative of the release of each of the plurality of software packages for each release of each of the plurality of software packages (See paragraphs [0017], [0032], [0060]-[0062], [0068], [0083], [0102], [0127]-[0128], [0202] and figures 1, 4A (and related text), “ a method for automating the release and deployment of a software application delivery model at least by tracking and moving the software application along the pipeline for the continuous release and deployment of the software application delivery model. In these embodiments, these techniques identify a release and pertinent information thereof for a software application delivery model and determine dependencies among at least some of the pertinent information. ”. Examiner notes: automating the release and deployment of a software application delivery model at least by tracking and moving the software application along the pipeline for the continuous release and deployment of the software application delivery model) and wherein the dashboard manager is configured to provide a user interface for an authorized user to access the stored information indicative of change, testing, and release of each of the plurality of software packages (See figures 5A-5U (and related text) and paragraphs [0223], [0227], [0254], dashboard manager used by an authorized user). With respect to claims 12-18, the claims are directed to a method that corresponds to the method recited in claims 1-7, respectively (see the rejection of claims 1-7 above) . Claim Rejections - 35 USC § 103 07-20-aia AIA 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. 07-23-aia AIA The factual inquiries 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. 07-21-aia AIA Claim s 8 and 19 are rejected under 35 U.S.C. 103 as being unpatentable over Hawrylo et al. (US Pub. No. 2019/0129701) in view of Gregorovic et al. (US Pat. No. 8,838,964 – hereinafter Gregorovic). With respect to claim 8, Hawrylo is silent to disclose, however, in an analogous art, Gregorovic teaches wherein the dashboard manager comprises a package comparer configured to automatically determine differences between components in different released or pre-released software packages or in different releases of the same software package (See column 7 lines 18-54, “ In another embodiment, the report generation engine 206 can receive subsequent changes detected by the package verification engine 202 to be included in the report. In one embodiment, the report generation engine 206 generates a report that provides a package manifest, the package manifest showing, for example, the subsequent changes to the one or more software packages, such as differences between releases of the software product, or the like. The package manifest may also list the software packages included in the software package release, whether these software packages have been validated by the package audit tool 112, whether these software packages have been approved, as well as whether the software packages have problems that need to be remedied, for example, by a Security Response Team (SRT). In one embodiment, the report generation engine 206 exports a copy of the report to a specified location, such as generating the report as a log file in a specified directory. The copy of the report may be saved in a format that is consumable by the SRT, or alternatively, as a text file. In another embodiment, instead of exporting a copy of the report, the report generation engine 206 can present the results to the administrator via the user interface 204, such as a web page showing the results of the verification process. This user interface 204 may present a list of software packages to the administrator to allow the administrator to approve the software packages for inclusion into the software product release, or allow the software packages to be put on a work queue for a supervisor to approve the package's inclusion in the software product release. The user interface 204 may also receive input from the administrator that specifies which of the software packages should be included in the software product release. In another embodiment, the package verification engine 202 can use a work queue and the notification mechanism 210 to make the administrator aware of package additions submitted for approval, as well as when the package audit tool 112 detects problems with the validation process or when the package audit tool 112 is completed. ”). It would have been obvious to one of ordinary skill in the art at the time the invention was made before the effective filing date of the claimed invention to modify Hawrylo’s teaching which set forth a method that automates the release and deployment of a software application delivery model for the continuous release and deployment of the software application delivery model, with Gregorovic’s teaching which set forth a method for software package auditing, Gregorovic would allow determine if certain information complies with the set of one or more requirements for a software product release (see column 2 lines 15-42) . With respect to claim 19, the claim is directed to a method that corresponds to the method recited in claim 8, respectively (see the rejection of claim 8 above) . 07-21-aia AIA Claim s 9 and 20 are rejected under 35 U.S.C. 103 as being unpatentable over Hawrylo et al. (US Pub. No. 2019/0129701) in view of Tauber et al. (US Pub. No. 2017/0372247 – hereinafter Tauber) . With respect to claim 9, Hawrylo is silent to disclose, however, in an analogous art, Tauber teaches wherein the dashboard manager comprises an aggregator configured to automatically combine information about each component in the software package received from multiple sources or at different times (See paragraph [0018], “ In some embodiments, the branch management module in the system may further include at least one of a snapshot module that is configured to take one or more snapshots of a state of a branch for the software application release upon an invocation of a commit command received from one or more modules operating on the branch; a data verification module that is configured to verify at least a newly created artifact or a modified artifact in the plurality of artifacts upon an invocation of the commit command received from the one or more modules operating on the branch and before storing the newly created artifact or the modified artifact in the at least one persistent code repository; a branching module that is configured to generate a project for the software application release, to create a branch with a common branch identifier, and to initiate a build process for the project with a project object model; a merge module that is configured to merge the newly created artifact or the modified artifact back into the one or more server computers; or an automatic tagging module that is configured to automatically tag at least some artifacts of the plurality artifacts with respective identifiers or package types. ”). It would have been obvious to one of ordinary skill in the art at the time the invention was made before the effective filing date of the claimed invention to modify Hawrylo’s teaching which set forth a method that automates the release and deployment of a software application delivery model for the continuous release and deployment of the software application delivery model, with Tauber’s teaching which set forth a system that develops and manages releases of software applications, Tauber would enhance the management of software releases. With respect to claim 20, the claim is directed to a method that corresponds to the method recited in claim 9, respectively (see the rejection of claim 9 above) . Conclusion 07-96 AIA The prior art made of record and not relied upon is considered pertinent to applicant's disclosure. Eizenman et al. (US Pub. No. 2024/0403199) discloses a system and method for CI/CT/CD, which is continuous integration/continuous testing/continuous delivery, in which testing is fully integrated to the needs of rapid code development and delivery. Such a system and method may also determine a relative importance of a selected test in a plurality of tests, such that the system and method may comprise a computational device for receiving one or more characteristics relating to an importance of the code, an importance of each of the plurality of tests, or both; and for determining the relative importance of the selected test according to said characteristics. (see abstract) . Govindaraju (US Pub. No. 2019/0163616) is directed to automated application-release-management system that provides for efficient check-in of code changes. The application-release-management process is specified, in the described implementation, by application-release-management pipelines, each pipeline comprising one or more stages, with each stage comprising one or more tasks. The application-release-management system provides continuous application delivery through automated code-change reception, automated testing, and automated delivery. The application-release-management system uses an efficient code-change code-change-check-in process carried out by a code-change-check-in subsystem that identifies and executes those testing methods that test code paths that include the modified code. (see abstract). Any inquiry concerning this communication or earlier communications from the examiner should be directed to ANIBAL RIVERACRUZ whose telephone number is (571)270-1200. The examiner can normally be reached Monday-Friday 9:30 AM-6:00 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, Hyung S Sough can be reached at 5712726799. 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. /ANIBAL RIVERACRUZ/Primary Examiner, Art Unit 2192 Application/Control Number: 18/677,516 Page 2 Art Unit: 2192 Application/Control Number: 18/677,516 Page 4 Art Unit: 2192 Application/Control Number: 18/677,516 Page 5 Art Unit: 2192 Application/Control Number: 18/677,516 Page 6 Art Unit: 2192 Application/Control Number: 18/677,516 Page 7 Art Unit: 2192 Application/Control Number: 18/677,516 Page 8 Art Unit: 2192 Application/Control Number: 18/677,516 Page 9 Art Unit: 2192 Application/Control Number: 18/677,516 Page 10 Art Unit: 2192 Application/Control Number: 18/677,516 Page 11 Art Unit: 2192 Application/Control Number: 18/677,516 Page 12 Art Unit: 2192 Application/Control Number: 18/677,516 Page 13 Art Unit: 2192 Application/Control Number: 18/677,516 Page 14 Art Unit: 2192 Application/Control Number: 18/677,516 Page 15 Art Unit: 2192 Application/Control Number: 18/677,516 Page 16 Art Unit: 2192 Application/Control Number: 18/677,516 Page 17 Art Unit: 2192 Application/Control Number: 18/677,516 Page 18 Art Unit: 2192 Application/Control Number: 18/677,516 Page 19 Art Unit: 2192 Application/Control Number: 18/677,516 Page 20 Art Unit: 2192 Application/Control Number: 18/677,516 Page 21 Art Unit: 2192 Application/Control Number: 18/677,516 Page 22 Art Unit: 2192 Application/Control Number: 18/677,516 Page 23 Art Unit: 2192 Application/Control Number: 18/677,516 Page 24 Art Unit: 2192 Application/Control Number: 18/677,516 Page 25 Art Unit: 2192 Application/Control Number: 18/677,516 Page 26 Art Unit: 2192 Application/Control Number: 18/677,516 Page 27 Art Unit: 2192 Application/Control Number: 18/677,516 Page 28 Art Unit: 2192 Application/Control Number: 18/677,516 Page 29 Art Unit: 2192 Application/Control Number: 18/677,516 Page 30 Art Unit: 2192 Application/Control Number: 18/677,516 Page 31 Art Unit: 2192
Read full office action

Prosecution Timeline

May 29, 2024
Application Filed
May 27, 2026
Non-Final Rejection mailed — §101, §102, §103 (current)

Precedent Cases

Applications granted by this same examiner with similar technology

Patent 12748576
Graph Analysis and Manipulation
2y 9m to grant Granted Sep 29, 2026
Patent 12748585
HOT UPGRADE WORKFLOW PROCESS IN AN EDGE COMPUTING ENVIRONMENT
2y 5m to grant Granted Sep 29, 2026
Patent 12743366
TEST SEQUENCE FOR STOP-AT-FIRST-FAIL TESTING
3y 0m to grant Granted Sep 22, 2026
Patent 12724698
Automated Assistive-Technology Driven Accessibility Testing Environments
2y 10m to grant Granted Sep 01, 2026
Patent 12717567
ENHANCED DEVICE UPDATING
3y 8m to grant Granted Aug 25, 2026
Study what changed to get past this examiner. Based on 5 most recent grants.

Strategy Recommendation AI-generated — please review before filing

Get a prosecution strategy drawn from examiner precedents, rejection analysis, and claim mapping.
Typically takes 5-10 seconds — AI-generated, attorney review required before filing

Prosecution Projections

1-2
Expected OA Rounds
91%
Grant Probability
99%
With Interview (+11.9%)
2y 3m (~0m remaining)
Median Time to Grant
Low
PTA Risk
Based on 761 resolved cases by this examiner. Grant probability derived from career allowance rate.

Sign in with your work email

Enter your email to receive a magic link. No password needed.

Personal email addresses (Gmail, Yahoo, etc.) are not accepted.

Free tier: 3 strategy analyses per month