SUPREME COURT GRANTS REVIEW OF MEDICAL PATENT THAT "CORRELATES" A TEST RESULT - AND DENIES MICROSOFT'S PETITION IN THE MEANTIME: The Supreme Court announced today that it will grant review of LabCorp v. Metabolite case, which was previously described as "dangerous" for the medical community. Labcorp's petition to the Supreme Court described the stakes thusly:

The Federal Circuit has construed a patent to grant a monopoly over a scientific fact, holding that doctors directly infringe the patent by thinking about a basic medical fact critical for treatment decisions, and that a third party induces infringement merely by reminding doctors of this fact. This decision, if allowed to stand, poses a severe threat to patient care. The opposition fails to dispel the intolerable uncertainty the Federal Circuit has imposed on all those who seek to provide doctors with the medical facts necessary for effective treatment of their patients, and all those who seek to comply with what should be uniform legal standards under the Patent Act. The Court should grant certiorari to resolve this uncertainty.

The issue in the case revolves partly around statutory subject matter (when it rains it pours), and particularly regarding the patenting of a natural phenomenon. Claim 13 of Metabolite's 4,940,658 patent recites the following:

13. A method for detecting a deficiency of cobalamin or folate in warm-blooded
animals comprising the steps of:

assaying a body fluid for an elevated level of total homocysteine; and

correlating an elevated level of total homocysteine in said body fluid with a deficiency of cobalamin or folate.

The sticking point in this claim is the word "correlating." According to LabCorp, there is no description of how the correlation occurs in the specification. And without this precise description, there is no enablement of the cited claim (see, e.g., Lizardtech, which was decided after this case). Furthermore, LabCorp argues that letting claim 13 stand from a patentable subject matter standpoint would open the door for parties to claim patent monopolies "over basic scientific facts rather than any novel inventions.

Arguments will be scheduled for next year. It is anticipated that the Court will address many of the patentability issues that have cropped-up over the last few years.

ABOUT MICROSOFT: Microsoft has not gotten much help from the courts (or from the USPTO for that matter) in dealing with their problems with Eolas. Not straying from the script, the Supreme Court denied Microsoft's petition for a writ of certiorari, and returned the entire case over to the district court to resolve a number of pending issues.

One point that was brought up by Dennis over at Patently-O was how the USPTO's claim interpretation will affect Microsoft's behavior towards its AcitveX plug-ins. Specifically, the Examiner found that, with respect to the active maps disclosed in the prior art, it is the browser application, and not "an executable application separate from the browser application," that makes the areas "interactive" by waiting for a user input, such as a mouse click. And because the prior art executable applications terminate after generating a static image, there is no on-going manipulation and control by the user of the object displayed within the browser-controlled window. As such, the prior art did not teach "interactive processing," as required by the claims (see page 5 of the Notice of Intent to Issue Reexam Certificate). Eolas' patent did not rely on a user event detected by the browser (such as a mouse click), but rather responded to the browser parsing an "embed text format" that is detected in the hypermedia document when first being loaded into the browser.

I don't see the Examiner's interpretation as being too limiting to Eolas, since many of these features have been already incorporated into ActiveX. However, there were some interesting comments made by the Examiner with respect to the Viola Browser application that was cited as prior art in the Reexam. I'd be interested to receive any feedback from the more hardcore programmers on these points:

If the Viola tags are considered as arguably corresponding to the instant claimed '906 "embed text format" (in the sense that the Viola tags specify "the location of at least a portion of an object external to the first distributed hypermedia document" as claimed in '906 claims 1 and 6), then the Viola script program specified between the tags is not equivalent to the instant '906 claimed external "object" when the claimed '906 external "object" is interpreted in a manner consistent with the specification of the '906 patent.

The Viola, "clock.v" script is a high-level source code PROGRAM. In contrast, the scope of the claimed '906 external "object" broadly encompasses myriad types of data objects, including self-extracting data objects [see '906 patent, col. 3, lines 33-51].

The scope of the claimed '906 external "object" is broad when construed in a manner consistent with the specification . . . However, the scope of the claimed '906 external "object" clearly does not read upon a high-level source code PROGRAM, such as a Viola script, nor does it read upon an object in byte-code form.

When the scope of the claimed '906 external "object" is construed in a manner consistent with the specification, it is clear that any executable component of the claimed '906 external data "object" is limited to performing self-extraction of the compressed data object . . . Although a self-extracting data object typically includes executable code to expand the compressed data object to its original size, this type of self-extraction extracts DATA that has no relationship to a high-level source code PROGRAM in the form of a Viola script, or a byte-code file, or the like.

Also, with respect to the "executable application" limitation:

While expert witnesses and dictionaries (considered as extrinsic evidence) may differ regarding the proper construction of the instant claimed "executable application," the Central Processing Unit (i.e., CPU or microprocessor) found in every computer system has only a single, precisely defined interpretation as to what constitutes an "executable application." When the CPU initiates a "fetch and execute" cycle, the program counter is loaded with the address of the next executable instruction. To be "executable" the contents of the memory location pointed to by the program counter must contain an instruction in binary form that is a member of the native instruction set of the microprocessor (i.e., a binary machine language instruction). The binary representation of the precise portion of the machine language instruction that determines what kind of action the computer should take (e.g., add, jump, load, store) is referred to as an operation code (i.e., OP code). From the perspective of the CPU, if a recognizable machine language instruction (i.e., a native CPU instruction) is not found within the memory location pointed to by. the program counter, the computer will crash.

The Viola system uses "C-like" Viola scripts that must be INTERPRETED by the browser and then TRANSLATED or CONVERTED into binary native executable machine code that can be understood by the CPU. Alternately, the Viola script is precompiled to intermediate byte-code form and the byte-code is interpreted (i.e., translated) into binary native executable machine code at runtime. This extra step of translation results in an unavoidable performance penalty, as interpreted applications run much slower than compiled native binary executable applications.

Accordingly, the "C-like" Viola scripts (or corresponding byte-code. representations) are not "executable applications" from the perspective of the CPU, which is the only perspective that really matters at runtime. A conventional CPU is only capable of processing binary machine language instructions from its own native instruction set.

Without an intermediate translation step performed by an interpreter component of the Viola browser, a Viola script (or corresponding byte-code representation) cannot be processed as an executable application by the CPU.

Significantly, the instant '906 specification is silent regarding the use of applications that rely upon scripts that must be interpreted before they can be executed. The instant '906 specification is silent with respect to interpreting code prior to execution. The instant '906 specification is silent with respect to the use of byte-code intermediate forms.

AND LAST, BUT NOT LEAST, a shout goes out to Stephen Nipper's Invent Blog that received an anonymous fax last year regarding US Patent 5,495,581, which apparently has some application to Eolas' '906 patent (to see the analysis, click the link to Stephen's Blog). In a Miscellaneous Incoming Letter, received in the PTO on October 16 in connection with the Reexam, the letter states that "[a] patent interference may exist between the matter of the above identified case and US Patent 5,495,581 and continuations stemming from it. Please have a look at this information by Googling: eolas interference nipper."

Bloggers - we HAVE arrived.