Google LLC

Patent Trials and Appeals Board

Dec 3, 2021

2020006009 (P.T.A.B. Dec. 3, 2021)

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