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 .
DETAILED ACTION
1. This action is in response to the amendment and argument field on 6 April 2026.
2. Claim 10 has been cancelled.
3. Claims 1, 9, 11, 19 and 20 have been amended.
4. Claim 21 has been newly added.
5. Claims 1-9 and 11-21 remain Pending.
Responses to the Argument
6. The applicant’s arguments filed on 6 April 2026 are moot in view of new ground of rejection rendered.
Claim Rejections - 35 USC § 103
7. The following is a quotation of 35 U.S.C. 103 which forms the basis for all obviousness rejections set forth in this Office action:
A patent for a claimed invention may not be obtained, notwithstanding that the claimed invention is not identically disclosed as set forth in section 102, if the differences between the claimed invention and the prior art are such that the claimed invention as a whole would have been obvious before the effective filing date of the claimed invention to a person having ordinary skill in the art to which the claimed invention pertains. Patentability shall not be negated by the manner in which the invention was made.
Claims 1-9 and 11-21 are rejected under 35 U.S.C §103 as being unpatentable over Riffert et al. (US Publication No. 20210142335), hereinafter Riffert and in view of Harris et al. (US publication no. 20220269781), hereinafter, Harris.
Regarding claim 1:
receiving, via an application server, a first dataset (Riffert, ¶65, ¶32), intelligently analyze user behavior and identify users that may intend to commit fraudulent behavior. Trained machine learning models can look for different fraud attributes within previous data associated with the user to generate scores. The scores are not necessarily a single user score, but a collection of multiple scores corresponding to how probable it is that a user will commit multiple different types of inappropriate behavior. Based on the different types of behavior that are identified as being associated with a user, the friction service
determining, via the application server using a trained machine learning model, a first friction level, wherein the trained machine learning model has been trained to predict a friction level based on at least one dataset training data including a plurality of user inputs (Riffert, ¶19, abstract, ¶27) wherein, friction points to turn on/off may be determined dynamically based on a particular user and their scores. In this case, friction point(s) may be activated depending on which negative behavior attribute is identified by the machine learning algorithms. See also ¶34.
Riffert does not explicitly suggest, a plurality of user input data, a plurality of indications of digital extraction, a plurality of data related to time spent on a webpage or website, a plurality of data related to time to respond to a security device, and a plurality of data related to media content HTML manipulation; however, in a same field of endeavor Harris discloses this limitation (Harris, ¶30, ¶37, ¶58, ¶46).
generating, via the application server, a first security device based on the first friction level; and (Riffert, ¶32, Fig.2A).
causing, via the application server the first security device to be output via a graphical user interface ("GUI") (Riffert, ¶54, ¶35-36).
It would have been obvious to one of ordinary skill in the art at the time the invention was filed to include the method of determining user interaction/friction behavior of Riffert with the computing data related to time spent disclosed in Harris to identify whether user is a bot or not, stated by Harris at ¶30.
Regarding claim 2:
further comprising: receiving, via the application server, a request for user authentication; and upon receiving the request for user authentication, requesting the first dataset from a data storage (Riffert, ¶25).
Regarding claim 3:
further comprising: receiving, via the application server, one or both of a first user input associated with the first security device or a second dataset; based on the first user input or the second dataset, determining, via the trained machine learning model, a second friction level; generating, via the application server, a second security device based on one or both of the first friction level or the second friction level; and causing to output, via a GUI, the second security device (Riffert, ¶26-27).
Regarding claim 4:
wherein generating the second security device based on one or both of the first friction level or the second friction level further comprises: determining, via the application server, the second friction level is higher than the first friction level; and generating, via the application server, the second security device such that the second security device has a higher security level than the first security device (Riffert, ¶49).
Regarding claim 5:
wherein generating the second security device based on one or both of the first friction level or the second friction level further comprises: determining, via the application server, the second friction level is lower than the first friction level; and generating, via the application server, the second security device such that the second security device has a lower security level than the first security device (Riffert, ¶20).
Regarding claim 6:
further comprising: receiving, via the application server, one or both of a second user input associated with the second security device or a third dataset; based on the second user input or the third dataset, determining, via the trained machine learning model, a third friction level; generating, via the application server, a third security device based on at least one of the first friction level, the second friction level, or the third friction level; and causing to output, via a GUI, the third security device (Riffert, ¶18, ¶27).
Regarding claim 7:
further comprising: receiving, via the application server, a third user input associated with the third security device; and based on the third user input, initiating at least one protective measure via an analysis system (Riffert, ¶17, ¶28).
Regarding claim 8:
wherein the security device includes at least one of a Completely Automated Public Turing test to tell Computers and Humans Apart (“CAPTCHA”), a toggle, a button, or a code verification element (Riffert, ¶35).
Regarding claim 9:
wherein the dataset includes at least one of at least one user input, user input data, an indication of digital extraction, screenshare activity, time on page, time to respond to security device, response to a security device, or media content HyperText Markup Language (“HTML”) manipulation (Riffert, ¶29, ¶22).
Regarding claim 11:
at least one memory storing instructions (Riffert, ¶60).
and at least one processor operatively connected to the memory (Riffert, ¶58), and configured to execute the instructions to perform operations for dynamically generating a friction-based security device, the operations including: receiving, via an application server, a first dataset (Riffert, ¶65, ¶32), intelligently analyze user behavior and identify users that may intend to commit fraudulent behavior. Trained machine learning models can look for different fraud attributes within previous data associated with the user to generate scores. The scores are not necessarily a single user score, but a collection of multiple scores corresponding to how probable it is that a user will commit multiple different types of inappropriate behavior. Based on the different types of behavior that are identified as being associated with a user, the friction service
determining, via the application server using a trained machine learning model, a first friction level, wherein the trained machine learning model has been trained to predict a friction level based on at least one dataset training data including a plurality of user inputs (Riffert, ¶19, abstract, ¶27) wherein, friction points to turn on/off may be determined dynamically based on a particular user and their scores. In this case, friction point(s) may be activated depending on which negative behavior attribute is identified by the machine learning algorithms. See also ¶34.
Riffert does not explicitly suggest, a plurality of user input data, a plurality of indications of digital extraction, a plurality of data related to time spent on a webpage or website, a plurality of data related to time to respond to a security device, and a plurality of data related to media content HTML manipulation; however, in a same field of endeavor Harris discloses this limitation (Harris, ¶30, ¶37, ¶58, ¶46).
generating, via the application server, a first security device based on the first friction level; and (Riffert, ¶32, Fig.2A).
causing, via the application server the first security device to be output via a graphical user interface ("GUI") (Riffert, ¶54, ¶35-36).
It would have been obvious to one of ordinary skill in the art at the time the invention was filed to include the method of determining user interaction/friction behavior of Riffert with the computing data related to time spent disclosed in Harris to identify whether user is a bot or not, stated by Harris at ¶30.
Regarding claim 12:
the operations further comprising: receiving, via the application server, a request for user authentication; and upon receiving the request for user authentication, requesting the first dataset from a data storage (Riffert, ¶25).
Regarding claim 13:
the operations further comprising: receiving, via the application server, one or both of a first user input associated with the first security device or a second dataset; based on the first user input or the second dataset, determining, via the trained machine learning model, a second friction level; generating, via the application server, a second security device based on one or both of the first friction level or the second friction level; and causing to output, via a GUI, the second security device (Riffert, ¶26-27).
Regarding claim 14:
wherein generating the second security device based on one or both of the first friction level or the second friction level further comprises: determining, via the application server, the second friction level is higher than the first friction level; and generating, via the application server, the second security device such that the second security device has a higher security level than the first security device (Riffert, ¶49).
Regarding claim 15:
wherein generating the second security device based on one or both of the first friction level or the second friction level further comprises: determining, via the application server, the second friction level is lower than the first friction level; and generating, via the application server, the second security device such that the second security device has a lower security level than the first security device (Riffert, ¶20).
Regarding claim 16:
the operations further comprising: receiving, via the application server, one or both of a second user input associated with the second security device or a third dataset; based on the second user input or the third dataset, determining, via the trained machine learning model, a third friction level; generating, via the application server, a third security device based on at least one of the first friction level, the second friction level, or the third friction level; and causing to output, via a GUI, the third security device (Riffert, ¶18, ¶27).
Regarding claim 17:
the operations further comprising: receiving, via the application server, a third user input associated with the third security device; and based on the third user input, initiating at least one protective measure via an analysis system (Riffert, ¶17, ¶28).
Regarding claim 18:
wherein the security device includes at least one of a Completely Automated Public Turing test to tell Computers and Humans Apart (“CAPTCHA”), a toggle, a button, or a code verification element (Riffert, ¶35).
Regarding claim 19:
wherein the dataset includes at least one of at least one user input, user input data, an indication of digital extraction, screenshare activity, time on page, time to respond to security device, response to a security device, or media content HTML manipulation (Riffert, ¶22, ¶29).
Regarding claim 20:
receiving, via an application server, a request for user authentication (Riffert, ¶19).
upon receiving the request for user authentication, requesting a first dataset from a data storage (Riffert, ¶26).
determining, via the application server using a trained machine learning model, a first friction level based on the first dataset (Riffert, ¶65, ¶32), intelligently analyze user behavior and identify users that may intend to commit fraudulent behavior. Trained machine learning models can look for different fraud attributes within previous data associated with the user to generate scores. The scores are not necessarily a single user score, but a collection of multiple scores corresponding to how probable it is that a user will commit multiple different types of inappropriate behavior. Based on the different types of behavior that are identified as being associated with a user, the friction service.
wherein the trained machine learning model has been trained to predict a friction level based on at least one dataset (Riffert, ¶19, abstract) wherein, friction points to turn on/off may be determined dynamically based on a particular user and their scores. In this case, friction point(s) may be activated depending on which negative behavior attribute is identified by the machine learning algorithms. See also ¶34.
the trained machine learning model having been trained to learn associations between training data to identify an output, the training data including a plurality of: (Riffert, ¶27-28, abstract) wherein, friction points to turn on/off may be determined dynamically based on a particular user and their scores. In this case, friction point(s) may be activated depending on which negative behavior attribute is identified by the machine learning algorithms. See also ¶34.
Riffert does not explicitly suggest, at least one user input a plurality of user inputs, user input data a plurality of user input data, an indication a plurality of indications of digital extraction, a plurality of data related to screenshare activity, a plurality of data related to time on page, a plurality of data related to time to respond to security device, a plurality of responses to a plurality of security devices, and a plurality of data related to media content HTML manipulation, or responses to security devices; however, in a same field of endeavor Harris discloses this limitation (Harris, ¶30, ¶37, ¶58, ¶46).
generating, via the application server, a first security device based on the first friction level; causing to output, via the application server a GUI, the first security device to be output via a GUI (Riffert, ¶64, ¶34-35).
receiving, via the application server, one or both of a first user input associated with the first security device or a second dataset (Riffert, ¶20), wherein New data may be received from the host platform that hosts the online resource where the user is interacting.
based on the first user input or the second dataset, determining, via the trained machine learning model, a second friction level (Riffert, ¶29, ¶34).
generating, via the application server, a second security device based on one or both of the first friction level or the second friction level (Riffert, ¶32, Fig.2A).
and causing to output, via the application server a GUI, the second security device to be output via the GUI (Riffert, ¶54, ¶35-36).
It would have been obvious to one of ordinary skill in the art at the time the invention was filed to include the method of determining user interaction/friction behavior of Riffert with the computing data related to time spent disclosed in Harris to identify whether user is a bot or not, stated by Harris at ¶30.
Regarding claim 21:
wherein generating the second security device based on one or both of the first friction level or the second friction level further comprises: generating, via the application server, the second security device such that the second security device has a higher security level than the first security device where the second friction level is determined to be higher than the first friction level; or generating, via the application server, the second security device such that the second security device has a lower security level than the first security device where the second friction level is determined to be lower than the first friction level (Riffert, ¶20, ¶34).
Conclusion
8. 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 extension fee 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 date of this final action.
The prior art made of record and not relied upon is considered pertinent to applicant’s disclosure (See form “PTO-892 Notice of reference cited).
Any inquiry concerning this communication or earlier communications from the examiner should be directed to MONJUR RAHIM whose telephone number is (571)270-3890.
If attempts to reach the examiner by telephone are unsuccessful, the examiner’s supervisor, Shewye Gelagay can be reached on 571-272-4219. The fax phone number for the organization where this application or proceeding is assigned is 571-273-8300.
Information regarding the status of an application may be obtained from the Patent Application Information Retrieval (PAIR) system. Status information for published applications may be obtained from either Private PAIR or Public PAIR. Status information for unpublished applications is available through Private PAIR only. For more information about the PAIR system, see http://pair-direct.uspto.gov. Should you have questions on access to the Private PAIR system, contact the Electronic Business Center (EBC) at 866-217-9197 (toll-free). If you would like assistance from a USPTO Customer Service Representative or access to the automated information system, call 800-786-9199 (IN USA OR CANADA) or 571-272-1000.
/Monjur Rahim/
Patent Examiner
United States Patent and Trademark Office
Art Unit: 2436; Phone: 571.270.3890
E-mail: monjur.rahim@uspto.gov
Fax: 571.270.4890
Prosecution Insights