X One, Inc. v. Uber Technologies, Inc.

Filing 73

ORDER CONSTRUING DISPUTED CLAIM TERMS OF U.S. PATENT NOS. 8,798,593 AND 8,798,647. Signed by Judge Lucy H. Koh on August 18, 2017. (patentlcsjS, COURT STAFF) (Filed on 8/18/2017)

1
2
3
4
5
6
7
8

UNITED STATES DISTRICT COURT

9

NORTHERN DISTRICT OF CALIFORNIA

10
SAN JOSE DIVISION

United States District Court
Northern District of California

11
12

X ONE, INC.,

13
14
15

Case No. 16-CV-06050-LHK
Plaintiff,

ORDER CONSTRUING DISPUTED
CLAIM TERMS OF U.S. PATENT NOS.
8,798,593 AND 8,798,647

v.
UBER TECHNOLOGIES, INC.,

16

Re: Dkt. No. 63

Defendant.

17
18

Plaintiff X One, Inc. (“X One” or “Plaintiff”) brings this action for patent infringement

19

against Defendant Uber Technologies, Inc. (“Uber” or “Defendant”). The parties now seek

20

construction of seven disputed terms used in the claims of the following patents-in-suit: U.S.

21

Patent Nos. 8,798,647 (“’647 patent”) and 8,798,593 (“’593 patent”) (collectively, “X One

22

Patents”).

23

I. BACKGROUND

24
25

A. Background and Description of the Invention
The ’593 patent is titled “Location Sharing and Tracking Using Mobile Phones or Other

26

Wireless Devices.” ECF No. 1 (“Compl.”) Ex. B (’593 patent). The ’647 patent is titled

27

“Tracking Proximity of Services Provider to Services Consumer.” Compl. Ex. A (’647 patent).

28

1
Case No. 16-CV-06050-LHK
ORDER CONSTRUING DISPUTED CLAIM TERMS OF U.S. PATENT NOS. 8,798,593 AND 8,798,647

1

The’647 patent is a continuation of the’593 patent, and thus the two patents share the same

2

specification. For simplicity, unless specifically referring to the ’593 patent or the ’647 patent, the

3

Court’s citations to the text and figures of the X One Patents refer to the ’593 patent specification.

4

1. Specification

5

The X One Patents relate to “[a] system for exchanging GPS or other position data

6

between wireless devices.” ’593 patent, Abstract. This system involves “phones [or] other

7

wireless devices” that “are programmed with software . . . to allow mutual tracking and optional

8

position mapping displays of members of groups.” Id., col. 2:35–40. These devices “work with

9

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

11
United States District Court
Northern District of California

10

devices also contain GPS receivers, and, in preferred embodiments, “sufficiently large liquid

12

crystal displays.” Id., col. 2:23–24.

13
14

Figure 2A illustrates exemplary communications between these devices according to the
invention of the X One Patents:

15
16
17
18
19
20
21
22
23
24
25
26
27
28

Id., Fig. 2A.
As Figure 2A illustrates, the requesting phone sends packets through the local phone
2
Case No. 16-CV-06050-LHK
ORDER CONSTRUING DISPUTED CLAIM TERMS OF U.S. PATENT NOS. 8,798,593 AND 8,798,647

1

carrier system, which are then relayed through the internet to a server. Id., col. 5:59–6:28. The

2

server then obtains the relevant data from the phones associated with individuals on a buddy list

3

for the requesting phone. Id. The server then relays the requested information—location data for

4

each phone associated with a “buddy” and a map showing that location—back to the requesting

5

phone through the internet and carrier service. See also id., col. 2:51–64 (“[T]he process of the

6

invention [] allows exchanging and mapping of position data with persons on a Buddy List.”).

7

However, the specification is not solely limited to the use of a server, and outlines a more

8

generalized process as well for the functioning of the invention. Figure 13 of the X One Patents

9

provides a “flowchart of the method of exchanging GPS position data among cell phones of a

10

watch list”:

United States District Court
Northern District of California

11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28

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
3
Case No. 16-CV-06050-LHK
ORDER CONSTRUING DISPUTED CLAIM TERMS OF U.S. PATENT NOS. 8,798,593 AND 8,798,647

1

data to the phones in the buddy list. Id. Those phones receive the information, interpret it, and

2

display that location on a map, and then obtain their own position and send their location to the

3

people on their buddy list. Id.

4

2. Asserted Claims

5

Plaintiff asserts that Defendant infringes thirty-four (34) claims across the X One Patents.

6

Opening Br. 7. Five of these asserted claims are independent claims, namely claims 1 and 19 of

7

the ’593 patent and claims 1, 22, and 28 of the ’647 patent. Id. All of the disputed claim terms

8

appear in one or several of these independent claims. See ECF No. 63 (“Joint Statement”) at 2.

9
10

B. Procedural History
On October 19, 2016, Plaintiff filed the instant patent infringement suit. In its complaint,

United States District Court
Northern District of California

11

Plaintiff alleged that Defendant “has infringed and continues to infringe one or more claims of the

12

[X One Patents].” Compl. ¶ 13. The products and services accused included “Uber’s mobile

13

device applications on iOS, Android, and Microsoft operating systems” as well as “the Uber ride-

14

sharing, car-pooling, and delivery services.” Id.

15

On December 9, 2016, Defendant moved to dismiss all of the asserted claims of the X One

16

Patents for failure to claim patent-eligible subject matter pursuant to 35 U.S.C. § 101. ECF No.

17

24. The Court denied Defendant’s motion on March 6, 2017. ECF No. 52.

18

On June 30, 2017, Plaintiff filed its Opening Brief on Claim Construction. ECF No. 64

19

(“Opening Br.” or “Opening Brief”). On July 17, 2017, Defendant filed its Responsive Claim

20

Construction Brief. ECF No. 66 (“Responsive Brief” or “Resp. Br.”). On July 21, 2017, Plaintiff

21

filed its Reply Brief. ECF No. 75 (“Reply Brief” or Reply Br.”). The Court held a tutorial and

22

claim construction hearing on August 17, 2017 (“Markman hearing”).

23

II. LEGAL STANDARD

24

A. Claim Construction

25

The Court construes patent claims as a matter of law based on the relevant intrinsic and

26

extrinsic evidence. See Lighting Ballast Control LLC v. Philips Elecs. N. Am. Corp., 744 F.3d

27

1272 (Fed. Cir. 2014) (en banc); Phillips v. AWH Corp., 415 F.3d 1303 (Fed. Cir. 2005) (en banc).

28

4
Case No. 16-CV-06050-LHK
ORDER CONSTRUING DISPUTED CLAIM TERMS OF U.S. PATENT NOS. 8,798,593 AND 8,798,647

1

“Ultimately, the interpretation to be given a term can only be determined and confirmed with a full

2

understanding of what the inventors actually invented and intended to envelop with the claim.”

3

Phillips, 415 F.3d at 1316 (internal quotation marks and citation omitted). Accordingly, a claim

4

should be construed in a manner that “stays true to the claim language and most naturally aligns

5

with the patent’s description of the invention.” Id.

6

In construing disputed terms, a court looks first to the claims themselves, for “[i]t is a

7

‘bedrock principle’ of patent law that ‘the claims of a patent define the invention to which the

8

