United States' Memorandum Regarding Modifications Contained in Second Revised Proposed Final Judgment

Wednesday, February 27, 2002
Document Type: 
Final Judgments + Proposed Final Judgments
This document is available in two formats: this web page (for browsing content) and PDF (comparable to original document formatting). To view the PDF you will need Acrobat Reader, which may be downloaded from the Adobe site.  For an official signed copy, please contact the Antitrust Documents Group.







Civil Action No. 98-1232 (CKK)
Next Court Deadline: March 6, 2002
Tunney Act Hearing


Plaintiff United States of America submits the following memorandum regarding modifications to the Revised Proposed Final Judgment ("RPFJ"). These modifications are reflected in the new, Second Revised Proposed Final Judgment ("SRPFJ"), which is being filed concurrently with this memorandum,(1) along with a new stipulation signed by representatives of the United States, the States of New York, Ohio, Illinois, Kentucky, Louisiana, Maryland, Michigan, North Carolina and Wisconsin (collectively the "Settling States") and Microsoft Corporation ("Microsoft").(2)


On November 6, 2001, the United States, the Settling States and Microsoft submitted the RPFJ to the Court. Pursuant to §§ 16(b) and (d) of the Tunney Act, 15 U.S.C. §§ 16(b)-(h), the United States received public comments submitted on the RPFJ between November 5, 2001, and January 28, 2002.(3) The United States received over 30,000 comments during that period, which it has reviewed and considered as required by 15 U.S.C. § 16(d). Concurrently with this Memorandum, the United States is filing the Response of the United States to Public Comments on the Revised Proposed Final Judgment and a Memorandum in Support of Entry of the Proposed Final Judgment. The United States will also file the public comments themselves (on CD-ROM only).


The Tunney Act contemplates that the United States should evaluate the public comments that it receives and, if appropriate, consider modifications of the proposed consent decree in response to the issues raised by those comments. See 15 U.S.C. § 16(b) and (d).(4) On a number of past occasions, the United States has modified proposed consent decrees as a result of public comments.(5) In response to the Court's Order dated January 30, 2002,(6) the parties reported in their Joint Status Report ("JSR") filed February 7, 2002, that they were "considering whether, in response to the public comments, to submit to the Court proposed modifications to the RPFJ." JSR at 7.

  1. In Response to Public Comments, the Parties Have Agreed on Certain Modifications to the Terms of the RPFJ

Having fully reviewed and considered all public comments it received regarding the RPFJ, the United States proposed several modifications to the RPFJ. Microsoft and the Settling States have agreed to the modifications that are reflected in the SRPFJ. While the United States believes that the RPFJ as originally filed with the Court effectively remedied the violations sustained by the Court of Appeals and would be in the public interest, it believes that the modifications contained in the SRPFJ effectively respond to specific concerns raised in the public comments and that entry of the SRPFJ is in the public interest.

Each modification clarifies the language of the RPFJ in provisions about which public commentors have indicated concerns regarding the precise meaning of the language. Each modification is an outgrowth of specific concerns raised in the public comments and does not fundamentally change the RPFJ. With one exception,(7) these modifications refine the language in the RPFJ, and are intended to clarify the parties' shared intentions in drafting the RPFJ. The following sections explain the modifications, as well as the rationale for making these refinements.

    1. Section III.D and Definition VI.A - API

