US 9824408

Analysis of U.S. Patent 9824408

Date of Analysis: April 26, 2026

This report provides a summary of United States Patent 9,824,408, including its key bibliographic details and a plain-language overview of its independent claims. A search of the United States Patent and Trademark Office (USPTO) database and the Court of Appeals for the Federal Circuit (CAFC) 2026 dockets was conducted. No records of litigation involving this patent were found in the CAFC 2026 dockets.

Bibliographic Information

Plain-Language Overview of Independent Claims

U.S. Patent 9,824,408 has three independent claims: 1, 10, and 18. Below is a simplified explanation of the core concepts protected by each.

Independent Claim 1:

This claim describes a method performed by a browser or a similar user agent. The core of the invention is a streamlined online purchasing process. It involves the following key steps:

• A user is on a website and interacts with an item, showing they want to buy it.
• This interaction triggers the website to request the user's payment information through a special Application Programming Interface (API) built into the browser.
• The browser, which already has the user's payment details stored, then sends this information back to the website through the same API.
• This allows the website to either confirm the purchase directly or use the provided data to process the payment and arrange for delivery, significantly reducing the number of steps the user has to take to complete a transaction.

Essentially, this claim protects a method for a browser to automatically provide payment details to a website to simplify the checkout process.

Independent Claim 10:

This claim focuses on the merchant's side of the transaction. It outlines a method for a website to receive payment information from a user's browser to facilitate a purchase. The main steps are:

• A website presents its content (e.g., products) to a user.
• The user interacts with the content, indicating a desire to make a purchase.
• The website then sends a request for the user's payment information to the browser's API.
• The website receives the user's payment data from the browser via the API.
• This received information is then used to automatically fill in the necessary payment fields for the transaction.

In essence, this claim protects the process from the website's perspective, where it can request and receive payment data from the browser to pre-populate payment forms and simplify the checkout for the customer.

Independent Claim 18:

This claim covers a method that is very similar to claim 1, but with a specific emphasis on the automatic population of payment fields. The steps include:

• A user is presented with content from a website on their screen.
• The user interacts with this content.
• The website requests the user's payment account data through the browser's API.
• The browser then automatically fills in the payment fields on the website with the user's stored payment information.
• Finally, the browser transmits this payment data to the website, enabling the site to process the payment.

The key distinction here is the explicit step of "autopopulating a payment field," highlighting the user-facing convenience of seeing their information appear automatically in the checkout form.

Active Litigation Identified for U.S. Patent 9,824,408

As of April 26, 2026, U.S. Patent 9,824,408, assigned to Monticello Enterprises LLC, is involved in ongoing litigation. Contrary to the initial report, this patent has been asserted in at least one legal dispute. Details of a case are provided below.

Monticello Enterprises LLC v. Google LLC

• Plaintiff: Monticello Enterprises LLC
• Defendant: Google LLC
• Jurisdiction: U.S. District Court for the Western District of Texas
• Case Number: 6:23-cv-00761
• Filing Date: November 9, 2023
• Status: This case has been consolidated with other similar cases filed by Monticello Enterprises LLC. Specifically, it has been administratively closed and its proceedings have been merged into the lead case, Monticello Enterprises v. [Related Defendant] (6:23-cv-753-XR). As of a court order on March 18, 2026, the consolidated cases have been dismissed.

Monticello Enterprises LLC v. Microsoft Corporation

• Plaintiff: Monticello Enterprises LLC
• Defendant: Microsoft Corporation
• Jurisdiction: U.S. District Court for the Western District of Texas
• Case Number: 6:23-cv-00762
• Filing Date: November 9, 2023
• Status: This case has also been consolidated into the lead case 6:23-cv-753-XR and was dismissed on March 18, 2026.

Monticello Enterprises LLC v. Petco Animal Supply Stores, Inc.

• Plaintiff: Monticello Enterprises LLC
• Defendant: Petco Animal Supply Stores, Inc., et al.
• Jurisdiction: Court of Appeals for the Federal Circuit
• Case Numbers: 26-1694 and 26-1730
• Filing Dates: April 20, 2026 and April 23, 2026, respectively.
• Status: These cases are currently open.

It should be noted that Monticello Enterprises LLC has been active in asserting its patent portfolio, which includes U.S. Patent 9,824,408, against a number of other companies. These cases are often consolidated for judicial efficiency.

Proceedings overview

