Software & AI Patent Attorney in Austin, Texas
Protecting software innovations and AI inventions with 17 years of patent prosecution experience and a genuine technical background in physics and semiconductor engineering.
Home → Practice Areas → Software & AI Patents
Why Software Patent Strategy Starts With Engineering, Not Law
I came to software patent prosecution from an unusual direction. Before law school I spent seven years working as a manufacturing process engineer in the semiconductor industry — writing Unix scripts, working with fabrication control systems, and developing the kind of hands-on relationship with computing architecture that you get from the factory floor rather than the classroom. That background shapes how I approach software patent claims in ways that matter practically, not just theoretically.
Most patent attorneys who work on software cases approach them from the legal framework outward — they learn the Alice/Mayo test, they understand the relevant Federal Circuit cases, and they apply legal doctrine to whatever technical description the inventor provides. What they cannot do is read an inventor's description of a machine learning architecture or a distributed systems design and understand — at an engineering level — what is technically novel about it, where the prior art boundaries actually are, and how to frame the claims to capture the genuine inventive contribution rather than a sanitized legal description of it.
That difference in starting point produces measurably different patents. When I draft claims for a software or AI invention, I start with the technical architecture — the specific engineering choices the inventor made, why those choices solve a problem that existing approaches do not, and what the technically novel elements are at the implementation level. The legal framework for getting those claims allowed comes second. This sequence produces patents that are both technically accurate and legally strong — which is the combination that actually protects your competitive position.
For Austin's software and AI companies competing in markets where competitors are well-funded, technically sophisticated, and actively building their own patent portfolios, the quality of your patent claims is not an abstract concern. It is the difference between a portfolio that provides genuine competitive protection and one that provides legal formality without practical significance.
Navigating Alice — A Practitioner's Perspective
The Alice/Mayo framework has been the defining challenge in software patent prosecution since the Supreme Court's 2014 decision, and its application has evolved significantly through subsequent Federal Circuit decisions that have both clarified and complicated the patentability analysis for software and AI claims. What practitioners who handle significant volumes of software prosecution understand — and what inventors often do not — is that Alice rejections are not random. They follow patterns that experienced prosecution counsel can anticipate and structure claims to avoid.
The most effective Alice avoidance strategies I use in practice are not legal tricks — they are engineering choices about how to describe and claim the invention. Section 101 jurisprudence consistently rewards claims that describe specific technical improvements to how computer systems function, specific technical problems solved in specific technical ways, and specific hardware-software interactions that produce technically concrete results. Claims that describe functional outcomes without specifying the technical mechanism — "a system configured to optimize X" without specifying how the optimization is technically implemented — consistently fail Alice scrutiny regardless of how valuable the underlying innovation is.
My semiconductor engineering background is particularly relevant here. The Federal Circuit cases that have most consistently survived Alice scrutiny involve claims that describe inventions in the kind of technical specificity that an engineer would use — not business results described in technical-sounding language, but actual technical architecture described with engineering precision. DDR Holdings, Enfish, McRO, Berkheimer — the decisions that give software patent holders the clearest path to Alice-resistant claims all involve this level of technical specificity. I know how to draft those claims because I understand what technical specificity looks like from the engineering side.
For AI-specific claims, the frontier is moving fast. USPTO guidance on AI patentability has evolved substantially over the past several years, and the examiners handling AI cases in the relevant art units have developed increasingly sophisticated expectations about what AI claims need to describe to satisfy Section 101. I follow these developments closely and adjust my claim drafting strategies to reflect current USPTO guidance — which means the AI applications I draft today are positioned for the examination standards that currently exist, not the ones that existed five years ago.
Machine Learning Patents — What Actually Gets Allowed
Machine learning patent prosecution has developed a distinct practice culture over the past several years, shaped by the intersection of Alice/Mayo jurisprudence, USPTO examination guidelines for AI innovations, and the technical sophistication of examiners in the 2100 and 3600 art units where most ML applications are examined. Understanding what actually gets allowed in this environment — not in theory, but in the prosecution reality of specific examiner art units — is practical knowledge that makes a direct difference in prosecution outcomes.
The ML patent applications that consistently achieve allowance with commercially meaningful claim scope share several characteristics. They describe the ML architecture specifically — not "a machine learning model" but the specific type of model, its structural characteristics, and the specific training or inference approach that constitutes the invention. They identify a specific technical problem that the ML approach solves better than prior approaches — not a business problem that ML helps address, but a technical problem in how computational systems process, classify, or analyze data. And they describe the technical improvement in terms of computational efficiency, accuracy metrics, or system performance in ways that are specific enough to distinguish the claims from prior art ML approaches.
The ML applications that consistently fail to achieve meaningful claim scope share the opposite characteristics — they describe ML at a level of abstraction that covers any application of the technology to the claimed domain, they identify business value rather than technical improvement, and they draft claims that read on prior art ML approaches because they do not distinguish the specific technical innovation from the general practice of applying machine learning.
For Austin's AI companies — particularly those in computer vision, natural language processing, autonomous systems, and AI-enabled medical devices — I bring prosecution experience in these specific ML application areas alongside the engineering background needed to understand the technical substance of the inventions I am drafting. The result is ML patent applications positioned for the prosecution environment that currently exists rather than the idealized version described in academic patent law discussions.
Fintech, SaaS, and Enterprise Software — Building Defensible Portfolios
The fintech, SaaS, and enterprise software sectors represent some of the most competitive and most patent-active segments of Austin's technology economy — and also some of the most challenging environments for building patent portfolios that provide genuine competitive protection rather than legal formality.
Fintech software patents face the combined challenge of Alice/Mayo scrutiny and the dense prior art landscape of financial services technology — an area where large financial institutions, established technology companies, and specialized fintech players have been filing patents for decades. Identifying genuinely novel fintech innovations that survive this prior art landscape requires both technical understanding of the underlying financial technology architecture and systematic prior art searching that looks beyond obvious database sources to financial industry standards documents, academic papers in financial engineering, and international patent databases where fintech prior art is concentrated in European and Asian banking technology filings.
SaaS and enterprise software patents require claim strategies that cover the distributed, cloud-based implementation of software innovations without falling into the trap of claiming abstract ideas implemented on a generic cloud infrastructure. The most valuable SaaS patents describe novel technical architectures for multi-tenant data isolation, novel approaches to distributed computation that solve specific technical scaling problems, and specific technical innovations in how software services are delivered that distinguish the invention from prior art cloud computing approaches. These claims require both technical understanding of cloud architecture and prosecution experience in the relevant examination art units where SaaS applications are examined.
For enterprise software companies preparing for acquisition or significant investment, the patent portfolio's technical credibility is often scrutinized more carefully by sophisticated technical buyers than by individual inventors or early-stage investors. A buyer's technical team reviewing an enterprise software patent portfolio can assess whether the claims actually cover what the company does, whether the prior art landscape was adequately searched, and whether the prosecution history contains admissions that limit the claims beyond their face language. I build enterprise software patent portfolios with this level of technical scrutiny specifically in mind — producing applications that will hold up to review by technically sophisticated audiences who understand both the technology and the patent system.
Cybersecurity, Blockchain, and Distributed Systems Patents
Cybersecurity, blockchain, and distributed systems represent three of the most technically active and legally complex areas of software patent prosecution — areas where the technology is advancing rapidly, the prior art landscape is dense and international in character, and the examination standards involve technical complexity that requires genuine computing expertise to navigate effectively.
Cybersecurity patents present specific prosecution challenges because the defensive and offensive techniques that constitute cybersecurity innovations often involve specific technical mechanisms that must be described with engineering precision to be patentable — while simultaneously being described at sufficient generality to cover the variations that competitors will implement. A cybersecurity patent that describes only one specific attack detection algorithm at the implementation level is vulnerable to design-around by competitors who implement the same detection approach with different technical specifics. My Unix background and systems-level computing experience inform how I approach cybersecurity claim drafting — describing security innovations at the architectural level that captures genuine technical novelty without unnecessary implementation specificity that limits the claims' coverage.
Blockchain and distributed ledger patents occupy an interesting position in the current patent landscape — technically sophisticated inventions that nonetheless face Alice challenges when claimed at too high a level of abstraction, and prior art challenges from the substantial academic and open-source literature that predates and accompanies blockchain technology development. Successful blockchain patent prosecution requires both technical precision in describing the specific consensus mechanisms, cryptographic approaches, or data structure innovations that constitute the invention and prior art searching that extends into the academic cryptography and distributed systems literature where the most relevant prior art is concentrated.
Distributed systems patents — covering innovations in cloud computing architecture, container orchestration, microservices design, and distributed data processing — represent some of the most commercially significant software patents in Austin's technology economy, protecting the infrastructure innovations that underlie many of the most successful cloud-native technology companies. I approach distributed systems patent prosecution with the architectural understanding developed through my semiconductor engineering background working with distributed control systems — an engineering perspective that informs how I describe distributed computing innovations at the technical level that produces Alice-resistant, defensible claims.
Austin's AI Ecosystem and What It Needs From Patent Counsel
Austin has become a genuinely significant AI innovation hub — driven by UT Austin's computer science and engineering research programs, the presence of major technology companies that have established AI research centers here, a venture capital community that has developed real sophistication in evaluating AI companies, and a dense ecosystem of AI startups across computer vision, NLP, autonomous systems, healthcare AI, and enterprise AI applications.
What this ecosystem needs from patent counsel — and what it often does not get from generalist patent attorneys without technical depth in computing and AI — is prosecution that reflects genuine understanding of the technical landscape. Austin AI founders are technically sophisticated. They know what their innovations are and why they matter. What they need is an attorney who can engage with that technical sophistication rather than translating it into legal description, who understands the prosecution dynamics specific to AI patent examination, and who builds portfolios with the strategic coherence that sophisticated investors and acquirers will recognize and value.
The specific Austin AI subsectors I work with most frequently include autonomous vehicle and robotics AI — where the intersection of perception algorithms, control systems, and real-time computing creates multi-layered patent opportunities; healthcare and medical AI — where FDA regulatory pathways intersect with software patent strategy in ways that require coordinated thinking; enterprise AI and data analytics — where the commercial significance of the AI application drives patent value but the generic application of ML to data creates Alice challenges that require careful claim strategy; and semiconductor AI — where the hardware-software integration of AI accelerators and AI-optimized chip architectures creates both utility patent and design patent opportunities.
For Austin AI companies at every stage from pre-seed through growth stage, I offer the combination of technical depth and legal expertise that this ecosystem's innovations deserve.
Call or text (512) 293-0710, email sconnolly@austin-patent-attorney.com, or fill out the contact form to schedule your free 30-minute consultation.
[ Software & AI Patent FAQs — Austin, Texas ]
Question: Can you patent software or AI inventions in 2026?
Answer: Yes — with the right claim strategy. Software and AI patents face heightened scrutiny under the Alice/Mayo framework but specific technical implementations that solve a concrete problem in a novel way remain patentable. The key is drafting claims that emphasize the concrete technical improvement rather than just describing an abstract idea. My engineering background is a significant advantage here.
Question: What is the Alice/Mayo framework?
Answer: Alice/Mayo refers to a two-step test USPTO examiners use to evaluate software and AI patent claims. Step one asks whether the claim is directed to an abstract idea. Step two asks whether the claim adds significantly more than the abstract idea. Successfully navigating Alice/Mayo requires technical precision in claim drafting — which is where my physics and semiconductor engineering background gives clients a meaningful advantage.
Question: How long does a software patent take?
Answer: Software and AI patents currently average 2-3 years from filing to grant at the USPTO, though the technology area and examiner workload affect timing. A provisional patent application gives you patent pending status immediately upon filing. Accelerated examination options are available if speed is critical.
Question: What is the current USPTO allowance rate for software and AI patent applications and how does it affect my prosecution strategy?
Answer: Allowance rates for software and AI applications vary significantly by art unit and by how the application is drafted — which is one reason that engineering-informed claim drafting matters so much in this technology area. Applications drafted with specific technical improvement language from the outset — describing how the claimed system improves computer functionality in specific, measurable ways — consistently achieve higher allowance rates than applications that describe software functionality in broad functional terms without adequate structural grounding. The 2024 USPTO guidance on AI applications has improved examination consistency compared to the volatile post-Alice period, but examiner-by-examiner variation remains significant. My approach involves drafting with the specific examiner population in mind — not as a tactical accommodation but as a reflection of what genuinely constitutes a technically specific, Alice-resistant claim.
Question: How do you protect a software invention when the core innovation is in the training data rather than the algorithm architecture?
Answer: Proprietary training datasets present a specific IP strategy challenge because the data itself — raw factual information — is not directly patentable, and disclosing specific training data compositions in a patent application may undermine the trade secret protection that makes the data valuable. The patent strategy for training-data-dependent innovations focuses on the technical methods of data curation, preprocessing, and augmentation that produce the distinctive training set rather than the data itself, the specific architectural choices that exploit the training data's characteristics, and the inference system design that translates the trained model into commercial output. The training data itself is typically better protected as a trade secret while the technical methods around it are pursued through patent prosecution — a coordinated strategy that I develop specifically for each client's situation.
Question: Can you patent improvements to a foundation model like GPT or LLaMA that my company fine-tuned for a specific application?
Answer: Yes — genuine technical improvements to foundation models like GPT or LLaMA can be patentable when the specific technical implementation is novel and non-obvious over the base model and its published documentation. The foundation model itself — whether open-source or commercially available — is treated as prior art, so your claims must clearly distinguish your technical contributions from what the base model already does. Patentable improvements typically include novel fine-tuning methodologies, retrieval-augmentation architectures, prompt-engineering systems, specific architectural modifications that improve efficiency or accuracy, custom inference optimization techniques, or integration approaches that combine the base model with proprietary components in novel ways. The strength of the resulting patent depends critically on how specifically and technically the claims describe your contributions, rather than simply claiming the functional output of the fine-tuned system. I draft foundation model improvement patents with the open-source prior art landscape specifically in mind from the first claim draft.
Question: What is the difference between patenting a software product and copyrighting it — and do I need both?
Answer: Patents protect the functional innovations in your software — the specific algorithms, architectures, and technical approaches — preventing competitors from using those innovations even if they write entirely different code. Copyright protects the specific code itself — preventing literal copying of your source files but not preventing independent development of software that performs the same functions differently. For most commercially significant software innovations, both are worth pursuing: patents on the core functional innovations that differentiate your product, and copyright registration on the specific code both for infringement enforcement purposes and for statutory damages eligibility. The combination creates layered protection that is significantly more difficult for competitors to circumvent than either form alone.
Question: How do you handle patent prosecution for a software company that releases frequent product updates?
Answer: Frequent product updates create both opportunities and challenges for patent prosecution. The challenge is that claimed inventions in software patents need to be supported by the specification as filed — you cannot add new technical content to a pending application after filing. The opportunity is that continuation applications allow you to pursue new claim sets directed at updated product features as long as those features were disclosed in the original specification. My approach for software companies with rapid release cycles involves drafting original specifications that are deliberately broad in their technical disclosure — describing not just the current product but the architectural principles that govern future versions — so that continuation claims can follow product evolution without requiring new independent filings for every update cycle.
Question: What specific Austin software and AI companies have the kinds of innovations that typically benefit most from patent protection?
Answer: The Austin software and AI companies that benefit most from patent protection are typically those whose innovations involve specific technical architectures that competitors would copy if they could — not companies whose competitive advantage comes primarily from network effects, brand, or execution speed where patents provide limited practical value. Companies building proprietary AI inference infrastructure, novel data processing pipelines with specific technical efficiencies, distinctive distributed computing architectures, specific natural language processing implementations, or fintech systems with novel fraud detection or risk modeling approaches typically have patentable technical innovations worth protecting. Austin's growing enterprise software sector — including companies in the HR technology, real estate technology, and healthcare technology spaces building on AI foundations — consistently produces patent-worthy technical innovations that sophisticated IP counsel can identify and protect.
Question: How do you assess whether a software innovation is genuinely novel versus an obvious combination of existing approaches?
Answer: Genuine novelty in software is frequently not obvious from the invention description alone — it requires knowing what the prior art actually says about the problem being solved and the approaches that have been tried. My assessment process starts from the specific technical problem the innovation addresses and searches not just patent databases but the technical literature — arXiv preprints, ACM digital library proceedings, IEEE publications, and the open-source project documentation that is the most current record of what the software engineering and AI research communities have actually built and published. An innovation that seems novel based on a quick Google search may be well-documented in a 2021 NeurIPS paper that keyword-based patent database searching misses entirely. Finding that paper before filing is far better than having the examiner find it during prosecution.
Question: My software innovation is really just a better algorithm — is that patentable?
Answer: The algorithm itself — expressed as a mathematical formula — is not patentable. But a specific technical implementation of that algorithm that produces a concrete technical result in a computing system may be patentable. The key is framing the claims around what the algorithm does in the computing environment — how it improves processing efficiency, reduces computational load, achieves a specific technical output that prior systems could not achieve — rather than claiming the mathematical relationship itself. My approach to algorithm patents starts from the engineering architecture: what specific technical problem does this algorithm solve, what technical constraints does it operate under, and what specific technical improvement does it achieve over prior approaches? Those answers define the patentable claim scope.
Question: How do I patent a machine learning model without disclosing my proprietary training data?
Answer: Patent specifications must disclose how to make and use the claimed invention with sufficient detail to enable a person of ordinary skill in the art — but they do not necessarily require disclosure of proprietary training datasets. Patent claims for ML innovations can be directed at the model architecture, the training methodology, the specific data preprocessing steps, or the inference system design rather than the training data itself. The training data can often remain a trade secret even while the model architecture and training method are patented. I help ML companies identify which aspects of their AI systems to protect through patents and which to protect as trade secrets — often the right answer involves both.
Question: Can I patent a neural network architecture?
Answer: Yes — novel neural network architectures that produce specific technical improvements over prior architectures are patentable. The claim must describe the architectural innovation with specificity — the specific layer arrangements, connection patterns, attention mechanisms, or architectural choices that constitute the invention — and connect those architectural features to specific technical improvements in accuracy, efficiency, computational cost, or other measurable technical parameters. Generic claims to "a neural network that classifies images" will not survive Alice scrutiny. Specific claims to "a convolutional neural network architecture comprising specific novel structural elements that achieve specific technical results" may be patentable with proper drafting.
Question: How much does a patent application cost in Austin?
Answer: Patent costs vary based on technology complexity and application type. I provide a detailed, transparent cost estimate during your free 30-minute consultation so you know exactly what to expect before committing to anything. Individual inventors and small businesses often qualify for significantly reduced USPTO filing fees.
Question: My AI system improves itself through reinforcement learning — can that self-improvement process be patented?
Answer: Yes — the specific technical methodology by which a reinforcement learning system improves its performance may be patentable if it involves novel and non-obvious technical choices in reward function design, policy gradient calculation, exploration strategy, or system architecture. The patent should describe the specific technical mechanism of the self-improvement process rather than the abstract concept of a system that gets better over time. Reinforcement learning patents are a growing area of AI patent activity, and I stay current with both USPTO examination guidance for AI applications and Federal Circuit decisions affecting AI patent eligibility.
Question: Can I patent an API?
Answer: API patents are complex. An API specification itself — the list of function names and parameters — is arguably more like an abstract interface than a patentable invention. However, the specific technical architecture underlying an API, the novel methods implemented through the API, and specific protocol innovations that an API embodies can be patentable. The Oracle v. Google litigation — which ultimately found that API declarations are copyrightable — established that API-related IP protection exists but involves careful analysis of what specifically is being protected. I advise software companies on comprehensive API protection strategies that coordinate patent and copyright protection.
Question: My software runs on edge devices with limited computing resources — does that affect patentability?
Answer: The specific technical constraints of edge computing — limited processing power, memory constraints, battery life requirements, real-time response demands — actually create opportunities for stronger patent protection. When your software innovation specifically addresses these constraints — achieving the same functional result with dramatically lower computational cost, designing novel compression approaches for efficient on-device inference, or creating specific communication protocols that minimize bandwidth use — the technical specificity of those constraint-driven innovations tends to produce more Alice-resistant claims than general-purpose software innovations. The resource constraint context helps establish the concrete technical problem that the invention solves.
Question: How quickly is the AI patent landscape evolving and will my patents still be relevant in a few years?
Answer: The AI patent landscape is evolving faster than almost any other technology area — with USPTO guidance on AI patentability itself evolving, Federal Circuit decisions clarifying the boundaries of AI patent eligibility, and the technology itself advancing at extraordinary speed. Two strategic approaches address this: first, continuation applications that allow you to pursue new claims as the competitive landscape evolves, keeping pending applications active that can be directed at tomorrow's implementations based on today's disclosure; and second, comprehensive specification drafting that describes your invention broadly enough to encompass future implementations that embody the same underlying innovation. I draft AI patent applications with both continuations and technology evolution specifically in mind.
Question: Can I patent a software invention that is implemented partially in hardware and partially in software?
Answer: Hardware-software integrated inventions often produce the strongest and most Alice-resistant patent claims because the hardware component grounds the claim in physical structure rather than pure abstraction. When a software algorithm is specifically implemented with dedicated hardware accelerators, custom silicon, or specific hardware-software co-design choices, the resulting system is significantly easier to protect than software running on generic hardware. This is directly relevant to AI accelerator chips, FPGA-implemented algorithms, embedded systems, and purpose-built computing architectures where the hardware-software integration is itself an innovation.
Question: What should I do if a competitor files a patent on software that I invented first?
Answer: Under the current first-to-file system, filing date rather than invention date determines priority in most circumstances. If a competitor files first, your options depend on the timing. If you filed a patent application before the competitor — even if their application was published first — you have priority. If they filed before you, a derivation proceeding at the PTAB is available if you can demonstrate that they derived the invention from you. For published applications that have not yet issued, post-grant challenges at the PTAB may be available. And depending on your prior art situation, the competitor's patent may be invalid based on prior disclosures of the technology. Contact me promptly — timing matters in all of these options.
Question: How do I protect a software-based business model that competitors could easily replicate?
Answer: Software business models are protected by a combination of IP strategies rather than any single tool. Patents protect the specific technical innovations that implement the business model — if those innovations are genuinely novel and non-obvious. Trade secrets protect the proprietary data, algorithms, and know-how that competitors cannot access by observing the public-facing product. Copyrights protect the specific code. And being the first mover with a strong brand — protected by trademark registration — creates the customer recognition that makes your business model hard to replicate even when the technical implementation can be reverse-engineered. I help software companies identify which elements of their business model are protectable by each form of IP and build coordinated strategies.
Question: Can I patent a user interface design for my software?
Answer: User interface innovations can be protected in multiple ways. Utility patents protect novel UI interactions, specific algorithmic approaches to UI functionality, or technical methods of rendering or processing UI elements. Design patents protect the ornamental appearance of specific UI screens, icon arrangements, and graphical elements. Copyright protects the specific visual expression of the UI design. The strongest UI protection typically combines utility patents on functional innovations with design patents on distinctive visual elements. Many major technology companies — Apple, Google, Samsung — maintain extensive UI patent portfolios combining all three approaches.
Question: Is open source software a problem for patenting my related innovations?
Answer: Open source software can be prior art that affects the patentability of your innovations — if the open source code or documentation publicly disclosed the relevant technical concept before your filing date. I search open source repositories, GitHub commit histories, and open source documentation as part of prior art searches for software inventions precisely because this prior art is often missed by searchers who focus only on patent databases. Having said that, the existence of related open source software does not preclude patenting genuinely novel improvements and innovations built on or around open source foundations — the question is always what is new and non-obvious over what was already publicly available.
Question: What is a software patent's specification supposed to describe?
Answer: The specification of a software patent application must describe the claimed invention in sufficient technical detail to enable a person of ordinary skill in the software engineering art to implement it without undue experimentation. For software patents this means the specification should describe the system architecture, the data structures, the algorithmic logic, the flow of data through the system, the specific technical improvements achieved, and — critically — multiple embodiments and alternative implementations that demonstrate the breadth of the inventive concept. Specifications that describe only the specific implementation the inventor built — without describing the broader inventive principle — create continuation vulnerability and fail to support the broad claims that provide maximum protection.
Question: Can I patent software that is already deployed and used by customers?
Answer: If your software has been publicly disclosed or in commercial use for more than 12 months you have lost US patent rights. If it has been publicly disclosed or used for any period — even one day — before filing, you have almost certainly lost international patent rights in absolute novelty jurisdictions. If you are within the 12-month US grace period from first disclosure, file immediately. Contact me as soon as possible to assess what protection is still available. For software that has not yet been publicly released or disclosed — even if it is internally deployed — you still have full patent filing options.
Question: My software uses a third-party API — can I still patent innovations that depend on that API?
Answer: Yes — your innovations that operate through a third-party API may be patentable independent of whether you have any IP rights in the API itself. The key is that your claims must describe what is novel about how your system uses the API, what your system adds beyond the API's existing functionality, or what novel technical result your system achieves that the API alone does not provide. The API is treated as prior art — existing technology that your innovation builds upon — and your claims must distinguish over that prior art by describing what is new and non-obvious about your specific technical implementation.
Question: What is the current USPTO examination environment for AI patents and how has it changed?
Answer: The USPTO has issued multiple rounds of AI-specific examination guidance since 2019, most recently updating its 2024 guidance to address generative AI innovations. The current environment is more favorable for AI patents than the immediate post-Alice period — examiners are more familiar with AI technology and more sophisticated in distinguishing between unpatentable abstract ideas and patentable technical implementations of AI. The 2024 guidance specifically addresses large language models, generative AI, and AI-hardware integration claims. Applications filed today benefit from accumulated examiner experience and clearer guidance compared to AI applications filed in 2015 or 2016. I stay current with USPTO guidance updates and adjust my claim drafting strategies to reflect the current examination environment rather than the one that existed when I first handled AI applications.
Question: Should I patent my AI training methodology or keep it as a trade secret?
Answer: This is one of the most consequential IP strategy decisions for AI companies and the right answer depends on the specific characteristics of your training methodology. Training methodologies that are difficult to reverse-engineer from the deployed model — complex multi-stage training pipelines, proprietary data preprocessing approaches, novel curriculum learning strategies — may be better protected as trade secrets providing indefinite protection without disclosure. Training methodologies that are likely to be independently developed by competitors or that competitors could deduce from observing model behavior may be better protected by patents establishing priority before competitors file. Many companies pursue both — patenting the architectural innovations that can be inferred from model behavior while maintaining as trade secrets the training details that cannot.
Question: How do large technology companies use software patents strategically and how can a startup compete?
Answer: Large technology companies use software patents in multiple strategic ways: as competitive weapons to exclude competitors from technology spaces, as licensing revenue sources, as defensive shields against competitor assertions, and as assets that enhance acquisition value and investor perception. Startups cannot build portfolios as large as major tech companies, but they can build focused, strategically coherent portfolios that protect the specific innovations that drive their competitive advantage. A startup with three well-drafted patents covering its core technical innovations is in a fundamentally stronger position than a startup with no patents — both for competitive protection and for fundraising conversations. I help Austin startups build focused patent portfolios calibrated to their actual IP budget and strategic priorities rather than attempting to match enterprise-scale portfolio strategies.
[ Related Services ]
Clients protecting software and AI innovations often also work with me on:
[Provisional Patent Applications] · [PCT International Patents] · [Freedom to Operate Opinions] · [Trade Secret Protection] · [Startup IP Strategy]
[ Schedule a Free Consultation ]
Software & AI Patent Services
If you are building software, AI systems, machine learning platforms, or any technology where the core competitive value lives in code and algorithms, the quality of your patent protection depends directly on how well your attorney understands what you have actually built. I spent seven years as a semiconductor manufacturing process engineer before becoming a patent attorney — writing Unix scripts, working with fabrication control systems, and developing the hands-on computing architecture experience that informs how I approach software and AI patent claims at an engineering level rather than a legal description level. That starting point changes everything about how I identify what is genuinely novel in your invention, how I structure claims to survive Alice/Mayo scrutiny, and how I engage USPTO examiners in the software and AI art units who are themselves technically trained.
I work with Austin's software companies, AI startups, SaaS platforms, fintech developers, cybersecurity innovators, and enterprise software teams on patent strategies that build real competitive protection — not legal formality.
Whether you are filing your first provisional application before a seed round, responding to an Office Action that raised Alice rejections, building a continuation portfolio around your growing product, or preparing for Series A IP due diligence, I offer a free 30-minute phone consultation to assess your specific situation and explain what strong software and AI patent protection would look like for your technology.
Call or text (512) 293-0710, email sconnolly@austin-patent-attorney.com, or fill out the form. Consultations are available Monday through Friday, 1:00pm to 4:00pm Central Time.
All discussions are confidential under attorney-client privilege. No obligation.
Phone: 512-293-0710
Email: sconnolly@austin-patent-attorney.com
Location: Austin, Texas
Serving Austin, Round Rock, Cedar Park, Georgetown, and all of Central Texas.
USPTO matters are federal — I work with clients throughout Texas and nationwide.