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 action is in reply to the amendments filed on February 23, 2026.
• Claims 1, 6-7, 9, 14-15, 17-18, and 20 have been amended and are hereby entered.
• Claims 1-20 are currently pending and have been examined.
• This action is made FINAL.
Response to Arguments
Applicant’s arguments filed February 23, 2026 have been fully considered but they are not persuasive.
The Examiner is withdrawing the 35 USC § 112 rejections due to Applicant’s amendments.
The Examiner is maintaining the double patenting rejections.
Applicant’s arguments with respect to 35 USC § 101 have been fully considered and are not persuasive.
Regarding Applicant’s argument on page 10, that the claims are not directed to an abstract idea, the Examiner respectfully disagrees. Applicant further argues on page 10 that the claims are directed to an improved manner of displaying user interfaces and facilitating user actions performed on an application. The argument is not persuasive. As indicated in the 35 USC § 101 rejection below, the claimed invention allows for generating a bill, posting a payment to an account, and generating a notification of the bill payment. The Specification at [0002] states: “the present disclosure relates to facilitating consumer-to-business bill payments by providing real-time, on-demand updates to multiple accounts associated with such a payment.” Furthermore, the Specification at [0004] states: “To deal with these complexities, existing systems and methods require multiple separate entities and computing systems that cause substantial delays (e.g., several days) in fully executing customer-to-business bill payments. Such delays create confusion among customers, tie up funds in pending transactions that otherwise may be used for other transactions, require substantial computing resources, and otherwise reduce the usability of bill payment systems and graphical user interfaces such as those provided with mobile banking applications.” The Specification and claims focus on an improvement to facilitating bill payments between payors and payee, which is a commercial and legal interaction including sales activities or behaviors which falls within the category of Certain Methods of Organizing Human Activity and therefore is an abstract idea.
Regarding Applicant’s arguments on pages 10-11, that the claims integrate a practical application, the Examiner respectfully disagrees. Under the Patent Subject Matter Eligibility analysis, Step 2A, prong two, integration into a practical application requires an additional element(s) or a combination of additional elements in the claim to apply, rely on, or use the judicial exception in a manner that imposes a meaningful limit on the judicial exception, such that the claim is more than a drafting effort designed to monopolize the exception. Limitations that are not indicative of integration into a practical application are those that generally link the use of the judicial exception into a particular technological environment or field of use-see MPEP 2106.05(h). Here the claims recite a provider computing system comprising: a processing circuit configured to perform claim functions; 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; a biller computing system; a graphical user interface on a user device; automatically launch, the bill pay application based on receiving a selection of the summary; present a second graphical user interface within the bill pay application displaying data, wherein the second graphical user interface is accessed responsive to selecting; a funds account circuit such that they amount to no more than generally linking the use of the judicial exception to a particular technological environment or field of use (e.g., a computer network) (see MPEP 2106.05(h)).
Furthermore, and in response to Applicant’s arguments on page 11, where Applicant argues that the claims provide a technical solution to a technical problem, in determining whether a claim integrates a judicial exception into a practical application, a determination is made of whether the claimed invention pertains to an improvement in the functioning of the computer itself or any other technology or technical field (i.e., a technological solution to a technological problem). Here, the claims recite generic computer components, i.e., a generic processor, a memory storing a computer program executable by the processor to perform the claimed method steps and system functions. The processor, memory and system are recited at a high level of generality and are recited as performing generic computer functions customarily used in computer applications.
Furthermore, the Specification describes a problem and improvement to a business or commercial process at least at [0002]-[0004], describing addressing complexities in existing bill pay systems and at [0004], stating “To deal with these complexities, existing systems and methods require multiple separate entities and computing systems that cause substantial delays (e.g., several days) in fully executing customer-to-business bill payments. Such delays create confusion among customers, tie up funds in pending transactions that otherwise may be used for other transactions, require substantial computing resources, and otherwise reduce the usability of bill payment systems and graphical user interfaces such as those provided with mobile banking applications.”
Regarding Applicant’s arguments on page 12, that the claims provide significantly more than the abstract idea, the Examiner respectfully disagrees. The limitations are directed to an abstract idea and when determining if the claims are directed to significantly more, the additional limitations of the claims in addition to the abstract idea are analyzed. In the instant application, the additional elements of the claim include a provider computing system comprising: a processing circuit configured to perform claim functions; 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; a biller computing system; a graphical user interface on a user device; automatically launch, the bill pay application based on receiving a selection of the summary; present a second graphical user interface within the bill pay application displaying data, wherein the second graphical user interface is accessed responsive to selecting; a funds account circuit. The additional limitations, when considered both individually and in combination, do not affect an improvement to another technology or technological field; the claims do not amount to an improvement to the functioning of the computer itself; and the claims do not move beyond a general link of use of an abstract idea to a particular technological environment. Therefore, the claims merely amount to merely generally linking the use of the abstract idea to a particular technological environment or field of use (e.g., a computer network), and is considered to amount to nothing more than requiring a generic computer network to carry out the abstract idea itself. The specifics about the abstract idea do not overcome the rejection.
The claims are not patent eligible.
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 “present a second graphical user interface within the bill pay application 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,” the Examiner respectfully disagrees. As discussed in the 103 reject below, Weinflash discloses this limitation at least at [0434] and [0436]-[0437], and FIG. 32-34, describing and depicting a display screen including a message, which can inform the payor that an invoice is available and the bill is due soon, and a 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. The cited art of record therefore teaches this limitation.
Regarding Applicant’s arguments on page 13 that the cited art of record does not teach “provide at least one post to a funds account circuit based on the payment request...wherein the instructions to deduct funds from the customer account and add funds to the biller account are provided simultaneously,” the Examiner respectfully disagrees. As discussed in the 103 reject below, Weinflash discloses this limitation at least at [0444] and FIG. 36, describing and depicting payment for the payment amount entered in payment amount selection can be confirmed using payment selection button and/or payment selection button, and by selecting payment selection button, the payor can choose to have the payment made immediately. The Examiner is interpreting the Pay now button as instructions to deduct funds from the customer account and add funds to the biller account. The prior 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 § 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-20 are rejected under 35 U.S.C. 101 because the claimed invention recites an abstract idea without significantly more. Independent claims 1, 9, and 17 are directed to a system (claim 1), a method (claim 9), and an apparatus (claim 17). Therefore, on its face, each independent claim 1, 9, and 17 are directed to a statutory category of invention under Step 1 of the Patent Subject Matter Eligibility analysis (see MPEP 2106.03).
Under Step 2A, Prong One of the Patent Subject Matter Eligibility analysis (see MPEP 2106.04), claims 1, 9, and 17 recite, in part, a system, a method, and an apparatus of organizing human activity. Using the limitations in claim 1 to illustrate, the claim recites a provider; receive, in response to authenticating, 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 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 customer account information; present, associated with the customer, a notification including a summary of the plurality of bills, wherein the summary includes a list of the plurality of bills; present additional information associated with one of the plurality of bills, wherein is accessed in response to selecting the bill from the list of the plurality of bills; receive a request to pay an amount of funds to the biller for the selected bill of the plurality of bills; generate a payment request comprising the customer number, the biller number, and the amount of funds; provide at least one post 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, wherein the instructions to deduct funds from the customer account and add funds to the biller account are provided simultaneously; generate and provide a payment data object comprising a plurality of attributes associated with the request and the customer; and update a current value attribute of the payment data object to a new value based on the request. The limitations, as drafted, is a process that, under its broadest reasonable interpretation, covers commercial and legal interactions (certain methods of organizing human activity), but for the recitation of generic computer components. The claims as a whole recite a method of organizing human activity. The claimed inventions allows for generating a bill, posting a payment to an account, and generating a notification of the bill payment, which is a commercial and legal interaction including sales activities or behaviors. The mere nominal recitation of a biller computing system and a user device do not take the claim out of the methods of organizing human activity grouping. Thus, the claims recite an abstract idea.
Under Step 2A, Prong Two of the Patent Subject Matter Eligibility analysis (see MPEP 2106.04), the judicial exception is not integrated into a practical application. In particular, the additional elements of a provider computing system comprising: a processing circuit configured to perform claim functions; 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; a biller computing system; a graphical user interface on a user device; automatically launch, the bill pay application based on receiving a selection of the summary; present a second graphical user interface within the bill pay application displaying data, wherein the second graphical user interface is accessed responsive to selecting; a funds account circuit are recited at a high-level of generality (i.e., as a generic computer components performing generic computer functions receiving bill information, receiving a request, notifying a user of a bill) such that it amounts to no more than generally linking the use of the judicial exception to a particular technological environment or field of use (e.g., a computer network).-see MPEP 2106.05(h).
Accordingly, the combination of the additional elements do not integrate the abstract idea into a practical application because they do not impose any meaningful limits on practicing the abstract idea. The claims are directed to an abstract idea.
Under Step 2B of the Patent Subject Matter Eligibility analysis (see MPEP 2106.05), the claim(s) does/do not include additional elements that are sufficient to amount to significantly more than the judicial exception. As discussed above with respect to integration of the abstract idea into a practical application, the additional elements in the claims amount to no more than generally linking the use of the judicial exception to a particular technological environment or field of use (see MPEP 2106.05(h)). Generally linking the use of the judicial exception to a particular technological environment or field of use using generic computer components cannot provide an inventive concept.
The claims are not patent eligible.
The dependent claims have been given the full two part analysis including analyzing the additional limitations both individually and in combination. The dependent claim(s) when analyzed both individually and in combination are also held to be patent ineligible under 35 U.S.C. 101 because for the same reasoning as above and the additional recited limitation(s) fail(s) to establish that the claim(s) is/are not directed to an abstract idea. Dependent claims 3-5, 11-13, and 18 simply help to define the abstract idea. Dependent claims 2, 6-8, 10, 14-16, and 19-20 simply further describes the technological environment. The additional limitations of the dependent claim(s) when considered individually and as an ordered combination do not amount to significantly more than the abstract idea.
Viewing the claim limitations as an ordered combination does not add anything further than looking at the claim limitations individually. When viewed either individually, or as an ordered combination, the additional limitations do not amount to a claim as a whole that is significantly more than the abstract idea. Accordingly, claims 1-20 are ineligible.
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, 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, a 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 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 (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.
THIS ACTION IS MADE FINAL. 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 nonprovisional extension fee (37 CFR 1.17(a)) 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 mailing date of this final action.
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