[00:00:00] Speaker 02:
This is telecon.

[00:00:49] Speaker 02:
Mr. Peterson.

[00:00:58] Speaker 04:
Thank you, may it please the court.

[00:01:01] Speaker 04:
Although we believe the board committed several errors in its failure to find the motivation to combine the prior art references cited by TCL in this proceeding, I'd like to focus on what I think is the

[00:01:15] Speaker 04:
most straightforward and simplest basis for reversing the board's decision and remanding for further analysis.

[00:01:21] Speaker 04:
And that's the relationship between the Yosui piece of prior art, the mobile execution environment standard cited in Yosui, and the security model of Java 2 micro edition.

[00:01:34] Speaker 04:
So on appendix page 32, the board found that the patent donor submitted persuasive evidence that using J2ME, that's using Java 2 micro edition on its own,

[00:01:45] Speaker 04:
would have been sufficient to be compliant with the mobile execution environment standard.

[00:01:49] Speaker 04:
That's MEXE.

[00:01:51] Speaker 04:
No evidence, much less substantial evidence, supports this finding.

[00:01:56] Speaker 04:
Now, Java 2 Micro Edition, everyone agrees, has a fairly basic security model.

[00:02:02] Speaker 04:
Uses what's called a sandbox model.

[00:02:04] Speaker 04:
Code is either trusted or untrusted.

[00:02:07] Speaker 04:
Untrusted code is placed in a sandbox with limited to no access to system resources.

[00:02:12] Speaker 04:
Trusted code, in contrast,

[00:02:13] Speaker 04:
has access to system resources.

[00:02:16] Speaker 04:
This is black and white, one or zero, either you are trusted or you are untrusted.

[00:02:23] Speaker 04:
The mobile execution environment, as Ericsson and as the board noted, has the concept of a sandbox for untrusted code, but it doesn't stop there.

[00:02:34] Speaker 04:
It also includes three different security domains for trusted code, each with varying levels of access control.

[00:02:42] Speaker 04:
And Yosui teaches that a security manager is necessary to implement the three trusted domains.

[00:02:47] Speaker 04:
But Yosui itself doesn't teach how to implement the security manager.

[00:02:52] Speaker 04:
And there's no evidence in this record that Java 2 Micro Edition on its own includes a security manager that would implement the three trusted domains of the MEXE standard.

[00:03:04] Speaker 04:
And in fact, there's not even an argument from Ericsson that J2ME on its own included a security manager

[00:03:10] Speaker 04:
that satisfied these three trusted domains.

[00:03:14] Speaker 04:
Every time that Erickson talked about the J2ME standard with the board with MEXC, Erickson was very careful to say that USUI was using J2ME for the untrusted portion of the MEXC standard.

[00:03:28] Speaker 04:
You'll see this on appendix pages 3882, that's in the patent donor's response, Erickson pointing out with the untrusted domain being fully addressed by the sandbox security model,

[00:03:40] Speaker 04:
Their expert says the same thing on appendix page 3983, 3984.

[00:03:44] Speaker 04:
As for the MEXC untrusted area, Yosui is using the sandbox model that was specifically designed for the J2ME platform.

[00:03:55] Speaker 04:
What Erickson hasn't argued is that J2ME on its own has a security manager that would satisfy the three trusted domains.

[00:04:04] Speaker 04:
So in our view, motivation to combine is straightforward.

[00:04:07] Speaker 04:
Yosui teaches you need to have a security manager

[00:04:10] Speaker 04:
to comply with these three trusted domains requirement.

[00:04:14] Speaker 04:
And Gong and Oakes both provide general architectural guidance on how to implement such a security manager.

[00:04:21] Speaker 04:
And in fact, this is an answer.

[00:04:23] Speaker 00:
Why would Gong and Oakes, which provide security in a computer environment, why would one of ordinary skill in the art

[00:04:35] Speaker 00:
inclined to look to those references to provide a security capability in a mobile environment, like Yusui?

[00:04:44] Speaker 04:
Well, as it was recognized at the time, Sun Microsystems in the computer environment had provided a more complex, more granular system for access control in the computer environment.

[00:04:55] Speaker 04:
In designing J2ME, which was intended for the mobile environment, Sun included a much more basic, much more limited security model.

[00:05:04] Speaker 04:
So when Yasui says implement MEXC, which is more granular, which provides more control, more complexity than Sun chose to include in the mobile environment, you would necessarily look to the desktop environment, which is where this more complex, more granular access control.

[00:05:21] Speaker 02:
But how do you know what to pick in the greater environment?

