US 10121186

Here is a concise summary of US patent 10121186:

US Patent 10121186: System and method of using a browser application programming interface for making payments

• Title: System and method of using a browser application programming interface for making payments
• Assignee: Monticello Enterprises LLC
• Inventors: Thomas M. Isaacson, Ryan Connell Durham
• Filing Date: 2017-05-04
• Issue Date: 2018-11-06
• Abstract: The patent describes a system, method, and computer-readable storage device that simplify online purchases using an improved browser application programming interface (API). This browser API facilitates communication between a browser or agent and a merchant site, allowing for pre-filling of payment fields or streamlining the purchase process to reduce user interaction steps. Another aspect involves presenting an input field on a generalized search entity's user interface. This search engine, which indexes both merchant and non-merchant sites, receives text-based user input. It correlates this query with a product database to determine if the user has a search intent or a purchase intent. If a purchase intent is detected, a purchase-related search result with a buy option is presented. When a user interacts with this buy option and confirms a purchase, the generalized search engine (or another payment service) assists in processing the item's purchase.

Plain-Language Overview of Independent Claims:

• Independent Claim 1: This claim describes a method where a browser's user interface receives input in a text field. An object appears only after the user starts typing. When the user interacts with this object, they are automatically taken to a second website linked to that object. The original input from the user is then automatically put into a search field on the second website, and the second website processes this input as if the user had typed it directly there.
• Independent Claim 10: This claim covers a method where a graphical user interface displays content from a website. When a user interacts with this content, the system receives a request from the website, via an API, for the user's payment information. This payment data is then sent back to the website through the API, allowing the website to automatically fill in payment fields for processing a purchase or to streamline the payment process for the user.
• Independent Claim 19: This claim describes a method from the perspective of a website. The website sends content to be displayed on a user's device. When the user interacts with this content, the website sends a request to an API for the user's payment account data. The website then receives this data via the API and uses it to automatically fill in payment fields for a purchase.
• Independent Claim 26: Similar to Claim 10, this method involves displaying content from a site on a graphical user interface. Upon user interaction, a request for payment account data is received through an API. The payment field associated with the displayed content is then automatically populated with this payment data, which is subsequently sent back to the site via the API to process a payment.
• Independent Claim 29: This claim describes a method where a user interacts with an advertisement or notice for a product on a first website within a browser. The user is then transitioned from this first site to a specific "deep link" state on a merchant's website. This transition uses data retrieved from the browser, allowing the user to buy the product with a single interaction (e.g., clicking a purchase button) without manually entering payment or address details.
• Independent Claim 36: This claim outlines a method involving a generalized search engine that searches both merchant and non-merchant sites through a user input field. After the user enters a text query, the search engine links it to a product database and determines if the user intends to search or purchase. If a purchase intent is found, a search result with a "buy option" is presented. If the user interacts with this buy option and confirms the purchase, the search engine (or a payment service) helps process the transaction.
• Independent Claim 40: This claim describes a method for social networking sites. A product post is transmitted with a "payment process initiation object" (like a button or link). When a user interacts with this object, a dialogue about the product begins as part of the payment process. At the end of this dialogue, the user can complete the purchase using a browser payment request API, where the social networking site or browser sends payment data to the merchant site for processing.

Litigation Search (CAFC 2026 Dockets):
A search of CAFC 2026 dockets for US patent 10121186 or the assignee Monticello Enterprises LLC did not return any specific litigation directly referencing this patent within the specified timeframe.

US Patent 10121186 has been involved in the following litigation:

• Plaintiff(s): Monticello Enterprises LLC

• Defendant(s): Undisclosed

• Jurisdiction: Texas Western District Court

• Case Number: 6:23-cv-00761

• Filing Date: Not specified in the provided information.

• Outcome/Current Status: Case filed.

• Plaintiff(s): Monticello Enterprises LLC

• Defendant(s): Undisclosed

