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 .
Claim Objections
Claims 3, 4, 9, and 13 are objected to because of the following informalities:
The claims recite “and/or” and since both cannot be satisfied at the same time, it renders the claims indefinite.
Appropriate correction is required.
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.
Claim(s) 1, 7, 9, 11-13, 17, and 27 is/are rejected under 35 U.S.C. 102(a)(1) as being anticipated by ETSI TS 129.512 “5G; 5G System; Session Management Policy Control Service; Stage 3 (3GPP TS 29.512 version 17.7.0 Release 17) hereinafter NPL 1.
Regarding claim 1, NPL 1 teaches a method for feature support notification in a communication network, the method comprising: (Pg 51-52, process for QOS monitoring)
determining, by a network management unit, (SMF or PCF) whether or not feature notifications (QoS Monitoring which enables certain communications) in relation to one or more features (QoS Monitoring) are supported by at least one network unit; (AF) (Pg 51; 4.2.3.25; If the "QosMonitoring" feature is supported, the PCF may generate the authorized QoS Monitoring data decision for the service data flow based on the QoS Monitoring request if received from the AF; When the feature "ExposureToEAS" is supported and the AF indication of direct notification is received, the PCF may determine whether duplicate notification is required, i.e., whether the QoS monitoring report is sent to the local AF/NEF by both, the UPF and the PCF. … The QoS monitoring report can be sent by the SMF to the PCF as described in clause 4.2.4.24)
and if it is determined that feature notifications are supported by the at least one network unit, receiving a feature report (receiving by the PCF a report from the SMF and sending the report (equivalent to notification) to the AF) and sending a feature notification; (receiving by the PCF a report from the SMF and sending the report (equivalent to notification) to the AF) (Pg 51-52; 4.2.3.25; When the feature "ExposureToEAS" is supported and the AF indication of direct notification is received, the PCF may determine whether duplicate notification is required, i.e., whether the QoS monitoring report is sent to the local AF/NEF by both, the UPF and the PCF. … The QoS monitoring report can be sent by the SMF to the PCF as described in clause 4.2.4.24)
or if it is determined that feature notifications are not (If feature is not supported, then feature communication is not supported) supported by the at least one network unit, sending a feature notification (sending a message related to the feature). (Pg 53: 4.2.3.26.1: If the "PolicyDecisionErrorHandling" feature is supported and the "ExtPolicyDecisionErrorHandling" feature is not supported, and the SMF receives one or more policy decision type(s) (as defined in clause 4.1.4.4) and/or condition data (as defined in clause 4.1.8), which are not referred by any provisioned PCC rule or session rule as defined in clause 4.2.3.2 … the SMF SHALL Include an HTTP "200 OK" status code and one or more PolicyDecisionFailureCode data types to indicate the type(s) of the failed policy decisions and/or condition data in the response message … Include an HTTP "200 OK" status code and one or more PartialSuccessReport data structure(s) including the "policyDecFailureReports" attribute to indicate the type(s) of the failed policy decisions and/or condition data and the "failureCause" attribute set to "POL_DEC_ERROR" in the response message)
Regarding claim 7, NPL 1 teaches the method of claim 1, and is disclosed above, NPL 1 further teaches wherein the at least one network unit comprises a Next Generation Radio Access Node (NG-RAN); (Pg 65: 4.2.4.14: If the "AuthorizationWithRequiredQoS" feature as defined in clause 5.8 is supported and if the SMF additionally receives the reference to the matching Alternative QoS Profile which the NG-RAN can guarantee, the SMF shall also include the reference to the QosData data structure for the Alternative QoS parameter set corresponding to the reference to the matching alternative QoS profile within the "altQosParamId" attribute.
wherein the method particularly comprises following a NG-RAN change, sending a further feature notification to the AF. (Pg 69: 4.2.4.20: upon receiving a notification from the NG-RAN that the GFBR can no longer be guaranteed or can be guaranteed again as defined clause 5.2.2.3.1 of 3GPP TS 29.502 [22]; … The SMF shall send an HTTP POST request to the PCF … When the PCF receives the HTTP POST request, it shall acknowledge the request by sending a "200 OK" response to the SMF and then notify the AF as defined in 3GPP TS 29.514 [17], clause 4.2.5.4.”
Regarding claim 9, NPL 1 teaches the method of any preceding claim 1, and is disclosed above, NPL 1 further teaches wherein the network management unit is a Session Management Function(SMF);(mapping above + Pg 51-52: teaches the smf performing management functions) and/or wherein the one or more features comprise: Quality of Service (QoS) monitoring; Time Sensitive Communications; and/or Redundant transmission for high reliability communication. (Examiner respectfully notes this element is part of an OR limitation, and since the smf is mapped, this element is not being elected)
Regarding claim 11, NPL 1 teaches a method for feature support notification in a communication network, the method comprising: (Pg 51-52, process for QOS monitoring)
sending, by an Application Function (AF) node a feature notification request relating to one or more features to a network management unit; (Pg 51: 4.2.3.25: If the "QosMonitoring" feature is supported, the PCF may generate the authorized QoS Monitoring data decision for the
service data flow based on the QoS Monitoring request if received from the AF)
and receiving, by the AF node, a feature notification (QoS monitoring report) from the network management unit (PCF or SMF). (Pg 51: Mapping above + may determine whether the QoS monitoring report is sent to the AF/NEF by the SMF bypassing the PCF or by the PCF …. The QoS monitoring report can be sent by the SMF to the PCF as described in clause 4.2.4.24)
Regarding claim 12, NPL 1 teaches the method of claim 11, and is disclosed above, NPL 1 further teaches wherein the network management unit is a Session Management Function(SMF) (Mapping claim 11 + Pg 51-52, the SMF is the management function)
Regarding claim 13, NPL 1 teaches the method of any of claim 11, and is disclosed above, NPL 1 further teaches wherein the feature notification request ) (Examiner respectfully notes this element is part of an OR limitation, and since the notification passing is mapped, this element is not being elected) and/or the feature notification pass between the AF node and the network management unit (40) via one or more further network components; (Mapping claim 11 + Pg 51-52: the qos monitoring report (feature notification) passes like this [SMF [Wingdings font/0xE0] PCF [Wingdings font/0xE0] AF])
wherein the one or more further network components in particular comprise a Policy Control Function (PCF), (Mapping claim 11 + Pg 51-52: the qos monitoring report (feature notification) passes like this [SMF [Wingdings font/0xE0] PCF [Wingdings font/0xE0] AF]) and/or wherein the one or more further network components comprise a Network Exposure Function (NEF). (Examiner respectfully notes this element is part of an OR limitation, and since the other component being a PCF is mapped, this element is not being elected)
Claim 17, inherits the same rejection as claim 1 for reciting similar limitations in a device claims NPL1 teaches (Page 17: Fig 4.1.2-1 and 2.1.2-2)
Claim 27, inherits the same rejection as claim 11 for reciting similar limitations in a device claims NPL1 teaches (Page 51 AF/NEF)
Claim Rejections - 35 USC § 103
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.
Claim(s) 2-4 is/are rejected under 35 U.S.C. 103 as being unpatentable over ETSI TS 129.512 “5G; 5G System; Session Management Policy Control Service; Stage 3 (3GPP TS 29.512 version 17.7.0 Release 17) hereinafter NPL 1 in view of Azorero et al. (WO 2021165856 A1).
Regarding claim 2, NPL 1 teaches the method of claim 1, and is disclosed above, NPL 1 does not explicitly teach teaches further comprising: prior to determining whether or not feature notifications are supported by at least one network unit, receiving a feature notification request from an Application Function (AF); and sending the feature notification to the AF.
In an analogous art Azorero teaches prior to determining whether or not feature notifications are supported by at least one network unit, (prior to determining if reporting timezone information is supported) receiving a feature notification request from an Application Function (AF); (receiving reporting request from AF) and sending the feature notification to the AF. (sending the reporting information to the AF) (Pg 19 Line 29 [Wingdings font/0xE0] Pg 20 Line 2: Step 600. The AF 416 sends a request for AN information to a PCF 414. In this 30 example, the AF 416 requests timezone information, e.g., for a particular UE 400. Step 602. The PCF 414 forwards the request to an SMF 412. Step 604. The SMF 412 determines that the AN 402 does not support reporting of timezone information. The SMF 412 may know this deficiency in advance, or it may query the AN 402 or a core network node that maintains this information to determine this deficiency.)
It would have been obvious to one of ordinary skill in the art prior to the effective filing of the application to modify the teachings of [NPL 1] to include [receiving a request and provide a response prior to determining if supported] as is taught by Azorero.
The suggestion/motivation for doing so is provisioning of access network information [Pg 1].
Regarding claim 3, NPL 1 in view of Azorero teach the method of claim 2, and is disclosed above, NPL 1 further teaches wherein the feature notification request is received at the network management unit from the AF via one or more further network components, (Examiner respectfully notes this element is part of an OR limitation, and since the notification passing is mapped, this element is not being elected) and/or wherein the feature notification is sent to the AF via one or more further network components. (Mapping claim 1 + Pg 51-52: the qos monitoring report (feature notification) passes like this [SMF [Wingdings font/0xE0] PCF [Wingdings font/0xE0] AF])
Regarding claim 4, NPL 1 in view of Azorero teach the method of claim 3, and is disclosed above, NPL 1 further teaches wherein the one or more further network components comprise a Policy Control Function(PCF) (Mapping claim 1 + Pg 51-52: the qos monitoring report (feature notification) passes like this [SMF -> PCF -> AF]) and/or wherein the one or more further network components comprise a Network Exposure Function(NEF) (Examiner respectfully notes this element is part of an OR limitation, and since the PCF is mapped, this element is not being elected)
Claim(s) 5 and 15 is/are rejected under 35 U.S.C. 103 as being unpatentable over ETSI TS 129.512 “5G; 5G System; Session Management Policy Control Service; Stage 3 (3GPP TS 29.512 version 17.7.0 Release 17) hereinafter NPL 1 in view of Kim et al (US 20220272175 A1)
Regarding claim 5, NPL 1 teaches the method of claim 1, and is disclosed above, NPL1 further teaches wherein the at least one network unit comprises a User Plane Function(UPF); (Pg 51: When the feature "ExposureToEAS" is supported and the AF indication of direct notification is received, the PCF may determine whether duplicate notification is required, i.e., whether the QoS monitoring report is sent to the local AF/NEF by both, the UPF and the PCF.)
NPL 1 does not explicitly teach wherein the method particularly comprises following a UPF relocation, sending a further feature notification to the AF.
In an analogous art Kim teaches wherein the method particularly comprises following a UPF relocation, sending a further feature notification to the AF ([0240] A network control node, e.g., an SMF, supports the operation of one or more of the following items, along with a relocation decision for UPF change for specific traffic. [0241] It is checked whether the AF has previously subscribed to a service for requesting a network control node, e.g., the SMF, to notify an event, i.e., a UP path change, for a specific traffic. [0242] When the notification message regarding the UP path change for specific traffic is transmitted to the AF, the SMF may transmit an indication that the temporary negative notification transmitted by the AF can be additionally processed. [0243] The SMF waits for the response of the notification message for the UP path change transmitted to the AF. In particular, if the AF subscribes to the notification service of the SMF while delivering the “AF acknowledgment to be expected” indication, the SMF should wait for a response message from the AF. [0244] Based on the information included in the response message) or receiving a further feature notification following a Next Generation Radio Access Node (NG- RAN) change. ) (Examiner respectfully notes this element is part of an OR limitation, and since UPF relocation is mapped, this element is not being elected)
It would have been obvious to one of ordinary skill in the art prior to the effective filing of the application to modify the teachings of [NPL 1] to include [providing a notification to the AF in response to UPF change] as is taught by Azorero.
The suggestion/motivation for doing so is provisioning of access network information [Pg 1].
Regarding claim 15, NPL 1 teaches the method of any of claim 11, and is disclosed above, NPL 1 does not explicitly teach further comprising receiving a further feature notification following a User Plane Function (UPF) relocation, or receiving a further feature notification following a Next Generation Radio Access Node (NG- RAN) change. ) (Examiner respectfully notes this element is part of an OR limitation, and since UPF relocation is mapped, this element is not being elected)
In an analogous art Kim teaches receiving a further feature notification following a User Plane Function (UPF) relocation, ([0240] A network control node, e.g., an SMF, supports the operation of one or more of the following items, along with a relocation decision for UPF change for specific traffic. [0241] It is checked whether the AF has previously subscribed to a service for requesting a network control node, e.g., the SMF, to notify an event, i.e., a UP path change, for a specific traffic. [0242] When the notification message regarding the UP path change for specific traffic is transmitted to the AF, the SMF may transmit an indication that the temporary negative notification transmitted by the AF can be additionally processed. [0243] The SMF waits for the response of the notification message for the UP path change transmitted to the AF. In particular, if the AF subscribes to the notification service of the SMF while delivering the “AF acknowledgment to be expected” indication, the SMF should wait for a response message from the AF. [0244] Based on the information included in the response message) or receiving a further feature notification following a Next Generation Radio Access Node (NG- RAN) change. ) (Examiner respectfully notes this element is part of an OR limitation, and since UPF relocation is mapped, this element is not being elected)
It would have been obvious to one of ordinary skill in the art prior to the effective filing of the application to modify the teachings of [NPL 1] to include [receiving a request and provide a response prior to determining if supported] as is taught by Azorero.
The suggestion/motivation for doing so is provisioning of access network information [Pg 1].
Conclusion
Any inquiry concerning this communication or earlier communications from the examiner should be directed to ABDERRAHMEN H CHOUAT whose telephone number is (571)431-0695. The examiner can normally be reached on Mon-Fri from 9AM to 5PM PST.
If attempts to reach the examiner by telephone are unsuccessful, the examiner’s supervisor, Christopher Parry, can be reached at telephone number 571-272-8328. The fax phone number for the organization where this application or proceeding is assigned is 571-273-8300.
Information regarding the status of an application may be obtained from Patent Center. Status information for published applications may be obtained from Patent Center. Status information for unpublished applications is available through Patent Center to authorized users only. Should you have questions about access to the USPTO patent electronic filing system, contact the Electronic Business Center (EBC) at 866-217-9197 (toll-free).
Examiner interviews are available via a variety of formats. See MPEP § 713.01. To schedule an interview, applicant is encouraged to use the USPTO Automated Interview Request (AIR) Form at https://www.uspto.gov/InterviewPractice.
Abderrahmen Chouat
Examiner
Art Unit 2451
/Chris Parry/Supervisory Patent Examiner, Art Unit 2451
