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 .
Priority
Receipt is acknowledged of certified copies of papers required by 37 CFR 1.55.
Information Disclosure Statement
The information disclosure statement (IDS) submitted on 9/3/2025 is in compliance with the provisions of 37 CFR 1.97. Accordingly, the information disclosure statement is being considered by the examiner.
Claim Objections
Claims 1, 3-7, 9-10, and 15 objected to because of the following informalities:
Claim 1: "transmitting to each of the selected QKD nodes (data' Remove the open parentheses or complete the enclosed reference to data (R).
Claim 3: "The method according to claim 1…" Replace 'according to' with 'of'. Similar informalities exist in claims 4-7, 9-10.
Claim 15: "Computer program product comprising… " An article ('a', 'the') is required.
Appropriate correction is required.
Claim Rejections - 35 USC § 112
The following is a quotation of the first paragraph of 35 U.S.C. 112(a):
(a) IN GENERAL.—The specification shall contain a written description of the invention, and of the manner and process of making and using it, in such full, clear, concise, and exact terms as to enable any person skilled in the art to which it pertains, or with which it is most nearly connected, to make and use the same, and shall set forth the best mode contemplated by the inventor or joint inventor of carrying out the invention.
The following is a quotation of the first paragraph of pre-AIA 35 U.S.C. 112:
The specification shall contain a written description of the invention, and of the manner and process of making and using it, in such full, clear, concise, and exact terms as to enable any person skilled in the art to which it pertains, or with which it is most nearly connected, to make and use the same, and shall set forth the best mode contemplated by the inventor of carrying out his invention.
Claims 2 and 4 are rejected under 35 U.S.C. 112(a) or 35 U.S.C. 112 (pre-AIA ), first paragraph, as failing to comply with the enablement requirement. The claim(s) contains subject matter which was not described in the specification in such a way as to enable one skilled in the art to which it pertains, or with which it is most nearly connected, to make and/or use the invention.
Claim 2 requires the existence of, for each of the QKD nodes, a preceding QKD node and a succeeding QKD node along the key forwarding path (Claim 1, "… generating, by each selected QKD node, a digital signature…", Claim 2, "The method of claim 1, wherein each digital signature comprises… and at least information about the preceding and the succeeding QKD node along the key forwarding path"). The specification describes that the path is a sequence of nodes, and is a selection of a contiguous path between a starting QKD node and a terminal QKD node (PGPub of Current Application, ¶23, "A path or a routing of a cryptographic key (a key forwarding path) may be understood to be a sequence of QKD nodes… The routing or key forwarding path includes a selection of a contiguous path between the starting QKD node and the terminal QKD node."). It is to be understood that, by reasonable interpretation of the claim terminology, a node that precedes another node along the path is one that must before it in the path; i.e., every node with a preceding node includes every node except the node at the start of the path. For the node at the start of the path (the 'starting' QKD node), there are no preceding QKD nodes for which the digital signature generated by the starting QKD node must include information of. Thus, it is impossible for each digital signature to include information about a preceding node along the path, since there is one digital signature from a QKD node that does not have any preceding nodes to include the information of. An impossibility regarding a QKD node that succeeds the terminal QKD node (i.e., one that is not succeeded by any nodes) can likewise be made. The specification does not offer any course to explain how one would resolve this impossibility, such that one skilled in the art is not enabled to make and/or use the invention.
For the purpose of examination, the claim will effectively be treated as '…and at least information about any at least immediately preceding and any at least immediately succeeding nodes along the path.' Reasoning comes from the specification (PGPub of Current Application, ¶33, "In these embodiments, the “path” entry in the message sent by the QKD node j may contain information about the preceding QKD nodes (at least information about the QKD node j−1) and information about the QKD node j+1, i.e., the one selected locally by the QKD node j.", such that it may contain the information, but is not strictly required)
Claim 4 requires the existence of, for each of the QKD nodes, a succeeding QKD node along the key forwarding path (Claim 4, "… each of the selected QKD nodes is configured to locally select the succeeding QKD node along the key forwarding path"). This is impossible for a substantially similar rationale to the similar requirement of claim 2. The specification does not offer any course to explain how one would resolve this impossibility, such that one skilled in the art is not enabled to make and/or use the invention.
For the purpose of examination, the claim will effectively be treated as '….each of the selected QKD nodes is configured to locally select the succeeding QKD node along the key forwarding path if applicable'.
The following is a quotation of 35 U.S.C. 112(b):
(b) CONCLUSION.—The specification shall conclude with one or more claims particularly pointing out and distinctly claiming the subject matter which the inventor or a joint inventor regards as the invention.
The following is a quotation of 35 U.S.C. 112 (pre-AIA ), second paragraph:
The specification shall conclude with one or more claims particularly pointing out and distinctly claiming the subject matter which the applicant regards as his invention.
Claims 2-4, 9-11 rejected under 35 U.S.C. 112(b) or 35 U.S.C. 112 (pre-AIA ), second paragraph, as being indefinite for failing to particularly point out and distinctly claim the subject matter which the inventor or a joint inventor (or for applications subject to pre-AIA 35 U.S.C. 112, the applicant), regards as the invention.
Claim 2 recites the limitation "the preceding and the succeeding QKD node along the key forwarding path" in paragraph 2. There is insufficient antecedent basis for this limitation in the claim.
Claim 3 recites the limitation "the end applications" in paragraph 2. There is insufficient antecedent basis for this limitation in the claim.
Claim 4 recites the limitation "the succeeding QKD node" in paragraph 2. There is insufficient antecedent basis for this limitation in the claim.
Claim 9 recites the limitation "the relative order of the selected QKD nodes" in paragraph 2. There is insufficient antecedent basis for this limitation in the claim.
Claim 10 recites the limitation "the distribution of D QKD keys" in paragraph 3. There is insufficient antecedent basis for this limitation in the claim. Claim 11 is rejected due to its dependence on claim 10.
Claim Rejections - 35 USC § 101
35 U.S.C. 101 reads as follows:
Whoever invents or discovers any new and useful process, machine, manufacture, or composition of matter, or any new and useful improvement thereof, may obtain a patent therefor, subject to the conditions and requirements of this title.
Claims 12-14 rejected under 35 U.S.C. 101 because the claimed invention is directed to non-statutory subject matter. The claim(s) does/do not fall within at least one of the four categories of patent eligible subject matter because the claim(s) recites a system without any definite structural recitations (i.e. 'software per se') (see MPEP § 2106.03).
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-3, 5, 7-9, and 12-15 is/are rejected under 35 U.S.C. 103 as being unpatentable over Y.3083 (ITU-T: TELECOMMUNICATION STANDARDIZATION SECTOR OF ITU, Y.3803, 'Quantum key distribution networks – Key management', Dec. 2020) in view of Looney (Looney et al., US 20190036943 A1)
Regarding claim 1, Y.3803 teaches a method for verifying a key forwarding path of at least one cryptographic key in a quantum key distribution (QKD) network, the method comprising at least steps of: selecting a number of QKD nodes of the QKD network, which define a key forwarding path of the at least one cryptographic key; transmitting to each of the selected QKD nodes data indicating at least partial information about the key forwarding path of the at least one cryptographic key (Figure 1, p.8, "Based on the key file, the KMAs, the KSAs, and cryptographic applications communicate to each other the key data, the metadata and key management information. In addition, the QKDN controller and the QKDN manager communicate control and management information based on the metadata to the KMAs and the KSAs.", p.10, "The key relay route is controlled by the QKDN controller as illustrated in Figure 1. The communication sessions between KMAs to establish the end-to-end key can be controlled by the QKDN controller.", Table 1, Section (3), both the Source KMA ID and Destination KMA ID are part of the metadata; the QKDN controller determines the key relay route between QKD nodes for a cryptographic key (the key relay route is interpreted as the key forwarding path, such that the QKD nodes on the path are selected by the controller), and the QKDN controller communicates the control and management information based on the metadata, such as the source KMA ID and destination KMA ID (which, as the source of the key information and destination of the key information, comprise at least partial information about the key forwarding path) to the KMAs and KSAs of the QKD nodes. See also p.10, "When further relaying the key to the next destination node, it is encrypted just as before, including the key relay information. In this case, the key relay information is updated with the current node as the source KMA, the next destination node as the destination KMA, and new relay time stamp at the current node. This updated key relay information is added to the source KMA-key metadata, and stored in the second destination KMA."); generating, by each selected QKD node, a hash, wherein the hash contains at least the at least one cryptographic key; transmitting, by each selected QKD node, the hash generated at that selected QKD node; and verifying the at least one cryptographic key through a verification of the transmitted hashes (pp. 10-11, "In each key relay, it should be confirmed whether the content (identity) of the key shared by the source and destination KMAs has been altered in transit. Therefore, as recommended by Req_KM 8 of [ITU-T Y.3801], appropriate methods of entity and message authentication are employed to ensure authenticity and integrity for the KMAs and KMA-key, respectively. In particular, for integrity protection of the KMA-key, a hash value or a message authentication code of the KMA-key data can be used. Integrity of key management information exchanged between KMAs is protected by performing message authentication."; each key relay (pairs of QKD nodes that relay the key to each other, such that each node of the full path selected by the controller is part of at least one key relay) hashes and exchanges (transmits) the key data to authenticate it (verifying the key data). See also p.9, "The pair of KMAs authenticate each other via the KMA link. Then one of the KMAs (say KMA1) sends the matching KMA (say KMA2) a key-authentication request including a hash value or a message authentication code of the buffered keys as well as the QKD-key identifier (ID). Then KMA2 synchronizes (in bit position) and authenticates the buffered keys by comparing the hash values or the message authentication code in its hand with that from KMA1. ").
Y.3803 does not teach that the hash is a digital signature that contains at least the data indicating at least partial information about the key forwarding path of the at least one cryptographic key. In an analogous art, Looney teaches that each node group of a network digitally signs data (generates a digital signature) indicating at least partial information about the path of a message of a network and transmits the digital signature, as well as verifying the path of the message through a verification of the transmitted signature (¶15, "… each node group that receives and forwards a route update message may digitally sign the route update message using a corresponding private key… When a downstream node group receives the message, the recipient node group may validate each signature of the signature chain using a public key associated with the corresponding private key to determine whether the path of the route update message is authentic. "). Framed by the invention of Y.3803, wherein the path of the message is equivalent to the data indicating at least partial information of the key forwarding path of the at least one cryptographic key (as both consist of routing information for messages through a network), wherein there is no teaching of any node groups bigger than a singular node (of which Looney allows as a node group (Looney, ¶17)), and wherein the nodes as QKD nodes and the network is a QKD network, Looney teaches the rest of the claimed invention. Y.3803 and Looney are analogous arts, as both deal with the security of digitally transmitted information and coordination of a route of a message through a network. One of ordinary skill in the art prior to the effective filing date of the claimed invention could modify Y.3803 using Looney to have each selected QKD node digitally sign the information of the key forwarding path, transmit it to other nodes of the path, and verify the key forwarding path with the signature by integrating the instructions of Looney into the setting and method of Y.3803 with predictable results. It would be obvious to do so because it would improve security of any routing updates within the network (Looney, ¶15)
Regarding claim 2, Y.3803 in view of Looney teaches the method of claim 1. Framed by Y.3803 (such that the node groups are QKD nodes and the routing information is the key forwarding path of the at least one cryptographic key), Looney further teaches that each digital signature comprises information about the at least one cryptographic key (¶15, "… each node group that receives and forwards a route update message may digitally sign the route update message using a corresponding private key… When a downstream node group receives the message, the recipient node group may validate each signature of the signature chain using a public key associated with the corresponding private key to determine whether the path of the route update message is authentic. ", the route update message (key forwarding path of the at least one cryptographic key, interpreted as information about the at least one cryptographic key)), a public identifier of the QKD node that generated the digital signature (¶12, ¶13, the route update message includes a prefix that acts as an address for any node that sends the digital signature), and at least information about the preceding and the succeeding QKD node along the key forwarding path (Fig. 1A, the signed route update message sent from Node Group 2 to Node Group 3 contains both information about the node that preceded Node Group 2 (i.e., Node Group 1) and the node that succeeded Node Group 2 (i.e. Node Group 3). See also ¶66, "For example, when a sending node group 220 transmits the route update message, the sending node group 220 may sign the route update message to indicate that the route update message has traveled directly from the sending node group 220 to a recipient node group 220.") (see claim 1 for motivation to combine)
Regarding claim 3, Y.3803 in view of Looney teaches the method according to claim 1, wherein the key forwarding path of the at least one cryptographic key is specified by one of the end applications, or by a QKD network controller (Y.3803, p.10, "The key relay route is controlled by the QKDN controller as illustrated in Figure 1. The communication sessions between KMAs to establish the end-to-end key can be controlled by the QKDN controller."; the QKDN controller determines the key relay route between QKD nodes for a cryptographic key (the key relay route is interpreted as the key forwarding path, such that the QKD nodes on the path are selected by the controller and the key forwarding path is specified by the controller)).
Regarding claim 5, Y.3803 in view of Looney teaches the method of claim 1. Framed by Y.3803 (such that the node groups are QKD nodes and the routing information is the key forwarding path of the at least one cryptographic key, and such that cryptographic hashes are transmitted from QKD nodes to other selected QKD nodes according to the key forwarding path (Y.3803, pp. 10-11, "In each key relay, it should be confirmed whether the content (identity) of the key shared by the source and destination KMAs has been altered in transit. Therefore, as recommended by Req_KM 8 of [ITU-T Y.3801], appropriate methods of entity and message authentication are employed to ensure authenticity and integrity for the KMAs and KMA-key, respectively. In particular, for integrity protection of the KMA-key, a hash value or a message authentication code of the KMA-key data can be used. Integrity of key management information exchanged between KMAs is protected by performing message authentication."; each key relay (pairs of QKD nodes that relay the key to each other, such that each node of the full path selected by the controller is part of at least one key relay) hashes and exchanges (transmits) the key data)), Looney further teaches that each of the selected QKD nodes transmits at least the digital signature it generated to another selected QKD node according to the key forwarding path (Looney, Fig. 1A, the digitally signed route update message is sent from each node group to another node group) (see claim 1 for motivation to combine).
Regarding claim 7, Y.3803 in view of Looney teaches the method according to claim 1, further comprising: obtaining at least one QKD network condition by a QKD network controller; and dynamically changing the key forwarding path by selecting, at least partially, different QKD nodes based on the at least one obtained QKD network condition (Y.3803, p. 4, "When QKD modules detect an alarm, such as an increase of their quantum bit error rates (QBERs), they alert the QKDN controller directly or indirectly via the KMs. The QKDN controller then reroutes the path for key relay to circumvent the faulty QKD link for successful key supply.".; the QKDN controller obtains an alert of modules with increased quantum bit error rates (QKD network condition, as modules with more QBERs are likelier to transmit errors to other modules) and reroutes the path to circumvent the previous link (which is interpreted as dynamically changing the key forwarding path by selecting, at least partially, different QKD nodes based on the at least one obtained QKD network condition because the key forwarding path would involve a set of nodes that doesn't include the previous link, i.e. at least partially different QKD nodes). See also p. 12, ‘8.2.5 Rerouting of key relay between KMAs’; the KMAs perform key relay automatically based on recent statistical records of key relay traffic).
Regarding claim 8, Y.3808 in view of Looney teaches the method of claim 7, further comprising: transmitting, by the QKD network controller, information about the dynamically changed key forwarding path to end applications (Y.3808, Fig. 1, p. 12, ‘8.2.5 Rerouting of key relay between KMAs’; the KMAs (interpreted as end applications, as they comprise the 'ends' of the QKD network that connect to the service layer) continue key relay according to the provision of rerouting by the QKDN controller (thus necessarily receiving information about the rerouted path from it)).
Regarding claim 9, Y.3803 in view of Looney teaches the method according to claim 1. Framed by Y.3803 (such that the node groups are QKD nodes and the routing information is the key forwarding path of the at least one cryptographic key), Looney further teaches that the digital signature generated by each selected QKD node contains at least partial information about the relative order of the selected QKD nodes along the key forwarding path of the at least one cryptographic key (Fig. 1A, the signed route update message sent from Node Group 2 to Node Group 3 contains both information about the node that preceded Node Group 2 (i.e., Node Group 1) and the node that succeeded Node Group 2 (i.e. Node Group 3), such that it contains information about the relative order of nodes the message is going through. See also ¶66, "For example, when a sending node group 220 transmits the route update message, the sending node group 220 may sign the route update message to indicate that the route update message has traveled directly from the sending node group 220 to a recipient node group 220.") (see claim 1 for motivation to combine).
Regarding claim 12, Y.3803 teaches a system for the verification of a key forwarding path of at least one cryptographic key, the system comprising: a number of QKD nodes forming a quantum key distribution, QKD, network (Fig. 1, QKD nodes form a QKD network), which are configured to receive and transmit cryptographic keys and are adapted to couple to end applications (Fig. 1, p. 4, "Each pair of QKD modules connected by a QKD link generates keys in its own way. Generated keys are transferred to KMs. The KMs manage the keys and supply them to cryptographic applications in the service layer of the user network. The keys can be relayed via KMs and shared between any designated QKD nodes.", QKD nodes receive and transmit cryptographic keys between each other and are connected (coupled) to Key Managers (KMs that contain Key Managers and Key Suppliers) and cryptographic applications (collectively interpreted as end applications)), wherein a selection of the QKD nodes define a key forwarding path; wherein each selected QKD node is configured to receive data (R) indicating at least partial information about the key forwarding path of the at least one cryptographic key (Figure 1, p.8, "Based on the key file, the KMAs, the KSAs, and cryptographic applications communicate to each other the key data, the metadata and key management information. In addition, the QKDN controller and the QKDN manager communicate control and management information based on the metadata to the KMAs and the KSAs.", p.10, "The key relay route is controlled by the QKDN controller as illustrated in Figure 1. The communication sessions between KMAs to establish the end-to-end key can be controlled by the QKDN controller.", Table 1, Section (3), both the Source KMA ID and Destination KMA ID are part of the metadata; the QKDN controller determines the key relay route between QKD nodes for a cryptographic key (the key relay route is interpreted as the key forwarding path, such that the QKD nodes on the path are selected by the controller), and the QKDN controller communicates the control and management information based on the metadata, such as the source KMA ID and destination KMA ID (which, as the source of the key information and destination of the key information, comprise at least partial information about the key forwarding path) to the KMAs and KSAs of the QKD nodes. See also p.10, "When further relaying the key to the next destination node, it is encrypted just as before, including the key relay information. In this case, the key relay information is updated with the current node as the source KMA, the next destination node as the destination KMA, and new relay time stamp at the current node. This updated key relay information is added to the source KMA-key metadata, and stored in the second destination KMA."), and to transmit the at least one cryptographic key using a hash (pp. 10-11, "In each key relay, it should be confirmed whether the content (identity) of the key shared by the source and destination KMAs has been altered in transit. Therefore, as recommended by Req_KM 8 of [ITU-T Y.3801], appropriate methods of entity and message authentication are employed to ensure authenticity and integrity for the KMAs and KMA-key, respectively. In particular, for integrity protection of the KMA-key, a hash value or a message authentication code of the KMA-key data can be used. Integrity of key management information exchanged between KMAs is protected by performing message authentication."; each key relay (pairs of QKD nodes that relay the key to each other, such that each node of the full path selected by the controller is part of at least one key relay) hashes and exchanges (transmits) the key data. See also p.9, "The pair of KMAs authenticate each other via the KMA link. Then one of the KMAs (say KMA1) sends the matching KMA (say KMA2) a key-authentication request including a hash value or a message authentication code of the buffered keys as well as the QKD-key identifier (ID). Then KMA2 synchronizes (in bit position) and authenticates the buffered keys by comparing the hash values or the message authentication code in its hand with that from KMA1. "),
Y.3803 does not teach that the hash is a digital signature, or that the digital signature contains at least the data indicating at least partial information about the key forwarding path of the at least one cryptographic key. In an analogous art, Looney teaches that each node group of a network digitally signs data (generates a digital signature) indicating at least partial information about the path of a message of a network and transmits the digital signature (¶15, "… each node group that receives and forwards a route update message may digitally sign the route update message using a corresponding private key… When a downstream node group receives the message, the recipient node group may validate each signature of the signature chain using a public key associated with the corresponding private key to determine whether the path of the route update message is authentic. "). Framed by the invention of Y.3803, wherein the path of the message is equivalent to the data indicating at least partial information of the key forwarding path of the at least one cryptographic key (as both consist of routing information for messages through a network), wherein there is no teaching of any node groups bigger than a singular node (of which Looney allows as a node group (Looney, ¶17)), and wherein the nodes as QKD nodes and the network is a QKD network, Looney teaches the rest of the claimed invention. Y.3803 and Looney are analogous arts, as both deal with the security of digitally transmitted information and coordination of a route of a message through a network. One of ordinary skill in the art prior to the effective filing date of the claimed invention could modify Y.3803 using Looney to have each selected QKD node digitally sign the information of the key forwarding path and transmit it to other nodes of the path by integrating the instructions of Looney into the setting and method of Y.3803 with predictable results. It would be obvious to do so because it would improve security of any routing updates within the network (Looney, ¶15).
Regarding claim 13, Y.3803 in view of Looney teaches the system of claim 12, further comprising a QKD network controller (Y.3803,Fig. 1), which is adapted to exchange data with at least part of the QKD nodes and the end applications (Y.3803, Fig. 1, QKDN controller exchanges information with the KMs coupled to the cryptographic applications and QKD nodes (at least part of the QKD nodes and the end applications)), and which is configured to generate a key forwarding path for at least one cryptographic key, wherein generating a key forwarding path comprises selecting a number of the QKD nodes (Y.3803, p.10, "The key relay route is controlled by the QKDN controller as illustrated in Figure 1. The communication sessions between KMAs to establish the end-to-end key can be controlled by the QKDN controller."; the QKDN controller determines the key relay route between QKD nodes for a cryptographic key (the key relay route is interpreted as the key forwarding path, such that the QKD nodes on the path are selected by the controller and the key forwarding path is specified by the controller)).
Regarding claim 14, Y.3803 in view of Looney teaches the system of claim 13, wherein the QKD network controller is further configured to obtain at least one network condition and to dynamically change the key forwarding path of the cryptographic key by selecting, at least partially, different QKD nodes based on the at least one obtained QKD network condition (Y.3803, p. 4, "When QKD modules detect an alarm, such as an increase of their quantum bit error rates (QBERs), they alert the QKDN controller directly or indirectly via the KMs. The QKDN controller then reroutes the path for key relay to circumvent the faulty QKD link for successful key supply.".; the QKDN controller obtains an alert of modules with increased quantum bit error rates (QKD network condition, as modules with more QBERs are likelier to transmit errors to other modules) and reroutes the path to circumvent the previous link (which is interpreted as dynamically changing the key forwarding path by selecting, at least partially, different QKD nodes based on the at least one obtained QKD network condition because the key forwarding path would involve a set of nodes that doesn't include the previous link, i.e. at least partially different QKD nodes). See also p. 12, ‘8.2.5 Rerouting of key relay between KMAs’; the KMAs perform key relay automatically based on recent statistical records of key relay traffic).
Regarding claim 15, Y.3803 in view of Looney teaches the method according to claim 1. Looney further teaches a computer program product comprising executable program code configured to, when executed, perform the method of the invention (¶53-¶54). One of ordinary skill in the art prior to the effective filing date of the claimed invention could further modify Y.3803 in view of Looney using Looney to use a computer program product comprising executable program code configured to, when executed, perform the method of the invention with predictable results. It would be obvious to do so because it would enable a person of ordinary skill in the art to implement the method of the invention.
Claim(s) 4 is/are rejected under 35 U.S.C. 103 as being unpatentable over Y.3083 in view of Looney as applied to claim 1 above, and further in view of Y.3082 (ITU-T: TELECOMMUNICATION STANDARDIZATION SECTOR OF ITU, Y.3802, 'Quantum key distribution networks – Functional architecture', Dec. 2020)
Regarding claim 4, Y.3803 in view of Looney teaches the method according to claim 1. Y.3803 in view of Looney does not explicitly teach but, in an analogous art, Y.3802 teaches that the key forwarding path of the at least one cryptographic key is specified dynamically, wherein each of the selected QKD nodes is configured to locally select the succeeding QKD node along the key forwarding path (Fig. 2, p.11, ‘9.1 Configuration 1: Distributed QKDN’; each QKD node has a dedicated QKDN controller to perform the functions of a QKDN without needing a centralized network controller. p.7, ‘7.3 Functional elements in a QKDN control layer’; the QKDN provisions an appropriate key relay route between two endpoints of key managers. p.17, ’10.4 Key relay procedure’, Step 2; the QKDN decides the key relay route to perform the next (succeeding) key relay).
Y.3802 and Y.3803 in view of Looney are analogous arts, as both deal with quantum key distribution managed by QKD controllers. One of ordinary skill in the art prior to the effective filing date of the claimed invention could modify Y.3803 in view of Looney using Y.3802 to select the key forwarding path locally and dynamically with predictable results. It would be obvious to do so because it would not require a centralized network controller (Y.3802, p. 11, "Each type 1 QKD node can perform QKDN functions in a distributed manner, without relying on a centralized network controller. ")
Claim(s) 6 is/are rejected under 35 U.S.C. 103 as being unpatentable over Y.3083 in view of Looney as applied to claim 1 above, and further in view of Sastry (SASTRY et al., US 20220239498 A1)
Regarding claim 6, Y.3803 in view of Looney teaches the method according to claim 1. Y.3803 in view of Looney does not teach but, in an analogous art, Sastry teaches that each of the selected nodes transmits the generated digital signature to a network controller (¶61, ¶76; each of the group member devices (which are interpreted as the nodes) transmits their signed messages to the group manager/verifying device (interpreted as the network controller)). Framed by Y.3803 in view of Looney, such that the network controller is a QKD network controller and the nodes are QKD nodes, Sastry teaches the rest of the claimed invention.
Sastry and Y.3803 in view of Looney are analogous arts, as both deal with managing networks related to quantum computing. One of ordinary skill in the art prior to the effective filing date of the claimed invention could modify Y.3803 in view of Looney using Sastry to have each of the selected QKD nodes transmit the generated digital signature to a QKD network controller by implementing the instructions taught by Sastry with predictable results. It would be obvious to do so because it would enable the tracing of signature to perform actions such as key revocation for a particular node (Sastry, ¶61)
Allowable Subject Matter
Claim 10 and 11 objected to as being dependent upon a rejected base claim, but would be allowable if rewritten in independent form including all of the limitations of the base claim and any intervening claims.
The following is a statement of reasons for the indication of allowable subject matter:
Regarding claim 10, Y.3808 in view of Looney teaches the method according to claim 1. Y.3808 in view of Looney does not teach generating, for the distribution of D QKD keys, a D-dimensional vector of messages at each selected QKD node, wherein each entry of the D-dimensional vector is associated with one of the D QKD keys.
The closest prior art of record is Brassard (Giles Brassard and Louis Salvail, 'Secret-Key Reconciliation by Public Discussion', 1994). Brassard teaches generating, for a distribution of D QKD keys, D messages at each selected QKD node, wherein each of the D messages is associated with one of the D QKD keys (p.2, ‘Introduction’; the protocols involved are for quantum key distribution (keys are QKD keys, nodes are QKD nodes). pp. 10-11, ‘7.1 Cascade Description’; the protocol known as Cascade is disclosed, wherein a key is separated into a number of blocks (D blocks, distribution of D keys), and information about each block (namely, the parity of the block, i.e., D messages associated with respective D QKD keys) is sent from one from one person (node) to another). However, Brassard does not teach that the D messages comprise a D-dimensional vector of messages, where each entry of the D-dimensional vector is one of the D messages. Thus, claim 10 would not be obvious over the prior art of record
Regarding claim 11, it, likewise, would not be found allowable over the prior art of record by virtue of its dependence on claim 10.
Claims 10 and 11 would be allowable if rewritten to overcome the rejection(s) under 35 U.S.C. 112(b) or 35 U.S.C. 112 (pre-AIA ), 2nd paragraph, set forth in this Office action and to include all of the limitations of the base claim and any intervening claims.
Conclusion
The prior art made of record and not relied upon is considered pertinent to applicant's disclosure.
Pearson (Pearson et al., US 20040184603 A1) teaches a QKD network that transports quantum cryptographic keys between QKD endpoints of private enclaves by hop-by-hop secure key transport to enable encrypted traffic between enclaves (Fig. 1) where the message data includes the node ID of the previous hop (Fig. 9B), and where the source node (end application) determines the path from the source to the destination (¶82, Fig. 12).
Roscoe (ROSCOE et al., US 20250038963 A1) teaches generating a transaction that contains the source and destination as metadata, along with the digital signature of all intermediary nodes the transaction passes through (Fig. 6).
Salvail (Louis Salvail et al., 'Security of Trusted Repeater Quantum Key Distribution Networks', 2009) teaches using message authentication codes to validate and authenticate keys sent through a repeater QKD network.
Yuan (YUAN et al., 'Quantum cryptography network dynamic routing method', CN 103001875 A) teaches a method for dynamic routing in quantum cryptography networks, wherein a routing server obtains information saying that relay node of a quantum link is abnormal and determines that the node is unusable (¶62, p. 13), along with the routing server notifying an end application of changed network topology (¶109, p. 19)
Takahashi (TAKAHASHI et al., US 20230308264 A1) teaches a QKD network, where nodes communicate through QKD links to send keys (local and global) to enable applications to communicate through an encrypted data communication network (Fig. 2), and where a vector of multiple keys is transported through the network (Fig. 6, ¶64-¶66).
Su (Su et al., US 20190260581 A1) teaches a centralized controller performs path selection for distributing quantum keys (¶149, ¶152, ¶155)
Rahman (Rahman et al., US 20210176055 A1) teaches a centralized software defined network intelligence is used to select an efficient quantum entanglement end-to-end distribution path or set of paths (¶19)
DiAdamo (DiAdamo et al., US 20260046119 A1) teaches providing a secure chain of key management servers for distribution of keys via point-to-point quantum key distribution links, validating all nodes in the chain (Abstract, Fig. 1, Fig. 5, ¶35).
Choi (CHOI et al., US 20250119278 A1) teaches a QKDN controller managing a QKD network, as well as rerouting a key forwarding path due to collected performance data of the network (¶104, ¶176).
Kim (KIM et al., US 20250184124 A1) teaches a QKDN controller that performs provisioning and rerouting of key relay paths (¶114) due to faults or performance degradation (¶180, ¶181)
Any inquiry concerning this communication or earlier communications from the examiner should be directed to AMIR MAHDI HAJIABBASI whose telephone number is (703)756-5511. The examiner can normally be reached M-F 7:30-5 EST.
Examiner interviews are available via telephone, in-person, and video conferencing using a USPTO supplied web-based collaboration tool. To schedule an interview, applicant is encouraged to use the USPTO Automated Interview Request (AIR) at http://www.uspto.gov/interviewpractice.
If attempts to reach the examiner by telephone are unsuccessful, the examiner’s supervisor, Catherine Thiaw can be reached at (571) 270-1138. 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.
/A.M.H./
Amir Mahdi HajiabbasiExaminer, Art Unit 2407
/Catherine Thiaw/Supervisory Patent Examiner, Art Unit 2407 9/28/2026
