CONFIDENTIAL BUSINESS SECRETS

RESPONSE OF MICROSOFT CORPORATION TO THE STATEMENT OF OBJECTIONS BY THE EUROPEAN COMMISSION DATED 21 DECEMBER 2005

__________________________________

Case No. COMP/C-3/37.792 Microsoft

___________________________________

15 February 2006

TABLE OF CONTENTS I. II.

III. IV.

V.

VI.

VII.

Introduction......................................................................................................................... 1 Summary ............................................................................................................................. 5 A. The Commission Has Denied Microsoft Its Right Of Defence By Denying Microsoft Fair Access To The File ............................................................................... 9 B. Microsoft Has Not Refused To Provide The Scope Of Documentation Requested.................................................................................................................... 10 C. The Commission Attacks The Usability of The Documentation Unfairly ................. 12 D. Microsoft Has In Fact Complied With The 2004 Decision ........................................ 12 The Commission Has Denied Microsoft Its Fundamental Rights of Defence By Denying Microsoft Its Right Of Access To The File........................................................ 14 The Statement Of Objections Cannot Stand Because It Falsely Accuses Microsoft Of Refusing To Provide Interoperability Information Requested By The Commission ...................................................................................................................... 20 A. Microsoft Has Never Refused To Supply Information The Commission Has Requested.................................................................................................................... 20 B. The Assertion That Microsoft Has Refused To Provide More Than “On-TheWire” Protocol Information Is A Pure Fiction That Misrepresents History............... 30 The Statement Of Objections Cannot Stand Because It Was Issued Before The Commission Even Reviewed The Additional Documentation Microsoft Submitted On 15 December That Remedied Any Deficiencies Validly Asserted By The Article 24(1) Decision....................................................................................................... 31 Microsoft Has Made A Major Effort To Comply With The 2004 Decision In The Same Way It Has Complied With The U.S. Settlement And Licensing Commitments Made In Private Transactions.................................................................... 40 A. Microsoft Has Committed Major Resources To Providing Interoperability Information ................................................................................................................. 40 B. A Substantial Part of Microsoft’s Documentation Has Been Submitted In The U.S. Proceedings And Successfully Licensed To Many Companies While Undergoing A Productive Ongoing Process Of Refinement And Improvement........ 42 C. Microsoft Has Licensed Complex Technology In Private Transactions And Has Successfully Implemented Those Programs........................................................ 46 Microsoft Has Complied With Article 5 Of The Decision ............................................... 47 A. There Is No Truth To The Claim In The Statement Of Objections That Microsoft Has Refused To Provide Technical Documentation Going Beyond “On- The-Wire” Protocol Specifications .................................................................... 47 B. Microsoft’s Technical Documentation Complies With The Requirements Of The 2004 Decision In A Manner Entirely Consistent With Established Industry Practice ......................................................................................................... 48 C. The Remaining Criticisms By the Trustee And Others Are Also Mistaken, Outdated, Or Solvable By A Normal Industry Practice Of Continued Interaction With Microsoft ......................................................................................... 55

-2VIII. IX.

X.

Microsoft Cannot Be Fined For Complying With Article 5 In A Manner Consistent With Software Industry Practices ................................................................... 62 Microsoft Has Further Confirmed Its Commitment To Compliance With Article 5 Of The 2004 Decision By Offering To License Windows Source Code And Extending Other Important Additional Assistance To Licensees..................................... 64 Imposition Of Any Penalty Would Be Unlawful And Unfair .......................................... 71 A. The Statement Of Objections Fails To Recognize The Complexity Of The Compliance Issue In This Proceeding......................................................................... 71 B. The Commission Has Failed to Meet Its Burden Of Showing Microsoft Has Failed To Comply ....................................................................................................... 73

I. 1.

INTRODUCTION In this proceeding, the Commission has challenged Microsoft Corporation’s (“Microsoft”)

compliance with Article 5 of the Commission’s Decision of 24 March 2004 ( the “2004 Decision”). As Microsoft has repeatedly informed the Commission, Microsoft is fully committed to compliance with the Decision and has taken extraordinary measures to insure that it is in compliance. Hundreds of Microsoft employees and contractors have worked for more than 30,000 hours to create over 12,000 pages of detailed technical documents that are available for license today. In addition, Microsoft has offered to provide licensees with 500 hours of technical support and has made its source code related to all the relevant technologies available under a reference license. These and other steps Microsoft has taken to ensure compliance are detailed below in this Response. While the sufficiency and adequacy of Microsoft’s technical documentation standing alone has been challenged in the Statement of Objections dated 21 December 2005 (the “Statement of Objections”), this Response demonstrates in detail why those objections are not well-founded. But the Statement of Objections does not properly consider the entirety of Microsoft’s compliance efforts, which are considerable, and Microsoft’s commitment to continue working with the Trustee, the Commission, and any licensees to ensure that the information Microsoft has prepared for license in compliance with the Decision is useful and complete. 2.

This is the first proceeding in which the Commission is applying its greatly enhanced

powers to impose penalties on companies for alleged non-compliance with Commission decisions, so far as Microsoft is aware.1 With a threatened fine, in the form of a periodic penalty payment of up to EUR 2,000,000 a day, this case will define for the future both the standards the Commission will follow, and the procedural safeguards and transparency, if any, which will apply in such proceedings. 3.

In contrast with Microsoft’s extensive efforts to meet its strong commitment to

compliance, the Commission’s conduct raises a number of important concerns that will have far-

1

Article 24 now allows fines to be imposed in amounts up to 5% of an undertaking’s average daily turnover. Under the previous version of what is now Article 24, fines were limited to EUR 1,000 per day. See Article 16(1) of Regulation 17 (the predecessor to Regulation 1/2003).

-2reaching effects in future cases and that raise serious questions about the propriety of seeking to impose huge fines in this case. For example:

4.

•

The Commission continually changed its interpretation of what technical documentation was required by the vague language in the Decision, and refused to put its new interpretations in writing despite repeated requests from Microsoft, out of concern that this new interpretation would come to the attention of the Court of First Instance (“CFI”) in Luxembourg.

•

The Commission waited many months before informing Microsoft that it believed changes were necessary to the technical documentation and then gave Microsoft only a few weeks to make extensive revisions.

•

When the Commission issued its Statement of Objections on 21 December 2005, the Commission and its experts had not even bothered to read the most recent version of those documents which Microsoft had made available on 15 December 2005 in accordance with the Article 24(1) Decision.

The Commission has denied Microsoft’s fundamental right of defence by prohibiting fair

and full access to the file underlying the Statement of Objections, including correspondence between the Commission and the outside experts upon whose evidence the Commission relies. In defiance of its own recent declaration of increased transparency, the Commission declares these experts to be “internal” for the purpose of shielding its communications with them, but “external” for purposes of relying on their reports. The Commission also prejudicially delayed disclosure of hundreds of relevant email messages between the Commission and Microsoft’s competitors. 5.

If the Commission may issue a Statement of Objections and seek to impose massive fines

for noncompliance under these circumstances, then the future of transparency and fair process in European competition proceedings appears bleak. Despite this conduct, which has gravely prejudiced Microsoft’s earnest efforts to comply, Microsoft has complied and the Statement of Objections is not well founded as can be established from examining the merits of the Statement of Objections. 6.

The Statement of Objections falsely and unfairly accuses Microsoft of failing to comply

with Article 5(a) and Article 5(c) of the 2004 Decision. The Statement of Objections rests this accusation on two claims. The first claim is that Microsoft has refused to provide the full scope of “Interoperability Information” (as defined by Article 1(1)) of the 2004 Decision) that the 2004

-3Decision requires. That is, the Statement of Objections asserts that Microsoft has refused to document the full range of Windows technology required for compliance. The second claim relates to the usability of the documentation of Interoperability Information that Microsoft has provided. According to the Statement of Objections, it is too hard for competitors to use the documentation to develop work group server operating systems that will be able to compete on an equal basis with Microsoft work group server operating systems. 7.

As for the first claim, the simple fact is that Microsoft has at all times supplied the scope of

Interoperability Information that the Commission has stated it interprets the 2004 Decision to require. Microsoft has done so even though the Commission’s present interpretation in fact goes well beyond the requirements of the 2004 Decision. 8.

Microsoft clearly advised the Commission, several times and in several ways, of the scope

of the draft Interoperability Information that Microsoft initially provided to the Commission in December 2004, and the basis for Microsoft’s understanding of what the 2004 Decision required. For more than nine months, the Commission never questioned, much less challenged, the scope of the Interoperability Information that Microsoft provided. To the contrary, it indicated that it agreed with Microsoft’s understanding of the 2004 Decision. 9.

When the Commission first indicated that it interpreted the 2004 Decision to require

something more than Microsoft had provided, Microsoft agreed to supply the scope of documentation the Commission was requesting, if only the Commission would confirm in writing the scope of the technical documentation containing the Interoperability Information required by Article 5 of the 2004 Decision (the “Technical Documentation”) that the Commission was insisting upon. The Commission refused to provide Microsoft a meaningful written statement, apparently because it wished to demand a broad scope of documentation, while, at the same time, preventing Microsoft from placing that fact squarely before the CFI in the appeal against the 2004 Decision (as substantiated by statements discussed in later sections of this Response). Microsoft, although dismayed by this gamesmanship, itself stated in writing that it would supply what it understood the Commission was requesting. 10.

The second claim made in the Statement of Objections, concerning the usability of

Microsoft’s documentation (that is, its ease of use), made an even more tardy appearance. Prior to 10 November 2005, the Commission raised the issue of usability in only a single

-4communication in June 2005. Microsoft promptly responded to the concerns raised, and submitted revised documentation in August. The Commission did not mention the subject again – although Microsoft and the Commission were in almost constant communication about the details of Microsoft’s licensing program for the Technical Documentation – until the Commission issued its Article 24(1) Decision on 10 November 2005, more than four months later. The Article 24(1) Decision claimed, among other things, that Microsoft’s documentation was not sufficiently usable for licensees. In large part, the Commission’s criticisms ignore the inherent complexity of writing specifications for software as complex as the Windows server operating system communications protocols. The task required many person years and resulted in more than 12,000 pages of specifications written, of necessity, for an audience of software engineers skilled in the relevant art. Of course, the specifications are detailed and demanding; they are not “unusable.” 11.

The Article 24(1) Decision gave Microsoft until 15 December 2005 to remedy the

deficiencies asserted. Microsoft advised the Commission that it would prepare revised documentation by that date to address the Commission’s usability concerns. Microsoft then did just that, and made revised documentation available on 15 December 2005. Microsoft noted at that time that its team had to work around the clock to draft the revised documentation in the short time provided. Had Microsoft been told of the Commission’s concerns earlier, its technical team could have used the additional time to make that documentation even better. 12.

Without even reviewing the revised documentation Microsoft made available on 15

December 2005, however, the Commission prematurely issued its Statement of Objections on 21 December 2005.2 The Commission did so despite the direct and repeated assurances by senior executives of Microsoft that the company was committed to complying with the requirements of the Decision, and that, in order to assure there could be no dispute about compliance, Microsoft would supply the Technical Documentation it understood the Commission to be requesting, 2

The revised documentation was made available at Microsoft’s headquarters on 15 December 2005, and Microsoft so confirmed to the Commission, but no one from the Commission, the Trustee or any prospective licensee viewed the documentation prior to the issuance of the Statement of Objections on 21 December 2005 (“SO”). Microsoft was not able to send a copy to the Commission until December 23, because several days were needed to add digital rights management features to the documentation. All this was in accord with the requirements of the Article 24(1) Decision and the 2004 Decision, as discussed in Part V.

-5despite Microsoft’s disagreement with the Commission’s interpretation of the Decision. In issuing the Statement of Objections, the Commission also failed to honor its promise that “[w]ith the help of the Trustee, we will evaluate the updated documentation.”3 The Commission issued the Statement of Objections without consideration for the extraordinary effort Microsoft invested in creating revised and extended documentation, without engaging in any dialog to understand how it was anticipated licensees would use the documentation, indeed without reviewing the new documentation at all. In short, the Statement of Objections claims Microsoft has failed to create Technical Documentation that the Commission did not read, and for which no competitor has sought a license, all to address a problem about which no customer has ever complained. II. 13.

SUMMARY An understanding of the facts showing that Microsoft has complied with Article 5(a) and

5(c) of the 2004 Decision must begin with the language of the Decision itself. Article 5(a) requires Microsoft to make “Interoperability Information available to any undertaking having an interest in developing and distributing work group server operating system products.” Article 5(c) requires Microsoft to “set up an evaluation mechanism” to allow such undertakings to “inform[…] themselves about the scope and terms of use of the Interoperability Information.” Article 1(1) defines “Interoperability Information” as “the complete and accurate specifications for all the Protocols implemented in Windows Work Group Server Operating Systems and that are used by Windows Work Group Servers to deliver file and print services and group and user administration services.”4 14.

On 11 December 2004, Microsoft supplied the Commission with a preliminary copy of the

Interoperability Information it planned to make available to potential licensees.5 At the same time Microsoft also provided the Commission with a clear and explicit description of the scope of the documentation being supplied. At various times since then, and most recently on 15 December 2005, Microsoft has supplied the Commission with revised and expanded versions of

3

Letter of 9 November 2005 from Commissioner Kroes to Steven Ballmer. Article 1(2) in turn defines “Protocol” to mean “a set of rules of interconnection and interaction between various instances of Windows Work Group Server Operating Systems and Windows Client PC Operating Systems running on different computers in a Windows Work Group Network.” 5 See SO ¶ 14. 4

-6the Technical Documentation containing Interoperability Information, including revisions made available on 8 August 2005; 11 and 23 November 2005; and 15 December 2005.6 15.

The Commission did not comment upon the 11 December 2004 draft documentation for

more than six months, and then ignored the 8 August 2005 revision for several months more. Specifically, it never challenged Microsoft’s description of the scope of the documentation that was being developed and supplied to the Commission. When the Commission first raised concerns about the scope of the documentation on 30 September 2005, Microsoft teams labored hard to address the Commission’s concerns. Nevertheless, the Statement of Objections seeks to impose a punitive daily fine upon Microsoft because of its alleged failure to comply with Article 5 of the 2004 Decision. This threat of a fine comes despite the fact that Microsoft’s employees have spent almost over 30,000 hours preparing, improving and extending the documentation,7 and despite the Commission’s astonishing decision not to even review Microsoft’s most recent revision to the documentation on 15 December 2005 before issuing the Statement of Objections. 16.

The Statement of Objections was issued on 21 December 2005 following the release by the

Commission of an Article 24(1) Decision on 10 November 2005. That decision identified asserted deficiencies in Microsoft’s Technical Documentation and stated that Microsoft must correct those deficiencies, and other asserted compliance deficiencies, by 15 December 2005 or face a fine of EUR 2,000,000 a day.8 17.

The Statement of Objections asserts that Microsoft has failed to remedy the Technical

Documentation deficiencies alleged in the Article 24(1) Decision.9 In claiming that Microsoft has not supplied the Interoperability Information required by the 2004 Decision, the Statement of Objections focuses upon two distinct categories of claimed deficiencies. The first, which the Statement of Objections identifies as the supposed absence of information on “behaviours and

6

SO ¶¶ 18, 28-30, 93, 96. See Annex 1. 8 Article 24(1) Decision, Article 1. The other deficiencies asserted in the Article 24(1) Decision related to the remuneration terms on which Microsoft has offered to make Interoperability Information available to competitors wishing develop work group server operating system. The Statement of Objections states that it was issued without prejudice to the Commission’s assessment whether Microsoft has remedied these other compliance deficiencies asserted by the Article 24(1) Decision. 9 See SO ¶¶ 105-106. 7

-7dependencies,”10 relates to the scope of the Technical Documentation. The second category encompasses certain alleged usability deficiencies that, according to the Statement of Objections, make the Technical Documentation unreasonably difficult for potential licensees to work with to develop work group server operating system products.11 18.

With regard to the scope of Microsoft’s Technical Documentation, the Statement of

Objections claims that Microsoft has provided only “on-the-wire” protocol information,12 that is, information relating to how the protocols communicate information between computers in a Windows network, such as how data must be formatted by the sender to be read by the recipient, and how the meaning of the information transmitted can be understood. The Statement of Objections asserts that Microsoft has refused to supply a broader range of information which would help explain why the computers in a network communicate particular information and how the communicated information is used and with what results. Such information does not describe the content and meaning of actual communications between computers in a network, but instead reveals the internal operations of the Windows work group server operating systems. 19.

The Statement of Objections states that this broader scope of documentation including the

internal “behaviours and dependencies”13 of work group server operating systems is “necessary to enable Microsoft’s competitors” to develop products that can “interoperate with the Windows domain architecture on an equal basis” with Microsoft’s products, and therefore must be included within the meaning of Interoperability Information.14 20.

The usability problems asserted by the Statement of Objections relate to its ease of use.

According to the Statement of Objections, descriptions of the proper sequencing of messages communicated between servers are not provided in a way “consistent with the kind of description commonly used in the industry” and in some instances are not provided at all.15 There is not enough “introductory and explanatory material.”16 The words used by the documentation require

10

See SO ¶¶ 57-60, see also SO ¶¶ 54, 81, 90, 104(i). See SO ¶¶ 61-66, 77-80, 85, 88-89,91, 104(ii)-(v). 12 SO ¶ 97. 13 SO ¶¶ 54, 57. 14 SO ¶¶ 47, 57. 15 SO ¶¶ 62, 104(ii). 16 SO ¶¶ 63, 78, 80, 104(iii). 11

-8a knowledge of the Microsoft programming environment.17 Not enough information is provided concerning the “revision history” of the protocols over the various Windows products covered by the 2004 Decision,18 and full information is lacking for Microsoft’s next generation Windows Vista operating system.19 21.

Because of these asserted deficiencies in the scope and usability of Microsoft's Technical

Documentation, the Statement of Objections concludes that a large daily penalty should be imposed, calculated from 15 December 2005, which was the date set by the Article 24(1) Decision for Microsoft to remedy the deficiencies asserted there. 22.

The Statement of Objections is mistaken in both its premise and its conclusion regarding

the scope of the Technical Documentation Microsoft has supplied. These errors are compounded by the determination manifest in the Statement of Objections to rush to a premature judgment about the usability of the documentation, while ignoring Microsoft’s efforts to respond to the Commission’s concerns and Microsoft’s repeated offers to work cooperatively with licensees to resolve any questions, as is the industry practice. 23.

The central fact is that Microsoft has complied with Article 5 of the 2004 Decision.

Microsoft has always endeavored to supply the scope of Technical Documentation requested by the Commission, even though the Commission’s demands have now gone well beyond the requirements of the 2004 Decision. Microsoft has also supplied this documentation in a usable form in accord with industry practice. To the extent that licensees require technical support in using the documentation, or that clarifications or even corrections are needed, Microsoft has repeatedly offered to provide such help as part of an ongoing process that is also totally consistent with industry practice, and totally necessary for licensees to implement successfully such a complex software development project. 24.

The Commission has refused to recognize this industry practice, and refused to recognize

other undeniable realities (such as the fact that licensees would inevitably start such a project by assigning engineers with experience in this specialized field). The Commission has also contested the significance of Microsoft’s voluntary offer to allow licensees to use the actual 17

SO ¶¶ 64, 79, 88, 104(iv). SO ¶¶ 65, 104(v). 19 SO ¶ 66. Microsoft has submitted documentation for the current test of “beta” version of Windows Vista, although the Vista design has not been finalized. 18

