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 FINAL Office action is issued in response to the Applicant’s submission filed on 27 November 2025.
Claims 1 and 11 have been amended.
Claims 3, 8, 13 and 18 are canceled.
Claims 1-2, 4-7, 9-12, 14-17 and 19-24 are pending and have been examined.
Claim Objections
The objection to claims 1, 2, 4-7, 9, 10-12, 14-17, 19-24 of the previous Office action is withdrawn in view of the amendments to claims 1 and 11.
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.
Claim(s) 1-2, 4-7, 9-12, 14-17 and 19-24 are rejected under 35 U.S.C. 103 as being unpatentable over DRYER (US 8538827 B1 to Dryer; Trevor D. et al.) in view of HAWES (US 11288642 B1 to HAWES, B.C. et al.).
Regarding claim(s) 1 and 11,
DRYER discloses:
A computing system [(claim 1)]/A computer-implemented method [(claim 11)] (see, at least, DRYER: col. 1, ll. 50-53: computer-implemented methods for alerting a consumer during an on-line transaction.; col. 3, ll. 24-27: system for alerting a consumer during an on-line transaction),
comprising: a processor (see, at least, DRYER col. 2, ll. 60-67: a computer program product comprising a non-transitory, computer readable storage medium having instructions which, when executed by a first computer of a consumer, cause the one or more processors to execute a process for alerting the consumer during an on-line transaction);
and a memory coupled to the processor, the memory storing computer-executable instructions that, when executed, configure the processor to(see, at least, DRYER col. 2, ll. 60-67: a computer program product comprising a non-transitory, computer readable storage medium having instructions which, when executed by a first computer of a consumer, cause the one or more processors to execute a process for alerting the consumer during an on-line transaction):
receive, via a browser application on a computing device during a web browsing session, a request to retrieve a first web page from a web server (see, at least, DRYER col. 2, ll. 12-19: method further comprises visiting a merchant website hosted by a second computer using the web browser, beginning an on-line transaction at the merchant website using the web browser, and before the on-line transaction has been completed, viewing an alert generated by the add-on and generated based at least in part upon a pre-determined result relative to the alert criteria that would occur if the on-line transaction is allowed to be completed; col. 3, ll. 36-44: the alert is displayed in response to the consumer visiting a certain URL address of a merchant and/or at different stages of an on-line transaction, e.g., when the consumer adds an item to an electronic shopping cart of a website of the merchant, when the consumer proceeds to checkout with the item already added to an electronic shopping cart, when the consumer selects a credit card or manually enters credit card information..)
process the first web page based on performing, by a document processing module, contextual scanning of document data of the first web page (see, at least, DRYER: col. 8, ll. 14-24: monitors the consumer's activities on the website 221 (e.g., by screen scraping or scanning HTML source code of the website pages 221 displayed) to determine when the consumer 215 has initiated or is in the process of an on-line purchase or transaction. For this purpose, the plug-in 213 is operable, programmed or configured to monitor data of the website 221 during consumer navigation and data selection or entry to identify any on-line transaction indicators 227 or keywords, phrases and/or numbers associated with the consumer 215 being engaged in an on-line transaction (and before the transaction is completed);
determine that the first web page is associated with a first entity based on the processing (see, at least, DRYER col. 3, ll. 13-20: detects that the consumer is in the process of purchasing the item during the on-line transaction based at least in part upon at least one transaction indicator, which may be data displayed by the web browser. The transaction indicator may be a pre-determined URL address or pre-determined on-line merchant (e.g., AMAZON, AMAZON.COM, E-BAY, E-BAY.COM);
in response to determining that the first web page is associated with the first merchant, (DRYER: figure 6: “Merchant Name + Transaction Word/Phrase” “triggers” determination “whether alert generated”)
determine a first allocation of resources comprising a user-defined budget indicating maximum resource amounts for each of to a plurality of categories of resource contribution (DRYER: col. 1, ll. 50-65: (6) Certain embodiments are related to computer-implemented methods for alerting a consumer during an on-line transaction. […] the add-on (such as a plug-in) may utilize an application program interface (API) of the FMS (financial management system) to identify data of the consumer's […] budget or profile.; DRYER col. 3, ll. 26-35: (13) In a single or multiple embodiments, whether an alert is generated by the add-on may depend upon whether execution of the on-line transaction to purchase the item lead to a pre-determined result such as the consumer exceeding a predetermined budget amount for purchases of the item, exceeding a predetermined budget amount for purchase from the merchant, […].; col. 7, ll. 37-44: consumer 215 selects or confirms alert criteria or rules 247 including, but not limited to, a budget for purchases made from merchant 225, a budget for purchases of a particular item or category of items; figure 4: budget by category: DVD Budget: $50 per month; Clothing Budget: $100 per month and entity Amazon.com: $200 per month, Ebay.com per month Budget, Macys.com per month Budget)
based on transmitting, using an application programming interface (API) associated with a resource server, an account query for obtaining allocation data of defined resource allocations for the resource account; (DRYER: col. 1, ll. 50-65: (6) Certain embodiments are related to computer-implemented methods for alerting a consumer during an on-line transaction. […] the add-on (such as a plug-in) may utilize an application program interface (API) of the FMS (financial management system) to identify data of the consumer's […] budget or profile.; DRYER col. 3, ll. 26-35: (13) In a single or multiple embodiments, whether an alert is generated by the add-on may depend upon whether execution of the on-line transaction to purchase the item lead to a pre-determined result such as the consumer exceeding a predetermined budget amount for purchases of the item, exceeding a predetermined budget amount for purchase from the merchant, […]; col. 11, ll. 40-45: the plug-in 213 may require the consumer 215 to log into the FMS 240 to view the account or budget that is the subject of an alert 214. For this purpose, the plug-in 213 can be configured or programmed to interface with the FMS 240 via the API 227);
detect, in real-time, a first user page action in the browser application for interacting with the first web page based on detecting a corresponding page interaction event that is initiated via the computing device (DRYER: col. 4, ll. 60-67: providing real-time alerts to consumers during an on-line transaction, i.e., before the on-line transaction has been completed such as before a consumer clicks "Proceed to Checkout" or "Place Your Order" to purchase an item; col. 3, ll. 13-26: the add-on detects that the consumer is in the process of purchasing the item during the on-line transaction based at least in part upon at least one transaction indicator, which may be data displayed by the web browser. The transaction indicator may be a pre-determined URL address or pre-determined on-line merchant (e.g., AMAZON, AMAZON.COM, E-BAY, E-BAY.COM), a pre-determined word or phrase associated with an on-line transaction (e.g., "shopping card" or "checkout" or transaction terms such as "tax," "total," "shipping address," and "billing address,", and a credit card number or portion thereof (e.g., while the consumer is in the process of typing the credit card number); DRYER col. 5, ll. 2-10: The browser is used to navigate pages of a merchant website and to begin an on-line transaction to purchase an item. Referring to FIG. 1, according to one embodiment of a method 100 for providing real-time alerts during on-line transactions involves a plug-in monitoring the consumer's activities or associated data and at 102, determining or detecting when the consumer has begun or is in the process of an on-line transaction.);
identify a first one of the plurality of budget categories that is associated with the detected first user page action and the first entity based on identifying a category to which a product that is currently displayed on the first web page belongs (DRYER: col. 11, ll. 65-67 to col. 12, ll. 1-20: (47) Referring to FIG. 10A, the consumer 215 may have selected a budget of $200 for the month of April. The budget may be for on-line purchases made […] from a particular merchant or of a particular item or category thereof. The FMS 240 maintains a table or other data structure that is used to track consumer spending […] relative to the budget to determine if or when an alert should be issued during an on-line transaction. […]. In this example, the plug-in 213 determines the amount of the current on-line transaction, accesses the transaction/budget data in the table, and determines that if this on-line transaction is completed, the consumer 215 will go over budget by $45 such that an alert 214 should be generated and displayed to the consumer 214 before the transaction is completed; col. 7, ll. 38-44: (26) At 304, the consumer 215 selects or confirms alert criteria or rules 247 including, but not limited to, a budget for purchases made from merchant 225, a budget for purchases of a particular item or category of items; col. 7, ll. 50-67: For example, the consumer 215 may have checking, savings and credit card accounts, and the account or financial summary 245 may be based particular items or categories of items (e.g., shirts and jeans are categorized as "clothing" by the FMS 240 and purchases made from a grocery store may be categorized as "food`). For example, […] the consumer 215 has budgeted to spend up to $200 per month on purchases from AMAZON.COM. It will be understood that different accounts and budgets may be utilized, and that the alert criteria or rule 247 for each of those accounts and budgets may vary. Accordingly, FIG. 4 is provided to generally illustrate how consumer 215 can select or confirm alert criteria or rules 247 for […] different merchants and items or categories thereof.);
determine that the first user page action causes a current quantity of resources associated with the first budget category of the first allocation to exceed a maximum amount defined for the budget category (DRYER: col. 11, ll. 65-67 to col. 12, ll. 1-20: (47) Referring to FIG. 10A, the consumer 215 may have selected a budget of $200 for the month of April. The budget may be for on-line purchases made […] from a particular merchant or of a particular item or category thereof. The FMS 240 maintains a table or other data structure that is used to track consumer spending […] relative to the budget to determine if or when an alert should be issued during an on-line transaction. […]. In this example, the plug-in 213 determines the amount of the current on-line transaction, accesses the transaction/budget data in the table, and determines that if this on-line transaction is completed, the consumer 215 will go over budget by $45 such that an alert 214 should be generated and displayed to the consumer 214 before the transaction is completed; col. 7, ll. 38-44: (26) At 304, the consumer 215 selects or confirms alert criteria or rules 247 including, but not limited to, a budget for purchases made from merchant 225, a budget for purchases of a particular item or category of items; col. 2, ll. 45-54: The add-on is downloadable to the first computer through a second network and being operable to detect when the consumer in the process of purchasing an item from the merchant during the on-line transaction, and communicate with a financial management system hosted by a third computer through a third network to access an account, financial summary, budget or profile of the consumer hosted by the financial management system in response to detecting the on-line transaction.; col. 3, ll. 27-36: whether an alert is generated by the add-on may depend upon whether execution of the on-line transaction to purchase the item lead to a pre-determined result such as the consumer […] exceeding a predetermined budget amount for purchases of the item, exceeding a predetermined budget amount for purchase from the merchant);
and in response to determining that the first user page action causes a current quantity of resources associated with the first budget category of the first allocation to exceed a maximum amount defined for the resource category (DRYER: col. 10, ll. 1-19: the consumer 215 specified a budget in which purchases from a particular merchant 225, such as AMAZON.COM, should not exceed $200 per month. The plug-in 213, upon determining that execution of the on-line transaction would be $300 during that same time period would trigger the plug-in 213 to generate an alert 214 to inform the consumer 215 that execution of the on-line transaction would cause the consumer 215 to go over the $200 AMAZON.COM budget. […]. It will be understood that the plug-in 213 may analyze one or multiple account attributes or budgets, and that an alert 214 may be triggered based on one or more results relative to these accounts or budgets. Thus, FIG. 4 is provided as an example of the types of data that may be transaction indicators 227 that trigger the plug-in 213 to access an account or financial summary 245 and compare alert criteria 247 with data of the on-line transaction data to determine whether to generate a real-time alert 214; col. 7, ll. 37-44: consumer 215 selects or confirms alert criteria or rules 247 including, but not limited to, a budget for purchases made from merchant 225, a budget for purchases of a particular item or category of items; figure 4: budget by category: DVD Budget: $50 per month; Clothing Budget: $100 per month and Amazon.com: $200 per month Budget, Ebay.com $50 per month Budget, Macys.com $200 per month Budget):
generate a contextual notification associated with the first allocation and the first user page action (DRYER: col. 4, ll. 60-67: providing real-time alerts to consumers during an on-line transaction, i.e., before the on-line transaction has been completed such as before a consumer clicks "Proceed to Checkout" or "Place Your Order" to purchase an item; DRYER: col. 11, ll. 65-67 to col. 12, ll. 1-20: (47) Referring to FIG. 10A, the consumer 215 may have selected a budget of $200 for the month of April. The budget may be for on-line purchases made […] from a particular merchant or of a particular item or category thereof. The FMS 240 maintains a table or other data structure that is used to track consumer spending […] relative to the budget to determine if or when an alert should be issued during an on-line transaction. […]. In this example, the plug-in 213 determines the amount of the current on-line transaction, accesses the transaction/budget data in the table, and determines that if this on-line transaction is completed, the consumer 215 will go over budget by $45 such that an alert 214 should be generated and displayed to the consumer 214 before the transaction is completed; col. 10, ll. 10-14: It will be understood that the plug-in 213 may analyze one or multiple account attributes or budgets, and that an alert 214 may be triggered based on one or more results relative to these accounts or budgets );
and provide, to the computing device for display in the browser application during the web browsing session, the generated notification as a page-specific overlay on a visible portion of the first web page (DRYER: col. 4, ll. 44-48: (11) FIG. 9A is a flow diagram of generating an active alert during an on-line transaction according to one embodiment, and FIG. 9B illustrates an example of an active alert in the form of a pop-up window with user input elements that may cause interruption to or block the pending on-line transaction; col. 11, ll. 19-28: an alert 214 may be positioned to block or certain merchant website elements or buttons. For example, the alert 214 can be positioned within a web page displayed to cover a "place order" button "proceed to checkout" button to prevent the consumer 215 from pressing the last button to complete the transaction and block or temporarily halt the transaction. An active alert 214 may even terminate the on-line transaction by closing the merchant website 221, redirect the consumer 215 to another webpage such as a home page).
DRYER does not disclose the following limitations which, HAWES, however, teaches:
that indicates historical user activity for the first web page (HAWES: col. 8, ll. 18-55: The executable file 114 displays a payment application representing a payment company web site on the web page being accessed on the client device 106 as a pop-up window, a new window, or any other visually perceptible format. In the examples shown herein, the window is a pop-up window that appears in front of the current browser window. […] In some embodiments, a payment application presents a data field such as a list of previously purchased products, […], a list of membership points, and a list of reward purchase options associated to the web page being accessed on the client device 106 and stored in a user profile. In some embodiments, a payment application presents a payment data field such as a budget amount selected by a user associated to the web page being accessed on the client device; figure 4: Pop-up window 408 at www.merchant.com)
It would have been obvious to one of ordinary skill in the art before the time of filing to combine/modify the system/method of DRYER, which discloses systems and methods of alerting consumers during real-time online transactions before the transaction is complete if the transaction would cause the consumer to go over budget (see figure 5 and col. 5, ll. 20-45) with the technique of HAWES, which relates to methods and systems for performing online payment transactions by a user from a web page being browsed by the user. in order to allow a user to stay on a web page without moving out of the web page opened on the client device or without need to log into a separate website. (HAWES column 16, lines 20-25).
Regarding claim(s) 2 and 12,
DRYER and HAWES teach the limitations of claims 1 and 11, respectively, as shown above.
DRYER further discloses:
wherein providing the generated notification to the computing device comprises transmitting an instruction to present the notification in a graphical user interface associated with the browser application on the computing device (DRYER: col. 4, ll. 19-24: embodiments for alerting consumers in real time during an on-line transaction utilizing an add-on such as a plug-in to a web browser utilized to access a merchant website and execute an on-line transaction; col. 4, ll. 49-53: an add-on or plug-in to a web browser generates an alert that is displayed to a consumer during an on-line transaction based at least in part upon a consumer budget, available credit and minimum account balances; col. 5, ll. 23-26: For example, the plug-in may generate an alert in the form of a pop-up window with a message informing the consumer about how the amount of the on-line purchase would cause the consumer to go over budget; figure 8B and col. 10, ll. 30-32: , the alert 214 generated by the plug-in 213 and displayed to the consumer 215 in the form of a pop-up window 850;.).
Regarding claim(s) 4 and 14,
DRYER and HAWES teach the limitations of claims 1 and 11, respectively, as shown above.
DRYER further discloses:
wherein detecting the first user page action comprises detecting that the user has navigated to a product page of a product offered by the first entity (DRYER: col. 6, ll. 30-34: The consumer 215 navigates website pages 221 to view merchant 225 offerings and purchase items on-line from the merchant 225.; col. 6, ll. 59-67: The plug-in 213 is operable to capture, scan or read data of website pages 221 displayed to or visited by the consumer 215 as the consumer 215 navigates the website 221 to select an item to purchase on-line.; col. 8, ll. 10-24: the plug-in 213 monitors the consumer's activities on the website 221 (e.g., by screen scraping or scanning HTML source code of the website pages 221 displayed) to determine when the consumer 215 has initiated or is in the process of an on-line purchase or transaction. For this purpose, the plug-in 213 is […] configured to monitor data of the website 221 during consumer navigation and data selection or entry to identify any on-line transaction indicators 227 or keywords, phrases and/or numbers associated with the consumer 215 being engaged in an on-line transaction; col. 2, ll. 45-49: The add-on is operable to detect when the consumer in the process of purchasing an item from the merchant during the on-line transaction; col. 2, ll. 65-67: the process comprising detecting when the consumer is in the process of purchasing an item from the merchant; col. 6, ll. 30-34: The consumer 215 navigates website pages 221 to view merchant 225 offerings and purchase items on-line from the merchant 225; col. 8, ll. 59-67: in one embodiment, scraps, scans, reads or receives data in the form of words, phrases and/or numbers related to the consumer 215 selecting items and/or deciding to purchase selected items […]. In the illustrated embodiment, transaction indicators 227 are in the form of keywords, phrases or numbers that indicate one or more of the consumer 215 has selected an item, added the item to a shopping cart, and is about to check out and purchase the item; col. 9, ll. 34-45: the plug-in 213 receives or determines on-line transaction data (e.g., […], items to be purchased, categories of items to be purchased, the merchant, the URL address of the website 221), and compares, in real time before the on-line transaction has been completed, data of the on-line transaction data or a result of executing the on-line transaction to the pre-determined alert criteria 247 (described above with reference to FIG. 4); figure 4: clothing budget, dvd budget; col. 7, ll. 50-55: may be based [on] particular items or categories of items (e.g., shirts and jeans are categorized as "clothing"; col. 11, ll. 65-67 to col. 12, ll. 1-2: the budget may be for on-line purchases made during a particular time (e.g., during April), from a particular merchant or of a particular item or category thereof.).
Regarding claim(s) 5 and 15,
DRYER and HAWES teach the limitations of claims 1 and 11, respectively, as shown above.
DRYER further discloses:
wherein the first allocation of resources comprises an indication of a defined quantity of resources associated with one or more categories of resource allocation (DRYER: col. 10, ll. 1-19: the consumer 215 specified a budget in which purchases from a particular merchant 225, such as AMAZON.COM, should not exceed $200 per month; generate an alert 214 to inform the consumer 215 that execution of the on-line transaction would cause the consumer 215 to go over the $200 AMAZON.COM budget. […]. It will be understood that the plug-in 213 may analyze one or multiple account attributes or budgets, and that an alert 214 may be triggered based on one or more results relative to these accounts or budgets. col. 7, ll. 37-44: consumer 215 selects or confirms alert criteria or rules 247 including, but not limited to, a budget for purchases made from merchant 225, a budget for purchases of a particular item or category of items; figure 4: budget by category: DVD Budget: $50 per month; Clothing Budget: $100 per month and Amazon.com: $200 per month Budget, Ebay.com $50 per month Budget, Macys.com $200 per month Budget; col. 7, ll. 50-55: may be based [on] particular items or categories of items (e.g., shirts and jeans are categorized as "clothing"; col. 11, ll. 65-67 to col. 12, ll. 1-2: the budget may be for on-line purchases made during a particular time (e.g., during April), from a particular merchant or of a particular item or category thereof.) .
Regarding claim(s) 6 and 16,
DRYER and HAWES teach the limitations of claims 1 and 11, respectively, as shown above.
DRYER further discloses:
wherein detecting the first user page action comprises detecting selection of a user interface element associated with a product that is displayed on the first web page (DRYER: col. 3, ll. 35-45: the alert is displayed in response to the consumer visiting a certain URL address of a merchant and/or at different stages of an on-line transaction, e.g., when the consumer adds an item to an electronic shopping cart of a website of the merchant, when the consumer proceeds to checkout with the item already added to an electronic shopping cart, when the consumer selects a credit card or manually enters credit card information; col. 8, ll. 63-67: transaction indicators 227 are in the form of keywords, phrases or numbers that indicate one or more of the consumer 215 has selected an item, added the item to a shopping cart, and is about to check out and purchase the item; col. 9, ll. 10-19: in the illustrated embodiment, transaction indicators 227 […] indicate that the consumer 215 has selected an item, added the item to a shopping cart, and is about to check out and complete the on-line transaction using the credit card; figure 6: “ITEM ADDED TO SHOPPING CART” triggers plug-in to determine whether to generate alert).
Regarding claim(s) 7 and 17,
DRYER and HAWES teach the limitations of claims 1 and 11, respectively, as shown above.
DRYER further discloses:
wherein the instructions, when executed, further configure the processor to obtain historical user activity data in connection with the first web page and wherein the notification is generated based at least in part on the historical user activity (DRYER: col. 6, ll. 64-67 to col. 7, ll. 1-7: The executable file 114 may learn from user browsing history, and compare URL information of the web page currently being accessed by the user with stored browsing history of the user to determine if any payment transaction information may be present on the web page currently being accessed by the user. In some embodiments, an executable file 114 may record name and location of one or more purchase keywords on the web sites accessed by the user and stored in the browsing history of the user.; col. 9, ll. 25-21: In some embodiments, the user browsing history and/or prior purchasing data at one or more business merchants determined by the executable file 114 may be formatted by the client device 106 and is transmitted to the system database; col. 8, ll. 30-40: In some embodiments, a payment application presents a data field such as a list of previously purchased products, a list of recommended products, a list of membership points, and a list of reward purchase options associated to the web page being accessed on the client device 106 and stored in a user profile. In some embodiments, a payment application presents a payment data field such as a budget amount selected by a user associated to the web page being accessed on the client device 106 and stored in a user profile.).
Regarding claim(s) 9 and 19,
DRYER and HAWES teach the limitations of claims 1 and 11, respectively, as shown above.
DRYER further discloses:
wherein the instructions, when executed, further configure the processor to determine whether the request is received from an authenticated user associated with the resource account (see, at least, DRYER: col. 7, ll. 24-32: before the consumer visits a merchant website to engage in on-line shopping, at 302, the consumer registers with or opens an account or financial summary with the [financial management system]. For this purpose, the consumer may provide information such as name, e-mail address, user ID and password and, if desired, information to allow the FMS to link to the consumer's FI accounts so that the FMS can receive data 261 such as account balances, transactions etc.; col. 11, ll. 43-49: the plug-in can be configured or programmed to interface with the [financial management system] 240 via the API 227, present fields for entry of a username and password or other login information by the consumer 215, and connect the consumer 215 to the [financial management system] 240 and pertinent account or budget for which the alert 214 was generated to allow the consumer 215 to view the account or budget; col. 10, ll. 9-23: the webserver 108 may be configured to require user authentication based upon a set of user authorization credentials […]. the webserver 108 may be configured to reference a merchant database configured to store user credentials in order to determine whether a set of entered credentials purportedly authenticating the user match an appropriate set of credentials that identify and authenticate the user. Upon authenticating the user, the webserver 108 which may be a merchant or other entity, generates content for display on a browser application 112 of the client device 106 such that the client device 106 can conduct a transaction (e.g., pay for a product or service) offered by the webserver 108.).
Regarding claim(s) 10 and 20,
DRYER and HAWES teach the limitations of claims 1 and 11, respectively, as shown above.
DRYER further discloses:
wherein generating the notification comprises: identifying a category of resource allocation that is associated with a user action on the first web page and comparing a quantity of resources associated with said category to a respective quantity defined by the first allocation (DRYER: col. 9, ll. 34-42: the plug-in receives or determines on-line transaction data (e.g., one or more of transaction amount, items to be purchased, categories of items to be purchased, the merchant, the URL address of the website), and compares, in real time before the on-line transaction has been completed, data of the on-line transaction data or a result of executing the on-line transaction to the pre-determined alert criteria 247 (described above with reference to FIG. 4); figure 4: budget settings; figure 4: budget by category: DVD Budget: $50 per month; Clothing Budget: $100 per month and Amazon.com: $200 per month Budget, Ebay.com $50 per month Budget, Macys.com $200 per month Budget; col. 11, ll. 65-67 to x: (47) Referring to FIG. 10A, the consumer 215 may have selected a budget of $200 for the month of April. The budget may be for on-line purchases made during a particular time (e.g., during April), from a particular merchant or of a particular item or category thereof. The FMS 240 maintains a table or other data structure that is used to track consumer spending (e.g., based upon checking account and/or credit card account transaction histories) relative to the budget to determine if or when an alert should be issued during an on-line transaction);
Regarding claim(s) 21 and 23,
DRYER and HAWES teach the limitations of claims 1 and 11 , respectively, as shown above.
DRYER further discloses:
wherein the instructions, when executed, further configure the processor to: in response to determining that the first user page action causes a current quantity of resources associated with a budget category of the first allocation to satisfy a defined condition, selectively disable user interface elements on the first web page that are associated with actions that affect the allocation data for the first allocation (DRYER: col. 9, ll. 34-42: the plug-in receives or determines on-line transaction data (e.g., one or more of transaction amount, items to be purchased, categories of items to be purchased, the merchant, the URL address of the website), and compares, in real time before the on-line transaction has been completed, data of the on-line transaction data or a result of executing the on-line transaction to the pre-determined alert criteria 247 (described above with reference to FIG. 4); figure 4: budget settings; figure 4: budget by category: DVD Budget: $50 per month; Clothing Budget: $100 per month and Amazon.com: $200 per month Budget, Ebay.com $50 per month Budget, Macys.com $200 per month Budget; col. 11, ll. 65-67: The FMS 240 maintains a table or other data structure that is used to track consumer spending (e.g., based upon checking account and/or credit card account transaction histories) relative to the budget to determine if or when an alert should be issued during an on-line transaction; DRYER): col. 11, ll. 15-30: it will be understood that embodiments may include different numbers of input elements 910 that provide for different functionality, that an alert 214 may be positioned to block or certain merchant website elements or buttons. For example, the alert 214 can be positioned within a web page displayed to cover a "place order" button "proceed to checkout" button to prevent the consumer 215 from pressing the last button to complete the transaction and block or temporarily halt the transaction. An active alert 214 may even terminate the on-line transaction by closing the merchant website 221, redirect the consumer 215 to another webpage such as a home page, or close the browser 22; col. 3, ll. 65-67 to col. 4, ll. 1-3: The alert may also interact with the browser and/or merchant website to disable certain features to prevent the consumer from proceeding with the on-line transaction, or redirect the consumer to another website.).
Regarding claim(s) 22 and 24,
DRYER and HAWES teach the limitations of claims 1, 11, 21, and 23 respectively, as shown above.
DRYER further discloses:
wherein the instructions, when executed, further configure the processor to: detect a second user page action for requesting the first user page action to be processed; and responsive to detecting the second user page action, enable one or more disabled user interface elements associated with the first user page action (DRYER col. 11, ll. 34-44: the active alert 214 may be a window with an alert message that allows the consumer to proceed only after the pre-determined waiting or cooling off period. For this purpose, the alert 214 may include a timer that counts down the time when the consumer 215 is allowed to continue with the on-lien transaction. Further, in another embodiment, the plug-in 213 may require the consumer 215 to log into the FMS 240 to view the account or budget that is the subject of an alert 214; figure 9B: alert overlay with “proceed” button 910a; DRYER col. 11, ll. 15-30: it will be understood that embodiments may include different numbers of input elements 910 that provide for different functionality, that an alert 214 may be positioned to block or certain merchant website elements or buttons. For example, the alert 214 can be positioned within a web page displayed to cover a "place order" button "proceed to checkout" button to prevent the consumer 215 from pressing the last button to complete the transaction and block or temporarily halt the transaction; DRYER: col. 10, ll. 30-40: the alert 214 generated by the plug-in 213 and displayed to the consumer 215 in the form of a pop-up window 850 or other message format that informs the consumer 215, for example, that this on-line transaction will cause the consumer 215 to go over the AMAZON.COM budget. […] At 804, the consumer 215 can close the alert window 850 and decide whether to proceed with or terminate the on-line transaction utilizing the user interface of the merchant website 215; figure 9B: proceed button on active alert window; col. 11, ll. 1-15: the active alert 214 includes a first input element or button 910a that can be clicked or selected to allow the consumer 215 to proceed with the on-line transaction, a second input element or button 910b that terminates the transaction, e.g., by closing the browser 212, closing the merchant webpage 221 or directing the consumer 215 from the merchant website 221 to another website such as a home page, and a third input element 910c allows allow the consumer 215 to save or bookmark the current location so that the on-line transaction can be completed at a later time. Thus, in these examples, the plug-in 213 interrupts or delays the consumer's interaction with the merchant website 221. For these purposes, the plug-in 213 may be configured to override the merchant website 221 or interface or interact with the merchant website 221 to achieve the desired interruption or restrictions placed upon the consumer 215.)
.
Response to Arguments
Applicant’s arguments filed 27 November 2025 at pages 8-10 with respect to claim(s) 1-2, 4-7, 9-12, 14-17 and 19-24 regarding the 35 U.S.C. 103 rejections in view Godsey (US 2015/0112836), Ariff (US 2010/0250420), Hao (US 11,513,753), Ur (US 2016/0171518) or Wender (US 2014/0156496) have been considered but are moot because the new ground of rejection does not rely on any reference applied in the prior rejection of record for any teaching or matter specifically challenged in the argument as each of the claims are now rejected under 35 U.S.C. 103 as being unpatentable over DRYER (US 8538827 B1 to Dryer; Trevor D. et al.) in view of HAWES (US 11288642 B1 to HAWES, B.C. et al.). Applicant's amendment necessitated the new ground(s) of rejection presented in this Office action.
Conclusion
The prior art made of record and not relied upon is considered pertinent to applicant's disclosure:
US 11222380 B2 teaches a shopping cart and dynamic budget forecast.
US 20180005241 A1 teaches an interface element for disabled and reenabled an account and automatically disabling the account under certain conditions.
Applicant's amendment necessitated the new ground(s) of rejection presented in this Office action. Accordingly, THIS ACTION IS MADE FINAL. See MPEP § 706.07(a). Applicant is reminded of the extension of time policy as set forth in 37 CFR 1.136(a).
A shortened statutory period for reply to this final action is set to expire THREE MONTHS from the mailing date of this action. In the event a first reply is filed within TWO MONTHS of the mailing date of this final action and the advisory action is not mailed until after the end of the THREE-MONTH shortened statutory period, then the shortened statutory period will expire on the date the advisory action is mailed, and any 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 BOLKO HAMERSKI whose telephone number is (571)270-7621. The examiner can normally be reached Monday-Friday 10:00 AM to 6:00 PM.
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 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.
BOLKO HAMERSKI
Examiner
Art Unit 3694
/BOLKO M HAMERSKI/ Examiner, Art Unit 3694
/BENNETT M SIGMOND/ Supervisory Patent Examiner, Art Unit 3694
Prosecution Insights