Opinion ID: 4076467
Heading Depth: 3
Heading Rank: 1

Heading: PBX Systems and Maintenance

Text: Of the two types of systems at issue in this litigation, the PBX has a substantially larger market. Avaya characterizes PBX systems as durable goods with extended longevity and high fixed costs. During much of the time relevant to this suit, PBX systems had a useful lifespan of about eight years, though some could remain in use for decades.5 They have many capabilities but were sold in a 4 The reasons for the divorce are, of course, like everything else in this case, hotly contested, and they are elaborated in more detail below. Here is a thumbnail sketch: Avaya contends that TLI violated its obligations as an Avaya agent, whereas TLI alleges that Avaya imposed onerous surprise conditions to prevent a partner firm like TLI from recouping the investments it had made at Avaya’s request. 5 Those statistics are based on PBXs sold before 2000. In the 2000s, traditional PBXs were replaced with systems that use internet protocol telephony. Whereas with older “refrigerator-box-type PBXs, it was ... easy to identify and define what a ... life of a system was,” with the “IP PBXs ... any one server might come out of service, perhaps as quickly as after just a couple ... years.” (J.A. 4382.) Given the constant replacement of equipment on those modern PBXs, it is “very difficult to measure” what the lifetime of a system is. (Id.) 9 default mode without most of them activated. Customers could then license individual capabilities, depending on their needs. As one Avaya systems engineer explained it at trial, Avaya “provide[s] software to our customers that’s able to do a vast number of things, but customers don’t want to pay for all the things the software can do. ... They may not need all the capabilities ... . So we allow customers to purchase the right to use aspects of the software ... .” (J.A. 1886.) One of those “aspects” is a set of maintenance features6 that was and is licensed separately from the PBX system itself. Those features are accessed via on-demand maintenance commands (“ODMCs”). Users of the maintenance features – whether Avaya technicians, nonAvaya technicians, or customers themselves – access the pertinent software using login credentials. Each login is matched to the ODMCs that that specific user is authorized to use. In addition to controlling those logins, Avaya has a second way to regulate access to the ODMCs. The ODMCs are only useable on a given PBX system if Avaya has activated the corresponding maintenance software permissions (“MSPs”). Avaya’s PBX systems come with the MSPs disabled, but customers who execute a specific license agreement can have the MSPs, and hence the ODMCs, 6 The use of the word “feature” to describe elements of the software that enabled remote maintenance is legally relevant to questions of contract interpretation in this case. See infra Part II.A.2. We use the word here as a generic term, without implying anything about how it should be read in the specific context of Avaya’s contracts with its customers. 10 enabled. Later, when that license terminates, Avaya disables the MSPs. Avaya and its authorized Business Partners offer maintenance service, which is a profitable line of business. Avaya contends that the “margin on the initial sale of a PBX is ‘thin,’” whereas the rate of profit on maintenance work is much higher. (Opening Br. at 8.) It says that the profit the company earns from maintenance is an important source of funds for the improvement of PBX systems and the development of new models, which are released roughly every two years. According to Avaya, its major competitors in this market – Cisco, Siemens, and Microsoft – follow a similar business model of low-margin equipment and highmargin maintenance, and those firms compete with each other and with Avaya over the “total cost of ownership” of both equipment and maintenance. (Opening Br. at 9.) During the time period covered by this litigation, Avaya offered three tiers of maintenance options for PBX customers. The highest-end, most expensive option was to buy maintenance from Avaya itself, whose technicians had full access to ODMCs and certain other Avaya software capabilities. The second, intermediate, option was to purchase maintenance from an authorized Avaya Business Partner. Business Partners could access a customer’s maintenance software through a login called “DADMIN,” once Avaya activated it on a customer’s PBX. As participants in Avaya’s maintenance program, Business Partners had to complete special training and were given access to engineering support. They also had to agree not to solicit maintenance contracts 11 from existing Avaya maintenance customers. Avaya forthrightly admits that it thus imposed vertical restraints on maintenance through the Business Partner program to encourage the Business Partners to “expand sales of Avaya PBXs in the competitive primary market, rather than simply to cannibalize existing maintenance business.” (Opening Br. at 13.) Finally, Avaya offered a self-maintenance option to its customers. Prior to 2008, customers who undertook to maintain their own PBX systems would have to purchase a license to gain access to the necessary MSPs. In 2005, out of tens of thousands of Avaya PBX customers, about 270 of Avaya’s largest customers used the self-maintenance option, which allowed their in-house technology departments to perform maintenance on their PBX systems. With its 2008 hardware release, Avaya began making MSPs part of the base package for all PBX purchasers, so that they no longer had to pay additional money for access to those maintenance features. They were, however, then subject to heightened contractual restrictions against using independent service providers (“ISPs”).7 ISPs in fact became a fourth source of maintenance for Avaya PBX systems, and – from Avaya’s perspective at least – a very unwelcome one. Avaya has made no secret of its 7 The Avaya expert who testified about the change in policy suggested that the reason for the change was that the features available for purchase on the PBXs had become so numerous that Avaya began including many of them by default. 12 hostility to ISPs, and it acknowledges that it “has never given third parties the logins necessary to access the ODMCs needed to maintain PBXs.” (Opening Br. at 15.) As Avaya characterizes it, prior to 2003, there were no significant ISPs on the market, and they did not become noticeable market players until 2005. At that point, Avaya released an internal July 2005 bulletin affirming that “Avaya ... does not provide maintenance support for clients of or directly to unauthorized service providers” (J.A. 7043), and it recapitulated its policy that MSPs and self-maintenance licensing would not be available to customers who used ISPs. A 2006 federal court opinion rejected an antitrust suit challenging Avaya’s policy against giving ISPs maintenance software access.8 In its campaign against ISPs, Avaya updated its customer agreements in 2008 to make explicit that PBX purchasers agreed not to use unauthorized third parties for 8 See United Asset Coverage, Inc. v. Avaya Inc., 409 F. Supp. 2d 1008, 1046 (N.D. Ill. 2006). That court’s analysis was critical of the kind of monopolization and tying claims now brought by TLI. Because “the software built into Avaya’s PBXs to facilitate their maintenance and repair is proprietary,” the court rejected the argument that maintenance and hardware were separate antitrust markets. Id. at 1045-46. It also rejected the claim that Avaya had surprised its customers with a post-sale policy change, characterizing that monopolization claim as “border[ing] on the absurd” because “[n]o one has an unclouded crystal ball as to future events, nor does anyone have a vested right in the expectation that the future will remain the same as the present.” Id. at 1046. 13 any service that required MSPs. Specifically, one license restriction stated that the Customer agrees not to ... allow any service provider or other third party, with the exception of Avaya’s ... resellers and their designated employees ... to use or execute any software commands that cause the software to perform functions that facilitate the maintenance or repair of any Product except ... those software commands that ... would operate if ... [MSPs] were not enabled or activated. (J.A. 7283.)