Section III.D. requires the disclosure of APIs (application programming interfaces) and other documentation for the purpose of ensuring interoperability between competing middleware and Windows Operating System Products. At least one commentor noted that in the RPFJ, the definition of API (Definition VI.A) includes only Microsoft APIs, thus rendering the other definitions that use the term API in the context of Non-Microsoft software potentially meaningless. Specifically, the definitions of Non-Microsoft Middleware, Non-Microsoft Middleware Product and Operating System arguably fail to function as intended if the definition of APIs is limited solely to Microsoft APIs. This definition of API, as originally drafted, was intended to apply only to Section III.D, but this limitation was not reflected in the text of the RPFJ. To correct this problem, the original definition of API has, in the SRPFJ, been inserted directly into Section III.D, so that Section III.D of the SRPFJ now reads:

    Starting at the earlier of the release of Service Pack 1 for Windows XP or 12 months after the submission of this Final Judgment to the Court, Microsoft shall disclose to ISVs, IHVs, IAPs, ICPs, and OEMs, for the sole purpose of interoperating with a Windows Operating System Product, via the Microsoft Developer Network ("MSDN") or similar mechanisms, the APIs and related Documentation that are used by Microsoft Middleware to interoperate with a Windows Operating System Product. For purposes of this Section III.D, the term APIs means the interfaces, including any associated callback interfaces, that Microsoft Middleware running on a Windows Operating System Product uses to call upon that Windows Operating System Product in order to obtain any services from that Windows Operating System Product. In the case of a new major version of Microsoft Middleware, the disclosures required by this Section III.D shall occur no later than the last major beta test release of that Microsoft Middleware. In the case of a new version of a Windows Operating System Product, the obligations imposed by this Section III.D shall occur in a Timely Manner. (New language in bold).

A generic definition of API that is not tied to Microsoft products has been inserted as Definition VI.A to apply throughout the SRPFJ except in Section III.D:

    "API" means application programming interface, including any interface that Microsoft is obligated to disclose pursuant to III.D.

The meaning of API in the definitions of Non-Microsoft Middleware, Non-Microsoft Middleware Product and Operating System is now defined, as intended, according to this generic definition, thereby resolving any potential concerns regarding their reliance on a definition of API that is specifically tied to Microsoft products. The modification does not change Microsoft's obligations under Section III.D.

    1. Section III.E

Section III.E requires Microsoft to disclose all Communications Protocols that a Windows Operating System Product uses to interoperate natively with a Microsoft server operating system product. It ensures that non-Microsoft servers will be able to interoperate with a Windows Operating System Product using the same protocols the Microsoft server operating system product uses. Several commentors argued, however, that because the word "interoperate" in Section III.E is not defined, its meaning is unclear, potentially making it possible for Microsoft to evade this provision. The United States believes that, as interoperate is used in this Section III.E, its meaning clearly reflects the parties' intention that this provision presents the opportunity for seamless interoperability between Windows Operating System Products and non-Microsoft servers. Although the United States believes that the meaning of interoperate as included in Section III.E of the RPFJ is clear, in response to the public comments, the United States proposed, and Microsoft and the Settling States agreed, to supplement the term "interoperate" with "or communicate," so that Section III.E of the SRPFJ now reads:

    Starting nine months after the submission of this proposed Final Judgment to the Court, Microsoft shall make available for use by third parties, for the sole purpose of interoperating or communicating with a Windows Operating System Product, on reasonable and non-discriminatory terms (consistent with Section III.I), any Communications Protocol that is, on or after the date this Final Judgment is submitted to the Court, (i) implemented in a Windows Operating System Product installed on a client computer, and (ii) used to interoperate or communicate, natively (i.e., without the addition of software code to the client operating system product) with a Microsoft server operating system product. (New language in bold).

The addition of the phrase "or communicate" after "interoperate" brings further clarity to this provision. This revision clarifies the parties' intent in drafting Section III.E and thus removes any potential for confusion or ambiguity regarding the scope of the provision based on the meaning of interoperate.

    1. Section III.H.2

