Legal Case Summary

We have four cases on the calendar this morning. I can case from a district court, a patent case from the PTO, a trade case from the Court of International Trade and the government, government employee case, so we submit it on the brief and therefore not the argue. The first case is from the district court, data pern versus blazing at out. 2013, 12, 51 and 52. This is the bell. Good morning, Your Honors. I'm Eric Belt of MacArthur in English, a representative turn, and thank you for hearing us today. There's a single issue in this case Your Honor. It is the claim construction of the term from claim one of the 502 patent employing the map to create at least one interface object. Now, let me just tell you briefly how we got to this point so that you can better understand the background. As Judge Moore may recall, there were two cases, two sets of cases, one pending in the Southern District of New York, one pending in Boston, the New York Court reached claim construction first. At that point, in the Boston case, the parties disputed whether the New York Court's claim construction would control until this court had a chance to rule on the terms. And the end result of that dispute was that data turn conceded non-infringement of one term. If that term employing the map to create at least one interface object were held by this court to have been construed correctly by the New York Court, then we conceded infringement. And that's why we're here on appeal today. So when I refer to the district court, I am referring to the New York Court's claim construction in the Mark Minoritor, which is part of the record of this case. To set the stage for what the court did here, it may help to have also a very brief explanation of the technology. In the Mark Minoritor, the... Why don't you focus on what the patent says? Okay, thank you. It's this

. A lot in there that's what you're really dealing with. All right. So that's what I was getting to next, Your Honor, and really it's what the patent says, of course, that control. And we're going to start with the claims. The claim says employing the map to create at least one interface object. The district court wrote into that phrase that the term create means to generate code for at least one class and instantiate an object from that class. It's not in the claim. There's nothing in the specification that requires that phrase to be written to the client. The specifications say a code generator is employed to examine the relationships fine in the map well, et cetera. It doesn't... It doesn't discuss the case. It says you're with the claim means. The specification tells you a preferred embodiment of the claim one embodiment. Is there another one? Yes, there is, Your Honor. So I'll take you through two figures. In one figure, figure one, Your Honor, in figure one, you have one way to generate an interface object through a code generator. Now that's claim 10. Claim 10 specifically calls out the use of the code generator. Claim one does not

. In figure one, there's a second root. And the district court recognized that. I believe it's on page A118 of the record. It means the double arrows. The arrows between from the map to the runtime engine to the interface object. And the runtime engine that's talking to the map and creating the interface object. And we know that because when you go now to figure seven, Your Honor. Figure seven shows, first of all, is described in the text of the specification starting at column six around line 31. Figure seven illustrates, I'm quoting, figure seven illustrates the sequence of actions that take place when a business object creates, there's that word, creates a DSL object in step 61. DSL object, I think both parties agree is the interface object. And so figure seven is talking about the dynamic process of creation. And that if you look at the claim wording. But isn't that utilizing a runtime engine? Figure seven is a diagram that illustrates operation of the runtime engine. Isn't that after the operation of a code generator? It could be your honor, but the claim one doesn't specify when or if a what happens with the class from which a interface object is instantiated. That claim one simply requires instantiating an object. And that can be done by the runtime engine itself, that it doesn't have to be done separately, that the runtime engine could actually cause that to occur. That's what I believe figure seven is showing the runner with the caveat that. And so your figure your claim one, the third element says utilizing a runtime engine, which invokes at least one interface object, you would say, OK, there, the runtime engine has to do it. But the employing the map to create at least one interface object can be done by a code generator, which creates a class and then instantiate an object or, and that would fall within this claim or alternatively. It could be done by the runtime engine pursuant to figure seven, which instantiate the claim that that that that entisities an object that claim one doesn't expressly claim creating the class by code generation. That's the next of our argument, your honor, which is claim one that step employing the map to create at least one interface object is silence as to the method of creation creation in that sense

. The kind of problem though, just so you know, which probably causes us and possibly even district courts to get off track from the technology is that throughout your brief, you keep objecting to code generation. But that's not your actual objection, your objection is class creation, your objection is we can use a pre existing class and then use the runtime engine, which by the way generates codes to instantiate the object. So if your argument isn't that code generation can't be or is never employed or doesn't need to be employed, it seems to me that your argument is that this all is about the fact that the claim doesn't require or limit us to creating a class through the code generator, but rather allows for use of a pre existing class. But that isn't the way you argue it. And that's why I think that you might have partially ended up here is because throughout your brief, you keep flaming about code generation. That's not your problem, you've not been with code generation, your problem is with class and creating it versus using pre existing. That seems to me the heart of what you would like changed about this destruction, am I right? Well, the, and I think that's actually what we did argue and I apologize if it did not come through as clearly as this. The district court didn't decide on that basis, certainly. The district, the newer court decide, wrote into the term. We're on appeal from the Massachusetts court, which relied on the district court. And you're talking now about figure seven and runtime. And that wasn't decided by the New York court on which the Massachusetts court relied, right? No, that was decided by the New York court. The new we argued in the New York case that the claim was not limited to use of a code generator to generate code for a class and during the process. Yes, but you didn't, the district court didn't decide on figure seven to analyze the figure seven point. I don't know if the district court wrote that into the opinion, the district court relied on figure one. To the district court in New York, regarding figure seven, creating an embodiment. I think we did, yes, you are. You think I'm pretty sure that we did. Yes. It's not in the record. You're right

. Did you join appendix? Excuse me? Is it in our joint appendix? No, well, the, the, what is in your, the appendix is the Markman order. So what is of record, and that's actually a very good point. What is of record in the Boston case, you're on, is the Markman order. So you have that text, the patent, of course. And you also have the declaration of data turns expert, Nourage Gupta, who says a paragraph 20 on page, I think it's 1075, that you could create a interface object from the preexisting class. He expressly references in that definition, in that declaration figure seven, and explains all that, right? Well, he, yes, I think that's true. In the case, does he, in the declaration expressly reference figure seven? I will look. So at paragraph 20, he is citing to the description of figure seven, starting at column six, to talk about where it is described that O object is a preexisting class from the beginning. So, I think that is what he says about the preexisting class, from which that it can be generated from. The, but he's got that weird testimony that you know doubt don't enjoy from the New York case where he, where someone asked him, were there any embodiments that didn't use code generation? He's like, nope, not that I see, not in this pattern. Well, what he, what he actually said was, as I'm sitting here today, I don't, I can't recall or I don't know what is in, I can't think of another one. Well, in there. That's not a big pattern. No, I know. How, how is it so clear to us that figure seven is predicated on a preexisting class rather than a generated class? Let me take you through it. So, please, the, I'm looking at column, the bottom column five through column six and, you know, the DLLs are generated. So, if you look at, and, and then the, the person in the middle of, well, I guess it's line 35 of column six, we see that, the person parentheses, the generated calm implementation class is invoked in step 62. That is, if you look at figure seven, you're on earth, that is preexisting at the time that the creation takes place. So, see, the problem is, and what I, what, what is the word, generated mean then to you? It could have been generated any time before, but at the time that, but what figure seven is showing is that that D person is, is constructed from O object, which is a class that exists in the runtime engine. If you look back at figure six and figure five, and what that does is don't forget the claim set. Figure five says generated DLLs, right? And one of the generated DLLs is the generated D person

