[00:00:09] Speaker ?:
cough cough

[00:00:40] Speaker 03:
OK, the next argued case is number 16, 1266, in Ray Schweikert.

[00:00:46] Speaker 03:
When you're ready, Mr. Bergstrom.

[00:00:51] Speaker 01:
May it please the court?

[00:00:55] Speaker 01:
My name is Bob Bergstrom.

[00:00:56] Speaker 01:
I'm a patent attorney in Seattle.

[00:00:57] Speaker 01:
I'm not a litigator.

[00:00:58] Speaker 01:
It's my only third time in court.

[00:01:01] Speaker 01:
So I'll do the best I can.

[00:01:06] Speaker 01:
We're here because.

[00:01:09] Speaker 01:
were 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 prosecution and also in the tail end of the appeal to the USPTO appeal board.

[00:01:23] Speaker 01:
I have a number of problems with this decision.

[00:01:26] Speaker 01:
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.

[00:01:35] Speaker 01:
The request to re-examine

[00:01:39] Speaker 01:
was made by a party that was being sued on this patent in litigation.

[00:01:48] Speaker 01:
And it's basically attorney opinion.

[00:01:52] Speaker 01:
It doesn't have any citation to authority.

[00:01:54] Speaker 01:
There's no citation to technical authority.

[00:01:57] Speaker 01:
It's just a bunch of interpretation of the claims by an attorney with an interest in defeating this patent.

[00:02:07] Speaker 01:
The USPTO examiner simply incorporated it by reference.

[00:02:11] Speaker 01:
So there's no indication on the record that it was considered or evaluated.

[00:02:17] Speaker 04:
I thought your brief did a good job.

[00:02:21] Speaker 04:
You had an interesting analogy.

[00:02:23] Speaker 04:
And you did a good job explaining the lack of motivation combined and why somebody would use a semaphore in the primary reference.

[00:02:31] Speaker 04:
Do you want to talk about that?

[00:02:32] Speaker 01:
Sure.

[00:02:35] Speaker ?:
OK.

[00:02:35] Speaker 01:
And this is part of the problem with the request for re-exam.

[00:02:40] Speaker 01:
In that request for re-exam, a semaphore was improperly defined.

[00:02:46] Speaker 01:
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.

[00:02:56] Speaker 01:
Semaphores have nothing at all to do with that.

[00:02:58] Speaker 01:
It's a very simple computational technique.

[00:03:01] Speaker 01:
So a semaphore involves two variables.

[00:03:05] Speaker 01:
tells you how many different processes can access a resource, a computational resource at any particular point in time.

[00:03:14] Speaker 01:
And the other variable tells you how many in fact have access.

[00:03:21] Speaker 01:
So you keep track of how many processes are currently accessing that resource.

[00:03:26] Speaker 01:
And there's a maximum number that can.

[00:03:29] Speaker 01:
And then there's two routines.

[00:03:31] Speaker 01:
There's a down routine.

[00:03:33] Speaker 01:
So when a process wants to use a resource, it calls a down routine.

[00:03:37] Speaker 02:
Mr. Bergstrom, I am sorry.

[00:03:39] Speaker 02:
You have very little time here with us, but let's just talk about CUNNF and its usage of the semaphore.

[00:03:45] Speaker 02:
And my understanding was in CUNNF, the semaphore acts like a gate to the buffer in terms of different application programs trying to access CUNNF's buffer.

[00:03:58] Speaker 02:
Exactly.

[00:04:00] Speaker 02:
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 kind of buffer.

[00:04:12] Speaker 02:
And in the PTO's view, it would be obvious to use such a gating function in Burrell's device.

[00:04:22] Speaker 02:
And now I'd like you to just comment on any of that reasoning by the PTO.

[00:04:27] Speaker 01:
OK, well, when I was explaining the semaphore,

[00:04:30] Speaker 01:
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.

[00:04:47] Speaker 01:
If so, it just continues to process.

[00:04:50] Speaker 01:
But if there were already too many other processes accessing that resource, it goes to sleep.

