null

Patent Trials and Appeals Board

Dec 2, 2019

15075696 - (D) (P.T.A.B. Dec. 2, 2019)

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.
15/075,696 03/21/2016 Guy Roetcisoender 2015P07106US 7323
45113 7590 12/02/2019
Siemens Corporation
Intellectual Property Department
3501 Quadrangle Blvd Ste 230
Orlando, FL 32817
EXAMINER
TSWEI, YU-JANG
ART UNIT PAPER NUMBER
2619
NOTIFICATION DATE DELIVERY MODE
12/02/2019 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):
IPDadmin.us@siemens.com
PTOL-90A (Rev. 04/07)
UNITED STATES PATENT AND TRADEMARK OFFICE
BEFORE THE PATENT TRIAL AND APPEAL BOARD
Ex parte GUY ROETCISOENDER,
ANDREAS HUGO WALTER JOHANNSEN, MICHAEL B. CARTER,
JAVEED NIZAMI, ERIK ANDERS SJOBLOM, JIANBING HUANG,
and BALAJI VENKATASUBRAMANIAM
Appeal 2019-001004
Application 15/075,696
Technology Center 2600
Before KARL D. EASTHOM, AMBER L. HAGY, and
KARA L. SZPONDOWSKI, Administrative Patent Judges.
EASTHOM, Administrative Patent Judge.
DECISION ON APPEAL
STATEMENT OF THE CASE
Pursuant to 35 U.S.C. § 134(a), Appellant1 appeals from the
Examiner’s Final Office Action rejecting all pending claims, claims 1, 2, 4–
9, 11–16, and 18–20. Final Act. 1; Appeal Br. 1. We have jurisdiction under
35 U.S.C. § 6(b).
We AFFIRM IN PART.

1 “Appellant” refers to “applicant” as defined in 37 C.F.R. § 1.42(a).
Appellant identifies the real party in interest as Siemens Product
Lifecycle Management Software Inc. Appeal Br. 4.
Appeal 2019-001004
Application 15/075,696

2
CLAIMED AND DISCLOSED SUBJECT MATTER
The Specification describes three-dimensional (3D) computer
modeling and visualization of products, using a product data management
(PDM) client server system. Spec. ¶¶ 2, 4. Visualized modeled products
include “[a]ircraft, ships, and factories . . . and . . . other products or
objects.” Id. ¶ 24. “Disclosed embodiments can interactively render the
complete 3D model [of an airplane, ship, etc.] in less than 30 seconds . . .
regardless of model size.” Id.
Figure 3 of the Specification follows:

Figure 3 illustrates “visualization data server (VDS)” 312 on “PDM
client system network” 340, with PDM server 302 providing 3D rendering
Appeal 2019-001004
Application 15/075,696

3
data, product data structure files for indexed products, and updates on the
server side to client side VDS 312, which then interacts and provides 3D
rendering data to at least one client side rendering machine 330A–330N.
See Spec. ¶¶ 4, 24, 31–34, 40.
The Specification states “[w]hile the example of Fig. 3 illustrates a
single VDS serving multiple rendering machines, other embodiments can
include one visualization data server per render machine, . . . [and] multiple
local client system network sites each with one or more VDS processes or
rendering machines.” Spec. ¶ 50 (emphasis added). In other words, each
client site may include a renderer and a VDS. Also, “each site
communicates with the same PDM server, multiple PDM servers at
geographically separated locations that each communicate with one or more
VDS processes and rendering machines, and other combinations of the
elements discussed herein.” Id.
The Specification describes the VDS as a “new server component” on
the client side with the renderers:
According to various embodiments, dynamic structure
solve, property retrieval, and access checking are no longer done
by the PDM server directly (which can be on a WAN relative to
the renderer), but instead it can be done jointly by the PDM
server and a new server component (the Visualization Data
Server (VDS)) that is co-located on the local LAN relative to the
renderer.
Id. ¶ 27.
In summary, the VDS supports rendering by communicating with the
PDM server and the rendering machines. Spec. ¶¶ 24, 43. For example,
“[t]he system is designed for incremental update, so periodic polling is done
to get changes from PDM server system 302 and apply them to VDS 312.”
Appeal 2019-001004
Application 15/075,696

