United States of America v. Google LLC. - Part 20: Google’s Android Contracts Are Exclusive

B. Google’s Android Contracts Are Exclusive

1. MADAs Contribute To Exclusivity

779. MADAS are the only way for OEMs to distribute GMS, including the Play Store, on their Android mobile devices. Tr. 779:10–13 (Kolotouros (Google)) (without a MADA, an Android OEM cannot distribute any GMS apps); Tr. 9516:5–7 (Rosenberg (Google)); UPX0557 at -436-37 (If a certain OEM does not sign a MADA, Google will “send them a cease and desist if they continue to ship with GMS without a contract.”).

780. Although MADAs technically give OEMs the option to preinstall GMS on a device-by-device basis, the must-have nature of the Play Store makes this an illusory choice- OEMs need the Play Store to have a viable Android device in the United States, which means OEMs must preinstall GMS and adhere to the MADA's requirements. Supra ¶¶238-244 (§ III.F.2.a.i); Tr. 781:7-11 (Kolotouros (Google)) (OEMS may elect whether to preinstall GMS on a device-by-device basis); UPX0312 at -154 (“I will say that there is value in the leverage that Play provides to get some of the non-critical GMS apps on a phone. What I mean by that, is that OEMs want the Play store on their phone, and in return we are able to get other apps like Google search and [C]hrome... on the phone as a result."); UPX0316 at -906 (“The worst risk to come of [not aligning incentives on the Play store] is that Chinese OEMs and Samsung will no longer need the Play Store for Apps on their phones, which would then weaken the leverage the MADA provides."); id. at -907 (“[L]osing Play protections could lead to a material drop in the value of MADA (and thus, loss of our potential ability to secure search and other apps)[.]”) ); UPX0325 at -850 (“If alternative app stores become a viable distribution channel for developers (ie. reach scale), Play revenue would be at risk, and the MADA would come under pressure. This could weaken our ability to secure distribution of the Google search widget on the device (channeling 60%+ of search revenue on Android in the US), as well as the other 1P services we distribute via the MADA and RSA . . . .”); Tr. 3118:22–3121:21 (Tinter (Microsoft)) (When Microsoft launched the Duo, Microsoft “had to have the Google Play Store on it”—there was no viable alternative Android app store—which meant Microsoft had to sign a MADA.); Tr. 3517:6–25 (Nadella (Microsoft)) (“Google has carrots and it has massive sticks, like one big stick is that we’ll remove Google Play if you sort of don’t have us as the primary browser.”); UPX0163 at -236 (“[A] strong Play Store is a prerequisite for the integrity [of] our MADA agreements,” which protect Search revenues.); Tr. 5727:5–5728:11 (Whinston (Pls. Expert)) (Google “give[s] away the must-have Play Store for free in order to get the MADA signed.” The Play Store is necessary “to have a marketable Android device.”).

781. Thus, virtually every Android smartphone in the United States has GMS preinstalled and therefore is subject to Google’s MADA requirements when sold to consumers, e.g., Google Search widget on the default home screen, GSA preinstalled, and Chrome (defaulting to Google search) preinstalled. Tr. 791:25–792:2 (Kolotouros (Google)) (has not seen any Android OEM smartphone in the United States that does not have GMS preinstalled); id. 815:16–816:1 (is not aware of any Android-compatible Samsung or Motorola devices without the Google Search widget on the default home screen); Tr. 1527:5–9 (Yoo (Google)) (nearly all Android phones sold in the U.S. are subject to both a MADA and an RSA).

782. Through the MADA, Google imposes search preinstallation, placement, and default requirements on all Android devices with GMS sold to U.S. consumers. Supra ¶¶ 235– 252 (§ III.F.2.a).

783. MADAs ensure that valuable home screen space is devoted to Google services (e.g., Search Widget, Play, and Google folder). Des. Tr. 98:1–3, 98:6–10 (E. Christensen (Motorola) Dep.) (Apps on the home screen are potentially easier for users to find.); Des. Tr. 59:18–24 (Ezell (AT&T) Dep.) (the home screen is valuable real estate for apps because it is the first screen users see); UPX0141 at -819 (MADA requires the Google Search Widget, the Play Store, and the Google folder (“[c]ollection of apps”) on the default home screen).

784. Google does not allow OEMs to deviate from the most important MADA obligations, e.g., placing the Google Search widget on the default home screen, or preinstalling Chrome. UPX0608 at -769 (“[W]e never deviate from MADA obligations and Chrome distribution via GMS. No exceptions.”); UPX0318 at -199 (Google’s position during a Samsung RSA renewal negotiation was that the “widget on home screen [requirement] stays in MADA (of course. this is non-negotiable. but Samsung will push harder than ever on it).”); UPX0554 at -915 (“[W]e should preemptively let Verizon and OEM’s [sic] know that if they endeavor to snap the MADA by pivoting search away, we will reject the request.”); UPX0555 at -931 (“[T]the ‘ask’ of the OEM is a reminder or notification that if Verizon comes to them (the OEM) and tells them to ditch the Google search widget and replace it [with] the Bing/AOL search box, the request to not adhere to MADA placement obligations will be denied.”); Des. Tr. 149:2–4, 149:8–10 (Christensen (Motorola) Dep.) (Although Motorola has not requested an exception to the MADA’s preinstallation requirements, the witness did not believe Google would grant such a request if it was made.).

785. The Google Search widget is a manifestation of Google search, supra ¶¶ 153, 155; Tr. 791:3–7, 794:3–9 (Kolotouros (Google)) (explaining that the Google Search widget is part of GSA and that it is a search box users can enter questions in), and “Chrome exists to serve Google search.” UPX1031 at -512.

786. The risk of violating the MADA—and losing the Play Store—protects Google’s exclusivity. T-Mobile had concerns that if it switched search defaults from Google, its devices would not be able to distribute the Google Play Store. Des. Tr. 112:19–113:2, 113:4–16 (Giard (T-Mobile) Dep.). T-Mobile discussed its concerns with Google, but Google would not give T-Mobile a direct answer. Des. Tr. 113:17–115:19, 115:21–116:2 (Giard (T-Mobile) Dep.). T-Mobile has never gotten an answer from Google on whether a device could be GMS-certified if its search provider was not Google. Des. Tr. 116:4–8, 116:10–12 (Giard (T-Mobile) Dep.).

787. The placement requirements for Google’s Search widget and Play Store are nonnegotiable for all OEMs. Tr. 793:24–794:2 (Kolotouros (Google)) (discussing UPX0741 at -799); id. 815:9–22 (“We had, without exception, not granted waivers with respect to the widget or the Play Store, that is correct.”); UPX0741 at -799 (“[L]et me state it more stringently. The widget and Play Store icon are staying.”).