. But the claim doesn't require that, you're wrong. I know, but you're trying to convince us that what's going on here in figure seven is a interesting new, separate, and distinct embodiment from what was disclosed in figure one about code generated. Rather than column five and six, really just being a further discussion of what's going on later in the claim about utilizing the runtime engine. Right. So, I'm trying to figure out in, and I wish I knew more about this field, about why there are strong signals here in this very hard to reach section of the path that convinces me that makes me feel comfortable in believing that yes, you are disclosing and you have contemplated a completely separate and distinct embodiment that is relying on pre existing classes. And it's not generating classes when I see the word generated here, here, here, and here. Okay. So, let me, there are two answers to that question. Answer number one is if you go through, excuse me, if you go through figure seven, you do not see anything here about code generation to generate a class during the process of creation, the moment of creation, you are not generating a class. It's as if the classes and objects have been analogized to cookie cutters and cookies. If I say create a cookie, that could be go to the machine shop, build a cookie cutter, each time you want to stamp out a new cookie, or it could be go to the kitchen junk drawer, get your pre existing cookie cutter out and stamp as many cookies as you like. That's actually what's happening in figure seven. You have the pre existing class, oh, oh, object, that is in the runtime engine that goes to the map at step 63 to get the attribute values and then imports that back to initialize the deep person interface object class. But there's a second answer. The second answer is an expert report I can read that says everything you just said to me. Well, we have paragraph 20 from Mr. Gupta's declaration, which is the only evidence in this case of record. And I think, and the second answer to the question I see that I'm running out of time is that the, it's not enough to say here's what it is for the specification to be read into the claim. The specification has to say this is what it is not. And micro strategy has not pointed to any such clear disclaimer of scope. And I'll leave you with your argument based on the spec

. I feel like you're running away from what I think are all your best arguments and I don't understand why don't we just answer judge 10 by saying figure seven as the spec says illustrates the sequence of actions that take place when a business object, quote, create an object. That's what I said. So why don't we just say to him figure seven expressly says it's all about creation the object which are identical words in the claim. You know what you know you're just. And that's your running. I'm sorry. I'm sorry. I'm sorry, Ron. I'm trying to answer his question, but that's how I started my argument, which was that's what figure seven shows and figure seven. But you can tell us that, but wouldn't it help you if you instead pointed at the spec, which says that's what figure seven shows. I did I read that actually your honor. I read exactly that sentence and I apologize if it's not more clear figure seven does show that figure seven shows and it's described as what happens during creation of the interface object. That is the sequence of events figure seven. So you even have to go further than that. Mr. Belt as you can see your time has expired. We'll give you your three months three minutes back and not thank the three months. I hope you'll certainly be here on. Mr. Castle. Thank you

. Good morning, there's your honors. Please the court. My name is Adam Kessel with me is Sivananda Reddy. I represent the Apple E micro strategy. I'm also authorized to speak on behalf of the other co-apply defendants aside from Lancet and Magic Software, who might understand. Is it appropriate for us to go chasing around into other joint appendices from other appeals? Yes. I'm still new to my job here, but this is a very weird domain that it's not in our joint appendix. Now we're being put on some kind of paper chase to go dig through other joint appendices. Or maybe even have to go through the district court's record to figure out what you're saying. So you're on a address the appendix issue first and I'd like to return to figure seven and then time permitting. I'd like to discuss what's the real point of this invention, but starting with the appendix question. The whole point of our stipulation in the district court was to save, re-creating, a duplicate record in the Boston court. The only evidence we put in was non-infringement evidence and we move for non-infringement under each of the different claims terms as they've been construed in New York. Data turn only stipulated on one and that's the one the judge went with. We didn't do a whole new claim construction process in Boston. But you also didn't move the admission into the record of all that evidence. So it's not part of your record in this case. So how can we choose an expert report filed in a different case that you never moved a simple your honor and light of this. We move into, can we move a grid, move into the record, all of this evidence? We're in a pilot court. We can't go outside of a record. Your record in this case doesn't include most of what you rely on in your brief

. How the heck could we possibly rely on that? So everything this court needs to affirm the Boston court's claim construction adopting the New York court's claim construction as a matter of public record. The provisional applications. We expert report filed in another case or a matter of public record and we're going to rely on them in this case to create extrinsic evidence that helps inform our claim construction. We can go right to the provisional. For the provisional. I understood your honor. The expert declaration we cited from the SAP appeal, which was in the appendix in the appeal argument that happened about a year ago, was explaining the intrinsic evidence. But we can go right to the intrinsic evidence, look right at the provisional, that that expert was opining on without the benefit of the expert testimony. That's what this court would prefer to do. It's all in there. We excited to what was in the public appendix in the SAP case to provide context for what the intrinsic record was. Frankly, your honor. I was unable to find any procedural authority on this somewhat unusual situation where the two appeals were not consolidated. They were fully briefed at the same time and then our appeal was stayed for about a year. I'd like to move on to the where we left off with figure seven. So figure seven is clearly not a separate embodiment of the invention. As your honor pointed out, all the discussion of figure seven, so that the starting point of figure seven are the generated DLLs, the generated interface objects, the generated classes. There's no suggesting in the specification that you've got to figure seven anyway, other than by generation. There's no suggestion in the record anywhere that generation means anything other than writing code. If you look at the pattern as a whole, figure one, figures five and six and seven are all connected. They're not different inventions or different embodiments

. They're all steps of the same process. You only get to figure seven. Figure seven doesn't show selecting an object model. It doesn't show getting the database schema. It doesn't show linking them together in a map. It doesn't show how that map gets to code. It just shows what happens at the end at the runtime, which is the final limitation of flame one and claim 10. Now, another critically important thing about figure seven is to claim requires creating an interface object, employing the map. Figure seven does not show employing the map to create an interface object. What about when it says set initial values to default from the attribute info in figure five and six, you can see that attribute info is a characteristic in the map. That's correct. Using the attribute info from the map. That's correct, Your Honor, and that would be argument. Well, not employing the map to create the object. That's correct, Your Honor, and that's the argument my brother raised in the reply brief. The reason that doesn't help them is the specification is clear that the creation being depicted in figure seven is step 61. You go from 61 to 62. That is when an object is instantiated from a class. That step does not employ a map. The object is instantiated by the end of step 61. There's nothing in the specification that suggests otherwise

. Once you have this object, an object is a data structure. It's essentially looking to be populated with data. At that point, what the specification teaches is the runtime engine uses the map to get data from the database and put it into the object that has already been created. There's nothing in the specification that suggests that the creation step goes all the way to the right side of the figure seven to include the data. Well, except it says in the description, O object is constructed when the constructor of the D person, the generated comment implementation class, is invoked in step 62. That's correct. So isn't O object the interface object? So invoked is different than created. I just want to make sure I understand the technology. Isn't O object the interface object? O object is the end of the process of creating an interface object. It's what's instantiated at the end of the district court's claim construction. Yes, it's the instantiated object. That's correct. Okay. So step 62 is the instantiated object. And so I don't understand the attributes is used expressly. I think I can help you. I don't understand. It's not part of the process. I think I can help you. This description of figure seven is fairly dense. First sentence says object is created in step 61. Meaning in step 62 we have the object. Then it says the object is constructed when the constructor of the D person, the generated implementation class is invoked in step 62. Invoking an object is not creating an object. And we know that because data turns stipulated to a construction of invoked, which means to call. This is at a 90 in our appendix. To call an object is different than to create an object. Calling is what you do once you have the object out there and you need to access the information in the object. So you need to make sure that the object is in the object. So you need to take it out. The last step of claim one also uses the word invoked. And that is the stipulated construction. It's not really at issue in this appeal, but it is utilizing a runtime engine which invokes that at least one interface object. So I guess that's what you mean by calling the interface object. That's what data turns means. That's how they stipulated in the Microsoft and SAP cases. They stipulated that invoked means call. And that's all consistent with all of the teachings of the intrinsic record. But I don't understand how that answers my question or clear things up for me because even if I extract the word invoked, stick the word call in there, it still says, oh, object is constructed. The normal definition of constructed is created, right? You can't construct something that has already been created. Correct. I mean, is there some other definition of the word constructed that you're familiar with? There is

