BM 725- item and tab density

July 24, 2006

Panglozz

The Mark James Exhibit list (IBM-725) contains "traffic analysis" information that corroborates the IBM claim that essential information is lacking in the allegations.

The exhibit list consists of "Items" and "Tabs". The "items" correspond to allegations, and the tabs can be inferred to represent supporting evidence.

The Exhibit list interleaves sealed Allegation Item #'s and sealed Tab #'s. The Tab numbers bear a logical relationship to the evidence the allegations are supported by. i.e. Item 1 is likely supported by 2 tabs and IBM briefs report that 2 files (AIX and Sys V) are presented by evidence. Item 3 cites 4 files and the tab numbers jump by 4.

Inclusive of Items 6 and 109, the Tab overrun compared to the Item integer stays at 9 or 10. This means after item 3, SCOX has not provided multiple files for these items in its final disclosure. In other words the supporting "evidence" consists of a single item-- no comparison between protected and Linux files is made.

In the James declaration items 55, 63, 84 have tab numbers that are well advanced-- and whose jump interval tie these items back to relationship with allegations 146 and 232 (which are known from descriptions in the brief).

The Item/tab correlation takes a jump from a leading 10 to 24 between allegation 109 and 252-- indicating there are multiple files presented somewhere in that broad interval.

The next jump (between 252 and 279) correspond to the 34 patents IBM describes as being attached to Item 271.

In conclusion, the manner in which the "tab" value tracks what is known of the supporting documentation supports the IBM and Judge Wells contention the documentation of infringement is lacking. Most Items can only possess a single piece of evidence, no side by side comparisons are available for these items.
< EOM >

1:51:18 PM


More from 725

July 26, 2006

jonathan_sizz

Folks, you will recall Panglozz' superb analysis of the tab numbers in 725 (SCO's exhibit list).  He noticed that 725 gives us sufficient tab numbers to reverse engineer the whole sequence, and that the tab numbers can be used to infer how many attachments of supporting evidence there are for each Item - hence its specificity, and how many files of code it implicates.  I hereby name this number the 'Panglozz Metric'.  Strangely (ha ha) it would appear that almost all the Items have a Panglozz Metric of exactly 1.

One Item between 47 and 52 must have no tabs at all, or at least share with another Item.

Assuming two tabs (PM=2) for each of the STREAMS items -- 150 to 164, "line-for-line code copied from System V" -- then the gap from Item 109 (tab 119) to Item 241 (tab 265) is nicely filled, with a surplus of just one tab. If we assume that the horribly inspecific Item 165 has no tabs at all (PM=0: note that Rochkind doesn't claim a Linux file), the tab numbers work out exactly.

Items 205 to 231, which also purport to be "line-for-line code copied from System V into the Linux kernel", have PM=1. 

Assuming Item 271 is PM=34 (it attaches 34 IBM patents), there are probably 13 tabs for the four ELF items 272-275.

On an unrelated matter, there's one interesting subliminal snippet in 725. Martin Bligh was deposed on 16 Jan 2006. Apart from the fact that this is astonishingly late for someone who was surely one of IBM's leading Linux contributors, it would appear that SCO are attempting to use deposition testimony taken after the Final Disclosure to shore up the Final Disclosure's specificity.  Tsk.

< EOM >

5:54:23 PM


Re: More from 725

July 26, 2006

monsieur_bobo

[ it would appear that SCO are attempting to use deposition testimony taken after the Final Disclosure to shore up the Final Disclosure's specificity.]

I wonder if that was intentional to give them some basis for appeal? The logic would be that pretty early on, they were aware that their 'astonishing lack of competant evidence' had not become any less astonishing, they defered Bligh until after close of discovery in order to later claim that they *would* have had some evidence if only they had gotten a road map from Bligh earlier, but due to IBM's misdeeds, and mistakes made by the court, they didn't get to him until after close of discovery.


< EOM >

6:23:40 PM 


Re: More from 725

July 26, 2006

sk43999

"Martin Bligh was deposed on 16 Jan 2006....it would appear that SCO are attempting to use deposition testimony taken after the Final Disclosure to shore up the Final Disclosure's specificity."

The close of fact discovery (except related to defenses) was Jan 27, so
presumably the deposition was allowed, provided it was not used to introduce new
misused materials - e.g., it could be used to support the merits of a particular
claim. However, I think you are right that they want to use it to provide
specificity at a time when SCO is past the deadline for doing so. Although
others on this board disagree, I think BSF and SCO were overloaded going into
the December deadline, and they ended up falling behind on collecting
depositions, which they are now trying to cover up for now.

< EOM >

7:14:10 PM


Re: More from 725

monsieur_bobo

July 26, 2006

[I think BSF and SCO were overloaded going into
the December deadline, and they ended up falling behind on collecting
depositions,]

I find that really difficult to believe. They must have known from day 1 of this fiasco who from IBM had posted to LKML, and had a pretty good idea who it as from Sequent that worked on RCU and NUMA - they had published papers on these topics. It isn't plausible that they would decide to wait until the very last second to depose the guys that could give them the 'roadmap' that they were crying in court that they absolutely needed to have.
< EOM >

7:19:37 PM


Re: More from 725

sk43999

July 26, 2006

"I find that really difficult to believe."

Why? Ultimately it is a people and resources issue. There are ~6 attorneys
actively working on SCO/IBM. Some come and go, but the total number is about
the same. All are also working on SCO/Novell. Some may be working on yet
other cases. To what extent do they control their workload? The CMVC
repository was delivered in May, 2005. BSF would have wanted time to digest
it before summoning people for depositions, so presumably that was their
intention (LKML not withstanding). Oops, Novell dumped it load of
counterclaims on SCO at the end of July, 2005, which must have demanded a lot
of time from SCO and attorneys to prepare responses and come up with additional
claims, all at the same time they were preparing and finalizing the list of
allegedly misused materials against IBM. Maybe BSF asked them to take on yet
other work, maybe work was dangled in front of their eyes with big $$
atthached, and they were unable to say NO. Best intentions not withstanding,
work on SCO/IBM slips to the point that deadlines are missed.

I have no idea that the above actually happened, but I've seen the
equivalent happen before. Not difficult to believe.

< EOM >

8:57:43 PM


Source: Investor Village SCO Board [ http://www.investorvillage.com/smbd.asp?mb=1911 ]

Copyright 2006