• Jurisdiction: Court of Appeals for the Federal Circuit (CAFC)

• Case Number: 26-1730

• Filing Date: Not specified in the provided information.

• Outcome/Current Status: Case filed.

• Plaintiff(s): Monticello Enterprises LLC

• Defendant(s): Undisclosed

• Jurisdiction: Court of Appeals for the Federal Circuit (CAFC)

• Case Number: 26-1694

• Filing Date: Not specified in the provided information.

• Outcome/Current Status: Case filed.

It is worth noting that while Unified Patents provides data on patent litigation, they primarily focus on inter partes reviews (IPRs) and challenging patents, rather than being a plaintiff in infringement cases. The information provided above is directly from the patent's Google Patents page, which cites Unified Patents' litigation data. To get more detailed, real-time information on case filings and status, one would typically use PACER (Public Access to Court Electronic Records), which is a national index for federal court cases. However, accessing PACER often requires a registered account and may involve fees.

Proceedings overview

There are no AIA trial proceedings (IPR, PGR, or CBM) on file for US Patent 10,121,186 as of the most recent ingest and confirmed by web search. This indicates that the patent has not been challenged via these mechanisms at the USPTO Patent Trial and Appeal Board. For a defendant, this means the patent's claims remain untested by the PTAB's validity standards.

Strategic summary

Currently, all claims of US Patent 10,121,1186 are UNTESTED by AIA trial proceedings. There have been no IPR, PGR, or CBM petitions filed against this patent.

The absence of PTAB proceedings means there is no estoppel landscape under 35 U.S.C. § 315(e)(2) for this patent. All prior art grounds are theoretically available to a defendant facing assertion of this patent, provided they meet the statutory requirements for any potential PTAB petition they might file.

The lack of PTAB activity can be a signal that the patent either has not been widely asserted yet, or that previous assertions have not prompted defendants to seek IPR/PGR, possibly due to licensing agreements or early settlements. Given that the patent has active litigation in district courts and at the Federal Circuit, the lack of PTAB challenges is noteworthy.

Recommended next steps

Since no PTAB activity exists for US Patent 10,121,186, a defendant currently facing assertion of this patent would need to evaluate the patentability of the claims from a first-principles perspective. Considerations for potential PTAB challenges would include:

• Prior Art Search: Conduct a thorough prior art search to identify any strong references that could form the basis of an IPR or PGR petition.
• Claim Analysis: Perform a detailed analysis of the claims of US10121186 against any newly discovered or existing prior art to identify potential invalidity grounds under 35 U.S.C. §§ 102, 103, or 112.
• Timing: Consider the statutory deadlines for filing IPR (e.g., within one year of being served with a complaint alleging infringement) or PGR (e.g., within nine months of patent grant).
• Litigation Strategy: Assess whether filing an IPR or PGR aligns with the overall litigation strategy, considering factors such as potential stays of district court litigation and the PTAB's lower burden of proof for invalidity.

Inventors

• Thomas M. Isaacson
• Ryan Connell Durham

The employer of the inventors at the time of filing is not explicitly stated. However, the inventors assigned their rights to Monticello Enterprises LLC. There is no information to suggest an unusual pattern of inventors departing the original assignee within 12 months of filing.

Original assignee

The original assignee, as listed on the patent and confirmed by the initial assignment, is Monticello Enterprises LLC. Based on available information, Monticello Enterprises LLC does not appear to ship products embodying the claims related to browser payment APIs. Their primary line of business, in the context of these patents, is patent assertion, as evidenced by their involvement in numerous patent infringement lawsuits. Their current status is operating.

Assignment timeline

• 2017-08-15 (executed) / recorded 2018-08-28 — Reel 046343/0651
  • Conveyance: ASSIGNMENT
  • Assignor: ISAACSON, THOMAS M.; DURHAM, RYAN CONNELL
  • Assignee: MONTICELLO ENTERPRISES LLC
  • Correspondent: N/A (NO CORRESPONDENT DATA AVAILABLE).
  • Context: Inventors assigned the patent rights to Monticello Enterprises LLC.

