All in the Prompt: Crafting AI Prompts for Precision Patent Drafting | IPWatchdog CLE Webinar

Welcome everyone and thank you for joining us today. We're going to have a conversation about prompting AI, crafting prompts for precise outputs. We're going to talk about not just strategy in a philosophical way. We're going to talk about how you actually do it, how uh we think it works best and give you some actionable insights or things that you can try on your own and see how you might adapt them to your own particular practice. So, um we got a lot of ground to cover. So what I'd like to do is just kick it over to Renee to introduce the speakers. So Renee, can you take it away?

Sure >> can. Thanks, Jean. On our panel today, we have Robert Deisio. He is the VP of intellectual property for Poet Technologies, where he leads development and management of the company's IP portfolio, supporting high-speed data communications and AI infrastructure. He brings over 30 years of semiconductor R&D and commercialization experience holding a PhD in engineering science and an MBA and is an inventor with 10 patents.

Next, we have Trent Merrill. He's a patent attorney at Talum IP Law with extensive experience in US and international patent law. He advises on global patent strategy, prosecution, and litigation with a strong technical background in computer engineering and biological sciences. Trent has worked both in-house and as outside council supporting innovations in AI, software, 5G, and advanced computing technologies.

Next, we have Daniel Rose. He's a partner at Pearson Ferdinand where he focuses on patent preparation, prosecution, and IP strategy across cutting edge technologies like AI, fintech, cyber security, and telecommunications. He advises clients ranging from startups to major public companies and is also recognized educator and speaker on software patentability and IP law.

Next we have Yuri Eleazer. He is the CEO and co-founder of Junior and a highly regarded US patent attorney known for securing high value litigation ready patents. He has advised companies from startups to global global brands like Microsoft and AT&T and previously led an IP practice at Founders Legal. With a background in engineering and entrepreneurship, he brings a unique blend of technical legal and business insight.

Our moderator today is Gene Quinn. He's a patent attorney and one of the most respected voices in patent law and innovation policy. He founded IP Watchdog in 1999 and today it's widely recognized as a leading resource in the IP community. Gene is known for his deep expertise in software patentability and US patent practice and has been named multiple times among the top 50 IP IP influencers as well as one of the top world's top IP strategists.

And last but not least, we have Marian Clay Hijam. Uh she's the chief re revenue officer at Junior. She's going to be available throughout the entire webinar to answer questions that are asked in the chat box. Uh so if you have any questions for the sponsor, you can ask them in the chat box. Back to you, Jean.

>> Thanks, Renee. And if you have any questions for the panel, you can put them into the Q&A box. I'll monitor the Q&A box. Since this is a Celely um hour, we'll also have a number of poll questions. We'd appreciate it if you would do those poll questions or at least do enough of the poll questions so that if and when anybody ever asks whether you were here and we can prove you were here, that gives us another way to know that you were here and active and paying attention. So, we'll sprinkle those in throughout the time we have with you here today. But, let me go around the horn to our panel, get everybody engaged in the conversation right away, right off the top here, uh, and get your preliminary thoughts on this topic of AI prompting and and how do you get AI really to give you the precise output that it is that you want? What do you want folks in the audience to focus on as we roll up our sleeves and start the conversation? Um, Yuri, I'll start I'll start with you. What where do you begin with this conversation today?

>> I would like to say that everyone in technology is starting to realize they need to be prompting AI in small businesses and startup companies especially down to up to the big corporations. our team, you know, it started with just the developers. Now it's everyone is prompting AI for every aspect of their job. Um, it's it's transformative in a way that's it's not going to begin to describe. You can build your own apps, you could build your own agents, you could build your own workflows, you could build a daily brief. It doesn't matter what it is. And so to the patent bar, we will be prompting two. We have trade secrets we have to be careful with. And so having the proper security in place is very important when you try this on your own, the proper privacy controls. And we'll also show you a couple of videos on how we do it. But this is not about how we do it. It's about how you do it and how our panelists do it and how what you'll learn. So enjoy. I we have a wonderful panel today. The discussions I've had with each of the these panelists show a different key insight in how our industry is changing and I'm excited for you all to hear that. Thank you.

>> Great. Thanks a lot, Yuri. Uh Dan, your initial comments.

>> Thanks, Jim. Um I think everyone is going to be using AI in the future. I think you know you want to be on the cutting edge of that and you want to be starting your use of it now to get used to it. Uh but I think the important thing to keep in mind is a healthy skepticism. Uh AI systems are autocomplete engines. They're not reasoning engines. They're not thinking engines. And you can't rely on them to do that. They can't replace the creativity and insight that we provide. But they can make us a lot more efficient. They can uh handle automation. They can take care of all the administrative tasks that get in the way from us being able to exercise that creativity. And so I think that's the primary thing. Think of ways you can use this as a tool to supplement your practice rather than one to replace it.

>> Yeah, I think that that's something that people need to focus on very specifically and that's another way I've said that over time is the human in the loop. The human needs to stay in the loop and that will be something I think we come back to throughout the time here today. Thanks Dan. Uh Trent, let's go to you next for your initial thoughts.

Yeah, I think just initially we're all busy. I think that with AI uh what I found is I I get back what I put in. So if I am creating a strong prompt, if I'm structuring it, if I'm giving requirements, guidelines, things to I guess guide AI in what what I want to get back from it. the more time I put into it, the better the the feedback I'm getting, the better the results, the better and more usable the information that I'm receiving. And so, I think even though we're all busy, I think it's it's worth it to spend a little bit of time trying to improve this skill, improve our prompt drafting skills so that over time we'll start getting that time back. We'll start saving time in our practices. we can improve our efficiency which will create more either more work for us, more money, more time with our families, more time doing our hobbies. I think it's it's a a great tool that if if we put time into it, we'll receive that time back uh tenfold or more.