Section III.H.2 requires Microsoft to provide points in its Windows Operating System Products for automatically launching competing middleware, commonly referred to as default settings, in certain circumstances. Although Section III.H.1 states that Microsoft must give end users "a separate and unbiased choice" with respect to altering default invocations in Section III.H.2, there was a concern that the requirement that Microsoft implement Section III.H.2 in a wholly unbiased manner was not entirely clear. To clarify that Microsoft must be unbiased with respect to Microsoft and Non-Microsoft products under Section III.H.2, this provision was revised to expressly state that such mechanisms and confirmation messages must be unbiased. The revised language of Section III.H.2 in the SPRFJ provides:

    Allow end users (via an unbiased mechanism readily available from the desktop or Start menu), OEMs (via standard OEM preinstallation kits), and Non-Microsoft Middleware Products (via a mechanism which may, at Microsoft's option, require confirmation from the end user in an unbiased manner) to designate a Non-Microsoft Middleware Product to be invoked in place of that Microsoft Middleware Product (or vice versa) .... (New language in bold).

This modification makes clear the parties' intention that the mechanism available to end users, as well as any confirmation messages to the end user, must be unbiased with respect to Microsoft and Non-Microsoft products.

This modification also addresses any concern that the phrase "at Microsoft's option" in Section III.H.2 could be read to allow Microsoft to take biased action against competing products. It also addresses concerns that Microsoft's presentation of the confirmation message could include derogatory comments about competing products.

In addition, the two exceptions (Sections III.H.2(a)and (b)) that previously followed Section III.H.3, but by their plain language modified III.H.2 ("Notwithstanding the foregoing Section III.H.2 ...."), have been moved, so that they now follow Section III.H.2, and renumbered accordingly for clarification.

    1. Section III.H.3

Section III.H.3 prohibits Microsoft from designing its Windows Operating System Products to alter automatically an OEM's configuration choices without seeking user confirmation and without waiting 14 days from the initial boot. In response to concerns raised regarding Microsoft's ability to change configurations pursuant to Section III.H.3, the following sentence has been added:

    Any such automatic alteration and confirmation shall be unbiased with respect to Microsoft Middleware Products and Non-Microsoft Middleware.

This sentence clarifies the parties' intention in drafting the RPFJ that Microsoft may not alter a configuration based on whether the middleware products are Microsoft or Non-Microsoft products. Similarly, Microsoft may not present a biased confirmation message (such as a message that is derogatory with respect to Non-Microsoft products). Nor may automatic alterations take actions based on a trigger or rule that is biased against Non-Microsoft Middleware or in favor of Microsoft Middleware Products. This modification makes clear, as intended by the parties in the RPFJ, that any action taken under Section III.H.3 must therefore be independent of whether the affected products are Microsoft or Non-Microsoft products.

    1. Section III.I.5

Several commentors raised concerns regarding Section III.I.5, under which an ISV, IHV, IAP, ICP, or OEM could be required to grant Microsoft a license, on reasonable and nondiscriminatory terms, to any intellectual property relating to that ISV's, IHV's, IAP's, ICP's or OEM's exercise of the options or alternatives provided by the RPFJ, if such a cross-license were necessary for Microsoft to provide the options or alternatives set forth in the RPFJ and exercised by the particular ISV, IHV, IAP, ICP or OEM. These concerns ranged from the general concern that the imposition of a cross-licensing requirement was inappropriate to more specific concerns, such as hypothesizing that the cross-licensing provision would reduce the likelihood that persons or entities would take advantage of the RPFJ's disclosure provisions.

As the United States pointed out in its CIS, Section III.I.5 was an extremely narrow provision designed to ensure that Microsoft would be able fully to comply with the terms of the RPFJ without creating greater indirect infringement liability for itself than it would otherwise have. See CIS at 50. In response to the concerns about this provision raised in the public comments, however, the United States proposed, and Microsoft and the Settling States agreed, that the provision should be deleted. Accordingly, Section III.I.5 does not appear in the SRPFJ. This modification does not alter Microsoft's existing obligations to comply fully with the terms of the SRPFJ.

    1. Definition VI.J - Microsoft Middleware

Many commentors suggested that Definition VI.J, Microsoft Middleware, which required that software code be Trademarked, as that term is defined, could potentially exclude current products such as Internet Explorer, Windows Media Player, Microsoft's Java Virtual Machine, and Window Messenger because at least some such products, the commentors claimed, did not satisfy the definition of Trademarked. To clarify any issues surrounding the status of the software code associated with these products, the Microsoft Middleware definition has been modified to include explicitly the software code that is marketed by Microsoft as a major version of any of the named Microsoft Middleware Products listed in Section VI.K.1. With this change, software code can qualify as Microsoft Middleware in part by being either (1) Trademarked or (2) marketed as a major version of any of the named Microsoft Middleware Products (i.e., Internet Explorer, etc.), even if it does not satisfy the definition for Trademarked. The limitation to a major version of a Microsoft Middleware Product is simply a restatement of the limitation in the last paragraph of the Microsoft Middleware definition, which limits the covered software code to that identified as a major version of a Microsoft Middleware Product.

In addition, the previous subsection (4) now modifies the entire definition and has been revised to read:

    Microsoft Middleware shall include at least the software code that controls most or all of the user interface elements of the Microsoft Middleware.

This change is intended to clarify that this provision of the definition is not a required element and therefore somehow intended to narrow or limit the definition; rather, the first three requirements are sufficient to define Microsoft Middleware. The purpose of this last provision is essentially to specify a minimum size or "floor" as to the collection of software code that is included in a particular piece of Microsoft Middleware, preventing the situation in which Microsoft could arbitrarily break up into separate pieces the software code of what would otherwise be Microsoft Middleware, thereby omitting from the Microsoft Middleware definition certain critical or significant pieces of code that constitute that Microsoft Middleware. This modification does not substantively change this definition but instead makes clear that this provision governs the scope of what code must be included in Microsoft Middleware.

    1. Definition VI.R - Timely Manner

A number of commentors question Section VI.R's definition of Timely Manner, the term that defines when Microsoft must meet its disclosure obligations under Section III.D. Several commentors contend that 150,000 beta testers is too high a threshold to trigger Section III.D's disclosure requirement, arguing that for past Windows Operating System Products, Microsoft may have distributed 150,000 beta copies but may not have distributed them to 150,000 individual beta testers. These commentors are concerned that the threshold will never be reached, resulting in no required disclosure before a new Windows Operating System Product is released. Similarly, a number of commentors contend that Microsoft may in the future choose to distribute to fewer beta testers and thereby evade its disclosure obligations.

The parties' intention in drafting this definition was not to distinguish between beta copies and beta testers with respect to the 150,000 requirement. The parties originally chose the 150,000 beta tester distribution level based on the approximate current Microsoft Developer Network ("MSDN") subscription base. In response to the foregoing concerns about the definition of Timely Manner, however, the United States proposed, and Microsoft and the Settling States agreed, to modify the definition to read:

    "Timely Manner" means at the time Microsoft first releases a beta test version of a Windows Operating System Product that is made available via an MSDN subscription offering or of which 150,000 or more beta copies are distributed.

This modification clarifies the parties' intention that Timely Manner should be triggered by the distribution of 150,000 or more beta copies, regardless of whether those copies are distributed to individuals who are considered to be "beta testers." The modification adds a provision such that Timely Manner can also be triggered by distribution via an MSDN subscription offering. The inclusion of distribution via an MSDN subscription offering as a trigger for this definition ensures that, even in the event that the level of MSDN subscribers decreases substantially, Microsoft's disclosure obligations under Section III.D will still be triggered. Therefore, while this modification clarifies, and in fact may slightly broaden, Microsoft's disclosure obligations, it does not substantively differ from the original definition of Timely Manner in the RPFJ.

  1. A New Round of Publication and Comment is Not Warranted Because the Proposed Modifications Are a Logical Outgrowth of the RPFJ.

The foregoing modifications directly respond to concerns raised in the public comments and are the result of the United States' review and consideration, as part of its compliance with the Tunney Act, of the public comments submitted on the RPFJ. The Tunney Act does not require a new round of publication and comment as a result of the modifications contained in the SRPFJ. The publication and comment provisions of the Act serve "to enable the district court to make" its public interest determination. HyperLaw, Inc. v. United States, 1998 WL 388807, at *3, 159 F.3d 636 (D.C. Cir. 1998) (unpublished table decision). Accordingly, a "court should treat notice and comment under the Tunney Act as analogous to agency rulemaking notice and comment." Id. (quotation marks omitted). Applying that analogy, "there is no need for successive rounds of notice and comment on each revision," provided the final decree "is a 'logical outgrowth' of the proposed consent decree. . . . Further notice and comment should be required only if it 'would provide the first opportunity for interested parties to offer comments that could persuade the agency to modify its [proposal].'" Id. (quoting Am. Water Works Ass'n v. EPA, 40 F.3d 1266, 1274 (D.C. Cir. 1994)).

