DETAILED ACTION
This communication responsive to the Application No. 18/870,259 filed on November 27, 2024. A preliminary amendment was filed on 11/27/2024 in which claims 3, 5-7, 9, 11-13, 17, 19-21, 23, 25-27 have been amended. Claims 1-28 are pending and are directed towards SOFTWARE MANAGEMENT SYSTEM.
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 .
Information Disclosure Statement
The information disclosure statements (IDS) submitted on 11/27/2024 and 02/27/2025 were Acknowledge. The submission is in compliance with the provisions of 37 CFR 1.97. Accordingly, the information disclosure statements are being considered by the examiner.
Specification
This application does not contain an abstract of the disclosure as required by 37 CFR 1.72(b). An abstract on a separate sheet is required.
Claim Rejections - 35 USC § 112
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.
Claims 6, 12, 14 and 15-28 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.
Claims 6 and 20 recites the limitation "provide the party access to one or more records of the distributed ledger based on the first access permission”. There is insufficient antecedent basis for this limitation in the claim.
Claims 12, 14, 26 and 28 recite undefined acronym “API” which is indefinite.
Claim 15 recites the limitation "execute one or more software tools of the set of software tools, thereby producing a result; and storing, by the controller, the result on a record of the distributed ledger”. There is insufficient antecedent basis for this limitation in the claim.
Claims 16-19, 21-25 and 27 are rejected by dependency.
Claim Rejections - 35 USC § 102
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 the appropriate paragraphs of 35 U.S.C. 102 that form the basis for the rejections under this section made in this Office action:
A person shall be entitled to a patent unless –
(a)(1) the claimed invention was patented, described in a printed publication, or in public use, on sale, or otherwise available to the public before the effective filing date of the claimed invention.
Claim(s) 1-8, 11-22 and 25-28 are rejected under 35 U.S.C. 102(a)(1) as being anticipated by Reddy et al. US 2019/0303579 A1 (hereinafter “Reddy”)
As per claims 1 and 15, Reddy teaches a software management system (the present disclosure relates generally to managing software assets. Reddy, para [0002]) comprising:
a controller (code analysis engine, build and test infrastructure. Reddy, Fig. 8-10);
a distributed ledger in communication with the controller, the distributed ledger comprising one or more records (record information about a software supply-chain in a blockchain (or other directed acyclic graph of cryptographic hash pointers). Units of documented code (such as constituent software assets) may include dependencies (including third-party API's, frameworks, libraries, and modules of an application), each of which may recursively include its own constituent software assets. The blockchain may include or verifiably document for each such constituent of the application relatively fine-grained information about versions, and state of those versions in a software-development life-cycle (SDLC) workflow. Reddy, para [0038]); and
a set of software tools configured to be executed by the controller (the build infrastructure may further include identifiers and versions of applications by which the software asset is built, such as identifiers and versions of compilers, interpreters, orchestration tools, tools by which virtual machine images and container images are composed, and the like. In some embodiments, the build infrastructure may further identify target computing environments, like target operating systems, virtual machines, container engines, and the like. In some embodiments, the build infrastructure trust record may further include other configuration settings of the applications by which software assets are built into forms suitable for subsequent testing and deployment. Reddy, para [0113]);
wherein the controller is configured to:
receive a software component (a given software asset. Reddy, para [0108]);
execute one or more software tools of the set of software tools, thereby producing a result (executed in a staging portion of a software development pipeline may create additional test records, for instance, by testing and recording and publishing test results of tests on the built software asset. In some embodiments, several tests may be applied and different tests may be recorded in different or the same trust record, for instance with different sets of trust assertions. Reddy, para [0114]); and
store the result on a record of the distributed ledger (an entity analyzing the code commit may publish a trust record 138 of the result of the analysis, which may include a reference to an address of the previous trust record 136 in the blockchain. Reddy, para [0111]) (to expedite reads, some embodiments may include an index maintained either inside or external to a blockchain or other tamper evident immutable decentralized data store that identifies addresses of the blockchain or other namespace of the data store to which each trust record of a software asset is published. Reddy, para [0117]).
As per claims 2 and 16, Reddy teaches the system of claim 1 and claim 15, wherein the controller is further configured to, in response to an interaction with the software component:
execute one or more software tools of the set of software tools, thereby producing a new result (executed in a staging portion of a software development pipeline may create additional test records, for instance, by testing and recording and publishing test results of tests on the built software asset. In some embodiments, several tests may be applied and different tests may be recorded in different or the same trust record, for instance with different sets of trust assertions. Reddy, para [0114]); and
store the new result on the record of the distributed ledger (an entity analyzing the code commit may publish a trust record 138 of the result of the analysis, which may include a reference to an address of the previous trust record 136 in the blockchain. Reddy, para [0111]) (to expedite reads, some embodiments may include an index maintained either inside or external to a blockchain or other tamper evident immutable decentralized data store that identifies addresses of the blockchain or other namespace of the data store to which each trust record of a software asset is published. Reddy, para [0117]).
As per claims 3 and 17, Reddy teaches the system of claim 1 and claim 15, wherein the controller is also configured to store test metadata associated with the result on the record of the distributed ledger (several tests may be applied and different tests may be recorded in different or the same trust record, for instance with different sets of trust assertions. In some embodiments, the test infrastructure may include results of human testing as well as results of test applications, such as dynamic test applications, like those examples described above. In some embodiments, the test trust records may include configurations of the tests, identifiers of the tests, identifiers of the test applications, identifiers of versions of the test applications, timestamps of the tests, cryptographic hash digests of the code of the software asset being tested, cryptographic hash digests of the code of the test application, descriptions of environments in which the tests are applied, test results. Reddy, para [0114]).
As per claims 4 and 18, Reddy teaches the system of claim 3 and claim 17, wherein the test metadata comprises one or more of:
a set of performed actions (trust records like trust record 136 may include a cryptographic hash of the content of code of the software asset, of a set of changes to the code of the software asset, and various other key-value pairs. Reddy, para [0110]);
an interacting party identifier;
a developer identifier (different entities may sign different trust assertions. In some cases, multiple entities may sign the same trust assertion (e.g., a developer, their organization, and a software application that performs an analysis). Reddy, para [0111]);
a merging party identifier; and
an approval party identifier.
As per claims 5 and 19, Reddy teaches the system of claim 3 and claim 17, wherein the controller is further configured to store mapping metadata on the record of the distributed ledger (The resulting index, or other reverse manifests (e.g., either mapping entities to software assets, or software assets to other software assets in an opposite direction of invocation), may be interrogated during the following process, e.g., by the alert smart contract, to select additional updated entities. Reddy, para [0205]).
As per claims 6 and 20, Reddy teaches the system of claim 1 and claim 15, wherein the controller is further configured to:
receive an access request from a party (a developer that submitted a pull request. Reddy, para [0150]);
determine an access permission associated with the party (a developer having a specified title or role in organization, for instance, as specified in an organizational chart defining permissions and roles and stored in the tamper-evident, immutable, decentralized data store described above. Reddy, para [0150]); and
provide the party access to one or more records of the distributed ledger based on the first access permission (retrieve an organizational chart or other definition of roles and permissions in the course of applying such criteria, or respective addresses of records about entities associated with the public/private key pair may contain roles and permissions. Reddy, para [0150]).
As per claims 7 and 21, Reddy teaches the system of claim 1 and claim 15, wherein the controller is further configured to transmit and store the software component on an application server following execution of the one or more software tools (Software assets can take many forms, including software assets implementing client-server models (with examples existing both on the server and client side) or in peer-to-peer applications. Software assets can be constructed as monolithic applications, with (or as) micro-services, or as lambda functions in serverless architectures, among other design patterns. Software assets can be deployed at various levels of a software stack, ranging from the application layer, to operating systems, and down to drivers, firmware, and microcode. Reddy, para [0025]).
As per claims 8 and 22, Reddy teaches the system of claim 7 and claim 21, wherein the controller is configured to transmit the software component via an end-to-end encrypted channel (each computing node may have a private and public cryptographic key pair like those described above, and the public cryptographic key may serve as a computing node identifier. In some embodiments, the computing nodes may cryptographically sign communications with their private key over the network (and in some cases encrypt with a public cryptographic key of a recipient) and receiving computing nodes may verify the signatures and that messages are not tampered with. Reddy, para [0088]).
As per claims 11 and 25, Reddy teaches the system of claim 1 and claim 15, wherein the set of software tools comprises one or more of:
a unit testing tool (test infrastructure engine. Reddy, Fig. 10);
a performance testing tool (the pipeline may include various dynamic analysis tests 42 of the as built software asset. Examples of dynamic analysis may include unit tests, performance tests, penetration testing, performance tests, fuzzing, program analysis, runtime verification, software profiling, functionality tests, stress test. Reddy, para [0054]);
a certification tool (a certificate authority 82. Reddy, para [0066]); and
a security scanning tool.
As per claims 12 and 26, Reddy teaches the system of claim 1 and claim 15, wherein the controller stores the result on the distributed ledger via an API (the constituent software assets are not compiled into a single executable but are accessed via system calls or network interfaces, e.g., in different hosts via application program interface requests and responses. Reddy, para [0026]).
As per claims 13 and 27, Reddy teaches the system of claim 1 and claim 15, wherein the controller is configured to:
generate an alert based on the result of the one or more software tools (a process 290 by which alerts pertaining to software assets may be promulgated without a central authority verifying the alerts. Reddy, para [0192-0194]); and
transmit the alert to a second system (pushing alerts to smart contracts, or publishing records that are polled by stakeholders (e.g., before (and in response to a request for) executing, installing, calling, or accepting output from a software asset). Some embodiments may document, in standardized records, events related to such alerts and verify that entities seeking to write such records are authorized to do so via PKI. Some embodiments may further document such events in verifiable, cryptographically signed records. Some embodiments may further push alerts upward through a call graph for software assets including the asset for which an alert is issued. Reddy, para [0192-0194]).
As per claims 14 and 28, Reddy teaches the system of claim 13 and claim 27, wherein the controller is configured to transmit the alert to the second system via an API (pushing alerts to smart contracts, or publishing records that are polled by stakeholders (e.g., before (and in response to a request for) executing, installing, calling, or accepting output from a software asset). Some embodiments may document, in standardized records, events related to such alerts and verify that entities seeking to write such records are authorized to do so via PKI. Some embodiments may further document such events in verifiable, cryptographically signed records. Some embodiments may further push alerts upward through a call graph for software assets including the asset for which an alert is issued. Reddy, para [0192-0194]).
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.
Claim(s) 9-10 and 23-24 are rejected under 35 U.S.C. 103 as being unpatentable over Reddy et al. US 2019/0303579 A1 (hereinafter “Reddy”) in view of Krishnan et al. WO 2020234814 A1 (hereinafter “Krishnan”)
As per claims 9 and 23, Reddy teaches the system of claim 7 and claim 21. Reddy does not explicitly teach wherein the controller is further configured to: receive a user credential from an external party; and provide access to the software component on the application server based on the user credential.
However, Krishnan teaches receive a user credential from an external party (A requestor can present a security token, password, encryption key and/or similar credentials to verify authorization. Krishnan, para [0541]); and
provide access to the software component on the application server based on the user credential (an entity to write specified data associated with a UUID and access control privileges (Block 1221). The permissions manager 181 or related component may authenticate the request to verify that sufficient credentials have been presented to ensure that the requestor is authorized to initiate a write process to change the identified data. A requestor can present a security token, password, encryption key and/or similar credentials to verify authorization. If authenticated, then the request is processed to determine a smart contract tied to the UUID and/or an identifier for the data to written to (Block 1223). Krishnan, para [0541]).
Therefore, it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention, to modify the teaching of Reddy in view of Krishnan. One would be motivated to do so, to enhance the security of the system by verifying the identity of the requestor.
As per claims 10 and 24, Reddy teaches the system of claim 9 and claim 23. Reddy does not explicitly teach wherein the controller provides access to the software component by verifying that the user credential is present on an identities ledger (an entity to write specified data associated with a UUID and access control privileges (Block 1221). The permissions manager 181 or related component may authenticate the request to verify that sufficient credentials have been presented to ensure that the requestor is authorized to initiate a write process to change the identified data. A requestor can present a security token, password, encryption key and/or similar credentials to verify authorization. If authenticated, then the request is processed to determine a smart contract tied to the UUID and/or an identifier for the data to written to (Block 1223). A smart contract can set forth and manage the process for data to be added to the blockchain that serves as a write of the data such that the data added to the blockchain serves to replace prior data in the blockchain though that data itself cannot be modified. The smart contract for a UUID or data associated with an UUID, or a specific object, record or field identified by the request is looked up in the blockchain and the metadata associated with the data to be written is examined to determine if the privileges allow for writes. Krishnan, para [0541]).
However, Krishnan teaches wherein the controller provides access to the software component by verifying that the user credential is present on an identities ledger.
Therefore, it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention, to modify the teaching of Reddy in view of Krishnan. One would be motivated to do so, to enhance the security of the system by verifying the identity of the requestor.
Conclusion
The prior art made of record and not relied upon is considered pertinent to applicant's disclosure.
A. Palanki et al. US 12,306,958 B2 directed to secure application development using distributed ledgers.
B. Digiambattista et al. US 2019/0229915 A1 directed to trusted verification of cybersecurity remediation.
Any inquiry concerning this communication or earlier communications from the examiner should be directed to KHALID M ALMAGHAYREH whose telephone number is (571)272-0179. The examiner can normally be reached Monday - Thursday 8AM-5PM EST & Friday variable.
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, RUPAL DHARIA can be reached at (571)272-3880. 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.
Respectfully Submitted
/KHALID M ALMAGHAYREH/Primary Examiner, Art Unit 2492