Israel L'Heureux et al.

Patent Trials and Appeals Board

Aug 29, 2019

14197019 - (D) (P.T.A.B. Aug. 29, 2019)

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/197,019 03/04/2014 ISRAEL L'HEUREUX 0013C1 3920
99476 7590 08/29/2019
Mark D. Alleman
12550 SW Iron Mountain Blvd.
Portland, OR 97219
EXAMINER
RAZA, MUHAMMAD A
ART UNIT PAPER NUMBER
2449
NOTIFICATION DATE DELIVERY MODE
08/29/2019 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):
mark.alleman@gmail.com
michael@andriconsulting.com
patents@andriconsulting.com
PTOL-90A (Rev. 04/07)
UNITED STATES PATENT AND TRADEMARK OFFICE
____________

BEFORE THE PATENT TRIAL AND APPEAL BOARD
____________

Ex parte ISRAEL L‘HEUREUX and MARK D. ALLEMAN
___________

Appeal 2017-011609
Application 14/197,019
Technology Center 2400
____________

Before MAHSHID D. SAADAT, ERIC B. CHEN, and
CARL L. SILVERMAN, Administrative Patent Judges.

CHEN, Administrative Patent Judge.

DECISION ON APPEAL

Appeal 2017-011609
Application 14/197,019

2
This is an appeal under 35 U.S.C. § 134(a) from the final rejection of
claims 21 and 24–40. Claims 1–20, 22, and 23 have been cancelled. We
have jurisdiction under 35 U.S.C. § 6(b). An oral hearing scheduled for
June 25, 2019 was waived. We reverse.

STATEMENT OF THE CASE
Appellants’ invention relates a network appliance configured to
receive from a client device, via a client-side wide area network, an HTTP
non-compliant request stream including HTTP non-compliant requests. The
network appliance is further configured to translate the HTTP non-compliant
requests of the HTTP non-compliant request stream into HTTP compliant
requests of an HTTP compliant request stream, and to forward the HTTP
compliant request stream including the HTTP compliant requests to server
devices via a server-side local area network. (Abstract.)
Claim 21 is exemplary, with disputed limitations in italics:
21. A network communications system, comprising:
a network appliance including a processor configured to:
receive from a client device via a client-side wide area
network, a non-compliant request stream including multiple
non-compliant requests formatted according to a non-compliant
application level protocol that is non-compliant with RFC
1945/HTTP/1.0 and RFC 2616/HTTP/1.1 at least because the
non-compliant application level protocol multiplexes the
multiple non-compliant requests of the client device over an
application level protocol specified number of client-side TCP
connections between the client-device and the network
appliance;
translate the multiple non-compliant requests of the non-
compliant request stream from the non-compliant application
level protocol into multiple compliant requests of a compliant
Appeal 2017-011609
Application 14/197,019

3
request stream formatted according to a compliant application
level protocol that is compliant with one of RFC
1945/HTTP/1.0 and RFC 2616/HTTP/1.1, by demultiplexing
the multiple noncompliant requests from the application level
protocol specified number of client-side TCP connections to a
programmatically specified number of persistent server-side
TCP connections, the application level protocol specified
number being less than the programmatically specified number;
forward the compliant request stream including the
multiple compliant requests to one or more server devices via
the persistent server-side TCP connections on a server-side
local area network;
receive a compliant response stream including multiple
compliant responses from the one or more server devices via
the persistent server-side TCP connections on the server-side
local area network, the multiple compliant responses being
responsive to the multiple compliant requests, the multiple
compliant responses formatted according to the compliant
application level protocol that is compliant with one of RFC
1945/HTTP/1.0 and RFC 2616/HTTP/1.1;
translate the multiple compliant responses of the
compliant response stream into multiple non-compliant
responses of a non-compliant response stream formatted
according to the non-compliant application level protocol that is
non-compliant with RFC 1945/HTTP/1.0 and RFC
2616/HTTP/1.1 by multiplexing the multiple compliant
responses for the client device from the programmatically
specified number of persistent server-side TCP connections to
the application level protocol specified number of client-side
TCP connections between the client device and the network
appliance; and
forward the non-compliant response stream including the
multiple non-compliant responses to the client device via the
client-side TCP connections on the client-side wide area
network;
Appeal 2017-011609
Application 14/197,019