patentee is entitled the right to exclude.’” Id. at 1312 (quoting Innova/Pure Water, Inc. v. Safari

9

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

11
United States District Court
Northern District of California

10

term[s] would have to a person of ordinary skill in the art in question at the time of the invention.”

12

Id. at 1312-13. In some instances, the ordinary meaning to a person of skill in the art is clear, and

13

claim construction may involve “little more than the application of the widely accepted meaning

14

of commonly understood words.” Id. at 1314.

15

In many cases, however, the meaning of a term to a person skilled in the art will not be

16

readily apparent, and a court must look to other sources to determine the term’s meaning. See id.

17

Under these circumstances, a court should consider the context in which the term is used in an

18

asserted claim or in related claims and bear in mind that “the person of ordinary skill in the art is

19

deemed to read the claim term not only in the context of the particular claim in which the disputed

20

term appears, but in the context of the entire patent, including the specification.” Id. at 1313. The

21

specification “‘is always highly relevant’” and “‘[u]sually . . . dispositive; it is the single best

22

guide to the meaning of a disputed term.’” Id. at 1315 (quoting Vitronics Corp. v. Conceptronic,

23

Inc., 90 F.3d 1576, 1582 (Fed. Cir. 1996)). Indeed, “the only meaning that matters in claim

24

construction is the meaning in the context of the patent.” Trs. of Columbia Univ. v. Symantec

25

Corp., 811 F.3d 1359, 1363 (Fed. Cir. 2016). Where the specification reveals that the patentee has

26

given a special definition to a claim term that differs from the meaning it would ordinarily possess,

27

“the inventor’s lexicography governs.” Id. at 1316. Likewise, where the specification reveals an

28

5
Case No. 16-CV-06050-LHK
ORDER CONSTRUING DISPUTED CLAIM TERMS OF U.S. PATENT NOS. 8,798,593 AND 8,798,647

1

intentional disclaimer or disavowal of claim scope by the inventor, the inventor’s intention as

2

revealed through the specification is dispositive. Id.

3

In addition to the specification, a court may also consider the patent’s prosecution history,

4

which consists of the complete record of proceedings before the United States Patent and

5

Trademark Office (“PTO”) and includes the cited prior art references. The prosecution history

6

“can often inform the meaning of the claim language by demonstrating how the inventor

7

understood the invention and whether the inventor limited the invention in the course of

8

prosecution, making the claim scope narrower than it would otherwise be.” Id. at 1317.

9

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

11
United States District Court
Northern District of California

10

Instruments, Inc., 52 F.3d 967, 980 (Fed. Cir. 1995) (en banc), aff’d, 517 U.S. 370 (1996). Expert

12

testimony may be particularly useful in “[providing] background on the technology at issue, . . .

13

explain[ing] how an invention works, . . . ensur[ing] that the court’s understanding of the technical

14

aspects of the patent is consistent with that of a person of skill in the art, or . . . establish[ing] that

15

a particular term in the patent or the prior art has a particular meaning in the pertinent field.”

16

Phillips, 415 F.3d at 1318. Although a court may consider evidence extrinsic to the patent and

17

prosecution history, such evidence is considered “less significant than the intrinsic record” and

18

“less reliable than the patent and its prosecution history in determining how to read claim terms.”

19

Id. at 1317-18 (internal quotation marks and citations omitted). Thus, while extrinsic evidence

20

may be useful in claim construction, ultimately “it is unlikely to result in a reliable interpretation

21

of patent claim scope unless considered in the context of the intrinsic evidence.” Id. at 1319. Any

22

expert testimony “that is clearly at odds with the claim construction mandated by the claims

23

themselves, the written description, and the prosecution history” will be significantly discounted.

24

Id. at 1318 (internal quotation marks and citation omitted). Finally, while the specification may

25

describe a preferred embodiment, the claims are not necessarily limited only to that embodiment.

26

Id. at 1323; see also Prima Tek II, L.L.C. v. Polypap, S.A.R.L., 318 F.3d 1143, 1151 (Fed. Cir.

27

2003) (“The general rule, of course, is that claims of a patent are not limited to the preferred

28

6
Case No. 16-CV-06050-LHK
ORDER CONSTRUING DISPUTED CLAIM TERMS OF U.S. PATENT NOS. 8,798,593 AND 8,798,647

1

embodiment, unless by their own language.”).

2

B. Indefiniteness
Under 35 U.S.C. § 112, ¶ 2 (2006 ed.), 1 a patent must “conclude with one or more claims

4

particularly pointing out and distinctly claiming the subject matter which the applicant regards as

5

[the] invention.” Section 112, ¶ 2 includes what is commonly called the “definiteness”

6

requirement. Nautilus, Inc. v. Biosig Instruments, Inc., 134 S. Ct. 2120, 2125 (2014). In Nautilus,

7

the United States Supreme Court held that “a patent is invalid for indefiniteness if its claims, read

8

in light of the specification delineating the patent, and the prosecution history, fail to inform, with

9

reasonable certainty, those skilled in the art about the scope of the invention.” Nautilus, 134 S. Ct.

10

at 2124. As the Court observed, § 112, ¶ 2 “entails a ‘delicate balance.’” Id. (quoting Festo Corp.

11
United States District Court
Northern District of California

3

v. Shoketsu Kinzoku Kogyo Kabushiki Co., 535 U.S. 722, 731 (2002)). “On the one hand, the

12

definiteness requirement must take into account the inherent limitations of language.” Id. (citing

13

Festo, 535 U.S. at 731). “At the same time, a patent must be precise enough to afford clear notice

14

of what is claimed, thereby ‘appris[ing] the public of what is still open to them.’” Id. (quoting

15

Markman, 517 U.S. at 373). Thus, “the certainty which the law requires in patents is not greater

16

than is reasonable, having regard to their subject-matter.” Id. at 2129 (quoting Minerals

17

Separation v. Hyde, 242 U.S. 261, 270 (1916)).
The Federal Circuit applied the Nautilus standard in Interval Licensing LLC v. AOL, Inc.,

18
19

766 F.3d 1364 (Fed. Cir. 2014). The case involved two patents which covered an “attention

20

manager for occupying the peripheral attention of a person in the vicinity of a display device.” Id.

21

at 1366. In one embodiment, the patents involved placing advertising on websites in areas

22

surrounding the principal content of the webpage, for example in the margins of an article.

23

Several of the asserted claims included a limitation that the advertisements (“content data”) would

24

be displayed “in an unobtrusive manner that does not distract a user of the display device.” Id. at

25
26
27
28

1

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.
7
Case No. 16-CV-06050-LHK
ORDER CONSTRUING DISPUTED CLAIM TERMS OF U.S. PATENT NOS. 8,798,593 AND 8,798,647

1

1368. The district court found that the terms “in an unobtrusive manner” and “does not distract

2

the user” were indefinite, and the Federal Circuit affirmed. Id. at 1368-69. The Federal Circuit

3

found that the “‘unobtrusive manner’ phrase is highly subjective and, on its face, provides little

4

guidance to one of skill in the art” and “offers no objective indication of the manner in which

5

content images are to be displayed to the user.” Id. at 1371. Accordingly, the Court looked to the

6

written description for guidance. The Court concluded that the specification lacked adequate

7

guidance to give the phrase a “reasonably clear and exclusive definition, leaving the facially

8

subjective claim language without an objective boundary.” Id. at 1373. Accordingly, the claims

9

containing the “unobtrusive manner” phrase were indefinite.
In applying the Nautilus standard, the Federal Circuit has cautioned that “the dispositive

11
United States District Court
Northern District of California

10

question in an indefiniteness inquiry is whether the ‘claims,’ not particular claim terms” fail the

12

Nautilus test. Cox Commc’ns, Inc. v. Sprint Commc’n Co. LP, 838 F.3d 1224, 1231 (Fed. Cir.

13

2016). For that reason, a claim term that “does not discernably alter the scope of the claims” may

14

fail to serve as a source of indefiniteness. Id. For example, in Cox Communications, the Federal

15

Circuit determined that the term “processing system” did not render the method claims at issue

16

indefinite because “the point of novelty resides with the steps of these methods, not with the

17

machine that performs them.” Id. at 1229. Thus, the court reasoned, “[i]f ‘processing system’

18

does not discernably alter the scope of the claims, it is difficult to see how this term would prevent

19

the claims . . . from serving their notice function under § 112, ¶ 2.” Id.
The Court therefore reviews the claims, specification, and prosecution history to determine

20
21

whether the claims “inform, with reasonable certainty, those skilled in the art about the scope of

22

the invention.” Nautilus, 134 S. Ct. at 2124. Indefiniteness renders a claim invalid, and must be

23

shown by clear and convincing evidence. See Halliburton Energy Servs. v. M-I LLC, 514 F.3d

24

1244, 1249 (Fed. Cir. 2008); cf. Nautilus, 134 S. Ct. at 2130 n.10.

25

III.

26
27
28

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.
8
Case No. 16-CV-06050-LHK
ORDER CONSTRUING DISPUTED CLAIM TERMS OF U.S. PATENT NOS. 8,798,593 AND 8,798,647

1

A. ’593 Patent
1. “account” (claims 1 and 19)

2
3
4
5

X One’s Proposed Construction
an arrangement for user-specific authenticated
access

Uber’s Proposed Construction
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:

6
1. An apparatus, comprising:
7
a server;
8
9
10

United States District Court
Northern District of California

11
12
13
14
15
16
17
18
19
20
21
22
23
24

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.
’593 patent, col. 28:51–29:4 (emphasis added).
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.

25
26
27
28

9
Case No. 16-CV-06050-LHK
ORDER CONSTRUING DISPUTED CLAIM TERMS OF U.S. PATENT NOS. 8,798,593 AND 8,798,647

1

a. Intrinsic Evidence
i. Claim Language

2
At the outset, the Court observes that the claim language on its face does not require
3
authenticated access. Rather, the claim language only requires that “account” is (1) “for a first
4
individual”—i.e., is user-specific; (2) is “represent[ed]” by a “database;” and (3) “ha[s] an
5
associated buddy list that identifies multiple users.” Thus, thus claim language, by itself, does not
6
support X One’s “authenticated access” proposal. However, claims must be read in “light of the
7
specification . . .” Corning Glass Works v. Sumitomo Elec. U.S.A., Inc., 868 F.2d 1251, 1257
8
(Fed. Cir. 1989). Accordingly, the Court proceeds to consider the specification.
9
ii. Specification
10
Turning to the specification, the Court first notes that the word “account” does not itself
11
United States District Court
Northern District of California

appear in the specification. See ’543 patent, col. 1:20–28:48. Both parties acknowledge this.
12
Opening Br. 9; Responsive Br. 7. Nevertheless, this does not prevent the Court from using the
13
specification to construe “account” because the “claims must be read in view of the specification”
14
and reading claims 1 and 19 in light of the specification informs the meaning of “account.”
15
Philips, 415 F.3d at 1315 (quoting Markman, 52 F.3d at 978 (quotation marks omitted)) (emphasis
16
added); see also, e.g., HBAC Matchmaker Media, Inc. v. Google Inc., 650 F. App’x 990, 993 (Fed.
17
Cir. 2016) (acknowledging the specification as helpful context even where the disputed claim term
18
did not appear in the specification).
19
X One contends that the specification supports its position that “account” requires
20
“authenticated access” because it discloses that location sharing is accomplished through user21
specific authenticated access. Opening Br. 9–10. As support for this, X One points to
22
embodiments where devices are first authenticated before location information is shared. Id. at 9
23
(citing, for example, ’593 patent, col. 10:7–8 (“The initiator and recipient are also authenticated—
24
230, and the packets are forwarded to the recipients via the cell system.”)). X One also argues that
25
user-specific authenticated access is required for the privacy features disclosed in the
26
specification, such as the ability to selectively disable location sharing. Id. at 9–10. Uber, on the
27
28

10
Case No. 16-CV-06050-LHK
ORDER CONSTRUING DISPUTED CLAIM TERMS OF U.S. PATENT NOS. 8,798,593 AND 8,798,647

1

other hand, argues that these citations refer only to preferred embodiments and that the claims

2

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

4

specification, it becomes clear that it requires “authenticated access.” As discussed above, claims

5

1 and 19 recite apparatuses that include a “server.” ’593 patent, col. 28:53, col. 30:50. The

6

specification, however, is broader than this and discloses embodiments that both include a server

7

and ones that do not. Compare, e.g., id., col. 8:12–9:65, with id., col. 9:66–10:34. Thus, for the

8

purposes of construing terms in claims 1 and 19, the Court need only focus on the embodiments

9

that include a “server.” See Aug. Tech. Corp. v. Camtek, Ltd., 655 F.3d 1278, 1285 (Fed. Cir.

10

2011) (construing claims in light of embodiments that used multiple wafers because the claim

11
United States District Court
Northern District of California

3

language required using multiple wafers, even though the specification disclosed embodiments

12

that used both multiple dies and multiple wafers); cf. Pacing Techs., LLC v. Garmin Int’l, Inc.,

13

778 F.3d 1021, 1026 (Fed. Cir. 2015) (“[W]here the patent describes multiple embodiments, every

14

claim does not need to cover every embodiment.”).
Focusing on the embodiments that include a “server,” the specification consistently

15
16

discloses that, when a server is involved, it performs the step of authenticating the participating

17

devices. Walking through relevant portions of the specification 2 confirms this. First, in the

18

opening paragraph of its “Detailed Description” section, the specification discloses an initial

19

preferred embodiment that includes “[a] Buddy Watch or Rubicon server” that performs the step

20

of “valid[ating] the content of the IP packet to authenticate the sender as a registered Rubicon user

21

and to verify that the sending phone EIN matches the phone EIN stored in the server.” ’543

22

patent, col. 5:60, col. 6:7–11 (emphasis added). Next, the specification describes several

23

embodiments of a “process to receive buddy location update requests and process them.” Id., col.

24

9:6–67. One of these embodiments uses a server, while the other does not. Compare id., col.

25
26
27
28

2

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.
11
Case No. 16-CV-06050-LHK
ORDER CONSTRUING DISPUTED CLAIM TERMS OF U.S. PATENT NOS. 8,798,593 AND 8,798,647

1

8:12–9:65, with id., col. 9:66–10:34. In the embodiment that includes a server, the specification

2

discloses that “[t]he initiator and recipient are authenticated—230 . . . .” Id., col. 10:7–8

3

(emphasis added). Next, the specification discusses “Buddy Watch Server Functions.” Id., col.

4

12:20. One of these functions, the specification discloses, is “to manage activate and deactivate

5

codes,” which the server uses to confirm that a participating device has a current subscription to

6

the Buddy Watch service. See id., col. 12:43–45 (“The Buddy Watch application will be a service

7

which a cellular carrier offers on a subscription basis.”). Again here the specification mentions the

8

step of authenticating the participating devices to make sure that they are registered users in the

9

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,

11
United States District Court
Northern District of California

10

the specification describes several embodiments of the Instant Buddy Setup process. Id., col.

12

13:12–15:13. In the embodiments that include a server, the specification discloses authentication.

13

Id., col. 13:40–43 (“Buddy Watch server authenticates the initiator and the recipient from data in

14

the packet as a [sic] Buddy Watch subscribers.”) (emphasis added), col. 14:60–61 (“Rubicon

15

server authenticates the initiator and recipient and forwards packets to cell system—258.”)

16

(emphasis added). Further on, the specification elaborates on how access codes and encryption

17

help the server ensure that only authenticated devices use the Buddy Watch service. Id., col.

18

23:21–42. Next, the specification discusses attributes of “all species” within the “User Interface

19

Genus,” the “Server Genus,” and “Client Application Genus.” Notably, for the “Server Genus,”

20

the specification discloses that “[a]ll servers programmed with Buddy Watch software will have

21

the functionality to . . . store at least some preference data that defines who can use the server, e.g.

22

only those with a valid Buddy watch user ID and password.” Id., col. 24:59–60, col. 25:8–10

23

(emphasis added). Finally, the specification describes embodiments of “TalkControl”

24

functionality, which works specifically with “walkie-talkie enabled phones” and uses a server. Id.,

25

col. 26:12–28:40. As with all the other server embodiments discussed above, here too the server

26

performs authentication. Id., col. 26:59–61 (“One or more packets are sent to the Rubicon server

27

which authenticates the token and the recipient and creates a database entry.”) (emphasis added),

28

12
Case No. 16-CV-06050-LHK
ORDER CONSTRUING DISPUTED CLAIM TERMS OF U.S. PATENT NOS. 8,798,593 AND 8,798,647

1

col. 27:25–28 (“. . . Rubicon server which authenticates the initiator and recipient . . .”) (emphasis

2

added), col. 27:49–51 (“. . . Rubicon servers which authenticate the initiator and recipient . . .”)

3

(emphasis added), col. 28:30–32 (“. . . Rubicon server then authenticates the initiator and recipient

4

. . .”) (emphasis added). Thus, all of the embodiments that include a server perform the step of

5

authentication. “The fact that [authentication] is ‘repeatedly and consistently’ used to characterize

6

the invention strongly suggests that it should be read as part of the claim.” Virnetx, Inc. v. Cisco

7

Sys., Inc., 767 F.3d 1308, 1318 (Fed. Cir. 2014); see also GPNE Corp. v. Apple Inc., 830 F.3d

8

1365, 1370 (Fed. Cir. 2016) (“[W]hen a patent ‘repeatedly and consistently’ characterizes a claim

9

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

11
United States District Court
Northern District of California

10

access.”

12

Other aspects of the specification bolster this conclusion. Specifically, the specification

13

discloses two objectives of the invention: (1) enforcing valid subscriptions; and (2) maintaining

14

privacy. Construing “account” to require “authenticated access” furthers both of these objectives.

15

Cf. Renishaw PLC v. Marposs Societa’ per Azioni, 158 F.3d 1243, 1250 (Fed. Cir. 1998) (“The

16

construction that stays true to the claim language and most naturally aligns with the patent’s

17

description of the invention will be, in the end, the correct construction.”). First, the specification

18

discloses that it is important to ensure that only users with valid subscriptions use the disclosed

19

invention. See ’543 patent, col. 2:51–54 (“the process of the invention only allows exchanging

20

and mapping of position data with persons on a Buddy List programmed onto a Buddy Watch . . .

21

device”). In order to know whether a device is a “Buddy Watch . . . device,” it would need to be

22

authenticated or validated in some way. Second, the specification discloses that an important

23

consideration in the X One Patents is privacy concerns. See id., col. 2:8–13 (“To alleviate privacy

24

concerns, it would be useful to be able to turn off location sharing . . . .”). Requiring that an

25

“account” includes “authenticated access” helps further this objective of protecting privacy,

26

because it helps ensure that the people with whom location information is shared are who they

27

purport to be. See id., col. 2:51–53 (describing how the user must allow specific individuals “on

28

13
Case No. 16-CV-06050-LHK
ORDER CONSTRUING DISPUTED CLAIM TERMS OF U.S. PATENT NOS. 8,798,593 AND 8,798,647

1

his Buddy Lists to ‘see’ his location . . . and the user must request to see the location of others on

2

his Buddy Lists to be able to have their positions reported and/or mapped”). Thus, “authenticated

3

access” helps further objectives of the invention disclosed in the specification. Compare, e.g.,

4

World Class Tech. Corp. v. Ormco Corp., 769 F.3d 1120, 1125 (Fed. Cir. 2014) (affirming

5

construction of “support surface” in orthodontic device patent that required engaging “the

6

moveable member during the entire time that the member was slidingly moved” because it best

7

aligned with specification and its discussion that the problem the invention solved). This supports

8

the Court’s conclusion that “account” requires “authenticated access.”
Uber, nevertheless, argues that requiring “authenticated access” improperly imports

10

limitations from the specification into the claims. Responsive Br. 7. The Court agrees that,

11
United States District Court
Northern District of California

9

ordinarily, limitations set forth in a preferred embodiment disclosed in a specification do not limit

12

the scope of the claims. See, e.g., Liebel–Flarsheim Co. v. Medrad, Inc., 358 F.3d 898, 908 (Fed.

13

Cir. 2004). However, here, the concept of “authenticated access” is not only consistently

14

disclosed in every server-dependent embodiment, but is also a concept that flows naturally from

15

the stated objectives of the invention. As such, the specification supports construing “account”

16

such that it requires “authenticated access.” See GPNE, 830 F.3d at 1370 (affirming construction

17

of “node” as a “pager” where “the words ‘pager’ and ‘pager units’ appear in the specification over

18

200 times, and, apart from the Abstract, the specification repeatedly and exclusively uses these

19

words to refer to the devices in the patented system”); In re Abbott Diabetes Care Inc., 696 F.3d

20

1142, 1149 (Fed. Cir. 2012) (holding that the conclusion that the claimed electrochemical sensor

21

could not have external wires was supported by: (1) “every embodiment disclosed in the

22

specification shows . . . [a] sensor without external cables or wires,” and (2) the discussion of the

23

prior art in the specification identified external cables or wires as a deficiency in the prior art

24

supported). Uber’s arguments to the contrary are unconvincing. 3

25
26
27
28

3

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
14
Case No. 16-CV-06050-LHK
ORDER CONSTRUING DISPUTED CLAIM TERMS OF U.S. PATENT NOS. 8,798,593 AND 8,798,647

1
2
3
4
5

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

7

dictionaries—and especially technical dictionaries—“as among the many tools that can assist the

8

court in determining the meaning of particular terminology to those of skill in the art of the

9

invention.” Phillips, 415 F.3d at 1318. The Federal Circuit has observed that dictionaries can be

10

especially helpful where, as is the case here with “account,” a claim term does not itself appear in

11
United States District Court
Northern District of California

6

the specification. See, e.g., HBAC Matchmaker Media, 650 F. App’x at 993 (relying on technical

12

dictionaries where the term “head end system” was “not defined or recited in the specification”).

13

Here, a computer dictionary from around the time of invention defines “account” as “a

14

record of a user’s name, password and rights to access a network or online system.” Mot. Ex. 2 at

15

XONE0104061. In addition, the non-technical Oxford English Dictionary defines “account” as

16

“an arrangement whereby a user is given (freq. personalized) access to a website, program,

17

system, etc., typically by entering username and password at a prompt; the data and setting

18

specific to each user of the website.” Mot. Ex. 1 at XONE0104061. A common thread in both of

19

these definitions is that an “account” includes some form of authenticated access. Although it is

20

true—as Uber points out, Responsive Br. 8—that at least the Oxford English Dictionary uses

21
22
23
24
25
26
27
28

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.
15
Case No. 16-CV-06050-LHK
ORDER CONSTRUING DISPUTED CLAIM TERMS OF U.S. PATENT NOS. 8,798,593 AND 8,798,647

1

qualifiers such as “freq[uently]” and “typically,” the fact that “account” is generally associated

2

with authenticated access suggests that a person of ordinary skill in the art would commonly read

3

the term “account” in claims 1 and 19 to include “authenticated access.” This supports the Court’s

4

conclusion that “account” requires “authenticated access.”

5

ii. Dr. Bartone’s Testimony

6

The testimony of Uber’s expert, Dr. Bartone, in its IPR petition is not inconsistent with this

7

conclusion. Dr. Bartone opined that a “person of ordinary skill in the art would understand that an

8

account is used to enable an individual to access data.” Mot. Ex. 3 ¶ 47. One way to allow

9

individual access is through authentication. Thus, construing “account” to require “authenticated

10

United States District Court
Northern District of California

11
12

access” does not conflict with this testimony.
c. Conclusion
As set forth above, while the claim language does not explicitly require that “account”

13

include “authenticated access,” the specification and relevant dictionary definitions support the

14

conclusion that “account” includes “authenticated access.” The Court therefore adopts X One’s

15

position and construes “account” to mean “an arrangement for user-specific authenticated access.”

16
17
18

2. “buddy list” (claims 1 and 19)
X One’s Proposed Construction
user list

19
20

Uber’s Proposed Construction
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

The term “buddy list” appears in claims 1 and 19. For example, claim 1 recites:
21
1. An apparatus, comprising:
22
a server;
23
24
25
26
27
28

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
16
Case No. 16-CV-06050-LHK
ORDER CONSTRUING DISPUTED CLAIM TERMS OF U.S. PATENT NOS. 8,798,593 AND 8,798,647

1
2
3
4
5
6
7
8
9
10

United States District Court
Northern District of California

11
12
13
14

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.
’593 patent, col. 28:51–29:4 (emphasis added).
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.

15

a. Whether the “buddy list” must identify multiple other individuals in addition
to the first individual

16

The parties first dispute whether a “buddy list” must identify multiple other individuals in

17

addition to the first individual. X One contends that the “buddy list” can include just the “first

18

individual” and one other user. Opening Br. 12–14. Uber agrees that a “buddy list” can include

19

the “first individual,” Responsive Br. 14, but argues that it must also include at least two other

20

users who are not the “first individual,” id. 9–14. Here, the Court agrees with Uber.

21
22

i. Claim Language
The claim language modestly favors Uber’s position. Claim 1 recites an “account for a

23

first individual . . . having an associated buddy list that identifies multiple users.” It then recites:

24

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

25
26
27
28

’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
17
Case No. 16-CV-06050-LHK
ORDER CONSTRUING DISPUTED CLAIM TERMS OF U.S. PATENT NOS. 8,798,593 AND 8,798,647

1

least two of the multiple users” are users other than the “first individual.” The claim language

2

uses different words—“first individual” and “multiple users”—to refer to each. See Bd. of

3

Regents of the U. of Texas System v. BENQ Am. Corp., 533 F.3d 1362, 1371 (Fed. Cir. 2008)

4

(“Different claim terms are presumed to have different meanings.”) (citations omitted). Further, it

5

makes more sense that the first individual would want to “obtain the last known position” of other

6

individuals than he would his own.

7

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

9

consistently with its appearance in other places in the same claim or in other claims of the same

10

patent”); CVI/Beta Ventures, Inc. v. Tura LP, 112 F.3d 1146, 1159 (Fed. Cir. 1997) (“[W]e are

11
United States District Court
Northern District of California

8

obliged to construe the term ‘elasticity’ consistently throughout the claims.”). Claim 4 recites:

12
13

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

14
distance to two other users, rather than his distance to himself (i.e., 0) and one other user. Thus,
15
the claim language modestly favors Uber’s position.
16
Nevertheless, the claim language is not perfectly clear and does not entirely exclude the
17
possibility that the “first individual” is not one of the “multiple users.” Thus, the Court turns to
18
the specification for further guidance.
19
ii. Specification
20
Reviewing the specification’s disclosures of “buddy lists,” the Court finds that the
21
specification also supports Uber’s position. In a number of instances, the specification uses the
22
word “others”—plural—to refer to users on a buddy list. ’593 patent, col. 2:57–61 (“The user
23
must allow others on his Buddy Lists to ‘see’ his location . . . and the user must request to see the
24
location of others on his Buddy Lists to be able to have their positions reported and/or mapped.”)
25
(emphasis added), col. 7:24–26 (“the Buddy Tracker location sharing application software is
26
active and is sharing the location of the phone with other members of a designated group”)
27
28

18
Case No. 16-CV-06050-LHK
ORDER CONSTRUING DISPUTED CLAIM TERMS OF U.S. PATENT NOS. 8,798,593 AND 8,798,647

1

(emphasis added), col. 8:12–14 (“the wireless devices in a group which has location tracking

2

turned on periodically send their GPO position data to all the other members in the group.”)

3

(emphasis added). In addition, the specification several times contrasts a buddy list of several

4

users with just a single user. Id., col. 8:31–33 (“The requested position update may be sent to

5

everybody on a selected Buddy List or just a single person’s wireless device.”), col. 10:2–3

6

(“Addresses of all persons on the buddy list or just a selected buddy are located in step 222.

7

Message packets are generated in 224 addressed to the selected Buddy List or individuals, and

8

encrypted position data is put in them.”). By contrast, there are no instances where the

9

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

10

United States District Court
Northern District of California

11

list” that contains only the first individual and one other user. It points to two instances: (1) Figure

12

2B; and (2) the instant buddy relationship, id., col. 11:50–12:9.4 Opening Br. 12–13. The Court

13

finds that, on close examination, neither of these instances disclose a “buddy list” that contains

14

only the first individual and one other user.
The Court turns first to Figure 2B. Figure 2B is shown below:

15
16
17
18
19
20
21
22
23
24
25
26
27
28

4

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.
19
Case No. 16-CV-06050-LHK
ORDER CONSTRUING DISPUTED CLAIM TERMS OF U.S. PATENT NOS. 8,798,593 AND 8,798,647

’593 patent, Fig. 2B. The specification discloses that “[i]n Figure 2B . . . [p]hone K has phone I

2

on its Buddy List and is set up to supervise phone I.” Id., col. 7:45–46. However, this does not

3

mean that, in Figure 2B, phone K only has phone I on its buddy list. The specification makes

4

clear that the purpose of Figure 2B is simply to “illustrate[] a matrix or web of supervisorial

5

relationships.” Id., col. 3:64–65, col. 7:37–40. A phone’s buddy list can contain more than just

6

the phones over which it has a supervisorial relationship. See, e.g., id., col. 7:27–30 (describing

7

how a parent or supervisor can include a supervised phone in the buddy list), col. 17:31–35

8

(same). Because Figure 2B simply “illustrates . . . supervisorial relationships,” it is impossible to

9

know whether phone K only has phone I on its buddy list or whether phone K also has other

10

phones on its buddy list. As such, the Court cannot rely on Figure 2B as an embodiment of a

11
United States District Court
Northern District of California

1

“buddy list” that contains only the first individual and one other user.

12

The Court next turns to the instant buddy relationship. The specification defines the

13

instant buddy relationship as “temporary location sharing between phones on an ask and accept

14

basis which automatically expires after a configurable interval terminates.” Id., col. 1:64–67.

15

Read in its entirety, the specification makes clear that the instant buddy relationship is a different

16

feature from the “buddy list.” It shows this in at least four different ways. First, the specification

17

consistently uses different terms to refer to each of these features: “Buddy List” and “Instant

18

Buddies,” both capitalized. See, e.g., Id., col. 11:20–12:9. Second, the specification’s

19

descriptions of each are discrete. For example, in describing Figure 14, the specification

20

separately lists “Buddy Lists” and “Instant Buddies” as two of “several modes” and provides

21

separate, back-to-back descriptions of each. Id. Third, the specification describes “Instant

22

Buddies” as something separate that can be displayed alongside the contents of a “Buddy List.”

23

For example, Figure 3 illustrates a “typical screen showing a named buddy list’s contents.” Id.,

24

Fig. 3. This display “shows individuals on the phone’s Buddy List,” “a group of buddies which

25

has been given the name Tennis Team,” and “an instant buddy entry for an instant buddy named

26

Inst01.” Id., col. 15:15–16, col. 15:26–27. Thus, the fact that an “Instant Budd[y]” is displayed in

27

addition to the “individuals on the phone’s Buddy List” shows that an instant buddy relationship

28

20
Case No. 16-CV-06050-LHK
ORDER CONSTRUING DISPUTED CLAIM TERMS OF U.S. PATENT NOS. 8,798,593 AND 8,798,647

1

cannot itself be a “buddy list.” Fourth and finally, in describing the “Buddies Only Mode,” the

2

specification distinguishes a “buddy list” from the instant buddy relationship by describing that the

3

“Buddies Only Mode” feature is only available for a “Buddy List,” but not “Instant Buddies.” Id.,

4

col. 18:53–58 (describing how in “Buddies only mode . . . position reports are only received from

5

Buddies on a specifically named Buddy List with specifically named Buddies. No . . . Instant

6

Buddy position reports can be received in this mode.”). Thus, in at least four different ways, the

7

specification makes clear that the instant buddy relationship is a separate feature from the “buddy

8

list.” As such, the instant buddy relationship is not an example of a “buddy list” that contains only

9

the first individual and one other user.

10

United States District Court
Northern District of California

11
12
13

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

14

positions. Thus, based on the claim language and specification, the Court agrees with Uber that

15

the “buddy list” must include at least two other users who are not the “first individual.”

16

b. Whether the “buddy list” requires information about location sharing

17

The parties next dispute whether the “buddy list” requires information about location

18

sharing. Uber’s proposed construction requires that the “multiple other users” are those “whose

19

location may be shared with the first individual and/or who may receive the location of the first

20

individual.” X One contends that “and/or who may receive the location of the first individual”

21

should not be included in the Court’s construction because this improperly introduces a two-way

22

location sharing feature, which is unsupported by the claims or specification. Opening Br. 14–15.

23

Uber defends its proposal as consistent with the specification and helpful to the jury. Responsive

24

Br. 13–14. For the reasons discussed below, the Court agrees with X One.

25
26
27
28

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
21
Case No. 16-CV-06050-LHK
ORDER CONSTRUING DISPUTED CLAIM TERMS OF U.S. PATENT NOS. 8,798,593 AND 8,798,647

1

“multiple users” share their location information with the first individual. See ’593 patent, col.

2

28:56–29:2, col. 30:54–31:2. They do not, however, recite that data flows in the other direction—

3

i.e., that the first individual shares his location information with the “multiple users.” See id.

4

Thus, the phrase “and/or who may receive the location of the first individual” introduces a two-

5

way location sharing feature that is not supported by the plain language of claims 1 and 19.

6

ii. Specification
The specification also does not support including “and/or who may receive the location of

8

the first individual” within the meaning of “buddy list.” The specification discloses embodiments

9

where location sharing is unidirectional. See, e.g., id., col. 7:32–37 (“This supervisory location

10

sharing can be hierarchical such that an employer can see the location of all its employees, and

11
United States District Court
Northern District of California

7

each of the employees can be set up as supervisor of their children such that the employees can see

12

the locations of their children, but the employer of each employee cannot see the locations of the

13

children of each employee.”), col. 17:38–41 (“[T]he location information sharing is unidirectional

14

from employees to supervisor but each employee can see the location of other employees on their

15

phones but not the location of the supervisor.”). Requiring that the “multiple users” “receive the

16

location of the first individual” would exclude these embodiments. See Victronics, 90 F.3d at

17

1583 (a construction that excludes a preferred embodiment is “rarely, if ever, correct”).

18

The Court notes that Uber’s proposal is written in the permissive (“may”) and thus does

19

not go so far as to categorically exclude unidirectional location sharing. Nevertheless, even if

20

“and/or who may receive the location of the first individual” only suggests that two-way location

21

sharing is possible, the Court finds it proper to exclude this phrase because it would be confusing

22

and unhelpful to the jury. “‘Claim construction’ is for the purpose of explaining and defining

23

terms in the claims . . . .” Abbott Labs. v. Sandoz, Inc., 544 F.3d 1341, 1360 (Fed. Cir. 2008). A

24

construction written in the permissive suggesting that an additional feature “may” be part of the

25

invention does not serve this purpose. Thus, the Court finds that the best course of action is to not

26

include “and/or who may receive the location of the first individual” in its construction of “buddy

27

list.” In sum, the Court agrees with X One that “and/or who may receive the location of the first

28

22
Case No. 16-CV-06050-LHK
ORDER CONSTRUING DISPUTED CLAIM TERMS OF U.S. PATENT NOS. 8,798,593 AND 8,798,647

1

individual” should not be included in the construction of “buddy list.”

2

c. Whether the “buddy list” corresponds to an account of the first individual

3

The parties’ final dispute is whether the “buddy list” corresponds to an account of the first

4

individual. Uber’s proposed construction requires that the “buddy list” is “a list, corresponding to

5

an account of the first individual.” Responsive Br. 9. X One argues that “corresponding” is an

6

improper redrafting of claims 1 and 19, which recite “a database representing an account for a first

7

individual, the account having an associated buddy list that identifies multiple users.” Opening

8

Br. 15–16. Uber defends “corresponding” as consistent with the plain meaning of the claim

9

language. Responsive Br. 14.

10

The parties largely agree on substance: whether the buddy list is “associated” with the first

United States District Court
Northern District of California

11

individual or “corresponds” to the first individual, the broader point is that there is some

12

relationship between the two. However, because the claim language uses the word “associated”

13

and Uber makes no argument as to why “corresponding” would assist the jury or is otherwise a

14

superior choice, the Court sees no reason to change “associated” to “corresponding.” See Abbott

15

Labs, 544 F.3d at 1360 (“‘Claim construction’ is for the purpose of explaining and defining terms

16

in the claims . . . .”). Thus, the Court will use “associated” in its construction.

17
18

d. Conclusion
As set forth above, the Court agrees with Uber that the “buddy list” must include at least

19

two other users who are not the “first individual.” However, the Court agrees with X One that

20

Uber’s proposed language of “and/or who may receive the location of the first individual” and

21

“corresponding” should not be included in the construction of “buddy list.” Accordingly, the

22

Court adopts a modified version of Uber’s proposal. The Court construes “buddy list” to mean “a

23

list, associated with an account of the first individual, that identifies multiple other users whose

24

location may be shared with the first individual.”

25

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)

