DETAILED ACTION
Notice of 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 .
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.
Election/Restrictions
Applicant's election with traverse of Invention I in the reply filed on 16 Feb 2026 is acknowledged. The traversal is on the ground(s) that “claims of the different claim groups are closely related and could be searched and examined in the current application without placing any undue burden on the Examiner.” Reply, 8. This is not found persuasive because the traversal fails to rebut the underlying premise of the Requirement for Restriction - that a protocol and a REST-API are separate and distinct root causes. The examiner maintains that searching for one, does not necessitate searching for the other. As a result, an undue burden would be placed on the examiner by having to search for two mutually-exclusive inventions.
The requirement is still deemed proper and is therefore made FINAL.
Priority
This Application is the continuation of a US application that claims foreign priority to an Indian application filed on 12 Oct 2020. Receipt is acknowledged of certified copies of papers required by 37 CFR 1.55.
No Prior Art Rejections
Claims 4 and 15 lack a prior art rejection. Figure 5A of Lad shows HTTP availability over a time period. Lad, figure 5A (arrow 502 is a dip in said HTTP availability [i.e. a problem in the application base layer]). Figure 5B of Lad shows packet loss over the same period. Lad, figure 5B and ¶116 (problem at dependent network layer). As a result, while teaching a first and second subsets of event data records, Lad does not teach “wherein the third subset of event data records includes event data records corresponding to a second dependent protocol for the first period of time.”
Claim Objections
Claims 1 and 13 lack a conjunction before their last limitation. Either an “and” or “or” needs to be added to each claim. For the sake of compact prosecution, the Examiner assumes an “and” conjoins the limitations of any claim that lacks a conjunction.
Claims 1 and 13 are objected to under Rule 1.75(d)(1), which requires “the terms and phrases used in the claims must find clear support or antecedent basis in the description.” Claims 1 and 13 recite, in part, “a dependent protocol failure of one of the one or more dependent protocols resulting in a base protocol failure.” The disclosure does not provide antecedent basis for this limitation.
Double Patenting
The nonstatutory double patenting rejection is based on a judicially created doctrine grounded in public policy (a policy reflected in the statute) so as to prevent the unjustified or improper timewise extension of the “right to exclude” granted by a patent and to prevent possible harassment by multiple assignees. A nonstatutory double patenting rejection is appropriate where the conflicting claims are not identical, but at least one examined application claim is not patentably distinct from the reference claim(s) because the examined application claim is either anticipated by, or would have been obvious over, the reference claim(s). See, e.g., In re Berg, 140 F.3d 1428, 46 USPQ2d 1226 (Fed. Cir. 1998); In re Goodman, 11 F.3d 1046, 29 USPQ2d 2010 (Fed. Cir. 1993); In re Longi, 759 F.2d 887, 225 USPQ 645 (Fed. Cir. 1985); In re Van Ornum, 686 F.2d 937, 214 USPQ 761 (CCPA 1982); In re Vogel, 422 F.2d 438, 164 USPQ 619 (CCPA 1970); In re Thorington, 418 F.2d 528, 163 USPQ 644 (CCPA 1969).
A timely filed terminal disclaimer in compliance with 37 CFR 1.321(c) or 1.321(d) may be used to overcome an actual or provisional rejection based on nonstatutory double patenting provided the reference application or patent either is shown to be commonly owned with the examined application, or claims an invention made as a result of activities undertaken within the scope of a joint research agreement. See MPEP § 717.02 for applications subject to examination under the first inventor to file provisions of the AIA as explained in MPEP § 2159. See MPEP § 2146 et seq. for applications not subject to examination under the first inventor to file provisions of the AIA . A terminal disclaimer must be signed in compliance with 37 CFR 1.321(b).
The filing of a terminal disclaimer by itself is not a complete reply to a nonstatutory double patenting (NSDP) rejection. A complete reply requires that the terminal disclaimer be accompanied by a reply requesting reconsideration of the prior Office action. Even where the NSDP rejection is provisional the reply must be complete. See MPEP § 804, subsection I.B.1. For a reply to a non-final Office action, see 37 CFR 1.111(a). For a reply to final Office action, see 37 CFR 1.113(c). A request for reconsideration while not provided for in 37 CFR 1.113(c) may be filed after final for consideration. See MPEP §§ 706.07(e) and 714.13.
The USPTO Internet website contains terminal disclaimer forms which may be used. Please visit www.uspto.gov/patent/patents-forms. The actual filing date of the application in which the form is filed determines what form (e.g., PTO/SB/25, PTO/SB/26, PTO/AIA /25, or PTO/AIA /26) should be used. A web-based eTerminal Disclaimer may be filled out completely online using web-screens. An eTerminal Disclaimer that meets all requirements is auto-processed and approved immediately upon submission. For more information about eTerminal Disclaimers, refer to www.uspto.gov/patents/apply/applying-online/eterminal-disclaimer.
Claims 1-16 are rejected on the ground of nonstatutory double patenting as being unpatentable over claims 1-13, 15, and 19 of U.S. Patent No. 11,979,270 in view of Lad (US 20170005887).
Instant Application
Reference Patent 11,979,270
13. An analytics system comprising: memory; and a first processor, the first processor controlling the analytics system to perform the following operations:
13. An analytics system comprising: memory; and a first processor, the first processor controlling the analytics system to perform the following operations:
generating a plurality of different cross-layer key performance indicators (CL-KPIs) from a set of event data records corresponding to a first period of time and a first base protocol, each CL-KPI in said plurality of different CL-KPIs being for a different failure cause scenario, said first base protocol corresponding to a first protocol layer and being a protocol to which one or more dependent protocols correspond,
a dependent protocol failure of one of the one or more dependent protocols resulting in a base protocol failure;
generating a plurality of different cross-layer key performance indicators (CL-KPIs) from a set of event data records corresponding to a first period of time and a first base protocol, each CL-KPI in said plurality of different CL-KPIs being for a different failure cause scenario, said first base protocol corresponding to a first application and a first protocol layer and being a protocol to which one or more dependent protocols correspond;
identifying a CL-KPI in said plurality of different CL-KPIs corresponding to the first period of time and said first base protocol having a highest CL-KPI value; and
identifying a CL-KPI in said plurality of different CL-KPIs corresponding to the first period of time and said first base protocol having a highest CL-KPI value;
determining a most likely failure cause scenario for said first base protocol to be the failure cause scenario associated with the identified CL-KPI having the highest CL-KPI value.
determining a most likely failure cause scenario for said first base protocol to be the failure cause scenario associated with the identified CL-KPI having the highest CL-KPI value;
wherein the first base protocol is an application layer protocol;
wherein said one or more dependent protocols includes a transport layer protocol used to carry the application layer protocol messages; wherein the first base protocol is Session Initiation Protocol; wherein the first application is a Voice over Long Term Evolution (VoLTE) Service application; wherein the first protocol layer is an application protocol layer in which Session Initiation Protocol messages are executed; and wherein the one or more dependent protocols includes at least one of the following protocols: Transmission Control Protocol (TCP) and User Datagram Protocol (UDP).
As shown in the table above, while instant claim 13 does not have exact same scope as reference claim 13, they are still directed to the same claimed invention. In particular, reference claim 13 lacks one limitation of instant claim 13 – “a dependent protocol failure of one of the one or more dependent protocols resulting in a base protocol failure.” However, as noted below, this limitation appears to be new matter. Additionally, Lad teaches the concept of a problem in one layer manifesting as a problem in another layer. Lad, ¶116 (HTTP [application layer] problem is really a network layer problem). At the time of the effective filing date of the invention, it would have been obvious for one of ordinary skill in the art to define dependent protocol failures, as taught by Lad, when determining the root cause of a network problem, as taught by the claimed invention of claim 13, in order to correlate results of cross-layer troubleshooting. Lad, ¶45.
While no table is provided, instant claims 1-12 are directed to the same invention as reference claims 1-12 in view of the reference patent 11,979,270 in view of Ladd. Instant claim 14 is directed to the same invention as reference claim 15 in view of Ladd and instant claim 16 is directed to the same invention as reference claim 19 in view of Ladd.
Claim Rejections - 35 USC § 112
The following is a quotation of the first paragraph of 35 U.S.C. 112(a):
(a) IN GENERAL.—The specification shall contain a written description of the invention, and of the manner and process of making and using it, in such full, clear, concise, and exact terms as to enable any person skilled in the art to which it pertains, or with which it is most nearly connected, to make and use the same, and shall set forth the best mode contemplated by the inventor or joint inventor of carrying out the invention.
Claims 1-16 rejected under 35 U.S.C. 112(a), as failing to comply with the written description requirement. The claim(s) contains subject matter which was not described in the specification in such a way as to reasonably convey to one skilled in the relevant art that the inventor or a joint inventor, or for applications subject to pre-AIA 35 U.S.C. 112, the inventor(s), at the time the application was filed, had possession of the claimed invention.
Claims 1 and 13 recite a limitation that is unsupported by the disclosure. In particular, the disclosure fails to demonstrate that the Applicant was in possession of an invention that determines a most likely failure cause scenario for a first base protocol, where “a dependent protocol failure of one of the one or more dependent protocols resulting in a base protocol failure.” The Reply specifically identifies paragraphs 23, 24, 83, and 92 as providing written description support for the quoted limitation. Reply, 8. Paragraph 23 describes determining the base protocol having the highest CL-KPI value, “which models the failure rate across a number of protocols that can lead to a failure of the first base protocol.” Spec., ¶23 (emphasis added). While this paragraph possesses a failure of a base protocol, it does not possess one or more dependent protocol failures resulting in the base protocol failure. Paragraph 24 notes that “dependent protocol failures are prerequisites before ever getting to the first base protocol initiated action.” Id., ¶24 (emphasis added). While paragraph 24 possesses dependent protocol failures triggering an action, it does not specify that said action is a base protocol failure. Paragraphs 83 and 92 appear to provide equivalent written description support to what is provided in paragraphs 23 and 24. In short, the disclosure does not demonstrate possession of an invention in which a dependent protocol failure “result[s] in a base protocol failure.”
Claims 2-12 and 14-16 are rejected due to their dependence upon an unsupported claim.
Claim Rejections - 35 USC § 103
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.
Claims 1, 5-6, 10-13, and 16 are rejected under 35 U.S.C. 103 as being unpatentable over Ratakonda (US 20170208487) in view of Lad (US 20170005887).
Regarding claims 1 and 13, Ratakonda teaches a method and an analytics system comprising: memory; and a first processor, the first processor controlling the analytics system, to perform the following operations:
generating a plurality of different cross-layer key performance indicators (CL-KPIs) from a set of event data records corresponding to a first period of time and a first base protocol (Ratakonda, ¶26 – multiple KPIs are generated; Ratakonda, ¶¶28, 46, claim 2 – various KPIs may correspond to different protocols/interfaces [i.e. layers], creating cross-layer KPIs; Ratakonda, ¶¶47, 52 – KPI records analyzed based on time period; Ratakonda, ¶31 – examples of protocols),
each CL-KPI in said plurality of different CL-KPIs being for a different failure cause scenario (Ratakonda, ¶¶49, 51 – each potential root cause/network failure is associated with one or more KPIs),
identifying a CL-KPI in said plurality of different CL-KPIs corresponding to the first period of time and said first base protocol having a highest CL-KPI value (Ratakonda, ¶51, table 2 – “threshold excess score” for each KPI is determined, where the KPI, “tracking area update reject above 1%” [see correlation to table 1], has the highest raw score - 100,000);
determining a most likely failure cause scenario for said first base protocol to be the failure cause scenario associated with the identified CL-KPI having the highest CL-KPI value (Ratakonda, ¶¶28, 52 – determines most likely root cause by sifting though and correlating all relevant KPIs; Ratakonda, ¶46 – KPI root cause analyzer identifies KPIs that are most significantly associated with the network failure; Ratakonda, ¶51, table 2 – root cause description ‘inter MME handover failure” has highest KPI score is given the highest probability score [60%] of being the root cause and is associated with KPI with the highest raw score – 100,000 for the KPI “tracking area update reject above 1%”).
Ratakonda does not explicitly teach (1) “said first base protocol corresponding to a first protocol layer and being a protocol to which one or more dependent protocols correspond” or (2) “a dependent protocol failure of one of the one or more dependent protocols resulting in a base protocol failure.” However, like Ratakonda, which provides “Layer 2 to Layer 7 troubleshooting,” Lad similarly teaches “cross-layer troubleshooting” of application layer delivery. Lad, abstract. In particular, Lad notes that (1) application layer problems may be caused by underlying problems in lower layers. Lad, ¶¶50, 172 (application layer [base protocol] problem may be correlated to a problem at the network layer [dependent protocol]). Lad also teaches (2) a problem at, for example, the network layer results in a problem at the application layer. Lad, ¶116 (network layer problem results in HTTP [application layer] availability drop). At the time of the effective filing date of the invention, it would have been obvious for one of ordinary skill in the art to use the consider the dependency between network layers, as taught by Lad, when determining the root cause of a network problem using KPIs, as taught by Ratakonda, in order to identify performance problems associated with distributed applications. Lad, ¶40.
Regarding claim 5, the combination of Ratakonda and Lad also teaches wherein said one or more dependent protocols includes a plurality of different dependent protocols corresponding to the first base protocol (Lad, ¶¶50, 172 - application layer [base protocol] problem may be correlated to a problem at the network layer [dependent protocol]; Ratakonda, ¶34 – layers 2-7 of the OSI depend upon each other as a protocol stack); the method further comprising: determining which one of the different dependent protocols corresponding to the first base protocol that can cause the determined most likely failure cause scenario has the highest number of failures for the first period of time. Ratakonda, ¶51, table 2 (“threshold excess score” for each KPI is determined, where the KPI, “tracking area update reject above 1%” [see correlation to table 1], has the highest raw score - 100,000). As a result, the protocol [i.e. layer] associated with TAU is found to be the most likely root cause. Ratakonda, ¶26 (RRC layer is the known layer to govern TAU).
Regarding claim 6, the combination of Ratakonda and Lad also teaches determining which portion of a communications network is the most likely source of the failures during the first period of time based on which dependent protocol of said different dependent protocols had the determined highest number of failures for the first period of time. Ratakonda, ¶49, table 1 (possible portions of the network that may be the root cause include the MME, SGW, and/or UE); Lad, ¶124 (determines which layer of the network is causing the problem).
Regarding claims 7 and 16, the combination of Ratakonda and Lad also teaches wherein the plurality of different cross-layer key performance indicators depends on a count of a number of dependent protocol failures of the one or more dependent protocols but does not depend on a count of a number of dependent protocol successes of the one or more dependent protocols for said first period of time. Ratakonda, ¶51, table 2 (“threshold excess score” only counts “rejects” or “failures” and does not consider successes).
Regarding claim 10, the combination of Ratakonda and Lad also teaches wherein the set of event data records for the first period of time excludes event data records for dependent protocols corresponding to successful events, said dependent protocols corresponding to the first base protocol. Ratakonda, ¶51, table 2 (“threshold excess score” only counts “rejects” or “failures” and does not consider the successes of any KPIs and the protocols/layers associated with them); Lad, ¶¶50, 172 (application layer [base protocol] problem may be correlated to a problem at the network layer [dependent protocol]).
Regarding claim 11, the combination of Ratakonda and Lad also teaches capturing or storing only event data records for failures for dependent protocols for the first period of time, said dependent protocols corresponding to the first base protocol. Ratakonda, ¶51, table 2 (“threshold excess score” only counts “rejects” or “failures” and does not consider successes [i.e. no indication that success information is even stored]); Lad, ¶¶50, 172 (application layer [base protocol] problem may be correlated to a problem at the network layer [dependent protocol]).
Regarding claim 12, the combination of Ratakonda and Lad also teaches automatically making a network configuration change in response to determining a most likely failure cause scenario for said first base protocol to be the failure cause scenario associated with the identified CL-KPI having the highest CL-KPI value. Lad, ¶172 (resolves application layer problem); Ratakonda, ¶51 (using KPI with highest raw score to determine most likely root cause).
Claims 2, 3, 8, 9, and 14 are rejected under 35 U.S.C. 103 as being unpatentable over Ratakonda in view of Lad (both of record) and further in view of Safavi (US 2020/267047).
Regarding claim 2, the combination of Ratakonda and Lad teaches the method of claim 1, determining a . . . [listing] of the different failure cause scenarios for said first base protocol for the first period of time using said generated CL-KPIs. Ratakonda, ¶52 (list of most likely root causes is prioritized based on their probability scores). Ratakonda does not explicitly “rank” its list of root causes. However, Safavi teaches the concept of ranking its most likely root causes. Safavi, ¶¶ 4, 124. At the time of the invention (pre-AIA ) or at the effective filing date of the invention (AIA ), it would have been obvious for one of ordinary skill in the art to rank the list of root causes, as taught by Safavi, based on their calculated probabilities, as taught by the combination of Ratakonda and Lad, in order to improve the display, such that the results are sorted based on probability score. Ibid. Specifically, sorted results would enable the user to quickly identify the most likely root cause, thus hastening the process to take corrective actions.
Regarding claims 3 and 14, the combination of Ratakonda and Lad teaches the method/system of claims 1 and 13, wherein generating a plurality of different cross-layer key performance indicators (CL-KPIs) from a set of event data records corresponding to a first period of time and a first base protocol (Ratakonda, ¶26 – multiple KPIs are generated; Ratakonda, ¶¶28, 46 – various KPIs may correspond to different protocol layers and interfaces, creating cross-layer KPIs; Ratakonda, ¶47, 52 – KPI records analyzed based on time period; Ratakonda, ¶31 – examples of base protocols).
The combination of Ratakonda and Lad does not explicitly teach “generating a first failure count by summing a count of failures of the first base protocol detected during the first period of time and a count of failures of different dependent protocols corresponding to the first base protocol detected during the first period of time; dividing said first failure count by a value which is based on a sum of the first failure count and a count of successes of the first base protocol for said first period of time.” Instead, the combination only explicitly teaches the number of failures being counted for each potential root cause. Ratakonda, ¶51, table 2 (“Actual # of rejects” in KPIs column). However, Safavi teaches (1) a network management system with counters for both successful and failed system level experience (SLE) parameters for each specific component and (2) determining the estimated probability of an SLE failure of a specific component based on the number of failures divided by the total number of occurrences (i.e. the sum of failures and successes). Safavi, ¶¶ 17, 19-20. At the time of the invention (pre-AIA ) or at the effective filing date of the invention (AIA ), it would have been obvious for one of ordinary skill in the art to use the counters, as taught by Safavi, within the KPI-based root cause determination, taught by the combination of Ratakonda and Lad, in order to monitor indicators of that affect the experience of the user when accessing the network. Id. at ¶5.
Regarding claim 8, the combination of Ratakonda and Lad teaches the method of claim 7, but does not explicitly teach “wherein the plurality of different cross-layer key performance indicators further depends on a count of a number of said first protocol layer successes for said first period of time.” However, Safavi counts successes when determining a root cause. Infra (see rejection of claim 3 for Safavi considering the total occurrences, which includes successes when determining a root cause). At the time of the invention (pre-AIA ) or at the effective filing date of the invention (AIA ), it would have been obvious for one of ordinary skill in the art to use the counters, taught by Safavi, within the KPI-based root cause determination, taught by the combination of Ratakonda and Lad, in order to monitor indicators of that affect the experience of the user when accessing the network. Id. at ¶5.
Regarding claim 9, the combination of Ratakonda, Lad, and Safavi also teaches generating a visual dashboard on a display device, said visual dashboard including the identified cross-layer key performance indicator and the failures corresponding to each dependent protocol of the one or more dependent protocols for the first period of time. Ratakonda, ¶52 and figure 4B (display results via user interface); Ratakonda, ¶46 (dependence between failures based on timestamp); Lad, ¶¶50, 172 (application layer [base protocol] problem may be correlated to a problem at the network layer [dependent protocol]).
Conclusion
Any inquiry concerning this communication or earlier communications from the examiner should be directed to BENJAMIN S LAMONT whose telephone number is (571)270-7514 and email address is benjamin.lamont@uspto.gov (see MPEP 502.03 for using EFS or mail, but not email to authorize electronic communications). The examiner can normally be reached M-F 7am to 3pm 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, Huy Vu can be reached at 571-272-3155. 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.
/Benjamin Lamont/Primary Examiner, Art Unit 2461