-9source code for Windows, even though the Commission itself demanded that the Trustee must be given the same code in order to determine Microsoft’s compliance. But before discussing these facts demonstrating Microsoft’s compliance in detail, the basic errors and unfairness that infect the Statement of Objections must be exposed. A. The Commission Has Denied Microsoft Its Right Of Defence By Denying Microsoft Fair Access To The File 25.

The Statement of Objections relies upon reports by the Trustee and the Commission’s

outside consulting firm to support its claims. The Statement of Objections was accompanied by an annex purportedly providing a “List of Documents in the file.” This list did not identify any communications between the Commission and the Trustee and its consultants except for two letters by the Trustee submitting his two reports. When Microsoft pressed for a full list of documents in the file, the Commission acknowledged that it was withholding a number of written communications with the Trustee and its consultants. 26.

When Microsoft asked for the documents that had been withheld, the Commission took the

position, with the support of the Commission Hearing Officer, that the documents were internal documents, and in any event did not show that the Commission had exercised any “undue” influence over the Trustee or its consultants.20 27.

Microsoft is clearly entitled to these documents under the 2005 Notice on Access to the

File, which was issued with the promise that it would “increase the transparency and efficiency of our merger and antitrust procedures” and a ringing statement of the Commission’s “commitment to guarantee full respect for the rights of defence of parties in competition procedures.”21 28.

The Commission cannot have it both ways. If it claims that the Trustee and its consultants

are merely acting as a constituent part of the Commission, so that communications with them are internal documents, then their reports are mere internal Commission opinions and cannot be relied upon as evidence to support the Statement of Objections. If the reports are relied upon as 20

Letter of 8 February 8, 2006 from DG Competition Hearing Officer to Ian S. Forrester (“Furthermore, I can reassure you that no undue influence was exercised by the Commission on the contents of the reports drawn up by OTR and Professor Barrett”). 21 Press Release IP/05/1581 of 13 December 2005: “Competition: Commission improves rules for access to the file in merger and antitrust procedures.”

- 10 evidence – and the Statement of Objections does just that – then Microsoft is entitled to access to the Commission’s communications with the authors of those reports as a vital part of its right of defence. Microsoft is entitled to determine and present arguments as to whether, for example, the Commission’s influence upon the Trustee and its consultants was “due influence” (whatever that might be) or “undue influence.” B. Microsoft Has Not Refused To Provide The Scope Of Documentation Requested 29.

Microsoft has never refused to supply any Technical Documentation that the Commission

has stated is required. The 2004 Decision requires “Interoperability Information” in the form of “specifications for all the Protocols implemented in Windows Work Group Server Operating Systems.”22 When Microsoft requested interim measures to suspend implementation of the 2004 Decision prior to a decision on its Application to Annul the Decision, the Commission and its supporting interveners represented to the President of the CFI that Microsoft’s fears of irreparable harm were groundless, because they sought only “on-the-wire” protocol specifications, and not information relating to the internal architecture or operation of Windows. Interim measures were denied, in important part, because the President of the CFI relied upon these representations. 30.

Microsoft therefore provided specifications for protocols used “on the wire” in networks to

the Commission for its review. In the Reply filed 28 February 2005 in its action for annulment of the 2004 Decision (the “Reply”), Microsoft also explicitly described the clarification of the Decision provided by the Commission and its supporting interveners in the interim measures proceeding. 31.

The Commission, far from disavowing the statements made at the interim measures

hearing or disagreeing with Microsoft’s statements in its Reply regarding the clarified scope of Interoperability Information, confirmed in its 13 June 2005 Rejoinder that the 2004 Decision required “interface specifications only.”23 The commonly-accepted meaning of an “interface specification” is a description of “the point at which a connection is made between two elements

22 23

2004 Decision, Articles 1(1), 5(a). Rejoinder ¶ 19.

- 11 so that they can work with each other or exchange information, and not a description of internal architecture or operation of a computer operating system.24 32.

As it worked to comply with the 2004 Decision after denial of interim measures, Microsoft

also explicitly described to the Commission the scope of the Technical Documentation being provided on a number of occasions, also without challenge from the Commission. 33.

The Commission received a draft of the Technical Documentation in December 2004

together with an explicit statement of what was and was not included, and received revised Technical Documentation in early August 2005. But the Commission went more than nine months without suggesting to Microsoft that the scope of the Interoperability Information provided was too narrow. Then, on the last day of September 2005, it suggested for the first time that a problem might exist with the scope of the Technical Documentation. 34.

Microsoft held rapid, intensive discussions with the Commission immediately after

learning that the Commission believed the scope of technology documented was too limited. Microsoft confirmed within a matter of a few days that it would provide the broader scope of documentation that it understood the Commission was tardily claiming that the 2004 Decision required, subject to preserving its right to seek review of the Commission’s overbroad interpretation of the 2004 Decision’s compliance requirements. All that Microsoft asked was for a clear statement of what the Commission required, so that it would know for certain what the Commission was demanding for compliance, and also so that Microsoft could make accurate facts available to the CFI in its pending appeal from the 2004 Decision. This was a reasonable request in view of the dramatic change in the Commission’s position as to what information was necessary for compliance. 35.

The Commission did not provide any such clear written description for the express reason

that it did not want Microsoft to be able to place these facts squarely and indisputably before the CFI. Microsoft nevertheless confirmed to the Commission that it would, in response to the

24

The definition of “interface” is quoted from the Microsoft Computer Dictionary, Fifth Edition, p. 279, which the Commission frequently cites for the meaning of computer terminology. See 2004 Decision ¶¶ 21, 37, 51, 55, 87, 160, 302, 465, 738, 740, 805. See also Software Directive recital 11 (“the parts of the program which provide for such interconnection and interaction between elements of software and hardware are generally known as ‘interfaces’”).

- 12 Commission’s oral demands, supply an expanded scope of Technical Documentation to the Commission as soon as possible, and did so within a matter of a few weeks, in November 2005. 36.

The Statement of Objections ignores these critical events, and falsely accuses Microsoft of

refusing to supply anything but “on-the-wire” protocol information. This is not just wrong, it is pure fiction. C. The Commission Attacks The Usability of The Documentation Unfairly 37.

The issue of the usability of Microsoft’s Technical Documentation has followed a different

chronology, but to similar effect: tardiness by the Commission in alerting Microsoft that the Commission saw a problem, urgent efforts by Microsoft to correct any problems, and finally the unjustified issuance of a Statement of Objections threatening a large daily fine for alleged noncompliance. 38.

Even more disturbing is the fact that, in issuing the Statement of Objections, the

Commission did not even review the revised Technical Documentation that Microsoft had worked so hard to make available to prospective licensees on 15 December 2005 exactly as required by the Commission’s Article 24(1) Decision. This was not an impartial or fair process. The Commission found Microsoft guilty before even having reviewed the evidence. D. Microsoft Has In Fact Complied With The 2004 Decision 39.

In addition to having been issued prematurely, the Statement of Objections is wrong in

asserting that Microsoft has failed to comply with Article 5 of the 2004 Decision. 40.

As an initial matter, several facts stand in dramatic contrast to the accusations of the

Statement of Objections that the Technical Documentation provided by Microsoft is misconceived and unusable. 41.

First, Microsoft has made a major commitment of resources to creating and refining the

Technical Documentation to be made available to competitors who may wish to develop work group server operating systems incorporating Windows functionality. During the period since the 2004 Decision, Microsoft employees have spent over 30,000 hours creating, refining and, at the Commission’s request, extending the Technical Documentation provided in order to comply with Article 5 of the Decision.

- 13 42.

Second, a substantial portion of the Technical Documentation which the Statement of

Objections finds deficient has previously been provided to the United States Department of Justice and licensed to more than 25 companies under the Microsoft Communications Protocol Program (“MCPP”) created as part of the settlement of the U.S. litigation. That MCPP documentation, as is customary in the software industry practice, is continuously reviewed for completeness and accuracy, and is subject to a process for clarification and corrections by Microsoft as needed. Recently, Microsoft’s technical documentation team has fallen behind on reviewing and responding to issues raised through this process, but Microsoft is fully committed to rapidly adding all the resources needed to stay current and to make sure the MCPP documentation is useful and complete, as described in the Report on U.S. Protocol Specification Program & Private Licensing Programs (“MCPP & Private Licensing Report”) submitted as Annex 2. Both the U.S. government and the MCPP licensees have found this interactive process sensible, and indeed the best way to achieve the goals of the MCPP program. This contrasts dramatically with the position taken by the Statement of Objections, which demands a perfect standalone set of Technical Documentation, and ignores repeated offers by Microsoft to provide ongoing technical assistance to users so that they may use the Technical Documentation productively to accomplish their specific goals. 43.

Third, Microsoft, as one of the world’s leading technology companies, has substantial

experience in licensing complex technology and working with licensees to make the process work. The fact that Microsoft has successfully licensed complex technology and worked cooperatively with licensees also stands in contrast to the assertions of the Statement of Objections that Microsoft’s Technical Documentation was created in bad faith and executed in an inept manner or worse. 44.

There is also ample direct evidence that Microsoft has complied with Article 5 of the 2004

Decision. Independent experts experienced with network operating systems have reviewed Microsoft’s Technical Documentation. They agree that the completeness and accuracy of such complex documentation cannot be fully assessed in a matter of days or even weeks. But they can and have concluded that Microsoft’s approach is consistent with industry practice and that the Technical Documentation, contrary to the assertions of the Statement of Objections, includes information about the internal architecture and functioning of the Windows work group server

- 14 operating systems that goes well beyond “on-the-wire” protocol specifications, which the Commission claims is all that Microsoft has been willing to provide. 45.

The independent experts also agree that the process of compliance undertaken by

Microsoft, which includes providing quality documentation and participating in an interactive process to assist licensees to implement the documentation, is consistent with standard industry practice and is indeed the only way to accomplish the Commission’s stated objectives. 46.

The criticisms of Microsoft’s documentation relied upon by the Statement of Objections do

not support an opposite conclusion. Many of those criticisms concern minor problems (such as spelling and typographical errors) that have been corrected by later editions of the documentation which the Statement of Objections simply ignores. Other criticisms reflect a misunderstanding of the documentation, and of the time and resources needed for a licensee to develop a functionally equivalent work group server operating system even with the assistance of Microsoft’s documentation. The criticisms also flow from a refusal to accept Microsoft’s offers of assistance, and an unreasonable haste to reach conclusions on a schedule imposed, inappropriately, by the Commission. 47.

In sum, the Statement of Objections does not satisfy the heavy burden of proof that would

be required for the imposition of the sizable daily punishment proposed. But that legal failing greatly understates the defectiveness of the Statement of Objections, which is so flawed and misleading that it is simply deceptive. III.

THE COMMISSION HAS DENIED MICROSOFT ITS FUNDAMENTAL RIGHTS OF DEFENCE BY DENYING MICROSOFT ITS RIGHT OF ACCESS TO THE FILE

48.

The Commission has denied Microsoft its full right of access to the file in this proceeding

which, as the Commission itself proclaimed publicly just 10 days before it issued the Statement of Objections, is a “fundamental procedural safeguard which ensures the rights of defence of companies.”25 Despite repeated requests from Microsoft, the Commission continues to deny Microsoft access to communications between the Commission and the Trustee and the Commission’s consultants at the OTR Group (“OTR”). The Commission justifies this denial on the grounds that these communications are “internal” Commission documents that are not subject 25

Press Release IP/05/1581 of 13 December 2005: “Competition: Commission improves rules for access to the file in merger and antitrust procedures.”

- 15 to disclosure under the 2005 Notice on Access to the File (the “2005 Notice”).26 To reach this conclusion, the Commission has interpreted the 2005 Notice in a way that is contrary to both its letter and its spirit. 49.

The 2005 Notice specifically addresses access-to-file issues related to reports of the kind

issued by the Trustee and OTR in this proceeding, and it is clear that the communications sought by Microsoft should be disclosed. Paragraph 11 states the general rule that “[r]esults of a study commissioned in connection with proceedings are accessible together with the terms of reference and the methodology of the study.” Paragraph 14, which is in the section of the 2005 Notice dealing with internal documents to which access need not be granted, carves out a narrow category of documents related to such reports that will be treated as internal: “[i]n the case of a study commissioned in connection with proceedings, correspondence between the Commission and its contractor containing evaluation of the contractor’s work or relating to financial aspects of the study, are considered internal documents and will thus not be accessible.” As the Commission has not suggested that its communications with the Trustee and OTR to which Microsoft is requesting access concern either an evaluation of the work of the Trustee or OTR or the financial aspects of their reports, they do not fall within the narrow exception carved out by Paragraph 14 and, consequently, must be disclosed. 50.

The Commission, however, resorts to a tortured reading of Paragraphs 11 and 14 to reach

the opposite conclusion. It interprets Paragraph 11 as giving an exhaustive description of the kinds of documents related to studies to which access must be granted and interprets Paragraph 14 as only giving examples of the kinds of documents that are “internal,” and, thus, to which access may be denied. This interpretation turns the 2005 Notice’s entire approach to access to the file upside down. By construing the general rule of access narrowly and the exception to this rule broadly, the Commission not only contradicts the basic rule of statutory interpretation that exceptions must be construed narrowly, but ignores the plain language of the 2005 Notice itself, which emphasizes that the parties will be granted access to “all documents making up the

26

Commission Notice on the rules for access to the Commission file in cases pursuant to Articles 81 and 82 of the EC Treaty, Articles 53, 54 and 57 of the EEA Agreement and Council Regulation (EC) No 139/2004, OJ (2005) C325/7 (the “2005 Notice”).

- 16 Commission file … with the exception of internal documents, business secrets of other undertakings, or other confidential information.”27 51.

The error of the Commission’s approach becomes even more apparent when Paragraph 14

is read in light of the 1997 Notice on Access to the File (the “1997 Notice”),28 which was replaced by the 2005 Notice. The 1997 Notice contains a special section on access to studies, which sets forth a broad right of access to studies and related documents: “It should be stressed that studies commissioned in connection with proceedings or for a specific file, whether used directly or indirectly in the proceedings, must be made accessible irrespective of their intrinsic value. Access must be given not only to the results of a study (reports, statistics, etc.), but also to the Commission's correspondence with the contractor, the tender specifications and the methodology of the study. However, correspondence relating to the financial aspects of a study and the references concerning the contractor remain confidential in the interests of the latter.”29 In denying access to communications with the Trustee and OTR, the Commission gave short shrift to this language, noting that the 1997 Notice is no longer in force, and proceeded to interpret the 2005 Notice in a manner that gives Microsoft a more limited right of access than it would have had under the 1997 Notice.30 The Commission’s treatment of this issue makes no sense, given that the Commission’s stated purpose for revising the 1997 Notice was to increase, not decrease, the right of access. 52.

The Commission’s effort to argue that the 2005 Notice reduces Microsoft’s right of access

to the file from that which was provided by the 1997 Notice is even more clearly refuted by the statements Commissioner Kroes made at the time of the adoption of the 2005 Notice: “[T]hese new rules will increase the transparency and efficiency of our merger and antitrust procedures. They reflect the Commission’s long-standing commitment to guarantee full respect for the rights of defence of parties in competition procedures.”31

27

2005 Notice, ¶ 10. Commission Notice on the internal rules of procedure for processing requests for access to the file in cases pursuant to Articles 81 and 82 of the EC Treaty, Articles 65 and 66 of the ECSC Treaty and Council Regulation (EEC) No 4064/89, OJ (1997) C23/3 (the “1997 Notice”). 29 1997 Notice, Section I(B). 30 Letter of 30 January 2006 from DG Competition Hearing Officer to Ian S. Forrester. 31 Press Release IP/05/1581 of 13 December 2005: “Competition: Commission improves rules for access to the file in merger and antitrust procedures” (emphasis added). 28

- 17 53.

In denying access to communications between itself and the Trustee and OTR, the

Commission sought to reassure Microsoft that its rights of defense were not being violated because, even if these communications were not considered to be “internal” documents, they would not be useful to Microsoft in mounting its defense. More specifically, the Commission noted that, in its opinion, these communications were (a) neither “indispensable” for understanding the experts’ methodology nor for testing their technical correctness, and (b) did not reveal any “undue influence” on the part of the Commission.32 54.

These statements beg the fundamental question: Who should make the decision of what

documents will be useful to Microsoft in exercising its right of defence? Should the prosecutor be able to choose which pieces of evidence a defendant can have? Should a Hearing Officer, with limited knowledge of the issues and evidence, make the determination? Or should Microsoft, the target of the Statement of Objections, be able to determine which documents it wishes to use in its defence? In particular, should Microsoft be entitled to review the relevant documents in the file to determine whether the “influence” the Commission imposed on the Trustee and OTR is “due” or “undue,” or should a Hearing Officer make that decision with no opportunity for Microsoft to see and comment on the document? 55.

It is not necessary to speculate on the answers to these questions because the CFI has

already answered them. In Solvay, it held that it is not for the Commission to decide what is exculpatory and what is not.33 In that same case, it also held that, having regard to the general principle of equality of arms that is designed to place the Commission and the defendant on an equal footing, the defendant should have access to the same documents as the Commission.34 32

