ALD Social, LLC v. Apple, Inc.

• Court: District Court, N.D. California
• Decided: July 24, 2023
• Docket: 3:23-cv-02695
• Status: Unknown

Opinion

1 2 3 4 UNITED STATES DISTRICT COURT 5 NORTHERN DISTRICT OF CALIFORNIA 6 7 ALD SOCIAL, LLC, Case No. 23-cv-02695-JSC

8 Plaintiff, ORDER RE: DEFENDANT APPLE’S 9 v. MOTION TO DISMISS

10 APPLE, INC., Re: Dkt. No. 21 Defendant. 11

12 13 ALD Social sues Apple for infringement of two patents directed to systems to detect crowd 14 safety risks and alert emergency personnel of such risks: U.S. Patent Nos. 9,198,054 (“the ’054 15 patent”) and 9,402,158 (“the ’158 patent”). (Dkt. No. 1.)1 Before this Court is Apple’s motion to 16 dismiss. (Dkt. No. 21.) After carefully considering the briefing, and with the benefit of oral 17 argument on July 13, 2023, the Court GRANTS the motion with leave to amend. The documents 18 Plaintiff attached to the complaint are inconsistent with the Accused Product satisfying the 19 Asserted Patents’ “crowd risk determinant” limitation or the ’158 patent’s “location aggregation” 20 limitation. 21 BACKGROUND 22 A. ALD Social’s Patents 23 Plaintiff filed suit against Apple for patent infringement in the Western District of Texas. 24 (Dkt. No. 1.) Both the ’054 patent and the ’158 patent (“Asserted Patents”) are titled “Aggregate 25 Location Dynometer (ALD).” (Dkt. No. 1 at 4.) The ’158 patent is a continuation of the ’054 26 patent. ’158 patent, col. 1 ll. 4-13. Both Asserted Patents’ abstracts describe: 27 1 An Aggregate Location Dynometer (ALD) in a physical wireless network alerts to a problematic crowd risk using location based 2 services (LBS). An Aggregate Location Dynometer (ALD) comprises a Network Monitor, a Crowd Risk Determinant and an Alert Module. 3 The Network Monitor monitors wireless traffic for a potential viral event, associated with a formation of a plurality of wireless devices. 4 The Crowd Risk Determinant requests location information associated with a plurality of wireless devices in a given area 5 regarding a respective viral event. The Crowd Risk Determinant determines if the viral event also indicates a crowd safety risk, based 6 on the shape and movement of observed wireless devices. The Alert Module triggers an alert of an impending crowd problem when crowd 7 risk is above a given threshold. Historical databases are empirically determined and maintained in the Aggregate Location Dynometer 8 (ALD) for use in viral event and crowd risk assessment. 9 ’054 patent, abstract; ’158 patent, abstract. The Asserted Patents elaborate on the significance of 10 wireless devices:

11 The Aggregate Location Dynometer (ALD) analyzes a bird’s-eye view of people formation, presuming those individuals possess 12 respective handheld wireless devices that permit collection of current location information, whether that current location information be 13 obtained from the wireless devices themselves, and/or from a network-based location server. 14 15 ’054 patent, col. 2 ll. 57-63; ’158 patent, col. 2 ll. 61-67. 16 The invention claims a system to track the geographic location of wireless devices and 17 determine whether a particular geographic region represents a “crowd related public safety risk.” 18 ’054 patent, col. 2 ll. 45–col. 3 ll. 26; ’158 patent, col. 2 ll. 49–col. 3 ll. 30. One such risk is a 19 potential viral outbreak when the system detects, e.g., too many wireless devices in one 20 geographical area. Id. More specifically, claim 1 of the ’054 patent states:

21 1. An aggregate location dynometer in a physical wireless network server, said aggregate location dynometer 22 comprising:

23 a network monitor to monitor a wireless network for an indication of a viral event; 24 a location aggregator to obtain a location of each of a 25 plurality of wireless devices associated with said viral event; 26 a crowd risk determinant, triggered by said network 27 monitor, to determine a crowd risk based on an 1 an alert module to initiate an alert message relating to a public safety risk determined from an analysis of said viral 2 event. 3 ’054 patent, col. 9 ll. 10-24. Claim 1 of the ’158 patent states:

4 1. An aggregate location dynometer in a physical wireless network server, said aggregate location dynometer 5 comprising:

6 a network monitor to monitor a wireless network for an indication of a potential viral event indicated by an 7 aggregation of current locations of a plurality of physical wireless devices associated with said potential viral event; 8 and

9 a crowd risk determinant to assess said aggregation of said current locations of said plurality of physical wireless 10 devices pertaining to said potential viral event triggered by said network monitor. 11 12 ’158 patent, col. 9 ll. 18-29. 13 B. Complaint Allegations 14 Plaintiff alleges Apple’s Exposure Notification system (the “Accused Product”) directly 15 infringes, literally and/or under the doctrine of equivalents, at least claim 1 of both the ’054 and 16 ’158 patents. (Dkt. No. 1 ¶¶ 18, 25.) Plaintiff’s complaint attaches claim charts for each patent. 17 (Dkt. No. 1-1 at 35-55.) 18 C. The Accused Product 19 Apple’s product is a “[contact] tracing system that utilizes Bluetooth wireless technology 20 to determine proximity of COVID-19 positive individuals and assess the risk of infection to alert 21 users of this risk.” (Dkt. No. 1-1 at 36, 49.) The system “has the capability to monitor a wireless 22 network through Bluetooth beacon keys to verify and store COVID-19 positive case information, 23 and once validated, send indication of the positive cases to users through a wireless network.” Id. 24 Apple’s system can “determine exposure risk value based on risk parameters including but not 25 limited to exposure proximity and duration.” Id. at 42, 53. 26 Plaintiff offers the following illustrations of the Accused Product: 27 1 Public health authority User Verification server User iPhone Key server

RP E i = Request verification code 3 «< Sends verification Enters verification 4 code code to iPhone Verification code 5 exchange 6 Sends exposure key data 7 Receives certificate Validate certificate and metadata and metadata -----N 8 Permission Permission to : granted upload keys 1 . ~«----/ 9 Upload keys, token : certificate and metadata Validate, stored for 10 other users

Alice and Bob don't know each other, but Bob is positively diagnosed for COVID-19 a 12 have a lengthy conversation sitting a few and enters the test result in an app from feet apart his public health authority 13 i) = Ss TY | \ } 4 Jf | KS “~~ □□ (FG 2) 3 — 15 ~

Q 16 Their phones exchange beacons with With Bob's consent, his phone uploads random Bluetooth identifiers (which change 4 few days later... the last 14 days of keys for his Bluetooth frequently) beacons to the server

