Ex Parte Cohen et al

Board of Patent Appeals and Interferences

May 24, 2010

10315758 (B.P.A.I. May. 24, 2010)

UNITED STATES PATENT AND TRADEMARK OFFICE
____________

BEFORE THE BOARD OF PATENT APPEALS
AND INTERFERENCES
____________

Ex parte NORMAN H. COHEN and APRATIM PURAKAYASTHA
____________

Appeal 2008-005331
Application 10/315,758
Technology Center 2100
____________

Decided: May 24, 2010
____________

Before JOHN A. JEFFERY, JEAN R. HOMERE, and
DEBRA K. STEPHENS, Administrative Patent Judges.

JEFFERY, Administrative Patent Judge.

DECISION ON APPEAL
Appellants appeal under 35 U.S.C. § 134(a) from the Examiner’s
rejection of claims 1, 2, and 4-13. We have jurisdiction under 35 U.S.C.
§ 6(b). We affirm.

Appeal 2008-005331
Application 10/315,758

2
STATEMENT OF THE CASE
Appellants’ invention relates to systems for providing data of a
requested kind. Specifically, the invention pertains to automatically
synthesizing suitable data from other kinds of data. See generally Abstract;
Spec. 1. Claim 5 is illustrative:
5. A system for obtaining data sources satisfying a result requirement
in a network environment that includes external data sources and synthesizer
templates, each external data source having an output contract and each
synthesizer template corresponding to a synthesis method capable of
producing an output value from input values, synthesizer-input requirements
to be satisfied by inputs, and a synthesizer-output contract satisfied by each
resulting output, the system comprising:

a first selecting module configured to select a synthesizer template to
be instantiated;

a second selecting module configured to select for each input of the
synthesizer template at least one data source from the external or synthesized
data source whose output contract satisfies the synthesizer-input requirement
for the each input of the synthesizer template;

an instantiating module configured to instantiate the synthesizer
template using the data source selected for the input of the synthesizer
template, thereby obtaining a new synthesized data source that may be
selected subsequently by the second selecting module; and

a constructing module configured to construct a set consisting of at
least one resulting synthesized data source or external data source whose
output contract satisfies the result requirement.

The Examiner relies on the following as evidence of unpatentability:
Gjovaag US 5,455,952 Oct. 3, 1995
Letourneau US 5,724,576 Mar. 3, 1998

Appeal 2008-005331
Application 10/315,758

3
THE REJECTIONS
1. The Examiner rejected claims 5-8 and 13 under 35 U.S.C. § 102(b) as
anticipated by Gjovaag. Ans. 3-6.1
2. The Examiner rejected claims 1, 2, 4, and 9-12 under 35 U.S.C.
§ 103(a) as unpatentable over Gjovaag and Letourneau. Ans. 6-13.

CLAIM GROUPING
Regarding the anticipation rejection, Appellants argue claims 5, 6, 12,
and 13 together as a group. See Br. 8-10. Although Appellants argue claims
7-9 separately from independent claim 5, the arguments are commensurate
with those presented for claim 5. See Br. 10. Accordingly, we group claims
5-8 and 13 together, and select claim 5 as representative.2 See 37 C.F.R.
§ 41.37(c)(1)(vii).
Since Appellants also argue claims 1, 2, 4, and 9-11 together
regarding the obviousness rejection (Br. 5-8), we select independent claim 1
as representative of these claims (along with claim 12 not separately
argued).

THE ANTICIPATION REJECTION
Regarding representative claim 5, the Examiner finds that Gjovaag
discloses every claimed feature including modules that not only select
“synthesizer templates” and data sources, but also instantiate the synthesizer
template and construct a data source set as claimed. Ans. 3-4, 13-17.

1 Throughout this opinion, we refer to the Appeal Brief filed October 24,
2007 and the Examiner’s Answer mailed February 7, 2008.
2 Since the Examiner rejected claim 12 under § 103—not § 102—we treat
this claim along with the other claims rejected under § 103.
Appeal 2008-005331
Application 10/315,758

