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 .
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 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-20 are rejected under 35 U.S.C. 103 as being unpatentable over US 20220188732 A1 (Boyle et al.) (hereinafter Boyle) in view of US 20190320335 A1 (French et al.) (hereinafter French).
In re claims 1, 8 and 14, Boyle discloses a method (Fig. 4, [0008], “method for determining the most probable cause of a KPI of a telecommunication system”) and a system (Fig. 5, [0014], “The system analyzes the call and determines that the faulty eNodeB is the most probable cause of the failure”) comprising: one or more processors (Fig. 5:510); one or more communication interfaces (Fig. 5:512); and one or more computer-readable media (Fig. 5: 504) storing instructions that, when executed by the one or more processors, cause the one or more processors to perform operations ([0076], “The software 506 may include machine readable instructions of a computer program product that when executed, perform the functions”) comprising:
detecting a voice call event associated with a first user of a first network and a second user of a second network ([0039], “The collection module 120 may also be able to identify VoLTE-To-VoLTE calls. This may be done by analyzing the SIP protocol packets in both directions (uplink and downlink directions on the S1U interface). Specifically, if both the originating and terminating user devices are in the VoLTE RAN, it may be determined that both are VoLTE” (detecting a voice call between two users). [0015], “Additionally, the system includes a database that links network user identities to the particular calls, and each of the calls may be linked to particular user equipment (UE), eNodeB’s, and other network equipment” (linking calls to networks));
receiving cause codes associated with a voice call event associated with a first user of a first network and a second user of a second network (Fig. 3, [0018], “the telecommunication network 104 may include various capture devices 118a, 118b that collect information from network events, such as communication sessions or calls” (collect information from calls). [0061], “For example, the system may receive the protocol event data and calculate a multi-protocol KPI by comparing protocol cause codes and reason codes for multiple protocols across multiple stages of the call to a pre-programmed table of protocol causes. The computed KPI may indicate a plurality of different cause codes in a plurality of different protocols”);
determining, based at least in part on the cause codes, that the voice call event is a voice call drop event ([0038], “Using principles described herein, loosely characterized KPIs such as successful calls, failed calls, dropped calls, mute calls are characterized based on a plurality of protocol and data exchanges associated with such calls” (calls are characterized based on cause codes such as a call drop). [0042], “For example, various combinations of data points from an event object may be associated with a dropped call KPI or a failed registration KPI” (analyzing the quality of call to infer it’s a call drop));
receiving call quality metrics associated with the first network and the voice call event ([0012], “Various embodiments include estimating a score for a telecommunications network, such as a Net Promoter Score (NPS), based on the user and service Key Performance Indicators (KPIs) computed from network data. An example embodiment uses the survey data that contains subscriber information, associated services, and customer rated NPS scores as labelled data and filters network and operator data for the same set of subscribers, computes the user and service KPIs from the network data (e.g., determines the most probable cause for a negative KPI for a call), to train supervised learning models. In addition, since the KPIs may be metrics derived from cause/failure codes, or observed behavior such as mobility, handovers, or inter-working between multiple technologies of underlying protocols, survey results may be mapped to the underlying protocol behavior”. [0014], “In one example, a call with a negative KPI is analyzed to determine a most probable cause of failure”. [0069], “The machine learning algorithm then outputs predicted NPS scores based on the network event data” (receiving and analyzing metrics with call events)); and
determining, based at least in part on the call quality metrics, a responsible party for the voice call event (Fig. 2, [0014], “In one example, a call with a negative KPI is analyzed to determine a most probable cause of failure. For instance, a faulty eNodeB may be causing radio failures, as experienced by the particular call. The system analyzes the call and determines that the faulty eNodeB is the most probable cause of the failure”. [0051], “FIG. 2 is a diagram showing inference of relationships between KPIs 201 and event parameters 211. The event parameters 211 include RAN/cell, device 214, core network 216, and geographic location 218. These event parameters may be associated with a particular event object. For example, an event object representing a particular call may specify which pieces of hardware within the RAN were involved”. [0030], “For example, the major categories may include repeat calls, dropped calls, one-way calls etc. Protocol KPI based characterization (based on protocol cause codes, observed packet behavior etc.) and failure type are identified. The failure types identified are suggestive of cause of failure, and include device cause, RAN-cause, core network cause, IMS-cause, and the like”. [0046], “The inference module 124 may also perform most probable cause analysis. This is explained in more detail below with respect to FIGS. 2 and 3 inference module 124 uses trained machine learning algorithms to process protocol-level data from calls. The inference module 124 then examines metadata from each of the machine learning algorithms to pinpoint a most probable cause that generates a particular KPI for particular set of inputs. An example most probable cause includes a failing eNodeB or an operating system problem at a UE” (root cause analysis includes which network is responsible)).
Boyle does not explicitly disclose receiving metrics associated with the first network and the voice call event.
French discloses receiving metrics associated with the first network (Fig. 1: Network 40) and the voice call event (Fig. 2, [0030], “Analytics system 100 comprises call monitoring software 110 which includes a call monitor 120. Call monitor 120 monitors a call to identify at step 200 of FIG. 3 one or more parameters which are indicative of call quality”. [0020], “A plurality of parameters associated with a telephone call are identified... A probability that a particular network segment is responsible for poor audio quality associated with the telephone call is calculated based on the plurality of parameters” (analyzing parameters for a call quality). [0021], “Embodiments of the present invention may apply in case poor audio quality is suspected as being responsible for the disconnect of a telephone call and is used to determine which network segment is likely to be responsible for the poor audio quality” (call drop). [0022], “The telephony network comprises CSP1's core network 10 which is connected to CSP2's core network 30 by core transmission network 20. A calling party 60 accesses CSP1's core network 10 via access network 40. Similarly, called party 70 accesses CSP2's core network 30 via access network 50. Taking FIG. 1 as an example, a CSP's analysis of CDRs might identify that, in a particular part of CSP1's access network during a given time period, a certain proportion of the calls illustrate evidence of significant voice quality impairments, but many other calls at the same location do not. A conclusion may therefore be reached that the cause of the problem is more likely to exist in the network(s) serving the called parties who are involved in such impaired voice calls” (called party network is responsible i.e. second network). [0026], “Such a determination could be used, for example, to decide whether or not to compensate the party charged for the call” (identifying the network responsible for bad call based on parameters)).
It would have been obvious for one of ordinary skill in the art before the effective filing date of the claimed invention to combine the teachings of Boyle with French to provide a system and a method to identify responsible network for a cross-network call drop event using trained machine algorithms and metrics. The advantage of doing so is better user experience and corrective actions with the responsible parties.
In re claim 2, the combination discloses the method of claim 1, wherein Boyle discloses wherein the responsible party is the second network and the method further comprises: providing a notification to a customer service system including call event data ([0012], “The models facilitate estimating NPS scores for large numbers of users, their services, and their interactions with customer support team without requiring sending online or hardcopy surveys”. [0072], “Another example includes notifying technicians to modify or repair a piece of infrastructure that may be failing. Corrective actions may include customer follow-up after repeated call problems, discounts/promotions after high number of problem calls, or any other action that may be expected to change or increase user satisfaction”).
In re claims 3 and 10, the combination discloses the method of claim 1 and the system of claim 8, wherein Boyle discloses wherein the responsible party is the second network and the method further comprises: determining second user data associated with the second user; and providing the second user data a customer acquisition system ([0018], “the telecommunication network 104 may include various capture devices 118a, 118b that collect information from network events, such as communication sessions or calls” (acquisition system may be at customer end). [0014], “The network operator may then take appropriate action, such as by providing a courtesy call to the affected network user, providing the affected network user with complementary data, or the like”).
In re claims 4 and 9, the combination discloses the method of claim 1 and the system of claim 8, wherein Boyle discloses wherein the responsible party is the second network and the method further comprises: determining one or more second voice call drop events associated with the second network; and determining a geographic region associated with the second network based at least in part on the voice call drop event and the one or more second voice call drop events ([0051], “FIG. 2 is a diagram showing inference of relationships between KPIs 201 and event parameters 211. The event parameters 211 include RAN/cell, device 214, core network 216, and geographic location 218. These event parameters may be associated with a particular event object. For example, an event object representing a particular call may specify which pieces of hardware within the RAN were involved (e.g., which enodeB/cell was connected wirelessly to a mobile device) and thus the geographic location of the call”. [0016], “Other examples include a particular handset model in a geographical area that may have trouble registering with the network, operating system issues on UE, damaged infrastructure such as cables and antennas, and the like”. [0034], “For example, the registration failures could be due to a new vendor device in a particular geographical region of an operator network”. [0043], “The inference module 124 takes the classified event objects and performs various functions to infer relationships from those event objects. For example, in addition to the data points used to classify the event objects, the event objects include several other data points such as type of devices used in the call, geographic location”).
In re claim 5, the combination discloses the method of claim 1, wherein Boyle discloses wherein the responsible party is the first network and the method further comprises: determining, based at least in part on the call quality metrics, a parameter adjustment for the first network ([0052], “FIG. 2 illustrates a number of “bad” KPIs, which include a failed call 202, a failed registration 204, a dropped call 206, and a media failure 208”. [0055], “Each of the inference functions 300 may produce metadata 314. For example, the naïve Bayes function 302 may produce metadata 314a, the generalization function 304 may produce metadata 314b, the deep learning function 306 may produce metadata 314c, the random forest function 308 may produce metadata 314d, and the gradient boost function 312 may produce metadata 316. Using this metadata 314, the analytics platform may determine which of the input parameters is driving the output. The input parameter (s) driving the decision towards the KPI 320 may be deemed the most probable cause 322 for the KPI”. [0051], “The event parameters 211 include RAN/cell, device 214, core network 216, and geographic location 218. These event parameters may be associated with a particular event object. For example, an event object representing a particular call may specify which pieces of hardware within the RAN were involved (e.g., which enodeB/cell was connected wirelessly to a mobile device) and thus the geographic location of the call” (adjusting one or more parameters for a call metric such as moving a UE to a different cell or geographic location)).
In re claim 6, the combination discloses the method of claim 1, wherein Boyle discloses wherein the cause codes are session initiation protocol (SIP) cause codes ([0035], “The rules table 300, illustrated in FIG. 3, combines signaling events (SIP cause codes, reason codes, observations from RTP, SRVCC events from Sv interfaces, S11, S1-MME cause codes etc.) for characterizing dropped calls, and the proportion of each cause code to the dropped calls”).
In re claim 7, the combination discloses the method of claim 1, wherein French discloses wherein the call quality metrics includes at least one of a reference signal received power (RSRP) metric associated with the first network or a reference signal received quality (RSRQ) metric associated with the first network ([0023], “Especially in a wireless network with its varying coverage, it is extremely unusual to have more than one such party sharing enough characteristics to make a comparison feasible. One call party might be close to the cell tower, whilst another call party might be at the cell coverage edge. A call party might suffer from interference whilst another call party might not. One call party might be deep in a large building sheltered by trees with wet leaves whilst another call party might not” (implicitly discloses one of the call quality metrics to be signal strength as measured by RSRP or RSRQ)).
In re claim 11, the combination discloses the system of claim 8, wherein Boyle discloses wherein determining the responsible party for the voice call event is based on a comparison of the call quality metrics to one or more thresholds ([0050], “For instance, a call made by particular user may suffer sub optimal performance, and that call may be run through the inference module 124 to identify most probable cause. Then, the inference module 124 may also predicted NPS score. If the NPS score fits certain criteria (e.g., is below a threshold or is associated with corrective action), then the inference module 124 may also search call records for similarly situated users, such as users who have experienced or may be expected to experience similar performance issues. In one example in which the most probable cause includes an eNodeB failure, then inference module 124 may search a database of call records for other users who often interact with that same eNodeB and then take appropriate action with respect to those different users”).
In re claim 12, the combination discloses the system of claim 8, wherein Boyle discloses wherein determining the responsible party for the voice call event is based on inputting the call quality metrics into one or more machine learned models (Fig. 3, [0053], “Machine learning functions are used to create models that define the relationships between a set of inputs and a set of outputs. Thus, using the models created by such machine learning functions, one can predict that with a certain set of inputs, a certain set of outputs will result”. [0047], “The inference module 124 may include other trained machine learning algorithms that receive most probable cause data and output predicted scores, such as predicted NPS scores”).
In re claims 13 and 19, the combination discloses the system of claim 8 and one or more computer-readable media of claim 14, wherein Boyle discloses wherein the cause codes are session initiation protocol (SIP) cause codes ([0035], “The rules table 300, illustrated in FIG. 3, combines signaling events (SIP cause codes, reason codes, observations from RTP, SRVCC events from Sv interfaces, S11, S1-MME cause codes etc.) for characterizing dropped calls, and the proportion of each cause code to the dropped calls”) and wherein French discloses wherein the call quality metrics includes a reference signal received power (RSRP) metric associated with the first network and a reference signal received quality (RSRQ) metric associated with the first network ([0023], “Especially in a wireless network with its varying coverage, it is extremely unusual to have more than one such party sharing enough characteristics to make a comparison feasible. One call party might be close to the cell tower, whilst another call party might be at the cell coverage edge. A call party might suffer from interference whilst another call party might not. One call party might be deep in a large building sheltered by trees with wet leaves whilst another call party might not” (implicitly discloses one of the call quality metrics to be signal strength as measured by RSRP or RSRQ)).
In re claim 15, the combination discloses one or more computer-readable media of claim 14, wherein French discloses wherein the operations further comprise: receiving second cause codes and second call quality metrics associated with a second voice call event between the first user of the first network and the second user of the second network; and determining, based at least in part on the second cause codes and the second call quality metrics, that the second network is a responsible party for the second voice call event ([0022], “Similarly, called party 70 accesses CSP2's core network 30 via access network 50. Taking FIG. 1 as an example, a CSP's analysis of CDRs might identify that, in a particular part of CSP1's access network during a given time period, a certain proportion of the calls illustrate evidence of significant voice quality impairments, but many other calls at the same location do not. A conclusion may therefore be reached that the cause of the problem is more likely to exist in the network(s) serving the called parties who are involved in such impaired voice calls”. [0054], “Because the call had not been abandoned prior to this part of the call, an increased probability may be reasonably inferred that the segment of the path added upon call answer and transmitting the called party's greeting—i.e. the uplink through the called party CSP's access network 50 from the called party 70—is where the impairment is occurring, as shown in FIG. 6” (here called party is associated with the second network)).
In re claim 16, the combination discloses one or more computer-readable media of claim 15, wherein Boyle discloses wherein the operations further comprise: In response to determining that the second network is the responsible party for the first voice call event and the second voice call event, determining a geographic area associated with the first voice call event and the second voice call event ([0051], “FIG. 2 is a diagram showing inference of relationships between KPIs 201 and event parameters 211. The event parameters 211 include RAN/cell, device 214, core network 216, and geographic location 218. These event parameters may be associated with a particular event object. For example, an event object representing a particular call may specify which pieces of hardware within the RAN were involved (e.g., which enodeB/cell was connected wirelessly to a mobile device) and thus the geographic location of the call”. [0016], “Other examples include a particular handset model in a geographical area that may have trouble registering with the network, operating system issues on UE, damaged infrastructure such as cables and antennas, and the like”. [0034], “For example, the registration failures could be due to a new vendor device in a particular geographical region of an operator network”. [0043], “The inference module 124 takes the classified event objects and performs various functions to infer relationships from those event objects. For example, in addition to the data points used to classify the event objects, the event objects include several other data points such as type of devices used in the call, geographic location”); and sending the geographic area to a customer acquisition system ([0018], “the telecommunication network 104 may include various capture devices 118a, 118b that collect information from network events, such as communication sessions or calls” (acquisition system may be at customer end). [0014], “The network operator may then take appropriate action, such as by providing a courtesy call to the affected network user, providing the affected network user with complementary data, or the like”).
In re claim 17, the combination discloses one or more computer-readable media of claim 15, wherein Boyle discloses wherein the operations further comprise: in response to determining that the second network is the responsible party for the first voice call event and the second voice call event, determining a geographic area associated with the first voice call event and the second voice call event; and sending user data associated with the second user to a customer acquisition system (See “In re claim 16”. All features are covered in claim 16. The geographic data may encompass user data associated with the second user)).
In re claim 18, the combination discloses one or more computer-readable media of claim 14, wherein Boyle discloses wherein the first call quality metrics includes at least one of: an average mean opinion score (MOS) associated with the first network, an average jitter associated with the first network, an average latency associated with the first network, or an average packet loss rate associated with the first network ([0032], “In some examples, if the Mean Opinion Score (MOS) scores are computed in real-time on the collected RTP/RTCP parameters, MOS scores for the duration of the call may be sufficient for the analytic system”. [0035], “Additionally, data reduction may include a density-based reduction in which the protocol cause codes (SIP, Q.850, S11, S1-MME, Sv etc.) along with data observations (such as RTP/RTCP media data) such as packet loss, delay, jitter are used to roll-up to a summary Call-KPI (CPI), and the density (%) of each underlying protocol cause is determined”).
In re claim 20, the combination discloses one or more computer-readable media of claim 19, wherein Boyle discloses wherein the SIP cause codes are received from at least one of a session border controller (SBC) or a telephony application server (TAS) ([0036], “Each of these protocol packets are received via the capture devices 118a, 118b (which may include, for example, an optical tap or mirror port) and processed in a compute server node which may be part of the collection module 120. The collection module 120 may also be referred to as a Data Capture Engine (DCE)”. [0037], “Each protocol uses bidirectional packets. For example, SIP traffic flows from the User Device (UE) to the IMS server, and from the IMS server to the UE” (cause codes received through telephony server)).
Contact
Any inquiry concerning this communication or earlier communications from the examiner should be directed to SWATI JAIN whose telephone number is (571)270-0699. The examiner can normally be reached Mon - Fri (830 am - 530 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, Pan Yuwen can be reached on 571-272-7855. 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.
/SWATI JAIN/Examiner, Art Unit 2649 /YUWEN PAN/Supervisory Patent Examiner, Art Unit 2649
Prosecution Insights