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 the Applicant’s communication filed on 03/10/2026. Claims 1 – 20 are pending in this application.
In view of applicant’s amendment and arguments regarding rejection of claims 1 – 10, 12, 17 and 20 under 35 U.S.C. 112(a) and (b) or pre-AIA 35 U.S.C. 112, first and/or second paragraph, set forth in the previous Office Action, the rejection(s) is/are hereby withdrawn.
The applicant’s arguments have been considered but are moot in view of new ground(s) of rejections necessitated by the applicant’s amendment. For the Examiner’s response to still relevant arguments, please see section Response to Arguments below.
Response to Arguments
On pages 22 – 23 of the Remarks, while arguing rejection of dependent claims 9 and 19, and with respect to the Examiner assertion of official notice, the Applicant states the following:
“While APIs are generally known in the art, the Patent Office has not provided any
documentary evidence or articulated a sufficient rationale for why one of ordinary skill in
the art would have been motivated to utilize an API specifically to receive real-time call
data including a transcription of an audio recording of an incoming call in the context of
the claimed fraud detection system. The mere existence of APIs as a general technology does not establish that the specific application of an API to receive real-time call data for fraud detection purposes would have been obvious. See MPEP § 2144.03(B) (requiring that the technical line of reasoning underlying a decision to take official notice must be clear and unmistakable). Applicant respectfully requests that the Patent Office provide documentary evidence in support of this assertion in any subsequent Office Action. See MPEP § 2144.03(C).”
The Examiner’s response.
The rejection of the specific limitation regarding usage of “an Application Program Interface” consists of two parts:
assertion of an Official Notice that application program interface on its own was well known in the art at the effective filing date of the application as a connection between computers or between computer programs. It is a type of software interface, offering a service to other pieces of software. An application programming interface connects computers or pieces of software to each other. It allows two software systems to communicate across a boundary - an interface - using mutually agreed-upon signals. In other words, an API connects software entities together. However, the Examiner did not stop at this and provided a reference supporting this Official Notice: https://en.wikipedia.org/wiki/API.
A statement of obviousness with regards to usage of API, such as to transmit disclosed by the prior art transcript of the phone call between different components of the system, and doing so would have simply conformed to the industry standards and protocols.
Therefore, with respect to item a. above, it is not clear what other “documentary evidence in support of this assertion” is the Applicant requesting since the Examiner already provided source of the Official Notice. With respect to item b. above, the Examiner also provided sufficient motivation of usage of API to transmit information between different components of the system, regardless of the specific nature of the information being transmitted.
In view of the above, the Applicant’s argument is not found to be persuasive.
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.
Claims 5, 6, 16 and 22 are rejected 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 applications subject to pre-AIA 35 U.S.C. 112, the applicant), regards as the invention.
Claims 5 and 16 each recites the limitation "the caller" in line 4 of each claim. There is insufficient antecedent basis for this limitation in each of the claims.
Claim 22 recites the limitation "the caller data" twice. There is insufficient antecedent basis for this limitation in the claim.
Claim 6 is also rejected as being dependent from the rejected base claim.
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.
Claims 1 – 4, 7, 8, 10 – 15, 17, 18 and 20 – 22 are rejected under 35 U.S.C. 103 as being unpatentable over 11943387 (Wolinsky) in view of US 20240031475 (Shah).
Regarding claims 1, 10 and 20, Wolinsky teaches “A fraud and abuse detection system (shown in FIG 2 with corresponding description), the fraud and abuse detection system comprising:
one or more platform servers (various components included within fraud management system 201 in FIG 2) communicatively coupled to a caller device (a caller device 202 in FIG 2), a callee device (subscriber 203 in FIG 2), and a caregiver device (Col. 12 lines 64 – 67: (iii) instruct the call controller to merge a third party (e.g., a guardian, family member, caregiver, etc.) into the call 218. Therefore, “a caregiver device” is at least implicitly present in the system “communicatively coupled” to the fraud management system 201), wherein the callee device includes a carrier bridge configured to communicatively couple the callee device to the one or more platform servers via a network (Col. 12 lines 23 – 32: the subscriber's telephone may be configured as an address communicating 221 to a PBX (private branch exchange) telephone system 220. The PBX 220 may operate as a component of a SIP communications network or such other configurations as is known in the art. The subscriber's calling 225, both inbound and outbound, may be routed through the call controller, thereby permitting the telephone fraud-call monitoring interdiction system 201 to operate on the subscriber's inbound and outbound calls. What this means is that the subscriber device 203 has a piece of hardware or software (“a carrier bridge”) that is capable of connecting the subscriber device 203 to PBX, call controller 209 and the rest of the system (“the one or more platform servers via a network”, where “a network” is shown as at least lines 225 and 221 in FIG 2)), the carrier bridge configured to route call data from a carrier's network to the one or more platform servers in a digital format (Col. 12 lines 23 – 32: the subscriber's calling 225, both inbound and outbound, may be routed through the call controller, thereby permitting the telephone fraud-call monitoring interdiction system 201 to operate on the subscriber's inbound and outbound calls. This means that “call data from a carrier's network to the one or more platform servers” is routed by means of the disclosed arrangement. Although Wolinsky does not explicitly disclose that it is done “in a digital format”, it is either implicit, as it would normally be done at the time Wolinsky’s application was filed (May 2022), especially in view of the subscriber device 203 shown as smartphone in FIG 2, or it would have been obvious to a person of ordinary skill in the art at the effective filing date of the application to utilize digital format, rather than analog format, to implement Wolinsky’s functionality. Doing so would have conformed to the modern digital communication technology rather than being done according to the analog technology of yesteryear), the one or more platform servers including one or more processors configured to execute a set of program instructions stored in a memory (see col. 44 lines 1 – 30), the one or more platform servers including a sentiment analysis module stored in the memory (Col. 12 lines 59 – 63: The call treatment engine 212 may evaluate in real time the conversation of the parties for fraud related threats that may include as shown (i) applying various conversation sentiment and voice and speech analysis technologies 216. Col. 13 lines 44 – 47: Neural network and AI activities may be configured to perform caller sentiment analyses. Col. 44 lines 1 – 2: When implemented in software, the functions may be stored as one or more instructions), the one or more platform servers including a circuit breaker module stored in the memory (Col. 39, lines 55 – 61: automatically disconnecting the call between the caller and recipient in response to the call managing system determining that information of either the caller or recipient is stored in a “bad” caller database. Col. 42 lines 47 – 56. Col. 44 lines 1 – 2: When implemented in software, the functions may be stored as one or more instructions), the set of program instructions configured to cause the one or more processors to:
analyze an incoming call in near real-time using the sentiment analysis module (Col. 12 lines 59 – 63: The call treatment engine 212 may evaluate in real time the conversation of the parties for fraud related threats that may include as shown (i) applying various conversation sentiment and voice and speech analysis technologies 216. Col. 13 lines 44 – 47: Neural network and AI activities may be configured to perform caller sentiment analyses.)…”
“…generate a confidence risk score in near real-time based on the sentiment analysis of the incoming call, wherein the confidence risk score corresponds to a likelihood of fraud or abuse based on sentiment analysis data from the sentiment analysis module (Col. 12 line 59 – col. 13 line 2: The call treatment engine 212 may evaluate in real time the conversation of the parties for fraud related threats that may include as shown (i) applying various conversation sentiment and voice and speech analysis technologies 216, … (iv) apply other technologies and services as can be used or developed to analyze the nature of a call 219, and (v) rank the call for monitoring system responses. Col. 17 lines 2 – 7: the monitoring system may use an AI cognition system 401b to assess and compute the probabilities and indexing (ranking) of fraud-call conversation threats from an unknown caller or party. Col. 17 lines 15 – 16: The monitoring system, based on rules, may rank the conversation as a “safe” or “unsafe” call 402b. Col. 17 lines 64 – 67: a telephone fraud-call monitoring system to generate and rank in real time the threat level of conversations between an unknown caller, or party, and a subscriber of the monitoring system. Col. 18 lines 17 – 62 disclose multiple tier ranking system with the highest tier 4 representing the highest “likelihood of fraud or abuse” and the lowest tier 0 representing the lowest “likelihood of fraud or abuse”. Thus, each tier represents “a confidence risk score” and it is determined by means of applying various conversation sentiment and voice and speech analysis technologies 216 (output of which representing “sentiment analysis data”) and thus “based on the sentiment analysis of the incoming call”); and
perform one or more actions using the circuit breaker module based on a determined confidence risk score (Col. 15 lines 20 – 23: The AI cognition system may employ a rules-based ranking engine 407 that may rank the unknown party's conversation for responsive monitoring system actions, for example, terminate the call 409 (“perform one or more actions using the circuit breaker module” which is based on assigned rank, where the rank corresponds to “a determined confidence risk score”)), wherein the one or more actions include one or more risk threshold tier actions corresponding to a respective confidence risk score (Col. 21 lines 35 – 41: In the event of a “0” threat tier (“a respective confidence risk score” being 0) determination or ranking 638 assigned to the conversation, the AI engine 604 may communicate instructions to network gateway 602 to turn off or terminate the call leg 620 to the AI/ML engine 604 and cease monitoring the in-progress call 639. Col. 21 lines 1 – 27: in the event of a threat tier determination or ranking 629, such as 1 or 2 assigned to the conversation (“a respective confidence risk score” being 1 or 2), the AI/ML engine 604 may communicate 630 to the network gateway 602 instructions to open a call leg to the security call center 605, whereby a security agent 631 may be merged with the call in-progress, or added to the conference bridge. Col. 20 lines 49 – 67: In the event a threat tier determination or ranking 624, such as of 3 or 4 assigned to the conversation (“a respective confidence risk score” being 3 or 4), the AI/ML engine 604 may communicate a “terminate call” notification 625 to the network gateway 602 which terminates the call 627. The AI/ML engine servers 604 may communicate a call cancellation notification to the subscriber 603 and any third parties 606 sanctioned by the subscriber 603 to receive such notices. The describe actions represent “one or more risk threshold tier actions corresponding to a respective confidence risk score”).”
Wolinsky does not disclose that “the sentiment analysis module including one or more sentiment analysis models configured to analyze a sentiment of a callee's voice.”
In similar art, Shah also teaches “A fraud and abuse detection system (FIG 1 – 6 with corresponding description)” comprising a similar structure including “a caller device (shown as 110 in FIG 1), a callee device (customer device 130 in FIG 1), and a caregiver device (paragraph 0024: The call manager 140 can contact the user via a user device 150. Paragraph 0023: The call manager 140 can contact or organize contact with a user. The user can be a medical professional (“a caregiver”). Therefore, the user device 150 corresponds to “a caregiver device”)”.
However, Shah also teaches “analyze an incoming call in near real-time using the sentiment analysis module, the sentiment analysis module including one or more sentiment analysis models configured to analyze a sentiment of a callee's voice (paragraph 0035: The analysis component 230 includes a conversation component 310 that can perform a conversation analysis by analyzing an ongoing conversation or ongoing/incoming call between the customer 120 and the spam caller 110 on the spam risk call. The conversation component 310 can analyze the voice of the customer 120 for signs of distress (“analyze a sentiment of a callee's voice”). The conversation component 310 can analyze the conversation to determine sentiment. The conversation component 310 can determine a distress sentiment based on the sentiment analysis for the customer 120. Paragraph 0019: The conversation model (“sentiment analysis models”) can analyze conversations in real time or near real time.)…”
In other words, Shah teaches “one or more sentiment analysis models” “to analyze a sentiment of a callee’s voice.”
Therefore, since Wolinsky does not provide sufficient details of sentiment analysis in the operation of the system, it would have been obvious to a person of ordinary skill in the art at the effective filing date of the application to utilize disclosed by Shah sentiment analysis model(s) to analyze a sentiment of a callee’s voice, in the system of Wolinsky simply to fill in the details missing from Wolinsky and since, according to the Supreme Court, “[t]he combination of familiar elements according to known methods is likely to be obvious when it does no more than yield predictable results.” KSR Int’l Co. v. Teleflex, Inc., 550 U.S. 398, 416 (2007).
Regarding claims 2 and 13, Wolinsky in combination with Shah teaches or fairly suggests “wherein the one or more risk threshold tier actions comprise: disconnect the incoming call in near real-time (Wolinsky, col. 20 lines 49 – 67: In the event a threat tier determination of 3 or 4 assigned to the conversation, the AI/ML engine 604 may communicate a “terminate call” notification 625 to the network gateway 602 which terminates the call 627. The AI/ML engine servers 604 may communicate a call cancellation notification to the subscriber 603 and any third parties 606 sanctioned by the subscriber 603 to receive such notices. Shah, paragraph 0039: The implementation component 420 can implement further security controls onto the spam risk call. The security controls can automatically cause a forced disconnect of the spam risk call), wherein the set of program instructions are further configured to cause the one or more processors to generate one or more control signals configured to cause the carrier bridge of the callee user device to disconnect the incoming call in near real-time (in Wolinsky, the termination of the call is performed by the network gateway 602. In Shah, the implementation component 420 forcing the termination of the call is part of the “callee device” 130 in FIG 1 and thus may be mapped to be a part of “the carrier bridge of the callee user device”. Additionally, the “one or more control signals” must have been generated for the action to take place. It would have been obvious to a person of ordinary skill in the art at the effective filing date of the application to further optionally incorporate disclosed by Shah functionality of disconnecting the call at the callee’s device itself simply as design choice with predictable results since, according to the Supreme Court, “[t]he combination of familiar elements according to known methods is likely to be obvious when it does no more than yield predictable results.” KSR Int’l Co. v. Teleflex, Inc., 550 U.S. 398, 416 (2007).).”
Regarding claims 3 and 14, Wolinsky in combination with Shah teaches or fairly suggests “wherein the one or more risk threshold tier actions comprise: generating one or more alerts, wherein the set of program instructions are further configured to cause the one or more processors to generate one or more control signals configured to cause one of a callee user device or a guardian user device to generate the one or more alerts in near real-time during the incoming call, wherein the generated one or more alerts include one of a visual alert or an auditory alert (Wolinsky, col. 7 lines 24 – 33: the monitoring system and threat tier responses may be configured to automatically send alerts of a fraud stop action or other actions to subscribers via emails, text messages, apps, and the like, while adult children, caregivers may be notified according to the specifications of the subscriber or authorized guardian. Third parties, such as adult children, caregivers and financial parties who may have subscribed an at-risk senior to the monitoring network may also receive the monitoring system's notifications. Using emails, text messages, apps involves including “one of a visual alert or an auditory alert.” In Shah, this is shown in FIG 1 as visual indication of “spam risk” on the user’s device (“a callee user device”). Paragraph 0024: The call manager 140 can generate and send a notification to the user device 150 (“a guardian user device”), implement a call to the user device 150, and/or the like. For example, the call manager 140 can send an SMS text message to the user device 150. The notification can include instructions for the user to contact the customer 120. The call manager 140 can pause or hold the spam risk call and place a call to the user device 150. Also paragraphs 0034 and 0039; all this represents “generate the one or more alerts in near real-time during the incoming call, wherein the generated one or more alerts include one of a visual alert or an auditory alert”).”
Regarding claims 4 and 15, Wolinsky in combination with Shah teaches or fairly suggests “wherein the one or more risk threshold tier actions are received from one of a callee or a guardian (“the one or more risk threshold tier actions” are disclosed by Wolinsky as explained in the rejection of claim 1 above. Col. 12 lines 64 – 66: (iii) instruct the call controller to merge a third party (e.g., an authorized security agent, guardian, family member, caregiver, etc.) into the call 218. Plurality of actions are also disclosed by Shah in paragraph 0039 and include notification to the user device 150 with instructions for the user (“a guardian”) to contact the customer 120. They also include automatically teleconferencing the user (“a guardian”) to join the user (“a callee”) to the spam risk call. For example, the implementation component 420 can connect the user via the user device 150 (“a guardian”) to the customer device 130 (“a callee”) such that the user (“a guardian”) joins the spam risk call and provide assistance to the customer 120 (“a callee”). Thus, in Wolinsky and in Shah, “the one or more … actions are received from one of … a guardian”, such as contacting and/or joining the customer/subscriber receiving the fraudulent phone call.).”
Regarding claims 7 and 17, Wolinsky teaches or fairly suggests “wherein the set of program instructions are further configured to cause the one or more processors to: store an evidence dossier in the memory, wherein the evidence dossier includes one of call data, a recording of the incoming call (Col. 13 lines 30 – 33: a partial recording of the call that gave rise to the system attempting to add the third party may be stored in association with the information of the non-subscriber caller.), the performed one or more actions of the circuit breaker module, the determined confidence risk score, or the sentiment analysis data analyzed (Since the claim is written in the alternative form (“one of A, B, C, D or E”), it is sufficient to meet at least one of the limitations “A” or “B” or “C” or “D” or “E” in the claim. In this case the limitations “B” (“a recording of the incoming call”) is met.).”
Regarding claims 8 and 18, Wolinsky and Shah teach or fairly suggest “wherein the one or more platform servers include a caller database stored in the memory, the caller database including one of an allowed caller database or a blocked caller database (Wolinsky, col. 4 lines 51 – 59: the caller's telephone call information, which may include headers, metadata and other routing and identifying indicia, may be analyzed to determine if the call is a known “good” or “bad” telephone number stored in a database of the system. The “good” and “bad” telephone numbers may be organized and stored as “whitelisted” and “backlisted” telephone numbers. Shah, paragraph 0020: the call manager 140 can detect a spam call risk via determining the call source and compare the call source to a list of blocklist sources (“a caller database” “the caller database including one of … a blocked caller database”) of known spam callers or spam call originators. The call manager 140 can classify the call as a spam risk call upon determining a match of the call source and a listing of the blocklist sources.).”
Regarding claim 11, Wolinsky and Shah both teach “wherein the one or more user devices further comprise: one or more guardian user devices communicatively coupled to the one or more platform servers (Wolinsky, Col. 12 lines 64 – 67: (iii) instruct the call controller to merge a third party (e.g., a guardian, family member, caregiver, etc.) into the call 218. Therefore, “one or more guardian user devices” is at least implicitly present in the system and “communicatively coupled to the one or more platform servers.” Additionally, Shah, paragraph 0024: The call manager 140 (“the one or more platform servers”) can contact the user via a user device 150. The user device 150 can be a mobile phone. Therefore, the call manager 140 is “communicatively coupled” to the user device 150. Paragraph 0023: The call manager 140 can contact or organize contact with a user. The user can be a medical professional (“guardian”). Therefore, the user device 150 corresponds to “one or more guardian user devices”).”
Regarding claim 12, Wolinsky in combination with Shah teach or fairly suggest “provide the sentiment analysis data…” “…to one or more guardian user devices associated with one or more guardians (Wolinsky, Col. 12 lines 64 – 67: (iii) instruct the call controller to merge a third party (e.g., a guardian, family member, caregiver, etc.) into the call 218. Shan, paragraph 0024: The call manager 140 can generate and send a notification to the user device 150 (“one or more guardian user devices associated with one or more guardians”), implement a call to the user device 150. The notification can include instructions for the user to contact the customer 120. The call manager 140 can pause or hold the spam risk call and place a call to the user device 150. The fact that the guardian’s device in Wolinsky, and/or the user device 150 in Shah is being contacted at least implicitly means that the sentiment analysis resulted in such “sentiment analysis data” as determination that the incoming phone call is fraudulent/spam. Shah, paragraph 0039: The notification reveals the sign(s) of distress of the customer 120.).”
Wolinsky and Shah do not teach that “the determined confidence risk score” is also provided to the guardian device. However, determination of the “confidence risk score” is disclosed by Wolinsky as a threat tier, as explained in the rejection of claim 1 above. Since the result of the sentiment analysis in the system of Wolinsky and Shah is provided to the guardian device, it would have been obvious to a person of ordinary skill in the art at the effective filing date of the application to provide this determined “confidence risk score” (threat tier) to the guardian device as well simply as design choice with predictable results, the results being providing additional information to the guardian that would be helpful in making an informed decision on how to proceed with the help to the user receiving the call.
Regarding claim 21, Wolinsky teaches “wherein the carrier bridge comprises a...” “…network device of a network carrier configured to route the call data from the network carrier's network to the one or more platform servers in the digital format (Col. 12 lines 23 – 32: the subscriber's telephone may be configured as an address communicating 221 to a PBX telephone system 220. The PBX 220 may operate as a component of a SIP communications network or such other configurations as is known in the art. The subscriber's calling 225, both inbound and outbound, may be routed through the call controller, thereby permitting the telephone fraud-call monitoring interdiction system 201 to operate on the subscriber's inbound and outbound calls. What this means is that the subscriber device 203 has a piece of hardware or software (“the carrier bridge comprises a...” “…network device of a network carrier”) that is capable of connecting the subscriber device 203 to PBX, call controller 209 and the rest of the system (“to route the call data from the network carrier's network to the one or more platform servers”). Although Wolinsky does not explicitly disclose that it is done “in a digital format”, it is either implicit, as it would normally be done at the time Wolinsky’s application was filed (May 2022), especially in view of the subscriber device 203 shown as smartphone in FIG 2, or it would have been obvious to a person of ordinary skill in the art at the effective filing date of the application to utilize digital format, rather than analog format, to implement Wolinsky’s functionality. Doing so would have conformed to the modern digital communication technology rather than being done according to the analog technology of yesteryear).”
Wolinsky does not teach that the network device is “a third party” network device.
However, neither claim nor the specification define what “a third party” may mean; nor do the claims and specification define what would be a first and second parties in this case. Therefore, this is interpreted according to the broadest reasonable interpretation. For example, if a first party is a caller and a second party is callee, “a third party” may, for example, simply be a manufacturer of the callee’s device or a manufacturer of the specific part of hardware within the device responsible for this function, which is implicit. Therefore, the claim is met.
Regarding claim 22, Wolinsky teaches “wherein the one or more platform servers are configured to receive the caller data…” “…wherein the caller data includes a recording of the incoming call (col. 11 lines 32 – 40: the proxy server/gateway 207 may be configured to: … (6) communicate 213 and open call legs to analytical technologies and call intervention services 210, which may include speech-to-text processing, voice recording and voice biometric analysis. Here, analytical technologies and call intervention services 210 represent claimed “the one or more platform servers” and their reception of voice recording and voice biometric analysis represent claimed “configured to receive the caller data…” “…wherein the caller data includes a recording of the incoming call”. Col. 27 lines 51 – 55: the monitoring system may perform a multi-step call scrutinizing analysis of the inbound or outbound calls, including conversation analysis which may include recording the conversation of both parties, in order to ascertain the safety of a call at step 1502. Here, the monitoring system represents claimed “the one or more platform servers” and its reception of recording the conversation of both parties represents claimed “configured to receive the caller data…” “…wherein the caller data includes a recording of the incoming call”. Col. 42 lines 57 – 63: Metadata and/or call content (“the caller data…” “…wherein the caller data includes a recording of the incoming call”) may be stored in a data repository in a data record (here, a data repository represent “the one or more platform servers” and their reception of the data represent “configured to receive the caller data”) in response to determining that the respective calling party or called party causes a non-zero threat level to be determined, thereby enabling the stored data to be accessed during future calls inclusive of the calling party or called party.) or metadata of the incoming call.”
Wolinsky does not teach that the reception of the caller data is performed “from an Application Program Interface”. However, the Examiner takes an Official Notice that “an Application Programming Interface” was well known in the industry at the effective filing date of the application as a connection between computers or between computer programs. It is a type of software interface, offering a service to other pieces of software. An application programming interface connects computers or pieces of software to each other. It allows two software systems to communicate across a boundary - an interface - using mutually agreed-upon signals. In other words, an API connects software entities together. (see https://en.wikipedia.org/wiki/API).
Therefore, it would have been obvious to a person of ordinary skill in the art at the effective filing date of the application to utilize well known in the industry and widely used application programming interface, in the system of Wolinsky, and receive disclosed by Wolinsky caller data including a recording of the incoming call, “from an Application Program Interface”. Doing so would have simply conformed to the industry standards and protocols and allowed multiple software systems to communicate across a boundary - an interface - using mutually agreed-upon signals.
Claims 5, 6 and 16 are rejected under 35 U.S.C. 103 as being unpatentable over 11943387 (Wolinsky) in view of US 20240031475 (Shah) as applied to claims 1 and 10 above, and further in view of US 10616411 (Chang).
Regarding claims 5 and 16, Wolinsky does not teach “direct the incoming call in near real-time to a screening module prior to connecting the caller to a callee; and perform an initial screening of the incoming call using the screening module, wherein a screening agent of the screening module is configured to gather screening data from a caller of the incoming call.”
Chang teaches a similar system of monitoring incoming call data generated during an incoming call between a user and an incoming caller, detect a fraud trigger within the incoming call data, and complete a fraud interception activity in response to detection of the fraud trigger (see abstract). Particularly, as disclosed in col. 9 line 64 – col. 10 line 4, an incoming call to the user mobile device 110 or the user landline phone 118 is intercepted at 202 by the fraud analysis computing system 130. The call interception is accomplished when the call intercept client application 116 or the call intercept hardware device 120 routes the incoming call to the fraud analysis computing system 130 via the network 170. Col. 10 lines 40 – 58: the method 200 proceeds to picking up the incoming call and conversing with the incoming caller at 210 performed by the fraud conversation processing circuit 136 (“direct the incoming call in near real-time to a screening module prior to connecting the caller to a callee”). As described above with reference to FIG. 1, the conversation may occur between the incoming caller and an artificial intelligence entity or a live person (“a screening module”). At the conclusion of the conversation, the artificial intelligence entity or the live person assigns a trust metric, score, or percentage to the incoming caller. If the metric assigned to the incoming caller exceeds a certain specified threshold, the fraud analysis computing system 130 completes a fraud interception activity at 214 which might include routing the incoming call to a “number disconnected” message. As further explained in col. 6 line 66 – col. 6 line 19, the fraud conversation processing circuit 136 is configured to converse with an incoming caller to determine whether the caller has a fraudulent intent (“to gather screening data from a caller of the incoming call”). An artificial intelligence entity is utilized to converse with the incoming caller. Alternatively, a live person engages in conversation with the caller. At the conclusion of the conversation, the artificial intelligence entity or the live person quantifies the likelihood that the incoming caller is fraudulent via a trust score, percentage, or some other metric. For example, the metric may be based on whether the incoming caller exhibits signs of nervousness or fright, whether the incoming caller's voiceprint matches a voiceprint stored in the fraud analysis computing system 130, or whether the incoming caller speaks a certain keyword or phrase (all of this representing “screening data from a caller of the incoming call”).
Therefore, it would have been obvious to a person of ordinary skill in the art at the effective filing date of the application to utilize disclosed by Chang screening module to collect initial data from the incoming phone call prior to connecting the call to the intended recipient, in the system of Wolinsky. Doing so would have allowed to perform initial assessment of the caller’s intention prior to connecting the phone call to the intended recipient thus increasing the functionality of the system in intercepting fraudulent calls.
Regarding claim 6, Wolinsky in combination with Shah teach or fairly suggest “provide the sentiment analysis data…” “…to one or more guardian user devices associated with one or more guardians (Wolinsky, Col. 12 lines 64 – 67: (iii) instruct the call controller to merge a third party (e.g., a guardian, family member, caregiver, etc.) into the call 218. Shan, paragraph 0024: The call manager 140 can generate and send a notification to the user device 150 (“one or more guardian user devices associated with one or more guardians”), implement a call to the user device 150, and/or the like. The notification can include instructions for the user to contact the customer 120. The call manager 140 can pause or hold the spam risk call and place a call to the user device 150. The fact that the guardian’s device in Wolinsky, and/or the user device 150 in Shah is being contacted at least implicitly means that the sentiment analysis resulted in such “sentiment analysis data” as determination that the incoming phone call is fraudulent/spam. Shah, paragraph 0039: The notification reveals the sign(s) of distress of the customer 120.).”
Wolinsky and Shah do not teach that “the determined confidence risk score” is also provided to the guardian device. However, determination of the “confidence risk score” is disclosed by Wolinsky as a threat tier, as explained in the rejection of claim 1 above. Since the result of the sentiment analysis in the system of Wolinsky and Shah is provided to the guardian device, it would have been obvious to a person of ordinary skill in the art at the effective filing date of the application to provide this determined “confidence risk score” (threat tier) to the guardian device as well simply as design choice with predictable results, the results being providing additional information to the guardian that would be helpful in making an informed decision on how to proceed with the help to the user receiving the call.
Wolinsky and Shah do not teach that “the screening data” is also provided to the guardian device.
Chang teaches collecting screening data from the caller of the incoming call and making a determination of the likelihood that the incoming caller is fraudulent, as explained in the rejection of parent claim 5 above. In the rejection of claim 5 above, examples of “screening data” were mapped to the conversation to determine if the caller has a fraudulent intent and/or matching a voiceprint stored in the fraud analysis system and/or speaking a certain keyword or phrase. Further, Chang in col. 7 line 66 – col. 8 line 12 teaches that a caregiver may wish to be informed (e.g., via text message, push notification, mobile application dashboard message, phone call) each time a fraud trigger is detected in an incoming call. In other words, the caregiver is provided with the result of determination of the fraudulent intent of the incoming call. Col. 10 lines 34 – 37: informing a caregiver and requiring the caregiver to provide approval before the incoming call passes to the next fraud check.
In Chang, this determination is based on the collected “screening data” from the caller of the incoming call.
However, it would have also been obvious to a person of ordinary skill in the art at the effective filing date of the application to provide, to the caregiver/guardian’s device in the system of combined Wolinsky, Shah and Chang’s disclosures, not only disclosed by Chang results of the screening analysis of the incoming phone call (such as determination of the fraudulent intent of the incoming call), but also “the screening data” used to make such determination simply as design choice with predictable results with such expected benefit as provided additional information to the guardian that would be helpful in making an informed decision on how to proceed with the help to the user that had received the call.
Claims 9 and 19 are rejected under 35 U.S.C. 103 as being unpatentable over 11943387 (Wolinsky) in view of US 20240031475 (Shah) as applied to claims 1 and 10 above, and further in view of US 10455085 (Roundy).
Regarding claims 9 and 19, Wolinsky teaches “receive real-time call data…” “…wherein the real-time call data includes a transcription of an audio recording of the incoming call (Col. 29 line 24 – col. 30 line 2 and FIG 17: a screen shot of an illustrative user interface dashboard 1700 that may be used by a security agent of a telephone fraud management system provider is shown. The features of the dashboard shown may be configured to provide: … (3) an interactive viewable area 1705 where a call transcript of the conversation in progress between the parties may be displayed and an AI threat detection engine may dynamically identify and optionally highlight 1706 any potentially unsafe or threat words and/or phrases spoken or responded to by either party of the conversation. A full transcription of the call (along with real-time updates to the call transcript) may be captured and displayed, but the display may automatically actually display only portions of the transcript that include the highlighted words identified by the AI threat detection engine and hide with selectable features to unhide transcription text outside of the highlighted portion, where the hidden portions of the text may be based on context, time, distance, or any other AI determined or non-AI determined parameter. Col. 41 lines 44 – 49: Audio signals inclusive of the conversation may be transcribed to generate a transcript of the conversation between the first and second persons. The transcription may be processed in real time to determine whether a fraud is being perpetrated on the first person by the second person.)…”
Wolinsky does not teach “wherein the one or more sentiment analysis models of the sentiment analysis module are configured to analyze the transcription of the audio recording of the incoming call in near real-time.”
Roundy also teaches systems and methods for real-time scam protection on phones (see title). Particularly, Roundy in col. 4 lines 35 – 38 teaches that system 100 may include scam analyzer module 108 that analyzes transcripts of the text which was converted from speech during a call in order to determine whether the caller is attempting to execute a scam. Col. 7 lines 24 – 28: voice to text converter 106 may convert the spoken audio of caller 320 and call recipient 330 into a transcript in text format. Also col. 7 lines 34 – 35 and col. 8 lines 5 – 35: scam analyzer 108 may analyze the transcripts of the call using natural language processing to determine the sentiments and/or emotions of the caller 320 and/or call recipient 330. Scam analyzer 108 may use a trained model to compare the text transcripts of the conversation to the keywords 308 and phrases associated with emotions and sentiments commonly experienced during scam calls. Scam analyzer 108 may detect sentiments of distress, intimidation, fear, terror, and/or anger to determine whether a call is a scam. All this is performed in real time.
Therefore, it would have been obvious to a person of ordinary skill in the art at the effective filing date of the application to utilize disclosed by Roundy sentiment analysis of the call transcript, in the system of Wolinsky. Doing so would have allowed to perform sentiment analysis of the call transcript in addition to the analyses of the transcript disclosed by Wolinsky thus improving reliability of determination whether the call is safe or unsafe.
Wolinsky and Roundy do not teach that the reception of call data is performed “via an Application Program Interface”. However, in the previous office action the Examiner took an Official Notice that “an Application Programming Interface” was well known in the industry at the effective filing date of the application as a connection between computers or between computer programs. It is a type of software interface, offering a service to other pieces of software. An application programming interface connects computers or pieces of software to each other. It allows two software systems to communicate across a boundary - an interface - using mutually agreed-upon signals. In other words, an API connects software entities together. (see https://en.wikipedia.org/wiki/API).
Therefore, it would have been obvious to a person of ordinary skill in the art at the effective filing date of the application to utilize well known in the industry and widely used application programming interface, in the system of Wolinsky, and transmit disclosed by Wolinsky transcript of the phone call between different components of the system “via an Application Program Interface”. Doing so would have simply conformed to the industry standards and protocols and allowed multiple software systems to communicate across a boundary - an interface - using mutually agreed-upon signals.
Conclusion
Applicant's amendment necessitated the new ground(s) of rejection presented in this Office action. Accordingly, THIS ACTION IS MADE FINAL. See MPEP § 706.07(a). Applicant is reminded of the extension of time policy as set forth in 37 CFR 1.136(a).
A shortened statutory period for reply to this final action is set to expire THREE MONTHS from the mailing date of this action. In the event a first reply is filed within TWO MONTHS of the mailing date of this final action and the advisory action is not mailed until after the end of the THREE-MONTH shortened statutory period, then the shortened statutory period will expire on the date the advisory action is mailed, and any nonprovisional extension fee (37 CFR 1.17(a)) pursuant to 37 CFR 1.136(a) will be calculated from the mailing date of the advisory action. In no event, however, will the statutory period for reply expire later than SIX MONTHS from the mailing date of this final action.
Any inquiry concerning this communication or earlier communications from the examiner should be directed to GENNADIY TSVEY whose telephone number is (571)270-3198. The examiner can normally be reached Mon-Fri 9-5:30.
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, Wesley Kim can be reached at 571-272-7867. 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.
/GENNADIY TSVEY/ Primary Examiner, Art Unit 2648
Prosecution Insights