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 .
Response to Amendment
Applicant’s “Amendment” filed on 03/03/2026 has been considered.
Claims 1, 5, 12, 15, and 19 are amended. Claims 1-20 remain pending in this application and an action on the merits follow.
Applicant' s response by virtue of amendment to claims 1, 8, and 15 has overcome the Examiner' s rejection under 35 USC § 112.
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-20 are rejected under 35 U.S.C. 103 as being unpatentable over U.S. Patent Application Publication No. 2015/0254647 to Bondesen et al., in view of U.S. Patent No. 11,880,845 to Misra et al., and further in view of U.S. Patent Application Publication No. 2022/0067719 to DiGangi et al.
With regard to claims 1, 8, and 15, Bondesen discloses a system, comprising:
a memory (paragraph 3); and
at least one processor coupled to the memory and configured to (paragraph 3):
responsive to the bank validation procedure succeeding, storing a record of the user account to an account database within the RTP network to link the virtual card token to the user account, wherein the record associates the user account with the virtual card token, the one or more bank accounts, and the one or more parameters, and wherein the record is keyed by the virtual card token (The user 2 may set up the digital wallet by communicating with the issuing financial institution 40 (e.g., the user's financial institution) to request a token for the payment device, either for the device itself, or for one or more digital wallets or one or more user accounts stored on the payment device. The issuing financial institution 40 may store the tokens, the associated user account information (e.g., including the user account number), and any limits on the use of the tokens, as was previously described with respect to the tokenization service 50 in FIG. 1A. In one embodiment the tokens may include user account information or routing information within the token or tied to the token, which allows the merchants 10 and other institutions in the payment processing systems to route the token and the transaction information to the proper institutions for processing. the user 2 may generate (e.g., create, request, or the like) a token in order to make a payment using the tokenization service 50, and in response the tokenization service 50 provides a token to the user and stores an association between the token and the user account number in a secure token and account database 52. Examiner notes that a token generated stored in account database of the digital wallet is considered as “storing a record of the user account to an account database within the RTP network to link the virtual card token to the user account, wherein the record associates the user account with the virtual card token, the one or more bank accounts, and the one or more parameters”, Paragraphs 42 and 48);
receive the virtual card token and a transaction amount from a merchant point- of-sale system (paragraphs 44, 49, and 84, transaction data is received from the user or a merchant. In one example, the user provides the token to the merchant (e.g., via NFR technology, wireless technology, and so forth), and the merchant then sends the token and the transaction data to a payment-processing network or other third party.);
retrieving, from the account database stored in the memory, the record of the user account corresponding to the virtual card token via a look-up of the account database (paragraphs 42, 44, 50, and 54, The tokenization service 50 may receive the token and transaction data from the acquiring financial institution 20, and in response, provide the acquiring financial institution 20 the user account number associated with the token as well as other user information that may be needed to complete the transaction. Once the token and transaction details are routed to the issuing financial institution 40, the issuing financial institution 20 determines the user account associated with the token through the use of the token account database 42. The token may be stored in the user's payment device 4 (e.g., on the digital wallet) or stored on the cloud or other service through the tokenization service 50. The issuing financial institution 40 accesses the token and account database 42 to identify the user account associated with the token);
identify, based on the record, one or more parameters specifying a priority of usage of the one or more bank accounts corresponding to the record, wherein the priority of usage specifies an arranged order of the one or more bank accounts (Fig. 3-4, paragraphs 54 and 78- 79, determines if the transaction information violates any limits associated with the token or the user account. the token is associated with one or more accounts. In some embodiments, the association of the token and the one or more accounts is based on the token request, user preferences, historical trends, and the like. As illustrated at block 308, parameters are set for the tokens. The parameters include restrictions, permissions, thresholds, rules, and categories related to token users, token utilization, and types of tokens. In some embodiments, the token parameters includes merchant codes, item codes (e.g., product SKUs or other identifiers), internal codes for identifying categories of products or merchants, and other codes. Examiner notes that parameters such as restrictions, permissions, thresholds, rules, and categories related to token users, and token utilization are specified to define a best account/token to be displayed, suggested/recommended, and utilized for a transaction, which is considered as “one or more parameters specifying a priority of usage of one or more bank accounts corresponding to the user account, wherein the priority of usage specifies an arranged order of the one or more bank accounts”);
select a bank account from the arranged order of the one or more bank accounts based on the priority of usage specified by the one or more parameters (Fig. 4, paragraphs 82-85, 87, and 91, the user is allowed to select at least one token for a transaction. In other embodiments, the system provides a token recommendation to the user. The token recommendation can be based on token types (single use or multi-use), token funding sources, permissions, token use restrictions (e.g., restricted by purchase items, merchants, and so forth), and the like. In other examples, the system may determine that certain tokens are funded by a credit card account associated with reward programs or that have a certain credit maximums and may prioritize tokens or make suggestions based on this information as well. In other examples, the user inputs a transaction amount and/or other transaction data in a digital wallet and selects a token. The transaction data is compared with the token parameters. It is determined whether the transaction is within the token parameters or otherwise compliant with the requirements of the token parameters based on the comparison. The account associated with the token is switched to another account if it is determined that the transaction is not within the token parameters. For example, some tokens may be funded by a third party account, such as the user's employer's account, and the system may determine that those tokens cannot be used to fund personal or unapproved transactions. Further, if a first account has reached its credit maximum, has a limited amount of funds, is beyond or near its expiration date, has a high interest rate, or is otherwise undesirable or unavailable, the token funding can be switched to a second account. Examiner notes that the system may prioritize tokens or make suggestions based on token funding sources, permissions, token use restrictions (e.g., restricted by purchase items, merchants, and so forth), and the like, which is considered as “select a bank account from the arranged order of the one or more bank accounts based on the priority of usage specified by the one or more parameters”);
withdraw the transaction amount from the bank account selected from the one or more bank accounts via the RTP network (paragraphs 4, 45, 73, and 78, the account switch occurs in real time and at a point of sale. The issuing financial institution 40 determines if the user 2 has the funds available to enter into the transaction. a single token can be associated with or otherwise funded by a single account or funded by multiple accounts. The token-account association provides a means for funding the tokens such that when the token is used, the account associated with the token is debited or credited.); and
in response to withdrawing the transaction amount, transmit a notification to the merchant point-of-sale system indicating approval of a transaction corresponding to the virtual card token (paragraph 50, If the transaction meets the limits associated with the token or user account, then the issuing financial institution 20 allows the transaction. The issuing financial institution sends a notification of the approval or denial of the transaction back along the channels of the transaction processing system to the merchant 10, which either allows or denies the transaction.).
However, Bondesen does not disclose causing the transaction amount to be transferred to a merchant account associated with the merchant point-of-sale system at a predetermined time interval determined based on a type of the bank account associated with the merchant account; generating a virtual card token for a user account for use among a Real-Time Payment (RTP) network, the generating further comprising: receiving, from a user device associated with the user account, one or more bank accounts; verifying ownership of the user account to the one or more bank accounts using a bank validation procedure, the bank validation procedure comprising at least one of: a penny drop verification, identification verification, or open banking framework validation.
However, Misra teaches causing the transaction amount to be transferred to a merchant account associated with the merchant point-of-sale system at a predetermined time interval (In some non-limiting embodiments or aspects, first user device 102 may include one or more devices, such as computers, computer systems, and/or peripheral devices capable of being used by a merchant to conduct a payment transaction with a user. For example, first user device 102 may include a POS device and/or a POS system. For example, first financial institution system 104 may be associated with an issuer institution that issued a payment account or instrument (e.g., a credit account, a debit account, a credit card, a debit card, etc.) to a user (e.g., a user associated with first user device 102, a merchant, etc.). RTP system 110 may include a RTP network in which payments between financial institutions are settled immediately. If the parameters of the transaction match with the fetched metadata according to the rules and/or directives, an appropriate response may be generated and sent back the participants via the gateway. For example, RTP system 110 may authorize the transaction in the RTP network and transfer the payment from the at least one account to the at least one other account (e.g., perform clearing and settlement (CS) of the transaction, etc.). Fig. 1, col. 13, lines 48-col. 14, lines 64, col. 12, lines 38-45, and col. 20, lines 1-23, Claim 4).
Therefore, it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to modify Bondesen to include, causing the transaction amount to be transferred to a merchant account associated with the merchant point-of-sale system at a predetermined time interval, as taught in Misra, in order to provide a real-time solution for rule exclusions (Misra, col. 1, lines 33-34).
However, DiGangi teaches generating a virtual card token for a user account for use among a Real-Time Payment (RTP) network, the generating further comprising: receiving, from a user device associated with the user account, one or more bank accounts (RTP platforms tokenize the deposit accounts of users, such that a sender can address an RTP payment or RTP message to a token that serves as a proxy for the recipient's account. Such tokens can take the form of usernames, email addresses, phone numbers (e.g., mobile numbers), other alphabetic identifiers, other numeric identifiers, other alphanumeric identifiers, and/or the like. the driver (person 126) uses an app such as a rideshare-service app or a mobile-banking app to send the command 302 to the financial-institution system 106. In this scenario, the person 126 has previously configured their rideshare-service account to include a token that is representative of their account with the financial institution 116, or instead configured their rideshare-service account to include both the routing number and account number of that account. paragraphs 20 and 45); verifying ownership of the user account to the one or more bank accounts using a bank validation procedure, the bank validation procedure comprising at least one of: a penny drop verification, identification verification, or open banking framework validation (RTP payments and/or RTP messages are leveraged by the inclusion therewith of additional information that is useful in validating identity. To that end, the identity-validation transmission (e.g., RTP payment or RTP message) may include a particular code (e.g., password, token, etc.) that may be included in such a notification message for presentation via a user interface of, e.g., the mobile device 124. This code may be used by the person 122 to confirm their identity to the person 126. In some embodiments in which the identity-validation transmission is an RTP payment (of, e.g., a nominal amount such as a penny, a few pennies, a fraction of a penny, and/or the like.), the financial-institution system 114 may, in response to receiving that RTP payment, send an equal RTP payment to the person-122 account. paragraphs 41-42).
Therefore, it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to modify Bondesen to include, generating a virtual card token for a user account for use among a Real-Time Payment (RTP) network, the generating further comprising: receiving, from a user device associated with the user account, one or more bank accounts; verifying ownership of the user account to the one or more bank accounts using a bank validation procedure, the bank validation procedure comprising at least one of: a penny drop verification, identification verification, or open banking framework validation, as taught in DiGangi, in order to leverage real-time payments for identity validation (DiGangi, paragraph 1).
With regard to claims 2, 9, and 16, Bondesen discloses the one or more parameters identify a first bank account, a second bank account, and a limit for using the first bank account, and wherein selecting the bank account further comprises: comparing the transaction amount to the limit; determining that the transaction amount exceeds the limit; and in response to the determining, selecting the second bank account (Fig. 4, paragraphs 85, 87, and 91).
With regard to claims 3, 10, and 17, Bondesen discloses the one or more parameters identify a transaction type corresponding to the bank account selected from the one or more bank accounts, and wherein selecting the bank account further comprises: categorizing the transaction based on merchant identification data; determining that a categorized transaction type of the transaction matches the transaction type corresponding to the bank account; and in response to the determining, selecting the bank account (Fig. 4, paragraphs 34, 79, and 91, The limitations may include, limiting the transactions of the user to a single merchant, a group of multiple merchants, merchant categories, single products, a group a products, product categories, transaction amounts, transaction numbers, geographic locations, or other like limits as is described herein. The parameters include restrictions, permissions, thresholds, rules, and categories related to token users, token utilization, and types of tokens. In some embodiments, the token parameters includes merchant codes, item codes (e.g., product SKUs or other identifiers), internal codes for identifying categories of products or merchants, and other codes. the account associated with the token is switched to another account if it is determined that the transaction is not within the token parameters. In such cases, the system can automatically switch or prompt the user to switch the funding source from the third party account to the user's personal account so that the token can be used. ).
With regard to claims 4, 11, and 18, Bondesen substantially discloses the claimed invention, however, Bondesen does not disclose transmitting an API command to the RTP network to transfer the transaction amount from the bank account selected from the one or more bank accounts to the merchant account via the RTP network.
However, Misra teaches transmitting an API command to the RTP network to transfer the transaction amount from the bank account selected from the one or more bank accounts to the merchant account via the RTP network (As used herein, the term “account identifier” may include one or more primary account numbers (PANs), tokens, or other identifiers associated with a customer account. The term “token” may refer to an identifier that is used as a substitute or replacement identifier for an original account identifier, such as a PAN. As used herein, the term “application programming interface” (API) may refer to computer code that allows communication between different systems or (hardware and/or software) components of systems. For example, RTP system 110 may authorize the transaction in the RTP network and transfer the payment from the at least one account to the at least one other account (e.g., perform clearing and settlement (CS) of the transaction, etc.) , Fig. 1, col. 10, lines 64-col. 11, lines 10, col. 12, lines 38-45, col. 13, lines 48-col. 14, lines 64, and col. 20, lines 1-23).
Therefore, it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to modify Bondesen to include, transmitting an API command to the RTP network to transfer the transaction amount from the bank account selected from the one or more bank accounts to the merchant account via the RTP network, as taught in Misra, in order to provide a real-time solution for rule exclusions (Misra, col. 1, lines 33-34).
With regard to claims 5, 12, and 19, Bondesen discloses based on the storing the record of the user account, (paragraph 42, stores an association between the token and the user account number in a secure token and account database 52. The tokenization service 50 may also store limits (e.g., geographic limits, transaction amount limits, merchant limits, product limits, any other limit described herein, or the like) associated with the token that may limit the transactions in which the user 2 may enter.), transmitting the virtual card token to the user device (paragraph 81, the token is sent to the user. The token may be provided to the user via any form of communication such as voice, text, or email. The token can also be sent to a user's online account or transmitted to a mobile application such as a digital wallet or mobile online account.).
With regard to claims 6, 13, and 20, Bondesen discloses transmitting the virtual card token to a digital wallet on a user device used to interact with the merchant point-of-sale system (paragraph 81).
With regard to claims 7 and 14, Bondesen discloses receiving the virtual card token and a second transaction amount from an online shopping website (paragraph 43, After or during creation of the token the user 2 enters into a transaction with a merchant 10 using the payment device 4 (or payment instrument over the Internet).); identifying the user account corresponding to the virtual card token (paragraphs 44 and 50); identifying, based on the user account, the one or more parameters specifying usage of the one or more bank accounts (Fig. 3-4, paragraphs 78- 79); selecting a second bank account from the one or more bank accounts based on the one or more parameters (Fig. 4, paragraphs 85, 87, and 91); withdrawing the second transaction amount from the second bank account selected from the one or more bank accounts via the RTP network (paragraphs 4, 45, 73, and 78); and in response to withdrawing the second transaction amount, transmitting a notification to the online shopping website indicating approval of an online transaction corresponding to the virtual card token (paragraph 50).
Response to Arguments
Applicants' arguments filed on 03/03/2026 have been fully considered but they are not fully persuasive especially in light of the new prior art applied in the rejections.
Applicants remark that “the combination of references does not disclose generating a virtual card token for a user account for use among a Real-Time Payment (RTP) network, the generating further comprising: receiving, from a user device associated with the user account, one or more bank accounts; verifying ownership of the user account to the one or more bank accounts using a bank validation procedure, the bank validation procedure comprising at least one of: a penny drop verification, identification verification, or open banking framework validation; and responsive to the bank validation procedure succeeding, storing a record of the user account to an account database within the RTP network to link the virtual card token to the user account, wherein the record associates the user account with the virtual card token, the one or more bank accounts, and the one or more parameters, and wherein the record is keyed by the virtual card token”.
Examiner directs Applicants' attention to the office action above.
Conclusion
Please refer to form 892 for cited references.
Applicant's amendment necessitated the new ground(s) 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 mailing date of this final action.
Any inquiry concerning this communication from the examiner should be directed to Ariel Yu whose telephone number is 571-270-3312. The examiner can normally be reached on Monday-Friday 9:00am-5:00pm EST.
If attempts to reach the examiner by telephone are unsuccessful, the examiner’s supervisor, Obeid Fahd A can be reached on 571-270-3324. 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.
/ARIEL J YU/Primary Examiner, Art Unit 3627
Prosecution Insights