[00:05:24] Speaker 02:
And where's the motivation to combine only the access controller of Oaks with this?

[00:05:31] Speaker 02:
Where's that, the specific motivation

[00:05:34] Speaker 02:
to say, OK, we're going to take this, this, and this from the desktop environment.

[00:05:39] Speaker 04:
Well, let's look at claim one of the 510 patent.

[00:05:42] Speaker 04:
I think this is helpful, because I think one of the ways the board... Can you answer her question?

[00:05:48] Speaker 04:
Well, Your Honor, what I'd like to do is answer it in the context of claim one of the 510 patent, because I think it's important that what we're asking for here is a motivation to combine... Why can't you specifically identify the things that you're going to pluck out of gong and oaks and stick in your suey?

[00:06:04] Speaker 04:
Yes, Your Honor.

[00:06:04] Speaker 01:
And point out where the evidence was that Lawrence Kilmer had done that.

[00:06:08] Speaker 01:
I think that's the thrust of Chief Judge's question.

[00:06:13] Speaker 04:
I think it's, well, yes.

[00:06:17] Speaker 01:
The way I see the case is that it's a substantial evidence case.

[00:06:21] Speaker 01:
The question of whether or not to modify Yosui after looking at Kongs and Oaks is a fact question, right?

[00:06:29] Speaker 01:
For review here.

[00:06:31] Speaker 01:
It's a fact question.

[00:06:32] Speaker 04:
I think that's correct.

[00:06:33] Speaker 01:
I will point the board to... So it's a fact question, and so we have to ask, you know, what was the evidence?

[00:06:41] Speaker 01:
And there's evidence that goes both ways.

[00:06:45] Speaker 01:
You have an expert that said, well, generally, well, of course one of ordinary skill would have looked at gong and oats.

[00:06:51] Speaker 01:
I mean, if what he's trying to do is to improve on the ability of the phone to control these transmissions coming in, we go look at computers.

[00:07:03] Speaker 01:
And that's just, that's the best evidence you have is that statement of your expert, not backed up by anything more than just that.

[00:07:10] Speaker 01:
The other side comes in and says, well, that may be the case, but actually the current thinking about telephones sort of teaches away from doing that because it's a very limited environment.

[00:07:19] Speaker 01:
You don't have a lot of space for cramming in a lot of this other stuff.

[00:07:22] Speaker 01:
So there's, in my judgment, there's evidence on both sides of the fence.

[00:07:28] Speaker 01:
And when it comes to deciding a substantial evidence case, if there's

[00:07:32] Speaker 01:
evidence on the other side against you, you lose.

[00:07:35] Speaker 01:
If you were here arguing the other side of the case, you would be arguing substantial evidence for sure, and it's an easy case.

[00:07:41] Speaker 04:
I think it's certainly true.

[00:07:42] Speaker 01:
What I'd say... So it seems to me integral to your case to be able to identify specifically what your one of ordinary skill in the art would have done looking at Gong's and Oaks.

[00:07:53] Speaker 01:
What would he have plucked out

[00:07:56] Speaker 01:
Yes in order to achieve the job and your best argument is that an attempt was made to do it that somebody actually took a cell phone before the filing date and crammed something else into it besides the sandbox.

[00:08:11] Speaker 01:
But the point was that you didn't make any factual showing about exactly what it was that was put in and how that worked.

[00:08:21] Speaker 01:
So to me it's a failure of proof case on your side.

[00:08:24] Speaker 01:
That's why I was interested in a real, direct answer to the chief judge's question instead of a let's go around the loop and talk about something else.

[00:08:33] Speaker 04:
Well, thank you.

[00:08:34] Speaker 04:
So the direct answer is what we believe that the patent that one of Still in the Art would have taken from Gong and Oaks is very basic, high-level architecture about how to implement ASIC.

[00:08:44] Speaker 01:
Where is the testimony from your expert that said just exactly that?

[00:08:49] Speaker 04:
Our expert identified the specific pieces

[00:08:53] Speaker 01:
Why don't you give us some citations for that?

[00:09:01] Speaker 01:
I'll grant you that your expert made a general statement that when I was going there, I would of course have looked at Long and Oaks and made these adjustments to Yosui.

[00:09:12] Speaker 01:
But show me in the record what that specific language is from your expert.

[00:09:17] Speaker 04:
Well, but I would point out it's appendix pages 3700 to

[00:09:23] Speaker 04:
In particular, 3720.

[00:09:27] Speaker 04:
3720?

[00:09:28] Speaker 04:
Yes, and what our expert's doing there is he's identifying the very high-level architectural pieces of how a security... Is that paragraph 223?