4
Id. ¶ 39. Also, the VDS receives “cell queries” or “request[s]” to “configure
the occurrences for spatial cells” from the rendering machines. See id. ¶ 45;
Appeal Br. Claims App’x (claim 1). In general, “[d]isclosed embodiments
can support both client-based rendering and remote rendering.” Id. ¶ 24.
Independent claim 1 illustrates the claimed subject matter:
1. A method for massive-model visualization, comprising:
receiving three-dimensional (3D) rendering data for a
product from a product data management (PDM) server system
by a visualization data server (VDS) on a PDM client system
network;
synchronizing and updating the 3D rendering data by the
VDS according to changes on the PDM server system;
computing spatial hierarchies from the 3D rendering data
by the VDS;
serving the computed spatial hierarchies, by the VDS, to
at least one rendering machine on the PDM client system
network, including dynamically configuring the product
according to cell queries received from the at least one rendering
machine on the PDM client system network.

REFERENCES
The Examiner relies upon the following prior art:
Name Reference Date
Moussa US 6,742,043 Bl May 25, 2004
Vredenburgh US 2005/0071135 Al Mar. 31, 2005
Carter US 2013/0132432 Al May 23, 2013
Sherman US 9,413,807 Bl Aug. 9, 2016

REJECTIONS
Claims 1, 2, 4, 6–9, 11, 13–16, 18, and 20 stand rejected under 35
U.S.C. § 103(a) as being unpatentable over Carter, Sherman, and Moussa.
Appeal 2019-001004
Application 15/075,696

5
Claims 5, 12, and 19 stand rejected under 35 U.S.C. § 103(a) as being
unpatentable over Carter, Sherman, Moussa, and Vredenburgh.
OPINION
After considering Appellant’s arguments and contentions (Appeal Br.
14–55; Reply Br. 8–28) in light of the Examiner’s findings and explanations
(Final Act. 2–16; Ans. 3–8), for the reasons set forth below, we AFFIRM IN
PART.
A. Claims 1, 2, 7–9, and 14–16
The Examiner relies on the combined teachings of Carter, Sherman,
and Moussa as teaching or suggesting the limitations of claim 1. Final Act.
3–8. The Examiner finds Carter teaches most of the limitations of claim 1,
except for the VDS limitation and the dynamically configuring limitation,
for which the Examiner relies respectively on the teachings of Sherman and
Moussa, in combination with Carter. See id.
Addressing the VDS limitation, the Examiner contends “Carter does
not expressly disclose a visualization data server (VDS) on a” “PDM client
system” “network.” Final Act. 4–5. The Examiner contends Sherman
teaches or suggests a VDS on a client system network. See Final Act. 5
(citing Sherman, Fig. 2, 9:7–26, 6:20–23). The Examiner contends
Sherman’s “server system determines the most efficient way to prepare the
requested visual representation (also known as a ‘data visualization’) for
display at the client system” including by using a local data cache 108-1 on
the client side that “includes data retrieved from the server system 130.” See
id. (quoting Sherman, 6:21–23).
Sherman supports the Examiner. Describing the noted efficiency
determination, Sherman discloses “[w]hen the data set is small, doing work
Appeal 2019-001004
Application 15/075,696

6
locally removes the latency of round-trips to the server.” Sherman, 6:1–3.
Sherman also discloses dynamically allocating the processing or rendering
of raw data between the local client and server as follows:
[D]ynamically allocating work allows the server system to scale
to very large data sets, rendering the visual representation at the
server when it is impractical to transfer all the raw data over a
network to a client. Furthermore, dynamic allocation of
rendering tasks allows the visualization server to serve client
devices with low bandwidth connections, old or out of date
browsers, or limited processing power.
Id. at 6:4–11 (emphasis added). In other words, as the Examiner recognizes,
Sherman’s system seeks to selectively divide the rendering work between
the client and server, in the most efficient manner, depending on a variety of
factors, including the relative capabilities and processing power of the
requesting client. See id. at 6:4–65; Final Act. 5–7.
The Examiner contends “Sherman and Carter are analogous since
both of them are dealing with visualization of data.” Final Act. 6. The
Examiner explains Carter’s system “process[e]s massive model visualization
in a PDM system,” and Sherman’s system transfers “display visualization
data between server and multiple clients” using a local cache on the client.
See id. According to the Examiner, using the local cache processing system
suggested by Sherman in Carter’s system would have been obvious for the
purpose of increasing the speed of the system based on the locally stored
cached data. See id. at 6–7 (“[S]ince the data is cached and stored in the
client side the access speed will be faster.”).
In the Answer, the Examiner explains further that “Carter does not
expressly disclose using [a] VDS” to “locally store the unconfigured data for
rendering.” Ans. 4. The Examiner explains that Sherman teaches a “client-
Appeal 2019-001004
Application 15/075,696

