Prosecution Insights
Last updated: October 02, 2026
Application No. 18/516,151

SYSTEMS AND METHODS FOR AUTONOMOUS INTERACTIONS WITH DELAYED ACTIVATION

Non-Final OA §103§112
Filed
Nov 21, 2023
Examiner
ZEROUAL, OMAR
Art Unit
3628
Tech Center
3600 — Transportation & Electronic Commerce
Assignee
Capital One Services LLC
OA Round
3 (Non-Final)
34%
Grant Probability
At Risk
3-4
OA Rounds
7m
Est. Remaining
73%
With Interview

Examiner Intelligence

Grants only 34% of cases
34%
Career Allowance Rate
124 granted / 370 resolved
-18.5% vs TC avg
Strong +40% interview lift
Without
With
+39.7%
Interview Lift
resolved cases with interview
Typical timeline
3y 5m
Avg Prosecution
35 currently pending
Career history
411
Total Applications
across all art units

Statute-Specific Performance

§101
38.2%
-1.8% vs TC avg
§103
35.6%
-4.4% vs TC avg
§102
4.9%
-35.1% vs TC avg
§112
20.6%
-19.4% vs TC avg
Black line = Tech Center average estimate • Based on career data from 370 resolved cases

Office Action

§103 §112
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 the Claims Claims 1-9 and 11-20 were previously pending and subject to a final office action mailed 02/18/2026. Claims 1-5, 7, 11, 13-14, and 20 were amended; no claim was cancelled, or added in a reply filed 05/11/2026. Therefore claims 1-9 and 11-20 are currently pending and subject to non-final office action below. Response to Arguments Applicant’s arguments, see remarks p. 12-14, filed 05/11/2026, with respect to 101 argument have been fully considered and are persuasive. The 101 rejection of claims 1-9 and 11-20 has been withdrawn. Applicant’s arguments with respect to 103 rejection 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. Claim Rejections - 35 USC § 112 The following is a quotation of the first paragraph of 35 U.S.C. 112(a): (a) IN GENERAL.—The specification shall contain a written description of the invention, and of the manner and process of making and using it, in such full, clear, concise, and exact terms as to enable any person skilled in the art to which it pertains, or with which it is most nearly connected, to make and use the same, and shall set forth the best mode contemplated by the inventor or joint inventor of carrying out the invention. The following is a quotation of the first paragraph of pre-AIA 35 U.S.C. 112: The specification shall contain a written description of the invention, and of the manner and process of making and using it, in such full, clear, concise, and exact terms as to enable any person skilled in the art to which it pertains, or with which it is most nearly connected, to make and use the same, and shall set forth the best mode contemplated by the inventor of carrying out his invention. Claims 1-9 and 11-20 are rejected under 35 U.S.C. 112(a) or 35 U.S.C. 112 (pre-AIA ), first paragraph, as failing to comply with the written description requirement. The claim(s) contains subject matter which was not described in the specification in such a way as to reasonably convey to one skilled in the relevant art that the inventor or a joint inventor, or for applications subject to pre-AIA 35 U.S.C. 112, the inventor(s), at the time the application was filed, had possession of the claimed invention. Claim 1 recites “: monitoring, via a browser plugin associated with an interaction activation system, navigation events of a browser operating on a user device to detect a check-out process of a website visited by the browser; in response to detecting the check-out process, causing, via the browser plugin, the browser to output a prompt via a Graphical User Interface (GUI) for a completion date…”. The limitation is new matter because Examiner is unable to find support for it in the specification. The closest support appears in paragraph 31. Paragraph 31 states “interaction activation system 106 may be integrated with or interact with entity 112, in some cases as a browser plugin”.. “during checkout for a user 102 with entity 112, interaction activation system 106 may be activated on the website 116 and ask user 102 for a preferred interaction completion (e.g., delivery) date”. Thus, the specification expressly supports use of a browser plugin and expressly supports presenting a request for a preferred completion date during checkout. Paragraph 17 similarly describes that “during completion of the interaction, the user may be given an option (e.g., shown via a user interface) to select a desired delivery window…” and then describes determining activation timing from various information after receiving the relevant inputs. However, neither paragraph 17 or 31, nor any other portion of the specification describes the browser plugin monitoring navigation events of the browser for the purposes of determining that a checkout process has been reached. The disclosed embodiment begins with the condition that the user is already “during checkout” and states that the interaction activation system may then be activated. It does not describe “observing browser navigation events; monitoring URL changes, page transitions, or browser state; determining from such navigation events that a checkout process is occurring; or triggering the GUI prompt in response to the browser plugin detecting checkout”. Accordingly, the disclosed statement that the system may operate “during checkout” does not reasonably convey possession of the claimed mechanism of monitoring browser navigation events to detect checkout and responsively causing the browser to output the completion date prompt. The generic definition in paragraph 16 also does not cure this deficiency. Paragraph 16 explains generally that phrases such as “if it is determined” may, depending on context, encompass “upon detecting” or “in response to detecting” a stated condition. That paragraph defines terminology where a detection condition is otherwise disclosed; it does not itself disclose monitoring browser navigation events or detecting a checkout process. Accordingly, there is no adequate written description support for “: monitoring, via a browser plugin associated with an interaction activation system, navigation events of a browser operating on a user device to detect a check-out process of a website visited by the browser; in response to detecting the check-out process, causing, via the browser plugin, the browser to output a prompt via a Graphical User Interface (GUI) for a completion date” Claim 1 further recites “receiving, via the browser plugin, the completion date from a user interacting with the GUI, obtaining, via the browser plugin and in response to receiving the completion date, authentication data from the user”. The limitation is new matter because Examiner is unable to find support for it in the specification. The specification undoubtably discloses both a completion date and authentication data. The issue is the newly claimed responsive relationship between the two operations. As noted above, paragraph 31 states that the interaction activation system may ask the user for a preferred completion date. Paragraph 32 states “interaction activation system 106 may further receive authentication data executable to activate the interaction with the entity”, “interaction activation system 106 may receive a username and password associate with user 102, allowing interaction activation system 106 to independently access entity 112 on a future date…” and “in some cases user 102 may provide authentication data (e.g. username and password to access entity 112 directly to interaction activation system 106”. The summary also discloses receiving data containing both a “completion date for the interaction” and “authentication data executable to activate the interaction with the entity”. These passages above establish possession of “receiving a completion date; receiving authentication data; receiving username/password information from the user; and using that authentication data for later independent access”. They do not, however, disclose that authentication data is obtained “in response to receiving the completion date”. Paragraph 31-32 describe separate functionality sequentially in the written description. Paragraph 32 states merely that the system “may further receive” authentication data. It does not state that receipt of the completion date triggers, causes, or otherwise serves as the condition for obtaining the authentication data. Similarly, the summary’s disclosure of completion date data and authentication data in the same received data packet does not disclose the claimed sequence in which the completion date is first received and, in response thereto, authentication data is subsequently obtained. Therefore, no adequate written description exists to support the causal relationship (e.g. in response to relationship) of “obtaining, via the browser plugin and in response to receive the completion date, authentication data from the user”. Claim 1 recites “prior to the activation date, generating, by the browser plugin, primed activation data that is specific to the interaction and includes the activation date and the authentication data, and transmitting the primed activation data to the interaction activation system” The limitation is new matter because Examiner is unable to find support for in the specification. The specification contains extensive disclosure of primed activation data, but the closest disclosure assigns its generation to the interaction activation system, rather than disclosing the presently claimed plugin to system generation and transmission arrangement. Paragraph 35 states “prior to the estimated activation date, interaction activation system 106 may generate primed activation data that includes the estimated activation date for the interaction”, “the primed activation data may include any data needed to activate (e.g., execute) the interaction with the entity on the estimated activation date” and “for example, the primed activation data may include authentication data to provide access to entity 112”. Paragraph 35 then states that, on the activation date: “interaction activation system 106 may activate the primed activation data”. Paragraph 48 also states “at step 206, the method 200 includes, prior to an estimated activation date, generating primed activation data that includes the estimated activation date for the interaction…” and explains that the primed data may be generated with reference to activation timing information and interaction activation options. The originally published claim 1 likewise assigned generation to “ the at least one processor” rather than to a browser plugin that then sends the generated primed activation data to a separate interaction activation system. Paragraph 31, as discussed above, does not disclose that interaction activation system 106 may, in some cases, be integrated with or interact with entity 112 as a browser plugin. Paragraph 43-44 generally disclose that components may communicate across network 110 and that components depicted separately may, in some embodiments, be integrated with or incorporated into other components. Those general architecture statement do not, however, describe the specific amended architecture. There are essentially two possibilities disclosed by paragraph 31: first, interaction activation system 106 itself may be implemented/integrated as a browser plugin. Under that embodiment, paragraph 35 can support the browser plugin implementation of system 106 generating primed activation data. But there is then no disclosed transmission of that primed activation data from the browser plugin “to the interaction activation system” because the plugin embodiment is the interaction activation system itself. Second, the browser plugin may be regarded as something interacting with or associated with interaction activation system 106. Under that interpretation, the specification does not disclose that the browser plugin component itself generates the primed activation data and then transmits that generated primed activation data to system 106. Paragraph 35 instead expressly identifies interaction activation system 106 as the component that generates the data. The generic disclose that system components may communicate or be distributed does not reasonably convey possession of the particular data flow now claimed: browser plugin generated primed activation data including activation date/authentication data and then transmits that primed activation data to the interaction activation system. Therefore, there is no adequate written description support for the limitation. Claims 11 and 20 are rejected for similar reasons as above. Claims 2-9 and 12-19 are also rejected for failing to cure the deficiencies above. Claim Rejections - 35 USC § 103 The following is a quotation of 35 U.S.C. 103 which forms the basis for all obviousness rejections set forth in this Office action: A patent for a claimed invention may not be obtained, notwithstanding that the claimed invention is not identically disclosed as set forth in section 102, if the differences between the claimed invention and the prior art are such that the claimed invention as a whole would have been obvious before the effective filing date of the claimed invention to a person having ordinary skill in the art to which the claimed invention pertains. Patentability shall not be negated by the manner in which the invention was made. 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. This application currently names joint inventors. In considering patentability of the claims the examiner presumes that the subject matter of the various claims was commonly owned as of the effective filing date of the claimed invention(s) absent any evidence to the contrary. Applicant is advised of the obligation under 37 CFR 1.56 to point out the inventor and effective filing dates of each claim that was not commonly owned as of the effective filing date of the later invention in order for the examiner to consider the applicability of 35 U.S.C. 102(b)(2)(C) for any potential 35 U.S.C. 102(a)(2) prior art against the later invention. Claim(s) 1-3, 5-9, 11-13, and 15-21 is/are rejected under 35 U.S.C. 103 as being unpatentable over Hogg (US 2021/0326818) in view of Compton (US 2012/0215657) and Nelson (US 20150294262) As per claim 1/11/20, Hogg discloses a computer-implemented method for delayed interaction with an entity, the method comprising: monitoring, via a browser plugin associated with an interaction activation system, navigation events of a browser operating on a user device to detect a check-out process of a website visited by the browser ([0090] During operation of the system of FIG. 10, the web browser 1000 launches the extension 1004 in response to the user having navigated to an e-commerce website 1002 with which the extension 1004 interoperates, as described previously, and as depicted in operation 900 of FIG. 9A. In the wake of having been launched, the extension 1004 monitors the user's actions and navigational path through the e-commerce website 1002, and detects events in which the user adds products or services to website's 1002 digital shopping cart, using techniques parallel to those described previously (operation 902). In response to having detected an item having been added to the digital shopping cart, the extension 1004 scrapes information from the active page (such as a product detail page), assembles it into a product object, and adds it to a product object array, again, in a manner parallel to that which was described previously. According to some embodiments, this aspect of operation 902 is optional, and the various product objects corresponding to the products in the digital shopping cart are constructed and populated into the product object array at a later step, such as during an operation performed when the entry page of the digital shopping cart is active (see, for example, operation 910—discussed below). In the event that the informational content available to be scraped by the extension 1004 at such later point is the same as—or lesser than only in unimportant ways—that which is available if scraping were to be performed in operation 902, then the scraping operation of 902 would be largely redundant of a scraping operation performed at a later stage, and it may be omitted from the process in favor of such later scraping process. [0091] In operation 904, the URL bar of the web browser 1000 is examined to determine whether it contains the URL corresponding to the entry point page of the digital shopping cart of the particular e-commerce web site 1002 currently interoperating with the extension 1004 (details pertaining to this inquiry were presented previously). If not, then operational control returns to operation 902, and the actions and navigational path of the user are monitored until such time as the user navigates to the entry point page of the shopping cart. Upon entering the shopping cart, control is passed to operation 906, whereupon the extension 1004 adds a user-input element, such as a button, to the entry point page of the digital shopping cart in order to permit the user to elect to acquire the goods and services in the shopping via the alternative transactional arrangement, if they are of a suitable nature. Addition of such a user-input element was discussed previously.); in response to detecting the check-out process, causing, via the browser plugin, the browser to output a prompt via a Graphical User Interface (GUI) receiving, via the browser plugin, arranged to initiate creation of a payment card number that is usable by the user on the website to conduct a payment operation pertaining to the aforementioned at least one good.), However, Hogg obtaining, via the browser plugin prior to the activation date, generating, by the browser plugin, primed activation data that is specific to the interaction and includes wake of having scraped the product data (operation 412), the extension 306 constructs a product object corresponding to the product that is the subject of the product detail page 506. Thus, a first unit of scraped data (example: product name) is assigned to a first attribute of the aforementioned product object, and a second unit of scraped data (example: product SKU) is assigned to a second attribute of the aforementioned product object, and so on. The product object may also include other data obtained from the web browser 304 as opposed to having been scraped from the e-commerce website 302, such as the particular URL corresponding to the product detail page of the product described by the product object. After having constructed the product object, the product object is added to a product object array that is stored in local memory in the browser, such as by use of the sessionStorage API (operation 414). Thus, there is one product object stored in the product object array for each product that was added to the cart by virtue of the user having clicked the “Add to Cart” button 508 from a product detail page….[0053]… thus, in operation 422 the extension 306 adjusts the product object array to reflect the items actually contained in the digital shopping cart: it removes any product objects that are in the array but not present in the dataset generated from scraping the cart (operation 418), and adds product objects to the array for any objects present in the dataset generated from operation 418 but not already present in the product object array… [0054] In the wake of having performed adjustment operation 422, the extension 306 presents the user with a login screen, depicted in FIG. 5G. Continuing on with the exemplary use case, the user enters his or her login credentials into the screen of FIG. 5G and clicks the “Login” button 517. In operation 426, the extension 306 responds by accessing a single-sign-on service 314 executing on the backend computing platform 308 and exposed to a network such as the Internet via an API (example: the service 314 may be a web service exposed via a RESTful API, for example). (The backend platform 308 exposes other services 316-334, discussed below, which may also be configured as web services exposed via RESTful APIs, or otherwise made available for access by the extension 306 via a network connection.) The extension 306 sends the login credentials entered by the user to the aforementioned service 314, which responds with: (1) an indication of success or failure of the login attempt; and, (2) assuming a successful login attempt, a global unique identification number (GUID) identifying the user to the various data systems making up the backend computing platform 308. (While operation 426 is being performed, the “Just a Moment” screen of FIG. 5H is presented to the user; the screen of FIG. 5H continues to be presented to the user during the execution of operations 428-436… [0071] Next, in operation 4990, the extension 306 posts a message to a messaging queue 702 of an RPA system executing on the backend computing platform (depicted in FIG. 7A). (The messaging queue 702 and FIG. 7A are discussed in more detail herein, below.) The message contains the information necessary for the RPA system to navigate the e-commerce website to conduct a purchase of the eligible products and to navigate the checkout process so as to pay for those products and have them delivered to the user's residence. According to some embodiments, the dataset communicated to the queue by the extension 306 includes the retailer ID, a lease ID, and the product object array. By virtue of having posted the aforementioned message to the messaging queue, the extension 306 has initiated the aforementioned RPA process. (According to some embodiments, the “Just a Moment” screen of FIG. 5H is presented by the extension during the execution of operation 4990.)); on the activation date, and independently of the user device, autonomously activating the primed activation data via the interaction activation system, which includes: the interaction activation system accessing the website using [the] authentication data; and the interaction activation system executing the interaction ([0071] Next, in operation 4990, the extension 306 posts a message to a messaging queue 702 of an RPA system executing on the backend computing platform (depicted in FIG. 7A). (The messaging queue 702 and FIG. 7A are discussed in more detail herein, below.) The message contains the information necessary for the RPA system to navigate the e-commerce website to conduct a purchase of the eligible products and to navigate the checkout process so as to pay for those products and have them delivered to the user's residence. According to some embodiments, the dataset communicated to the queue by the extension 306 includes the retailer ID, a lease ID, and the product object array. By virtue of having posted the aforementioned message to the messaging queue, the extension 306 has initiated the aforementioned RPA process. (According to some embodiments, the “Just a Moment” screen of FIG. 5H is presented by the extension during the execution of operation 4990.) [0072] In the wake of operation 4990, operational control is passed to operation 4992, in which the extension 306 constructs and presents the confirmation screen, as depicted in FIG. 55. The confirmation screen includes a statement confirming to the user that his or her order is being processed (i.e., the aforementioned RPA process has been initiated and is underway), and also presents the lease ID (example: 810708) and a reiteration of the user's remaining open-to-lease line, which was presented previously to the user on the screen depicted in FIG. 5I. The screen contains a “Continue Shopping” button 544. The user clicks the button 544 (operation 4994), and the extension 306 responds by removing the eligible items from the digital shopping cart. Thus, the digital shopping cart native to the e-commerce website 302 now contains only those items that could not be acquired via the sought-after transaction (i.e., the lease-to-own arrangement, according to this example). Finally, the extension 306 closes, removing its user interface from the web browser 304 (operation 4998), thus revealing the shopping cart, and thereby giving the user the opportunity to purchase the remaining items in the shopping cart via the native checkout process. [0078] Discussion now turns to an embodiment of the aforementioned RPA process for purchasing the eligible goods from the e-commerce website in the wake of having completed the sought-after transaction. FIG. 7A depicts an embodiment of a computerized system 700 for performing such a process. The system includes a messaging queue 702 that receives the messages sent from the extension to initiate execution of the process, such as may occur during execution of operation 4490 (FIG. 4G). Introduction of a new message into the queue 702 generates an event that is responded to by an event-drive process 704, which, according to some embodiments, is dynamically allocated computing resources and executed in response to the occurrence of such an event. The process extracts the aforementioned message from the queue and enters into a database 706 as a new record. A computerized robot (“bot”) 708 responds to the creation of such a new record by reading the record, and performing an RPA process to purchase the goods described by the record. According to some embodiments, the bot may be embodied as a web browser automation system, such as Selenium web browser automation tool, which performs actions within web browsers without necessitation of human effort, i.e., “robotically.” Certain embodiments of the process performed by the bot are depicted in FIGS. 7B and 7C…. [0079] Initially, the bot responds to the acquisition of a new record from the database 706 by examining the record to determine from which particular e-commerce website the products within the record are to be purchased. The bot 708 launches a (headless, according to some embodiments) instance of a web browser, navigates to the particular e-commerce site from which the products that are the subject of the record are to be bought, and logs into a user account pre-established in the name of the transaction company (lease-to-own company, in the context of the present example) on the aforementioned e-commerce site (operation 710). However, Hogg does not disclose but Compton discloses Requesting a desired completion timing ([0063] At a step 306, the host computing device 106 sends a transmission to the customer to request customer input, such as sending a transmission to the customer computing device 116 (e.g., a laptop computer used in the step 206) or a second of the customer computing devices 116 of the customer (e.g., a cell phone not used in the step 206). The transmission includes a query to determine if the customer wishes to conduct a repeat purchase of the resource found in the second search 512. For example, the host computing device 106 sends a SMS message or notification to the customer computing device 116 indicating: "Ms. Mary Smith, your next order of Kotex Maxi Pads 24 pack is due to arrive in 5 days. This automatic and/or autonomic purchase will be at the guaranteed lowest current price on the web and requires no action on your part, unless you wish to SPEED UP, SLOW DOWN, SUSPEND, OR CANCEL the delivery." In certain embodiments, the "SPEED UP" and "SLOW DOWN" "SUSPEND," or "CANCEL" options of the message are displayed in drop down boxes or entry fields where new delivery dates can be selected if desired. This helps Mary Smith from overstocking resources or feeling locked into future purchases. Mary Smith has the option to conduct the second purchase. Alternatively, Mary Smith has the option to expedite the delivery of the one or more resource (deliver the resource on July 1st rather than July 5th in the above example) or delay the delivery (deliver the resource on July 10th rather than July 5th in the above example). Alternatively, Mary Smith has the option to cancel the delivery of the resource found in the second search and conduct a third search for the resource for delivery at the specified delivery schedule (e.g., Jul. 5, 2009). Alternatively, Mary Smith has the option to cancel the second delivery all together (no delivery of the resource until the subsequent 30 days after Jul. 5, 2009). Other changes to the specified delivery schedule are also contemplated.) obtaining, via the interaction activation system, an estimated duration between an activation and a completion of the interaction ([0059] In certain embodiments, the host computing device 106 calculates a date to conduct a second search 612 for vendors selling the research based on the preselected search window 606, a date of the first purchase 608, an estimated or actual first delivery of the resource 610, and the customer's specified delivery schedule 602. To illustrate, a customer requests monthly delivery of a resource (step 206). The host computing device 106 selects a first vendor from which to buy the resource (step 210) and conducts a first purchase 608 of the resource (step 216). For example, if the first purchase 608 date is Jun. 1, 2009, the host computing device 106 searches the a non-transitory computer readable medium 111 to determine the first vendor's estimated shipping duration, such as 5 days from the date of the first purchase 608. Therefore, a first estimated delivery of the resource 610 is estimated to occur on Jun. 5, 2009, in this example.”); determining, via the interaction activation system and based on the estimated duration, an activation date for the interaction predicted to cause the completion of the interaction to coincide with the completion date ( [0059] In certain embodiments, the host computing device 106 calculates a date to conduct a second search 612 for vendors selling the research based on the preselected search window 606, a date of the first purchase 608, an estimated or actual first delivery of the resource 610, and the customer's specified delivery schedule 602. To illustrate, a customer requests monthly delivery of a resource (step 206). The host computing device 106 selects a first vendor from which to buy the resource (step 210) and conducts a first purchase 608 of the resource (step 216). For example, if the first purchase 608 date is Jun. 1, 2009, the host computing device 106 searches the a non-transitory computer readable medium 111 to determine the first vendor's estimated shipping duration, such as 5 days from the date of the first purchase 608. Therefore, a first estimated delivery of the resource 610 is estimated to occur on Jun. 5, 2009, in this example.; [0061] Given that the customer's specified delivery schedule 602 is every 30 days in the above example, the host computing device 106 determines that an estimated second delivery of the resource 614 should be on Jul. 5, 2009 (e.g., 30 days from Jun. 5, 2009). Assuming a 10 day preselected search window 506, the host computing device 106 schedules to automatically and/or autonomically conduct the second search 612 between Jun. 25, 2009 and Jul. 5, 2009. In another implementation the preselected search window 606 has an upper and a lower limit. For example, if the search window 606 is a period of time between 10 to 5 days prior to the estimated second delivery of the resource 514, the search is done in time to accommodate a five day delivery period for the second delivery 514.”). Therefore, it would have been obvious to one of ordinary skill in the art at the time of the invention to include the limitation above as taught by Compton in the teaching of Hogg, in order to select a vendor from which to purchase a customer's desired resource (please see Compton abstract). However, Hogg in view of Compton does not disclose but Nelson discloses Selecting delivery time frames ([0091] In another embodiment, the carrier system 100 and/or the retailer system/third party system 125 can determine/identify or identify multiple expected, estimated, confirmed, and/or guaranteed pickup or delivery times (including pickup or delivery windows). In an online environment, this may allow for customers to select a specific delivery time or delivery time window before an item is purchased, as part of the checkout process, after an item has been received by the carrier for transport, and/or the like. ) In response to receiving the completion date, receiving authentication data ([0097]… Additionally or alternatively, in some embodiments, location may be requested. FIG. 20 shows a display 2000 that may be presented by the retailer system/third party system 125 to a customer (e.g., operating a customer computing entity 110/120) displaying a pop-up window requesting customer location information/data (e.g., a zip code). In some embodiments, the retailer system may determine the customer's location before, during, or subsequent to selection of item, placement of an item in a shopping cart, a checkout process, shipping of the item or the like in order provide potential and/or available delivery windows to the customer. Whereas, in other embodiments, location may be determined later. Moreover, in some embodiments, retailer system/third party system 125 may include means, such as processor 205 or the like, for determining the authentication of a customer, which is discussed below, for providing one or more additional benefits to those consumers that are determined to be authenticated and, in some embodiments, those consumers who elect to receive/select delivery windows, or in some embodiments, access points, and are temporarily enrolled in the authentication process….[0110]… FIG. 23B shows display 2305 which may be displayed upon reception of user selection and be configured to receive the retailer login information/data (e.g., username and password) to access the carrier system 100. FIG. 23C then shows a display 2310 which may be displayed upon reception of the user's retailer login information.) the authentication data enabling the interaction activation system to independently access the website and complete the interaction with the website ([0068] In one embodiment, the carrier system 100 and/or retailer system/third party system 125 may create a customer profile for the customer via the enrollment/registration process. Accordingly, the carrier system 100 and/or retailer system/third party system 125 may create, store, and/or have access to various customer profiles (e.g., via database) and/or information/data associated with the customer profiles. In addition to at least the information/data described above, a customer profile may include one or more corresponding usernames and passwords (e.g., credentials) for accessing accounts associated with the carrier and/or retailer. For example, the carrier system 100 can store and use a customer's retailer credentials for access to the carrier system 100, and/or the retailer system/third party system 125 can store and use a customer's carrier credentials for access to the retailer system/third party system 125.) Therefore, it would have been obvious to one of ordinary skill in the art at the time of the invention to include the limitation above as taught by Nelson in the teaching of Hogg in view of Compton, in order to select a vendor from which to purchase a customer's desired resource (please see Compton abstract). As per claim 2/21, Hogg discloses wherein the browser plugin receives at least one user parameter for the interaction via input to the GUI from a user device associated with the user (paragraph 60-61, “[0060] In the wake of receiving the response from the transaction-terms service 324, a transaction details screen, such as the one depicted in FIG. 5J, is constructed and presented by the extension (operation 444). The transaction details screen presents: (1) the email address to which communications pertaining to the leased products will be sent—obtained during operation 434; (2) the phone number that the lease-to-own company would call in connection with any issues related to the contemplated lease-to-own arrangement—obtained during operation 434; (3) the address to which the leased items will be shipped—obtained during operation 434; (4) a pair of toggle buttons 521 and 524 by which the user may indicate his selection of either companion service—toggled on during the initial presentation of the transaction details screen, according to some embodiments; (5) an estimate of the monthly (or other short term lease renewal basis) lease payment that the user would owe, if the user elects to renew the lease and companion services each term, assuming the companion service selection indicated by the toggle buttons −$160.27=$133.89 monthly cost for the sofa+$12.28 monthly for the limited damage waiver+$1.11 monthly tax on the limited damage waiver+$11.92 monthly for the benefits package+$1.07 monthly tax for the benefits package). The aforementioned estimated monthly payment is adjusted by the extension 306 as the user toggles the toggle buttons 521 or 524 (operations 446 and 448). For example, if the user were to de-select toggle button 524 (related to the benefits package), then the extension 306 would re-calculate the estimated monthly payment as: $147.28=$133.89 monthly cost for the sofa+$12.28 monthly for the limited damage waiver+$1.11 monthly tax on the limited damage waiver. The transaction details screen of FIG. 5J also contains a user input element 526 by which the user may indicate his next pay date. The user's pay date may be used to determine the particular date within each month upon which the user's payments will be due. This date will be stated in a transaction agreement (example: lease-to-own agreement)—discussed herein, below.) As per claim 3/13, Hogg does not disclose but Compton discloses receiving, by the interaction activation system, additional activation timing information from a third-party entity, the additional activation timing information derived from at least one of historical data analysis, routing algorithms, or geospatial analysis, (paragraph 34, 47, 59-61, the shipping duration from the shipping entity is received, “[0034] In certain embodiments, the resource is purchased from the vendor that is offering the resource for the lowest price (e.g., that may or may not include the shipping costs, handling costs, or taxes). Consequently, the host computing device is configured to select a vendor to purchase one or more resources, and/or calculate and coordinate: the scheduled repetitive searches, the specified delivery schedule, and the vendor's estimated shipping duration such that the resources are replenished, for example, without the customer running out of the resource. ..[0047] At a step 202 of method 200 in FIG. 2, the host computing device 106 optionally receives from each of a plurality of vendors, information about respective resources that the corresponding vendor is offering for sale. The information includes, for example, a description of each resource offered for sale, such as a Stock Keeping Unit (SKU) number, Universal Product Code (UPC), a brand name, a manufacturer name, a make or model of the resource, a quality of the resource (e.g., "made in America," "green product," "locally grown," or other descriptor), a quantity of units within a package of the resource (e.g., 10 pounds, 6 cans), reviews about a quality of the resource (e.g. top rated cereal), a shipping cost for the resource, a shipping cost for a group of resources, or an estimated shipping duration (e.g. 5 business days for ground transportation). At a step 204, the host computing device 106 optionally stores the received information about the respective resources at the non-transitory computer medium 111. ..[0059] In certain embodiments, the host computing device 106 calculates a date to conduct a second search 612 for vendors selling the research based on the preselected search window 606, a date of the first purchase 608, an estimated or actual first delivery of the resource 610, and the customer's specified delivery schedule 602. To illustrate, a customer requests monthly delivery of a resource (step 206). The host computing device 106 selects a first vendor from which to buy the resource (step 210) and conducts a first purchase 608 of the resource (step 216). For example, if the first purchase 608 date is Jun. 1, 2009, the host computing device 106 searches a non-transitory computer readable medium 111 to determine the first vendor's estimated shipping duration, such as 5 days from the date of the first purchase 608. Therefore, a first estimated delivery of the resource 610 is estimated to occur on Jun. 5, 2009, in this example…. [0061] Given that the customer's specified delivery schedule 602 is every 30 days in the above example, the host computing device 106 determines that an estimated second delivery of the resource 614 should be on Jul. 5, 2009 (e.g., 30 days from Jun. 5, 2009). Assuming a 10 day preselected search window 506, the host computing device 106 schedules to automatically and/or autonomically conduct the second search 612 between Jun. 25, 2009 and Jul. 5, 2009. In another implementation the preselected search window 606 has an upper and a lower limit. For example, if the search window 606 is a period of time between 10 to 5 days prior to the estimated second delivery of the resource 514, the search is done in time to accommodate a five day delivery period for the second delivery 514.”) (please see claim 1 rejection for combination rationale). As per claim 5/15, Hogg does not disclose but Compton discloses prior to executing the interaction on the activation date, receiving a confirmation from a user device associated with the user. (paragraph 33, “In certain embodiments, the host computing device queries the customer to confirm the purchase, to determine whether to place the order, delay the order, expedite the order, or to forgo the order.”). However, Raman in view of Compton does not disclose but Zarakas discloses a browser plugin ([0090] FIG. 5 illustrates an example method of utilizing a wireless pairing of a dynamic transaction card and a user device application to facilitate multi-factor authentication and a secure online checkout. The method 500 may start at block 502. At block 504, a customer completing an online shopping transaction may log in to a browser extension associated with an electronic checkout page. A browser extension may include a plug-in that may extend the functionality of the web browser of the merchant online shopping website, which may be utilized to facilitate a secure checkout) (please see claim 1 rejection for combination rationale). As per claim 6/16, Hogg does not disclose but Compton discloses prior to executing the interaction on the activation date, providing an indication to the user device of an alteration to the interaction; and receiving an additional confirmation from the user device related to the alteration of the interaction (paragraph 33, 74, “In certain embodiments, the host computing device queries the customer to confirm the purchase, to determine whether to place the order, delay the order, expedite the order, or to forgo the order.”, “At a step 804, the user gets the electronic notification and responds by selecting to accept delivery, speed up delivery, slow down or suspend the delivery.”) However, Raman in view of Compton does not disclose but Zarakas discloses a browser plugin ([0090] FIG. 5 illustrates an example method of utilizing a wireless pairing of a dynamic transaction card and a user device application to facilitate multi-factor authentication and a secure online checkout. The method 500 may start at block 502. At block 504, a customer completing an online shopping transaction may log in to a browser extension associated with an electronic checkout page. A browser extension may include a plug-in that may extend the functionality of the web browser of the merchant online shopping website, which may be utilized to facilitate a secure checkout) (please see claim 1 rejection for combination rationale) As per claim 7/17, Hogg does not disclose but Compton discloses storing information related to the interaction such that the interaction is repeatable at a future date designated by a user device associated with the user (paragraph 49, 50-51) (please see claim 1 rejection for combination rationale). As per claim 8/18, Hogg does not disclose but Compton discloses repeating completion of the interaction on a regular basis (paragraph 49, 50-51) (please see claim 1 rejection for combination rationale). As per claim 9/19, Hogg does not disclose but Compton discloses holding resources necessary for completion of the interaction in a virtual account; and expending the resources during execution of the interaction (paragraph 48, 73, “an account identifier of the customer usable to make a future purchase (e.g., checking account number, a credit account number, a charge card account number, an electronic wire transfer account number”) (please see claim 1 rejection for combination rationale). As per claim 12, Hogg does not disclose but Compton discloses wherein the activation timing information includes an estimated duration between the activation date for the interaction and the completion date for the interaction (paragraph 47, 60) (please see claim 1 rejection for combination rationale). Claim(s) 4 and 14 is/are rejected under 35 U.S.C. 103 as being unpatentable over Hogg (US 2021/0326818) in view of Compton (US 2012/0215657) and Nelson (US 20150294262), as disclosed in the rejection of claim 3, in further view of McAlister (US 2022/0114543). As per claim 4/14, Hogg in view of Compton does not disclose but McAlister discloses wherein the additional activation timing information derived from historical data analysis includes regular duration data for interactions having a threshold similarity with the interaction, the regular duration data based on analysis of previous deliveries including at least one of shipment origins, destinations, distances, transit times, or delivery dates. ([0096] In a second implementation, time-in-transit data for a plurality of historical shipment records is represented as a mean number of days in transit and a corresponding standard deviation value that is computed from the days in transit data identified by each historical shipment record….[0084] In some implementations of the twelfth example of an aggregation rule, data for a historical shipment data record whose shipping lane overlaps with a shipping lane segment is aggregated with other historical shipment data records (whose shipping lanes overlap with the segment) if a distance of the shipping lane segment is greater than a threshold percentage of the total shipping lane distance for the shipping lane of the historical shipment data record. For example, if the shipping lane distance for a historical shipment is 100 miles, the threshold percentage is 90%, and the overlapping shipping lane segment distance is 95 miles, then data for the shipment is aggregated with data for other historical shipments whose shipping lanes overlap with the segment. In variants, the threshold percentage can be selected based on one or more constraints. Such constraints can include at least one of: a minimum shipment threshold requirement amount (which specifies a minimum number of shipments that should be aggregated); and a minimum threshold percentage. In variants, constraints can be adjusted as needed based on the availability of data matching each constraint. In an example, the threshold percentage is 90%, however, any suitable threshold percentage can be selected as the threshold percentage. For example, a lower threshold percentage results in more historical shipment data records being aggregated (thereby resulting in more statistically significant time-in-transit data), but at the cost of the time-in-transit data accurately representing the actual shipping lanes of the historical shipments. [0085] However, data for historical shipment data records can be aggregated in any suitable manner and in accordance with any suitable process or rule. [0114] In some implementations, the number of historical shipments used to generate time-in-transit data for a shipping lane defined at a finer level of granularity (e.g., zips to zips) is less than the number of historical shipments used to generate time-in-transit data for a shipping lane defined at a coarser level of granularity (e.g., zip3 to zone). In some implementations, the shipping lane selection rule includes a shipment threshold requirement that specifies a minimum number of historical shipments (shipment threshold requirement amount) for a shipping lane. In some implementations, selecting a matching shipping lane based on a selection rule (S813) includes: identifying each matching shipping lane associated with a number of historical shipments greater than the minimum number of historical shipments specified by the threshold requirement, and selecting the identified shipping lane (that satisfies the threshold requirement) that is defined at the finest level of granularity. In some implementations, a shipping lane that is defined at the finest level of granularity is the shipping lane that is the closest match to the origin and destination of the shipment request.” McAlister teaches analyzing historical deliveries selected according to threshold/route similarity criteria and generating representative transit duration information for the similar historical shipments. It further teaches historical shipment data involving shipment origin and destination and computing distances between historical shipment endpoints and relevant lane segments, together with historical time in transit information.) Therefore, it would have been obvious to one of ordinary skill in the art at the time of the invention to include the limitation above as taught by McAlister in the teaching of Hogg in view of Compton, in order to satisfy a shipping customer's time in transit requirements, even though the shipping carrier does not guarantee a time in transit that satisfies the customer's requirement (please see McAlister, paragraph 15). Conclusion Any inquiry concerning this communication or earlier communications from the examiner should be directed to OMAR ZEROUAL whose telephone number is (571)272-7255. The examiner can normally be reached Flex schedule. 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, Lynda Jasmin can be reached at (571) 272-6782. 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. OMAR . ZEROUAL Examiner Art Unit 3628 /OMAR ZEROUAL/Primary Examiner, Art Unit 3629
Read full office action

Prosecution Timeline

Show 1 earlier event
Aug 12, 2025
Non-Final Rejection mailed — §103, §112
Nov 12, 2025
Response Filed
Feb 18, 2026
Final Rejection mailed — §103, §112
Apr 30, 2026
Examiner Interview Summary
Apr 30, 2026
Applicant Interview (Telephonic)
May 11, 2026
Request for Continued Examination
May 13, 2026
Response after Non-Final Action
Sep 22, 2026
Non-Final Rejection mailed — §103, §112 (current)

Precedent Cases

Applications granted by this same examiner with similar technology

Patent 12731442
PLATFORM FOR VEHICLE BASED TOLLING AND TELEMATICS
1y 8m to grant Granted Sep 08, 2026
Patent 12718182
STREAM BASED FRAMEWORK FOR ASSOCIATING LOGISTICS DOCUMENTS USING CORRELATION FEATURES
3y 5m to grant Granted Aug 25, 2026
Patent 12711535
SYSTEMS AND METHODS FOR PERSONALIZING BUNDLES BASED ON PERSONAS
2y 0m to grant Granted Aug 18, 2026
Patent 12682369
SYSTEM AND METHOD FOR TRADING PRIVACY INFORMATION
3y 4m to grant Granted Jul 14, 2026
Patent 12675764
DELIVERY SYSTEM, DELIVERY METHOD, AND NON-TRANSITORY COMPUTER-READABLE STORAGE MEDIUM
4y 1m to grant Granted Jul 07, 2026
Study what changed to get past this examiner. Based on 5 most recent grants.

Strategy Recommendation AI-generated — please review before filing

Get a prosecution strategy drawn from examiner precedents, rejection analysis, and claim mapping.
Typically takes 5-10 seconds — AI-generated, attorney review required before filing

Prosecution Projections

3-4
Expected OA Rounds
34%
Grant Probability
73%
With Interview (+39.7%)
3y 5m (~7m remaining)
Median Time to Grant
High
PTA Risk
Based on 370 resolved cases by this examiner. Grant probability derived from career allowance rate.

Sign in with your work email

Enter your email to receive a magic link. No password needed.

Personal email addresses (Gmail, Yahoo, etc.) are not accepted.

Free tier: 3 strategy analyses per month