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

• Court: Court of Appeals for the Federal Circuit
• Decided: March 3, 2020
• Docket: 19-1165
• Status: Unpublished

Opinion

Case: 19-1165 Document: 46 Page: 1 Filed: 03/03/2020

NOTE: This disposition is nonprecedential.

United States Court of Appeals for the Federal Circuit ______________________

UBER TECHNOLOGIES, INC., Appellant

v.

X ONE, INC., Appellee ______________________

2019-1165 ______________________

Appeal from the United States Patent and Trademark Office, Patent Trial and Appeal Board in No. IPR2017- 01264. ______________________

Decided: March 3, 2020 ______________________

LAUREN ANN DEGNAN, Fish & Richardson PC, Wash- ington, DC, argued for appellant. Also represented by MICHAEL JOHN BALLANCO, CHRISTOPHER DRYER, WALTER KARL RENNER.

DORIS JOHNSON HINES, Finnegan, Henderson, Farabow, Garrett & Dunner, LLP, Washington, DC, ar- gued for appellee. Also represented by JEFFREY CURTISS TOTTEN; KEVIN D. RODKEY, Atlanta, GA; JACOB ADAM SCHROEDER, Palo Alto, CA. Case: 19-1165 Document: 46 Page: 2 Filed: 03/03/2020

______________________

Before PROST, Chief Judge, DYK and WALLACH, Circuit Judges. DYK, Circuit Judge. Uber Technologies, Inc. (“Uber”) appeals a decision of the Patent Trial and Appeal Board (“Board”). The Board declined to find certain claims of U.S. Patent No. 8,798,647 (“the ’647 patent”) unpatentable as obvious. We reverse the Board’s determination of non-obviousness as to the inde- pendent claims, vacate the Board’s determination as to the dependent claims, and remand for further proceedings. BACKGROUND X One, Inc., (“X One”) owns the ’647 patent, which is directed to exchanging GPS data between two devices. The patent’s background section characterizes the prior art as limited to “one way location sharing”—that is, the shar- ing of a location of a first device to a second device, but not from the second device back to the first device. ’647 patent, col. 1, l. 32. The patent, by contrast, is said to provide for two-way location sharing. The specification explains that the claimed invention allows “mutual tracking and op- tional position mapping displays of members of groups and instant buddies.” ’647 patent, col. 2, ll. 36–38. In particu- lar, the patent discloses a “Buddy Watch application” and a “Mapit” method with which a user can track and map other users, and also share the user’s location with other users. The ’647 patent has three independent claims: claims 1, 22, and 28. Claim 1 recites: Case: 19-1165 Document: 46 Page: 3 Filed: 03/03/2020

UBER TECHNOLOGIES, INC. v. X ONE, INC. 3

A method of tracking proximity of position associ- ated with a first wireless device relative to a posi- tion 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 reques- tor 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 asso- ciated with the position associated with the first wireless device and the position of sec- ond wireless device; causing display of the map on the first wireless device with position associated with the first wireless device and the posi- tion of the second wireless device rendered thereon; and causing receipt of information on the first wireless device representing positional up- date of the second wireless device, and causing update of display of the map on the first wireless device with the position asso- ciated with the first wireless device and up- dated position of the second wireless device rendered thereon; wherein the causing of the update is to be performed to indicate proximity of and di- rection 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 Case: 19-1165 Document: 46 Page: 4 Filed: 03/03/2020

request from the requestor for the desired service; and wherein the provider is selected in connec- tion with the request for the desired service and the method further comprises forming a use-specific group to have the first wire- less device and the second wireless device in connection with the request for the de- sired service. ’647 patent, col. 28, l. 50–col. 29, l. 19 (emphasis added). Independent claim 28 is directed to an apparatus and, like claim 1, includes a limitation wherein method steps di- rected to updating a map displayed on a “first wireless de- vice” based on “positional update[s]” from a “second wireless device” are “invoked responsive to launching an application.” ’647 patent, col. 31, l. 37–col. 32, l. 6 (empha- sis added). Independent claim 22 recites: A method of tracking proximity of position associ- ated with a first wireless device relative to position of a second wireless device, wherein the first wire- less device is associated with a requestor of a de- sired 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 de- vice, wherein the second wireless device is associated with the provider and is thereby Case: 19-1165 Document: 46 Page: 5 Filed: 03/03/2020