[00:09:41] Speaker 04:
I believe it's paragraph 178 through 223, Your Honor.

[00:09:47] Speaker 00:
Is there a particular paragraph in that collection that you would direct us to?

[00:09:52] Speaker 02:
Paragraph 178 explains that generally... So you're on 3,700.

[00:09:57] Speaker 02:
Okay, so this is about 20 pages that you've referred us to.

[00:10:01] Speaker 04:
Yes, Your Honor, and I'm sorry about that, but what our expert did is explain how the general high-level structural disclosures of the Gong reference correspond to the general high-level structural security manager disclosures.

[00:10:16] Speaker 04:
I'll certainly claim one of the 510 patent here.

[00:10:19] Speaker 04:
And recall, this claim is

[00:10:22] Speaker 04:
really quite basic.

[00:10:24] Speaker 04:
The key portions that we're relying on for Gong are simply when you implement a security manager, you need to have an interception module that receives a request to access the protected resources.

[00:10:36] Speaker 04:
Gong calls that a resource manager.

[00:10:38] Speaker 04:
And then you need to have a decision entity to determine if that request should be granted.

[00:10:42] Speaker 04:
And that decision entity has to hold access and permission policies.

[00:10:46] Speaker 04:
Gong teaches that this is an access controller.

[00:10:48] Speaker 04:
So the question

[00:10:50] Speaker 04:
for motivation to combine is whether one would be motivated to combine Yosui and Gong, keeping in mind that Yosui says you need to add on a security manager to the J2ME mobile environment in order to implement these three trusted domains.

[00:11:03] Speaker 01:
Wouldn't that then depend on what you're going to do, what you're going to stick in the phone beyond the sandbox and how much space it was going to take up in the phone?

[00:11:13] Speaker 04:
Well, I think that's right.

[00:11:14] Speaker 04:
But Yosui has crossed that bridge.

[00:11:16] Speaker 04:
And most of the resource are- Crossed which bridge?

[00:11:19] Speaker 04:
The bridge of going beyond what Sun Microsystems already put into J2ME.

[00:11:23] Speaker 04:
We think the board's analysis of whether Gong and Oaks were too resource intensive were based on a misunderstanding of whether J2ME already complied with the MEXE standard.

[00:11:35] Speaker 04:
So Erickson was able to say, well, Sun Microsystems, in its wisdom, chose not to include anything beyond basic J2ME security when it implemented J2ME for the mobile environment.

[00:11:47] Speaker 04:
Therefore, one of skill in the art wouldn't go beyond that.

[00:11:50] Speaker 04:
And if you accept the premise, it's really a fairly compelling argument and one that the board accepted.

[00:11:55] Speaker 04:
But the problem is the premise is wrong.

[00:11:56] Speaker 04:
Yasui already says you have to add more into the mobile environment than Sun Microsystems chose to put in there with the basic MEXC standard.

[00:12:05] Speaker 00:
But even if that's what Yasui said, that you have to add more, the question is why would one of ordinary skill in the art look to

[00:12:17] Speaker 00:
Gong and Oaks to find that extra security and what in those computer environment references might apply in the resource restricted environment of a mobile system.

[00:12:34] Speaker 04:
And certainly what our expert testifies is that these are known methods of providing more granular access control in the basic sandbox system and in particular Gong itself points to the defects

[00:12:44] Speaker 04:
in the sandbox system and the need for more granular access control.

[00:12:48] Speaker 04:
With panel's permission, I'll reserve for later my time.

[00:13:08] Speaker 03:
Good morning, Your Honors.

[00:13:10] Speaker 03:
I think the Court's already recognized that this is really a case about

[00:13:14] Speaker 03:
Is there substantial evidence to support the board's decision on the motivation to combine?

[00:13:19] Speaker 03:
And some of that's been couched by the briefs from TCL in terms of various arguments that they are arguing now they didn't make before the board.

[00:13:29] Speaker 03:
I think the more important question is, what did the board actually have in front of it in making its decision?

[00:13:34] Speaker 03:
And so if we turn to the board's decision on page 27, APPX 27,

[00:13:41] Speaker 03:
The board actually quotes TCL's actual argument that they're making as to what are they combining.

[00:13:47] Speaker 03:
And they say, petitioners rely on a particular theory for the motivation to combine.

[00:13:53] Speaker 03:
Specifically, that is, quoting TCL, would that person of skill and the art have been motivated to implement the access controller of Gong as the security management mechanism of Yusui to provide the fine-grained access control identified in Yusui?