>> Great. Awesome. I I do think I I agree. The more you put in, you you get what you put in. I mean, this is like, you know, it's not we're not at the place, I think, where it's a perpetual motion machine. AI is a perpetual motion machine where you get out more than what you put in. But you've got to put if you put in the effort, you get out really good output and we're going to show you that here today. So, thanks for those thoughts, Trent. Uh, and last but not least, Robert, what are your initial thoughts for the group here today?

>> Uh, my initial thoughts, uh, u, I'd like to say good day to everyone and it's a pleasure to be here, uh, with this group. Um my thoughts of course I echo what um Dan and Trent just said but um the the uh we um much of the uh drafting workflow can be can be reduced to mechanism mechanistic based u mechanistic rule-based processes. So where we begin to implement these these these promptbased um workflows uh can be the the risk can be minimized by by finding the best uh loca uh the the best parts of the process uh within which to implement them. So um so I would like to emphasize that um to minimize any risk right we we we take a very uh cautious approach to implementing AI um but um by identifying mechanis mechanistic rule-based uh processes that are more amunable to to prompting um we can minimize the risk. Um, so, um, yeah, that's

>> Thank you, Robert.

>> Great. Thanks a lot, Robert. Okay, so ne next in order, I think we have, uh, Yuri, you wanted to show, I think a quick video to spark the conversation um, so folks can get an idea of how this is done.

>> Absolutely. I think Robert properly introduced it. It's it's a um we like to explore prompt sequencing and using prompts and structuring and so we have a little video on how we do it here at Junior um for y'all to see. And I'm going to stop sharing my screen and uh we have some audio issues. Renee, you might want to try and enable the audio or whoever is controlling it. And it's okay. We can just play where from where things left off and with audio. It'll be fine.

>> Renee, are you there?

>> I am. For some reason, it seems to be dis uh disabled. It's not allowing me to do uh the sound.

>> I don't Yeah, I wouldn't mind if we come back to that at a maybe after Roberts then just to keep things moving along. We have a lot to cover.

>> All right. Sure. So, let's go to uh we'll loop back to that and go ahead. Uh take it away, Robert.

>> All right. So, first slides. Um well, I'll do a brief introduction. Robert's um you know a VP of IP at Poet Technologies and Robert you've got a very complic complicated complex technology you write up and uh your use of AI through that process is very interesting and and how you work with outside council and engineers internally. So floor is yours.

>> Right. Do do I have the slides coming up?

>> Oh, they're not shared anymore. Sorry, I I took them down. I pull. Here we go.

>> Do we see him now?

>> Yeah, there we go.

>> Um, so AI implementation and impatent drafting. So just just a brief introduction before I get started. So, oh, you can go to the next slide. So I'm going to talk about a drawing centric but but um so last year was all about uh security right we we you know I spent much of last year building a workstation because I thought everything had to be isolated but this year we're finding with the response from toolmakers software developers that that that those concerns have been largely eliminated right we what what started out um as uh as uh everyone holding things close to their vest to hey now we can communicate with these tools uh readily. Um the industry has responded with security standards that have really allowed us um ease of mind in in using the tools and and and sending our information out um where we would have otherwise been been a very um would have been very cautious. Uh this year however it's all about tool selection, defining your workflows, right? Everybody has their own workflows. Um and now we're forced to really sit down and nail really nail down each individual step in those workflows to try to find um uh areas where we can apply uh AI in a mechanic in a mechanistic way rule-based way that u that allow us to execute those workflows. And then we're um we're translating then these patent drafting workflows into prompt sequences and then ultimately um automating these prompt sequences. Uh I think next year we'll start to see the flattening of of knowledge gaps and other u gaps between uh in-house teams and outside council. So, what I'm going to talk about today is largely how we as an in-house team address um uh some of these these knowledge gaps uh with promptable workflows. So, yeah, thanks.

So, um these are some of the gaps that I've um that I encounter uh in working with outside counsel. So the the the um ter the what's in parenthesis there the OC or the in-house is where really where the the um the the particular item is is weighted. So technical knowledge of inventive subject matter right it's it's heavily weighted towards the in-house people. The inventors are in-house, the u the gatekeepers are in-house and and it's the ta the primary task of of the inventor and the in-house council to relay the information to outside council so that the outside council has a suitable amount of information to um to execute um the the patent drafting process and and coming up with a suitable set of claims. There are other gaps. Uh legal knowledge heavily weighted to the outside counsel. The impact of work product again heavily weighted towards the outside. It's the outside council that comes up with the final set of claims. Uh accountability, it's almost entirely in-house, right? The end result of the patent portfolio is really dependent on the in-house team. Uh or or the accountability is is is associated with the in-house team. Uh and then motivations. There are differences in motivation, right? in-house teams are concerned about coverage. Uh the outside council is they they have their own concerns right with profit and loss for their their businesses. So we can go to the next slide.

