DETAILED ACTION
Status of Claims
This is a first office action on the merits in response to the application filed on 24 March 2025.
Claim 1 was cancelled via preliminary amendment received 20 May 2025.
Claims 2-20 are currently pending and have been considered by the examiner.
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 .
Information Disclosure Statement
The information disclosure statement (IDS) submitted on 24 March 2025 was filed considered by the examiner.
Double Patenting
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 conflicting claims 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); 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 nonstatutory double patenting provided the reference application or patent either is shown to be commonly owned with the examined application, or claims an invention made as a result of activities undertaken within the scope of a joint research agreement. See MPEP § 717.02 for applications subject to examination under the first inventor to file provisions of the AIA as explained in MPEP § 2159. See MPEP § 2146 et seq. for applications not subject to examination under the first inventor to file provisions of the AIA . A terminal disclaimer must be signed in compliance with 37 CFR 1.321(b).
The USPTO Internet website contains terminal disclaimer forms which may be used. Please visit www.uspto.gov/patent/patents-forms. The filing date of the application in which the form is filed determines what form (e.g., PTO/SB/25, PTO/SB/26, PTO/AIA /25, or PTO/AIA /26) 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 www.uspto.gov/patents/process/file/efs/guidance/eTD-info-I.jsp.
Claim 2-20 are rejected on the ground of nonstatutory double patenting as being unpatentable over claims of U.S. Patent No. 12293355. Although the claims at issue are not identical, they are not patentably distinct from each other because the claims recite (emphasized):
US Pat. No. 12293355
Present Application (19087985)
Claim 1
Claim 2
A computer-implemented method, comprising: receiving client information, wherein when the client information is received from a client device via a modal on the client device, the modal is automatically generated; receiving, at an account security system having one or more processors, a status inquiry associated with a secure transaction, a merchant system, and a closure of the modal on a client device;
automatically processing the status inquiry in real-time to determine that the merchant system has been previously validated and that the status inquiry is from the merchant system;
verifying the status inquiry using a machine learning model, wherein the machine learning model is trained to identify one or more patterns in status queries, wherein the patterns are associated with fraud, and wherein the machine learning model is trained to generate fraud alerts when fraudulent patterns are identified; generating a tokenized client account number using the client information, wherein generating is based on verifying the status inquiry;
accessing data including the tokenized client account number, wherein accessing is part of a real-time automatic response to the determination that the merchant system has been previously validated; sharing the tokenized client account number with a separate system to allow the merchant system to settle payment for the secure transaction with the separate system without the merchant system having access to the client information; and
automatically transmitting the data in real time, wherein when the data is associated with a push system, the data is pushed to a merchant uniform resource locator, wherein the data includes the tokenized client account number, and wherein the tokenized client account number facilitates processing of the secure transaction by the merchant system without the merchant system having access to the client information.
A computer-implemented method, comprising: receiving, at an account security system with one or more processors, a status inquiry associated with a secure transaction, a merchant system, and a client device involved in the secure transaction;
automatically processing the status inquiry to determine that the merchant system has been previously validated and that the status inquiry is from the merchant system;
verifying the status inquiry using a machine learning model, wherein the machine learning model is trained to identify one or more patterns in status queries, wherein the one or more patterns are associated with fraud, and wherein the machine learning model is trained to generate fraud alerts when fraudulent patterns are identified;
accessing postback data including a tokenized client account number associated with client information and associated with the secure transaction, wherein accessing is based on verification of the status inquiry, and wherein the tokenized client account number facilitates the merchant system being isolated from sensitive client information used to generate the tokenized client account number; and
automatically transmitting data in real time, wherein the data includes the tokenized client account number, and wherein the tokenized client account number facilitates processing of the secure transaction by the merchant system without the merchant system having access to the client information.
As highlighted in the above comparison, claim 1 of U.S. Patent No. 12293355 fully anticipates claim 2 of the present application. Therefore, it can be concluded that the invention of the present application is patentably indistinct from the invention claimed in U.S. Patent No. 12293355.
Accordingly, claim 2 of the present application be rejected under the nonstatutory double patenting doctrine.
Additionally, claims 3-9, 11-13, and 15-20 and of the present application recite similar limitations and are anticipated by limitations recited in claims 2-5, 7-10, and 12-15 of U.S. Patent No. 12293355 and thus claims 3-9, 11-13, and 15-20 are rejected under the nonstatutory double patenting doctrine
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 2-20 are rejected under 35 U.S.C. 101 because the claimed invention is directed to an abstract idea without significantly more.
In the instant case, claim 2-9 are directed towards a method, claims 14-20 are directed to a system/apparatus, and claim 10-13 are directed towards a non-transitory computer readable medium. Therefore, these claims fall within the four statutory categories of invention.
Claim 2 recites the following:
A computer-implemented method, comprising:
receiving, at an account security system with one or more processors, a status inquiry associated with a secure transaction, a merchant system, and a client device involved in the secure transaction;
automatically processing the status inquiry to determine that the merchant system has been previously validated and that the status inquiry is from the merchant system;
verifying the status inquiry using a machine learning model, wherein the machine learning model is trained to identify one or more patterns in status queries, wherein the one or more patterns are associated with fraud, and wherein the machine learning model is trained to generate fraud alerts when fraudulent patterns are identified;
accessing postback data including a tokenized client account number associated with client information and associated with the secure transaction, wherein accessing is based on verification of the status inquiry, and wherein the tokenized client account number facilitates the merchant system being isolated from sensitive client information used to generate the tokenized client account number; and
automatically transmitting data in real time, wherein the data includes the tokenized client account number, and wherein the tokenized client account number facilitates processing of the secure transaction by the merchant system without the merchant system having access to the client information.
Regarding Step 2A Prong One, the claims recite the abstract idea of risk mitigation. Specifically, the claims recite the limitations underlined above which recite the process of mitigating risk associated with an economic transaction which is grouped within the Certain Methods of Organizing Human Activity grouping of abstract ideas in prong one of step 2A of the Alice/Mayo test (See MPEP § 2106.04) because the claims involve the process of mitigating risk. Accordingly, the claims recite an abstract idea (See pages 7, 10, Alice Corporation Pty. Ltd. v. CLS Bank International, et al., US Supreme Court, No. 13-298, June 19, 2014; 2019 Revised Patent Subject Matter Eligibility Guidance, 84 Fed. Reg. 50, 53-54 (January 7, 2019)).
Regarding Step 2A Prong Two, the recited abstract idea is not integrated into a practical application because, when analyzed under prong two of step 2A of the Alice/Mayo test (See MPEP § 2106.04(d)), the additional element(s) of the claim(s) such as a “processor”, “device”, and “machine learning model” merely use(s) a computer as a tool to perform an abstract idea. Specifically, the “processor”, “device”, and “machine learning model” perform(s) the steps or functions underlined above. The use of a processor/computer as a tool to implement the abstract idea does not integrate the abstract idea into a practical application because it requires no more than a computer performing functions that correspond to acts required to carry out the abstract idea. The additional elements do not involve improvements to the functioning of a computer, or to any other technology or technical field (MPEP 2106.05(a)), the claims do not apply or use the abstract idea to effect a particular treatment or prophylaxis for a disease or medical condition (Vanda Memo), the claims do not apply the abstract idea with, or by use of, a particular machine (MPEP 2106.05(b)), the claims do not effect a transformation or reduction of a particular article to a different state or thing (MPEP 2106.05(c)), and the claims do not apply or use the abstract idea in some other meaningful way beyond generally linking the use of the abstract idea to a particular technological environment, such that the claim as a whole is more than a drafting effort designed to monopolize the exception (MPEP 2106.05(e) and Vanda Memo). Therefore, the claims do not, for example, purport to improve the functioning of a computer. Nor do they effect an improvement in any other technology or technical field. Accordingly, the additional elements do not impose any meaningful limits on practicing the abstract idea, and the claims are directed to an abstract idea.
The claim(s) do not include additional elements that are sufficient to amount to significantly more than the judicial exception because, when analyzed under step 2B of the Alice/Mayo test (See MPEP § 2106.05), the additional element(s) of a “processor”, “device”, and “machine learning model” amounts to no more than using a computer or processor to automate and/or implement the abstract idea. As discussed above, taking the claim elements separately, the “processor”, “device”, and “machine learning model” perform(s) the steps or functions underlined above. These functions correspond to the actions required to perform the abstract idea. Viewed as a whole, the combination of elements recited in the claims merely recite risk mitigation. Therefore, the use of these additional elements does no more than employ the computer as a tool to automate and/or implement the abstract idea. The use of a computer or processor to merely automate and/or implement the abstract idea cannot provide significantly more than the abstract idea itself (MPEP 2106.05(I)(A)(f) & (h)). Therefore, the claim is not patent eligible.
Dependent claims 3-9, 11-13, and 15-20 further describe the recited abstract idea. The dependent claims do not include additional elements that integrate the abstract idea into a practical application or that provide significantly more than the abstract idea. Specifically:
Claim 3, 5, 9, 15, 17-18, 20 merely further describes the data analyzed when performing the recited abstract idea.
Claim 4, 16 recites the additional element of a generic database which fails to integrate the recited abstract idea into practical application nor amount to significantly more.
Claims 6, 11-12 merely further describes steps directed towards the recited abstract idea
Claims 7-8, 13, 19 recites additional steps which are also directed towards the recited abstract idea.
Therefore, as the dependent claims do not include additional elements that integrate the abstract idea into a practical application nor provide significantly more than the abstract idea, the dependent claims are also not patent eligible.
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) 2-20 is/are rejected under 35 U.S.C. 103 as being unpatentable over Senci (US 20180114203 A1) in view of Howe (US 20160110713 A1) in further view of Morris et al. (US 20190378010 A1).
Regarding Claim 2, Senci discloses:
A computer-implemented method, comprising:
receiving, at an account security system with one or more processors, a status inquiry associated with a secure transaction, a merchant system, and a client device involved in the secure transaction (See Senci: Para. [0037] – “To obtain current account data, merchant 24 enrolls in payment platform 20 and submits an update request to regulated ABU computing device 34. The update request may include one or more account identifiers, such as PANs, corresponding to cardholders 22 for which merchant 24 is requesting current payment card account data. The update request may also include one or more merchant identifiers corresponding to which merchant 24 is requesting current payment card account data.”);
automatically processing the status inquiry to determine that the merchant system has been previously validated and that the status inquiry is from the merchant system (See Senci: Para. [0045] – “For example, on receipt of the update request from merchant 24, regulated ABU computing device 34 may verify the update request by determining whether merchant 24 has prior approved transactions, stored in fraud information data source 42, corresponding to accountholder's 22 payment card account data”);
accessing postback data including a client account number associated with client information and associated with the secure transaction, wherein accessing is based on verification of the status inquiry (See Senci: Para. [0045] – “However, if prior approved payment card transactions are present between merchant 24 and accountholder 22, then regulated ABU computing device 34 may determine that merchant 24 is verified and allow the update request, providing the current payment card account data to merchant 24”; See Senci: Par [0036] – “For each payment card account of cardholder 22, account information data source 38 may include account data including, but not limited to, an account identifier such as a PAN, an expiration date, and a business identification number (BIN) identifying issuer 30”), and
automatically transmitting data in real time (See Senci: Para. [0045]), wherein the client account number facilitates processing of the secure transaction by the merchant system (See Senci: Fig. 1 – Transaction submitted between Network 28 and Issued 30)
However, Senci fails to explicitly disclose:
Wherein the client account number is tokenized
wherein the tokenized client account number facilitates the merchant system being isolated from sensitive client information used to generate the tokenized client account number
Processing the secure transaction by the merchant system without the merchatn system having access to the client information
However, in a similar field of endeavor, Howe discloses:
Wherein the client account number is tokenized (See Howe: Fig. 5 - Steps 502 - 510, See Howe: Para. [0047-0048] - "In step 502, the receiving unit 202 of the processing server 102 may receive a transaction message. The transaction message may be formatted pursuant to one or more standards governing the interchange of transaction messages and may include at least an indicated recipient, and may also include one or more tokens or data values In step 510, the processing unit 204 may generate and/or identify a token for each of the data values" - It is clear to one of ordinary skill in the art that transaction message, formatted pursuant to one or more standards governing the interchange of transaction messages, would include at least account data analogous to the
claimed client account number)
wherein the tokenized client account number facilitates the merchant system being isolated from sensitive client information used to generate the tokenized client account number and Processing the secure transaction by the merchant system without the merchant system having access to the client information (See Howe: Fig. 5 - Steps 504-506, 518-520, and 516, See Howe Para. [0050] - "If, in step 506, the processing unit 204 determines that tokens are included in the transaction message, then, in step 518, the processing unit 204 may identify corresponding token profiles 210 in the token database 208. The corresponding token profiles 210 may be token profiles 210 that include the token and include an associated data element that corresponds to the data element in the transaction message in which the respective token was stored. In step 520, the processing unit 204 may swap the tokens in the data elements in the transaction message for the corresponding data value included in the identified token profiles 210. In step 516, the transmitting unit 206 may forward the transaction message to the processing entity 110 using the payment network", See Howe: Para. [0023] - "The consumer 106 may provide data to a computing device 108. The computing device 108 may be a point of sale device or other type of computing device configured to communicate with the payment network 104 and transmit data")
Therefore, it would have been obvious to one of ordinary skill in the art at the time of the effective filing date to substitute the retrieved client account number disclosed by Senci for the tokenized client information including a tokenized client account number as disclosed by Howe yielding the predictable improvement of an increase in security strength by leveraging the well- known benefits of data tokenization ensuring that only required parties are able to access plaintext consumer data.
However, the combination of Senci and Howe fails to explicitly disclose:
verifying the status inquiry using a machine learning model, wherein the machine learning model is trained to identify one or more patterns in status queries, wherein the one or more patterns are associated with fraud, and wherein the machine learning model is trained to generate fraud alerts when fraudulent patterns are identified;
However in similar field of endeavor, Morris discloses:
verifying the status inquiry using a machine learning model, wherein the machine learning model is trained to identify one or more patterns in status queries, wherein the one or more patterns are associated with fraud, and wherein the machine learning model is trained to generate fraud alerts when fraudulent patterns are identified (See Morris: Para. [0082] – “In step 610, the system may use historical data (e.g., historical fraud data, known vulnerabilities, and/or emerging fraud patterns) and compare such historical data to the received data from step 602 and/or the output/analysis from either or both steps 604 and 606 and/or the anomalies determined in step 608. Such a comparison may be made using a conventional computing device and/or a machine learning model (e.g., the same or a different machine learning model as compared to the model used in steps 604 and 608). Entities may, individually and/or as related, not necessarily suggest an anomaly; however, historical data (e.g., a history of a device always being used fraudulently) may suggest an anomaly. As one example, a stolen credit card may have been involved in a large number of fraudulent transactions, such that a subsequent transaction may appear legitimate but, with the benefit of historical context, be fraudulent as well. As another example, the machine learning model may cluster a first transaction with one or more other transactions and may determine that the cluster is an outlier when compared with other clusters (e.g., from prior transactions). The machine learning model may, based on such clustering activity, indicate a transaction is fraudulent.”);
Therefore, it would have been obvious to one of ordinary skill in the art before the effective filing date to utilize the fraud detection capabilities of the machine learning model disclosed by Morris to detect fraudulent activity patterns of the transactions disclosed by the combination of Senci and Howe, yielding the predictable result of an increase in the security strength of the invention.
Regarding Claims 4, 12, and 16 the combination discloses:
wherein generating a client token for the secure transaction in response to a checkout communication, the method further comprising: storing the client token in a database with additional postback data for the secure transaction (See Howe: Fig. 5 – Step 512 – Howe discloses storing generated tokens to be used for postback/as retrieved data for future transaction authorization).
Regarding Claims 5 and 17, the combination discloses:
wherein the status inquiry includes identifying codes or passwords associated with the secure transaction (See Senci: Para. [0042] – “Additionally, for each merchant 24, fraud information data source 42 may further store merchant fraud data. For example, fraud data for merchant 24 may include merchant velocity data, such as one or more of a date/time of chargeback per merchant 24, per merchant category code, and per merchant county.”).
Regarding Claims 6 and 18, the combination discloses:
wherein processing the status inquiry includes accessing an independent system to process data from the status inquiry (See Senci: Para. [0100] – “The systems and processes are not limited to the specific embodiments described herein. In addition, components of each system and each process can be practiced independent and separate from other components and processes described herein. Each component and process can also be used in combination with other assembly packages and processes.”).
Regarding Claims 7, 13, and 19 the combination discloses:
receiving an account communication associated with the secure transaction including a client token and the client information, wherein the account communication is associated with the merchant system, wherein the client token is associated with the secure transaction (See Howe: Para. [0047] – “In step 502, the receiving unit 202 of the processing server 102 may receive a transaction message. The transaction message may be formatted pursuant to one or more standards governing the interchange of transaction messages and may include at least an indicated recipient, and may also include one or more tokens or data values in data elements reserved for private use pursuant to the standards. In step 504, the processing unit 204 of the processing server 102 may determine who the recipient of the message is based on the data included in or accompanying the transaction message.”), and wherein the client information is not received from the merchant system (See Howe: Para. [0023] – “The consumer 106 may provide data to a computing device 108. The computing device 108 may be a point of sale device or other type of computing device configured to communicate with the payment network 104 and transmit data. The computing device 108 may receive the data from the consumer 106, such as by reading data encoded in a magnetic strip of a card, receiving data via near field communication from another computing device, receiving data input via one or more input devices, etc. The computing device 108 may then transmit the data to the payment network 104 in a transaction message, which may route the data to the processing server 102.”); and generating the tokenized client account number in response to the account communication (See Howe: Para. [0048] – “If the recipient of the message is the processing entity 110, then, in step 506, the processing unit 204 may determine if the data elements in the transaction message include tokens. If the data elements do not include tokens, and therefore include data values, then, in step 508, the processing unit 204 may decrypt the data values using a private key. In step 510, the processing unit 204 may generate and/or identify a token for each of the data values. Methods for generation of a token corresponding to a data value will be apparent to persons having skill in the relevant art.”).
Regarding Claim 8, the combination discloses:
further comprising authenticating the client device by confirming that the client device is not compromised (See Senci: para. [0068] – “Referring to FIG. 3, regulated ABU computing device 300 may correspond to device authenticator 250 shown in FIG. 2. Regulated ABU computing device 300 may be coupled to payment processor 240 or may be a separate computing device included in the system of FIG. 2, and may be connected to one or more of the other computing devices via the network 210. In this example, regulated ABU computing device 300 includes a receiver 310, an analyzer 320, a processor 330, and a transmitter 340. Regulated ABU computing device 300 may include additional components not shown, or less than the amount of components shown. Also, one or more of the components in this example may be combined or may be replaced by processor 330. The computer components described herein (e.g., receiver 310; analyzer 320; processor 330; and transmitter 340) may include hardware and/or software that are specially configured or programmed to perform the steps described herein.”).
Regarding Claims 9 and 20, the combination discloses:
wherein the postback data is generated by the account security system using data from a modal presented on a client device as part of a merchant system website (See Howe: Para. [0070] – “The computer system 800 may further include a display interface 802. The display interface 802 may be configured to allow data to be transferred between the computer system 800 and external display 830. Exemplary display interfaces 802 may include high-definition multimedia interface (HDMI), digital visual interface (DVI), video graphics array (VGA), etc. The display 830 may be any suitable type of display for displaying data transmitted via the display interface 802 of the computer system 800, including a cathode ray tube (CRT) display, liquid crystal display (LCD), light-emitting diode (LED) display, capacitive touch display, thin-film transistor (TFT) display, etc.”).
Regarding Claims 11 and 15, the combination discloses:
wherein processing the status inquiry includes analyzing the status inquiry to confirm that the status inquiry includes valid field data indicating a valid request (See Senci: Para. [0018] – “In general, the regulated ABU computing device receives account data from one or more issuers and maintains the account data in an account information data source. The regulated ABU computing device may then receive update requests from requesting parties, which may include one or more merchants. The regulated ABU computing device then validates the update request using one or more validation rules. Based on the authorization, the regulated ABU computing device may allow the update request and return an update response containing the requested data, or the regulated ABU computing device may block the update request and return an update response containing a denial. Throughout this process, the regulated ABU computing device may record update request data. Additionally, the regulated ABU computing device may receive verification rules and also fraud information data for accounts and merchants. In certain embodiments, the regulated ABU computing device may also generate and transmit reports based on the verification rules applied.”).
Conclusion
Any inquiry concerning this communication or earlier communications from the examiner should be directed to NICHOLAS K PHAN whose telephone number is (571)272-6748. The examiner can normally be reached M-F 1 pm-9 pm EST.
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, Neha Patel can be reached at 571-270-1492. 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 K PHAN/Examiner, Art Unit 3699
Prosecution Insights