DETAILED ACTION
This action is in response to communication filed on 3/10/2026.
Claims 1-14 and 21-26 are pending.
Claims 21-26 have been added.
Claims 15-20 have been cancelled.
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 .
Response to Arguments
Applicant’s election of Invention I without traverse is acknowledged.
Claim Rejections - 35 USC § 102
In the event the determination of the status of the application as subject to AIA 35 U.S.C. 102 and 103 (or as subject to pre-AIA 35 U.S.C. 102 and 103) is incorrect, any correction of the statutory basis (i.e., changing from AIA to pre-AIA ) for the rejection will not be considered a new ground of rejection if the prior art relied upon, and the rationale supporting the rejection, would be the same under either status.
The following is a quotation of the appropriate paragraphs of 35 U.S.C. 102 that form the basis for the rejections under this section made in this Office action:
A person shall be entitled to a patent unless –
(a)(1) the claimed invention was patented, described in a printed publication, or in public use, on sale, or otherwise available to the public before the effective filing date of the claimed invention.
Claims 1-6, 21, and 24 rejected under 35 U.S.C. 102(a)(1) as being anticipated by Viswanath et al. (US 6,798,788).
Regarding claim 1, Viswanath discloses a network device comprising: memory circuitry; and packet processing circuitry coupled to the memory circuitry and configured to:
maintain a flow cache on the memory circuitry that contains a flow cache entry associated with a network flow (Viswanath discloses the policy cache (stored in memory) that holds completed flow entries (L3 + L4 information) for a network flow, each entry associated with a policy identifier for the flow; col. 7/lines 35-65; detx 17; “The policy cache 84, which stores for each entry an IP source address, IP destination address, TCP/UDP input port, TCP/UDP output port, and corresponding policy identifier, is used by the policy filter 80 to check if any non fragmented packets have been classified earlier with respect to the corresponding policy identifier; if so, the policy filter 80 can reuse the previous search results stored in the policy cache 84”); and
maintain a fragment mapping table on the memory circuitry that contains a fragment mapping table entry that maps network layer header information of a packet fragment to the flow cache entry (Viswanath discloses the internal table (fragment mapping table) that stores network-layer header information from a fragment (IP source address, IP destination address, and IP identifier) and maps it directly to the policy identifier that was obtained from (and points back to) the policy cache/flow-cache entry for that same flow; col. 7/lines 65 – col. 8/lines13; detx 18 “The flow identification module 82 stores the IP source address, IP destination address, the IP identifier 64, and the corresponding policy identifier (tag) into an internal table 86 at the same time that the data is written into the policy cache 84. The flow identification module 82 uses the combination of the IP source address and the IP identifier to uniquely identify each of the data fragments 72 as belonging to the same IP datagram 70 for a given layer 4 data flow. Hence, the flow identification module 82 can select the policy identifier for each of the subsequent layer 3 frame fragments 72b and 72c based on a match between the IP source address and IP identifier stored in the table 86 and the IP source address 60 and the IP identifier 64 in each of the layer 3 frame fragments 72b and 72c”).
Regarding claim 2, Viswanath discloses the network device defined in claim 1, wherein the flow cache entry includes transport layer header information and at least some of the network layer header information and wherein the transport layer header information and the at least some of the network layer header information define the network flow (Viswanath col. 5/lines 20-40; detx 6; “These policies are implemented by loading into the switch fabric 25 a set of layer 3 switching decisions for each corresponding layer 3 switching entry; in other words, each layer 3 switching entry has a corresponding unique set of layer 3 and possiblye layer 4 address values, for example specific values for a IP source address, an IP destination address, a transmission control protocol (TCP) source port, a TCP destination port, a user datagram protocol (UDP) source port, and/or a UDP destination port”).
Regarding claim 3, Viswanath discloses the network device defined in claim 2, wherein the fragment mapping table entry includes the network layer header information and an identifier for the flow cache entry (Viswanath col. 7/lines 65 – col. 8/lines 12; detx 18; “The flow identification module 82 stores the IP source address, IP destination address, the IP identifier 64, and the corresponding policy identifier (tag) into an internal table 86 at the same time that the data is written into the policy cache 84”).
Regarding claim 4, Viswanath discloses the network device defined in claim 1, wherein the packet processing circuitry is configured to receive a leading fragment of multiple packet fragments split from an original packet and is configured to provide the fragment mapping table entry by processing the leading fragment (Viswanath col. 8/lines 37-45; detx 21; “If in step 102 the flow module 44 determines that the flow is fragmented, if the fragment is the first fragment in step 112, the policy filter 80 performs the same operation in steps 106, 108, and 110, and outputs the template tag to the switch fabric in step 120. However in this case, the flow identification module 82 monitors the output bus of the policy filter 80, and stores into the table 86 the IP source address, IP destination address (optional), the IP identifier, and the corresponding policy tag of the first IP fragment in step 114”).
Regarding claim 5, Viswanath discloses the network device defined in claim 4, wherein the packet processing circuitry is configured to receive a non-leading fragment of the multiple packet fragments split from the original packet and is configured to look up network layer header field values of the non-leading fragment in the fragment mapping table to identify the fragment mapping table entry (Viswanath col. 8/lines 45-51; detx 22; “If in step 112 the fragment is not the first fragment, the flow identification module 82 performs a lookup in the table 86, using the IP source address and IP identifier of the corresponding received frame fragment. The flow identification module 82 then outputs the tag for use by the layer 3 switching logic in step 120”).
Regarding claim 6, Viswanath discloses the network device defined in claim 5, wherein the packet processing circuitry is configured to provide the non-leading fragment along with metadata based on the fragment mapping table entry for downstream processing of the non-leading fragment (Viswanath and col. 2/lines 27-47 detx 15; “The cached portions of the layer 3 information and the corresponding policy identifier are then used by the flow identification module to identify the appropriate policy for subsequent fragmented layer 3 frames that lack the layer 4 information necessary for performing another policy lookup, but that have sufficient layer 3 information to uniquely identify each layer three flow. Hence, each layer 3 fragment can be assigned a unique policy for execution of layer 3 switching decisions” and col. 8/lines 45-51; detx 22; “The flow identification module 82 then outputs the tag for use by the layer 3 switching logic in step 120”).
Regarding claim(s) 21 and 24, do(es) not teach or further define over the limitation in claim(s) 1 respectively. Therefore claim(s) 21 and 24 is/are rejected for the same rationale of rejection as set forth in claim(s) 1 respectively.
Claim Rejections - 35 USC § 103
In the event the determination of the status of the application as subject to AIA 35 U.S.C. 102 and 103 (or as subject to pre-AIA 35 U.S.C. 102 and 103) is incorrect, any correction of the statutory basis for the rejection will not be considered a new ground of rejection if the prior art relied upon, and the rationale supporting the rejection, would be the same under either status.
The following is a quotation of 35 U.S.C. 103 which forms the basis for all obviousness rejections set forth in this Office action:
A patent for a claimed invention may not be obtained, notwithstanding that the claimed invention is not identically disclosed as set forth in section 102 of this title, if the differences between the claimed invention and the prior art are such that the claimed invention as a whole would have been obvious before the effective filing date of the claimed invention to a person having ordinary skill in the art to which the claimed invention pertains. Patentability shall not be negated by the manner in which the invention was made.
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.
Claims 7-9, 22-23 and 25-26 are rejected under 35 U.S.C. 103 as being unpatentable over Viswanath et al. (US 6,798,788) in view of Battestilli et al. (US 2012/0224581).
Regarding claim 7, Viswanath discloses the invention substantially, however the prior art does not explicitly disclose the network device defined in claim 1, wherein the packet processing circuitry is configured to receive a non-leading fragment of multiple packet fragments split from an original packet prior to the fragment mapping table containing the fragment mapping table entry and is configured to buffer the non-leading fragment.
Battestilli in the field of the same endeavor discloses techniques for steering al fragments of the same original IP datagram to one server port. In particular, Battestilli disclose the following:
wherein the packet processing circuitry is configured to receive a non-leading fragment of multiple packet fragments split from an original packet (Battestilli discloses the ethernet switch (packet processing circuity) receives follow-on (non-leading) fragments that arrive before the lead fragment; [0028] “if the packet header of fragment 202 is not a lead fragment then it has only the 3-tuple fields in its header. The parsing logic 206 is able to determine that fragment 202 is not a lead fragment in a fragment series, but rather is a subsequent ("follow-on") fragment…the fragmentation control service 216 pushes subsequent fragment 202 onto a local queue, such as FIFO queue 218”)
prior to the fragment mapping table containing the fragment mapping table entry (Battestilli discloses the fragmentation table entry is created/updated only when the lead fragment arrives and supplies the missing 5-tuple information. Therefore, any non-leading fragment received before that point is received prior to the table containing the entry; [0028] “Fragment 202 stays on FIFO queue 218 until the lead fragment of a fragmented IP packet arrives at Ethernet switch 204. A fragmentation table 222 contains entries that steer all fragments in a series to a same destination port based on the 3-tuple and identification field in the header. When the lead fragment of a fragmented IP packet arrives at Ethernet switch 204, Ethernet switch 204 looks-up in TCAM 208 what to do with the series of fragments that make up the original IP packet based on the 5-tuple. The Ethernet switch 204 then forwards the lead fragment to the Fragmentation Control Service 216, where it is added to the FIFO queue 218 and the fragmentation table 222 is updated”) and
is configured to buffer the non-leading fragment (Battestilli discloses the ethernet switch buffers the non-leading fragment in a FIFO queue until the lead fragment arrives and the table entry is created; [0028] “the fragmentation control service 216 pushes subsequent fragment 202 onto a local queue, such as FIFO queue 218”).
Therefore, it would have been obvious to a person of ordinary skill in the art at the time the invention was effectively filed to modify the prior art with the teaching of Battestilli. One would have been motivated because Battestilli would enable one to active consistent and efficient steering of all fragments using the complete header information available only in the leading fragment.
Regarding claim 8, Viswanath-Battestilli discloses the network device defined in claim 7, wherein the packet processing circuitry is configured to receive a leading fragment of the multiple packet fragments split from the original packet while the non-leading fragment is buffered and is configured to provide the fragment mapping table entry by processing the leading fragment (Battestilli discloses the non-leading (“follow-on”) fragment arrives first and is buffered in a FIFO queue. Later, while the non-leading fragment reminds buffered, the switch receives the leading fragment, processes it (parses the 5-tuple, determines the destination port/steering decision), and uses that processing to create/update the fragmentation table entry (the “fragment mapping table entry”). The table entry maps the network-layer header information (3-tuple + Identification field) of any fragment in the series to the full flow-steering decision (destination port). Once the entry is provided by the leading fragment, the buffered non0leading fragment(s) are immediately popped from the queue and steered using the new table entry; [0030-0031] “if the fragment received at the switch is the lead fragment, then the 5-tuple is used to determine the destination port for that IP packet fragment (block 408). The lead fragment is sent to a Fragmentation Control Service (FCS) (block 418). When the lead fragment arrives at the FCS, a fragmentation table is updated with an entry of the selected destination port, which will be use to steer all fragments of this series (block 422)…If however, the lead fragment has not yet arrived, then the follow-on fragment is added to a FIFO queue for this fragment series (block 414)” and [0042-0043] “Once the lead/first packet fragment arrives at fragmentation control service 216 (block 514), there is no hit in the fragmentation table (decision block 516). Therefore, the fragmentation table is updated (block 520) with an entry containing the 3-tuple plus the identification field and the selected destination server port… When this non-lead fragment arrives at fragmentation control service 216 (block 514), and there is no hit in the fragmentation table (block 516) because the lead fragment has not yet arrived, the fragment is added to a FIFO queue (blocks 528, 530, 532)”).
Regarding claim 9, Viswanath-Battestilli discloses the network device defined in claim 8, wherein the packet processing circuitry is configured to output the non-leading fragment for downstream processing based on the fragment mapping table entry being provided and wherein the non-leading fragment is output along with metadata based on the fragment mapping table entry (Battestilli discloses non-leading fragments received before the lead fragment are buffered. When the lead fragment arrives, the circuity provides (updates) the fragmentation table entry and then immediately outputs every buffered non-leading fragment for downstream steering/processing; [0042] “Once the lead/first packet fragment arrives at fragmentation control service 216 (block 514), there is no hit in the fragmentation table (decision block 516)…The fragments are sent to Ethernet switch 204 for steering to the appropriate server/service via the port identified in the lead packet fragment's 5-tuple (block 544), and the process ends (block 546)”).
Regarding claim 22, Viswanath discloses the one or more non-transitory computer-readable storage media defined in claim 21 further comprising computer- executable instructions that, when executed by the one or more processors, cause the one or more processors to:
provide the fragment mapping table entry based on processing a leading fragment (Battestilli [0041-0042] “the fragment and the selected server port are always sent to fragmentation control service 216 (block 512), in order to update a fragmentation table and preserve the arrival order of the fragment to Ethernet switch 204… Once the lead/first packet fragment arrives at fragmentation control service 216 (block 514), there is no hit in the fragmentation table (decision block 516). Therefore, the fragmentation table is updated (block 520) with an entry containing the 3-tuple plus the identification field and the selected destination server port”),
wherein the packet fragment is a non-leading fragment (Battestilli [0043] “If Ethernet switch 204 receives a fragment that is not a lead fragment (decision block 504), then it forwards it to fragmentation control service 216 (block 526). When this non-lead fragment arrives at fragmentation control service 216 (block 514), and there is no hit in the fragmentation table (block 516) because the lead fragment has not yet arrived, the fragment is added to a FIFO queue (blocks 528, 530, 532). If there is a hit in the fragmentation table (decision block 516), then it is checked whether there is a FIFO queue (block 522). If yes, then the fragment is added to the queue (block 534); else it is sent to the selected server port (block 524)”) and
wherein an original packet split into at least the leading fragment and the non-leading fragment (Battestilli [0040-0041] “Ethernet switch 204 (switch system) receives a packet fragment from an original IP packet (block 502)… If the fragment is the lead/first packet fragment (query block 504), then the packet header and 5-tuple are parsed (block 506) in order to determine what egress server port to steer all the fragments of the original IP packet. Based on TCAM look-up (block 508), the egress server port can be specified in a redirection rule based on the 5-tuple, or the redirection rule can be a rule that directs to a link aggregation group (LAG)”).
Regarding claim 23, Viswanath discloses the one or more non-transitory computer-readable storage media defined in claim 22, wherein the flow cache entry includes transport layer header information (Viswanath col. 6/lines 63 0 col. 7/lines 10; detx 14; “the transmitting network node generates layer 4 payload data 74 (e.g., components A, B, and C), and layer 4 header information 76, for example transmission control protocol (TCP) source port, destination port, etc. that identifies the layer 4 payload data 74 as belonging to a prescribed layer 4 data stream”),
wherein the leading fragment includes the transport layer header information (Viswanath col. 7/lines 10-20; detx 15; “the first layer 2 packet 72a includes an Ethernet header 52, the IP header 54, the TCP header 76, and a portion of the layer 4 payload data 74a”), and
wherein the non-leading fragment lacks the transport layer header information (Viswanath col. 7/lines 65 – col. 8/lines 14; detx 18; “the flow identification module 82 can select the policy identifier for each of the subsequent layer 3 frame fragments 72b and 72c based on a match between the IP source address and IP identifier stored in the table 86 and the IP source address 60 and the IP identifier 64 in each of the layer 3 frame fragments 72b and 72c”).
Regarding claim 25, Viswanath discloses the method defined in claim 24, wherein the packet fragment is a non-leading fragment split from an original packet fragment (Battestilli [0043] “If Ethernet switch 204 receives a fragment that is not a lead fragment (decision block 504), then it forwards it to fragmentation control service 216 (block 526). When this non-lead fragment arrives at fragmentation control service 216 (block 514), and there is no hit in the fragmentation table (block 516) because the lead fragment has not yet arrived, the fragment is added to a FIFO queue (blocks 528, 530, 532). If there is a hit in the fragmentation table (decision block 516), then it is checked whether there is a FIFO queue (block 522). If yes, then the fragment is added to the queue (block 534); else it is sent to the selected server port (block 524)”).
Regarding claim 26, Viswanath discloses the method defined in claim 24 further comprising:
providing the fragment mapping table entry based on processing a leading fragment split from the original packet (Battestilli [0041-0042] “the fragment and the selected server port are always sent to fragmentation control service 216 (block 512), in order to update a fragmentation table and preserve the arrival order of the fragment to Ethernet switch 204… Once the lead/first packet fragment arrives at fragmentation control service 216 (block 514), there is no hit in the fragmentation table (decision block 516). Therefore, the fragmentation table is updated (block 520) with an entry containing the 3-tuple plus the identification field and the selected destination server port”).
Claims 10-11 and 14 are rejected under 35 U.S.C. 103 as being unpatentable over Viswanath et al. (US 6,798,788) in view of Babbar et al. (US 2005/0286517).
Regarding claim 10, Viswanath discloses the invention substantially, however the prior art does not explicitly disclose the network device defined in claim 1, wherein the fragment mapping table entry includes a source Internet Protocol (IP) address, a destination IP address, a transport layer (L4) protocol, and an IP identification value.
Babbar in the field of the same endeavor discloses techniques for buffering all received fragments of a fragmented datagram in fragment memory until all filter parameter become available from the arriving fragments. In particular, Babbar teaches the following:
wherein the fragment mapping table entry includes a source Internet Protocol (IP) address, a destination IP address, a transport layer (L4) protocol, and an IP identification value (Babbar discloses a routing table entry (FIG. 6/item 612) stores a datagram identifier that is built directly from the four IP-header fields. These four fields are stored in the table entry and used as the lookup key for every fragment; [0029] “identification--carries an identification value assigned by a source host to aid in the re-assembly of fragments (if any) for the datagram” (IP identification), [0033] “Protocol--indicates the next higher layer protocol used in the payload portion of the IP packet” (L4 protocol), [0034] “Source Address--carries the IP address of the source host” (source IP), [0035] “Destination Address--carries the IP address of the destination host” (destination IP), [0038] “Datagram identifier 200 is formed by concatenating the Identification, Protocol, Source Address, and Destination Address fields of the IP header”) that are collectively usable to identify each of multiple fragments split from an original packet (Babbar discloses the same four fields are required to be identical across every fragment of one original datagram, and the routing table uses exactly that four-tuple as the key to retrieve the single stored processing decision (filter result) that applies to the entire original packet; [0038] “The same identification value is used for all fragments of a given datagram. Thus, all IP packets with the same set of values for these four fields may be considered as belonging to the same datagram”).
Therefore, it would have been obvious to a person of ordinary skill in the art at the time the invention was effectively filed to combine the prior art with the teaching of Babbar. One would have been motivated because combining Babbar’s stored routing decision with the prior art would predictably yield a more complete and efficient fragment-handling mechanism.
Regarding claim 11, Viswanath-Babbar discloses the network device defined in claim 10, wherein the flow cache entry includes the source IP address, the destination IP address (Viswanath discloses a network switch port includes a policy cache because it aches flow-defining information for repeated use on subsequent packet/fragments of the same flow (see also flow identification module 82 that works in conjunction with the policy cache to handle fragments and stores both the source IP address and destination IP address); col. 7/lines 35-64; detx 17; “The policy cache 84, which stores for each entry an IP source address, IP destination address, TCP/UDP input port, TCP/UDP output port, and corresponding policy identifier, is used by the policy filter 80 to check if any non fragmented packets have been classified earlier with respect to the corresponding policy identifier”), the L4 protocol (Viswanath col. 8/lines 24-36; detx 20 “the policy filter 80 determines the policy identifier in step 106 based on the IP source address, and the TCP source port address”), a source L4 port, and a destination L4 port that collectively define the network flow (Viswanath discloses the fields (src/dst IP + L4 protocol (TCP/UDP) + src/dst L4 ports) are stored together in the cache entry and are used by the policy filter and flow indication module to uniquely identify and process the entire network flow (including all fragments of the same datagram) col. 7/liens 65 - col. 8/lines 13; detx 18; “The flow identification module 82 stores the IP source address, IP destination address, the IP identifier 64, and the corresponding policy identifier (tag) into an internal table 86 at the same time that the data is written into the policy cache 84. The flow identification module 82 uses the combination of the IP source address and the IP identifier to uniquely identify each of the data fragments 72 as belonging to the same IP datagram 70 for a given layer 4 data flow”).
Regarding claim 14, Viswanath-Babbar discloses the network device defined in claim 1, wherein the packet processing circuitry is configured to remove the fragment mapping table entry based on all packet fragments associated with the fragment mapping table entry being received by the packet processing circuitry (Babbar discloses the filtering node’s processor (packet processing circuitry) that executes process 400. The fragment mapping table entry corresponds to the routing table entry created and maintained for each fragmented datagram. This entry is indexed by the datagram identifier (network-layer header fields) and stores information used to process all fragments of that datagram; [0055] “The node then determines whether all fragments of the datagram have been received based on the updated fragment information (block 444). The entire datagram is received if (1) the last fragment for the datagram has been received (the last fragment has the MF bit set to "0") and (2) all other fragments for the datagram have also been received (which may be determined based on the fragment offset and payload size of each received fragment). If the entire datagram has been received, then the node deletes the routing table entry for the datagram and purges all of the fragments of the datagram from the fragment memory (block 446)”).
Claims 12-13 are rejected under 35 U.S.C. 103 as being unpatentable over Viswanath et al. (US 6,798,788) in view of Babbar et al. (US 2005/0286517) in view of Battestilli et al. (US 2012/0224581).
Regarding claim 12, Viswanath-Babbar disclose the invention substantially, however the prior art does not explicitly disclose the network device defined in claim 11, wherein the packet processing circuitry is configured to process a non-leading fragment of the multiple packet fragments split from the original packet based on the flow cache entry using the fragment mapping table entry, wherein the non-leading fragment includes the source IP address, the destination IP address, the L4 protocol, and the IP identification value, and wherein the non-leading fragment lacks the source L4 port and the destination L4 port.
Battestilli in the field of the same endeavor discloses techniques for steering al fragments of the same original IP datagram to one server port. In particular, Battestilli disclose the following:
wherein the packet processing circuitry is configured to process a non-leading fragment of the multiple packet fragments split from the original packet based on the flow cache entry using the fragment mapping table entry (Battestilli discloses the ethernet switch (packet processing circuitry) and its Fragmentation Control Service receive a follow-on (non-leading) fragment and perform a lookup in the fragmentation table (the “fragment mapping table entry”). This lookup directly yields the destination-port steering decision that was previously determined from the lead fragment’s full 5-tuple processing (the “flow cache entry” / action for the entire flow). The non-leading fragment is then immediately steered/processed using that decision; [0028] “A fragmentation table 222 contains entries that steer all fragments in a series to a same destination port based on the 3-tuple and identification field in the header. When the lead fragment of a fragmented IP packet arrives at Ethernet switch 204, Ethernet switch 204 looks-up in TCAM 208 what to do with the series of fragments that make up the original IP packet based on the 5-tuple. The Ethernet switch 204 then forwards the lead fragment to the Fragmentation Control Service 216, where it is added to the FIFO queue 218 and the fragmentation table 222 is updated” and [0031] “If the lead fragment has already arrived (query block 412) then there is already an entry for this fragment series in the fragmentation table and thus the follow-on fragment is sent to the specified destination port (block 416)”),
wherein the non-leading fragment includes the source IP address, the destination IP address, the L4 protocol, and the IP identification value (Battestilli discloses every non-leading/follow-on fragment carries exactly these network-layer fields (3-typle + IP Identification) in its IP header; [0023] “The subsequent ("follow-on") packet fragments in the series only retain the 3-tuple in their headers, i.e. 1) source IP address, 2) destination IP address, and 3) the protocol”), and
wherein the non-leading fragment lacks the source L4 port and the destination L4 port (Battestilli [0021] “"5-tuple" and/or "IP 5-tuple" is defined as five particular fields in the IP packet header” and [0023] “only the first ("lead") packet fragment retains the original IP header and thus contains the entire 5-tuple. The subsequent ("follow-on") packet fragments in the series only retain the 3-tuple in their headers, i.e. 1) source IP address, 2) destination IP address, and 3) the protocol”).
Therefore, it would have been obvious to a person of ordinary skill in the art at the time the invention was effectively filed to modify the prior art with the teaching of Battestilli. One would have been motivated because Battestilli would enable one to active consistent and efficient steering of all fragments using the complete header information available only in the leading fragment.
Regarding claim 13, Viswanath-Babbar-Battestilli discloses the network device defined in claim 12, wherein the packet processing circuitry is configured to process a leading fragment of the multiple packet fragments split from the original packet based on the flow cache entry (Viswanath discloses packet processing circuitry (policy filter 80 + flow identification module 82 inside each network switch port) that processes the leading (first) fragment by applying the full L3/L4 policy lookup to determine the policy identifier/tag (the flow-cache decision) and then immediately uses that tag to forward the leading fragment itself through the switch fabric; col. 8/lines 36-45; detx 21; “If in step 102 the flow module 44 determines that the flow is fragmented, if the fragment is the first fragment in step 112, the policy filter 80 performs the same operation in steps 106, 108, and 110, and outputs the template tag to the switch fabric in step 120. However in this case, the flow identification module 82 monitors the output bus of the policy filter 80, and stores into the table 86 the IP source address, IP destination address (optional), the IP identifier, and the corresponding policy tag of the first IP fragment in step 114”),
wherein the leading fragment includes the source IP address, the destination IP address, the L4 protocol, the IP identification value, the source L4 port, and the destination L4 port (Viswanath col. x/lines x; detx 17; “the policy filter 80 obtains the layer 3 information (such as IP source address, IP destination address), and layer 4 information (such as TCP source port or TCP destination port) from the non fragmented IP packet 70 or the first IP fragment in the layer 2 packet 72a” and col. 6/lines 50-63; detx 13; “The IP header portion 54 also includes an IP source address field 60, and IP destination address field 62, and an IP identifier field 64”).
Conclusion
For the reason above, claims 1-14 and 21-26 have been rejected and remain pending.
Any inquiry concerning this communication or earlier communications from the examiner should be directed to JIMMY H TRAN whose telephone number is (571)270-5638. The examiner can normally be reached Monday-Friday 9am-5pm PST.
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, Chris Parry can be reached at 571-272-8328. 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.
JIMMY H TRAN
Primary Examiner
Art Unit 2451
/JIMMY H TRAN/Primary Examiner, Art Unit 2451
Prosecution Insights