There are no other recorded assignments for US10121186 in the USPTO Assignment Center.

Timeline diagram

timeline
    title Ownership of US 10121186
    2014 : Priority date
    2017 : Inventors assigned to Monticello
    2018 : Patent issued to Monticello
    2023 : First suit filed by Monticello

NPE / troll-pattern signals

1. Shell-entity transfer — Present. Monticello Enterprises LLC appears to operate as a licensing-only entity. Evidence from search results indicates its primary activity concerning these types of patents is assertion against operating companies, such as Petco, Starbucks, and Macy's, rather than product development or sales. Unified Patents explicitly categorizes Monticello Enterprises LLC as an NPE (Patent Assertion Entity).
2. Known asserter in the chain — Present. Monticello Enterprises LLC is explicitly identified as an NPE by Unified Patents, a prominent anti-NPE organization, in relation to its patent assertion activities, including patents on browser payment interfaces.
3. Repeat correspondent across the chain — Unclear. The single assignment recorded (Reel 046343/0651) has "NO CORRESPONDENT DATA AVAILABLE," so recurrence cannot be assessed from this record.
4. Cascading transfers — Not present. Only one assignment is recorded for this patent.
5. Pre-litigation transfer — Not present. The only recorded assignment (Reel 046343/0651, recorded 2018-08-28) occurred well before the first infringement suit filed in 2023.
6. Bankruptcy fire-sale — Not present. No evidence suggests the patent was acquired through bankruptcy proceedings.
7. Privateering — Unclear. While Monticello Enterprises LLC is an NPE asserting patents against operating companies, there is no explicit information in the provided context or search results to indicate that they are doing so on behalf of a specific operating company.
8. Defensive aggregator (anti-NPE) — Not present. The chain ends with Monticello Enterprises LLC, which is an asserter, not a defensive aggregator.

Verdict

NPE — high confidence. Monticello Enterprises LLC is identified as the original and current assignee, and Unified Patents explicitly labels them as a Patent Assertion Entity (NPE) in the context of their active patent litigation related to browser payment APIs. This, combined with the lack of evidence that Monticello Enterprises LLC produces products embodying the claims, strongly indicates an NPE pattern. The first recorded litigation involving this patent family (6:23-cv-00761) also names Monticello Enterprises LLC as the plaintiff.

USPTO Assignment Center search page: https://assignmentcenter.uspto.gov/

To identify the most relevant prior art for US patent 10121186, I will examine the patent citations provided within the patent document itself. The patent lists "Prior art keywords" and "Priority claimed from" dates, which typically point to relevant prior art. Since the prompt specifically requests prior art for US10121186, I will focus on the references that US10121186 cites.

As a reminder, prior art anticipates a claimed invention if it describes the invention in sufficient detail to enable a person of ordinary skill in the art to carry it out. An invention is not patentable if it was described in an earlier printed publication or patent.

I will now extract the cited prior art from the patent document and analyze it.

Prior Art Cited in US10121186:

The patent US10121186 B2 lists the following "Priority claimed from" patents, which are generally considered prior art to the current patent:

1. US9430794B2

   • Full Citation: US9430794B2, titled "Unified input search field for making purchases", inventors Thomas M. Isaacson and Ryan Connell Durham.
   • Publication/Filing Date: The priority date for US10121186B2 is 2014-03-31, and US9430794B2 is listed as a priority claim from US14/230,864, which also shares the 2014-03-31 priority date. The publication date of US9430794B2 is September 6, 2016.
   • Brief Description: This patent describes a system and method for a unified input search field that allows a user to perform searches and make purchases from various websites with fewer interactions. It anticipates the idea of dynamically presenting options (like one-click purchase buttons or specific site searches) based on user input, and streamlining the process of transitioning to external sites in a pre-configured state to complete actions such as purchasing.
   • Potentially Anticipates Claim(s) under 35 U.S.C. § 102: This patent likely anticipates a significant number of claims related to the unified input field, intent determination (search vs. purchase), dynamic presentation of options, and streamlined transitions to merchant or search sites with pre-filled information. Specifically, claims related to receiving user input in a generalized search field, determining user intent (search or purchase), presenting purchase options (e.g., buy buttons), and facilitating one-click purchases or pre-filled forms on destination sites are potentially anticipated.