So, what we're trying to do with our with our in-house patent drafting process is to not necessarily come up with a final draft or or a final uh version of the patent, but a but to come up with a draft that we could hand off to outside counsel in the language of the outside council. Right? So, so what are we good at as as part of the in-house teams? We have direct access to the um to the um to the inventors. Uh we have direct access to the R&D teams. Um we can receive a disclosure and sometimes a disclosure could be as as little as an inventor email, an email from an inventor to a to a full-blown presentation or a technical paper. So we can take that disclosure and we can develop drawings, right? So we can better uh capture what the um what the essence of the structure is that the invention might be contained within. We do a lot of photonic structures um a lot of mechanical structures or and and we do methods as well but um we don't do chemistry molecules or anything like that. So we can take our these disclosures, we can develop the drawings. Um then we can categorize those drawings and then mechanically draft uh set up prompts to mechanically draft descriptions of those drawings. Um and then so so we've selected the the um the the creation of the the draft the uh detailed disclosure or detailed description and uh and then also the the front matter that can all be mechanized in the formation of a draft. Again we are not trying here to to uh complete the final product that would be submittable to the patent office yet uh but that that may come down the road. Then we take that draft and we hand it off to the outside council and it's it's the outside council's it's in the language of the outside council. It's in the form that they understand. It's not them trying to come back and say, "Wait a minute, I don't really understand the drawing or I don't really understand." Hopefully, we've crossed all those bridges and provide a a a fully described set of information to the outside council. So, I I have a feeling we're we're >> going through these slow, but but I think that that kind of forms the crux the crux of what I wanted to say. These um these follow-up drawings kind of repeat. U you can go to the next one. This is a

>> Well, I do have a question for you, Robert, here. Um if if I'm may in terms of claim construction ultimately who gets to decide in this process in in your process that you're proposing what will ultimately be the subject matter that that goes into that claim? Is it your team in this scenario now that you have let's say more robust AI tools? Do you feel more comfortable doing that or to what extent are you outlining the claim I guess is the question in this?

>> Yeah. So that that points out a significant difference between an in-house council or an in-house team and an outside counsel, right? We want as broad a coverage as we can get. We want as um we we want to fully describe the embodiment so that we can create a a a claims pipeline, not just a set of 20 claims that we're going to file with one one application. We want to know that we've got u assemblies covered. We want to know that we've gotten the the the intimate details of the of the um of a structure covered that we have um you know the methods covered. Um so so it's a little bit of back and forth. Uh but from our perspective we want to make sure that the drawings encompass all of those. Ultimately um it's a it's a it's a discussion that happens between outside counsel and and and with us but >> right >> so it's a little bit of both a little bit of discussion that goes both ways >> so you mentioned that one of the biggest time s you know time constraints that costs a lot of time rather is educating >> we're forever educator >> how is AI in that pro reduced maybe how some of that time can um in this >> well well it there's a significant reduction in the time if we can provide a document to the outside council that's already in a form that they understand with very detailed drawings right we want to ex we want to expand on the drawing set we want to expand on the description of the embodiment and then we want to hand that information so AI has made that process so much easier right the drawings um that's something we've we've somewhat always been committed to right we want to provide the drawing set. We don't want a set of dotted lines. We don't want to hand off a set of dotted lines to drawings to a to an outside council and have them interpret it. Right? So, so we've always invested the time in creating drawings that are uh that are understandable by the outside council. So AI has then allowed us to provide very extensive descriptions in the form of a drafted patent in the sections that would be uh ultimately drafted in a final draft um in in a very systematic way. We we can we can implement these um we can take these drawings as the basis right you with any AI system you want to have strong inputs. Our strong inputs are um uh are the drawings and the and we'll compose expanded brief descriptions for those drawings so that we can then build upon using AI a the f build upon uh take the expanded brief descriptions which is textbased something that AI systems tend to like more than drawings uh but then we can combine them with the drawings and come up with Uh

>> so let me yeah let me let me propose this and you know I was trained to be a claim ccentric >> drafter uh but now with with you and and your AI stack of prompts and your process is drawing centric because as you mentioned you have to educate the attorneys before and the best way to do it is not through claims you don't start with that you kind of go by drawings and you build out the description of the invention and you found a prompt sequence quence that helps you write that application exactly as you like it using a drawing centric sequence and I think here on the right you outline it. Do you want to uh just um tell us about that those four steps?

>> Right. So in a in a drawing centric approach uh we create the drawings, right? That's the that's where our uh our f our effort is made to really really think through what the invention is, right? Um and and all of this has to be supported with prior art searches. So it's not like it's not that we're doing this in isolation, right? We're generating the drawings. We're defining uh we're we're starting the drawings with the the idea, right? The invention, the the feedback from the inventor. The inventor comes up with an idea. He says, "Oh, I got this great idea." Now, we take that baton and we we create a set of drawings that um and we interact with that inventor until we we have a what we until we feel that we've really captured uh the invention. Um then we can ex create an expanded description of that drawing. From that we can uh from that we could uh uh mechanic create a set of prompts that kind of mechanically translates um those drawings into a brief a detailed description. Um and and much of that is mechanical. It's not that um we can avoid any hallucinogenic effects or anything like that by by making as mechanical as possible. Okay. Get the AI to see what type of drawing it is. Right? There are only a few different types of drawings that that we that make up 90% of what we see. Right? It's a structure drawing. It's a method flowchart or it's a it's a um it's an enablement support document or a drawing that might be a uh a graph. It might be some data. It might be a a picture of an apparatus that enables the um the invention to be executed. Um, so, uh,

>> well, thank you, Rob, for for that, uh, outline. And I guess the the concluding, uh, remark I would have you you address is great, you use AI to help prepare a first draft. It's going to be really good. And over time, I imagine that they're going to get excellent before you send them out to outside counsel. But uh we still as outside council have to fully read understand the invention well enough for you to trust us to structure the claims that you've already kind of built a pipeline for but ultimately we're prosecuting those claims. Right. So um >> how much time do you expect outside council to be saving with h with your new process AI augmented process?

>> Oh hours hours and hour 10 hours. Uh it it's significant because they don't have to go there's no back and forth. We're a limit. We're we're >> there. Yeah, there will there may be some >> interaction. There will always be some interaction some questions that arise but but um yeah I think significant.

>> Thank you. I appreciate Robert and maybe chime in throughout the discussion. Uh let's move on to Dan Rose. Now Dan has, you know, an interesting code to claim patent drafting process that he will share with us today.

