DETAILED ACTION
Notice of Pre-AIA or AIA Status
The present application, filed on or after March 16, 2013, is being examined under the first inventor to file provisions of the AIA .
This office action is responsive to a response filed on March 09th, 2026. In this Office Action:
Claims 1-20 are pending.
Claims 1-20 are rejected.
Information Disclosure Statement
The information disclosure statement (IDS) submitted on March 09th, 2026 is in compliance with the provisions of 37 CFR 1.97. Accordingly, the information disclosure statement is being considered by the examiner.
Summary of Previous Office Action
In the Non-Final Office Action mailed on December 12th, 2025:
Claims 1-2, 4-6, 9-13, and 15-20 were objected to because of the informalities.
Claims 2-9, 12-20 were rejected under 35 U.S.C. 112(b) or 35 U.S.C. 112 (pre-AIA ), second paragraph, as being indefinite for failing to particularly point out and distinctly claim the subject matter which the inventor or a joint inventor (or for applications subject to pre-AIA 35 U.S.C. 112, the applicant), regards as the invention.
Claim 1 was rejected under 35 U.S.C. 103 as being unpatentable over Eriksson et al. (Pub. No. US 2015/0058446), hereinafter Eriksson; in view of Kannan et al. (Pub. No. US 2018/0024830), hereinafter Kannan.
Claims 2-3 and 9 were rejected under 35 U.S.C. 103 as being unpatentable over Eriksson et al. (Pub. No. US 2015/0058446), hereinafter Eriksson; in view of Kannan et al. (Pub. No. US 2018/0024830), hereinafter Kannan; and further in view of Pong (Pub. No. US 2007/0260719).
Claims 4-8 were rejected under 35 U.S.C. 103 as being unpatentable over Eriksson et al. (Pub. No. US 2015/0058446), hereinafter Eriksson; in view of Kannan et al. (Pub. No. US 2018/0024830), hereinafter Kannan; further in view of Pong (Pub. No. US 2007/0260719); and further in view of Hendel et al. (Pub. No. US 2004/0013117), hereinafter Hendel.
Claims 10-11 were rejected under 35 U.S.C. 103 as being unpatentable over Eriksson et al. (Pub. No. US 2015/0058446), hereinafter Eriksson; in view of Kannan et al. (Pub. No. US 2018/0024830), hereinafter Kannan; and further in view of Hendel et al. (Pub. No. US 2004/0013117), hereinafter Hendel.
Claims 12-15 and 19-20 were rejected under 35 U.S.C. 103 as being unpatentable over Pong (Pub. No. US 2007/0260719); in view of Eriksson et al. (Pub. No. US 2015/0058446), hereinafter Eriksson.
Claims 16-18 were rejected under 35 U.S.C. 103 as being unpatentable over Pong (Pub. No. US 2007/0260719); in view of Eriksson et al. (Pub. No. US 2015/0058446), hereinafter Eriksson; and further in view of Hendel et al. (Pub. No. US 2004/0013117), hereinafter Hendel.
Response to Amendment
The amendments filed on March 09th, 2026 have been entered.
Claims 1, 7-8, 12-13, 15, 18, and 20 have been amended.
The previously raised claim objections are withdrawn for claims 1-2, 4-6, 9-13, and 15-20 in light of the amendments.
The previously raised 35 U.S.C. 112(b) rejection is withdrawn for claims 2-9 and 12-20 in light of the amendments.
Response to Arguments
Applicant’s arguments filed on March 09th, 2026 have been fully considered, but are moot in view of the new grounds of rejection, as presented in this Office Action.
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, 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.
The factual inquiries set forth in Graham v. John Deere Co., 383 U.S. 1, 148 USPQ 459 (1966), that are applied for establishing a background for determining obviousness under 35 U.S.C. 103 are summarized as follows:
1. Determining the scope and contents of the prior art.
2. Ascertaining the differences between the prior art and the claims at issue.
3. Resolving the level of ordinary skill in the pertinent art.
4. Considering objective evidence present in the application indicating obviousness or nonobviousness.
Claim 1 is rejected under 35 U.S.C. 103 as being unpatentable over Eriksson et al. (Pub. No. US 2015/0058446), hereinafter Eriksson; in view of Schlansker et al. (Patent No. US 7,788,437), hereinafter Schlansker.
Claim 1. Eriksson discloses [a] server device comprising:
a host device including a Transmission Control Protocol (TCP) data buffer configured to store a first data of a first request to be transmitted to a network (See Parag. [0011]; a first communication device configured for real-time communication over TCP with a second communication device. The first communication device comprises processor circuitry, and a storage unit storing instructions (i.e., code) that, when executed by the processor circuitry, cause the first communication device to obtain a first TCP segment, having a first sequence number, from a TCP buffer in a TCP layer in the first communication device. See also Parag. [0030]. Examiner’s note: Applicant discloses in the Specification, Parag. [0028], that a request is a command); and
a network interface device configured to receive the first parameter, fetch the first data from a region of the TCP data buffer corresponding to the first sequence number, and generate a first TCP packet for the first request (See Parag. [0011]; cause the first communication device to obtain a first TCP segment, having a first sequence number, from a TCP buffer in a TCP layer in the first communication device. The instructions also cause the first communication device to form a first IP packet comprising the first TCP segment. See Parag. [0032]; The communication device also comprises a communication interface. Examiner’s interpretation: The Examiner interprets “an interface device configured to receive the first parameter, fetch the first data from a region of the TCP data buffer …” as the first communication device is using the first parameter (i.e., first sequence number) to obtain the first TCP segment from the TCP buffer).
Eriksson doesn’t explicitly disclose a first command queue configured to store a first parameter of the first request including a first sequence number for the first data; receive the first parameter from the first command queue; [and] the network interface device not including an internal buffer for retransmission of the first data.
However, Schlansker discloses a first command queue (See Fig. 1; “command buffer 110”) configured to store a first parameter of the first request including a first sequence number for the first data; receive the first parameter from the first command queue (See Col. 4 lines 1-13; The command buffer 110 holds pertinent information about all of the pending transfers. This information may include the address of the remote NIC 122, message sequence number, time-out, pending message status, retransmit buffer pointer and message length. The network interface control processor 116 utilizes the information in the command buffer 110 to configure the network interface 118 for the retransmission of the message. Examiner’s note: Applicant discloses in the Specification, Parag. [0028], that a request is a command); [and] the network interface device (See Fig. 1; “network interface 118”) not including an internal buffer for retransmission (See Fig. 1; “retransmission buffer 114”) of the first data (See Col. 9 lines 44-52; The remote NIC 122 address and the message sequence number are loaded into the network interface 118 ... the transmission formatter 206 is configured for sending the contents of the retransmit buffer 114 to the network interface 118 which is further coupled to the network 120).
It would be obvious to one of ordinary skill in the art at the time before the effective filling date of the claimed invention to modify the obtaining of the first TCP segment, having a first sequence number, from a TCP buffer in a TCP layer in the first communication device, taught by Eriksson, to include a first command queue configured to store a first parameter of the first request including a first sequence number for the first data, receive the first parameter from the first command queue, and the network interface device not including an internal buffer for retransmission of the first data, as taught by Schlansker. This would be convenient in reducing application latency when communicating with the packet switched data network (Schlansker, See Col. 1 lines 6-9).
Claims 2-3 and 9 are rejected under 35 U.S.C. 103 as being unpatentable over Eriksson et al. (Pub. No. US 2015/0058446), hereinafter Eriksson; in view of Schlansker et al. (Patent No. US 7,788,437), hereinafter Schlansker; and further in view of Pong (Pub. No. US 2007/0260719).
Claim 2. Eriksson in view of Schlansker discloses [t]he server device of claim 1,
Eriksson in view of Schlansker doesn’t explicitly disclose wherein the network interface device comprises: a TCP controller configured to output a first header information by performing a TCP operation for the first parameter, a host interface configured to receive the first data by way of a direct memory access (DMA) from the TCP data buffer in response to a first access signal; and a packet generator configured to generate the first TCP packet by receiving the first header information from the TCP controller, and receiving the first data from the host interface.
However, Pong discloses wherein the network interface device comprises:
a TCP controller configured to output a first header information by performing a TCP operation for the first parameter (See Parag. [0046]; The protocol processors 422 direct the TCP Tx engine 425 to prepare and write TCP/IP headers to the allocated buffer TxBuf 610. See Parag. [0051]; TCP engine 425 provides the TCP/IP header length information. See Parag. [0052-0056]; The protocol processor provides the following information: the RDMA header length information, the length of the payload to transfer, the starting TCP sequence number (sseq) for the very first byte of the outgoing TCP packet, the initial RDMA send sequence number (rdma_iss). See also Parag. [0046] [0047]),
a host interface configured to receive the first data by way of a direct memory access (DMA) from the TCP data buffer in response to a first access signal (See Parag. [0046]; The protocol processors 422 instruct the inbound DMA engine 520 in HIF (i.e., Host Interface) 320 to copy outgoing data from the host buffer into TxBuf 610. See also Parag. [0049]; HIF 320 has completed copying data from the source host data buffer into the TxBuf 610. See also Fig. 4); and
a packet generator configured to generate the first TCP packet by receiving the first header information from the TCP controller, and receiving the first data from the host interface (See Parag. [0045]; The protocol processors 422 direct the TCP Tx engine 425 to prepare and write TCP/IP headers to the allocated buffer TxBuf 610 … See Parag. [0049]; After HIF (i.e., Host Interface) 320 has completed copying data from the source host data buffer into the TxBuf 610, HIF 320 will signal the transmit control/unload logic 630 of the Tx interface 310. Tx interface 310 then directs its transmit control/unload logic 630 to read the packet out of the TxBuf 610 into the transmit buffer 640. Along this path, a data formatter 650 will "pack" the data byte stream, resulting in the format shown on the right of FIG. 7. See Parag. [0052-0057]; From the length information, the data formatter 650 can gather necessary data. Starting with the sequence number rdma_iss, data formatter 650 will insert a marker, four bytes in length, at a stride of every 512 bytes … Examiner’s note: A packet is generated to comprise the data stream shown in Fig. 7 by the transmit interface (TxIF) 310 including the data formatter 650; See Fig. 6).
It would be obvious to one of ordinary skill in the art at the time before the effective filling date of the claimed invention to modify the first communication device configured for real-time communication over TCP with the second communication device, taught by Eriksson in view of Schlansker, to comprise a TCP controller configured to output a first header information by performing a TCP operation for the first parameter, a host interface configured to receive the first data by way of a direct memory access (DMA) from the TCP data buffer in response to a first access signal; and a packet generator configured to generate the first TCP packet by receiving the first header information from the TCP controller, and receiving the first data from the host interface, as taught by Pong. This would be convenient to provide a system with which MPA markers and CRC digests can be easily inserted and removed during RDMA communications (Pong, Parag. [0009]).
Claim 3. Eriksson in view of Schlansker and Pong discloses [t]he server device of claim 2,
Eriksson in view of Schlansker doesn’t explicitly disclose wherein the first data is delivered to the packet generator from the host interface without being buffered or copied.
However, Pong discloses wherein the first data is delivered to the packet generator from the host interface without being buffered or copied (See Parag. [0049]; After HIF (i.e., Host Interface) 320 has completed copying data from the source host data buffer into the TxBuf 610, HIF 320 will signal the transmit control/unload logic 630 of the Tx interface 310. Tx interface 310 then directs its transmit control/unload logic 630 to read the packet out of the TxBuf 610 into the transmit buffer 640. Along this path, a data formatter 650 will "pack" the data byte stream, resulting in the format shown on the right of FIG. 7. See Parag. [0046]; … instruct the inbound DMA engine 520 in HIF 320 to copy outgoing data from the host buffer into TxBuf 610. See Parag. [0004]; Remote DMA (RDMA) is a technology for transferring data from the memory of one computer or server to the memory of another, without involving a CPU or operating system of either machine. Because the data being transferred is not stored in application memory or in operating system buffers, RDMA is said to accomplish the transfer in a "zero-copy" manner. Examiner’s note: Direct Memory Access (DMA) is a data transfer strategy that bypasses the CPU “zero-copy”).
It would be obvious to one of ordinary skill in the art at the time before the effective filling date of the claimed invention to modify the first communication device configured for real-time communication over TCP with the second communication device, taught by Eriksson in view of Schlansker, to include wherein the first data is delivered to the packet generator from the host interface without being buffered or copied, as taught by Pong. This would be convenient to provide a system with which MPA markers and CRC digests can be easily inserted and removed during RDMA communications (Pong, Parag. [0009]).
Claim 9. Eriksson in view of Schlansker and Pong discloses [t]he server device of claim 2,
Eriksson further discloses wherein the first sequence number is different from a sequence number of a TCP header of the first TCP packet (See Parag. [0034]; … the first and second TCP segments 44 in the TCP buffer comprise payload data 43 to be transmitted in the first and second IP packets 46, respectively, and wherein the forming a second IP packet comprises transforming the second TCP segment into an IP packet which is then transformed into the second IP packet, said transforming into the second IP packet 91 comprising replacing a second sequence number of the second TCP segment with the first sequence number of the first TCP segment in the second IP packet. See also Parag. [0051]).
Claims 4-8 are rejected under 35 U.S.C. 103 as being unpatentable over Eriksson et al. (Pub. No. US 2015/0058446), hereinafter Eriksson; in view of Schlansker et al. (Patent No. US 7,788,437), hereinafter Schlansker; further in view of Pong (Pub. No. US 2007/0260719); and further in view of Hendel et al. (Pub. No. US 2004/0013117), hereinafter Hendel.
Claim 4. Eriksson in view of Schlansker and Pong discloses [t]he server device of claim 2,
The combination doesn’t explicitly disclose wherein the network interface device further comprises: a receive parser configured to extract a second header information from a second TCP packet received from the network, and transmit a second data to the host interface without being buffered or copied.
However, Hendel discloses a receive parser configured to extract a second header information from a second TCP packet received from the network, and transmit a second data to the host interface without being buffered or copied (See Parag. [0035]; packets received at communication interface 110 are separated into their payload and header portions in accordance with payload separation 120. By dividing packets in this manner, protocol processing of headers can be separated from the storage of payloads and management of the storage buffers. More specifically, from the sequence number of a packet payload, a host buffer is identified through buffer mapping 124, and the payload is placed in the buffer through DMA in accordance with DMA transfer 128. After the DMA is completed, the header portion of the packet is forwarded to a host processor according to encapsulation 126. See Parag. [0009]; the payloads need not be buffered or temporarily stored in the communication interface and need not be handled by a host processor. However, packet headers are passed to the host processor. Thus, protocol termination remains in the host, while payload storage is performed by the communication interface. See Parag. [0023]; Upon receipt, packet payloads are forwarded directly to their destination host, application or consumer through DMA (Direct Memory Access) operations, without requiring intermediate buffering or copying. See also Parag. [0025] [0034]).
It would be obvious to one of ordinary skill in the art at the time before the effective filling date of the claimed invention to modify the network interface device, taught by the combination, to comprise a receive parser configured to extract a second header information from a second TCP packet received from the network, and transmit a second data to the host interface without being buffered or copied, as taught by Hendel. This would be convenient for reducing the amount of processing necessary to separate a packet payload from its headers and pass the payload to its destination (Hendel, Parag. [0008]).
Claim 5. Eriksson in view of Schlansker, Pong (combination), and Hendel discloses [t]he server device of claim 4,
The combination doesn’t explicitly disclose wherein the host interface transmits the second data by way of the DMA to a region corresponding to a second sequence number for the second data, within the TCP data buffer.
However, Hendel discloses wherein the host interface transmits the second data by way of the DMA to a region corresponding to a second sequence number for the second data, within the TCP data buffer (See Parag. [0025]; communication interface such as a TCA (Target Channel Adapter) or NIC (Network Interface Card) receives packets from a network or other communication link. The interface separates a packet's payload from its headers, transfers the payload to a host memory buffer (via DMA). See Parag. [0011]; The payload sequence number is compared to the anchor sequence number to determine whether and where the payload falls within the translation window. The sequence numbers of the beginning and end of the payload may be considered to determine which buffer(s) the payload should be stored in. Illustratively, the host buffers may be seen as "overlaying" the sequence number space of the connection, so that each sequence number with the sequence number space maps to a location within one of the buffers. See also Parag. [0010]).
It would be obvious to one of ordinary skill in the art at the time before the effective filling date of the claimed invention to modify the network interface device, taught by the combination, to comprise wherein the host interface transmits the second data by way of the DMA to a region corresponding to a second sequence number for the second data, within the TCP data buffer, as taught by Hendel. This would be convenient for reducing the amount of processing necessary to separate a packet payload from its headers and pass the payload to its destination (Hendel, Parag. [0008]).
Claim 6. Eriksson in view of Schlansker, Pong (combination), and Hendel discloses [t]he server device of claim 5,
The combination doesn’t explicitly disclose wherein the host device further comprises: a TCP session table configured to store a pair of transmit offsets and a pair of receive offsets corresponding to the first sequence number and the second sequence number and representing a state of the TCP data buffer for each TCP session.
However, Hendel discloses a TCP session table configured to store a pair of transmit offsets and a pair of receive offsets corresponding to the first sequence number and the second sequence number and representing a state of the TCP data buffer for each TCP session (See Parag. [0045]; when a new connection is opened and connection table 210 is initialized for the connection, anchor buffer identifier 222 is configured to identify the first buffer in the buffer list (e.g., buffer number zero). Anchor sequence number 220 is set to the value ISN+1. As one skilled in the art will appreciate, when a TCP connection is opened, an ISN (Initial Sequence Number) is (randomly) assigned to mark the beginning of the TCP stream. See Parag. [0046]; an anchor buffer "start offset" field may be defined (e.g., within connection table 210) to indicate an offset of the anchor sequence number within a buffer (e.g., the buffer corresponding to anchor buffer identifier 222)).
It would be obvious to one of ordinary skill in the art at the time before the effective filling date of the claimed invention to modify the host device, taught by the combination, to comprises a TCP session table configured to store a pair of transmit offsets and a pair of receive offsets corresponding to the first sequence number and the second sequence number and representing a state of the TCP data buffer for each TCP session, as taught by Hendel. This would be convenient for reducing the amount of processing necessary to separate a packet payload from its headers and pass the payload to its destination (Hendel, Parag. [0008]).
Claim 7. Eriksson in view of Schlansker, Pong (combination), and Hendel discloses [t]he server device of claim 6,
The combination doesn’t explicitly disclose wherein one of the pair of transmit offsets is updated when the transmission of the first data is acknowledged, and one of the pair of receive offsets is updated when a reception of the second data is acknowledged.
However, Hendel discloses wherein one of the pair of transmit offsets is updated when the transmission of the first data is acknowledged, and one of the pair of receive offsets is updated when a reception of the second data is acknowledged (See Parag. [0071]; a host processor that receives and processes a packet header (or an entire packet) may instruct the communication interface to update connection table data for the packet's connection. For example, the anchor may be adjusted as the receive translation window slides along the connection space, when a buffer is posted or consumed (thereby necessitating an update to a buffer status), etc. See Parag. [0075]; When a buffer is unmapped or purged, the connection anchor is updated accordingly. In particular, the anchor buffer identifier and the anchor sequence number are advanced. Thus, when a new connection is opened, and a corresponding connection table is initialized, the connection anchor is set to the first buffer and the anchor sequence number is derived from ISN (e.g., ISN+1). Thereafter, as buffers are posted and consumed, the anchor is updated to move with the receive window. See Parag. [0077]; In FIG. 4, receive translation window 404 slides along TCP sequence number space 402 as connection data are received and acknowledged … See also Parag. [0045-0046] [0072-0074).
It would be obvious to one of ordinary skill in the art at the time before the effective filling date of the claimed invention to modify the host device system, taught by the combination, to include wherein one of the pair of transmit offsets is updated when the transmission of the first data is acknowledged, and one of the pair of receive offsets is updated when the reception of the second data is acknowledged, as taught by Hendel. This would be convenient for reducing the amount of processing necessary to separate a packet payload from its headers and pass the payload to its destination (Hendel, Parag. [0008]).
Claim 8. Eriksson in view of Schlansker, Pong, and Hendel discloses [t]he server device of claim 4,
Eriksson doesn’t explicitly disclose wherein the host device further comprises: a second command queue configured to receive and store a second parameter corresponding to the second header information from the network interface device.
However, Schlansker discloses a second command queue configured to receive and store a second parameter corresponding to the second header information from the network interface device (See Col. 5 lines 26-29; Data from the bus interface 202 may couple directly to the command buffer 110, the retransmit buffer 114, the transmit buffer 204 and the receive buffer 208. See also Col. 8 lines 34-42 and Fig. 2).
It would be obvious to one of ordinary skill in the art at the time before the effective filling date of the claimed invention to modify the host device, taught by Eriksson, to include a second command queue configured to receive and store a second parameter corresponding to the second header information from the network interface device, as taught by Schlansker. This would be convenient in reducing application latency when communicating with the packet switched data network (Schlansker, See Col. 1 lines 6-9).
Claims 10-11 are rejected under 35 U.S.C. 103 as being unpatentable over Eriksson et al. (Pub. No. US 2015/0058446), hereinafter Eriksson; in view of Schlansker et al. (Patent No. US 7,788,437), hereinafter Schlansker; and further in view of Hendel et al. (Pub. No. US 2004/0013117), hereinafter Hendel.
Claim 10. Eriksson in view of Schlansker discloses [t]he server device of claim 1,
Eriksson in view of Schlansker doesn’t explicitly disclose wherein the TCP data buffer is addressed by a number of least significant bits of the first sequence number corresponding to a size of the TCP data buffer.
However, Hendel discloses wherein the TCP data buffer is addressed by a number of least significant bits of the first sequence number corresponding to a size of the TCP data buffer (See Parag. [0010]; when a packet is received at the communication interface, its communication connection is identified, its payload is delineated and a sequence number (e.g., a TCP sequence number) of the payload is determined. From per-connection data stored on the interface, an anchor sequence number and anchor buffer identifier are retrieved. The anchor sequence number is a sequence number associated with the beginning of a receive translation window for the connection, while the anchor buffer identifier identifies a host buffer encompassing the anchor sequence number. The connection data may also include a circular list of host buffers for receiving connection payloads, states of those buffers (e.g., to indicate whether they are available), the length of the buffer list, a size of the buffers, etc. See also Parag. [0047]).
It would be obvious to one of ordinary skill in the art at the time before the effective filling date of the claimed invention to modify the first communication device configured for real-time communication over TCP with the second communication device, taught by Eriksson in view of Schlansker, to include wherein the TCP data buffer is addressed by a number of least significant bits of the first sequence number corresponding to a size of the TCP data buffer, as taught by Hendel. This would be convenient for reducing the amount of processing necessary to separate a packet payload from its headers and pass the payload to its destination (Hendel, Parag. [0008]).
Claim 11. Eriksson in view of Schlansker discloses [t]he server device of claim 1,
Eriksson in view of Schlansker doesn’t explicitly disclose wherein the TCP data buffer comprises sub-buffer regions corresponding to each TCP session.
However, Hendel discloses wherein the TCP data buffer comprises sub-buffer regions corresponding to each TCP session (See Parag. [0048]; buffer list 224 is a circular list and the combined areas of the buffers provides sufficient storage space to cover some or all of the total sequence number space in the communication connection specified by connection identifier 212. See also Parag. [0076]; the connection is a TCP connection and the sequence number space is based on the TCP sequence numbering of packets within the connection).
It would be obvious to one of ordinary skill in the art at the time before the effective filling date of the claimed invention to modify the first communication device configured for real-time communication over TCP with the second communication device, taught by Eriksson in view of Schlansker, to include wherein the TCP data buffer comprises sub-buffer regions corresponding to each TCP session, as taught by Hendel. This would be convenient for reducing the amount of processing necessary to separate a packet payload from its headers and pass the payload to its destination (Hendel, Parag. [0008]).
Claims 12-15 and 19-20 are rejected under 35 U.S.C. 103 as being unpatentable over Pong (Pub. No. US 2007/0260719); in view of Schlansker et al. (Patent No. US 7,788,437), hereinafter Schlansker.
Claim 12. Pong discloses [a] network interface device comprising:
a Transmission Control Protocol (TCP) controller configured to generate a first header information by performing a TCP operation on a received first request (See Parag. [0046]; The protocol processors 422 direct the TCP Tx engine 425 to prepare and write TCP/IP headers to the allocated buffer TxBuf 610. See Parag. [0051]; TCP engine 425 provides the TCP/IP header length information. See also Parag. [0046] [0047]. Examiner’s interpretation: Applicant discloses in the Specification, Parag. [0028], that a request is a command);
a host interface configured to receive a first data corresponding to the first request from an external source (See Parag. [0046]; The protocol processors 422 instruct the inbound DMA engine 520 in HIF (i.e., Host Interface) 320 to copy outgoing data from the host buffer into TxBuf 610. See also Parag. [0049]; HIF 320 has completed copying data from the source host data buffer into the TxBuf 610. See also Fig. 4. Examiner’s interpretation: The first data is received from a source external to the host interface); and
a packet generator configured to generate a first TCP packet corresponding to the first request by receiving the first header information from the TCP controller, and receiving the first data from the host interface (See Parag. [0045]; The protocol processors 422 direct the TCP Tx engine 425 to prepare and write TCP/IP headers to the allocated buffer TxBuf 610 … See Parag. [0049]; After HIF (i.e., Host Interface) 320 has completed copying data from the source host data buffer into the TxBuf 610, HIF 320 will signal the transmit control/unload logic 630 of the Tx interface 310. Tx interface 310 then directs its transmit control/unload logic 630 to read the packet out of the TxBuf 610 into the transmit buffer 640. Along this path, a data formatter 650 will "pack" the data byte stream, resulting in the format shown on the right of FIG. 7. See Parag. [0052-0057]; From the length information, the data formatter 650 can gather necessary data. Starting with the sequence number rdma_iss, data formatter 650 will insert a marker, four bytes in length, at a stride of every 512 bytes … Examiner’s note: A packet is generated to comprise the data stream shown in Fig. 7 by the transmit interface (TxIF) 310 including the data formatter 650; See Fig. 6).
Pong doesn’t explicitly disclose receiving the first data in response to a first access signal that includes an information corresponding to a sequence number for the first data; [and] wherein, in response to retransmission of the first data, the host interface is further configured to receive the first data fetched from the external source.
However, Schlansker discloses receive a first data in response to a first access signal that includes an information corresponding to a sequence number for a first data of the first request; [and] wherein, in response to retransmission of the first data, the host interface is further configured to receive the first data fetched from the external source (See Col. 4 lines 1-13; The command buffer 110 holds pertinent information about all of the pending transfers. This information may include the address of the remote NIC 122, message sequence number, time-out, pending message status, retransmit buffer pointer and message length. The network interface control processor 116 utilizes the information in the command buffer 110 to configure the network interface 118 for the retransmission of the message. Examiner’s interpretation: The first data is received from a source external to the host interface Examiner’s note: Applicant discloses in the Specification, Parag. [0028], that a request is a command).
It would be obvious to one of ordinary skill in the art at the time before the effective filling date of the claimed invention to modify Pong to include receiving the first data in response to a first access signal that includes an information corresponding to a sequence number for the first data, and wherein, in response to retransmission of the first data, the host interface is further configured to receive the first data fetched from the external source, as taught by Schlansker. This would be convenient in reducing application latency when communicating with the packet switched data network (Schlansker, See Col. 1 lines 6-9).
Claim 13. Pong in view of Schlansker discloses [t]he network interface device of claim 12,
Pong further discloses wherein the host interface comprises: a Direct Memory Access (DMA) controller (“DMA engine 520”) configured to transmit the first data by way of a direct memory access (See Parag. [0046]; … instruct the inbound DMA engine 520 in HIF 320 to copy outgoing data from the host buffer into TxBuf 610. See also Parag. [0048] and Fig. 5).
Claim 14. Pong in view of Schlansker discloses [t]he network interface device of claim 12,
Pong further discloses wherein the first data is delivered from the host interface to the packet generator without being buffered or copied (See Parag. [0049]; After HIF (i.e., Host Interface) 320 has completed copying data from the source host data buffer into the TxBuf 610, HIF 320 will signal the transmit control/unload logic 630 of the Tx interface 310. Tx interface 310 then directs its transmit control/unload logic 630 to read the packet out of the TxBuf 610 into the transmit buffer 640. Along this path, a data formatter 650 will "pack" the data byte stream, resulting in the format shown on the right of FIG. 7. See Parag. [0046]; … instruct the inbound DMA engine 520 in HIF 320 to copy outgoing data from the host buffer into TxBuf 610. See Parag. [0004]; Remote DMA (RDMA) is a technology for transferring data from the memory of one computer or server to the memory of another, without involving a CPU or operating system of either machine. Because the data being transferred is not stored in application memory or in operating system buffers, RDMA is said to accomplish the transfer in a "zero-copy" manner. Examiner’s note: Direct Memory Access (DMA) is a data transfer strategy that bypasses the CPU “zero-copy”).
Claim 15. Pong in view of Schlansker discloses [t]he network interface device of claim 12,
Pong further discloses wherein the packet generator comprises:
a first header queue configured to receive the first header information from the TCP controller (See Parag. [0045]; The protocol processors 422 direct the TCP Tx engine 425 to prepare and write TCP/IP headers to the allocated buffer TxBuf 610. See also Fig. 6. Examiner’s note: The buffer TxBuf 610 is within the transmit interface (TxIF) 310 that generates the packet),
a first data queue configured to receive the first data from the host interface (See Parag. [0046]; … instruct the inbound DMA engine 520 in HIF (i.e., Host Interface) 320 to copy outgoing data from the host buffer into TxBuf 610. See also Parag. [0049]; HIF 320 has completed copying data from the source host data buffer into the TxBuf 610),
a header generator configured to generate a TCP header of the first TCP packet by receiving the first header information from the first header queue (See Parag. [0047]; a transmit packet in the TxBuf 610 has the layout shown on the left in FIG. 7 … each TxBuf is 2 KB in size. When one of protocol processors 422 issues a transmit request, the protocol processor allocates a TxBuf. The first 256 bytes will be reserved. The TCP Tx engine 425 will fill the first 128-byte region 710 with an ethernet header 715, an IP header 720, and a TCP header 725. The protocol processor will fill the next 128-byte region 730 with RDMA protocol headers 735. See Parag. [0049]; … data formatter 650 will "pack" the data byte stream, resulting in the format shown on the right of FIG. 7 …);
a payload generator configured to receive the first data from the first data queue and process it as a payload of the first TCP packet (See Parag. [0048-0049]; packet payload 740 starts at the point that is 256 bytes offset from the beginning of the TxBuf 610 … After HIF 320 has completed copying data from the source host data buffer into the TxBuf 610, HIF 320 will signal the transmit control/unload logic 630 of the Tx interface 310. Tx interface 310 then directs its transmit control/unload logic 630 to read the packet out of the TxBuf 610 into the transmit buffer 640. Along this path, a data formatter 650 will "pack" the data byte stream, resulting in the format shown on the right of FIG. 7); and
a combiner configured to combine the TCP header and the payload and output the combined TCP header and payload as the first TCP packet (See Parag. [0045]; The protocol processors 422 direct the TCP Tx engine 425 to prepare and write TCP/IP headers to the allocated buffer TxBuf 610 … See Parag. [0049]; After HIF 320 has completed copying data from the source host data buffer into the TxBuf 610, HIF 320 will signal the transmit control/unload logic 630 of the Tx interface 310. Tx interface 310 then directs its transmit control/unload logic 630 to read the packet out of the TxBuf 610 into the transmit buffer 640. Along this path, a data formatter 650 will "pack" the data byte stream, resulting in the format shown on the right of FIG. 7 See Parag. [0047]; a transmit packet in the TxBuf 610 has the layout shown on the left in FIG. 7).
Claim 19. Pong in view of Schlansker discloses [t]he network interface device of claim 12,
Pong further discloses wherein the first access signal is output from the TCP controller simultaneously with the generation of the first header information or after the first header information is generated (See Parag. [0046]; The protocol processors 422 then direct the TCP Tx engine 425 to prepare and write TCP/IP headers to the allocated buffer TxBuf 610, and instruct the inbound DMA engine 520 in HIF 320 to copy outgoing data from the host buffer into TxBuf 610).
Claim 20. Pong in view of Schlansker discloses [a] method of operating the network interface device of claim 12,
Pong further discloses the method comprising:
receiving the first request from the external source by the host interface (See Parag. [0046]; The protocol processors 422 instruct the inbound DMA engine 520 in HIF (i.e., Host Interface) 320 to copy outgoing data from the host buffer into TxBuf 610. Examiner’s interpretation: Applicant discloses in the Specification, Parag. [0028], that a request is a command);
generating the first header information by performing the TCP operation for the first request by the TCP controller (See Parag. [0046]; The protocol processors 422 direct the TCP Tx engine 425 to prepare and write TCP/IP headers to the allocated buffer TxBuf 610. See Parag. [0051]; TCP engine 425 provides the TCP/IP header length information);
receiving the first data from the external source by way of Direct Memory Access (DMA), in response to the first access signal, by the host interface (See Parag. [0046]; The protocol processors 422 instruct the inbound DMA engine 520 in HIF (i.e., Host Interface) 320 to copy outgoing data from the host buffer into TxBuf 610. See also Parag. [0049]; HIF 320 has completed copying data from the source host data buffer into the TxBuf 610. See also Fig. 4); and
generating the first TCP packet by receiving the first header information from the TCP controller, and by receiving the first data from the host interface without being buffered or copied by the packet generator (See Parag. [0045]; The protocol processors 422 direct the TCP Tx engine 425 to prepare and write TCP/IP headers to the allocated buffer TxBuf 610 … See Parag. [0049]; After HIF (i.e., Host Interface) 320 has completed copying data from the source host data buffer into the TxBuf 610, HIF 320 will signal the transmit control/unload logic 630 of the Tx interface 310. Tx interface 310 then directs its transmit control/unload logic 630 to read the packet out of the TxBuf 610 into the transmit buffer 640. Along this path, a data formatter 650 will "pack" the data byte stream, resulting in the format shown on the right of FIG. 7. See Parag. [0052-0057]; From the length information, the data formatter 650 can gather necessary data. Starting with the sequence number rdma_iss, data formatter 650 will insert a marker, four bytes in length, at a stride of every 512 bytes … Examiner’s note: A packet is generated to comprise the data stream shown in Fig. 7 by the transmit interface (TxIF) 310 including the data formatter 650; See Fig. 6. See Parag. [0004]; Remote DMA (RDMA) is a technology for transferring data from the memory of one computer or server to the memory of another, without involving a CPU or operating system of either machine. Because the data being transferred is not stored in application memory or in operating system buffers, RDMA is said to accomplish the transfer in a "zero-copy" manner. Examiner’s note: Direct Memory Access (DMA) is a data transfer strategy that bypasses the CPU “zero-copy”).
Claims 16-18 are rejected under 35 U.S.C. 103 as being unpatentable over Pong (Pub. No. US 2007/0260719); in view of Schlansker et al. (Patent No. US 7,788,437), hereinafter Schlansker; and further in view of Hendel et al. (Pub. No. US 2004/0013117), hereinafter Hendel.
Claim 16. Pong in view of Schlansker discloses [t]he network interface device of claim 12,
Pong in view of Schlansker doesn’t explicitly disclose the network interface device further comprises: a receive parser configured to extract a second header information and a second data from a second TCP packet received from a network, and transmit the second data to the host interface without being buffered or copied.
However, Hendel discloses a receive parser configured to extract a second header information and a second data from a second TCP packet received from a network, and transmit the second data to the host interface without being buffered or copied (See Parag. [0035]; packets received at communication interface 110 are separated into their payload and header portions in accordance with payload separation 120. By dividing packets in this manner, protocol processing of headers can be separated from the storage of payloads and management of the storage buffers. More specifically, from the sequence number of a packet payload, a host buffer is identified through buffer mapping 124, and the payload is placed in the buffer through DMA in accordance with DMA transfer 128. After the DMA is completed, the header portion of the packet is forwarded to a host processor according to encapsulation 126. See Parag. [0009]; the payloads need not be buffered or temporarily stored in the communication interface and need not be handled by a host processor. However, packet headers are passed to the host processor. Thus, protocol termination remains in the host, while payload storage is performed by the communication interface. See also Parag. [0025] [0034]).
It would be obvious to one of ordinary skill in the art at the time before the effective filling date of the claimed invention to modify the network interface device, taught by Pong in view of Eriksson, to comprise a receive parser configured to extract a second header information and a second data from a second TCP packet received from a network, and transmit the second data to the host interface without being buffered or copied, as taught by Hendel. This would be convenient for reducing the amount of processing necessary to separate a packet payload from its headers and pass the payload to its destination (Hendel, Parag. [0008]).
Claim 17. Pong in view of Schlansker and Hendel discloses [t]he network interface device of claim 16,
Pong doesn’t explicitly disclose wherein when the first TCP packet is transmitted externally by the packet generator or the second data is transmitted externally by the host interface, neither the first data nor the second data is present within the network interface device.
However, Schlansker discloses wherein when the first TCP packet is transmitted externally by the packet generator or the second data is transmitted externally by the host interface, neither the first data nor the second data is present within the network interface device (See Col. 9 lines 44-52; The remote NIC 122 address and the message sequence number are loaded into the network interface 118 ... the transmission formatter 206 is configured for sending the contents of the retransmit buffer 114 to the network interface 118 which is further coupled to the network 120 (the second data is transmitted externally by the host interface, neither the first data nor the second data is present within the network interface device). See also Col. 4 lines 1-13 and Fig. 1).
It would be obvious to one of ordinary skill in the art at the time before the effective filling date of the claimed invention to modify Pong to include the second data is transmitted externally by the host interface, neither the first data nor the second data is present within the network interface device, as taught by Schlansker. This would be convenient in reducing application latency when communicating with the packet switched data network (Schlansker, See Col. 1 lines 6-9).
Claim 18. Pong in view of Schlansker and Hendel discloses [t]he network interface device of claim 16,
Pong in view of Schlansker doesn’t explicitly disclose wherein the network interface device does not comprise an internal buffer to buffer the first data or the second data until an Acknowledgement (ACK) processing corresponding to a transmission of the first data or the reception of the second data is completed.
However, Hendel discloses wherein the network interface device does not comprise an internal buffer to buffer the first data or the second data until an Acknowledgement (ACK) processing corresponding to a transmission of the first data or the reception of the second data is completed (See Parag. [0009]; facilitating the reassembly of packet payloads directly into host memory buffers from a communication interface … the payloads need not be buffered or temporarily stored in the communication interface and need not be handled by a host processor. See Parag. [0077]; In FIG. 4, receive translation window 404 slides along TCP sequence number space 402 as connection data are received and acknowledged. Host memory for receiving the TCP payloads includes buffers 410, 412, 414 and 416, which are included in the buffer list of the connection table associated with the illustrated connection).
It would be obvious to one of ordinary skill in the art at the time before the effective filling date of the claimed invention to modify the network interface device, taught by Pong in view of Schlansker, to not comprise an internal buffer to buffer the first data or the second data until an ACK processing corresponding to a transmission of the first data or the reception of the second data is completed, as taught by Hendel. This would be convenient for reducing the amount of processing necessary to separate a packet payload from its headers and pass the payload to its destination (Hendel, Parag. [0008]).
Conclusion
The prior art made of record and not relied upon is considered pertinent to applicant's disclosure.
Elnathan (Patent No. US 7,072,342) – Related art in the area of reordering out-of-order packets, (Abstract; Tasks are assigned to process packets, but the tasks may not process the packets in the order in which the packets were received. Thus, the order of the packets may be lost during processing. The packets, however, should still be transferred in the order in which the packets were received. Therefore, reordering is performed. In particular, the reordering is performed by having tasks write commands for packets into command buffers of a command queue based on a packet sequence number of a packet matching a current sequence number associated with the buffer and by reading commands for consecutive packets in order by passing from one command buffer to another command buffer. With the command buffers in the command queue being written and read in this manner, the packets are "reordered" so that they are transferred in the order in which they were received).
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 ABDELBASST TALIOUA whose telephone number is (571)272-4061. The examiner can normally be reached on Monday-Thursday 7:30 am - 5:30 pm.
Examiner interviews are available via telephone, in-person, and video conferencing using a USPTO supplied web-based collaboration tool. To schedule an interview, applicant is encouraged to use the USPTO Automated Interview Request (AIR) at http://www.uspto.gov/interviewpractice.
If attempts to reach the examiner by telephone are unsuccessful, the examiner’s supervisor, Oscar Louie can be reached on 571-270-1684. 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 https://ppair-my.uspto.gov/pair/PrivatePair. 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.
/Abdelbasst Talioua/Primary Examiner, Art Unit 2445
Prosecution Insights