. Meaning in step 62 we have the object. Then it says the object is constructed when the constructor of the D person, the generated implementation class is invoked in step 62. Invoking an object is not creating an object. And we know that because data turns stipulated to a construction of invoked, which means to call. This is at a 90 in our appendix. To call an object is different than to create an object. Calling is what you do once you have the object out there and you need to access the information in the object. So you need to make sure that the object is in the object. So you need to take it out. The last step of claim one also uses the word invoked. And that is the stipulated construction. It's not really at issue in this appeal, but it is utilizing a runtime engine which invokes that at least one interface object. So I guess that's what you mean by calling the interface object. That's what data turns means. That's how they stipulated in the Microsoft and SAP cases. They stipulated that invoked means call. And that's all consistent with all of the teachings of the intrinsic record. But I don't understand how that answers my question or clear things up for me because even if I extract the word invoked, stick the word call in there, it still says, oh, object is constructed. The normal definition of constructed is created, right? You can't construct something that has already been created. Correct. I mean, is there some other definition of the word constructed that you're familiar with? There is. I don't know that there's record support for it other than looking at how this oh object is used throughout the specification, throughout the two provisional. How do you instantiate an object without having a class? D person is the only class referred to in figure seven. There's no other class referred to. You can't instantiate an object, right? Until you have the class. Correct? That's precisely our point. Technically. So how can the object be created prior to use of D person, which is articulated in that second sentence? Oh object is constructed when the constructor of the D person is invoked in step 62. How can I be read any other way other than the object is created when you use the class that is D person and instantiate the object? So there's a. One point I think you're on a made for me, which is how do you get an object without a class you can't. So you can't create an object without having a class and there's no teaching in this pattern of coming up with a class other than by generating a code for that class. There's no way to do it. Another nuance that I think I really need to clear up here is the pattern makes clear that oh object is a call it a generic implementation. It doesn't do anything that needs the custom interface object that was created based on the mapping of the relational database to the object oriented program to actually be functional. That's right there. Who for every object, right? You're not describing something unique about oh object that is set apart from every other embodied. I am your honor. The description of all objects in the specification said that it is generic. I have this location here somewhere. Big column six line 34 talks about constructing or objects. That's right. And then if you jump up one paragraph column six line eight, it describes what oh obeys an oh object are

. I don't know that there's record support for it other than looking at how this oh object is used throughout the specification, throughout the two provisional. How do you instantiate an object without having a class? D person is the only class referred to in figure seven. There's no other class referred to. You can't instantiate an object, right? Until you have the class. Correct? That's precisely our point. Technically. So how can the object be created prior to use of D person, which is articulated in that second sentence? Oh object is constructed when the constructor of the D person is invoked in step 62. How can I be read any other way other than the object is created when you use the class that is D person and instantiate the object? So there's a. One point I think you're on a made for me, which is how do you get an object without a class you can't. So you can't create an object without having a class and there's no teaching in this pattern of coming up with a class other than by generating a code for that class. There's no way to do it. Another nuance that I think I really need to clear up here is the pattern makes clear that oh object is a call it a generic implementation. It doesn't do anything that needs the custom interface object that was created based on the mapping of the relational database to the object oriented program to actually be functional. That's right there. Who for every object, right? You're not describing something unique about oh object that is set apart from every other embodied. I am your honor. The description of all objects in the specification said that it is generic. I have this location here somewhere. Big column six line 34 talks about constructing or objects. That's right. And then if you jump up one paragraph column six line eight, it describes what oh obeys an oh object are. This is starting on line nine, oh base is a base abstract class, which is used as a base for all the generated implementation classes. This is kind of the the empty shell with the the oh obeys isn't what we're talking about. We're talking about a logic. Well, and then that paragraph goes to describe that oh obeys contains a pointer to the oh object. These are the more detailed description of oh object starts at line 24 of column six where describes what's in oh object. These are generic attribute flags. These are not the results of the mapping. This isn't the thing that connects the database and the object oriented program that previously had this object relational mismatch. This is a generic class. It says for abstracting the runtime functionality for a generic object column six line 20. What about the fact that claim 10 expressly recite code generator while claim one the method claim does not. I have two two responses first. I think that helps us because it gives some color to what an interface object is. It's the sort of thing that a code generator creates. Otherwise, this is a this is a coin term. There's no evidence that everybody knows what an interface object is. It's used a little unusually here because there are many uses in the specification of an object to mean a class in the figures and in the specification. So claim 10 gives some clarity to what sort of thing an interface object is. It's what gets bit out of the code generator. What concerns me, you know, let's just assume for the moment that data turns alternative reading of figure one we disagree with. Let's also assume for the moment that figure seven is just a wash

. This is starting on line nine, oh base is a base abstract class, which is used as a base for all the generated implementation classes. This is kind of the the empty shell with the the oh obeys isn't what we're talking about. We're talking about a logic. Well, and then that paragraph goes to describe that oh obeys contains a pointer to the oh object. These are the more detailed description of oh object starts at line 24 of column six where describes what's in oh object. These are generic attribute flags. These are not the results of the mapping. This isn't the thing that connects the database and the object oriented program that previously had this object relational mismatch. This is a generic class. It says for abstracting the runtime functionality for a generic object column six line 20. What about the fact that claim 10 expressly recite code generator while claim one the method claim does not. I have two two responses first. I think that helps us because it gives some color to what an interface object is. It's the sort of thing that a code generator creates. Otherwise, this is a this is a coin term. There's no evidence that everybody knows what an interface object is. It's used a little unusually here because there are many uses in the specification of an object to mean a class in the figures and in the specification. So claim 10 gives some clarity to what sort of thing an interface object is. It's what gets bit out of the code generator. What concerns me, you know, let's just assume for the moment that data turns alternative reading of figure one we disagree with. Let's also assume for the moment that figure seven is just a wash. Like all the court has is two teams of lawyers talking at it without any sufficient expert support. Okay. So now we're left with a situation where the claim on its own terms is pretty broad. It doesn't explain how the object is being created other than the fact that it's employing a map. It doesn't talk about using a code generator, even though the disclosed embodiment references a code generator. There's a lot of times where disclosed embodiment will itemize a series of elements, but then the claim only recites some but not all of those elements. And there's nothing inherently wrong with that that, you know, when we have a claim like that, we don't start shoveling in every single element that's disclosed in the embodiment that isn't actually recited in the claim. We know that the patent owner knows how to recite code generator into a claim. It did it in claim 10 and it did not do it in claim 1. Well, you're on our submit there. We have an apparatus claim and a method claim. They seem to be reading on the same embodiment, but let me get to the heart of your question. What do we do in this situation? Sure. With that one, the method claim, the method claim does talk about employing a map. So that part from figure one has been brought into point one, but the code generator is not been brought into claim one. We're dealing with an abstraction here employing a map to create an interface object aside from this debate, which we've been having for most of my time on what what what the embodiment are. We also look at what the patent says about what is the problem that solved how does it solve it? What are the benefits of the invention? This is very similar to the retractable technology case to the Microsoft, the multi tech case several years back. And we look at the statement in the patent about what the benefits are at column one line 66. It's precise. A benefit of the invention is neither programmers nor software applications need have knowledge of the database structure to obtain access to the relational database that can only be done by writing code. Well, it can only be done according to the patent by having something called an interface object that bridges the gap between the database and the software