>> Well, thank you, Yuri. I think Robert and I are dealing with the same issue, but from different ends of the spectrum. He he's in the house. I'm outside counsel, but the issue is getting the best disclosure you can and and the most guidance for the person who's ultimately drafting the patent application. And I I do a lot of work with startups where they don't have in-house counsel who can help drive that. And so a lot of times a reoccurring challenge is that the written disclosure that we get is often not that helpful. It's incomplete for drafting purposes. It's very high level and abstract or it focuses on what the inventors think is important but not necessarily what the system is actually doing at the level of detail that we need to develop strong claims and write a a robust spec. So the shift that I've made in the right cases is to get closer to the underlying technical material and not just a polished disclosure and not a high level architecture deck but sometimes the actual code base and that wasn't always a routine ask in practice or practical barriers. Most of us attorneys don't want to spend lots of time digging through source code, but AI kind of changes that equation and it gives us a way to review a code repository more efficiently, summarize functionality, identify relationship between modules, and orient ourselves much faster than we could before. And the point is not that AI is drafting the application for you. It doesn't, and I don't trust it to do that. But the point is that AI can help you understand the technology more deeply, which puts you in a better position to draft claims and shape that disclosure. So this slide is a a workflow that's a practical version of that idea. Uh first I obtained the full code repository and that does represent a meaningful change from in this approach from what I would have done in the past. Uh it's becoming much more normal now especially with smaller startups. I use AI tools to summarize the code, map relationships between the components and identify areas that appear central to the invention. And importantly I'm not asking the model to tell me what it thinks is patentable. I'm using it to help me understand what the code is doing. Uh I then manually verify the output and that step is really essential. If the model describes a function in a certain way or identifies a relationship between modules, I go back to the source and confirm it because I'm not going to trust what the AI tells me right away. But it helps me find those sections and look through the code and see where different functions are referenced. Then becomes an iterative understanding. Take multiple passes through because one pass is rarely enough. uh I may begin with a broad highle summary then move into subsystem level reviews and then drill down into particular routines or interactions that I think are important and then compare that back to what the inventor told me at the beginning for their explanation. Only after that do I move into targeted claim drafting and at that stage I'm identifying particular functions and interactions and technical features that I want to capture in those claims. And finally there's substantial editing. The AI output is just a starting point not an end product. It can help us accelerate understanding and drafting. It can relieve the uh blank page syndrome. Just getting some text down there on the page, even if you then delete it all and start rewriting from scratch, helps a lot of times, you know, otherwise you get paralyzed staring at the page and not quite sure what to what to start with. And AI can help with that. It still requires significant practitioner judgment and revision, though. The analogy that I often use is that this is similar to examining a physical prototype in a mechanical case. you know there it's kind of the best way of understanding the invention to actually be able to pick it up take it apart look at how it works inside with code we can do the same thing and AI really helps us do that efficiently and fast you can go ahead thank you uh this slide captures the use case that really convinced me of the value of this approach uh I had a matter where the original exposure was simply too light to support drafting it wasn't useless but it didn't provide enough depth to move forward comfortably especially with regards to patent eligibility where we really need the low-level details, not just the highle abstract idea. In a more traditional workflow, that would probably have meant multiple rounds of inventor interviews, going back and forth, reconstructing the architecture and understanding those mechanics of the system. Instead, I just asked the inventor to give me access to the code repository. I did that, used AI to summarize it, organize the code, gave me a much clearer picture of how the invention actually worked than what the original disclosure did, and surfed relationships and implementation details that the inventor had overlooked because they were used to them. They had been working with those for months and didn't think that they were all that important. But I saw that there was some really crucial parts of the code there. So that saved time, but more importantly, it improved understanding. And to me, that's the real value proposition here. Efficiency is helpful, but the stronger benefit is substantive clarity. I want to write the best patent application I can, and AI is a good way to get there, not just to get faster. So, the takeaway from this slide is that using AI with code can function much like examining that physical prototype, and it can reveal aspects of the invention that the original disclosure may not fully capture. Have you had a problem in getting your clients to, you know, input you into their codebase or give you access to that or is that generally um cool nowadays?

>> Honestly, it it hasn't been that hard. I I'd say the bigger push back has been from larger companies, but then you've also got the benefit of in-house counsel where they can have better access and do that sort of thing on the inside. For smaller startups, no telling them, you know, here's my GitHub account. uh just add me as a viewer on your repository and that's usually pretty straightforward.

>> There's a you know MCP access now or you know different ways to access that data. Um it'll be interesting to see how this integrates.

>> Yeah, absolutely. I think um for prompting uh the most important strategy and lesson that I I've developed and take away from this is that narrow prompting beats broad every time. Uh when I work with code, I don't ask the AI broad questions like what's patentable? Uh because that tends to produce output that is overconfident, biased, and not particularly useful. If I just take it at its word immediately, I'm probably going to miss stuff. It may not be right. I won't know. And that's I think the biggest danger of AI is not knowing when the answer that you're getting is a hallucination or not. And so you really have to check every time. Um or just don't rely on it for that. Instead, ask much more specific questions. So I start with what I want analyzed or claimed. I make the prompts progressively narrower each time. I specify certain functions, the system boundaries, the interactions, the technical points that I want to focus on. And then I run multiple passes each time making the prompt a little narrower, really tightening down onto whatever aspects that I think are the most important. And that matters because AI output can create anchoring effects too. If the model characterizes the invention in a particular way early on, then there's a real risk that you start thinking of it in that way too. even if you disagree with the AI and you start going in the same direction but it it kind of guides you down a path and you may find it difficult to move from that path. Just for example with claim drafting if you ask an AI for a claim and it gives you a serverside claim you may just start thinking serverside claims serverside claims and never turn it around and say what about client side claims or what about intermediaries in the system you know what are they doing the AI can kind of guide you down that path and get you stuck there in some senses

