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.
Priority
Acknowledgment is made of applicant's claim for foreign priority under 35 U.S.C. 119(a)-(d). The certified copy has been received.
Election/Restrictions
Applicant’s election without traverse of claims 1-18 and 26 in the reply filed on 12/17/25 is acknowledged. As such, claims 1-18 and 26 are examined and claims 19-25 are withdrawn from consideration.
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
The prior art made of record and not relied upon is considered pertinent to applicant's disclosure is listed on the enclosed PTO-892 form.
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 - Friday, 9:30am - 5:30pm, 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