. Like all the court has is two teams of lawyers talking at it without any sufficient expert support. Okay. So now we're left with a situation where the claim on its own terms is pretty broad. It doesn't explain how the object is being created other than the fact that it's employing a map. It doesn't talk about using a code generator, even though the disclosed embodiment references a code generator. There's a lot of times where disclosed embodiment will itemize a series of elements, but then the claim only recites some but not all of those elements. And there's nothing inherently wrong with that that, you know, when we have a claim like that, we don't start shoveling in every single element that's disclosed in the embodiment that isn't actually recited in the claim. We know that the patent owner knows how to recite code generator into a claim. It did it in claim 10 and it did not do it in claim 1. Well, you're on our submit there. We have an apparatus claim and a method claim. They seem to be reading on the same embodiment, but let me get to the heart of your question. What do we do in this situation? Sure. With that one, the method claim, the method claim does talk about employing a map. So that part from figure one has been brought into point one, but the code generator is not been brought into claim one. We're dealing with an abstraction here employing a map to create an interface object aside from this debate, which we've been having for most of my time on what what what the embodiment are. We also look at what the patent says about what is the problem that solved how does it solve it? What are the benefits of the invention? This is very similar to the retractable technology case to the Microsoft, the multi tech case several years back. And we look at the statement in the patent about what the benefits are at column one line 66. It's precise. A benefit of the invention is neither programmers nor software applications need have knowledge of the database structure to obtain access to the relational database that can only be done by writing code. Well, it can only be done according to the patent by having something called an interface object that bridges the gap between the database and the software. It doesn't say right there. Thanks to our handy code generator that we've invented. Well, let me let me get to the extensive evidence on it. Much of it is in the provisional. Now the first provisional is about 90 pages mentions code generation 60 times any page that doesn't mention code generation is talking about a completely different aspect. The provisional says the value proposition for this OI three, which is the embodiment in the provisional includes push button code generation. And the provisional goes on. It compares the new product to what they were calling the predecessor product. This is the September 26, 1997 provisional at 52. It distinguishes the predecessor product, which implemented map mapping at runtime. It says, OI three avoid generic instrumentation. The generic mappings will be C++ code and then it lets all these negative features of doing it the old way of doing it with doing it all at runtime execution time complexity maintenance issues start up overhead. And then it says in the provisional code generation addresses all the negative features listed above this is a clear statement of what's being invented what the benefit is. And it's throughout both of the provisional which are there in the specification they're incorporated by reference they keep referring to the code generation button the benefits of code generation how it saves the programmer time how it can accommodate changes in the database structure. Without the programmer having to do the laborious work that was in the prior art the object relational mismatch required the programmer to handwrite this code. And that's there right in the specification we don't need to go to Dr. Hoskins declaration we can see it in the specification that they had a predecessor product that didn't do code generation the original filing the second filing the third filing every reference to an interface object is the first one. So if they generate an interface object there's some different terminology in the provisional and we point to the so if the claim is read is plainly and broadly as data term would happen then would you have a validity ground. Absolutely absolutely we would but we submit that because the provisional talks about the prior art is not doing code generation and then talks about the benefits of code generation and it matches every embodiment matches figures one five six seven every reference to these things every reference to these interface objects is something that started with code generation so. The question is given you next for time do you have a final summary sentence just your honor that this invention was all about code generation and that's what the intrinsic record shows thank you. Thank you

. It doesn't say right there. Thanks to our handy code generator that we've invented. Well, let me let me get to the extensive evidence on it. Much of it is in the provisional. Now the first provisional is about 90 pages mentions code generation 60 times any page that doesn't mention code generation is talking about a completely different aspect. The provisional says the value proposition for this OI three, which is the embodiment in the provisional includes push button code generation. And the provisional goes on. It compares the new product to what they were calling the predecessor product. This is the September 26, 1997 provisional at 52. It distinguishes the predecessor product, which implemented map mapping at runtime. It says, OI three avoid generic instrumentation. The generic mappings will be C++ code and then it lets all these negative features of doing it the old way of doing it with doing it all at runtime execution time complexity maintenance issues start up overhead. And then it says in the provisional code generation addresses all the negative features listed above this is a clear statement of what's being invented what the benefit is. And it's throughout both of the provisional which are there in the specification they're incorporated by reference they keep referring to the code generation button the benefits of code generation how it saves the programmer time how it can accommodate changes in the database structure. Without the programmer having to do the laborious work that was in the prior art the object relational mismatch required the programmer to handwrite this code. And that's there right in the specification we don't need to go to Dr. Hoskins declaration we can see it in the specification that they had a predecessor product that didn't do code generation the original filing the second filing the third filing every reference to an interface object is the first one. So if they generate an interface object there's some different terminology in the provisional and we point to the so if the claim is read is plainly and broadly as data term would happen then would you have a validity ground. Absolutely absolutely we would but we submit that because the provisional talks about the prior art is not doing code generation and then talks about the benefits of code generation and it matches every embodiment matches figures one five six seven every reference to these things every reference to these interface objects is something that started with code generation so. The question is given you next for time do you have a final summary sentence just your honor that this invention was all about code generation and that's what the intrinsic record shows thank you. Thank you. This is available to you. Thank you. What about all these references and the provisional about the howding the need for code generation right well two things to say about that your honor first of all that is not in this record and as I think it may have been judge more maybe it was you I don't recall under 28 roll 28 I Michael strategy and the defendants cannot bring into this record of the pleadings and the Okay we got that argument but on the merit and on the merits that was not the basis the by the time that you get to the full utility application and the patent that was not the basis for distinguishing the prior art and In fact, I can tell you that in the New York case, we did not rely on the September Provisional. We relied on the December Provisional for Priority. And the patent says, at the pre-summary of the invention, the mapping, this is the front page of your patent, refers to both provisions. It does, but I'm telling you there was a late US application data. I can tell you that there was testimony by the inventor, one of the inventors that there were further developments since between September and December for the December Provisional. The... Well, let me go to the merits, though, of this issue, technical standpoint. Doesn't code have to be generated to instantiate an object. Yes. Everybody agrees, they're fighting over where the code has to be generated to create a class. You're saying, that's not part of the claims, they're saying it is, but doesn't code still have to be generated to instantiate an object. No, you're on it. You can instantiate an object from a pre-existing class. No, no, no. You have to use code to do it. This is a software patent for God'sakes. I mean, how are you instantiate an object? You're bringing it up all a clay and molding it? No, you've got to use code, right? In the