The proposed decree as modified is a logical outgrowth of the RPFJ and requires no further notice and comment. As explained above, each modification responds to public comments on the RPFJ and clarifies language based upon those comments. Without question, each is a natural and logical outgrowth of the notice and comment process. Taken separately or together, the modifications do not fundamentally change the RPFJ. All contribute to benefitting the public interest (and certainly have no adverse effect on the public interest). The purpose of the notice and comment has thus been well-satisfied, and further notice and comment would merely delay the Court's public interest determination without good cause.(8)


For the reasons described herein, the United States hereby submits the SRPFJ to the Court. In our separate Memorandum in Support of Entry of the Proposed Final Judgment and Response of the United States to Public Comments on the Revised Proposed Final Judgment, both of which are also being filed today, we set forth the reasons why the SRPFJ is in the public interest. Upon completion of the Tunney Act requirements, we will respectfully move the Court to enter the judgment.

DATED: February 27, 2002 Respectfully submitted,
   Assistant Attorney General
   Deputy Assistant Attorney General

U.S. Department of Justice
Antitrust Division
601 D Street N.W., Suite 1200
Washington, D.C. 20530
(202) 514-8276

   Special Trial Counsel



1. For the Court's convenience, the United States also submits a red-lined version of the SRPFJ, attached hereto as Exhibit A, which compares the SRPFJ to the RPFJ.