788. Google refused to grant the Duo, Microsoft’s dual-screen Android smartphone, a waiver from the MADA’s requirement that the Google Search widget be preloaded on the home screen. Tr. 9505:20–25 (Rosenberg (Google)). Microsoft, of course, wanted the Duo’s search access points to default to Bing, but to get the Play Store, Microsoft had to sign a MADA and had to put the Google Search widget on the Duo’s homescreen. Tr. 3119:02–3121:2, 3121:25– 3122:25, 3125:16–22 (Tinter (Microsoft)).

789. Although the MADA does not prohibit OEMs from preinstalling a second search widget, Google knows that OEMs are unlikely to do so, at least in part, because it would be a poor user experience. Tr. 1527:24–1528:20 (Yoo (Google)) (discussing UPX0141 at -819 and explaining that a second widget is described as “[a]llowed but not likely” because “OEMs want to sell devices, they want to be competitive[] [a]nd we thought that having two widgets was a little too much, so that OEMs are not likely to put two widgets on a device”); UPX0131 at -250 (2017 deck stating “[a]dditional search widget allowed but unlikely” (emphasis omitted)).

790. Microsoft did not place the Bing search widget on the Duo’s homescreen next to Google’s Search widget because, in part, having two search widgets “would be really confusing” and “wouldn’t be a good product for the user.” Tr. 3126:3–10 (Tinter (Microsoft)).

791. There are no Android smartphones sold in the United States with more than one search widget preinstalled on the default home screen. Tr. 2877:2–2877:7 (Kartasheva (Google)) (agreeing that she has never seen an Android device with two search widgets); Tr. 803:17–20 (Kolotouros (Google)) (not aware of any Samsung or Motorola smartphone sold in the United States at any time that had more than one search widget preinstalled); Tr. 1528:12–20 (Yoo (Google)) (discussing UPX0141 at -819 and stating that he is not aware of any Android smartphone sold in the United States that has two widgets side-by-side on the default home screen). Even when Google agreed to MADA amendments that allow Samsung to remove the Google folder from the default home screen, Google continued to require that the Google Search Widget and Play Store are placed on the default home screen. Tr. 807:22–808:3, 813:2–25, 815:9–22 (Kolotouros (Google)).

792. Samsung’s MADA requires the company to preinstall Chrome. JX0037 at -053 (§ 1.9 defining “Core Applications” to include Chrome), -055 (§ 2.1 requiring Samsung to “preload each device with all Core Applications”) (Samsung MADA (2017)). Samsung also preinstalls S Browser, its first-party browser, on Android devices. Tr. 858:7–12, 939:12–16 (Kolotouros (Google)). Search rivals like Microsoft believed that Samsung was “not willing to ship three browsers on [Android] device[s].” UPX0133 at -811. Accordingly, Microsoft believed that the MADA made it impossible for Microsoft to get the Edge browser with Bing preinstalled on Samsung Android devices. Id. at -811 (“Given [Samsung is] contractually obligated to ship Chrome, shipping Edge would require replacing the Samsung browser. They are not willing to take this dependency now.”); UPX0301 at -646 (“[Samsung is] required to include Chrome on device. This is consistent with our MADA obligations and the standard MADA that G[oogle] has OEMs sign so reasonable to assume Samsung customer MADA has the obligation. Therefore to take Edge they would either need to ship 3 browsers on the device (Samsung browser, Edge, and Chrome) or drop Samsung Browser. 3 browsers is DOA [dead on arrival]. They don’t want that high of an app load (they are still trying to reduce total number of pre-installs) and actually told me they are getting pressure from carriers to drop the number of browser to 1. . . They worry a lot about damaging the Google relationship and how much leverage they have.”).

793. The MADA access points—GSA/widget and Chrome—account for most of the search queries and search revenue generated by Android devices. Tr. 16:19–17:3 (Sept. 19, 2023 sealed PM session) (Yoo (Google)) (emphasizing the leverage to secure GSA and Chrome because those were Google’s highest revenue-generating apps and therefore very important in the context of a finance organization); UPX0146 at -388 (for the major U.S. carriers (AT&T, Verizon, T-Mobile, and Sprint) 67–75% of search revenue comes through GSA and 19–32% of search revenue comes through Chrome); UPX0660 at -369 (redacted% of the search revenue from Android devices with Samsung Client IDs (i.e., governed by Samsung’s RSA) flowed through Chrome and GSA, “i.e., access points [Google gets] via MADA”); UPX1105 at -208 (2018 native spreadsheet at Summary tab, columns I, M, Q, U; the vast majority of search revenue and queries for each Android partner came through MADA access points); UPX0563 at -135 (native spreadsheet at Summary tab, columns E-G, K-M; indicating that between 2014 and 2016 the vast majority of search revenue and queries for each Android partner came through MADA access points).

794. At various times, Google has estimated that ~75–90% of search revenue on Android devices comes through GSA and Chrome. UPX0146 at -388 (for AT&T, Verizon, T-Mobile, and Sprint, Chrome and GSA account for between 85% and 99% of search revenue); UPX0567 at -918 (“Today [approximately March 2017], ~90% of Search revenue for current partners and markets where we will be offering revenue share, is generated by GSA and Chrome, where Google is set as default per MADA[.]”); UPX1108 at -924 (“MADA access points (GSA and Chrome) contribute vast majority of search revenue on Samsung devices”; estimating [redacted]% of search revenue on Samsung comes from Chrome and GSA).

795. In recent years, GSA “became a very prominent destination for users to search on an Android device.” Tr. 19:3–20:14 (Sept. 19, 2023 sealed PM session) (Yoo (Google)); UPX1107 at -732 (“In the US, GSA has grown to dominate as a dist[ribution] search access point, representing nearly [redacted]% of search revenue through the [redacted]” (emphasis omitted)); Tr. 23:4–17 (Sept. 19, 2023 sealed PM session) (Yoo (Google)) (approximately [redacted] of revenue on Verizon Android devices and even more on other carrier Android devices came through GSA, including the search widget).

796. The Google Search Widget alone accounts for 50% or more of search revenue from Android devices. UPX0316 at -906 (“Without MADA, we would not be able to incentivize placement of the Widget, which drives ~50% of search revenue on a device and secures other 1P apps like Chrome and Assistant.”); UPX0150 at -900 (Google Search Widget accounts for an estimated 60% of search revenue on Android devices); Tr. 10187:21–10188:3 (Murphy (Def. Expert)) (agreeing that expert’s own slide shows Google’s Search Widget has overtaken browsers in terms of search volume). As Google acknowledges, the MADA secures this revenue. UPX0131 at -250 (2017 deck stating that MADA “secure[s]” 60% of search revenue).

