DETAILED ACTION
Specification Objections
The disclosure is objected to because of the following informalities:
It is required that continuing data is consistent in 1st paragraph of specification and Bib data sheet and therefore, it is necessary to update Patent No. 12/010,195 in the specification. Appropriate correction is required.
Double Patenting
The nonstatutory double patenting rejection is based on a judicially created doctrine grounded in public policy (a policy reflected in the statute) so as to prevent the unjustified or improper timewise extension of the "right to exclude" granted by a patent and to prevent possible harassment by multiple assignees. See In re Goodman, 11 F.3d 1046, 29 USPQ2d 2010 (Fed. Cir. 1993); In re Longi, 759 F.2d 887, 225 USPQ 645 (Fed. Cir. 1985); In re Van Ornum, 686 F.2d 937, 214 USPQ 761 (CCPA 1982); In re Vogel, 422 F.2d 438, 164 USPQ 619 (CCPA 1970); and, In re Thorington, 418 F.2d 528, 163 USPQ 644 (CCPA 1969).
A timely filed terminal disclaimer in compliance with 37 CFR 1.321(c) may be used to overcome an actual or provisional rejection based on a nonstatutory double patenting ground provided the conflicting application or patent is shown to be commonly owned with this application. See 37 CFR 1.130(b).
Effective January 1, 1994, a registered attorney or agent of record may sign a terminal disclaimer. A terminal disclaimer signed by the assignee must fully comply with 37 CFR 3.73(b).
The USPTO internet Web site contains terminal disclaimer forms which may be used. Please visit http://www.uspto.gov/forms/. The filing date of the application will determine what form should be used. A web-based eTerminal Disclaimer may be filled out completely online using web-screens. An eTerminal Disclaimer that meets all requirements is auto-processed and approved immediately upon submission. For more information about eTerminal Disclaimers, refer to http://www.uspto.gov/patents/process/file/efs/guidance/eTD-info-I.jsp.
Claims 1-20 are rejected under the judicially created doctrine of obviousness-type double patenting as being unpatentable over claims 1-20 of U.S. Patent No. 11,496,599 (hereinafter ‘599) and claims 1-18 of U.S. Patent No. 12,010,195 (hereinafter ‘195). Although the conflicting claims are not identical, they are not patentably distinct from each other because despite slight difference in wording, for example, claim 1 of ‘599 and claim 1 of ‘195 recite essentially all claimed subject matter of claim 1 in the present application.
“A later patent claim is not patentably distinct from an earlier patent claim if the later claim is obvious over, or anticipated by, the earlier claim. In re Longi, 759 F.2d at 896, 225 USPQ at 651 (affirming a holding of obviousness-type double patenting because the claims at issue were obvious over claims in four prior art patents); In re Berg, 140 F.3d at 1437, 46 USPQ2d at 1233 (Fed. Cir. 1998) (affirming a holding of obviousness type double patenting where a patent application claim to a genus is anticipated by a 35 patent claim to a species within that genus). “ELI LILLY AND COMPANY v BARR LABORATORIES, INC., United States Court of Appeals for the Federal Circuit, ON PETITION FOR REHEARING EN BANC (DECIDED: May 30, 2001).
Accordingly, absent a terminal disclaimer, claims 1-20 are properly rejected under the doctrine of obviousness-type double patenting.” (In re Goodman (CA FC) 29 USPQ2d 2010 (12/3/1993).
Instant Application No.: 18/656,456
U.S. Patent No.:11/496,599
A method, comprising:
- determining, by an accelerator of a smart network interface card (smartNIC), that a cache entry is a candidate for removal, the accelerator being responsible for forwarding packets associated with a particular flow based at least in part on a flow state;
- generating, by the accelerator, an instruction to remove a cache entry of the particular flow from a cache based at least in part on receiving the determination that the cache entry is the candidate for removal;
- removing, by the accelerator, the cache entry of the particular flow from the cache based at least in part on the instruction;
- generating, by the accelerator, a control packet that includes a flow information associated with the particular flow being formatted utilizing a particular header format; and transmitting, by the accelerator, the control packet to a programming data plane utilizing a path based at least in part on the control packet utilizing the particular header format.
A computer-implemented method, comprising:
- determining, by an accelerator of a smart network interface card (smartNIC), that a cache entry of a cache that is managed by the accelerator is a candidate for removal, the cache entry storing flow state of a particular flow, the accelerator being responsible for forwarding packets associated with the particular flow based at least in part on the flow state, and the cache entry being indexed within the cache based at least in part on a hash that is generated based at least in part on flow information associated with the particular flow, the flow information formatted utilizing a particular header format;
- generating, by the accelerator, a control packet that includes the flow information associated with the particular flow being formatted utilizing the particular header format; including, by the accelerator within the control packet, an instruction that requests a programming data plane of the smart network interface card to provide a second instruction that directs the accelerator to remove the cache entry of the particular flow from the cache; transmitting, by the accelerator, the control packet to the programming data plane utilizing a path that is also used by the accelerator to forward non-control packets to the programming data plane, the path being utilized based at least in part on the control packet utilizing the particular header format; generating, by the programming data plane, the second instruction based at least in part on receiving the control packet from the accelerator; transmitting, by the programming data plane, the second instruction to the accelerator; and removing, by the accelerator, the cache entry of the particular flow from the cache based at least in part on the second instruction.
Instant Application No.: 18/656,456
U.S. Patent No.:12/010,195
A method, comprising:
- determining, by an accelerator of a smart network interface card (smartNIC), that a cache entry is a candidate for removal, the accelerator being responsible for forwarding packets associated with a particular flow based at least in part on a flow state;
- generating, by the accelerator, an instruction to remove a cache entry of the particular flow from a cache based at least in part on receiving the determination that the cache entry is the candidate for removal;
- removing, by the accelerator, the cache entry of the particular flow from the cache based at least in part on the instruction;
- generating, by the accelerator, a control packet that includes a flow information associated with the particular flow being formatted utilizing a particular header format; and transmitting, by the accelerator, the control packet to a programming data plane utilizing a path based at least in part on the control packet utilizing the particular header format.
A method, comprising:
determining, by an accelerator of a smart network interface card (smartNIC), that a cache entry is a candidate for removal, the cache entry being part of a cache that is managed by the accelerator, the cache entry storing flow state of a particular flow, the accelerator being responsible for forwarding packets associated with the particular flow based at least in part on the flow state, and the cache entry being indexed within the cache based at least in part on a hash that is generated based at least in part on flow information associated with the particular flow, and the flow information formatted utilizing a particular header format; generating, by the accelerator, an instruction to remove the cache entry of the particular flow from the cache based at least in part on receiving the determination that the cache entry is the candidate for removal; removing, by the accelerator, the cache entry of the particular flow from the cache based at least in part on the instruction; generating, by the accelerator, a control packet that includes the flow information associated with the particular flow being formatted utilizing the particular header format; and transmitting, by the accelerator, the control packet to a programming data plane utilizing a path that is used by the accelerator to forward non-control packets to the programming data plane, the path being utilized based at least in part on the control packet utilizing the particular header format.
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 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.
Claims 1-20 are rejected under 35 U.S.C. 103 as being unpatentable over Raindel et al. (US 2016/0330112, “Raindel”) in view of Deval et al. (US 2020/0314011, “Deval”) and further in view of Kamisetty et al. (US 2022/0166718, “Kamisetty”).
Regarding claim 1, Raindel discloses a method, comprising:
- determining, by an accelerator of a smart network interface card (smartNIC) (See 32 & 40 Fig.1 NIC with acceleration; Examiner’s Note: Deval discloses the limitation “smart NIC”), that a cache entry is a candidate for removal (See ¶.34, the accelerator logic updates the table as required; Examiner’s Note: Deval discloses the limitation “removing of a cache entry”), the accelerator being responsible for forwarding packets associated with the particular flow based at least in part on the flow state (See Fig.5 and ¶.63, If flag is not already set, control logic sends a special packet via interface to NIC, containing the flow state data, at a flow state forwarding step 126; See 132 Fig.5, ‘forward the original packet to NIC’);
- generating, by the accelerator, an instruction to remove a cache entry of the particular flow from a cache based at least in part on receiving the determination that the cache entry is the candidate for removal (See ¶.10, the acceleration logic is configured to store the entries in the flow state table in response to table update instructions conveyed by the host processor to the acceleration logic via the first packet communication interface; See ¶.36, send a request to update the state information in the flow state table, thus enabling the accelerator to resume its hardware-based processing of the packets in the flow at a point indicated by the host processor; See ¶.54, NIC tags the management packets that are used for table updates according to the originating user or process; Examiner’s Note: Deval discloses the limitation “removing of a cache entry”).
Raindel does not explicitly disclose what Deval discloses,
- smart NIC (Deval, See ¶.2-3, smartNIC ) and
- removing, by the accelerator, the cache entry of the particular flow from the cache based at least in part on the instruction (Deval, See ¶.42, a hash-table is a commonly used search algorithm in packet processing hardware accelerators; See ¶.40, cache is updated; See 308 Fig.3 and ¶.41, FIG. 3 shows a flowchart illustrating operations and logic for removing a match-action entry, according to one embodiment. As shown in a block 302, software runs a thread to remove match-action entries from host memory (e.g., match-action entries in host memory match actions tables). In a decision block 304 a determine is made to whether the entry is aged out. For example, in one embodiment aged-out entries are marked when they are aged out but are not immediately removed from host memory match actions tables. If the answer to decision block 304 is YES, the entry is removed in an end block 306. If the entry has not been aged out, then there is a possibility that the entry is cached in the EM cache. Accordingly, in a block 308 a hint is sent to the EM cache to flush (evict or remove) the entry. The entry is removed from host memory match actions tables in an end block 310. Generally, the operations in block 308 and 310 may be performed in parallel or have their order reversed, with the net result being removal of a match-action entry from host memory match actions tables and the EM cache (when the entry is cached in the EM cache; See claim 19, in response to finding a match-action entry in a match-action table, the software instructions are configured, upon execution by a processor core, to forward information to the network interface associated with the matching match-action entry, and wherein the circuitry in the network interface is further configured to insert a new match-action entry in the EM cache corresponding to the matching match-action entry).
Therefore, it would have been obvious to one of ordinary skill in the art before the effective filing date to apply “the smart NIC and the method of removing, by the accelerator, the cache entry of the particular flow from the cache based at least in part on the instruction” as taught by Deval into the system of Raindel, so that it provides a way of reducing memory used or allocated for use by hash memories or tables (Deval, See ¶.68).”
Raindel further discloses,
- generating, by the accelerator, a control packet that includes a flow information associated with the particular flow (Raindel, See ¶.56, the tagging of packets in connection with functions of accelerator can be implemented in various ways. One way to do the tagging is using an extra layer-2 header, such as multiple VLAN tags, a CN-Tag, as defined in IEEE specification 802.1Qau, or another, similar Ethertype type-length-value (TLV) structure. Another possible way to do the tagging is to push a MPLS header onto the packet, with the accelerator extracting the MPLS header and using it to identify what processing is needed. It is also possible to use layer-3 and layer-4 tagging and/or encapsulation for this purpose, such as GRE/NVGRE/VXLAN encapsulation, modifying the IPv6 flow-ID field, adding an IP header option field, or adding a TCP header option field. Depending on the format of the tagging, accelerator can either strip the tag from the packet or leave it as non-harmful tag that does not affect packet processing further along the path in network; See Fig.3, flow identifier, expected sequence number for encryption state; See ¶.47, parameters may include the last block that was processed, as well as the hash state for purposes of the message authentication code (MAC). Additionally, parameters may contain the index used in CCM mode (counter with CBC-MAC)) being formatted utilizing a particular header format (See ¶.56, modifying the IPv6 flow-ID field, adding an IP header option field, or adding a TCP header option field. Depending on the format of the tagging, accelerator can either strip the tag from the packet or leave it as non-harmful tag that does not affect packet processing further along the path in network; See ¶.61, control logic may tag forwarded packets in an “inverse” manner, such that only packets that are forwarded in their original format are marked, while decrypted and verified packets are not tagged. In either case, control logic can mark the packets by setting a certain field in the Ethernet or IP header); and
- transmitting, by the accelerator, the control packet to a programming data plane utilizing a path based at least in part on the control packet utilizing the particular header format (Raindel, See Fig.4,
PNG
media_image1.png
391
523
media_image1.png
Greyscale
See ¶.55, a mechanism of tagging packets by NIC 32 to facilitate different sorts of processing by accelerator can be useful for other operations, as well. This tagging can relay to the accelerator information that it does not have, such as identifying the software entity from which the packet originated. The tagging can also provide information about partial processing done by the NIC, such as doing a lookup of the 5-tuple in a NIC-based table. Additionally the tagging can be generated by software running on CPU, allowing the software to specify different processing for different packets sent; See ¶.58, the control logic forwards the original packet to NIC via interface, at a packet forwarding step 106. NIC passes the packet to CPU, which handles the packet in accordance with its normal software processing flow; See ¶.60, control logic will forward the new state to CPU 28 upon reception of the next out-of-order packet.) Finally control logic forwards the decrypted and/or verified packet contents to NIC, at a payload forwarding step 118; See ¶.61, control logic may tag forwarded packets in an “inverse” manner, such that only packets that are forwarded in their original format are marked, while decrypted and verified packets are not tagged. In either case, control logic can mark the packets by setting a certain field in the Ethernet or IP header; See Fig.5, ¶.62-64 for forwarding the packet; See Fig.6 and ¶.66-72 for forwarding the encrypted packets in the flow; Examiner’s Note: Kamisetty discloses the limitations “a programming data plane”).
Raindel discloses the method of transmitting the control packet to host computers via NIC interface in order to deal with data (See Fig.4), but does not explicitly disclose the limitations “a programming data plane.”
However, Kamisetty discloses “a programming data plane” (Kamisetty, See ¶.4, in certain embodiments, are systems employing a programmable input/output (IO) device (e.g., a smartNIC) to provide a programmable data plane that stores received packets in a ring buffer as the associated flow is installed in the routing table(s)).
Therefore, it would have been obvious to one of ordinary skill in the art before the effective filing date to apply the method of transmitting to “a programming data plane” as taught by Kamisetty into the system of Raindel and Deval, so that it provides a way of employing a smartNIC to provide a programmable data plane that stores received packets in a buffer as the associated flow is installed in the routing tables (Kamisetty, See ¶.4).
Regarding claim 2, Raindel does not explicitly disclose what Deval discloses “determining that a timer associated with the particular flow has expired, wherein the accelerator determines that the cache entry for the particular flow is the candidate for removal based at least in part on determining that a timer associated with the particular flow has expired (Deval, See ¶.40, if there was a flow entry expiration or addition, the host memory match-action tables are updated).” Therefore, this claim is rejected with the similar reasons and motivation set forth in the rejection of claim 1.
Regarding claim 3, Raindel and Deval disclose “receiving a data packet associated with the particular flow (Raindel, See 100 Fig.5 and 100 Fig.7, receiving packet); determining that the data packet indicates a termination or a reset of the particular flow, wherein the accelerator determines that the cache entry for the particular flow is the candidate for removal based at least in part on determining that the data packet indicates a termination or a reset of the particular flow (Deval, See ¶.40, a flow entry expiration; See Fig.3 and ¶.38, remove entry).” Therefore, this claim is rejected with the similar reasons and motivation set forth in the rejection of claim 1.
Regarding claim 4, Raindel and Deval disclose “receiving a data packet, wherein the data packet comprises the particular header format and the flow information associated with the particular flow, processing from the data packet a source Internet Protocol (IP) address, a destination Internet Protocol (IP) address, a source port, a destination port, or a protocol type (Raindel, See Fig.3 and ¶.45, for TCP/IP flows, flow identifier may comprise the packet 5-tuple (source and destination IP addresses and ports, along with the transport protocol) that identifies the TCP connection); generating, using a hash function, a hash associated with the data packet (Deval, See Fig.4 and ¶.44, hash function); and generating the cache entry for the cache, wherein the cache entry is indexed in the cache based at least in part on the hash (Deval, See Fig.5a-b and ¶.53-54, hash indexed), and wherein the cache entry comprises the flow information associated with the particular flow (Deval, See ¶.40, flow entry in the cache is updated). Therefore, this claim is rejected with the similar reasons and motivation set forth in the rejection of claim 1.
Regarding claim 5, Raindel does not explicitly disclose what Deval discloses “determining a number of cache entries stored in cache exceed a threshold storage capacity, wherein each cache entry is associated with the particular flow, and wherein the accelerator determines that the cache entry for the particular flow is the candidate for removal based at least in part on determining that the number of cache entries stored in cache exceed the threshold storage capacity (See ¶.39 for exceeding a threshold; See Fig.5a-b and the related paragraphs for hash index associated with a flow; See ¶.38-39 for removing method).” Therefore, this claim is rejected with the similar reasons and motivation set forth in the rejection of claim 1.
Regarding claim 6, Raindel and Deval do not explicitly disclose what Kamisetty discloses “wherein the path is used by the accelerator to forward non-control packets to a programming data plane (as rejected in claim 1 disclosed by Kamisetty), and wherein the path corresponds to a network on a chip (NOC) that is configured to route packets that utilize the particular header format between the accelerator and the programming data plane (Kamisetty, See ¶.4, systems employing a programmable input/output (IO) device/subsystem (e.g., a smartNIC) to provide a programmable data plane that stores received packets in a ring buffer as the associated flow is installed in the routing table(s). In some embodiments, once the data flow is installed, packets are released in the correct order. In some embodiments, packets reinjected into the data flow from the ring buffer include an extra bit, a packet descriptor, to flag, for example, the first packet and last packet in buffer; See NoC based on IP).” Therefore, this claim is rejected with the similar reasons and motivation set forth in the rejection of claim 1.
Regarding claim 7, Raindel discloses “wherein the flow information is formatted using a particular header format comprising a five-tuple Internet Protocol (IP) format, and wherein data fields of the five-tuple IP format correspond to the flow information that is associated with the particular flow (See Fig.3 and ¶.45, for TCP/IP flows, flow identifier may comprise the packet 5-tuple (source and destination IP addresses and ports, along with the transport protocol) that identifies the TCP connection. Entries are originally posted in table by CPU upon initiation of the corresponding flow, and then are updated by control logic as packets in the flow are received and processed).”
Regarding claim 8, it is an accelerator claim corresponding to the method claim 1, except the limitation “a memory and a processor (See Fig.1, CPU and memory)” and is therefore rejected for the similar reasons set forth in the rejection of the claim.
Regarding claims 9-14, they are claims corresponding to claims 2-7, respectively and are therefore rejected for the similar reasons set forth in the rejection of the claims.
Regarding claim 15, it is a non-transitory computer readable media claim corresponding to the method claim 1 and is therefore rejected for the similar reasons set forth in the rejection of the claim.
Regarding claims 16-20, they are claims corresponding to claims 2-6, respectively and are therefore rejected for the similar reasons set forth in the rejection of the claims.
Contact Information
Any inquiry concerning this communication or earlier communications from the examiner should be directed to Jung Park whose telephone number is 571-272-8565. The examiner can normally be reached on Mon-Fri during 7:00-3:00.
If attempts to reach the examiner by telephone are unsuccessful, the examiner’s supervisor, Derrick Ferris can be reached on 571-272-3123. 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).
/JUNG H PARK/Primary Examiner, Art Unit 2411
Prosecution Insights