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 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.
Claim(s) 1, 5-6, 10-12, 15-17, 20 is/are rejected under 35 U.S.C. 102/103 as being anticipated by NPL - 8rd Generation Partnership Project; Technical Specification Group Services and System Aspects; Management and orchestration; Study on enhancement of Management Data Analytics (MDA) (Release 17)", 3GPP STANDARD; TECHNICAL REPORT; 3GPP TR 28.809, 3RD GENERATION PARTNERSHIP PROJECT (8GPP), MOBILE COMPETENCE CENTRE ; 650, ROUTE DES LUCIOLES ; F-06921 SOPHIA-ANTIPOLIS CEDEX ; FRANCE no. V1.1.0 4 December 2020 (2020-12-04), pages 1-93, XP051961771, (from IDS filed by Applicant 9/12/24) in view of Kiu US 20160330067
1. A network issue information sending method, applied to a first apparatus (NPL: "MDAS producer") (see in particular page 12, section 4.1 Overview; page 14/15, section 5.2 Management interaction with NWDAF and gNB; figure 5.2-1), wherein the method comprises:
receive a first request, wherein the first request includes the following: a network issue query condition and network issue indication information (NPL: procedure may be triggered by the request or periodically; page 21, 6.2.1.3.1, page 87, section 6.99.2.1 – e.g., The consumer submits a request to MDAS producer to subscribe to the MDA reports … the consumer may indicate the method that the MDA reports are to be reported);
in response to the first request, determining first information ("analytics report ") about a network issue, wherein the determining the first information includes determining diagnosis information of the network issue, and the diagnosis information describes an analysis result of the network issue (NPL: "Once the coverage issue is detected, the MDAS producer provides the analytics report that precisely describes the coverage issue, and the analytics report needs to contain sufficient information to enable the MDAS consumer (e.g., SON CCO function) to take the remedy actions. The MDAS producer may also provide the recommended actions to solve the identified coverage issue in the analytics report" page 17, section 6.1.1.1 Use case; "REQ-ALARM_MDA-01: The MDAS producer should have a capability to provide the analytics report describing the alarm incident analysis. REQ-ALARM_MDA-02: The analytics report describing the alarm incident should include the following information: - Alarm incident Identifier, - List of Correlated Alarms, performance measurements, - The start time and end time of the Alarm incident, - The root cause or root alarm of the Alarm incident, - Severity level, - Affected objects, - Recommended actions" page 49, section 6.4.1.2 Potential requirements: The MDAS producer provides an analytics report describing the alarm incident analysis on detection of a network issue / alarm. The analytics report comprises an alarm incident identifier; List of Correlated Alarms, performance measurements; start time and end time of the Alarm incident; root cause or root alarm of the Alarm incident; Severity level; Affected objects and recommended actions. Where the List of Correlated Alarms, performance measurements; start time and end time of the Alarm incident; root cause or root alarm of the Alarm incident; Severity level and Affected objects correspond to diagnosis information of the network issue / analysis result and the recommended actions correspond to a recovery information / status); and
sending the first information to a second apparatus (NPL: "The MDAS producer may also provide the recommended actions to solve the identified coverage issue in the analytics report, so that the MDAS consumer can execute the actions accordingly or by taking the recommended actions into account." page 17, section 6.1.1.1 Use case; figure 5.2-1: The MDAS producer sends the analytics report to an MDAS consumer).
wherein the determining the diagnosis information of the network issue includes determining one or more of a cause of the network issue, a recovery capability corresponding to the network issue, or a predicted recovery result of the network issue (NPL: page 49, section 6.4.1.2, section 5.1 - analysis result and the recommended actions correspond to a recovery information / status);
wherein the determining the recovery capability includes determining the first apparatus is able to recover the network issue or the first apparatus is not able to recover the network issue (NPL: analysis result and the recommended actions correspond to a recovery information / status, page 17, section 6, 6.1.1.1 Use case; page 20, section 6.2 Resource related issues, 6.2.1 RAN user plane congestion analysis, 6.2.1.1 Use case - page 47, section 6.3.7 Jitter analysis; section 6.5.3.3.3 - e.g., list of cells in the selected cluster, for which it is predicted that those will be congested at the Prediction Horizon); and
wherein the determining the predicted recovery result of the network issue includes determining a predicted network performance indicator obtained after the network issue is recovered (NPL: predictive analytics can make it possible to take anticipatory steps, e.g., list of cells in the selected cluster, for which it is predicted that the congestion shall ease out at the Prediction Horizon)
NPL merely discloses the term “apparatus”
Liu teaches the term apparatus (Liu: [0052] an apparatus)
Thus, it would have been obvious to one skill in the art before the effective filing date of the claim invention to include the above recited limitation into NPL’s invention in order to perform fault recovery, as taught by Liu.
5. The method according to claim 1, wherein the determining the diagnosis information of the network issue further includes determining a recovery suggestion for the network issue; wherein the determining the recovery suggestion for the network issue includes determining an operation of the first apparatus to recover the network issue (NPL: the analytics report needs to contain sufficient information to enable the MDAS consumer (e.g., SON CCO function) to take the remedy actions. The MDAS producer may also provide the recommended actions to solve the identified coverage issue in the analytics report, so that the MDAS consumer can execute the actions accordingly or by taking the recommended actions into account." page 17, section 6.1 Coverage related issues, 6.1.1 Coverage issue analysis, 6.1.1.1 Use case).
Regarding claims 6, 10-12, 15-17, 20, the independent claim and each dependent claim are related to the same limitation set for hereinabove in claims 1, 5, where the difference used is a “apparatus” with a processor and a memory (Liu: Referring to FIG. 4, unit 400) and the wordings of the claims were interchanged within the claim itself or some of the claims were presented as a combination of two or more previously presented limitations. This change does not affect the limitation of the above treated claims. Adding these phrases to the claims arid interchanging the wording did not introduce new limitations to these claims. Therefore, these claims were rejected for similar reasons as stated above.
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.
Claim(s) 1, 5-6, 10-12, 15-17, 20 is/are rejected under 35 U.S.C. 102/103 as being anticipated by NPL - 8rd Generation Partnership Project; Technical Specification Group Services and System Aspects; Management and orchestration; Study on enhancement of Management Data Analytics (MDA) (Release 17)", 3GPP STANDARD; TECHNICAL REPORT; 3GPP TR 28.809, 3RD GENERATION PARTNERSHIP PROJECT (8GPP), MOBILE COMPETENCE CENTRE ; 650, ROUTE DES LUCIOLES ; F-06921 SOPHIA-ANTIPOLIS CEDEX ; FRANCE no. V1.1.0 4 December 2020 (2020-12-04), pages 1-93, XP051961771, (from IDS filed by Applicant 9/12/24) in view of Yao US 2021/037400 (from IDS filed by Applicant 9/12/24)
1. A network issue information sending method, applied to a first apparatus (NPL: "MDAS producer") (see in particular page 12, section 4.1 Overview; page 14/15, section 5.2 Management interaction with NWDAF and gNB; figure 5.2-1), wherein the method comprises:
receive a first request, wherein the first request includes the following: a network issue query condition and network issue indication information (NPL: procedure may be triggered by the request or periodically; page 21, 6.2.1.3.1, page 87, section 6.99.2.1 – e.g., The consumer submits a request to MDAS producer to subscribe to the MDA reports … the consumer may indicate the method that the MDA reports are to be reported);
in response to the first request, determining first information ("analytics report ") about a network issue, wherein the determining the first information includes determining diagnosis information of the network issue, and the diagnosis information describes an analysis result of the network issue (NPL: "Once the coverage issue is detected, the MDAS producer provides the analytics report that precisely describes the coverage issue, and the analytics report needs to contain sufficient information to enable the MDAS consumer (e.g., SON CCO function) to take the remedy actions. The MDAS producer may also provide the recommended actions to solve the identified coverage issue in the analytics report" page 17, section 6.1.1.1 Use case; "REQ-ALARM_MDA-01: The MDAS producer should have a capability to provide the analytics report describing the alarm incident analysis. REQ-ALARM_MDA-02: The analytics report describing the alarm incident should include the following information: - Alarm incident Identifier, - List of Correlated Alarms, performance measurements, - The start time and end time of the Alarm incident, - The root cause or root alarm of the Alarm incident, - Severity level, - Affected objects, - Recommended actions" page 49, section 6.4.1.2 Potential requirements: The MDAS producer provides an analytics report describing the alarm incident analysis on detection of a network issue / alarm. The analytics report comprises an alarm incident identifier; List of Correlated Alarms, performance measurements; start time and end time of the Alarm incident; root cause or root alarm of the Alarm incident; Severity level; Affected objects and recommended actions. Where the List of Correlated Alarms, performance measurements; start time and end time of the Alarm incident; root cause or root alarm of the Alarm incident; Severity level and Affected objects correspond to diagnosis information of the network issue / analysis result and the recommended actions correspond to a recovery information / status); and
sending the first information to a second apparatus (NPL: "The MDAS producer may also provide the recommended actions to solve the identified coverage issue in the analytics report, so that the MDAS consumer can execute the actions accordingly or by taking the recommended actions into account." page 17, section 6.1.1.1 Use case; figure 5.2-1: The MDAS producer sends the analytics report to an MDAS consumer).
wherein the determining the diagnosis information of the network issue includes determining one or more of a cause of the network issue, a recovery capability corresponding to the network issue, or a predicted recovery result of the network issue (NPL: page 49, section 6.4.1.2, section 5.1 - analysis result and the recommended actions correspond to a recovery information / status);
wherein the determining the recovery capability includes determining the first apparatus is able to recover the network issue or the first apparatus is not able to recover the network issue (NPL: analysis result and the recommended actions correspond to a recovery information / status, page 17, section 6, 6.1.1.1 Use case; page 20, section 6.2 Resource related issues, 6.2.1 RAN user plane congestion analysis, 6.2.1.1 Use case - page 47, section 6.3.7 Jitter analysis; section 6.5.3.3.3 - e.g., list of cells in the selected cluster, for which it is predicted that those will be congested at the Prediction Horizon); and
wherein the determining the predicted recovery result of the network issue includes determining a predicted network performance indicator obtained after the network issue is recovered (NPL: predictive analytics can make it possible to take anticipatory steps, e.g., list of cells in the selected cluster, for which it is predicted that the congestion shall ease out at the Prediction Horizon)
NPL merely discloses the term “apparatus”
Yao teaches the term apparatus (Yao: [0162] an apparatus to operate as a Management Data Analytics Service (MDAS) producer)
Yao further teaches receive a first request, wherein the first request includes the following: a network issue query condition and network issue indication information (Yao: [0101, 0103] The MDAS producer sends notifications about readiness of the analytics report file to the consumers who have subscribed to the analytics reports on coverage issues);
in response to the first request, determining first information ("analytics report ") about a network issue, wherein the determining the first information includes determining diagnosis information of the network issue, and the diagnosis information describes an analysis result of the network issue (Yao: [0073] the MDA can identify ongoing issues impacting the performance of the network and service, and discover in advance the potential issues that would cause potential failure and/or performance degradation. MDA can also assist to predict the network and service demand to enable the timely resource provisioning); and
sending the first information to a second apparatus (Yao: [0073] deployments which would allow fast time-to-market network and service deployment).
wherein the determining the diagnosis information of the network issue includes determining one or more of a cause of the network issue, a recovery capability corresponding to the network issue, or a predicted recovery result of the network issue (Yao: [0101-0102] the MDA can identify ongoing issues impacting the performance of the network and service, and discover in advance the potential issues that would cause potential failure and/or performance degradation. MDA can also assist to predict the network and service demand to enable the timely resource provisioning),
wherein the determining the recovery capability includes determining the first apparatus is able to recover the network issue or the first apparatus is not able to recover the network issue (Yao: [0064-0070, 0102-0106] the MDA can identify ongoing issues impacting the performance of the network and service, and discover in advance the potential issues that would cause potential failure and/or performance degradation. MDA can also assist to predict the network and service demand to enable the timely resource provisioning); and
wherein the determining the predicted recovery result of the network issue includes determining a predicted network performance indicator obtained after the network issue is recovered (Yao: [0101-0102, 0080] the MDA can identify ongoing issues impacting the performance of the network and service, and discover in advance the potential issues that would cause potential failure and/or performance degradation. MDA can also assist to predict the network and service demand to enable the timely resource provisioning).
Thus, it would have been obvious to one skill in the art before the effective filing date of the claim invention to include the above recited limitation into NPL’s invention in order to determine analytics and diagnose issues impacting the performance of the mobile network, as well as predicting potential future issues, as taught by Yao.
5. The method according to claim 1, wherein the determining the diagnosis information of the network issue further includes determining a recovery suggestion for the network issue; wherein the determining the recovery suggestion for the network issue includes determining an operation of the first apparatus to recover the network issue (NPL: the analytics report needs to contain sufficient information to enable the MDAS consumer (e.g., SON CCO function) to take the remedy actions. The MDAS producer may also provide the recommended actions to solve the identified coverage issue in the analytics report, so that the MDAS consumer can execute the actions accordingly or by taking the recommended actions into account." page 17, section 6.1 Coverage related issues, 6.1.1 Coverage issue analysis, 6.1.1.1 Use case; Yao: [0064-0070, 0102-0106]).
Regarding claims 6, 10-12, 15-17, 20, the independent claim and each dependent claim are related to the same limitation set for hereinabove in claims 1, 5, where the difference used is a “apparatus” with a processor and a memory (Yao: Referring to FIG. 1, the device includes a processor, a memory) and the wordings of the claims were interchanged within the claim itself or some of the claims were presented as a combination of two or more previously presented limitations. This change does not affect the limitation of the above treated claims. Adding these phrases to the claims arid interchanging the wording did not introduce new limitations to these claims. Therefore, these claims were rejected for similar reasons as stated above.
Response to Amendment
Applicant's arguments with respect to claim(s) 1, 5-6, 10-12, 15-17, 20 have been considered but are moot in view of the new ground(s) of rejection.
Remark:
The examiner stresses that the claims are too broad and require detail or specialization of the steps as recited in the claims. Alone and as claimed, the limitations are too open.
Examiner has cited particular portions of the references as applied to each claim limitation for the convenience of the applicant. Although the specified citations are representative of the teachings of the art and are applied to the specific limitations within the individual claim, other passages and figures may apply as well. It is respectfully requested from the applicant in preparing responses, to fully consider the references in entirety as potentially teaching all or part of the claimed invention, as well as the context of the passage as taught by the prior art or disclosed by the Examiner.
In addition, an interview could expedite the prosecution.
Conclusion
Any inquiry concerning this communication or earlier communications from the examiner should be directed to Sulaiman Nooristany whose telephone number is 571-270-1929. The examiner can normally be reached on Monday thru Friday: 8:30am to 5:00pm (EST). If attempts to reach the examiner by telephone are unsuccessful, the examiner’s supervisor, Jeff Rutkowski can be reached on 571-270-1215. 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 the Patent Application Information Retrieval (PAIR) system. Status information for published applications may be obtained from either Private PAIR or Public PAIR. Status information for unpublished applications is available through Private PAIR only. Should you have questions on access to the Private PAIR system, contact the Electronic Business Center (EBC) at 866-217-9197 (toll-free). If you would like assistance from a USPTO Customer Service Representative or access to the automated information system, call 800-786-9199 (IN USA OR CANADA) or 571-272-1000.
/SULAIMAN NOORISTANY/
Primary Examiner, Art Unit 2415
Prosecution Insights