797. It is possible for users to delete the Google widget or Chrome browser and install an alternative; however, few users do so due to the power of defaults. Infra ¶¶ 868–874 (§ VI.D.1).

2. RSAs Contribute To Exclusivity

798. Search default exclusivity with Android partners has long been the “primary goal” of Google’s RSA. Tr. 332:12–334:1 (Barton (Google)) (obtaining the exclusive search default is RSA’s “primary goal”). As explained by Christopher Barton, a former Google employee who negotiated the early RSAs with Android partners during his time at Google (2004–2011), exclusivity for search defaults was a “standard part” of Google’s revenue share requirements. Tr. 312:25–313:12, 325:9–24 (Barton (Google)) (testifying about “always” dealing for default exclusivity in exchange for revenue share).

799. Google’s “philosophy” is to pay revenue share in return for search default exclusivity. Tr. 346:16–24 (Barton (Google)) (reviewing UPX0134 at -869); UPX0134 at -865 (“We need to incentivize carriers to ship Google by using the same approach we at Google have used for many years: ‘We will pay you revenue share in return for exclusive default placement.’ This contract is an exchange. . . Without exclusivity, we are not ‘getting’ anything.”). As Arjan Dijk, who worked at Google for more than a decade before joining Booking.com, explained: “[I]t was clearly understood [at Google] that being the default is almost everything, because when you’re the default 95 percent of people will stick with the default. Maybe 5 percent of people will opt out. And that kind of realization was very clear.” Tr. 5282:25–5283:4, 5283:11– 24 (Dijk (Booking.com)); id. 5329:21–5330:6 (“I [ran] a growth marketing team, together with behavioral scientists, that we would look at, you know, the power of defaults and what we could do to really make sure that Google would be preferred.”).

800. Google views “[a]ny deal which invests in devices that do not have Google Search as default (where available) is a waste of time and money.” UPX0088 at -356.

801. For distributors to maximize RSA payments, Google requires that the distributors set Google as the default on all search access points and prohibits distributors from preinstalling any general search rival. Supra ¶¶ 253, 259.

