DETAILED ACTION
Status of Claims
The present application, filed on or after March 16, 2013, is being examined under the first inventor to file provisions of the AIA .
This action is in reply to the application filed on 02/28/2025.
Claims 1-20 are currently pending and have been examined.
Information Disclosure Statement
The information disclosure Statement(s) filed 06/25/2025 have been considered. Initialed copies of the Form 1449 are enclosed herewith.
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 towards non-statutory subject matter as claims 1-8 and 16-20 are directed towards software per se and claims 9-15 are directed towards an abstract idea without significantly more, and fails step 2 of the analysis because the focus of the claims is not on the devices themselves or a practical application but rather directed towards an abstract idea, the analysis is provided below.
Step 1 (Statutory Categories) – Claims 9-15 pass claims pass step 1 of the subject matter eligibility test (see MPEP 2106(III)) as the claims are directed towards a method and non-transitory computer-readable medium. Claims 1-8, and 16-20, however fail step 1 of the test and are rejected as software per se. Claims 1-8, and 16-20 are directed towards 2 systems which comprise servers. As per MPEP 2106.03, Non-limiting examples of claims that are not directed to any of the statutory categories include: Products that do not have a physical or tangible form, such as information (often referred to as "data per se") or a computer program per se (often referred to as "software per se") when claimed as a product without any structural recitations. Claims are directed to an Apparatus must be distinguished from the prior art in terms of structure rather than function, In re Danly 263 F.2d 844, 847, 120 USPQ 582, 531 (CCPA 1959). A claim containing a “recitation with respect to the manner in which a claimed apparatus is intended to be employed does not differentiate the claimed apparatus from a prior art apparatus” if the prior art apparatus teaches all the structural limitations of the claim. Ex parte Masham, 2 USPQ2d 1657 (bd Pat. App. & Inter. 1987). However, in the instant application the aforementioned claims do not positively recite any elements that necessarily constitute a system or apparatus, such as computer hardware. Rather, claims 1-8, and 16-20 are directed towards a system comprising servers, and are directed towards the functions which servers perform without positively reciting any non-tangible components. A person having ordinary skill in the art would recognize that a server could be interpreted as a software program, additionally [0028-0029] does not explicitly define the server to physical embodiments, as [0029] defines that servers may implemented as physical computers and virtual computers, i.e. software per se. That is to say, the server and functions are not claimed as embodied in a non-transitory computer-readable media and are functional descriptive material per se and are considered to be software per se, which is not statutory (see MPEP 2106.03) and therefor claims 1-8, and 16-20 fail step 1 of the test and stand rejected as software per se.
Step 2A – Prong One (Do the claims recite an abstract idea?) -
For the sake of compact prosecution, all the claims will be analyzed under Step 2A Prong 2.
Claim 1, while varying in scope in the different embodiments of the independent claims, recites an idea, in part, by:
provide a payment information form;
process payment information to determine a primary transaction status; and
provide a confirmation, wherein the payment information form to:
accept payment information from a user;
convey the payment information to the first set of one or more servers; and
store the payment information in a temporary storage location, and
wherein the via the confirmation:
obtain a user decision regarding a secondary transaction;
send, without requiring completion of another payment information form, the payment information to a second set of one or more servers for a second website if the user decision is affirmative; and
delete the payment information from the temporary storage location before, or upon, closure of the confirmation page or the subsequent page.
Claim 9, while varying in scope in the different embodiments of the independent claims, recites an idea, in part, by:
rendering a payment information form;
accepting via the payment information form payment information from a user;
conveying the payment information;
storing the payment information in a temporary, local storage location;
displaying a confirmation;
obtaining a user decision regarding a purchase transaction;
sending, without requiring completion of a payment information form, the payment information if the user decision is affirmative; and
deleting the payment information from the temporary storage location before, or upon, closure of the confirmation page or the subsequent page.
Claim 13, while varying in scope in the different embodiments of the independent claims, recites an idea, in part, by:
obtain a user decision regarding a secondary transaction;
send, if the user decision is affirmative and without requiring completion of a payment information form associated with a second website, payment information previously stored by the internet browser in a temporary, local storage location in response to a primary transaction with the first website; and
delete the payment information from the temporary storage location before, or upon, closure of the confirmation page.
Claim 16, while varying in scope in the different embodiments of the independent claims, recites an idea, in part, by:
store, in a temporary storage location, encrypted payment information encrypted using a public key associated with a second website,
obtain a user decision regarding a secondary transaction;
send the encrypted payment information from the temporary storage location to a second set of one or more servers for a second website if the user decision is affirmative; and
delete the payment information from the temporary storage location before, or upon, closure of the subsequent page.
The steps recited above under Step 2A Prong One of the analysis under the broadest reasonable interpretation covers commercial or legal interactions (including sales activities or behaviors; business relations) but for the recitation of generic computer components. That is other than reciting a non-transitory computer-readable medium, a processor, an internet browser, a client device, a page for a first website, a second website, a confirmation page/subsequent page, a first set of set of one or more servers for the first website, and a second set of one or more servers for the second website nothing in the claim elements are directed towards anything other than commercial or legal interactions for allowing a user to complete secondary transactions without re-enter their payment information. If a claim limitation, under its broadest reasonable interpretation, covers commercial or legal interactions, then it falls within the “Certain Methods of Organizing Human Activities” groupings of abstract ideas. Accordingly, the claims recite an abstract idea.
Step 2A – Prong Two (Does the claim recite additional elements that integrate the judicial exception into a practical application?) - This judicial exception is not integrated into a practical application. In particular, the claims only recite the additional elements of a non-transitory computer-readable medium, a processor, an internet browser, a client device, a page for a first website, a second website, a confirmation page/subsequent page, a first set of set of one or more servers for the first website, and a second set of one or more servers for the second website. The non-transitory computer-readable medium, processor, internet browser, client device, page for a first website, second website, confirmation page/subsequent page, first set of set of one or more servers for the first website, and second set of one or more servers for the second website are recited at a high level of generality such that it amounts to no more than mere instructions to apply the exception using generic computer components and limits the judicial exception to the particular environment of computers. Mere instructions to apply the judicial exception using generic computer components and limiting the judicial exception to a particular environment are not indicative of a practical application (see MPEP 20106.05(f) and MPEP 20106.05(h)). As MPEP 2106.05(f) Use of a computer or other machinery in its ordinary capacity for economic or other tasks (e.g., to receive, store, or transmit data) or simply adding a general purpose computer or computer components after the fact to an abstract idea (e.g., a fundamental economic practice or mathematical equation) does not integrate a judicial exception into a practical application or provide significantly more. See Affinity Labs v. DirecTV, 838 F.3d 1253, 1262, 120 USPQ2d 1201, 1207 (Fed. Cir. 2016) (cellular telephone);. 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 claims are directed towards an abstract idea.
Step 2B (Does the claim recite additional elements that amount to significantly more than the judicial exception?) - The claims do not include additional elements that are sufficient to amount to significantly more than the judicial exception because, as discussed above, with respect to integration of the abstract idea into a practical application, using the additional elements of a page for a first website, a second website, a confirmation page/subsequent page, a first set of set of one or more servers for the first website, and a second set of one or more servers for the second website to perform the steps recited in Step 2A Prong One of the analysis amounts to no more than mere instructions to apply the exception using generic computer components and limits the judicial exception to the particular environment. Mere instructions to apply an exception using generic computer components and limiting the judicial exception to a particular environment does not provide an inventive concept. The additional elements have been considered separately, and as an ordered combination, and do not add significantly more (also known as an “inventive concept”) to the judicial exception. Further, MPEP 2106.05(d)(ii) provides that receiving and transmitting data over a network (see buySAFE, Inc. v. Google, Inc., 765 F.3d 1350, 1355, 112 USPQ2d 1093, 1096 (Fed. Cir. 2014) (computer receives and sends information over a network), and Electronic recordkeeping, Alice Corp. Pty. Ltd. v. CLS Bank Int'l, 573 U.S. 208, 224-26, 110 USPQ2d 1984-1985 (2014) (see also creating and maintaining "shadow accounts", "create electronic records, track multiple transactions, and issue simultaneous instructions" (, Alice Corp. Pty. Ltd. v. CLS Bank Int'l 573 U.S. at 224-26, 110 USPQ2d at 1984-85); are well-understood routine and conventional, similar to the instant application claims which recites and sending and receiving data over network, and storing and retrieving information from the network database. See also Remotely accessing user-specific information through a mobile interface and pointers to retrieve the information without any description of how the mobile interface and pointers accomplish the result of retrieving previously inaccessible information, Intellectual Ventures v. Erie Indem. Co., 850 F.3d 1315, 1331, 121 USPQ2d 1928, 1939 (Fed. Cir. 2017); and Requiring the use of software to tailor information and provide it to the user on a generic computer, Intellectual Ventures I LLC v. Capital One Bank (USA), 792 F.3d 1363, 1370-71, 115 USPQ2d 1636, 1642 (Fed. Cir. 2015); in which the Courts found the claims to ineligible, akin to the instant application with respect to rendering the payment form and storing and conveying the payment information merely invoking the generic computer components as tools to do. Further, the displaying and rendering steps falls to transform the claims into patent eligible material, as this is part of the field of use and technical environment in which the abstract idea is being implement and does not result in an improvement to additional elements (see MPEP 2106.05(h) Electric Power Group court decision). The claims are not patent eligible.
The dependent claims have been given the full analysis including analyzing the additional limitations both individually and in combination as a whole. For instance, 2-8, 10-12, 14-5, and 17-20 are all steps that fall within the “Certain Methods of Organizing Human Activities” groupings of abstract ideas, generally linking the use of the judicial exemption to a particular technical computing environment and further limiting the abstract idea similar to as discussed above. The Dependent claims when analyzed both individually and in combination are also held to be patent ineligible under 35 U.S.C. 101 for the same reasoning as above and the additional recited limitations fail to establish that the claims are not directed to an abstract idea. The additional limitations of the dependent claims when considered individually and as an ordered combination do not amount to significantly more than the abstract idea.
Claim Rejections - 35 USC § 103
In the event the determination of the status of the application as subject to AIA 35 U.S.C. 102 and 103 (or as subject to pre-AIA 35 U.S.C. 102 and 103) is incorrect, any correction of the statutory basis for the rejection will not be considered a new ground of rejection if the prior art relied upon, and the rationale supporting the rejection, would be the same under either status.
The following is a quotation of 35 U.S.C. 103 which forms the basis for all obviousness rejections set forth in this Office action:
A patent for a claimed invention may not be obtained, notwithstanding that the claimed invention is not identically disclosed as set forth in section 102, if the differences between the claimed invention and the prior art are such that the claimed invention as a whole would have been obvious before the effective filing date of the claimed invention to a person having ordinary skill in the art to which the claimed invention pertains. Patentability shall not be negated by the manner in which the invention was made.
The factual inquiries set forth in Graham v. John Deere Co., 383 U.S. 1, 148 USPQ 459 (1966), that are applied for establishing a background for determining obviousness under 35 U.S.C. 103 are summarized as follows:
1. Determining the scope and contents of the prior art.
2. Ascertaining the differences between the prior art and the claims at issue.
3. Resolving the level of ordinary skill in the pertinent art.
4. Considering objective evidence present in the application indicating obviousness or nonobviousness.
Claims 1, 4, 6, 9, 12, and 13 are rejected under 35 U.S.C. 103 as being unpatentable over Isaacson, et al. (US Patent Application Publication 20230351474), “Isaacson” in view of Frederick, et al. (US Patent 11,023,960 B1), “Frederick”.
As per claim 1, Isaacson:
A payment system that comprises: [0011]
a first set of one or more servers for a first website, the first set of servers collectively configured to: [0153], [0236] It is presumed, such as in the case of Amazon or an auction web site, that when the user navigates to one-search.com, that user information, debit/credit card information, address information, etc., is stored in a user profile and available, as in the case of a registered user at Amazon.com. For example, as part of a registration or enrollment process, the user can establish an account with one-search.com, and authenticate or provide credentials to link the one-search.com account with accounts at other websites… In this example user interface, the user enters the text “iPhone 5S” into a unified input field 902. The browser communicates the text to a one-search server that returns navigation destinations.
provide a payment information form page; [0266] Once the user clicks enter, the system can transition immediately to the new URL or destination site as if the user had clicked and navigated through a series of pages in a shopping cart, loading each page in turn and entering data automatically on the browser side, or the system can communicate with the target website directly to accomplish the various sub-tasks associated with selecting an item, adding that item to a cart, entering or selecting shipping and payment information, and so forth, leading up to the final stage where the user simply clicks “submit order.” The browser API could be used to manage the payment process
process payment information to determine a primary transaction status; and [0267-0268] The system can analyze the input from the user into the first input field to determine whether the user desires to perform a search or to make a purchase to yield a determination (1404). The determination can indicate that a confidence level that the user desires to make a purchase has passed a threshold… If the determination indicates that the user desires to make a purchase, and without any other input from the user other than the input and/or perhaps the enter key, the system can automatically transition the user interface to a second website in which a second user interface has a second input field (1406). The system can prepopulate the second input field associated with the second website with the input (1408). The system can preprocess the second website using the input in the second input field such that the user is in a state after the automatic transitioning where a product associated with the input can be processed for purchase and delivery via a one-click action from the user (1410). The system can, for example, transmit user data from one of the first web site and/or a browser via an API to the second website, or automatically navigate through a shopping cart model of the second website to yield the state where the product can be processed for purchase and delivery via the one-click action.
provide a confirmation page, wherein the payment information form page configures a client device to: [0254] The method includes presenting a user input field that processes input according to a default destination site (1260), receiving user input in the input field (1262), based on the user input, automatically presenting an object indicating that if the user enters the user input in the input field, that the user will transition to a second destination site that differs from the default destination site (1264), and receiving a confirmation from the user to process the user input (1266). The method further includes, based on the confirmation, transitioning the user to the second destination site (1268). The confirmation can be the user hitting an enter button, providing some other type of input indicating that the user input should be processed or pressing the enter key on a keyboard. The order of items in a menu can also dynamically adjust as the user types such that the default site changes while typing.
accept payment information from a user; [0271] the method includes presenting a purchase-related search result for the product, wherein the purchase-related search result is configured such that when a user interacts with the purchase-related search result and confirms the payment associated with the product in the purchase-related search result, the generalized search entity initiates a purchasing process for the product.
convey the payment information to the first set of one or more servers; and [0268] The system can automatically transition the user interface to the second website by replacing the first website in the uniform resource locator field of a browser with the second website in the uniform resource locator field of the browser. The system can further prepare a third website having a third input field preprocessed using the input, wherein the user can provide a switching input to indicate that the third website should be presented rather than the second website. In another example, the first site can process a payment for the item and coordinate with the second site to provide the necessary information for delivery of the item.
store the payment information in a temporary storage location, and [0368-0371] In one aspect, the payment information (credit card, address, expiration date, name, etc.) is communicated to the kiosk browser such that the proper memory is populated with the information…The kiosk browser, following the final confirmation, deletes from its memory the payment information for Mary and can confirm the deletion
wherein the confirmation page, or a subsequent page reachable via the confirmation page, configures the client device to: obtain a user decision regarding a secondary transaction; [0036], [0673] The plurality of search results an include a first product advertisement configured according to a first type of advertisement, wherein the first product advertisement, when selected by the user, is configured to enable a purchase of the first product from the first merchant site, wherein the purchase of the first product is initiated by the generalized search entity using payment data for the user that is stored with the generalized search entity, a network based entity or on a user device. The operations can include (3) in response to the user input, presenting, as part of the plurality of search results, a second product advertisement configured according to a second type of advertisement, wherein the second product advertisement, when selected by the user, is configured to transition the user to a second merchant site associated with the second product advertisement such that the user interacts with the second merchant site to manage a payment for a second product… The difference is that the second site is already communicating with the browser for the payment process of the second product. The user, however, has navigated away from the first site, so a communication back to the first site must identify the product as well as providing payment and/or delivery data to the first site for “reminding” the first site of the previously searched-for product. Processing the payment of both the first product and the second product further can include transmitting, through the browser application programming interface a package of data which enables the first site to process the first purchase of the first product. The package of data can include payment data for the first site to process the payment for the first product and address information associated with the user for the first site to deliver the product. The method can also include receiving a confirmation from the user of the purchase of both the first product and the second product utilizing a same set of object interactions used for purchasing one product via the browser payment interface. In other words, since the user is already in the browser interface for processing the payment for the second product, the method can include utilizing the same “one-click” plus perhaps one fingerprint recognition or CVC code entry, or whatever few steps are utilized for the purchase of the second product, to also process the payment for the first product
send, without requiring completion of another payment information form, the payment information to a second set of one or more servers for a second website if the user decision is affirmative; and [0036] The difference is that the second site is already communicating with the browser for the payment process of the second product. The user, however, has navigated away from the first site, so a communication back to the first site must identify the product as well as providing payment and/or delivery data to the first site for “reminding” the first site of the previously searched-for product. Processing the payment of both the first product and the second product further can include transmitting, through the browser application programming interface a package of data which enables the first site to process the first purchase of the first product. The package of data can include payment data for the first site to process the payment for the first product and address information associated with the user for the first site to deliver the product. The method can also include receiving a confirmation from the user of the purchase of both the first product and the second product utilizing a same set of object interactions used for purchasing one product via the browser payment interface. In other words, since the user is already in the browser interface for processing the payment for the second product, the method can include utilizing the same “one-click” plus perhaps one fingerprint recognition or CVC code entry, or whatever few steps are utilized for the purchase of the second product, to also process the payment for the first product.
Isaacson does not expressly disclose the following, Frederick, however discloses:
delete the payment information from the temporary storage location before, or upon, closure of the confirmation page or the subsequent page. Col. 9 lines 57-67, col. 16 lines 1-5 Referring to FIG. 11, optionally, a confirmation window 52 may be generated and displayed to the user… Preferably, any action that aborts a process, closes a window, terminates the browser session, or otherwise discontinues the process of interacting with the system will trigger a cleanup script that clears all browser cookies generated by the system… If the buyer's computer is a registered computer registered with CMS 106 it may be provided with a token. A token is a cookie stored in buyer's computer 102 that identifies the buyer to CMS 106 and enables the buyer to buy through the AJAX interface.
It would have been obvious to one having ordinary skill in the art at the time the invention was filed to modify Isaacson with the ability to clear the browsing data and cookies when the user terminates a browser session as taught by Frederick, doing so further allows the user’s token to cleared upon exiting a session (Col. 9 lines 57-67, col. 16 lines 1-5).
As per claim 4, Isaacson discloses:
wherein the client device employs an internet browser to render the payment information form page and the confirmation page. [0153], [0236], [0254], [0275] It is presumed, such as in the case of Amazon or an auction web site, that when the user navigates to one-search.com, that user information, debit/credit card information, address information, etc., is stored in a user profile and available, as in the case of a registered user at Amazon.com. For example, as part of a registration or enrollment process, the user can establish an account with one-search.com, and authenticate or provide credentials to link the one-search.com account with accounts at other websites… In this example user interface, the user enters the text “iPhone 5S” into a unified input field 902. The browser communicates the text to a one-search server that returns navigation destinations… The method includes presenting a user input field that processes input according to a default destination site (1260), receiving user input in the input field (1262), based on the user input, automatically presenting an object indicating that if the user enters the user input in the input field, that the user will transition to a second destination site that differs from the default destination site (1264), and receiving a confirmation from the user to process the user input (1266). The method further includes, based on the confirmation, transitioning the user to the second destination site (1268). The confirmation can be the user hitting an enter button, providing some other type of input indicating that the user input should be processed or pressing the enter key on a keyboard. The order of items in a menu can also dynamically adjust as the user types such that the default site changes while typing… The services provided by the API 1502 can be accessible from a web server serving pages to web browsers or other web clients, an application for mobile devices, or from a web browser, such as through a JavaScript call to the API 150
As per claim 6, Isaacson discloses:
wherein the temporary storage location is an HTTP cookie associated with the first website. [0155], [0371] The one-search.com website can inspect and use browser cookies from other sites to glean user data, glean search history, or any other information stored in or made available via cookies. User payment and address information, as well as any other type of data, can be stored in a browser or capable of being accessible by a browser. The system can, for example, use a session cookie to determine that a user has or had an active session with a particular website, and can use information in the session cookie to construct a URL for a one-click page to execute a purchase in response to user provided input… The kiosk browser, following the final confirmation, deletes from its memory the payment information for Mary and can confirm the deletion.
As per claim 9, Issacson discloses:
A method for facilitating secure payments, the method comprising: [0021]
rendering a payment information form page for a first website; [0153], [0236] It is presumed, such as in the case of Amazon or an auction web site, that when the user navigates to one-search.com, that user information, debit/credit card information, address information, etc., is stored in a user profile and available, as in the case of a registered user at Amazon.com. For example, as part of a registration or enrollment process, the user can establish an account with one-search.com, and authenticate or provide credentials to link the one-search.com account with accounts at other websites… In this example user interface, the user enters the text “iPhone 5S” into a unified input field 902. The browser communicates the text to a one-search server that returns navigation destinations.
accepting via the payment information form page payment information from a user; [0271] the method includes presenting a purchase-related search result for the product, wherein the purchase-related search result is configured such that when a user interacts with the purchase-related search result and confirms the payment associated with the product in the purchase-related search result, the generalized search entity initiates a purchasing process for the product.
conveying the payment information to a first set of set of one or more servers for the first website; [0268] The system can automatically transition the user interface to the second website by replacing the first website in the uniform resource locator field of a browser with the second website in the uniform resource locator field of the browser. The system can further prepare a third website having a third input field preprocessed using the input, wherein the user can provide a switching input to indicate that the third website should be presented rather than the second website. In another example, the first site can process a payment for the item and coordinate with the second site to provide the necessary information for delivery of the item.
storing the payment information in a temporary, local storage location; [0368-0371] In one aspect, the payment information (credit card, address, expiration date, name, etc.) is communicated to the kiosk browser such that the proper memory is populated with the information…The kiosk browser, following the final confirmation, deletes from its memory the payment information for Mary and can confirm the deletion
displaying a confirmation page for the first website; [0054] The method can further include updating the presentation to include a buy option which is configured, based on a confirmation from the user, to enable the site to utilize the payment account data received through the API to process a purchase of an item or service without a need of the user to fill in the payment fields on the site. The browser or other agent communicating via the API can also provide the graphic for a “pay now” type of button to integrate with site graphics.
obtaining via the confirmation page or via a subsequent page reachable from the confirmation page, a user decision regarding a purchase transaction from a second website; [0036], [0673] The plurality of search results an include a first product advertisement configured according to a first type of advertisement, wherein the first product advertisement, when selected by the user, is configured to enable a purchase of the first product from the first merchant site, wherein the purchase of the first product is initiated by the generalized search entity using payment data for the user that is stored with the generalized search entity, a network based entity or on a user device. The operations can include (3) in response to the user input, presenting, as part of the plurality of search results, a second product advertisement configured according to a second type of advertisement, wherein the second product advertisement, when selected by the user, is configured to transition the user to a second merchant site associated with the second product advertisement such that the user interacts with the second merchant site to manage a payment for a second product… The difference is that the second site is already communicating with the browser for the payment process of the second product. The user, however, has navigated away from the first site, so a communication back to the first site must identify the product as well as providing payment and/or delivery data to the first site for “reminding” the first site of the previously searched-for product. Processing the payment of both the first product and the second product further can include transmitting, through the browser application programming interface a package of data which enables the first site to process the first purchase of the first product. The package of data can include payment data for the first site to process the payment for the first product and address information associated with the user for the first site to deliver the product. The method can also include receiving a confirmation from the user of the purchase of both the first product and the second product utilizing a same set of object interactions used for purchasing one product via the browser payment interface. In other words, since the user is already in the browser interface for processing the payment for the second product, the method can include utilizing the same “one-click” plus perhaps one fingerprint recognition or CVC code entry, or whatever few steps are utilized for the purchase of the second product, to also process the payment for the first product
sending, without requiring completion of a payment information form for the second website, the payment information to a second set of one or more servers for the second website if the user decision is affirmative; and [0036] The difference is that the second site is already communicating with the browser for the payment process of the second product. The user, however, has navigated away from the first site, so a communication back to the first site must identify the product as well as providing payment and/or delivery data to the first site for “reminding” the first site of the previously searched-for product. Processing the payment of both the first product and the second product further can include transmitting, through the browser application programming interface a package of data which enables the first site to process the first purchase of the first product. The package of data can include payment data for the first site to process the payment for the first product and address information associated with the user for the first site to deliver the product. The method can also include receiving a confirmation from the user of the purchase of both the first product and the second product utilizing a same set of object interactions used for purchasing one product via the browser payment interface. In other words, since the user is already in the browser interface for processing the payment for the second product, the method can include utilizing the same “one-click” plus perhaps one fingerprint recognition or CVC code entry, or whatever few steps are utilized for the purchase of the second product, to also process the payment for the first product.
Isaacson does not expressly disclose the following, Frederick, however discloses:
deleting the payment information from the temporary storage location before, or upon, closure of the confirmation page or the subsequent page. Col. 9 lines 57-67, col. 16 lines 1-5 Referring to FIG. 11, optionally, a confirmation window 52 may be generated and displayed to the user… Preferably, any action that aborts a process, closes a window, terminates the browser session, or otherwise discontinues the process of interacting with the system will trigger a cleanup script that clears all browser cookies generated by the system… If the buyer's computer is a registered computer registered with CMS 106 it may be provided with a token. A token is a cookie stored in buyer's computer 102 that identifies the buyer to CMS 106 and enables the buyer to buy through the AJAX interface.
It would have been obvious to one having ordinary skill in the art at the time the invention was filed to modify Isaacson with the ability to clear the browsing data and cookies when the user terminates a browser session as taught by Frederick, doing so further allows the user’s token to cleared upon exiting a session (Col. 9 lines 57-67, col. 16 lines 1-5).
As per claim 12, Isaacson discloses:
wherein said rendering, accepting, conveying, and storing operations are implemented by an internet browser responsive to instructions for providing the payment information page, and [0268-0271] the method includes presenting a purchase-related search result for the product, wherein the purchase-related search result is configured such that when a user interacts with the purchase-related search result and confirms the payment associated with the product in the purchase-related search result, the generalized search entity initiates a purchasing process for the product… .The system can automatically transition the user interface to the second website by replacing the first website in the uniform resource locator field of a browser with the second website in the uniform resource locator field of the browser. The system can further prepare a third website having a third input field preprocessed using the input, wherein the user can provide a switching input to indicate that the third website should be presented rather than the second website. In another example, the first site can process a payment for the item and coordinate with the second site to provide the necessary information for delivery of the item.
wherein said displaying, obtaining, sending, and deleting operations are implemented by the internet browser responsive to instructions for providing the confirmation page or the subsequent page. [0368-0371] In one aspect, the payment information (credit card, address, expiration date, name, etc.) is communicated to the kiosk browser such that the proper memory is populated with the information…The kiosk browser, following the final confirmation, deletes from its memory the payment information for Mary and can confirm the deletion [0054] The method can further include updating the presentation to include a buy option which is configured, based on a confirmation from the user, to enable the site to utilize the payment account data received through the API to process a purchase of an item or service without a need of the user to fill in the payment fields on the site. The browser or other agent communicating via the API can also provide the graphic for a “pay now” type of button to integrate with site graphics. [0036] The difference is that the second site is already communicating with the browser for the payment process of the second product. The user, however, has navigated away from the first site, so a communication back to the first site must identify the product as well as providing payment and/or delivery data to the first site for “reminding” the first site of the previously searched-for product. Processing the payment of both the first product and the second product further can include transmitting, through the browser application programming interface a package of data which enables the first site to process the first purchase of the first product. The package of data can include payment data for the first site to process the payment for the first product and address information associated with the user for the first site to deliver the product. The method can also include receiving a confirmation from the user of the purchase of both the first product and the second product utilizing a same set of object interactions used for purchasing one product via the browser payment interface. In other words, since the user is already in the browser interface for processing the payment for the second product, the method can include utilizing the same “one-click” plus perhaps one fingerprint recognition or CVC code entry, or whatever few steps are utilized for the purchase of the second product, to also process the payment for the first product.
As per claim 13, Isaacson discloses:
A non-transitory computer-readable medium storing instructions that, when incorporated in a confirmation form page of a first website accessed by an internet browser on a client device, configures a processor to: [0495], [0254] The method includes presenting a user input field that processes input according to a default destination site (1260), receiving user input in the input field (1262), based on the user input, automatically presenting an object indicating that if the user enters the user input in the input field, that the user will transition to a second destination site that differs from the default destination site (1264), and receiving a confirmation from the user to process the user input (1266). The method further includes, based on the confirmation, transitioning the user to the second destination site (1268). The confirmation can be the user hitting an enter button, providing some other type of input indicating that the user input should be processed or pressing the enter key on a keyboard. The order of items in a menu can also dynamically adjust as the user types such that the default site changes while typing.
obtain a user decision regarding a secondary transaction; [0036], [0673] The plurality of search results an include a first product advertisement configured according to a first type of advertisement, wherein the first product advertisement, when selected by the user, is configured to enable a purchase of the first product from the first merchant site, wherein the purchase of the first product is initiated by the generalized search entity using payment data for the user that is stored with the generalized search entity, a network based entity or on a user device. The operations can include (3) in response to the user input, presenting, as part of the plurality of search results, a second product advertisement configured according to a second type of advertisement, wherein the second product advertisement, when selected by the user, is configured to transition the user to a second merchant site associated with the second product advertisement such that the user interacts with the second merchant site to manage a payment for a second product… The difference is that the second site is already communicating with the browser for the payment process of the second product. The user, however, has navigated away from the first site, so a communication back to the first site must identify the product as well as providing payment and/or delivery data to the first site for “reminding” the first site of the previously searched-for product. Processing the payment of both the first product and the second product further can include transmitting, through the browser application programming interface a package of data which enables the first site to process the first purchase of the first product. The package of data can include payment data for the first site to process the payment for the first product and address information associated with the user for the first site to deliver the product. The method can also include receiving a confirmation from the user of the purchase of both the first product and the second product utilizing a same set of object interactions used for purchasing one product via the browser payment interface. In other words, since the user is already in the browser interface for processing the payment for the second product, the method can include utilizing the same “one-click” plus perhaps one fingerprint recognition or CVC code entry, or whatever few steps are utilized for the purchase of the second product, to also process the payment for the first product
send, if the user decision is affirmative and without requiring completion of a payment information form associated with a second website, payment information previously stored by the internet browser in a temporary, local storage location in response to a primary transaction with the first website; and [0036] [0368-0371] In one aspect, the payment information (credit card, address, expiration date, name, etc.) is communicated to the kiosk browser such that the proper memory is populated with the information…The kiosk browser, following the final confirmation, deletes from its memory the payment information for Mary and can confirm the deletion…The difference is that the second site is already communicating with the browser for the payment process of the second product. The user, however, has navigated away from the first site, so a communication back to the first site must identify the product as well as providing payment and/or delivery data to the first site for “reminding” the first site of the previously searched-for product. Processing the payment of both the first product and the second product further can include transmitting, through the browser application programming interface a package of data which enables the first site to process the first purchase of the first product. The package of data can include payment data for the first site to process the payment for the first product and address information associated with the user for the first site to deliver the product. The method can also include receiving a confirmation from the user of the purchase of both the first product and the second product utilizing a same set of object interactions used for purchasing one product via the browser payment interface. In other words, since the user is already in the browser interface for processing the payment for the second product, the method can include utilizing the same “one-click” plus perhaps one fingerprint recognition or CVC code entry, or whatever few steps are utilized for the purchase of the second product, to also process the payment for the first product.
Isaacson does not expressly disclose the following, Frederick, however discloses:
delete the payment information from the temporary storage location before, or upon, closure of the confirmation page. Col. 9 lines 57-67, col. 16 lines 1-5 Referring to FIG. 11, optionally, a confirmation window 52 may be generated and displayed to the user… Preferably, any action that aborts a process, closes a window, terminates the browser session, or otherwise discontinues the process of interacting with the system will trigger a cleanup script that clears all browser cookies generated by the system… If the buyer's computer is a registered computer registered with CMS 106 it may be provided with a token. A token is a cookie stored in buyer's computer 102 that identifies the buyer to CMS 106 and enables the buyer to buy through the AJAX interface.
It would have been obvious to one having ordinary skill in the art at the time the invention was filed to modify Isaacson with the ability to clear the browsing data and cookies when the user terminates a browser session as taught by Frederick, doing so further allows the user’s token to cleared upon exiting a session (Col. 9 lines 57-67, col. 16 lines 1-5).
Claims 2, 3, 10, 11, 14, 16, and 17 are rejected under 35 U.S.C. 103 as being unpatentable over Isaacson, et al. (US Patent Application Publication 20230351474), “Isaacson” in view of Frederick, et al. (US Patent 11,023,960 B1), “Frederick” in view of Fan (US Patent Application Publication 20180375863), “Fan”.
As per claims 2, 10, and 14, Isaacson does not expressly disclose the following, Fan, however discloses:
wherein the temporary storage location holds the payment information in encrypted form and said storing includes using a public key to generate the encrypted form, wherein the public key is associated with the second website. [0052-0055], [0067] For example, shopping website S first verifies authenticity of this password-free proxy login setting request. S can use the public key of payment website A to check authenticity of the website name of payment website A included in token a. When shopping website S determines that the request is indeed sent by payment website A, shopping website S creates token b in this step. Token b can be referred to as a first token… Token b can include three types of information. A first type of information is a device fingerprint. The device fingerprint mainly serves as an identifier indicating a running environment where current password-free proxy login is set. The running environment can include, for example, a current computer and a browser that the shopping website and the payment website run on. In specific implementation, for example, client code, such as JavaScript or Flash used in the browser, can be used to actively collect browser platform information, for example, a browser language. Server code, for example, Java or Python, can be used to actively collect field information such as operating system code in network protocols of various layers such as HTTP and TCP/IP. A device fingerprint can be used to uniquely identify a client computer (including a browser) after data combination. The fingerprint is encrypted by using the public key of S. A second type of information is the website identifier (e.g. the website name) of payment website A encrypted by using the public key of S. A third type of information is the current time encrypted by using the public key of S… In step 304, shopping website S stores token b in cookies of a browser, and can store a correspondence between token b and token a in a backend database of the website… For example, shopping website S can identify, based on the website identifier of payment website A included in token c, token b including the website identifier in cookies of a browser, delete token b, and delete the corresponding token b and token a from a backend database.
It would have been obvious to one having ordinary skill in the art at the time the invention was filed to modify Isaacson with the ability encrypt the token using the public key of the website as taught by Fan, doing so further allows password free proxy login based on the public key for completing transactions [0151], [0160].
As per claims 3, and 11, Issacson discloses:
wherein said sending includes transmitting the encrypted form of the payment information retrieved from the temporary storage location. [0353], [0368-0371] In one aspect, the payment information (credit card, address, expiration date, name, etc.) is communicated to the kiosk browser such that the proper memory is populated with the information…The kiosk browser, following the final confirmation, deletes from its memory the payment information for Mary and can confirm the deletion… The process can enable the site to receive or create a pay button (different in function from their locally used pay button which does not interface through an API with the browser), request and receive payment data about the user such as an address and payment account data, which can be encrypted, enable the user to update any of the payment data and then locally process the payment using the received payment data. There are many mechanisms through which the browser can pass payment information to the site. For example, the browser can store a credit card and/or could be integrated with Android Pay through Chrome or Apple Pay through Safari. In this regard, there may be a separate application or software such as Android Pay or Apple Pay that communicates with the browser to provide one or more of the data needed to pass to the site for payment processing.
As per claim 16, Isaacson discloses:
A payment system that comprises: [0011]
a first set of one or more servers for a first website having at least one page that configures a client device to store, in a temporary storage location, payment information the first website further having a subsequent page that configures the client device to: [0153], [0236], [0368-0371] It is presumed, such as in the case of Amazon or an auction web site, that when the user navigates to one-search.com, that user information, debit/credit card information, address information, etc., is stored in a user profile and available, as in the case of a registered user at Amazon.com. For example, as part of a registration or enrollment process, the user can establish an account with one-search.com, and authenticate or provide credentials to link the one-search.com account with accounts at other websites… In this example user interface, the user enters the text “iPhone 5S” into a unified input field 902. The browser communicates the text to a one-search server that returns navigation destinations… In one aspect, the payment information (credit card, address, expiration date, name, etc.) is communicated to the kiosk browser such that the proper memory is populated with the information…The kiosk browser, following the final confirmation, deletes from its memory the payment information for Mary and can confirm the deletion
obtain a user decision regarding a secondary transaction; [0036], [0673] The plurality of search results an include a first product advertisement configured according to a first type of advertisement, wherein the first product advertisement, when selected by the user, is configured to enable a purchase of the first product from the first merchant site, wherein the purchase of the first product is initiated by the generalized search entity using payment data for the user that is stored with the generalized search entity, a network based entity or on a user device. The operations can include (3) in response to the user input, presenting, as part of the plurality of search results, a second product advertisement configured according to a second type of advertisement, wherein the second product advertisement, when selected by the user, is configured to transition the user to a second merchant site associated with the second product advertisement such that the user interacts with the second merchant site to manage a payment for a second product… The difference is that the second site is already communicating with the browser for the payment process of the second product. The user, however, has navigated away from the first site, so a communication back to the first site must identify the product as well as providing payment and/or delivery data to the first site for “reminding” the first site of the previously searched-for product. Processing the payment of both the first product and the second product further can include transmitting, through the browser application programming interface a package of data which enables the first site to process the first purchase of the first product. The package of data can include payment data for the first site to process the payment for the first product and address information associated with the user for the first site to deliver the product. The method can also include receiving a confirmation from the user of the purchase of both the first product and the second product utilizing a same set of object interactions used for purchasing one product via the browser payment interface. In other words, since the user is already in the browser interface for processing the payment for the second product, the method can include utilizing the same “one-click” plus perhaps one fingerprint recognition or CVC code entry, or whatever few steps are utilized for the purchase of the second product, to also process the payment for the first product
send the encrypted payment information from the temporary storage location to a second set of one or more servers for a second website if the user decision is affirmative; and [0036] The difference is that the second site is already communicating with the browser for the payment process of the second product. The user, however, has navigated away from the first site, so a communication back to the first site must identify the product as well as providing payment and/or delivery data to the first site for “reminding” the first site of the previously searched-for product. Processing the payment of both the first product and the second product further can include transmitting, through the browser application programming interface a package of data which enables the first site to process the first purchase of the first product. The package of data can include payment data for the first site to process the payment for the first product and address information associated with the user for the first site to deliver the product. The method can also include receiving a confirmation from the user of the purchase of both the first product and the second product utilizing a same set of object interactions used for purchasing one product via the browser payment interface. In other words, since the user is already in the browser interface for processing the payment for the second product, the method can include utilizing the same “one-click” plus perhaps one fingerprint recognition or CVC code entry, or whatever few steps are utilized for the purchase of the second product, to also process the payment for the first product.
Isaacson does not expressly disclose the following, Frederick, however discloses:
delete the payment information from the temporary storage location before, or upon, closure of the subsequent page. Col. 9 lines 57-67, col. 16 lines 1-5 Referring to FIG. 11, optionally, a confirmation window 52 may be generated and displayed to the user… Preferably, any action that aborts a process, closes a window, terminates the browser session, or otherwise discontinues the process of interacting with the system will trigger a cleanup script that clears all browser cookies generated by the system… If the buyer's computer is a registered computer registered with CMS 106 it may be provided with a token. A token is a cookie stored in buyer's computer 102 that identifies the buyer to CMS 106 and enables the buyer to buy through the AJAX interface.
It would have been obvious to one having ordinary skill in the art at the time the invention was filed to modify Isaacson with the ability to clear the browsing data and cookies when the user terminates a browser session as taught by Frederick, doing so further allows the user’s token to cleared upon exiting a session (Col. 9 lines 57-67, col. 16 lines 1-5).
Isaacson does expressly disclose the payment information as encrypted using the public key associated with a second website, Fan how discloses this feature as shown below:
encrypted payment information encrypted using a public key associated with a second website [0052-0055], [0067] For example, shopping website S first verifies authenticity of this password-free proxy login setting request. S can use the public key of payment website A to check authenticity of the website name of payment website A included in token a. When shopping website S determines that the request is indeed sent by payment website A, shopping website S creates token b in this step. Token b can be referred to as a first token… Token b can include three types of information. A first type of information is a device fingerprint. The device fingerprint mainly serves as an identifier indicating a running environment where current password-free proxy login is set. The running environment can include, for example, a current computer and a browser that the shopping website and the payment website run on. In specific implementation, for example, client code, such as JavaScript or Flash used in the browser, can be used to actively collect browser platform information, for example, a browser language. Server code, for example, Java or Python, can be used to actively collect field information such as operating system code in network protocols of various layers such as HTTP and TCP/IP. A device fingerprint can be used to uniquely identify a client computer (including a browser) after data combination. The fingerprint is encrypted by using the public key of S. A second type of information is the website identifier (e.g. the website name) of payment website A encrypted by using the public key of S. A third type of information is the current time encrypted by using the public key of S… In step 304, shopping website S stores token b in cookies of a browser, and can store a correspondence between token b and token a in a backend database of the website… For example, shopping website S can identify, based on the website identifier of payment website A included in token c, token b including the website identifier in cookies of a browser, delete token b, and delete the corresponding token b and token a from a backend database.
It would have been obvious to one having ordinary skill in the art at the time the invention was filed to modify Isaacson with the ability encrypt the token using the public key of the website as taught by Fan, doing so further allows password free proxy login based on the public key for completing transactions [0151], [0160].
As per claim 17, Issacson discloses:
wherein the client device employs an internet browser to render the payment information form page and the confirmation page. [0036], [0673] [0266] Once the user clicks enter, the system can transition immediately to the new URL or destination site as if the user had clicked and navigated through a series of pages in a shopping cart, loading each page in turn and entering data automatically on the browser side, or the system can communicate with the target website directly to accomplish the various sub-tasks associated with selecting an item, adding that item to a cart, entering or selecting shipping and payment information, and so forth, leading up to the final stage where the user simply clicks “submit order.” The browser API could be used to manage the payment process… The plurality of search results an include a first product advertisement configured according to a first type of advertisement, wherein the first product advertisement, when selected by the user, is configured to enable a purchase of the first product from the first merchant site, wherein the purchase of the first product is initiated by the generalized search entity using payment data for the user that is stored with the generalized search entity, a network based entity or on a user device. The operations can include (3) in response to the user input, presenting, as part of the plurality of search results, a second product advertisement configured according to a second type of advertisement, wherein the second product advertisement, when selected by the user, is configured to transition the user to a second merchant site associated with the second product advertisement such that the user interacts with the second merchant site to manage a payment for a second product… The difference is that the second site is already communicating with the browser for the payment process of the second product. The user, however, has navigated away from the first site, so a communication back to the first site must identify the product as well as providing payment and/or delivery data to the first site for “reminding” the first site of the previously searched-for product. Processing the payment of both the first product and the second product further can include transmitting, through the browser application programming interface a package of data which enables the first site to process the first purchase of the first product. The package of data can include payment data for the first site to process the payment for the first product and address information associated with the user for the first site to deliver the product. The method can also include receiving a confirmation from the user of the purchase of both the first product and the second product utilizing a same set of object interactions used for purchasing one product via the browser payment interface. In other words, since the user is already in the browser interface for processing the payment for the second product, the method can include utilizing the same “one-click” plus perhaps one fingerprint recognition or CVC code entry, or whatever few steps are utilized for the purchase of the second product, to also process the payment for the first product
Claims 5 and 15 are rejected under 35 U.S.C. 103 as being unpatentable over Isaacson, et al. (US Patent Application Publication 20230351474), “Isaacson” in view of Frederick, et al. (US Patent 11,023,960 B1), “Frederick” in view of Davis, et al. (US Patent Application Publication 20130151515), “Davis”.
As per claims 5, and 15, Isaacson does not expressly disclose the following, Davis, however discloses:
wherein the temporary storage location is memory allocated to a local variable in a runtime environment for the internet browser. [0056], [0118] For certain example implementations, at least one device may obtain at least one indication of family relation 706 for at least one authorized user via at least one cookie (e.g., a Hypertext Transfer Protocol (HTTP) cookie, a piece of data saved on a user device by a website via a browser function or capability, a storage location associated with a website as allotted by a browser, a combination thereof, etc.) stored by a browser (e.g., stored in a browser; stored under the direction of a browser; stored into a block of memory allocated to a browser; stored in response to a command initiated at, authorized by, or routed through a browser; a combination thereof; etc.) that is facilitating at least one browser-based interaction. By way of example but not limitation, a cloud-based service (e.g., Apple's iCloud) may obtain at least one indication of family relation for at least one authorized user via at least one cookie (e.g., by reading data saved by Ancestry[dot]com or another website and) stored by a browser (e.g., stored by Safari on an iMac) that is facilitating at least one browser-based interaction… Instructions 420 may comprise, by way of example but not limitation, a program, a module, an application or app (e.g., that is native, that runs in a browser, that runs within a virtual machine, a combination thereof, etc.), an operating system, a combination thereof, etc. or portion thereof; operational data structures; source code, object code, just-in-time (JIT) compiled code, a combination thereof, etc.
It would have been obvious to one having ordinary skill in the art at the time the invention was filed to modify Isaacson with the ability store data as allotted by the browser as taught by Davis, doing so further allows for browser-based interactions [0118].
Claim 7 is rejected under 35 U.S.C. 103 as being unpatentable over Isaacson, et al. (US Patent Application Publication 20230351474), “Isaacson” in view of Frederick, et al. (US Patent 11,023,960 B1), “Frederick” in view of Granbery (US Patent Application Publication 20160021687), “Granbery”.
As per claim 7, Isaacson does not expressly disclose the following, Granbury, however discloses:
wherein the temporary storage location has a timeout that triggers deletion of the payment information if not previously deleted. [0031], [0034], [0067-0068] The applications 118 may also include token management applications that may, for example, receive, process, manage, and/or present tokens allowing user 110 to perform transactions, present credentials, and/or the like… remote server 104 may send a cookie, token, and/or other object to client computing device 102 that provides an indication of the association between user 110 and client computing device 102… At a process 620, client computing device 102 may determine whether a time out period for the recreated custom token is expired. In some embodiments, recreation of the custom token during process 616 and/or activation of token management application 914 during process 618 may include having token management application 914 activate a timer 916... In some embodiments, the time out period may be set to a fixed period of time after the time at which the custom token was recreated. In some embodiments, the fixed period of time may be set by policy and/or user preference and may be based on the type and/or desired use of the custom token… When the time out period expires, the recreated custom token is removed using a process 622
It would have been obvious to one having ordinary skill in the art at the time the invention was filed to modify Isaacson with the ability to remove the token after a set period of time as taught by Granbery, doing so further allows the tokens to be time-limited as desired by the user [0067].
Claim 8 is rejected under 35 U.S.C. 103 as being unpatentable over Isaacson, et al. (US Patent Application Publication 20230351474), “Isaacson” in view of Frederick, et al. (US Patent 11,023,960 B1), “Frederick” in view of Jones, et al. (US Patent Application Publication 20220383314), “Jones”.
As per claim 8, Isaacson does not expressly disclose the following, Jones, however discloses:
wherein the confirmation page, or a subsequent page reachable via the confirmation page, configures the client device to delete the payment information upon determining that the user decision is negative. [0090], [0100-0103] As described herein, decomposed field data 204 may include elements of customer data 206, payment data 208, transaction data 210, counterparty data 212, and remittance information 214 that collectively identify and characterize the request, from the first retailer… Further, when presented within notification interface 352 by display unit 109A, interface elements 364 may provide a graphical representation 374 of payment notification 326 that prompts user 101 to approve or reject the $75.00 payment requested by the second retailer (e.g., “Woody's Suits”) for the purchased pants on May 30, 2022, e.g., based on additional input provided to input unit 109B of client device 102 that selects a respective one of an “APPROVE” icon 378 and a “REJECT” icon 380… In other instances, and based on confirmation data indicating a rejection by user 101 of one or more of the requested real-time payments (e.g., based on additional input selecting corresponding ones of “REJECT” icon 372, 380, and 386), FI computing system 130 may perform operations that access RFP messages 202A, 202B, and 202C maintained within RFP queue 135 (along with corresponding elements of decomposed field data 204, 252, and 266), and delete from RFP queue 135 one or more of RFP messages 202A, 202B, and 202C, and the elements of decomposed field data 204, 252, and 266, that are associated with the rejected, real-time payment (or payments), and generate and transmit one or more messages to corresponding ones of merchant systems 110, 114, and 118 indicative of the rejected payment, either directly across network 120 or through one or more of computing systems or devices associated with participants in the RTP ecosystem (e.g., additional ISO-20022-compliant messages, etc.).
It would have been obvious to one having ordinary skill in the art at the time the invention was filed to modify Isaacson with the ability to delete the payment data when the user rejects an offer as taught by Jones, doing so further allows payment data to be removed if the user declines a transaction [0100-0103].
Claim 18 is rejected under 35 U.S.C. 103 as being unpatentable over Isaacson, et al. (US Patent Application Publication 20230351474), “Isaacson” in view of Frederick, et al. (US Patent 11,023,960 B1), “Frederick” in view of Fan (US Patent Application Publication 20180375863), “Fan” in view of Davis, et al. (US Patent Application Publication 20130151515), “Davis”.
As per claim 18, Isaacson does not expressly disclose the following, Davis, however discloses:
wherein the temporary storage location is memory allocated to a local variable in a runtime environment for the internet browser. [0056], [0118] For certain example implementations, at least one device may obtain at least one indication of family relation 706 for at least one authorized user via at least one cookie (e.g., a Hypertext Transfer Protocol (HTTP) cookie, a piece of data saved on a user device by a website via a browser function or capability, a storage location associated with a website as allotted by a browser, a combination thereof, etc.) stored by a browser (e.g., stored in a browser; stored under the direction of a browser; stored into a block of memory allocated to a browser; stored in response to a command initiated at, authorized by, or routed through a browser; a combination thereof; etc.) that is facilitating at least one browser-based interaction. By way of example but not limitation, a cloud-based service (e.g., Apple's iCloud) may obtain at least one indication of family relation for at least one authorized user via at least one cookie (e.g., by reading data saved by Ancestry[dot]com or another website and) stored by a browser (e.g., stored by Safari on an iMac) that is facilitating at least one browser-based interaction… Instructions 420 may comprise, by way of example but not limitation, a program, a module, an application or app (e.g., that is native, that runs in a browser, that runs within a virtual machine, a combination thereof, etc.), an operating system, a combination thereof, etc. or portion thereof; operational data structures; source code, object code, just-in-time (JIT) compiled code, a combination thereof, etc.
It would have been obvious to one having ordinary skill in the art at the time the invention was filed to modify Isaacson with the ability store data as allotted by the browser as taught by Davis, doing so further allows for browser-based interactions [0118].
Claim 19 is rejected under 35 U.S.C. 103 as being unpatentable over Isaacson, et al. (US Patent Application Publication 20230351474), “Isaacson” in view of Frederick, et al. (US Patent 11,023,960 B1), “Frederick” in view of Fan (US Patent Application Publication 20180375863), “Fan” in view of Granbery (US Patent Application Publication 20160021687), “Granbery”.
As per claim 19, Isaacson does not expressly disclose the following, Granbury, however discloses:
wherein the temporary storage location has a timeout that triggers deletion of the payment information if not previously deleted. [0031], [0034], [0067-0068] The applications 118 may also include token management applications that may, for example, receive, process, manage, and/or present tokens allowing user 110 to perform transactions, present credentials, and/or the like… remote server 104 may send a cookie, token, and/or other object to client computing device 102 that provides an indication of the association between user 110 and client computing device 102… At a process 620, client computing device 102 may determine whether a time out period for the recreated custom token is expired. In some embodiments, recreation of the custom token during process 616 and/or activation of token management application 914 during process 618 may include having token management application 914 activate a timer 916... In some embodiments, the time out period may be set to a fixed period of time after the time at which the custom token was recreated. In some embodiments, the fixed period of time may be set by policy and/or user preference and may be based on the type and/or desired use of the custom token… When the time out period expires, the recreated custom token is removed using a process 622
It would have been obvious to one having ordinary skill in the art at the time the invention was filed to modify Isaacson with the ability to remove the token after a set period of time as taught by Granbery, doing so further allows the tokens to be time-limited as desired by the user [0067].
Claim 20 is rejected under 35 U.S.C. 103 as being unpatentable over Isaacson, et al. (US Patent Application Publication 20230351474), “Isaacson” in view of Frederick, et al. (US Patent 11,023,960 B1), “Frederick” in view of Fan (US Patent Application Publication 20180375863), “Fan” in view of Jones, et al. (US Patent Application Publication 20220383314), “Jones”.
As per claim 20, Issacson does not expressly disclose the following, Jones, however discloses:
wherein the subsequent page configures the client device to delete the payment information upon determining that the user decision is negative. 0090], [0100-0103] As described herein, decomposed field data 204 may include elements of customer data 206, payment data 208, transaction data 210, counterparty data 212, and remittance information 214 that collectively identify and characterize the request, from the first retailer… Further, when presented within notification interface 352 by display unit 109A, interface elements 364 may provide a graphical representation 374 of payment notification 326 that prompts user 101 to approve or reject the $75.00 payment requested by the second retailer (e.g., “Woody's Suits”) for the purchased pants on May 30, 2022, e.g., based on additional input provided to input unit 109B of client device 102 that selects a respective one of an “APPROVE” icon 378 and a “REJECT” icon 380… In other instances, and based on confirmation data indicating a rejection by user 101 of one or more of the requested real-time payments (e.g., based on additional input selecting corresponding ones of “REJECT” icon 372, 380, and 386), FI computing system 130 may perform operations that access RFP messages 202A, 202B, and 202C maintained within RFP queue 135 (along with corresponding elements of decomposed field data 204, 252, and 266), and delete from RFP queue 135 one or more of RFP messages 202A, 202B, and 202C, and the elements of decomposed field data 204, 252, and 266, that are associated with the rejected, real-time payment (or payments), and generate and transmit one or more messages to corresponding ones of merchant systems 110, 114, and 118 indicative of the rejected payment, either directly across network 120 or through one or more of computing systems or devices associated with participants in the RTP ecosystem (e.g., additional ISO-20022-compliant messages, etc.).
It would have been obvious to one having ordinary skill in the art at the time the invention was filed to modify Isaacson with the ability to delete the payment data when the user rejects an offer as taught by Jones, doing so further allows payment data to be removed if the user declines a transaction [0100-0103].
Conclusion
Any inquiry concerning this communication or earlier communications from the examiner should be directed to GREGORY S CUNNINGHAM II whose telephone number is (313)446-6564. The examiner can normally be reached Mon-Fri 8:30am-4pm.
Examiner interviews are available via telephone, in-person, and video conferencing using a USPTO supplied web-based collaboration tool. To schedule an interview, applicant is encouraged to use the USPTO Automated Interview Request (AIR) at http://www.uspto.gov/interviewpractice.
If attempts to reach the examiner by telephone are unsuccessful, the examiner’s supervisor, Bennett Sigmond can be reached at 303-297-4411. The fax phone number for the organization where this application or proceeding is assigned is 571-273-8300.
Information regarding the status of published or unpublished applications may be obtained from Patent Center. Unpublished application information in Patent Center is available to registered users. To file and manage patent submissions in Patent Center, visit: https://patentcenter.uspto.gov. Visit https://www.uspto.gov/patents/apply/patent-center for more information about Patent Center and https://www.uspto.gov/patents/docx for information about filing in DOCX format. For additional questions, contact the Electronic Business Center (EBC) at 866-217-9197 (toll-free). If you would like assistance from a USPTO Customer Service Representative, call 800-786-9199 (IN USA OR CANADA) or 571-272-1000.
GREGORY S. CUNNINGHAM II
Primary Examiner
Art Unit 3694
/GREGORY S CUNNINGHAM II/Primary Examiner, Art Unit 3694
Prosecution Insights