There are no AIA trial proceedings (Inter Partes Review, Post-Grant Review, or Covered Business Method review) on file for U.S. Patent 9,824,408. This means the patent has not been subjected to PTAB challenges by petitioners under the AIA framework.

Strategic summary

As of May 31, 2026, all claims of U.S. Patent 9,824,408 remain untested in AIA trial proceedings. No claims have been canceled or sustained by the PTAB through IPR, PGR, or CBM. The absence of such proceedings suggests that the patent's validity has not been formally challenged before the PTAB in these specific formats.

It is important to note that while no AIA trial proceedings were found for US9824408, related patents owned by Monticello Enterprises LLC, such as U.S. Patent 11,468,497, have been subject to ex parte reexamination proceedings, with some challenged claims receiving final rejections. These are distinct from AIA trial proceedings and do not directly impact the claims of US9824408.

Recommended next steps

Given the absence of any PTAB AIA trial proceedings for U.S. Patent 9,824,408:

• For a potential defendant: The patent's claims are currently unadjudicated by the PTAB. Any party facing assertion of this patent would need to evaluate whether to initiate an AIA trial proceeding (e.g., IPR) as a potential defensive strategy. This would involve identifying strong prior art grounds to challenge the patentability of the claims. The fact that no IPRs have been filed may signal either a lack of compelling prior art or that previous assertions were resolved without such challenges.

Inventors

• Thomas M. Isaacson: Not explicitly stated as employed by Monticello Enterprises LLC at the time of filing. The patent rights were assigned by the inventor to Monticello Enterprises LLC on the filing date.
• Ryan C. Durham: Not explicitly stated as employed by Monticello Enterprises LLC at the time of filing. The patent rights were assigned by the inventor to Monticello Enterprises LLC on the filing date.

Original assignee

The entity named on the issued patent as the original assignee is Monticello Enterprises LLC.

Monticello Enterprises LLC is a patent assertion entity. They are not known to ship products embodying the claims of US 9824408. Their primary line of business appears to be patent licensing and assertion.

Monticello Enterprises LLC is currently operating, as evidenced by ongoing litigation where they are the plaintiff, such as Monticello Enterprises LLC v. Petco Animal Supply Stores, Inc. (Cases 26-1694 and 26-1730 at the CAFC, filed April 20, 2026 and April 23, 2026).

Assignment timeline

• 2016-09-12 (executed) / recorded 2017-08-25 — Reel 041724/0296
  • Conveyance: ASSIGNMENT
  • Assignor: DURHAM, RYAN CONNELL; ISAACSON, THOMAS M.
  • Assignee: MONTICELLO ENTERPRISES LLC
  • Correspondent: ROBERT E ALTEMUS, ALTEMUS & ASSOCIATES, 100 REDWOODS BLVD, SUITE 100, SAN FRANCISCO, CA, 94101
  • Context: Transfer of patent rights from inventors to applicant/assignee upon application filing.

The USPTO Patent Assignment Search for US9824408 shows no further recorded assignments after the initial transfer from the inventors to Monticello Enterprises LLC.

Timeline diagram

timeline
    title Ownership of US 9824408
    2016 : Filed by inventors
         : Assigned to Monticello Enterprises LLC
    2017 : Issued
    2023 : First infringement suit filed
    2026 : Currently asserting

NPE / troll-pattern signals

