It realizes the request could end up being moot, but just in case one of its ships comes in, could it please, please amend to provide the court with "additional evidence that the Android dexopt tool performs the recited functions of the asserted claims 'at runtime'"? Yup, Oracle is still going on about "at runtime". It lost that battle, but Boies Schiller never gives in, never gives up. It claims the court's construction of the "at runtime" isn't the same as Google's or Oracle's, and that makes it new, and "unexpected". So that, it argues, would justify amending. And yes, Oracle attaches a "proposed supplemental infringement report" from "Prof. Mitchell", if the court gives in and gives up and lets them do this. But first, we'll be hearing from Google, who is probably turning purple by now. Nah. Their lawyers have proven to be every bit equal to this challenge. So let's just stay tuned.

The filings:

03/12/2012 - 781 - Administrative Motion to File Under Seal Portions of Motion to Amend Infringement Contentions and Supplement Expert Reports filed by Oracle America, Inc.. (Jacobs, Michael) (Filed on 3/12/2012) (Entered: 03/12/2012)

03/12/2012 - 782 - MOTION to Amend/Correct Oracle's '205 Patent Infringement Contentions and Supplement Expert Reports filed by Oracle America, Inc.. Responses due by 3/16/2012. Replies due by 3/19/2012. (Attachments: # 1 Proposed Order)(Jacobs, Michael) (Filed on 3/12/2012) (Entered: 03/12/2012)

03/12/2012 - 783 - Declaration of Marc Peters in Support of 782 MOTION to Amend/Correct Oracle's '205 Patent Infringement Contentions and Supplement Expert Reports filed byOracle America, Inc.. (Attachments: # 1 Exhibit A - proposed amended infringement contentions, # 2 Exhibit B - proposed supplemental infringement report, # 3 Exhibit C - portions of August noninfringement report)(Related document(s) 782 ) (Peters, Marc) (Filed on 3/12/2012) (Entered: 03/12/2012)

B. Oracle’s Amendments Will Not Unduly Prejudice Google

The proposed amendment will not unduly prejudice Google for two reasons. First, it does not change the infringement theory; it only identifies additional evidence to support the same theory. Oracle’s limited amendment to its infringement contentions does not create any need for Google to change its invalidity theories. Second, Google has sufficient time to respond to the proposed amendment, particularly if the trial is held in the fall.

1. Amendments Do Not Change Oracle’s Infringement Theory

Because Oracle seeks only to provide additional evidence to support the same infringement theory it has asserted since December 2010, the proposed amendments will not prejudice Google. In its ICs, Oracle has consistently contended that one of the ways Android infringes the asserted claims of the ’205 patent is when dexopt optimizes the classes in a Dalvik executable (“DEX”) file. For example, the ICs quote Google documentation entitled “Dalvik Optimization and Verification With dexopt,” which states that dexopt “[r]eplace[s] a handful of high-volume calls, like String.length(), with ‘inline’ replacements.” (Peters Decl. Ex. A at 7.) Statements like these, as well as the implementing code, support Oracle’s theory that dexopt’s inline substitution functionality infringes the asserted claims.

Oracle’s ICs identify how Android’s dexopt performs the steps of Claim (Id. at 2-22.) The ICs identify the DexOptimize.c Android source code file, which includes the optimizeClass() and optimizeMethod() functions that receive and optimize the virtual machine instructions in a given class and method. (Id. at 10.) The ICs show how optimizeMethod() in turn calls the rewriteExecuteInlineRange() function for certain virtual machine instructions to determine whether those instructions can be rewritten. (Id. at 11-13.) Whenever possible, the identified rewriteExecuteInlineRange() function generates a new virtual machine instruction, with OP_EXECUTE_INLINE_RANGE as the new opcode. (Id. at 13-14.) The instruction includes an index to the native code. (Id.) Thus, Oracle’s ICs explain how dexopt performs the step of “generating, at runtime, a new virtual machine instruction that represents or references one or more native instructions that can be executed instead of said first virtual machine instruction.”

Oracle’s ICs include evidence that dexopt runs at runtime. Dexopt’s documentation state that “[s]ome of these [the optimizations performed by dexopt] require information only available at runtime.” (Id. at 7.) For an Android phone, the ICs identify that dexopt may be run by the installer (the Android installer is an Android application) or in a “just-in-time” fashion on a development phone:

The system tries to pre-verify all classes in a DEX file to reduce class load overhead, and performs a series of optimizations to improve runtime performance. Both of these are done by the dexopt command, either in the build system or by the installer. On a development device, dexopt may be run the first time a DEX file is used and whenever it or one of its dependencies is updated (“just-in-time” optimization and verification).

(Peters Decl. Ex. A at 8, 13 (emphasis added).)

Oracle’s proposed amendment does not change this theory. The only substantive change is the addition of two paragraphs to the claim charts for the “generating, at runtime” element. (Id. at 19-20.) The other changes are two corrections of typographical errors and an update to the prefatory remarks to reflect the state of fact discovery after it closed in August 2011. Other than that, the proposed amendment does not change any of the quoted source code or the accompanying explanations.

The two paragraphs that Oracle seeks to add to address the Court’s construction of “at runtime” identify the specific Android installer virtual machine code that is executing when dexopt generates new virtual machine instructions. The proposed amendment identifies the Installer.java and PackageManagerService.java source code files as containing the dexopt() method and performDexOptLI() method, respectively, that cause dexopt to run when an application is being installed. (Id. at 19-20.) Because PackageManagerService.java and Installer.java classes are written in the Java programming language, both classes are compiled to virtual machine instructions for execution. Therefore, the entire dexopt process occurs during the execution of the virtual machine instructions of these two classes. The proposed additions to the ICs merely identify that these specific virtual machine instructions are executing when dexopt performs the generating step by calling the functions in DexOptimize.c, including optimizeClass(), optimizeMethod(), and rewriteExecuteInlineRange().

Prof. Mitchell’s supplemental report discusses this evidence in detail. It traces how the performDexOptLI() method of the PackageManagerService class invokes the dexopt() method of the Installer class, which is responsible for running dexopt. (Peters Decl. Ex. B at 8-10.) It quotes from the referenced PackageManagerService and Installer source code to clarify which virtual machine instructions are executing during the dexopt process. (Id. at 8-14.) Like the ICs, the supplemental report does not change the infringement theory—it only discusses additional evidence to specifically address the Court’s construction of “at runtime.”

OMG. We seem to be losing bigtime. What happened?

P.S. To all the patent trolls and any others dreaming of sticking their hands in Google's deep pockets and pulling out a big handful of money: never sue Google over anything where search skills could affect the outcome.