DETAILED ACTION
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 statements (IDS) submitted on 12/20/2024 was in compliance with the provisions of 37 CFR 1.97. Accordingly, the information disclosure statement is being considered by the examiner.
Status of Claims
This action is in reply to the application filed on 12/20/2024, wherein:
Claims 1-4, 6-8, and 10-13 have been amended;
Claims 5, and 9 remain as original; and
Claims 1-13 are currently pending and have been examined.
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-13 are rejected under 35 U.S.C. 101 because the claimed invention is directed to an abstract idea without significantly more. The claims recite a method, server, and computer readable medium for using virtual cards in transactions which is considered a judicial exception because it falls under Certain Methods of Organizing Human Activity such as commercial or legal interactions, including sales activities or behaviors. This judicial exception is not integrated into a practical application as discussed below and the claims do not include additional elements that are sufficient to amount to significantly more than the judicial exception as discussed below.
This rejection follows the 2019 Revised Patent Subject Matter Eligibility Guidance, 84 Fed Reg 4, January 7, 2019, pp. 50-57 (“2019 PEG”)(MPEP 2106).
Analysis
Step 1 (Statutory Categories) – 2019 PEG pg. 53 (See MPEP 2106.03)
Claims 1-13 are directed to the statutory category of a process, machine, or manufacture.
Step 2A, Prong 1 (Do the claims recite an abstract idea?) – 2019 PEG pg. 54 (See MPEP 2106.04(a)-(c))
For independent claims 1, 12, and 13, the claims recite an abstract idea of: using virtual cards in transactions. The steps of independent claim 1 recite the abstract idea (in bold below) of: A computer-implemented method for enabling use of virtual cards in e-commerce transactions, the method performed by a tokenization server, the method comprising: receiving, from a user device, a transaction request corresponding to a transaction with a merchant; generating a virtual card number, VCN, which corresponds to a virtual card; generating and storing a cryptogram specific to the transaction with the merchant; providing the VCN to the merchant; obtaining an underlying funding primary account number, FPAN, of the virtual card; retrieving the cryptogram; checking the validity of the cryptogram; and providing an indication to the merchant if the cryptogram is valid or not valid. Independent claim 12 and 13 recite similar steps that recite the abstract idea. Independent claims 1, 12, and 13, as drafted, are a process that, under the broadest reasonable interpretation, covers Certain Methods of Organizing Human Activity, since they recite commercial or legal interactions, including sales activities or behaviors. If the claim limitations, under the broadest reasonable interpretation, covers methods of organizing human activity but for the recitation of additional elements including generic computer components, then it falls within the “Certain Methods of Organizing Human Activity” grouping of abstract ideas. Other than reciting the abstract idea, the independent claims recite additional elements including generic computer components such as “computer implemented, a virtual card, a tokenization server, a user device, a cryptogram, and a computer-readable medium comprising instructions executed by a processor”, and nothing in the claims precludes the steps from being performed as a method of organizing human activity. Accordingly, the independent claims recite an abstract idea.
Dependent claims 2-11 recite similar limitations as independent claims 1, 12, and 13; and when analyzed as a whole are held to be patent ineligible under 35 U.S.C 101 because the additional recited limitations only refine the abstract idea further. Other than reciting the abstract idea, the dependent claims recite similar additional elements including generic computer components as the independent claims, such as “computer implemented, the virtual card, the user device, a database, the cryptogram, and an API”. If a claim limitation, under its broadest reasonable interpretation, covers commercial or legal interactions, but for the recitation of generic computer components, then it falls within the “Certain Methods of Organizing Human Activity” grouping of abstract ideas.
Step 2A, Prong 2 (Does the claim recite additional elements that integrate the judicial exception into a practical application?) – 2019 PEG pg. 54 (See MPEP 2106.04(d)-(c))
This judicial exception is not integrated into a practical application. In particular, independent claims 1, 12, and 13 only recite the additional elements of “computer implemented, a virtual card, a tokenization server, a user device, a cryptogram, and a computer-readable medium comprising instructions executed by a processor”. A plain reading of the Figures and associated descriptions in the specification reveals that generic processors may be used to execute the claimed steps. The additional elements are recited at a high level of generality (i.e., as a generic processor performing generic computer functions) such that it amounts to no more than mere instructions to apply the exception using generic computer components (See MPEP 2106.05(f)) and limits the judicial exception to a particular environment (See MPEP 2106.05(h)). Mere instructions to apply an exception using a generic computer component and limiting the judicial exception to a particular environment doesn’t integrate the abstract idea into a practical application in Step 2A. Accordingly, these additional elements do not integrate the abstract idea into a practical application because it does not impose any meaningful limits on practicing the abstract idea. Hence, independent claims 1, 12, and 13 are directed to an abstract idea.
Dependent claims 2-11, recite similar additional elements as the independent claims including generic computer components, such as “computer implemented, the virtual card, the user device, a database, the cryptogram, and an API”. The judicial exception is not integrated into a practical application because the additional elements in the dependent claims are also recited at a high-level of generality such that it amounts to more no more than mere instructions to apply the exception using generic computer components. Therefore, the additional elements do not integrate the abstract idea into a practical application because they also do not impose any meaningful limits on practicing the abstract idea. Also, the claims do not affect an improvement to another technology or technical field; the claims do not amount to an improvement of the functioning of a computer system itself; the claims do not effect a transformation or reduction of a particular article to a different state or thing; and the claims do not move beyond a general link of the use of an abstract idea to a particular technological environment.
Step 2B (Does the claim recite additional elements that amount to significantly more than the judicial exception?) – 2019 PEG pg. 56 (See MPEP 2106.05)
Independent claims 1, 12, and 13 do not include additional elements that are sufficient to amount to significantly more than the judicial exception. As discussed above with respect to integration of the abstract idea into a practical application, the recited additional elements amount to no more than mere instructions to apply the exception using a generic computer component (See MPEP 2106.05(f)) and limits the judicial exception to the particular environment of computers (See MPEP 2106.05(h)). The additional elements of the instant underlying process, when taken in combination, together do not offer substantially more than the sum of the function of the elements when each is taken alone. Mere instructions to apply an exception using a generic computer component cannot provide an inventive concept in Step 2B.
In addition, the dependent claims 2-11 do not include additional elements that are sufficient to amount to significantly more than the judicial exception. As discussed above with respect to integration of the abstract idea into a practical application, the additional elements of the dependent claims to perform the claimed limitations, amounts to no more than mere instructions to apply the exception using a generic computer component (See MPEP 2106.05(f)). Similar to the independent claims, mere instructions to apply an exception using a generic computer component cannot provide an inventive concept. Also, for the same reasoning as the independent claims, the additional elements of the limitations of the dependent claims, when considered individually and as an ordered combination, together do not offer significantly more than the sum of the functions of the elements when each is taken alone and the dependent claims as a whole, do not amount to significantly more than the abstract idea itself. For these reasons, the dependent claims also are not patent eligible.
Claim Rejections - 35 USC § 103
In the event the determination of the status of the application as subject to AIA 35 U.S.C. 102 and 103 (or as subject to pre-AIA 35 U.S.C. 102 and 103) is incorrect, any correction of the statutory basis for the rejection will not be considered a new ground of rejection if the prior art relied upon, and the rationale supporting the rejection, would be the same under either status.
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, 3-6, and 10-13 are rejected under 35 U.S.C. 103 as being unpatentable over US 2015/0134540 to Law et al. (hereinafter referred to as Law), in view of US 2021/0073813 to Nolte et al. (hereinafter referred to as Nolte).
In regards to claim 1, Law discloses a computer-implemented method for enabling use of virtual cards in e-commerce transactions (system and method for executing an e-commerce with a merchant using a mobile device and a virtual card, paras. 0176-0179, figs. 7-13), the method performed by a tokenization server (payment gateway server 506, figs. 7-17; mobile device 501 communicates with payment gateway server 506 or merchant acquirer 103 via an e-commerce webpage or payment application using the Internet, paras. 0176-0179, figs. 7-17), the method comprising: receiving, from a user device (mobile device 501, figs. 7-17), a transaction request corresponding to a transaction with a merchant (GUI 1401 displays an e-commerce webpage with transaction details for a user selected item on mobile device 501 and sends virtual funding card data to the payment gateway server 506 or merchant acquirer 103 when the user enters a PIN and selects the “pay now” button, paras. 0176-0183, figs. 7-17); generating a virtual card number, VCN, which corresponds to a virtual card (virtual card number, the expiry date of the virtual card and other data are computed by the payment gateway server 506, paras. 0124 and 184; claims 4, 19; figs. 7-17); providing the VCN to the merchant (virtual card issuing server creates a virtual card PAN and sends it to the mobile device which sends the virtual card data to the merchant acquirer 103, paras. 0126-0134, 0176-0179); obtaining an underlying funding primary account number, FPAN, of the virtual card (payment gateway server 506 validates the virtual card data received from the mobile device via the merchant acquirer 103 and retrieves the funding card data associated with the virtual card data card in block 804 and sends a payment authorization request to the merchant acquirer 103 and the funding card issuer server 104 to process the transaction, paras. 0116-0120, 0176-0179, figs. 7-17). However, Law fails to disclose generating and storing a cryptogram specific to the transaction with the merchant, retrieving the cryptogram; checking the validity of the cryptogram; and providing an indication to the merchant if the cryptogram is valid or not valid.
Nolte, in the related field of processing merchant transactions using cryptograms, teaches generating (if the consumer is successfully authenticated, the issuer generates and provides a cryptogram to the merchant, para. 0051-0057, 0091-0098) and storing a cryptogram (issuer may store one or more of the cryptogram; the payment credentials; the transaction details; and the transaction reference in the database 138, paras. 0091-0096) specific to the transaction with the merchant (cryptogram is a cryptographic code including information specific to both the transaction and consumer generated using an algorithm and key known only to the issuer, paras. 0091-0098), retrieving the cryptogram (issuer validates cryptogram by comparing the received cryptogram with the cryptogram stored in the database 138, para. 0101); checking the validity of the cryptogram (issuer receives an authorization request including the payment card details and the cryptogram from the merchant, validates the cryptogram and processes the transaction against the payment card details, para. 0051-0056, claims 1, 3, and 7); and providing an indication to the merchant if the cryptogram is valid or not valid (If the cryptogram is valid, the issuer transmits an authorization response to the merchant 110 via the payment processing network 140, para. 0102). It would have been obvious to one having ordinary skill in the art at the time the invention was filed to provide the method of Law with the ability to generate and store a cryptogram for a transaction as taught by the method of Nolte. The motivation for doing so would have been to provide a mechanism for gaining consumer consent to a transaction and then providing proof of that consent in an authorization performed using conventional rails with allows more user friendly approval of the transaction while allowing normal processing (Nolte, para. 0053).
In regards to claim 3, modified Law discloses the computer-implemented method of claim 1, and further discloses wherein providing the VCN to the merchant (virtual card issuing server creates a virtual card PAN and sends it to the mobile device which sends the virtual card data to the merchant acquirer 103, paras. 0126-0134, 0176-0179) further comprises: providing the VCN to the user device for display to a user who manually transfers the VCN to the merchant (virtual card issuing server creates a virtual card PAN and sends it to the mobile device which sends the virtual card data to the merchant acquirer 103, paras. 0126-0134, 0176-0179).
In regards to claim 4, modified Law discloses the computer-implemented method of claim 1, and further discloses wherein obtaining an underlying funding primary account number, FPAN, of the virtual card (payment gateway server 506 validates the virtual card data received from the mobile device via the merchant acquirer 103 and retrieves the funding card data associated with the virtual card data card in block 804 and sends a payment authorization request to the merchant acquirer 103 and the funding card issuer server 104 to process the transaction, paras. 0116-0120, 0176-0179, figs. 7-17) further comprises: receiving the FPAN of the virtual card from a virtual card management service (virtual card issuing server 401 sends the virtual card data to the virtual card operator 402 to retrieve the associated user profile and funding card data to verify the received virtual card data by comparing data with the server computed version of the expected card data, para. 0135).
In regards to claim 5, modified Law discloses the computer-implemented method of claim 4, and further discloses wherein the virtual card management service retrieves the FPAN by querying a database with the VCN (payment gateway server 506 validates the virtual card data received from the mobile device via the merchant acquirer 103 and retrieves the funding card data associated with the virtual card data card in block 804, paras. 0116-0120, 0176-0179, figs. 7-17) to return the FPAN (virtual card operator 402 associates the virtual card PAN with the funding card PAN and stores it in the database 509, para. 0130).
In regards to claim 6, modified Law discloses the computer-implemented method of claim 1, but fails to disclose wherein when the cryptogram is not valid, a response declining authorization is provided to the merchant via an acquirer.
Nolte, in the related field of processing merchant transactions using cryptograms, teaches wherein when the cryptogram (issuer validates cryptogram by comparing the received cryptogram with the cryptogram stored in the database 138, para. 0101) is not valid, a response declining authorization is provided to the merchant via an acquirer (If the cryptogram is not valid, the transaction mab be aborted, para. 0102). It would have been obvious to one having ordinary skill in the art at the time the invention was filed to provide the method of Law with the ability to approve a cryptogram for a transaction as taught by the method of Nolte. The motivation for doing so would have been to provide a mechanism for gaining consumer consent to a transaction and then providing proof of that consent in an authorization performed using conventional rails with allows more user friendly approval of the transaction while allowing normal processing (Nolte, para. 0053).
In regards to claim 10, modified Law discloses the computer-implemented method of claim 1, and further discloses wherein the VCN is an alphanumeric string (virtual card issuing server creates a virtual card PAN which has the last four digits identical to the last four digits of the funding card PAN and the virtual PAN is created by using the first 6 digits assigned to the virtual card issuer, a unique, never used before, 8 digits long random number (to prevent collision), and the check mod10 digit, para. 0129).
In regards to claim 11, modified Law discloses the computer-implemented method of claim 1, but fails to disclose wherein checking the validity of the cryptogram further comprises one or more of: checking that a time of the cryptogram is valid; checking that a transaction amount and currency matches an amount and currency at the merchant; and checking a channel the cryptogram is being used for is correct.
Nolte, in the related field of processing merchant transactions using cryptograms, teaches wherein checking the validity of the cryptogram (Validating the cryptogram 416 may include comparing the received cryptogram with a cryptogram stored in the database 138, para. 0100, claims 1, 3, and 7); comprises checking that a transaction amount and currency matches an amount and currency at the merchant (cryptogram may include one or more of a verification; transaction details and a transaction identifier including full transaction details, para. 0113). It would have been obvious to one having ordinary skill in the art at the time the invention was filed to provide the method of Law with the ability to check the validity of a cryptogram for a transaction as taught by the method of Nolte. The motivation for doing so would have been to provide a mechanism for gaining consumer consent to a transaction and then providing proof of that consent in an authorization performed using conventional rails with allows more user friendly approval of the transaction while allowing normal processing (Nolte, para. 0053).
In regards to claim 12, Law discloses a tokenization server (payment gateway server 506, figs. 7-17; mobile device 501 communicates with payment gateway server 506 or merchant acquirer 103 via an e-commerce webpage or payment application using the Internet, paras. 0176-0179, figs. 7-17) configured to perform a method (system and method for executing an e-commerce with a merchant using a mobile device and a virtual card, paras. 0176-0179, figs. 7-13) comprising: receiving, from a user device (mobile device 501, figs. 7-17), a transaction request corresponding to a transaction with a merchant (GUI 1401 displays an e-commerce webpage with transaction details for a user selected item on mobile device 501 and sends virtual funding card data to the payment gateway server 506 or merchant acquirer 103 when the user enters a PIN and selects the “pay now” button, paras. 0176-0183, figs. 7-17); generating a virtual card number, VCN, which corresponds to a virtual card (virtual card number, the expiry date of the virtual card and other data are computed by the payment gateway server 506, paras. 0124 and 184; claims 4, 19; figs. 7-17); providing the VCN to the merchant (virtual card issuing server creates a virtual card PAN and sends it to the mobile device which sends the virtual card data to the merchant acquirer 103, paras. 0126-0134, 0176-0179); obtaining an underlying funding primary account number, FPAN, of the virtual card (payment gateway server 506 validates the virtual card data received from the mobile device via the merchant acquirer 103 and retrieves the funding card data associated with the virtual card data card in block 804 and sends a payment authorization request to the merchant acquirer 103 and the funding card issuer server 104 to process the transaction, paras. 0116-0120, 0176-0179, figs. 7-17). However, Law fails to disclose generating and storing a cryptogram specific to the transaction with the merchant, retrieving the cryptogram; checking the validity of the cryptogram; and providing an indication to the merchant if the cryptogram is valid or not valid.
Nolte, in the related field of processing merchant transactions using cryptograms, teaches generating (if the consumer is successfully authenticated, the issuer generates and provides a cryptogram to the merchant, para. 0051-0057, 0091-0098) and storing a cryptogram (issuer may store one or more of the cryptogram; the payment credentials; the transaction details; and the transaction reference in the database 138, paras. 0091-0096) specific to the transaction with the merchant (cryptogram is a cryptographic code including information specific to both the transaction and consumer generated using an algorithm and key known only to the issuer, paras. 0091-0098), retrieving the cryptogram (issuer validates cryptogram by comparing the received cryptogram with the cryptogram stored in the database 138, para. 0101); checking the validity of the cryptogram (issuer receives an authorization request including the payment card details and the cryptogram from the merchant, validates the cryptogram and processes the transaction against the payment card details, para. 0051-0056, claims 1, 3, and 7); and providing an indication to the merchant if the cryptogram is valid or not valid (If the cryptogram is valid, the issuer transmits an authorization response to the merchant 110 via the payment processing network 140, para. 0102). It would have been obvious to one having ordinary skill in the art at the time the invention was filed to provide the method of Law with the ability to generate and store a cryptogram for a transaction as taught by the method of Nolte. The motivation for doing so would have been to provide a mechanism for gaining consumer consent to a transaction and then providing proof of that consent in an authorization performed using conventional rails with allows more user friendly approval of the transaction while allowing normal processing (Nolte, para. 0053)
In regards to claim 13, Law discloses a computer-readable medium comprising instructions which, when executed by a processor (computer executable or processor implemented instructions are provided for facilitating a transaction, paras. 0114, 0124, and 0184; figs. 8-12, and 16) cause the processor to perform a method (system and method for executing an e-commerce with a merchant using a mobile device and a virtual card, paras. 0176-0179, figs. 7-13) comprising: receiving, from a user device(mobile device 501, figs. 7-17), a transaction request corresponding to a transaction with a merchant (GUI 1401 displays an e-commerce webpage with transaction details for a user selected item on mobile device 501 and sends virtual funding card data to the payment gateway server 506 or merchant acquirer 103 when the user enters a PIN and selects the “pay now” button, paras. 0176-0183, figs. 7-17); generating a virtual card number, VCN, which corresponds to a virtual card (virtual card number, the expiry date of the virtual card and other data are computed by the payment gateway server 506, paras. 0124 and 184; claims 4, 19; figs. 7-17); providing the VCN to the merchant (virtual card issuing server creates a virtual card PAN and sends it to the mobile device which sends the virtual card data to the merchant acquirer 103, paras. 0126-0134, 0176-0179); obtaining an underlying funding primary account number, FPAN, of the virtual card (payment gateway server 506 validates the virtual card data received from the mobile device via the merchant acquirer 103 and retrieves the funding card data associated with the virtual card data card in block 804 and sends a payment authorization request to the merchant acquirer 103 and the funding card issuer server 104 to process the transaction, paras. 0116-0120, 0176-0179, figs. 7-17). However, Law fails to disclose generating and storing a cryptogram specific to the transaction with the merchant, retrieving the cryptogram; checking the validity of the cryptogram; and providing an indication to the merchant if the cryptogram is valid or not valid.
Nolte, in the related field of processing merchant transactions using cryptograms, teaches generating (if the consumer is successfully authenticated, the issuer generates and provides a cryptogram to the merchant, para. 0051-0057, 0091-0098) and storing a cryptogram (issuer may store one or more of the cryptogram; the payment credentials; the transaction details; and the transaction reference in the database 138, paras. 0091-0096) specific to the transaction with the merchant (cryptogram is a cryptographic code including information specific to both the transaction and consumer generated using an algorithm and key known only to the issuer, paras. 0091-0098), retrieving the cryptogram (issuer validates cryptogram by comparing the received cryptogram with the cryptogram stored in the database 138, para. 0101); checking the validity of the cryptogram (issuer receives an authorization request including the payment card details and the cryptogram from the merchant, validates the cryptogram and processes the transaction against the payment card details, para. 0051-0056, claims 1, 3, and 7); and providing an indication to the merchant if the cryptogram is valid or not valid (If the cryptogram is valid, the issuer transmits an authorization response to the merchant 110 via the payment processing network 140, para. 0102). It would have been obvious to one having ordinary skill in the art at the time the invention was filed to provide the method of Law with the ability to generate and store a cryptogram for a transaction as taught by the method of Nolte. The motivation for doing so would have been to provide a mechanism for gaining consumer consent to a transaction and then providing proof of that consent in an authorization performed using conventional rails with allows more user friendly approval of the transaction while allowing normal processing (Nolte, para. 0053).
Claims 2, and 7-9 are rejected under 35 U.S.C. 103 as being unpatentable over Law, in view of Nolte, and further in view of US 2014/0129435 to Pardo et al. (hereinafter referred to as Pardo).
In regards to claim 2, modified Law discloses the computer-implemented method of claim 1, but fails to disclose wherein providing the VCN to the merchant further comprises: transmitting the VCN to an API which transmits the VCN to the merchant.
Pardo, in the related field of electronic transactions, teaches transmitting the VCN to an API (wallet application program interface (API) is provided to pass card details, shipping information and security tokens, para. 0071) which transmits the VCN to the merchant (Step of providing the virtual card number to the merchant is carried out by exposing API 5999 to the merchant, para. 0167). It would have been obvious to one having ordinary skill in the art at the time the invention was filed to provide the method of Law with the ability to send the VPN using an API as taught by the method of Pardo. The motivation for doing so would have been to provide a seamless operation by integrating a wallet with the merchant website via an API (Pardo, paragraph 0130).
In regards to claim 7, modified Law discloses the computer-implemented method of claim 1, but fails to disclose wherein when the cryptogram is valid, the cryptogram is provided to the merchant with a virtual card management service which performs further checks.
Nolte, in the related field of processing merchant transactions using cryptograms, teaches generating wherein when the cryptogram is valid, the cryptogram is provided to the merchant (If the cryptogram is valid, the issuer transmits an authorization response to the merchant 110 via the payment processing network 140, para. 0102). It would have been obvious to one having ordinary skill in the art at the time the invention was filed to provide the method of Law with the ability to generate and store a cryptogram for a transaction as taught by the method of Nolte. The motivation for doing so would have been to provide a mechanism for gaining consumer consent to a transaction and then providing proof of that consent in an authorization performed using conventional rails with allows more user friendly approval of the transaction while allowing normal processing (Nolte, para. 0053). However the combination of Law and Nolte fails to disclose provided with a virtual card management service which performs further checks.
Pardo, in the related field of electronic transactions, teaches provided with a virtual card management service which performs further checks (user may set a dollar limit for a transaction, spending in a certain time, or for spending in a certain category in a certain period of time, and may choose to decline transactions that are over the limit or to receive an alert regarding same, para. 0130). It would have been obvious to one having ordinary skill in the art at the time the invention was filed to provide the method of Law with the ability to set limits for a VPN as taught by the method of Pardo. The motivation for doing so would have been to allow customized spend management controls for customers (Pardo, paragraph 0130).
In regards to claim 8, modified Law discloses the computer-implemented method of claim 7, but fails to disclose wherein the further checks comprise one or more of determining whether: the transaction is within a pre-configured timeframe; the transaction is at an allowed merchant and/or merchant category; a transaction amount is within a specified range; the transaction is for a specific amount; an aggregate of spend with the virtual card is less than or equal to a specified amount; the aggregate of spend with the virtual card by merchant and/or merchant category is within a specified amount; the spend and/or aggregate spend with the virtual card at a merchant/merchant category is within a specified amount and within a specified time period.
Pardo, in the related field of electronic transactions, teaches wherein the further checks comprise: whether: the transaction is within a pre-configured timeframe; the transaction is at an allowed merchant and/or merchant category; a transaction amount is within a specified range; or the transaction is for a specific amount (user may set a dollar limit for a transaction, spending in a certain time, or for spending in a certain category in a certain period of time, and may choose to decline transactions that are over the limit or to receive an alert regarding same, para. 0130). It would have been obvious to one having ordinary skill in the art at the time the invention was filed to provide the method of Law with the ability to set limits for a VPN as taught by the method of Pardo. The motivation for doing so would have been to allow customized spend management controls for customers (Pardo, paragraph 0130).
In regards to claim 9, modified Law discloses the computer-implemented method of claim 8, but fails to disclose wherein it is determined whether the further checks result in the transaction being declined or allowed with an alert.
Pardo, in the related field of electronic transactions, teaches wherein it is determined whether the further checks result in the transaction being declined or allowed with an alert (user may set a dollar limit for a transaction, spending in a certain time, or for spending in a certain category in a certain period of time, and may choose to decline transactions that are over the limit or to receive an alert regarding same, para. 0130). It would have been obvious to one having ordinary skill in the art at the time the invention was filed to provide the method of Law with the ability to set limits for a VPN as taught by the method of Pardo. The motivation for doing so would have been to allow customized spend management controls for customers (Pardo, paragraph 0130).
Conclusion
The prior art made of record and not relied upon is considered pertinent to applicant's disclosure.
Ferenczi (US 20230114697) teaches zero knowledge proof based virtual cards.
Bimolaksondo et al. (US 20240257100) teaches real time transactions using a virtual card token.
Fonseca et al. (US 20180374088) teaches one time virtual card numbers for immediate installment payments.
Any inquiry concerning this communication or earlier communications from the examiner should be directed to Paul Schwarzenberg whose telephone number is (313) 446-6611. The examiner can normally be reached on Monday-Thursday (7:30-6:30).
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, Christine Behncke, can be reached on (571) 272-8103. 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.
/PAUL S SCHWARZENBERG/Primary Examiner, Art Unit 3695 6/22/2026
Prosecution Insights