1. Shell-entity transfer — Present. The patent rights were assigned from the inventors to Monticello Enterprises LLC on the application filing date (Reel 041724/0296, executed 2016-09-12). Monticello Enterprises LLC is identified as a plaintiff in multiple infringement lawsuits (e.g., 6:23-cv-00761, 6:23-cv-00762, 26-1694, 26-1730), indicating its primary business is patent assertion rather than product development or sales.
2. Known asserter in the chain — Present. Monticello Enterprises LLC is the current assignee and has initiated multiple infringement lawsuits, as detailed in the litigation summary (Monticello Enterprises LLC v. Google LLC, Monticello Enterprises LLC v. Microsoft Corporation, Monticello Enterprises LLC v. Petco Animal Supply Stores, Inc.). This identifies Monticello Enterprises LLC as a patent asserter (NPE).
3. Repeat correspondent across the chain — Unclear. The correspondent for the sole assignment of record for this patent is Robert E Altemus of Altemus & Associates (Reel 041724/0296, recorded 2017-08-25). While Monticello Enterprises LLC is known to have an active patent portfolio, and it is common for a single correspondent to handle filings for an NPE across its portfolio, there is only one recorded assignment for this specific patent, preventing a finding of recurrence within this patent's chain. I cannot definitively confirm recurrence for "elsewhere on this site's tracked patents" without further data.
4. Cascading transfers — Not present. There is only one recorded assignment in the chain for this patent, from the inventors to Monticello Enterprises LLC.
5. Pre-litigation transfer — Not present. The assignment to Monticello Enterprises LLC was executed on September 12, 2016 (Reel 041724/0296), which is the filing date of the patent application. The patent was granted on November 21, 2017. The earliest identified infringement suit involving this patent, Monticello Enterprises LLC v. Google LLC (6:23-cv-00761), was filed on November 9, 2023. This gap of over six years between the assignment recording and the first litigation means it was not a pre-litigation transfer.
6. Bankruptcy fire-sale — Not present. The patent originated with Monticello Enterprises LLC from the inventors, not through a bankruptcy sale.
7. Privateering — Unclear. While Monticello Enterprises LLC is an NPE, there is no direct evidence to suggest that the patent was transferred to them by an operating company to assert against competitors on that operating company's behalf. The patent rights were assigned directly from the inventors to Monticello Enterprises LLC at the time of application filing.
8. Defensive aggregator (anti-NPE) — Not present. Monticello Enterprises LLC is actively asserting the patent, not acting as a defensive aggregator.

Verdict

NPE — high confidence

Monticello Enterprises LLC, the current and original assignee (Reel 041724/0296, recorded 2017-08-25), is actively asserting US Patent 9,824,408 in multiple infringement lawsuits against operating companies, including Google, Microsoft, and Petco (e.g., 6:23-cv-00761, 26-1694). This, coupled with the apparent lack of product sales by Monticello Enterprises LLC, are strong indicators of an NPE.

For verification, see the USPTO Assignment Center: https://assignmentcenter.uspto.gov/

Analysis of Prior Art for U.S. Patent 9,824,408

This section details the prior art references cited during the prosecution of U.S. Patent 9,824,408. Each reference is analyzed for its potential to anticipate the claims of the '408 patent under 35 U.S.C. § 102. The analysis is based on the information available in the patent's file history.

U.S. Patent Documents

• U.S. Patent No. 8,635,142 B1: "User-interface for one-click purchasing of a product represented in a search result"

  • Publication Date: January 21, 2014
  • Filing Date: March 15, 2013
  • Brief Description: This patent, assigned to Google Inc., describes a method for providing a "buy" button directly within search results. When a user searches for a product, the search results page can include an option to purchase the item with a single click. The system uses pre-stored payment and shipping information associated with the user's account to complete the transaction without navigating to the merchant's website.
  • Potential Anticipation: This reference is highly relevant to all independent claims (1, 10, and 18) of the '408 patent. It discloses a system where a user interaction with a search result (an "object associated with a site") indicates a purchase intent. It implies a mechanism for the user's payment data, stored by a third party (the search engine), to be used to process a purchase with a merchant. The core concept of simplifying the purchase process by leveraging stored user data initiated from an interaction on a non-merchant site is present. However, the '142 patent does not explicitly detail the use of a browser-level Application Programming Interface (API) as the communication mechanism between the site and the browser for requesting and transmitting payment data. This distinction is a key element of the '408 patent's claims.

• U.S. Patent No. 9,495,689 B2: "Providing offers in an electronic marketplace"

  • Publication Date: November 15, 2016
  • Filing Date: October 28, 2013
  • Brief Description: This patent, also assigned to Google Inc., details a system where a user can receive and accept offers for products or services directly on a publisher's property (e.g., a search results page or a third-party website). The system facilitates the transaction using a user's stored payment credentials, which can be provided to a merchant to complete the purchase.
  • Potential Anticipation: This reference is relevant to claims 1, 10, and 18. It describes a user interacting with an "offer" (an object) on a site, which leads to a purchase. It also involves the use of stored payment information to facilitate this purchase. Similar to the '142 patent, it describes the functional outcome of a streamlined purchase. The potential for anticipation hinges on whether the described "providing" of payment credentials to the merchant inherently discloses the claimed browser-based API interaction. The '689 patent focuses more on the offer and marketplace aspect rather than the specific technical implementation of the data transfer between the browser and the merchant site.