. This is available to you. Thank you. What about all these references and the provisional about the howding the need for code generation right well two things to say about that your honor first of all that is not in this record and as I think it may have been judge more maybe it was you I don't recall under 28 roll 28 I Michael strategy and the defendants cannot bring into this record of the pleadings and the Okay we got that argument but on the merit and on the merits that was not the basis the by the time that you get to the full utility application and the patent that was not the basis for distinguishing the prior art and In fact, I can tell you that in the New York case, we did not rely on the September Provisional. We relied on the December Provisional for Priority. And the patent says, at the pre-summary of the invention, the mapping, this is the front page of your patent, refers to both provisions. It does, but I'm telling you there was a late US application data. I can tell you that there was testimony by the inventor, one of the inventors that there were further developments since between September and December for the December Provisional. The... Well, let me go to the merits, though, of this issue, technical standpoint. Doesn't code have to be generated to instantiate an object. Yes. Everybody agrees, they're fighting over where the code has to be generated to create a class. You're saying, that's not part of the claims, they're saying it is, but doesn't code still have to be generated to instantiate an object. No, you're on it. You can instantiate an object from a pre-existing class. No, no, no. You have to use code to do it. This is a software patent for God'sakes. I mean, how are you instantiate an object? You're bringing it up all a clay and molding it? No, you've got to use code, right? In the... Oh, yeah. Let me put it this way, Your Honor. The patent is not specific to any one kind of object-oriented software programming language. Yes, but in all the point code, in the patent, which is referring to a glyphs C++, that is a way to do it. It's not the only way to do it. And the patent, the claim is silent as to how it gets on that. Not every way to do it, employ code. Forget about whether code is created. Oh, yes, the base. Create a class is in code a necessary component of instantiating an object. The creation of code to instantiate the object. I think we're talking about software coding in general. So the lot of things that you're right, there are a lot of things that are depending on that. The claim does not require that. And the claim does not say when that class comes into existence. What if the claim didn't say employing a map? What if it just said creating an interface object? Then it would be even broader. Right. And then would you say, oh, the claim doesn't require a map either. Yes, that claim does not require a map

... Oh, yeah. Let me put it this way, Your Honor. The patent is not specific to any one kind of object-oriented software programming language. Yes, but in all the point code, in the patent, which is referring to a glyphs C++, that is a way to do it. It's not the only way to do it. And the patent, the claim is silent as to how it gets on that. Not every way to do it, employ code. Forget about whether code is created. Oh, yes, the base. Create a class is in code a necessary component of instantiating an object. The creation of code to instantiate the object. I think we're talking about software coding in general. So the lot of things that you're right, there are a lot of things that are depending on that. The claim does not require that. And the claim does not say when that class comes into existence. What if the claim didn't say employing a map? What if it just said creating an interface object? Then it would be even broader. Right. And then would you say, oh, the claim doesn't require a map either. Yes, that claim does not require a map. If it does not recite it, it is not in the claim. And last, the mapping feature of this invention seems to be awfully critical. That's what it was going to come to when it seems to be like the heavy spotlight is on the map. And that's what I wanted to create. That's what I wanted to get to when I was answering your first question. The patent says in the brief summary of the invention at column one line 58 there about 59, the database schema, object model, and mapping are employed to provide interface objects that are utilized by an object oriented software application to access the relational database. Now the fact that the mapping is an important part of this is the claim title of the invention. And that's why it's in the claim, you're on it. Because that was part of that. And I think the runtime engine and the interface objects are all working hand in glove together to provide the interface between the object oriented application and the relational data. Likewise, if we were looking to use the specification to help us to find the invention as recent cases, which we have just issued, talk about language like present invention would be important. And at column one line 53, this says in accordance with the present invention, a mapping is employed. So you'd have a hard time running away from the map being a critical part of this invention which would need to be something that would be employed. But there is no similar language anywhere in this spec about the present invention in terms of co-generation of a class. That is correct, Your Honor. And that's why the mapping is recited in the claim and it's shown in figure 7, the attribute, I think it's step 63, is getting the attribute, which if you look at figure 6, shows that that step is part of the map. Now maybe I could leave you with this, Your Honor. One of the cases that I'm sorry. It's certainly going to leave us misspelled. But if you leave us with one further thought, that will be fine. Yeah, that's what that's where I was going

. If it does not recite it, it is not in the claim. And last, the mapping feature of this invention seems to be awfully critical. That's what it was going to come to when it seems to be like the heavy spotlight is on the map. And that's what I wanted to create. That's what I wanted to get to when I was answering your first question. The patent says in the brief summary of the invention at column one line 58 there about 59, the database schema, object model, and mapping are employed to provide interface objects that are utilized by an object oriented software application to access the relational database. Now the fact that the mapping is an important part of this is the claim title of the invention. And that's why it's in the claim, you're on it. Because that was part of that. And I think the runtime engine and the interface objects are all working hand in glove together to provide the interface between the object oriented application and the relational data. Likewise, if we were looking to use the specification to help us to find the invention as recent cases, which we have just issued, talk about language like present invention would be important. And at column one line 53, this says in accordance with the present invention, a mapping is employed. So you'd have a hard time running away from the map being a critical part of this invention which would need to be something that would be employed. But there is no similar language anywhere in this spec about the present invention in terms of co-generation of a class. That is correct, Your Honor. And that's why the mapping is recited in the claim and it's shown in figure 7, the attribute, I think it's step 63, is getting the attribute, which if you look at figure 6, shows that that step is part of the map. Now maybe I could leave you with this, Your Honor. One of the cases that I'm sorry. It's certainly going to leave us misspelled. But if you leave us with one further thought, that will be fine. Yeah, that's what that's where I was going. The resonate case that we cite in our reply brief, 338 F1360 at page 1365 says, the district court's level of detail analysis does not withstand close scrutiny. The patent needs apparent choice, not to specify a transmission path from the server to the client, and led the district court to add a limitation that the requested resource be transmitted directly to the client. But patent fees are not required to claim each part of an invention with the same amount of detail. Indeed, such a role likely would prove unworkable. Court may not rewrite. Thank you, Mr. Bell. We thank you all. And that's our, that's the basis of our own. Thank you. Thank you.

