DETAILED ACTION
This communication is in response to Application No. 18/303,704 filed on 4/20/2023. The amendment presented on 12/9/2025, which amends claims 1, 3-4, 7-12 and cancels claim 2, is hereby acknowledged. Claims 1 and 3-20 have been examined.
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 arguments with respect to claims 1 and 3-20 have been considered but are moot because the new ground of rejection does not rely on any reference applied in the prior rejection of record for any teaching or matter specifically challenged in the argument.
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.
Claims 1, 3, and 14-20 are rejected under 35 U.S.C. 103 as being unpatentable over Subramanian et al. (hereinafter Subramanian)(US 9,853,898) in view of Basavaraj et al. (hereinafter Basavaraj)(US 2021/0314182).
Regarding claim 1, Subramanian teaches as follows:
A method of operating a network device (network device 40 in figure 2 may represent an example instance of service control gateway 20 of FIG. 1, see, col. 11, lines 55-67) comprising:
receiving a data packet (network device 40 receives packets for packet flow 80 and directs the packets along the service chain defined by services list 60, see, col. 13, lines 11-17 and figure 2) via a logical interface (an “in” VRF having an outgoing interface (OIF) for sending service traffic to the service node, and an “out” VRF having an incoming interface (IIF) for receiving service traffic from the service node. Reference herein to incoming and outgoing interfaces may refer to virtual or software interfaces (equivalent to applicant’s logical interface) configured in the device, see, col. 12, lines 12-25); and
performing virtual routing and forwarding (VRF) mapping lookup to identify, using the logical interface, a forwarding VRF identifier and a source VRF identifier (forwarding unit 54 includes lookup module 56, which is configured to determine a next service 62 in the ordered services list 60 for application to service traffic based on the VRF with which the network device 40 receives the traffic, see, col. 13, lines 11-17 and figure 2)(services list 60 specifies the services as a list of respective VRF names that identify VRFs 64, 70 with which network device 40 exchanges services traffic with the corresponding service nodes 10. Service 62A specifies “SVC-VRF-1” identifying VRFs 64 for exchanging service traffic with service node 10A, and service 62B specifies “SVC-VRF-2” identifying VRFs 70 for exchanging service traffic with service node 10B. In this way, forwarding unit 54 is configured to stitch together a service chain made from service node 10A to service node 10B, see, col. 12, line 62 to col. 13, line 10 and figure 2. Therefore packet flow 80 is mapped from service node 10A (SVC-VRF-1)(equivalent to applicant’s source VRF identifier) to service node 10B (SVC-VRF-2)(equivalent to applicant’s forwarding VRF identifier); and
identifying an additional next hop by performing forwarding lookup using the forwarding VRF identifier (forwarding unit 54 includes lookup module 56, which is configured to determine a next service 62 (equivalent to applicant’s additional next hop) in the ordered services list 60 for application to service traffic based on the VRF with which the network device 40 receives the traffic, see, col. 13, lines 11-17 and figure 2).
Subramanian does not teach the reverse path forwarding (RPF) to identify a next hop.
Basavaraj teaches as follows:
After receiving multicast packets 301, north/south packet handler 122 performs its reverse path forwarding (RPF) check on multicast packets 301 at step 3 to determine whether multicast packets 301 should be transferred to a next hop or dropped to stop looping. In particular, north/south packet handler 122 references unicast routing information 341 to determine whether an entry exists for source 103. In this example, multicast packets 301 identify their source based on the source's network address, which is network address 331 of source 103. Source 103 is, likewise, identified by its network address 331 in unicast routing information 341 (see, ¶ [0030] and figure 3).
Therefore, it would have been obvious for one of ordinary skill in the art before the effective filing date of the claimed invention to modify Subramanian with Basavaraj to include the reverse path forwarding (RPF) check as taught by Basavaraj in order to efficiently identify a next hop based on the source address.
Regarding claim 3, Subramanian teaches as follows:
Performing the VRF mapping lookup comprises using the logical interface as a key to a VRF mapping lookup table (lookup table 220 includes entries 220A-220F each having an IIF key value and resolving to different forwarding table that is dependent on whether the received packets having the IIF key value are uplink packets or downlink packets, see, col. 19, lines 20-35).
Regarding claims 14 and 15, Subramanian teaches all limitations as presented above in the rejection of claim 1 except for the reverse path forwarding (RPF).
Basavaraj teaches the reverse path forwarding (RPF) check as presented above.
Therefore, they are rejected for similar reason as presented above.
Regarding claim 16, Subramanian teaches as follows:
A system (interpreted as the network system 2 in figure 1) comprising:
an interface (interpreted as IIF 66B and IIF 72B in figure 2 which receives packet flow 80 from service node 10A or 10B) configured to receive a data packet (network device 40 receives packets for packet flow 80 and directs the packets along the service chain defined by services list 60, see, col. 13, lines 11-17 and figure 2);
a virtual routing and forwarding (VRF) mapping stage configured to perform a VRF mapping lookup operation to identify first and second VRF identifiers; a second forwarding stage configured to perform a forwarding lookup operation to identify a next hop based on at least the second VRF identifier (forwarding unit 54 includes lookup module 56, which is configured to determine a next service 62 in the ordered services list 60 for application to service traffic based on the VRF with which the network device 40 receives the traffic, see, col. 13, lines 11-17 and figure 2)(services list 60 specifies the services as a list of respective VRF names that identify VRFs 64, 70 with which network device 40 exchanges services traffic with the corresponding service nodes 10. Service 62A specifies “SVC-VRF-1” identifying VRFs 64 for exchanging service traffic with service node 10A, and service 62B specifies “SVC-VRF-2” identifying VRFs 70 for exchanging service traffic with service node 10B. In this way, forwarding unit 54 is configured to stitch together a service chain made from service node 10A to service node 10B, see, col. 12, line 62 to col. 13, line 10 and figure 2. Therefore packet flow 80 is mapped from service node 10A (SVC-VRF-1)(equivalent to applicant’s source VRF identifier) to service node 10B (SVC-VRF-2)(equivalent to applicant’s forwarding VRF identifier).
Subramanian does not teach the first forwarding stage configured to perform a reverse path forwarding (RPF) lookup operation.
Basavaraj teaches as follows:
After receiving multicast packets 301, north/south packet handler 122 performs its reverse path forwarding (RPF) check on multicast packets 301 at step 3 to determine whether multicast packets 301 should be transferred to a next hop or dropped to stop looping. In particular, north/south packet handler 122 references unicast routing information 341 to determine whether an entry exists for source 103. In this example, multicast packets 301 identify their source based on the source's network address, which is network address 331 of source 103. Source 103 is, likewise, identified by its network address 331 in unicast routing information 341 (see, ¶ [0030] and figure 3).
Therefore, it would have been obvious for one of ordinary skill in the art before the effective filing date of the claimed invention to modify Subramanian with Basavaraj to include the reverse path forwarding (RPF) check as taught by Basavaraj in order to efficiently identify a next hop based on the source address.
Regarding claims 17-18, Subramanian in view of Basavaraj teaches similar limitations as presented above except for one or more intermediate stages interposed between two stages.
Therefore, it would have been obvious for one of ordinary skill in the art before the effective filing date of the claimed invention to modify Subramanian in view of Basavaraj to include interposing intermediate stage in order to efficiently add new operation stage between existing operation stages.
Regarding claims 19-20, Subramanian in view of Basavaraj teaches similar limitations as presented above. Subramanian further teaches the forwarding information base (FIB) as follows:
Routing process 166A resolves the topology defined by routing information in RIB 145 to select or determine one or more active routes through the network and then installs these routes to forwarding information base 142 (“FIB 142”), which is stored by kernel 143 that is responsible for synchronizing the FIB 142 (the master copy of the network device 100 FIB) with FIBs 148A-148N on respective forwarding units 125A-125N (see, col. 14, lines 38-53).
Therefore, they are rejected for similar reason as presented above.
Claims 4-11 are rejected under 35 U.S.C. 103 as being unpatentable over Subramanian et al. (hereinafter Subramanian)(US 9,853,898) in view of Basavaraj et al. (hereinafter Basavaraj)(US 2021/0314182), and further in view of Kamath et al. (hereinafter Kamath)(US 2020/0389358).
Regarding claims 4-8, Subramanian in view of Basavaraj teaches similar limitations as presented above except for setting a VRF profile to a value.
Kamath teaches as follows:
The computing device graphically presents (202) a plurality of VRF elements, which represent a plurality of stored VRF profiles. Each VRF profile contains profile data, and each VRF element presents at least part of the profile data from one of the VRF profiles. The profile data enables the networking device to route data toward a destination device. The profile data may include a routing table, protocol definitions that define parameters of one or more protocols the networking device may use to route the data, characteristics or properties of the networking device (see, ¶ [0029] and figure 2); and
the plurality of VRF elements may each include a status indicator that indicates deployment status of the represented stored VRF profile. For example, the status indicator indicates a deployment status of not deployed (e.g., INACTIVE), deployed without error (e.g., ACTIVE), or deployed with error (e.g., ACTIVE WARNING)
4. The method of claim 2, further comprising: in response to identifying the forwarding VRF identifier and the source VRF identifier, setting a VRF profile equal to a first value… Determining the status indicator may be based on analysis of the underlying profile or configuration data of the VRF profile and/or analysis of operation data resulting from operating a networking device configured using the VRF profile (see, ¶ [0030]).
Therefore, it would have been obvious for one of ordinary skill in the art before the effective filing date of the claimed invention to modify Subramanian in view of Basavaraj with Kamath to include the VRF profile as taught by Kamath in order to efficiently perform the data packet forwarding based on the VRF profile.
Regarding claim 9, Subramanian teaches as follows:
Performing RPF lookup by using the source VRF identifier and a source address of the data packet as keys to lookup a forwarding table (forwarding unit 54 includes lookup module 56, which is configured to determine a next service 62 in the ordered services list 60 for application to service traffic based on the VRF with which the network device 40 receives the traffic, see, col. 13, lines 11-17).
Regarding claim 10, Subramanian teaches as follows:
Performing forwarding lookup using the forwarding VRF identifier and a destination address of the data packet as keys to lookup the forwarding table (each of the VRFs and interfaces illustrated in FIGS. 5A-5B may include a forwarding table having routes that key to destination network addresses of packets and specify one or more actions for matching packets, e.g., forwarding the matching packets via an OIF for an attachment circuit to a service node, see, col. 19, line 51 to col. 20, line 3).
Regarding claim 11, Subramanian in view of Basavaraj and Kamath teaches all limitations as presented above except for dropping the data packet.
Therefore, it would have been obvious for one of ordinary skill in the art before the effective filing date of the claimed invention to modify Subramanian in view of Basavaraj and Kamath to include dropping (discarding) the data packet when no next hop is available in order to efficiently reduce processing delay.
Claims 12-13 are rejected under 35 U.S.C. 103 as being unpatentable over Subramanian et al. (hereinafter Subramanian)(US 9,853,898).
Regarding claim 12, Subramanian teaches as follows:
A method of operating a network device comprising:
receiving a data packet (network device 40 receives packets for packet flow 80 and directs the packets along the service chain defined by services list 60, see, col. 13, lines 11-17 and figure 2) via an interface (an “in” VRF having an outgoing interface (OIF) for sending service traffic to the service node, and an “out” VRF having an incoming interface (IIF) for receiving service traffic from the service node. Reference herein to incoming and outgoing interfaces may refer to virtual or software interfaces (equivalent to applicant’s logical interface) configured in the device, see, col. 12, lines 12-25); and
performing virtual routing and forwarding (VRF) mapping lookup to identify, based on the interface, a forwarding VRF identifier and a source VRF identifier (forwarding unit 54 includes lookup module 56, which is configured to determine a next service 62 in the ordered services list 60 for application to service traffic based on the VRF with which the network device 40 receives the traffic, see, col. 13, lines 11-17 and figure 2)(services list 60 specifies the services as a list of respective VRF names that identify VRFs 64, 70 with which network device 40 exchanges services traffic with the corresponding service nodes 10. Service 62A specifies “SVC-VRF-1” identifying VRFs 64 for exchanging service traffic with service node 10A, and service 62B specifies “SVC-VRF-2” identifying VRFs 70 for exchanging service traffic with service node 10B. In this way, forwarding unit 54 is configured to stitch together a service chain made from service node 10A to service node 10B, see, col. 12, line 62 to col. 13, line 10 and figure 2. Therefore packet flow 80 is mapped from service node 10A (SVC-VRF-1)(equivalent to applicant’s source VRF identifier) to service node 10B (SVC-VRF-2)(equivalent to applicant’s forwarding VRF identifier); and
storing the source VRF identifier associated with the data packet (service node 10A (SVC-VRF-1) associated with packet flow 80 is inherently stored, see, col. 12, line 62 to col. 13, line 10 and figure 2).
Subramanian does not explicitly teach the well-known metadata associated with the data packet.
Therefore, it would have been obvious for one of ordinary skill in the art before the effective filing date of the claimed invention to modify Subramanian to include the well-known metadata in order to efficiently provide more information associated with the data packet.
Regarding claim 13, Subramanian teaches of performing forwarding operation as presented above.
Therefore, it would have been obvious for one of ordinary skill in the art before the effective filing date of the claimed invention to modify Subramanian to include utilizing information stored as the metadata before performing the forwarding operation in order to efficiently forward the received data packet based on information associated with the data packet.
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 Jeong S Park whose telephone number is (571)270-1597. The examiner can normally be reached Monday through Friday 8:00-4:30 ET.
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, Glenton B Burgess can be reached at 571-272-3949. 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.
/JEONG S PARK/Primary Examiner, Art Unit 2454
March 16, 2026