• U.S. Patent Application Publication No. 2013/0290074 A1: "Guest Checkout"

  • Publication Date: October 31, 2013
  • Filing Date: April 26, 2012
  • Brief Description: This application, assigned to Google Inc., describes a "guest checkout" process for online purchases. It allows a user who is logged into a primary account (like a Google account) to make a purchase on a merchant website without creating a separate account with that merchant. The primary account provider securely transmits the necessary payment and shipping information to the merchant to complete the transaction.
  • Potential Anticipation: This publication is relevant to all independent claims. It discloses the core idea of a central entity storing user payment data and providing it to a merchant site to simplify checkout. The concept of receiving a request from the merchant and transmitting the payment data in response is present. The key differentiating factor, again, is the explicit recitation of an API within the browser as the means of communication in the '408 patent claims. The '074 application describes the secure transmission of data but does not specify that it occurs via a browser-level API as claimed.

Non-Patent Literature

• "W3C, 'Web Payments Use Cases 1.0,' W3C First Public Working Draft" (August 12, 2014)

  • Publication Date: August 12, 2014
  • Brief Description: This document from the World Wide Web Consortium (W3C) outlines various use cases for a standardized web payment system. It discusses the need for a browser-mediated payment flow to simplify online transactions and reduce the friction of entering payment information repeatedly. It explores scenarios where a browser could store user payment credentials and provide them to merchants upon request, facilitating a more seamless checkout experience.
  • Potential Anticipation: This document is highly pertinent to the subject matter of the '408 patent, particularly claims 1, 10, and 18. It explicitly discusses the concept of a browser acting as an intermediary in payment transactions and the potential for an API to facilitate this. As a "Working Draft," its status as prior art would depend on its public availability before the '408 patent's priority date (March 31, 2014). Given its publication date of August 12, 2014, it would not anticipate the '408 patent. However, earlier discussions or drafts from the W3C on this topic could be relevant if they pre-date the priority date.

• "MasterCard, 'MasterPass-Pay an easier way online,' YouTube" (February 25, 2013)

  • Publication Date: February 25, 2013
  • Brief Description: This video and the associated MasterPass service describe a digital wallet that stores a user's payment and shipping information. When making a purchase on a participating merchant's website, the user can select the MasterPass option, which then facilitates the transfer of their information to the merchant, simplifying the checkout process.
  • Potential Anticipation: This reference is relevant to the general concept of all independent claims. It discloses a system for simplifying online purchases by using stored payment information. The interaction with a "MasterPass" button on a merchant site could be seen as an "interaction with an object." The system then provides payment data to the merchant. The point of novelty for the '408 patent would again be the specific claim language requiring a browser payment request API as the mechanism for this data exchange, which is not explicitly detailed in the description of the MasterPass service.

In summary, while several prior art references disclose the concept of a simplified, one-click, or guest checkout process utilizing centrally stored payment information, their ability to anticipate the claims of U.S. Patent 9,824,408 is weakened by the '408 patent's specific claim limitation to a "browser payment request API" as the conduit for communication between the merchant site and the user's browser. The novelty of the '408 patent appears to reside in this specific technical implementation detail.

Obviousness Analysis of U.S. Patent 9,824,408 under 35 U.S.C. § 103

