Page

I. INTRODUCTION *

II. RESPONSE TO MICROSOFT¹S "STATEMENTS OF UNDISPUTED FACTS" *

II. STATEMENT OF ADDITIONAL MATERIAL FACTS *

IV. SUMMARY JUDGMENT STANDARD *

V. ARGUMENT *

VI. CONCLUSION *

Page

Plaintiff Caldera, Inc. respectfully submits this Memorandum in Opposition to the following three motions:

1. Defendant¹s Motion for Partial Summary Judgment on Plaintiff¹s "Predisclosure" Claim ("Microsoft¹s Beta Blacklist Memo.");
2. Defendant¹s Motion for Partial Summary Judgment on Plaintiff¹s Alleged "Intentional Incompatibilities" ("Microsoft¹s Intentional Incompatibilities Memo."); and,
3. Defendant¹s Motion for Partial Summary Judgment on Plaintiff¹s Claim of "Perceived Incompatibilities" ("Microsoft¹s AARD Code Memo.").

1. INTRODUCTION

By the late 1980s, Microsoft¹s computer desktop operating system, MS-DOS, was a monopoly "gold mine," upon which Microsoft relied for the majority of its profits. Starting in 1988, DRI, and later Novell, threatened Microsoft¹s DOS monopoly by releasing successive versions of DR DOS, its competing operating system, that were both better and cheaper than MS-DOS. Microsoft responded by engaging in the pattern of predatory acts alleged in Caldera¹s First Amended Complaint.

A key component of Microsoft¹s anticompetitive scheme was to persuade the market that DR DOS was incompatible with Microsoft Windows. Windows was, by all accounts, the single most important application for any DOS to be capable of running during this time period‹and Microsoft knew it. Microsoft also knew that DR DOS was fully compatible with Windows 3.0. Microsoft undertook a plan to ensure that DR DOS would not be fully compatible with the next major release of Windows, Windows 3.1‹and that the market would know it‹by:

• Announcing publicly that DR DOS would not be compatible with Windows 3.1 (See Statement of Additional Material Facts, ¶¶ 22-25, below);
• Blacklisting DRI from the Windows 3.1 beta program, in order to guarantee DRI would not be able to fix incompatibilities during the lengthy, well-publicized Windows 3.1 beta cycle (see id., ¶¶ 26-37); and,
• Coding software incompatibilities between Windows 3.1 and DR DOS including code that prevented users from setting up Windows on DR DOS, code that specifically detected DR DOS and then refused to run, and code that displayed false error messages when it detected DR DOS‹and Microsoft blamed these problems on DR DOS (see id., ¶¶ 38-76).

Each of these predatory acts contributed to creating fear, uncertainty and doubt that DR DOS could not run Windows 3.1 and future versions of Windows. And each act reinforced the other related acts. In combination, these acts materially contributed to eliminating DR DOS as a viable competitor in the desktop operating system market.

Microsoft attempts to "divide and conquer" Caldera¹s Section 2 claim by making separate motions for partial summary judgment directed at each related aspect of Microsoft¹s predatory conduct. Apparently, Microsoft hopes that if each bad act is viewed in isolation the nature of its scheme will not be obvious. In any event, the Tenth Circuit has rejected defendants¹ attempts to take a piecemeal approach in considering Section 2 claims:

Aspen Skiing Co v. Aspen Highlands Skiing Corp., 738 F.2d 1509, 1522 n.18.

This Memorandum summarizes evidence‹much of it out of the mouths of Microsoft¹s senior executives‹that proves Microsoft engaged in a carefully planned and coordinated series of acts which were intended to, and did, exclude DR DOS as a competitor in the desktop operating system market. If Microsoft is correct, i.e., if Microsoft is entitled to summary judgment on Caldera¹s Section 2 claims, then that means the law permits a monopolist to exercise its market power in one market to foreclose competition in another by: secretly making its product incompatible with its competitor¹s complementary product; blaming the incompatibilities on its competitor; precluding the competitor from access to the product causing the incompatibility; and, hiding all of this conduct by doing things such as encrypting code and secretly disabling tools that would help in uncovering the predatory conduct. The Sherman Act does not, and never has, permitted this sort of anticompetitive conduct and Microsoft offers no good reason this Court should permit it.

Microsoft has unlawfully maintained its monopoly by use of exclusionary conduct that does not "further competition on the merits or does so in an unnecessarily restrictive way." Aspen Skiing Co. v. Aspen Highlands Skiing Corp. 472 U.S. 585, 605 n.32 (1985). Its summary judgment motions should be denied.

1. RESPONSE TO MICROSOFT¹S "STATEMENTS OF UNDISPUTED FACTS"

Caldera responds to Microsoft¹s numbered paragraphs as follows:

1. In response to paragraph 1, Caldera admits that DRI developed DR DOS and that DR DOS competed with MS-DOS from 1988 through 1994.
2. Caldera denies paragraph 2. Microsoft suggests that DRI was contemplating developing a Windows competitor when DRI requested to participate in the Windows 3.1 beta program. The facts are otherwise. In late January 1990, DRI and ASCII Corporation of Japan, a long-time partner of DRI, jointly undertook a study to determine the feasibility of developing a graphical user interface ("GUI") that could compete with Microsoft¹s evolving Windows product. See Deposition of Stephen Tucker ("Tucker Dep.") at 97, Record Support, v.4 to Consolidated Statement of Facts. Caldera and ASCII Corporation commenced and conducted the study, named "Cutlass," taking great care to prevent any legal challenges by Microsoft based on DRI¹s participation in the Windows 3.0 beta program. Deposition of Phil Balma ("Balma Dep.") at 106, attached as Ex. 1 to the Declaration of Lynn M. Engel ("Engel Decl."); Tucker Dep. at 113-15, Record Support, v.4 to Consolidated Statement of Facts. The majority of the Cutlass Study work was completed over a 2-3 month period in 1990. See id. at 135. Cutlass was strictly a feasibility study and did not result in the development of a product, or even a prototype. See id. at 161. The final report, entitled "Cutlass Feasibility Study" and circulated in March 1991, concluded that developing a product to compete with Windows was not a viable strategy for DRI due to the substantial expense and "moving target risk" of such an undertaking. Engel Decl., Ex. 2 at 1-1; Ex. 16 to Microsoft¹s Beta Blacklist Memo. Thus, well before it requested participation in the Windows 3.1 beta program, DRI had considered and rejected the idea of developing a Windows competitor. As an alternative to competing with Windows, Dick Williams, DRI¹s President and CEO, decided that DRI¹s primary course should be "to the best of our abilities, [to] cooperate with Microsoft. . . . I believed that the best of all worlds would be for the Windows product with Microsoft to be broadly available, and available to Novell such that we could fully support it. That was number one." Deposition of Dick Williams ("Williams Dep.") at 245, Record Support, v.4 to Consolidated Statement of Facts. Having decided not to challenge Microsoft head-to-head in the GUI market, DRI soon learned that cooperation with Microsoft, even where DRI posed no direct threat, was not an alternative. In July 1991, Microsoft placed DRI on its beta blacklist; in August 1991, when DRI formally requested to become a beta site for Windows 3.1, Microsoft denied the request. See Consolidated Statement of Facts ¶¶ 205-209. Later, in March 1992, having learned the hard way that Microsoft was intent on ensuring that Windows would not work with DR DOS, DRI (which by then had merged with Novell), considered a project that would have made Apple¹s GUI work on Intel computers. See Tucker Dep. at 248-49, Record Support, v.4 to Consolidated Statement of Facts. The project was abandoned before a marketable product was ever developed (a decision largely influenced by Apple¹s unwillingness to proceed). See Tucker Dep. at 255, Record Support, v.4 to Consolidated Statement of Facts.
3. In response to paragraph 3, Caldera admits that Microsoft decided wrongfully to exclude DRI from the Windows 3.1 beta test cycle. Microsoft suggests that DR DOS was a "competitor" to Windows, and that this was the reason for the beta blacklist. Caldera denies this statement. DR DOS did not compete with Windows 3.1; in fact, DR DOS worked in conjunction with Windows 3.1. See Deposition of Paul Maritz ("Maritz Dep."), Record Support, v.2 to Consolidated Statement of Facts at 117. The decision to exclude DRI from the Windows 3.1 beta test cycle was to thwart DR DOS¹ ability to be compatible with Windows 3.1 when it was released, and to spread fear, uncertainty and doubt to that effect. See Consolidated Statement of Facts ¶¶ 201-210.
4. Caldera denies paragraph 4. Windows 3.1 was not an "operating system," but required MS-DOS or DR DOS to run. Windows 3.1 was in many respects nothing more than an add-on to DOS. See Consolidated Statement of Facts ¶ 210. DRI sought to ensure DR DOS was compatible with Windows 3.1; Microsoft sought to thwart that goal and instill fear, uncertainty and doubt in the industry about DR DOS¹ compatibility with Windows. Caldera denies that the purported "operating system competitors" listed by Microsoft were placed on the beta blacklist for reasons having anything to do with direct competition with Windows. Microsoft provides no details or evidence to support its assertion with respect to those particular companies. Caldera has abundant evidence that Microsoft widely implemented the beta blacklist to retaliate against perceived industry enemies, and to retaliate against anyone supporting or promoting DR DOS in any way. See Consolidated Statement of Facts ¶¶ 285-91 & 375-82.
5. Caldera denies paragraph 5. Microsoft asserts a conclusion of law drawn from disputed facts. Microsoft relies heavily on the testimony of Toby Corey, but Mr. Corey was not the person most knowledgeable about this issue. The people most knowledgeable about this issue, i.e., the key developers at DRI (John Constant, Roger Gross and Andy Wightman), set forth facts that flatly contradict Microsoft¹s assertions here. Those facts are confirmed in documents‹indeed, a document Microsoft itself relies on sets forth a chronology that confirms the testimony of Mr. Constant, Mr. Gross and Mr. Wightman. See Exhibit 11 to Microsoft¹s Intentional Incompatibilities Memo. at 3 (May 7, 1992, memo from John Constant to Sturge Sobin). First and most important, DRI did not obtain a pre-release copy of Windows 3.1 until March 18, 1992, just three weeks before the commercial release of Windows 3.1. See id at 3; see also Deposition of John Constant ("Constant Dep.") at 30, Record Support, v.3 to Consolidated Statement of Facts. This release was not a beta release‹it was an engineering release that was a candidate for commercial release‹and the DRI developers never obtained a copy of the Windows 3.1 beta. See id. at 30; see also Deposition of Roger Gross ("Gross Dep.") at 138 (never had a beta release), attached as Ex. 3 to Engel Decl.; Deposition of Andrew Wightman ("Wightman Dep.") at 142, attached as Ex. 4 to Engel Decl. Moreover, by the time the DRI developers received this disk, the beta program had run for nine months and had been completed. Earlier, on February 18-19, 1992, Mr. Wightman had attended a Microsoft Windows developers¹ conference where Microsoft blamed incompatibility problems on DR DOS, not Windows. See Wightman Dep. at 145-46, Engel Decl., Ex. 4. A week later, on February 24, a DRI engineer called Provo to confirm the existence of the incompatibilities. See Exhibit 11 to Microsoft¹s Intentional Incompatibilities Memo. at 3; see also Gross Dep. at 23, Engel Decl., Ex. 3. Shortly after that, on March 9, a customer demonstrated incompatibilities to the DRI engineers. See Exhibit 11 to Microsoft¹s Intentional Incompatibilities Memo. at 3. DRI also heard reports from its customers about problems they were having running DR DOS with the Windows 3.1 beta. Gross Dep. at 38-39, Engel Decl., Ex. 3; Engel Decl., Ex. 5. That is the extent of what happened. Finally, what is most surprising is that Microsoft would try to characterize DRI¹s conduct as illegal given that what little information DRI had about the Windows 3.1 betas was gained (i) from unsolicited customer comments, or (ii) from efforts to mitigate the effects of Microsoft¹s predatory conduct in excluding DRI in the first instance.
6. Caldera denies paragraph 6. Microsoft misquotes paragraph 53 of Caldera¹s First Amended Complaint. That paragraph states that "Novell was able to release an enhanced version of DR DOS supporting Windows 3.1 without substantial technical difficulty." (Emphasis added.) Microsoft¹s statement is misleading insofar as it implies that DRI was able to easily solve the compatibility problems between DR DOS 6.0 and Windows 3.1. DRI had to await release of the final version of Windows 3.1 to ascertain whether it had successfully remedied the compatibility problems. See Constant Dep. at 171-72, Record Support, v.3 to Consolidated Statement of Facts. Microsoft ignores the fact that the beta blacklisting itself made the task of solving the compatibility problems "substantially difficult." The beta blacklist was implemented to create fear, uncertainty and doubt in the market about whether DR DOS was compatible with Windows. Blacklisting furthered this purpose, by making it clear to the market that DRI¹s hands were tied, by allowing Microsoft to publicize the incompatibilities Microsoft created and blamed on DR DOS, and by preventing DRI from detecting and fixing the false error message and software incompatibilities Microsoft had engineered into Windows. See Consolidated Statement of Facts ¶ 214.
7. In response to paragraph 7, Caldera admits that Microsoft released Windows 3.1 for general commercial use in April 1992.
8. In response to paragraph 8, Caldera admits that Microsoft released Windows 3.0 for general commercial use in May 1990. Windows 3.0 was not, however, an "operating system" as stated by Microsoft. It was a graphical user interface that ran in conjunction with, and required, MS-DOS or DR DOS. Even the press release cited by Microsoft confirms Windows 3.0 was merely a "graphical user interface for MS-DOS and PC-DOS based personal computers." Exhibit 30 to Microsoft¹s Beta Blacklist Memo.
9. In response to paragraph 9, Caldera denies Microsoft¹s purported reasons for beginning development of Windows 3.1. Windows 3.1 was developed to fix "several thousand" problems in Windows 3.0. See FTC Deposition of Aaron Reynolds ("Reynolds FTC Dep.") at 122-23, Record Support, v.2 to Consolidated Statement of Facts. Caldera admits that DRI requested to participate in the Windows 3.1 beta program in August 1991 in order to ensure continued compatibility between DR DOS and Windows. See Consolidated Statement of Facts ¶ 209.
10. Caldera denies paragraph 10. On its face, Microsoft asserts a conclusion of law. DRI was not a "competitor" with Microsoft as to Windows 3.1. See ¶ 3, above. As a monopolist, Microsoft had a legal obligation to provide nondiscriminatory access to the Windows 3.1 beta. Caldera admits, however, that Microsoft wrongfully refused DRI access to the Windows 3.1 beta.
11. Caldera denies paragraph 11. The paragraph is misleading, for DRI and Microsoft were not "competitors" as to Windows 3.1, but only as between MS-DOS and DR DOS. DRI did not request to be an MS-DOS beta site; instead, DRI requested to be a Windows 3.1 beta site and in response, Microsoft blacklisted DRI. See Consolidated Statement of Facts ¶¶ 209, 380. Microsoft allowed scores of its other "competitors" into the Windows 3.1 beta cycle because they did not compete with Windows 3.1. See id. ¶ 200 n.22.
12. Caldera denies paragraph 12. Microsoft¹s snippets take Mr. Constant¹s testimony out of context. Mr. Constant testified that Microsoft denied DRI access to Windows 3.1 betas; that customers were justifiably alarmed at this discriminatory exclusion when it was reported; that DRI was unable to reassure the market that compatible versions of DR DOS would be available upon the release of Windows 3.1; and that, in fact, DRI was not able to release its patch until after Windows 3.1 shipped and DRI was able to test all of its work on the final product. See Constant Dep. at 163-64 & 171-72, Record Support, v.3 to Consolidated Statement of Facts.
13. In response to paragraph 13, Caldera admits that DRI had limited access to information about the Windows 3.1 beta releases. Caldera denies that any such access was "illegal." See ¶ 5, above. The only "illegal" conduct was that of Microsoft, as an entrenched monopolist, seeking to eliminate competition in the DOS market by leveraging its uncontested monopoly power in the market for Windows.
14. Caldera denies paragraph 14. See ¶¶ 5 & 13, above. The cited provision of the Novell nondisclosure agreement in no way suggests that what Novell engineers did was contrary to those terms. Microsoft¹s cited testimony of Mr. Constant does not support its assertion that Novell violated its NDA. In any event, Microsoft seeks to draw a legal conclusion based on disputed facts. Moreover, Microsoft itself chose not to enforce the NDAs, for the trade press was reporting‹publicly‹problems encountered running Windows 3.1 with DR DOS. See Exhibit 254  to Consolidated Statement of Facts; Exhibit 23 to Microsoft¹s AARD Code Memo.
15. Caldera denies paragraph 15. See ¶¶ 5 & 13, above.
16. In response to paragraph 16, Caldera admits that DR DOS developers discussed the Windows 3.1 beta problems with Novell engineers, but by that time the damage had already been done to DR DOS¹ reputation for Windows compatibility. See ¶ 5, above. Microsoft had blacklisted DRI in mid-1991; Microsoft released Windows 3.1 some eight to nine months later, on April 6, 1992; DRI was not able to begin, much less complete any efforts to uncover the problems Microsoft had created until March 1992, just weeks before the April 6, 1992, release date. See, e.g., Engel Decl., Exs. 6 & 7.
17. Caldera denies paragraph 17. See ¶¶ 5 & 13, above. To the extent Microsoft asserts DR DOS engineers tested DR DOS with Windows 3.1 within a few weeks of the end of the beta test cycle, Caldera admits this. That, of course, is the legitimate purpose of a beta test cycle. Microsoft¹s statement is misleading, though, for it suggests that testing occurred throughout the beta cycle. It did not. See ¶¶ 5 & 16, above. Thus, Microsoft¹s campaign to create fear, uncertainty and doubt was a success. And Novell still was not ready with fully-tested DR DOS patches at the time Windows 3.1 was released. See ¶ 18, below.
18. Caldera denies paragraph 18. See ¶¶ 5, 13 & 17, above. Microsoft presents no evidence that Novell or DRI had to "reverse engineer" Windows 3.1 to achieve DR DOS compatibility. Furthermore, Mr. Constant¹s testimony is clear that full compatibility was thwarted by the beta blacklist until after Windows 3.1 was commercially released. See Constant Dep. at 171-72, Record Support, v.3 to Consolidated Statement of Facts.
19. Caldera denies paragraph 19. Microsoft overstates the content of Mr. Constant¹s declaration. The declaration is unclear whether the code was shipped before Windows 3.1 was released or shortly thereafter. Moreover, damage to DR DOS had already occurred by the time a fix was coded. Press reports of problems caused by the Nested Task Flag bug had been circulating for at least six months by that time. Exhibit 257 to Consolidated Statement of Facts.
20. Caldera admits paragraph 20, but notes that by that time, Microsoft¹s blacklist/FUD campaign had been successfully creating fear, uncertainty and doubt about DR DOS/Windows compatibility for at least nine months.
21. Caldera denies paragraph 21. See ¶¶ 5 & 13 above. Microsoft¹s statement is surprising in two respects. First, nothing suggests that DRI¹s limited access to information late in the beta cycle was in any way illegal. See ¶ 5, above. Second, DRI did not "gain[] an illegal advantage"‹it simply tried unsuccessfully to mitigate the harm it was suffering as a result of Microsoft¹s illegal conduct.
22. Caldera denies paragraph 22. Microsoft¹s campaign to create fear, uncertainty and doubt about DR DOS compatibility with Windows‹by blacklisting DRI, by introducing incompatibilities, by creating false error messages, and by publicizing these facts‹prevented DRI from competing "based on its own innovation."
23. In response to paragraph 23, Caldera admits that Microsoft spent money developing Windows and MS-DOS. It is worth noting, however, that Microsoft¹s statement is misleading, in that it refuses to acknowledge the distinction between Windows 3.1 and MS-DOS, and that DR DOS competed only with MS-DOS.
24. Caldera denies that paragraph 24 is a complete description of DR DOS. DR DOS was designed to be both compatible with and superior to MS-DOS. See Goodman Report at Exhibit C, Record Support v.6 to Consolidated Statement of Facts.
25. Caldera denies paragraph 25. See ¶ 2, above. It is worth noting that the "Cutlass Feasibility Study" recommended the project be killed in March 1991, long before the Windows 3.1 beta cycle began. See Exhibit 16 to Microsoft¹s Beta Blacklist Memo. at A0808524.
26. Caldera admits paragraph 26, except as follows: Microsoft¹s assertion that the goal was to "combine DR DOS with the GUI environment of OS/2" is misleading. Novell and DRI simply wanted DR DOS to provide a platform for OS/2, just as it already did with Windows. Microsoft overlooks the fact that the ability of DR DOS to run with the OS/2 GUI and with Windows 3.1 in fact confirms that DR DOS was not itself in competition with Windows 3.1.
27. Caldera admits paragraph 27, except as follows: Discussions with Apple regarding the "Star Trek" project began in February or March 1992. Deposition of Toby Corey ("Corey Dep.") at 44, Record Support, v.3 to Consolidated Statement of Facts. Thus, DRI did not even explore this possibility until just before Windows 3.1 was released‹and not until DRI had been improperly excluded from the Windows 3.1 beta cycle for at least seven months. By that time, it was clear that Microsoft would improperly restrict access to Windows¹ betas, and would do all it could to thwart DR DOS compatibility with Windows in the future. See Consolidated Statement of Facts ¶¶ 209 & 380; Corey Dep. at 154-55, Record Support, v.3 to Consolidated Statement of Facts. Indeed, Dick Williams, DRI¹s President and CEO, confirmed that the "number one" strategy "was, to the best of our abilities, cooperate with Microsoft . . . for the Windows product with Microsoft to be broadly available, and available to Novell such that we could fully support it." Williams Dep. at 245, Record Support, v.4 to Consolidated Statement of Facts.