[00:04:58] Speaker 01:
So it calls an operating system function that suspends it.

[00:05:02] Speaker 01:
Now, in the case of a multitasking operating system as in Kanoff, these processes are assumed to be interruptible.

[00:05:12] Speaker 01:
That's what a multitasking operating system does.

[00:05:15] Speaker 01:
But in Burl, there's only one control program.

[00:05:18] Speaker 01:
If that control program goes asleep, the device isn't operable.

[00:05:22] Speaker 01:
It doesn't work.

[00:05:25] Speaker 01:
So you would never use a semaphore

[00:05:27] Speaker 01:
in the case that there's only one process.

[00:05:30] Speaker 01:
You just don't do it.

[00:05:31] Speaker 01:
There's no advantage.

[00:05:34] Speaker 01:
So there's a lot of risks.

[00:05:38] Speaker 01:
I cited an authoritative text on operating systems that pointed out they're unpredictable, non-deterministic, they don't solve all the problems.

[00:05:52] Speaker 01:
Very difficult thing to use.

[00:05:54] Speaker 01:
But the only thing you use this MFOR is to

[00:05:58] Speaker 01:
moderate contention for a shared resource.

[00:06:01] Speaker 01:
Burl doesn't have that problem.

[00:06:04] Speaker 02:
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 Burl so that there were multiple sources trying to access the RAM?

[00:06:22] Speaker 02:
And then if we had such a situation, then yes, we would

[00:06:28] Speaker 02:
want to have a type of semaphore locking system, gating system?

[00:06:33] Speaker 01:
Well, first of all, it sort of runs contrary to NRI-RADI, which you can't modify the reference imagination to operate differently.

[00:06:41] Speaker 01:
Changing a single process system into a multitasking operating system type system is a very difficult problem.

[00:06:48] Speaker 01:
And if you were to successfully do it, you would have already incorporated semaphores.

[00:06:52] Speaker 01:
You have to use them in those cases.

[00:06:55] Speaker 01:
So that doesn't make any sense to me at all.

[00:06:58] Speaker 04:
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.

[00:07:10] Speaker 01:
How does that work?

[00:07:11] Speaker 01:
I didn't understand how that would actually concern battery.

[00:07:13] Speaker 01:
The most power-consuming portion of this little media player is operating the disk.

[00:07:19] Speaker 01:
So what they want to do is only operate it very infrequently, only enough to bring the data in and then stop it.

[00:07:25] Speaker 01:
and let the play mechanism go ahead and play that data over time.

[00:07:29] Speaker 01:
So what they've done is they've divided RAM into a bunch of really small buffers, and they only lock one of them.

[00:07:37] Speaker 01:
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.

[00:07:50] Speaker 01:
So by only having 1 16th of the RAM,

[00:07:54] Speaker 01:
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.

[00:08:02] Speaker 01:
It's a lot faster to read from disk than play the audio data that's stored in memory.

[00:08:09] Speaker 04:
And your claims, now they're broader than 1 16th.

[00:08:12] Speaker 04:
You just say at least two, right?

[00:08:15] Speaker 01:
Well, we're saying that there's, I think it says that there's more than two independently lockable buffers in memory.

[00:08:22] Speaker 02:
Do you have a copy of your patent, the 272 patent, with you?

[00:08:28] Speaker 01:
I do.

[00:08:32] Speaker 02:
This doesn't relate to the rejection at hand, but I did have a question about column 10.

[00:08:44] Speaker 02:
There's a paragraph in column 10 starting at line 42 and ends at line 56.

[00:08:51] Speaker 02:
And this is where you're talking about the advantage of locking up 1 16th of 16 buffers and then that out conserves power.

[00:09:03] Speaker 02:
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

[00:09:20] Speaker 02:
for data transfer operations to the codec.

[00:09:24] Speaker 02:
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?

[00:09:46] Speaker 02:
Yes.

[00:09:47] Speaker 02:
OK.

[00:09:48] Speaker 02:
And so when we look at your claims,

[00:09:52] Speaker 02:
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 two.

[00:10:08] Speaker 02:
Right.

