Ex Parte AssarpourDownload PDFPatent Trial and Appeal BoardFeb 5, 201813628358 (P.T.A.B. Feb. 5, 2018) 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/628,358 09/27/2012 Hamid Assarpour 112636-2090-101 6166 1473 7590 Haley Guiliano LLP 75 Broad Street Suite 1000 NEW YORK, NY 10004 EXAMINER WILLIAMS, ELTON S ART UNIT PAPER NUMBER 2465 NOTIFICATION DATE DELIVERY MODE 02/07/2018 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): haleyguiliano_PAIR @ firsttofile. com HGPatentDocket @ hglaw. com DocketRequests @ hglaw. com PTOL-90A (Rev. 04/07) UNITED STATES PATENT AND TRADEMARK OFFICE BEFORE THE PATENT TRIAL AND APPEAL BOARD Ex parte HAMID ASSARPOUR Appeal 2016-001370 Application 13/628,358 Technology Center 2400 Before DENISE M. POTHIER, JEFFERY S. SMITH, and JOSEPH LENTIVECH, Administrative Patent Judges. POTHIER, Administrative Patent Judge. DECISION ON APPEAL STATEMENT OF THE CASE Appellant1 appeals under 35 U.S.C. § 134(a) from the Examiner’s rejection of claims 1-3, 5-13, and 15-19. Claims 4 and 14 have been cancelled. App. Br. I.2 We have jurisdiction under 35 U.S.C. § 6(b). We affirm in part. 1 The real party in interest is listed as Avaya, Inc. App. Br. 1. 2 Throughout this opinion, we refer to (1) the Final Action (“Final Act.”) mailed October 28, 2014, (2) the Advisory Action (“Adv. Act.”) mailed April 17, 2015, (3) the Appeal Brief (“App. Br.”) filed June 9, 2015, (4) the Examiner’s Answer (“Ans.”) mailed September 18, 2015, and (5) the Reply Brief (“Reply Br.”) filed November 11, 2015. Appeal 2016-001370 Application 13/628,358 Invention Appellant’s invention relates to network elements (e.g., switches, nodes, router or other devices 12 in Figure 1) and how data traffic should be handled by network elements. See Spec. 2-6, Fig. 1. A self-adapting driver (e.g., 28) can be used to abstract and control data plane hardware. See id. 1, 7-8, 20-21, Figs. 2-3. In one embodiment, an API (application programming interface) has a small instruction set, enabling SET, GET, and EVENT actions to be implemented on virtual tables. See id. ^ 21. In this scenario, changes to the hardware’s functionality do not require changes to (1) the API or (2) the application level. Id. Independent claims 1 and 19 are reproduced below: 1. A method of implementing a self adapting driver for controlling datapath hardware elements of a network element, the method comprising the steps of: providing a virtual table schema definition; parsing the virtual table schema definition to specify a configuration library containing a set of data structures defining a mapping between a set of virtual tables and a set of physical tables used by the datapath hardware elements of the network element to make forwarding decisions for packets of data being transported on a communication network, and to specify a set of functions to be used to access the data structures; [and] using a generic driver to access the data structures via the set of functions to map data from records in the virtual tables to records in the physical tables. 19. A method of generating a driver to be used to program forwarding tables of a data plane of a network element, the method comprising the steps of: specifying a mapping function between a set of virtual tables accessible by applications running on the network element and a set of datapath hardware tables implementing the forwarding tables of the data plane of the network element, the 2 Appeal 2016-001370 Application 13/628,358 datapath hardware tables being used by a forwarding function to make forwarding decisions for packets of data being transported on a communication network; and using a configuration language defining the meaning of information stored in the virtual tables by the mapping function to correlate information from the virtual tables with fields of the datapath hardware tables. App. Br. 22, 24 (Claims App’x). The Examiner relies on the following as evidence of unpatentability: Tabbara Rathinam Koponen Casado US 6,460,043 B1 Oct. 1,2002 US 2011/0145210 A1 June 16, 2011 US 2012/0120964 A1 May 17, 2012 US 2013/0044751 A1 Feb. 21,2013 The Rejections Claim 19 is rejected under 35 U.S.C. § 103(a) (pre-AIA) as unpatentable over Koponen and Casado. Final Act. 3—4. Claims 1-3, 5-7, 9-13, 15,3 17, and 18 are rejected under 35 U.S.C. § 103(a) (pre-AIA) as unpatentable over Koponen, Tabbara, and Casado. Final Act. 4-12. Claims 8 and 16 is rejected under 35 U.S.C. § 103(a) as unpatentable over Koponen, Tabbara, Casado, and Rathinam. Final Act. 12-14.4 OBVIOUSNESS REJECTION OVER KOPONEN AND CASADO Regarding independent claim 19, the Examiner finds that Koponen teaches many of its limitations, including a method of generating a driver as 3 As noted above, claims 4 and 14 have been cancelled. 4 The rejection of claim 19 based on35U.S.C. § 112, 2 (pre-AIA) (Final Act. 2) has been withdrawn. Adv. Act. 1, Box 5. 3 Appeal 2016-001370 Application 13/628,358 recited in the preamble. Final Act. 3—4 (citing Koponen 36-37, 125-26, 400, Figs. 5, 13). Appellant argues that Koponen fails to teach the recited “driver.” App. Br. 10-13; Reply Br. 4-6. ISSUE Under § 103(a), has the Examiner erred in rejecting claim 19 by finding that Koponen and Casado collectively would have taught or suggested “[a] method of generating a driver to be used to program forwarding tables of a data plane of a network element” as recited? ANALYSIS Appellant does not argue that Koponen and Casado fail to teach any of the limitations in the body of claim 19. App. Br. 10-13. As such, given the record, Koponen and Casado render the undisputed method steps in the body of claim 19 obvious. Final Act. 3-4 (citing Koponen 36-37, 125— 26, 400, Figs. 5, 13 and Casado ^ 70); Ans. 4 (citing Koponen ^[11, 93). We thus confine our discussion to whether Koponen teaches a “driver.” The key disputed limitation of claim 19 recites “[a] method of generating a driver to be used to program forwarding tables of a data plane of a network element” in its preamble. Concerning this preamble, “[wjhile there is no simple test for determining when a preamble limits claim scope, . . . [there are] some general principles to guide that inquiry.” Am. Med. Systems, Inc. v. Biolitec, Inc., 618 F.2d 1354, 1358 (Fed. Circ. 2010) (citation omitted). “[T]he preamble may be construed as limiting ‘if it recites essential structure or steps, or if it is ‘necessary to give life, meaning, and vitality’ to the claim.’” Id. (citation omitted). Conversely, a “preamble 4 Appeal 2016-001370 Application 13/628,358 is not regarded as limiting, however, ‘when the claim body describes a structurally complete invention such that deletion of the preamble phrase does not affect the structure or steps of the claimed invention.’” Id. (citation omitted). In the case of claim 19, the term “driver” is in the preamble but not the claim’s body. That is, the preamble’s phrase “generating a driver” merely states the intended use of the claim and has not been shown to be necessary to give meaning to the claim. Because the recited “driver” has not been shown to be necessary to give meaning to claim 19, such a driver does not serve to distinguish the method patentably.5 For this reason, Appellant’s argument related to Koponen failing to teach a driver6 (App. Br. 10-13) or more specifically a “self-adapting driver” (App. Br. 10) are not persuasive. Moreover, any argument related to how the driver is implemented or any implied argument that a driver requires a direct communication between 5 In contrast, the phrase “forwarding tables of a data plane of a network element” in the preamble is also located in the claim’s body (e.g., “implementing the forwarding tables of the data plane of the network element” (App. Br. 24 (Claims App’x))) and is necessary to give meaning to claim 19. 6 Appellant contends a “driver” is defined in the Specification. App. Br. 11 (quoting Spec. ^ 7). We disagree. Rather, this sentence explains how a driver is “used” and what the driver “provides.” Spec. ^ 7. The Examiner definition of a “driver” (Final Act. 3 (stating “[a] driver being software that communicates with hardware connected to a computer” (italics omitted)) is one reasonable definition of a “driver.” For example, the Microsoft Computer Dictionary, 5th edition, defines “driver” to include “[a] software driver [that] is a device-specific control program that enables a computer to work with a particular device, such as a printer or a disk drive.” 5 Appeal 2016-001370 Application 13/628,358 software and hardware elements is not required by claim 19. See App. Br. 11-13; Reply Br. 1^1. We therefore interpret the phrase “generating a driver” in the preamble as a statement of intended use or intended effect of the recited method steps. Appellant indicates that “some sort of driver is used to implement [Koponen’s] process” (App. Br. 13), illustrating Koponen’s teachings have the net intended effect of generating a driver. Similarly, the Examiner determines Koponen “describes logical datapath sets that logically express desired forwarding behaviors that are to be implemented by a set of managed switching elements” or are capable of generating a driver as broadly recited. See Ans. 4 (citing Koponen 11, 93 and discussing control logic 125 and forwarding logic 130); see also Koponen, Fig. 13 (having dotted arrows between table entries in NIB 1355 and switching element S2). Lastly, Appellant states the internal logic of Koponen’s switching element contains a driver, thus further illustrating Koponen’s process is capable of generating a driver. Reply Br. 3 (discussing Koponen 96-97).7 These examples illustrate that Koponen’s process behaves as a driver or has the intended effect of “generating a driver to be used to program forwarding tables,” as recited in claim 19’s preamble. Lastly, even assuming, without agreeing that, the preamble’s “generating a driver” limitation is limiting, the record has sufficiently explained how Koponen teaches and suggests “generating a driver” as recited. We refer above for more details. Furthermore, Casado, when 7 Koponen discusses the internal logic converts entries in a control table to populate a forwarding table, and the forwarding tables are executed by the switching element’s switching chip, routing data packets. Koponen 97. 6 Appeal 2016-001370 Application 13/628,358 combined with Koponen, has been cited to teach and suggest that one skilled in the art would have known to implement logical datapaths to forward data packets on a communication network or further contributes to a driver function used to forward data packets to a network. See Final Act. 4 (citing Casado ^ 70). For the foregoing reasons, Appellant has not persuaded us of error in the rejection of independent claim 19. OBVIOUSNESS REJECTION OVER KOPONEN, TABBARA, AND CASADO Regarding independent claim 1, the Examiner finds Koponen teaches the step of “using a generic driver” but not the steps of “providing a virtual table schema definition” or “parsing the virtual table schema definition to specify a configuration library containing a set of data structures defining a mapping between a set of virtual tables and a set of physical tables, and to specify a set of functions to be used to access the data structures.” Final Act. 4-5. The Examiner turns to Tabbara to teach these latter limitations and to modify Koponen to include these limitations and yield the recited “providing” and “parsing” steps. Id. at 5-6 (citing Tabbara 9:40-65). Among other arguments, Appellant asserts Tabbara provides an interface to data and “the SQL database causes the data associated with the database to be stored in underlying storage,” but fails to teach a mapping between virtual tables and physical tables as recited in the “parsing” step. App. Br. 14. Appellant also argues Koponen and Tabbara as proposed would not result in the claimed “mapping” or “driver.” Id. at 14-15. 7 Appeal 2016-001370 Application 13/628,358 ISSUE Under § 103(a), has the Examiner erred in rejecting claim 1 by finding Koponen, Tabbara, and Casado collectively would have taught or suggested parsing the virtual table schema definition to specify a configuration library containing a set of data structures defining a mapping between a set of virtual tables and a set of physical tables used by the datapath hardware elements of the network element to make forwarding decisions for packets of data being transported on a communication network as recited? ANALYSIS Based on the record before us, we agree with Appellant that the proposed combination of Koponen and Tabbara fails to teach or suggest the recited “parsing” step. Tabbara teaches CQL (conceptual query language) supports a number of database commands and functions to retrieve rows from a database, add new Objects to the database, and change data in Objects. Tabbara 9:40-50. Tabbara further discusses ORM (object relational model) modeling, which involves a data structure (e.g., a data dictionary file (DDF)) that maps elements of an ORM to a physical schema. Id. at 9:50-65. Tabbara states Figures 6A-16 diagrammatically illustrate in table form the contents of the data structure but does not discuss how the ORM is structured or organized. See id. at 9:63-65. Granted, Tabbara discusses the ORM as “an abstract, conceptual schema 67” {id. at 7:13-14; see also Final Act. 6 (identifying the conceptual model as a virtual table)) but there is no discussion that this schema is organized as tables — let alone “virtual tables” as recited. Tabbara 8 Appeal 2016-001370 Application 13/628,358 describes an ORM diagram having predicates presented by roleboxes/objects rather than “a set of virtual tables” as recited. Id. at 7:55-60, Fig. 4B. The referenced figures (id. at 9:63-65) in Tabbara also do not show adequately the ORM being mapped to the physical schema as recited. Id., Figs. 6A-16. Figures 11A-E address the physical mapping and mapping rules. Id., Figs. 11A-E. Nevertheless, none of the figure discuss a mapping between virtual tables and physical tables. Id. Nor has the Examiner sufficiently explained how Tabbara’s conceptual schema suggests the recited “set of virtual tables” and further the recited “mapping between a set of virtual tables and a set of physical tables.” Final Act. 5-6; see also Ans. 5 (addressing whether Tabbara is analogous art). Also, modifying Koponen with Tabbara’s technique discussed above would have resulted in an ORM element-to-physical schema mapping and any driver or datapath hardware elements would use Tabbara’s—not Koponen’s—taught mapping. See Final Act. 5-6. That is, the record does not sufficiently explain how modifying Koponen’s control application, virtualization application, and network operating system (NOS), which includes the recited “driver” (see Final Act. 5), with Tabbara’s conceptual schema-to-physical schema mapping (Final Act. 5-6) would result in “defining a mapping between a set of virtual tables and a set of physical tables” or using the recited “driver ... to map from the virtual tables to records in the physical tables” as recited in claim 19 and as argued. See App. Br. 14-16. Moreover, although Casado is relied upon to teach an ordinary artisan would have recognized using datapath hardware elements to make forwarding decision for packets, Casado is not cited to cure the above-noted deficiencies related to the recited mapping. See Final Act. 6. 9 Appeal 2016-001370 Application 13/628,358 For the foregoing reasons, Appellant has persuaded us of error in the rejection of (1) independent claim 1, (2) independent claim 11, which recite commensurate limitations, and (3) dependent claims 2, 3, 5-7, 9, 10, 12, 13, 15, 17, and 18 for similar reasons. THE REMAINING OBVIOUSNESS REJECTION Claims 8 and 16 depend from claims 1 and 11 respectively and are rejected under 35 U.S.C. § 103(a) (pre-AIA) as unpatentable over Koponen, Tabbara, Casado, and Rathinam. Final Act. 12-14. Rathinam has not been relied upon to teach the above-noted deficiencies. See id. 12-13. We thus will not sustain the rejection of claims 8 and 16 for the same reasons previously discussed. DECISION We affirm the Examiner’s rejection of claim 19 under 35 U.S.C. § 103(a) (pre-AIA). We reverse the Examiner’s rejections of claims 1-3, 5-13, and 16-18 under 35 U.S.C. § 103(a) (pre-AIA). 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 IN PART 10 Copy with citationCopy as parenthetical citation