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




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




                   ______________________

     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




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




         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




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




         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




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




                               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




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




 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




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




 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




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




 “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




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




     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.