[00:14:09] Speaker 03:
Now, the board goes on to analyze that under the appropriate standards, first looking to the scope and content of the prior art, looking at what is disclosed in USUI and what's disclosed in Gong, making findings that USUI is directed to a particular problem of developing software, a user interface for a very resource-limited device, a mobile phone, which they call a CLDC, connection-limited device configuration.

[00:14:36] Speaker 03:
And that had known parameters, as Ericsson explained in its testimony and evidence that it submitted to the board.

[00:14:42] Speaker 03:
And the board found that that was a design criteria utilized for the phones.

[00:14:49] Speaker 03:
And what Yusui was trying to do was develop software that could execute quickly.

[00:14:53] Speaker 03:
Java is known, according to Yusui, to execute slowly.

[00:14:57] Speaker 03:
And so the solution for that was keep the Java component as small as possible so it would execute quickly.

[00:15:03] Speaker 03:
The board turned next to evaluating Gol.

[00:15:05] Speaker 03:
and found that it was directed to a computer-based desktop-type system interconnected with the internet that had complex security parameters, and that it was basically directed to a different environment.

[00:15:18] Speaker 03:
And that was supported by substantial evidence submitted by Ericsson showing that Sun Microsystems, the developer of the Java system, actually considered those two environments very different, had different software, different applications, each of which required different system

[00:15:34] Speaker 03:
requirements in terms of processing power and memory, ultimately concluding that it wouldn't have been obvious to make that combination.

[00:15:42] Speaker 03:
I want to address another point that's been raised, is the concept of the MEXE standard.

[00:15:49] Speaker 03:
Yusui references that in the actual text of the article.

[00:15:54] Speaker 03:
And contrary to what counsel has said, Erickson did submit testimony and evidence directed to that aspect.

[00:16:02] Speaker 03:
that USUI would use three domains for the trusted software and the sandbox model for the untrusted, that those are compliant with the MEXC standard.

[00:16:15] Speaker 03:
So again, there is substantial evidence supporting the board's conclusions that they failed to demonstrate a motivation to combine USUI with Gong, and similarly, USUI with the OAKS reference in a separate IPR.

[00:16:31] Speaker 03:
One of the issues raised in the briefing that wasn't raised here in discussion was the argument that the board should have construed the claims before addressing the motivation to combine.

[00:16:42] Speaker 03:
Here it was clear that was unnecessary to resolve the dispute.

[00:16:45] Speaker 03:
The elements that were found lacking in USUI, TCL freely admits that those elements aren't in USUI.

[00:16:52] Speaker 03:
In their own papers, point that.

[00:16:58] Speaker 03:
So in APPX 94,

[00:17:01] Speaker 03:
They recognize in the petition that USUI fails to disclose the interception module aspect of the claim.

[00:17:08] Speaker 03:
And then in APPX 94, they concede that USUI fails to disclose the decision entity module.

[00:17:15] Speaker 03:
So without the proposed combination, there was no need to do a claim construction because petitioner freely admits that USUI by itself fails to disclose these claim elements.

[00:17:25] Speaker 03:
So there again, the board did not err by not constring those because it's not necessary

[00:17:30] Speaker 03:
to resolve the dispute.

[00:17:34] Speaker 03:
One further point.

[00:17:36] Speaker 03:
They raise a number of new arguments in their briefing that weren't before the board.

[00:17:40] Speaker 03:
And one thing I would note is they did not raise these in request for rehearing before the board.

[00:17:46] Speaker 03:
So the board never had an opportunity to consider these.

[00:17:49] Speaker 03:
One is that somehow the MEXC standard itself provided motivation to make the combination.

[00:17:55] Speaker 03:
Will the board address the MEXC standard based on the arguments actually presented during the proceeding?

[00:18:00] Speaker 03:
and found that there was no motivation based on compliance with the standard.

[00:18:05] Speaker 03:
They also reached to further instances in Gong that they allege would support a motivation to combine.

[00:18:11] Speaker 03:
Again, these were not addressed below.

[00:18:13] Speaker 03:
Finally, in their appeal briefing here, they raised for the first time that the claims themselves should be considered broad enough.

[00:18:21] Speaker 03:
I would point out here, my only opportunity to respond to that, that the claims don't even address an access controller, the decision entity,

[00:18:28] Speaker 03:
or the interception module.

[00:18:30] Speaker 03:
So those elements aren't even the claims.

[00:18:32] Speaker 03:
Of course, there's no testimony about that, and it's simply attorney argument.

[00:18:36] Speaker 03:
Finally, I'd note that, again, it's TCL's argument that it's Gong's access controller that would be implemented in USUI.