We have four cases on the calendar this morning. I can case from a district court, a patent case from the PTO, a trade case from the Court of International Trade and the government, government employee case, so we submit it on the brief and therefore not the argue. The first case is from the district court, data pern versus blazing at out. 2013, 12, 51 and 52. This is the bell. Good morning, Your Honors. I'm Eric Belt of MacArthur in English, a representative turn, and thank you for hearing us today. There's a single issue in this case Your Honor. It is the claim construction of the term from claim one of the 502 patent employing the map to create at least one interface object. Now, let me just tell you briefly how we got to this point so that you can better understand the background. As Judge Moore may recall, there were two cases, two sets of cases, one pending in the Southern District of New York, one pending in Boston, the New York Court reached claim construction first. At that point, in the Boston case, the parties disputed whether the New York Court's claim construction would control until this court had a chance to rule on the terms. And the end result of that dispute was that data turn conceded non-infringement of one term. If that term employing the map to create at least one interface object were held by this court to have been construed correctly by the New York Court, then we conceded infringement. And that's why we're here on appeal today. So when I refer to the district court, I am referring to the New York Court's claim construction in the Mark Minoritor, which is part of the record of this case. To set the stage for what the court did here, it may help to have also a very brief explanation of the technology. In the Mark Minoritor, the... Why don't you focus on what the patent says? Okay, thank you. It's this. A lot in there that's what you're really dealing with. All right. So that's what I was getting to next, Your Honor, and really it's what the patent says, of course, that control. And we're going to start with the claims. The claim says employing the map to create at least one interface object. The district court wrote into that phrase that the term create means to generate code for at least one class and instantiate an object from that class. It's not in the claim. There's nothing in the specification that requires that phrase to be written to the client. The specifications say a code generator is employed to examine the relationships fine in the map well, et cetera. It doesn't... It doesn't discuss the case. It says you're with the claim means. The specification tells you a preferred embodiment of the claim one embodiment. Is there another one? Yes, there is, Your Honor. So I'll take you through two figures. In one figure, figure one, Your Honor, in figure one, you have one way to generate an interface object through a code generator. Now that's claim 10. Claim 10 specifically calls out the use of the code generator. Claim one does not. In figure one, there's a second root. And the district court recognized that. I believe it's on page A118 of the record. It means the double arrows. The arrows between from the map to the runtime engine to the interface object. And the runtime engine that's talking to the map and creating the interface object. And we know that because when you go now to figure seven, Your Honor. Figure seven shows, first of all, is described in the text of the specification starting at column six around line 31. Figure seven illustrates, I'm quoting, figure seven illustrates the sequence of actions that take place when a business object creates, there's that word, creates a DSL object in step 61. DSL object, I think both parties agree is the interface object. And so figure seven is talking about the dynamic process of creation. And that if you look at the claim wording. But isn't that utilizing a runtime engine? Figure seven is a diagram that illustrates operation of the runtime engine. Isn't that after the operation of a code generator? It could be your honor, but the claim one doesn't specify when or if a what happens with the class from which a interface object is instantiated. That claim one simply requires instantiating an object. And that can be done by the runtime engine itself, that it doesn't have to be done separately, that the runtime engine could actually cause that to occur. That's what I believe figure seven is showing the runner with the caveat that. And so your figure your claim one, the third element says utilizing a runtime engine, which invokes at least one interface object, you would say, OK, there, the runtime engine has to do it. But the employing the map to create at least one interface object can be done by a code generator, which creates a class and then instantiate an object or, and that would fall within this claim or alternatively. It could be done by the runtime engine pursuant to figure seven, which instantiate the claim that that that that entisities an object that claim one doesn't expressly claim creating the class by code generation. That's the next of our argument, your honor, which is claim one that step employing the map to create at least one interface object is silence as to the method of creation creation in that sense. The kind of problem though, just so you know, which probably causes us and possibly even district courts to get off track from the technology is that throughout your brief, you keep objecting to code generation. But that's not your actual objection, your objection is class creation, your objection is we can use a pre existing class and then use the runtime engine, which by the way generates codes to instantiate the object. So if your argument isn't that code generation can't be or is never employed or doesn't need to be employed, it seems to me that your argument is that this all is about the fact that the claim doesn't require or limit us to creating a class through the code generator, but rather allows for use of a pre existing class. But that isn't the way you argue it. And that's why I think that you might have partially ended up here is because throughout your brief, you keep flaming about code generation. That's not your problem, you've not been with code generation, your problem is with class and creating it versus using pre existing. That seems to me the heart of what you would like changed about this destruction, am I right? Well, the, and I think that's actually what we did argue and I apologize if it did not come through as clearly as this. The district court didn't decide on that basis, certainly. The district, the newer court decide, wrote into the term. We're on appeal from the Massachusetts court, which relied on the district court. And you're talking now about figure seven and runtime. And that wasn't decided by the New York court on which the Massachusetts court relied, right? No, that was decided by the New York court. The new we argued in the New York case that the claim was not limited to use of a code generator to generate code for a class and during the process. Yes, but you didn't, the district court didn't decide on figure seven to analyze the figure seven point. I don't know if the district court wrote that into the opinion, the district court relied on figure one. To the district court in New York, regarding figure seven, creating an embodiment. I think we did, yes, you are. You think I'm pretty sure that we did. Yes. It's not in the record. You're right. Did you join appendix? Excuse me? Is it in our joint appendix? No, well, the, the, what is in your, the appendix is the Markman order. So what is of record, and that's actually a very good point. What is of record in the Boston case, you're on, is the Markman order. So you have that text, the patent, of course. And you also have the declaration of data turns expert, Nourage Gupta, who says a paragraph 20 on page, I think it's 1075, that you could create a interface object from the preexisting class. He expressly references in that definition, in that declaration figure seven, and explains all that, right? Well, he, yes, I think that's true. In the case, does he, in the declaration expressly reference figure seven? I will look. So at paragraph 20, he is citing to the description of figure seven, starting at column six, to talk about where it is described that O object is a preexisting class from the beginning. So, I think that is what he says about the preexisting class, from which that it can be generated from. The, but he's got that weird testimony that you know doubt don't enjoy from the New York case where he, where someone asked him, were there any embodiments that didn't use code generation? He's like, nope, not that I see, not in this pattern. Well, what he, what he actually said was, as I'm sitting here today, I don't, I can't recall or I don't know what is in, I can't think of another one. Well, in there. That's not a big pattern. No, I know. How, how is it so clear to us that figure seven is predicated on a preexisting class rather than a generated class? Let me take you through it. So, please, the, I'm looking at column, the bottom column five through column six and, you know, the DLLs are generated. So, if you look at, and, and then the, the person in the middle of, well, I guess it's line 35 of column six, we see that, the person parentheses, the generated calm implementation class is invoked in step 62. That is, if you look at figure seven, you're on earth, that is preexisting at the time that the creation takes place. So, see, the problem is, and what I, what, what is the word, generated mean then to you? It could have been generated any time before, but at the time that, but what figure seven is showing is that that D person is, is constructed from O object, which is a class that exists in the runtime engine. If you look back at figure six and figure five, and what that does is don't forget the claim set. Figure five says generated DLLs, right? And one of the generated DLLs is the generated D person. But the claim doesn't require that, you're wrong. I know, but you're trying to convince us that what's going on here in figure seven is a interesting new, separate, and distinct embodiment from what was disclosed in figure one about code generated. Rather than column five and six, really just being a further discussion of what's going on later in the claim about utilizing the runtime engine. Right. So, I'm trying to figure out in, and I wish I knew more about this field, about why there are strong signals here in this very hard to reach section of the path that convinces me that makes me feel comfortable in believing that yes, you are disclosing and you have contemplated a completely separate and distinct embodiment that is relying on pre existing classes. And it's not generating classes when I see the word generated here, here, here, and here. Okay. So, let me, there are two answers to that question. Answer number one is if you go through, excuse me, if you go through figure seven, you do not see anything here about code generation to generate a class during the process of creation, the moment of creation, you are not generating a class. It's as if the classes and objects have been analogized to cookie cutters and cookies. If I say create a cookie, that could be go to the machine shop, build a cookie cutter, each time you want to stamp out a new cookie, or it could be go to the kitchen junk drawer, get your pre existing cookie cutter out and stamp as many cookies as you like. That's actually what's happening in figure seven. You have the pre existing class, oh, oh, object, that is in the runtime engine that goes to the map at step 63 to get the attribute values and then imports that back to initialize the deep person interface object class. But there's a second answer. The second answer is an expert report I can read that says everything you just said to me. Well, we have paragraph 20 from Mr. Gupta's declaration, which is the only evidence in this case of record. And I think, and the second answer to the question I see that I'm running out of time is that the, it's not enough to say here's what it is for the specification to be read into the claim. The specification has to say this is what it is not. And micro strategy has not pointed to any such clear disclaimer of scope. And I'll leave you with your argument based on the spec. I feel like you're running away from what I think are all your best arguments and I don't understand why don't we just answer judge 10 by saying figure seven as the spec says illustrates the sequence of actions that take place when a business object, quote, create an object. That's what I said. So why don't we just say to him figure seven expressly says it's all about creation the object which are identical words in the claim. You know what you know you're just. And that's your running. I'm sorry. I'm sorry. I'm sorry, Ron. I'm trying to answer his question, but that's how I started my argument, which was that's what figure seven shows and figure seven. But you can tell us that, but wouldn't it help you if you instead pointed at the spec, which says that's what figure seven shows. I did I read that actually your honor. I read exactly that sentence and I apologize if it's not more clear figure seven does show that figure seven shows and it's described as what happens during creation of the interface object. That is the sequence of events figure seven. So you even have to go further than that. Mr. Belt as you can see your time has expired. We'll give you your three months three minutes back and not thank the three months. I hope you'll certainly be here on. Mr. Castle. Thank you. Good morning, there's your honors. Please the court. My name is Adam Kessel with me is Sivananda Reddy. I represent the Apple E micro strategy. I'm also authorized to speak on behalf of the other co-apply defendants aside from Lancet and Magic Software, who might understand. Is it appropriate for us to go chasing around into other joint appendices from other appeals? Yes. I'm still new to my job here, but this is a very weird domain that it's not in our joint appendix. Now we're being put on some kind of paper chase to go dig through other joint appendices. Or maybe even have to go through the district court's record to figure out what you're saying. So you're on a address the appendix issue first and I'd like to return to figure seven and then time permitting. I'd like to discuss what's the real point of this invention, but starting with the appendix question. The whole point of our stipulation in the district court was to save, re-creating, a duplicate record in the Boston court. The only evidence we put in was non-infringement evidence and we move for non-infringement under each of the different claims terms as they've been construed in New York. Data turn only stipulated on one and that's the one the judge went with. We didn't do a whole new claim construction process in Boston. But you also didn't move the admission into the record of all that evidence. So it's not part of your record in this case. So how can we choose an expert report filed in a different case that you never moved a simple your honor and light of this. We move into, can we move a grid, move into the record, all of this evidence? We're in a pilot court. We can't go outside of a record. Your record in this case doesn't include most of what you rely on in your brief. How the heck could we possibly rely on that? So everything this court needs to affirm the Boston court's claim construction adopting the New York court's claim construction as a matter of public record. The provisional applications. We expert report filed in another case or a matter of public record and we're going to rely on them in this case to create extrinsic evidence that helps inform our claim construction. We can go right to the provisional. For the provisional. I understood your honor. The expert declaration we cited from the SAP appeal, which was in the appendix in the appeal argument that happened about a year ago, was explaining the intrinsic evidence. But we can go right to the intrinsic evidence, look right at the provisional, that that expert was opining on without the benefit of the expert testimony. That's what this court would prefer to do. It's all in there. We excited to what was in the public appendix in the SAP case to provide context for what the intrinsic record was. Frankly, your honor. I was unable to find any procedural authority on this somewhat unusual situation where the two appeals were not consolidated. They were fully briefed at the same time and then our appeal was stayed for about a year. I'd like to move on to the where we left off with figure seven. So figure seven is clearly not a separate embodiment of the invention. As your honor pointed out, all the discussion of figure seven, so that the starting point of figure seven are the generated DLLs, the generated interface objects, the generated classes. There's no suggesting in the specification that you've got to figure seven anyway, other than by generation. There's no suggestion in the record anywhere that generation means anything other than writing code. If you look at the pattern as a whole, figure one, figures five and six and seven are all connected. They're not different inventions or different embodiments. They're all steps of the same process. You only get to figure seven. Figure seven doesn't show selecting an object model. It doesn't show getting the database schema. It doesn't show linking them together in a map. It doesn't show how that map gets to code. It just shows what happens at the end at the runtime, which is the final limitation of flame one and claim 10. Now, another critically important thing about figure seven is to claim requires creating an interface object, employing the map. Figure seven does not show employing the map to create an interface object. What about when it says set initial values to default from the attribute info in figure five and six, you can see that attribute info is a characteristic in the map. That's correct. Using the attribute info from the map. That's correct, Your Honor, and that would be argument. Well, not employing the map to create the object. That's correct, Your Honor, and that's the argument my brother raised in the reply brief. The reason that doesn't help them is the specification is clear that the creation being depicted in figure seven is step 61. You go from 61 to 62. That is when an object is instantiated from a class. That step does not employ a map. The object is instantiated by the end of step 61. There's nothing in the specification that suggests otherwise. Once you have this object, an object is a data structure. It's essentially looking to be populated with data. At that point, what the specification teaches is the runtime engine uses the map to get data from the database and put it into the object that has already been created. There's nothing in the specification that suggests that the creation step goes all the way to the right side of the figure seven to include the data. Well, except it says in the description, O object is constructed when the constructor of the D person, the generated comment implementation class, is invoked in step 62. That's correct. So isn't O object the interface object? So invoked is different than created. I just want to make sure I understand the technology. Isn't O object the interface object? O object is the end of the process of creating an interface object. It's what's instantiated at the end of the district court's claim construction. Yes, it's the instantiated object. That's correct. Okay. So step 62 is the instantiated object. And so I don't understand the attributes is used expressly. I think I can help you. I don't understand. It's not part of the process. I think I can help you. This description of figure seven is fairly dense. First sentence says object is created in step 61. Meaning in step 62 we have the object. Then it says the object is constructed when the constructor of the D person, the generated implementation class is invoked in step 62. Invoking an object is not creating an object. And we know that because data turns stipulated to a construction of invoked, which means to call. This is at a 90 in our appendix. To call an object is different than to create an object. Calling is what you do once you have the object out there and you need to access the information in the object. So you need to make sure that the object is in the object. So you need to take it out. The last step of claim one also uses the word invoked. And that is the stipulated construction. It's not really at issue in this appeal, but it is utilizing a runtime engine which invokes that at least one interface object. So I guess that's what you mean by calling the interface object. That's what data turns means. That's how they stipulated in the Microsoft and SAP cases. They stipulated that invoked means call. And that's all consistent with all of the teachings of the intrinsic record. But I don't understand how that answers my question or clear things up for me because even if I extract the word invoked, stick the word call in there, it still says, oh, object is constructed. The normal definition of constructed is created, right? You can't construct something that has already been created. Correct. I mean, is there some other definition of the word constructed that you're familiar with? There is. I don't know that there's record support for it other than looking at how this oh object is used throughout the specification, throughout the two provisional. How do you instantiate an object without having a class? D person is the only class referred to in figure seven. There's no other class referred to. You can't instantiate an object, right? Until you have the class. Correct? That's precisely our point. Technically. So how can the object be created prior to use of D person, which is articulated in that second sentence? Oh object is constructed when the constructor of the D person is invoked in step 62. How can I be read any other way other than the object is created when you use the class that is D person and instantiate the object? So there's a. One point I think you're on a made for me, which is how do you get an object without a class you can't. So you can't create an object without having a class and there's no teaching in this pattern of coming up with a class other than by generating a code for that class. There's no way to do it. Another nuance that I think I really need to clear up here is the pattern makes clear that oh object is a call it a generic implementation. It doesn't do anything that needs the custom interface object that was created based on the mapping of the relational database to the object oriented program to actually be functional. That's right there. Who for every object, right? You're not describing something unique about oh object that is set apart from every other embodied. I am your honor. The description of all objects in the specification said that it is generic. I have this location here somewhere. Big column six line 34 talks about constructing or objects. That's right. And then if you jump up one paragraph column six line eight, it describes what oh obeys an oh object are. This is starting on line nine, oh base is a base abstract class, which is used as a base for all the generated implementation classes. This is kind of the the empty shell with the the oh obeys isn't what we're talking about. We're talking about a logic. Well, and then that paragraph goes to describe that oh obeys contains a pointer to the oh object. These are the more detailed description of oh object starts at line 24 of column six where describes what's in oh object. These are generic attribute flags. These are not the results of the mapping. This isn't the thing that connects the database and the object oriented program that previously had this object relational mismatch. This is a generic class. It says for abstracting the runtime functionality for a generic object column six line 20. What about the fact that claim 10 expressly recite code generator while claim one the method claim does not. I have two two responses first. I think that helps us because it gives some color to what an interface object is. It's the sort of thing that a code generator creates. Otherwise, this is a this is a coin term. There's no evidence that everybody knows what an interface object is. It's used a little unusually here because there are many uses in the specification of an object to mean a class in the figures and in the specification. So claim 10 gives some clarity to what sort of thing an interface object is. It's what gets bit out of the code generator. What concerns me, you know, let's just assume for the moment that data turns alternative reading of figure one we disagree with. Let's also assume for the moment that figure seven is just a wash. Like all the court has is two teams of lawyers talking at it without any sufficient expert support. Okay. So now we're left with a situation where the claim on its own terms is pretty broad. It doesn't explain how the object is being created other than the fact that it's employing a map. It doesn't talk about using a code generator, even though the disclosed embodiment references a code generator. There's a lot of times where disclosed embodiment will itemize a series of elements, but then the claim only recites some but not all of those elements. And there's nothing inherently wrong with that that, you know, when we have a claim like that, we don't start shoveling in every single element that's disclosed in the embodiment that isn't actually recited in the claim. We know that the patent owner knows how to recite code generator into a claim. It did it in claim 10 and it did not do it in claim 1. Well, you're on our submit there. We have an apparatus claim and a method claim. They seem to be reading on the same embodiment, but let me get to the heart of your question. What do we do in this situation? Sure. With that one, the method claim, the method claim does talk about employing a map. So that part from figure one has been brought into point one, but the code generator is not been brought into claim one. We're dealing with an abstraction here employing a map to create an interface object aside from this debate, which we've been having for most of my time on what what what the embodiment are. We also look at what the patent says about what is the problem that solved how does it solve it? What are the benefits of the invention? This is very similar to the retractable technology case to the Microsoft, the multi tech case several years back. And we look at the statement in the patent about what the benefits are at column one line 66. It's precise. A benefit of the invention is neither programmers nor software applications need have knowledge of the database structure to obtain access to the relational database that can only be done by writing code. Well, it can only be done according to the patent by having something called an interface object that bridges the gap between the database and the software. It doesn't say right there. Thanks to our handy code generator that we've invented. Well, let me let me get to the extensive evidence on it. Much of it is in the provisional. Now the first provisional is about 90 pages mentions code generation 60 times any page that doesn't mention code generation is talking about a completely different aspect. The provisional says the value proposition for this OI three, which is the embodiment in the provisional includes push button code generation. And the provisional goes on. It compares the new product to what they were calling the predecessor product. This is the September 26, 1997 provisional at 52. It distinguishes the predecessor product, which implemented map mapping at runtime. It says, OI three avoid generic instrumentation. The generic mappings will be C++ code and then it lets all these negative features of doing it the old way of doing it with doing it all at runtime execution time complexity maintenance issues start up overhead. And then it says in the provisional code generation addresses all the negative features listed above this is a clear statement of what's being invented what the benefit is. And it's throughout both of the provisional which are there in the specification they're incorporated by reference they keep referring to the code generation button the benefits of code generation how it saves the programmer time how it can accommodate changes in the database structure. Without the programmer having to do the laborious work that was in the prior art the object relational mismatch required the programmer to handwrite this code. And that's there right in the specification we don't need to go to Dr. Hoskins declaration we can see it in the specification that they had a predecessor product that didn't do code generation the original filing the second filing the third filing every reference to an interface object is the first one. So if they generate an interface object there's some different terminology in the provisional and we point to the so if the claim is read is plainly and broadly as data term would happen then would you have a validity ground. Absolutely absolutely we would but we submit that because the provisional talks about the prior art is not doing code generation and then talks about the benefits of code generation and it matches every embodiment matches figures one five six seven every reference to these things every reference to these interface objects is something that started with code generation so. The question is given you next for time do you have a final summary sentence just your honor that this invention was all about code generation and that's what the intrinsic record shows thank you. Thank you. This is available to you. Thank you. What about all these references and the provisional about the howding the need for code generation right well two things to say about that your honor first of all that is not in this record and as I think it may have been judge more maybe it was you I don't recall under 28 roll 28 I Michael strategy and the defendants cannot bring into this record of the pleadings and the Okay we got that argument but on the merit and on the merits that was not the basis the by the time that you get to the full utility application and the patent that was not the basis for distinguishing the prior art and In fact, I can tell you that in the New York case, we did not rely on the September Provisional. We relied on the December Provisional for Priority. And the patent says, at the pre-summary of the invention, the mapping, this is the front page of your patent, refers to both provisions. It does, but I'm telling you there was a late US application data. I can tell you that there was testimony by the inventor, one of the inventors that there were further developments since between September and December for the December Provisional. The... Well, let me go to the merits, though, of this issue, technical standpoint. Doesn't code have to be generated to instantiate an object. Yes. Everybody agrees, they're fighting over where the code has to be generated to create a class. You're saying, that's not part of the claims, they're saying it is, but doesn't code still have to be generated to instantiate an object. No, you're on it. You can instantiate an object from a pre-existing class. No, no, no. You have to use code to do it. This is a software patent for God'sakes. I mean, how are you instantiate an object? You're bringing it up all a clay and molding it? No, you've got to use code, right? In the... Oh, yeah. Let me put it this way, Your Honor. The patent is not specific to any one kind of object-oriented software programming language. Yes, but in all the point code, in the patent, which is referring to a glyphs C++, that is a way to do it. It's not the only way to do it. And the patent, the claim is silent as to how it gets on that. Not every way to do it, employ code. Forget about whether code is created. Oh, yes, the base. Create a class is in code a necessary component of instantiating an object. The creation of code to instantiate the object. I think we're talking about software coding in general. So the lot of things that you're right, there are a lot of things that are depending on that. The claim does not require that. And the claim does not say when that class comes into existence. What if the claim didn't say employing a map? What if it just said creating an interface object? Then it would be even broader. Right. And then would you say, oh, the claim doesn't require a map either. Yes, that claim does not require a map. If it does not recite it, it is not in the claim. And last, the mapping feature of this invention seems to be awfully critical. That's what it was going to come to when it seems to be like the heavy spotlight is on the map. And that's what I wanted to create. That's what I wanted to get to when I was answering your first question. The patent says in the brief summary of the invention at column one line 58 there about 59, the database schema, object model, and mapping are employed to provide interface objects that are utilized by an object oriented software application to access the relational database. Now the fact that the mapping is an important part of this is the claim title of the invention. And that's why it's in the claim, you're on it. Because that was part of that. And I think the runtime engine and the interface objects are all working hand in glove together to provide the interface between the object oriented application and the relational data. Likewise, if we were looking to use the specification to help us to find the invention as recent cases, which we have just issued, talk about language like present invention would be important. And at column one line 53, this says in accordance with the present invention, a mapping is employed. So you'd have a hard time running away from the map being a critical part of this invention which would need to be something that would be employed. But there is no similar language anywhere in this spec about the present invention in terms of co-generation of a class. That is correct, Your Honor. And that's why the mapping is recited in the claim and it's shown in figure 7, the attribute, I think it's step 63, is getting the attribute, which if you look at figure 6, shows that that step is part of the map. Now maybe I could leave you with this, Your Honor. One of the cases that I'm sorry. It's certainly going to leave us misspelled. But if you leave us with one further thought, that will be fine. Yeah, that's what that's where I was going. The resonate case that we cite in our reply brief, 338 F1360 at page 1365 says, the district court's level of detail analysis does not withstand close scrutiny. The patent needs apparent choice, not to specify a transmission path from the server to the client, and led the district court to add a limitation that the requested resource be transmitted directly to the client. But patent fees are not required to claim each part of an invention with the same amount of detail. Indeed, such a role likely would prove unworkable. Court may not rewrite. Thank you, Mr. Bell. We thank you all. And that's our, that's the basis of our own. Thank you. Thank you