Oral argument — In Re Schweickert

Okay, the next argued case is number 16-12-66, and Re Schweickert, when you're ready, Mr. Bergstrom. May it please the court. My name is Bob Bergstrom, I'm a patent attorney in Seattle, I'm not a litigator, it's my only third time in court, so I'll do the best I can. We're here because we're appealing the decision of the appeal board at the USPTO on a patent that I did not write, but I was involved in the tail end of the prosecution, and also in the tail end of the appeal to the USPTO appeal board. I have a number of problems with this decision. The first problem is, I don't see much in the way of fact finding or evidence anywhere in this case on the part of the USPTO. The request for re-exam was made by a party that was being sued on this patent in litigation, and it's basically attorney opinion. It doesn't have any citation to authority, there's no citation to technical authority, it's just a bunch of interpretation of the claims by an attorney with an interest in defeating this patent. The USPTO examiner simply incorporated it by reference, so there's no indication in the record that it was considered or evaluated. I thought your brief did a good job, you had an interesting analogy, and you did a good job of explaining the lack of motivation combined and why somebody would use a semaphore in the primary reference. Do you want to talk about that? Sure. Okay. So, and this is part of the problem of the request for re-exam. In that request for re-exam, a semaphore was improperly defined. The attorney in that case said a semaphore has something to do with flagging whether a memory buffer is available or not, and all kinds of other things. Semaphores have nothing at all to do with that. Very simple computational technique. So a semaphore involves two variables. One tells you how many different processes can access a resource, a computational resource, at any particular point in time. And the other variable tells you how many, in fact, have access. So you keep track of how many processes are currently accessing that resource, and there's a maximum number that can. And then there's two routines. There's a down routine. So when a process wants to use a resource, it calls a down routine. Mr. Bergstrom, I'm sorry, you have very little time here with us, but let's just talk about CUNF and its usage of the semaphore. And my understanding was in CUNF, the semaphore acts like a gate to the buffer in terms of And so I guess in the PTO's view, that behaves like a lock in the sense that it locks out one of the application programs from accessing CUNF's buffer. And in the PTO's view, it would be obvious to use such a gating function in Burrell's device. And now I'd like you to just comment on any of that reasoning by the PTO. Okay, well, when I was explaining the semaphore, what I was about to get to is the fact that when a process does the down function in order to use it, the process decrements this counter and then decides if there was space for him to be working on this. If so, it just continues to process. But if there were already too many other processes accessing that resource, it goes to sleep. So it calls an operating system function that suspends it. Now in the case of a multitasking operating system as in CUNF, these processes are assumed to be interoperable. That's what a multitasking operating system does. But in Burrell, there's only one control program. If that control program goes to sleep, the device is inoperable. It doesn't work. So you would never use a semaphore in the case that there's only one process. You just don't do it. There's no advantage. So there's a lot of risks. I cited an authoritative text on operating systems that pointed out they're unpredictable, non-deterministic, they don't solve all the problems. Very difficult thing to use. But the only thing you use a semaphore is to moderate contention for a shared resource. Burrell doesn't have that problem. I saw the patent board in the rehearing decision apparently try to morph the rationale for the combination by suggesting, well, what if we modified Burrell so that there were multiple sources trying to access the RAM? And then if we had such a situation, then yes, we would want to have a type of semaphore locking system, gating system. Well, first that sort of runs contrary to Enri Roddy, which you can't modify the reference in the combination to operate differently. Changing a single process system into a multitasking operating system type system is a very difficult problem. And if you were to successfully do it, you would have already incorporated semaphores. You have to use them in those cases. So that doesn't make any sense to me at all. In the patent, as I understand it, your client's patent, it says that having this locking and unlocking of the various parts of the memory concerns battery. How does that work? I didn't understand how that would actually concern battery. Well, so the most power consuming portion of this little media player is operating the disk. So what they want to do is only operate it very infrequently, only enough to bring the play mechanism go ahead and play that data over time. So what they've done is they've divided RAM into a bunch of really small buffers and they only lock one of them. And the reason they have to lock it is because there's an independent operating component called the codec that reads from RAM and translates that into an audio signal, which is broadcast to the listener. So by only having 1 16th of the RAM as one example, then they can wait for a real long time before they start the disk again and fill up those other 15 buffers. It's a lot faster to read from disk than play the audio data that's stored in memory. And your claims, now they're broader than 1 16th, they just say at least two, right? Well, we're saying that there's, I think it says that there's more than two, but independently lockable buffers in memory. Do you have a copy of your patent, the 272 patent with you? I do. This doesn't relate to the rejection at hand, but I did have a question about column 10. There's a, there's a paragraph in column 10 starting at line 42 and ends at line 56. And this is where you're talking about the advantage of locking up 1 16th of 16 buffers and then that out conserves power. And then there's a sentence that says such operation is in sharp contrast to a typical buffering operation in which a buffer is allocated into two portions with only one half of the buffer space available for read write operations, while the other half of the buffer space is locked for data transfer operations to the codec. And so am I right to read this sentence as stating that it was already known in the art to have two buffer areas and lock one of the buffer areas while there's content in there that's going to be accessed by the codec and then the other buffer area to be unlocked? Yes. Okay. And so when we look at your claims, as I understand it, this sentence basically acknowledges that everything in the claim was already old except for the fact that your claim, instead of talking about two buffer, lockable buffer areas, the claim says more than, more than two. Right. So. And they're all independently lockable. So the, so the obviousness question then boils down to whether it be obvious to have more than two lockable buffer areas when we already know in the art that you can do it with two lockable buffer areas. Yes. However, that isn't really part of the appeal board decision. I mean. Right. No, I'm just trying to understand. Yeah. If I understand this passage correctly. Yes. Okay. And again, the advantage is by having a whole bunch of smaller buffers, there's several advantages that are mentioned in here, but one is by having very small buffers and only locking one, you have a lot more RAM that you can read in from the disk so that you don't have to operate the disk nearly as often. So it saves quite a bit of power to do this. Another advantage is, as I mentioned later in this patent, you can dynamically allocate these buffers. So depending on the characteristics of the codec and everything else, you can divide the buffers into appropriate sizes that allow you to maximize the amount of time that that disk was turned off. So it's not just, you know, two versus 16. It's a huge power saving and it also has a flexibility so that you can tailor the way you manage memory to the actual devices. Right. The claims don't say 16 buffer areas, right? They don't say more than two. The claim covers three buffer areas. Well, it says more than two. So that's three. Or 16 or 32. Or 89, but it includes three. Okay. Okay, let's hear from the other side and we'll save you rebuttal time. Okay. Thank you. Mr. Resiller. Thank you. May it please the Court. I think before addressing the arguments made by counsel, I think it's important to note here that the 272 patent under reexamination, as Judge Chen mentioned in this case, broadly claims a portable media player that's comprised of elements that were well known at the time of the application. This appeal focuses on the memory and buffer components which the claims broadly just require to be lockable and unlockable by the processor. Neither the claims nor the specification of the 272 further describe or limit how the memory buffers can be locked and unlocked by the system. In fact, the paragraph that Judge Chen was just looking at in column 10 simply notes that the locked buffer is unavailable for other read-write operations when it's transferring data to the codec. In this case, the board and the examiner looked to both Burrell and Cunniff. The board found that Burrell had all the elements of the claims except for the locked and unlockable memory buffers. They looked to Cunniff to find that. In this case, the board and counsel for Schweikert himself, they all agree that a semaphore is a type of lock. The definition of semaphore is simply a signal or a type of flag variable. What though is the basis for putting a lock in Burrell when there's a single CPU that's accessing? What is the basis for using a lock or a semaphore or whatever it is that Cunniff teaches even if it's broad enough to cover what's in the patent suit? The board addressed this and said that we're not just looking at Burrell alone. It's the combination of what the prior art as a whole teaches. You're saying you're going beyond Burrell and Cunniff? No, we're saying that the combination of Burrell and Cunniff together. So when combined, the system of Burrell then can allow the use of asynchronous application programs, multiple entities. So you want to combine Burrell with Cunniff to create the problem that the patent suit solves? No, I don't think that that's the proper way of phrasing that. I think that what Cunniff teaches is, what Burrell teaches is that there is some type of logic that needs to be in place that when the threshold value is hit in Burrell, some portion of the memory is protected from being overwritten. So therefore, there is some logic that effectively locks those sections of Burrell, the RAM in Burrell, to prevent the overwriting. Now, one way of doing that... That's not exactly how I read Burrell. The way I read Burrell was there's this play control logic. And the play control logic is timed so that it is designed to replenish or add new data to the RAM just in time as the prior packet of data in the RAM is getting played out by the codec. So, it's not a question of trying to lock up the RAM to avoid accidental overwriting of data you still want and need. It's more a question of figuring out the timing so that the new cache of data will get there just in time. That's the way I understood Burrell. And just so I understand the combination. Is it your understanding that the board's combination rests on replacing the play control logic with the Cunniff semaphore? Or is it just adding the semaphore to Burrell's system, which already includes and still has the play control logic? Which one is it? I think it can be either. Which one is it? So, I think that the way that the board looked at it, I think it was saying that it was a substitution of a known element using a known method, in this case the semaphore, in order to get to a predictable result, which is preventing the unwanted overwriting of data. So, it's your understanding that the play control logic goes away and then we stick in Cunniff semaphore? That's correct. Okay. But if you do that, why doesn't that entirely defeat the purpose of Burrell? Which is to have this play control logic so that the system will know when is the right time to pump in more data into the RAM, more compressed data into the RAM. Well, the logic that it's getting rid of in Burrell is the logic that just prevents the overwriting. So, this goes back to your first question, which was about the timing of Burrell. And it's a question of timing as to when to replenish the data. That's correct. That's what Burrell does. But Burrell also has to prevent overwriting of all the RAM. It's not just a question of the timing of the replenishing of the data. There also has to be some segmentation where certain parts of that data are not overwritten to allow, for example, the rewinding. Why isn't that one and the same? In the sense that the timing is all about trying to figure out when the data that's in the RAM has been exhausted and now you're going to put in new data. By using that timing sequence, you're necessarily not overwriting data because you're trying to figure out when that data has been exhausted already. Well, I think once you've figured out that it's been exhausted, you could still have the system overwrite that data. But what Burrell teaches is that in order to provide somebody the ability to rewind, then you do not want to overwrite a certain period, a certain portion of that data. Now, it doesn't tell you how it does that. It just says that the data is not overwritten. So one of ordinary skill in the art could look at that and see that there are many different ways of doing that. To your second question, then the importing or the substitution of the semaphore locking capability from CUNIF could be used because all that does is it allows that system, allows Burrell to utilize asynchronous application programs or have multiple entities access the audio RAM sections, the RAM sections where the audio data is stored, and you get the advantages along with that. You get the real-time access. You get the ability to allow Burrell to do more things, to be more efficient, to allow the different types of the control procedures and mechanisms to access, to be run asynchronously. And you can still have a single CPU and do that. You can have a single thread or multiple threads of the single CPU to run asynchronously, which is what CUNIF is directed to. Another concern is I don't see how the combination leads to having more than two RAM buffers or even more than one RAM buffer. CUNIF, I see one RAM. In Burrell, I see one RAM. So I guess I don't see either of them talking about the idea of let's carve up the RAM buffer and subdivide it into multiple little buffer areas that can then be each individually lockable and unlockable. I think both Burrell and CUNIF both teach segmented RAM buffers. Where is that? So in Burrell, if you look at figures 2, it's 2A, 2B, 2C, 2D. It teaches that in the RAM, particularly looking at figure 2C, within the RAM you've got play state information. You've got playlist information. You've got table of contents information. And then you also have the audio data. Each one of those little boxes is a segmented part of the RAM. So Burrell does contemplate and teach RAM buffers that are separate and that are treated separately. And then layered on top of this, some portion of that audio data in block 192 and figure 2C is being prevented from being overwritten when the rewind capability. The first few lines or areas of the RAM, you don't need to sometimes lock them, sometimes unlock them. Those are just areas where you're not going to be pumping in new compressed data. That's not true because as you get more information, more songs in there, you're going to change the table of contents information that are in there. Those things are being changed. As you download additional data and get new songs and new audio files introduced into the RAM, you're also going to be introducing the table of content information about them. That's like the title information and things about the song itself that help to break the song into various attributes. Is there anything in the patent that talks about breaking up the end minutes of audio data? If you look at Column 6, Appendix 808, that's where it talks about that the play control logic will not completely overwrite the data in RAM with data from Disk 104 once the threshold is reached. Instead, the final portion of the previously played data will be retained in the case if the user wishes to reverse direction of play. So you're saying in Burrell, for the combination, you would yank that piece out of Burrell and then you would put in the semaphore of CUNF? No, we're not yanking. Oh, I'm sorry. The play control logic that's referred to in Column 6. So basically what you'd be doing to Burrell is taking the semaphore locking capability of CUNF and using that as the play control logic, which can prevent the overwriting of that section of audio data to allow the rewind. To the second question about where the RAM is segmented in CUNF, what CUNF does teach is that the memory buffer that's used in the semaphore mechanism is segmented into four different buffers. And that's in Figure 4 at Appendix Page 816. And there it shows that it's broken into the command buffer, the attribute buffer, the send buffer, and the receive buffer. What do you make of Column 10 of the 272 patent, which talks about how it was segmented into four different buffer areas? I think that further supports the board and the examiner's obviousness rejection in this case. I think not only do all the parties agree that a semaphore can be considered a lock, the patent itself recognizes that locking was known in the art for at least locking one of two memory buffers. Neither the board or the examiner pointed to this portion of 272, right? That's correct. So they did not rely on this at all, right? No, they did not rely on the admission. So we shouldn't read their opinion as relying on it. We shouldn't rely on whatever this admission is. We shouldn't rely on it when we're reviewing the decision below, right? I mean, I still think it is in the record and it helps support the substantial evidence that the board and the examiner pointed to, but I don't think because they didn't actually cite to it, I don't think that you would be relying on it in this case. I wanted to address some of the arguments made by counsel in his opening. He did state that or stated that the examiner did not make any findings that the examiner merely just adopted those findings in the request for reexamination. That's not true. The examiner did go through and make independent findings in the final rejection. That's at pages, the appendix 531 through 537. He walks through and finds each of the elements in the prior art that are in claim one and then goes on and talks about the motivation to combine. Now with the motivation to combine, he does incorporate the reasons that were stated in the request for reexamination. And so to the extent he's talking about incorporation, that is what the examiner was incorporating. He was incorporating the reasons that support the motivation to combine with Burrell in this case. I believe that the board, because the board and the examiner did find and point to substantial evidence on the record to support the obviousness rejection in this case that this court should affirm. If there are any other questions, I see my time is running out. Any more questions for Mr. Russella? Thank you. Thank you, Mr. Russella. Mr. Bergstrom? Well, I don't understand a lot of what the opposing counsel said. Burrell does not use locks and it was admitted by the appeal board that it doesn't. It doesn't need locks. You were right, Judge Chandler. It treats that as a circular buffer, calculates in advance how much data to put in that buffer. It knows what the limits are and it instructs the disc exactly what data to put in there. There's no reason for a lock. Locks are only used when you have multiple processes contending for a resource and Burrell doesn't have one. You're saying at least on the two references we have before us and on the record that we have before us, that's the only use of locks? Well, I'm saying in general in computer science. You don't use a semaphore for a single process. It doesn't work. If that ever goes to sleep, the system's dead. There's nobody left to wake it up. That's how a semaphore operates. I guess the PTO is saying that, well, let's not worry about that. We could substitute the plate control logic. The plate control logic in a sense behaves in a way that prevents the system from overriding accidentally or overriding data you don't want overwritten. And so we can switch that feature out that's already in Burrell with something like the semaphore and kind of that could likewise lock data that you don't want overwritten. It doesn't make sense to me. Is it like you think it's hindsight that they're relying on your patent application to come up with that combination? It's not hindsight. If I was managing a development group and a software engineer put a single process system, I'd fire him. It doesn't work. It's dangerous. It doesn't provide any advantage. The only thing a semaphore does is manage contention for a resource by processes. If you replace the plate logic with a semaphore, that system wouldn't do anything. The semaphore doesn't know anything about reading from RAM, audio conversion, anything like that. All it does is keep track of how many processes are currently accessing a resource. That's it. And when there's too many that try to access it, it puts one to sleep. And if there's only one process and it's put to sleep, that system will never recover because there's no other process to wake it up. So that doesn't make sense. As far as these segmented memory buffers, well, that's just tables showing data. That has nothing to do with locking RAM or continuous feeding of data from the disk to memory. All data is segmented. I mean, that has nothing to do with dividing a memory buffer up into separately lockable portions, as we're teaching in GIT. There's just so many things. It's hard to... The other thing that I want to mention about CUNAF is that CUNAF explicitly states throughout the patent application that it is a hardware resource controller designed to run on top of a multitasking operating system. And it states throughout CUNAF that that hardware resource controller is only designed to mitigate contention for a shared resource by multiple application programs. There are no application programs on these little player devices. None whatsoever. There's no multitasking operating system. Why do you need a multitasking operating system? Well, you need to be sure that anything that you're going to use on a semaphore can be interrupted, stop, be suspended, and then at a later time continue. That's not the case with the media player. If these things are not continuously running, the music stops. So CUNAF is really not analogous art at all. The other thing to note about CUNAF is that the hardware resource that's being controlled is an audio card. And all it does is take little tiny audio files to generate things like beeps and hums and whatever for application programs. It's not playing music. And what is being protected by the semaphore in CUNAF is a very tiny little buffer. It's a command buffer. So the application program puts a command in. It needs to use a semaphore to make sure another application isn't overriding that command. And as soon as it's done, then the hardware resource controller goes ahead and does all the operations with the audio card. It's not the same type of system at all. Okay. I have just one point I want to make, which is that I thought your blue brief was very good at explaining your position and your arguments, your technical positions. I wanted to, based on your invitation that this is the first time that you've been a litigator, I wanted to just point out that I thought that I didn't find some of the rhetoric in your reply brief very helpful. And I would recommend that you not write that way, particularly in this court. I'll give you an example, something about how if we affirm, then the PTO might as well rely on palmistry and astronomy and astrology. These kinds of things aren't as helpful. But I do want to say that I thought your analogy was great in your blue brief, and so really just sticking to the facts would be very helpful for you. And for everybody. Thank you. Thank you. Thank you. Thank you. Thank you. Thank you. Thank you. Thank you. Thank you.