Judge Chooses Simplest Claim Construction in a Markman Hearing Shootout

The judge on the Juxtacomm versus Ascential Et Al case released a preliminary list of patent construction terms and definitions and it looks like the definitions from the plaintiff were preferred to the more specific definitions from the defendant.

Quick History: JuxtaComm dreams of $138 billion in lawsuit against ETL vendors and sue the biggest software vendors in the world for patent infringement. Last week The Small Fish Settle in Juxtacomm versus Ascential Et Al where five of the parties agreed to a preliminary settlement leaving seven parties fighting it out including the big fish of IT in IBM, Microsoft and Business Objects.

The Markman Hearing game here was quite simple – you take a bunch of key phrases out of the data integration patent owned by Juxtacomm and Teilhard technologies, terms like “metadata database” and “script” and you try to agree on a definition for these terms so you can work out which parts of the defendants software suite infringe on the patent. When you can’t agree on definitions you bring in the judge and he reads both sets of opinions and comes up with a set of terms. Generally the Plaintiff provides simple and general definition so they can argue that a wide range of products infringe while the defence tries to pin the terms back with more specific definitions. This week the judge filed his preliminary ruling on these terms:

Case 2:07-cv-00359-LED Document 458 Filed 02/10/2009

This is a preliminary order concerning the claim construction of U.S. Patent No. 6,195,662 (“the ‘662 patent”). The Court’s determination of disputed terms in the ‘662 patent are listed in the chart below. A full claim construction opinion will be forthcoming.

What follows is a list of terms and definitions from that filing which mean almost nothing to you I or a lamp post, and matched them up to the terms and definitions that were submitted by both parties last year in the filing “JOINT CLAIM CONSTRUCTION AND PREHEARING STATEMENT IDENTIFICATION OF DISPUTED CLAIM TERMS WITH INTRINSIC AND EXTRINSIC EVIDENCE”. I’ve then scored each definition based on whose definition “won” and got their definition for the upcoming court case in November to see who did best in the Markman Hearing Shootout.

The Plaintiff is Juxtacomm (owned by Teilhard Technologies), the defendants are IBM, Microsoft, Informatica, Metastorm, Sybase, Intersystems and Software AG, the judge is Leonard Davis – United States District Judge.

Distribution System

First cab off the rank - “Distribution System” and the “[AGREED]” in the definition shows both parties came to an agreement on the definition and neither “won” this round, so our Markman scoreboard starts off at nil all:

Judge: [AGREED] a computer system for importing data from a source computer system, transforming the imported data and exporting the transformed data to a target computer system

Script

A big win to the home team on the definition of “Script” with the judge accepting the plaintiff definition, the score becomes:

1. Plaintiff: a group of commands to control data movement into and out of the system, and to control data transformation within the system
2. Defendants: A series of text commands interpretively run by the script processor, such that one command at a time is translated and executed at runtime before the next command is translated and executed, and that control data movement into and out of the system and control data transformation within the system
3. Judge: a group of commands to control data movement into and out of the system, and to control data transformation within the system

This was the BIG ONE – a definition of a script could have implication over what type of programs this patent covered. In the original joint claim construction both parties had evidence to support their definition and 12 pages of the 30 page document was spent on the defendants describing script. They lost, but this is half the battle, the other half is working out what a “group of commands” really is and specifically whether it covers the programs produced by the most popular data integration tools on the market such as DataStage and PowerCenter that do not have scripts but have a visual design interface.

For example, in other court filings Juxtacomm says:

“[t]he scope of the claims of the ‘662 patent properly include all types of scripts, including graphical (visual) scripts,” and “[t]here is nothing in the intrinsic evidence limiting scripts to text-only scripts

But in reply Microsoft (who has three visual design tools under attack) says:

JuxtaComm cites no dictionaries or scientific treatises that demonstrate one of skill in the art at the time would have considered these visual presentations “a group of commands” (JuxtaComm’s own construction for the term “script”).

So we may need the full report from the judge to decide this one.

Script processor:

Another win to the plaintiff with the judge taking a broad definition of script and script processor:

1. Plaintiff: software that processes a script
2. Defendant: a software component that interpretively runs scripts by translating and executing one script command at a time at runtime, before translating and executing the next script command.
3. Judge: software component that processes a script

Metadata Database

The defendants finally get on the scoreboard but only after the Plaintiff concedes the point:

1. Plaintiff: a database that contains metadata
2. Defendants: “a database that stores definitions of the logical import and export data interfaces, data transformation rule sets and scripts used by the system
3. Judge: [Agreed] a database that stores the logical import and export data interfaces, data transformation rule sets and scripts used by the system

This is a relief to any company out there with a metadata database that has nothing to do with data integration! As I have said in the past the broad definition of metadata database covers about half the database in existence as something as simple as a lookup table could be considered metadata.

Data Bag

I think both parties were saying the same thing but in different ways but a technical win to the Plaintiff.

1. Plaintiff: a data structure that is stored in non-persistent memory, is created by the script processor and exists while the script is running, and contains both generic format data and definitions of that data
2. Defendant: A single container in non-persistent memory containing both the generic format data and definitions of that data, created by the script processor and existing solely in non-persistent memory while a script is running
3. Judge: [AGREED] a data bag is stored in non-persistent memory, is created by the script processor and exists while the script is running, and contains both generic format data and definitions of that data

Data Transformation Rule Sets

On a roll the Plaintiff takes another one and spectators are beginning to file out of the ground to avoid the traffic jam in the car park:

Plaintiff: a collection of rules for transforming data

Defendant: A collection of rules used to transform a data bag in one format into another data bag of a different format

Judge: a collection of rules for transforming data

Rule

It’s getting real messy now. We are in junk time and the plaintiff lawyers are making trick shots:

1. Plaintiff: one or more statements
2. Defendant: one or more statements that are executed from top to bottom to perform a specific operation to achieve a Plaintiff's Intrinsic and Extrinsic Evidence: desired result.
3. Result: one or more statements

There we go with that top to bottom stuff again – the defence team are obsessed with top down scripts and it has failed to take hold in any definition.

Systems Interface

You really can’t blame the defence team for losing this so badly, after all they only had about 100 lawyers working on it:

1. Plaintiff: an interface to the distribution system
2. Defendant: A component that enables a user to interact with the system and create definitions required by the system
3. Judge: an interface to the distribution system

Utilizing Metadata from a Metadata Database

Even my three year old daughter knows the definition for this one, nice try defendants:

1. Plaintiff: using metadata from a metadata
2. Defendants: Accessing the logical import and export data interfaces and data transformation rule sets from the metadata database during execution of a script
3. Judge: using metadata from a metadata database

Final Tally

Plaintiff 7, Defendants 1. I’ve left out four more “Data Bag” derivative terms that had simple and agreed on definitions that neither party argued about and the phrase “rule set processor responsive to said script processor” that wasn’t in the original joint filing so I don’t know who won that one (I’m guessing it was the Plaintiff!)

So a good result for Juxtacomm and Teilhard Technologies. We need to wait to see the full report from the judge to see how strictly the patent will be adhered to but based on the term definitions so far there remain a lot of products that Juxtacomm can sue – and not just ETL products. The defendant was fighting an uphill battle on these terms, the judge is not an IT specialist and has to take into account a November jury of people who know next to nothing about this technology so we see the simpler definitions preferred over the specific ones.