4
the processor of the network appliance executing a
translator module and an application delivery controller
module, the translator module including one or more of:
a rewriter module configured to modify one or
more of a URL, a header, or a data payload of the non-
compliant request stream or the non-compliant response
stream;
a protocol module configured to select the non-
compliant application level protocol from a plurality of
protocols supported by the network appliance;
a stream decomposer configured to translate the
non-compliant request stream into the compliant request
stream;
a stream recomposer configured to translate the
compliant response stream into the non-compliant
response stream; and
a rules engine configured to instruct one or more
of the rewriter module of the translator module, protocol
module, stream decomposer, or stream recomposer to
perform respective actions in accordance with the one or
more rules upon satisfaction of a respective condition
associated with each rule; the application delivery
controller module including one or more of:
a rewriter module configured to modify one or
more of a URL, a header, or a data payload of the
compliant request stream or the compliant response
stream;
a load balancer module configured to load balance
the forwarded compliant requests of the compliant
request stream among a plurality of server devices
including the one or more server devices;
a multiplexer/demultiplexer module configured to
multiplex one or more of the compliant requests of the
client device with one or more other compliant requests
of one or more other client devices, and demultiplex one
or more of the compliant responses for the client device
Appeal 2017-011609
Application 14/197,019

5
from one or more other compliant responses for one or
more other client devices;
and a rules engine configured to instruct one or
more of the rewriter module of the application delivery
controller, load balancer module, or
multiplexer/demultiplexer module to perform respective
actions in accordance with the one or more rules upon
satisfaction of a respective condition associated with each
rule.

Claims 21 and 24–40 stand rejected under 35 U.S.C. § 112(a) as
failing to comply with the written description requirement.
Claims 21 and 24–40 stand rejected under 35 U.S.C. § 112(b) as
indefinite for failing to particularly point out and distinctly claim the subject
matter which the inventor or a joint inventor regards as the invention.
Claims 21 and 24–40 stand rejected under 35 U.S.C. § 103 as
unpatentable over Zilbershtein (US 2008/0008211 A1; Jan. 10, 2008),
Watson (US 2011/0222404 A1; Sept. 15, 2011), and Christenson (US
2008/0114882 A1; May 15, 2008).

ANALYSIS
§ 112(a) Rejection
We are persuaded by Appellants’ arguments (App. Br. 17) that the
functional limitations recited in independent claims 21 and 35 comply with
the written description requirement under 35 U.S.C. § 112(a).
The Examiner found that “[e]ven original claims may fail to satisfy
the written description requirement when the invention is claimed and
described in functional language but the specification does not sufficiently
Appeal 2017-011609
Application 14/197,019

6
identify how the invention achieves the claimed function.” (Final Act. 5.)
In particular, the Examiner found the following:
Applicant does not even disclose a representative number of
species (i.e., algorithms or steps/procedures) in the specification
for the claimed genus for achieving the functionality “translate
the multiple non-compliant requests of the non-compliant
request stream from the non-compliant application level
protocol into multiple compliant requests of a compliant request
stream . . . translate the multiple compliant responses of the
compliant response stream into multiple non-compliant
responses of a non-compliant response stream formatted
according to the non-compliant application level protocol”
(Id. at 7–8.) We do not agree with the Examiner’s findings.
Figure 2 of Appellants’ Specification illustrates a flow diagram for an
exemplary network communications method 200 (¶ 19), which includes
steps 210 to 224 (¶¶ 21–29). In one embodiment, network communications
method 200 can be executed on network appliance 110, as illustrated in
Figure 1. (¶ 19.) Moreover, Appellants’ Specification discloses that
Figures 3 and 4 illustrate different embodiments of network appliances 310
and 410, respectively. (¶¶ 7–8, 31, 45.) Thus, because the Specification
discloses that network communications method 200, an algorithm, can be
executed on either of network appliances 110, 310, and 410, three separate
embodiments, the Specification provides written description support for the
functional limitations recited in independent claims 21 and 34. See Ariad
Pharm., Inc. v. Eli Lilly & Co., 598 F.3d 1336, 1349 (Fed. Cir. 2010) (en
banc) (“the specification must demonstrate that the applicant has made a
generic invention that achieves the claimed result and do so by showing that
the applicant has invented species sufficient to support a claim to the
functionally-defined genus.”)
Appeal 2017-011609
Application 14/197,019