7
server data module system that provide[s]” “multiple client[s]” with “data
retrieved from [the] server.” Id. According to the Examiner, Sherman’s
system “provide[s] data . . . to clients” “dynamically generated based on the
presentation model . . . [while] utiliz[ing] state information in the client to
generate the visual representation.” Id. Therefore, the Examiner finds that
“the client device provided by . . . Sherman serve[s] . . . the same purpose as
the [claimed] VDS by locally configur[ing] the data on the client side.” Id.
Essentially, the Examiner maintains that the only difference between
Carter’s system and the claimed invention turns on using local VDS
functionality at the client side to perform the VDS functions recited in claim
1, whereas Carter’s system performs at least some functions at the client side
and some at the server side, with Sherman suggesting performing rendering
functions at the client side using a server on the client side to, for example,
locally configure data from the server on the client side. See Final Act. 6;
Ans. 4–5.
Appellant responds to the “Answer’s argument that ‘the client device
provided by the Sherman serve[s] . . . the same purpose as the [claimed]
VDS by locally configur[ing] the data on the client side,” Reply Br. 14
(quoting Ans. 4), as follows:
[The Answer] ignore[s] that the claims describe that the VDS
performs certain tasks to offload them from the client rendering
machine(s) and so that the 3D rendering data as a whole need
not be transmitted to the client rendering machine(s). By
insisting that the claimed functions of the VDS system are
performed by Sherman’s client system, the Examiner’s Answer
concedes that Sherman also does not teach systems and methods
as claimed, which require (at least) three different types of
systems: the PDM server system, the VDS, and at least one client
rendering machine.
Appeal 2019-001004
Application 15/075,696

8
Reply Br. 14–15 (emphasis added). In other words, Appellant agrees with,
and does not dispute, the Examiner’s finding and rationale that Sherman
suggests offloading the tasks recited in claim 1 from Carter’s server side to
its client side. See id.; Sherman at code (57). Rather, Appellant contends
that claim 1 recites “three different types of systems,” as quoted above.
Contrary to Appellant’s argument, however, claim 1 recites only two
different systems, namely 1) a “product data management (PDM) server
system,” and 2) “a PDM client system network.” Claim 1 specifically
recites “a visualization data server (VDS) on a PDM client system network.”
Therefore, Appellant does not show error in the Examiner’s finding and
rationale that Sherman suggests offloading tasks such as those recited in
claim 1 from Carter’s server side to its client side.
Appellant’s remaining arguments for the most part attack the
references individually. See Reply Br. 14–23. For example, Appellant
argues “the Office Action acknowledges that Carter has no VDS,” and
Appellant also argues “[t]he data module 224 on Sherman’s client system
102 does not synchronize and update 3D rendering data according to
changes on the PDM server system, and so does not function as the claimed
VDS.” Id. at 15. Nevertheless, even if Carter does not disclose a VDS and
Sherman’s data module 224 does not function (by itself) as the claimed
VDS, Appellant does not dispute that Sherman suggests offloading the
claimed tasks to Carter’s client device, as the Examiner finds. See Ans. 4.
Furthermore, as discussed above, the Examiner does not rely solely on
Sherman’s data module 224 as performing all the recited VDS functionality
and instead relies on Sherman’s teachings directed to dividing rendering
tasks selectively “using [a] LAN [(local area network)] to store cached data
Appeal 2019-001004
Application 15/075,696