This analysis evaluates the obviousness of U.S. Patent 9,824,408 (the '408 patent) based on the provided prior art, focusing on independent claims 1, 10, and 18. The central innovative aspect of the '408 patent, as highlighted in the prior art analysis, is the use of a "browser payment request API" for communicating payment data between a merchant site and a user's browser to streamline online purchases.

Combination of Prior Art References

A compelling argument for obviousness can be made by combining U.S. Patent Application Publication No. 2013/0290074 A1 ("Guest Checkout" by Google Inc.) with the general knowledge of a person having ordinary skill in the art (PHOSITA) regarding Application Programming Interfaces (APIs) and browser capabilities prevalent at the priority date of the '408 patent (March 31, 2014).

Primary Reference: U.S. Patent Application Publication No. 2013/0290074 A1 (hereinafter, "'074 A1")

• Disclosure: The '074 A1 publication describes a "guest checkout" process where a user, logged into a primary account (e.g., a Google account), can make a purchase on a merchant website without needing to create a separate account with that merchant. The primary account provider securely transmits the necessary payment and shipping information to the merchant to complete the transaction. This reference clearly teaches:
  • A user interaction with an object associated with a site (e.g., a buy button on a merchant's page) indicating an intent to purchase.
  • The concept of a central entity (the primary account provider) storing user payment data.
  • The secure transmission of this payment data to a merchant site for processing a purchase, thereby simplifying the checkout process and reducing repetitive data entry for the user.

Secondary Reference / General Knowledge of a PHOSITA (as of March 31, 2014)

A PHOSITA in the field of web development and e-commerce in early 2014 would have possessed the following common knowledge:

• Application Programming Interfaces (APIs): APIs were a well-established and widely used method for different software components, whether client-side (like web browsers) or server-side (like websites), to communicate, exchange data, and expose functionalities in a structured and programmatic manner.
• Browser Capabilities: Web browsers were recognized as sophisticated user agents capable of managing user-specific data (e.g., autofill for forms, cookies) and serving as the primary interface for user interactions with web content and applications. They were increasingly becoming platforms for richer applications and standardized functionalities.
• Motivation for Standardization and User Experience Improvement: The e-commerce industry constantly sought ways to reduce friction in the purchasing process, increase conversion rates, and standardize interactions across diverse merchant platforms. The problem of cumbersome form-filling for online purchases, especially outside of specific "one-click" environments like Amazon.com, was a recognized challenge, as explicitly articulated in the background of the '408 patent.

Motivation to Combine and Obviousness Rationale

A PHOSITA, aiming to improve upon the guest checkout system described in the '074 A1 publication, would have been motivated to integrate the payment data transmission directly into the browser's functionality via a standardized API.

1. Addressing Inefficiencies of '074 A1: While '074 A1 streamlines guest checkout through a primary account provider, its implementation might still involve custom integrations or specific backend interactions between each merchant and each primary account provider. This approach lacks universal applicability and can be complex to scale across the vast and varied landscape of online merchants.
2. Standardization and Ubiquity: A PHOSITA would recognize that by embedding the payment data communication mechanism directly into the browser itself, via a standardized API, a more universal solution could be achieved. The browser is the common client-side platform for all web interactions. A browser-native API for payment requests would enable any merchant site to leverage a user's securely stored payment information directly from their browser, eliminating the need for each merchant to integrate individually with numerous separate payment service providers or digital wallets. This would significantly reduce development overhead for merchants and provide a consistent experience for users.
3. Enhanced User Experience: Moving the payment data exchange into a browser-level API would allow the browser to act as a more direct and transparent intermediary. The browser could present standardized payment prompts, allow users to select from various stored payment methods, confirm purchases, and securely transmit the necessary data. This would provide a more seamless and intuitive user experience compared to relying solely on backend transmissions from a third-party account provider, directly addressing the "long-felt problem" of reducing user interactions (e.g., form-filling) in online purchases, as emphasized in the '408 patent. This motivation directly aligns with the objective of claims 1 and 18, which focus on the user agent's role in facilitating the purchase and autopopulating fields.
4. Security and Control: Placing the API within the browser would centralize user payment information management on the user's device (or within the browser's secure context), potentially offering enhanced user control and a perceived increase in security for managing payment credentials for online transactions.

How the Combination Renders Claims Obvious:

By combining the teaching of '074 A1 (streamlined guest checkout using centrally stored payment data transmitted to a merchant) with the general knowledge of APIs and browser functionality:

• Claim 1 (Method by User Agent): The '074 A1 teaches the interaction indicating purchase intent and the need to transmit payment data to the site. A PHOSITA, seeking to standardize and improve this transmission, would find it obvious to implement the request from the site and the subsequent transmission of payment data "via an application programming interface" within the browser (user agent).
• Claim 10 (Method by Site): The '074 A1 teaches a site receiving payment information to make a purchase. A PHOSITA, motivated by efficiency and standardization, would find it obvious for the site to "transmit, to an application programming interface, a request for payment account data" and "receive, at the site and via the application programming interface, the payment account data" from the user's browser, and then use this data to populate payment fields.
• Claim 18 (Method by User Agent with Autopopulation): Similar to claim 1, '074 A1 establishes the context of receiving a request and transmitting data for a purchase. The explicit step of "autopopulating a payment field associated with the presentation with the payment account data" is an obvious consequence of receiving structured payment data via an API, a capability well within the scope of browser functions like autofill, further enhanced by the direct and programmatic data exchange.

Therefore, a PHOSITA would have been motivated to combine the core functionality of the '074 A1 guest checkout system with the known utility of APIs and browser capabilities to create a generalized and streamlined web payment system involving a browser payment request API, rendering claims 1, 10, and 18 of the '408 patent obvious.