[00:10:10] Speaker 02:
And they're all independently locked.

[00:10:13] Speaker 02:
So the obviousness question then boils down to whether it be obvious to have more than two

[00:10:20] Speaker 02:
lockable buffer areas when we already know in the art that you can do it with two lockable buffer areas.

[00:10:27] Speaker 01:
Yes.

[00:10:28] Speaker 01:
However, that isn't really part of the appeal board decision.

[00:10:33] Speaker 02:
Right.

[00:10:34] Speaker 02:
No, I'm just trying to understand if I understand this passage correctly.

[00:10:38] Speaker 01:
Yes.

[00:10:39] Speaker 02:
Okay.

[00:10:43] Speaker 01:
And again, the advantage is

[00:10:45] Speaker 01:
By having a whole bunch of smaller buffers, there's several advantages that are mentioned in here.

[00:10:51] Speaker 01:
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.

[00:11:02] Speaker 01:
So it saves quite a bit of power to do this.

[00:11:06] Speaker 01:
Another advantage is, as I mentioned later in this patent,

[00:11:10] Speaker 01:
you can dynamically allocate these buffers.

[00:11:13] Speaker 01:
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.

[00:11:28] Speaker 01:
So it's not just 2 versus 16.

[00:11:32] Speaker 01:
It's a huge power saving, and it also has a flexibility so that you can tailor the way you manage memory.

[00:11:38] Speaker 01:
to the actual devices.

[00:11:40] Speaker 02:
The claims don't say 16 buffer areas, right?

[00:11:42] Speaker 02:
They don't say more than two.

[00:11:43] Speaker 02:
The claim covers three buffer areas.

[00:11:47] Speaker 02:
Well, it says more than two.

[00:11:48] Speaker 02:
So that's three.

[00:11:50] Speaker 02:
Or 16, or 32.

[00:11:52] Speaker 02:
Or 89, but it includes three.

[00:11:56] Speaker 03:
OK.

[00:11:59] Speaker 03:
OK, let's hear from the other side, and we'll save you rebuttal time.

[00:12:11] Speaker 00:
I think before addressing the argument made by counsel, I think it's important to note here that the 272 patent under re-examination, as Judge Chen mentioned this case, broadly claims a portable media player that's comprised of elements that were well known at the time of the application.

[00:12:33] Speaker 00:
This appeal focuses on the memory and buffer components which the claims broadly just require to be lockable and unlockable by the processor.

[00:12:42] Speaker 00:
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.

[00:12:50] Speaker 00:
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

[00:13:02] Speaker 00:
when it's transferring data to the codec.

[00:13:06] Speaker 00:
In this case, the board and the examiner looked to both Borel and CUNNF.

[00:13:13] Speaker 00:
The board found that Borel had all the elements of the claims except for the locked and unlockable memory buffers.

[00:13:20] Speaker 00:
They looked to CUNNF to find that.

[00:13:23] Speaker 00:
And in this case, the board and Councilor Schweikart himself

[00:13:30] Speaker 00:
They all agree that a semaphore is a type of lock.

[00:13:33] Speaker 00:
And the definition of semaphore is simply a signal, a flag, or a type of flag variable.

[00:13:39] Speaker 04:
What, though, is the basis for putting a lock and barrel when there's a single CPU that's accessing?

[00:13:48] Speaker 04:
What is the basis for using a lock or a semaphore, whatever it is that kind of teaches, even if it's broad enough to cover what's in the patent and suit?

[00:13:57] Speaker 00:
The board addressed this and said that we're not, we have to remember that we're not just looking at Burrell alone.

[00:14:04] Speaker 00:
It's the combination of what the prior art as a whole teaches.

[00:14:07] Speaker 04:
And in this case... You mean you're saying you're going beyond Burrell and CUNNF?

[00:14:11] Speaker 00:
No, no, no.

[00:14:11] Speaker 00:
We're saying that the combination of Burrell and CUNNF together.

[00:14:15] Speaker 00:
So when combined, the system of Burrell then can

[00:14:20] Speaker 00:
allow the use of asynchronous application programs, multiple entities.