UBER TECHNOLOGIES, INC. v. X ONE, INC. 5

selected in associated 1 [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 infor- mation representing a map associated with the position associated with the first wire- less 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 posi- tion data provided by the second wireless device, and causing update of display of the map on the first wireless device with re- spective position associated with the first wireless device and positional update de- pendent on the GPS position data provided by the second wireless device rendered thereon; wherein selecting the provider of the de- sired service includes forming a use-spe- cific group to have the first wireless device

1 The word “associated” here appears to be a typo- graphical error. The Board interpreted “associated” as “as- sociation,” J.A. 11, and neither party challenges that interpretation on appeal. Case: 19-1165 Document: 46 Page: 6 Filed: 03/03/2020

and the second wireless device in connec- tion with the request for the desired ser- vice. ‘647 patent, col. 30, l. 47–col. 31, l. 12 (emphasis added). Each independent claim is directed to the idea of dis- playing a map of the positions of a “first wireless device” and a “second wireless device” on the first wireless device, and updating that map based on “positional update[s]” as to the location of the second wireless device. In each claim, a method step is or method steps are in some way tied to the “launch” of an “application.” In claims 1 and 28, a method of updating a displayed map based on positional updates is “invoked responsive to launching an applica- tion.” In claim 22, a “second wireless device” for which lo- cation is to be mapped is selected “in association with an application launched by a requestor.” Uber filed a petition for inter partes review with the Board, challenging claims 1, 4–11, 13, 22–25, 27–28, 31– 37, 39–42, and 45. The petition asserted the obviousness of the independent claims—claims 1, 22, and 28—based on two separate prior art references. The first reference, Jap- anese Unexamined Patent Application Publication 2002- 352388 (“Konishi”), discloses a “vehicle allocation system” in which a “customer” can reserve a vehicle (e.g., a taxi) and view, using a “mobile telephone set 13,” a map of “cus- tomer position” and “vehicle position” as the vehicle ap- proaches the customer. J.A. 1331–34. The second reference, Japanese Unexamined Patent Application Pub- lication 2003–168190 (“Mitsuoka”), discloses a “vehicle dis- patch guidance system” in which a user can use a “portable terminal” to “request[] dispatch of a taxi” and map the “cur- rent location of the user” and “current location of the taxi” as the taxi approaches the user. J.A. 1356–58. Uber also challenged many of the ’647 patent’s dependent claims as obvious, relying on other prior art for some limitations. Case: 19-1165 Document: 46 Page: 7 Filed: 03/03/2020

UBER TECHNOLOGIES, INC. v. X ONE, INC. 7

The Board instituted review, but in its final written de- cision concluded that Uber had failed to show that the in- dependent claims were unpatentable as obvious. The Board construed the “responsive to” limitation present in claims 1 and 28 as requiring the claimed “method” to be invoked “during or near” the time at which the claimed “ap- plication” is launched. J.A. 15. The Board construed the “in association with” limitation present in claim 22 as re- quiring “some relationship” between application launch and method invocation. Id. Applying these constructions, the Board concluded that neither Konishi nor Mitsuoka taught the “responsive to” limitation of claims 1 and 28, or the “in association with” limitation of claim 22. [J.A. 21, 32.] Because the Board concluded that the prior art did not teach the ’647 patent’s independent claims, the Board did not separately analyze the ’647 patent’s dependent claims. Uber appealed. We have jurisdiction pursuant to 28 U.S.C. § 1295(a)(4)(A). DISCUSSION “We review the Board’s factual findings for substantial evidence and review its legal conclusions de novo.” In re Cuozzo Speed Techs., LLC, 793 F.3d 1268, 1280 (Fed. Cir. 2015). We thus review de novo the Board’s interpretations of the patent claims and determinations based on evidence intrinsic to the patent. Williamson v. Citrix Online, LLC, 792 F.3d 1339, 1346 (Fed. Cir. 2015). “If, as here, the IPR stems from a petition filed before November 13, 2018, the claims are given the ‘broadest reasonable interpretation’ consistent with the specification.” Game & Tech. Co. v. Wargaming Grp. Ltd., 942 F.3d 1343, 1351 (Fed. Cir. 2019) (quoting Cuozzo Speed Techs., LLC v. Lee, 136 S. Ct. 2131, 2142 (2016)). Case: 19-1165 Document: 46 Page: 8 Filed: 03/03/2020

I With respect to claims 1 and 28, the Board concluded that neither Konishi nor Mitsuoka teaches that a method “is invoked responsive to launching an application.” J.A. 22, 32. The Board agreed with a district court con- struction of the “responsive to” limitations as “simply plac[ing] a temporal relationship on launching and the other claimed functions.” J.A. 15 (emphasis added) (quot- ing X One, Inc. v. Uber Techs., Inc., No. 5:16-cv-6050-LHK, 2017 WL 3581184, *22 (N.D. Cal. Aug. 18, 2017)). The Board went on to “clarify” that the district court’s construc- tion requires the method to be invoked “during or near” the time at which the application is launched. J.A. 15. The Board further stated that “[t]he required relationship is not shown by simply pointing out that the application was started some point in time prior to the occurrence of the recited activities.” Id. Applying this construction, the Board concluded that neither Konishi nor Mitsuoka discloses the “responsive to” limitations. The Board acknowledged that Konishi dis- closes “an application [that] is running on the mobile device and, thus, [that] the application was launched at some point in time prior to the recited mapping activities.” J.A. 21. The Board similarly found with respect to Mitsuoka “persuasive evidence of a relationship between the running application and the invocation of the method.” J.A. 31 (em- phasis in original). But, for both prior art references, the Board concluded that there was no sufficient “temporal re- lationship” between the launch of the application and the invocation of the method. J.A. 21–22, 31–32. A We first address claim construction. The parties differ as to the correct claim construction. X One appears to ar- gue that the claims require invocation of the method imme- diately upon launch of the application, whereas Uber Case: 19-1165 Document: 46 Page: 9 Filed: 03/03/2020

UBER TECHNOLOGIES, INC. v. X ONE, INC. 9

appears to interpret the claims as requiring only that the method be invoked at some point after launch. We think neither party’s construction is correct and that the Board’s “during or near” requirement is generally correct. At the same time, we agree with Uber that the Board’s claim con- struction is imprecise and that some refinement of the Board’s construction is necessary in light of the specifica- tion. The intrinsic evidence establishes that the “responsive to” limitation is met if the claimed method is invoked minutes or hours after launch of the application. Any nar- rower of a “during or near” requirement would exclude the specification’s preferred embodiment. The specification ex- plains that the mapping method (i.e., “Mapit”) is part of the disclosed Buddy Watch application. 2 That application

2 X One asserts that “Mapit . . . is itself an applica- tion.” Appellee’s Br. 29. Thus, to X One, the specification’s description of Buddy Watch is irrelevant to the construc- tion of “responsive to.” We disagree. The specification makes clear that Buddy Watch corresponds to the claimed “application” and Mapit to the claimed “method.” For ex- ample, the specification repeatedly characterizes Buddy Watch as an “application” or “application program,” and in- stead characterizes Mapit as a “page,” a “screen,” a “com- mand,” or a “function.” See, e.g., ’647 patent, col. 3, l. 67, col. 5, l. 21, col. 6, ll. 30–31, col. 10., l. 50, col. 15, l. 59, col. 16, l. 39. For example, the specification describes the “Mapit page” being launched from within “the Buddy Watch application.” Id., Fig. 2C, col. 6, ll. 29–44. Moreo- ver, the specification describes the “Mapit function” as be- ing “invoked,” mirroring the claims’ recitation of “wherein the method is invoked.” Compare id., col. 15, ll. 59–61 with id., col. 28, l. 50–col. 29, l. 19. A person of ordinary skill reading the specification would therefore understand Case: 19-1165 Document: 46 Page: 10 Filed: 03/03/2020

includes functionality to add buddies and view the location of buddies in a tabular format. A user invokes Mapit to view the location of other users on a map by selecting “Mapit” on the Buddy Watch’s “start-up screen.” See ’647 patent, col. 6, ll. 29–44. The specification places no re- striction on when, after launching Buddy Watch, the user may select the “Mapit” application. But the specification discloses several features demonstrating that Mapit may be invoked minutes or hours after launching Buddy Watch. The specification notes, for instance, that a user can open the Buddy Watch application in order to start sharing the user’s location without immediately invoking Mapit. See ’647 patent, Fig. 1. As an example, the specification describes each member of a tennis team sharing his or her location with the other team members. See ’647 patent, col. 15, ll. 15–25, 39–65. Team members may be in “active sta- tus”—that is, have the Buddy Watch application launched and transmitting location data—even before the Mapit method is practiced. See ’647 patent, Fig. 1, col. 7, ll. 24– 26, col. 15, ll. 18–20. A team member may, therefore, have launched Buddy Watch (for the purpose of sharing his or her location) and, minutes or hours later, invoke Mapit (to see the other team members’ locations). The specification further notes that in “the preferred embodiment for the instant buddy setup process,” several steps need to occur after a user launches the Buddy Watch application before the user can map the position of an “in- stant buddy.” These include: (1) an “initiator” user “select- ing the instant buddy setup process”; (2) “fill[ing] in a timeout period” for the instant buddy relationship; (3) rout- ing “instant buddy packets” to the “Buddy Watch[] server”; (4) “authenticat[ing] the initiator”; (5) sending a message

Mapit to be a method invoked as part of the Buddy Watch application. Case: 19-1165 Document: 46 Page: 11 Filed: 03/03/2020

UBER TECHNOLOGIES, INC. v. X ONE, INC. 11

to the “proposed instant buddy”; (6) the proposed instant buddy “accepting or denying the relationship”; (7) “if ac- cepted,” sending a “packet . . . back to the initiator[]”; (8) displaying “an [i]nstant [b]uddy accept screen . . . which the initiator must OK to establish the relationship”; (9) “record[ing],” at the Buddy Watch server, “the new instant buddy relationship”; and, finally, (10) “verifying” the “col- lect[ion of] GPS data.” ’647 patent, Fig. 22, col. 14, l. 54 to col. 15, l. 13. Thus, a user that launched the Buddy Watch application to map an instant buddy might only invoke the Mapit method minutes or hours later, once the instant buddy setup process has completed. In sum, the specification contemplates scenarios in which there are minutes or hours between the launch of Buddy Watch and the invocation of Mapit. In light of this disclosure, the Board’s “during or near” requirement must allow for method invocation minutes or hours after appli- cation launch. A contrary interpretation would exclude embodiments of the invention. “A ‘claim construction that does not encompass a disclosed embodiment is rarely, if ever, correct.’” Medrad, Inc. v. MRI Devices Corp., 401 F.3d 1313, 1320 (Fed. Cir. 2005) (quoting Johns Hopkins Univ. v. CellPro, 152 F.3d 1342, 1355 (Fed. Cir. 1998)) (alteration omitted). The “responsive to” limitations in claims 1 and 28 are met if “the method is invoked” within minutes or hours of “launching an application.” B Under this construction, the Board erred in concluding that Konishi and Mitsuoka do not teach or suggest the “re- sponsive to” limitations. 1 Konishi “relates to a vehicle allocation system for allo- cating commercial vehicles such as taxis or cargo collection Case: 19-1165 Document: 46 Page: 12 Filed: 03/03/2020

and delivery vehicles based on customer reservations.” J.A. 1331. In Konishi, a user carries a “mobile telephone set 13” with a “built-in GPS system.” J.A. 1334. To reserve a vehicle, the user “selects a vehicle allocation service with the mobile telephone set 13.” Id. The “mobile telephone set 13” then sends the position of the phone to an “infor- mation processing device 11” via a “computer 20.” Id. The information processing device 11 retrieves any vacant ve- hicles located “within a prescribed range from the current position of the mobile telephone set 13” from a “vehicle monitoring system 24.” Id. If there are vacant vehicles in range, “the information processing device 11 reads out a map of a region of a specific range with the customer posi- tion in the center from the map system 28,” “inputs the cus- tomer position and the current position of the retrieved vacant vehicle,” “transmits the information to the mobile telephone set 13,” and “displays the information on the [mobile telephone set’s] screen 25.” Id. The customer may then “make a reservation,” which the driver of the reserved vehicle can accept. J.A. 1334–35. At this point, “[t]he cur- rent position of the reserved vehicle, which approaches mo- ment by moment, is displayed on the map together with the customer position,” “transmitted to the mobile telephone set 13,” and “displayed as a navigation display.” J.A. 1335. The mapping terminates once the user indicates that he or she has entered the reserved vehicle. Konishi’s disclosure exactly parallels the ’647 patent’s claims. The “application” is Konishi’s vehicle allocation service. The “launching” of the “application” is when in Konishi the user selects a vehicle allocation service with the mobile telephone set 13. The “method” of Konishi is the display of a map with the position of a reserved vehicle up- dated “moment by moment” as it approaches the user. The very purpose of Konishi is to start mapping shortly after the launch of the vehicle allocation service. Konishi notes that, in the prior art, “because the customer is Case: 19-1165 Document: 46 Page: 13 Filed: 03/03/2020

UBER TECHNOLOGIES, INC. v. X ONE, INC. 13

unaware of the current position of a reserved vehicle, the customer is uneasy about whether the reserved vehicle will arrive in the promised time.” J.A. 1332. Konishi also notes that, in the prior art, “because the person in charge [of ve- hicle allocation] talks with the customer by telephone, the method requires the response time of the person in charge.” Id. The purpose of Konishi is, therefore, to quickly reserve a vehicle and display the location of that vehicle on a map as it arrives. Thus, a user in Konishi typically will reserve a vehicle within minutes after launching the vehicle allo- cation service. Konishi’s mapping “method” is “invoked” when a vehicle is reserved. Accordingly, Konishi teaches the “responsive to” limitations of claims 1 and 28. To be sure, Konishi does not place a strict time constraint on when, after launching the vehicle allocation service, a user may reserve a vehicle. But neither does the ’647 patent impose a strict time constraint between launching Buddy Watch and invoking the MapIt method. Konishi discloses the “responsive to” limitations. Be- cause X One did not argue before the Board that any other limitations of claims 1 or 28 were not disclosed by Konishi, we conclude that those claims would have been obvious in light of Konishi. 2 Mitsuoka, is directed to a system in which users re- serve taxis and view taxi positions on a map. In Mitsuoka, a user can “request[] dispatch of a taxi 3,” by “mak[ing] a dial-up connection to [Application Service Provider (“ASP”)] 4 from the user’s portable terminal 1.” J.A. 1356. At “ASP 4, the maps in map [database (“DB”)] 15 are searched based on the location information for portable ter- minal 1 . . . and a map of the vicinity of the current location of portable terminal 1 is extracted.” Id. “An image repre- senting the user . . . is then . . . added at the location of portable terminal 1 on the extracted map.” Id. Similarly, Case: 19-1165 Document: 46 Page: 14 Filed: 03/03/2020

“location information for taxis 3, which is transmitted from taxis 3, is constantly received in ASP 4.” Id. “[I]f the re- ceived location of an available taxi is within the map ex- tracted from map DB 15, a taxi image . . . is added at the location of the available taxi on the extracted map.” Id. The ASP 4 then “transmits . . . the map data . . . to portable terminal 1.” J.A. 1357. The user can then request, for ex- ample, “taxi 3A,” and “this selection information is trans- mitted to ASP 4.” Id. As taxi 3A travels to the user, “the ASP 4 receives . . . location information successively trans- mitted from taxi 3A, adds an image of the taxi to the corre- sponding location on the vicinity map, and delivers this display data in real time to the portable terminal 1, as a result of which, the status of the requested taxi heading to [the user’s] own current location is displayed in real time along with a map of the vicinity on the display unit of the portable terminal 1.” Id. Mitsuoka’s disclosure exactly parallels the ’647 pa- tent’s claims. The process in Mitsuoka’s portable user ter- minal that makes a dial-up connection to the ASP 4 is, as the Board found, an “application.” Making the dial-up con- nection is, therefore, “launching” the application. The mapping “method” of Mitsuoka displays the real-time loca- tion of a requested taxi on a map as the taxi heads to the user’s location. This “method” is “invoked” when the user requests the taxi. In Mitsuoka (as in Konishi), the user will typically invoke the “method” (i.e., request the taxi) within minutes of when the connection between the user terminal and the ASP is made. It is true that Mitsuoka’s disclosure does not specify a strict time limit between connecting to the ASP (i.e., the “launch” of the “application”) and requesting a taxi (i.e., the “invok[ing]” of the “method”). But neither does the ’647 pa- tent impose a strict time limit between launching Buddy Watch and invoking the MapIt method. Mitsuoka teaches the “responsive to” limitations of claims 1 and 28. Case: 19-1165 Document: 46 Page: 15 Filed: 03/03/2020

UBER TECHNOLOGIES, INC. v. X ONE, INC. 15

Because X One did not argue before the Board that any other limitations of claims 1 or 28 were not disclosed by Mitsuoka, we conclude that those claims would have been obvious in light of Mitsuoka. II The Board concluded that neither Konishi nor Mitsuoka renders obvious claim 22’s limitation that a “sec- ond wireless device” (whose location is to be mapped) is “se- lected in association with launch of the application.” J.A. 22–23, 32–33 (emphasis added). The Board adopted the district court’s construction of the “in association with” lan- guage, which stated that “‘[r]esponsive to launching’ simply places a temporal relationship on launching and the other claimed functions: they happen in response to launching. ‘In association with an application launched’ is broader, and just requires some relationship between launching and the claimed functions.” J.A. 15 (quoting X One, 2017 WL 3581184, at *22) (alteration in original) (em- phasis added). We agree with the Board that the “in association with” limitation is “broader” than the “responsive to” limitation. J.A. 15. As we have explained, both Konishi and Mitsuoka disclose the “responsive to” limitation. It follows, then, that Konishi and Mitsuoka disclose the “in association with” limitation. Specifically, Konishi’s selection of a vehi- cle to be reserved (i.e., the claimed “select[ion]”) occurs af- ter and as a result of (i.e., “in association with”) the selection of the vehicle allocation service (i.e., the “the launch of the application”). Mitsuoka’s request for a taxi (i.e., the claimed “select[ion]”) occurs after and as a result of (i.e., “in association with”) the portable user terminal’s connection to the ASP (i.e., “the launch of the application”). Konishi and Mitsuoka thus teach claim 22’s “in association with” limitation. Case: 19-1165 Document: 46 Page: 16 Filed: 03/03/2020

X One did not argue before the Board that any other limitation of claim 22 rendered it patentable over the prior art. Thus, we conclude that claim 22 would have been ob- vious in light of Konishi and, independently, in light of Mitsuoka. CONCLUSION We reverse the Board’s determination of non-obvious- ness as to the ’647 patent’s independent claims (claims 1, 22, and 28), vacate the Board’s determination of non-obvi- ousness as to the dependent claims (claims 4, 5–11, 13, 23– 25, 27, 31–37, 39–42, and 45), and remand the case to the Board to separately consider the patentability of the de- pendent claims. REVERSED-IN-PART, VACATED-IN-PART, AND REMANDED COSTS No costs.