Silicon Investor (SI) -- The First Internet Community

STOCKTALK

We've detected that you're using an ad content blocking browser plug-in or feature. Ads provide a critical source of revenue to the continued operation of Silicon Investor. We ask that you disable ad blocking while on Silicon Investor in the best interests of our community. If you are not using an ad blocker but are still receiving this message, make sure your browser's tracking protection is set to the 'standard' level.

Strategies & Market Trends : Booms, Busts, and Recoveries -- Ignore unavailable to you. Want to Upgrade?

To: Ilaine who wrote (6731)	8/6/2001 12:25:26 PM
From: Arrow Hd.	Read Replies (1) \| Respond to of 74559

Just visiting here and saw what I consider to be an interesting topic. Sorry for the length. I tend to agree more with your thoughts than those who may disclaim the patent strategy. On the premise that intellectual property is one of the battlegrounds of the 21st century, and with the fact that hardware is more and more a simple commodity (common chip sets, etc.) then software is the true implementor of the system design in a Specified Operating Environment (SOE is the total system encompassing hardware, microcode, operating systems and applications). I would protect software every way I could. --Patents: As you pointed out, much software is a process. Microcode is imbedded software that implements the hardware and provides the interface to the operating system at the external user interface. It facilitates a process and at least the process and its tips and techniques should be patented. Microcode is where a huge amount of the intellectual property resides. A patent on the code itself is a good question since the registration and notice process may require disclosing the actual code. I don't know this answer but disclosing the code would be unwise so I would stick to patenting the process and protecting the microcode as part of process's patent. Contractually, since microcode is below the external user interface and under its hardware design points, it is part of the hardware terms and conditions, business practices and contract documents. --Copyright: Protection here is not as clear as would seem. Certainly all software, including microcode, should be copyrighted. But laws on a global basis are not adequate and courts will not allow defending copyrights if the company is being abusive and/or hiding behind the copyright (IBM vs: AMI where the question of pricing a refresh of microcode was tried). So copyright is just one step. --Licensing: For a long time companies have licensed software such that there is no title transfer, just a fair use license to one copy (and an emergency backup copy maybe), later to become object code only. In the late 80s, as more of the intellectual property moved into the microcode, licensing of the microcode (known as LIC, Licensed Internal Code) became popular in mainframes. This was done to provide another layer of protection. The Ts and Cs provided no end user flexibility (you can't copy, adapt, modify, reverse compile, experiment, etc.) and even companies with anti-trust consent decrees such as IBM were allowed to implement these strategies since the protecting of the intellectual property did not impact competition at the machine level which is the level of trade at which hardware companies operate. If challenged, there was always the OEM level of trade where the complainant could be engaged. --Encryption: Finally, assuming there are crooks out there who would ignore copyright and licensing terms, encryption was implemented to prevent the stealing of code. The important issue here is not the ability to see the code but to misappropriate the code that resides within the machine as resident code that is not implemented. For example, the efficient cost/expense model in building a mainframe is to build one machine. The machine will have one Multi Chip Module installed with all 12 engines on the chip. The end user selects how many engines they need, contracts as such, pays the price based upon K per MIP, gets LIC to run only those engines, and everyone is happy. This works because chips are cheap but MCMs, system design, and multiple manufacturing lines are not. What if the code was compromised and the end user (or leasing company owner) figured out how to turn on additional engines without going to the manufacturer? The entire revenue model for this product is destroyed. Surely the copyright/licensing argument would be pursued but the dollar opportunity is so large that certainly in some countries (China for instance) this abuse would be whole-scale. So encryption, along with knee-capping system performance if any abnormalities are detected by the microcode, is how hardware and more commonly now, software companies, are protecting their intellectual properties. And, as you pointed out in your example, these encryption routines are a process and have been patented. So in combination, this microcode subsystem has been patented, copyrighted, licensed, contractually engaged and encrypted for safe-keeping. They're taking no chances on this battleground.