Ex Parte May et alDownload PDFPatent Trial and Appeal BoardDec 13, 201714251335 (P.T.A.B. Dec. 13, 2017) 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. 14/251,335 04/11/2014 Henry J. MAY ROC920140001US2 9349 46797 7590 12/15/2017 Patterson Rr SheriHan T T P EXAMINER 24 Greenway Plaza, Suite 1600 Houston, TX 77046 WILLIAMS, ELTON S ART UNIT PAPER NUMBER 2465 NOTIFICATION DATE DELIVERY MODE 12/15/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): Pair_eOfficeAction@pattersonsheridan.com IBM@PATTERSONSHERIDAN.COM rociplaw@us.ibm.com PTOL-90A (Rev. 04/07) UNITED STATES PATENT AND TRADEMARK OFFICE BEFORE THE PATENT TRIAL AND APPEAL BOARD Ex parte HENRY J. MAY, CHRISTOPH RAISCH, STEFAN ROSCHER, DANIEL SENTLER, BHARATH B. SOMAYAJI, and SUDHEER R. YELANDURU Appeal 2017-007333 Application 14/251,3351 Technology Center 2400 Before: CARLA M. KRIVAK, IRVIN E. BRANCH, and PHILLIP A. BENNETT, Administrative Patent Judges. BENNETT, Administrative Patent Judge. DECISION ON APPEAL STATEMENT OF THE CASE Appellants appeal under 35 U.S.C. § 134 from the Examiner’s final rejection of claims 1—3, 5—13, and 15—18. We have jurisdiction under 35 U.S.C. § 6(b). We affirm. 1 Appellants’ Brief (“App. Br.”) identifies International Business Machines Corporation as the real party in interest. App. Br. 3. Appeal 2017-007333 Application 14/251,335 CLAIMED SUBJECT MATTER The claims are directed to an exchange switch protocol version in a distributed switch environment. Claim 1, reproduced below, is illustrative of the claimed subject matter: 1. A method for managing a distributed Fibre Channel (FC) fabric, the method comprising: establishing a switch link between a first switching element and a second switching element of the distributed FC fabric; transmitting, to the second switching element, a control- plane request frame that specifies at least one version of a protocol supported by the first switching element, wherein the control-plane request frame includes a capability descriptor comprising a code identifying the protocol, a lowest supported version value for the protocol, and a highest supported version value for the protocol; receiving, from the second switching element, a control- plane response frame that specifies an accepted version of the protocol mutually supported by the first switching element and the second switching element; and operating the switch link established between the first switching element and the second switching element using the accepted version of the protocol. App. Br. 18 (Claims Appendix). REFERENCES The prior art relied upon by the Examiner in rejecting the claims on appeal is: Ayandeh Kazar Hudson Shukla US 7,466,659 B1 Dec. 16, 2008 US 2011/0044344 A1 Feb. 24, 2011 US 2013/0148659 A1 Jun. 13, 2013 US 2013/0287389 A1 Oct. 31,2013 2 Appeal 2017-007333 Application 14/251,335 REJECTIONS Claims 1—3, 5—8, 10-13, and 15—18 stand rejected under 35 U.S.C. § 103(a) as being unpatentable over Ayandeh and Kazar. Final Act. 5—17. Claim 9 stands rejected under 35 U.S.C. § 103(a) as being unpatentable over Ayandeh, Kazar, Shukla, and Hudson. Final Act. 17—20. ISSUES First Issue: Has the Examiner erred in finding Kazar teaches or suggests “a capability descriptor comprising a code identifying the protocol, a lowest supported version value for the protocol, and a highest supported version value for the protocol,” as recited in independent claim 1? Second Issue: Has the Examiner erred in finding Ayandeh and Kazar teach or suggest “capability descriptors that specify a list of protocols and corresponding versions supported by the first switching element,” as recited in dependent claim 3? ANALYSIS First Issue In rejecting claim 1, the Examiner finds Ayandeh teaches a general operating environment for switch communication in a distributed fibre channel fabric, while Kazar teaches or suggests the specific transmission and protocol negotiation of the claimed method. Final Act. 5—8. Particularly, the Examiner finds Kazar’s message header depicted in Figure 7A, and its associated description, teaches the recited “control-plane request frame includes a capability descriptor comprising a code identifying the protocol, a lowest supported version value for the protocol, and a highest supported 3 Appeal 2017-007333 Application 14/251,335 version value for the protocol.” Final Act. 7 (citing Kazar Fig. 7A, col. 15, 11. 21—34 and 51—55). Specifically, the Examiner finds the header depicted in Kazar’s Figure 7A includes a capability descriptor because it identifies a supported protocol. Final Act. 3. The Examiner further finds the header also provides a version (720) including a major version number (722) and a minor version number (724). Id. The Examiner finds the major version number (722) is both a lowest supported version value and a highest supported version value, because major and minor versions are supported within the major version number. Id. Appellants contend Kazar is deficient because it identifies only a single version of a supported protocol—the single version that is constituted by a major and minor version value. App. Br. 10. Specifically, Appellants argue the Examiner’s finding that the single version of the version number corresponds to both a lowest and highest supported version is “mere speculation,” and that Kazar “is completely silent on a ‘lowest’ supported version of a protocol being proposed along with the highest supported version.” App. Br. 12. Accordingly, Appellants contend Kazar merely teaches a protocol negotiation in which each node proposes progressively lower versions until a mutually supported version is reached. Id. We are not persuaded by Appellants’ arguments. Appellants’ Specification details various embodiments of “supported version(s) specified by the capability descriptor.” Spec. 1 55. Importantly, Appellants Specification states that “[i]n some embodiments, the least supported] version and the highest supported version may have identical values, indicating that single version of the protocol is supported by the switching elements.” Id. Thus, according to at least certain of Appellants’ 4 Appeal 2017-007333 Application 14/251,335 embodiments, the highest supported version and the lowest supported version may be encompassed in a single value. This interpretation is supported by the language recited in the disputed limitation. The disputed limitation recites a “capability descriptor comprising a code identifying the protocol, a lowest supported version value for the protocol, and a highest supported version value for the protocol.” App. Br. 18 (Claims Appendix). By its plain language, nothing in the claim requires the lowest supported version to differ from the highest supported version, nor does the language require that the lowest and highest supported versions be stored in two separate data values. Rather, the limitation only requires that the capability descriptor include “code” which can be used for “identifying” the highest and lowest supported values. Therefore, we agree with the Examiner that Kazar’s identification of version (720) as shown in Figure 7A teaches, suggests, or at least renders obvious the disputed limitation. Kazar teaches a requesting device sends the message header (700A) from Figure 7A to a responding device, indicating the proposed version for the session. Kazar Figs. 7A, 8. A person of ordinary skill in the art would have recognized that, in some instances, a device would support only a single version of the protocol. In those situations, the version (720) would have represented both a lowest supported version and a highest supported version. As such, we agree with the Examiner that the header (700A) shown in Kazar’s Figure 7A renders obvious “wherein the control-place request frame includes a capability descriptor comprising a code identifying the protocol, a lowest supported version value for the protocol, and a highest supported version value for the protocol,” as recited in claim 1. 5 Appeal 2017-007333 Application 14/251,335 Second Issue Appellants argue separately for patentability of claim 3, which depends from claim 1 and recites the additional limitation “wherein the control-plane request frame comprises a Switch Fabric Internal Link Services (SW_ILS) frame having a plurality of capability descriptors that specify a list of protocols and corresponding versions supported by the first switching element.” App. Br. 18 (Claims Appendix). The Examiner finds Ayandeh teaches the use of SW_ILS control frames which are sent back and forth between Fiber Channels Over Ethernet forwarder (“FCF”) nodes and Fiber Channels Over Ethernet data forwarder (“FDF”) nodes via A_Ports, VA_Ports, and VA_Port virtual links. Ans. 8 (citing Ayandeh Fig. 7, 18, 40). The Examiner further finds Ayandeh teaches the SW_ILS including a list of controlling FCFs (“c/FCFs”) to which the FDFs have link connectivity. Id. The Examiner further finds Kazar describes the use of capability descriptors which are sent as control frames including a protocol tag having major and minor version numbers. Kazar’s major and minor version numbers, according to the Examiner’s findings, specify a list of protocols including the major protocol version and the various minor protocol versions included in the major protocol versions. Ans. 9. Appellants argue “Kazar, at best teaches negotiating the version of a single protocol at a time, and doing so does not involve a frame with ‘capability descriptors specifying a list of protocols and corresponding versions supported by the first switching element’.” App. Br. 16. Appellants further contend the cited references provide no teaching of specifying a list of “protocols (plural) and corresponding versions” 6 Appeal 2017-007333 Application 14/251,335 because the headers identify only versions of the same protocol. Reply Br. 7. We disagree with Appellants’ argument. The crux of Appellants’ argument is that the header described in Kazar specifies only a single protocol, while the claim requires a list of “protocols,” a plural form. Appellants’ argument, however, does not recognize that the Examiner does not rely solely on Kazar as disclosing the recited “list of protocols.” Rather, the Examiner relies on the combined teachings of Ayandeh and Kazar. Specifically, the Examiner finds Ayandeh teaches the SW_ILS frames sent between the FCF and FDF nodes include multiple item lists of supported c/FCFs to which the sending node has VA_Port and A_Port link connectivity. Ayandeh Fig. 7, ]Hf 40-41. Thus, Ayandeh teaches it was known to include multi-item lists in SW_IFS control-plane frames. As noted supra, Kazar teaches the use of capability descriptors having at least a single item list of protocols as well as lowest and highest supported versions. Kazar Fig. 7A, col. 15,11. 8—34. An ordinarily skilled artisan, possessing Ayandeh’s teaching that multi-item lists can be included in SW_IFS frames, would have sought to include all supported protocols in a list of supported protocols as taught by Kazar. Moreover, even if Appellants are correct that the combined teachings do not disclose a “list with [plural] protocols,” our reviewing court has held a claim that “simply recites repetition of a known procedure until success is achieved,” is not nonobvious where the repetition is the only difference between the claim and the prior art. Perfect Web Techs., Inc. v. InfoUSA, Inc., 587 F.3d 1324, 1330 (Fed. Cir. 2009). Thus, even if we were to credit Appellants’ assertion that the references do not disclose a multi-item list of protocols, this alleged distinction is not dissimilar to that found insufficient 7 Appeal 2017-007333 Application 14/251,335 in Perfect Web Technologies. Here, the claim simply adds an additional protocol to an already listed protocol that is present in the prior art. Thus, we agree with the Examiner that in a situation where a switch, such as that found in Ayandeh, supports multiple protocols, a person of ordinary skill in the art would have been prompted to list each supported protocol in the SW_ILS frame as taught by Kazar. Accordingly, we are not persuaded by Appellants’ argument, and we sustain the rejection of claim 3. Summary Because we are not persuaded the Examiner erred in concluding claims 1 and 3 are unpatentable under 35 U.S.C. § 103(a), we sustain the rejections of those claims. For the same reasons, we also sustain the rejections of claims 11 and 13, for which Appellants present identical arguments. Appellants do not separately argue for patentability of the remaining claims. Consequently, we also sustain those rejections. DECISION We affirm the Examiner’s rejections of claims 1—3, 5—13, and 15—18. No time period for taking any subsequent action in connection with this appeal may be extended under 37 C.F.R. § 1.136(a). See 37 C.F.R. § 1.136(a)(l)(iv). AFFIRMED 8 Copy with citationCopy as parenthetical citation