Letter of 8 February 2006 from DG Competition Hearing Officer to Ian S. Forrester (emphasis added). 33 Case T-30/91, Solvay v Commission, [1995] ECR II-1775, para. 81 (“In that context the Commission observes that although its officials themselves examined and re-examined all the documents in its possession, they found no evidence which might exculpate the applicant, so that there was no point in disclosing them. In that regard, it should be stated that in the defended proceedings for which Regulation No 17 provides it cannot be for the Commission alone to decide which documents are of use for the defence. Where, as in the present case, difficult and complex economic appraisals are to be made, the Commission must give the advisers of the undertaking concerned the opportunity to examine documents which may be relevant so that their probative value for the defence can be assessed.” (emphasis added)) 34 Id., para. 83 (“Having regard to the general principle of equality of arms, which presupposes that in a competition case the knowledge which the undertaking concerned has of the file used in

- 18 56.

Allowing the Commission, which is effectively in the role of a prosecutor once it issues a

Statement of Objections, the discretion to decide whether documents are useful to the defendant’s case would be contrary to basic principles of due process. In this case, it is unnecessary to resort to a discussion of general principles of due process on this point, however, because the 2005 Notice itself does not allow the exercise of such discretion: if a document is neither internal nor confidential, it must be disclosed. Considerations such as whether or not that document is inculpatory, exculpatory, indispensable, or reveals the exercise of “undue” influence are all irrelevant because the 2005 Notice requires a process of full disclosure that, except for very narrowly-defined exceptions allows the defendant, not the Commission, to choose which documents are relevant for its defence.35 57.

The wisdom of this approach is evident when one considers the Commission’s assurance in

the course of the debate over access to the file in this proceeding that none of the documents revealed “undue” influence on its part vis-à-vis the Trustee or OTR. It is fundamentally wrong for the Commission to be the sole judge of whether or not it has exercised “undue” influence on the Trustee or OTR. Since the Statement of Objections relies heavily on the reports of the Trustee and OTR, Microsoft is entitled to know – as part of its rights of defence – what influence the Commission exerted on them. Microsoft should be able to bring any such influence to the attention of the Commission and, if necessary, to the European Courts. Transparency and fundamental fairness would be eviscerated if the Commission could exert influence, undue or otherwise, on so-called “independent” experts and then deny the accused party access to documents evidencing such influence. 58.

Microsoft’s right to full access to the file is not just a matter of abstract legal principle, as

fundamentally important as that principle may be to defendants in competition proceedings, but the proceeding is the same as that of the Commission, the Commission' s view cannot be upheld. The Court considers that it is not acceptable for the Commission alone to have had available to it, when taking a decision on the infringement, the documents marked "V", and for it therefore to be able to decide on its own whether or not to use them against the applicant, when the applicant had no access to them and was therefore unable likewise to decide whether or not it would use them in its defence. In such a situation, the rights of defence which the applicant enjoys during the administrative procedure would be excessively restricted in relation to the powers of the Commission, which would then act as both the authority notifying the objections and the deciding authority, while having more detailed knowledge of the case-file than the defence.” (emphasis added)). 35 See Case T-30/91, Solvay v Commission, [1995] ECR II-1775, ¶ 83.

- 19 concerns concrete documents that could have a direct impact on Microsoft’s defense in this case. For example, the list of documents received by Microsoft suggests that the Commission may have influenced the Trustee’s report of 15 December 2005, which goes to the heart of the dispute because it is relevant to the evaluation of the Technical Documentation supplied by Microsoft. The list of documents indicates that the Commission sent comments to the Trustee on his report on 15 December and on 19 December.36 These comments preceded the final faxed version of the report and must have influenced37 the final versions of the report that were annexed to the Statement of Objections. 59.

Finally, the Commission cannot treat the Trustee as an internal adviser when it comes to

access to documents, while portraying him as an independent adviser when relying on his reports in its Statement of Objections. If the Trustee is akin to an expert acting as an ad hoc Commission official evaluating third party evidence to provide internal advice to the Commission, as suggested by the Commission in denying access to the file, the Trustee’s reports ought to be regarded as Commission opinions and cannot be relied on by the Commission as “evidence” supporting its objections. If the Trustee is an independent adviser whose evidence can be relied upon in a Statement of Objections, the correspondence between the Commission and the Trustee must be accessible to Microsoft, subject to the limited exceptions defined in the 2005 Notice, none of which apply here.

36

E-mails to the Trustee from Ms. Verzelen of the Commission of 15 December (e-mail entitled “Remarks on the Sufficiency Test”) and on 19 December (email entitled “Remarks on the annex to a letter.”) In addition, Ms. Verzelen also sent an e-mail on 29 November commenting on a previous report (e-mail entitled “Remarks on the report by the Trustee”). In each instance, the remarks sent by the Commission preceded the Trustee’s final report. 37 The earlier versions of the Trustee’s reports to which Ms. Verzelen offered comments are classified as internal in the Commission’s list of documents. This necessarily means that they were different from the final version of the reports that were annexed to the Statement of Objections, since the final versions of the reports were sent to Microsoft and could not therefore be considered as internal.

- 20 IV.

THE STATEMENT OF OBJECTIONS CANNOT STAND BECAUSE IT FALSELY ACCUSES MICROSOFT OF REFUSING TO PROVIDE INTEROPERABILITY INFORMATION REQUESTED BY THE COMMISSION A. Microsoft Has Never Refused To Supply Information The Commission Has Requested

60.

Microsoft has uniformly attempted to supply the proper scope of Technical Documentation

according to its best understanding of the Commission’s requirements, although that has not been easy because of the Commission’s refusal to state its requirements in clear written terms. 61.

There is no mystery why the Commission refuses to state its standard for compliance

regarding Interoperability Information in clear written form. The Commission argues (1) that Microsoft’s competitors must have the ability to “achieve the same degree of interoperability with the Windows domain architecture as Windows work group server operating systems” in order to be viable competitors,38 while at the same time arguing (2) that the forced disclosure of Microsoft’s proprietary Interoperability Information will result in the emergence of “new products”39 (as opposed to merely leading to the creation of functional equivalents of Microsoft’s products). The Commission is compelled to make the second argument, in order to satisfy the established requirements for compulsory licensing of intellectual property (to wit, that compulsory licensing is necessary in order to allow the emergence of “new products” for which there is unmet demand). 62.

But it becomes impossible for the Commission to argue that any “new products” will

emerge when the Commission demands that Microsoft disclose such broad documentation that competitors can create “drop-in” replacement work group server operating systems (that is, products that are so much like Windows servers that they function in a manner equivalent to Windows server in performing work group server operating system functions). What will emerge are not “new products,” but competitors’ copies of the same product, in functional terms, that Microsoft already offers consumers. Viewed in that light, the Commission’s refusal to provide a clear written description of the scope of Technical Documentation it now demands is not surprising.

38 39

2004 Decision ¶ 669. See also Defence ¶¶ 110-1114, interpreting 2004 Decision ¶ 694.

- 21 63.

The Commission was also motivated to avoid a clear written statement of the broad scope

of documentation it demanded in the fall of 2005 because, by clearly demanding a broad scope of disclosure to competitors, it would be clear to everyone considering Microsoft’s appeal that the Commission was commanding the compulsory license of some of Microsoft’s most valuable intellectual property relating to the internal architecture and operation of the Windows server operating systems. 64.

The 2004 Decision requires “Interoperability Information” in the form of “specifications

for all the Protocols implemented in Windows Work Group Server Operating Systems.”40 Consistent with this operative language, the recitals of the 2004 Decision state that the Commission’s concept of effective interoperability requires disclosure only of “interface specifications”41 and that the Commission was not “ordering Microsoft to [disclose information that would] allow copying of Windows by third parties.”42 But there are also vaguely-worded recitals that speak of interoperability as requiring the ability to “achieve the same degree of interoperability with Windows domain architecture as Windows work group server operating systems do.”43 65.

Microsoft pointed out in its 7 June 2004 Application for Annulment that some recitals in

the 2004 Decision might be argued to require broad Interoperability Information sufficient to meet a standard of substitutability, or “plug replaceability.”44 That is, the Technical Documentation would need to allow competitors to develop products sufficiently similar to Microsoft work group server operating systems so that a Microsoft server could figuratively be unplugged and a competitor’s product plugged in as a replacement server that would operate as a substitute in “the same way that a Windows server operating system does.”45 66.

When Microsoft applied for interim measures in its appeal against the 2004 Decision, it

argued in part that any forced disclosure of such broad Interoperability Information would cause irreparable harm. The Commission and the interveners supporting the Commission stated in response that Microsoft did not need to fear any such interpretation of the 2004 Decision. At the 40

2004 Decision, Articles 1(1), 5(a). 2004 Decision ¶ 1004. 42 2004 Decision ¶ 572. 43 2004 Decision ¶ 669; see also ¶¶ 176-184, 679, 1003. 44 Microsoft Application for Annulment ¶¶ 67, 95, 98. 45 Microsoft Application for Annulment ¶ 88. 41

- 22 30 September 2004 hearing on interim measures, the President of the CFI asked the parties to comment on the required scope of disclosure. After Microsoft responded, the President asked the Commission if it wanted to comment. The Commission representative, Mr. Wainwright, responded, “[w]e would like Mr. Alepin to say something about this.” 67.

Mr. Alepin, on that day acting as an expert for the intervener CCIA in support of the

Commission, testified that “the communications protocol information which is sought . . . . are the specifications which describe the messages exchanged between the parties” (emphasis added). Additional interveners supporting the Commission agreed: “What is being requested is simply the wire protocol” (emphasis added) (Mr. Taylor for Novell); “We need to know what goes on the wire between those two machines and give that information. We do not need to know anything else” (emphasis added) (Mr. Allison for FSFE). The 22 December 2004 Order of the President subsequently also noted that the written materials submitted by Mr. Alepin on behalf of CCIA stated that the Interoperability Information to be disclosed would need to “reveal little or nothing about the internal structure, algorithms and other innovative aspects of the [Windows] operating systems.”46 68.

Microsoft understood these simple, direct statements by the Commission’s interveners,

speaking at the request of the Commission and without any correction by the Commission,47 to make it clear that the required Interoperability Information did not need to include information about the internals working of Windows. It should be limited to “the wire protocol” (Novell) or the “on-the-wire” protocol specifications for communications between machines (FSFE). Microsoft so stated in its Reply. In addressing the duty imposed by Article 5, Microsoft stated that it welcomed the clarification of the 2004 Decision provided by the unequivocal statements at the interim measures hearing that “disclaimed any interest in the internal workings of Windows server operating systems.” The Reply also pointed in this regard to statements in the Commission’s Defence filed on 29 October 2004 that also rejected an interpretation of the 2004 46

Order of 22 December 2004 of the President of the Court of First Instance in Case T-201/04 R at ¶ 262. 47 The Commission has indeed formally confirmed that it coordinated its observations regarding Microsoft’s request for interim measures in its appeal against the 2004 Decision with those of the interveners supporting it. See Observations of the Commission on the withdrawal of the intervention by the Computer & Communications Industry Association (CCIA) in Case T201/04 R (18 November 2004).

- 23 Decision that might have required Interoperability Information so broad as to allow competitors to create functionally equivalent work group server operating systems.48 69.

Microsoft supplied a draft of its Technical Documentation on 11 December 2004 for the

Commission’s review.49 Consistent with the events described above, this documentation was written to provide “on-the-wire” protocol specifications. 70.

On the same day, Microsoft also provided the Commission a detailed description of the

documentation to be provided licensees which stated explicitly that the documentation would cover “protocols used on the wire in networks,” and that this documentation concerning “messages exchanged over the network” would “not include the source code or other internal details of particular integrated or distributed software implementations of the protocol such as internal state management, data validation methods, processing algorithms and logic, or the architecture of a particular product or set of software components.”50 71.

There was extensive correspondence and communications between the Commission and

Microsoft concerning the form and content of the WSPP agreements during the remainder of 2004 and the first nine months of 2005, as partially reflected in the chronology of written contacts set out in the Article 24(1) Decision.51 72.

Microsoft’s description of the documentation being provided as covering only “protocols

used on the wire in networks” remained the same in all subsequent submissions of the draft license agreements to the Commission during the following months.52 The scope of documentation to be supplied was also recognized in discussions between Microsoft and the Commission staff. For example, at a meeting on January 19 there was a discussion of the need to reduce the licensee royalty rates Microsoft had proposed to take account of the fact that internal details of Windows server operating systems such as routing algorithms would not be included in

48

Reply ¶ 14, citing Defence ¶¶ 49, 66 & n.127. SO ¶ 14. 50 10 December 2004 draft Microsoft Work Group Server Protocol Program License Agreement, Appendix 2 (“Protocol Technical Documentation Specification”) at pp. 29-30 (emphasis added), attached to e-mail of 11 December 2004 from Greg Sivinski to Jurgen Mensching. 51 See Article 24(1) Decision ¶¶ 15, 18-38, 40-45. 52 E.g., 7 June 2005 Microsoft Work Group Server Protocol Program License Agreement, Appendix 2 (“Protocol Technical Documentation Specification”) at pp. 40-41. 49

- 24 the Technical Documentation. This argument by the Commission recognized, without disagreement, the scope of Technical Documentation that Microsoft had defined and submitted. 73.

The Commission never stated to Microsoft during this extended period that there might be

a problem with the “protocols used on the wire in networks” scope of the Technical Documentation submitted by Microsoft on 11 December 2004 and described explicitly in the draft license agreements. 53 It was not until 30 September 2005, more than nine months later, that the Commission first advised Microsoft of this possibility. Indeed, as shown by the Commission’s Article 24(1) Decision chronology, the Commission directed only a single communication on the adequacy of the Technical Documentation to Microsoft during this entire nine-month period, which did not challenge the scope of the documentation, and to which Microsoft promptly responded.54 74.

Specifically, on 15 June 2005, the Commission sent a letter to Microsoft forwarding a copy

of a four-page 11 June 2005 report by OTR concerning the Technical Documentation provided by Microsoft on 11 December 2004.55 75.

The 11 June 2005 OTR report did not criticize the scope of the Technical Documentation

supplied (to wit, “protocols used on the wire in networks”). It raised only “usability and accessibility”56 questions, to which Microsoft responded by letter on 8 July 2005. 57 Microsoft also submitted revised Technical Documentation on 8 August 2005.58 53

To the contrary, in a letter to Microsoft in March 2005 raising questions concerning the terms of Microsoft’s proposed WSPP agreements, the Commission referred to the focus of Article 5 of the 2004 Decision as requiring the disclosure of “interface information,” which was consistent with Microsoft’s description of the protocol specifications supplied to the Commission and offered to licensees. See letter of March 17 from Director General Lowe to Bradford Smith, Annex at ¶ 24. 54 See Article 24(1) Decision ¶ 39. 55 SO ¶ 17. See also letter of 15 June 2005 from Angel Tradacete to Jean-Yves Art and attached 11 June 2005 OTR Memorandum “Completeness of the Technical Documentation.” 56 SO ¶¶ 17-18. 57 Letter of 8 July 2005 from Jean-Yves Art to Angel Tradacete and Annex B thereto (response to OTR comment). The Statement of Objections mistakenly states that the 11 June 2005 OTR Report complained that the scope of Microsoft’s Technical Documentation was inadequate because OTR could not find information concerning “behaviors and dependencies.” SO ¶ 59. This is plainly wrong. The Statement of Objections relies for support for this assertion upon a purported quote from the first OTR report, which is attributed to page 2 of the 11 June 2005 report. SO ¶ 59 n.51. The quoted statement does not appear in the 11 June 2005 first OTR

- 25 76.

In its 8 July 2005 response to the OTR report, Microsoft addressed each of the headings of

criticism, including the asserted absence of adequate explanatory material, with regard to which Microsoft confirmed once again that the material was divided into reference topics that defined protocols being documented.59 77.

Microsoft also expressed its willingness, in its 8 July 2005 letter to the Commission, to

address such technical issues with the Commission and technical experts working with the Trustee. In that regard, Microsoft described the process being followed under the Microsoft Communications Protocol Program (“MCPP”) created under the U.S. settlement. That process includes continuous ongoing improvements in the technical documentation of protocol specifications covered by that program, many of which are also covered by the 2004 Decision. Under the MCPP program, Microsoft’s 8 July letter explained, Microsoft has refined and improved its specifications based upon input from MCPP licensees and independent technical experts, and a similar process could wisely be followed under the 2004 Decision as well.

report, however. The quote comes from a substantially later report OTR submitted to the Commission on 28 September 2005, where the quotation appears at page 7 in Section 1.3 (a report which the Commission did not disclose to Microsoft until 10 November 2005). In its effort to justify its attack upon Microsoft, the Commission has, at best, confused its sources. 58 Letter of 8 August 2005 from Jean-Yves Art to Cecilio Madero (providing revised documentation). 59 With regard to the OTR criticisms, Microsoft explained in Annex B to Mr. Art’s 8 July letter that the perceived lack of full “explanatory material” (OTR Report 1.1) may have been due to OTR’s failure to realize that links were provided to publicly available explanatory material rather than further swelling the size of the Technical Documentation; that OTR’s criticism that the documentation was not usable by persons not having access to the Microsoft programming environment (OTR 1.2) appeared to be based on a misunderstanding of the documentation; that OTR’s opinion that reverse-engineering would still be necessary (OTR 1.3) because of the absence of “protocol state diagrams” reflected a misunderstanding because most of the protocols were stateless (i.e., did not contain state information); that OTR’s criticism of a lack of “sequencing of messages” information (OTR 1.4) was also wrong because many protocols required no such information, and sequencing information was provided where necessary for more complex protocols; that OTR’s complaint that some items were “inaccessible”(OTR 1.5) could not be replicated by Microsoft and was likely the product of a corrupted file; that OTR’s complaints about the usability and speed of the computer screen viewing mechanism (OTR 2.1) also could not be replicated and were likely the result of a problem with OTR’s computer; and that OTR’s criticism that there were not enough explanations of the meaning of several elements of the documentation (OTR 2.2) was simply incorrect (explanations were provided, as shown in a computer screen shot printout included in Microsoft’s response).

- 26 78.

The Commission did not respond to Microsoft’s 8 July 2005 reply to the criticisms made

by the Commission’s consultants in June.60 79.

The first time the Commission suggested there might be a problem with the scope of the

Technical Documentation initially supplied by Microsoft on 11 December 2004 was when Director General Lowe called Mr. Bradford Smith, Microsoft’s General Counsel, on 30 September 2005 to review a list of nine issues the Commission believed needed to be addressed in order for the Commission to recognize that Microsoft was in compliance. 80.

The first issue, as summarized in an e-mail sent the next day, 1 October 2005, was that the

Commission had received “negative feedback on the completeness and accuracy of the documentation provided by Microsoft.”61 81.

Mr. Smith responded on 3 October 2005 pointing out that some prospective licensees

providing negative feedback might simply wish to obtain a broader scope of documentation than was required by the 2004 Decision as clarified by the Commission and its interveners at the interim measures hearing. 82.

Mr. Smith went on to state, however, that “[i]f the Commission wishes to determine that a

scope of disclosure that is greater than previously articulated is required, Microsoft will prepare additional documentation to satisfy that obligation as well, subject only to obtaining a clear and

60

Nor has the Commission responded to Microsoft’s offer in the 8 July 2005 letter to cooperate with licensees (and the Trustee) in addressing any difficulties, or to any of Microsoft’s other offers of ongoing cooperation and assistance for licensees. See, e.g., letter of 15 December 2005 from Steven Ballmer to Commissioner Kroes (renewing offers of cooperation, including 500 free hours of dedicated Microsoft technical support for each licensee). 61 E-mail of 1 October 2001 from Director General Lowe to Bradford Smith. Since the e-mail continued to state “We have not received any feedback yet and are working with our independent experts [OTR] on analyzing the issue,” Director General Lowe apparently was referring to “negative feedback” from Microsoft’s competitors who had reviewed the 8 August 2005 revised Technical Documentation. The Commission had made an Article 18 request to Sun on 5 September 2005 asking its reactions to the Technical Documentation, to which Sun had responded on 20 September asserting that the documentation was lacking in information on “behaviors and dependencies.” A similar request was made to Oracle on 22 September and, after Director General Lowe’s call to Microsoft on 30 September, to IBM and Novell on 4 October 2005. See Article 24(1) Decision ¶ 74 n. 78.

- 27 written position that preserves our right to seek court review of the Commission’s position in this regard.”62 83.

In short, Microsoft told the Commission only three days after being told for the first time

that there might be a problem with the scope of documentation provided that, if Commission wanted a greater scope of documentation, Microsoft would provide what the Commission wanted, while reserving its rights to challenge the Commission’s demands. 84.

Two days later, Mr. Steven Ballmer, CEO of Microsoft, met with Commissioner Kroes and

informed her and the other Commission representatives attending the meeting that Microsoft had supplied Technical Documentation in accordance with its understanding of the requirements of the 2004 Decision. 85.

Mr. Ballmer immediately went on to say, however, that if the Commission had a different

standard in mind, it should let Microsoft know what that standard was, and Microsoft would promptly supply additional Technical Documentation to meet that standard, while reserving Microsoft’s rights to bring the issue before the CFI for review. 86.

Commissioner Kroes responded that the Commission would tell Microsoft what its

standard for documentation was by the next day, 6 October 2005. 87.

On Friday, 7 October 2005, Director General Lowe wrote to Microsoft. In asserted

fulfillment of the Commissioner Kroes’s undertaking to tell Microsoft what the Commission’s standard for Technical Documentation was, the letter stated, “It is not clear why there might be any misunderstanding on Microsoft’s part as regards the scope of the interoperability information which it is obliged to disclose pursuant to the Decision.” The letter then simply quoted Articles 1(1) and 1(2) of the 2004 Decision, and stated “[t]he nature of this obligation has not changed.” 88.

Microsoft regarded this as a non-response, which it was. On Monday, 10 October 2005,

Mr. Smith called Director General Lowe, who informed him that DG Competition refused to 62

Letter of 3 October 2005 from Bradford Smith to Director General Lowe (emphasis in original). Mr. Smith also advised Director General Lowe in his letter that Microsoft would address six of the nine issues identified by Director General Lowe by making revisions to the WSPP Agreements as requested, and that Mr. Smith would provide a response on one of the two remaining issues by the next day, and suggested that the final issue (regarding the reasonableness of Microsoft’s proposed royalty rate for one protocol) be addressed with prospective licensees and the Trustee.

- 28 state in writing anything more informative about the required scope of Interoperability Information because of a concern that Microsoft would then renew its request for interim measures.63 89.

Mr. Smith told Director General Lowe that Microsoft strongly wanted to avoid any dispute

as to whether it had complied with Article 5, and was willing to promise in writing that it would not renew its request for interim measures if the Commission would simply confirm the scope of Technical Documentation it wanted, which Microsoft now understood to be the broader standard of “plug replaceability” disavowed by the Commission and its supporting interveners at the interim measures hearing a year earlier. Director General Lowe suggested to Mr. Smith that he write a letter saying that. 90.

Mr. Smith accordingly sent Director General Lowe a letter later on 10 October 2005 under

cover of an e-mail stating “Here is a letter along the lines that we discussed earlier today. If this misses the mark from our conversation, let me know and we can address that.” The letter stated: “I am writing to follow up on our phone call earlier today regarding the scope of technology that Microsoft is obligated to document under the Commission’s March 2004 Decision. We discussed two possible interpretative standards regarding ‘Interoperability Information’ as that term has been used by the Commission: one that would obligate Microsoft to provide technical documentation for all Windows technology under Article 1 of the Decision necessary to enable plug replaceability with the Windows domain architecture and another that focuses only on ‘protocols on the wire.’ To date Microsoft has prepared technical documentation according to the ‘protocols on the wire’ standard. We will promptly prepare such documentation according to the ‘plug replaceability’ standard, the ability to function in all respects like covered Windows server operating systems within the scope of Article 1, if the Commission instructs us that this is what the March 2004 Decision requires. As requested, I confirm that Microsoft will not use any statement by the Commission in this regard as a basis to seek interim measures regarding any aspect of protocol licensing or 63

The Commission doubtless had in mind that, in denying Microsoft’s request for interim measures in December 2004, the President of the Court had stated that the “rejection of an application for an interim measure does not bar the party who made it from making a further application on the basis of new facts. In the present case, it cannot be ruled out that a continuing disagreement as to the details of implementation of the Decision may be regarded as a ‘new fact.’” Order of 22 December 2004 of the President of the Court of First Instance in Case T201/04 R at ¶ 325.

- 29 documentation.”64 91.

Microsoft’s purpose in promising not to seek interim measures was to induce the

Commission to say clearly what it was the Commission wanted in order to allow Microsoft satisfy the Commission that it was complying with the Commission’s interpretation of Article 5 of the 2004 Decision. 92.

It did not work. No written description was forthcoming from the Commission.

93.

When the Commission did not reply, Mr. Smith had more conversations the next day, on

11 October 2005, with Director General Lowe, who informed him that DG Competition was unwilling to provide a written description of the compliance standard it was imposing, because Microsoft would place such a statement before the CFI to support its appeal against the 2004 Decision. 94.

Mr. Smith replied that this position was simply unfair.

95.

Director General Lowe said that Microsoft could write a letter to the Commission stating

its understanding of what the Commission was saying to Microsoft orally. 96.

Mr. Smith therefore sent a letter to Director General Lowe that same day, 11 October 2005.

After describing the background and reasons for Microsoft’s prior understanding of the required scope of Technical Documentation as limited to “protocols ‘on the wire,’” Mr. Smith wrote, “In view of our recent discussions,” Microsoft would submit the broader scope of documentation it understood the Commission to be requesting, including relevant algorithms “and other internal workings” of the Windows server operating systems. 65 97.

On the same day Mr. Ballmer also wrote a letter to Commissioner Kroes in which he also

promised that Microsoft would provide additional Technical Documentation, and would do so within six weeks, a very short time considering the complexity of the task.66 98.

Microsoft did what it promised, and submitted additional documentation in November

toward satisfying a “plug replaceability” scope of Technical Documentation.

64

Letter of 10 October 2005 from Bradford Smith to Director General Lowe (emphasis added.) Letter of 11 October 2005 from Bradford Smith to Director General Lowe (emphasis added.) 66 Letter of 11 October 2005 from Steven Ballmer to Commissioner Kroes. 65

- 30 99.

In short, Microsoft has never refused to supply Technical Documentation that the

Commission has requested. To the contrary, after the interim measures hearing, it understood the requirement to be documentation for “on-the-wire” protocols. It so advised the Commission a number of times in a number of ways. 100. When the Commission first indicated that there “might” be a problem on 30 September 2005, Microsoft stated clearly and in writing that, subject to its right to seek judicial review, it was willing to provide whatever the Commission was saying was required, if only the Commission would tell Microsoft in writing what the standard was. After this reasonable proposal, there ensued an unfortunate back and forth in which the Commission continued to say that Microsoft’s Technical Documentation was too narrow in scope, but refused to tell Microsoft in writing what the Commission’s standard was in clear terms. Microsoft nevertheless persevered and confirmed to the Commission in writing that it would supply additional Technical Documentation as quickly as possible, and in any event in no more than six weeks. Microsoft then did exactly that. B. The Assertion That Microsoft Has Refused To Provide More Than “On-TheWire” Protocol Information Is A Pure Fiction That Misrepresents History 101. The Statement of Objections accuses Microsoft of refusing to provide an appropriate scope of Technical Documentation, and even goes so far as to assert that Microsoft has provided only “on-the-wire” protocol specifications. To support that accusation, the Statement of Objections relies on the fact that Microsoft had described its documentation in terms of “protocols used on the wire in networks” in Appendix 2 to the draft WSPP agreements, and had described its previously submitted Technical Documentation in those terms in July and in later correspondence.67 102. The Statement of Objections ignores the fact that Microsoft explicitly and promptly undertook to provide the broader documentation required for “drop-in” replaceability when the Commission made that request in early October, and did so in November. 103. The Statement of Objections ignores the fact that in making its 15 December 2005 submission Microsoft explicitly suggested revising “protocols used on the wire in networks” description of the scope of Technical Documentation in Appendix 2 to the WSPP Agreements 67

SO ¶ 97.

- 31 because it was obsolete in view of the broader scope of documentation requested and submitted.68 104. The Statement of Objections ignores the fact that the earlier correspondence from October (which the Statement relies upon to claim that Microsoft has provided documentation only for “on-the-wire” protocols)69 described ”on-the-wire” protocols as the prior scope of documentation, but explicitly stated that Microsoft would submit additional documentation designed to satisfy the Commission’s request for a broader scope of documentation. 105. The Statement of Objections also ignores the fact that Microsoft did supply additional documentation on 11 November and 22 November 2005 which supplied a substantially broadened scope of Technical Documentation to satisfy the Commission’s assertion, first made only weeks before, that the 2004 Decision required additional information going beyond the specifications for protocols used “on the wire” in networks, which Microsoft had advised the Commission in December 2004 were being provided to potential licensees.70 106. In short, the Statement of Objections is demonstrably false, misleading and unfair in asserting that Microsoft has refused to supply Technical Documentation going beyond specifications for protocols used “on the wire” in networks. V.

THE STATEMENT OF OBJECTIONS CANNOT STAND BECAUSE IT WAS ISSUED BEFORE THE COMMISSION EVEN REVIEWED THE ADDITIONAL DOCUMENTATION MICROSOFT SUBMITTED ON 15 DECEMBER THAT REMEDIED ANY DEFICIENCIES VALIDLY ASSERTED BY THE ARTICLE 24(1) DECISION

107. There is a fundamental flaw in the Statement of Objections that would make the imposition of any fine on Microsoft unlawful: The Commission never reviewed the revised Technical Documentation that Microsoft made available on 15 December 2005, the deadline set by the Article 24(1) Decision for Microsoft to remedy the deficiencies asserted by that Decision and

68

Letter of 15 December 2005 from Bradford Smith to Director General Lowe. SO ¶ 97 & n.93 70 Letter of 11 November 2005 from Jean-Yves Art to Cecilio Madero (documentation for DRS protocol), letter of 22 November 2005 from Mary Snapp to Cecilio Madero (documentation for File Replication Service (FRS) and Directory File System (DFS) protocols). 69

- 32 thereby “fully compl[y] with the obligations set out in Article 5(a) and (c) of Commission Decision (C(2004)900) of 24 March 2004.”71 108. As set forth in detail in the following paragraphs, prior to the issuance of the Article 24(1) Decision, Microsoft strenuously sought to identify any remaining problems the Commission found with the Technical Documentation, in addition to submitting a broader scope of Technical Documentation as discussed in the previous section. After the issuance of Article 24(1) Decision, as also discussed below, Microsoft worked with the Commission to develop a work plan to revise the Technical Documentation to satisfy the Commission. 109. On 15 December 2005, in accordance with the deadline set by the Article 24(1) Decision, Microsoft submitted a large volume of material to further insure compliance with Article 5 of the 2004 Decision. In its cover letter describing that submission, Microsoft explained that it was making available at its headquarters in Redmond that day a revised version of the Technical Documentation responding to the criticisms in the Article 24(1) Decision (and in the Trustee Report received six days previously), and that its engineers were working to complete the digital protection process needed to make it accessible in electronic form.72 110. The Commission did not review the 15 December 2005 revised Technical Documentation prior to issuing the Statement of Objections on 21 December 2005.73

71

Article 24(1) Decision Article 1. Letter of 15 December 2005 from Bradford Smith to Director General Lowe. 73 The Commission also did not have access to any other copy of the 15 December 2005 revised Technical Documentation prior to 21 December 2005. Microsoft did send a copy of the Technical Documentation to the Commission in electronic form, but this was not possible until 22 December 2005, which was as soon as Microsoft was able to add digital rights management protection to the Technical Documentation to protect it from inappropriate further disclosure. It should be noted that there is no possible basis to argue that Microsoft did not comply with the 15 December 2005 deadline in making the documentation available that day at its headquarters. Article 1 of the Article 24(1) Decision requires Microsoft to comply with Article 5(a) and (c) of the 2004 Decision, which in turn require Microsoft to make Interoperability Information available to undertakings wishing to develop competitive operating systems and to establish a mechanism for such undertakings to evaluate the Interoperability Information. Microsoft discharged that responsibility by making the revised documentation available at its headquarters in Redmond (where competitors had, for example, previously evaluated earlier versions of the documentation), and so complied with the requirements imposed by the Article 24(1) Decision and Article 5(a) and (c) of the 2004 Decision. In addition, of course, Microsoft informed the Commission that the 15 December 2005 documentation was available at its headquarters (for the 72

- 33 111. It would be unlawful for the Commission to impose a fine upon Microsoft for failing to comply with the requirements of the Article 24(1) Decision in view of the undisputed fact that the Commission did not review the revised Technical Documentation Microsoft made available for review in compliance with the 15 December 2005 deadline imposed by the Article 24(1) Decision.74 112. The events leading to this extraordinary state of affairs – the issuance of a Statement of Objections accusing Microsoft of failing to comply with the Article 24(1) Decision without reviewing the revised Technical Documentation submitted by Microsoft to comply with that Decision – are set forth below. 113. Microsoft’s correspondence and conversations with the Commission during late September and October 2005 concerning the completeness of Microsoft’s Technical Documentation addressed only the scope of the documentation, specifically the assertion by the Commission “that Microsoft has not documented all of the Windows technology that it is obligated to document by the Decision.”75 114. In particular, the Commission made no mention during this period of usability issues concerning the form of the Technical Documentation, that is, whether the documentation was presented in such a way that a person knowledgeable in the subject area could work effectively with it to implement the functionality described in the documentation in a competiting operating system. 115. Four months previously, on 11 June 2005, the Commission’s consultants OTR had raised several usability issues with the original preliminary Technical Documentation that Microsoft Commission as well as potential licensees), and sent a copy to the Commission as soon as it was possible to do so. 74 The Commission acknowledges that it did not review the 15 December 2005 revised Technical Documentation, but attempts to justify that on the ground that it understood the documentation addressed merely “formatting” issues. See SO ¶ 93; see also Commission Memorandum “Competition: Statement of Objections to Microsoft for non-compliance with March 2004 decision -- frequently asked questions” (22 December 2005) (“The Commission understands that Microsoft has recently prepared revised documentation addressing only points relating to formatting (e.g., typos, missing hyperlinks), but not general concerns about completeness and accuracy”). In fact, as discussed below, significantly more important revisions were made. But the central, undisputed fact is that the Commission did not review the 15 December 2005 revised documentation prior to issuing the Statement of Objections on 21 December 2005. 75 Letter of 11 October 2005 from Bradford Smith to Director General Lowe.

- 34 had provided to the Commission in December 2004. Microsoft had responded with a letter explaining in detail why a number of OTR’s criticisms were based on misunderstandings,76 and had submitted revised Technical Documentation on 8 August 2005 to improve further the usability of the Technical Documentation.77 116. The Commission did not inform Microsoft that there was any remaining difficulty with the usability of the Technical Documentation at that time, and, despite repeated requests by Microsoft to identify any remaining compliance issues, the Commission did not thereafter assert any usability deficiencies until it issued its Article 24(1) Decision four months later on 10 November 2005, which suddenly resurrected usability as a claimed deficiency of the Technical Documentation. 117. Thus, three days after Microsoft confirmed to the Commission that it would submit additional Technical Documentation to broaden its scope, on 14 October 2005, Mr. Smith sent an e-mail to Director General Lowe saying, “I want to make sure that we’re addressing all the right issues. You’ve said over the last week that there are three issues that remain open: the additional technical documentation, the price for the No-Patent license for the DRS [Directory Replication Service] protocol; and flat-fee remuneration options for licensee. If there is anything else that is open on the Commission’s list, can you let me know so I can make sure we address it?”78 118. Director General Lowe responded the same day, “That seems to be the list, though I have one qualification on the no-patent license question.” Director General Lowe went on to request a new study not related to any issue addressed in the Statement of Objections. 79 119. Nothing was said by Director General Lowe about any usability issues concerning the Technical Documentation.

76

Letter of 8 July 2005 from Jean-Yves Art to Angel Tradacete and Annex B thereto. Letter of 8 August 2005 from Jean-Yves Art to Cecilio Madero. 78 E-mail of 14 October 2005 from Bradford Smith to Director General Lowe (emphasis added). 79 E-mail of 14 October 2005 from Director General Lowe to Bradford Smith (emphasis added) The unrelated new study requested by Director General Lowe was for a “technical analysis of the DRS protocol” applying the pricing criteria outlined in the draft WSPP Agreement. Microsoft submitted that newly requested technical report on the criteria for pricing licenses of the DRS protocol on 20 October 2005. See letter of 20 October 2005 from Bradford Smith to Director General Lowe. 77

- 35 120. Mr. Smith sent a letter to Director General Lowe on 16 October 2005 which reviewed the list of three open issues, and reconfirmed Microsoft’s commitment to provide the additional scope of Technical Documentation the Commission had requested, and estimated that 500 to 1,000 pages of additional documentation would be supplied within six weeks to supplement the over 12,000 pages already submitted. 121. Mr. Smith’s letter also emphasized that Microsoft would be “pleased to work with OTR [the Commission’s technical consultants] on a rolling basis to be sure that the additional set of technology conforms to the Commission’s expectations.”80 122. On 23 October 2005, Mr. Ballmer sent Commissioner Kroes a letter setting forth Microsoft’s understanding that it had responded to all nine open issues identified by Director General Lowe in his 1 October 2005 e-mail to Microsoft (including the commitment to provide additional Technical Documentation covering a broader scope of Windows technology). His letter concluded, “I hope you will conclude that Microsoft has satisfactorily addressed all of the concerns the Commission has identified.”81 123. During the following week, the Commission made still another new request, for pricing concessions on licenses. Microsoft also agreed to that new and additional request.82 124. Microsoft thought it was done, having responded to all of the Commission’s compliance concerns. 125. The Commission accepted all of Microsoft’s concessions and commitments, and responded by issuing its Article 24(1) Decision on 10 November 2005, accusing Microsoft of a range of deficiencies, not only in the scope of its Technical Documentation, but also with regard to the usability of that documentation, even though usability had not been suggested by the Commission to be a problem since Microsoft had responded four months previously, on 8 July 2005, to the concerns voiced by the Commission’s technical consultants.83

80

Letter of 16 October 2005 from Bradford Smith to Director General Lowe. Letter of 23 October 2005 from Steven Ballmer to Commissioner Kroes. 82 Letter of 29 October 2005 from Bradford Smith to Director General Lowe. 83 The Article 24(1) Decision also raised issues concerning the reasonableness of the remuneration Microsoft proposed offering to prospective licensees. 81

- 36 126. Despite Microsoft’s repeated offers to work with the Commission and OTR “on a rolling basis” to address any documentation issues,84 the Commission disclosed for the first time in its Article 24(1) Decision a second report it had received from OTR on 28 September 2005, six weeks previously, raising new criticisms of the usability of Microsoft’s Technical Documentation.85 Microsoft was only given a copy of this report, after several requests, on 9 December 2005.86 127. The Article 24(1) Decision set a short 15 December 2005 deadline for Microsoft to remedy the deficiencies asserted in the Decision.87 128. Despite its disappointment at the Commission’s action, on 11 November and 22 November 2005, Microsoft submitted extensive additional Technical Documentation in an effort to respond to the Commission’s oral demands made in October and in the Article 24(1) Decision88 129. During the weeks following 10 November 2005, Microsoft also had a number of conversations with the Commission concerning a work plan to satisfy the Commission that the other issues identified in the Article 24(1) Decision would be resolved by the 15 December 2005 deadline. 130. On 6 December 2005, the Commission mentioned it had received a report from the Trustee on the additional Technical Documentation that Microsoft had submitted in November 2005.

84

E.g., letter of 16 October 2005 from Bradford Smith to Director General Lowe. Article 24(1) Decision ¶ 46. The Article 24(1) Decision also revealed for the first time criticisms of the usability of the Technical Documentation the Commission had obtained from Microsoft’s competitors during the period between 20 September and 21 October 2005. Article 24(1) Decision ¶¶ 74 n.78, 83-91. 86 Letter of 9 December from Cecilio Madero to Jean-Yves Art. 87 Article 24(1) Decision, Article 1. 88 Letter of 11 November 2005 from Jean-Yves Art to Cecilio Madero (documentation for DRS protocol), letter of 22 November 2005 from Mary Snapp to Cecilio Madero (documentation for File Replication Service (FRS) and Directory File System (DFS) protocols); see also e-mail of 30 November 2005 from Marianne Holifield to Trustee Barrett (confirming that additional documentation supplied for DRS, FRS and DFS protocol had been supplied to satisfy the Commission’s requests). The 30 November 2005 e-mail also explained the reasons why additional documentation was not necessary for the other protocols in the WSPP program in order to provide the additional functionality requested by the Commission. 85

- 37 After a second request from Microsoft, the Commission sent this 30 November 2005 preliminary report by the Trustee to Microsoft on 8 December 2005.89 131. In short, the Statement of Objections proposes to fine Microsoft for failing to respond in six days (from December 9 to December 15) to all the criticisms raised in its Trustee’s 30 November 2005 report, which the Commission withheld for 10 days from Microsoft, and the 28 September 2005 OTR report, which the Commission withheld for 71 days, despite Microsoft’s frequent requests to the Commission to call any problems immediately to Microsoft’s attention.90 132. On 15 December 2005, in accordance with the deadline set by the Article 24(1) Decision and the work plan Microsoft had discussed in detail with the Commission, Microsoft submitted a large volume of material to further ensure compliance with the 2004 Decision as now being interpreted by the Commission and to satisfy the concerns raised in the Article 24(1) Decision. 133. Microsoft explained in its cover letter to that submission that, in addition to materials responding to concerns about the reasonableness of Microsoft’s proposed rates for licensees, Microsoft was making available that day a revised version of the Technical Documentation responding to statements concerning usability issues made in the Article 24(1) Decision and in the Trustee report received just six days earlier. The letter also noted that Microsoft had previously, on 11 November and 23 November, provided more than 450 pages of new documentation to satisfy the Commission’s statements in October concerning the need for a broader scope of documentation. 91 134. The 15 December 2005 Microsoft letter also suggested that, in view of the broader scope of documentation requested by the Commission and submitted by Microsoft, it would make sense “to develop a revised specification to that now in place (and provided as Appendix 2 to the WSPP license agreements).” As previously discussed, Appendix 2, provided to the Commission in December 2004, described the scope of documentation to be provided as covering “protocols used on-the-wire in networks.”92 89

E-mail of 8 December 2005 from Bradford Smith to Director General Lowe; letter of 8 December 2005 from Cecilio Madero to Jean-Yves Art (sent 9 December 2005). 90 E.g., letter of 8 July 2005 from Jean-Yves Art to Angel Tradacete. 91 Letter of 15 December 2005 from Bradford Smith to Director General Lowe. 92 See 10 December 2004 draft Microsoft Work Group Server Protocol Program License Agreement, Appendix 2 (“Protocol Technical Documentation Specification”) at pp. 29-30

- 38 135. Microsoft also provided a response on 15 December 2005 to the concerns expressed in the Trustee’s preliminary report of 30 November 2005.93 The response went on to point out that this additional documentation provided extensive information concerning the internal implementation of Windows functionality (information which is not included in protocols used in network communications), including various identified algorithms and architectural information concerning internal components of Active Directory. 136. With regard to the usability concerns stated by the Trustee, the Microsoft response apologized that the abbreviated schedule on which it had prepared additional documentation submitted in November 2005 had created presentational issues, but stated that the revised documentation being made available on 15 December 2005 and sent to the Commission addressed the Trustee’s usability concerns. These revisions included clarifying instructions for use and the suggested order of reading, improved consistency in the use of terminology in references to topics, the addition of hyperlinks between topics to make the documentation more easily navigable, integration of the additional documentation provided in November into the previously-existing documentation to enable more effective searching and ease of use, and further reviews to correct any remaining typographical spelling errors. 137. Microsoft also offered to make available “free of charge to all program licensees a total of 500 hours of dedicated Microsoft technical support to help licensees implement the protocol specifications” as part of its continuing effort “to be creative and proactive in identifying

(emphasis added), attached to e-mail of 11 December 2004 from Greg Sivinski to Jurgen Mensching. 93 Microsoft Response to Trustee Report “WSPP Documentation Review Preliminary Report 30th November 2005” at p. 6 (Annex 2 to 15 December 2005 Submission). The response also noted, as had the Microsoft cover letter, that the Article 24(1) Decision at ¶ 63 used a slightly different phrasing of the required scope of documentation as that necessary to enable competitors to develop products that “interoperate with the Windows domain architecture on an equal basis with Microsoft’s [work group] operating system products,” which Microsoft stated it understood to be “a linguistic formulation with equivalent meaning” to the “drop-in” standard of replaceability articulated by the Commission in October. It should also be noted that of course one would not literally unplug one server and plug in another, whether dealing with Windows or non-Windows servers. In the context of a Windows server operating system acting as a domain controller, one would join the new domain controller to a domain and then delete the machine which previously held that role.

- 39 additional steps that may make the protocol licensing program more attractive, above and beyond our legal obligations under the Commission’s 2004 Decision.”94 138. Despite Microsoft’s substantial and serious efforts to reach the ever-receding horizon of the Commission’s demands for achieving compliance, the Commission was not to be deterred from its pre-holiday rush to impose a punitive daily fine on Microsoft. The Commission issued the Statement of Objections on 21 December 2005. 139. The Statement of Objections brushes aside the Commission’s failure even to review Microsoft’s revised Technical Documentation of 15 December 2005 by attempting to suggest that those revisions were immaterial because Microsoft had said they addressed only “formatting” issues.95 The Microsoft response to the Trustee’s preliminary report, from which the Commission extracted the word “formatting,” explicitly stated, however, that the revisions addressed the very same usability concerns the Trustee had raised in his 30 November 2005 report.96 94

Letter of 15 December 2005 from Steven Ballmer to Commissioner Neelie Kroes. SO ¶ 93. The Commission might conceivably also attempt to quarrel with the fact that Microsoft made the revised and improved documentation available at its headquarters in Redmond WA on 15 December 2005, and was only able to send a copy to the Commission in electronic form on 22 December 2005. Any such arid formalism would be senseless in view of the fact that Microsoft informed the Commission on 15 December that the documentation was available at its headquarters that day, and in view of the minimal time the Article 24(1) Decision had allowed Microsoft to remedy the alleged deficiencies (after the Commission had failed to inform Microsoft of the second OTR report criticizing the documentation for over two months and had failed to inform Microsoft of the Trustee’s critical 30 November report for over a week). In any event, Articles 5(a) and 5(c) require Microsoft to make Interoperability Information available to undertakings wishing to develop competitive operating systems and to establish a mechanism for such undertakings to evaluation the Interoperability Information. Microsoft discharged that responsibility by making the revised documentation available in Redmond (where competitors had, for example, previously evaluated earlier versions of the documentation), and so complied with any requirements imposed by the Article 24(1) Decision. 96 See Microsoft Response to Trustee Report “WSPP Documentation Review Preliminary Report 30th November 2005” at p. 1 (Annex 2 to 15 December 2005 Submission). For the Commission’s continued reliance upon the usability issues raised in the Trustee’s 30 November report and addressed in Microsoft’s unread 15 December 2005 revisions to the Technical Documentation, see Statement of Objections ¶¶ 76-79. The Statement of Objections also relies upon similar criticisms of usability by the Trustee in his second report of 15 December 2005, which was issued before the Commission afforded him any opportunity to review Microsoft’s revised documentation. SO ¶¶ 84-86, 92. The Statement of Objections also continues to rely upon usability concerns raised by the Commission’s technical consultants OTR in their review of 95

- 40 140. The Commission’s attempt to justify ignoring Microsoft’s 15 December 2005 documentation, which Microsoft created and made available on the deadline stated by the Article 24(1) Decision, also ignores the Commission’s promise in issuing the Article 24(1) Decision that “[w]ith the help of the Trustee, we will evaluate the updated documentation” required by the Decision.97 VI.

MICROSOFT HAS MADE A MAJOR EFFORT TO COMPLY WITH THE 2004 DECISION IN THE SAME WAY IT HAS COMPLIED WITH THE U.S. SETTLEMENT AND LICENSING COMMITMENTS MADE IN PRIVATE TRANSACTIONS

141. There are at the outset several facts appropriate to place in context the scenario painted by the Statement of Objections of a willful failure by Microsoft to produce Technical Documentation compliant with Article 5 of the 2004 Decision. Before turning to the direct evidence that Microsoft has indeed complied, it is useful to review this broader context of relevant facts. 142. As described in greater detail below, Microsoft has committed very substantial resources to providing the required Technical Documentation. Much of the Technical Documentation has been provided in the United States as part of the Microsoft Communications Protocol Program (“MCPP”) created as part of the U.S. settlement, and has been found helpful there by all concerned. Finally, Microsoft is experienced in licensing complex technology in private transactions, and the approach it has followed there of providing sound documentation and agreeing to then work cooperatively with licensees has been followed here. A. Microsoft Has Committed Major Resources To Providing Interoperability Information 143. Microsoft has taken its duty to comply with Article 5 seriously. Over 200 Microsoft employees, including senior executives, have been involved in the production of the Technical Documentation. In addition, Microsoft engaged over 20 outside contractors to work on specific tasks in the production of the Technical Documentation as well as a team of computer scientists from Microsoft’s research facility in China and a team of consultants in India. Collectively, Microsoft’s employees and outside contractors have spent an estimated 35,000-40,000 working the 8 August 2005 edition of the Technical Documentation, without allowing OTR either any opportunity to review Microsoft’s 15 December 2005 revised documentation. SO ¶¶ 61-66. 97 Letter of 9 November 2005 from Commissioner Kroes to Steven Ballmer.

- 41 hours since the end of 2001 to prepare and refine the Technical Documentation submitted to the Commission.98 144. Microsoft’s efforts to comply with Article 5 of the Commission’s 2004 Decision are described in a report by Mr. Gene Chellis, Director, Competitive & Regulatory Affairs.99 Mr. Chellis has been involved in the preparation of the MCCP documentation and the Technical Documentation since 2001. His experience at Microsoft includes server product group program management and Windows business development management. Prior to joining Microsoft, Mr. Chellis developed significant expertise in areas relating to software programming, technology consulting, technology startup management, and legal affairs. 145. Microsoft’s compliance efforts were lead and managed by a core team headed by Mr. Chellis. Since the beginning of the work in 2001, between eight and fifteen Microsoft employees have worked on his team, including Greg Gilkeson, Director Regulatory Engagement, who has a wide experience in the management of the operational side of numerous compliance projects; Thomas Pfenning, a senior software architect; and Lisa Supinski, Senior Business Program Manager, who has more than five years of experience managing technical documentation projects and teams at Microsoft as well as experience in hands-on document writing. It is estimated that the members of the core team collectively spent between 8,000 and 9,000 working hours on the Technical Documentation. 146. The actual documentation writing was carried out by a team of over 25 documentation and product experts, headed by Mr. Roy Hirst as technical lead and writing manager. Mr. Hirst has 17 years experience in network and embedded systems programming and worked for ten years as developer documentation specialist. The documentation and writing team included writing and/or technical advisors, production specialists, software tools experts, a document builder, an 98

Since Microsoft employees generally do not bill time like lawyers to various task and projects and also do not keep specific records on how much time they spend on various tasks, the time spent on the Technical Documentation had to be estimated on the basis of information obtained from the employees directly working on the Technical Documentation or their supervisors. Also, as will be described in more detail in the following section, a number of protocols included in the Technical Documentation have also been made available in the U.S. as part of the MCPP program. Therefore, time spend on the MCPP documentation has been allocated to the WSPP Technical Documentation on a proportionate basis to the extent it related to protocols included in the Technical Documentation. 99 Report on Compliance Effort (“Compliance Effort Report”) submitted as Annex 1.

- 42 ebooks specialist, and a software design engineer. The documentation and writing team spent an estimated total of more than 12,000 hours on the Technical Documentation. 147. Furthermore, Microsoft entrusted outside contractors in the United States, a team from its computer science research facility in China and consultants in India with specific tasks with respect to the preparation of the Technical Documentation. It is estimated that the outside contractors collectively spent about 12,000 hours on the Technical Documentation. 148. The Technical Documentation was reviewed for quality assurance by each of the product engineering teams responsible for the specific features of the code that were documented. Microsoft has identified some 150 employees who reviewed parts of the Technical Documentation, but believes the number may be higher. It is conservatively estimated that the reviewers collectively spent about 800 hours reviewing the Technical Documentation. 149. Finally, several members of Microsoft’s Legal and Corporate Affairs department were also involved in the compliance effort. Their time spent on the project, however, has not been included in the estimated 35,000-40,000 hours. 150. The above clearly demonstrates that Microsoft has taken the task of providing the Technical Documentation pursuant to Article 5 very seriously and committed significant resources to the writing of the Technical Documentation, both with respect to the qualifications of the employees working on the project and also with respect to the large amounts of time these employees spent on the project. B. A Substantial Part of Microsoft’s Documentation Has Been Submitted In The U.S. Proceedings And Successfully Licensed To Many Companies While Undergoing A Productive Ongoing Process Of Refinement And Improvement 151. A number of the 52 protocols covered by WSPP have already been made available to licensees under the MCPP created pursuant to the U.S. settlement. The MCPP program has made available 110 client-to-server protocols. Some involve functions outside the WSPP work group server operating system area, but a significant number of protocols, including ones specifically criticized by the Trustee, are common to both programs.100 For such common protocols, a single source is used to generate both the WSPP documentation of those protocols 100

The WSPP program also includes server-to-server protocols, which are not covered by the MCPP program.

- 43 and the MCPP documentation so that ongoing improvements made to the MCPP documentation directly and immediately benefits the WSPP program as well. Even those protocols newly documented in WSPP were documented by the same team of technical writers, editors, and supervisors, using the same standards for documentation content, format, and level of detail, as under the MCPP program.101 152. In contrast to the claims of the Commission and the Trustee that the WSPP documentation is “totally unfit at this stage for its intended purpose,” through the MCPP program, companies are licensing much of this same documentation and are shipping products incorporating the documented protocols. There are presently 28 companies that have entered licenses under the MCPP program, including eight companies that have licensed protocols that overlap substantially with WSPP. Twelve licensees are shipping products incorporating MCPP protocols and intellectual property rights, including two companies licensing protocols that overlap substantially with WSPP. Since the ultimate purpose of both MCPP and WSPP is to encourage the development of interoperable products, these licensees and their products demonstrate that the MCPP and WSPP documentation are indeed fit for their intended purposes. 153. Microsoft has worked closely with these numerous licensees, together with the United States Department of Justice and the various other interested parties, to ensure that the documentation provided by Microsoft is usable and suitable to achieve the purposes of the MCPP program, particularly in conjunction with the ongoing review and refinement process in which Microsoft participates to make the program a success. 154. The Commission has so far taken the approach of initiating legal proceedings based on comments from parties that have not had, and have not sought, a reasonable opportunity to work with Microsoft on their concerns. The MCPP program models a more realistic and constructive process to improve documentation iteratively and using implementation experience. This approach has allowed Microsoft to focus its energies under the MCPP program on efforts that will ultimately improve the documentation for the benefit of licensees.

101

The description in this section of the MCPP program is based upon Report on U.S. Protocol Specification Program & Private Licensing Programs (“MCPP & Private Licensing Report”) submitted as Annex 2.

- 44 155. When Microsoft responded on 8 July 2005 to the criticisms in the 11 June 2005 OTR report of the preliminary Technical Documentation submitted to the Commission on 11 December 2004, it pointed out to the Commission that to the extent licensees (or the Trustee) had questions concerning the documentation or believed there were errors, “[w]e already have . . . a process for continuous improvement of the MCPP program in place with the US Department of Justice, various States, and the Technical Committee, all of whom recognize that over time there will be many opportunities to adjust and improve the MCPP technical specifications based on input from licensees and independent technical experts.” The letter went on to point out, “Microsoft is open to the possibility that a similar process be put in place for technical engagement between Microsoft, the Commission, and technical experts working on behalf of the Trustee.”102 156. In order to carry out this process of continuous improvement, a Technical Committee advises Microsoft and the U.S Department of Justice on technical issues relating to the implementation of the U.S. Consent Decree, and the Technical Committee has led the work with Microsoft on the process of continuous improvement of the technical documentation made available under the MCPP. This Technical Committee is composed of three members with expertise in software design and programming, and its mandate is “to assist in enforcement of and compliance with” the terms of the U.S. settlement, including the MCPP program. 157. Importantly, the Technical Committee has worked cooperatively with Microsoft to determine procedures for ensuring compliance. The portions of the Joint Status Reports filed with the U.S. district court that are authored by the U.S. Department of Justice and the various States contain numerous references to this cooperation, referring to “dialog between the [Technical Committee] and Microsoft” and joint efforts to “develop a standard for completeness to which the documentation will be held.” These efforts culminated in the development of implementation and validation projects that the U.S. antitrust agencies called a “comprehensive plan to ensure the completeness and accuracy of the technical documentation and to accomplish further work on the documentation.” 158. In contrast to the approach the Commission and Trustee have so far taken, the Technical Committee has worked closely with Microsoft in a sustained and substantial manner on its 102

Letter of 8 July 2005 from Jean-Yves Art to Angel Tradacete.

- 45 validation projects. From the beginning, U.S. antitrust agencies envisioned that validation would be at least a one-year project, and that it would involve hiring a number of additional engineers. Microsoft was asked to “work closely with the [Technical Committee] . . . to define the scope of this project,” and throughout the project, Microsoft and the Technical Committee have met “on a weekly basis,” conferring “regularly on this part of the project.” 159. Microsoft has also put in place a detailed process for collecting issues as they arise and for addressing these issues and is in the process of rapidly adding additional resources to ensure that it can stay current in reviewing and responding to issues raised. Some of these issues are resolved through changes to the documentation, but a “substantial number of issues have also been closed with no change to the documentation required; for example, in some of these cases the [Technical Committee] has been able to locate the necessary information in sources other than the technical documentation itself.” For those issues that do result in changes to the documentation, the close working relationship between the Technical Committee and Microsoft, together with monthly updating of the documentation, ensures that improved documentation quickly reaches “the hands of licensees.” 160. Under the MCPP program, Microsoft also has undertaken to provide 500 hours of free technical and consulting support for the MCPP protocol specifications, in addition to unlimited correction assistance free of charge to address those situations where corrections have been found necessary.103 This technical support includes developer support not only to address issues with the documentation itself, but also to provide guidance on issues with the operation of MCPP protocols between licensee products and Windows products. MCPP licensees can also take advantage of the extensive technical resources provided by the Microsoft Developer Network (“MSDN”) on advantageous terms, and like other Microsoft licensees and customers can obtain additional technical support. 161. This process of working cooperatively with the Technical Committee to find and address issues with the documentation and of working cooperatively with licensees to assist them in their development efforts demonstrates Microsoft’s commitment to the ultimate goal of encouraging the development of interoperable products. Both the suitability of the protocol specifications 103

Microsoft has already offered to make the same free technical support available under the WSPP program. See letter of 15 December 2005 from Steven Ballmer to Commissioner Kroes.

- 46 Microsoft has provided under the MCPP program and the process for continued cooperation by Microsoft to work with the other parties in that program provide relevant evidence of Microsoft’s willingness and ability to comply with the requirements of the WSPP program. C. Microsoft Has Licensed Complex Technology In Private Transactions And Has Successfully Implemented Those Programs 162. Microsoft has also engaged in a number of private transactions for licensing complex technology. As with the MCPP program, these licensing arrangements have succeeded through a combination of Microsoft’s ability and willingness to provide detailed, usable documentation for the technology in question, and Microsoft’s continued interaction with these private licensees to assist them in successfully making use of the technology and to refine and improve the documentation as necessary.104 163. Microsoft has substantial experience in licensing specifications for network protocols comparable to the protocols in the MCPP and WSPP programs, with some programs dating back to 2000. Indeed, Microsoft separately licensed at least some parts of certain protocols, such as the Remote Desktop Protocol (“RDP”), before the inclusion of these protocols in the MCPP program. Most of Microsoft’s network protocol programs have at least a half-dozen licensees, with the Windows Media Networking Protocol program having more than 60. 164. Microsoft has always understood the importance of continuing to work with licensees in these programs, to assist in the development of the products that are ultimately the goal of such programs. In some cases, such as the Live Communications Server protocol and the RDP, this has meant that the product development teams who created the protocols work directly with licensees and help them not only with correction assistance, but with assistance in integrating the protocols into their products. Microsoft provides this assistance despite the absence of any contractual obligation on Microsoft’s part to do so. In other cases, such as the ActiveSync licensing program, this has meant training a team of support specialists in Microsoft’s Product Support Services division to provide additional support beyond that provided by the product development team, despite having too few licensees to justify this additional support function on a cost basis.

104

The description in this section of Microsoft’s private licensing programs is based upon the MCPP & Private Licensing Report.

- 47 165. Microsoft’s substantial experience in the private licensing of networking protocols and its commitment in such cases to working with licensees to develop products is further evidence of Microsoft’s willingness and ability to comply with the requirements of the WSPP program. VII.

MICROSOFT HAS COMPLIED WITH ARTICLE 5 OF THE DECISION

166. Microsoft has asked independent experts with deep experience in network operating systems to review the Technical Documentation made available on 15 December 2005 and to evaluate the criticisms made in the Statement of Objections and materials relied on therein. The Report of Professor Anthony Finkelstein et al. (“Finkelstein Report”) is attached as Annex 3, and the Report of Professor Manfred Broy (“Broy Report”) is attached as Annex 4. 167. These independent experts have concluded that, contrary to the allegations of the Statement of Objections, Microsoft’s Technical Documentation plainly extends beyond “on-thewire” protocol specifications. Moreover, they have concluded that the Technical Documentation fully conforms to industry standards in providing a basis for prospective licensees to develop work group server operating systems that can work on an equal basis with Microsoft’s own products within the Windows domain architecture. 168. The criticisms by the Trustee and others do not establish otherwise. They are mistaken, outdated, or resolvable by a process of continued interaction with Microsoft, of the sort Microsoft has repeatedly suggested. A. There Is No Truth To The Claim In The Statement Of Objections That Microsoft Has Refused To Provide Technical Documentation Going Beyond “On- The-Wire” Protocol Specifications 169. The Statement of Objections asserts that the Technical Documentation is “based solely on the documentation of the ‘on-the-wire’ information” and that Microsoft has refused to supply Technical Documentation broader in scope than “on-the-wire” protocol specifications.105 170. As explained in Part IV, these allegations flatly ignore Microsoft’s repeated written undertakings to supply a broader scope of documentation to satisfy the broader scope of documentation articulated by the Commission in early October 2005.

105

SO ¶ 97; see also SO ¶¶ 100-101.

- 48 171. Moreover, these allegations completely disregard the fact that Microsoft supplied 450 pages of additional documentation on 11 and 22 November 2005 which expanded the scope of the Technical Documentation to go substantially beyond the previously provided specifications for protocols used “on the wire,” in order to satisfy the Commission’s demands for broader documentation.106 172. Both Professor Finkelstein and Professor Broy have confirmed that the additional documentation submitted by Microsoft in November 2005 (as well as the further enhanced version submitted in December 2005) contains information relating to the internal architecture of Windows server operating systems that goes well beyond information contained in “on-the-wire” protocols and addresses the issues required to allow prospective licensees to develop a substitute work group server operating system for use within the Windows domain architecture.107 173. The information needed to develop such operating systems can be placed in three categories: (a) protocols for client-server and server-server interactions that are visible “on-thewire,” (b) dependencies between services on two different servers that are not necessarily visible on the wire or at interfaces, and (c) “implicit knowledge” by a service on one server of the state of a service on another server resulting from the application of the same algorithms on each server to copies of the same data.108 The Technical Documentation covers all three categories: protocols, dependencies and implicit knowledge, and “goes significantly beyond what is ‘on-thewire’ so as to assist skilled and knowledgeable software developers to develop a Work Group Server operating system that can work on an equal basis with Microsoft’s own products within the Windows domain architecture.”109 B. Microsoft’s Technical Documentation Complies With The Requirements Of The 2004 Decision In A Manner Entirely Consistent With Established Industry Practice 174. As set forth in the expert reports of Professors Finkelstein and Broy, the Technical Documentation provided by Microsoft satisfies the Article 5 requirement for Interoperability 106

Letter of 11 November 2005 from Jean-Yves Art to Cecilio Madero (documentation for DRS protocol), letter of 22 November 2005 from Mary Snapp to Cecilio Madero (documentation for File Replication Service (FRS) and Directory File System (DFS) protocols). 107 Finkelstein Report ¶ 0.3; Broy Report p. 3. 108 Finkelstein Report ¶¶ 0.3, 1.9, 1.10, 1.11. 109 Finkelstein Report ¶ 0.3.

- 49 Information in a manner that is entirely consistent with established industry practice. Assertions to the contrary are based on utterly unrealistic and demonstrably incorrect assumptions in the Statement of Objections about how technical specifications are actually developed and used, not only by Microsoft, but by any company that might actually seek to develop a work group server operating system or similarly complex product. 175. While many of the unsupportable criticisms of Microsoft’s Technical Documentation set forth in the Statement of Objections are based upon opinions expressed by the Trustee, the fault lies not with the Trustee but with the Commission. The Trustee acts upon the instructions of the Commission, and many of the deficiencies of the Statement of Objections flow from the fact that the Commission apparently directed the Trustee to reach conclusions in too short a time, without opportunity to carry out a more realistic process of review of the Technical Documentation, and without any opportunity at all to evaluate the documentation Microsoft made available on 15 December 2005 in response to the Article 24(1) Decision. 176. Microsoft work group server operating systems are enormously complex software systems, implemented in tens of millions of lines of source code. As explained in the expert reports, specifications for such complex systems can never be expected to be used by persons without appropriate background knowledge. Nor can they be used without reference to external sources of information. Nor can they be developed without errors or omissions in one or a few increments. Nor can they be perfected in isolation from an iterative real-world effort to use the specifications for developing an interoperable product. 177. On the contrary, the only realistic process for such a complex system is (a) addressing the Technical Documentation to an audience of skilled engineers who already possess knowledge of the Microsoft network and programming environment and an ability to find and use relevant external information, (b) working diligently to determine how the Technical Documentation could be improved and issuing enhanced releases to achieve such improvements, and (c) offering live technical support from knowledgeable developers who can address issues that actually arise in the use of the documentation to develop server operating system products.110 The claim in the Statement of Objections that this approach is somehow deficient can only be based on a disregard of real industry practice. 110

Finkelstein Report, including ¶¶ 0.3, 5.3 & 5.4; Broy Report, including p. 3 & §§ 1.3.3 & 1.4.

- 50 178. One of the Trustee’s principal criticisms of the Technical Documentation is that it “assume[s] prior knowledge of the Microsoft environment.”111 This criticism maintains that the Technical Documentation, to be sufficient, must enable a person with no prior knowledge of the Microsoft network and programming environment to implement the work group server operating system functionalities described by the Technical Documentation. As stated by Professor Finkelstein, this criticism of the documentation is “[o]ne of the most surprising of the criticisms advanced by the Trustee” and “can only be regarded as naïve and hardly a good working basis for the tasks that the documentation envisages.”112 Indeed, the thought that any company seeking to develop a work group server operating system comparable to a Windows server operating system product would attempt this task using only engineers who knew nothing of the Microsoft environment is entirely divorced from reality.113 179. Equally groundless is the basic assumption, relied on by the Statement of Objections, that the interoperability Technical Documentation should be “free standing.”114 As stated in the Finkelstein Report, this assumption not only “is not a realistic requirement” but actually “runs counter to good software engineering practice.”115 The Finkelstein Report explains: “It is a basic error to confuse completeness with the notion that a specification should be useable on a free-standing basis. Indeed, were it even possible to 111

Trustee’s Preliminary Report dated 30 November 2005 (“Trustee’s 1st Report”) p. 1. Finkelstein Report ¶ 8.1. 113 Merely “[d]eploying” Windows Server 2003 that is, installing and configuring it, out of the box, on server hardware, without writing any code “is a substantial undertaking, even on a small network,” and merely “planning” such a deployment “can be a daunting process . . . .” William R. Stanek, Microsoft Windows Server 2003 Inside Out p. 31 (2004). A book on Windows Server 2003 aimed at those who do not create operating systems software, but merely administer networks, notes that, even though the book is 1,400 pages in length, the author “is assuming” that the reader already has not only “basic networking skills” but at least “some experience managing Windows-based networks.” Id. The idea that one could actually create an operating system that interoperates with Windows Server 2003 to the degree demanded by the Commission without any “prior knowledge” of the Microsoft environment is difficult to comprehend. 114 Trustee’s “WSPP Documentation Sufficiency Test,” second page. (The Trustee’s “WSPP Documentation Sufficiency Test” document, which was provided to Microsoft by the Commission by letter dated 17 January 2006, is undated and bears no page numbers.) See also Response of Sun Microsystems, Inc. to Commission Art. 18 Request dated 5 September 2005 (“Sun Response”), Response 2 item 3: “In Sun’s view the protocol documentation should be complete within its four corners and neither assume nor require additional Microsoft information residing elsewhere.” 115 Finkelstein Report ¶ 5.1. 112

- 51 provide documentation that could be completely free-standing, that documentation would probably as a result be so large as to be wholly unusable. . . . External standards upon which a Microsoft implementation relies should clearly be referenced, and indeed they are. It would make no sense to copy such information into the documentation in all but the most limited cases. To do so would risk the infamous ‘double maintenance problem’: an error is detected in the standard, or additional clarification information, such as notes on superseded features, is appended and there would be no guarantee that these would be carried across to the WSPP documentation.”116 180. The Finkelstein Report further notes: “Interestingly where Microsoft has deemed it necessary to copy information from other sources, competitor evaluators have complained.”117 Whereas competitors like Sun complain that Microsoft has included too little external information,118 Oracle complains that Microsoft has included too much.119 As far as Microsoft’s critics are concerned, Microsoft is “damned if it does and damned if it doesn’t.” Such criticism is obviously biased and unreliable. 181. Likewise, the Broy Report affirms that Microsoft’s decision to address the Technical Documentation to an audience of skilled engineers who possess the requisite prior knowledge, with the expectation that they would refer to materials external to the documentation as a natural part of the development process, was in fact the only choice consistent with industry practice. If Microsoft had prepared the Technical Documentation for persons with no prior knowledge of the relevant network and programming environment who were not going to look at anything else, the Technical Documentation would have been far less usable, if usable at all. To address such an audience, Microsoft would have needed to include extensive materials that can easily be found in public sources, including the MSDN and Microsoft TechNet, both of which are readily available on the global Internet, and various texts and treatises.120 182. Moreover, Microsoft would have needed to explain public standards with which knowledgeable engineers would already be familiar, and it would have had to offer tutorials on programming concepts and methods that engineers with the proper background would already know. The result would have been massive and verbose documentation that would have 116

Id. Id. 118 Sun Response, Response 2 item 3. 119 WSPP 3-Day Evaluation Technical Report prepared by Ronald S. Alepin dated 11 October 2005 (“Oracle Response”), p. 4 n.2. 120 Broy Report, including p. 3 & §§ 1.3.3 & 1.4. 117

- 52 impaired the ability of engineers skilled in the relevant art to find the information they actually needed. By not needlessly reproducing information an appropriately skilled and knowledgeable engineer would know or be able to determine, and focusing on the information that would actually need to be gained from the documentation, Microsoft did exactly what good software engineering requires. 183. Annex 5, Report of Roy Hirst (“Hirst Report”), provides an example of how a licensee engineer could use the Technical Documentation together with the available engineering art, including public standard protocols, to understand the use of a field within the DRSBind packet in the Microsoft DRS RPC interface so as to be able to use the Technical Documentation in the development of a server operating system product. 184. As stated in Annex 6, Report of Jim Thatcher (“Thatcher Report”), Mr. Thatcher worked at Novell for five years (from 1995 to 2000) as a software engineer designing and developing directory services administrative tools for Novell network software and as a directory services architect on Novell’s Advanced Development Group. These are core areas of work group server functionality of the kind at issue in this case. In these roles, Mr. Thatcher developed the Software Development Kit (SDK) for Novell’s NetWare Administrator and other software for integrating products with the Novell directory service. After joining Microsoft in 2000, Mr. Thatcher managed the NetWare interoperability tools for Windows XP and Windows Server 2003.121 Mr. Thatcher therefore is uniquely qualified to describe industry practice relating to the development of the work group server functionalities at issue. 185. Mr. Thatcher reports that the development and documentation of Novell’s published Application Programming Interfaces and SDKs assumed that developers of products designed for integration with NetWare already understood NetWare network administration and distributed network directory services, had used NetWare, were familiar with Novell Directory Service (“NDS”) administration using Novell’s NetWare Administrator or ConsoleOne, and understood concepts such as network authentication, the hierarchical data structure used in NDS, access rights based on user authentication, and fundamental directory object types in NDS. Developers who lacked such understanding were expected to turn to available materials external

121

Thatcher Report ¶¶ 2-7.

- 53 to particular product specifications to acquire understanding of these matters necessary to perform their responsibilities.122 186. Mr. Thatcher further states, based on in his experience at Novell: “Similarly, Novell developers who were building software to integrate Windowsbased computer systems into Novell networks invested significant effort in understanding Windows programming, security, and networking. Novell purchased Microsoft Developer Network (MSDN) subscriptions, acquired books on Windows programming, and sent several developers to Microsoft’s Professional Developer’s Conference each year to learn about and stay current on Windows technology and the Microsoft programming environment.”123 187. As Mr. Thatcher’s experience makes clear, Novell certainly did not expect developers with no “prior knowledge” of the Novell environment to attempt to develop software that would interoperate with Novell server software, and Novell certainly did not expect developers with no “prior knowledge” of the Microsoft environment to attempt to develop software that would interoperate with Microsoft server software. Nor, as the Finkelstein and Broy Reports make clear, would any other company realistically attempt to do so. 188. As the expert reports also show, Microsoft’s practice of working diligently to determine how the Technical Documentation can be improved and issuing enhanced releases to achieve such improvements, and its offering of live technical support from knowledgeable developers who can address issues that actually arise in the use of the documentation, also conform to standard industry practice and provide the standard mechanism for dealing with problems of the kind that have been asserted in the criticisms of the Technical Documentation. 189. The 2004 Decision explicitly recognizes that software development is inherently an iterative process. The 2004 Decision states: “Commercial implementations are specific to a given software environment and optimised and tuned for performance. Furthermore, the development of a commercial product involves testing it and correcting possible ‘bugs’, that is to say, mistakes in the source code. Most such bugs are only discovered after intensive testing in a variety of possible configurations. In addition to the testing that they carry out internally, most software vendors take advantage of the feedback provided by potential customers or partners, who get access to a 122 123

Thatcher Report ¶¶ 8-9. Thatcher Report ¶ 10.

- 54 pre-release called a ‘beta test version’ and report on potential bugs. In spite of all those efforts, many bugs are often corrected after the official ‘release to market’, either by means of software add-ons, or fixes called ‘patches’ or in future commercial releases.”124 190. Strangely, however, even though the 2004 Decision expressly acknowledges these facts about the software development process, the Statement of Objections completely ignores the applicability of the same principles to the software documentation process, despite a clear exposition of this applicability in one of the very textbooks that the Article 24(1) Decision itself cites. That Decision cites a textbook by Carlo Ghezzi et al., Fundamentals of Software Engineering (2003).125 In a passage that the Article 24(1) Decision does not cite or acknowledge, the Ghezzi textbook explicitly recognizes that the specification process, like the software development process, is inherently iterative. The textbook states: “Specifications themselves are the result of a complex and creative design activity; they are subject to errors just as are the products of other activities, such as coding.”126 As a result, design principles that include “incrementality,” which apply to coding, also apply to the process of developing specifications.127 “Incrementality characterizes a process that proceeds in a stepwise fashion, in increments. We try to achieve the desired goal by successively closer approximations to it. Each approximation is an increment over the previous one.”128 Indeed, because of the recognized “difficulties in achieving complete, precise, and unambiguous specifications, the use of the incrementality principle is especially important in deriving specifications.”129 191. Despite having acknowledged the incrementality principle in software development, and despite ostensibly taking into account the Ghezzi textbook, the Commission fails to recognize what the Ghezzi textbook calls the “especially important” applicability of the incrementality principle to the process of deriving specifications. As the Broy Report explains, however, it is absolutely common practice that specification documents of the kind involved here are improved iteratively while being used in a dialogue between users and documenters. Microsoft’s offer of 124

2004 Decision, ¶ 25. Article 24(1) Decision ¶ 64 n.66. 126 Carlo Ghezzi, Mehdi Jazayeri and Dino Mandrioli, Fundamentals of Software Engineering p. 162 (2d ed. 2003). 127 Id. pp. 53, 162. 128 Id. p. 53 (emphasis in original). 129 Id. p. 167 (emphasis in original). 125

- 55 500 hours of free technical assistance is standard industrial practice and “the appropriate way to close unavoidable gaps, errors and misconceptions.”130 192. Microsoft’s competitor critics have also ignored offers of technical assistance. The report prepared by Ronald S. Alepin for Oracle expressly acknowledges that Microsoft “volunteered to have us meet with developers if we had specific questions during our evaluation,” that the reviewers “had only a few, narrow issues that required interaction with other parts of Microsoft,” and that “[t]his offer of assistance was helpful, but, in truth we did not put it through its paces.”131 193. As put even more simply in the Finkelstein Report: “It is well known that no developer is ever wholly satisfied with the documentation they receive. There are matters of interpretation, understanding and straight out bugs. For this reason all significant bodies of interoperability information are provided in the context of an offer of help and assistance.”132 If readers of the documentation identify alleged issues but choose not to take advantage of such an offer of help and assistance, the best inference is that they are interested not in using the documentation but in condemning it. C. The Remaining Criticisms By the Trustee And Others Are Also Mistaken, Outdated, Or Solvable By A Normal Industry Practice Of Continued Interaction With Microsoft 194. The Trustee’s 30 November 2005 Report notes that it was based on a review of “around 10 working days,”133 and the 15 December 2005 Report was issued around 10 working days later. Clearly, the Commission’s rush to issue the 21 December 2005 Statement of Objections, without even reading the version of the Technical Documentation that was made available by Microsoft on 15 December or asking the Trustee to review it, meant that the Trustee’s criticisms were based on a very limited review. The Trustee’s criticisms all must be viewed in this light. 195. A striking example of the Trustee’s inability to conduct a thorough analysis under these circumstances is the Trustee’s so-called “sufficiency test,” on which the Trustee heavily relies for his conclusions. In this asserted test of the sufficiency of the Technical Documentation, the 130

Broy Report § 1.4. Oracle Response pp. 5-6. 132 Finkelstein Report ¶ 5.3. 133 Trustee’s 1st Report p. 2. 131

- 56 Trustee attempted “to specify the design of programs intended to implement” the functionality of “adding a new user.”134 196. According to the Trustee, his “unsuccessful work” on this effort took the following time: •

12 hours on 8 December;

•

10 hours on 10 December;

•

8 hours on 11 December; and

•

12 hours on 13 December.135

Based on his inability, in only 42 hours, to design an implementation of the add user functionality for a server operating system that would be “capable of providing the equivalent functionality as a Windows server to the Windows clients and/or the other Windows servers which might form a part of an organisation’s network,” the Trustee concluded that the Technical Documentation had “failed” the sufficiency test.136 197. The Trustee’s Second Report asserts that “to receive and process a request to add a new user” is “one of the simplest possible operations in a distributed system environment.”137 As the Finkelstein Report explains, this assertion is a major error: “Any consideration of the sufficiency test must . . . be immediately prefaced by a fundamental reservation. . . . . The test may at first blush seem simple because client-side ‘add-user’ is indeed very straightforward; just use the LDAP (Lightweight Directory Access Protocol, an IETF standard) interfaces or the many other routes to solving the same problem. But this reflects a misunderstanding of the selected test, and our view speaks directly to the contrary; the test chosen is one of the most difficult that could have been selected.”138 134

Trustee’s Second Report dated 15 December 2005 (“Trustee’s 2d Report”) p. 6. Trustee’s 2d Report transmittal letter p. 2. 136 Trustee’s 2d Report transmittal letter p. 1. The Trustee identified a second possible element of the sufficiency test “to develop the necessary functions to propagate a password change throughout a network by means of the replication services” but apparently did not finish the effort. Id. As the Finkelstein Report states: “There is inadequate information provided in the document of 17th January 2006 for us to comment on the second sufficiency test . . . . No evidence is presented [by the Trustee] in respect to this test and thus it is difficult for us attach any credence to the Trustee’s conclusion that it can be ‘said equally to have failed.’” Finkelstein Report ¶ 12.3. 137 Trustee’s 2d Report p. 6. 138 Finkelstein Report ¶ 12.2. 135

- 57 198. The fundamental concepts of distributed system security and access “rest on users being correctly added to the system.”139 As explained by Professor Broy, although “add new user” might seem at first glance to be simple, it becomes evident that the opposite is true when one takes into account the manner in which Active Directory (the Microsoft directory that stores user information) acts a system and all the subsystems that are involved in the add new user task. These functions not only interact with the client in accepting the add new user request, but store the information in Active Directory and replicate the new data to other Active Directory domain controllers. The task thus implicates fundamental Windows server functionality.140 199. As further stated in the Broy Report: “Trying to do an experiment on a system and a specification of the size of a server by trying to implement a particular function, which in addition requires substantial functionality, on which it is based, is not trivial. To carry out such an attempt without solid background within a few days is again quite impossible and frankly speaking naive.”141 200. Appendix B to the Finkelstein Report examines the Trustee’s sufficiency test in detail and exposes multiple “basic misunderstandings that account in full for the difficulties that the Trustee encountered.”142 As just one example, the Technical Documentation uses the software engineering term “context handle,” but the Trustee states that he has “no idea what a ‘context handle’ might be” and even says, “I have no way of knowing.”143 But it is simply not true that the Trustee has “no way of knowing” what a “context handle” is. As explained in Appendix B to the Finkelstein report, “context handle” is clearly defined in “a public, well-known document”144 which is “referenced frequently” in the Technical Documentation (for example, at pages 9820, 9828, 9841, 9870, and 9910).145 Indeed, an “RPC context handle is a standard, well-known programming construct.”146 Moreover, the Trustee had many other “way[s] of knowing” what a context handle is; for example, when Professor Finkelstein checked Google, the very first hit for 139

Id. Broy Report § 4.2. 141 Id. 142 Finkelstein Report ¶ 12.4. 143 Trustee’s 2d Report p. 3. 144 Finkelstein Report App. B2. The document is Open Groups Distributed Computing Environment Version 1.1 Remote Procedure Call. 145 Id. The document is referenced in the Samr chapter of the Technical Documentation. 146 Finkelstein Report App. B3. 140

- 58 “context handle” provided the relevant definition.147 If the Trustee had “no idea what a ‘context handle’ might be,” it is not because he had “no way of knowing,” as he stated, but because he made no effort to find out. 201. As another example of the basic misunderstandings that account for the Trustee’s difficulties in the sufficiency test, the Trustee assumes that a specification for the structure SAMPR_HANDLE is needed, because it is “self-evidently a fundamental requirement given the operation of the ‘samr’ and related functions.” Appendix B to the Finkelstein Report explains: “This is a totally incorrect conclusion. A specification of the SAMPR_HANDLE is not necessary for any kind of communication or interoperability.”148 202. As yet another example of the basic misunderstandings that account for the Trustee’s difficulties in the sufficiency test, the Trustee states that he cannot use the file “ntstatus.h” in its printed form with the Technical Documentation and that there is “no explanation” where to find the file. As explained in the Finkelstein Report, this statement is simply wrong. Ntstatus.h is part of Microsoft SDKs (Software Development Kits) and is also available on other websites, and page 9108 of the Technical Documentation, a part of the General Information chapter, clearly explains where to obtain header files such as ntstatus.h.149 203. In addition to the serious errors described above, Appendix B to the Finkelstein Report provides numerous additional examples of basic misunderstandings that are more than sufficient to account for the Trustee’s difficulties in the sufficiency test. Moreover, both Professor Finkelstein150 and Professor Broy151 have identified promising potential approaches to the “add new user” task in the context of an actual implementation of a work group server operating system that the Trustee overlooked or ignored. In these circumstances, the claimed failure of the Trustee’s sufficiency test proves nothing about the Technical Documentation or its sufficiency.

147

Finkelstein Report App. B2. The definition is for a context handle in the Microsoft Interface Definition Language, which is part of Microsoft RPC. 148 Finkelstein Report App. B3. See id. for a detailed description why the Trustee’s conclusion in this regard is plainly erroneous. 149 Finkelstein Report App. B6. 150 Finkelstein Report App. C. 151 Broy Report § 4.2.

- 59 204. Annex 7, Microsoft Responses to Documentation Criticisms (“Microsoft Responses to Criticisms”), provides more detailed responses to additional criticisms of the Technical Documentation by the Trustee and others. As set forth in Annex 7, some of these additional criticisms, like the complaint that a technical documentation set in excess of 12,000 pages contains a few typographical errors, are trivial, and some, like the OTR comments on usability, are based on the preliminary version provided in 2004 and do not reflect either the November 2005 enhancements or the 15 December 2005 version.152 Others are simply mistaken. 205. For example, the Trustee’s claim that “examples and example-based explanations are virtually absent from the Technical Documentation”153 is not only unsubstantiated but demonstrably incorrect. Indeed, the Trustee explicitly acknowledges that the documentation contains “code presented as an example.”154 The Technical Documentation shows examples of major packet and data structures, using either MIDL or C++ source examples. The examples occur in the Technical Documentation topics where the packet and data structures are defined. They are not at all absent. 206. Complaining that the Technical Documentation does not contain enough graphical illustrations, the Trustee states: “Simple inspection of available textbooks covering many of the aspects of system operation and interoperation show that illustrations are widely used by technical authors to augment textual presentation.”155 This remark reflects a fundamental misconception. The 2004 Decision does not require that Microsoft write a textbook. As reflected in the Hirst Report, numerous textbooks that offer detailed background information on Windows server operating systems and the Microsoft network and programming environment are readily available.156 The Technical Documentation is designed to provide a reference to supplement the knowledge of engineers already skilled in the art of developing work group server operating systems. Although in fact Microsoft Press already makes available a number of

152

Although the Commission has asserted that the comments in the 28 September 2005 OTR comments are still valid because the Technical Documentation that Microsoft submitted in November was particularly addressed to the DRS, FRS and DFS protocols, in fact 19 out of the 52 WSPP protocols received documentation revisions between August and December 2005. 153 Trustee’s 1st Report p. 3. 154 Id. 155 Annex to letter of 16 December 2005 from Trustee to Cecilio Madero. 156 Hirst Report p. 2.

- 60 books (which the Trustee does not appear to have used), Microsoft is not obligated to create instructional textbooks for engineers who lack this foundational knowledge and skill. 207. In claiming that the documentation “quite explicitly obfuscates some important details” by using “void pointers,”157 the Trustee completely misunderstands the role of void pointers in the Technical Documentation. As explained more fully in Annex 7, the Trustee recognizes that a void pointer is “used where the programmer wishes to hide detail of implementation of particular data structures,”158 but he errs in concluding from this that the documentation uses void pointers to withhold necessary information from licensees. On the contrary, the void pointer indicates that licensees are free to implement the relevant data structure entirely as they see fit and that the protocol imposes no restrictions on the format of the data structure.159 208. As Professor Finkelstein explains: “Abstraction and information hiding should not be confused with obfuscation. This confusion is however strongly evident in the Trustee’s reports. For example, one of the techniques used in WSPP implementation is stateless servers in which the server does not maintain information on the state of clients using the server. . . . This is a sound and well known distributed software engineering technique. It is therefore surprising that the Trustee refers to this as a serious problem with the specification. The same basic approach can be used to allow stateful servers in a session-less protocol. Instead of sending all client related information to server in every transaction the client sends this information once and receives a session handle from the server. . . . Much is made of the typedef void* SAMPR_HANDLE example that, in fact uses context handles. The void* type is good software engineering practice and means that the client does not depend on the server implementation. Context handles are also used in respect to binding information for remote procedure calls and their use is well documented in, among other places, MSDN.”160 209. The Trustee also complains that the Technical Documentation does not provide sufficient information on error handling.161 As discussed in more detail in Annex 7,162 this criticism reflects a misunderstanding of the proper relationship between error handling and protocol

157

Trustee’s 1st Report p. 3. Trustee’s 1st Report p. 3 n.1 (emphasis added). 159 See Annex 7 ¶¶ 25-29 for a more detailed explanation of void pointers and the Trustee’s misunderstanding of their use in the Technical Documentation. 160 Finkelstein Report ¶ 3.5. 161 Trustee’s 2d Report p. 5. 162 See Annex 7 ¶¶ 19-24. 158

- 61 execution. A protocol specification defines the errors that can be generated, but does not usually define how those errors should be handled. Rather, error handling is left to each individual implementation, and different implementations can handle errors in different ways without affecting the correctness of the protocol execution. A specification that required errors to be handled in a particular manner would unnecessarily (in most instances) limit the freedom of licensees to choose how they wanted to handle errors.163 210. The appropriateness of the approach to error handling taken by Microsoft in the Technical Documentation is actually confirmed by one of the very textbooks the Statement of Objections cites: Paul Clements et al., Documenting Software Architectures, 2003.164 Clements states: “Making a strong distinction between detecting an error condition and handling it provides greater flexibility in taking corrective action. The right place to fix a problem raised by a resource is usually the actor that invoked it, not in the resource itself. The resource detects the problem; the actor handles it.”165 In this case, the “resource” is a Windows client or server and the “actor” is a licensee implementation. Although the Windows system reports errors as defined in the protocol, the licensee implementation remains free to handle the error as it sees fit. The omission of an error handling requirement in the protocols, far from constituting a deficiency, avoids imposing needless constraints on error handling by licensee implementations. 211. The Trustee’s other criticisms relating to error handling are equally groundless. For example, the Trustee expresses frustration with the large size of the file that lists possible

163

Annex 7 ¶ 24. In those few situations in which the protocol does dictate that errors be handled in a particular manner and this error handling is non-obvious, error handling information is described in the documentation. For an example of a protocol that does incorporate error handling information, see the topic “Microsoft Distributed File System Protocol\DFS.” 164 SO ¶ 53 n.48 (citing “Paul Clements, Felix Bachman, Len Bass, David Garlan, James Ivers, Reed Little, Robert Nord and Judith Stafford, Documenting Software Architecture [sic], 2005 [sic]”). The correct title of the book is Documenting Software Architectures: Views and Beyond (hereinafter referred to as “Documenting Software Architectures”), and the correct date of the book is not 2005, as stated by the Commission, but 2003 (with actual publication on 26 September 2002), according to the description on the website of the book’s publisher, Addison Wesley, at http://www.aw-bc.com/catalog/academic/product/0,1144,0201703726,00.html. Neither the publisher’s website nor Amazon.com says anything about a 2005 edition of this book. 165 Paul Clements et al., Documenting Software Architectures p. 234 (2003).

- 62 Windows error codes.166 The fact is that these error codes are available to a Windows system and could be returned by a Windows system. Licensees would know that, after providing for errors most relevant to a protocol, they can handle remaining errors through a default mechanism.167 212. Finally, the Statement of Objections alleges that protocols for Microsoft’s yet-to-bereleased Windows Vista operating system are “generally missing” from the documentation.168 As stated in Annex 7, new protocols that were implemented as of Windows Vista Beta 1 have been documented. After the Beta 2 source code is frozen and stabilized, which has not yet happened, the Beta 2 protocol additions will also be documented.169 The Statement of Objections simply assumes that something is missing, with no evidence and no basis in fact. VIII. MICROSOFT CANNOT BE FINED FOR COMPLYING WITH ARTICLE 5 IN A MANNER CONSISTENT WITH SOFTWARE INDUSTRY PRACTICES 213. Microsoft has complied with Article 5 of the 2004 Decision by providing thorough and sound documentation that provides the scope of Technical Documentation the Commission has requested, and by devoting considerable resources to respond to suggestions for improved usability that have been made. Equally important, it has offered, time after time,170 to cooperate with licensees (and the Trustee) by providing assistance in understanding and working with the documentation. 214. As discussed in the previous section, the independent experts Microsoft has retained have explained that this is the normal industry practice for licensing complex technology; to wit, providing usable documentation addressed to engineers skilled in the relevant art and working with licensees on an ongoing interactive basis to resolve difficulties. 215. This is the approach that has been followed, and found constructive by all parties, in the MCPP program created under the U.S. settlement, with demonstrable success: over 25 licensees have signed up to take advantage of the Microsoft specifications – many of them the same 166

Annex to letter of 16 December 2005 from Trustee to Cecilio Madero. Annex 7 ¶ 24. 168 SO ¶ 66. 169 Annex 7 ¶ 51. 170 See, e.g., letter of 8 July 2005 from Jean-Yves Art to Angel Tradacete; letter of 15 December 2005 from Steven Ballmer to Commissioner Neelie Kroes 167

- 63 protocols to be licensed under the WSPP program here – and are making successful use of the documentation and associated intellectual property rights.171 The 2004 Decision indeed cites the U.S. MCPP program as providing a reference point for the sort of specifications required by the Decision.172 Microsoft has also successfully licensed complex technology in private transactions, following the same industry practice of providing extensive documentation and assisting licensees on an ongoing basis.173 216. The Statement of Objections attempts to impose an entirely different approach to compliance. Ignoring Microsoft’s repeated offers to help the licensees (and the Trustee) work successfully with the Technical Documentation, the Statement of Objections asserts that a sizable daily penalty should be imposed on Microsoft because it has not provided Technical Documentation that is letter perfect and transparently clear to the Trustee on a first reading and, and which would allow the Trustee with a few days’ effort to implement a part of the Technical Documentation. (A “test” implementation which, as Microsoft’s experts have pointed out, could not realistically be carried out in isolation from the overall project, and certainly not in a matter of a few days, even by a software engineer with extensive experience in this specific area, such as would be assigned to the project by any licensee making a serious effort to take advantage of the Technical Documentation.) 217. The Statement of Objections is demanding for compliance a perfect user’s manual for an extremely complex undertaking, one that can be provided on a standalone basis and successfully (and virtually instantaneously) used by recipients, without the recipients ever having a question that could be answered by Microsoft or making any use of the extensive, readily-available public resources that are commonly used by hundreds and probably thousands of engineers in the industry, and without the discovery of possible errors that could similarly be resolved by simply calling the issue to Microsoft’s attention for correction or clarification. 218. The Statement of Objections also insists that this user’s manual should be written for an audience with no “prior knowledge” of software development for network operating systems of the Microsoft programming environment. The Commission, however, provides no explanation why such a standard is required, very much in the same way that the Trustee simply “assumes” 171

See MCPP & Private Licensing Report. 2004 Decision ¶ 571. 173 See MCPP & Private Licensing Report. 172

- 64 that the documentation should be “free standing” without explaining on what basis this assumption is made. This total lack of explanation is easily explained by the fact that, as Microsoft’s experts have explained, any licensee wishing to embark upon such a project would, as a matter of industry practice and simple common sense, assign software engineers to the task who did have these essential skills, and who would be frustrated by being asked to use documentation that was needlessly bloated by the inclusion of lengthy explanations of matters wholly obvious to them. 219. There is no lawful basis for the Commission to impose a particular method of compliance, particularly a method that departs so radically from normal industry practice. 220. Article 5(a) of the 2004 Decision requires Microsoft to make “Interoperability Information available to any undertaking having an interest in developing and distributing work group server operating system products.” Neither the 2004 Decision nor any principle of Community law requires Microsoft to make the required Technical Documentation available in any particular manner. Microsoft has chosen, and carried out in a thorough and responsible way, to accomplish the technology licensing program required by following established industry practice. It has provided extremely extensive documentation of more than 12,000 pages, and voluntarily offered ongoing assistance. As described in the next section, Microsoft has more recently taken the final step of offering to license relevant Windows source code. 221. The Statement of Objections offers no explanation or reasoning why that approach should be rejected out of hand, and none exists. IX.

MICROSOFT HAS FURTHER CONFIRMED ITS COMMITMENT TO COMPLIANCE WITH ARTICLE 5 OF THE 2004 DECISION BY OFFERING TO LICENSE WINDOWS SOURCE CODE AND EXTENDING OTHER IMPORTANT ADDITIONAL ASSISTANCE TO LICENSEES

222. Microsoft had complied with Article 5 of the 2004 Decision by the time of the 15 December 2005 deadline set by the Article 24(1) Decision, and remedied any legitimate deficiencies identified by that decision. In addition to all it had done before, Microsoft had supplied additional Technical Documentation in November 2005 to address the Commission’s demand for a broader scope of documentation, and had made additional documentation available on 15 December 2005 to address asserted usability issues. This was all done with close and repeated consultation with the Commission to try to identify the Commission’s specific standards

- 65 for compliance and to discuss what Microsoft would be doing (and did) to address these concerns, as discussed in previous sections. 223. Microsoft was therefore surprised when the Commission issued the Statement of Objections on 21 December 2005. Its astonishment was the greater upon reading the Statement of Objections, which revealed that neither the Commission nor the Trustee had even paused to review Microsoft’s 15 December 2005 documentation in rushing to issue the Statement of Objections. Microsoft was also dismayed that the Statement of Objections allowed Microsoft only five weeks to respond despite the fact that eight weeks is the virtually standard time set for responses to Statements of Objection, in cases which typically are much less complicated than this proceeding, and despite the Christmas holidays. 224. Furthermore, when Microsoft submitted a request for an extension of time to 28 February 2006 in a letter that set forth in detail the reasons why, among other factors, Microsoft’s newlyretained outside experts needed that time to review the documentation and prepare their reports,174 Microsoft was given only until 15 February 2006, two weeks less than requested.175 The Hearing Officer’s letter rejecting the requested extension began by stating that Microsoft had received an initial delivery of part of the record before the Commission on 23 December 2005 (after business hours) and was thereby “put in a position to begin the preparation of their reply” then - that is, on Christmas Eve, while the Commission’s offices were closed from 24 December 2005 to 3 January 2006. The Hearing Officer’s rejection letter then proceeded to the extraordinary proposition that Microsoft’s request asked for too much time because its experts did not need “to analyze the 12,000 pages of documentation provided by Microsoft” despite the clear fact that the very core of the Statement of Objections is the Commission’s assertion that this documentation is incomplete and unusable. 225. These events, together with those of the previous months, made Microsoft more than fearful that the Commission is not interested in Microsoft’s compliance, but rather in painting a false picture of Microsoft as a renegade that refuses to comply. Microsoft concluded that even stronger measures were necessary to demonstrate its total dedication to compliance to the Commission and, if necessary, to reviewing courts. 174 175

Letter of 17 January 2006 from Ian S. Forrester to DG Competition Hearing Officer. Letter of 23 January 2006 from DG Competition Hearing Officer to Ian S. Forrester.

- 66 226. On 25 January 2006 Microsoft therefore took the unprecedented step of voluntarily offering to license the actual Windows source code for the communications protocols covered by the 2004 Decision for licensees to use as a reference in assisting them to develop their own implementations. This source code is the ultimate and decisive disclosure of the relevant technologies for the Windows server operating systems. Indeed, it is the actual embodiment of those technologies, and therefore constitutes some of Microsoft’s most valuable intellectual property. On 30 January, Microsoft met with the Commission staff and the Trustee to discuss the proposed terms of the source code license, and on 31 January Microsoft provided the Trustee with a demonstration of how developers would use the licensed source code. In addition, on 8 February, Microsoft provided further information regarding the source code license program to the Commission, and confirmed to the Commission that the draft agreement which had been provided the previous week for the source code license could be shared under confidentiality with potential licensees. 227. The specifications that Microsoft has previously supplied containing more than 12,000 pages are more than sufficient to comply with the requirement set forth in Article 5 of the 2004 Decision for Interoperability Information in the form of specifications for communications protocols “used by Windows Work Group Servers to deliver file and print services and group and user administration services,”176 and also to address the Commission’s demands for documentation of the internal architecture and operation of Windows to allow competitors to develop replacement operating systems for Windows work group server operating systems that can work within the Windows domain architecture. 228. Specifications are by nature an attempt to describe the computer programs that constitute these communication protocols and technologies. The task of describing the precise and complex mathematical operations represented by a computer program is inevitably difficult to perform with perfect results. Such descriptions are sometimes unclear, often lack the precision of mathematical operations, and may be understood differently by different readers. These difficulties are much greater when enormously complex programs such as Windows are

176

2004 Decision, Article 1(1), Article 5(a).

- 67 involved. The 2004 Decision notes that the source code for Windows constitutes tens of millions of lines of code.177 229. The Windows source code is not a description of these protocols and technologies: it is the protocols and technologies, and therefore it unambiguously discloses those protocols and technologies. While the source code for Windows cannot be directly used as source code to be added to a licensee’s operating system, it provides valuable guidance for a licensee seeking to implement the functionality in question in its operating system. 230. In order to assist licensees in their use of the source code, Microsoft hereby confirms that it is undertaking a number of additional steps. These include the following, many of which result from feedback received from the Trustee or Commission staff during the meetings of 30-31 January: •

Microsoft is making available an extensive organizational hierarchy (like a table of contents), and powerful navigation and search tools for the source code.

•

The source code delivery is through a secure web site, so licensees may access the source code from their own development facilities.

•

The web site includes a set of “frequently asked questions” regarding the use of the source code, an online full day’s training that may be accessed as often as needed, and international telephone and email support, available 24 hours a day, seven days a week. None of this support will count against the 500 hours of free technical assistance offered to each licensee.

•

Microsoft will provide onsite training to licensees, led by persons skilled in the source code delivery program. These training opportunities for effective use of the source code similarly will not count against the 500 hours of free technical assistance which are offered in support of the Technical Documentation.

•

Microsoft is providing a license of the intellectual property rights needed make effective use of the source code. These rights go beyond those found in typical reference licenses used in the software industry.

177

2004 Decision ¶ 335 & n.423 (citing testimony in a U.S. proceeding that the Windows source code contains at least 38 million lines of code).

- 68 231. Microsoft took the extraordinary step of volunteering to license the relevant source code of Windows because it wanted to demonstrate its commitment to compliance with Article 5 of the 2004 Decision. 232. Microsoft is not offering to license this valuable source code as a substitute for the Technical Documentation it has already offered to licensees. The source code is offered in addition to this extensive documentation of protocol specifications and additional Windows technologies. 233. Microsoft is also not asking licensees to make any additional payments for this source code. The source code license is being offered to licensees as a free addition to any royaltybearing license covering trade secrets under the WSPP program. 234. As additional steps to demonstrate its commitment to compliance, Microsoft has also announced several other actions to help licensees make effective use of the source code and the Technical Documentation already being offered. In addition to the previously offered 500 hours of free technical assistance for each licensee, 178 Microsoft is committed to taking other steps as well, including any reasonable steps suggested by the Trustee or Commission staff. For example: •

Microsoft will offer additional tools to aid a licensee to test and debug its protocol implementations.

•

Microsoft will supply licensees with free copies of existing Microsoft manuals on its server software.

•

Microsoft will continue to improve the Technical Documentation, working with the Trustee, the Commission, and licensees. If needed and helpful, Microsoft will expand the resources that are devoted to this effort.

235. Microsoft will also engage a third-party firm that specializes in technical documentation, at Microsoft’s expense, if the Commission determines that it would be constructive to engage such a firm to make additional improvements to the documentation Microsoft has provided. In any event, Microsoft will also continue to increase its own internal resources in order to continuously improve the documentation, whether based on suggestions of a third party firm, its own continual 178

Letter of 15 December 2005 from Steven Ballmer to Commissioner Neelie Kroes.

- 69 review, the review of the Trustee and/or the review of potential licensees. Microsoft fully expects that the documentation, and the tools which support its usability, will continue to evolve, just as they do in commercial settings, whether from the evolution of the technology which they document and support, or the experience of users and testers . 236. The importance and value of the Windows source code in understanding and implementing the communications protocols and other technologies covered by the 2004 Decision and the Commission’s demands cannot reasonably be doubted. 237. The Commission itself has recognized this by asserting in the 2004 Decision that “the accuracy and completeness of the specifications to be disclosed can only be ascertained on a case-by-case basis and by having the possibility to interrogate Microsoft’s source code,”179 and stating that “the Monitoring Trustee should have full access to the source code of the relevant Microsoft products (any controversy as to the accuracy and completeness of the specifications that will be disclosed can only be resolved if the technical information is checked against the actual source code of Microsoft’s products).”180 238. As additional evidence of the value of source code, Microsoft like many other software companies, increasingly has made certain source code available to improve interoperability and enhance innovation, and has extended access to portions of source code for a variety of Microsoft technologies to selected governments, large enterprises and key partners though the Shared Source Initiative. This is the first time however that Microsoft has licensed its Windows source code to competitors. In order to ensure that the source code may be used by WSPP licensees without undue fear of infringing Microsoft’s intellectual property rights, Microsoft provides not only the industry standard “reference license” but also additional license grants for trade secrets, copyrights and patents, which are needed in order to enable licensees to use those rights disclosed by their review of the source code in order to implement the protocols for interoperability purposes.

179

2004 Decision ¶ 1043. 2004 Decision ¶ 1048(iv). Articles 3.2 and 4.2 of the Commission’s decision on the monitoring trustee accordingly require Microsoft to make its source code available to the Trustee. See Commission Decision of 28 July 2005 relating to a proceeding under Article 82 of the EC Treaty (Case COMP/C-3/37.792 Microsoft), C(2005) 2988 final. 180

- 70 239. The value of source code in developing software products that can interoperate with Windows has also been emphasized in the U.S. Microsoft proceedings, where in determining the final remedy, witnesses testified that source code is “invaluable” or “critical” in achieving interoperability.181 240. Microsoft’s voluntary offer to license source code goes beyond the requirements of the 2004 Decision, since the Decision states that it “does not contemplate the compulsory disclosure of source code as this is not necessary to achieve the development of interoperable products.”182 Even if access to source code is not necessary to achieve interoperability, however, the Commission cannot plausibly argue that source code is not a valuable aid to achieving interoperability, in view of the Commission’s insistence upon its availability as part of the enforcement mechanism, as well as the other evidence discussed above. 241. This is particularly so because the Windows source code was at all relevant times the only embodiment of the server-to-server protocols Microsoft is accused of abusing a dominant position by refusing to supply. Microsoft has repeatedly emphasized that there were no “specifications” describing its server-to-server protocols until Microsoft prepared specifications after the March 2004 Decision directed it to do so. The Commission has never challenged that fact, nor could it. 242. In all previous cases where an assertedly dominant firm was accused of refusing to make a product or property right available to other firms, the alleged refusal to supply was a refusal to

181

United States of America v. Microsoft Corp. (Civil No. 98-1232) (CKK) and State of New York, et al. v. Microsoft Corp. (Civil No. 98-1233) (CKK), testimony of Jonathan Schwartz, Sun Microsystems, Inc. p. 49; testimony of Professor Andrew Appel of Princeton University p.34; testimony of Michael Tiemann, Redhat, Inc. p. 77. 182 2004 Decision ¶ 1004. The Decision seems to have decided to refrain from ordering the compulsory licensing of source code partly in order to argue that competitors would not be able to “clone” Microsoft’s Windows work group server operating systems since they would not have the Windows source code and would need to write their own source, 2004 Decision ¶ 714, and partly in order to be able to argue that Microsoft was not being forced to disclose what the Commission attempts to argue is the only potentially innovative part of a software program, its actual implementation in source code, cf. 2004 Decision ¶ 740. Both arguments are wrong, as Microsoft has shown in other filings.

- 71 supply or allow the use of an existing product or property right.183 It is, indeed, difficult to see how there can be a refusal to supply that which does not exist.184 243. The source code Microsoft has offered to license as a supplement to the massive written documentation it has already provided, together with Microsoft’s repeated and now expanded offers to provide assistance to licensees in achieving interoperability solutions, should conclusively demonstrate that Microsoft is committed to compliance, and has complied with Article 5 of the 2004 Decision. X.

IMPOSITION OF ANY PENALTY WOULD BE UNLAWFUL AND UNFAIR A. The Statement Of Objections Fails To Recognize The Complexity Of The Compliance Issue In This Proceeding

244. This case is not the typical Article 24 case because the issue of compliance is unavoidably complicated and requires subjective assessment by experts. In the typical case, compliance is easy to assess and the Commission can usually determine whether the addressee of the Article 24 decision has complied with its obligations almost immediately upon the expiration of the deadline. Whether or not the addressee gave the Commission access to its premises to allow it to

183

See, e.g., Case C-418/01 IMS Health and NDC Health, judgment of 29 April 2004, not yet reported, ¶ 4 (copyright for particular map dividing Germany into zones based on postcodes); Case C-241/91 RTE and ITP v Commission [1995] ECR I-743, ¶ 47 (information relating to television programming); Case C-7/97 Bronner v. Mediaprint [1998] ECR I-7791) , ¶ 7 (nationwide newspaper home delivery system). 184