7
Accordingly, we are persuaded by Appellants’ arguments that
Furthermore, the specification and drawings provide numerous
examples of algorithms and steps/procedures of which the claimed
subject matter represents a specific implementation. . . . Within each
step of FIG. 2, numerous examples and alternatives are provided. . . .
FIGS. 3 and 4, and associated description disclose how the algorithm
of FIG. 2 may be implemented within a network appliance in a variety
of different ways, including with respect to the SPDY protocol and
other enhanced protocols.
. . . FIGS. 3 and 4 represent different algorithms having
different steps/procedures that may depend, for example, on the type
of non-compliant algorithm that is being translated.
(App. Br. 17.)
Thus, we do not agree with the Examiner that the Specification fails to
provide written description support for the functional limitations recited in
independent claim 21.
Accordingly, we do not sustain the rejection of independent claim 21
under 35 U.S.C. § 112(a). Claims 24–34 depend from claim 21. Therefore,
we do not sustain the rejection of claims 24–34 under 35 U.S.C. § 112(a) for
the same reasons discussed with respect to independent claim 21.
Independent claim 35 recites limitations similar to those discussed
with respect to independent claim 21. Claims 36–40 depend from claim 21.
Therefore, we do not sustain the rejection of claims 36–40 under 35 U.S.C.
§ 112(a) for the same reasons discussed with respect to independent
claim 21.

§ 112(b) Rejections
First, we are persuaded by Appellants’ arguments (Reply Br. 3) that
the limitation “wide area network,” as recited in independent claim 24,
Appeal 2017-011609
Application 14/197,019

8
complies with 35 U.S.C. § 112(b) by particularly pointing out and distinctly
claiming the subject matter which the inventor or a joint inventor regards as
the invention.
With respect to independent claim 24, the Examiner found that “the
term ‘wide area network’ is a relative term which renders the claim
indefinite.” (Ans. 5 (emphasis omitted).) In particular, the Examiner found
that “[t]he term ‘wide area network’ is not defined by the claim, the
specification does not provide a standard for ascertaining the requisite
degree, and one of ordinary skill in the art would not be reasonably apprised
of the scope of the invention.” (Id.) We do not agree.
In reference to Figure 1, Appellants’ Specification discloses the
following:
Network appliance 110 may facilitate network communications
between client devices 170 and server devices 160 via
respective client-side wide area network 140 and server-side
local area network 150. As one example, network appliance
110 may connect thousands of client devices to hundreds of
server devices of a server farm.
(¶ 10 (emphasis added).) Thus, Appellants’ Specification discloses that
communication distances between client devices 170 in wide area network
(WAN) 140 are determined relative to communication distances between
server devices 160 in local area network (LAN) 150. In other words, one of
ordinary skill would understand that the geographical area for devices in a
WAN (e.g., client devices 170) are determined relative to the geographical
area for devices in a LAN (e.g., server devices 160).1

1 One relevant definition of “WAN” (or “wide area network”) is “[a]
geographically widespread network, one that relies on communications
capabilities to link the various network segments,” such that “[a] WAN can
Appeal 2017-011609
Application 14/197,019

9
Accordingly, we are persuaded by Appellants’ arguments that
The claim language itself also establishes a network topology
defining the LAN as the network between the network
appliance and the server, and the WAN as the network between
the client and the network appliance. As one of ordinary skill
in the art would appreciate, LANs connect computers in a close
physical area and enable higher communication speeds and
lower latency, while WANs connect computers across greater
distances than LANs and have lower communication speeds
and higher latency.
(Reply Br. 3.)
Thus, we do not agree with the Examiner that the limitation “wide
area network” is indefinite.
Second, we are persuaded by Appellants’ arguments (Reply Br. 3) that
the limitation “non-compliant application level protocol,” as recited in
independent claim 24, complies with 35 U.S.C. § 112(b) by particularly
pointing out and distinctly claiming the subject matter which the inventor or
a joint inventor regards as the invention.
With respect to independent claim 24, the Examiner found that “the
term ‘non-compliant application level protocol’ is not a well-known term in
that art.” (Ans. 6 (emphasis omitted).) In particular, the Examiner found
that “[t]he term ‘non-compliant application level protocol’ is a subjective
term coined by the appellant to obfuscate the claim language to prevent
relevant prior art from being discovered” (id.) and “appellant fails to

be one large network, or it can consist of a number of linked LANs (local
area networks).” MICROSOFT® COMPUTER DICTIONARY 561 (5th ed. 2002).
Likewise, one relevant definition of “LAN” (or “local area network”) is “[a]
group of computers and other devices dispersed over a relatively limited area
and connected by a communications link that enables any device to interact
with any other on the network.” (Id. at 304.)
Appeal 2017-011609
Application 14/197,019

