decoration decoration

When you want to know more...
For layout only
Site Map
About Groklaw
Legal Research
ApplevSamsung p.2
Cast: Lawyers
Comes v. MS
Gordon v MS
IV v. Google
Legal Docs
MS Litigations
News Picks
Novell v. MS
Novell-MS Deal
OOXML Appeals
Quote Database
Red Hat v SCO
Salus Book
SCEA v Hotz
SCO Appeals
SCO Bankruptcy
SCO Financials
SCO Overview
SCO v Novell
Sean Daly
Software Patents
Switch to Linux
Unix Books


Groklaw Gear

Click here to send an email to the editor of this weblog.

You won't find me on Facebook


Donate Paypal

No Legal Advice

The information on Groklaw is not intended to constitute legal advice. While Mark is a lawyer and he has asked other lawyers and law students to contribute articles, all of these articles are offered to help educate, not to provide specific legal advice. They are not your lawyers.

Here's Groklaw's comments policy.

What's New

No new stories

COMMENTS last 48 hrs
No new comments


hosted by ibiblio

On servers donated to ibiblio by AMD.

Dr. Mitchell's Testimony | 89 comments | Create New Account
Comments belong to whoever posts them. Please notify us of inappropriate comments.
Corrections thread
Authored by: nsomos on Thursday, May 17 2012 @ 05:08 PM EDT
Please post corrections here.
e.g. Misteak -> Mistake