The 2004 Decision attempts to justify an order to supply “specifications” for a withheld product by pointing out that in the Tetra Pak II tying case, the Commission remedy included a requirement that Tetra Pak provide “specifications” for packaging cartons to be used by its machines, in order to prevent Tetra Pak from being able to achieve a tie by indirect means. 2004 Decision ¶ 742 & n.893, citing Commission Decision 92/163/EEC, Article 3(5), and Judgment of the Court of First Instance in Tetra Pak II, ¶ 139. But even assuming the dubious relevance of this tying case, there was no assertion in Tetra Pak II that such specifications did not exist, nor would any such assertion have been plausible. The 2004 Decision also discusses the IBM Undertaking to supply interoperability information relating to its mainframe computers. 2004 Decision ¶¶ 736-741. But that was a voluntary undertaking to induce the Commission to suspend a pending investigation, and IBM’s undertaking to supply such information was made to avoid the need to disclose source code or any information about the internal operation of its products, a distinction between “interface information and internal product design (in this case, the source code of Windows)” which the Decision states “also informs the Commission’s approach in this case.” 2004 Decision ¶ 736 nn.883, 886, ¶ 740.

- 72 carry out an inspection,185 supplied a chemical to a competitor,186 replied to a request for information,187 or granted a license to a copyright for a map188 can generally be determined quickly and easily. In contrast, determining whether or not Microsoft has supplied complete and accurate Interoperability Information in accordance with its obligations under the 2004 Decision is an evaluation that requires careful study and therefore takes time, and that must take into account the industry standards on how such information is provided. 245. The Statement of Objections ignores the fact that the compliance issue in this case is unusual, and that Article 24 cannot be applied in the same way as in the more typical case. First, careful study, and therefore an appropriate amount of time devoted to examining documentation supplied, is needed to judge whether Microsoft has complied with its obligations under the Commission’s 2004 Decision. It could not be immediately apparent to the Commission upon the expiration of the 15 December 2005 deadline set forth in the Article 24(1) Decision whether or not Microsoft had complied because the Commission could not have reviewed, and did not review, the information supplied by Microsoft on 15 December2005. Nor did the Commission conduct an adequate review of the documentation submitted in November, as reflected in the Commission’s clearly false claim that the November documentation was limited to “on-the-wire” information. Second, evaluating compliance in this case requires recognition of the fact that licensing complex technology through the provision of documentation is an iterative process that is never 100% complete because there are always improvements that can be made to specifications, questions to be answered, and clarifications that can be provided. The Statement of Objections fails to take into account how comparable documentation is provided to licensees in the software industry. Rather, the Statement of Objections demands a standard of immediate perfection and unchallengeable clarity in every particular of the many thousand pages of documentation provided by Microsoft. The imposition of a penalty in these circumstances would be both unlawful and unfair.