2. The Settling States also agreed to the RPFJ. Following the submission of the RPFJ to the Court on November 6, 2001, the Court deconsolidated United States v. Microsoft Corp. from New York, et al. v. Microsoft Corp., in which the Settling States, nine other states and the District of Columbia are parties.

3. The public comment period officially ran from November 28, 2001, the date that the RPFJ and the United States' Competitive Impact Statement ("CIS") were published in the Federal Register. 66 Fed. Reg. 59,452 (Nov. 28, 2001). Out of an abundance of caution, the United States also chose to accept and treat as Tunney Act comments various communications from members of the public commenting on the proposed settlement that were received by the DOJ beginning on November 5, 2001, the first business day following submission of the initial Proposed Final Judgment to the Court.

4. Of course, the United States retains the right to withdraw its consent to the proposed decree at any time prior to entry, based on the public comments or otherwise. Stipulation, November 6, 2001, at 1; Stipulation, February 27, 2002, at 1.

5. See, e.g.,United States v. Allied Waste Indus., Response to Public Comments on Antitrust Consent Decree and Joint Motion for Entry of a Modified Judgment, 65 Fed. Reg. 36,224 (June 7, 2000) (parties modified divestiture requirements as a result of objections raised in comments); United States v. Thomson Corp., 949 F. Supp. 907, 915 (D.D.C. 1996) (parties proposed modifications to final judgment in response to public comment, among other things); see also Antitrust Procedures and Penalties Act: Hearings on S. 782 and S. 1088 Before the Subcomm. on Antitrust and Monopoly of the Senate Comm. on the Judiciary, 93rd Cong., 1st Sess. 146 (1973) (Testimony of the Hon. J. Skelly Wright) ("The Department itself has modified consent decrees on a number of occasions as a result of public comment.").

6. The Order stated, inter alia, that "the parties shall address ... whether, in response to the comments received by the Department of Justice in accordance with 15 U.S.C. § 16(b), the United States and Microsoft are considering any modifications" to the RPFJ. Order at 1.

7. See Section II.E., infra at 8-9, discussing Section III.I.5. of the RPFJ.

8. Entry of a decree following modification without a new round of notice and comment is conventional in Tunney Act practice. For example, after notice and comment in AT&T, the court said it would enter the decree as in the public interest if the parties agreed to a number of modifications, and the Court entered the modified decree without a new round of notice and comment once the parties did so. United States v. AT&T, 552 F. Supp. 131, 225-26 (D.D.C. 1982); see also Mass. Sch. of Law v. United States, 118 F.3d 776, 778 (D.C. Cir. 1997).

Download 223751.pdf (187.48 KB)
Updated June 30, 2015