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 . Claims 23-25, 27-32, 34-44 are currently pending. Claims 38-43 are withdrawn from consideration.
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) 23-25, 27-37, and 44 is/are rejected under 35 U.S.C. 102(a)(1) as being anticipated by 3GPP TR 28.809 V0.4.0: Study on enhancement of Management Data Analytics (MDA) (Release 17), referred hereafter as D1.
Regarding claim 23, D1 discloses an apparatus comprising: memory to store self-organizing network (SON) conflict data (section 6.6.1.1; collecting/obtaining historical and current network performance data, performance measurements etc. by MDAS producer for analysis); and processing circuitry, coupled with the memory, to: identify, based on the SON conflict data, a potential or existing SON conflict (section 6.9.1.1; identifying potential/occurred SON conflict by analyzing data such as historical and the most recent changes made by the SON functions, current network configurations, historical and current network performance data related to the SON function(s) and the relevant non-SON functions (load information of the NR cells, handover performance measurements), policies and targets for the SON functions), wherein the SON conflict data includes an indication of a network resource model (NRM) update made by an SON function or a non-SON function (section 6.1.1.3.2; analyzing the data includes configuration data which comprises attributes contained in NRMs and NRM updates that include changes or creations of MOIs affecting RAN coverage); wherein the SON conflict data includes an indication of a radio link failure (RLF) report (section 6.1.1.3.2; analyzing the data includes performance measurements which comprises RLF reports) (sections 6.8.1.1 and 6.8.1.3.1; SON conflict (potential or already occurred) is identified by RLF report/data analyzed and correlated by the MDAS producer); and provide an analytics report to management data analytics service (MDAS) consumer that includes an indication of the potential or existing SON conflict (section 6.9.1.1; MDAS producer provides an analytics report to described potential/occurred SON conflict between SON functions or between SON function and non-SON function).
Regarding claim 24, D1 further suggests wherein the SON conflict data includes an indication of a performance measurement associated with an SON function (section 6.9.1.1; identifying potential/occurred SON conflict by analyzing data such as historical and the most recent changes made by the SON functions, current network configurations, historical and current network performance data related to the SON function(s) and the relevant non-SON functions (load information of the NR cells, handover performance measurements), policies and targets for the SON functions).
Regarding claim 25, D1 further suggests wherein the SON conflict data includes an indication of an attribute of a managed object instance (MOI), a policy of an SON function, or a target of an SON function (section 6.1.1.3.2; analyzing the data includes configuration data which comprises attributes contained in NRMs and NRM updates that include changes or creations of MOIs affecting RAN coverage) (section 6.9.1.1; identifying potential/occurred SON conflict by analyzing data such as historical and the most recent changes made by the SON functions, current network configurations, historical and current network performance data related to the SON function(s) and the relevant non-SON functions (load information of the NR cells, handover performance measurements), policies and targets for the SON functions).
Regarding claim 27, D1 further suggests wherein the analytics report includes an indication of: conflict type, a conflicting functions identifier, a conflicting attribute, or a conflict reason (section 6.1.1.3.3; the analytics report describing the coverage issue contains the following information: coverage issue type indication, root cause, affected objects, recommended actions etc.).
Regarding claim 28, D1 further suggests wherein the analytics report includes an indication of an energy-saving instruction identifier (section 6.6.1.3.3; analytics report includes energy efficiency issue identifier which is identifier of MDA assisted energy saving).
Regarding claim 29, D1 further suggests wherein the analytics report includes an indication of a new radio (NR) cell to enter an energy saving state or a user plane function (UPF) to enter an energy-saving state (section 6.6.1.1; MDAS can be used to provide an analytic report by analyzing the information comprehensively to assist the energy saving related decision making. The information such as load information of related cells and energy saving policies is used to achieve energy saving by activating the energy saving mode of the NR capacity booster cell or 5GC NF (e.g. UPF etc.)).
Regarding claim 30, D1 further suggests wherein the processing circuitry is further to cause the MDAS producer to provide a training report to the MDAS consumer, the training report including an indication of: a training identifier, a validation feedback identifier, a training result, or a failure cause (section 6.1.1.3.3; the analytics report describing the coverage issue contains the following information: coverage issue type indication, root cause, affected objects, recommended actions etc.) (section 6.1.1.1; MDAS producer provides the analytics report to MDAS consumer to take remedy actions) (section 5.3; consumer may validate the output data provided by the MDAS producer. The output data to be validated may be the analytics report and/or the ML model training report. The consumer may provide the validation data as feedback to the MDAS producer).
Regarding claim 31, D1 discloses one or more non-transitory computer-readable media storing instructions that, when executed by one or more processors, cause a management data analytics service (MDAS) producer to: receive self-organizing network (SON) conflict data (section 6.6.1.1; collecting/obtaining historical and current network performance data, performance measurements etc. by MDAS producer for analysis) that includes an indication of a network resource model (NRM) update made by an SON function or a non-SON function (section 6.1.1.3.2; analyzing the data includes configuration data which comprises attributes contained in NRMs and NRM updates that include changes or creations of MOIs affecting RAN coverage), and an indication of a radio link failure (RLF) report (section 6.1.1.3.2; analyzing the data includes performance measurements which comprises RLF reports) (sections 6.8.1.1 and 6.8.1.3.1; SON conflict (potential or already occurred) is identified by RLF report/data analyzed and correlated by the MDAS producer); identify, based on the SON conflict data, a potential or existing SON conflict (section 6.9.1.1; identifying potential/occurred SON conflict by analyzing data such as historical and the most recent changes made by the SON functions, current network configurations, historical and current network performance data related to the SON function(s) and the relevant non-SON functions (load information of the NR cells, handover performance measurements), policies and targets for the SON functions); and provide an analytics report to an MDAS consumer that includes an indication of the potential or existing SON conflict (section 6.9.1.1; MDAS producer provides an analytics report to described potential/occurred SON conflict between SON functions or between SON function and non-SON function).
Regarding claim 32, D1 further suggests wherein the SON conflict data includes an indication of a performance measurement associated with an SON function (section 6.9.1.1; identifying potential/occurred SON conflict by analyzing data such as historical and the most recent changes made by the SON functions, current network configurations, historical and current network performance data related to the SON function(s) and the relevant non-SON functions (load information of the NR cells, handover performance measurements), policies and targets for the SON functions).
Regarding claim 34, D1 further suggests wherein the analytics report includes an indication of: a conflict type, a conflicting functions identifier, a conflicting attribute, or a conflict reason(section 6.1.1.3.3; the analytics report describing the coverage issue contains the following information: coverage issue type indication, root cause, affected objects, recommended actions etc.).
Regarding claim 35, D1 further suggests wherein the analytics report includes an indication of an energy-saving instruction identifier (section 6.6.1.3.3; analytics report includes energy efficiency issue identifier which is identifier of MDA assisted energy saving).
Regarding claim 36, D1 further suggests wherein the analytics report includes an indication of a new radio (NR) cell to enter an energy saving state or a user plane function (UPF) to enter an energy-saving state (section 6.6.1.1; MDAS can be used to provide an analytic report by analyzing the information comprehensively to assist the energy saving related decision making. The information such as load information of related cells and energy saving policies is used to achieve energy saving by activating the energy saving mode of the NR capacity booster cell or 5GC NF (e.g. UPF etc.)).
Regarding claim 37, D1 further suggests wherein the media further stores instructions to cause the MDAS producer to provide a training report to the MDAS consumer, the training report including an indication of: a training identifier, a validation feedback identifier, a training result, or a failure cause (section 6.1.1.3.3; the analytics report describing the coverage issue contains the following information: coverage issue type indication, root cause, affected objects, recommended actions etc.) (section 6.1.1.1; MDAS producer provides the analytics report to MDAS consumer to take remedy actions) (section 5.3; consumer may validate the output data provided by the MDAS producer. The output data to be validated may be the analytics report and/or the ML model training report. The consumer may provide the validation data as feedback to the MDAS producer).
Regarding claim 44, D1 further suggests wherein the SON conflict data includes an indication of an attribute of a managed object instance (MOI), a policy of an SON function, or a target of an SON function (section 6.8.1.3.1 and 6.8.1.3.2, discloses that the data required (configuration data NRM) for SON conflict analysis include the execution data including the changes or the configuration (attributes) of the MOIs, policy and targets of the SON functions).
Response to Remarks/Arguments
Applicant's remarks/arguments filed 11/25/2025 have been fully considered but they are not persuasive. On pages 7-8 of the Applicant’s remarks regarding the amended claim 23, Applicant disagrees and submits that the cited section of D1 relates to coverage analysis and is not tied in any manner to SON conflict detection. The RLF reports mentioned in D1 are used to determine any coverage issues. D1 clearly states that "The MDAS producer correlates, processes and analyzes the data described in the following subclause within a time period on a regular basis or trigged by events (e.g., the RLF reports) to identify the coverage issue, and provide the analytics reports to describe the identified coverage issues (which could be new issues or the updates of existing issues)." (D1 at section 6.1.1.3.1; emphasis added). Clearly, the RLF report of D1 has nothing to do with SON conflict data or SON conflict analysis. Thus, Applicant submits that D1 does not teach or suggest "wherein the SON conflict data includes an indication of a radio link failure (RLF) report". In response, the Examiner respectfully disagrees with the Applicant’s assertion that D1 does not teach or suggest "wherein the SON conflict data includes an indication of a radio link failure (RLF) report" as recited in the amended claim 23. For further clarification, D1, in section 6.8.1.1, discloses that RLF data/report is analyzed by the MDAS to identifying potential SON conflict or a SON conflict that occurred. If SON conflict is identified, MDAS provides an analytics report to describe the conflict. D1, in section 6.8.1.3.1 and the table in section 6.8.1.3.2, also discusses that the MDAS correlates and analyzes the data (MDT/RLF data) described in table triggered by the RLF report to identify a SON conflict (potential or already occurred) and provides the analytics report to describe the SON conflict. Thus the RLF report of D1 clearly correlates with SON conflict data or SON conflict analysis to provide the analytics report. Therefore, D1 clearly discloses "wherein the SON conflict data includes an indication of a radio link failure (RLF) report".
Applicant further submits that D1 does not disclose "wherein the SON conflict data includes an indication of a network resource model (NRM) update made by an SON function or a non-SON function." D1 mentions that MDA should analyze configuration changes (NRM updates) in the network, but only in the context of RAN coverage issues or as generic "changes made by SON functions" for conflicts. Notably, D1 never explicitly or implicitly teaches capturing the identity of the function (SON vs. non-SON) responsible for a given NRM update as part of the conflict analytics data. In the present case, notifications of NRM updates are stored with the ID of the SON or non-SON function that made the change. This ensures the conflict data explicitly links each configuration change to its source (e.g., which SON algorithm or manual operation triggered it). Applicant submits that D1 is silent on attaching such source identifiers to the data. Thus, claim 23's requirement that the conflict data include an indication of an NRM update made by a SON or non-SON function is not met by D1. In response, the Examiner respectfully disagrees with the Applicant’s assertion that D1 does not disclose or suggest "wherein the SON conflict data includes an indication of a network resource model (NRM) update made by an SON function or a non-SON function." For further clarification, D1, in section 6.8.1.3.1 and 6.8.1.3.2, discloses the MDAS producer correlates and analyzes the data described in table on a regular basis to identify a SON conflict (potential or already occurred) and provides the analytics report to describe the SON conflict. The Data required for SON conflict analysis includes notifications of the NRM updates made by SON functions or non-SON functions. The notification needs to include the ID of the SON function or non-SON function who made the NRM updates. Thus, D1 explicitly discloses capturing the identity of the function (SON vs. non-SON) responsible for a given NRM update as part of the conflict analytics data and notifications of NRM updates are stored/captured with the ID of the SON or non-SON function that made the change. Therefore D1 clearly discloses "wherein the SON conflict data includes an indication of a network resource model (NRM) update made by an SON function or a non-SON function."
Applicant further submits there is no disclosure in D1 of a memory that stores a compiled set of SON conflict indicators. In short, claim 23's recitation of an apparatus explicitly storing "SON conflict data" (with specific conflict-triggering inputs like NRM change logs). In response, the Examiner respectfully disagrees with the Application’s assertion that D1 does not disclose storing "SON conflict data" (with specific conflict-triggering inputs like NRM change logs). D1, in section 6.8.1.3.1 and 6.8.1.3.2, discloses that the data required (configuration data NRM) for SON conflict analysis include the execution data including the changes or the configuration (attributes) of the MOIs and including historical UE configurations. The required data (measurements, NRM updates, RLF data, QoE data, configuration data, affected parameters) for SON conflict analysis is inherently stored for processing by MDAS producer to correlate and analyze to identify a SON conflict (potential or already occurred). Thus D1 indeed suggests storing "SON conflict data" as claimed. Therefore the rejection of claim 23 have been maintained for at least all the reasons discussed above.
For claim 27, the Applicant submits that D1 is related to analytics report for coverage issues and not for SON conflict issues. D1 does not enumerate any of the above-recited fields in its description of the analytics report. It merely says the report describes the coverage issues. Notably, D1 is silent about indicating which functions were in conflict or the precise reason/parameter for the conflict information. In response, the Examiner respectfully disagrees with the Applicant’s assertion that D1 does not disclose "wherein the analytics report includes an indication of: conflict type, a conflicting functions identifier, a conflicting attribute, or a conflict reason." D1, in section 6.8.1.3.3, discloses that the Analytics report for SON conflict prevention and resolution includes conflicting functions ID, Conflict type, Conflicting attributes, Conflicting reason, Conflicting metrics, Attribute conflict status, and recommended actions. Thus, D1 indeed, discloses disclose "wherein the analytics report includes an indication of: conflict type, a conflicting functions identifier, a conflicting attribute, or a conflict reason." as claimed. Therefore the rejection of claim 27 has been maintained for at least the reason discussed above. The rejections of independent claim 31 have also been maintained for at least the reasons discussed with respect to claim 23 above.
Conclusion
THIS ACTION IS MADE FINAL. Applicant is reminded of the extension of time policy as set forth in 37 CFR 1.136(a).
A shortened statutory period for reply to this final action is set to expire THREE MONTHS from the mailing date of this action. In the event a first reply is filed within TWO MONTHS of the mailing date of this final action and the advisory action is not mailed until after the end of the THREE-MONTH shortened statutory period, then the shortened statutory period will expire on the date the advisory action is mailed, and any nonprovisional extension fee (37 CFR 1.17(a)) pursuant to 37 CFR 1.136(a) will be calculated from the mailing date of the advisory action. In no event, however, will the statutory period for reply expire later than SIX MONTHS from the mailing date of this final action.
Any inquiry concerning this communication or earlier communications from the examiner should be directed to HOANG-CHUONG Q VU whose telephone number is (571)270-3945. The examiner can normally be reached Monday-Friday (9:30-5:30 PM 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, AYAZ SHEIKH can be reached at 571-272-3795. 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.
HOANG-CHUONG Q. VU
Primary Examiner
Art Unit 2476
/HOANG-CHUONG Q VU/Primary Examiner, Art Unit 2476