Ex Parte Wakumoto et alDownload PDFPatent Trial and Appeal BoardFeb 26, 201611056990 (P.T.A.B. Feb. 26, 2016) Copy Citation UNITED STA TES p A TENT AND TRADEMARK OFFICE APPLICATION NO. FILING DATE FIRST NAMED INVENTOR 111056,990 02/1112005 Shaun Kazuo Wakumoto 56436 7590 03/01/2016 Hewlett Packard Enterprise 3404 E. Harmony Road Mail Stop 79 Fort Collins, CO 80528 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 ATTORNEY DOCKET NO. CONFIRMATION NO. 82206098 4580 EXAMINER WYLLIE, CHRISTOPHER T ART UNIT PAPER NUMBER 2465 NOTIFICATION DATE DELIVERY MODE 03/01/2016 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 mkraft@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 SHAUN KAZUO W AKUMOTO and BALLARD CLAUDE BARE Appeal2014-001769 Application 11/056,990 Technology Center 2400 Before JOHN A. EVANS, LINZY T. McCARTNEY, and MATTHEW J. McNEILL, Administrative Patent Judges. EV ANS, Administrative Patent Judge. DECISION ON APPEAL Appeal2014-001769 Application 11/056,990 STATUS OF CLAIMS Appellants 1 take the present appeal from, inter alia, the Notice of Panel Decision from Pre-Appeal Brief Review mailed on April 18, 2013 ("Pre-App. Rev."). App. Br. 1. The pre-appeal review conference determined that: 1. Claims 33--40 stand as ALLOWED; 2. Claims 3, 12, and 13 stand as OBJECTED TO; and 3. Claims 1, 2, 5-11, 15-20, and 22-32 stand as REJECTED. Appellants' Claims Appendix presents Claims 1, 2, 5-11, 15-20, and 22-32 for appeal. App. Br. 20-25. Appellants seek our review under 35 U.S.C. § 134(a) of the Examiner's final rejection of Claims 1-3, 5-13, 15-20, and 22--40 under 35 U.S.C. § 112 and Claims 1, 2, 5-11, 15-26, and 30-32 under 35 U.S.C. § 103. See App. Br. 6-18. The Examiner has withdrawn the rejection of Claims 1-3, 5-13, 15-20, and 22--40 under 35 U.S.C. § 112. Ans. 2. We AFFIRM. STATEMENT OF THE CASE The claims relate to a method of configuring a traffic-associated path through a switching mesh. See Abstract. Claims 1 and 11 are independent. An understanding of the invention can be derived from a reading of exemplary Claims 1 and 11, reproduced below with some formatting and emphasis added: 1. A method of configuring a traffic-associated path through a switching mesh for handling a plurality of different types of traffic, 1 The Appeal Brief identifies Hewlett-Packard Development Company, LP as the real party in interest. App. Br. 3. 2 Appeal2014-001769 Application 11/056,990 the method comprising: receiving a request at a source switch to associate a first type of traffic from among said plurality of different types of traffic to a specified path, wherein the specified path is designated for said first type of traffic through the switching mesh and the source switch is located at a beginning of the specified path; allocating a path tag to the specified path, wherein the source switch allocates the path tag to the specified path; building the specified path through the switching mesh, wherein the source switch builds the specified path; and programming an association between the first type of traffic and the path tag, wherein the path tag is to be applied to subsequent traffic of the first type of traffic in the request received by the source switch. 11. A switching apparatus for configuring a traffic-associated path through a switching mesh for handling a plurality of different types of traffic comprising: a plurality of ports, wherein one of the plurality of ports receives a specified path through the switching apparatus for a first type of traffic from among said plurality of different types of traffic; and and a switch control device coupled to the plurality of ports; a processor for executing instructions; memory for storing data and the instructions for the processor; a communication system interconnecting the processor, the memory, and the switch control device, wherein the instructions are for the processor to receive a request to associate the first type of traffic to the specified path beginning at the switching apparatus, 3 Appeal2014-001769 Application 11/056,990 to allocate a path tag to the specified path, to initiate generation of the specified path through a switching mesh of switching apparatuses, and to program an association between the first type of traffic and the path tag, wherein the path tag is to be applied to subsequent traffic of the first type of traffic in the request received by the source switch. References and Rejections The Examiner relies upon the prior art as follows: Aubin us 4,736,363 Apr. 5, 1988 Cheriton us 6,091,725 July 18, 2000 Mann US 6,314,093 B 1 Nov. 6, 2001 de Boer US 2003/0161304 Al A lHL 28- 2001 - ---o- --, -- -- Chang US 2004/0103153 Al May 27, 2004 Elie-Dit-Cosaque US 2004/0218525 Al Nov. 4, 2004 The claims stand rejected as follows: 2 1. Claims 1, 6, 11, 16, 24--26, 30, and 31 stand rejected under 35 U.S.C. § 103(a) as obvious over Elie-Dit-Cosaque, Mann, and deBoer. Final Act. 3-11. 2. Claim 2 stands rejected under 35 U.S.C. § 103(a) as obvious over Elie-Dit- 2 Based on Appellants' arguments in the Appeal Brief, we will decide the appeal on the basis of claims as set forth below. See 37 C.F.R. § 41.37(c)(l)(iv). 4 Appeal2014-001769 Application 11/056,990 Cosaque, Mann, deBoer, and Aubin. Final Act. 12. 3. Claims 7-10, 17-20, and 32 stand rejected under 35 U.S.C. § 103(a) as obvious over Elie-Dit-Cosaque, Mann, deBoer, and Chang. Final Act. 12- 15. 4. Claims 5, 15, 22, and 23 stand rejected under 35 U.S.C. § 103(a) as obvious over Elie-Dit-Cosaque, Mann, deBoer, and Cheriton. Final Act. 15-17. ANALYSIS Rather than reiterate the arguments of Appellants and the Examiner, we refer to the Appeal Brief (filed May 20, 2013, "App. Br."), the Reply Brief (filed November 8, 2013, Reply Br."), the Examiner's Answer (mailed September 12, 2013, "Ans."), the Final Action (mailed December 4, 2012, "Final Act."), and the Specification (filed February 11, 2005, "Spec.") for the respective details. We have reviewed the rejections of Claims 1, 2, 5-11, 15-20, and 22-32 in light of Appellants' arguments that the Examiner erred. We have considered in this decision only those arguments Appellants actually raised in the Briefs. Any other arguments which Appellants could have made but chose not to make in the Briefs are deemed to be waived. See 37 C.F.R. § 41.37(c)(l)(iv). We are not persuaded that Appellants identify reversible error. Upon consideration of the arguments presented in the Appeal Brief and Reply Brief, we agree with the Examiner that all claims before us for review are unpatentable over the cited combination of references. We adopt as our own the findings and reasons set forth in the rejection from which this appeal is taken and in the Examiner's Answer. We provide the following explanation to highlight and address specific arguments and findings primarily for emphasis. 5 Appeal2014-001769 Application 11/056,990 CLAIMS 1, 6, 11, 16, 24--26, 30, AND 31: OBVIOUSNESS OVER ELIE-DIT-COSAQUE, MANN, AND DEBOER Receiving a request at a source switch to associate a first type of traffic ... to a specified path Claim 1: Appellants traverse the Examiner's finding that Elie-Dit- Cosaque discloses: receiving a request at a source switch to associate a first type of traffic ... to a specified path, wherein the specified path is designated for said first type of traffic through the switching mesh and the source switch is located at a beginning of the specified path, as recited in independent Claim 1. App. Br. 9 (citing Final Act. 5). Appellants argue that Elie-Dit-Cosaque teaches that the ingress node receives a "connection request, which is a request for connection to a destination, and not a request to associate a particular type of traffic to a specified path. Id. Accordingly, the ingress node of Elie-Dit-Cosaque does not receive a request to associate a first type of traffic to a specified path, as claimed. App. Br. 5-6. The Examiner finds that Elie-Dit-Cosaque teaches a connection request can be sent to a source node. The Examiner finds Mann teaches a service request (connection request) may specify the type of traffic, from a plurality of traffic- types, to be included. Ans. 4. Thus, Appellants' argument that Elie-Dit-Cosaque does not specify the type of traffic is unavailing. Appellants concede that Mann discloses the "service requests may specify the type of data traffic to be transferred, eg data or voice," but argue that Mann does not teach the user makes the request to associate a specific traffic-type with a specific route. Reply Br. 6. We do not find Appellants' arguments to be 6 Appeal2014-001769 Application 11/056,990 persuasive because the claims do not recite that a user makes the association request. Programming an association between the first type of traffic and the path tag Claim 1: Appellants contend deBoer fails to teach "programming an association between the first type of traffic and the path tag, wherein the path tag is to be applied to subsequent traffic of the first type of traffic in the request received by the source switch," as recited in Claim 1. Appellants assert the Examiner has found that neither Elie-Dit-Cosaque nor Mann so teach. The Examiner finds deBoer teaches that a constrained routing label distribution protocol (CR-LDP) can be used as a path establishment mechanism. The established path can be identified with a path identifier. Moreover, deBoer teaches the network node uses MPLS TE (multi-protocol label switched path Traffic Engineering extension) which employs "constraint-based routing" in which a path for traffic flow meets the resource requirements of the traffic flow. Ans. 6. Appellants argue that deBoer's MPLS and MPLS TE are rules for directing traffic through paths, but are not types of traffic. Thus, deBoer does not associate a path identifier to a specific type of traffic. Reply Br. 7. Appellants' arguments are not persuasive because Appellants fault deBoer for failing to teach aspects of the claims that the Examiner has found to be taught by Elie-Dit-Cosaque and/or Mann. Ans. 4. Claim 11: Appellants contend Claim 11 is patentable for the reasons advanced in favor of Claim 1. App. Br. 13. In view of our previous discussion, we do not find Appellants' arguments to be persuasive. 7 Appeal2014-001769 Application 11/056,990 Dependent Claims 6, 16, 24--26, 30, and 31: Appellants contend the dependent claims are patentable in view of their dependence from one of Claims 1 and 11. Id. In view of our previous discussion, we do not find Appellants' arguments to be persuasive. Claim 31: Appellants contend that Claim 31 is patentable because the cited art fails to teach "the specified path is defined before the formulation of the request to associate the first type of traffic to the specified path." App. Br. 14. Appellants contend that Mann represents point to point connection requests as an index in a look-up table, but that the point to point connection requests represented as an index in a lookup table do not include a specified path being defined before the formulation of a request to associate a type of traffic to the specified path. Appellants argue Mann fails to teach receiving a request to associate a type of traffic to a specified path. App. Br. 14. The Examiner finds that iviann teaches a method flow whereby parameters and instructions are input, then a representation (table lookup index) is generated, and then the table is searched. The Examiner finds the paths are already entered in the lookup table before generation of connection requests. Ans. 7. Appellants do not reply to this finding and therefore fail to persuade us the Examiner has erred. CLAIM 2: OBVIOUSNESS OVER ELIE-DIT-COSAQUE, MANN, DEBOER, AND AUBIN Appellants contend Claim 2 is patentable for the reasons advanced in favor of Claim 1 and that Aubin fails to provide the allegedly missing teachings. App. Br. 15. In view of our previous discussion, we do not find Appellants' arguments to be persuasive. 8 Appeal2014-001769 Application 11/056,990 CLAIMS 7-10, 17-20, AND 32: OBVIOUSNESS OVER ELIE-DIT-COSAQUE, MANN, DEBOER, AND CHANG Appellants contend Claims 7-10, 17-20, and 32 are patentable for the reasons advanced in favor of Claims 1 and 11 and that Chang fails to provide the allegedly missing teachings. App. Br. 16. In view of our previous discussion, we do not find Appellants' arguments to be persuasive. Claim 7 Claim 7 further recites "after said programming, applying selection criteria to a packet received by the source switch to determine whether the packet comprises said first type of traffic." Appellants contend this recitation is not taught by Chang and that the Examiner finds that it is not taught by the remaining art. Id. Appellants argue that Chang teaches a packet sniffer reads the contents of the packets traversing the SNA (smart network appliance), but Chang fails to apply selection criteria to the packets to determine their traffic type. App. Br. 17. In view of the definition of packet sniffer, we agree with the Examiner's finding that Chang teaches the packet sniff er3 determines the content of the packet and 3 Packet sniffer. A hardware and/or software device that examines every packet sent across a network. Microsoft Computer Dictionary, Fifth ed., (2002) 386. A packet analyzer (also known as a network analyzer, protocol analyzer or packet sniffer---or, for particular types of networks, an Ethernet sniffer or wireless sniffer) is a computer program or piece of computer hardware that can intercept and log traffic that passes over a digital network or part of a network. As data streams flow across the network, the sniffer captures each packet and, if needed, decodes the packet's raw data, showing the values of various fields in the packet, and analyzes its content according to the appropriate RFC or other specifications. Wikipedia. Packet Analyzer. (citing Kevin J. Connolly (2003 ). Law of Internet Security and Privacy. Aspen Publishers. p. 131. ISBN 978-0-7355-4273-0. 9 Appeal2014-001769 Application 11/056,990 thus, the traffic type. Ans. 8. Chang discloses "a packet sniffer for reading the contents of each network packet transmitted from or to the network." Chang, ,-r 7 4 (See Ans. 8). A person of ordinary skill in the art would understand that a "packet sniffer" examines every packet on its assigned circuit(s) and monitors the data stream for various pattems.4 Thus, a person of ordinary skill in the art would understand that Chang's packet sniffer that "reads the contents of each network packet transmitted from or to the network" (Chang, ,-r 74) would determine the type of traffic that each read packet represented. We are not persuaded the Examiner has erred. CLAIMS 5, 15, 22, AND 23: OBVIOUSNESS OVER ELIE-DIT-COSAQUE, MANN, DEBOER, AND CHERITON Appellants contend that Claims 5, 15, 22, and 23 are patentable in view of their dependence from one of Claims 1 or 11. App. Br. 18. In view of the foregoing discussion, we are not persuaded the Examiner has erred. DECISION The rejection of Claims 1, 2, 5-11, 15-20, 22-26, and 30-32 under 35 U.S.C. § 103 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). 4 Packet Sniffer. A piece of software that simply examines every packet on whichever circuit/s it's assigned to monitor. It could [] be used by an intruder to monitor a data stream for a pattern such as a password or credit card numbers. Harry Newton, Newton's Telecom Dictionary 19th ed., p. 589 (2003). 10 Appeal2014-001769 Application 11/056,990 AFFIRMED 11 Copy with citationCopy as parenthetical citation