DETAILED ACTION
Status of Claims
The present application, filed on or after March 16, 2013, is being examined under the first inventor to file provisions of the AIA .
This action is in reply to the amendment filed on 04/26/2026.
Claims 1-20 are currently pending and have been examined.
Response to Arguments
The previous software per se rejection of claims 13-14 and 17-20 is hereby withdrawn due to applicant’s amendments.
Applicant’s arguments, see pages 10-11, filed 04/23/2026, with respect to claims 1-20 rejected under 35 USC 101 for being directed towards an abstract idea have been fully considered and are persuasive. The 101 rejection of claims 1-20 has been withdrawn.
Applicant’s arguments with respect to claim(s) 1-20 rejected under 35 USC 102 and 35 USC 103 have been considered but are moot because the new ground of rejection does not rely on any reference applied in the prior rejection of record for any teaching or matter specifically challenged in the argument.
Claim Objections
Claim 15 objected to because of the following informalities: Claim 15 recites “… the first memory stores a set up deepfake models…”. Examiner believes this to be a typo and should be “the first memory stores a set of deepfake models…“. Appropriate correction is required.
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 for the rejection will not be considered a new ground of rejection if the prior art relied upon, and the rationale supporting the rejection, would be the same under either status.
The following is a quotation of 35 U.S.C. 103 which forms the basis for all obviousness rejections set forth in this Office action:
A patent for a claimed invention may not be obtained, notwithstanding that the claimed invention is not identically disclosed as set forth in section 102, if the differences between the claimed invention and the prior art are such that the claimed invention as a whole would have been obvious before the effective filing date of the claimed invention to a person having ordinary skill in the art to which the claimed invention pertains. Patentability shall not be negated by the manner in which the invention was made.
The factual inquiries set forth in Graham v. John Deere Co., 383 U.S. 1, 148 USPQ 459 (1966), that are applied for establishing a background for determining obviousness under 35 U.S.C. 103 are summarized as follows:
1. Determining the scope and contents of the prior art.
2. Ascertaining the differences between the prior art and the claims at issue.
3. Resolving the level of ordinary skill in the pertinent art.
4. Considering objective evidence present in the application indicating obviousness or nonobviousness.
Claims 1, 2, 5, 10-14, and 17 are rejected under 35 U.S.C. 103 as being unpatentable over Shahriar, et al. (US Patent Application Publication 20230319058), “Shahriar” in view of Buck et al. (US Patent Application Publication 20210243595), “Buck”.
As per claim 1, and 13, Shahriar discloses:
A method for facilitating prevention of fraudulent transactions, the method comprising: [0002], [0026], [0032]
extracting, by a fraud prevention server, content from an ongoing call established with a first device associated with a first user; [0020], [0036] Further disclosed herein are methods and systems for authenticating a caller based on data captured from a gateway device (e.g., configured as a trusted device) located at a premises of the party. For example, if a security escalation is triggered during a communication session (e.g., a phone call or a video chat), a service provider may send a request to the gateway device to authenticate the caller (e.g., the source of the communication)… The security manager 102 may use voice-to-text conversion to generate the call data 116. The security manager 102 may use keyword searching, or machine learning to analyze the call data 116 and determine a call (e.g., from the first user device 110) includes a request for sensitive information.
determining, by the fraud prevention server, that the content indicates that a financial transaction is associated with the ongoing call; [0026], [0032], [0036] A goal of the second user device 114 may be to lure the user of the first user device 110 into disclosing or transmitting sensitive information to the second user device 114. Based on a request from the second user device 114, the user of the first user device 110 may verbally disclose sensitive information (e.g., a social security number, bank account information, credit card information, user accounts and/or passwords, etc.) or may complete a financial transaction… The security manager 102 may use voice-to-text conversion to generate the call data 116. The security manager 102 may use keyword searching, or machine learning to analyze the call data 116 and determine a call (e.g., from the first user device 110) includes a request for sensitive information. The security manager 102 may determine, based on the call data 116, that a communication is insecure, has an unknown source, includes suspicious activity, or is potentially fraudulent… For example, Bob's phone may block Bob from responding to requests for sensitive information (e.g., social security numbers or bank information) or may distort QR codes that Alice shares with Bob for payments.
identifying, by the fraud prevention server, a second user associated with the ongoing call based on the content that indicates the financial transaction is associated with the ongoing call; [0026], [0032], [0036], [0040] The security manager 102 may use voice-to-text conversion to generate the call data 116. The security manager 102 may use keyword searching, or machine learning to analyze the call data 116 and determine a call (e.g., from the first user device 110) includes a request for sensitive information… Based on a request from the second user device 114, the user of the first user device 110 may verbally disclose sensitive information (e.g., a social security number, bank account information, credit card information, user accounts and/or passwords, etc.) or may complete a financial transaction… An identity of one or more parties to a communication (e.g., a source of the communication or a party requesting sensitive information) may be verified based on one or more forms of authentication. For example, a party requesting sensitive information may be authenticated via biometric authentication or audio/video confirmation from a trusted device. A gateway device (e.g., configured as a trusted device) located at a premises of the party to authenticate may receive a request to authenticate the party requesting the sensitive information. The gateway device may perform the authentication based on one or more monitored parameters (e.g., audio or video confirmation, pings from assigned devices on the gateway, television viewing habits for the caller, unlocked home security with assigned code, sounds produced in the caller's home environment, etc.) or data received from one or more trusted devices connected to the gateway device… The verification service 104 may be configured to verify an identity of one or more parties to the communication session… The call's capabilities may be restricted based on the untrusted nature of the call. For example, Bob's phone may block Bob from responding to requests for sensitive information (e.g., social security numbers or bank information) or may distort QR codes that Alice shares with Bob for payments.
retrieving, by the fraud prevention server, contact information of the second user identified from the content of the ongoing call; [0033-0034] The network device 112 may be configured to process (e.g., route) communication for a plurality of devices, including calls to and from the first user device 110 or second user device 114. The network device 112 may store call information. The call information may be accessed and/or stored as call data 116. The call data 116 may include one or more characteristics associated with the call, including a phone number, date/time, contact information, audio, video, etc. In order to protect privacy, any identifying data (e.g., call data 116) may be stored in a secure manner… The security manager 102 may be configured to analyze the call data 116. For example, the security manager 102 may identify a call as having an unknown source, suspicious, or potentially fraudulent (e.g., by comparing call data 116 to screening data 118). Moreover, the security manager 102 may be configured to generate and/or update screening data 118 based on analysis of the call data 116.
initiating, by the fraud prevention server, a first communication with a second device associated with the second user, [0049], [0068] At step 212 of process 200, the second user device 114 may select a verifier from a list of available verifiers. A verifier may be a trusted device such as another device (e.g., network device 112) connected to the same network (e.g., network 108) and/or another device in the vicinity of the first user device 110. The verifier may be configured to record audio, video, or may comprise another device configured to receive a user input… At step 406, an identity of the first party to the communication session may be verified. The identity may be verified based on the interruption of the communication session. The verification may be performed based on biometric authorization or audio/video confirmation from a trusted device
Shahriar does not expressly disclose the following, Buck, however discloses:
wherein the first communication includes a request for confirmation or denial that the ongoing call established with the first device was set-up by the second user; and [0198-0200], [0203-0205] In at least one embodiment, during a call with an enterprise… For example, when call A is initiated between company B and caller C (scammer) about account F, and call D is initiated by caller C (scammer) to customer E (customer of company B) about account F, a signal can be triggered by company B on call A to determine whether the user device 104 is associated with customer E and in response to a determination that the device is not associated with customer E, an action can be taken…. In another embodiment, in response to a call being received from an enterprise, the security component 122 can send a request to the enterprise requesting confirmation that the phone call was placed by the enterprise, based on the response received from the enterprise, remedial actions can be taken such as notifying the user of the potential vishing threat, or terminating the phone call… In some embodiments, the communication can be sent to the one or more devices 104 associated with the user whose vishing risk level meets a threshold amount, for example a message “Did you just make a phone call to bank A and request to transfer funds?” In response to a user correctly answering validation steps/questions, the request can be rejected or accepted. In at least one embodiment, in response to the vishing attempt being identified, one or more accounts associated with the user can be locked (i.e., can mean that an intruder previously accessed the user account).
instructing a payment application server, by the fraud prevention server, to reject the financial transaction associated with the ongoing call based on one of (i) a first response to the first communication indicating denial of the ongoing call being set-up by the second user and (ii) an absence of the first response to the first communication, wherein the payment application server is a server arrangement for facilitating financial transactions. [0053-0055], [0065], [0178], [0191], [0196], [0200] In some embodiments, the communication can be sent to the one or more devices 104 associated with the user whose vishing risk level meets a threshold amount, for example a message “Did you just make a phone call to bank A and request to transfer funds?” In response to a user correctly answering validation steps/questions, the request can be rejected or accepted. In at least one embodiment, in response to the vishing attempt being identified, one or more accounts associated with the user can be locked (i.e., can mean that an intruder previously accessed the user account)… In another example, a bank may receive a request from an application for payment from an account associated with a user identifier 904. At step 1012, the server system 102 may determine from one or more threat assessments (e.g., impossible travel determination) from one or more of the user's devices 104 correlated with that user identifier 904 that that particular application is not actually installed on any of the user's devices 104. The request may therefore be flagged as fraudulent or potentially fraudulent… The method 1000 may further include flagging 1018 the activity from steps 1006 and 1008 as fraudulent. This may invoke actions to reduce harm caused by the fraudulent activity, such as alerting the user of the device 104, stopping processing of payment, stopping fulfillment of a purchase, or performing other actions to reverse actions invoked in response to the fraudulent activity… A security policy 114 may include conditions to be tested or checked, and corresponding actions to be taken, which actions can include one or more of… notifying a server… allowing or disallowing access to a particular service or services, e.g., enterprise services, which could include terminating an existing session with a particular service or services… This enterprise vishing module 1022 can be used to protect the account owner, and/or the enterprise (e.g., bank).
It would have been obvious to one having ordinary skill in the art at the time the invention was filed to modify Shahriar with the ability to validate a user by using validation questions such as “Did you just make a phone call to bank A and request to transfer funds?” as taught by Buck, doing so allows transaction request to be accepted or rejected based on the user’s response to security questions [0200].
As per claim 2, and 14, Shahriar discloses:
parsing, by the fraud prevention server, the content to determine whether the content indicates that the financial transaction is associated with the ongoing call. [0032], [0036] The security manager 102 may use voice-to-text conversion to generate the call data 116. The security manager 102 may use keyword searching, or machine learning to analyze the call data 116 and determine a call (e.g., from the first user device 110) includes a request for sensitive information. The security manager 102 may determine, based on the call data 116, that a communication is insecure, has an unknown source, includes suspicious activity, or is potentially fraudulent. The security manager 102 may utilize one or more trust rules to associate a status of one or more parties to the communication with corresponding actions. For example, the one or more trust rules may comprise requiring a signed token prior to allowing a financial transaction between the parties to the communication… Based on a request from the second user device 114, the user of the first user device 110 may verbally disclose sensitive information (e.g., a social security number, bank account information, credit card information, user accounts and/or passwords, etc.) or may complete a financial transaction.
As per claim 5, and 17, Shahriar discloses:
determining, by the fraud prevention server, based on reception of the ongoing call on the first device, whether contact information of a caller of the ongoing call is absent in a contact list associated with the first user, wherein the content of the ongoing call is extracted upon the determination that the contact information of the caller is absent in the contact list. [0034], [0040] The security manager 102 may be configured to analyze the call data 116. For example, the security manager 102 may identify a call as having an unknown source, suspicious, or potentially fraudulent (e.g., by comparing call data 116 to screening data 118)… The screening data 118 may comprise a list and/or a database of data used for determining whether a call should be further processed using by the security manager 102… The security manager 102 may determine, based on the call data 116, that a communication is insecure, has an unknown source, includes suspicious activity, or is potentially fraudulent… The verification service 104 may be configured to verify an identity of one or more parties to the communication session. For example, the security manager 102 may send a request to the verification service 104 to verify the identity of an unknown source of a communication session (e.g., from a second user device 112). The verification service 104 may verify the identity of one or more parties to the communication session by using biometric authentication (e.g., fingerprint reading, facial recognition, eye scanning, etc.).
As per claim 10, Shahriar discloses:
communicating, by the fraud prevention server, a first notification to the first device based on the first response indicating the denial of the ongoing call being set-up by the second user, wherein the first notification indicates to the first user that the ongoing call is a fraudulent call. [0002], [0023], [0034] If a request for sensitive information is detected or a communication is identified as having an unknown source, a security escalation process may begin. A status of the communication or a source of the communication may be output (e.g., via a display) to the recipient of the communication. The status may indicate that the communication is unsecure or the source of the communication is unverified. Moreover, the communication may be paused and/or outgoing communication (e.g., audio or video) may be blocked so a user does not accidentally share sensitive information on an unsecured communication… If the gateway cannot verify that Joe is the caller, the call may be terminated or Susan may be presented with a warning that the caller cannot be verified… The security manager 102 may be configured to analyze the call data 116. For example, the security manager 102 may identify a call as having an unknown source, suspicious, or potentially fraudulent (e.g., by comparing call data 116 to screening data 118).
As per claim 11, Shahriar discloses:
wherein the content of the ongoing call corresponds to at least one of audio content and video content, and wherein the ongoing call comprises a real-time communication session between the first device and the second device. [0016], [0025] Some disclosed methods and systems may prevent deep-fake-based scams by adding a “verified by” capability to the communication session (e.g., a voice call or video chat)… In an example, if a caller places a phone call or initiates a video-chat, the caller's biometric information (e.g., fingerprint, retina scan, etc.) may be used to generate an encrypted token. The token may be stored (e.g., in a cache, on a user's device, on a server, on a network device, etc.) for a duration of the call. If a security escalation process is triggered during the phone call (e.g., based on a request for sensitive information detected by a service provider), the service provider may send a request to the device to verify the caller.
As per claim 12, Shahriar discloses:
wherein the first communication corresponds to one of a call, an email, an instant message, a text message, a short message service (SMS), a flash message, and a pop-up notification , wherein the first communication is initiated while the ongoing call is active. [0027], [0042] To elevate her call to verified status, Alice may request another camera in the vicinity to verify her. The video call software may present her with a list of validators near her who may verify her video. These validators may be video cameras that are managed by services (e.g., service providers or equipment manufacturers) who are unlikely to be hacked or otherwise compromised. Alice may select a local camera as the validator and she may then be required to continue the call while standing in front of the validator. Alice may add that camera to her call as the validator and the validator may then compare the video being shared on the call from Alice's phone to what the validator sees. If the videos match, the validator may send an encrypted/signed certificate with the call verifying that the video Alice is sharing is the video the validator is seeing as well. Bob's phone may validate this certificate and mark the call as verified… For example, the security manager 102 may have interrupted or paused the call based on determining that a party (e.g., first user device 110) to a video-chat has requested sensitive information from another party (e.g., second user device 114) to the video-chat.
As per claims 13, 14, and 17, claims 13, 14, and 17 recite substantially similar limitations to those found in claims 1, 2, and 5, respectively. Therefor claims 13, 14, and 17 are rejected under the same art and rationale as claims 1, 2, and 5. Furthermore, Shahriar discloses a system, server, memory and processor [0078-0080].
Claims 3, 4, 15, and 16 are rejected under 35 U.S.C. 103 as being unpatentable over Shahriar, et al. (US Patent Application Publication 20230319058), “Shahriar” in view of Buck et al. (US Patent Application Publication 20210243595), “Buck” in view of Ur (US Patent Application Publication 20210126929), “Ur”.
As per claim 3, Shahriar discloses the content as being an on-going call ([0020], [0036]), but does not expressly the utilizing a set of models, Ur, however discloses the following:
wherein identifying the second user associated with the ongoing call comprises: executing upon extracting the content, by the fraud prevention server, a set of deepfake detection models associated with the fraud prevention server to analyze the content; and [0038-0039], [0042-0043], [0056] In some exemplary embodiments, the GAN techniques may utilize classification results of the personalized model, which may be used as a deepfake detector, to learn how to avoid being spotted by the detector… In some exemplary embodiments, one or more personalized models in the possession of the user may be examined to identify therein a personalized model of the participant that matches the identified context... In some exemplary embodiments, personalized models may be trained to identify a person with which the user is communicating in non-public contexts, based on media of the person that is not publicly accessible... In some exemplary embodiments, a media stream associated with a participant, such as a real-time media stream, may be obtained. In some exemplary embodiments, the media stream may be obtained from a media source such as a broadcast, a radio-based communication, a phone call, a video call, a FACBOOK™ live stream, a YOUTUBE™ live stream, or the like. In some exemplary embodiments, the media stream may be captured or displayed at a computing device of a user, e.g., via an application of the device, a camera of the device, a browser of the device, or the like. In some exemplary embodiments, the media stream may depict a communication of the user with a participant in a specific communication context, e.g., during an interaction of a certain type. In some exemplary embodiments, the media stream may or may not be publicly accessible, publicly available, or the like…
determining, by the fraud prevention server, based on execution of the set of deepfake detection models, whether the ongoing call is a deepfake call to identify the identifier of the second user. [0058-0059], [0065], [0092] In some exemplary embodiments, the personalized model may only classify real time communications such as telephone conversations, video calls, or the like, without attempting to authenticate uploaded media... In some exemplary embodiments, Personalized Model 130 may be configured to authenticate Participant 150 in the communication context, e.g., in real time, as the authentic participant or as a fraud… In some exemplary embodiments, two or more different personalized models of respective people may be utilized during a same communication session.
It would have been obvious to one having ordinary skill in the art at the time the invention was filed to modify Shahriar with the ability to execute a set of personalized models to detect if a user is deepfake as taught by Ur, doing so allows the model with the highest score to be utilized indicating it’s the most similar model to the user [0043-44].
As per claim 4, and 16, Shahriar does not expressly the following, Ur, however discloses:
training, by the fraud prevention server, the set of deepfake detection models when a second response to the first communication indicates confirmation of the ongoing call being initiated by the second user. [0047], [0050-0051], [0097] In some exemplary embodiments, different personalized models for different participants may be trained to identify the participants in corresponding communications with the user. In some exemplary embodiments, a user may retain a personalized model for one or more participants with which he communicates, and each such participant may be considered to be a separate communication context. For example, communications of the user with a first person may be used to train a personalized model of the first person, and communications of the user with a second person may be used to train a personalized model of the second person. Based on the first and second models, any incoming call or other communication with the first or second person may be authenticated… In some exemplary embodiments, the verification indication may be used to tag the communication as correctly classified or incorrectly classified, which may be used for enhancing the personalized model by further training.
It would have been obvious to one having ordinary skill in the art at the time the invention was filed to modify Shahriar with the ability to use the verification indication that the communication was classified correctly for further training of the models as taught as Ur, doing so further enhances the models based on correct classifications [0097].
As per claim 15, Shahriar, discloses the content as being an on-going call ([0020], [0036]), but does not expressly the following, Ur, however discloses the following:
wherein the first memory stores a set up deepfake detection models; and [0111]
execute, the set of deepfake detection models to analyze the content upon extracting the content; and [0038-0039], [0042-0043], [0056] In some exemplary embodiments, the GAN techniques may utilize classification results of the personalized model, which may be used as a deepfake detector, to learn how to avoid being spotted by the detector… In some exemplary embodiments, one or more personalized models in the possession of the user may be examined to identify therein a personalized model of the participant that matches the identified context... In some exemplary embodiments, personalized models may be trained to identify a person with which the user is communicating in non-public contexts, based on media of the person that is not publicly accessible... In some exemplary embodiments, a media stream associated with a participant, such as a real-time media stream, may be obtained. In some exemplary embodiments, the media stream may be obtained from a media source such as a broadcast, a radio-based communication, a phone call, a video call, a FACBOOK™ live stream, a YOUTUBE™ live stream, or the like. In some exemplary embodiments, the media stream may be captured or displayed at a computing device of a user, e.g., via an application of the device, a camera of the device, a browser of the device, or the like. In some exemplary embodiments, the media stream may depict a communication of the user with a participant in a specific communication context, e.g., during an interaction of a certain type. In some exemplary embodiments, the media stream may or may not be publicly accessible, publicly available, or the like.
determine based on execution of the set of deepfake detection models, whether the ongoing call is a deepfake call to identify the identifier of the second user. [0058-0059], [0065], [0092] In some exemplary embodiments, the personalized model may only classify real time communications such as telephone conversations, video calls, or the like, without attempting to authenticate uploaded media... In some exemplary embodiments, Personalized Model 130 may be configured to authenticate Participant 150 in the communication context, e.g., in real time, as the authentic participant or as a fraud… In some exemplary embodiments, two or more different personalized models of respective people may be utilized during a same communication session.
It would have been obvious to one having ordinary skill in the art at the time the invention was filed to modify Shahriar with the ability to execute a set of personalized models to detect if a user is deepfake as taught by Ur, doing so allows the model with the highest score to be utilized indicating it’s the most similar model to the user [0043-44].
As per claim 16, claim 16 recites substantially similar limitations to those found in claim 4. Therefor claim 16 is rejected under the same art and rationale as claim 4. Furthermore, Shahriar discloses a system, server, memory and processor [0078-0080].
Claims 6 and 18 are rejected under 35 U.S.C. 103 as being unpatentable over Shahriar, et al. (US Patent Application Publication 20230319058), “Shahriar” in view of Buck et al. (US Patent Application Publication 20210243595), “Buck” in view of Maizels, et al. (International Publication Number WO 2024018400), “Maizels”.
As per claim 6, and 18, Shahriar discloses:
comprising retrieving, by the fraud prevention server, contact information of the second user based on the identifier of the second user from a contact list associated with the first user, wherein the first communication is initiated with the second device based on the contact information, and the contact information of the second user corresponds to at least one of a contact number, a social media username, and an email identifier of the second user. [0030], [0032], [0036], [0040] An identity of one or more parties to a communication (e.g., a source of the communication or a party requesting sensitive information) may be verified based on one or more forms of authentication. For example, a party requesting sensitive information may be authenticated via biometric authentication or audio/video confirmation from a trusted device. A gateway device (e.g., configured as a trusted device) located at a premises of the party to authenticate may receive a request to authenticate the party requesting the sensitive information. The gateway device may perform the authentication based on one or more monitored parameters (e.g., audio or video confirmation, pings from assigned devices on the gateway, television viewing habits for the caller, unlocked home security with assigned code, sounds produced in the caller's home environment, etc.) or data received from one or more trusted devices connected to the gateway device… The verification service 104 may be configured to verify an identity of one or more parties to the communication session…The first user device 110 or second user device 114 may each comprise and/or be associated with a user identifier. The user identifier may comprise a number, such as a phone number.
Shahriar does not expressly disclose the following, Maizels, however discloses
wherein the identifier of the second user is a name of the second user [0927], [0993] Consistent with some disclosed embodiments, verifying the identity includes verification of a name of the subject. Verification of the name of the subject may include correlating the identity of the subject of the communication with the name of the subject. For example, facial micromovements may be used to determine the identity of the subject. A data structure may be created based on historical data that correlates the identity of the subject using facial micromovements and the name of the subject. During the real-time transaction, a lookup in the data structure may retrieve the name of the subject and the second data stream may be generated including the name of the subject. The second data stream may be transmitted to the destination (i.e., entity) where the name may be used to verify the identity of the subject.
It would have been obvious to one having ordinary skill in the art at the time the invention was filed to modify Shahriar with the ability to identify a user based on their name as taught by Maizels, doing so allows the user to be identified based on providing their name [0927], [0993].
As per claim 18, claim 18 recites substantially similar limitations to those found in claim 6. Therefor claim 18 is rejected under the same art and rationale as claim 6. Furthermore, Shahriar discloses a system, server, memory and processor [0078-0080].
Claims 7-9 and 19-20 are rejected under 35 U.S.C. 103 as being unpatentable over Shahriar, et al. (US Patent Application Publication 20230319058), “Shahriar” in view of Singhal, et al. (US Patent Application Publication 20100229245), “Singhal”.
As per claim 7, and 19, Shahriar does not expressly disclose the following ,Singhal, however discloses:
setting by the fraud prevention server, a value of a first time period; and [0033] The contact by the transaction processing entity or the mobile authorization service provider via the owner's wireless mobile communication device may include a SMS text message that embeds a pre-placed security code and may include sending to the identity data owner, (i) name of the transaction initiating entity, date and time, and optionally an amount for a payment transaction. The authorization may include accept, decline or time out due to lack of response, where the time out is set based on the type of the transaction.
determining, by the fraud prevention server, whether the first response is received based on the initiation of the first communication with the second device in the first time period, wherein the payment application server is instructed to reject the financial transaction based on the absence of the first response to the first communication at an end of the first time period. [0033], [0087] The contact by the transaction processing entity or the mobile authorization service provider via the owner's wireless mobile communication device may include a SMS text message that embeds a pre-placed security code and may include sending to the identity data owner, (i) name of the transaction initiating entity, date and time, and optionally an amount for a payment transaction. The authorization may include accept, decline or time out due to lack of response, where the time out is set based on the type of the transaction… Further, the protocol in Internet type computer networks are based on state based transactions and can keep a transaction pending until authorization is obtained or not obtained and then issue an acceptance or rejection as appropriate. For that, a time out limit may be implemented by the ODFI and may be appropriately set.
It would have been obvious to one having ordinary skill in the art at the time the invention was filed to modify Shahriar with the ability to decline a transaction if no response is received after a time out as taught by Singhal, doing so further prevents fraud of a someone impersonating the user using remote authorizations [0052-0053].
As per claim 8, and 20, Shahriar does not expressly disclose the following, Singhal, however discloses:
setting, by the fraud prevention server, a value of a second time period upon setting the value of the first time period, wherein the second time period is shorter than the first time period; and [0081] The RDFI 212 may, however, reject the ACH transaction and return it to the ODFI 208 if, for example, the account had insufficient funds or the account holder indicated that the transaction was unauthorized. An RDFI 212 has a prescribed amount of time in which to perform returns, ranging from 2 to 60 days from the receipt of the ACH transaction… [0084] Such a protocol as ACH 210 may optionally be enhanced to communicate a predefined time delay in acceptance or delayed acceptance, in addition to acceptance and rejection of the transaction immediately by the receiving bank, allowing the receiving bank to seek an authorization by the true identity data owner, the bank account owner. The protocol may indicate that the approval is delayed depending upon the type of the transaction for an authorization beyond checking sufficiency of funds or other issues such as stop payment. The protocol may be based on using the current rejection protocol by adding a time delay to resubmit the transaction. Similar protocols exist in ACH such as one that communicates a stop payment order or insufficient funds as part of the rejection… [0093] In the reactive mode, the enable/disable flag 79 would be left in the disable mode at all times. When a transaction is conducted, the identity data owner would get a real time transaction advisory message. The id data owner can review these transactions and could reject a transaction from final completion, if he/she sends a reject message before expiration of a certain time limit from the time of the transaction origination. The time limit could be in hours and could be up to 18 hours, as the ACH payment systems provide for an actual fund transfer in 24 hours after the payment authorization… [0095] After the transaction is completed, then, the id data owner could press another function key to enable the enable/disable flag 79. Alternatively, the enable/disable flag 79 could be automatically enabled after a time out of, let us say five minutes, without the id data owner have to press the second function key… The mobile authorization may be implemented as defined as three operational modes of a proactive mode, a reactive mode and a combined mode.
generating by the fraud prevention server, a hold request indicating the payment application server to place the financial transaction on hold, wherein the financial transaction is placed on hold by the payment application server based on the hold request, and wherein the hold request is generated at an end of the second time period and upon the absence of the first response within the second time period. [0070], [0073], [0150-0151] The receiving bank then either accepts or rejects the transaction by using the communication protocol. The protocol enables the rejected transaction to be resubmitted again two times… The payer's bank 18, the transaction processing entity, while processing this request for payment or payment authorization puts the request on hold for a brief period of time, and via a mobile authorization system 30, that has a mobile contact database 32 and IVR/SMS subsystem 34, sends a request for authorization of the transaction to the mobile device 36 of the identity data owner, or payer entity 12…At step 108, awaiting the response by the entity from the customer for a period of time, and processing the response, where on receiving (i) a yes response approving the request, (ii) on receiving a No response declining the request and (iii) for lack of response, advising the requesting entity to present the request at a later time… At step 110, selecting and setting the period of time of response threshold based on the type of the payment request, the identification of the requesting entity, and originating location of the request, to be between 30 seconds and 18 hours.
It would have been obvious to one having ordinary skill in the art at the time the invention was filed to modify Shahriar with the ability to decline a transaction if no response is received after a time out and the ability to resubmit the transaction within a second predetermined amount of time as taught by Singhal, doing so further prevents fraud of a someone impersonating the user using remote authorizations [0052-0053].
As per claim 9, Shahriar discloses:
receiving, by the fraud prevention server, a second response to the first communication indicating confirmation of the ongoing call being set-up by the second user; and [0020], [0025] Some disclosed methods and systems may prevent deep-fake-based scams by adding a “verified by” capability to the communication session (e.g., a voice call or video chat). The verification may be based on video (e.g., or audio) recorded by a trusted video camera. An object recognition process (e.g., using a machine learning model trained to recognize specific users) may analyze the video (e.g., or audio) to determine that a person is detected and/or the person matches a specific person, such as the person for which verification is attempted… For example, if a security escalation is triggered during a communication session (e.g., a phone call or a video chat), a service provider may send a request to the gateway device to authenticate the caller (e.g., the source of the communication). The gateway may survey the caller's activities and send a signed token to the service provider.
does not expressly disclose the following, Singhal, however discloses:
transmitting based on the reception of the second response, by the fraud prevention server, a release notification to the payment application server to release the hold on the financial transaction, wherein when the second response is received after the end of the second time period and before the end of the first time period, the release notification is transmitted to the payment application server. [0029], [0073], [0150] In the system of the preferred embodiment, a transaction processing entity, after it receives an identity data driven transaction from a transaction initiating entity, puts on hold the processing of the transaction for a period of time and via the identity data owner's wireless mobile communication device, contacts the identity data owner for authorization of the transaction before the transaction processing is allowed to complete… The receiving bank, upon receiving a payment transaction authorization request record, first checks to see if it can approve the transaction. For example, the receiving bank can reject a transaction if there are insufficient funds to cover the request and also if there is a stop order that has been placed against a particular check. The receiving bank then either accepts or rejects the transaction by using the communication protocol. The protocol enables the rejected transaction to be resubmitted again two times… At step 108, awaiting the response by the entity from the customer for a period of time, and processing the response, where on receiving (i) a yes response approving the request, (ii) on receiving a No response declining the request and (iii) for lack of response, advising the requesting entity to present the request at a later time.
It would have been obvious to one having ordinary skill in the art at the time the invention was filed to modify Shahriar with the ability to decline a transaction if no response is received after a time out and the ability to resubmit the transaction within a second predetermined amount of time as taught by Singhal, doing so further prevents fraud of a someone impersonating the user using remote authorizations [0052-0053].
As per claims 19, and 20, claims 19, and 20 recite substantially similar limitations to those found in claims 7, and 8, respectively. Therefor claims 19, and 20 are rejected under the same art and rationale as claims 7 and 8. Furthermore, Shahriar discloses a system, server, memory and processor [0078-0080].
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 GREGORY S CUNNINGHAM II whose telephone number is (313)446-6564. The examiner can normally be reached Mon-Fri 8:30am-4pm.
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, Bennett Sigmond can be reached at 303-297-4411. 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.
GREGORY S. CUNNINGHAM II
Primary Examiner
Art Unit 3694
/GREGORY S CUNNINGHAM II/Primary Examiner, Art Unit 3694
Prosecution Insights