DETAILED ACTION
Notice of Pre-AIA or AIA Status
The present application, filed on or after March 16, 2013, is being examined under the first inventor to file provisions of the AIA .
Status of Claims
This office action is in response to the claim amendments filed on December 18, 2025.
Claims 1, 3-14 and 16-20 are pending.
Claims 2 and 15 have been canceled.
Claims 1, 3-14 and 16-20 have been examined.
Response to Arguments
With respect to Claim Rejections - 35 USC § 101
Applicant argues: claim 1 now specifies that the merchant computer program determines that the token reference identifier in the customer wallet is on the list of token reference identifiers that have been pre-qualified for one or more of the installment payment options for the purchase from the merchant, wherein the merchant computer program determines whether the token reference identifier is pre-qualified without contacting the financial institution computer program. Because the information needed to make this determination is pre-staged with the merchant computer program, no communication with the financial institution computer program is needed. Thus, the merchant computer program can make this determination independently, including if the financial institution computer program is unavailable. See Applicant’s Arguments pages 9-11.
The Examiner, however, respectfully disagrees. As a preliminary matter, the Examiner follows the 2019 Patent Eligibility Guidance (“2019 PEG”) which is a synthesis of the case law of Alice and its progeny. Additionally, the reasoning for this rejection is the same as was laid out in the Office Action Non-Final Rejection, dated 10/01/2025 (hereinafter, “Office Action”).
Furthermore, while Applicant has amended the claim to recite additional subject matter, for example, the amended claim limitations recite: “determining, by the merchant computer program, that the token reference identifier in the customer wallet is on the list of token reference identifiers that have been pre-qualified for one or more of the installment payment options for the purchase from the merchant, wherein the merchant computer program determines whether the token reference identifier is pre-qualified without contacting the financial institution computer program;” further describe the abstract idea of presentation of payment options which is grouped within the “certain methods of organizing human activity” because it describes a process for carrying out a commercial interaction between parties.
Furthermore, the claims recite receiving, provisioning messages from a payment network identifying payment cards that have been stored or provisioned to customer wallets for a merchant; adding, the payment cards to a database comprising an identification of a plurality of payment cards that have been stored or provisioned to the customer wallets for the merchant; identifying, in the database maintained by the financial institution, the plurality of payment cards that have been stored in or provisioned to the customer wallets for a merchant; pre-qualifying, each of the customers associated with the stored or provisioned payment cards for one or more installment payment options for a purchase from the merchant; communicating, a list of token reference identifiers for stored or provisioned payment cards that have been pre-qualified and the one or more pre-qualified installment payment options to a merchant computer program; receiving, as part of a checkout flow of a checkout user interface, a token reference identifier for a stored or provisioned payment card in one of the customer wallets; determining, that the token reference identifier in the customer wallet is on the list of token reference identifiers that have been pre-qualified for one or more of the installment payment options for the purchase from the merchant, wherein the merchant computer program determines whether the token reference identifier is pre-qualified without contacting the financial institution computer program; and presenting, the one or more installment payment options associated with the token reference identifier in the customer wallet has been pre-qualified in the checkout flow of the checkout user interface”, can be performed by using a pen and paper and/or that can be performed mentally. The courts consider a mental process (thinking) that "can be performed in the human mind, or by a human using a pen and paper" to be an abstract idea. Additionally, a processor, does not necessarily restrict the claim from reciting an abstract idea. Accordingly, the claims (e.g., the amended claims) recite an abstract idea (See MPEP 2106.04). (Step 2A-Prong 1: YES).
Additionally, the claims (e.g., the amended claims) also fail to recite a practical application of the abstract ideas. According to the 2019 PEG, the additional claim elements are considered when determining whether the claim recites a practical application, such as a technological improvement, of the abstract idea. However, the claims fail to introduce any such additional elements. Again, receiving, provisioning messages from a payment network identifying payment cards that have been stored or provisioned to customer wallets for a merchant; adding, the payment cards to a database comprising an identification of a plurality of payment cards that have been stored or provisioned to the customer wallets for the merchant; identifying, in the database maintained by the financial institution, the plurality of payment cards that have been stored in or provisioned to the customer wallets for a merchant; pre-qualifying, each of the customers associated with the stored or provisioned payment cards for one or more installment payment options for a purchase from the merchant; communicating, a list of token reference identifiers for stored or provisioned payment cards that have been pre-qualified and the one or more pre-qualified installment payment options to a merchant computer program; receiving, as part of a checkout flow of a checkout user interface, a token reference identifier for a stored or provisioned payment card in one of the customer wallets; determining, that the token reference identifier in the customer wallet is on the list of token reference identifiers that have been pre-qualified for one or more of the installment payment options for the purchase from the merchant, wherein the merchant computer program determines whether the token reference identifier is pre-qualified without contacting the financial institution computer program; and presenting, the one or more installment payment options associated with the token reference identifier in the customer wallet has been pre-qualified in the checkout flow of the checkout user interface are not considered as additional claim elements. More specifically, the amended claim language, “wherein the merchant computer program determines whether the token reference identifier is pre-qualified without contacting the financial institution computer program” which represents an additional function of the merchant computer program determines whether the token reference identifier is pre-qualified without contacting the financial institution computer program. This language describes the characteristics of how a transaction is performed and further elaborates on the abstract idea of presentation of payment options noted in claim 1. Therefore, the claims do not, for example, purport to improve the functioning of a computer. And the claims are directed to an abstract idea. Thus, claims do not integrate the abstract idea into a practical application. Therefore, this analysis is the same as was laid out in the Office Action. (Step 2A-Prong 2: NO).
The claims also fail to recite significantly more than the abstract idea. According to the 2019 PEG, the additional elements, when considered individually and as a combination, are analyzed to determine whether the claims recite significantly more than the abstract idea. However, the claims (e.g., the amended claims) fail to recite any new additional elements. As noted in the Office Action, the additional elements serve to implement the abstract idea in a computing environment.
Furthermore, the amended claim, “determining, by the merchant computer program, that the token reference identifier in the customer wallet is on the list of token reference identifiers that have been pre-qualified for one or more of the installment payment options for the purchase from the merchant, wherein the merchant computer program determines whether the token reference identifier is pre-qualified without contacting the financial institution computer program”, it does not appear that the amended claim would result in any improvement to the recited technology. Therefore, the claims limitations do not include additional elements that integrate the abstract idea into a practical application or that provide significantly more than the abstract idea. Therefore, the claim is not patent eligible. (Step 2B: NO). See detail rejection below.
Accordingly, this ground of rejection is maintained.
With respect to Claim Rejections - 35 USC § 103
Applicant’s arguments with respect to claims 1, 3-14 and 16-20 have been considered but are moot in view of new grounds of rejection initiated by applicant’s amendment to the claims.
Claim Rejections - 35 USC § 112
The following is a quotation of the first paragraph of 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.
Claim 1, 3-14 and 16-20 rejected under 35 U.S.C. 112, 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(s), at the time the application was filed, had possession of the claimed invention.
Claim 1 recites “the merchant computer program determines whether the token reference identifier is pre-qualified without contacting the financial institution computer program” thus contain negative limitations.
The Examiner notes that negative limitations tend to define the invention in terms of what it was not, rather than pointing out the invention. In re Schechter, 205 F.2d 185, 98 USPQ 144 (CCPA 1953).
Any negative limitation or exclusionary proviso must have basis in the original disclosure. If alternative elements are positively recited in the specification, they may be explicitly excluded in the claims. See In re Johnson, 558 F.2d 1008, 1019, 194 USPQ 187, 196 (CCPA 1977) (“[the] specification, having described the whole, necessarily described the part remaining.”).
However, As noted in MPEP 2100, “Any claim containing a negative limitation which does not have basis in the original disclosure should be rejected under 35 U.S.C. 112, first paragraph, as failing to comply with the written description requirement.” Ex parte Parks, 30 USPQ2d 1234, 1236 (Bd. Pat. App. & Inter. 1993). See MPEP § 2163 - § 2163.07(b) for a discussion of the written description requirement of 35 U.S.C. 112, first paragraph.
Claim Rejections - 35 USC § 101
35 U.S.C. 101 reads as follows:
Whoever invents or discovers any new and useful process, machine, manufacture, or composition of matter, or any new and useful improvement thereof, may obtain a patent therefor, subject to the conditions and requirements of this title.
Claims 1, 3-14 and 16-20 are rejected under 35 U.S.C. 101 because the claimed invention is directed to an abstract idea without significantly more.
In the instant case, claims 1 and 3-13 are directed to a method, and claims 14 and 16-20 are directed to a system comprising a memory and a processor. Therefore, these claims fall within the four statutory categories of invention.
The claims recite an abstract idea of presentation of payment options. Specifically, the claims recite “receiving, by a financial institution computer program executed by a financial institution backend, provisioning messages from a payment network identifying payment cards that have been stored or provisioned to customer wallets for a merchant; adding, by the financial institution computer program, the payment cards to a database comprising an identification of a plurality of payment cards that have been stored or provisioned to the customer wallets for the merchant; identifying, in the database maintained by the financial institution, the plurality of payment cards that have been stored in or provisioned to the customer wallets for a merchant; pre-qualifying, by the financial institution computer program, each of the customers associated with the stored or provisioned payment cards for one or more installment payment options for a purchase from the merchant; communicating, by the financial institution computer program, a list of token reference identifiers for stored or provisioned payment cards that have been pre-qualified and the one or more pre-qualified installment payment options to a merchant computer program executed by a merchant backend; receiving, by the merchant computer program, as part of a checkout flow of a checkout user interface, a token reference identifier for a stored or provisioned payment card in one of the customer wallets; determining, by the merchant computer program, that the token reference identifier in the customer wallet is on the list of token reference identifiers that have been pre-qualified for one or more of the installment payment options for the purchase from the merchant, wherein the merchant computer program determines whether the token reference identifier is pre-qualified without contacting the financial institution computer program; and presenting, by the merchant computer program, the one or more installment payment options associated with the token reference identifier in the customer wallet has been pre-qualified in the checkout flow of the checkout user interface”, which is grouped within the “certain methods of organizing human activity” grouping of abstract ideas in prong one of step 2A of the Alice/Mayo test (See MPEP 2106.04(a)) because it describes a process for carrying out a commercial interaction between parties that involves communicating data needed to complete a transaction to the parties. Accordingly, the claims recite an abstract idea (See MPEP 2106.04).
This judicial exception is not integrated into a practical application because, when analyzed under prong two of step 2A of the Alice/Mayo test (See MPEP 2106.04(a or d)), the additional element(s) of the claim(s) such as a computer processor merely use(s) a computer as a tool to perform an abstract idea. Specifically, the computer processor perform(s) the steps or functions of “receiving, by a financial institution computer program executed by a financial institution backend, provisioning messages from a payment network identifying payment cards that have been stored or provisioned to customer wallets for a merchant; adding, by the financial institution computer program, the payment cards to a database comprising an identification of a plurality of payment cards that have been stored or provisioned to the customer wallets for the merchant; identifying, in the database maintained by the financial institution, the plurality of payment cards that have been stored in or provisioned to the customer wallets for a merchant; pre-qualifying, by the financial institution computer program, each of the customers associated with the stored or provisioned payment cards for one or more installment payment options for a purchase from the merchant; communicating, by the financial institution computer program, a list of token reference identifiers for stored or provisioned payment cards that have been pre-qualified and the one or more pre-qualified installment payment options to a merchant computer program executed by a merchant backend; receiving, by the merchant computer program, as part of a checkout flow of a checkout user interface, a token reference identifier for a stored or provisioned payment card in one of the customer wallets; determining, by the merchant computer program, that the token reference identifier in the customer wallet is on the list of token reference identifiers that have been pre-qualified for one or more of the installment payment options for the purchase from the merchant, wherein the merchant computer program determines whether the token reference identifier is pre-qualified without contacting the financial institution computer program; and presenting, by the merchant computer program, the one or more installment payment options associated with the token reference identifier in the customer wallet has been pre-qualified in the checkout flow of the checkout user interface”. The use of a processor/computer as a tool to implement the abstract idea does not integrate the abstract idea into a practical application because it requires no more than a computer performing functions that correspond to acts required to carry out the abstract idea. The additional elements do not involve improvements to the functioning of a computer, or to any other technology or technical field (See MPEP 2106.05(a)), the claims do not apply the abstract idea with, or by use of, a particular machine (See MPEP 2106.05(b)), the claims do not effect a transformation or reduction of a particular article to a different state or thing (See MPEP 2106.05(c)), and the claims do not apply or use the abstract idea in some other meaningful way beyond generally linking the use of the abstract idea to a particular technological environment, such that the claim as a whole is more than a drafting effort designed to monopolize the exception (MPEP 2106.05(e) and Vanda Memo). Therefore, the claims do not, for example, purport to improve the functioning of a computer. Nor do they effect an improvement in any other technology or technical field. Accordingly, the additional elements do not impose any meaningful limits on practicing the abstract idea, and the claims are directed to an abstract idea.
The claim(s) does/do not include additional elements that are sufficient to amount to significantly more than the judicial exception because, when analyzed under step 2B of the Alice/Mayo test (See MPEP 2106.05), the additional element(s) of using a computer processor to perform the steps amounts to no more than using a computer or processor to automate and/or implement the abstract idea of presentation of payment options. As discussed above, taking the claim elements separately, the computer processor perform(s) the steps or functions of “receiving, by a financial institution computer program executed by a financial institution backend, provisioning messages from a payment network identifying payment cards that have been stored or provisioned to customer wallets for a merchant; adding, by the financial institution computer program, the payment cards to a database comprising an identification of a plurality of payment cards that have been stored or provisioned to the customer wallets for the merchant; identifying, in the database maintained by the financial institution, the plurality of payment cards that have been stored in or provisioned to the customer wallets for a merchant; pre-qualifying, by the financial institution computer program, each of the customers associated with the stored or provisioned payment cards for one or more installment payment options for a purchase from the merchant; communicating, by the financial institution computer program, a list of token reference identifiers for stored or provisioned payment cards that have been pre-qualified and the one or more pre-qualified installment payment options to a merchant computer program executed by a merchant backend; receiving, by the merchant computer program, as part of a checkout flow of a checkout user interface, a token reference identifier for a stored or provisioned payment card in one of the customer wallets; determining, by the merchant computer program, that the token reference identifier in the customer wallet is on the list of token reference identifiers that have been pre-qualified for one or more of the installment payment options for the purchase from the merchant, wherein the merchant computer program determines whether the token reference identifier is pre-qualified without contacting the financial institution computer program; and presenting, by the merchant computer program, the one or more installment payment options associated with the token reference identifier in the customer wallet has been pre-qualified in the checkout flow of the checkout user interface”. These functions correspond to the actions required to perform the abstract idea. Viewed as a whole, the combination of elements recited in the claims merely recite the concept of presentation of payment options. Therefore, the use of these additional elements does no more than employ the computer as a tool to automate and/or implement the abstract idea. The use of a computer or processor to merely automate and/or implement the abstract idea cannot provide significantly more than the abstract idea itself (MPEP 2106.05(I)(A)(f) & (h)). Therefore, the claim is not patent eligible.
Regarding dependent claims
Claims 3, 11 and 16 recite: wherein the pre-qualified installment payment options comprise a reduced interest rate for a period of time.
Claims 4, 12 and 17 recite: wherein the merchant computer program accesses an offer database to retrieve the installment payment options.
Claim 5 recites: wherein the merchant computer program accesses an offer database to retrieve the installment payment options.
Claims 6 and 20 recite: consolidating, by the financial institution computer program, a plurality of accepted installment payment option offers for the same token reference identifier.
Claim 7 recites: maintaining, by the financial institution computer program, the accepted installment payment option offer separately from other purchases made with the payment card.
Claim 9 recites: receiving, by the merchant computer program, acceptance of one of the one or more pre-qualified installment payment options; notifying, by the merchant computer program, the financial institution backend of the acceptance by providing the token reference identifier and an identifier for the accepted pre-qualified installment payment option; and conducting, by the merchant computer program, a transaction.
Claim 10 recites: wherein the pre-qualified installment payment options comprise a reduced interest rate for a period of time.
Claim 13 recites: wherein the merchant computer program stores the list of token reference identifiers for payment cards that have been pre-qualified and the one or more pre-qualified installment payment options in a token reference identifier database.
Claim 18 recites: comprising a payment network, and the merchant computer program conducts the transaction over the payment network.
Claim 19 recites: The system of claim 18, further comprising a second network, wherein merchant computer program communicates the token reference identifier and the identifier for the accepted pre-qualified payment option to the financial institution backend over the second network.
Dependent claims further describe the abstract idea of presentation of payment options. The dependent claims do not include additional elements that integrate the abstract idea into a practical application or that provide significantly more than the abstract idea. Therefore, the dependent claims are also not patent eligible.
Claim Rejections - 35 USC § 103
This application currently names joint inventors. In considering patentability of the claims the examiner presumes that the subject matter of the various claims was commonly owned as of the effective filing date of the claimed invention(s) absent any evidence to the contrary. Applicant is advised of the obligation under 37 CFR 1.56 to point out the inventor and effective filing dates of each claim that was not commonly owned as of the effective filing date of the later invention in order for the examiner to consider the applicability of 35 U.S.C. 102(b)(2)(C) for any potential 35 U.S.C. 102(a)(2) prior art against the later invention.
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.
The factual inquiries set forth in Graham v. John Deere Co., 383 U.S. 1, 148 USPQ 459 (1966), that are applied for establishing a background for determining obviousness under 35 U.S.C. 103 are summarized as follows:
1. Determining the scope and contents of the prior art.
2. Ascertaining the differences between the prior art and the claims at issue.
3. Resolving the level of ordinary skill in the pertinent art.
4. Considering objective evidence present in the application indicating obviousness or nonobviousness.
Claims 1, 8, 13, 14 and 18 are rejected under 35 U.S.C. 103 as being unpatentable over Davis et al. (US 20230297992 A1, “Davis”) in view of Mueller et al. (US 20240202675 A1, “Mueller”) further in view of Aitenbichler et al. (US 20160371716 A1, “Aitenbichler”).
Regarding claim 1: Davis discloses: A method for efficient presentation of payment options at point of sale devices, comprising (see Figs. 1 and 3):
[…]
adding, by the financial institution computer program, the payment cards to a database comprising an identification of a plurality of payment cards that have been stored or provisioned to the customer wallets for the merchant (Davis [0019]: The issuers 108a-c are configured to issue payment accounts (e.g., credit accounts, debit accounts, prepaid accounts, etc.) to users, including the user 112. The payment accounts are often linked to payment devices, such as card and/or virtual wallets, etc.) (see paragraphs 0052] and [0054]);
identifying, in the database maintained by the financial institution, the plurality of payment cards that have been stored in or provisioned to the customer wallets for a merchant (Davis [0019]: The issuers 108a-c are configured to issue payment accounts (e.g., credit accounts, debit accounts, prepaid accounts, etc.) to users, including the user 112. The payment accounts are often linked to payment devices, such as card and/or virtual wallets, etc.; [0024]: In doing so, the issuer 108a may be configured to issue an installment account to the user 112 (e.g., identified by a PAN in a specific range of PANs, etc.). The issuer 108a, then, may be configured to cooperate with a wallet provider (associated with the wallet SDK 122) to provision the pre-approved installment account to the virtual wallet of the user 112; [0025]: he issuers 108a-c are configured to define installment terms for users, more generally. In doing so, the issuers 108a-c may define, for each of the installment options, particular terms and conditions for the installment options, payment terms, interest rates (if applicable), payment timelines, amounts, merchant types/categories, etc. (broadly, installment configurations, etc.). The installment configurations, then, may be used by the issuers 108a-c, for example, to manage business rules governing consumer eligibility for installment options/plans and installment plan processing);
pre-qualifying, by the financial institution computer program, each of the customers associated with the stored or provisioned payment cards for one or more installment payment options for a purchase from the merchant (Davis [0022]: This may include, for example, facilitating pre-approval (and actual approval) of the user 112 (and other users) in connection with providing an installment plan to the user 112 and confirming repayment thereof; [0024]: the issuers 108a-c may be configured to submit pre-approvals for users, specific to certain users (e.g., existing card holders, etc.), etc. as parameters (e.g., for use then by the IPP 124, etc.). For example, the issuer 108a (or one of the other issuers 108b-c) may pre-approve one or more users, including the user 112, for installment options (e.g., where the user 112 may already have an account with the issuer 108a, etc.). In doing so, the issuer 108a may be configured to issue an installment account to the user 112 (e.g., identified by a PAN in a specific range of PANs, etc.));
communicating, by the financial institution computer program, a list of token reference identifiers for stored or provisioned payment cards that have been pre-qualified and the one or more pre-qualified installment payment options to a merchant computer program executed by a merchant backend (Davis [0024]: The issuer 108a, then, may be configured to cooperate with a wallet provider (associated with the wallet SDK 122) to provision the pre-approved installment account to the virtual wallet of the user 112; [0031]: The installment host 116, in turn, is configured to store the account number in the database 118, for example, or to tokenize the account number (e.g., through interaction with the processing network 106, etc.) and to store the token, as a card-on-file payment for the installments indicated in the select installment plan).
receiving, by the merchant computer program, as part of a checkout flow of a checkout user interface, a token reference identifier for a stored or provisioned payment card in one of the customer wallets (Davis [0019]: the user 112 is associated with the mobile device 110, which includes a virtual wallet application 114 (broadly, a network-based application) and which configures the mobile device 110 to communicate with the issuer 108b, for example, to provision a payment account issued by the issuer 108b for the user 112 to the virtual wallet application 114; [0031]: The installment host 116, in turn, is configured to store the account number in the database 118, for example, or to tokenize the account number (e.g., through interaction with the processing network 106, etc.) and to store the token, as a card-on-file payment for the installments indicated in the select installment plan);
determining, by the merchant computer program, that the token reference identifier in the customer wallet is on the list of token reference identifiers that have been pre-qualified for one or more of the installment payment options for the purchase from the merchant, […] (Davis [0031]: In connection therewith, the first party 102 (and/or mobile device 110) is configured, by the wallet SDK 122, to present the payment account provisioned to the wallet application 114 and/or another account option; [0047]: In response, the wallet SDK 122 included in the website retrieves wallet data for the user 112 (e.g., after an authentication or login, etc.). In addition, the wallet SDK 122 determines, at 304, if eligibility for installment payments exist for the given transaction); and
presenting, by the merchant computer program, the one or more installment payment options associated with the token reference identifier in the customer wallet has been pre-qualified in the checkout flow of the checkout user interface (Davis [0031]: The first party 102 is configured, by the installment SDK 120, to then present the installment options/offers to the user 112; [0051]: the installment SDK 120 included in the website of the first party 102 presents the installment option(s) to the user 112. In connection therewith, the user 112 may be presented, at the mobile device 110, with interface 406 of FIG. 4C, for example, which illustrates the “Pay in 4” type installment option for the purchase and includes the specific amounts to be paid on the specific dates, as determined by the installment host 116).
Davis does not specifically disclose; however, Mueller discloses:
receiving, by a financial institution computer program executed by a financial institution backend, provisioning messages from a payment network identifying payment cards that have been stored or provisioned to customer wallets for a merchant (Mueller [0064]: the external payment gateway may list an aggregation various digital wallets with which the payment sources are linked or otherwise associated);
As indicated above, Davis discloses the following limitations. The Examiner notes, Mueller also discloses the following limitations.
adding, by the financial institution computer program, the payment cards to a database comprising an identification of a plurality of payment cards that have been stored or provisioned to the customer wallets for the merchant (Mueller [0065]: Once the user accesses their online account with their financial institution, one of the webpages associated with the financial institution may display account information about a payment source associated with the user. This account information may include a list of the digital wallets that are linked to this specific financial account number; [0066]: In one embodiment, the computing system may prompt the user to associate the specific financial account number to a specific digital wallet application. For instance, the user's email address or other identifying information or data that is stored in a database or other storage facility of the financial institution may overlap with information that was provided to a digital wallet application service provider when the digital wallet was set up. The database may include information that corresponds to user information of one or more users of the financial institution. For example, the database may include financial information, user authentication information, user preferences, digital wallet connection information, user's transactional information history, etc.);
identifying, by a financial institution computer program executed by a financial institution backend and in a database maintained by the financial institution, a plurality of payment cards that have been stored in or provisioned to customer wallets for a merchant (see paragraphs [0065] and [0066]).
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 Davis with Mueller to include additional functions of application programming interface integration to communicate data such as receiving provisioning messages to enhance payment transaction performance.
Davis does not specifically disclose; however, Aitenbichler discloses: the merchant computer program determines whether the [payment transaction] is pre-qualified without contacting the financial institution computer program (Aitenbichler [0070]: In block 220, the user initiates a financial transaction with the merchant. In an example embodiment, the financial transaction is an offline payment transaction where the merchant computing device 120 is without a network 140 connection to the account management system 140 or other system maintaining an account for the user. In this embodiment, the merchant computing device 120 processes and authorizes the offline payment transaction without receiving notification, confirmation, or verification from an issuer system or account management system 130 that sufficient funds are available to authorize with the offline payment transaction).
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 the combination of Davis and Mueller with Aitenbichler to include additional functions of authorizing a transaction without communicating with a issuer to enhance user experience.
Regarding claim 8: Davis and Mueller, discloses the limitations of claim 1 above.
Davis further discloses: A method for efficient presentation of payment options at point of sale devices, comprising (see abstract and Figs. 1 and 3):
receiving, by a merchant computer program executed by a merchant backend for a merchant and from a financial institution backend, a list of token reference identifiers for payment cards that have been pre-qualified and one or more pre- qualified installment payment options for the token reference identifiers (Davis [0017]: As shown in FIG. 1, the first party 102 (e.g., the e-commerce platform associated therewith, etc.) includes an installment software development kit (SDK) 120 and a wallet SDK 122…the installment SDK 120 and the wallet SDK 122 may be included in a single SDK (e.g., the installment SDK 120, the wallet SDK 122, another SDK, etc.), or otherwise included in the e-commerce platform of the first party 102; [0019]: as shown in FIG. 1, the user 112 is associated with the mobile device 110, which includes a virtual wallet application 114 (broadly, a network-based application) and which configures the mobile device 110 to communicate with the issuer 108b, for example, to provision a payment account issued by the issuer 108b for the user 112 to the virtual wallet application 114. In this example embodiment, the wallet SDK 122 may be associated with the wallet application 114, whereby a wallet profile of the user 112, associated with the wallet application 114, may be accessible to the user 112 via the wallet SDK 122 (e.g., after a suitable login, authentication, etc.); [0024]: The issuer 108a, then, may be configured to cooperate with a wallet provider (associated with the wallet SDK 122) to provision the pre-approved installment account to the virtual wallet of the user 112;) wherein the token reference identifiers are identified from a database maintained by the financial institution backend from provisioning messages from a payment network that identify payment cards that have been stored or provisioned to customer wallets for the merchant (Davis [0031]: The installment host 116, in turn, is configured to store the account number in the database 118, for example, or to tokenize the account number (e.g., through interaction with the processing network 106, etc.) and to store the token, as a card-on-file payment for the installments indicated in the select installment plan);
storing, by the merchant computer program, the list of token reference identifiers (Davis [0019]: the user 112 is associated with the mobile device 110, which includes a virtual wallet application 114 (broadly, a network-based application) and which configures the mobile device 110 to communicate with the issuer 108b, for example, to provision a payment account issued by the issuer 108b for the user 112 to the virtual wallet application 114; [0031]: The installment host 116, in turn, is configured to store the account number in the database 118, for example, or to tokenize the account number (e.g., through interaction with the processing network 106, etc.) and to store the token, as a card-on-file payment for the installments indicated in the select installment plan; [0045]: At the outset, it should be appreciated that the database 118 includes the MAID for the first party 102, along with the installment and eligibility parameters for the first party 102 and the issuers 108a-c.), (see paragraphs [0017], [0019], [0024] and [0045]);
receiving, by the merchant computer program, a log in to a customer wallet with the merchant as part of a checkout flow for a transaction in a checkout user interface (Davis [0047]: In response, the wallet SDK 122 included in the website retrieves wallet data for the user 112 (e.g., after an authentication or login, etc.).), (see paragraphs [0013] and [0019]);
retrieving, by the merchant computer program, a token reference identifier for a payment card that has been stored in or provisioned to the customer wallet (Davis [0036]: When the installment plan is created, and stored, the installment host 116 is configured to indicate the success to the first party 102. In turn, the first party 102 is configured to complete the checkout of the user 112 for the product(s) purchase, and to initiate a transaction for the amount of the purchase, using the RCN or associated token, or the VCN; [0047]: In response, the wallet SDK 122 included in the website retrieves wallet data for the user 112 (e.g., after an authentication or login, etc.).);
determining, by the merchant computer program, that the token reference identifier in the customer wallet is on the list of token reference identifiers that have been pre-qualified (Davis [0047]: the wallet SDK 122 determines, at 304, if eligibility for installment payments exist for the given transaction; [0022]: This may include, for example, facilitating pre-approval (and actual approval) of the user 112 (and other users) in connection with providing an installment plan to the user 112 and confirming repayment thereof. The installment host 116, then, is configured to provide data integration from the IPP 124 (and, potentially, from other IPPs in the system 100, etc.); [0024]: the issuers 108a-c may be configured to submit pre-approvals for users, specific to certain users (e.g., existing card holders, etc.), etc. as parameters (e.g., for use then by the IPP 124, etc.);
retrieving, by the merchant computer program, the one or more pre-qualified installment payment options for the token reference identifier in the customer wallet (Davis [0047]: In response, the wallet SDK 122 included in the website retrieves wallet data for the user 112 (e.g., after an authentication or login, etc.). In addition, the wallet SDK 122 determines, at 304, if eligibility for installment payments exist for the given transaction), (see paragraphs [0047]-[0048] and Fig. 3); and
presenting, by the merchant computer program, the one or more pre- qualified installment payment options in the checkout flow of the checkout user interface (Davis [0048]: Upon receipt, the wallet SDK 122, as part of the first party website, presents, at 312, the installment types to the user 112. In connection therewith, the mobile device 110 may display the interface 404 of FIG. 4B to the user 112, for example, via the user's wallet application 114. In doing so, in this example, the interface 404 includes three options for funding the transaction of which one is a “Pay in 4” type installment payment directed to a pre-approved, user specific account (e.g., an account ending in 1234, etc.).), (see Fig. 3).
Regarding claim 13: Davis and Mueller, discloses the limitations of claim 1 above.
Davis further discloses: The method of claim 8, wherein the merchant computer program stores the list of token reference identifiers for payment cards that havebeen pre-qualified and the one or more pre-qualified installment payment options in a token reference identifier database (see paragraphs [0017], [0019], [0024], [0031] and [0045] and Fig. 1).
Regarding claim 14: Claim 14 recites subject matter similar to that discussed above in connection with claims 1 and 8. Accordingly, claim 14 is rejected under a similar rationale as claims 1 and 8.
Regarding claim 18: Davis and Mueller, discloses the limitations of claim 1 above.
Davis further discloses: The system of claim 14, further comprising a payment network, and the merchant computer program conducts the transaction over the payment network (see abstract and Fig. 1).
Claims 3-7, 9, 11, 12, 16, 17 and 20 are rejected under 35 U.S.C. 103 as being unpatentable over Davis et al. (US 20230297992 A1, “Davis”) in view of Mueller et al. (US 20240202675 A1, “Mueller”) in view of Aitenbichler et al. (US 20160371716 A1, “Aitenbichler”) further in view of Vidit BHARGAVA (US 20200051110 A1, “BHARGAVA”).
Regarding claims 3, 11 and 16: Davis and Mueller, discloses the limitations of claim 1 above.
Davis further discloses: The method of claim 1, wherein the pre-qualified installment payment options comprise a [interest rate] for a period of time (see paragraphs [0024]-[0025]).
Davis does not specifically disclose, installment payment options comprise a reduced interest rate for a period of time.
However, BHARGAVA discloses:
installment payment options comprise a reduced interest rate for a period of time. (BHARGAVA [0089]: The payment term plan displayed in FIGS. 6A and 6B are for example purposes only, and the payment term plans, as such, can be customized to any extent by the user or from the issuer server. Also, any form of Equated Monthly Installment (EMI) calculation may apply and monthly installments may differ in different payment term plans and also for different users. For instance, one way of EMI calculation may include decreasing interest part and increasing principal part with each installment).
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 the combination of Davis, Mueller and Aitenbichler with BHARGAVA, a system for facilitating installment payment with reward points, to include additional functions of installment payment options, to enhance user experience and payment transaction.
Regarding claims 4, 12 and 17: Davis and Mueller, discloses the limitations of claim 1 above.
Davis further discloses: The method of claim 1, wherein the merchant computer program accesses an offer database to retrieve the installment payment options (Davis [0047]: In turn, the installment host 116 retrieves, at 306, the installment parameters for the first party 102, based on the MAID. As described above, the installment parameters indicate whether the first party 102 has opted into or out of installment payments, and potentially, the specific types of installments that the first party 102 has opted in for, if any.) (see paragraphs [0047]-0048]).
Alternatively, BHARGAVA also discloses, wherein the merchant computer program accesses an offer database to retrieve the installment payment options (BHARGAVA [0030]: At 310, the installment payment module 206 checks if the issuer server 114 from which the request is received has enrolled for integrating installment payment with reward points feature), (see abstract and paragraphs [0058]-[0060] and Fig. 3).
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 the combination of Davis, Mueller and Aitenbichler with BHARGAVA, a system for facilitating installment payment with reward points, to include additional functions of installment payment options, to enhance user experience and payment transaction.
Regarding claim 5: Davis and Mueller, discloses the limitations of claim 1 above.
Davis further discloses: The method of claim 1, further comprising: receiving, from the merchant backend, a notification that one of the one or more installment payment options was accepted, wherein the notification comprises an identification of the accepted installment payment option and the token reference identifier (see paragraph [0049]).
Alternatively, BHARGAVA also discloses: The method of claim 1, further comprising: receiving, from the merchant backend, a notification that one of the one or more installment payment options was accepted, wherein the notification comprises an identification of the accepted installment payment option and the token reference identifier (BHARGAVA [0060]: At 310, the installment payment module 206 checks if the issuer server 114 from which the request is received has enrolled for integrating installment payment with reward points feature. The installment payment module 206 queries the payment server database 212 to access information corresponding to enrollment of the issuer server 114 for the installment payment with reward points feature), (see Fig. 3).
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 the combination of Davis, Mueller and Aitenbichler with BHARGAVA, a system for facilitating installment payment with reward points, to include additional functions of installment payment options, to enhance user experience and payment transaction.
Regarding claims 6 and 20: Davis and Mueller, discloses the limitations of claim 1 above.
Davis does not specifically disclose; however, BHARGAVA also discloses: The method of claim 1, further comprising: consolidating, by the financial institution computer program, a plurality of accepted installment payment option offers for the same [payment cards/payment term plan] reference identifier (BHARGAVA [0062]: At 318, the issuer server 114 checks for one or more criteria based on which the payment term plan may be calculated. The one or more criteria include, but are not limited to, payment history associated with the payment card, available reward point in the card, other existing payment term plans associated with the payment card, etc. It shall be noted that the issuer database 204 may store one or more generic installment plans for all cardholders), (see paragraph [0088] and Figs. 3, 6A and 6B).
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 the combination of Davis, Mueller and Aitenbichler with BHARGAVA, a system for facilitating installment payment with reward points, to include additional functions of installment payment options, to enhance user experience and payment transaction.
Regarding claim 7: Davis and Mueller, discloses the limitations of claim 1 above.
Davis does not specifically disclose; however, BHARGAVA also discloses: The method of claim 1, further comprising: maintaining, by the financial institution computer program, the accepted installment payment option offer separately from other purchases made with the payment card (BHARGAVA [0088]: FIGS. 6A and 6B are example representations of tables 600 and 650 respectively, displaying a payment schedule of an installment payment with reward points, maintained at the issuer database 204), (see paragraphs [0062] and Figs. 6A and 6B).
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 the combination of Davis, Mueller and Aitenbichler with BHARGAVA, a system for facilitating installment payment with reward points, to include additional functions of installment payment options, to enhance user experience and payment transaction.
Regarding claim 9: Davis and Mueller, discloses the limitations of claim 1 above.
Davis further discloses:
receiving, by the merchant computer program, acceptance of one of the one or more pre-qualified installment payment options (see paragraph [0052] and Fig. 3).
[…];
conducting, by the merchant computer program, a transaction (see paragraph [0052] and Fig. 3).
Davis does not specifically disclose; however, BHARGAVA also discloses:
notifying, by the merchant computer program, the financial institution backend of the acceptance by providing the token reference identifier and an identifier for the accepted pre-qualified installment payment option (BHARGAVA [0062]: Upon receiving the conversion result, at 316, the installment payment module 206 or the payment server 112 requests for a payment term plan to the issuer server 114. At 318, the issuer server 114 checks for one or more criteria based on which the payment term plan may be calculated), (see paragraph [0071] and Figs. 3 and 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 the combination of Davis, Mueller and Aitenbichler with BHARGAVA, a system for facilitating installment payment with reward points, to include additional functions of installment payment options, to enhance user experience and payment transaction.
Claims 10 and 19 are rejected under 35 U.S.C. 103 as being unpatentable over Davis et al. (US 20230297992 A1, “Davis”) in view of Mueller et al. (US 20240202675 A1, “Mueller”) in view of Aitenbichler et al. (US 20160371716 A1, “Aitenbichler”) in view of Vidit BHARGAVA (US 20200051110 A1, “BHARGAVA”) further in view of Chen et al. (US 20200074434 A1, “Chen”).
Regarding claim 10: Davis and Mueller, discloses the limitations of claim 1 above.
Davis doesn’t explicitly disclose; however, Chen discloses: wherein the transaction is conducted over a payment network, and wherein the token reference identifier and the identifier for the accepted pre-qualified payment option are provided over a network other than the payment network (see paragraphs [0143]-0144]).
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 the combination of Davis, Mueller, Aitenbichler and BHARGAVA with Chen, a system for providing installment payment options for a payment transaction to include additional communication protocols to enhance payment data security.
Regarding claim 19: Davis and Mueller, discloses the limitations of claim 1 above.
Davis doesn’t explicitly disclose; however, Chen discloses: The system of claim 18, further comprising a second network (e.g., network 112), wherein merchant computer program communicates the token reference identifier and the identifier for the accepted pre-qualified payment option to the financial institution backend over the second network (see paragraph [0140] and Fig. 1).
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 the combination of Davis, Mueller, Aitenbichler and BHARGAVA with Chen, a system for providing installment payment options for a payment transaction to include additional communication protocols to enhance payment data security.
Conclusion
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 date of this final action.
Any inquiry concerning this communication or earlier communications from the examiner should be directed to JAHED ALI whose telephone number is (571)270-1085. The examiner can normally be reached 8:00 - 5:00 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, Neha Patel can be reached on (571) 270-1492. 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.
/JAHED ALI/Examiner, Art Unit 3699 /NEHA PATEL/Supervisory Patent Examiner, Art Unit 3699