2. US9361638B2

   • Full Citation: US9361638B2, titled "System and method of using an application programming interface for making payments", inventors Thomas M. Isaacson and Ryan Connell Durham.
   • Publication/Filing Date: This patent claims priority from US14/672,876, with a priority date of 2015-03-30. The publication date of US9361638B2 is June 7, 2016.
   • Brief Description: This patent focuses on the use of an Application Programming Interface (API) to facilitate payments, particularly for enabling one-click or fewer-click purchasing experiences by communicating payment data between a browser or agent and a merchant site. It describes the use of an API to retrieve and transmit payment data, address data, and other user information to pre-fill forms and simplify the purchase process.
   • Potentially Anticipates Claim(s) under 35 U.S.C. § 102: This patent likely anticipates claims related to the browser payment request API, automatic population of payment fields, and simplifying the purchasing process by reducing user interaction for entering payment or address data. Claims addressing the method of receiving a request for payment data via an API, transmitting payment data via an API, and enabling a site to process a payment without manual entry are potentially anticipated.

3. US9824408B2

   • Full Citation: US9824408B2, titled "System and method of managing purchases across multiple sites", inventors Thomas M. Isaacson and Ryan Connell Durham.
   • Publication/Filing Date: This patent claims priority from US15/263,057, with a priority date of 2016-09-12. The publication date of US9824408B2 is November 21, 2017.
   • Brief Description: This patent introduces the concept of a purchase management engine that receives conversion data about purchases made through various "buy buttons" on different sites (e.g., Google, Facebook, Amazon) and correlates this data into a single user account. This account spans multiple purchasing platforms, allowing users to manage their purchases across disparate sites from a unified interface.
   • Potentially Anticipates Claim(s) under 35 U.S.C. § 102: This patent likely anticipates claims concerning the management of user purchase history across multiple, disparate merchant sites, the use of an API to gather purchase data from different platforms, and presenting a consolidated view of purchases to the user. Claims related to a "purchase management engine" and coordinating actions (like cancellations, reorders, tracking) across multiple platforms are potentially anticipated.

It is important to note that all three of these prior art documents share at least one inventor (Thomas M. Isaacson and Ryan Connell Durham) with US10121186B2. Under 35 U.S.C. § 102(b)(1)(A), a disclosure made within one year or less before the effective filing date of a claimed invention is not prior art if the disclosure was made by the inventor or a joint inventor, or by another who obtained the subject matter disclosed directly or indirectly from the inventor or a joint inventor. However, without further information on the specific filing dates of the claims within US10121186B2 relative to the publication/filing dates of these prior art documents, it's not possible to definitively determine if this exception applies to all claims. For the purpose of this analysis, they are considered prior art as they were cited as "Priority claimed from."

US Patent 10121186, titled "System and method of using a browser application programming interface for making payments," concerns innovations aimed at simplifying online purchases, improving Internet navigation, and unifying search functionalities. The effective prior art date for this patent is March 31, 2014 [cite: "Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.) 2014-03-31"]. A person having ordinary skill in the art (PHOSITA) in this field, at the time of the invention, would be a software engineer or developer knowledgeable in e-commerce, web browser technologies, and online payment systems.

The patent itself identifies several existing technologies and problems that its innovations seek to address, which serve as foundational implicit prior art for this obviousness analysis.