9
and display visualization data between server and multiple clients” (Final
Act. 6), in a “client-server environment 100,” which “includes one or more
client systems 102, a server system 130, and a network 120” (id. at 5)
(emphasis omitted). See also Ans. 4 (“The system further provide[s] data
sen[t] to clients that [are] dynamically generated based on the presentation
model and utilize[s] state information in the client to generate the visual
representation. Hence the client device provided by the Sherman serve[s]
. . . the same purpose as the VDS by locally configur[ing] the data on the
client side.”).
Sherman supports the Examiner, as found above. Similar to the
claimed invention, Sherman teaches locally rendering data on the client side.
For example, “the system determines where rendering and interaction should
be performed based on the current state of the visualization.” Sherman,
8:46–48. “[T]he appropriate code and state information is sent to the client
system. Data may be sent to the client as ‘data’ to be rendered and
computed locally or sent as image files and metadata.” Id. at 8:49–52
(emphasis added). Also, “[c]ode sent to the client may be dynamically
generated or it may be based on presentation models.” Id. at 8:52–54.
As reproduced by the Examiner (Final Act. 6), Figure 2 illustrates
Sherman’s client system 102 as including CPUs 202 and memory 212.
Memory 212 includes web browser 104 in addition to distinct visual data
rendering module 110 for rendering images. Sherman, Fig. 2. Also, client
side memory system 212 specifically includes, inter alia, operating system
216 in addition to cached data 108 in data module 224. All of this indicates
or suggests server functionality on a client side (i.e., the claimed VDS) to
reach and access cached data 108 to render images. See Sherman Fig. 2,
Appeal 2019-001004
Application 15/075,696

10
Fig. 4A, code (57). As indicated above, Sherman generally teaches allowing
the clients and the server to render images and process data, depending on
the processing power of the client, thereby creating an efficient system. See
id. at code (57).
In addition, the client side includes its own “processing power.”
Sherman, Fig. 4. Sherman’s client system CPUs and/or web browser access
the rendering modules, cache, and display, and also send data requests from
the client system to the server system. See id. at 9:25–10:12, Fig. 2.
Similarly, Carter’s system includes renderer 216 as a distinct component on
client 230. Carter, Fig. 2. In other words, as the Examiner finds, and
contrary to Appellant’s arguments that focus on Sherman’s memory 224 (see
Appeal Br. 24) and allege “(at least) three different systems” (id. at 29), the
combined teachings of Carter and Sherman suggest three different entities,
including the claimed server (VDS) functionality on the client side residing
in the form of CPU processing power or modules, as distinct entities from
the rendering modules (machines) on the client side, and as distinct entities
from the server side. See Sherman, Fig. 1, Fig. 2, Carter Fig. 1. Similar to
the combined teachings of Sherman and Carter, as described in the opening
discussion of the claimed and disclosed invention above, the Specification
reveals that each rendering machine may be associated with a VDS at a
client site. Spec. ¶ 50.
Appellant also argues that claim 1 “describes computing spatial
hierarchies from the 3D rendering data by the VDS.” Reply Br. 15.
Appellant maintains “[a]gain, there is no VDS in Carter,” and the Examiner
relies on Carter, “which describes that MMDB spatial BBox hierarchy 206 is
computed and stored on server 220.” Id. at 15–16 (citing Carter, Fig. 2,
Appeal 2019-001004
Application 15/075,696

11
¶¶ 32–33). According further to Appellant, Carter’s “spatial BBox hierarchy
206 of the MMDB can be downloaded and stored as spatial BBox hierarchy
212 in client system 230.” Id. (citing Carter ¶ 34). In other words,
according to Appellant, “Carter’s server, not a VDS, creates MMDB spatial
BBox hierarchy 206.” Id. at 16. Stated differently, Appellant contends that
the Examiner asserts Carter’s PDM server performs the claimed function of
“serving the computed spatial hierarchies.” See id. (“The Office Action
refers to a teaching that Carter’s server 220 spatial BBox hierarchy 206 can
be downloaded to client system 230 to be stored as spatial BBox hierarchy
212.”).
However, as noted above, the Examiner does not rely in the Answer
solely on Sherman’s data module 224 or on Carter’s separate teachings.
Rather, the Examiner more generally contends that Sherman suggests
transferring the claimed rendering server functionality from Carter’s server
side to Carter’s client side (i.e., the claimed VDS). See Ans. 4; Final Act. 6–
7. The Examiner finds the combination suggests processing some rendering
data on the client side to generate the visual representation, using, inter alia,
a cache, “to create a more efficient system” (Ans. 4) and because “the access
speed will be faster” (Final Act. 6–7). Sherman supports the Examiner, as
discussed above. See, e.g., Sherman, 7:38–41 (“When the client system is
an efficient place to render the visual representations, the server system
transmits the requested data set to the client system for rendering and
display.”). Patent Owner’s separate attacks on the references or on specific
components disclosed in Sherman (i.e., data module 224) do not show error
in the Examiner’s reliance on the combined teachings.
Appeal 2019-001004
Application 15/075,696

