Ex Parte Brown et alDownload PDFPatent Trial and Appeal BoardDec 23, 201412610018 (P.T.A.B. Dec. 23, 2014) Copy Citation UNITED STATES PATENT AND TRADEMARK OFFICE ____________________ BEFORE THE PATENT TRIAL AND APPEAL BOARD ____________________ Ex parte JEREMY BROWN and SHAUN WACKERLY ____________________ Appeal 2012-007888 Application 12/610,018 Technology Center 2400 ____________________ Before CARLA M. KRIVAK, JOHN A. EVANS, and HUNG H. BUI, Administrative Patent Judges. BUI, Administrative Patent Judge. DECISION ON APPEAL Appellants1 seek our review under 35 U.S.C. § 134(a) of the Examiner’s final rejection of claims 1–21. We have jurisdiction under 35 U.S.C. § 6(b). We AFFIRM.2 1 The Real Party in Interest is Hewlett-Packard Development Company, LP. 2 Our decision refers to Appellants’ Appeal Brief filed December 6, 2011 (“App. Br.”); Reply Brief filed April 16, 2012 (“Reply Br.”); Examiner’s Answer mailed February 21, 2012 (“Ans.”); and original Specification filed October 30, 2009 (“Spec.”). App App desig autom devi sync appr co down to ea netw Acco “a fi of su eal 2012-0 lication 12 Appellan ned for im atically p ces within hronizatio opriate net Appellan Ap impleme nfiguration As show loaded in ch of its n ork for pro rding to A le containi ch setting 07888 /610,018 ST ts’ invent plementin ropagate i a peer gro n is dynam work devi ts’ Fig. 1 pellants’ F nting conf file to ot p n in Fig. 1 to a memo eighbor ne per config ppellants, ng all of th s (i.e., one ATEMEN Appella ion relates g configu ts configu up on a ne ically and ces within and Fig. 2 ig. 1 and iguration her approp eer group , a configu ry 16 of a twork dev uration sy the term “ e settings or more p 2 T OF TH nts’ Inven to a netwo ration sync ration file twork, sho continual the same are reprod Fig. 2 show synchroniz riate netw 20 on a ne ration file network d ices 10b-1 nchroniza configura for a netw arameters) E CASE tion rk device hronizatio to other ap wn in Fig ly maintai peer group uced belo a netwo ation, via ork device twork. 14 is rece evice 10, 0e within tion. Id. a tion file” i ork device ” and con , shown in n and con propriate . 2, such th ned betwe . Spec. 4 w. rk device propagatin s 10b–10e ived and and is then a peer gro t 5:18–6:1 s broadly as well a tains “info Fig. 1, figured to network at proper en all :23–27. 10 for g its within a forwarde up on the 8. defined as s a portion rmation d Appeal 2012-007888 Application 12/610,018 3 regarding the device’s protocol parameters and other communication-related information.” Id. at 6:3–5 and 9–10. Claims on Appeal Claims 1, 9, and 17 are independent claims. Representative claim 1 is reproduced below: 1. A network device for implementing configuration synchronization, comprising: a port configured to a receive a configuration file; a memory; and a processing engine; wherein said processing engine is configured such that: if a configuration file is received on said port, said processing engine determines whether said network device containing the processing engine is a member of a peer group corresponding to said configuration file and, if so, said processing engine loads said configuration file into said memory; and said processing engine forwards said configuration file to at least one neighbor device of said network device. App. Br. 21 (Claims Appendix) (disputed limitations in italics). Evidence Considered Pabla US 7,571,227 B1 Aug. 4, 2009 Sagy US 2008/0031148 A1 Feb. 7, 2008 Regale US 2007/0253432 A1 Nov. 1, 2007 Verbeke US 2004/0098447 A1 May 20, 2004 Appeal 2012-007888 Application 12/610,018 4 Examiner’s Rejections (1) Claims 1–3, 7, 9–11, 15, 18, 19, and 213 stand rejected under 35 U.S.C. § 102(e) as being anticipated by Pabla. Ans. 5–9. (2) Claims 4, 12, and 20 stand rejected under 35 U.S.C. § 103(a) as being unpatentable over Pabla and Sagy.4 Ans. 9–10. (3) Claims 5–6 and 13–14 stand rejected under 35 U.S.C. § 103(a) as being unpatentable over Pabla, Sagy, and Verbeke. Ans. 3–12. (4) Claims 8 and 16 stand rejected under 35 U.S.C. § 103(a) as being unpatentable over Pabla, Verbeke, and Regale. Ans. 3–12. Issues on Appeal Based on Appellants’ arguments, the dispositive issue on appeal is whether the Examiner erred in rejecting claims 1–3, 7, 9–11, 15, 18, 19, and 21 under 35 U.S.C. § 102(e) as being anticipated by Pabla. In particular, the appeal turns on whether Pabla discloses a network device comprising a processing engine configured such that “if a configuration file is received on said port, said processing engine determines whether said network device containing the processing engine is a member of a peer group corresponding to said configuration file and, if so, said processing engine loads said configuration file into said memory” and then “forwards said configuration file to at least one neighbor device of said network device” as recited in 3 Claim 21 was not listed but was rejected by the Examiner and confirmed by Appellants on page 8 of the Appeal Brief and, as such, has been included for purposes of completeness. See Ans. 5, 9. 4 Sagy was not listed but was relied upon by the Examiner (instead of Verbeke) and, as such, has been included for purposes of completeness. See Ans. 9–10. App App App 9 and § of a Fig. such engin engin and, eal 2012-0 lication 12 ellants’ ind 17. App 102(e) Rej Appellan compute n 9 as reprod Fig. 9 its comp ( Appellan that: (1) “ e determi e is a mem if so, said 07888 /610,018 ependent . Br. 9–16 ection of ts acknow ode compr uced belo of Pabla ute node c i.e., a mas ts contend if a config nes wheth ber of a p processing claim 1, an . AN Claims 1– ledge Pab ising a pro w. shows a n onfiguratio ter node or the proce uration fil er said net eer group engine lo 5 d similarl ALYSIS 3, 7, 9–11, Pabla la disclose cessing en etwork dev n with an a peer no ssing engi e is receiv work devi correspon ads said c y recited i 15, 18, 19 s a networ gine and ice 820 se other netw de) on a n ne of Pabl ed on said ce contain ding to sa onfiguratio n independ , and 21 b k device i a memory lf-updatin ork device etwork. a is not co port, said ing the pro id configu n file into ent claim ased on n the form shown in g 830 nfigured processing cessing ration file said s Appeal 2012-007888 Application 12/610,018 6 memory” and (2) then “forwards said configuration file to at least one neighbor device of said network device” as recited in Appellants’ independent claim 1, and similarly recited in independent claims 9 and 17. App. Br. 4–11. In particular, Appellants acknowledge: “Pabla teaches that a new node (820) sends configuration data to a second, existing node (830). The existing node (830) determines if the new node (820) is properly configured. ‘Node 830 may then determine from compute node configuration information 840 if compute node configuration 826 of compute node 820 needs to be updated.’ (Id.) If an updated is needed, the existing node, ‘node 830 may then send update information 836 to compute node 820, as indicated at 842, for example using the peer-to-peer platform protocols. Compute node 820 may then update the compute node configuration 826 in accordance with the update information.’ (Id.). The new node (820) apparently always accepts the configuration update from the existing node (830). App. Br. 10; Reply Br. 4. According to Appellants: “[T]here is absolutely no teaching in Pabla of making any determination prior to accepting a configuration file into the memory of a node that has received the configuration… After accepting the update from existing node (830), Pabla does not teach or suggest that the new node (820) then forwards the configuration file to another device.” Id. at 11 (citing Pabla 11:38-55) (emphasis added); Reply Br. 7. In response, the Examiner takes the position that: (1) existing node (830) sends update information (842) to compute node 820 that includes a peer identifier (Ans. 12); (2) Pabla clearly discloses a discover mechanism, i.e. discovery of other peers and groups, which occurs prior to data exchange Appeal 2012-007888 Application 12/610,018 7 and supports a determination of a peer group prior to receiving update information (Id. at 13 citing Pabla 2:50–55 and 3:35–38); and (3) Fig. 8 of Pabla shows a logically nearby peer (810) in updating compute node (812) which indicates that update information, i.e., configuration data can be passed on or forwarded from one node to another node (Id. at 14 citing Pabla Fig. 8). As the outset, we find Appellants’ arguments are not commensurate with scope of independent claims 9 and 17 and, as such, are unpersuasive. In particular, we note Appellants’ independent claims 9 and 17 are significantly broader than independent claim 1, and do not require any separate determination of whether a network device is a member of a peer group corresponding to a configuration file prior to loading the configuration file into its memory and then forwarding the configuration file to another network device, as Appellants argue. Nor do we find Appellants’ claims 9 and 17 define any features of Appellants’ disclosed invention that would achieve “configuration synchronization” and ensure proper synchronization dynamically and continually maintained between all appropriate network devices within the same peer group. See Spec. 4:23–27. Instead, claims 9 and 17 simply recite a network device (i.e., any type of device on a network) that receives a configuration file, loads that file into memory and then forwards the configuration file a neighbor device. For example, claim 17 recites a non-transitory computer-readable medium associated with a network device, containing instructions that, when executed, causes: receiving a configuration file by the network device which is a member of a predetermined peer group; Appeal 2012-007888 Application 12/610,018 8 loading the configuration file into a memory of the network device; and forwarding the configuration file from the network device to a neighbor device. On its face, Appellants’ claims 9 and 17 cover practically the entire classification of network and computing devices (i.e., PC or mobile devices) all of which are capable of receiving and loading a configuration file (i.e., configuration information) and forwarding the configuration file to another device, including, for example, the compute node of Pabla. As correctly found by the Examiner, for example, a compute node 830, as shown in Fig. 9 (which can be a master node 800, shown in Fig. 7, or a logically nearby peer 810, as shown in Fig. 8 of Pabla) is a member of a peer group (Pabla 2:40–50) and is described as receiving configuration information 840 (814, 840, shown in Figs. 7–8) for storage in memory 834, and then sending or forwarding update information 842 (including configuration information and any other information used to update compute node configurations on compute nodes, Pabla 11:18–26). Ans. 7-9. Turning now to independent claim 1, we note that claim 1 contains a “wherein” clause coupled with conditional limitations “if” and “if so.” First, these conditional limitations, when given their broadest reasonable interpretation consistent with the specification, are considered optional elements. “Optional elements do not narrow the claim because they can always be omitted.” See In re Johnston, 435 F.3d. 1381, 1384 (Fed. Cir. 2006). Based on such an interpretation, the Examiner is not required to find the disclosure of these conditional limitations in Pabla. See Ex Parte Gary M. Katz, 2011 WL 514314, *4 (BPAI 2011). Appeal 2012-007888 Application 12/610,018 9 Assuming arguendo that these conditional limitations are given patentable weight, which the Examiner has done, we find the preponderance of evidence supports the Examiner’s findings that Pabla teaches the underlying limitations, i.e., (1) determining whether a network device is a member of a peer group “if” a configuration file is received on its port, and (2) loading the configuration file into its memory “if” the network device is determined to be a member of a peer group, in the form of “peer-to-peer platform protocols and discovery mechanism” used to automatically configure compute nodes. Ans. 13 (citing Pabla 2:50–55, 3:35–38). For example, Pabla teaches that, when a new compute node (network device) is deployed or installed on a network, a master node 800, shown in Fig. 7, or a logically nearby peer 810, as shown in Fig. 8 of Pabla (a member of a peer group) is notified about a presence of the new compute node and is provided with configuration information received from the new compute node. Pabla 6:28–57. Once discovery is completed, the master node 800 or the logically nearby peer 810 can proceed to send or forward update information (including configuration information and any other information used to update compute node configurations on compute nodes, Pabla 11:18–26), as correctly found by the Examiner. Ans. 14 (citing Pabla Fig. 8). For the reasons set forth above, we find no reversible error in the Examiner’s position and, as such, sustain the Examiner’s anticipation rejection of Appellants’ independent claims 1, 9, and 17. With respect to dependent claims 3, 7, 10–11, 15, 18, and 19, Appellants present no separate patentability arguments. For the same reasons discussed, we also sustain the Examiner’s anticipation rejection of claims 3, 7, 10–11, 15, 18, and 19. Appeal 2012-007888 Application 12/610,018 10 With respect to dependent claim 21, Appellants argue the Examiner has not addressed how the limitation “said processing engine is configured to listen for said configuration file” is anticipated by Pabla. App. Br. 15–16. The Examiner responds that limitation is met as a part of self-updating. Ans. 14. We agree with the Examiner and see no error in the Examiner’s position and, as such, sustain the Examiner’s anticipation rejection of claim 21. § 103(a) Rejection of Claims 4, 12, and 20 based on Pabla and Sagy. Claims 4, 12, and 20 further recite that “the configuration file includes a protocol parameter and wherein the peer group represents a group of network devices each requiring the same protocol parameter to facilitate effective communication.” Appellants allege nowhere in Sagy is there disclosure of incorporating a protocol parameter in a configuration file. App. Br. 17. Such a skeletal argument as offered here is not an argument in support of separate patentability pursuant to 37 C.F.R. §41.37(c)(1)(vii) and, therefore, need not be addressed. In re Lovin, 652 F.3d 1349, 1356-57 (Fed. Cir. 2011). Even if Appellants’ sole argument regarding claims 4, 12, and 20 is an argument in support of separate patentability, we still find it unavailing because Appellant fails to dispute the Examiner’s finding that Sagy teaches protocol parameters used in peer-to-peer protocols as disclosed by Pabla. Ans. 15. Moreover, Pabla also teaches using peer-to-peer protocols which allow compute nodes (network devices) on a network to communicate and update configuration information in a peer-to-peer (P2P) manner and these compute nodes (network devices) belong to a peer group. Pabla 2:37–54. As such, Appeal 2012-007888 Application 12/610,018 11 Sagy is not necessary for disclosing the features recited in claims 4, 12, and 20. For the reasons set forth above, Appellants have not persuaded us of error in the Examiner’s rejection of claims 4, 12, and 20. Accordingly, we sustain the Examiner’s obviousness rejection of Appellants’ claims 4, 12, and 20. With respect to dependent claims 5–6, 8, 13–14, and 16, we are not persuaded by Appellants’ arguments and adopt as our own (1) the Examiner’s findings and explanations provided on pages 11–12 of the Examiner’s Answer. CONCLUSION On the record before us, we conclude the Examiner has not erred in rejecting claims 1–21 under 35 U.S.C. § 103(a). DECISION As such, we AFFIRM the Examiner’s final rejection of claims 1–21.5 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). 5 In the event of further prosecution, we suggest the Examiner evaluate Appellants’ independent claims 1, 9, and 17 for compliance with 35 U.S.C. § 112, 1st and 2nd paragraphs. For example, claims 1 and 9 define a method of implementing configuration synchronization in a network device (i.e., any type of device on a network) that receives a configuration file and forwards the configuration file another device. None of these steps would achieve Appellants’ claimed “configuration synchronization” and the purpose of ensuring proper synchronization dynamically and continually maintained between all appropriate network devices within the same peer group as disclosed by Appellants’ Specification. See Spec. 4:23–27. Appeal 2012-007888 Application 12/610,018 12 AFFIRMED Copy with citationCopy as parenthetical citation