Google LLCDownload PDFPatent Trials and Appeals BoardDec 3, 20212020006009 (P.T.A.B. Dec. 3, 2021) Copy Citation UNITED STATES PATENT AND TRADEMARK OFFICE UNITED STATES DEPARTMENT OF COMMERCE United States Patent and Trademark Office Address: COMMISSIONER FOR PATENTS P.O. Box 1450 Alexandria, Virginia 22313-1450 www.uspto.gov APPLICATION NO. FILING DATE FIRST NAMED INVENTOR ATTORNEY DOCKET NO. CONFIRMATION NO. 16/053,409 08/02/2018 Nikhil Bakshi 16113-7834004 9163 26192 7590 12/03/2021 FISH & RICHARDSON P.C. PO BOX 1022 MINNEAPOLIS, MN 55440-1022 EXAMINER LANIER, BENJAMIN E ART UNIT PAPER NUMBER 2437 NOTIFICATION DATE DELIVERY MODE 12/03/2021 ELECTRONIC Please find below and/or attached an Office communication concerning this application or proceeding. The time period for reply, if any, is set in the attached communication. Notice of the Office communication was sent electronically on above-indicated "Notification Date" to the following e-mail address(es): PATDOCTC@fr.com PTOL-90A (Rev. 04/07) UNITED STATES PATENT AND TRADEMARK OFFICE ____________________ BEFORE THE PATENT TRIAL AND APPEAL BOARD ____________________ Ex parte NIKHIL BAKSHI, OLIVER MICHAEL KING, DOOYUM JEREMIAH MALU, and TOMMASO FRANCESCO BERSANO BEGEY ____________________ Appeal 2020-006009 Application 16/053,409 Technology Center 2400 ____________________ Before JOSEPH L. DIXON, DAVID M. KOHUT, and JON M. JURGOVAN, Administrative Patent Judges. JURGOVAN, Administrative Patent Judge. DECISION ON APPEAL Appellant1 seeks review under 35 U.S.C. § 134(a) from a final rejection of claims 1, 3–8, 10–15, and 17–20. We have jurisdiction under 35 U.S.C. § 6(b). We AFFIRM.2 1 We use the word “Appellant” to refer to “applicant” as defined in 37 C.F.R. § 1.42. The real party in interest is Google LLC. (Appeal Br. 1.) 2 Our Decision refers to the Specification (“Spec.”) filed August 2, 2018, Final Office Action (“Final Act.”) mailed January 15, 2020, Appeal Brief (“Appeal Br.”) filed May 28, 2020, Examiner’s Answer (“Ans.”) mailed June 30, 2020, and Reply Brief (“Reply Br.”) filed August 20, 2020. Appeal 2020-006009 Application 16/053,409 2 CLAIMED INVENTION The claims are directed to a method and system for “reducing latency in network communications and in data presentation” by “pre-caching, at the user’s device, data that the user is likely to request but has not yet requested,” thereby “allow[ing] the client device to present the requested data quicker as the client device does not have to wait for a request to traverse the network, the server to identify the requested data, and the requested data to make its way to the client device.” (Spec. 1:19–20, 3:15–30.) Independent claim 1, reproduced below, is illustrative of the claimed subject matter: 1. A method performed by data processing apparatus, the method comprising: generating, by the data processing apparatus and for presentation on a client device during a same user session initiated by a particular user, a visualization of an initial dashboard user interface that includes multiple different display cards that provide different reports for a given online account for presentation to the particular user during the same user session, wherein the multiple different display cards present different types of data in a same user interface; selecting, by the data processing apparatus, a set of data for a different display card that is not included in the initial dashboard user interface; and reducing latency for presenting an updated dashboard user interface at the client device during the same user session in which the initial dashboard user interface is displayed at the client device for presentation to the particular user during the same user session by pre-caching, at the client device, the set of data for the different display card that is not included in the initial dashboard, wherein the pre-caching is performed prior to a request from the client device to present the different display card Appeal 2020-006009 Application 16/053,409 3 and while the initial dashboard user interface is displayed at the client device during the same user session; detecting, during the same user session, a trigger to update the pre-cached set of data for the different display card; determining, in response to detecting the trigger and during the same user session, whether to update the pre-cached set of data for the different display card, including: updating the pre-cached set of data for the different display card when an analysis indicates that the pre-cached set of data should be updated; and waiting for another trigger before updating the pre- cached set of data for the different display card when the analysis indicates that the pre-cached set of data should not be updated. (Appeal Br. 15–20 (Claims App.).) REJECTIONS3 & REFERENCES Claims 1, 3–8, 10–15, and 17–20 stand rejected under 35 U.S.C. § 103 based on Ullrich (US 2016/0142497 A1, published May 19, 2016) (“Ullrich”) and Preiss et al. (US 2012/0173257 A1, published July 5, 2012) (“Preiss”). (Final Act. 10–15.) 3 Claims 1, 2, 5–9, 12–16, 19, and 20 were rejected on the ground of nonstatutory double patenting as being unpatentable over claims 1–20 of US 10,075,449, and claims 3, 4, 10, 11, 17, and 18 were rejected on the ground of nonstatutory double patenting as being unpatentable over claims 1–20 of US 10,075,449 in view of Ullrich (US 2016/0142497 A1). (See Final Act. 4–9.) However, these rejections have been withdrawn by the Examiner, in light of the filing of a terminal disclaimer, and thus, are not before us for review as part of the instant appeal. (Ans. 4.) After the Examiner’s withdrawal of the double patenting rejections, it appears that claims 2, 9, and 16 are not presently subject to any rejection. Appeal 2020-006009 Application 16/053,409 4 ANALYSIS Appellant has the burden on appeal to the Board to demonstrate error in the Examiner’s position. See In re Kahn, 441 F.3d 977, 985–86 (Fed. Cir. 2006). We review the appealed rejection for error based upon the issues identified by Appellant and in light of the arguments and evidence produced thereon. Ex parte Frye, 94 USPQ2d 1072, 1075 (BPAI 2010) (precedential), (cited with approval in In re Jung, 637 F.3d 1356, 1365 (Fed. Cir. 2011) (“[I]t has long been the Board’s practice to require an applicant to identify the alleged error in the examiner’s rejections.”)). After considering the evidence presented in this Appeal and each of Appellant’s arguments, we are not persuaded that Appellant identifies reversible error. Thus, we affirm the Examiner’s § 103 rejection for the reasons expressed in the Final Office Action and the Answer. We add the following primarily for emphasis. With respect to the Examiner’s rejection of claim 1, Appellant argues Ullrich and Preiss, alone or in combination, do not teach or suggest “selecting and pre-caching a set of data for a different display card that is not included in the initial dashboard while the initial dashboard is displayed at the client device” and “detecting a trigger to update the pre- cached set of data for the different display card,” as claimed. (Appeal Br. 6, 10; Reply Br. 2–4.) In particular, Appellant argues Ullrich’s creation and delivery of a virtual desktop is “merely referring to presenting the last logged state of the user session rather than looking forward to pre-caching data that is not part of the current user session.” (Appeal Br. 7–8 (citing Ullrich ¶¶ 35–36, 40).) With respect to Preiss, Appellant argues that the “relied upon portions of Preiss merely refer to having patient information Appeal 2020-006009 Application 16/053,409 5 pre-loaded when a Dr. enters a patient’s room, and using the geolocation of the Dr. to determine when the Dr. is entering the patient’s room,” whereby: the entirety of the data (e.g., all of the patient’s information and images) is preloaded with all necessary information to perform the surgery. In other words, according to Preiss, all of the information is provided to the workstation 820 at the same time, e.g., when the location device enters the operating room and initiates the user session. This feature of Preiss is specifically in contradiction to the claimed feature of: “selecting a set of data for a different display card that is not included in the initial dashboard user interface and . . . during the same user session . . . pre-caching, at the client device, the set of data [for the different display card] . . . while the initial dashboard user interface is displayed at the client device during the same user session.” While the claims recite the initial presentation of “multiple different display cards [that] present different types of data” and then the selecting and pre-caching of a “set of data for a different display card,” Preiss merely describes a single action in which all necessary information is provided to the workstation so that it will be available when the Dr. arrives. (Appeal Br. 7, 9–10 (citing Preiss ¶¶ 33, 41–43, Fig. 8); see also Reply Br. 2–3.) Appellant further argues Preiss “fail[s] to suggest trigger detection” and “merely refer[s] to hiding presentation of a patient’s sensitive information when non-medical staff enter the room, and launching a collaborative application when other doctors enter a room already occupied by a doctor.” (Appeal Br. 10 (citing Preiss ¶¶ 42, 44).) Appellant asserts that Preiss merely describes “providing additional medi[c]al information when medi[c]al staff enters the room” and “loading additional/new data for the new users [(medical staff)] who have entered the room,” which does not teach or suggest a “trigger to update the pre-cached set of data for the different display card [that is not displayed in the initial dashboard]” and Appeal 2020-006009 Application 16/053,409 6 does not provide “an update (e.g., a refresh) of the already pre-cached data that was ‘pre-loaded’ for the ‘doctor 910 [the user].’” (Appeal Br. 11, 13; Reply Br. 4 (citing Preiss ¶ 44).) We are not persuaded by Appellant’s arguments. Instead, we agree with the Examiner that the asserted combination of references teaches and suggests the claimed method of “reducing latency . . . by pre-caching,” “detecting . . . a trigger to update the pre-cached set of data,” and “determining, in response to detecting the trigger and during the same user session, whether to update the pre-cached set of data,” as recited in claim 1. At the outset, we note Appellant has submitted arguments that are not supported by corresponding language in claim 1. For example, Appellant argues “the art does not suggest the claimed pre-caching” because “[t]he claims are referring to pre-caching data that might be needed next as the user is viewing other data during the user session, while the art is specifically directed to downloading all available information when it is available.” (See Reply Br. 2.) However, the pre-caching recited in claim 1 (i) does not require pre-caching only “data that might be needed next” and (ii) does not preclude “downloading all available information when it is available” (as Appellant argues, see id. (emphases added)). Instead, claim 1 recites pre- caching “data for the different display card that is not included in the initial dashboard.” (See Appeal Br. 15 (claim 1) (emphasis added).) In addition, Appellant’s Specification does not differentiate pre-caching data (that is “performed prior to a request from the client device to present the different display card,” as claimed) from downloading the same kind of data (i.e., data that has not yet been expressly requested by the client device). Rather, Appellant’s Specification appears to indicate that pre-caching can be Appeal 2020-006009 Application 16/053,409 7 performed by anticipative downloading from a remote location (e.g., from “one or more servers located in one or more data centers”). (See Spec. 7:26– 29, and 9:13–15 and 15:25–30 (describing a second dataset, which can be pre-cached using a data center’s “pre-caching engine 223 [that] can send the second dataset to the client device. . . . [which] can store the second dataset in a high-speed cache 264” that “includes high-speed memory devices that store account data”), Fig. 2.) In light of the broad “pre-caching” recited in claim 1, we agree with the Examiner that: Preiss discloses preloading medical data ([0032]) such as images associated with a patient’s surgery at a specific workstation that is displaying other data associated with the same patient ([0043]). . . . Paragraph [0043] [in Preiss] provides an example where “images associated with the surgery” are preloaded to the device. Going back to paragraph [0032], these “images associated with the surgery” would represent the data predicted to be next likely needed and are therefore, preloaded/cached while other data is being displayed. Additionally, paragraph [0043] of Preiss specifically states that the workstation prepares an application to display information about the procedure to be performed on the patient along with all of the patient’s information such as name, date of birth, height, weight, etc. Therefore, paragraph [0043] clearly states that this information is displayed, while the “images associated with the surgery” are simply “preloaded” to the workstation. (Ans. 6–8 (emphasis added) (citing Preiss ¶¶ 32, 43).) Appellant disagrees with the Examiner’s assessment for the reasons that “Preiss is clearly referring to pre-loading data at the workstation before the doctor arrives (before the user session is initiated)” such that “all of the information is provided to the workstation 820 at the same time, e.g., when Appeal 2020-006009 Application 16/053,409 8 the location device enters the operating room,” and “Preiss fails to teach pre- caching data that might be needed next as the user is viewing other data during the user session.” (Reply Br. 2–3 (citing Preiss ¶¶ 31–33, 43); Appeal Br. 9–10 (citing Preiss ¶¶ 33, 41–43, Fig. 8).) Appellant’s arguments are unpersuasive for the following reasons. First, the “user session” recited in claim 1 is broad and does not preclude an extended collaborative session (such as that disclosed by Preiss, see ¶ 44) at a workstation being used by multiple doctors (e.g., of a surgical team, see id.) operating on a patient. (See Preiss ¶¶ 23, 38, 43–44, 48; Ans. 10–13; Final Act. 12–13.) Claim 1 also does not provide details as to how the recited “user session” is “initiated,” and the claim does not preclude multiple users (e.g., doctors in a surgical team) from participating (e.g., accessing preloaded data specific to each doctor, such as the doctor’s notes, see Preiss ¶¶ 32, 38, 48) in the claimed “user session initiated by a particular user.” (Ans. 10–15; Final Act. 12.) Thus, Appellant’s argument that Preiss merely discloses “pre-loading data at the workstation before the doctor arrives (before the user session is initiated)” is unpersuasive. (See Reply Br. 2.) Second, Preiss’ paragraph 38 discloses the location-based clinical information retrieval system “can . . . as the doctor 310 approaches a patient’s room 320, update equipment in the room 320 to launch appropriate application(s), preload applicable patient(s)” such that “if the doctor 310 is a radiologist, an imaging application is loaded along with recent imaging exam(s) for the given patient” and “if the doctor 310 is a surgeon, an application detailing the patient’s upcoming and/or recent surgery is loaded.” (See Preiss ¶ 38 (emphases added); Ans. 14 (citing Preiss ¶ 38).) Appeal 2020-006009 Application 16/053,409 9 Further, Preiss’ paragraph 43 provides that when a patient with a geolocation device enters the operating room, the location service preloads the workstation 820 in the, for example, operating room 830 with the patient’s information and appropriate application(s) for surgery. For example, the workstation 820 prepares a RIS [(radiology information system)] application to display information about the procedure to be performed on the patient 810 along with all of the patient’s information such as name, date of birth, height, weight, etc. If there are images associated with the surgery, the imaging workstation 820 is also preloaded with the image(s). (See Preiss ¶ 43; see also Ans. 7–8, 9, 11 (citing Preiss ¶ 43).) Thus, Preiss discloses that “appropriate application(s)” are launched, loaded, and prepared for a medical (e.g., surgical) team (see Preiss ¶¶ 38, 43 (emphases added)), thereby teaching that a “user session” has been initiated, as claimed. (Ans. 6–8; Final Act. 3, 12.) Upon launching the “appropriate application(s),” Preiss’ information retrieval system “preload[s] applicable patient(s), and configure[s] setting(s) based on one or more rules, preferences, setting, etc., associated with the doctor 310, patient, room” and “prepares a RIS application to display information about the procedure to be performed on the patient 810 along with all of the patient’s information such as name, date of birth, height, weight, etc.” (See Preiss ¶¶ 38, 43; see also Ans. 5–8, 14 (citing Preiss ¶¶ 32, 38, 43).) As the Examiner finds, this disclosure in Preiss teaches an “initial dashboard user interface” displayed at a client device (workstation), as claimed. (Final Act. 3, 12; Ans. 7–8.) Preiss’ paragraph 43 further specifies that “[i]f there are images associated with the surgery, the imaging workstation 820 is also preloaded with the image(s)”—which (as the Examiner finds) teaches that “‘images associated Appeal 2020-006009 Application 16/053,409 10 with the surgery’ would represent the data predicted to be next likely needed and are therefore, preloaded/cached while other data [(information about the procedure to be performed on the patient along with all of the patient’s information such as name, date of birth, height, weight)] is being displayed.” (Ans. 7–8 (citing Preiss ¶ 43).) We therefore remain unpersuaded by Appellant’s arguments that Preiss merely discloses “pre-loading data at the workstation before the doctor arrives (before the user session is initiated),” or that “Preiss fails to teach pre-caching data that might be needed next as the user is viewing other data during the user session.” (See Reply Br. 2–3). The Examiner’s rejection also provides additional evidence and technical reasoning that reasonably support a determination that the combination of Preiss and Ullrich teaches the claimed pre-caching—i.e., pre-caching that reduces latency by being “performed prior to a request from the client device to present the different display card and while the initial dashboard user interface is displayed at the client device during the same user session,” as claimed. (See Ans. 6–7, 9; Final Act. 12–13.) In particular, the Examiner reasons a skilled artisan would recognize that patient data could be advantageously delivered to Preiss’ workstation as soon as the data is available, as Ullrich discloses that real-time patient data can be delivered to a “virtual desktop . . . created as soon as the individual’s [(e.g., surgeon’s)] presence within a facility is detected . . . or when s/he is detected . . . near a particular location within the facility.” (See Ullrich ¶ 38; see also id. ¶¶ 35 (“For example, retrieved data may include documents opened in a word processor, patient records accessed via an EMR system, lab reports, real-time patient data obtained remotely from a medical device, etc.”), 40, 42; Ans. 5–9.) As the Examiner notes, delivery of patient data as soon as the Appeal 2020-006009 Application 16/053,409 11 data is available would support Preiss’ goal of initiating a download of the “next likely data needed by a user for a patient . . . earlier in time, thereby providing those few extra minutes which are often so crucial in an emergency care situation, for example.” (See Preiss ¶¶ 19, 32; Ans. 6–9 (citing Preiss ¶ 32).) More particularly, the Examiner finds: Ullrich discloses that the user’s virtual desktop can be updated with information that includes “real-time patient data” ([0035]). While, updating the virtual desktop suggests information that is actively retrieved and cached without specific requests, Ullrich does not explicitly disclose that some patient data is displayed while another portion of the retrieved patient data is cached for future display. Preiss discloses preloading medical data ([0032]) such as images associated with a patient’s surgery at a specific workstation that is displaying other data associated with the same patient ([0043]). . . . [R]eal-time patient data would not necessarily be available at the same time the initial patient data is provided to the workstation. Instead, the combined teachings of Ullrich and Preiss, as outlined in the Final, allow for the preloading of real-time patient data that eliminates the need for a care provider to manually request needed patient data thereby reducing the amount of time required for care providers to view patient data as suggested by Preiss ([0043]). (Ans. 9.) Appellant’s arguments do not substantively address the Examiner’s asserted combination of Preiss and Ullrich. (See Reply Br. 2–4.) For example, Appellant’s argument that “[e]ven in combination with the ‘virtual nodes’ of Ulrich, Preiss fails to teach pre-caching data that might be needed next as the user is viewing other data during the user session” (see Reply Br. 2–3) does not sufficiently explain why the Examiner’s asserted combination of Preiss and Ullrich (discussed supra) would be deficient. We are also not persuaded by Appellant’s arguments that Preiss fails to teach or suggest “trigger detection” and “trigger to update the pre-cached Appeal 2020-006009 Application 16/053,409 12 set of data for the different display card [that is not displayed in the initial dashboard].” (Appeal Br. 10, 13; Reply Br. 4.) For example, Appellant argues “Preiss is describing loading additional/new data for the new users who have entered the room and not, as claimed, ‘updating [in response to the trigger] the [data that has been previously] pre-cached . . . for the different display card.’” (See Reply Br. 4; see also id. at 3 (“the relied upon portions of Preiss are referring to loading new information for a different doctor rather than updating the already pre-cached data that was already preloaded for the doctor that was already in the room”).) Appellant’s arguments are unpersuasive because the claimed “updating the pre-cached set of data for the different display card” does not require “a refresh[] of the already pre-cached data,” and does not preclude loading “additional/new data” (as Appellant argues, see Reply Br. 3–4). The Examiner has identified an update of a pre-cached set of data as including medical information specific to/usable by an additional doctor joining the patient’s surgical procedure, as described by Preiss (see Ans. 12–15 and Preiss ¶¶ 44, 48). That is, the claimed update of a pre-cached set of data identified by the Examiner in Preiss includes an update to the medical information pertaining to the same medical procedure (e.g., a patient’s surgery), the update “allow[ing] the doctors 910, 920 to view patient information for an upcoming or ongoing surgery and/or other procedure in a more collaborative way.” (See Preiss ¶ 44; Ans. 14–15.) We find the Examiner’s conclusions reasonable because the claimed “updating the pre- cached set of data for the different display card” is broad and does not preclude an addition of new data pertaining to the same subject (e.g., a particular surgical procedure). Moreover, Appellant’s Specification does not Appeal 2020-006009 Application 16/053,409 13 provide an explicit and exclusive definition of the claimed term “updating the pre-cached set of data”; instead, the Specification provides discussion of non-limiting examples of such “updating.” (See Spec. 3:9–13, 23:22–24:2 (describing options for updating old data, or updating data when “data stored in the cache has changed from the value stored in the cache,” updating data when “a number of data items . . . have changed since the data was transmitted to the client device for storage in the cache,” and updating data based on “a user modification to account data”).) Appellant also argues that pre-loading medical information specific to the doctors that join a patient’s surgical procedure (as described by Preiss, see ¶ 44) does not meet the claimed “updating” because: this portion of Preiss specifically describes launching a new application environment: “a doctor 910 is in a room 940 using a workstation 930 that has been previously configured for her [the user’s] usage, with correct patient data and application(s) loaded. One or more additional doctors and/or medical staff 920 enter the room 940 (e.g., an operating room), each with a geolocation device. A location service configures the workstation 930 in the room 940 with a [new user session] collaboration application,” (Preiss [0044]), which is a different application, and thus cannot teach to the actions of the claim that occur during a “same user session initiated by a particular user.” (Reply Br. 4 (emphases added).) Appellant’s argument is unpersuasive because, as discussed supra, claim 1’s “user session” is broad and does not preclude a collaborative session (such as that disclosed by Preiss, see ¶ 44). (Ans. 10, 12.) Claim 1 also does not preclude multiple applications from being part of the “user session,” and does not preclude multiple users (e.g., doctors of a surgical team) from participating in the claimed “user session initiated by a particular user.” Appeal 2020-006009 Application 16/053,409 14 As to Appellant’s argument that Preiss fails to teach or suggest “trigger detection” as claimed (see Appeal Br. 10), the Examiner has made reasonable findings that Preiss discloses the limitation. (See Ans. 10, 13– 15.) For example, the Examiner finds: when Preiss discloses that one or more additional doctors and/or medical staff enter the room ([0044]), that detection of additional doctors/medical staff is the equivalent to the claimed “triggering.” . . . This detection of an additional doctor/medical staff would then trigger the loading of additional medical information to the workstation 930 that is specific to that the new doctor/medical staff that has just entered the room (Preiss: [0044]), and that information can include medical information such as the doctor’s notes (Preiss: [0048]). Therefore, the Preiss reference can be said to reasonably show triggering an update to the precached set of data as claimed because when the new doctors/medical staff are detected the medical information that was already stored on the workstation, and includes the pre-cached data as explained above, is updated with new medical information that is specific to the new doctor/medical staff that just entered the room. (Ans. 13–15 (emphases added).) Appellant’s support for the contention that Preiss does not teach or suggest “trigger detection” (see Appeal Br. 10) relies upon Appellant’s arguments already discussed supra (such as the argument that “providing additional med[c]ial information when med[c]ial staff enters the room is merely referring to providing new information, rather than updating already pre-cached information,” see Appeal Br. 11–13.) As discussed supra, we are not persuaded that the claimed triggered update precludes an addition of new data pertaining to the same subject (e.g., a patient’s surgical procedure). For the same reasons, we are not persuaded that the claimed “detecting . . . a trigger to update” would preclude detection Appeal 2020-006009 Application 16/053,409 15 of additional data that pertains to the same subject/medical procedure (as asserted by the Examiner, see Ans. 11–15). As Appellant’s arguments have not persuaded us of error in the Examiner’s rejection of claim 1, we sustain the Examiner’s § 103 rejection of claim 1, independent claims 8 and 15 argued for the same reasons, and dependent claims 3–7, 10–14, and 17–20, argued for their dependency. (See Appeal Br. 10, 13.) DECISION SUMMARY The Examiner’s rejection of claims 1, 3–8, 10–15, and 17–20 under 35 U.S.C. § 103 is AFFIRMED. In summary: Claims Rejected 35 U.S.C. § Reference(s)/ Basis Affirmed Reversed 1, 3–8, 10– 15, 17–20 103 Ullrich, Preiss 1, 3–8, 10– 15, 17–20 No time period for taking any subsequent action in connection with this appeal may be extended under 37 C.F.R. § 1.136(a). See 37 C.F.R. § 1.136(a)(1)(iv). AFFIRMED Copy with citationCopy as parenthetical citation