>> I think uh Dan there's um in another interesting approach that I would layer on this and that's after you're done. You feel like you you and the AI have come to some consensus as to what you like. Um, now tell me why this is terrible. Tell me why this is going to get rejected. You know, tell me why this is naive. And asking the AI those those kind of questions, it really reduces the all the confidence you've built up to that point on that matter working with the AI. It's like, oh man, it's so it's quite persuasive in the way these different models communicate with you. It makes you feel intelligent and not question it as much. So,

>> yeah, Yuri, no, it's a great point. Um, having the AI query you about the invention is a great way to help solidify your understanding. You I like to say that you don't really understand something until you can teach someone else what it is. you know, if if I can explain an invention to my 90-year-old grandfather, then I understand it a lot better than I would have if I couldn't do that. Um, you know, and and one of the things AI can be useful for is replacing those sort of water cooler conversations where just saying, "Hey, I'm working on this cool invention. Here's what it is." And and you work through and kind of figure out what it really is under the hood and having an AI as someone to bounce off ideas off of. you know, just relying just using it as a recipient rather than a guide can help you solidify your own understanding and make sure that your arguments are better. And that also works for office sections. I know we're talking about patent drafting, too. But for off sections, having an AI, you know, spitting your argument into it and then asking it what's wrong with this, why why is this argument weak? How could this be stronger? Is sometimes really helpful.

>> So, I'm wondering here if you shared um Oh, there it is. I think um

>> you shared a prompt with this. Oh, I think that's Trent. But

>> yeah, Trent Trent did I think.

>> So, let's

>> But yeah, just continuing here. Um, I want to be candid about the limitations in patent drafting because I think this is where expectations need to rem remain realistic. And I think we as patent practitioners uh have a particular risk here. Uh we, you know, we've certainly seen news stories from across the legal world of people using AI in drafting responses, motions, and things like that and coming up with hallucinated cases. And those are are very public and very embarrassing. But they're also relatively easy to check cuz you can go and look up whether the case actually says that and does it say that thing. It's a little more different a little more difficult on the patent side because we're not necessarily looking for case law. We're looking for what is an important part of invention or what what's a crucial aspect? What's a key aspect? And so when an AI hallucinates something, you don't necessarily know and there's not really a good way to immediately check that the same way that there is if you know check whether the case that it came up with is actually from that circuit. Uh and so you have to be skeptical. You you have to always check and bear that in mind and realize that AIS are not reasoning engines. They're not analytical engines. They're autocomplete engines. They're they're really good at filling in the next most likely words, the next most likely sentence for something that it saw before, but not very good at coming up with something new and non-obvious, which is what we're looking for as patent practitioners. So, you know, specific limitations I run into. Uh, AI generated claims are generally not filing ready. They're roughly equivalent to what I get out of a patent agent with a couple of months of experience and usually require rewriting. Um, you know, it's not something I'd use immediately. Uh, another issue is limited expansion. If I provide a disclosure, a flowchart to an AI that says, you know, step one receive data, step two, process the data in some way. The claim that I'll get back will say step one receive data, step two process the data in some way. there there's no expansion there about what that means where it's receiving data from what the data format is in what you know all of these additional details that we need to add to the specification in order to be to be complete and have enablement um multiple actor problems a lot of times the claims that I've seen AI draft have multiple actor issues with both servers and clients in the same claim things like that uh alternatives they there can sometimes be multiple alternatives in a claim saying you know receive a packet that has this and do this and receive a packet that doesn't have that and do this other thing. A and that can create issues where you can't actually infringe that claim. Uh for figure generation of flowcharts, I know Robert is using it in a different way, but he's driving more into those prompts and what comes out of those. If you ask an AI to just make a figure off of your claim, you'll get something that looks like a straight line flowchart with all the steps copy pasted into the boxes and that's just not helpful. Um, so while AI can help you get started, you can't rely on it. You you shouldn't use it to replace your own judgment.

>> And I'd like to quote Jason Chang from from AT&T here. He was on a panel with me a couple weeks ago. and he has his team consider drafting a first claim without AI because as soon as you see one way to claim it, it could bias you forever and you're you're you're locked into that.

>> yeah, absolutely. Uh if you want to go to the next one though, um you know, so that that was all limitations, but I think there it's equally important to say where AI does con consistently have great value. Uh, and so first, editing and cleanup. You know, this is one of the least glamorous but most useful applications. I say don't don't treat AI like it's a lawyer. Treat AI like it's an English major or an editor cuz it can be really good at that. Checking that all your acronyms are spelled out the first time they appear. Making sure that your terminology is consistent throughout the spec, that your elements are numbered properly. AI and automation is really good at that stuff and frequently much better than humans. you know, we we've just, you know, you you spend 10 hours drafting an application, your mind's kind of going numb at that point. You've seen these sentences over and over and and so when you go to read it, you know, closely and proofread it, frequently you gloss over stuff and you'll miss things. You know, that's why they tell people when proof reading their work, read paragraphs backwards. Read the last sentence, then the previous sentence, then the previous sentence just to break it up so that you're not reading it in the same way you were before and can't just slide over it. AI doesn't have that issue. you can shove us back into AI and say, you know, make sure that my grammar is cleaned up. And it does that a lot better than the built-in grammar checkers in Word or things like that. Uh, second, code analysis. And this is especially valuable when working with unfamiliar languages. Uh, like, you know, Swift I'm not that familiar with. I've done a little bit of programming there, but not that much. So, dumping something into in Swift into an AI and saying, "Summarize this. Show me a map of the function. Show me what relates to what." it's really good at and helps me then come to a greater understanding of what is actually going on under the hood. Uh, and third, large context synthesis. You know, this happens with code bases where you've got lots of different functions and lots of different libraries being involved. But even in in other times, I've gotten from inventors, you know, functional specs, copies of standards, technical documentation, pseudo code, a photo of their whiteboard. And taking all of that and piecing it together into a coherent system that I can then look at as a sole thing and understand is really helpful. you know, asking an AI, show me in all of these documents where it discusses this particular function and and put them all together into a single document and what does that mean? Uh, that is really helpful. And so, I think generally using AI as your support team to help you get down to your core function of being a lawyer is is really helpful and I think where we're going to be in the future, five years, 10 years from now, as this becomes a lot more routine. Thank you, Dan. It's quite excellent uh presentation.

