Notice of Pre-AIA or AIA Status
The present application, filed on or after March 16, 2013, is being examined under the first inventor to file provisions of the AIA .
Information Disclosure Statement
The information disclosure statement (IDS) submitted on 05/15/2026 and 10/06/2025 has been considered by the examiner.
Drawings
The drawing submitted on 01/13/2025 has been accepted.
Specification
The specification submitted on 01/13/2025 has been accepted.
Double Patenting
The nonstatutory double patenting rejection is based on a judicially created doctrine grounded in public policy (a policy reflected in the statute) so as to prevent the unjustified or improper timewise extension of the “right to exclude” granted by a patent and to prevent possible harassment by multiple assignees. A nonstatutory double patenting rejection is appropriate where the conflicting claims are not identical, but at least one examined application claim is not patentably distinct from the reference claim(s) because the examined application claim is either anticipated by, or would have been obvious over, the reference claim(s). See, e.g., In re Berg, 140 F.3d 1428, 46 USPQ2d 1226 (Fed. Cir. 1998); In re Goodman, 11 F.3d 1046, 29 USPQ2d 2010 (Fed. Cir. 1993); In re Longi, 759 F.2d 887, 225 USPQ 645 (Fed. Cir. 1985); In re Van Ornum, 686 F.2d 937, 214 USPQ 761 (CCPA 1982); In re Vogel, 422 F.2d 438, 164 USPQ 619 (CCPA 1970); In re Thorington, 418 F.2d 528, 163 USPQ 644 (CCPA 1969).
A timely filed terminal disclaimer in compliance with 37 CFR 1.321(c) or 1.321(d) may be used to overcome an actual or provisional rejection based on nonstatutory double patenting provided the reference application or patent either is shown to be commonly owned with the examined application, or claims an invention made as a result of activities undertaken within the scope of a joint research agreement. See MPEP § 717.02 for applications subject to examination under the first inventor to file provisions of the AIA as explained in MPEP § 2159. See MPEP § 2146 et seq. for applications not subject to examination under the first inventor to file provisions of the AIA . A terminal disclaimer must be signed in compliance with 37 CFR 1.321(b).
The filing of a terminal disclaimer by itself is not a complete reply to a nonstatutory double patenting (NSDP) rejection. A complete reply requires that the terminal disclaimer be accompanied by a reply requesting reconsideration of the prior Office action. Even where the NSDP rejection is provisional the reply must be complete. See MPEP § 804, subsection I.B.1. For a reply to a non-final Office action, see 37 CFR 1.111(a). For a reply to final Office action, see 37 CFR 1.113(c). A request for reconsideration while not provided for in 37 CFR 1.113(c) may be filed after final for consideration. See MPEP §§ 706.07(e) and 714.13.
The USPTO Internet website contains terminal disclaimer forms which may be used. Please visit www.uspto.gov/patent/patents-forms. The actual filing date of the application in which the form is filed determines what form (e.g., PTO/SB/25, PTO/SB/26, PTO/AIA /25, or PTO/AIA /26) should be used. A web-based eTerminal Disclaimer may be filled out completely online using web-screens. An eTerminal Disclaimer that meets all requirements is auto-processed and approved immediately upon submission. For more information about eTerminal Disclaimers, refer to www.uspto.gov/patents/apply/applying-online/eterminal-disclaimer.
Claims 21-40 are directed to rejected on the ground of nonstatutory double patenting as being unpatentable over claims 1-20 of U.S. Patent No. 12200122. Although the claims at issue are not identical, they are not patentably distinct from each other because limitation features of claims 21 and 31 of the current application 19/019160 are generic to corresponding limitation features of claims 1 and 10 of the U.S. Patent No. 12200122 respectively.
Current Instant Application 19/019160
Conflicting US Pat. No.: 12200122 B1
21 (New) A server device for authenticating client devices on a communication network, comprising:
a transceiver configured for operable communication with a plurality of client devices of the communication network including a first client device;
a processor including a memory configured to store computer-executable instructions, which, when executed by the processor, cause the server device to:
initiate a secure communication session with the first client device prior to a transition to post-quantum cryptography;
generate a post quantum key for the first client device;
generate authentication data for the post quantum key including a certificate chain for the post quantum key;
generate an authentication signature of the authentication data including the certificate chain for the post quantum key;
transmit, to the first client device, the post quantum key, the authentication data, and the authentication signature to the first client device;
receive an authentication request from the first client device, wherein the authentication request is received subsequent to a transition to post-quantum cryptography, wherein the authentication request includes client authentication data encrypted by the post quantum key for the first client device; and
authenticate the first client device based upon the client authentication data. initiate a secure communication session with the first client device prior to a transition to post-quantum cryptography;
1. A server device for authenticating client devices on a communication network, comprising: a transceiver configured for operable communication with at least one client device of the communication network; a processor including a memory configured to store computer-executable instructions, which, when executed by the processor, cause the server device to: receive an authentication request from a client device, wherein the authentication request is received prior to a transition to post-quantum cryptography; authenticate the client device based upon the authentication request; if the client device is authenticated, generate a seed for a first post quantum key for the client device; if the client device is authenticated, encrypt the seed for the first post quantum key; if the client device is authenticated, transmit, to the client device, an authentication reply including the encrypted seed for the first post quantum key and one or more operations to be performed on the seed for first post quantum key to generate the first post quantum key, wherein the authentication reply is transmitted prior to a transition to post-quantum cryptography; receive a hash of the first post quantum key from the client device, wherein the client device decrypted the seed and performed the one or more operations on the seed to generate the first post quantum key prior to generating the hash of the first post quantum key; and validate the first post quantum key based upon the hash of the first post quantum key.
31 (New) A server device for authenticating client devices on a communication network, comprising a processor including a memory configured to store computer-executable instructions, which, when executed by the processor, cause the server device to: authenticate a client device that stores a first key; determine an update to the first key; transmit, to the client device, the update to the first key and one or more operations to be performed on the update for first key and the first key to generate the updated first key; receive a hash of the updated first key from the client device; and validate the updated first key based on the hash of the updated first key.
10. A server device for authenticating client devices on a communication network, comprising: a transceiver configured for operable communication with at least one client device of the communication network; a processor including a memory configured to store computer-executable instructions, which, when executed by the processor, cause the server device to: receive an authentication request from a client device, wherein the client device stores a first post quantum key, wherein the authentication request is received prior to a transition to post-quantum cryptography; authenticate the client device based upon the authentication request; if the client device is authenticated, determine an update to the first post quantum key; if the client device is authenticated, encrypt the update for the first post quantum key; if the client device is authenticated, transmit, to the client device, an authentication reply including the encrypted update to the first post quantum key and one or more operations to be performed on the update for first post quantum key and the first post quantum key to generate the updated first post quantum key, wherein the authentication reply is transmitted prior to a transition to post-quantum cryptography; receive a hash of the updated first post quantum key from the client device, wherein the client device decrypted the update for the first post quantum key and performed the one or more operations on the update for the first post quantum key and the first post quantum key prior to generating the hash of the updated first post quantum key; and validate the updated first post quantum key based on the hash of the updated first post quantum key.
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.
Claim(s) 31-40 are rejected under 35 U.S.C. 103 as being unpatentable over MOULDS et al. (US 20170244687 A1 –hereinafter—" MOULDS”) in view of Lowans et al. (US US 20130251145 A1 —hereinafter—“ Lowans”).
As per claim 31:
MOULDS discloses a server device for authenticating client devices on a communication network, comprising a processor including a memory configured to store computer-executable instructions, which, when executed by the processor, cause the server device to ([0052] FIG. 3, TA 106 may facilitate in establishing one or more secure communication channels between server 102 and client 104, in authenticating server 102 to client 104, and/or authenticating client 104 to server 102):
authenticate a client device that stores a first key ([0031] a client device configured to securely receive random data from a server, the client device comprising: at least one memory configured to store a client secret key; [0055] As described in further detail below with regard to FIG. 3, TA 204 may facilitate in establishing one or more (e.g., encrypted and integrity validated) communication channels between one or more servers 202 and client 104, in authenticating one or more servers 202 to client 104, and/or in authenticating client 104 to one or more servers 202);
determine an update to the first key ([0078] Assurances regarding authenticity and integrity of random data and other messages can, in some embodiments, be provided by including an HMAC (Hash-based Message Authentication Code) that is calculated for every message sent by both the client (such as client 104) and server (such as server 102). [0079] According to some embodiments, both the client and the server calculate an HMAC on each message they send to allow the receiver to verify the origin of the message and the integrity of the data. This HMAC can prevent an attacker from masquerading as the server and sending less than random data to the clients or from modifying the random data that is being sent to the clients. This HMAC can be calculated using a pre-shared authentication key that is generated at the server during client enrollment with the server, and can be transmitted to the client by a system administrator of the server. Because this authentication key can be generated on the server, the integrity of the authentication key can be assured since the server has a physical random number generator or other source of entropy (such as entropy source 108) providing it with random data. The HMAC key can then be moved onto the client by a system administrator, and can be protected at the client in the fashion deemed suitable by the organization's security policy. For example, the key could be protected in hardware protected and tamper-resistant memory such as that provided by Trusted Platform Module (TPM) chips, smart cards, secure USB memory devices or hardware security modules (HSM));
transmit, to the client device, the update to the first key and one or more operations to be performed on the update for first key and the first key to generate the updated first key ([0013] receiving, at the client device, another set of random data from the server; transforming, at the client device, the another set of random data using random data generated by a pseudorandom number generator local to the client device to derive a fourth set of random data; updating, at the client device, the client secret key based on a first subset of the fourth set of random data; determining, at the client device, a re-key interval based on a second subset of the fourth set of random data; determining, at the client device, when the re-key interval has elapsed; and when the re-key interval has elapsed, refreshing the client secret key ); and
receive a hash of the updated first key from the client device ([0013]updating, at the client device, the client secret key based on a first subset of the fourth set of random data; determining, at the client device, a re-key interval based on a second subset of the fourth set of random data; determining, at the client device, when the re-key interval has elapsed; and when the re-key interval has elapsed, refreshing the client secret key. [0078] Assurances regarding authenticity and integrity of random data and other messages can, in some embodiments, be provided by including an HMAC (Hash-based Message Authentication Code) that is calculated for every message sent by both the client (such as client 104) and server (such as server 102). [0079] According to some embodiments, both the client and the server calculate an HMAC on each message they send to allow the receiver to verify the origin of the message and the integrity of the data. This HMAC can prevent an attacker from masquerading as the server and sending less than random data to the clients or from modifying the random data that is being sent to the clients. This HMAC can be calculated using a pre-shared authentication key that is generated at the server during client enrollment with the server, and can be transmitted to the client by a system administrator of the server. Because this authentication key can be generated on the server, the integrity of the authentication key can be assured since the server has a physical random number generator or other source of entropy (such as entropy source 108) providing it with random data. The HMAC key can then be moved onto the client by a system administrator, and can be protected at the client in the fashion deemed suitable by the organization's security policy).
MOULDS does not explicitly disclose validate the updated first key based on the hash of the updated first key. Lowans, in analogous art however, discloses validate the updated first key based on the hash of the updated first key ([0091]: In the authentication step, each of the nodes Node.sub.X, Node.sub.Y passes to the other a cryptographic hash using the authentication key of a message MYX it passed to the other node in the key agreement step, the cryptographic hash being generated by mean of an authentication key AY which is a `shared secret` between the two nodes Node.sub.X, Node.sub.Y. In FIG. 2 the cryptographic hashes are denoted [MXY].sub.AY and [MYX].sub.AY. Each node compares the hash it receives from the other node with a locally generated equivalent, thus confirming the identity of the other node, hence protecting against a so-called `man-in-the-middle attack`. The whole or part of the quantum key established between the nodes Node.sub.X, Node.sub.Y may be used to generate or update the authentication key AY shared by the two). Therefore, it would have been obvious to a person having ordinary skill in the art before the effective filing date of the invention to modify the claimed limitations of the hash of the updated first key. disclosed by MOULDS to include validate the updated first key. This modification would have been obvious because a person having ordinary skill in the art would have been motivated by the desire to provide quantum key distribution arranged to improve and/or ensure the security of data transmitted thereby by ensuring a certain level of loss within at least part of the network, placing a penultimate and an endpoint nodes in situated in a secure second enclave, analyzing a transmitted bit stream to ensure that it does not provide an unacceptable amount of information about the key that may be generated therefrom, and varying the order in which bits are used to generate a key as suggested by Lowans ([0023-0024]).
As per claim 32: MOULDS in view of Lowans discloses the server device of Claim 31, wherein the server device is further programmed to: encrypt the update for the first key; and transmit, to the client device, the encrypted update to the first key (MOULDS [0016] a client device configured to securely receive encrypted random numbers from a server, the client device receive, via the communication interface, an encrypted set of random data from the server, wherein the encrypted set of random data is derived by encrypting an original set of random data using a server key).
As per claim 33: MOULDS in view of Lowans discloses the server device of Claim 31, wherein the client device is configured to decrypt the update for the first key and perform the one or more operations on the update for the first key on the first key prior to generating the hash of the updated first key (MOULDS [0016] transform the encrypted set of random data by decrypting the encrypted set of random data using a client secret key that is unrelated to the server key to generate a third set of random data that is different from both the encrypted set of random data received by the client device and the original set of random data).
As per claim 34: MOULDS in view of Lowans discloses the server device of Claim 31, wherein the update includes one or more non-reversible operations to be performed on the first key to generate the updated first key (MOULDS [0016] In another aspect, the present disclosure is directed at a client device configured to securely receive encrypted random numbers from a server, the client device comprising: at least one memory configured to store a client secret key; a communication interface configured to receive data from the server; and at least one processor coupled to the at least one memory and the communication interface, the at least one processor configured to: receive, via the communication interface, an encrypted set of random data from the server, wherein the encrypted set of random data is derived by encrypting an original set of random data using a server key, and transform the encrypted set of random data by decrypting the encrypted set of random data using a client secret key that is unrelated to the server key to generate a third set of random data that is different from both the encrypted set of random data received by the client device and the original set of random data).
As per claim 35: MOULDS in view of Lowans discloses the server device of Claim 31, wherein the update includes an update key to be applied to the first key to generate the updated first key (MOULDS [0084] Back to call diagram 300, before, during, or after step 302, T generates two long-term master keys, K and L, which may be two sets of random numbers. T also generates a key encryption key K.sub.S=H(K∥S) and a key authentication key L.sub.S=H(L∥S) for S. T also generates a key encryption key K.sub.C=H(K∥C) and a key authentication key L.sub.C=H(L∥C) for C.
As per claim 36: MOULDS in view of Lowans discloses the server device of Claim 31, wherein the server device is further programmed to: generate a seed for the first key for the client device; transmit the seed for the first key to the client device; receive a hash of the first key from the client device; and validate the first key based on the hash of the first key (MOULDS [0006-0007] securely receiving encrypted random data at a client device from a server, the method comprising: receiving, at the client device, an encrypted set of random data from the server, wherein the encrypted set of random data is derived by encrypting an original set of random data using a server key; and transforming, at the client device, the encrypted set of random data by decrypting the encrypted set of random data using a client secret key that is unrelated to the server key to generate a third set of random data that is different from both the encrypted set of random data received by the client device and the original set of random data. The encrypted set of random data is derived by encrypting the original set of random data using the server key according to a symmetric key encryption-decryption algorithm; and the encrypted set of random data is transformed at the client device by decrypting the encrypted set of random data according to the same symmetric key encryption-decryption algorithm, using the client secret key that is different from the server key).
As per claim 37: MOULDS in view of Lowans discloses the server device of Claim 36, wherein the server device is further programmed to transmit, to the client device, at least one operation for the client device to perform on the seed of the first key to generate the first key (MOULDS [0015] using the third set of random data as a seed for a pseudorandom number generator local to the client device, or to calculate a key for encrypting data for transmission or storage. [0040] configured to use the second set of random data as a seed for a pseudorandom number generator local to the client device, or to calculate a key for encrypting data for transmission or storage).
As per claim 38: MOULDS in view of Lowans discloses the server device of Claim 36, wherein the seed for the first key is transmitted prior to availability of post-quantum cryptography (Lowans [0063] The PRNGs may be seeded with a shared value, which may comprise an identity key. Shared values may be distributed as is familiar from known QKD techniques to update identity keys, session keys, traffic keys, or the like. [0156])
As per claim 39: MOULDS in view of Lowans discloses the server device of Claim 31, wherein the server device is further programmed to: receive a seed for a server key from the client device; generate the server key from the seed; generate a hash of the server key; and transmit the hash of the server key to the client device for validation (MOULDS [0074] In step 406, the reseed interval is converted to an integer and serves as the new reseed interval for the current client secret key. In step 408, the newly generated key is XOR'd with the existing client secret key. In step 410, the result of the XOR in step 408 is used as an updated client secret key for subsequent client-side transformations (using, for example, an AES encryption algorithm). In step 408, the new key could also simply be used to replace the old key or be combined with the old key in some other way. In step 412, each time the client determines it is time to use the client secret key to transform random data received from the server, the client determines whether the reseed interval has been exhausted in step 412. The reseed interval may either represent a number of times that the client secret key may be used before it needs to be refreshed, an amount of time that the client secret key may be used for (irrespective of how many times it is used during that amount of time). If the reseed interval has not been exhausted, the current client secret key continues to be used. If the reseed interval has been exhausted, the process begins again at step 402).
As per claim 40: MOULDS in view of Lowans discloses the server device of Claim 39, wherein the server device is further programmed to: receive, from the client device, at least one operation to perform on the seed of the server key to generate the server key; and perform the at least one operation on the seed to generate the server key (MOULDS [0009] In some embodiments, the encrypted set of random data is derived by encrypting the original set of random data using the server key according to an asymmetric key encryption-decryption algorithm; and the encrypted set of random data is transformed at the client device by decrypting the encrypted set of random data according to the same asymmetric key encryption-decryption algorithm, using the client secret key that is different from the server key, wherein the client secret key is not mathematically related to the server key according to requirements of the asymmetric key encryption-decryption algorithm. [0010] In some embodiments, the encrypted set of random data is derived by encrypting the original set of random data using the server key according to a first encryption-decryption algorithm; and the encrypted set of random data is transformed at the client device by decrypting the encrypted set of random data according to a second encryption-decryption algorithm).
Allowable Subject Matter
Claim 21-30 are allowable over prior arts of record The following is a statement of reasons for the indication of allowable subject matter: After consideration of the applicant’s correspondence filed on October 17, 2025 through examination of the application, claims, and conducted search, the pertinent prior arts of record, either taken alone or in combination neither anticipates nor renders obvious the claimed subject matter of the instant application when taken as a whole and therefore claims 21-30 having the following features would be in condition for allowance , based on condition after resolving any outstanding objections or rejections provided in this Office Action Correspondence.
As per claim 21 : initiate a secure communication session with the first client device prior to a transition to post-quantum cryptography; generate a post quantum key for the first client device; generate authentication data for the post quantum key including a certificate chain for the post quantum key; generate an authentication signature of the authentication data including the certificate chain for the post quantum key; transmit, to the first client device, the post quantum key, the authentication data, and the authentication signature to the first client device; receive an authentication request from the first client device, wherein the authentication request is received subsequent to a transition to post-quantum cryptography, wherein the authentication request includes client authentication data encrypted by the post quantum key for the first client device; and authenticate the first client device based upon the client authentication data.
The prior art made of record and not relied upon is considered pertinent to applicant's disclosure.
Jacobs (US 20130315395 A1) discuses a way for two quantum key distribution systems to prove to each other that they are legitimate without spending or revealing their secret authentication keys. Each side sends or receives quantum events, such as photon polarization states, and then builds a raw key from the events it transmitted or detected. The systems openly share only limited information, such as which detection intervals matched up, which bases were used, and some parity information. Using that limited information, both sides independently sift their raw keys, detect and correct errors, and optionally apply privacy amplification. The same pre-provisioned secret authentication key is also used locally to seed identical pseudo-random processes on both sides. Because both sides use the same hidden key and the same disclosed public data, they should arrive at matching authenticated encryption keys if the link is legitimate.
Carter, Jr. US 11356247 B1 discuses generating a first quantum one-time pad having a first set of entangled quantum particles. It subsequently stores the first set of entangled quantum particles in a first set of quantum storage cells. Each entangled quantum particle in the first set of entangled quantum particles may be stored in a respective quantum storage cell in the first set of quantum storage cells. Further, each entangled quantum particle in the first set of entangled quantum particles may be entangled with a respective entangled quantum particle in a second set of entangled quantum particles comprised by a second quantum one-time pad and stored in a second set of quantum storage cells.
Griffin et al. (US 11212090 B1)a method for using symmetric keys between two entities comprising a device and a host include initiating, by the device, a transaction involving original data, wherein the original data needs to be verified by the host. The method further includes deriving, by the device, a first key based on a previously generated key and a first number, wherein the first key is unique to the transaction, and the first number is randomly generated. The method further includes sending, by the device, the first key to the host for verification.
Contact Information
Any inquiry concerning this communication or earlier communications from the examiner should be directed to TECHANE GERGISO whose telephone number is (571)272-3784. The examiner can normally be reached 9:30am to 6:30pm.
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, LINGLAN EDWARDS can be reached at (571) 270-5440. 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.
/TECHANE GERGISO/Primary Examiner, Art Unit 2408
Prosecution Insights