IN THE UNITED STATES DISTRICT COURT
DATED: JANUARY 28, 2002
The United States Court of Appeals for the District of Columbia Circuit has held that, over the last seven years, Microsoft has engaged in a broad range of anticompetitive conduct seeking to stifle the development and distribution of innovative middleware technologies. Microsoft’s actions have been directed at entrepreneurial competitors that have, through innovation and ground-breaking competition, invented new products, such as internet browsers, electronic mail, instant messaging, digital imaging, digital media and voice recognition, that have given rise to entirely new industries and new sources of consumer welfare. By imposing an effective remedy to curb Microsoft’s anticompetitive abuses, this Court can help ensure that the varied markets for innovative middleware products remain fertile ground for competition and innovation.
Driven by a desire to maintain the dominance of its operating system monopoly, Microsoft has, as the trial court’s factual findings and the Court of Appeals’ opinion demonstrate, consistently used its monopoly power in a manner that harms consumers and competition. By manipulating the design of its operating system and its own middleware products, Microsoft has effectively denied personal computer manufacturers (“OEMs”) the ability to choose whether or not they want to include Microsoft middleware products on the computers they sell and similarly denied consumers the ability to remove such software from the computers they buy. By imposing broad, exclusionary licensing restrictions by fiat, Microsoft has denied OEMs the opportunity to configure their personal computers in the way they choose, being required instead to favor Microsoft’s middleware products over those offered by competitors. By entering into exclusive contracts with a broad range of parties, such as Internet Access Providers (“IAPs”), Internet Content Providers (“ICPs”), Independent Software Vendors (“ISVs”) and Independent Hardware Vendors (“IHVs”), Microsoft has to a significant extent foreclosed the distribution of competing middleware products. At every step of this process, Microsoft has wielded its monopoly power to threaten, coerce and retaliate against parties that resist its demands.
As a result, Microsoft has effectively denied consumers the choice of buying a personal computer that is not laden with Microsoft middleware products. This harms not only today’s computer users, but tomorrow’s purchasers of personal computers, cellular telephones, personal digital assistants, digital home entertainment centers, set-top boxes, and game consoles, all of whom may have their choices substantially limited if Microsoft’s anticompetitive curbs on innovation are not constrained today.
It is long settled that such broad findings of liability demand even broader, forward-looking remedies designed to prohibit Microsoft from continuing its anticompetitive acts and finding new ways to hinder the growth of other innovative middleware products. The failure of the last consent decree agreed to between Microsoft and the Department of Justice (“DOJ”) in 1995 serves as a stark reminder of the waste of judicial resources and harm to competition that results from a narrow, backward-looking remedy. Neither consumers nor competition will be served through imposition of yet another flawed, ineffective remedy that will make the next antitrust suit a foregone conclusion.
Unfortunately, the Revised Proposed Final Judgment offered by Microsoft, the DOJ and certain states (“RPFJ”) fails to heed the all-too-recent lessons of history. As discussed herein, the contours of the RPFJ reflect the concessions required to gain Microsoft’s agreement rather than the safeguards required to constrain Microsoft’s anticompetitive conduct. The loophole-laden RPFJ is full of exceptions and ambiguities that will not only fail to terminate Microsoft’s anticompetitive conduct, but will ensure that extended judicial proceedings will be required to clarify, if not enforce, its provisions.
For the reasons set forth below, RealNetworks respectfully submits that entry of the RPFJ would not be in the public interest.
II. REALNETWORKS AND THE DIGITAL MEDIA MARKET
RealNetworks, which was founded in Seattle, Washington in 1994,  is a pioneer in the development of digital media technology and services that enable people to create, deliver, discover, and play digital audio and video content over the Internet and other networks, both through downloading and through a method RealNetworks developed called "streaming." Streaming allows digital media files to be compressed and broken into packets, then delivered and decompressed seriatim, so that consumers can enjoy uninterrupted, real-time broadcasts over the Internet. For example, following the events of September 11, 2001, CNN streamed its newscast via the Internet 24 hours a day to provide people with immediate access to the breaking news from their desktops.
Innovation in the market for media players has consistently been driven, not through integration of functionality into operating systems, but by independent developers creating a new market for sophisticated digital media technologies with robust and integrated features and functions. RealNetworks developed the first streaming media player and the first streaming media server in 1995. Since then, RealNetworks has continued to lead innovation in the digital media delivery market, consistently bringing industry-leading innovations -- such as a built-in radio tuner, delivery of stereo audio at 28.8 kbps modem speeds, bookmarking of favorite streams, links to media programming, support for animation, and automatic updating and just-in-time installation of codecs -- to consumers ahead of Microsoft. Rather than being a source of innovation, Microsoft’s commingling of its media player into its operating system has constituted a means by which it has sought to suppress, rather than spur, innovation and competition.
RealNetworks’ technology falls squarely within the Court of Appeals’ definition of middleware as “software products that expose their own APIs,” or Application Programming Interfaces.  RealNetworks makes available software development kits to enable software developers to build applications and extensions using RealNetworks’ technologies to create, deliver and playback digital media. Over 500 ISVs are developing applications using RealNetworks SDKs and websites that provide access to content in RealNetworks’ RealAudio and RealVideo formats utilize RealNetworks’ middleware. Microsoft competes with RealNetworks in seeking to convince software developers and content providers to build applications using their respective technologies. Applications created using RealNetworks’ technology include news broadcasts, distance learning, financial reporting, security for streamed and downloaded content, radio broadcast services, music subscription services, video-on-demand services, web conferencing, e-commerce services and more. One need only look as far as the extensive use of RealNetworks’ technology in the pervasive Internet coverage of the events of September 11th to see how important and pervasive such technologies are becoming.
RealNetworks offers a universal platform designed to provide the highest quality digital media creation, delivery, playback and security experience across multiple operating systems, transport technologies, media formats and digital devices. This RealSystem technology works on over 20 different operating systems (e.g., Unix, Linux, Windows, Solaris, AIX, HP/UX, Symbian), delivers and plays over 50 different formats or datatypes (e.g., MP3, MPEG-1, MPEG-2, MPEG-4, Quicktime, Macromedia Flash, RealAudio, RealVideo), and works with a wide variety of digital devices (e.g., personal computers, Sony PlayStation2, Hewlett Packard’s Digital Entertainment Center, Nokia cell phones, portable music players and personal digital assistants). Applications built using RealNetworks’ technology are operating system independent, so that consumers, content providers, businesses, network operators, and others using such applications do not need to install Windows operating systems on either their personal computers or on the servers that deliver media.
The opportunities for digital media are enormous. The current U.S. market for audio and visual media amounts to over $200 billion per year.  Current estimates for spending in the streaming digital media sector alone exceed $10 billion by 2010.  The pace of innovation and adoption of digital media is rapidly increasing as more content is digitized, more consumer electronics equipment supports digital formats and broadband growth continues to accelerate. By 2007, there will be an estimated 120 million streaming media users in the U.S. alone.  There are over 10 million broadband customers in the U.S., a number expected to grow to over 35 million by 2006.  Broadband use is important because it greatly improves and facilitates streaming media resulting in significantly higher streaming media usage rates. 
III. The Court Has Broad Authority To Ensure That The Remedy Imposed Prohibits Microsoft From Again Limiting The Development of Middleware In An Illegal Manner.
In affirming the trial court’s holding that Microsoft illegally maintained its operating system monopoly, the Court of Appeals broadly condemned a wide range of actions through which Microsoft attempted to reduce usage of competing middleware products.  Under the reasoning of the Court of Appeals’ decision, actions taken by Microsoft that have the effect of hindering competing middleware developers “from gaining the critical mass of users necessary to attract developer attention away from Windows as the platform for software development” -- other than Microsoft’s efforts to improve the quality of its own products – violate Section 2 of the Sherman Act.  Among other things, the court condemned Microsoft’s conduct that falls within the following four broad categories: (1) licensing restrictions limiting the ability of personal computer original equipment manufacturers (“OEMs”) to configure their personal computers in the manner they determine to be appropriate  (2) Microsoft’s design of the Windows operating systems and Microsoft Middleware in a manner that limits the ability of OEMs and consumers to remove Middleware code from the operating system  (3) Microsoft’s entry into exclusive contracts designed to limit usage of competing middleware products  and (4) Microsoft’s threats and intimidation designed to limit the development and distribution of middleware.  In condemning Microsoft’s actions, the Court of Appeals rejected Microsoft’s assertions that integrating Middleware into the operating system or otherwise attempting “to keep developers focused upon its API s” somehow provides any procompetitive justification for Microsoft’s actions. 
A. The Breadth Of The Court Of Appeals’ Liability Holding Demands Imposition Of Broad Remedies
The guiding principles underlying our antitrust laws make clear that the broad grounds of liability affirmed by the Court of Appeals demand imposition of an even broader range of remedies. The Supreme Court has repeatedly held that, in enacting the Sherman Act, Congress sought to "preserv[e] free and unfettered competition as the rule of trade."  This need to safeguard free competition is a direct result of the fundamental premise of our economic system that
This policy is embodied in two types of legal standards -- those applied to the liability phase of antitrust cases and those governing the relief phase. As the Supreme Court has observed, the formulation of adequate remedies is the “most significant phase of the case.”  Courts have broad discretion during the relief phase to ensure that the antitrust remedies imposed "effectively pry open to competition a market that has been closed by defendants' illegal restraints."  An antitrust decree must "break up or render impotent the monopoly power found to be in violation of the Act."  In other words, “the decree must leave the defendant without the ability to resume the actions which constituted the antitrust violation in the first place.” For these reasons, the decree should not be limited to past violations; it must also effectively foreclose the possibility that similar antitrust violations will occur or recur. As the Court noted in International Salt, “ it is not necessary that all of the untraveled roads to [anticompetitive conduct] be left open and that only the worn one be closed. The usual ways to the prohibited goals may be blocked against the proven transgressor.” 
In evaluating the adequacy of an antitrust remedy, the court’s inquiry “necessarily looks forward,” considering evidence that was not necessarily placed in the trial record and, indeed, may not have even been in existence at the time of trial.  It is long settled that the Court may at the relief stage prohibit practices that have not been found unlawful if such a prohibition is necessary to avoid the recurrence of monopolization.  In addition, restraints may be imposed upon the defendant that are designed to allow the development of nascent competition within the relevant market.  Such a remedy is critical here, given the Court of Appeals’ explicit conclusions regarding the nascent potential of middleware to erode the applications barrier to entry that protects Microsoft’s operating system monopoly. 
B. The Antitrust Procedures And Penalties Act Authorizes The Court To Engage In A Broad Inquiry To Determine The Adequacy Of The Proposed Decree
Congress has directed the Court here to determine whether entry of the RPFJ is in the public interest. In making that determination, the Antitrust Procedures and Penalties Act authorizes the Court to undertake a wide-ranging inquiry into two broad areas of evaluation. First, the Court is to consider the “competitive impact” of the proposed consent decree, including whether the proposed decree would actually terminate the defendant’s violations and whether the proposed decree’s enforcement provisions are adequate. In making this determination, the statute expressly authorizes the court to consider “the anticipated effectiveness of alternative remedies, as well as “any other considerations bearing upon the adequacy of such judgment.”  Second, the statute authorizes the court to consider the impact of the proposed decree on the public generally and on those individuals harmed by Microsoft’s violations of the Sherman Act. 
Highly relevant to both of these areas of inquiry is the clarity of the proposed decree. As the Court of Appeals has recognized, “the district judge who must preside over the implementation of the decree is certainly entitled to insist on that degree of precision concerning the resolution of known issues as to make [her] task, in resolving subsequent disputes, reasonably manageable.”  In this way, Congress intends the courts to be an “independent force” in reviewing the adequacy of proposed consent decrees. 
As broad as this language is, it is clear that the statute – which references “alleged violations” rather than violations proven at trial, as well as benefits “to be derived from a determination of the issues at trial”  -- primarily contemplates review of consent decrees settling claims that have not yet been adjudicated. Where, as here, federal and state antitrust enforcers have actually proven during the course of a 76-day bench trial that Microsoft illegally maintained its operating system monopoly in violation of the Sherman Act, and that holding has been affirmed on appeal, the court’s powers of review are at their maximum level. Unlike Judge Sporkin’s review of the DOJ’s previous, ill-fated consent decree with Microsoft, which settled claims that had not been proven, this is not a case in which the court’s review will implicate the DOJ’s prosecutorial discretion in framing the complaint and in appraising whether to pursue its claims through trial, nor does it raise the constitutional concerns of impinging upon the prosecutorial discretion of the executive branch.  Because the Court's determination here is concerned solely with the proper extent of the remedies to be imposed to redress proven violations of the Sherman Act, the Court’s evaluation of this proposed decree should be guided by the well-settled principles governing the adequacy of antitrust remedies.
As set forth below, careful review of the proposed consent decree demonstrates that it falls woefully short of meeting these standards, which were reflected in the Court of Appeals’ admonition that the remedy for Microsoft’s illegal acts
IV. THE RPFJ NEITHER FREES THE MARKET FROM MICROSOFT’S ANTICOMPETITIVE CONDUCT NOR DENIES MICROSOFT THE FRUITS OF ITS ILLEGAL CONDUCT.
The RPFJ fails to satisfy the Court’s clear and simple standard. The RPFJ neither terminates Microsoft’s illegal monopoly nor denies it the fruits of its statutory violations. It fails to ensure that no practices remain that are likely to result in future monopolization. Certainly, Microsoft’s current dominance in the browser market for personal computers is a fruit of its illegal conduct. The RPFJ reads like a tacit approval of Microsoft’s newly imposed browser monopoly; indeed, it is not even mentioned in the DOJ’s Competitive Impact Statement (“CIS”). Nor does the CIS address how the RPFJ is designed to terminate the illegal monopoly or restore JAVA to the position it would have held absent the illegal conduct. The CIS is silent regarding the market conditions that would currently exist were it not for Microsoft’s anticompetitive acts – market conditions that should be restored as part of any adequate remedy. The RPFJ fails to understand and address the long-term impact of Microsoft’s conduct.
Moreover, the RPFJ’s provisions are vague, internally inconsistent and replete with exceptions and loopholes that will allow a determined and proven illegal monopolist to delay and even avoid the remedies. Indeed, the many instances in which the CIS reads into the RPFJ substantial additional terms/restrictions necessary to create a reasonable interpretation of the provisions foreshadows the difficulty of enforcing the RPFJ. Disagreements at this stage between the parties to the RPFJ will pale in comparison to the disagreements that will arise between Microsoft on the one hand and antitrust regulators and impacted parties on the other hand as the Court seeks to enforce the RPFJ.
Because it provides insufficient remedies relating to middleware, OEM/ISV flexibility, information disclosure and enforcement, it is likely that Microsoft will be able to continue with many of its current anticompetitive practices virtually unchanged. In addition, it in effect imposes upon Microsoft’s competitors several restrictions and conditions on doing business and innovating that do not exist today.
This following discussion outlines only some of the deficiencies in the RPFJ. It is not intended to be an exhaustive review of the deficiencies and implications of the proposed settlement.
A. The RPFJ’s Definitions Are Confusing, Inadequate And Create Loopholes And Exceptions To The Actual Remedial Provisions.
Unfortunately, the definitions set forth in the RPFJ severely undermine the RPFJ’s proposed remedies by offering a number of significant loopholes and exceptions to the application of the remedial provisions. By contrast, the Litigating States have proposed a set of definitions that do not allow Microsoft to avoid application of the remedial provisions and that are designed to create a more certain and fair remedial framework. A sample of some of the more obvious definitional problems are addressed below.
B. The RPFJ Does Not Effectively Prevent Microsoft From Using Anticompetitive Tactics Against Competing Middleware.
The Court of Appeals held that Microsoft’s restrictions limiting the ability of OEMs to configure their personal computers in a manner that promotes the use of non-Microsoft middleware violates the Sherman Act. In any effective remedy, OEMs, ISVs and others must be free to bundle, distribute and promote non-Microsoft middleware applications with their products and completely remove Microsoft middleware. They, and end users, must be free to automatically launch competing middleware at any time and must be free to set that middleware as the default applications under any circumstances, irrespective of what Microsoft’s middleware does or does not do. Microsoft should not be able to use its operating system monopoly to override the considered decisions of consumers, OEMs and ISVs without explicit consumer consent, or to automatically prompt consumers override such choices. Whether Microsoft has competing middleware is utterly irrelevant to the threat posed to Microsoft’s monopoly operating system by middleware and should not form the basis for the many exclusions provided in the proposed Settlement. The Litigating States have in fact suggested remedies that accomplish these goals without providing Microsoft a litany of loopholes.
Section III.H purports to provide some limited additional freedom to allow OEMs and third parties to use competing middleware. Unfortunately, the provision is undermined by exceptions and limitations that fail to comply with the Court of Appeals’ admonitions regarding OEM freedom and protection for competing middleware.
Section III.H.3 limits Microsoft’s ability to use its “Windows Operating System Product” to override the freedoms granted to OEMs, but that limitation only lasts for fourteen days, after which Microsoft is completely free to use its commingled and bundled middleware to override the OEM configurations. Microsoft can use this gaping loophole to override OEM/consumer choice instantly, automatically, and without notice to consumers to OEMs as long as Microsoft does so through its commingled middleware, rather than through its operating system. Furthermore, a mere fourteen days after an end user starts using his or her personal computer, Microsoft can use its monopoly operating system to “recommend” that the user change his or her default settings to favor Microsoft middleware to the exclusion of competing middleware. Thus, on day fifteen we can expect Windows to start a daily process of exhorting the user to reject competing middleware. Windows XP currently uses similar behaviors to consistently attempt to reclaim default status for its favored Microsoft middleware. For example, even after a user has selected competing middleware to play back CDs, Windows XP prompts the user to change to Windows Media Player when a CD is inserted. The prompt includes Windows Media Player as the preselected application at the top of the list.
The exception provided in the last paragraph of Section III.H. limits application of that section to Microsoft Middleware Products that “exist” more than seven months prior to the “last beta test version” of the operating system. This loophole allows Microsoft to engineer its releases of new middleware to be less than seven months from the final beta in order to completely avoid the remedial provisions in Section III.H. For instance, because Windows Media Player 8 was released within 7 months of the final beta for Windows XP, Microsoft can be expected to argue that competing middleware would not be entitled to the protections of Section III.H. Certainly, this could not be the intended result of the language and the Court must ensure that the parties to the RPFJ clarify the interpretation of the exception to avoid such unintended results.
Oddly, the RPFJ’s limitations protect Microsoft’s middleware from innovative competitors. For instance, Section III.H.2 allows OEMs to set competing middleware as the default only if Microsoft has a “Microsoft Middleware Product” that would otherwise launch in its own separate “Top-Level Window.” There is no legal or procompetitive justification for so limiting OEMs, ISVs or end users based on the existence or performance of Microsoft middleware products. As the Court of Appeals recognized, middleware is important because it has the potential to erode Microsoft’s operating system monopoly and the applications barrier to entry that protects it. Conditioning middleware protections on actions within Microsoft’s control obviously presents Microsoft with the ability to manipulate its software design, as it has in the past, in a manner that will further impede the development and distribution of competing middleware products. Whether Microsoft has competing middleware – and by extension the performance characteristics of that middleware – is irrelevant to the nascent threat that middleware poses to Microsoft’s operating system monopoly and ignores its past anticompetitive efforts to harm competing middleware. Third party innovators should not be excluded from the application of the RPFJ until and Microsoft first develops its own competing product. In the CIS, the DOJ states that Microsoft Middleware “is the concept that triggers Microsoft’s obligations, including those relating to Microsoft’s licensing and disclosure obligations . . .” without providing any rationale. The applicability of the remedies set forth in Sections III.C.3, H.1 and H.2 should not depend upon the presence or performance of Microsoft’s middleware in any way, nor should any other provision.
Section III.H.1 of the RPFJ allows Microsoft to override OEM configurations and consumer choice for default middleware as long as Microsoft uses one of its own servers to communicate with its own competing middleware. This allows Microsoft to use its Passport, MSN, Dot.net, Hotmail and other servers to avoid and override the explicit choices made by OEMs/ISVs and consumers. Section III.H.1 has no procompetitive justification and once again places competing middleware at an unfair disadvantage.
The RPFJ would grant Microsoft the right to require consumers who expressly choose to use Non-Microsoft Middleware to subsequently confirm their choices to Microsoft. Some Non-Microsoft middleware products provide consumers with an opportunity to choose whether to establish the middleware product as the default for certain functions and, if so, to authorize the middleware product to protect against attempts by Microsoft to override the consumer’s choice. Rather than requiring Microsoft to honor such consumer choices, Section III.H.2 would allow Microsoft to require the consumer to confirm his or her choice every time Microsoft attacks it.
C. The RPFJ Does Not Provide OEMs With Appropriate Freedom To Choose Competing Middleware, Remove Microsoft Middleware, And Customize The User Interfaces, Menus, Desktop And Other Windows Elements.
The need for an effective remedy that prevents Microsoft from illegally abusing its operating system monopoly to harm competitors is beyond dispute. The undisputed facts, as found by the trial court and affirmed by the Court of Appeals, establish in detail the broad power that Microsoft possesses over OEMs and the broad manner in which it has abused that power to maintain its monopoly in violation of the Sherman Act.
As the DOJ and the plaintiff States proved in this litigation, Microsoft’s operating system monopoly grants it tremendous sway over OEMs. For example, in June 1996 “Compaq executives opined that their firm could not continue in business for long without a license for Windows.” This is consistent with Hewlett Packard’s lament to Microsoft in March 1997 that “[i]f we had a choice of another supplier, based on your actions in this area, I assure you [that you] would not be our supplier of choice.” Based on such statements, the trial court found that OEMs had “no commercially viable alternative” to pre-installing the Windows operating system on their personal computers. Moreover, Microsoft’s power has actually increased since the trial court made its findings in 1999: according to the International Data Corporation, from 1999 to 2000 Microsoft’s share of the client operating system market, including Apple’s Mac OS, increased by 10.6% to 95.4% (when measured by shipment and upgrade revenue) and by 11.1% to 92.6% (when measured by new license shipments).
Plainly, any effective remedy for Microsoft’s anticompetitive conduct must put an end to such practices. The RPFJ, however, falls woefully short of either unfettering OEMs from Microsoft’s control or ensuring that Microsoft will not continue to impose restrictions on OEMs that harm the development of competing middleware.
1. The RPFJ does not require Microsoft to allow OEMs to remove its middleware from Windows
The RPFJ does not even allow OEMs and end users to completely uninstall and remove Microsoft’s middleware once they have acquired the bundled products. In affirming the trial court’s conclusion that Microsoft illegally maintained its operating system monopoly in violation of the Sherman Act, the Court of Appeals twice held that Microsoft’s design of Windows in a manner that denied OEMs the ability to remove middleware – specifically, Internet Explorer – from Windows operating systems is anticompetitive because it “deters OEMs from pre-installing rival browsers, thereby reducing the rivals’ usage share and, hence, developers’ interest in rivals APIs as an alternative to the API set exposed by Microsoft’s operating system.” Moreover, the Court explicitly rejected Microsoft’s assertions that such integration “is highly efficient and provides substantial benefits to customers and developers,” concluding instead that Microsoft was simply “protect[ing] its operating system monopoly from a middleware threat” in violation of Section 2 of the Sherman Act.
Notwithstanding the clarity of the Court’s ruling on this issue, the RPFJ would essentially endorse Microsoft’s anticompetitive commingling of its own middleware into Windows in a manner that prevents OEMs from removing it from the operating system. This is not an idle concern because Microsoft still prevents OEMs from removing middleware, such as Internet Explorer and the Windows Media Player, from the Windows operating systems. Nor would the deceptively named “add/remove” remedy enable OEMs or consumers to actually remove Microsoft middleware functionality or even disable the middleware, as it simply hides icons without actually removing the middleware code from the operating system. With the middleware code intact, there are many ways in which Microsoft’s middleware can still be launched and take default status for all middleware functions. Without appropriate remedies like those proposed by the Litigating States, Microsoft will leverage its ability to bundle and bind its middleware with every copy of the operating system to attempt to convince developers to write to the Microsoft’s middleware APIs rather than competing middleware APIs. Allowing Microsoft to commingle its middleware and refusing to allow OEMs to remove Microsoft middleware flies directly in the face of the Court of Appeals decision.
2. The RPFJ enshrines, rather than prohibits, Microsoft’s ability to require OEMs to provide access to Microsoft Middleware while restricting the end-user access that OEMs can provide for Non-Microsoft Middleware
The findings of fact in this litigation establish beyond dispute that Microsoft has required OEMs to include certain icons, Start Menu entries and other forms of end-user access for Microsoft middleware products while it has at the same time restricted the ability of OEMs to promote competing middleware products during the Windows operating system boot sequence. Specifically, the trial court found that, in the spring of 1996, Microsoft imposed a series of new operating system licensing restrictions on OEMs explicitly intended to restrict the ability of OEMs to reconfigure the Windows operating system desktop and boot sequence in a manner that would improve usage of non-Microsoft middleware. These restrictions included the following:
Indeed, Microsoft went so far as to threaten to terminate Compaq’s operating system license based on its removal of such icons for Microsoft’s Internet-related middleware products. The Court of Appeals broadly condemned such actions, which reduce usage of competing middleware products, “not by improving [Microsoft’s] own product but, rather, by preventing OEMs from taking actions that could increase rivals’ share of usage.”
Notwithstanding these clear legal findings and conclusions, Section III.C of the RPFJ allows Microsoft to continue to retain considerable control over how and whether OEMs can make competing middleware accessible to consumers of its personal computers through display of icons, menu entries and shortcuts. Section III.C.1 allows Microsoft to set rules restricting the manner in which OEMs display icons, menu entries and shortcuts for non-Microsoft middleware. The discretion afforded to Microsoft provides it with yet another method of limiting the prominence that OEMs can assign to competing middleware on personal computers running Windows operating systems. Section III.C.1 allows Microsoft to dictate which Non-Microsoft middleware can be accessible in which places in the Windows operating systems, without justifying its functionality-based distinctions. There is no valid, pro-competitive reason to take this control away from OEMs. As the trial court found, “[s]ince OEMs share Microsoft's interest in ensuring that consumers can easily find the features they want on their Windows PC systems, Microsoft would not have prohibited OEMs from removing icons, folders, or ‘Start’ menu entries if its only concern had been consumer satisfaction.”
Nor does the RPFJ protect the ability of OEMs to choose which middleware products to establish as the default on its personal computers. In light of the trial court’s finding that Microsoft reduced the Windows royalty price for certain OEMs, including Gateway, that set Internet Explorer as the default browser on their personal computers, such protection is required. The proposed decree, however, safeguards the ability of OEMs to designate competing middleware as the default only in those situations where the Windows operating system would otherwise launch Microsoft’s application in a “Top-level Window” that displays “all of the user interface elements.” For instance, this significant loophole would allow Microsoft to continue to prevent OEMs from launching competing middleware in a variety of instances in which the middleware is invoked as an embedded component in another application, like Internet Explorer.
Similarly, by allowing Microsoft to prevent OEMs from launching any non-Microsoft middleware product that does not display a user interface or that displays a user interface that is similar to or smaller than the user interface of Microsoft’s middleware product, Section C.3 of the proposed settlement would hand Microsoft the ability to exercise significant control over the design of middleware products and other software applications. This loophole is particularly unjustifiable given the trial court’s finding that Microsoft had previously “prohibited OEMs from adding icons or folders to the Windows desktop that were not similar in size and shape to icons supplied by Microsoft.” A proposed remedy that endorses, rather than condemns, anticompetitive conduct is not in the public interest. More generally, there is no procompetitive justification for allowing Microsoft, which maintained its operating system monopoly in violation of U.S. antitrust law, to have a substantial impact on the design decisions of competitors that have been disadvantaged by Microsoft’s anticompetitive practices. Because these conditions would restrict the ability of OEMs to increase the usage of middleware products that compete with Microsoft, it is apparent that, were they imposed by Microsoft independently, they would be found to violate the Sherman Act under the reasoning of the Court of Appeals decision.3. The RPFJ does not prohibit Microsoft from continuing to threaten and retaliate against OEMs that have resisted doing Microsoft’s bidding
The trial court’s findings of fact amply document Microsoft’s repeated and brazen efforts to threaten and retaliate against OEMs when they have resisted doing Microsoft’s bidding. For example, the trial court concluded that, as part of its efforts to “ostracize Navigator from the vital OEM distribution channel,” Microsoft “threatened to terminate the Windows license of any OEM that removed Microsoft's chosen icons and program entries from the Windows desktop or the ‘Start’ menu. It threatened similar punishment for OEMs who added programs that promoted third-party software to the Windows ‘boot’ sequence.” Such retaliatory efforts extended so far as threatening “to terminate Compaq's license for Windows 95,” demonstrating that Microsoft “was prepared to go to the brink of losing all Windows sales through its highest-volume OEM partner” in pursuit of its anticompetitive ends. Microsoft’s operating system monopoly enabled it to take such actions with impunity, indifferent to the fact that such threats “soured Microsoft's relations with OEMs and stymied innovation that might have made Windows PC systems more satisfying to users.” In light of this sustained practice of intimidation, the DOJ correctly points out that “it is critical that the OEMs, through whom the large majority of copies of Microsoft’s Windows Operating System Products reach consumers, are free to choose to distribute and promote middleware without interference from Microsoft.”
The RPFJ, however, fails to place any restriction on Microsoft’s ability to inflict financial retaliation on OEMs. Indeed, Section III.A. of the proposed decree explicitly limits application of its “anti-retaliation” provisions to “newly introduced forms of non-monetary Consideration.” Neither Microsoft nor the DOJ offers any justification for failing to restrict Microsoft from employing financial penalties to threaten or retaliate against recalcitrant OEMs. Moreover, in the face of the extensive record in this litigation of Microsoft’s past course of threats and retaliation, Section III.A does not even prohibit Microsoft from withholding existing forms of non-monetary consideration from OEMs that seek to develop, distribute or use non-Microsoft middleware, distribute competing operating systems, or otherwise seek to exercise their purported “rights” under the RPFJ. Instead, Section III.A applies only to “newly introduced forms” of non-monetary consideration. Such gaping loopholes simply cannot be reconciled with the DOJ’s assertion that “Section III.A ensures that OEMs have the contractual and economic freedom to make decisions about distributing and supporting non-Microsoft software products that have the potential to weaken Microsoft’s personal computer operating system monopoly without fear of coercion or retaliation by Microsoft.”
4. Similarly, the RPFJ does not prohibit Microsoft from continuing to employ discounts and other financial inducements to accomplish its anticompetitive ends
The undisputed factual record in this case similarly documents Microsoft’s extensive use of discounts and other financial inducements as a critical component of its anticompetitive conduct. For example, it is no longer disputed that Microsoft offered IBM substantial benefits, including “soft dollars and marketing assistance, “in return for . . . shipping its systems without any software that competed with Microsoft.” The trial court also found that Microsoft “grant[ed] Hewlett-Packard and other OEMs discounts off the royalty price of Windows as compensation for the work required to bring their respective alternative user interfaces into compliance with Microsoft's requirements” restricting their ability to reconfigure the desktop and boot sequence in Windows 95 and Windows 98. Similarly, Microsoft “used incentives and threats in an effort to secure the cooperation of individual OEMs” to promote the Internet Explorer “to the exclusion of Navigator.” Indeed, the court found that “Microsoft agreed to give OEMs millions of dollars in co-marketing funds, as well as costly in-kind assistance, in exchange for their carrying out other promotional activities for Internet Explorer.” Consistent with this, Microsoft reduced the Windows royalty price for certain OEMs, including Gateway, that set Internet Explorer as the default browser on their personal computers and that displayed Internet Explorer's logo and links to Microsoft's Internet Explorer update page on their own home pages, and offered to compensate Gateway if it would replace Navigator with Internet Explorer.
The RPFJ, however, would not prevent Microsoft from continuing to use discounts, market development allowances and other such programs as part of its efforts to coerce OEMs into favoring Microsoft’s middleware over competing software. Given the loopholes that pervade the proposed decree, Section III.B.3 simply requires that Microsoft identify the criteria on which discounts are based and make them available to all OEMs covered by the decree. While this may somewhat limit Microsoft’s ability to discriminate among OEMs, it does not prevent Microsoft from using such inducements to coerce OEMs into discriminating against competing middleware products.
D. The RPFJ Contains Insufficient Provisions To Ensure Adequate And Timely Information Disclosure
Microsoft has a history of refusing to disclose APIs, delaying disclosure of APIs, and selectively disclosing APIs to favored ISVs at the expense of disfavored ISVs. For example, Microsoft has refused to disclose APIs relating to Secure Audio Path (“SAP”) and has actively used its exclusive access to this technology to market against its competitors beginning at least as far back as October 2000. The RPFJ does not end this type of head start and exclusive access. Microsoft uses its control over Windows interfaces to thwart competition from better, more compelling middleware applications. For instance, Microsoft has refused to disclose critical interface and other technical information used by it in Windows XP relating to a number of functions, including direct access to SAP and to the “Play all” and “Burn CD” features in the My Music folder. Access to all of the APIs and technical interfaces available in the monopoly Windows OS is critical to ISVs and should be in Microsoft’s best interest given its stated top goal of providing a platform upon which all ISVs can build. Because of Microsoft’s past anticompetitive behavior, it is important to have a clear and broad remedy provision requiring full disclosure of any technical interfaces, appropriately defined, between Microsoft’s operating system, bundled middleware and any other Microsoft applications.
The RPFJ contains several major exceptions and loopholes that allow Microsoft to delay and avoid disclosing the technical information necessary to allow competing middleware providers to fully interoperate with Microsoft’s software. Section III.D of the RPFJ only requires Microsoft to disclose APIs relating to “Microsoft Middleware” – a very narrowly defined term that does not include any middleware bundled with the operating system (unless separately distributed as an “update”). This subtlety in the RPFJ allows Microsoft to easily avoid the information disclosure requirements. As long as Microsoft bundles its middleware with its operating system, rather than distributing it separately, it will no doubt argue that there is no information disclosure requirement, although that would seem contrary to the intent of the RPFJ.
Limiting Section III.D to Microsoft Middleware makes it easy for Microsoft to avoid disclosing APIs for a host of features and functions made available to Microsoft’s application developers. This is especially true given the fact that the RPFJ allows Microsoft, in its “sole discretion,” to decide what is in the operating system and what is not. This provides virtually unlimited opportunity for gerrymandering. There is certainly no procompetitive justification for this restriction. The Litigating States’ proposed remedy, on the other hand, requires Microsoft to provide all APIs that are used by Microsoft’s own application developers to interoperate with either the operating system or middleware. It does not provide a complex web of limitations and restrictions that are bound to create further unnecessary litigation.
The provision regarding server interoperability excludes communications between Microsoft Middleware Products – even those that are commingled and bound with the Windows operating system -- and Microsoft servers. This is an enormous loophole. As written, Microsoft is likely to argue that the provision does not allow ISVs to obtain any access to Microsoft’s communications protocols between Microsoft servers and applications such as Internet Explorer, Windows Media Player and instant messaging. Again, this does not seem consistent with the intent of the RPFJ.
In an amazing reversal of fortune, the RPFJ would actually require law-abiding ISVs to license their technology to Microsoft – an illegal monopoly – if they want to take advantage of Microsoft’s APIs. The fact that an ISV might license and use technology from Microsoft, as allowed under the proposed settlement, should not entitle Microsoft to get a license to the ISV’s technology “relating to the exercise of their options or alternatives.” By ensuring that Microsoft will obtain contractual rights to technologies that it deems to be strategic, the RPFJ provides assistance to Microsoft’s continuing anticompetitive efforts to restrict the development and distribution of competing middleware by bundling its own versions of those technologies with its operating system in an attempt to dominate the market to the detriment of its more innovative competitors. Because Microsoft is not doing any development on behalf of the ISVs as part of the RPFJ, it does not need licenses to ISV technology to perform its obligations. This provision in effect operates as a poison pill that presents substantial disincentives for competing middleware developers to qualify for the protection of the very provisions of the RPFJ that are designed to foster competition in these nascent markets.
E. Microsoft Can Continue Its Anticompetitive Practices For Up To One Year – And Intends To Do So.
The RPFJ’s time periods for Microsoft’s compliance with a variety of provisions, including those related to information disclosure, place competing application developers at a serious disadvantage. Middleware ISVs should have as much time as Microsoft’s own application developers to use the APIs and other technical information necessary to access, utilize and support the full features and functionality offered by the Windows operating systems. Indeed, the extended time provided to Microsoft to comply with the RPJF is in direct contradiction of one of the DOJ’s stated reasons for entering into the settlement: prompt relief. For example, Microsoft has a full year to comply with the bulk of the information disclosure provisions and other provisions related to middleware in Sections III.D and H. Microsoft essentially has been blessed to continue wield its monopoly power for long periods of time to the detriment of consumers and competition. Instead, relief should be immediately available. If Microsoft does not have the technology ready, it should nevertheless be required to allow others to implement the provisions on their own while Microsoft delays disclosing the APIs. There is no competitive justification for giving Microsoft nine or twelve months to disclose – and license – interfaces that are readily available to, and now in use by, Microsoft’s own application developers. In fact, Microsoft is already relying on the 12 month delay provision to avoid disclosing APIs to SAP. Despite repeated requests, Microsoft has not provided RealNetworks with any information or even confirmation that it would provide access to SAP. In a January 2002 communication to RealNetworks, Microsoft simply pointed to the twelve-month time frame and claimed it was in compliance.F. The RPFJ Does Not Materially Affect Microsoft’s Ability To Engage In Anticompetitive Exclusive Dealing
The RPFJ does not effectively prohibit Microsoft from using deals with an IAP, ICP, ISV, an independent hardware vendor (“IHV”), or OEM to limit competition. Microsoft has long relied on such deals in an attempt to limit the development of competing middleware solutions. For example, Microsoft has entered into agreements specifically limiting or forbidding use of middleware that threatens its operating system monopoly. Microsoft has entered into agreements requiring independent content providers to use technology designed to detect whether the end user has Microsoft middleware installed on his or her computer and then using that technology to the exclusion of competing middleware, even when the consumer had chosen the competing middleware as their default. Such conduct flies in the face of Microsoft’s own statements that it is trying to create a platform for ISVs Microsoft’s actions are damaging to any ISV who build competing middleware on Microsoft’s platform.
Section III.G allows Microsoft to demand parity with any third party product that Microsoft considers to be a competitor to its Platform Software in any deal with an IAP, ICP, ISV, IHV, or OEM that distributes, promotes, uses, or supports the third party product. This provision seems designed to prevent competitors from getting ahead of Microsoft.
In addition, Microsoft is sure to continue to use its investments as a vehicle to demand exclusivity or preference for its products to the detriment of competing middleware. Microsoft can enter into any agreement with an ISV, IHV, IAP, ICP, or OEM provided that each contributes either “significant developer” or “other resources” prohibiting the entity from competing with the object of the agreement for a reasonable (undefined) period of time. This would bless and legitimize Microsoft’s current anti-competitive behavior through which Microsoft leverages other assets to maintain its illegal monopoly. Moreover, Microsoft can apparently avoid even these requirements simply by licensing intellectual property as part of the deal (see Section III.G.2). Section G appears to allow Microsoft to license third party intellectual property under whatever scenario it desires. This presents a gaping loophole to the entire section, as does the exception for any “joint development or joint services” arrangement. Virtually any technology deal could be styled as such.
The prohibitions of Section III.G.2 are strangely applicable only to contracts with IAPs and ICPs (not IHVs, ISV or OEMs) to obtain placement in Windows. In fact, it should simply prohibit Microsoft from entering any contract conditioned on any third party’s agreement to refrain from or limit distribution, promotion or use of competing middleware. As written, the provision would allow Microsoft to require any ISV or IHV to refrain from distributing or promoting competing middleware as a condition for placement in Windows, or for placement on MSN, or for access to Dot.Net or for anything else. Surely, this could not have been the intent of the DOJ, yet it is the result of the language in the RPFJ.
G. The Enforcement Provisions Are Weak And Ineffective
The Court of Appeals conclusively established that Microsoft is an illegal monopolist. Yet, remarkably, Microsoft has not modified its anticompetitive behavior in any meaningful way despite the Court’s clear conclusions, just as previously the consent decree entered by the DOJ failed to end Microsoft’s anticompetitive conduct. The necessary enforcement mechanisms must reflect the harsh reality that Microsoft has repeatedly shown its complete disrespect for the judicial process and directives of the courts. Unfortunately, the enforcement mechanisms in the RPFJ are completely ineffectual and are destined to fail. Any conduct-based remedies in this complex environment will be effective only to the extent they are capable of prompt, rigorous enforcement.
For instance, the proposed settlement fails to put in place a meaningful mechanism for preventing, identifying and resolving violations of the proposed agreement in an expedited manner. The voluntary dispute resolution mechanism is designed for delay rather than deterrence. It is essential that any decree establish clearly defined procedures, with prompt, prescribed time deadlines, to enable the government and the court to address violations of the decree in a full and expeditious manner. By contrast, the “voluntary dispute resolution” provisions of the proposed settlement are as inadequate as the name suggests. The only “penalty” for willful and systemic violations of the proposed settlement is a one-time, two-year extension on the already truncated five-year term, much of which does not even become effective for an entire year. The time frames for investigating complaints are loose or non-existent, with no clear or prompt recourse to the court for resolution. Moreover, the “Technical Committee” is housed at Microsoft, cannot independently go to the court for redress and cannot present any of its findings or information to the court, which ensures that the substantial time, effort, and expense devoted to the Committee’s processes would need to be duplicated in future compliance efforts. Inexplicably, Microsoft is allowed to appoint a member of the Technical Committee, a sort of permanent seat on the security council to oversee its overseers. Rather, the proposed decree needs to establish a Special Master, that can make prompt recommendations directly to the Court.
This litigation has been going on for over three years. Microsoft has reaped the rewards of its illegal conduct during that time, and continues to do so. The RPFJ would provide Microsoft with an additional 12 months to comply with several provisions that should require immediate compliance. The proposed time frames greatly overstate the difficulty of providing ISVs with technical information that Microsoft has been using itself to develop Middleware and other applications. Any purported hardship imposed by more appropriate deadlines would certainly by justified by Microsoft’s history of illegal conduct. Consumers deserve swift and certain relief.
As set forth above, entry of the ambiguous and loophole-laden RPFJ would engender significant uncertainty as to its terms and actual effect and would, in many respects, potentially assist Microsoft in its anticompetitive efforts to restrict the development and distribution of competing, innovative middleware. The full anticompetitive harm that would result from a failure to effectively redress the anticompetitive conduct identified by the Court of Appeals cannot, however, be fully understood simply by examining Microsoft’s anticompetitive conduct to date, as substantial as that is. As the trial court found in this litigation, the full effects of Microsoft’s anticompetitive conduct extend well beyond today’s consumers of personal computers to chill tomorrow’s innovations and the new products and markets that such innovations will make possible:
By contrast, the Court has before it an eminently superior remedy proposed by the Litigating States. Bereft of the ambiguity and loopholes that benefit the monopolist they are ostensibly intended to restrain, the States’ proposed remedy highlights the extent to which the RPFJ fails to effectively end Microsoft’s anticompetitive conduct. Forward-looking in scope and straightforward in application, the States’ proposed remedy is appropriately tailored to redress the anticompetitive conduct identified by the Court of Appeals, while preserving Microsoft’s ability to compete with other operating systems and other middleware products on the merits.
For the reasons set forth herein, RealNetworks respectfully submits that entry of the RPFJ would not be in the public interest.
 United States v. Microsoft Corp., 253 F.3d 34, 53 (D.C. Cir. 2001), cert. denied, 151 L. Ed. 2d 264, 122 S. Ct. 350, 70 U.S.L.W. 3267 (2001). APIs are interfaces exposed by operating systems and middleware that support the functions of software programs, called “applications,” that perform specific user-oriented tasks. APIs “are synapses at which the developer of an application can connect to invoke pre-fabricated blocks of code in the operating system. These blocks of code in turn perform crucial tasks, such as displaying text on the computer screen.” United States v. Microsoft Corp., 84 F. Supp. 2d 9, ¶ 2 (D.D.C. 1999), aff’d, 253 F.3d 34 (D.C. Cir. 2001), cert. denied, 151 L. Ed. 2d 264, 122 S. Ct. 350, 70 U.S.L.W. 3267 (2001).
 See Microsoft, 253 F.3d at 60. Assistant Attorney General Charles A. James acknowledged that this “was a middleware case, a middleware case, a middleware case.” Mark Wigfield, Antitrust Chief Defends Government’s Settlement with Microsoft, Dow Jones Newswires, Nov. 16, 2001.
 Northern Pacific Railway Co. v. United States , 356 U.S. 1, 4 (1958). See also National Society of Professional Engineers v. United States , 435 U.S. 679, 692 (1978); United States v. Crescent Amusement Co. , 323 U.S. 173, 187 (1944).
 United States v. Grinnell Corp. , 384 U.S. 563, 577 (1966). See also United States v. United Shoe Machinery Corp. , 391 U.S. 244, 251 (1968); Schine Chain Theatres, Inc. v. United States , 334 U.S. 110, 128-29 (1948).
 International Salt , 332 U.S. at 400. >See also National Society of Professional Engineers, 435 U.S. at 697-98; United States v. United States Gypsum Co. , 340 U.S. 76, 88 (1950); Associated Press v. United States , 326 U.S. 1, 22 (1945); Crescent Amusement, 323 U.S. at 188; United States v. United Shoe Machinery Corp., 110 F. Supp. at 346-47.
 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. 1 (1973) (statement of Sen. Tunney).
 For example, Microsoft delayed release of Windows 98 so as to miss the holiday shopping season in 1996 – contrary OEMs’ economic interests, well Microsoft’s own economically rational interests solely ensure that Internet Explorer 4.0 could be commingled into operating system, regardless suffering imposed on OEMs terms lost sales. 84 F. Supp. 2d at ¶ 167 “Maritz agreed with Allchin's point synchronizing was ‘the only thing makes sense even if suffer.’" ) >
 253 F.3d at 64-66. >See also Order (D.C. Cir. Aug, 2, 2001)(per curiam)(denying Microsoft’s petition for rehearing on the commingling issue). Indeed, in denying Microsoft’s petition for rehearing on this issue in the clearest possible terms, the Court pointedly advised the parties that “[n]othing in the Court’s opinion is intended to preclude the District Court’s consideration of remedy issues.” Id.
 84 F. Supp. 2d at ¶ 230 (“Microsoft used incentives and threats in an effort to secure the cooperation of individual OEMs” its efforts ensure that personal computer users would have ready access Internet Explorer>). See also id. at ¶¶ 235-38 (describing pressure exerted on Gateway and IBM).
 Secure Audio Path is a technology designed to maintain the security of a file as it moves through the operating system for eventual playback by a sound card. It is designed to prevent interception of secure content along the route to the sound card. Microsoft has been exhorting content providers to use its Windows Media middleware in part because of its exclusive access to Secure Audio Path.