12
The Examiner further relies on Moussa to suggest a client side proxy,
in order to supplement the teachings of Carter and Sherman, to process PDM
functions on the client side. See Ans. 4–5; Final Act. 7–8. According to the
Examiner, Moussa suggests employing a client side proxy in this manner
and also to allow communication with the server side, thereby to “increase
the flexibility for the system.” See Final Act. 7–8 (“[I]t would have been
obvious to one of ordinary skill in the art . . . to incorporate using [a] proxy
server layer taught by Moussa into modified invention of Carter such that
system will be able to store spatial hierarchies data on the proxy server on
the client side network at the same time system will be able to dynamically
sending request[s] from client side to PDM server side using the modular
proxy server which increase the flexibility for the system.”).
Appellant argues that “Moussa has literally nothing to do with
massive model visualization with a product lifecycle management system, as
in the present application, and as in the Carter reference.” Appeal Br. 25.
According to Appellant, “Moussa describes a ‘WebTV’ server that includes
a proxy server that can reformat web content to properly display on a client
device according to that device’s capabilities –– its target use case is
reformatting higher-resolution web content that is appropriate for a computer
monitor to a lower-format version that can be displayed on a TV.” Id. at 24–
25.
Nevertheless, as Appellant notes, and as the Examiner recognizes,
Moussa describes a client server system that includes an additional proxy
server layer, which aids in formatting visual data on the client side,
according to the client side capabilities. See Final Act. 7 (“Moussa and
Carter are analogous since both of them are dealing with process data in
Appeal 2019-001004
Application 15/075,696

13
between client and server. Carter provided a way of process massive model
visualization in a PDM system using client and server process. Moussa
provided a client side proxy sever to handle the data request in between
remote server and client.”). So each of the three references involves
processing data in a client server system for the purpose of providing visual
data. Accordingly, Appellant’s argument that “Moussa fails to teach the
claim features at issue” amounts to a piecemeal attack on Moussa that does
not address the Examiner’s findings premised on the combination of
references. See Appeal Br. 25 (“[C]onsistent with the [S]pecification, the
cell queries refer to specific spatial cells, e.g., specific areas in 3D space in
which portions of the product are located in the computed spatial
hierarchies.”). As noted above, Appellant recognizes that the Examiner
asserts Carter’s PDM server performs the claimed function of “serving the
computed spatial hierarchies.” Reply Br. 16 (“The Office Action refers to a
teaching that Carter’s server 220 spatial BBox hierarchy 206 can be
downloaded to client system 230 to be stored as spatial BBox hierarchy
212.”).
In a similar separate attack, Appellant asserts that the Examiner
“equate[s] Moussa’s ‘requests’ with the claimed cell queries, but this is
simply factually incorrect.” Appeal Br. 25. Contrary to this argument,
however, the Specification refers to “cell queries” as “request[s].” Spec.
¶ 45 (“[A] request is made to the VDS 312 to ‘configure the occurrences for
spatial cells’. This is sometimes called the cell queries.” (emphasis added)).
Also, the Examiner primarily relies on Moussa for its teaching regarding the
client side proxy, as noted above. The Examiner further shows other
similarities as supporting reasons for processing data on the client side,
Appeal 2019-001004
Application 15/075,696

