Ex Parte DeMesa et alDownload PDFPatent Trial and Appeal BoardOct 23, 201411415710 (P.T.A.B. Oct. 23, 2014) Copy Citation UNITED STATES PATENT AND TRADEMARK OFFICE UNITED STATES DEPARTMENT OF COMMERCE United States Patent and Trademark Office Address: COMMISSIONER FOR PATENTS P.O. Box 1450 Alexandria, Virginia 22313-1450 www.uspto.gov APPLICATION NO. FILING DATE FIRST NAMED INVENTOR ATTORNEY DOCKET NO. CONFIRMATION NO. 11/415,710 05/01/2006 Jesse G. DeMesa 2004P12835US03 (S06.079/D 6107 28062 7590 10/23/2014 BUCKLEY, MASCHOFF & TALWALKAR LLC 50 LOCUST AVENUE NEW CANAAN, CT 06840 EXAMINER LO, WEILUN ART UNIT PAPER NUMBER 2179 MAIL DATE DELIVERY MODE 10/23/2014 PAPER 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. PTOL-90A (Rev. 04/07) UNITED STATES PATENT AND TRADEMARK OFFICE __________ BEFORE THE PATENT TRIAL AND APPEAL BOARD __________ Ex parte JESSE G. DEMESA and DAVID C. JOHNSON __________ Appeal 2012-004332 Application 11/415,710 Technology Center 2100 __________ Before DONALD E. ADAMS, JEFFREY N. FREDMAN, and ULRIKE W. JENKS, Administrative Patent Judges. FREDMAN, Administrative Patent Judge. DECISION ON APPEAL This is an appeal1 under 35 U.S.C. § 134 involving claims to a method of generating a computer model for the collection and display of data. The Examiner rejected the claims as anticipated and as obvious. We have jurisdiction under 35 U.S.C. § 6(b). We affirm. 1 Appellants identify the Real Party in Interest as Siemens Aktiengesellschaft (see App. Br. 1). Appeal 2012-004332 Application 11/415,710 2 Statement of the Case Background “A number of attempts have been made to retrieve data from a business organization’s various data sources . . . and to present that data to users. An organization’s various back-end data sources may contain different types and formats of data, including relational data, point data, time-series data, and object data” (Spec. 1 ¶ 3). The Specification teaches “the use of a class-based component and view model to collect and display data from multiple sources. The class- based component and view model is preferably embodied within a system that uses reusable components and views to monitor the operation of a business entity” (Spec. 3 ¶ 9). The Claims Claims 1–5 and 7–16 are on appeal.2 Claim 1 is representative and reads as follows: 1. A method of generating a computer model for the collection and display of data, the method comprising: generating, by a computer, a first reusable software component that collects data from a first type of data source; generating, by a computer, a first view that specifies how data collected by the first component is to be displayed; creating, by a computer, multiple instances of the first component, each such instance corresponding to a different 2 Appellants state that “the rejection of claim 6 is not separately appealed/argued herein” (App. Br. 3). Because the rejection of claim 6 was not appealed, the Examiner’s Final Rejection of this claim becomes a final agency action. Claim 6 should have been canceled by Appellants. Nevertheless, in the event of further prosecution, the Examiner should cancel claim 6. See Ex parte Ghuman, 88 USPQ2d 1478 (BPAI 2008) (precedential). Appeal 2012-004332 Application 11/415,710 3 respective data source of the first type and using the first view to display data collected therefrom; and connecting, by a computer, each instance of the first component to its respective data source such that at least some of the multiple instances are configured to retrieve data from their respective data sources in a different manner than others of the multiple instances. The issue The Examiner rejected claims 1–5 and 7–16 under 35 U.S.C. § 102(e) as anticipated by Thalhammer-Reyero3 (Ans. 4–7). The Examiner finds that Thalhammer-Reyero teaches the claimed method, and in particular, teaches “three bioObjects 302 that collect data from sources 301. The 1st BioObject 302 collects data via a 2nd input pin, different from the 3rd bioObject 302 which collects data via its 3rd input pin. Similarly, bioObjects 303 and 304 also collect data in different manners from the others as shown by the connection lines” (Ans. 9). The Examiner finds that “Figure 4 shows bioObjects 521, 526, 531 and 536, each collects data in a different manner from the others” (Ans. 9). The issue with respect to this rejection is: Does the evidence of record support the Examiner’s conclusion that Thalhammer-Reyero teaches that “multiple instances are configured to retrieve data from their respective data sources in a different manner than others of the multiple instances” as required by claims 1 and 10? Findings of Fact 1. Thalhammer-Reyero teaches “a shell environment to construct specific object-oriented, visual and interactive information, modeling and 3 Thalhammer-Reyero, C., US 5,980,096, issued Nov. 9, 1999. Appeal 2012-004332 Application 11/415,710 4 simulation systems in the chemical and biochemical domains” (Thalhammer-Reyero, col. 13, ll. 21–23). 2. Thalhammer-Reyero teaches computerizing biochemical systems to provide data representing “a powerful knowledge representation of physical chemical and biochemical entities (such as DNA, enzymes, receptors, ligands, mediators, or ions)” (Thalhammer-Reyero, col. 15, ll. 23– 25). 3. Figure 2 of Thalhammer-Reyero is reproduced below: “FIG. 2 shows as examples the subworkspaces of one such a set of generic bioReservoirs (301 and 303) and bioProcesses (302 and 304) with their encapsulated bioSchematics, to help the reader to visualize some of the basic Appeal 2012-004332 Application 11/415,710 5 types of graphical constructions and methods that are object of this invention” (Thalhammer-Reyero, col. 26, ll. 56–61). 4. Thalhammer-Reyero teaches that computer representations of biochemical pathways “may be composed with: diverse instances of subclasses of protein-component and simple-bioEntity” among other biochemical reactants (Thalhammer-Reyero, col. 75, ll. 13–15). 5. Figure 13 of Thalhammer-Reyero is reproduced below: “FIG. 13 shows the Palettes with representative examples of master instances of some of the different subclasses of protein-domain (2001), Appeal 2012-004332 Application 11/415,710 6 protein-motif (2006), and simple-bioEntity (2011), accessed through the walking menu (not shown) displayed when selecting the ‘Protein Components’ option (1817)” (Thalhammer-Reyero, col. 74, ll. 52–57). 6. Thalhammer-Reyero teaches, regarding bioEntities, “allowing their repeated use as building blocks in a variety of situations” (Thalhammer-Reyero, col. 14, ll. 28–29). 7. Thalhammer-Reyero teaches that “functional units are further broken down into operational and standardized knowledge and data structures that add flexibility and facilitate the development of generic domain-specific graphic bioObjects that the user is able to open individually to input data, modify existing bioObjects, or create new bioObjects” (Thalhammer-Reyero, col. 14, ll. 32–37). 8. Thalhammer-Reyero teaches that “objects are represented as graphic icons that can be dragged on a workspace (window) or transferred between workspaces” (Thalhammer-Reyero, col. 17, ll. 1–3). 9. Thalhammer-Reyero teaches that “attributes that define an object’s composition and behavior can be viewed and modified by clicking a dialog box and editing the text in a table” (Thalhammer-Reyero, col. 17, ll. 4–6). 10. Thalhammer-Reyero teaches that bioEntities and bioObjects have attributes which provide alternatives for “the modeler to include additional information, which in this case is specific for each instance, including copies. Clones of those instances can be combined in different ways to model, using the basic paradigm of ‘Clone, Connect and Configure’, at the desired level of detail, the structure of a bioEntity” (Thalhammer- Reyero, col. 75, ll. 7–12). Appeal 2012-004332 Application 11/415,710 7 11. Thalhammer-Reyero further teaches that each “bioEntity may have information encoded in two different ways: a) that information and data stored in its table of attributes, and b) each bioEntity may have a subworkspace upon which the components that represent its functional architecture are graphically defined” (Thalhammer-Reyero, col. 52, ll. 23– 28; FF 11). 12. Thalhammer-Reyero teaches that in “addition to the structure in the subworkspace, additional information about that instance of bioEntity can be stored in its table of attributes” (Thalhammer-Reyero, col. 53, ll. 49– 51). 13. Thalhammer-Reyero teaches “a graphical interface and associated methods that integrate data and information of different knowledge structures dispersed throughout several workspaces in the knowledge-base” (Thalhammer-Reyero, col. 18, ll. 4–8). 14. Thalhammer-Reyero teaches The class bioObject comprises all the classes of knowledge structures necessary to represent the chemical and biochemical systems characteristic of this domain. These object classes are characterized by their assigned attributes, which can be: a) simple attributes of various types, such as text, symbols, integers, floats or truth values, or b) pointers to defined text, logic, symbolic or numeric parameters, variables, list or arrays, or pointers to other objects. The classes of the objects pointed to, including the variable structures (which are also defined as objects), have to be previously defined. The values for the parameters and variables can be provided by any of a variety of sources, such as the user-inputs, on-line sensors, or dynamically by the inference engine (for instance, through specific or generic formulas, rules or procedures), or a simulator (for instance, through specific or generic simulation formulas or Appeal 2012-004332 Application 11/415,710 8 simulation procedures), reflecting the changing values of the attributes defined within the knowledge structures and in the context selected by the user. (Thalhammer-Reyero, col. 40, ll. 5–23.) Principles of Law “A single prior art reference that discloses, either expressly or inherently, each limitation of a claim invalidates that claim by anticipation.” Perricone v. Medicis Pharm. Corp., 432 F.3d 1368, 1375 (Fed. Cir. 2005). Analysis Thalhammer-Reyero teaches “a shell environment to construct specific object-oriented, visual and interactive information, modeling and simulation systems in the chemical and biochemical domains” (Thalhammer-Reyero, col. 13, ll. 21–23; FF 1). Translating this to the language of claim 1, Thalhammer-Reyero is teaching a method of generating a model, here a biochemical model, on a computer which collects, displays, and models biochemical data of entities in biological pathways (FF 3), where the data represents “a powerful knowledge representation of physical chemical and biochemical entities (such as DNA, enzymes, receptors, ligands, mediators, or ions)” (Thalhammer-Reyero, col. 15, ll. 23–25; FF 2). These biochemical entities are termed either bioEntities or bioObjects by Thalhammer-Reyero, and are computer representations which “may be composed with: diverse instances of subclasses of protein-component and simple-bioEntity” among other biochemical reactants (Thalhammer-Reyero, col. 75, ll. 13–15; FF 4). Thalhammer-Reyero teaches the first step of claim 1, generating, by a computer, a first reusable software component that collects data from a first Appeal 2012-004332 Application 11/415,710 9 type of data source (FF 5–7). Specifically, Thalhammer-Reyero teaches bioEntities and bioObjects as reusable software components on a palette with different motifs (FF 5). Here, the bioEntity and bioObject software components are representations of the proteins, and their constituent domains, which are used in the biochemical models of Thalhammer-Reyero (FF 5). Thalhammer-Reyero teaches reusability of software components such as bioEntities and bioObjects, specifically “allowing their repeated use as building blocks in a variety of situations” (Thalhammer-Reyero, col. 14, ll. 28–29; FF 6). Finally, Thalhammer-Reyero teaches that bioObjects obtain data from a first data source where “the user is able to open individually to input data, modify existing bioObjects, or create new bioObjects” (Thalhammer-Reyero, col. 14, ll. 32–37; FF 7). Thalhammer-Reyero teaches the second step of claim 1, with a first view that specifies how data collected by the first component is to be displayed (FF 8–9). Specifically, Thalhammer-Reyero teaches that bioEntities or bioObjects “are represented as graphic icons that can be dragged on a workspace (window) or transferred between workspaces” (Thalhammer-Reyero, col. 17, ll. 1–3; FF 8). Thalhammer-Reyero explains how the underlying data of a bioObject is used so that “attributes that define an object’s composition and behavior can be viewed and modified by clicking a dialog box and editing the text in a table” (Thalhammer-Reyero, col. 17, ll. 4–6; FF 9). Thalhammer-Reyero teaches the third step of claim 1, creating, by a computer, multiple instances of the first component, each such instance corresponding to a different respective data source of the first type and using the first view to display data collected therefrom (FF 10–11). Specifically, Appeal 2012-004332 Application 11/415,710 10 Thalhammer-Reyero teaches making multiple instances of bioEntities and bioObjects where “[c]lones of those instances can be combined in different ways to model, using the basic paradigm of ‘Clone, Connect and Configure’, at the desired level of detail, the structure of a bioEntity” (Thalhammer- Reyero, col. 75, ll. 7–12; FF 10). Thalhammer-Reyero further teaches that each “bioEntity may have information encoded in two different ways: a) that information and data stored in its table of attributes, and b) each bioEntity may have a subworkspace upon which the components that represent its functional architecture are graphically defined” (Thalhammer-Reyero, col. 52, ll. 23–28; FF 11). Each instance of a bioEntity therefore will rely upon a unique subworkspace, which subworkspace is reasonably interpreted as a data source of the first type used to display the graphically defined data (FF 11). Thalhammer-Reyero teaches the fourth step of claim 1, connecting, by a computer, each instance of the first component to its respective data source such that at least some of the multiple instances are configured to retrieve data from their respective data sources in a different manner than others of the multiple instances (FF 12–14). Specifically, Thalhammer-Reyero teaches that in “addition to the structure in the subworkspace, additional information about that instance of bioEntity can be stored in its table of attributes” (Thalhammer-Reyero, col. 53, ll. 49–51; FF 12). Further, Thalhammer-Reyero teaches “a graphical interface and associated methods that integrate data and information of different knowledge structures dispersed throughout several workspaces in the knowledge-base” (Thalhammer-Reyero, col. 18, ll. 4–8; FF 13). Finally, Thalhammer-Reyero clearly teaches that bioObjects or bioEntities may retrieve data from “user- Appeal 2012-004332 Application 11/415,710 11 inputs, on-line sensors, or dynamically by the inference engine (for instance, through specific or generic formulas, rules or procedures), or a simulator” (Thalhammer-Reyero, col. 40, ll. 17–19; FF 14). Appellants contend that “Tha[l]hammer-Reyero et al. do not teach or suggest that at least some of the multiple instances are configured to retrieve data from their respective data sources (of the first type) in a different manner than others of the multiple instances, as recited in claim 1” (App. Br. 5). We are not persuaded. As mentioned above, Thalhammer-Reyero clearly teaches that bioObjects or bioEntities may retrieve data from “user- inputs, on-line sensors, or dynamically by the inference engine (for instance, through specific or generic formulas, rules or procedures), or a simulator” (Thalhammer-Reyero, col. 40, ll. 17–19; FF 14). When one bioObject retrieves data from user-input and another bioObject retrieves data from on- line sensors, these multiple bioObject instances are reasonably understood as retrieving data in a “different manner” than each other (FF 14). This interpretation is particularly reasonable in this instant case, where the Specification not only lacks any definition of the phrase “different manner,” but where the phrase only appears one time in the entire Specification, in originally filed claim 1. There is no discussion in the Specification providing a limiting understanding of what constitutes a “different manner.” Conclusion of Law The evidence of record supports the Examiner’s conclusion that Thalhammer-Reyero teaches that “multiple instances are configured to retrieve data from their respective data sources in a different manner than others of the multiple instances” as required by claims 1 and 10. Appeal 2012-004332 Application 11/415,710 12 SUMMARY In summary, we affirm the rejection of claims 1 and 10 under 35 U.S.C. § 102(e) as anticipated by Thalhammer-Reyero. Pursuant to 37 C.F.R. § 41.37(c), we also affirm the rejection of claims 2–5, 7–9, and 11–16, as these claims were not argued separately. No time period for taking any subsequent action in connection with this appeal may be extended under 37 C.F.R. § 1.136(a). AFFIRMED cdc Copy with citationCopy as parenthetical citation