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.
Response to Arguments
Applicant’s arguments, see page 6, filed 12/23/2025, with respect to 42, 47-48, 53 have been fully considered and are persuasive. The rejection under 35 USC § 112 (b) of 09/23/2023 has been withdrawn.
Applicant's arguments filed 12/23/2025 have been fully considered but they are not persuasive.
Applicant argues about rejection under 35 USC § 103 :
“First, taking claim 1 as an example, the proposed Fu-Tysowski combination fails to teach, suggest, or disclose "an adapter" configured to both "present a QKD protocol to a network element" and "use a key management protocol to communicate with a hardware security module (HSM)…..The proposed Fu-Tysowski combination also fails to teach, suggest, or disclose an adapter that "respond[s] to key status requests and key requests ... in the QKD protocol by interacting with the HSM using the key management protocol," as recited in claim 1.”…. “However, system 300 of Fu, whether considered alone or in combination with any of the other cited references, does not disclose or suggest a QKD adapter between any of the nodes that wish to communicate with each.
Examiner respectfully disagree because Fu in para [Col 4, lines 19-24 ] discloses a QKD-process in which server and client can negotiate, using quantum key exchange mechanism, one or more shared keys (=group shared key)… thereby inherently providing an interface between QKD processes, HSM key management, and network elements.
Also Fu disclose in [Col 7, lines 22-28], 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).
The prior art does not require to use the exact term “quantum key distribution protocol adapter” where it disclose equivalent structure or functionality. Further BB84 inherently requires interfacing between classical communication systems and quantum photon transmission systems, which corresponds to the claimed functionality.
Under the broadest reasonable interpretation, a quantum protocol adapter encompasses components configures to enable or interface communication according to a quantum communication protocol. The encoding, decoding and processing operations disclosed in the cited reference perform this functionality by adapting classical information for transmission via quantum polarization states and converting measured quantum states back into classical information.
Additionally Applicant argues:
Therefore, the QKD protocol (as defined in claim 1) in which the adapter "present[s] a QKD protocol to a network element" is not equivalent to the QKD scheme (such as the BB84 protocol) disclosed by Fu”.
Examiner respectfully disagree because Fu disclose in [Col 4, lines 9-17], QKD process in which QKD module can facilitate quantum key exchange to communicate with each other in a secure manner via a quantum channel. [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 term “presenting” when given its BRI, reasonably include providing, enabling, making functionality available to a network elements.
Nothing in the claim language or specification limits “presenting” to passive display or informational disclosure. Rather the claimed language is reasonably interpreted as enabling the operational use of the protocol by network element.
The cited reference disclose the “facilitate quantum key exchange to communicate between each other” Facilitating quantum key exchange necessarily required enabling participating network elements to operate according to defined QKD protocol procedure. A network element can not facilitate quantum key exchange without access to protocol rules governing preparation, transmission, measurement, reconciliation, and key generation operations.
Therefore, facilitating quantum key exchange inherently requires making QKD protocol available to the network elements, which reasonably corresponds to presenting the QKD protocol.
Furthermore applicant argues:
“As explained further below, Tysowski does not disclose an adapter at all, much less one having the translation behavior recited in claim 1.…However, Tysowski does not disclose or suggest the use of a QKD adapter for a host of each site to retrieve the quantum keys from the KMS”.
Examiner respectfully disagree because, Claim 1 does not require a discrete, standalone component labeled an “adapter,” but instead recites functional capabilities, which may be implemented by integrated or distributed components as recognized under MPEP § 2111.
Under the broadest reasonable interpretation, a quantum protocol adapter encompasses components configures to enable or interface communication according to a quantum communication protocol. The encoding, decoding and processing operations disclosed in the cited reference perform this functionality by adapting classical information for transmission via quantum polarization states and converting measured quantum states back into classical information.
The prior art does not require to use the exact term “quantum key distribution protocol adapter” where it disclose equivalent structure or functionality. Further BB84 inherently requires interfacing between classical communication systems and quantum photon transmission systems, which corresponds to the claimed functionality.
Under the broadest reasonable interpretation, a quantum protocol adapter encompasses components configures to enable or interface communication according to a quantum communication protocol. The encoding, decoding and processing operations disclosed in the cited reference perform this functionality by adapting classical information for transmission via quantum polarization states and converting measured quantum states back into classical information.
The prior art does not require to use the exact term “quantum key distribution protocol adapter” where it disclose equivalent structure or functionality. Further BB84 inherently requires interfacing between classical communication systems and quantum photon transmission systems, which corresponds to the claimed functionality.
To the extent Fu does not explicitly disclose responding to key status requests or key requests, Tysowski teaches key request and key status modules that service session key requests, track allocation and reservation of quantum-generated keys, and provide key status information. It would have been obvious to incorporate Tysowski’s key request and key status management techniques into Fu’s QKD-enabled HSM architecture to improve scalability and efficient utilization of quantum-generated keys.
Accordingly, the combination of Fu and Tysowski teaches or renders obvious all limitations of claim 1, and the rejection under 35 U.S.C. § 103 is maintained.
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, 41-46, 52-57 are rejected under 35 U.S.C. 103 as being unpatentable over Fu (U. S. Pat. No. 10,855,452 B2) (hereinafter “Fu”), and further in view of “The engineering of a scalable multi-site communications system utilizing QKD, Piotr K Tysowski et al 2018 Quantum Sci. Technol. 3 024001” (hereinafter “Tysowski”)
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:
respond to key status requests (Tysowski: [page 9, Table 1], Key status module: This module keeps track of the current status of key bits as keys are assigned to fulfill session key requests. Key bits will need to be reserved (even after allocation to the local host) until the remote host also retrieves the same key, and the key negotiation protocol concludes) and key requests from the network element in the QKD protocol by interacting with the HSM using the key management protocol (Tysowski: [page 9, Table 1]: Key request module: As the primary interface point for hosts, this module services requests for session keys. It also collects and analyzes demand statistics. When the quantum key pool is exhausted, it falls back to key derivation if allowed by the policy, or blocks the host)
and provide the requested key status information or keys to the network element in the QKD protocol (Tysowski: [page 9, Table 1], Key status module: This module keeps track of the current status of key bits as keys are assigned to fulfill session key requests. Key bits will need to be reserved (even after allocation to the local host) until the remote host also retrieves the same key, and the key negotiation protocol concludes).
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 Tysowski’s method of providing key status module and key request, in order to keep track of current status of key bits.
Regarding claim 41, Fu in view Tysowski teaches:
The adapter of claim 1 (see rejection of claim 1 above),
in which the QKD protocol is ETSI QKD (Tysowski: [page 11, Table 2]: Interface to the QKD link layer: This interface provides a communication mechanism between the QNL and the QKD link layer (and ultimately the physical layer), through which key generation request and response messages are exchanged. This interface has to be extensible so that it can work with different QKD devices, as the command interfaces of those devices are typically vendor-dependent. In the context of the relevant QKD ETSI Industry Specification Group (ISG)standard [20], this interface could satisfy the ETSI QKD application interface API, which is used to obtain key material for an associated key handle. The network layer can specify quality of service (QoS) information to the link layer to request a particular bit rate, based on the demand data provided by the KMS)
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 Tysowski’s providing ETSI QKD, in order to obtain key material for an associated key handle.
Regarding claim 42, Fu in view Tysowski teaches:
The adapter of claim 1 (see rejection of claim 1 above),
in which the QKD protocol is a protocol for secure key integration (Fu: [Col 11, lines 19-33], (60) In general, QKD schemes can ensure the distribution security of keys, hence the data transmission security; the trusted-computing-based authentication of the platform and users can ensure the validity of the platform and users; and the trusted-computing-based environment measurement and behavior measurement can ensure the trustworthiness of the environment and behavior of the parties participating the communication. (61) The secure system can also include other components that implement trusted computing, such as trusted routers, trusted switches, trusted proxy servers in the access layer, etc. They can perform various functionalities in the secure system (e.g., a secure cloud computing system). For simplicity of illustration, these components are not shown in FIGS. 3 and 4).
Regarding claim 43, Fu in view Tysowski 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 Tysowski 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 Tysowski teaches:
The adapter of claim 1 (see rejection of claim 1 above),
in which the QKD system is a satellite QKD system (Tysowski: [Page 11, line 1-2], a satellite- or aircraft-based QKD setup could serve as a travelling node to provide temporary connectivity if a fibre link is unavailable or longer range is required. [page 11, 2.6.The QKD link layer], Longer distances could be supported by quantum repeaters and satellites, and physical routing accomplished via optical switching, whether active or passive. Resource sharing is possible with the multiplexing of QKD and classical signals. Ultimately, the target context will help select suitable QKD technologies).
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 Tysowski’s method of providing satellite QKD setup in order to provide longer range connectivity.
Regarding claim 46, Fu in view Tysowski 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 52, this claim contains identical limitations found within that of claim 41. For this reason the same grounds of rejection are applied to claim 52.
Regarding claim 53, this claim contains identical limitations found within that of claim 42. For this reason the same grounds of rejection are applied to claim 53.
Regarding claim 54, Fu in view Tysowski 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”), and further in view of “The engineering of a scalable multi-site communications system utilizing QKD, Piotr K Tysowski et al 2018 Quantum Sci. Technol. 3 024001” (hereinafter “Tysowski”); and further in view of Elliott et al. (U. S. PGPub. No. 2004/0120528 A1) (hereinafter “Elliott”)
Regarding claim 47, Fu in view Tysowski 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 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 Tysowski 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 Tysowski 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 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 Tysowski 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 teahes:
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 or keys to the network element in the QKD protocol and the network element.
However in an analogus art Tysowski teach:
and the adapter being arranged to respond to key status requests (Tysowski: [page 9, Table 1], Key status module: This module keeps track of the current status of key bits as keys are assigned to fulfill session key requests. Key bits will need to be reserved (even after allocation to the local host) until the remote host also retrieves the same key, and the key negotiation protocol concludes) and key requests from the network element in the QKD protocol by interacting with the secure key store using the key management protocol (Tysowski: [page 9, Table 1]: Key request module: As the primary interface point for hosts, this module services requests for session keys. It also collects and analyzes demand statistics. When the quantum key pool is exhausted, it falls back to key derivation if allowed by the policy, or blocks the host),
and being arranged to provide the requested key status information or keys to the network element in the QKD protocol (Tysowski: [page 9, Table 1], Key status module: This module keeps track of the current status of key bits as keys are assigned to fulfill session key requests. Key bits will need to be reserved (even after allocation to the local host) until the remote host also retrieves the same key, and the key negotiation protocol concludes).
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 Tysowski’s method of providing key status module and key request, in order to keep track of current status of key bits.
Fu in view of Tysowski 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 Tysowski 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 Tysowski 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 Tysowski 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 Tysowski teaches:
The adapter of claim 49 (see rejection of claim 49 above),
The Fu in view Tysowski 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 Tysowski 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 analogus art, Tysowski 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 (Tysowski: [page 10, Table 1]: Key request module: As the primary interface point for hosts, this module services requests for session keys. It also collects and analyzes demand statistics. When the quantum key pool is exhausted, it falls back to key derivation if allowed by the policy, or blocks the host),
provide the requested key status information or keys to the network element in the QKD protocol and the network element,(Tysowski: [page 10, Table 1], Key status module: This module keeps track of the current status of key bits as keys are assigned to fulfill session key requests. Key bits will need to be reserved (even after allocation to the local host) until the remote host also retrieves the same key, and the key negotiation protocol concludes);
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 Tysowski’s method of providing key status module and key request, in order to keep track of current status of key bits.
The Fu in view Tysowski 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 Tysowski 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.
U. S. PGPub. No. 2014/0173276 A1 (Vanstone et al.): A method and system for distributed security for a plurality of devices in a communication network, each of the devices being responsible for generating, distributing and controlling its own keys for access to the communication network and using the keys to establish a trusted network, each device's membership to the communication network being checked periodically by other devices by using a challenge response protocol to establish which devices arc allowed access to the communication network and the trusted network.
U. S. PGPub. No. 2013/0083926 A1 (Hughes et al.): Innovations for quantum key management harness quantum communications to form a cryptography system within a public key infrastructure framework. In example implementations, the quantum key management innovations combine quantum key distribution and a quantum identification protocol with a Merkle signature scheme (using Winternitz one-time digital signatures or other one-time digital signatures, and Merkle hash trees) to constitute a cryptography system. More generally, the quantum key management innovations combine quantum key distribution and a quantum identification protocol with a hash-based signature scheme. This provides a secure way to identify, authenticate, verify, and exchange secret cryptographic keys. Features of the quantum key management innovations further include secure enrollment of users with a registration authority, as well as credential checking and revocation with a certificate authority, where the registration authority and/or certificate authority can be part of the same system as a trusted authority for quantum key distribution.
U. S. Pat. No. 8,681,982 B2 (Wiseman et al.): A method of establishing a quantum key for use between a first network node (QNode1) and a second network node (QNode3) in a network for carrying out quantum cryptography includes a key agreement step carried out by a third node (QNode2) and the second node (QNode3) and a subsequent authentication step carried out by the first and second nodes directly. As the key agreement step does not involve QNode1, another key agreement step may be simultaneously performed by another pair of network nodes QNode4, QNode5 to agree a quantum key for use by network nodes QNode1 and QNode5. The invention allows respective quantum keys to be established between a network node and each of a set of other nodes more rapidly than is the case if each quantum key is established serially by key agreement and authentication steps.
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 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