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 .
Status of the Claims
Claims 21 and 22 are presented for examination. Applicant filed a response to non-final Office action on 10/15/2025 amending claims 21 and 22. In light of Applicant’s amendment, Examiner has withdrawn the previous objections and § 101 rejection. Examiner has, however, established new § 101 rejection for claims 21 and 22 in the instant Office action. Since the new § 101 rejection was necessitated by Applicant’s amendments, instant rejection of claims 21 and 22 is FINAL rejection of the claims.
Examiner’s Remarks
Patent Eligibility under § 101:
Applicant argues in pages 8-9 and 11 of Applicant’s Remarks:
[Step 2A – Prong 1:] Claim 21 is not directed solely to a judicial exception of an abstract idea. Instead, it recites a specific, technical process for implementing a secure, distributed architecture that enables real- time generation, provisioning, and runtime enforcement of digital variant cards using tokenization, programmable API contracts, device binding, and dynamic CVV authentication. The recited elements, such as determining and enforcing granular API-defined contract conditions (e.g., credit limits, device identifiers, merchant restrictions, transaction caps, validity periods, geographic limits, and usage days), are not abstract business practices but rather are implemented as a specific, rules-based, technological improvement to digital payment infrastructure. This addresses technical problems in legacy systems, such as onboarding bottlenecks and insecure sub-user access (paras. [0001]-[0003]), similar to the self-referential data structures in Enfish, which improved database efficiency beyond conventional methods. Enfish, LLC v. Microsoft Corp., 822 F.3d 1327, 1336 (Fed. Cir. 2016) ("the plain focus of the claims is on an improvement to computer functionality itself, not on economic or other tasks for which a computer is used in its ordinary capacity.").
. . .
[Step 2A – Prong 2:] Claim 21 includes a distributed process executed by a card computing platform that uses secure API contracts to define granular, programmable transaction parameters, including merchant identifiers, geographic restrictions, transaction limits, and device-based access. Variant cards are provisioned in real-time, bound to specific sub-user devices, and used for transactions that are authenticated by per-transaction dynamic CVV values generated by a card network (paras. [0027]- [0036]; FIGS. 2-5). In the amended claim, these elements are recited with specificity and not a high level of generality such as a generic purpose processor performing generic computer functions. Instead, the recited elements in amended claim 21 precisely define how the process enforces financial access control using non-conventional data flow and execution logic, such as real-time credit limit synchronization and API-driven token requests that remove dependencies on issuing institutions. This claimed arrangement dramatically improves payment network security and efficiency by enabling issuer-independent, real-time enforcement of programmable constraints, which is not feasible in conventional card systems.
. . .
[Step 2B:] [T]he specification describes dynamic CVVs as on-demand API-generated for per-transaction security, exceeding static verification methods, which provides factual evidence under Berkheimer that these elements are not well-understood, routine, or conventional. See id. Moreover, the ordered combination of API contracts, device binding, and per-transaction CVVs provides a non-routine solution to payment scalability and security, akin to the non-conventional filtering arrangement in BASCOM Global Internet v. AT&T Mobility LLC, by enabling distributed sub-user control without central issuer coordination. See 827 F.3d 1341, 1350-51 (Fed. Cir. 2016) ("The claims do not merely recite the abstract idea of filtering content along with the requirement to perform it on the Internet, or to perform it on a set of generic computer components ... Nor do the claims preempt all ways of filtering content on the Internet; rather, they recite a specific, discrete implementation of the abstract idea of filtering content ... to improve an existing technological process"). Accordingly, the features of claim 21-individually and in combination-amount to significantly more than the alleged abstract idea of "methods of organizing human activity" and Step 2B is also satisfied.
Examiner respectfully disagrees:
Step 2A – Prong 1: The Federal Circuit Court, in Electric Power Group, also distinguished the claims at issue from the claims in Enfish: “In Enfish, we applied the distinction to reject the § 101 challenge at stage one because the claims at issue focused not on asserted advances in uses to which existing computer capabilities could be put, but on specific improvement–a particular database technique–in how computers could carry out one of their basic functions of storage and retrieval of data. Enfish, 822 F.3d 1335-36 …The present case is different: the focus of the claims is not on such an improvement in computers as tools, but on certain independently abstract ideas that use computers as tools.” (8). This is similar to the instant claims 21 and 22 which focus on abstract idea of generating and managing digital variant cards for sub-users using computing systems as a tool instead of improving computer as a tool. Thus, the instant claims 21 and 22 are not patent eligible under Step 2A – Prong 1 of the Test.
Step 2A – Prong 2: Claims 21 and 22, as a whole, do not amount to significantly more than the abstract idea itself. There is nothing in the claims 21 and 22 recited that integrates the abstract idea into a practical application. Applicant's claims are reciting a method and a system that solves a business problem instead of technological problem. Instant claims do not effect an improvement to another technology or technical field; the claims do not amount to an improvement to the functioning of a computer itself; and the claims do not move beyond a general link of the use of an abstract idea to a particular technological environment. The recited limitations of claims 21 and 22 merely amount to the application or instructions to apply the abstract idea of generating and managing digital variant cards for sub-users on a computing system, and these limitations are considered to amount to nothing more than requiring a generic computer system to carry out the abstract idea itself. Therefore, the instant claims 21 and 22 are not patent eligible under Step 2A – Prong 2 of the Test.
Step 2B: First, the factual evidence under Berkheimer for the additional elements being well-understood, routine, and conventional elements that amount to no more than implementing the abstract idea with a computerized system comes directly from the Applicant’s Specification in [0023] that describes a general-purpose computing system. Second, the Federal Circuit Court, in Electric Power Group, distinguished the claims at issue from the claims in Bascom explaining: “Nor do the claims here require an arguably inventive distribution of functionality within a network, thus distinguishing the claims at issue from those in Bascom …The claims in this case specify what information in the power-grid field it is desirable to gather, analyze, and display, including in “real time”; but they do not include any requirement for performing the claimed functions of gathering, analyzing, and displaying in real time by use of anything but entirely conventional, generic technology.” (10-11). Similarly here, the instant claims 21 and 22 do not use anything besides entirely conventional, generic technology of general purpose computing system. While the Federal Circuit Court in Bascom found non-conventional and non-generic arrangement of the additional elements, no such non-conventional and non-generic arrangement of the additional elements is present with the instant claims. Thus, the instant claims 21 and 22 are not patent eligible under Step 2B of the Test.
Prior Art under § 102/§ 103:
The previously cited prior art reference Dey (US 2023/0102161 A1) teaches:
Embodiments provide methods and systems for associating a single token with multiple accounts of a user, and enabling the user to define rules for processing transactions using the token. A Federated Virtual Card (FVC) may be provisioned on a digital wallet of a user device through a token associated with the FVC. Transactions conducted using the FVC may be divided among the two or more user accounts based on user-defined rules.
Another prior art reference de Anda (US 2023/0252450 A1) teaches:
Techniques are described for providing a virtual card payments system that enables commercial customers to make business-to-business (B2B) payments via a virtual credit card number without exposing an originating account to a payment recipient. A commercial customer may submit bill information for one or more invoices to the virtual card payments system. The virtual card payments system sends a request to a credit account number server for generation of a virtual credit card number that is associated with the commercial customer's originating account for each submitted invoice. The virtual credit card number may then be sent to a recipient via a secure channel to perform payment of the invoice without exposing the originating account to the recipient. The virtual card payments system may send the virtual credit card number to the recipient or directly to the recipient's merchant acquirer to process payment of the invoice.
Neither Dey or de Anda – alone or in combination with other references – teach all the claim limitations of independent claims 21 and 22 as an ordered combination of steps.
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 21 and 22 are rejected under 35 USC § 101 because they are directed to non-statutory subject matter. The rationale for this finding is explained below.
The Supreme Court in Mayo laid out a framework for determining whether an applicant is seeking to patent a judicial exception itself or a patent-eligible application of the judicial exception. See Alice Corp., 134 S. Ct. at 2355,110 USPQ2d at 1981 (citing Mayo, 566 U.S. 66, 101 USPQ2d 1961). This framework, which is referred to as the Mayo test or the Alice/Mayo test (“the test”), is described in detail in Manual of Patent Examining Procedure (”MPEP”) (see MPEP § 2106(III) for further guidance). The step 1 of the test: It need to be determined whether the claims are directed to a patent eligible (i.e., statutory) subject matter under 35 USC § 101. Step 2A of the test: If the claims are found to be directed to a statutory subject matter, the next step is to determine whether the claims are directed to a judicial exception i.e., law of nature, natural phenomenon, and abstract idea (Prong 1). If the claims are found to be directed to an abstract idea, it needs to be determined whether the claims recite additional elements that integrate the judicial exception into a practical application (Prong 2). Step 2B of the test: If the claims are directed to a judicial exception, the next and final step is to determine whether the claims recite additional elements that amount to significantly more than the judicial exception.
Step 1 of the Test:
When considering subject matter eligibility under 35 USC § 101, it must be determined whether the claim is directed to one of the four statutory categories of invention, i.e., process, machine, manufacture, or composition of matter. Here, the claimed invention of claim 21 is a series of steps, which is method (i.e., a process) and, thus, one of the statutory categories of invention. Further, claimed invention of claim 22 is a system, which is also one of the statutory categories of invention.
Conclusion of Step 1 Analysis: Therefore, claims 21 and 22 are statutory under 35 USC § 101 in view of step 1 of the test.
Step 2A of the Test:
Prong 1: Claims 21 and 22, however, recites an abstract idea of generating and managing digital variant cards for sub-users. The creation of generating and managing digital variant cards for sub-users, as recited in the independent claims 21 and 22 belongs to certain methods of organizing human activity (i.e., commercial interactions) that are found by the courts to be abstract ideas. The limitations in independent claims 21 and 22, which set forth or describe the recited abstract idea, are found in the following steps:
“determining contract conditions defined by secure API contracts for each variant card, including: a portion of the authorized user's credit limit to be shared with the respective sub-user; a specific device of the sub-user to which the variant card is to be associated, identified by a device identifier; one or more merchant identifiers specifying merchants where the variant card can be used; a maximum transaction amount for each transaction; a total number of transactions allowed for the variant card; a validity period defined by a start date and an end date; a geographic restriction specifying that the variant card can only be used for domestic transactions or within a specific geographic area; and specific days of the week during which the variant card is valid” (claim 21);
“generating a digital variant card for each sub-user, each associated with its respective token ID and linked to the authorized user's original purchasing card, wherein each variant card is configured to share its determined portion of the credit limit” (claim 21);
“provisioning each digital variant card on its respective associated sub-user device, wherein each provisioned card is bound to the designated device identifier using token-based binding and secured using tokenization” (claim 21);
“enabling each sub-user to use their respective variant card for transactions at authorized merchants within the validity period, on specified days of the week, within the geographic restriction, and up to the maximum transaction amount and total number of transactions, wherein each transaction is authenticated using a generated dynamic card verification value (CVV) at the time of transaction” (claim 21);
“monitoring transactions made with each variant card” (claim 21);
“monitoring the total credit used by all variant cards associated with the authorized user's original purchasing card and ensuring, through real-time credit limit synchronization via API calls that aggregate and compare usage data across tokens, that it does not exceed the authorized credit limit of the original purchasing card” (claim 21);
“consolidating bill payments for all transactions made with the variant cards and the original purchasing card into a single billing statement for the authorized user” (claim 21);
“performing the generation and management of the variant cards in real-time without requiring intervention from the issuing financial institution of the original purchasing card, such that programmable contract conditions are enforced at the time of transaction by evaluating transaction data against token identification using a rules engine that applies dynamic CVV validation and contract condition matching to authenticate sub-user devices” (claim 21);
“determining contract conditions defined by secure API contracts for each variant card, including: a portion of the authorized user's credit limit to be shared with the sub-user; a specific device of the sub-user identified by a device identifier; one or more merchant identifiers specifying authorized merchants; a maximum transaction amount per transaction; a total number of allowed transactions; a validity period defined by start and end dates; a geographic restriction specifying domestic transactions or a specific geographic area; and specific days of the week for validity” (claim 22);
“generating and provisioning digital variant cards on sub-user devices, wherein each card is tokenized, associated via a unique token identification number, bound to a specific device using token-based association via device identification parameters, authentication at runtime through a transaction pipeline that verifies dynamic card verification values, and configured to operate within the determined contract conditions” (claim 22);
“monitoring transactions made with each variant card” (claim 22);
“monitoring total credit usage across all variant cards and ensuring, through real-time credit limit synchronization via algorithmic aggregation of token data, that it does not exceed the original purchasing card's credit limit” (claim 22);
“consolidating bill payments for all transactions into a single billing statement for the authorized user” (claim 22);
“generating token IDs in response to token requests, wherein the token IDs embed the contract conditions as data structures for runtime evaluation” (claim 22);
“generating a dynamic card verification value (CVV) specific to that transaction based on transaction parameters for each transaction initiated with a variant card” (claim 22);
“determining whether the transaction complies with the contract conditions associated with the variant card's token ID using a rules-based engine that performs real-time comparison for each transaction initiated with a variant card, including: availability of credit within the allocated credit limit via centralized credit limit management; authorization for the merchant based on merchant identifiers; compliance with the maximum transaction amount; compliance with the total number of allowed transactions; compliance with the validity period; compliance with geographic restrictions; and compliance with allowed days of the week” (claim 22);
“authorizing the transaction and mapping it to the original purchasing card for settlement if compliant” (claim 22);
“declining the transaction if not compliant” (claim 22);
“storing and using provisioned variant cards” (claim 22);
“processing transactions using variant cards” (claim 22);
“verifying dynamic CVVs” (claim 22); and
“enabling sub-users to use their variant cards for transactions sharing the authorized user's credit limit without requiring intervention from the issuing financial institution, ensuring that all transactions are processed securely using API-driven tokenization and per-transaction dynamic CVVs in accordance with the predefined rules set by the authorized user, and enabling a technical variant card architecture for real-time credential enforcement and programmable financial access control” (claim 22).
Prong 2: In addition to abstract steps recited above in Prong 1, independent claims 21 and 22 recite additional elements:
“a card computing platform hosted in a data center” (claim 21);
“a mobile application” (claims 21 and 22);
“a secure tokenization API” (claim 21);
“an API service layer” (claims 21 and 22);
“a card network service provider” (claim 21);
“a secure communication channel” (claims 21 and 22);
“a card network” (claims 21 and 22);
“a dynamic CVV generation API” (claims 21 and 22);
“the mobile application's user interface” (claim 21);
“the card computing platform communicates with user devices and the card network via one or more networks selected from wired networks, wireless networks, and cellular networks” (claim 21);
“a distributed card computing platform hosted in a data center with at least one processor and anon-transitory memory storing instructions” (claim 22);
“a card network service provider comprising at least one processor and memory storing executable instructions” (claim 22);
“one or more sub-user devices” (claim 22);
“point-of-sale terminals” (claim 22);
“automated teller machines” (claim 22); and
“a tokenization and distributed rules engine” (claim 22).
These additional elements are recited at a high level of generality (i.e., as a generic purpose processor performing generic computer functions) such that they amount to no more than mere instructions to apply the exception using a generic computer components. Also, the following additional limitations recite insignificant extra solution activity (for example, data gathering):
“receiving a request from an authorized user to generate one or more variant cards for one or more sub-users” (claim 21);
“transmitting a token request for each variant card, the token request including the respective contract conditions embedded as programmable parameters in the token” (claim 21);
“receiving a token ID for each token request” (claim 21);
“providing options for the authorized user to block or remove any variant card in real-time” (claim 21);
“sending transaction alerts to the authorized user” (claim 21);
“receiving requests from authorized users to generate digital variant cards for sub-users” (claim 22);
“transmitting token requests and receiving token IDs for each variant card” (claim 22);
“sending transaction alerts to authorized users” (claim 22);
“providing options for authorized users to block or remove variant cards” (claim 22);
“receiving transaction requests for each transaction initiated with a variant card” (claim 22); and
“transmitting transaction requests for authorization” (claim 22).
These additional elements/limitations do not integrate the abstract idea into a practical application because they do not impose a meaningful limit on the judicial exception. The additional elements/limitations of independent claims 21 and 22 here do not render improvements to the functioning of a computer or to any other technology or technical field (see MPEP § 2106.05(a)), nor do they integrate the abstract idea into a practical application under MPEP § 2106.05(b) (particular machine); render patent eligibility under MPEP § 2106.05(c) (particular transformations); or render patent eligibility under MPEP § 2106.05(e) (other meaningful limitations). Further, the combination of these additional elements/limitations is no more than mere instructions to apply the exception using a generic device. Accordingly, even in combination, these additional elements/limitations do not integrate the abstract idea into a practical application because they do not impose any meaningful limits on practicing the abstract idea.
Conclusion of Step 2A Analysis: Therefore, independent claims 21 and 22 are non-statutory under 35 USC § 101 in view of step 2A of the test.
Step 2B of the Test: The additional elements/limitations of independent claims 21 and 22 (see above under Step 2A – Prong 2) are well-understood, routine, and conventional elements that amount to no more than implementing the abstract idea with a computerized system. The Applicant’s Specification describes the additional elements in following terms:
[23] In an embodiment, a card computing platform 106 may be configured to provide one or more interfaces that allow for configuration and management of one or more cards, computing devices, and/or computer systems included in the computing environment. In yet another embodiment, a computing environment also may include one or more computing platforms. For example, a computing environment may include a card computing platform 106. As illustrated in greater detail below, a card computing platform 106 may include one or more computing devices configured to perform one or more of the functions described herein. For example, a card computing platform 106 may include one or more computers (e.g., laptop computers, desktop computers, servers, server blades, or the like). The computing environment also may include one or more networks 114, which may interconnect one or more of card alert computing platforms, a user device 108, a point-of-sale terminal 110, and/or an automated teller machine 112. For example, a computing environment may include a network 114, which may include one or more public networks, one or more private networks, and/or one or more sub-networks (e.g., local area networks (LANs), wide area networks (WANs), or the like). In addition, as discussed above, network 114 may also include a telephone (POTS) system, and/or a cellular network in addition to digital data networks. Other networks such as card network 115 may connect card authorization organizations 142 with card computing platform 106.
This is a description of general-purpose computing system. Further, the additional limitations of “receiving,” “transmitting,” “sending,” and “providing” information to and from a user device amount to no more than mere instructions to apply the exception using generic computer components. For the same reason, these additional limitations are not sufficient to provide an inventive concept. The additional limitations of “receiving,” “transmitting,” “sending,” and “providing” information to and from a user device were considered insignificant extra-solution activity in Step 2A – Prong 2. Re-evaluating here in Step 2B, they are also determined to be well-understood, routine, and conventional activity in the field. Similarly to OIP Techs., Inc., v. Amazon.com, Inc., 788 F.3d 1359, 1363, 115 USPQ2d 1090, 1093 (Fed. Cir. 2015) (sending messages over a network), and buySAFE, Inc. v. Google, Inc., 765 F.3d 1350, 1355, 112 USPQ2d 1093, 1096 (Fed. Cir. 2014) (computer receives and sends information over a network), the additional limitations “receive,” “transmit,” “send,” and “provide” information over a network in a merely generic manner. The courts have recognized “receiving,” “transmitting,” “sending,” and “providing” information to and from a user device functions as well-understood, routine and conventional when claimed in a merely generic manner. Therefore, the additional elements/limitations of independent claims 21 and 22 are well-understood, routine, and conventional. Further, taken as combination, the additional elements/ limitations add nothing more than what is present when the additional elements/limitations are considered individually. There is no indication that the combination provides any effect regarding the functioning of the computer or any improvement to another technology.
Conclusion of Step 2B Analysis: Therefore, independent claims 21 and 22 are non-statutory under 35 USC § 101 in view of step 2B of the test.
Dependent Claims: There are no dependent claims.
Conclusion of the 35 USC § 101 Analysis: Therefore, claims 21 and 22 are rejected as directed to an abstract idea without “significantly more” under 35 USC § 101.
Conclusion
The prior art made of record and not relied upon is considered pertinent to applicant's disclosure.
Shanmugam (US 2022/0114582 A1) discloses: “The method involves providing an aggregator account having a token balance at a blockchain network (107). The child accounts of the aggregator account are generated. The top-up transactions are periodically initiated at the blockchain network to transfer tokens from the aggregator account to multiple child accounts. The respective token balances are concurrently incremented for multiple users by initiating multiple user top-up transactions at the blockchain network to transfer tokens from multiple child accounts to the user blockchain accounts.”
Faith (US 8,954,353 B2) discloses: “A method for forming a dynamic verification value. The method includes altering a first data string to form a second data string, and forming a first dynamic verification value using at least a portion of the second data string. The first dynamic verification value is used to authenticate a phone in a first transaction. The second data string is used to form a third data string. A second dynamic verification value is formed using at least a portion of the third data string. The second dynamic verification value is used to authenticate the phone in a second transaction.”
Batlle (US 2016/0321663 A1) discloses: “Systems and methods are disclosed for allocating funds from a primary account to one or more configurable payment cards for use in a payment transaction. An electronic transaction system includes an account database storing account and configurable card data for a user. A budget module enables the user to allocate funds to various virtual accounts and assign configurable cards to each virtual account, and configure resource limitations and use restrictions on each virtual account and configurable card. A user device provides an interface for managing the account, budget and configurable card information and receives a real-time account, budget and configurable card information. The configurable cards may be used to make payments through a merchant's point-of-sale system which interfaces with the electronic transaction system to authenticate the card transaction.”
Praisner (US 7,319,986 B2) discloses: “The dynamic payment cards can be traditional payment cards with card control settings that are dynamically managed. In addition, a dynamic card management system can automatically interface with card processor systems to dynamically modify these card control settings, and a purchasing management system or other request and approval workflow engine can provide an interface between a company and the dynamic card management system. More generally, an advantageous solution for purchasing management is disclosed that utilizes dynamically or actively managed approval parameters to help control transaction authorization determinations associated with purchasing mechanisms.”
Vishwas Patil and R. K. Shyamasundar, "An efficient, secure and delegable micro-payment system," IEEE International Conference on e-Technology, e-Commerce and e-Service, 2004. EEE '04. 2004, Taipei, Taiwan, 2004, pp. 394-404.
Applicant's amendment necessitated the new grounds of rejection presented in this Office action. Accordingly, THIS ACTION IS MADE FINAL. See MPEP § 706.07(a). Applicant is reminded of the extension of time policy as set forth in 37 CFR 1.136(a). A shortened statutory period for reply to this final action is set to expire THREE MONTHS from the mailing date of this action. In the event a first reply is filed within TWO MONTHS of the mailing date of this final action and the advisory action is not mailed until after the end of the THREE-MONTH shortened statutory period, then the shortened statutory period will expire on the date the advisory action is mailed, and any extension fee pursuant to 37 CFR 1.136(a) will be calculated from the mailing date of the advisory action. In no event, however, will the statutory period for reply expire later than SIX MONTHS from the date of this final action.
Any inquiry concerning this communication or earlier communications from the examiner should be directed to VIRPI H. KANERVO whose telephone number is 571-272-9818. The examiner can normally be reached on Monday – Friday, 10 am – 6 pm. If attempts to reach the examiner by telephone are unsuccessful, the examiner’s supervisor Abhishek Vyas can be reached on 571-270-1836. The fax phone number for the organization where this application or proceeding is assigned is 571-273-8300.
Information regarding the status of an application may be obtained from the Patent Application Information Retrieval (PAIR) system. Status information for published applications may be obtained from either Private PAIR or Public PAIR. Status information for unpublished applications is available through Private PAIR only. For more information about the PAIR system, see http://pair-direct.uspto.gov. Should you have questions on access to the Private PAIR system, contact the Electronic Business Center (EBC) at 866-217-9197 (toll-free). If you would like assistance from a USPTO Customer Service Representative or access to the automated information system, call 800-786-9199 (IN USA OR CANADA) or 571-272-1000.
/VIRPI H KANERVO/Primary Examiner, Art Unit 3691