[00:14:24] Speaker 04:
So you want to combine Borel with Conif to create the problem that the patent and suit solves?

[00:14:30] Speaker 00:
No.

[00:14:30] Speaker 00:
I don't think that that's the proper way of phrasing that.

[00:14:35] Speaker 00:
I think that what Conif teaches is that there is some type of logic that needs to be in place that when the threshold value is hit in Borel,

[00:14:47] Speaker 00:
some portion of the memory is protected from being overwritten.

[00:14:51] Speaker 00:
So therefore, there is some logic that effectively locks those sections of the RAM and Borel to prevent the overwriting.

[00:15:02] Speaker 02:
Now, one way of doing that... That's not exactly how I read Borel.

[00:15:08] Speaker 02:
The way I read Borel was there's this play control logic.

[00:15:12] Speaker 02:
And the play control logic is timed so that it is

[00:15:18] Speaker 02:
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.

[00:15:31] Speaker 02:
So it's not a question of trying to lock up the RAM to avoid accidental overwriting of data you still want and need.

[00:15:43] Speaker 02:
It's more a question of figuring out the timing so that

[00:15:47] Speaker 02:
the new cache of data will get there just in time.

[00:15:51] Speaker 02:
That's the way I understood Burrell.

[00:15:53] Speaker 02:
Well, that's definitely one of the advantages to Burrell.

[00:15:57] Speaker 02:
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 kind of semaphore?

[00:16:10] Speaker 02:
Or is it just adding the semaphore to Burrell's system, which

[00:16:17] Speaker 02:
already includes and still has the play-control logic.

[00:16:20] Speaker 02:
Which one is it?

[00:16:22] Speaker 00:
I think it can be either, but going back to your first... I see problems with both, but which one is it?

[00:16:29] Speaker 00:
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 with

[00:16:44] Speaker 00:
using a known method, in this case a semaphore, in order to get to a predictable result, which is preventing the unwanted overriding of data.

[00:16:51] Speaker 02:
Okay, so you're understanding that the play-control logic goes away and then we stick in kind of semaphore.

[00:16:58] Speaker 02:
That's correct.

[00:16:59] Speaker 02:
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

[00:17:12] Speaker 02:
to pump in more data into the RAM, more compressed data into the RAM?

[00:17:17] Speaker 00:
Well, the logic that it's getting rid of in Borel is the logic that just prevents the overwriting.

[00:17:26] Speaker 00:
So this goes back to your first question, which was about the timing of Borel.

[00:17:32] Speaker 00:
And it's a question of timing as to when to replenish the data.

[00:17:35] Speaker 00:
That's correct.

[00:17:36] Speaker 00:
That's what Borel does.

[00:17:37] Speaker 00:
But Borel also has to prevent

[00:17:40] Speaker 00:
overriding of all the RAMs.

[00:17:42] Speaker 00:
It's not just a question of the timing of the replenishing of the data.

[00:17:48] Speaker 00:
There also has to be some segmentation where certain parts of that data are not overwritten to allow, for example, the rewinding.

[00:17:56] Speaker 02:
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?

[00:18:10] Speaker 02:
By using that timing sequence, you're necessarily not overwriting data, because you're trying to figure out when that data's been exhausted already.

[00:18:25] Speaker 00:
Well, I think once you've figured out that it's been exhausted, you could still have the system overwrite that data.

[00:18:34] Speaker 00:
But what Borel teaches is that in order to provide somebody the ability to rewind,

[00:18:41] Speaker 00:
then you do not want to overwrite a certain period, a certain portion of that data.

[00:18:47] Speaker 00:
Now, it doesn't tell you how it does that.

[00:18:49] Speaker 00:
It just says that the data is not overwritten.

[00:18:51] Speaker 00:
So one of ordinary skill in the art could look at that and see that there are many different ways of doing that.

[00:18:58] Speaker 00:
And so to your second question, then the importing or the substitution of the semaphore locking capability from Conif could be used because

[00:19:10] Speaker 00:
All that does is it allows that system, it allows Borel 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.