802. Through the RSAs, Google gets “[o]ut-of-the-box search defaults and exclusivity,” which prevents rivals from accessing default distribution on Android devices covered by RSAs. UPX0129 at -906; Tr. 837:5–25 (Kolotouros (Google)) (In the RSA’s deviceby-device tier, OEM RSAs require Google to be set as the default on all search access points and “out of the box exclusivity with respect to pre-loading.”); Des. Tr. 79:10–13, 80:7–81:3, 81:5–8, 81:11–13 (Levine (Google) Dep.) (The main value of the carrier RSAs was revenue in exchange for the carrier assuring that “Google Search . . . was the only search product promoted by the carrier out of the box.”); UPX0317 at -176 (Google gets “Device exclusivity + Defaults” from the RSA with “Top Carriers and OEMs.”); UPX0574 at -945 (having “Mobile Rev Share Partners” with OEMs like Samsung means “[a]ll devices have search exclusivity (for pre-install and default search)”); id. at -952 (“A[n] redacted% OEM rev share can be offered to gain search & output-based exclusivity, along with expanded default settings with strategic partners[.]”); UPX0580 at -945 (The “[r]ationale in support of the [Samsung RSA] proposal" includes "Google as default search/exclusive search.")).

803. RSAS allow Google to protect search access points not covered by the MADA, such as secondary browsers (i.e., browsers other than Chrome). All the major RSAs require the partner to set Google as the default on all browsers if the partner wants to maximize revenue share percentage. Supra ¶¶ 253–309 (§ III.F.2.b). Securing the defaults on secondary browsers on Android devices is important to Google. In a 2019 exchange regarding the Samsung RSA, Mr. Kolotouros and Mr. Yoo analyzed the implications if they viewed all of Google's payments to Samsung under its RSA as being made in exchange for the default on Samsung's S Browser. UPX0165 at -226. They found that Google's payments to Samsung [redacted]. Id. ("For a while now, we have been [redacted]"). Id.

804. The exclusive defaults secured through Google's MADAs and RSAs cover roughly 19.4 percent of all general search queries in the United States. Tr. 5763:14–22 (Whinston (Pls. Expert)) (explaining UPXD104 at 36, which attributes 19.4% share to Android).

805. Android partners have pushed back on the RSAs' exclusivity terms for many years. UPX1026 at -080 (Verizon removed the search exclusivity term from a term sheet during negotiations with Google in 2018.); UPX0558 at -045 (“Samsung pushed back strongly on proposed terms for revenue share agreements,” including asking for “no exclusivity requirements.”); UPX0321 at -015 (“T-Mobile asking for a) higher rev share percentage, b) no restrictions on other Assistants/ no exclusivities or defaults, and c) no new security requirements."); infra ¶¶ 822–831 (§ VI.B.4).

806. In 2008, Google was negotiating an early RSA with Sprint. In an email discussing Sprint’s edits to the draft terms, Mr. Barton identified as a “key issue” the threat of removal of exclusive default commitments, noting that without these commitments, Sprint could give rival GSEs the “same level of prominence” as Google. UPX0544 at -628 (“Sprint appears to have removed commitments that Google will be the ONLY default search wherever it is placed. In other words, they could put Yahoo [and] MSN at the same level of prominence (despite the fact that we are paying out revenue share).”); UPX0288 at -765–68 (2008 Google-proposed term sheet with exclusive default search terms); UPX1081 at -066–70 (Sprint deleted exclusive default search terms from Google’s proposed term sheet).

807. Sprint’s attempt to remove the exclusive default commitments was a “key issue” for Google because being the exclusive default was the RSA’s “primary goal.” Tr. 333:20–334:1 (Barton (Google)). Ultimately, the 2008 Sprint RSA included default exclusivity. UPX5533 at -124–25 (Sprint RSA (2008)) (§ 5) (“Default Exclusivity” terms); UPX1080 at -183 (It was “a good thing [Google] negotiated hard since [Sprint] kept changing their story on where search was.”).

808. Google monitors OEMs and carriers to ensure they comply with the RSA prohibitions, including that partners do not make it too easy for users to change their search defaults. For example, in 2018, some Samsung devices allowed users to easily change the S Browser’s search default by selecting from a drop-down menu. UPX0149 at -003. Google notified Samsung that this easy-to-change default violated Samsung’s RSA; Google told Samsung that devices with this feature were not eligible for revenue share. Id. at .001. Complying with Google’s demand, Samsung changed the functionality on its Android devices to ensure a simple drop-down menu would not change the S Browser’s search default. Tr. 856:2–858:4 (Kolotouros (Google)); id. 885:19–888:2 (The RSA prohibited Samsung from permitting its users to change the default using the drop-down menu.); UPX0853 at -652 (“We also need to make sure that by January 31st, they OTA an update so that it does not make the drop-down search default selection permanent.”).

809. Similarly, when LG wanted to incorporate Naver, a South Korean GSE, on its Android devices, Google enforced the RSA’s exclusivity and prevented this. UPX0308 at -852– 53 (2011 emails stating that Google would not pay revenue share if LG gave users a choice between “Google mode” (which would set Google as the default search engine) and “LG mode” (which would set Naver as the default search engine)); UPX0135 at -670–71 (2010 email thread stating that Samsung would remove Naver from an Android tablet it planned to manufacture for a South Korean carrier because having Naver on the device would violate Samsung’s RSA with Google and cost the OEM revenue share on that tablet).

810. By obtaining default exclusivity on Android devices, Google excludes rivals from accessing an important search distribution channel. Tr. 899:6–900:1 (Kolotouros (Google)) (discussing UPX0569 and explaining that Google wanted Motorola to enroll as many devices in the RSA’s Premier Tier as possible); UPX0569 at -691 (“[C]ritical to the Moto/Lenovo deal is knowing that we are buttoned up so that high-value devices/countries cannot be carved-off and we don’t lose tablet volume as well.”); Tr. 340:24–341:21 (Barton (Google)) (discussing UPX0134 and explaining that Google sought exclusivity for Android devices because otherwise Google “would have created an ecosystem that basically would just lead to a bunch of searches on competing services”); id. 324:11–21 (Google asked for exclusivity because “[it] wanted to be the partner that [carriers and OEMs] would select as opposed to our key search competitors with regards to being the default search exclusive partner.”); UPX1077 at -001, -004 (“Microsoft and Amazon pursuing distribution deals on devices not covered by RSA,” e.g., “Bing is a default search on Xiaomi & Vivo in India”).

811. Google has long recognized that its RSAs excluded competitors from gaining a foothold on Android devices and it has sought to use its RSAs for that purpose. Tr. 324:11–21 (Barton (Google)). As one Google document put it, “[r]ev shares protect [the] Golden Goose (Google.com on Android).” UPX0541 at .005.

812. In 2011, Mr. Barton recognized that “Android is by far the greatest opportunity for Search monetization in mobile over the next years and is very strategic to Google.” UPX0134 at -865; Tr. 339:4–340:19 (Barton (Google)) (discussing UPX0134 and explaining that Android combined with other Google products “would create an opportunity that would be orders of magnitude, lead some orders of magnitude, more searches, and more search ad monetization per device, more than predecessor devices”).

813. Mr. Barton told his colleagues that Google seeks to make RSAs “exclusive across all Android devices,” so that Android devices “will come with Google as the only search engine out-of-the-box.” UPX0134 at -869. He explained the importance and purpose of exclusivity: “Without the exclusivity, we are not ‘getting’ anything. Without an exclusive search deal, a large carrier can and will ship alternatives to Google (as seen with Verizon, AT&T, and America Movil).” Id. at -865. He further explained: “[Without exclusivity,] Bing or Yahoo Can come and steal away our Android search distribution at any time, thus removing the value of entering into contracts with them. Our philosophy is that we are paying revenue share *in return for* exclusivity.” Id. at -869.

814. In 2020, when Google was negotiating new RSAs with U.S. carriers, Jamie Rosenberg, then VP of Business and Operations for Android, posited that if Google lowered the revenue share paid to carriers, then rivals might be able to obtain distribution on Android phones by outbidding Google. UPX0150 at -900; Tr. 2859:5–8 (Kartasheva (Google)) (discussing UPX0150).

815. Anna Kartasheva, who supported the Android business development teams and worked on restructuring the RSAs, reassured Mr. Rosenberg that lowering the revenue share would not put Google at risk of losing the search exclusivity it achieves with the MADAs and RSAs. UPX0150 at -900. Ms. Kartasheva explained that search exclusivity is well protected because “MADA protects the [Search] widget on the device (60% of the revenue)” and the “Samsung RSA ensures Chrome is in hotseat/set as default browser on carrier devices as well (30% of the revenue),” leaving only 10% of search revenue that “would be not protected on carrier devices in the absence of [carrier] RSA[s].” UPX0150 at -900 (emphasis omitted). She further stated, “This leaves, in the pretty generous case, only about 10% of the search revenue of [an Android] device to any rival who wants to buy [Google] out.” Id.

816. Ms. Kartasheva further explained that she believed a rival “would have to give up at the minimum, 150% of their monetization” to outbid Google for the remaining search access points still available after a carrier deal. UPX0150 at -900 (emphasis omitted).

817. At trial, Ms. Kartasheva sought to recant the analysis in her 2020 email to her boss. However, Ms. Kartasheva conceded that even correcting for the alleged errors in her analysis, a rival search provider could bid for only 20% of the search revenue on an Android device. Tr. 2869:25–2870:6 (Kartasheva (Google)) (discussing UPX0150 and how the percentages in the numbered listed at the top of -900 might change if she corrected for alleged errors). Moreover, she acknowledged that figures similar to those that she reported in her 2020 analysis appeared in other contemporaneous Google documents and admitted that she believed her analysis to be accurate at the time she sent it to her boss. Tr. 2865:15–23 (analysis accurate) (Kartasheva (Google)); id. 2874:14–17, 2875:5–2876:17 (similar contemporaneous figures in UPX0131 at -250); UPX0131 at -250 (MADA “secure[s]” 60% of search revenue).

3. MADAs And RSAs Are A Belt-And-Suspenders Strategy To Exclude Rivals From Accessing Search Distribution

818. MADAs and RSAs work together as a belt-and-suspenders strategy for excluding search rivals from distribution on Android devices. UPX0573 at -244 (The “incremental benefits” of offering revenue share to carriers “over MADAs with OEMs” are to “take a much needed belt and suspenders approach to our Search and Play contracts to include both OEM’s and carriers. . . While the MADA is essential to set the foundation with OEM’s, the carriers could potentially overrule the OEM placement by placing considerable pressure on said OEM’s, leveraging the fact that those carriers are buying the OEM devices, after all.”); UPX0645 at -303 (Adding the RSAs, on top of the MADAs, “provides a way to safeguard search defaults.”); UPX0158 at -115 (“[W]e secure distribution through three mechanisms. MADA ensures access, RSA optimises access points, and Aftermaket complements the two.” And the RSA is an “[i]nsurance policy that preserves our search and assistant usage.”); Tr. 321:18–322:1 (Barton (Google)) (Google negotiated search distribution contracts with both carriers and OEMs because sometimes the carrier decides whether Google search goes onto a mobile device, and sometimes the OEM decides.).

819. Google’s economic expert Prof. Murphy agreed that (1) Google buys protections on Android devices through a combination of the MADA and RSA, and (2) OEMs and carriers both consider the agreements that the other has with Google when entering into its own agreements. Tr. 10173:12–10175:11 (Murphy (Def. Expert)) (Google buys protections on Android devices “in two chunks”—“some through the MADA” and “the rest through the RSA.”); id. 10175:14–19 (conceding expectation that when Google sets the RSA percentage for carriers, it considers the prior agreement and what they’ve already got in the MADA); id. 10184:25–10185:19 (OEMs consider the add-on net benefits of signing the RSA when they consider signing the MADA.).

820. When carriers decide whether to sign an RSA with Google, they do so against the backdrop of the OEM’s MADA, which ensures that GSA and Chrome will be on the device regardless of what the carrier decides. Tr. 1516:24–1517:10 (Yoo (Google)) (discussing UPX0141 and agreeing that although carriers do not sign MADAs, the devices sold by carriers are subject to the MADAs of the OEMs that manufactured them); UPX0326 at -850 (Without an RSA in place, only non-MADA access points on Android are available to rivals.).

821. In the case of Android devices sold by U.S. carriers, no one party (carrier or OEM) can unilaterally decide to move away from Google search defaults, i.e., “if a carrier decided it wanted to just completely ditch Google, it can’t because the OEM has agreed to a MADA.” Tr. 5714:15–5715:17 (Whinston (Pls. Expert)). Similarly, if the OEM wanted to replace Google, it can’t because the carrier has agreed to an RSA. Tr. 5714:15–5715:17 (Whinston (Pls. Expert)).

4. Google’s Agreements Prevented Verizon From Preinstalling The Yahoo Search App On Its Android Devices

822. During negotiations leading up to Verizon’s 2021 RSA, Google refused Verizon’s request to preinstall the Yahoo search app and still qualify for the top (Preferred) RSA tier. Supra ¶ 276; UPX0495 at -003–04 (Google dropped the revenue share to only [redacted]% if Yahoo general search was preinstalled, which Verizon executives described as “punitive.”); Tr. 1065:2– 6 (Higgins (Verizon)); 1075:14–21 (Higgins (Verizon)) (Google refused to provide a carveout in the 2021 RSA that covered Yahoo’s general search functionality with no impact to the revenue share.). Verizon bought Yahoo in June 2017. Tr. 1043:14–18 (Higgins (Verizon)).

823. In Verizon’s 2014 RSA, the prohibition on preinstalling alternative search services had been inadvertently removed from the executed agreement. Tr. 9356:3–14, 9356:24– 9357:12 (McCallister (Google)); UPX2093 at -398 (“[I]n previous amendments . . . the exclusivity provision was removed (!!) so we are paying Verizon [redacted]% for basically nothing right now. . . [T]he highest priority is re-securing exclusivity.”).

824. During RSA negotiations in 2018 and 2019, Verizon “argu[ed] vigorously” to keep the contract non-exclusive. UPX0642 at -198; UPX1026 at -080 (Verizon removed the search exclusivity term from a term sheet during negotiations with Google in 2018). Google refused. Under the 2021 RSA, Verizon earns [redacted]% revenue share if Google has search exclusivity (the Preferred Tier), but only earns [redacted]% revenue share if it preinstalls an alternative search service (the Core Tier). Supra ¶¶ 276, 278.

825. Verizon secured a limited carveout in the Preferred Tier that allowed Verizon to preinstall the Yahoo Mobile App with web search functionality as long as Verizon owned Yahoo, placed the app on the plus one screen or device app tray (not the home screen), and made sure the app “didn’t allow a punch-out into general search.” Tr. 1094:19–1095:15 (Higgins (Verizon)); JX0093 at -500 (§ 5.2(a)(i)) (Verizon RSA (2021)); UPX0293 at -425 (Google’s rationale for allowing Verizon to preinstall the Yahoo home app on the plus one screen included that “[s]earch usage [was] not expected to be materially impacted as long as Google retain[ed] placement on DHS [default home screen].”).

826. Google noted the benefits of giving Verizon a patina of control by “[r]elaxing configuration requirements to allow preloads of alternative Search apps helps ease regulatory risk and reinforces Google’s principle to provide options to users.” UPX0293 at -425.

827. In a 2019 analysis, during RSA negotiations with Google, Verizon looked at the cost of preinstalling the Yahoo Search, assuming Verizon would earn [redacted]% revenue share from Google if Verizon gave Google exclusivity but only [redacted]% revenue share if Yahoo Search was preinstalled. UPX0304 at -606; UPX0290 at -608. Verizon concluded it would cost Verizon over $[redacted] to preinstall Yahoo. Id. (The value of “agree[ing] to Google’s exclusivity terms” and only preinstalling Google Search was $[redacted] (assuming [redacted]% revenue share), while the value of preinstalling Yahoo Search and earning only [redacted]% revenue share was only $[redacted]). From a strictly financial perspective, including Yahoo Search did not make sense under the agreement. Id.

). From a strictly financial perspective, including Yahoo Search did not make sense under the agreement. Id. [redacted]% revenue share as a “punitive” response to Verizon preinstalling the Yahoo Search on its Android devices. UPX0495 at -003; Tr. 1065:2–13 (Higgins (Verizon)) (Google’s insistence on dropping the revenue share to [redacted]% if Yahoo general search was preinstalled was punitive “because of the size of the reduction,” which “seemed large.”); UPX0305 at -781 (“Google is . . . creating new obligations on Verizon that would inappropriately influence decisions we need to make with our business.”).