Identified Prior Art (from the patent's own description):

1. Amazon.com one-click purchasing: A system enabling users to make purchases without manually re-entering payment and address data within the Amazon.com ecosystem. [cite: "Some sites like Amazon.com provide a “one-click” purchasing option but those simplifications are only available in the controlled Amazon.com environment."]
2. Safari's omnikey feature: A browser functionality allowing users to type a query like "amazon headphones" into the browser's input field to directly search a specified third-party site (e.g., Amazon.com) for the given terms. [cite: "One effort to make this transition was provided by the omnikey feature of Safari."]
3. General browser input/search fields: Standard web browsers with input fields in the header for searching the Internet, often configurable with a default search engine (e.g., Google, Yahoo). [cite: "browsers often have input fields in the header portion which can be used for searching the Internet. Users can select whether a default search engine for that input field is google.com, yahoo.com or other search engine."]
4. Deep linking: The practice of linking to specific content within a website or application, rather than just the homepage. This was a known web development technique to improve user navigation.
5. Buy buttons on non-merchant sites: Features on social networking sites (e.g., Google, Facebook, Instagram) or other non-merchant platforms that allow users to initiate purchases directly from those sites. [cite: "buttons on such sites as google.com, facebook.com, instagram.com, say.com, bing.com, yahoo.com, youtube.com, amazon.com and twitter.com a specific challenge arises in terms of tracking purchases.", "the goal of buy buttons on various sites is to enable purchases in those “micro-moments” when a person using social media such as Facebook or Instagram, and see something they might want to buy."]
6. Online payment services (e.g., PayPal, Apple Pay): Established platforms for processing electronic payments, often providing APIs for integration with third-party merchants. [cite: "an interface with PayPal® or Apple Pay is provided such that purchases can be easily processed."]
7. Storage of user payment data by online entities: Sites like Google.com maintain user purchase information, including credit card details. [cite: "sites like google.com maintain purchase information such as credit card or payment account information."]
8. Contextual advertising and user intent determination: Search engines and ad platforms analyze user queries and behavior to infer whether the user has informational intent (e.g., "Paul Revere American revolution") or commercial/purchase intent (e.g., "iPhone 5S 32 GB silver") and deliver relevant content or advertisements.
9. Centralized purchase history: Services like Amazon.com provide users with an account to view and manage their purchase history, albeit limited to their own platform. [cite: "The ability to manage a user account and history of purchases on such a site is considerably easier."]

Obviousness Combinations

1. Browser Payment Request API for Generalized One-Click Purchasing via Deep Links

Claimed Invention (exemplary elements): A method including receiving an interaction from a user with an object (e.g., buy button) on a first site presented within a browser, transitioning the user from the first site to a destination merchant site in a deep link state, where the deep link state enables the user to purchase a product via an interaction with a purchase object without manually entering payment account data or user address data. The method further involves retrieving data from the browser automatically via a browser payment request application programming interface (API) between the destination merchant site and the browser. [cite: "a method aspect includes receiving an interaction from a user with an object associated with an advertisement for a product or any kind of notice, the advertisement or notice being presented via a first site presented within a browser, and transitioning the user from the first site to a destination merchant site in a deep link state.", "the transitioning process includes retrieving data from the browser and using the data from the browser to enable the user to transition from the first site to the destination merchant site in the deep link state.", "the deep link state enables the user to purchase the product via an interaction with a purchase object without manually entering payment account data or user address data.", "Retrieving data from the browser can occur automatically via a browser payment request application programming interface between the destination merchant site and the browser."]

Combination of Prior Art:

• Amazon.com one-click purchasing (Primary Reference): Teaches the core concept of purchasing with minimal interaction (e.g., one click) by leveraging stored user payment and address data. [cite: "Some sites like Amazon.com provide a “one-click” purchasing option but those simplifications are only available in the controlled Amazon.com environment."]
• Buy buttons on non-merchant sites (Secondary Reference 1): Teaches initiating a purchase intention from a "first site" (e.g., a social media ad or a search result with a buy option). [cite: "buttons on such sites as google.com, facebook.com, instagram.com, say.com, bing.com, yahoo.com, youtube.com, amazon.com and twitter.com a specific challenge arises in terms of tracking purchases."]
• Deep linking (Secondary Reference 2): A known technique for directing users to specific pages within a website, enabling a "deep link state" to a product page.
• Browser autofill/storage of user data (Secondary Reference 3): Browsers already had capabilities to store and autofill user information, including address and payment details, in web forms.
• Online payment services and their APIs (e.g., PayPal, Apple Pay) (Secondary Reference 4): These services demonstrated the use of APIs for secure transfer of payment information to facilitate online transactions. [cite: "an interface with PayPal® or Apple Pay is provided such that purchases can be easily processed."]

Motivation to Combine: A PHOSITA would be motivated to extend the convenience of Amazon's one-click purchasing beyond its proprietary ecosystem, as the patent itself highlights this limitation [cite: "Some sites like Amazon.com provide a “one-click” purchasing option but those simplifications are only available in the controlled Amazon.com environment."]. Recognizing that users frequently encounter purchase opportunities on "first sites" (e.g., social media feeds or search results) that are not the final merchant destination, a PHOSITA would seek to streamline the transition to a merchant site for purchase. It would be obvious to combine the initiation of a purchase from a "first site" (like a buy button on Facebook) with deep linking to take the user directly to the relevant product page on the merchant site. To achieve a true "one-click" experience on the destination site, it would be a predictable extension to leverage user data already stored or accessible by the browser (like autofill data or through a browser extension) and transfer this data securely using a browser payment request API. Such an API would be an obvious development given the existence of general web APIs for data exchange and specialized payment APIs (like PayPal's), aiming to standardize and simplify the process of populating payment fields or directly processing payments. This combination would predictably reduce user friction and improve conversion rates for online purchases initiated from various "first sites."