[ Reply to This | # ]

How does reading back testimony actually work?
Authored by: Anonymous on Thursday, May 17 2012 @ 05:10 PM EDT
How does reading back testimony actually work?
I mean can Oracle just pick and choose what bit they want read back, or can
Google also choose rebuttal testimony to be read back? Or do they present
different options and the judge decides?

[ Reply to This | # ]

Off Topic Here
Authored by: SilverWave on Thursday, May 17 2012 @ 05:15 PM EDT

RMS: The 4 Freedoms
0 run the program for any purpose
1 study the source code and change it
2 make copies and distribute them
3 publish modified versions

[ Reply to This | # ]

News Picks Here
Authored by: SilverWave on Thursday, May 17 2012 @ 05:16 PM EDT

RMS: The 4 Freedoms
0 run the program for any purpose
1 study the source code and change it
2 make copies and distribute them
3 publish modified versions

[ Reply to This | # ]

Tweets googlevoracle
Authored by: SilverWave on Thursday, May 17 2012 @ 05:18 PM EDT!/tqft 9999/googlevoracle

RMS: The 4 Freedoms
0 run the program for any purpose
1 study the source code and change it
2 make copies and distribute them
3 publish modified versions

[ Reply to This | # ]

Comes Stuff Here
Authored by: SilverWave on Thursday, May 17 2012 @ 05:21 PM EDT

RMS: The 4 Freedoms
0 run the program for any purpose
1 study the source code and change it
2 make copies and distribute them
3 publish modified versions

[ Reply to This | # ]

Dr. Mitchell's Testimony
Authored by: Chromatix on Thursday, May 17 2012 @ 05:35 PM EDT

I might be getting a little optimistic here, but this is what the jury could be thinking at this point:

Firstly, they're confused. They got a lot of conflicting testimony, of which (as we know) much was *designed* to confuse them, but at least they *know* they're confused.

So now they're trying to sort out the confusion by eliminating witnesses that they can show are untrustworthy. If, after eliminating those, most of the evidence is consistent and clear, they'll be in a much better position to make a decision.

They've selected Dr. Mitchell as potentially untrustworthy, and want to get the readback as part of that evaluation. Don't ask me why they need a readback for this - surely they have the transcripts in front of them?

[ Reply to This | # ]

"permitted to be taken as evidence"
Authored by: bugstomper on Thursday, May 17 2012 @ 06:32 PM EDT
Reading over the question and the answer I think that Judge Alsup did give them
something they can work with.

They asked if something is "permitted to be taken as evidence". He
answered, "I've previously told you what's evidence in this case, and
what's not, I'm not going to repeat that." That tells them to review their
instructions which will say that expert testimony is part of the evidence, and
it is up to them to weigh the credibility of the expert testimony as they weigh
all of the evidence and witness testimony.

He then says "your question is one that goes to the weight of the evidence
and how to evaluate it. That is for you to decide." Combined with the first
part it tells them that yes, it is part of the evidence, and like all the
evidence it is up to them to decide who and what to believe.

What they asked is if they could consider what Parr said about how he
demonstrated that the stack code was not run as evidence. They were told that
they could consider it and it is up to them to consider it and decide about it.
Now they are asking for Mitchell's testimony which disagrees with Parr. That
shows that they are considering the dueling expert testimony. That's what they
should be doing.

[ Reply to This | # ]

Reporter appreciation thread - Who is this amazing reporter?
Authored by: bugstomper on Thursday, May 17 2012 @ 07:01 PM EDT
PJ, I know that having a nym would not really identify the reporter, but can we
have one by which we can refer to her or him when expressing appreciation for
this truly amazing job of on the fly transcription? Is this person an off-duty
court reporter?

[ Reply to This | # ]

Shame the one dumb guy won't disqualify himself.
Authored by: BitOBear on Thursday, May 17 2012 @ 08:13 PM EDT
Imagining the deliberations, I suspect that there is one guy on the jury who
just doesn't "get" his job.

The jury seems to be trying to find a verdicts that make -all- the testimony
true. This is a typical scenario where someone is trying to be an intellectual
peace maker.

If you have ever been in an argument with someone who doesn't understand that
all citations and recitations of alleged fact are not -equally- true, then you
know the exact experience I suspect is bogging down this jury.

If someone throws in a "bad fact" such completionists can deadlock
-themselves- let alone a quorum.

Think "twelve angry men", but more passive aggressive. /joke.

[ Reply to This | # ]

Parr for the case
Authored by: Ian Al on Friday, May 18 2012 @ 06:45 AM EDT
I'm glad I reviewed Mr. Parr's testimony. It helped me spot this bit of nonsense from Oracle.
Now, the first point: the experiment that Dr. Parr did went to proving that the stack was not used in Android. That is legally irrelevant, as there's no requirement in the claims that the stack be used. In other claims there is such a requirement, but not in the asserted claims.
What Mr. Parr did was to explain how dex (I think that is the pronunciation of dx) uses simulated execution, as described extensively in its comments. Whenever dx does simulated execution it makes extensive use of stack manipulation. Whenever it stops using simulation, it stops manipulating the stack. This is nothing to do with patent claims. It is to do with how dx works.

You need to see quite a lot of Mr. Parr's testimony to answer the juries question for yourself.
"We are attempting to determine the scope of the meaning of the term 'simulating execution of the bytecodes' in patent '520. Is the existence of an example of the Android code not functiong (punting), when formatted in a normal simulated execution setting, permitted to be taken as evidence that Android's array initialization diverges from the patented array intiialization?"
Here is a lot of what Mr. Parr said, including the reference to 'punt'.
Mr. Parr: I understand "execution" to mean running live on the JVM. Simulating execution is in the preloader -- it's like a dress rehearsal versus a live show. The goal is to simulate these bytecodes to determine the static initialization of the array.

Google: What's the core requirement for simulating execution on a stack machine?

Mr. Parr: Well, you need to manipulate the stack -- pushing, popping, etc.

Google: Is this described in the patent?

Mr. Parr: It does not say stack manipulation.

[Shows how the example code in the patent is operating on a stack]

"Object stack[] = new Object[stackSize]; // create stack for play execution" etc...

Google: Were you in court for Dr. Mitchell's testimony on infringement?

Mr. Parr: Yes.

Google: Do you agree with his testimony?

Mr. Parr: No.

Google: Why not?

Mr. Parr: Because dexopt doesn't use simulated execution for the purpose of determining static initialization of the array.

Google: How did you determine that?

Mr. Parr: Spent a long time looking at the dex source, running tests, etc.

Google: What's the purpose of the Android dex tool?

Mr. Parr: It takes the .class files emitted by the Java compiler, and translates them to .dex files.

The Java Virtual Machine and the Dalvik VM have completely different instruction sets, so a translation has to occur... That's what dex does. It translates Java bytecodes into Android bytecodes, so Android can execute them.

[Discussion about how dex uses simulated execution, as described extensively in its comments.]

Google: So you'd agree that the Simulator class does know how to simulate bytecodes?

Mr. Parr: Yes.

Google: So why doesn't it infringe the '520 patent?

Mr. Parr: That's because for the very specific purpose of identifying the static initialization of the array, it does something different -- it uses pattern matching...

Mr. Parr: What I identified was the specific part of the program, dex, that identified the static initialization of the array. It's in parseNewarray... there's a comment: "Try to match the array initialization idiom. For example, if the subsequent code is initializing an int array, we are expecting the following pattern repeatedly" -- and then you see the pattern we saw earlier, for how to initialize an array. It appeared to me to be a classic example of a pattern matcher.

Google: How do you know?

Mr. Parr: Well, I've been building parsers for 30 years. See line 965, it defines a variable called "punt" -- it's looking for something, if it doesn't find it, it fails. It's a classic example of pattern recognition.

Google: Is it manipulating the stack at all here?

Mr. Parr: No, I didn't see any stack manipulation.

Google: What experiments did you use to test your hypothesis that this was using pattern matching?

Mr. Parr: Well, first I did a simple test to see that there were no stack manipulations in the static array initialization. I put print statements in the stack manipulation instructions (push, pop), like an alarm, so they'd trigger if there was any stack manipulation. I didn't see any.

[Demonstrative, titled "parseNewarray does not use the stack", showing the output of running the program with his debug prints added]

During the normal operation of the simulated execution, we see stack manipulation. But as we enter the parseNewarray method, what I observed is the stack alarms went silent until the parseNewarray method had exited. But once we returned from parseNewarray, we again got stack manipulations.

Since there are no stack manipulations, it can't be using simulated execution to identify these initialization.

Google: What was the second experiment you performed?

Mr. Parr: Well, this one's a little trickier, but useful. If it were using pattern matching, then if the pattern of initializations were altered, the pattern would fail to match. But if it were using simulated execution, then a minor change wouldn't affect it and it would still work...

Mr. Parr: First, I ran dexopt on this sequence, generated by the compiler. It does indeed create an instruction to initialize this array, all in one go. So the default output of the compiler is recognized by the dex tool as static initialization.

So, how can I change this sequence of instructions without modifying the end result? Remember a new array is already initialized to zero. I'm just going to add an extra instruction at the beginning to set it to zero again. This is a tweak that doesn't affect the code; if it executes, it wouldn't change the end array. However, if the dex tool is a pattern matcher, it'll fail to recognize this pattern.

I ran the dex tool on this modified bytecode stream, and the dex tool failed to generate an instruction to initialize these elements in one go...

You can see these extra instructions don't change anything, since that zero is already there.

Here are the Dalvik bytecode instructions created by the dex tool in response to the original bytecode sequence: it uses fill-array-data.

But with the modified code, there's no fill-array-data to initialize the array in one go. You see the normal conversion of Java bytecodes to Dalvik instructions (new-array, aput, etc.).

Google: If the dex tool were in fact simulating the execution of the Java bytecode, what would have resulted?

Mr. Parr: If it were simulating, it wouldn't care about the extra instruction.
What he has done is identified that arrays are statically initialised by dx using parseNewarray. During its operation it does not manipulate the stack. His demonstration shows that the stack is not manipulated during the execution of parseNewarray and that this is shown by monitoring for the break in stack manipulation which is used by dx for simulated execution.

His second experiment was to add an extra single instruction at the beginning to set the array to zero. Running dx on the modified code fails to generate an additional single instruction to initialise the array. If simulation had been used, dx would have ignored the existence of that first single step initialisation instruction, spotted the subsequent instruction group initialising the array and generated an additional replacement single instruction.

So, the answer to the jury question is 'yes' if you believe that Mr. Parr has demonstrated that dx uses stack manipulation when simulating execution.

Ian Al
Software Patents: It's the disclosed functions in the patent, stupid!

[ Reply to This | # ]

Groklaw © Copyright 2003-2013 Pamela Jones.
All trademarks and copyrights on this page are owned by their respective owners.
Comments are owned by the individual posters.

PJ's articles are licensed under a Creative Commons License. ( Details )