1. Response to Microsoft¹s "Statement of Undisputed Facts" Regarding Plaintiff¹s Alleged Intentional Incompatibilities.

1. Caldera admits paragraph 1, except as follows: Microsoft suggests that XMS was important in order to run the Windows 3.1 setup program, but in fact it was entirely gratuitous because setup makes no use of XMS.
2. Caldera admits that Microsoft added an XMS internal revision number check to the setup program included with Windows 3.1 and that the version check routine functions the same way whether MS-DOS or DR DOS is present on the user¹s machine. (Although the XMS specification itself states that this number is "mainly for debugging purposes" and nowhere suggests that the number indicates driver capabilities.) Caldera denies that the particular XMS internal revision number check employed was either necessary or included to protect consumers. There were far less restrictive methods available to exclude possibly deficient XMS drivers. See Deposition of Michael Colee ("Colee Dep.") at 66-70, Engel Decl., Ex. 8. As Microsoft itself admits, setup itself makes no use of XMS. Id. at 18 ("Q. Does the setup program utilize services in XMS driver? A. No. Short of querying for the version number. That is the only service that the setup program utilizes."). Logically, then, Microsoft must maintain that setup is performing this check to assist some other component of Windows. According to Colee, this other component was DOSX, the standard mode DOS extender. Id. at 19. However, DOSX performs its own query for the XMS revision number, and is satisfied with 2.28 or higher. See First Supplemental Declaration of Lee Hollaar ("Hollaar Decl.") at ¶ 5. Caldera further denies that Mr. Constant¹s testimony referred to the version check at issue. He was referring instead to Microsoft¹s refusal to provide the XMS 3.0 specification to DR DOS. See Constant Dep. at 181, Record Support, v.3 to Consolidated Statement of Facts.
3. In response to paragraph 3, Caldera admits that the XMS test required internal version 2.60 or higher. Caldera admits further that an error message appeared if the test failed. Caldera denies the remedy was simple or obvious. See Section J, ¶¶ 62 & 63, below.
4. In response to paragraph 4, Caldera admits that Mr. Colee denied knowing that DR DOS returned an internal revision number of 2.50. However, Colee says he "obtain[ed] the design criteria that were to be supplied in writing this code" from a "features specification" from "product management" such as David Cole, so his ignorance of the 2.50 number probably signifies nothing. See Colee Dep. at 20-21, Engel Decl., Ex. 8. Caldera further admits that it revised the internal revision number before the commercial release of Windows 3.1. Caldera denies the task of diagnosing and remedying the problem was a "simple matter," for as Mr. Constant testified, although the change required was small, determining what change had to be made was difficult because Microsoft refused DRI access to the XMS specification and the Windows 3.1 beta. See Constant Dep. at 168-69, Record Support, v.3 to Consolidated Statement of Facts. Finally, although DRI eventually remedied the problem, it was not until late in the beta cycle after the damage had been done. See ¶¶ 5 & 16 to Response to Undisputed Facts Regarding "Predisclosure" Claims, Section II.A., above.
5. Caldera admits paragraph 5, except for the statement that setting the value of the "nested task flag to one . . . was not the behavior one would anticipate on Intel microprocessors." The statement simply makes no sense. In real-mode software such as a DOS operating system, the flag could be set to 1 or 0. As Microsoft¹s expert John Bennett states, "The NT flag has no effect on the execution of the IRET instruction when the processor is executing in real mode." Bennett Report at 11, Engel Decl., Ex. 9. Because the flag only has meaning in protected mode, it is the responsibility of protected-mode software such as Windows to set the flag as appropriate. See Hollaar Decl. at ¶ 3.
6. Caldera denies paragraph 6. The error was caused by code (to be precise, the absence of a single line of code) inside the DOSX component of Microsoft Windows 3.1, not in DR DOS. DOSX contains a software "bug": it fails to clear the Nested Task flag, instead relying on whatever value it might have received in real mode. See Hollaar Decl. at ¶ 3. Moreover, the bug created by Microsoft had no technical benefit whatsoever, and, in fact, made the product improvements it sought to include more difficult, not less difficult to implement. Id. See Reynolds FTC Dep. at 70-72, Record Support, v.2 to Consolidated Statement of Facts. It was the responsibility of Windows, not that of real-mode software, to maintain the Nested Task flag: the flag is maintained properly in other parts of DOSX and in the Enhanced mode VMM. See Hollaar Decl. at ¶ 3. See also Reynolds FTC Dep. at 70-72, Record Support, v.2 to Consolidated Statement of Facts ("I have observed at other times that basically if that bit accidentally gets set, some very bad things will probably eventually get around to happening." (Emphasis added)).
7. In response to paragraph 7, Caldera admits at the end of the beta cycle, long after DR DOS¹ reputation for compatibility with Windows 3.1 had been severely damaged (see, e.g., Barnett Report at 15, Record Support, v.6 to Consolidated Statement of Facts), DRI was able to diagnose and code a work-around for the problem. DR DOS 6 had already been commercially released; the work-around for Microsoft¹s problem appeared in an April 1992 "business update" to DR DOS 6. Microsoft never fixed the bug in its code; it was included in the commercial release of Windows 3.1. See Hollaar Decl. at ¶ 3. In June 1992, Microsoft issued a statement on "Running Windows with DR-DOS" which stated that users of DR DOS "will be unable to start Windows." It gave instructions for reverting to Windows 3.0. Engel Decl., Ex. 10.
8. In response to paragraph 8, Caldera admits that Microsoft included the AARD code in the Christmas Beta of Windows 3.1. Caldera denies the remainder of paragraph 8. The code was designed to detect the presence of DR DOS and create false error messages, which were intended to make users believe that DR DOS was incompatible with Windows. See Hollaar Report at 11 & 13-14, Record Support, v.6 to Consolidated Statement of Facts; see also Statement of Additional Material Facts ¶¶ 43-47. As Brad Silverberg, the Microsoft executive admitted:

What the guy is supposed to do is feel uncomfortable, and when he has bugs, suspect that the problem is DR DOS and then go out to buy MS-DOS. Or decide to not take the risk for the other machines he has to buy for in the office.

Exhibits 277 & 278 to Consolidated Statement of Facts.

9. In response to paragraph 9, Caldera admits that the AARD code did not modify DR DOS or prevent DR DOS from running. Caldera denies the remainder of paragraph 9. Microsoft suggests in this paragraph that generating false error messages is not an "incompatibility" for purposes of analyzing its predatory conduct under the antitrust laws. Dr. Hollaar made no such concession. He specifically limited his answer to applying a narrow definition of incompatibility that required the error to interfere with operation of the program. He stated further that under a technical definition of incompatibility, the AARD code created an incompatibility. See Deposition of Lee Hollaar ("Hollaar Dep.") at 90-91, Engel Decl., Ex. 11.
10. In response to paragraph 10, Caldera admits that Microsoft accurately quotes its interrogatory response.
11. Caldera denies paragraph 11. Mr. Dixon testified that he not only was aware of the software locks, but he witnessed the effect they had when users attempted to execute Hanguel versions of Microsoft¹s applications. See Deposition of Richard Dixon ("Dixon Dep.") at 39-45, Record Support, v.3 to Consolidated Statement of Facts. Microsoft has never produced Hanguel versions of its applications. Caldera has located, however, through third party sources, copies of Hanguel versions of Microsoft Windows 3.0 and 3.1. Both programs produce error messages telling users that they should only operate Windows on MS-DOS. See Hollaar Decl. at ¶ 7.
12. Caldera denies paragraph 12. Mr. Dixon testified that he witnessed the software locks preventing Microsoft applications from running on DR DOS. See Dixon Dep. at 39-45, Record Support, v.3 to Consolidated Statement of Facts. Microsoft seems to be suggesting that because Microsoft has been unable to produce copies of its software, the Court should ignore the testimony of a witness who saw the locks.
13. Caldera admits the first part of paragraph 13, but denies the last part. Microsoft asserts that PROTMAN.DOS was created by 3Com and merely included by Microsoft in Windows for Workgroups. Microsoft misquotes Ludwig¹s FTC testimony. According to Microsoft, "The only changes made to PROTMAN.DOS were bug fixes." See Deposition of John Ludwig ("Ludwig Dep.") at 21, Engel Decl., Ex. 12. However, Ludwig also refers to "support added for additional versions of DOS." Id. at 19. That is precisely the area that caused problems for DR DOS. PROTMAN.DOS contains a Microsoft as well as a 3Com copyright notice. Starting with version 5, the MS-DOS kernel contains special provision for PROTMAN that required close coordination with code inside PROTMAN (indeed with precisely the section of code of which Caldera complains). See Ludwig Dep. at 39-40, Engel Decl., Ex. 12.
14. Caldera admits paragraph 14 except as follows: that "DRI could have fixed this problem by having DR DOS report itself as a larger version of MS-DOS" is disingenuous. Simply reporting itself as version 5, for instance, would have produced significant problems.
15. Caldera admits that paragraph 15 accurately characterizes the cited testimony of the two witnesses identified.
16. Caldera admits paragraph 16.
17. Caldera admits paragraph 17.
18. Caldera admits paragraph 18.
19. Caldera admits paragraph 19.
20. Caldera admits that Microsoft packaged DOS and Windows together in Windows 95, and that by doing so Microsoft foreclosed DR DOS from running with the Windows portion of Windows 95. Caldera denies that Windows 95 is integrated. As Caldera shows elsewhere, see Caldera¹s Opposition to Microsoft¹s Motion for Partial Summary Judgment on Plaintiff¹s "Technological Tying" Claim, there is a fully separable copy of MS-DOS, version 7.x, contained in the Windows 95 and Windows 98 boxes. Caldera also denies that Windows 95 "performs some of the functions that MS-DOS performed for earlier versions of Windows." Windows 95 performs all of the functions MS-DOS performed for earlier versions of Windows. Although Windows may not employ them, DOS supplies them.

1. Response to Microsoft¹s "Statement of Undisputed Facts" Regarding Plaintiff¹s "Perceived Incompatibilities" Claim.

1. Caldera admits paragraph 1 except as follows: Microsoft¹s statement is misleading insofar as support expenses are dwarfed by development expenses. Microsoft itself states as "undisputed fact" that it spent "an enormous amount of money and substantial number of man-hours in designing, developing, testing and marketing Windows 3.1 and MS-DOS. See Undisputed Fact 23 in Microsoft¹s Beta Blacklist Memo.
2. In response to paragraph 2, Caldera admits that Microsoft provides telephone support to a subset of Microsoft customers. Caldera denies the remainder of paragraph 2. The statement in the exhibit Microsoft cites identifies problems created by Windows¹ incompatibilities with other products. See Exhibit 19 to Microsoft¹s AARD Code Memo. at 5. Although Microsoft would like to blame those problems on other vendors, the problems were caused by incompatibilities with Windows. Id. Furthermore, there is no evidence that DR DOS users "often contacted" Microsoft for support. Exhibit 20 to Microsoft¹s AARD Code Memo., the document on which Microsoft relies as support, shows just the opposite to be true. In June 1992, when more than three million copies of DR DOS were in circulation (Ivie Report at 32, Record Support, v.6 to Consolidated Statement of Facts), even by Microsoft¹s count support calls for DR DOS users made up about 2/3 of one percent of total calls. See Exhibit 20 to Microsoft¹s AARD Code Memo. (625 calls out of a total of 93,722 calls). Furthermore, according to the report, Microsoft spent 21,275 hours on support in June. Id. DR DOS callers accounted for 76 of those hours (which amounts to 1/3 of one percent of the time spent). Id. Moreover, Microsoft apparently used these calls not as a means of providing support, but rather as a marketing opportunity, telling callers that Windows did not work with DR DOS and that they should switch to MS-DOS. See Deposition of Jody Clifton ("Clifton Dep.") at 267-68, Engel Decl., Ex. 13; see also Consolidated Statement of Facts ¶¶ 218-29, 230 & 235.
3. In response to paragraph 3, Caldera admits that internal documents suggest that Microsoft considered including an error message in the production release of Windows 3.1 that would have appeared when users attempted to run Windows with DR DOS. However, Caldera denies that Microsoft considered putting in this message due to the "support burden." Microsoft put the false error messages in the Windows 3.1 beta in order to make DR DOS users "uncomfortable" and "suspect the problem is DR DOS and go out and buy MS-DOS." See Exhibit 278 to Consolidated Statement of Facts. Caldera admits that paragraph 3 accurately characterizes the testimony regarding user manuals and "Readme" files, and agrees that if Microsoft¹s intent was to increase the effect of the message, having it appear as an error message would cause users a high level of concern.

4. In response to paragraph 4, Caldera admits that Mr. Frankenberg and Dr. Hollaar testified that they would not have objected to a message identifying a lack of testing, but both Mr. Frankenberg and Dr. Hollaar objected to the error messages actually implemented by Microsoft as deceptive and misleading. See Deposition of Robert Frankenberg ("Frankenberg Dep.") at 320-21, Record Support, v.3 to Consolidated Statement of Facts; Hollaar Report at 13-14, Record Support, v.6 to Consolidated Statement of Facts.

5. In response to paragraph 5, Caldera admits that Microsoft tested pre-release versions of Windows 3.1 with various versions of MS-DOS. Caldera also admits that Microsoft did not devote development resources to fixing incompatibilities between Windows 3.1 and DR DOS. Rather, Microsoft devoted development resources to creating incompatibilities (and the perception of incompatibilities) between Windows 3.1 and DR DOS. See Statement of Additional Material Facts ¶¶ 41-49. Caldera further admits that Microsoft stated publicly that it did not test Windows 3.1 with DR DOS, but the statement, including the statement quoted by Microsoft ("We do no testing at all with DR DOS . . .") was plainly untrue. The statement was made in January 1992, yet in September 1991, during the Windows 3.1 beta cycle, Microsoft distributed a comprehensive DR DOS test plan, that included extensive testing with all versions of Windows. See Exhibit 184 to Consolidated Statement of Facts; see also Deposition of Brad Chase ("Chase Dep.") at 136-38, Record Support, v.1 to Consolidated Statement of Facts; Deposition of Thomas Lennon ("Lennon Dep.") at 198-203, Record Support, v.1 to Consolidated Statement of Facts (describing DR DOS testing efforts by Microsoft, including a "DR Hammerfest" intended to find DR DOS bugs, complete with prizes for those Microsoft programmers who found the most DR DOS bugs). Caldera admits that while Microsoft was blacklisting DRI from the Windows 3.1 beta program, Microsoft made public statements that it was DRI¹s responsibility to make any changes necessary to DR DOS to ensure compatibility with Windows 3.1. Yet, as described more fully below, Microsoft was creating incompatibilities between Windows and DR DOS, telling the industry that the incompatibilities were caused by DR DOS, and denying DRI access to the information necessary to fix the problems. See Statement of Additional Material Facts ¶¶ 42 & 48. See also FTC Deposition of Phillip Barrett ("Barrett FTC Dep.") at 101-02, Engel Decl., Ex. 14 (describing how the problem was with "Bambi," not DR DOS).

6. Caldera admits paragraph 6, except as follows: Windows 3.1 was not an "operating system," but required MS-DOS or DR DOS to run. See Consolidated Statement of Facts ¶ 210. Microsoft¹s description of its beta program and the purpose of the program is incomplete and inaccurate. Microsoft used the Windows 3.1 beta program not only for testing, but also for marketing purposes. See, e.g., Exhibit 24 to Microsoft¹s AARD Code Memo. at 11-12 (noting the marketing purposes underlying the beta program and reporting that only 37% of the beta sites reported problems). See also Consolidated Statement of Facts ¶ 228.

7. Caldera admits paragraph 7. See Consolidated Statement of Facts ¶ 212.

8. Caldera denies paragraph 8. The XMS version check, the Nested Task flag bug, "Bambi," and the AARD code (what Microsoft refers to as the "non-fatal error message") were all part of Microsoft¹s scheme to preclude competition in the DOS market. See, e.g., Bennett Report, Appendix F, Engel Decl., Ex. 9 (showing users encountering both the Nested Task error message ("Standard mode: Fault in MS-DOS Extender" error message) and the AARD code¹s non-fatal error message). Furthermore, these problems were created by Microsoft, not DRI. See Statement of Additional Material Facts ¶¶ 41-49, see also Caldera¹s Response to Undisputed Facts Regarding Intentional Incompatibilities, Section II.B., above.

9. Caldera admits paragraph 9, but notes the incompatibilities reported by the press were incompatibilities created by Microsoft, not DRI. See Statement of Additional Material Facts ¶¶ 41-49; see also Response to Undisputed Facts Regarding Intentional Incompatibilities, Section II.B., above.

10. Caldera admits paragraph 10, except as follows: End-users did not make up only a small subset of beta testers. As Microsoft¹s Exhibit 24 shows, of the 15,106 total beta sites, 5,607 of those sites were corporate sites‹which, of course, are end-users. See Exhibit 24 to Microsoft¹s AARD Code Memo. at 20. Another 255 sites were government sites (again, end-users of the product), and there were several other categories that appear to be end-users. Id. Thus, the single largest category of testers was end-users. See Consolidated Statement of Facts ¶ 228.

11. Caldera denies paragraph 11. As described in Exhibit 24 to Microsoft¹s AARD Code Memo., some sites returned beta applications without signed NDAs and some Windows Developer¹s conference attendees were merely handed copies of the Windows 3.1 beta at the conference without the "beta kit" containing documentation. Exhibit 24 to Microsoft¹s AARD Code Memo. at 7. Later in the beta cycle, beta testers were not required to sign NDAs, but rather were provided copies of NDAs they never had to execute. Id. Moreover, Microsoft selectively enforced the NDAs. Members of the trade press often signed the NDAs. See id. at 10. Microsoft allowed and encouraged disclosure by the trade, Engel Decl., Ex. 15, despite the NDAs, so long as the disclosure was favorable to Microsoft (as reports of Windows 3.1/DR DOS compatibility "problems" were). See Consolidated Statement of Facts ¶ 314.

12. Caldera admits paragraph 12, except as follows: The AARD code was developed by Aaron Reynolds, who had carefully researched and discovered specific differences between DR DOS and MS-DOS. See Statement of Additional Material Facts ¶¶ 44 n.4; see also Consolidated Statement of Facts ¶ 39. The AARD code was intended to detect DR DOS. See Exhibit 194 to Consolidated Statement of Facts (September 27, 1991, e-mail entitled "FYI: Windows message" and sent to Brad Silverberg and Brad Chase: "The check for dr dos better be perfect") see also Consolidated Statement of Facts ¶ 237.

13. Caldera denies paragraph 13. The AARD code was included for the express purpose of creating the impression that DR DOS was incompatible with Windows and to create enough fear and uncertainty to cause users to reject DR DOS. See Hollaar Report at 11-14, Record Support, v.6 to Consolidated Statement of Facts (explaining why Microsoft¹s excuse for the code is inconsistent with the code itself, how it was implemented and the error messages generated by it). Brad Silverberg, the Microsoft executive responsible for the code, summed up the purpose of the code as follows:

Exhibits 277 & 278 to Consolidated Statement of Facts. Nor was there just one message, as Microsoft implies. The code was designed to trigger a false error message at five separate points. And the messages were not innocuous. They failed to explain that an error had not in fact occurred (see Reynolds Dep. at 79, Record Support, v.2 to Consolidated Statement of Facts (conceding no error had occurred)), they failed to identify that the messages were a product of secret, encrypted detection code, and they left the user with no knowledge about the true cause of the messages. See Hollaar Report at 13-14, Record Support, v.6 to Consolidated Statement of Facts; see also Consolidated Statement of Facts ¶ 231. Moreover, when users contacted Microsoft support they were not told any of these things‹instead they were told that switching to MS-DOS would solve the problem. See, e.g., Bennett Report, Appendix F at 45-46, Engel Decl., Ex. 9 (Microsoft Compuserve posting responding to users¹ concerns about the error messages: "You should be able to get rid of the message by using MS-DOS instead of DR-DOS"). The effect on DR DOS was devastating. See Barnett Report at 3-4 & 15, Record Support, v.6 to Consolidated Statement of Facts; see also Consolidated Statement of Facts ¶¶ 218-19, 230 & 235.

