Ex Parte Cohen et alDownload PDFBoard of Patent Appeals and InterferencesMay 24, 201010315758 (B.P.A.I. May. 24, 2010) Copy Citation 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 Copy with citationCopy as parenthetical citation