>> Thank you.

>> Yeah. Um Jean, do you have any comments or we move on to the next uh

>> Well, I think, you know, given the time, we probably should want to make sure we give Trent the opportunity to go through what he wants to say and then we could loop back and get to as many of these questions as we can.

>> Absolutely.

>> Sure. And I I've been keeping an eye on the questions. So I'll try the ones that I can remember as I speak. I'll try and address as I go through my slides. U you can go to the the next slide, Yuri. So I I'm just going to walk through uh a possible prosecution appeal workflow. This works equally as well for office actions and it doesn't take much imagination to apply it to drafting patents either. Um, in the initial stages, I like to use structured prompts for issue spotting when I receive an office action. Uh, helping the having the AI be, you know, my junior associate or someone who can go and and dig into some of the information before I do or or at the same time as that I'm doing it. Um, to identify possible issues, uh, surface, you know, weaknesses of the rejection and to organize the record for analysis. And I guess upfront I should say I also use platforms that allow me to uh input the record. So the AI tools, the large language model that I'm using is pulling from my specification from my own invention disclosure transcripts from the office action themselves from the uh cited prior art for the all of these things. So I have this closed universe that I can really try, you know, have my LLM focus on this closed universe before it starts reaching out into what is available on Google or or to the rest of the the internet. And so I'm using AI as my junior associate to go and help me find the information I need so that I can then make the strategy decisions that I can still be the lawyer. It's just doing some investigative work for me. Then when I start drafting, I use I call it a a humanbuilt uh AI populated argument framework. So I create the framework. I'll show you an example of what I do just, you know, very bare bones version of it. Uh but I create the argument. I've found in office actions, a lot of my arguments tend to look the same. Uh, and so the the portions that do look very similar from response to response, argument to argument, I've created sort of a template that has prompts within it and blanks and things like that that I can give to the AI and just see, you know, what it gives me back. And then I use the AI or the LLM as a reviewer. I assign it distinct roles. And I'll get into that. Uh so we can jump to the next slide which um so for structured prompts when I'm initially looking at an office action when I'm initially considering appealing you know with the examiner and I've reached an impass and so we're moving toward appeal uh I will use the AI as a co-worker. So I have structured prompts that help with issue spotting analysis and I have some more examples. Let's we can just move to the next slide too in the interest of time. It has much of the same information. Um yes there we go. So with it I def give it a defined role. Uh you are a junior patent associate who is reviewing an office action uh to determine whether or not you know these these situations exist. Uh I set citation requirements. I think a lot of us who have who have dabbled in LLM and and AI use uh find that we get back information that is good but it's not always correct based on the record we're dealing with. Sometimes we could ask for a a claim. What would you how would you recommend amending this claim? And they come back with this great amendment but it's nowhere to be found in the record. Right? So, one of the structures that I include in every prompt that I do is I have these strict citation requirements. You must site specific passages for every disclosed element. Everything you tell me about the prior art needs to have a citation of where it can be found. Uh if you're uncertain, say that it's uncertain. Distinguish the facts. Uh do not make legal conclusions. do not. So I create these specific requirements to set guard rails for wi, you know, within my prompt for what the AI can do, what it cannot do, and what I'm trying to reserve for myself. Um, in the scope of review, uh, unsupported. So this is the issue identification, unsupported mappings. Maybe the examiner has handwaved and we've probably all seen it once or twice maybe where they handwaved

The rejection. Uh, it feels like the reference might be teaching something in that direction, but it's not teaching our claim as it's recited. Uh, and so the AI does a pretty good job of spotting those things where the examiner is applying the art very broadly and probably overreading what's being taught. Um, it can look for lacks of motivation to combine. I've not found that great success yet in this one. Uh, usually it will talk about, well, here's what the motivation to combine that they offer is, and then I still dive in. So, sometimes it's more of a a smell test.

When I get back the results, uh, from that analysis, uh, if if everything looks to be in order, uh, then I'll dive a little bit deeper. But again, I'm using this as sort of a coworker. I'm I'm meeting my LLM at the at the the water fountain and we're we're talking about the case and what we can move forward. Uh, claim construction defects, prior art qualifications, inherency thing arguments. So really, I'm I'm asking AI to help me do the issue spotting, find things that I might not have on my first pass. Uh, and then it also confirms some of the things that I'm looking at and thinking about doing.

Um, it can give case snapshots. It can do claim decomposition, uh, can pull all sorts of things from the the record and put them into one format. And so with these structured prompts, I then have a structured output so that every time I'm using this tool, every time I'm using this prompt, I'm getting the same output. So then I can start judging the output. What do I need to tweak to improve it? Um, how can I improve it? And then I also know where to look for specific information.

