Detailed Action
The office action is in response to the communications filed on 12/29/2025.
Notice of 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 .
Claims Status
Claims 12-19 have been withdrawn.
Claims 1 and 29 have been amended.
Claims 1-11 and 20 are pending in this application.
Prior Art Made of Record
The prior art made of record and not relied upon is considered pertinent to applicant's disclosure. Kumar et al. (Publication No. US 2017/0163531), the prior art discloses that the SFFs that are stateful use flow state to record SPI and SIs and validate the same when the packet is received back from a SF; see ¶ 0061.
Response to Arguments
Applicant remarks, filed on 12/29/2025, argues that the cited portion of the prior art, individually or in combination, fails to discloses the features in claim 1.
In specific, Applicant argues that the prior art identifier is not an identifier of an executing entity that processes a data stream. Examiner respectfully disagrees. Based on the context of the claim the identifier is any information enabling the identification of the executing entity. Nainar discloses that once a particular SFP has been selected, the service function identification is included in the packet; see figure 7 numeral 708 & ¶ 0040. The policy table includes an entry for source/destination addresses for packet, a service function chain ID, and a selected SFP [resource modules]; see figure 5 numeral 114-118 & ¶ 0029. When using the SRv6 protocol for implementing service function chain, the policy table further includes information regarding a stack of SRv6 segments [identifier of the resource module] for implementing the specific SFP selected; see figure 5 numeral 410 & ¶ 0029. For example, the stack of SRv6 segments [identifier of the resource module] implementing SFP1 is segments 2001::100; 2001::1; 2001::2; and 2001::200; see figure 5 numeral 424 & ¶ 0030. Therefore, the identifier has been equated to the prior art identification information. Examiner suggest to explicitly describe the type of identifier in order to distinguish from the prior art of record.
In addition, Applicant has amended the claim to distinguish from the previous rejection by incorporating the concept of storing status information associated with processing the data stream. Examiner agrees with Applicant that the cited portion of the prior art failed to disclose this new concept of claim 1. However, upon further consideration, Examiner is unpersuaded that this feature is not taught by Nainar, because it discloses that the service function chain [resource module] includes a forward classifier, wherein the forward classifier stores a forwarding table, wherein the forwarding table includes information associated with the network traffic; see figure 5 forwarding table & ¶ 0029-0030.
For these reasons discussed above the claim is met by the prior art.
Claim Rejections - 35 USC § 102
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)(2) the claimed invention was described in a patent issued under section 151, or in an application for patent published or deemed published under section 122(b), in which the patent or application, as the case may be, names another inventor and was effectively filed before the effective filing date of the claimed invention.
Claims 1-11 and 20 are rejected under AIA 35 U.S.C. 102(a)(2) as being anticipated by Nainar et al. (Publication No. US 2019/0140863, hereinafter referred as Nainar).
Regarding claims 1 and 20, Nainar discloses receiving an uplink data stream packet (Receive network traffic; see figure 7 numeral 704.);
determining a resource module used to process the uplink data stream packet and an identifier of the resource module used to process the uplink data stream packet (Select a service function path (SFP) for the network traffic, wherein the SFPs send the matching network traffic through the service function chain [resource module] in a forward direction [uplink]; see figure 7 numeral 706 & ¶ 0039. Once a particular SFP has been selected, the service function identification is included in the packet; see figure 7 numeral 708 & ¶ 0040. The policy table includes an entry for source/destination addresses for packet, a service function chain ID, and a selected SFP [resource modules]; see figure 5 numeral 114-118 & ¶ 0029. When using the SRv6 protocol for implementing service function chain, the policy table further includes information regarding a stack of SRv6 segments [identifier of the resource module] for implementing the specific SFP selected; see figure 5 numeral 410 & ¶ 0029. For example, the stack of SRv6 segments implementing SFP1 is segments 2001::100; 2001::1; 2001::2; and 2001::200; see figure 5 numeral 424 & ¶ 0030.);
wherein the resource module stores status information associated with processing the data stream (The service function chain [resource module] includes a forward classifier, wherein the forward classifier store a forwarding table, wherein the forwarding table includes information associated with the network traffic; see figure 5 forwarding table & ¶ 0029-0030.);
modifying the uplink data stream packet based on the identifier of the resource module, wherein a modified uplink data packet comprises the identifier of the resource module used to process the uplink data stream packet (The SFP identification information is included in an encapsulation [modifying] header of the packet(s); see figure 7 numeral 710.); and
sending the modified uplink data stream packet (Forward the network traffic with the encapsulated header; see figure 7 numeral 710.).
Regarding claim 2, Nainar discloses determining, based on the received uplink data stream packet, a destination address for processing the uplink data stream packet (Receiving an incoming packet and determining that the packet matches the destination address set in the policy table; see figure 5 numeral 112 & ¶ 0029.); and
determining, from resource modules corresponding to the destination address, the resource module used to process the uplink data stream packet and the identifier of the resource module used to process the uplink data stream packet (The policy table includes an entry for source/destination addresses for packet, a service function chain ID, and a selected SFP [resource modules]; see figure 5 numeral 114-118 & ¶ 0029. When using the SRv6 protocol for implementing service function chain, the policy table further includes information regarding a stack of SRv6 segments [identifier of the resource module] for implementing the specific SFP selected; see figure 5 numeral 410 & ¶ 0029.).
Regarding claim 3, Nainar discloses that the modified uplink data stream packet carries a correspondence between the identifier of the resource module and a service function (SF) (The policy table includes an entry for source/destination addresses for packet, a service function chain ID [SF], and a selected SFP [identifier resource modules]; see figure 5 numeral 114-118 & ¶ 0029.).
Regarding claim 4, Nainar discloses that modifying the uplink data stream packet comprises: adding the correspondence to a segment routing header (SRH) of the uplink data stream packet (When using the SRv6 protocol for implementing service function chain, the policy table further includes information regarding a stack of SRv6 segments for implementing the specific SFP selected; see figure 5 numeral 410 & ¶ 0029. The encapsulated header includes the service path identification information identifying the stack of SRv6 segments implementing the selected SFP used in the forward direction [uplink], wherein the encapsulation header is SRH; see figure 5 numeral 424 & ¶ 0030.).
Regarding claim 5, Nainar discloses that adding the correspondence to the SRH of the uplink data stream packet comprises: adding the correspondence to a segment routing identifier SID in a segment list in the SRH (The encapsulated header includes the service path identification information identifying the stack of SRv6 segments implementing the selected SFP used in the forward direction [uplink], wherein the encapsulation header is SRH; see figure 5 numeral 424 & ¶ 0030. For example, the stack of SRv6 segments implementing SFP1 is segments 2001::100; 2001::1; 2001::2; and 2001::200; see figure 5 numeral 424 & ¶ 0030.); or adding the correspondence to an optional type-length-value TLV field in the SRH.
Regarding claim 6, Nainar discloses searching for a forwarding entry based on the destination address, wherein the forwarding entry comprises the resource modules corresponding to the destination address and identifiers of the resource modules corresponding to the destination address (The policy configured may include at least information to identify a destination address or other defined criteria for matching incoming network traffic to the policy; see figure 7 numeral 702 & ¶ 0038.); and
obtaining, from the forwarding entry, the resource module used to process the uplink data stream packet and the identifier of the resource module used to process the uplink data stream packet (If there is a match, selects one of the multiple SFPs [resource module] to send the matching network traffic through the service function chain in a forward direction [uplink]; see figure 7 numeral 706 & ¶ 0039. When using the SRv6 protocol for implementing service function chain, the policy table further includes information regarding a stack of SRv6 segments [identifier of the resource module] for implementing the specific SFP selected; see figure 5 numeral 410 & ¶ 0029.).
Regarding claim 7, Nainar discloses receiving a protocol packet, wherein the protocol packet carries the destination address and the resource modules corresponding to the destination address; and generating the forwarding entry based on the protocol packet (The BCP flag in encapsulation header of packet causes the reverse classifier to program a policy to select the same SFP listed in encapsulation header for the reverse path of packet and associated traffic; see ¶ 0026. For example, reverse classifier may store a policy table having source/destination addresses for packet, a service function chain ID, and the selected SFP [resource modules]; see ¶ 0026.).
Regarding claim 8, Nainar discloses that the identifier of the resource module is used to uniquely identify the resource module in a service function (SF) to which the resource module belongs, or the identifier of the resource module is used to uniquely identify the resource module in all SFs for processing a data stream (If there is a match, selects one of the multiple SFPs [resource module] to send the matching network traffic through the service function chain in a forward direction [uplink]; see figure 7 numeral 706 & ¶ 0039. When using the SRv6 protocol for implementing service function chain, the policy table further includes information regarding a stack of SRv6 segments [identifier of the resource module] for implementing the specific SFP selected; see figure 5 numeral 410 & ¶ 0029.).
Regarding claim 9, Nainar discloses that after forwarding the modified uplink data stream packet, receiving a downlink data stream packet (The SF2 sends the forward packet to a reverse classifier and receive a reverse packet from the reverse classifier; see figure 4 numeral 131/140. The BCP flag in encapsulation header of the forward packet causes the reverse classifier to program a policy to select the same SFP listed in encapsulation header for the reverse path of the forward packet; see figure 5 numeral 300/403 & ¶ 0031-0032.),
wherein the downlink data stream packet carries the identifier of the resource module used to process the uplink data stream packet (The selected SFP in policy table of reverse classifier follows the return path of first SFP1 [identifier of the resource module]; see figure 5 numeral 300/403 & ¶ 0032.),
a destination address of the downlink data stream packet is a source address of the uplink data stream packet, and a source address of the downlink data stream packet is the destination address of the uplink data stream packet (Additionally, the source/destination addresses for the reverse packet listed in policy table stored at reverse classifier will be reversed from source/destination addresses; see figure 5 numeral 300 & ¶ 0026. In order to establish a bidirectional SFC for the network using the same SFP as the forward classifier; see figure 5 numeral 300 & ¶ 0026.); and
determining, based on the identifier of the resource module used to process the uplink data stream packet, a resource module used to process the downlink data stream packet (The selected SFP [resource module] in policy table of reverse classifier is first SFP1 [identifier], based on the information contained in encapsulation header of the forward packet; see figure 5 numeral 300/403 & ¶ 0026.),
wherein the resource module used to process the downlink data stream packet is the same as the resource module used to process the uplink data stream packet (The resource module [SFP1] are the same given that uses the same path as the forward packet but in the reverse direction; see figure 5 numeral 112/410 & 300/430.).
Regarding claim 10, Nainar discloses determining, based on the received downlink data stream packet, the destination address for processing the downlink data stream packet (The selected SFP in policy table of reverse classifier follows the return path of first SFP1 [identifier of the resource module]; see figure 5 numeral 300/403 & ¶ 0032. Additionally, the source/destination addresses for the reverse packet listed in policy table stored at reverse classifier will be reversed from source/destination addresses; see figure 5 numeral 300 & ¶ 0026. In order to establish a bidirectional SFC for the network using the same SFP as the forward classifier; see figure 5 numeral 300 & ¶ 0026.); and
determining, based on the destination address and the identifier of the resource module used to process the uplink data stream packet, the resource module used to process the downlink data stream packet (The policy table of reverse classifier follows the return path of first SFP (SFP1) [resource module] by reversing the order of the stack of SRv6 segments included in encapsulation header of the forward packet received; see ¶ 0032.).
Regarding claim 11, Nainar discloses that before determining the resource module used to process the downlink data stream packet, adding, to a segment routing header (SRH) of the downlink data stream packet, a correspondence between the identifier of the resource module used to process the uplink data stream packet and a service function (SF) (The policy table of reverse classifier follows the return path of first SFP (SFP1) [resource module] by reversing the order of the stack of SRv6 segments included in encapsulation header of the forward packet received; see ¶ 0032. For example, the stack of SRv6 [SRH] segments for implementing the selected SFP (e.g., first SFP 402 (SFP1)) in the reverse direction is associated with segments 2001::200; 2001::2; 2001::1; and 2001::100; see ¶ 0032.).
Conclusion
THIS ACTION IS MADE FINAL. 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 HECTOR REYES whose telephone number is (571)270-0239. The examiner can normally be reached M-F 6-5.
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, Kevin Bates can be reached on (571) 272-3980. 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.
/H.R/Examiner, Art Unit 2472
/KEVIN T BATES/Supervisory Patent Examiner, Art Unit 2472
Prosecution Insights