DETAILED ACTION
Status of Claims
This is a first office action on the merits in response to the application filed on 26 December 2025.
Claims 1-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 .
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.
Claims 1-20 are rejected on the ground of nonstatutory double patenting as being unpatentable over claims of U.S. Patent No. 12530665. Although the claims at issue are not identical, they are not patentably distinct from each other because the claims recite (emphasized):
US Pat. No. 12530665
Present Application (19433594)
Claim 1
Claim 1
A method of authenticating a transaction, the method comprising: receiving, by an authentication logic of a computing system from a third-party computing system, an authentication request regarding the transaction, wherein the authentication request comprises: an authentication code from a user device of a user, the authentication code including a cryptogram generated by a smart card and provided to the user device by the smart card via a first short-range wireless communication between the user device and the smart card, the smart card storing card information; and
payment information regarding a payment card, wherein the user device receives the payment information by a user input via a graphical user interface of the user device, and wherein the third-party computing system receives the authentication code via a first communication and the third-party computing system receives the payment information via a second communication;
authenticating, by the authentication logic of the computing system, the transaction by:
decoding the authentication code to reveal information and the cryptogram, the information comprising the card information;
validating the cryptogram by determining that the cryptogram was generated by the smart card; and
verifying that the payment card is the smart card by determining that the payment information at least partially matches the card information associated with the smart card; and
transmitting, based on authenticating the transaction, an authentication approval for the transaction, wherein the transaction is an online transaction with a third-party associated with the third-party computing system.
A method of authenticating a transaction, the method comprising: receiving, by a computing system from a third-party computing system, an authentication request regarding the transaction, wherein the authentication request comprises: an authentication code from a user device of a user, the authentication code including a cryptogram generated by a smart card and provided to the user device by the smart card via a first short-range wireless communication between the user device and the smart card; and
payment information regarding a payment card, wherein the user device receives the payment information by a user input via a graphical user interface of the user device;
authenticating, by the computing system, the transaction by:
decoding the authentication code to reveal information and the cryptogram, the information comprising card information associated with the smart card;
validating the cryptogram by determining that the cryptogram was generated by the smart card; and
verifying that the payment card is the smart card by determining that the payment information at least partially matches the card information associated with the smart card; and
transmitting, based on authenticating the transaction, an authentication approval for the transaction.
As highlighted in the above comparison, claim 1 of U.S. Patent No. 12530665 fully anticipates claim 1 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. 12530665.
Accordingly, claim 1 of the present application be rejected under the nonstatutory double patenting doctrine.
Additionally, claims 2-7, 9-14, and 16-20 of the present application recite similar limitations and are anticipated by limitations recited in claims 2-6, 8-12, and 14-17 of U.S. Patent No. 12530665 and thus claims 2-7, 9-14, and 16-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 1-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, claims 1-7 are directed towards a method, claims 8-14 are directed to a system/apparatus, and claims 15-20 are directed towards a non-transitory computer readable medium. Therefore, these claims fall within the four statutory categories of invention.
Claim 1 recites the following:
A method of authenticating a transaction, the method comprising:
receiving, by a computing system from a third-party computing system, an authentication request regarding the transaction, wherein the authentication request comprises:
an authentication code from a user device of a user, the authentication code including a cryptogram generated by a smart card and provided to the user device by the smart card via a first short-range wireless communication between the user device and the smart card; and
payment information regarding a payment card, wherein the user device receives the payment information by a user input via a graphical user interface of the user device;
authenticating, by the computing system, the transaction by:
decoding the authentication code to reveal information and the cryptogram, the information comprising card information associated with the smart card;
validating the cryptogram by determining that the cryptogram was generated by the smart card; and
verifying that the payment card is the smart card by determining that the payment information at least partially matches the card information associated with the smart card; and
transmitting, based on authenticating the transaction, an authentication approval for the transaction.
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 authenticating a transaction to mitigate risk 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 associated with an economic transaction. 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 “computing system from a third-party computing system”, “user device”, “smart card”, and “graphical user interface” merely use(s) a computer as a tool to perform an abstract idea. Specifically, the “computing system from a third-party computing system”, “user device”, “smart card”, and “graphical user interface” 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 “computing system from a third-party computing system”, “user device”, “smart card”, and “graphical user interface” 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 “computing system from a third-party computing system”, “user device”, “smart card”, and “graphical user interface” 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 2-7, 9-14, and 16-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:
Claims 2-3, 6-7, 9-10, 13-14, 16-17, and 19-20 merely further recite limitations directed towards the recited abstract idea.
Claims 4, 11, and 18 merely further specifies when information is transferred between the systems when performing that recited abstract idea.
Claims 5 and 12 recite the additional element of a generically reciting contactless trip which does not place the recited abstract idea into practical application nor amount to significantly more.
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) 1, 4-8, 12-15 and 18-20 is/are rejected under 35 U.S.C. 103 as being unpatentable over Chamberot et al. (US 20190156340 A1) in view of Prakash et al. (US 20160092872 A1).
Regarding Claims 1, 8, and 15, Chamberot discloses:
A method of authenticating a transaction, the method comprising:
receiving, by a computing system from a third-party computing system, an authentication request regarding the transaction (See Chamberot: Para. [0108 – “The reader 2 thus transmits (E36) the ARQC cryptogram (and where appropriate the IDD information) to the bank server 3”]), wherein the authentication request comprises:
an authentication code from a user device of a user, the authentication code including a cryptogram generated by a smart card and provided to the user device by the smart card (See Chamerot: Para. [0106] – “(E34) a cryptogram (or cryptographic certificate) that includes a message authentication code (MAC), which code is typically encrypted using a cryptographic key stored in the smart card 1.”) via a first short-range wireless communication between the user device and the smart card (See Chamberot: Para. [0117] – “In this example, the external contacts 6 constitute an interface module enabling the smart card 4 (and more particularly the microprocessor 5) to set up communication, e.g. via contacts in this example, with an external entity such as the terminal 30 as described below with reference to FIG. 4. It can be understood that other types of interface module could equally well be envisaged, such as an interface module enabling contactless communication to be set up (e.g. including a radiofrequency (RF) antenna) between the smart card and an external terminal.”); and
payment information regarding a payment card, wherein the user device receives the payment information by a user input via a graphical user interface of the user device (See Chamberot: Para. [0151] – “The secret code may be a PIN code to be input by the user via the card reader 30 co-operating with the smart card 4 in order to authenticate the user during a transaction.”);
authenticating, by the computing system, the transaction (See Chamberot: Para. [0108] – “the bank server 3 that performs (E38) new analysis on the basis of the data it receives. This analysis E38 typically comprises performing a certain number of verifications in order to ensure that the transaction is valid.”); and
transmitting, based on authenticating the transaction, an authentication approval for the transaction (See Chamberot: Para. [0108] – “The reader 2 receives (E40) in response an encrypted ARPC message giving the issuer's decision. The reader 2 transmits (E42) this ARPC message to the payment card 1 in order to inform it of the decision taken by the issuer.”).
However, Chamberot fails to explicitly disclose:
decoding the authentication code to reveal information and the cryptogram, the information comprising card information associated with the smart card;
validating the cryptogram by determining that the cryptogram was generated by the smart card; and
verifying that the payment card is the smart card by determining that the payment information at least partially matches the card information associated with the smart card
However, in a similar field of endeavor, Prakash discloses:
decoding the authentication code to reveal information and the cryptogram, the information comprising card information associated with the smart card (See Prakash Para. [0076-0077] – “Upon receiving the authorization request message including the cryptogram (i.e. the transaction data encrypted with the selected encryption key), the server computer 110 may determine the transaction type and the risk policies associated with the transaction type. For example, the server computer 110 may determine that the transaction is an in person transaction and retrieve an in person encryption key (e.g., card-present LUK) for decrypting the cryptogram ... At step 222, the server computer 110 may determine whether the cryptogram is generated using the appropriate encryption key. If the server computer 110 can decrypt the cryptogram using the selected encryption key (e.g., the card-present encryption key in this exemplary embodiment), the server computer 110 may determine that the cryptogram is generated using the appropriate encryption key.”);
validating the cryptogram by determining that the cryptogram was generated by the smart card (See Prakash: Para. [0077] – “At step 222, the server computer 110 may determine whether the cryptogram is generated using the appropriate encryption key. If the server computer 110 can decrypt the cryptogram using the selected encryption key (e.g., the card-present encryption key in this exemplary embodiment), the server computer 110 may determine that the cryptogram is generated using the appropriate encryption key.”); and
verifying that the payment card is the smart card by determining that the payment information at least partially matches the card information associated with the smart card (See Prakash: Para. [0077] – “The server computer 110 may retrieve the decrypted transaction data. The server computer 110 may also retrieve sensitive user data identified by the token (e.g., an account number of the user) from a token vault.” – It is clear to one of ordinary skill in the art that the received payment token must be determined to partially match the associated payment data stored in the token vault in order to perform the disclosed retrieval of correct, corresponding payment data)
Therefore, it would have been obvious to one of ordinary skill in the art before the effective filing date to substitute the generic certain number of verifications disclosed by Chamberot for the series of verification including the steps of decoding, validating, and verifying disclosed by Prakash yielding the predictable result of an increase in the security strength of the invention by utilizing a more specific security methodology.
Regarding Claims 4, 11, and 18, the combination discloses:
wherein the third-party computing system receives the authentication code via a first communication (See Chamberot: Para. [0108 – “The reader 2 thus transmits (E36) the ARQC cryptogram (and where appropriate the IDD information) to the bank server 3”]) and the third-party computing system receives the payment information via a second communication (See Chamberot: Para. [0151] – “The secret code may be a PIN code to be input by the user via the card reader 30 co-operating with the smart card 4 in order to authenticate the user during a transaction.”).
Regarding Claims 5 and 12, the combination discloses:
wherein the first short-range wireless communication is a short-range wireless communication between a contactless chip of the smart card and the user device (See Chamberot: Para. [0117] – “In this example, the external contacts 6 constitute an interface module enabling the smart card 4 (and more particularly the microprocessor 5) to set up communication, e.g. via contacts in this example, with an external entity such as the terminal 30 as described below with reference to FIG. 4. It can be understood that other types of interface module could equally well be envisaged, such as an interface module enabling contactless communication to be set up (e.g. including a radiofrequency (RF) antenna) between the smart card and an external terminal.”).
Regarding Claims 6, 13, and 19, the combination discloses:
wherein the information revealed from the authentication code includes at least one of personal information or financial information relating to the user (See Prakash: Para. [0036] – “The payment token may include a payment token issuer identifier that may be a substitute for a real issuer identifier for an issuer. An authorization request message may also comprise additional data elements corresponding to “identification information” including, for example, a service code, a CW (card verification value), a dCW (dynamic card verification value), an expiration date, etc. An authorization request message may also comprise “transaction information,” such as any information associated with a current transaction (e.g., the transaction amount, merchant identifier, merchant location, etc.) as well as any other information that may be utilized in determining whether to identify and/or authorize a payment transaction” – Prakash discloses that the received authorization request includes user information comprising at least financial information relating to the user in the form of a payment token related to the user’s issuer and is thus broadly related to the user), the method further comprising: comparing the at least one of the personal information or the financial information relating to the user with user information stored in a database (See Prakash: Para. [0077] – “The server computer 110 may retrieve the decrypted transaction data. The server computer 110 may also retrieve sensitive user data identified by the token (e.g., an account number of the user) from a token vault” – Prakash discloses retrieving sensitive user data from a token vault identified by the token received in the authorization request. It is clear to one of ordinary skill in the art that for said process of retrieving to be performed correctly, the server computer must broadly compare the received token to the data entries in the token vault to correctly identify which user data to retrieve).
Regarding Claims 7, 14, and 20, the combination discloses:
verifying, based on a presence of the authentication code, that the smart card is present at a time of the transaction (See Chamberot: Para. [0089] – “In order to facilitate understanding the invention, there follows, with reference to FIG. 1, a description of an example of a payment transaction in compliance with the EMV protocol using a smart card 1 co-operating with an external reader (or terminal) 2. The reader 2 is suitable for communicating with a bank server 3 associated with the issuer of the smart card 1. In this example, the smart card 1 is a payment card and the reader 2 is a payment terminal.”; See Chamerot: Para. [0106] – “(E34) a cryptogram (or cryptographic certificate) that includes a message authentication code (MAC), which code is typically encrypted using a cryptographic key stored in the smart card 1.”).
Claim(s) 2-3, 9-10, and 16-17 is/are rejected under 35 U.S.C. 103 as being unpatentable over Chamberot in view of Prakash in further view of Kadaster et al. (US 20160148201 A1).
Regarding Claims 2, 9, and 16, the combination of Chamberot and Prakash discloses the method of claim 1 but fails to explicitly disclose:
wherein the authentication request is received as a transaction authorization request entailing a charge of less than one dollar, and
wherein the authentication request is processed as a transaction authorization request.
However, in a similar field of endeavor, Kadaster discloses:
wherein an authentication request is received as a transaction authorization request entailing a charge of less than one dollar (See Kadaster: Para. [0030] – “The non-instantaneous account authentication options may allow consumers that are not capable of utilizing an instantaneous authentication option or that do not wish to provide the information necessary for an instantaneous authentication option to utilize the authentication process. An exemplary non-instantaneous authentication option is a challenge-deposit-withdrawal (CDW) process. A CDW process includes the deposit or withdrawal of a small sum or sums to the bank account to be authenticated, and the consumer then provides the amount of the deposit or withdrawal to the authentication provider to demonstrate that they have access to the account”), and
wherein the authentication request is processed as a transaction authorization request (See Kadaster: Para. [0030] – “An exemplary non-instantaneous authentication option is a challenge-deposit-withdrawal (CDW) process. A CDW process includes the deposit or withdrawal of a small sum or sums to the bank account to be authenticated, and the consumer then provides the amount of the deposit or withdrawal to the authentication provider to demonstrate that they have access to the account. The bank account to be authenticated may be identified by the consumer by supplying the routing number and account number associated with the bank account”)
Therefore, it would have been obvious to one of ordinary skill in the art before the effective filing date to modify the authentication request, containing payment information, which is transmitted to an issuer as disclosed by the combination of Chamberot and Prakash to be transmitted and received as a small-sum transaction (less than one dollar) which is subsequently processed by the issuer as disclosed by Kadaster yielding the predictable result of a improvement of the invention’s economic viability by reducing the barrier to entry for use of the invention for potential users(See Kadaster: Para. [0030] – “The non-instantaneous account authentication options may allow consumers that are not capable of utilizing an instantaneous authentication option or that do not wish to provide the information necessary for an instantaneous authentication option to utilize the authentication process”)
Regarding Claims 3, 10, and 17, the combination discloses:
recognizing, based on a requested transaction amount of less than one dollar, that a transaction authorization request includes the authentication request (See Kadaster: Para. [0030] – “An exemplary non-instantaneous authentication option is a challenge-deposit-withdrawal (CDW) process. A CDW process includes the deposit or withdrawal of a small sum or sums to the bank account to be authenticated, and the consumer then provides the amount of the deposit or withdrawal to the authentication provider to demonstrate that they have access to the account” – Kadaster discloses performing an authorization based on the receipt of a CDW verification. It is known to one of ordinary skill in the art that CDW transactions are conventionally identified/differentiated by, at least, they’re abnormally small transaction amounts); and
applying, based on the transaction authorization request including the authentication request, a set of authentication rules to authenticate the authentication request (See Kadaster: Para. [0030] – “the consumer then provides the amount of the deposit or withdrawal to the authentication provider to demonstrate that they have access to the account. The bank account to be authenticated may be identified by the consumer by supplying the routing number and account number associated with the bank account. Alternatively, an image of a check may be provided by the consumer that includes the routing number and account number associated with the bank account” – Kadaster discloses applying a set of authentication rules in the form of consumer identification via routing and account number based on the receipt of an CDW authentication request).
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