[00:19:35] Speaker 00:
You get the real-time access.

[00:19:40] Speaker 00:
the ability to allow Borel to do more things, to be more efficient, to allow the different types of the control procedures and mechanisms to be run asynchronously.

[00:19:55] Speaker 00:
And you can still have a single CPU and do that.

[00:19:57] Speaker 00:
You can have a single thread or multiple threads of the single CPU to run asynchronously, which is what is directed to.

[00:20:05] Speaker 02:
Another concern is I don't see how the combination leads to having

[00:20:10] Speaker 02:
more than two RAM buffers or even more than one RAM buffer.

[00:20:16] Speaker 02:
CUNNF, I see one RAM.

[00:20:20] Speaker 02:
In URAL, I see one RAM.

[00:20:22] Speaker 02:
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.

[00:20:38] Speaker 00:
I think both Borel and CUNNF both teach segmented RAM buffers.

[00:20:45] Speaker 00:
So in Borel, if you look at figures 2, it's 2A, 2B, 2C, 2D, it teaches that

[00:21:06] Speaker 00:
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.

[00:21:19] Speaker 00:
Each one of those little boxes is a segmented part of the RAM.

[00:21:23] Speaker 00:
So Borel does contemplate and teach RAM buffers that are separate and that are treated separately.

[00:21:31] Speaker 00:
And then layered on top of this, some portion of that audio data in block 192 in figure 2C is being prevented from being overwritten when the threshold level is being met to allow the rewind capability.

[00:21:43] Speaker 02:
The first few lines or areas of the RAM, you don't need to sometimes lock them, sometimes unlock them.

[00:21:57] Speaker 02:
Those are just areas where you're not going to be

[00:22:00] Speaker 02:
pumping in new compressed data.

[00:22:02] Speaker 00:
Well, that's not true, because as you change, as you get more information, more songs in there, you're going to change the table of content information that are in there.

[00:22:10] Speaker 00:
So those things are being changed.

[00:22:12] Speaker 00:
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.

[00:22:23] Speaker 00:
That's like the title information and things about the song itself that help to break the song.

[00:22:29] Speaker 00:
into various attributes.

[00:22:33] Speaker 04:
Is there anything in the patent that talks about breaking up the end minutes of audio data marked as delineated as 192?

[00:22:41] Speaker 00:
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.

[00:22:58] Speaker 00:
Instead, the final portion of the previously played data will be retained in the case if the user wishes to reverse direction of play.

[00:23:07] Speaker 02:
So you're saying in burl, for the combination, you would yank that piece out of burl, and then you would put in the semaphore of kind of.

[00:23:19] Speaker 00:
No, we're not yanking.

[00:23:20] Speaker 00:
Oh, I'm sorry.

[00:23:22] Speaker 00:
The play control logic that's referred to in column six.

[00:23:26] Speaker 00:
Basically, what you'd be doing to Burrell is taking the semaphore locking capability of CUNNF and using that as the play control logic, which can prevent the overwriting of that section of audio data to allow the rewind.

[00:23:46] Speaker 00:
And then to the second question about where the RAM is segmented in CUNNF, the shared

[00:23:54] Speaker 00:
What kind of does teach is that the memory buffer that's used in the semaphore mechanism is segmented into four different buffers.

[00:24:05] Speaker 00:
And that's in figure four at appendix page 816.

[00:24:11] Speaker 00:
And there it shows that it's broken into the command buffer, the attribute buffer, the send buffer, and the receive buffer.

[00:24:19] Speaker 02:
What do you make of column 10?

[00:24:23] Speaker 02:
the 272 patent, which talks about how it was already known to have two lockable, unlockable buffer areas.

[00:24:34] Speaker 00:
I think that further supports the board and the examiners' obviousness rejection in this case.

[00:24:40] Speaker 00:
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

[00:24:52] Speaker 00:
locking one of two memory buffers.

[00:24:55] Speaker 00:
Neither the board or the examiner pointed to this portion of 272, right?

[00:25:02] Speaker 00:
That's correct.

[00:25:03] Speaker 04:
So they did not rely on this at all, right?