2. Unified Input Field with Purchase Intent Determination

Claimed Invention (exemplary elements): A method including presenting an input field on a user interface of a generalized search entity, receiving user input (a text-based query), correlating the query with a product database, determining if the user input is associated with a search intent or a purchase intent, and presenting a purchase-related search result comprising a buy option associated with the user input, or a search result including a non-merchant site. [cite: "a method includes presenting an input field on a user interface of a generalized search entity, such that the generalized search entity processes data using a generalized search engine.", "the search engine indexes and searches both merchant sites and non-merchant sites and receives user input in the input field", "the user input includes a text-based query", "the search engine correlates the text-based query with a product database of products for sale from merchants to produce a correlation.", "a determination is made that the user input is associated with one of a search intent and a purchase intent.", "a purchase-related search result comprising a buy option associated with the user input is presented."]

Combination of Prior Art:

• General browser input/search fields and search engines (Primary Reference): Teaches accepting user input for search queries and returning results (e.g., Google, Yahoo). [cite: "browsers often have input fields in the header portion which can be used for searching the Internet. Users can select whether a default search engine for that input field is google.com, yahoo.com or other search engine."]
• Safari's omnikey feature (Secondary Reference 1): Teaches using a single input field to target searches to specific third-party sites based on explicit user input (e.g., "amazon headphones"). [cite: "One effort to make this transition was provided by the omnikey feature of Safari."]
• Contextual advertising and user intent determination (Secondary Reference 2): Search engines and advertising platforms were already proficient at analyzing user queries to infer whether the user has informational intent (e.g., "Paul Revere American revolution") or commercial/purchase intent (e.g., "iPhone 5S 32 GB silver") and displaying relevant ads or product listings.
• Dynamic presentation of options/autocomplete (Secondary Reference 3): Autocomplete features in search bars and dynamic menus that appear as a user types were common, presenting suggestions or alternative actions.

