Ex Parte Garg et al

Patent Trial and Appeal Board

Sep 26, 2017

13789519 (P.T.A.B. Sep. 26, 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.
13/789,519 03/07/2013 Meenakshi Garg 112-0708US 5212
85197 7590 09/28/2017 EXAMINER
RrnoaHe
c/o Blank Rome LLP LIU, LI
717 Texas Avenue, Suite 1400
Houston, TX 77002 ART UNIT PAPER NUMBER
2636
NOTIFICATION DATE DELIVERY MODE
09/28/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):
acollins@blankrome.com
hou stonpatents @ blankrome .com
klutsch @blankrome. com
PTOL-90A (Rev. 04/07)
UNITED STATES PATENT AND TRADEMARK OFFICE
BEFORE THE PATENT TRIAL AND APPEAL BOARD
Ex parte MEENAKSHI GARG, VENUGOPAL TUMMALA,
GIN MAN CHEUNG, RAYMOND GRIGSBY, and
BALAKRISHNA WUSIRIKA
Appeal 2016-008061
Application 13/789,519
Technology Center 2600
Before JEFFREY S. SMITH, JOHNNY A. KUMAR, and
TERRENCE W. McMILLIN, Administrative Patent Judges.
SMITH, Administrative Patent Judge.
DECISION ON APPEAL
Appeal 2016-008061
Application 13/789,519
STATEMENT OF THE CASE
This is an appeal under 35 U.S.C. § 134(a) from the rejection of
claims 1—24, which are all the claims pending in the application. We have
jurisdiction under 35 U.S.C. § 6(b).
We affirm.
Representative Claim
1. A device comprising:
a processor;
a network frame handling element coupled to said
processor and including a capability to loop back received
frames; and
a network port coupled to said processor and to said
network frame handling element, said network port including a
media interface module with capabilities to loop back remote
optical signals,
wherein said processor is adapted to configure said
network frame handling element and said network port to leave
a normal operating mode and enter a diagnostic mode on request,
where said diagnostic mode includes at least one of looping back
received optical signals and received frames and occurs for a
diagnostic mode period and there is no normal traffic during said
diagnostic mode, and
wherein said processor is adapted to automatically return
said network frame handling element and said network port to
said normal operating mode in response to said diagnostic mode
period ending.
DeRolf
Li
DeLew
Prior Art
US 2002/0104039 A1
US 2009/0214221 A1
US 2010/0074614 A1
Aug. 1, 2002
Aug. 27, 2009
Mar. 25, 2010
2
Appeal 2016-008061
Application 13/789,519
Examiner’s Rejections
Claims 1—6, 8—12, and 14—24 stand rejected under 35 U.S.C. § 103(a)
as being unpatentable over Li and DeLew.
Claims 7 and 13 stand rejected under 35 U.S.C. § 103(a) as being
unpatentable over Li, DeLew, and DeRolf.
ANALYSIS
We adopt the findings of fact made by the Examiner in the Final
Rejection and Examiner’s Answer as our own. We concur with the
conclusions reached by the Examiner for the reasons given in the
Examiner’s Answer. We highlight the following for emphasis.
103 rejection of claims 1, 2, 4, 6 9, 11—15, 17—20, 22, and 24
“Network Frame Handling Element Coupled to said Processor”
Claim 1 recites “a network frame handling element coupled to said
processor.” Appellants find support for the claimed network frame handling
element in the disclosure of Fibre Channel (FC) Chip 500 shown in Fig. 3B
of Appellants’ Specification. App. Br. 4. Paragraph 37 and Table 1 of
Appellants’ Specification describes the FC Chip 500 contains modules that
perform a variety of tasks, including a Serdes as a serializer and deserializer
and a CPU that processes management frames. Therefore, the scope of the
claimed “network frame handling element,” when read in light of the
Specification, encompasses a Serdes (serializer and deserializer), as well as a
CPU to process management frames.
The Examiner finds that the claimed network frame handling element
is taught by Fi’s micro controller unit MCU 410, part of the smart optical
3
Appeal 2016-008061
Application 13/789,519
transceiver 400 Ans. 2, 35 (citing Li Figs. 2, 4). Appellants contend Li’s
MCU and transceiver module does not teach the claimed “network handling
frame element” that is “coupled to” the claimed processor. App. Br. 9—11.
Li teaches the MCU 410 is the “central unit of processing and
generating management data.” Li|43. The claimed “network frame
handling element,” encompassing a CPU to process management frames, is
taught by Li’s MCU 410 that processes and generates management data on
transceiver 400. Li also teaches the optical transceiver 400 can include
functional blocks such as SerDes (Serializer Deserializer). Li 144. The
scope of the claimed “network frame handling element,” in light of
Appellants’ Specification, also encompasses a Serdes (serializer and
deserializer), taught by Li’s transceiver 400 including functional blocks such
as SerDes (Serializer Deserializer).
The Examiner finds the claimed “processor,” to which the network
frame handling element is coupled, is taught by Li’s management module
212. Ans. 2, 35 (citing Li, Fig. 2).
Supportive of the Examiner’s findings, Figure 2 of Li shows the
management module 212 communicating with optical transceiver 210 over
the interface 216. Paragraph 23 explains that management information is
sent between the management module 212 and the “smart optical transceiver
via a communication interface 216.” Figure 4 and Paragraph 42 of Li
illustrate a “smart optical transceiver 400... which is compatible with the
optical transceivers 210, 220” shown in Figure 2.
Li’s management module 212 is coupled with (i.e., communicates
with over interface 216) optical transceiver 210, which is compatible with
optical transceiver 400. Therefore, we agree with the Examiner’s position
4
Appeal 2016-008061
Application 13/789,519
that the claimed processor coupled to network frame handling element is
taught by Li’s management module 212 coupled to optical transceiver 200,
such as transceiver 400 including MCU 410. Appellants have not
persuasively rebutted the Examiner’s finding that the claimed “network
handling frame element coupled to said processor” is taught by Li’s MCU
410 on smart optical transceiver 400, which is communicatively coupled to
Li’s management module 212.
“Network Port Including a Media Interface Module ”
Claim 1 recites “a network port coupled to said processor and to said
network frame handling element, said network port including a media
interface module with capabilities to loop back remote optical signals.”
Appellants find support for the claimed network port in the disclosure of LC
Ports in Pig. 3 A, and the claimed media interface module in the disclosure of
small form-factor pluggable (SPP) module blocks shown in Pig. 3B. App.
Br. 4. Paragraphs 34 and 35 of Appellants’ Specification describe the PC
ports are connected to a SERDES circuit, and in turn are “connected to
media interface 220, conventionally an SFP,”1 and that SFP modules
“receive optoelectronic converters for use with fiber optic cabling.” Thus,
the scope of the claimed “network port” including the claimed “media
interface module” encompasses an FC port connected to an SFP that
provides for conversion between electrical and optical signals.
The Examiner finds that the claimed “network port” is taught by Li’s
port in the transceiver module that is associated with the interface 116 and
1 See Appellants’ Spec. 134, filed Mar. 7, 2013, and Amended Spec. 134,
filed Sept. 18,2015.
5
Appeal 2016-008061
Application 13/789,519
216 and transceiver 210/220, and the claimed “media interface module” is
taught by Li’s transmitter optical subassembly/receiver optical subassembly.
Ans. 2—3, 41 (citing Li Figs. 2, 3, 4—6, 8). Appellants contend Li’s
transceiver chip 210 and optical subassembly 210/211 shown in Figure 2 is
one single element that cannot teach both the claimed “network frame
handling element” and the claimed “network port.” App. Br. 11—12; Reply
Br. 9-10.
Appellants’ arguments are directed at the optical transceiver as shown
in Figure 2 of Li. However, Figure 4, as also cited by the Examiner,
illustrates a “smart optical transceiver 400 . . . which is compatible with the
optical transceivers 210, 220” shown in Figure 2. Li|42. Figure 4,
detailing the optical transceiver 400 that corresponds to the optical
transceiver 210 of Figure 2, shows the transceiver 400 includes transmitter
optical subassembly 401 and receiver optical assembly 402. Paragraph 42
teaches the “transmitter optical subassembly (TOSA) 401 can emit optical
output signals at a transmission optical interface 422” and the “reception
optical signal at a reception optical interface 432 can be converted to
reception electrical signals by a receiver optical subassembly (ROSA).”
The Examiner’s findings are directed towards Li’s optical transceiver,
shown as 210 in Figure 2 and 400 in Figure 4. We find the claimed
“network port including a media interface module,” encompassing an FC
port connected to a media interface such as SFP that receives optoelectronic
converters for use with fiber optic cabling, is taught by Li’s port with optical
subassembly that transmits, receives, and converts optical signals. We agree
with the Examiner’s findings that the claimed network frame handling
element is taught by Li’s micro controller unit MCU 410, part of the smart
6
Appeal 2016-008061
Application 13/789,519
optical transceiver 400. Therefore, we find the claimed “network frame
handling element” and “network port including a media interface module”
are taught by Li’s MCU 410 and optical subassembly 401, two different
subcomponents of smart optical transceiver 400.
“Automatically Return to Normal Operating Mode ”
Claim 1 further recites “wherein said processor is adapted to
automatically return said network frame handling element and said network
port to said normal operating mode in response to said diagnostic mode
period ending.” Paragraph 77 of Appellants’ Specification provides an
example of toggling, to acknowledge receipt of testing and diagnostic
results, which is “an indication to both ports to revert back to normal port
operation.” Therefore, the scope of the claimed “automatically return ... to
said normal operating mode in response to said diagnostic mode period
ending,” when read in light of the Specification, encompasses indicating to
return to normal operation after testing and receiving diagnostic results.
The Examiner finds that Figure 6C of Li discloses a switch controlled
by a signal to cause the transceiver to operate in either normal mode or loop-
back mode. Ans. 42-43. The Examiner further finds that the claimed
“automatically return said network frame handling element and said network
port to said normal operating mode in response to said diagnostic mode
period ending” is taught by DeLew’s adding test data patterns are added to
the network traffic or signal and then “at the end of the test/diagnostic
period, the BER test patterns are no longer added to the existing network
traffic or standard communications signal” and “the system is returned to a
normal operation mode in response to the diagnostic mode period ending.”
7
Appeal 2016-008061
Application 13/789,519
Ans. 4AA5. Appellants contend Li and DeLew do not teach automatically
returning a network frame handling element and network port to a normal
operating mode in response to a diagnostic mode period ending. App. Br.
12; Reply Br. 10. Specifically, Appellants argue Li “at most discloses an
automatic process to transition into a diagnostic mode, which differs from
transitioning back into a normal operating mode.” Reply Br. 11; App. Br.
13.
Figure 6C of Li is reproduced below:
Figure 6C above shows an optical switch 660 that includes a common
port 661, a branching port A 662, and a branching port B 663. The common
port can be switched to either the branching port A 662 or the branching port
B 663 under the control of a control signal 665. In case of power failure, it
can automatically restore to a default state such that an optical loop-back
path is established for remote testing. Li | 51. The Examiner finds one of
ordinary skill in the art would cause the system to automatically return to
normal mode using control signal 665 after the debugging period has ended,
8
Appeal 2016-008061
Application 13/789,519
for the benefit of performing normal functions instead of remaining in loop-
back mode forever. Ans. 43. Appellants have not persuasively rebutted this
finding. Appellants also have not persuasively shown that causing the
switch of Li to automatically transition to normal mode was “uniquely
challenging or difficult for one of ordinary skill in the art” who can cause the
switch to automatically transition from normal mode as taught by Li. See
Leapfrog Enters., Inc. v. Fisher—Price, Inc., 485 F.3d 1157, 1162 (Fed. Cir.
2007) (citing KSR Int 7 Co. v. Teleflex, Inc., 550 U.S. 398, 419 (2007)).
We find the teachings of DeLew to be cumulative to the teachings of
Li. We briefly address DeLew to complete the record. Appellants further
argue DeLew’s “BER test pattern can be transmitted in a variety of
operating modes” and “transmission and insertion of Delew’s BER test
patterns cannot possibly represent a transition between normal and
diagnostic operation modes.” Reply Br. 13; App. Br. 14—15.
As cited by the Examiner, Figure 4 and Paragraph 53 of DeLew teach
employing a loop back test data path 470 and transmitting test data patterns,
and Paragraph 55 teaches communicating the signal with the test pattern
information and determining “if the ‘loopback’ test pattern was received.”
Figure 6 of DeLew shows transmitting a test data pattern and then not
continuing to transmit test data patterns and ending the procedure. See
DeLew 1 65. Paragraph 24 teaches “test data pattern may also be
transmitted via a respective communications signal as a series of test data
patterns that may be initiated by a user or system software during, for
example, a troubleshooting or diagnostic session,” and “adding the pattern to
existing network traffic communications signals in, for example, the payload
portion of the signals.”
9
Appeal 2016-008061
Application 13/789,519
The claimed “automatically return... to said normal operating mode in
response to said diagnostic mode period ending,” encompassing indicating
returning to normal operation after completing testing or diagnostic, is
taught by DeLew’s loop back test data path and transmission of test data
patterns, added to signals either in diagnostic session or existing network
traffic, followed by not continuing to transmit test data patterns and
signifying the end of the procedure.
Therefore, we agree with the Examiner’s conclusion that combination
of Li and DeLew renders claim 1 unpatentable. Accordingly, we sustain the
rejection of claim 1 under 35 U.S.C. § 103(a).
Appellants do not present arguments for separate patentability of
independent claims 8, 14, and 19, or dependent claims 2, 4, 6, 7, 9, 11—13,
15, 17, 18, 20, 22, and 24, which fall with claim 1. See App. Br. 16, 18—19.
Accordingly, we sustain the rejection of claims 2, 4, 6—9, 11—15, 17—20, 22,
and 24 under 35 U.S.C. § 103(a).
103 rejection of claims 3, 10, 16, and 21
Claim 3 recites “said request is initiated on resetting of the device,”
wherein said request is the request “to leave a normal operating mode and
enter a diagnostic mode” recited in claim 1.
Appellants argue DeLew generates a reset request “after transmitting
a BER test pattern and detecting a failure” and not “in order to... enter the
diagnostic mode.” App. Br. 16; Reply Br. 15. We agree with the
Examiner’s findings that the combination of Li and DeLew teaches a request
is initiated on resetting of the device. Ans. 9, 47.
10
Appeal 2016-008061
Application 13/789,519
As previously cited by the Examiner, Paragraph 51 of Li teaches in
“case of power failure, it can automatically restore to a default state such
that an optical loop-back path is established for remote testing.” Appellants
have not provided persuasive evidence or argument that Li’s restoring a
default state, for remote testing, upon a power failure, fails to teach or
suggest a request to enter a diagnostic mode is initiated upon resetting the
device as required by claim 3.
Accordingly, we sustain the rejection of claim 3 under 35 U.S.C.
§ 103(a), as well as claims 10, 16, and 21, which fall with claim 3.
103 rejection of claims 5 and 23
Claim 5 recites “the device is a switch and said network frame
handling element is a switch ASIC.”
Appellants argue Li’s optical transceiver is a small form-factor
pluggable (SPP) and not a switch ASIC. App. Br. 17. According to
Appellants, clearly “an SPP is not the same as a switch ASIC.” App. Br. 18.
Appellants do not provide persuasive evidence or argument to distinguish
the claimed ASIC from the SPP of Li.
Appellants also contend the Examiner erred in finding the network
frame handling element and the media interface module as claimed
encompass a single component of Li.; Reply Br. 16. Appellants’ contention
is unpersuasive for the reasons given in our analysis of claim 1.
Accordingly, we sustain the rejection of claim 5 under 35 U.S.C.
§ 103(a), as well as claim 23, which falls with claim 5.
11
Appeal 2016-008061
Application 13/789,519
DECISION
The Examiner’s rejections of claims 1—24 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).
AFFIRMED
12