14. Caldera admits paragraph 14.

15. In response to paragraph 15, Caldera admits that Microsoft accurately quotes Mr. Frankenberg¹s testimony, but notes that Mr. Frankenberg testified further that a non-fatal error message would indicate an error has in fact occurred. See Frankenberg Dep. at 105, Record Support, v.3 to Consolidated Statement of Facts; see also Consolidated Statement of Facts ¶ 231.

16. In response to paragraph 16, Caldera admits that the AARD code did not modify DR DOS or prevent DR DOS from running. Caldera denies the remainder of paragraph 16. Microsoft suggests in this paragraph that generating false error messages is not an "incompatibility" for purposes of analyzing Microsoft¹s predatory conduct under the Sherman Act. Dr. Hollaar made no such concession. He specifically limited his answer to applying a narrow definition of incompatibility that required the error to interfere with the actual operation of the program rather than the creation of false error messages. He stated further that under another definition of incompatibility, the AARD code created an incompatibility. See Hollaar Dep. at 90-91, Engel Decl., Ex. 11. Moreover, there is no dispute that the message itself was false. The developer of the code that produced the false error messages conceded that there was in fact "no error." Reynolds Dep. at 79, Record Support, v.2 to Consolidated Statement of Facts.

17. Caldera admits paragraph 17, except as follows. Microsoft asserts that "very few communications with beta testers of Windows 3.1 occurred outside the CompuServe forum" without offering any support for this proposition. It is clear from the record that beta testers contacted Microsoft directly by telephone. See Exhibit 24 to Microsoft¹s AARD Code Memo. at 5-8. The volume of these communications is unknown, but it was sufficiently high to cause Microsoft to complain about it. Id. at 7.

18. Caldera admits paragraph 18, except as follows. It is not clear that all beta testers were covered by valid NDAs (see ¶ 11, above), nor is it clear that anyone routinely complied with NDAs. See Deposition of Steve Ballmer ("Ballmer Dep.") at 193, Record Support, v.1 to Consolidated Statement of Facts ("Well, the computer industry is not a very tight-lipped ship. If you tell‹a systems design preview is an event we would do for independent software vendors. If you tell 50 independent software vendors something, you're going to find it's under a Non-Disclosure Agreement, the high, high, high, high, high, high probability is that that will be in the press the next week"); see also Consolidated Statement of Facts ¶ 314.

19. Caldera denies paragraph 19. Every single DR DOS user that ran the Windows 3.1 Christmas beta saw the false error messages‹and they saw them every single time they attempted to run the beta. See Hollaar Decl. at ¶ 6. In addition, the record shows not only that users were concerned that the messages were the result of an incompatibility between DR DOS and Windows, but that Microsoft told users who encountered the messages that they should switch from DR DOS to MS-DOS. See Statement of Additional Material Facts ¶ 51; see also Consolidated Statement of Facts ¶¶ 218, 219, 230, 233 & 235; see also ¶ 20, below.

20. Caldera denies paragraph 20. It is surprising that Microsoft asserts that "Microsoft never posted a message in the CompuServe forum stating that the Œnon-fatal error¹ message was the result of incompatibilities between DR DOS and Windows 3.1." Maybe Microsoft intends only to assert that it did not use those exact words, because Microsoft plainly told users that the error messages were caused by DR DOS and switching to MS-DOS would solve the problem. In response to a Compuserve beta forum posting about "Non-fatal error detected: Error #2726" (i.e., the AARD code), Microsoft responded: "You should be able to get rid of the message by using MS-DOS instead of DR-DOS." See Bennett Report, Appendix F, at 45-46, Engel Decl., Ex. 9. Moreover, Microsoft never posted anything to clarify that the false error messages were not caused by any incompatibility between Windows 3.1 and DR DOS. See Consolidated Statement of Facts ¶¶ 230 & 235-36.

21. Caldera denies paragraph 21. Rather than improperly examining a Novell copy of the Windows 3.1 beta, near the end of the beta cycle DRI developers contacted Novell by telephone to confirm reports of errors it had received from customers. See ¶ 5 to Response to Undisputed Facts Regarding "Predisclosure" Claim, Section II.A., above. Meanwhile, Microsoft was busy directing one of its OEM representatives to steal a copy of a DR DOS 6 beta so that Microsoft could test it to come up with other FUD points. See ¶¶ 5 & 14 to Response to Undisputed Facts Regarding "Predisclosure" Claim, Section II.A., above.

22. Caldera denies paragraph 22. DRI was able to modify DR DOS to make it compatible with Windows 3.1 only after the commercial release of Windows 3.1. A version of DR DOS compatible with Windows 3.1 was not released until approximately one month after the commercial release of Windows 3.1. Constant Dep. at 29, Record Support, v.3 to Consolidated Statement of Facts. Moreover, Windows 3.1 is not an operating system. See ¶ 6, above; see also ¶¶ 4, 12 & 16 to Response to Undisputed Facts Regarding "Predisclosure" Claim, Section II.A., above.

23. In response to paragraph 23, Caldera admits that Microsoft, in response to concerns regarding the bad press it was receiving and expected to receive, disabled the false error messages so that they no longer appeared. Caldera denies that Microsoft decided not to include the false error messages in the commercial release of Windows 3.1 "because Microsoft was concerned about possible misperceptions of Microsoft¹s intentions." Microsoft disabled the error messages because the media and the industry were criticizing Microsoft for detecting DR DOS and including false error messages. Reynolds FTC Dep. at 76-77, Record Support, v.2 to Consolidated Statement of Facts.

24. In response to paragraph 24, Caldera admits that the false error messages did not appear when the commercial release of Windows 3.1 was run on top of DR DOS. Caldera denies that Microsoft disabled the code. Microsoft disabled the messages. The Windows 3.1 commercial release still ran the AARD code ran every time a user loaded Windows 3.1.

1. STATEMENT OF ADDITIONAL MATERIAL FACTS

1. Caldera¹s Memorandum In Opposition to Defendant¹s Motion for Partial Summary Judgment on "Product Disparagement" Claims ("Product Disparagement Response") explains that Microsoft¹s DR DOS campaign relied on several related predatory acts to create fear, uncertainty and doubt ("FUD") in the market about the quality and compatibility of DR DOS. Caldera¹s Product Disparagement Response focused principally on Microsoft¹s false and misleading statements. This Statement of Additional Material Facts outlines the related aspects of Microsoft¹s FUD campaign: (1) beta blacklisting, (2) coding false error messages in the Windows 3.1 beta, and (3) creating intentional incompatibilities between DR DOS and Windows. As will be shown, each of these practices reinforced the other, and, combined with Microsoft¹s false and misleading statements and Microsoft¹s other predatory practices, succeeded in eliminating DR DOS as a competitive threat to Microsoft¹s desktop operating system monopoly.

1. 1988-1990: DR DOS Enters the Desktop Operating System Market.

1. By the mid-1980s, Microsoft¹s MS-DOS had a monopoly in the desktop operating system market. Kearl Report at 11, Record Support, v.6 to Consolidated Statement of Facts. Without competition to force product innovation, Microsoft put very little effort into improving MS-DOS for several years. See, e.g., Exhibit 38.
2. In June 1988, Microsoft released MS-DOS 4.0. It was widely perceived to be a poor quality product‹even within Microsoft. Exhibits 18, 38, & 39. One of Microsoft¹s principal developers described MS-DOS 4.0 as follows:

1. It was an embarrassment because it was full of bugs?

1. Yeah, it was buggy and it was not user friendly. There were a number of what we called, somewhat jokingly, user-hostile features that were added.

Deposition of Phillip Barrett ("Barrett Dep.") at 37-38, Engel Decl., Ex. 16.

1. The market was ripe for a competitive DOS. DRI re-entered the DOS market with a new product: DR DOS 3.31. Within Microsoft, Bill Gates conceded that DR DOS was "as good as our dos. . . ." Exhibit 38. Gates recognized the quality of DR DOS, explaining to IBM that MS-DOS "is under extreme attack by high quality clones like DR DOS." Exhibit 39; see also Exhibit 26 ("Initial consensus from [Microsoft¹s] DOS program management is that DRI has a product which competes very favorably against MS-DOS."); Exhibit 25 (PC Week May 9, 1989) ("Digital Research produced DOS the way it should have been done in the first place. . . . It¹s a much cleaner, faster system than MS-DOS . . . and it¹s cheaper.").
2. By May 1989, Bill Gates estimated that competition from DR DOS had caused a 30% to 40% reduction in MS-DOS prices. Exhibit 29.
3. On April 26, 1990, DRI announced the release of DR DOS 5.0, which included several new and important technological improvements‹many of which users had been requesting for some time. See Goodman Report, Exhibit C, Record Support, v.6 to Consolidated Statement of Facts.
4. Software industry experts immediately recognized DR DOS 5.0 to be a superior operating system product that was fully compatible with all popular DOS applications, including Windows 3.0:

PC User Magazine, July 4, 1990:

PC User Verdict: This is the first time I¹ve given any product an all "excellent" verdict, which speaks for itself.

Exhibit 61.

PC Magazine, January 15, 1991:

DR DOS 5.0 does all the things you wish MS DOS did. It¹s features includeŠfull compatibility with MS DOS. . . . Everybody¹s DOS should be this advanced.

Exhibit 106 (emphasis added).

PC Magazine, February 12, 1991:

DR DOS 5.0 will run nearly any program that runs under MS DOS, including Microsoft Windows 3.0. Compatibility is not an issue with DR DOS 5.0.

Exhibit 109 (emphasis added).

5. DR DOS 5.0 won Byte Magazine¹s Award of Distinction (January 1991) and PC Magazine¹s Award for Technical Excellence (January 15, 1991). Exhibits 105 & 106.
6. Within Microsoft, the reviews of DR DOS were equally positive:

DR DOS 5.0 runs every DOS app [application] I know. DR DOS 5.0 works successfully with Windows. . . . DR DOS 5.0 is vastly superior to MS/PC DOS 3.31 and 4.01.

Exhibit 123.

DR DOS 5.0 is a "far superior product. . . ."

Exhibit 120 (Joachim Kempin, Microsoft¹s Director of Worldwide OEM Sales).

7. Microsoft was caught flatfooted. It did not have a competitive product to offer the market. In fact, Microsoft would not release its competing operating system‹MS DOS 5.0‹until June 1991, a full 13 months after DR DOS 5.0 was released. Consolidated Statement of Facts ¶ 307. In response, Microsoft used several related predatory practices to "freeze the market" and otherwise prevent PC users and PC manufacturers ("OEMs") from switching to DR DOS 5.0. See Caldera¹s Responses to Microsoft¹s various summary judgment motions.

1. July 1991: Novell Announces the Merger With DRI.

1. Microsoft executives worried about losing their operating system monopoly. At the annual Microsoft Executive Retreat, Scott Oki, Microsoft¹s Senior Vice President for Sales, Marketing & Services, stated the company¹s strategic agenda:

Maintain control of the desktop systems platform. DOS is still the gold mine. It is the cash cow that allows us to invest in other potential cash cow businesses.

Exhibit 110 (emphasis added).

2. In addition to worrying about DR DOS, Microsoft executives had heard that Novell was thinking about entering the desktop operating system market. In a February 1991 memo to Steve Ballmer, Senior Vice President of Systems, Jim Allchin, Vice President of Advanced Systems, characterized competition from Novell on the desktop as "a severe threat . . . Novell is in the best position to impact our position. . . ." Exhibit 111.
3. In July 1991, Novell announced its pending merger with DRI. Hearing the news, Jim Allchin wrote to Bill Gates:

I thought about it all night. Since I came here I said there were two things that concerned me related to Novell: one Novell partnering with IBM and two Novell coming at us at the desktop. Both fears have now come true.

Given this, I suggest (at least for Systems) that we . . .

consider changing our apps to not run unless the OS [operating system] is our OS [MS-DOS].

Exhibit 280 (emphasis added).

4. Brad Silverberg, the senior executive responsible for MS-DOS and Windows, immediately instructed his development team to find ways to prevent Novell from competing on the desktop. Exhibit 148.
5. Phil Barrett, the MS-DOS 5.0 Development Manager, responded. He observed: "Totally freezing them out will force them to compete on a wider basis and could cause the disaster scenario to occur. Not to mention the thin FTC ice that we would be on." Instead he suggested, ". . . we have an advantage with windows and should press it in the systems area." Engel Decl., Ex. 17 (emphasis added). Brad Silverberg, Vice President, Personal Systems, concurred. Id.
6. At the time, Microsoft was preparing to release the beta version of Windows 3.1, preparatory to a release of the final product in Spring 1992. Brad Silverberg and Jim Allchin decided Microsoft should engineer Windows 3.1 in a way that would create compatibility problems for DR DOS:

Silverberg:

. . . drdos has problems running windows today, and I assume will have more problems in the future.

Allchin:

You should make sure it has problems in the future.

Exhibit 197 (emphasis added).

7. Microsoft¹s fears about DR DOS and Novell became even more severe in September 1991 with the release of DR DOS 6.0. Once again, the industry press was overwhelmingly favorable:

PC User, September 25, 1991:

VERDICT: more of an operating system than MS DOS, with no obvious disadvantages.

Exhibit 193.

PC Week, September 30, 1991:

DR DOS has a lot going for it. DRI had already made significant headway against MS-DOS earlier this year with DR DOS 5.0 and DRI¹s successful "toss your DOS" campaign. Microsoft¹s release of MS-DOS 5.0 this summer was clearly in response to the growing acceptance of DR DOS 5.0.

Now, only months after the release of MS-DOS 5.0, DRI has again stepped ahead with the release earlier this month of DR DOS 6.0, which once again matches and exceeds the features and capabilities of Microsoft¹s product. Starting from a small base, DR DOS is clearly gaining market share.

Exhibit 200 (emphasis added).

8. DR DOS 6.0 won "Best of Comdex," and Byte Magazine¹s "Best Utility Software." Exhibit 228 (Business Wire, October 24, 1991). InfoWorld awarded DR DOS 6.0 a score of 7.6, as compared to 7.1 for MS-DOS. Exhibit 235 (InfoWorld, November 4, 1991). PC/Computing said, "DR DOS 6.0 steals thunder from MS DOS in nearly every area." Exhibit 233 (November 1991). PC Magazine said, "DR DOS 6.0 leapfrogs MS DOS 5.0 with task switching and RAM." Exhibit 244 (November 12, 1991).
9. Once again, Microsoft internal reviews recognized that DR DOS was superior to MS-DOS and that DR DOS had established a big lead over Microsoft in the introduction of new DOS technology. As Novell was about to release DR DOS 7.0, Richard Freedman, the MS-DOS 6.0 Product Manager stated:

Exhibit 350.

David Cole, MS-DOS/Windows Program Manager, worried:

Exhibit 273.

1. Fall 1991: Microsoft Plans to Make Windows 3.1 Incompatible With DR DOS.

1. Fearing loss of its desktop operating system monopoly, Microsoft decided to use Windows to eliminate the DR DOS/Novell threat. With the success of Windows 3.0 and the pending release of Windows 3.1, Microsoft knew most OEMs believed they had to license and offer Windows with their PCs. As Joachim Kempin, Director of Worldwide OEM Sales, said: OEMs "will hurt if they do not ship WIN. . . ." Exhibit 118. Further, Microsoft knew that OEMs would not license DR DOS if they feared it would not run Windows:

Any degree of incompatibility is enough to create fear, uncertainty & doubt among endusers when it comes time to buy new systems‹this suggests PC OEMs will take on a big risk if they ship DR-DOS with their systems.

Exhibit 126; see also Deposition of Sergio Pineda ("Pineda Dep.") at 37, Record Support, v.2 to Consolidated Statement of Facts; Barnett Report at 9 & 15, Record Support, v.6 to Consolidated Statement of Facts.

2. Microsoft¹s attack on DR DOS had five complimentary aspects: (1) Microsoft publicly stated it would take steps to prevent DR DOS from being compatible with Windows; (2) Microsoft excluded DR DOS from the Windows 3.1 beta program so DRI could not detect and fix real and perceived incompatibilities that Microsoft intentionally engineered into Windows 3.1; (3) Microsoft placed a purposely deceptive "error" message in a Windows 3.1 beta that caused the market to believe DR DOS was not compatible; (4) Microsoft reinforced its deceptive "error" message by making false public statements that DR DOS was not compatible and that MS-DOS was "required" to run Windows; and (5) Microsoft intentionally engineered software incompatibilities between Windows 3.1 and DR DOS. See ¶¶ 22-49, below.

1. Microsoft Made Public Statements That Caused the Market to Expect DR DOS Would Not Be Compatible With Windows.

1. Microsoft knew that, since PC users and even OEMs cannot understand every complexity in a new software product‹indeed, few people other than the developers themselves have access to the information necessary to gain such an understanding‹"perception is the most important determining factor." Freedman Dep. at 10-11, Record Support, v.1 to Consolidated Statement of Facts.
2. Brad Silverberg stated Microsoft¹s plan:

We need to create the reputation for problems and incompatibilities to undermine confidence in DR DOS 6; so people will make judgments against it without knowing the details or facts.

Exhibit 227.

3. Microsoft engaged in a public relations campaign to convince the market that Microsoft would take steps to prevent DR DOS from being compatible with Windows. For example, Microsoft instructed its account managers to tell OEMs:

. . . dr dos and windows will get them complaints. . . . in addition, they will get even more questions later as we update ms-dos 6 and windows as dr dos could not be compatible.

Exhibit 159 (emphasis added).

also ask them if they really want to risk their reputation on their brand new machines with a brand new unproven poorly tested os. what if it doesn¹t work with the next version of windows? they could literally blow their whole pc business‹first impressions are hard to overcome if they blow it.

Exhibit 173 (emphasis added).

4. Microsoft even went so far as to state outright that DR DOS was not compatible:

Exhibit 218 (emphasis added).

1. Microsoft Selectively Excluded DR DOS From the Windows 3.1 Beta Program.

1. Brad Silverberg and Steve Ballmer, the two senior Microsoft executives responsible for MS-DOS and Windows, ensured that the market would take these threats seriously and that Microsoft would be able to hide its efforts to manufacture incompatibilities, by excluding DRI from the Windows 3.1 beta program.

Brad Silverberg:

There should be NO HELP for DRI. They are totally on their own. Do we know if DR has Win 3.1? They are NOT an official beta tester.

Steve Ballmer:

brad pls make sure we are not supporting DRI anywhere in the company with this stuff thx

Exhibit 158; see also Product Disparagement Response Statement of Additional Material Facts ¶¶ 19-20 & 22.

2. Microsoft¹s purposes in excluding DR DOS were at least three-fold. Exclusion would: (1) let the market know Microsoft was making it difficult for DR DOS to be compatible; (2) prevent DRI from discovering and fixing the incompatibilities Microsoft planned to engineer into Windows; and (3) prevent DRI from having a Windows-compatible version of DR DOS ready for market at the same time Microsoft released Windows 3.1. See Product Disparagement Response Statement of Additional Material Facts ¶¶ 19 & 21.
3. Microsoft knew it was wrong to selectively exclude DRI. See Product Disparagement Response Statement of Additional Material Facts ¶¶ 18 & 21.
4. Waggener Edstrom, Microsoft¹s public relations firm, warned Brad Silverberg:

PR is going to have limited ability to help you if Microsoft is deliberately and selectively keeping DRI from participating in the beta program. That is, if you are making a special case of them that is not consistent with the way that the beta program is being administered for the rest of the industry.

Exhibit 238. Yet selective exclusion is precisely what Microsoft did. See Product Disparagement Response Statement of Additional Material Facts ¶¶ 22-23.

5. Knowing it was improper to exclude the developers of DR DOS, a product that was complimentary to Windows, Microsoft began propagating the fiction that Windows 3.1 and DR DOS were competitive "operating systems."

Silverberg:

We recently decided to start referring to Windows as an operating system in our communications, not a graphical environment or user interface for dos. we should be consistent in the new usage. thanks.

Exhibit 164.

6. A beta tester asked Brad Silverberg directly:

What is MS¹ official response to the charge that you folks have been deliberately shutting out DRI from the BETA program, and that you¹ve made 3.1 incompatible with DR DOS intentionally? I hear a lot of accusations to this effect, and some of them are down-right libelous. What¹s the word, Brad?

Exhibit 443. Silverberg responded:

Windows is an operating system. That¹s how we view it and certainly a sign of how it will evolve.