4
Specifically, the Examiner equates Gjovaag’s “tool classes” with the recited
“synthesizer templates,” and notes that these selectable “tool classes” have
various types and inputs which can be satisfied to obtain a particular result.
Ans. 14-15.
Appellants argue that Gjovaag’s tool classes do not comport with the
Specification’s description of a “synthesizer template,” namely a method for
synthesizing a data source meeting a given set of requirements, given data
sources that meet other requirements, specified as part of the template. Br.
9. Appellants add that the Examiner failed to explain or show why Gjovaag
meets various recited modules, specifically the first selecting module, the
instantiating module, and the constructing module. Br. 9-10.
The issue before us, then, is as follows:

ISSUE
Under § 102, has the Examiner erred in rejecting claim 5 by finding
that Gjovaag discloses:
(1) a first selecting module configured to select a synthesizer
template to be instantiated;
(2) an instantiating module configured to instantiate the synthesizer
template using the data source selected for the synthesizer template’s input;
and
(3) a constructing module configured to construct a set consisting of at
least one resulting synthesized data source or external data source whose
“output contract” satisfies a result requirement?

Appeal 2008-005331
Application 10/315,758

5
FINDINGS OF FACT (FF)
1. Gjovaag discloses a network-based data visualization system
enabling a user to graphically edit a network of displayed objects3 and their
interconnections to specify an underlying data computing and visualization
process. Each displayed object is selected by the user from a menu of
objects representing data structures and functions (e.g., data fields to be
analyzed, mathematical operations, data input functions, and display
manipulation functions). Gjovaag, Abstract.
2. To this end, the user in Gjovaag graphically draws lines
interconnecting ports on the objects that have underlying data structure
addresses that establish and control data and operational flow through the
underlying computer-driven process. Id.
3. An “object dependency network” comprises (1) “tools” (i.e.,
instances which represent the result of a computation); (2) “tool classes”;
and (3) dependency relationships between tools. A dependency relationship
is created when an “antecedent” tool is connected to an input port of a
“dependent” tool. Gjovaag, col. 5, ll. 28-32, 42-44; col. 6, ll. 1-5.
4. Each tool class defines a set of input ports that determine the
number and type of antecedents a tool may have. Gjovaag, col. 5, ll. 39-52.
5. Figure 2 shows an object dependency network 40 with tool 44
dependent on antecedent tools 42, 46. Tool 44 is an instance of a
“RealScalarSum” class, and represents the sum of two real numbers (“A”
and “B”) that are likewise represented by antecedent tools 42, 46. Gjovaag,
col. 5, ll. 57-67; col. 6, ll. 29-38; Fig. 2.

3 “An ‘object’ is an actual instance of data structures described by a ‘class’.”
Gjovaag, col. 5, ll. 9-10.
Appeal 2008-005331
Application 10/315,758

6
6. Figures 3-6 show various other exemplary object dependency
networks. These examples show that certain dependent tools (e.g., tools 66,
74, 76, 112, 106) can function as antecedent tools with respect to other
dependent tools. See generally Gjovaag, col. 6, l. 48 – col. 8, l. 42; col. 11,
l. 19 – col. 12, l. 32; Figs. 3-6.
7. A user can create a tool by selecting the tool class name from a
menu which enables the user to position a corresponding tool icon by
dragging it with a mouse. Connections can be created by (1) selecting an
antecedent tool icon, and then (2) selecting an input port on a dependent tool
icon. Next, a line is drawn between the antecedent tool to the dependent
tool’s input port. Gjovaag, col. 10, ll. 33-49.
8. Appellants’ Specification notes that data sources have “contracts
promising that their outputs have certain characteristics.” Data sources can
be (1) “active” (i.e., one that “takes the initiative in emitting values”); (2)
“passive” (i.e., provides data responsive to a request); or (3) “hybrid” (i.e.,
does both active and passive functions). Spec. 3:32–4:5.
9. “A synthesizer template specifies a method for synthesizing a data
source meeting a given set of requirements, given data sources that meet
other requirements, specified as part of the template.” Spec. 4:27-29.
10. Dependency networks can be saved for reuse. To rerun or use a
network as a basis for a new network, the user selects the network from a
library menu. Gjovaag, col. 12, ll. 21-31.

Appeal 2008-005331
Application 10/315,758

