Our first case this morning is data encryption versus Microsoft Mr. Dorman. I have two objectives in my first nine minutes this morning. The first thing to share the reasons I believe this is an important press and natural out of the NAMMISOVAL case both from a legal perspective and a public policy perspective and secondly to provide to you what I believe is the conceptual key to assuring that the trial courts, erroneous claim construction rulings are corrected consistent with the patent documents. There is an important and helpful distinction to be made when evaluating whether a judicially enforceable disavowal has occurred that no recorded decision I believe has ever been addressed and that distinction requires us to ask the following question. Is the subject matter of the alleged disavowal a component of a claimed invention itself or is it rather an advantage or a potential benefit of using the claimed invention? And if a patent in the patent describes advantages or benefits in the written description, we need to discern further are those advantages or benefits describing components of the invention or potential advantages of uses of the invention. Now that difference is key to resolving the disavowal issue in this case. Let me ask you the language one of the disavowal provisions says all data subject encryption by operation of the present invention is maintained. How is that not a disavowal? Let's deal with the operation of the present invention. The invention is a system. This is not a method claim. The invention itself relates to that combination of hardware and software that is described, for example, in Representative Claim 5. There are eight, a number of eight uses, potential uses of that particular invention that are described in the summary of invention. And whether you encrypt or have encrypted data remain in the kernel space is simply one of a number of potential uses. It's not the invention itself. You're on a, we have every case cited by Microsoft to persuade the court to graph on that negative limitation, address structural components of the claim convention itself
. You know, the solubleizer in the AstraZeneca case, the fuel filter in the Honeywell case, the dilation catheter in the Simon case, the hairspray safety, hair dryer safety mechanism in Gaubs, and in those cases, the individual patenties frequently as exococographers talk what comprises and did not comprise the invention itself. In this court properly held in all those cases that the intended scope of the invention as expressed by the inventors needs to define the invention and they should be held to what they intended. But she did contrast those cases with the facts here at bar. Here, the statements by the patenties relied on for disavowal have nothing to do with the components of the claim convention itself. The invention, again, is a file extension computer system, you know, made up of hardware and software components that are described in the description. The summary list those eight advantages, and those in the sense, those advantages are simply a list of the utility or potential utility of this invention. Now, what did Microsoft do? And this is what is most troubling, is that they pick one of eight potential advantages to be gained by the use of the invention that's described as specification, and they promote it that discretionary advantage into a requirement of the invention itself. Now, I ask you to consider the absurd result, if this is permitted to occur, that this leaves. We're a cork, as the trial court did here, finds disavowal upon the absence of the use of an articulated benefit of an invention, among many benefits that are described in the invention. It leads to the absurd result of a finding of no infringement, even though all the elements of the claim are met. And even though the alleged infringer is practicing some but not all of the articulated particular potential uses. So, where in the respect do you or in the claims, do you articulate the use that Microsoft makes? There is no use in the claim. Well, this is not a method claim. This is a system claim. There are no uses limitations in the claim
. That's precisely the point, is that they are in drafting onto a system claim, a use limitation, which is, you know, it's just, it's contrary to the law, and it's troubling. I want to move quickly, if I can, to the public policy issue here, to disemplify. I had a discussion last night with an attorney who was in house at Aver, who was a client of mine, and another matter. And I was sharing with him the subject matter of this lawsuit, and talking about disavowal and making this very distinction, and his concern about disavowal cases. And he says to me, Rod, I better tell you what I now tell my prosecutors is that in drafting patent applications, do not describe any advantages or benefits of doing it one way or another. Because if you do, we are now subject increasingly to the argument that you somehow disavow claims go. So what we have now is regrettably a situation where people are increasingly avoiding these kind of, are failing to fully utilize the teaching benefit of the patent system as well they could for fear of that. Well, I appreciate what you're saying, and but can we turn back to the language here in the patent here? Yes. What is your claim construction of the interface routine limitation? It says the language is the first and second logical data areas, through said encryption routine. What is your construction of through said encryption routine? Okay, my construction of system interface routine, I'm going to answer your first question, and claim fly for example, are instructions within the operating system that controls the transfer of data between a described and a memory, and B controls data transfers within main memory, and determines the encryption state and selectively applies encryption decryption function. The transfer issue in this case, what's key to this case, is the fundamental dispute that we have with Microsoft concerning the logical management of memory. What this patent talks about, and it's talking about transfer, is either physical transfer of data from the disk to the memory, or in the context of logical data areas, the logical transfer of information through but can you focus on its transfer through said encryption new to, can you focus on the portion that says through said encryption routine, and tell me what your construction of that is? Transfer through encryption routine is that the encryption routine is applied, first in with the kernel operating with the system, with the kernel mode of control, operating on the data, it's in place, and the transfer then, the transfer occurs where there is a logical switch to the second logical data area, after the encryption routine is applied to the data, it's applied in place, and then it is handed off to the application program. And where is that supported in the spec? In column 15. And the read system call received the discussions in column 15. Are you on line 13? Yes, it's 13
. What? You're on column 15, what line were you reading from? Right, beginning in line 13 of column 15, and even before prefectory to that, on column 13, if you look down at a rather on the portion beginning on line 34. What can we just stick with column 15 for a moment? I'm pleased to go back there, but the foundation, let me just, you know, to answer your question, Ron, is that figure 4c, that talks about encryption in place beginning on column 13, line 34, all the way through line 65. It explains, importantly, at line 52, in accordance with the preferred embodying of the present mentioned, the encrypted encrypted blocks 82 and 88 are one and the same. So it was explaining that although in figure 4c, you see two different blocks on the right left hand side, those are really the same blocks, the transfers occurring through a change of the logical address. That's what's occurring with respect to that. And then, if you go to 15, there is a further explanation of how in the read right, rather than the read system, call procedure, that's utilized with an explanation then at the bottom, even that this again is encryption done in place repeatedly. I'm not understanding. Down on line 59, if authentication succeeds, the right data buffer again existing in the user data space is located, and the contents of the buffer encrypted, the encryption procedure used, is that discussed in connection with figure 4a, which is that earlier discussion with respect to the encryption in place. So the transfer is a logical transfer of data addresses so that the same memory block, if you will, at one point in time is subject to the operating system control in the kernel where they apply the encryption routine, and then a logical transfer occurs after the encryption occurs, for example, where that is handed off to the processor operating using the user application. But the word transfer doesn't occur in this section in column 15. It does not. The word transfer, I don't believe, is actually there, but that's clearly what is described and what is understood by one of school in your end as to transfer the predetermined block through said encryption routine. But transfers, you're telling me it's not here, but that's what we're talking about. We're talking about two types of transfers in one of our school in our understand when they talk about transfers just to address change you're saying in this case. Correct, but what it is, it's an address change that allows a modality switch from kernel mode to user mode
. In other words, it allows access of the different modality. This is what the patents talking about where it talks about the. The kernel mode is not equivalent to current space, right? It's correct. What we're talking about here is first logical data area and second logical data area in this patent talks about which the operating system is executing instructions based upon the operating system or based upon application user application activities. That's what what this patent is talking about. And if I may reserve a couple minutes, you were going to give you your time backs. You'll be fine. Thank you, Mr. Doran. Mr. Benjamin, if you could give him as Hanseker an additional four minutes, if she needs to use it, then that'll. Keep the time a little more even. Thank you, Your Honor. You're welcome. May I please the court counsel for deck just stood up here and told you that disavowal has nothing to do with the components of the invention itself itself
. That is completely wrong. And let me show you why if I could please direct the court's attention to page six of respondents red breath. There is a figure that illustrates very well all of the technical plane construction and non-inferential issues necessary to resolve this case. This figure is part of the intrinsic record of the patent. It comes from box design of the Unix operating system, which is incorporated by reference into the patent specification. And it provides a logical layout of the computer system with the hardware at the bottom highlighted in red, the kernel memory area in the middle and blue, and the user memory area at the top in yellow. As this court focused on in the questions to Mr. Doran, the claim language, independent of the disavowal, the claim language of all these started claims requires a system that encrypts and decrypts data between the blue and the yellow, between the kernel memory area and the user memory area. Let me ask you just about this chart. The buffer cache is... Here it says buffer cache and the patent, the diagram says buffer pool, one and the same. One and the same and the specification also at column five line 63 says within the kernel space a buffer pool or buffer cache is maintained by the operating system. Actually I saw something similar in another part of the patent
. And then in Windows system, Windows decrypts a block of data, is a copy of the unencrypted data always placed in the cache. In the default mode of operation, Windows always decrypts, always places a copy of the data in the buffer cache. The unencrypted data. If I could go back to... Oh so let me just say, I couldn't find anything in the record that discusses that or supports that. Is that something you could point me to? Yes, if you could go to A326, this document is the EFS which is the encrypting file system of Windows, driver specification, data in 2002, long before this lawsuit rose. Okay, well that's... I'm going to go ahead and make a point, I just need that clarification. Okay, that's a good document to go to at this point. Paragraph 1.3 of that specification says that Windows encrypts and decrypts data when it is transferred to and from disk
. On this diagram, on page 6 of our brief, that's between the red and the blue. The claims on the other hand, both claim 5 and independent claim 8 require an encryption routine that is employed when data is transferred between the first logical data area and the second logical data area. Now this claim language provided an independent basis for the court summary judgment. So regardless of disavowal, regardless of the location of data, this court based solely on the claim language can confirm the judgment below. However, I'd like to explain to you how this claim language provides the structure relevant to the disavowal statements in this specification. If data is being transferred from disk and it is decrypted between the red and the blue. At that point, when it's in kernel memory, the data is unencrypted, it's unprotected. On the other hand, in the pattern where the decryption does not happen until between the blue and the yellow, when the data is transferred from the disk to the blue, it is still encrypted and it's encrypted in the first logical data area. It is only decrypted when it is passed up to the user application between the boundary between the blue and the yellow. Now, how do we know that with certainty? I understand that that's the preferred embodiment, but how do we know with certainty that that's it? I mean, we have to use the disavowal argument. I mean, that's your disavowal argument. Well, it's independent of the disavowal argument. And so I'll get to the disavowal argument in a minute. But my point being that under Phillips and this Court's other claim instructions, when you're interpreting the language of the claim, and at this point, I'm referring to the clause, selectively directing the predetermined, selectively directing the transfer of data between the first and second logical data areas. One of the benefits of the invention described in the specification is the ability to maintain data unencrypted in kernel memory, or, excuse me, encrypted in kernel memory
. And by specifying when the encryption and decryption take place, namely at the highest levels of the operating system, the claim language, in all of these assertive claims, has in fact provided that advantage as a component of the invention. Mr. Dorman's only argument, why the claim language alone, why that basis does not provide Microsoft grounds for summary judgment, is really a disputed issue of claim construction. It is not a disputed issue of fact. Mr. Dorman would like this Court to construe a data transfer as being the same as a load switch. There is nothing in the claim language, nothing in the specification, nothing in the box book incorporated by reference, and nothing in the expert testimony that supports that construct. We're in the claim, particularly this selectively language, selectively directing the transfer, does it require encryption upon transfer. Where it says through setting encryption routine, so the claim reads the clause that we're talking about, says said system interface routine, selectively directing the transfer of said predetermined block of data between said first and second logical data areas, through said encryption routine. Is that encryption upon transfer? That requires that the encryption happen when the data is transferred between carlin user memory, not when it's transferred between disk and memory. What is it that I assume that the first and second, what's the language first and second logical data areas of the user memory and the kernel memory. What is it that establishes that the transferred through said encryption routine means that encryption occurs at the time of that transfer. Where would we look to pin that point down? That was your response to just Raider's question, and my follow-up is where in the pattern would we find support for that assertion? The support for the assertion that encryption rather transferred through said encryption routine means encryption upon the point of transfer between kernel and user memory. So I would first point to the claim language itself. Well, you've got the explanation
. He said it all occurs at one place, they just change the address. So the specification? That's the through said encryption routine and he supports it. So we need to have you show us somewhere where that is requiring us to see the encryption occurring not in one place but moving at the time of the transfer. Well, to be clear, I don't disagree with Mr. Dorman that the data is decrypted in place in the sense that it is located in a single memory area. So the question is, let me back up for a second. In describing the Cummings prior art, the way that encryption during a transfer is defined is that it's part of the transfer operation. It has to actually be in memory. So in other words, the data is physically in a memory buffer. By saying it happens during a transfer, it means that it happens as part of the transfer operations, part of the set of instructions in the software that is transferring the data between the kernel memory and the user memory. In answer to the court's previous question, at column five, beginning at line 59, the specification draws a clear distinction when it is talking about a process running, the mode of operation, in this case it says when the CPU is executing program code in user space, the process within which such execution is occurring then exists in user mode, where the process is executing in kernel space, then execution is in kernel mode. It doesn't refer to that as a transfer of data or the location of data. The next sentence, on the other hand, says within the kernel space a buffer pool or buffer cache is maintained by the operating system. If I'm hearing you, right, you're telling me encryption routine, which is a phrase used several times, includes a transfer. You're trying to read the transfer into the encryption routine, I'm not sure it's there
. No, the system interface routine is what includes a transfer. And what the claim language does is it creates a structural relation between the transfer of the system interface routine and the encryption routine. Well, I think I'm still with where Judge Prost was, is that you're still going to require us to rely on the disavowl, and then we have the problem of finding out whether that's a clear and unequivocal disavowl. So I'll get to the disavowl and just one in just a moment, I didn't want to point the court in answer to its question regarding where in the specification it describes encryption between the system interface and the encryption. The user in kernel memory. At the bottom of column 13, line 66, it begins talking about buffered random reads and writes of an encrypted file are permitted by operation of the present mentioned earlier in the specification. And in chapter three of the book, there's lengthy discussion about buffer reads and writes. I'm correct. This is all part of the, is this a preferred embodiment? The portion of the specification that I'm reading is describing a preferred embodiment. We think it also specifies clear and manifest disavowl, but it is describing the invention, the present invention. So at the top of column 14, it goes on to say that the entire data file need not be read into memory or otherwise copied for decryption rather only the specific block containing the file portion requested unaware and uninformed of the operation of the present mentioned need be decrypted. Going down to, and that's the disavowl line, which I mean that's part that's what precedes the language that you and the court relied on for the disavowl correct. That's correct. But that's just one embodiment. Your honor, it's described as the present invention. Let me, let me turn to the disavowl. This is not like ventana, metacool, or like go light, which in the primary case is relied on by data. This is not a case where there's general descriptions of advantages of the invention and nothing more. To the contrary, in column two of the specification, we not only have the patentee disparaging the prior art that allowed unencrypted data in the Pernel memory. We not only have, at column four in the summary of the invention, a statement that an advantage of the present invention includes the opposite feature. But that's one advantage out of eight, and this kind of harkens back to our Phillips case. We don't focus in on a single advantage is limiting the claim. That's absolutely right, and that's why the language at column 14 provides the something more that this court has required in disavowl. And that's because you're saying it's not limited because it repeatedly refers to the describing the operation of the present invention. So it's not limited to. It's a description of the present invention, but it's also use of language, all data, subject to encryption by operation of the present invention, is maintained in an encrypted state in the buffer pool. Since the assignment case, since the all embodiments language in the assignment case, this is about as close to that as it can be without actually saying all embodiments. There's not a rigid requirement that the language of the specifications say all embodiments in order to affect the disavowl. Going back to your column 14, it says the entire file need not even be read into memory. Thus it may be read in, right? The specification talks at length about decrypting data on block by block basis and the claim
. Let me, let me turn to the disavowl. This is not like ventana, metacool, or like go light, which in the primary case is relied on by data. This is not a case where there's general descriptions of advantages of the invention and nothing more. To the contrary, in column two of the specification, we not only have the patentee disparaging the prior art that allowed unencrypted data in the Pernel memory. We not only have, at column four in the summary of the invention, a statement that an advantage of the present invention includes the opposite feature. But that's one advantage out of eight, and this kind of harkens back to our Phillips case. We don't focus in on a single advantage is limiting the claim. That's absolutely right, and that's why the language at column 14 provides the something more that this court has required in disavowl. And that's because you're saying it's not limited because it repeatedly refers to the describing the operation of the present invention. So it's not limited to. It's a description of the present invention, but it's also use of language, all data, subject to encryption by operation of the present invention, is maintained in an encrypted state in the buffer pool. Since the assignment case, since the all embodiments language in the assignment case, this is about as close to that as it can be without actually saying all embodiments. There's not a rigid requirement that the language of the specifications say all embodiments in order to affect the disavowl. Going back to your column 14, it says the entire file need not even be read into memory. Thus it may be read in, right? The specification talks at length about decrypting data on block by block basis and the claim. To the extent you're relying on this is clear and unequivocal. It's starting to look less clear and unequivocal, isn't it? No, you're on a beat. Beginning at line 10. It's as data pending either a read or write operation to dis. Again, we're talking here about a single embodiment, but I understand that this is somewhat helpful to your argument, but it's in the context of something that may or may not be read into the memory. The statement all data is subject to operation, to encryption by operation of the present invention is maintained in encrypted state in the buffer pool refers to the present invention. And our problem is the claim just does not say if the claim did say maintain encrypted, there's no maintained word in the claim is there. There's not. The claim just says encryption routine. The claim says that the data is, that a pre-determined block of data is transferred between the kernel memory and the user memory through the encryption. Through an encryption routine, yes, we were there a minute ago. So by stating that all data is subject to encryption by operation of the present invention is maintained in a encrypted state in the buffer pool. There's no way a reasonable competitor reading that language would believe that software that does in fact maintain data, unencrypted in the buffer pool, be covered. And that is what we require that competitor to read the claim and we wouldn't find any language in the claim about maintaining encryption, would we? We would find language in the claim specifying that encryption must happen between kernel and user memory. Against somewhat unclear language, it says directing transfer through set encryption routine which may happen in the same place may not include transfer at all
. To the extent you're relying on this is clear and unequivocal. It's starting to look less clear and unequivocal, isn't it? No, you're on a beat. Beginning at line 10. It's as data pending either a read or write operation to dis. Again, we're talking here about a single embodiment, but I understand that this is somewhat helpful to your argument, but it's in the context of something that may or may not be read into the memory. The statement all data is subject to operation, to encryption by operation of the present invention is maintained in encrypted state in the buffer pool refers to the present invention. And our problem is the claim just does not say if the claim did say maintain encrypted, there's no maintained word in the claim is there. There's not. The claim just says encryption routine. The claim says that the data is, that a pre-determined block of data is transferred between the kernel memory and the user memory through the encryption. Through an encryption routine, yes, we were there a minute ago. So by stating that all data is subject to encryption by operation of the present invention is maintained in a encrypted state in the buffer pool. There's no way a reasonable competitor reading that language would believe that software that does in fact maintain data, unencrypted in the buffer pool, be covered. And that is what we require that competitor to read the claim and we wouldn't find any language in the claim about maintaining encryption, would we? We would find language in the claim specifying that encryption must happen between kernel and user memory. Against somewhat unclear language, it says directing transfer through set encryption routine which may happen in the same place may not include transfer at all. Well, I believe the claim does require that there be a transfer between kernel and user memory and what this language does is it creates a structural relationship between that transfer and the encryption routine itself. The confidential markings in the briefs, those are under a protective order. There is a matter of subject to protect where? Please take more time if you need it. If you need more time, please proceed. Okay. Up until data file that's repniated in this case, the system that they accused of infringement was a system that falls squarely within the disaball of the path. It falls squarely within this statement of column 14, lines 13 through 15. It was a product that maintains data in kernel memory, unencrypted, just like the Cummings prior are. And regardless whether the claims require maintenance of data or don't require maintenance of data, this statement clearly says that if software does maintain data in an unencrypted state, it's not covered by this pattern. Am I correct that there's no prosecution history that adds any weight to your disaball? How's your meant? It's based purely on the specification. Could we give you a couple minutes to wind up here? One final point going back to Mr. Dorman's argument about the logical versus the physical. The question is not whether there's a physical or logical transfer of data. The question is what must be transferred. And again, looking at the language of the claim, the language of the claim refers to data areas and data spaces, not modes of operation
. Well, I believe the claim does require that there be a transfer between kernel and user memory and what this language does is it creates a structural relationship between that transfer and the encryption routine itself. The confidential markings in the briefs, those are under a protective order. There is a matter of subject to protect where? Please take more time if you need it. If you need more time, please proceed. Okay. Up until data file that's repniated in this case, the system that they accused of infringement was a system that falls squarely within the disaball of the path. It falls squarely within this statement of column 14, lines 13 through 15. It was a product that maintains data in kernel memory, unencrypted, just like the Cummings prior are. And regardless whether the claims require maintenance of data or don't require maintenance of data, this statement clearly says that if software does maintain data in an unencrypted state, it's not covered by this pattern. Am I correct that there's no prosecution history that adds any weight to your disaball? How's your meant? It's based purely on the specification. Could we give you a couple minutes to wind up here? One final point going back to Mr. Dorman's argument about the logical versus the physical. The question is not whether there's a physical or logical transfer of data. The question is what must be transferred. And again, looking at the language of the claim, the language of the claim refers to data areas and data spaces, not modes of operation. The language of the claim refers to the transfer of a predetermined block of data, not the transfer of a mode of operation. In both the specification and in the blockbook, it's made very clear that user memory addresses can still be accessed while operating in kernel mode. It doesn't alter the location of the, it doesn't change a user memory address to become a kernel memory address merely because it's being operated on by a kernel word process. So I submit to you, there are at least two independent grounds that you can affirm the court's judgment below. The court concluded there's no disputed issue of material fact that windows does not transform the data between kernel memory and user memory. Instead, it transforms the data between the disk and the memory just as the prior art did. An independent of that limitation, that affirmative limitation in the claims is the ground that in the patent specification, there was a very clear and very manifest disavowable. I think we're starting to repeat. Just one final question. I assume you have validity arguments if this should happen to go back. Is that correct? We do. But it just haven't been reached yet in the process. They were dismissed without prejudice so that the appeal could come up in the court would have jurisdiction to decide the infringement. Thank you, Ms. Uncistak
. The language of the claim refers to the transfer of a predetermined block of data, not the transfer of a mode of operation. In both the specification and in the blockbook, it's made very clear that user memory addresses can still be accessed while operating in kernel mode. It doesn't alter the location of the, it doesn't change a user memory address to become a kernel memory address merely because it's being operated on by a kernel word process. So I submit to you, there are at least two independent grounds that you can affirm the court's judgment below. The court concluded there's no disputed issue of material fact that windows does not transform the data between kernel memory and user memory. Instead, it transforms the data between the disk and the memory just as the prior art did. An independent of that limitation, that affirmative limitation in the claims is the ground that in the patent specification, there was a very clear and very manifest disavowable. I think we're starting to repeat. Just one final question. I assume you have validity arguments if this should happen to go back. Is that correct? We do. But it just haven't been reached yet in the process. They were dismissed without prejudice so that the appeal could come up in the court would have jurisdiction to decide the infringement. Thank you, Ms. Uncistak. If you could give Mr. Dorman nine minutes, that would pretty close to even think about. If you need to use the Mr. Dorman. Thank you. All right. I don't think I'll need to use them. The, just a couple points. The repeated reference to the static picture in page six. You know, this picture points up the fundamental dispute, I think it's going on. Part of the problem with the briefing in this case, at least the early briefing until the reply brief. It's as if they're talking about two different things. I had that sense. And part of that was because their patent world is a static patent world of, there are bound reads and there are spaces and there's user memory. There's kernel memory and never the two show me, etc
. If you could give Mr. Dorman nine minutes, that would pretty close to even think about. If you need to use the Mr. Dorman. Thank you. All right. I don't think I'll need to use them. The, just a couple points. The repeated reference to the static picture in page six. You know, this picture points up the fundamental dispute, I think it's going on. Part of the problem with the briefing in this case, at least the early briefing until the reply brief. It's as if they're talking about two different things. I had that sense. And part of that was because their patent world is a static patent world of, there are bound reads and there are spaces and there's user memory. There's kernel memory and never the two show me, etc. And our understanding of this patent, reading this patent consistent with the box book and the Unic system, is that it's a dynamic system where you can have kernel memory, you can have user memory. But what's important to identify a first logical data area and a second logical data area is which instructions have control of the data in that area. In other words, when a piece of data is in the user memory, but that data is being accessed by the operating system using operating system instructions. In other words, it's being accessed in kernel mode. That's the first logical data area. It's dictated by the mode in which it's operated. That's how this patent explains. But kernel mode is not kernel memory, right? So it's in the user memory and it's operated under kernel mode. Correct. The kernel mode is not the same as kernel space. Now, where in the patent is there any, or anywhere in the record, is there anything that says a change in mode is the same as a transfer? Well, I don't think that that definition statement is not anywhere. But how do I reach that conclusion? You're telling, if I understand right, you're saying that. I am saying that. And in column 5 of the patent, if you look at line 56, what does it struggle in line 50 words? It's the main memory 16 provides an addressable memory space to the CPU 12 for the storage of application programs and data and of the operating system and the related data. It's generally depicted in the figure one
. And our understanding of this patent, reading this patent consistent with the box book and the Unic system, is that it's a dynamic system where you can have kernel memory, you can have user memory. But what's important to identify a first logical data area and a second logical data area is which instructions have control of the data in that area. In other words, when a piece of data is in the user memory, but that data is being accessed by the operating system using operating system instructions. In other words, it's being accessed in kernel mode. That's the first logical data area. It's dictated by the mode in which it's operated. That's how this patent explains. But kernel mode is not kernel memory, right? So it's in the user memory and it's operated under kernel mode. Correct. The kernel mode is not the same as kernel space. Now, where in the patent is there any, or anywhere in the record, is there anything that says a change in mode is the same as a transfer? Well, I don't think that that definition statement is not anywhere. But how do I reach that conclusion? You're telling, if I understand right, you're saying that. I am saying that. And in column 5 of the patent, if you look at line 56, what does it struggle in line 50 words? It's the main memory 16 provides an addressable memory space to the CPU 12 for the storage of application programs and data and of the operating system and the related data. It's generally depicted in the figure one. The main memory 16 is logically managed. So here we have, contrary to what Microsoft's counsel just said, that there's no discussion of mode, logical management, here it's right in the patent. It's logically managed as a combination of user space and kernel space. When the CPU 12 is executing program code in user space, the process within which such extension is occurring then exists in user mode. When the process is executing in kernel space, then execution is in kernel mode. And you are quite correct, Your Honor, that it would have been nice that then there was a further exploration of precisely that when a operating system is in kernel mode, even working on data that's in user space, that's trying to tell me what a skill in our would understand. I am talking about that's exactly what any computer scientist would understand reading this. And this is to whom this matter speaks. And that's precisely where this is. Now, the final thing you're honored that I'd like to do is. So let me just be clear on your construction of encryption routine is what? Can I do a better job with what you was with the transfer through encryption routine? Because I'm up that when I was first given a second opportunity. Well, I just like a clear proposal in terms of what the construction is. Okay, well, my definition of transfer through encryption routine is encryption of data in place and importance with a figure of 4D. I mean, that's what the patent teaches. And a logical change in access to the data from the processor in kernel mode to the processor in user mode
. The main memory 16 is logically managed. So here we have, contrary to what Microsoft's counsel just said, that there's no discussion of mode, logical management, here it's right in the patent. It's logically managed as a combination of user space and kernel space. When the CPU 12 is executing program code in user space, the process within which such extension is occurring then exists in user mode. When the process is executing in kernel space, then execution is in kernel mode. And you are quite correct, Your Honor, that it would have been nice that then there was a further exploration of precisely that when a operating system is in kernel mode, even working on data that's in user space, that's trying to tell me what a skill in our would understand. I am talking about that's exactly what any computer scientist would understand reading this. And this is to whom this matter speaks. And that's precisely where this is. Now, the final thing you're honored that I'd like to do is. So let me just be clear on your construction of encryption routine is what? Can I do a better job with what you was with the transfer through encryption routine? Because I'm up that when I was first given a second opportunity. Well, I just like a clear proposal in terms of what the construction is. Okay, well, my definition of transfer through encryption routine is encryption of data in place and importance with a figure of 4D. I mean, that's what the patent teaches. And a logical change in access to the data from the processor in kernel mode to the processor in user mode. I mean, that's what's occurring. That's what this teaches. Where is encryption occurring under that definition? And where is the encryption occurring? The data that's being encrypted is either in user space or kernel space depending upon which particular. What we're talking about, what we're talking about, what it's about, the change mode specification or the read call. No copy of that data is made. It's written over. So what happens is whatever processing instructions are working or working on it right in place, it isn't physically taken somewhere. It's my understanding about how this works. The extent that it's processed in place. We are in the first logical data area. First lunch, because. In the kernel memory. It's in the first logical data area. It may or may not be kernel memory. It's first logical data area is determined by what modality is acting on the data
. I mean, that's what's occurring. That's what this teaches. Where is encryption occurring under that definition? And where is the encryption occurring? The data that's being encrypted is either in user space or kernel space depending upon which particular. What we're talking about, what we're talking about, what it's about, the change mode specification or the read call. No copy of that data is made. It's written over. So what happens is whatever processing instructions are working or working on it right in place, it isn't physically taken somewhere. It's my understanding about how this works. The extent that it's processed in place. We are in the first logical data area. First lunch, because. In the kernel memory. It's in the first logical data area. It may or may not be kernel memory. It's first logical data area is determined by what modality is acting on the data. That's how I understand that this path. Thank you. Thank you, Mr. Dorman. Thank you both counsel. Tough sledding as they say.
Our first case this morning is data encryption versus Microsoft Mr. Dorman. I have two objectives in my first nine minutes this morning. The first thing to share the reasons I believe this is an important press and natural out of the NAMMISOVAL case both from a legal perspective and a public policy perspective and secondly to provide to you what I believe is the conceptual key to assuring that the trial courts, erroneous claim construction rulings are corrected consistent with the patent documents. There is an important and helpful distinction to be made when evaluating whether a judicially enforceable disavowal has occurred that no recorded decision I believe has ever been addressed and that distinction requires us to ask the following question. Is the subject matter of the alleged disavowal a component of a claimed invention itself or is it rather an advantage or a potential benefit of using the claimed invention? And if a patent in the patent describes advantages or benefits in the written description, we need to discern further are those advantages or benefits describing components of the invention or potential advantages of uses of the invention. Now that difference is key to resolving the disavowal issue in this case. Let me ask you the language one of the disavowal provisions says all data subject encryption by operation of the present invention is maintained. How is that not a disavowal? Let's deal with the operation of the present invention. The invention is a system. This is not a method claim. The invention itself relates to that combination of hardware and software that is described, for example, in Representative Claim 5. There are eight, a number of eight uses, potential uses of that particular invention that are described in the summary of invention. And whether you encrypt or have encrypted data remain in the kernel space is simply one of a number of potential uses. It's not the invention itself. You're on a, we have every case cited by Microsoft to persuade the court to graph on that negative limitation, address structural components of the claim convention itself. You know, the solubleizer in the AstraZeneca case, the fuel filter in the Honeywell case, the dilation catheter in the Simon case, the hairspray safety, hair dryer safety mechanism in Gaubs, and in those cases, the individual patenties frequently as exococographers talk what comprises and did not comprise the invention itself. In this court properly held in all those cases that the intended scope of the invention as expressed by the inventors needs to define the invention and they should be held to what they intended. But she did contrast those cases with the facts here at bar. Here, the statements by the patenties relied on for disavowal have nothing to do with the components of the claim convention itself. The invention, again, is a file extension computer system, you know, made up of hardware and software components that are described in the description. The summary list those eight advantages, and those in the sense, those advantages are simply a list of the utility or potential utility of this invention. Now, what did Microsoft do? And this is what is most troubling, is that they pick one of eight potential advantages to be gained by the use of the invention that's described as specification, and they promote it that discretionary advantage into a requirement of the invention itself. Now, I ask you to consider the absurd result, if this is permitted to occur, that this leaves. We're a cork, as the trial court did here, finds disavowal upon the absence of the use of an articulated benefit of an invention, among many benefits that are described in the invention. It leads to the absurd result of a finding of no infringement, even though all the elements of the claim are met. And even though the alleged infringer is practicing some but not all of the articulated particular potential uses. So, where in the respect do you or in the claims, do you articulate the use that Microsoft makes? There is no use in the claim. Well, this is not a method claim. This is a system claim. There are no uses limitations in the claim. That's precisely the point, is that they are in drafting onto a system claim, a use limitation, which is, you know, it's just, it's contrary to the law, and it's troubling. I want to move quickly, if I can, to the public policy issue here, to disemplify. I had a discussion last night with an attorney who was in house at Aver, who was a client of mine, and another matter. And I was sharing with him the subject matter of this lawsuit, and talking about disavowal and making this very distinction, and his concern about disavowal cases. And he says to me, Rod, I better tell you what I now tell my prosecutors is that in drafting patent applications, do not describe any advantages or benefits of doing it one way or another. Because if you do, we are now subject increasingly to the argument that you somehow disavow claims go. So what we have now is regrettably a situation where people are increasingly avoiding these kind of, are failing to fully utilize the teaching benefit of the patent system as well they could for fear of that. Well, I appreciate what you're saying, and but can we turn back to the language here in the patent here? Yes. What is your claim construction of the interface routine limitation? It says the language is the first and second logical data areas, through said encryption routine. What is your construction of through said encryption routine? Okay, my construction of system interface routine, I'm going to answer your first question, and claim fly for example, are instructions within the operating system that controls the transfer of data between a described and a memory, and B controls data transfers within main memory, and determines the encryption state and selectively applies encryption decryption function. The transfer issue in this case, what's key to this case, is the fundamental dispute that we have with Microsoft concerning the logical management of memory. What this patent talks about, and it's talking about transfer, is either physical transfer of data from the disk to the memory, or in the context of logical data areas, the logical transfer of information through but can you focus on its transfer through said encryption new to, can you focus on the portion that says through said encryption routine, and tell me what your construction of that is? Transfer through encryption routine is that the encryption routine is applied, first in with the kernel operating with the system, with the kernel mode of control, operating on the data, it's in place, and the transfer then, the transfer occurs where there is a logical switch to the second logical data area, after the encryption routine is applied to the data, it's applied in place, and then it is handed off to the application program. And where is that supported in the spec? In column 15. And the read system call received the discussions in column 15. Are you on line 13? Yes, it's 13. What? You're on column 15, what line were you reading from? Right, beginning in line 13 of column 15, and even before prefectory to that, on column 13, if you look down at a rather on the portion beginning on line 34. What can we just stick with column 15 for a moment? I'm pleased to go back there, but the foundation, let me just, you know, to answer your question, Ron, is that figure 4c, that talks about encryption in place beginning on column 13, line 34, all the way through line 65. It explains, importantly, at line 52, in accordance with the preferred embodying of the present mentioned, the encrypted encrypted blocks 82 and 88 are one and the same. So it was explaining that although in figure 4c, you see two different blocks on the right left hand side, those are really the same blocks, the transfers occurring through a change of the logical address. That's what's occurring with respect to that. And then, if you go to 15, there is a further explanation of how in the read right, rather than the read system, call procedure, that's utilized with an explanation then at the bottom, even that this again is encryption done in place repeatedly. I'm not understanding. Down on line 59, if authentication succeeds, the right data buffer again existing in the user data space is located, and the contents of the buffer encrypted, the encryption procedure used, is that discussed in connection with figure 4a, which is that earlier discussion with respect to the encryption in place. So the transfer is a logical transfer of data addresses so that the same memory block, if you will, at one point in time is subject to the operating system control in the kernel where they apply the encryption routine, and then a logical transfer occurs after the encryption occurs, for example, where that is handed off to the processor operating using the user application. But the word transfer doesn't occur in this section in column 15. It does not. The word transfer, I don't believe, is actually there, but that's clearly what is described and what is understood by one of school in your end as to transfer the predetermined block through said encryption routine. But transfers, you're telling me it's not here, but that's what we're talking about. We're talking about two types of transfers in one of our school in our understand when they talk about transfers just to address change you're saying in this case. Correct, but what it is, it's an address change that allows a modality switch from kernel mode to user mode. In other words, it allows access of the different modality. This is what the patents talking about where it talks about the. The kernel mode is not equivalent to current space, right? It's correct. What we're talking about here is first logical data area and second logical data area in this patent talks about which the operating system is executing instructions based upon the operating system or based upon application user application activities. That's what what this patent is talking about. And if I may reserve a couple minutes, you were going to give you your time backs. You'll be fine. Thank you, Mr. Doran. Mr. Benjamin, if you could give him as Hanseker an additional four minutes, if she needs to use it, then that'll. Keep the time a little more even. Thank you, Your Honor. You're welcome. May I please the court counsel for deck just stood up here and told you that disavowal has nothing to do with the components of the invention itself itself. That is completely wrong. And let me show you why if I could please direct the court's attention to page six of respondents red breath. There is a figure that illustrates very well all of the technical plane construction and non-inferential issues necessary to resolve this case. This figure is part of the intrinsic record of the patent. It comes from box design of the Unix operating system, which is incorporated by reference into the patent specification. And it provides a logical layout of the computer system with the hardware at the bottom highlighted in red, the kernel memory area in the middle and blue, and the user memory area at the top in yellow. As this court focused on in the questions to Mr. Doran, the claim language, independent of the disavowal, the claim language of all these started claims requires a system that encrypts and decrypts data between the blue and the yellow, between the kernel memory area and the user memory area. Let me ask you just about this chart. The buffer cache is... Here it says buffer cache and the patent, the diagram says buffer pool, one and the same. One and the same and the specification also at column five line 63 says within the kernel space a buffer pool or buffer cache is maintained by the operating system. Actually I saw something similar in another part of the patent. And then in Windows system, Windows decrypts a block of data, is a copy of the unencrypted data always placed in the cache. In the default mode of operation, Windows always decrypts, always places a copy of the data in the buffer cache. The unencrypted data. If I could go back to... Oh so let me just say, I couldn't find anything in the record that discusses that or supports that. Is that something you could point me to? Yes, if you could go to A326, this document is the EFS which is the encrypting file system of Windows, driver specification, data in 2002, long before this lawsuit rose. Okay, well that's... I'm going to go ahead and make a point, I just need that clarification. Okay, that's a good document to go to at this point. Paragraph 1.3 of that specification says that Windows encrypts and decrypts data when it is transferred to and from disk. On this diagram, on page 6 of our brief, that's between the red and the blue. The claims on the other hand, both claim 5 and independent claim 8 require an encryption routine that is employed when data is transferred between the first logical data area and the second logical data area. Now this claim language provided an independent basis for the court summary judgment. So regardless of disavowal, regardless of the location of data, this court based solely on the claim language can confirm the judgment below. However, I'd like to explain to you how this claim language provides the structure relevant to the disavowal statements in this specification. If data is being transferred from disk and it is decrypted between the red and the blue. At that point, when it's in kernel memory, the data is unencrypted, it's unprotected. On the other hand, in the pattern where the decryption does not happen until between the blue and the yellow, when the data is transferred from the disk to the blue, it is still encrypted and it's encrypted in the first logical data area. It is only decrypted when it is passed up to the user application between the boundary between the blue and the yellow. Now, how do we know that with certainty? I understand that that's the preferred embodiment, but how do we know with certainty that that's it? I mean, we have to use the disavowal argument. I mean, that's your disavowal argument. Well, it's independent of the disavowal argument. And so I'll get to the disavowal argument in a minute. But my point being that under Phillips and this Court's other claim instructions, when you're interpreting the language of the claim, and at this point, I'm referring to the clause, selectively directing the predetermined, selectively directing the transfer of data between the first and second logical data areas. One of the benefits of the invention described in the specification is the ability to maintain data unencrypted in kernel memory, or, excuse me, encrypted in kernel memory. And by specifying when the encryption and decryption take place, namely at the highest levels of the operating system, the claim language, in all of these assertive claims, has in fact provided that advantage as a component of the invention. Mr. Dorman's only argument, why the claim language alone, why that basis does not provide Microsoft grounds for summary judgment, is really a disputed issue of claim construction. It is not a disputed issue of fact. Mr. Dorman would like this Court to construe a data transfer as being the same as a load switch. There is nothing in the claim language, nothing in the specification, nothing in the box book incorporated by reference, and nothing in the expert testimony that supports that construct. We're in the claim, particularly this selectively language, selectively directing the transfer, does it require encryption upon transfer. Where it says through setting encryption routine, so the claim reads the clause that we're talking about, says said system interface routine, selectively directing the transfer of said predetermined block of data between said first and second logical data areas, through said encryption routine. Is that encryption upon transfer? That requires that the encryption happen when the data is transferred between carlin user memory, not when it's transferred between disk and memory. What is it that I assume that the first and second, what's the language first and second logical data areas of the user memory and the kernel memory. What is it that establishes that the transferred through said encryption routine means that encryption occurs at the time of that transfer. Where would we look to pin that point down? That was your response to just Raider's question, and my follow-up is where in the pattern would we find support for that assertion? The support for the assertion that encryption rather transferred through said encryption routine means encryption upon the point of transfer between kernel and user memory. So I would first point to the claim language itself. Well, you've got the explanation. He said it all occurs at one place, they just change the address. So the specification? That's the through said encryption routine and he supports it. So we need to have you show us somewhere where that is requiring us to see the encryption occurring not in one place but moving at the time of the transfer. Well, to be clear, I don't disagree with Mr. Dorman that the data is decrypted in place in the sense that it is located in a single memory area. So the question is, let me back up for a second. In describing the Cummings prior art, the way that encryption during a transfer is defined is that it's part of the transfer operation. It has to actually be in memory. So in other words, the data is physically in a memory buffer. By saying it happens during a transfer, it means that it happens as part of the transfer operations, part of the set of instructions in the software that is transferring the data between the kernel memory and the user memory. In answer to the court's previous question, at column five, beginning at line 59, the specification draws a clear distinction when it is talking about a process running, the mode of operation, in this case it says when the CPU is executing program code in user space, the process within which such execution is occurring then exists in user mode, where the process is executing in kernel space, then execution is in kernel mode. It doesn't refer to that as a transfer of data or the location of data. The next sentence, on the other hand, says within the kernel space a buffer pool or buffer cache is maintained by the operating system. If I'm hearing you, right, you're telling me encryption routine, which is a phrase used several times, includes a transfer. You're trying to read the transfer into the encryption routine, I'm not sure it's there. No, the system interface routine is what includes a transfer. And what the claim language does is it creates a structural relation between the transfer of the system interface routine and the encryption routine. Well, I think I'm still with where Judge Prost was, is that you're still going to require us to rely on the disavowl, and then we have the problem of finding out whether that's a clear and unequivocal disavowl. So I'll get to the disavowl and just one in just a moment, I didn't want to point the court in answer to its question regarding where in the specification it describes encryption between the system interface and the encryption. The user in kernel memory. At the bottom of column 13, line 66, it begins talking about buffered random reads and writes of an encrypted file are permitted by operation of the present mentioned earlier in the specification. And in chapter three of the book, there's lengthy discussion about buffer reads and writes. I'm correct. This is all part of the, is this a preferred embodiment? The portion of the specification that I'm reading is describing a preferred embodiment. We think it also specifies clear and manifest disavowl, but it is describing the invention, the present invention. So at the top of column 14, it goes on to say that the entire data file need not be read into memory or otherwise copied for decryption rather only the specific block containing the file portion requested unaware and uninformed of the operation of the present mentioned need be decrypted. Going down to, and that's the disavowl line, which I mean that's part that's what precedes the language that you and the court relied on for the disavowl correct. That's correct. But that's just one embodiment. Your honor, it's described as the present invention. Let me, let me turn to the disavowl. This is not like ventana, metacool, or like go light, which in the primary case is relied on by data. This is not a case where there's general descriptions of advantages of the invention and nothing more. To the contrary, in column two of the specification, we not only have the patentee disparaging the prior art that allowed unencrypted data in the Pernel memory. We not only have, at column four in the summary of the invention, a statement that an advantage of the present invention includes the opposite feature. But that's one advantage out of eight, and this kind of harkens back to our Phillips case. We don't focus in on a single advantage is limiting the claim. That's absolutely right, and that's why the language at column 14 provides the something more that this court has required in disavowl. And that's because you're saying it's not limited because it repeatedly refers to the describing the operation of the present invention. So it's not limited to. It's a description of the present invention, but it's also use of language, all data, subject to encryption by operation of the present invention, is maintained in an encrypted state in the buffer pool. Since the assignment case, since the all embodiments language in the assignment case, this is about as close to that as it can be without actually saying all embodiments. There's not a rigid requirement that the language of the specifications say all embodiments in order to affect the disavowl. Going back to your column 14, it says the entire file need not even be read into memory. Thus it may be read in, right? The specification talks at length about decrypting data on block by block basis and the claim. To the extent you're relying on this is clear and unequivocal. It's starting to look less clear and unequivocal, isn't it? No, you're on a beat. Beginning at line 10. It's as data pending either a read or write operation to dis. Again, we're talking here about a single embodiment, but I understand that this is somewhat helpful to your argument, but it's in the context of something that may or may not be read into the memory. The statement all data is subject to operation, to encryption by operation of the present invention is maintained in encrypted state in the buffer pool refers to the present invention. And our problem is the claim just does not say if the claim did say maintain encrypted, there's no maintained word in the claim is there. There's not. The claim just says encryption routine. The claim says that the data is, that a pre-determined block of data is transferred between the kernel memory and the user memory through the encryption. Through an encryption routine, yes, we were there a minute ago. So by stating that all data is subject to encryption by operation of the present invention is maintained in a encrypted state in the buffer pool. There's no way a reasonable competitor reading that language would believe that software that does in fact maintain data, unencrypted in the buffer pool, be covered. And that is what we require that competitor to read the claim and we wouldn't find any language in the claim about maintaining encryption, would we? We would find language in the claim specifying that encryption must happen between kernel and user memory. Against somewhat unclear language, it says directing transfer through set encryption routine which may happen in the same place may not include transfer at all. Well, I believe the claim does require that there be a transfer between kernel and user memory and what this language does is it creates a structural relationship between that transfer and the encryption routine itself. The confidential markings in the briefs, those are under a protective order. There is a matter of subject to protect where? Please take more time if you need it. If you need more time, please proceed. Okay. Up until data file that's repniated in this case, the system that they accused of infringement was a system that falls squarely within the disaball of the path. It falls squarely within this statement of column 14, lines 13 through 15. It was a product that maintains data in kernel memory, unencrypted, just like the Cummings prior are. And regardless whether the claims require maintenance of data or don't require maintenance of data, this statement clearly says that if software does maintain data in an unencrypted state, it's not covered by this pattern. Am I correct that there's no prosecution history that adds any weight to your disaball? How's your meant? It's based purely on the specification. Could we give you a couple minutes to wind up here? One final point going back to Mr. Dorman's argument about the logical versus the physical. The question is not whether there's a physical or logical transfer of data. The question is what must be transferred. And again, looking at the language of the claim, the language of the claim refers to data areas and data spaces, not modes of operation. The language of the claim refers to the transfer of a predetermined block of data, not the transfer of a mode of operation. In both the specification and in the blockbook, it's made very clear that user memory addresses can still be accessed while operating in kernel mode. It doesn't alter the location of the, it doesn't change a user memory address to become a kernel memory address merely because it's being operated on by a kernel word process. So I submit to you, there are at least two independent grounds that you can affirm the court's judgment below. The court concluded there's no disputed issue of material fact that windows does not transform the data between kernel memory and user memory. Instead, it transforms the data between the disk and the memory just as the prior art did. An independent of that limitation, that affirmative limitation in the claims is the ground that in the patent specification, there was a very clear and very manifest disavowable. I think we're starting to repeat. Just one final question. I assume you have validity arguments if this should happen to go back. Is that correct? We do. But it just haven't been reached yet in the process. They were dismissed without prejudice so that the appeal could come up in the court would have jurisdiction to decide the infringement. Thank you, Ms. Uncistak. If you could give Mr. Dorman nine minutes, that would pretty close to even think about. If you need to use the Mr. Dorman. Thank you. All right. I don't think I'll need to use them. The, just a couple points. The repeated reference to the static picture in page six. You know, this picture points up the fundamental dispute, I think it's going on. Part of the problem with the briefing in this case, at least the early briefing until the reply brief. It's as if they're talking about two different things. I had that sense. And part of that was because their patent world is a static patent world of, there are bound reads and there are spaces and there's user memory. There's kernel memory and never the two show me, etc. And our understanding of this patent, reading this patent consistent with the box book and the Unic system, is that it's a dynamic system where you can have kernel memory, you can have user memory. But what's important to identify a first logical data area and a second logical data area is which instructions have control of the data in that area. In other words, when a piece of data is in the user memory, but that data is being accessed by the operating system using operating system instructions. In other words, it's being accessed in kernel mode. That's the first logical data area. It's dictated by the mode in which it's operated. That's how this patent explains. But kernel mode is not kernel memory, right? So it's in the user memory and it's operated under kernel mode. Correct. The kernel mode is not the same as kernel space. Now, where in the patent is there any, or anywhere in the record, is there anything that says a change in mode is the same as a transfer? Well, I don't think that that definition statement is not anywhere. But how do I reach that conclusion? You're telling, if I understand right, you're saying that. I am saying that. And in column 5 of the patent, if you look at line 56, what does it struggle in line 50 words? It's the main memory 16 provides an addressable memory space to the CPU 12 for the storage of application programs and data and of the operating system and the related data. It's generally depicted in the figure one. The main memory 16 is logically managed. So here we have, contrary to what Microsoft's counsel just said, that there's no discussion of mode, logical management, here it's right in the patent. It's logically managed as a combination of user space and kernel space. When the CPU 12 is executing program code in user space, the process within which such extension is occurring then exists in user mode. When the process is executing in kernel space, then execution is in kernel mode. And you are quite correct, Your Honor, that it would have been nice that then there was a further exploration of precisely that when a operating system is in kernel mode, even working on data that's in user space, that's trying to tell me what a skill in our would understand. I am talking about that's exactly what any computer scientist would understand reading this. And this is to whom this matter speaks. And that's precisely where this is. Now, the final thing you're honored that I'd like to do is. So let me just be clear on your construction of encryption routine is what? Can I do a better job with what you was with the transfer through encryption routine? Because I'm up that when I was first given a second opportunity. Well, I just like a clear proposal in terms of what the construction is. Okay, well, my definition of transfer through encryption routine is encryption of data in place and importance with a figure of 4D. I mean, that's what the patent teaches. And a logical change in access to the data from the processor in kernel mode to the processor in user mode. I mean, that's what's occurring. That's what this teaches. Where is encryption occurring under that definition? And where is the encryption occurring? The data that's being encrypted is either in user space or kernel space depending upon which particular. What we're talking about, what we're talking about, what it's about, the change mode specification or the read call. No copy of that data is made. It's written over. So what happens is whatever processing instructions are working or working on it right in place, it isn't physically taken somewhere. It's my understanding about how this works. The extent that it's processed in place. We are in the first logical data area. First lunch, because. In the kernel memory. It's in the first logical data area. It may or may not be kernel memory. It's first logical data area is determined by what modality is acting on the data. That's how I understand that this path. Thank you. Thank you, Mr. Dorman. Thank you both counsel. Tough sledding as they say