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
The instant application having Application No. 18/595,475 is presented for examination by the examiner. Claims 1-26 are pending. Claims 19-25 are withdrawn. Claims 1-18 and 26 are examined.
Response to Arguments
Applicant's arguments filed 5/20/26 have been fully considered but they are not persuasive.
Applicant alleges that Petry does not explicitly teach receiving first cryptographic material offloaded from the local host device over the host interface. In response to applicant's argument that the references fail to show certain features of the invention, it is noted that the features upon which applicant relies (i.e., timing of offloading being after finishing the handshake or part of finishing the handshake) are not recited in the rejected claim(s). Although the claims are interpreted in light of the specification, limitations from the specification are not read into the claims. See In re Van Geuns, 988 F.2d 1181, 26 USPQ2d 1057 (Fed. Cir. 1993).
Petry teaches that host processor 102 may populate/update values in flow descriptor lookup table 926, where the flow descriptor contains cryptographic material including a MAC secret and encryption key. FAP 104 subsequently retires the flow descriptor from lookup table 926 based on the packet flow key and uses the retrieved security context for packet processing. Thus, the host’s placement/update of cryptographic material in a lookup structure accessible to FAP 104 can be interpreted as offloading to cryptographic material from the host processor to the packet-processing hardware.
Applicant also purports that Petry does not explicitly teach generating the DTLS headers in hardware. Applicant points to paragraph 0128 and Table 4 for support. However, there is no evidence of the host 102 generating the header in paragraph 0128 and Table 4. These passages explain that host can append a transmit descriptor telling FAP how to process the packet. Table 4 lists “Header data” as a template for headers that the FAP may copy into the outgoing packet. The nuance is that the host can provide template and seed information (initial sequence number) but it is not the completed outgoing header attached to the packet. Petry explicitly says in 0127 that the FAP 104 receives a packet from the transmit buffer and generates the DTLS headers and calculates the DTLS MAC. This is where Petry generates the actual header that is attached to the packet. It is not simply a copy/paste of the template or seed information. Paragraph 0155-0157 explain that the FAP may write header fields and inserts the DTLS sequence numbers into active packets and itself must manage and track the fields (0145). The FAP updates these fields and values as the packets are processed. The host is not responsible for any of this processing. This packet processing is performed in hardware by the FAP. The claim does not require more than what is taught by Petry. In view of the foregoing, respectfully, the rejection must be maintained.
With respect to the first 103 argument, Applicant alleges that Petry and Boyd are fundamentally incompatible. The word bypass host processor is particular troublesome in this context but to support the idea of incompatible, then bypass needs to require zero involvement. But host processor still has a role to play even if they are not doing the heavy lifting. The host processor in Petry is not clueless about what is happening. There is some involvement. In RDMA, the host need not process the RDMA payload itself. Therefore, the RDMA advantage is not defeated because the host need not process the RDMA payload. The host can configure the state and the accelerator can handle the packets using the established state. RDMA is not free of the host CPU in an absolute sense. RDMA bypasses host processing of the data path while permitting the host to establish and control the state. Petry host side provisioning of DTLS therefore does not conflict with the use of RDMA packets because the FAP subsequently retrieves and applies the cryptographic functioning of each RDMA payload without requiring host processing. This goes back to the previous argument because Applicant alleges the host provides this processing. As shown above, it provisions a starting template but the FAP actively generating each header and updates their fields accordingly.
The remainder of the arguments are fall back to the hardware argument. Therefore, the previous response applies and, respectfully, the rejections must be maintained.
Claim Rejections - 35 USC § 102
In the event the determination of the status of the application as subject to AIA 35 U.S.C. 102 and 103 (or as subject to pre-AIA 35 U.S.C. 102 and 103) is incorrect, any correction of the statutory basis for the rejection will not be considered a new ground of rejection if the prior art relied upon, and the rationale supporting the rejection, would be the same under either status.
The following is a quotation of the appropriate paragraphs of 35 U.S.C. 102 that form the basis for the rejections under this section made in this Office action:
A person shall be entitled to a patent unless –
(a)(1) the claimed invention was patented, described in a printed publication, or in public use, on sale, or otherwise available to the public before the effective filing date of the claimed invention.
Claims 1, 3-7, 10, 11, and 26 are rejected under 35 U.S.C. 102(a)(1) as being anticipated by USP Application Publication 2013/0329557 to Petry et al., hereinafter Petry.
As per claims 1 and 26, Petry teaches a system, comprising a local networking device (100), including:
a host interface [comm interface 108] to receive first packets from a local host device (0019);
packet processing hardware [combination of FAP 104 and Security Coprocessor 106] to:
receive first cryptographic material offloaded from the local host device over the host interface [host 102 places these material in lookup table that FAP 104 can pull from; 0128, 0137 and Table 4];
perform cryptographic operations on the first packets based on the first cryptographic material (0127 and 0210-0212);
generate first datagram transport layer security (DTLS) headers including respective DTLS sequence numbers in hardware (0127, 0145, and 0155-0157); and
encapsulate the first packets with the first DTLS headers in hardware (0127, 0137, 0140, and 0179); and
a network interface [switch] to send the first packets with the first DTLS headers to a remote networking device over a packet data network (0126 and 0216).
As per claim 3, Petry teaches the network interface is to receive from the remote networking device over the packet data network second packets having headers including second DTLS headers (0032 and 0034);
the packet processing hardware is to:
parse the headers of the second packets (0032 and 0034);
construct second cryptographic material from at least one of the second DTLS headers [calculates a MAC to be checked; 0033 and 0034];
find at least one decryption key in the first cryptographic material based on source and destination data [flow key based on IP4 source/destination; 0051] in at least one of the second DTLS headers [flow key used to locate key in lookup table; 0032 and 0084];
decrypt and authenticate the second packets based on the at least one decryption key and the second cryptographic material (0033 and 0034); and
perform replay protection checks based on DTLS sequence numbers of the second packets (0075 and 0076).
As per claim 4, Petry teaches the packet processing hardware is to: check a DTLS data type of the second packets [table 1, content type];
pass control packets [table 1, “port 5246 for control packets] of the second packets to host software running on the local host device (0071 and 0072); and decapsulate data packets of the second packets [separates payload from header for checking; 0016 and 0034].
As per claim 5, Petry teaches the packet processing hardware is to perform a direct memory access operation of a host memory of the local host device after decapsulating the data packets (0020 and 0122).
As per claim 6, Petry teaches the packet processing hardware is to retain the DTLS sequence numbers of the first packets in plaintext for sending to the remote networking device [Table 1, 0026 and handshake unencrypted; 0124].
As per claim 7, Petry teaches the packet processing hardware is to generate header fields of the first DTLS headers at a fixed length per header field (0094).
As per claim 10, Petry teaches the local host device including a processor to run software to: establish a DTLS connection with a remote host device using a DTLS handshake [handshaking message evident; 0112-0114]; and offload the first cryptographic material to the local networking device (0018 and 0129).
As per claim 11, Petry teaches the software running on the processor of the local host device is to generate each of the first packets with a single DTLS record [Petry teaches that a packet may contain multiple DTLS records. Since they ‘may’ contain multiple DTLS record they are not required to and thus they may contain a single DTLS record; 0117].
Claim Rejections - 35 USC § 103
In the event the determination of the status of the application as subject to AIA 35 U.S.C. 102 and 103 (or as subject to pre-AIA 35 U.S.C. 102 and 103) is incorrect, any correction of the statutory basis for the rejection will not be considered a new ground of rejection if the prior art relied upon, and the rationale supporting the rejection, would be the same under either status.
The following is a quotation of 35 U.S.C. 103 which forms the basis for all obviousness rejections set forth in this Office action:
A patent for a claimed invention may not be obtained, notwithstanding that the claimed invention is not identically disclosed as set forth in section 102 of this title, 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 2 is rejected under 35 U.S.C. 103 as being unpatentable over Petry in view of WO2004/0233054A1 to Boyd et al., hereinafter Boyd.
As per claim 2, Petry is silent in explicitly teaching the first packets include remote direct memory access (RDMA) packets. Petry teaches an offload acceleration networking data path that is content independent. In other words, the type of content being transmitted does not matter. Boyd teaches accelerating RDMA messages to a network accelerator (pg. 1, lines 7-13 and pg. 18, lines 27-42). See also pg. 19, lines 29-31 where the hardware in the host takes work elements that are queued and places it into frame to be communicated. This is the same process by which Petry accelerates packets from the host using the FAP. Since, Petry is not concerned with the type of message that is encapsulated into DTLS messages, given the teachings of Boyd, the RDMA messages could have been accelerated in the system of Petry. Boyd shows that it was known to offload to RDMA enable NICs. Petry uses offloading to a FAP to send message to a remote device. The claim is obvious because one of ordinary skill in the art can combine methods known before the effective filing date which produce predictable results. Offloading RDMA messages through the FAP of Petry would have produced a predictable result because it was already known in the art that RDMA messages could be offloaded to a RNIC and Petry’s system is not bound to any particular type of payload.
Claim 8 is rejected under 35 U.S.C. 103 as being unpatentable over Petry in view of NPL entitled “RFC 9147 The Datagram Transport Layer Security (DTLS) Protocol Version 1.3” published April 2022, hereinafter RFC 9147.
As per claim 8, Petry teaches the packet processing hardware is to: receive a DTLS control message from the local host device;
generate a DTLS sequence number for the DTLS control message (0127, 0145 and 0155-0157);
save the DTLS sequence number for the DTLS control message to a memory of the local host device (0133 and 0145);
add a DTLS header to the DTLS control message in hardware (0127), the DTLS header of the DTLS control message including the DTLS sequence number of the DTLS control message (0155 and 01570;
send the DTLS control message to a remote host device (0126 and 0216);
and receive offload of the new cryptographic material from the software [each type the cryptograph material is found in the lookup table using the flow key and the host updates that material (0032).
Petry is silent in explicitly teaching (i) the DTLS control message is a key update DTLS control message and (ii) receive from the remote host device an acknowledgment DTLS control message including the DTLS sequence number of the key update message as an acknowledgement message of the key update message; provide the acknowledgment DTLS control message to software running on the local host device.
Petry uses DTLS to encapsulate packets. RFC 9147 is the standard for DTLS 1.3. In that standard, key update commands are defined. Petry can send any type of message using DTLS. DTLS 1.3 was known to use key update messaging (pg. 41). Therefore, key updates could have obviously been sent by the host to the remote device and the FAP would have performed the exact same processing steps to add DTLS headers with sequence number. In fact, RFC 9147 states that DTLS headers have sequence numbers (Figure 4, pg. 11). So, any key update message would have a sequence number and the protocol demands that it does. On page 41, RFC 9147 states that all key update messages must be responded to with an ACK message. The ACK message explicitly references a record number (pg. 39). The record number is comprised of the sequence number and an epoch (pg. 11). Therefore RFC 9147 teach both (i) and (ii) from above as they are taught to be part of the DTLS 1.3 protocol. One of ordinary skill in the art could have implemented DTLS 1.3 in the system of Petry with predictable results. The claim is obvious because one of ordinary skill in the art can combine methods known before the effective filing date which produce predictable results.
Claim 12 is rejected under 35 U.S.C. 103 as being unpatentable over Petry in view of NPL entitled “RFC 8446 - The Transport Layer Security (TLS) Protocol Version 1.3”, hereinafter RFC 8446.
As per claim 12, Petry is silent in explicitly teaching the software running on the processor of the local host device is to generate each of the first packets with a same padding length. RFC 8446 teaches the software running on the processor of the local host device is to generate each of the first packets with a same padding length as means to increase security by making all of the payload a fixed amount (pg. 80 and 83) to hide the size of the traffic. This is specifically taught to be done in TLS 1.3 to which DTLS shares many features. Therefore, one of ordinary skill in the art could have used the fixed padding amount taught in RFC 8446 in the packets of Petry to hide the size of the traffic. The claim is obvious because one of ordinary skill in the art can combine methods known before the effective filing date which produce predictable results.
Allowable Subject Matter
Claims 9 and 13-18 are 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.
Conclusion
Applicant's amendment necessitated the new ground(s) of rejection presented in this Office action. Accordingly, THIS ACTION IS MADE FINAL. See MPEP § 706.07(a). Applicant is reminded of the extension of time policy as set forth in 37 CFR 1.136(a).
A shortened statutory period for reply to this final action is set to expire THREE MONTHS from the mailing date of this action. In the event a first reply is filed within TWO MONTHS of the mailing date of this final action and the advisory action is not mailed until after the end of the THREE-MONTH shortened statutory period, then the shortened statutory period will expire on the date the advisory action is mailed, and any extension fee pursuant to 37 CFR 1.136(a) will be calculated from the mailing date of the advisory action. In no event, however, will the statutory period for reply expire later than SIX MONTHS from the date of this final action.
Any inquiry concerning this communication or earlier communications from the examiner should be directed to MICHAEL R. VAUGHAN whose telephone number is (571)270-7316. The examiner can normally be reached on Monday - Thursday, 7:30am - 5:00pm, EST. If attempts to reach the examiner by telephone are unsuccessful, the examiner’s supervisor, Lynn Feild can be reached on (571) 272-2092. 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 the Patent Application Information Retrieval (PAIR) system. Status information for published applications may be obtained from either Private PAIR or Public PAIR. Status information for unpublished applications is available through Private PAIR only. For more information about the PAIR system, see http://pair-direct.uspto.gov. Should you have questions on access to the Private PAIR system, contact the Electronic Business Center (EBC) at 866-217-9197 (toll-free). If you would like assistance from a USPTO Customer Service Representative or access to the automated information system, call 800-786-9199 (IN USA OR CANADA) or 571-272-1000.
/MICHAEL R VAUGHAN/
Primary Examiner, Art Unit 2431
Prosecution Insights