7
ANALYSIS
We begin by construing a key disputed limitation of claim 5 which
calls for, in pertinent part, a first selecting module configured to select a
“synthesizer template.” According to Appellants’ Specification, “[a]
synthesizer template specifies a method for synthesizing a data source
meeting a given set of requirements, given data sources that meet other
requirements, specified as part of the template.” FF 9.
Given this definition, we see no error in the Examiner’s reliance on
Gjovaag’s tools and their associated tool classes used in connection with an
object dependency network (FF 1-3) as corresponding to the recited
“synthesizer template.” As the Examiner indicates (Ans. 14-16), these tools
represent the result of a calculation. FF 3. And this calculation is based on
the dependency relationship created by the tool’s “antecedents,” namely the
type and number of data sources (i.e., antecedent tools) that are connected to
the dependent tool’s input ports which, in the example of Gjovaag’s Figure
2, is the sum of two numbers “A” and “B.” FF 3-5.
Based on this functionality, we find that Gjovaag’s tools and
associated tool classes constitute “synthesizer templates” as claimed since
they effectively specify methods for synthesizing a data source meeting a
given set of requirements (e.g., by providing a “RealScalarSum” type of
passive data source as in Figure 2). See FF 3-6. In reaching this conclusion,
we emphasize that the term “data source” is quite broad, particularly in light
of the Specification which notes that data sources can include a variety of
data sources, including those that are “passive” (i.e., sources that provide
data responsive to a request). See FF 8. The data provided by Gjovaag’s
tools—which represent the result of a computation (FF 3)—amply meets this
Appeal 2008-005331
Application 10/315,758

8
criterion. That these tools themselves can function as data sources (i.e.,
antecedent tools) with respect to other dependent tools (FF 6) as the
Examiner indicates (Ans. 14-15) only bolsters our conclusion that Gjovaag’s
tools not only constitute synthesizer templates, but also synthesized data
sources with particular output characteristics (i.e., “contracts”) as well. See
FF 8-9.
And as the Examiner indicates (Ans. 15-16), users can create desired
object dependency networks by selecting and manipulating tools and their
associated interconnections using menus and a graphical interface. See FF 7.
We therefore agree with the Examiner that this functionality meets the
recited first selecting module configured to select a synthesizer template as
claimed. Moreover, since these tools are associated with objects and are
instances of data structures associated with a class (see FF 1, 3, 5), we find
Gjovaag’s functionality likewise meets an “instantiating module” to obtain a
new synthesized data source as claimed. And since the resulting data
sources are saved and displayed as a set (see FF 1-7)—including saving for
reuse (FF 10)—Gjovaag’s functionality fully meets the recited “constructing
module” as claimed.

THE OBVIOUSNESS REJECTION
Regarding representative claim 1, the Examiner finds that Gjovaag
discloses all the recited subject matter except for (1) forming a set of
instances of the template, and (2) creating and instantiating the same tool
class multiple times. Ans. 6-8. The Examiner, however, relies on
Letourneau’s parallel processing teachings in concluding that the claim
would have been obvious. Ans. 8-9.
Appeal 2008-005331
Application 10/315,758

9
Appellants do not dispute the Examiner’s reliance on Letourneau, but
rather reiterate similar arguments made in connection with claim 5 regarding
Gjovaag’s purported deficiencies regarding commensurate limitations in
claim 1. Br. 5-7. Appellants add that Gjovaag’s vector cross product does
not teach or suggest the recited Cartesian product since they are different
operations as evidenced by the exhibits in the Brief’s Evidence Appendix.
Br. 7-8.
The Examiner, however, maintains that Gjovaag teaches or suggests
the recited Cartesian product which, according to the Examiner, is a product
of two sets. Ans. 21-22. The Examiner reasons that since Gjovaag
computes a “norm vector” across a “vector field” which, according to the
Examiner is a set of vectors, the resulting cross product is therefore a
Cartesian product.
The issue before us, then, is as follows:

ISSUE
Under § 103, has the Examiner erred in rejecting claim 1 by finding
that Gjovaag and Letourneau collectively would have taught or suggested:
(1) selecting a synthesizer template to be instantiated;
(2) instantiating the synthesizer template using the data source
selected for the synthesizer template’s input;
(3) constructing a set consisting of at least one resulting synthesized
data source or external data source whose “output contract” satisfies a result
requirement; and
Appeal 2008-005331
Application 10/315,758