26
27
28

X One’s Proposed Construction
A database including data related to a first

Uber’s Proposed Construction
a database accessible by the server that
23

Case No. 16-CV-06050-LHK
ORDER CONSTRUING DISPUTED CLAIM TERMS OF U.S. PATENT NOS. 8,798,593 AND 8,798,647

1
2

individual who is authorized to access and use
the software. A buddy list is associated with
the first individual’s account.

3

includes an account for a first individual, the
account having a list of multiple other users
that identifies those users whose location may
be shared with the first individual and/or who
may receive the location of the first individual

The disputed phrase “a database . . .” appears in claims 1 and 19. For example, claim 1
4
recites:
5
1. An apparatus, comprising:
6

a server;

7

a database representing an account for a first individual, the account
having an associated buddy list that identifies multiple users; and

8

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;

9
10

United States District Court
Northern District of California

11

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

12
13
14

wherein the software to obtain the map is to obtain the map in a manner
having a default geographic resolution.

15
16

’593 patent at col. 28:51–29:4 (emphasis added).

17
18
19

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. 5 The
Court addresses each of these disputes in turn.

20

a. Whether the database must store the account

21

The parties’ first dispute is whether the database must store the account. X One argues that

22
23
24
25
26
27
28

5

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.
24
Case No. 16-CV-06050-LHK
ORDER CONSTRUING DISPUTED CLAIM TERMS OF U.S. PATENT NOS. 8,798,593 AND 8,798,647