Id. (emphasis added); see also Exhibit 443 (Silverberg attempting to justify Microsoft¹s exclusion of DR DOS on the grounds that Windows and DR DOS are direct competitors, "Are the Redskins going to give their game plan in advance to the Bills?").

7. But Microsoft knew that Windows 3.1 was not an "operating system" and, more important, that it did not compete with DOS. Windows 3.1 was, and is, a graphical extension of DOS that requires the underlying DOS operating system‹either MS-DOS or DR DOS‹to run. DR DOS competes with MS-DOS. Microsoft recognized these markets were separate markets‹and the danger of using control of one market to eliminate competition in the other:

David Cole (MS DOS/Windows Group Program Manager):

Uhmm . . . denying DRI the VxD [virtual device driver] smells of an antitrust lawsuit. You¹re not supposed to use your control of one market, in this case Windows, to influence another market, in this case DOS. Err something like that.

Exhibit 99 (emphasis added). The press similarly explained:

PC Week:

Microsoft officials have said they won¹t help Digital Research, Inc. (DRI) resolve incompatibilities between Windows 3.1‹over which the companies don¹t compete‹and DRI¹s DR DOS 6.0, which challenges Microsoft¹s DOS monopoly.

Exhibit 254 (emphasis added); see also Product Disparagement Response Statement of Additional Material Facts ¶¶ 23-25.

8. Microsoft¹s economic expert, Professor Hausman, conceded that Microsoft excluded DR DOS to harm its ability to compete with MS-DOS, even though including DR DOS could have benefited Microsoft¹s sales of Windows 3.1:

Q: . . . and wouldn¹t inclusion . . . if it occurred . . . be a benefit to Windows?

A: It could be a benefit to Windows, but it would be a detriment to the overall Microsoft, and that¹s what they are looking at.

Q: It would be a detriment to Microsoft¹s sales of MS-DOS, right?

A: It could be, yes.

Deposition of Jerry Hausman ("Hausman Dep.") at 104-105, Engel Decl., Ex. 18.; see also Product Disparagement Response Statement of Additional Material Facts ¶¶ 26-27.

9. Blacklisting had the result Microsoft intended. DR DOS¹ exclusion from the Windows beta program was widely known and reported in the press:

Microsoft officials have said they won¹t help Digital Research Inc. (DRI) resolve incompatibilities between Windows 3.1‹over which the companies don¹t compete‹and DRI¹s DR DOS¹s 6.0, which challenges Microsoft¹s DOS monopoly.

Exhibit 254 (PC Week, December 9, 1991) (emphasis added); see also Exhibit 257 (InfoWorld, December 16, 1991) ("Microsoft Balks at Fixing DR DOS, Windows Bugs; DRI Cites Responsibility to Users").

10. DR DOS lost business. For example, in January 1992, DRI was notified, by a potential corporate account of its decision to reject DR DOS 6.0:

What I feel is the most important factor however, is the rift developing between Digital Research and Microsoft. By this I mean Microsoft not allowing you to beta test Windows 3.1. Since the users who would be most inclined to switch to DR DOS are also using Windows, this one factor is of particular concern.

Exhibit 266.

11. Microsoft also ensured that the OEM and developer community knew not only that DR DOS was excluded from the Windows 3.1 beta program, but also that the incompatibilities were the fault of DR DOS, not Microsoft (which, as explained below, was not true). For example, Microsoft hosted a Windows developers conference in February 1992. Wightman Dep. at 309-10, Engel Decl., Ex. 4. The conference was attended by developers and OEMs, including the major OEMs‹DRI¹s key target market. Id. at 310-11. Microsoft charged attendees, who came to hear the "latest information" from Microsoft¹s executives and developers about Windows 3.1. Id. at 310. A newsletter was distributed to attendees. Id. at 314. The newsletter reported that DR DOS was incompatible with Windows 3.1. Id. Jon Lazarus, a Microsoft executive reporting to Steve Ballmer, gave the keynote speech. The first question from the audience following the speech was about DR DOS/Windows 3.1 incompatibilities. Id. In response, Mr. Lazarus did not admit that Microsoft had introduced the Nested Task flag bug, that Microsoft had put code in SmartDrv that would prevent it from running on DR DOS, or that Microsoft had hidden secret detection code in five different Windows modules that displayed false error messages when a user tried to run Windows 3.1 on DR DOS. Instead, he said Microsoft was "doing nothing" to create the incompatibilities and that it was up to DRI to fix the problems. Id. at 314-15. Thus, developers and OEMs left knowing that DRI had been excluded from the Windows 3.1 beta program, and they left with the impression that: (i) the rumors of DR DOS/Windows incompatibilities were true (confirmed in the newsletter), (ii) Microsoft had not created the incompatibilities (which plainly was not true), and (iii) Microsoft would continue to exclude DRI from access to the information it needed to fix the problems (which plainly was true).
12. All of this happened at a critical point in time for DR DOS. During the Windows 3.1 beta cycle, it was negotiating a potential OEM contract with IBM. See Wightman Dep. at 310-12, Engel Decl., Ex. 4. In November 1991, DRI responded to a request from IBM with a DR DOS licensing proposal. Engel Decl., Ex. 19; Wightman Dep. at 311, Engel Decl., Ex. 4. In January 1992, DRI officials met with IBM in Florida to continue the negotiations. Id. at 311-12; Engel Decl., Ex. 20. IBM was expressing a high degree of interest in DR DOS, but Microsoft¹s campaign to create fear, uncertainty and doubt about DR DOS/Windows compatibility worked. IBM expressed concerns about this very issue:

• PROVIDING AND CONTINUING COMPATIBILITY WHEN MICROSOFT WILL CONTINUE TO ASSERT OTHERWISE"

Exhibit 268 at 5 & 8; see also Wightman Dep. at 312, Engel Decl., Ex. 4 (IBM concerned about DR DOS/Windows compatibility during negotiations). IBM ultimately decided not to license DR DOS.

1. Microsoft Ensured That Windows Would Be Incompatible With DR DOS.

1. Microsoft knew, of course, that DR DOS would be compatible with Windows 3.1 unless Microsoft took specific actions to prevent compatibility. DR DOS had proven its ability to support Windows, by ensuring full compatibility with Windows 3.0. See Exhibit 230.
2. As part of the plan, Brad Silverberg directed his Windows developers to "bind [Windows] closer to MS DOS." Exhibit 198. A number of ways to do this were suggested and discussed. Id.
3. On September 30, 1991, David Cole, the MS-DOS/Windows Group Program Manager, summarized (for Silverberg) the development team¹s proposal for creating incompatibilities between Windows 3.1 and DR DOS:

It¹s pretty clear we need to make sure Windows 3.1 only runs on top of MS DOS or an OEM version of it. I checked with legal, and they are working up some text we are suppose to display if someone tries to setup or run Windows on a alien operating system. We are suppose to give the user the option of continuing after the warning. However, we should surely crash at some point shortly later.

Now to the point of this mail. How shall we proceed on the issue of making sure Win 3.1 requires MS DOS. We need to have some pretty fancy internal checks to make sure we are on the right one. Maybe there are several very sophisticated checks so that competitors get put on a treadmill. Aaronr [Aaron Reynolds] had some pretty wild ideas after 3 or so beers, earleh has some too. We need to make sure this doesn¹t distract the team for a couple of reasons 1) the pure distraction factor 2) the less people know about exactly what gets done, the better.

Please advise.

Exhibit 206.

4. Two alternatives were proposed: (1) place some "pretty fancy internal checks" in Windows that will display a "warning" text to "put competitors on a treadmill," and (2) "crash" Windows if a user tries to run it with DR DOS. Microsoft did both‹despite the fact that even Microsoft¹s lawyers advised against creating intentional incompatibilities that would cause Windows to "crash." Exhibit 206.

1. Microsoft Introduced Incompatibilities in Windows 3.1, Including the AARD Code, "Bambi," the XMS Check, and the Nested Task Flag Bug.

1. Having told the market to expect DR DOS¹ incompatibility with Windows, Microsoft followed through on its threat.
2. Although Microsoft has repeatedly denied that it put code in the Windows 3.1 beta that checked for DR DOS, the evidence shows otherwise. Microsoft included code in at least one beta release in a module, called Smartdrv (which was code-named "Bambi") that explicitly checked for DR DOS (via INT 21h function 4452h‹a hexadecimal code that stands for "DR"). The detection technique is the same technique explained in the "Roger Sour" correspondence. See Consolidated Statement of Facts ¶¶ 256-60. Cliff Garrett, a member of Microsoft¹s Strategic Customers & Products OEM Team, stated: "I got the previous mailings info from DR personally. I have a person I can get internals from." Exhibit 202. Later that day, he posted an e-mail stating:

The OFFICIAL way to detect dr. dos is as follows.

1) set the carry flag

2) nt 2lh ax = 4452h

3) the carry will be clear if it is dr. dos, and set if it is pc-docs

Exhibit 201. Using this technique to detect DR DOS, Microsoft programmed the beta to display a fatal error message, "Invalid device interface. Unable to load," and then refuse to run. Users would not know that the message resulted from DR DOS detection code. Even putting aside the fact that Microsoft repeatedly misled the market by denying that it was engaging in this predatory conduct, there is absolutely no technical justification for the code. See Hollaar Decl. at ¶ 4; see also Barrett FTC Dep. at 100-10, Engel Decl., Ex. 14 (describing how original smartdrv problem was not caused by DR DOS and describing his beliefs that Cliff Garrett at Microsoft had contacted DRI using the false name Roger Sour).

3. Microsoft eventually replaced this code with secret, encrypted detection code that produced false error messages when users attempted to setup and run Windows 3.1 with DR DOS. See Hollaar Report at 2-14, Record Support, v.6 to Consolidated Statement of Facts.
4. To create these false error messages, Microsoft first had to develop code that would detect DR DOS when Windows was running on it. Microsoft knew the DR DOS detection code had to be precise or it would also detect OEM versions of MS-DOS. Exhibit 194. Microsoft also knew that placing a false "error" message in the Windows 3.1 was wrong:

2) The message has to be consistent with our other error messages (caution box etc.) and avoid making us look bad. The message below, in my opinion, leads us open to bad PR‹it surely is the outer boundary of rudeness. It is also fairly extreme compared to others in the product we have seen.

. . . .

I hate this whole thing. I think it¹s totally rude, reinforces the image that users have of us as the evil ones, etc.

Exhibit 194; see also Exhibit 238. Aaron Reynolds wrote and tested the DR DOS detection code, the "AARD Code." Reynolds Dep. at 30-31, Record Support, v.2 to Consolidated Statement of Facts.

5. During this time, Microsoft sought to ensure that its efforts to create the image that DR DOS was incompatible with Windows were effective. For example, Microsoft told beta testers in October 1991 that MS-DOS was "required" to run Windows:

For beta testers that report problems W/DR DOS and 3.1

DR DOS is an untested and therefore unsupported operating system. MS-DOS (or OEM versions of it) is required for Windows. Using DR DOS with Microsoft Windows is at the sole risk of the user. We don¹t support it.

Exhibit 231 (emphasis added). The following month (November 1991), Microsoft made the decision to put the AARD code in the final beta of Windows 3.1. Exhibit 239.

6. There is little doubt that error messages are an effective means of scaring users. Microsoft asserts as an "undisputed fact" that error messages are more effective than written documentation or even electronic documentation provided with the programs. See ¶ 3 of Caldera¹s Response to Microsoft¹s "Statement of Undisputed Facts" Regarding Plaintiff¹s "Perceived Incompatibilities" Claim, Section II.C., above. Microsoft chose a message that would scare users, without telling them that, in fact, no problem had occurred:

Detection for the absence of MS-DOS will be in the Final Beta Release (AKA beta 3) . . . the message will say: Non-fatal error detected: error # (Please contact Windows 3.1 beta support).

Exhibit 248 (emphasis added). The fact that it was a nonfatal error was at least as disturbing if not more disturbing than a fatal error. See Hollaar Dep. at 133-34 & 147-48, Engel Decl., Ex. 11; Goodman Rebuttal Report at 12, Engel Decl., Ex. 21.

7. There was no error. The AARD code (1) detected that DR DOS was the underlying operating system, and (2) displayed the false error message. Aaron Reynolds, the author of the AARD code, could not have testified more clearly: "There¹s no problem." Reynolds Dep. at 79, Record Support, v.2 to Consolidated Statement of Facts.
8. Microsoft also introduced an incompatibility earlier in the Windows 3.1 beta cycle that prevented users from installing Windows 3.1 with DR DOS. As part of the Windows 3.1 development process, Microsoft added DPMI support to Windows. In the process of implementing DPMI support, Microsoft created an incompatibility between DR DOS and Windows by failing to include a line of code that would have ensured the Nested Task Flag was set properly when protected mode was initiated. As a result, when users tried to install Windows on DR DOS, they encountered a fatal error‹the program halted and a message appeared stating: "Standard Mode: Fault in MS-DOS Extender." The message did not identify the cause of the problem. The evidence shows that Microsoft knew about the incompatibility, knew the cause of the incompatibility, and knew it could have corrected the error by adding a single line of code. Yet Microsoft did nothing to remedy the problem in the Windows 3.1 production release. Introducing this incompatibility resulted in no technical benefit to Windows. The incompatibility was not required for, or even helpful to, Windows in implementing DPMI or in running setup in Standard Mode‹in fact, it was a hindrance. Moreover, if DRI/Novell had been allowed to participate in the Windows 3.1 beta program, it would have been a relatively simple matter for DRI/Novell to code a work around that would have eliminated the incompatibility. See Hollaar Decl. at ¶ 3; Reynolds FTC Dep. at 70-72, Record Support, v.2 to Consolidated Statement of Facts.
9. In addition, during the Windows 3.1 development cycle, Microsoft added a "version check" to the Windows setup program that specified internal version 2.6 or higher for XMS (the extended memory specification). DR DOS failed to pass this version check, because it reported internal version 2.5. MS-DOS passed the check. Setup made no use of XMS, so the test was unnecessary for the proper operation of setup. Windows modules that used XMS included XMS version checks, but DR DOS passed all of those version checks. See Hollaar Decl. at ¶ 5.

1. Microsoft Intended That False Errors Would Cause OEMs and PC Users Not to Buy DR DOS.

1. Microsoft intended to scare OEMs and users, and thus eliminate DR DOS as a competitive threat. Microsoft¹s intentions were clearly stated by Brad Silverberg. David Cole sent Silverberg an e-mail asking, "what is the guy is supposed to do" when he sees the false error message? Silverberg responded:

What the guy is supposed to do is feel uncomfortable, and when he has bugs, suspect that the problem is DR DOS and then go out to buy MS-DOS. Or decide to not take the risk for the other machines he has to buy for in the office.

Exhibit 278.

2. Microsoft took no chances in this respect. The text of the false error messages said, "Non-fatal error detected. . . . Please contact Windows 3.1 beta support." When a beta tester called the Microsoft help desk, Microsoft did not tell users that the messages were caused by secret, encrypted detection code, but rather blamed the "problem" on DR DOS and told the user‹consistent with Mr. Silverberg¹s stated reason for the message‹that the user should buy MS-DOS instead. For example, beta testers asked:

I thought I¹d try RC 1 [Windows beta 3.1] on DR DOS 5.0 . . . a funny message is displayed.

Non fatal error detected: error number 2726

Please contact Windows 3.1 data support.

Press ENTER to cancel, or C to continue.

(Well, I * am * contacting beta support . . .)

If I press C, it works okay. However, this messes up my "automatic" batch test file I have. Is there any way to eliminate this message?

Microsoft responded:

Greg, you should be able to get rid of the message by using MS-DOS instead of DR DOS. You should send in a copy of bootable DR DOS floppy disk, with the error number written on the label. . . .

Exhibit 443 (emphasis added).

3. When a Microsoft beta support group member asked Andy Hill (MS DOS Developer), what Microsoft can tell a customer, "about compatibility or not with DR DOS 6?," Hill replied:

The standard response is: Windows is only tested with MS-DOS operating systems. DR-DOS claims to be 100% compatible with MS-DOS, so if that is true, then the user shouldn¹t have any problems.

There is really nothing we can do.

Exhibit 291 (emphasis added).

4. OEMs who called in were told that "Windows was not supposed to work with DR DOS." Deposition of Stefanie Reichel ("Reichel Dep.") at 61-62, Record Support, v.2 to Consolidated Statement of Facts.
5. Mr. Silverberg made certain beta testers who called in were told they needed MS-DOS, not DR DOS, to run Windows. He directed the Windows 3.1 beta support to say:

windows is designed and tested for ms-dos. not dr dos. it says MS-DOS on the box, not MS-DOS or DR DOS . . . this is what to tell the world (in a nice way). using a system other than ms-dos puts the user at his own risk. it says this very clearly first thing in the readme.

there is another "fix" for them: use ms-dos. that should be mentioned in addition to telling them that digital research is providing them with a new version.

Exhibit 292 (emphasis added); see also Exhibit 263 (Silverberg instructed the Windows 3.1 beta support group to post "a nice SOL [___ out of luck] message. bottom line is that he needs ms dos‹something that is compatible with windows").

6. The campaign was effective. For example, a disgruntled end-user in Canada wrote to Digital Research (by then, a division of Novell) in July 1992:

Exhibit 317 (emphasis added).

1. Microsoft¹s Campaign Succeeded In Scaring OEMs and Users Away From Buying DR DOS.

1. The Windows 3.1 beta containing the AARD code 12,000 to 15,000 sites just prior to Christmas 1991. Deposition of David Cole ("Cole Dep.") at 178, Record Support, v.1 to Consolidated Statement of Facts; Exhibit 290. The Christmas beta was a "preview" beta: "essentially for‹it is a marketing tool to get the product into the hands of people making buying decisions." Barrett Dep. at 77, Engel Decl., Ex. 16. Members of the press also got this beta. Id.; Cole Dep. at 178, Record Support, v.1 to Consolidated Statement of Facts.
2. Microsoft¹s Windows 3.1 Compuserve forum started receiving users¹ concerns about the detected "error" almost immediately. Such postings were, and would remain, available for viewing by all beta sites‹which included significant OEMs, ISVs, influential end-users, and media analysts. The following are examples of postings related to the AARD code:

December 22, 1991:

I was able to install build 61D on my laptop using MS-DOS 5, with no problems. However, when starting this, under DR DOS, I get a non fatal error number 2726 upon startup. I enter C to continue. Everything appears to work properly anyway. I realize that this is most probably due to problems with DR DOS.

December 28, 1991:

While setting up a beta test on DR DOS 6.0 the following was noted:

Non fatal error detected error number 4D53

I will make a report on the correct form after I try to reproduce the problem on another machine with DR DOS 6.0.

January 12, 1992:

I don¹t know about you but I have encountered some problems using DR DOS 6.0 with 3.1. Even with my config.sys and Autoexec.bat stripped down, I still get an error message on startup, but performance was adequate, despite the non fatal error.

Of note is an article I read in a local computer freebie magazine, that accused MS of designing 3.1 to not work with DR DOS 6. I assume (hope) that this is not true.

January 22, 1992:

I am receiving an error: non fatal error 2726 when starting Windows 3.1. Windows then starts correctly, but this error is printed every time Windows is started. The problem goes away if I boot under Compaq DOS 3.1. My regular operating system is DR DOS 6.0. Is there an incompatibility between DR DOS and Windows?

February 14, 1992:

I got some trouble with WIN 31 (final beta) on setup over a previously installed Windows 3.0‹after starting setup (automatic mode) the message‹non fatal error detected number 453‹appeared. . . . I¹m running DR DOS 6.0. . . . What can I do???

Beta Site:

Last I heard DR DOS did not work with Windows 3.1. Since MS is not about to help DR clone DOS, they are not likely to help them (DR) solve their WIN 3.1 incompatibilities. It¹s all up to DR to fix their DOS problems.

Beta Site:

. . . I wanted DR DOS for home because it provides a cheap method of doubling hard disk space + a lot of other utilities my home machine isn¹t budgeted for. Yet if Microsoft is going to make life difficult for DRI guess DR DOS isn¹t an option since I need to run the current betas.

Beta Site 1:

. . . . Has anybody got any confidence that DR will fix its WIN 3.1 problems?

Engel Decl., Ex. 22 (emphasis added).