O (aN laws aw (a Zz 18 Apps can only get ? mare information via ———— user consert 19 Key om + => Key =14 day temporary store @ | Google Alice continues her day unaware she had Alice sees a notification on her phone 9 1 been near a potentially contagious person 7 ALERT you have recently come ~) 22 ( contact ttn sernacne mao hee 4 \ tested pomtree ter Cows 19 (7 Tap toe more infurmattion kg y 23 rs) □ Gy f Kw EL ty Alice's phone periodically downloads the Alice’s phone receives a notification with 95 Bluetooth beacon keys of everyone who has Sometime later... information about what to do next. tested positive for COVID-19 in her region. A match is found with Bob's random Bluetooth 2 6 identifiers. Agobonal information is provides Dy the health authority app 27 ee match is founc 2 g Anonymous identifier keys are Govwnioaded periodically «|

1 (Dkt. No. 1-1 at 37-38, 50-51.) These images show the Accused Product’s “ability to exchange 2 Bluetooth proximity identifiers, or keys, between devices as a form of location aggregation 3 relative to a device” to “identify potential exposure to the virus between individuals.” (Dkt. No. 1- 4 1 at 36, 49.) The keys of users who report a positive COVID-19 diagnosis are added to a positive 5 diagnosis list that devices “will periodically download and search” for “matches indicating 6 proximity to COVID-19 positive individuals.” Id. Apple’s system can then send “alert messages 7 to those with potential exposure to COVID-19 positive individuals.” Id. at 45. 8 D. Procedural Background 9 While the matter was pending in the Western District of Texas, Apple filed a motion to 10 dismiss the complaint for failure to state a claim under Federal Rule of Civil Procedure 12(b)(6). 11 (Dkt. No. 21.) The case was then transferred to this Court with the motion still pending. (Dkt. 12 Nos. 32, 33.) Apple’s motion to dismiss the complaint in its entirety is now pending. (Dkt. Nos. 13 21, 23, 24.) 14 DISCUSSION 15 Apple argues the complaint’s factual allegations are insufficient to plausibly state a claim 16 for infringement. In particular, Apple insists the complaint fails to allege facts demonstrating the 17 Accused Product comprises a network monitor, location aggregator, or crowd risk determinant. 18 Apple also argues both counts rely on Plaintiff’s allegation the Accused Product aggregates 19 location information, which is contradicted by the documents attached to the complaint. 20 For Plaintiff’s complaint to survive, its factual allegations must raise a plausible right to 21 relief. Bell Atl. Corp. v. Twombly, 550 U.S. 544, 554–56 (2007). “Determining whether a 22 complaint states a plausible claim for relief is a context-specific task that requires the reviewing 23 court to draw on its judicial experience and common sense.” Ebner v. Fresh, Inc., 838 F.3d 958, 24 963 (9th Cir. 2016) (cleaned up). Though the Court must accept the complaint’s factual 25 allegations as true, conclusory assertions are insufficient to state a claim. Ashcroft v. Iqbal, 556 26 U.S. 662, 678 (2009). A claim is facially plausible when the plaintiff pleads enough factual 27 content to justify the reasonable inference that the defendant is liable for the misconduct alleged. 1 An “element-by-element pleading standard for patent infringement . . . is unsupported and 2 goes beyond the standard the Supreme Court articulated in Iqbal and Twombly.” Bot M8 LLC v. 3 Sony Corp. of Am., 4 F.4th 1342, 1352 (Fed. Cir. 2021). Rather, “[t]he adequacy of the facts pled 4 depends on the breadth and complexity of both the asserted patent and the accused product or 5 system and on the nature of the defendant’s business activities.” K-Tech Telecomms., Inc. v. Time 6 Warner Cable, Inc., 714 F.3d 1277, 1286 (Fed. Cir. 2013). For a “simple technology,” a plaintiff 7 may plausibly plead by providing the asserted patents, identifying the accused products “by name 8 and by attaching photos of the product packaging,” and alleging the accused products meet “each 9 and every element of at least one claim… either literally or equivalently.” Disc Disease Sols. Inc. 10 v. VGH Sols., Inc., 888 F.3d 1256, 1260 (Fed. Cir. 2018). However, “a plaintiff cannot assert a 11 plausible claim for infringement under the Iqbal/Twombly standard by reciting the claim elements 12 and merely concluding that the accused product has those elements. There must be some factual 13 allegations that, when taken as true, articulate why it is plausible that the accused product infringes 14 the patent claim.” Bot M8 LLC v. Sony Corp. of Am., 4 F.4th 1342, 1353 (Fed. Cir. 2021) 15 (agreeing with the district court’s dismissal where the complaint’s allegations were conclusory, 16 merely tracked the claim language, and did not present plausible factual content in support of 17 infringement). 18 Even when a complaint provides sufficient factual statements, a plaintiff may still fail to 19 plausibly state a claim where (1) the infringement allegation rests on an implausible claim 20 construction, Ottah v. Fiat Chrysler, 884 F.3d 1135, 1141-42 (Fed. Cir. 2018), or (2) “the factual 21 allegations are actually inconsistent with and contradict infringement.” Bot M8 LLC, 4 F.4th at 22 1354. 23 A. Direct Infringement 24 A party who “makes, uses, offers to sell, or sells” a patented invention “without authority” 25 directly infringes a patent. 35 U.S.C. § 271(a). Direct infringement requires the accused product 26 to literally infringe or infringe under the doctrine of equivalents. Ottah v. Bracewell LLP, No. 22- 27 1876, 2022 WL 16754378, at *2 (Fed. Cir. Nov. 8, 2022). “A finding of literal patent 1 product.” Id. Apple seeks dismissal because the complaint fails to allege factual support for the 2 Accused Product’s infringement of elements ubiquitous to the Asserted Patents’ claims: the 3 “network monitor,” “location aggregation,” and “crowd risk determinant” limitations. The Court 4 addresses each element in turn. 5 1. Network Monitor 6 Claim 1 of the Asserted Patents requires a “network monitor to monitor a wireless network 7 for an indication of a viral event.” ’054 patent, col. 9 ll. 13-14; ’158 patent, col. 9 ll. 21-22. 8 Potential viral events are “indicated by an aggregation of current locations of a plurality of 9 physical wireless devices associated with said potential viral event[s].” ’158 patent, col. 9 ll. 21- 10 25. More specifically,

11 the Network Monitor utilizes location based services (LBS) to monitor the formation of a plurality of wireless devices at a given 12 point in a wireless network. The Network Monitor compares obtained traffic parameters pertaining to monitored wireless traffic, with 13 historical traffic parameters having to do with crowd risk determination to determine if a viral event may be occurring or 14 impending. A snapshot look at current location data collected by the Network Monitor is subsequently logged in an appropriate historical 15 database. 16 ’054 patent, col. 1 ll. 44-54; ’158 patent, col. 1 ll. 47-57. 17 Plaintiffs allege the Accused Product has a network monitor because of its “capability to 18 monitor a wireless network through Bluetooth beacon keys to verify and store COVID-19 positive 19 case information, and once validated, send indication of the positive cases to users through a 20 wireless network.” (Dkt. No. 1-1 at 36, 49.) Apple argues Plaintiff fails to identify a network 21 monitor in the Accused Product because “there is no identification of a network monitor of any 22 Bluetooth network,” Dkt. No. 21 at 11, or “any monitoring for a viral event that is performed via 23 the Bluetooth beacon keys.” (Dkt. No. 24 at 7.) 24 The complaint alleges the existence of a network monitor in the Accused Product by 25 referencing images included in Plaintiff’s claim charts. (Dkt. No. 1-1 at 36-39, 49-52.)2 The first 26

27 2 The Court may consider Plaintiff’s claim charts because Plaintiff attached them to the complaint. 1 image is also the first pictured above in the Background section. In the first image, a user of the 2 Accused Product requests a verification code from the public health authority, which then sends 3 the verification code to the user, who then enters the verification code into their mobile device. 4 (Dkt. No. 1-1 at 37, 50.) The mobile device then exchanges the verification code with and sends 5 exposure key data to the verification server in exchange for a certificate and metadata the mobile 6 device then validates before asking the user for permission to upload keys. Id. When the user 7 grants permission, the user’s keys, token certificate, and metadata are uploaded to the key server, 8 which validates and stores COVID-19 exposure information for other users. Id. 9 The second image, which is the second image pictured above in the Background section, 10 shows two users of the Accused Product, Alice and Bob, sitting next to each other on a bench as 11 their mobile devices exchange random and frequently changing Bluetooth identifiers. (Dkt. No. 1- 12 1 at 38, 51.) A few days after their bench encounter, Bob receives a positive COVID-19 diagnosis 13 and enters the test result into his public health authority’s application. Id. With Bob’s consent, his 14 mobile device uploads the last 14 days of keys for his Bluetooth beacons to the key server. Id. 15 Because Alice’s mobile device is periodically downloading the Bluetooth beacon keys of everyone 16 who has tested positive for COVID-19 in her region, she receives a notification that she recently 17 encountered someone who tested positive for COVID-19 when her mobile device finds Bob’s 18 Bluetooth identifier in the list of those associated with a positive COVID-19 diagnosis. Id. 19 The third image is a diagram illustrating the flow of broadcasting between two devices 20 using the Accused Product. (Dkt. No. 1-1 at 52.) The image shows the Accused Product asks the 21 user permission to enable exposure notification before generating a temporary exposure key for 22 that user’s device and saving the device’s rolling proximity identifier and associated encrypted 23 metadata into the key server. Id. Every 15 minutes, the user’s rolling proximity identifier and 24 associated encrypted metadata changes. Id. Every 24 hours, the Accused Product generates a new 25 temporary exposure key with associated encrypted metadata for each user’s device. Id. 26 Taken as true, the claim charts indicate the Accused Product senses the real-time proximity 27 between a plurality of devices over a wireless network via Bluetooth “for the purpose of 1 computing an exposure event” and ultimately “to combat the spread of the coronavirus.”3 2 Exposure Notification Bluetooth Specification (April 2020), https://covid19-static.cdn- 3 apple.com/applications/covid19/current/static/contact-tracing/pdf/ExposureNotification- 4 BluetoothSpecificationv1.2.pdf?1 at 3, 4 (document cited at Dkt. No. 1-1 at 40, 44, 52, 55). This 5 is sufficient to support an inference the Accused Product monitors the formation of mobile devices 6 over a wireless network for indication of a viral event. The complaint plausibly alleges the 7 existence of a network monitor in the Accused Product. 8 2. Location Aggregator 9 Claim 1 of the ’054 patent requires a “location aggregator to obtain a location of each of a 10 plurality of wireless devices associated with said viral event.” ’054 patent, col. 9 ll. 15-17. Claim 11 1 of the ’158 patent requires “indication of a potential viral event indicated by an aggregation of 12 current locations of a plurality of physical wireless devices associated with said potential viral 13 event.” ’158 patent, col. 9 ll. 22-25. 14 Plaintiff alleges the Accused Product has a location aggregator because it “includes the 15 ability to exchange Bluetooth proximity identifiers between devices as a form of location 16 aggregation relative to a device.” (Dkt. No. 1-1 at 39, 49.) Plaintiff identifies the Accused 17 Product’s “method to determine if the user traveled outside of their app-associated region,” which 18 Plaintiff contends “demonstrates that [the Accused Product] can access location data of each of a 19 plurality of wireless devices associated with the viral event.” (Dkt. No. 1-1 at 39.) Apple argues 20 the complaint does not identify any “location aggregation,” and relies on documents attached to 21 Plaintiff’s claim charts showing the Accused Product does not monitor location or aggregate any 22 current location data. 23 i. Location Aggregation 24 Apple argues Plaintiff fails to identify an aggregation of locations in the Accused Product 25 and instead only identifies an exchange of Bluetooth keys between two devices. Apple claims 26 3 Exposure Notification Bluetooth Specification (April 2020), https://covid19-static.cdn- 27 apple.com/applications/covid19/current/static/contact-tracing/pdf/ExposureNotification- 1 Plaintiff’s claim charts, which attach Apple’s documents describing the functionality of the 2 Accused Product, contradict any location aggregation in the Accused Product because “[l]ocation 3 information is not collected from a user’s device.” (Dkt. No. 21 at 15.) The documents attached 4 to Plaintiff’s claim charts say the Accused Product “does not share location data from the user’s 5 device with the Public Health Authority, Apple, or Google,”4 and “does not use location for 6 proximity detection. It strictly uses Bluetooth beaconing to detect proximity.” Bluetooth 7 Specification at 8. 8 The “location aggregation” limitation requires the location of each of a plurality of mobile 9 devices associated with a viral event be obtained and aggregated in a physical wireless network 10 server. ’054 patent, col. 9 ll. 10-17; ’158 patent, col. 9 ll. 18-25. According to the claim charts, 11 the Accused Product deploys two kinds of servers: the verification server and the key server. 12 (Dkt. No. 1-1 at 37, 50.) The verification server validates positive diagnoses during key upload. 13 The key server handles key uploads and downloads. According to Plaintiff’s claim charts and 14 attached documents, the servers contain information allowing the Accused Product to notify users 15 who encountered an infected individual of the day, length, and degree of their COVID-19 16 exposure.

17 If a user decides to participate, exposure notification data will be stored and processed on device. Other than the random Bluetooth 18 identifiers that are broadcast, no data will be shared by the system with the public health authority unless one of the following two 19 scenarios takes place:

20  If a user chooses to report a positive diagnosis of COVID-19, the user’s most recent keys to their Bluetooth beacons will be 21 added to the positive diagnosis list shared by the public health authority so that other users who came in contact with those 22 beacons can be alerted.  If a user is notified that they have come into contact with an 23 individual who is positive for COVID-19 the system will share the day the contact occurred, how long it lasted and 24 the Bluetooth signal strength of that contact, as well as the type of report (such as confirmed by test, clinical diagnosis, 25 or self-report). Any other information about the contact will 26 4 Exposure Notifications Frequently Asked Questions (September 2020), https://covid19- 27 static.cdn-apple.com/applications/covid19/current/static/contact-tracing/pdf/ExposureNotification- not be shared.

2 |} FAQ at 5 (emphasis added). Users are not alerted of where they encountered an infected 3 individual—i.e, location of their exposure. /d. Plaintiff nonetheless alleges the Accused Product 4 || has a location aggregator because applications using the Accused Product must declare their 5 || geographic region of operation and the Accused Product can track users’ travel across regions. 6 || (Dkt. No. 1-1 at 39, 49.) 7 All applications using the Accused Product must specify the region for which they work. 8 || Zd. Plaintiffs claim charts identify the Accused Product’s method for determining whether a user 9 || has traveled outside of the region associated with an application anytime in the last 14 days. Jd. 10 11 func userTraveled() asyne throws -> Bool

E 13 || getUserTraveled(completionHandler:), APPLE DEVELOPER, S 14 || https://developer.apple.com/documentation/exposurenotification/enmanager/3644439- 3 15 || getusertraveled (document cited at Dkt. No. 1-1 at 39, 49). Apple’s Developer page says this 16 || information can be used to determine when to share keys across regions. /d. This raises the i 17 || plausible inference the Accused Product obtains and stores location data from users’ devices so it 18 can be accessed to determine users’ location within the last 14 days. Without location data, how 19 || would the Accused Product determine whether and where a user traveled across geographic 20 || regions? 21 Apple side-steps this question, claiming Plaintiff improperly conflates Bluetooth 22 || beaconing with the Accused Product’s ability to function in a given geographical region. Apple 23 instead focuses on Plaintiffs failure to allege any connection between location aggregation and 24 || risk determination in the Accused Product. Apple insists the complaint must allege facts showing 25 || the Accused Product aggregates location information to determine COVID-19 exposure because 26 || the Asserted Patents’ claims require aggregated location data be used for risk determination. The 27 || Court disagrees. Plaintiff need not prove its case at the pleading stage. Bot MS LLC v. Sony Corp. 28 || of Am., 4 F.4th 1342, 1352 (Fed. Cir. 2021). Apple is on notice that its system is being accused of

1 infringement based in part on its alleged aggregation of location information from mobile devices 2 to assess coronavirus exposure. Lifetime Indus., Inc. v. Trim-Lok, Inc., 869 F.3d 1372, 1379 (Fed. 3 Cir. 2017) (“Our precedent requires that a complaint place the alleged infringer on notice of what 4 activity is being accused of infringement.” (cleaned up)). Plaintiff plausibly alleges the Accused 5 Product employs location data to determine whether to share exposure information across 6 geographic regions despite Apple’s claim “an explicit feature of [the Accused Product] is that no 7 location data is shared, stored, or analyzed.” (Dkt. No. 21 at 9.) Accordingly, the complaint 8 plausibly alleges facts supporting its claim of the Accused Product’s infringement of the “location 9 aggregation” limitation of both Asserted Patents. 10 ii. Current Location Data 11 The ’158 patent requires “aggregation of current locations of a plurality of physical 12 wireless devices associated with said potential viral event.” ’158 patent, col. 9 ll. 22-25 (emphasis 13 added). According to Plaintiff’s claim charts and attached documents, the Accused Product does 14 not aggregate current locations of mobile devices to indicate a potential viral event. Rather, 15 Plaintiff’s claim charts and attached documents show the Accused Product indicates a viral event 16 based on reported COVID-19 diagnoses and proximity data recorded from past interactions among 17 mobile devices. When a user voluntarily reports a positive COVID-19 result, the Accused Product 18 uploads the last 14 days of their beacon keys to the key server and notifies devices that 19 encountered the infected user’s device of their past, though recent, exposure. Because the 20 documents Plaintiff attached to the complaint show the Accused Product does not aggregate 21 current locations of mobile devices associated with positive COVID-19 diagnoses to indicate 22 coronavirus exposure, Plaintiff does not plausibly plead the Accused Product satisfies the 23 “location aggregation” limitation of the ’158 patent. 24 3. Crowd Risk Determinant 25 Claim 1 of the Asserted Patents requires a “crowd risk determinant, triggered by said 26 network monitor, to determine a crowd risk based on an aggregation of said location of each of 27 said plurality of wireless devices associated with said viral event.” ’054 patent, col. 9 ll. 15-17; 1 determine if a viral event indicates a crowd safety risk. ’054 patent, col. 1 ll. 56-58; ’158 patent, 2 col. 1 ll. 59-61.

3 In particular, the Crowd Risk Determinant initiates a location request to obtain location information pertaining to a multitude of wireless 4 devices in a given area, regarding a viral event that has been triggered by the Network Monitor. The Crowd Risk Determinant compares the 5 viral pattern formed by the shape and movement of wireless devices in locations observed, with predetermined risk rules to determine if 6 the viral event is also a crowd safety risk. 7 ’054 patent, col. 1 ll. 58-66; ’158 patent, col. 1 ll. 61 – col. 2 ll. 2. 8 Plaintiff alleges the Accused Product infringes the crowd risk determinant element because 9 the Accused Product “includes an algorithm for determining risk after finding a match from the 10 key data.” (Dkt. No. 1-1 at 42, 53.) Plaintiff’s claim charts and attached documents show the 11 Accused Product can use an algorithm to determine exposure risk based on factors including but 12 not limited to exposure proximity and duration. Id. at 53-55. Apple argues Plaintiff failed to 13 identify a “crowd risk determinant” because the algorithm Plaintiff references determines risk to 14 individuals, not crowd safety. In essence, Apple seeks dismissal of Plaintiff’s complaint because 15 the documents Plaintiff attached to the complaint show the Accused Product does not determine 16 “crowd risk” or indicate “crowd safety risk.” To address Apple’s argument, the Court considers 17 the meaning of the term “crowd risk.” 18 Claim construction is generally not proper at the 12(b)(6) stage. See Nalco Co. v. Chem- 19 Mod, LLC, 883 F.3d 1337, 1350 (Fed. Cir. 2018); see also Fujitsu Ltd. v. Belkin Int’l, Inc., 782 F. 20 Supp. 2d 868, 890 (N.D. Cal. 2011) (explaining a “motion to dismiss is not the proper time to 21 initiate claim construction”). However, the Court may dismiss a complaint prior to claim 22 construction if the complaint depends on an implausible claim construction. See Fiat Chrysler, 23 884 F.3d at 1141-42; see also Nalco Co., 883 F.3d at 1349 (explaining patent infringement 24 plaintiff must plead sufficient facts “to raise a reasonable expectation that discovery will reveal 25 evidence” to support plaintiff’s allegations). 26 For the Accused Product to infringe the Asserted Patents’ “crowd risk determinant” 27 limitation, it must determine a “crowd risk.” The Asserted Patents’ claim an invention “to predict 1 patent, col. 2 ll. 52-56; ’158 patent, col. 2 ll. 58-60. The invention alerts “to a problematic crowd 2 risk in a given geographical location.” ’054 patent, col. 1 ll. 32-33; ’158 patent, col. 1 ll. 35-36. 3 The Asserted Patents’ specifications are instructive:

4 Crowd risk is assessed based upon given wireless network traffic parameters such as the number of wireless devices in 5 communication with a given base station (e.g., a density), the shape formed by representations of the individual locations of 6 the densest areas where active wireless devices are currently located, and/or the movement of the wireless devices within 7 the region as defined.

8 ’054 patent, col. 3 ll. 9-15; ’158 patent, col. 3 ll. 13-19.

9 Motion trends are also analyzed to assess crowd risk. The Crowd Risk Determinant preferably determines whether the accumulation of 10 wireless devices is becoming more or less dense about a central location and whether or not this behavior is expected based on trends 11 and configured thresholds established for particular locations. 12 ’054 patent, col. 8 ll. 18-23; ’158 patent, col. 8 ll. 26-31. The term “crowd risk,” consistent with 13 its plain language meaning and the Asserted Patents’ descriptions, denotes a danger posed by a 14 contemporaneous accumulation of people in a geographic location, as indicated by the observable 15 location and movement of wireless devices. 16 Plaintiff argues the Accused Product determines and assesses a crowd risk because it 17 “monitor[s] every interaction between two or more people, including crowd gatherings of any 18 kind, and assesses the individual and unique risk of COVID-19 exposure of every individual in the 19 crowd.” (Dkt. No. 23 at 9.) This is contradicted by Plaintiff’s claim charts and attached 20 documents. First, it is an inaccurate description of the Accused Product. Neither the complaint 21 nor the claim chart support a plausible inference the Accused Product monitors every interaction 22 between people and assesses the individual, unique risk of COVID-19 exposure for every 23 monitored individual. The documents attached to the complaint show the Accused Product 24 monitors the proximity between mobile devices via Bluetooth and alerts specific devices of 25 potential viral exposure based on reported COVID-19 results and past data of interactions between 26 mobile devices. 27 Second, it is implausible to construe the term “crowd risk” to include exposure risk ] retroactively to individuals. The Asserted Patents predict the occurrence of an impending viral 2 || outbreak based on present conditions at a geographic location. As described in the documents 3 Plaintiff attached to the complaint, the Accused Product indicates the incidence and potential 4 || degree of past viral exposure to individuals based on past conditions untethered from geographic 5 location. Risk to an individual is not the same as or equivalent to risk posed by a crowd. The term 6 || “crowd risk” does not encompass the likelihood of an individual’s past exposure to COVID-19. 7 || See Fiat Chrysler, 884 F.3d at 1141-42 (“The district court correctly found that the “book holder” 8 cannot plausibly be construed to include or be the equivalent of a camera holder, in view of the 9 || specification and the prosecution history.”). 10 The complaint fails to plausibly allege the Accused Product infringes the Asserted Patents’ 11 “crowd risk determinant” limitation because the term “crowd risk” cannot plausibly be construed 12 || to include the likelihood of an individual’s past exposure to COVID-19. E 13 CONCLUSION 14 The documents Plaintiff attached to the complaint demonstrate the Accused Product does 3 15 || not satisfy the Asserted Patents’ “crowd risk determinant” limitation or the °158 patent’s “location 16 || aggregation” limitation. Apple’s motion to dismiss is therefore GRANTED. Plaintiff may file an i 17 || amended complaint on or before August 14, 2023. Yagman v. Garcetti, 852 F.3d 859, 863 (9th Z 18 Cir. 2017). An initial case management conference is set for November 9, 2023 at 1:30 p.m. by a 19 || Zoom videoconference. A joint case management conference is due by November 2, 2023. 20 This Order disposes of Docket No. 21. 21 IT IS SO ORDERED. 22 || Dated: July 24, 2023 23

JAQQUELINE SCOTT CORL 25 United States District Judge 26 27 28