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 Claims
Applicant’s submission filed 4/15/25 has been entered. Claims 1-20 are cancelled. Claims 21-40 are presented for examination.
Information Disclosure Statement
The information disclosure statement (IDS) submitted on 3/31/25 has been considered by the examiner.
Claim Rejections - 35 USC § 103
The following is a quotation of 35 U.S.C. 103 which forms the basis for all obviousness rejections set forth in this Office action:
A patent for a claimed invention may not be obtained, notwithstanding that the claimed invention is not identically disclosed as set forth in section 102, if the differences between the claimed invention and the prior art are such that the claimed invention as a whole would have been obvious before the effective filing date of the claimed invention to a person having ordinary skill in the art to which the claimed invention pertains. Patentability shall not be negated by the manner in which the invention was made.
Claims 1-27, 29-38 are rejected under 35 U.S.C. 103 as being unpatentable over Evans et al. (US 20140279474 A1), in view of Pareek (US 20170053265 A1).
Re-claims 21, 29, Evans et al. teach --A system, comprising: one or more processors, coupled with memory, to:
--identify a plurality of digital accounts linked with a paycard, the plurality of digital accounts comprising at least a digital health account;
(see e.g. [0019] The MULTI-PURSE ONE CARD TRANSACTION technology (hereinafter "MPOC") provides a payment platform which processes a multi-purse consumer vehicle for both restricted-use accounts and non-restricted-use accounts. For example, the multi-purse consumer vehicle may comprise a prepaid card, an electronic mobile wallet, and/or the like, which stores information with regard to multiple consumer accounts.
[0023] Examples of a restricted use account may comprise Flexible Savings Accounts (FSA), one or more Health Savings Accounts (HSA), Line of Credit (LOC), one or more health reimbursement accounts (HRA), one or more government insurance programs (i.e., Medicare or Medicaid))
--determine a payment number associated with the paycard, the payment number used to route paycard data to one or more networked devices associated with the plurality of digital accounts based on a selection of one or more of the plurality of digital accounts on an interface displayed on an output device;
(see e.g. [0054] Within implementations, upon receiving the user's account selection, the merchant 210 (e.g., the smart PoS terminal, etc.) may generate a payment request message 216 to the MPOC server 220 based on the received purchase item information and the retrieved account usage rules. --The transaction data may include the customer's common account number that is the same for some or all of restricted-use accounts and non-restricted-use accounts. Advantageously, a customer can carry only one card, but, as described below, the card processing network intelligently determines how to route message 216 to the appropriate issuer and determines which of the customer's account will provide a source of funds for a purchase transaction.)
[0075] In one implementation, the MPOC server 220 may provide an account listing 235 (add a data structure) to the user, e.g., see 585 in FIG. 5C, and the user may submit an account selection 214 by tapping on an account.
[0035] For example, the mobile wallet may detect the consumer's location at a healthcare provider 108 via its GPS component, and thus may recommend healthcare benefit accounts for consumer payment by highlighting the accounts "FSA" 111 and "HSA". When the consumer selects the FSA account 111, the wallet may display an available balance 112 of the FSA account. The consumer may then tap on a "pay" button 113 of the mobile wallet to initiate a consumer payment transaction.
[0020] Because the same account number is used for multiple accounts, intelligence is required to route a payment authorization request message to the appropriate issuer processor for approval of the purchase transaction.
[0022] If determined to be an eligible provider, the example embodiments may retrieve routing information for the associated restricted-use issuer processor for routing of the payment authorization request message thereto. ---Thus, even though a common account number is assigned to each of the user's restricted-use and non-restricted accounts, the example embodiments intelligently direct the payment authorization request messages to the appropriate issuer processor for processing.)
claim 29. The system of claim 21, wherein the digital health account comprises a health savings account (HSA).
(see e.g. [0025] For example, the MPOC processing platform may facilitate payment with healthcare restricted-use accounts (e.g., FSA, HSA, etc.) when a user/patient visits a healthcare provider.)
Evans et al. teach do not teach the following limitations as claimed.
However, Pareek teaches A system, comprising: one or more processors, coupled with memory, to:
--identify a plurality of digital accounts linked with a paycard, the plurality of digital accounts comprising at least a digital identification account;
(see e.g. [0051] A system 10 for implementation of an embodiment of the present invention is illustrated in the form of a block diagram in FIG. 1. The system enables a user to utilise their individual credential device both for its ordinary purpose of gaining access to commercial facilities (e.g. unlocking access controlled doors), as well as for conducting contactless financial transactions (e.g. buying merchandise). For the purposes of the following description the credential device will be referred to as a ‘access card’ 100, but in practice may be in the form of a card, badge, fob or other physical manifestation. The access card comprises a proximity device that includes a coil antenna coupled to internal circuitry, and is adapted to wirelessly communicate with a reader circuit when located in the proximity thereof.).
---responsive to a second request comprising the payment number, execute a clock-in or clock-out operation using the paycard by transmitting the paycard data to at least one of the one or more networked devices corresponding with the digital identification account based on the selection.
(see e.g. [0042] The employer can use an embodiment to help integrate e-commerce web-sites, enabling employees to use their employer log ins for e-commerce transactions.
[0055] In use, when the employee presents access card 100 to the card reader 22, the access card code is provided to the control circuit 24. The control circuit 24 communicates the access card code to the security server 28 which consults the corresponding database record. If the access privileges for that employee include the door at which the card reader 22 is located, then the control circuit 24 activates the door latch 26 and permits the employee access.)
Therefore, it would have been obvious to a person of ordinary skill in the art, before the effective filing date of the claimed invention, to modify the non-restricted-use accounts of Evans et al., with the features of Pareek’s employee access card as a simple substitution of one known element for another to obtain predictable results (see KSR) and furthermore, the system enables a user to utilise their individual credential device both for its ordinary purpose of gaining access to commercial facilities (e.g. unlocking access controlled doors), as well as for conducting contactless financial transactions
Re-claim 22, Evans et al. teach--- The system of claim 21, wherein the one or more processors further:
--identify one or more eligible operations corresponding to the digital health account; and
--execute the payment operation by performing at least one of the one or more eligible operations using funds available to the digital health account.
(see e.g. [0022] Subsequent to receiving the payment authorization request message, the restricted-use issuer processor may determine whether to approve the transaction based on whether the restricted-use account has sufficient funds and whether the products/services are appropriate for purchase using the restricted-use account. Based on these determinations, the restricted-use issuer may then fully approve, partially approve, or decline the authorization request message.
[0030] In one implementation, a consumer 102 may engage a mobile wallet 103 to pay for the purchase at a PoS terminal 109 of the merchant. In one implementation, the mobile wallet 103 may provide a prompt alert 111 to the consumer via a mobile consumer interface, showing that part or all of the consumer's purchases are eligible for one or more restricted-use accounts that have been enrolled in the consumer's mobile wallet. For example, as shown in FIG. 1B, when the consumer has purchased pharmaceutical products such as "NyQuil" and "Penicillin," the mobile wallet may notify the consumers that such drugs are eligible for FSA usage. In one implementation, if the consumer selects "Yes" to proceed with payment with FSA, the consumer may need to split the purchase to pay for the eligible items 117a in the shopping cart with his FSA account and submit an amount of the drugs.).
Re-claim 23, Evans et al. teach-- The system of claim 21, wherein the one or more processors further:
--transmit, for display, the interface comprising a plurality of graphical objects corresponding to the plurality of digital accounts;
(see e.g. [0035] For example, the mobile wallet may detect the consumer's location at a healthcare provider 108 via its GPS component, and thus may recommend healthcare benefit accounts for consumer payment by highlighting the accounts "FSA" 111 and "HSA". When the consumer selects the FSA account 111, the wallet may display an available balance 112 of the FSA account. The consumer may then tap on a "pay" button 113 of the mobile wallet to initiate a consumer payment transaction.
[0028] In one implementation, when a consumer 101 proceeds to checkout for his/her purchase, e.g., at a PoS terminal of a merchant store, an online shopping checkout page, etc., the consumer 101 may need to select an account to pay for the his/her shopping cart. In one implementation, the consumer 101 may get confused to select an appropriate card for the purchase 102, e.g., when to apply a FSA account, when to apply a membership card, etc. In one implementation, the MPOC platform may provide a streamline process for the consumer 101 to instantiate his/her wallet at a PoS terminal 109, which may automatically select an account from the wallet 104.)
--identify, responsive to a first entry or input using the interface, a first selection of at least one of the plurality of graphical objects corresponding with the digital health account; and --determine the first request corresponds with a transaction based on the payment number or the first selection.
(see e.g. [0030] In one implementation, if the consumer selects "Yes" to proceed with payment with FSA, the consumer may need to split the purchase to pay for the eligible items 117a in the shopping cart with his FSA account and submit an amount of the drugs. For example, the consumer may view a list of the FSA eligible items 113a, and a list of healthcare restricted-use accounts such as FSA, HSA, etc. If the consumer selects to pay with FSA, the consumer may view the remaining balance of the FSA account 112. Upon selecting to pay 113, the consumer may submit the transaction to pay with FSA account for the healthcare products 113a.)
Re-claim 24, Evans et al. teach --The system of claim 21, wherein the one or more processors further:
--identify the first request corresponds with performing the payment operation;
--responsive to identifying the first request corresponds with performing the payment operation, execute the payment operation by causing the at least one of the one or more networked devices corresponding to the digital health account to perform a transaction using the payment number; and--transmit, for display, at least a portion of the paycard data based on execution of the transaction.
(see e.g. [0054] Within implementations, upon receiving the user's account selection, the merchant 210 (e.g., the smart PoS terminal, etc.) may generate a payment request message 216 to the MPOC server 220 based on the received purchase item information and the retrieved account usage rules. --The transaction data may include the customer's common account number that is the same for some or all of restricted-use accounts and non-restricted-use accounts.
[0142] For example, as shown in FIG. 5C, if a user 502 goes to a primary care physician on Jun. 8, 2015, i.e., more than half a year to the end date to his FSA, and a medical bill indicates a co-pay amount of $50.00 (e.g., at 581), the user may enter $50.00 into the MPOC mobile application and indicate it is medical purchase. Upon verifying the eligibility of medical purchase, the MPOC 520 may retrieve applicable healthcare restricted use accounts, and determine the user has his FSA, HSA and LOC accounts enrolled 582. The MPOC may then update the balance information of each account with the account sponsors 570.)
[0144] The MPOC may send a report summary to the user including the updated remaining balance of the accounts after payment, and/or the like.)
Re-claims 25, 26, Evans et al. teach -- provide, for display, the interface comprising a plurality of graphical objects corresponding to the plurality of digital accounts;
(see e.g. [0027] FIG. 1A provides a block diagram illustrating aspects of user usage of various accounts within embodiments of the MPOC. In one implementation, a consumer 101 may have various payment accounts associated with various payment cards. For example, the consumer 101 may possess accounts and payment cards such as a bank card 102a (e.g., a bank credit card, a debit card, a checking card, etc.), a restricted-use account card 102b (e.g., HSA, FSA, LOC, government food stamp, voucher, etc.), mileage or club membership card 102c (e.g., Starbucks, Continental, JetBlue, etc.), gift cards (e.g., Macy's, JCPenny, etc.), and/or the like.
[0035] When the consumer selects the FSA account 111, the wallet may display an available balance 112 of the FSA account. The consumer may then tap on a "pay" button 113 of the mobile wallet to initiate a consumer payment transaction.)
Evans et al. do not teach the following limitation.
However, Pareek teaches --- The system of claim 21, wherein the one or more processors further:
--identify, responsive to a second entry or input using the interface, a second selection of at least one of the plurality of graphical objects corresponding with the digital identification account; and
-- determine the second request corresponds with an identification function based on the payment number or the second selection.
(see e.g. [0053] When the employee presents their access card 100, a card reader circuit 22 communicates wirelessly with the access card by way of a radio-frequency (RF) interface so as to elicit the access card code. The card reader circuit 22 may be positioned, for example, next to an access controlled door to the corporate premises, wherein the lock on the door is actuated by an electrically controlled door latch 26. Operation of the door latch 26 is controlled by a control circuit 24 which is coupled to the card reader circuit 22 as well as a corporate security server 28.
[0056] The exemplary system 10 is constructed to enable the access card 100 to additionally be used for contactless financial transactions, as described hereinbelow. Item 40 in FIG. 1 represents a retail merchant such as a store, café or the like.);
-- The system of claim 21, wherein the one or more processors further:
--identify the second request corresponds with performing the clock-in or clock-out operation;
--responsive to identifying the first request corresponds with performing the clock-in or clock-out operation, execute the clock-in or clock-out operation by causing the at least one of the one or more networked devices corresponding to the digital identification account to perform an identification function using the payment number; and
[0055] In use, when the employee presents access card 100 to the card reader 22, the access card code is provided to the control circuit 24. The control circuit 24 communicates the access card code to the security server 28 which consults the corresponding database record. If the access privileges for that employee include the door at which the card reader 22 is located, then the control circuit 24 activates the door latch 26 and permits the employee access. Access cards, card readers and systems of the kind described above are available from HID Corporation, for example, from which further detailed information about the components and functions are available.)
Regarding the following limitation—"cause, via the interface, a display of at least a portion of the paycard data based on performance of the identification function”, it is considered an obvious variation of Pareek to display a portion of the paycard data based on performance of the identification function since Pareek teaches [0078] Hardware logic may also be incorporated into display screens for implementing embodiments of the invention.
Therefore, it would have been obvious to a person of ordinary skill in the art, before the effective filing date of the claimed invention, to modify Evans et al., and include the steps cited above, as taught by Pareek, in order to enables a user to utilise their individual credential device for its ordinary purpose of gaining access to commercial facilities (e.g. unlocking access controlled doors. (see e.g. Pareek [0051]).
Re-claim 27, Evans et al. teach --The system of claim 21, wherein the paycard data comprises one or more of the payment number, account data of the plurality of digital accounts, card data of a plurality of cards linked with the plurality of digital accounts, device information, identification information, health information, user identifiers, and addresses, and -wherein the plurality of cards comprise at least a health card linked with the digital health account and an identification card linked with the digital identification account.
(see e.g. [0019] The MULTI-PURSE ONE CARD TRANSACTION technology (hereinafter "MPOC") provides a payment platform which processes a multi-purse consumer vehicle for both restricted-use accounts and non-restricted-use accounts. For example, the multi-purse consumer vehicle may comprise a prepaid card, an electronic mobile wallet, and/or the like, which stores information with regard to multiple consumer accounts.
[0020] The multi-purse consumer vehicle may store a common account number associated with some or all of a customer's restricted-use accounts and non-restricted-use accounts.
[0023] Examples of a restricted use account may comprise Flexible Savings Accounts (FSA), one or more Health Savings Accounts (HSA), Line of Credit (LOC), one or more health reimbursement accounts (HRA), one or more government insurance programs (i.e., Medicare or Medicaid), various private insurance--rules, a supplemental nutrition assistance program (SNAP) account, a temporary assistance for needy families (TANF) account
[0004] A restricted-use account is a financial account which is administered to restrict use of the account to purchase a qualified category of consumer goods and services. A flexible spending account (FSA) is a restricted-use account that is used exclusively for medical expenses and dependent care. )
Re-claims 30, 31, Evans et al. teach --The system of claim 21, wherein the one or more processors further:--provide a gateway system configured to link the paycard with the plurality of digital accounts; and --route, using the gateway system, the paycard data to the one or more networked devices associated with the plurality of digital accounts based on the selection.
(see e.g. [0115] For example, the user 402 may submit a registration request 442a to the MPOC server 420 in order to add a restricted-use account (e.g., FSA/HSA, LOC, Medicare, Medicaid, employee benefit program, food stamp, etc.) to the electronic wallet.
[0020] Because the same account number is used for multiple accounts, intelligence is required to route a payment authorization request message to the appropriate issuer processor for approval of the purchase transaction.
[0054] Advantageously, a customer can carry only one card, but, as described below, the card processing network intelligently determines how to route message 216 to the appropriate issuer and determines which of the customer's account will provide a source of funds for a purchase transaction.)
The system of claim 21, wherein the one or more processors further:
--provide, for display on the interface of the output device, a notification corresponding to one or more eligible operations associated with the digital health account.
(see e.g. [0138] In another implementation, if the product code and/or terminal ID shows a healthcare purchase, the MPOC may determine a recommended plan based on user specified rules. For example, if the user prefers to pay with FSA, the MPOC may determine whether there is FSA 555 enrolled in the wallet. If yes, the MPOC may send a balance inquiry 556 to the account issuer 570, which may verify the account credentials (e.g., a token, etc.) 557 and return the available balance 558. The MPOC may proceed to determine whether there is sufficient balance 560. If yes, the MPOC may put FSA on top of a recommended account list 563. If not, the MPOC, may recommend FSA with the remaining available balance 568. The MPOC may query for other enrolled restricted use accounts 566 in a similar manner.
[0139] In a further implementation, the MPOC may determine if there is user specified goods (e.g., as shown at the rules specified by the user in 442a in FIG. 4A, etc.), and may put user defined priority account at the top of the recommendation list 566.
[0140] In one implementation, the MPOC may generate a prioritized list of accounts 572 and presented to the user 573 in the wallet payment page, e.g., as illustrated in FIGS. 5C-5D.)
Claim 32 recites similar limitation as claim 21, and is therefore rejected under the same arts and rationale.
Claim 33 recites similar limitation as claim 22, and is therefore rejected under the same arts and rationale.
Claim 34 recites similar limitation as claim 23, and is therefore rejected under the same arts and rationale.
Claim 35 recites similar limitation as claim 24, and is therefore rejected under the same arts and rationale.
Claim 36 recites similar limitation as claim 25, and is therefore rejected under the same arts and rationale.
Claim 37 recites similar limitation as claim 26, and is therefore rejected under the same arts and rationale.
Claim 38 recites similar limitation as claim 27, and is therefore rejected under the same arts and rationale.
Claim 40 recites similar limitation as claim 21, and is therefore rejected under the same arts and rationale.
Claims 28, 39 are rejected under 35 U.S.C. 103 as being unpatentable over Evans et al. (US 20140279474 A1), in view of Pareek (US 20170053265 A1), in further view of Purves (US 20160232600 A1).
Re-claim 28, Evans et al. teach -- The system of claim 21, comprising wherein the one or more processors further:
--generate, using the neural network and based on analyzing the transaction history, a plurality of recommendations for using funds available to the plurality of digital accounts.
(see e.g. [0049] For example, when the merchant is equipped with a smart PoS terminal, the terminal may query for a list of eligible types of restricted-use accounts for each purchase item based on the purchase item's item category type code, to determine whether the restricted-use account may be applied to purchase the item. In one implementation, the PoS terminal may generate a restricted-use account white list matching status 206, which may comprise information as to a recommended restricted-use account that may be applied to the item
[0074] The MPOC server 220 may then query a user database for user enrolled account, and the information retrieved by the MPOC from the online databases is processed by an optimization algorithm that operates on the rules in the retrieved information. The MPOC may derive a recommendation that includes a currency payment amount to pay against the balance due bill respectively from each said currency balance of the one or more accounts issued by respective issuers.
[0134] In another implementation, the MPOC may retrieve item category related usage rules, and group purchase items into categories 510. For each item category 512, the MPOC may query for an applicable account as prescribed by a usage rule 515, e.g., healthcare products for FSA account, grocery items for food stamp, etc. If there is an account applicable for the item category, the MPOC may associate the account as a recommended account 516.
[0135] In one implementation, the MPOC may provide an account recommendation list 528 for the user to select, and/or confirm the recommended account to proceed with payment
Evans et al., in view of Pareek, do not teach the following limitations.
However, Purves teaches --determine a transaction history of the plurality of digital accounts based on a plurality of operations executed using the paycard;
--analyze the transaction history using a machine learning system; (see e. g. [0031] In some implementations, the client 700 may automatically determine a suggested payment method to be displayed to the user, and retrieve the associated payment method information 730 (e.g., full or partial credit card number, expiration date, billing address, nickname, card art, etc.). The suggested payment method may be determined based on the user's last-used or default payment method information. For example, the client 700 may identify the last-used or default payment method in any conventional way known to one of ordinary skill in the art (e.g., the user's account may include a field specifying the last-used or default payment method, or each of the user's registered payment methods may include a flag indicating whether it is the default or last-used payment method). In some other implementations, the suggested payment method may be determined using machine learning or by some other logic-based decision.)
Therefore, it would have been obvious to a person of ordinary skill in the art, before the effective filing date of the claimed invention, to modify Evans et al., in view of Pareek, and include the steps cited above, as taught by Purves, in order to improve the way in which merchants persist and use customers' payment method information. (see e.g. [0004]).
Evans et al., in view of Pareek, in further view of Purves do not teach the neural network feature.
However, Evans et al. teach deriving a recommendation for currency payment amount from one or more accounts using an optimization algorithm [0074] . Purves teaches “the suggested payment method may be determined using machine learning or by some other logic-based decision”.
Therefore, it is considered an obvious variation of Evans et al., in view of Purves to include a neural network for analyzing the transaction history. [0031]. No unpredictable results are foreseen.
Claim 39 recites similar limitation as claim 28, and is therefore rejected under the same arts and rationale.
Conclusion
Any inquiry concerning this communication or earlier communications from the examiner should be directed to LUNA CHAMPAGNE whose telephone number is (571)272-7177. The examiner can normally be reached M-F 8:00-5:00.
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, Florian Zeender can be reached at 571 272-6790. 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.
/LUNA CHAMPAGNE/Primary Examiner, Art Unit 3627
June 3, 2026
Prosecution Insights