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-20 were previously pending and subject to a non-final office action mailed 11/12/2025. Claims 1-6 and 11-20 were amended; claim 10 was cancelled, and no claim was added in a reply filed 11/12/2025. Therefore claims 1-9 and 11-20 are currently pending and subject to the final office action below.
Response to Arguments
Applicant's arguments filed 11/12/2025 in regards to 101 rejection have been fully considered but they are not persuasive.
Applicant argues that the addition of “browser, browser plugin, user device, interaction activation system, primed activation data” are all additional elements that include features that recite significantly more than a judicial exception. Applicant also argues that the subject matter of the amended independent claims reflects an improvement to logistics infrastructure technology. The cooperation between the browser plugin and the interaction activation system enables delayed completion of an interaction even when the user device is deactivated. In particular, the features in the independent claims do not merely recite the concept of a solution, but rather recite with particularity how a technical solution is achieved (remarks p. 12-13). Examiner respectfully disagrees.
The claimed focus of remains delaying/scheduling performance of a checkout interactions, which fits the “commercial interactions” of the “certain methods of organizing human activity” grouping.
The Office has expressly indicated this grouping can encompass interactions between a person and a computer, not only person to person interaction (please see October 2019 Update: Subject Matter Eligibility). So, a website checkout via browser plugin does not remove it from the certain methods of organizing human activity grouping.
Applicant’s statement that using a browser plugin on a user device plus a separate “interaction system” integrates the exception is conclusory because it does not explain how the additional element apply/limit the exception in a way that imposes a meaningful limit.
Merely implementing the concept using generic computer elements and generic computer functions (prompting via GUI, receiving data, storing/using “authentication data”, accessing a website and executing the interaction) are merely “apply it” instructions which do not transform the abstract idea into an eligible application.
The assertion that the amended claims improve “logistics infrastructure technology” is not commensurate with the claim language as presented. The MPEP improvement consideration looks for an improvement to computer functioning or another technology as reflected by the claim. Here, the claim does not recite a specific improvement to browser/security/network operation. It recites the desired outcome 9delayed execution) using standard web access steps, which the MPEP describes as insufficient when the claims do not improve the functioning of the computer itself or a technical field.
Furthermore, the fact that the interaction completes while the user device is deactivated is a business/automation objective, but the claim still does not recite the particular technical mechanism that achieves it. Without such technical detail, the additional elements read as tools for executing the abstract scheduling/organizing concept rather than integrating it into a practical application.
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 § 101
35 U.S.C. 101 reads as follows:
Whoever invents or discovers any new and useful process, machine, manufacture, or composition of matter, or any new and useful improvement thereof, may obtain a patent therefor, subject to the conditions and requirements of this title.
Claims 1-20 are rejected under 35 U.S.C. 101 because the claimed invention is directed to a judicial exception (i.e., a law of nature, a natural phenomenon, or an abstract idea) without significantly more.
Claim 1 is rejected under 35 U.S.C. 101 because the claimed invention is directed to an abstract idea without significantly more. The claim recites “obtaining, in response to receiving the completion date, authentication data executable to activate the interaction with the website; obtaining an estimated duration between an activation and a completion of the interaction; determining 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; prior to the activation date, generating primed activation data that includes the activation date and the authentication data; and on the activation date, activating the primed activation data, and executing the interaction”
The limitations above, as drafted, is a process that, under its broadest reasonable interpretation, covers executing a transaction on behalf of another party which is a method of organizing a human activity. That is, the method allows for commercial or legal interactions (including agreements in the form of contracts; legal obligations; advertising, marketing or sales activities or behaviors; business relations), managing personal behavior or relationships or interactions between people (including social activities, teaching, and following rules or instructions).
This judicial exception is not integrated into a practical application. In particular, the claim recites “in response to a check-out process of a website visited by a browser of a user device, and via a browser plugin associated with an interaction activation system, causing the browser to output a prompt via a Graphical User Interface (GUI) for a completion date of an interaction associated with the check-out process”, “the browser plugin”, “GUI”, “the interaction activation system”, “providinq the primed activation data to the interaction activation system”, “the website”, “accessing the website using the authentication data” (claim 1). Each of the additional limitations is recited at a high level of generality and amounts to no more than mere instructions to apply the exception using a generic computer component. Accordingly, these additional elements do not integrate the abstract idea into a practical application because they do not impose any meaningful limits on practicing the abstract idea. The claim is directed to an abstract idea.
The claim does not include additional elements that are sufficient to amount to significantly more than the judicial exception. As discussed above with respect to integration of the abstract idea into a practical application, the additional elements, alone or in combination, are nothing more than mere instructions to apply the exception on a general-purpose computer.
Dependent claim 2 is also directed to an abstract idea without significantly more because it further narrows the abstract idea described in relation to claim 1 without successfully integrating the exception into a practical application (a user device, browser plugin and GUI are recited at a high level of recitation which amounts to mere instructions to apply the exception in a computer environment) or providing significantly more limitations.
Dependent claim 3-10 and 12-19 is also directed to an abstract idea without significantly more because it further narrows the abstract idea described in relation to claim 1/11 without successfully integrating the exception into a practical application (a user device is recited at a high level of recitation which amounts to mere instructions to apply the exception in a computer environment) or providing significantly more limitations.
Claim 11/20 is rejected under 35 U.S.C. 101 because the claimed invention is directed to an abstract idea without significantly more. The claim recites “obtaining, in response to receiving the completion date, authentication data executable to activate the interaction with the website; obtaining activation timing information, the activation timing information including interaction activation options; determining 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; prior to the activation date, generating, with reference to the activation timing information and the interaction activation options , primed activation data that includes the activation date, the interaction activation options, and the authentication data and providing the primed activation data to the interaction activation system; and on the activation date, activating the primed activation data, and executing, which reference to the authentication data, the interaction”
The limitations above, as drafted, is a process that, under its broadest reasonable interpretation, covers executing a transaction on behalf of another party which is a method of organizing a human activity. That is, the method allows for commercial or legal interactions (including agreements in the form of contracts; legal obligations; advertising, marketing or sales activities or behaviors; business relations), managing personal behavior or relationships or interactions between people (including social activities, teaching, and following rules or instructions).
This judicial exception is not integrated into a practical application. In particular, the claim recites “in response to a check-out process of a website visited by a browser of a user device, and via a browser plugin associated with an interaction activation system, causing the browser to output a prompt via a Graphical User Interface (GUI) for a completion date of an interaction associated with the check-out process”, “the browser plugin”, “GUI”, “the interaction activation system”, “the website”, “providing the primed activation data to the interaction activation system”, “accessing the website using the authentication data” (claim 11, 20), a non-transitory computer medium (claim 20). Each of the additional limitations is recited at a high level of generality and amounts to no more than mere instructions to apply the exception using a generic computer component. Accordingly, these additional elements do not integrate the abstract idea into a practical application because they do not impose any meaningful limits on practicing the abstract idea. The claim is directed to an abstract idea.
The claim does not include additional elements that are sufficient to amount to significantly more than the judicial exception. As discussed above with respect to integration of the abstract idea into a practical application, the additional elements, alone or in combination, are nothing more than mere instructions to apply the exception on a general-purpose computer.
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-9 and 11-20 is/are rejected under 35 U.S.C. 103 as being unpatentable over Raman (US 2014/0052571) in view of Zarakas (US 2018/0181956) and Compton (US 2012/0215657)
As per claim 1, Raman discloses a computer-implemented method for delayed interaction with an entity, the method comprising:
in response to a check-out process of a website visited by a browser of a user device, and via a browser associated with an interaction activation system, causing the browser to output a prompt via a Graphical User Interface (GUI) for a completion date of an interaction associated with the check-out process (fig. 5a, [0012] Described in detail herein is an apparatus and method for automatic checkout of items in a virtual shopping cart. An online marketplace receives pre-set or pre-configured automatic checkout settings from a user. The automatic checkout settings include a pre-authorization from the user/buyer to purchase items in his or her online shopping cart at a scheduled time; [0013] The following description is presented to enable any person skilled in the art to create and use a computer system configuration and related method and article of manufacture to receive auto checkout settings for a user, monitor the availability of better deals on the user's behalf up until the user's scheduled checkout time, update the user's cart in accordance with better deals found, and then automatically purchase the items in the user's cart at the user scheduled checkout time without further input from the user; [0036] Otherwise when the user is authenticated, the display/UI module 304 is configured to provide an auto checkout setting UI to the user. Such UI may be provided by the device machine 110 or 112 directly or via a server included in the networked system 102 (e.g., API server 114, web server 116, or application servers 118). FIG. 5A illustrates an example auto checkout setting UI/screen 500. The screen 500 includes the following information types: shipping address 502, payment method and authorization 504, cart purchase time 506, shipping preference 508, and substitute item preference 510. The screen 500 also includes the following respective input fields: shipping address field 503, payment field 505, cart purchase time field 507, shipping preference field 509, and substitute item preference icons 511 and 512. The screen 500 may additionally include icons and other indicators for the user to configure the auto checkout settings and/or navigate within the setting screen(s), such as "change" icons/buttons and "submit/save" icons/buttons.”)
obtaining, via the browser and in response to receiving the completion date via the GUI, authentication data executable to activate the interaction with the website (0044] FIG. 4B illustrates portions of the flow diagram 400 pertaining to populating a virtual or online shopping cart and the automatic checkout of item(s) in the cart according to some embodiments. At a block 422, the user authentication module 302 is configured to receive authentication information from a user (e.g., the same user that specified the auto checkout settings discussed with respect to FIG. 4A) at the device machine 110 or 112. Authentication information can comprise a user name and a password associated with the user. The user provided information can be checked by a server included in the networked system 102 to verify the user information.”);
prior to the activation date, generating, by the browser, primed activation data that includes the activation date and the authentication data, ([0038] The user also specifies a particular purchase time (also referred to as a scheduled checkout time, automatic checkout time, pre-determined checkout time) in the cart purchase time field 507, at which automatic checkout or purchase of item(s) in his or her virtual shopping cart is to take place. For instance, the purchase time may be set to 8 pm Pacific Standard Time (PST) Monday through Friday, 10 pm PST every Friday, 8 pm PST, or any other one time or reoccurring date and/or time. The purchase time is also referred to as a scheduled checkout time, a scheduled auto checkout time, a pre-determined checkout time, a scheduled purchase time, an automatic checkout time, an automatic purchase time, or other similar terms, 0055] Lastly, if the current time is the same as the scheduled auto checkout time at block 434 and branch 438, then the shopping cart module 308 automatically purchases all the items in the user's cart at a block 458. The user can forget about manually performing checkout of items in his/her cart. Instead, the shopping cart module 308 is configured to checkout the items in the user's cart in accordance with auto checkout settings previously configured by the user. Next at a block 460, the notification module 310 provides notification to the user that the purchase has been completed, [0057] Automatic checkout of a virtual shopping cart is beneficial for buyers that purchase items on a consistent or repeated basis. Instead of having to place multiple orders throughout the day, for example, or having to remember to return to items saved in a shopping cart and complete checkout, the user merely places desired items in his/her shopping cart and then can forget about the rest. The system automatically monitors availability and best price for each item in the cart until the pre-set purchase time.”; and
on the activation date, activating the primed activation data via the interaction activation system, which includes: accessing the website using the authentication data; and executing the interaction ([0035] Before a user (also referred to as a buyer) can purchase item(s) of interest online using automatic checkout, he or she configures auto checkout settings, as shown in FIG. 4A. At a block 402, the device machine 110 (or device machine 112) presents a login screen to receive user identity information in order to verify the user's right to configure the auto checkout settings. A server included in the networked system 102 (e.g., API server 114, web server 116, or application servers 118) can be configured to receive user authentication information from the device machine 110 or 112, such as, but not limited to, a user name and password associated with the user. A check is then performed at a block 404 against a database of user authentication information, such as database 126, by the user authentication module 302. If the inputted user authentication information does not match information stored in the database, then the user may retry entering the correct user name and password (returns to block 402)., [0038] The user also specifies a particular purchase time (also referred to as a scheduled checkout time, automatic checkout time, pre-determined checkout time) in the cart purchase time field 507, at which automatic checkout or purchase of item(s) in his or her virtual shopping cart is to take place. For instance, the purchase time may be set to 8 pm Pacific Standard Time (PST) Monday through Friday, 10 pm PST every Friday, 8 pm PST, or any other one time or reoccurring date and/or time. The purchase time is also referred to as a scheduled checkout time, a scheduled auto checkout time, a pre-determined checkout time, a scheduled purchase time, an automatic checkout time, an automatic purchase time, or other similar terms. The user may also specify shipping preferences in the shipping preference field 509, such as deciding between the cheapest shipping, fastest shipping, least number of packages, etc. In case an item added to the user's cart sells out, expires (the time to purchase ends prior to the user's set purchase time), is selling at a better price, or some other interim condition occurs after the item has been added to the cart but prior to the purchase time, the user can specify looking for substitute items by selecting the "yes" button 511 or not substituting items by selecting the "no" button 512., [0041] Once the user has specified the auto checkout settings (e.g., entered information into the fields provided in screen 500 and clicked on the "submit/save" button), the auto checkout settings module 306 is configured to check the received auto checkout settings at a block 410. Various checks may be performed such as, but not limited to, confirming that the received shipping address is a valid address, verifying the validity of the payment method and/or account, and the like. Performing one or more of the checks may require interfacing with other servers, databases, or other information sources. Checking block 410 may also be performed simultaneous with the receiving block 408--as information is received from the user, the auto checkout settings module 306 may perform checks in real- or near real-time., [0048] Once at least one item is saved in the user's cart, the networked system 102 is configured to (continually or periodically) analyze the items in the user's cart in accordance with the user-specified auto checkout settings until auto checkout is completed. At a block 434, the shopping cart module 308 is configured to determine the current time in comparison to the scheduled auto checkout time. The current time may be earlier than the scheduled auto checkout time (branch 436), the current time may be the same as the scheduled auto checkout time (branch 438), or the current time may be later than the scheduled auto checkout time (branch 440).”).
However, Raman does not disclose but Compton discloses 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 Raman, in order to select a vendor from which to purchase a customer's desired resource (please see Compton abstract).
However, Raman does not disclose but Zarakas discloses a browser plugin, associated with an interaction activation system, wherein authentication data is obtained and provided to an interaction activation system, via the browser plugin, to access a website and execute an interaction ([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, [0105] If the authentication fails, the process may end at block 614. Upon authentication of a customer based on the evaluation of the connection between the dynamic transaction card and the user device, log in credentials of the user for logging in to the browser extension associated with the checkout page, and user information stored in the digital security delivery storage, the dynamic transaction card application may transmit customer account information to the customer application, via a Bluetooth or BLE network, at block 616, which at block 618, may prompt the browser extension to populate the fields on the electronic checkout page using the user account information transmitted by the dynamic transaction card to automatically facilitate payment to the merchant system. The customer account information may be passed and queued on the backend merchant system to complete the checkout transaction. The process may end at block 620.).
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 Zarakas in the teaching of Raman, in order to facilitate multi-factor authentication and secure electronic checkout of any website (please see Zarakas abstract).
As per claim 11/20, Raman discloses a system for delayed interaction with an entity, the system comprising: a memory storing instructions; and at least one processor operatively connected to the memory and configured to execute the instructions to perform operations including:
in response to a check-out process of a website visited by a browser of a user device, and via a browser associated with an interaction activation system, causing the browser to output a prompt via a Graphical User Interface (GUI) for a completion date of an interaction associated with the check-out process (fig. 5a, [0012] Described in detail herein is an apparatus and method for automatic checkout of items in a virtual shopping cart. An online marketplace receives pre-set or pre-configured automatic checkout settings from a user. The automatic checkout settings include a pre-authorization from the user/buyer to purchase items in his or her online shopping cart at a scheduled time; [0013] The following description is presented to enable any person skilled in the art to create and use a computer system configuration and related method and article of manufacture to receive auto checkout settings for a user, monitor the availability of better deals on the user's behalf up until the user's scheduled checkout time, update the user's cart in accordance with better deals found, and then automatically purchase the items in the user's cart at the user scheduled checkout time without further input from the user; [0036] Otherwise when the user is authenticated, the display/UI module 304 is configured to provide an auto checkout setting UI to the user. Such UI may be provided by the device machine 110 or 112 directly or via a server included in the networked system 102 (e.g., API server 114, web server 116, or application servers 118). FIG. 5A illustrates an example auto checkout setting UI/screen 500. The screen 500 includes the following information types: shipping address 502, payment method and authorization 504, cart purchase time 506, shipping preference 508, and substitute item preference 510. The screen 500 also includes the following respective input fields: shipping address field 503, payment field 505, cart purchase time field 507, shipping preference field 509, and substitute item preference icons 511 and 512. The screen 500 may additionally include icons and other indicators for the user to configure the auto checkout settings and/or navigate within the setting screen(s), such as "change" icons/buttons and "submit/save" icons/buttons.”)
obtaining, via the browser and in response to receiving the completion date via the GUI, authentication data executable to activate the interaction with the website (0044] FIG. 4B illustrates portions of the flow diagram 400 pertaining to populating a virtual or online shopping cart and the automatic checkout of item(s) in the cart according to some embodiments. At a block 422, the user authentication module 302 is configured to receive authentication information from a user (e.g., the same user that specified the auto checkout settings discussed with respect to FIG. 4A) at the device machine 110 or 112. Authentication information can comprise a user name and a password associated with the user. The user provided information can be checked by a server included in the networked system 102 to verify the user information.”);
prior to the activation date, generating, by the browser and with reference to the activation timing information and the interaction activation options, primed activation data that includes the activation date, automatic checkout time, pre-determined checkout time) in the cart purchase time field 507, at which automatic checkout or purchase of item(s) in his or her virtual shopping cart is to take place. For instance, the purchase time may be set to 8 pm Pacific Standard Time (PST) Monday through Friday, 10 pm PST every Friday, 8 pm PST, or any other one time or reoccurring date and/or time. The purchase time is also referred to as a scheduled checkout time, a scheduled auto checkout time, a pre-determined checkout time, a scheduled purchase time, an automatic checkout time, an automatic purchase time, or other similar terms, 0055] Lastly, if the current time is the same as the scheduled auto checkout time at block 434 and branch 438, then the shopping cart module 308 automatically purchases all the items in the user's cart at a block 458. The user can forget about manually performing checkout of items in his/her cart. Instead, the shopping cart module 308 is configured to checkout the items in the user's cart in accordance with auto checkout settings previously configured by the user. Next at a block 460, the notification module 310 provides notification to the user that the purchase has been completed, [0057] Automatic checkout of a virtual shopping cart is beneficial for buyers that purchase items on a consistent or repeated basis. Instead of having to place multiple orders throughout the day, for example, or having to remember to return to items saved in a shopping cart and complete checkout, the user merely places desired items in his/her shopping cart and then can forget about the rest. The system automatically monitors availability and best price for each item in the cart until the pre-set purchase time.”; and
on the activation date, activating the primed activation data via the interaction activation system, which includes: accessing the website using the authentication data; and executing, with reference to the authentication data, the interaction with the website on the activation date ([0035] Before a user (also referred to as a buyer) can purchase item(s) of interest online using automatic checkout, he or she configures auto checkout settings, as shown in FIG. 4A. At a block 402, the device machine 110 (or device machine 112) presents a login screen to receive user identity information in order to verify the user's right to configure the auto checkout settings. A server included in the networked system 102 (e.g., API server 114, web server 116, or application servers 118) can be configured to receive user authentication information from the device machine 110 or 112, such as, but not limited to, a user name and password associated with the user. A check is then performed at a block 404 against a database of user authentication information, such as database 126, by the user authentication module 302. If the inputted user authentication information does not match information stored in the database, then the user may retry entering the correct user name and password (returns to block 402)., [0038] The user also specifies a particular purchase time (also referred to as a scheduled checkout time, automatic checkout time, pre-determined checkout time) in the cart purchase time field 507, at which automatic checkout or purchase of item(s) in his or her virtual shopping cart is to take place. For instance, the purchase time may be set to 8 pm Pacific Standard Time (PST) Monday through Friday, 10 pm PST every Friday, 8 pm PST, or any other one time or reoccurring date and/or time. The purchase time is also referred to as a scheduled checkout time, a scheduled auto checkout time, a pre-determined checkout time, a scheduled purchase time, an automatic checkout time, an automatic purchase time, or other similar terms. The user may also specify shipping preferences in the shipping preference field 509, such as deciding between the cheapest shipping, fastest shipping, least number of packages, etc. In case an item added to the user's cart sells out, expires (the time to purchase ends prior to the user's set purchase time), is selling at a better price, or some other interim condition occurs after the item has been added to the cart but prior to the purchase time, the user can specify looking for substitute items by selecting the "yes" button 511 or not substituting items by selecting the "no" button 512., [0041] Once the user has specified the auto checkout settings (e.g., entered information into the fields provided in screen 500 and clicked on the "submit/save" button), the auto checkout settings module 306 is configured to check the received auto checkout settings at a block 410. Various checks may be performed such as, but not limited to, confirming that the received shipping address is a valid address, verifying the validity of the payment method and/or account, and the like. Performing one or more of the checks may require interfacing with other servers, databases, or other information sources. Checking block 410 may also be performed simultaneous with the receiving block 408--as information is received from the user, the auto checkout settings module 306 may perform checks in real- or near real-time., [0048] Once at least one item is saved in the user's cart, the networked system 102 is configured to (continually or periodically) analyze the items in the user's cart in accordance with the user-specified auto checkout settings until auto checkout is completed. At a block 434, the shopping cart module 308 is configured to determine the current time in comparison to the scheduled auto checkout time. The current time may be earlier than the scheduled auto checkout time (branch 436), the current time may be the same as the scheduled auto checkout time (branch 438), or the current time may be later than the scheduled auto checkout time (branch 440).”).
However, Raman does not disclose but Compton discloses obtaining, via the interaction activation system and from the website, activation timing information, the activation timing information including interaction activation options ([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.”);
determining, via the interaction activation system and based on the activation timing information, 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 Raman, in order to select a vendor from which to purchase a customer's desired resource (please see Compton abstract).
However, Raman does not disclose but Zarakas discloses a browser plugin, associated with an interaction activation system, wherein authentication data is obtained and provided to an interaction activation system, via the browser plugin, to access a website and execute an interaction ([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, [0105] If the authentication fails, the process may end at block 614. Upon authentication of a customer based on the evaluation of the connection between the dynamic transaction card and the user device, log in credentials of the user for logging in to the browser extension associated with the checkout page, and user information stored in the digital security delivery storage, the dynamic transaction card application may transmit customer account information to the customer application, via a Bluetooth or BLE network, at block 616, which at block 618, may prompt the browser extension to populate the fields on the electronic checkout page using the user account information transmitted by the dynamic transaction card to automatically facilitate payment to the merchant system. The customer account information may be passed and queued on the backend merchant system to complete the checkout transaction. The process may end at block 620.).
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 Zarakas in the teaching of Raman, in order to facilitate multi-factor authentication and secure electronic checkout of any website (please see Zarakas abstract).
As per claim 2, Raman does not disclose but Zarakas 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 ([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., 0093] At block 514, the customer may be authenticated by utilizing multi-factor authentication based on the pairing of the dynamic transaction card and the successful log in of the customer to the browser extension. This multi-factor authentication may provide computer access control in which the user is only granted access to complete the secure online checkout after successfully presenting these pieces of evidence to an authentication system. For example, the customer may be authenticated based on evaluation of the connection between the dynamic transaction card and the user device, log in credentials of the customer for logging in to the browser extension associated with the electronic checkout page and user information stored in a digital security database. The dynamic transaction card may communicate directly with the browser extension through a wireless connection, which may include Bluetooth or BLE. For example a user device, which may include Bluetooth or BLE may be utilized to facilitate this direct communication.) (please see claim 1 rejection for combination rationale).
As per claim 3, Compton discloses receiving additional activation timing information from a third-party entity, wherein the activation date is further based on the additional activation timing information (paragraph 59-60, the shipping duration from the shipping entity is received, “[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.”) (please see claim 1 rejection for combination rationale).
As per claim 4, Compton discloses wherein the additional activation timing information includes regular duration data for interactions having a threshold similarity with the interaction. (paragraph 60, the shipping duration from the shipping entity is about shipping duration for previous purchases) (please see claim 1 rejection for combination rationale).
As per claim 5/15, Raman 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, Raman 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, Raman 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, Raman 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, Raman 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, Raman 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).
As per claim 13, Raman does not disclose but Compton discloses wherein the processor is configured to execute the instructions to perform additional operations including receiving additional activation timing information from a third-party entity (paragraph 47, 60) (please see claim 1 rejection for combination rationale).
As per claim 14, Raman does not disclose but Compton discloses wherein the additional activation timing information includes regular duration data for interactions having a threshold similarity with the interaction. (paragraph 47, 60) (please see claim 1 rejection for combination rationale).
Conclusion
THIS ACTION IS MADE FINAL. Applicant is reminded of the extension of time policy as set forth in 37 CFR 1.136(a).
A shortened statutory period for reply to this final action is set to expire THREE MONTHS from the mailing date of this action. In the event a first reply is filed within TWO MONTHS of the mailing date of this final action and the advisory action is not mailed until after the end of the THREE-MONTH shortened statutory period, then the shortened statutory period will expire on the date the advisory action is mailed, and any nonprovisional extension fee (37 CFR 1.17(a)) pursuant to 37 CFR 1.136(a) will be calculated from the mailing date of the advisory action. In no event, however, will the statutory period for reply expire later than SIX MONTHS from the mailing date of this final action.
Any inquiry concerning this communication or earlier communications from the examiner should be directed to 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, Resha Desai can be reached at (571) 270-7792. 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 3628