DETAILED ACTION
This final office action is in response to claims 1-17 filed on 05/26/2026 for examination. Claims 1-17 are being examined and are pending.
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 .
In the event the determination of the status of the application as subject to AIA 35 U.S.C. 102 and 103 (or as subject to pre-AIA 35 U.S.C. 102 and 103) is incorrect, any correction of the statutory basis for the rejection will not be considered a new ground of rejection if the prior art relied upon, and the rationale supporting the rejection, would be the same under either status.
Response to Amendment
The amendment filed May 26, 2026 has been entered. Claims 1-17 remain pending in the application. The claims have been amended. Applicant’s arguments and amendments to the claims have overcome each and every drawings objection, claim objection, 35 U.S.C. 112 rejection, and 35 U.S.C. 101 rejection previously set forth in the Non-Final Office Action mailed February 26, 2026. Claims 1-4, 6-7, 9-12, 14-15, and 17 have been amended and have necessitated a new ground(s) of rejection in this Office Action. Therefore, Applicant’s arguments filed on 05/26/2026 have been fully considered but are moot in view of the new ground(s) of rejection because the arguments do not apply to any of the updated reference(s) being used in the current rejection.
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.
The following is a quotation of 35 U.S.C. 112 (pre-AIA ), second paragraph:
The specification shall conclude with one or more claims particularly pointing out and distinctly claiming the subject matter which the applicant regards as his invention.
Claim(s) 1-17 is/are rejected under 35 U.S.C. 112(b) or 35 U.S.C. 112 (pre-AIA ), second paragraph, as being indefinite for failing to particularly point out and distinctly claim the subject matter which the inventor or a joint inventor (or for applications subject to pre-AIA 35 U.S.C. 112, the applicant), regards as the invention. Particularly: Claim 1 recites “wherein the modifying comprises setting dually common secret key being currently used by the first application and additional common secret key using key exchange algorithm of PQC” in lines 10-11. This language is grammatically inconsistent and unclear as to what Applicant is attempting to claim. For examination (and in view of Applicant’s Remarks pgs. 9-11), Examiner is interpreting this language as setting both the original common key and setting a separate PQC common key. Claims 9 and 17 recite similar language, and are rejected under like rationale. Claims 2-8 and 10-16 incorporate the deficiency of the parent claim(s), and are rejected under like rationale.
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.
Claim(s) 1-5, 8-13, and 16-17 is/are rejected under 35 U.S.C. 103 as being unpatentable over Papaxenopoulos et al. (US20180336356; Hereinafter “Papaxenopoulos”) in view of Truskovsky et al. (US11265159; Hereinafter “Truskovsky”) and O’Connell et al. (US20230247010; Hereinafter “O’Connell”).
Regarding claim 1, Papaxenopoulos teaches a method for automatically performing |security| migration on an application using a computing device (abstract – system is an auto-remediation system for fixing security vulnerabilities), the method comprising:
determining whether a first application has |security| vulnerability based on information about the first application ([0014-015] and [0047] – source code/associated information is retrieved from website or source code repository. The source code/associated information is then scanned and examined to determine if the application has a security vulnerability), wherein the information is collected from an application distribution server configured to distribute source code of an application ([0014-015] and [0047] – source code/associated information is retrieved from a website or source code repository <i.e., application distribution server>. The source code/associated information is then scanned and examined to determine if the application has a security vulnerability);
modifying one or more of source code, settings, or environment variables for the first application, based on a result of the determination, by the application distribution server ([0048] and [0019-022] – Security vulnerabilities are identified by the application. Security patch rules are used to produce modified source code/application variables resolving the identified security vulnerabilities. A patch is produced, and then the patch is committed for implementation); and
generating an execution file for the first application by reflecting the modified one or more of source code, settings, or environment variables ([0020-022], [0034], and [0045] – Security patch rules are used to produce modified source code/application variables resolving the identified security vulnerabilities. The patched source code/application <i.e., execution file> is generated, approved, and committed to the source code repository for implementation),
as well as wherein a cryptographic algorithm of a first [[post-quantum]] cryptography library corresponding to the first application is further reflected in addition to a cryptographic algorithm currently being used in the first application ([0014] and [0019-020] – APIs can include libraries and methods actively utilized in the application as well as libraries and methods not currently utilized that can be used to remediate vulnerabilities <i.e., both old and new algorithms can be stored>, and security patch rules can add encryption calls and implement multiple encryption methodologies or combinations <i.e., any of the stored can be used>).
While Papaxenopoulos teaches a system for performing security migration, identifying security vulnerabilities, and adding cryptography libraries (see, e.g., Papaxenopoulos at [0014-022]), Papaxenopoulos appears to fail to specifically disclose wherein the security migration is a PQC migration and the security vulnerabilities are quantum vulnerabilities, as well using a post-quantum cryptographic library, and wherein the modifying comprises setting dually common secret key currently being used by the first application and additional common secret key using key exchange algorithm of PQC.
However, Truskovsky teaches a similar system for performing security migration and identifying security vulnerabilities (see Truskovsky at column 7, lines 1-29 and column 11, lines 29-43), wherein the security migration is a PQC migration, the security vulnerabilities are quantum vulnerabilities, and the new library is a post-quantum cryptographic library (column 7, lines 1-29 and column 11, lines 29-column 12 line 5 – The system determines whether a resource is quantum attack vulnerable. The vulnerable resource is modified to use quantum-secure cryptography).
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to modify Papaxenopoulos with the teachings of Truskovsky, comprising a method for automatically performing PQC migration on an application using a computing device, the method comprising: determining whether or not a first application has quantum vulnerability on the basis of information about the first application, and implementing a cryptographic algorithm of a first post-quantum cryptography library corresponding to the first application is further reflected in addition to a cryptographic algorithm currently being used in the first application to protect applications against quantum computing attacks (see, e.g., Truskovsky at column 7, lines 1-29 and column 4, line 43-column 5 line 45).
Yet, the combination of Papaxenopoulos and Truskovsky appear to fail to specifically disclose wherein the modifying comprises setting dually common secret key currently being used by the first application and additional common secret key using key exchange algorithm of PQC.
However, O’Connell teaches a similar system for upgrading existing cryptographic communications to post-quantum cryptography (see, e.g., [0026-029]), wherein the modifying comprises setting dually common secret key currently being used by the first application and additional common secret key using key exchange algorithm of PQC ([0018] and [0026-029] – a standard TLS handshake generates a master secret ss0 shared between a client and a server <i.e., common secret key being used by the first application>, after which the client and server implement a PQE key exchange protocol to create a shared secret ss1 <i.e., additional common secret key> using a PQE KEM for key exchange <i.e., using key exchange algorithm of PQC>. The quantum-resistant encryption key is appended to an already negotiated TLS key <i.e., setting dually>).
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 combination of Papaxenopoulos and Truskovsky with the teachings of O’Connell, wherein the modifying comprises setting dually common secret key currently being used by the first application and additional common secret key using key exchange algorithm of PQC, to provide a backwards-compatible post-quantum upgrade over existing encryption protocols (see, e.g., O’Connell at [0026-029] and [0034]).
Regarding claim 2, the combination of Papaxenopoulos, Truskovsky, and O’Connell teach the method according to claim 1, wherein the determining comprises discriminating whether the first application has quantum vulnerability using a predefined rule set, based on version information of the first application (Papaxenopoulos at [0028], [0041]and [0047-048] – the security vulnerabilities are detected based on scanning the application following a rule set; Truskovsky at column 9, lines 7-24 and column 7, lines 1-29 – the detected security vulnerabilities may be, e.g., quantum vulnerabilities. The vulnerabilities may be determined/detected at least in part based on the version number). It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to implement the combination of Papaxenopoulos, Truskovsky, and O’Connell with the teachings of Truskovsky, wherein the determining comprises determining whether or not the first application has quantum vulnerability using a predefined rule set, on the basis of version information of the first application, to easily identify and protect applications against quantum computing attacks (see, e.g., Truskovsky at column 7, lines 1-29 and column 4, line 43-column 5 line 45).
Regarding claim 3, the combination of Papaxenopoulos, Truskovsky, and O’Connell teach the method according to claim 2, wherein the discriminating comprises, when the rule set does not include information on quantum vulnerability corresponding to the version information of the first application, determining whether the first application has quantum vulnerability using the source code of the first application (Papaxenopoulos at [0028], [0041]and [0047-048] – other methods are used to determine whether a security vulnerability is present, e.g., the code scanning. These methods are used regardless of whether version information is present <i.e., even in a case where there is no version information, determining is made>; Truskovsky at column 9, lines 7-24 and column 7, lines 1-29 – the detected security vulnerabilities may be, e.g., quantum vulnerabilities). It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to implement the combination of Papaxenopoulos, Truskovsky, and O’Connell with the teachings of Truskovsky, wherein the determining comprises, in a case where the rule set does not include information on quantum vulnerability corresponding to the version information of the first application, determining whether or not the first application has quantum vulnerability using the source code of the first application, to protect applications against quantum computing attacks even if it is not previously documented as a vulnerability (see, e.g., Papaxenopoulos at [0028], [0041], and [0047-048]; with Truskovsky at column 7, lines 1-29 and column 4, line 43-column 5 line 45).
Regarding claim 4, the combination of Papaxenopoulos, Truskovsky, and O’Connell teach the method according to claim 3, comprising updating the rule set based on a result of determining whether the first application has quantum vulnerability using the source code of the first application (Papaxenopoulos at [0014-018], [0032-034], [0037], and [0050] – a security vulnerability is identified using the source code and updated rules are generated if not already present. The rules are then updated to the rules repository for future remediation).
Regarding claim 5, the combination of Papaxenopoulos, Truskovsky, and O’Connell teach the method according to claim 2, wherein the modifying comprises: producing a first post-quantum cryptography library corresponding to the version information of the first application using the rule set (Truskovsky at column 9 lines 7-column 10-15 and column 7, lines 1-29 – the application version is identified. Based on the application version number, a determination is made whether the application’s quantum vulnerable cryptographic library is to be replaced by a quantum secure cryptographic library); and modifying one or more of the source code, settings, or environment variables for the first application such that a cryptographic algorithm of the first post-quantum cryptography library is further reflected in addition to a cryptographic algorithm currently being used in the first application (Papaxenopoulos at [0018-022] – the application’s source code is modified by the security patch to improve the security of the application. E.g., the cryptographic libraries are upgraded; with Truskovsky at column 7, lines 1-29 and column 9 lines 7-column 10-15 – the cryptographic algorithms of the quantum secure cryptographic library are utilized by the upgraded application). It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to implement the combination of Papaxenopoulos, Truskovsky, and O’Connell with the teachings of Truskovsky, wherein the modifying comprises: producing a first post-quantum cryptography library corresponding to the version information of the first application using the rule set; and modifying one or more of the source code, settings, or environment variables for the first application such that a cryptographic algorithm of the first post-quantum cryptography library is further reflected in addition to a cryptographic algorithm currently being used in the first application, to protect applications against quantum computing attacks (see, e.g., Papaxenopoulos at [0028], [0041], and [0047-048]; with Truskovsky at column 7, lines 1-29 and column 4, line 43-column 5 line 45).
Regarding claim 8, the combination of Papaxenopoulos, Truskovsky, and O’Connell teach the method according to claim 1, wherein the computing device is configured to perform PQC migration on the first application that is produced or updated and distributed by a third party (Papaxenopoulos at [0047] and [0018-022]– the source code of the application for modification can be provided by a customer or customer site <i.e., distributed by third-party>. The auto-remediation system performs the security migration on the application; with Truskovsky at column 9, lines 7-24 and column 7, lines 1-29 – the detected security vulnerabilities may be, e.g., quantum vulnerabilities). It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to implement the combination of Papaxenopoulos, Truskovsky, and O’Connell with the teachings of Truskovsky, wherein the computing device is configured to perform PQC migration on the first application that is produced or updated and distributed by a third party, to protect vulnerable customer applications against quantum computing attacks (see, e.g., Papaxenopoulos at [0028], [0041], and [0047-048]; with Truskovsky at column 7, lines 1-29 and column 4, line 43-column 5 line 45).
Regarding claim 9, Papaxenopoulos teaches a server comprising a processor and a memory ([0066-069] – system implemented via processors executing computer instructions stored in memory), and configured to automatically perform |security| migration on an application, wherein the memory comprises instructions configured to cause, when executed by the processor, the server to implement specific operations ([0066-069] – system implemented via processors executing computer instructions stored in memory; abstract – system is an auto-remediation system for fixing security vulnerabilities), and wherein the specific operations comprises:
determining whether a first application has |security| vulnerability based on information about the first application ([0014-015] and [0047] – source code/associated information is retrieved from website or source code repository. The source code/associated information is then scanned and examined to determine if the application has a security vulnerability), wherein the information is collected from an application distribution server configured to distribute source code of an application ([0014-015] and [0047] – source code/associated information is retrieved from a website or source code repository <i.e., application distribution server>. The source code/associated information is then scanned and examined to determine if the application has a security vulnerability);
modifying one or more of source code, settings, or environment variables for the first application, based on a result of the determination, by the application distribution server ([0048] and [0019-022] – Security vulnerabilities are identified by the application. Security patch rules are used to produce modified source code/application variables resolving the identified security vulnerabilities. A patch is produced, and then the patch is committed for implementation); and
generating an execution file for the first application by reflecting the modified one or more of source code, settings, or environment variables ([0020-022], [0034], and [0045] – Security patch rules are used to produce modified source code/application variables resolving the identified security vulnerabilities. The patched source code/application <i.e., execution file> is generated, approved, and committed to the source code repository for implementation),
as well as wherein a cryptographic algorithm of a first [[post-quantum]] cryptography library corresponding to the first application is further reflected in addition to a cryptographic algorithm currently being used in the first application ([0014] and [0019-020] – APIs can include libraries and methods actively utilized in the application as well as libraries and methods not currently utilized that can be used to remediate vulnerabilities <i.e., both old and new algorithms can be stored>, and security patch rules can add encryption calls and implement multiple encryption methodologies or combinations <i.e., any of the stored can be used>).
While Papaxenopoulos teaches a system for performing security migration, identifying security vulnerabilities, and adding cryptography libraries (see, e.g., Papaxenopoulos at [0014-022]), Papaxenopoulos appears to fail to specifically disclose wherein the security migration is a PQC migration and the security vulnerabilities are quantum vulnerabilities, as well using a post-quantum cryptographic library, and wherein the modifying comprises setting dually common secret key currently being used by the first application and additional common secret key using key exchange algorithm of PQC.
However, Truskovsky teaches a similar system for performing security migration and identifying security vulnerabilities (see Truskovsky at column 7, lines 1-29 and column 11, lines 29-43), wherein the security migration is a PQC migration, the security vulnerabilities are quantum vulnerabilities, and the new library is a post-quantum cryptographic library (column 7, lines 1-29 and column 11, lines 29-column 12 line 5 – The system determines whether a resource is quantum attack vulnerable. The vulnerable resource is modified to use quantum-secure cryptography).
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to modify Papaxenopoulos with the teachings of Truskovsky, comprising a method for automatically performing PQC migration on an application using a computing device, the method comprising: determining whether or not a first application has quantum vulnerability on the basis of information about the first application, and implementing a cryptographic algorithm of a first post-quantum cryptography library corresponding to the first application is further reflected in addition to a cryptographic algorithm currently being used in the first application to protect applications against quantum computing attacks (see, e.g., Truskovsky at column 7, lines 1-29 and column 4, line 43-column 5 line 45).
Yet, the combination of Papaxenopoulos and Truskovsky appear to fail to specifically disclose wherein the modifying comprises setting dually common secret key currently being used by the first application and additional common secret key using key exchange algorithm of PQC.
However, O’Connell teaches a similar system for upgrading existing cryptographic communications to post-quantum cryptography (see, e.g., [0026-029]), wherein the modifying comprises setting dually common secret key currently being used by the first application and additional common secret key using key exchange algorithm of PQC ([0018] and [0026-029] – a standard TLS handshake generates a master secret ss0 shared between a client and a server <i.e., common secret key being used by the first application>, after which the client and server implement a PQE key exchange protocol to create a shared secret ss1 <i.e., additional common secret key> using a PQE KEM for key exchange <i.e., using key exchange algorithm of PQC>. The quantum-resistant encryption key is appended to an already negotiated TLS key <i.e., setting dually>).
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 combination of Papaxenopoulos and Truskovsky with the teachings of O’Connell, wherein the modifying comprises setting dually common secret key currently being used by the first application and additional common secret key using key exchange algorithm of PQC, to provide a backwards-compatible post-quantum upgrade over existing encryption protocols (see, e.g., O’Connell at [0026-029] and [0034]).
Regarding claim 10, the combination of Papaxenopoulos, Truskovsky, and O’Connell teach the server according to claim 9, wherein the determining comprises discriminating whether the first application has quantum vulnerability using a predefined rule set based on version information of the first application (Papaxenopoulos at [0028], [0041]and [0047-048] – the security vulnerabilities are detected based on scanning the application following a rule set; Truskovsky at column 9, lines 7-24 and column 7, lines 1-29 – the detected security vulnerabilities may be, e.g., quantum vulnerabilities. The vulnerabilities may be determined/detected at least in part based on the version number). It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to implement the combination of Papaxenopoulos and Truskovsky with the teachings of Truskovsky, wherein the determining comprises determining whether or not the first application has quantum vulnerability using a predefined rule set, on the basis of version information of the first application, to easily identify and protect applications against quantum computing attacks (see, e.g., Truskovsky at column 7, lines 1-29 and column 4, line 43-column 5 line 45).
Regarding claim 11, the combination of Papaxenopoulos, Truskovsky, and O’Connell teach the server according to claim 10, wherein the discriminating comprises, in a case where the rule set does not include information on quantum vulnerability corresponding to the version information of the first application, determining whether the first application has quantum vulnerability using the source code of the first application (Papaxenopoulos at [0028], [0041]and [0047-048] – other methods are used to determine whether a security vulnerability is present, e.g., the code scanning. These methods are used regardless of whether version information is present <i.e., even in a case where there is no version information, determining is made>; Truskovsky at column 9, lines 7-24 and column 7, lines 1-29 – the detected security vulnerabilities may be, e.g., quantum vulnerabilities). It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to implement the combination of Papaxenopoulos, Truskovsky, and O’Connell with the teachings of Truskovsky, wherein the determining comprises, in a case where the rule set does not include information on quantum vulnerability corresponding to the version information of the first application, determining whether or not the first application has quantum vulnerability using the source code of the first application, to protect applications against quantum computing attacks even if it is not previously documented as a vulnerability (see, e.g., Papaxenopoulos at [0028], [0041], and [0047-048]; with Truskovsky at column 7, lines 1-29 and column 4, line 43-column 5 line 45).
Regarding claim 12, the combination of Papaxenopoulos, Truskovsky, and O’Connell teach the server according to claim 11, wherein the rule set is updated based on a result of determining whether the first application has quantum vulnerability using the source code of the first application (Papaxenopoulos at [0014-018], [0032-034], [0037], and [0050] – a security vulnerability is identified using the source code and updated rules are generated if not already present. The rules are then updated to the rules repository for future remediation).
Regarding claim 13, the combination of Papaxenopoulos, Truskovsky, and O’Connell teach the server according to claim 10, wherein the modifying comprises: producing a first post-quantum cryptography library corresponding to the version information of the first application using the rule set (Truskovsky at column 9 lines 7-column 10-15 and column 7, lines 1-29 – the application version is identified. Based on the application version number, a determination is made whether the application’s quantum vulnerable cryptographic library is to be replaced by a quantum secure cryptographic library); and modifying one or more of the source code, settings, or environment variables for the first application such that a cryptographic algorithm of the first post-quantum cryptography library is further reflected in addition to a cryptographic algorithm currently being used in the first application (Papaxenopoulos at [0018-022] – the application’s source code is modified by the security patch to improve the security of the application. E.g., the cryptographic libraries are upgraded; with Truskovsky at column 7, lines 1-29 and column 9 lines 7-column 10-15 – the cryptographic algorithms of the quantum secure cryptographic library are utilized by the upgraded application). It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to implement the combination of Papaxenopoulos, Truskovsky, and O’Connell with the teachings of Truskovsky, wherein the modifying comprises: producing a first post-quantum cryptography library corresponding to the version information of the first application using the rule set; and modifying one or more of the source code, settings, or environment variables for the first application such that a cryptographic algorithm of the first post-quantum cryptography library is further reflected in addition to a cryptographic algorithm currently being used in the first application, to protect applications against quantum computing attacks (see, e.g., Papaxenopoulos at [0028], [0041], and [0047-048]; with Truskovsky at column 7, lines 1-29 and column 4, line 43-column 5 line 45).
Regarding claim 16, the combination of Papaxenopoulos, Truskovsky, and O’Connell teach the server according to claim 9, wherein the server is configured to perform PQC migration on the first application that is produced or updated and distributed by a third party (Papaxenopoulos at [0047] and [0018-022]– the source code of the application for modification can be provided by a customer or customer site <i.e., distributed by third-party>. The auto-remediation system performs the security migration on the application; with Truskovsky at column 9, lines 7-24 and column 7, lines 1-29 – the detected security vulnerabilities may be, e.g., quantum vulnerabilities). It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to implement the combination of Papaxenopoulos, Truskovsky, and O’Connell with the teachings of Truskovsky, wherein the computing device is configured to perform PQC migration on the first application that is produced or updated and distributed by a third party, to protect vulnerable customer applications against quantum computing attacks (see, e.g., Papaxenopoulos at [0028], [0041], and [0047-048]; with Truskovsky at column 7, lines 1-29 and column 4, line 43-column 5 line 45).
Regarding claim 17, Papaxenopoulos teaches a non-transitory computer-readable storage medium storing instructions configured to cause, when executed by a processor, a server, which comprises the processor and is configured to automatically perform |PQC| migration on an application, to implement specific operations ([0066-069] – system implemented via processors executing computer instructions stored in memory; abstract – system is an auto-remediation system for fixing security vulnerabilities), wherein the specific operations comprises:
determining whether a first application has |security| vulnerability based on information about the first application ([0014-015] and [0047] – source code/associated information is retrieved from website or source code repository. The source code/associated information is then scanned and examined to determine if the application has a security vulnerability), wherein the information is collected from an application distribution server configured to distribute source code of an application ([0014-015] and [0047] – source code/associated information is retrieved from a website or source code repository <i.e., application distribution server>. The source code/associated information is then scanned and examined to determine if the application has a security vulnerability);
modifying one or more of source code, settings, or environment variables for the first application, based on a result of the determination, by the application distribution server ([0048] and [0019-022] – Security vulnerabilities are identified by the application. Security patch rules are used to produce modified source code/application variables resolving the identified security vulnerabilities. A patch is produced, and then the patch is committed for implementation); and
generating an execution file for the first application by reflecting the modified one or more of source code, settings, or environment variables ([0020-022], [0034], and [0045] – Security patch rules are used to produce modified source code/application variables resolving the identified security vulnerabilities. The patched source code/application <i.e., execution file> is generated, approved, and committed to the source code repository for implementation),
as well as wherein a cryptographic algorithm of a first [[post-quantum]] cryptography library corresponding to the first application is further reflected in addition to a cryptographic algorithm currently being used in the first application ([0014] and [0019-020] – APIs can include libraries and methods actively utilized in the application as well as libraries and methods not currently utilized that can be used to remediate vulnerabilities <i.e., both old and new algorithms can be stored>, and security patch rules can add encryption calls and implement multiple encryption methodologies or combinations <i.e., any of the stored can be used>).
While Papaxenopoulos teaches a system for performing security migration, identifying security vulnerabilities, and adding cryptography libraries (see, e.g., Papaxenopoulos at [0014-022]), Papaxenopoulos appears to fail to specifically disclose wherein the security migration is a PQC migration and the security vulnerabilities are quantum vulnerabilities, as well using a post-quantum cryptographic library, and wherein the modifying comprises setting dually common secret key currently being used by the first application and additional common secret key using key exchange algorithm of PQC.
However, Truskovsky teaches a similar system for performing security migration and identifying security vulnerabilities (see Truskovsky at column 7, lines 1-29 and column 11, lines 29-43), wherein the security migration is a PQC migration, the security vulnerabilities are quantum vulnerabilities, and the new library is a post-quantum cryptographic library (column 7, lines 1-29 and column 11, lines 29-column 12 line 5 – The system determines whether a resource is quantum attack vulnerable. The vulnerable resource is modified to use quantum-secure cryptography).
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to modify Papaxenopoulos with the teachings of Truskovsky, comprising a method for automatically performing PQC migration on an application using a computing device, the method comprising: determining whether or not a first application has quantum vulnerability on the basis of information about the first application, and implementing a cryptographic algorithm of a first post-quantum cryptography library corresponding to the first application is further reflected in addition to a cryptographic algorithm currently being used in the first application to protect applications against quantum computing attacks (see, e.g., Truskovsky at column 7, lines 1-29 and column 4, line 43-column 5 line 45).
Yet, the combination of Papaxenopoulos and Truskovsky appear to fail to specifically disclose wherein the modifying comprises setting dually common secret key currently being used by the first application and additional common secret key using key exchange algorithm of PQC.
However, O’Connell teaches a similar system for upgrading existing cryptographic communications to post-quantum cryptography (see, e.g., [0026-029]), wherein the modifying comprises setting dually common secret key currently being used by the first application and additional common secret key using key exchange algorithm of PQC ([0018] and [0026-029] – a standard TLS handshake generates a master secret ss0 shared between a client and a server <i.e., common secret key being used by the first application>, after which the client and server implement a PQE key exchange protocol to create a shared secret ss1 <i.e., additional common secret key> using a PQE KEM for key exchange <i.e., using key exchange algorithm of PQC>. The quantum-resistant encryption key is appended to an already negotiated TLS key <i.e., setting dually>).
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 combination of Papaxenopoulos and Truskovsky with the teachings of O’Connell, wherein the modifying comprises setting dually common secret key currently being used by the first application and additional common secret key using key exchange algorithm of PQC, to provide a backwards-compatible post-quantum upgrade over existing encryption protocols (see, e.g., O’Connell at [0026-029] and [0034]).
Claim(s) 6-7 and 14-15 is/are rejected under 35 U.S.C. 103 as being unpatentable over Papaxenopoulos in view of Truskovsky and O’Connell, further in view of Kumar et al. (US20160350081; Hereinafter “Kumar”).
Regarding claim 6, the combination of Papaxenopoulos, Truskovsky, and O’Connell teach the method according to claim 1. Yet the combination of Papaxenopoulos, Truskovsky, and O’Connell appear to fail to specifically disclose wherein the generating comprises generating a docker container image to be executed on the basis of a cloud for the first application.
However, Kumar teaches a system for deploying software (see, e.g., [0002-003]), wherein the generating comprises generating a docker container image to be executed based on a cloud for the first application ([0002], [0023], [0019-020], and [0037] – deploying software for an application may be done in a cloud system using a docker container image).
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 combination of Papaxenopoulos, Truskovsky, and O’Connell with the teachings of Kumar, wherein the generating comprises generating a docker container image to be executed on the basis of a cloud for the first application, so that the updates may be conveniently implemented in the vulnerable application (see, e.g., Papaxenopoulos at [0014-022]; with Kumar at [0002-003], [0022], and [0037]).
Regarding claim 7, the combination of Papaxenopoulos, Truskovsky, O’Connell, and Kumar teach the method according to claim 6, wherein the modifying comprises modifying a docker file for the first application based on the modified one or more of source code, settings, or environment variables (Papaxenopoulos at [0014-022] – the modifying comprises modifying files for an application on the basis of source code/associated information, and committing the modified files for usage; with Kumar at [0022-023], [0043], and [0002-003] – a docker file may be modified based on the modified source elements of the application, and used in the application). 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 combination of Papaxenopoulos, Truskovsky, O’Connell, and Kumar with the teachings of Kumar, wherein the modifying comprises modifying a docker file for the first application on the basis of the modified source code, settings, or environment variables, so that the updates may be conveniently implemented in the vulnerable application (see, e.g., Papaxenopoulos at [0014-022]; with Kumar at [0002-003], [0022], and [0037]).
Regarding claim 14, the combination of Papaxenopoulos, Truskovsky, and O’Connell teach the server according to claim 9. Yet the combination of Papaxenopoulos, Truskovsky, and O’Connell appear to fail to specifically disclose wherein the generating comprises generating a docker container image to be executed on the basis of a cloud for the first application.
However, Kumar teaches a system for deploying software (see, e.g., [0002-003]), wherein the generating comprises generating a docker container image to be executed based on a cloud for the first application ([0002], [0023], [0019-020], and [0037] – deploying software for an application may be done in a cloud system using a docker container image).
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 combination of Papaxenopoulos, Truskovsky, and O’Connell with the teachings of Kumar, wherein the generating comprises generating a docker container image to be executed on the basis of a cloud for the first application, so that the updates may be conveniently implemented in the vulnerable application (see, e.g., Papaxenopoulos at [0014-022]; with Kumar at [0002-003], [0022], and [0037]).
Regarding claim 15, the combination of Papaxenopoulos, Truskovsky, O’Connell, and Kumar teach the server according to claim 14, wherein the modifying comprises modifying a docker file for the first application on the basis of the modified one or more of source code, settings, or environment variables (Papaxenopoulos at [0014-022] – the modifying comprises modifying files for an application on the basis of source code/associated information, and committing the modified files for usage; with Kumar at [0022-023], [0043], and [0002-003] – a docker file may be modified based on the modified source elements of the application, and used in the application). 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 combination of Papaxenopoulos, Truskovsky, O’Connell, and Kumar with the teachings of Kumar, wherein the modifying comprises modifying a docker file for the first application on the basis of the modified source code, settings, or environment variables, so that the updates may be conveniently implemented in the vulnerable application (see, e.g., Papaxenopoulos at [0014-022]; with Kumar at [0002-003], [0022], and [0037]).
Conclusion
The prior art made of record and not relied upon is considered pertinent to applicant's disclosure. Arbajian et al. (US11322050) teaches a system for evaluating quantum risk in systems and migrating the systems to a post-quantum cryptography scheme (see, e.g., Arbajian at columns 1-2). Rao et al. (US20250184132) teaches a system for migrating legacy security cryptographic techniques to PQC techniques (see, e.g., Rao at abstract, [0006-010]). Sharma et al. (US20250258754) teaches a system for scanning code in a repository for vulnerabilities, and when issues are found, automatically generating and submitting remediation changes for the code (see, e.g., Sharma at abstract, [0017-022]).
Applicant's amendment necessitated the new ground(s) of rejection presented in this Office action. Accordingly, THIS ACTION IS MADE FINAL. See MPEP § 706.07(a). Applicant is reminded of the extension of time policy as set forth in 37 CFR 1.136(a).
A shortened statutory period for reply to this final action is set to expire THREE MONTHS from the mailing date of this action. In the event a first reply is filed within TWO MONTHS of the mailing date of this final action and the advisory action is not mailed until after the end of the THREE-MONTH shortened statutory period, then the shortened statutory period will expire on the date the advisory action is mailed, and any nonprovisional extension fee (37 CFR 1.17(a)) pursuant to 37 CFR 1.136(a) will be calculated from the mailing date of the advisory action. In no event, however, will the statutory period for reply expire later than SIX MONTHS from the mailing date of this final action.
Any inquiry concerning this communication or earlier communications from the examiner should be directed to JOSHUA RAYMOND WHITE whose telephone number is (571)272-4365. The examiner can normally be reached Monday-Thursday, & Alternate Fridays.
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, Taghi Arani can be reached at 5712723787. 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.
/J.R.W./Examiner, Art Unit 2438 /TAGHI T ARANI/Supervisory Patent Examiner, Art Unit 2438
Prosecution Insights