Ex Parte May et al

Patent Trial and Appeal Board

Dec 13, 2017

14251335 (P.T.A.B. Dec. 13, 2017)

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