DETAILED ACTION
This communication is in response to Application No. 18/033,299 filed on 4/21/2023. The response presented on 4/23/2023 is hereby acknowledged. Claims 22-33 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 .
Allowable Subject Matter
Claims 22-25 and 32 are allowed.
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 26-28, 30, 31, and 33 are rejected under 35 U.S.C. 103 as being unpatentable over Yong et al. (hereinafter Yong)(US 2018/0152374) in view of Chandramouli et al. (hereinafter Chandramouli)(US 2023/0276339)
Regarding claim 26, Yong in view of Chandramouli teaches as follows:
A method performed by a second Service Communication Proxy (SCP) (interpreted as the SFF 112A in figure 2), or a Network Function (NF), comprising:
sending, towards a first SCP (interpreted as the SFF 112B in figure 2), a request message (interpreted as the service change packet 209 in figure 2) comprising original routing path detection information (interpreted as the lop prevention field 220 in figure 2)(after incrementing, SFF 112A forwards the service chain packet 209 to SFF 112B based on the service path identifier 215 in the service header 212, see, ¶ [0039]) wherein the routing path detection information is used to detect dead looping in the routing path (the service chain packet 209 may be additionally encapsulated with an overlay header to be transmitted across overlay nodes in an overlay network. In an embodiment, the overlay header may include a Time-to-Live (TTL) field that may be more than 2 bits. For example, a TTL field may be 8 bits in length. The TTL field may be set by an ingress node on an overlay path to include a value indicating a maximum number of hops for an overlap path that may be used for loop detection, see, ¶ [0068]); and
receiving, from the first SCP, a response message when the request message is rejected by the first SCP (the SFF 112B incremented the value in the loop prevention field 220 to 2, such that when SFF 112C receives the service chain packet 209, the value in the loop prevention field 220 is no longer less than the predefined parameter, which is also 2. The SFF 112C may be configured to discard the service chain packet 209 when the value in the loop prevention field 220 is greater than or equal to the predefined parameter, see, ¶ [0047]).
Yong teaches of discarding the service chain packet but does not explicitly teach of sending a response message.
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 Yong to include sending a notification message upon discarding the packet to previous SFF in order to efficiently update current packet transmission status.
Yong teaches all limitations performed by the SFF (the SFFs 112 are any network nodes or devices, such as router, switches, and/or bridges, configured to forward packets and/or frames received from the network 106 to one or more SNs 115 associated with the SFFs 112 according to information carried in the service header, see, ¶ [0031]) as presented above except for the well-known service communication proxy (SCP).
Chandramouli teaches the well-known service communication proxy (SCP) as follows:
Communication between two entities may take place via a communication proxy. For example, a network function service consumer and a network function service provider may communicate via a service communication proxy (SCP) or security edge protection proxy (SEPP)(see, ¶ [0152]); and
the network function service consumer 400 sends a service request to service agent 400a located in a first SCP 420, where the service requested is provided by a network function service producer 402 with its associated service agent 402a located in a second SCP 422 (see, ¶ [0177] and figure 4e).
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 Yong with Chandramouli to include the well-known service communication proxy (SCP) as taught by Chandramouli in order to efficiently provide communication between a network function service consumer and a network function service.
Regarding claim 27, Yong teaches as follows:
Wherein the original routing path detection information comprises a value indicating a maximum number of allowed intermediate SCPs to relay the message (the TTL field may be set by an ingress node on an overlay path to include a value indicating a maximum number of hops for an overlap path that may be used for loop detection. The initial value in the TTL field may be configurable or specific to one or more overlay paths, see, ¶ [0068]).
Bai teaches the target HTTP server as presented on the rejection of claim 22.
Therefore, it is rejected for similar reason as presented above.
Regarding claim 28, Yong teaches as follows:
The service header 212 may further include a loop prevention field 220 (equivalent to applicant’s routing path detection information). The loop prevention field 220 may be configured to indicate whether an error has occurred during transmission of the data packet 206 across network 106 (see, ¶ [0035]).
Yong does not explicitly teach using the well-known HTTP message.
Chandramouli teaches of exchanging HTTP signaling (see, ¶ [0201]).
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 Yong in view of Chandramouli to include the well-known HTTP message in order to efficiently enhance security and improve performance.
Regarding claim 30, Yong teaches as follows:
The SDN controller 103 (equivalent to applicant’s operating and managing system) makes routing decisions and communicates the routing decisions to all the network devices, such as the classifier 109, the SFFs 112, the SNs 115, and any other network nodes, in the network 106 (see, ¶ [0027]); and
the SDN controller 103 performs SDN management and/or control operations, such as determining forwarding paths in the network 106 and configuring network nodes, such as the classifier 109, the SFFs 112, and the SNs 115, with the forwarding instructions (see, ¶ [0029]).
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 Yong in view of Chandramouli to include updating or fixing misconfiguration for the routing path by the SDN controller in order to efficiently reconfigure the routing path based on the detected looping error.
Regarding claim 31, Yong teaches as follows:
Wherein the original routing path detection information is obtained from one of: a message transmitted from another SCP or NF; or configuration information (a classifier in the network sets an initial value in the loop prevention field to 0 and transmits the service chain packet to an SFF, see, ¶ [0025]).
Regarding claim 33, Yong teaches as follows:
The SFFs 112 are any network nodes or devices, such as router, switches, and/or bridges, configured to forward packets and/or frames received from the network 106 to one or more SNs 115 associated with the SFFs 112 according to information carried in the service header (see, ¶ [0031]).
Chandramouli teaches as follows:
The control apparatus may comprise at least one random access memory (RAM) 211a, at least on read only memory (ROM) 211b, at least one processor 212, 213 and an input/output interface 214. The at least one processor 212, 213 may be coupled to the RAM 211a and the ROM 211b. The at least one processor 212, 213 may be configured to execute an appropriate software code 215 (see, ¶ [0147] and figure 2).
Therefore, they are rejected for similar reason as presented above.
Claim 29 is rejected under 35 U.S.C. 103 as being unpatentable over Yong et al. (hereinafter Yong)(US 2018/0152374) in view of Chandramouli et al. (hereinafter Chandramouli)(US 2023/0276339), and further in view of Puvvada (US 2015/0288591).
Regarding claim 29, Yong teaches as follows:
The service header 212 includes a loop prevention field 220 that indicates whether an error has occurred during transmission of the data packet (see, ¶ [0054] and figure 2).
Yong in view of Chandramouli teaches all limitations as presented above except for the application error indicating a reason of rejecting the request message.
Puvvada teaches as follows:
A response to the transmitted packet may be received at step 250. The response may be an error message, a receipt or acknowledgment, or some other message (equivalent to applicant’s response code or application error). If the transmitted packet has travelled the maximum number of hops as defined by a TTL or other life value without reaching its destination, then the response may include an error message indicating that the packet cannot be transmitted any further (see, ¶ [0023] and figure 2).
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 Yong in view of Chandramouli with Puvvada to include transmitting an error message indicating the packet travelled the maximum number of hops as taught by Puvvada in order to efficiently inform packet transmission status.
Response to Arguments
Applicant’s arguments with respect to claims 26-30, 31, and 33 have been considered but are moot because the limitation on claim 26 is different than the arguments allowed from claim 22. Therefore, claims 26-30, 31, and 33 are maintained same rejection with current prior art references as presented above.
Conclusion
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
June 17, 2026