Rideapp, Inc. v. Lyft, Inc.

Opinion

NOTE: This disposition is nonprecedential.

United States Court of Appeals for the Federal Circuit

______________________

RIDEAPP INC., Plaintiff-Appellant,

v.

LYFT, INC., Defendant-Appellee.

______________________

2020-1284

______________________

Appeal from the United States District Court for the Northern District of California in No. 4:18-cv-07152-JST, Judge Jon. S. Tigar.

______________________

Decided: March 25, 2021

______________________

CHARLES A. PANNELL, III, Addy Hart P.C., Atlanta, GA, argued for appellant. Also represented by MEREDITH MARTIN ADDY.

JEREMEY TAYLOR, Baker Botts L.L.P., San Francisco, CA, argued for appellee. Also represented by SARAH J. GUSKE; ELIZABETH KATHLEEN BOGGS, JOHN GAUSTAD, KEITH MARVIN JUREK, Palo Alto, CA; JENNIFER COZEOLINO TEMPESTA, New York, NY.

______________________

2 RIDEAPP, INC. v. LYFT, INC.

Before WALLACH, CHEN, and HUGHES, Circuit Judges.

CHEN, Circuit Judge.

RideApp Inc. (RideApp) appeals the district court’s claim construction order finding claims 2, 3, and 6 of U.S. Patent No. 6,697,730 (’730 patent) indefinite under 35 U.S.C. § 112, ¶ 2 1 for failing to disclose adequate structure corresponding to various computer-implemented means- plus-function claim terms. For the following reasons, we affirm.

BACKGROUND

A

The ’730 patent is directed to an “urban transit system based on digital cellular communications [and] GPS locating technology . . . to provide real-time command and control of passengers and vehicles.” See ’730 patent at Abstract. A “central assigning system” (CAS) communicates with and collects data from both passengers and vehicles in the system. See id. at col. 4 ll. 3–6. The CAS is “capable of matching a passenger’s trip request with current transit parameters to determine vehicle assignment and routes that reduce passenger trip and wait times, wherein the current transit parameters and passenger location are obtained via wireless communication devices optionally capable of transmitting location data.” Id. at col. 3 ll. 56–62.

1 Section 112, ¶ 2 was replaced by § 112(b) when the America Invents Act (AIA) took effect on September 12, 2012. See Advanced Ground Info. Sys., Inc. v. Life360, Inc., 830 F.3d 1341, 1343 n.1 (Fed. Cir. 2016). Because the application for the instant patent was filed before that date, we refer to the pre-AIA version of § 112.

RIDEAPP, INC. v. LYFT, INC. 3

Several of the patent’s figures relate to the invention’s core feature: “real-time,” i.e., “on-demand,” “match[ing of] a user’s [trip] request with existing [transit] services.” See id. at col. 14 ll. 49–51. The patent’s Figure 5 illustrates “a logic flow diagram of a preferred embodiment of the present transit system.” See id. at col. 13 ll. 53–54. According to the patent, Figure 6 explains Figure 5’s block 504—entitled “Process Trip Request”—“in detail.” See id. at col. 14 l. 14. Additionally, the patent states that Figure 9 “show[s] the interaction of passenger, central assigning system, and vehicle.” See id. at col. 20 ll. 41–42.

The patent also includes a table purportedly providing “exemplary central processing software subsystems” for the disclosed invention. See id. at col. 20 ll. 42–43, Table 1. For example, Table 1’s “Find Best Trip” module “[s]olves the trip assignment task based on available vehicles, their schedules, and their passenger loadings.” Id. at Table 1.

B

RideApp sued Lyft, Inc. (Lyft), alleging that Lyft’s ride and bikeshare services infringe claims 2, 3, and 6 of the ’730 patent when “[a] passenger uses the Lyft App to request or locate a ride and, through the Lyft App, a driver accepts the request.” See J.A. 683, 1286. Claim 2 is reproduced below:

2. An automated system for providing unified billing for passenger transport comprising: (a) a central data system for tracking passenger transportation vehicle usage and distributing periodic invoices for the usage; and (b) a plurality of communication devices for providing wireless communication between passengers, vehicles, and the central data system in connection with the passenger transportation vehicle usage; and 4 RIDEAPP, INC. v. LYFT, INC.