829. Verizon viewed not being able to set Yahoo as the default search service on Chrome as a significant revenue disadvantage. UPX1130 at -531 (“If we can’t displace Googe search in chrome, then I don’t think we have much – a separate browser with yahoo search will not be able to replace the revenue in Chrome.”).

830. Verizon never preloaded Yahoo Search on any of its devices and ultimately sold Yahoo in May 2021, a month before the 2021 RSA was executed. Tr. 1056:16–18 (Higgins (Verizon)); id. 1072:11–13; JX0093 at -514 (Verizon RSA (2021)) (RSA executed June 2021).

831. In addition to Verizon’s ownership of Yahoo, another reason Verizon sought flexibility in the RSA is because the technology space changes rapidly and Verizon wanted to make sure it was not limiting the capabilities or innovations it could offer to its customers. Tr. 1080:7–14 (Higgins (Verizon)).

5. Google’s Agreements Prevented Branch From Distributing Its App-Search Program On Android Phones

832. Since 2014, Branch’s primary mission has been developing an app-search tool for easily identifying and surfacing app content in response to a query. Tr. 2893:18–2895:6 (Austin (Branch)). Google’s exclusivity agreements prevented Branch from having its app-search tool preinstalled on Android devices without restrictions on its functionality.

833. For several years, Branch sought to partner with OEMs and carriers to distribute Branch’s app-search tool as a preloaded feature on smartphones. Id. 2914:7–2915:10 (Branch chose to partner with OEMs to have its app-search tool preloaded rather than made available as a standalone app available through the Play Store because “[i]t’s very challenging to get anybody to actually go out of their way and use some sort of alternative app or even download a new app.”); PSX00952 (summarizing Branch discussions and meetings with Samsung and U.S. carriers about preloading Branch’s app-search tool). Branch explored distributing its app-search tool through search bars on Android devices but understood that OEMs and carriers had existing agreements with Google on those search access points. Tr. 2897:16–2899:13 (Austin (Branch)) (“[P]retty universally the feedback we would get from prominent, popular search bars was, we have a relationship with Google. We receive large sums of money. And, you know, unless you can compensate for that, we’re not going to use you. And there’s all sorts of restrictions about how the placement would work, et cetera.”).

