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 .
Priority
The instant application 19/194,872 claims priority to provisional application US 63/640,970 which claims the priority filing date of 05/01/2024. Therefore, the effective filing date of the instant application is 05/01/2024.
Oath/Declaration
Applicant’s oath/declaration filed on 04/30/2025 has been reviewed by the examiner and is found to conform to the requirements prescribed in 37 C.F.R. 1.63.
Information Disclosure Statement
The information disclosure statements (IDS) submitted on 07/25/2025, 09/29/2025, and 01/08/2026 are in compliance with the provisions of 37 CFR 1.97. Accordingly, the information disclosure statement is being considered by the examiner.
Drawings
The drawings submitted on 04/30/2025 with the instant application are acceptable for examination purposes.
Specification
The specification submitted on 04/30/2025 with the instant application are acceptable for examination purposes.
Claim Rejections - 35 USC § 101
35 U.S.C. 101 reads as follows:
Whoever invents or discovers any new and useful process, machine, manufacture, or composition of matter, or any new and useful improvement thereof, may obtain a patent therefor, subject to the conditions and requirements of this title.
Claims 1-20 are rejected under 35 USC 101 because the claimed invention is directed to
abstract ideas without significantly more.
Claim 1 is directed to a system for receiving a screening payload and identifying a device based on characteristics included in the payload in order to signal an alert at the identified device. The recited system is a machine which falls within one of the statutory categories.
Claim 1 recites judicial exceptions in the steps of identifying a stored enhanced authorization request and identifying a device on a network having second device characteristics. These processes, under broadest reasonable interpretation, cover performance of the limitations in the mind except for the recitation of the generically stated system. That is, the recited limitations “identify a stored enhanced authorization request corresponding to the identified authorization request, the stored enhanced authorization request including first device characteristics”; and “identify a device on a network having second device characteristics, the second device characteristics matching the first device characteristics” are interpretable as mental processes, with recitations being performed by a generically stated device.
These judicial exceptions are not integrated into a practical application. Additional elements of the claim include the system, storage media, processor, instructions, screening payload, client platform, an identified device, and the receiving and control signal transmission steps. All of the hardware/functional elements of the claim are recited at a high level of generality. The screening payload, client platform, authorization request, and enhanced authorization request are also broadly stated elements that do not serve to narrow the interpretable environment or particular device functionality. The receiving step represents a conventional data gathering activity, i.e. receiving data (screening payload) from some source (client platform). The subsequent transmitting of the control signal represents extra-solution activity, as the act of transmitting the control signal is not meaningfully connected to either of the abstract ideas nor the performance of the steps by the recited system. That is, it is not clear which condition or if there is a condition that triggers the transmission of the control signal. Further, it is not clear what the alert that the identified device is caused to generate should indicate. Therefore, these additional elements cannot be considered to integrate the abstract ideas into a practical application, as they do not pose any meaningful limits on practicing the abstract ideas.
The claim does not incorporate the additional elements in a manner that is sufficient to amount to significantly more than the judicial exceptions. The additional elements, as stated above, are recited at a high level of generality—the claim language does not meaningfully connect the abstract identifying steps to the operation of the system. Therefore, nothing in the claim adds significantly more than the abstract ideas, and the claim is ineligible.
Claims 2-8 are also rejected due to their dependence on Claim 1.
Claim 9 recites substantially similar limitations to those of Claim 1.
Claim 9 recited a corresponding process of claim 1 to be performed by a networked computer platform. However, the networked computer platform is also recited at a high level of generality, and does not integrate the abstract ideas into a practical application. Therefore, Claim 9 is also ineligible for at least the same reasons as Claim 1.
Claims 10-16 are also rejected due to their dependence on Claim 9.
Claim 17 is directed to a storage medium storing executable instructions for receiving a screening payload and identifying a device based on characteristics included in the payload in order to notify a screening device of the location of the identified device. The recited storage medium is a machine which falls within one of the statutory categories.
Similar to Claim 1, Claim 17 recites judicial exceptions in the steps of identifying a stored enhanced authorization request and identifying a device on a network having second device characteristics. Claim 17 recites an additional judicial exception in its step for determining the location of the identified device. These processes, under broadest reasonable interpretation, cover performance of the limitations in the mind except for the recitation of the generically stated system. That is, the recited limitations “identifying a stored enhanced authorization request corresponding to the identified authorization request, the stored enhanced authorization request including first device characteristics”; “identifying a device on a network having second device characteristics, the second device characteristics matching the first device characteristics”; and “determining a location of the identified device” are all interpretable as mental processes.
These judicial exceptions are not integrated into a practical application. Additional elements of the claim include the storage medium, processor, instructions, screening payload, client platform, screening device, an identified device, and the receiving and transmitting steps. The hardware/functional elements of the claim are recited at a high level of generality, and their interactions are not presented in a way that is meaningfully tied to the performance of the judicial exceptions. The screening payload, client platform, screening device, identified device, authorization request, and enhanced authorization request are broadly stated elements that do not serve to narrow the interpretable environment or particular device functionality. Similarly to those of Claim 1, the receiving step represents a conventional data gathering activity, and the transmitting step represents extra-solution activity. Transmitting the location of the identified device to the screening device does not provide a meaningful conclusive step relative to the abstract ideas. Claim 17 does not clearly indicate the relationship between the platforms/devices/screening device. Particularly, it is not clear why the transmission of the location of the identified device to the screening device should be considered significant. Therefore, these additional elements cannot be considered to integrate the abstract ideas into a practical application, as they do not pose any meaningful limits on practicing the abstract ideas.
The claim does not incorporate the additional elements in a manner that is sufficient to amount to significantly more than the judicial exceptions. The additional elements do not meaningfully connect the abstract identifying and determining steps to the operation of the platforms and devices, and the claim is ineligible.
Claims 18-20 are also rejected due to their dependence on Claim 20.
Claim Rejections - 35 USC § 103
The following is a quotation of 35 U.S.C. 103 which forms the basis for all obviousness rejections set forth in this Office action:
A patent for a claimed invention may not be obtained, notwithstanding that the claimed invention is not identically disclosed as set forth in section 102, if the differences between the claimed invention and the prior art are such that the claimed invention as a whole would have been obvious before the effective filing date of the claimed invention to a person having ordinary skill in the art to which the claimed invention pertains. Patentability shall not be negated by the manner in which the invention was made.
Claim(s) 1-16 is/are rejected under 35 U.S.C. 103 as being unpatentable over Varghese (US 20090089869 A1) hereinafter Varghese, in view of Dutt et al. (US 20240135383 A1) hereinafter Dutt.
Regarding Claim 1:
Varghese teaches a system comprising: non-transitory computer-readable media storing instructions; and an electronic processor configured to execute the instructions to (Varghese – Paragraph [0024]: According to yet another embodiment of the present invention, a machine-readable medium is disclosed, the machine-readable medium having stored thereon a series of instructions which, when executed by a processing component, cause the processing component to detect anomalous data submitted to a software application): receive a screening payload from a client platform, the screening payload identifying an authorization request (Varghese – Paragraph [0052]: In one set of embodiments, the various fraud detection, monitoring, and authentication processes of the present invention are implemented using a client/server type architecture (or, more generally, a distributed systems architecture); and Paragraph [0071]: Generally speaking, embodiments of the present invention provide techniques for determining whether requests (e.g., authentication requests, transaction requests, etc.) submitted by users of a software application (e.g., online shopping application, online banking application, etc.) are fraudulent and/or malicious. In an embodiment, a copy of the request or information included in the request is received), identify a stored enhanced authorization request corresponding to the identified authorization request (Varghese – Paragraph [0162]: As described above, embodiments of the present invention provide techniques for detecting whether a request (e.g., authentication request, transaction request, etc.) submitted by a user of a service provider application (e.g., online shopping application, online banking application, etc.) is likely to be fraudulent and/or malicious; and Paragraph [0166]: As shown in step 1804, the first application fingerprint is associated with one or more first contexts representing contexts in which the first data was submitted. These contexts serve to correlate the first application fingerprint with other, previously submitted application fingerprints. The one or more first contexts may include, for example, a user context identifying a user that submitted the first data, a device context identifying a device used to submit the first data, a location context identifying a location from which the first data was submitted, a workflow context identifying a workflow that was being performed when the first data was submitted, and/or the like; and Paragraph [0168]: Once the first application fingerprint has been generated, the first application fingerprint is compared with at least one second application fingerprint (step 1806). The second application fingerprint is based on second data previously submitted via the input field, and is associated with one or more second contexts substantially similar to the one or more first contexts. In other words, the second application fingerprint is a signature of historical data that was previously submitted to the application under the same or similar circumstances (e.g., by the same user, from the same device, from the same location, during the same workflow, etc.) as the first data), the stored enhanced authorization request including first device characteristics (Varghese – Paragraph [0162]: As described above, embodiments of the present invention provide techniques for detecting whether a request (e.g., authentication request, transaction request, etc.) submitted by a user of a service provider application (e.g., online shopping application, online banking application, etc.) is likely to be fraudulent and/or malicious; and Paragraph [0166]: As shown in step 1804, the first application fingerprint is associated with one or more first contexts representing contexts in which the first data was submitted. These contexts serve to correlate the first application fingerprint with other, previously submitted application fingerprints. The one or more first contexts may include, for example, a user context identifying a user that submitted the first data, a device context identifying a device used to submit the first data, a location context identifying a location from which the first data was submitted, a workflow context identifying a workflow that was being performed when the first data was submitted, and/or the like; and Paragraph [0168]: Once the first application fingerprint has been generated, the first application fingerprint is compared with at least one second application fingerprint (step 1806). The second application fingerprint is based on second data previously submitted via the input field, and is associated with one or more second contexts substantially similar to the one or more first contexts. In other words, the second application fingerprint is a signature of historical data that was previously submitted to the application under the same or similar circumstances (e.g., by the same user, from the same device, from the same location, during the same workflow, etc.) as the first data).
Varghese does not expressly teach identify a device on a network having second device characteristics, the second device characteristics matching the first device characteristics, and transmit a control signal to the identified device, the control signal configured to cause the identified device to generate an alert.
However, Dutt teaches identify a device on a network having second device characteristics, the second device characteristics matching the first device characteristics (Dutt – Figure 4A: illustration of a process for authenticating a transaction; and Paragraph [0103]: In the following example, one of the primary characteristics analyzed is location. During initiation of the transaction the user device provides first location information on the location of the first user device, and the server at the transaction site transmits transaction information necessary for the transaction to the transaction server … The transaction server calls an authentication device and the authentication device requests second location information defining the location of a second user device associated with the transaction from location information servers 1 to N, each at one of N communications service provider sites where N is an integer with N>1. The location information server of the communications service provider that provides communications services to the second user device provides a response containing the second location information; and Paragraph [0104]: Responsive to receiving the second location information, the authentication server performs location authentication by determining a level of correlation between the first location and the second location and authenticates the transaction based on the level of correlation between the first location and the second location), and transmit a control signal to the identified device, the control signal configured to cause the identified device to generate an alert (Dutt – Paragraph [0104]: A verification request is sent to the second user device in response to the location authentication requesting user credentials. In some implementations the user credentials include a PIN (Personal Identification Number), implicit information, or biometric information. Biometric information can include reading fingerprints, iris scans, temperature, pulse rate, facial recognition as well as other methods. Responsive to receiving the authentication request the user credentials are entered and a reply containing the user credentials is transmitted to the authentication device. The user credentials are authenticated and the authentication device transmits a message to the second user device indicating that the authentication has been verified; and Figure 8 with corresponding description in Paragraphs [0162]-[0167]: [0162] An example of the implementation of the fraud detection system and resolution management system can be seen in FIG. 8. In this example, a third party payment gateway is integrated with the system to enable credit processing. In some embodiments, the payment gateway may be part of the fraud verification and resolution management system.[0163] The user logins in (1) to the system (payment gateway) using a mobile device as their device (la) and registers with the system server (Fraud Detection Unit). The user sets their preferences regarding notifications and financial security with the system server (2).[0164] These settings are passed on to the payment gateway authentication database of the payment gateway (3).[0165] If a transaction is flagged by the payment gateway, a notification is sent to the Fraud Detection Unit utilizing an application programming interface (4). In some embodiments, the flag is stored on the payment gateway database (4a) prior to the flag being pushed to the fraud detection unit (4b).[0166] The fraud detection unit, receiving the flag from the payment gateway, pushes the flag to the user via rich push notifications (5). The user device receives the notification (6) and the transaction information is downloaded or viewed on the user device (7).[0167] The user may input a secondary password to authenticate (8), and the corresponding user selected action (e.g., allow/prevent/flag) is pushed to the fraud detection unit. This response is sent from the Fraud Detection Unit to the payment gateway (10a) and recorded in the database within the payment gateway (10b)).
It would have been obvious before the effective filing date of the claimed invention to a person having ordinary skill in the art to modify Varghese, further incorporating Dutt to arrive at the conclusion of the claimed invention. One would be motivated to incorporate Dutt’s teaching of confirming user intent via push notification in a process for transaction fraud prevention into Varghese’s system for comparing incoming requests with historical requests. Varghese provides techniques to detect potentially fraudulent transactions based on request context, while Dutt adds push notifications for interactive, real-time user transaction confirmations to bolster security while also limiting resource expenditure on false positives.
Regarding Claim 2:
The combination of Varghese and Dutt teaches the system of claim 1.
Varghese further teaches wherein the stored enhanced authorization request includes a historical authorization request submitted by a historical device (Varghese – Paragraph [0051]: FIG. 13A is a simplified block diagram illustrating a first system environment in accordance with an embodiment of the present invention. The system environment includes one or more service provider servers 1302, 1304 and an authentication server 1306. Servers 1302, 1304, 1306 are interconnected via network 710 to one or more user computing devices 720, which are used by end-users to submit various requests (e.g., login requests, transaction requests, etc.) to service provider applications A, B, C, D, etc. Servers 1302, 1304, 1306 are generally structured as known in the art, and include a CPU, volatile memory (e.g., RAM), disc-based or other nonvolatile memory, communication interfaces, optional user interface equipment, and the like. Database 1308 is communicatively coupled with authentication server 1306 and is configured to store data used in authentication processes, such as device, location, workflow, and application fingerprints/histories; and Paragraph [0064]: DCR process 1110 gathers the results of the current request authentication processing and stores them in a DCR database in association with the identifying information (for example, the Device ID) of the originating user device. These stored results may include, for example, whether or not the request was validated and/or whether or not the request was found to be fraudulent. In this manner, the DCR database can provide a historical record of the results of previous request authentication processing to guide FAAS 700 in future authentication request processing)).
The motivation to combine the arts is the same as that of Claim 1.
Regarding Claim 3:
The combination of Varghese and Dutt teaches the system of claim 2.
Varghese further teaches wherein the stored enhanced authorization request includes static attributes of the historical device (Varghese – Table 4: table listing various hardware and software characteristics that may be associated with a historically observed device).
The motivation to combine the arts is the same as that of Claim 1.
Regarding Claim 4:
The combination of Varghese and Dutt teaches the system of claim 3.
Varghese further teaches wherein the stored enhanced authorization request includes dynamic attributes of the historical device (Varghese – Table 4: table listing various hardware and software characteristics that may be associated with a historically observed device).
The motivation to combine the arts is the same as that of Claim 1.
Regarding Claim 5:
The combination of Varghese and Dutt teaches the system of claim 1.
Varghese further teaches wherein the stored enhanced authorization request includes hardware attributes of the historical device (Varghese – Table 4: table listing various hardware and software characteristics that may be associated with a historically observed device).
The motivation to combine the arts is the same as that of Claim 1.
Regarding Claim 6:
The combination of Varghese and Dutt teaches the system of claim 5.
Varghese further teaches wherein the electronic processor is configured to generate a device fingerprint of the historical device based on at least one of the static attributes of the historical device, the dynamic attributes of the historical device, or the hardware attributes of the historical device (Varghese – Paragraph [0074]: The diagram includes the various request attributes of Table 2 (except for application data information). In an embodiment, the request attributes of the criteria are condensed into fingerprints--for example, a location fingerprint, a device fingerprint, a workflow fingerprint, and an application fingerprint (application fingerprinting is discussed in further detail below). The fingerprints are then processed to generate actions, risk alerts, and/or risk scores. One possible action is primary authentication, which is the process by which the user is initially identified and authenticated. Primary authentication is performed primarily based on location and device fingerprints, and can include presentation of one or more authentication interfaces at the user device. Another possible action is secondary authentication, which can be invoked during the post-authentication phase of a transaction if, for example, a particular piece of data submitted by the user appears to be malicious, thereby necessitating further authentication. Secondary authentication can include use of, for example, email, voiceprints, and/or the like; and Table 4: table listing various hardware and software characteristics that may be associated with a historically observed device).
The motivation to combine the arts is the same as that of Claim 1.
Regarding Claim 7:
The combination of Varghese and Dutt teaches the system of claim 6.
Varghese further teaches wherein the stored enhanced authorization request includes the device fingerprint of the historical device (Varghese – Paragraph [0116]: At step 406, the captured device identity information (ID), including any previously stored Device ID, is compared to identity information that has been previously stored by the FAAS process in a database referred to as a "device/profile history" (see 610 of FIG. 6 where the device/profile history is referred to as a "profile history"). The device history/profile database includes record(s) associated with and describing previously recognized and/or identified devices. If it can be established that the captured device information corresponds to information previously stored for a device (test 408), the new identifying information updates the device history record for the device at step 412).
The motivation to combine the arts is the same as that of Claim 1.
Regarding Claim 8:
The combination of Varghese and Dutt teaches the system of claim 2.
Dutt further teaches wherein the identified device and the historical device are a same device (Dutt – Figure 4A: illustration of a process for authenticating a transaction; and Paragraph [0103]: In the following example, one of the primary characteristics analyzed is location. During initiation of the transaction the user device provides first location information on the location of the first user device, and the server at the transaction site transmits transaction information necessary for the transaction to the transaction server … The transaction server calls an authentication device and the authentication device requests second location information defining the location of a second user device associated with the transaction from location information servers 1 to N, each at one of N communications service provider sites where N is an integer with N>1. The location information server of the communications service provider that provides communications services to the second user device provides a response containing the second location information; and Paragraph [0104]: Responsive to receiving the second location information, the authentication server performs location authentication by determining a level of correlation between the first location and the second location and authenticates the transaction based on the level of correlation between the first location and the second location; and Paragraph [0010]: In some embodiments of the invention, the first device and the second device are the same device; and Paragraph [0161]: As discussed above, the database in the fraud prevention system is used to look at historical transactions of all users to check for potential fraud, and then appropriate users are notified/alerted of potential fraudulent transactions on their account, via rich push notifications, email, phone, or SMS for example).
The motivation to combine the arts is the same as that of Claim 1.
Regarding Claim 9:
Claim 9 is a method claim with limitations corresponding to those of system Claim 1. Therefore, Claim 9 is rejected with the same combination and rationale as Claim 1.
Varghese further teaches the additional limitations including a networked computer platform and a client platform (Varghese – Paragraph [0052]: In one set of embodiments, the various fraud detection, monitoring, and authentication processes of the present invention are implemented using a client/server type architecture (or, more generally, a distributed systems architecture). Accordingly, these processes may be executed either on the service provider's servers (e.g., 1302, 1304) or on a dedicated authentication server (e.g., 1306)).
Regarding Claim 10:
Claim 10 is a method claim with limitations corresponding to those of system Claim 2. Therefore, Claim 10 is rejected with the same combination and rationale as Claim 2.
Regarding Claim 11:
Claim 11 is a method claim with limitations corresponding to those of system Claim 3. Therefore, Claim 11 is rejected with the same combination and rationale as Claim 3.
Regarding Claim 12:
Claim 12 is a method claim with limitations corresponding to those of system Claim 4. Therefore, Claim 12 is rejected with the same combination and rationale as Claim 4.
Regarding Claim 13:
Claim 13 is a method claim with limitations corresponding to those of system Claim 5. Therefore, Claim 13 is rejected with the same combination and rationale as Claim 5.
Regarding Claim 14:
Claim 14 is a method claim with limitations corresponding to those of system Claim 6. Therefore, Claim 14 is rejected with the same combination and rationale as Claim 6.
Regarding Claim 15:
Claim 15 is a method claim with limitations corresponding to those of system Claim 7. Therefore, Claim 15 is rejected with the same combination and rationale as Claim 7.
Regarding Claim 16:
Claim 16 is a method claim with limitations corresponding to those of system Claim 8. Therefore, Claim 16 is rejected with the same combination and rationale as Claim 8.
Claim(s) 17-20 is/are rejected under 35 U.S.C. 103 as being unpatentable over Varghese in view of Dutt and Etchegoyen (US 20130167203 A1), hereinafter Etchegoyen.
Regarding Claim 17:
Varghese teaches a non-transitory computer-readable medium comprising executable instructions that, when executed by an electronic processor, cause an electronic processor to perform a set of operations comprising (Varghese – Paragraph [0024]: According to yet another embodiment of the present invention, a machine-readable medium is disclosed, the machine-readable medium having stored thereon a series of instructions which, when executed by a processing component, cause the processing component to detect anomalous data submitted to a software application): receiving a screening payload from a client platform, the screening payload identifying an authorization request (Varghese – Paragraph [0052]: In one set of embodiments, the various fraud detection, monitoring, and authentication processes of the present invention are implemented using a client/server type architecture (or, more generally, a distributed systems architecture); and Paragraph [0071]: Generally speaking, embodiments of the present invention provide techniques for determining whether requests (e.g., authentication requests, transaction requests, etc.) submitted by users of a software application (e.g., online shopping application, online banking application, etc.) are fraudulent and/or malicious. In an embodiment, a copy of the request or information included in the request is received), the screening payload generated by a screening device (Varghese – Paragraph [0110]: At step 402, a request is received at a service provider server from a user device 720 (FIG. 13A), for example, for data resident thereon. The fingerprinting process is invoked and information describing the request is transferred. The user device may be a personal computer 720 as in FIG. 13A, a cell phone, personal data assistant (PDA), automated teller machine (ATM), or other suitable device capable of accessing a server. Preferably, the service provider server is a web server accessible from the user device via the Internet, or other public network, or a private network; and Paragraph [0111]: At step 404, device identity information for the user device is captured. This information can be captured by a client program already resident on the user device. For Internet applications, the client program is commonly a web browser. Alternatively, a software module can be downloaded to the user device and executed to gather identifying information. For Internet applications, the software module can be a plug-in, a script, or an applet (e.g., a Java applet) downloaded by the web browser and executed; Examiner’s Comment: the user device is interpreted as the claimed screening device and the client through which the authentication requests are processed is interpreted as the claimed client platform); identifying a stored enhanced authorization request corresponding to the identified authorization request (Varghese – Paragraph [0162]: As described above, embodiments of the present invention provide techniques for detecting whether a request (e.g., authentication request, transaction request, etc.) submitted by a user of a service provider application (e.g., online shopping application, online banking application, etc.) is likely to be fraudulent and/or malicious; and Paragraph [0166]: As shown in step 1804, the first application fingerprint is associated with one or more first contexts representing contexts in which the first data was submitted. These contexts serve to correlate the first application fingerprint with other, previously submitted application fingerprints. The one or more first contexts may include, for example, a user context identifying a user that submitted the first data, a device context identifying a device used to submit the first data, a location context identifying a location from which the first data was submitted, a workflow context identifying a workflow that was being performed when the first data was submitted, and/or the like; and Paragraph [0168]: Once the first application fingerprint has been generated, the first application fingerprint is compared with at least one second application fingerprint (step 1806). The second application fingerprint is based on second data previously submitted via the input field, and is associated with one or more second contexts substantially similar to the one or more first contexts. In other words, the second application fingerprint is a signature of historical data that was previously submitted to the application under the same or similar circumstances (e.g., by the same user, from the same device, from the same location, during the same workflow, etc.) as the first data), the stored enhanced authorization request including first device characteristics (Varghese – Paragraph [0162]: As described above, embodiments of the present invention provide techniques for detecting whether a request (e.g., authentication request, transaction request, etc.) submitted by a user of a service provider application (e.g., online shopping application, online banking application, etc.) is likely to be fraudulent and/or malicious; and Paragraph [0166]: As shown in step 1804, the first application fingerprint is associated with one or more first contexts representing contexts in which the first data was submitted. These contexts serve to correlate the first application fingerprint with other, previously submitted application fingerprints. The one or more first contexts may include, for example, a user context identifying a user that submitted the first data, a device context identifying a device used to submit the first data, a location context identifying a location from which the first data was submitted, a workflow context identifying a workflow that was being performed when the first data was submitted, and/or the like; and Paragraph [0168]: Once the first application fingerprint has been generated, the first application fingerprint is compared with at least one second application fingerprint (step 1806). The second application fingerprint is based on second data previously submitted via the input field, and is associated with one or more second contexts substantially similar to the one or more first contexts. In other words, the second application fingerprint is a signature of historical data that was previously submitted to the application under the same or similar circumstances (e.g., by the same user, from the same device, from the same location, during the same workflow, etc.) as the first data).
Varghese does not expressly teach identifying a device on a network having second device characteristics, the second device characteristics matching the first device characteristics; determining a location of the identified device; and transmitting the location of the identified device to the screening device.
However, Dutt teaches identifying a device on a network having second device characteristics, the second device characteristics matching the first device characteristics (Dutt – Figure 4A: illustration of a process for authenticating a transaction; and Paragraph [0103]: In the following example, one of the primary characteristics analyzed is location. During initiation of the transaction the user device provides first location information on the location of the first user device, and the server at the transaction site transmits transaction information necessary for the transaction to the transaction server … The transaction server calls an authentication device and the authentication device requests second location information defining the location of a second user device associated with the transaction from location information servers 1 to N, each at one of N communications service provider sites where N is an integer with N>1. The location information server of the communications service provider that provides communications services to the second user device provides a response containing the second location information; and Paragraph [0104]: Responsive to receiving the second location information, the authentication server performs location authentication by determining a level of correlation between the first location and the second location and authenticates the transaction based on the level of correlation between the first location and the second location); determining a location of the identified device (Dutt – Paragraph [0103]: During initiation of the transaction the user device provides first location information on the location of the first user device, and the server at the transaction site transmits transaction information necessary for the transaction to the transaction server. The information includes, among other information, the first location information on the user device, together with a phone number of the user, for example. As discussed above, in some implementations the information includes additional characteristic information related to the first user device. The transaction server calls an authentication device and the authentication device requests second location information defining the location of a second user device associated with the transaction from location information servers 1 to N, each at one of N communications service provider sites where N is an integer with N>1), and transmitting [the location of the identified device] to the screening device (Dutt – Paragraph [0104]: A verification request is sent to the second user device in response to the location authentication requesting user credentials. In some implementations the user credentials include a PIN (Personal Identification Number), implicit information, or biometric information. Biometric information can include reading fingerprints, iris scans, temperature, pulse rate, facial recognition as well as other methods. Responsive to receiving the authentication request the user credentials are entered and a reply containing the user credentials is transmitted to the authentication device. The user credentials are authenticated and the authentication device transmits a message to the second user device indicating that the authentication has been verified; and Figure 8 with corresponding description in Paragraphs [0162]-[0167]: [0162] An example of the implementation of the fraud detection system and resolution management system can be seen in FIG. 8. In this example, a third party payment gateway is integrated with the system to enable credit processing. In some embodiments, the payment gateway may be part of the fraud verification and resolution management system.[0163] The user logins in (1) to the system (payment gateway) using a mobile device as their device (la) and registers with the system server (Fraud Detection Unit). The user sets their preferences regarding notifications and financial security with the system server (2).[0164] These settings are passed on to the payment gateway authentication database of the payment gateway (3).[0165] If a transaction is flagged by the payment gateway, a notification is sent to the Fraud Detection Unit utilizing an application programming interface (4). In some embodiments, the flag is stored on the payment gateway database (4a) prior to the flag being pushed to the fraud detection unit (4b).[0166] The fraud detection unit, receiving the flag from the payment gateway, pushes the flag to the user via rich push notifications (5). The user device receives the notification (6) and the transaction information is downloaded or viewed on the user device (7).[0167] The user may input a secondary password to authenticate (8), and the corresponding user selected action (e.g., allow/prevent/flag) is pushed to the fraud detection unit. This response is sent from the Fraud Detection Unit to the payment gateway (10a) and recorded in the database within the payment gateway (10b)).
It would have been obvious before the effective filing date of the claimed invention to a person having ordinary skill in the art to modify Varghese, further incorporating Dutt to arrive at the conclusion of the claimed invention. One would be motivated to incorporate Dutt’s teaching of confirming user intent via push notification in the event that a requesting device location sufficiently matches with a known user device location into Varghese’s system for comparing incoming requests with historical requests. This combination would enable real-time user confirmation for authorizing requests based on user preferences.
The combination of Varghese and Dutt does not expressly teach and transmitting the location of the identified device to the screening device.
However, Etchegoyen teaches and transmitting the location of the identified device to the screening device (Etchegoyen – Paragraph [0010]: An exemplary embodiment of the invention may be realized as a system for authorizing a request for remote access to customer account information. The system generally includes a server configured to receive the request via a network from a remote computing device, a database storing the customer account information accessible by the server, and memory accessible by the server. The memory stores a customer notification program which, when executed by the server, performs steps for (a) identifying, responsive to the server receiving the request, the remote computing device by a device fingerprint and by a requesting location, (b) determining whether the device fingerprint matches any of a number of device fingerprints authorized to access the customer account information, and (c) sending, responsive to determining a mismatch between the device fingerprint and each of the previously authorized device fingerprints, a notification of the request to a customer-specified address, the notification indicating (i) the request, (ii) identity of the remote computing device, and (iii) the requesting location).
It would have been obvious before the effective filing date of the claimed invention to a person having ordinary skill in the art to modify Varghese and Dutt, further incorporating Etchegoyen to arrive at the conclusion of the claimed invention. One would be motivated to incorporate Etchegoyen’s teaching to alert a user of a suspected fraudulent access request and include the location of the requesting device in the alert into Varghese and Dutt’s system for comparing incoming requests with historical requests. These additional considerations provide a user with more context into the request that caused the alert in order for the user to either confirm the activity as fraud or confirm the request and avoid triggering a similar alert in the future.
Regarding Claim 18:
The combination of Varghese, Dutt, and Etchegoyen teaches the non-transitory computer-readable medium of claim 17.
Varghese further teaches wherein the stored enhanced authorization request includes a historical authorization request submitted by a historical device (Varghese – Paragraph [0051]: FIG. 13A is a simplified block diagram illustrating a first system environment in accordance with an embodiment of the present invention. The system environment includes one or more service provider servers 1302, 1304 and an authentication server 1306. Servers 1302, 1304, 1306 are interconnected via network 710 to one or more user computing devices 720, which are used by end-users to submit various requests (e.g., login requests, transaction requests, etc.) to service provider applications A, B, C, D, etc. Servers 1302, 1304, 1306 are generally structured as known in the art, and include a CPU, volatile memory (e.g., RAM), disc-based or other nonvolatile memory, communication interfaces, optional user interface equipment, and the like. Database 1308 is communicatively coupled with authentication server 1306 and is configured to store data used in authentication processes, such as device, location, workflow, and application fingerprints/histories; and Paragraph [0064]: DCR process 1110 gathers the results of the current request authentication processing and stores them in a DCR database in association with the identifying information (for example, the Device ID) of the originating user device. These stored results may include, for example, whether or not the request was validated and/or whether or not the request was found to be fraudulent. In this manner, the DCR database can provide a historical record of the results of previous request authentication processing to guide FAAS 700 in future authentication request processing)) and at least one of static attributes of the historical device, dynamic attributes of the historical device, or hardware attributes of the historical device (Varghese – Table 4: table listing various hardware and software characteristics that may be associated with a historically observed device).
The motivation to combine the arts is the same as that of Claim 17.
Regarding Claim 19:
The combination of Varghese, Dutt, and Etchegoyen teaches the non-transitory computer-readable medium of claim 18.
Varghese further teaches wherein the set of operations further include generating a device fingerprint of the historical device based on at least one of the static attributes of the historical device, the dynamic attributes of the historical device, or the hardware attributes of the historical device (Varghese – Paragraph [0074]: The diagram includes the various request attributes of Table 2 (except for application data information). In an embodiment, the request attributes of the criteria are condensed into fingerprints--for example, a location fingerprint, a device fingerprint, a workflow fingerprint, and an application fingerprint (application fingerprinting is discussed in further detail below). The fingerprints are then processed to generate actions, risk alerts, and/or risk scores. One possible action is primary authentication, which is the process by which the user is initially identified and authenticated. Primary authentication is performed primarily based on location and device fingerprints, and can include presentation of one or more authentication interfaces at the user device. Another possible action is secondary authentication, which can be invoked during the post-authentication phase of a transaction if, for example, a particular piece of data submitted by the user appears to be malicious, thereby necessitating further authentication. Secondary authentication can include use of, for example, email, voiceprints, and/or the like; and Table 4: table listing various hardware and software characteristics that may be associated with a historically observed device).
The motivation to combine the arts is the same as that of Claim 17.
Regarding Claim 20:
The combination of Varghese, Dutt, and Etchegoyen teaches the non-transitory computer-readable medium of claim 18.
Dutt further teaches wherein the identified device and the historical device are a same device (Dutt – Figure 4A: illustration of a process for authenticating a transaction; and Paragraph [0103]: In the following example, one of the primary characteristics analyzed is location. During initiation of the transaction the user device provides first location information on the location of the first user device, and the server at the transaction site transmits transaction information necessary for the transaction to the transaction server … The transaction server calls an authentication device and the authentication device requests second location information defining the location of a second user device associated with the transaction from location information servers 1 to N, each at one of N communications service provider sites where N is an integer with N>1. The location information server of the communications service provider that provides communications services to the second user device provides a response containing the second location information; and Paragraph [0104]: Responsive to receiving the second location information, the authentication server performs location authentication by determining a level of correlation between the first location and the second location and authenticates the transaction based on the level of correlation between the first location and the second location; and Paragraph [0010]: In some embodiments of the invention, the first device and the second device are the same device; and Paragraph [0161]: As discussed above, the database in the fraud prevention system is used to look at historical transactions of all users to check for potential fraud, and then appropriate users are notified/alerted of potential fraudulent transactions on their account, via rich push notifications, email, phone, or SMS for example).
The motivation to combine the arts is the same as that of Claim 17.
Conclusion
The prior art made of record and not relied upon is considered pertinent to applicant's disclosure.
Senecal et al. (US 20240039912 A1) teaches a method for authenticating resource access requests based on device fingerprinting and comparing an incoming request to characteristics of historical requests
Cockerill et al. (US 20190141030 A1) teaches a method for authorizing an access request based on device fingerprint matching
Kim et al. (US 20250337724 A1) teaches methods and systems for using partial cookies to facilitate authorization of access requests
Walters et al. (US 20200226605 A1) teaches systems and methods for monitoring device and transaction activity in order to detect abnormalities in new requests
Cheek et al. (US 20210136063 A1) teaches a system for identifying suspicious logins based on device history and user preferences
Pennella et al. (US 20080226142 A1) teaches a system for device-based authentication in which a user configures security settings for devices associated with varying levels of account access or security clearance
Ferenczi et al. (US 20180375955 A1) teaches techniques for integrating device-identifying code into a webpage for performing transactions in which device characteristics are compared to known/historical devices during transaction processing
Any inquiry concerning this communication or earlier communications from the examiner should be directed to NICHOLAS JOSEPH DILUZIO whose telephone number is (703)756-1229. The examiner can normally be reached Mon - Fri -- 7:30 AM - 5 PM.
Examiner interviews are available via telephone, in-person, and video conferencing using a USPTO supplied web-based collaboration tool. To schedule an interview, applicant is encouraged to use the USPTO Automated Interview Request (AIR) at http://www.uspto.gov/interviewpractice.
If attempts to reach the examiner by telephone are unsuccessful, the examiner’s supervisor, Yin-Chen Shaw can be reached at 571-272-8878. 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.
/NICHOLAS JOSEPH DILUZIO/Examiner, Art Unit 2498
/YIN CHEN SHAW/Supervisory Patent Examiner, Art Unit 2498
Prosecution Insights