14
including the similarities between “dynamically configuring the product
according to cell queries received [at the VDS] from the at least one
rendering machine on the PDM client network” as claimed, and Moussa’s
“requests” from “a first client for content on a remote server.” See Final
Act. 7. But the Examiner does not, and need not, literally “equate” the
claimed cell queries to Moussa’s requests, to support the obviousness
rejection. Rather, as indicated above, the Examiner relies on the combined
teachings and suggestions for cell queries according to teachings in Carter
and Moussa. See id.
Specifically, the Examiner relies on Carter as teaching “dynamically
configuring the product according to cell queries.” Final Act. 4. Then, the
Examiner analogizes Moussa’s proxy layer as further suggesting the claimed
VDS on the client side, and analogizes Moussa’s requests as “cell queries,”
Moussa’s client as a “rendering machine,” and Moussa’s dynamically-
linkable modules in the proxy layer as suggesting “dynamically configuring
the product” according to “cell queries” as claimed. See id. at 7.
As indicated above, Appellant’s arguments mainly attack the
references separately and do not show error in the Examiner’s rejection.
Appellant cannot undermine the Examiner’s obviousness showing by
attacking references individually, where the Examiner rejects the claims
based on a combination of references. In re Merck & Co., 800 F.2d 1091,
1097 (Fed. Cir. 1986); In re Keller, 642 F.2d 413, 425–26 (CCPA 1981).
Appellant groups dependent claim 2 with independent claim 1.
Appeal Br. 16. Appellant facially presents separate headings and arguments
directed to independent claims 8 and 15. See id. at 33–41, 44–53. Claims 8
and 15 track the limitations of claim 1. In addition, Appellant’s arguments
Appeal 2019-001004
Application 15/075,696

15
with respect to claims 8 and 15 materially track the arguments with respect
to claim 1 despite the separate headings. Id. Appellant groups independent
claims 8 and 15, respectively, with dependent claims 9 and 16. See id.
Based on the foregoing discussion of claim 1 and the arguments presented,
Appellant does not show error in the Examiner’s rejection of claims 2, 8, 9,
15, and 16. See 37 C.F.R. § 41.37(c)(1)(iv). Appellant does not present
separate arguments addressing the Examiner’s rejection of claims 7 and 14.
For the foregoing reasons, Appellant does not show error in the
Examiner’s rejection of claims 1, 2, 7–9, and 14–16.
B. Claims 4, 11, and 18
Claim 4 depends from claim 1 and further recites “wherein the 3D
rendering data is cached on the VDS from the PDM server system and is
served by the VDS to multiple rendering machines.” Claims 4, 11, and 18
recite materially similar limitations. Appellant’s arguments for claims 11
and 18 materially repeat the arguments for claim 4. See Appeal Br. 29–30,
41–42, 53–54. Based on the materially similar arguments presented and the
materially similar limitations recited, claim 4 represents claims 4, 11, and 18
for purposes of this appeal.
Similar to the showing with respect to claim 1 discussed above, the
Examiner relies on the combination of references with Sherman and Moussa
suggesting the claimed VDS functionality on Carter’s client side. See Ans.
5–6; Final Act. 9–10. For example, the Examiner asserts as follows:
Sherman teaches . . . that a system include[s] server system and
multiple Client systems. When the server system determines to
render the visual representation at the client system, the server
system sends the requested set of data to the client system for
rendering and display, data may be sent to the client as “data” to
Appeal 2019-001004
Application 15/075,696

