e.Digital Corporation (fka EDIG)

[cksla]

Posted by: Tinroad
In reply to: None Date: 2/13/2002 6:12:50 PM
Post # of 11559

A supposition that's costing me some sleep... (from Jan 18th, 2001)

The way I see it, the non-standard file structure used by MicroOS would render data files created/assembled via MicroOS (in non-sequential but not necessarily non-contiguous blocks internally linked via header-embedded and possibly key-encrypted last/next pointer data) manageable but unusable by normal FAT-based file managers. The FAT disk mgmt system used to track file locations could be used to track what physical locations are in use by MicroOS files, but wouldn't necessarily have the ability to read their data in the proper, sensible sequence. That task would be done via a MicroOS kernel, using the MicroOS block header info (and a unique decoding key if desired/needed for security reasons) to determine the proper assembled sequence for the blocks comprising the file.

Without the MicroOS file manager, DOS/Windows/ etc could see and manage the files, (FAT knows where they are) but not successfully retrieve the contained data in the sequence needed by an application (FAT manager alone doesn't know the correct block sequence). Several layers of security are thus provided. Then again, maybe I'm making something out of nothing; that's why I need feedback from folks acquainted with the real facts re file mgmt/storage techniques & practices.

* * * * * * * * * * *

Reply from an programmer at Microsoft-Redmond...

"Thanks for the clarification and thus your premise is entirely feasible. Much of the file system in Windows is very abstracted from the hardware, so as long as MicroOS maintains the same interfaces to the FAT table then the actual file data can be anything. Also the MicroOS can use Windows installable file system -- like Unix. In fact, DataPlay uses this technique to enable their drive and my guess is that the MicroOS is serving as the underlying interface. Also the MicroOS can fit as a device driver. Or as Jimee pointed out replace the entire file system and be compiled directly into the kernel. I'm not familiar with the specific security aspects of the MicroOS but it is quite possible to use the MicroOS to replace part of all of another OS's file system -- thus the DOS2MOS as you and Haiyaku often allude. Once again I cannot absolutely say that VedaLabs is using the MicroOS but I'm beginning to clearly see why you are losing sleep."

* * * * * * * * * * * * *

OK, if you have absorbed and understood the above technobabble, understand the MicroOS base patent, and are aware that virtually ALL of the installed base of PCs uses one form or another of the standard FAT12, 16 or 32 file management systems, try rereading my original 'Sleepless' posts...

http://ragingbull.lycos.com/mboard/boards.cgi?board=EDIG&read=581952
http://ragingbull.lycos.com/mboard/boards.cgi?board=EDIG&read=581994
http://ragingbull.lycos.com/mboard/boards.cgi?board=EDIG&read=582014

Unless everyone at EDIG, INTC, ITRU, LQID, RNWK, SDMI, TXN, CRUS, etc is asleep at the wheel, some or all of MicroOS' patented technology might well have crept into the secure file protection/processing/distribution chain. If so, 'Global Standard' is not an unrealistic goal.

An addendum...

I see the possibility of locking content by encrypting the last/next pointers used by MOS via proprietary algorithm/key code, maybe licensed from Verance or someone else & grafted onto the MOS kernel. The same code would be used by the content distributor to generate the secure files to be distributed.

It was pointed out to me that the FAT systems also use last/next pointers in their block headers, just as MicroOS does. However, as I envision it, this external stuff would be added over the underlying MOS headers, which would just be regarded/treated by the FAT system as pure data, rather than headers appended to blocks of data. Only the MOS would see them for what they actually are (after the FAT system retrieves the raw data file from disk). When you transfer the PC-resident files to a portable device, the FAT headers are discarded, leaving only a pure MicroOS-based file to be processed by the device itself, leaving behind all the excess baggage and overhead requirements inherent to FAT-based file management. Needless to say, in the area of direct transfers to portables/mobiles from satellite/wireless transmissions or broadband cable modems, the FAT attributes/overhead aren't needed at all.

* * * * * * * * *

Caveat to the impatient:
I wouldn't count on any significant revenues from potential EDIG involvement in secure downloads, satellite radio or DataPlay disk mastering until those respective markets develop. This remains a highly speculative stock, although the sufficiently diligent already know that. If you go overboard on diligence, try not to miss the forest for the trees. (I certainly hope I haven't.)

* * * * * * * * *

A PS request: Please don't pester EDIG with attempts to ascertain whether or not they are using MicroOS as an encryption tool as I have speculated above. I briefly flew the matter by Robert and was totally stonewalled, not even a "no comment". Take it from a former military crypto gear repairman; such matters are never discussed with those not having a need to know.

Best wishes,
Tinroad

A later follow-up from a fellow long:
"I recall 'Mike' (I will call him that ) was indeed a senior DataPlay engineer. He spoke very highly of what EDIG had done for DataPlay. He talked about how they had 'Universal', or one of the other record company tied up, by hiring of a major record company agent who brought them in the 'fold' He then talked about the DataPlay disk, saying that they would sell that small disk for $10.00 dollars or less, with a CD already encoded on the disk. Then, the disk owner would have the option of logging on to their site, and for payments made he would be able to download more songs on to the disk that he had bought. It was at this stage that DataPlay would use a "KEY" to unlock the 'gate' which EDIG had helped put in place on the disk. That 'gate' is most certainly "another" use of MOS to permit 'secure' downloading of music from the internet."

An even later follow-up:
The stashing of portions of the MicroOS in silicon (via the Actel programmable gate array deal) only serves to enhance the security of MicroOS as a means of rendering files inaccessible without the proper hardware/software.

* * * * * * * * *

Disclaimer: None of my conjectures and speculations are to be taken as fact. Neither do I have any way to verify any of the anecdotal statements and opinions quoted above; they should also be construed as conjecture rather than as fact. Do your own DD before making any investment decision. I am a shareholder in e.Digital.