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 .
Priority
Acknowledgment is made of applicant’s claim for foreign priority under 35 U.S.C.119 (a)-(d). The certified copy has been filed in parent REPUBLIC OF KOREA patent application No. KR10-2022-0125316 filed on 09/30/2022 and No. KR10-2023-0054040 filed on 04/25/2023. Receipt is acknowledged of certified copies of papers required by 37 CFR1.55.
Response to Amendment
This Office Action is in response to applicant’s amendment submitted on January 15, 2026.
Claims, 1-20 are now currently pending in the present application.
Claim Rejections - 35 USC § 102
In the event the determination of the status of the application as subject to AIA 35 U.S.C. 102 and 103 (or as subject to pre-AIA 35 U.S.C. 102 and 103) is incorrect, any correction of the statutory basis (i.e., changing from AIA to pre-AIA ) for the rejection will not be considered a new ground of rejection if the prior art relied upon, and the rationale supporting the rejection, would be the same under either status.
The following is a quotation of the appropriate paragraphs of 35 U.S.C. 102 that form the basis for the rejections under this section made in this Office action:
A person shall be entitled to a patent unless –
(a)(1) the claimed invention was patented, described in a printed publication, or in public use, on sale, or otherwise available to the public before the effective filing date of the claimed invention.
(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.
CLAIM 1-20 are rejected under U.S.C. 102(a)(1) as being anticipated by 3GPP TR 23.700-18 V 0.2.1 (2022-04) (hereinafter 3GPP).
Consider CLAIM 1, 3GPP discloses A method performed by an application function (AF) in a wireless communication system, the method comprising:
Requesting a service function chaining (SFC) service from a network exposure function (NEF), (section 6.2.2, The procedure below shows an example of AF using the Traffic Influence API to allow an AF to request a predefined SFC).
Wherein the requesting the SFC service comprises the SFC service is requested by inputting an SFC policy identifier and a metadata value on a basis of an Nnef_TrafficInfluence service interface, and (section 6.4.2, Figure 6.4.2-1: The AF creates AF request that includes an SFP ID and, optionally, Metadata corresponding to that SFP ID, in addition to existing parameters (e.g. Traffic descriptor, Application Identifier, traffic steering information (TSI)), to the NEF for requesting traffic routing to a SFP identified by the SFC ID. The AF sends the AF request via Nnef_TrafficInfluence_Create/Update/Delete message to NEF).
Wherein the SFC policy identifier is mapped to an identifier defined in a policy and charging control (PCC) rule, and (Section 5, Clause 5.8.2.8.2: Enforcement of Dynamic PCC Rules in which the SMF shall maintain the mapping between a PCC rule received over Npcf and the flow level PDR(s) used on N4 interface).
Wherein a traffic steering rule applied by a session management function (SMF) to a user plane function (UPF) uses both N6-LAN traffic steering and AF-influenced traffic steering for a piece of traffic. (Section 6.8.1, the AF-influenced traffic steering enforcement control is only applied to the uplink traffic in the existing specification. The N6-LAN traffic steering enforcement control can be applied to the downlink traffic, uplink traffic or both. The N6-LAN Traffic steering policy identifiers can be different for uplink and downlink direction).
Consider CLAIM 2, 3GPP discloses the method of claim 1, wherein the SFC policy identifier is mapped to the identifier defined in the PCC rule by using an existing traffic steering policy (TSP) ID. (Section 6.3.2.1, The PCF maps the SFC ID to a TSP ID provided in the PCC rules: policy information indicates how the UPF should "tag" (e.g. via traffic steering identifiers etc.) the classified traffic identified by the corresponding SF filter(s)).
Consider CLAIM 3, 3GPP discloses the method of claim 1, wherein the SFC policy identifier is mapped to the identifier defined in the PCC rule by using an SFC ID input from the AF. (Section 6.3.1, the available SFCs and their types, as well as the service path related classification tag (referred to as SFP Id and metadata information in this solution) and DNAI, is available to 5GC so that such information can be exposed to the AF via NEF API, and the AF can therefore associate some traffic with a certain SFC by indicating the SFC ID).
Consider CLAIM 4, 3GPP discloses the method of claim 1, wherein the SFC policy identifier is mapped to the identifier defined in the PCC rule by using a service function path (SFP) ID to be performed by the UPF on an actual packet. (Section 6.3.2.0, PCF to create PCC rules for PDU Sessions. In order to support the second scenario PCC rules and N4 rules (FAR) need extension to carry the SFP Id and metadata information. For example, the FAR / Outer header creation information needs new values corresponding to NSH / VXLAN tag etc. to be added after SFC classification done by the PSA UPF).
Consider CLAIM 5, 3GPP discloses the method of claim 1, further comprising:
Transmitting, by the AF, new policy information comprising the identifier and metadata defined in the PCC rule to the SMF via a policy control function (PCF). (Section 6.3.2.1, the PCF determines if existing PDU Sessions are potentially impacted by the AF request. For each of existing or new PDU Sessions, the PCF updates the SMF with corresponding policy information about the PDU Session by invoking Npcf SM Policy Control Update Notify Npcf_SM Policy Control Create service operation).
Consider CLAIM 6, 3GPP discloses the method of claim 1, further comprising:
Transmitting, by the AF, forwarding action rule (FAR) forwarding information comprising the identifier and metadata defined in the PCC rule to the UPF via the SMF. (Section 6.5.1, SFC capabilities can be decided by the PCF when the AF requests them via the NEF, or they can be pre-configured statically in the PCF. With the addition of SFC capabilities: SFP Identification and SFP Information for the SFC encapsulation in
the UPF, the PCC rule can be used to detect and steer traffic flows. SFC capabilities are now defined in the PCC rule and the Forwarding Action Rule (FAR)).
Consider CLAIM 7, 3GPP discloses the method of claim 1, further comprising:
Identifier and metadata in a unified data repository (UDR). (Section 6.5.2, SFC capabilities is delivered in AF request from the AF to the NEF. Then, the NEF stores the AF request information in the UDR including SFC capabilities.
Consider CLAIM 8, 3GPP discloses the method of claim 7, wherein the UDR
notifies a policy control function (PCF) that information comprised in the UDR has been updated. (Section 6.5.2, When the updated policy information about the PDU Session is received from the PCF, the SMF may take appropriate actions to reconfigure the User plane of the PDU Session including SFC capabilities, as shown in Table 6.5-3.
Consider CLAIM 9, 3GPP discloses the method of claim 1, wherein the identifier defined in the PCC rule is an identifier (ID) used inside a 5G system (5GS). (Section 6.5.1, Table 6.5-2: The elements related to traffic steering in the PCC rule information in 5GC).
Consider CLAIM 10, 3GPP discloses a method performed by a network exposure function (NEF) in a wireless communication system, the method comprising: Receiving a request of a service function chaining (SFC) service from an application function (AF), (Section 5.2.1, how to enable support for AF to request usage of predefined SFC/SFP(s) for traffic flow(s) related with target UE(s)).
Wherein the receiving the request of the SFC service comprises the request of the SFC service is received by inputting an SFC policy identifier and a metadata value on a basis of an Nnef_TrafficInfluence service interface, and (section 6.4.2, Figure 6.4.2-1: the AF creates AF request that includes an SFP ID and, optionally, Metadata corresponding to that SFP ID, in addition to existing parameters (e.g. Traffic descriptor, Application Identifier, traffic steering information (TSI)), to the NEF for requesting traffic routing to a SFP identified by the SFC ID. The AF sends the AF request via Nnef_Traffic InfluenceCreate/Update/Delete message to NEF).
Wherein the SFC policy identifier is mapped to an identifier defined in a policy and charging control (PCC) rule, and (Section 5, Clause 5.8.2.8.2: Enforcement of Dynamic PCC Rules in which the SMF shall maintain the mapping between a PCC rule received over Npcf and the flow level PDR(s) used on N4 interface).
Wherein a traffic steering rule applied by a session management function (SMF) to a user plane function (UPF) uses both N6-LAN traffic steering and AF-influenced traffic steering for a piece of traffic. (Section 6.8.1, the AF-influenced traffic steering enforcement control is only applied to the uplink traffic in the existing specification. The N6-LAN traffic steering enforcement control can be applied to the downlink traffic, uplink traffic or both. The N6-LAN Traffic steering policy identifiers can be different for uplink and downlink direction).
Consider CLAIM 11, 3GPP discloses the method of claim 10, wherein the SFC policy identifier is mapped to the identifier defined in the PCC rule by using an existing traffic steering policy (TSP) ID. (Section 6.3.2.1, The PCF maps the SFC ID to a TSP ID provided in the PCC rules: policy information indicates how the UPF should "tag" (e.g. via traffic steering identifiers etc.) the classified traffic identified by the corresponding SF filter(s)).
Consider CLAIM 12, 3GPP discloses the method of claim 10, wherein the SFC policy identifier is mapped to the identifier defined in the PCC rule by using an SFC ID input from the AF. (Section 6.3.1, the available SFCs and their types, as well as the service path related classification tag (referred to as SFP Id and metadata information in this solution) and DNAI, is available to 5GC so that such information can be exposed to the AF via NEF API, and the AF can therefore associate some traffic with a certain SFC by indicating the SFC ID).
Consider CLAIM 13, 3GPP discloses the method of claim 10, wherein the SFC policy identifier is mapped to the identifier defined in the PCC rule by using a service function chaining (SFC) ID to be performed by the UPF on an actual packet. (Section 6.3.2.0, PCF to create PCC rules for PDU Sessions. In order to support the second scenario PCC rules and N4 rules (FAR) need extension to carry the SFP Id and metadata information. For example, the FAR / Outer header creation information needs new values corresponding to NSH / VXLAN tag etc to be added after SFC classification done by the PSA UPF).
Consider CLAIM 14, 3GPP discloses the method of claim 10, further comprising:
Receiving, by the NEF, new policy information comprising the identifier and the metadata defined in the PCC rule from the SMF via a policy control function (PCF). (Section 6.3.2.1, the PCF determines if existing PDU Sessions are potentially impacted by the AF request. For each of existing or new PDU Sessions, the PCF updates the SMF with corresponding policy information about the PDU Session by invoking Npcf SM Policy Control Update Notify Npcf_SM Policy Control_Create service operation).
Consider CLAIM 15, 3GPP discloses the method of claim 10, further comprising:
Transmitting, by the NEF, forwarding action rule (FAR) forwarding information comprising the identifier and the metadata defined in the PCC rule to the UPF via the SMF. (Section 6.5.1, SFC capabilities can be decided by the PCF when the AF requests them via the NEF, or they can be pre-configured statically in the PCF. With the addition of SFC capabilities: SFP Identification and SFP Information for the SFC encapsulation in the UPF, the PCC rule can be used to detect and steer traffic flows. SFC capabilities are now defined in the PCC rule and the Forwarding Action Rule (FAR)).
Consider CLAIM 16, 3GPP discloses the method of claim 10, further comprising:
Storing, by the NEF, the SFC policy identifier and the metadata in a unified data repository (UDR). (Section 6.5.2, SFC capabilities is delivered in AF request from the AF to the NEF. Then, the NEF stores the AF request information in the UDR including SFC capabilities).
Consider CLAIM 17, 3GPP discloses the method of claim 16, wherein the UDR notifies a policy control function (PCF) that information comprised in the UDR has been updated. (Section 6.5.2, When the updated policy information about the PDU Session is received from the PCF, the SMF may take appropriate actions to reconfigure the User plane of the PDU Session including SFC capabilities, as shown in Table 6.5-3).
Consider CLAIM 18, 3GPP discloses the method of claim 16, wherein the identifier defined in the PCC rule is an identifier (ID) used inside a 5G system (5GS). (Section 6.5.1, Table 6.5-2: The elements related to traffic steering in the PCC rule information in 5GC).
Consider CLAIM 19, 3GPP discloses an apparatus of an application function (AF) in a wireless communication system, the apparatus comprising:
A transceiver unit; and a controller operably connected to the transceiver, wherein the controller is configured to: request an SFC service from a network exposure function (NEF); (Section 6.2.2, The procedure below shows an example of AF using the Traffic Influence API to allow an AF to request a predefined SFC).
Requests the SFC service by inputting an SFC policy identifier and a metadata value on a basis of an Nnef_TrafficInfluence service interface in order to request the SFC service; and (section 6.4.2, Figure 6.4.2-1: The AF creates AF request that includes an SFP ID and, optionally, Metadata corresponding to that SFP ID, in addition to existing parameters (e.g. Traffic descriptor, Application Identifier, traffic steering information (TSI)), to the NEF for requesting traffic routing to a SFP identified by the SFC ID. The AF sends the AF request via Nnef_TrafficInfluence_Create/Update/Delete message to NEF).
Wherein the SFC policy identifier is mapped to an identifier defined in a PCC rule, and (Section 5, Clause 5.8.2.8.2: Enforcement of Dynamic PCC Rules in which the SMF shall maintain the mapping between a PCC rule received over Npcf and the flow level PDR(s) used on N4 interface).
Wherein a traffic steering rule applied by a session management function (SMF) to a user plane function (UPF) uses both N6-LAN traffic steering and AF-influenced traffic steering for a piece of traffic. (Section 6.8.1, the AF-influenced traffic steering enforcement control is only applied to the uplink traffic in the existing specification. The N6-LAN traffic steering enforcement control can be applied to the downlink traffic, uplink traffic or both. The N6-LAN Traffic steering policy identifiers can be different for uplink and downlink direction).
Consider CLAIM 20, The method of claim 1, wherein when two pieces of SFC policy information exist in a same direction corresponding to an uplink direction or a downlink direction, and one of the two pieces of SFC policy information is applied according to priority. (Section 6.8.1, In the request, the AF shall include the N6-LAN traffic steering control information, which includes target UE Identifier(s), DNN, S-NSSAI, SFC identifier (uplink and/or downlink), to the 5GC based on the SLA between the operator and the 3rd party. The PCF authorizes the N6-LAN traffic steering control information received from AF based on the SFC identifier (uplink and/or downlink) and operator's policy when generating the PCC rule. And then the N6-LAN traffic steering enforcement control information provisioning and enforcement defined in clauses 6.1.3.14 and 6.2.2.6 of TS 23.503 [4] can be applied, i.e. installing the related rule at UPF).
Conclusion
Applicant's amendment necessitated the new ground(s) of rejection presented in this Office action. Accordingly, THIS ACTION IS MADE FINAL. See MPEP § 706.07(a). Applicant is reminded of the extension of time policy as set forth in 37 CFR 1.136(a).
A shortened statutory period for reply to this final action is set to expire THREE MONTHS from the mailing date of this action. In the event a first reply is filed within TWO MONTHS of the mailing date of this final action and the advisory action is not mailed until after the end of the THREE-MONTH shortened statutory period, then the shortened statutory period will expire on the date the advisory action is mailed, and any nonprovisional extension fee (37 CFR 1.17(a)) pursuant to 37 CFR 1.136(a) will be calculated from the mailing date of the advisory action. In no event, however, will the statutory period for reply expire later than SIX MONTHS from the mailing date of this final action.
Any inquiry concerning this communication or earlier communications from the examiner should be directed to MICHELE CAMILLE DOUGLAS whose telephone number is (571)270-0458. The examiner can normally be reached Monday - Friday 6:30 am - 5:00 pm.
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, Matthew Anderson can be reached at 571-272-4177. 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.
/MICHELE C DOUGLAS/Examiner, Art Unit 2646
/MATTHEW D. ANDERSON/Supervisory Patent Examiner, Art Unit 2646