U.S. Department
of Justice
Microsoft Tunney Act Comment : Palm, Inc.
| |
| Comments To The Revised Proposed Final Judgment In Submitted By Palm, Inc. January 28, 2002 TABLE OF CONTENTS
Pursuant to the Antitrust Procedures and Penalties Act, 15 U.S.C. § 16(b)-(h), Palm, Inc. ("Palm") hereby submits its comments and objections to the Revised Proposed Final Judgment ("RPFJ") filed by Plaintiffs United States of America ("DOJ") and the States of New York, Ohio, Illinois, Kentucky, Louisiana, Maryland, Michigan, North Carolina and Wisconsin, and Defendant Microsoft Corporation ("Microsoft") on November 6, 2001. Palm, a leader in mobile computing,1 respectfully submits that the RPFJ will not ensure vigorous competition in this important industry. Microsoft is already engaging in actions designed to unfairly extend its personal computing operating system ("PC OS") monopoly into the mobile computing market by eliminating competition and preventing free customer choice.2 The RPFJ fails to address Microsoft's current actions, and will not constrain it from repeating in the mobile computing market the same tactics it used against Netscape and Java. Mobile computing is an emerging threat to Microsoft's PC OS business. Handhelds are already displacing some notebook and desktop PCs for storing, accessing and managing information, including Interact information.3 That competition will increase over time. If an open competitive environment exists, the convenience and simplicity of handheld devices will increasingly cause an evolution away from desktop and laptop PCs to handheld computers for accessing and managing information. The growth of handheld devices not based on Microsoft technology is a threat to Microsoft's PC OS monopoly, as were the competitive inroads being made by non-Microsoft Internet browsers. As noted above, Microsoft is already taking actions to forestall competition in the mobile computing industry. In particular:
Microsoft has also already exhibited its intent to foreclose companies such as Palm by breaking interoperability with its products. Bill Gates himself directed his staff to alter Microsoft products to ensure that Microsoft's "PDA will connect to Office in a better way than other PDAs even if that means changing how we do flexible schema in Outlook and how we tie some of our audio and video advanced work to only run on our PDAs." (Remedy Exhibit GX1 attached to this submission). As the DOJ argued previously: ... on July 11, 1999, less than thirty days after the conclusion of the trial in this action, Bill Gates wrote an e-mail directing that Microsoft redesign its software in order to harm competitors. This time, the products in question were the Personal Digital Appliances that Microsoft heralded at trial as one of the products that might someday undo its monopoly. Plaintiffs' Memorandum In Support Of Proposed Final Judgment, filed April 28, 2000 (corrected as of May 2, 2000) (citing Remedy Exhibit GX1). Microsoft's anticompetitive incentive is obvious. Its anticompetitive conduct will enable it to monopolize the emerging handheld industry and, at the same time, eliminate the threat handhelds pose to its PC OS monopoly. As delineated more fully below, it is Palm's belief that the RPFJ, if adopted, would fail to protect competition in the handheld industry for at least the following reasons:
If the above RPFJ shortcomings are not addressed, Microsoft will be able to dictate customer decisions regarding computing models and standard technologies for the indefinite future, rather than having those decisions made by consumers on the competitive merits. Competition, and the innovative solutions that emerge from that competition, will suffer. Any settlement with Microsoft must address these issues now, because, as the industry has learned from the Internet browser war, competition can be lost in the blink of an eye. Palm develops and markets, among other products, a line of handheld computers that operates proprietary and non-proprietary applications using its Palm OS. Based on the Palm OS platform, Palm's handheld solutions allow consumers to store and access their most critical information and communications, including from the Internet. Palm handhelds address the needs of individuals, enterprises and educational institutions through thousands of application solutions that ISVs create. The Palm OS platform is also the foundation for products from Palm's licensees and strategic partners (also known as the Palm Economy), such as Acer, AlphaSmart, Franklin Covey, HandEra (formerly TRG), Garmin, Handspring, IBM, Kyocera, Samsung, Sony and Symbol Technologies, as well as a multitude of ISVs and IHVs. Palm competes with numerous companies in its software and hardware businesses. Microsoft's Pocket PC OS is one of Palm's most direct competitors in operating systems designed for handheld devices. Microsoft licenses the Pocket PC OS to OEMs, including Compaq and Hewlett Packard, that install the OS in their handheld products. It markets these products as "Windows Powered" -- suggesting deceptively, Palm believes, that the Pocket PC product is a direct extension of its monopoly Windows PC OS product, and thereby leveraging the Windows monopoly to extend its market control into handhelds. Plaintiff States that have opted not to join in the Microsoft settlement ("the Litigating States") approached Palm in an effort to remedy through their own proposed relief Microsoft's potential anticompetitive conduct that, under the RPFJ, could eliminate the threat posed by the handheld industry. Palm has agreed to testify in Track 2 in support of the Litigating States' proposed relief ("the Litigation States' Remedies"). Palm respectfully submits that the Litigating States' Remedies, unlike the RPFJ, protect competition in mobile computing industry as well as the competition that industry will provide to the PC OS monopoly. The RPFJ fails to create the market conditions necessary for competition to thrive. The structure and terms of the RPFJ are rooted in the computing industry as it existed in the mid-1990s, when the Internet was only beginning to gain widespread consumer use and software development was still focused on the PC. To be effective, the remedy must take into account the industry as it exists today, and the new emerging threats against which Microsoft could (and, if left unchecked, will) repeat its pattern of anticompetitive behavior. The focus of competition in computing has shifted from the PC to the Internet, the server and to new devices such as handhelds. Microsoft's .NET initiative is an acknowledgement of this change, and the fact that it is being driven into virtually every Microsoft product highlights its significance. The RPFJ completely ignores this, and other, crucial dynamics. As products that manage users' information, handhelds must interface with the OS and applications on a customer's PC. When that PC is part of a larger network (as it is in nearly every corporate or "enterprise" scenario), handhelds must also interface with the software on the network, typically resident on a server,5 In order to interoperate effectively with Microsoft products, handhelds must, at the very least, be able to:
In short, Palm and other handheld manufacturers must know the "commands" (to access the data) and the "data formats" (to understand the data) with respect to the target PC or server in order to develop the necessary conduits to interoperate with the target. In most cases (and nearly all business situations), in addition to interacting with the PC OS, the handheld device interoperates with Outlook or Exchange information (such as e-mails, contact information, and calendars), Word and Excel documents on the PC or other databases on the server. The RPFJ fails to ensure that anyone other than Microsoft will be able to interface with Outlook, Exchange, software on corporate servers, other PC applications such as Office, middleware for distributed or web-based applications or even the PC OS itself. Specifically, Sections III.D and III.E of the RPFJ do not address the potential threat (as articulated by Mr. Gates in his e-mail cited supra) that Microsoft can constrain or eliminate competition in and from the handheld industry by regulating the access to technical information necessary for interoperability.7 In general, the RPFJ does not require any disclosure of technical information regarding the interface between Microsoft's PC or server products and handheld products. For example, the section neither requires disclosure of server APIs, nor information regarding the interfaces between PC OS or middleware and server applications. Moreover, the RPFJ also permits Microsoft to foreclose access to critical interfaces that it migrates from the PC OS to the applications or "distributed" environment on a network (and in the case of .NET services, to the Internet) by limiting the disclosure requirements to the APIs between the PC OS and middleware, and the communication protocols between the PC OS and the server OS.8 The RPFJ does not require disclosure of the commands and data formats necessary to interface with the critical applications on the PC, such as Outlook, Office or Internet Explorer. In addition, Microsoft can create proprietary .NET APIs that work only with the Pocket PC OS, bundle them with Microsoft's Visual Studio software development environment, discussed infra, and encourage the development of web services and applications that can be accessed only through Microsoft's OS products.9 Finally, the RPFJ is silent regarding the interfaces between handhelds and software that resides on the servers. In a networked environment, such as corporate networks, handhelds need to exchange data particularly with software on servers.10 For example, without access to data on Microsoft Exchange (the server application product that complements the client e-mail and calendar application Microsoft Outlook), non-Microsoft handhelds cannot offer features offered by Pocket PC products. The Definitions of "Operating System," "Windows Operating System Product" And "Personal Computer" Are Fatally Flawed. The definition of "operating system" specifies code that executes on a PC. Microsoft can evade this definition simply by moving code off of the PC and onto a server or other device. Microsoft's .NET architecture even facilitates this scheme. The definition of "Windows Operating System Product" determines the scope of Microsoft's disclosure obligation. The definition itself, however, leaves Microsoft free to determine in its sole discretion what software code comprises a "Windows Operating System Product." In other words, Microsoft's disclosure obligation is subject entirely to its own discretion. The RPFJ is also undermined by the interaction between the definitions of PC and OS. The definition of PC explicitly excludes almost every new category of device that may compete with PCs in the future, including set top boxes, handhelds, and servers. Because an OS is defined as software running on a PC, competing operating systems running on anything other than a PC appear to be excluded from the RPFJ's coverage. The Definitions Of "Non-Microsoft Middleware" And "Microsoft Middleware" Are Too Narrow. To qualify as competing middleware protected by the RPFJ, software in question must run on the Windows PC OS and must be distributed in at least one million copies per year. The requirement that covered middleware run on the Windows PC OS leaves Microsoft free to retaliate against middleware software that runs on other devices, such as servers and handhelds. The million unit restriction allows Microsoft to target newly-developed middleware that does not yet sell a million units per year. In fact, Microsoft has an incentive to target such middleware before it can grow to a million units and enjoy the protections of the RPFJ. This restriction will stifle innovation by focusing Microsoft's competitive activity against smaller, younger companies -- the companies least able to protect themselves against Microsoft's tactics. Furthermore, as more and more software becomes network-based, the whole concept of "distributing copies of software" becomes irrelevant. It is now possible for very popular software to exist only in a single copy. For example, the Yahoo web service is intensely popular even though it is not copied onto any user's computer. As Microsoft's .NET initiative indicates, the industry is moving towards a web-based services model where consumers access software applications on the Internet. The RPFJ ignores this crucial change in the marketplace. Moreover, to qualify as a middleware product, software must either provide the functionality contained in a short list of products (Explorer, Java, Media Player, Messenger, Outlook Express), or must first be sold separately, have a trademarked name and compete with qualifying non-Microsoft middleware. Missing from the list are a large number of Microsoft monopoly products which have already become "platforms" with which Microsoft competitors have to interoperate. These products include Microsoft Office, full Microsoft Outlook (as opposed to just the Express version), Microsoft Exchange, Microsoft Visual Studio, and Microsoft .NET. Because the RPFJ excludes these products from the middleware definition, Microsoft is left free to manipulate its interfaces and APIs to exclude competitors. This gap alone is enough to render the RPFJ almost completely ineffective. Under the RPFJ, Microsoft can avoid the provision regarding middleware simply by not trademarking the product name. According to this definition, many Microsoft products currently in the market would fail to qualify as middleware. Furthermore, to qualify as middleware software must include user interface code; Microsoft can avoid this by simply distributing the user interface code separately. Version numbers are also used to determine which software updates are covered; if the whole number or first decimal of the version number does not change, the software does not qualify. It appears that Microsoft could evade the middleware definition simply by changing its software numbering scheme (for example, moving to letters - version a, version b, etc.). The RPFJ's Failure To Define "Interoperate" Creates A Significant Loophole. Neither Section III.E nor any other provision of the proposal defines "interoperate." This omission invites Microsoft to enable non-Microsoft products to continue to function but in a much less robust way than Microsoft's handheld products, to the detriment of consumers. The Definition Of ISV Is Too Narrow. The definition of ISV covers only companies creating software that runs on the Windows PC OS. Many current and future Microsoft competitors create software that needs to access information on PCs but does not run on the PC itself. As more and more software development becomes web-based, it will be the norm for competing software not to run on the PC. The RPFJ does not protect these emerging competitors. The Definition Of APIs Is Too Narrow. Under Section III.D of the RPFJ, the disclosure is narrowly limited to "APIs and related Documentation." Microsoft can circumvent this provision by hard-wiring links to its applications and through other anticompetitive coding schemes. The RPFJ ignores Microsoft's control over application development tools, and how Microsoft can use that control to foreclose competition from third parties. The applications barrier to entry was the linchpin of this case and the RPFJ ignores how Microsoft can use development tools to perpetuate it. For example, Microsoft's Visual Studio product has, as a result of Microsoft's PC OS monopoly, become the software development tools standard for most corporate and commercial application programmers, including prospective developers of software for mobile devices. As handheld technology increasingly displaces PC functionality, more and more PC OS developers have been seeking to create mobile software. Nevertheless, Microsoft has, up to this point, denied Palm access to the Visual Studio Integration Program,11 despite Palm's significant position in the handheld space.12 Microsoft's exclusion of third parties such as Palm from Visual Studio has the following adverse effects. Exclusion makes it impossible for Visual Studio users (the vast majority of PC ISVs) to create Palm OS applications without changing the programming tools they use -- an unlikely proposition. This, in turn, makes it more difficult for Palm to recruit software developers. Exclusion also makes it very difficult to sell Palm OS handhelds to corporations, because Visual Studio is very often the standard for their in-house developers. Lastly, exclusion allows Microsoft to claim that Palm OS handhelds are incompatible with corporate standards. The net effect of these restrictions discourages PC ISVs from supporting non-Microsoft operating systems, and reduces the selection of software available to users of non-Microsoft OS handhelds. Reduced to its essence, Microsoft's predatory developer tool strategy: (1) leverages its PC OS monopoly to create a software "standard"; (2) prevents competitors from accessing that standard; (3) "informs" customers that the competitive products are incompatible with the very same products that Microsoft used to create the incompatibility; and thereby most importantly, (4) limits consumer choice and experience by foreclosing non-Microsoft products as competitive alternatives. The RPFJ is notably deficient in its failure to address the potential for Microsoft to bundle or commingle its products with other dominant Microsoft software. The RPFJ also fails to prevent Microsoft from engaging in anticompetitive pricing to the ultimate detriment of the consumer (e.g., charging less for its Pocket PC OS only when it is licensed as part of a larger bundle). The royalty schedule restrictions in particular appear to be a major threat to legitimate competition. For example, under the RPFJ Microsoft will be able to offer discounts on Windows to a PC OEM that also agrees to sell Pocket PC handhelds, so long as Microsoft offers this same subsidy to all OEMs. This gives Microsoft enormous coercive power to prevent any PC OEM from selling non-Microsoft based devices. The RPFJ does not address Microsoft's ability to obstruct the interoperability of a nonMicrosoft handheld by limiting the consumer's or OEM's ability to install drivers that must sit on top of the OS so that the handheld can communicate with the PC. Website developers specifically develop their products to be compatible with Internet Explorer because of Microsoft's monopolization of the browser market. Thus, Internet Explorer itself has become the ultimate test of Web compatibility for all computing devices, including handhelds. The RPFJ does not remedy Microsoft's ability to use this interoperability with Internet Explorer as a weapon. Microsoft has refused to even consider porting Internet Explorer to Palm OS, despite requests from Palm. Microsoft has, though, ported Internet Explorer to Pocket PC in the form of Pocket Internet Explorer. The disclosure requirements under the RPFJ do not become operative for up to twelve months in the case of interfaces relating to middleware and operating systems, and nine months in the case of interfaces between the PC OS and the server OS. In light of the speed with which the industry moves, these delays will continually undermine the competitive vitality of Microsoft's competitors, which will of course only result in further consumer harm. The timing of the disclosure requirements under the RPFJ is also deficient. When Microsoft releases an OS, the disclosure requirements do not become effective until Microsoft releases a beta test version to 150,000 or more beta testers. Under this standard, Microsoft will not have to disclose the relevant technical information until very close to the public release date of the product, whereas Microsoft's in-house developers working on peripheral software (such as the Pocket PC OS) will have immediate access to the relevant information. Software development can take a year or longer, whereas the last beta cycle may be only a few weeks or months before release. If disclosure does not happen until the last beta cycle, non-Microsoft products will be at a substantial disadvantage relative to Microsoft products. Also, the definition of "timely manner" specifies a beta cycle of at least 150,000 people. Microsoft apparently could evade all OS pre-disclosure requirements by limiting its beta programs to 149,999 participants. The RPFJ contains no prohibition against Microsoft's intentional interference with the performance of non-Microsoft products by manipulating the interfaces with non-Microsoft products. Without such a restriction, Microsoft can eliminate the effectiveness of the disclosure requirements by altering the interfaces or other information on which non-Microsoft products rely. Microsoft Retains Control of Desktop Innovation. Because of the RPFJ's restrictive definitions of middleware, Microsoft retains control of desktop innovation by being able to prohibit OEMs from installing or displaying icons or other shortcuts to non-Microsoft software, products and/or services, if Microsoft does not provide the same software, products and/or services. This undermines the OEMs' ability to differentiate their products, and stifles the emergence of new competitors to Microsoft. The RPFJ's Non-Retaliation Restrictions Are Ineffective. Section III.F attempts to prohibit retaliation against companies working with competing products, but the narrow definitions of "operating system" and "personal computer" make it unclear whether Microsoft is prohibited from retaliating against companies that work with competing handhelds, set-top boxes, servers or Internet software infrastructure. This ambiguity, plus Microsoft's ability to threaten retaliation even when it is prohibited from carrying out the threats, will make it extremely uncomfortable for any PC OEM to contemplate working with any non-Microsoft product. Under Section III.A, Microsoft is free to "threaten" to retaliate in any form. Further, Microsoft is constrained only from the specified forms of actual retaliation, a remedy further weakened by the fact that the protected OEM activities are narrowly and specifically defined. Retaliation against an OEM for installing a non-Microsoft application that does not meet the middleware definition is not prohibited; nor is retaliation against an OEM for removing a Microsoft application that does not meet the middleware definition. As noted above, the definitions are so narrowly drawn that the protection of the RPFJ will not apply in most competitive situations Microsoft is likely to encounter in the future. Microsoft could, for example, retaliate against a PC OEM for selling handhelds based on the Palm OS. Add/Remove Provisions Relate Only To Icons. Not The Middleware Itself. The add/remove provisions in the RPFJ only allow for removal of end user access to Microsoft middleware, not the middleware itself. If Microsoft's middleware remains on PCs, then applications developers will continue to write applications that run on that middleware, reinforcing the applications barrier to entry that is at the heart of this litigation. Non-Microsoft Icons Should Not Be Subject To Add/Remove. The RPFJ allows Microsoft to demand inclusion of non-Microsoft icons in the add/remove utility, which does not make sense in the absence of any finding that the permanence of non-Microsoft middleware icons on the desktop is anticompetitive. Microsoft's competitors should not be treated as if they are equally guilty of Microsoft's anticompetitive behavior. Desktop Most Favored Nation Requirements. Nothing in the RPFJ forbids Microsoft from requiring, especially where the product fails to meet the definition of middleware, most favored nation agreements from the OEMs. These agreements tax OEM efforts to promote Microsoft rivals by requiring that equal promotion or placement be given to Microsoft products, often without compensation. Notification To Developers Only When They Ask. Microsoft can disable competing middleware that fails to meet its requirements without any notice to the middleware developer. The developer is expected to discover the disablement and then request an explanation. Microsoft should be required to disclose in advance any conditions that would cause a competing product to be disabled. Technical Committee And Compliance Officer. As stated above, a Technical Committee of three experts, one of whom will be selected by Microsoft, will monitor Microsoft's compliance with the RPFJ. The RPFJ also obligates Microsoft to have an internal Compliance Officer. However, the RPFJ fails to provide this Committee and the Compliance Officer with effective oversight power. For example, Microsoft employees do not have a confidential mechanism to report violations to the Committee, the Compliance Officer, the Court or the Plaintiffs. Nor does the RPFJ require Microsoft to retain documents regarding topics relating to the business issues in this case. Sanctions. In light of Microsoft's violations so far and the potential for continued serious harm to competition, the RPFJ is deficient in not including a "crown jewel" provision requiring Microsoft to incur substantial liability or divestiture of certain assets in the event of future violations of the RPFJ. For the reasons articulated above, Palm submits that the Court should reject the RPFJ as insufficient to remedy Microsoft's past unlawful conduct and to ensure vigorous competition in the future. In the alternative, this Court should defer ruling on the RPFJ until after the Track 2 proceedings conclude. FOOTNOTES 1 Mobile computers are small computers designed to be carried by the user in a pocket or purse. They perform a wide variety of tasks. Mobile computers include handheld computers and the new, emerging category of smart phones (cell phones that have handheld computing functionality built into them). Mobile computers are also sometimes referred to as Personal Digital Assistants ("PDAs"). 2 Microsoft, of course, also manufactures the Pocket PC operating system ("Pocket PC OS") a rival OS to the Palm operating system ("Palm OS"). 3 As Microsoft admitted in its filings before the Court: "...[A] range of devices other than personal computers such as handheld computers, television set-top boxes and game machines are becoming increasingly capable, providing functionality that consumers used to obtain exclusively from personal computers." (Defendant Microsoft Corporation's Revised Proposed Findings of Fact, at 5 (submitted Sept. 10, 1999) (emphasis supplied)). See also id. at 227, 230 and 235. 4 As discussed below, this "information" could come in the form of APIs, data formats, commands and protocols. 5 As we discuss more fully below, this is particularly true where the software that has traditionally resided on the PC is increasingly being distributed, by design, to various locations over the networked environment. 6 A conduit is a piece of software that interoperates with the handheld and the target PC or server, managing the communication between them. 7 We note that the RPFJ requires even less disclosure than the parallel provision in the Interim Order, which was intended to serve as a remedial bridge pending the previously ordered divestiture. United States v. Microsoft. Final Judgment (D.D.C. 2000) ("Interim Order"). For instance, Section III(b)(iii) of the Court's Interim Order required Microsoft to disclose all APIs, Communications Interfaces and Technical Information (i.e., any and all possible technical dependencies) between (a) software installed on any device (including servers and handhelds) and (b) any Microsoft Operating System or Middleware installed on a PC. 8 Microsoft defines .NET as its "platform for XML web services." .NET Defined, available at http://www.Microsoft.com/net/whatis.asp. The services that .NET offers are a combination of pre-designed applications, some of which come under the rubric .NET My Services or "Hailstorm," and a set of tools designed to allow developers to create web applications which rely on the all-important APIs exposed by Microsoft programs (see discussion of "VSIP" infra). At the core of .NET stands the .NET Framework (for PCs) and .NET Compact Framework (for handhelds). The Framework is Microsoft's answer to the Java runtime environment, with a key difference: It lacks the freedom from reliance on Microsoft's APIs. .NET is important because it extends Microsoft's program interface (that is, Microsoft's APIs) to provide the underpinnings necessary for web-based services and distributed applications that do not reside on the PC and/or handheld. 9 It is Palm's understanding that, absent being forced to by the Court, Microsoft will not make certain of these APIs available at all. Others will be available on terms that essentially force Palm to exit the OS business, thereby reducing it to a device manufacturer implementing Microsoft software. 10 The interface between the handheld and server products can be designed to be "through" the cradle and the PC via the network connection between the PC and the server, or a wireless link directly with the server as in the case of Microsoft's Mobile Information Server ("MIS") technology, to which Palm lacks unhindered access. 11 The Visual Studio Integration Program ("VSIP") is a Microsoft licensing program which enables companies outside of Microsoft to "host" their software development within the Visual Studio tool. Many companies other than Palm have been given entry to the VSIP. If Palm is denied entry to the VSIP, Visual Studio users will find it much more difficult to create software for Palm OS handhelds. 12 Microsoft first engaged in stall tactics by simply not responding to Palm's request for participation in the VSIP. Then, Microsoft told Palm that the Visual Studio team lacked the resources for Palm to participate (even as it added other companies to VSIP, Palm believes). Next, Microsoft told Palm that it could participate in the VSIP under the condition that Palm adopt Microsoft's proprietary .NET APIs under unacceptable terms that would have "commoditized" Palm's products. This would have extended the applications barrier to entry to the handheld industry by ensuring that applications developers designed their products not for the Palm platform but for Microsoft's. Ultimately, Microsoft's conduct would have eliminated Palm as a competitive platform. Only recently has Palm received an "offer" to join the Visual Studio without adopting .NET, which Palm believes is due to Microsoft teaming that Palm is testifying in the Track 2 proceedings, i.e., only when Microsoft concluded that its behavior would be subject to judicial scrutiny (and after 18 months of delay). Palm is currently evaluating the terms offered by Microsoft.
While I was at the Allen and CO conference I met with Jurma Oillie CEO of Nokia. I was totally confused by them licensing their WAP browser to Spyglass. It's a disaster for us to have an effort that is duplicative that we give away while the leaders in the industry move in their own direction. I think the PDA group needs some better strategic think in this whole cheap browse area. How come we don't merge our effort with Nokia? Why do we let Spyglass undermine us IN so many areas? Who keeps paying money Spyglass? I am also completely confused about why we aren't doing more due diligence on GPRS with Nokia and others. Jurma seemed very surprised when I told him our goal was to fund someone to roll out a nationwide wireless network using HDR or GPRS as quickly as possible to create something a based on Windows CE. He said his people need to explain to use how GPRS is a much better choice. They would love to help get involved in rolling this out with some partners. He rays HDR or another fraud from Qualcomm where exaggeration sways people who don't hear both sides of the story. Jurma was asking about our strategy for voice recognition servers to make PDAs work a lot better. He sees all networked PDAs as needing. a voice recognition, server infrastructure (like phones) and that this changes the UI quite a bit I said I agreed with his view and that we had not factored that into our plans right now. We talked about how voice and screens will come together. l said there were a lot of key scenarios that we our PDA group was parenting around (I wish our activity level here was really as high as I suggested to him). Jurma also wanted to know what sort of strategy we had to bring Hotmail Contact lists/Schedules together with Exchange. They use Exchange internally but a lot of their people use Hotmail and don't understand what we are doing., Jurma told me their Fenix project is delayed because of a key chip so it won't ship until March 2000 so they don't want to announce at Telcom where I am going. He talked about how much money people spend on their booths at Telcom. I am a bit confused about what we should be doing on wireless data/pbx with various vendors. Why wouldn't we want to have a Windows PDA to work with each of their wireless PBX solutions? Jurma talked about how he is thinking perhaps Cisco or Lucent may buy Ericsson if it doesn't get straightened out fairly soon. He also thinks someone will buy 3Corn. We talked about how we view Palm as a competitor. I was amazed at the number of Palm Pilots I saw at this conference. We really need to follow up with them on GPRS rapidly and get their best thinking given our goals. We really need to demonstrate to people like Nokia why our PDA will connect to Office in a better way than other PDAs even if that means changing how we do flexible schema in Outlook and how we tie some of our audio and video advanced work to only run on our PDAs.
| |||||||||||||||||||||||||||||||||||||||
| MSCE 0097924 CONFIDENTIAL | |||||||||||||||||||||||||||||||||||||||
| | |||||||||||||||||||||||||||||||||||||||
| |||||||||||||||||||||||||||||||||||||||
| There is a lot of stuff here. I will try to answer line by line.
--Original Message--
While t was at the Alien and CO conference I met with Jurma Ollila CEO of Nokis. I was totally confused by them licensing their WAP browser to Spyglass. It's a disaster for us to have an effort that is duplicative that we give away while the leaders in the industry move in their own direction. I think the PDA group needs some better strategic thinking in this whole cheap browser area. How come we don't merge our effort with Nokia? Why do we let Spyglass undermine us in so many areas? Who keeps paying money Spyglass? I am also completely confused about why we aren't doing more due diligence on GPRS with Nokia and others. Jurma seemed very surprised when I told him our goal was to fund someone to roll out a nationwide wireless network using HDR or GPRS as quickly as possible to create something a based on Windows CE He said his people need to explain to use. how GPRS is a much better choice. They would love to help get involved in roiling this out with some partners. He says HDR is another fraud from Qualcomm where exaggeration sways people who don't hear both sides of the story. Jurma was asking about our strategy for voice recognition servers to make PDAs work a lot better. He sees all now voice PD as needing a voice, recognition server infrastructure (like phones) and it this changes the UI quite a bit. I said I agreed with his yew and that we had not factored that into our plans night now. We talked about how voice and screens will come together. I raid there were a lot of Key scenarios that we our PDA group was parenting around (I wish our activity level here was really as high as I suggested to him). Jurma also wanted to know what sort of strategy we had to bring Hotmail Contact lists/Schedules together with Exchange. They use Exchange internally but a lot of their people use Hotmail and don t understand what we are doing. Jurma told me their Fenix project is delayed because of a key chip so it won't ship until March 2000 so they don't want to announce at Telcom where I am going. He talked about how much money people spend on their booths at Telcom. I am a bit confused about what we should be doing on witless data/PBX with various vendors. Why wouldn't we want to have a Windows PDA to work with each of their wireless PBX solutions? MSCE OO97925 Jurma talked about how he is thinking perhaps Cisco or Lucent may buy Ericsson if it doesn't get straightened out fairly soon. He also thinks someone will buy 3Corn. We talked about how we view Palm as a competitor. I was amazed at the number of Palm Pilots I saw at this conference, We really need to follow up with them on GPRS rapidly and get their best thinking given our goats. We really need to demonstrate to people like Nokia why our PDA will connect to Office in a better way than other PDAs even if that means changing now we do flexible schema in Outlook and how we tie some of our audio and video advanced work to only run on our PDAs. MSCE 0097926
Forgot one thing: We absolutely need to go after other PBX manufacturers and develop the market independently of what Nokia can or cannot do.
--Original Message--
There is a lot of stuff here. I will try to answer line by line. --Original Message--
While t was at the Alien and CO conference I met with Jurma Ollila CEO of Nokis. I was totally confused by them licensing their WAP browser to Spyglass. It's a disaster for us to have an effort that is duplicative that we give away while the leaders in the industry move in their own direction. I think the PDA group needs some better strategic thinking in this whole cheap browser area. How come we don't merge our effort with Nokia? Why do we let Spyglass undermine us in so many areas? Who keeps paying money Spyglass? I am also completely confused about why we aren't doing more due diligence on GPRS with Nokia and others. Jurma seemed very surprised when I told him our goal was to fund someone to roll out a nationwide wireless network using HDR or GPRS as quickly as possible to create something a based on Windows CE He said his people need to explain to use. how GPRS is a much better choice. They would love to help get involved in roiling this out with some partners. He says HDR is another fraud from Qualcomm where exaggeration sways people who don't hear both sides of the story. MSCE OO97925 Jurma was asking about our strategy for voice recognition servers to make PDAs work a lot better. He sees all now voice PD as needing a voice, recognition server infrastructure (like phones) and it this changes the UI quite a bit. I said I agreed with his yew and that we had not factored that into our plans night now. We talked about how voice and screens will come together. I raid there were a lot of Key scenarios that we our PDA group was parenting around (I wish our activity level here was really as high as I suggested to him). Jurma also wanted to know what sort of strategy we had to bring Hotmail Contact lists/Schedules together with Exchange. They use Exchange internally but a lot of their people use Hotmail and don t understand what we are doing. Jurma told me their Fenix project is delayed because of a key chip so it won't ship until March 2000 so they don't want to announce at Telcom where I am going. He talked about how much money people spend on their booths at Telcom. I am a bit confused about what we should be doing on witless data/PBX with various vendors. Why wouldn't we want to have a Windows PDA to work with each of their wireless PBX solutions? Jurma talked about how he is thinking perhaps Cisco or Lucent may buy Ericsson if it doesn't get straightened out fairly soon. He also thinks someone will buy 3Corn. We talked about how we view Palm as a competitor. I was amazed at the number of Palm Pilots I saw at this conference, We really need to follow up with them on GPRS rapidly and get their best thinking given our goats. We really need to demonstrate to people like Nokia why our PDA will connect to Office in a better way than other PDAs even if that means changing now we do flexible schema in Outlook and how we tie some of our audio and video advanced work to only run on our PDAs. MSCE 0097926 | |||||||||||||||||||||||||||||||||||||||