1

the database need only store “data related to a first individual”—not the account itself—because

2

the claim language requires no more than this. Opening Br. 16–17. Uber argues that the database

3

should store the account itself because in order for the database to “represent[]” the account, it

4

must include the account. Responsive Br. 16. For the reasons discussed below, the Court agrees

5

with X One.

6
7

i. Claim Language
The claim language resolves the parties’ dispute. Claims 1 and 19 only require “a database

8

representing an account.” ’593 patent, col. 28:53, col. 30:51 (emphasis added). A representation

9

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

11
United States District Court
Northern District of California

10

‘symbolizing’ or ‘to stand for’ . . . . On the other hand, the statement that one item ‘represents’

12

another cannot be interpreted so broadly as to include any case in which the two items are related

13

in some way. Rather, the first item must be directly related to and stand for, or be a reasonable

14

proxy for, the latter item.”); ART+COM Innovationpool Gmbh v. Google Inc., No. CV 1:14-217-

15

TBD, 2016 WL 2945194, at *2 (D. Del. May 20, 2016) (“[T]he ordinary meaning of

16

‘representing’ is broader than ‘displaying on a screen’ and can include symbolizing, standing for,

17

or being a reasonable proxy for a subsequent viewable image.”). Thus, unless the specification or

18

prosecution history otherwise compel it, “representing” is entitled to the full scope of its plain and

