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 11/24/2025 has been entered.
Response to Amendment
Applicant’s “Response to Amendment and Reconsideration” filed on 10/22/2025 has been considered.
Claims 1-20 are pending in this application and an action on the merits follows.
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-20 are rejected under 35 U.S.C. 103 as being unpatentable over Ready et al. (US Patent Publication No. 2018/0253713), in view of Chumbley (WO Patent Publication No. 2018075630).
Regarding Claims 1, 11 and 20, Ready teaches
a user accounts database; [(user profile, [21], and
a merchant payment system configured to communicate with a plurality of user devices and a plurality of digital wallet provider systems, (the system 100 includes a user device 120 (e.g., a smartphone), a merchant server or device 130, a digital wallet provider server 170, and at least one service provider server or device 180 (e.g., network server device) in communication over the network 160, [16], the merchant payment system comprises a control circuit configured to, (Digital wallet provider server 170 maintains one or more accounts in an account database 172, each of which may include account information 174 associated with individual users (e.g., user 102), [32], …The service provider server 180, in one embodiment, may be configured to maintain one or more user accounts and merchant accounts in an account database 192, each of which may include account information 194 associated with one or more individual users (e.g., user 102) and merchants, [36]; account information 194 also includes user purchase profile information such as account funding options and payment options associated with the user 102 (e.g., various digital wallets used by the user, [36]);
associate a user account with a plurality of digital wallet accounts in the user accounts database, (the service provider server 180 receives the request and identifies one or more digital wallets associated with user 102, [44])
wherein each digital wallet account is associated with a different digital wallet provider, (variety of electronic wallet providers have come on the market to attempt to simplify this shopping experience for the consumer. While there will likely be consolidation of these offerings in the future, it is also very likely that multiple electronic wallet options will be available, [4])
receive a transaction request from the user account; (the user 102 may conduct financial transactions (e.g., account transfers or payments) with the digital wallet provider server 170 and/or the service provider server 180 via the user device 120, [17-18])
receive a charge amount from a POS system for a transaction; (the merchant associated with the purchase sends a purchase request to the service provider server 180. The request asks for payment information and/or funding information. The purchase request can also include information regarding the purchase, such as name and/or description of each product or service, price for each product, total price, [43]);
pair the charge amount from the POS system to the transaction request from the user account; (the service provider server 180 receives the request and identifies one or more digital wallets associated with user 102, [44]);
select a digital wallet provider from the plurality of digital wallet accounts associated with the user account based on digital wallet preferences retrieved from the user accounts database; (the service provider may access the user's purchase profile in database 192 to retrieve the digital wallets the user 102 has used in the past…. the service provider server 180 determines one or more recommended digital wallets from the one or more identified digital wallets. In several embodiments, the service provider also prioritizes or ranks the digital wallets so that the most applicable digital wallet is made more prominent than the other wallets….. determine which digital wallet(s) should be recommended for a given user… he criteria may include a user's authentication with one or more major online identity(ies) providers such as Google®, Facebook®, etc. … A user may want to use a more personal type of wallet when checking out of one kind of store, and a more business type of wallet when making a more business type purchase, [45-47]….Wallet providers can partner with merchants to provide deals in some circumstances to promote their wallet. For example, the service provider can examine how different digital wallets affect reward programs, perks, discounts, spending limits, etc. The service provider can select digital wallets based on which wallets are most advantageous to the user…. the presentation may account for a merchant preference to differentiate the one or more recommended digital wallets for the given consumer from other digital wallets, [65-66], the service provider server 180 includes a digital wallet application 186. The digital wallet application 186 receives purchase requests from merchants, identifies digital wallets associated with user 102, determines which digital wallets are most applicable to user 102, and provides merchants with the most applicable digital wallets, [39]).
automatically, in response to receiving the transaction request and the charge amount, send a payment authorization request to a digital wallet provider system associated with the digital wallet provider for payment authorization, the payment authorization request comprises digital wallet account information retrieved from the user accounts database; (user 102 may have an account with the service provider that allows user 102 to use the service provider for making payments to merchants that allow use of authentication, authorization, and payment services of the service provider as a payment intermediary, [31], the service provider server 180 includes a digital wallet application 186. The digital wallet application 186 receives purchase requests from merchants, identifies digital wallets associated with user 102, determines which digital wallets are most applicable to user 102, and provides merchants with the most applicable digital wallets. Determination of which wallets should be presented to the user 102 can depend on a variety of factors, such as user location, type and amount of purchase), [39], Purchase request to the service provider server which includes detailed information about the purchase which effectively shows where the charge amount for the transaction is established, [42-44].
communicate a result of the payment authorization to the POS system to complete the transaction, (Fig. 2, 3B),
wherein the user accounts database and the merchant payment system are part of a merchant payment network, and the digital wallet provider system as external system, ( service provider, in cooperation with digital wallet providers, provides a simplified interface for a merchant to support multiple wallets via the service provider's application programming interface (API), [12], The user profile may be updated with each financial and/or information transaction (e.g., payment transaction, purchase transaction, etc.) achieved through use of the user device 120, [21], (teaches merchant payment service provider and user account data maintained within that provider system). Further, merchants will need to support all major wallets and make them available to consumers in their purchase flow, [4-5], a digital wallet provider server 170, and at least one service provider server or device 180 (e.g., network server device) in communication over the network 160, [16], (teaches digital wallet providers are external to the merchant/service provider system and communication occurs across a network boundary).
Ready substantially discloses the claimed invention, however does not explicitly disclose wherein at least one of the plurality of digital wallet accounts is associated with two or more payment methods, and wherein two or more of the digital wallet accounts each includes at least one bank card as a payment method; store, with the user account, a digital wallet customer token for a digital wallet account of the plurality of digital wallet accounts, the digital wallet customer token being received from a digital wallet provider system of the digital wallet account; the payment authorization request comprises digital wallet account information, including the digital wallet customer token retrieved from the user accounts database; the digital wallet provider system is a third-party system outside of the merchant payment network.
Ready teaches the service provider server 180 includes a digital wallet application 186. The digital wallet application 186 receives purchase requests from merchants, identifies digital wallets associated with user 102, determines which digital wallets are most applicable to user 102, and provides merchants with the most applicable digital wallets, [39]);
However, Chumbley teaches tokens that represent the entered account information may be stored in user device 120 and/or digital wallet database 142 and linked to the created account (e.g. digital wallet account), [60]; "payment token" may include an identifier for a payment account that is a substitute for an account identifier, such as a primary account number (PAN), [39], receiving, by a server computer, a request for a resource provider specific token.. linking and storing, by the digital wallet server computer, [7]; token service 182 receives the request and then retrieves a resource provider specific token from token vault 164 and records that the retrieved token is associated with digital wallet server computer 140. The resource provider specific token is then sent over processing network 150 to digital wallet server computer 140, [62]; User 110 may use the generic account token to conduct transactions through an interface provided by the digital wallet application stored on user device 120, [59], system 100 includes 140 and 160 digital wallet server computer 140 and token provider server computer 160 whre 160 is NOT part of the merchant wallet or wallet server and it is a separate system, see also “the token provider server computer 160 oncludes a token service 162 and token vault 164, [55], (third party issuance and control).
It would have been obvious to one with ordinary skill in the art before the effective filing date of the invention, to modify the method of Ready, to include the above limitations, as taught by Chumbley, in order to securely and efficiently updating account information across resource providers, (Chumbley, [6]).
Regarding Claims 2 and 12, Ready teaches wherein the merchant payment system communicated with a user device configured to execute a mobile application configured to communicate with the merchant payment system and one or more digital wallet provider systems, (see at least Fig. 3A-B).
Regarding Claims 3 and 13, Ready teaches wherein the transaction request comprises a session ID the user device received from the digital wallet provider, [22].
Regarding Claims 4 and 14, Ready teaches the result of the payment authorization is provided by the digital wallet provider system based on a communication between the digital wallet provider system and at least one payment card industry payment processor system, [31].
Regarding Claims 5 and 15, Ready does not explicitly teach, however, Chumbley teaches payment methods associated with a digital wallet account of the plurality of digital wallet accounts comprise one or more of a credit card account, a debit card account, a gift card and a bank account, [39].
Regarding Claims 6 and 16, Ready teaches the digital wallet provider is selected based on one or more payment rules associated with the user account, [46].
Regarding Claims 7 and 17, Ready teaches the user account is further associated with one or more payment methods not associated with the plurality of digital wallet accounts, [36].
Regarding Claims 8 and 18, Ready teaches the merchant payment system is further configured to directly communicate with one or more payment processor systems to process payments using one or more payment methods, [17].
Regarding Claims 9 and 19, Ready teaches the merchant payment system is further configured to select from among the plurality of digital wallet accounts and the one or more payment methods associated with the user account for the transaction in response to receiving the transaction request, [39].
Regarding Claim 10, Ready teaches the POS system comprises a display screen and the transaction request is generated by a user device in response to capturing an image displayed on the display screen of the POS system, [13, 22].
Response to Arguments
Applicant’s arguments with respect to claims 1-20 have been considered but are moot because the new ground of rejection does not rely on Chumbley reference applied in the prior rejection of record for any teaching or matter specifically challenged in the argument.
Conclusion
Any inquiry concerning this communication or earlier communications from the examiner should be directed to MILENA RACIC whose telephone number is (571)270-5933. The examiner can normally be reached M-F 7:30am-4pm EST.
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 (Ryan) 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.
/MILENA RACIC/Patent Examiner, Art Unit 3627
/FLORIAN M ZEENDER/Supervisory Patent Examiner, Art Unit 3627