DETAILED ACTION
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.
Continued Examination Under 37 CFR 1.114
A request for continued examination under 37 CFR 1.114, including the fee set forth in 37 CFR 1.17(e), was filed in this application after final rejection. Since this application is eligible for continued examination under 37 CFR 1.114, and the fee set forth in 37 CFR 1.17(e) has been timely paid, the finality of the previous Office action has been withdrawn pursuant to 37 CFR 1.114. Applicant's submission filed on 04/22/2026 has been entered.
Claims 1, 47-49, 58-59 are amended.
Claims 2-42, 52-53 are cancelled.
Claims 1, 43-51, 54-59 are pending.
Response to Arguments
Applicant’s arguments with respect to claim(s) 1, 41-46, 52-57 have been considered but are moot because the new ground of rejection does not rely on any reference applied in the prior rejection of record for any teaching or matter specifically challenged in the argument.
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, 43-46, 54-57 are rejected under 35 U.S.C. 103 as being unpatentable over Fu (U. S. Pat. No. 10,855,452 B2) (hereinafter “Fu”) in view of Parry et al. (U. S. Pat. No. 11,652,620 B2) (hereinafter “Parry”)
Regarding Claim 1, Fu teaches:
A quantum key distribution (QKD) protocol adapter comprising (Fu: [Col 5, lines 61-63], (33) Bennett-Brassard-84 (BB84) is a popular quantum key distribution protocol. BB84 uses the polarization states of single photons to transmit information) at least one processor configured to: (Fu: [Col 19, lines 17-21], (100) From these various memory units, processing unit(s) 1212 retrieves instructions to execute and data to process in order to execute the processes of the subject disclosure. The processing unit(s) can be a single processor or a multi-core processor in different implementations)
Present a QKD protocol to a network element (Fu: [Col 4, lines 9-17], (20) To ensure safety of the keys, the subkeys can be encrypted using a quantum key obtained via a quantum key distribution (QKD) process before being sent to the cloud server. [Col 7, lines 34-42], QKD modules 106 and 108 can couple to each other via a quantum channel 110. VPNs 102 and 104 are coupled to each other via a classical or conventional communication channel 112. QKD modules 106 and 108 can facilitate quantum key exchanges, and the HSMs of VPNs 102 and 104 can each obtain and maintain the negotiated quantum key from the corresponding QKD module. Using the quantum key, VPNs 102 and 104 can communicate with each other in a secure manner);
use a key management protocol to communicate with a hardware security module (HSM) (Fu: [Col 4, lines 2834], (21) Quantum key distribution mechanisms can ensure the secrecy of the keys, thus ensuring the security of data transmission. Trusted computing can be used for authentication of the client and server and for ensuring the integrity of the client and server. The combination of quantum key distribution and trusted computing can enhance security in a cloud computing environment. [Col 9, lines 49-56], More specifically, on the QKD-enabled communication channels, communication partners can negotiate encryption keys using the quantum channel and then use the negotiated keys for secure communication. For example, a user within user group 316 can communicate with the cloud servers using the quantum-enhanced secure channel. Moreover, the user can perform initial configuration of his cloud-HSM via the QKD-enabled communication channels. [Col 7, lines 22-28], To further enhance security, cloud-HSMs may implement a quantum key distribution mechanism. More superficially, a quantum-key-based HSM can include a quantum key injection module that can couple, via various types of interface (e.g., a network interface, a universal serial bus (USB) interface, or a console interface), to quantum key distribution equipment to obtain quantum keys);
use group shared keys provided to the HSM by a QKD system (Fu: [Col 4, lines 19-24], To establish a secure communication channel, the server and client can negotiate, using a quantum key exchange mechanism, one or more shared keys (=group shared key). The shared key or keys can be saved into the TCPs of the cloud client and the cloud server. The cloud client and server can communicate with each other using the shared key or keys. [Col 5, lines 64-65], A QKD process (e.g., BB84) can be performed to allow trusted client 402 and trusted server 404 to obtain a shared key);
Fu does not explicitly disclose:
wherein the QKD protocol is ETSI QKD or a protocol for secure key integration;
respond to key status information requests and key requests from the network element in the QKD protocol by interacting with the HSM using the key management protocol, and provide the requested key status information and keys to the network element in the QKD protocol.
However, in an analogous art, Parry teach:
wherein the QKD protocol is ETSI QKD or a protocol for secure key integration (Parry: [Col 15, lines 10-13], QKD capacity rate monitoring routines are shown for determining available keys in a QKD device 24. In FIG. 14, the routine is adapted for use with the ETSI GS QKD 014 API. [Col 14, lines 35-45], (70) Using the standards specification of ETSI GS QKD 014, allows for a client to query the QKD device 24 for the quantity of key material available for retrieval via an API. Vendors may have other implemented APIs to provide this information as well. With such APIs, there are three API endpoints, namely one to get keys for the first time, one to get keys with specific IDs (done by the second client using a QKD pair), and a “status” endpoint that has a few data metrics, such as stored key count (number of keys available) and max key count (maximum number of the stored key count);
respond to key status information requests and key requests from the network element in the QKD protocol by interacting with the HSM using the key management protocol, (Parry: [Col 14, lines 35-37], (70) Using the standards specification of ETSI GS QKD 014, allows for a client to query (=request) the QKD device 24 for the quantity of key material available for retrieval via an API. [Col 10, lines 37-39], allowing an immediate response (when keys are available) to key requests without the overhead and latency of an added synchronization protocol).
and provide the requested key status information (Parry (US 11,652,620 B2): [Col 14, lines 45-48], Using the ETSI GS QKD 014 “get status” (=key status) API endpoint, the client can poll the QKD device 24 to determine how many keys are available to retrieve as well as the maximum number of keys it can store) and keys to the network element in the QKD protocol (Parry (US 11,652,620 B2): [Col 15, lines 13-17], the client queries the ETSI 014 device using the “get status” API at step 200 to determine at step 202 if any keys are available. If so, the available keys are requested by the client at step 204 using the ETSI 014 “get keys” API (=keys)).
It would be obvious to a person having ordinary skill in the art, before the effective filing date of the invention, to modify Fu’s method of establishing one or more shared keys to securely communicate between client and server by applying Parry’s method of determining how may keys are available using “get status” API and if keys are available then retrieving keys using “get keys” API, in order to enabling seamless integration, strong interoperability and protection against quantum threats. The Motivation is to provide a quantum computer to solve problems of a practical scale, currently-deployed conventional public key cryptography is felt to be critically vulnerable to attack, and a new way of protecting transactions over a network. (Parry: [Col 1, lines 32]).
Regarding claim 43, Fu in view Parry teaches:
The adapter of claim 1 (see rejection of claim 1 above),
in which the key management protocol is Key Management Interoperability Protocol (KMIP) or Public-Key Cryptography Standards #11 (PKCS #11) (Fu: [Col 7, lines 15-18], A typical front-end API of the cloud-HSM can be provided in the form of the C standard library and can support a standard interface such as PKCS #11, Bsafe, CDSA, etc).
Regarding claim 44, Fu in view Parry teaches:
The adapter of claim 1 (see rejection of claim 1 above),
in which the group shared keys are QKD keys (Fu: [Col 4, lines 18-22], To establish a secure communication channel, the server and client can negotiate, using a quantum key exchange mechanism, one or more shared keys. The shared key or keys can be saved into the TCPs of the cloud client and the cloud server. [Col 7, lines 24-29], More superficially, a quantum-key-based HSM can include a quantum key injection module that can couple, via various types of interface (e.g., a network interface, a universal serial bus (USB) interface, or a console interface), to quantum key distribution equipment to obtain quantum keys).
Regarding claim 45, Fu in view Parry teaches:
The adapter of claim 1 (see rejection of claim 1 above),
in which the QKD system is a satellite QKD system (Parry: [Col 13, lines 27-36], (62) QKD devices 24 are currently known to have a limited amount of storage space. This range from large traditional servers hosting a QKD link 28 to relatively small storage capacity satellite-based QKD link 28. As QKD keys are retrieved through real time use or as part of an optimized key swap solution (e.g., as described above), there are found, almost always, to be one or more QKD links 28 that have unretrieved keys over some period of time. For example, link 100.fwdarw.101 shown in FIG. 9 might have a surplus of 512 bps).
It would be obvious to a person having ordinary skill in the art, before the effective filing date of the invention, to modify Fu’s method of establishing one or more shared keys to securely communicate between client and server by applying Parry’s method of providing satellite-based QKD link, in order to achieving global-scale quantum communication, and minizine photon loss. The Motivation is to provide a quantum computer to solve problems of a practical scale, currently-deployed conventional public key cryptography is felt to be critically vulnerable to attack, and a new way of protecting transactions over a network. (Parry: [Col 1, lines 32]).
Regarding claim 46, Fu in view Parry teaches:
The adapter of claim 1 (see rejection of claim 1 above),
in which the group shared keys are shared by a group of two or more network elements (Fu: [Col 4, lines 19-27], To establish a secure communication channel, the server and client can negotiate, using a quantum key exchange mechanism, one or more shared keys. The shared key or keys can be saved into the TCPs of the cloud client and the cloud server. The cloud client and server can communicate with each other using the shared key or keys. Moreover, messages exchanged between the client and server need to carry the platform configuration register (PCR) values encrypted with a shared key to ensure the integrity of the client and server during transmission).
Regarding claim 54, Fu in view Parry teaches:
The adapter of claim 49 (see rejection of claim 49 above),
in which the secure key store is a hardware security module (HSM), or a secure store implemented by a secure enclave or a secure in- memory cache (Fu: [Col 16, 3-12], Subsequent to the mutual authentication, the server can then negotiate, using a QKD process, one or more quantum keys with the client (operation 928), and store the negotiated keys in its TPM (operation 930). Subsequent to the key negotiation, the server can communicate with the client using the negotiated keys (operation 932). In some embodiments, during communication, the server can include its trusted platform information (e.g., PCR values) in each message sent to the client to allow the client to determine the platform integrity of the server).
Regarding claim 55, this claim contains identical limitations found within that of claim 43. For this reason the same grounds of rejection are applied to claim 55.
Regarding claim 56, this claim contains identical limitations found within that of claim 44. For this reason the same grounds of rejection are applied to claim 56.
Regarding claim 57, this claim contains identical limitations found within that of claim 46. For this reason the same grounds of rejection are applied to claim 57.
Claim(s) 47-51 and 58-59 are rejected under 35 U.S.C. 103 as being unpatentable over Fu (U. S. Pat. No. 10,855,452 B2) (hereinafter “Fu”) in view of Parry et al. (U. S. Pat. No. 11,652,620 B2) (hereinafter “Parry”); and further in view of Elliott et al. (U. S. PGPub. No. 2004/0120528 A1) (hereinafter “Elliott”)
Regarding claim 47, Fu in view Parry teaches:
The system of claim 46 (see rejection of claim 46 above),
combination with a network element, wherein the network element is arranged to cooperate with other network elements of the group of two or more network elements (Elliott: [0029] First enclave 102 and second enclave 104 may be a node, a device, such as a personal computer, or a plurality of devices or nodes coupled together by a network. For example, as shown, first enclave 102 and second enclave 104 may include a local area network, such as an Ethernet network, that interconnects a group of devices such as personal computers 110a-b, 110c-e, and printers 112a, and 112b, respectively. First enclave 102 and second enclave 104 may include other types of devices not shown, such as laptop computers, servers, firewalls, or personal digital assistants. First enclave 102 may also include other types of networks, such as a wide area network or a wireless network) to mutually agree on a group key for use to establish secure communications between the group of two or more network elements [Elliott: [0007], These algorithms are known as secret-key algorithms or single-key algorithms and require that a sender and receiver agree on at least one key before they can communicate secured information)
A person having ordinary skill in the art, before the effective filing date of the invention, would have found it obvious to modify Fu in view Parry by applying the well-known technique as disclosed by Elliott of one key agreement between sender and receiver before they can communicate with each other. The motivation is to ensure the security of the sequence of bits, the sequence of bits is encrypted based on the respective pairwise keys of neighboring nodes as it is forwarded in messages through the messaging network (Elliott: [Abstract]).
Regarding claim 48, Fu in view Parry teaches:
The system of claim 47(see rejection of claim 47 above),
wherein the network element is arranged to cooperate with other network elements of the group of two or more network elements (Elliott: [0029] First enclave 102 and second enclave 104 may be a node, a device, such as a personal computer, or a plurality of devices or nodes coupled together by a network. For example, as shown, first enclave 102 and second enclave 104 may include a local area network, such as an Ethernet network, that interconnects a group of devices such as personal computers 110a-b, 110c-e, and printers 112a, and 112b, respectively. First enclave 102 and second enclave 104 may include other types of devices not shown, such as laptop computers, servers, firewalls, or personal digital assistants. First enclave 102 may also include other types of networks, such as a wide area network or a wireless network) to mutually agree on a group key for use to establish secure communications between the group of two or more network elements by (Elliott: [0007], Symmetric algorithms are algorithms where the encryption key can be calculated from the decryption key and vice versa. In most symmetric algorithms, the encryption key and decryption key are the same. These algorithms are known as secret-key algorithms or single-key algorithms and require that a sender and receiver agree on at least one key before they can communicate secured):
arranging the network elements of the group of two or more network elements into pairs (Elliott: [0017], A set of nodes are coupled to the first network and the second network. Nodes that neighbor each other (=pairs) in the second network establish respective keys. The nodes are configured to then communicate the sequence of bits from the first node to the second node through the first network based on the respective keys established through the second network);
each pair of network elements agreeing a key between them (Elliott: [0007], Symmetric algorithms are algorithms where the encryption key can be calculated from the decryption key and vice versa. In most symmetric algorithms, the encryption key and decryption key are the same. These algorithms are known as secret-key algorithms or single-key algorithms and require that a sender and receiver agree on at least one key (=a key) before they can communicate secured information).;
and using the agreed keys of the pairs of network elements to generate a group key for use by all of the network elements of the group of two or more network elements (Elliott: [0007], Symmetric algorithms are algorithms where the encryption key can be calculated from the decryption key and vice versa. In most symmetric algorithms, the encryption key and decryption key are the same. These algorithms are known as secret-key algorithms or single-key algorithms and require that a sender and receiver agree on at least one key (=agreed key) before they can communicate secured information. [0026] The nodes that neighbor each other in the key distribution network establish respective pairwise keys (=a group key)).
A person having ordinary skill in the art, before the effective filing date of the invention, would have found it obvious to modify Fu in view Parry by applying the well-known technique as disclosed by Elliott of establish respective pairwise keys for the nodes that neighbor each other in the key distribution network. The motivation is to ensure the security of the sequence of bits, the sequence of bits is encrypted based on the respective pairwise keys of neighboring nodes as it is forwarded in messages through the messaging network (Elliott: [Abstract]).
Regarding Claim 49, Fu teaches:
A quantum key distribution (QKD) protocol adapter comprising (Fu: [Col 5, lines 61-63], (33) Bennett-Brassard-84 (BB84) is a popular quantum key distribution protocol. BB84 uses the polarization states of single photons to transmit information):
a first interface presenting a QKD protocol to a network element (Fu: [Col 4, lines 9-17], (20) To ensure safety of the keys, the subkeys can be encrypted using a quantum key obtained via a quantum key distribution (QKD) process before being sent to the cloud server. [Col 7, lines 34-42], QKD modules 106 and 108 can couple to each other via a quantum channel 110. VPNs 102 and 104 are coupled to each other via a classical or conventional communication channel 112. QKD modules 106 and 108 can facilitate quantum key exchanges, and the HSMs of VPNs 102 and 104 can each obtain and maintain the negotiated quantum key from the corresponding QKD module. Using the quantum key, VPNs 102 and 104 can communicate with each other in a secure manner);
a second interface arranged to use a key management protocol to communicate with a secure key store (Fu: Col 6, lines 61-67 -Col 7, lines 1-4], (38) Certain advanced cryptographic technologies can be applied into cloud computing to increase the data security, including the use of hardware security modules (HSMs). An HSM is a hardware appliance that provides secure key storage and cryptographic operations within a tamper-resistant hardware device. HSMs are designed to securely store cryptographic key material and use the key material without exposing it outside the cryptographic boundary of the appliance. Typical HSMs can come in the form of a plug-in card or an external device that attaches directly to a computer or network server);
the adapter being arranged to use group shared keys provided to the secure key store by a cloud service (Fu: [Col 4, lines 19-24], To establish a secure communication channel, the server and client can negotiate, using a quantum key exchange mechanism, one or more shared keys (=group shared key). The shared key or keys can be saved into the TCPs of the cloud client and the cloud server. The cloud client and server can communicate with each other using the shared key or keys. [Col 5, lines 64-65], A QKD process (e.g., BB84) can be performed to allow trusted client 402 and trusted server 404 to obtain a shared key);
Fu does not explicitly disclose:
and the adapter being arranged to respond to key status requests and key requests from the network element in the QKD protocol by interacting with the secure key store using the key management protocol,
and being arranged to provide the requested key status information and keys to the network element in the QKD protocol and the network element.
However in an analogous art Parry teach:
and the adapter being arranged to respond to key status requests and key requests from the network element in the QKD protocol by interacting with the secure key store using the key management protocol (Parry: [Col 14, lines 35-37], (70) Using the standards specification of ETSI GS QKD 014, allows for a client to query (=request) the QKD device 24 for the quantity of key material available for retrieval via an API. [Col 10, lines 37-39], allowing an immediate response (when keys are available) to key requests without the overhead and latency of an added synchronization protocol).
and being arranged to provide the requested key status information (Parry (US 11,652,620 B2): [Col 14, lines 45-48], Using the ETSI GS QKD 014 “get status” (=key status) API endpoint, the client can poll the QKD device 24 to determine how many keys are available to retrieve as well as the maximum number of keys it can store) and keys to the network element in the QKD protocol (Parry (US 11,652,620 B2): [Col 15, lines 13-17], the client queries the ETSI 014 device using the “get status” API at step 200 to determine at step 202 if any keys are available. If so, the available keys are requested by the client at step 204 using the ETSI 014 “get keys” API (=keys)).
It would be obvious to a person having ordinary skill in the art, before the effective filing date of the invention, to modify Fu’s method of establishing one or more shared keys to securely communicate between client and server by applying Parry’s method of determining how may keys are available using “get status” API and if keys are available then retrieving keys using “get keys” API, in order to enabling seamless integration, strong interoperability and protection against quantum threats. The Motivation is to provide a quantum computer to solve problems of a practical scale, currently-deployed conventional public key cryptography is felt to be critically vulnerable to attack, and a new way of protecting transactions over a network. (Parry: [Col 1, lines 32]).
Fu in view of parry does not explicitly disclose:
the adapter being arranged to perform agreement of keys with at least one another adapter through the cloud service;
However, in an analogous art, Elliott teach:
the adapter being arranged to perform agreement of keys with at least one another adapter through the cloud service (Elliott: [0028] associating a trust level to each correspondent; each of the correspondents using the public key and the group key for performing key agreement in order to establish secure communication within the group [0051] Referring to FIG. 7 and FIG. 8, in order to establish a secure communication between device A and B, device A performs the steps of acquiring device B's full static address or device ID and a public key or symmetric key in order to perform key agreement, in step 110);
A person having ordinary skill in the art, before the effective filing date of the invention, would have found it obvious to modify Fu in view Parry by applying the well-known technique as disclosed by Elliott of using group key for performing key agreement in order to establish secure communication within the group. The motivation is to ensure the security of the sequence of bits, the sequence of bits is encrypted based on the respective pairwise keys of neighboring nodes as it is forwarded in messages through the messaging network (Elliott: [Abstract]).
Regarding claim 50, Fu in view Parry teaches:
The adapter of claim 49 (see rejection of claim 49 above),
in which the adapter is arranged to perform pre-agreement of keys with at least one another adapter through the cloud service [Elliott: [0007], These algorithms are known as secret-key algorithms or single-key algorithms and require that a sender and receiver agree on at least one key before they can communicate secured information).
A person having ordinary skill in the art, before the effective filing date of the invention, would have found it obvious to modify Fu in view Parry by applying the well-known technique as disclosed by Elliott of using group key for performing key agreement in order to establish secure communication within the group. The motivation is to ensure the security of the sequence of bits, the sequence of bits is encrypted based on the respective pairwise keys of neighboring nodes as it is forwarded in messages through the messaging network (Elliott: [Abstract]).
Regarding claim 51, Fu in view Parry teaches:
The adapter of claim 49 (see rejection of claim 49 above),
The Fu in view Parry does not explicitly disclose:
in which the adapter is arranged to perform dynamic agreement of keys with at least one another adapter through the cloud service.
However, in an analogous art, Elliott teach:
in which the adapter is arranged to perform dynamic agreement of keys with at least one another adapter through the cloud service (Elliott: [0028] associating a trust level to each correspondent; each of the correspondents using the public key and the group key for performing key agreement in order to establish secure communication within the group [0051] Referring to FIG. 7 and FIG. 8, in order to establish a secure communication between device A and B, device A performs the steps of acquiring device B's full static address or device ID and a public key or symmetric key in order to perform key agreement, in step 110).
A person having ordinary skill in the art, before the effective filing date of the invention, would have found it obvious to modify Fu in view Parry by applying the well-known technique as disclosed by Elliott of using group key for performing key agreement in order to establish secure communication within the group. The motivation is to ensure the security of the sequence of bits, the sequence of bits is encrypted based on the respective pairwise keys of neighboring nodes as it is forwarded in messages through the messaging network (Elliott: [Abstract]).
Regarding claim 58, Fu teaches:
A system comprising: a quantum key distribution (QKD) protocol adapter configured to (Fu: [Col 5, lines 61-63], (33) Bennett-Brassard-84 (BB84) is a popular quantum key distribution protocol. BB84 uses the polarization states of single photons to transmit information):
present a QKD protocol to a network element (Fu: [Col 4, lines 9-17], (20) To ensure safety of the keys, the subkeys can be encrypted using a quantum key obtained via a quantum key distribution (QKD) process before being sent to the cloud server. [Col 7, lines 34-42], QKD modules 106 and 108 can couple to each other via a quantum channel 110. VPNs 102 and 104 are coupled to each other via a classical or conventional communication channel 112. QKD modules 106 and 108 can facilitate quantum key exchanges, and the HSMs of VPNs 102 and 104 can each obtain and maintain the negotiated quantum key from the corresponding QKD module. Using the quantum key, VPNs 102 and 104 can communicate with each other in a secure manner);
use a key management protocol to communicate with a secure key store (Fu: Col 6, lines 61-67 -Col 7, lines 1-4], (38) Certain advanced cryptographic technologies can be applied into cloud computing to increase the data security, including the use of hardware security modules (HSMs). An HSM is a hardware appliance that provides secure key storage and cryptographic operations within a tamper-resistant hardware device. HSMs are designed to securely store cryptographic key material and use the key material without exposing it outside the cryptographic boundary of the appliance. Typical HSMs can come in the form of a plug-in card or an external device that attaches directly to a computer or network server);
use group shared keys provided to the secure key store by a cloud service (Fu: [Col 4, lines 19-24], To establish a secure communication channel, the server and client can negotiate, using a quantum key exchange mechanism, one or more shared keys (=group shared key). The shared key or keys can be saved into the TCPs of the cloud client and the cloud server. The cloud client and server can communicate with each other using the shared key or keys. [Col 5, lines 64-65], A QKD process (e.g., BB84) can be performed to allow trusted client 402 and trusted server 404 to obtain a shared key), wherein the group shared keys are shared by a group of two or more network elements (Fu: [Col 4, lines 22-24], The cloud client and server can communicate with each other using the shared key or keys) [Col 6, lines 38-40], In cloud computing, security responsibility is shared between cloud providers and users of the cloud services);
Fu does not explicitly disclose:
respond to key status requests and key requests from the network element in the QKD protocol by interacting with the secure key store using the key management protocol and being arranged to provide the requested key status information or keys to the network element in the QKD protocol and the network element.
However in an analogues art, Parry teach:
respond to key status requests and key requests from the network element in the QKD protocol by interacting with the secure key store using the key management protocol (Parry: [Col 14, lines 35-37], (70) Using the standards specification of ETSI GS QKD 014, allows for a client to query (=request) the QKD device 24 for the quantity of key material available for retrieval via an API. [Col 10, lines 37-39], allowing an immediate response (when keys are available) to key requests without the overhead and latency of an added synchronization protocol).
provide the requested key status information (Parry (US 11,652,620 B2): [Col 14, lines 45-48], Using the ETSI GS QKD 014 “get status” (=key status) API endpoint, the client can poll the QKD device 24 to determine how many keys are available to retrieve as well as the maximum number of keys it can store) and keys to the network element in the QKD protocol and the network element, (Parry (US 11,652,620 B2): [Col 15, lines 13-17], the client queries the ETSI 014 device using the “get status” API at step 200 to determine at step 202 if any keys are available. If so, the available keys are requested by the client at step 204 using the ETSI 014 “get keys” API (=keys)).
It would be obvious to a person having ordinary skill in the art, before the effective filing date of the invention, to modify Fu’s method of establishing one or more shared keys to securely communicate between client and server by applying Parry’s method of determining how may keys are available using “get status” API and if keys are available then retrieving keys using “get keys” API, in order to enabling seamless integration, strong interoperability and protection against quantum threats. The Motivation is to provide a quantum computer to solve problems of a practical scale, currently-deployed conventional public key cryptography is felt to be critically vulnerable to attack, and a new way of protecting transactions over a network. (Parry: [Col 1, lines 32]).
The Fu in view Parry does not explicitly disclose:
perform agreement of keys with at least one another adapter through the cloud service;
wherein the network element is arranged to cooperate with other network elements of the group of two or more network elements to mutually agree a group key for use to establish secure communications between the group of two or more network elements.
However, in an analogous art, Elliott teach:
perform agreement of keys with at least one another adapter through the cloud service (Elliott: [0028] associating a trust level to each correspondent; each of the correspondents using the public key and the group key for performing key agreement in order to establish secure communication within the group [0051] Referring to FIG. 7 and FIG. 8, in order to establish a secure communication between device A and B, device A performs the steps of acquiring device B's full static address or device ID and a public key or symmetric key in order to perform key agreement, in step 110);
wherein the network element is arranged to cooperate with other network elements of the group of two or more network elements (Elliott: [0029] First enclave 102 and second enclave 104 may be a node, a device, such as a personal computer, or a plurality of devices or nodes coupled together by a network. For example, as shown, first enclave 102 and second enclave 104 may include a local area network, such as an Ethernet network, that interconnects a group of devices such as personal computers 110a-b, 110c-e, and printers 112a, and 112b, respectively. First enclave 102 and second enclave 104 may include other types of devices not shown, such as laptop computers, servers, firewalls, or personal digital assistants. First enclave 102 may also include other types of networks, such as a wide area network or a wireless network) to mutually agree a group key for use to establish secure communications between the group of two or more network elements (Elliott: [0007], Symmetric algorithms are algorithms where the encryption key can be calculated from the decryption key and vice versa. In most symmetric algorithms, the encryption key and decryption key are the same. These algorithms are known as secret-key algorithms or single-key algorithms and require that a sender and receiver agree on at least one key before they can communicate secured).
A person having ordinary skill in the art, before the effective filing date of the invention, would have found it obvious to modify Fu in view Parry by applying the well-known technique as disclosed by Elliott of using group key for performing key agreement in order to establish secure communication within the group. The motivation is to ensure the security of the sequence of bits, the sequence of bits is encrypted based on the respective pairwise keys of neighboring nodes as it is forwarded in messages through the messaging network (Elliott: [Abstract]).
Regarding Claim 59, this claim contains identical limitations found within that of claim 48. For this reason the same grounds of rejection are applied to claim 59.
Conclusion
The prior art made of record and not relied upon is considered pertinent to a disclosure. Refer to PTO-892, Notice of References Cited for a listing of analogous art.
KO et al. (U. S. PGPub. No. 2022/0006627 A1): A quantum key distribution (QKD) node apparatus and a QKD method therein. The QKD node apparatus may include a QKD module for generating quantum keys and quantum key IDs, a quantum key synchronization management module for storing the quantum keys and the quantum key IDs as outbound and inbound quantum keys in a distributed manner and sharing the outbound and inbound quantum keys with a second QKD node apparatus, and a quantum key orchestration module for delivering a master key and a master key ID to a secure application connected therewith in response to a request for the master key with the ID of a second secure application and delivering a packet including the master key encrypted with the outbound quantum key shared with the second QKD node apparatus, the master key ID, and a quantum key ID, to the second QKD node apparatus.
Hay et al. (U. S. Pat. No. 11,424,918 B2): A trusted node, for quantum key distribution, has a quantum key engine, a quantum key controller and a trusted node controller. The quantum key engine exchanges quantum keys. The quantum key controller directs encryption and decryption. The trusted node controller directs the quantum key controller and the quantum key engine, and has no direct access to keys and data protected by the system, including unencrypted quantum keys.
Any inquiry concerning this communication or earlier communications from the examiner should be directed to RUPALI DHAKAD whose telephone number is (571)270-3743. The examiner can normally be reached M-F 8:30-5:30.
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, Alexander Lagor can be reached at 5712705143. 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.
/R.D./Examiner, Art Unit 2437
/ALI S ABYANEH/Primary Examiner, Art Unit 2437
Prosecution Insights