10
describe or mention in the specification what constitute or is meant by ‘non-
compliant application level protocol’” (id. at 7). We do not agree.
Independent claim 24 recites “a non-compliant application level
protocol that is non-compliant with RFC 1945/HTTP/1.0 and RFC
2616/HTTP/1.1” (emphasis added).
Appellants’ Specification discloses the following:
The Hypertext Transfer Protocol (HTTP) is a commonly used
application level protocol for communicating on the Internet
within the Transmission Control Protocol (TCP) transport layer
of the Internet Protocol Suite. Recent advancements in
application level protocols within the TCP framework, such as
SPDY, HTTP-MPLEX, and other enhanced application level
protocols may not be supported by HTTP compliant servers.
(¶ 2 (emphasis added).) Thus, according to Appellants’ Specification,
examples of more advanced application level protocols, which are not
supported by HTTP servers, are SPDY and HTTP-MPLEX. One of ordinary
skill in the art would interpret the claim language “a non-compliant
application level protocol” as an application level protocol that is not
supported by an HTTP compliant server, for example, RFC 1945/HTTP/1.0
and RFC 2616/HTTP/1.1. Accordingly, because Appellants’ Specification
provides an explanation of compliant (and non-compliant) application level
protocols, those skilled in the art would understand what is claimed when the
claim is read in light of the Specification. See Power-One, Inc. v. Artesyn
Techs., Inc., 599 F.3d 1343, 1350 (Fed. Cir. 2010).
Accordingly, we are persuaded by Appellants’ arguments that “[t]he
term ‘non-compliant’ does not introduce vagueness into the claims because
the exact manner of non-compliance is recited on the face of the claim.”
(Reply Br. 3.)
Appeal 2017-011609
Application 14/197,019

11
Thus, we do not agree with the Examiner that the limitation “non-
compliant application level protocol” is indefinite.
Last, we are persuaded by Appellants’ arguments (App. Br. 20–21)
that the limitations “application level protocol specified number of TCP
connections” and “programmatically specified number of TCP connections,”
as recited in independent claim 24, complies with 35 U.S.C. § 112(b) by
particularly pointing out and distinctly claiming the subject matter which the
inventor or a joint inventor regards as the invention.
With respect to independent claim 24, the Examiner found that “the
term ‘programmatically specified number of TCP connections’ is . . . coined
by the appellant and it is a subjective term with subjective meaning” and
“[t]he term ‘programmatically specified number of TCP connections’ is
completely subjective.” (Ans. 12.) We do not agree.
Appellants’ Specification discloses the following:
In at least some implementations, network appliance 110
may be configured to demultiplex multiple responses for
multiple clients from a response stream received from a server
device from the programmatically specified number of
persistent server-side TCP connections to the application level
protocol specified number of client-side TCP connections.
Network appliance 110 may be further configured to multiplex
multiple responses for an individual client device over the
application level protocol specified number of client-side TCP
connections. As one example, the SPDY application level
protocol may specify only a single client-side TCP connection
for receiving responses from network appliance 110.
(¶ 12 (emphasis added).)
In at least some implementations, the one or more HTTP
compliant requests of the HTTP compliant request stream may
be sent to the one or more server devices over a
programmatically specified number of TCP connections . . . .
Appeal 2017-011609
Application 14/197,019

12
Furthermore, in at least some implementations, multiple HTTP
compliant requests of multiple client devices may be
multiplexed over a given TCP connection with a server device
as will be described in greater detail with reference to FIGS. 3
and 4.
(¶ 24 (emphasis added).) Accordingly, Appellants’ Specification discloses
that the recitation of “application level protocol specified number of TCP
connections” is in reference to the client-side TCP connection and provides
one example as a single TCP connection for the SPDY application level
protocol. (¶ 14.) Similarly, Appellants’ Specification discloses that the
recitation of “programmatically specified number of TCP connections” is in
reference to the server-side TCP connection. (¶ 24.)
Accordingly, because Appellants’ Specification provides an
explanation of “application level protocol specified number of TCP
connections” and “programmatically specified number of TCP connections,”
those skilled in the art would understand what is claimed when the claim is
read in light of the Specification. See Power-One, 599 F.3d 1343 at 1350.
Accordingly, we are persuaded by Appellants’ arguments that:
The phrase “application level protocol specified number”
on the client side of the network appliance is used to distinguish
from the “programmatically specified number” of TCP
connections on the server side of the network appliance. The
claims further provide that this application level protocol
specified number is less than the programmatically specified
number.
(App. Br. 20–21.)
Thus, we do not agree with the Examiner that the limitations
“application level protocol specified number of TCP connections” and
“programmatically specified number of TCP connections” are indefinite.
Appeal 2017-011609
Application 14/197,019