And so sometimes when when we're working with LLM one day, we're getting great output and we do the exact same thing another day on a new chat or in, you know, if we're working in an enterprise system, we're working on a new uh chat that doesn't have the previous day's knowledge, um, then it gives output in a totally different different way, different format, different even language style sometimes. And so by creating these structures, by telling it this is your role, here's what you must do, here's what you must not do, and then giving it sort of a a structure of of how you want its output to be, then you start seeing things better. It helps you be more efficient. It gives you the information you're looking for in the way that you're wanting to see it. Uh, and that just helps as we begin our analysis and start strategizing and changing our strategies.

Then then we can um uh improve our prompt and and we can accept or reject it. Uh, when I get to the argument portion after I've had used the LLM to help me find the issues uh and gone through and developed my own strategy, I create templates for myself uh structured legal framework, structured arguments uh where I am doing the drafting. I'm drafting the argument, but then there are some portions, you know, that just take time to fill in from the record. And so, uh, on the next slide, I think I have a little bit more information.

Yeah, this is an example prompt for a 101 argument. And I use something like this when I'm drafting. I use it in office action responses, things where I know that I'm going to be using similar language or the same or similar argument. I can create a template like this. So, this is very bare bones. You can use it. I would definitely recommend you expand it uh for when you use it. But here in the the brackets, I'm asking the AI to go into my specification, find the problem of the existing technology as I've described it in the specification and then summarize it here. And then implementations of this invention address the foregoing problem by providing blank. And then it goes into my record, pulls out the inventive concept, and I ask it to key in on the feature, especially if I'm amending the claims, uh, ask it to key in on that feature, and use that as my argument because that's the new piece. And I, so I build out these arguments with these blanks or with these brackets, and that is what the AI is filling in for me. It's not inventing the argument. It's not creating all of this stuff. I have the strategy. I'm drafting the argument. I'm just using the AI as a helper to fill in the gaps. It's my argument. Um, and and it is pulling from the record to to fill in these blanks.

And so then after I've drafted it, I like to use AI then especially in sort of in an appeal situation. AI, you are now the PTAB judge or you are the examiner that's going to respond to this appeal brief. What expected response can I will I should I what response should I expect to receive? How will this argument be uh received by the PTAB judges? Push back. Would the board push back? And I ask for this board push back simulation. Why would this argument be rejected? What are the chances of winning this? Um, would they reject it? Would they discount it? I ask it to check my uh citation discipline. I ask it to check my tone and my credibility. If I'm making six arguments, which of these arguments are the least likely to win? Do I lose any credibility with the board if I make this argument? Does it look make me, you know, how does it change how the appeal brief is accepted if this argument stays in? And I just bounce ideas back off of it by giving it again a role. This is who you are. You're a senior attorney, you're a PTAB judge, you're an examiner, uh, check this appeal brief for these issues and and and by giving it again these structured prompts struct with with a structured output style that you're asking it to give you back, it will help your work be more efficient. It gives you the information in a format that you're looking for so you can digest it easier, so you can audit it easier.

So, as you're going back through and checking, which we should be doing with all of our AI uh generated content, um, it's it's easy to go back and see, okay, this is where it's coming from, especially if we're requiring it to follow our own citation guidelines. Pull everything from the record. Tell me where from the record you got it from. Um, and it it really has been a benefit to me. Uh, again, I mean, you can go back to the next slide, Yuri, where you just advanced it to. Uh, I don't ask AI to invent the arguments. I build reusable templates then I that I leave the fact dependent portions available for AI to come in and save me 10 or 15 minutes to fill it in. Uh, it it's a lot easier to audit what has been you know, inputted, what AI has given me versus coming up with it myself or going and finding it in the patent, copying pasting, changing the format, all of those things that it really helps uh to have AI populate the record again. I keep speed but without surrendering the judgment, uh, without surrendering the strategic decisions that are important for me to keep, uh, but I use it as a coworker.

