Ex Parte Leizerovich et alDownload PDFPatent Trial and Appeal BoardDec 29, 201613535913 (P.T.A.B. Dec. 29, 2016) 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. 13/535,913 06/28/2012 Maxim Leizerovich 82976942 7125 56436 7590 Hewlett Packard Enterprise 3404 E. Harmony Road Mail Stop 79 Fort Collins, CO 80528 EXAMINER RIVERA, ANIBAL ART UNIT PAPER NUMBER 2192 NOTIFICATION DATE DELIVERY MODE 01/03/2017 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): hpe.ip.mail@hpe.com chris. mania @ hpe. com PTOL-90A (Rev. 04/07) UNITED STATES PATENT AND TRADEMARK OFFICE BEFORE THE PATENT TRIAL AND APPEAL BOARD Ex parte MAXIM LEIZEROVICH and ILAN MEIRMAN Appeal 2015-006219 Application 13/535,913 Technology Center 2100 Before JOHN A. JEFFERY, LARRY J. HUME, and MATTHEW J. McNEILL, Administrative Patent Judges. JEFFERY, Administrative Patent Judge. DECISION ON APPEAL Appellants appeal under 35 U.S.C. § 134(a) from the Examiner’s decision to reject claims 1—20. We have jurisdiction under 35 U.S.C. § 6(b). We affirm. STATEMENT OF THE CASE Appellants’ disclosed invention generates test data for form validation by (1) maintaining metadata for a database; (2) mapping a control field of a form to a database column; and (3) generating test data based on the mapping and metadata. See generally Abstract. Appeal 2015-006219 Application 13/535,913 Claim 1 is illustrative: 1. A method comprising: maintaining column metadata for a database; mapping a control field of a form to a column of the database; and automatically generating, by a processor, test data for testing the form based on the mapping and the column metadata. THE REJECTIONS The Examiner rejected claims 1—3, 7, 8, and 10-17 under 35 U.S.C. § 102(b) as anticipated by Kristiansen (US 2006/0026506 Al; Feb. 2, 2006). Final Act. 2—5.1 The Examiner rejected claims 4—6, 9, and 18—20 under 35 U.S.C. § 103(a) as unpatentable over Kristiansen and Desgrousilliers (US 5,715,373; Feb. 3, 1998). Final Act. 6-7. THE ANTICIPATION REJECTION The Examiner finds that Kristiansen (1) maintains column metadata for a database; (2) maps a control field of a form to a database column associated with the “ID,” “Name,” “BaseRate,” and “ShipRate” properties in Figures 3—2 and 7; and (3) automatically generates test data for testing the form based on the mapping and column metadata via data provided by, among other things, test scripts. Final Act. 2—3; Ans. 4—9. Appellants argue that Kristiansen is silent regarding a column, let alone maintaining column metadata for a database. App. Br. 6; Reply 1 Throughout this opinion, we refer to (1) the Final Rejection mailed August 15, 2014 (“Final Act.”); (2) the Appeal Brief filed January 12, 2015 (“App. Br.”); (3) the Examiner’s Answer mailed March 30, 2015 (“Ans.”); and (4) the Reply Brief filed June 1, 2015 (“Reply Br.”). 2 Appeal 2015-006219 Application 13/535,913 Br. \-A. According to Appellants, Kristiansen’s form definitions, maps, and business models associated with various modeled entities disclose metadata for a database, but do not disclose column metadata for a database. Id. Appellants add that Kristiansen also does not automatically generate form test data based on the recited mapping and metadata, but rather provides test data by entering that data directly into a logical layer model. App. Br. 6—9; Reply Br. 4—6. Appellants add that even if Kristiansen’s test scripts automatically generate form test data, this generation is not based on the recited mapping and metadata. App. Br. 8. Appellants argue various other recited limitations summarized below. ISSUES Under § 102, has the Examiner erred by finding that Kristiansen: (1) (a) maintains column metadata for a database, and (b) automatically generates, by a processor, form test data based on the mapping and metadata recited in claim 1 ? (2) receives user input for associating the database column to the form’s control field as recited in claim 2? (3) generates test scripts based on the test data as recited in claim 7? ANALYSIS Claims 1, 3, 8, 11—15, and 17 We begin by construing the key disputed limitation of claim 1 which recites, in pertinent part, “column metadata.” Appellants’ Specification does not define the term, but does note that database metadata may include column metadata such as field type, maximum length, mandatory field(s), relationships to other columns, and other column constraints or rules. Spec. 3 Appeal 2015-006219 Application 13/535,913 111. Our emphasis underscores that these forms of column metadata are merely exemplary. So while this description informs our construction of the term “column metadata,” it does not limit our interpretation. As is known in the art, metadata is simply data about data. Microsoft Computer Dictionary 336 (5th ed. 2002). Moreover, the term “database” is defined quite broadly as “[a]ny electronically-stored collection of data.” Alan Freedman, The Computer Glossary 86 (9th ed. 2001). Accord In re Comiskey, 554 F.3d 967, 981 (Fed. Cir. 2009) (citing this definition from an earlier edition). Therefore, under its broadest reasonable interpretation, “column metadata” is simply data about a column for an electronically-stored data collection. With this construction, we see no error in the Examiner’s finding that data associated with entities 381 to 384 and their properties in Kristiansen’s Figure 3-1, including data associated with the “Ship Method” entity and properties in Figure 3-2, 5, and 6, shows column metadata, namely data about a column for an electronically-stored data collection. See Ans. 5 (citing these figures). Notably, entities 381 to 384 and their properties are shown in Kristiansen’s Figure 3-1 as four separate tables, each with two rows and a single column, and data associated with the “Ship Method” entity and properties column is mapped to respective form control fields in user interface model 390 in Figure 3-2. See Kristiansen || 45, 50. In short, this column metadata is maintained for a database, namely an electronically- stored data collection, under the term’s plain meaning. That the entities’ properties in Figures 3-1 and 3-2 are consistent with field types—one of the exemplary forms of column metadata in paragraph 11 of the Specification— only further bolsters the Examiner’s finding that these elements constitute 4 Appeal 2015-006219 Application 13/535,913 column metadata. Moreover, Appellants’ contention that a form with columns does not does not necessarily require maintaining column metadata for a database in light of the various cited examples in that regard (Reply Br. 4) is unavailing and not commensurate with the scope of the limitation. We also see no error in the Examiner’s finding that a processor in Kristiansen automatically generates test data for testing a form based on the mapping and column metadata via data provided by test scripts. Final Act. 2—3; Ans. 4—9. Our emphasis underscores that although Kristiansen’s test module 640 and associated scripts 645 in Figure 6 automatically provide data to the logical layer 625 for testing as noted in paragraph 70, Kristiansen does not state explicitly that this data is automatically generated as Appellants indicate. App. Br. 7—8; Reply Br. 5—6. Nevertheless, we see no error in the Examiner’s findings in this regard given the scope and breadth of the term “generating” which is not defined in the Specification and, therefore, is construed with its plain meaning. The term “generate” is defined as either “bring into being” or, alternatively, as “produce.” HarperCollins Compact Dictionary & Thesaurus 322 (2003). Given these broad definitions, and even assuming, without deciding, that Kristiansen’s test data provided to the logical layer in Kristiansen’s Figure 6 pre-exists in the test module such that the data is not originally generated by that module, this data is nonetheless produced with respect to the logical layer when the data is so provided. That is, because the test data did not previously exist in the logical layer, the data is effectively automatically produced or brought into being (i.e., automatically generated) with respect to that layer when the test module provides data to that layer. Despite Appellants’ arguments to the contrary (App. Br. 8; Reply Br. 6), this 5 Appeal 2015-006219 Application 13/535,913 automatic generation of test data would be at least partly based on the mapping and column metadata given the form definitions and maps in database 610 which is associated with the logical layer 625 as shown by the arrow between these elements in Figure 6, and column metadata associated with at least the “Ship Method” entity and properties in Figures 5 to 7. In addition, the very act of recording the test data provided to the logical layer to develop test scripts in paragraphs 74 and 75 would automatically generate test data for testing the form, namely by automatically generating a copy of the test data provided to the logical layer—an automatic generation that would be based at least partly on the recited mapping and column metadata as noted above. Therefore, we are not persuaded that the Examiner erred in rejecting claim 1, and claims 3, 8, 11—15, and 17 not argued separately with particularity. Claims 2 and 16 We also sustain the Examiner’s rejection of claim 2 reciting that the mapping comprises receiving user input for associating the database column to the form’s control field. Our emphasis underscores that the claim does not require that received user input actually associate the column with the field, but rather that the input is for such an association—an intended use of the recited user input. So to the extent that Appellants contend that Kristiansen’s user input does not perform the recited association (See App. Br. 9), such an argument is not commensurate with the scope of the claim which does not require such an association. Nevertheless, we see no error in the Examiner’s reliance on the user input associated with Kristiansen’s model-based mapping system (Final 6 Appeal 2015-006219 Application 13/535,913 Act. 3; Ans. 9—10), where this input would at least be capable of associating a database column to a form control field, particularly given Kristiansen’s column-based mapping functionality noted previously. Appellants’ contention that Kristiansen lacks a database column (Reply Br. 6—7) is unavailing for the reasons previously discussed. Therefore, we are not persuaded that the Examiner erred in rejecting claim 2, and claim 16 not argued separately with particularity. Claims 7 and 10 We also sustain the Examiner’s rejection of claim 7 reciting, in pertinent part, generating test scripts based on the test data that, under the terms of claim 1, is automatically generated based on the recited mapping and column metadata. Despite Appellants’ arguments to the contrary (App. Br. 10; Reply Br. 7), we see no error in the Examiner’s reliance on the data recorded by recorder 650, namely test data provided to the logical layer 625, that is used to develop test scripts manually or automatically. Final Act. 3; Ans. 10—11; Kristiansen H 70, 73—75. Appellants’ contention that Kristiansen is silent regarding how Kristiansen’s recorded operating data is generated, let alone that such a generation is based on the recited mapping and column metadata (Reply Br. 7), is unavailing and not commensurate with the scope of the claim for the reasons previously discussed. As noted in Kristiansen’s paragraphs 74 and 75, the data that is recorded and used to generate the test scripts is data that is provided to the logical layer—data that is automatically generated based on the recited mapping and column metadata as noted previously. Therefore, we are not persuaded that the Examiner erred in rejecting claim 7, and claim 10 not argued separately with particularity. 7 Appeal 2015-006219 Application 13/535,913 THE OBVIOUSNESS REJECTION We also sustain the Examiner’s obviousness rejection of claim 5 over Kristiansen and Desgrousilliers. Final Act. 6. Claim 5 depends from claim 4 which recites generating at least one of {1) negative test data, and (2) data for inter-field logic validation. Claim 5 further recites that the inter field logic validation test data comprises test data for validating relationships between multiple combo fields of the form. Our emphasis underscores that the “at least one of’ language of claim 4 means that only one of the two recited forms of test data need be taught or suggested by the cited prior art to satisfy the claim. Notably, claim 5 further limits only one of those alternatives, namely inter-field logic validation test data, but does not further limit the negative test data alternative. This distinction is significant, for the Examiner addresses only the negative test data alternative in the rejection of claim 4—not the inter-field logic validation test data alternative. See Final Act. 6. Notably, Appellants do not persuasively rebut the Examiner’s findings and conclusions in this regard apart from alleging that Desgrousilliers does not cure Kristiansen’s previously-noted deficiencies with respect to claim 1 (App. Br. 11)— arguments that we find unpersuasive for the reasons previously discussed. So even if we were to accept Appellants’ contention that the cited prior art does not teach or suggest the particular aspects of the inter-field logic validation test data recited in claim 5 (App. Br. 11—12; Reply Br. 8), Appellants still do not squarely address—let alone persuasively rebut—the Examiner’s findings and conclusions regarding the other recited alternative of claims 4 and 5, namely the negative test data alternative. We reach a 8 Appeal 2015-006219 Application 13/535,913 similar conclusion regarding the Examiner’s rejection of claim 19 which recites commensurate limitations. Therefore, we are not persuaded that the Examiner’s obviousness rejection of claims 4—6, 9, and 18—20 is erroneous. CONCLUSION The Examiner did not err in rejecting (1) claims 1—3, 7, 8, and 10—17 under § 102, and (2) claims 4—6, 9, and 18—20 under § 103. DECISION The Examiner’s decision rejecting claims 1—20 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)(l)(iv). AFFIRMED 9 Copy with citationCopy as parenthetical citation