10
(4) forming a set of instances as its inputs, each instance using as its
inputs the data sources in a distinct element of a Cartesian product of the set
of data sources that satisfy each input requirement of the template?

FINDINGS OF FACT
11. In the object dependency network of Gjovaag’s Figure 6, a
gradient field block 110 creates a tool that computes a gradient (vector) field
of a scalar field. A norm block 112 creates a tool that produces a scalar field
that is the mathematical norm of the vector field computed responsive to the
gradient field block. Gjovaag, col. 11, ll. 50-54; Fig. 6.
12. In a declaration filed under 37 C.F.R. § 1.132, Roger Breitenstein
avers that while a “vector cross product and the Cartesian product are
sometimes referred to as a ‘cross product’, they are different mathematical
operations and are not equivalent to each other.” Br. Ev. App’x, Exh. A.
13. Exhibit C of the Brief’s Evidence Appendix notes that “[t]he
Cartesian product of two sets A and B (also called the . . . cross product) is
defined to be the set of all points (a, b) where a є A and b є B. . . .” This
exhibit further notes that “[i]n the Cartesian view, points in the plane are
specified by their vertical and horizontal coordinates, with points on a line
being specified by just one coordinate.” Br. Ev. App’x, Exh. C.

ANALYSIS
We sustain the Examiner’s obviousness rejection of representative
claim 1. First, we are not persuaded by Appellants’ arguments directed to
Gjovaag’s alleged failure to select a synthesizer template to be instantiated
Appeal 2008-005331
Application 10/315,758

11
for the reasons indicated previously with respect to claim 5. We reach a
similar conclusion regarding the recited instantiating and constructing steps
of claim 1.
Nor have Appellants persuaded us of error regarding the Examiner’s
reliance on Gjovaag for the recited Cartesian product limitation in claim 1.
Although we appreciate the distinction between a vector cross product and a
Cartesian product as noted by Mr. Brieitenstein in the Brief’s Evidence
Appendix (FF 12), Appellants have simply provided no evidence on this
record to rebut the Examiner’s position that a Cartesian product would be
determined in Gjovaag (Ans. 22).
Specifically, the Examiner notes that Gjovaag computing a “norm
vector” across a “vector field” in Figure 6—a vector field that is a set of
vectors. Id. (emphasis added). The Examiner then reasons that since
Cartesian products are mathematical operations on sets, then computing the
norm of sets of vectors as in Gjovaag therefore results in a Cartesian
product. See id.
On this record, Appellants have simply not persuasively rebutted this
reasoning. First, Appellants do not dispute the Examiner’s finding that
Gjovaag’s vector field is a set of vectors. And notably, Gjovaag “norm
block” tool produces a scalar field that is the mathematical norm of this
vector set. FF 11 (emphasis added). It is this scalar norm of a set in
Gjovaag that the Examiner seemingly equates to the recited Cartesian
product. See Ans. 22. Even assuming, without deciding, that (1) solely
vector components were used to arrive at this mathematical norm, and (2)
Cartesian operations pertain to point-based mathematical operations (see FF
Appeal 2008-005331
Application 10/315,758

12
13), Appellant has not shown that the resulting scalar norm of the vector set
in Gjovaag (FF 11) would not involve at least some point-based attributes of
a Cartesian system, and therefore at least suggest a Cartesian product as the
Examiner indicates.
We are therefore not persuaded that the Examiner erred in rejecting
representative claim 1, and claims 2, 4, and 9-12 which fall with claim 1.

CONCLUSION
The Examiner did not err in rejecting (1) claims 5-8 and 13 under §
102, and (2) claims 1, 2, 4, and 9-12 under § 103.

ORDER
The Examiner’s decision rejecting claims 1, 2, and 4-13 is affirmed.
No time period for taking any subsequent action in connection with
this appeal may be extended under 37 C.F.R. § 1.136(a)(1)(iv).

AFFIRMED

pgc

THE LAW OFFICE OF IDO TUCHMAN
ECM #72212
PO Box 4668
New York, NY 10163-4668