3. The AARD code directly impacted OEMs¹ decisions to license DR DOS or MS-DOS. Theo Lieven, CEO of Vobis, specifically stated he was "concerned" about the "nonfatal error" message. Reichel Dep. at 58, Record Support, v.2 to Consolidated Statement of Facts.
4. Bruce Fryer, product strategy manager of Zenith Data Systems in 1992, testified his software engineers ran into the AARD code during beta tests of Windows 3.1 on DR DOS. Deposition of Bruce Fryer ("Fryer Dep.") at 59, Record Support, v.3 to Consolidated Statement of Facts. The engineers determined that "this error message in fact didn¹t reflect any operational problems or incompatibilities." Id. at 110. Even so, Zenith abandoned any further consideration of DR DOS 6.0 based on objective fear that "Microsoft might intentionally put code in Windows that would cause problems with DR DOS." Id. at 112.
5. Other OEM deponents testified that a "nonfatal error" would cause "a great deal of concern among the testers." Deposition of Gary Bachelor ("Bachelor Dep.") at 80-81, Record Support, v.5 to Consolidated Statement of Facts. This was "[b]ecause we wanted compatibility in the products," and "those nonfatal error messages could cause just those sorts of concerns. . . ." Id. at 81; see also Frankenberg Dep. at 105, Record Support, v.3 to Consolidated Statement of Facts ("Well, it would be an indication that this software wasn¹t completely bug free, that it had problems of some type in interacting with other software on the system. . . .").
6. Review of the CompuServe forum messages pertaining to the other incompatibilities demonstrates that Microsoft¹s other FUD were equally devastating.
7. Exhibit 22 to Engel Decl. is a subset of the CompuServe forum messages. The messages show: users who complained of problems were told to switch to MS-DOS; numerous users encountered and complained about the problems created by the incompatibilities Microsoft created; Microsoft blamed the problems on DR DOS; users who complained of problems were told they should switch to MS-DOS; users were aware of and concerned about Microsoft¹s decision to blacklist DRI from the beta program; users recognized that DRI did not compete in the Windows market; and even though users recognized that DR DOS was a superior product to MS-DOS, the incompatibilities were forcing them to use MS-DOS instead. A few quotes follow:

1. Microsoft¹s response to the reports of errors:

We don¹t test against DR DOS. You should use MS DOS.

If you¹re using DR-DOS, I wouldn¹t expect it to work. Are you using

DR-DOS?

You should be able to get rid of the message by using MS-DOS instead of DR-DOS.

[Statement to a trade press reporter] Oh, I forgot to say that Windows is designed and tested to work with MS-DOS. We do no testing at all with DR DOS and we do not know first hand whether it¹s compatible with Win 3.1 or not. There is no code in Windows that says, "if DR-DOS then. . . ." We don¹t detect it.

[From a user:] Jeff, I talked with someone from Microsoft after I first reported the problem, and after the article in PC Week, and the claim is that there is a substantive problem with DR DOS, most probably in the memory handler.

Sorry, but Windows is designed and tested for MS-DOS. DRI claims 100% compatibility with msdos. if that were indeed true, then windows would just work.

Here¹s the straight story on this Marty. Windows 3.1 is designed and tested only on MS-DOS and OEM versions of MS-DOS version 3.1 and higher. Running Windows on any other system will result in unpredictable results. We are not working, nor do we plan to work with DRI on this issue.

[From a user:] The official line from MS about DR-DOS is that "Windows has not been tested with DR-DOS." That¹s probably about all you¹ll get out of them.

2. Statements from users and OEMs encountering incompatibilities created by Microsoft:

This is a realy big issue with us. DFM Systems ( the company I work for ) Manufactures a Touch Screen Notebook computer and planned on using Windows for Pen computing. We also "burn" DR DOS into a psudo drive in the BIOS. If Windows won¹t work with DR 6.0 it will be a big mess. I can get windows to come up, but so far it has mucho problems. With EMM386 ( it claims it ( windows ) can¹t load the driver, I can load the network drivers, and login, however, vpipx claims that the driver is not loaded, there are 2 or 3 error numbers that I have to <C>ontinue thru, and I haven¹t yet gotten SuperPCK to run, nor SuperStore. needless to say, performance is not pretty. I upgraded the machine I use day to day with DR 6 and had to resort to my floppy boot disk to continue with my daily work.

I¹m having mega problems getting this beta to install, and I run DR6.

I can¹t get past the second diskette when installing 3.1 beta release 2.

DRDOS 6 flatly refuses to run 3.1, in fact it even causes the new himem.sys to fail.

DRDOS 6 will *not* allow the beta to install. I¹ve left numerous msgs to Andy, none answered yet. Also called the tech line, no answers. Getting rather tired of no answers. Got confirmation from DRI that v6 won¹t work, and M-S and DRI aren¹t talking about it to each other, either.

Precisely why I use MS-DOS 5. Good luck.

Having total failure installing this beta with DR DOS v6. Lots of reports saying beta will not run with DRDOS at all. I can confirm it for you. What¹s the scoop now? Can MS send me a copy of MSDOS 5 as a lender for this testing? Send me a copy to replace DRDOS entirely??? I¹d be glad to give up DRI if they want to send me a copy of MSDOS5.

Build 60 runs great under DRv6 in enhanced mode, but croaks in standard mode.

My build 60 doesn¹t run with DRDOS 6 in any kind of mode. HIMEM.SYS even generates an instruction for me to call Micrososft.

It is true that 3.1 does NOT work with DR-DOS 6.0. I tried it on my ALR and 3.1 just refuses to install. (I had to uninstall DR-DOS to get back to MS-DOS 4.01.)

This confirms my finding that DrDOS v6.0 is NOT compatible with Windows version 3.1.

Thats right Windows 3.1 won¹t work at all (or at least in my trials) with DR-DOS v6.0. I stripped it down (DR-DOS that is), changed memory managers and anything else I could have thought of and nothing!

[In response to compatibility problems] I really must say that the good people of Microsoft have vastly reduced the confusion of which OS to upgrade to from 4.01!

Last I heard Dr DOS did not work with Windows 3.1. Since MS is not about to help DR clone DOS, they are not likely to help them (DR) solve their Win 3.1 incompatabilities. It¹s all up to DR to fix their DOS problems.

Also, I tried DR DOS on a couple of installations‹all had compatibility problems which I traced to DR DOS. We have installed MS-DOS 5 on these computers and the problems went away. We are recommending to our clients to stay away from DR DOS.

Cannot install under DR DOS, i tried both version 5 and 6, Boot under MSDOS 5 and install, still get the errors I mailed to you. I See in info from another Beta source, Smartdrv.exe will not load under DR DOS. Is there anything special I should do? I will try QEMM and 386MAX and try to get a config that will work.

[Microsoft responds:] DR-DOS has not been tested under Windows 3.1.

Has anyone else tried loading Build 61d under DR DOS 6.0? Setup gave several error messages and then Abended. Will try RC1 and advise. Uploaded MSD report and no response yet.

With NO mem mgrs installed at all, Setup for Build 61d & RC1 Abend with "Standard Mode: Fault in MS-DOS Extender" & a register dump.

I recently bought a copy of DR Dos 6.0 to try it out. After I had installed it I tried to load Windows 3.1 RC1. When I ran the setup program, it told me that the XMS manager that was loaded was not compatible with Windows. The DR Dos manuals say that it was compatible with Windows 3.0. Is there any type of update that will fix this problem so that Windows 3.1 will run under DR Dos 6.0? I would appreciate any help anyone could give me on this subject. Thanks.

3. Statements about press coverage of the problems:

Well, basically, the article stated that DRDOS 6 has trouble with Win 3.1 due to differences in memory management techniques, that Microsoft considers it DR¹s problem and isn¹t about to help, and that DR says they have been locked out of the Win beta process. I think that covers the highlights.

It¹s DR.DOS¹s problem is what I have read in the rag¹s I get.<g>

4. Statements asking if users can contact DRI:

Is it permissable to ask Digital Research for assitance in problems with DRDOS6 and Win 3.1 (60) ?

My answer yesterday was a curt, but flat no don¹t you dare!!!!! Remember a thing called NDA???? I¹m strictly adhering to it, but wish MS would talk with DRI.

[Response from Microsoft] Jeff, Don¹t say anything about 3.1 to DRI.

5. Statements recognizing that DR DOS was a better product and that it did not compete with Windows:

1. DR DOS was damaged as a result. For example, DRI lost the Sears account to MS-DOS because Sears demanded that DRI guarantee DR DOS would be compatible with future versions of Windows‹something DRI was reluctant to do in light of Microsoft¹s apparent plan to create intentional incompatibilities. A Microsoft document reports the incident:

DR has since faltered by not agreeing to sign the Sears contract which included a guarantee to run future versions of Windows. With this misstep, Johnk, DebbyRea, and Don Hardwick were able to get Sears to sign up for MS-DOS 5.

Engel Decl., Ex. 23 (emphasis added).

2. Robert Frankenberg, who at the time was Vice President at Hewlett Packard, summarized the view among OEMs that they could not risk licensing DR DOS since Microsoft intended to prevent DR DOS from remaining compatible with Windows:

[T]here was a significant amount of fear, uncertainty, and doubt in the industry surrounding whether [DR DOS] would remain compatible with Windows, and that had a significant impact on whether people believed that it would continue to be a viable platform.

Frankenberg Dep. at 56, Record Support, v.3 to Consolidated Statement of Facts.

3. Even Microsoft recognized that the combined impact of the beta test exclusion, incompatibilities and AARD code had been devastating to DR DOS. In December 1991, Brad Silverberg stated:

Exhibit 256 (emphasis added); see also Exhibit 294 ("It¹s truly a wonderful thing that we¹ve done to DR¹s sales in the last 2 mos. Some of this was due to W31 [Windows 3.1] FUD. . . .").

1. Microsoft Publicly Denied the Truth About the Incompatibilities It Had Created.

1. Microsoft knew it¹s conduct was predatory. Whenever someone confronted a senior Microsoft executive with a question or an accusation about the AARD code and related matters, Microsoft denied the truth. As Cole said in his original e-mail about creating DR DOS/Windows incompatibilities, "the less people know about exactly what gets done the better." Exhibit 206.
2. A beta tester asked Brad Silverberg about exclusion of DRI from the beta program and the AARD code "error" message. Silverberg responded:

That¹s correct‹we have not made DRI a win 3.1 beta. . . .

I forgot to say that Windows is designed and tested to work with MS-DOS. We do no testing at all with DR DOS and we do not know first hand whether it¹s compatible with Win 3.1 or not. There is no code in Windows that says, "if DR-DOS then . . .". We don¹t detect it.

Exhibit 443 (emphasis added).

3. Mr. Silverberg¹s public statement is false in several respects. First, he says, "We do no testing at all with DR DOS and we do not know first hand whether it¹s compatible with Win 3.1 or not." But, as shown previously:

• Microsoft tested DR DOS 5.0 and 6.0 extensively itself, as well as contracting with independent testing laboratories to test DR DOS. Exhibits 116, 123, 210 & 168; Deposition of Tom Lennon ("Lennon Dep.") at 220, Record Support, v.1 to Consolidated Statement of Facts.
• Microsoft¹s tests and those done by independent testing laboratories and software industry reviewers confirmed that DR DOS was fully compatible with Windows 3.0, with the initial beta of Windows 3.1, and that DR DOS would be compatible with Windows 3.1 unless Microsoft purposely engineered incompatibilities into Windows. Exhibits 4, 78, 106, 109, 123 & 116; Deposition of Mark Chestnut ("Chestnut Dep.") at 47 & 54, Record Support, v. 1 to Consolidated Statement of Facts ¶ 210; ¶¶ _____, above.

1. In response to subsequent trade press inquiries about the incompatibilities, Microsoft consistently repeated the same false statement:

Microsoft does not test Windows on anything other than Microsoft¹s MS-DOS. We don¹t have the development or testing resources, nor do we consider it our job to test Windows on other systems.

Engel Decl., Ex. 24 (InfoWorld, November 22, 1993).

2. Silverberg¹s public statement is also false in that he says, "There is no code in Windows that says, ŒIf DR DOS then. . . .¹ We don¹t detect it." Yet, as shown above, the code was carefully designed to detect only DR DOS. See Response to ¶ 12 to Microsoft¹s Undisputed Facts Regarding the AARD Code.
3. Moreover, at one point, the Windows¹ development team proposed that the error message say, "The Windows setup program has detected another operating system on your machine." Exhibit 270. Silverberg responded:

I am wondering if we should change the detection words to say we failed to detect MS-DOS, rather than say we detected an operating system other than MS-DOS. The latter words would make people think we are looking for DR DOS . . . .

Id. (emphasis added).

4. Finally in 1993, sophisticated software developer, Andrew Schulman, succeeded in de-encrypting the AARD Code. He passed along his findings to the FTC, and sent an e-mail to Silverberg.

I have stumbled across a really awful piece of code (with the initials) "AARD"! in four separate programs in Windows. . . . This AARD code is deliberately obfuscated, encrypted with XORs, attempts to disable a debugger. . . . But after much effort by myself and Geoff Chappell, we have found that the purpose of this code (in Windows!!) is to check for genuine MS-DOS by checking several otherwise-irrelevant things in the DOS data segment. In two beta versions of Windows, this code when run on DR DOS produced error messages. . . . Brad, I am extremely pissed at Microsoft. I have been trying to defend you guys against what I thought were stupid allegations, and now I find out that in fact the company has done something really bad. I have passed my findings on to the FTC.

Exhibit 363.

5. Schulman¹s findings were reported in the September 1993 edition of Dr.  Dobb¹s Journal, a software industry publication. Silverberg responded to Schulman. His response was published in Dr. Dobb¹s Journal. As in the past, Silverberg denied the truth about what Microsoft had done:

It has never been the practice of this company to deliberately create incompatibilities between Microsoft system software and the system software of other OS (operating system) publishers. . . . The intended purpose of this disclosure message was to protect the customer and reduce the product support burden from the use of Windows on untested systems.

Exhibit 381 (Letter from Silverberg to Schulman in Dr. Dobb¹s Journal; emphasis added).

6. Silverberg¹s statement in Dr. Dobb¹s Journal stands in stark contrast to the statements he and others made in internal Microsoft e-mail:

what the guy is supposed to do is feel uncomfortable, and when he has bugs, suspect that the problem is dr dos and then go out to buy ms dos. or decide not to take the risk for the other machines he has to buy for the office.

Exhibits 277 & 278.

7. Schulman was not fooled. He responded to Microsoft:

Exhibit 369 (emphasis added).

1. SUMMARY JUDGMENT STANDARD

Summary judgment is inappropriate unless the record shows there are no issues of material fact and the moving party is entitled to judgment as a matter of law. Fed. R. Civ. P. 56(c). In the context of antitrust cases, courts are reluctant to grant summary judgment on the issue of whether a particular type of conduct is anticompetitive. See, e.g., Ratino v. Medical Service, 718 F.2d 1260, 1268 n.23 (4^th Cir. 1983) ("The question of whether a restraint promotes or suppresses competition is not one that can typically be resolved through summary proceedings. Rather, resolution must await a full-developed trial record.").

2. ARGUMENT

1. Caldera¹s Claims Are Section 2 Claims and Should Be Evaluated Under That Standard.

The antitrust laws permit‹indeed, encourage‹rivals to compete vigorously by producing better, cheaper, and more attractive products. Because of Microsoft¹s dominance, however, its actions must be "examined through a special lens: behavior that might otherwise not be of concern to the antitrust laws‹or that might even be viewed as pro-competitive‹can take on exclusionary connotations when practiced by a monopolist." Eastman Kodak Co. v. Image Technical Services, Inc., 504 U.S. 451, 488 (1992) (Scalia, J., dissenting) (citing 3 P. Areeda & D. Turner, Antitrust Law, ¶ 813 at 300-302 (1978)). When a monopolist such as Microsoft uses its power to "foreclose competition, to gain a competitive advantage, or to destroy a competitor," it violates the law. Eastman Kodak, 504 U.S. at 482-483 (quoting United States v. Griffith, 334 U.S. 100, 107 (1948)). Indeed, "[t]he anti-trust laws are as much violated by the prevention of competition as by its destruction." Lorain Journal Co. v. United States, 342 U.S. 143, 154 n.7 (1951) (emphasis added) (quoting Griffith, 334 U.S. at 107). Here, Microsoft did both.

To prove unlawful monopolization in violation of Section 2 of the Sherman Act, Caldera need only establish: (1) monopoly power, and (2) the acquisition or maintenance of that power through exclusionary conduct. See TV Communications Network, Inc. v. Turner Network Television, Inc., 964 F.2d 1022, 1025 (10th Cir.), cert. denied, 506 U.S. 999 (1992); see also Aspen Skiing Co. v. Aspen Highlands Skiing Co., 472 U.S. 585, 596 n.19 (1985); United States v. Grinnell Corp., 384 U.S. 563, 570-71 (1966).

Monopoly power is "the power to control prices or exclude competition," Grinnell, 384 U.S. at 571 (quoting United States v. E. I. du Pont de Nemours & Co., 351 U.S. 377, 391 (1956)), and "ordinarily may be inferred from the predominant share of the market" controlled by the alleged monopolist. Id. Market shares in excess of 60 to 70 percent are generally adequate to establish market power. See, e.g., Reazin v. Blue Cross & Blue Shield of Kansas, Inc., 899 F.2d 951, 967-70 (10th Cir.) (market share of approximately 60% supported jury verdict of monopolization), cert. denied, 497 U.S. 1005 (1990); see also Eastman Kodak, 504 U.S. at 481-82 (citing cases); 3A P. Areeda & H. Hovenkamp, Antitrust Law, ¶ 801a at 301 (1996) (reasonable to presume substantial market power when defendant¹s share of relevant market exceeds 70-75% for the five years preceding the complaint). Caldera has presented evidence that Microsoft exercised monopoly power in both of the relevant markets: the DOS market and the graphical user interface ("GUI") market. See Consolidated Statement of Facts 2 n.2 & ¶ 110. Microsoft nowhere denies this fact. Instead, Microsoft insists that its conduct was not exclusionary.

Exclusionary conduct is conduct that attempts to "¹exclude rivals on some basis other than efficiency¹. . . ." Aspen Skiing Co. v. Aspen Highlands Skiing Corp., 472 U.S. 585, 605. Prohibited exclusionary conduct is conduct that impairs the opportunities of rivals to compete and does not "further competition on the merits or does so in an unnecessarily restrictive way." Id. at 605 n.32 (citation omitted); see also Multistate Legal Studies, Inc. v. Harcourt Brace Jovanovich Legal & Professional Publications, Inc., 63 F.3d 1540, 1550 (10th Cir. 1995), cert. denied, 516 U.S. 1044 (1996); Data General Corp. v. Grumman Systems Support Corp., 36 F.3d 1147, 1182 (1st Cir. 1994). In Aspen, the Supreme Court instructed that courts consider the impact of conduct on consumers, competitors, and the monopolist itself, as well as whether the conduct "impaired competition in an unnecessarily restrictive way." 472 U.S. n.32 (emphasis added). The monopolist¹s purpose for taking the challenged actions is helpful in determining whether the conduct is exclusionary. Id. at 602. As the Tenth Circuit has explained: "Predatory practices are illegal if they impair opportunities of rivals or are more restrictive than reasonably necessary for such competition." Instructional Systems Development Corp. v. Aetna Cas. & Surety Co., 817 F.2d 639, 649 (10th Cir. 1987) (emphasis added). The actions of a monopolist bear heightened scrutiny. Intergraph Corp. v. Intel Corp., 3 F. Supp. 2d 1255 (N.D. Ala. 1998); see also cases cited in Product Disparagement Response, Section III.B.

Microsoft attempts to avoid this standard by asking this Court to evaluate certain acts in a vacuum. For example, Microsoft seeks to have this Court consider the incompatibilities Microsoft intentionally created between DR DOS and Windows 3.1 without taking into account the fact that Microsoft blacklisted DRI from the Windows 3.1 beta program, thereby guaranteeing that DRI could not determine the cause of the incompatibilities and remedy them in a timely manner. The Tenth Circuit has specifically rejected this piecemeal approach to Section 2 claims:

Plaintiff¹s evidence should be viewed as a whole. Each of the Œsix things¹ viewed in isolation need not be supported by sufficient evidence to amount to a Section 2 violation. It is enough that taken together they are sufficient to prove the monopolization claim.

Aspen Highlands Skiing Corp. v. Aspen Skiing Co., 738 F.2d 1509, 1522 n.18 (10^th Cir. 1984), aff¹d, 472 U.S. 585 (1985); see also cases cited in Caldera Inc.¹s Motion to Strike Microsoft¹s Partial Summary Judgment Briefs Relating to Substantive Antitrust Violations.

2. Microsoft¹s Predatory Scheme Plainly Violated Section 2.

The question before the Court is thus a straightforward Section 2 inquiry that asks whether, taking account of the heightened standard applied to monopolists, Microsoft¹s conduct was exclusionary. This is not a close question. Microsoft¹s conduct in executing a plan to create "fear, uncertainty and doubt" ("FUD") as a means of driving DR DOS out of the market was anything but competition on the merits. Consider what the evidence shows:

• Microsoft had monopoly power in the DOS and GUI markets (Microsoft does not contest this point);
• Windows and DOS are complementary products‹Windows requires DOS to run (see Response to Statement of Undisputed Facts Regarding Predisclosure Claim ¶ 3);
• Microsoft included code in Windows 3.1 that was designed to detect DR DOS and then, when it did, halt operation (see, e.g., Statement of Additional Material Facts ¶ 43);
• Microsoft included code in Windows 3.1 that was designed to detect DR DOS and then, when it did, display false error messages (see, e.g., Statement of Additional Material Facts ¶¶ 44-45);
• Microsoft included code in Windows 3.1 that prevented Windows from working with DR DOS and had no technical benefit whatsoever (see, e.g., Statement of Additional Material Facts ¶¶ 49-50);
• Microsoft blacklisted DR DOS from the Windows 3.1 beta program, which ensured both that DRI would be unable to respond to the DR DOS/Windows incompatibilities created by Microsoft and that the market knew that Microsoft would thwart efforts by DRI to ensure compatibility (see, e.g., Statement of Additional Material Facts ¶ 66);
• Microsoft publicly blamed the problems it created on DR DOS (see Statement of Additional Material Facts ¶¶ 34, 58, 62-63 & 67-76);
• Microsoft publicly denied that it had created the incompatibilities, leaving users with the impression that the problems were caused by DR DOS (see Statement of Additional Material Facts ¶¶ 58, 62-63 & 67-76); and,
• When users asked about the cause of the problems, Microsoft did not admit that it had created them‹instead, users were told to switch to MS-DOS (see, e.g., Statement of Additional Material Facts ¶¶ 62-63).

Microsoft does not, of course, agree with all of these statements, but that is beside the point. At the very least these are disputed issues of material fact. And it is clear that none of this conduct can be justified as competition on the merits‹it is difficult to imagine how any of this could be could be characterized as anything other than an attempt to "¹exclude rivals on some basis other than efficiency¹. . . ." Aspen Skiing Co. v. Aspen Highlands Skiing Corp., 472 U.S. at 605 (1985).

1. Microsoft¹s Predatory Scheme Caused Antitrust Injury.

Antitrust injury is an element in a private antitrust damages action under Section 4 of the Clayton Act. Reazin, 899 F.2d at 960 (citations omitted). The Tenth Circuit has stated that a plaintiff seeking damages under the antitrust laws must show injury in fact, i.e., "a causal connection between the defendant's actions violative of the Sherman Act and the actual injury to the plaintiff's business." Instructional Systems, 817 F.2d at 650 (quoting King & King Enterprises v. Champlin Petroleum Co., 657 F.2d 1147, 1156 (10th Cir. 1981), cert. denied, 102 S. Ct. 1038 (1982)); see also Reazin, 899 F.2d at 962 n.15.

The standard is not difficult to satisfy. Under Tenth Circuit law, "a plaintiff¹s burden to show injury in fact Œis satisfied by its proof of some damage flowing from the unlawful conspiracy,¹ which may be established by reasonable inferences drawn from circumstantial evidence." Instructional Systems, 817 F.2d at 650 (quoting World of Sleep, Inc. v. La-Z-Boy Chair Co., 756 F.2d 1467,1478 (10th Cir.), cert. denied, 106 S. Ct. 77 (1985)). For instance, in Reazin, where Blue Cross had announced termination of plaintiff as a contracting provider hospital, it was sufficient that plaintiff had lost patients; reduced its price to retain market share; and spent money on advertisements to reassure patients that Blue Cross subscribers were still welcome. 899 F.2d at 962; see also Aspen Highlands, 738 F.2d at 1522-25 (antitrust injury shown where defendant's refusal to offer its three mountains in skiing package with plaintiff¹s mountain resulted in diminished revenue to plaintiff).

Moreover, Section 2 prohibits not only the acquisition of monopoly but its maintenance as well. Lorain Journal, 342 U.S. at 154 n.7. When a company maintains its monopoly position, by definition it prevents competition from occurring. There may be no visible change in prices or quantities, because the monopoly has been preserved, but the harm to competition exists nonetheless: prices are higher and output lower than would have been the case without the exclusionary conduct. For this reason, "[i]njury to competition is presumed to follow from the conduct proscribed by § 2." Walker v. U-Haul Co. of Mississippi, 747 F.2d 1011, 1013 (5th Cir. 1984) ("Section 2 of the Sherman Act . . . does not explicitly require a plaintiff to prove an injury to competition; the plaintiff must prove only the existence of monopoly power and the willful continued maintenance of that power."). Again, intent can be relevant to this inquiry: "Intent determines whether the challenged conduct is fairly characterized as exclusionary or anti-competitive." City of Chanute v. Williams Natural Gas Co., 955 F.2d 641, 654 (10^th Cir. 1992) (citing Aspen Skiing Co., 472 U.S. 585).

Here, the evidence establishes a causal connection between Microsoft¹s predatory acts and injury to DR DOS¹ business. Microsoft¹s anticompetitive tactics, including its efforts during the Windows 3.1 beta program caused potential customers to select MS-DOS, rather than DR DOS, because they believed DR DOS would not run Windows. See, e.g., Barnett Report, Record Support, v.6 to Consolidated Statement of Facts. There is a clear link between the harm suffered and Microsoft¹s predatory acts. See id.; see also Statement of Additional Material Facts ¶ 65. DRI lost business as a direct result of these acts. For example, a potential corporate account told DRI that it was rejecting DR DOS 6.0 because of Microsoft¹s exclusionary refusal to allow DRI to beta test Windows 3.1. See id. ¶ 35. IBM, expressing concerns about DR DOS/Windows compatibility during the height of Microsoft¹s campaign to induce fear about DR DOS/Windows compatibility decided against licensing DR DOS. See id. ¶ 37. And even though Zenith Data Systems determined that the non-fatal error messages "in fact didn¹t reflect any operational problems or incompatibilities," it nevertheless abandoned consideration of DR DOS 6.0 because it feared Microsoft would "intentionally put code in Windows that would cause problems with DR DOS." See id. ¶ 60. DRI also lost Sears¹ business when Sears demanded a guarantee of compatibility with future versions of Windows. See id. ¶ 64. As Microsoft itself recognized, its tactics had the damaging effect desired. See Exhibit 256 ("oem¹s and corporations that are thinking about standardizing on dr-dos now have reasons to worry about their decision. they know they will have problems now, and they know we are not going to help dr-dos compete with us."); see also Exhibit 294 ("It¹s truly a wonderful thing that we¹ve done to DR¹s sales in the last 2 mos. Some of this was due to W31 [Windows 3.1] FUD. . . ").

By eliminating DR DOS, Microsoft eliminated the only real competition it faced in the DOS market. Microsoft¹s market share in the DOS market averaged more than 90% between 1989 and 1992, and increased further after that time. Leitzinger Report at 12, Record Support, v.7 to Consolidated Statement of Facts; see also Engel Decl., Exhibit 9. With the demise of DR DOS, Microsoft¹s market share increased. Not surprisingly, the standard measure of market concentration, the HHI index, rose sharply after DR DOS effectively exited the market. Leitzinger Report at 44, Record Support, v.7 to Consolidated Statement of Facts.

At the same time, Microsoft eliminated any real price competition when it eliminated DR DOS. Competition from DR DOS had forced Microsoft to lower its MS-DOS prices by as much as 30-40%. Bill Gates recognized as much, and complained to others at Microsoft about it. See Exhibit 27 ("The DOS gold mine is shrinking and our costs are soaring . . . I believe people underestimate the impact DR DOS has had on us in terms of pricing."); see also Additional Statement of Material Facts ¶ 5, Kearl Report, appendices 1-4, Record Support, v.6 to Consolidated Statement of Facts. Thus, MS-DOS prices dropped when DR DOS entered the market, and rose after DR DOS was effectively eliminated as a competitor. Kearl Report at 26, Record Support, v.6 to Consolidated Statement of Facts.

Without DR DOS as a competitor, Microsoft also lost competitive pressure to innovate with respect to MS-DOS. Microsoft itself concedes that before DR DOS entered the market, Microsoft had allowed MS-DOS to stagnate. See Exhibit 38 ("[O]ver the last four years we have done very little with it [MS-DOS] technically . . ."). Hardware had outrun PC operating system capabilities, and Microsoft had failed to respond. See Goodman Report, Exhibit C, Record Support, v.6 to Consolidated Statement of Facts. While DR DOS was in the market, Microsoft was forced to innovate, adding features to match those of DR DOS. Id.; see also Exhibit 195 ("One of the most important stimulants for adding features [to MS-DOS 5.0] was competitive pressure from DR DOS 5.0 . . ."). In contrast, after Novell stopped active development of DR DOS in September of 1994, Microsoft stopped development of MS-DOS. With the exception of a minor update of MS-DOS from version 6.20 to 6.22, Microsoft has not released any new standalone versions of DOS since September of 1994. The harm to competition could not be more evident.

The remainder of this memorandum addresses more specifically the arguments raised by Microsoft, the standards Microsoft seeks to have applied and the evidence that undermines Microsoft¹s position. Under the Section 2 standard set forth above, none of this analysis is necessary or especially relevant‹it is plain that, at a minimum, Caldera has raised material issues of fact regarding whether Microsoft¹s predatory conduct violated Section 2, and that is all that is required.

1. Microsoft Violated Section 2 When It Blacklisted DRI.

1. Beta Blacklist.

Microsoft¹s beta blacklist crossed the line between lawful, vigorous competition and exclusion. Conduct of this type is predatory when it preserves a monopolist¹s market dominance: "[A] monopolist¹s unilateral refusal to deal with its competitors (as long as the refusal harms the competitive process) may constitute prima facie evidence of exclusionary conduct in the context of a Section 2 claim." Data General v. Grumman Systems Support Corp., 36 F.3d 1147, 1183 (1^st Cir. 1994) (citing Eastman Kodak, 504 U.S. at 483 n.32).

Although even a monopolist has a right not to deal with its competitors, this right is qualified. Aspen, 472 U.S. at 600-01. The Supreme Court established the rule regarding one company¹s obligation to do business with another in United States v. Colgate: "In the absence of any purpose to create or maintain a monopoly, [Section 1 of] the act does not restrict the long recognized right of a trader or manufacturer engaged in an entirely private business, freely to exercise his own independent discretion as to parties with whom he will deal." United States v. Colgate & Co., 250 U.S. 300, 307 (1919) (emphasis added). But where the refusal to deal serves to monopolize, it is prohibited by Section 2. Eastman Kodak, 504 U.S. at 483 n.32; Aspen, 472 U.S. at 601-03; Lorain Journal, 342 U.S. at 155. Thus, Colgate does not protect a monopolist that "[r]etaliates against customers who have the temerity to compete with him, by cutting such customers off . . . in order to discourage competition." Olympia Equipment Leasing Co. v. Western Union Telegraph Co., 797 F.2d 370, 377 (7th Cir. 1986), cert. denied, 480 U.S. 934 (1987).

Microsoft¹s exclusion of DRI from the Windows 3.1 beta program was part of an overall plan to cause the market to believe DR DOS was incompatible with Windows, and thereby eliminate DR DOS as a competitive threat. The purpose and effect of Microsoft¹s plan was to maintain its DOS monopoly. As such, excluding DRI from the beta program violated Section 2.

2. Microsoft Violated Section 2 When It Unlawfully Used Its Market Power in the Windows Market to Destroy Competition in the DOS Market.

A monopolist is not permitted to use its market power in one market to gain competitive advantage in another market. Berkey Photo, Inc. v. Eastman Kodak, Co., 603 F.2d 263, 276 (2^nd Cir. 1979), cert. denied, 444 U.S. 1093 (1980) (use of monopoly power attained in one market to gain a competitive advantage in another is a violation of §2, even if there has not been an attempt to monopolize the second market); Eastman Kodak, 504 U.S. at 479 n.29 ("The Court has held many times that power gained through some natural and legal advantage such as a patent, copyright, or business acumen can give rise to liability if a seller exploits his dominant position in one market to expand his empire into the next"). The requirements for liability include: "[m]onopoly power in one market; the use of that power, however lawfully acquired, to foreclose competition, to gain a competitive advantage or to destroy a competitor in another market; and injury caused by the challenged conduct." Grand Light & Supply Co. v. Honeywell, Inc., 771 F.2d 672, 681 (2d Cir. 1985); see also Kerasotes Mich. Theatres v. National Amusements, Inc., 854 F.2d 135, 136-37 (6^th Cir.), reh¹g denied, (1988), cert. dismissed, 490 U.S. 1087 (1989).

Microsoft had to market its power in Windows because, as the monopolist in the GUI market, it controlled basic product information indispensable to the business of almost every OEM and software developer. By cutting off DRI‹and publicly broadcasting this fact‹Microsoft knew that OEMs would fear the stability of Windows running on top of DR DOS, thereby causing them to license MS-DOS, instead of DR DOS. See, e.g., Statement of Additional Material Facts ¶ 37; Exhibit 256; Exhibit 294. Microsoft also knew that blacklisting DRI would ensure that it could introduce incompatibilities between Windows and DR DOS while preventing DR DOS from identifying the source of the incompatibilities, much less fixing them.

Placing the DR DOS development team on the beta blacklist was a raw exercise of monopoly power designed to force DR DOS out of the DOS market. Even Microsoft management knew this retaliation against DR DOS was illegal. See Statement of Material Facts ¶ 32.

As explained in Aspen Highlands, sacrifice of short-term benefits is evidence of anticompetitive purpose and nature. When the defendant there refused to accept coupons or permit a competitor to purchase tickets in bulk for inclusion in a package deal, thereby foregoing profits, the Court held that it was reasonable to conclude that the defendant "elected to forgo these short-run benefits because it was more interested in reducing competition in the Aspen market over the long run by harming its smaller competitor." 472 U.S. at 608. Here, Microsoft likewise was motivated by the long-term preservation of its monopoly and was therefore willing to sacrifice, in the near term, its relationship with both current and potential customers. This is a hallmark of monopolization: by excluding DR DOS, Microsoft gave up the benefits it obtained from the cooperative relationship it had previously enjoyed with DRI. Microsoft¹s goal was to have "Windows everywhere." That meant allowing Windows to run on DR DOS as well as MS-DOS. When Windows was not yet a monopoly product‹i.e., prior to the success of Windows 3.0‹Microsoft permitted DR DOS to participate in the Windows 3.0 beta program, and hence, to allow Windows 3.0 to run on DR DOS. Post-monopolization, Microsoft deliberately chose to forego Windows¹ ability to run on DR DOS‹and so forced any OEM seeking to install Windows to choose MS-DOS. At the same time, Microsoft sacrificed sales of Windows 3.1 to PC owners who used DR DOS as their operating system, and it sacrificed the benefits that would accrue to Windows if DRI was able to develop DR DOS features that would enhance the performance of Windows.

3. Microsoft¹s Blacklisting of DRI Was Both an Unlawful Refusal to Deal and Denial of Access to Essential Facilities.

The case for liability is even stronger where, as here, a monopolist¹s refusal to deal denies a potential competitor access to an essential facility. The Tenth Circuit has addressed the "essential facilities" doctrine in several Section 2 cases involving refusals to deal. See, e.g., Tarabishi v. McAlester Regional Hosp., 951 F.2d 1558, 1568 (10th Cir. 1991), cert. denied, 505 U.S. 1206 (1992); City of Chanute, 955 F.2d at 647-49; McKenzie v. Mercy Hospital of Independence, Kansas, 854 F.2d 365,  368-70; and Aspen Highlands, 738 F.2d at 1520-22. The doctrine arose where "bottlenecks" were being abused to leverage monopoly power. See United States v. St. Louis Terminal Railroad Assoc., 32 S. Ct. 507 (1912) (association that controlled access to rail bridges spanning the Mississippi at St. Louis required to allow competing railroads use of facilities without regard to membership in association). A refusal to deal "may be unlawful because a monopolist¹s control of an essential facility (sometimes called a Œbottleneck¹) can extend monopoly power from one stage of production to another, and from one market into another." MCI Communications Co. v. AT&T, 708 F.2d 1081, 1132 (7th Cir. 1983), cert. denied, 464 U.S. 891 (1983).

Firms controlling an essential facility have an obligation to make the facility available on non-discriminatory terms. MCI Communications Co., 708 F.2d at 1132; Otter Tail Power Co. v. United States, 410 U.S. 366 (1973); Aspen Skiing Co. v. Aspen Highlands Skiing Corp., 472 U.S. 585 (1985) (access to essential facility must be granted by ski lift owner controlling seventy-five percent of the ski lifts); Tic-X-Press, Inc. v. Omni Promotions Co. of Ga., 815 F.2d 1407 (11th Cir. 1987) (Omni arena was unique facility with substantial economic advantages; lack of viable alternative arenas gave the owner substantial market power).

The Tenth Circuit applies the following elements in evaluating an essential facilities claim:

City of Chanute, 955 F.2d at 647.

In Aspen Highlands the Tenth Circuit explicitly approved and applied the doctrine. There, plaintiff controlled access to one mountain at Aspen and defendant controlled the other three. Suit arose when defendant refused to continue offering with plaintiff multi-day, multi-mountain packages for all four mountains as in past years. The court noted that defendant's refusal led to plaintiff's inability to compete in the market for multi-day, multi-mountain tickets. Yet by controlling three mountains, defendant could continue to offer such a ticket. The court found this "sufficiently analogous to satisfy the element of control of an essential facility." 738 F.2d at 1520-21.

More recently, the doctrine has been applied in the high-technology industry. See Intergraph Corp. v. Intel Corp., 3 F. Supp. 2d 1255 (N.D. Ala. 1997). Intel dominates the CPU (microprocessor) market. Intergraph is an OEM, dependent upon advance knowledge of forthcoming Intel chip-design advances. Without timely receipt of Intel¹s plans, Intergraph cannot make competitive computers immediately available. Intel¹s practice had been to provide Intergraph the advance specifications it needed, and in fact, Intel reviewed Intergraph designs to help "debug" Intergraph¹s products. When Intergraph attempted to assert certain patent protections of its own work, Intel precluded Intergraph from receiving future chip-design plans. The court entered a preliminary injunction against Intel:

Id. at 1278.

1. The Windows 3.1 Beta Program Constituted an Essential Facility.

Microsoft has not challenged that it exercises monopoly power in the relevant market. The threshold question, then, is whether access to the Windows 3.1 beta constitutes an essential facility.

The Intel court explicitly held that "[r]easonable and timely access to critical business information that is necessary to compete is an essential facility." Intel, 3 F. Supp. 2d at 1278 (citing Bellsouth Adver. & Publ¹g Corp. v. Donnelly Info. Publ¹g Inc., 719 F. Supp. 1551, 1566 (S.D. Fla. 1988), aff'd, 933 F.2d 952 (11th Cir. 1991). Similarly, access to advancing Windows technology was fundamental to DRI¹s attempt to carve out a niche of the DOS market; indeed, over time, nothing was more important. As far as GUIs were concerned, Windows was "the only game in town." Twin Labs, Inc. v. Weider Health & Fitness, 900 F.2d 566, 569 (2^nd Cir. 1990). Microsoft has intellectual property protections for that software which create significant barriers to entry.

But DRI had been able to develop successive versions of DR DOS that did not infringe on Microsoft¹s intellectual property rights in MS-DOS, and, at the same time, were compatible with all popular DOS applications, including Windows. As Windows became widely-used, the ability to run Windows became an essential feature of DOS. Microsoft¹s own witnesses admitted that timely access to Windows product information was critical to the success of software products that ran in conjunction with Windows. See Consolidated Statement of Facts ¶ 199. Indeed, Microsoft¹s behavior is tacit admission that Windows was vital to DRI¹s ability to create competitive DOS-based operating systems and Microsoft knew that denying DRI access to such software would give Microsoft a competitive advantage in the DOS operating system market.

2. DRI Could Not Duplicate the Windows 3.1 Beta.

The plaintiff need merely demonstrate that it is practically or reasonably unable to duplicate the essential facility. See Cyber Promotions, Inc. v. America Online, Inc., 948 F. Supp. 456, 464 (E.D. Pa. 1996). Given the legal obstacles and Microsoft¹s market power, it is undisputed that it would have taken a substantial period of time for either DRI or Novell to develop a competitive GUI. Until July 1991, DRI did not know that it would be excluded from the Windows 3.1 beta program; indeed, Microsoft had included DRI in the Windows 3.0 beta program. See Consolidated Statement of Facts ¶¶ 205-09. Even if DRI had started a Windows-competitor project in July 1991‹and it was in no position to do so‹it would have taken years to complete. It would not and could not have duplicated the Windows 3.1 beta program, which would have been long since completed.

In addition, Microsoft¹s argument on that score misreads the law, and would force DRI and Novell‹which competed with Microsoft in only one market‹to enter an entirely new market. It would be akin to forcing a hypothetical railroad company competing with the defendant of United States v. Terminal R.R. Ass¹n, 224 U.S. 383 (1912), to enter the bridge-building market to remain competitive in the railroad market. The essential facilities doctrine in essence forces a monopolist to allow non-discriminatory access to its monopoly product; it does not require a competitor in another market to attempt to displace the monopoly product.

3. The Denial of the Use of the Facility to a Competitor.

Microsoft does not dispute that it denied DRI access to the Windows beta program. The record is replete with evidence of Microsoft¹s attempts to ensure that the Windows beta releases were not disclosed to DRI. See Consolidated Statement of Facts ¶¶ 199-209; Statement of Additional Material Facts ¶ 63.

4. The Feasibility of Providing the Facility.

Microsoft easily could have provided Windows betas to DRI‹ in the same manner as beta programs, including the Windows 3.0 beta, had been distributed to DRI in the past, and as both subsequent beta programs and APIs were distributed to virtually every other legitimate software manufacturer who did not produce a competing DOS-based operating system. See Consolidated Statement of Facts ¶¶ 200-09. Indeed, a monopolist¹s duty to cooperate with a rival is stronger when the monopolist has a history of cooperating with the rival and did not have a valid business justification for its decision to terminate cooperation. Such reversal of cooperation is subject to heightened judicial scrutiny. See also Intel at 3 F. Supp. 2d 1255.

1. Microsoft¹s Justifications for Its Conduct Are Pretextual.

Business justifications are illegitimate when inconsistent with the facts of the case. See Aspen Highlands, 472 U.S. at 608-11. In Aspen Highlands, the Supreme Court rejected the business justifications offered by Aspen Ski Co., the defendant ski operator, for its decision to terminate an all-mountain lift ticket that it jointly offered with Aspen Highlands Skiing Corp., the plaintiff, because such justifications were not supported by the evidence presented:

Id. at 608-10 (emphasis added) (citations and footnote omitted); see also Image Technical Services, 125 F.3d at 1218 ("Neither the aims of intellectual property law, nor the anti-trust laws justify allowing a monopolist to rely upon a pre-textual business justification to mask anti-competitive conduct.").

Microsoft¹s actions are likewise inconsistent with any legitimate business purpose. It is illogical for Microsoft to deny DRI¹s (and later Novell¹s) DR DOS development team access to the Windows beta programs and APIs because they were "proprietary secrets," yet provide the software to hundreds of other legitimate software manufacturers, including other Novell software developers. See Consolidated Statement of Facts ¶ 200; see also Exhibit 20 to Microsoft¹s AARD Code Memo. (identifying cites by category). Each of these manufacturers had the ability to study and potentially to replicate Microsoft¹s software codes. Indeed, if Microsoft was concerned about Novell developing a GUI product competitive to Windows, as it claims in its summary judgment motion‹why did Microsoft allow Novell¹s developers, other than those working on DR DOS, access to the Windows 3.1 beta?

1. Intentional Incompatibilities.

1. The Section 2 Standard Governs the Inquiry.

Although Microsoft may wish it were otherwise, there is not a different, more favorable standard that will shield its predatory practice of introducing DR DOS incompatibilities in Windows 3.1. This practice was, as explained above, part of Microsoft¹s overall scheme to create fear, uncertainty and doubt about DR DOS/Windows compatibility. The conduct is part of the conduct that underlies Caldera¹s Section 2 claim‹and that conduct is judged under the same Section 2 standard set forth above. Moreover, Microsoft¹s FUD campaign was part of an array of predatory tactics used by Microsoft. The proper standard for judging Microsoft¹s conduct is, therefore, not restricted to the standard used by some courts to evaluate pure intentional incompatibility claims, but is, rather, the standard applied in Section 2 claims generally. In addition to monopoly power and anti-competitive injury, Caldera need only establish that Microsoft attempted to "exclude rivals on some basis other than efficiency." Aspen Skiing Co., 472 U.S. at 605. See Section V.A.1., above. The evidence plainly supports that conclusion.

2. Microsoft, In Any Event, Misstates the Intentional Incompatibility Standard.

Even if Microsoft¹s conduct were viewed solely as an intentional incompatibility claim, liability would nevertheless result. Perhaps it is for this reason that Microsoft grossly mischaracterizes the legal standards that apply to the evaluation of such claims. According to Microsoft, product incompatibility results in liability only when the incompatibility (1) prevents the operation of dependent products, (2) is done "solely for the purpose of crippling a competitor," and (3) is devoid of technical merit. Microsoft¹s Intentional Incompatibilities Memo. at 2-3. This is not the law.

Microsoft¹s second requirement‹sole purpose‹is the most glaring of its mischaracterizations. Microsoft cites Transamerica as authority for this standard. In fact, the Transamerica court in that case rejected the sole purpose standard in favor of another standard entirely. See In re IBM Peripheral EDP Devices Antitrust Litigation, 481 F. Supp. 965, 1003 (N.D. Cal. 1979) ("Transamerica"), aff¹d and modified on other grounds sub nom., Transamerica Computer Co. v. IBM, 698 F.2d 1377 (9th Cir. 1983). In rejecting the sole purpose standard, the court reasoned that "discerning corporate intent is seldom easy, and, in any event, the law against monopolization is much more concerned with the effect of conduct rather than with its purpose." Id. at 1003.

Microsoft¹s first and third requirements are similarly ungrounded. They appear to have been pieced together from contextually dissimilar snippets of other cases. Microsoft uses the first requirement (preventing operation of dependent products) to argue that any sabotaging of DR DOS during the beta process cannot give rise to liability‹which makes little sense, given the important marketing role the beta process plays in introducing new products. See Section V.C.3., below. Microsoft¹s third proposed requirement (that the incompatibility has no technical merit) exaggerates the amount of judicial deference allowed to technological justifications for design decisions. See, e.g., Northeastern Telephone Co. v. AT&T Co., 651 F.2d 76, 94 (2nd Cir. 1981) (although design choice was found to be an "adequate" solution to technical problem, the fact that the problem could have been solved another way without creating incompatibility was evidence of anticompetitive conduct). In any event, even if the law were as favorable to monopolists as Microsoft argues it is, Microsoft would still be liable, as explained below.

The proper standard for judging pure incompatibility claims is set forth in Transamerica, the case on which Microsoft relies: "If the design choice is unreasonably restrictive of competition, the monopolist¹s conduct violates the Sherman Act." Transamerica, 481 F. Supp. at 1003 (citing Sherman v. British Leyland Motors, Ltd., 601 F.2d 429, 452 n.46 (9th Cir. 1979)); see also California Computer Products, Inc. v. IBM Corp., 613 F.2d 727, 735-36 & 744 (9^th Cir. 1979) (test is whether defendant¹s conduct is "unreasonably restrictive of competition"). In determining whether a design choice is unreasonably restrictive of competition, a court is to consider the following factors:

• the effects of the design on competitors;
• the effects of the design on consumers;
• the degree to which the design was the product of desirable technological creativity; and,
• the monopolist¹s intent, since a contemporaneous evaluation by the actor should be helpful to the fact finder in determining the effects of a technological change.

Transamerica, 481 F. Supp. at 1003.

Intent and technical merit are, therefore, just two relevant factors to be considered in an incompatibility claim. Thus, even a design change that has some technical merit can give rise to liability if the design problem could have been solved without creating the incompatibility. Northeastern Telephone Co., 651 F.2d at 94. And despite Microsoft¹s assertions to the contrary, the technical merits of programming design decisions are not immune from scrutiny and are, of course, a proper subject of expert testimony. See Transamerica, 481 F. Supp. at 1003 & 1005; C.R. Bard, Inc. v. M3 Systems, Inc., 157 F.3d 1340, 1382 (Fed. Cir. 1998). That is all the more true where, as here, the so-called "design decisions" had no technical merit whatsoever. See Section C.3., below.

The Transamerica factors, furthermore, must be interpreted in light of the Supreme Court¹s later decision in Aspen Skiing Co., 472 U.S. 585 (discussed above). Aspen Skiing held that a monopolist¹s refusal to deal with a competitor results in liability where competition is unreasonably affected, especially when the refusal reverses an established pattern of dealing in that market or is a departure from the monopolist¹s conduct in similar, competitive markets. Id. at 603-04. Aspen debunks Microsoft¹s simplistic proposition that it has no duty to share information or do anything to promote compatibility other than to refrain from intentional acts whose sole purpose is to cripple a competing product.

1. Microsoft¹s Predatory Conduct Gives Rise to Liability Under Either Standard.

Microsoft created incompatibilities between DR DOS and Windows 3.1 in at least four different ways and between DR DOS and other Microsoft programs in at least two different ways. None of these design decisions had any technical merit, and all prevented DR DOS from operating properly with Windows. The Windows 3.1 incompatibilities consisted of the following:

• inclusion of DR DOS detection and disabling code in a component of Windows known as Smartdrive (which Microsoft referred to by the code name "Bambi");
• introduction of a bug in the implementation of DPMI in Windows 3.1 which prevented DR DOS users from installing Windows (this problem is commonly referred to as the "nested task flag problem");
• inclusion of a gratuitous version check in the Windows 3.1 setup program that created an incompatibility with DR DOS¹ memory manager (this problem is commonly referred to as the "XMS version check"); and,
• inclusion of code in the Windows 3.1 beta that detected DR DOS and displayed false error messages (this issue is commonly referred to by the identity of the code that produced the error messages, i.e., the "AARD code").

The other areas of incompatibilities arose out of: a module that was part of Windows for Workgroups called "Protman.dos"; the Korean (Hanguel) versions of Windows and some Microsoft applications programs; and, Windows 95. The evidence on each of these incompatibilities is discussed below.

1. Bambi.

Although Microsoft publicly denied ever doing so, Microsoft included code in a Windows 3.1 beta designed solely to detect DR DOS and then refuse to run. The code was included in Smartdrv, a module included with Windows and code-named "Bambi."

In 1991, Microsoft executives grew alarmed that IBM, the company that gave Microsoft its start, would soon announce its intention to license DR DOS. See Exhibits 198 & 197. In response to this concern and its concern that it had fallen behind DR DOS on technological merit, Microsoft decided to take advantage of its Windows monopoly. To do this, it undertook a plan to "make sure it [DR DOS] has problems [running Windows] in the future. . . ." Exhibit 197.

Microsoft introduced an incompatibility between DR DOS and certain versions of MS-DOS (including Compaq DOS) in Bambi. See Statement of Additional Material Facts ¶ 43. The programmer responsible for the problem fixed it, and Bambi functioned properly with DR DOS and the specific versions of MS-DOS that earlier had compatibility problems. See Statement of Additional Material Facts ¶ 43. Nevertheless, Phil Barrett, the lead developer on Windows 3.1, instructed the programmer to include code that would detect DR DOS and refuse to load. Barrett responded to the programmer¹s report as follows:

heh, heh, heh . . . my proposal is to have bambi refuse to run this alien OS ? Comments ? The approach we take is to detect dr 6 and refuse to load.

Exhibit 207 to Consolidated Statement of Facts. That is exactly what Microsoft did: in Smartdrive beta version 4.00.059 Microsoft included code that both eliminates the incompatibility with DR DOS and Compaq DOS and executes the DR DOS detection and refusal to load instruction as proposed by Barrett. Hollaar Decl. ¶ 4. The error message displayed did not tell the user what happened or why it happened. Once the message was displayed, Windows 3.1 then refused to run. See Statement of Additional Material Facts ¶ 43. Microsoft apparently obtained the information it needed to program this detection from DRI, by contacting DRI using a fictitious name. Consolidated Statement of Facts ¶¶ 256-58.

It is difficult to imagine a more blatant violation of Section 2 or, for that matter, the law as it applies to incompatibilities. The effect on DR DOS was obvious and drastic: the Microsoft program simply refused to run on DR DOS. And it did so by making it appear that DR DOS was incompatible with Windows. The effect on users was equally obvious and drastic: they could not run DR DOS with Bambi. More important, the detection and refusal to run code was not the product of "technological creativity," nor did it result in any technological benefit. Including the detection and refusal to run code did not allow Microsoft to implement some other desirable new feature‹it simply prevented DR DOS from working with Microsoft¹s product. Finally, although one could infer Microsoft¹s intent by the nature of the code itself and the complete lack of technological benefit associated with it, there is no need to do so. Microsoft answers that question directly: "heh, heh, heh . . . ." Exhibit 207. Microsoft¹s intent is further evidenced by its conduct during this time period: it consistently blamed DRI for any and all incompatibilities that arose during the Windows 3.1 beta cycle and it precluded DRI from gaining access to the information it would have needed to uncover the detection and refusal to run code.

Of course, under Section 2, none of this conduct can be justified. Microsoft cannot argue that including detection and refusal to run code was anything other than unnecessarily restrictive, nor can it argue that it amounted to competition on the merits. The code further demonstrates Microsoft¹s willingness to sacrifice short-run benefits‹revenue from Windows sales to DR DOS customers, goodwill, and increased compatibility between Windows and DR DOS‹to inflict harm on its competitor, which is the hallmark of anti-competitive conduct. See Aspen Skiing, 472 U.S. at 610-11. This is exactly the sort of conduct the antitrust laws seek to deter.

2. Nested Task Flag.

Microsoft also introduced an incompatibility early in the Windows 3.1 beta cycle that prevented users from installing Windows 3.1 with DR DOS. As part of the Windows 3.1 development process, Microsoft added something called DPMI support to Windows. Hollaar Decl. at ¶ 3. In the process of implementing DPMI support, Microsoft created an incompatibility between DR DOS and Windows. Id. The incompatibility resulted from the failure to include a single line of code that would have ensured the Nested Task flag was set properly when protected mode was initiated. As a result, when users tried to run Windows on DR DOS, Windows would refuse to load. The user encountered a fatal error message, which did not identify the cause of the problem. ("Standard Mode: Fault in MS-DOS Extender.") See Hollaar Decl. ¶ 3.

This incompatibility was introduced early in the beta cycle and was not remedied by Microsoft in the production release. The evidence shows that Microsoft knew about the incompatibility, knew the cause of the incompatibility, and knew how to remedy it. See Hollaar Decl. ¶ 3. To correct the error would have required the addition of a single line of code by Microsoft. Microsoft argues to the contrary, but Caldera¹s experts have determined that there was no technical benefit to Windows (or, for that matter, to any other program) that resulted from the introduction of this incompatibility. Id. It was not required for or even helpful to Windows in implementing DPMI or in running setup in Standard Mode‹in fact, it was a hindrance. Id. And it was contrary to accepted programming practices to fail to clear the Nested Task flag. Id. Moreover, if DRI had been allowed to participate in the Windows 3.1 beta program, it would have been a relatively simple matter for DRI to code a work around that would have eliminated the incompatibility. Id.

The incompatibility was serious, it was publicized, and users complained about it. See Statement of Additional Material Facts ¶¶ 62-63. For example, the trade press reported the problem in December 1991‹and DRI had no way to respond, because Microsoft had blacklisted DRI from the Windows 3.1 beta. See, e.g., Statement of Additional Material Facts ¶ 34. At the same time, customers were complaining to Microsoft about the problem, but Microsoft was simply blaming the problem on DR DOS. Engel Decl., Ex. 22. And Microsoft itself asserts, as an undisputed fact, that the reports of incompatibilities were widespread. See Undisputed Fact 7 in Microsoft¹s AARD Code Memo.

Just as Bambi satisfies both the Section 2 standard and Microsoft¹s alleged incompatibilities standard so, too, does the Nested Task flag incompatibility. The effect on DR DOS and consumers was the same: it prevented DR DOS from running with Windows. The incompatibility had no technical benefit; to the contrary, it was a programming bug that caused problems. It was not the product of any design creativity. And Microsoft¹s intent is plain from the facts: Microsoft blacklisted DRI from the beta program, thus ensuring whatever incompatibilities arose, DRI would not be able to respond to them. Furthermore, Microsoft knew the cause of the Nested Task flag problem yet refused either to remedy it or at least allow DRI to have access to the beta which would have permitted DRI to write code to avoid the problem. Instead, Microsoft publicly blamed the problem on DR DOS. There is no efficiency justification for this conduct, and there is no benefit to competition or consumers. To the contrary, this is another example of conduct designed to preclude competition. Finally, as is true with Bambi, Microsoft¹s willingness here to impair the performance of its own product‹Windows‹is a short term sacrifice characteristic of the exercise of monopoly power condemned in Aspen Skiing.

3. XMS Version Check.

Microsoft included code in the setup program of Windows 3.1 that tested the internal version number of something called the extended memory specification, which is commonly referred to as XMS. See Hollaar Decl. ¶ 5. DR DOS failed the test; MS-DOS passed the test. The test was completely gratuitous‹the setup program that included the test made no use of XMS, so it did not matter what version it found. Id. The other Windows modules that made use of XMS had their own version checks‹and DR DOS passed all those version checks, because DR DOS¹ XMS was compatible with Windows. Id. Thus, Microsoft¹s setup XMS check accomplished one thing and one thing alone: it created another incompatibility with DR DOS. See id. This incompatibility was new to Windows 3.1; the problem had not occurred in previous versions of Windows.

This incompatibility, like Bambi and like the Nested Task flag problem, gives rise to liability under the general Section 2 standard and under Microsoft¹s alleged incompatibility standard. The incompatibility harmed DR DOS and DR DOS users by making it impossible to run DR DOS¹ memory manager with Windows. The incompatibility had no technical benefit‹the test was gratuitously included in a module that made no use of XMS and those that did included tests that DR DOS passed. To the extent intent is relevant, it is easily inferred. The test¹s only effect was to exclude DR DOS, it was implemented during the time DRI was blacklisted from the beta program, and it was done during a time period when Microsoft was including other code in Windows 3.1 designed specifically to prevent DR DOS from operating properly‹or at all‹with Windows.

4. AARD Code.

Microsoft also included secret, encrypted code in five different modules in the third Windows beta. See Hollaar Report, Record Support, v.6 to Consolidated Statement of Facts. The code was designed to detect DR DOS and then display error messages. Id. The error messages did not identify the cause of the supposed error‹they simply told the user an error had occurred and, for several of the messages, halted operation and asked the user to decide whether to hit "enter" to terminate Windows or "C" to continue. Id. The messages also encouraged users to contact Microsoft. Id. The messages were false: as Microsoft itself admits, no error had occurred. See Statement of Additional Material Facts ¶ 48. The users did not know this, however, and Microsoft never revealed the truth. Indeed, when users contacted Microsoft about the errors they were told that they could eliminate the errors by switching from DR DOS to MS-DOS. See Statement of Additional Material Facts ¶ 58; Engel Decl., Ex. 22. All of this is described in more detail, in Section V.D., below.

This incompatibility too gives rise to liability and it does so regardless of the standard that is applied. Under Microsoft¹s alleged incompatibilities standard, the factors weigh heavily against Microsoft. The code¹s effect on DR DOS and its users was plain: it created alarming error messages, even though no error actually existed, leaving DR DOS and users with the clear impression that DR DOS was incompatible with Windows. One expert compares the messages to learning that you have a tumor but did not learn until much later that it is benign. There was no technical benefit associated with the messages‹indeed, they did nothing to improve Windows performance and, in fact, made Windows more difficult to maintain. See Hollaar Report at 5, Record Support, v.6 to Consolidated Statement of Facts. And Microsoft¹s intent could be inferred, but there is no reason to do so; Brad Silverberg, the Microsoft executive responsible for the code, explained why the false error messages were included:

What the guy is supposed to do is feel uncomfortable, and when he has bugs, suspect that the problem is DR DOS and then go out to buy MS-DOS. Or decide to not take the risk for the other machines he has to buy for in the office.

Exhibits 277 & 278.

5. Windows 95.

Microsoft also foreclosed all competition in the DOS market by altering Windows with the release of Windows 95 to run only with the MS-DOS packaged with Windows 95. Microsoft¹s argument that MS-DOS was equally disadvantaged by Windows 95 ignores the fact that MS-DOS is in fact packaged with Windows 95. The nature of the incompatibilities Microsoft created are discussed more fully in Caldera¹s response to Microsoft¹s "Technological Tying" motion.

6. Other Incompatibilities.

Microsoft created several other incompatibilities with DR DOS. The dispute over the incompatibility Microsoft created in a version of Windows for Workgroups centers on a module of code call PROTMAN.DOS. Microsoft argues that the incompatibility was the result of a problem in DR DOS, not Windows for Workgroups, that there was no true incompatibility because the problem was eventually corrected by DRI, and that the incompatibility could not have been intentional because the PROTMAN.DOS code was written by a third party, a company called 3COM. All three arguments fail.

The only evidence Microsoft cites to support its claim that the problem resided in DR DOS is the deposition testimony of John Constant, the chief technical officer of DRI. In fact, however, Mr. Constant testified that the incompatibility resulted from a "very dubious technique" of programming by Microsoft. See Constant Dep. 175, Record Support, v.3 to Consolidated Statement of Facts. In light of the Transamerica test and Microsoft¹s obligations under Aspen Skiing, Mr. Constant¹s testimony alone is sufficient to defeat summary judgment. Moreover, Microsoft¹s argument that no incompatibility resulted because DRI eventually fixed the problem ignores the obviously detrimental effects of the delay in achieving incompatibility, as well as the damage to DRI¹s goodwill and reputation from having to issue corrective patches for a released version of its product.

Finally, Microsoft¹s intent argument is implausible; it asks the Court to believe that Microsoft had no interaction with the company that wrote a critical piece of code for Windows for Workgroups. Because no module of software code exists completely independent of others in the program, PROTMAN.SYS could not have been written in isolation and inserted into Windows without assistance from Microsoft.

Microsoft also asserts that Caldera has no evidence to support its claim that Microsoft included software locks in the Hanguel (Korean) versions of some of its applications products. Microsoft then points to marginalia written by a Novell attorney in October of 1990 indicating a lack of evidence and the absence of a Hanguel reading computer at DRI¹s European Headquarters to suggest that Caldera committed a Rule 11 violation by asserting this claim. See Microsoft¹s Intentional Incompatibility Memo. at 10. Microsoft must have neglected to check the deposition transcripts before making such remarks. The DRI Vice-President for Far Eastern OEM sales, Richard Dixon, testified that he witnessed the software lock in question. Through the work of engineers from Hope Electronics, who decompiled the code, DRI determined that the cause of the lock was an instruction Microsoft had placed in the application. See Dixon Dep. at 42-48, Record Support, v.3 to Consolidated Statement of Facts. The software lock demonstration and resulting code decompilation took place in Korea, not Europe. Id. Novell¹s attorneys later included the Korean software locks claim as part of their submission to the Federal Trade Commission in 1992. Engel Decl., Ex. 27 at ¶ 50. Given the instruction from Bill Gates that all Microsoft applications should detect and impede DR DOS, and Microsoft e-mail that indicates his instruction was followed for Microsoft¹s Hanguel versions, the locks in the Hanguel applications are consistent with Microsoft¹s internal documents, and with Microsoft¹s predatory strategy as a whole. Exhibit 30.

Microsoft claims it no longer has copies of the versions of Hanguel Windows and applications in question. Until recently, Caldera has tried unsuccessfully to obtain copies of them from other sources. Tests performed on the recently uncovered version of Hanguel Windows support Caldera¹s claims. The Hanguel Windows 3.0 includes the following error message:

The Hanguel Windows 3.1 includes the following error message:

Hollaar Decl. ¶ 7.

1. The Beta Process Is Not Immune From Antitrust Scrutiny.

Microsoft also argues that incompatibilities created in beta versions of Windows 3.1 are immune from antitrust liability because the purpose of the beta process is to discover and resolve incompatibilities. The argument suffers from several obvious defects. First, carving out a safe harbor for beta versions ignores the serious and clearly foreseeable impact that beta test programs have on marketplace acceptance of a product. See, e.g., Goodman Report at 4-6, Record Support, v.6 to Consolidated Statement of Facts. A number of witnesses in this case have testified about the devastating impact that incompatibilities in Windows 3.1 beta versions had on DR DOS. See, e.g., Deposition Theo Lieven ("Lieven Dep.") ¶¶ 229-30, Record Support, v.5 to Consolidated Statement of Facts (describing abrupt cessation of DR DOS sales after negative press articles about its compatibility based on review of Windows beta); Deposition of Jose Vasco ("Vasco Dep.") at 157-58, Engel Decl., Ex. 28 (DRI sales representative describing lost sales resulting from discussion of AARD code in Windows 3.1 Christmas beta raised at press conference); Corey Dep. at 268-73, Record Support, v.3 to Consolidated Statement of Facts (beta incompatibility tainted market in a very significant way); Dixon Dep. at 338, Record Support, v.3 to Consolidated Statement of Facts; see also Goodman Report at 6, Record Support, v.6 to Consolidated Statement of Facts. The CompuServe forum messages from Windows 3.1 beta testers provide additional evidence of the severe harm Microsoft inflicted on DRI during the beta process. See, e.g., Statement of Additional Material Facts ¶ 63 "DR DOS will *not* allow the beta to install. . . ." "Precisely why I use MS-DOS 5. Good luck."

Second, although, the major purpose of most beta testing is to work out incompatibilities, it is undisputed that Microsoft had no intention of working out incompatibilities with DR DOS. Indeed, it is undisputed that Microsoft excluded DRI from the beta process and publicly stated that it would render no information or assistance. Microsoft¹s purpose in excluding DRI was directly contrary to the purpose of beta testing: Microsoft sought to create incompatibilities and prevent DRI from remedying them. Consequently, the basic rationale Microsoft relies upon to support such a safe haven is completely absent here.

Third, these incompatibilities affected released versions of DR DOS. Novell/DRI was even forced to issue corrective updates to fix the Nested Task flag and XMS version check problems. Clifton Dep. at 226, Engel Decl., Ex. 13. As with a product recall, doing so is expensive, reduces customer goodwill, and cements the very fears about DR DOS that Microsoft intended to create.

1. AARD Code False Error Messages.

As explained in the previous section, Microsoft¹s inclusion of false error messages in the Windows 3.1 beta was, in fact, yet another engineered incompatibility and that alone is enough to give rise to Section 2 liability. Under a tortured definition of "incompatibility," however, Microsoft insists the encrypted and obfuscated false error message code did not amount to an incompatibility. Thus, Microsoft argues, its predatory conduct must be judged under a different standard. Even putting aside the lack of any basis for this contention, it makes no difference: even under Microsoft¹s proposed standard, Microsoft is not entitled to summary judgment.

1. Microsoft Relies on the Wrong Standard for Evaluating Its False Error Message Code in the Windows 3.1 Beta.

Microsoft ignores both the substance and letter of Caldera¹s claims to insist that Caldera¹s allegations regarding the AARD code are, in fact, a disparagement claim and thus must be evaluated under the law governing disparagement, separate and apart from Microsoft¹s other predatory acts. Microsoft¹s AARD Code Memo. at 1. Caldera, however, has not pled a separate disparagement claim. Rather, Caldera alleges that Microsoft¹s inclusion of false error messages in the Windows 3.1 Christmas beta was one of numerous predatory acts Microsoft committed in violation of Section 2‹all designed to preclude DR DOS from competing in the DOS market. See First Amended Complaint ¶¶ 49-53 & 72-77.

Despite Microsoft¹s attempt to recast Caldera¹s claims, Caldera¹s AARD code claims are not disparagement claims. Classic product disparagement occurs when one competitor makes statements disparaging another competitor¹s product. Where disparagement is alleged as the basis for antitrust liability, courts presume a de minimus effect on competition because "most consumers view statements about a competitor cynically, recognizing the inherent bias and lack of objectivity of such statements." American Professional Testing Serv., Inc. v. Harcourt Brace Jovanovich Legal & Professional Publications, Inc., 108 F.3d 1147, 1152 (9^th Cir. 1997). Neither the definition of disparagement nor the rationale for presuming a de minimus effect on competition apply here. The false error messages left people with the impression that a real incompatibility existed between Windows 3.1 and DR DOS. There was no reason for consumers to know, or suspect, that they should view the false error messages "cynically" or as mere puffing by Microsoft.

In fact, what Microsoft did with the false error messages is akin to the following analysis: Imagine a world where Sony is the only TV manufacturer. Sony also makes VCRs. Rather than telling consumers that Panasonic makes inferior VCRs, Sony designs a detection mechanism in its TVs so that every time a consumer attempts to use a Panasonic VCR with the TV, an error message appears and makes it appear as if the VCR will not work with the TV. The message also tells the user to contact Sony. When the user calls Sony to find out what the problem is, Sony tells the user he or she should go out and buy a Sony VCR. This behavior is not disparagement; it is, however, precisely the type of behavior the antitrust laws were designed to prevent.

In support of its position that Caldera¹s AARD code allegations are governed by disparagement law, Microsoft relies on a single case, David L. Aldridge Co. v. Microsoft Corp., 995 F. Supp. 728, 747-50 (S.D. Tex. 1998). Notwithstanding Microsoft¹s representations, Aldridge does not hold that Section 2 claims regarding computer-generated error messages must be evaluated as if they were disparagement claims. See Microsoft¹s AARD Code Memo. at 1. As Microsoft well knows, the Aldridge court applied disparagement law to Aldridge¹s claims because that is how he pled them. See Ex. 29 to Engel Decl. (Aldridge complaint). The Aldridge court simply did not have to consider whether disparagement law was the correct standard to apply. Microsoft relies heavily on this case, though, and is attempting to create a new legal standard‹not based on any legal precedent‹but rather, out of nothing more than one plaintiff¹s strategic pleading decision. Unlike the plaintiff in Aldridge, Caldera has pled a Section 2 claim that involves a coordinated scheme of predatory and anticompetitive acts, all designed to instill fear, uncertainty and doubt about DR DOS¹s ability to run Windows.

Moreover, as is obvious from the Aldridge court¹s opinion, there are numerous reasons why disparagement law should not be applied to evaluate incompatibilities claims, whether or not they involve error messages. For example, the Aldridge court rested its holding in part on the fact that computer error messages disappear after the computer is turned off. 955 F. Supp. at 750. Apparently, the court believed that this meant the messages would have little effect, but Microsoft itself knows that not to be true‹it asserts here, as an "undisputed fact," that error messages are far more effective than written documentation or electronic documentation included with programs. See Microsoft¹s Statement of Undisputed Facts Regarding Plaintiff¹s "Perceived Incompatibilities" Claim ¶ 3. In any event, Aldridge is easily distinguished from this case.

Aldridge designed and sold a third-party software utility that improved the performance of MS-DOS and the performance of MS-DOS and Windows together, by shifting certain functions from the hard disk to random access memory. Id. at 733-34. When Microsoft subsequently designed Windows 95, it did so in such a way that when Windows 95 detected Aldridge¹s utility, a computer generated message appeared. Id. at 737. The message told the user that the utility might decrease the operating system¹s performance. Id. The user then had the option of obtaining additional information about the problem. Id. If the user chose "yes" and asked for more information, a second message appeared, explaining that the utility forced the operating system to operate in a slower mode. Id. The user could then choose to review two more messages that provided even more information regarding the problem. Id.

Aldridge did not participate in the Windows 95 beta program. Id. at 739. At least a year before Windows 95 was released, however, Aldridge learned from Windows 95 beta testers that Windows 95 displayed messages regarding Aldridge¹s product. Id. at 751. Despite this, Aldridge never asked Microsoft for a Windows 95 beta. Id. at 739. Aldridge¹s sales began declining even before the Windows 95 general release and, even though Aldridge ultimately developed a product that was compatible with Windows 95, the new product did not stop Aldridge¹s sales from plummeting. Id.

Aldridge alleged that Microsoft violated of the Sherman Act by disparaging Aldridge¹s product and by denying Aldridge access to an essential facility‹Windows 95. Id. at 747-48. On Microsoft¹s motion for summary judgment, the district court, consistent with Aldridge¹s complaint, applied the six-part disparagement test to Aldridge¹s disparagement claim. The court found that Aldridge raised factual issues about the falsity of two of the messages, about materiality, and about reliance. Id. at 750. The court also found that Aldridge had established that Microsoft published the messages to consumers who had little understanding of the subject matter. Id. The court, however, found that two of the messages were true, that the messages did not appear for prolonged periods (because they were not displayed when the computer was turned off), and that the messages were susceptible to neutralization. With respect to the final prong, the court noted that Aldridge did not ask Microsoft about the messages or attempt to upgrade its product to make it compatible with Windows 95, even though Aldridge had received reports from Windows 95 beta testers regarding the messages a year before the commercial release of Windows 95. Id. at 751 n.133. The court, thus, granted Microsoft¹s motion for summary judgment on Aldridge¹s disparagement claim.

In contrast to Aldridge, Caldera has alleged a coordinated scheme of predatory acts, including false error messages, beta blacklisting, intentional incompatibilities, per processor licensing, tying and other exclusionary conduct, that go far beyond those alleged in Aldridge. Aldridge¹s principal claim was disparagement, the messages Aldridge complained of were not part of a coordinated scheme to encourage users to contact Microsoft, only to be told to switch to MS-DOS. Nor was Aldridge blacklisted from the Windows 95 beta program; DRI actively sought to participate in the Windows 3.1 beta program but was turned down. As discussed more fully above, see Section V.A., the entire course of Microsoft¹s conduct must be considered before concluding that Microsoft has or has not violated Section 2.

2. Even if the Disparagement Standard Did Apply, Microsoft¹s False Error Messages Give Rise to Section 2 Liability.

Even if the disparagement standard did apply to Caldera¹s allegations regarding the AARD code, there would still be material issues of fact. Microsoft argues that the error messages were not "clearly false"; that the false error messages could not have reasonably induced reliance on the part of the beta testers; that the false error messages were not made to consumers, but rather to sophisticated users; and that Novell could have neutralized the damaging effects of the false error messages. Microsoft is wrong on all counts.

1. The Error Messages Were False.

Every time the message appeared, the message falsely stated that there was an error. In fact, however, there was no error. Reynolds Dep. at 79, Record Support, v.2 to Consolidated Statement of Facts ("There is no problem."); Hollaar Report at 12-14, Record Support, v.6 to Consolidated Statement of Facts. To generate an error message when there is in fact no error is little different than pulling a fire alarm when there is no fire. Microsoft¹s argument, that the AARD code "did not create any actual incompatibility [because it] did not modify DR DOS or interfere with the operation of DR DOS in any way," is akin to saying that there is nothing wrong with shouting "Fire!" in a crowded movie theatre because it does not actually cause a fire.

Microsoft also argues that the error message cannot be "false" because it did not identify DRI or Novell by name. Not surprisingly, Microsoft fails to cite a single case stating that this is a requirement. Regardless, Microsoft specifically and repeatedly identified DR DOS as the cause of the error messages. See Statement of Additional Material Facts ¶ 52.

Finally, after arguing that the false error messages were "devoid of content" and said "nothing," Microsoft makes a puzzling alternative argument, conceding that although the false error messages may have suggested that there were incompatibilities between DR DOS and Windows 3.1, the messages are not actionable because they were "true." Microsoft¹s AARD Code Memo. at 6. The developer of the AARD code himself, however, testified that when these error messages appeared, there was no error. Reynolds Dep. at 79, Record Support, v.2 to Consolidated Statement of Facts. There is not a definition of "true" that can rescue Microsoft here.

2. The Beta Testers Were "Consumers" Who Reasonably Relied on the False Error Messages When Evaluating DR DOS¹ Compatibility With Windows.

Microsoft makes the misleading argument that because the false error messages were not included in the commercial release of Windows 3.1, the messages were not seen by "consumers having little understanding of the subject matter." Microsoft AARD Code Memo. at 8. The Windows 3.1 Christmas beta was released to over 15,000 users. These testers included end-users, corporations, government offices, members of the press and others. See to Response to Microsoft¹s AARD Code Undisputed Facts ¶ 10, Section II.C., above. This group was not, as Microsoft suggests, a specialized group of testers, highly trained and prepared to uncover the fact that the error messages were false error messages. The evidence on this point is strong. True beta testers should be reporting problems on a regular basis; only 37% of the Windows 3.1 beta sites returned even a single error report. Id. at ¶ 6. Moreover, Microsoft admits that the beta program was‹especially in the late stages‹much more than a testing program. It had an important marketing purpose, which explains the broad distribution and the low reporting statistics. Id.

Microsoft also glosses over the point that it alone had access to the source code for Windows 3.1. Thus, no one, with the exception of a few highly skilled software engineers, was in a position to discover the fact that the error messages were, in fact, false error messages. This task was made even more difficult by Microsoft¹s practice of deliberately obfuscating the source of the messages by encrypting the object code itself and by deliberately disabling the debugger‹the tool most useful in trying to uncover the source of the false error messages.

Every tester who ran the Christmas beta on DR DOS saw one or more of the false error messages. Every tester who viewed the dialogue on the Compuserve Forum site for the Windows 3.1 beta would have seen Microsoft¹s responses to questions about the false error messages. See Statement of Additional Material Facts ¶ 52. It was more than reasonable for beta testers to rely on Microsoft¹s representations about what caused the false error messages. After all, Windows 3.1 was Microsoft¹s product‹who better than Microsoft would know what was causing the error messages? There was no way these beta testers would know, or even suspect, that the error messages were false or that Microsoft¹s purpose in creating the false error messages was to make the user feel "uncomfortable" and to "think that the problem was DR DOS and go out and buy MS-DOS." Id. at ¶ 52; see also Goodman Rebuttal Report at 12, Engel Decl., Ex. 21. Moreover, there was no reason why beta testers would know, or suspect, that Microsoft was not telling the truth when it blamed the problems on DR DOS.

Finally, Microsoft fails to mention the fact that it encrypted and obfuscated the AARD code to keep secret its function and purpose. Contrary to Microsoft¹s assertion that those received the beta program were highly trained and unable to uncover the fact that the error messages were false, it was not until 1993‹two years later‹when a beta user finally deciphered the AARD code. Statement of Additional Material Facts ¶¶ 97-100. His reaction:

Why the purely arbitrary test that only MS-DOS would pass, and then why encrypt it, obfuscate it, and attempt to disable a debugger that¹s stepping through it? No, I think the code is very sleazy.

3. The False Error Messages Were Not Susceptible to Neutralization.

Microsoft designed and encrypted code that caused false error messages to appear when the Windows 3.1 beta ran with DR DOS. Hollaar Report at 9-12, Record Support, v.6 to Consolidated Statement of Facts. Microsoft released the beta to over 15,000 test sites, including OEMs who were deciding whether to license DR DOS, the trade press who passed on information to the general public, and average PC users. See Response to Microsoft¹s Undisputed Facts Regarding the AARD Code ¶ 10, Section II.C., above. Microsoft posted messages on a Compuserve Forum suggesting that the error messages were caused by incompatibilities between DR DOS and Windows 3.1. See Statement of Additional Material Facts ¶ 52. Microsoft refused, and let the industry know that it refused, to provide DRI with a beta so DRI could identify the cause of the messages. Id. at ¶¶ 31-32 & 34-37. And, at the same time, Microsoft was warning users that Microsoft could only guarantee future compatibility between MS-DOS and Windows. Id. at ¶¶ 22-25. Given all of this, it is irrelevant that DRI "could have" subsequently designed code to remove the message or disable the detection mechanism. Microsoft¹s AARD Code Memo. at 10. By the time Windows 3.1 was commercially released, the damage to DR DOS was done. Microsoft itself recognized that the false error messages had the desired effect. See Reynolds FTC Dep. at 76-77, Record Support, v.2 to Consolidated Statement of Facts.

1. There Is Substantial Evidence of Harm to Competition.

Microsoft incorrectly argues that Caldera must satisfy the six-part Areeda test and prove market harm. Microsoft¹s AARD Code Memo. at 3. As discussed in Caldera¹s Product Disparagement Response at Section C, this is not the law. The six part Areeda test is a substitute for proof of harm. See, e.g., National Ass¹n of Pharmaceutical Mfrs. v. Ayerst Labs., 850 F.2d 904, 916 (2^nd Cir. 1988). As shown above, Caldera easily satisfies this test.

In any event, Caldera has abundant direct evidence that Microsoft¹s predatory acts harmed competition, including eliminating MS-DOS¹ only real competition‹DR DOS, eliminating price competition in the DOS market, and consequently, eliminating any competitive pressure on Microsoft to innovate. See Section V.A.3., above; see also Product Disparagement Response at Section E.

2. The "Common Interest" Privilege Cannot Protect Microsoft From Liability for the False Error Messages.

Microsoft makes a half-hearted attempt to convince this Court that the false error messages constituted a communication between Microsoft and the users of the Windows 3.1 beta program that was protected by the common interest privilege set forth in Section 596 of the Restatement (Second) of Torts. This is absurd. First, Section 596 sets forth the qualified privilege that exists in the context of defamation claims, not antitrust claims. Caldera has not claimed the false error messages were defamatory. Second, Microsoft does not cite a single case to support its position that communications protected by this common interest privilege are immune from the antitrust laws. The one case Microsoft cites never reached the issue because the court found that there was no common interest privilege. See California Energy Co. v. Southern California Edison Co., 1992 WL 330263, *3 (N.D. Cal. 1992). Third, even if common interest privileged communications were immunized from the antitrust laws, Microsoft has not established that it had the necessary common interest with its 15,000-plus beta program users. Common interest is limited to special relationships, such as fellow partners or officers of a corporation for profit. See Restatement (Second) Torts § 596 (1977), comment d. The limited, arms-length dealings between Microsoft and the Windows 3.1 beta users do not approach the special relationship requirement.

1. CONCLUSION

DATED this 19th day of April, 1999.

SNOW, CHRISTENSEN & MARTINEAU