(c) a wireless means of on-demand allocation of a passenger to a specific vehicle through the central data system.

’730 patent at claim 2 (emphasis added).

Claim 3 is an independent claim containing each of the limitations of claim 2 and an additional limitation:

(d) a wireless means of informing the passenger of the assignment and updated expected arrival time.

See id. at claim 3.

Claim 6 is also independent, contains the same first two limitations as claims 2 and 3, i.e., limitations (a) and (b), and adds a third limitation:

(c) a wireless means of detecting the proximity of the passenger and alerting the passenger of the proximity of the vehicle.

See id. at claim 6 (emphasis added).

C

During claim construction, Lyft argued that the following computer implemented means-plus-function claim limitations were indefinite because the ’730 patent failed to provide a corresponding structure—specifically, an algorithm —for their respective functions recited in the claims:

a central data system for tracking passenger transportation vehicle usage and distributing periodic invoices for the usage; a wireless means of on-demand allocation of a passenger to a specific vehicle through the central data system; a wireless means of informing the passenger of the assignment and updated expected arrival time; and

RIDEAPP, INC. v. LYFT, INC. 5

a wireless means of detecting the proximity of the passenger and alerting the passenger of the proximity of the vehicle. The district court agreed with Lyft as to each of the identified means-plus-function limitations and invalidated each of the asserted claims. See RideApp, Inc. v. Lyft, Inc., No. 18-CV-07152-JST, 2019 WL 7834175, at *1 (N.D. Cal. Oct. 16, 2019) (Claim Construction Order). As to “on-demand allocation,” the district court determined first that the disclosed system step of “assignment”—matching a user’s request to existing transit services—was a part of the allocation function. See id. at *8. The district court then rejected RideApp’s argument that the “Find Best Trip” module in Table 1 provides an algorithm for the trip assignment function because it disclosed no procedure for doing so. See id. at *9. Similarly, the district court found that Figures 5 and 6 and the corresponding specification discussion of those figures failed to disclose the requisite structure. See id.

The district court likewise found the “detecting the proximity” limitation indefinite. See id. at *11. The district court adopted RideApp’s interpretation of proximity as referring to geographic distance, but nonetheless found the limitation indefinite because “the specification is silent on how proximity is to be calculated.” See id. The district court rejected RideApp’s argument that a simple algorithm , such as the Pythagorean theorem, need not be disclosed because a straight-line calculation is just one of several ways to calculate proximity. See id.

Having found each asserted claim indefinite, the district court entered final judgment in favor of Lyft. See J.A. 1–3. RideApp appeals to this court. We have jurisdiction under 28 U.S.C. § 1295(a)(1).

6 RIDEAPP, INC. v. LYFT, INC.

DISCUSSION

RideApp argues that the district court erred in finding each of the four limitations at issue, and thus, claims 2, 3, and 6, indefinite. Because we agree with the district court that the on-demand allocation and proximity limitations are indefinite, we affirm without addressing the tracking and distributing or expected arrival time limitations.

We review a district court’s indefiniteness conclusion de novo and any underlying factual findings based on extrinsic evidence for clear error. See Williamson v. Citrix Online, LLC, 792 F.3d 1339, 1346 (Fed. Cir. 2015) (en banc). Construing means-plus-function terms requires first identifying the claimed function(s) of the phrase and second determining what structure disclosed in the specification performs that function. See id. at 1351. The intrinsic evidence must “clearly link[] or associate[] that structure to the function recited in the claim.” Id. at 1352. For a patent to satisfy this standard, a skilled artisan must “be []able to recognize the structure in the specification and associate it with the corresponding function in the claim.” Id. When a function is implemented in a special-purpose computer, “the specification [must] disclose an algorithm for performing the claimed function,” which “may be expressed as a mathematical formula, in prose, or as a flow chart, or in any other manner that provides sufficient structure.” See id.

A

Regarding the “on-demand allocation” limitation, we agree with the district court that the “on-demand allocation ” function requires the “wireless means” to assign a passenger to a specific vehicle. See Claim Construction Order at *8. The district court found that allocation included assignment for several reasons. First, it concluded that the “assignment” recited in the fourth limitation of claim 3 would have no antecedent if assignment were not a part of