16
be rendered and computed locally. Code sent to the client may
be dynamically generated.
Ans. 5 (citing Sherman, Fig. 1, 2:17–20, 8:50–53).
Appellant argues “Sherman’s data module 224 in memory 212 of
client system 102 does not serve 3D rendering data to multiple rendering
machines as required by this claim.” Appeal Br. 30 (emphasis added).
Appellant also argues “nothing in Sherman . . . suggests that a module in a
memory of a single client system is even capable of serving data to other
client systems.” Id. (emphasis added). The Examiner’s Answer does not
address Appellant’s contention regarding a VDS serving multiple rendering
machines. See Ans. 6.
Figure 3 of the Specification, reproduced above, “illustrates a single
VDS serving multiple rendering machines” and represents an example of an
embodiment covered by claim 4. Spec. ¶ 50. In the Reply Brief, Appellant
argues “[e]ven the Examiner’s Answer does not actually allege any system
that caches the 3D rendering data from the PDM server system and serves it
to multiple rendering machines, as the claimed VDS does.” Reply Br. 25
(emphases added). As indicated above, Appellant raises a valid point. See
Ans. 5. For example, the Examiner’s Answer states “[s]ince there are
multiple client systems and each client system is doing rendering, . . . the
combination of the prior art Carter and Sherman anticipate[s] all the
limitations.” Id. (emphases added).
This conclusion does not address Appellant’s argument and appears to
concede the correctness of Appellant’s argument. For example, the
Examiner does not allege that the claim 4 limitation, “served by the VDS to
multiple rendering machines,” reads on multiple VDSs with each serving a
single rendering machine––a reading that the Examiner contends the
Appeal 2019-001004
Application 15/075,696

17
combination teaches. Also, asserting anticipation via a combination of
references, without more, fails how to show how this claim feature would
have been obvious. In other words, the Examiner does provide a reason
supported by a factual foundation that explains why the subject matter of
claim 4 would have been obvious.
Claim 18 recites the same relevant limitation as recited in claims 4
and 11, “served by the VDS to multiple rendering machines.” Appellant
groups claim 18 with claims 4 and 11. Reply Br. 24–25. The Examiner
agrees claims 11 and 18 “recite[] limitations similar in scope to the
limitations of [c]laim 4.” Ans. 7–8. Based on the foregoing discussion,
Appellant shows error in the Examiner’s rejection of claims 4, 11, and 18.
B. Claims 6, 13, and 20
Claim 6 recites “[t]he method of claim 1, wherein the VDS gets
product data structure files for all structures indexed for visualization from
the PDM server system and loads the product data structure files into an in-
memory product structure model on the VDS.” Claims 13 and 20 recite
materially similar limitations as claim 6. Appellant provides separate
headings and facially argues claims 6, 13, and 20 separately, but Appellant’s
arguments for claims 13 and 20 materially repeat the arguments for claim 6.
Appeal Br. 31–32, 43–44, 54–56. Based on the materially similar arguments
presented and the materially similar limitations recited, claim 6 represents
claims 6, 13, and 20 for purposes of this appeal.
Similar to its showing with respect to claims 1 and 4, the Examiner
relies on the combination of Carter, Sherman, and Moussa to teach the VDS
and local memory limitations. See Final Act. 10 (finding inter alia, “the
server system [of Sherman] determines the most efficient way to prepare the
Appeal 2019-001004
Application 15/075,696

18
requested visual representation . . . for display at the client system” and “the
data cache 108-1 includes data retrieved from the server system 130”)
(quoting Sherman at 6:20–23, 9:25–27). The Examiner also finds Carter
teaches the claimed product data structure files, and finds Carter teaches
downloading the files from a server and storing the files locally “as spatial
BBox hierarchy 212 in client system 230.” Id. (quoting Carter ¶ 34).
Appellant repeats its arguments advanced with respect to claim 1.
Appeal Br. 31–32. For the reasons discussed above, Appellant’s arguments
do not show error. Addressing the Examiner’s findings that Carter teaches
storing the files locally on the client, Appellant largely agrees, arguing
Carter’s “client system itself can get the BBox hierarchy directly from the
server, contrary to the claims.” Id. at 31. This argument does not address
the combination of teachings relied upon by the Examiner.
Appellant also argues “Sherman’s data module 224 in memory 212 of
client system 102 does not get[] product data structure files for all structures
indexed for visualization from the PDM server system as required by this
claim.” Id. at 32. Again, this argument does not address the Examiner’s
findings that the combination of references teaches or suggests a VDS that
performs local client functions as dictated by the server side to provide a
more efficient system. See, e.g., Ans. 4 (“Hence the client device provided
by . . . Sherman serve[s] . . . the same purpose as the VDS by locally
configuring] the data on the client side. By applying Sherman’s client data
configuration to . . . Carter’s PDM model, [the] system will be able to store
cached data on [the] client site . . . separated from the server side . . . to
create a more efficient system.”).
Appeal 2019-001004
Application 15/075,696

