PalDETAILED ACTION
The Office Action is in response to a Request for Continued Examination filed 12/12/2025.
Claims 1, 11, and 20 are currently amended.
Claims 8 and 18 are currently cancelled.
Claims 1-7, 9-17, and 19-20 are currently pending.
For clarity of the prosecution history record, it is noted that the instant application is a later-filed continuation of U.S. Application No 18/307627 hereinafter ‘627, which has been abandoned. Thus, there is no double patenting between ‘627 and the instant application.
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 .
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 and 10-11 are rejected under 35 U.S.C. 103 as being unpatentable over US 20200351099 A1 hereinafter "Whitcomb" in view of US 11687656 B2 hereinafter “Palanki” and further in view of US 20190305959 hereinafter "Reddy".
With regards to claim 1,
Whitcomb teaches:
A computing system for implementing a confidential code execution environment for a code transparency service, the computing system (Whitcomb [0012], "a system 100 configured to provide and maintain irrefutable proof of the building, testing, deployment and release of a software product according to an embodiment of the present disclosure. As used herein, the term "software product" encompasses any software that is built, tested, deployed and/or released in any form, including a downloadable software application and software stored and delivered on a computer readable medium.") comprising: a processor and a storage device containing instructions that, when executed, cause the processor to: (Whitcomb [0019], "may use any known processor technology, including but not limited to graphics processors and multi-core processors. Input device 204 may be any known input device technology, including but not limited to a keyboard (including a virtual keyboard), mouse, track ball, and touch sensitive pad or display. Bus 212 may be any known internal or external bus technology, including but not limited to ISA, EISA, PCI, PCI Express, NuBus, USB, Serial ATA or FireWire. Computer-readable medium 210 may be any mcdium that participates in providing instructions to processor(s) 202 for execution, including without limitation, non-volatile storage media (e.g., optical disks, magnetic disks, flash drives, etc.), or volatile media (e.g., SDRAM, ROM, etc.").
receive code data from a producer; (Whitcomb [0028], "An API may define one or more parameters that are passed between a calling application and other software code ( e.g., an operating system, library routine, function) that provides a service, that provides data, or that performs an operation or a computation")
store a code identity artifact comprising the code data on a ledger, (Whitcomb [0047-53], "The type of data that may be managed in the blocks 412, 414, 416, 418, 420 within the ledger 410 could be: The initial SHA (secure hash algorithm) identifier of the source code from the Git repository. The secure hash of the build artifact. The location of the artifact. The timestamp of the start and end of each transaction. The unique identifier of the build, deploy and release requester. Secure hashes of intermediate listings of build and deployment specifics and the locations of the listings."). [Examiner Note: The block is the code identity artifact] wherein the ledger is updatable by an authorized party; (Whitcomb [0036], "In one example embodiment, the electronic ledger may be implemented using cryptography such as e.g., digital hashing and digital signatures, which may form the backbone of the desired security and identification features. In one embodiment, the ledger may be implemented using blockchain or similar technologies. As such, a software product may be built, tested, deployed and released with confidence that software artifacts were not tampered with and that each participant in release cycle was the expected participant (i.e., a members only network).")
Whitcomb does not explicitly teach:
store an acceptance policy artifact on the ledger, wherein the acceptance policy artifact describes a policy that is enforced on the code identity artifact;
receive the code identity endorsement from an auditor for the stored code identity artifact, wherein the code identity endorsement indicates that the code identity artifact adheres to the policy described in the acceptance policy artifact;
store a code identity endorsement artifact on the ledger based on the received endorsement from the auditor, wherein the code identity endorsement artifact is associated with the stored code identity artifact.
However, in an analogous art Palanki teaches to store an acceptance policy artifact on the ledger, (Palanki Column 3 Lines 6-11, “Examples of a distributed ledger 116 can include blockchains, distributed hash tables (DHTs), and similar data structures. Data stored in the distributed ledger 116 can include one or more endorsed application component records 119, one or more security policies 123, and one or more public keys 126.”) wherein the acceptance policy artifact describes a policy that is enforced on the code identity artifact; (Palanki Column 5 Lines 3-14, “A security policy 123 can represent a policy regarding the circumstances in which component files 129 can be permitted for inclusion in an application (e.g., endorsed by a validation node 103). Multiple security policies 123 may be present for evaluation by a validation node 103. For example, some security policies 123 may only be applicable to particular types of component files 129 (e.g., third-party libraries, plug-ins, modules, etc.), while other security policies 123 may be applicable to all component files 129 generally.”)
receive the code identity endorsement from an auditor for the stored code identity artifact, (Palanki Column 9 Lines 47-63, “the distributed agent 163 can generate an endorsed application component record 119. For example, the distributed agent 163 can add the component files 129 and/or network address 133 to the endorsed application component record 119. The distributed agent 163 could also add the version identifier 139, the distributor identifier 143, and security attributes 146, if available. Finally, the distributed agent 163 could generate file signatures 136 for individual component files 129 and an endorsement signature 149 for the endorsed application component record 119. If compliance was conditional, the distributed agent 163 could also add information about the conditions. For example, the distributed agent 163 could application identifiers 153 or use indicators 156 to the endorsed application component record 119 to specify the limited circumstances in which the component file(s) 129 is/are authorized to be used.”) wherein the code identity endorsement indicates that the code identity artifact adheres to the policy described in the acceptance policy artifact; (Palanki Column 8 Lines 45-54, “Then at block 206, the distributed agent 163 can determine whether the component file(s) 129 of the application component comply with an applicable security policy 123. If the component file(s) 129 fail to comply with the security policy 123, the process proceeds to block 209. If the component file(s) 129 comply with the security policy 123, the process proceeds to block 213. Whether the component file(s) 129 comply with the security policy 123 can be determined according to various criteria or combinations of criteria. “)
store a code identity endorsement artifact on the ledger based on the received endorsement from the auditor, wherein the code identity endorsement artifact is associated with the stored code identity artifact. (Palanki Column 3 Lines 12-23, “An endorsed application component record 119 can represent an application component that has been analyzed or reviewed by one or more validation nodes 103. Upon review, the application component can be approved for future use, in which case a record of it can be saved in the distributed ledger 116 as an endorsed application component record 119. Accordingly, the endorsed application component record 119 can include information about one or more component files 129 that form the application component or a network address 133 for the code repository 106 from which the component files 129 can be obtained.”)
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 Palanki into the teachings of Whitcomb. This combination of teachings would have resulted in a system to receive code data that updates a ledger, as in Whitcomb, with an auditor to verify compliance of code to security policies stored in the ledger to store metadata accordingly, as in Palanki. One of ordinary skill in the art would have been motivated to combine these teachings for the purpose of securing the development and deployment of applications by sending it through a verifying entity to check for potential security risks (Palanki Column 1 Lines 60-67).
The combination of Whitcomb and Palanki does not teach: before receiving a code identity endorsement, transmit instructions to an archiving service for storing a copy of the code identity artifact on an external system outside a control of the computing system;
However, in an analogous art Reddy teaches before receiving a code identity endorsement, transmit instructions to an archiving service for storing a copy of the code identity artifact on an external system outside a control of the computing system; (Reddy [0073-74], "In some cases, these transactions may read or write records [transmit instructions for storing], for instance, trust assertions in the below-described trust records, indicative of functionality invoked by or performed by the various illustrated components, including configuration supplied by the components, identifiers of the components, reports on outputs of the components, timestamps of when functionality is invoked or a record is output, identifiers of inputs to the components, identifiers of computing devices or operating systems in which the component executes, identifiers of users invoking functionality of the components, identifiers of entities making the components, identifiers of organizations of users, and the like. In some cases, the identifiers may be cryptographic hash digests of some or all of comprehensive descriptions of the respective thing being described, like a cryptographic hash of a set of configuration settings, an executable file of a test application, a source code format file of a software asset, or the like [a copy of the code identity artifact]. In some embodiments, the development environment 72 may include the applications that operate upon software assets before those software assets are refined for purposes of testing or releasing the production, in some cases operating upon software assets encoded in source code format. In some embodiments, the development environment includes applications executed by developer computing devices and hosted services accessed by those computing devices to define source code, including a development repository 82, a test application 84, development tools 86, and code reviewer computing devices 88. In some embodiments, the development repository 82 may include a Git repository or other version control system [to an archiving service] by which a developer, by operation of their computing device, checks out a software asset, forms a branch version of the software asset, and submits a request to merge the software asset back into a mainline branch, for instance along with a record showing a set of differences between the merged version and the existing version.") and (Reddy [0081], "In some embodiments, the decentralized computing platform 80 may be a peer-to-peer computing network in which no single computing device serves as a central authority to control the operation of the other computing devices in the peer-to-peer computing network. In some embodiments, the decentralized computing platform combines a Turing complete scripting language with a blockchain implementation. In some embodiments, the decentralized computing platform is an implementation of Ethereumᵀ, Hyperledger Fabricᵀ, CardanoᵀM, NEOᵀM or the like, or a combination thereof [on an external system outside a control of the computing system].")
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 Whitcomb in view of Palanki. This combination of teachings would have resulted in a system to receive code data that updates a ledger, as in Whitcomb, with an auditor to verify compliance of code to security policies stored in the ledger to store metadata accordingly, as in Palanki, wherein the code data is stored as an external copy in an external data source prior to the endorsement or verification, as in Reddy. One of ordinary skill in the art
would have been motivated to combine these teachings for the purpose of publishing a software
asset to a decentralized computing platform configured to store configuration/cryptographic keys
subsequent to eventual verification or endorsement for release of the software to production
(Reddy [0230-238]).
With regards to claim 10, the rejection of claim 1 is incorporated.
Whitcomb further teaches wherein the external system is operated by a party designated by a relying party (Whitcomb [0060], "As illustrated, the software release cycle flows from left to right in the pipeline 600, starting with the build services 620 and ending with the release services 650. Depending upon the complexity of the software being released, the pipeline 600 could consist of multiple test and deployment steps. The illustrated pipeline 600 consists of various build, test, deployment and release services available in the market place. It should be appreciated that any of these could be combined to construct a software release system. As such, and as explained above, it is critical to provide a way to track and audit the release process. As can be appreciated, the ledger 610 ensures the actors, artifacts and flow of the release process is what was intended")
Claim 11 is directed to a method corresponding to the system limitations as disclosed in claim 1. Thus, claim 11 is rejected for the same reasons set forth in claim 1.
Claims 2, 3, 6, 12, 13, and 16 are rejected under 35 U.S.C. 103 as being unpatentable over Whitcomb in view of Palanki and further in view of Reddy as applied to claims 1 and 11 above, and further in view of US 1178062 B2 hereinafter “Lounsberry”.
With regards to claim 2, the rejection of claim 1 is incorporated.
The combination of Whitcomb, Palanki, and Reddy does not teach: wherein the auditor comprises a machine learning model that provides the code identity endorsement.
However, in an analogous art Lounsberry teaches wherein the auditor comprises a machine learning model that provides the code identity endorsement. (Lounsberry Column 39 Lines 7-40, "the score is precomputed and stored with the secret, while in others the score is generated on-demand based on current or historic context from a secret risk-generation system or oracle (e.g., a secret store, a machine learning model) 1308 modulate access based on at least one secret risk score 410; performed computationally; since a risk score 410 is an example of secret risk metadata 302, step 1308 is an example of step 1310 which effects a modulation 600 reporting an attack in a text message, email, generated-voice message, printout, alert, screen display, or other communication to an administrator or to security personnel or both, (b) triggering defense, e.g., by making a remote procedure call, or by sending a message, signal, or other digital action or communication to a tool such as an intrusion prevention system, firewall, or exfiltration prevention tool in order to request (as a possible action or as a command) that the triggered tool impose an access restriction, ( ) imposing an access restriction, (d) locking an account, (e) blocking a location e.g., an IP address or device or geolocation, (f) requiring additional authentication before permitting access, e.g., a one time password (OTP) sent by text message or email or generated by an authenticator app, or a biometric credential such as a fingerprint scan result, voiceprint, face recognition, or iris scan result, or a verified presence of a hardware token, or a digital token or certificate")
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 Lounsberry into the teachings of Whitcomb in view of Palanki and further in view of Reddy. This combination of teachings would have resulted in a system to receive code data that updates a ledger, as in Whitcomb, with an auditor to verify compliance of code to security policies stored in the ledger to store metadata accordingly, as in Palanki, wherein the code data is stored as an external copy in an external data source prior to the endorsement or verification, as in Reddy wherein all code is verified with the aid of machine learning for the author to provide authorization, as in Lounsberry. One of ordinary skill in the art would have been motivated to combine these teachings for the purpose of protecting data against intrusion and unwanted access (Lounsberry, Column 3 Lines 31-36).
With regards to claim 3, the rejection of claim 2 is incorporated.
The combination of Whitcomb, Palanki, and Reddy does not teach: wherein the machine learning model reviews portions of the code data
However, in an analogous art Lounsberry teaches wherein the machine learning model reviews portions of the code data, (Lounsberry Column 39 Lines 47-63, "1402 receive a risk score 410 or risk score component data from a machine learning model; performed computationally 1404 machine learning model; may be based on super-vised or unsupervised learning; may be used, e.g., to calculate a risk score 410 or to determine whether to change 1406 access requirements 1406 change access requirement; performed computationally not manually 1408 access requirement, e.g., authentication or authorization credentials required or procedures that must be completed successfully to gain access to an asset computationally employ secrets-risk-metadata based functionality, e.g., secret risk metadata 302, scoring procedure 1412, or modulation procedure 1414 1412 secrets risk scoring procedure, e.g., software which produces a risk score 410")
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 Lounsberry into the teachings of Whitcomb in view of Palanki and further in view of Reddy. This combination of teachings would have resulted in a system to receive code data that updates a ledger, as in Whitcomb, with an auditor to verify compliance of code to security policies stored in the ledger to store metadata accordingly, as in Palanki, wherein the code data is stored as an external copy in an external data source prior to the endorsement or verification, as in Reddy wherein all code is verified with the aid of machine learning for the author to provide authorization, as in Lounsberry. One of ordinary skill in the art would have been motivated to combine these teachings for the purpose of protecting data against intrusion and unwanted access (Lounsberry, Column 3 Lines 31-36).
With regards to claim 6, the rejection of claim 1 is incorporated.
Whitcomb further teaches transmit a receipt of the received endorsement to the relying party. (Whitcomb [0057], "The notification can be provided to the other members of the peer-to-peer network established for the system 100, if desired and or agreed upon by the members. As such, the method 500 (at step 510) can confirm that the transaction was accepted via the notification").
The combination of Whitcomb, Palanki, and Reddy does not explicitly teach:
wherein the instructions further cause the processor to: receive a verification request from a relying party;
However, in an analogous art Lounsberry teaches wherein the instructions further cause the processor to: receive a verification request from a relying party; (Lounsberry Column 40 Lines 54-59, "a request for access to an asset, e.g., a login request, a request for authentication or authorization or both, a request for digital signing or validation of a digital signature; may be performed by or via an API, network transmission, or other computing system communication")
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 Lounsberry into the teachings of Whitcomb in view of Palanki and further in view of Reddy. This combination of teachings would have resulted in a system to receive code data that updates a ledger, as in Whitcomb, with an auditor to verify compliance of code to security policies stored in the ledger to store metadata accordingly, as in Palanki, wherein the code data is stored as an external copy in an external data source prior to the endorsement or verification, as in Reddy wherein all code is verified with the aid of machine learning for the author to provide authorization, as in Lounsberry. One of ordinary skill in the art would have been motivated to combine these teachings for the purpose of protecting data against intrusion and unwanted access (Lounsberry, Column 3 Lines 31-36).
Claims 12, 13, and 16 are directed to a method corresponding to the system limitations as disclosed on claims 2, 3, and 6 respectively. Thus, claims 12, 13, and 16 are rejected for the same reasons set forth in claims 2, 3, and 6.
Claims 4 and 14 are rejected under 35 U.S.C. 103 as being unpatentable over Whitcomb in view of Palanki in view of Reddy and further in view of Lounsberry, as applied to claims 3 and 13 respectively above, and further in view of US 20200026510 A1 hereinafter “Adams”.
With regards to claim 4, the rejection of claim 2 is incorporated.
The rejection of Whitcomb, Palanki, Reddy, and Lounsberry does not teach: wherein the machine learning model is implemented on the computing system
However, in an analogous art Adams teaches wherein the machine learning model is implemented on the computing system (Adams [0038], "Along with reporting on software artifacts, data from the software development life cycle, or SDLC, may be leveraged to support the control systems such as approval systems or automated deployment systems. This may be achieved by either providing comprehensive reporting to the approver, or by creating auto approval systems based on the solution. For example, minimum standards for risk and quality scan results, or performance test results, may be used to support any control decisions. In one embodiment, control systems may base decisions on adherence to other corporate policies, such as the particular source code repositories or build systems being used to produce the data, as well as machine learning.")
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 Adams into the teachings of Whitcomb in view of Palanki and further in view of Reddy. This combination of teachings would have resulted in a system to receive code data that updates a ledger, as in Whitcomb, with an auditor to verify compliance of code to security policies stored in the ledger to store metadata accordingly, as in Palanki, wherein the code data is stored as an external copy in an external data source prior to the endorsement or verification, as in Reddy, wherein all code is verified with the aid of machine learning for the author to provide authorization, as in Lounsberry, and the machine learning is deployed on the computing system, as in Adams. One of ordinary skill in the art would have been motivated to combine these teachings for the purpose of analysis of how applications are developed, how they perform, and how users interact to see its impact on outcomes/objectives (Adams [0048]).
Claim 14 is directed to a method corresponding to the system as disclosed in claim 4. Claim 14 further discloses the ledger which is also anticipated and disclosed in claim 1. Therefore, claim 14 is rejected for the same reasons set forth in claims 1 and 4.
Claims 5 and 15 are rejected under 35 U.S.C. 103 as being unpatentable over Whitcomb in view of Palanki and further in view of Reddy, as applied to claims 1 and 11 respectively above, and further in view of US 20230077289 A1 hereinafter “Sloane”.
With regards to claim 5, the rejection of claim 1 is incorporated.
The combination of Whitcomb, Palanki, and Reddy does not teach: wherein the auditor is an approved auditor designated by a relying party.
However, in an analogous art Sloane teaches wherein the auditor is an approved auditor designated by a relying party. (Sloane [0040], "Based on the detected characteristics of the data artifact, the artifact testing platform may call upon one or more validators (e.g., users, computing systems, applications, databases or repositories, intelligence feeds, AI mod ules, or the like) to validate the data artifact based on the characteristics. In this regard, the validators may be selected based on the suitability of a particular validator to evaluate the data artifact along its one or more characteristics").
Therefore, it would have been obvious to one of ordinary skill in the art to have incorporated the teachings of Sloane into the teachings of Whitcomb in view of Palanki and further in view of Reddy. This combination of teachings would have resulted in a system to receive code data that updates a ledger, as in Whitcomb, with an auditor to verify compliance of code to security policies stored in the ledger to store metadata accordingly, as in Palanki, wherein the code data is stored as an external copy in an external data source prior to the endorsement or verification, as in Reddy, which is endorsed or verified by the author of the received code data to store the artifact metadata accordingly by an approved auditor, as in Sloane. One of ordinary skill in the art would have been motivated to combine these teachings for the purpose of validation of data artifacts within a network environment (Sloane Abstract).
Claim 15 is directed to a method corresponding to system limitations as disclosed in claim 5. Thus, claim 15 is rejected for the same reasons set forth in claim 5.
Claims 7, 9, 17, and 19-20 are rejected under 35 U.S.C. 103 as being unpatentable over Whitcomb in view of Palanki in view of Reddy and further in view of Adams.
With regards to claim 7, the rejection of claim 1 is incorporated.
The combination of Whitcomb, Palanki, and Reddy does not teach: wherein the instructions further cause the processor to: store a reproducible build service artifact associated with the code identity artifact;
receive a reproducible build service endorsement from the auditor; and store a reproducible build service endorsement artifact on the ledger, wherein the reproducible build service endorsement artifact is associated with the reproducible build service artifact.
However, in an analogous art Adams teaches wherein the instructions further cause the processor to store a reproducible build service artifact associated with the code identity artifact; (Adams [0036], "All of these repositories have the ability to store both software and artifact data (e.g., details of what version of the tool that was used) and may be leveraged as data stores.") receive a reproducible build service endorsement from the auditor; (Adams [0034], "In order to be able to guarantee the validity of any artifact, the metadata stored may be signed by the source of the data. Digital signing requires each system producing data to have its own certificate that can identify the system. Code signing utilizes public key cryptography to create a digital signature that can uniquely identify an artifact and its originating owner. This digital signature may be provided as an additional piece of metadata to the data store.") and store a reproducible build service endorsement artifact on the ledger, (Adams [0036], "All of these repositories have the ability to store both software and artifact data (e.g., details of what version of the tool that was used) and may be leveraged as data stores.") [Examiner Note: Data/metadata stores can be implemented via ledgers (see Paragraph [0012])] wherein the reproducible build service endorsement artifact is associated with the reproducible build service artifact. (Adams [0035], "Organizations often have a number of software data repositories for software artifacts. Data stores are generally built around the very specific needs of the software system that holds the data. For example, there are standard repositories offering common reusable components distributed by language specific dependency management solutions such as Maven for Java, NPM for node.js and NuGet for .Net applications. Common software package formats for installing packages also have repository solutions offering package dependency management, such as Yellowdog Updater, Modified (YUM) for RPM and Advanced Package Tool (APT) for Debian packages. Further software repository types containing full Virtual Machine Images and more latterly container images also exist.").
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 Adams into the teachings of Whitcomb in view of Palanki and further in view of Reddy. This combination of teachings would have resulted in a system to receive code data that updates a ledger, as in Whitcomb, with an auditor to verify compliance of code to security policies stored in the ledger to store metadata accordingly, as in Palanki, wherein the code data is stored as an external copy in an external data source prior to the endorsement or verification, as in Reddy, and wherein the
artifact and the endorsement/verification are stored on the code execution system accordingly, as
in Adams. One of ordinary in the art would have been motivated to combine these teachings for
the purpose of linking multiple tools and systems that can provide full visibility into the software
supply chain (e.g. plan, develop, compile, build, scan, test, deploy, release, run). (Adams
[0028]).
With regards to claim 9, the rejection of claim 1 is incorporated.
The combination of Whitcomb, Palanki, and Reddy does not teach: wherein the code identity artifact is stored on a public ledger on the external system
However, in an analogous art Adams teaches wherein the code identity artifact is stored on a public ledger on the external system (Adams [0065], "In one embodiment, all metadata may be written to metadata store 130. Metadata store 130 may be permissioned and private, or it may be public and un-permissioned")
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 Adams into the teachings of Whitcomb in view of Palanki and further in view of Reddy. This combination of teachings would have resulted in a system to receive code data that updates a ledger, as in Whitcomb, with an auditor to verify compliance of code to security policies stored in the ledger to store metadata accordingly, as in Palanki, wherein the code data is stored as an external copy in an external data source prior to the endorsement or verification, as in Reddy, and wherein the
artifact and the endorsement/verification are stored on the code execution system accordingly, as
in Adams. One of ordinary in the art would have been motivated to combine these teachings for
the purpose of linking multiple tools and systems that can provide full visibility into the software
supply chain (e.g. plan, develop, compile, build, scan, test, deploy, release, run). (Adams
[0028]).
Claims 17 and 19 are directed to a method corresponding to the system limitations as disclosed in claims 7 and 9 respectively. Thus, claims 17 and 19 are rejected for the same reasons set forth in claims 7 and 9.
With regards to claim 20, Whitcomb teaches
A computing system for implementing a confidential code execution environment for a code transparency service, (Whitcomb [0012], "a system 100 configured to provide and maintain irrefutable proof of the building, testing, deployment and release of a software product according to an embodiment of the present disclosure. As used herein, the term "software product" encompasses any software that is built, tested, deployed and/or released in any form, including a downloadable software application and software stored and delivered on a computer readable medium.") the computing system comprising:
a set of processors; and
a set of storage devices storing: (Whitcomb [0019], "may use any known processor technology, including but not limited to graphics processors and multi-core processors. Input device 204 may be any known input device technology, including but not limited to a keyboard (including a virtual keyboard), mouse, track ball, and touch-sensitive pad or display. Bus 212 may be any known internal or external bus technology, including but not limited to ISA, EISA, PCI, PCI Express, NuBus, USB, Serial ATA or FireWire. Computer-readable medium 210 may be any medium that participates in providing instructions to processor(s) 202 for execution, including without limitation, non-volatile storage media (e.g., optical disks, magnetic disks, flash drives, etc.), or volatile media (e.g., SDRAM, ROM, etc.").
a ledger; (Whitcomb [0011], "A computing device creates an electronic ledger that may be stored in a database accessible over one or more networks. In one embodiment, the ledger is implemented as a plurality of electronic blocks linked together via cryptography such as e.g., hashing and digital signatures. In one embodiment, the ledger may be implemented using block chain or similar technologies. The computing device or one or more additional computing devices, when performing a transaction/activity related to the software release cycle, may access the electronic ledger to record the transaction/activity performed and when it was performed") and
instructions that, when executed, cause the set of processors to:
receive code data from a producer; (Whitcomb [0028], "An API may define one or more parameters that are passed between a calling application and other software code ( e.g., an operating system, library routine, function) that provides a service, that provides data, or that performs an operation or a computation")
store a code identity artifact comprising the code data on a ledger, (Whitcomb [0047-53], "The type of data that may be managed in the blocks 412, 414, 416, 418, 420 within the ledger 410 could be: The initial SHA (secure hash algorithm) identifier of the source code from the Git repository. The secure hash of the build artifact. The location of the artifact. The timestamp of the start and end of each transaction. The unique identifier of the build, deploy and release requester. Secure hashes of intermediate listings of build and deployment specifics and the locations of the listings."). [Examiner Note: The block is the code identity artifact] wherein the ledger is updatable by an authorized party; (Whitcomb [0036], "In one example embodiment, the electronic ledger may be implemented using cryptography such as e.g., digital hashing and digital signatures, which may form the backbone of the desired security and identification features. In one embodiment, the ledger may be implemented using blockchain or similar technologies. As such, a software product may be built, tested, deployed and released with confidence that software artifacts were not tampered with and that each participant in release cycle was the expected participant (i.e., a members only network).")
Whitcomb does not teach: store an acceptance policy artifact on the ledger,
receive the code identity endorsement from the auditor module for the stored code identity artifact, and
store a code identity endorsement artifact on the ledger based on the received endorsement from the auditor module, wherein the code identity endorsement artifact is associated with the stored code identity artifact.
However, in an analogous art Palanki teaches to store an acceptance policy artifact on the ledger, (Palanki Column 3 Lines 6-11, “Examples of a distributed ledger 116 can include blockchains, distributed hash tables (DHTs), and similar data structures. Data stored in the distributed ledger 116 can include one or more endorsed application component records 119, one or more security policies 123, and one or more public keys 126.”) wherein the acceptance policy artifact describes a policy that is enforced on the code identity artifact; (Palanki Column 5 Lines 3-14, “A security policy 123 can represent a policy regarding the circumstances in which component files 129 can be permitted for inclusion in an application (e.g., endorsed by a validation node 103). Multiple security policies 123 may be present for evaluation by a validation node 103. For example, some security policies 123 may only be applicable to particular types of component files 129 (e.g., third-party libraries, plug-ins, modules, etc.), while other security policies 123 may be applicable to all component files 129 generally.”)
receive the code identity endorsement from the auditor module for the stored code identity artifact, (Palanki Column 9 Lines 47-63, “the distributed agent 163 can generate an endorsed application component record 119. For example, the distributed agent 163 can add the component files 129 and/or network address 133 to the endorsed application component record 119. The distributed agent 163 could also add the version identifier 139, the distributor identifier 143, and security attributes 146, if available. Finally, the distributed agent 163 could generate file signatures 136 for individual component files 129 and an endorsement signature 149 for the endorsed application component record 119. If compliance was conditional, the distributed agent 163 could also add information about the conditions. For example, the distributed agent 163 could application identifiers 153 or use indicators 156 to the endorsed application component record 119 to specify the limited circumstances in which the component file(s) 129 is/are authorized to be used.”) wherein the code identity endorsement indicates that the code identity artifact adheres to the policy described in the acceptance policy artifact; (Palanki Column 8 Lines 45-54, “Then at block 206, the distributed agent 163 can determine whether the component file(s) 129 of the application component comply with an applicable security policy 123. If the component file(s) 129 fail to comply with the security policy 123, the process proceeds to block 209. If the component file(s) 129 comply with the security policy 123, the process proceeds to block 213. Whether the component file(s) 129 comply with the security policy 123 can be determined according to various criteria or combinations of criteria.”) and
store a code identity endorsement artifact on the ledger based on the received endorsement from the auditor module, wherein the code identity endorsement artifact is associated with the stored code identity artifact. (Palanki Column 3 Lines 12-23, “An endorsed application component record 119 can represent an application component that has been analyzed or reviewed by one or more validation nodes 103. Upon review, the application component can be approved for future use, in which case a record of it can be saved in the distributed ledger 116 as an endorsed application component record 119. Accordingly, the endorsed application component record 119 can include information about one or more component files 129 that form the application component or a network address 133 for the code repository 106 from which the component files 129 can be obtained.”)
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 Palanki into the teachings of Whitcomb. This combination of teachings would have resulted in a system to receive code data that updates a ledger, as in Whitcomb, with an auditor to verify compliance of code to security policies stored in the ledger to store metadata accordingly, as in Palanki. One of ordinary skill in the art would have been motivated to combine these teachings for the purpose of securing the development and deployment of applications by sending it through a verifying entity to check for potential security risks (Palanki Column 1 Lines 60-67).
The combination of Whitcomb and Palanki does not teach: before receiving a code identity endorsement from the auditor module, transmit instructions to an archiving service for storing a copy of the code identity artifact on an external system outside a control of the computing system
However, in an analogous art Reddy teaches before receiving a code identity endorsement from the auditor module, transmit instructions to an archiving service for storing a copy of the code identity artifact on an external system outside a control of the computing system (Reddy [0073-74], "In some cases, these transactions may read or write records [transmit instructions for storing], for instance, trust assertions in the below-described trust records, indicative of functionality invoked by or performed by the various illustrated components, including configuration supplied by the components, identifiers of the components, reports on outputs of the components, timestamps of when functionality is invoked or a record is output, identifiers of inputs to the components, identifiers of computing devices or operating systems in which the component executes, identifiers of users invoking functionality of the components, identifiers of entities making the components, identifiers of organizations of users, and the like. In some cases, the identifiers may be cryptographic hash digests of some or all of comprehensive descriptions of the respective thing being described, like a cryptographic hash of a set of configuration settings, an executable file of a test application, a source code format file of a software asset, or the like [a copy of the code identity artifact]. In some embodiments, the development environment 72 may include the applications that operate upon software assets before those software assets are refined for purposes of testing or releasing the production, in some cases operating upon software assets encoded in source code format. In some embodiments, the development environment includes applications executed by developer computing devices and hosted services accessed by those computing devices to define source code, including a development repository 82, a test application 84, development tools 86, and code reviewer computing devices 88. In some embodiments, the development repository 82 may include a Git repository or other version control system [to an archiving service] by which a developer, by operation of their computing device, checks out a software asset, forms a branch version of the software asset, and submits a request to merge the software asset back into a mainline branch, for instance along with a record showing a set of differences between the merged version and the existing version.") and (Reddy [0081], "In some embodiments, the decentralized computing platform 80 may be a peer-to-peer computing network in which no single computing device serves as a central authority to control the operation of the other computing devices in the peer-to-peer computing network. In some embodiments, the decentralized computing platform combines a Turing complete scripting language with a blockchain implementation. In some embodiments, the decentralized computing platform is an implementation of Ethereumᵀ, Hyperledger FabricᵀM, CardanoᵀM, NEOᵀ or the like, or a combination thereof [on an external system outside a control of the computing system].")
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 Whitcomb in view of Palanki. This combination of teachings would have resulted in a system to receive code data that updates a ledger, as in Whitcomb, with an auditor to verify compliance of code to security policies stored in the ledger to store metadata accordingly, as in Palanki, wherein the code data is stored as an external copy in an external data source prior to the endorsement or verification, as in Reddy. One of ordinary skill in the art
would have been motivated to combine these teachings for the purpose of publishing a software
asset to a decentralized computing platform configured to store configuration/cryptographic keys
subsequent to eventual verification or endorsement for release of the software to production
(Reddy [0230-238]).
The combination of Whitcomb, Palanki, and Reddy does not teach: an auditor module comprising a code review machine learning model;
However, in an analogous art Adams teaches an auditor module comprising a code review machine learning model; (Adams [0038], "Along with reporting on software artifacts, data from the software development life cycle, or SDLC, may be leveraged to support the control systems such as approval systems or automated deployment systems. This may be achieved by either providing comprehensive reporting to the approver, or by creating auto-approval systems based on the solution. For example, minimum standards for risk and quality scan results, or performance test results, may be used to support any control decisions. In one embodiment, control systems may base decisions on adherence to other corporate policies, such as the particular source code repositories or build systems being used to produce the data, as well as machine learning.")
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 Adams into the teachings of Whitcomb in view of Palanki and further in view of Reddy. This combination of teachings would have resulted in a system to receive code data that updates a ledger, as in Whitcomb, with an auditor to verify compliance of code to security policies stored in the ledger to store metadata accordingly, as in Palanki, wherein the code data is stored as an external copy in an external data source prior to the endorsement or verification, as in Reddy, and wherein the
artifact and the endorsement/verification are stored on the code execution system accordingly, as
in Adams. One of ordinary in the art would have been motivated to combine these teachings for
the purpose of linking multiple tools and systems that can provide full visibility into the software
supply chain (e.g. plan, develop, compile, build, scan, test, deploy, release, run). (Adams [0028]).
Response to Arguments
Applicant’s arguments with respect to claims 1-7, 9-17, and 19-20 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
The prior art made of record and not relied upon is considered pertinent to applicant's disclosure.
Oerton (US 20230379699 A1) teaches: A blockchain-based system for manages the root of trust for a swarm of deployed devices. The blockchain is operated by a set of stakeholder entities that provide consensus for adding transactions to the blockchain or channels thereof, which comprise attestation data for use by the devices during onboarding, firmware installation and updates, and policy updates. Devices subscribe to message topics on a message broker system to obtain control plane and data plane messages. Access to message topics is managed by rules enforced by the secure processing environment.
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