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 .
Examiner Notes
Examiner cites particular columns and line numbers in the references as applied to the claims below for convenience of the applicant. Although the specified citations are representative of the teachings in the art and are applied to the specific limitations within the individual claim, other passages and figures may apply as well. It is respectfully requested that, in preparing responses, the applicant fully consider the references cited in their entirety as potentially teaching all or part of the claimed invention, as well as the context of the passage as taught by the prior art or disclosed by the examiner.
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 3/09/2026 has been entered.
Response to Amendment
The Amendment filed 2/12/2026 has been entered. The Amendments to the claims have been fully considered and overcome all Rejections under 35 U.S.C. 112(a) set forth in the previous Office Action. Claims 1-20 remain pending in the present Office Action.
Claim Objections
Claims 6, 14 and 16 are objected to because of the following informalities:
In claim 6, lines 1-2, the limitation “wherein automatically updating the database of known session interaction parameters comprises” should be modified to maintain consistency with claim 1, e.g., by reciting “automatically updating, in real time, within the database of known session interaction parameters, the association comprises”.
In claim 14, lines 1-2, the limitation “wherein automatically updating the database of known session interaction parameters comprises” should be modified to maintain consistency with claim 9, e.g., by reciting “automatically updating, in real time, within the database of known session interaction parameters, the association comprises”.
In claim 16, lines 28-32, the limitations “by: input [….], and identify” is grammatically incorrect and should recite “by inputting […], and identifying”.
Appropriate correction is required.
Claim Interpretation
The following is a quotation of 35 U.S.C. 112(f):
(f) Element in Claim for a Combination. – An element in a claim for a combination may be expressed as a means or step for performing a specified function without the recital of structure, material, or acts in support thereof, and such claim shall be construed to cover the corresponding structure, material, or acts described in the specification and equivalents thereof.
The following is a quotation of pre-AIA 35 U.S.C. 112, sixth paragraph:
An element in a claim for a combination may be expressed as a means or step for performing a specified function without the recital of structure, material, or acts in support thereof, and such claim shall be construed to cover the corresponding structure, material, or acts described in the specification and equivalents thereof.
The claims in this application are given their broadest reasonable interpretation using the plain meaning of the claim language in light of the specification as it would be understood by one of ordinary skill in the art. The broadest reasonable interpretation of a claim element (also commonly referred to as a claim limitation) is limited by the description in the specification when 35 U.S.C. 112(f) or pre-AIA 35 U.S.C. 112, sixth paragraph, is invoked.
As explained in MPEP § 2181, subsection I, claim limitations that meet the following three-prong test will be interpreted under 35 U.S.C. 112(f) or pre-AIA 35 U.S.C. 112, sixth paragraph:
(A) the claim limitation uses the term “means” or “step” or a term used as a substitute for “means” that is a generic placeholder (also called a nonce term or a non-structural term having no specific structural meaning) for performing the claimed function;
(B) the term “means” or “step” or the generic placeholder is modified by functional language, typically, but not always linked by the transition word “for” (e.g., “means for”) or another linking word or phrase, such as “configured to” or “so that”; and
(C) the term “means” or “step” or the generic placeholder is not modified by sufficient structure, material, or acts for performing the claimed function.
Use of the word “means” (or “step”) in a claim with functional language creates a rebuttable presumption that the claim limitation is to be treated in accordance with 35 U.S.C. 112(f) or pre-AIA 35 U.S.C. 112, sixth paragraph. The presumption that the claim limitation is interpreted under 35 U.S.C. 112(f) or pre-AIA 35 U.S.C. 112, sixth paragraph, is rebutted when the claim limitation recites sufficient structure, material, or acts to entirely perform the recited function.
Absence of the word “means” (or “step”) in a claim creates a rebuttable presumption that the claim limitation is not to be treated in accordance with 35 U.S.C. 112(f) or pre-AIA 35 U.S.C. 112, sixth paragraph. The presumption that the claim limitation is not interpreted under 35 U.S.C. 112(f) or pre-AIA 35 U.S.C. 112, sixth paragraph, is rebutted when the claim limitation recites function without reciting sufficient structure, material or acts to entirely perform the recited function.
Claim limitations in this application that use the word “means” (or “step”) are being interpreted under 35 U.S.C. 112(f) or pre-AIA 35 U.S.C. 112, sixth paragraph, except as otherwise indicated in an Office action. Conversely, claim limitations in this application that do not use the word “means” (or “step”) are not being interpreted under 35 U.S.C. 112(f) or pre-AIA 35 U.S.C. 112, sixth paragraph, except as otherwise indicated in an Office action.
This application includes one or more claim limitations that do not use the word “means,” but are nonetheless being interpreted under 35 U.S.C. 112(f) or pre-AIA 35 U.S.C. 112, sixth paragraph, because the claim limitation(s) uses a generic placeholder that is coupled with functional language without reciting sufficient structure to perform the recited function and the generic placeholder is not preceded by a structural modifier. Such claim limitation(s) is/are: “suspect detection unit” and “suspect detection unit module” in claims 1, 7, 9, 16 and 19.
Because this/these claim limitation(s) is/are being interpreted under 35 U.S.C. 112(f) or pre-AIA 35 U.S.C. 112, sixth paragraph, it/they is/are being interpreted to cover the corresponding structure described in the specification as performing the claimed function, and equivalents thereof.
If applicant does not intend to have this/these limitation(s) interpreted under 35 U.S.C. 112(f) or pre-AIA 35 U.S.C. 112, sixth paragraph, applicant may: (1) amend the claim limitation(s) to avoid it/them being interpreted under 35 U.S.C. 112(f) or pre-AIA 35 U.S.C. 112, sixth paragraph (e.g., by reciting sufficient structure to perform the claimed function); or (2) present a sufficient showing that the claim limitation(s) recite(s) sufficient structure to perform the claimed function so as to avoid it/them being interpreted under 35 U.S.C. 112(f) or pre-AIA 35 U.S.C. 112, sixth paragraph.
For clarity of the record, the Examiner would like to point to FIG. 2 and paragraph [30] which teach an algorithm for utilizing a suspect detection unit within a computing device to generate an interactive communication. The “suspect detection unit” and “suspect detection unit module” are therefore interpreted to be referring to software executing within a computing device by performing the algorithm of FIG. 2.
Claim Rejections - 35 USC § 103
The following is a quotation of 35 U.S.C. 103 which forms the basis for all obviousness rejections set forth in this Office action:
A patent for a claimed invention may not be obtained, notwithstanding that the claimed invention is not identically disclosed as set forth in section 102, if the differences between the claimed invention and the prior art are such that the claimed invention as a whole would have been obvious before the effective filing date of the claimed invention to a person having ordinary skill in the art to which the claimed invention pertains. Patentability shall not be negated by the manner in which the invention was made.
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, 5-7, 9-11, 13-14, and 16-19 are rejected under 35 U.S.C. 103 as being unpatentable over Woirhaye et al. (U.S. Patent No. 10,778,840), hereinafter Woirhaye, in view of Meredith et al. (U.S. Pub. No. 2021/0037135), hereinafter Meredith, HAZONY et al. (U.S. Pub. No. 2021/0240836), hereinafter HAZONY, Botner et al. (U.S. Patent No. 10,601,986), hereinafter Botner, and Weiss et al. (U.S. Patent No. 10,447,838), hereinafter Weiss.
Regarding claim 1, Woirhaye teaches a computer-implemented method (Col. 7, lines 26-32 – “FIG. 3 is a flow diagram of an example computer-implemented method 300 for identifying unsolicited communications on a computing device. The steps shown in FIG. 3 may be performed by any suitable computer-executable code and/or computing system, including system 100 in FIG. 1, system 200 in FIG. 2, and/or variations or combinations of one or more of the same.”; Col. 6, lines 2-6 – “In one example, all or a portion of the functionality of the modules 102 may be performed by the computing device 202, the classification server 206, the category server 212, and/or any other suitable computing system.”; Col. 12, lines 33-34 – “FIG. 4 is a flow diagram of an example computer-implemented method 400”) comprising:
(FIG. 1 and 2, physical processor 130),
continually receiving, by the at least one processor, (Col. 8, line 38-Col. 9, line 5 – “The classification data may be historical data that has been collected from many users of the system who have provided feedback with regards to the unrecognized phone number. In some examples, the classification data may be a collection of data obtained from analyzing communications that have been transmitted through the system, which may be identified based on the content of the message, originator of the message, or the like. In some examples, classification data 124, which may also be referred to as reputation data, for incoming calls from unrecognized phone numbers may be generated using data collected through one or more known crowdsourcing methodologies. Different types of data may be collected from user devices, such as user devices 208 A, 208B, and 208N (collectively referred to as 208). For example, the user devices 208B and 208N may receive incoming calls from unrecognized phone numbers, such as from unknown device 210 associated with an unrecognized phone number. […] In some examples, the data collected may be inferred from a user interaction with the incoming phone call rather than direct collection of data from a user. For example, the classification server 206 may receive information from the user devices 208 about the incoming call from the unrecognized phone number, such as time and date of the phone call, user interaction with the incoming phone call (e.g., ignored phone call, rejected phone call, sent to voicemail, etc.), the number of phone calls received from the unrecognized phone call within a time period, or the like.” The classification server 206 may receive and store data relating to incoming calls received at user devices 208, such as the number of calls from an unrecognized number to user devices 208 within a time period (“predetermined period of time”).);
identifying, by the at least one processor, based on the monitoring data, a plurality of related incoming interaction sessions being initiated, within the predetermined period of time, across the plurality of computing devices associated with the plurality of users (Col. 8, lines 23-31 – “At step 306, one or more systems described herein may obtain classification data 124 using the unrecognized phone number. […] The classification server 206 may query a data store, using the unrecognized phone number, to identify any classification data 124 associated with the unrecognized phone number.”; Col. 8, lines 38-45 – “The classification data may be historical data that has been collected from many users of the system who have provided feedback with regards to the unrecognized phone number. In some examples, the classification data may be a collection of data obtained from analyzing communications that have been transmitted through the system, which may be identified based on the content of the message, originator of the message, or the like.”; Col. 8, lines 50-55 – “Different types of data may be collected from user devices, such as user devices 208 A, 208B, and 208N (collectively referred to as 208). For example, the user devices 208B and 208N may receive incoming calls from unrecognized phone numbers, such as from unknown device 210 associated with an unrecognized phone number.”; Col. 8, line 65-Col. 9, line 5 – “For example, the classification server 206 may receive information from the user devices 208 about the incoming call from the unrecognized phone number, such as time and date of the phone call, user interaction with the incoming phone call (e.g., ignored phone call, rejected phone call, sent to voicemail, etc.), the number of phone calls received from the unrecognized phone call within a time period, or the like.” The classification server obtains/identifies classification data associated with a specific phone number that was collected from a plurality of incoming calls received by the plurality of user devices 208. Thus, the plurality of incoming calls/interactions are related because they are all from a common unrecognized phone number.);
automatically verifying, by the at least one processor, at least one common session interaction parameter associated with the plurality of related incoming interaction sessions to identify the plurality of related incoming interaction sessions as being a plurality of suspect interaction sessions when, based on a database of known session interaction parameters, the at least one common session parameter is associated with at least one of a suspect entity, a suspect individual, or a suspect physical location (Col. 8, lines 28-38 – “The classification server 206 may query a data store, using the unrecognized phone number, to identify any classification data 124 associated with the unrecognized phone number. The term "classification data," as used herein, generally refers to any type of data that may be used to classify phone numbers associated with an incoming communication. For example, classification data may indicate whether an unrecognized phone number is associated with a spammer, a robocaller, has transmitted fraudulent messages, or is benign.” An unrecognized phone number (“common session parameter”) is automatically verified as being associated with a spammer or robocaller (“suspect entity” or “suspect individual”) by obtaining classification data for the phone number from a data store.);
receiving, by the at least one processor, new monitoring data from a particular computing device of the plurality of computing devices; wherein the new monitoring data comprises an indication of a new incoming interaction session (FIG. 3, steps 302 and 304; Col. 7, lines 37-44 – “at step 302 one or more of the systems described herein may receive a communication from an unrecognized phone number. The system may perform step 302 in any suitable manner. For example, the receiving module 104 may, as part of computing device 202 in FIG. 2, receive data associated with a communication (e.g., phone call or a message) through mobile application 122.”; Col. 8, lines 8-22 – ”At step 304, one or more systems described herein may obtain the unrecognized phone number from the communication. […] For example, the detection module 106 may process the received data to find any set of numbers and determine whether the numbers are a telephone number.”);
automatically determining, by the at least one processor, based on the new monitoring data that the new incoming interaction session has the at least one common session interaction parameter associated with the plurality of suspect interaction sessions (FIG. 8, steps 306 and 310; Col. 8, line 23-45 – “At step 306, one or more systems described herein may obtain classification data 124 using the unrecognized phone number. [… ] For example, classification data may indicate whether an unrecognized phone number is associated with a spammer, a robocaller, has transmitted fraudulent messages, or is benign. The classification data may be historical data that has been collected from many users of the system who have provided feedback with regards to the unrecognized phone number. In some examples, the classification data may be a collection of data obtained from analyzing communications that have been transmitted through the system, which may be identified based on the content of the message, originator of the message, or the like.”; Col. 10, lines 51-54 – “At step 310, one or more systems described herein may determine that the communication is an unsolicited communication based on the classification data and/or the category data.”) by:
inputting the at least one common session interaction parameter into (Col. 8, lines 23-31 – “At step 306, one or more systems described herein may obtain classification data 124 using the unrecognized phone number. The system may perform step 306 in any suitable manner. For example, the analysis module 108 may transmit the unrecognized phone number to a server, such as the classification server 206. The classification server 206 may query a data store, using the unrecognized phone number, to identify any classification data 124 associated with the unrecognized phone number.” Col. 8, lines 46-Col. 9, line 5 – “classification data 124, which may also be referred to as reputation data, for incoming calls from unrecognized phone numbers may be generated using data collected through one or more known crowdsourcing methodologies. Different types of data may be collected from user devices, such as user devices 208 A, 208B, and 208N (collectively referred to as 208). For example, the user devices 208B and 208N may receive incoming calls from unrecognized phone numbers, such as from unknown device 210 associated with an unrecognized phone number. […] For example, the classification server 206 may receive information from the user devices 208 about the incoming call from the unrecognized phone number, such as time and date of the phone call, user interaction with the incoming phone call (e.g., ignored phone call, rejected phone call, sent to voicemail, etc.), the number of phone calls received from the unrecognized phone call within a time period, or the like.” The analysis module 108 transmits the unrecognized phone number to the classification server 206 which queries a data store using the number (“inputs” the number to a data store) which identifies (“outputs”) classification data 124 for the number.
For clarity of the record, the Examiner would like to point to paragraph 35 of the specification of the instant application, which recites “the frequency metric may refer to a historical pattern associated with the plurality of suspect interaction sessions over the predetermined period of time”. The classification data 124 for an unrecognized phone number may be generated from data collected such as the number of calls received by user devices 208 from the unrecognized number within a time period (i.e., a “historical pattern associated with the plurality of suspect interaction sessions over the predetermined period of time”). Thus, the classification data generated may be considered a “frequency metric”.), and
identifying, based at least one risk threshold value determined from the at least one frequency metric, that the new incoming interaction session is a new suspect interaction session (Col. 10, lines 59-65 – “The analysis module 108 may use one or more rules to apply to the classification data 124 associated with the communication. For example, a user-specified rule may indicate that any communication that has reputation data over a predefined minimum (e.g., over 85% negative feedback in the classification data) may be categorized as unsolicited.” The analysis module may use a rule to apply to the classification/reputation data (“frequency metric”), where the rule may specify a threshold (“risk threshold value”) of the classification data to categorize an incoming call/interaction as unsolicited (“suspect”).);
(Col. 11, lines 35-43 – “At step 312, one or more systems described herein may, in response to determining that the communication is the unsolicited communication, perform a security action to manage interactions with the unsolicited communication received from the unrecognized phone number. The system may perform step 312 in any suitable manner. For example, the security module 110 may receive, from the analysis module 108, an indication that the communication is unsolicited.”; Col. 5, lines 14-18 – “one or more of the modules 102 may represent modules stored and configured to run on one or more computing devices, such as the devices illustrated in FIG. 2 (e.g., computing device 202, classification server 206, and/category server 212).” Any one or more of the modules 102 may be on any of the computing device 202 (“particular computing device”), the classification server 206 or category server 212. Thus, the embodiment where the analysis module 108 is on a server and transmits an indication that the communication is unsolicited to a security module 110 on the computing device 202 is taught.);
utilizing, by the at least one processor, based on the at least one interaction instruction, a suspect detection unit of the particular computing device to generate an interactive communication within the new incoming interaction session (Col. 11, lines 43-55 – “In response to receiving the indication that the communication is unsolicited, the security module 110 may perform one or more security actions. In one example, the security action may include presenting a recommendation to the user of the mobile application. The recommendation may suggest an advised action, such as ignoring the communication or adding the unrecognized phone number to a block list. In some embodiments, the recommendation may be presented as a push notification, as an overlay to the incoming message, or some other method of presenting the recommendation in conjunction with incoming communication from the unrecognized phone number through, for example, the mobile application 122.”; Col. 12, lines 20-22 – “In some examples, the system may present a warning to a user. The warning may include classification data 124 associated with the communication.” For clarity of the record, the indication from the analysis module 108 to security module 110 is interpreted as the “interaction instruction”, and the security action performed by the security module, which may be a warning related to the classification data of the unrecognized number, is interpreted as the generated “interactive communication”.)
receiving, by the at least one processor, from the particular computing device, a response to the interactive communication (Col. 11, lines 59-67 – “In some examples, the security module 110 may receive an indication to ignore or block the unrecognized number. In response to receiving the indication, the security module 110 may perform the action specified in the indication. In response to presenting the recommendation to block the unrecognized phone number, the security module 110 may receive an indication to add the unrecognized phone number to a block list”; Col. 12, lines 7-11 – “In some examples, the security module 110 may transmit the information associated with the communication from the now-blocked phone number to a repository on a remote server, such as category server 212, which may host a communication profile data store.”; Col. 12, lines 22-28 – “In response to presenting the warning, the security module 110 may receive additional classification data 124 to associate with the communication. The security module 110 may transmit the additional classification data to the classification server 206 to be added to the classification data associated with the phone number of the communication.” The security module 110 may receive an indication from the user (such as to block the unrecognized number) and/or additional classification data in response to presenting a recommendation/warning. The security module 110 may then transmit the information received to the classification server 206 (i.e., “receiving […] from the particular computing device”).); and
automatically updating, by the at least one processor, (Col. 12, lines 25-62 – “The security module 110 may transmit the additional classification data to the classification server 206 to be added to the classification data associated with the phone number of the communication. The security module 110 may transmit additional information, such as type of communication, date and time the communication was sent, and the like, to include with the additional classification data. FIG. 4 is a flow diagram of an example computer-implemented method 400 for collection additional information for identifying unsolicited communications on a computing device. […] at step 402, in response to determining a user has interacted with a communication from an unrecognized phone number, one or more of the systems described herein may display a request for classification data from the user. The system may perform step 402 in any suitable manner. […] detect if the caller has ended a phone call from the unrecognized phone number, if the caller selected an "ignore" button or "send to voicemail" button in response to receiving a phone call from the unrecognized phone number, performed an action to add the unrecognized phone number to a blocklist, or the like.”; Col. 13, lines 10-26 – “At step 406, one or more systems described herein may collect additional data associated with the communication. […] additional action taken in response to the communication ( e.g., adding the unrecognized phone number to a block list, selecting a link in a message to unsubscribe or remove from a caller list of the unrecognized phone number, etc.)”; Col. 13, lines 33-41 – “In some examples, the classification server 206 may use the classification data 124 and the additional data to update the classification data 124 for the unrecognized phone number. For example, if the classification data received from the user indicates that the communication was spam, the classification server 206 may update the classification data 124 associated with the unrecognized phone number to indicate that the unrecognized phone number is spam.” Col. 8, line 46-Col. 9, line 5 – data collected (classification data/additional data) and sent to the classification server may be inferred from user interaction (e.g., the response to the interactive communication) rather than direct collection of data from the user (i.e., it may be done “automatically”); Col. 8, lines 35-37 – “classification data may indicate whether an unrecognized phone number is associated with a spammer, a robocaller, has transmitted fraudulent messages”. As referenced previously, the classification data (“an association” of the unrecognized phone number with a robocall/spammer) is stored in a data store accessible by the classification server 206 (see Col. 8, lines 28-31), therefore updating the classification data for the unrecognized number would involve updating the association within the data store.).
Woirhaye fails to expressly teach obtaining, […] via each respective instance of at least one graphical user interface (GUI) having at least one programmable GUI element, a permission from each user in a plurality of users to monitor a plurality of activities executed within a plurality of computing devices associated with the plurality of users; and continually receiving the monitoring data in response to obtaining the permission from the plurality of users; inputting the at least one common session interaction parameter into at least one machine learning model that is trained to output at least one frequency metric associated with the plurality of suspect interaction sessions; utilizing […] a natural language processing algorithm, and automatically updating the association in real time.
However, Meredith teaches obtaining, […] via each respective instance of at least one graphical user interface (GUI) having at least one programmable GUI element, a permission from each user in a plurality of users to monitor a plurality of activities executed within of a plurality of computing devices associated with the plurality of users and receiving the monitoring data in response to obtaining the permission from the plurality of users ([0052] – “a telephone or mobile device owner can opt-in to a call challenge service, which can employ the use of call challenger 605. In example embodiments, the call challenger 605 can facilitate presentation of a web-page, or some other application interface, in which a user identity can input a selection to opt-in to the call challenge service (see, e.g., GUI show in FIG. 8). The selection can be stored as a data element in a database associated with the call challenger 605 (e.g., call challenger repository 650). During the opt-in process, the device owner can also be prompted to provide a keyword, which can be used to challenge callers directing calls at the mobile device or telephone of the owner.”; [0053] – “Still on FIG. 6, once keywords are retained ( e.g., in call challenger repository 650), and an incoming call directed to called party UE 220 is routed to the call challenger 605, the call challenger 605 first examines (or inspects) the call and determines if the owner of the number associated with the called device has opted-in for the call challenge functionality. In example embodiments, when an incoming call is routed through the call challenger 605, the call challenger 605 can inspect data associated with the call that indicates the destination of the call (e.g., the phone number of the destination device). The call challenger 605 can access the call challenger repository 650 to determine whether the phone number of the call destination matches a phone number of a device owner that has opted-in to the call challenge service.” Owners of mobile devices can opt-in (provide “permission”) to a call challenge service which intercepts, examines (“monitors”), and potentially blocks incoming calls (“activities”) to the mobile devices. Users can select to opt-in through an input to a GUI element on their mobile device.).
Woirhaye and Meredith are considered to be analogous art to the claimed invention because they are reasonably pertinent to the problem faced by the inventor in identifying suspect interaction sessions, and more specifically fraudulent phone calls. Therefore it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to modify the computer-implemented method taught by Woirhaye such that permission to monitor calls on a user device is obtained from users before collecting data related to the calls. The method taught by Woirhaye for identifying unsolicited calls includes determining the call is unsolicited based on the classification data associated with a phone number, and performing a security action such as blocking the unsolicited call (Woirhaye: Col. 1, line 55-Col. 2, line 19). Additionally, Woirhaye teaches the classification data may indicate the number making the unsolicited call is associated with a robocaller (Woirhaye: Col. 8, lines 32-38). Meredith teaches that not all robocalls may be fraudulent, as they may be used to make public service announcements, and therefore not every user may want to utilize a service that identifies and blocks robocalls (Meredith: [0037]); thus, obtaining permission from a user as taught by Meredith provides the benefit of giving users control over whether their incoming calls are monitoring and potentially blocked.
Woirhaye in view of Meredith fails to teach […] inputting the at least one common session interaction parameter into at least one machine learning model that is trained to output at least one frequency metric associated with the plurality of suspect interaction sessions; and utilizing […] a natural language processing algorithm, and automatically updating the association in real time.
However, HAZONY teaches utilizing […] a natural language processing algorithm ([0137] – “AU 315 may receive, e.g., from an AV system or a 3rd party unit, notifications related to a user and provide the notifications, possibly adding (or using) natural-language chat-bot explanations and/or training material, to the user. For example, as known in the art, an AV may generate a message that merely includes an error or warning number, such number may be translated or converted, by AU 315, to simple text and the simple text may be presented to the user.”; [0143] – “AU 315 may intervene in an interaction or communication based on information received for a user. For example, AU 315 may block an incoming email message or it may prevent a user from opening, or interacting with an incoming email message. For example, if AU 315 suspects that an incoming email message includes phishing objects (e.g., links, attachments or call for action requests), AU 315 may prevent opening or interacting with the message (e.g., prevent mouse clicks in the message body) and AU 315 may further present a message to the user, e.g., a message saying "This email message might include phishing objects, please do not interact with this message and report it to the CISO". Any guidance, suggestions or tips may be presented or provided to a user, by AU 315, in addition to blocking or preventing an interaction of a user with an application as described.” Assistant unit 315 uses a natural-language chat-bot to generate warnings or explanations about a suspicious incoming communication.
For clarity of the record, the Examiner would like to point to paragraph [20] of the specification, which teaches “the suspect interaction session may be a form of a vishing attack using a phone call, a voice mail message, or an email”; therefore, the interpretation of “suspect interaction session” is not limited to a phone call, and may be applicable to other forms of communication such as email messages.).
HAZONY is considered to be analogous art to the claimed invention because it is reasonably pertinent to the problem faced by the inventor in automatically identifying suspect interaction sessions. The method taught by Woirhaye for identifying unsolicited communications is not limited to phone calls, and may be used to identify unsolicited emails or other messages (Woirhaye: Col. 7, lines 55-63). Likewise, the teachings of HAZONY are not limited to emails, but are instead applicable to any form of correspondence, not limited to but including SMS messages and messages exchanged via an application (HAZONY: [0061]). Therefore, it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to have modified the teachings of Woirhaye such that the indication (“interaction instruction”) sent from the analysis module on a classification server to the security module on a particular user computing device of Woirhaye is generated by a natural language processing algorithm as taught by HAZONY. Using a natural language chat-bot allows for more effective, personalized warnings about phishing communications to individual users and avoids disturbing a user redundantly (HAZONY: [0120] and [0136]).
The combination of Woirhaye in view of Meredith and HAZONY fails to expressly teach inputting the at least one common session interaction parameter into at least one machine learning model that is trained to output at least one frequency metric associated with the plurality of suspect interaction sessions, and automatically updating the association in real time.
However, Botner teaches inputting the at least one common session interaction parameter into at least one machine learning model that is trained to output at least one frequency metric associated with the plurality of suspect interaction sessions (Col. 5, lines 27-49 – “The service 110 sends the INVITE packet, plus additional data to the active model or models 122-128 for scoring purpose. […] The additional information includes data, such as the number of calls the calling number has made in a recent time interval, such as the last six minutes and/or a one minute time interval. Each model receives the INVITE and additional data, then "scores" the incoming call and returns the numerical score along with a scam/spam flag (yes/no) depending on the score value.”; Col. 6, lines 17-23 – “Decisions are guided using machine learning methods, such as K-means clustering. K-means clustering is a machine learning technique used during the model trainer process to identify likely spoofing behavior.” Col. 13 lines 24-26 – “The call model, once completed, may be considered 'trained' and is then published to the call management system.”; Col. 14, lines 32-35 – “The SIP INVITE contains all of the information about the call. The call processing server and its corresponding models use the SIP INVITE in determining each calls' scam score.”; Col. 22, line 65-Col. 23, line 7 – “The one or more data messages include SIP INVITE data messages, and the plurality of call parameters may include, but are not limited to one or more of: a caller telephone number, a callee telephone number, an IP address of a caller device, an IP address of a callee device, an IP address of a device operating on the caller's network, an IP address of a device operating on the callee's network, an average call duration of calls associated with the callee telephone number, and other SIP specific parameters identified at least in FIG. 6A.”. The SIP INVITE data, which may contain a caller telephone number (“common session interaction parameter”), and additional data, such as the number of calls the calling number has made in a previous interval, is provided (“inputted”) to a trained model for the model to calculate and return (“output”) a scam score (“frequency metric”).
Again for clarity of the record, the Examiner would like to point to paragraph 35 of the specification of the instant application, which recites “the frequency metric may refer to a historical pattern associated with the plurality of suspect interaction sessions over the predetermined period of time”. Thus, since the scam score may be based on additional data, such as a number of calls made by the calling number over an interval, this scam score can be considered analogous to the claimed “frequency metric”.).
Botner is considered to be analogous art to the claimed invention because it is reasonably pertinent to the problem faced by the inventor in automatically identifying suspect interaction sessions. Therefore, it would have been obvious to one of ordinary skill in the art to have modified the teachings of Woirhaye in view of Meredith and HAZONY such that the common session interaction parameter is inputted into at least one machine learning model trained to output a frequency metric associated with the plurality of suspect interaction sessions as taught by Botner. Using one or more trained models that can analyze a plurality of call parameters allows for a real-time and adaptable method of identification of scam calls which is more accurate than just relying on the calling phone number alone (Botner: Col. 6, lines 24-41).
The combination of Woirhaye in view of Meredith, HAZONY, and Botner fails to expressly teach automatically updating the association in real time.
However, Weiss teaches automatically updating, in real time, within a database, an association of the at least one common session interaction parameter with at least one of the suspect entity, the suspect individual, or the suspect physical location based on a response received from the particular computing device (Col. 1, lines 48-49 – “Described is a processor-based automated phone fraud management system”; Col. 5, lines 1-4 – “The database 16 and possibly the data disk 19 include one or more lists of telephone numbers associated with or suspected of being used for attempting or having committed telephone fraud.”; Claim 25 – “providing, in a user interface via the application, alerts during the phone communications to a plurality, of users through the plurality of communication devices based on the comparison of the particular phone number to the at least one list and based on the suspected fraudulent intent during the ongoing phone communications, the alerts comprising an indication of a fraud risk corresponding to the particular phone number and an actuatable flagging mechanism, and the alerts provided during the phone communications as the phone communications are ongoing to the plurality of users; receiving via user actuation of the flagging mechanism a plurality of fraud suggestions corresponding to the particular phone number from the plurality of users; updating the at least one list based on the plurality of fraud suggestions; providing via the application a certain alert indicating a potential fraud during a particular phone communication as the particular phone communication is ongoing to a certain user through a certain communication device based on the comparison of the particular phone number to the updated at least one list and responsive to determining that the ongoing particular phone communication corresponds to the suspected fraudulent intent; interrupting the particular phone communication between the particular communication device and the certain communication device of the certain user while the particular phone communication is ongoing by a process comprising disabling audio of the particular phone communication via the application on the certain communication device based on the comparison of the particular phone number to the updated at least one list and responsive to determining that the ongoing particular phone communication corresponds to the suspected fraudulent intent; and re-enabling the particular phone communication responsive to a user input by the certain user via the certain communication device.”).
Weiss is considered to be analogous art to the claimed invention because it is reasonably pertinent to the problem faced by the inventor in automatically identifying suspect interaction sessions. Therefore, it would have been obvious to one of ordinary skill in the art to have modified the teachings of Woirhaye in view of Meredith, HAZONY and Botner, such that the association of the common session interaction parameter with at least one of the suspect entity, suspect individual, or the suspect physical location based on the response from the particular computer device is automatically updated within the database in real time, i.e., a the incoming interaction session is ongoing, as taught by Weiss. Doing so would improve security and protection of the user during an incoming call by allowing for an updated determination and indication of whether or not the call is fraudulent during the call based on user feedback to an initial determination as incorporated within the updated database, and by allowing for taking an action to mitigate risk (e.g., disconnecting the call) based on the updated determination incorporating the user feedback (see Col. 5, lines 19-23 and claim 25). In this manner, one of ordinary skill in the art would have combined the teachings of Woirhaye, Meredith, HAZONY, Botner, and Weiss to achieve the invention as recited in claim 1.
Regarding claim 2, the combination of Woirhaye in view of Meredith, HAZONY, Botner, and Weiss teaches the computer-implemented method of claim 1, wherein the at least one processor resides within at least one enterprise server (Woirhaye: Col. 5, lines 14-18 – “one or more of the modules 102 may represent modules stored and configured to run on one or more computing devices, such as the devices illustrated in FIG. 2 (e.g., computing device 202, classification server 206, and/or category server 212)”; Col. 6, lines 6-12 – “As will be described in greater detail below, one or more of the modules 102 from FIG. 1 may, when executed by at least one processor of the computing device 202, the classification server 206 and/or the category server 212, enable the computing device 202, the classification server 206, and/or the category server 212 to identify unsolicited communications on a computing device 202.”; Col. 14, lines 21-31 – “Although the systems and methods described herein are described in the context of end points (e.g., user devices), they may also be utilized and applied by different service providers in the phone service delivery ecosystem. For example, monitoring communications from unrecognized phone numbers may be provided by one or more phone service operators, such as mobile phone services or landline phone services. In some examples, the systems and methods described herein may be implemented and/or utilized by computing device manufacturers rather than or in conjunction with phone service operators.”).
Regarding claim 3, the combination of Woirhaye in view of Meredith, HAZONY, Botner, and Weiss teaches the computer-implemented method of claim 1, wherein determining the at least one risk threshold value comprises receiving preferences associated with at least one user from the plurality of users to determine the at least one risk threshold value (Woirhaye: Col. 10, lines 59-65 – “The analysis module 108 may use one or more rules to apply to the classification data 124 associated with the communication. For example, a user-specified rule may indicate that any communication that has reputation data over a predefined minimum (e.g., over 85% negative feedback in the classification data) may be categorized as unsolicited.” The user may specify rules indicating a threshold for which the generated classification data (“frequency metric”) is compared to.).
Regarding claim 5, the combination of Woirhaye, Meredith, HAZONY, Botner, and Weiss teaches the computer-implemented method of claim 1, wherein the at least one risk threshold value is a calculated average of interaction sessions for the plurality of users within the predetermined period of time (Woirhaye: Col. 8, line 46-Col. 9, line 5 – “In some examples, classification data 124, which may also be referred to as reputation data, for incoming calls from unrecognized phone numbers may be generated using data collected through one or more known crowdsourcing methodologies […] For example, the classification server 206 may receive information from the user devices 208 about the incoming call from the unrecognized phone number, such as time and date of the phone call, user interaction with the incoming phone call (e.g., ignored phone call, rejected phone call, sent to voicemail, etc.), the number of phone calls received from the unrecognized phone call within a time period, or the like.” The classification data (“frequency metric”) for an unrecognized phone number may be generated from data collected about incoming calls to user devices such as the number of calls received by user devices 208 from the unrecognized number within a time period. Col. 9, line 45-Col. 10, line 13 – “The classification server 206 may generate classification data 124 for the unrecognized phone number using the category data 126 associated with each of the identified user devices 208 and/or computing devices 202 contacted by the unrecognized phone number. […] The classification server 206 may take an average of the categories or confidence scores and use the average to generate classification data 124 to associated with the unrecognized phone number. For example, if all of the devices contacted by the unrecognized phone number are categorized as spam-prone, the unrecognized phone number may be classified as spam. If the unrecognized phone number contacted a threshold number of phone numbers categorized, for example, as spam-prone or fraud-prone, then the classification data 124 for the unrecognized phone number may be that it is spam or fraud. […] Based on ratio of the number of communications made by the unrecognized phone number to a certain category of phone numbers to overall number of communications, a confidence score may be calculated and maintained in relation to the likelihood that the unrecognized phone number is a certain type of caller.” The categories of the devices contacted by the unrecognized number within the time period may be averaged to generate classification data (the “frequency metric”) which is compared to a threshold to classify the unrecognized number as spam or benign.).
Regarding claim 6, the combination of Woirhaye, Meredith, HAZONY, Botner, and Weiss teaches the computer-implemented method of claim 1, wherein automatically updating the database of known session interaction parameters comprises inputting the at least one common session interaction parameter associated with the new incoming interaction session (Woirhaye: Col. 12, lines 25-32 – “The security module 110 may transmit the additional classification data to the classification server 206 to be added to the classification data associated with the phone number of the communication. The security module 110 may transmit additional information, such as type of communication, date and time the communication was sent, and the like, to include with the additional classification data.” The classification data store may be updated with more information about the unrecognized number associated with the new interaction session. Col. 13, lines 33-41 – “In some examples, the classification server 206 may use the classification data 124 and the additional data to update the classification data 124 for the unrecognized phone number. For example, if the classification data received from the user indicates that the communication was spam, the classification server 206 may update the classification data 124 associated with the unrecognized phone number to indicate that the unrecognized phone number is spam.” Automatically updating the classification data store involves updating the classification data stored for an unrecognized number to indicate the particular classification of the unrecognized number.).
Botner teaches inputting interaction session parameters associated with the new interaction session into a trained machine learning model (Col. 5, lines 29-45 – “Once a call model is created and distributed to certain servers, at the start of any particular call to a client end user device, the call processing platform service server 110 may receive a SIP INVITE packet 102, which is provided to the call management service to produce a scam score 104. The service 110 sends the INVITE packet, plus additional data to the active model or models 122-128 for scoring purposes.”).
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to have modified the step of updating the database storing known session parameters in which the data indicating the classification of a common interaction session parameter associated with a new interaction session is updated as taught by Woirhaye to include inputting the parameters associated with the new interaction session into a trained machine learning model to screen the new incoming session as taught by Botner. Using one or more trained models that can analyze a plurality of call parameters allows for a real-time and adaptable method of identification of scam calls which is more accurate than just relying on the calling phone number alone (Botner: Col. 6, lines 24-41).
Regarding claim 7, the combination of Woirhaye, Meredith, HAZONY, Botner and Weiss teaches the computer-implemented method of claim 1, further comprising utilizing a suspect detection unit module to automatically generate at least one new interactive communication based on the response to the interactive communication (Woirhaye: Col. 12, lines 44-56 – “As illustrated in FIG. 4, at step 402, in response to determining a user has interacted with a communication from an unrecognized phone number, one or more of the systems described herein may display a request for classification data from the user. The system may perform step 402 in any suitable manner. For example, the analysis module 108 may, as part of computing device 202 in FIG. 2, in response to determining the user has interacted with the communication from the unrecognized phone number, display a request for classification data 124 from the user. In some examples, the request may be a push notification, an overlay, or some other method of displaying the request to the user of the computing device 202.” As explained in the rejection of claim 1, the first interactive communication was, for example, a recommendation for responding, such as a recommendation to ignore the incoming call or to block the number. The user then interacts with the communication from the unrecognized number (by blocking, ignoring, answering, etc.), which is a response to the first interactive communication. Based on the user’s interaction, the system may generate a request for classification data (“at least one new interactive communication”).).
HAZONY teaches generating interactive communications using the natural language processing algorithm ([0137] – “AU 315 may receive, e.g., from an AV system or a 3rd party unit, notifications related to a user and provide the notifications, possibly adding (or using) natural-language chat-bot explanations and/or training material, to the user. For example, as known in the art, an AV may generate a message that merely includes an error or warning number, such number may be translated or converted, by AU 315, to simple text and the simple text may be presented to the user.” Assistant unit 315 uses a natural-language chat-bot to generate warnings or explanations and communicate with a user about a suspicious incoming communication.).
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to have modified the teachings of Woirhaye such that the interactive communications generated on user computing device of Woirhaye are generated by a natural language processing algorithm as taught by HAZONY. Using a natural language chat-bot allows for more effective, personalized warnings about phishing communications to individual users and avoids disturbing a user redundantly (HAZONY: [0120] and [0136]).
Claim 9 is a computer implemented method (Woirhaye: Col. 7, lines 26-32; Col. 6, lines 2-6; Col. 12, lines 33-34) comprising: the limitations recited in claims 1 and 7. Accordingly, claim 9 is rejected as being unpatentable over Woirhaye in view of Meredith, HAZONY, Botner, and Weiss for the same reasons as those presented with respect to claims 1 and 7 above.
Claims 10-11 and 13-14 recite substantially the same additional limitations as those recited in claims 2-3 and 5-6, respectively. Accordingly, claims 10-11 and 13-14 are rejected as being unpatentable over Woirhaye in view of Meredith, HAZONY, Botner, and Weiss for the same reasons as those presented with respect to claims 2-3 and 5-6 above.
Claim 16 is directed to a system (Woirhaye: FIG. 1, system 100) comprising:
a non-transient computer memory storing software instructions (Woirhaye: FIG. 1, memory 140, storing modules 102); and
at least one processor configured that, when executing the software instructions (Woirhaye: FIG. 1, physical processor 130; Col. 7, lines 26-32 – “FIG. 3 is a flow diagram of an example computer-implemented method 300 for identifying unsolicited communications on a computing device. The steps shown in FIG. 3 may be performed by any suitable computer-executable code and/or computing system, including system 100 in FIG. 1, system 200 in FIG. 2, and/or variations or combinations of one or more of the same.”; Col. 6, lines 2-12 – “In one example, all or a portion of the functionality of the modules 102 may be performed by the computing device 202, the classification server 206, the category server 212, and/or any other suitable computing system. As will be described in greater detail below, one or more of the modules 102 from FIG. 1 may, when executed by at least one processor of the computing device 202, the classification server 206 and/or the category server 212, enable the computing device 202, the classification server 206, and/or the category server 212 to identify unsolicited communications on a computing device 202”), is at least configured to: perform the method of claim 1. Accordingly, claim 16 is rejected as being unpatentable over Woirhaye in view of Meredith, HAZONY, Botner, and Weiss for the same reasons as those presented with respect to claim 1 above.
Claims 17-18 recite substantially the same additional limitations as those recited in claims 2-3, respectively. Accordingly, claims 17-18 are rejected as being unpatentable over Woirhaye in view of Meredith, HAZONY, Botner, and Weiss for the same reasons as those presented with respect to claims 2-3 above.
Claim 19 recites substantially the same additional limitations as those recited in claim 7. Accordingly, claim 19 is rejected as being unpatentable over Woirhaye in view of Meredith, HAZONY, Botner, and Weiss for the same reasons as those presented with respect to claim 7 above.
Claims 4 and 12 are rejected under 35 U.S.C. 103 as being unpatentable over Woirhaye in view of Meredith, HAZONY, Botner, and Weiss as applied to claims 1 and 9 above, and further in view of Joshi et al. (U.S. Pub. No. 2022/0141326), hereinafter Joshi.
Regarding claim 4, the combination of Woirhaye in view of Meredith, HAZONY, Botner, and Weiss teaches the computer-implemented method of claim 1, but fails to teach wherein the at least one common session interaction parameter is a session interaction protocol certificate.
However, Joshi teaches wherein the at least one common session interaction parameter is a session interaction protocol certificate ([0018] – “the client dialer application 119 may be configured to identify a phone number of an incoming caller device (e.g., third party device 106) to the client device 102, establish an out-of-band control channel, and request and receive, via the out-of-band control channel, a digital certificate 128 for the phone number from the incoming caller device. In some embodiments, the digital certificate 128 for the phone number may be issued by the certificate authority at the request of a telephone company that is issuing and registering the phone number. The digital certificate 128 for the phone number may include a digital signature or other authentication identifier, an issuing certification authority, and identifier information associated with the phone number.” When receiving an incoming call, a digital certificate corresponding to the phone number from which the call is originating may be transmitted to the receiving device.).
Joshi is considered to be analogous art to the claimed invention because it is reasonably pertinent to the problem faced by the inventor in identifying suspect interaction sessions, specifically identifying fraudulent incoming calls. Therefore, it would have been obvious to one of ordinary skill in the art to have modified the common interaction session parameter as taught by Woirhaye (a phone number), to be a session interaction protocol certificate as taught by Joshi. Joshi teaches these digital certificates can be issued by a certificate authority at the request of a telephone company when a phone number is registered to a person/entity, and can contain identifying information that may be presented to a user when receiving an incoming call (Joshi: [0018]). Using these certificates would improve security as they provide a way of verifying the identity of a caller that is more trustworthy than solely using the actual phone number, since they are updated when the owner of a registered phone number changes (Joshi: [0012]).
Claim 12 recites substantially the same additional limitations as those recited in claim 4. Accordingly, claim 12 is rejected as being unpatentable over Woirhaye in view of Meredith, HAZONY, Botner, and Weiss as applied to claim 9 above, and further in view of Joshi for the same reasons as those presented with respect to claim 4 above.
Claims 8, 15, and 20 are rejected under 35 U.S.C. 103 as being unpatentable over Woirhaye in view of Meredith, HAZONY, Botner, and Weiss as applied to claims 1, 9, and 16 above, and further in view of Guerra et al. (U.S. Pub. No. 2015/0055763), hereinafter Guerra.
Regarding claim 8, the combination of Woirhaye in view of Meredith, HAZONY, Botner, and Weiss teaches the computer-implemented method of claim 1, but fails to teach the method further comprising confirming, via at least one agent of a plurality of agents within a call center, that the new incoming interaction session has the at least one common session interaction parameter associated with the plurality of suspect interaction sessions.
However, Guerra teaches confirming, via at least one agent of a plurality of agents within a call center, that the new incoming interaction session has the at least one common session interaction parameter associated with the plurality of suspect interaction sessions ([0058] – “At 614, each group of call data may be utilized by the live agent to create a Fraud Behavioral Model (FBM) for each fraudster. The live agent may use the GUI module 308 to glean information from multiple calls (call data) made by a same fraudster to determine a FBM for said fraudster. […] the FBM of a fraudster may provide information about a mode of operation or a method being used by the fraudster to perpetrate fraud.”; [0061] – “the live agent may check [...] whether the fraudster X always called from a same phone number or from a same geographical location, and whether the fraudster X always called from a same type of telephony service (such as VoIP) or not. Based upon the set of parameters mentioned above, more information about the behavioral characteristics of the fraudster X may be determined, thereby revealing a FBM for the fraudster X. The FBM of the fraudsters may be used to detect fraud in future as explained below.”; [0069] – “when a new caller calls the call center 100, his/her name may be screened against the blacklist, his/her behavior model may be screened against the existing FBMs, and his/her method of transaction may be screened against the existing fraud patterns to determine whether the new caller is a fraudster. […] If any of the new callers has a similar behavioral model, their transactions may be put under suspect and investigated further. The similarity between the behavioral models of the new callers and the existing FBMs may be determined by the live agent, thereby making the FDS 102 more accurate and reliable.” A live agent of a call center develops a Fraud Behavioral Model (FBM) for a plurality of calls received from a particular fraudster, where the plurality of calls may share a common parameter, such as a phone number the fraudster used. The live agent then determines (“confirms”) the similarities between an FBM and a new incoming call.).
Guerra is considered to be analogous art to the claimed invention because it is reasonably pertinent to the problem faced by the inventors of identifying suspect interaction sessions, specifically identifying fraudulent phone calls. Therefore, it would have been obvious to one of ordinary skill in the art before the effective filing date of the method for identifying unsolicited calls as taught by Woirhaye to include the step of confirming the new incoming interaction session has at least one common session interaction parameter associated with the plurality of suspect interaction sessions via an agent of a call center as taught by Guerra. Confirming the similarities of a new call with a group of previously received calls from a known fraudster by a live agent at a call center can make a fraud detection system more accurate and reliable (Guerra: [0069]).
Claim 15 recites substantially the same additional limitations as those recited in claim 8. Accordingly, claim 15 is rejected as being unpatentable over Woirhaye in view of Meredith, HAZONY, Botner, and Weiss as applied to claim 9 above, and further in view of Guerra for the same reasons as those presented with respect to claim 8 above.
Claim 20 recites substantially the same additional limitations as those recited in claim 8. Accordingly, claim 20 is rejected as being unpatentable over Woirhaye in view of Meredith, HAZONY, Botner, and Weiss as applied to claim 16 above, and further in view of Guerra for the same reasons as those presented with respect to claim 8 above.
Response to Arguments
Applicant’s arguments, see pages 12-13 of the Remarks, filed 2/12/2026, with respect to the rejections of claims 1-20 under 35 U.S.C. 112(a) have been fully considered and are persuasive. The rejections of claims 1-20 under 35 U.S.C. 112(a) have been withdrawn.
Specifically, Applicant’s amendments filed 2/12/2026 to the claim limitations identified as not supported in the Specification clarify the limitations such that the Specification provides support for the amended limitations.
Conclusion
The prior art made of record and not relied upon is considered pertinent to applicant's disclosure.
Newman et al. (U.S. Patent No. 10,484,532) teaches a system for detecting fraudulent calls received from an incoming call network by a call service center involving a fraud training table comprising at least one entry comprising a characteristic of a fraudulent caller, and a machine learning model trained using the fraud training table, and applied to data associated with a call (see Abstract, claim 1).
PARK et al. (U.S. Pub. No. 2015/0156300) teaches a server performing an update operation of storing a sender phone number determined as a spam phone number in a spam database in real time (see [0129]-[0134]).
Wolinksy et al. (U.S. Patent No. 11,943,387) teaches a method for monitoring calls in which a database stores identifying parameters of calls, such as a telephone number, and compares data associated with a subscriber’s incoming call to the data in the database (see Abstract, Col. 4, line 45-Col. 5, line 5). The monitoring system further uses a combination of machine learning and natural language processing techniques to provide security for subscribers (see Col. 5, line 36-Col. 6, line 17 and Col. 8, lines 3-22).
Any inquiry concerning this communication or earlier communications from the examiner should be directed to JENNIFER MARIE GUTMAN whose telephone number is (703)756-1572. The examiner can normally be reached M-F: 8:00 am - 4:00 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, Kevin Young can be reached at 571-270-3180. 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.
/JENNIFER MARIE GUTMAN/Examiner, Art Unit 2194 /KEVIN L YOUNG/Supervisory Patent Examiner, Art Unit 2194
Prosecution Insights