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 .
Continued Examination Under 37 CFR 1.114
A request for continued examination under 37 CFR 1.114, including the fee set forth in 37 CFR 1.17(e), was filed in this application after final rejection. Since this application is eligible for continued examination under 37 CFR 1.114, and the fee set forth in 37 CFR 1.17(e) has been timely paid, the finality of the previous Office action has been withdrawn pursuant to 37 CFR 1.114. Applicant's submission filed on 07/21/2026 has been entered.
Response to Amendment
Applicant’s “Amendment” filed on 07/21/2026 has been considered.
Claims 1, 8, and 15 are amended. Claims 1-20 remain pending in this application and an action on the merits follow.
Claim Rejections - 35 USC § 112
The following is a quotation of the first paragraph of 35 U.S.C. 112(a):
(a) IN GENERAL.—The specification shall contain a written description of the invention, and of the manner and process of making and using it, in such full, clear, concise, and exact terms as to enable any person skilled in the art to which it pertains, or with which it is most nearly connected, to make and use the same, and shall set forth the best mode contemplated by the inventor or joint inventor of carrying out the invention.
The following is a quotation of the first paragraph of pre-AIA 35 U.S.C. 112:
The specification shall contain a written description of the invention, and of the manner and process of making and using it, in such full, clear, concise, and exact terms as to enable any person skilled in the art to which it pertains, or with which it is most nearly connected, to make and use the same, and shall set forth the best mode contemplated by the inventor of carrying out his invention.
Claims 1, 8, and 15 are rejected under 35 U.S.C. 112(a) or 35 U.S.C. 112 (pre-AIA ), first paragraph, as failing to comply with the written description requirement. The claim(s) contains subject matter which was not described in the specification in such a way as to reasonably convey to one skilled in the relevant art that the inventor or a joint inventor, or for applications subject to pre-AIA 35 U.S.C. 112, the inventor(s), at the time the application was filed, had possession of the claimed invention. The newly proposed limitation includes “creating a surrogate transaction credential…contemporaneously with the creating the surrogate transaction credential…the surrogate credential of the virtual card token”. The specification does not describe or support a surrogate transaction credential and how can it be created is how can it be associated with the virtual card token.
Claim Rejections - 35 USC § 102
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 (i.e., changing from AIA to pre-AIA ) 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 the appropriate paragraphs of 35 U.S.C. 102 that form the basis for the rejections under this section made in this Office action:
A person shall be entitled to a patent unless –
(a)(1) the claimed invention was patented, described in a printed publication, or in public use, on sale, or otherwise available to the public before the effective filing date of the claimed invention.
Claims 1-2, 4-9, 11-16, and 18-20 are rejected under 35 U.S.C. 102 (a)(1) as being anticipated by U.S. Patent Application Publication No. 2018/0293573 to Ortiz et al.
With regard to claims 1, 8, and 15, Ortiz discloses a system, comprising:
a memory (paragraph 130); and
at least one processor coupled to the memory and configured to (paragraph 130):
generate a virtual card token for a user account for use among a Real-Time Payment (RTP) network, the generating further comprising: receive, from a user device associated with the user account, one or more bank accounts and one or more parameters for using the one or more bank accounts with a merchant point-of-sale system (paragraphs 214 and 263, In the embodiment shown, process 1900 enables payment by a user 190 of a device 110, 110′ for a transaction using one or more “funding tokens” generated dynamically (in real time) to settle payment for a transaction, using multiple debit, credit, points, and/or other funding sources through the use of dynamic card emulators (e.g., dynamic HCEs). The user is presented with an interactive graphical device 1420 in the form of a touchscreen-enabled slider 1422 that may be used by the user to designate a portion of the total transaction price by increasing or decreasing the amount of the total $40.25 to be paid using the loyalty account.);
verify 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 (paragraphs 73 and 106, The identity may be forwarded by the POS/device to a server which will verify that the ID is trusted to pay or meet other obligations using any one or more sets of payment accounts. For example, as noted above, identity verification is another possible application (e.g., the bank trusts me, you trust the bank, so you, arbitrary third party, trust me). Each bank or FSP 160 may be validated and verified with the other banks or FSPs 160 in the trusted platform system 100.); and
responsive to the bank validation procedure succeeding: (i) create a surrogate transaction credential of the virtual card token for the user account to provide to the merchant point-of-sale system (paragraphs 71 and 82-84, The identity may be forwarded by the POS/device to a server which will verify that the ID is trusted to pay or meet other obligations using any one or more sets of payment accounts. In some cases, a payment credential sent to a merchant server may be an exact copy of a token previously stored in the mobile wallet in association with a particular payment method. Alternatively, or in addition, the virtual wallet application may generate a single-use token for the transaction that is wholly or partially derived from, or otherwise associated with, the token permanently stored in the virtual wallet and respond to the merchant application with the single-use token rather than the permanent token. For example, in addition to one or more separate credit card types, or protocols, payment tokens linked to individual or multiple bank accounts, and/or lines of credit may be generated and stored by the mobile wallet for use in mobile payments, including secure in-app payments. In general, each authorized method of payment may be associated with one or more different payment tokens); and
(ii) contemporaneously with the creation of the surrogate transaction credential, store 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 surrogate credential (paragraphs 83-84, 156, and 157, In some cases, the payment credential used to complete the transaction (either directly or through generation of a single-use token) can be generated in advance, and stored in the virtual wallet prior to commencement of the transaction. For example, such certificate data sets can comprise any data associated uniquely with any one or more of the device(s) 132, 134, 136, 130 and/or a specific payment account(s) associated with such device(s). Such certification/identification data can include, for example, names, ‘secret’ personal information, serial numbers, random or pseudo-random codes, account numbers, etc. Copies of such certificate data sets may be provided to the device(s) 132, 134, 136, 130 and stored in secure memory associated with the trusted platform 120, in association with further identifiers associated with the device(s) 132, 134, 136, 130, one or more merchants or other entities associated with the device(s) 132, 134, 136, 130, and/or one or more accounts associated with such entities.);
receive the virtual card token and a transaction amount from the merchant point-of-sale system (paragraph 275, at 1913 use the funds to generate a funding token for payment of the merchant in satisfaction of the requested transaction. Such a token can comprise data representing a token value, for example a value corresponding to the transaction amount payable to the merchant, and one or more identifiers associated with one or more sources of the funds to be used to pay the merchant.);
retrieve, 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, wherein the look-up comprises extracting the record using the virtual card token (paragraph 158, For example, a payment token data set may be received by a trusted platform 110 from a trusted device 110′, 130′, the token comprising a certification data set which may be looked up in a database 125, along with associated user and/or account information, for use in processing payments and other transactions.);
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 using the one or more parameters, wherein the priority of usage specifies an arranged order of the one or more bank accounts (paragraphs 213 and 314, options 1408 presented in such list(s) may be selected by any of device(s) 110, 120, 130, 160, or combination(s) thereof, according to criteria previously selected by user(s) 190 and/or any of such devices, including for example preferred form of debit, credit, or non-monetary value accounts; availability of funds, etc. For example, a preference can comprise a simple ordering or ranking of accounts to which a specific user (human or juristic) has authorized access, to be applied inflexibly, optionally conditioned upon the availability of adequate funds, etc., and/or can comprise more complex logic such as if/then statements to apply specific payment methods with specific vendors (merchants), or it can be conditioned on the availability or maintenance of specific thresholdor minimum amounts in particular accounts, and/or maximum balances not to exceed on credit account(s).);
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 (paragraph 314-315, An authorized account user can also be enabled to allow the FI 120, 160 that administers one or more of its accounts to select method(s) of payment already registered with, or otherwise associated with, such authorized account user that the FI believes is most optimal or otherwise advantageous for its client for a given transaction. );
withdraw, via the RTP network, the transaction amount from the selected bank account selected from the one or more bank accounts via the RTP network (paragraphs 164 and 255, the numbers of accounts to be used and the amount to be drawn from each. The user can do so by, for example, using an interactive slider graphical device 1422 to determine how much of the funding is to be drawn from the debit or credit “card” account and how much from the rewards point balance.); 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 surrogate credential of the virtual card token and cause the transaction amount to be transferred to a merchant account associated with the merchant point-of-sale system at a predetermined time interval (paragraphs 160, 164 and 455, the purchase is complete, and the customer receives a push notification providing details and/or confirmation of the purchase. Affording such users time in which to change or affirm which account(s) are to be used can provide time for user(s) to ensure that charges will clear designated accounts, decide whether to apply awards or loyalty points to a transaction, or otherwise determine the numbers of accounts to be used and the amount to be drawn from each. the trusted platform 120 may work offline to complete final confirmation and clearance of the tranasctions, either by offsetting a day's or other accumulation of such transactions against one another, and settling balances with fourth-party platforms 160, or by simply working with one or more fourth-party platforms 160 to balance payments at end of day or other accounting period.).
With regard to claims 2, 9, and 16, Ortiz 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 (paragraph 214 and 322, it can be conditioned on the availability or maintenance of specific threshold or minimum amounts in particular accounts, and/or maximum balances not to exceed on credit account(s).).
With regard to claims 4, 11, and 18, Ortiz discloses 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 (paragraphs 150 and 255, The use of such universal APIs can be a significant advantage: by working, for example, in accordance with common or universal token and/or HCE credential protocol(s), universal APIs 116 can offer purchasers such as users 190 a wide range of payment options at the time of executing transactions. The user can do so by, for example, using an interactive slider graphical device 1422 to determine how much of the funding is to be drawn from the debit or credit “card” account and how much from the rewards point balance.).
With regard to claims 5, 12, and 19, Ortiz discloses based on the storing the record of the user account, transmitting the virtual card token to the user device (paragraph 84).
With regard to claims 6, 13, and 20, Ortiz discloses transmitting the virtual card token to a digital wallet on a user device used to interact with the merchant point-of-sale system (paragraphs 83-84).
With regard to claims 7 and 14, Ortiz discloses receiving the virtual card token and a second transaction amount from an online shopping website (paragraphs 154 and 181, a user may navigate to a web page or website using, e.g., any suitably-configured I/O devices 610 as described herein. After the user 190 has generated a suitably-configured transaction request data set (or ‘requested transaction data set’), comprising for example data representing one or more items the user wishes to purchase, and perhaps a full or partial description thereof, along with item, subtotal, and/or total purchase prices, by for example selecting the items for addition to the merchant application's virtual shopping cart, and has initiatied a payment (e.g., ‘checkout’) process, merchant application 115 may display an option to the user to pay for the transaction using a wallet application 112, 612 installed in mobile OS 608. In some cases, as described herein, payment token(s) may also be provided to a merchant backend 136, 136′, 910 directly from a bank or trusted platform 120, 905 following identity verification of a user or user's mobile device 110, 600.);
identifying the user account corresponding to the virtual card token (paragraph 158, a payment token data set may be received by a trusted platform 110 from a trusted device 110′, 130′, the token comprising a certification data set which may be looked up in a database 125, along with associated user and/or account information, for use in processing payments and other transactions.);
identifying, based on the user account, the one or more parameters specifying usage of the one or more bank accounts (paragraphs 314, the availability or maintenance of specific threshold or minimum amounts in particular accounts, and/or maximum balances not to exceed on credit account(s).);
selecting a second bank account from the one or more bank accounts based on the one or more parameters (paragraph 315, Preferences can also be specified to enable automatic or semi-automatic splitting of transaction payment across multiple payment methods. For example, a financial account administrator 120, 160 can parse a transaction request data set to determine an amount due and a funding preference to be suggested for confirmation by the user, or automatically applied in satisfaction of the request, and access multiple accounts associated with a purchaser to determine the best, or otherwise preferred split funding arrangement to be applied.);
withdrawing the second transaction amount from the second bank account selected from the one or more bank accounts via the RTP network (paragraph 367, the user can invoke a second, trusted wallet application 112′, and complete a generate a payment instruction data set with which is consistent with the merchant's requirements but draws funds from one or more of the user's desired accounts.); 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 455, the customer receives a push notification providing details and/or confirmation of the purchase).
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 3, 10, and 17 are rejected under 35 U.S.C. 103 as being unpatentable over U.S. Patent Application Publication No. 2018/0293573 to Ortiz et al., in view of U.S. Patent Application Publication No. 2016/0196549 to Mizhen et al.
With regard to claims 3, 10, and 17, Ortiz substantially discloses the claimed invention, however, Ortiz does not disclose 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.
However, Mizhen teaches 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 (The invention provides a computer-implemented method to select a preferred card for a purchase based on a merchant category. In the exemplary method, the computer associates a plurality of financial accounts with an account of a user; associates a merchant category with a financial account associated with the user account; and receives data from a transaction. The computer can maintain a database of merchant categories; determine the category of the merchant based on the data associated with the transaction; and extract data to identify the merchant, such as merchant name, address, or telephone number. The computer can determine the geo-location of the user device and determine the merchant identify from the location. The computer can determine a merchant category of the merchant from the merchant identity; select the financial account associated with the merchant category of the merchant; and communicate the financial account selected to conduct the transaction., abstract).
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 Ortiz to include, 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, as taught in Mizhen, in order to select a preferred payment instrument in a contactless payment transaction based on a category of the merchant (Mizhen, paragraph 1).
Response to Arguments
Applicants' arguments filed on 07/21/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 receiving, from a user device associated with the user account, one or more parameters for using the one or more bank accounts with a merchant point-of-sale system; creating a surrogate transaction credential of the virtual card token for the user account to provide to the merchant point-of-sale system; and identifying, based on the record, a priority of usage of the one or more bank accounts corresponding to the record using the one or more parameters”.
Examiner directs Applicants' attention to the office action above.
Conclusion
Please refer to form 892 for cited references.
Any inquiry concerning this communication or earlier communications from the examiner should be directed to ARIEL J YU whose telephone number is (571)270-3312. The examiner can normally be reached 11AM - 7PM (M-F).
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, 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