RIDEAPP, INC. v. LYFT, INC. 7

“allocation.” See id. Additionally, the district court found that the plain meaning of the term “allocation” supported its construction, which was not contradicted by any intrinsic evidence. See id. We see no error in the district court’s construction of “allocation” as including “assignment,” particularly in light of RideApp’s representations to the Patent Office that “[o]n-demand allocation includes ‘assignment.’” See J.A. 1446.

Next, we agree with the district court that the patent fails to disclose sufficient algorithmic structure for the assignment function. See Claim Construction Order at *9. RideApp largely relies on Figures 5 and 6 as detailing the assignment algorithm. See Appellant’s Br. at 53–58. Yet neither figure describes how the system analyzes different passenger transportation requests and vehicle availability to assign a particular route or vehicle to a given user. Instead , the patent simply calls for the system to “match” an available vehicle to a passenger request. See, e.g., Figure 6; col. 14, ll. 49–53. At oral argument, counsel for RideApp cited column 15 line 25 and “between columns seven and eight” as the best evidence of an assignment algorithm. Oral Arg. at 11:27–12:16. But the cited specification portions merely state that “[o]nce the routes and methods are determined, the central processing system allocates them based on a passenger’s parameters,” ’730 patent at col. 15 ll. 24–26, and “[t]he data interpreted and evaluated by the central assigning system can include . . . communications to vehicles to allocate routes, schedules and passengers,” id. at col. 7 l. 65–col. 8 l. 4. Similarly, the Find Best Trip module in Table 1 merely states that it “[s]olves the trip assignment task” without explaining how it does so. See id. at Table 1. These passages, like the others cited by RideApp, are too generic and fail to provide sufficient algorithmic structure for the assigning function embedded in on-demand allocation. This limitation, recited in claims 2 and 3, is therefore indefinite.

8 RIDEAPP, INC. v. LYFT, INC.

B

We likewise agree with the district court that the “proximity” limitation recited in claim 6 is indefinite. Ride- App contends that the district court erred in faulting the patent for failing to disclose a “simple calculation” which, according to RideApp, would not “affect claim scope.” See Appellant’s Br. at 76–78.

RideApp’s first point—that a skilled artisan “would know many methods to calculate distance between sets of coordinates,” id. at 77—underscores why this means-plus- function limitation is indefinite. RideApp argued to the district court that a skilled artisan, or even a high-school student, could use a formula as simple as the Pythagorean theorem to ascertain the distance between two points. See Claim Construction Order at *11. Yet as Lyft points out, the calculation of an as-the-crow-flies, straight-line distance makes little sense in the context of vehicle travel constrained to roadways. As Lyft’s expert testified, a calculation considering the layout of the underlying street system would be more appropriate. See id. On appeal, RideApp does not explicitly defend its Pythagorean theorem approach. Rather, it contends that the invention utilizes some unidentified “simple calculation” to calculate distance. See Appellant’s Br. at 78. RideApp’s lack of specificity is unsurprising given its only proposed “simple calculation ” would make little sense in this context and the patent’s failure to provide any guidance on the scope of this limitation. Without any limit on how the invention calculates proximity, RideApp “has in effect claimed everything that [performs the task] under the sun.” See Claim Construction Order at *10 (quoting ePlus, Inc. v. Lawson Software , Inc., 700 F.3d 509, 519 (Fed. Cir. 2012)).

RideApp’s second point—that any disclosed algorithm would not affect claims scope—misunderstands the law. A computer-implemented, means-plus-function claim element is, by definition, limited to the disclosed algorithm

RIDEAPP, INC. v. LYFT, INC. 9

and equivalents thereof. See Williamson, 792 F.3d at 1347 (noting the scope of means-plus-function claim element is limited “to only the structure . . . described in the specification as corresponding to the claimed function and equivalents thereof”). As any disclosed algorithm would necessarily affect claim scope, we decline to resurrect claim 6 on this basis.

CONCLUSION

We have considered RideApp’s remaining arguments and find them unpersuasive. For the reasons set forth above, we affirm the district court’s order finding claims 2, 3, and 6 of the ’730 patent invalid as indefinite.

AFFIRMED