Ex Parte Abraham et alDownload PDFPatent Trial and Appeal BoardJan 22, 201812705508 (P.T.A.B. Jan. 22, 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. 12/705,508 02/12/2010 Vineet M. Abraham BRCD-l 12-0422US 8630 73257 7590 01/24/2018 PVF — Brocade Communications Systems Inc. c/o PARK, VAUGHAN, FLEMING & DOWLER LLP 2820 Fifth Street Davis, CA 95618 EXAMINER NGUYEN, ANGELA ART UNIT PAPER NUMBER 2442 NOTIFICATION DATE DELIVERY MODE 01/24/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): sy_incoming @parklegal.com PTOL-90A (Rev. 04/07) UNITED STATES PATENT AND TRADEMARK OFFICE BEFORE THE PATENT TRIAL AND APPEAL BOARD Ex parte VINEET M. ABRAHAM, SATHISH K. GNANASEKARAN, and QINGYUAN MA Appeal 2017-009187 Application 12/705,5081 Technology Center 2400 Before TERRENCE W. McMILLIN, KARA L. SZPONDOWSKI, and SCOTT B. HOWARD, Administrative Patent Judges. McMILLIN, Administrative Patent Judge. DECISION ON APPEAL This is a decision on appeal under 35 U.S.C. § 134(a) of the final rejection of claims 1—20. Final Act. 1. We have jurisdiction under 35 U.S.C. § 6(b). We AFFIRM. 1 According to Appellants, Brocade Communications Systems, Inc. is the real party in interest. App. Br. 1. Appeal 2017-009187 Application 12/705,508 THE CLAIMED INVENTION The present invention generally relates to “network management,” and more particularly to “a method and system for monitoring data flows in a network.” Spec. 12. Independent claim 1 is directed to a switch; independent claim 7 is directed to a method; independent claim 13 is directed to a switching means; and independent claim 16 is directed to a network. App. Br. 18—21. Claim 1 recites (emphasis added): 1. A switch, comprising: a storage device configured to store a counter indicating a volume of data transfer of a data flow identified by a flow identifier, wherein the flow identifier includes a host identifier of a host, a target device identifier of a target device, and a logical unit identifier of a logical unit residing on the target device; and a traffic monitoring module configured to: monitor the data flow based on the flow identifier; and update the counter based on a read or write command in response to detecting the command in a payload of a data frame belonging to the data flow, and a communication module configured to determine an egress port for reporting a value of the counter to a traffic management module. REJECTIONS ON APPEAL Claims 1, 2, 4, 5, 7, 8, 10, 13, and 14 stand rejected under 35 U.S.C. § 102(b) as anticipated by Chandrasekaran (US 2006/0227776 Al, published Oct. 12, 2006). Final Act. 3. 2 Appeal 2017-009187 Application 12/705,508 Claims 3, 6, 9, 11, 12, and 15 stand rejected under 35 U.S.C. § 103(a) as being unpatentable over Chandrasekaran and Barrett et al. (US 2009/0259749 Al, published Oct. 15, 2009) (“Barrett”). Final Act. 5. Claims 16—18 and 20 stand rejected under 35 U.S.C. § 103(a) as being unpatentable over Chandrasekaran and Wu et al. (US 2002/0176417 Al, published Nov. 28, 2002) (“Wu”). Final Act. 6.2 Claim 19 stands rejected under 35 U.S.C. § 103(a) as being unpatentable over Chandrasekaran, Kanda (US 2009/0116381 Al, published May 7, 2009), and Barrett. Final Act. 7. ANALYSIS Claims 1, 4, 7, 10, and 13 Claim 1 recites “a counter indicating a volume of data transfer of a data flow identified by a flow identifier.” Appellants contend Chandrasekaran’s I/O Total Count and I/O Total Block Count “merely count the total number of I/O operations and the total number of data blocks transferred” but do “not represent a transfer data length” and thereby “do not indicate ‘a counter indicating a volume of a data transfer of a data flow.’” App. Br. 7—8; Reply Br. 7—8. We agree with the Examiner’s findings that the claim requires a count which indicates a volume of a data transfer, without specifying the metric by which the claimed volume is measured, and that Chandrasekaran’s I/O Total Count and I/O Total Block Count teaches the claimed counter indicating a number of 2 The Examiner’s statement of rejection in the Final Action incorrectly identifies the reference as Kanda. Final Act. 6. However, Appellants correctly identify the reference is Wu. App. Br. 10. The Examiner properly cites to Wu in the Examiner’s Answer. Ans. 4. 3 Appeal 2017-009187 Application 12/705,508 data blocks transferred. Ans. 2; see Final Act. 3 (citing Chandrasekaran 11 50-60). Appellants’ Specification provides broad examples for the command descriptor block including “the target LUN, the logical block addressing (which indicates the logical address at which the write operation occurs), and a transfer data length.” Spec. 138. Appellants do not provide any limiting definition for a “volume of data,” nor do Appellants liken a “volume of data” to a “transfer data length” or provide a limiting definition for a “transfer data length.” Instead, the claimed “volume of data” indicated by the counter, in light of Appellants’ Specification, broadly encompasses an amount of data transferred. As cited by the Examiner (Final Act. 3), Chandrasekaran teaches a “wide variety of statistics” stored including “read statistics” such as I/O Total Count and I/O Total Block Count and “write statistics” such as I/O Total Count and I/O Total Block Count. Chandrasekaran || 50—51, 54, 60- 61,64. As such, consistent with the broad claim limitation for a counter indicating a “volume of data,” and in light of Appellants’ Specification not providing any limiting definition of “volume of data,” Chandrasekaran’s I/O Total Count and I/O Total Block Count, indicating the number of data blocks transferred, teaches “a counter indicating a volume of data transfer of a data flow identified by a flow identifier” as claimed. (Emphasis added). Appellants have not provided persuasive evidence that a counter for a volume of data transfer, as required by claim 1, is not taught or otherwise suggested by Chandrasekaran’s I/O Total Count and I/O Total Block Count. 4 Appeal 2017-009187 Application 12/705,508 Claim 1 further recites “update the counter based on a read or write command in response to detecting the command in a payload of a data frame belonging to the data flow” Appellants contend Chandrasekaran’s “snooping a packet to determine ‘initiator and target information'' does not involve ‘detecting the command in a payload of a data frame belonging to the data flow.’” App. Br. 9; Reply Br. 8, 10. We agree with the Examiner’s findings that that storing I/O total count for read/write commands requires updating the counter, and that Chandrasekaran teaches snooping the packet for commands, and then looking at a target/initiator pair, and if a flow is detected then analyzing the flow to determine commands and statistics for the packets. Ans. 3; see Final Act. 3. As cited by the Examiner (Final Act. 3), Chandrasekaran teaches “monitor[ing] fibre channel data received on the input port and snoop[ing] for command frames to determine that the command frame is associated with a selected flow.” Chandrasekaran 110 (emphasis added). Appellants have not provided persuasive evidence that “updating the counter based on a read or write command,” as recited in claim 1, is not taught or otherwise suggested by Chandrasekaran’s maintaining I/O Total Count and I/O Total Block Count read statistics and write statistics (Chandrasekaran || 50—70), and that “in response to detecting the command in a payload of a data frame belonging to the data flow,” as recited in claim 1, is not taught or otherwise suggested by Chandrasekaran’s snooping for command frames (detecting the command is in a payload of a data frame) to determine that a command frame is associated with a selected flow (the data frame belonging to the data flow). 5 Appeal 2017-009187 Application 12/705,508 Claim 1 further recites “reporting a value of the counter to a traffic management module." Appellants contend Chandrasekaran “merely forwards data frames to the analyzer, not ‘a value of the counter to a traffic management module.'''’'’ App. Br. 9. We agree with the Examiner’s findings that Chandrasekaran teaches sending gathered flow statistics and information to a switch port analyzer (traffic management module). Ans. 3; see Final Act. 3 (citing Chandrasekaran 149). As cited by the Examiner (Final Act. 3; see App. Br. 9), Chandrasekaran teaches “a switch port analyzer” used with the SCSI MIB, and that “information is forwarded to a switch port analyzer instead of being processed at a fibre channel switch line card,” and the various read and write statistics maintained using the SCSI MIB. Chandrasekaran 149; see also Chandrasekaran || 50—70. In other words, Chandrasekaran teaches forwarding information to a switch port analyzer, associated with the SCSI MIB (Small Computer Systems Interface management information base) that maintains the read and write statistics including I/O Total Count and I/O Total Block Count. Appellants have not provided persuasive evidence that reporting the counter value to a traffic monitoring module, as required by claim 1, is not taught or otherwise suggested by Chandrasekaran’s forwarding information associated with the SCSI MIB including I/O Total Count and I/O Total Block Count to the switch port analyzer. Accordingly, we sustain the 35 U.S.C. § 102(b) rejection of independent claim 1, as well as the rejection of independent claims 7 and 13, which recite limitations commensurate in scope to the disputed limitations 6 Appeal 2017-009187 Application 12/705,508 discussed above, and dependent claims 4 and 10, not separately argued. See App. Br. 7, 11. Claims 2, 5, 8, and 14 Claim 2 further recites “wherein the traffic monitoring module is further configured to determine a direction of the data flow based on determining whether the command is a read or a write command.'1'’ (Emphasis added). Appellants contend Chandrasekaran’s read or write statistics do not include the direction of data flow. App. Br. 11. We agree with the Examiner’s findings that Chandrasekaran’s description of read and write statistics maintained teaches an indication of direction of data flow based on whether they are read or write statistics. Final Act. 4; Ans. 4. As cited by the Examiner (Final Act. 4), Chandrasekaran teaches a “wide variety of statistics” stored, including “read statistics” such as I/O Total Count and I/O Total Block Count” and “write statistics” such as I/O Total Count and I/O Total Block Count. Chandrasekaran || 50, 51, 54, 60, 61,64. Appellants have not provided persuasive evidence that determining the direction of data flow based on whether the command is a read or write command, as required by claim 2, is not taught or otherwise suggested by Chandrasekaran’s maintained read statistics and write statistics indicating commands being read or written and thereby indicating the direction of data flow. 7 Appeal 2017-009187 Application 12/705,508 Accordingly, we sustain the 35 U.S.C. § 102(b) rejection of dependent claim 2, as well as dependent claims 5, 8, and 14, not separately argued. See App. Br. 10-12. Claims 3, 9, and 15 Claim 3 recites “wherein the traffic monitoring module comprises a statistics-collection module configured to compute a data rate of the data flow over a predetermined period of time.” (Emphasis added). Appellants contend Barrett’s I/O command completion time indicates latency, and does not represent “data rate of data flow,” and that Barrett does not consider the calculation of data rate “over a predetermined period of time.” App. Br. 14—15; see Reply Br. 13. We agree with the Examiner’s findings that Barrett teaches an average I/O command completion time, which is a data rate over a period of time corresponding to the rate of data being processed. Ans. 5; Final Act. 5 (citing Barrett || 63, 72). Appellants’ Specification provides broad examples of traffic statistics including “average data rate (computed over a relatively long period), burst data rate (computed over a relatively short period), average end-to-end latency, and current end-to-end latency.” Spec. 136. Appellants do not provide any limiting definition for “data rate of the data flow over a predetermined period of time.” Instead, the claimed “data flow,” in light of Appellants’ Specification, broadly encompasses average data rate computed over a longer period of time. As cited by the Examiner (Final Act. 5), Barrett teaches “automatically detecting] average I/O command completion time trend 8 Appeal 2017-009187 Application 12/705,508 increases” and computing and storing the “average I/O command completion time information.” Barrett | 63. As such, consistent with the broad claim limitation “data rate of the data flow over a predetermined period of time,” and in light of Appellants’ Specification describing “average data rate computed over a relatively long period,” Chandrasekaran’s computed average I/O command completion time teaches data rate for a data flow over a predetermined period of time as claimed. Appellants have not provided persuasive evidence that data rate, as required by claim 3, is not taught or otherwise suggested by Chandrasekaran’s computed average I/O command completion time. Accordingly, we sustain the 35 U.S.C. § 103(a) rejection of dependent claim 3, as well as dependent claims 9 and 15, not separately argued. See App. Br. 14-15. Claims 6 and 12 Claim 6 recites “wherein the traffic monitoring module is configured to throttle the data flow at a level of the logical unit in response to determining that the data flow contributes to a network bottleneck detected based on the flow identifier.” (Emphasis added). Appellants contend Barrett only throttles I/O commands rather than the claimed throttling data flow. App. Br. 16; Reply Br. 14—15. We agree with the Examiner’s findings that Barrett teaches throttling the data rate at the LU (logical unit) level to throttle incoming data when a target is too busy. Ans. 5—6; Final Act 5—6 (citing Barrett || 63, 97, 118). As cited by the Examiner (Final Act. 5—6), Barrett teaches “automatically detecting] average I/O command completion time trend 9 Appeal 2017-009187 Application 12/705,508 increases and throttling] back the outstanding I/O commands for each LU in a target.” Barrett 163. Throttling back the outstanding I/O commands is one such example of “automatic intervention” and throttling back I/O commands encompasses throttling back some of the data flow. Appellants have not provided persuasive evidence that throttling the data flow at the level of the logical unit, as required by claim 6, is not taught or otherwise suggested by Barrett’s throttling back the outstanding I/O commands for each LU. Appellants further argue that Barrett’s bottleneck indicates the switch is too busy rather than the claimed bottleneck detected based on the flow identifier. App. Br. 16; Reply Br. 14—15. Appellants’ argument against Barrett separately from Chandrasekaran does not persuasively rebut the combination made by the Examiner. One cannot show non-obviousness by attacking references individually, where the rejections are based on combinations of references. In re Merck & Co., Inc., 800 F.2d 1091, 1097 (Fed. Cir. 1986); In re Keller, 642 F.2d 413, 425 (CCPA 1981). Specifically, we agree with the Examiner’s finding that Barrett teaches throttling the data rate at the FU level to throttle incoming data when a target is too busy, and that Chandrasekaran teaches detecting data flow based on a data flow identifier. Ans. 5—6. Appellants have not provided persuasive evidence that Chandrasekaran’s detecting data flow based on a data flow identifier, combined with Barrett’s throttling back I/O commands at each FU in response to computing the I/O completion time, does not teach or otherwise suggest “throttle the data flow at a level of the logical unit in response to 10 Appeal 2017-009187 Application 12/705,508 determining that the data flow contributes to a network bottleneck detected based on the flow identifier,” as recited in claim 6. Accordingly, we sustain the 35 U.S.C. § 103(a) rejection of dependent claim 6, as well as dependent claim 12, not separately argued. See App. Br. 15-16. Claims 16 and 18 Claim 16 recites “an ingress switch; an egress switch; wherein the ingress switch, the egress switch, or both comprise a storage device, a traffic monitoring module, and a traffic monitoring module.'” (Emphasis added). Appellants contend that Wu teaches analyzing a packet to determine a response, but does not teach a switching comprising a storage device, a traffic monitoring module, and a traffic monitoring module as claimed. App. Br. 10. Appellants’ argument against Barrett separately from Wu does not persuasively rebut the combination made by the Examiner. See Merck, 800 F.2d at 1097; see also Keller, 642 F.2d at 425. Specifically, we agree with the Examiner’s findings that Wu teaches specific switch characteristics, such as ingress and egress switch characteristics, and Chandrasekaran teaches the traffic monitoring module as claimed. Ans. 5; see Final Act. 6—7. Appellants have not persuasively addressed the Examiner’s proffered combination of Chandrasekaran and Wu. Accordingly, we sustain the 35 U.S.C. § 103(a) rejection of independent claim 16, as well as claim 18, not separately argued. See App. Br. 13-14. 11 Appeal 2017-009187 Application 12/705,508 Claims 11, 17, 19, and 20 Appellants have provided no separate arguments towards patentability for claims 11, 17, 19, and 20. See App. Br. 11—12. Therefore, the Examiner’s, 35 U.S.C. § 103(a) rejections of claims 11, 17, 19, and 20 are sustained for similar reasons as noted supra. DECISION The rejections of claims 1—20 are 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 12 Copy with citationCopy as parenthetical citation