19
In the Reply Brief, Appellant addresses the Examiner’s Answer, but
largely repeats arguments addressed above in connection with claim 1. For
example, Appellant argues that Sherman does not teach or suggest the “same
functionality” of the VDS, without explaining why the combination lacks the
claimed functionality: “Even if it were true that the ‘same functionality’
were present––which is it not––it is contrary to the claims to have the client
systems perform any tasks that the claims describe are performed by the
VDS, since the claims avoid moving such tasks and associated data to each
of the rendering machines.” Reply Br. 28 (emphasis omitted). This
argument incorrectly ignores the claim requirement that the client system
includes a VDS, as determined above in connection with claim 1, and the
Examiner persuasively contends the combination suggests a server on the
client side with VDS functionality, as discussed above. See claim 1, App’x
(“receiving three-dimensional (3D) rendering data for a product from a
product data management (PDM) server system by a visualization data
server (VDS) on a PDM client system network”). Accordingly, Appellant
fails to show error in the Examiner’s rejection of claims 6, 13, and 20.
C. Claims 5, 12, and 19
The Examiner relies on the combined teachings of Carter, Sherman,
Moussa, and Vredenburgh as teaching or suggesting the subject matter of
dependent claims 5, 12, and 19, which respectively depend from claims 1, 8,
and 15. These claims recite materially similar limitations. Appellant groups
the claims together and also relies on its arguments with respect to
independent claims 1, 8, and 15. Appeal Br. 57. Accordingly, claim 5
represents claims 5, 12, and 19 for purposes of this appeal.
Appeal 2019-001004
Application 15/075,696

20
As Appellant notes, “these claims describe that the PDM server
system implements a full text search indexing system.” Appeal Br. 57.
Particularly, representative claim 5 recites “[t]he method of claim 1, wherein
the PDM server system implements a full text search indexing system.” The
Examiner finds that Vredenburgh teaches a full text indexing system via a
relational database. Final Act. 14–15. For example, the Examiner finds that
Vredenburgh discloses providing fast access to data by employing index
based searching. See id. (quoting Vredenburgh ¶¶ 68, 80, 122). Based on
these findings and others, the Examiner further finds as follows:
Vredenburgh and Sherman and Carter are analogous since
they are all dealing with data using PDM. Carter provided a way
of process massive model visualization in a PDM system.
Sherman provide[s] a way of using LAN to store cached data and
display visualization data between server and multiple clients.
Vredenburgh provided a way of using full text index searching
in PDM system. Therefore, it would have been obvious to . . .
incorporate using full text index search in PDM taught by
Vredenburgh into modified invention of Carter, Sherman and
Moussa such that system will be able to search the data based on
the full text indexed and provide better performance for the
matching.
Final Act. 15.
In response, Appellant contends “Vredenburgh describes that a
relational database can have a full-text index, but otherwise bears no relation
to the claim processes as described in the parent claims.” Appeal Br. 57.
This response does not address the Examiner’s obviousness determination,
which relies on similarities in Vredenburgh, Sherman, and Carter as
involving PDM data systems, and the finding that a full text search indexing
system such as that of Vredenburgh’s would have been obvious for the
Appeal 2019-001004
Application 15/075,696

21
purpose of finding relevant data quickly and efficiently, thereby improving
performance. See Final Act. 14–15.
Accordingly, Appellant fails to show error in the Examiner’s rejection
of claims 5, 12, and 19.
CONCLUSION
The Examiner’s decision under 35 U.S.C. § 103(a) to reject claims 1,
2, 5–9, 12–16, 19, and 20 is AFFIRMED. The Examiner’s decision under
35 U.S.C. § 103(a) to reject claims 4, 11, and 18 is REVERSED.
In summary:
Claims
Rejected
35 U.S.C. § References Affirmed Reversed
1, 2, 4, 6–9,
11, 13–16,
18, 20
103(a) Carter, Sherman, Moussa

1, 2, 6–9,
13–16, 20
4, 11, 18
5, 12, 19

103(a) Carter, Sherman, Moussa,
Vredenburgh 
5, 12, 19
OUTCOME SUMMARY 1, 2, 5–9,
12–16, 19,
20
4, 11, 18

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 IN PART