Ex Parte Snyder et al

Patent Trial and Appeal Board

Sep 19, 2017

14150602 (P.T.A.B. Sep. 19, 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/150,602 01/08/2014 Wilson Parkhurst Snyder II CVM-010US 5497
106719 7590
Pavel Kalousek
22262 Crestline Road
P.O. Box 245
Palomar Mountain, CA 92060
09/21/2017 EXAMINER
ESMAEILIAN, MAJID
ART UNIT PAPER NUMBER
2477
NOTIFICATION DATE DELIVERY MODE
09/21/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):
pkalousek. ip @ gmail. com
PTOL-90A (Rev. 04/07)
UNITED STATES PATENT AND TRADEMARK OFFICE
BEFORE THE PATENT TRIAL AND APPEAL BOARD
Ex parte WILSON PARKHURST SNYDER II and DANIEL ADAM KATZ
Appeal 2017-004917
Application 14/150,6021
Technology Center 2400
Before LINZY T. McCARTNEY, NATHAN A. ENGELS, and
JAMES W. DEJMEK, Administrative Patent Judges.
ENGELS, Administrative Patent Judge.
DECISION ON APPEAL
STATEMENT OF THE CASE2
Appellants appeal under 35 U.S.C. § 134(a) from a Final Rejection of
claims 1—20. We have jurisdiction over the pending claims under
35 U.S.C. § 6(b). We affirm.
1 Appellants identify Cavium, Inc. as the real party in interest. Appeal Br. 1.
2 Although not identified by Appellants as a related appeal, Appellants filed
an appeal involving similar claims, prior art, and issues. Compare Appeal
Br., Appeal No. 2017-004918 (filed Sept. 16, 2016), with Appeal Br.,
Appeal No. 2017-004917 (filed June 29, 2016). We remind Appellants that
37 C.F.R. § 41.37(c)(l)(ii) requires that Appellants identify related appeals,
interferences, and trials in their appeal briefs.
Appeal 2017-004917
Application 14/150,602
REPRESENTATIVE CLAIM
Claims 1, 10, 16, and 19 are independent claims. Claim 1, reproduced
below, is representative of the claimed subject matter:
1. A parser for parsing network packets, the parser
comprising:
a plurality of clusters, each cluster comprising one or more
engines;
a launcher configured to determine a candidate cluster of
the plurality of clusters to parse a subset of a plurality of received
packets;
a loader configured to transmit the subset of the plurality
of packets to the candidate cluster, wherein each of the one or
more engines in the candidate cluster is configured to parse and
derive parse results for a packet of the subset of the plurality of
packets; and
an unloader configured to receive from the candidate
cluster the parse results for the subset of the plurality of packets
and to transmit that information to a target.
THE REJECTIONS3
Claims 1—8 and 10-20 stand rejected under 35 U.S.C. § 103 as
unpatentable over Kumar et al. (US 2013/0120168 Al; May 16, 2013)
3 The Final Rejection states that claims 1—20 are rejected under
pre-AIA 35 U.S.C. § 103(a). Final Act. 8, 18—19. But because the
application was filed after March 16, 2013, the statements of rejection
should have referenced AIA 35 U.S.C. § 103, not pre-AIA 35 U.S.C.
§ 103(a). Nevertheless, the bodies of the rejections include findings from
Kumar, Panigrahy, and/or Wilkinson for each limitation, along with
rationales to combine the cited references in accordance with
AIA 35 U.S.C. § 103. Final Act. 8—19. Accordingly, we understand claims
1—8 and 10-20 to stand rejected under AIA 35 U.S.C. § 103 as unpatentable
over Kumar and Panigrahy and claim 9 to stand rejected under AIA 35
2
Appeal 2017-004917
Application 14/150,602
(“Kumar”) and Panigrahy (US 2005/0238022 Al; Oct. 27, 2005).
Final Act. 8—18.
Claim 9 stands rejected under 35 U.S.C. § 103 as unpatentable over
Kumar, Panigrahy, and Wilkinson et al. (US 5,717,944; Feb. 10, 1998)
(“Wilkinson”). Final Act. 18-19.
ANALYSIS
Claim 1
Appellants argue that in rejecting claim 1, the Examiner’s rejection
(1) fails to demonstrate that Kumar and Panigrahy disclose all of the
limitations of an architecture arranged to support a simple instruction,
multiple data (SIMD) machine as claimed; (2) takes inconsistent positions in
regards to several of the alleged limitations; (3) fails to demonstrate that a
person of ordinary skill in the art would combine the references by some
articulated reasoning with some rational underpinning to support the
conclusion of obviousness; and (4) fails to answer the substance of
Appellants’ arguments. Appeal Br. 3. For the reasons explained below, we
disagree with Appellants.
In rejecting claim 1, the Examiner found “Kumar teaches a multi-core
system wherein network traffic is distributed across one or more packet
processing engines for packet processing purposes according to a flow-bases
[sic] scheme.” Final Act. 9. More specifically, the Examiner found the
multi-core system depicted in Kumar’s Figure 5B and related disclosures
teaches or suggests claim 1 with the exception of transmitting parse results
U.S.C. § 103 over Kumar, Panigrahy, and Wilkinson and treat these
oversights to be typographical errors.
3
Appeal 2017-004917
Application 14/150,602
to a target, for which the Examiner relied on Panigrahy. Final Act. 8—9
(citing Kumar Fig. 5B, || 106, 187, 210, 215); Ans. 16—19 (citing, among
other things, Kumar | 107).
Figure 5B of Kumar is reproduced below:
545
1------------------
J SST i
* Flow , NIG
! OiStriOUiOf '
560
RSS Ntod'olfc
FIG. SB
Figure 5B of Kumar is a block diagram illustrating an embodiment of
Kumar’s multi-core system. Kumar 126. Figure 5B of Kumar shows a
plurality of processing cores (Cores 505A—N), wherein each processing core
includes a packet engine or packet processing engine (548A—N) in
communication with a memory bus. Kumar Fig. 5B, 1187. We agree with
the Examiner that Kumar’s disclosure of a plurality of processing cores
4
Appeal 2017-004917
Application 14/150,602
teaches “a plurality of clusters,” as recited in claim 1. See Ans. 18 (“a core
is equivalent to a cluster”). We also agree with the Examiner that Kumar
teaches “each cluster comprising one or more engines” with its disclosure
that each of processing cores (505A—N) includes a packet processing engine
(548A-N). See Ans. 18-19.
Relevant to “each . . . engine [] . . . configured to parse and derive
parse results for a packet,” the Examiner found Kumar discloses that each
packet processing engine is responsible for managing the kernel-level
processing of network packets received and transmitted by the multi-core
system via a network. Final Act. 9 (citing Kumar 1106). For example, a
packet processing engine can process received or transmitted network
packets responsive to a time interval provided by a packet-processing timer.
Ans. 16 (citing Kumar 1107); see also Final Act. 2—3; Adv. Act. 2.
Consistent with the Examiner’s findings, Kumar further discloses that its
packet processing engine can provide a variety of functions, including
content switching, load balancing, packet acceleration, compression,
encoding, decompression, decoding, network I/O processing, SSF offloading
and processing, layer processing, and traffic management. Kumar || 171,
188. These disclosures of Kumar imply or at least suggest that processing
network packets includes checking or analyzing, in other words, “pars[ing],”
the contents of the packet to determine how the packet should be processed
and which function the packet processing engine should apply.
Accordingly, we agree with the Examiner that Kumar’s disclosure of
packet processing engines configured to process network packets teaches or
suggests “each . . . engine[] . . . configured to parse and derive parse results
for a packet,” as recited in claim 1. The Examiner’s findings are consistent
5
Appeal 2017-004917
Application 14/150,602
with the Specification, which does not explicitly define “parsing],” but
instead describes the term broadly as “analyzing] the data in the packet to
determine its characteristics . . . [that] may include its source, destination, or
type.” Spec. 13; see also Spec. ^fl[ 34—35 (disclosing non-limiting examples
in which parsing is performed on one or more of a packet’s protocol layers
and fields within those protocols).
As teaching “a launcher” and “a loader,” the Examiner cites functions
of Kumar’s flow distributor (550), which communicates with processing
cores (505A—N) as shown above in Figure 5B. Final Act. 8 (citing Fig. 5B,
1187). The flow distributor distributes, forwards, routes, controls, and/or
manages the distribution of data packets among the processing cores and/or
packet processing engines running on the cores. Kumar 1198. More
specifically,
[t]he flow distributor 550 can . . . tak[e] in data packets and
distribute] them across the processors according to an
operative load balancing or distribution scheme. . . . [T]he flow
distributor 550 can comprise one or more operations, functions
or logic to determine how to distribute packers [sic], work or
load accordingly. . . . [T]he flow distributor 550 can comprise
one or more sub operations, functions or logic that can identify
a source address and a destination address associated with a
data packet, and distribute packets accordingly.
Kumar 1200.4; Further, “[t]he flow distributor may use any type and form of
statistical or probabilistic algorithms or decision making to balance the flows
across the cores.” Kumar 1198; see also Kumar 1200 (“The flow
4 See also Kumar 1199 (“In one instance, the one or more flow distributors
550 can determine how to balance load by communicating with each
other.”).
6
Appeal 2017-004917
Application 14/150,602
distributor 550 can distribute network traffic among the cores 505 according
to a distribution, computing or load balancing scheme such as those
described herein.”).5 Still further, the Examiner found
[t]he flow distributor may operate responsive to any one or
more rules or policies . . . [that] may identify a core or packet
processing engine to receive a network packet.... The rules
may identify any type and form of tuple information related to a
network packet.... Based on a received packet matching the
tuple specified by the rule, the flow distributor may forward the
packet to a core or packet engine.
Final Act. 8 (citing Kumar 1215).6
We agree with the Examiner that these disclosures of Kumar teach “a
launcher” and “a loader,” as recited in claim 1. In particular, the flow
distributor performs the functions of “a launcher” by determining which core
(“candidate cluster”) to receive a network packet, and the flow distributor
performs the functions of “a loader” by forwarding the packet to the
determined core for processing by the core’s packet processing engine.
Notably, the Specification does not define “a launcher” and “a loader” as
separate structural elements; in fact, the Specification describes them as
functional software modules for execution by a computer processor. Spec.
141 (describing a system including, among other things, a launcher module
and a loader module), 145 (describing a launcher module), 146 (describing
5 See also Kumar 1199 (disclosing various load criteria by which the flow
distributor can determine whether to forward a data packet to a particular
core or packet (processing) engine therein).
6 Kumar’s tuple information also provides support in parsing IPv6 extension
headers of a received network packet. Final Act. 8 (citing Kumar 1210
(“2-tuple of source IPv6 address, and destination IPv6 address, including
support for parsing IPv6 extension headers”), 1215).
7
Appeal 2017-004917
Application 14/150,602
a loader), 1130 (disclosing that modules can be “implemented via one or
more software programs for performing the functionality of the
corresponding modules or via computer processors executing those software
programs.”).
We also agree with the Examiner that the combination of Kumar and
Panigrahy teaches or suggests “an unloader,” as also recited in claim 1. The
Examiner found Kumar’s packet processing engine may comprise a buffer
for queuing one or more network packets during processing, such as for
receipt or transmission of a network packet. Final Act. 9 (citing Kumar
1106). We agree with the Examiner that Kumar’s packet processing engine
teaches or suggests “an unloader” of network packets by performing the
functions of receiving network packets and transmitting network packets to a
buffer. See Kumar H 106, 107 (disclosing “the processing of incoming, i.e.,
received, or outgoing, i.e., transmitted, network packets.”).
Additionally, the Examiner found Panigrahy discloses a network
device including a parsing processor that parses incoming packets and sends
processed outgoing packets to the network. Final Act. 9 (citing Panigrahy
Fig. 1,110). We agree with the Examiner that Panigrahy’s network device
teaches “an unloader configured to receive . . . parse results ... to transmit
that information to a target” by receiving processed outgoing packets and
transmitting that information to a target, namely, the network.
See Panigrahy Fig. 1, || 10, 25—26 (describing Figure 1 in more detail).
Appellants argue the Examiner erred by disregarding the term
“parser” as defined in the Specification and instead interpreted “parser” in a
manner inconsistent with how it would be interpreted by one of ordinary
skill in the art. Appeal Br. 3—8; Reply Br. 2—8. We disagree.
8
Appeal 2017-004917
Application 14/150,602
“Quite apart from the written description and the prosecution history,
the claims themselves provide substantial guidance as to the meaning of
particular claim terms.” Phillips v. AWH Corp., 415 F.3d 1303, 1314 (Fed.
Cir. 2005). “[T]he context of the surrounding words of the claim . . . must
be considered in determining the ordinary and customary meaning of those
terms.” ACTV, Inc. v. Walt Disney Co., 346 F.3d 1082, 1088 (Fed. Cir.
2003). The preamble of claim 1 recites a “parser for parsing network
packets . . . comprising,” and the body of claim 1 defines the parser as
including “a plurality of clusters, each cluster comprising one or more
engines; ... a launcher; ... a loader; . . . and an unloader . . . .” Thus,
contrary to Appellants’ arguments, the Examiner correctly interpreted the
claimed parser consistent with the plain language of the claim. Further, the
cited portions of the Specification do not explicitly define the term “parser;”
the Specification provides examples of functions that may be included in
“some embodiments” of a parser and parse results. See Spec. ]Hf 34—35
(describing non-limiting examples of a “parser” and its associated
functions). Further still, Appellants acknowledge their proffered
interpretation of “a parser” is consistent with Panigrahy’s disclosure of a
parsing processor. Appeal Br. 4—5 (citing Spec. Tflf 34—35; Panigrahy || 3,
9).
As such, as discussed above, the combination of Kumar and
Panigrahy teaches or suggests all of the limitations recited in the body of
claim 1, including “a plurality of clusters,” “a launcher,” “a loader,” and “an
unloader.” Accordingly, we agree with the Examiner that the combination
of Kumar and Panigrahy also teaches or suggests a “parser for parsing
network packets” comprising those limitations.
9
Appeal 2017-004917
Application 14/150,602
Nevertheless, even if we were to agree with Appellants’ interpretation
of “parser”—as a device providing content information about a packet—
Kumar’s multi-core system teaches or at least suggests such a “parser.”
More specifically, as discussed above, Kumar’s multi-core system teaches a
device providing content information about a packet with its flow distributor
that can identify a source and destination address associated with a data
packet and distribute the packet accordingly. Further, Kumar also teaches a
packet processing engine that processes a received network packet and
performs various packet-based functions.
Next, Appellants argue the Examiner erred in finding Kumar’s
plurality of packet processing engines teaches “a plurality of clusters.”
Appeal Br. 8—10. We are unpersuaded of Examiner error because, as the
Examiner explains Kumar’s plurality of processing cores teaches “a plurality
of clusters.” See Ans. 4 (“Kumar[,] Fig. 5B and [paragraph 187] teach[] a
plurality of core processors 505A—N (i.e. [,] clusters) comprising a packet
processing engine”) (emphasis omitted); Ans. 18 (“Kumar Fig. 5B, showing
a multi-core system (i.e., a core is equivalent to a cluster), including one or
more packet engines or processors”); accord Final Act. 8 (citing Kumar Fig.
5B, items 505A—N, 1187). Moreover, as discussed above, we agree with
the Examiner that Kumar’s plurality of processing cores, wherein each
processing core includes a packet processing engine, teaches “a plurality of
clusters, each cluster comprising one or more engines.”
Appellants additionally argue the Examiner’s Answer includes a new
ground of rejection because, according to Appellants, the Examiner took
inconsistent positions with respect to the claimed “plurality of clusters, each
cluster comprising one or more engines.” Appeal Br. 11—12; Reply Br. 8—
10
Appeal 2017-004917
Application 14/150,602
10. In particular, Appellants assert the “allegation [in the Examiner’s
Answer] that ‘every core, is considered as a cluster’ contradicts the
examiner’s allegation form [sic] the Office action (s) that a plurality of
packet processing engines is considered to be a cluster’'’ and appears to
introduce a new ground of rejection. Reply Br. 8—9. However, allegations
that an Examiner’s Answer contains undesignated new grounds of rejection
must be resolved by filing a petition to reopen prosecution under 37 C.F.R.
§ 1.181, the absence of which constitutes waiver of such arguments. 37
C.F.R. § 41.40 (“Failure of appellant to timely file such a petition will
constitute a waiver of any arguments that a rejection must be designated as a
new ground of rejection.”); accord MPEP § 1207.03. Appellants did not file
a petition and therefore waived any argument that the Examiner’s Answer
includes new grounds of rejection.
Next, Appellants argue Kumar’s flow distributor cannot be cited as
teaching both “a launcher” and “a loader” because these limitations are
separate entities with separate functions. Appeal Br. 13. We disagree with
Appellants because, as discussed above, the Specification describes a
launcher and loader not as separate structural elements, but instead as
functional software modules for execution by a computer processor. See,
e.g., Spec. 1130. Accordingly, for the reasons discussed above, we agree
with the Examiner that the functions performed by Kumar’s flow distributor
satisfy “a launcher” and “a loader.”
Appellants also assert that the unloader, cluster, and parsing engine
are distinct entities with distinct and different functions. Appeal Br. 15.
Thus, Appellants argue the Examiner’s rejection improperly alleges a single
entity, Kumar’s processing core including a single packet processing engine,
11
Appeal 2017-004917
Application 14/150,602
has a triple function as a cluster, as a parsing engine, and as a an unloader.
Appeal Br. 15.
We find Appellants’ argument unpersuasive of error. Even though
“cluster,” “engine[s] . . . configured to parse,” and “unloader” are distinct
claim limitations, a broad but reasonable interpretation of the claim language
encompasses a processing core (“cluster”) having a packet processing engine
that performs parsing (“engine[] . . . configured to parse”) and unloading
(“unloader”) functions. The Specification does not define “an unloader” as a
separate structural element, but instead describes it as a functional software
module for execution by a computer processor. Spec. 141 (describing a
system including, among other things, an unloader module), 1 54 (describing
unloader), 1130 (disclosing that modules can be “implemented via one or
more software programs for performing the functionality of the
corresponding modules or via computer processors executing those software
programs.”).
Further, with respect to the claimed “unloader” limitation, Appellants
argue Kumar’s packet processing engine receives network packets which are
not “parse results,” and although Kumar’s received network packets are
stored in a buffer, Appellants argue they are not “transmit [ted]... to a
target.” Appeal Br. 15—16. Appellants also argue Panigrahy’s parsed
packets, which, according to Appellants, comprise only a portion of a
packet, i.e., a packet field, are different from the claimed “parse results,”
which Appellants argue as “information related to one or more protocol
layers and fields within those protocols according to which the packets are
built.” Appeal Br. 17; Spec. 134.
12
Appeal 2017-004917
Application 14/150,602
We find Appellants’ arguments unpersuasive because the arguments
attack Kumar and Panigrahy individually without substantively addressing
what a person of ordinary skill would have understood from the combined
teachings of the prior art. See In re Keller, 642 F.2d 413, 425 (CCPA 1981).
Indeed, as discussed above, the Examiner did not rely on Kumar or
Panigrahy alone, but on the combined teachings of Kumar and Panigrahy, to
teach or suggest “an unloader” as recited in claim 1. Further, contrary to
Appellants’ arguments, the Specification does not define “parse results” as
Appellants suggest; the Specification broadly states “[pjarser 120 is a
parsing system configured to parse the received packets and extracts [sic]
from those packets some parse results.” Spec. 134. Rather than providing
limiting definition of parse results, the Specification describes “some
embodiments” and “examples” of parse results, stating that “[i]n some
embodiments, the parse results include information related to one or more
protocol layers and fields within those protocols according to which the
packets are built” (Spec. 134) and “parse results, for example, may include
the type of the packet’s protocol, whether one or more fields or layers of that
protocol are present in the packet, the packet destination” (Spec. 135).
Appellants have not identified anything in the claims or Specification that
precludes “parse results” from encompassing Panigrahy’s parsed packets, as
found by the Examiner. See Final Act. 9 (citing Panigrahy Fig. 1,110).
Additionally, Appellants argue the Examiner failed to provide a
rational underpinning by reciting two different and incompatible
technologies in support of a legal conclusion of obviousness. Appeal Br. 18.
More specifically, Appellants assert that Kumar discloses a multi-core
architecture and that the paragraph of Kumar “used to justify the
13
Appeal 2017-004917
Application 14/150,602
combination” of Kumar and Panigrahy merely discloses a single-core
processing unit. Appeal Br. 18 (citing Kumar || 78, 88). Appellants further
argue, based on the assertion that Kumar fails to disclose a parser, that the
Examiner failed to provide a rational underpinning because it is unclear why
Kumar would incorporate Panigrahy’s parser processor, which would not be
used. Appeal Br. 18.
We find Appellants’ arguments unpersuasive. As an initial matter, we
disagree with Appellants that the Examiner relied on paragraph 78 of Kumar
to justify the combination of Kumar and Panigrahy. Rather, in combining
Kumar and Panigrahy, the Examiner articulates a rationale to combine— in
order to benefit from a parsing processor that can efficiently store a large
number of transitions on-chips—drawn directly from the Panigrahy
reference, and Appellants do not persuasively rebut that rationale. See Final
Act. 9; Panigrahy || 76, 77 (“[T]he parsing processor 120 can efficiently
store a large number of transitions on-chip.”). Appellants’ arguments are
also unpersuasive because, as discussed above, Kumar’s multi-core system
teaches or suggests “a parser.” Still further, Appellants cite no evidence to
show that applying Panigrahy’s “unloader” teachings to Kumar’s multi-core
system—to produce a multi-core system that receives parsed packets and
transmits that information to a target—would have been uniquely
challenging or anything more than a routine exercise of applying known
techniques to achieve predictable results. See KSR Int’l Co. v. Teleflex Inc.,
550 U.S. 398, 416—17 (2007) (explaining as examples of combinations likely
to be obvious “[t]he combination of familiar elements according to known
methods . . . when it does no more than yield predictable results” and “the
mere application of a known technique to a piece of prior art ready for the
14
Appeal 2017-004917
Application 14/150,602
improvement”); Leapfrog Enters, v. Fisher-Price, Inc., 485 F.3d 1157, 1162
(Fed. Cir. 2007) (citing KSR, 550 U.S. at 418). For the reasons stated above,
Appellants’ arguments have not shown the Examiner failed to provide a
rational underpinning in support of the legal conclusion of obviousness.
In view of the foregoing, Appellants have not persuaded us that the
Examiner erred in rejecting claim 1 over the combination of Kumar and
Panigrahy. See Appeal Br. 3—19; Reply Br. 2—12.
Claim 2
Appellants argue the “buffer” recited in claim 2 “cannot be considered
to correspond to the buffer as disclosed by Kumar et al. because the buffers
are (1) at different locations] in the architecture and (2) serve different
functions.” Appeal Br. 20. According to Appellants, the claimed “buffer” is
separate from the cluster and used for queuing of received packets before
providing the packets to the cluster and ultimately to the engines for
processing. Appeal Br. 20 (citing Fig. 3, item 322, Spec. H 6, 41, 46).
We find Appellants’ arguments unpersuasive. As the Examiner
correctly identifies (Final Act. 5; Adv. Act. 3), Appellants’ arguments
improperly rely on features not recited in the claim. “[I]t is important not to
import into a claim limitations that are not a part of the claim. For example,
a particular embodiment appearing in the written description may not be
read into a claim when the claim language is broader than the embodiment.”
SuperGuide Corp. v. DirecTV Enters., 358 F.3d 870, 875 (Fed. Cir. 2004).
Here, claim 2 does not specify the location of the recited “assembly buffer”
and, thus, does not preclude the assembly buffer from being part of a cluster.
Nor does the claim specify a time when the buffer is to store the plurality of
15
Appeal 2017-004917
Application 14/150,602
packets, such as before providing the packets to the cluster. Additionally,
cited portions of Appellants’ disclosure merely provide non-limiting
examples of an assembly buffer and do not limit the term to a particular
location or function. See Spec. Fig. 3, item 322, || 6, 41, 46. Accordingly,
Appellants have not identified anything in claim 2 or the Specification that
precludes the “assembly buffer” from encompassing the buffer within
Kumar’s packet processing engine, wherein the buffer stores a plurality of
network packets during processing. Final Act. 10 (citing Kumar 1106); see
also Kumar Fig. 2A, item 243 (buffer).
Claim 4
Appellants argue Kumar does not teach or suggest “memories,” as
recited in claim 4 because, according to Appellants, the cited memory bus
and the claimed “memories” are completely different structures. Appeal
Br. 21—22. We find Appellants’argument unpersuasive. Contrary to
Appellants’ argument, the Examiner’s finding that Kumar discloses a
memory bus implies or suggests the presence of a memory, as the purpose of
a memory bus is to connect a memory to another part of the system. See
Final Act. 10 (citing Kumar Fig. 5B, item 556 (Memory Bus), 1192); see
also Kumar | 80 (disclosing that various busses may be used to connect
different units and devices within the system). Moreover, the cited
paragraph of Kumar discloses that “the system 545 can comprise any
number of memory buses” and that “the memory bus 556 can be any type
and form of memory.” Kumar 1192 (emphasis added). Thus, contrary to
Appellants’ argument, Kumar’s disclosure of memory buses teaches or at
least suggests the claimed “memories.”
16
Appeal 2017-004917
Application 14/150,602
Claim 6
Appellants argue Kumar does not teach or suggest “wherein the
candidate cluster includes a plurality of engines each configured to parse and
derive parse results for one packet,” as recited in claim 6. Appeal Br. 23—24.
We disagree. As discussed above with respect to independent claim 1, we
agree with the Examiner that Kumar teaches a plurality of processing cores,
each core including a packet processing engine configured to parse and
derive parse results for a network packet. Consistent with the Examiner’s
findings for claim 1, Kumar further discloses that “[tjhere may be multiple
packet engines 240 each running on a respective core of the plurality of
cores.” Kumar 1168; see also Kumar 1190 (“In some embodiments, a
single packet engine(s) 548A—N carries out a load balancing scheme, while
in other embodiments one or more packet engine(s) 548A—N carry out a load
balancing scheme.”). In other words, Kumar teaches or at least suggests a
plurality of packet processing engines in a respective processing core, each
engine configured to parse and derive parse results for a network packet.
Claim 7
Appellants argue Kumar does not teach or suggest “wherein the
plurality of engines in the candidate cluster operate independently,” as
recited in claim 7. Appeal Br. 24—25. To the contrary, Appellants assert the
work of Kumar’s processing cores is dependent on one another because the
response by one processing core to a request packet is dependent on the
request by another processing core. Appeal Br. 25.
17
Appeal 2017-004917
Application 14/150,602
We find Appellants’ argument unpersuasive because the argument is
not commensurate with the plain reading of the claim language in view of
the Specification. The Specification provides that “[wjhile a cluster is in a
processing state, each of its processing engines may operate independently.
That is, each processing engine parses its allocated packet data that is
different from the data allocated to other engines.” Spec. 153. In other
words, to “operate independently” includes parsing packet data that is
different from the data allocated to other engines. As discussed above with
respect to claim 1, this is what Kumar’s flow distributor is configured to do
by performing load balancing and distributing the network packets for
processing among the different cores and their respective packet processing
engine(s). See, e.g., Kumar || 198—200 (describing the flow distributor’s
functions in detail); Final Act. 8 (citing Kumar Fig. 5B, item 550,1187).
The disclosed functions of Kumar’s flow distributor would have at least
suggested to one of ordinary skill in the art that the packet processing engine
of one processing core processes network packets distinct from the network
packets processed by the packet processing engine of another processing
core.
Claim 8
Appellants argue Kumar does not teach or suggest “wherein the
launcher is configured to determine the candidate cluster as a cluster when at
least one engine in the candidate cluster is idle,” as recited in claim 8.
Appeal Br. 25—26. In rejecting claim 8, the Examiner found the rules and
policies used by Kumar’s flow distributor to send a particular network
packet to a particular core “can be when a device is idle.” Final Act. 11
18
Appeal 2017-004917
Application 14/150,602
(citing Kumar Fig. 5B, 1187) (emphasis omitted). In response, Appellants
assert that the Examiner exercised impermissible hindsight because Kumar
“is silent about the flow distributor rules of [sic] policies being based on a
state of the processor, i.e., the processor state being idle.” Appeal Br. 26.
We find Appellants’ argument unpersuasive. Rather, we agree with
the Examiner that Kumar teaches or suggests the disputed limitation by
implementing rules and policies whereby when a packet processing engine
in a processing core is idle, network packets are allocated to the idle engine.
More specifically, Kumar discloses a rule in which packets are allocated to
the processing core having the least amount of load. Kumar || 183—184; see
also Kumar || 187, 198—200 (describing the load balancing functions of the
flow distributor). Similar to the limitation at issue, in the event one of the
processing cores among a plurality of cores is packet-less and, thus, is
“idle,” applying Kumar’s “least amount of load” rule, network packets
would be sent to that packet-less core. See Kumar Figure 5A (top figure),
item 505C (showing a functional parallelism distribution scheme in which
Core 3 is packet-less and, thus, “idle”); see also Kumar || 183—184.
Further, given the cited disclosures of Kumar, one of ordinary skill in
the art would understand that when Kumar’s multi-core system is initialized
and the flow distributor begins to function, each of the packet processing
engines would be “idle” until the flow distributor distributed a network
packet to one of them for processing. See KSR, 550 U.S. at 418 (explaining
that an obviousness analysis can take account of the inferences and creative
steps of a person of ordinary skill in the art); DyStar Textilfarben GmbH &
Co. Deutschland KG v. C.H. Patrick Co., 464 F.3d 1356, 1368 (Fed. Cir.
2006) (stating that “the prior art” includes basic principles unlikely to be
19
Appeal 2017-004917
Application 14/150,602
restated in cited references). In other words, consistent with the
Specification, upon initialization of Kumar’s multi-core system, each packet
processing engine would be idle because each engine is “not processing
[packets] and to which no packet has been allocated.” Spec. 147.
Claim 9
Appellants argue one of ordinary skill in the art would not utilize a 16
bit processor of Wilkinson in the communication compression of Kumar,
which discloses SMS messages that are 32 bits, because using a 16 bit
processor would present technological difficulties and associated
disadvantages when applied to the 32 bit system of the present application.
Appeal Br.28— 29. But Appellants mischaracterize Kumar by stating that it
is limited to SMS messages that are “32 bits long.”
Although Kumar discloses the SMS messages can be, for example, a
32-bit integer (see Kumar 1268), Kumar is not limited to such an
embodiment. Kumar also discloses embodiments that use multipart or long
SMS messages and an embodiment in which the SMS and other text
messages are 1120 bits or less in length, for example, no greater than 160 7-
bit characters, 140 8-bit characters, or 70 16-bit characters. Kumar 1228.
Accordingly, we find Appellants’ argument unpersuasive because Kumar’s
disclosure evidences the flexibility to use different bit systems, including a
16-bit system such as the system disclosed in Wilkinson. Compare Kumar |
228, with Wilkinson Fig. 18 (cluster 0 showing 512 PMEs), 15:30 (“each
PME is a 16 bit wide processor with 32K words of local memory”), 26:37—
3 8 (“[T]he PME has its 32K by 16 bit main store in the form of two DRAM
macros.”).
20
Appeal 2017-004917
Application 14/150,602
In conclusion, having considered the Examiner’s rejections of claims
1, 2, 4, 6, 7, 8, and 9 in light of each of Appellants’ arguments and the
evidence of record, we disagree with Appellants and agree with the
Examiner’s findings, conclusions, and reasoning, which we adopt as our
own. Appellants do not present separate arguments for independent claims
10, 16, and 19 or dependent claims 3, 5, 11—15, 17, 18, and 20; thus, these
claims fall with representative claim 1. Appeal Br. 29-30; 37 C.F.R.
§ 41.37(c)(l)(iv). We sustain the Examiner’s rejections of claims 1—20.
DECISION
We affirm the Examiner’s decision rejecting claims 1—20.
No time period for taking any subsequent action in connection with
this appeal may be extended under 37 C.F.R. § 1.136(a)(1). See 37 C.F.R.
§§ 41.50(f), 41.52(b).
AFFIRMED
21