DETAILED ACTION
Notice of Pre-AIA or AIA Status
The present application, filed on or after March 16, 2013, is being examined under the first inventor to file provisions of the AIA .
Continued Examination Under 37 CFR 1.114
A request for continued examination under 37 CFR 1.114, including the fee set forth in 37 CFR 1.17(e), was filed in this application after final rejection. Since this application is eligible for continued examination under 37 CFR 1.114, and the fee set forth in 37 CFR 1.17(e) has been timely paid, the finality of the previous Office action has been withdrawn pursuant to 37 CFR 1.114. Applicant's submission filed on June 9, 2026 has been entered.
Status of Claims
• This action is in reply to the RCE filed on June 9, 2026.
• Claims 1, 9, and 17 have been amended and are hereby entered.
• Claims 1-20 are currently pending and have been examined.
• This action is made Non-FINAL.
Response to Arguments
Applicant’s arguments filed May 11, 2026 have been fully considered but they are not persuasive.
The Examiner is withdrawing the 35 USC § 101 rejections due to Applicant’s amendments. The Examiner notes the claims integrate a practical application. The claimed invention recites limitations including: present, on a first graphical user interface on a user device associated with the customer while a bill pay application is in an unlaunched state, a notification including a summary of the plurality of bills, wherein the summary includes a list of the plurality of bills; automatically launch, by the user device, the bill pay application based on receiving a selection of the summary; present a second graphical user interface within the bill pay application while the bill pay application is in a launched state, the second graphical user interface displaying additional information associated with one of the plurality of bills, wherein the second graphical user interface is accessed responsive to selecting the bill from the list of the plurality of bills displayed on the first graphical user interface while the bill pay application is in the unlaunched state. These are meaningful limitations that are more than applying the user of the abstract idea to a computer. These limitations, in combination, are indicative of a practical application. The claims provide an improved GUI for electronic mobile devices, as described in the Specification at para. 15:
a graphical user interface (GUI) displayed on one or more user devices can present a notification to the respective user providing a summary of a transaction (e.g., a bill payment) or a requested transaction (e.g., a new bill for which payment is owed by the user). The notification can be provided in the form of an application summary reachable directly from a menu of the mobile device of the user (e.g., by hovering over an application icon of a mobile wallet application, by selecting the application icon without actually launching the application). The application summary indicates a summary of the payment or bill (e.g., an amount of the payment/bill). By selecting the application summary, the mobile wallet application (e.g., bill pay application) is launched and automatically navigated to a sub-screen of the application providing additional and more specific details of the transaction or bill (e.g., time of transaction, currency used, whether the payment is a repeat payment from a same prior payer, amount owed, biller identity, detailed invoice). The application summary can provide a summary of more than one transactions or bills (e.g., a list of bills received organized by due date). Accordingly, the application summary provides only limited data when the application is in an unlaunched state, and further details of each transaction can be accessed by selecting the corresponding transaction/bill summary to automatically launch the application and to be automatically navigated to the corresponding sub-screen displaying additional and more specific details of the transaction or bill, thereby providing an improved GUI for electronic devices, and particularly electronic mobile devices
Furthermore, as an ordered combination, the claim limitations are also not well-understood, routine, or conventional.
The Examiner is maintain the double patenting rejections.
Applicant’s arguments with respect to 35 USC § 103 have been fully considered and are not persuasive.
Regarding Applicant’s argument on pages 12-13, that the cited art of record does not teach “identify a plurality of bills matched with the customer based on cross-referencing the bill information and the customer account information by comparing one or more first customer identifiers present in the bill information with one or more second customer identifiers present in the account information,” the Examiner respectfully disagrees. As discussed in the 103 rejection below, Weinflash teaches the limitation of “identify a plurality of bills matched with the customer based on cross-referencing the bill information and the customer account information” at least at [0423]-[0427], describing a user selecting billers to set up payments with by selecting a biller from a list of billers including billers that the customer has used in the past. And, Bennette teaches the limitation of identifying “by comparing one or more first customer identifiers present in the bill information with one or more second customer identifiers present in the customer account information” at least at [0125]-[0126] and [0092] and [0083], describing records of transactions, which may be bills, able to be searched by account number, which may be a customer account number, to identify the bill. The cited art of record therefore teaches this limitation.
For the reasons above, Applicant’s arguments are not persuasive.
Double Patenting
Claims 1-20 are rejected on the ground of nonstatutory double patenting as being unpatentable over claims 1-17 of US Patent No. 11270279. Although the claims at issue are not identical, they are not patentably distinct from each other because both claims speak to a provider computing system associated with a provider, comprising: a processing circuit configured to: receive, in response to authenticating a biller computing system, bill information associated with a biller and customer account information associated with a customer of a provider, the bill information comprising a biller number; determine a customer number of the customer; identify a bill matched with the customer based on cross-referencing the bill information and the customer account information by comparing one or more first customer identifiers present in the bill information with one or more second customer identifiers present in the customer account information; present, by a graphical user interface on a user device associated with the customer, a notification including a summary of the bill; automatically launch, by the user device, the bill pay application based on receiving a selection of the summary; receive, via the bill pay application, a request to pay an amount of funds to the biller; generate a payment request comprising the customer number, the biller number, and the amount of funds; provide at least one post to a funds account circuit based on the payment request, the at least one post comprising instructions to deduct funds from a customer account associated with the customer number and add funds to a biller account associated with the biller number; generate and provide a payment data object comprising a plurality of attributes associated with the request and the customer to the biller computing system; and update a current value attribute of the payment data object to a new value based on the request. The claims differ in the fact that claims 1-17 of US Patent No. 11270279 teaches limitations omitted from the independent claims of the instant application. Outside of this difference, the claims are substantially similar. Therefore, since the claims of US Patent No. 11270279 anticipates every limitation of the instant application’s independent claims, the claims are being rejected as being double-patenting (see MPEP § 804(II)(B)(2)).
Dependent claims 2-8, 10-16, and 18-20 of the instant application recite substantially similar limitations to those of claims 1-17 of US Patent No. 11270279, and therefore are anticipated by US Patent No. 11270279.
Claims 1-20 are rejected on the ground of nonstatutory double patenting as being unpatentable over claims 1-15 of U.S. Patent No. 12112305. Although the claims at issue are not identical, they are not patentably distinct from each other because both claims speak to a provider computing system associated with a provider, comprising: a processing circuit configured to: receive, in response to authenticating a biller computing system, bill information associated with a biller and customer account information associated with a customer of a provider, the bill information comprising a biller number; determine a customer number of the customer; identify a bill matched with the customer based on cross-referencing the bill information and the customer account information by comparing one or more first customer identifiers present in the bill information with one or more second customer identifiers present in the customer account information; present, by a graphical user interface on a user device associated with the customer, a notification including a summary of the bill; automatically launch, by the user device, the bill pay application based on receiving a selection of the summary; receive, via the bill pay application, a request to pay an amount of funds to the biller; generate a payment request comprising the customer number, the biller number, and the amount of funds; provide at least one post to a funds account circuit based on the payment request, the at least one post comprising instructions to deduct funds from a customer account associated with the customer number and add funds to a biller account associated with the biller number; generate and provide a payment data object comprising a plurality of attributes associated with the request and the customer to the biller computing system; and update a current value attribute of the payment data object to a new value based on the request. The claims differ in the fact that claims 1-15 of U.S. Patent No. 12112305 teaches limitations omitted from the independent claims of instant application. Outside of this difference, the claims are substantially similar. Therefore, since the claims of U.S. Patent No. 12112305 anticipates every limitation of the instant application’s independent claims, the claims are being rejected as being double-patenting (see MPEP § 804(II)(B)(2)).
Dependent claims 2-8, 10-16, and 18-20 of the instant application recite substantially similar limitations to those of claims 1-15 of U.S. Patent No. 12112305, and therefore are anticipated by U.S. Patent No. 12112305.
Claim Rejections - 35 USC § 103
In the event the determination of the status of the application as subject to AIA 35 U.S.C. 102 and 103 (or as subject to pre-AIA 35 U.S.C. 102 and 103) is incorrect, any correction of the statutory basis (i.e., changing from AIA to pre-AIA ) for the rejection will not be considered a new ground of rejection if the prior art relied upon, and the rationale supporting the rejection, would be the same under either status.
The following is a quotation of 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 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-6, 9-14, and 17-19 are rejected under 35 U.S.C. 103 as being unpatentable over US 20180121975 A1 (“Weinflash”) in view of US 20150186855 A1 (“Bennett”).
Regarding claim 1, Weinflash discloses a provider computing system associated with a provider, comprising: a processing circuit configured to (See at least FIG. 10, Application Service Provider 1030. Application server provider may be a computer. See at least [0401].):
receive, in response to authenticating a biller computing system (Billers register for real-time payment transactions with a transaction system. The biller can send a request to register to the transaction system. The request to register under a certified biller status includes a unique public identifier, and due diligence can be used to ensure the public identifier, contact information, and the biller account provided in the request are legitimately associated with the biller, see at least [0403]-[0405]. See also FIG. 29, Biller 2980 using Biller system 2970. See also [0400].),
bill information associated with a biller and customer account information associated with a customer of a provider (The payors (e.g., sender) can be known to transaction system to be customers of certain billers (e.g., biller) based on the confirmation messages, based on information provided by the biller financial institution (e.g., receiving participant), based on information provided by the payor financial institution (e.g., sending participant), and/or based on information provided by application service provider, such as a mobile wallet provider or an application running within or alongside the mobile wallet in sender system. The biller financial institution (e.g., receiving participant), and/or payor financial institution (e.g., sending participant) can determine that the payor is a customer of a certain biller (e.g., biller) based on payments previously made from the payor's account (e.g., sender account) to the biller account (e.g., recipient account, billing account). For example, the biller financial institution (e.g., receiving participant) can determine that a first payor (e.g., sender) has sent payments to an electric company (e.g., biller) out of sender account to recipient account in the past, and the biller financial institution (e.g., receiving participant) can send this information to transaction system, which can send an enrollment message to the first payor (e.g., sender) to notify the first payor (e.g., sender) that the electric company (e.g., biller) is available to be paid through real-time payment transactions. See at least [0415].),
determine a customer number of the customer (The application service provider can send a credit call to transaction system. See at least [0257]. Credit call can include elements in the inquiry message. See at least [0258]. Inquiry message can include identifier of the account of the payor, including routing number/account number. See also [0070]. See also [0127]. The Examiner interprets the identifier of the account of the payer as the customer number.);
identify a plurality of bills matched with the customer based on cross-referencing the bill information and the customer account information (Mobile app allowing a user to set up payments with companies that the user pays frequently. Upon the user selecting “scan account” the system can scan the account associated with the payer to determine billers that have been paid in the past using the account. The user can select billers to set up payments with. User can select one or more billers in the list of billers, and the list of billers may include billers that the user has been billed by in the past. Once the user is enrolled, invoices can be sent to the payor via text. The biller can initiate invoices which can be sent through the biller system to the payor. See at least [0423]-[0427]. See also FIG. 30 and 31.);
present, on a first graphical user interface on a user device associated with the customer while a bill pay application is in an unlaunched state, a notification including a summary of the plurality of bills, wherein the summary includes a list of the plurality of bills (Display screen is an example of an invoice message that can be displayed in a text message (e.g., SMS (Short Message Service) message, MMS (Multimedia Messaging Service) message) that is sent to a payor (e.g., sender). In various embodiments, the invoice message sent to the payor (e.g., sender), as displayed in display screen, can be a short message, without billing details, that simply notifies the payor (e.g., sender) of the invoice and/or reminds the payor (e.g., sender) to pay the invoice. For example, display screen can include a message source, such as “BrandX.” In several embodiments, display screen can include a message, which can inform the payor (e.g., sender) that an invoice is available and the bill is due soon, such as by stating “Your Visa bill is due soon. Pay with BrandX.” See at least [0434] and FIG. 33-34, (depicting a received text message from BrandX on the user’s device information regarding the user’s Visa bill, and depicting a received text message from BrandX on the user’s device information regarding the user’s Verizon bill). Multiple billers sending multiple invoices to payors, see at least [0423]-[0427]. A person having ordinary skill in the art at the time of filing would understand that Weinflash teaches an interface of a text message thread with multiple bill summaries for each bill sent to the user via text message, and thefore Weinflash teaches the list of the plurality of bills via teaching a text message interface that sends messages to the user regarding multiple bills..);
automatically launch, by the user device, the bill pay application based on receiving a selection of the summary (For example, display screen can include a message source, such as “BrandX.” In several embodiments, display screen can include a message, which can inform the payor that an invoice is available and the bill is due soon, such as by stating “Your Visa bill is due soon. Pay with BrandX.” In various embodiments, message can include a hyperlink, such as the “BrandX” hyperlink, which can allow the payor can click hyperlink to navigate to one or more screens with additional invoice information, such as the invoice information and/or the response options shown in FIG. 32. See at least [0434] and see at least FIG. 33, and see at least FIG. 32 depicting the screen navigated to in response to selecting the hyperlink in FIG. 33. (See also [0436]-[0437] and FIG. 34, depicting a text message including a hyperlink “BrandX” similar to hyperlink in FIG. 33 in which payor can click to navigate to screens with additional invoice information.) Clicking the hyperlink to navigate to a screen that includes options including “Pay Now”. See at least [0437], [0414], and FIG. 32, depicting the screen that can be navigating to after selecting the BrandX hyperlink, including options such as “Pay Now.”);
present a second graphical user interface within the bill pay application while the bill pay application is in a launched state, the second graphical user interface displaying additional information associated with one of the plurality of bills, wherein the second graphical user interface is accessed responsive to selecting the bill from the list of the plurality of bills displayed on the first graphical user interface while the bill pay application is in the unlaunched state (For example, display screen can include a message source, such as “BrandX.” In several embodiments, display screen can include a message, which can inform the payor that an invoice is available and the bill is due soon, such as by stating “Your Visa bill is due soon. Pay with BrandX.” In various embodiments, message can include a hyperlink, such as the “BrandX” hyperlink, which can allow the payor can click hyperlink to navigate to one or more screens with additional invoice information, such as the invoice information and/or the response options shown in FIG. 32. See at least [0434] and see at least FIG. 33, and see at least FIG. 32 depicting the screen navigated to in response to selecting the hyperlink in FIG. 33. (See also [0436]-[0437] and FIG. 34, depicting a text message including a hyperlink “BrandX” similar to hyperlink in FIG. 33 in which payor can click to navigate to screens with additional invoice information.) Clicking the hyperlink to navigate to a screen that includes options including “Pay Now”. See at least [0437], [0414], and FIG. 32, depicting the screen that can be navigating to after selecting the BrandX hyperlink, including options such as “Pay Now.”);
receive, via the bill pay application, a request to pay an amount of funds to the biller for the selected bill of the plurality of bills (The payor can select a payment amount using payment input area, and the payment amount entered can be displayed in payment amount selection. Payment for the payment amount entered in payment amount selection can be confirmed using payment selection button and/or payment selection button. By selecting payment selection button, the payor can choose to have the payment made immediately. See at least [0444]. See also FIG. 36.);
generate a payment request comprising the customer number, the biller number, and the amount of funds (Sender can use sender system to submit payment in real-time to application service provider in a message. Application service provider can receive message from sender system, and can send a message to transaction system to debit sender account. See at least [0182]. The application service provider can send a credit call to transaction system. See at least [0257]. Credit call can include elements in the inquiry message. See at least [0258]. Elements in the inquiry message include a payment amount. See at least [0127]. Inquiry message can include a dollar amount specified, account number of requestor, payee, and/or depositor. See at least [0069]. Inquiry message can include identifier of the account of the payor, including routing number/account number. See also [0070]. See also [0127]. The Examiner interprets the account number of the payee as a biller number. The Examiner also interprets the identifier of the account of the payer as the customer number.),
wherein the instructions to deduct funds from the customer account and add funds to the biller account are provided simultaneously (The payor can select a payment amount using payment input area, and the payment amount entered can be displayed in payment amount selection. Payment for the payment amount entered in payment amount selection can be confirmed using payment selection button and/or payment selection button. By selecting payment selection button, the payor can choose to have the payment made immediately. See at least [0444]. See also FIG. 36, depicting “Pay now” button. The Examiner interprets the Pay now button as instructions to deduct funds from the customer account and add funds to the biller account.);
provide at least one post to a funds account circuit based on the payment request, the at least one post comprising instructions to deduct funds from a customer account associated with the customer number and add funds to a biller account associated with the biller number (Sender can use sender system to submit payment in real-time to application service provider in a message. Application service provider can receive message from sender system, and can send a message to transaction system to debit sender account. Transaction system can receive message from application service provider, and can send a message to sending participant to debit sender account in sending participant. Sending participant can receive message from transaction system, can debit the funds for the payment from sender account, and can credit the funds to sending participant settlement account. See at least [0181]. Transaction system includes a communication system capable of facilitating communications regarding crediting and debiting of accounts. See at least [0383]-[0384]. The Examiner is interpreting the communication system of the transaction system as a funds account circuit.);
generate and provide a payment data object comprising a plurality of attributes associated with the request and the customer to the biller computing system (Once application service provider has determined that the debit of sender account was successful, application service provider can send a message to transaction system of a promise-to-pay credit. Transaction system can receive message from application service provider. See at least [0182]. Transaction system may be a computer. See at least [0162]. The credit call (such as the promise-to-pay credit call message 1177) can include various elements in the message. See at least [0258]. The Examiner interprets the “promise-to-pay credit” message as a payment data object, and the Examiner also interprets the transaction system as a biller computing system.); and
update a current value attribute of the payment data object to a new value based on the request (Application service provider may provide a user interface or API for the payment application and be in communication with the transaction system, sender system, sending participant, and receiving participant to send and receive data via API. See at least [0206]. See also [0174], [0396], [0427], FIGs 10-12, Application Service Provider 1030. Sending participant can apply the debit of funds from sender account in real-time for providing a payment guarantee. Billing account can be updated in real-time to reflect the payment in the balance and open-to-buy (OTB) amount of the USAA credit card, for example. Receiving participant can update recipient account to apply a hard credit in real-time after receiving participant receives the promise-to-pay (e.g., message 1177). Recipient account can be credited from receiving participant settlement account. See at least [0192]. See also [0182], [0176], and see also [0287], disclosing message protocols including real-time promise-to-pay message protocol used for real-time funds transfer..).
While Weinflash discloses bill information, Weinflash does not expressly disclose the bill information comprising a biller number. Furthermore, while Weinflash discloses identifying, Weinflash does not expressly disclose identifying by comparing one or more first customer identifiers present in the bill information with one or more second customer identifiers present in the customer account information.
However, Bennett discloses the bill information comprising a biller number (Transaction file for a bill includes biller bill number, see at least [0092].);
identifying by comparing one or more first customer identifiers present in the bill information with one or more second customer identifiers present in the customer account information (Records stored in the transaction database for several transactions for a biller. The records can be searched by account number to identify all records in the transaction database that are associated with a particular account number. See at least [0125]-[0126]. Account number may be a customer account number, see at least [0092]. Transaction may be a bill, see at least [0083]. See also FIG. 3A-3B.).
From the teaching of Bennett, it would have been obvious to one having ordinary skill in the art before the effective filing date to modify the bill information of Weinflash to include a biller number, as taught by Bennett, and to modify the identifying of a bill of Weinflash to identify by comparing one or more first customer identifiers present in the bill information with one or more second customer identifiers present in the customer account information, as taught by Bennett, in order to improve efficiency of managing payments between payors and billers (see Bennett at least at [0002]-[0003]), and in order to increase collection yields for a biller (see Bennett at least at [0083]).
Regarding claim 2, the combination of Weinflash and Bennett discloses the limitations of claim 1, as discussed above, and Weinflash further discloses generating and providing the payment data object to the biller computing system further comprises pushing the payment data object to the biller computing system (Once application service provider has determined that the debit of sender account was successful, application service provider can send a message to transaction system of a promise-to-pay credit. Transaction system can receive message from application service provider. See at least [0182]. Promise-to-pay message can be sent in real-time. See at least [0176]. See also [0287], disclosing message protocols including real-time promise-to-pay message protocol used for real-time funds transfer).
Regarding claim 3, the combination of Weinflash and Bennett discloses the limitations of claim 1, as discussed above, and Weinflash further discloses providing the payment data object to the biller computing system further comprises providing the payment data object to the biller computing system in real time (Once application service provider has determined that the debit of sender account was successful, application service provider can send a message to transaction system of a promise-to-pay credit. Transaction system can receive message from application service provider. See at least [0182]. Promise-to-pay message can be sent in real-time. See at least [0176]. See also [0287], disclosing message protocols including real-time promise-to-pay message protocol used for real-time funds transfer).
Regarding claim 4, the combination of Weinflash and Bennett discloses the limitations of claim 1, as discussed above, and Weinflash further discloses update the customer account and the biller account based on the payment data object (Application service provider can receive message from sender system, and can send a message to transaction system to debit sender account. Transaction system can receive message from application service provider, and can send a message to sending participant to debit sender account in sending participant. Sending participant can receive message from transaction system, can debit the funds for the payment from sender account, and can credit the funds to sending participant settlement account. See at least [0181]. Once application service provider has determined that the debit of sender account was successful, application service provider can send a message to transaction system of a promise-to-pay credit. Transaction system can receive message from application service provider. See at least [0182].).
Regarding claim 5, the combination of Weinflash and Bennett discloses the limitations of claim 1, as discussed above, and Weinflash further discloses generate (The credit call, also known as the promise-to-pay. See at least [0257]. Credit call includes elements in the inquiry message. See at least [0258]. Inquiry message can include a dollar amount specified, account number of requestor, payee, and/or depositor. See at least [0069]. Inquiry message can include identifier of the account of the payor, including routing number/account number. See also [0070]. Data elements of the credit call include billing account information. See at least [0260].)
or update a bill data object that comprises at least one of the customer number, the amount of funds, or the biller number.
Regarding claim 6, the combination of Weinflash and Bennett discloses the limitations of claim 1, as discussed above, and Weinflash further discloses the processing circuit is further configured to: generate a third graphical user interface for display on the user device based on the bill information and in response to the bill pay application being launched (A second graphical user interface as depicted in FIG. 40, displaying a payment completion indicator indicating the payment to the bill has been successfully made. See at least [0454] and FIG. 40.).
Claim 9 has similar limitations found in claim 1 above, and therefore is rejected by the same art and rationale.
Claim 10 has similar limitations found in claim 2 above, and therefore is rejected by the same art and rationale.
Claim 11 has similar limitations found in claim 3 above, and therefore is rejected by the same art and rationale.
Claim 12 has similar limitations found in claim 4 above, and therefore is rejected by the same art and rationale.
Claim 13 has similar limitations found in claim 5 above, and therefore is rejected by the same art and rationale.
Claim 14 has similar limitations found in claim 6 above, and therefore is rejected by the same art and rationale.
Claim 17 has similar limitations found in claim 1 above, and therefore is rejected by the same art and rationale. And Weinflash discloses a non-transitory computer-readable storage media having instructions stored thereon that, when executed by a processing circuit, cause the processing circuit to perform claim functions (see Weinflash at least at [0499]).
Regarding claim 18, the combination of Weinflash and Bennett discloses the limitations of claim 17, as discussed above, and Weinflash further discloses update the customer account and the biller account based on the payment data object (Application service provider can receive message from sender system, and can send a message to transaction system to debit sender account. Transaction system can receive message from application service provider, and can send a message to sending participant to debit sender account in sending participant. Sending participant can receive message from transaction system, can debit the funds for the payment from sender account, and can credit the funds to sending participant settlement account. See at least [0181]. Once application service provider has determined that the debit of sender account was successful, application service provider can send a message to transaction system of a promise-to-pay credit. Transaction system can receive message from application service provider. See at least [0182].);
generate a bill data object that comprises at least one of the customer number, the amount of funds, or the biller number (The credit call, also known as the promise-to-pay. See at least [0257]. Credit call includes elements in the inquiry message. See at least [0258]. Inquiry message can include a dollar amount specified, account number of requestor, payee, and/or depositor. See at least [0069]. Inquiry message can include identifier of the account of the payor, including routing number/account number. See also [0070]. Data elements of the credit call include billing account information. See at least [0260].).
Claim 19 has similar limitations found in claim 2 above, and therefore is rejected by the same art and rationale.
Claims 7-8, 15-16, and 20 are rejected under 35 U.S.C. 103 as being unpatentable over Weinflash in view of Bennett, and in further view of US 10891037 B1 (“Mackrell”).
Regarding claim 7, the combination of Weinflash and Bennett discloses the limitations of claim 6, as discussed above, and Weinflash further discloses the second graphical user interface enables a second payment request to be initiated by the user device (A second graphical user interface as depicted in FIG. 40, displaying a payment completion indicator indicating the payment to the bill has been successfully made. Display screen can include a selector to send another payment. See at least [0454] and FIG. 40.).
While Weinflash discloses a second payment request, Weinflash does not expressly disclose the second payment request is to pay a second amount of funds.
However, Mackrell discloses the second payment request is to pay a second amount of funds (For example, a first sub-screen (“scheduled out”) may present information regarding bill payments that are scheduled for payment in the near-term (e.g., until the next scheduled payday or within a pre-determined time period measured from the current date). Bill payment information provided by each sub-screen may include, for example, the billing parties and the payment due to each, the scheduled date of each payment, and the total amount scheduled to be paid. See at least col. 5, lines 39-52, and see at least FIG. 4B, depicting sub-screen with payment amount 87.17 for T-Mobile and 600.00 for Geico.).
From the teaching of Mackrell, it would have been obvious to one having ordinary skill in the art before the effective filing date to modify the second payment request of Weinflash to be for a second amount of funds, as taught by Mackrell, in order to improve user interfaces of applications for consumers and to improve customer experience with transferring funds via an application (see Mackrell at least at col. 1, lines 23-67), and in order to improve customer experience in using applications for bill payments (see Mackrell at least at col. 2, lines 29-42.).
Regarding claim 8, the combination of Weinflash, Bennett, and Mackrell discloses the limitations of claim 7, as discussed above, and Weinflash further discloses generating and providing the payment data object to the biller computing system comprises enabling the biller computing system to access the provider computing system to retrieve the payment data object (Application service provider may provide a user interface or API for the payment application and be in communication with the transaction system, sender system, sending participant, and receiving participant to send and receive data via API. See at least [0206]. See also [0174], [0396], [0427], FIGs 10-12, Application Service Provider 1030.).
Claim 15 has similar limitations found in claim 7 above, and therefore is rejected by the same art and rationale.
Claim 16 has similar limitations found in claim 8 above, and therefore is rejected by the same art and rationale.
Regarding claim 20, the combination of Weinflash and Bennett discloses the limitations of claim 17, as discussed above, and Weinflash further discloses generate a second graphical user interface for display on the user device based on the bill information and in response to the bill pay application being launched (A second graphical user interface as depicted in FIG. 40, displaying a payment completion indicator indicating the payment to the bill has been successfully made. See at least [0454] and FIG. 40.),
the second graphical user interface enabling a second payment request to be initiated by the user device; and present the second graphical user interface on the user device (A second graphical user interface as depicted in FIG. 40, displaying a payment completion indicator indicating the payment to the bill has been successfully made. Display screen can include a selector to send another payment. See at least [0454] and FIG. 40.).
While Weinflash discloses a second payment request, Weinflash does not expressly disclose the second payment request is to pay a second amount of funds.
However, Mackrell discloses the second payment request is to pay a second amount of funds (For example, a first sub-screen (“scheduled out”) may present information regarding bill payments that are scheduled for payment in the near-term (e.g., until the next scheduled payday or within a pre-determined time period measured from the current date). Bill payment information provided by each sub-screen may include, for example, the billing parties and the payment due to each, the scheduled date of each payment, and the total amount scheduled to be paid. See at least col. 5, lines 39-52, and see at least FIG. 4B, depicting sub-screen with payment amount 87.17 for T-Mobile and 600.00 for Geico.).
From the teaching of Mackrell, it would have been obvious to one having ordinary skill in the art before the effective filing date to modify the second payment request of Weinflash to be for a second amount of funds, as taught by Mackrell, in order to improve user interfaces of applications for consumers and to improve customer experience with transferring funds via an application (see Mackrell at least at col. 1, lines 23-67), and in order to improve customer experience in using applications for bill payments (see Mackrell at least at col. 2, lines 29-42.).
Conclusion
The prior art made of record and not relied upon is considered pertinent to applicant's disclosure.
Kanchan Mahajan, "A novel method for automatic electricity billing system using Ad-Hoc networks," dated June 2017, IEEE, https://ieeexplore.ieee.org/document/7955359?source=IQplus (hereinafter "Mahajan") discloses to provide a possible solution on issues is automation in meter reading collection process for electricity billing, so the readings are taken via micro-controller via event triggering. The bill will be prepared and notification is sent to customer via GSM. A customer can make a bill payment via an application. This more efficient and independent system will help to avoid the manual way of paying the bills, automation will establish transparency in billing system & also increase user awareness about consumption of electricity via an android application interface.
Pensri Pukkasenunk, "An Efficient of Secure Mobile Phone Application for Multiple Bill Payments," dated March 2016, IEEE, https://ieeexplore.ieee.org/document/7471248?source=IQplus (hereinafter "Pukkasenunk") discloses a secure mobile bill payment application. It is developed from a concept of a lightweight, agent-based, secure mobile payment protocol. This aspect focuses on measuring the efficiency of the application while processing on a mobile phone.
Oladotun Omosebi, "An Openstack Based Accounting and Billing Service for Future Internet Applications," dated March 2016, IEEE, https://ieeexplore.ieee.org/document/7474146?source=IQplus (hereinafter "Omosebi") discloses following the business benefits of the cloud services into more advanced and modular systems the requirements for effective accounting and billing with regards to the service usage and the accurate billing of consumers of services becomes challenging. This work focuses on cloud platforms, their platform segregations and services, and presents an accounting and billing service that can be used to rate, charge and bill consumers of within a cloud or an inter-cloud platforms. The solution is developed based on FIWARE platform, which promotes the usage of Cloud Computing in Europe by designing general purpose cloud services namely as Generic Enablers (GEs).
US 11182767 B1 (“Mateer’) discloses systems and methods for managing payments to a payee using a communication device associated with a payor. In one embodiment, the method includes accessing billing data associated with a payor, and determining whether to send a payment notification to the communication device based on the billing data. The method also includes sending the payment notification to the communication device. The payment notification initiates a prompt on the communication device.
US 11010763 B1 (‘Fillinger’) discloses transmitting push notification data to a computing device, the push notification data being processable by the computing device to display a push notification, receiving biometric data, the biometric data being provided from user input responsive to the push notification, determining that a user providing the user input is authenticated at least partially based on the biometric data, and inducing execution of a transaction in response to determining that the user is authenticated.
US 11354675 B1 (“Tuomikoski’”) discloses an app administration service that receives an indication of the intended transaction from the interactive voice response service and triggers provision of a push notification to at least one app running on at least one electronic device associated with the user. The push notification includes an indication of a deep dive view to be presented on the app. The deep dive view includes a particular transaction screen of the app associated with the intended transaction.
Any inquiry concerning this communication or earlier communications from the examiner should be directed to RAVEN E YONO whose telephone number is (313)446-6606. The examiner can normally be reached Monday - Friday 8-5PM 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, Bennett M Sigmond can be reached at (303) 297-4411. 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.
/RAVEN E YONO/Primary Examiner, Art Unit 3694
Prosecution Insights