185

See Hoechst v. Commission, [1989] ECR 2859. See Commercial Solvents, J.O. (1972) L299/51. 187 See Baccarat, OJ (1991) L97/16. 188 See NDC/IMS Health, OJ (2002) L59/18. 186

- 73 B. The Commission Has Failed to Meet Its Burden Of Showing Microsoft Has Failed To Comply 246. The imposition of a daily fine on Microsoft would be unlawful because the Commission has failed to prove to the requisite legal standard that Microsoft has failed to comply with the obligations set forth in the 2004 Decision. As in any competition proceeding, the Commission bears the burden of proof of establishing the infringement.189 To discharge its burden of proof, the Commission must put forward “firm, precise and coherent” evidence of Microsoft’s failure to meet its obligations under Article 5 of the 2004 Decision.190 As with any evidentiary standard, the strictness of the standard depends in some part on the circumstances. In the context of a case such as this one where the Commission is threatening substantial fines, the standard of proof must be applied in a strict manner that reflects the quasi-criminal nature of the sanction being threatened.191

189

Regulation 1/2003, Art. 2. Ahlstrom Osakeyhtio and others v. Commission, [1993] ECR I-1307 at ¶ 127. While this standard has been expressed in slightly different ways in the case law, the differences are not material. See, e.g., CRAM and Rheinzink v. Commission, [1984] ECR 1679 at ¶ 20 (“sufficiently precise and coherent proof”); Volkswagen v. Commission, [2003] ECR I-9189 at ¶ 20 (“sufficiently precise and consistent evidence”); Mannesmannrohren-Werke v. Commission, Case T-44/00 (not yet reported) at ¶ 260 (“precise and consistent evidence”). 191 Acting as an Advocate General for the Court of First Instance in Rhone-Poulenc v. Commission, [1999] ECR II-867 at p. II-991, Judge Vesterdorf stated that “competition cases [involving the possibility of fines] are in reality of a penal nature, which naturally suggests that a high standard of proof is required.” In a similar vein, the European Court of Justice has found that Article 6(2) of the European Convention on Human Rights (“ECHR”), which sets forth various procedural guarantees applicable in criminal cases also applies in competition proceedings where there is a possibility of fines or periodic penalty payments, though the ECJ did not address the impact of this on the relevant standard of proof in competition cases. Montecatini v. Commission, [1999] ECR I-4539 at ¶¶ 175-76. In Napp Pharmaceutical Holdings Ltd. and Director General of Fair Trading, Case No. 1001/01, [2002] Comp AR 13, the UK Competition Appeal Tribunal also concluded that Article 6(2) of the ECHR applies to competition cases and, as a result, the civil standard of proof applied in these cases should be applied in a manner akin to the criminal standard of beyond a reasonable doubt. More specifically, the Tribunal held that a civil standard should apply to competition cases, but that “within the civil standard … the more serious allegation, the more cogent should be the evidence before the court concludes that the allegation is established on the preponderance of probability.” Id. at para. 107. The Tribunal also noted that “whether we are, in technical terms, applying a civil standard on the basis of strong and convincing evidence, or a criminal standard of beyond a reasonable doubt, we think in practice the result is likely to be the same.” Id. at para. 108. Finally, the Tribunal noted that “[w]e have no reason to suppose that the standard of proof we 190