And so I hope some of those prompts I gave bare bones, you know, examples. If you have any questions about those prompts or if you're wondering how you could implement it, I've found >> uh, you can just hop into whatever LLM you're using and say, I'm looking for a prompt to analyze prior art to see if this feature has been taught. Give me the prompt. And it gives it back to you and it's something that you can implement and use in your own workflow. Trent, that's that's excellent. This is a great example prompt. I would also, in light of the output you get in response to such a prompt, suggest that you require as a rule that everything the LLM outputs is supported directly in the specification. Because a lot of times practitioners take a look at the output, oh yeah, this is great. This is a good argument, but that they don't go back. They assume the LLM knows it's got to be supported in the spec, but without a tool that's properly constructed and prompted, it won't be doing that. It it doesn't know to. Right. >> Absolutely. Yeah. And and that that's one of the reasons why in my workflow I have that strict citation policy. Everything that everything that the AI pulls from the record, I need to see what paragraph or page number that it's coming from so that I can go and audit it real quickly. Um, because that I I mean that's something I ran into as I was starting to use AI and I thought I was getting garbage output and it turns out that I think I I just needed to improve my prompt, improve the input so that it could it better know what I was looking for and and to get back absolutely check everything. Um, that sometimes will try and make up its own stuff if you don't give it the right guidelines. >> I mean, we we should be used to doing that anyway. You know, in in an office action when an examiner quotes some sentence out of a piece of prior art, you need to go back and check them actually says that and and what the surrounding sentences say already. So, you know, why should we suddenly abandon that when it's AI? >> Absolutely. Yeah, great great comment. Uh, Gina, Mike, Mike mic is yours if if >> there is one question that we could probably get to in the time that we have here that kind of I think does go along this lines of um prompting and also it picks up I think on something Dan you you had mentioned earlier about how you know you you really need to know what good output looks like um, you know, if to decide whether you're getting it and you have to verify as Trent was just and you know, what what it comes out with so that you know you're not dealing with garbage or some kind of hallucination or something that maybe is just taken out of context, even not necessarily hallucination, but it just, you know, took something out of context, right? So we all know that because we've all been in this industry for an extremely long time and you can look at something and it's like, okay, well, that's just crap, you know, like you get a bad back in the day, you get a bad search from India, you'd look at it and say, okay, I know there has to be better prior art than this, throw it away, start over. What advice do you have for somebody who's younger, less experienced, maybe not even just starting out, but has less experience and so because you know the old rule was is you got to see 25 cases probably from start to finish before you're ready to do this on your own, you know, and but that takes that can take four or five years to get all the way through 25 different cases, right? So what is a person to do who has, you know, maybe some real experience but, you know, is still struggling to fill those gaps in their knowledge? How do they know what they're looking at is good or bad? >> That is an excellent question, Jean. Um, other than other than just time and experience, I don't know that there's necessarily a good answer. I think when it comes to to AI, you have to treat it as untrustworthy, as as eager. It's it's like a little puppy. It really wants to please you. It will say anything that it can to make you happy. Uh, even if it's a complete fabrication. So, you just have to not trust it. Always go back, check your sources. Yeah, it it's great to work with, but you have to go and and do the leg work and make sure that it's right yourself. Um, you know, how do you develop that instinct for when it's immediately wrong? Uh, I don't I don't know that you can without experience and time and I don't know that you necessarily should because thinking about it, AI is going to get better at sounding reasonable >> uh, because that is one of the things that it's very good at. Um, and over time it's going to start putting out better and better outputs that are more like what you would expect it cuz especially if if you know it has some feedback in there where it's being penalized when you're saying no, that's wrong. Um, then it's going to start training itself on your particular responses and and work to come up with responses that it thinks that you will appreciate better. Uh, which may still be wrong. So I think you almost have to always go back and check uh, because and you can't get complacent about saying, well, this looks right, even even with the benefit of my, you know, decades of experience, because it could still >> Trent, any any thoughts on that? Robert, I'll ask your thoughts on it as well, but Trent >> I mean, I don't think that you can replace experience. I think uh, it's such an important part of of growing and and learning as as an attorney of having mentors that you can learn from. And I think it's it's important to see what quality looks like before you can start really analyzing the the output of AI. I think it's easier to detect the hallucinations, easier to detect, I mean, because some hallucin using hallucinations as a broad term, right? It's just things that shouldn't be there. And I think it's difficult for would be difficult for a first, second, third year associate to detect those things. Um >> Yeah. >> And and so I think it's a you can't I don't think you can replace true experience with with an LLM. >> Robert, your your thoughts on that? >> Yeah. Um, I I think we're in the middle of a a a fairly significant transformation, right? And so we have to be judicious about how we bring bring um these AI tools on. Um, so to minimize um the the um the the hallucinogenic effects or whatever the the the untrustworthy aspects, uh, we choose u areas where we can be re be more reliant on the tool. Um, I I noticed your poll question. Uh, writing the detailed description from drawings and embodiment kind of makes that case, right? Uh, you don't need a lot of judgment. It can be mechanized, right? So the feedback that we'd get um in mechanizing um allows us to uh examine the output from an AI system and and get it um get the experience with it in an area that's not so uh pivotal, >> right? >> It's important but not pivotal. Well, and also well, so maybe I'll throw my answer out there for for this, and I know we've we're over the hour, so everybody successfully completed the CL hour, so we'll wrap up here very quickly, but but my thought about this is is looking at the doing these things in, you know, bite-sized chunks and and telling it, you know, you don't say, you know, here's a here's a one paragraph disclosure I got from the inventor, write me a patent application. I mean, I suppose you could do that, but I think the results you're going to get from that kind of, as we're saying, very broad prompting is is going to be very dissatisfying. And you may based on your experience, not really know that that output is not great, right? But if you say, okay, hey, I need uh this, I need to describe this figure, you know, I need to describe an alternative embodiment that has these things in it, you know, and you give it very discreet tasks one by one by one, then when you get back, it's much easier to know what you're getting, right? And that may be as you're first starting, probably the way that you need need to do it and you go little by little because you're not only learning patent law and drafting. You're learning AI drafting and techniques and you have to inch forward. You can't leap forward. You know, there's no shortcut. There's no magic button here. There's no way that we can impart you with 30 years of experience all at once. And that's what you want. AI doesn't do that. But you can incrementally get there purposefully, I think. So, Yuri, let let me give you the final word here. Um, what what say you about I mean, we had a this was a great conversation and lots of real good ideas and tips that I think people should probably go and try and weave in themselves or test themselves and see how it works in their own systems that they use and then their own workflows. But what what's your final takeaway message to the audience? >> Uh, thank you, Jean. Prompting is is a real um next step in what we have to learn as practitioners and in fact arguably what most professionals, most knowledge workers will have to learn and I'm grateful for the panelists who have presented their techniques um in Trent, your case, your specific uh example prompt, thank you. And we devoted the last three years of developing prompt sequencing technology. I'd love for you guys to check out what we've done at junior.law. Um, and as the panelists say, it's not your one-click magic button. It's your structuring of prompts and how we've built that in to where you work and so it doesn't interrupt your workflow. So, we had a couple videos cued, but I think in interest of time, we're we're out of it. And so, um, please reach out if you're interested and we'll connect you with any one of these panelists if you'd like to learn more about how they work and their structures. >> And we can make sure everybody can get access to those those videos so you can see a little bit. I know a lot of you are are interested in getting a a demo. We'll pass that information on to to Yuri and his team along with all the questions that we were unable to to get to today. So, we'll make sure everybody can get a followup. Um, so that's all the time we have for today. I really appreciate you spending a portion of your day with us and we hope to see you soon. So, good luck everybody and have a good day. >> Thanks. Thanks, sir.