DETAILED ACTION
The present application, filed on or after March 16, 2013, is being examined under the first inventor to file provisions of the AIA .
This action is responsive to communications: Application filed on 4/4/2024.
Claims 1-20 are pending. Claims 1, 12, and 20 are independent.
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.
Claim(s) 1-20 is/are rejected under 35 U.S.C. 103 as being unpatentable over Haggerty (US10,965,806) in view of Verma et al. (US11,729,309).
In regards to claim 1, Hagarty et al. discloses a computer-implemented method for using a model that is trained off a computing device to improve voice call quality on the computing device comprising:
receiving, by an application of the computing device, the model that is trained using machine learning and that is configured to determine a given cause of a given event that is affecting given voice call quality on the computing device (Haggarty col17 ln33-45, invokes a voice quality module to predict cause of poor voice quality and possible action to improve call quality col19 ln34-42, Voice quality module makes use of one or more predictive models); and
accessing, by the application, network data that indicates characteristics of a network with which the computing device is communicating (Haggerty et al. Fig. 1 col5 ln29-44, parameters may be associated with the network over which the call is carried (network parameter))
providing, by the application, the device data, the network data, and data identifying an event that is affecting voice call quality on the computing device as an input to the model (Haggarty et al. col 17 ln10-32, party’s service provider and whether the party is using a mobile device or landline may be provided as input to identify cause of poor voice quality);
receiving, by the application and from the model, data indicating a cause of the event (Haggarty et al. col 17 ln33-42, the voice quality module identifies one or more causes for the poor voice quality);
determining, by the application, an action that improves the voice call quality by remediating the cause of the event (Haggarty et al. col17 ln52-59, if any actions have been taken, IVR module determines if quality is now acceptable)
performing, by the application, the action that remediates the cause of the event (Haggarty et al. col6 ln54 to col7 ln17, determines than an action can be taken and performs action).
Haggarty does not explicitly disclose accessing, by the application, device data that indicates characteristics of the computing device.
However Verma et al. discloses accessing, by the application, device data that indicates characteristics of the computing device (Verma et al. fig. 3 330 col17 ln 42-59, identifies device ID characteristics).
It would have been obvious to one of ordinary skill in the art before the filing date of the invention to have combined the auto-correction method of Haggerty with the device identification method of Verma et al. in order to identify device characteristics (Verma et al. col1 ln39-63).
In regards to claim 2, Haggerty as modified by Verma et al. discloses the method of claim 1, wherein accessing device data that indicates the characteristics of the computing device comprises:
accessing, from a telephony application layer of the computing device, the device data that that indicates the characteristics of the computing device (Verma et al. fig. 3 col17 ln16-41, accesses electronic frequency components used to identify device characteristics).
In regards to claim 3, Haggerty as modified by Verma et al. discloses the method of claim 1, wherein accessing device data that indicates the characteristics of the computing device comprises:
accessing, from a framework module of the computing device, the device data that that indicates the characteristics of the computing device (Verma et al. fig. 1 col9 ln20-46, the VCCS 140 determines one or more characteristics associated with the ring signal data 120″, such as a device identification characteristic).
In regards to claim 4, Haggerty as modified by Verma et al. discloses the method of claim 1, wherein accessing device data that indicates the characteristics of the computing device comprises:
accessing, from a modem of the computing device, the device data that that indicates the characteristics of the computing device (Verma et al. fig. 3 col17 ln60 to col18 ln3, the stored ID characteristics 285 based on the device ID data 212. In some cases, one or more stored ID characteristics are encoded as vector data).
In regards to claim 5, Haggerty as modified by Verma et al. discloses the method of claim 1, wherein accessing device data that indicates the characteristics of the computing device comprises:
accessing, from an interprocess communication module of the computing device, the device data that that indicates the characteristics of the computing device (Verma et al. fig. 3 col17 ln60 to col18 ln3, accesses stored device ID data).
In regards to claim 6, Haggerty as modified by Verma et al. discloses the method of claim 1, comprising:
generating, by the application, an interface that indicates the event and the action (Haggerty et al. col20 ln39-46, However, if one or more actions can be taken to attempt to address the cause of the poor voice quality, then the voice quality module has the actions performed in Operation 545. At this point, the voice quality module sets the message to indicate action(s) have been taken to attempt to improve the voice quality in Operation); and
providing, for output by the application, the interface (Haggerty et al. col7 ln34-46, the party may be given a code that he or she can provide to be given priority).
In regards to claim 7, Haggerty as modified by Verma et al. discloses the method of claim 1, comprising:
receiving, by the application, an updated model that is trained using machine learning and that is configured to determine the given cause of the given event associated with the computing device (Haggerty et al. col15 ln59 to col16 ln6, neural network weights are updated based on the training data).
In regards to claim 8, Haggerty as modified by Verma et al. discloses the method of claim 1, wherein the model is trained by an additional computing device using machine learning and previous device data, previous network data, data identifying previous events, and previous causes of the previous events (Haggerty et al. col15 ln59 to col16 ln6, The data is made up of audio signals of telephone calls in which poor voice quality was experienced during the call and is identified with the cause of the poor voice quality).
In regards to claim 9, Haggerty as modified by Verma et al. discloses the method of claim 1, wherein determining the action that remediates the cause of the event comprises:
providing, by the application, the device data, the network data, the data identifying the event, and data identifying the cause to an additional model that is configured to output the action (Haggerty et al. col5 ln29-44, the parameters may encompass parameters associated with different aspects of the call).
In regards to claim 10, Haggerty as modified by Verma et al. discloses the method of claim 9, wherein the additional model is trained by an additional computing device using machine learning and previous device data, previous network data, data identifying previous events, previous causes of the previous events, and previous actions that remediated the previous events (Haggerty et al. col5 ln45-59, Once the data for the parameters have been taken, the data is then provided as input in various embodiments to one or more predictive models to predict cause(s) of the poor voice quality).
In regards to claim 11, Haggerty as modified by Verma et al. discloses the method of claim 1, comprising:
receiving, by the application, data indicating whether the action improved the voice call quality of the computing device (Haggarty col7 ln7-17, At this point, the process may involve returning to Step 120 and interacting with the party on the call to inquire as to whether the voice quality has improved); and
providing, for output by the application, the data indicating whether the action improved the voice call quality of the computing device (Haggarty col7 ln7-17, If the voice quality has improved to the point that the party is happy with the quality he or she is experiencing, then the call is handled using conventional processing normally experienced in contact centers).
Claims 12, 13, and 14-19 recite substantially similar limitations to claims 1, 2-5, and 6-11. Thus claims 12, 13, and 14-19 are rejected along the same rationale as claims 1, 2-5, and 6-11.
Claim 20 recites substantially similar limitations to claim 1. Thus claim 20 is rejected along the same rationale as claim 1.
Conclusion
The prior art made of record and not relied upon is considered pertinent to applicant's disclosure.
Hui et al. (US2018/0192303) teaches using a decision tree to identify cause of call problems.
Roostacyan et al. (US12,675,686) teaches updating a model between multiple devices.
Veggalam et al. (US2022/0124574) teaches training multiple machine learning models to improve call quality.
Vasseur et al. (US2018/0365581) teaches a model for predicting call quality based on device and network characteristics.
Any inquiry concerning this communication or earlier communications from the examiner should be directed to NICHOLAS HASTY whose telephone number is (571)270-7775. The examiner can normally be reached Monday-Friday 8:30am-5:00pm.
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, Matt Ell can be reached at (571)270-3264. 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.
/N.H/Examiner, Art Unit 2141
/MATTHEW ELL/Supervisory Patent Examiner, Art Unit 2141
Prosecution Insights