[00:25:05] Speaker 00:
No, they did not rely on the admission.

[00:25:07] Speaker 04:
So we shouldn't read their opinion as relying on it.

[00:25:09] Speaker 04:
We shouldn't rely on whatever this admission is.

[00:25:12] Speaker 04:
We shouldn't rely on it when we're reviewing the decision below, right?

[00:25:15] Speaker 00:
I mean, I still think it is in the record.

[00:25:25] Speaker 00:
It helps support the substantial evidence that the board and the examiner pointed to.

[00:25:33] Speaker 00:
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.

[00:25:47] Speaker 00:
I wanted to address some of the arguments made by counsel in his opening.

[00:25:53] Speaker 00:
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.

[00:26:05] Speaker 00:
That's not true.

[00:26:06] Speaker 00:
The examiner did go through and make independent findings in the final rejection.

[00:26:10] Speaker 00:
That's at pages the appendix 531 through 537.

[00:26:14] Speaker 00:
He walks through and finds each of the elements in the prior art that are in claim one.

[00:26:23] Speaker 00:
and then goes on and talks about the motivation to combine.

[00:26:27] Speaker 00:
Now, with the motivation to combine, he does incorporate the reasons that were stated in the request for re-examination.

[00:26:33] Speaker 00:
And so to the extent he's talking about incorporation, that is what the examiner was incorporating.

[00:26:38] Speaker 00:
He was incorporating the reasons that support the motivation to combine CUNNF with BREL in this case.

[00:26:51] Speaker 00:
I believe that because the board and examiner did find and point to substantial evidence on the record to support the obviousness rejection in this case that this court should affirm.

[00:27:02] Speaker 00:
And if there are any other questions, I see my time is running out.

[00:27:04] Speaker 03:
Any more questions for Mr. Rossella?

[00:27:05] Speaker 03:
Thank you.

[00:27:07] Speaker 03:
Thank you, Mr. Rossella.

[00:27:10] Speaker 03:
Mr. Bergstrom.

[00:27:15] Speaker 01:
Well, I don't understand a lot of what

[00:27:19] Speaker 01:
The opposing counsel said, BRIL does not use locks, and it was admitted by the appeal board that it doesn't.

[00:27:24] Speaker 01:
It doesn't need locks.

[00:27:26] Speaker 01:
You were right, Judge Chen.

[00:27:27] Speaker 01:
It treats that as a circular buffer, calculates in advance how much data to put into that buffer, it knows what the limits are, and it instructs the disk exactly what to put in there.

[00:27:38] Speaker 01:
There's no reason for a lock.

[00:27:40] Speaker 01:
Locks are only used when you have multiple processes contending for a resource, and BRIL doesn't have one.

[00:27:46] Speaker 04:
You're saying, at least on the two references we have before us,

[00:27:49] Speaker 04:
and on the record that we have before us, that's the only use of locks.

[00:27:53] Speaker 01:
Well, I'm saying in general in computer science.

[00:27:55] Speaker 01:
You don't use a semaphore for a single process.

[00:28:00] Speaker 01:
It doesn't work.

[00:28:01] Speaker 01:
If that ever goes to sleep, the system's dead.

[00:28:05] Speaker 01:
There's nobody left to wake it up.

[00:28:08] Speaker 01:
That's how a semaphore operates.

[00:28:10] Speaker 02:
I guess the PTO is saying that, well,

[00:28:14] Speaker 02:
Let's not worry about, we could substitute the play control logic.

[00:28:17] Speaker 02:
The play control logic, in a sense, behaves in a way that prevents the system from overriding accidentally, or overriding data you don't want overridden.

[00:28:32] Speaker 02:
And so we can switch that feature out that's already in Borel with something like the semaphore and CUNNF that could likewise block

[00:28:44] Speaker 02:
data that you don't want overwritten?

[00:28:47] Speaker 02:
It doesn't make sense to me.

[00:28:49] Speaker 04:
Do you think it's hindsight that they're relying on your patent application to come up with that combination?

[00:28:54] Speaker 01:
It's not hindsight.

