e.Digital does not populate a link list to build a file as antisipated by MSFT years ago.

e.Digital builds a stream of independent DISCRETE !!!!!! data pieces that do not constitute a typical file. The word discrete was used in the patent to differentiate and is ignored.

A stream of this discrete data can be read back as a typical complete file that MSFT anticipates....however it does not end there.

MSFT file: (address)A(segment)----->B(segment)------->C(segment)-------->D(segment)------>E(segment)

In the above MSFT connects (or points > a link list of elements) ABCDE as a complete file with A having initial address locator.

The only thing that can be READ BACK from the accumulated link list is ABCDE Period. MSFT cannot, with its initial considerations, READ BACK a single letter by itself because the data segments are not DISCRETE data segments or indipendent addressed files.

e.Digital discrete segments: (address)A(segment)-----(address)B(segment)-------(address)C(segment)--------(address)D(segment)------(address)E(segment)

note I removed the > yet we appear to be link list...

e.Digital, can read back any segment , combination of segments or all the segments as MSFT anticipated. e.Digital can edit new discrete data segments between the above discrete segments.....in any way shape or form.

They seem similar, as link lists go, however they are very much different as link lists go...and whatever language used cannot be considered to be twisted to avoid anticipation of link list, and whatever words are used to broaden the specification teachings (example above) into the claims can not be considered to be twisted to find infringement, because the use of the teaching can do many, many things beyond simple link list file constructions.

doni