[00:18:43] Speaker 03:
And they even point and say it would be a primary embodiment of Gong, that access controller that would be implemented.

[00:18:48] Speaker 03:
So nothing as broad as they're arguing now, and there is no expert testimony to support their arguments.

[00:18:54] Speaker 03:
And in fact, the expert testimony supports

[00:18:57] Speaker 03:
Erickson's position that there was substantial evidence on the board's findings.

[00:19:03] Speaker 03:
If there are no questions from the panel.

[00:19:08] Speaker 04:
Thank you.

[00:19:13] Speaker 04:
Your Honor, when I begin my argument by saying there's no evidence of a particular point in the record, I would hope to hear the appellee cite the record evidence to support that point.

[00:19:22] Speaker 04:
And what's critical is that my friend didn't

[00:19:26] Speaker 04:
defend the board's mistake on appendix page 32 that I began my argument with.

[00:19:31] Speaker 04:
There is no evidence and Erickson has never argued that J2ME on its own was sufficient to be compliant with MEXE.

[00:19:41] Speaker 04:
That mistake, this belief that Sun Microsystems in J2ME itself had already included a security manager that was compliant with MEXE tainted the board's analysis of whether there was motivation

[00:19:54] Speaker 04:
to add a security manager using Gong and Oaks onto the Usui reference, because Usui teaches you need to implement a security manager, and it infected the board's reasoning about whether it would have been common sense just to use J2ME sandboxing.

[00:20:10] Speaker 04:
We argue below the same argument we're making now, which is that J2ME sandboxing on its own

[00:20:16] Speaker 04:
is not sufficient to comply with the MEXC standard.

[00:20:19] Speaker 04:
So what you really have here is frankly just, it's a round hole and a round peg.

[00:20:23] Speaker 04:
Yosui says you need a security manager to provide this more granular access to system resources via the three trusted domains of MEXC.

[00:20:35] Speaker 01:
Yosui says that, but the question is where would you go look?

[00:20:38] Speaker 01:
Where would one of our ordinaries kill in the air be inclined to look?

[00:20:41] Speaker 04:
And our expert testified, one ordinary skill in the art, to known methods of providing more granular access control, indeed, that have been used in the Java environment, like Gong and Oaks.

[00:20:52] Speaker 04:
Sun said, we're going to do something less complicated on the mobile system.

[00:20:57] Speaker 04:
Yasui said, you need to do something more complicated.

[00:20:59] Speaker 04:
Where would one skill in the art go to look for that?

[00:21:01] Speaker 04:
One skill in the art would go back and look at the known, more complex methods of security control that had already been used.

[00:21:09] Speaker 04:
Their expert doesn't say where else one would look.

[00:21:11] Speaker 04:
That's really quite significant.

[00:21:13] Speaker 01:
You'll see this is paragraph 203 of... Wasn't the board saying your expert's explanation wasn't specific enough?

[00:21:22] Speaker 01:
You fail for specificity?

[00:21:24] Speaker 01:
And I think the problem is... Isn't that what they were saying?

[00:21:28] Speaker 01:
So your question to ask is to decide whether or not you need to be more specific than your expert wants?

[00:21:34] Speaker 04:
Well, the problem is I think the board's analysis was based on a false premise.

[00:21:38] Speaker 04:
The board said, well, hold on.

[00:21:40] Speaker 04:
Some microsystems already has an MEXC-compliant security manager in Java 2 Micro Edition.

[00:21:46] Speaker 04:
Why would you go out and do more with that?

[00:21:48] Speaker 04:
Why would you add on these more resource-heavy, more intensive, complicated security management systems when you already have a perfectly good security manager in Yosui that already satisfies MEXC?

[00:22:00] Speaker 04:
That, I think, is the essence of the board's understanding why the board rejected our expert's testimony.

[00:22:05] Speaker 04:
It simply didn't understand that Yosui was already teaching you need to go beyond MEXC.

[00:22:13] Speaker 04:
I'm sorry, not you need to go beyond MEXE.

[00:22:17] Speaker 04:
You need to go beyond J2ME in order to satisfy MEXE.

[00:22:21] Speaker 04:
You need to add a more complicated security manager.

[00:22:23] Speaker 04:
onto the basic Java 2 mobile edition environment.

[00:22:27] Speaker 04:
And so the arguments that say, you wouldn't do anything more complicated than Sun has already done, simply fall away.

[00:22:33] Speaker 04:
And we think those were crucial to the board's analysis.

[00:22:35] Speaker 04:
And we'd simply ask to return to the board.

[00:22:38] Speaker 04:
And with that mistake corrected, to have further proceedings there.

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