Motivation to Combine: A PHOSITA would be motivated to enhance the efficiency and intelligence of generalized search fields, particularly in the context of e-commerce. Recognizing the limitations of existing browser search fields (e.g., needing explicit prefixes like in Safari's omnikey, or defaulting to a single search engine) [cite: "the problem with this approach is that it is likely easier to click on an amazon tab and type headphones in the Amazon search field than it is to type amazon at the beginning of the search."], it would be obvious to integrate advanced intent determination. By combining a general input field with the existing capability of search engines to determine user intent (search vs. purchase) based on query semantics, and the ability to present dynamic options (e.g., in a drop-down menu or autocomplete list) based on that intent, the system could directly link to either a general search result or a purchase-ready option on a merchant site (potentially using deep linking and one-click concepts). This combination would predictably provide a more user-friendly and efficient experience, allowing users to move from initial query to desired action (information retrieval or product purchase) with fewer steps and greater relevance.

3. Cross-Site Purchase Management Engine

Claimed Invention (exemplary elements): A purchase management engine receiving conversion data about purchases made through various buy buttons (e.g., Google Buy Button, Facebook Buy Button, Amazon.com purchases) and correlating this data into a single user account that spans multiple purchasing platforms. [cite: "an API that is designed to communicate information to and from multiple different types of sites that currently manage purchases individually.", "the API can receive conversion data about purchases made through the Google Buy Button (Purchases on Google), the Facebook Buy Button, the Pinterest Buy Button, Amazon.com purchases, and so forth.", "a purchase management engine receives the various pieces of data and correlates the data into a single user account that spans multiple purchasing platforms."]

Combination of Prior Art:

• Centralized purchase history (Amazon.com) (Primary Reference): Teaches the concept of a user account managing purchase history, returns, reorders, etc., but limited to a single merchant. [cite: "The ability to manage a user account and history of purchases on such a site is considerably easier."]
• Buy buttons on non-merchant sites (Secondary Reference 1): Teaches that purchases can originate from numerous distinct online platforms, leading to dispersed purchase records. [cite: "buttons on such sites as google.com, facebook.com, instagram.com, say.com, bing.com, yahoo.com, youtube.com, amazon.com and twitter.com a specific challenge arises in terms of tracking purchases.", "the goal of buy buttons on various sites is to enable purchases in those “micro-moments” when a person using social media such as Facebook or Instagram, and see something they might want to buy."]
• APIs for data sharing between services (Secondary Reference 2): Teaches that disparate online services can exchange data (e.g., user activity, transaction details) via application programming interfaces.
• Centralized user accounts for online services (Secondary Reference 3): Major online platforms (Google, Facebook) offer central user accounts that aggregate user data and activity across various affiliated services.

Motivation to Combine: A PHOSITA would be motivated to address the "difficulty of managing purchases spread across uncoordinated, disparate sites" [cite: "presenting buy options at non-merchant sites to take advantage of such micro-moments introduces the difficulty of managing purchases spread across uncoordinated, disparate sites."]. Recognizing the growing number of ways users can make purchases online (e.g., via buy buttons on social media, direct merchant sites), and the user frustration associated with fragmented purchase histories [cite: "A user may forget where a purchase was made and may feel frustrated when they cannot manage purchases or review their purchase history."], it would be obvious to develop a centralized management solution. This would involve extending the known concept of a single-merchant purchase history (like Amazon's) and leveraging existing APIs for data exchange to gather "conversion data" from various independent purchase sources (e.g., Google Buy Button, Facebook Buy Button, Amazon.com). Aggregating and correlating this data into a single, unified user account is a common pattern in data aggregation and dashboard development, making it a predictable application of known techniques to solve a well-identified problem in user experience. The patent explicitly states its aim to solve the problem of managing purchases across "uncoordinated, disparate sites" and creating a "single user account that spans multiple purchasing platforms." [cite: "the present approach differs from the amazon.com user account because it is maintained only for purchases made at amazon.com and not for purchases from different types of sites such as google.com or facebook.com."]