DETAILED ACTION
It is hereby acknowledged that the following papers have been received and placed of record in the file: Amendment date 09/15/2025.
Claims 1-20 are presented for examination.
Note: Double Patenting Rejection be held abeyance until the claims are in condition for allowance.
Response to Arguments
Applicant's arguments with respect to claims 1-20 have been considered but are moot in view of the new ground(s) of rejection.
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. A nonstatutory double patenting rejection is appropriate where the claims at issue are not identical, but at least one examined application claim is not patentably distinct from the reference claim(s) because the examined application claim is either anticipated by, or would have been obvious over, the reference claim(s). See, e.g., In re Berg, 140 F.3d 1428, 46 USPQ2d 1226 (Fed. Cir. 1998); 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) or 1.321(d) may be used to overcome an actual or provisional rejection based on a nonstatutory double patenting ground provided the reference application or patent either is shown to be commonly owned with this application, or claims an invention made as a result of activities undertaken within the scope of a joint research agreement. See MPEP § 717.02 for applications subject to examination under the first inventor to file provisions of the AIA as explained in MPEP § 2159. See MPEP §§ 706.02(l)(1) - 706.02(l)(3) for applications not subject to examination under the first inventor to file provisions of the AIA . A terminal disclaimer must be signed in compliance with 37 CFR 1.321(b).
The filing of a terminal disclaimer by itself is not a complete reply to a nonstatutory double patenting (NSDP) rejection. A complete reply requires that the terminal disclaimer be accompanied by a reply requesting reconsideration of the prior Office action. Even where the NSDP rejection is provisional the reply must be complete. See MPEP § 804, subsection I.B.1. For a reply to a non-final Office action, see 37 CFR 1.111(a). For a reply to final Office action, see 37 CFR 1.113(c). A request for reconsideration while not provided for in 37 CFR 1.113(c) may be filed after final for consideration. See MPEP §§ 706.07(e) and 714.13.
The USPTO Internet website contains terminal disclaimer forms which may be used. Please visit www.uspto.gov/patent/patents-forms. The actual filing date of the application in which the form is filed determines what form (e.g., PTO/SB/25, PTO/SB/26, PTO/AIA /25, or PTO/AIA /26) 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 www.uspto.gov/patents/apply/applying-online/eterminal-disclaimer.
Claims 1, 8 and 15 rejected on the ground of nonstatutory double patenting as being unpatentable over claims 1, 7 and 17 of U.S. Patent No. 12,015,562 (562’ hereinafter). Although the claims at issue are not identical, they are not patentably distinct from each other because the instant application and U.S Patent are claiming common subject matter, as follows:
Instant Application US Application #: 18/656436 (436’)
U.S. Patent #: 12,015,562 (562’)
1. A computer-implemented method, comprising:
1. A computer-implemented method, comprising:
receiving, by an accelerator of a smart network interface card, a packet from a first port of the smart network interface card,
the first port being associated with a first data path and a second data path; determining, by the accelerator, that the packet was received from the first port via the second data path instead of the first data path,
wherein a programming data plane of the smart network interface card determines a particular flow associated with the packet based at least in part on determining that the packet was transmitted to the smart network interface card from a first host computer via the second data path;
modifying, by the accelerator, the packet by inserting a header to indicate that the packet arrived from the first port via the second data path;
inserting, by the accelerator, the modified packet into a queue;
determining, by the programming data plane, whether the modified packet arrived at the first port via the second path based at least in part on the header, the header inserted after receiving the packet from the first port; and
receiving, by the programming data plane, the modified packet from the queue; and
receiving, by an accelerator of a smart network interface card (smartNIC), a packet from a first port of a plurality of ports of the smart network interface card,
the first port being connected to a splitter device that splits a first data path into a second data path and a third data path that are both associated with the first port, and the packet arriving at the first port via the second data path;
determining, by the accelerator, that the packet was received at the first port via the second data path instead of the third data path,
wherein a programming data plane of the smart network interface card determines a particular flow associated with the packet based at least in part on determining that the packet was transmitted to the smart network interface card from a first host computer via the second data path;
modifying, by the accelerator, the packet to indicate that the packet arrived at the first port via the second data path;
inserting, by the accelerator, the modified packet into a queue of the smart network interface card, the queue being associated with both the second data path and the third data path that are associated with the first port, and the queue interfacing between the accelerator and the programming data plane of the smart network interface card;
receiving, by the programming data plane, the modified packet from the queue; and
processing, by the programming data plane, the modified packet based at least in part on determining that the packet arrived at the first port via the second data path.
processing, by the programming data plane, the modified packet based at least in part on determining that the packet arrived at the first port of the plurality of ports via the second data path.
Although the conflict claims are not identical, they are not patentably distinct from each other because 436’ discloses the computer-implemented method, comprising:,
· receiving, by an accelerator of a smart network interface card, a packet from a first port of the smart network interface card,
· inserting, by the accelerator, the modified packet into a queue;
· receiving, by the programming data plane, the modified packet from the queue;
436’ does not discloses the phrase “a plurality of ports”, “determining, by the accelerator, that the packet was received at the first port via the second data path instead of the third data path” and “the queue being associated with both the second data path and the third data path that are associated with the first port, and the queue interfacing between the accelerator and the programming data plane of the smart network interface card” in the instant application. However, it would have been obvious to one or ordinary skill in the art to determined network interface card have first port and second port that corresponding to plurality of port of NIC; 436’ further disclose in claim 3 first port is associated with a third data path corresponding to determine whether the packet was received at the first port via the second data path; 436 further disclose in the modified packet into a queue, where the queuing packets are coming from all the data path (even though doesn’t specify which paths) that performing the same functions (determining, modifying, inserting, receiving and processing) as the instant application. Therefore, they are not patentably distinct from each other.
Regarding claims 8 and 15 are rejected for the same reasons as claim 1 described above corresponding to U.S. Patented claims 7 and 11. Therefore, this is Non-Provisional nonstatutory obviousness-type double patenting rejection because the conflicting claims in the reference U.S. Patent.
Claim Rejections - 35 USC § 103
The following is a quotation of 35 U.S.C. 103 which forms the basis for all obviousness rejections set forth in this Office action:
A patent for a claimed invention may not be obtained, notwithstanding that the claimed invention is not identically disclosed as set forth in section 102, if the differences between the claimed invention and the prior art are such that the claimed invention as a whole would have been obvious before the effective filing date of the claimed invention to a person having ordinary skill in the art to which the claimed invention pertains. Patentability shall not be negated by the manner in which the invention was made.
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(a) 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.
Claims 1-5, 8-12 and 15-19 is/are rejected under 35 U.S.C. 103 as being unpatentable over Caulfield et al. (US 2016/0380896 A1) in view of Matthews et al. (US 10,742,558 B1).
Regarding claim 1, Caulfield teaches a computer-implemented method, comprising:
receiving, by an accelerator of a smart network interface card, a packet from a first port of the smart network interface card, the first port being associated with a first data path and a second data path (receiving, by the Smart NIC 104, packets from first port (host-side) 170, where the first port have being associated with different path, Path to local Rx/tx port 174 or network side port 172 see Caulfield: Fig.4; ¶0031]; Fig.3 include switch 156);
determining, by the accelerator, that the packet was received from the first port via the second data path instead of the first data path (switch 156 determine the packet from first port into packet classifiers into different packet class (corresponding to data paths) and into packet buffer “the switch 156 has two packet buffers; one for the receiving (Rx) first port 170 and one for the receiving second port 172. The packet buffers are split into several region” see Caulfield: ¶[0030]; Fig.4), wherein a programming data plane of the smart network interface card determines a particular flow associated with the packet based at least in part on determining that the packet was transmitted to the smart network interface card from a first host computer via the second data path (switch able to configured the pass packets received on the local port for example only first port or second port “the switch 156 may be configured to pass packets received on the local port 174 (e.g., LTP packets) only to the second port 172 (not the first port 170” see Caulfield: ¶[0029-0030]);
modifying, by the accelerator, the packet to indicate that the packet arrived from the first port via the second data path (Priority flow control insert to modified the packet “A PFC insertion block allows the switch 156 to insert PFC frames between flow packets at the transmit half of either of the ports 170, 172” see Caulfield: ¶[0030-0031]);
inserting, by the accelerator, the modified packet into a queue (insert receiving packet into packet buffer to control the traffic see Caulfield: ¶[0030-0031]; Fig.4 packet buffers);
receiving, by the programming data plane, the modified packet from the queue (receiving packet from packet buffers at the arbiter “Once a packet is stored and ready to transmit, an arbiter selects from among the available packets and transmits the packet (the packet may be framed by the switch 156 or another element of the smart NIC)” see Caulfield: ¶[0030]; Fig.4); and
processing, by the programming data plane, the modified packet based at least in part on the determination that the packet arrived at the first port via the second data path (arbiter selects from among packets and transmit the packet to network side port 172 see Caulfield: Fig.4; ¶0030-0031]).
Caulfield does not explicitly teaches modifying, by the accelerators, by inserting a header and determining, by the programming data plane, whether the modified packet arrived at the first port via the second path based at least in part on the header, the header inserted after receiving the packet from the first port.
However, Matthews teaches the modifying, by the accelerators, by inserting a header (control information 473 received packet and additive with respect to the information such as (path information and next internal destination component “The control information 473 may simply include information already in the data unit (e.g. addressing information, priority data, or labels in the header of the data unit 110), may replace such information in the data unit (e.g. a new destination address or a revised priority level), or may be additive with respect to the information in the header (e.g. internal markings, path information, tracking information, a next internal destination component to process the data unit, editing instructions, other handling instructions, etc.)” see Matthews: Fig.4; Col.19 lines 28-42) and determining, by the programming data plane, whether the modified packet arrived at the first port via the second path based at least in part on the header, the header inserted after receiving the packet from the first port (additive header information “The control information 473 may simply include information already in the data unit (e.g. addressing information, priority data, or labels in the header of the data unit 110), may replace such information in the data unit (e.g. a new destination address or a revised priority level), or may be additive with respect to the information in the header (e.g. internal markings, path information, tracking information, a next internal destination component to process the data unit, editing instructions, other handling instructions, etc.)” see Matthews: Fig.4; Col.19 lines 28-42) in order to expediently send and store that data to the appropriate destination once determined (see Matthews: Col.2 lines 38-45).
It would have been obvious to one of ordinary skill in the art before the effective filling date of the claimed invention to create the invention of Caulfield to include (or to use, etc.) the modifying, by the accelerators, by inserting a header and determining, by the programming data plane, whether the modified packet arrived at the first port via the second path based at least in part on the header, the header inserted after receiving the packet from the first port as taught by Matthews in order to expediently send and store that data to the appropriate destination once determined (see Matthews: Col.2 lines 38-45).
Regarding claim 2, the modified Caulfield taught the computer-implemented method of claim 1 as described hereinabove. Caulfield further teaches wherein the header corresponds to a bit-string indicating the second data path (header field identify traffic class of packet “field in a packet header can be used to identify which traffic class the packet belongs to” see Caulfield: ¶[0028]).
Regarding claim 3, the modified Caulfield taught the computer-implemented method of claim 1 as described hereinabove. Caulfield further teaches wherein the first port is associated with a third data path, and wherein the first port is connected to a splitter device that splits the third data path into the first data path and the second data path (switch 156 maybe be configured to pass the packet into different class of packet (example: lossless, lossy) and transmit the data see Caulfield: ¶[0030]; Fig.4).
Regarding claim 4, the modified Caulfield taught the computer-implemented method of claim 3 as described hereinabove. Caulfield further teaches wherein the first data path is associated with a first physical medium that connects the splitter device to the first host computer, and wherein the second data path is associated with a second physical medium that connects the splitter device to a second host computer (MAC 150 connect to host and MAC 152 connect to network see Caulfield: ¶[0024]; Fig.3).
Regarding claim 5, the modified Caulfield taught the computer-implemented method of claim 1 as described hereinabove. Caulfield further teaches wherein processing the modified packet further comprises: identifying, by the programming data plane, a bit-string within the modified packet that indicates that the packet arrived at the first port via the second data path; and determining, by the programming data plane, a particular customer account identifier based at least in part on the bit-string (received packet into data buffer with index and also identify destination IP address and sequence number “The LTP module 130 may include one or more data buffers 190 to buffer payload, a transmit buffer 192, a connection table 194, connection management logic 196, and data transmission logic 198” see ¶[0036-0037]; Fig.5 elements 190, 194).
Regarding claims 8-12, they are rejected for the same reason as claims 1-5 as described set forth hereinabove. Regarding claims 8-12, they discloses a smart network interface card that comprising the same functionalities as method of claims 1-5 as described hereinabove.
Regarding claims 15-19, they are rejected for the same reason as claims 1-5 as described set forth hereinabove. Regarding claims 15-19, they discloses one or more non-transitory computer media cause a smart network interface card that comprising the same functionalities as method of claims 1-5 as described hereinabove.
Claims 6-7, 13-14 and 20 is/are rejected under 35 U.S.C. 103 as being unpatentable over Caulfield et al. (US 2016/0380896 A1) in view of Matthews et al. (US 10,742,558 B1) and further in view of Peri (US 20230300075 A1).
Regarding claim 6, the modified Caulfield taught the computer-implemented method of claim 5 as described hereinabove. The modified Caulfield does not explicitly teaches identifying, by the programming data plane, a tuple within the modified packet that is associated with a particular flow; and generating, by the programming data plane, a hash based at least in part on at least one of: a virtual local area network tag, the bit-string, or the tuple.
However, Peri teaches the identifying, by the programming data plane, a tuple within the modified packet that is associated with a particular flow; and generating, by the programming data plane, a hash based at least in part on at least one of: a virtual local area network tag, the bit-string, or the tuple (hash generate based on at least one of flow identifier or quality of the sub flows, wherein the hash based on bit stream “the first configuration determination circuitry 206 can determine a format of a sub flow identifier based on the configuration. For example, the first configuration determination circuitry 206 can determine the format to be a bit stream, a bit concatenation, a hash (e.g., a hash generated by executing a computer hash algorithm) of a concatenation of at least one of a flow identifier or a parallel window identifier, etc., based on at least one of a flow identifier of the data flow or a quantity of the sub flows” see Peri: ¶[0053]) in order to reduce latency, congestion and power consumption of the network (see Peri: ¶[0003]).
It would have been obvious to one of ordinary skill in the art before the effective filling date of the claimed invention to create the invention of the modified Caulfield to include (or to use, etc.) the identifying, by the programming data plane, a tuple within the modified packet that is associated with a particular flow; and generating, by the programming data plane, a hash based at least in part on at least one of: a virtual local area network tag, the bit-string, or the tuple as taught by Peri in order to reduce latency, congestion and power consumption of the network (see Peri: ¶[0003]).
Regarding claim 7, the modified Caulfield taught the computer-implemented method of claim 6 as described hereinabove. Peri further teaches wherein the hash is associated with a cache entry of a cache maintained by the smart network interface card, the cache entry storing data associated with the particular flow, and wherein the smart network interface card determines to process the packet based at least in part on the data within the cache entry (hash generate based on at least one of flow identifier or quality of the sub flows, wherein the hash based on bit stream and flow identifier and cache management “the first configuration determination circuitry 206 can determine a format of a sub flow identifier based on the configuration. For example, the first configuration determination circuitry 206 can determine the format to be a bit stream, a bit concatenation, a hash (e.g., a hash generated by executing a computer hash algorithm) of a concatenation of at least one of a flow identifier or a parallel window identifier, etc., based on at least one of a flow identifier of the data flow or a quantity of the sub flows” see Peri: ¶[0053]; ¶[0171]) in order to reduce latency, congestion and power consumption of the network (see Peri: ¶[0003]).
Regarding claims 13-14, they are rejected for the same reason as claims 6-7 as described set forth hereinabove.
Regarding claim 20, claim 20 is rejected for the same reason as claims 6 as described set forth hereinabove.
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 nonprovisional extension fee (37 CFR 1.17(a)) 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 mailing date of this final action.
Any inquiry concerning this communication or earlier communications from the examiner should be directed to GUANG W LI whose telephone number is (571)270-1897. The examiner can normally be reached Monday - Thursday 7AM-5PMET.
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, Joseph Avellino can be reached at (571) 272-3905. The fax phone number for the organization where this application or proceeding is assigned is 571-273-8300.
Information regarding the status of published or unpublished applications may be obtained from Patent Center. Unpublished application information in Patent Center is available to registered users. To file and manage patent submissions in Patent Center, visit: https://patentcenter.uspto.gov. Visit https://www.uspto.gov/patents/apply/patent-center for more information about Patent Center and https://www.uspto.gov/patents/docx for information about filing in DOCX format. For additional questions, contact the Electronic Business Center (EBC) at 866-217-9197 (toll-free). If you would like assistance from a USPTO Customer Service Representative, call 800-786-9199 (IN USA OR CANADA) or 571-272-1000.
GUANG W. LI
Primary Examiner
Art Unit 2478
December 26, 2025
/GUANG W LI/Primary Examiner, Art Unit 2478