DETAILED ACTION
The Office Action is in response to a Request for Continued Examination filed 1/23/2026.
Claims 1, 3, 5, 10, 12, 16, and 18-19 are currently amended.
Claims 21-24 are newly added claims.
Claims 6, 9, 15, and 20 are currently cancelled.
Claims 1-5, 7-8, 10-14, 16-19, and 21-24 are pending.
The objection of claims 3, 12, and 18 are withdrawn with respect to the amendments to claims 3, 12, and 18 respectively.
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 .
Continued Examination Under 37 CFR 1.114
A request for continued examination under 37 CFR 1.114, including the fee set forth in 37 CFR 1.17(e), was filed in this application after final rejection. Since this application is eligible for continued examination under 37 CFR 1.114, and the fee set forth in 37 CFR 1.17(e) has been timely paid, the finality of the previous Office action has been withdrawn pursuant to 37 CFR 1.114. Applicant's submission filed on 12/22/2025 has been entered.
Claim Rejections - 35 USC § 103
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 (i.e., changing from AIA to pre-AIA ) 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.
The following is a quotation of 35 U.S.C. 103 which forms the basis for all obviousness rejections set forth in this Office action:
A patent for a claimed invention may not be obtained, notwithstanding that the claimed invention is not identically disclosed as set forth in section 102, if the differences between the claimed invention and the prior art are such that the claimed invention as a whole would have been obvious before the effective filing date of the claimed invention to a person having ordinary skill in the art to which the claimed invention pertains. Patentability shall not be negated by the manner in which the invention was made.
The factual inquiries 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.
Claims 1, 10, and 16 are rejected under 35 U.S.C. 103 as being unpatentable over US 20240370316 Al hereinafter “Johnson” in view of US 20140380267 A1 hereinafter “Fiebig” and further in view of US 20190303579 A1 hereinafter “Reddy”.
With regards to claim 1, Johnson teaches A method, comprising:
automatically performing the following steps, in response to an occurrence of a designated event, wherein the designated event comprises obtaining a request (Johnson [0038], “The process of making software changes may involve software change request (SCR) processes. As referenced herein, a software change request (SCR) may include not only the request, but also the software change (e.g., the code, application, and/or specifications corresponding to the software change) [wherein the designated event comprises obtaining a request]. Moreover, while embodiments are disclosed herein with respect to SCRs as an example, is embodiments may likewise be applicable to initial code deployments and not just the software changes that follow initial code deployments [in response to an occurrence of a designated event].”) to add at least one software item to one or more stages of a software deployment pipeline, wherein the at least one software item is obtained from a designated software repository: (Johnson [0043-44], “The pipeline services may include pipeline deployment agents of the pipeline infrastructure 102 that may include software applications to automate software deployment and software changes deployment through various stages to production services corresponding to a production deployment 255. Such automation of software and software change deployments may include continuously integrating software, configuration states, scripts, artifacts, and or the like into production services corresponding to production deployment 255 [to add at least one software item to one or more stages of a software deployment pipeline]. The pipeline deployment agents may facilitate the deployment pipeline in stages that may include preproduction stages, where the developed software may be automatically tested … With one or more of the preproduction stages, the pipeline deployment agents may build executables (e.g., applications, code segments, etc.) of the software and software changes from a source code repository 265 (e.g., software repository system 103), which may store the software and software change specifications provided in part by the developers.”)
wherein the method is performed by the at least one processing device comprising a processor coupled to a memory. (Johnson [0069], “As shown in FIG. 8, computer system 800 includes various subsystems including a processing subsystem 804 that communicates with a number of other subsystems via a bus subsystem 802. These other subsystems may include a processing acceleration unit 806, an I/O subsystem 808, a storage subsystem 818, and a communications subsystem 824. Storage subsystem 818 may include non-transitory computer-readable storage media including storage media 822 and a system memory 810.”)
Johnson does not teach: automatically determining, by at least one processing device, an approval status of the obtained at least one software item for inclusion in at least one of the one or more stages of the software deployment pipeline based, at least in part, on an evaluation of one or more designated properties of the obtained at least one software item relative to one or more designated criteria
However, in an analogous art Fiebig teaches automatically determining, by at least one processing device, an approval status of the obtained at least one software item for inclusion in at least one of the one or more stages of the software deployment pipeline (Fiebig [0042], “In certain embodiments, conditional approvals can be implemented by extending the definition of an approval process beyond just accepting rejecting a requested lifecycle transition. More flexibility can be achieved by allowing the approver to decide on the target lifecycle state for a requested lifecycle transition [for inclusion in at least one of the one or more stages of the software deployment pipeline]. If the target lifecycle state can be chosen by an approver, conditional approvals can be implemented by introducing additional lifecycle states with additional transitions to the target state. These transitions can be annotated with policies governing the final lifecycle state transitions. One advantage of this approach is that the status of the approval is indicated properly when looking at the asset [automatically determining, by at least one processing device, an approval status of the obtained at least one software item].”) based, at least in part, on an evaluation of one or more designated properties of the obtained at least one software item relative to one or more designated criteria, (Fiebig [0044], “Moreover, events and event stream consuming policies can be used [relative to one or more designated criteria] in certain embodiments to combine conditional approvals with runtime and/or design-time monitoring of SOA and/or API management assets [an evaluation of one or more designated properties of the obtained at least one software item]. To address the previously described use cases, it is assumed that events channels transport test result events generated by testing tools and/or runtime invocation events generated by runtime policy enforcement points. Based on this event driven approach, other development and/or governance tooling can be easily combined with conditional approvals.”) [Examiner’s Note: A lifecycle state may correspond to one or more stages of a deployment pipeline. By approval of a software asset, the asset can transition and thereby be incorporated into the pipeline]
Therefore, it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to have incorporated the teachings of Fiebig into the teachings of Johnson. This combination of teachings would have resulted in a method configured to obtain a trigger event from a request to automatically integrate software into deployment, as in Johnson, while making a determination of approval based on various quality control criteria, as in Fiebig. One of ordinary skill in the art would have been motivated to combine these teachings for the purpose of managing the lifecycle of computing components between lifecycle states under conditional approvals (Fiebig [0040]).
The combination of Johnson and Fiebig does not teach: wherein the automatically determining the approval status of the obtained at least one software item comprises automatically evaluating whether the at least one software item can be added [to the at least one of the one or more stages of the software deployment pipeline] under at least one license covering the at least one software item; and
automatically initiating, [by the at least one processing device,] one or more automated actions, with respect to at least one stage of the software deployment pipeline, based, at least in part, on at least one result of the automatic determination, wherein the one or more automated actions are implemented [by the at least one processing device and] comprise one or more of failing a validation of one or more of the stages of the software deployment pipeline , initiating a designated review process and preventing a promotion of the software deployment pipeline to a next stage;
However, in an analogous art Reddy teaches wherein the automatically determining the approval status of the obtained at least one software item comprises automatically evaluating whether the at least one software item can be added (Reddy [0057-58], “In various portions of the lifecycle 30, a software asset may be subject to auditing, as indicated by block 46 [wherein the automatically determining the approval status of the obtained at least one software item]. Various examples of audits are described below, and in some cases, audits may be triggered upon changes in versions of the software asset, periodic expirations of time, changes in policies or regulations, changes in use cases, or the like. In some embodiments, the lifecycle includes deployment of the software asset, as indicated by block 48, which in some cases may include modifying compose files to reference the software asset, modifying manifests to references software asset in other software assets, adding the software asset to machine images for virtual machines, adding the software asset the container images, adding the software asset to an inventory of software assets managed by a configuration management application or orchestration tool, or the like [comprises automatically evaluating whether the at least one software item can be added]”) [to the at least one of the one or more stages of the software deployment pipeline] under at least one license covering the at least one software item; (Reddy [0176], “Various types of audits may be performed and documented in trust records. Examples include security audits, software license audits, audits regarding software development practices, audits for compliance with various policies of an organization, audits regarding compliance with standards set by standard-setting bodies, audits regarding compliance with various regulations, and audits regarding compliance with various laws. For instance, an audit may indicate whether a software asset complies with license requirements of an open source license, violates an allocation of seats in a commercial software license, or exceeds a number of process threads, transactions, or processors afforded by a commercial software license [under at least one license covering the at least one software item].”) and
automatically initiating, [by the at least one processing device,] one or more automated actions, with respect to at least one stage of the software deployment pipeline, based, at least in part, on at least one result of the automatic determination, wherein the one or more automated actions are implemented [by the at least one processing device and] comprise one or more of failing a validation of one or more of the stages of the software deployment pipeline (Reddy [0191], “In some embodiments, results may be logged, and in the event of an audit requirement failing to be met [comprise one or more of failing a validation of one or more of the stages of the software deployment pipeline], an alarm may be emitted, execution of the software asset may be blocked, inclusion of the software asset in a virtual machine image or container image may be blocked, or the set of computing environments in which the software asset is deployed may be constrained, e.g., the software asset may be excluded from a walled-garden repository of software assets [automatically initiating … one or more automated actions with respect to at least one stage of the software deployment pipeline,].”), initiating a designated review process (Reddy [0199], “In some cases, for some types of alerts, such as reports of vulnerabilities or bugs, an entity providing the software asset may host a bug bounty or vulnerability bounty program with the alert smart contract. For instance, some embodiments may receive proposed alerts from the public with the smart contract and then require a second entity, e.g., a developer of the entity operating the program, to review and confirm the alert before the alert is issued [initiating a designated review process]. In some cases, the process may verify that an authorized entity has cryptographically signed a verification of the alert upon reviewing such a submission.“) and preventing a promotion of the software deployment pipeline to a next stage; (Reddy [0154], “Additionally or alternatively, some embodiments may output the result of the determination to the participating entity computing device or other participating entity computing devices corresponding to the other components of the computing environment 70 described above. For example, various software development tooling used in the next stage may receive the output and that output may cause that software development tooling to transform the software asset in accordance with the next stage upon being promoted (or block the transformation in the alternative) [and preventing a promotion of the software deployment pipeline to a next stage]. In some embodiments, a current stage of a software asset may be recorded as a trust assertion in the above-described trust records. In some embodiments, the sequence of stages and stages responsive to failure criteria may be specified in the promotion policy, and embodiments may interrogate these records to determine the identifier of the next stage or an identifier of a demotion stage corresponding to a given failed trust record.”)
Therefore, it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to have incorporated the teachings of Reddy into the teachings of Johnson in view of Fiebig. This combination of teachings would have resulted in a method configured to obtain a trigger event from a request to automatically integrate software into deployment, as in Johnson, while making a determination of approval based on various quality control criteria, as in Fiebig, wherein the criteria requires that the software item be properly licensed for the stages of a deployment pipeline, as in Reddy. One of ordinary skill in the art would have been motivated to combine these teachings for the purpose of establishing trust and gating determinations regarding advancement or use of a software asset in the software lifecycle (Reddy [0063]).
Claim 10 is directed to an apparatus corresponding to the method limitations as disclosed in claim 1. Thus, claim 10 is rejected for the same reasons set forth in claim 1.
Claim 16 is directed to a non-transitory processor-readable medium corresponding to the method limitations as disclosed in claim 1. Thus, claim 16 is rejected for the same reasons set forth in claim 1.
Claims 2, 11, and 17 are rejected under 35 U.S.C. 103 as being unpatentable over Johnson in view of Fiebig in view of Reddy as applied to claims 1, 10, and 16 above, and further in view of US 20240029023 A1 hereinafter "Cherian".
With regards to claim 2, the rejection of claim 1 is incorporated.
The combination of Johnson, Fiebig, and Reddy does not teach: wherein the software deployment pipeline is associated with a particular product and wherein the one or more designated properties of the at least one software item are specified for the particular product
However, in an analogous art Cherian teaches wherein the software deployment pipeline is associated with a particular product and wherein the one or more designated properties of the at least one software item are specified for the particular product (Cherian [0064], "As mentioned, the develop stage 106 also uses CI/CD functionalities for developing the code associated with the software for which the product story is being written. As shown in pipeline 604-1, this includes a code check-in module 606-1, a code review module 608-1 with a number of files 609-1, a unit testing module 610-1 with test results 611-1, an integration testing module 612-1 with test results 613-1, a code deploy module 614-1, and a build internal and external document (doc) fragment module 616-1.")
Therefore, it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to have incorporated the teachings of Cherian into the teachings of Johnson in view of Fiebig and further in view of Reddy. This combination of teachings would have resulted in a method configured to obtain a trigger event from a request to automatically integrate software into deployment, as in Johnson, while making a determination of approval based on various quality control criteria, as in Fiebig, wherein the criteria requires that the software item be properly licensed for the stages of a deployment pipeline, as in Reddy, with the software deployment pipeline specially defined for particular products as in Cherian. One of ordinary skill in the art would have been motivated to combine these teachings for the purpose of using processing elements to generate code as part of an associated software product while developing and testing accordingly (Cherian [0004]).
Claim 11 is directed to an apparatus corresponding to the method limitations as disclosed in claim 2. Thus, claim 11 is rejected for the same reasons set forth in claim 2.
Claim 17 is directed to a non-transitory processor-readable medium corresponding to the method limitations as disclosed in claim 2. Thus, claim 17 is rejected for the same reasons set forth in claim 2.
Claims 3, 12, and 18 are rejected under 35 U.S.C. 103 as being unpatentable over Johnson in view of Fiebig in view of Reddy as applied to claims 1, 10, and 16 above, and further in view of US 20240345904 A1 hereinafter "Teja”.
With regards to claim 3, the rejection of claim 1 is incorporated.
The combination of Johnson, Fiebig, and Reddy does not teach: wherein the one or more designated properties of the at least one software item comprise one or more of a version of the at least one software item and an approval status of the at least one software item
However, in an analogous art Teja teaches wherein the one or more designated properties of the at least one software item comprise one or more of a version of the at least one software item and an approval status of the at least one software item (Teja [0040], “Additionally, the software development system 105 can have at least one associated database 106 configured to store data pertaining to, for example, software code 107 of at least one application and a repository of one or more job log errors 108. For example, at least a portion of the at least one associated database 106 may correspond to at least one code repository that stores the software code 107 [wherein the one or more designated properties of the at least one software item comprise one or more of a version of the at least one software item]. In such an example, the at least one code repository may include different snapshots or versions of the software code 107, at least some of which can correspond to different branches of the software code 107 used for different development environments (e.g., one or more testing environments, one or more staging environments, and/or one or more production environments).”) (Teja [0051], “Finally, a validation and compliance stage 250 comprises the steps to validate a deployment, for example, based at least in part on the needs of a given organization. For example, image security scanning tools may be employed to ensure a quality of the deployed images by comparing them to known vulnerabilities, such as those known vulnerabilities in a catalog of common vulnerabilities and exposures (CVEs).”)
Therefore, it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to have incorporated the teachings of Teja into the teachings of Johnson, Fiebig, and Reddy. This combination of teachings would have resulted in a method configured to obtain a trigger event from a request to automatically integrate software into deployment, as in Johnson, while making a determination of approval based on various quality control criteria, as in Fiebig, wherein the criteria requires that the software item be properly licensed for the stages of a deployment pipeline, as in Reddy, wherein the approval status is dependent upon software versions, as in Teja. One of ordinary skill in the art would have been motivated to combine these teachings for the purpose of allowing development teams to merge and verify changes and passing successfully tested code to the production environment (Teja [0019]).
Claim 12 is directed to an apparatus corresponding to the method limitations as disclosed in claim 3. Thus, claim 12 is rejected for the same reasons set forth in claim 3.
Claim 18 is directed to a non-transitory processor-readable medium corresponding to the method limitations as disclosed in claim 2. Thus, claim 18 is rejected for the same reasons set forth in claim 3.
Claims 4 and 19 are rejected under 35 U.S.C. 103 as being unpatentable over Johnson in view of Fiebig in view of Reddy as applied to claims 1 and 16 above, and further in view of US 8359655 hereinafter "Pham".
With regards to claim 4, the rejection of claim 1 is incorporated.
The combination of Johnson, Fiebig, and Reddy does not teach: further comprising obtaining a classification of the at least one software item into one or more of a plurality of designated license categories obtaining one or more license guidelines associated with the one or more designated license categories
However, in an analogous art Pham teaches further comprising obtaining a classification of the at least one software item into one or more of a plurality of designated license categories (Pham Column 4 Lines 22-60, "The source code [at least one software item] indexed in the code datastore 122 may be broken into constituent parts (e.g., files, objects, lines of code, etc.) and may be associated with a license under which the source code is distributed An identification of a website or other repository for retrieving information (e.g., downloads, updates, license, etc.) As such, the classification engine 110 may identify one or more licenses and classifications associated therewith using the code datastore 122 and/or the license datastore [further comprising obtaining a classification. into one or more of a plurality of designated license categories]")
obtaining one or more license guidelines associated with the one or more designated license categories (Pham Column 5 Lines 18-23, "The defined interface used by the code/license sources 118A 118n may be a structured XML ( eXtensible Markup Language) interface that enables code/license sources 118A 118n to provide software code, license terms, attribution terms, other restrictions/uses, patent information, etc. to the software recognition engine 102")
Therefore, it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to have incorporated the teachings of Pham into the teachings of Johnson in view of Fiebig and further in view of Reddy. This combination of teachings would have resulted in a method configured to obtain a trigger event from a request to automatically integrate software into deployment, as in Johnson, while making a determination of approval based on various quality control criteria, as in Fiebig, wherein the criteria requires that the software item be properly licensed for the stages of a deployment pipeline, as in Reddy, and obtaining software item classifications with licensing to determine guidelines for its integration, as in Pham. One of ordinary skill in the art would have been motivated to combine these teachings for the purpose of using the classification to generate a report that could indicate the risk of uploading software into a larger code base or project (Pham Abstract).
Claim 19 is directed to a non-transitory processor-readable storage medium corresponding to the method limitations as disclosed in claim 4. Thus, claim 19 is rejected for the same reasons set forth in claim 4.
Claims 5, 13, and 23 are rejected under 35 U.S.C. 103 as being unpatentable over Johnson in view of Fiebig in view of Reddy as applied to claims 1, 10, and 16 above, in view of Pham and further in view of US 20230169170 A1 hereinafter "Yaron".
With regards to claim 5, the rejection of claim 4 is incorporated.
The combination of Johnson, Fiebig, and Reddy does not teach: wherein the metadata [for the at least one software item] is based at least in part on the one or more designated license categories
However, in an analogous art Pham teaches wherein the metadata [for the at least one software item] is based at least in part on the one or more designated license categories (Pham Column 4 Lines 30-57, "The code datastore 122 and the license datastore 124 may be implemented as one datastore. In some implementations, the code datastore 122 and/or license datastore 124 may store and track information such as: An identifier of an open source product. A product version. A publisher/manufacturer. A company product( s) and subsystem utilizing component (including product version). A file name of the open source product. A license agreement (include license version, if applicable). A class, if known, of the open source (e.g., Class A, B or C). A company product version. A copy of the license agreement. Attribution requirements. Additional information that may be added or supplied by users may include: An identify the source/provider (company developer's name). A described use/purpose. An identified use (e.g., embedded, separate file, or internal development). An identified type ( e.g., library, utility, or development tool). An identification of modifications, if any. An identification of a website or other repository for retrieving information ( e.g., downloads, updates, license, etc.)") [ Examiner's Note: Pham teaches the at least one software item in Claim 4]
Therefore, it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to have incorporated the teachings of Pham into the teachings of Johnson in view of Fiebig and further in view of Reddy. This combination of teachings would have resulted in a method configured to obtain a trigger event from a request to automatically integrate software into deployment, as in Johnson, while making a determination of approval based on various quality control criteria, as in Fiebig, wherein the criteria requires that the software item be properly licensed for the stages of a deployment pipeline, as in Reddy, and obtaining software item classifications with licensing to determine guidelines for its integration, as in Pham. One of ordinary skill in the art would have been motivated to combine these teachings for the purpose of using the classification to generate a report that could indicate the risk of uploading software into a larger code base or project (Pham Abstract).
The combination of Johnson, Fiebig, Reddy, and Pham does not teach: further comprising adding metadata to a manifest of software items associated with a given stage of the software deployment pipeline,
However, in an analogous art Yaron teaches further comprising adding metadata to a manifest of software items associated with a given stage of the software deployment pipeline, (Yaron [0091], “At S610, software development pipeline data is accessed or otherwise obtained. The software development pipeline data may be, for example, software development
lifecycle (SDLC) pipeline data (e.g., data of a continuous integration [CI] and continuous
delivery [CD] pipeline) [associated with a given stage of the software deployment pipeline].
Such SDLC data may include, but is not limited to, a pipeline configuration, a pipeline
definition, build scripts and other scripts used in the pipeline ( e.g., deployment scripts,
validation scripts, testing scripts, etc.), source code, logs, manifests, metadata, combinations
thereof, portions thereof, and the like [to a manifest of software items]. In some embodiments,
the software development pipeline data may be accessed using computing interface permissions
provided by an operator of the software development pipeline. The accessed software
development pipeline may be, but is not limited to, data stored in a source control, data retrieved
via an API, data uploaded by a user for analysis, combinations thereof, and the like. [further
comprising adding metadata]")
Therefore, it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to have incorporated the teachings of Yaron into the teachings of Johnson in view of Fiebig in view of Reddy and further in view of Pham. This combination of teachings would have resulted in a method configured to obtain a trigger event from a request to automatically integrate software into deployment, as in Johnson, while making a determination of approval based on various quality control criteria, as in Fiebig, wherein the criteria requires that the software item be properly licensed for the stages of a deployment pipeline, as in Reddy, and obtaining software item classifications with licensing to determine guidelines for its integration, as in Pham, and adding metadata that can define a software item in any stage of the pipeline, as in Yaron. One of ordinary skill in the art would have been motivated to combine these teachings for the purpose of analyzing the software for the root cause of potential vulnerabilities and generating a fix action plan with a plurality of alerts (Yaron [0018]).
With regards to claim 13, the rejection of claim 10 is incorporated.
The combination of Johnson, Fiebig, and Reddy does not teach: further comprising obtaining a classification of the at least one software item into one or more of a plurality of designated license categories; and obtaining one or more license guidelines associated with the one or more designated license categories
wherein the metadata [for the at least one software item] is based at least in part on the one or more designated license categories
However, in an analogous art Pham teaches further comprising obtaining a classification of the at least one software item into one or more of a plurality of designated license categories (Pham Column 4 Lines 22-60, "The source code [at least one software item] indexed in the code datastore 122 may be broken into constituent parts (e.g., files, objects, lines of code, etc.) and may be associated with a license under which the source code is distributed An identification of a website or other repository for retrieving information (e.g., downloads, updates, license, etc.) As such, the classification engine 110 may identify one or more licenses and classifications associated therewith using the code datastore 122 and/or the license datastore [further comprising obtaining a classification. into one or more of a plurality of designated license categories]")
obtaining one or more license guidelines associated with the one or more designated license categories (Pham Column 5 Lines 18-23, "The defined interface used by the code/license sources 118A 118n may be a structured XML ( eXtensible Markup Language) interface that enables code/license sources 118A 118n to provide software code, license terms, attribution terms, other restrictions/uses, patent information, etc. to the software recognition engine 102")
wherein the metadata [for the at least one software item] is based at least in part on the one or more designated license categories (Pham Column 4 Lines 30-57, "The code datastore 122 and the license datastore 124 may be implemented as one datastore. In some implementations, the code datastore 122 and/or license datastore 124 may store and track information such as: An identifier of an open source product. A product version. A publisher/manufacturer. A company product( s) and subsystem utilizing component (including product version). A file name of the open source product. A license agreement (include license version, if applicable). A class, if known, of the open source (e.g., Class A, B or C). A company product version. A copy of the license agreement. Attribution requirements. Additional information that may be added or supplied by users may include: An identify the source/provider (company developer's name). A described use/purpose. An identified use (e.g., embedded, separate file, or internal development). An identified type ( e.g., library, utility, or development tool). An identification of modifications, if any. An identification of a website or other repository for retrieving information ( e.g., downloads, updates, license, etc.)") [ Examiner's Note: Pham teaches the at least one software item in Claim 4]
Therefore, it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to have incorporated the teachings of Pham into the teachings of Johnson in view of Fiebig and further in view of Reddy. This combination of teachings would have resulted in a method configured to obtain a trigger event from a request to automatically integrate software into deployment, as in Johnson, while making a determination of approval based on various quality control criteria, as in Fiebig, wherein the criteria requires that the software item be properly licensed for the stages of a deployment pipeline, as in Reddy, and obtaining software item classifications with licensing to determine guidelines for its integration, as in Pham. One of ordinary skill in the art would have been motivated to combine these teachings for the purpose of using the classification to generate a report that could indicate the risk of uploading software into a larger code base or project (Pham Abstract).
The combination of Johnson, Fiebig, Reddy, and Pham does not teach: further comprising adding metadata to a manifest of software items associated with a given stage of the software deployment pipeline,
However, in an analogous art Yaron teaches further comprising adding metadata to a manifest of software items associated with a given stage of the software deployment pipeline, (Yaron [0091], “At S610, software development pipeline data is accessed or otherwise obtained. The software development pipeline data may be, for example, software development
lifecycle (SDLC) pipeline data (e.g., data of a continuous integration [CI] and continuous
delivery [CD] pipeline) [associated with a given stage of the software deployment pipeline].
Such SDLC data may include, but is not limited to, a pipeline configuration, a pipeline
definition, build scripts and other scripts used in the pipeline ( e.g., deployment scripts,
validation scripts, testing scripts, etc.), source code, logs, manifests, metadata, combinations
thereof, portions thereof, and the like [to a manifest of software items]. In some embodiments,
the software development pipeline data may be accessed using computing interface permissions
provided by an operator of the software development pipeline. The accessed software
development pipeline may be, but is not limited to, data stored in a source control, data retrieved
via an API, data uploaded by a user for analysis, combinations thereof, and the like. [further
comprising adding metadata]")
Therefore, it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to have incorporated the teachings of Yaron into the teachings of Johnson in view of Fiebig in view of Reddy and further in view of Pham. This combination of teachings would have resulted in a method configured to obtain a trigger event from a request to automatically integrate software into deployment, as in Johnson, while making a determination of approval based on various quality control criteria, as in Fiebig, wherein the criteria requires that the software item be properly licensed for the stages of a deployment pipeline, as in Reddy, and obtaining software item classifications with licensing to determine guidelines for its integration, as in Pham, and adding metadata that can define a software item in any stage of the pipeline, as in Yaron. One of ordinary skill in the art would have been motivated to combine these teachings for the purpose of analyzing the software for the root cause of potential vulnerabilities and generating a fix action plan with a plurality of alerts (Yaron [0018]).
Claim 23 is directed to a non-transitory processor-readable storage medium corresponding to the method limitations as disclosed in claim 5. Thus, claim 23 is rejected for the same reasons set forth in claim 5.
Claims 7, 14, and 22 are rejected under 35 U.S.C. 103 as being unpatentable over Johnson in view of Fiebig in view of Reddy as applied to claims 1, 10, and 16 above, in view of US 20230185559 A1 hereinafter "Landman" and further in view of US 20130262265 A1 hereinafter "Song".
With regards to claim 7, the rejection of claim 1 is incorporated.
The combination of Johnson, Fiebig, and Reddy does not teach: in response to a request to ingest the at least one software item into a designated software repository,
However, in an analogous art Landman teaches in response to a request to ingest the at least one software item into a designated software repository, (Landman [0080], "Members of the federated software repository may perform repository update operations (e.g., file sharing operations) based on entries in the respective file queue to enable file sharing across the federated software repository [to ingest the at least one software item into a designated software repository]. The file updates may include sending newly added or modified files at one member of the federated repository to the other members, based on receiving requests (e.g., pull or import instructions) from the other members, or based on entries the member's file queue in push-based implementations [further comprising, in response to a request]. In some implementations, in addition to the above-described bi-directional repository updates, members of the federated software repository may be configured to perform one or more types of unidirectional repository updates. As non-limiting examples, unidirectional repository updates may include event-based push updating, event-based pull updating, metadata first synchronization, metadata first event-based updating, or any combination thereof. Event-based push updating may include a member initiating performance of a push operation to send a file to other members responsive to a local event (e.g., a change to an artifact). Event-based pull updating may include a member initiating performance of an import operation to receive a most recent version of a file from another member responsive to a local event (e.g., a user request, a request for the file from another application or process, an automatically detected event, etc.).")
Therefore, it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to have incorporated the teachings of Landman into the teachings of Johnson in view of Fiebig and further in view of Reddy. This combination of teachings would have resulted in a method configured to obtain a trigger event from a request to automatically integrate software into deployment, as in Johnson, while making a determination of approval based on various quality control criteria, as in Fiebig, wherein the criteria requires that the software item be properly licensed for the stages of a deployment pipeline, as in Reddy, in order to share software items across repositories in response to a request, as in Landman. One of ordinary skill in the art would have been motivated to combine these teachings for the purpose of hosting software packages that can make up a software release by using a repository to modify, add, delete, or perform other operations (Landman [0039]).
The combination of Johnson, Fiebig, Reddy, and Landman does not teach: [further comprising, in response to a request to ingest the at least one software item into a designated software repository,] determining whether the at least one software item is licensed.
However, in an analogous art Song teaches […] determining whether the at least one software item is licensed. (Song [0049], "The virtual machine may perform a check to determine if it has received the software license for the licensed software application from the license service system, e.g., a response to the software license request from the license service system (block 615). If the virtual machine has received the software license for the licensed software application from the license service system, the virtual machine may allow the subscribing entity access to the licensed software application (block 620).")
Therefore, it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to have incorporated the teachings of Song into the teachings of Johnson in view of Fiebig in view of Reddy and further in view of Landman. This combination of teachings would have resulted in a method configured to obtain a trigger event from a request to automatically integrate software into deployment, as in Johnson, while making a determination of approval based on various quality control criteria, as in Fiebig, wherein the criteria requires that the software item be properly licensed for the stages of a deployment pipeline, as in Reddy, in order to share software items across repositories in response to a request, as in Landman, and determining the licensing status of the software product, as in Song. One of ordinary skill in the art would have been motivated to combine these teachings for the purpose of accounting or auditing the usage of software for the purpose of determining its associated licensing needs (Song [0010]).
Claim 14 is directed to an apparatus corresponding to the method limitations as disclosed
in claim 7. Thus, claim 14 is rejected for the same reasons set forth in claim 7.
Claim 22 is directed to a non-transitory processor-readable storage medium corresponding to the method limitations of claim 7. Thus, claim 22 is rejected for the same reasons set forth in claim 7.
Claims 8, 21, and 24 are rejected under 35 U.S.C. 103 as being unpatentable over Johnson in view of Fiebig in view of Reddy as applied to claims 1, 10, and 16 above, and further in view of Yaron.
With regards to claim 8, the rejection of claim 1 is incorporated.
The combination of Johnson, Fiebig, and Reddy does not teach: further comprising applying one or more real-time changes to the one or more designated properties of the at least one software item.
However, in an analogous art Yaron teaches further comprising applying one or more real-time changes to the one or more designated properties of the at least one software item. (Yaron [0085], "At S550, a universal definition is output for each of the computing infrastructure resources based on the mapping. In an embodiment, S550 includes inserting one or more properties [applying one or more real-time changes to the one or more designated properties] represented in the original definition of each computing infrastructure resource into respective fields of the matching universal definition template determined for the computing infrastructure resource at S540 [of the at least one software item]. The result of S550 is a universal definition for each of the computing infrastructure resources expressed in a unified format, which allows for application of policies created using the unified format")
Therefore, it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to have incorporated the teachings of Yaron into the teachings of Johnson in view of Fiebig and further in view of Reddy. This combination of teachings would have resulted in a method configured to obtain a trigger event from a request to automatically integrate software into deployment, as in Johnson, while making a determination of approval based on various quality control criteria, as in Fiebig, wherein the criteria requires that the software item be properly licensed for the stages of a deployment pipeline, as in Reddy, and using metadata to update the software item properties, as in Yaron. One of ordinary skill in the art would have been motivated to combine these teachings for the purpose of analyzing the software for the root cause of potential vulnerabilities and generating a fix action plan with a plurality of alerts (Yaron [0018]).
Claim 21 is directed to a non-transitory processor-readable storage medium corresponding to the method limitations as disclosed in claim 8. Thus, claim 21 is rejected for the same reasons set forth in claim 8.
Claim 24 is directed to an apparatus corresponding to the method limitations as disclosed in claim 8. Thus, claim 24 is rejected for the same reasons set forth in claim 8.
Response to Arguments
Applicant’s arguments with respect to claims 1-5, 7-8, 10-14, 16-19, and 21-24 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.
Conclusion
Any inquiry concerning this communication or earlier communications from the examiner should be directed to TRAVIS VIET TRAN whose telephone number is (571)272-3720. The examiner can normally be reached Monday-Friday 8:30AM-5PM.
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 Mui 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.
/T.V.T./Examiner, Art Unit 2191 /WEI Y MUI/Supervisory Patent Examiner, Art Unit 2191