19

ordinary meaning. Wasica Fin. GmbH v. Cont’l Auto. Sys., Inc., 853 F.3d 1272, 1281 (Fed. Cir.

20

2017) (“It is axiomatic that we will not narrow a claim term beyond its plain and ordinary meaning

21

unless there is support for the limitation in the words of the claim, the specification, or the

22

prosecution history.”) (quoting 3M Innovative Props. Co. v. Tredegar Corp., 725 F.3d 1315, 1333

23

(Fed. Cir. 2013). Consistent with the Federal Circuit’s and other courts’ assessments of the word

24

“representing,” this plain and ordinary meaning would require that the “represent[ation] of the

25

account” is directly related to and standing for the account, but nothing more restrictive.

26
27
28

ii. Specification and Prosecution History
Neither party identifies anything in the specification or prosecution history that warrants a
25
Case No. 16-CV-06050-LHK
ORDER CONSTRUING DISPUTED CLAIM TERMS OF U.S. PATENT NOS. 8,798,593 AND 8,798,647

1

narrower construction of “representing.” Opening Br. 16–18; Responsive Br. 15–16. Thus, the

2

Court will not narrow its meaning beyond the plain and ordinary meaning discussed above.

3

Accordingly, the Court agrees with X One that the database need not store the actual account.

4
5

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.

6

X One argues that the database need not be accessible by the server because the claim language is

7

silent on this point. Opening Br. 17–18. Uber argues that the database must be accessible by the

8

server because the specification discloses that this is the case. Responsive Br. 16. The Court

9

agrees with Uber.

10

United States District Court
Northern District of California

11

i. Claim Language
Beginning with the claim language, the Court notes that the claims do not explicitly state

12

where the “database” is stored and whether it is accessible by the server. See ’593 patent, col.

13

28:51–29:4, col. 30:49–31:2. However, when “database” is read in context with the remainder of

14

the claim language, the claim language supports Uber’s position that the “database” is “accessible

15

by the server.” ACTV, Inc. v. Walt Disney Co., 346 F.3d 1082, 1088 (Fed. Cir. 2003) (“[T]he

16

context of the surrounding words of the claim also must be considered in determining the ordinary

17

and customary meaning of those terms.”). Specifically, after the claims recite “a database

18

representing an account . . . having an associated buddy list . . . ,” the claims immediately recite

19

operations that are performed by “software” using this “buddy list” information, such as

20

“obtain[ing] a last known position for multiple users identified by the buddy list.” ’593 patent,

21

col. 28:56–61, col. 30:54–58. As determined below with respect to “last known location,” this

22

“software” is run on the “server.” See Section III.A.4, infra. Thus, it makes sense that, in order

23

for the “software” to be able to perform the recited operations with respect to the “buddy list,” the

24

“database” must be accessible by the “server.” As such, the claim language supports Uber’s

25

position.

26
27
28

ii. Specification
The specification provides further support for Uber’s position. In its section on “The
26
Case No. 16-CV-06050-LHK
ORDER CONSTRUING DISPUTED CLAIM TERMS OF U.S. PATENT NOS. 8,798,593 AND 8,798,647

1

Server Genus,” the specification discloses that “[a]ll servers programmed with the Buddy Watch

2

software will have functionality to . . . store user defined data that embodies each user’s buddy

3

lists and buddies and configuration data.” ’593 patent, col. 25:6–10. This statement does not

4

simply describe a preferred embodiment. Instead, it is an explicit characterization of all of the

5

“servers” in the invention. See Aventis Pharma S.A. v. Hospira, Inc., 675 F.3d 1324, 1330 (Fed.

6

Cir. 2012) (A “clear expression [to define a claim term] need not be in haec verba but may be

7

inferred from clear limiting descriptions of the invention in the specification or prosecution

8

history.”); see, e.g., Stumbo v. Eastman Outdoors, Inc., 508 F.3d 1358, 1363 (Fed. Cir. 2007)

9

(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

11
United States District Court
Northern District of California

10

have the “functionality . . . to store data that embodies each user’s buddy lists and buddies and

12

configuration data.” ’593 patent, col. 25:6–10. It follows that if the server can store this data, this

13

data is accessible to the server. This conclusion is bolstered by other portions of the specification,

14

which describe preferred embodiments where a database is accessible to a server. Id., col. 6:11–

15

15 (describing how “[a] response to the request in the packet [from a device] is prepared using

16

information from a database maintained by the Rubicon server”), col. 12:39–40 (listing “database

17

access and maintenance” as a “function[] of the Buddy Watch server”). Accordingly, the claimed

18

“server” includes “functionality to . . . store data that embodies each user’s buddy lists and

19

buddies and configuration data.”

20

That said, the Court does not read the specification as requiring that the claimed “database”

21

is the same as the server’s “functionality . . . to store data that embodies each user’s buddy lists

22

and buddies and configuration data.” ’593 patent, col. 26:6–10. It may be, for example, that the

23

server has this “functionality . . .” but then additionally the claimed “database” is stored

24

somewhere else. Nevertheless, the fact that the server has this “functionality . . . to store data that

25

embodies each user’s buddy lists and buddies and configuration data,” id., at least bolsters the

26

conclusion that the claimed “database” that contains “represent[ations] of this data” is accessible

27

by the “server.”

28

27
Case No. 16-CV-06050-LHK
ORDER CONSTRUING DISPUTED CLAIM TERMS OF U.S. PATENT NOS. 8,798,593 AND 8,798,647

1
2
3

Accordingly, the specification supports what the claim language already suggests: the
“database” must be accessible by the server.
c. Conclusion

4

In sum, the Court finds that (1) the “database” need not store the account; but (2) the

5

“database” must be accessible by the server. In addition, the parties agree that the “database” need

6

not store the buddy list. Compare Opening Br. 16, with Responsive Br. 16.

7

As the Court has resolved one dispute in favor of X One and one dispute in favor of Uber,

8

the Court must determine which of the parties’ competing constructions it should use as a model

9

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

11
United States District Court
Northern District of California

10

construction’ is for the purpose of explaining and defining terms in the claims . . . .”). Uber’s

12

proposed construction is a crisp phrase that parallels the grammatical structure of the disputed

13

limitation and incorporates the construction of “buddy list,” whereas X One’s proposed

14

construction consists of two bulky sentences that do not define “buddy list.” The Court will thus

15

adopt the structure of Uber’s proposal, but modify it to reflect the Court’s resolution of the parties’

16

dispute. The Court construes “a database representing an account for a first individual, the

17

account having an associated buddy list that identifies multiple users” to mean “a database

18

accessible by the server that includes data directly related to and standing for an account for a first

19

individual, the account having an associated list that identifies multiple other users whose location

20

may be shared with the first individual.”

21
22
23

4. “last known location” (claims 1 and 19)
X One’s Proposed Construction
plain meaning

24

Uber’s Proposed Construction
most-recent position stored on the server for a
user at the time the user’s position is plotted
on the map

The term “last known location” appears in claims 1 and 19. For example, claim 1 recites:
25
26

1. An apparatus, comprising:
a server;

27
28

a database representing an account for a first individual, the account having an
28
Case No. 16-CV-06050-LHK
ORDER CONSTRUING DISPUTED CLAIM TERMS OF U.S. PATENT NOS. 8,798,593 AND 8,798,647

1
2
3
4
5
6
7
8
9
10

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.
’593 patent, col. 28:51–29:4 (emphasis added).
X One argues that “last known location” requires no construction. Opening Br. 18–20.

United States District Court
Northern District of California

11

Uber argues that “last known location” should be construed to mean “most-recent position stored

12

on the server for a user at the time the user’s position is plotted on the map.” Responsive Br. 16–

13

20. Hence, the parties dispute whether (1) a user’s “last known location” is stored on the server;

14

and (2) the “last known location” is determined at the time a user’s position is plotted on the map.

15

The Court addresses each of these disputes in turn.

16
17
18

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

19

the “last known location” is stored. Nevertheless, read in its entirety, the Court finds that the

20

claim language, on balance, favors Uber’s position. Claims 1 and 19 recite a “server.” ’593

21

patent, col. 28:52, col. 30:50. Then, they recite “software” which performs server-like functions,

22

such as “obtain a map,” “obtain a last known position for multiple users identified by the buddy

23

list,” “plot the last known location of at least two of the multiple users on the map,” “transmit the

24

map with plotted locations to the first individual,” and “request and store position information

25

associated with cell phones of plural ones of the multiple users.” Id., col. 28:57–64. Thus, the

26

most logical reading of this claim language is that the “software” runs on the server. If this is true,

27

this means that when the “software . . . request[s] and store[s] position information,” this “position

28

29
Case No. 16-CV-06050-LHK
ORDER CONSTRUING DISPUTED CLAIM TERMS OF U.S. PATENT NOS. 8,798,593 AND 8,798,647

1

information”—including the “last known location”—is stored on the server. As such, reading

2

“last known location” in the context of the rest of the claims supports Uber’s position that “last

3

known location” is stored on the server.

4
5

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

7

“software” in claims 1 and 19 as functions of which “[a]ll servers programmed with Buddy Watch

8

software” will be capable. ’593 patent, col. 24:59–25:21 (disclosing that “[a]ll servers

9

programmed with Buddy Watch software will have functionality to . . . obtain pertinent map data,”

10

“request and receive update and regularly scheduled GPS location data from users,” “render buddy

11
United States District Court
Northern District of California

6

locations on maplets based upon GPS location data,” and “serve the maplet data to Buddy Watch

12

enabled phones”). As stated above with respect to “database,” this is an explicit definitional

13

statement about all servers, not just a description of a preferred embodiment. See Section III.A.3,

14

supra. This is further bolstered by portions of the specification that explicitly disclose that the

15

server stores location information. E.g., ’593 patent, col. 17:59–61 (“The server receives positions

16

reports from all the Buddy Watch phones registered with it and stores them and knows the Buddy

17

Lists for each phone.”). Thus, when read in light of the specification, the “software” in claims 1

18

and 19 is “software” that resides on the server.

19

As discussed above, the claims require that the “software . . . store position information,”

20

and wherever the software is run is also where the “position information” is “stor[ed].” Thus,

21

because, as discussed above, the specification makes clear that the “software” is run on the server,

22

the “position information”—including the “last known location”—is also stored on the server.

23

X One nevertheless argues that the “last known location” need not be stored on the server

24

because the specification discloses embodiments where a user’s last known location is not sent to

25

(and hence, not stored on) the server, but is instead sent directly from one device to another.

26
27
28

30
Case No. 16-CV-06050-LHK
ORDER CONSTRUING DISPUTED CLAIM TERMS OF U.S. PATENT NOS. 8,798,593 AND 8,798,647

1

Opening Br. 19 (citing ’543 patent, col. 8:40–9:65).6 However, as discussed above with respect to

2

“account,” claims 1 and 19 specifically require a “server.” See Section III.A.1, supra. Thus, in

3

construing claims 1 and 19, the Court must focus on disclosed embodiments in the specification

4

that include a server. Accordingly, the device-to-device embodiments that X One cites fall outside

5

the scope of claims 1 and 19 and have little relevance to their construction.
In sum, the specification confirms what the claim language modestly suggests: Uber is

6
7

correct that the “last known location” is stored on the server.

8

b. Whether the “last known location” is determined at the time a user’s position
is plotted on the map

9
The claim language is sufficient to end the parties’ dispute. Claims 1 and 19 recite a fluid
10
set of actions that occur “responsive to a request from the first individual:” “obtain[ing] a map,”
11
United States District Court
Northern District of California

“obtain[ing] a last known position for multiple users,” and “plot[ting] the last known location of at
12
least two of the multiple users on the map.” ’593 patent, col. 28:57–61, col. 30:60–64. Putting
13
these statements together, the “last known location” must be determined at the time of plotting. It
14
would not make sense for it to be determined before the time of plotting because that would mean
15
that the plotting was not “responsive” to the first individual’s request. It would also not make
16
sense for it to be determined after the time of plotting, because, in order to “plot[] the last known
17
location,” that “last known location” must first be determined. Thus, the “last known location” is
18
determined at the time of plotting.
19
Nevertheless, having determined that “last known location” is determined at the time of
20
plotting still leaves open the question of whether Uber’s proposed language of “most-recent
21
position stored on the server” better captures this meaning than the claim language itself. X One
22
argues that “most-recent position stored on the server” ignores the fact that a user may have
23
several “last known locations” depending on the buddy list: a user may choose to share his
24
25
26
27
28

6

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.
31
Case No. 16-CV-06050-LHK
ORDER CONSTRUING DISPUTED CLAIM TERMS OF U.S. PATENT NOS. 8,798,593 AND 8,798,647

1

location with one buddy all the time, whereas the user may choose to share his location with

2

another buddy only sometimes. Opening Br. 19–20; Reply Br. 8–9. Uber does not specifically

3

respond to this argument. Responsive Br. 16–20.

4

The Court agrees with X One that “most-recent position stored on the server” injects some

5

confusion into the meaning of “last known location” because different buddy lists could have

6

different “last known locations.” Compare, e.g., ’593 patent, col. 11:12–19 (describing a buddy

7

list where location sharing is always on), with id., col. 11:25–27 (describing a buddy list where

8

location sharing is only on during work hours). However, the Court finds that this problem can be

9

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

11
United States District Court
Northern District of California

10

that that user has shared with a particular buddy list. Thus, the Court will adopt Uber’s proposed

12

construction, subject to this modification.

13
14

c. Conclusion
In sum, the Court finds that (1) a user’s “last known location” is stored on the server; and

15

(2) the “last known location” is determined at the time a user’s position is plotted on the map. The

16

Court, however, agrees with X One that “last known location” can be different depending on the

17

buddy list used. As such, the Court adopts a modified version of Uber’s proposed construction.

18

The Court construes “last known location” to mean “most-recent shared position stored on the

19

server for a user at the time the user’s position is plotted on the map.”

20
21
22
23
24
25
26
27
28

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
plain meaning

Uber’s Proposed Construction
wherein the requestor of the desired service
selects the provider of the desired service /
selecting the provider of the desired service by
the 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
32
Case No. 16-CV-06050-LHK
ORDER CONSTRUING DISPUTED CLAIM TERMS OF U.S. PATENT NOS. 8,798,593 AND 8,798,647

1
2
3
4
5
6
7
8
9
10

United States District Court
Northern District of California

11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28

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
33
Case No. 16-CV-06050-LHK
ORDER CONSTRUING DISPUTED CLAIM TERMS OF U.S. PATENT NOS. 8,798,593 AND 8,798,647

1
2
3
4
5
6
7
8
9
10

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.
’647 patent, col. 28:50–29:19, col. 30:47–31:12 (emphasis added).
X One argues that the disputed phrases require no construction and should be given their

United States District Court
Northern District of California

11

plain meaning. Opening Br. 20–21. Uber, on the other hand, argues that the phrase “wherein the

12

provider is selected in connection with the request for the desired service” in claims 1 and 28

13

should be construed to mean “wherein the requestor of the desired service selects the provider of

14

the desired service.” Responsive Br. 20–22. Uber argues that the phrase “selecting the provider

15

of the desired service” in claim 22 should be construed to mean “selecting the provider of the

16

desired service by the requestor of the desired service.” Id. Comparing these proposals, the

17

parties’ dispute boils down to a simple issue: whether anyone (X One’s position) or only the

18

“requestor” (Uber’s position) can select the service provider. For the reasons discussed below, the

19

Court agrees with X One.

20
21

i. Claim Language and Specification
The plain language of the claims only recites “selecting the provider” or that the “provider

22

is selected,” and does not specify who does the selecting. ’647 patent, col. 30:47–31:12, col.

23

31:37–32:5. As a result, both sides focus on the specification. X One argues that the specification

24

not only discloses embodiments where the requestor selects the service provider, but also

25

embodiments where someone else—such as the service provider company—selects the service

26

provider. Opening Br. 20–21. In particular, X One points to two embodiments: (1) a “stranded

27

motorist or hiker” embodiment, ’647 patent, col. 17:7–14; and (2) a skillset-based selection
34

28

Case No. 16-CV-06050-LHK
ORDER CONSTRUING DISPUTED CLAIM TERMS OF U.S. PATENT NOS. 8,798,593 AND 8,798,647

1

embodiment, id., col. 20:58–21:1. Uber responds that the “stranded motorist or hiker”

2

embodiment confirms that only the requestor selects the service provider. Responsive Br. 21–22.

3

Uber does not address the skillset-based selection embodiment. See id.

4

Upon reviewing each of the identified embodiments, the Court finds that the specification

5

does not support an inference that only the “requestor” can select the service provider. Turning

6

first to the “stranded motorist or hiker” embodiment, the specification discloses that:

7

9

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.

10

’647 patent, col. 17:7–14. The key to the parties’ dispute is the first sentence: after calling a tow

11

truck or 911, the stranded motorist or hiker “get[s]” the caller ID and carrier of his specific tow

12

truck driver or rescuer. Id., col. 17:8–10. This phrase is ambiguous as to who does the selecting:

13

in some cases, it may be that the 911 operator selects a tow truck or rescue service; in other cases,

14

it may be that the stranded motorist or hiker himself requests a particular tow truck or rescue

15

service, either by virtue of calling a particular tow truck service or by telling the 911 operator

16

which service they would like to use. Thus, it does not support limiting the claims such that only

17

the “requestor” may select a particular service provider.

United States District Court
Northern District of California

8

18

Turning next to the skillset-based selection embodiment, the specification discloses that:

19

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.

20
21
22
23
24

Id., col. 20:58–21:1 (emphasis added). In its plainest reading, this passage discloses that the

25

“service based organization” can select a service provider. Specifically, the fact that the “service

26

based organization can determine which individuals” have the fitting skillset implies that, through

27

making this determination, the “service based organization” selects those individuals—i.e., service

28

35
Case No. 16-CV-06050-LHK
ORDER CONSTRUING DISPUTED CLAIM TERMS OF U.S. PATENT NOS. 8,798,593 AND 8,798,647

1

providers. See id., col. 20:64–21:1. Thus, the skillset-based selection embodiment supports

2

Uber’s position that entities other than the “requestor” can select the service provider.

3
4

ii. Conclusion
In sum, the claims are silent as to who can select the service provider and the specification

5

supports the inference that entities other than the “requestor” can select the service provider.

6

Accordingly, the Court agrees with X One that anyone—not just the “requestor”—can select the

7

service provider. The claims, written in the passive voice, best reflect this meaning. Accordingly,

8

the Court will not construe them further.

9

2. “responsive to launching an application” (claims 1 and 28) / “in association with
an application launched” (claim 22)

10

United States District Court
Northern District of California

11

X One’s Proposed Construction
plain meaning

12

Uber’s Proposed Construction
in association with the running of the
application

The phrase “responsive to launching an application” appears in claims 1 and 28 of the ’647
13
14

patent. The phrase “in association with an application launched” appears in claim 22. For
example, claims 1 and 22 recite:

15
16
17
18
19
20
21
22
23
24
25
26
27
28

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
36
Case No. 16-CV-06050-LHK
ORDER CONSTRUING DISPUTED CLAIM TERMS OF U.S. PATENT NOS. 8,798,593 AND 8,798,647

1
2
3
4
5
6
7
8
9
10

United States District Court
Northern District of California

11
12
13
14
15
16
17
18
19
20
21
22
23

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 usespecific group to have the first wireless device and the second wireless device
in connection with the request for the desired service.
’647 patent, col. 28:50–29:19, col. 30:47–31:12 (emphasis added).
X One argues that the disputed phrases require no construction and should be given their

24
plain meaning. Opening Br. 21–23. Uber, on the other hand, argues that the disputed phrases
25
26

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

27
28

37
Case No. 16-CV-06050-LHK
ORDER CONSTRUING DISPUTED CLAIM TERMS OF U.S. PATENT NOS. 8,798,593 AND 8,798,647

1

with the running of an application, or simply in association with either “launching an application”

2

or “an application launched.” For the reasons discussed below, the Court agrees with X One.
i. Claim Language and Specification

3
4

The plain language of the claims is silent as to what relation the claimed actions have to

5

whether an application is running. See ’647 patent, col. 28:50–29:19, col. 30:47–31:12, col.

6

31:37–32:5. Hence, if there is any support for Uber’s proposed construction, it must be found in

7

the specification. Upon review of the specification, the Court finds that it does not require the

8

“running” modification that Uber proposes. In general, the specification describes the

9

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

11
United States District Court
Northern District of California

10

running. See, e.g., ’647 patent, col. 15:27–38, col. 17:7–27. Moreover, the specification discloses

12

that it is possible for devices to be temporarily disabled where the application would not be

13

running. Id., col. 10:50–11:4, col. 22:5–11, col. 22:44–23:20. Accordingly, the specification also

14

does not require the “running” modification that Uber proposes.

15

In its briefing, Uber does not make an affirmative case for why the Court should adopt its

16

“running” modification. Instead, it devotes most of its briefing to arguing why X One’s plain

17

meaning position is incorrect. Although the Court has already rejected Uber’s proposed “running”

18

modification, it additionally finds that none of Uber’s arguments against X One’s plain meaning

19

approach is persuasive. It discusses each in turn.

20

First, Uber argues that the phrases “responsive to launching” or “in association with an

21

application launched” are vague. Responsive Br. 22–23. The Court disagrees. “Responsive to

22

launching” simply places a temporal relationship on launching and the other claimed functions:

23

they happen in response to launching. “In association with an application launched” is broader,

24

and just requires some relationship between launching and the claimed functions. Thus, in both

25

cases, how the claimed functions relate to launching is sufficiently clear. It may be that the claims

26

are not as narrowly scoped as Uber would like, but this is not a reason to adopt a narrowing

27

construction.

28

38
Case No. 16-CV-06050-LHK
ORDER CONSTRUING DISPUTED CLAIM TERMS OF U.S. PATENT NOS. 8,798,593 AND 8,798,647

Second, Uber argues that the specification does not provide written description support for

1
2

“responsive to launching” and “in association with an application launched.” Responsive Br. 23.

3

The Court disagrees. As Uber admits in its briefing (Responsive Br. 22–23), the specification

4

discloses launching an application. See, e.g., ’647 patent, col. 6:29–31 (“On startup, each handset

5

starts its GPS sampler and the Buddy Watch application program.”). Then, as Uber also admits

6

(Responsive Br. 23), the specification discloses “display of [a] map.” See, e.g., ’647 patent, col.

7

6:31–41 (describing “show[ing] the Mapit page”), col. 15:26–38 (describing showing a tow truck

8

driver and a stranded motorist on a moving map), col. 17:6–27 (same). The fact that these

9

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

11
United States District Court
Northern District of California

10

“responsive to” or “in association with” launching. Cf. Pozen Inc. v. Par Pharm., Inc., 696 F.3d

12

1151, 1167 (Fed. Cir. 2012) (“As this court has explained, ‘[i]n order to satisfy the written

13

description requirement, the disclosure as originally filed does not have to provide in haec verba

14

support for the claimed subject matter at issue . . . . Nonetheless, the disclosure . . . must convey

15

with reasonable clarity to those skilled in the art that . . . [the inventor] was in possession of the

16

invention.’”) (quoting Purdue Pharma L.P. v. Faulding Inc., 230 F.3d 1320, 1323 (Fed. Cir.

17

2000)). Thus, there is written description support for “responsive to launching” and “in

18

association with an application launched.”
Third and finally, Uber argues that “responsive to launching” or “in association with an

19
20

application launched” excludes a preferred embodiment. Responsive Br. 23. The Court disagrees.

21

As an initial matter, Uber does not specifically identify what this preferred embodiment is, but

22

simply refers to it as “the preferred embodiment which requires user input while the application is

23

running.” 7 Nevertheless, even without specifically addressing this purportedly excluded

24

embodiment, the Court can conclude that it would not be excluded. “Responsive to launching” or

25
26
27
28

7

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.
39
Case No. 16-CV-06050-LHK
ORDER CONSTRUING DISPUTED CLAIM TERMS OF U.S. PATENT NOS. 8,798,593 AND 8,798,647

1

“in association with an application launched” does not mean that the application cannot be

2

running. Thus, a preferred embodiment which requires user input while the application is running

3

would not be automatically excluded by “responsive to launching” or “in association with an

4

application launched.”

5
6

ii. Conclusion
In sum, neither the claim language nor the specification warrants Uber’s proposed

7

construction. Instead, the Court finds that the claim language is sufficiently clear. The phrases

8

“responsive to launching an application” and “in association with an application launched” shall

9

be given their plain meaning and not construed further.

10

3. “forming a use-specific group” (claims 1 and 22) / “formation of a use-specific
group” (claim 28)

United States District Court
Northern District of California

11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28

X One’s Proposed Construction
plain meaning

Uber’s Proposed Construction
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
40
Case No. 16-CV-06050-LHK
ORDER CONSTRUING DISPUTED CLAIM TERMS OF U.S. PATENT NOS. 8,798,593 AND 8,798,647

1
2
3
4
5
6
7
8
9
10

United States District Court
Northern District of California

11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28

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 usespecific 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 machinereadable 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
41
Case No. 16-CV-06050-LHK
ORDER CONSTRUING DISPUTED CLAIM TERMS OF U.S. PATENT NOS. 8,798,593 AND 8,798,647

1
2
3
4
5
6
7
8
9
10

United States District Court
Northern District of California

11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28

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.
’647 Patent at col. 28:50–29:18, col. 30:47–31:12, col. 31:37–32:5 (emphasis added).
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 “usespecific 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,
42
Case No. 16-CV-06050-LHK
ORDER CONSTRUING DISPUTED CLAIM TERMS OF U.S. PATENT NOS. 8,798,593 AND 8,798,647

1

whereas the specification uses the phrase “Instant Buddies” to refer to a relationship between a

2

service provider and a requestor. Id. at 25.

3

For the reasons discussed below, the Court finds that “use-specific group” does not render

4

the asserted claims of the ’647 patent indefinite. Instead, the Court adopts X One’s proposal and

5

construes this phrase according to its plain meaning.

6

i. Claim Language

7

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

9

service” and “a requestor of the desired service.” ’647 patent, col. 28:50–56, col. 30:47–52, col.

10

31:55–60. Then, in referring to “use-specific group,” they recite “forming a use-specific group to

11
United States District Court
Northern District of California

8

have the first wireless device and the second wireless device in connection with the request for the

12

desired service.” Id., col. 29:13–18, col. 31:9–12, col. 31:66–32:5. Reading these limitations

13

together, it is plain that the “group” is the pairing of the “first wireless device” and the “second

14

wireless device” and it is “use-specific” because it is formed for the purpose of facilitating or

15

effectuating the “desired service.” The claims recite no other entities that could be part of the

16

“group” or no other aspects of their relationship that would muddy why their pairing is “use-

17

specific.” As such, a person of ordinary skill in the art would be able to read claims 1, 22, and 28

18

and understand the meaning of “use-specific group” such that they would be informed about the

19

scope of the invention with reasonable certainty. See Nautilus, 134 S. Ct. at 2124.

20

The same holds true for “forming.” The claim language surrounding “[forming / formation

21

of] a use-specific group” recites “selecting the provider of the desired service” and “to have the

22

first wireless device and the second wireless device in connection.” ’647 patent, col. 29:13–18,

23

col. 31:9–12, col. 31:66–32:5. Read in context, it is clear that “forming” simply refers to this

24

process of connecting the first and second wireless devices. A skilled artisan would be able to

25

know the range of what it means for two wireless devices to be “connect[ed].” Thus, a person of

26

ordinary skill in the art would also be able to read claims 1, 22, and 28 and understand the

27

meaning of “forming” such that they would be informed about the scope of the invention with

28

43
Case No. 16-CV-06050-LHK
ORDER CONSTRUING DISPUTED CLAIM TERMS OF U.S. PATENT NOS. 8,798,593 AND 8,798,647

1
2

reasonable certainty. See Nautilus, 134 S. Ct. at 2124.
ii. Specification

3

The specification bolsters these conclusions. As discussed in other sections above, one of

4

the service provider-specific embodiments disclosed in the specification is the “stranded motorist

5

or hiker” embodiment. ’647 patent, col. 15:26–38, col. 17:7–27. In this embodiment,

6
7
8
9
10

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

11
United States District Court
Northern District of California

tow truck driver and the user, and it is “use-specific” because the pairing is set up for the specific
12
purpose of helping to provide the towing service. Thus, reading the claims in light of this
13
disclosure further elucidates the meaning of “use-specific group.” It would not be unreasonable
14
for a skilled artisan to take this example and know what other types of “use-specific groups” are
15
covered by the claims.
16
The same can be said of “forming.” Here, in this example, the two wireless devices that
17
“form[]” the “use-specific group” are cell phones. There is a discrete range of possible ways the
18
cell phones can connect with one another, all of which would be familiar to a skilled artisan. The
19
skilled artisan would also be able to take this example and infer, for other types of “use-specific
20
groups” involving other types of “wireless devices,” the range of ways of connecting that would
21
be covered by “forming.” Thus, the specification further helps inform the meaning of “[forming /
22
formation of] a use-specific group.” As such, the Court concludes that “[forming / formation of] a
23
use-specific group” does not make it such that the “claims, read in light of the specification
24
delineating the patent, and the prosecution history, fail to inform, with reasonable certainty, those
25
skilled in the art about the scope of the invention.” Nautilus, 134 S. Ct. at 2124.
26
Uber’s arguments to the contrary, Responsive Br. 24–25, are unpersuasive. First, whether
27
28

44
Case No. 16-CV-06050-LHK
ORDER CONSTRUING DISPUTED CLAIM TERMS OF U.S. PATENT NOS. 8,798,593 AND 8,798,647

1

the phrase “use-specific group” appears in the specification of the X One Patents is irrelevant. See

2

Cox Commc’ns, 838 F.3d at 1231 (explaining that “the dispositive question in an indefiniteness

3

inquiry is whether the ‘claims,’ not particular claim terms” fail the Nautilus test). Second, as

4

discussed above, the Court finds that the “stranded motorist or hiker” embodiment does inform the

5

meaning of “use-specific group” because it gives a concrete example of a “group” (the motorist

6

and the tow truck driver) and how it is “use-specific” (towing services). Finally, the fact that the

7

specification uses “group” to refer to something other than the embodiments covered by claims 1,

8

22, and 28 is irrelevant. Even if there are differences between the use of the word “group” in the

9

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

11
United States District Court
Northern District of California

10

scope of the claims with reasonable certainty, the claims are not indefinite. Nautilus, 134 S. Ct. at

12

2124. Such is the case here.

13

Accordingly, “[forming / formation of] a use-specific group” does not render the claims

14

indefinite. The Court instead adopts X One’s position and construes this phrase according to its

15

plain meaning.

16

IV. CONCLUSION

17

For the foregoing reasons, the Court construes the disputed claim terms as follows:

18

’593 patent:

19

1.

“account” as “an arrangement for user-specific authenticated access;”

20

2.

“buddy list” as “a list, associated with an account of the first individual, that

21
22

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

23

associated buddy list that identifies multiple users” as “a database accessible by the server that

24

includes data directly related to and standing for an account for a first individual, the account

25

having an associated list that identifies multiple other users whose location may be shared with the

26

first individual;”

27

4.

28

“last known location” as “most-recent shared position stored on the server for a
45

Case No. 16-CV-06050-LHK
ORDER CONSTRUING DISPUTED CLAIM TERMS OF U.S. PATENT NOS. 8,798,593 AND 8,798,647

1

user at the time the user’s position is plotted on the map;”

2

’647 patent:

3

5.

4
5
6
7

“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

8

group” as plain meaning.

9

IT IS SO ORDERED.

10

United States District Court
Northern District of California

11
12
13

Dated: August 18, 2017
______________________________________
LUCY H. KOH
United States District Judge

14
15
16
17
18
19
20
21
22
23
24
25
26
27
28

46
Case No. 16-CV-06050-LHK
ORDER CONSTRUING DISPUTED CLAIM TERMS OF U.S. PATENT NOS. 8,798,593 AND 8,798,647