13
Accordingly, we do not sustain the rejection of independent claim 21
under 35 U.S.C. § 112(b). Claims 24–34 depend from claim 21. Therefore,
we do not sustain the rejection of claims 24–34 under 35 U.S.C. § 112(b) for
the same reasons discussed with respect to independent claim 21.
Independent claim 35 recites limitations similar to those discussed
with respect to independent claim 21. Claims 36–40 depend from claim 21.
Therefore, we do not sustain the rejection of claims 36–40 under 35 U.S.C.
§ 112(b) for the same reasons discussed with respect to independent
claim 21.

§ 103 Rejection
We are persuaded by Appellants’ arguments (App. Br. 26; see also
Reply Br. 3–4) that the combination of Zilbershtein, Watson, and
Christenson would not have rendered obvious independent claim 21, which
includes the limitation “receive from a client device via a client-side wide
area network a non-compliant request stream.”
The Examiner found that the bidirectional gating of Zilbershtein
between low parallelity devices in a network (e.g., client LANs 170B and
170C) and a remote server with a higher parallelity capability (e.g., WAN
server 110), corresponds to the limitations
receive from a client device via a client-side wide area network,
a non-compliant request stream . . . .
. . . translate the multiple non-compliant requests of the non-
compliant request stream from the non-compliant application
level protocol into multiple compliant requests of a compliant
request stream . . .
. . . forward the compliant request stream including the multiple
compliant requests to one or more server devices via the
Appeal 2017-011609
Application 14/197,019

14
persistent server-side TCP connections on a server-side local
area network.
(Final Act. 13–14.) In particular, the Examiner found that “wide area
network (WAN) and local area network (LAN) [are] merely . . . networks
providing connections between devices” and “the use of WAN and LAN in a
particular orientation by the appellant is completely subjective and merely a
design choice without any impact on the functionality in view of the
specification.” (Ans. 23.) We do not agree with the Examiner’s findings.
Zilbershtein relates to “translation of data between protocols with
different degrees of parallelity.” (¶ 2.) Zilbershtein explains that “[i]n an
exemplary embodiment of the invention, there is provided a method for
bidirectional gating between low parallelity devices in a network and a
remote server with a higher parallelity capability.” (¶ 25.) In particular,
Figure 1 of Zilbershtein “illustrates communication between WAN server
110 and client LANs 170B and 170C.” (¶ 93.) Moreover, Zilbershtein
explains that “low parallelity protocols are inefficient over WAN links and
are prone to timeouts and/or repeat requests” and “[a]s a result, use of low
parallelity protocols over a WAN link is undesirable.” (¶ 95.)
Although the Examiner cited to the low parallelity devices of
Zilbershtein in a network, for example, client LANs 170B and 170C, the
Examiner has provided insufficient evidence to support a finding that
Zilbershtein teaches the limitation “receive from a client device via a client-
side wide area network a non-compliant request stream” (emphasis added).
In particular, because Zilbershtein explains that that “low parallelity
protocols are inefficient over WAN links” due to timeouts and repeat
requests (¶ 95), the Examiner has not demonstrated that the substitution of
Appeal 2017-011609
Application 14/197,019

15
WAN link for the low parallelity devices of Zilbershtein is “design choice
without any impact on the functionality” (Ans. 23).
On this record, the Examiner has not shown that Zilbershtein teaches
the limitation “receive from a client device via a client-side wide area
network a non-compliant request stream.” In addition, Watson and
Christenson do not cure the above noted deficiencies of Zilbershtein.
Thus, we are persuaded by Appellants’ arguments, as follows:
Zilbershtein discourages the use of low parallelity
protocols over a WAN link by disclosing that the “use of low
parallelity protocols over a WAN link is undesirable”. Yet, this
is the approach described by claim 21. The claimed subject
matter, when considered in its entirety provides that the lesser
number of TCP connections are used on the WAN and the
greater TCP connections are used on the LAN.
(App. Br. 29 (emphasis omitted); see also Reply Br. 3–4.)
Accordingly, we do not sustain the rejection of independent claim 21
under 35 U.S.C. § 103. Claims 24–34 depend from independent claim 21.
We do not sustain the rejection of claims 24–34 under 35 U.S.C. § 103 for
the same reasons discussed with respect to independent claim 21.
Independent claim 35 recites limitations similar to those discussed
with respect to independent claim 21. We do not sustain the rejection of
claim 35, as well as dependent claims 36–40, for the same reasons discussed
with respect to claim 21.

DECISION
The Examiner’s decision rejecting claims 21 and 24–40 under 35
U.S.C. § 112(a) is reversed.
Appeal 2017-011609
Application 14/197,019

16
The Examiner’s decision rejecting claims 21 and 24–40 under 35
U.S.C. § 112(b) is reversed.
The Examiner’s decision rejecting claims 21 and 24–40 under 35
U.S.C. § 103 is reversed.

REVERSED