Beyond Abstract Ideas: Lessons from Granted Software Patents for Drafting Defensible Software Process Claims
A software method claim may solve a real technical problem and appear innovative, but it can still face eligibility challenges under Alice/Mayo if the claim does not clearly explain the technical mechanism behind the solution. Here is what four of eBay's granted patents reveal about the line between that stronger software claims from weaker ones.
AT A GLANCE
This benchmarking exercise analyzed two exemplary software patent drafts against four granted eBay software patents using a limitation-by-limitation comparison approach. The objective was not to determine validity of any particular application, but to identify recurring drafting weaknesses that can create eligibility challenges under §101. The comparison revealed twelve common software patent drafting pitfalls and provides a practical checklist for improving claim quality and reducing avoidable eligibility issues.
For software inventions directed to similar business or informational concepts, differences in claim drafting can materially affect how the technological implementation and asserted improvement are evaluated under Alice/Mayo.
It is therefore useful to examine the drafting closely without treating any particular drafting pattern as a guarantee of eligibility.
This benchmarking study compares two recent draft applications against four of eBay's own granted software patents covering closely related subject matter - personalization, AI-driven messaging, inventory automation, and data synchronization. The goal is not to relitigate any single draft, but to extract a repeatable, defensible checklist for drafting software process claims that hold up under examination.
The obvious question is where these drafts went wrong on the merits.
The more useful question is what eBay's granted claims do differently, and whether that difference is repeatable.
The comparison highlights recurring software patent drafting pitfalls: the benchmark claims more often describe specific implementation details, such as defined data structures, triggering events, processing steps, or conflict-resolution logic, while the draft claims more often focus on the intended result. That distinction is the throughline of the analysis below. It is a drafting observation, not a categorical statement of §101 law.
THE PROBLEM: WHY SOFTWARE PROCESS CLAIMS GET REJECTED ( COMMON PITFALLS THAT CREATE CHALLENGES FOR SOFTWARE PROCESS CLAIMS )
Since the Supreme Court's 2014 decision in Alice Corp. v. CLS Bank International, patent eligibility for software has turned on a two-step framework - often called the Alice/Mayo test - that every software process claim must survive before it is examined on novelty or obviousness at all.
The Alice/Mayo Framework
Step 1 asks whether the claim falls into a statutory category (process, machine, manufacture, or composition of matter). Nearly every software claim clears this step trivially.
Step 2A, Prong One asks whether the claim recites a judicial exception - an abstract idea, law of nature, or natural phenomenon. The USPTO groups abstract ideas into three buckets that come up constantly in software patents:
- Mathematical concepts
- Certain methods of organizing human activity - fundamental economic practices, managing relationships, commercial or advertising activity
- Mental processes - anything a person could do in their head or with pen and paper
Step 2A, Prong Two asks whether that abstract idea is nonetheless integrated into a practical application - does the claim improve computer functionality itself, apply the idea using a particular machine, or effect a genuine transformation, rather than merely reciting the idea “on a computer”?
Step 2B asks, if the idea is not integrated into a practical application, whether the claim adds an inventive concept - something significantly more than well-understood, routine, conventional activity.
Many software eligibility challenges depend on whether the claim explains enough of the technical implementation or improvement. The issue is often not that the underlying idea lacks value, but that the claim does not provide a clear technical mechanism showing how the computer system achieves the result.
A Practical Lesson from Software Claim Drafting
Alice is the most-cited case in this area, but the framing point worth remembering internally is that eBay itself has been on the sharp end of this exact issue before. The lesson repeated across years of Federal Circuit and USPTO software guidance remains consistent: claim the how, not just the what. Reciting a generic computer performing a familiar business function - “a processor to determine,” “a module to generate,” “an interface to present” - without any technical mechanism is precisely the pattern Alice condemned, and it is the single most common reason software claims fail today.
Where the USPTO Stands Today
The USPTO's 2019 Patent Eligibility Guidance, refined by the 2024 AI Subject Matter Eligibility Guidance Update and further clarified by memoranda issued in August and December 2025, has not changed this core analysis - it has made it more explicit for AI and software claims specifically. Current guidance directs examiners to distinguish between claims that merely “apply it on a computer” and claims that recite a particular technical solution or an improved way of achieving a result. A useful negative example is the Federal Circuit's 2025 decision in Recentive Analytics v. Fox Corp., which held that applying conventional machine learning techniques to a new data environment - without improving the ML technology or computer functioning itself - remains abstract and ineligible, no matter how novel the application.
OUR METHODOLOGY
This benchmarking study compared two draft applications against four eBay patents that were granted covering related, but not deeply technical, software subject matter - chosen because they involve software concepts that commonly raise questions about how technical implementation is expressed in claims, rather than patents anchored in genuinely hard computer science (e.g. novel compression algorithms or cryptographic protocols) where eligibility is rarely contested.
Draft applications reviewed
- Patent Publication X - related to a computer-implemented inventory management interface for representing physical inventory assets in a digital environment.
- Patent Publication Y - related to a network-based system for generating personalized digital interfaces using user-related information and contextual data.
eBay granted benchmark patents reviewed
- US 11,507,984 B2 - Generating personalized banner images using machine learning
- US 12,619,447 B2 - Message personalization for an electromechanical device
- US 11,853,944 B2 - Managed inventory
- US 11,995,705 B2 - Updating of stored item data via a remote computing system
Each draft's independent claims were mapped limitation-by-limitation against the closest analogous eBay claim to identify exactly where technical specificity was present in the granted patent and absent in the draft. The full limitation map and supporting claim text are maintained in the companion benchmarking workbook; the sections below summarize the findings.
CASE A - THE VIRTUAL ASSORTMENT / INVENTORY DRAFT
Patent Publication X claims a system that mirrors a physical storage arrangement containing multiple compartments as a digital interface representing corresponding virtual compartments that a user can browse and use for selecting components.
The core drafting pitfall identified: the claim converts a physical retail process into a digital interface, but does not clearly describe the technical mechanism that improves how the digital system operates.
Representative claim language (Draft, Claim 2):
“...creating, by a processor, a digital interface comprising multiple virtual representations corresponding to physical storage locations; associating inventory data with the virtual representations; and accessing a virtual representation to select and process a component for purchase...”
Two claim limitations illustrate the pattern most clearly.
Real-time synchronization, asserted rather than claimed
Dependent claim 3 recites “updating... the data in said virtual drawer in real-time matching the data in said physical drawer.” Nothing in the claim, and nothing in the specification, describes how that consistency is achieved. Compare this with eBay's US 11,995,705, which claims synchronization as a step responsive to a specific, named technical event:
US 11,995,705, Claim 1 (excerpt):
“...while the client device is disconnected from the remote computing system, performing an operation with respect to the digital item; subsequent to performing the operation, reestablishing... electronic communication with the remote computing system; and in response to reestablishing the electronic communication, synchronizing the operation performed with respect to the digital item with the remote computing system.”
Dependent claim 7 of the same patent goes further, reciting an explicit timestamp-comparison algorithm to resolve conflicts between the two data sources - exactly the kind of concrete mechanism that was never disclosed, let alone claimed, in the draft.
Cosmetic UI as a claimed limitation
Claim 6 of the draft recites “simulating... opening and closing of said virtual drawer.” This is a skeuomorphic animation with no effect on the underlying data operation - the kind of GUI-only limitation that courts have repeatedly found adds nothing technical (see Trading Technologies v. IBG). None of the four eBay benchmarks claim an equivalent “simulate a physical object” limitation as their inventive concept.
A separate, non-101 defect
Independent of the eligibility analysis, claim 21 of the filed application contains a preamble that does not match its own claim body: it recites a computer system “for accessing and using contextual identity information during a law enforcement encounter” before reciting virtual-drawer inventory language. This is very likely a template or copy-paste artifact from an unrelated matter, and it is a straightforward §112(b) indefiniteness problem that a single proofreading pass would have caught before filing.
CASE B - THE PERSONALIZED DIGITAL INTERFACE DRAFT
Patent Publication Y claims a system that receives user-related information through a network-connected device, collects profile information, and uses an artificial intelligence-based processing module to generate a personalized digital interface.
The core §101 pitfall identified: the claim's central inventive element - the AI module - is claimed and disclosed entirely by its output.
Representative claim language (Draft, Claim 1):
“...an artificial intelligence processing module configured to generate personalized features associated with one or more services based on user information and contextual data...”
Reviewing the full specification confirms the defect goes beyond claim drafting into the underlying disclosure. The specification describes the intended function of the AI processing module but does not sufficiently explain the underlying implementation details, such as model architecture, processing methodology, training approach, or technical mechanism used to generate the personalized output. The system architecture diagram (Figure 4) introduces undefined terms - “Companion AI,” a “Parent”/“Child” relationship, “3 Parts” - that are never explained anywhere in the body text, which raises an independent §112(a) enablement concern. And the worked examples throughout the specification (Figures 1 and 5 through 8) show the “AI” performing simple conditional branching on stored flags (“if vegan, show the vegan menu”) - there is no disclosed inference or learning process anywhere in the illustrated embodiments.
Compare this against eBay's US 12,619,447, where the analogous AI-driven personalization limitation specifies both the input structure and the training regime:
US 12,619,447, Claim 1 (excerpt):
“...generating a message... the generating performed by inputting the system information data as a prompt to generative artificial intelligence representative of a plurality of characteristics of the electromechanical device, the generative artificial intelligence trained to analyze the system information data and to output the message that has one or more language characteristics based on the plurality of characteristics of the electromechanical device, wherein the one or more language characteristics are unique to the electromechanical device...”
Dependent claim 12 of the same patent goes a step further and closes the loop between the AI output and the underlying system:
US 12,619,447, Claim 12:
“...receiving, as output from the generative artificial intelligence, an indication of a modification to one or more system settings of the electromechanical device based on the change in the one or more components...; and updating the one or more system settings based on the modification...”
The same personalization pattern - behavior data driving a generated output - also appears in US 11,507,984, where the mechanism is a concrete, named data structure rather than a functional label:
US 11,507,984, Claim 1 (excerpt):
“...generating... using a machine learning algorithm, a vector comprising the one or more data features pertaining to the user behavior and a template data feature representing one or more structural elements... receiving a selection of the online banner image; updating the vector based on adding an additional feature associated with the selection...; and updating the online banner image based on the updated vector.”
Both benchmark patents illustrate a similar drafting approach: personalization is claimed as a defined data object (a prompt, a vector) processed by a specified mechanism (a trained model, an ML algorithm) that produces a testable, specific output property - never as an unexplained module that simply “creates personalized features.”
WHAT EBAY'S OWN PATENTS’ PROSECUTION TEACHES
Reviewing eBay's granted claims as a set, several drafting patterns recur across all four benchmarks regardless of subject matter, and each maps to a specific point in the Alice/Mayo framework:
Pattern 1 - Named, structured data objects can add specificity
Every benchmark claim recites a specific data structure at the center of its inventive step: a feature vector (US 11,507,984), a structured prompt object built from sensor data, diagnostics, and a text prompt (US 12,619,447), a folder-based synchronization record with timestamps (US 11,995,705), or named sensor-configuration objects (US 11,853,944). None of them simply say “data” or “information” as the input to an unexplained black-box process.
Pattern 2 - Automated actions are tied to identifiable events or conditions
US 11,995,705 triggers synchronization on reconnection to a network, not on an abstract passage of time. US 11,853,944 triggers an order on sensor-measured duration and temperature thresholds, not on an unspecified “quantity is low” condition. This event-driven structure gives the examiner a concrete technical happening to evaluate, rather than an abstract state of affairs.
Pattern 3 - Where relevant, AI/ML claims can specify model, training, or processing details
Both AI-driven benchmarks (US 11,507,984 and US 12,619,447) recite training data and a training or fine-tuning process as part of the claimed system, not merely a trained model used as a black box. This directly answers the USPTO's 2024 AI-SME guidance concern about claims that merely “apply” AI without any specificity about the model or its training.
Pattern 4 - Dependent claims can add technical mechanisms rather than only field-of-use limits
Where the drafts under review use dependent claims to enumerate business contexts (establishment types, device types, service categories), eBay's dependents typically add an additional technical mechanism - object recognition to determine characteristics (US 12,619,447, claim 3), database identifier lookups (claim 4), or weighted, multi-factor supplier-scoring algorithms (US 11,853,944, claims 2 and 3).
Pattern 5 - The specification can identify a genuine technological problem
US 11,995,705's specification frames its problem as maintaining data consistency between a client device and a remote system across disconnection and reconnection - a technical problem in distributed systems, not a UX inconvenience. This framing matters directly for Prong Two: an examiner's practical-application analysis looks to what the specification says the invention solves.
SIDE BY SIDE: WHERE THE DRAFTS AND THE BENCHMARKS DIVERGE
The table below maps each recurring weakness identified in the draft applications to its closest analog among the eBay benchmark claims.
| CATEGORY | DRAFT LANGUAGE | EBAY BENCHMARK EQUIVALENT | TAKEAWAY |
|---|---|---|---|
|
AI/personalization mechanism |
Patent Publication Y, claim 1: “Recites a system for providing integrated and personalized services through a digital interface, the system comprising: one or more Network Service Provider (NSP) modules configured to receive a network connection request from a user device through a networking device for providing network services; a data collection module configured to provide a prompt to the user device after receiving the network connection request, the prompt requesting the user to provide personalized responses and/or share a user profile stored in a private memory space; the data collection module further configured to receive user information including responses to personalized questions and/or the shared user profile based on the user's selection; an Artificial Intelligence (AI) module configured to generate one or more personalized features associated with one or more services based on the received user information and location information associated with the networking device; an integration module configured to generate a personalized digital interface including links to one or more webpages based on the generated personalized features; and a personalized digital interface push module configured to provide the personalized digital interface to the user device through a push service.” - purely functional, no mechanism disclosed anywhere in the claim or the specification. |
US 12,619,447, claim 1: “A computer-implemented method, comprising: receiving system information data associated with a change in state of one or more components of an electromechanical device; generating a message indicating feedback responsive to the change in state of the one or more components, the generating performed by inputting the system information data as a prompt to generative artificial intelligence representative of a plurality of characteristics of the electromechanical device, the generative artificial intelligence trained to analyze the system information data and to output the message that has one or more language characteristics based on the plurality of characteristics of the electromechanical device, wherein the one or more language characteristics are unique to the electromechanical device; and outputting the message indicating the feedback.” |
The benchmark claim does not merely recite an AI module by its output. It claims the input structure, AI processing mechanism, training relationship, and defined output characteristics. |
|
AI output tied to system control |
No claim in either draft ties the AI/personalization output to any device or system-state change; output is only ever a displayed interface or message. |
US 12,619,447, claim 12: “The computer-implemented method of claim 1, further comprising: receiving, as output from the generative artificial intelligence, an indication of a modification to one or more system settings of the electromechanical device based on the change in the one or more components of the electromechanical device; and updating the one or more system settings based on the modification to the one or more system settings, wherein the message indicates the one or more system settings are updated.” |
A stronger software claim connects the AI output to a technical action, such as modifying system parameters, updating device behavior, or controlling another technical process. |
|
Personalization from behavior data |
Patent Publication Y, claims 1: “Recites a system including: one or more Network Service Provider (NSP) modules configured to receive network connection requests from user devices; a data collection module configured to request and obtain user-specific information including answers to personalized questions and stored user profile information; an Artificial Intelligence (AI) module configured to generate personalized features for one or more services based on the received user information and contextual information associated with the networking device; an integration module configured to create a personalized digital interface including webpage links corresponding to the generated personalized features; and a push module configured to present the personalized digital interface on the user device.” - a static profile lookup with no described learning process. |
US 11,507,984, claim 1: “A method comprising: receiving, by one or more data processors, a user selection indicating one or more data features pertaining to user behavior of a user in relation to an image of a product, the image of the product displayed on a website accessed by the user; generating, by the one or more data processors using a machine learning algorithm, a vector comprising the one or more data features pertaining to the user behavior and a template data feature representing one or more structural elements of an online banner image, the machine learning algorithm being trained with training data comprising known data combinations of user behavior data features and corresponding structural elements of online banner images; generating, by the one or more data processors for display at a client device in communication with the one or more data processors, the online banner image for the user based on the one or more data features and the template data feature associated with the vector, wherein the online banner image is generated using the one or more structural elements of the template data feature; receiving a selection of the online banner image; updating the vector based on adding an additional feature associated with the selection of the online banner image; and updating the online banner image based on the updated vector.” |
The personalization mechanism is anchored to a defined data structure (feature vector), a trained algorithm, and an update process rather than an unexplained personalization function. |
|
Real-time / data synchronization |
Patent Publication X, dependent claim: Recites a method for providing a virtual inventory interface for components in an e-commerce environment, comprising: obtaining, by a processor, component inventory data associated with multiple compartments of physical drawers, including compartment identifiers, component types, component serial numbers, and available component quantities; creating, by the processor, a virtual drawer interface including multiple virtual drawers corresponding to the physical drawers; associating and storing the obtained component inventory data with the corresponding virtual drawers; and accessing, by the processor, a selected virtual drawer to select a component and add the selected component to a virtual shopping cart for completing a purchase transaction.” - an asserted result with no described mechanism. |
US 11,995,705, claim 1: “A method comprising: receiving, at a client device while the client device is in electronic communication with a remote computing system, a user selection of a digital item displayed on a user interface provided by the remote computing system; based on the user selection: retrieving, using at least one hardware processor of the client device, item data associated with the selected digital item from the remote computing system; and storing the item data in a folder of a data storage system residing on the client device, the digital item being organized into at least one of a plurality of lists of downloaded digital items at the client device, the plurality of lists including a list of recommended digital items; while the client device is disconnected from the remote computing system, performing an operation with respect to the digital item; subsequent to performing the operation, reestablishing, by the client device, electronic communication with the remote computing system; and in response to reestablishing the electronic communication, synchronizing the operation performed with respect to the digital item with the remote computing system.” - synchronization is claimed as a step responsive to a specific network event |
The benchmark identifies a specific technical trigger for synchronization (network reconnection), rather than merely claiming the result of ‘real-time updating. |
|
Conflict resolution on sync |
No claim or specification disclosure of how conflicting updates between the virtual and physical/remote data would be resolved. |
US 11,995,705, claim 7: “The method of claim 6, wherein the comparing comprises: determining a last update time for the current item data at the remote computing system and a last update time for updating the updated item data in the folder; and identifying a most recent update time between the last update time for the current item data at the remote computing system and the last update time for updating the updated item data in the folder, wherein the synchronizing occurs based on the most recent update time being the last update time for updating the updated item data in the folder.” - an explicit timestamp-comparison algorithm |
The claim adds an explicit conflict-resolution algorithm, converting a broad consistency objective into a defined technical process. |
|
Sensor-triggered automation |
Patent Publication X, dependent claim: “generating an alert when a corresponding component quantity represented in the digital inventory interface falls below or exceeds a threshold.” However, the claim does not identify the source of the quantity data, the sensors or inputs used to determine inventory status, or the decision logic connecting the data to the alert. - a bare threshold check with no sensor or data source specified. |
US 11,853,944, claim 1: named sensor types, sensor configuration steps, and a multi-factor quantity-determination formula “A method comprising: accessing history information for a user account, the history information including information for an item ordered by the user account; presenting a first user interface that includes a selector for sensors; receiving an input at the selector, the input being for a selection at the first user interface relating to the sensors; presenting a second user interface that allows configuration of the sensors in response to receiving the input at the selector for the selection at the first user interface; receiving a selection at the second user interface relating to the configuration of a first sensor of the sensors; presenting a third user interface having a field to receive conditions for placing an order for the item; receiving an input at the field of the third user interface corresponding to a condition for placing the order for the item; configuring the first sensor based on the received configuration, the configuration relating to determining a duration of time; electronically receiving first sensor data from the first sensor relating to the duration of time; processing the first sensor data to determine if the duration of time exceeds a time threshold; configuring a second sensor to detect an ambient temperature; electronically receiving second sensor data from the second sensor relating to the ambient temperature; processing the second sensor data to determine if a detected ambient temperature exceeds a temperature threshold; determining an amount of the item used; processing the first sensor data to determine a quantity of the item to be ordered, the quantity of the item to be ordered being determined based on the amount of the item used, the duration of time, the ambient temperature, and variable based on whether the duration of time exceeds the time threshold and whether the detected ambient temperature exceeds the temperature threshold; and causing delivery of the item by a delivery date to a shipping address based on the duration of time exceeding the time threshold and the detected ambient temperature exceeding the temperature threshold.” |
The automation is supported by named sensors, measured conditions, and decision logic rather than a generic threshold-based action. |
|
UI / skeuomorphic elements |
Patent Publication X, dependent claim: " Recites simulating the opening and closing of a physical storage element within the digital interface to represent the operation of the corresponding physical storage arrangement." - a cosmetic animation with no technical effect on the underlying data operation. |
No equivalent "simulate a physical object" limitation appears in any independent claim across the four benchmark patents. |
Pure visual simulation of a physical object generally does not provide technical significance unless tied to an underlying data-processing improvement. |
|
Field-of-use dependent claims |
Dependents recite establishment type (bank, hotel, restaurant ...), device-type lists, and personalized-service categories - narrowing to a commercial context without adding technical structure. |
US 12,619,447, claim 3 (object-recognition-based characteristic determination) and claim 4 (database identifier lookup); US 11,853,944, claims 2-3 (weighted supplier-scoring algorithm). |
Stronger dependent claims add technical mechanisms (e.g., object recognition, database lookups, scoring algorithms) rather than merely limiting the invention to a particular business context or use case. |
THE CHECKLIST: 12 POINTS TO TAKE CARE OF WHILE DRAFTING SOFTWARE PROCESS CLAIMS
Distilled from the comparison above, these are the 12 recurring software patent drafting pitfalls identified from the benchmarking analysis. They provide practical guidance for drafting stronger software process claims and addressing common eligibility concerns.
| S. NO | POINT | WHY IT MATTERS |
|---|---|---|
|
1. |
Claim the mechanism, not the result |
"An AI module to create personalized features" is a result. "Inputting data as a structured prompt to a model trained to analyze X and output Y with property Z" is a mechanism. The latter provides a stronger technical basis for explaining how the claimed result is achieved. |
|
2. |
Give every functional module a named data structure |
Vectors, knowledge graphs, timestamped records - a structured data object claimed as part of the process is concrete evidence of a technical implementation, not just a functional label. |
|
3. |
Tie automation to sensed, real-world conditions |
An alert or automated action triggered by unspecified "data" reads as abstract. The same action triggered by named sensors evaluated against named thresholds reads as a technical control system. |
|
4. |
Identify the real technical trigger for synchronization |
"Updates in real time" is an assertion. "Synchronizing in response to reestablishing network connectivity" identifies an actual technical event and claims the response to it. |
|
5. |
Add a conflict-resolution mechanism wherever two data sources might disagree |
A timestamp-comparison (or equivalent) step is inexpensive to add and gives an examiner a concrete algorithm to evaluate instead of a bare consistency claim. |
|
6. |
Avoid skeuomorphic UI limitations as your inventive concept |
Animating a digital object to resemble its physical counterpart does not change the underlying data operation, and has repeatedly been found to add nothing technical. |
|
7. |
Narrow dependent claims with technical mechanisms, not business context |
"Wherein the establishment is a hotel" adds nothing to a §101 analysis. "Wherein the characteristics are determined using object recognition on an image input" does. |
|
8. |
Close the loop from AI output back into system state wherever possible |
A module whose only output is a displayed message stays business/UX-flavored. The same module whose output modifies a system setting has a claimed technical effect. |
|
9. |
Frame at least one problem in the specification as a technical problem |
Prong Two analysis looks to what problem the specification says is being solved. "Saves the user time" is a business problem; "reconciles inconsistent data across disconnected devices" is a technical one. |
|
10. |
Don't leave your best technical disclosure out of the independent claims |
If the specification discloses a genuinely technical mechanism, pull it into claim 1 - it does no good sitting unclaimed in a body paragraph. |
|
11. |
Proofread every claim preamble against its own claim body before filing |
Template reuse across matters is efficient until a preamble from a different invention survives into a filed claim - an entirely avoidable §112(b) rejection and a credibility cost with the client. |
|
12. |
Expect and pre-empt a §101 rejection - don't just react to one |
Map every independent claim against Alice, Electric Power Group, and Intellectual Ventures v. Capital One before filing, not after the first Office Action. |
GENERAL PRACTICE VS. BEST PRACTICE ( AVOIDING THE 12 SOFTWARE PATENT DRAFTING PITFALLS )
The following table generalizes the findings above into a reusable reference, organized by drafting dimension rather than by any single patent, so that these principles can be applied across different software inventions and technology areas.
| DRAFTING DIMENSION | GENERAL PRACTICE (VULNERABLE TO §101) | BEST PRACTICE (EBAY-BENCHMARKED) |
|---|---|---|
|
AI / ML module claiming |
Claim the module only by its output: "an AI module to create personalized features based on X and Y." No model type, no data structure, no training process specified. |
Recite the input structure (data fed as a structured prompt), the training regime (a model fine-tuned per entity/device), and a testable output property tied to that training. |
|
Personalization/recommendation logic |
Personalization is simple conditional branching on stored profile flags ("if vegan, show X") dressed up as "AI," with no data structure or update mechanism claimed. |
Recite a concrete data structure (e.g., a feature vector combining behavior data and template features) with an explicit update mechanism fed by subsequent user actions. |
|
Real-time / synchronization claims |
Assert the technical result ("data updates in real time") without claiming or disclosing any mechanism for achieving it. |
Identify the actual technical trigger (e.g., reconnection after disconnection) and claim synchronization as responsive to that event; add a conflict-resolution mechanism such as timestamp comparison in a dependent claim. |
|
Sensor/automation claims |
Automation is claimed as a bare threshold check ("generate an alert when quantity is below a threshold") with no sensor, data source, or decision logic specified. |
Specify sensor types, sensor configuration steps, and a multi-factor decision formula tying the automated action to sensed, real-world conditions. |
|
UI / display limitations |
A skeuomorphic or purely cosmetic UI behavior (e.g., simulating a drawer opening and closing) is claimed as if it carries patentable weight. |
Where UI elements are claimed, tie them to functional configuration steps that produce a defined technical outcome, not to visual mimicry alone. |
|
Dependent claim strategy |
Dependents narrow only by business or field-of-use context (establishment type, device type lists, service categories) without adding technical structure. |
Dependents narrow by adding an additional technical mechanism, e.g. object-recognition-based characteristic determination, database identifier lookups, or weighted scoring algorithms. |
|
AI output tied to system effect |
The chain stops at a displayed message or interface; the AI/module output is never connected to any device or system-state change. |
Where plausible, close the loop: claim the AI/module output as directly triggering a system-setting modification or other technical state change, not just a UI display. |
|
Problem statement in the specification |
The problem and advantages are framed purely as UX or business convenience ("avoids repetitive searching," "unique shopping experience"). |
At least one problem is framed as a genuine technical problem (network state transitions, data consistency across distributed systems, sensor-based automation), giving Prong Two analysis a technical problem to point to. |
|
Use of available technical disclosure |
A genuinely technical mechanism is disclosed in the specification (e.g. a local data-storage / access-control architecture) but is left out of the independent claims. |
The specification's most technical, most specific mechanism is pulled into the independent claim rather than left unclaimed in a body paragraph. |
THE TAKEAWAY
The difference between software claims that withstand a §101 challenge and those that do not can depend, among other factors, on how the claims and specification present the technological implementation and asserted improvement - not merely on the commercial value or novelty of the underlying idea.
Across every comparison in this benchmarking study, the eBay benchmark claims and the draft claims were often solving conceptually similar problems - personalizing content, synchronizing data, automating reorders.
In this benchmark, an important difference was whether the claim recited particular implementation details that made the technological contribution easier to identify, or instead relied primarily on functional language describing the desired result. That distinction can be significant under §101, but it is not dispositive in every case.
The twelve software patent drafting pitfalls identified above, together with the patterns illustrated by eBay's granted claims, form a practical quality-control checklist that can be applied during drafting. The purpose is to identify potential drafting weaknesses early, not to predict a particular examiner's decision or guarantee eligibility.
Next Steps
This benchmarking approach-mapping draft claims against granted patents, limitation by limitation-can be used as one quality-control pass before a software application is filed. It should complement, not replace, a claim-by-claim analysis under §101, §102, §103, and §112 and a review of the relevant prosecution history and current USPTO guidance.