834. Branch settled on having its app-search tool run on a search bar within an Android feature called the “app drawer” or “app tray.” Tr. 2896:24–2899:13 (Austin (Branch)). On Android, the app drawer provides users quick access to all installed apps. Id. The app drawer has a built-in search bar to filter apps. Id. For instance, using the existing functionality, a user could search for “pizza” and see a list of every app on the user’s phone with “pizza” in its name. Id. 2900:13–2901:8 (explaining DX0612 at .018 and describing user experience without Branch integration).

835. When powered by Branch, that same search for “pizza” would showcase app content. For instance, when a user searched “pizza” in the Branch-powered search bar, the user might see results from restaurant review sites like Yelp, food delivery services like DoorDash and UberEats, travel sites like TripAdvisor, and other apps with content matching the “pizza” query. Id. (explaining DX0612 at .018); DX0612 at .018 (showing example integration of Branch’s technology into the app tray). Clicking on the link would take the user directly into relevant pages within the app (known as a deep link). Tr. 2902:5–14 (Austin (Branch)).

836. Branch’s first and most promising OEM relationship was with Samsung. Id. 2914:7–2915:10. Samsung invested in Branch in 2015; for years Samsung and Branch met to discuss how the app-search tool could be integrated onto Samsung phones. Id. 2907:8–21, 2907:25–2908:4. In 2018, talks between Branch and Samsung executives intensified as the companies worked to launch the tool in March 2019, on Samsung’s flagship device, the Galaxy S10. Id. 2907:8–21, 2907:25–2908:4.

837. In the months before the S10’s release, Samsung grew concerned that distributing Branch’s app-search tool, without changes to its functionality, might conflict with Samsung’s search distribution agreements with Google. Id. 2905:1–19, 2908:6–13, 2919:8–21 (describing Samsung’s concerns and UPX1064 as representative of Branch’s communications with Samsung) ; UPX1064 at -543 (Nov. 2018 email from Junghan Kang (Samsung) to Branch employees explaining, “the gating factor here is the Google-Samsung contract terms and anything that can be claimed by Google as ‘web search’ is something we need to avoid’”); UPX0687 at -078 (2020 chat message from Patrick Chang, asking rhetorically, “Why would [Samsung] turn down a billion a year today with Google for dozens of millions with branch?”).

838. To avoid conflict with the Google agreement, Samsung requested Branch reduce or eliminate functionality on its app-search tool. Tr. 2905:1–19 (Austin (Branch)). Those restrictions drastically limited the usefulness of Branch’s tool and Branch’s ability to monetize it. Id. 2911:12–2912:11; Tr. 4497:20–23, 4498:23–4499:4 (Chang (Samsung Next)) (Branch’s full functionality was not integrated on the S10); UPX0658 at -586 (“OEMs/Carriers are afraid of Google’s influence[.] . . . [Samsung has] [p]laced significant restrictions on Branch functionality (only installed apps, no linking to web)”). For example, although Branch had indexed thousands of apps, Samsung directed Branch to hide results from all but 20 or 25 pre-determined apps; Samsung manually checked each approved app to ensure it was not sending users to websites. Tr. 2910:16–2911:11 (Austin (Branch)); UPX1038 at -753–54 (listing 20 to 25 pre-determined apps permitted by Samsung on S10 launch). As a result, users did not see results from new and popular apps if they were not included in those Samsung pre-selected. Tr. 2954:3–14 (Austin (Branch)).

839. Also, Branch’s app-search tool was not permitted to direct users to websites. Id. 2908:15–2909:2. Although Branch’s default experience was to send users to app pages, companies or users could configure their search results to go to a mobile website instead of an app page if the user had not installed the app. Id. 2909:16–2010:14. For some users, this was preferable to being directed to the Play Store to download an app before using it. Id.; Tr. 4499:5– 15 (Chang (Samsung Next)) (Branch, as implemented through the S-Finder, was limited to a “select number of applications”).

840. Samsung recognized that directing Branch to curb the functionality of its appsearch tool adversely impacted the user experience but felt those curbs were necessary due to Samsung’s RSA terms. UPX1064 at -543 (“[Y]es, I do realize [Branch with certain functionality] is [a] much better experience . . . . However, the gating factor here is the GoogleSamsung contract terms and anything that can be claimed by Google as ‘web search’ is something we need to avoid.”); UPX0690 at -427 (Aug. 2020 chat between Patrick Chang (Samsung) and David Eun (Samsung) bemoaning Samsung’s eventual decision to walk away from Branch partnership stating, “They aren’t thinking about longer term strategy and insuring that we have some functionality outside of Google, in addition to optimizing the user experience”).