[00:28:56] Speaker 01:
If I was managing a development group and a software engineer put a semaphore into a single process system, I'd fire him.

[00:29:03] Speaker 01:
It doesn't work.

[00:29:04] Speaker 01:
It's dangerous.

[00:29:05] Speaker 01:
It doesn't provide any advantage.

[00:29:08] Speaker 01:
The only thing a semaphore does is manage contention for a resource by processes.

[00:29:14] Speaker 01:
If you replace the play logic with a semaphore, that system wouldn't do anything.

[00:29:18] Speaker 01:
The semaphore doesn't know anything about reading from RAM, audio conversion, anything like that.

[00:29:24] Speaker 01:
All it does is keep track of how many processes are currently accessing a resource.

[00:29:29] Speaker 01:
That's it.

[00:29:31] Speaker 01:
And when there's too many that try to access it, it puts one to sleep.

[00:29:35] Speaker 01:
And if there's only one process and it's put to sleep, that system will never recover.

[00:29:39] Speaker 01:
Because there's no other process to wake it up.

[00:29:43] Speaker 01:
So that doesn't make sense.

[00:29:45] Speaker 01:
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.

[00:30:04] Speaker 01:
All data is segmented.

[00:30:06] Speaker 01:
I mean, that has nothing to do with dividing a memory buffer up into separately lockable

[00:30:13] Speaker 01:
portions as we're teaching in Geltz.

[00:30:20] Speaker 01:
The other thing that I want to mention about Kunoff is that Kunoff explicitly states throughout the patent application that it is a hardware resource controller

[00:30:39] Speaker 01:
designed to run on top of a multitasking operating system.

[00:30:44] Speaker 01:
And it states throughout CUNA that that hardware resource controller is only designed to mitigate contention for a shared resource by multiple application programs.

[00:30:55] Speaker 01:
There are no application programs in these little player devices, none whatsoever.

[00:31:00] Speaker 01:
There's no multitasking operating system.

[00:31:04] Speaker 01:
Why do you need a multitasking operating system?

[00:31:07] Speaker 01:
Well, you need

[00:31:09] Speaker 01:
to be sure that anything that you're gonna use on a semaphore can be interrupted.

[00:31:14] Speaker 01:
Stop, be suspended, and then at a later time continue.

[00:31:18] Speaker 01:
That's not the case with the media player, if these things are not continuously running the music stops.

[00:31:25] Speaker 01:
So, cunef is really not analogous art at all.

[00:31:35] Speaker 01:
The other thing to note about cunef

[00:31:38] Speaker 01:
is that the hardware resources being controlled is an audio card.

[00:31:42] Speaker 01:
And all it does is take little tiny audio files to generate things like beeps and hums and whatever for application programs.

[00:31:51] Speaker 01:
It's not playing music.

[00:31:54] Speaker 01:
And what is being protected by the semaphore in CUNA is a very tiny little buffer.

[00:32:00] Speaker 01:
It's a command buffer.

[00:32:02] Speaker 01:
So the application program

[00:32:05] Speaker 01:
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.

[00:32:20] Speaker 04:
It's not the same type of system at all.

[00:32:27] Speaker 04:
I have just one point I want to make, which is that I thought your blue brief was very good at explaining

[00:32:34] Speaker 04:
your position and your arguments, your technical positions.

[00:32:37] Speaker 04:
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.

[00:32:52] Speaker 04:
And I would recommend that you not write that way, particularly in this court.

[00:32:57] Speaker 04:
I'll give you an example, something about how if we affirm

[00:33:00] Speaker 04:
then the PTO might as well rely on Palm Street and astronomy, astrology.

[00:33:06] Speaker 04:
These kinds of things aren't as helpful.

[00:33:10] Speaker 04:
But I do want to say that I thought your analogy was great in your blue brief.

[00:33:14] Speaker 04:
And so really just sticking to the facts would be very helpful for you.

[00:33:21] Speaker 04:
And for everybody.

[00:33:22] Speaker 04:
Thank you.

[00:33:23] Speaker 04:
Thank you.