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 responsive to: an original application filed on 12 August 2025.
2. Claims 1-20 are currently pending and rejected.
Information Disclosure Statement
3. The information disclosure statement (IDS) submitted on 27 August 2025. The submission is in compliance with the provisions of 37 CFR 1.97. Accordingly, the information disclosure statement is being considered by the examiner.
Priority
4. Priority date claimed has been noted.
Drawings
5. The drawings filed on 12 August 2025 are accepted by the examiner.
Double Patenting
6. The nonstatutory double patenting rejection is based on a judicially created doctrine grounded in public policy (a policy reflected in the statute) so as to prevent the unjustified or improper timewise extension of the “right to exclude” granted by a patent and to prevent possible harassment by multiple assignees. A nonstatutory double patenting rejection is appropriate where the claims at issue are not identical, but at least one examined application claim is not patentably distinct from the reference claim(s) because the examined application claim is either anticipated by, or would have been obvious over, the reference claim(s). See, e.g., In re Berg, 140 F.3d 1428, 46 USPQ2d 1226 (Fed. Cir. 1998); In re Goodman, 11 F.3d 1046, 29 USPQ2d 2010 (Fed. Cir. 1993); In re Longi, 759 F.2d 887, 225 USPQ 645 (Fed. Cir. 1985); In re Van Ornum, 686 F.2d 937, 214 USPQ 761 (CCPA 1982); In re Vogel, 422 F.2d 438, 164 USPQ 619 (CCPA 1970); and In re Thorington, 418 F.2d 528, 163 USPQ 644 (CCPA 1969).
A timely filed terminal disclaimer in compliance with 37 CFR 1.321(c) or 1.321(d) may be used to overcome an actual or provisional rejection based on a nonstatutory double patenting ground provided the reference application or patent either is shown to be commonly owned with this application, or claims an invention made as a result of activities undertaken within the scope of a joint research agreement. A terminal disclaimer must be signed in compliance with 37 CFR 1.321(b).
The USPTO internet Web site contains terminal disclaimer forms which may be used. Please visit http://www.uspto.gov/forms/. The filing date of the application will determine what form should be used. A web-based eTerminal Disclaimer may be filled out completely online using web-screens. An eTerminal Disclaimer that meets all requirements is auto-processed and approved immediately upon submission. For more information about eTerminal Disclaimers, refer to http://www.uspto.gov/patents /process/ file/efs/guidance /eTD-info-I.jsp.
Claims 1-20 are rejected under the grounds of non-statutory obviousness-type double patenting, as they are deemed unpatentable over claims 1-20 of US Patent application No. 17/661,429 and 18/760,564. Although the conflicting claims are not identical, they are considered not patentably distinct from one another, as they convey the same inventive concept. Specifically, both sets of claims disclose a method/system for training an Al engine for real-time monitoring of false positives during user registration. Furthermore, it would have been obvious to one of ordinary skill in the art, at the time of the invention’s filing, to employ this approach to prevent and protect data from hacking, thereby rendering the claims unpatentable.
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, 4-9, 12-16 and 19-20 are rejected under 35 U.S.C §103 as being unpatentable over Fuchs et al. (US Publication No. 20160063389), hereinafter Fuchs and in view of Straub et al. (US Publication No. 20160086262), hereinafter Straub.
Regarding claim 1:
A system for training an Al engine for real-time monitoring of false positives during user registration comprising: at least one processor (Fuchs, abstract, ¶42, ¶12), structure-learning systems and methods have a training phase and a classification phase. During the training phase, a tuple instance count data structure has been created based on the training dataset for the classification problem. In the classification phase, we classify an input using data counts from this trained tuple instance count data structure stored in memory. Unlike most supervised learning systems, these structure learning methods operate during the classification phase (i.e. work with records one at a time as they become available to be classified) to find partitions that make the classification process faster and more accurate.
a communication interface communicatively coupled to the at least one processor (Fuchs, Fig.9, ¶99), user interface input devices 938, user interface output devices 978, and a network interface subsystem 976. The input and output devices allow user interaction with computer system 910. Network interface subsystem 976 provides an interface to outside networks, including an interface to corresponding interface devices in other computer systems.
and a memory device storing executable code that, when executed, causes the processor to Fuchs, ¶103): receive a first set of data from at least one Al security model, wherein the data comprises input data from the at least one Al security model and output data from the at least one Al security model,
wherein the input data comprises data indicative of user registration, wherein the output data comprises a classification (Fuchs, ¶63, ¶40, ¶42, abstract), finding effective partitions makes use of the sets of features (and their counts) stored in the trained tuple instance count data structure described earlier. More generally, the tuple instance count data structure is trained on the set of (x.sub.1,x.sub.2, . . . ,x.sub.n,c) tuples that comprise the training set of the classification problem. Here, x.sub.i is the value of feature X.sub.i in the corresponding input and c is the input's class label and it can include hour of day when a user registered, day of week when a user registered, first name, last name, email address used for registration, email domain used for registration, email prefix used for registering and Tuple set with class labels 112 includes tuples generated from combinations of feature values in the record set 108 with a priori class labels. For instance, a tuple set may include 5 features: user registration first name, last name, third block of IP address, fourth block of IP address, and a class label. An example class label may be fraudulent or not, with class value c=1 for fraudulent or class value c=0 for not fraudulent—referring to whether the user registration has been previously determined to be fraudulent.
Fuchs does not explicitly suggest, receive a second set of data from a false positive database, wherein the false positive database comprises a list of false positive instances; however, in a same field of endeavor Straub discloses this limitation (Straub, ¶41, ¶60), technology may reduce false positives and increase the probability of identifying and stopping fraud based on a customized identity theft-based fraud score. According to an example implementation of the disclosed technology, a model may be utilized to process identity-related input information against reference information (for example, as obtained from one or more public or private databases) to determine whether the input identity being presented corresponds to a real identity, the correct identity, and/or a possibly fraudulent identity.
correlate the first set of data with the second set of data to create a correlated dataset from the correlated dataset, create a training dataset and a test dataset (Fuchs, Fig.4A, ¶33), makes use of a tuple instance count data structure stored in memory that delivers counts for structured records organized into features (that also could be properties, fields, objects or attributes.) The structured records in the data set include a class label. Typically feature values are assigned to the features, and a class value is assigned to the class label. Tuples are generated from one or more records of features (that also could be fields, objects or attributes) of a data set with values that occur sufficiently frequently; i.e. that have sufficient support to satisfy a minimum threshold. Thresholding is applied to manage the number of tuples generated.
use the training dataset to train a false positive identification model to identify false positives (Fuchs, ¶38, ¶48), Record sets 108, training set sub-tuples 104, and tuple sets with class labels 112 can store information from one or more tenants into tables of a common database image to form an on-demand database service, which can be implemented in many ways, such as a multi-tenant database system (MTDS). A database image can include one or more database objects.
and apply an Al engine to a user registration system, wherein the Al engine comprises an Al security model and the false positive identification model (Fuchs, ¶42), tuple set with class labels 112 includes tuples generated from combinations of feature values in the record set 108 with a priori class labels. For instance, a tuple set may include 5 features: user registration first name, last name, third block of IP address, fourth block of IP address, and a class label. An example class label may be fraudulent or not, with class value c=1 for fraudulent or class value c=0 for not fraudulent—referring to whether the user registration has been previously determined to be fraudulent.
Fuchs does not explicitly suggest, wherein the at least one Al security model is configured to compare user information to personally identifiable information from one or more public or private databases; however, in a same field of endeavor Straub discloses this limitation (Straub, ¶59-61), determine or estimate a probability of identity theft-based fraud based upon a set of parameters. In an example implementation, the parameters may be utilized to examine the input data, such as name, address and social security number, for example, to determine if such data corresponds to a real identity. In an example implementation, the input data may be compared with the reference data, for example, to determine field value matches, mismatches, weighting, etc. In certain example implementations of the disclosed technology, the input data (or associated entity record) may be scored to indicate the probability that it corresponds to a real identity.
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 false positive of Fuchs with the compare user information to personally identifiable information from one or more public or private databases disclosed in Straub to detect a potential fraudulent requests for payment or benefits, and may be utilized to cancel a payment or benefit to a potential fraudster stated by Straub at para.83.
Regarding claim 4:
wherein applying the AI engine further comprises: upon receiving the positive result from the AI security model, apply the false positive identification model; and receive a result from the false positive identification model, wherein the result may be a false result or a true result (Fuchs, ¶110).
Regarding claim 5:
wherein applying the AI engine further comprises: upon receiving the false result from the false positive identification model, allow user registration (Fuchs, ¶48).
Regarding claim 6:
wherein applying the AI engine further comprises: upon receiving the true result from the false positive identification model, block user registration (Fuchs, ¶48).
Regarding claim 7:
wherein extracting data from the user information comprises extracting personally identifiable information (Fuchs, ¶49).
Regarding claim 8:
Fuchs does not explicitly suggest, wherein applying the AI engine further comprises: determining a false positive rate, based on the false positive rate, triggering an alert to modify the at least one AI security model; however, in a same field of endeavor Straub discloses this limitation (Straub, ¶55).
Same motivation for combining the respective features of Fuchs and Straub applies herein, as discussed in the rejection of claim 1.
Regarding claim 9:
wherein modifying the AI security model comprises: retraining the AI security model, or selecting a new AI security model (Fuchs, ¶110).
Regarding claim 12:
wherein the false positive identification model comprises a Bayesian machine learning algorithm (Fuchs, abstract).
Regarding claim 13:
further comprising executable code that, when executed, causes the processor to perform unsupervised learning to further train the false positive identification model (Fuchs, ¶61).
Regarding claim 14:
wherein retraining the AI security model comprises: ingesting data wherein the data comprises the input data from the at least one AI security model, the output data from the at least one AI security model, and a third set of data from the false positive database; correlate the input data and the output data with the third set of data to create a second correlated dataset to create a second training dataset and a second test dataset; and use the second training dataset to re-train the false positive identification model to identify false positives (Fuchs, ¶50, ¶12-13).
Regarding claim 15:
wherein the data is pre-processed prior to ingestion (Fuchs, ¶33).
Regarding claim 16:
receiving a first set of data from at least one Al security model, wherein the data comprises input data from the at least one Al security model and output data from the at least one Al security model,
wherein the input data comprises data indicative of user registration, wherein the output data comprises a classification (Fuchs, ¶63, ¶40, ¶42, abstract), finding effective partitions makes use of the sets of features (and their counts) stored in the trained tuple instance count data structure described earlier. More generally, the tuple instance count data structure is trained on the set of (x.sub.1,x.sub.2, . . . ,x.sub.n,c) tuples that comprise the training set of the classification problem. Here, x.sub.i is the value of feature X.sub.i in the corresponding input and c is the input's class label and it can include hour of day when a user registered, day of week when a user registered, first name, last name, email address used for registration, email domain used for registration, email prefix used for registering and Tuple set with class labels 112 includes tuples generated from combinations of feature values in the record set 108 with a priori class labels. For instance, a tuple set may include 5 features: user registration first name, last name, third block of IP address, fourth block of IP address, and a class label. An example class label may be fraudulent or not, with class value c=1 for fraudulent or class value c=0 for not fraudulent—referring to whether the user registration has been previously determined to be fraudulent.
Fuchs does not explicitly suggest, receiving a second set of data from a false positive database, wherein the false positive database comprises a list of false positive instances; however, in a same field of endeavor Straub discloses this limitation (Straub, ¶41, ¶60), technology may reduce false positives and increase the probability of identifying and stopping fraud based on a customized identity theft-based fraud score. According to an example implementation of the disclosed technology, a model may be utilized to process identity-related input information against reference information (for example, as obtained from one or more public or private databases) to determine whether the input identity being presented corresponds to a real identity, the correct identity, and/or a possibly fraudulent identity.
correlating the first set of data with the second set of data to create a correlated dataset from the correlated dataset, create a training dataset and a test dataset (Fuchs, Fig.4A, ¶33), makes use of a tuple instance count data structure stored in memory that delivers counts for structured records organized into features (that also could be properties, fields, objects or attributes.) The structured records in the data set include a class label. Typically feature values are assigned to the features, and a class value is assigned to the class label. Tuples are generated from one or more records of features (that also could be fields, objects or attributes) of a data set with values that occur sufficiently frequently; i.e. that have sufficient support to satisfy a minimum threshold. Thresholding is applied to manage the number of tuples generated.
using the training dataset to train a false positive identification model to identify false positives (Fuchs, ¶38, ¶48), Record sets 108, training set sub-tuples 104, and tuple sets with class labels 112 can store information from one or more tenants into tables of a common database image to form an on-demand database service, which can be implemented in many ways, such as a multi-tenant database system (MTDS). A database image can include one or more database objects.
and applying an Al engine to a user registration system, wherein the Al engine comprises an Al security model and the false positive identification model (Fuchs, ¶42), tuple set with class labels 112 includes tuples generated from combinations of feature values in the record set 108 with a priori class labels. For instance, a tuple set may include 5 features: user registration first name, last name, third block of IP address, fourth block of IP address, and a class label. An example class label may be fraudulent or not, with class value c=1 for fraudulent or class value c=0 for not fraudulent—referring to whether the user registration has been previously determined to be fraudulent.
Fuchs does not explicitly suggest, wherein the at least one Al security model is configured to compare user information to personally identifiable information from one or more public or private databases; however, in a same field of endeavor Straub discloses this limitation (Straub, ¶59-61), determine or estimate a probability of identity theft-based fraud based upon a set of parameters. In an example implementation, the parameters may be utilized to examine the input data, such as name, address and social security number, for example, to determine if such data corresponds to a real identity. In an example implementation, the input data may be compared with the reference data, for example, to determine field value matches, mismatches, weighting, etc. In certain example implementations of the disclosed technology, the input data (or associated entity record) may be scored to indicate the probability that it corresponds to a real identity.
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 false positive of Fuchs with the compare user information to personally identifiable information from one or more public or private databases disclosed in Straub to detect a potential fraudulent requests for payment or benefits, and may be utilized to cancel a payment or benefit to a potential fraudster stated by Straub at para.83.
Regarding claim 19:
further comprising: upon receiving the positive result from the AI security model, applying the false positive identification model; receiving a result from the false positive identification model, wherein the result may be a false result or a true result; upon receiving the false result from the false positive identification model, allowing user registration; and upon receiving the true result from the false positive identification model, blocking user registration (Fuchs, ¶50, ¶12-13).
Regarding claim 20:
Fuchs does not explicitly suggest, wherein applying the AI engine further comprises: determining a false positive rate, based on the false positive rate, triggering an alert to modify the at least one AI security mode; however, in a same field of endeavor Straub discloses this limitation (Straub, ¶55).
Same motivation for combining the respective features of Fuchs and Straub applies herein, as discussed in the rejection of claim 1.
8. Claims 2-3, 10-11 and 17-18 are rejected under 35 U.S.C §103 as being unpatentable over Fuchs in view Straub and in view of Kyisuke Tomoda (US Publication No. 20210264299), hereinafter Tomoda.
Regarding claim 2:
Fuchs in view of Straub does not explicitly suggest, wherein applying the AI engine comprises: receive the user information from a user attempting to register a new account; upon receiving user information, extract data from the user information; apply the at least one AI security model to the extracted data; and receive a result from the at least one AI security model, wherein the result is either a negative result or a positive result; however in a same field of endeavor Tomoda teaches this limitation (Tomoda, ¶170-171, ¶7).
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 false positive of Fuchs in view of Straub with the compare user receive a result from the at least one AI security model, wherein the result is either a negative result or a positive result disclosed in Tomoda to identify relationships between comparison results of the blacklist items in Service A and Service B and the presence/absence of fraudulence in Service C. stated by Tomoda at para.112.
Regarding claim 3:
Fuchs in view of Straub does not explicitly suggest, wherein applying the AI engine further comprises: upon receiving the negative result from the AI security model, allow user registration; however in a same field of endeavor Tomoda teaches this limitation (Tomoda, ¶137).
Same motivation for combining the respective features of Fuchs in view Straub and Tomoda applies herein, as discussed in the rejection of claim 2.
Regarding claim 10:
Fuchs in view of Straub does not explicitly suggest, wherein the false positive identification model comprises a neural network; however, in a same field of endeavor Tomoda teaches this limitation (Tomoda, ¶57).
Same motivation for combining the respective features of Fuchs in view Straub and Tomoda applies herein, as discussed in the rejection of claim 2.
Regarding claim 11:
Fuchs in view of Straub does not explicitly suggest, wherein the neural network is selected from the group consisting of a convolution neural network (CNN), a recurrent neural network (RNN), and a feed-forward network; however, in a same field of endeavor Tomoda teaches this limitation (Tomoda, ¶108).
Same motivation for combining the respective features of Fuchs in view Straub and Tomoda applies herein, as discussed in the rejection of claim 2.
Regarding claim 17:
Fuchs in view of Straub does not explicitly suggest, further comprising: receiving the user information from a user attempting to register a new account; upon receiving user information, extracting data from the user information; applying the at least one AI security model to the extracted data; and receiving a result from the at least one AI security model, wherein the result is either a negative result or a positive result; however in a same field of endeavor Tomoda teaches this limitation (Tomoda, ¶170-171, ¶7).
Same motivation for combining the respective features of Fuchs in view Straub and Tomoda applies herein, as discussed in the rejection of claim 2.
Regarding claim 18:
Fuchs in view of Straub does not explicitly suggest, further comprising upon receiving the negative result from the AI security model, allowing user registration; however, in a same field of endeavor Tomoda teaches this limitation (Tomoda, ¶137).
Same motivation for combining the respective features of Fuchs in view Straub and Tomoda applies herein, as discussed in the rejection of claim 2.
Conclusion
9. The prior art made of record and not relied upon is considered pertinent to applicant’s disclosure. Any inquiry concerning this communication or earlier communications from the examiner should be directed to Monjour Rahim whose telephone number is (571)270-3890.
If attempts to reach the examiner by telephone are unsuccessful, the examiner’s supervisor, Shewaye 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 CANANDA) 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