SYSTEMS AND METHODS FOR REAL-TIME UPLINK AND DOWNLINK AUDIO ABNORMALITY DETECTION

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 . See 35 U.S.C. § 100 (note). Art Rejections Obviousness 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–3 and 11–13 are rejected under 35 U.S.C. § 103 as being unpatentable over the combination of US Patent Application Publication 2022/0319537 (published 06 October 2022) (“Michaelis”) and US Patent Application Publication 2019/0068389 (published 28 February 2019) (“Chitre”). Claim 1 is drawn to “a computerized method for uplink and downlink audio abnormality detection.” The following table illustrates the correspondence between the claimed method and the Michaelis reference. Claim 1 The Michaelis Reference “1. A computerized method for uplink and downlink audio abnormality detection comprising: The Michaelis reference describes a method that is performed in a computerized network that includes endpoints 102 and 103 and communication session system 101 to perform real-time detection of audio issues, or audio abnormalities. Michaelis at Abs., ¶¶ 20–24, FIGs.1, 2. For the purposes of this rejection, the Examiner will explain the correspondence between Michaelis and the claimed invention by viewing endpoint 102 as an uplink endpoint (i.e., an endpoint that acts as an audio source and a transmitter of audio) and endpoint 103 as a downlink endpoint (i.e., an endpoint that receives audio transmitted by an uplink endpoint). Michaelis describes that audio issues may be detected by any of system 101, endpoint 102 and endpoint 103 and then reported back to the originating endpoint. Id. at ¶¶ 20, 23, 25, 30. Thus, Michaelis teaches performing both uplink and downlink abnormality detection in uplink endpoint 102 and downlink endpoint 103. “at an uplink device, diagnosing audio issues at each major stage of an audio uplink pipeline in an ordered fashion; Michaelis describes performing an orderly analysis of uplink audio at different stages of an audio uplink pipeline. Id. at ¶ 26. For example, Michaelis begins by analyzing a video to detect whether a user of endpoint 102 is speaking (e.g., detecting mouth movements). Id. at ¶ 25, FIGs.2, 3. Having confirmed that a user is speaking, Michaelis determines if any voice signals were actually received (i.e., is there a voice input?). Id. If there is no voice signal input the system checks for software problems (e.g., local muting) first and then hardware problems (e.g., malfunctioning microphone). Id. If there are no software/hardware problems, the system analyzes the recorded audio itself to determine if there is a problem with the audio. Id. For example, Michaelis determines if the audio is delayed with respect to the video, has an unacceptably low SNR or has dropped speech. Id. In this way, Michaelis determines at the hardware input, software interface and audio processing stages if there is an audio issue. Id. “at a downlink device, diagnosing the audio issues by combining abnormality monitoring from packet handling and decoding; Michaelis describes detecting a bad connection to detect the source of an audio issue. Id. at ¶¶ 1, 31, 34. For example, Michaelis performs audio quality checks at both an uplink point and a downlink point to determine if audio quality may have deteriorated over a communication link. Id. at ¶¶ 31, 34. Michaelis, however, does not describe diagnosing audio issues by combining abnormality monitoring from packet handling and decoding (e.g., detecting packet handling errors and errors in the audio after decoding). “wherein the diagnosing the audio issues triggers three independent check paths; and Michaelis similarly performs at least three independent checks, including software checks (e.g., checking for local or central mutes), device hardware checks (e.g., checking for bad microphones), audio signal flow analysis (e.g., checking for audio/video sync, noisy speech, quiet speech, dropped words) and network transmission checks (e.g., detecting bad connections). Id. at ¶¶ 22, 26, 34, 35, 40. “identifying a root cause via the diagnosing the audio issues.” Michaelis describes similarly identifies root causes, such as detecting software issues, hardware issues and connection issues. Id. For example, Michaelis describes detecting software issues (e.g., a user setting their microphone on mute); hardware issues (e.g., activating alternative microphones or testing a microphone), other audio issues (e.g., poor quality due to low-voice level, or SNR) and connection issues (e.g., poor quality at a downlink point caused by a poor connection). Id. Table 1 The table above shows that the Michaelis reference describes a method that corresponds closely to the claimed method. Michaelis does not anticipate the claimed invention because it does not particularly describe using downlink endpoint 103 to diagnose audio issues by combining abnormality monitoring from packet handling and decoding. The differences between the claimed invention and the Michaelis reference are such that the invention as a whole would have been obvious to one of ordinary skill in the art at the time this Application was effectively filed. Michaelis, like the claimed invention, is drawn to detecting uplink and downlink audio abnormalities. Michaelis describes a system with endpoint 102, communication session system 101, endpoint 103 and links 111 and 112. Michaelis at ¶¶ 18–24, FIGs.1, 2. Endpoint 102 can be viewed as an uplink endpoint that receives speech from participant 122 through a microphone, processes the audio and transmits the audio over link 111 to system 101. Id. System 101 transmits the audio to endpoint 103 over link 112. Id. Endpoint 103 receives the audio and plays it back for participant 123. Id. Michaelis describes performing numerous checks for audio issues along the processing path. Id. For example, Michaelis describes checking for software issues, such as local muting; hardware issues, such as malfunctioning microphones; audio quality issues along an audio processing path and connection issues caused by links 111, 112. Id. at ¶¶ 22, 26, 34, 35, 40. To detect connection issues, Michaelis describes evaluating audio quality at endpoint 103 to identify desyncs or distortion indicating a poor connection. Id. at ¶¶ 31, 34. However, the Michaelis reference repeatedly indicates that checks at system 101 may also be performed at endpoint 103. Id. at ¶¶ 20, 23, 25, 30. Thus, Michaelis readily suggests modifying system 100 to perform a connection check at endpoint 103. See MPEP § 2143(I)(D) (applying a known technique to a known device ready for improvement to yield predictable results: applying Michaelis’s link check, which is useful for diagnosing problems in link 111, at endpoint 103 to detect errors in link 112). Even with this modification in place, the Michaelis reference does not expressly describe checking a link connection by combining abnormality monitoring from packet handling and decoding. At best, Michaelis describes detecting abnormalities related to decoding, such as audio/video desyncs and distorted audio. The Chitre reference is related to Michaelis because they both relate to audio conferencing systems and specifically to solving problems related to detecting, reporting and correcting audio quality issues. Chitre at ¶ 30. Chitre teaches that conferencing systems may experience poor quality connections for several reasons, including latency and jitter that can cause dropped audio packets. Id. Chitre teaches detecting these types of root causes and either suggest or execute establishing another connection. Id. Read in light of Michaelis, Chitre reasonably suggests modifying Michaelis system to include the claimed downlink audio issue monitoring feature that combines abnormality monitoring from packet handling and decoding. See MPEP § 2143(I)(A) (combining prior art elements according to known methods to yield predictable results). For example, Chitre suggests detecting latency, jitter and/or dropped packets to assist in troubleshooting connection problems. These are examples of abnormality monitoring relating to packet handling. One of ordinary skill would have recognized that adding this feature to Michaelis’s downlink endpoint 103 would allow endpoint 103 to detect when received audio is likely to have low quality due to latency, jitter and/or dropped packets as well as based on detected audio desync issues and audio distortion (i.e., abnormality monitoring related to decoding of audio). This information would be used to then notify participants 122 and 123 or perform an automatic fix, such as switching connection. For the foregoing reasons, the combination of the Michaelis and the Chitre references makes obvious all limitations of the claim. Claim 2 depends on claim 1, and further requires the following: “further comprising providing information to a user to fix the audio issues, wherein the information is responsive to the root cause.” Michaelis similarly describes providing information to users, or participants 122, 123 on how to fix the root causes of audio issues. Michaelis at ¶¶ 17, 23, 24, 34, 35. For example, Michaelis’s system may inform a user to unmute himself, check his microphone or switch a network connection (based on the suggestions of Chitre discussed in the obviousness rejection of claim 1). See id.; Chitre at ¶ 51, FIG.12. For the foregoing reasons, the combination of the Michaelis and the Chitre references makes obvious all limitations of the claim. Claim 3 depends on claim 1, and further requires the following: “wherein the three independent check paths include a device operation check, an audio signal flow check and a network transmission check.” Michaelis similarly performs at least three independent checks, including software checks (e.g., checking for local or central mutes), device/hardware operation checks (e.g., checking for bad microphones), audio signal flow checks (e.g., checking for audio/video sync, noisy speech, quiet speech, dropped words) and network transmission checks (e.g., detecting bad connections). Michaelis at ¶¶ 22, 26, 34, 35, 40, For the foregoing reasons, the combination of the Michaelis and the Chitre references makes obvious all limitations of the claim. Claim 11 is drawn to “a computerized system for uplink and downlink audio abnormality detection.” The following table illustrates the correspondence between the claimed system and the Michaelis reference. Claim 11 The Michaelis Reference “11. A computerized system for uplink and downlink audio abnormality detection comprising: The Michaelis reference describes a method that is performed in a computerized network that includes endpoints 102 and 103 and communication session system 101 to perform real-time detection of audio issues, or audio abnormalities. Michaelis at Abs., ¶¶ 20–24, FIGs.1, 2. For the purposes of this rejection, the Examiner will explain the correspondence between Michaelis and the claimed invention by viewing endpoint 102 as an uplink endpoint (i.e., an endpoint that acts as an audio source and a transmitter of audio) and endpoint 103 as a downlink endpoint (i.e., an endpoint that receives audio transmitted by an uplink endpoint). Michaelis describes that audio issues may be detected by any of system 101, endpoint 102 and endpoint 103 and then reported back to the originating endpoint. Id. at ¶¶ 20, 23, 25, 30. Thus, Michaelis teaches performing both uplink and downlink abnormality detection in uplink endpoint 102 and downlink endpoint 103. “an uplink device configured to diagnose audio issues at each major stage of an audio uplink pipeline in an ordered fashion; Michaelis describes performing an orderly analysis of uplink audio at different stages of an audio uplink pipeline. Id. at ¶ 26. For example, Michaelis begins by analyzing a video to detect whether a user of endpoint 102 is speaking (e.g., detecting mouth movements). Id. at ¶ 25, FIGs.2, 3. Having confirmed that a user is speaking, Michaelis determines if any voice signals were actually received (i.e., is there a voice input?). Id. If there is no voice signal input the system checks for software problems (e.g., local muting) first and then hardware problems (e.g., malfunctioning microphone). Id. If there are no software/hardware problems, the system analyzes the recorded audio itself to determine if there is a problem with the audio. Id. For example, Michaelis determines if the audio is delayed with respect to the video, has an unacceptably low SNR or has dropped speech. Id. In this way, Michaelis determines at the hardware input, software interface and audio processing stages if there is an audio issue. Id. “a downlink device configured to diagnose the audio issues by combining abnormality monitoring from packet handling and decoding; Michaelis describes detecting a bad connection to detect the source of an audio issue. Id. at ¶¶ 1, 31, 34. For example, Michaelis performs audio quality checks at both an uplink point and a downlink point to determine if audio quality may have deteriorated over a communication link. Id. at ¶¶ 31, 34. Michaelis, however, does not describe diagnosing audio issues by combining abnormality monitoring from packet handling and decoding (e.g., detecting packet handling errors and errors in the audio after decoding). “wherein the diagnosing the audio issues triggers three independent check paths; and Michaelis similarly performs at least three independent checks, including software checks (e.g., checking for local or central mutes), device hardware checks (e.g., checking for bad microphones), audio signal flow analysis (e.g., checking for audio/video sync, noisy speech, quiet speech, dropped words) and network transmission checks (e.g., detecting bad connections). Id. at ¶¶ 22, 26, 34, 35, 40. “a detection module configured to identify a root cause via the diagnosing the audio issues.” Michaelis describes similarly identifies root causes, such as detecting software issues, hardware issues and connection issues. Id. For example, Michaelis describes detecting software issues (e.g., a user setting their microphone on mute); hardware issues (e.g., activating alternative microphones or testing a microphone), other audio issues (e.g., poor quality due to low-voice level, or SNR) and connection issues (e.g., poor quality at a downlink point caused by a poor connection). Id. Table 2 The table above shows that the Michaelis reference describes a system that corresponds closely to the claimed system. Michaelis does not anticipate the claimed invention because it does not particularly describe using downlink endpoint 103 to diagnose audio issues by combining abnormality monitoring from packet handling and decoding. The differences between the claimed invention and the Michaelis reference are such that the invention as a whole would have been obvious to one of ordinary skill in the art at the time this Application was effectively filed. Michaelis, like the claimed invention, is drawn to detecting uplink and downlink audio abnormalities. Michaelis describes a system with endpoint 102, communication session system 101, endpoint 103 and links 111 and 112. Michaelis at ¶¶ 18–24, FIGs.1, 2. Endpoint 102 can be viewed as an uplink endpoint that receives speech from participant 122 through a microphone, processes the audio and transmits the audio over link 111 to system 101. Id. System 101 transmits the audio to endpoint 103 over link 112. Id. Endpoint 103 receives the audio and plays it back for participant 123. Id. Michaelis describes performing numerous checks for audio issues along the processing path. Id. For example, Michaelis describes checking for software issues, such as local muting; hardware issues, such as malfunctioning microphones; audio quality issues along an audio processing path and connection issues caused by links 111, 112. Id. at ¶¶ 22, 26, 34, 35, 40. To detect connection issues, Michaelis describes evaluating audio quality at endpoint 103 to identify desyncs or distortion indicating a poor connection. Id. at ¶¶ 31, 34. However, the Michaelis reference repeatedly indicates that checks at system 101 may also be performed at endpoint 103. Id. at ¶¶ 20, 23, 25, 30. Thus, Michaelis readily suggests modifying system 100 to perform a connection check at endpoint 103. See MPEP § 2143(I)(D) (applying a known technique to a known device ready for improvement to yield predictable results: applying Michaelis’s link check, which is useful for diagnosing problems in link 111, at endpoint 103 to detect errors in link 112). Even with this modification in place, the Michaelis reference does not expressly describe checking a link connection by combining abnormality monitoring from packet handling and decoding. At best, Michaelis describes detecting abnormalities related to decoding, such as audio/video desyncs and distorted audio. The Chitre reference is related to Michaelis because they both relate to audio conferencing systems and specifically to solving problems related to detecting, reporting and correcting audio quality issues. Chitre at ¶ 30. Chitre teaches that conferencing systems may experience poor quality connections for several reasons, including latency and jitter that can cause dropped audio packets. Id. Chitre teaches detecting these types of root causes and either suggest or execute establishing another connection. Id. Read in light of Michaelis, Chitre reasonably suggests modifying Michaelis system to include the claimed downlink audio issue monitoring feature that combines abnormality monitoring from packet handling and decoding. See MPEP § 2143(I)(A) (combining prior art elements according to known methods to yield predictable results). For example, Chitre suggests detecting latency, jitter and/or dropped packets to assist in troubleshooting connection problems. These are examples of abnormality monitoring relating to packet handling. One of ordinary skill would have recognized that adding this feature to Michaelis’s downlink endpoint 103 would allow endpoint 103 to detect when received audio is likely to have low quality due to latency, jitter and/or dropped packets as well as based on detected audio desync issues and audio distortion (i.e., abnormality monitoring related to decoding of audio). This information would be used to then notify participants 122 and 123 or perform an automatic fix, such as switching connection. For the foregoing reasons, the combination of the Michaelis and the Chitre references makes obvious all limitations of the claim. Claim 12 depends on claim 11, and further requires the following: “wherein the detection module is further configured to provide information to a user to fix the audio issues, wherein the information is responsive to the root cause.” Michaelis similarly describes providing information to users, or participants 122, 123 on how to fix the root causes of audio issues. Michaelis at ¶¶ 17, 23, 24, 34, 35. For example, Michaelis’s system may inform a user to unmute himself, check his microphone or switch a network connection (based on the suggestions of Chitre discussed in the obviousness rejection of claim 1). See id.; Chitre at ¶ 51, FIG.12. For the foregoing reasons, the combination of the Michaelis and the Chitre references makes obvious all limitations of the claim. Claim 13 depends on claim 11, and further requires the following: “wherein the three independent check paths include a device operation check, an audio signal flow check and a network transmission check.” Michaelis similarly performs at least three independent checks, including software checks (e.g., checking for local or central mutes), device/hardware operation checks (e.g., checking for bad microphones), audio signal flow checks (e.g., checking for audio/video sync, noisy speech, quiet speech, dropped words) and network transmission checks (e.g., detecting bad connections). Michaelis at ¶¶ 22, 26, 34, 35, 40, For the foregoing reasons, the combination of the Michaelis and the Chitre references makes obvious all limitations of the claim. Summary Claims 1–3 and 11–13 are rejected under at least one of 35 U.S.C. §§ 102 and 103 as being unpatentable over the cited prior art. 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. This Application currently names joint inventors. In considering patentability of the claims the examiner presumes that the subject matter of the various claims was commonly owned as of the effective filing date of the claimed invention(s) absent any evidence to the contrary. Applicant is advised of the obligation under 37 C.F.R. § 1.56 to point out the inventor and effective filing dates of each claim that was not commonly owned as of the effective filing date of the later invention in order for the examiner to consider the applicability of 35 U.S.C. § 102(b)(2)(C) for any potential 35 U.S.C. § 102(a)(2) prior art against the later invention. Allowable Subject Matter Claims 4–10 and 14–20 are objected to as reciting allowable subject matter while depending on a rejected base claim. The claims would be allowable if rewritten in independent form, including all the limitations of their base claim and any and all intervening claims. Claim 4 depends on claim 3, and further requires the following: “wherein an uplink audio check includes an ADM recording frequency check, a muted microphone check, a near-in signal frozen check, a near-out signal frozen check, a recording signal volume adjustment check, an audio stream send enabled check, and a low send bitrate check.” This claim presents a conjunctive list of required audio checks. The cited prior art describes or suggests some of the audio checks, but does not describe all of them in combination (e.g., ADM recording frequency check, near-in signal frozen check, near-out signal frozen check and audio stream send enabled). Claims 5 and 6 depend on claim 4 and include the same limitations. For the foregoing reasons, claims 4–6 recite allowable subject matter. Claim 7 depends on claim 3, and further requires the following: “wherein a downlink audio includes an ADM playback frequency check, a muted remote peers check, a playback signal volume adjustment check, a speaker muted check, a no peers check, a peer analyzer check and a far-in signal frozen check.” This claim presents a conjunctive list of required downlink audio checks. The cited prior art describes or suggests some of the audio checks, but it does not describe all of them in combination (e.g., ADM playback frequency check, a no peers check, a peer analyzer check and a far-in signal frozen check). Claims 8–10 depend on claim 7 and include the same limitations. For the foregoing reasons, claims 7–10 recite allowable subject matter. Claim 14 depends on claim 13, and further requires the following: “wherein an uplink audio check includes an ADM recording frequency check, a muted microphone check, a near-in signal frozen check, a near-out signal frozen check, a recording signal volume adjustment check, an audio stream send enabled check, and a low send bitrate check.” This claim presents a conjunctive list of required audio checks. The cited prior art describes or suggests some of the audio checks, but does not describe all of them in combination (e.g., ADM recording frequency check, near-in signal frozen check, near-out signal frozen check and audio stream send enabled). Claims 15 and 16 depend on claim 14 and include the same limitations. For the foregoing reasons, claims 14–16 recite allowable subject matter. Claim 17 depends on claim 13, and further requires the following: “wherein a downlink audio check includes an ADM playback frequency check, a muted remote peers check, a playback signal volume adjustment check, a speaker muted check, a no peers check, a peer analyzer check and a far-in signal frozen check.” This claim presents a conjunctive list of required downlink audio checks. The cited prior art describes or suggests some of the audio checks, but it does not describe all of them in combination (e.g., ADM playback frequency check, a no peers check, a peer analyzer check and a far-in signal frozen check). Claims 18–20 depend on claim 17 and include the same limitations. For the foregoing reasons, claims 17–20 recite allowable subject matter. Additional Citations The table below lists references that were identified during a search of the subject matter disclosed and claimed in this Application. While this Office action does not rely on the listed references, they contain subject matter that is relevant to the subject matter of this Application. Applicant is advised to consider these references when preparing a response to this Office action. Citation Relevance US 2023/0344965 Audio checks, device checks, connection checks Table 3 Objections Claims 9 and 19 both include the phrase “a check in the receiving bitrate”. This appears to be a typo and should be “a check if the receiving bitrate”. Claim 7 recites “wherein a downlink audio includes”. This appears to be a typo and should be “wherein a downlink audio check includes”. Claim 9 recites “wherein the network peer analyzer includes”. This appears to be a typo and should be “wherein the network peer analyzer check includes”. Appropriate correction is required. No new matter may be entered. Conclusion Any inquiry concerning this communication or earlier communications from the examiner should be directed to WALTER F BRINEY III whose telephone number is (571)272-7513. The examiner can normally be reached M-F 8 am-4:30 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, Carolyn Edwards can be reached at 571-270-7136. 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. /Walter F Briney III/ Walter F Briney IIIPrimary ExaminerArt Unit 2692 9/4/2026