841. In response to Samsung’s concerns, Branch developed a feature called “Deepview” to work around Google’s restrictions. Tr. 2915:25–2916:20, 2918:2–11 (Austin (Branch)) (discussing the “Deepview” feature). But again, Samsung raised concerns about violating its RSA; Junghan Kang, Samsung’s product manager for the Branch-Samsung integration, informed Branch that “the gating factor” to integrating a feature onto S10 devices was “the Google-Samsung contract terms” and “[a]nything that can be claimed by Google as ‘web search’ is something [Samsung] need[ed] to avoid.” UPX1064 at -543; Tr. 2921:2–16, 2921:21–2922:9 (Austin (Branch)) (discussing UPX1064).

842. Like Samsung, other OEMs and U.S. carriers expressed concern that Branch’s app-search tool (even with limited functionality) would violate Google’s distribution agreements. Tr. 2922:12–25, 2926:16–2928:12 (Austin (Branch)) (describing discussions with OEMs related to concerns over Google RSAs); UPX0656 at -451 (2020 email exchange between AT&T and Branch employees discussing AT&T’s concerns about Branch’s app-search tool infringing on Google’s RSA requirements); Des. Tr. 278:18–279:3 (Christensen (Motorola) Dep.) (If Motorola were to load Branch’s app-search tool onto its Verizon devices, its devices may fall out of compliance with the RSA’s premier tier requirements); UPX0692 at -4000 (Samsung email discussing push-back from carriers to Branch’s launch on Samsung devices).

843. Branch spoke to every major Android OEM and U.S. carrier but repeatedly heard that RSAs required Google to be the only GSE preloaded on their devices. Tr. 2926:14–2928:12 (Austin (Branch)); id. 2932:5–9 (Branch “talked to every OEM,” after Samsung about integrating its app-search tool.); Des. Tr. 139:21–140:4 (Giard (T-Mobile) Dep.) (T-Mobile was interested in Branch because of its potential to “further improv[e] the customer experience on devices” and “develop[e] a new revenue stream”); Tr. 1112:15–21 (Higgins (Verizon)) (Verizon discussed with Branch “ways in which we could potentially improve the device experience” by incorporating Branch technology onto Verizon’s Android devices); UPX0967 at -778 (email from Comcast executive to Gary Wolfson at Branch, stating Branch’s app-search tool “would create conflict with [Comcast’s] rev share from Google”).

844. Branch was not able to reach a deal with any OEM to distribute the “broad app search” functionality that Branch envisioned could “help a user find information across apps.” Tr. 2932:10–19 (Austin (Branch)). Branch was only able to distribute its local search version, with greatly restricted functionality and monetization, because partners deemed this lower functionality compatible with Google’s RSAs. Id. 2932:10–19 (discussing OEM outreach generally); id. 2933:4–24 (Branch’s deal with Xiaomi permitted Branch’s service to be preloaded on devices that were more than a year old. This still “limited [Branch’s] ability to monetize greatly, “because usually a device a year old is a lot less valuable from an advertising perspective than a fresh device.”).

845. Similarly, Branch was not able to reach a deal with U.S. carriers to distribute tools with the broad app-search functionality, even though the U.S. carriers saw value in Branch’s product. Tr. 2934:6–13 (Austin (Branch)); Des. Tr. 238:9–239:7, 247:1–3 (Ezell (AT&T) Dep.) (before walking away, AT&T discussed “expand[ing] and monetize[ing] Branch’s service already available on Samsung devices); Des. Tr. 139:21–140:4 (Giard (T-Mobile) Dep.) (discussing T-Mobile’s interested in Branch’s technology).

846. Again, Branch understood from carriers that concerns over violating Google RSA terms was a significant roadblock. Tr. 2935:14–20 (Austin (Branch)).

847. Branch spoke repeatedly with AT&T executives who expressed concerns that distributing Branch’s app-search tool would violate AT&T’s RSA. Tr. 2936:1–4 (Austin (Branch)) (“We spend a lot of time talking with AT&T.”); UPX0656 at -451 (AT&T asking Branch executive to confirm that Branch’s app-search tool would not infringe on Google’s search requirements). Branch was never able to move AT&T past those concerns. Tr. 2940:10– 2941:9 (Austin (Branch)) (discussing AT&T’s concerns as expressed in UPX0656); Des. Tr. 247:1–3 (Ezell (AT&T) Dep.) (confirming that ultimately, AT&T did not pursue a partnership with Branch).

848. Although Branch eventually reached distribution deals with Verizon and T-Mobile, those deals only distributed Branch’s app-search tool with reduced functionality. Tr. 2942:14–2943:23 (Austin (Branch)).

849. Google’s RSAs blocked distribution of Branch’s tools, and Google sought to prevent distribution of Branch’s app-search tool, even with its reduced functionality. Infra ¶¶ 850–858. By Spring 2020, Branch and AT&T’s discussions regarding a potential distribution partnership had advanced substantially. As Jeffrey Ezell, Vice President of business development for AT&T’s mobility business unit, explained, AT&T believed there was ambiguity regarding whether Branch’s app-search tool would be considered a competitive search service under the RSA. Des. Tr. 239:8–9, 239:11–240:5 (Ezell (AT&T) Dep.). AT&T tried to ascertain if Branch’s app-search tool was supplemental to or overlapping with general web search; if Google considered Branch’s app-search tool a competing or alternative search service, AT&T could be in breach of its RSA and lose search revenue from Google. Id. 239:8–9, 239:11–240:5, 242:22– 243:18; UPX0656 at -451 (AT&T seeking assurances from Branch that preloading its products would not violate AT&T’s Google Search requirements).

850. In May 2020, after several months of discussions with Branch, AT&T’s Eli Trowbridge emailed Kesh Patel, AT&T’s relationship manager at Google, to ask whether distributing devices with a Branch-powered S-Finder was consistent with the RSA. UPX0982 at -695. Mr. Patel immediately sought additional information about the Branch service, including how the service worked on Samsung phones. Id. at -693–95. Mr. Patel passed the information to his colleagues, including Ms. Kartasheva. Tr. 2790:25–2791:12 (Kartasheva (Google)) (discussing UPX0664 and explaining that her colleagues had relayed a question from AT&T about whether distributing a Branch-powered S-Finder was consistent with the RSA).

851. Upon learning of Branch’s integration into Samsung’s S Finder, Ms. Kartasheva ran on-device searches using the Galaxy S10’s S Finder which, at the time, was powered by Branch’s app-search tool. Tr. 2801:11–2802:2, 2802:15–17 (Kartasheva (Google)). She compared search results on S Finder when the device was connected to the internet with search results when the phone was on airplane mode and determined that, even with the limitations Samsung placed on Branch’s app-search tool, the search results were more robust when the service was connected to the internet. Id. 2801:11–2802:2, 2803:2–2804:12. Ms. Kartasheva concluded that Branch technology conflicted with Google’s definition of the Alternative Search in AT&T’s RSA because Branch conducted off-device searches that returned results across multiple apps. Id. 2802:3–2804:12; UPX0664 at -453–54 (“We have discovered that Samsung Finder in its current implementation (incorporating Branch io API) does appear to conduct offdevice (web) search across multiple apps, which conflicts with our definition of the Alternative Search . . . .”).

