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 .
DETAILED ACTION
This Office Action is in response to the application 18/973,052 filed on 12/08/2024.
Claims 1, 10, 21, and 25 are independent claims. Claims 1-20 have been examined and are pending. This Action is made Non-FINAL.
Drawings
The drawings were received on 12/08/2024. These drawings are reviewed and accepted by the Examiner.
Information Disclosure Statement
The information disclosure statement (IDS) submitted on 06/03/2025 is being considered by the examiner.
Claim Objections
Claims 5 and 15 are objected to because of the following informalities:
Regarding claim 5, claim 5 recites "receiving path information from the NTB, the path information comprising path information indicating modifications to an integrity-protected portion of a packet." The second occurrence of "path information" within the recitation "comprising path information indicating modifications" appears to be a typographical error, as the limitation would otherwise be recursive (defining "path information" in terms of itself). The Examiner suggests that the second occurrence of "path information" be amended to read "information," so that the limitation reads: "receiving path information from the NTB, the path information comprising [[path]] information indicating modifications to an integrity-protected portion of a packet." Appropriate correction is required.
Regarding claim 15, claim 15 contains the same typographical error and is objected to for the same reason. The Examiner suggests the same correction be made to claim 15. Appropriate correction is required.
Claim Rejections - 35 USC § 112
The following is a quotation of 35 U.S.C. 112(b):
(b) CONCLUSION.—The specification shall conclude with one or more claims particularly pointing out and distinctly claiming the subject matter which the inventor or a joint inventor regards as the invention.
The following is a quotation of 35 U.S.C. 112 (pre-AIA ), second paragraph:
The specification shall conclude with one or more claims particularly pointing out and distinctly claiming the subject matter which the applicant regards as his invention.
Claims 1, 14, and 27 are rejected under 35 U.S.C. 112(b) or 35 U.S.C. 112 (pre-AIA ), second paragraph, as being indefinite for failing to particularly point out and distinctly claim the subject matter which the inventor or a joint inventor (or for applications subject to pre-AIA 35 U.S.C. 112, the applicant), regards as the invention.
Regarding claim 1, claim 1 recites the limitation “the first Message Authentication Code” in line 5. There is insufficient antecedent basis for this limitation in the claim.
Regarding claim 14, claim 14 recites "wherein a first device to: determine the expected modifications..." The term "a first device" is introduced without a clear relationship to "the first host" recited in parent claim 12. It is unclear whether "the first device" refers to the first host of claim 12 or to a different entity. The use of two different terms ("device" and "host") without an explicit relationship between them renders the claim scope ambiguous.
Regarding claim 27, claim 27 recites the same inconsistency and is rejected for the same reason.
The Examiner suggests amending "a first device" to "the first host" in claims 14 and 27 for consistency with the parent claim.
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.
Claims 1-2 and 10-11 are rejected under 35 U.S.C. 103 as being unpatentable over Harriman et al. (“Harriman,” US 2020/0151362) in view of Wan et al. (“Wan,” US 2022/0368781)
Regarding claim 1, Harriman teaches a method comprising:
protecting integrity of a first segment of a communication path with a first integrity code (Harriman: fig. 5 A, hop-by-hop, in PCIe protocol; par. 84, In FIG. 5A, a hop-by-hop protocol includes a different key pair for each link to enable encryption at every transmitting port and decryption at every receiving port. Keys 501A and 501B are used as the key pair of link 512, par. 0090, At IDE TKP 662 [], the prefix is inserted into the packet, an integrity code value (ICV) such as a MAC is generated over the packet (e.g., prefix, header, data), and the ICV is added to the packet; par. 0083, For a device connected to the server platform via a serial interconnect interface, such as peripheral component interface express (PCie ), enabling direct assignment of the device to TD memory requires the data flowing between the TD and the device over the PCie link to be secured to enforce confidentiality, integrity, and replay protection of the data); and
protecting integrity of a second segment of the communication path with a second integrity code, wherein the second integrity code is different than the first Message Authentication Code (“MAC”) (Harriman: fig. 5 A, hop-by-hop, in PCIe protocol; par. 84, In FIG. 5A, a hop-by-hop protocol includes a different key pair for each link to enable encryption at every transmitting port and decryption at every receiving port [], keys 503A and 503B are used as the key pair of link 522; par. 0090, At IDE TKP 662 [], the prefix is inserted into the packet, an integrity code value (ICV) such as a MAC is generated over the packet (e.g., prefix, header, data), and the ICV is added to the packet; par. 0089, Advanced Encryption Standard-Galois/Counter Mode (AES-GCM) construction with 96-bit counters and a 96-bit Message Authentication Code (MAC)can be used for cryptographically securing the traffic. par. 0083, For a device connected to the server platform via a serial interconnect interface, such as peripheral component interface express (PCie ), enabling direct assignment of the device to TD memory requires the data flowing between the TD and the device over the PCie link to be secured to enforce confidentiality, integrity, and replay protection of the data).
Harriman teaches protecting integrity of a first segment of a communication path with a first integrity code but does not explicitly teach different PCIe domains connected by a non-transparent bridge (NTB).
However, in analogous art, Wan teaches different PCIe domains connected by a non-transparent bridge (NTB) (Wan: par. 0082, FIG. 2 shows a communications system including two PCie systems. The two PCie systems may communicate with each other through a non-transparent bridge (NTB). The NTB can be deployed on a switch. Because each device in a PCie system is independently managed by its own root, addresses and IDs of devices in different PCie systems may conflict with each other. To ensure that the two systems are connected and communicate with each other normally, bridging translation needs to be performed between the two systems to translate addresses or IDs. The NTB may be responsible for address or ID translation, so that the two PCie systems communicate with each other.).
Therefore, it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to combine the teaching of Wan with the method of Harriman to include PCIe domains connected by a non-transparent bridge (NTB). One would have been motivated to apply Harriman's hop-by-hop integrity architecture to Wan's two-PCIe-domain NTB topology because Wan teaches that "addresses and IDs of devices in different PCIe systems may conflict with each other" such that "bridging translation needs to be performed between the two systems to translate addresses or IDs" (Wan: [082]). A POSITA would recognize that an end-to-end integrity code computed over those fields would fail verification at the destination after the NTB has performed its translation, and that Harriman's hop-by-hop architecture with "a different key pair for each link" (Harriman: [0084]) provides the established alternative protection for communication paths traversing intermediate devices that modify packet fields.
Regarding claim 2, the combination of Harriman and Wan teaches the method of claim 1. The combination of Harriman and Wan further teaches comprising:
defining the first segment of the communication path to be between an originating host and a PCIe switch in non-transparent bridge mode (Harriman: par. [0084] — "Keys 501A and 501B are used as the key pair of link 512"; Wan: par. 0082, Wan teaches that "the NTB can be deployed on a switch" between two PCIe systems to enable cross-domain communication); and
defining the second segment of the communication path to be between the PCIe switch in non-transparent bridge mode and a destination host (Harriman: par. [0084] — "keys 503A and 503B are used as the key pair of link 522"; Wan: par. 0082, Wan teaches that "the NTB can be deployed on a switch" between two PCIe systems to enable cross-domain communication).
Regarding claim 10, Harriman teaches a system, comprising:
a PCIe system including an SoC 510 as an originating device connected to a PCIe switch 520 via link 512 (Harriman: par. [0084]. Under broadest reasonable interpretation, SoC 510 of Harriman reads on a host in a PCIe topology. However, Harriman does not expressly teach that SoC 510 belongs to a separate PCIe domain distinct from a second PCIe domain — Harriman's Fig. 5A shows a single PCIe domain with one root);
device 530 connected to PCIe switch 520 via link 522 as a target device in the same PCIe system as SoC 510 (Harriman: par. [0084]); under BRI, Device 530 reads on an endpoint in a PCIe topology); and
Harriman further teaches PCIe switch 520 as an intermediate device connecting SoC 510 and Device 530 (Harriman: par. [0084]. Under BRI, PCIe switch 520 is a transparent switch within a single PCIe domain, not a non-transparent bridge connecting two separate domains);
wherein integrity of a first segment of a communication path between the first host and the second host is protectable with a first integrity code (Harriman teaches a hop-by-hop protocol in which "a different key pair for each link" provides cryptographic protection, where "Keys 501A and 501B are used as the key pair of link 512" and "an integrity code value (ICV) such as a MAC is generated over the packet" (Harriman: pars. [0084], [0090])), and a second segment of the communication path is protectable with a second integrity code (Harriman teaches that on a second link "keys 503A and 503B are used as the key pair of link 522," with the same ICV/MAC mechanism applied per link (Harriman: pars. [0084], [0090]), the second integrity code different than the first integrity code (Harriman: par. [0084]).
Harriman teaches that PCIe system including an SoC 510 as an originating device connected to a PCIe switch 520 via link 512, Device 530 connected to PCIe switch 520 via link 522 as a target device in the same PCIe system as SoC 510, and PCIe switch 520 as an intermediate device connecting SoC 510 and Device 530 s recited above but does not explicitly disclose
a first host of a first Peripheral Component Interconnect Express (“PCIe”), a second host of a second PCIe domain, and a non-transparent bridge (NTB) connecting the first PCIe domain and the second PCIe domain.
However, in analogous art, Wan teaches:
a first host of a first PCIe domain and a second host of a second PCIe domain (Wan: fig. 2, par. [0082] FIG. 2 shows a communications system including two PCie systems. The two PCie systems may communicate with each other through a non-transparent bridge (NTB). The NTB can be deployed on a switch. Because each device in a PCie system is independently managed by its own root, addresses and IDs of devices in different PCie systems may conflict with each other. To ensure that the two systems are connected and communicate with each other normally, bridging translation needs to be performed between the two systems to translate addresses or IDs. The NTB may be responsible for address or ID translation, so that the two PCie systems communicate with each other);
a non-transparent bridge (NTB) connecting the first PCIe domain and the second PCIe domain (Wan: fig. 2, par. [0082], FIG. 2 shows a communications system including two PCie systems. The two PCie systems may communicate with each other through a non-transparent bridge (NTB). The NTB can be deployed on a switch. Because each device in a PCie system is independently managed by its own root, addresses and IDs of devices in different PCie systems may conflict with each other. To ensure that the two systems are connected and communicate with each other normally, bridging translation needs to be performed between the two systems to translate addresses or IDs. The NTB may be responsible for address or ID translation, so that the two PCie systems communicate with each other).
Therefore, it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to combine the teaching of Wan with the system of Harriman to include a first host of a first Peripheral Component Interconnect Express (“PCIe”), a second host of a second PCIe domain, and a non-transparent bridge (NTB) connecting the first PCIe domain and the second PCIe domain. One would have been motivated to apply Harriman's hop-by-hop integrity architecture to Wan's two-PCIe-domain NTB topology because Wan teaches that "addresses and IDs of devices in different PCIe systems may conflict with each other" such that "bridging translation needs to be performed between the two systems to translate addresses or IDs" (Wan: par. [082]). A POSITA would recognize that an end-to-end integrity code computed over those fields would fail verification at the destination after the NTB has performed its translation, and that Harriman's hop-by-hop architecture with "a different key pair for each link" (Harriman: par. [0084]) provides the established alternative protection for communication paths traversing intermediate devices that modify packet fields.
Claims 3-5, 12, and 14-15 are rejected under 35 U.S.C. 103 as being unpatentable over Harriman et al. (“Harriman,” US 2020/0151362) in view of Wan et al. (“Wan,” US 2022/0368781), and Wyseur (“Wyseur,” US 2021/0258297), further in view of S. Kent, RFC 4302 (“Kent,” IP Authentication Header, IETF, Dec. 2005)
Regarding claim 3, the combination of Harriman and Wan teaches the method of claim 1. The combination of Harriman and Wan further teaches
generating the first integrity code based on an integrity-protected portion of a packet (Harriman: par. 0090, "an integrity code value (ICV) such as a MAC is generated over the packet (e.g., prefix, header, data)".; par. 0089, The metadata (e.g., TLP secure stream prefixes, TLP Headers) of a transaction is integrity and replay protected.); and
generating an integrity code [[that is the second integrity code]] [[based on expected modifications]] to the integrity-protected portion of the packet (Harriman: par. [0090]); Wan teaches NTB modification of the integrity-protected portion — "The NTB may be responsible for address or ID translation" (Wan: [082]); Under BRI, Harriman + Wan establish the general framework — source generates integrity code over packet, NTB modifies integrity-protected portion.).
Harriman and Wan do not explicitly disclose generating a "second integrity code" at the source as a pre-computed integrity code distinct from the first, or (ii) generating that second integrity code "based on expected modifications" to the integrity-protected portion.
However, in an analogous art, Wyseur teaches the second integrity code as a pre-computed integrity code at the source (Wyseur teaches "pre-computing a message tag, such as a MAC, and subsequently replacing the computation of the MAC when the tag is to be validated (or indeed also on authentication and sending) by a table look-up" (Wyseur: abstract, [0013])).
Therefore, it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to combine the teaching of Wyseur with Harriman and Wan because to reduce the time required for message authentication" (Wyseur: abstract). KSR (550 U.S. 398, 416–421).
The combination of Harriman, Wan, and Wyseur teaches generating the second integrity code as a pre-computed integrity code but does not expressly teach generating that second integrity code based on expected modifications to the integrity-protected portion.
However, in analogous art, Kent teaches generating an integrity code based on expected modifications to the integrity-protected portion of the packet (Kent: §3.3.3.1.1, “If a field may be modified during transit, the value of the field is set to zero for purposes of the ICV computation. If a field is mutable, but its value at the (IPsec) receiver is predictable, then that value is inserted into the field for purposes of the ICV calculation).
Therefore, it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to combine the teaching of Kent with the method of Harriman, Wan, and Wyseur to include generating the second integrity code based on expected modifications to the integrity-protected portion of the packet. One would have been motivated to compute the second integrity code over expected modifications because Wan teaches that the NTB modifies addresses and IDs of packets crossing between two PCIe systems (Wan: [082]), and Kent teaches the established solution for integrity protection across an intermediate device that modifies header fields — inserting "the predictable [post-modification] value into the field for purposes of the ICV calculation" (Kent: §3.3.3.1.1). KSR (550 U.S. 398, 416–421).
Regarding claim 4, the combination of Harriman, Wan, Wyseur, and Kent teaches the method of claim 3. The combination of Harriman, Wan, Wyseur, and Kent further teaches comprising: determining the expected modifications to the integrity-protected portion of the packet at least partially based on path information received from the NTB (Wan: par. 0082, Wan teaches that "The NTB may be responsible for address or ID translation" between the two PCIe systems, and that the address type (AT) field of a TLP "is used to indicate whether an address needs to be translated" (Wan: [099]); Under broadest reasonable interpretation, Wan establishes that the NTB controls the translation rules — including the specific address and ID modifications applied to packets crossing the bridge. Kent teaches that for the integrity-protecting endpoint to compute the ICV using "the predictable [post-modification] value" of a mutable field, the endpoint must have knowledge of those predicted values (Kent §3.3.3.1.1). The combination of Wan's NTB as the source of translation rules with Kent's requirement that the integrity-protecting endpoint know the predicted post-modification values renders obvious the claimed receipt of path information from the NTB to determine the expected modifications. "At least partially based on" further reads on any contribution of NTB-supplied translation rules to the determination, regardless of whether other information sources also contribute. KSR (550 U.S. 398, 416–421).
Regarding claim 5, the combination of Harriman, Wan, Wyseur, and Kent teaches the method of claim 4. The combination of Harriman, Wan, Wyseur, and Kent further teaches receiving path information from the NTB, the path information comprising path information indicating modifications to an integrity-protected portion of a packet (Wan teaches that "The NTB may be responsible for address or ID translation" between two PCIe systems (Wan: [082]), and that the address type (AT) field of a TLP "is used to indicate whether an address needs to be translated" (Wan: [099]). Under broadest reasonable interpretation, Wan establishes that the NTB controls translation rules — specifically the address and ID modifications applied to packets crossing the bridge. For a programmable NTB to function, its translation rules must be configured by and accessible to host software via standard PCIe configuration register reads; the host's act of obtaining these rules reads on the claimed "receiving path information from the NTB." Harriman teaches that the integrity-protected portion of a TLP includes the header fields modified by the NTB — "metadata (e.g., TLP secure stream prefixes, TLP Headers) of a transaction is integrity and replay protected" (Harriman: [0089]). The NTB-supplied translation rules therefore constitute path information indicating modifications to the integrity-protected portion. Kent §3.3.3.1.1 further teaches that the integrity-protecting endpoint must have knowledge of the predicted post-modification field values, reinforcing that the host's receipt of NTB translation rules is the natural source of that knowledge).
Regarding claim 12, claim 12 is similar in scope to claim 3, and is therefore rejected under similar rationale.
Regarding claim 14, claim 14 is similar in scope to claim 4, and is therefore rejected under similar rationale.
Regarding claim 15, claim 15 is similar in scope to claim 5, and is therefore rejected under similar rationale.
Claims 6-9, 16-18, and 19-20 are rejected under 35 U.S.C. 103 as being unpatentable over Harriman et al. (“Harriman,” US 2020/0151362) in view of Wan et al. (“Wan,” US 2022/0368781), and Wyseur (“Wyseur,” US 2021/0258297), further in view of Shanbhogue et al. (“Shanbhogue,” US 2023/0098288).
Regarding claim 6, the combination of Harriman and Wan teaches the method of claim 1. The combination of Harriman and Wan further teaches, comprising:
receiving a packet with a first integrity code [[and a second integrity code]] (Harriman: par. 0090, receiving a packet at an intermediate device with an integrity code, where "an integrity code value (ICV) such as a MAC is generated over the packet (e.g., prefix, header, data)" and "the ICV is verified" at the receiver.);
verifying the first integrity code (Harriman: par. 0090, teaches that at the receiving device, "the ICV is verified", and in the hop-by-hop architecture, integrity verification is performed at every receiving port (Harriman: [0084]));
modifying an integrity-protected portion of the packet (Harriman: par. 0089, teaches that the integrity-protected portion includes the TLP header — "metadata (e.g., TLP secure stream prefixes, TLP Headers) of a transaction is integrity and replay protected" (Harriman: [0089]); Wan: par. 0082, teaches that "The NTB may be responsible for address or ID translation" between two PCIe systems); and
sending the modified packet [[including the second integrity code]] (Harriman: par. 0084, teaches that the intermediate device forwards the packet onward — "data flowing through a hop-by-hop network with one or more intermediate devices, such as PCIe switch 520, gets encrypted and decrypted several times before it reaches its destination". Wan: par. 0082).
Harriman does not explicitly teach a second integrity code in the received packet, by the intermediate device.
However, in analogous art, Wyseur teaches of a second integrity code as a pre-computed integrity code (Wyseur” par. 0014, teaches "pre-computing a message tag, such as a MAC, and subsequently replacing the computation of the MAC when the tag is to be validated (or indeed also on authentication and sending) by a table look-up").
Therefore, it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to combine the teachings of Wyseur with the method of Harriman and Wan to include “receiving a packet with a first integrity code and a second integrity code”. One would have been motivated to reduce time for manage authentication (Wyseur: abstract).
The combination of Harriman, Wan, and Wyseure teaches receiving a packet with a first integrity code second, integrity code; modifying an integrity-protected portion of the packet and sending the modified packet but does not explicitly disclose “including the second integrity code”.
However, in analogous art, Shanbhogue teaches an intermediate device that does not perform cryptographic computation on integrity codes (Shanbhogue: par. 0322, teaches that "The use of Selective IDE Streams minimizes the TCB and attack surface by allowing intermediate Switches to be excluded from the TCB").
Therefore, it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to combine the teachings of Shanbhogue with the method and system of Wan, Wyseur, and Shanbhogue to include sending the modified packet including the second integrity code including the second integrity code. One would have been motivated to minimize the CB and attack surface (Shanbhogue: par. 0322). KSR (550 U.S. 398, 416–421).
Regarding claim 7, the combination of Harriman, Wan, Wyseur, and Shanbhogue teaches the method of claim 6. The combination of Harriman, Wan, Wyseur, and Shanbhogue further teaches, comprising:
upon verifying the first integrity code writing the second integrity code to a field of the packet for an integrity code protecting an integrity-protected portion of the packet (Harriman: par. [0090], verification of ICV; par. [0100], MAC field 818 in TLP for integrity protection; par. 0089, TLP header and data as integrity-protected portion; Wan: par. 082, NTB modifying the integrity-protected portion; Wyseur: abstract, par. 0013, pre-computed MAC retrieved and used at the moment of authentication or sending; Shanbhogue: par.[ 0322], intermediate switches excluded from TCB / cryptographic computation). Under broadest reasonable interpretation, Harriman's MAC field 818 in the TLP (Harriman: [0100]) reads on the claimed "field of the packet for an integrity code protecting an integrity-protected portion of the packet." Harriman's verification of the ICV (Harriman: [0090]) reads on "upon verifying the first integrity code." Wyseur's pre-computed MAC available at the moment of sending (Wyseur: [0013]) provides the "second integrity code" already in the packet. Shanbhogue's intermediate switch excluded from cryptographic computation (Shanbhogue: [0322]) means the intermediate device does not compute a new MAC. The combination — verify the first integrity code (Harriman), then place the pre-computed second integrity code (Wyseur) into the standard MAC field (Harriman) — yields the claimed writing step as a mechanical, non-cryptographic consequence of the combined teachings. KSR (550 U.S. 398, 416–421).)
Regarding claim 8, the combination of Harriman, Wan, Wyseur, and Shanbhogue teaches the method of claim 7. The combination of Harriman, Wan, Wyseur, and Shanbhogue further teaches, wherein writing the second integrity code to the field comprises overwriting the first integrity code with the second integrity code (Harriman: par. [0090], verification of ICV; par. [0100], MAC field 818 in TLP for integrity protection; par. 0089, TLP header and data as integrity-protected portion; Wan: par. 082, NTB modifying the integrity-protected portion; Wyseur: abstract, par. 0013, pre-computed MAC retrieved and used at the moment of authentication or sending; Shanbhogue: par.[ 0322], intermediate switches excluded from TCB / cryptographic computation). under broadest reasonable interpretation, Harriman's MAC field 818 in the TLP (Harriman: [0100]) is a single defined field holding the integrity code for the integrity-protected portion of the packet. Per the combination established in claim 7, the standard MAC field initially holds the first integrity code (MAC1) when the packet arrives at the intermediate device. After verification of MAC1 per Harriman [0090], MAC1 has served its purpose for the intermediate device and has no further use downstream. Placing the pre-computed second integrity code (per Wyseur [0013]) into the same standard MAC field necessarily overwrites the first integrity code, because the field is a single storage location that can hold only one value. The overwrite is the mechanical consequence of writing MAC2 into the field that already holds MAC1). A POSITA would be motivated to make this combination because combining prior art elements according to known methods yields the predictable result. KSR, 550 U.S. 398, 416–421) of overwriting the first integrity code with the second integrity code in the single standard MAC field of the packet).
Regarding claim 9, he combination of Harriman, Wan, Wyseur, and Shanbhogue teaches the method of claim 6. The combination of Harriman, Wan, Wyseur, and Shanbhogue further teaches:
(a) writing the first integrity code to a first field of a packet, and (a1) writing the second integrity code to a second field of the packet, (a2) wherein the first field is a standard field for storing codes to protect integrity of a PCIe packet, and (a3) wherein the second field is a reserved field (Harriman: par. [0090], verification of ICV; par. [0100], MAC field 818 in TLP for integrity protection; par. 0089, TLP header and data as integrity-protected portion; Wan: par. 082, NTB modifying the integrity-protected portion; Wyseur: abstract, par. 0013, pre-computed MAC retrieved and used at the moment of authentication or sending;. Under broadest reasonable interpretation: The first field as recited in (a) and (a2) reads on Harriman's MAC field 818 — the defined PCIe IDE field for storing the integrity code that protects the integrity-protected portion of the TLP. Harriman [0100] explicitly identifies this as the standard field where the "Message Authentication Code (a.k.a. MAC or Integrity Check) 818" is stored. The first integrity code (MAC1 supplied by Harriman) is written to this standard field; The second field as recited in (a1) and (a3) reads on a reserved field of the TLP. Wan [0018] explicitly teaches the use of reserved values/fields in the TLP header — "the first field is a reserved value. Alternatively, the second field is a reserved value. Alternatively, both the first field and the second field are reserved values" (Wan: [0018]) — to carry additional information beyond standard PCIe semantics. The second integrity code (MAC2 supplied by Wyseur's pre-computation per [0013]) is written to this reserved field; The combination renders the two-field carriage obvious — Harriman supplies the standard MAC field for MAC1, Wan [0018] supplies the reserved field for additional content, Wyseur supplies the pre-computed MAC2 available for storage. A POSITA would be motivated to make this combination because combining prior art elements according to known methods yields the predictable result. 550 U.S. 398, 416–421) of writing the first integrity code to the standard PCIe MAC field and writing the second (pre-computed) integrity code to a reserved field of the packet.).
Regarding claim 16, claim 16 is similar in scope to claim 6, and is therefore rejected under similar rationale.
Regarding claim 17, claim 17 is similar in scope to claim 7, and is therefore rejected under similar rationale.
Regarding claim 18, claim 18 is similar in scope to claim 8, and is therefore rejected under similar rationale.
Regarding claim 19, the combination of Harriman and Wan teaches the system of claim 10. The combination of Harriman and Wan further teaches, wherein the second host to:
receive a packet including an integrity code [[a same integrity code]] in a first field and a second field of the packet, (a1) wherein the first field is a standard field for storing an integrity code for protecting integrity of a PCIe packet, and (a2) wherein the second field is a reserved field (Harriman teaches that the integrity code is stored in the defined MAC field of the TLP — "Message Authentication Code (a.k.a. MAC or Integrity Check) 818" (Harriman: [0100]); Wan teaches reserved-field carriage in the TLP header — "the first field is a reserved value. Alternatively, the second field is a reserved value. Alternatively, both the first field and the second field are reserved values" (Wan: [0018]). Under broadest reasonable interpretation, Harriman's MAC field 818 reads on the claimed "first field ... standard field for storing an integrity code," and Wan's reserved field reads on the claimed "second field ... reserved field.");
read an integrity code [[the second integrity code]] from the first field of the packet (Harriman teaches that the receiving device reads the integrity code from the defined MAC field and verifies it — "the ICV is verified" (Harriman: [0090]). Under broadest reasonable interpretation, Harriman's verification of the ICV at the receiver reads on the claimed reading and verifying steps for an integrity code in the first field. Harriman teaches reading and verifying an integrity code generically); and
verifying the integrity code [[the second integrity code]] (Harriman teaches that the receiving device reads the integrity code from the defined MAC field and verifies it — "the ICV is verified" (Harriman: [0090]). Under broadest reasonable interpretation, Harriman's verification of the ICV at the receiver reads on the claimed reading and verifying steps for an integrity code in the first field. Harriman teaches reading and verifying an integrity code generically).
The combination of Harriman and Wan does not explicitly expressly teach a same integrity code in both fields, or that the integrity code read from the first field is the second integrity code originating from the first host as a pre-computed integrity code.
However, in analogous art, Wyseur teaches the second integrity code as a pre-computed integrity code (Wyseur teaches "pre-computing a message tag, such as a MAC, and subsequently replacing the computation of the MAC when the tag is to be validated (or indeed also on authentication and sending) by a table look-up" (Wyseur: abstract, [0013]); Under broadest reasonable interpretation, Wyseur establishes that an integrity code may be pre-computed at the source and used at the destination without recomputation. Combined with Harriman's standard MAC field, Wan's reserved field, and Harriman's standard ICV verification at the receiver, Wyseur's pre-computed integrity code supplies the claimed "second integrity code" — stored at the source in the packet, present in both the standard and reserved fields, read from the standard field by the second host, and verified by the second host. The "same integrity code in both fields" of limitation (a) reads on the pre-computed integrity code per Wyseur stored in both fields of the packet).
Therefore, it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to combine the teaching of Wyseur with the method and system of Harriman and Wan because Wyseur teaches that pre-computing a MAC "reduces the time required for message authentication" (Wyseur: abstract). KSR (550 U.S. 398, 416–421).
The combination of Harriman, Wan, and Wyseur teaches that the pre-computed integrity code originates from the first host and is stored in the packet for downstream verification by the second host.
The combination does not expressly teach that the pre-computed integrity code survives transit from the first host to the second host without alteration by intermediate devices.
However, in analogous art, Shanbhogue teaches that intermediate devices do not perform cryptographic computation on integrity codes (Shanbhogue teaches that "The use of Selective IDE Streams minimizes the TCB and attack surface by allowing intermediate Switches to be excluded from the TCB" (Shanbhogue: [0322]).
Therefore, it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to combine the teaching of Shanbhogue with
the method and system of Harriman, Wan, and Wyseur because Shanbhogue teaches that excluding intermediate switches from the TCB "minimizes the TCB and attack surface" of the system (Shanbhogue: [0322]). KSR (550 U.S. 398, 416–421).
Regarding claim 20, the combination of Harriman and Wan teaches the system of claim 10. The combination of Harriman and Wan further teaches, wherein the second host to:
receive a packet including the first integrity code in a first field [[and the second integrity code]] in a second field of the packet, (a1) wherein the first field is a standard field for storing an integrity code for protecting integrity of a PCIe packet, and (a2) wherein the second field is a reserved field (Harriman teaches that the integrity code is stored in the defined MAC field of the TLP — "Message Authentication Code (a.k.a. MAC or Integrity Check) 818" (Harriman: [0100]); Wan teaches reserved-field carriage in the TLP header — "the first field is a reserved value. Alternatively, the second field is a reserved value. Alternatively, both the first field and the second field are reserved values" (Wan: [0018]); under broadest reasonable interpretation, Harriman's MAC field 818 reads on the claimed "first field ... standard field for storing an integrity code," and Wan's reserved field reads on the claimed "second field ... reserved field." Harriman's MAC in the standard field reads on the claimed "first integrity code.");
read an integrity code [[the second integrity code]] from the second field of the packet (Wan: [0018]); Under broadest reasonable interpretation, Harriman's verification of the ICV at the receiver, combined with Wan's reserved-field carriage, reads on the claimed reading and verifying steps for an integrity code in the second (reserved) field. Harriman teaches reading and verifying an integrity code generically); and
verify the integrity code [[the second integrity code]] (Wan: [0018]); Under broadest reasonable interpretation, Harriman's verification of the ICV at the receiver, combined with Wan's reserved-field carriage, reads on the claimed reading and verifying steps for an integrity code in the second (reserved) field. Harriman teaches reading and verifying an integrity code generically).
The combination of Harriman and Wan does not explicitly teach a second integrity code in the reserved field as a pre-computed integrity code originating from the first host, or that the integrity code read from the second field is the second integrity code originating from the first host.
However, in analogous art, Wyseur teaches the second integrity code as a pre-computed integrity code (Wyseur teaches "pre-computing a message tag, such as a MAC, and subsequently replacing the computation of the MAC when the tag is to be validated (or indeed also on authentication and sending) by a table look-up" (Wyseur: abstract, [0013]); Under broadest reasonable interpretation, Wyseur establishes that an integrity code may be pre-computed at the source and used at the destination without recomputation. Combined with Harriman's standard MAC field, Wan's reserved field, and Harriman's standard ICV verification at the receiver, Wyseur's pre-computed integrity code supplies the claimed "second integrity code" — stored at the source in the reserved field of the packet, read from the reserved field by the second host, and verified by the second host using standard ICV verification).
Therefore, it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to combine the teaching of Wyseur with the method and system of Harriman and Wan because Wyseur teaches that pre-computing a MAC "reduces the time required for message authentication" (Wyseur: abstract). KSR (550 U.S. 398, 416–421).
The combination of Harriman, Wan, and Wyseur teaches that the pre-computed integrity code originates from the first host and is stored in the reserved field for downstream verification by the second host.
The combination does not expressly teach that the pre-computed integrity code in the reserved field survives transit from the first host to the second host without alteration by intermediate devices.
However, in analogous art, Shanbhogue teaches that intermediate devices do not perform cryptographic computation on integrity codes (Shanbhogue teaches that "The use of Selective IDE Streams minimizes the TCB and attack surface by allowing intermediate Switches to be excluded from the TCB" (Shanbhogue: [0322]).
Therefore, it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to combine the teaching of Shanbhogue with the method and system of Harriman, Wan, and Wyseur because Shanbhogue teaches that excluding intermediate switches from the TCB "minimizes the TCB and attack surface" of the system (Shanbhogue: [0322]). KSR (550 U.S. 398, 416–421).
Claim 13 is rejected under 35 U.S.C. 103 as being unpatentable over Harriman et al. (“Harriman,” US 2020/0151362) in view of Wan et al. (“Wan,” US 2022/0368781), and Wyseur (“Wyseur,” US 2021/0258297), and further in view of S. Kent, RFC 4302 (“Kent,” IP Authentication Header, IETF, Dec. 2005).
Regarding claim 13, the combination of Harriman, Wan, Wyseur, and Kent teaches the system of claim 12. The combination of Harriman, Wan, Wyseur, and Kent further teaches wherein the first host to:
(a) write the first integrity code to a first field of a packet, (a1) and write the second integrity code to a second field of the packet, (a2) wherein the first field is a standard field for storing codes to protect integrity of a PCIe packet, and (a2) wherein the second field is a reserved field ((Harriman: par. [0090], verification of ICV; par. [0100], MAC field 818 in TLP for integrity protection; par. 0089, TLP header and data as integrity-protected portion; Wan: par. 082, NTB modifying the integrity-protected portion; Wyseur: abstract, par. 0013, pre-computed MAC retrieved and used at the moment of authentication or sending;. Under broadest reasonable interpretation: The first field as recited in (a) and (a2) reads on Harriman's MAC field 818 — the defined PCIe IDE field for storing the integrity code that protects the integrity-protected portion of the TLP. Harriman [0100] explicitly identifies this as the standard field where the "Message Authentication Code (a.k.a. MAC or Integrity Check) 818" is stored. The first integrity code (MAC1 supplied by Harriman) is written to this standard field; The second field as recited in (a1) and (a3) reads on a reserved field of the TLP. Wan [0018] explicitly teaches the use of reserved values/fields in the TLP header — "the first field is a reserved value. Alternatively, the second field is a reserved value. Alternatively, both the first field and the second field are reserved values" (Wan: [0018]) — to carry additional information beyond standard PCIe semantics. The second integrity code (MAC2 supplied by Wyseur's pre-computation per [0013]) is written to this reserved field; The combination renders the two-field carriage obvious — Harriman supplies the standard MAC field for MAC1, Wan [0018] supplies the reserved field for additional content, Wyseur supplies the pre-computed MAC2 available for storage,. A POSITA would be motivated to make this combination because combining prior art elements according to known methods yields the predictable result. KSR, 550 U.S. 398, 416–421) of writing the first integrity code to the standard PCIe MAC field and writing the second (pre-computed) integrity code to a reserved field of the packet).
Claims 21, 24, 25, and 28 are rejected under 35 U.S.C. 103 as being unpatentable over Harriman et al. (“Harriman,” US 2020/0151362) in view of Wan et al. (“Wan,” US 2022/0368781)
Regarding claim 21, Harriman teaches a method comprising:
protecting integrity of a first segment of a communication path with an end-to-end integrity code (Harriman: fig. 5B, end-to-end PCIe protocol, par. 0085, In an end-to-end protocol shown in fig. 5B, different key pairs are provisioned for each end-to-end link 507 and 509. Keys are provided only at an initiating device and a target device. For example, keys 506A and 506B are used as the key pair for the end-to-end link 507, and keys 508A and 508B are used as the key pair for the end-to-end link 509. An initiating device encrypts data to be transmitted to a target device, the target device decrypts the data received from the initiating device, and intermediate devices simply route the encrypted transactions. For example, when SoC 510 sends data to device 530, SoC 510 is the initiating device and device 530 is the target device. Conversely, when device 530 sends data to SoC 510, device 530 is the initiating device and SoC 510 is the target device; par. 0090, At IDE TKP 662 [], the prefix is inserted into the packet, an integrity code value (ICV) such as a MAC is generated over the packet (e.g., prefix, header, data), and the ICV is added to the packet; par. 0083, For a device connected to the server platform via a serial interconnect interface, such as peripheral component interface express (PCie ), enabling direct assignment of the device to TD memory requires the data flowing between the TD and the device over the PCie link to be secured to enforce confidentiality, integrity, and replay protection of the data), PCIe switch 520 as an intermediate device in the end-to-end architecture (Harriman: [0085], Under BRI, Harriman's switch 520 is a transparent PCIe switch within a single domain); and
protecting integrity of a second segment of the communication path with the end-to-end integrity code (Harriman: par. 0085, par. 0083, For a device connected to the server platform via a serial interconnect interface, such as peripheral component interface express (PCie ), enabling direct assignment of the device to TD memory requires the data flowing between the TD and the device over the PCie link to be secured to enforce confidentiality, integrity, and replay protection of the data).
Harriman teaches PCIe switch 520 as an intermediate device in the end-to-end architecture (Harriman: par. 0085 but does not explicitly disclose
different Peripheral Component Interconnect Express (“PCIe”) domains and the different PCIe domains connected by a non-transparent bridge ("NTB");
However, in analogous art, Wan teaches
different PCIe domains connected by a non-transparent bridge (NTB) (Wan: fig. 2, par. [0082] FIG. 2 shows a communications system including two PCie systems. The two PCie systems may communicate with each other through a non-transparent bridge (NTB). The NTB can be deployed on a switch. Because each device in a PCie system is independently managed by its own root, addresses and IDs of devices in different PCie systems may conflict with each other. To ensure that the two systems are connected and communicate with each other normally, bridging translation needs to be performed between the two systems to translate addresses or IDs. The NTB may be responsible for address or ID translation, so that the two PCie systems communicate with each other).
Therefore, it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to combine the teaching of Wan with the method of Harriman to include the different PCIe domains connected by a non-transparent bridge ("NTB"). One would have been motivated to apply Harriman's end-to-end integrity architecture to Wan's two-PCIe-domain NTB topology because Wan teaches that two PCIe systems may "communicate with each other through a non-transparent bridge (NTB)" deployed on a switch (Wan: par. [082]). Harriman expressly teaches end-to-end as a designed protocol option in which "intermediate devices simply route the encrypted transactions" (Harriman: par. [0085]) — a mode in which the intermediate device (the NTB of Wan) does not participate in the cryptographic protection and the same integrity code spans the entire path. A POSITA would recognize that applying Harriman's end-to-end architecture to Wan's NTB topology yields a system in which a single end-to-end integrity code protects both segments of the path on either side of the NTB.
Regarding claim 24, the combination of Harriman and Wan teaches the method of claim 21. The combination of Harriman and Wan further teaches the method, comprising:
defining the first segment of the communication path between a first host and a PCIe switch in non-transparent bridge mode (Harriman: par. [0084], Harriman further teaches an end-to-end architecture in which intermediate devices route packets between source and destination endpoints (Harriman: par. [0085]); Wan teaches that "the NTB can be deployed on a switch" between two PCIe systems to enable cross-domain communication (Wan: par. [082])); and
defining the second segment of the communication path between the PCIe switch in non-transparent bridge mode and a second host (Harriman: par. [0084], Harriman further teaches an end-to-end architecture in which intermediate devices route packets between source and destination endpoints (Harriman: [0085]); Wan teaches that "the NTB can be deployed on a switch" between two PCIe systems to enable cross-domain communication (Wan: [082])).
Regarding claim 25, Harriman teaches a system, comprising:
Harriman teaches an initiating device (e.g. SoC 510) connected to PCIe topology and operating in an end-to-end protocol (Harriman: fig. 5B, end-to-end PCIe protocol, par. 0084, par. 0085, In an end-to-end protocol shown in fig. 5B, different key pairs are provisioned for each end-to-end link 507 and 509. Keys are provided only at an initiating device and a target device. For example, keys 506A and 506B are used as the key pair for the end-to-end link 507, and keys 508A and 508B are used as the key pair for the end-to-end link 509. An initiating device encrypts data to be transmitted to a target device, the target device decrypts the data received from the initiating device, and intermediate devices simply route the encrypted transactions. For example, when SoC 510 sends data to device 530, SoC 510 is the initiating device and device 530 is the target device. Conversely, when device 530 sends data to SoC 510, device 530 is the initiating device and SoC 510 is the target device; par. 0090, At IDE TKP 662 [], the prefix is inserted into the packet, an integrity code value (ICV) such as a MAC is generated over the packet (e.g., prefix, header, data), and the ICV is added to the packet; par. 0083, For a device connected to the server platform via a serial interconnect interface, such as peripheral component interface express (PCie ), enabling direct assignment of the device to TD memory requires the data flowing between the TD and the device over the PCie link to be secured to enforce confidentiality, integrity, and replay protection of the data);
Harriman further teaches a target device (e.g., Device 530) connected in the same PCIe topology as the initiating device (Harriman: fig. 5, pars. 0084-0085); and
Harriman teaches further PCIe switch 520 as an intermediate device between the initiating device and the target device in the end-to-end architecture (Harriman: fig. 5, pars. 0084-0085);
wherein integrity of a first segment of a communication path between the first host and the second host protectable with an end-to-end integrity code (Harriman: pars. 0085, 0090; par. 0083, For a device connected to the server platform via a serial interconnect interface, such as peripheral component interface express (PCie ), enabling direct assignment of the device to TD memory requires the data flowing between the TD and the device over the PCie link to be secured to enforce confidentiality, integrity, and replay protection of the data.), and integrity of a second segment of the communication path protectable with the end-to-end integrity code (Harriman: par. 0085, par. 0083, For a device connected to the server platform via a serial interconnect interface, such as peripheral component interface express (PCie ), enabling direct assignment of the device to TD memory requires the data flowing between the TD and the device over the PCie link to be secured to enforce confidentiality, integrity, and replay protection of the data, Note that).
Harriman teaches that PCIe system including an SoC 510 as an originating device connected to a PCIe switch 520 via link 512, Device 530 connected to PCIe switch 520 via link 522 as a target device in the same PCIe system as SoC 510, and PCIe switch 520 as an intermediate device connecting SoC 510 and Device 530 s recited above but does not explicitly disclose
a first host of a first PCIe domain, a second host of a second PCIe domain, and a non-transparent bridge (NTB) connecting the first PCIe domain and the second PCIe domain.
However, in analogous art, Wan teaches
a first host of a first PCIe domain and (a second host of a second PCIe domain (Wan: fig. 2, par. [0082] FIG. 2 shows a communications system including two PCie systems. The two PCie systems may communicate with each other through a non-transparent bridge (NTB). The NTB can be deployed on a switch. Because each device in a PCie system is independently managed by its own root, addresses and IDs of devices in different PCie systems may conflict with each other. To ensure that the two systems are connected and communicate with each other normally, bridging translation needs to be performed between the two systems to translate addresses or IDs. The NTB may be responsible for address or ID translation, so that the two PCie systems communicate with each other);
a non-transparent bridge (NTB) connecting the first PCIe domain and the second PCIe domain (Wan: fig. 2, par. [0082] FIG. 2 shows a communications system including two PCie systems. The two PCie systems may communicate with each other through a non-transparent bridge (NTB). The NTB can be deployed on a switch. Because each device in a PCie system is independently managed by its own root, addresses and IDs of devices in different PCie systems may conflict with each other. To ensure that the two systems are connected and communicate with each other normally, bridging translation needs to be performed between the two systems to translate addresses or IDs. The NTB may be responsible for address or ID translation, so that the two PCie systems communicate with each other).
Therefore, it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to combine the teaching of Wan with the system of Harriman to include a first host of a first PCIe domain, a second host of a second PCIe domain, and a non-transparent bridge (NTB) connecting the first PCIe domain and the second PCIe domain. One would have been motivated to apply Harriman's end-to-end integrity architecture to Wan's two-PCIe-domain NTB topology because Wan teaches that two PCIe systems may "communicate with each other through a non-transparent bridge (NTB)" deployed on a switch (Wan: par. [082]). Harriman expressly teaches end-to-end as a designed protocol option in which "intermediate devices simply route the encrypted transactions" (Harriman: par. [0085]) — a mode in which the intermediate device (the NTB of Wan) does not participate in the cryptographic protection and the same integrity code spans the entire path. A POSITA would recognize that applying Harriman's end-to-end architecture to Wan's NTB topology yields a system structurally capable of protecting both segments of the path with a single end-to-end integrity code.
Regarding claim 28, claim 28 is similar in scope to claim 24, and is therefore rejected under similar rationale.
Claims 22-23 and 26-27 are rejected under 35 U.S.C. 103 as being unpatentable over Harriman et al. (“Harriman,” US 2020/0151362) in view of Wan et al. (“Wan,” US 2022/0368781), further in view of S. Kent, RFC 4302 (“Kent,” IP Authentication Header, IETF, Dec. 2005)
Regarding claim 22, the combination of Harriman and Wan teaches the method of claim 21. The combination of Harriman and Wan further teaches comprising:
generating the end-to-end integrity code [[based on expected modifications]] to an integrity-protected portion of a packet (Harriman teaches that the integrity code is generated over the packet at the source — "an integrity code value (ICV) such as a MAC is generated over the packet (e.g., prefix, header, data)" (Harriman: [0090]) — and that the integrity-protected portion includes the TLP header — "metadata (e.g., TLP secure stream prefixes, TLP Headers) of a transaction is integrity and replay protected" (Harriman: [0089]); Wan: par. 0082, teaches that the NTB modifies the integrity-protected portion).
The combination of Harriman and Wan teaches generating the end-to-end integrity code [[based on expected modifications]] to an integrity-protected portion of a packet but does not explicitly disclose “based on expected modifications to the integrity-protected portion of the packet.”
However, in analogous art, Ken teaches (a)generating the end-to-end integrity code based on expected modifications to an integrity-protected portion of a packet (Kent: §3.3.3.1.1, teaches "If a field is mutable, but its value at the (IPsec) receiver is predictable, then that value is inserted into the field for purposes of the ICV calculation).
Therefore, it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to combine the teachings of Kent with the method and system of Harriman and Wan because Wan teaches that the NTB modifies addresses and IDs of packets crossing between two PCIe systems (Wan: [082]), and Kent teaches the established solution for integrity protection across an intermediate device that modifies header fields — inserting "the predictable [post-modification] value into the field for purposes of the ICV calculation" (Kent: §3.3.3.1.1). KSR (550 U.S. 398, 416–421).
Regarding claim 23, the combination of Harriman, Wan, and Kent teaches the method of claim 22. The combination of Harriman, Wan, and Kent further teaches, comprising:
determining the expected modifications to the integrity-protected portion of the packet at least partially based on path information received from the NTB (Wan teaches that "The NTB may be responsible for address or ID translation" between the two PCIe systems (Wan: [082]), and that the address type (AT) field of a TLP "is used to indicate whether an address needs to be translated" (Wan: [099]); Under broadest reasonable interpretation, Wan establishes that the NTB controls the translation rules — including the specific address and ID modifications applied to packets crossing the bridge. Kent teaches that for the integrity-protecting endpoint to compute the ICV using "the predictable [post-modification] value" of a mutable field, the endpoint must have knowledge of those predicted values (Kent: §3.3.3.1.1). The combination of Wan's NTB as the source of translation rules with Kent's requirement that the integrity-protecting endpoint know the predicted post-modification values renders obvious the claimed receipt of path information from the NTB to determine the expected modifications. "At least partially based on" further reads on any contribution of NTB-supplied translation rules to the determination, regardless of whether other information sources also contribute. KSR (550 U.S. 398, 416–421)).
Regarding claim 26, claim 26 is similar in scope to claim 22, and is therefore rejected under similar rationale.
Regarding claim 27, claim 26 is similar in scope to claim 23, and is therefore rejected under similar rationale.
Conclusion
Any inquiry concerning this communication or earlier communications from the examiner should be directed to CANH LE whose telephone number is (571)270-1380. The examiner can normally be reached on Monday to Friday 6:00AM to 3:30PM other Friday off.
If attempts to reach the examiner by telephone are unsuccessful, the examiner’s supervisor, Luu Pham, can be reached at telephone number 571-270-5002. The fax phone number for the organization where this application or proceeding is assigned is 571-273-8300.
Information regarding the status of an application may be obtained from Patent Center and the Private Patent Application Information Retrieval (PAIR) system. Status information for published applications may be obtained from Patent Center or Private PAIR. Status information for unpublished applications is available through Patent Center and Private PAIR for authorized users only. Should you have questions about access to the Private PAIR system, contact the Electronic Business Center (EBC) at 866-217-9197 (toll-free).
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) Form at https://www.uspto.gov/patents/uspto-automated- interview-request-air-form.
/Canh Le/
Examiner, Art Unit 2439
May 27th, 2026
/LUU T PHAM/Supervisory Patent Examiner, Art Unit 2439
Prosecution Insights