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 .
This Office Action is in response to Applicant’s RCE Amendment filed on February 3, 2026 in response to the Final Office Action filed on December 23, 2025. Claims 1, 3-6, 8-9, 11-14, 16-17, and 19-20 are now pending in the present application. This Action is made NON-FINAL.
Continued Examination Under 37 CFR 1.114
A request for continued examination under 37 CFR 1.114, including the fee set forth in 37 CFR 1.17(e), was filed in this application after final rejection. Since this application is eligible for continued examination under 37 CFR 1.114, and the fee set forth in 37 CFR 1.17(e) has been timely paid, the finality of the previous Office action has been withdrawn pursuant to 37 CFR 1.114. Applicant's submission filed on February 3, 2026 has been entered.
Claim Rejections - 35 USC § 112
The following is a quotation of 35 U.S.C. § 112(b):
(b) CONCLUSION.—The specification shall conclude with one or more claims particularly pointing out and distinctly claiming the subject matter which the inventor or a joint inventor regards as the invention.
The following is a quotation of 35 U.S.C. § 112 (pre-AIA ), second paragraph:
The specification shall conclude with one or more claims particularly pointing out and distinctly claiming the subject matter which the applicant regards as his invention.
The prior rejections of claims 19 and 20 under 35 U.S.C. § 112(b) or 35 U.S.C. § 112 (pre-AIA ), second paragraph, as being indefinite for failing to particularly point out and distinctly claim the subject matter which the inventor or a joint inventor, or for pre-AIA the applicant regards as the invention, are now withdrawn since claim 19 (from which claim 20 depends) now depends from claim 17, rather than canceled claim 18.
Claim Rejections - 35 USC § 103
In the event the determination of the status of the application as subject to AIA 35 U.S.C. § 102 and § 103 (or as subject to pre-AIA 35 U.S.C. § 102 and § 103) is incorrect, any correction of the statutory basis (i.e., changing from AIA to pre-AIA ) for the rejection will not be considered a new ground of rejection if the prior art relied upon, and the rationale supporting
the rejection, would be the same under either status.
The following is a quotation of 35 U.S.C. 103 which forms the basis for all obviousness
rejections set forth in this Office action:
A patent for a claimed invention may not be obtained, notwithstanding that the claimed invention is not identically disclosed as set forth in section 102, if the differences between the claimed invention and the prior art are such that the claimed invention as a whole would have been obvious before the effective filing date of the claimed invention to a person having ordinary skill in the art to which the claimed invention pertains. Patentability shall not be negated by the manner in which the invention was made.
The factual inquiries for establishing a background for determining obviousness under 35 U.S.C. § 103 are summarized as follows:
Determining the scope and contents of the prior art.
Ascertaining the differences between the prior art and the claims at issue.
Resolving the level of ordinary skill in the pertinent art.
Considering objective evidence present in the application indicating obviousness or nonobviousness.
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 CFR § 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.
Claims 1, 3, 4, 8, 17, 19, and 20 are rejected under 35 U.S.C. § 103 as obvious over U.S. Patent No. 11,463,582 to Serban (“the Serban reference”)—and which, like the instant application, names T-Mobile as the applicant and assignee, in view of Kalra Khwab, Bootstrap Aggregating: Improving Machine Learning Models through Resampling (April 25, 2023) (“the Aggregating reference”), and in further view of U.S. Published Patent Application No. 2018/0152558 (“the Chan reference”), for the following reasons.
Claim 1, as amended, is directed to a “computer-implemented method”.
In this regard, the Abstract of the Serban reference discloses a “computer-implemented method”, since it discloses the following:
Systems and methods for detecting indications of a scam caller are disclosed. Call data, such as call audio, is received and used to create a training dataset. Using the training dataset, a machine learning model is trained to detect indications of a scam caller in a phone call. . . . If the caller is determined to be a likely scam caller, an alert can be generated and/or the call can be disconnected.
In short, the Serban reference discloses or at least suggests the limitation of a “computer-implemented method”.
Claim 1 recites the further limitation of “receiving, at a computer server, a voice call to a user, the voice call being associated with a phone number”. That is, a computer server receives a voice call, associated with a phone number, to a user.
In this regard, the Serban reference discloses that the system and method are implemented using computer servers 130 (at col. 4, lines 28-31) (“To provide features of the network, telecommunications service providers use one or more servers 130, which can be used to provide all or portions of the disclosed scam caller detection system”).
The Serban reference further discloses (at col. 7, lines 2-7; col. 9, line 66 to col. 10, line 4) the following:
The call data module 210 is configured and/or programmed to receive/store/process data associated with phone calls or other communications. Call data can include a variety of data or metadata
associated with phone calls, such as call detail records (CDRs), call logs, and/or audio of phone calls (e.g., recorded or transcribed audio).
. . . .
[T]he reporting and log module 240 can cause display on a subscriber's mobile device of a report showing that a call was determined to be associated with a likely scam caller, a phone number associated with the call, a time and date for the call. . . .
In short, the Serban reference discloses or at least suggests the limitation of “receiving, at a computer server, a voice call to a user, the voice call being associated with a phone number”.
Claim 1 recites the further limitation of “determining, by the computer server, that the phone number is associated with a first category”. That is, the computer server determines that the phone number is associated with a first category.
The instant specification discloses (at paragraphs [0040]-[0042]) that spam calls associated with a first category include PDN/PHN (potential dislike number/potential harmful number).
[0040] The PDN/PHN classifier 310 may include one or more machine learning models (e.g., ML model #1, ML model #2, ..., ML model #N) trained to classify a candidate Robo call to one or more categories. For example, the Robo call may be associated with a potential harmful number, a potential dislike number, etc. Each of the ML models may be built and trained with respect to one of the voice data metrics 402. In some examples, the PDN/PHN classifier 310 may be trained in a remote PDN/PHN classifier training server 316. The PDNIPHN classifier training server 316 may create a training data set based at least in part on the data in the voice call database 320. Each data point of the training data set may represent one or more features related to the MT calls originated from a same phone number. After the PDN/PHN classifier 310 is trained and validated to satisfy a criteria, e.g., the classification accuracy satisfying a threshold, the PDN/PHN classifier 310 may be downloaded and implemented on the PDN/PHN classifier 310 of the TAS 116. In some examples, the PDN/PHN classifier 310 may be trained locally at the TAS 116.
[0041] The string generating module 312 may generate one or more strings corresponding to the one or more categories outputted by the PDN/PHN classifier 310. The one or more strings may provide a textual description of the one or more categories. For a potential harmful number, for example, the string generating module 312 may generate a string of "most people did not accept this number." Alternatively, the string generating module 312 may generate a string of "many people reported spam for this number" for a potential harmful number. For a potential dislike number, the string generating module 312 may generate a string of "this number was call disconnected in 5 seconds from other users many times," or a string of "this number was rejected by 90% of users in the past few months," etc. The string generating module 312 may store the correlation of the one or more categories, e.g., PDN/PHN, with the strings in a datastore of the TAS 116.
[0042] The PDN/PHN blacklist 314 may maintain a blacklist of candidate PDNs and PHNs. In some examples, the PDN/PHN blacklist 314 may also include the strings corresponding to the candidate PDNs and PHNs. When an incoming call is determined to be in the blacklist, the TAS 116 may select one of the strings corresponding to the incoming call number and transmit the selected string to the MT party 304.
In this regard, the Serban reference discloses (at col. 9, line 55 to col. 10, line 15) the following:
The reporting and log module 240 is configured and/or programmed to record information associated with received phone calls, such as whether the call is determined to be associated with a scam [(spam)] caller or a legitimate caller
. . . . The reporting and log module 240 records and reports information about these received phone calls. For example, if a caller is determined to be a likely scam [(spam)] caller, the reporting and log module 240 can cause display on a subscriber's mobile device of a report showing that a call was determined to be associated with a likely scam caller, a phone number associated with the call, a time and date for the call, and so forth. The reporting and log module 240 can further log this call information in a database, for example, so that the information can be used to add a caller to a blacklist of callers. In some implementations, rather than automatically classifying a caller as a scam [(spam)] caller, the system can request confirmation from a subscriber that a caller is a scam caller, e.g., by having the caller review a call transcript or recording and select an icon or button confirming that the caller is a scam [(spam)] caller. In such implementations, this subscriber confirmation can also be logged by the reporting and log module 240.
In short, the Serban reference discloses or at least suggests the limitation of “determining, by the computer server, that the phone number is associated with a first category”.
Claim 1, as amended, further recites the limitation of “determin[ing] an overall probability that the phone number is associated with the first category.”
In this regard, the Serban reference discloses (at col. 10, lines 15-33; col. 13, line 65 to col. 14, line 19) to the use of a probability distribution resulting from an analysis of training data (phone data), and analyzing scam calls based on a threshold or a probability.
Accordingly, the Serban reference discloses or at least suggests the limitation of “determin[ing] an overall probability that the phone number is associated with the first category.”
Claim 1 recites the further limitation of “generating, by the computer server, a string indicative of the first category”, and “presenting, by the computer server, the phone number and the string on a user interface (UI) of a device of the user”.
The instant specification discloses (at paragraph [0041]) that the string associated with the category is a text string, as follows:
[0041] The string generating module 312 may generate one or more strings corresponding to the one or more categories outputted by the PDN/PHN classifier 310. The one or more strings may provide a textual description of the one or more categories. For a potential harmful number, for example, the string generating module 312 may generate a string of "most people did not accept this number." Alternatively, the string generating module 312 may generate a string of "many people reported spam for this number" for a potential harmful number. For a potential dislike number, the string generating module 312 may generate a string of "this number was call disconnected in 5 seconds from other users many times," or a string of "this number was rejected by 90% of users in the past few months," etc. . . .
In this regard, the Serban reference discloses (at col. 9, line 55 to col. 10, line 15) the following:
The reporting and log module 240 is configured and/or programmed to record information associated with received phone calls, such as whether the call is determined to be associated with a scam [(spam)] caller or a legitimate caller
. . . . The reporting and log module 240 records and reports information about these received phone calls. For example, if a caller is determined to be a likely scam [(spam)] caller, the reporting and log module 240 can cause [(generate or present)] [a] display on a subscriber's mobile device [(a UI of a user device)] of a report showing that a call was determined to be associated with a likely scam caller, a phone number associated with the call, a time and date for the call, and so forth.
In short, the Serban reference discloses the further limitation of “generating, by the computer server, a string indicative of the first category”, and “presenting, by the computer server, the phone number and the string on a user interface (UI) of a device of the user”.
As explained above as to claim 1, the Serban reference discloses or at least suggests the limitation of “determining, by the computer server, that the phone number is associated with a first category”.
As further regards the “machine learning models” limitation of claim 1, Figure 4 of the Serban reference discloses a “flow diagram illustrating an example process for training a machine learning model to detect indications of a scam [(spam)] caller”—in which a phone number is necessarily associated with the “first category”.
In particular, the Serban reference discloses (at col. 11, line 48 to col. 12, line 18), as follows:
Training of Machine Learning Model
FIG. 4 is a flow diagram illustrating a process 400 for training a machine learning model to detect indications of a scam caller during a phone call. The process 400 begins at block 410, where call data is received for multiple phone calls associated with known scam callers and known good callers. This call data can be, for example, call audio, such as recorded phone calls. Call data can include metadata and other information as well, such as call detail records (CDRs), identities of a caller and/or called party, identifiers associated with callers and/or called parties (e.g., phone numbers), device information for callers and/or called parties, phone number information (e.g., type of number, location information, etc.), telecommunication service provider information, and so forth. Call data can also include network-level data, such as data about a telecommunications service provider associated with the caller and/or about a telecommunications network or components thereof.
The process 400 then proceeds to block 420, where a training dataset is created using the received call data. Creating the training dataset can include, for example, processing the received call data. In implementations where the training dataset is limited to call audio, the call audio can be extracted from the call data. Creating the training dataset can include calculating variables and/or identifying characteristics of the call data. In addition, creating the training dataset can include identifying metadata or other information about each call or caller, such as whether the caller number [(which a target phone number)] is domestic or international, whether the [phone] number is part of a range of a verifiable carrier, and so forth. It can also include identifying information about the duration of the call, whether the call had abruptly ended, or the number of call instances the caller had initiated in a certain time period. For example, a very frequent number of calls over a short period from an unverified caller can be associated with a high confidence of a scam [(spam)] caller. These and other characteristics of call data can be identified (e.g., by tagging data, calculating variables, etc.) in a training dataset.
The process 400 then proceeds to block 430, where the training dataset is used to train the machine learning model to detect indications of a scam [(spam)] caller in a phone call.
It is first noted that nothing in the instant specification makes clear the difference between a “first category”, such as a “dislike” number or a “harmful” number, from a spam (scam) number.
It is also noted that the “phone number” is a “target phone number” in that the machine learning model is trained to determine that the “phone number” (which is a “target phone number”) is associated with the first category.
Accordingly, the Serban reference discloses a “first category”, such as spam/scam--which necessarily includes at least one of a potential harmful number or a potential dislike number.
Thus, the Serban reference discloses or at least suggests the further limitation that the “determining, by the computer server, that the phone number is associated with a first category”.
Claim 1, as amended, further recites the limitation in which the “plurality of different metrics” comprise . . . “at least one of”: [A] “durations of past voice calls to a plurality of end users”, [C] “no-answering rates of the past voice calls to the plurality of end users”, or [D] “location information of the past voice calls”.
Since the recited metrics of [A], [C], or [D] are recited in the alternative as to [A], [C], or [D], establishing at least one of [A], [C], or [D] satisfies claim 1, as amended.
In particular, as regards the limitation of [A] “durations of the past voice calls to the plurality of end users”, the Serban reference discloses (at col. 9, line 55 to col. 10, line 15; and col. 11, line 66 to col. 12, line 18) the following:
The reporting and log module 240 is configured and/or programmed to record information associated with received phone calls, such as whether the call is determined to be associated with a scam [(spam)] caller or a legitimate caller
. . . . The reporting and log module 240 records and reports information about these received phone calls. For example, if a caller is determined to be a likely scam [(spam)] caller, the reporting and log module 240 can cause display on a subscriber's mobile device of a report showing that a call was determined to be associated with a likely scam caller, a phone number associated with the call, a time and date for the call, and so forth. The reporting and log module 240 can further log this call information in a database, for example, so that the information can be used to add a caller to a blacklist of callers. In some implementations, rather than automatically classifying a caller as a scam [(spam)] caller, the system can request confirmation from a subscriber that a caller is a scam caller, e.g., by having the caller review a call transcript or recording and select an icon or button confirming that the caller is a scam [(spam)] caller. In such implementations, this subscriber confirmation can also be logged by the reporting and log module 240.
. . . .
The process 400 then proceeds to block 420, where a training dataset is created using the received call data. Creating the training dataset can include, for example, processing the received call data. In implementations where the training dataset is limited to call audio, the call audio can be extracted from the call data. Creating the training dataset can include calculating variables and/or identifying characteristics of the call data. [C]reating the training dataset can include identifying metadata or other information about each call or caller, such as whether the caller number is domestic or international, whether the number is part of a range of a verifiable carrier, and so forth. It can also include identifying information about the duration of the call, whether the call had abruptly ended, or the number of call instances the caller had initiated in a certain time period. For example, a very frequent number of calls over a short period [(duration)] from an unverified caller can be associated with a high confidence of a scam caller. These and other characteristics of call data can be identified (e.g., by tagging data, calculating variables, etc.) in a training dataset.
In short, the Serban reference discloses or at least suggests the further limitation of “one or more metrics”—which is call data—"associated with the past voice calls include at least one of” [A] “durations of the past voice calls to the plurality of end users”, . . . .
As regards the limitation of [D] “location information of the past voice calls”, the Serban reference discloses (at col. 14, lines 20-34) the following:
In some implementations, the process 500 includes generating a log entry, database entry, or other record of a received phone call and whether the call was determined to be associated with a likely scam caller. The record can include, for example, call data and/or metadata, such as phone number information (e.g., phone number, location, name or business associated with the phone number, telecommunications service provider associated with the phone number, etc.), call audio, and so forth. The record can then be used, for example, to generate or update caller whitelists and blacklists, such as those used to determine whether a caller is a suspected scam caller (e.g., at decision block 520). Additionally, the record can be stored for later assessment and evaluation to determine accuracy of the conversational agent in detecting scam callers.
In short, the Serban reference discloses or at least suggests the further limitation of “one or more metrics”—which is call data associated with the past voice calls include [D] “location information of the past voice calls”.
Since the recited metrics of [A] and [D] are recited in the alternative of “at least one of”, either of these two claim elements [A] and [D] satisfies claim 1.
Thus, the Serban reference discloses or at least suggests the further limitation in which the metrics comprise . . . “at least one of”: [A] “durations of past voice calls to a plurality of end users”, [C] “no-answering rates of the past voice calls to the plurality of end users”, or [D] “location information of the past voice calls”.
Claim 1, as amended, now recites the further limitation of “aggregating outputs, from a plurality of different machine learning models that are generated based on a plurality of different metrics”.
While the Serban reference may not explicitly disclose the “aggregating” limitation, the Aggregating reference discloses (at page 1, first paragraph; see Aggregation Flowchart; page 2, 2nd and 3rd paragraphs; and see steps 1-3 at page 3) aggregating a plurality of machine learning models using datasets or different hyperparameters (which represent different metrics).
The Serban reference discloses machine learning of the subject metrics, as explained above, and the Aggregating reference discloses aggregating outputs from a plurality of machine learning models using datasets or different hyperparameters (which represent different metrics). These references are analogous since they concern machine learning based on different metrics or datasets/hyperparameters. A person having ordinary skill in the art would be motivated to use the aggregating technique disclosed by the Aggregating reference with the Serban reference disclosure of machine learning of the subject metrics, since aggregating a plurality of machine learning models provides improved accuracy of the machine learning models, as explained by the Aggregating reference (at page 1, first paragraph; see Aggregation Flowchart; page 2, 2nd and 3rd paragraphs; and see steps 1-3 at page 3).
Thus, the Serban reference in view of the Aggregating reference discloses or at least suggests the limitation of “aggregating outputs, from a plurality of different machine learning models that are generated based on a plurality of different metrics”.
Claim 1, as amended, further recites the limitation in which the “plurality of different metrics” comprise [B] “rejection rates of the past voice calls to the plurality of end users”, and (as explained above) “at least one of”: [A], [C], or [D].
As explained above, the Serban reference discloses at least one of [A], [C], or [D] so that this aspect of the limitation is satisfied.
While the Serban reference and Aggregating reference, as combined, may not explicitly disclose the limitation in which the “plurality of different metrics” comprise [B] “rejection rates of the past voice calls to the plurality of end users”, as regards the limitation of [B], the Chan reference discloses the further metric of “rejection rates” (at paragraphs [0053] and [0054]) the following:
[0053] FIG. 2C is a flowchart illustrating further operations of CCS [(Cognitive Computing Service)] 142. . . . Referring to step 240, CCS 142 analyzes user responses. According to an example embodiment, CCS 142 monitors and analyzes user responses, such as whether the user accepts or rejects the call, or hangs up after a short period of time, and analyzes the conversation and user physical responses during the conversation, such as if the user disconnected the incoming call within a short time after viewing caller details or a short time after answering a call. Disconnecting the call after a short conversation time or rejecting a call altogether may indicate a user's intent to add the phone number to a blacklist 114. In addition, CCS 132 may determine the reason that triggered the user physical response, such as caller name or a topic and update the caller details in a corresponding account stored in call log information 116 and call information database 144. For example, if the caller name was the reason for disconnecting the call, CCS 142 may further determine caller voice signature and suggest to add the user to a blacklist 114.
[0054] Referring to step 242, CCS 142 determines a user response value that is stored in call log information 116 or call information database 144 or both. The CCS 142 response threshold may be user defined and configured to a specific response value in user preferences. The response value may be calculated for example, by adding 1 to the response value of the corresponding caller any time when the user rejected a call from the caller by pressing an end call button, adding 10 to the response value when a user hang up the call within several seconds after hearing the voice of the caller and adding 100 to the response value every time when the user response showed intent that he never wants to speak to the caller again. The user may define a minimum threshold value that when reached the caller details are added to the blacklist 114.
In short, the Chan reference discloses or at least suggests the [B] limitation of “rejection rates of the past voice calls to the plurality of end users”.
As explained above, the Serban/Aggregating references and the Chan reference each discloses machine learning (such as, for example, Cognitive Computing Services (CCS) in the Chan reference) of the subject metrics, as explained above, and the Aggregating reference discloses aggregating outputs from a plurality of machine learning models using datasets or different hyperparameters (which represent different metrics). These references are analogous since they concern machine learning based on different metrics or datasets/hyperparameters. A person having ordinary skill in the art would be motivated to use the “rejection rates” metric disclosed by the Chan reference, with the other metrics of the machine learning models of Serban/Aggregating references to improve the accuracy of the machine learning models.
Thus, the Serban reference and the Aggregating reference, in view of the Chan reference, discloses or at least suggests the further limitation in which the metrics comprise [B] “rejection rates of the past voice calls to the plurality of end users”, and “at least one of”: [A] “durations of past voice calls to a plurality of end users”, [C] “no-answering rates of the past voice calls to the plurality of end users”, or [D] “location information of the past voice calls”.
Claim 1 is therefore rejected under 35 U.S.C. § 103 as being unpatentable over the Serban reference, in view of the Aggregating reference, and in view of the Chan reference, for the foregoing reasons.
Claim 3 depends from claim 1, and it recites the further limitations that the “first category includes at least one of a potential harmful number or a potential dislike number”, and the method further comprises “training the plurality of different machine learning models to determine whether a target phone number is at least one of the potential harmful number or the potential dislike number”.
It is first noted that, as explained above as to claim 1, nothing in the instant specification makes clear the difference between a “first category”, such as a “dislike” number or a “harmful” number, from a spam (scam) number.
It is also noted that the “phone number” is necessarily a “target phone number” in that the machine learning model is trained to determine that the “phone number” (which is a
“target phone number”) is associated with the first category.
Accordingly, the Serban reference discloses a “first category”, such as spam/scam--which necessarily includes at least one of a potential harmful number or a potential dislike number.
In short, the Serban reference discloses or at least suggests the further limitations that
the “first category includes at least one of a potential harmful number or a potential dislike number”, and the method further comprises “training the machine learning model to determine whether a target phone number is at least one of the potential harmful number or the potential dislike number”.
Claim 3 is therefore rejected under 35 U.S.C. § 103 as being unpatentable over the Serban reference, in view of the Aggregating reference, and in view of the Chan reference, for the same reasons as claim 1, and for the foregoing reasons.
Claim 4 depends from claim 3, and it recites the further limitations of “training of the
machine learning model to determine whether a target phone number is at least one of the potential harmful number or the potential dislike number” includes the recited operations.
As explained as to claim 3, the Serban reference discloses or at least suggests the further limitation of “training the machine learning model to determine whether a target phone number is at least one of the potential harmful number or the potential dislike number”.
As regards the recited operations, claim 4 includes the limitations of “obtaining, from a database, data associated with past voice calls to a plurality of end users, the past voice calls being originated from the target phone number”, and “extracting one or more metrics associated with the past voice calls”.
In this regard, the Serban reference discloses (at col. 9, line 55 to col. 10, line 15; and col. 11, line 66 to col. 12, line 18) the following:
The reporting and log module 240 is configured and/or programmed to record information [(that is, metrics)] associated with received phone calls, such as whether the call is determined to be associated with a scam [(spam)] caller or a legitimate caller
. . . . The reporting and log module 240 records and reports information about these received phone calls. For example, if a caller is determined to be a likely scam [(spam)] caller, the reporting and log module 240 can cause display on a subscriber's mobile device of a report showing that a call was determined to be associated with a likely scam caller, a phone number [(which is a target phone number)] associated with the call, a time and date for the call, and so forth. The reporting and log module 240 can further log this call information in a database, for example, so that the information can be used to add a caller [(that is, the target phone number of the caller)] to a blacklist of callers. In some implementations, rather than automatically classifying a caller as a scam [(spam)] caller, the system can request confirmation from a subscriber that a caller is a scam caller, e.g., by having the caller review a call transcript or recording and select an icon or button confirming that the caller is a scam [(spam)] caller. In such implementations, this subscriber confirmation can also be logged by the reporting and log module 240.
. . . .
The process 400 then proceeds to block 420, where a training dataset is created using the received call data [(that is, metrics)]. Creating the training dataset can include, for example, processing the received call data [(that is, metrics)]. In implementations where the training dataset is limited to call audio, the call audio can be extracted from the call data [(that is, metrics)]. Creating the training dataset can include calculating variables and/or identifying characteristics of the call data. [C]reating the training dataset can include identifying metadata [(that is, metrics)] or other information about each call or caller, such as whether the caller number is domestic or international, whether the number is part of a range of a verifiable carrier, and so forth. It can also include identifying information about the duration of the call, whether the call had abruptly ended, or the number of call instances the caller had initiated in a certain time period. For example, a very frequent number of calls over a short period [(duration)] from an unverified caller can be associated with a high confidence of a scam caller. These and other characteristics of call data [(that is, metrics)] can be identified (e.g., by tagging data, calculating variables, etc.) in a training dataset.
In short, the Serban reference discloses or at least suggests the further limitation of
“obtaining, from a database, data associated with past voice calls to a plurality of end users, the past voice calls being originated from the target phone number”, and “extracting a plurality of different metrics associated with the past voice calls”.
Claim 4, as amended, also includes the limitation of “creating, based at least in part on the data, training data set indicative of the plurality of different metrics”.
In this regard, the Serban reference discloses (at col. 9, line 55 to col. 10, line 15; and col. 11, line 66 to col. 12, line 18) (see cited text above) the further limitation of “creating, based at least in part on the data, training data set indicative of the one or more metrics”.
Still further, claim 4 includes the limitation of “training, using the training data set, the
plurality of different machine learning models to determine whether the target phone number is at least one of the potential harmful number or the potential dislike number”.
In this regard, the Abstract of the Serban reference discloses the following:
Systems and methods for detecting indications of a scam caller are disclosed. Call data, such as call audio, is received and used to create a training dataset. Using the training dataset, a machine learning model is trained to detect indications of a scam caller in a phone call. . . . If the caller is determined to be a likely scam caller, an alert can be generated and/or the call can be disconnected.
In short, the Serban reference discloses or at least suggests the further limitation of “training, using the training data set, the plurality of different machine learning models to determine whether the target phone number is at least one of the potential harmful number or the potential dislike number”.
Finally, claim 4 includes the limitation of “creating a UI string corresponding to the target phone number in response to a determination that the target phone number is at least one of the potential harmful number or the potential dislike number”.
In this regard and as explained with respect to the “string” limitation of claim 1, the Serban reference discloses (at col. 9, line 55 to col. 10, line 15) the following:
The reporting and log module 240 is configured and/or programmed to record information associated with received phone calls, such as whether the call is determined to be associated with a scam [(spam)] caller or a legitimate caller
. . . . The reporting and log module 240 records and reports information about these received phone calls. For example, if a caller is determined to be a likely scam [(spam)] caller, the reporting and log module 240 can cause [(generate or present)] [a] display on a subscriber's mobile device [(a UI of a user device)] of a report showing that a call was determined to be associated with a likely scam caller, a phone number associated with the call, a time and date for the call, and so forth.
In short, the Serban reference discloses or at least suggests the further limitation of “creating a UI string corresponding to the target phone number in response to a determination that the target phone number is at least one of the potential harmful number or the potential dislike number”.
Claim 4 is therefore rejected under 35 U.S.C. § 103 as being unpatentable over the Serban reference, in view of the Aggregating reference, and in view of the Chan reference, for the same reasons as claims 1 and 3, and for the foregoing reasons.
Claim 8 depends from claim 1, and it recites the further limitations of “adding, by the computer server, the phone number to blacklist”, in which the “blacklist is coupled to a webpage server that facilitates the user to look up the phone number in the blacklist”.
In this regard, the Serban reference discloses (at col. 9, line 55 to col. 10, line 15; and col. 11, line 66 to col. 12, line 18) the following:
The reporting and log module 240 is configured and/or programmed to record information associated with received phone calls, such as whether the call is determined to be associated with a scam [(spam)] caller or a legitimate caller
. . . . The reporting and log module 240 records and reports information about these received phone calls. For example, if a caller is determined to be a likely scam [(spam)] caller, the reporting and log module 240 can cause display on a subscriber's mobile device of a report showing that a call was determined to be associated with a likely scam caller, a phone number associated with the call, a time and date for the call, and so forth. The reporting and log module 240 can further log this call information in a database . . . so that the information can be used to add a caller to a blacklist of callers. In some implementations, rather than automatically classifying a caller as a scam [(spam)] caller, the system can request confirmation from a subscriber that a caller is a scam caller, e.g., by having the caller review a call transcript or recording and select an icon or button confirming that the caller is a scam [(spam)] caller. In such implementations, this subscriber confirmation can also be logged by the reporting and log module 240.
As explained with respect to claim 1 and in view of the foregoing, the system and method are implemented using servers 130 and the information can be stored in databases in the memory of the servers. In view of the widespread usage of webpages for storing, accessing and displaying information, it would be obvious for a person having ordinary skill in the art to implement a webpage on the server for use in storing, accessing and displaying the blacklist on a webpage server.
Thus, the Serban reference discloses (or at least suggests) the further limitations of “adding, by the computer server, the phone number to blacklist”, in which the “blacklist is coupled to a webpage server that facilitates the user to look up the phone number in the blacklist”.
Claim 8 is therefore rejected under 35 U.S.C. § 103 as unpatentable over the Serban reference, in view of the Aggregating reference, and in view of the Chan reference for the same reasons as claim 1, and for the further foregoing reasons.
Independent claim 17 includes actions or steps like those of claim 1, except that claim 17 is to a “non-transitory computer-readable storage medium storing computer-readable instructions, that when executed by a processor, cause the processor” to perform the recited
actions, which are like the steps (or actions) of claim 1.
The Serban reference discloses (at col. 14, lines 36-53; and col. 15, lines 15-41) a
“system” having a “processor”, a “network interface”, and a “memory storing instructions executed by the processor” to perform the recited actions, as follows:
FIG. 6 is a block diagram illustrating an example of a computing system 600 in which at least some operations described herein can be implemented. As shown, the computing system 600 can include: one or more processors 602, main memory 606, non-volatile memory 610, a network interface device 612, video display device 618, an input/output device 620, a control device 622. . . .
The memory (e.g., main memory 606, non-volatile memory 610, machine-readable medium 626) can be local, remote, or distributed. Although shown as a single medium, the machine-readable medium 626 can include multiple media (e.g., a centralized/distributed database and/or associated caches and servers) that store one or more sets of instructions 628. The machine-readable (storage) medium 626 can include any medium that is capable of storing, encoding, or carrying a set of instructions for execution by the computing system 600. The machine-readable medium 626 can be non-transitory or comprise a non-transitory device. In this context, a non-transitory storage medium can include a device that is tangible, meaning that the device has a concrete physical form, although the device can change its physical state. Thus, for example, non-transitory refers to a device remaining tangible despite this change in state.
Although implementations have been described in the context of fully functioning computing devices, the various examples are capable of being distributed as a program product in a variety of forms. Examples of machine-readable storage media, machine-readable media, or computer-readable media include recordable-type media such as volatile and non-volatile memory devices 610, removable flash memory, hard disk drives, optical disks, and transmission-type media such as digital and analog communication links.
In short, the Serban reference discloses a “system” having a “processor”, a “network interface”, and a “memory storing instructions executed by the processor” to perform the recited actions—like those of claim 1.
Claim 17 is therefore rejected under 35 U.S.C. § 103 as obvious over the Serban reference, in view of the Aggregating reference, and in view of the Chan reference, for the same reasons as the steps of claim 1, and for the foregoing reasons.
Claim 19 improperly depends from canceled claim 18. For purposes of the Section 103 analysis of claim 19, it is treated as depending from claim 17, and claim 19 includes the further limitations like those of dependent claim 3.
Accordingly, claim 19 is therefore rejected under 35 U.S.C. § 103 as being unpatentable over the Serban reference, in view of the Aggregating reference, and in view of the Chan reference, for the same reasons as claim 17 (rather than canceled claim 18) and dependent claim 3, and for the foregoing reasons.
Claim 20 depends from claim 19, which depends from canceled claim 18. For purposes
of the Section 103 analysis of claim 20, claim 19 is treated as depending from claim 17, and claim 20 includes the further limitations like those of dependent claim 4.
Accordingly, claim 20 is therefore rejected under 35 U.S.C. § 103 as being unpatentable over the Serban reference, in view of the Aggregating reference, and in view of the Chan reference, for the same reasons as claim 19 and dependent claim 4, and for the foregoing reasons.
Claim 5 is rejected under 35 U.S.C. § 103 as unpatentable over the Serban reference, in view of the Aggregating reference, further in view of the Chan reference, and further in view of U.S. Patent No. 11,711,464 to Ives (“the Ives reference”)—and which, like the instant application, names T-Mobile as the applicant and assignee, for the following reasons—for the
same reasons as claims 4, 3, and 1, and for the following reasons.
Claim 5 depends from claim 4, and it recites the further limitations of “obtaining calendar data on user equipments (UEs) of the plurality of end users”, and “generating, based at least in part on the calendar data, a first feature indicative of coincidence of events with the past voice calls”. That is, spam may re-occur on certain dates (and times), so that there is a coincidence of events with the past phone calls.
In this regard, the Ives reference discloses (at col. 5, line 44 to col. 6, line 3; and col. 13, line 55 to col. 14, line 15) the following:
The [machine learning] models that the spam call identifier 128 may use to determine whether a telephone call was likely a spam telephone call may include [machine learning] models trained using machine learning and historical data. The historical data may include data similar to the telephone call data 116 and labels indicating whether a previous telephone call was a spam telephone call or not a spam telephone call. The historical data may include, for the previous telephone calls, a date, time, and/or the duration of the telephone call. The historical data may include data indicating whether the called party answered the telephone call, whether the voicemail system answered the telephone call, and/or whether the calling party left a voicemail. The historical data may also include data identifying the calling party and data identifying the called party. The data identifying the calling party may include a phone number of the calling party, a name of the calling party, a geographic location of the calling party at the time of the call, a network location of the calling party at the time of the call, data identifying a computing device used by the calling party, and/or any other similar information of the calling party. The data identifying the called party may include a phone number of the called party, a name of the called party, a geographic location of the called party at the time of the call, a network location of the called party at the time of the call, data identifying a computing device used by the called party and/or any other similar information of the called party.
. . . .
The models that the spam call identifier 265 may use to determine whether a telephone call was likely a spam telephone call may include models trained using machine learning and historical data. The historical data may include data similar to the telephone call data 116 and labels indicating whether a previous telephone call was a spam telephone call or not a spam telephone call. The historical data may include, for the previous telephone calls, a date, time, and/or the duration of the telephone call. The historical data may include data indicating whether the called party answered the telephone call, whether the voicemail system answered the telephone call, and/or whether the calling party left a voicemail. The historical data may also include data identifying the calling party and data identifying the called party. The data identifying the calling party may include a phone number of the calling party, a name of the calling party, a geographic location of the calling party at the time of the call, a network location of the calling party at the time of the call, data identifying a computing device used by the calling party, and/or any other similar information of the calling party. The data identifying the called party may include a phone number of the called party, a name of the called party, a geographic location of the called party at the time of the call, a network location of the called party at the time of the call, data identifying a computing device used by the called party and/or any other similar information of the called party.
In view of the disclosure that the plurality of machine learning models that the spam call
identifier may use to determine whether a telephone call was a spam telephone call may include the plurality of machine learning models trained using machine learning and historical data, in which the historical data may include data indicating whether a previous telephone call was a spam telephone call, and in which the historical data may include, for the previous telephone calls, a date, time, and/or the duration of the telephone calls.
A person having ordinary skill in the art would recognize that the plurality of machine learning models would include the dates (e.g., a particular date or day of the week) of prior spam calls to determine whether a call is a spam call, since there may be a correlation or coincidence based on a particular date (or day).
The Serban and the Chan references and the Ives reference are plainly analogous to the claimed subject matter because they are in the same field of endeavor of using the plurality of machine learning models to detect and reduce spam (that is, disliked or harmful phone numbers).
It is therefore the case that it would have been obvious to a person having ordinary skill in the art before the effective date filing date of the claimed invention to modify the Serban and Chan references, based on the teachings, motivations and/or suggestions of the Ives reference, so as to include the capability of using re-occurring dates (and/or times) from the historical call data to determine whether a call is a spam call.
In short, the Ives reference also discloses (or at least suggests) to a person having ordinary skill in the art the further limitation of “obtaining calendar data”—that is, a date, which is calendar data, “on user equipments (UEs) of the plurality of end users”, and “generating, based at least in part on the calendar data, a first feature indicative of coincidence
of events with the past voice calls”.
Also, it is noted that the Serban reference similarly discloses (at col. 9, line 55 to col. 10, line 15) the following:
The reporting and log module 240 is configured and/or programmed to record information [(that is, metrics)] associated with received phone calls, such as whether the call is determined to be associated with a scam [(spam)] caller or a legitimate caller. . . . The reporting and log module 240 records and reports information about these received phone calls. For example, if a caller is determined to be a likely scam [(spam)] caller, the reporting and log module 240 can cause display on a subscriber's mobile device of a report showing that a call was determined to be associated with a likely scam caller, a phone number [(which is a target phone number)] associated with the call, a time and date [—which is calendar data—] for the call, and so forth. The reporting and log module 240 can further log this call information in a database . . . so that the information can be used to add a caller [(that is, the target phone number of the caller)] to a blacklist of callers. In some implementations, rather than automatically classifying a caller as a scam [(spam)] caller, the system can request confirmation from a subscriber that a caller is a scam caller, e.g., by having the caller review a call transcript or recording and select an icon or button confirming that the caller is a scam [(spam)] caller. In such implementations, this subscriber confirmation can also be logged by the reporting and log module 240.
In short, the Serban reference also discloses or at least suggests the further limitation of “obtaining calendar data”—that is, a date, which is calendar data, “on user equipments (UEs)”.
Accordingly, the Serban reference in view of the Ives reference discloses (or at least
suggests) the further limitations of “obtaining calendar data”—that is, a date, which is calendar data, “on user equipments (UEs) of the plurality of end users”, and “generating, based at least in part on the calendar data, a first feature indicative of coincidence of events with the past voice calls”.
Finally, claim 5 also includes the limitations of “updating, using the training data set and the first feature, the plurality of different machine learning models to generate a plurality of updated machine learning models”, and “updating the UI string based on the plurality of updated machine learning models”.
In particular, the Serban reference discloses (at col. 11, line 48 to col. 12, line 18), as
follows:
Training of Machine Learning Model
FIG. 4 is a flow diagram illustrating a process 400 for training a machine learning model to detect indications of a scam caller during a phone call. The process 400 begins at block 410, where call data is received for multiple phone calls associated with known scam callers and known good callers. This call data can be, for example, call audio, such as recorded phone calls. Call data can include metadata and other information as well, such as call detail records (CDRs), identities of a caller and/or called party, identifiers associated with callers and/or called parties (e.g., phone numbers), device information for callers and/or called parties, phone number information (e.g., type of number, location information, etc.), telecommunication service provider information, and so forth. Call data can also include network-level data, such as data about a telecommunications service provider associated with the caller and/or about a telecommunications network or components thereof.
The process 400 then proceeds to block 420, where a training dataset is created using the received call data. Creating the training dataset can include, for example, processing the received call data. In implementations where the training dataset is limited to call audio, the call audio can be extracted from the call data. Creating the training dataset can include calculating variables and/or identifying characteristics of the call data. In addition, creating the training dataset can include identifying metadata or other information about each call or caller, such as whether the caller number [(which a target phone number)] is domestic or international, whether the [phone] number is part of a range of a verifiable carrier, and so forth. It can also include identifying information about the duration of the call, whether the call had abruptly ended, or the number of call instances the caller had initiated in a certain time period. For example, a very frequent number of calls over a short period from an unverified caller can be associated with a high confidence of a scam [(spam)] caller. These and other characteristics of call data can be identified (e.g., by tagging data, calculating variables, etc.) in a training dataset.
The process 400 then proceeds to block 430, where the training dataset is used to train the machine learning model to detect indications of a scam [(spam)] caller in a phone call.
Still further, the Abstract of the Serban reference discloses the following:
Systems and [machine learning] methods for detecting indications of a scam caller are disclosed. Call data, such as call audio, is received and used to create a training dataset. Using the training dataset, a machine learning model is trained [(and necessarily updated)] to detect indications of a scam caller in a phone call. . . . If the caller is determined to be a likely scam caller, an alert can be generated and/or the call can be disconnected.
Any machine learning model is necessarily updated using the training dataset, so that an updated machine learning model is generated.
As explained with respect to claim 1, the Serban reference discloses generating strings (that is, text strings or messages). In this regard, any text message (string) is necessarily based on whether a call is a spam call as determined by the trained and updated machine learning model using the training dataset.
In particular, the Serban reference discloses (at col. 9, line 55 to col. 10, line 15) the following:
The reporting and log module 240 is configured and/or programmed to record information associated with received phone calls, such as whether the call is determined to be associated with a scam [(spam)] caller or a legitimate caller
. . . . The reporting and log module 240 records and reports information about these received phone calls. For example, if a caller is determined to be a likely scam [(spam)] caller, the reporting and log module 240 can cause [(generate or present)] [a] display [(that is, a text string)] on a subscriber's mobile device [(a UI of a user device)] of a report showing that a call was determined to be associated with a likely scam caller, a phone number associated with the call, a time and date for the call, and so forth.
In short, the Serban reference discloses (or at least suggests) the further limitations of “updating, using the training data set and the first feature, the plurality of different machine learning models to generate a plurality of updated machine learning models”, and “updating the UI string based on the plurality of updated machine learning models”.
Claim 5 is therefore rejected under 35 U.S.C. § 103 as unpatentable over the Serban reference, in view of the Aggregating reference, in view of the Chan reference, in view of the Andersen reference, and in view of the Ives reference, for the same reasons as claims 1, 3, and 4, and for the foregoing reasons.
Claim 6 is rejected under 35 U.S.C. § 103 as unpatentable over the Serban reference, in view of the Aggregating reference, further in view of the Chan reference, further in view of U.S. Patent No. 11,330,023 to Chen et al. (“the Chen reference”), for the same reasons as claims 4, 3, and 1, and for the following reasons.
Claim 6 depends from claim 4, and it recites the further limitations of “obtaining
feedbacks on the past voice calls from the plurality of end users”, and “generating, based at least in part on the feedbacks, a second feature indicative of intentions of handling the past voice calls”.
In this regard, the Chen reference discloses (at col. 9, lines 35-45; col. 9, line 62 to col. 10, line 40; and col. 11, lines 39-60) the following:
FIG. 5 illustrates the example generation . . . of one or more such models, based on which an analysis of call requests may be performed to determine whether the call requests are spam. MLAAC 303 may receive (at 502), for example, UE feedback information 501 from one or more UEs 101 (e.g., UEs 101 that have received call requests). . . . MLAAC 303 may receive, such as via an API implemented by UEs 101, information indicating whether particular call requests were answered or ignored, such as call requests that were determined as not being spam and/or otherwise allowed to be provided to UEs 101.
. . . .
[UE] feedback information 501 may include information regarding calls placed by UEs 101, which may include calls to callers from whom call requests have been identified as spam. For example, if a particular UE 101 calls back a caller from whom a call request has been identified as spam, this may be an indicator that the classification of the call request as spam was incorrect, and that that call requests having similar attributes should be less likely to be classified as spam in the future.
[To] refine (at 508) spam detection model 507, MLAAC 303 may also make use of call information 503 (received at 504) and spam determination information 505 (received at 506). [Call] information 503 (e.g., words, phrases, sound signatures, MDNs, etc.) may be used to refine spam detection model 507 for classifications of spam for call requests sharing similar attributes. Similarly, spam determination information 505 (e.g., previous determinations of whether given call requests) may also be used to refine spam detection model 507. For example, a likelihood that a classification of particular attributes as being associated with spam may be more heavily adjusted when UE feedback information 501 indicates that the classification may have been incorrect.
MLAAC 303 may receive (at 502) UE feedback information 501 from . . . UEs 101, such as from one or more APIs implemented by UEs 101 that are configured to communicate with MLAAC 303. MLAAC 303 may receive or determine (at 504) call information 503 based on call audio from one or more calling UEs 101, such as call audio provided (e.g., at 110) as part of a call screening process. In . . . lieu of, receiving audio, MLAAC 303 may receive video, a text transcript, metadata, or other information derived from audio and/or video. [W]hile examples are discussed here in the context of voice/audio calls, similar concepts may apply for video calls or other types of calls or messaging. MLAAC 303 may also receive or determine (at 506) spam determination information 505 based on previous iterations of a spam analysis process performed on past call requests. MLAAC 303 may receive (at 502, 504, and/or 506) such information on an ongoing basis, and may refine (at 508) spam detection model 507 on an ongoing basis. In this manner, spam detection model 507 may continue to be improved, and resulting spam analyses may continue to be improved, on an ongoing basis.
. . . .
Process 600 may additionally include receiving (at 612) user and/or UE feedback after the spam determination. For example, as discussed above, MLSDC 105 may determine whether UE 101-2 answered the call (if the call request was allowed to proceed), and/or how long the ensuing call was if the call was answered. As another example, MLSDC 105 may determine whether callee UE 101-1 called calling UE 101-1, sent calling UE 101-1 a message (e.g., a Short Message Service (“SMS”) message, a Multimedia Messaging Service (“MMS”) message, or the like), added calling UE 101-1 to an address book, or performed other similar operations that may suggest that the call request was incorrectly classified as spam.
Process 600 may also include refining (at 614) one or more models based on the feedback. For example, . . . MLSDC 105 (e.g., MLAAC 303) may refine the one or more models based on the classification of the call request as spam or not spam, UE feedback information, and/or other suitable information. As discussed above, the models may be refined on an ongoing basis, in order to continually improve the accuracy of the models.
The Serban and Chan references and the Chen reference are plainly analogous to the claimed subject matter because they are in the same field of endeavor of using the plurality of machine learning models to detect and reduce spam (that is, disliked or harmful phone numbers).
It is therefore the case that it would have been obvious to a person having ordinary skill in the art before the effective date filing date of the claimed invention to modify the Serban and Chan references, based on the teachings, motivations and/or suggestions of the Chen reference, so as to include the capability of using feedbacks of the past voice calls from the end users, and generating, based on the feedbacks, how the past voice calls were handled to determine whether a particular call is a spam call.
In short, the Serban and Chan references and the Chen reference disclose (or at least suggest) the further limitations of “obtaining feedbacks on the past voice calls from the plurality of end users”, and “generating, based at least in part on the feedbacks, a second feature indicative of intentions of handling the past voice calls”.
Finally, claim 6 also includes the limitations of “updating, using the training data set and the second feature, the machine learning model to generate a plurality of updated machine learning models”, and “updating the UI string based on the plurality of updated machine learning models”.
In particular, the Serban reference discloses (at col. 11, line 48 to col. 12, line 18), as
follows:
Training of Machine Learning Model
FIG. 4 is a flow diagram illustrating a process 400 for training a machine learning model to detect indications of a scam caller during a phone call. The process 400 begins at block 410, where call data is received for multiple phone calls associated with known scam callers and known good callers. This call data can be, for example, call audio, such as recorded phone calls. Call data can include metadata and other information as well, such as call detail records (CDRs), identities of a caller and/or called party, identifiers associated with callers and/or called parties (e.g., phone numbers), device information for callers and/or called parties, phone number information (e.g., type of number, location information, etc.), telecommunication service provider information, and so forth. Call data can also include network-level data, such as data about a telecommunications service provider associated with the caller and/or about a telecommunications network or components thereof.
The process 400 then proceeds to block 420, where a training dataset is created using the received call data. Creating the training dataset can include, for example, processing the received call data. In implementations where the training dataset is limited to call audio, the call audio can be extracted from the call data. Creating the training dataset can include calculating variables and/or identifying characteristics of the call data. In addition, creating the training dataset can include identifying metadata or other information about each call or caller, such as whether the caller number [(which a target phone number)] is domestic or international, whether the [phone] number is part of a range of a verifiable carrier, and so forth. It can also include identifying information about the duration of the call, whether the call had abruptly ended, or the number of call instances the caller had initiated in a certain time period. For example, a very frequent number of calls over a short period from an unverified caller can be associated with a high confidence of a scam [(spam)] caller. These and other characteristics of call data can be identified (e.g., by tagging data, calculating variables, etc.) in a training dataset.
The process 400 then proceeds to block 430, where the training dataset is used
to train the machine learning model to detect indications of a scam [(spam)]
caller in a phone call.
Still further, the Abstract of the Serban reference discloses the following:
Systems and [machine learning] methods for detecting indications of a scam caller are disclosed. Call data, such as call audio, is received and used to create a training dataset. Using the training dataset, a machine learning model is trained [(and necessarily updated)] to detect indications of a scam caller in a phone call. . . . If the caller is determined to be a likely scam caller, an alert can be generated and/or the call can be disconnected.
Any machine learning model is necessarily updated using the training dataset, so that an updated machine learning model is generated.
As explained with respect to claim 1, the Serban reference discloses generating strings (that is, text strings or messages). In this regard, any text message (string) is necessarily based on whether a call is a spam call as determined by the trained and updated machine learning model using the training dataset.
In particular, the Serban reference discloses (at col. 9, line 55 to col. 10, line 15) the following:
The reporting and log module 240 is configured and/or programmed to record information associated with received phone calls, such as whether the call is determined to be associated with a scam [(spam)] caller or a legitimate caller
. . . . The reporting and log module 240 records and reports information about these received phone calls. For example, if a caller is determined to be a likely scam [(spam)] caller, the reporting and log module 240 can cause [(generate or present)] [a] display [(that is, a text string)] on a subscriber's mobile device [(a UI of a user device)] of a report showing that a call was determined to be associated with a likely scam caller, a phone number associated with the call, a time and date for the call, and so forth.
In short, the Serban reference discloses (or at least suggests) the further limitations of “updating, using the training data set and the second feature, the machine learning model to generate a plurality of updated machine learning models”, and “updating the UI string based on the plurality of updated machine learning models”.
Claim 6 is therefore rejected under 35 U.S.C. § 103 as unpatentable over the Serban
reference, in view of the Aggregating reference, in view of the Chan reference, in view of the Andersen reference, and in view of the Chen reference, for the same reasons as claims 1, 3, and 4, and for the foregoing reasons.
Claims 9, 11, 12, and 16 are rejected under 35 U.S.C. § 103 as obvious over U.S. Patent No. 11,463,582 to Serban (“the Serban reference”)—and which, like the instant application, names T-Mobile as the applicant and assignee, in view of Kalra Khwab, Bootstrap Aggregating: Improving Machine Learning Models through Resampling (April 25, 2023) (“the Aggregating reference”), further in view of U.S. Published Patent Application No. 2018/0152558 (“the Chan reference”), and further in view of Andersen, “How Many Phone Calls Are You Missing? See How Your Industry Stacks Up (“the Andersen reference”), for the following reasons.
Independent claim 9, as amended, includes actions or steps like those of claim 1, except that claim 9 is to a “system” having a “processor”, a “network interface”, and a “memory storing instructions executed by the processor” to perform the recited actions, which are like the steps (or actions) of claim 1.
The Serban reference discloses (at col. 14, lines 36-53) a “system” having a “processor”, a “network interface”, and a “memory storing instructions executed by the processor” to
perform the recited actions, as follows:
FIG. 6 is a block diagram illustrating an example of a computing system 600 in which at least some operations described herein can be implemented. As shown, the computing system 600 can include: one or more processors 602, main memory 606, non-volatile memory 610, a network interface device 612, video display device 618, an input/output device 620, a control device 622 (e.g., keyboard and pointing device), a drive unit 624 that includes a storage medium 626, and a signal generation device 630 that are communicatively connected to a bus 616. The bus 616 represents one or more physical buses and/or point-to-point connections that are connected by appropriate bridges, adapters, or controllers. Various common components (e.g., cache memory) are omitted from FIG. 6 for brevity. Instead, the computer system 600 is intended to illustrate a hardware device on which components illustrated or described relative to the examples of the figures and any other components described in this specification can be implemented.
In short, the Serban reference discloses a “system” having a “processor”, a “network interface”, and a “memory storing instructions executed by the processor” to perform the recited actions—which are like those of claim 1, except for the “plurality of different metrics” limitation in the “aggregating outputs” clause.
In particular, claim 9, as amended, includes the further limitation in which the “plurality of different metrics” comprise: [A] “no-answering rates of the past voice calls to the plurality of end users”, and at least one of: [B] “durations of past voice calls to a plurality of end users”, [C] “rejection rates of the past voice calls to the plurality of end users”, or [D] “location information of the past voice calls”.
As explained above as to claim 1, the Serban reference discloses the “durations” and “location” limitations of claim 9.
As explained above as to claim 1, the Chan reference discloses the “rejection rates”.
While the Serban, Aggregating, and Chan references may not explicitly disclose the “no-answering” limitation of claim 9, the Andersen reference specifically discloses (at page 2, “Unanswered Call Rates” Section) the further different metric of “unanswered call rates”—which are “no-answering rates” as in claim 9—of voice calls to the users.
The Serban, Aggregating, and Chan references concern using different metrics in machine learning models for indicating spam/scam calls (such as a potential harmful number or a potential dislike number). A person having ordinary skill in the art would be motivated to use the “unanswered call rates” metric of the Andersen reference to improve the accuracy of the machine learning models for indicating spam/scam calls.
Claim 9 is therefore rejected under 35 U.S.C. § 103 as being unpatentable over the Serban reference, in view of the Aggregating reference, for the same reasons as the steps of claim 1, and for the foregoing reasons.
Claim 11 depends from claim 9, and it includes the further limitations like those of dependent claim 3.
Accordingly, claim 11 is therefore rejected under 35 U.S.C. § 103 as being unpatentable over the Serban reference, in view of the Aggregating reference, in view of the Chan reference, and in view of the Andersen reference, for the same reasons as claim 9 and dependent claim 3, and for the foregoing reasons.
Claim 12 depends from claim 11, and it includes the further limitations like those of dependent claim 4.
Accordingly, claim 12 is therefore rejected under 35 U.S.C. § 103 as being unpatentable
over the Serban reference, in view of the Aggregating reference, in view of the Chan reference, and in view of the Andersen reference, for the same reasons as claim 11 and dependent claim 4, and for the foregoing reasons.
Claim 16 depends from claim 9, and like claim 8, it recites the further limitations of “adding, by the computer server, the phone number to blacklist”, in which the “blacklist is coupled to a webpage server that facilitates the user to look up the phone number in the blacklist”.
Accordingly, claim 16 is therefore rejected under 35 U.S.C. § 103 as unpatentable over the Serban reference, in view of the Aggregating reference, in view of the Chan reference, and in view of the Andersen reference, for the same reasons as claim 9 and claim 8, and for the foregoing reasons.
Claim 13 is rejected under 35 U.S.C. § 103 as unpatentable over the Serban reference, in view of the Aggregating reference, further in view of the Chan reference, further in view of Andersen, “How Many Phone Calls Are You Missing? See How Your Industry Stacks Up (“the Andersen reference”), and further in view of U.S. Patent No. 11,711,464 to Ives (“the Ives reference”)—and which, like the instant application, names T-Mobile as the applicant and assignee, for the following reasons—for the same reasons as claims 12, 11, and 9, and for the following reasons.
Claim 13 depends from claim 12, and it includes the further limitations like those of dependent claim 5.
Accordingly, claim 13 is therefore rejected under 35 U.S.C. § 103 as unpatentable over the Serban reference, in view of the Aggregating reference, in view of the Chan reference, in view of the Andersen reference, and in view of the Ives reference, for the same reasons as claims 12, 11, 9 and dependent claim 5, and for the foregoing reasons.
Claim 14 is rejected under 35 U.S.C. § 103 as unpatentable over the Serban reference, in view of the Aggregating reference, further in view of the Chan reference, further in view of Andersen, “How Many Phone Calls Are You Missing? See How Your Industry Stacks Up (“the Andersen reference”), and further in view of U.S. Patent No. 11,330,023 to Chen et al. (“the Chen reference”), for the same reasons as claims 12, 11, and 9, and for the following reasons.
Claim 14 depends from claim 12, and it includes the further limitations like those of dependent claim 6.
Accordingly, claim 14 is therefore rejected under 35 U.S.C. § 103 as being unpatentable over the Serban reference, in view of the Aggregating reference, in view of the Chan reference, in view of the Andersen reference, and in view of the Chen reference, for the same reasons as claim 12, 11, 9 and dependent claim 6, and for the foregoing reasons.
Response to Arguments
The RCE Amendment does not address in any specific manner the facts presented in the Non-Final Office Action that explain in detail why the applied references disclose all of the
limitations of prior claim 1 (as well as the remaining claims).
The RCE Amendment therefore amended independent claims 1, 9 and 17, as explained above.
Applicant’s arguments with respect to the pending claims have been considered but are moot because of the new grounds of rejection that are attributable to the new amendments. (See M.P.E.P. FP 7.38). While not repeated here in the Response Section, the new grounds of rejection provided above are referenced here as necessary.
In particular, as explained above, claim 1, as amended, is therefore rejected under 35
U.S.C. § 103 as unpatentable over the applied references, as detailed herein.
While not repeated here in the Response Section, the present Office Action also explains in detail why the dependent claims of claim 1 are also rejected under 35 U.S.C. § 103 as unpatentable over the applied references, as detailed herein.
In particular, as explained above, claim 9, as amended, is therefore rejected under 35
U.S.C. § 103 as unpatentable over the applied references, as detailed herein.
While not repeated here in the Response Section, the present Office Action also explains in detail why the dependent claims of claim 9 are also rejected under 35 U.S.C. § 103 as unpatentable over the applied references, as detailed herein.
In particular, as explained above, claim 17, as amended, is therefore rejected under 35
U.S.C. § 103 as unpatentable over the applied references, as detailed herein.
While not repeated here in the Response Section, the present Office Action also explains in detail why the dependent claims of claim 17 are also rejected under 35 U.S.C. § 103 as unpatentable over the applied references, as detailed herein.
Conclusion
Any inquiry concerning this communication or earlier communications from the examiner should be directed to AARON C. DEDITCH whose telephone number is (571)272-4780.
The examiner can normally be reached Monday through Thursday at 8:00 am to 6: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, Rafael Perez-Gutierrez can be reached on 571-272-7915. 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.
/Aaron C. Deditch/Examiner, Art Unit 2642
/Rafael Pérez-Gutiérrez/Supervisory Patent Examiner, Art Unit 2642 2/18/2026