- 74 247. Regardless of the precise standard of proof that is applied in this case, the Statement of Objections does not come close to meeting it. As documented in detail in this Response and the accompanying annexes, Microsoft has fulfilled its obligations under Article 5(a) and (c) of the 2004 Decision and, therefore, has fulfilled the conditions set forth in the Article 24(1) Decision. Microsoft has provided complete and accurate Interoperability Information as required under the 2004 Decision and has offered technical assistance as a complement to the Technical Documentation itself. Microsoft has supplied this information on an ongoing basis in an effort to meet the Commission’s ever-increasing demands for more information, and Microsoft’s most recent submission of 15 December 2005 was in accordance with the deadline set forth in the Article 24(1) Decision. 248. The Commission has failed to put forward evidence that the information supplied by Microsoft by the 15 December deadline failed to fulfill the requirements set forth in the 2004 Decision. Much of the evidence that the Commission has put forward in the Statement of Objections is based on earlier versions of the information supplied by Microsoft. Although reports based on information supplied prior to the deadline may provide useful context, they are irrelevant in determining whether the revised documentation supplied by Microsoft on 15 December met the requirements of the Article 24(1) Decision. 249. As a matter of law, not to mention logic and common sense, in order to determine whether the information supplied by Microsoft by the 15 December deadline fulfilled its obligations under the 2004 Decision, the information supplied by Microsoft as of the deadline would need to be reviewed. Neither the Commission nor the Trustee conducted such a review. 250. The lone piece of evidence cited by the Statement of Objections that is dated after 15 December, the Trustee’s 16 December letter responding to Microsoft’s comments on his 30 November preliminary report, does not establish that Microsoft failed to comply with the 2004 Decision because, by his own admission, the Trustee had not yet had a chance to review the additional information made available by Microsoft the previous day. Therefore, in his letter, the Trustee could only express doubt as to whether the additional information submitted by

