Patent claim charting has always rewarded the same thing: getting from a claim to a defensible, evidence-backed answer about what that claim covers, without either overstating the evidence or missing what it actually shows. Whether the objective is an infringement read, a validity challenge, or a freedom-to-operate opinion, the underlying task is the same. A claim gets broken into limitations, and each limitation needs a piece of evidence behind it before anyone can rely on the result.
AI has changed how quickly that mapping gets done. It has not changed what makes a chart usable. This article works through what that distinction looks like in practice, using the same patent, the same claim, and the same product run twice: once through a general-purpose AI assistant with no connected patent data, and once through that same kind of assistant connected to a live patent database through the Model Context Protocol.
What a claim chart is, and why the type matters more than the format
A claim chart maps the individual limitations of a patent claim to corresponding evidence. The underlying exercise across every chart type remains largely the same, claim charting, mapping claim language to evidence, but the legal question being asked of that evidence changes with the format:
- Evidence of use. The claim mapped against a specific product, to determine whether the product practices the claimed technology.
- Invalidity. The claim mapped against prior art, asking whether a single reference discloses every limitation, expressly or inherently, arranged as the claim requires.
- Freedom to operate. A product or planned implementation checked against live, enforceable claims that could block it, a forward-looking risk question rather than a single infringement read.
- Essentiality. The claim mapped against a technical standard, for FRAND licensing purposes.
The rest of this piece works through an evidence-of-use chart specifically, since that is the type most directly tied to the manual mapping burden every practitioner already knows: gathering documentation, checking it against each limitation, and building a record someone else can independently verify.
What a general AI assistant produces without a connected data source
To make the comparison concrete, we asked ChatGPT, with no connected patent database, to build an evidence-of-use chart for claim 1 of U.S. Patent 5,960,411, Amazon's well-known "single action" ordering patent, against Amazon's own 1-Click ordering feature. The same patent and claim are used in the connected example further down, so the two runs are directly comparable.
The response deserves credit before it deserves scrutiny. It correctly identified the patent as expired, citing Google Patents. It introduced its own hierarchy for weighing evidence, ranking Amazon's own product documentation above court testimony, above a press release, above the patent specification itself. Two of the ten limitations were flagged in the prose as needing further technical support rather than presented as settled alongside the rest.
Prompt: "Build an evidence-of-use claim chart for claim 1 of US Patent 5,960,411 against Amazon's 1-Click ordering feature."
Full response:
"Yes. Below is a public-evidence-based evidence-of-use (EoU) claim chart for claim 1 of U.S. Patent No. 5,960,411 against Amazon's 1-Click ordering functionality.
One important qualification: U.S. Patent No. 5,960,411 expired in 2017, so this is an evidence-of-use/technical mapping exercise, not a current infringement opinion. Google Patents lists the patent as 'Expired, Lifetime.'"
| Claim 1 limitation | Evidence of use in Amazon 1-Click | Assessment |
|---|---|---|
| 1. "A method of placing an order for an item comprising:" | Amazon's 1-Click functionality is expressly described as a method for ordering products through Amazon. Amazon's own 1999 announcement states that 1-Click allows a customer to buy a selected item with one mouse click rather than repeatedly entering billing and shipping information. | Strong |
| 2. "under control of a client system, displaying information identifying the item" | Amazon's product-detail page displays information about the particular product. A contemporaneous judicial description of Amazon's 1-Click system explains that a user navigates to a product-detail page containing information about the product and an option to "buy now with 1-Click." | Strong |
| 3. "in response to only a single action being performed, sending a request to order the item...to a server system" | Amazon's 1-Click interface is specifically designed so that selecting the "Buy now with 1-Click" button initiates the ordering process. Amazon documentation states that Buy Now allows customers to place orders "with a single click of a button." A contemporaneous court record likewise states that choosing "buy now with 1-Click" initiates the product ordering and shipping process. | Strong |
| 4. "...along with an identifier of a purchaser of the item to a server system" | The technical architecture described for Amazon's 1-Click system uses the customer's Amazon account/customer information to associate the order with the purchaser. The patent itself describes the mechanism as sending an identifier that allows the server to locate the purchaser's previously stored information. A contemporaneous technical description of Amazon's implementation states that customer information was maintained in an Amazon server database and did not need to be entered at the time of purchase. | Strong, but source-code-level proof would strengthen it |
| 5. "under control of a single-action ordering component of the server system," | Amazon's 1-Click architecture includes server-side functionality that processes the single-action purchase request and uses stored customer information. The patent specification describes this architecture in detail, and Amazon's 1-Click implementation was the technology for which Amazon obtained the patent. | Strong |
| 6. "receiving the request;" | The court's description of the actual 1-Click operation states that selecting "buy now with 1-Click" initiates the ordering process. The request necessarily reaches Amazon's server-side ordering infrastructure to initiate the order. | Strong |
| 7. "retrieving additional information previously stored for the purchaser identified by the identifier in the received request;" | This is one of the clearest limitations. Amazon's 1-Click system relies on previously stored payment and shipping information. Amazon's documentation states that Buy Now associates a payment method with frequently used shipping addresses so an order can be placed with a single click. Amazon's own 1999 announcement similarly states that 1-Click securely stores billing and shipping information. | Very strong |
| 8. "generating an order to purchase the requested item for the purchaser identified by the identifier in the received request using the retrieved additional information;" | Amazon's documentation states that when the "Buy now with 1-Click" button is selected, the order is automatically charged to the account's default payment method and shipped to the default address. This demonstrates use of stored purchaser information to generate/process the purchase order. | Very strong |
| 9. "and fulfilling the generated order to complete purchase of the item" | Amazon's 1-Click process includes arranging shipment to the customer's default address. The contemporaneous court record states that after selection, the order is placed into a holding state and, if not cancelled, is finalized and shipped to the address registered for 1-Click. Amazon documentation likewise states that the order is automatically charged and shipped to the default address. | Very strong |
| 10. "whereby the item is ordered without using a shopping cart ordering model." | This is another particularly strong limitation. The court record expressly describes Amazon's 1-Click as a streamlined ordering process distinct from the shopping-cart process. The patent itself characterizes the claimed process as ordering without a shopping cart. | Very strong |
Overall mapping (as returned): Display item, Strong. Single action, Strong. Purchaser identifier, Strong*. Server receives request, Strong. Server retrieves stored purchaser information, Very strong. Generates order using stored information, Very strong. Fulfills order, Very strong. Without shopping cart, Very strong. Overall claim 1: Strong public-record mapping.
"*The purchaser-identifier/request mechanism is the element for which I would want additional technical evidence, for example historical Amazon source code, patent prosecution/reexamination materials, technical documentation, or discovery evidence, if this were being prepared for litigation rather than a preliminary EoU analysis.
Why this is an unusually strong EoU example. There is something important here that makes this particular chart different from a typical third-party EoU exercise: Amazon itself was the assignee and developer of the patented 1-Click technology.
The patent's abstract describes essentially the same architecture: a client receives an identifier associated with purchaser information; the user selects an order button; the server receives the request; the server combines the stored purchaser information with the requested item; and an order is generated using the billing and shipping information.
Amazon's own 1999 announcement also explicitly identified the patented technology as 1-Click, explaining that it stored billing and shipping information so a customer could buy a selected item with one click.
There is also contemporaneous litigation evidence describing the actual operation of Amazon's 1-Click system. The court record explains that the customer selected 'buy now with 1-Click' from the product page, that the feature used the customer's registered information, and that the resulting order was ultimately finalized and shipped to the registered address.
Key evidence hierarchy. For a professional EoU chart, I would rank the evidence approximately as follows: Amazon's own technical/product documentation, strongest for what the feature does. Contemporaneous court testimony/exhibits describing actual 1-Click operation, very strong. Amazon's 1999 press release identifying 1-Click and describing its operation, strong. The '411 patent specification itself, useful corroborating evidence, but I would not rely on the patent alone to prove infringement/use by the accused system. Third-party descriptions, useful corroboration, but lower priority.
Important EoU caveat. I would not mark every limitation simply 'Yes' based solely on the marketing language if this were going into a litigation-grade claim chart. In particular, I'd flag 'sending a request...along with an identifier of a purchaser' and 'single-action ordering component of the server system' for additional technical corroboration. The public evidence strongly indicates that Amazon's server identifies the customer and retrieves stored account information, but a litigation-quality chart should ideally show the actual data flow, for example what identifier/cookie/account token is transmitted from the client, how Amazon resolves that identifier to the account, and how the server-side ordering component uses that information. Also, because the patent expired in 2017, the chart should be labeled something like 'Historical Evidence-of-Use Mapping' rather than 'current infringement chart.'
Bottom line. Claim 1 maps remarkably closely to Amazon's 1-Click functionality. On the publicly available evidence, I would preliminarily characterize all limitations as having strong or very strong evidence of use, with the purchaser-identifier/server-component limitations deserving additional technical evidence before being treated as conclusively proven.
For an actual patent-practice workflow, the next step would be to turn this into a litigation-grade chart with columns for: claim limitation → claim construction → accused product feature → exact evidence/quotation → source URL → date → evidence type → mapping rationale → confidence → evidence gap. That format is much more useful than a simple 'Yes/No' EoU chart."
Three specific gaps separate this answer from something an attorney could actually build on, and each one is a matter of what the chart can and cannot support, not a matter of tone.
The evidence is described, not shown
Every source in the response is only described, not linked. It mentions Amazon's 1999 announcement, a court record, and Amazon's product documentation, but gives no actual citations.
That matters because a claim chart should be easy for someone else to check. Simply saying that a source exists is not enough. If a reader cannot open and verify the source, it is not strong evidence.
Courts have already seen cases where AI-generated filings included made-up citations to cases that did not exist. The response here did not do that, but the basic lesson is the same: citations should be verifiable, not just confidently described.
Two problems with the claim chart
The response checked the patent's expiration date but did not check the claim's full history. It missed the 2006 to 2010 reexamination, which could have changed the scope of the "without a shopping cart" limitation.
It also says that two limitations need more evidence, but still rates both as Strong in the summary table. This can mislead a reader, especially an attorney who looks at the table first.
The Same AI, Now Connected to IP Author Through MCP
IP Author's evidence of use assistant connects to the same kind of AI assistant, Claude or ChatGPT, through the Model Context Protocol, an open standard that lets the assistant query a live, curated patent database rather than reason from what it already knows. A fair question is why that matters more than simply pointing a general assistant at public sources like the USPTO or Google Patents directly. The difference is preparation. A public search interface returns documents. A curated database has already resolved assignee names, legal status, and classification codes, and added the context needed to answer a plain-language question with a usable, deduplicated result rather than a set of records still waiting to be sorted by hand.
Once the connector is authorized, running the equivalent request takes the same shape: name the patent, name the claim, point to the product.
Because the patent and the product in this example belong to the same company, the analysis is a self-referential exercise, a standard way to test whether a claim reads on a real implementation of the invention it describes, rather than an infringement accusation. The result below is interactive as it came back: filterable by verdict, with the reasoning and sourcing behind every row available on expansion.
Reading the two results against each other
| ChatGPT, no connected source | Connected to IP Author MCP | |
|---|---|---|
| Source citations | Described by name and date, not linked | Each verdict traces to a specific, working link |
| Handling a dead link | No mechanism to detect one; sources are asserted, not fetched | Detected an actual 404, disclosed the substitution |
| Where the uncertainty lives | In prose only; the scored table reads Strong throughout | On the verdict itself, Present, Unclear, or Absent |
| Claim-history awareness | Caught the 2017 expiration; the 2006 to 2010 reexamination went unmentioned | Flagged both the expiration and the reexamination's tension with the granted claim language |
| What a colleague can independently check | A well-organized set of assertions | A chart with a link and a reason behind every row |
Why One Connected Workflow Is Better
The value of a connected setup goes beyond a single search. Today, patent work often requires multiple tools: one for prior art, another for prosecution history, another for product evidence, and another for standards. A single matter can involve ten or more tools. Every time information moves from one tool to another, someone has to copy and paste it, making it easier to lose the connection between the evidence and its original source.
A connected setup removes those handoffs. In this example, the evidence-of-use chart, prosecution history review, and prior-art search can all happen in the same conversation. Each step builds on the previous one without requiring the user to repeatedly explain which patent or claim they are working on. This continuity also helped uncover the reexamination issue: the assistant could immediately follow up using the patent's actual prosecution history because the patent was already part of the conversation.
There are also two important benefits for law firms. First, the connection is not locked to one AI vendor. Because the Model Context Protocol is an open standard, the same patent data connection can work with Claude, ChatGPT, or another compatible AI assistant. Second, individual tool calls can be logged, not just the final answer. That gives firms a way to see how the chart was built and where the evidence came from, which is important when they need to review or defend the work later.
Conclusion
Generic AI tools can create claim charts that look confident and well researched. But the evidence still needs to be checked. And if a citation cannot be checked, it should not be treated as solid evidence.
Connecting AI to live patent data through MCP, like IP Author's, helps close that gap. For patent attorneys, it gives the AI better evidence to work with and makes it easier to trace the final verdict back to the source.
Want to see how this works on one of your own matters? Book a demo with IP Author and bring a real patent to the call.