852. Led by Ms. Kartasheva, Google sought to prevent OEMs and carriers from distributing Branch’s app-search tool. UPX0664 at -453–54. After meeting with Google colleagues, Ms. Kartasheva shared a set of next steps for the business development teams. Id. at -453–54. First, they would confirm that other major U.S. carriers had language in their RSAs, like AT&T’s, that would allow Google to ask them to discontinue their distribution of Branch’s app-search tool. Id. at -454. Second, they would determine (1) if Samsung had enabled Branch’s app-search tool on Samsung devices globally, and (2) whether Samsung doing so was a breach of its RSA. Id. Finally, Mr. Patel would contact AT&T “specifically to get this resolved” by telling Mr. Trowbridge that Branch’s app-search tool, as implemented, was not permitted on AT&T devices that qualified for a revenue share. Id.; UPX0982 at -686–87.

853. Google employees carried out Ms. Kartasheva’s plan, “pushing back” on OEM and carrier deals with Branch. UPX0694 at -599–600 (“We believe [the S Finder implementation with Branch’s technology] goes beyond the scope of what we originally allowed Samsung (and US carriers) and have started pushing back on them . . . .”); UPX0982 at -686–87.

854. Mr. Patel responded to AT&T’s inquiry about Branch, saying that “search results that pull from ‘Internet content’ in a manner substantially similar to Google” constitute an alternative search service. UPX0982 at -686–87. AT&T understood Google’s position that preinstalling Branch’s app-search tool on AT&T’s devices, using an internet connection as intended, would be violating AT&T’s RSA. Tr. 340:1–341:6 (Ezell (AT&T) Dep.) (“[T]he way it was reported back to me was that Google indicated they felt that it was inconsistent with the RSA.”).

855. After deciding that Branch’s functionality was a threat to Google, Ms. Kartasheva reached out to others at Google, including Adrienne McCallister, then the Managing Director of Global Partnerships, to organize outreach to Samsung and the other U.S. carriers concerning S Finder and Branch technology. UPX0664 at -454; UPX1067 at -799–801.

856. Ms. Kartasheva created and circulated a PowerPoint presentation that explained the Branch “situation,” stating that “Samsung’s partnership with Branch expands the search experience via deep linking, violating their contracts.” UPX0694 at -202; Tr. 2886:3–2887:2 (Kartasheva (Google)).

857. Ms. Kartasheva sought to placate partners dissatisfied by Google’s rejection of Branch. On June 10, 2020, Ms. Kartasheva reached out to a colleague on the Search product team asking if “Google Search [could] do something similar to this” so Google could “pivot the conversation with Samsung and carriers from asking them to take it down, to seeing if Google could power this experience.” UPX0694 at -599–600.

858. Ms. Kartasheva also took steps to ensure that subsequent Samsung RSAs clearly prohibited Samsung from preinstalling Branch’s app-search tool. On a draft RSA term sheet being prepared by Google’s Samsung Business Development team, Ms. Kartasheva commented, “[P]er discussion today on Branch, should we clarify that app search implementation that they have in Samsung Finder is not allowed?” UPX0609 at -629. Google’s Business Development team took Ms. Kartasheva’s comment to heart. Days later, Google sent Samsung a draft RSA term sheet expressly foreclosing Branch’s services: “S Finder (or its successor) and other services which provide on-device search (settings, contacts, etc.) functionality shall not return any results which require a connection to the internet.” UPX2003 at -990, -992; UPX0654 at -795, -798 (email from Christopher Li (Google) to Mr. Kolotouros (Google) discussing language added into the newest RSA iteration preventing preinstallation of Branch functionality that uses an internet connection to return search results). To Samsung, Google’s position suggested that it was afraid that Samsung would use Branch to create a product that would “cannibalize Google’s main business” and Google wanted to “kill all of Branch’s attempts” to preinstall its app-search tool on Android devices. UPX0690 (“Google is afraid of Samsung creating an Apple Spotlight type of search, Vertical Search will cannibalize Google’s main business”).

859. Branch tried to salvage its distribution deal with Samsung by, among other things, developing a completely offline version of its search product. This version lacked core functionality and was a degraded user experience, but only periodically required a connection to the internet. Tr. 2927:2–2930:6 (Austin (Branch)) (describing development of offline search and its further limitations on the functionality of its app-search tool); PSX00075 at -000; UPX0689 at-271-73 (Branch presentation describing offline search).

860. Google's actions successfully dissuaded AT&T and Samsung from working with Branch. After Google indicated to AT&T that preinstalling Branch's app-search tool was inconsistent with the RSA, AT&T chose not to pursue a partnership with Branch because it did not believe that the economic upside from Branch was significant enough to justify the risk to Google revenue share. Tr. 242:22–244:9, 340:1–341:6 (Ezell (AT&T) Dep.) (explaining Google's opinion of Branch's app-search tool, as communicated back to him, and the decision to walk away); id. 247:1–249:12 (“It didn't appear that the economic upside from Branch was significant enough to, you know, potentially put at risk a device not being eligible for our Google Search revenue.").

861. Similarly, Google's 2020 Samsung RSA included terms that effectively blocked Branch from increasing the functionality of its app-search tool on Samsung devices. JX0071 at-394 (§ 1.5) (Samsung RSA (2020)) (defining “Alternative Search Service” as “any web or on- device search service (including on-device search that incorporates multiple vertical search functionalities) that offers functionality that is similar to Google Search”). Samsung understood these terms to substantially constrain its ability to distribute Branch's tools, let alone increase the functionality of Branch's original vision of an app-search tool. UPX0663 at -469 ("The current agreement is looking like google will own all search on device. . . . This will completely kill all potential for any branch search and other future services."). Based on conversations with Samsung, Branch held a similar understanding. Tr. 3069:21-3072:6 (Austin (Branch)) (explaining conversations with Samsung employee and feedback Branch received about Samsung's decision making).

862. Samsung ultimately terminated discussions with Branch about an expanded partnership. Branch’s understanding, informed by communications it had with Samsung executives, was that Samsung did not move forward with “Offline Search” because of its Google agreement. Tr. 2930:17–2931:11 (Austin (Branch)).