DETAILED ACTION
This action is in response to the application filed on 3/30/2023.
Claims 1-20 are pending in this application.
The present application, filed on or after March 16, 2013, is being examined under the first inventor to file provisions of the AIA .
Claim Objections
Claims 4-6, and 9-19 are objected to because of the following informalities:
Claim 4 at line 4, “the second time stamp” lacks antecedent basis.
Claim 9 at line 2 after system, “whereint” should be --wherein--.
Claim 16 at line 7, “the second block” lacks proper antecedent basis.
Dependent claims 5, 6, 10-15, and 17-19 do not overcome the deficiency of the base
claims and, therefore, are objected for the same reasons as the base claims.
Appropriate correction is required.
Claim Rejections - 35 USC § 103
The following is a quotation of 35 U.S.C. 103 which forms the basis for all obviousness rejections set forth in this Office action:
A patent for a claimed invention may not be obtained, notwithstanding that the claimed invention is not identically disclosed as set forth in section 102, if the differences between the claimed invention and the prior art are such that the claimed invention as a whole would have been obvious before the effective filing date of the claimed invention to a person having ordinary skill in the art to which the claimed invention pertains. Patentability shall not be negated by the manner in which the invention was made.
Claims 1-13 and 16-20 are rejected under 35 U.S.C. 103 as being unpatentable over Reddy et al. (US Patent Application Publication 20190303623 A1) in view of Landman (US Patent Application Publication 2023/0040803 A1).
As to claim 1, Reddy teaches a method, comprising adding a first block to a blockchain in response to a first code (e.g. source code of software asset) by a first system (e.g. developer computing device, See e.g. Figs: 3 and 7 and associated text, e.g. [0074]- 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, and [0110]- upon a developer committing code changes to the software asset to the repository, a new trust record 136 may be published. In some embodiments, the new trust record 136 may include a reference to an address of the previous trust record 134 in the blockchain), wherein the first block comprises a first time indicator (See e.g. [0106]- the trust records may include key-value pairs like those present in the illustrated example and delimited by reserved terms (like a colon) with end of line characters delimiting key-value pairs, and in some cases, including a timestamp indicative of when the trust record was created (e.g., when the information therein was ascertained, when the record was formed, or when the record was signed) and adding a second block to the blockchain in response to a second code (e.g. compiled code of software asset) by a second system (e.g. build environment, see e.g. Figs 3 and 9 and associated text, e.g. [0075]- the computing environment 70 may include a build environment 73, which may include a compiler 75 or an interpreter 77, and which may input source code and output machine code or byte code and [0112]- the tested software asset may be processed with build infrastructure, which in some cases may create an additional trust record 140 with a reference back to the address of the previous trust record 138), wherein the second block comprises a second time indicator (See e.g. [0106]- the trust records may include key-value pairs like those present in the illustrated example and delimited by reserved terms (like a colon) with end of line characters delimiting key-value pairs, and in some cases, including a timestamp indicative of when the trust record was created (e.g., when the information therein was ascertained, when the record was formed, or when the record was signed), wherein the second code is different from the first code (see e.g. Fig.2 and associated text, e.g. [0053]- the preceding portions of the lifecycle may involve source code of the software asset. Some embodiments of the pipeline may include a build operation 40 by which a human readable body of source code is compiled or interpreted into machine code or byte code, respectively, or the code is otherwise packaged and formatted for execution, e.g., on a target platform (like an OS version).
Reddy does not specifically teach adding the first block to the blockchain in response to signing the first code or adding the second block to the blockchain in response to signing the second code.
In an analogous art of however, Landman teaches adding a first block (e.g. entry) to a blockchain (e.g. ledger, see e.g. Fig.5 and associated text, e.g. [0107]- Development ledger 500 may be maintained by a server, such as server 110, server 168, server 340, server 404, or any combination thereof. The development ledger 500 is based on digital signatures and digital signature metadata, such as the digital signatures and digital signature metadata included in digital signature information 332) and [0109]- Each entry includes a digital signature and corresponding metadata. For example, first entry 502 includes a first digital signature 510 (“$#&%”) and digital signature metadata 512), in response to signing a first code by a first system (See e.g. Fig.4 and associated text, e.g. [0099]- code for one or more files (e.g., artifacts) may be generated or developed. The code may be combined into a first build job at first build 412. The first build job may undergo unity testing at unity test 416. Upon successful completion of unity test 416, a first digital signature 442 is generated; First digital signature 442 may be provided to server 404 for storage) and adding a second block (e.g. second entry) to a blockchain (e.g. ledger, see e.g. Fig.5 and associated text, e.g. [0107]- Development ledger 500 may be maintained by a server, such as server 110, server 168, server 340, server 404, or any combination thereof. The development ledger 500 is based on digital signatures and digital signature metadata, such as the digital signatures and digital signature metadata included in digital signature information 332) and [0109]- Each entry includes a digital signature and corresponding metadata; second entry 504, third entry 506, and fourth entry 508 each include a digital signature, a time, an author, a development stage, a build number, and a checksum) in response to signing a second code by a second system (see e.g. Fig.4 and associated text, e.g. [0101]- In addition to generating the first build job, the code may be combined into a second build job at second build 414; Upon successful completion of unity test 418, a second digital signature 446 is generated).
It would have been obvious to one having ordinary skill in the art before the effective filing date of the claimed invention to have modified the method of Reddy to incorporate/implement the limitations as taught by Landman in order to provide a more efficient method of verifying completion of one or more stages of a development process for a software release.
As to claim 2, Landman further teaches wherein the second system verifies a first signature on the first code using a first public key of the first system, wherein the first public key is encapsulated in a first public key certificate of the first system (See e.g. [0059]- credential 232 may include security or authentication information, such as a private key, a public key, and/or a token of a user and/or entity), [0070]- Entity device 310 includes one or more processors 312 and a memory 314. Memory 314 includes software 316 (e.g., one or more files), one or more private keys 318, and one or more public keys 319. Public keys 319 correspond to private keys 318. For example, a digital signature that is encrypted using a particular private key can be decrypted through use of a corresponding particular public key, and [0085]- After identifying (and/or receiving) software 352, node device 360 performs one or more verification operations on software 352. For example, verifier 363 verifies whether software 352 has completed development stages 320 based on the multiple digital signatures and public keys 319. To illustrate, verifier 363 may decrypt a particular digital signature using the corresponding public key to determine whether the particular digital signature is valid) and in response to verifying the first signature, the second system performs at least one of [testing the first code, compiling the first code, modifying the first code, or] distributing the first code (See e.g. [0087]- Node device 360 processes software 352 based on verifying that software 352 (e.g., the one or more files) has completed the development stages 320. For example, if verifier 363 verifies that software 352 has completed development stages 320, node device 360 may load software 352 to memory 364 (or another memory other than transaction directory 370).
It would have been obvious to one having ordinary skill in the art before the effective filing date of the claimed invention to have modified the method of Reddy to incorporate/implement the limitations as taught by Landman in order to provide a more efficient method of verifying completion of one or more stages of a development process for a software release.
As to claim 3, Landman further teaches wherein the first code is signed by the first system using a first private key of the first system, wherein the first private key corresponds to the first public key and the second code is signed by the second system using a second private key of the second system (See e.g. [0024]- Each digital signature may be generated based on a private key corresponding to the completed development stage (or a private key corresponding to a user who signs off on completion of the development stage); Each private key has a corresponding public key. Additionally, or alternative, digital signature metadata corresponding to the digital signatures, the private key, and/or the public key may be generated and [0070]- [0070]- Entity device 310 includes one or more processors 312 and a memory 314. Memory 314 includes software 316 (e.g., one or more files), one or more private keys 318, and one or more public keys 319. Public keys 319 correspond to private keys 318. For example, a digital signature that is encrypted using a particular private key can be decrypted through use of a corresponding particular public key).
It would have been obvious to one having ordinary skill in the art before the effective filing date of the claimed invention to have modified the method of Reddy to incorporate/implement the limitations as taught by Landman in order to provide a more efficient method of verifying completion of one or more stages of a development process for a software release.
As to claim 4, Reddy also teaches wherein the first indicator comprises a first Time Stamp Token (TST) (e.g. trust record 136), the first TST comprises a hash of the first code, a first timestamp, and a first cryptographic signature, without the first code (See e.g. [0106]- the trust records may include key-value pairs like those present in the illustrated example and delimited by reserved terms (like a colon) with end of line characters delimiting key-value pairs, and in some cases, including a timestamp indicative of when the trust record was created (e.g., when the information therein was ascertained, when the record was formed, or when the record was signed) and [0110]- 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 like those illustrated),
the second time stamp comprises a second TST (e.g. trust record 140) and the second TST comprises a hash of the second code, a second timestamp, and a second cryptographic signature, without the second code (see e.g. [0113]- the trust record by the build infrastructure may similarly include a cryptographic hash digest of the software asset, a timestamp, and in some cases may be cryptographically signed by a private key of the application that is transforming the software asset into the built state).
As to claim 5, Reddy also teaches wherein at least one of: the first TST is generated using a hash of the first code without a first signature of the first system or the second TST is generated using a hash of the second code without a second signature of the second system (See e.g. [0111]- In some cases, each trust record may include the above-describe cryptographic hash digest of the code of the software asset to which the trust record pertains to afford the above-describe verification features).
As to claim 6, Reddy also teaches wherein at least one of the first TST is generated using a hash of the first code with a first signature of the first system; or the second TST is generated using a hash of the second code with a second signature of the second system (see e.g. [0111]- In some embodiments, the trust record 138 may be cryptographically signed by an entity that analyze the committed code of the software asset described above).
As to claim 7, Reddy also teaches wherein the first system comprises a Development (DEV) system (see e.g. [0066]- the computing environment 70 includes a development environment 72), wherein the first block comprises a DEV Code Sign Event Record (CSER), the DEV CSER comprises the first time indicator for the DEV system (See e.g. [0106]- the trust records may include key-value pairs like those present in the illustrated example and delimited by reserved terms (like a colon) with end of line characters delimiting key-value pairs, and in some cases, including a timestamp indicative of when the trust record was created (e.g., when the information therein was ascertained, when the record was formed, or when the record was signed and [0110]- upon a developer committing code changes to the software asset to the repository, a new trust record 136 may be published. In some embodiments, the new trust record 136 may include a reference to an address of the previous trust record 134 in the blockchain); and the second system comprises a TEST system (see e.g. [0076]- Some embodiments may further include a testing environment 74 with various test applications 92), wherein the second block comprises a TEST CSER (See e.g. [0106]- the trust records may include key-value pairs like those present in the illustrated example and delimited by reserved terms (like a colon) with end of line characters delimiting key-value pairs, and in some cases, including a timestamp indicative of when the trust record was created (e.g., when the information therein was ascertained, when the record was formed, or when the record was signed and [0111]- 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).
As to claim 8, Reddy also teaches wherein the first system comprises a TEST system (see e.g. [0076]- Some embodiments may further include a testing environment 74 with various test applications 92), wherein the first block comprises a TEST Code Sign Event Record (CSER), the TEST CSER comprises the first time indicator for the TEST system (See e.g. [0106]- the trust records may include key-value pairs like those present in the illustrated example and delimited by reserved terms (like a colon) with end of line characters delimiting key-value pairs, and in some cases, including a timestamp indicative of when the trust record was created (e.g., when the information therein was ascertained, when the record was formed, or when the record was signed and [0111]- 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); and the second system comprises a User Acceptance Test (UAT) system (e.g. post build test infrastructure, see e.g. [0114]- post build test infrastructure, for example, 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; 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, and the like), wherein the second time indicator comprises a UAT timestamp (See e.g. [0106]- the trust records may include key-value pairs like those present in the illustrated example and delimited by reserved terms (like a colon) with end of line characters delimiting key-value pairs, and in some cases, including a timestamp indicative of when the trust record was created (e.g., when the information therein was ascertained, when the record was formed, or when the record was signed).
As to claim 9, Reddy teaches adding a third block to the blockchain in response to a third code (e.g. source code of software asset) by a third system (e.g. another developer computing device, See e.g. Figs: 3 and 7 and associated text, e.g. [0051]- the pipeline may further include code review, as indicate by block 36, which may include having another developer review, comment on, enter entries in an issue tracking repository regarding, or modify candidate versions of a software asset with a different or the same developer computing device, [0074]- 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, and [0110]- upon a developer committing code changes to the software asset to the repository, a new trust record 136 may be published. In some embodiments, the new trust record 136 may include a reference to an address of the previous trust record 134 in the blockchain), wherein the third block comprises a third time indicator (See e.g. [0106]- the trust records may include key-value pairs like those present in the illustrated example and delimited by reserved terms (like a colon) with end of line characters delimiting key-value pairs, and in some cases, including a timestamp indicative of when the trust record was created (e.g., when the information therein was ascertained, when the record was formed, or when the record was signed), wherein the third code is different from the second code (see e.g. Fig.2 and associated text, e.g. [0053]- the preceding portions of the lifecycle may involve source code of the software asset. Some embodiments of the pipeline may include a build operation 40 by which a human readable body of source code is compiled or interpreted into machine code or byte code, respectively, or the code is otherwise packaged and formatted for execution, e.g., on a target platform (like an OS version).
Reddy does not specifically teach adding the third block to the blockchain in response to signing the third code.
In an analogous art of however, Landman teaches adding a third block (e.g. entry) to a blockchain (e.g. ledger, see e.g. Fig.5 and associated text, e.g. [0107]- Development ledger 500 may be maintained by a server, such as server 110, server 168, server 340, server 404, or any combination thereof. The development ledger 500 is based on digital signatures and digital signature metadata, such as the digital signatures and digital signature metadata included in digital signature information 332) and [0109]- Each entry includes a digital signature and corresponding metadata. For example, first entry 502 includes a first digital signature 510 (“$#&%”) and digital signature metadata 512), in response to signing a third code by a third system (See e.g. Fig.4 and associated text, e.g. [0099]- code for one or more files (e.g., artifacts) may be generated or developed. The code may be combined into a first build job at first build 412. The first build job may undergo unity testing at unity test 416. Upon successful completion of unity test 416, a first digital signature 442 is generated; First digital signature 442 may be provided to server 404 for storage).
It would have been obvious to one having ordinary skill in the art before the effective filing date of the claimed invention to have modified the method of Reddy to incorporate/implement the limitations as taught by Landman in order to provide a more efficient method of verifying completion of one or more stages of a development process for a software release.
As to claim 10, Reddy also teaches wherein the second code comprises source code, and the third code comprises compiled executable code (see e.g. Fig.2 and associated text, e.g. [0053]- the preceding portions of the lifecycle may involve source code of the software asset. Some embodiments of the pipeline may include a build operation 40 by which a human readable body of source code is compiled or interpreted into machine code or byte code, respectively, or the code is otherwise packaged and formatted for execution, e.g., on a target platform (like an OS version).
As to claim 11, Reddy also teaches wherein the third system comprises a Production (PROD) system (see e.g. [0079]- the production environment 78 may include components by which a software asset is executed in its deployed form), wherein the third time indicator comprises a PROD timestamp (See e.g. [0106]- the trust records may include key-value pairs like those present in the illustrated example and delimited by reserved terms (like a colon) with end of line characters delimiting key-value pairs, and in some cases, including a timestamp indicative of when the trust record was created (e.g., when the information therein was ascertained, when the record was formed, or when the record was signed and [0115]- deployment may be implemented with release infrastructure, which may create additional trust records 144).
As to claim 12, Reddy also teaches wherein a user system verifies a signature of the third system on the third code using a third public key of the third system and the third public key is encapsulated in a third public key certificate of the third system (See e.g. [0024]- Each digital signature may be generated based on a private key corresponding to the completed development stage (or a private key corresponding to a user who signs off on completion of the development stage); Each private key has a corresponding public key. Additionally, or alternative, digital signature metadata corresponding to the digital signatures, the private key, and/or the public key may be generated and [0070]- [0070]- Entity device 310 includes one or more processors 312 and a memory 314. Memory 314 includes software 316 (e.g., one or more files), one or more private keys 318, and one or more public keys 319. Public keys 319 correspond to private keys 318. For example, a digital signature that is encrypted using a particular private key can be decrypted through use of a corresponding particular public key).
As to claim 13, Reddy also teaches wherein the third system verifies a second signature on the second code using a second public key of the second system, wherein the second public key is encapsulated in a second public key certificate of the second system (See e.g. [0059]- credential 232 may include security or authentication information, such as a private key, a public key, and/or a token of a user and/or entity), [0070]- Entity device 310 includes one or more processors 312 and a memory 314. Memory 314 includes software 316 (e.g., one or more files), one or more private keys 318, and one or more public keys 319. Public keys 319 correspond to private keys 318. For example, a digital signature that is encrypted using a particular private key can be decrypted through use of a corresponding particular public key, and [0085]- After identifying (and/or receiving) software 352, node device 360 performs one or more verification operations on software 352. For example, verifier 363 verifies whether software 352 has completed development stages 320 based on the multiple digital signatures and public keys 319. To illustrate, verifier 363 may decrypt a particular digital signature using the corresponding public key to determine whether the particular digital signature is valid); and in response to verifying the second signature, the third system performs at least one of:[compiling the second code to generate the third code or] releasing the third code (See e.g. [0087]- Node device 360 processes software 352 based on verifying that software 352 (e.g., the one or more files) has completed the development stages 320. For example, if verifier 363 verifies that software 352 has completed development stages 320, node device 360 may load software 352 to memory 364 (or another memory other than transaction directory 370).
It would have been obvious to one having ordinary skill in the art before the effective filing date of the claimed invention to have modified the method of Reddy to incorporate/implement the limitations as taught by Landman in order to provide a more efficient method of verifying completion of one or more stages of a development process for a software release.
As to claim 16, the limitations of system claim 16 are substantially similar to the limitations of method claim 1, and therefore, it is rejected for the reasons stated above. Reddy further discloses a processing circuit comprising a processor and a memory (see FIG. 19)
As to claim 17, the limitations of system claim 17 are substantially similar to the limitations of method claim 2, and therefore, it is rejected for the reasons stated above.
As to claim 18, the limitations of system claim 18 are substantially similar to the limitations of method claim 3, and therefore, it is rejected for the reasons stated above.
As to claim 19, Reddy teaches wherein the processing circuit (see e.g. [0216]) is configured to add a third time indicator to the blockchain in response to third code (e.g. source code of software asset) by a third system (e.g. another developer computing device, See e.g. Figs: 3 and 7 and associated text, e.g. [0051]- the pipeline may further include code review, as indicate by block 36, which may include having another developer review, comment on, enter entries in an issue tracking repository regarding, or modify candidate versions of a software asset with a different or the same developer computing device, [0074]- 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, and [0110]- upon a developer committing code changes to the software asset to the repository, a new trust record 136 may be published. In some embodiments, the new trust record 136 may include a reference to an address of the previous trust record 134 in the blockchain), wherein the third block comprises a third time indicator (See e.g. [0106]- the trust records may include key-value pairs like those present in the illustrated example and delimited by reserved terms (like a colon) with end of line characters delimiting key-value pairs, and in some cases, including a timestamp indicative of when the trust record was created (e.g., when the information therein was ascertained, when the record was formed, or when the record was signed), wherein the third code is compiled from the second code (see e.g. Fig.2 and associated text, e.g. [0053]- the preceding portions of the lifecycle may involve source code of the software asset. Some embodiments of the pipeline may include a build operation 40 by which a human readable body of source code is compiled or interpreted into machine code or byte code, respectively, or the code is otherwise packaged and formatted for execution, e.g., on a target platform (like an OS version).
Reddy does not specifically teach adding a third time indicator to the blockchain in response to signing the third code.
In an analogous art of however, Landman teaches adding a third time indicator (e.g. time value) to a blockchain (e.g. ledger, see e.g. Fig.5 and associated text, e.g. [0107]- Development ledger 500 may be maintained by a server, such as server 110, server 168, server 340, server 404, or any combination thereof. The development ledger 500 is based on digital signatures and digital signature metadata, such as the digital signatures and digital signature metadata included in digital signature information 332) and [0109]- Each entry includes a digital signature and corresponding metadata. For example, first entry 502 includes a first digital signature 510 (“$#&%”) and digital signature metadata 512; digital signature metadata 512 includes a time value 514 (e.g., a time that first digital signature 510 was generated), in response to signing a third code by a third system (See e.g. Fig.4 and associated text, e.g. [0099]- code for one or more files (e.g., artifacts) may be generated or developed. The code may be combined into a first build job at first build 412. The first build job may undergo unity testing at unity test 416. Upon successful completion of unity test 416, a first digital signature 442 is generated; First digital signature 442 may be provided to server 404 for storage).
It would have been obvious to one having ordinary skill in the art before the effective filing date of the claimed invention to have modified the method of Reddy to incorporate/implement the limitations as taught by Landman in order to provide a more efficient method of verifying completion of one or more stages of a development process for a software release.
As to claim 20, the limitations of medium claim 20 are substantially similar to the limitations of method claim 1, and therefore, it is rejected for the reasons stated above.
Allowable Subject Matter
Claims 14 and 15 are objected to as being dependent upon a rejected base claim, but would be allowable if rewritten in independent form including all of the limitations of the base claim and any intervening claims.
Conclusion
The prior art made of record and not relied upon is considered pertinent to applicant's disclosure. Harrington (US Patent Application Publication 2020/0177397 A1) discloses a validation record chain that is generated for a particular version of a software package may be used to verify the legitimacy of the particular version.
Any inquiry concerning this communication or earlier communications from the examiner should be directed to CHENECA SMITH whose telephone number is (571)270-1651. The examiner can normally be reached Mon-Fri 8:00AM-4:30PM EST.
Examiner interviews are available via telephone, in-person, and video conferencing using a USPTO supplied web-based collaboration tool. To schedule an interview, applicant is encouraged to use the USPTO Automated Interview Request (AIR) at http://www.uspto.gov/interviewpractice.
If attempts to reach the examiner by telephone are unsuccessful, the examiner’s supervisor, Hyung S Sough can be reached at 571-272-6799. 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.
/CHENECA SMITH/Examiner, Art Unit 2192
/S. SOUGH/SPE, Art Unit 2192