Opinion
Case No. 16-CV-06050-LHK
08-18-2017
X ONE, INC., Plaintiff, v. UBER TECHNOLOGIES, INC., Defendant.
ORDER CONSTRUING DISPUTED CLAIM TERMS OF U.S. PATENT NOS. 8,798,593 AND 8,798,647 Re: Dkt. No. 63
Plaintiff X One, Inc. ("X One" or "Plaintiff") brings this action for patent infringement against Defendant Uber Technologies, Inc. ("Uber" or "Defendant"). The parties now seek construction of seven disputed terms used in the claims of the following patents-in-suit: U.S. Patent Nos. 8,798,647 ("'647 patent") and 8,798,593 ("'593 patent") (collectively, "X One Patents").
I. BACKGROUND
A. Background and Description of the Invention
The '593 patent is titled "Location Sharing and Tracking Using Mobile Phones or Other Wireless Devices." ECF No. 1 ("Compl.") Ex. B ('593 patent). The '647 patent is titled "Tracking Proximity of Services Provider to Services Consumer." Compl. Ex. A ('647 patent). The'647 patent is a continuation of the'593 patent, and thus the two patents share the same specification. For simplicity, unless specifically referring to the '593 patent or the '647 patent, the Court's citations to the text and figures of the X One Patents refer to the '593 patent specification.
1. Specification
The X One Patents relate to "[a] system for exchanging GPS or other position data between wireless devices." '593 patent, Abstract. This system involves "phones [or] other wireless devices" that "are programmed with software . . . to allow mutual tracking and optional position mapping displays of members of groups." Id., col. 2:35-40. These devices "work with a . . . server coupled to the internet." Id. These devices "must be web enabled to send and receive TCP/IP or other protocol packets over the internet to the . . . server." Id., col. 2:25-27. These devices also contain GPS receivers, and, in preferred embodiments, "sufficiently large liquid crystal displays." Id., col. 2:23-24.
Figure 2A illustrates exemplary communications between these devices according to the invention of the X One Patents:
Image materials not available for display. Id., Fig. 2A.
As Figure 2A illustrates, the requesting phone sends packets through the local phone carrier system, which are then relayed through the internet to a server. Id., col. 5:59-6:28. The server then obtains the relevant data from the phones associated with individuals on a buddy list for the requesting phone. Id. The server then relays the requested information—location data for each phone associated with a "buddy" and a map showing that location—back to the requesting phone through the internet and carrier service. See also id., col. 2:51-64 ("[T]he process of the invention [] allows exchanging and mapping of position data with persons on a Buddy List.").
However, the specification is not solely limited to the use of a server, and outlines a more generalized process as well for the functioning of the invention. Figure 13 of the X One Patents provides a "flowchart of the method of exchanging GPS position data among cell phones of a watch list":
Image materials not available for display. Id., Figs. 13A & 13B.
In this illustrated method, a buddy location update request is received, the persons in the buddy list are identified, and the requesting device sends, through the cellular system, its location data to the phones in the buddy list. Id. Those phones receive the information, interpret it, and display that location on a map, and then obtain their own position and send their location to the people on their buddy list. Id.
2. Asserted Claims
Plaintiff asserts that Defendant infringes thirty-four (34) claims across the X One Patents. Opening Br. 7. Five of these asserted claims are independent claims, namely claims 1 and 19 of the '593 patent and claims 1, 22, and 28 of the '647 patent. Id. All of the disputed claim terms appear in one or several of these independent claims. See ECF No. 63 ("Joint Statement") at 2.
B. Procedural History
On October 19, 2016, Plaintiff filed the instant patent infringement suit. In its complaint, Plaintiff alleged that Defendant "has infringed and continues to infringe one or more claims of the [X One Patents]." Compl. ¶ 13. The products and services accused included "Uber's mobile device applications on iOS, Android, and Microsoft operating systems" as well as "the Uber ride-sharing, car-pooling, and delivery services." Id.
On December 9, 2016, Defendant moved to dismiss all of the asserted claims of the X One Patents for failure to claim patent-eligible subject matter pursuant to 35 U.S.C. § 101. ECF No. 24. The Court denied Defendant's motion on March 6, 2017. ECF No. 52.
On June 30, 2017, Plaintiff filed its Opening Brief on Claim Construction. ECF No. 64 ("Opening Br." or "Opening Brief"). On July 17, 2017, Defendant filed its Responsive Claim Construction Brief. ECF No. 66 ("Responsive Brief" or "Resp. Br."). On July 21, 2017, Plaintiff filed its Reply Brief. ECF No. 75 ("Reply Brief" or Reply Br."). The Court held a tutorial and claim construction hearing on August 17, 2017 ("Markman hearing").
II. LEGAL STANDARD
A. Claim Construction
The Court construes patent claims as a matter of law based on the relevant intrinsic and extrinsic evidence. See Lighting Ballast Control LLC v. Philips Elecs. N. Am. Corp., 744 F.3d 1272 (Fed. Cir. 2014) (en banc); Phillips v. AWH Corp., 415 F.3d 1303 (Fed. Cir. 2005) (en banc). "Ultimately, the interpretation to be given a term can only be determined and confirmed with a full understanding of what the inventors actually invented and intended to envelop with the claim." Phillips, 415 F.3d at 1316 (internal quotation marks and citation omitted). Accordingly, a claim should be construed in a manner that "stays true to the claim language and most naturally aligns with the patent's description of the invention." Id.
In construing disputed terms, a court looks first to the claims themselves, for "[i]t is a 'bedrock principle' of patent law that 'the claims of a patent define the invention to which the patentee is entitled the right to exclude.'" Id. at 1312 (quoting Innova/Pure Water, Inc. v. Safari Water Filtration Sys., Inc., 381 F.3d 1111, 1115 (Fed. Cir. 2004)). Generally, the words of a claim should be given their "ordinary and customary meaning," which is "the meaning that the term[s] would have to a person of ordinary skill in the art in question at the time of the invention." Id. at 1312-13. In some instances, the ordinary meaning to a person of skill in the art is clear, and claim construction may involve "little more than the application of the widely accepted meaning of commonly understood words." Id. at 1314.
In many cases, however, the meaning of a term to a person skilled in the art will not be readily apparent, and a court must look to other sources to determine the term's meaning. See id. Under these circumstances, a court should consider the context in which the term is used in an asserted claim or in related claims and bear in mind that "the person of ordinary skill in the art is deemed to read the claim term not only in the context of the particular claim in which the disputed term appears, but in the context of the entire patent, including the specification." Id. at 1313. The specification "'is always highly relevant'" and "'[u]sually . . . dispositive; it is the single best guide to the meaning of a disputed term.'" Id. at 1315 (quoting Vitronics Corp. v. Conceptronic, Inc., 90 F.3d 1576, 1582 (Fed. Cir. 1996)). Indeed, "the only meaning that matters in claim construction is the meaning in the context of the patent." Trs. of Columbia Univ. v. Symantec Corp., 811 F.3d 1359, 1363 (Fed. Cir. 2016). Where the specification reveals that the patentee has given a special definition to a claim term that differs from the meaning it would ordinarily possess, "the inventor's lexicography governs." Id. at 1316. Likewise, where the specification reveals an intentional disclaimer or disavowal of claim scope by the inventor, the inventor's intention as revealed through the specification is dispositive. Id.
In addition to the specification, a court may also consider the patent's prosecution history, which consists of the complete record of proceedings before the United States Patent and Trademark Office ("PTO") and includes the cited prior art references. The prosecution history "can often inform the meaning of the claim language by demonstrating how the inventor understood the invention and whether the inventor limited the invention in the course of prosecution, making the claim scope narrower than it would otherwise be." Id. at 1317.
A court is also authorized to consider extrinsic evidence in construing claims, such as "expert and inventor testimony, dictionaries, and learned treatises." Markman v. Westview Instruments, Inc., 52 F.3d 967, 980 (Fed. Cir. 1995) (en banc), aff'd, 517 U.S. 370 (1996). Expert testimony may be particularly useful in "[providing] background on the technology at issue, . . . explain[ing] how an invention works, . . . ensur[ing] that the court's understanding of the technical aspects of the patent is consistent with that of a person of skill in the art, or . . . establish[ing] that a particular term in the patent or the prior art has a particular meaning in the pertinent field." Phillips, 415 F.3d at 1318. Although a court may consider evidence extrinsic to the patent and prosecution history, such evidence is considered "less significant than the intrinsic record" and "less reliable than the patent and its prosecution history in determining how to read claim terms." Id. at 1317-18 (internal quotation marks and citations omitted). Thus, while extrinsic evidence may be useful in claim construction, ultimately "it is unlikely to result in a reliable interpretation of patent claim scope unless considered in the context of the intrinsic evidence." Id. at 1319. Any expert testimony "that is clearly at odds with the claim construction mandated by the claims themselves, the written description, and the prosecution history" will be significantly discounted. Id. at 1318 (internal quotation marks and citation omitted). Finally, while the specification may describe a preferred embodiment, the claims are not necessarily limited only to that embodiment. Id. at 1323; see also Prima Tek II, L.L.C. v. Polypap, S.A.R.L., 318 F.3d 1143, 1151 (Fed. Cir. 2003) ("The general rule, of course, is that claims of a patent are not limited to the preferred embodiment, unless by their own language.").
B. Indefiniteness
Under 35 U.S.C. § 112, ¶ 2 (2006 ed.), a patent must "conclude with one or more claims particularly pointing out and distinctly claiming the subject matter which the applicant regards as [the] invention." Section 112, ¶ 2 includes what is commonly called the "definiteness" requirement. Nautilus, Inc. v. Biosig Instruments, Inc., 134 S. Ct. 2120, 2125 (2014). In Nautilus, the United States Supreme Court held that "a patent is invalid for indefiniteness if its claims, read in light of the specification delineating the patent, and the prosecution history, fail to inform, with reasonable certainty, those skilled in the art about the scope of the invention." Nautilus, 134 S. Ct. at 2124. As the Court observed, § 112, ¶ 2 "entails a 'delicate balance.'" Id. (quoting Festo Corp. v. Shoketsu Kinzoku Kogyo Kabushiki Co., 535 U.S. 722, 731 (2002)). "On the one hand, the definiteness requirement must take into account the inherent limitations of language." Id. (citing Festo, 535 U.S. at 731). "At the same time, a patent must be precise enough to afford clear notice of what is claimed, thereby 'appris[ing] the public of what is still open to them.'" Id. (quoting Markman, 517 U.S. at 373). Thus, "the certainty which the law requires in patents is not greater than is reasonable, having regard to their subject-matter." Id. at 2129 (quoting Minerals Separation v. Hyde, 242 U.S. 261, 270 (1916)).
Paragraph 2 of 35 U.S.C. § 112 was replaced with newly designated § 112(b) when § 4(c) of the America Invents Act ("AIA"), Pub. L. No. 112-29, took effect on September 16, 2012. Because the applications resulting in the patents at issue in this case are continuations of applications that were filed before that date, the Court refers to the pre-AIA version of § 112.
The Federal Circuit applied the Nautilus standard in Interval Licensing LLC v. AOL, Inc., 766 F.3d 1364 (Fed. Cir. 2014). The case involved two patents which covered an "attention manager for occupying the peripheral attention of a person in the vicinity of a display device." Id. at 1366. In one embodiment, the patents involved placing advertising on websites in areas surrounding the principal content of the webpage, for example in the margins of an article. Several of the asserted claims included a limitation that the advertisements ("content data") would be displayed "in an unobtrusive manner that does not distract a user of the display device." Id. at 1368. The district court found that the terms "in an unobtrusive manner" and "does not distract the user" were indefinite, and the Federal Circuit affirmed. Id. at 1368-69. The Federal Circuit found that the "'unobtrusive manner' phrase is highly subjective and, on its face, provides little guidance to one of skill in the art" and "offers no objective indication of the manner in which content images are to be displayed to the user." Id. at 1371. Accordingly, the Court looked to the written description for guidance. The Court concluded that the specification lacked adequate guidance to give the phrase a "reasonably clear and exclusive definition, leaving the facially subjective claim language without an objective boundary." Id. at 1373. Accordingly, the claims containing the "unobtrusive manner" phrase were indefinite.
In applying the Nautilus standard, the Federal Circuit has cautioned that "the dispositive question in an indefiniteness inquiry is whether the 'claims,' not particular claim terms" fail the Nautilus test. Cox Commc'ns, Inc. v. Sprint Commc'n Co. LP, 838 F.3d 1224, 1231 (Fed. Cir. 2016). For that reason, a claim term that "does not discernably alter the scope of the claims" may fail to serve as a source of indefiniteness. Id. For example, in Cox Communications, the Federal Circuit determined that the term "processing system" did not render the method claims at issue indefinite because "the point of novelty resides with the steps of these methods, not with the machine that performs them." Id. at 1229. Thus, the court reasoned, "[i]f 'processing system' does not discernably alter the scope of the claims, it is difficult to see how this term would prevent the claims . . . from serving their notice function under § 112, ¶ 2." Id.
The Court therefore reviews the claims, specification, and prosecution history to determine whether the claims "inform, with reasonable certainty, those skilled in the art about the scope of the invention." Nautilus, 134 S. Ct. at 2124. Indefiniteness renders a claim invalid, and must be shown by clear and convincing evidence. See Halliburton Energy Servs. v. M-I LLC, 514 F.3d 1244, 1249 (Fed. Cir. 2008); cf. Nautilus, 134 S. Ct. at 2130 n.10.
III. DISCUSSION
The parties request construction of four terms of the '593 patent and three terms of the '647 patent. The Court discusses each in turn.
A. '593 Patent
1. "account" (claims 1 and 19)
| X One's Proposed Construction | Uber's Proposed Construction |
|---|---|
| an arrangement for user-specific authenticatedaccess | plain and ordinary meaning |
The term "account" appears in claims 1 and 19 of the '593 patent. For example, claim 1 of the '593 patent recites:
1. An apparatus, comprising:
'593 patent, col. 28:51-29:4 (emphasis added).a server;
a database representing an account for a first individual, the account having an associated buddy list that identifies multiple users; and
software responsive to a request from the first individual to obtain a map, to obtain a last known position for multiple users identified by the buddy list, and to plot the last known location of at least two of the multiple users on the map, and to transmit the map with plotted locations to the first individual;
where the software is to request and store position information associated with cell phones of plural ones of the multiple users and where the software is to permit the first individual to change geography represented by the map and to transmit to the first individual a map representing the changed geography with plotted position of at least one of the multiple users, each in a manner not requiring concurrent voice communications; and
wherein the software to obtain the map is to obtain the map in a manner having a default geographic resolution.
X One argues that "account" should be construed as "an arrangement for user-specific authenticated access." Opening Br. 8. Uber argues that this term should be given its plain and ordinary meaning. Responsive Br. 6. In responding to X One's proposal, Uber acknowledges that an account must be "for a first individual," but disagrees that an account must have "user-specific authenticated access." See id. at 7-8. Thus, the parties appear to agree that an "account" must be user-specific, but dispute whether it requires "authenticated access." For the reasons discussed below, the Court agrees with X One.
a. Intrinsic Evidence
i. Claim Language
At the outset, the Court observes that the claim language on its face does not require authenticated access. Rather, the claim language only requires that "account" is (1) "for a first individual"—i.e., is user-specific; (2) is "represent[ed]" by a "database;" and (3) "ha[s] an associated buddy list that identifies multiple users." Thus, thus claim language, by itself, does not support X One's "authenticated access" proposal. However, claims must be read in "light of the specification . . ." Corning Glass Works v. Sumitomo Elec. U.S.A., Inc., 868 F.2d 1251, 1257 (Fed. Cir. 1989). Accordingly, the Court proceeds to consider the specification.
ii. Specification
Turning to the specification, the Court first notes that the word "account" does not itself appear in the specification. See '543 patent, col. 1:20-28:48. Both parties acknowledge this. Opening Br. 9; Responsive Br. 7. Nevertheless, this does not prevent the Court from using the specification to construe "account" because the "claims must be read in view of the specification" and reading claims 1 and 19 in light of the specification informs the meaning of "account." Philips, 415 F.3d at 1315 (quoting Markman, 52 F.3d at 978 (quotation marks omitted)) (emphasis added); see also, e.g., HBAC Matchmaker Media, Inc. v. Google Inc., 650 F. App'x 990, 993 (Fed. Cir. 2016) (acknowledging the specification as helpful context even where the disputed claim term did not appear in the specification).
X One contends that the specification supports its position that "account" requires "authenticated access" because it discloses that location sharing is accomplished through user-specific authenticated access. Opening Br. 9-10. As support for this, X One points to embodiments where devices are first authenticated before location information is shared. Id. at 9 (citing, for example, '593 patent, col. 10:7-8 ("The initiator and recipient are also authenticated—230, and the packets are forwarded to the recipients via the cell system.")). X One also argues that user-specific authenticated access is required for the privacy features disclosed in the specification, such as the ability to selectively disable location sharing. Id. at 9-10. Uber, on the other hand, argues that these citations refer only to preferred embodiments and that the claims should not be so limited. Responsive Br. 7.
The Court agrees with X One that, when the term "account" is viewed in the context of the specification, it becomes clear that it requires "authenticated access." As discussed above, claims 1 and 19 recite apparatuses that include a "server." '593 patent, col. 28:53, col. 30:50. The specification, however, is broader than this and discloses embodiments that both include a server and ones that do not. Compare, e.g., id., col. 8:12-9:65, with id., col. 9:66-10:34. Thus, for the purposes of construing terms in claims 1 and 19, the Court need only focus on the embodiments that include a "server." See Aug. Tech. Corp. v. Camtek, Ltd., 655 F.3d 1278, 1285 (Fed. Cir. 2011) (construing claims in light of embodiments that used multiple wafers because the claim language required using multiple wafers, even though the specification disclosed embodiments that used both multiple dies and multiple wafers); cf. Pacing Techs., LLC v. Garmin Int'l, Inc., 778 F.3d 1021, 1026 (Fed. Cir. 2015) ("[W]here the patent describes multiple embodiments, every claim does not need to cover every embodiment.").
Focusing on the embodiments that include a "server," the specification consistently discloses that, when a server is involved, it performs the step of authenticating the participating devices. Walking through relevant portions of the specification confirms this. First, in the opening paragraph of its "Detailed Description" section, the specification discloses an initial preferred embodiment that includes "[a] Buddy Watch or Rubicon server" that performs the step of "valid[ating] the content of the IP packet to authenticate the sender as a registered Rubicon user and to verify that the sending phone EIN matches the phone EIN stored in the server." '543 patent, col. 5:60, col. 6:7-11 (emphasis added). Next, the specification describes several embodiments of a "process to receive buddy location update requests and process them." Id., col. 9:6-67. One of these embodiments uses a server, while the other does not. Compare id., col. 8:12-9:65, with id., col. 9:66-10:34. In the embodiment that includes a server, the specification discloses that "[t]he initiator and recipient are authenticated—230 . . . ." Id., col. 10:7-8 (emphasis added). Next, the specification discusses "Buddy Watch Server Functions." Id., col. 12:20. One of these functions, the specification discloses, is "to manage activate and deactivate codes," which the server uses to confirm that a participating device has a current subscription to the Buddy Watch service. See id., col. 12:43-45 ("The Buddy Watch application will be a service which a cellular carrier offers on a subscription basis."). Again here the specification mentions the step of authenticating the participating devices to make sure that they are registered users in the Buddy Watch system: "The Buddy Watch server . . . check[s] the activation code status each time before communication with a phone is carried out." Id., col. 12:58-61 (emphasis added). Next, the specification describes several embodiments of the Instant Buddy Setup process. Id., col. 13:12-15:13. In the embodiments that include a server, the specification discloses authentication. Id., col. 13:40-43 ("Buddy Watch server authenticates the initiator and the recipient from data in the packet as a [sic] Buddy Watch subscribers.") (emphasis added), col. 14:60-61 ("Rubicon server authenticates the initiator and recipient and forwards packets to cell system—258.") (emphasis added). Further on, the specification elaborates on how access codes and encryption help the server ensure that only authenticated devices use the Buddy Watch service. Id., col. 23:21-42. Next, the specification discusses attributes of "all species" within the "User Interface Genus," the "Server Genus," and "Client Application Genus." Notably, for the "Server Genus," the specification discloses that "[a]ll servers programmed with Buddy Watch software will have the functionality to . . . store at least some preference data that defines who can use the server, e.g. only those with a valid Buddy watch user ID and password." Id., col. 24:59-60, col. 25:8-10 (emphasis added). Finally, the specification describes embodiments of "TalkControl" functionality, which works specifically with "walkie-talkie enabled phones" and uses a server. Id., col. 26:12-28:40. As with all the other server embodiments discussed above, here too the server performs authentication. Id., col. 26:59-61 ("One or more packets are sent to the Rubicon server which authenticates the token and the recipient and creates a database entry.") (emphasis added), col. 27:25-28 (". . . Rubicon server which authenticates the initiator and recipient . . .") (emphasis added), col. 27:49-51 (". . . Rubicon servers which authenticate the initiator and recipient . . .") (emphasis added), col. 28:30-32 (". . . Rubicon server then authenticates the initiator and recipient . . .") (emphasis added). Thus, all of the embodiments that include a server perform the step of authentication. "The fact that [authentication] is 'repeatedly and consistently' used to characterize the invention strongly suggests that it should be read as part of the claim." Virnetx, Inc. v. Cisco Sys., Inc., 767 F.3d 1308, 1318 (Fed. Cir. 2014); see also GPNE Corp. v. Apple Inc., 830 F.3d 1365, 1370 (Fed. Cir. 2016) ("[W]hen a patent 'repeatedly and consistently' characterizes a claim term in a particular way, it is proper to construe the claim term in accordance with that characterization.") (citations omitted). Accordingly "account" should include "authenticated access."
In particular, the Court walks through each portion of the specification that details server operations. These are the portions of the specification that would mention authentication, if authentication was indeed performed in that embodiment.
Other aspects of the specification bolster this conclusion. Specifically, the specification discloses two objectives of the invention: (1) enforcing valid subscriptions; and (2) maintaining privacy. Construing "account" to require "authenticated access" furthers both of these objectives. Cf. Renishaw PLC v. Marposs Societa' per Azioni, 158 F.3d 1243, 1250 (Fed. Cir. 1998) ("The construction that stays true to the claim language and most naturally aligns with the patent's description of the invention will be, in the end, the correct construction."). First, the specification discloses that it is important to ensure that only users with valid subscriptions use the disclosed invention. See '543 patent, col. 2:51-54 ("the process of the invention only allows exchanging and mapping of position data with persons on a Buddy List programmed onto a Buddy Watch . . . device"). In order to know whether a device is a "Buddy Watch . . . device," it would need to be authenticated or validated in some way. Second, the specification discloses that an important consideration in the X One Patents is privacy concerns. See id., col. 2:8-13 ("To alleviate privacy concerns, it would be useful to be able to turn off location sharing . . . ."). Requiring that an "account" includes "authenticated access" helps further this objective of protecting privacy, because it helps ensure that the people with whom location information is shared are who they purport to be. See id., col. 2:51-53 (describing how the user must allow specific individuals "on his Buddy Lists to 'see' his location . . . and the user must request to see the location of others on his Buddy Lists to be able to have their positions reported and/or mapped"). Thus, "authenticated access" helps further objectives of the invention disclosed in the specification. Compare, e.g., World Class Tech. Corp. v. Ormco Corp., 769 F.3d 1120, 1125 (Fed. Cir. 2014) (affirming construction of "support surface" in orthodontic device patent that required engaging "the moveable member during the entire time that the member was slidingly moved" because it best aligned with specification and its discussion that the problem the invention solved). This supports the Court's conclusion that "account" requires "authenticated access."
Uber, nevertheless, argues that requiring "authenticated access" improperly imports limitations from the specification into the claims. Responsive Br. 7. The Court agrees that, ordinarily, limitations set forth in a preferred embodiment disclosed in a specification do not limit the scope of the claims. See, e.g., Liebel-Flarsheim Co. v. Medrad, Inc., 358 F.3d 898, 908 (Fed. Cir. 2004). However, here, the concept of "authenticated access" is not only consistently disclosed in every server-dependent embodiment, but is also a concept that flows naturally from the stated objectives of the invention. As such, the specification supports construing "account" such that it requires "authenticated access." See GPNE, 830 F.3d at 1370 (affirming construction of "node" as a "pager" where "the words 'pager' and 'pager units' appear in the specification over 200 times, and, apart from the Abstract, the specification repeatedly and exclusively uses these words to refer to the devices in the patented system"); In re Abbott Diabetes Care Inc., 696 F.3d 1142, 1149 (Fed. Cir. 2012) (holding that the conclusion that the claimed electrochemical sensor could not have external wires was supported by: (1) "every embodiment disclosed in the specification shows . . . [a] sensor without external cables or wires," and (2) the discussion of the prior art in the specification identified external cables or wires as a deficiency in the prior art supported). Uber's arguments to the contrary are unconvincing.
At the Markman hearing, Uber also expressed concern that X One's proposed construction injects a password-like requirement into "account" which requires that authentication itself is "user-specific." Uber argued that such "user-specific authenticated access" excludes a preferred embodiment because the specification discloses that whole groups of people can be authenticated using a single access code: "[l]arge groups with many phones, [sic] can ask for and receive access codes that allow operation across a large number of phones." '593 patent, col. 23:33-35. The Court agrees with Uber that the authentication mechanism need not be discrete for each individual user. Instead, as Uber points out, multiple users could be authenticated using a single, shared access code. Id. However, even with a single, shared access code, it is still the individual user that is being authenticated. See id., col. 23:30-39 (describing how "access codes"—whether discrete or shared—"are downloaded to the phone from the cell provider's server or emailed to the user when the user provides their name, phone number, phone serial number and a form of payment."). In this sense, then, the authentication is "user-specific." Thus, the Court finds that X One's proposed construction of "user-specific authenticated access" does not exclude this embodiment.
In sum, because the specification consistently discloses server embodiments that include authentication, the term "account" requires "authenticated access."
b. Extrinsic Evidence
i. Dictionary Definitions
The conclusion that "account" requires "authenticated access" is also supported by the dictionary definitions submitted by X One. The Federal Circuit has approved the use of dictionaries—and especially technical dictionaries—"as among the many tools that can assist the court in determining the meaning of particular terminology to those of skill in the art of the invention." Phillips, 415 F.3d at 1318. The Federal Circuit has observed that dictionaries can be especially helpful where, as is the case here with "account," a claim term does not itself appear in the specification. See, e.g., HBAC Matchmaker Media, 650 F. App'x at 993 (relying on technical dictionaries where the term "head end system" was "not defined or recited in the specification").
Here, a computer dictionary from around the time of invention defines "account" as "a record of a user's name, password and rights to access a network or online system." Mot. Ex. 2 at XONE0104061. In addition, the non-technical Oxford English Dictionary defines "account" as "an arrangement whereby a user is given (freq. personalized) access to a website, program, system, etc., typically by entering username and password at a prompt; the data and setting specific to each user of the website." Mot. Ex. 1 at XONE0104061. A common thread in both of these definitions is that an "account" includes some form of authenticated access. Although it is true—as Uber points out, Responsive Br. 8—that at least the Oxford English Dictionary uses qualifiers such as "freq[uently]" and "typically," the fact that "account" is generally associated with authenticated access suggests that a person of ordinary skill in the art would commonly read the term "account" in claims 1 and 19 to include "authenticated access." This supports the Court's conclusion that "account" requires "authenticated access."
ii. Dr. Bartone's Testimony
The testimony of Uber's expert, Dr. Bartone, in its IPR petition is not inconsistent with this conclusion. Dr. Bartone opined that a "person of ordinary skill in the art would understand that an account is used to enable an individual to access data." Mot. Ex. 3 ¶ 47. One way to allow individual access is through authentication. Thus, construing "account" to require "authenticated access" does not conflict with this testimony.
c. Conclusion
As set forth above, while the claim language does not explicitly require that "account" include "authenticated access," the specification and relevant dictionary definitions support the conclusion that "account" includes "authenticated access." The Court therefore adopts X One's position and construes "account" to mean "an arrangement for user-specific authenticated access."
2. "buddy list" (claims 1 and 19)
| X One's Proposed Construction | Uber's Proposed Construction |
|---|---|
| user list | a list, corresponding to an account of the firstindividual, that identifies multiple other userswhose location may be shared with the firstindividual and/or who may receive the locationof the first individual |
The term "buddy list" appears in claims 1 and 19. For example, claim 1 recites:
1. An apparatus, comprising:
a server;
a database representing an account for a first individual, the account having an associated buddy list that identifies multiple users; and
software responsive to a request from the first individual to obtain a map, to obtain a last known position for multiple users identified by the buddy list, and to plot the last known location of at least two of the multiple users on the map, and to transmit the map with plotted locations to the first individual;
where the software is to request and store position information associated with
'593 patent, col. 28:51-29:4 (emphasis added).cell phones of plural ones of the multiple users and where the software is to permit the first individual to change geography represented by the map and to transmit to the first individual a map representing the changed geography with plotted position of at least one of the multiple users, each in a manner not requiring concurrent voice communications; and
wherein the software to obtain the map is to obtain the map in a manner having a default geographic resolution.
X One argues that "buddy list" should be construed to mean a "user list." Opening Br. 11. Uber argues that "buddy list" should be construed to mean "a list, corresponding to an account of the first individual, that identifies multiple other users whose location may be shared with the first individual and/or who may receive the location of the first individual." Responsive Br. 9. Hence, the parties agree that "buddy list" is a list of users, but disagree as to whether a "buddy list" (1) must identify multiple other individuals in addition to the first individual; (2) requires information about location sharing; and (3) corresponds to an account of the first individual. The Court addresses each of these disputes in turn.
a. Whether the "buddy list" must identify multiple other individuals in addition to the first individual
The parties first dispute whether a "buddy list" must identify multiple other individuals in addition to the first individual. X One contends that the "buddy list" can include just the "first individual" and one other user. Opening Br. 12-14. Uber agrees that a "buddy list" can include the "first individual," Responsive Br. 14, but argues that it must also include at least two other users who are not the "first individual," id. 9-14. Here, the Court agrees with Uber.
i. Claim Language
The claim language modestly favors Uber's position. Claim 1 recites an "account for a first individual . . . having an associated buddy list that identifies multiple users." It then recites:
software responsive to a request from the first individual to obtain a map, to obtain a last known position for multiple users identified by the buddy list, and to plot the last known location of at least two of the multiple users on the map, and to transmit the map with plotted locations to the first individual'543 patent, col. 28:57-61 (emphasis added). Although the claim simply says "multiple users" and not "multiple other users," the most common sense reading of this limitation is that the "at least two of the multiple users" are users other than the "first individual." The claim language uses different words—"first individual" and "multiple users"—to refer to each. See Bd. of Regents of the U. of Texas System v. BENQ Am. Corp., 533 F.3d 1362, 1371 (Fed. Cir. 2008) ("Different claim terms are presumed to have different meanings.") (citations omitted). Further, it makes more sense that the first individual would want to "obtain the last known position" of other individuals than he would his own.
This conclusion becomes stronger when claim 1 is compared with claim 4. Rexnord Corp. v. The Laitram Corp., 274 F.3d 1336, 1342 (Fed. Cir. 2001) ("a claim term should be construed consistently with its appearance in other places in the same claim or in other claims of the same patent"); CVI/Beta Ventures, Inc. v. Tura LP, 112 F.3d 1146, 1159 (Fed. Cir. 1997) ("[W]e are obliged to construe the term 'elasticity' consistently throughout the claims."). Claim 4 recites:
4. The apparatus of claim 3, where the software provides a distance from the first individual to each of the at least two of the multiple users.'543 patent, col. 29:11-13. It makes more sense that the first individual would want to know his distance to two other users, rather than his distance to himself (i.e., 0) and one other user. Thus, the claim language modestly favors Uber's position.
Nevertheless, the claim language is not perfectly clear and does not entirely exclude the possibility that the "first individual" is not one of the "multiple users." Thus, the Court turns to the specification for further guidance.
ii. Specification
Reviewing the specification's disclosures of "buddy lists," the Court finds that the specification also supports Uber's position. In a number of instances, the specification uses the word "others"—plural—to refer to users on a buddy list. '593 patent, col. 2:57-61 ("The user must allow others on his Buddy Lists to 'see' his location . . . and the user must request to see the location of others on his Buddy Lists to be able to have their positions reported and/or mapped.") (emphasis added), col. 7:24-26 ("the Buddy Tracker location sharing application software is active and is sharing the location of the phone with other members of a designated group") (emphasis added), col. 8:12-14 ("the wireless devices in a group which has location tracking turned on periodically send their GPO position data to all the other members in the group.") (emphasis added). In addition, the specification several times contrasts a buddy list of several users with just a single user. Id., col. 8:31-33 ("The requested position update may be sent to everybody on a selected Buddy List or just a single person's wireless device."), col. 10:2-3 ("Addresses of all persons on the buddy list or just a selected buddy are located in step 222. Message packets are generated in 224 addressed to the selected Buddy List or individuals, and encrypted position data is put in them."). By contrast, there are no instances where the specification explicitly discloses a buddy list of one other user. See generally id., col. 5:57-28:48.
X One nevertheless argues to the contrary that the specification does disclose a "buddy list" that contains only the first individual and one other user. It points to two instances: (1) Figure 2B; and (2) the instant buddy relationship, id., col. 11:50-12:9. Opening Br. 12-13. The Court finds that, on close examination, neither of these instances disclose a "buddy list" that contains only the first individual and one other user.
In addition, at the Markman hearing, X One also identified Figure 13 and its use of "person(s)"—singular or plural—in step 112 as an additional example of a "buddy list" that contains only the first individual and one other user. The Court disagrees that Figure 13 provides such an example. In describing Figure 13, the specification makes clear that Figure 13 refers to a "buddy list" that includes multiple other users. '593 patent, col. 8:31-33. The "person(s)" in step 112 refers to the specific buddy(ies) within a buddy list for which the first individual requests a location update. Id., col. 8:35-40 ("Step 112 represents the process of looking up the addresses for all people on the selected Buddy List . . . or just a selected individual . . . ."). Thus, Figure 13 only shows that it is possible for a first individual to request a location update from a single buddy on a "buddy list" that includes multiple other users.
The Court turns first to Figure 2B. Figure 2B is shown below:
Image materials not available for display. '593 patent, Fig. 2B. The specification discloses that "[i]n Figure 2B . . . [p]hone K has phone I on its Buddy List and is set up to supervise phone I." Id., col. 7:45-46. However, this does not mean that, in Figure 2B, phone K only has phone I on its buddy list. The specification makes clear that the purpose of Figure 2B is simply to "illustrate[] a matrix or web of supervisorial relationships." Id., col. 3:64-65, col. 7:37-40. A phone's buddy list can contain more than just the phones over which it has a supervisorial relationship. See, e.g., id., col. 7:27-30 (describing how a parent or supervisor can include a supervised phone in the buddy list), col. 17:31-35 (same). Because Figure 2B simply "illustrates . . . supervisorial relationships," it is impossible to know whether phone K only has phone I on its buddy list or whether phone K also has other phones on its buddy list. As such, the Court cannot rely on Figure 2B as an embodiment of a "buddy list" that contains only the first individual and one other user.
The Court next turns to the instant buddy relationship. The specification defines the instant buddy relationship as "temporary location sharing between phones on an ask and accept basis which automatically expires after a configurable interval terminates." Id., col. 1:64-67. Read in its entirety, the specification makes clear that the instant buddy relationship is a different feature from the "buddy list." It shows this in at least four different ways. First, the specification consistently uses different terms to refer to each of these features: "Buddy List" and "Instant Buddies," both capitalized. See, e.g., Id., col. 11:20-12:9. Second, the specification's descriptions of each are discrete. For example, in describing Figure 14, the specification separately lists "Buddy Lists" and "Instant Buddies" as two of "several modes" and provides separate, back-to-back descriptions of each. Id. Third, the specification describes "Instant Buddies" as something separate that can be displayed alongside the contents of a "Buddy List." For example, Figure 3 illustrates a "typical screen showing a named buddy list's contents." Id., Fig. 3. This display "shows individuals on the phone's Buddy List," "a group of buddies which has been given the name Tennis Team," and "an instant buddy entry for an instant buddy named Inst01." Id., col. 15:15-16, col. 15:26-27. Thus, the fact that an "Instant Budd[y]" is displayed in addition to the "individuals on the phone's Buddy List" shows that an instant buddy relationship cannot itself be a "buddy list." Fourth and finally, in describing the "Buddies Only Mode," the specification distinguishes a "buddy list" from the instant buddy relationship by describing that the "Buddies Only Mode" feature is only available for a "Buddy List," but not "Instant Buddies." Id., col. 18:53-58 (describing how in "Buddies only mode . . . position reports are only received from Buddies on a specifically named Buddy List with specifically named Buddies. No . . . Instant Buddy position reports can be received in this mode."). Thus, in at least four different ways, the specification makes clear that the instant buddy relationship is a separate feature from the "buddy list." As such, the instant buddy relationship is not an example of a "buddy list" that contains only the first individual and one other user.
In sum, the specification confirms what the claim language already modestly suggests: the "buddy list" must include at least two other users who are not the "first individual."
iii. Conclusion
The parties do not rely on prosecution history or extrinsic evidence to support their positions. Thus, based on the claim language and specification, the Court agrees with Uber that the "buddy list" must include at least two other users who are not the "first individual."
b. Whether the "buddy list" requires information about location sharing
The parties next dispute whether the "buddy list" requires information about location sharing. Uber's proposed construction requires that the "multiple other users" are those "whose location may be shared with the first individual and/or who may receive the location of the first individual." X One contends that "and/or who may receive the location of the first individual" should not be included in the Court's construction because this improperly introduces a two-way location sharing feature, which is unsupported by the claims or specification. Opening Br. 14-15. Uber defends its proposal as consistent with the specification and helpful to the jury. Responsive Br. 13-14. For the reasons discussed below, the Court agrees with X One.
i. Claim Language
The claim language does not support including "and/or who may receive the location of the first individual" within the meaning of "buddy list." Claims 1 and 19 specifically recite that the "multiple users" share their location information with the first individual. See '593 patent, col. 28:56-29:2, col. 30:54-31:2. They do not, however, recite that data flows in the other direction—i.e., that the first individual shares his location information with the "multiple users." See id. Thus, the phrase "and/or who may receive the location of the first individual" introduces a two-way location sharing feature that is not supported by the plain language of claims 1 and 19.
ii. Specification
The specification also does not support including "and/or who may receive the location of the first individual" within the meaning of "buddy list." The specification discloses embodiments where location sharing is unidirectional. See, e.g., id., col. 7:32-37 ("This supervisory location sharing can be hierarchical such that an employer can see the location of all its employees, and each of the employees can be set up as supervisor of their children such that the employees can see the locations of their children, but the employer of each employee cannot see the locations of the children of each employee."), col. 17:38-41 ("[T]he location information sharing is unidirectional from employees to supervisor but each employee can see the location of other employees on their phones but not the location of the supervisor."). Requiring that the "multiple users" "receive the location of the first individual" would exclude these embodiments. See Victronics, 90 F.3d at 1583 (a construction that excludes a preferred embodiment is "rarely, if ever, correct").
The Court notes that Uber's proposal is written in the permissive ("may") and thus does not go so far as to categorically exclude unidirectional location sharing. Nevertheless, even if "and/or who may receive the location of the first individual" only suggests that two-way location sharing is possible, the Court finds it proper to exclude this phrase because it would be confusing and unhelpful to the jury. "'Claim construction' is for the purpose of explaining and defining terms in the claims . . . ." Abbott Labs. v. Sandoz, Inc., 544 F.3d 1341, 1360 (Fed. Cir. 2008). A construction written in the permissive suggesting that an additional feature "may" be part of the invention does not serve this purpose. Thus, the Court finds that the best course of action is to not include "and/or who may receive the location of the first individual" in its construction of "buddy list." In sum, the Court agrees with X One that "and/or who may receive the location of the first individual" should not be included in the construction of "buddy list."
c. Whether the "buddy list" corresponds to an account of the first individual
The parties' final dispute is whether the "buddy list" corresponds to an account of the first individual. Uber's proposed construction requires that the "buddy list" is "a list, corresponding to an account of the first individual." Responsive Br. 9. X One argues that "corresponding" is an improper redrafting of claims 1 and 19, which recite "a database representing an account for a first individual, the account having an associated buddy list that identifies multiple users." Opening Br. 15-16. Uber defends "corresponding" as consistent with the plain meaning of the claim language. Responsive Br. 14.
The parties largely agree on substance: whether the buddy list is "associated" with the first individual or "corresponds" to the first individual, the broader point is that there is some relationship between the two. However, because the claim language uses the word "associated" and Uber makes no argument as to why "corresponding" would assist the jury or is otherwise a superior choice, the Court sees no reason to change "associated" to "corresponding." See Abbott Labs, 544 F.3d at 1360 ("'Claim construction' is for the purpose of explaining and defining terms in the claims . . . ."). Thus, the Court will use "associated" in its construction.
d. Conclusion
As set forth above, the Court agrees with Uber that the "buddy list" must include at least two other users who are not the "first individual." However, the Court agrees with X One that Uber's proposed language of "and/or who may receive the location of the first individual" and "corresponding" should not be included in the construction of "buddy list." Accordingly, the Court adopts a modified version of Uber's proposal. The Court construes "buddy list" to mean "a list, associated with an account of the first individual, that identifies multiple other users whose location may be shared with the first individual."
3. "a database representing an account for a first individual, the account having an associated buddy list that identifies multiple users" (claims 1 and 19)
| X One's Proposed Construction | Uber's Proposed Construction |
|---|---|
| A database including data related to a first | a database accessible by the server that |
| individual who is authorized to access and usethe software. A buddy list is associated withthe first individual's account. | includes an account for a first individual, theaccount having a list of multiple other usersthat identifies those users whose location maybe shared with the first individual and/or whomay receive the location of the first individual |
The disputed phrase "a database . . ." appears in claims 1 and 19. For example, claim 1 recites:
1. An apparatus, comprising:
'593 patent at col. 28:51-29:4 (emphasis added).a server;
a database representing an account for a first individual, the account having an associated buddy list that identifies multiple users; and
software responsive to a request from the first individual to obtain a map, to obtain a last known position for multiple users identified by the buddy list, and to plot the last known location of at least two of the multiple users on the map, and to transmit the map with plotted locations to the first individual;
where the software is to request and store position information associated with cell phones of plural ones of the multiple users and where the software is to permit the first individual to change geography represented by the map and to transmit to the first individual a map representing the changed geography with plotted position of at least one of the multiple users, each in a manner not requiring concurrent voice communications; and
wherein the software to obtain the map is to obtain the map in a manner having a default geographic resolution.
Comparing the parties' proposals, the parties dispute two related issues: (1) whether the database must store the account; and (2) whether the database is accessible by the server. The Court addresses each of these disputes in turn.
In addition, in its Opening Brief, X One identified "whether the database must . . . also store a user's buddy list" as a disputed issue. Opening Br. 16. In its responsive brief, Uber rephrased this issue as "whether the account has a buddy list." Responsive Br. 15. In comparing the parties' briefing on this topic, the Court discerns no actual dispute. X One's only argument in its briefing on this topic is that "the buddy list need not be stored in the same database as the account data." Opening Br. 17. Uber agrees with this. Responsive Br. 16 ("Uber's proposed construction does not place a restriction on where or how the buddy list is stored"). Thus, the Court deems this issue resolved and adopts the parties' positions that the claimed "database" need not store the buddy list.
a. Whether the database must store the account
The parties' first dispute is whether the database must store the account. X One argues that the database need only store "data related to a first individual"—not the account itself—because the claim language requires no more than this. Opening Br. 16-17. Uber argues that the database should store the account itself because in order for the database to "represent[]" the account, it must include the account. Responsive Br. 16. For the reasons discussed below, the Court agrees with X One.
i. Claim Language
The claim language resolves the parties' dispute. Claims 1 and 19 only require "a database representing an account." '593 patent, col. 28:53, col. 30:51 (emphasis added). A representation of a thing need not be the thing itself. Compare, e.g., Tehrani v. Hamilton Med., Inc., 331 F.3d 1355, 1361 (Fed. Cir. 2003) ("[T]he ordinary meaning of 'representing' is broad enough to include 'symbolizing' or 'to stand for' . . . . On the other hand, the statement that one item 'represents' another cannot be interpreted so broadly as to include any case in which the two items are related in some way. Rather, the first item must be directly related to and stand for, or be a reasonable proxy for, the latter item."); ART+COM Innovationpool Gmbh v. Google Inc., No. CV 1:14-217-TBD, 2016 WL 2945194, at *2 (D. Del. May 20, 2016) ("[T]he ordinary meaning of 'representing' is broader than 'displaying on a screen' and can include symbolizing, standing for, or being a reasonable proxy for a subsequent viewable image."). Thus, unless the specification or prosecution history otherwise compel it, "representing" is entitled to the full scope of its plain and ordinary meaning. Wasica Fin. GmbH v. Cont'l Auto. Sys., Inc., 853 F.3d 1272, 1281 (Fed. Cir. 2017) ("It is axiomatic that we will not narrow a claim term beyond its plain and ordinary meaning unless there is support for the limitation in the words of the claim, the specification, or the prosecution history.") (quoting 3M Innovative Props. Co. v. Tredegar Corp., 725 F.3d 1315, 1333 (Fed. Cir. 2013). Consistent with the Federal Circuit's and other courts' assessments of the word "representing," this plain and ordinary meaning would require that the "represent[ation] of the account" is directly related to and standing for the account, but nothing more restrictive.
ii. Specification and Prosecution History
Neither party identifies anything in the specification or prosecution history that warrants a narrower construction of "representing." Opening Br. 16-18; Responsive Br. 15-16. Thus, the Court will not narrow its meaning beyond the plain and ordinary meaning discussed above. Accordingly, the Court agrees with X One that the database need not store the actual account.
b. Whether the database must be accessible by the server
The parties' next and final dispute is whether the database must be accessible by the server. X One argues that the database need not be accessible by the server because the claim language is silent on this point. Opening Br. 17-18. Uber argues that the database must be accessible by the server because the specification discloses that this is the case. Responsive Br. 16. The Court agrees with Uber.
i. Claim Language
Beginning with the claim language, the Court notes that the claims do not explicitly state where the "database" is stored and whether it is accessible by the server. See '593 patent, col. 28:51-29:4, col. 30:49-31:2. However, when "database" is read in context with the remainder of the claim language, the claim language supports Uber's position that the "database" is "accessible by the server." ACTV, Inc. v. Walt Disney Co., 346 F.3d 1082, 1088 (Fed. Cir. 2003) ("[T]he context of the surrounding words of the claim also must be considered in determining the ordinary and customary meaning of those terms."). Specifically, after the claims recite "a database representing an account . . . having an associated buddy list . . . ," the claims immediately recite operations that are performed by "software" using this "buddy list" information, such as "obtain[ing] a last known position for multiple users identified by the buddy list." '593 patent, col. 28:56-61, col. 30:54-58. As determined below with respect to "last known location," this "software" is run on the "server." See Section III.A.4, infra. Thus, it makes sense that, in order for the "software" to be able to perform the recited operations with respect to the "buddy list," the "database" must be accessible by the "server." As such, the claim language supports Uber's position.
ii. Specification
The specification provides further support for Uber's position. In its section on "The Server Genus," the specification discloses that "[a]ll servers programmed with the Buddy Watch software will have functionality to . . . store user defined data that embodies each user's buddy lists and buddies and configuration data." '593 patent, col. 25:6-10. This statement does not simply describe a preferred embodiment. Instead, it is an explicit characterization of all of the "servers" in the invention. See Aventis Pharma S.A. v. Hospira, Inc., 675 F.3d 1324, 1330 (Fed. Cir. 2012) (A "clear expression [to define a claim term] need not be in haec verba but may be inferred from clear limiting descriptions of the invention in the specification or prosecution history."); see, e.g., Stumbo v. Eastman Outdoors, Inc., 508 F.3d 1358, 1363 (Fed. Cir. 2007) (holding that a district court correctly interpreted claims to require a feature based the specification's teaching of what "must" be present). Thus, the "server" in claims 1 and 19 must have the "functionality . . . to store data that embodies each user's buddy lists and buddies and configuration data." '593 patent, col. 25:6-10. It follows that if the server can store this data, this data is accessible to the server. This conclusion is bolstered by other portions of the specification, which describe preferred embodiments where a database is accessible to a server. Id., col. 6:11-15 (describing how "[a] response to the request in the packet [from a device] is prepared using information from a database maintained by the Rubicon server"), col. 12:39-40 (listing "database access and maintenance" as a "function[] of the Buddy Watch server"). Accordingly, the claimed "server" includes "functionality to . . . store data that embodies each user's buddy lists and buddies and configuration data."
That said, the Court does not read the specification as requiring that the claimed "database" is the same as the server's "functionality . . . to store data that embodies each user's buddy lists and buddies and configuration data." '593 patent, col. 26:6-10. It may be, for example, that the server has this "functionality . . ." but then additionally the claimed "database" is stored somewhere else. Nevertheless, the fact that the server has this "functionality . . . to store data that embodies each user's buddy lists and buddies and configuration data," id., at least bolsters the conclusion that the claimed "database" that contains "represent[ations] of this data" is accessible by the "server."
Accordingly, the specification supports what the claim language already suggests: the "database" must be accessible by the server.
c. Conclusion
In sum, the Court finds that (1) the "database" need not store the account; but (2) the "database" must be accessible by the server. In addition, the parties agree that the "database" need not store the buddy list. Compare Opening Br. 16, with Responsive Br. 16.
As the Court has resolved one dispute in favor of X One and one dispute in favor of Uber, the Court must determine which of the parties' competing constructions it should use as a model for its own. On this point, the Court finds that the structure of Uber's proposed construction would be more clear and helpful to the jury. See Abbott Labs, 544 F.3d at 1360 ("'Claim construction' is for the purpose of explaining and defining terms in the claims . . . ."). Uber's proposed construction is a crisp phrase that parallels the grammatical structure of the disputed limitation and incorporates the construction of "buddy list," whereas X One's proposed construction consists of two bulky sentences that do not define "buddy list." The Court will thus adopt the structure of Uber's proposal, but modify it to reflect the Court's resolution of the parties' dispute. The Court construes "a database representing an account for a first individual, the account having an associated buddy list that identifies multiple users" to mean "a database accessible by the server that includes data directly related to and standing for an account for a first individual, the account having an associated list that identifies multiple other users whose location may be shared with the first individual."
4. "last known location" (claims 1 and 19)
| X One's Proposed Construction | Uber's Proposed Construction |
|---|---|
| plain meaning | most-recent position stored on the server for auser at the time the user's position is plottedon the map |
The term "last known location" appears in claims 1 and 19. For example, claim 1 recites:
1. An apparatus, comprising:
a server;
a database representing an account for a first individual, the account having an
'593 patent, col. 28:51-29:4 (emphasis added).associated buddy list that identifies multiple users; and
software responsive to a request from the first individual to obtain a map, to obtain a last known position for multiple users identified by the buddy list, and to plot the last known location of at least two of the multiple users on the map, and to transmit the map with plotted locations to the first individual;
where the software is to request and store position information associated with cell phones of plural ones of the multiple users and where the software is to permit the first individual to change geography represented by the map and to transmit to the first individual a map representing the changed geography with plotted position of at least one of the multiple users, each in a manner not requiring concurrent voice communications; and
wherein the software to obtain the map is to obtain the map in a manner having a default geographic resolution.
X One argues that "last known location" requires no construction. Opening Br. 18-20. Uber argues that "last known location" should be construed to mean "most-recent position stored on the server for a user at the time the user's position is plotted on the map." Responsive Br. 16-20. Hence, the parties dispute whether (1) a user's "last known location" is stored on the server; and (2) the "last known location" is determined at the time a user's position is plotted on the map. The Court addresses each of these disputes in turn.
a. Whether the user's "last known location" is stored on the server
i. Claim Language
Beginning with the claim language, the Court notes that it does not explicitly recite where the "last known location" is stored. Nevertheless, read in its entirety, the Court finds that the claim language, on balance, favors Uber's position. Claims 1 and 19 recite a "server." '593 patent, col. 28:52, col. 30:50. Then, they recite "software" which performs server-like functions, such as "obtain a map," "obtain a last known position for multiple users identified by the buddy list," "plot the last known location of at least two of the multiple users on the map," "transmit the map with plotted locations to the first individual," and "request and store position information associated with cell phones of plural ones of the multiple users." Id., col. 28:57-64. Thus, the most logical reading of this claim language is that the "software" runs on the server. If this is true, this means that when the "software . . . request[s] and store[s] position information," this "position information"—including the "last known location"—is stored on the server. As such, reading "last known location" in the context of the rest of the claims supports Uber's position that "last known location" is stored on the server.
ii. Specification
The specification confirms that the "software" is run on the server. In describing "The Server Genus," the specification lists many of the same functions that are attributed to the "software" in claims 1 and 19 as functions of which "[a]ll servers programmed with Buddy Watch software" will be capable. '593 patent, col. 24:59-25:21 (disclosing that "[a]ll servers programmed with Buddy Watch software will have functionality to . . . obtain pertinent map data," "request and receive update and regularly scheduled GPS location data from users," "render buddy locations on maplets based upon GPS location data," and "serve the maplet data to Buddy Watch enabled phones"). As stated above with respect to "database," this is an explicit definitional statement about all servers, not just a description of a preferred embodiment. See Section III.A.3, supra. This is further bolstered by portions of the specification that explicitly disclose that the server stores location information. E.g., '593 patent, col. 17:59-61 ("The server receives positions reports from all the Buddy Watch phones registered with it and stores them and knows the Buddy Lists for each phone."). Thus, when read in light of the specification, the "software" in claims 1 and 19 is "software" that resides on the server.
As discussed above, the claims require that the "software . . . store position information," and wherever the software is run is also where the "position information" is "stor[ed]." Thus, because, as discussed above, the specification makes clear that the "software" is run on the server, the "position information"—including the "last known location"—is also stored on the server.
X One nevertheless argues that the "last known location" need not be stored on the server because the specification discloses embodiments where a user's last known location is not sent to (and hence, not stored on) the server, but is instead sent directly from one device to another. Opening Br. 19 (citing '543 patent, col. 8:40-9:65). However, as discussed above with respect to "account," claims 1 and 19 specifically require a "server." See Section III.A.1, supra. Thus, in construing claims 1 and 19, the Court must focus on disclosed embodiments in the specification that include a server. Accordingly, the device-to-device embodiments that X One cites fall outside the scope of claims 1 and 19 and have little relevance to their construction.
X One also cites to embodiments which X One describes as "sending a user's last known location to a server that, rather than storing it, simply forwards it to another user's mobile device." Opening Br. 19 (citing '543 patent, col. 9:66-10:34). The Court disagrees that this embodiment does not store the last known location. The specification does not support X One's assertion.
In sum, the specification confirms what the claim language modestly suggests: Uber is correct that the "last known location" is stored on the server.
b. Whether the "last known location" is determined at the time a user's position is plotted on the map
The claim language is sufficient to end the parties' dispute. Claims 1 and 19 recite a fluid set of actions that occur "responsive to a request from the first individual:" "obtain[ing] a map," "obtain[ing] a last known position for multiple users," and "plot[ting] the last known location of at least two of the multiple users on the map." '593 patent, col. 28:57-61, col. 30:60-64. Putting these statements together, the "last known location" must be determined at the time of plotting. It would not make sense for it to be determined before the time of plotting because that would mean that the plotting was not "responsive" to the first individual's request. It would also not make sense for it to be determined after the time of plotting, because, in order to "plot[] the last known location," that "last known location" must first be determined. Thus, the "last known location" is determined at the time of plotting.
Nevertheless, having determined that "last known location" is determined at the time of plotting still leaves open the question of whether Uber's proposed language of "most-recent position stored on the server" better captures this meaning than the claim language itself. X One argues that "most-recent position stored on the server" ignores the fact that a user may have several "last known locations" depending on the buddy list: a user may choose to share his location with one buddy all the time, whereas the user may choose to share his location with another buddy only sometimes. Opening Br. 19-20; Reply Br. 8-9. Uber does not specifically respond to this argument. Responsive Br. 16-20.
The Court agrees with X One that "most-recent position stored on the server" injects some confusion into the meaning of "last known location" because different buddy lists could have different "last known locations." Compare, e.g., '593 patent, col. 11:12-19 (describing a buddy list where location sharing is always on), with id., col. 11:25-27 (describing a buddy list where location sharing is only on during work hours). However, the Court finds that this problem can be remedied by modifying "most-recent position" in Uber's proposed construction to "most-recent shared position," which makes clear that "most-recent" is limited to only the location information that that user has shared with a particular buddy list. Thus, the Court will adopt Uber's proposed construction, subject to this modification.
c. Conclusion
In sum, the Court finds that (1) a user's "last known location" is stored on the server; and (2) the "last known location" is determined at the time a user's position is plotted on the map. The Court, however, agrees with X One that "last known location" can be different depending on the buddy list used. As such, the Court adopts a modified version of Uber's proposed construction. The Court construes "last known location" to mean "most-recent shared position stored on the server for a user at the time the user's position is plotted on the map."
B. '647 Patent
1. "wherein the provider is selected in connection with the request for the desired service" (claims 1 and 28) / "selecting the provider of the desired service" (claim 22)
| X One's Proposed Construction | Uber's Proposed Construction |
|---|---|
| plain meaning | wherein the requestor of the desired serviceselects the provider of the desired service /selecting the provider of the desired service bythe requestor of the desired service |
The phrase "wherein the provider is selected in connection with the request for the desired service" appears in claims 1 and 28 of the '647 patent. The phrase "selecting the provider of the desired service" appears in claim 22. For example, claims 1 and 22 recite:
1. A method of tracking proximity of position associated with a first wireless device relative to a position of a second wireless device, wherein one of the first wireless device and the second wireless device is associated with a provider of a desired service and the other of the first wireless device and the second wireless device is associated with a requestor of the desired service, the method comprising:
causing receipt of information on the first wireless device representing the position of the second wireless device and a map associated with the position associated with the first wireless device and the position of second wireless device;
causing display of the map on the first wireless device with position associated with the first wireless device and the position of the second wireless device rendered thereon; and
causing receipt of information on the first wireless device representing positional update of the second wireless device, and causing update of display of the map on the first wireless device with the position associated with the first wireless device and updated position of the second wireless device rendered thereon;
wherein the causing of the update is to be performed to indicate proximity of and direction between position of the provider of the desired service and position associated with the requestor of the desired service;
wherein the method is invoked responsive to launching an application on the first wireless device in connection with a request from the requestor for the desired service; and
wherein the provider is selected in connection with the request for the desired service and the method further comprises forming a use-specific group to have the first wireless device and the second wireless device in connection with the request for the desired service.
22. A method of tracking proximity of position associated with a first wireless device relative to position of a second wireless device, wherein the first wireless device is associated with a requestor of a desired service and the second wireless device is associated with a provider of the desired service, the method comprising:
selecting the provider of the desired service in association with an application launched by the requestor on the first wireless device, wherein the second wireless device is associated with the provider and is thereby selected in associated [sic] with launch of the application;
causing receipt of information on the first wireless device representing position of the provider, dependent on global positioning system (GPS) position data provided by the second wireless device, and receipt of information representing a map associated with the position associated with
'647 patent, col. 28:50-29:19, col. 30:47-31:12 (emphasis added).the first wireless device and the position of the second wireless device;
causing display of the map on the first wireless device with the position associated with the requestor and the position of the second wireless device rendered thereon; and
causing receipt of information on the first wireless device representing intermittent positional update dependent on GPS position data provided by the second wireless device, and causing update of display of the map on the first wireless device with respective position associated with the first wireless device and positional update dependent on the GPS position data provided by the second wireless device rendered thereon;
wherein selecting the provider of the desired service includes forming a use-specific group to have the first wireless device and the second wireless device in connection with the request for the desired service.
X One argues that the disputed phrases require no construction and should be given their plain meaning. Opening Br. 20-21. Uber, on the other hand, argues that the phrase "wherein the provider is selected in connection with the request for the desired service" in claims 1 and 28 should be construed to mean "wherein the requestor of the desired service selects the provider of the desired service." Responsive Br. 20-22. Uber argues that the phrase "selecting the provider of the desired service" in claim 22 should be construed to mean "selecting the provider of the desired service by the requestor of the desired service." Id. Comparing these proposals, the parties' dispute boils down to a simple issue: whether anyone (X One's position) or only the "requestor" (Uber's position) can select the service provider. For the reasons discussed below, the Court agrees with X One.
i. Claim Language and Specification
The plain language of the claims only recites "selecting the provider" or that the "provider is selected," and does not specify who does the selecting. '647 patent, col. 30:47-31:12, col. 31:37-32:5. As a result, both sides focus on the specification. X One argues that the specification not only discloses embodiments where the requestor selects the service provider, but also embodiments where someone else—such as the service provider company—selects the service provider. Opening Br. 20-21. In particular, X One points to two embodiments: (1) a "stranded motorist or hiker" embodiment, '647 patent, col. 17:7-14; and (2) a skillset-based selection embodiment, id., col. 20:58-21:1. Uber responds that the "stranded motorist or hiker" embodiment confirms that only the requestor selects the service provider. Responsive Br. 21-22. Uber does not address the skillset-based selection embodiment. See id.
Upon reviewing each of the identified embodiments, the Court finds that the specification does not support an inference that only the "requestor" can select the service provider. Turning first to the "stranded motorist or hiker" embodiment, the specification discloses that:
Typically, a stranded motorist or hiker will call a tow truck or 911 and get the caller ID and carrier of the tow truck driver or rescuer. The stranded motorist or hiker will then enter this information in boxes 72 and 76. Box 70 shows an instant buddy ID which is automatically assigned by the system. After entering the information, the request command shown at 80 is selected.'647 patent, col. 17:7-14. The key to the parties' dispute is the first sentence: after calling a tow truck or 911, the stranded motorist or hiker "get[s]" the caller ID and carrier of his specific tow truck driver or rescuer. Id., col. 17:8-10. This phrase is ambiguous as to who does the selecting: in some cases, it may be that the 911 operator selects a tow truck or rescue service; in other cases, it may be that the stranded motorist or hiker himself requests a particular tow truck or rescue service, either by virtue of calling a particular tow truck service or by telling the 911 operator which service they would like to use. Thus, it does not support limiting the claims such that only the "requestor" may select a particular service provider.
Turning next to the skillset-based selection embodiment, the specification discloses that:
The Buddy Watch server is configured and programmed to be compatible with business applications where the customer may desire to find individuals based upon their capabilities, certifications or the equipment they are carrying. By making the Buddy Watch fields of the Buddy Watch database available for search and/or integration into other business databases, a company such as a service based organization can determine which individuals have the proper certification to work on a specific problem and/or who have the appropriate tools and where those individuals are located relative to a site to which the company wishes them to be dispatched.Id., col. 20:58-21:1 (emphasis added). In its plainest reading, this passage discloses that the "service based organization" can select a service provider. Specifically, the fact that the "service based organization can determine which individuals" have the fitting skillset implies that, through making this determination, the "service based organization" selects those individuals—i.e., service providers. See id., col. 20:64-21:1. Thus, the skillset-based selection embodiment supports Uber's position that entities other than the "requestor" can select the service provider.
ii. Conclusion
In sum, the claims are silent as to who can select the service provider and the specification supports the inference that entities other than the "requestor" can select the service provider. Accordingly, the Court agrees with X One that anyone—not just the "requestor"—can select the service provider. The claims, written in the passive voice, best reflect this meaning. Accordingly, the Court will not construe them further.
2. "responsive to launching an application" (claims 1 and 28) / "in association with an application launched" (claim 22)
| X One's Proposed Construction | Uber's Proposed Construction |
|---|---|
| plain meaning | in association with the running of theapplication |
The phrase "responsive to launching an application" appears in claims 1 and 28 of the '647 patent. The phrase "in association with an application launched" appears in claim 22. For example, claims 1 and 22 recite:
1. A method of tracking proximity of position associated with a first wireless device relative to a position of a second wireless device, wherein one of the first wireless device and the second wireless device is associated with a provider of a desired service and the other of the first wireless device and the second wireless device is associated with a requestor of the desired service, the method comprising:
causing receipt of information on the first wireless device representing the position of the second wireless device and a map associated with the position associated with the first wireless device and the position of second wireless device;
causing display of the map on the first wireless device with position associated with the first wireless device and the position of the second wireless device rendered thereon; and
causing receipt of information on the first wireless device representing positional update of the second wireless device, and causing update of display of the map on the first wireless device with the position associated with the first wireless device and updated position of the second wireless device rendered thereon;
wherein the causing of the update is to be performed to indicate proximity of and direction between position of the provider of the desired service and
position associated with the requestor of the desired service;
wherein the method is invoked responsive to launching an application on the first wireless device in connection with a request from the requestor for the desired service; and
wherein the provider is selected in connection with the request for the desired service and the method further comprises forming a use-specific group to have the first wireless device and the second wireless device in connection with the request for the desired service.
22. A method of tracking proximity of position associated with a first wireless device relative to position of a second wireless device, wherein the first wireless device is associated with a requestor of a desired service and the second wireless device is associated with a provider of the desired service, the method comprising:
'647 patent, col. 28:50-29:19, col. 30:47-31:12 (emphasis added).selecting the provider of the desired service in association with an application launched by the requestor on the first wireless device, wherein the second wireless device is associated with the provider and is thereby selected in associated [sic] with launch of the application;
causing receipt of information on the first wireless device representing position of the provider, dependent on global positioning system (GPS) position data provided by the second wireless device, and receipt of information representing a map associated with the position associated with the first wireless device and the position of the second wireless device;
causing display of the map on the first wireless device with the position associated with the requestor and the position of the second wireless device rendered thereon; and
causing receipt of information on the first wireless device representing intermittent positional update dependent on GPS position data provided by the second wireless device, and causing update of display of the map on the first wireless device with respective position associated with the first wireless device and positional update dependent on the GPS position data provided by the second wireless device rendered thereon;
wherein selecting the provider of the desired service includes forming a use-specific group to have the first wireless device and the second wireless device in connection with the request for the desired service.
X One argues that the disputed phrases require no construction and should be given their plain meaning. Opening Br. 21-23. Uber, on the other hand, argues that the disputed phrases should be construed to mean "in association with the running of the application." Responsive Br. 22-23. Thus, the parties dispute whether the claimed functions must be performed in association with the running of an application, or simply in association with either "launching an application" or "an application launched." For the reasons discussed below, the Court agrees with X One.
i. Claim Language and Specification
The plain language of the claims is silent as to what relation the claimed actions have to whether an application is running. See '647 patent, col. 28:50-29:19, col. 30:47-31:12, col. 31:37-32:5. Hence, if there is any support for Uber's proposed construction, it must be found in the specification. Upon review of the specification, the Court finds that it does not require the "running" modification that Uber proposes. In general, the specification describes the functionality of embodiments relating to service providers (i.e., embodiments relating to claims 1, 22, and 28) in the abstract, and does not specify what happens while an application is actively running. See, e.g., '647 patent, col. 15:27-38, col. 17:7-27. Moreover, the specification discloses that it is possible for devices to be temporarily disabled where the application would not be running. Id., col. 10:50-11:4, col. 22:5-11, col. 22:44-23:20. Accordingly, the specification also does not require the "running" modification that Uber proposes.
In its briefing, Uber does not make an affirmative case for why the Court should adopt its "running" modification. Instead, it devotes most of its briefing to arguing why X One's plain meaning position is incorrect. Although the Court has already rejected Uber's proposed "running" modification, it additionally finds that none of Uber's arguments against X One's plain meaning approach is persuasive. It discusses each in turn.
First, Uber argues that the phrases "responsive to launching" or "in association with an application launched" are vague. Responsive Br. 22-23. The Court disagrees. "Responsive to launching" simply places a temporal relationship on launching and the other claimed functions: they happen in response to launching. "In association with an application launched" is broader, and just requires some relationship between launching and the claimed functions. Thus, in both cases, how the claimed functions relate to launching is sufficiently clear. It may be that the claims are not as narrowly scoped as Uber would like, but this is not a reason to adopt a narrowing construction.
Second, Uber argues that the specification does not provide written description support for "responsive to launching" and "in association with an application launched." Responsive Br. 23. The Court disagrees. As Uber admits in its briefing (Responsive Br. 22-23), the specification discloses launching an application. See, e.g., '647 patent, col. 6:29-31 ("On startup, each handset starts its GPS sampler and the Buddy Watch application program."). Then, as Uber also admits (Responsive Br. 23), the specification discloses "display of [a] map." See, e.g., '647 patent, col. 6:31-41 (describing "show[ing] the Mapit page"), col. 15:26-38 (describing showing a tow truck driver and a stranded motorist on a moving map), col. 17:6-27 (same). The fact that these embodiments may require user action between the launching of the application and, for example, the display of the map does not negate the fact that the display of the map is at least indirectly "responsive to" or "in association with" launching. Cf. Pozen Inc. v. Par Pharm., Inc., 696 F.3d 1151, 1167 (Fed. Cir. 2012) ("As this court has explained, '[i]n order to satisfy the written description requirement, the disclosure as originally filed does not have to provide in haec verba support for the claimed subject matter at issue . . . . Nonetheless, the disclosure . . . must convey with reasonable clarity to those skilled in the art that . . . [the inventor] was in possession of the invention.'") (quoting Purdue Pharma L.P. v. Faulding Inc., 230 F.3d 1320, 1323 (Fed. Cir. 2000)). Thus, there is written description support for "responsive to launching" and "in association with an application launched."
Third and finally, Uber argues that "responsive to launching" or "in association with an application launched" excludes a preferred embodiment. Responsive Br. 23. The Court disagrees. As an initial matter, Uber does not specifically identify what this preferred embodiment is, but simply refers to it as "the preferred embodiment which requires user input while the application is running." Nevertheless, even without specifically addressing this purportedly excluded embodiment, the Court can conclude that it would not be excluded. "Responsive to launching" or "in association with an application launched" does not mean that the application cannot be running. Thus, a preferred embodiment which requires user input while the application is running would not be automatically excluded by "responsive to launching" or "in association with an application launched."
The Court can only guess that Uber is referring to one of the preferred embodiments discussed in other portions of its briefing, such as the "stranded motorist or hiker" embodiment, '647 patent, col. 15:26-38, col. 17:7-27. --------
ii. Conclusion
In sum, neither the claim language nor the specification warrants Uber's proposed construction. Instead, the Court finds that the claim language is sufficiently clear. The phrases "responsive to launching an application" and "in association with an application launched" shall be given their plain meaning and not construed further.
3. "forming a use-specific group" (claims 1 and 22) / "formation of a use-specific group" (claim 28)
| X One's Proposed Construction | Uber's Proposed Construction |
|---|---|
| plain meaning | Indefinite |
The phrase "forming a use-specific group" appears in claims 1 and 22 of the '647 patent. The phrase "formation of a use-specific group" appears in claim 28. Those claims recite:
28. A method of tracking proximity of position associated with a first wireless device relative to a position of a second wireless device, wherein one of the first wireless device and the second wireless device is associated with a provider of a desired service and the other of the first wireless device and the second wireless device is associated with a requestor of the desired service, the method comprising:
causing receipt of information on the first wireless device representing the position of the second wireless device and a map associated with the position associated with the first wireless device and the position of second wireless device;
causing display of the map on the first wireless device with position associated with the first wireless device and the position of the second wireless device rendered thereon; and
causing receipt of information on the first wireless device representing positional update of the second wireless device, and causing update of display of the map on the first wireless device with the position associated with the first wireless device and updated position of the second wireless device rendered thereon;
wherein the causing of the update is to be performed to indicate proximity of and direction between position of the provider of the desired service and
position associated with the requestor of the desired service;
wherein the method is invoked responsive to launching an application on the first wireless device in connection with a request from the requestor for the desired service; and
wherein the provider is selected in connection with the request for the desired service and the method further comprises forming a use-specific group to have the first wireless device and the second wireless device in connection with the request for the desired service.
22. A method of tracking proximity of position associated with a first wireless device relative to position of a second wireless device, wherein the first wireless device is associated with a requestor of a desired service and the second wireless device is associated with a provider of the desired service, the method comprising:
selecting the provider of the desired service in association with an application launched by the requestor on the first wireless device, wherein the second wireless device is associated with the provider and is thereby selected in associated [sic] with launch of the application;
causing receipt of information on the first wireless device representing position of the provider, dependent on global positioning system (GPS) position data provided by the second wireless device, and receipt of information representing a map associated with the position associated with the first wireless device and the position of the second wireless device;
causing display of the map on the first wireless device with the position associated with the requestor and the position of the second wireless device rendered thereon; and
causing receipt of information on the first wireless device representing intermittent positional update dependent on GPS position data provided by the second wireless device, and causing update of display of the map on the first wireless device with respective position associated with the first wireless device and positional update dependent on the GPS position data provided by the second wireless device rendered thereon;
wherein selecting the provider of the desired service includes forming a use-specific group to have the first wireless device and the second wireless device in connection with the request for the desired service.
28. An apparatus comprising instructions stored on non-transitory machine-readable media, the instructions when executed operable to:
cause receipt of information on the first wireless device representing position of the second wireless device and a map associated with position associated with the first wireless device and the position of the second wireless device;
cause display of the map on the first wireless device with the position association with the first wireless device and the position of the second wireless device rendered thereon; and
'647 Patent at col. 28:50-29:18, col. 30:47-31:12, col. 31:37-32:5 (emphasis added).cause receipt of information on the first wireless device representing positional update of the second wireless device, and cause update of display of the map on the first wireless device with the position associated with the first wireless device and updated position of the second wireless device rendered thereon;
wherein one of the first wireless device and the second wireless device is associated with a provider of a desired service, wherein the update of the display is to [be] performed to indicate proximity of and direction between the provider of the desired service and a position associated with a requestor of the desired service, wherein the causing of the receipt of the information representing the position, the causing of the display, and the causing of the receipt of information representing positional update are invoked responsive to launching an application on the first wireless device in connection with a request by the requestor for the desired service, wherein the provider is selected in connection with the request for the desired service, wherein the instructions when executed are to cause formation of a use-specific group to have the first wireless device and the second wireless device in connection with the request for the desired service.
X One argues that plain meaning governs. Opening Br. 23-25. Uber, on the other hand, argues that "[forming / formation of] a use-specific group" renders the asserted claims of the '647 patent indefinite. Responsive Br. 23-25.
In support of indefiniteness, Uber argues that the phrase "use-specific group" appears nowhere in the X One Patents and that the specification fails to explain what it means to "form[]" such a group. Id. On this latter point, Uber argues that neither the tennis team embodiment, '647 patent, col. 15:39-16:8, nor the employee/supervisor embodiment, id., col. 18:8-51, informs the meaning of "use-specific group" because these embodiments do not relate to service providers and thus are not covered by claims 1, 22, and 28. Responsive Br. 24. Uber also argues that the "stranded motorist or hiker" embodiment, '647 patent, col. 15:26-38, col. 17:7-27, does not inform the meaning of "use-specific group" because this embodiment simply suggests that "use-specific group" is something that "allow[s] the two-way sharing of location information," which is superfluous with other claim language. Responsive Br. 24-25. Uber also argues that the specification fails to elucidate "use-specific group" because the specification exclusively uses the word "group" to refer to embodiments where individuals on a buddy list share information, whereas the specification uses the phrase "Instant Buddies" to refer to a relationship between a service provider and a requestor. Id. at 25.
For the reasons discussed below, the Court finds that "use-specific group" does not render the asserted claims of the '647 patent indefinite. Instead, the Court adopts X One's proposal and construes this phrase according to its plain meaning.
i. Claim Language
The Court begins with the claim language. Claims 1, 22, and 28 all recite that the "first wireless device" and the "second wireless device" are associated with "a provider of a desired service" and "a requestor of the desired service." '647 patent, col. 28:50-56, col. 30:47-52, col. 31:55-60. Then, in referring to "use-specific group," they recite "forming a use-specific group to have the first wireless device and the second wireless device in connection with the request for the desired service." Id., col. 29:13-18, col. 31:9-12, col. 31:66-32:5. Reading these limitations together, it is plain that the "group" is the pairing of the "first wireless device" and the "second wireless device" and it is "use-specific" because it is formed for the purpose of facilitating or effectuating the "desired service." The claims recite no other entities that could be part of the "group" or no other aspects of their relationship that would muddy why their pairing is "use-specific." As such, a person of ordinary skill in the art would be able to read claims 1, 22, and 28 and understand the meaning of "use-specific group" such that they would be informed about the scope of the invention with reasonable certainty. See Nautilus, 134 S. Ct. at 2124.
The same holds true for "forming." The claim language surrounding "[forming / formation of] a use-specific group" recites "selecting the provider of the desired service" and "to have the first wireless device and the second wireless device in connection." '647 patent, col. 29:13-18, col. 31:9-12, col. 31:66-32:5. Read in context, it is clear that "forming" simply refers to this process of connecting the first and second wireless devices. A skilled artisan would be able to know the range of what it means for two wireless devices to be "connect[ed]." Thus, a person of ordinary skill in the art would also be able to read claims 1, 22, and 28 and understand the meaning of "forming" such that they would be informed about the scope of the invention with reasonable certainty. See Nautilus, 134 S. Ct. at 2124.
ii. Specification
The specification bolsters these conclusions. As discussed in other sections above, one of the service provider-specific embodiments disclosed in the specification is the "stranded motorist or hiker" embodiment. '647 patent, col. 15:26-38, col. 17:7-27. In this embodiment,
the user's car breaks down. The user calls a towing service, and finds out the tow truck driver has a cell phone with Buddy Tracker on it. The user dials the tow truck driver's cell phone and requests to be an instant buddy of the tow truck driver's phone. His phone is then set up as an instant buddy on the user's phone. After both phones are set up as instant buddies, each phone shows the location of the other phone on its moving map. This allows the tow truck driver to find the user tow truck customer and the user customer to know where the tow truck driver is.Id., col. 15:29-38. How "use-specific group" maps onto this example is plain: the "group" is the tow truck driver and the user, and it is "use-specific" because the pairing is set up for the specific purpose of helping to provide the towing service. Thus, reading the claims in light of this disclosure further elucidates the meaning of "use-specific group." It would not be unreasonable for a skilled artisan to take this example and know what other types of "use-specific groups" are covered by the claims.
The same can be said of "forming." Here, in this example, the two wireless devices that "form[]" the "use-specific group" are cell phones. There is a discrete range of possible ways the cell phones can connect with one another, all of which would be familiar to a skilled artisan. The skilled artisan would also be able to take this example and infer, for other types of "use-specific groups" involving other types of "wireless devices," the range of ways of connecting that would be covered by "forming." Thus, the specification further helps inform the meaning of "[forming / formation of] a use-specific group." As such, the Court concludes that "[forming / formation of] a use-specific group" does not make it such that the "claims, read in light of the specification delineating the patent, and the prosecution history, fail to inform, with reasonable certainty, those skilled in the art about the scope of the invention." Nautilus, 134 S. Ct. at 2124.
Uber's arguments to the contrary, Responsive Br. 24-25, are unpersuasive. First, whether the phrase "use-specific group" appears in the specification of the X One Patents is irrelevant. See Cox Commc'ns, 838 F.3d at 1231 (explaining that "the dispositive question in an indefiniteness inquiry is whether the 'claims,' not particular claim terms" fail the Nautilus test). Second, as discussed above, the Court finds that the "stranded motorist or hiker" embodiment does inform the meaning of "use-specific group" because it gives a concrete example of a "group" (the motorist and the tow truck driver) and how it is "use-specific" (towing services). Finally, the fact that the specification uses "group" to refer to something other than the embodiments covered by claims 1, 22, and 28 is irrelevant. Even if there are differences between the use of the word "group" in the specification and the claims, a person of ordinary skill in the art would be able to read these words in context and understand that these are different things. As long as that person can discern the scope of the claims with reasonable certainty, the claims are not indefinite. Nautilus, 134 S. Ct. at 2124. Such is the case here.
Accordingly, "[forming / formation of] a use-specific group" does not render the claims indefinite. The Court instead adopts X One's position and construes this phrase according to its plain meaning.
IV. CONCLUSION
For the foregoing reasons, the Court construes the disputed claim terms as follows:
'593 patent:
1. "account" as "an arrangement for user-specific authenticated access;"
2. "buddy list" as "a list, associated with an account of the first individual, that identifies multiple other users whose location may be shared with the first individual;"
3. "a database representing an account for a first individual, the account having an associated buddy list that identifies multiple users" as "a database accessible by the server that includes data directly related to and standing for an account for a first individual, the account having an associated list that identifies multiple other users whose location may be shared with the first individual;"
4. "last known location" as "most-recent shared position stored on the server for a user at the time the user's position is plotted on the map;"
'647 patent:
5. "wherein the provider is selected in connection with the request for the desired service" as plain meaning; "selecting the provider of the desired service" as plain meaning;
6. "responsive to launching an application" as plain meaning; "in association with an application launched" as plain meaning;
7. "forming a use-specific group" as plain meaning; and "formation of a use-specific group" as plain meaning.
IT IS SO ORDERED.
Dated: August 18, 2017
/s/_________
LUCY H. KOH
United States District Judge