propose to follow is any different from that followed in practice by the courts in Luxembourg.” Id. at para. 113.

- 75 Microsoft would be able to meet the concerns that he had expressed in earlier reports. More specifically, the Trustee stated in his letter: “It may well transpire that, when the ‘release of 15 December’ is communicated to me on or after 23rd December 2005, the usability concerns have indeed been addressed and resolved. I would not wish to prejudge the characteristics of a release not yet available to me for review. However, I am very concerned that my legitimate concerns regarding the technical content appear to have been dismissed. On that basis, I cannot bring myself to believe that the conclusion that the documentation set is insufficient will have been addressed.” 251. Apart from the fact that the Statement of Objections does not rely on any evidence other than this letter to show that the information made available by Microsoft as of the 15 December deadline was insufficient to meet its obligations under the Article 24(1) Decision, the predeadline evidence cited in the Statement of Objections in support of the allegations against Microsoft is insufficient to discharge the Commission’s evidentiary burden. In essence, the Statement of Objections relies on evidence that shows minor deficiencies in the Interoperability Information, but fails to overcome the plain fact that Microsoft has supplied Interoperability Information that is complete and accurate in accordance with industry standards. More specifically, the evidence that purports to show deficiencies in the information supplied by Microsoft fails to take into account industry standards, holding Microsoft to a standard that is impossible for any licensor to meet. 252. In summary, Microsoft respectfully submits that the Commission has not met the standard of proof required of it for the imposition of a fine under Article 24. First, it has submitted no evidence subsequent to Microsoft’s submission on the December 15 deadline that even purports to take this submission into account. Second, the evidence relied upon by the Statement of Objections falls well short of establishing that the information provided by Microsoft in accordance with the 15 December deadline fell short of the obligations set forth in the Article 24(1) Decision.