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 .
Response to Remarks
2. This Office action is considered fully responsive to the amendments filed 03/09/2026.
a) Claims 21-40 are pending in the application, claim 40 has been amended, and claims 21-39 were previously presented.
b) The objection to the claims is withdrawn in light of Applicant’s amendments.
c) The specification objection using the Trademarks is maintaining because the trademarks should be capitalized entirely wherever it appears, or, where appropriate, include a proper symbol indicating use in commerce such as ™, SM, or ® following the term.”
d) The specification objection of the abstract is maintaining because it should be on a separate sheet that may not include any other materials/parts of the application.
Specification Objection
3. There is no abstract of the disclosure to comply 37 CFR 1.72 Title and abstract:
(a) The use of the term Bluetooth, Wi-Fi, WiMAX, Zigbee or Z-Wave which is a trade name or a mark used in commerce, has been noted in this application. The term should be accompanied by the generic terminology; furthermore, the term should be capitalized wherever it appears or, where appropriate, include a proper symbol indicating use in commerce such as ™, SM , or ® following the term.
Although the use of trade names and marks used in commerce (i.e., trademarks, service marks, certification marks, and collective marks) are permissible in patent applications, the proprietary nature of the marks should be respected and every effort made to prevent their use in any manner which might adversely affect their validity as commercial marks.
(b) A brief abstract of the technical disclosure in the specification must commence on a separate sheet, preferably following the claims, under the heading “Abstract” or “Abstract of the Disclosure.” The sheet or sheets presenting the abstract may not include other parts of the application or other material. The abstract must be as concise as the disclosure permits, preferably not exceeding 150 words in length. The purpose of the abstract is to enable the Office and the public generally to determine quickly from a cursory inspection the nature and gist of the technical disclosure.
A corrected abstract of the disclosure is required and must be presented on a separate sheet, apart from any other text. See MPEP § 608.01(b).
Response to Arguments
4. Applicant's arguments filed on 03/09/2026 have been fully considered but they are not persuasive. The applicant argues that:
Song does not teach control plane configuration protocols between an orchestrator and a classifier. (Pages 10-11, Remarks).
In response to A), the examiner respectfully disagrees. Song explicitly teaches in [0070] the control plane as a part of router architecture that responsible for collecting distributing/ propagating the data used for forwarding incoming packets, as stated “The control plane of an MPLS network (e.g., 200) is the part of the router architecture that is responsible for collecting and propagating the information that will be used later to forward incoming packets.” and further stated “Routing Protocols and label distribution protocols are parts of the control plane. The control plane is responsible for exchanging layer 3 routing information and labels.” Which provides the including of routing protocols and label distribution protocols, that are important components for the control plane orchestration as the control plane is responsible on exchanging routing information and labels. [0096] lines 3-7 and [0112] lines 1-4 illustrate how the improvement and orchestration in the control plane in managing and propagating new label values, as an example. [0070] also states “The network controller 212 can be used to perform a variety of control path and/or control plane functions.” That implies the network controller, can be considered as a orchestrator in modern network architecture such as SDN, (which uses standard protocols) to perform the control plane functions, see [0114] lines 15-17, Fig.2 and [0070], as stated “FIG. 2 also illustrates a network controller 212 that is communicatively coupled to each of the routers 210 of the MPLS network 200, as represented in dashed lines.” [0111] and [0121] provide examples on control plane configuration to ensure coordination of the network. See also [0089] describes how the service classifier added NSH to packet for service function chaining, which is the role of the classifier to add NSH that contains service plane protocol specifically for the creation of dynamic service chains and is composed of the following elements: Service Function Path identification; indication of location within a Service Function Path; and optional per packet metadata (fixed length or variable), as stated in [0089], see also [0130]. Therefore, the office action still teach the limitations as currently claimed.
The office action does not teach bidirectional request-response messaging. (Page 12, Remarks).
In response to applicant's argument B) that the references fail to show certain features of the invention, it is noted that the features upon which applicant relies (i.e., bidirectional request-response messaging) are not recited in the rejected claim(s). Although the claims are interpreted in light of the specification, limitations from the specification are not read into the claims. See In re Van Geuns, 988 F.2d 1181, 26 USPQ2d 1057 (Fed. Cir. 1993).
The combination of the references does not teach the integrated orchestration workflow of claim 21, the vertical integration of claim 21 across protocol layers or the horizontal integration across orchestration phases that claim 21recites. (Pages 13-14, Remarks).
In response to applicant's argument C) that the references fail to show certain features of the invention, it is noted that the features upon which applicant relies (i.e., the integrated orchestration workflow of claim 21, the vertical integration of claim 21 across protocol layers or the horizontal integration across orchestration phases) are not recited in the rejected claim(s). Although the claims are interpreted in light of the specification, limitations from the specification are not read into the claims. See In re Van Geuns, 988 F.2d 1181, 26 USPQ2d 1057 (Fed. Cir. 1993).
The Office Action does not explain how Flinck's description of types of information that can exist in a shared database teaches that these specific information elements would be included in a request message, nor does the Office Action explain the transformation from Flinck's database schema to the message format of claim 22. (Page 14, Remarks)
In response to D), the examiner respectfully disagrees. Flinck teaches in [0033], Fig. 6 and [0053], “the shared context is implemented as a black board (shared data structure) between the participating SFs.” Which means the shared database (shared data structure/black board) can be updated by the service functions or SFC controller, including metadata of NSH of the user plane packets, as stated in claim 3 and [0071], that means the shared data/information (context, rules, polices) can be mapped in the metadata field of NSH, as stated in [0011] “a context can also have dynamically changing components that depend on user feedback or flow/stream of user plane packets and other attributes like quota of used resources. Context information is a superset of metadata carried in the NSH. But the metadata in NSH is delivered only to downstream service functions following the flow of packets as illustrated in FIG. 11. “ and claims 1 and 3. which implies the shared context in SFC may include dynamically changing components such as quota of used resources depend on the status (user feedback/ traffic flow), see also [0014], lines 3-7. [0010], [0072] and claim 4 illustrate how the classifier can add the NSH to the packets by encapsulate them with service chain for correct redirection, as stated “The classifier may add a service chain encapsulation including a Network Service Header (NSH) to the redirected user plane packets.” Where [0037 ]states “Shared context captures, e.g., UE, application and service provider criteria used in context aware conditionality,” see also [0039]-[0040] , that indicated the ability of capturing the device specific, user specific, service specific, time specific, location specific or even any combination of those, so that the outcome of conditionality guides the acceptance to proceed with the service provided by SFC user plane. That explains the different types of information can exist in a shared database and the transformation of database format. Therefore, the office action still teach the limitations as currently claimed.
The office action does not specifically teach that the xNB or eUPF entities provide the SFC classifier function, claim 24. (Page 15, Remarks)
In response to E), the examiner respectfully disagrees. Lake provides that the SFC classifier can be in any point of the network, as stated in Page. 5 Para. 5, “Classification and reclassification of traffic can occur at any point in the network “ , which implies the classifier can be provided by xNB or eUPF, and the Page. 5 Para. 5 further describes such headers can be inserted from either a centralized or distributed control plane using the Software-Defined Networking (SDN) paradigm including extensions to SDN controllers such as OpenDaylight and software switches such as Open vSwitch (or programable switch). Fig. 7, describe the enhanced UPF can provide the FSC classifier and flexible service chaining, Para. 8, page. 19, states “Whilst the software forwarding plane remains in the virtual environment and therefore running in software, the programming of the UPFs from the 5G control-plane is also sent to the network programming layer which controls an FPGA-based hardware switch” and Para. 3, page 17, states “Deploying the TEID components in an accelerated data-plane, for example by programming TEID forwarding directly into DPDK as the authors have done”, these sections confirm enhancing UPF to include SFC classifier capabilities by deploying and programming TEID to classify traffic of service path and enable dynamic chaining function. Therefore, the office action still teach the limitations as currently claimed.
The office action does not teach the specific architecture where different filters are configured into different eUPF instances based on analysis of which SFs are topologically or logically reachable from each respective eUPF, claim 30. (Pages 15-16, Remarks).
In response to applicant's argument F) that the references fail to show certain features of the invention, it is noted that the features upon which applicant relies (i.e., based on analysis of which SFs are topologically or logically reachable) are not recited in the rejected claim(s). Although the claims are interpreted in light of the specification, limitations from the specification are not read into the claims. See In re Van Geuns, 988 F.2d 1181, 26 USPQ2d 1057 (Fed. Cir. 1993).
Applicant argues that the independent claims 21, 37, 39 are allowable for similar reasons (Page 14, Remarks).
Examiner respectfully disagrees, for at least the same reasons given in the response above, and as detailed in the Claim Rejections section.
H) Applicant argues that the remaining claims, dependent claims are allowable for similar reasons (Page 14-15, Remarks).
Examiner respectfully disagrees, for at least the same reasons given in the response above, and as detailed in the Claim Rejections section.
Claim Rejections - 35 USC § 103
5. 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 factual inquiries 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.
This application currently names joint inventors. In considering patentability of the claims the examiner presumes that the subject matter of the various claims was commonly owned as of the effective filing date of the claimed invention(s) absent any evidence to the contrary. Applicant is advised of the obligation under 37 CFR 1.56 to point out the inventor and effective filing dates of each claim that was not commonly owned as of the effective filing date of the later invention in order for the examiner to consider the applicability of 35 U.S.C. 102(b)(2)(C) for any potential 35 U.S.C. 102(a)(2) prior art against the later invention.
6. Claims 21-24, 26-32, and 37-40 are rejected under 35 U.S.C. 103 as being unpatentable over Lake et al. (Softwarization of 5G Networks-Implications to Open Platforms and Standardizations) in view of Flinck et al. (US-20190222521-A1) and further in view of Song et al. (US-20200358698-A1).
Regarding claim 21 (Previously Presented), Lake teaches an apparatus for a Service Orchestration and Chaining Function (SOCF) (Section SFC, pages 5-6, discuses the SFC for enabling the orchestrating / organizing service functions for end to end delivery,“) configured for operation in a 6th generation (6G) network (Fig. 7, Para. 1, page 8, states “Within the mobile packet core for 5G and beyond, the multi-tenancy solution is seen as analogous to the Network Slicing portions of the 5G system architecture with the same goal of allowing a single set of hardware to appear as several different, logically-separated environments” and Para. 3, page 20, states “Supporting the development of both the RAN and Packet Core in 5G and beyond are an array of SDOs… This chapter not only surveys and summarizes each of the relevant SDOs to the development of 5G and future packet-core technologies, but also offers a commentary on the operation and basic rules-of-engagement of each to assist the reader in determining how best to contribute to the groups.” implies the development in RAN and packet core in 5G and beyond is directly related the enhancement of NodeB (xNB) in future network like 6G, Para. 2, page 24, and Para. 2, page 14).
Lake does not disclose the apparatus comprising: processing circuitry to configure the SOCF to orchestrate and configure Service Functions (SFs ), the processing circuitry to: send, to a control function (CF), a Service Function Chaining (SFC) request for the CF to perform SF selection and configure the SFs, the processing circuitry to: send, to a control function (CF), a Service Function Chaining (SFC) request for the CF to perform SF selection and configure the SFs.
However, Flinck teaches the apparatus comprising: processing circuitry to configure the SOCF to orchestrate and configure Service Functions (SFs ) (Fig. 1, [0034], lines 3-6, a schematic block diagram illustrates a configuration of a control unit 10 “in which the condition function is implementable. The control unit 10 comprises processing resources 11 (e.g. processing circuitry), memory resources 12 (e.g. memory circuitry), and interfaces 13 (e.g. interface circuitry). The memory resources 12 may store a program that when executed by the processing resources 11 enable the control unit 10 to operate in accordance with the exemplary embodiments of this invention”, [0001] and [0014], describes the configuration/ adjusting of SFs involves different steps, [0078]-[0080]), the processing circuitry to: send, to a control function (CF), a Service Function Chaining (SFC) request for the CF to perform SF selection and configure the SFs ([0032], lines 4-5 “control function referred to as “condition function”. [0033], lines 9-12, “The condition function reads (receives) the shared context and acts based on service specific rules and policies associated with the read shared context to adjust traffic flow across the whole service function chain”, which implies the CF can perform and configure the whole SFC not just a single SF in the SFC, [0014], lines 1-7); receive, from the CF in response to transmission of the SFC request, an SFC response that includes information of the SFs ([0033]-[0034], The condition function reads the shared context and acts based on service specific rules and policies associated with the read shared context to adjust traffic flow across the whole service function chain. [0051], FIG. 5 further shows the condition function 30 which controls the SFs, e.g. configures the SF2 with a run time condition. “The SF2 implements the run time condition and based on how its condition is satisfied, it decides either to forward the user plane packets towards the SF3 or to redirect them back to the default path” which implies the CF sends the SFC response with information about SFs, Claims 22-23, ); and a memory configured to store the information of the SFs (Fig. 1, [0034], The memory resources 12 may store a program that when executed by the processing resources 11 enable the control unit 10 to operate functions of the method).
Therefore, it would have been obvious to someone of ordinary skill in the art before the effective filing date of the claimed invention to have modified Lake to incorporate the teachings of Flinck (in analogous art) by sending, to a control function (CF), a Service Function Chaining (SFC) request for the CF to perform SF selection and configure the SFs to enable dynamic context-aware and efficient management of SFC which enhance the performance and resource utilization in the network (Flinck , [0014]).
Lake and Flinck do not teach generate, based on information in the SFC response, a Segment Routing (SR) label; send, to a SFC classifier, an SR label request to configure the SR label; and receive, from the SFC classifier in response to transmission of the SR label request, an SR label response that includes a status of a configuration of the SR label.
However, Song teaches generate, based on information in the SFC response, a Segment Routing (SR) label (Fig. 4, [0158], lines 1-4, describes the generating the SR labels by supporting SFC information, [0142], lines 5-10, and [0027], sates “he MPLS label stack includes a plurality of label stack entries with a label stack entry at a top of the MPLS label stack including a SID used to forward the packet to the router, and the SRH type MPLS extension header includes one or more SIDs that collectively provide a SID list for use in segment routing”, which implies the generating of SR label based on updated SFC information); send, to a SFC classifier, an SR label request to configure the SR label ([[0089], states “A Service Classifier adds NSH.” Where NSH is “Network Service Header (NSH) contains service path information and optionally metadata that are added to a packet or frame and used to create a service plane” which implies the classifier can configure the SR label); and receive, from the SFC classifier in response to transmission of the SR label request, an SR label response that includes a status of a configuration of the SR label ([0034], “The SRH type MPLS extension header includes one or more SIDs that collectively provide a SID list for use in segment routing. The one or more processors also execute the instructions to copy one of the one or more SIDs in the SRH type MPLS extension header to the top of the MPLS label stack, and forward the packet to another router of the MPLS network based on the one of the one or more SIDs included in the label stack entry at the top of the MPLS label stack”, this implies SRH includes SIDs, which are essentially SR labels and provides the routing configuration of the packet, update it and forward the packet to another MPLS network).
Therefore, it would have been obvious to someone of ordinary skill in the art before the effective filing date of the claimed invention to have modified Lake in view of Flinck to incorporate the teachings of Song (in analogous art) by generating, based on information in the SFC response, a Segment Routing (SR) label to avoids the need for hop-by-hop routing decisions to be made on the IP layer network address, instead traffic is sent along a path predetermined by a particular set of labels. (Song , [0005]).
Regarding claim 22 (Previously Presented), Lake, Flinck and Song teach the apparatus of claim 21.
Lake and Song do not teach, but Flinck teaches, wherein the SFC request includes: a number of communication (Comm) SF types, domain, and processing rate for Comm CF ([0040], describes the shared context in the SFC (request/response) may have a special scope like device specific, user specific, service specific ([0010], lines 17-21, gives examples on the comm SF types, [0061], lines 7-9) , time specific (which related to processing rate for required service and traffic flow across the SFC ), location specific ([0014], lines 9-11, gives example on domain/certain location) or even any combination of those), requirements on a status of a Comp SF, including resource occupancy ([0011], lines 10-12, states “ a context can also have dynamically changing components that depend on user feedback or flow/stream of user plane packets and other attributes like quota of used resources, “ which implies the shared context in SFC may include dynamically changing components such as quota of used resources depend on the status (user feedback/ traffic flow), [0014], lines 3-7), and requirements on a data SF including pre-processing and labeling ([0042]-[0046] and claim 1 states “providing a shared context comprising rules and policies for processing the user plane packets, the shared context being shared between the service functions of the service function chain; reading the shared context; and adjusting traffic flow across the service function chain based on the rules and policies associated with the read shared context.” Which implies modification the data to match the policies and the roles required of the shared context).
Therefore, it would have been obvious to someone of ordinary skill in the art before the effective filing date of the claimed invention to have modified Lake in view of Song to incorporate the teachings of Flinck (in analogous art) by sending, to a control function (CF), a Service Function Chaining (SFC) request for the CF to perform SF selection and configure the SFs to enable dynamic context-aware and efficient management of SFC which enhance the performance and resource utilization in the network (Flinck , [0014]).
Regarding claim 23 (Previously Presented), Lake, Flinck and Song teach the apparatus of claim 21.
Lake and Song do not teach, but Flinck teaches wherein at least one of:
a configuration of each of the SFs includes: SFC session-related information including a
session identifier (ID), a session type, and quality of service (QoS); SFC packet filter and traffic
processing rules; and parameters of the SF, or
the information of each of the SFs includes ([0037], [0053], the SFs update their status/ information in the database directly and can include): an identifier (ID) of the SF (Figs 3-11, illustrates that each SF has identifier, which implies that SFs are uniquely identifiable within SFC, as they are referenced individually (e.g., SF1, SF2, SF3), a sequence of the SF ([0051], states “As illustrated in FIG. 5, the SFC comprises SFs SF1 → SF2 → SF3, and a classifier identifies user plane packets to be redirected to the SFC.” This suggest the SFs are sequenced within the chain), metadata associated with the SF ([0011] describes Context information is a superset of metadata carried in the NSH, which is updated by the SFs, as illustrated in FIG. 11).
Therefore, it would have been obvious to someone of ordinary skill in the art before the effective filing date of the claimed invention to have modified Lake in view of Song to incorporate the teachings of Flinck (in analogous art) by sending, to a control function (CF), a Service Function Chaining (SFC) request for the CF to perform SF selection and configure the SFs to enable dynamic context-aware and efficient management of SFC which enhance the performance and resource utilization in the network (Flinck , [0014]).
Lake further teaches and a security key to access the SF (Para. 17, page 11, “management of user and instance identity, authentication and authorization including interfaces to external databases via LDAP”, in order to satisfy with requirements of service isolation and security, as states in Para. 4, page 4 and Para. 5, page 26 “Coupled with this are the requirements are service isolation and security”. That’s imply using secure entrance for the system).
Regarding claim 24, (Previously Presented) Lake, Flinck and Song teach the apparatus of claim 21.
Lake further teaches wherein a Radio Access Network NodeB (xNB) or an enhanced user plane function ( eUPF) provides the SFC classifier ( It provides that the SFC classifier can be in any point of the network, as stated in Page. 5 Para. 5, “Classification and reclassification of traffic can occur at any point in the network “ , which implies the classifier can be provided by xNB or eUPF, and the Page. 5 Para. 5 further describes such headers can be inserted from either a centralized or distributed control plane using the Software-Defined Networking (SDN) paradigm including extensions to SDN controllers such as OpenDaylight and software switches such as Open vSwitch (or programable switch). Fig. 7, describe the enhanced UPF can provide the FSC classifier and flexible service chaining, Para. 8, page. 19, states “Whilst the software forwarding plane remains in the virtual environment and therefore running in software, the programming of the UPFs from the 5G control-plane is also sent to the network programming layer which controls an FPGA-based hardware switch” and Para. 3, page 17, states “Deploying the TEID components in an accelerated data-plane, for example by programming TEID forwarding directly into DPDK as the authors have done”, these sections confirm enhancing UPF to include SFC classifier capabilities by deploying and programming TEID to classify traffic of service path and enable dynamic chaining function).
Regarding claim 27 (Previously Presented), Lake, Flinck and Song teach the apparatus of claim 21.
Lake further teaches wherein traffic steering rules for an SFC path that includes a plurality of at least one of Radio Access Network NodeBs (xNBs), enhanced user plane function (eUPFs) (Fig. 7 and Para. 5, page 19, states “further show that in specific cases where traffic is being passed between two-or-more UPFs in a virtualized environment, performance is greatly impacted both in terms of throughput and RTT.” Which describes traffic steering rules using plurality eUPFs), and Communication (Comm) SFs are provided in the SR label request,
and the traffic steering rules include at least one of: identifiers of a destination for packets to be forwarded, and a next function to which to steer traffic along the SFC path (Para. 3, page 5, “Service Function Chaining (SFC) is a technology which allows both topological and transport independence from the underlying hardware by defining the end-to-end delivery of services through an ordered set of defined service functions”, which defines an ordered set of service functions, meaning the traffic steering rules must include the next /destination function in the chain to ensure proper routing, Para. 4, page 5), whether to skip a particular SF based on network status, whether to split traffic to different SF instances based on the network status.
Regarding claim 28 (Previously Presented), Lake, Flinck and Song teach the apparatus of claim 21,
Lake further teaches wherein: traffic steering rules are provided as SFC packet filters in a SFC service layer of the SFC classifier (Para. 4, page 5, illustrates NSH is part of SFC service layer, Para. 5, page 5 states “NSH also provides metadata to the control plane to indicate suitability/operation of a network path. All SFC techniques require effective traffic classification”, which implies the traffic classification and steering can involve information /packet filters), and the SFC service layer is independent of an underlying transport network (Para. 4, page 5 “Service Function Chaining (SFC) is a technology which allows both topological and transport independence from the underlying hardware by defining the end-to-end delivery of services through an ordered set of defined service functions”, this independence design allows the service layer to operate separately from transport network“), and the SFC service layer is at a packet data unit (PDU) layer (Para. 3, page 6, illustrates the packets are processed and forwarded using service function and based on their headers and metadata, where NSH is part of SFC service layer, Para. 4, page 5).
Regarding claim 29 (Previously Presented), Lake, Flinck and Song teach the apparatus of claim 21.
Lake teaches wherein: traffic steering rules are provided as SFC packet filters in a SFC service layer of the SFC classifier (Para. 4, page 5, illustrates NSH is part of SFC service layer, Para. 5, page 5 states “NSH also provides metadata to the control plane to indicate suitability/operation of a network path. All SFC techniques require effective traffic classification,” implies the traffic classification and steering can involve information /packet filters), and the SFC service layer is independent of an underlying transport network (Para. 4, page 5 “Service Function Chaining (SFC) is a technology which allows both topological and transport independence from the underlying hardware by defining the end-to-end delivery of services through an ordered set of defined service functions”, this independence design allows the service layer to operate separately from transport network“), and the processing circuitry is to configure the SFC packet filters at a time of setting up SFC service or packet data unit (PDU) sessions (Fig. 7 and Para. 8, page 19 depicts the SDN controller (processing circuitry is responsible for programming the hardware and software changes with necessary filters and forwarding rules, which can be occur at any time/point in the network, “Classification and reclassification of traffic can occur at any point in the network” Para. 5, page 5).
Regarding claim 30 (Previously Presented), Lake, Flinck and Song teach the apparatus of claim 21.
Lake teaches wherein: traffic steering rules are provided as SFC packet filters in a SFC service layer of the SFC classifier(Para. 4, page 5, illustrates NSH is part of SFC service layer, Para. 5, page 5 states “NSH also provides metadata to the control plane to indicate suitability/ operation of a network path. All SFC techniques require effective traffic classification,” implies the traffic classification and steering can involve information /packet filters), and the SFC service layer is independent of an underlying transport network (Para. 4, page 5 “Service Function Chaining (SFC) is a technology which allows both topological and transport independence from the underlying hardware by defining the end-to-end delivery of services through an ordered set of defined service functions”, this independence design allows the service layer to operate separately from transport network“), and the processing circuitry is to configure different SFC packet filters into different enhanced user plane functions (eUPFs) to steer traffic through SFs that are reachable from each of the eUPFs (Fig. 7, Para. 8, page 19 states “Whilst the software forwarding plane remains in the virtual environment and therefore running in software, the programming of the UPFs from the 5G control-plane is also sent to the network programming layer which controls an FPGA-based hardware switch. A decision can be taken at network forwarding time as to whether the packet should transition the switch to the software forwarding elements or be ``cut-through'' in the hardware switch.” This indicates the controller, processing circuitry, configures a packet filters in the eUPFs to direct traffic appropriately. Para. 5, page 5, indicates that the controller dynamically configures filters in eUPFs to steer traffic through reachable SFs).
Regarding claim 31 (Previously Presented), Lake, Flinck and Song teach the apparatus of claim 21.
Lake further teach wherein: traffic steering rules are provided as SFC packet filters in a SFC service layer of the SFC classifier (Para. 4, page 5, illustrates NSH is part of SFC service layer, Para. 5, page 5 states “NSH also provides metadata to the control plane to indicate suitability/operation of a network path. All SFC techniques require effective traffic classification,” implies the traffic classification and steering can involve information/packet filters), and the SFC service layer is independent of an underlying transport network (Para. 4, page 5 “Service Function Chaining (SFC) is a technology which allows both topological and transport independence from the underlying hardware by defining the end-to-end delivery of services through an ordered set of defined service functions”, this independence design allows the service layer to operate separately from transport network“),
Lake and Song do not teach and each SFC packet filter comprises at least one of: information in the SFC service layer), transport identifiers for a traffic path source and destination internet protocol (IP) address.
However, Flinck teaches each SFC packet filter comprises at least one of: information in the SFC service layer ([0010], lines 8-10, [0011], lines 13-16 states “Context information is a superset of metadata carried in the NSH. But the metadata in NSH is delivered only to downstream service functions following the flow of packets as illustrated in FIG. 11.” Which indicates that the SFC packet does include information in the SFC service layer through the NSH metadata), transport identifiers for a traffic path ([0010], describes the classifier may add a service chain encapsulation a NSH which carries metadata related to packet transport already used by the forwarding/redirected user plane packets, [0011], lines 13-16 implies the metadata includes transport identification (transport related information) that necessary for steering traffic for SFC ), source and destination internet protocol (IP) address ([0011],lines 6-9, describes that simple packet classification may base on using a five tuple of packet headers, which is standard terminology in networking, can includes source/destination IP addresses and source/destination ports and transport protocol), or IPv6 prefix, source and destination port number, protocol identifier (ID) of a protocol above an IP or next header type, a type of service or traffic class and mask, a flow label, a security parameter index, and a packet filter direction.
Therefore, it would have been obvious to someone of ordinary skill in the art before the effective filing date of the claimed invention to have modified Lake in view of Song to incorporate the teachings of Flinck (in analogous art) by sending, to a control function (CF), a Service Function Chaining (SFC) request for the CF to perform SF selection and configure the SFs to enable dynamic context-aware and efficient management of SFC which enhance the performance and resource utilization in the network (Flinck, [0014]).
Regarding claim 32 (Previously Presented), Lake, Flinck and Song teach the apparatus of claim 21.
Lake further teaches wherein: traffic steering rules are provided as SFC packet filters in a SFC service layer of the SFC classifier(Para. 4, page 5, illustrates NSH is part of SFC service layer, Para. 5, page 5 states “NSH also provides metadata to the control plane to indicate suitability/operation of a network path. All SFC techniques require effective traffic classification,” implies the traffic classification and steering can involve information /packet filters), and the SFC service layer is independent of an underlying transport network (Para. 4, page 5 “Service Function Chaining (SFC) is a technology which allows both topological and transport independence from the underlying hardware by defining the end-to-end delivery of services through an ordered set of defined service functions”, this independence design allows the service layer to operate separately from transport network“), and the processing circuitry is to configure a session management function (SMF) to configure an enhanced user plane function (eUPF) with SFC packet filter (Figs. 1 and 7 illustrates the relation between the SMFs to control the UPFs with SFC packet filter, Table 2 describe the trade-offs between the flexibility and the performance in various virtualization techniques , which directly impact the SMF capability to handle/manage the sessions, Para. 4, page 25, Para. 7, page 19, Para. 3, page 19) and SF forwarding rules using a Packet Forwarding Control Protocol (PFCP) with tunnel endpoint identifiers (TEIDs) as SR labels (para. 6, page 23, “draft-ietf-dmm-fpc-cpdp [151] is an active draft discussing standardization of the Protocol for Forwarding Policy Configuration (PFPC) which provides separation between the control-plane and data-planes in a packet core. Note, this should NOT be confused with the 3GPP Packet Forwarding Control Protocol (PFCP) TS 29.244 [152] which provides forwarding programming” and Para. 2, page 10 states “it currently only acts on the available OpenFlow matching paradigm which does not extend to the TEID or the inner-tunnel details as with the extended Open vSwitch above and as would be required in current 5G UPF implementations” and para. 8, page 19, illustrates any changes of header, for example SFC label or TEID, is programmed into the switch by the Data Plane SDN Controller.)
Regarding claim 37 (Previously Presented), Lake teaches an apparatus for a Radio Access Network NodeB (xNB) configured for operation in a 6th generation (6G) network (Fig. 7, Para. 1, page 8, states “Within the mobile packet core for 5G and beyond, the multi-tenancy solution is seen as analogous to the Network Slicing portions of the 5G system architecture with the same goal of allowing a single set of hardware to appear as several different, logically-separated environments” and Para. 3, page 20, states “Supporting the development of both the RAN and Packet Core in 5G and beyond are an array of SDOs” implies the development in RAN and packet core in 5G and beyond is directly related the enhancement of NodeB (xNB) in future network like 6G, Para. 2, page 24, and Para. 2, page 14),
Lake fail to teach the apparatus comprising: processing circuitry to configure the xNB to ): receive traffic forwarding rules provided by a Service Orchestration and Chaining Function (SOCF), the traffic forwarding rules to steer traffic to different Service Functions (SFs) based on identifiers of the SFs, receive data from a user equipment (UE), and steer the data for Service Function Chaining (SFC) on a user plane based on the traffic forwarding rules, and a memory configured to store the traffic forwarding rules.
However, Flinck teaches the apparatus comprising: processing circuitry to configure the xNB to (Claim 19, describes apparatus comprising: at least one processor; and at least one memory including computer program code, the at least one memory and the computer program code configured to, with the at least one processor, cause the apparatus at least to perform the functions of the method): receive traffic forwarding rules provided by a Service Orchestration and Chaining Function (SOCF) (Claim 19 describes the apparatus configure to reading (receiving) the shared context; and adjusting traffic flow across the service function chain based on the rules and policies associated with the read shared context), the traffic forwarding rules to steer traffic to different Service Functions (SFs) based on identifiers of the SFs (Claims 19, 23 and 24, illustrates the apparatus can request a policy and charging rules function to adjust the traffic and service steering related policies and rules in the traffic steering support function and adjusting traffic and service steering related policies and rules in a traffic steering support function for different SFs based on identifier [0010], lines 4-10, and [0043]-[0044]); receive data from a user equipment (UE) ([0037], states “ Shared context captures, e.g., UE, application and service provider criteria used in context aware conditionality.” And [0066] and[ 0066], describes that the apparatus can receive data from the UE “An AF (Application Function) communicates with a UE and collects user input to the context aware conditionality”); and steer the data for Service Function Chaining (SFC) on a user plane based on the traffic forwarding rules (Fig. 12, [0066], [0076]-[0078] and claim 19, these paragraphs illustrate the process of service and traffic steering across the SFC); and a memory configured to store the traffic forwarding rules (Fig. 1, [0034] and claim 20, illustrate memory and the computer program code are configured to, with the at least one processor, perform: acquiring at least one of status and context information from the service functions to generate and update the shared context, which include traffic forwarding rules).
Therefore, it would have been obvious to someone of ordinary skill in the art before the effective filing date of the claimed invention to have modified Lake to incorporate the teachings of Flinck (in analogous art) by sending, to a control function (CF), a Service Function Chaining (SFC) request for the CF to perform SF selection and configure the SFs to enable dynamic context-aware and efficient management of SFC which enhance the performance and resource utilization in the network (Flinck , [0014]).
Regarding claim 38 (Previously Presented), Lake and Flinck teach the apparatus of claim 37.
wherein the processing circuitry is to use at least one of:
Lake and Flinck fail to teach, but Song teaches an SFC inherent SR protocol stack in which ([0158], states “Service Function Chaining (SFC) can be supported using SR that is implemented using an MPLS Extension Header with advantages over SFC supported by conventional SR-MPLS”, and [0159] describes the Segment Routing (SR) and NSH functionality can be integrated to better support SFC, which confirm this limitation) first SFC-related information is carried as a locator: function field in Segment Routing Header (SRH) (Abstract discloses “The SRH type MPLS extension header includes one or more segment identifiers (SIDs) that collectively provide a SID list for use in segment routing”, these SIDs acts as locator for specific nodes/ SFs, [0017], line 5-10 and [0158], lines 1-4) and second SFC-related information is contained in a type-length-value (TLV) field of the SRH ([0158], explicitly discloses “ metadata (that is useful for message passing and/or information sharing between service functions) can be carried in the optional TLV field 1014 in the SRH.” [0159], lines 6-10, NSH integration with segment routing SR to get better support SFC), the first SFC-related information comprising the Comm SF and identification of SFs reachable from the Comm SF (Abstract discloses “The SRH type MPLS extension header includes one or more segment identifiers (SIDs) that collectively provide a SID list for use in segment routing” where the segment list is a series of segment IDs or SIDs which re[present the path/traffic through specific/comm SFs, [0017], also states “For each SID, of the one or more SIDs included in the SRH type MPLS extension header, content of the corresponding function and argument field includes instructions and parameters for use in network programming associated with a segment specified by the SID”).
And separate SFC service layer and transport protocols in which transport uses identifiers of
different enhanced user plane functions (eUPFs) and communication (Comm) SFs,
transport protocols that are integrated with SFC-related information in which a General
Packet Radio Service (GPRS) Tunneling Protocol (GTP)-user (GTP-U) header or a Segment
Routing Header (SRH) has type-length-value (TL V) fields contains the SFC-related information.
Therefore, it would have been obvious to someone of ordinary skill in the art before the effective filing date of the claimed invention to have modified Lake in view of Flinck to incorporate the teachings of Song (in analogous art) by generating, based on information in the SFC response, a Segment Routing (SR) label to avoids the need for hop-by-hop routing decisions to be made on the IP layer network address, instead traffic is sent along a path predetermined by a particular set of labels. (Song , [0005]).
Regarding claim 39 (Previously Presented), Flinck teaches a non-transitory computer-readable storage medium that stores instructions for execution by one or more processors of a Service Orchestration and Chaining Function (SOCF) (claim 16 discloses a computer program product embodied on a non-transitory computer-readable medium, the product including a program for a control unit, comprising software code portions for performing the steps of SFC method when the program is run on the control unit), the one or more processors to configure the SOCF to, when the instructions are executed (Claim 19 states “the apparatus comprising: at least one processor; and at least one memory including computer program code, the at least one memory and the computer program code configured to, with the at least one processor”, cause the apparatus at least to perform the functions of the SFC method): send, to a control function (CF), a Service Function Chaining (SFC) request for the CF to perform Service Function (SF) selection and configure SFs ([0032], lines 4-5 “control function referred to as “condition function”. [0033], lines 9-12, “The condition function reads (receives) the shared context and acts based on service specific rules and policies associated with the read shared context to adjust traffic flow across the whole service function chain”, which implies the CF can perform and configure the whole SFC not just a single SF in the SFC, [0014], lines 1-7); receive, from the CF in response to transmission of the SFC request, an SFC response that includes information of the SFs ([0033]-[0034], The condition function reads the shared context and acts based on service specific rules and policies associated with the read shared context to adjust traffic flow across the whole service function chain. [0051], FIG. 5 further shows the condition function 30 which controls the SFs, e.g. configures the SF2 with a run time condition. “The SF2 implements the run time condition and based on how its condition is satisfied, it decides either to forward the user plane packets towards the SF3 or to redirect them back to the default path” which implies the CF sends the SFC response with information about SFs, Claims 22-23).
Flinck fails to teach configured for operation in a 6th generation (6G) network.
However, Lake teaches configured for operation in a 6th generation (6G) network (Fig. 7, Para. 1, page 8, states “Within the mobile packet core for 5G and beyond, the multi-tenancy solution is seen as analogous to the Network Slicing portions of the 5G system architecture with the same goal of allowing a single set of hardware to appear as several different, logically-separated environments” and Para. 3, page 20, states “Supporting the development of both the RAN and Packet Core in 5G and beyond are an array of SDOs” and Para. 5, page 16 states “Assuming that the issue of optimal function placement can be overcome or at least better understood as the packet core scales to support 5G and beyond, concerns over the packet forwarding capabilities of the elements in the core remain”, implies the development in RAN and packet core in 5G and beyond is directly related the enhancement of NodeB (xNB) in future network like 6G, Para. 2, page 24, and Para. 2, page 14).
Therefore, it would have been obvious to someone of ordinary skill in the art before the effective filing date of the claimed invention to have modified Flinck to incorporate the teachings of Lake (in analogous art) by configured for operation in a 6th generation (6G) network to align with ongoing standarazation effort by 3GPP (Lake , Para. 3, page 22).
Lake and Flinck fail to teach generate, based on information in the SFC response, a Segment Routing (SR) label ); send, to a SFC classifier, an SR label request to configure the SR label and receive, from the SFC classifier in response to transmission of the SR label request, an SR label response that includes a status of a configuration of the SR label.
However, Song teaches generate, based on information in the SFC response, a Segment Routing (SR) label (Fig. 4, [0158], lines 1-4, describes the generating the SR labels by supporting SFC information, [0142], lines 5-10, and [0027], sates “he MPLS label stack includes a plurality of label stack entries with a label stack entry at a top of the MPLS label stack including a SID used to forward the packet to the router, and the SRH type MPLS extension header includes one or more SIDs that collectively provide a SID list for use in segment routing”, which implies the generating of SR label based on updated SFC information); send, to a SFC classifier, an SR label request to configure the SR label ([[0089], states “A service Classifier adds NSH.” Where NSH is “Network Service Header (NSH) contains service path information and optionally metadata that are added to a packet or frame and used to create a service plane” which implies the classifier can configure the SR label) ; and receive, from the SFC classifier in response to transmission of the SR label request, an SR label response that includes a status of a configuration of the SR label ([0034], “The SRH type MPLS extension header includes one or more SIDs that collectively provide a SID list for use in segment routing. The one or more processors also execute the instructions to copy one of the one or more SIDs in the SRH type MPLS extension header to the top of the MPLS label stack, and forward the packet to another router of the MPLS network based on the one of the one or more SIDs included in the label stack entry at the top of the MPLS label stack”, this implies SRH includes SIDs, which are essentially SR labels and provides the routing configuration of the packet, update it and forward the packet to another MPLS network).
Therefore, it would have been obvious to someone of ordinary skill in the art before the effective filing date of the claimed invention to have modified Lake in view of Flinck to incorporate the teachings of Song (in analogous art) by generating, based on information in the SFC response, a Segment Routing (SR) label to avoids the need for hop-by-hop routing decisions to be made on the IP layer network address, instead traffic is sent along a path predetermined by a particular set of labels. (Song , [0005]).
Regarding claim 40 (Currently Amended), Lake, Flinck and Song teach the non-transitory computer-readable storage medium of claim 39.
Flinck further teaches wherein the instructions, when executed, further configure the SOCF (Claim 19 states “the apparatus comprising: at least one processor; and at least one memory including computer program code, the at least one memory and the computer program code configured to, with the at least one processor”, cause the apparatus at least to perform the functions of the SFC method): to use at least one of:
Lake and Flinck do not teach, but Song teaches an SFC inherent SR protocol stack in which ([0158], states “Service Function Chaining (SFC) can be supported using SR that is implemented using an MPLS Extension Header with advantages over SFC supported by conventional SR-MPLS”, and [0159] describes the Segment Routing (SR) and NSH functionality can be integrated to better support SFC, which confirm this limitation) first SFC-related information is carried as a locator: function field in Segment Routing Header (SRH) (Abstract discloses “The SRH type MPLS extension header includes one or more segment identifiers (SIDs) that collectively provide a SID list for use in segment routing”, these SIDs acts as locator for specific nodes/ SFs, [0017], line 5-10 and [0158], lines 1-4) and second SFC-related information is contained in a type-length-value (TLV) field of the SRH ([0158], explicitly discloses “ metadata (that is useful for message passing and/or information sharing between service functions) can be carried in the optional TLV field 1014 in the SRH.” [0159], lines 6-10, NSH integration with segment routing SR to get better support SFC), the first SFC-related information comprising the Comm SF and identification of SFs reachable from the Comm SF (Abstract discloses “The SRH type MPLS extension header includes one or more segment identifiers (SIDs) that collectively provide a SID list for use in segment routing” where the segment list is a series of segment IDs or SIDs which re[present the path/traffic through specific/comm SFs, [0017], also states “For each SID, of the one or more SIDs included in the SRH type MPLS extension header, content of the corresponding function and argument field includes instructions and parameters for use in network programming associated with a segment specified by the SID”).
separate SFC service layer and transport protocols in which transport uses identifiers of
different enhanced user plane functions (eUPFs) and communication (Comm) SFs,
transport protocols that are integrated with SFC-related information in which a General
Packet Radio Service (GPRS) Tunneling Protocol (GTP)-user (GTP-U) header or a Segment Routing Header (SRH) has type-length-value (TL V) fields contains the SFC-related information, and
Therefore, it would have been obvious to someone of ordinary skill in the art before the effective filing date of the claimed invention to have modified Lake in view of Flinck to incorporate the teachings of Song (in analogous art) by generating, based on information in the SFC response, a Segment Routing (SR) label to avoids the need for hop-by-hop routing decisions to be made on the IP layer network address, instead traffic is sent along a path predetermined by a particular set of labels. (Song , [0005]).
7. Claims 25-26 and 33-36 are rejected under 35 U.S.C. 103 as being unpatentable over Lake et al. (Softwarization of 5G Networks-Implications to Open Platforms and Standardizations) in view of Flinck et al. (US-20190222521-A1) in view of Song et al. (US-20200358698-A1) and further in view of Li et al. (A Framework for Constructing Service Function Chaining Systems Based on Segment Routing).
Regarding claim 25 (Previously Presented), Lake, Flinck and Song teach the apparatus of claim 21, wherein:
Lake, Flinck and Song do not teach, but Li teaches an SFC service layer is a protocol layer above a SFC transport layer (Sec. 4.1 states “For NSH-based SFC with SR-based transport tunnel, service information is maintained by NSH, which represents the service layer, while SR is only used for transport between SFFs. This indicates that the SFC service layer operates on top of the SFC transport layer), and the SFC service layer is configured to hold SFC-related information (Para. 2, page 6, , describe the SFC service layer is configured to hold SFC-related information and managing SFC specific data, Para. 2, page 3, states the related information “SFC can be implemented based on Network Service Header [RFC8300 ] . In NSH-based SFC, per-SFC state, such as a mapping between Service Path Identifier (SPI) and Service Index (SI) to next-hop forwarding, needs to be maintained on nodes along the Service Function Path(SFP), and it can therefore, be termed as "stateful SFC"), which includes path information and an ordered list of SFs, in addition to quality of service (QoS), and provide SFC encapsulation (Fig. 1, illustrates path information and an ordered list of SFs. Abstract, para. 2, describe the ordered list of SFs, “Service Function Chaining (SFC) provides support for the creation of composite services that consist of an ordered set of Service Functions (SF) that are to be applied to packets and/or frames selected as a result of classification.”, The encapsulation, as shown in Fig. 1, ensure that properly classified and steered to ensure the required QoS policies).
Therefore, it would have been obvious to someone of ordinary skill in the art before the effective filing date of the claimed invention to have modified Lake in view of Flinck in view of Song to incorporate the teachings of Li (in analogous art) by the SFC service layer is configured to hold SFC-related information to avoid per-SFC state needs to be maintained along with the SFP, and it can therefore be termed "stateless SFC" (Li , Para. 4, page 3).
Regarding claim 26 (Previously Presented), Lake, Flinck, Song and Li teach the apparatus of claim 25.
Lake further teaches wherein the SFC encapsulation includes: a service identifier (ID) ( Fig. 7, Para. 4, page 5, states “discuss the challenges of choosing a suitable method of carrying classification between devices and between different vendor's hardware showing how the use of a Network Service Header (NSH) can be added to any packet as an inter-SFC-enabled marker”, which implies NSH includes metadata that contains service identifier for rout packets through SF in the chain), an ordered list of SFs that includes at least one of a list of SF names, addresses, SF service names (Fig. 1, , para. 3, page 5 states “Service Function Chaining (SFC) is a technology which allows both topological and transport independence from the underlying hardware by defining the end-to-end delivery of services through an ordered set of defined service functions”, implies SFC relies on an ordered list, the figure 1 shows SF service names, such as NSSF, NRF, NRF, etc. which are standardized identifier for types of service functions names) , and Fully Qualified Domain Names (FQDNs) , SFC path information that includes at least one of identifiers of path transport end points (Para. 8, Page 23, states “LISP-Locator and ID Separator maps locally significant Endpoint Identifiers to globally-routable Routing Locators (RLOC) and therefore allow a separation between the mobility needs and fixed routing” , this define the end-to-end (identifiers of path transport) delivery services), a network slice ID Single (Fig. 2 illustrates different slice ID such as smartphones, automative devices and massive IoT devices over single set of infrastructure, as described in network slicing section) - Network Slice Selection Assistance Information (S-NSSAI), and a current serving SF ID.
Regarding claim 33 (Previously Presented), Lake, Flinck and Song teach the apparatus of claim 21.
Lake and Song do not teach, but Flinck further teaches wherein: the processing circuitry is to configure a communication (Comm) control function (CF) ([0034] states “FIG. 1 shows a schematic block diagram illustrating a configuration of a control unit 10 in which the condition function is implementable. The control unit 10 comprises processing resources 11 (e.g. processing circuitry), memory resources 12 (e.g. memory circuitry), and interfaces 13 (e.g. interface circuitry).”to configure a Comm SF (Claim 1 states “ A method of controlling a service function chain including service functions which process user plane packets, the method comprising: providing a shared context comprising rules and policies for processing the user plane packets, the shared context being shared between the service functions of the service function chain”, which indicate configuring service functions) with at least one of a SFC packet filter and SF forwarding rules (Fig. 2, [0033], [0073], and [0076] describe these actions involve configuring SFs with packet filters and forwarding rules.)
Therefore, it would have been obvious to someone of ordinary skill in the art before the effective filing date of the claimed invention to have modified Lake to incorporate the teachings of Flinck (in analogous art) by sending, to a control function (CF), a Service Function Chaining (SFC) request for the CF to perform SF selection and configure the SFs to enable dynamic context-aware and efficient management of SFC which enhance the performance and resource utilization in the network (Flinck , [0014]).
Lake, Flinck and Song do not teach, but Li teaches using at least one of: a PFCP, Path Computation Element Protocol (PCEP) (Table 1, describes using PCEP for configuring SFPR and steering policy, especially, PCEP extensions are defined “When SFC is constructed based on SR, SFPR and packet steering rules can be installed by SR policy at the ingress node, which plays the role of classifier in the SFC architecture Para. 4, Section 2, Section 3.2, and Section 4.2), OpenFlow, or Netconf protocol, with SR-MultiProtocol Label Switching (SR-MPLS) or SRv6 labels as SR labels,
Therefore, it would have been obvious to someone of ordinary skill in the art before the effective filing date of the claimed invention to have modified Lake in view of Flinck in view of Song to incorporate the teachings of Li (in analogous art) by the SFC service layer is configured to hold SFC-related information to avoid per-SFC state needs to be maintained along with the SFP, and it can therefore be termed "stateless SFC" (Li , Para. 4, page 3).
Lake further teaches and a General Packet Radio Service (GPRS) Tunneling Protocol (GTP)-user (GTP-U) header contains SFC-related information at or after octet 12 (Fig. 7, Para. 2, page 23, “A case in-point is the use of the Generic Tunneling Protocol (GTP) in the mobile packet core until recently, GTP was only described by a 3GPP definition [147] as it was simply a use of an UDP/IP datagram. It has been added to the IETF through draft-hmm-dmm-5g-uplane analysis-01 [148] as of late 2019.” This implies the protocol can used for enabling data transfer with ensuring correctly routing through wireless networks),
Lake and Flinck do not teach, but Song teaches the SFC-related information comprising at least one of a service identifier (ID), a path ID, and a current SF ([0089], states “NSH defines a service plane protocol specifically for the creation of dynamic service chains and is composed of the following elements: Service Function Path identification; indication of location within a Service Function Path; and optional per packet metadata (fixed length or variable)”).
Therefore, it would have been obvious to someone of ordinary skill in the art before the effective filing date of the claimed invention to have modified Lake in view of Flinck to incorporate the teachings of Song (in analogous art) by generating, based on information in the SFC response, a Segment Routing (SR) label to avoids the need for hop-by-hop routing decisions to be made on the IP layer network address, instead traffic is sent along a path predetermined by a particular set of labels. (Song , [0005]).
Regarding claim 34 (Previously Presented), Lake, Flinck and Song teach the apparatus of claim 21.
Lake and Song do not teach, but Flinck further teaches wherein: the processing circuitry is to configure a communication (Comm) control function (CF) ([0034] states “FIG. 1 shows a schematic block diagram illustrating a configuration of a control unit 10 in which the condition function is implementable. The control unit 10 comprises processing resources 11 (e.g. processing circuitry), memory resources 12 (e.g. memory circuitry), and interfaces 13 (e.g. interface circuitry).”to configure a Comm SF (Claim 1 states “ A method of controlling a service function chain including service functions which process user plane packets, the method comprising: providing a shared context comprising rules and policies for processing the user plane packets, the shared context being shared between the service functions of the service function chain”, which indicate configuring service functions) with at least one of a SFC packet filter and SF forwarding rules (Fig. 2, [0033], [0073], and [0076] describe these actions involve configuring SFs with packet filters and forwarding rules.)
Therefore, it would have been obvious to someone of ordinary skill in the art before the effective filing date of the claimed invention to have modified Lake to incorporate the teachings of Flinck (in analogous art) by sending, to a control function (CF), a Service Function Chaining (SFC) request for the CF to perform SF selection and configure the SFs to enable dynamic context-aware and efficient management of SFC which enhance the performance and resource utilization in the network (Flinck , [0014]).
Lake, Flinck and Song do not teach, but Li teaches using at least one of: a PFCP, Path Computation Element Protocol (PCEP) (Table 1, describes using PCEP for configuring SFPR and steering policy, especially, PCEP extensions are defined “When SFC is constructed based on SR, SFPR and packet steering rules can be installed by SR policy at the ingress node, which plays the role of classifier in the SFC architecture Para. 4, Section 2, Section 3.2, and Section 4.2), OpenFlow, or Netconf protocol, with SR-MultiProtocol Label Switching (SR-MPLS) or SRv6 labels as SR labels,
Therefore, it would have been obvious to someone of ordinary skill in the art before the effective filing date of the claimed invention to have modified Lake in view of Flinck in view of Song to incorporate the teachings of Li (in analogous art) by the SFC service layer is configured to hold SFC-related information to avoid per-SFC state needs to be maintained along with the SFP, and it can therefore be termed "stateless SFC" (Li , Para. 4, page 3).
Lake and Flinck do not teach, but Song teaches an 1Pv6 Segment Routing Header (SRH) has type-length-value (TL V) fields that contains SFC-related information (Fig. 10, [0141], [0158]-[0159], These paragraphs confirm that the IP6 segment Routing Header (SRH) includes TL V, ”that is useful for message passing and/or information sharing between service functions) can be carried in the optional TLV field 1014 in the SRH”), the SFC-related information comprising at least one of a service identifier (ID), a path ID, and a current SF ([0089], states “NSH defines a service plane protocol specifically for the creation of dynamic service chains and is composed of the following elements: Service Function Path identification; indication of location within a Service Function Path; and optional per packet metadata (fixed length or variable)”).
Therefore, it would have been obvious to someone of ordinary skill in the art before the effective filing date of the claimed invention to have modified Lake in view of Flinck to incorporate the teachings of Song (in analogous art) by generating, based on information in the SFC response, a Segment Routing (SR) label to avoids the need for hop-by-hop routing decisions to be made on the IP layer network address, instead traffic is sent along a path predetermined by a particular set of labels. (Song , [0005]).
Regarding claim 35 (Previously Presented), Lake, Flinck and Song teach the apparatus of claim 21.
Lake and Song do not teach, but Flinck further teaches wherein: the processing circuitry is to configure a communication (Comm) control function (CF) ([0034] states “FIG. 1 shows a schematic block diagram illustrating a configuration of a control unit 10 in which the condition function is implementable. The control unit 10 comprises processing resources 11 (e.g. processing circuitry), memory resources 12 (e.g. memory circuitry), and interfaces 13 (e.g. interface circuitry).”to configure a Comm SF (Claim 1 states “ A method of controlling a service function chain including service functions which process user plane packets, the method comprising: providing a shared context comprising rules and policies for processing the user plane packets, the shared context being shared between the service functions of the service function chain”, which indicate configuring service functions) with at least one of a SFC packet filter and SF forwarding rules (Fig. 2, [0033], [0073], and [0076] describe these actions involve configuring SFs with packet filters and forwarding rules.)
Therefore, it would have been obvious to someone of ordinary skill in the art before the effective filing date of the claimed invention to have modified Lake to incorporate the teachings of Flinck (in analogous art) by sending, to a control function (CF), a Service Function Chaining (SFC) request for the CF to perform SF selection and configure the SFs to enable dynamic context-aware and efficient management of SFC which enhance the performance and resource utilization in the network (Flinck , [0014]).
Lake, Flinck and Song do not teach, but Li teaches using at least one of: a PFCP, Path Computation Element Protocol (PCEP) (Table 1, describes using PCEP for configuring SFPR and steering policy, especially, PCEP extensions are defined “When SFC is constructed based on SR, SFPR and packet steering rules can be installed by SR policy at the ingress node, which plays the role of classifier in the SFC architecture Para. 4, Section 2, Section 3.2, and Section 4.2), OpenFlow, or Netconf protocol, with SR-MultiProtocol Label Switching (SR-MPLS) or SRv6 labels as SR labels,
Therefore, it would have been obvious to someone of ordinary skill in the art before the effective filing date of the claimed invention to have modified Lake in view of Flinck in view of Song to incorporate the teachings of Li (in analogous art) by the SFC service layer is configured to hold SFC-related information to avoid per-SFC state needs to be maintained along with the SFP, and it can therefore be termed "stateless SFC" (Li , Para. 4, page 3).
Lake and Flinck do not teach, but Song teaches a SR-MPLS or SRv6 header includes SFC-related information ([0014], states “a noticeable missing feature of SR-MPLS is network programming, which is a powerful feature of SRv6. “, and Fig. 5, [0093] and[0158] states “MPLS Extension Headers (which can also be referred to herein more succinctly as Extension Headers), and related metadata” which indicate the SR-MPLS header can include metadata), the SFC-related information comprising a series of SR labels to steer traffic towards Comm SFs and SFs reachable from the Comm SFs (the abstract discloses “The SRH type MPLS extension header includes one or more segment identifiers (SIDs) that collectively provide a SID list for use in segment routing” where the segment list is a series of segment IDs or SIDs which re[present the path/traffic through specific/comm SFs, [0017], also states “For each SID, of the one or more SIDs included in the SRH type MPLS extension header, content of the corresponding function and argument field includes instructions and parameters for use in network programming associated with a segment specified by the SID”).
Therefore, it would have been obvious to someone of ordinary skill in the art before the effective filing date of the claimed invention to have modified Lake in view of Flinck to incorporate the teachings of Song (in analogous art) by generating, based on information in the SFC response, a Segment Routing (SR) label to avoids the need for hop-by-hop routing decisions to be made on the IP layer network address, instead traffic is sent along a path predetermined by a particular set of labels. (Song , [0005]).
Regarding claim 36 (Previously Presented), The apparatus of claim 21.
Lake and Song do not teach, but Flinck further teaches wherein: the processing circuitry is to configure a communication (Comm) control function (CF) ([0034] states “FIG. 1 shows a schematic block diagram illustrating a configuration of a control unit 10 in which the condition function is implementable. The control unit 10 comprises processing resources 11 (e.g. processing circuitry), memory resources 12 (e.g. memory circuitry), and interfaces 13 (e.g. interface circuitry).”to configure a Comm SF (Claim 1 states “ A method of controlling a service function chain including service functions which process user plane packets, the method comprising: providing a shared context comprising rules and policies for processing the user plane packets, the shared context being shared between the service functions of the service function chain”, which indicate configuring service functions) with at least one of a SFC packet filter and SF forwarding rules (Fig. 2, [0033], [0073], and [0076] describe these actions involve configuring SFs with packet filters and forwarding rules.)
Therefore, it would have been obvious to someone of ordinary skill in the art before the effective filing date of the claimed invention to have modified Lake to incorporate the teachings of Flinck (in analogous art) by sending, to a control function (CF), a Service Function Chaining (SFC) request for the CF to perform SF selection and configure the SFs to enable dynamic context-aware and efficient management of SFC which enhance the performance and resource utilization in the network (Flinck , [0014]).
Lake, Flinck and Song do not teach, but Li teaches using at least one of: a PFCP, Path Computation Element Protocol (PCEP) (Table 1, describes using PCEP for configuring SFPR and steering policy, especially, PCEP extensions are defined “When SFC is constructed based on SR, SFPR and packet steering rules can be installed by SR policy at the ingress node, which plays the role of classifier in the SFC architecture Para. 4, Section 2, Section 3.2, and Section 4.2), OpenFlow, or Netconf protocol, with SR-MultiProtocol Label Switching (SR-MPLS) or SRv6 labels as SR labels,
Therefore, it would have been obvious to someone of ordinary skill in the art before the effective filing date of the claimed invention to have modified Lake in view of Flinck in view of Song to incorporate the teachings of Li (in analogous art) by the SFC service layer is configured to hold SFC-related information to avoid per-SFC state needs to be maintained along with the SFP, and it can therefore be termed "stateless SFC" (Li , Para. 4, page 3).
Lake and Flinck do not teach, but Song teaches first SFC-related information is carried as a locator: function field in Segment Routing Header (SRH) (Abstract discloses “The SRH type MPLS extension header includes one or more segment identifiers (SIDs) that collectively provide a SID list for use in segment routing”, these SIDs acts as locator for specific nodes/ SFs, [0017], line 5-10 and [0158], lines 1-4) and second SFC-related information is contained in a type-length-value (TLV) field of the SRH ([0158], explicitly discloses “ metadata (that is useful for message passing and/or information sharing between service functions) can be carried in the optional TLV field 1014 in the SRH.” [0159], lines 6-10, NSH integration with segment routing SR to get better support SFC), the first SFC-related information comprising the Comm SF and identification of SFs reachable from the Comm SF (Abstract discloses “The SRH type MPLS extension header includes one or more segment identifiers (SIDs) that collectively provide a SID list for use in segment routing” where the segment list is a series of segment IDs or SIDs which re[present the path/traffic through specific/comm SFs, [0017], also states “For each SID, of the one or more SIDs included in the SRH type MPLS extension header, content of the corresponding function and argument field includes instructions and parameters for use in network programming associated with a segment specified by the SID”).
Therefore, it would have been obvious to someone of ordinary skill in the art before the effective filing date of the claimed invention to have modified Lake in view of Flinck to incorporate the teachings of Song (in analogous art) by generating, based on information in the SFC response, a Segment Routing (SR) label to avoids the need for hop-by-hop routing decisions to be made on the IP layer network address, instead traffic is sent along a path predetermined by a particular set of labels. (Song , [0005]).
Relevant Prior Art
8. The prior art made of record and not relied upon is considered pertinent to applicant's
disclosure.
Wang et al. (US-10122622-B2), GANDHI et al. (US-20220286395-A1), Garvia (US-11095559-B1), Hu et al. (CN-111988395-B) teach methods involved traffic steering for SFC in wireless networks.
Conclusion
9. 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 SANAA S AL SAMAHI whose telephone number is (571)272-4171. The examiner can normally be reached M-F 8-5 EST.
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, Asad Nawaz can be reached at (571) 272-3988. 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.
/SANAA AL SAMAHI/Examiner, Art Unit 2463
/OMAR J GHOWRWAL/Primary Examiner, Art Unit 2463
Prosecution Insights