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 .
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.
Claim(s) 1-3, 7-10,13, 21-23 and 27 is/are rejected under 35 U.S.C. 102(a)(1) as being anticipated by Nagre (US 2021/0075724 A1).
Regarding claim 1, Nagre discloses a method in a network device (Fig. 1 - 102/110) for forwarding packets (Nagre, fig. 1, [0022] discloses a method in a network device 102 which includes a forwarding engine 110 that processes packets that are transmitted on layer 3 network 104 or layer 2 network 106),
the method comprising:
receiving a packet (Nagre [0022] Network device 102 includes a forwarding engine that is capable of receiving a packet, where the packet includes a source address and a destination address);
concurrently searching both a first table (fig. 1 - exact match (EM) table -112) and a second table (fig. 1 - Longest Prefix match (LPM) table - 114) using the received packet (Packet received by network device 102) (Nagre, fig. 1, [0022; 0025] the forwarding engine 110 included in the network device 102 may receive a packet, which includes a source address and a destination address, and then use one of an exact match (EM) table 112 and a longest prefix match (LPM) table 114 to determine a next hop for the packet; For a given destination address, the network device 102 performs address lookups on the destination address using both exact match table 112 and longest prefix match table 114. The network device 102 performs these address lookups concurrently);
in response to a search of the second table (Longest Prefix match (LPM) table - 114) yielding a search result (table entry (yielding a match – next hop)) (Nagre [0022; 0064] forwarding engine 110 may receive a packet, which includes a source address and a destination address, and then use one of an exact match (EM) table 112 and a longest prefix match (LPM) table 114 to determine a next hop for the packet. The second table 114 uses a longest prefix address lookup to determine a longest prefix that matches the destination address in the layer 3 address or the destination address in the layer 2 address route to determine the next hop address):
locating a bin (entry/location within a table) in the table entry (Prefix address) using the received packet (Nagre, [0026; 0064] the network device uses the second table to store each layer 3 address in specific entry/location in the table. When a packet is received by the network device 102/110, the destination address in the packet is used to perform a second type of lookup in the second table to determine which location/entry in the table contains a prefix address that matches the next hop address for layer 3 addresses that matches the destination address in the received packet);
when the located bin contains a next hop, then forwarding the received packet according to the next hop (Nagre [0025] entries in exact match table 112 and longest prefix match table 114 may be referred to as address routes, and may include an address or address range (e.g., a subnet) and a next hop. When an entry/location in the longest match table storing an address that matches the destination address in the received packet is identified, the address identified in that specific entry/location in the table is the next hop in the path the packet would traverse towards the destination address indicated in the packet. The next hop is a next step in the route in which a packet is transmitted, such as an interface that is used by the network device 102 to transmit a packet with an address that matches the entry); and
when the located bin (entry/location in longest prefix table) contains a predefined value (default value) that does not represent a next hop (Nagre [0030] If a key from a longest prefix match being looked up does not match any entry at all, a default value stored in the longest prefix table may be returned, indicating that a next hop was not found in the longest prefix match table),
then forwarding the received packet according a next hop contained in a search result from the first table (Exact match table) (Nagre [0025; 0031] for a given destination address, the network device 102 performs address lookups on the destination address using both exact match table 112 and longest prefix match table 114. The network device 102 performs these address lookups concurrently. The exact match address lookup is preferred over the longest prefix match address lookup, thus, forwarding engine 110 may make sure that more specific routes are stored in exact match table 112 and not in the longest prefix match table 114. Because some routes may not be stored in the longest prefix match table, some lookups in the longest prefix match table may return a default value indicating that no match or next hop was found. However, a similar lookup in the exact match table will produce a match/next hop and the packet will be forwarded using the match resulting from the exact match table/first table); and
in response to a search of the second table not yielding a search result (Nagre [0030 -0031] If a key from a longest prefix match being looked up does not match any entry at all, a default value may be returned, indicating that a next hop was not found in the longest prefix match table. In response to not finding a match in the longest prefix table, performing a lookup in the exact match table),
then, forwarding the received packet according to the next hop contained in the search result from the first table (Nagre [0025; 0031] the exact match address lookup is preferred over the longest prefix match address lookup, thus, forwarding engine 110 may make sure that more specific routes are stored in exact match table 112 and not longest prefix match table 114. Because some routes may not be stored in the longest prefix match table, some lookups in the longest prefix match table may return a default value indicating that no match or next hop was found. However, a similar lookup in the exact match table will produce a match/next hop and the packet will be forwarded according to match/next hop found in the exact match table).
Regarding claim 2, Nagre discloses the method of claim 1, further comprising, in response to both a search of the first table (exact match (EM) table -112)) yielding a search result (first result) and a search of the second table (longest prefix match (LPM) table 114) yielding a search result (second result), forwarding the packet according the first search result or the second search result depending on which search result is associated with a longer prefix (Nagre [0030] Network device 102 may store entries in longest prefix match table 114 as key value pairs. Forwarding engine 110 uses the destination addresses as the key for the address lookup in entries of the longest prefix match table. It is possible that multiple matches may occur for the key. Thant is, the prefix used to perform the look-up may be associated with multiple keys in longest prefix match table 114. The look-up selects the key from longest prefix match table 114 that matches the key having the most number of bits (e.g., the most specific key) that match. For example, if one forwarding entry can match 16 bits of an address and another forwarding entry matches 24 bits of an address, forwarding engine 110 uses the second forwarding entry for the longest prefix match as matching 24 bits is longer than matching 16 bits).
Regarding claim 3, Nagre discloses the method of claim 1, further comprising using a destination Internet Protocol (DIP) address in the received packet to search the first and second tables (Nagre [0022; 0027] Network device 102 includes a forwarding engine 110 that processes packets that are transmitted on layer 3 network 104 or layer 2 network 106. Forwarding engine 110 may receive a packet, which includes a source address and a destination address, and then use one of an exact match (EM) table 112 and a longest prefix match (LPM) table 114 to determine a next hop for the packet. If network device 102 is performing both a 23 and 19 bit prefix lookup, the lookup for the 23 bit prefix would be 1′b0 followed by the first 23 bits of the destination IP address then all zeroes afterwards and the lookup for 19 bit address would be 1′b1 followed by the first 19 bits of the destination IP address and then all zeroes).
Regarding claim 7, Nagre discloses the method of claim 1, wherein the first table is a longest prefix match table, wherein the second table is an exact match table (Nagre [0023] discloses an exact match table 112 and longest prefix match table 114 can include forwarding information. For example, exact match table 112 and longest prefix match table 114 store routing table entries for the one or more routing protocols that are used by forwarding engine 110).
Regarding claim(s) 8-10 and 13, the claim(s) are rejected with rational similar to that of claim(s) 1-3 and 7, respectively.
Regarding claim(s) 21-23 and 27, the claim(s) are rejected with rational similar to that of claim(s) 1-3 and 7, 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 (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 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 text of those sections of Title 35, U.S. Code not included in this action can be found in a prior Office action.
Claim(s) 4,11 and 24 is/are rejected under 35 U.S.C. 103 as being unpatentable over Nagre (US 2021/0075724 A1), in view of Ise et al. (US 2003/0133411 A1).
Regarding claim 4, Nagre discloses the method of claim 1, wherein searching the second table (longest prefix match table 114) comprises using a first prefix of a DIP address in the received packet as a lookup key (multiple keys in longest prefix match table 114), (Nagre [0030] for a given destination IP (DIP) address in a packet, the first prefix of the DIP address used to perform the look-up may be associated with multiple keys in longest prefix match table 114);
Nagre did not explicitly disclose wherein locating the bin in the table entry comprises using a second prefix of the DIP address.
Ise discloses wherein locating the bin (flow group) in the table entry (flow group identifier) comprises using a second prefix (network address) of the DIP address (destination IP address) (Ise, figs. 5 & 7 [0065-0066;0076] discloses a technique for grouping packets with the same network destination IP address into the same flow group/bin and stored in a route identification table of fig. 7 using a flow group identifier. The route identification table may be searched using the route identifier to identifier packets belonging to a flow group and forward the packet to a destination address identified in the packet).
One of ordinary skill in the art would have been motivated to combine Nagre and Ise because these teachings are from the same field of endeavor with respect to disclosing techniques for determining how to forward a packet received in a communication network.
Therefore, before the effective filing date of the invention, it would have been obvious to a person of ordinary skill in the art to incorporate the strategies by Ise into the invention of Nagre. The motivation would have been to ensure the allocation of sufficient network communication resources to one set of flows which share at least a route from that edge node to an egress node of the network using priority control, Ise, [Abstract].
Regarding claim 11, the claim is rejected with rational similar to that of claim 4.
Regarding claim 24, the claim is rejected with rational similar to that of claim 4.
Allowable Subject Matter
Claim(s)5-6,12, 25-26 are objected to as being dependent upon a rejected base claim, but would be allowable if rewritten in independent form including all of the limitations of the base claim and any intervening claims.
Conclusion
The prior art made of record and not relied upon is considered pertinent to applicant's disclosure. The following publications show the state of the art related to techniques for determining how to forward a packet received in a communication network.
Zamsky et al. (US 11,178,054 B1)
Ko et al. (US 2004/0105442 A1)
Ise et al. (US 6,33,129 B1)
Brown (US 2004/0059830 A1)
Aimoto US 2002/0181484 A1)
Any inquiry concerning this communication or earlier communications from the examiner should be directed to DIXON F DABIPI whose telephone number is (571)270-3673. The examiner can normally be reached on Monday - Friday from 9:00 am – 5:00 pm.
If attempts to reach the examiner by telephone are unsuccessful, the examiner’s supervisor, Christopher L Parry, can be reached at telephone number 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 an application may be obtained from Patent Center. Status information for published applications may be obtained from Patent Center. Status information for unpublished applications is available through Patent Center to authorized users only. Should you have questions about access to the USPTO patent electronic filing system, contact the Electronic Business Center (EBC) at 866-217-9197 (toll-free).
Examiner interviews are available via a variety of formats. See MPEP § 713.01. To schedule an interview, applicant is encouraged to use the USPTO Automated Interview Request (AIR) Form at https://www.uspto.gov/InterviewPractice.
/D.F.D/ Examiner, Art Unit 2451
/Chris Parry/Supervisory Patent Examiner, Art Unit 2451
Prosecution Insights